C++ ScopeGuard non-reference rationale?

B7568a7d781a2ebebe3fa176215ae667
0
Wernaeh 101 Jan 15, 2010 at 10:09

Hello out there :)

Recently, I’ve been trying to understand (not only use) the popular ScopeGuard object suggested by Alexandrescu (see the original article or the current code in loki)

The general internal working is rather clear to me.

However, I’m missing the rationale behind the internal layout. In particular, why do the ScopeGuard objects internally store constant copies of their parameters, and not constant references ?

The copy behaviour may lead to problems when passing in allocating objects, such as std::string, since the ScopeGuard constructor then may throw, and this in turn keeps the cleanup action from executing.

The original implementation provides a layered solution for references, where a macro is used to create a specialized reference holder instance. Thus, all problematic parameters need to be tagged explicitly.

The only caveat I could see with directly using references were that the referenced objects could be modified by consecutive operations, and thus also produce flaws in the cleanup code.

Anybody have some more reasonable explanation ?

Thank you for your time :)
Cheers,
- Wernaeh

0 Replies

Please log in or register to post a reply.

No replies have been made yet.