|
Boost : |
From: Reid Sweatman (reids_at_[hidden])
Date: 1999-07-09 17:01:27
> Also, the sentence "For functions which can throw
> std::bad_alloc, empty
> throw specifiers are not supplied." is confusing. Of course empty
> throw specifiers woundn't be supplied. The issue is why isn't
> throw(std::bad_alloc) specified. I believe all the functions
> that throw
> bad_alloc also contain a delete of the user's type. According to the
> discussion in this thread, this is a good reason for not
> having a throw
> specification.
Let me ask for a clarification here. When you say bad_alloc throws delete
the user's type, you mean the type that failed of allocation, don't you?
Not the containing object that called that type's new operator, right? I
guess you mean that there's then no reason to specify throw(bad_alloc) on
the outer object's definition, because its
DTOR won't explode because of the failed allocation. But the next level of
object would probably want to know the allocation failed, right? So
wouldn't you still want the decoration? I strongly suspect I'm missing some
key issues in this entire discussion, for which I apologize.
------------------------------------------------------------------------
eGroups.com home: http://www.egroups.com/group/boost
http://www.egroups.com - Simplifying group communications
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk