Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / char * == "" Debug vs Release

Author
Message
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 22nd Aug 2008 13:45
This is quite a weird problem. In the below code, when in debug Test is equal to "" but in release Test is not equal to "", I have set every setting in project settings to be the same for both release and debug so what is causing the difference?



I've attached the project folder.

Attachments

Login to view attachments
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 22nd Aug 2008 14:18
It's possible the strings are pooled in debug mode(but it doesn't matter as you shouldn't rely on the compiler to produce the same results here as unless I'm mistaken it's not defined in the C standard for strings like this to have the same address, why should they?), either way, by the look of your code you don't want to be doing this. You aren't comparing strings here, you're comparing the addresses of those chars, so you're comparing a char* to a char*. If you wish to compare a c-style string to another then use strcmp(), where a return value of 0 means a match.

Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 22nd Aug 2008 17:18
It can't be stated more strongly. You do NOT use the equality operator when testing for the equality of a string when that string is represented by an address/pointer.

Test is a pointer that holds the address of a (very short) static character array somewhere in memory. When you state

Test == ""

you're comparing the address held in Test to the address of (probably) another (very short) static character array somewhere else in memory. Sometimes the compiler will consolidate matching strings into a single string but it depends on the implementation.

When comparing the equivalency of character arrays as string use the strcmp or stricmp functions.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 22nd Aug 2008 17:44
Quote: "(but it doesn't matter as you shouldn't rely on the compiler to produce the same results here as unless I'm mistaken it's not defined in the C standard for strings like this to have the same address, why should they?)"

You're right, but see this taken from here:

Quote: "Whether all string literals are distinct (that is, are stored in nonoverlapping objects) is implementation-defined"


The reason some compilers give string pooling as an option is probably because it saves space. After all there's no point in using distinct storage for string constants that are the same.

I agree with what Lilith said, although I'd like to add that it is in one case possible to compare via pointers, but both pointers must point to string literals, and string pooling must be enabled. There are no exceptions.

ionstream
20
Years of Service
User Offline
Joined: 4th Jul 2004
Location: Overweb
Posted: 23rd Aug 2008 10:02
Apparently in MSVC++ 2008, Debug does do string pooling, and I can't find it in the Configuration anywhere so it must be implied by Debug. Odd.

But yeah, either use strcmp or std::string.

Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 23rd Aug 2008 16:07
C/C++->Code Generation->Enable String Pooling

ionstream
20
Years of Service
User Offline
Joined: 4th Jul 2004
Location: Overweb
Posted: 23rd Aug 2008 23:22
Oddly enough though, both debug and release mode have "No" for string pooling on my machine, but debug definitely pools!

I think I've found it: in the General tab, changing the debugging format to Program Database for Edit & Continue (/ZI) (the same as debug) will cause the string pointers to be the same.
Sorry, this was bugging me :/ .

Login to post a reply

Server time is: 2024-09-30 05:33:59
Your offset time is: 2024-09-30 05:33:59