From: Giovanni Bajo (giovannibajo_at_[hidden])
Date: 2003-05-18 18:46:09
Guillaume Melquiond <gmelquio_at_[hidden]> wrote:
> According to the paragraph 18.104.22.168-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
> 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
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?
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk