From: dave@boostpro.com
on Sun Oct 02 2011, nmm1-AT-cam.ac.uk wrote:
> In article ,
> Dave Abrahams wrote:
>
>>> As I said, I did a few tests doing things both ways, and came to
>>> the conclusion that the benefit was small, at best. Take a look
>>> Bjarne's matrix.h and boost::multi_array to see the approach others
>>> have taken :-)
>>
>> Is your code exception-safe, Nick? I'm curious, because it's been my
>> experience that using std::vector is a *major* simplification,
>> especially when that's not the only resource your class has to manage,
>> if you're writing exception-safe code. Try writing a Compressed Sparse
>> Row matrix both ways and you'll see what I mean.
>
> I have done worse - I have designed and written code that was safe
> against asynchronous exceptions! Yes, it is WAY beyond the ability of
> most people, and hell even for the few people who can do it.
So... how did you test (or otherwise prove) its safety? I'm not even
sure what you mean by "exception-safe" in the context of asynchronous
exceptions. Since all operations are essentially allowed to throw, I
think it means you are never allowed to break invariants, even
momentarily during modifications, because you're never assured of being
able to complete the process of restoring a broken invariant. Sounds
like a simple enough world, though I imagine higher-level abstractions
might be quite hard to build.
> C++ exceptions were originally intended to allow for those to be
> included, but C++11 took a decision to formally exclude them,
Asynchronous exceptions were formally excluded in C++98/03 as well. I'm
not aware of any changes to the standard language in this area for
C++11, but even if there were, nothing in C++98/03 allowed "int i = 0;"
to throw (leaving aside the "resource limits" backdoor which allows
anything at all).
> though I doubt most people in WG21 took that on board. The key is
> transferring exceptions between threads - that is an absolute no-no
> for such things.
>
> More generally, when writing code, I rarely use exceptions, precisely
> because they are so hard to get right.
That's a misconception IMO. It's usually much harder to get "error
handling" right without exceptions, just like it's harder to get
subroutines right without first-class functions and looping right
without "for." It's just that people don't think carefully enough about
"error handling," or test the "error" paths enough, to realize their
code is totally broken. When ex-C programmers started thinking about
exceptions, they were unfamiliar, and when combined with a general lack
of understanding of "error" recovery, a lot of people were confused.
> Since the 1960s, many experts have said that all forms of alternate
> return (of which C++ exceptions are merely one example) are the spawn
> of the devil. I would not go quite so far, but there is something in
> that. I generally favour the intermediate state (i.e. supporting
> trap-diagnose-and-terminate only), which is VASTLY easier to do than
> trap-recover-and-continue.
Ah, yes, it's much easier, that's true. It's also totally inappropriate
for many applications.
In fairness, it is completely outside the culture for most scientific
computing applications to use exception handling. Instead, in my
experience, checkpointing is usually used for recovery of large-scale
computations, and that may well be the most appropriate choice.
> If std::vector WERE exception-safe, I would be more impressed, but
> I am afraid that it isn't.
Exceeeeeeeeuse me? I spent several years of my life creating a
well-founded definition of exception-safety, ensuring that in the '98
standard, the containers, *were* indeed exception-safe, and educating
the community about it. The containers are generally acknowledged to be
exception-safe, and people are using the exception-safety guarantees
successfully.
> The standard specifies that insertion is, but nothing much else
That's incorrect. All operations are exception-safe, where
exception-safety is defined as the preservation of invariants: no
components are allowed to stop working just because an exception was
thrown.
> - and that, in itself, can't be done if the exception is thrown by a
> destructor following reallocation!
Errors generated by destructors are difficult to deal with in a
meaningful way, no matter what reporting system you use. They're
generally not recoverable conditions and thus exceptions are not an
appropriate way to deal with them.
> Most of the STL allows more-or-less arbitrary data corruption, by the
> omission of defined behaviour (see 1.3.12 in C++03).
You're linking me to the definition of undefined behavior? I'm quite
familiar with that, thank you. I'm sure you know this, but undefined
behavior in C++ exists where it would impose an unacceptable performance
penalty to do otherwise. [I also happen to think undefined behavior
provides us with a valuable distinction that allows us to label code
that invokes it objectively incorrect, but that's a separate issue].
> This could be improved considerably, especially with regard to
> parallelism, and there is an outstanding offer from me to help if
> WG21 were to take on such a project seriously.
I'm sure that if you can eliminate significant amounts of undefined
behavior from the language standard without imposing performance
penalties, your proposals would be seriously welcomed. But it's also my
guess that if you're waiting around to see "WG21 take the project
seriously," nothing will ever happen. Things get done in WG21 by those
who care most about them, and as far as I can tell you're the only one
on the committee who even understands your vision about what should be
improved.
--
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! ]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
