Jump to content
  • Advertisement
Sign in to follow this  
roos

Defining variables in headers

This topic is 4766 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

Hi, There's this rule of thumb that I've been using for several years now, and the funny thing is, I can't even remember why I use this rule any more, and that scares me because for all I know, maybe this rule isnt even valid. :) So, here's my rule... I never define a variable in a header... So for example if I have a constant I want, then I have to do this: (In blah.h:) extern const int width; (In blah.cpp:) const int width = 50; Now the thing is I'm working on a project, and there everyone simply does this: (In blah.h:) const int width = 50; So my question is, is there any downside to simply defining variables in the .h file, or have I been making trouble for myself all this time? :) Thanks, roos

Share this post


Link to post
Share on other sites
Advertisement
Well if you ask me, your way is less likely to come up with conflicts between modules, so is therefore the better way.

Think about it like this; You include a header in 2 different C files (So the include guards wont kick in), and that variable will be 'compiled in' to both.

Then, when you get to the linking step, the linker will discover a conflict between the 2 files and wont link.

With your method, it's always going to connect them up at the linking stage, so you wont get the conflict. :)

God I'm tired, hope that made sense.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Global variables are evil in some peoples eyes. My friend was docked marks for each and every global he had. They make your .exe file larger from my understanding. The way you do it seems to be the way most professional programmers do it too. If you're working on a project with more then 2 programmers you really should have a programmers development guide that lays out formatting, indents, etc in it and include this.

Hope this helped in someway.

Share this post


Link to post
Share on other sites
Thanks guys. I made a quick test of this.. Actually it looks like what you said is right PlayfulPuppy, although if it's a CONST variable, then no conflict occurs

roos

Share this post


Link to post
Share on other sites
For a const, may as well put it in the header.

Anything that's not const does not belong there, because there needs to be actual storage to hold it then, and you'll have trouble if the header is used in multiple translation units - include guards can only protect you within the same translation unit, and then you get 'multiply defined symbols' (several object files containing what is supposed to be the same variable with the same name, and the linker doesn't know which to use).

Share this post


Link to post
Share on other sites
Some of it depends on where and how you define your variables in the header. For example, we will do something like this.

[src]
class Box
{
public:
static const int kMaxWidgets = 7;
Box()
~Box()

Widget get(int index)

private:
Widget mWidgets[kMaxWidgets];
};
[/src]

in this case, the static const int acts the same as a #define, but is more Standard C++ compliant.

Share this post


Link to post
Share on other sites
The right tags are [-code-] and [-/code-] (without the -).

You're defining the variable in a class and you have to make sure, that you are not redefining your class, so it's basically the same as with the global variables.

If you want to make a variable global for only one compilation unit, you can put it in an anonymous namespace, for example:


namespace
{
int counter = 0;
}


If you put this into a header file every compilation unit that includes this header has its own counter global variable.


Share this post


Link to post
Share on other sites
lukeyes: Your src should be source, then it will work correctly. Or the code tags like ext said.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!