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
example):
On 15 June 2017 at 01:28, Gavin Lambert via Boost
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 /listinfo.cgi/boost