I use MMGR in my project to debug my memory management as well ;)

Every one of my cpp files (indirectly/directly) includes a file called "core.h", which contains some standard stuff (typedef unsigned int uint; etc...). So I just include MMGR inside "core.h" and everything includes it. Any standard headers get included prior to including "core.h" so that MMGR doesn't screw with the standard libraries.

Quote:Original post by instinKt
It went well, but for it to work properly the header needs to be included in a specific order which I tried to abide but it would mean making some major changes to the includes I have and possibly project wide headers that are included in every file etc etc.

If you have a project wide header that's included in every file, put the MMGR include in that header!

Quote:Original post by instinKt
So this got me thinking, is there any sort of standard or "good practice" methods to where to include your headers. Currently I include standard headers before any of my own, and in every .h and .cpp file I include what I need.

I usually have a header paired with every cpp file. The cpp file includes the header of the same name, as well as any headers that are needed by the implementation (but aren't needed by the declaration). The header contains all the includes needed by the declaration.

e.g. In (1) "bar.h" is required in the declaration, so must be included in the Foo header. In (2) "bar.h" is only required by the implementation, so is included in the Foo CPP file only.

1)include "bar.h"class Foo{  Foo();  Bar myMember;}2)class Bar;class Foo{  Foo();  Bar* myMember;}

Quote:Original post by instinKt
Eg. if the header has a class with a vector member then ill include <vector> in the header and in the .cpp also.

Whats the point of putting it in the cpp if it's already in the header?

The order I use varies from project to project. I lack discipline.

Usually it'll be:

1. standard library includes
2. stable/external library includes (e.g. boost, GUI toolkit, etc, "standard" as far as my applications are concerned)
3. my own headers

However, there is one reasonably important exception to this order.

I'll always #include "X.h" before anything else in X.cpp.

This is to make sure that nothing is missing from the interface provided by X.h i.e. all necessary #includes and forward declarations have been made in X.h.

If something is missing, we'll get a compiler error that we might not have otherwise seen if we put it further down the list.

This is important when preparing X.h as a header for a stand-alone library. You don't want someone else #including it and getting weird compiler errors.

Quick example:





Now any file that includes a.h before b.h will compile fine. Reverse the order or remove a.h entirely and the compiler will barf. If you distributed b.h as part of a library, clients should reasonably be able to expect any header to be #include-able without getting a compiler error.

Edd

What is all this about?

Quote:B_H_2317_04062007

Why not just B_H.

There might be multiple b.h files in the project. By putting on a time stamp or some other hash you reduce the chance of conflicts.

And yes such conflicts do happen. They have to me anyway. It took a while to find out why some stuff wasn't declared to the compiler.

In fact I usually prepend the library/module name too:
LIBNAME_FILENAME_HPP_TIME_DATE

It's long, but who cares when a script/editor does it for you?

Edd