   Question about simple C language data types.
  Hello,I have a question about simple C language data types.  As far as aliasing the C language data types, can you think of any other types you would add besides those listed below?  Any other thoughts/advice on this matter?Thank you,Jeremy (grill8)<code>/* char--------------------------------------------------------*/typedef chardchar;typedef signed chardschar;typedef unsigned charduchar;typedef const chardcchar;typedef const signed char    dcschar;typedef const unsigned char  dcuchar;/* integer -----------------------------------------------------*/typedef intdint;typedef signed intdsint;typedef unsigned intduint;typedef const intdcint;typedef const signed intdcsint;typedef const unsigned int   dcuint;/* short -------------------------------------------------------*/typedef shortdint16;typedef signed shortdsint16;typedef unsigned shortduint16;typedef const shortdcint16;typedef const signed short   dcsint16;typedef const unsigned short dcuint16;/* long--------------------------------------------------------*/typedef longdint32;typedef signed longdsint32;typedef unsigned longduint32;typedef const longdcint32;typedef const signed long    dcsint32;typedef const unsigned long  dcuint32;/* float -------------------------------------------------------*/typedef float dfloat;typedef const floatdcfloat;/* double ------------------------------------------------------*/typedef doubleddouble;typedef const doubledcdouble;/* long double -------------------------------------------------*/typedef long doubledldouble;typedef const long double    dcldouble;</code>Thank you for your help,Jeremy (grill8)   
  Is there any particular reason why you're doing this?   ;Quote:Original post by Sc4FreakIs there any particular reason why you're doing this?Probably the same reason why every engine and 3rd party api does it....The only thing I might change is to make the alias more descriptive. So for example, if your just aliasing out an int for your L33T ENGINE, i might alias them out to something like L33T_INT - lol,cheesy, but you get the idea. Just adding a letter or two to the front seems kind of pointless.;Quote:Original post by RIZAXProbably the same reason why every engine and 3rd party api does it.Many engines do it for a few types so they can either change them later or get more concise names. Many of grill8's aliases are longer than the original types (most of the signed types) so I doubt it's done to get concise names.Except from:- dsint16- duint16- dsint32- duint32There is only one choice for the rest of the types (just use the rules: dcT = const dT, dT = dsT and if T is the name of a primitive type dsT = T and duT = unsigned T) so it doesn't seem to be for flexibility.Personally I can't really see the reason for this either.Now assuming you're really doing this for some good reason it seems odd that you miss a boolean type and all pointer types are missing (including void* and char*). Also how about size_t?   ;  RIZAX is right, there are definately reasons why it is done for just about every professional C/C++ software project ever developed.  Some of those reasons include ...1) Different host machines use different sizes for ints so if your host machine uses 32 bit ints and you port to a host machine that uses 16 bit ints there can be porting issues that you did not plan on since the sizes of ints are host machine dependent.  If you change dint to dint32 you are now safe in that case.  So, one changed line of code could potentially save a lot of time porting to a different host machine architecture.  You do not get this benefit when using a simple "int".2) A lot of people claim that it makes for a cleaner interface to projects and particularly APIs.  If your types are specific to the API you are developing you get a cleaner and clearer api to the interface you present to your client.3) Yeah, ints are signed by default but this can be changed with compiler settings.  By using data type aliasing you can tweak your compiler settings or port to other environments and only change a few lines of code.  Again, you do not get this benefit with unaliased data types.4) As a side benefit, it is much easier to type "dcuchar" than "const unsigned char" for example when developing a large engine where that type may be implemented MANY MANY times.  5) Microsoft does it all the time (DirectX), ODE does it (dReal etc.), there are simply a LOT of reasons why it is done.  I agree, boolean and size_t should definately be covered although as far as I can deduce they only require a regular and const version since they are always unsigned.  I agree again with RIZAX, a different naming convention should probably be used based on the engine or project name perhaps.  Pointer types are not necessary to name and usually aren't simply because it is only 1 char more to type the * and a * is more clear than a prefixed p.  void is always void.Anyone else have any input?Jeremy (grill8)   ;  What about long long (__int64)?   ;  This is not so much advice as just griping ;)I really hope that if you go to the effort to maintain consistent aliases that you are doing so for a good reason.  I've personally had enough of hungarian and similar notations unless there is a really good reason for it -- the good reasons are many, even if we just note the ability to quickly identify a variable's type; but the cons are many too -- putting a new engineer on a project results in wasted time with them learning different notations for different bits of code (i.e. if you have several libraries making up your game and each one uses different naming schemes and conventions, if people from different teams have to read each other's code it can be awful :'( ).But this is just gripes.  You've reassured me by explaining you know why it is a good idea -- perhaps you are making something grand :)~Shiny   ;Quote:Original post by grill8..1) Different host machines use different sizes for ints so if your host machine uses 32 bit ints and you port to a host machine that uses 16 bit ints there can be porting issues that you did not plan on since the sizes of ints are host machine dependent.  If you change dint to dint32 you are now safe in that case.  So, one changed line of code could potentially save a lot of time porting to a different host machine architecture.  You do not get this benefit when using a simple "int".This is a reason for using stdint.h, not for reinventing it.Quote:2) A lot of people claim that it makes for a cleaner interface to projects and particularly APIs.  If your types are specific to the API you are developing you get a cleaner and clearer api to the interface you present to your client.They're integers, not some API-specific concept like handles or enumerations... if your API users are confused in even the slightest way by integers in the API, your problems will require more than a few typedefs to solve.Quote:5) Microsoft does it all the time (DirectX), ODE does it (dReal etc.), there are simply a LOT of reasons why it is done.Microsoft has done many things it regrets (hungarian notation, for instance). dReal is actually a means to lose information (the particular implementation of reals) instead of specifying it (the particular size of integers).   ;  Thank you all,That is all great help.  I will definately do some more investigation to figure out a proper and suitable way to handle this.  I know my fundamental types well but could definately learn more about other types and proper aliasing.  I had no idea stdint.h even existed so thank you.Your friend, Jeremy (grill8)   