Does a utility like the following already exist in boost? If so, what is it called? If not, is there interest in adding it? template < typename Function > struct free_on_error { private: Function function_; bool reset_; public: free_on_error ( Function function ) : function_ ( function ), reset_ ( true ) { } ~ free_on_error ( ) { if ( reset_ ) { function_ ( ); } } void discard ( ) { reset_ = false; } }; This would be used to make certain operations exception safe. For example: A * foo ( ) { A * a = new A ( ); free_on_error < BOOST_TYPEOF ( lambda::bind ( delete _1, a ) ) > release ( lambda::bind ( delete _1, a ) ); a->DoSomethingThatMightThrow ( ); release.discard ( ); return a; } (my experience with lambda is minimal, so I'm not sure that delete _1 creates a valid lambda functor, but you get the idea) -Jason
Jason Hise wrote:
Does a utility like the following already exist in boost? If so, what is it called? If not, is there interest in adding it?
template < typename Function > struct free_on_error { private: Function function_; bool reset_;
public: free_on_error ( Function function ) : function_ ( function ), reset_ ( true ) { }
~ free_on_error ( ) { if ( reset_ ) { function_ ( ); } }
void discard ( ) { reset_ = false; } };
This would be used to make certain operations exception safe. For example:
A * foo ( ) { A * a = new A ( ); free_on_error < BOOST_TYPEOF ( lambda::bind ( delete _1, a ) ) > release ( lambda::bind ( delete _1, a ) ); a->DoSomethingThatMightThrow ( ); release.discard ( ); return a; }
It sounds like you may be looking for Petru and Andrei's ScopeGuard: http://tinyurl.com/26vzp. (BTW, has anyone noticed http://www.scopeguard.com/ ?) It uses a neat trick to avoid specifying the return type of bind or lambda expressions. A version of ScopeGuard exists as an implementation detail of multi_index. Previously, I had used a ScopeGuard in iostreams, and was planning to move it to boost/detail. Unfortunately it caused problems with borland 5.x, Metrowerks 8.3 and VC6, so I excised it. Jonathan
On Sun, 1 May 2005 15:06:22 -0600, Jonathan Turkanis wrote
It uses a neat trick to avoid specifying the return type of bind or lambda expressions. A version of ScopeGuard exists as an implementation detail of multi_index. Previously, I had used a ScopeGuard in iostreams, and was planning to move it to boost/detail. Unfortunately it caused problems with borland 5.x, Metrowerks 8.3 and VC6, so I excised it.
Yet more wreakage from legacy compilers. Hate to rediscuss this issue again, but I really think 1.33 needs to be the end of the line for these non-compliant compilers. Imagine the regression testing cycles and intellectual energy that will be saved by abondoning porting libraries to these non-compliant compilers. Jeff
Yet more wreakage from legacy compilers. Hate to rediscuss this issue again, but I really think 1.33 needs to be the end of the line for these non-compliant compilers. Imagine the regression testing cycles and intellectual energy that will be saved by abondoning porting libraries to these non-compliant compilers.
I am all for it. Support for all these ancient compilers make my life so much more difficult. Gennadiy
Hi All, Something my company does to cut down the backward compatibility burden is to provide old versions for those platforms. In other words, if 1.32 (or whatever) works, make it available for those compilers. Perhaps even make bug fixes on that branch for critical issues. That way, the rest of us can move on... ;) Just an idea, Don Jeff Garland wrote:
On Sun, 1 May 2005 15:06:22 -0600, Jonathan Turkanis wrote
It uses a neat trick to avoid specifying the return type of bind or lambda expressions. A version of ScopeGuard exists as an implementation detail of multi_index. Previously, I had used a ScopeGuard in iostreams, and was planning to move it to boost/detail. Unfortunately it caused problems with borland 5.x, Metrowerks 8.3 and VC6, so I excised it.
Yet more wreakage from legacy compilers. Hate to rediscuss this issue again, but I really think 1.33 needs to be the end of the line for these non-compliant compilers. Imagine the regression testing cycles and intellectual energy that will be saved by abondoning porting libraries to these non-compliant compilers.
participants (5)
-
Don G -
Gennadiy Rozental -
Jason Hise -
Jeff Garland -
Jonathan Turkanis