Peter Dimov wrote:
Andrey Semashev wrote:
FILE * f = fopen( ... );
if( f == 0 ) throw ...;
scoped_guard file_closer = make_guard( fclose, f );
In this (or similar) case I might rather make a tiny wrapper around FILE* instead of guard.
Interesting... when Andrei Alexandrescu and Petru Marginean introduced ScopeGuard, this was one of their primary motivating examples, and my initial reaction was that, indeed, biting the bullet and writing a separate File class might be a better option.
Eliminating resource management as a motivation leaves me wondering what are the primary uses for scope[d]_guard that you have in mind?
First, I didn't say the resource management area is not for scope guard. I just said that in this case it is questionable weither to use scope guard or making a tiny wrapper. And agreed that in this guard use case the "arm" method would be useless. Nothing more. Second, in addition to Pavel's note, there also is a lot of use cases of scope guard class which cannot be put to resouce management or transactions category. One of them, for example, is implementing post-processing queues which may help when you have complicated interactions between different objects that causes some of these objects get to an unexpected state. You may want to have such queue to perform the postponed actions after the call-stack is unrolled. The another use case is ensuring some action will be made regardless of the result of some part of program (the resource management comes as sub-category of this use case). By the way, the "arm" method is mostly used in the latter field. PS: Why scoped_guard? The object watches for the scope end to alarm, IOW he guards the scope. So scope_guard looks more applicable.