The bottom line is that there is no setting for this, and there is no known
It's probably just a mistake in your code. If you want more specific help,
I'll try to explain myself better:
Firstly, I am interfacing with another piece of software and I use some
#include's from their software. All of their strings use: unsigned short
*.
I had compiler problems when I used the Treat wchar_t as built-type set to
YES.
I agree totally on my bad form of declaring my string variable wchar_t
instead of TCHAR...I have changed that.
My real issue/question concerns the following:
I have an exported function from an MFC dll:
bool MyFunction( LPTSTR szString );
I call the function as follows:
TCHAR szMyString[31] = {0};
MyFunction( szMyString );
At time of variable declaration, an example memory location is: 0x0012fe30
When I step into MyFunction, the address of the szMyString is: 0x0012fe34.
One thing of note: After the line that declares the variable, szMyString,
the first two characters (array elements) have values in them (not ascii
codes), the remaining characters are zero'd. I'd have thought that using
=
{0} would have cleared the whole character array.
This behavior is only exhibited in the Release build of the program. Am I
missing some build setting? I have gone through them many times and can't
see it.
"Joseph M. Newcomer" wrote:
See below...
On Wed, 3 Dec 2008 18:43:01 -0800, JR <JR@discussions.microsoft.com>
wrote:
I believe I am going crazy. I just compiled the 'release' version of my
program and am having issues with the passing of a wchar_t string to a
function.
Both Debug and Release:
- stdcall calling convention
- treat wchar_t as built-in type = NO
- unicode char set
code:
bool MyFunction( LPTSTR szString );
wchar_t szMyString[31];
****
Why are you declaring a variable of wide character type of fixed size?
This is usually
dangerous. If the parameter is LPTSTR, you will need to use T2W to make
sure it is a
wide-character string at the point where you pass it.
You have not said what you are doing here, and the relationship of the
szMyString[31] to
MyFunction. For example, are you doing
MyFunction(szMyString);
?
If so, you should have said so. Note that if it is an LPTSTR, you cannot
pass a wchar_t
to it; you can only pass a TCHAR, because it will only work in Unicode
builds and as such
the code you have written is incorrect.
Also, why did you set "treat wchar_t as built-in type" to NO? This will
cause problems
with C++ name resolution and binding, since one will try to bind a
wchar_t in the name and
the other will try to bind a short.
****
When I declare the szMyString variable, it has a starting memory address
4
bytes BEFORE the address that it has when it is passed inside the
function.
This only happens on the Release version of the program. Am using
VS2005.
Any ideas?
****
This is a meaningless statement. The addresses in different builds will
be in different
places for good reasons. So what if they are in different addresses?
What is important
is whether or not the address is a pointer to the string. If you think
addresses are
going to be consistent between debug and release builds, you have made a
very serious
error in logic. Addresses are wherever they end up being. If that
variable is a local
variable, what would surprise me would be if it was at the SAME address
between debug and
release builds. Now THAT would be an anomaly.
If you say that the address in one build points to a different string or
to a different
location which is *not* part of the string, that makes sense to say that
there is
something wrong. But if the pointer really points to the string, its
address is
completely meaningless to you, and worrying about its numeric value is a
pointless
concern.
joe
****
Thanks,
Jeremy
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm