Exceptions and object code bloat

S

Steven T. Hatton

I'm engaged in a discussion on the Qt mailing list regarding exceptions. It
has been stated that exception handling leads to significantly larger
executable images than does 'error-code' programming. Nobody has provided
a concrete example of this, and I would like to know what the technical
issues really are. Searching the Internet only resulted in finding more
rumor and legend regarding this issue. What are the facts?
 
N

Noah Roberts

Steven said:
I'm engaged in a discussion on the Qt mailing list regarding exceptions. It
has been stated that exception handling leads to significantly larger
executable images than does 'error-code' programming. Nobody has provided
a concrete example of this, and I would like to know what the technical
issues really are. Searching the Internet only resulted in finding more
rumor and legend regarding this issue. What are the facts?

http://www.open-std.org/jtc1/sc22/wg21/docs/18015.html

The facts are, if it isn't measurable and there are no concrete
examples showing that code blote exists then it can't very well be
significant. I feel for you, but at least you're just dealing with
people on some OSS email list and not in the workplace. I had a
manager that wouldn't let us use exceptions because of this unseen and
unmeasured "bloat" and "speed costs".

Good luck convincing them...
 
?

=?ISO-8859-15?Q?Juli=E1n?= Albo

Steven said:
I'm engaged in a discussion on the Qt mailing list regarding exceptions.
It has been stated that exception handling leads to significantly larger
executable images than does 'error-code' programming. Nobody has provided
a concrete example of this, and I would like to know what the technical
issues really are. Searching the Internet only resulted in finding more
rumor and legend regarding this issue. What are the facts?

I think the only clear fact is: nobody is willing to write a large program
in two versions just to try to prove a point.

And even if somebody do it, no one will believe his results.

And even if the results were indisputable, nobody will change his
programming style because of that.

So better don't waste your time.
 
S

Steven T. Hatton

Julián Albo said:
I think the only clear fact is: nobody is willing to write a large program
in two versions just to try to prove a point.

And even if somebody do it, no one will believe his results.

And even if the results were indisputable, nobody will change his
programming style because of that.

So better don't waste your time.
I have limited, if diminishing, faith that there are some rational human
beings in the world. Since I use Qt, and the discussion is about how Qt is
designed, it is more than a matter of persuading other people to do what
makes sense for themselves. I have to live with the choices made. Since
Trolltech makes their money by satisfying the user community, an
ill-informed user community is inevitably going to want things which don't
make sense. The same applies to the C++ community as a whole.

For example, compare what is said about virtual functions in the first paper
found here:
http://www.open-std.org/jtc1/sc22/wg21/docs/18015.html
with Stan Lippman's observations found here:
http://blogs.msdn.com/slippman/archive/2004/01/27/63473.aspx

If people were only exposed to the first view, they might accept it as the
only valid approach: "If C++ is not used anywhere in a project, then the
possibility of a virtual base class 'sneaking' into the code base is
eliminated."
 
I

Ian Collins

Steven said:
I'm engaged in a discussion on the Qt mailing list regarding exceptions. It
has been stated that exception handling leads to significantly larger
executable images than does 'error-code' programming. Nobody has provided
a concrete example of this, and I would like to know what the technical
issues really are. Searching the Internet only resulted in finding more
rumor and legend regarding this issue. What are the facts?

It all depends on the compiler. Some are piss poor at generating code
with exceptions, others introduce next to no overhead.

Unfortunately, I have to use one of each at the moment...
 
?

=?iso-8859-1?q?Kirit_S=E6lensminde?=

Steven said:
I have limited, if diminishing, faith that there are some rational human
beings in the world. Since I use Qt, and the discussion is about how Qt is
designed, it is more than a matter of persuading other people to do what
makes sense for themselves. I have to live with the choices made. Since
Trolltech makes their money by satisfying the user community, an
ill-informed user community is inevitably going to want things which don't
make sense. The same applies to the C++ community as a whole.

For example, compare what is said about virtual functions in the first paper
found here:
http://www.open-std.org/jtc1/sc22/wg21/docs/18015.html
with Stan Lippman's observations found here:
http://blogs.msdn.com/slippman/archive/2004/01/27/63473.aspx

If people were only exposed to the first view, they might accept it as the
only valid approach: "If C++ is not used anywhere in a project, then the
possibility of a virtual base class 'sneaking' into the code base is
eliminated."

<rant>

OO seems to have become synonymous with inheritance and of course it
just isn't so. The STL is a brilliant execution of OO concepts. In
reality OO focuses on message passing concepts not on inheritance -
there are OO languages that don't have inheritance, but all have a
concept of separation between message and method.

With C++ we are lucky because we can use just about any message to
method delivery mechanism we want. Static binding and virtual binding
are two obvious ones, but generics is simply another way of tying a
message to a method. We can also implement our own. MFC does this in
delivering window messages to objects and my company's FOST.3 framework
uses a custom message delivery system to determine how to build and
process object edit forms in HTML at run-time.

The problem with inheritance is the problem with all taxonomies -
they're arbitrary and in the real world nearly impossible to get right.
But it seems familiar to students when they learn OO as it is seems to
reflect how people see the world (but they always neglect the special
cases).

Message passing on the other hand seems nebulous, but once understood
it makes systems much easier to see for what they really are - an
exchange of information that needs to be acted upon. Lippman's example
is one of looking at how to get the messages to invoke the right
methods - once you think about the problem in that way the use of
templates to provide this wiring becomes much easier to understand and
to see.

</rant> :)


K
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,768
Messages
2,569,574
Members
45,048
Latest member
verona

Latest Threads

Top