|
Boost : |
From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-02-19 09:49:01
At 07:35 PM 2/18/2001 -0600, Ed Brey wrote:
>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.
I've thought about it a bit more, and think it would be worthwhile. It
seems to me that the correct place to put such constants would be in a
<boost/cstdlib.hpp> header, since they aren't really part of the test
library.
The contents might be something like this:
// boost/cstdlib.hpp header
#ifndef BOOST_CSTDLIB_HPP
#define BOOST_CSTDLIB_HPP
#include <cstdlib>
namespace boost
{
// The intent is to propose the following for addition to namespace std
// in the C++ Standard Library, and to then deprecate EXIT_SUCCESS and
// EXIT_FAILURE. As an implementation detail, this header defines the
// new constants in terms of EXIT_SUCCESS and EXIT_FAILURE. In a new
// standard, the constants would be implementation-defined, although it
// might be worthwhile to "suggest" (which a standard is allowed to do)
// values of 0 and 1 respectively.
// Rationale for several failure constants: some environments may wish
// to distinguish between different classes of errors.
// Rationale for choice of values: programs often use values < 100 for
// their own error reporting. Values > 255 are sometimes reserved for
// system detected errors. 200/201 were suggested to minimize
conflict.
const int exit_success = EXIT_SUCCESS; // implementation-defined value
const int exit_failure = EXIT_FAILURE; // implementation-defined value
const int exit_exception_failure = 200;
const int exit_test_failure = 201;
}
#endif
Comments?
>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.
I went back and reread 18.3/8 and believe your interpretation is
correct. I'll make changes accordingly.
--Beman
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk