Re: operator new not forced to throw std::bad_alloc?
On 13 Mai, 19:57, numerical.simulat...@web.de wrote:
During some debug session of an MFC application (VS2005) I found out
that std::allocator<double>::allocate calls operator new which throws
a
CMemoryException.
I expected operator new to throw std::bad_alloc, so that exception
went
uncaught. This is odd.
void* __cdecl operator new(size_t nSize)
{
...
// That's platform specific code here:
if (_afxNewHandler == NULL || (*_afxNewHandler)(nSize) == 0)
}
Q: Did I misunderstand Stroustrup?
I don't know. What did he say to you? ;-)
Q: Is an STL allowed to throw things which do not inherit from
std::exception?
Q: No standard under my pillow: What's the wording about what operator
new may throw?
Both the current valid standard N14882:2003 as well as the
recent draft N2588, require a std::bad_alloc, [lib.new.delete.single]/
3:
"Required behavior: Return a non-null pointer to suitably aligned
storage (3.7.3), or else throw a bad_alloc exception. This
requirement
is binding on a replacement version of this function."
On the other hand, [basic.stc.dynamic.allocation]/3 says:
"[..] If an allocation function declared with an empty exception-
specification (15.4), throw(), fails to allocate storage, it shall
return a null pointer. Any other allocation function that fails to
allocate storage shall only indicate failure by throwing an
exception of class std::bad_alloc (18.4.2.1) or a class derived
from std::bad_alloc."
The recent draft has refined the last part to say:
"[..] by throwing an exception of a type that would match a
handler (15.3) of type std::bad_alloc (18.5.2.1)"
So, if CMemoryException corresponds (as an alias) or derives
publicly from std::bad_alloc, this would be fine. Alas, this
is not the case, because the inheritance chain is:
CMemoryException <- CSimpleException <- CException [<- CObject]
(The last one exists only under specific settings)
So, if we ignore a special compiler magic for the moment
(which might exist, so you must test this!), this
implementation probably does not match the specification
of the standard.
Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]