Exception Misconceptions: Exceptions are for unrecoverable errors.

[tanix]

Please watch the Subject: header.
It has been modified by some fools to fragment this thread.
Right now, there are several threads that have CR/LF and blanks inserted
into subject line, which, according to NNTP standard, makes them all
different threads.

Here is the correct Subject header:
Re: Exception Misconceptions: Exceptions are for unrecoverable errors.

When you follow up on one of those screwed up threads, change
the subject as shown above.

For a lot of tasks that is so true. But then there are things where
this argument doesn't work. If you have a heavy workload and budget
hardware, you will have to work on the optimization really hard. In
some workloads a good application architecture won't be any good
without razor sharp innerloop.

Think of 1080p mpeg-4 or h.264 decoding on Intel Atom; you don't have
the luxury of saying that "well hardware is fucking fast I'll just do
this decoder in Perl.

Understood. I would not even conceiver of writing things like decoders
in perl or even Python for that matter.
:--}

If the decoder skips frames, you suck. If you write 2% of the decoder
in assembler, for example, so that you can use instructions you know
the Atom has and tried to trick the compiler to use them in C/C++ (for
example) without success, you just say: "**** THIS SHIT" and get the
job done. You squeeze extra 8% of performance out of your code, and
meet the target performance (full framerate =3D no dropped frames and
some headroom for higher bitrate files), job well done.

No problem with that one.

If the Atom platform has GPU, you might want to write CUDA / OpenCL /
GLSL / CS / etc. code to use the graphics processor to do some last
stages of the decoding, so that you can write directly into a
texture / framebuffer object. If nothing else, the YUV-to-RGB
conversion at least can be done in the GPU. For that kind of task, you
use the langauges that you must.

But yeah, for some simple flow control logic and stuff like that, we
got practically endless CPU cycles. But as always, absolute statements
are inaccurate and misleading. Different strokes for different tasks
and all that, right sirs?

Sure. Why not. As long as you keep things in proper perspective
and try to squeeze some performance out of a totally screwed up code.

I have seen plenty of cases where you can get several times more
performance without trying to squeze out every cpu cycle.

In fact, I have a luxury, if I need to squeze it even further,
hey, you've got some slack, go for it.

Except it is the LAST thing I am going to do.
That means, before you try to squeze those cpu cycles out of something,
better make sure you whole architecture is already as efficient as it
gets.

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.

 

[James Kanze]

"James Kanze" <[email protected]>

Hm, to me that is what sounds strange. To me mutex locking
means a ctirical section of code, and has nothing to do with
invariants or coherence.

Well, I won't insist on it; I don't generally think of it in
terms of program coherence either. But I do remember reading
(by someone who I respect, but I've forgotten who) that you
could consider whether the mutex is locked or not part of the
program state (it certainly is, when it comes down to it), and
the "coherent state", or the program invariant (which you may
violate temporarily, but only provided you return to a "coherent
state" later) is that all mutex's are unlocked.

It's certainly a possible point of view. I won't go much beyond
that.

And invariant means something that holds. And supposed to. It
may be broken for some special technical reason (like not
having atomic multi-assign), but it better be avoided.

As you said, it may be broken for some special technical reason,
within a single operation. In Eiffel, I believe, invariants are
checked when a call is entered from outside the object, and
again when you return from that call; they are not checked when
calling within the obect. Translated to C++, that would mean
that the invariants must hold when you call a public function,
and when you return from that function, but they may be broken
(temporarily) when you are in the function.

That's the standard definition of "class invariant" that I know
from programming by contract. Extending it to include program
state, of course (as opposed to simply class invariants) is
perhaps a bit risky, and I'd certainly be more adverse to
breaking program invariants (accross classes). But again, it's
all a question of point of view.

While critical sections are totally meant to be entered, and
perfectly natural.

It's also perfectly natural to temporarily violate class
invariants within a member function. At least, it has been
traditionally held to be so.

[...]

I did study that constructor when it was a new thing (guess
like a decade ago), and it was definitely illuminating. IIRC
it was before Herb's Exceptional... books, and the Abrahams
guarantees were either in the future or new stuff.

By today the scene hopefully is different, that material is
considered fundamental for a long time. And have high
attention in interviews for a C++ position and code reviews.

But boost::shared_ptr remains illuminating, because of its
particular post conditions: the object will be deleted
(guaranteed) as soon as there are no boost::shared_ptr referring
to it. Which means that if construction of the
boost::shared_ptr can fail (and it can), then there will be no
boost::shared_ptr pointing to it, and the object it points to
will be deleted.

[...]

In normal cases we want to avoid that very problem.

Then use garbage collection. But in practice, even with
garbage collection, you can't simply ignore the lifetime of an
object. Or at least, not of all objects. (It is your design
which must decide which objects can be ignored, with regards to
lifetime. And in my experience, those are often value objects,
which you generally won't allocate on the stack anyway.)

 

[tanix]

Watch the thread Subject header.
You are still talking on one of those atrophied threads.

Modify subject to this one to keep it all on one thread when you respond.

Re: Exception Misconceptions: Exceptions are for unrecoverable errors.

"James Kanze" <[email protected]>

Hm, to me that is what sounds strange. To me mutex locking
means a ctirical section of code, and has nothing to do with
invariants or coherence.

Well, I won't insist on it; I don't generally think of it in
terms of program coherence either. But I do remember reading
(by someone who I respect, but I've forgotten who) that you
could consider whether the mutex is locked or not part of the
program state (it certainly is, when it comes down to it), and
the "coherent state", or the program invariant (which you may
violate temporarily, but only provided you return to a "coherent
state" later) is that all mutex's are unlocked.

It's certainly a possible point of view. I won't go much beyond
that.

And invariant means something that holds. And supposed to. It
may be broken for some special technical reason (like not
having atomic multi-assign), but it better be avoided.

As you said, it may be broken for some special technical reason,
within a single operation. In Eiffel, I believe, invariants are
checked when a call is entered from outside the object, and
again when you return from that call; they are not checked when
calling within the obect. Translated to C++, that would mean
that the invariants must hold when you call a public function,
and when you return from that function, but they may be broken
(temporarily) when you are in the function.

That's the standard definition of "class invariant" that I know
from programming by contract. Extending it to include program
state, of course (as opposed to simply class invariants) is
perhaps a bit risky, and I'd certainly be more adverse to
breaking program invariants (accross classes). But again, it's
all a question of point of view.

While critical sections are totally meant to be entered, and
perfectly natural.

It's also perfectly natural to temporarily violate class
invariants within a member function. At least, it has been
traditionally held to be so.

[...]

I did study that constructor when it was a new thing (guess
like a decade ago), and it was definitely illuminating. IIRC
it was before Herb's Exceptional... books, and the Abrahams
guarantees were either in the future or new stuff.

By today the scene hopefully is different, that material is
considered fundamental for a long time. And have high
attention in interviews for a C++ position and code reviews.

But boost::shared_ptr remains illuminating, because of its
particular post conditions: the object will be deleted
(guaranteed) as soon as there are no boost::shared_ptr referring
to it. Which means that if construction of the
boost::shared_ptr can fail (and it can), then there will be no
boost::shared_ptr pointing to it, and the object it points to
will be deleted.

[...]

In normal cases we want to avoid that very problem.

Then use garbage collection. But in practice, even with
garbage collection, you can't simply ignore the lifetime of an
object. Or at least, not of all objects. (It is your design
which must decide which objects can be ignored, with regards to
lifetime. And in my experience, those are often value objects,
which you generally won't allocate on the stack anyway.)

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.