Re: Which STL algorithm?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Pete Becker (petebecker_at_acm.org)
Date: 02/24/05 

Date: Thu, 24 Feb 2005 14:13:40 -0500

Doug Harrison [MVP] wrote:

> Pete Becker wrote:
>
>
>>Doug Harrison [MVP] wrote:
>>
>>
>>>Is there any prohibition on an output iterator throwing an exception? I
>>>don't think so, and if not, you could write a set_any_in_common function
>>>that catches this exception and terminates as soon as possible. This might
>>>be appropriate for algorithms more complicated than the one Pete posted in
>>>his message.
>>
>>No, it would not be appropriate. Exceptions aren't for normal returns.
>>They're for exceptional events. They create hidden execution paths, and
>>that makes understanding the code hard. Not to mention the performance hit.
>
>
> In general I agree with that. However, provided there is no prohibition on
> the output iterator throwing exceptions, it would be appropriate to do just
> that to adapt an algorithm too complex or lengthy to duplicate, or absent
> the source code, recreate entirely on your own. Consider:
>
> bool f()
> {
> try
> {
> lengthy_f_that_provides_no_early_return(Iter_that_throws());
> }
> catch (the_exception_type)
> {
> return true;
> }
> return false;
> }
>
> As lengthy_f is a black box that doesn't prohibit the iterator from
> throwing, the "hidden execution path" argument doesn't even apply to the
> person writing f. The performance hit argument may not apply, given that the
> poor performance of the algorithm that doesn't terminate ASAP is the whole
> reason for looking for an alternative. That's something that can only be
> determined empirically. But if duplicating the algorithm as you did is
> significantly harder than writing the Iter_that_throws class, looking for a
> way to work with what you've got surely is the way to go, at least until
> proven otherwise.
>

This is the first step down the slippery slope towards Java-style use of
exceptions. Don't do it. 

-- 
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

Relevant Pages

  • Re: Commenting the source code.
    ... >> Comments often help me concentrate on what I'm doing. ... Well written code seldom needs any comments, if the algorithm used is ... There are exceptions, ... Dan Pop ...
    (comp.lang.c)
  • Re: Return or Not?
    ... Alwyn wrote: ... The designers of the STL, for better or worse, decided to ... > suppose, say that the algorithm has failed, but I would agree that the ... It must be evaluated on a case by case basis if exceptions ...
    (alt.comp.lang.learn.c-cpp)
  • Berlekamps algorithm
    ... I'm trying to implement Berlekamp's algorithm. ... irreducible polynomials." ... I've found quite a few exceptions, and here are one of them: ... But the null space basis has dimension 3: ...
    (sci.math)
  • Re: simplify disksort, please review.
    ... > Our disksort algorithm used to be complicated by the BIO_ORDERED flag, ... > which could cause us to make some exceptions in the sorting. ... > ordered support was removed we never simplified the algorithm. ... Sorry for the late review, ...
    (freebsd-arch)
  • Re: Real life cost of using exceptions for control flow?
    ... >>Certainly it's not worth refactoring just because of the performance ... >>So, ignore the performance aspect for the moment, and design it in the ... exceptions per hour is a disturbing rate of exceptions being thrown. ... that a performance hit of "x" is okay, ...
    (microsoft.public.dotnet.framework.performance)