Sign in to follow this  

UINT, LONG, TCHAR etc. What is adviseable?

This topic is 3300 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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
L"Hi I'm a string!"
So I'm wondering what the most current advice for strings is these days. Thanks.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Defend
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.
Or just use Unicode for everything. Most multibyte Win32 API calls simply convert multibyte parameters to Unicode before calling the Unicode variant.

Share this post


Link to post
Share on other sites

This topic is 3300 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this