Re: [boost] Preliminary Boost Test Tools Library

From: Ed Brey (brey_at_[hidden])
Date: 2000-12-04 09:20:22

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
in from
> a
>  >single translation unit (or not #included at all, but rather
linked in
> from
>  >the boost library (.a, .lib, or .dll).
>
> I'll have to think about that.  Packaging the whole implementation
in the
> 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
convenience.

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.

>  >3. test_main.hpp(69): boost::test_tools_exception& -> const
>  >boost::test_tools_exception&
>
> Well, I certainly was inconsistent!  Two catches used const, the
rest
> didn't.  The rules for catching const &'s are a bit different from
> function  arguments (ISO 15.3 paragraphs 18 & 19) so const
apparently isn't
> required, but const doesn't hurt anything either so I added it to
all.  (I
> skimmed the appropriate sections of C++ Programming Language,
Special
> Edition, and More Effective C++, and neither is very clear as to
whether
> const ref or just plain ref is preferred.)

I was just going off the principle that you know you don't intend to
modify the object, so best to tell the compiler to keep an eye on you.
Of course, if I really stuck to my principles, I'd always write
  int sum(const int a, const int b) {return a + b;}
with the consts, which I often don't for trivial functions, so I
probably shouldn't talk.  OTOH, the catch is dealing with an object by
reference, rather than a copy, and it could rethrow, so constness is
more important; but then again, in this case, the catches are trivial
and not much more error prone than my sum example.  But what if they
grow during maintenence?  Anyway, enough debating with myself. :-)

> The name of the header is main.hpp, following the logic that that's
the
> name of the supplied function.  Your "test_main" might be a bit
clearer,
> but since we can't change the name of main(), I'll leave the name
alone.

Sorry, I extrapolated test_main from test_tools when writing without
thinking about it.  I didn't mean to imply I had a problem with
main.hpp.

But now that I think about it, I do have a problem with main.hpp.  My
concern is that, by the current convention, if some other boost
library wanted to implement main, it would also want to have a
main.hpp, and there would be a name clash.  A couple notes on this: If
you were planning on putting main.hpp in its own subdirectory, I have
no problem.  Also, I acknowledge that anything that would implement
main is basically a framework, just like this library is a testing
framework, and frameworks should be rare in boost; I in fact can't
think of where we would again have a situation with another library
that wants to implement main, but I don't want to exclude (or make
awkward) the possibility.

 >And then a question: In order to better support existing test apps
that
>  >return a value to indicate an error (as opposed to using the
BOOST_TEST
>  >macros or exceptions), would it be useful to have main print out
the
> value
>  >of "result"?
>
> It already does:
>
> { std::cout << "\n**** error; test_main returned: " << result << ...

Sorry, I missed that.  I was looking down below the catch blocks only.