Re: Are throwing default constructors bad style, and if so, why?
on Thu Oct 16 2008, Francis Glassborow <francis.glassborow-AT-btinternet.com> wrote:
JoshuaMaurice@gmail.com wrote:
On Oct 15, 3:48 pm, "Nevin :-] Liber" <ne...@eviloverlord.com> wrote:
The decision not to use exceptions pretty much has to be done from the
ground up, and it will result in a code base that is harder to get
correct, harder to maintain, and overall might end up slower.
I agree completely. Exception use is so pervasive in normal C++ that
it's quite difficult to isolate and squash exceptions.
However, my company is trying: No exceptions anywhere. The performance
critical sections are a like a flashback of bad C I would expect to
see 15 years ago.
I was going to attempt to persuade them that exceptions are good, but
the argument is a little harder now in light of the my somewhat-
trivial tests showing significant exception handling overhead when no
exception is thrown.
Yes but that is not the consequence of using exceptions but of using a
bad compiler. What your company is doing is writing hard to maintain
poor quality C++ because you have determined that a specific compiler
is making the presence throwing an exception expensive even if it is
never thrown.
Then it's a bad platform, because unless something has changed in the
past few years, all Windows 32-bit compilers still use a
setjmp/longjmp-like implementation of EH so they can interoperate with
"structured exception handling." It's usually not a particularly good
idea to interoperate that way, but that's the norm on 32-bit Windows.
Metrowerks, when they still existed, used to offer an option to do EH
the fast way or the interoperable way, but they're long gone now :(.
We now know that exceptions can be implemented on normal platforms
with close to zero overhead (less than the cost of using error
returns). There can be a case for writing exception free programs
(note that, no exceptions anywhere) for some limited resource (usually
embedded) platforms.
Doing that involves avoiding a great deal of library resources and
should therefore not be undertaken lightly.
As a general engineering principle (not specific to software) one
avoids tools that make the product more expensive in development,
construction and maintenance.
What your evidence should do is to produce a very strong case for your
employers to switch to other compilers that do not cause them to have
to choose between seriously degraded performance and excessively high
development and maintenance costs.
Got any suggestions? For now at least, 32-bit Windows is still an
important platform to support.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]