Re: [boost] Patch for the Function library

From: Guillaume Melquiond (gmelquio_at_[hidden])
Date: 2003-05-19 01:09:33

On Mon, 19 May 2003, Giovanni Bajo wrote:

> Guillaume Melquiond <gmelquio_at_[hidden]> wrote:
>
> > According to the paragraph 3.7.3.1-3 of the Standard, an 'operator new'
> > can return a null pointer or throw an exception to report a failed
> > allocation; but it isn't allowed to adopt the two behaviors.
>
> Really? I don't see this specified in that very paragraph. To me, it looks
> like it's saying that:
>
> - an allocation function which is declared as throw() must return a null
> pointer in case of failure.
> - an allocation function which is not declared as throw() can call
> new_handler, or, alternatively, throw a std::bad_alloc (or exception derived
> from it).

My interpretation of the standard was: an allocation function that returns
a null pointer must have an empty exception clause and so is not allowed
to throw any kind of exception.

> >    void* operator new(std::size_t, stateless_integer_add*)
> >    {
> >      throw std::runtime_error("Cannot allocate a stateless_integer_add");
> > -    return 0; // suppress warnings
> > +    return (void*)1; // suppress warnings
> >    }
>
> Since this allocation function is not declared throw(), it should throw a
> std::bad_alloc(), not a runtime_error(). The return value does not make
> sense here because of the throw: that statement is never reached. If there

What kind of argument is that? :-)
Yes the code is unreachable; but it's not enough of a reason to write bad
code each time it's unreachable.

In fact, I would have suggested to remove this return statement if there
was not this comment:

    return 0; // suppress warnings

The return statement is already here to suppress warnings with some
compilers. But it also adds a warning with GCC. It's the reason why I
suggested a patch that does a minimal change of the code: the return
statement is not suppressed, but the return value is changed.

> are warnings about the return value, compilers could be improved to at least
> shut them off in such situation, or can be simply turned off in any way
> (return 0 is ok).
>
> What is the warning you get with GCC?

GCC complains that the allocator returns a null pointer and so should have
an empty throw() clause.

> Instead, I think this is ill-formed because it's throwing an exception which
> is not derived from std::bad_alloc(). What is this code supposed to do? If
> the goal is disabling new() for stateless_integer_add, why simply you don't
> add a protected operator new as member of the class?

Because it is no more a trivial patch; because it clearly changes the
meaning of the code. And as a consequence I prefer to let this kind of
change to the maintener of the file.

Regards,

Guillaume