Re: wchar_t as a string parameter

Tech-Archive recommends: Fix windows errors by optimizing your registry

Also, just to add, I am not a big fan of hard coding numbers as array sizes so I'd likely do something like:

#define STRING_SIZE 31

TCHAR szMyString[STRING_SIZE];
memset(szMyString,0,STRING_SIZE * sizeof TCHAR);

Then you can easily change the string size when you decide it's going to be larger.

Tom

"JR" <JR@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:FCFCC5B7-40EF-4128-89B9-82D0A7A90F06@xxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm


.

Relevant Pages

  • Re: Working with floating point numbers.
    ... Some languages let you do this sort of thing by declaring two variables ... at the same address - e.g. a Double and an 8-byte array of Char. ... S As String * 4 ... Dim S As MyStrings ...
    (microsoft.public.access.modulesdaovba)
  • Re: wchar_t as a string parameter
    ... The bottom line is that there is no setting for this, and there is no known compiler bug that causes this to happen. ... I agree totally on my bad form of declaring my string variable wchar_t ... MyFunction(szMyString); ...
    (microsoft.public.vc.mfc)
  • Re: wchar_t as a string parameter
    ... I agree totally on my bad form of declaring my string variable wchar_t ... MyFunction(szMyString); ... Note that it is possible to debug the release build, and, as I indicated, examine the ...
    (microsoft.public.vc.mfc)
  • Re: alternative php syntax
    ... I am building an array of strings in the form of "number=", ... I literally mean to assign string values such as: ... know php is loose about declaring variables. ...
    (alt.php)
  • Re: string in an array
    ... My doubt comes when declaring a array bigger than the string it is ... you pass the pointer to free. ... Keep in mind that a "string" is not a data type; ...
    (comp.lang.c.moderated)