Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c++ > #13641

Re: Oozing poison

From Ian Collins <ian-news@hotmail.com>
Newsgroups comp.lang.c++
Subject Re: Oozing poison
Date 2012-01-29 12:22 +1300
Message-ID <9ojea4F8j0U16@mid.individual.net> (permalink)
References (7 earlier) <3EEUq.107196$487.32649@news.usenetserver.com> <9ogpsvF8j0U6@mid.individual.net> <qGKUq.152389$624.85025@news.usenetserver.com> <9ohe2qF8j0U9@mid.individual.net> <0Y_Uq.11149$Jp3.8515@news.usenetserver.com>

Show all headers | View raw


On 01/29/12 11:49 AM, Scott Lurndal wrote:
> Ian Collins<ian-news@hotmail.com>  writes:
>> On 01/28/12 05:18 PM, Scott Lurndal wrote:
>
>>> However, in this case (modeling a physical device), the best determination
>>> of how to present the failure  can be made as close to the cause of the
>>> exception as possible.   I would think that for most applications that
>>> can actually recover from an error (as opposed to just catching std::exception
>>> at the top level, printing a message, and exiting), keeping the recovery action
>>> as close to the code that actually failed makes recovery much simpler.
>>
>> It may well be, but the catch and the throw my still be several calls
>> away.  Using nested small functions is much cleaner with exceptions than
>> with return codes.  In your example you return the state in the object
>> passed.  An exception based design may well pass the state in an
>> application specific exception.
>
> Which  will have additional  overhead to allocate, construct,
> destroy and deallocate the application class derived from std::exception, nicht wahr?

Only in the exceptional circumstances where one is thrown.  As I said, 
the state has to be returned somewhere.

> I think you would find that "small nested functions" is exactly what is
> used, and in this case, the object passed doesn't necessary _return_ the state
> passed so much as provide a channel for returning the state to the final
> receipient.
>
> Now in the core processor simulation code sigsetjmp/siglongjmp are used to reset
> the simulated processor to the start of the instruction processing loop when
> an exception occurs executing an instruction (an address error, invalid instruction,
> etc).   These could possibly be converted to exceptions, but I'm quite sure that
> the performance would be worse and the RAS characteristics of the application
> wouldn't change appreciably.

By using exceptions, you are able to utilise the full power of the 
language, such as RAII which out of band jumps preclude.

One point I have been trying to make is bolting exceptions onto an 
existing design is seldom a good idea.  Neither is having to take them 
out, which was a situation I once found myself in!  Error handling is a 
fundamental part of a system's design and mixing paradigms invariably 
ends in tears.

> I remember reading Tom Cargill's article on exceptions back when they were
> introduced to the language - I think many of his points still apply - exceptions
> are not a universal panacea and careful analysis of all codepaths need be done
> to prevent memory leaks or access to deallocated data when exceptions are being
> thrown.

This is true and the language provides us with the tools to achieve 
this. Tools which cannot be used with out of band jumps!

>    The same caveats, of course, apply to setjmp/longjmp as well, but I
> don't need to allocate an exception object (just set one of 10 bits in a member
> field of the current 'this' when the longjmp is issued; the jmp_buf also a member
> of the current object).

The cost of constructing an exception object are far outweighed by the 
cost of throwing it *in the exceptional case*.

>>>> The catch is also the reason for all the extra code, constructing and
>>>> destructing a temporary std::exception object.  The actual exception
>>>> handling part of the code is this bit:
>>>
>>> Yet creating and destroying a temporary std::exception object also counts in
>>> terms of both extra cycles and code footprint.   Both of which impact
>>> performance (generally negatively).
>>
>> Only if the exceptional condition occurs.  The normal path of execution
>> will not be impacted (and will be cleaner and faster than the error
>> checking case).
>
> I haven't seen this in practice, but then my sole exposure to C++ code
> has been in the Operating Systems/Microkernel/Hypervisor area none of which
> used exceptions (most of which predated exceptions :-), aside from one
> application at a major internet certification authority, which also predated
> exceptions.

That's where our experiences diverge, I've been comparing the 
performance of exceptions on various platforms for many years and I've 
found exceptions are generally faster (always on the Unix and Linux 
platforms I use).  From my perspective, the exceptions vs error returns 
argument was settled long ago.

> Let me be clear, I never actually took an exception in the test I described above;
> the sole difference was changing the
>
>     buf = malloc(XXX); if (buf == NULL) { YYY}
>
> test to
>
>     try {buf = new uint8[XXX];} catch (std::exception&  e) { YYY }
>
> (and of course, the corresponding 'free()'<->  'delete []' changes).

You have introduced two variables, exceptions and new.  Try eliminating 
both.

-- 
Ian Collins

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Oozing poison AD <isquat@gmail.com> - 2012-01-10 04:35 -0800
  Re: Oozing poison Leigh Johnston <leigh@i42.co.uk> - 2012-01-10 15:19 +0000
    Re: Oozing poison AD <isquat@gmail.com> - 2012-01-11 00:43 -0800
      Re: Oozing poison "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2012-01-11 10:01 +0100
        Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-11 22:09 +1300
          Re: Oozing poison AD <isquat@gmail.com> - 2012-01-11 01:42 -0800
            Re: Oozing poison Leigh Johnston <leigh@i42.co.uk> - 2012-01-11 13:36 +0000
              Re: Oozing poison John Bokma <john@castleamber.com> - 2012-01-11 10:08 -0600
              Re: Oozing poison AD <isquat@gmail.com> - 2012-01-12 06:08 -0800
                Re: Oozing poison Leigh Johnston <leigh@i42.co.uk> - 2012-01-12 14:13 +0000
                Re: Oozing poison AD <isquat@gmail.com> - 2012-01-17 02:08 -0800
                Re: Oozing poison Henrik Faber <hfaber@invalid.net> - 2012-01-17 12:50 +0100
                Re: Oozing poison Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-13 02:18 -0800
                Re: Oozing poison AD <isquat@gmail.com> - 2012-01-17 02:24 -0800
      Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-11 16:50 +0000
        Re: Oozing poison AD <isquat@gmail.com> - 2012-01-12 06:04 -0800
          Re: Oozing poison Victor Bazarov <v.bazarov@comcast.invalid> - 2012-01-12 10:13 -0500
            Re: Oozing poison AD <isquat@gmail.com> - 2012-01-17 02:19 -0800
              Re: Oozing poison Victor Bazarov <v.bazarov@comcast.invalid> - 2012-01-17 08:04 -0500
              Re: Oozing poison Miles Bader <miles@gnu.org> - 2012-01-18 13:51 +0900
                Re: Oozing poison AD <isquat@gmail.com> - 2012-01-21 04:40 -0800
                Re: Oozing poison Quint Rankid <qbr567@gmail.com> - 2012-01-21 09:05 -0800
                Re: Oozing poison Wil Evers <bouncer@dev.null> - 2012-01-21 18:52 +0000
                Re: Oozing poison Quint Rankid <qbr567@gmail.com> - 2012-01-21 11:33 -0800
                Re: Oozing poison AD <isquat@gmail.com> - 2012-01-25 02:23 -0800
                Re: Oozing poison AD <isquat@gmail.com> - 2012-01-25 02:07 -0800
                Re: Oozing poison Victor Bazarov <v.bazarov@comcast.invalid> - 2012-01-25 07:59 -0500
                Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-26 07:54 +1300
                Re: Oozing poison Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-01-21 22:43 -0500
                Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-22 21:05 +1300
                Re: Oozing poison Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-01-22 18:21 -0500
                Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-23 15:55 +0000
                Re: Oozing poison gwowen <gwowen@gmail.com> - 2012-01-23 08:37 -0800
                Re: Oozing poison Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-01-24 22:48 -0500
                Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-25 19:44 +0000
                Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-26 08:56 +1300
                Re: Oozing poison 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-25 23:04 -0800
                Re: Oozing poison Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-26 03:24 -0800
                Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-26 19:13 +0000
                Re: Oozing poison Brian Drummond <brian@shapes.demon.co.uk> - 2012-01-27 00:12 +0000
                Re: Oozing poison "MikeWhy" <boat042-nospam@yahoo.com> - 2012-01-26 22:44 -0600
                Re: Oozing poison 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-28 14:25 -0800
                Re: Oozing poison Robert Miles <milesrf@Usenet-News.net> - 2012-02-26 22:16 -0600
              Re: Oozing poison "Gernot Frisch" <me@privacy.net> - 2012-01-24 18:21 +0100
                Re: Oozing poison Victor Bazarov <v.bazarov@comcast.invalid> - 2012-01-24 12:41 -0500
                Re: Oozing poison Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-26 03:25 -0800
              Re: Oozing poison Rui Maciel <rui.maciel@gmail.com> - 2012-01-25 19:44 +0000
                Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-26 09:44 +0000
                Re: Oozing poison Rui Maciel <rui.maciel@gmail.com> - 2012-01-26 10:36 +0000
                Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-26 19:18 +0000
                Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-26 20:42 +0000
                Re: Oozing poison Juha Nieminen <nospam@thanks.invalid> - 2012-01-26 16:30 +0000
                Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-26 19:24 +0000
                Re: Oozing poison Cholo Lennon <chololennon@hotmail.com> - 2012-01-26 17:13 -0300
                Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-26 20:55 +0000
                Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-26 22:08 +0000
                Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-27 00:32 +0000
                Re: Oozing poison Dombo <dombo@disposable.invalid> - 2012-01-28 12:59 +0100
                Re: Oozing poison Cholo Lennon <chololennon@hotmail.com> - 2012-01-27 18:28 -0300
                Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-29 18:02 +0000
                Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-27 20:18 +1300
                Re: Oozing poison Miles Bader <miles@gnu.org> - 2012-01-27 18:09 +0900
                Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-27 20:29 +0000
                Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-28 10:06 +1300
                Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-27 21:26 +0000
                Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-28 12:22 +1300
                Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-28 04:18 +0000
                Re: Oozing poison Miles Bader <miles@gnu.org> - 2012-01-28 13:44 +0900
                Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-28 21:31 +0000
                Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-29 11:32 +1300
                Re: Oozing poison 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-28 14:55 -0800
                Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-29 11:59 +1300
                Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-30 17:08 +0000
                Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-28 18:06 +1300
                Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-28 22:49 +0000
                Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-29 12:22 +1300
                Re: Oozing poison scott@slp53.sl.home (Scott Lurndal) - 2012-01-27 20:16 +0000
                Re: Oozing poison Ian Collins <ian-news@hotmail.com> - 2012-01-28 10:01 +1300
                Re: Oozing poison Juha Nieminen <nospam@thanks.invalid> - 2012-01-28 16:00 +0000
  Re: Oozing poison Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-10 21:42 +0000
    Re: Oozing poison AD <isquat@gmail.com> - 2012-01-17 02:31 -0800

csiph-web