|
Hi!
I've to convert a wide char string to tolower. This the code I used.
s32 id = profileList->getSelected();
stringw strtoDelete = profileList->getListItem(profileList->getSelected());
if(!strcmp(reinterpret_cast<const char*>(tolower(strtoDelete.c_str())),reinterpret_cast<const char*>("default")))
{
profileList->removeItem(id);
}
But I got the following errors:
Error 5 error C2143: syntax error : missing ')' before '{' d:\goldminer\source\game\gamemenuprofilestate.cpp 237
Error 4 error C2661: 'strcmp' : no overloaded function takes 1 arguments d:\goldminer\source\game\gamemenuprofilestate.cpp 236
Error 3 error C2664: 'tolower' : cannot convert parameter 1 from 'const wchar_t *' to 'int' d:\goldminer\source\game\gamemenuprofilestate.cpp 236
7 IntelliSense: argument of type "const wchar_t *" is incompatible with parameter of type "int" d:\goldminer\source\game\gamemenuprofilestate.cpp 236
How to convert a wide char string to tolower?
|
|
|
|
|
|
Hi!
Is there any single function for string<wchar_t> which works like tolower?
|
|
|
|
|
C99 defines a towlower which converts a single character. There's an implementation in VC++ from at 2003 onwards. You can use that with std::transform to convert a wide string to lowercase.
Cheers,
Ash
PS: Most of the time when you're having to use reinterpret_cast to shut the compiler up there's something a bit wrong with your code. Using strcmp is usually an additional signal, especially when you're using it with C++ style strings.
PPS: Just out of interest why are you trying to compare a C++ wide string to a narrow C string? Wouldn't it be far easier to just say:
if( strToDelete == L"default" )
{
}
or am I missing something fundamental here?
|
|
|
|
|
Not only: using reinterpret_cast to convert a pointer to C-style unicode string to a pointer to C-style ANSI string simply produces crashes or wrong results. To convert from unicode to ANSI or viceversa there are specific functions!
|
|
|
|
|
Why not use _wcsicmp[^]?
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
wstring strtoDelete = ............
wstring szDefault = L"default";
if(!_tcscmp(reinterpret_cast<const TCHAR*>(_tcslwr(strtoDelete.c_str())), szDefault.c_str()))
{
....
}
Sameer();
|
|
|
|
|
|
Moak wrote: Somebody knows what it tries to do while "checking for a solution"? Is Windows sending information to Microsoft without users' consent?
Have a look at:
Does "Windows is checking for a solution..." actually do anything?.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Thanks for the info! Looks like Microsoft Windows is massively phoning home, no user information, obsolete privacy statements (via control panel)... scary.
|
|
|
|
|
What is the difference between CreateWindow and CreateWindowEx?
I know of the extra functionality provided by using the CreateWindowEx, but is their any difference in performance.
Is my program missing out on any other speed or interaction functionality by using the older CreateWindow function?
|
|
|
|
|
Calling CreateWindow will internally call CreateWindowEx .
I confirmed this using Windbg.
|
|
|
|
|
difference is,later function takes one extra parameter.
Actually, CreateWindow is a macro, expanding to CreateWindowEx with NULL(no extended style) as first parameter.
In effect you are using only one function.
|
|
|
|
|
What does this mean? Does the 64 bit machine use 32 bit arithmetic for such a project?
thanks
|
|
|
|
|
You can run 32 bit on 32 or 64 bit machine.
However 64 bit has to run on a 64 bit machine ONLY!
|
|
|
|
|
well i ran 64 bit compiled code on a 32 bit machine and it ran without crashing but gave me different results from when it ran on the 64 bit machine where it was compiled.....
|
|
|
|
|
Are you certain you targeted 64 bits when building on your 64bits machine ?
Watched code never compiles.
|
|
|
|
|
gone to google 'targeted'
be back. thanks!
|
|
|
|
|
Please start providing some clear facts about your tools, their switch settings, your app, the kind of calculations you are doing, what parts run fine, what parts don't, how the results are different from what you want; show us a code sample (with variable declaration!) and some relevant results (twice: good and bad).
i.e. stop saying "it doesn't work"
|
|
|
|
|
This does not compute! Or does it??
I compiled the same code on a 32 bit machine and also on a 64 bit machine and when I run each one the numerical output is different. There are some overlapping results but there are others missing or extra in the others, or slightly different.
How can this be?
|
|
|
|
|
ns wrote: the numerical output is different.
Which output ? What are the differences ? What is your code doing ?
|
|
|
|
|
if real numbers are involved, any change in compiler or compiler setting can influence the outcome; the difference may range from a change in one of the least significant digits, all the way up to an iterative process not converging any longer (which probably would indicate poor code, an unreliable algorithm or an ill-defined mathematical system).
OTOH it could also be just a stupid bug, say a function parameter list getting misaligned because you didn't treat parameter types as they should (remember, pointers now become 8B, so they don't fit in an int anymore).
|
|
|
|
|
thank you all!
I narrowed it down to where if I disable a certain custom function and call an alternate function, the same results are produced by both builds (64 bit and 32 bit machines)
So I am going to inspect this function and see what gives.
Appreciate the help and I will attempt to be more descriptive in my next question.
|
|
|
|
|
ns wrote: I compiled the same code on a 32 bit machine and also on a 64 bit machine
Compiled as 32 and 64 bits or using the same 32 bits exe on both machines ?
are you doing low level operation on bits ? doing shift (for multiplcation/divisions) ? are you certain all the types you are using have the same size in 32 and 64 bits (loosing precision) ?
Watched code never compiles.
|
|
|
|
|
Check for overflow.
If doing a long string of computations, break them up; you may have precedence wrong.
|
|
|
|