Re: [boost] Preliminary Boost Test Tools Library

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),
with
> 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
sense?

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.