Best practices in Visual Studio C++

Question

Hi all

Visual Studio seems to want to put class contructor code and event handling code in the .h file. I have only been involved in small 1 man projects and was wondering what the general industry standard was.

For Visual C++ Application projects what code would one put in the .h file? I am used to the mode classical C++ way of declaring your class in the .h file and coding in the .cpp file. Does this still apply to Visual Studio applications?

I have a strong C background which would explain my preference for this. The VSC++ compiler doesn't seem to mind.

In short: What is one supposed to put in which type of file?

TIA Ends

Answer 1

For Visual C++ Application projects what code would one put in the .h file? I am used to the mode classical C++ way of declaring your class in the .h file and coding in the .cpp file. Does this still apply to Visual Studio applications?

Short: Yes Long: Depends on the person or language. In c++ the header is for declaring and cpp for the coding. For C# you have one file (or if you use interfaces, 2)

Answer 2

If you're using MFC and you're talking about the generated code, it's best to leave it alone.

If you're trying to do 'normal' C++ development, put as little as you can get away with in the header, as it means client code doesn't depend on too many implementation details. What you can get away with depends a little on use of templates, and how much indirection your performance budget can support.

Answer 3

There is no widely accepted industry standard. By putting (short) function definitions in the header, you give the compiler a better chance to inline the code. The benefit is that it can make the code run faster (keep those functions short, though). However, this comes at the cost of exposing more code to the clients who include that header, making you (or your colleagues) recompile more files when you change the implementation.

You also have to take into account the cost of going against your tools. Since VC++'s wizards insist on putting the functions in the headers, you have to move them everytime if you disagree.

It's really project-specific, I would say.

Answer 4

This might seem minor, but just remember: headers are #included in several places. (And headers including headers complicates things further.) Any time you change a header, a lot of files are gonna be compiled again. Keeping as little of frequently changing code in the header reduces recompilation of dependant files.

Another thing: an uncluttered header file gives you a quick overview of what a class/form has to offer.