Is C faster than C++

[P.J. Plauger]

Re: Is C faster than C++

"Dave Rahardja" <ask@me.com> wrote in message
news:tp7tj1ldqc pbercr2qa7m36gu qv66h4sf6@4ax.c om...
[color=blue]
> On Sat, 1 Oct 2005 06:55:03 -0400, "P.J. Plauger" <pjp@dinkumware .com>
> wrote:
>[color=green]
>>So if you declare *every* function either as extern "C" or with a
>>throw() qualifier, you can match the lower overhead of native C
>>code, at least with *some* compilers. But the least lapse in this
>>style -- such as writing C++ the way all the books tell you to --
>>and you get the bloat of exception handling whether or not you
>>use it.[/color]
>[color=green]
>>So if you don't use the library *designed* for use with Standard
>>C++, the way all the books tell you, you can match the lower overhead
>>of native C style, at least with *some* compilers.
>>
>>Now please review your words and consider whether there is anything
>>*inherently * inefficient with the language itself. Asymptotic behavior
>>doesn't mean much in the world of real programming.[/color]
>
> It's obvious that we're not going to convince each other in this matter.
> It
> appears that our views of what constitutes a fair comparison differ
> considerably.
>
> My experience with C++ in both the desktop and embedded worlds is that the
> overhead for _equivalent_ behavior is zero. Each overhead in C++ comes
> with an
> additional feature, which C does not afford you. C++ defaults to a larger
> set
> of features that you can "turn off", while C starts out with a basic set
> to
> which you must add. In my mind, a fair comparison involves turning off
> features in your C++ program to match the behavior of the C program that
> you're comparing it to. Anything else is not a fair comparison in my mind,
> but
> you obviously think that that's too much to ask in the "real world".[/color]

In the usual sense, yes. What's advertised for C++ is: if you don't
use it, you don't pay for it. What you admit above, and several others
have demonstrated, is that you have to "use" quite a bit of stuff from
exception handling to *not* pay for it. Specifically, you have to make
liberal use of throw specifications. (Or you can declare all of your
functions extern "C", don't use any C++ functions from the library,
and hence "turn off" cross-module type checking in the bargain.)

And BTW, not all implementations of Standard C++ eliminate all space
and time overheads for exceptions even if you do the above. It's
well over a decade now since compilers started shipping with exceptions,
and that's still the state of the art.

So yes, I do consider my comparisons fair, and yes, I think that's
too much to ask in the real world. Having said that, I observe that
some C++ compilers have a switch that disables exception handling
unilaterally. All you need then is a library that can tolerate
such antics. We happen to provide one called EC++. It's part of our
standard library package, alongside the Standard C++ library. But
the same people who argue that C++ has zero overheads usually foam
at the mouth at the mention of subsetting...
[color=blue]
> Maybe I can convince others, if not you, that what you consider
> "asymptotic
> behavior" is par for the course in many application domains, including
> mine
> (embedded code), although for most applications, the overhead associated
> with
> the "traditiona l" coding style is more than made up for by the features
> that
> C++ brings to the table.[/color]

Please note that I made exactly this point in my first posting.
My major point was that it's a mark of zealotry to deny that
overheads do exist.
[color=blue]
> However, C-equivalent efficiency is attainable by
> correct specification.[/color]

For some implementations . If you know what "correct" means.
And if you do your best to write C code masquerading as C++.
Please also note that this style is fragile. All you need is
one maintainer who's not clued in to the correct style to
add one innocent call (possibly copied from a reputable text
book) and suddenly bloat up an executable.
[color=blue]
> I stand by my statements and observations (and take advantage of them
> daily),
> although you probably disagree with them.[/color]

Actually, I don't.
[color=blue]
> I do concede that the two areas you highlight--default exception handling
> behavior and iostreams--contribute to significant data and code bloat in
> C++
> programs and must be aggressively managed for efficiency-critical code.[/color]

Yep. And it's the "aggressive ly managed" part that puts the lie
to the opinion that prompted my first posting:

