L"Hi I'm a string!"UINT, LONG, TCHAR etc. What is adviseable?
Author
Another old newbie question. I'm using C++ and DX9 in VS2008.
The Windows API and DirectX SDK use all these redefined types.. INT, UINT, BOOL, etc.
What is the benefit of using them, and is it recommended greatly? They sure do remove a lot of readability when the IDE was already colour coding the primitive types for you. I'm happy to use them, but I want to know the point first.
Second question, can someone please give me the current way to go with strings. I see TCHAR, TSTRING, WCHAR .. or things along these lines. Also an "L" function or operator. I don't actually know what it is when I see
UINT, LONG, TCHAR, etc are just typedefs (or defines) to the standard c++ types. For example if you look up UINT, you will see that it is just an unsigned int. So it doesnt matter if you use those types of the standard c++ types.
As for TCHARs and WCHARs, etc. Those are UNICODE values. UNICODE uses two bytes to store a character instead of one. This means it can support all the characters in all the languages in the world. Including Asian, Russian, and Arabian characters. By putting an L in front of your string just forces the string to be made into a UNICODE string instead of keeping it as a multi byte string...
I would suggest that you use UNICODE because you can support many character sets but if you don't really care, then just go with multi byte. UNICODE is good when you will translate your game into other languages. Thats all.
As for TCHARs and WCHARs, etc. Those are UNICODE values. UNICODE uses two bytes to store a character instead of one. This means it can support all the characters in all the languages in the world. Including Asian, Russian, and Arabian characters. By putting an L in front of your string just forces the string to be made into a UNICODE string instead of keeping it as a multi byte string...
I would suggest that you use UNICODE because you can support many character sets but if you don't really care, then just go with multi byte. UNICODE is good when you will translate your game into other languages. Thats all.
The Windows API defines its own types so that it can define definitively the size of each. In C and C++, the numeric types don't have specific ranges defined (ie. they can be freely set by the compiler). By declaring its own types, Win32 allows each compiler to include a header that correctly defines each type to be the right size on that compiler. Nowadays I doubt that any of the commonly used compilers differ from these sizes, but the system is still around.
For a nice listing of all the awesome string types you can pick from when using C++, see Promit's article on the subject. That's it. There is no more.
Once you've done amusing yourself with that, you can hear the short answer. 1) Use std::string (included in the SC++L header file "string") unless you absolutely need to use something else.
The difference between normal strings and strings prefixed with 'L' is that the latter denotes a Unicode string. The default project settings for VS 2008 is to set the project up to use Unicode (which means that the Win32 methods are going to want you to specify all strings in Unicode), but if you don't want that it's trivial to change it back.
For a nice listing of all the awesome string types you can pick from when using C++, see Promit's article on the subject. That's it. There is no more.
Once you've done amusing yourself with that, you can hear the short answer. 1) Use std::string (included in the SC++L header file "string") unless you absolutely need to use something else.
The difference between normal strings and strings prefixed with 'L' is that the latter denotes a Unicode string. The default project settings for VS 2008 is to set the project up to use Unicode (which means that the Win32 methods are going to want you to specify all strings in Unicode), but if you don't want that it's trivial to change it back.
C++ has a library called string.
#include<string>
The C++ string class has a lot of functionality that makes it easy to work with strings. Concatenation, for example, is performed with the + operator. E.g.
myConcatString = myString1 + myString2
You can always get out the character array by using the c_str() member function.
const char* myCharArray = myString.c_str()
You may need to work with other string types to deal with libraries that are older. For example, the CImage class uses something called String (I believe - note the difference in the capitals - string vs String). But you should be able to translate between a c++ string class and any other type of string.
I recommend using the c++ string class, and translating to other entities as needed.
#include<string>
The C++ string class has a lot of functionality that makes it easy to work with strings. Concatenation, for example, is performed with the + operator. E.g.
myConcatString = myString1 + myString2
You can always get out the character array by using the c_str() member function.
const char* myCharArray = myString.c_str()
You may need to work with other string types to deal with libraries that are older. For example, the CImage class uses something called String (I believe - note the difference in the capitals - string vs String). But you should be able to translate between a c++ string class and any other type of string.
I recommend using the c++ string class, and translating to other entities as needed.
Quote:Original post by RealMarkP
As for TCHARs and WCHARs, etc. Those are UNICODE values. UNICODE uses two bytes to store a character instead of one. This means it can support all the characters in all the languages in the world. Including Asian, Russian, and Arabian characters. By putting an L in front of your string just forces the string to be made into a UNICODE string instead of keeping it as a multi byte string...
That statement isn't 100% accurate. While TCHAR and WCHAR are in fact 2 byte representations of characters, Unicode is something a bit different.
There are many different unicode encoding formats, one of which is UTF-16 (which is descended from the deprecated UCS2, and whose code units (characters) are made up of either 2 bytes or something called surrogate pairs (for characters existing outside of the BMP, or basic multilingual plane). Surrogate pairs are simply 2 code units (each 2 bytes) that make up a character).
UTF8 is another popular unicode encoding. This encoding uses single byte code units, and can represent any character (including those outside the BMP) by describing characters using variable numbers of code units. UTF8 encoded strings would most likely use char rather than wchar_t buffers.
There are a lot of good wikipedia articles regarding unicode (search utf8 or utf16 in google and you should get it).
Author
Ah thanks all.
I found a wiki article that gives a clear explanation of the reasons for and differences between UTF8 and UTF16, the _T and L macros, what the headers are doing and basically what I should do.
http://en.wikibooks.org/wiki/Windows_Programming/Unicode
Basically L"" creates a Unicode string, while _T("") checks to see if Unicode is defined and creates a normal, ASCII character string if not. So I will stick with the _T macro.
As for the ints/longs/bools etc, I will stick with the primitive types there too. I doubt it will cause a problem for me and the colour coding and reduced capitalisation is much clearer.
I found a wiki article that gives a clear explanation of the reasons for and differences between UTF8 and UTF16, the _T and L macros, what the headers are doing and basically what I should do.
http://en.wikibooks.org/wiki/Windows_Programming/Unicode
Basically L"" creates a Unicode string, while _T("") checks to see if Unicode is defined and creates a normal, ASCII character string if not. So I will stick with the _T macro.
As for the ints/longs/bools etc, I will stick with the primitive types there too. I doubt it will cause a problem for me and the colour coding and reduced capitalisation is much clearer.
Quote:Original post by DefendOr just use Unicode for everything. Most multibyte Win32 API calls simply convert multibyte parameters to Unicode before calling the Unicode variant.
Basically L"" creates a Unicode string, while _T("") checks to see if Unicode is defined and creates a normal, ASCII character string if not. So I will stick with the _T macro.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
