Question about simple C language data types.
Author
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 char dchar;
typedef signed char dschar;
typedef unsigned char duchar;
typedef const char dcchar;
typedef const signed char dcschar;
typedef const unsigned char dcuchar;
/* integer -----------------------------------------------------*/
typedef int dint;
typedef signed int dsint;
typedef unsigned int duint;
typedef const int dcint;
typedef const signed int dcsint;
typedef const unsigned int dcuint;
/* short -------------------------------------------------------*/
typedef short dint16;
typedef signed short dsint16;
typedef unsigned short duint16;
typedef const short dcint16;
typedef const signed short dcsint16;
typedef const unsigned short dcuint16;
/* long --------------------------------------------------------*/
typedef long dint32;
typedef signed long dsint32;
typedef unsigned long duint32;
typedef const long dcint32;
typedef const signed long dcsint32;
typedef const unsigned long dcuint32;
/* float -------------------------------------------------------*/
typedef float dfloat;
typedef const float dcfloat;
/* double ------------------------------------------------------*/
typedef double ddouble;
typedef const double dcdouble;
/* long double -------------------------------------------------*/
typedef long double dldouble;
typedef const long double dcldouble;
</code>
Thank you for your help,
Jeremy (grill8)
Quote:Original post by Sc4Freak
Is 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 RIZAX
Probably 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
- duint32
There 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?
Author
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)
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)
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
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).
Author
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)
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)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
