Very Strange behaviour with LPCTSTR

[SMSdude]

Hi all,

I've got a very strange thing happening and cannot figure it out.

In the following code the first messagebox displays "SUCCESS" and the second "not equal too". What could be the reason why it would enter the loop? I made some changes to the build properties - could it be that?

LPCSTR strConnect = "SUCCESS";//pEBUF->Connect();
AfxMessageBox((strConnect));
			
if (strConnect != "SUCCESS")
{
      	AfxMessageBox("not equal too");
}

Thanks
SMSDude

[bitshifter420]

You Cant Compare LPCTSTR Like That.

Do It Like So...

if(lstrcmp(strConnect, "SUCCESS") == 0)
{
...
}

[SMSdude]

Thanks bitshifter420

I'm just confused as to why it worked before...

[VictorN]

I'm just confused as to why it worked before...

It was just your delusion that "it worked"...

[0xC0000005]

Thanks bitshifter420

I'm just confused as to why it worked before...

There are actually times when something such as you describe will 'work' although it's not proper coding. It all depends on how the compiler deals with static strings. Since you have two static strings defined as "SUCCESS" then the complier can store two instances of "SUCCESS" or just one - as long as storing just one does not interfere with the operation of the program.

For example:

	LPCSTR s1 = "SUCCESS";
	LPCSTR s2 = "SUCCESS";

	CString message;
	
	message.Format("SUCCESS=%p, s1=%p (%s), s2=%p (%s) SUCCESS=%p\n","SUCCESS",s1,s1,s2,s2,"SUCCESS","SUCCESS");
	
	::OutputDebugString(message);

The output of this code is:
SUCCESS=00420520, s1=00420520 (SUCCESS), s2=00420520 (SUCCESS) SUCCESS=00420520

The example clearly shows that only one static instance of the string literal "SUCCESS" is stored and so comparisons such as you made are likely to work even though they are not proper.

By the way, I compiled your code and it does work for me as you were expecting - it DOES NOT display "not equal too".

[Conrad Braam]

Basically as xC0000005 stated, your code is actually comparing a pointer to the literal "SUCCESS" to your pointer. Nothing prevents the compiler from having placed the 2 in separate modules and then failing the pointer-comparison. Generally you are safe, but it's non-portable code you are writting, if someone move your constants to another DLL, or to another namespace, you will fail the compare.

Been badly bitten in a similar way when defining a pointer in one module and then declaring it elsewhere slightly differently, another common error.
extern char * mystring[];
... other module
char *mystring="hello world";
...they are not the same 'mystring' in the end.

[kirants]

I'm just confused as to why it worked before...

If the strConnect was a CString, your code would've worked as intended.