Skip to main content
gamedev.net
🔒 Locked

string problem (C++)

Started by laotzu8 Jan 12, 2003 at 3:03 AM 5 replies 200+ views
Original Post
laotzu8
laotzu8
I had a really wierd problem suddenly pop up with my usage of string (std:. So I made a simple test program and still got the same results. The problem occurs when I try to append 16 or more characters to a string (test prog follows) ------- #include <string> int main() { string x = "12345678901234"; //x="12345678901234" - alls good x += "5"; //x="123456789012345" x += "6"; //<--- problem occurs here (x="h,2") x += "7"; //x="h,2" return 0; //"h,2" can be other random characters as well } ------- This is using Visual Studio .NET Professional. I was certainly using strings before today, without this problem (*curses himself for not using source control at home*). Anyways, the problem doesn''t occur using the exact same code in Visual Studio 6.0. Looking at the string (x) in quickwatch - there''s a weird member in the .NET version of string called _Bx (which contains two variables: _Ptr (char *) and what would appear to be the trouble maker - _Buf (char[16])). In the VS6.0 version the only member string has is _Ptr, I can''t figure out where that char[16] comes from - or what made it start occuring today... Thank you very much for any ideas on what the problem is. Let me know if you need more info. -laotzu
civguy
civguy
_Buf is there so that small strings, i.e. strings less than 17 characters, could be stored without allocating memory from the heap.

Dunno why it crashes on you though. Maybe your version has a bug? I have MSVC.NET too with same _Buf member in my string and your example worked fine.
dalleboy
dalleboy
Are you only looking at the string in the Watch window? Try to do a MessageBox(NULL, x.c_str(), "Output", MB_OK) to see if it is the Watch window that is incorrect.



Update GameDev.net system time campaign: ''date ddmmHHMMYYYY''
null_pointer
null_pointer
It is the watch window that is incorrect. cout << x << endl prints the correct string.
null_pointer
null_pointer
BTW there is no need to return anything from main.
laotzu8
laotzu8
Thank you all for your help in this matter. It turns out that the string did indeed hold the correct value - it was just VS''s display that was wrong. Don''t know why it didn''t occur to me to try outputting the actual string last night.

Thanks again,
-laotzu

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.