Re: [boost] Review: Test library

From: Ed Brey (brey_at_[hidden])
Date: 2001-02-18 20:35:42

From: "Beman Dawes" <bdawes_at_[hidden]>
>  >  If trying to be like EXIT_FAILURE, what is the difference?
>
> Environments may want to distinguish between different classes of
> errors.  Also, lots of programs distinguish between types of errors by
> returning codes which are typically are integers < 100. OTOH, I had a
> comment from Jens that some environments use integers >=256 for other
> purposes.  Thus he suggested using 200 as the Boost code.  I thought we
> might want to distinguish between exceptions and other errors, so I was
> going to use 201 or 199 for the other value.

Sounds good, although please document the rationale, as others will find it
as undeducable as I did.  I like the idea in your subsequent post of
providing non-macro exit_failure and exit_success and then modelling the
test-library variants off of those.

>  >3. Function_object be checked against EXIT_SUCCESS instead of zero to
>  >determine success, unless there is a good reason to do otherwise?  A
>  >rationale should be documented.
>
> I'll change it to EXIT_SUCCESS.

Actually, after looking more closely at 18.3/8 in the Standard, it seems
pretty clear that the check should be like this (pseudo-code):
    if (return_value == 0 || return_value == exit_success)
        std::cout << "Successful termination\n";
    else if (return_value == exit_failure)
        std::cout << "Unsuccessful termination\n";
    else
        std::cout << "Termination with non-standard return value\n";

One could make a pragmatic argument for lumping the last case above in with
the unsuccessful termination case, but I don't see any reason not to do the
check for 0 or EXIT_SUCCESS by the book.

>  >2. Talks about "std::EXIT_SUCCESS" and "std::EXIT_FAILURE".  These names
>  >are macros and are not in any namespace.  Also, it is implied that
>  > EXIT_SUCCESS is always 0 and that EXIT_FAILURE is always non-zero.
>  > The Standard doesn't seem to guarantee such; rather it says that
success
>  > is returned if and only if exit is passed either 0 or EXIT_SUCCESS
>  > (but EXIT_SUCCESS is not constrained to be either the same or
>  > different than 0). 18.3/8
>
> I'll work on making it clearer.  Both the C and C++ standards seem to try
> to leave a lot of wiggle room in their wording.  That makes it hard to
> write docs users can rely on across all implementations.

Maybe just quote the four relevent sentences from the Standard or include
pseudo-code like what I wrote above.

>  >4. I agree with a previous post that calls for giving several of the
> global
>  >variables a home.
>
> I'm planning to do that, but also note that variables in the unnamed
> namespace are not globals and it is a stylistic rather than code safety
> issue.

That's not always the case if you allow the shortcut of including the cpp
file.  There may be a name clash with a variable of the same name in a
user's unnamed namespace in the same translation unit.  Consider this
generic example:

// library_file.cpp:
namespace {int foo;}

// user_code.cpp:
#include <boost/library_file.cpp>
namespace {int foo;}
void f() {foo = 1;}

It would seem that unnamed namespaces and the #include <implementation>
convenience feature are incompatible.