Boost logo

Boost :

From: Ed Brey (brey_at_[hidden])
Date: 2000-12-07 10:30:15

From: "Beman Dawes" <beman_at_[hidden]>
> >1. When used as a header, it makes it more obvious that the header
> >must only be included into a single translation unit, and that the
> >code being pulled into the translation unit is of the form that is
> >traditionally not #included, but is done so in this case for
> >convenience.
> >
> >[...]
> [...]
> Perhaps have both a header (.hpp) and an implementation file (.cpp),
> the default being that the header includes the .cpp file too. But
if some
> macro is defined, then use separate compilation. Does that make any

It still doesn't give the benefit I mentioned in my point 1 above.
For exmaple, consider:

#include <vector>
#include <boost/utility.hpp>
#include <boost/test_tools_main.cpp>

void callback(MyObject* base, DWORD pObj) {
    Derived& d = static_cast<D&>(*base);
    SomeClass& o = *reinterpret_cast<SomeClass*>(pObj);

Just as the reinterpret_cast jumps out at you when dealing with legacy
interfaces, including a .cpp jumps out at you that you are not just
including a header declaring some items: you are pulling in defintions
from what could be its own translation unit. The .cpp is serves as
excellent documentation here. I know this from practical experience,
since we have a couple utilities that generated code which includes
.cpp that we include; also Microsoft's IDL compiler generates .c
files, which are commonly included. (The advantage including
generated code rather than putting it into the makefile/project is
that then the makefile contains only source modules, which helps in
automating revision control operations.)

The bottom line is that there is no need to put a wrapper in place to
avoid #including a .cpp: in this situation, #including a .cpp is a
good thing.

Boost list run by bdawes at, gregod at, cpdaniel at, john at