Newbie: Declaring in CPP or in h files?
-
Hello, I'm novice with VC++6 and I would like to know wich differences are between declaring a class, a function or a variable in a header or in a cpp file... If I have to use a global var, where should I put it? Thank you! :-O
It's all about scoping. If you make a declaration in a CPP file, then that declaration is only available in that file. So, for a global, it's not good. If you declare in a header file, then you can include it multiple times (ie, once for each cpp file in your project) If you want a global variable, you should declare it like this in one of your header files:
extern typename varname;
// eg
extern int nTurtles;You then need the implementation of that variable. Put this in 1, and only one, cpp file:
typename varname;
// eg
int nTurtles;It would be ok technically to declare a class in a cpp file, along with it's implementation. However, this is bad programming practise, and i'd personally avoid it. Jon Sorry to dissapoint you all with my lack of a witty or poignant signature.
-
Hello, I'm novice with VC++6 and I would like to know wich differences are between declaring a class, a function or a variable in a header or in a cpp file... If I have to use a global var, where should I put it? Thank you! :-O
Jon's reply is spot on IMHO but maybe a bit of coding philosophy is in order. The distinction between .h and .cpp files is really all about information hiding. That's what he means by scope really. A .h file can be included pretty well anywhere so you can give access to the code it contains to pretty well anything you want just by using a #include. In other words what you really want in the .h file is the interface to whatever code it supports. A fundamental principle of software engineering is to minimise the interface. That means put as little as possible into the .h file and hide the rest in the .cpp file. To a large extent, users of your code only have to worry about what is in the .h file in this case. You're hiding the implementation details from the user (in this case I mean other programmers or you yourself in six months time when you've forgotten how your super duper widget class works). People can get really stuffy and prissy about using globals and functions that aren't class members. I find globals extremely useful sometimes. For example I nearly always have an instance of a CLog class that logs diagnostic data to disk from pretty well everywhere in everything I write. Making this a global means I don't have to worry about passing it around everywhere as a parameter. If you limit yourself to a few cases like this then I don't have a problem with globals. Non-member functions are often recommended by the gurus. Stroustrup uses them a lot in 'The C++ Programming Language', I think (my copy is at work so can't check it was him), as helper functions. His argument is solid (if a bit too advanced for details here) but it seems to go against the grain of conventional wisdom that says make your functions members of the class on which they operate. A good set of rules of thumb is only use globals where they really make life easier and implement them like Jon suggests, put your functions in a class as members of that class, and put your class interface in the .h file and it's implementation in the .cpp file. Like all rules these are made to be broken but knowing when you can break them safely only comes with pain and experience. The point really is that you need to strive towards coding correctly but if you make a few wrong decisions along the way nobody's going to shoot you. There aren't many coders out there who can honestly look at code they wrote six months ago and not find something they would do differently now. The good thing about C++ is you can write really really bad code and it will