Jump to content


C++ ScopeGuard non-reference rationale?


  • You cannot reply to this topic
No replies to this topic

#1 Wernaeh

    Senior Member

  • Members
  • PipPipPipPip
  • 368 posts

Posted 15 January 2010 - 10:09 AM

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
Some call me mathematician, some just call me computer guy. Yet, I prefer the term professional weirdo :)





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users