1

I realize why it is (usually) best to catch exceptions by reference versus by pointer or by value, and I know that the compiler is able to make some optimizations, in general, if the programmer uses const variables versus non-const variables. This Stack Overflow question sheds some light on that subject.

But what that question does not mention is if there are any possible performance optimizations that could be used by catching exceptions by const reference versus just simply by reference, e.g. using

try
{
    ...
}
catch (const std::exception& e)
{
    ...
}

versus just

try
{
    ...
}
catch (std::exception& e)
{
    ...
}

I know that there are some things you can do if you catch the exception by non-const reference, such as modify it and rethrow it, or pass it to a function that takes in a non-const reference as an argument. I also understand that using const variables where appropriate generally makes your code more readable. But are there any possible optimizations that the compiler could perform that would make using const references to exceptions inherently "better" or faster? Or would code generally function exactly the same if I caught all of my exceptions by non-const reference?

Community
  • 1
  • 1
villapx
  • 1,743
  • 1
  • 15
  • 31
  • 1
    I looked at assembly produced by apple clang 7 and by gcc 5 (with optimisation O3) and I does not see any difference between const ref and non-const ref assembly. So, i guess there are no difference in optimisations for gcc and apple clang. – Vasiliy Soshnikov Mar 28 '16 at 20:06
  • @Vasiliy Cool. I'd be interested to know if anyone has happened to experience anything different (doubtful, but possible)...if the "duplicate" flag gets removed, it'd be cool if you could post that as an answer. – villapx Mar 28 '16 at 20:11
  • I can but I'm not sure about classic clang, vss, icc. – Vasiliy Soshnikov Mar 28 '16 at 20:13
  • 1
    P.S. I did re-post my comment in 'Why catch an exception as reference-to-const?' – Vasiliy Soshnikov Mar 28 '16 at 20:14
  • Also, slightly besides your question, but: in general you shouldn't need to be optimizing the exception path, as catching an exception probably means that your code has bigger issues to fix than micro-optimization in the `catch`-handler (such as preventing the exception in the first place). – CompuChip Mar 28 '16 at 20:29
  • @CompuChip Some would disagree there, as I've certainly heard of programmers using exceptions as part of their normal control flow. It likely makes a program less readable to use exceptions in that way, and most people would agree with you (myself included, I'd say), but there are some that don't. – villapx Mar 28 '16 at 20:40
  • 1
    @villapx that is why I placed the comment as a side remark. In general I tend to make this side-note for such performance/optimization questions, because people who read the question later may think that such premature optimization is useful when it is not, even when the question asker is aware of this and asking the question for a good and/or purely theoretical reason. – CompuChip Mar 28 '16 at 20:49

0 Answers0