Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

<string> size problems

Status
Not open for further replies.

mlatimer

IS-IT--Management
Jul 18, 2002
6
0
0
GB
Hi all

Imconfused by a daft problem..
Our apps are written using MFC (CStrings etc) but we are using a library which uses ATL (strings). I understand tstring is a basic string but cant get my head around this simple problem...
I cannot assign a tstring longer than 15 chars...
To show an example..

string s1;
CString cs1;
cs1 = m_sRootURL.Left(10);
s1 = cs1.GetString(); // ok

cs1 = m_sRootURL.Left(12);
s1 = cs1.GetString(); // ok

cs1 = m_sRootURL.Left(14);
s1 = cs1.GetString(); // ok

cs1 = m_sRootURL.Left(16);
s1 = cs1.GetString(); // not ok, s1 = "5rf"

All help etc.. etc...
 
Problem may be with GetString. Try
Code:
s1 = (LPCTSTR) cs1;
 
Many thanks for this, but same result.
Any other suggestions?
Am running in debug mode in vc7.0, could it be a project compiler setting issue?
 
chipper, no its not.
This was(is) test code to see what was happening in the app whilst debugging. Is more than 20 chars (typical ftp URL).

The idea of the code above was to see how many chars i could transfer (as I have other vars that were transfering with no problems at all)...
 
Ok, just checking the obvious stuff first.


The fact that you get garbage when it fails makes me think that the CString uses a different representation for short strings than for long ones; many string classes do that.

You're assigning it a long string, which it probably stores in dynamic memory. Then, for whatever reason, it's returning the (probably non-dynamic) memory location used to store short strings. Since that's never been used, it contains garbage.
 
In which case, would you expect

cs1 = m_sRootURL.Left(10);
s1 = (LPCTSTR)cs1;

cs1 = m_sRootURL.Mid(10,10);
s1 += (LPCTSTR)cs1;

to work?
The first call is fine, the second junks the <string>.

If the <string> is initailzed correcly {as in string("")}. the junking takes the form of returning the string to empty, BUT the _mySize and _myRes members indicate correct values of 20 and 31....

arrgghh
 
That's what I'd expect if the STL [tt]string[/tt] had the problem I mentioned. That's also consistent with the problem in your initial post. Sounds like a buggy [tt]string[/tt] implementation to me.


Well, hold on a sec... you say you're running in debug mode. Are you getting your info by examining the memory locations through the debugger, or does your application actually gve you bad values when you run it?

Because if you're just using the debugger to look at a memory location, and the string uses two different memory locations to hold strings, then, you may just always be looking at the "short string" memory location, so you never see the long string.

In other words, your application may be working fine, and you're just looking in the wrong place.
 
Im afraid the junk string is passed to the funtion that requires it.
I'm using VC7.0 so I would assume that the <string> implementation cannot be "that" buggy. Can it?
 
I've just tried your posted code with m_sRootURL set to "abcdefghijk" and it works as expected.

Is the CString made up of char or wchar_t? string only knows about char. You need wstring for wchar_t.
 
mlatimer said:
I would assume that the <string> implementation cannot be "that" buggy. Can it?
I'd certainly hope not. A quick Google search didn't turn up any such bug, and that should be a fairly obvious one...


How does the code work if you try it in non-debug mode?

Is there anything fundamentally different about the way you're using this particular string and the way you're using the other ones that work?


Otherwise, I'm stumped.
 
xwb, yes, with "abcdefghijk" its ok , (11 chars). Its only when i get over 15.

CString is char (neither UNICODE or _MCBS set).
 
chipperMDW said:
Well, hold on a sec... you say you're running in debug mode. Are you getting your info by examining the memory locations through the debugger, or does your application actually gve you bad values when you run it?
mlatimer said:
Im afraid the junk string is passed to the funtion that requires it.
You didn't answer the question...

How do you know a junk string is getting passed to the function? Unless you output it to the screen or check the length by calling length() or size() I don't think you can be sure. It very well might be some other issue, but assigning a CString to an STL string works for everybody else, so I would make sure you are not looking at the string while debugging when you see your problem.
 
Seems to work fine with 26 chars. How are you printing the contents of s1? Is it s1.c_str() or just s1 or are you looking at it in the debugger?

Can you just write a noddy program and see if it works. If it doesn't, post it.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top