: "Mabden" <mabden@sbc_glo bal.net> wrote in message
: news:q5b_e.640$ Y_5.493@newssvr 11.news.prodigy .com...
: ...
: Anything you believe about "hidden costs" are similar to your beliefs
: about UFOs and gods. Ie: non-existent.

The hidden costs are real if you have to work hard to drag
them out of hiding before you can exorcise them.

P.J. Plauger
Dinkumware, Ltd.

http://www.dinkumware.com

[Dave Rahardja]

Re: Is C faster than C++

On Sat, 1 Oct 2005 14:57:34 -0400, "P.J. Plauger" <pjp@dinkumware .com> wrote:

[color=blue][color=green]
>> I do concede that the two areas you highlight--default exception handling
>> behavior and iostreams--contribute to significant data and code bloat in
>> C++
>> programs and must be aggressively managed for efficiency-critical code.[/color]
>
>Yep. And it's the "aggressive ly managed" part that puts the lie
>to the opinion that prompted my first posting:
>
>: "Mabden" <mabden@sbc_glo bal.net> wrote in message
>: news:q5b_e.640$ Y_5.493@newssvr 11.news.prodigy .com...
>: ...
>: Anything you believe about "hidden costs" are similar to your beliefs
>: about UFOs and gods. Ie: non-existent.
>
>The hidden costs are real if you have to work hard to drag
>them out of hiding before you can exorcise them.[/color]

[color=blue][color=green]
>> It's obvious that we're not going to convince each other in this matter.[/color][/color]

-dr

[P.J. Plauger]

Re: Is C faster than C++

"Dave Rahardja" <ask@me.com> wrote in message
news:mhkuj1p7c4 sv0ebv9h0dlq2ji v9cuelmsr@4ax.c om...
[color=blue]
> On Sat, 1 Oct 2005 14:57:34 -0400, "P.J. Plauger" <pjp@dinkumware .com>
> wrote:
>
>[color=green][color=darkred]
>>> I do concede that the two areas you highlight--default exception
>>> handling
>>> behavior and iostreams--contribute to significant data and code bloat in
>>> C++
>>> programs and must be aggressively managed for efficiency-critical code.[/color]
>>
>>Yep. And it's the "aggressive ly managed" part that puts the lie
>>to the opinion that prompted my first posting:
>>
>>: "Mabden" <mabden@sbc_glo bal.net> wrote in message
>>: news:q5b_e.640$ Y_5.493@newssvr 11.news.prodigy .com...
>>: ...
>>: Anything you believe about "hidden costs" are similar to your beliefs
>>: about UFOs and gods. Ie: non-existent.
>>
>>The hidden costs are real if you have to work hard to drag
>>them out of hiding before you can exorcise them.[/color]
>
>[color=green][color=darkred]
>>> It's obvious that we're not going to convince each other in this matter.[/color][/color][/color]

There exists at least one implementation where, with
"aggressive ly managed" code, you can reduce exception
overhead to zero.

Therefore, the "hidden costs" of using C++ instead of C
are nonexistent.

If you're convinced that this is a logically tight
argument, then you're right, I'll never convince
you otherwise. Please look up the definition of
zealotry.

P.J. Plauger
Dinkumware, Ltd.

http://www.dinkumware.com

[Dave Rahardja]

Re: Is C faster than C++

On Sun, 2 Oct 2005 09:42:56 -0400, "P.J. Plauger" <pjp@dinkumware .com> wrote:
[color=blue][color=green][color=darkred]
>>>> It's obvious that we're not going to convince each other in this matter.[/color][/color]
>
>There exists at least one implementation where, with
>"aggressivel y managed" code, you can reduce exception
>overhead to zero.
>
>Therefore, the "hidden costs" of using C++ instead of C
>are nonexistent.
>
>If you're convinced that this is a logically tight
>argument, then you're right, I'll never convince
>you otherwise. Please look up the definition of
>zealotry.[/color]

PJ, please stop putting words in my mouth, get off your high horse about
zealotry, and listen for a change. Instead of that asinine sequence of
arguments that you wrote, what I said was:

- C++ has features "turned on" by default that _do_ add inefficiencies in the
code. These inefficiencies afford features such as exception handling that do
not exist in C without manual addition.

- These features can be turned off by conscientiously managing your code (or
even managing your compiler switches), thus allowing your C++ code to match
the efficiency of C.

Notice that nowhere in my statements have I said that C++ overhead is
"nonexisten t". I said that C++ code is not /necessarily/ less efficient than
C.

We are always dependent on compiler implementation for the proper generation
of our code. Just because _not all_ compilers support a standard construct
doesn't mean that the construct is worthless, or not a good practice. As far
as I can tell, the MSVC and g++ compilers (as well as my embedded compiler,
Diab) support the suppression of exception handling via the throw()
specification. That seems to be a large enough base of compiler installations
to me. How large of a base would you like to see before a compiler's
implementation becomes more than a curiosity in your eyes?

Having said all that, in most applications the overhead caused by leaving the
C++ features "on" is not significant. Where they do count, such as in the
real-time embedded world that I live in, aggressive management of code is par
for the course, not just for C++ overhead reasons, but for other efficiency
reasons such as type conversions, word sizes, and hardware considerations.

Look: I understand your arguments and agree with most of them--and it seems
that the converse is true as well. Our differences lie in the extent to which
we are willing to advocate code management to (re)gain efficiencies in C++. If
that makes you want to use a dismissive label like "zealot" on me, then I at
least claim to be a _practical_ zealot, because I practice just that sort of
"zealotry" in efficiency-sensitive portions of my code every day, with
positive results. Your mileage may vary.

-dr

[P.J. Plauger]

Re: Is C faster than C++

"Dave Rahardja" <ask@me.com> wrote in message
news:1vrvj1tq3o u7aa7td9g11153d 37ci0ce90@4ax.c om...
[color=blue]
> On Sun, 2 Oct 2005 09:42:56 -0400, "P.J. Plauger" <pjp@dinkumware .com>
> wrote:
>[color=green][color=darkred]
>>>>> It's obvious that we're not going to convince each other in this
>>>>> matter.[/color]
>>
>>There exists at least one implementation where, with
>>"aggressive ly managed" code, you can reduce exception
>>overhead to zero.
>>
>>Therefore, the "hidden costs" of using C++ instead of C
>>are nonexistent.
>>
>>If you're convinced that this is a logically tight
>>argument, then you're right, I'll never convince
>>you otherwise. Please look up the definition of
>>zealotry.[/color]
>
> PJ, please stop putting words in my mouth, get off your high horse about
> zealotry, and listen for a change. Instead of that asinine sequence of
> arguments that you wrote, what I said was:
>
> - C++ has features "turned on" by default that _do_ add inefficiencies in
> the
> code. These inefficiencies afford features such as exception handling that
> do
> not exist in C without manual addition.
>
> - These features can be turned off by conscientiously managing your code
> (or
> even managing your compiler switches), thus allowing your C++ code to
> match
> the efficiency of C.[/color]

And that's where I part company with your quibble. There's
nothing in the C++ Standard that requires the kind of
efficiencies you claim, and in fact not all compilers
provide them. There's an important missing qualifier here.
[color=blue]
> Notice that nowhere in my statements have I said that C++ overhead is
> "nonexisten t".[/color]

But that indeed was what was asserted at the beginning of
this thread, and defended in various ways by you and others.
Your first post emphasized the phrase "exactly zero" three
times, while carefully decorating it with qualifiers.
There are important *disguised* qualifiers there.
[color=blue]
> I said that C++ code is not /necessarily/ less efficient
> than
> C.[/color]

And I've agreed that, if you work at it and if you have a
suitable compiler, you can achieve that goal for some
class of programs.
[color=blue]
> We are always dependent on compiler implementation for the proper
> generation
> of our code. Just because _not all_ compilers support a standard construct
> doesn't mean that the construct is worthless, or not a good practice.[/color]

And I didn't say that. It's not a worthless practice; it can
be "good" if carefully enforced.
[color=blue]
> As
> far
> as I can tell, the MSVC and g++ compilers (as well as my embedded
> compiler,
> Diab) support the suppression of exception handling via the throw()
> specification. That seems to be a large enough base of compiler
> installations
> to me. How large of a base would you like to see before a compiler's
> implementation becomes more than a curiosity in your eyes?[/color]

My experiments with gcc are not as unequivocally positive as
yours. Nor is it true of all the embedded compilers I've
encountered. And I've never dubbed the "throw()" practice a
mere curiosity. I observed instead that:

a) It violates the principle that those who no nothing about
a feature (exceptions in this case) don't pay for it.

b) It's a fragile programming technique to require widespread
decoration of function declarations.

c) Even then, it's not universally guaranteed to eliminate
*all* space and time overheads with all compilers.

Those are important, practical, qualifiers.
[color=blue]
> Having said all that, in most applications the overhead caused by leaving
> the
> C++ features "on" is not significant.[/color]

And I pointed that out in my first posting.
[color=blue]
> Where they do count, such as in the
> real-time embedded world that I live in, aggressive management of code is
> par
> for the course, not just for C++ overhead reasons, but for other
> efficiency
> reasons such as type conversions, word sizes, and hardware considerations.[/color]

Well, there's aggressive and there's aggressive, in my book.
Doing the obvious to save time and space is par for the
course. Doing magic by rote is fragile.
[color=blue]
> Look: I understand your arguments and agree with most of them--and it
> seems
> that the converse is true as well. Our differences lie in the extent to
> which
> we are willing to advocate code management to (re)gain efficiencies in
> C++. If
> that makes you want to use a dismissive label like "zealot" on me, then I
> at
> least claim to be a _practical_ zealot, because I practice just that sort
> of
> "zealotry" in efficiency-sensitive portions of my code every day, with
> positive results. Your mileage may vary.[/color]

My charge of zealotry is to the OP, who proclaimed that such
overheads are nonexistent. But I have almost as much problem
with apologists who seem to say, "Well, he's not completely
crazy *all* the time." (This brouhaha reminds me of the
elderly lady who calls the cops, complaining that a man
across the street is behaving indecently before his window.
The cop looks and sees nothing. "Stand on the bed!" she
insists.)

The fundamental issue is whether programming in C++ yields
programs that are larger and slower than comparable programs
written in C. In my extensive experience, the simple answer
is yes. The most prudent course for a project manager is to
assume 5 to 15 per cent overheads, and take for granted that
the benefits of C++ will justify the extra costs. I went
through a similar period with C a few decades ago, selling
it against assembly language. I agree the overheads can be
managed, often significantly reduced; and it's worth teaching
people how to do so. But pretending that the problem doesn't
exist at all does not help our credibility with a rightly
critical audience of potential new users.

P.J. Plauger
Dinkumware, Ltd.

http://www.dinkumware.com

[Dave Rahardja]

Re: Is C faster than C++

On Sun, 2 Oct 2005 13:47:10 -0400, "P.J. Plauger" <pjp@dinkumware .com> wrote:
[color=blue]
>The fundamental issue is whether programming in C++ yields
>programs that are larger and slower than comparable programs
>written in C. In my extensive experience, the simple answer
>is yes. The most prudent course for a project manager is to
>assume 5 to 15 per cent overheads, and take for granted that
>the benefits of C++ will justify the extra costs. I went
>through a similar period with C a few decades ago, selling
>it against assembly language. I agree the overheads can be
>managed, often significantly reduced; and it's worth teaching
>people how to do so. But pretending that the problem doesn't
>exist at all does not help our credibility with a rightly
>critical audience of potential new users.[/color]

Now this I can agree with. Let's leave it at that, shall we?

-dr

[Branimir Maksimovic]

Re: Is C faster than C++

Dave Rahardja wrote:[color=blue]
> On Fri, 30 Sep 2005 17:49:09 +0200, "Branimir Maksimovic" <bmaxa@eunet.yu >
> wrote:
>[color=green][color=darkred]
> >>> If
> >>> exception
> >>> handling is not required, we can properly declare non-throwing functions
> >>> with
> >>> the throw() specification, or resort to compiler switches. I also imagine
> >>> that
> >>> a C++ compiler can assume that C functions declared extern "C" do not
> >>> throw.
> >>>
> >>
> >> throw() wouldn't help.
> >> To quote part of 15.5.1:
> >> "An implementation is not permitted to finish stack unwinding prematurely
> >> based on a determination that the unwind process will eventually cause
> >> a call to terminate()."[/color][/color]
>
> [snip]
>[color=green]
> >I've just investigated further. Exception specification makes run time
> >overhead to function
> >only if function throws or calls function that does not have throw()
> >specificatio n.[/color]
>
> This has also been my experience. The overhead of non-throwing functions is
> exactly ZERO, both in run time code and in data space.
>[/color]
........[color=blue]
> With that quick exercise it is easy to see that exception handling overhead is
> exactly _zero_ with MSVC++ .NET when functions are properly declared throw().
> Furthermore, MSVC is smart enough to figure out that extern "C" functions do
> not throw.
>
>
> My experience with the embedded compiler that I use daily has been the same:
> the exception handling overhead for properly-declared code is not only
> trivial, it is _zero_.
>
> However, I will admit again that the decision to assume that functions with no
> throw clause can "throw anything" instead of "throw nothing" makes it very
> difficult for compilers to automatically elide the generation of exception
> handling infrastructure. Declaring functions throw() when it really doesn't
> throw anything is good practice whenever resources are at a premium.
>
>[/color]

Yes, throw() specification seems to be the best practice, because
it completely eliminates exception code and data both on linux and
windows with gcc, too. Without them even C compiled as C++ has overhead
on linux. One thing more , for gcc extern "C" functions have to be
declared throw() as well. On windows && gcc,every function that have
destructor(s) (and there are almost no C++ programs that doesn't have
auto objects in functions)execu ted has big run time overhead
(entry/exit exception code added).
So, mister P.J.Plauger is generaly right, we have to put lot's of
throw()
specifications in order to avoid either code bloat(linux) or run time
penalty
and code bloat(windows), even with same compiler on different
platforms.

Greetings, Bane.

[Greg]

Re: Is C faster than C++

Branimir Maksimovic wrote:[color=blue]
> Dave Rahardja wrote:[color=green]
> > On Fri, 30 Sep 2005 17:49:09 +0200, "Branimir Maksimovic" <bmaxa@eunet.yu >
> > wrote:
> >[color=darkred]
> > >>> If
> > >>> exception
> > >>> handling is not required, we can properly declare non-throwing functions
> > >>> with
> > >>> the throw() specification, or resort to compiler switches. I also imagine
> > >>> that
> > >>> a C++ compiler can assume that C functions declared extern "C" do not
> > >>> throw.
> > >>>
> > >>
> > >> throw() wouldn't help.
> > >> To quote part of 15.5.1:
> > >> "An implementation is not permitted to finish stack unwinding prematurely
> > >> based on a determination that the unwind process will eventually cause
> > >> a call to terminate()."[/color]
> >
> > [snip]
> >[color=darkred]
> > >I've just investigated further. Exception specification makes run time
> > >overhead to function
> > >only if function throws or calls function that does not have throw()
> > >specificatio n.[/color]
> >
> > This has also been my experience. The overhead of non-throwing functions is
> > exactly ZERO, both in run time code and in data space.
> >[/color]
> .......[color=green]
> > With that quick exercise it is easy to see that exception handling overhead is
> > exactly _zero_ with MSVC++ .NET when functions are properly declared throw().
> > Furthermore, MSVC is smart enough to figure out that extern "C" functions do
> > not throw.
> >
> >
> > My experience with the embedded compiler that I use daily has been the same:
> > the exception handling overhead for properly-declared code is not only
> > trivial, it is _zero_.
> >
> > However, I will admit again that the decision to assume that functions with no
> > throw clause can "throw anything" instead of "throw nothing" makes it very
> > difficult for compilers to automatically elide the generation of exception
> > handling infrastructure. Declaring functions throw() when it really doesn't
> > throw anything is good practice whenever resources are at a premium.
> >
> >[/color]
>
> Yes, throw() specification seems to be the best practice, because
> it completely eliminates exception code and data both on linux and
> windows with gcc, too. Without them even C compiled as C++ has overhead
> on linux. One thing more , for gcc extern "C" functions have to be
> declared throw() as well. On windows && gcc,every function that have
> destructor(s) (and there are almost no C++ programs that doesn't have
> auto objects in functions)execu ted has big run time overhead
> (entry/exit exception code added).
> So, mister P.J.Plauger is generaly right, we have to put lot's of
> throw()
> specifications in order to avoid either code bloat(linux) or run time
> penalty
> and code bloat(windows), even with same compiler on different
> platforms.
>
> Greetings, Bane.[/color]

There are some compilers that have "zero runtime overhead" exception
handling; but the tradeoff they make is in size. Exception support can
add significantly to the size of compiled code.

I don't see how a throw() specification would be likely to eliminate
any exception processing overhead. After all, a throw() specification
is no guarantee that the function will not throw an exception. It only
guarantees that a caller will never be able to catch an exception
thrown during a call to that routine [because the program will have
stopped running]. And in order to provide this guarantee the compiler
must add exception processing logic to a function with a throw()
specification just to make sure that no thrown exceptions are allowed
to escape.

In short, to eliminate exception overhead really requires going outside
the syntax defined by the language and to use use a pragma or an other
compiler-dependent way to disable the feature.

Greg

[Branimir Maksimovic]

Re: Is C faster than C++

Greg wrote:[color=blue]
> Branimir Maksimovic wrote:[color=green]
> > Dave Rahardja wrote:[color=darkred]
> > > On Fri, 30 Sep 2005 17:49:09 +0200, "Branimir Maksimovic" <bmaxa@eunet.yu >
> > > wrote:
> > >
> > > >>> If
> > > >>> exception
> > > >>> handling is not required, we can properly declare non-throwing functions
> > > >>> with
> > > >>> the throw() specification, or resort to compiler switches. I also imagine
> > > >>> that
> > > >>> a C++ compiler can assume that C functions declared extern "C" do not
> > > >>> throw.
> > > >>>
> > > >>
> > > >> throw() wouldn't help.
> > > >> To quote part of 15.5.1:
> > > >> "An implementation is not permitted to finish stack unwinding prematurely
> > > >> based on a determination that the unwind process will eventually cause
> > > >> a call to terminate()."
> > >
> > > [snip]
> > >
> > > >I've just investigated further. Exception specification makes run time
> > > >overhead to function
> > > >only if function throws or calls function that does not have throw()
> > > >specificatio n.
> > >
> > > This has also been my experience. The overhead of non-throwing functions is
> > > exactly ZERO, both in run time code and in data space.
> > >[/color]
> > .......[color=darkred]
> > > With that quick exercise it is easy to see that exception handling overhead is
> > > exactly _zero_ with MSVC++ .NET when functions are properly declared throw().
> > > Furthermore, MSVC is smart enough to figure out that extern "C" functions do
> > > not throw.
> > >
> > >
> > > My experience with the embedded compiler that I use daily has been the same:
> > > the exception handling overhead for properly-declared code is not only
> > > trivial, it is _zero_.
> > >
> > > However, I will admit again that the decision to assume that functions with no
> > > throw clause can "throw anything" instead of "throw nothing" makes it very
> > > difficult for compilers to automatically elide the generation of exception
> > > handling infrastructure. Declaring functions throw() when it really doesn't
> > > throw anything is good practice whenever resources are at a premium.
> > >
> > >[/color]
> >
> > Yes, throw() specification seems to be the best practice, because
> > it completely eliminates exception code and data both on linux and
> > windows with gcc, too. Without them even C compiled as C++ has overhead
> > on linux. One thing more , for gcc extern "C" functions have to be
> > declared throw() as well. On windows && gcc,every function that have
> > destructor(s) (and there are almost no C++ programs that doesn't have
> > auto objects in functions)execu ted has big run time overhead
> > (entry/exit exception code added).
> > So, mister P.J.Plauger is generaly right, we have to put lot's of
> > throw()
> > specifications in order to avoid either code bloat(linux) or run time
> > penalty
> > and code bloat(windows), even with same compiler on different
> > platforms.
> >
> > Greetings, Bane.[/color]
>
> There are some compilers that have "zero runtime overhead" exception
> handling; but the tradeoff they make is in size. Exception support can
> add significantly to the size of compiled code.
>
> I don't see how a throw() specification would be likely to eliminate
> any exception processing overhead. After all, a throw() specification
> is no guarantee that the function will not throw an exception. It only
> guarantees that a caller will never be able to catch an exception
> thrown during a call to that routine [because the program will have
> stopped running].[/color]
Well if you look at my previous post that is what I thought about
throw().
But, it simply elliminates any trace of exception handling code and
data in gcc object files. I guess compiler knows that
eh code is not needed if every single function used in compilation unit
(declared or defined) has throw() specification.

And in order to provide this guarantee the compiler[color=blue]
> must add exception processing logic to a function with a throw()
> specification just to make sure that no thrown exceptions are allowed
> to escape.[/color]

I looked at generated assembly and this is not the case.
If function has throw() specification (with or without auto objects
with destructors)and does not calls something that
can throw (it is good practice that destructors have throw()
anyway) no eh code or data is generated for that function.
It seems that that is the case with VC too (according to Dave).
So, finally this thread gaved me a good knowledge about exception
specs, and when they should be used - in functions that actually
don't throw exceptions :)
I was rather carelless about specs, but now, I know that compilers
can optimise unnedded eh code and data out when they see them.
They won't heart anyway.

Greetings, Bane.

[Dave Rahardja]

Re: Is C faster than C++

On 3 Oct 2005 15:03:55 -0700, "Greg" <greghe@pacbell .net> wrote:
[color=blue]
>There are some compilers that have "zero runtime overhead" exception
>handling; but the tradeoff they make is in size. Exception support can
>add significantly to the size of compiled code.[/color]

Yes, I've seen at least one implementation that uses a static table of "throw
ranges" or "call sites" to deduce the objects that need to be destructed if an
exception were to be thrown at that point. Such implementations have literally
zero execution overhead (using no additional stack space and no additional
instructions in the stream). When exceptions are thrown control is passed to a
global exception handler, along with the current exception-thrower's address
and stack pointer and does the unwinding based on the tables.

The cost is obviously the substantial tables that need to be linked in
(although in most OS implementations this can be done so that the tables do
not get paged into physical memory until an exception actually occurs).
[color=blue]
>I don't see how a throw() specification would be likely to eliminate
>any exception processing overhead. After all, a throw() specification
>is no guarantee that the function will not throw an exception.[/color]

Actually it does (see 15.4.11), or at least /should/. However, the throw()
specification does not become part of the function type, so a function
declared throw() in one module looks identical to the linker as the function
defined without the throw-specification.

MSVC at least does give a compile-time warning if you declare a function
throw() and then proceed to throw an exception in it.

I guess the secret is to use the same declaration (i.e. header file) for the
declaration of a function everywhere in the program.
[color=blue]
>In short, to eliminate exception overhead really requires going outside
>the syntax defined by the language and to use use a pragma or an other
>compiler-dependent way to disable the feature.[/color]

To completely eradicate exception handling overhead once and for all you
probably need to use a compiler switch. I wonder what this does to library
functions that are specified to throw exceptions though, such as operator
new().

-dr