Jump to content
  • Advertisement
too_many_stars

Typedefing in a central *.h file

Recommended Posts

Hello Everyone,

I am sure we have all seen things like

const glm::vec2 & v

or,

std::unique_ptr< SomeObject > object;

I was wondering if it's a good idea to perhaps make a typedef.h file and sprinkle it through out the project so I can save some typing.

#ifndef TYPEDEF_H
#define TYPEDEF_H

typedef const glm::vec2 c_vec2;
typedef std::unique_ptr< SomeObject > ptr_obj;
typedef ...

#endif

 

Maybe like this...

I am using typedefs, but in classes only. However, I would like to access those typedefs globally without having to call SomeClass::typedef.

Is there anything wrong with this global approach? Are there some issues that can come crop up down the line which I am not considering?

Please let me know,

Thanks again,

Mike

 

Share this post


Link to post
Share on other sites
Advertisement

No problem if you ask me, I do the same with uint (unsigned int 32), my IO folders etc.
It's actually not more then 15 lines of code, so not getting out of hand.

I use the forced include option in Visual Studio to make sure it's always there.

Share this post


Link to post
Share on other sites

I would do that for very general typedefs used anywhere or so in the code, which don't refer to types defined by you, and which aren't going to change much, but not for ALL typedefs you are going to define in the project. That would be unpractical:

- Editing a single line would trigger a complete recompilation of almost all source files. If your project starts growing, you are gonna feel this.

- The user would need to parse the enum file each time to find out if some specific typedef exists, rather than finding all right next to what he is using.

I would keep typedefs related to a specific class in the same file where that class is defined. You don't necessarily need to define them in class scope, do that when it improves readability and don't do that when it hinders readability. E.g. your typedef std::unique_ptr<SomeObject> would probably be better off in SomeObject.hpp.

In some cases, e.g. with template classes, which might have several associated typedefs, I like having an extra *Fwd.hpp (e.g. SomeObjectFwd.hpp) file to group them without needing to include the actual header if all I need is the type declaration.

 

Also consider employing "using" rather than typedefs, since it is more flexible. :)

 

Cheers!

Edit: removed some post duplication. :)

Edited by GenusPongo

Share this post


Link to post
Share on other sites

It is fairly common to have a header file that includes declarations, typedefs, and other common elements, but due to problems with it sometimes there are strict coding policies against it.

When done well, anyone can use the forward-declares if they're only using pointers and handles, but if they want to use anything inside them they'll need to include the proper header that includes the implementation details. In the standard libraries an example is <iosfwd> which is much faster to process than the complete io streams.

Sometimes, however, those declaration-only files pull in all the implementation details in addition to the forward declarations and typedefs.  When that happens typically compile times skyrocket, and code gets messy since developers stop paying attention to where functionality actually lives within the project.  

 

As long as you keep it limited ONLY to typedefs of the classes and forward declarations of functions, they're speedy and convenient.  When developers start opting for convenience of pulling in definitions it quickly becomes nightmarish.  Avoid that temptation.

Share this post


Link to post
Share on other sites

In addition to what others have said, if you're going to do this, put your typedefs in a namespace. 

Actually, in general, put everything in a header file in a namespace.

Share this post


Link to post
Share on other sites
3 minutes ago, ChaosEngine said:

In addition to what others have said, if you're going to do this, put your typedefs in a namespace. 

Actually, in general, put everything in a header file in a namespace.

Can you tell me what the purpose is of putting header file contents in a namespace please? I only ask because I have never heard of this before.

The problem with the C++ books I have read (introductory to intermediate) is that often times they don't cover many of the aspects I find here on gamedev.net.

Thanks so much for all the replies!

Mike

Share this post


Link to post
Share on other sites
5 hours ago, too_many_stars said:

Can you tell me what the purpose is of putting header file contents in a namespace please? I only ask because I have never heard of this before

Sure, let's take the example you posted. You have some kind of vector type called vec2, typedef'd as c_vec2.

Because you use this type pretty much everywhere it goes in your typdefs.h file that is included everywhere. So far so good.

A while later you want to add something to the game and you see a neat bit of code/library that will do exactly what you want, and being a good programmer, you decide to go with the already written, tested and used library.

Except it has it's own vec2 type and it also has a "c_vec2" typedef, and they're also in the global namespace (ugh, bad library developer... go stand in the corner and think about what you've done!). Now, you have a namespace clash.

"ahhhh what are the chances of this happening?!"

Low, but non-zero. 

The point is that the kind of widely used, general purpose typedefs you're talking about here are especially likely to use common names that could potentially clash. 

One more point:

11 hours ago, too_many_stars said:

sprinkle it through out the project so I can save some typing.

Don't do this. Saving typing is never a good reason to do anything (especially with IDEs, autocompletion, etc). You create typedefs to reduce errors, and increase readability. Saving typing is (sometimes) a side effect of that. 

Edited by ChaosEngine

Share this post


Link to post
Share on other sites

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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!