Richard Cownie (tich@pobox.com) on 8/26/09 wrote:
---------------------------
>JasonB (no@spam.com) on 8/25/09 wrote:
>---------------------------
>
>>of compilers, yes. What is your point?
>
>My point is that "standard" and "conformant" are rather
>unhelpful concepts. There's stuff that's officially
>"standard" that shouldn't be used because hardly anyone
>implements it. There's stuff that's arguably "conformant"
>but completely useless.

Be careful about throwing out the baby with the bathwater just because there is one feature not implemented by the majority of compilers because it is pretty useless and hard to implement.

It's not a justification for relying on stuff that is specified to be unreliable, and in fact not only varies between implementations, and with different compiler switches in the same implementation, but even varies depending on what features your code is using (e.g. threading in your case).

>So it comes down to culture: you work in one kind of
>culture - small group of competent developers, Windows,
>MSVC++, adherence to coding standards. I work in a very
>different culture - largish group of developers of (to
>be polite) varying competence, Linux, g++, no ability
>to enforce coding standards. Applying the judgments of
>one culture to practices in another culture is not a
>very productive exercise, any more than criticizing a
>Kalahari Bushman for not wearing a jacket and tie.

The thing is that all of that is an even bigger argument for writing your own malloc() or at least checking the code to see if the behaviour you were seeing was real. My point from the beginning was the inconsistency in your position where you were unwilling to use a well-defined subset of the language because it might be implemented poorly (STL), but were willing to base an entire pointer compression algorithm on the apparent behaviour of one function without even looking at its implementation when the standard specifically states that that particular behaviour is not specified.

>>Should I have said "there is no practical substitute"?
>
>It's ugly, but it's practical: we do it, where we have to,
>it works, and we can sell the app.

Ouch. And you had to do all of that because GCC doesn't implement dynamic_cast properly?

I'm sure GCC is a mess, but I wonder if it would have been easier to try and fix the bug in GCC instead? :-)

>>I just searched through our code and we never use dynamic_cast for any of
>>our own code -- properly designed application-level OO code has very few uses for
>
>Oh, I agree. If you're using it, it's probably poor
>design. But that was my original point: are there
>features in the language standard that you never, or
>hardly ever, use ? We can put dynamic_cast on that list.

It's one of those things that you hardly ever use in well-designed code of a certain type, but is absolutely vital in another context.

Look at reinterpret_cast: that has no real place in most application-level code, but you couldn't write system-level code without it. At least dynamic_cast has some justification at the application level: safely downcasting a pointer to a parent class down to the appropriate child. Usually there are better designs that eliminate the need, but C++ is a pragmatic language.

>>With exceptions you can freely choose at any level to handle any subset of any
>>possible exceptions without ever having to worry about anything falling through
>>the cracks, and without having intimate knowledge of the implementation of the code
>
>The problem is not with the places where you handle
>or don't handle exceptions. The problem is with code A
>that worked just fine without exceptions, but becomes
>broken because code B starts throwing an exception and
>code C catches it and tries to recover.
>
>Like this:
>
>void A(char* fname)
>{
>int fd = open(fname, O_RDONLY, 0);
>if (fd < 0) ... error check
>ParseTree* foo = ParseFile(fd);
>close(fd);
>}
>
>Is that code ok ? Yes if ParseFile() can't throw an
>exception; no if ParseFile() can throw an exception -
>in that case we'll leak the file descriptor fd.

Fortunately it only takes one line to fix:

void A(char* fname)
{
int fd = open(fname, O_RDONLY, 0);
if (fd < 0) ... error check
ON_BLOCK_EXIT(close, fd);

ParseTree* foo = ParseFile(fd);
}

(I assume you actually do something with foo rather than just leak it.)

This routine is now exception safe. (ParseFile may not be, but that's ParseFile's problem.)

That's the beauty of scopeguard.

You can even save a line if you use ifstream instead because it uses RAII internally.

>And I can't tell by looking at this code alone.

The whole point of RAII is that for each routine, if you make that routine exception-safe in isolation, you don't have to care about implementing try-catch(-finally) at all except in the routines that actually try to handle the exception.

>And
>if ParseFile changes, nothing in the compiler is even
>going to warn me that the non-local effects of the
>change make it necessary to review and possibly change
>this code.
>
>Yeuch!

That's why making each routine exception safe is so important, which is why making writing exception safe code easy is so important, which is why RAII is so important, which is why C++ makes writing robust code easier than e.g. Java.

BTW, one of the reasons why the compiler doesn't warn you that a routine you are calling has exceptions that you aren't handling is because C++ has to interface with legacy code and there is no way for it to know that.

In hindsight, after seeing the mess that checked exceptions results in with Java, it turns out that even if it had been possible to make exception specifications a mandatory requirement it would have been a bad idea. 15 years ago it seemed like a reasonable thing and that C++ was missing out because of compatibility requirements, but now it seems like it dodged a bullet.

I consider checked exceptions the "export" equivalent for Java -- something that sounds good on paper but really needed a few years experience in writing large programs before committing to.

>>The second is functionality: throwing an exception guarantees the destruction of
>>all objects on the stack from the thrower to the catcher, allowing RAII to be used
>>to guarantee no resources leak and the program to be exception safe (to the point
>
>Except it doesn't.

Yes, it does.

>It guarantees that all *objects* get
>destroyed. But there are resources that aren't necessarily
>objects with destructors. So this becomes a bit half-assed.

Read what I wrote. If you aren't using objects to manage resources then you aren't using RAII.

You can always create an object to manage a resource. You can even model resources that it doesn't make sense to copy (e.g. a keyboard). If you don't already have a resource management object and you can't be bothered writing one, then use scopeguard. It allows you to create a lightweight object in one line of code that tells how to release the resource. (ON_BLOCK_EXIT is simply a macro to create an anonymous object.)

If you're using so many C-style interfaces in your code then scopeguard can really help, not only with exception safety but even just simplifying code by allowing you to keep resource management code adjacent to each other spatially (even if their execution is temporally separated).

In case you're not using it already, here's a slightly modified one from the original: http://www.zete.org/people/jlehrer/scopeguard.h. It has features that aren't in the one in Boost.

>Sure, if all your code everywhere carefully follows the
>necessary rules, then exceptions can work out pretty
>well. But a) verifying global compliance to rules that
>can't be automatically checked is a hard problem,

This is why it's so important to use a very simple idiom that you can see immediately has been followed. Adding one line of code immediately below the existing code is much easier to enforce than making sure the same call is made at the other end of the routine plus on every relevant return path.

>and b) enforcing *new* global rules in an old codebase
>is just about impossible.

The approach we took was to update the code as we went, starting at the top level routines. Then, over time, if an exception could be profitably handled lower down that would mean the entire operation needn't be aborted, add a handler for that. Using the standard C++ classes (plus MFC's) rather than C functions automatically gives you a lot of RAII by default because I can't think of one that doesn't use RAII.

>>I really don't care what mediocre developers will do. Mediocre developers will
>>always find ways to do things wrong.
>
>Like I said, different culture. In my environment, the
>best choices are to make sure that anything subtle is
>carefully encapsulated (preferably in a single file);
>and to apply defensive programming at the interfaces
>(assertion checking etc) so that when someone does
>something stupid, you can detect it and tell them about
>it quickly.

The whole point about using scopeguard (or classes with RAII) is that it simplifies code while, at the same time, making it robust. The weaker the developers, the more value there is in using this approach.