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 :)
C++ ScopeGuard non-reference rationale?
No replies to this topic
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users