From: Beman Dawes (beman_at_[hidden])
Date: 2000-12-06 20:10:59
At 08:20 AM 12/4/2000 -0600, Ed Brey wrote:
>From: "Beman Dawes" <beman_at_[hidden]>
>> >> I also would rename test_main.hpp to
>> >test_main.cpp, to make it obvious that it should only be included
>> >single translation unit (or not #included at all, but rather
>> >the boost library (.a, .lib, or .dll).
>> I'll have to think about that. Packaging the whole implementation
>> header has some advantages.
>Agreed. I didn't mean to imply the option of #including a
>implementation should be removed. My point, to be more explicit, is
>that having the file end in .cpp provides two advantages:
>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
>2. It makes it easier to provide a prebuilt test harness library or
>object file, to be pulled into the client test program just by
>linking. I'm looking ahead here to when we have a build system in
>place and it is common for a user to build a static or dynamic library
>for boost right after download, or maybe download prebuilt libraries.
>Whether the test code code could go into the general boost library or
>whether it would need its own depends on whether the linker knows to
>perfer a client program's main over the library's in the case of
>linking non-test programs.
OK, now I see what you are getting at. Yes, it would be nice if it could
be used either way.
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?
> ... discussion of catching exceptions as const or not
I've changed them all to const. That doesn't hurt, and at the very least
it eliminates future questions.
> ... discussion of a better name for boost/main.hpp
I've renamed it boost/test_tools_main.hpp for now.
Thanks for the comments, Ed. I'm going to bring the Boost Test Tools
forward for formal review right after the holidays. I've had some private
comments that it would be better to get going with something basic than to
wait for perfection.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk