Joaquín Mª López Muñoz <joaquin@tid.es> writes:
Peter Dimov ha escrito:
Pavel Vozenilek wrote:
The reasons to use macros instead of RAII is convenience and performance.
Can you elaborate please. I'm slowly coming to the conclusion that any catch that can be replaced by RAII should be. Including the one in shared_count. ;-)
I think I can contribute here. Earlier versions of indexed_set did extensively use scopeguards in place of try-catch blocks. When doing the performance measures, I discovered that scopeguards were introducing a non-negligible penalty --for instance, a single-indexed indexed_set was 20% slower than its equivalent std container with scopeguards, and just 10% slower with try-catch blocks (rough figures.)
I believe that. It's hard for scopeguards to compete with try/catch in cases like: try { ... } catch(...) // cleanup in this case only ... throw; } // no cleanup In cases like: try { ... } catch(...) // cleanup ... throw; } // the same cleanup again getting RAII to be as efficient as try/catch generally depends on the optimizer. If the resources can fit into registers in the try/catch, the optimizer needs to be smart enough never to put them on the stack in the RAII case. Speaking generally, that's pretty unlikely, especially on systems that bind SEH and C++ exceptions together. I think Scott Meyers once told me that Microsoft engineers had told *him* that try/catch costs more than constructing an object with a nontrivial destructor. I didn't see how it was possible, and your measurements seem to confirm my suspicions.
See http://tinyurl.com/33e4a for current performance results.
Can't see much of use there, FWIW; the graphs don't show. I had to check the material out from the sandbox CVS. -- Dave Abrahams Boost Consulting www.boost-consulting.com