I have some programming waiting to get done as well, so I'll try to be brief. :-)

Richard Cownie (tich@pobox.com) on 8/27/09 wrote:
---------------------------
>As for the "standard" crapola, you're perfectly willing
>to use hash_map<> even though it is *not* in the standard.
>It probably should have been from the start, but it isn't.

The issue was never whether you had to restrict yourself to the standard (the standard libraries don't have a lot of API's necessary for modern applications, so you really can't if you want to have a windowing UI (we use MFC), 3D graphics (we use OpenGL), threading (our own routines on top of MFC, but Boost and/or OpenMP would also work), etc.) but whether you assume things about the behaviour of the standard library (or any library you don't control the implementation of, for that matter) when specifically warned not to.

>>Look at reinterpret_cast: that has no real place in most application-level
>>code, but you couldn't write system-level code without it.
>
>Of course you could: you can do it with a union,

Reading from a union member other than the last one you assigned to is unspecified.

The only exception is when your union contains objects that have common initial elements, in which case you can safely read or write those particular elements through any of the objects that contain them -- but that's useless for using it to implement reinterpret_cast.

>or by
>taking the address of the thing and casting it as a
>pointer to the type you want. That's two ways to do
>(both of which would work all the way back to K&R C).

That shouln't even compile unless you use reinterpret_cast or a C-style cast, and the latter is cheating because it will do the same as reinterpret_cast so you're still using it anyway, only now you're using it on the pointers rather than the data you're trying to convert.

And even then if you actually try to dereference the pointer to the type you want the result can still be undefined if the type you want is anything other than [u]char. (Think about what happens if the alignment restrictions on the type you want are more onerous than the source type.)

>>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.
>
>Back around 1984, I worked with some ex-Xerox PARC people
>for a while, who had experience with early code using
>exceptions on what was it ? The Alto or Dorado ?
>Anyway, they'd been on the bleeding edge. And what I heard
>was that the number 1 problem on those systems was programse
>crashing with "uncaught exception". That gave me a
>negative view of the whole idea from the start.

Actually, that's one of the good things about exceptions, and goes to something you said before -- better to have an error noticed immediately rather than silently ignored. Forget to handle an exception somewhere in your code and, under Windows at least, the very first time you trigger it the OS will tell you about it in no uncertain terms. Forget to check the return value of a function and it could be ages before the consequences hit home.

The issue I was alluding to with checked exceptions was the idea of declaring exactly what exceptions a routine can throw as part of its interface. Intuitively, this seems like a good idea, because the exceptions a routine can throw really are just as much a part of its interface as the return value is. Even better, the compiler can actually check at compile time that every exception is being handled. It's brilliant.

Except it turns out that it doesn't scale and it's a real PITA to maintain. Java programmers either end up using very general exception specifications (saying not much more than "this routine throws some sort of exception but I'm not going to be more explicit than that") or using unchecked exceptions (which don't have to be declared) because the overhead of maintaining all those exception specifications becomes significant as the code grows. Imagine adding one new exception at a very low level that you don't want to handle until the top level, and having to update the signature of every method in between to include the new exception...

The reason C++ dodged this bullet was that although it has exception specifications like Java does, the default behaviour, if no specification is given, is to assume that any exception can be thrown, rather than none. This was necessary to cope with all that existing code out there. So nobody uses them (except in the very rare case where you really want to say no exception can possibly be thrown, like with a swap() routine, which is a necessary precondition for exception-safe code) and we therefore missed the whole experience.

>>Read what I wrote. If you aren't using objects to manage >resources then you aren't using RAII.
>
>OK, so we're not. And we can't guarantee that. Actually,
>no-one can *guarantee* it, because there's no way to check
>it automatically. So now what ?

Well, one option could be to search through all your code looking for the functions you use to acquire resources, and either replace them with C++ equivalents that do implement RAII, or use scopeguard.

But that's besides the point. It's a tool. You can use it to achieve what you are looking for, but to do that you need to use it. If you have a problem caused by not using the tool, then it's not the tool's fault, and it doesn't contradict my statement about the benefits of using that tool.

If you really want to realise the benefits then using it has to become part of the culture because unless C-style interfaces are deprecated and warned against by the compiler (which would probably annoy the heck out of people using them extensively, like yourself) that's the only way the tool will be used.

>>You can always create an object to manage a resource.
>
>Yeah, you *can*. And you *can* write a large program in
>assembly language that always uses all its global variables
>with the right types. It's just damn hard, because no
>tools enforce the constraint. Whereas strongly-typed
>languages make it easy. Rules without tools are pretty
>weak (you can make up for that weakness by hiring really
>good people and applying good management practices, but
>those are tricky problems in themselves).

The thing is that resources don't come from nowhere, you acquire them somehow. In your case you have been using C APIs (e.g. malloc, fopen, etc.). C++ already has objects that can do the same thing, and all the ones I can think of release the resource in the destructor if it hasn't already been released explicitly. MS followed the same approach with MFC. If you use C++ APIs then you get the benefit automatically; if you want to take advantage of C++'s backwards compatibility with C then you don't get the benefit, but it seems a little unfair to blame C++ for that and equate not using C APIs in C++ programs with writing a large program in assembly language.

>>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.
>
>Thanks. It's a good trick, and I'll consider using it
>in my own code.

I suspect it would do you even more good than me because searching through our code I can only actually see one use of it (to manage a manually-allocated buffer passed to a Win32 routine) and I realise we could have simply used a vector for that anyway.

But if we were using more C API's I'd definitely be using it then.

Anyway, if you haven't already seen it, this is the original article with motivating examples:

http://www.ddj.com/cpp/184403758

The trick to avoid virtual function overheads was neat.

To me the main benefit is resource management (i.e. using object destruction to release resources) rather than implementing transactional semantics (using object destruction to undo an operation unless told not to) but the same tool does both.

Solution 1 is what you need to do in Java, which is why I find Java's "simplicity" to be illusory.

The explanation for the modifications in the one I linked to is here:

http://www.zete.org/people/jlehrer/scopeguard.html