Wide String Constants | developer.brewmp.com Wide String Constants | developer.brewmp.com

Developer

Wide String Constants

Forums:

I'm running into a difference between Visual C++ and the ADS Compiler with wide character constants and I was wondering if anyone had any suggestions.

In Visual C++ (and any compiler where you can use the standard libraries), you have the wonderful _T() macro for making character constants wide strings. Use is:

TCHAR *sTmp = _T("Test");

We don't have access to the _T macro in BREW so I grabbed it from the MS headers:

#define __T(x) L ## x

#define _T(x) (AECHAR *)__T(x)
#define _TEXT(x) (AECHAR *)__T(x)

Which essentially just uses the L modifier to make the string constant wide.

Visual C++ creates 2-byte characters with this which is compatible with the BREW AECHAR type (and works great on the emulator), but the ADS compiler creates 4-byte characters. Needless to say, this doesn't work for BREW (second AECHAR is 0).

Obviously I can use STRTOWSTR() or stick my constants into a resource .. but that adds extra work and memory for constants. Consider the simple case of adding simple formatting to a collection of strings you grab from resources or user input:

AECHAR sTmp[128];

WSPRINTF(sTmp, 128 * sizeof(AECHAR), _T("%s : %s - %d"), sString1, sString2, iSomeInt);

becomes a much larger pain in the butt because you either have to create a temp AECHAR string and put the format string into it with STRTOWSTR(), grab the format string out of a resource, or get into the ugly {'%','s',' ', etc} nonsense.

So ... what I want to know is if anyone is aware of a way to coax the ADS compiler into making 2-byte wide string literals, or has come up with some other solution to this problem.

Tom

What version of the compiler are you using? L"..." is defined in the C++ standard to create a string of wchar_t. In ADS 1.1, wchar_t is "an implicit typedef for int", in ADS 1.2 its "an implicit typedef for unsigned short" and RVCT 2.0 wchar_t is a real type.
-Aaron

What version of the compiler are you using? L"..." is defined in the C++ standard to create a string of wchar_t. In ADS 1.1, wchar_t is "an implicit typedef for int", in ADS 1.2 its "an implicit typedef for unsigned short" and RVCT 2.0 wchar_t is a real type.
-Aaron

Does anyone know of an alternate way to create a unicode string that maybe circumvents the L-directive to avoid these issues?
Or does anyone know a feasible way to override the "implicit typedef" for wchar_t?

Does anyone know of an alternate way to create a unicode string that maybe circumvents the L-directive to avoid these issues?
Or does anyone know a feasible way to override the "implicit typedef" for wchar_t?

I'm using 1.1.
Thanks for the info .. I'll look into using 1.2. For now, my makefiles aren't compatible with 1.2.
I take it you don't know of anyway to get 1.1 to work as an unsigned short?
Tom

I'm using 1.1.
Thanks for the info .. I'll look into using 1.2. For now, my makefiles aren't compatible with 1.2.
I take it you don't know of anyway to get 1.1 to work as an unsigned short?
Tom

In a couple of days I will have a AECHAR specialization of a String class ready. If someone is interested to test an early version please let me know.
Radu

In a couple of days I will have a AECHAR specialization of a String class ready. If someone is interested to test an early version please let me know.
Radu

I would like to take a look at your implementation. I might not have time to actually test it, but I'm happy to review the interfaces and walk through the code. I tried getting the ARM (rogue wave) implementation of std::basic_string to work, but it has two problems. One, it requires static data to handle the empty strings. In addition, it can't handle run-time out-of-memory conditions without exceptions, blocking assert(), or exit() and therefore you can't be assured its going to work at run time on low memory in the BREW environment. That means that things like + and += are dangerous/fragile operations, unless you have something like mystring::checkerror() after every operation. So I will review it with those things in mind.
-Aaron

I would like to take a look at your implementation. I might not have time to actually test it, but I'm happy to review the interfaces and walk through the code. I tried getting the ARM (rogue wave) implementation of std::basic_string to work, but it has two problems. One, it requires static data to handle the empty strings. In addition, it can't handle run-time out-of-memory conditions without exceptions, blocking assert(), or exit() and therefore you can't be assured its going to work at run time on low memory in the BREW environment. That means that things like + and += are dangerous/fragile operations, unless you have something like mystring::checkerror() after every operation. So I will review it with those things in mind.
-Aaron

and what is the unified workaround for L"wide string" to be considered as two bytes in VC as well as ARM ?

and what is the unified workaround for L"wide string" to be considered as two bytes in VC as well as ARM ?

Have you tried "S" for short (assuming "L" is for long)?
I use Metrowerks Codewarrior and gcc rather than VC++ and ADS so I can't try this myself.
Ed

Have you tried "S" for short (assuming "L" is for long)?
I use Metrowerks Codewarrior and gcc rather than VC++ and ADS so I can't try this myself.
Ed

Ezavada,
L## actually stands for "Literal." Hence your assumption is incorrect and doesn't work. ;)

Ezavada,
L## actually stands for "Literal." Hence your assumption is incorrect and doesn't work. ;)

Using L"" syntax works fine in x86 gcc with the emulator, but as soon as I compile for the device (GNUDE gcc 3.3.1), it only shows the first character of the string. Anyone have any ideas why that would be? Has anyone successfully gotten the L"" constants to work in the ARM gcc?
-Al

Using L"" syntax works fine in x86 gcc with the emulator, but as soon as I compile for the device (GNUDE gcc 3.3.1), it only shows the first character of the string. Anyone have any ideas why that would be? Has anyone successfully gotten the L"" constants to work in the ARM gcc?
-Al

-fshort-wchar

-fshort-wchar

rabidcow wrote:-fshort-wchar
Awesome, worked like a charm. Thank you.

rabidcow wrote:-fshort-wchar
Awesome, worked like a charm. Thank you.

alwold,
are you saying that "-fshort-wchar" gives you the ability to now display strings on a uione phone?
I set "-fshort-wchar" and it still doesn't work

alwold,
are you saying that "-fshort-wchar" gives you the ability to now display strings on a uione phone?
I set "-fshort-wchar" and it still doesn't work

joeramley2007 wrote:alwold,
are you saying that "-fshort-wchar" gives you the ability to now display strings on a uione phone?
I set "-fshort-wchar" and it still doesn't work
Yeah, you have to do that and use syntax like this:
AECHAR *str = (AECHAR *)L"my string";
Are you getting an error?

joeramley2007 wrote:alwold,
are you saying that "-fshort-wchar" gives you the ability to now display strings on a uione phone?
I set "-fshort-wchar" and it still doesn't work
Yeah, you have to do that and use syntax like this:
AECHAR *str = (AECHAR *)L"my string";
Are you getting an error?

No error. It compiles and runs on the phone but the strings don't display

No error. It compiles and runs on the phone but the strings don't display

strings display on the simulator but not the uione phone

strings display on the simulator but not the uione phone