In general, should I use some sort of convention for structure names which is di
ID: 654299 • Letter: I
Question
In general, should I use some sort of convention for structure names which is distinct from other type name? I was thinking about this when my professor started talking about structures.
I had the following discussion with myself, and since I do not want to come to any unreliable conclusions. How would you answer the question(s) and which answer(s) are untrustworthy?
Q: Should I distinguish structure names and type names to make the code more clear?
A: A structure is a type, so there doesn't need to be a distinction.
RE: Q: So there is never a case when someone uses typedef int SOMETYPE to rename a built-in type to make the code more flexible?
RE: A: There is no practical reason to rename built-in types. Actually, defining int types as SOMETYPE makes the code less readable because someone reading the code will not know the built-in type used for that type.
Honestly I do not trust either answer. Looking at some of the base structure in a new Win32Project using Visual Studio, I see things like typedef short HFILE; which, I guess, makes it more clear to the programmer what the variable is used for. Perhaps that is too subjective however.
As an aside, how does one usually determine what is going on when they come across variable declarations which use types you have never seen before. Do you just rely on the IDE to take you to or display the declaration?
Explanation / Answer
In C++ structs and classes are equivalent, except that the default visibility for struct members is public, while for classes it is private. The following are equivalent:
struct X { private: int i; }
and
class X { int i; }
There is no reason to give structs a special prefix.
Also, just because something is in the Win32 API doesn't make it a good idea
Perhaps typedef short HFILE was useful for a C API, in case they later wanted to change to typedef int HFILE. It's a poor practice for C++, where you could write:
struct HFILE { short s; }
This would allow passing HFILEs around by value as efficiently as shorts, while preventing unwanted conversion between an HFILE and numeric types.