Subject: Re: [boost] Noexcept
From: Richard Hodges (hodges.r_at_[hidden])
Date: 2017-06-15 06:49:42
>> Given that RAII is so fundamental to exception safety, it's surprising
that there isn't a vocabulary execute-lambda-inside-destructor type (eg.
"guard") in the STL, to replace cleanup/try-finally style code.
AFAIAA, this was the main reason for the introduction of
std::uncaught_exceptions() in c++17. It facilitates the writing of scoped
transactional program in a standards-defined manner. The previous
std::uncaught_exception() (note the singular) in c++11 wasn't sufficient
and turned out to be a white elephant.
So expect to see code with scoped commit/rollback semantics become common
soon after the release of c++17
people do it in c++11 but it requires messiness (boost's ScopedExit, for
On 15 June 2017 at 01:28, Gavin Lambert via Boost <boost_at_[hidden]>
> On 15/06/2017 07:52, Richard Hodges wrote:
>> If developers do not understand RAII, then an afternoon of training can
>> solve that.
>> RAII is the foundation of correct c++. It is the fundamental guarantee of
>> deterministic object state. A program without RAII is not worthy of
>> consideration. The author may as well have used C.
>> Perhaps there is an argument that says that RAII adds overhead to a
>> programâs footprint. If things are that tight, fair enough.
> Given that RAII is so fundamental to exception safety, it's surprising
> that there isn't a vocabulary execute-lambda-inside-destructor type (eg.
> "guard") in the STL, to replace cleanup/try-finally style code.
> Granted, it's simple to write one yourself, but that seems like a poor
> rationalisation to omit it, especially once lambdas became standard.
> I suspect that the lack of such a type is probably a significant reason
> exception-unsafe code ends up surviving -- it's more effort to write RAII
> wrappers for code that you're not really expecting to encounter exceptions
> in, even though you should.
> Unsubscribe & other changes: http://lists.boost.org/mailman