|
Besides that, shouldn't we be using strncpy and strncat to be safe?
|
|
|
|
|
.. shouldn't you be using wchar_t or TCHAR here? Come on, man, we don't program in an English-centric world anymore, gotta worry about those non-ASCII characters. 
Remember, even if you win the rat race, you're still a rat.
|
|
|
|
|
I prefer to stick to old style "c" types as a basic interview foundation.
Of course, when I start working with newbies, I insist on "bool" (not BOOL), TCHAR (not char), LPCTSTR (not const char*) as well as const correctness, assertions and 1,000,000,000 little bits and pieces that make the code clear and fun to read.
Navin wrote:
Come on, man, we don't program in an English-centric world anymore, gotta worry about those non-ASCII characters.
Actually, I speak french and it so happens that french, like most western countries have managed to map their character set in the 8 bit address set of ASCII. (extended ascii, if you prefer, since pure ascii is a 7 bit)
So it's not a question of English-centric world, it's a western hemisphere centric world 
|
|
|
|
|
Bamaco2 wrote:
I insist on "bool" (not BOOL), TCHAR (not char), LPCTSTR (not const char*)
bool and not BOOL, fine, but at the same time LPCTSTR instead of const TCHAR* (LPCTSTR is not a const char*, notice the "T" in LPCTSTR :P )
Well, Instead of the Win32 define thingy BOOL you use bool, I agree there, but instead of a const char* you use the Win32 define LPCSTR, hmmmm, very much not consequent I would say 
- Anders
Money talks, but all mine ever says is "Goodbye!"
ShotKeeper, my Photo Album / Organizer Application[^]My Photos[^]
|
|
|
|
|
Anders Molin wrote:
LPCTSTR is not a const char*, notice the "T" in LPCTSTR
Well, if you want to get technical...
LPCTSTR IS const, and will default to a LPCWSTR if UNICODE is defined.
LPCWSTR is a pointer to a const null-terminated string of 16-bit Unicode characters.
(both of which being null-terminated of course)
~Nitron.
ññòòïðïðB A
start
|
|
|
|
|
|
If you're going to be hard coding all the strings, there's no real reason to be using anything other than char arrays, is there? I find that the hassle in making code international typically comes from hard-coded values, rather than hard-coded types. A little time spent with the replace function of any text editor can convert code to use TCHAR or wchar_t, but there's no simple way to extract all the hard-coded strings into properties or resources files. So far as I know, at least.
|
|
|
|
|
I try to make my code independent of char size
by using the _T() macro for my constants.
This way, when unicode is defined, characters are taken as 16 bit values,
otherwise, the compiler uses 8 bit values.
Most of the output on the GUI can be covered this way.
I work a lot with microcontrollers, where most of the type I handle are not
"compiler optimal" but have a pre-defined width.
My code is full of "uint8" "int8" "uint16" "int16" "uint32" "int32" and "uint64" "int64"
then I usually #include "ProjectTypes.h" where those symbols are typedefed. I hardly
ever handle strings, except for quick and dirty debug strings. Those stay 8 bit wide.
that's for the microcontroller code and for the PC code interfacing with shared structures between PC and microcontroller.
Actually, I like to pass const CString& around as function parameters (in windows, anyway.
I never deal with CString like objects in my microcontroller code.
Instead, I might have something like this:
#ifdef _TRACE_THIGNY<br />
char temp[40];<br />
sprintf(temp,"x=%d. y=%d. z=%d", (int)x, (int)y, (int)z);<br />
SendMsgString(temp);<br />
#endif
|
|
|
|
|
That is true, the toughest part if i18n is collecting all those strings that need to be translated and putting them in text/resource files. However for any strings that don't need translation, or any other hard-coded string, _T() and TCHAR still apply, in case you want to be able to compile your app in both Unicode and ASCII.
Remember, even if you win the rat race, you're still a rat.
|
|
|
|
|
You can use non-ASCII characters in regular char strings. It's a little tricky with languages that use multi-byte charsets, since you have to worry about lead/trail bytes, but it's definitely possible.
For the most part you only really NEED Unicode when you're mixing vastly different languages within strings, like russian and chinese.
|
|
|
|
|
Bamaco2 wrote:
// What is the output of this function call ?
//
// foo("box");
//
Well actually nothing will happen. The call to foo is commented out 
|
|
|
|
|
Nothing - it's declared as void.
No-one seems to have mentioned it yet, so I would suggest using STL strings/wstrings and stringstreams/wstringstreams to avoid that sort of memory problem.
Gavin Greig
"Haw, you're no deid," girned Charon. "Get aff ma boat or ah'll report ye."
Matthew Fitt - The Hoose O Haivers: The Twelve Trauchles O Heracles.
|
|
|
|
|
I can't imagine hiring a c++ programmer at our company, a c# programmer maybe, but c++? Not unless we wanted someone to take over the "back catalog" updates.
There is much to be said in favor of modern journalism. By giving us the opinions of the uneducated, it keeps us in touch with the ignorance of the community.<br />
- Oscar Wilde<br />
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
