Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk