Richard Cownie (tich@pobox.com) on 8/25/09 wrote:
---------------------------
>JasonB (no@spam.com) on 8/25/09 wrote:
>---------------------------
>
>>Strictly speaking you can use separate compilation of templates with definitions
>>in a separate .cpp file (and only declarations in the header,
>
>Yes. But that's a homebrew method.

I wouldn't call it "homebrew", it's a perfectly valid and legal way of separating implementation from interface, it's just not very practical.

>The standard defines
>a "standard" way to do it. Which turns out to useless,
>because no-one implements it.

Apparently Comeau C++ and Borland C++ Builder X implement it. But export is an attempt to extend a nice principle (namely compilation of implementation only once) to templates, and the lack of it is hardly a show-stopper.

For readability purposes we often separate interface from implementation by declaring the implementation outside of the class, in a separate file, that is #included at the end of the header. The only real downside to this compared to the normal separation is that the template will be recompiled for each cpp file it is used in rather than just once, i.e. it's a compilation performance issue -- but even then it's not a big one because VC++ supports precompiled headers anyway. Importantly it does not affect the final result in any way because the linker will automatically remove all duplicate copies of the same instantiation (i.e. if you use a vector of ints in every compilation unit in your project you will still only have exactly one implementation of vector for ints in your final exe; of course if the compiler chooses to inline some of the routines then they could be all over the place, but whether a method is inlined is completely orthogonal to whether it was declared inline, and in VC++ even routines compiled into separate compilation units can be ultimately inlined with Whole Program Optimisation enabled. Conversely, the compiler will generally not inline recursive functions, "large" functions, or functions that you take the address of, even if they are declared inline).

>It's a question of
>"culture", i.e. the body of experience and knowledge
>about techniques and tools. If a super-intelligent
>alien came to Earth and tried to write programs simply
>by reading the C++ standard, they'd write programs that
>wouldn't even compile, let alone run correctly.

If they happened to make the mistake of using the export keyword with the majority of compilers, yes. What is your point? It's one feature added at the last minute in the current standard that almost nobody uses and very few vendors implement because it's not really necessary. The C++ standards committee even put removing it to a vote and ended up deciding to leave it in there since there were now implementations and some people using it, although most would probably agree it was a mistake to include it in the first place. So? Sometimes that happens, it doesn't invalidate everything else.

>>>dynamic_cast (because it
>>>didn't - maybe still doesn't ? - work correctly in g++),
>>
>>dynamic_cast isn't needed all that often, but when it is needed there is no substitute.
>
>The substitute is that you put a whole bunch of extra
>virtual methods on every class in your hierarchy for
>casting to every other class. Which is N-squared in
>the number of classes, so it's really ugly.

Should I have said "there is no practical substitute"?

>>In keeping with C++'s general philosophy, however, you >need to have RTTI enabled in order for it to work.
>
>I think you're talking specifically about MSVC++ there ?

I don't think so -- I imagine most compilers allow RTTI (and exception support) to be enabled or disabled because enabling them imposes a cost and if you don't use dynamic_cast (or exceptions) in your code at all you can avoid paying that cost, which is one of the main principles of C++ (i.e. you don't pay for what you don't use; cf. methods not being virtual by default). In g++ at least the switch to disable RTTI appears to be "-fno-rtti".

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 casting. The OTT use of casting in Java, for example, is because in earlier versions all containers had to contain Objects and you always had to use a cast every time you retrieved something from the container; in C++ you just use templated containers that check at compile time that you're only inserting and retrieving objects of the specified type.

We only ever use it to cast pointers returned by the MFC framework that should always be what it is expected but it's just making sure. We also have our own cast that does a dynamic_cast in debug mode and a static_cast in release mode for the same types of things.

>>Exceptions, when only used for exceptional stuff (i.e. not for routine errors,
>>like Java does), are useful. As I mentioned before, we put try-catch blocks at the
>>"user level" of individual operations and do the work off to the side so that if
>>anything goes wrong with the operation itself no damage is done and we can simply
>>tell the user the operation couldn't be performed.
>
>Sure, but used like that it doesn't add much beyond
>what setjmp/longjmp give you.

Well, off the top of my head I can see two serious obstacles to using setjmp/longjmp as a substitute for exceptions.

The first is practicality: the amount of housekeeping you would need to do and the unacceptable level of coupling and co-operation between completely different levels of your program would be a nightmare to both implement and maintain.

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 that you are calling. It might be perfectly reasonable, for example, to handle an out-of-memory exception at a relatively low level in a certain case, but want to let an illegal access violation pass up to a much higher level where your "I'm sorry, please let me submit this bug report for you" handler can take care of it and then continue on.

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 where it is possible to file a bug report with the server related to the particular operation that was attempted, and then allow the user to continue on in exactly the same state they were in prior to attempting that operation with a warning that they probably should not attempt that particular operation again until the bug has been fixed).

>And mediocre developers
>tend to say "we'll use exceptions" as a *substitute* for
>actually designing an error-handling strategy.

I really don't care what mediocre developers will do. Mediocre developers will always find ways to do things wrong. If I wanted to limit my options by excluding anything mediocre programmers might get wrong I'd be using Java, not C++, and even then I wouldn't have achieved much. (Find me an exception-safe Java program...)

>>Writing exception-safe code is hard, but doing so is worth it.
>
>Possibly, if you design it in from the beginning. But
>taking millions of lines of exception-unsafe code and
>trying to make it exception-safe is infeasible. And
>I *really* don't like features that require a global
>change in assumptions and coding practices: that makes
>it a big cost.

Actually, it wasn't all that hard for us. For the most part we have exception handlers around the user-level operations and we make those high-level routines exception safe -- in the worst case we simply report the problem to the user and the program is in exactly the same state it was in before.

>>Note that, on Windows at least, underlying CPU and OS exceptions can be mapped
>>into the language (structured exceptions) and handled just like any other exception.
>>Even if you don't use exceptions yourself, writing exception-safe code means you
>>can automatically do something nicer than core dump when there's a bug in your code.
>
>Up to a point. If the exception is saying "something
>really screwy just happened in your code", then trying
>to catch it with an exception handler that does a lot
>of complicated stuff may not be robust.

Our exception handlers are of the form:

   try {

      MakeCoffee(options);

   } catch (const structured_exception& e){

      // Ooh, this shouldn't happen. Most likely a bug.

      RequestPermissionToLodgeReport(e);

   } catch (const std::exception& e){

      // A standard problem

      ReportException(e);

   }

structured_exception handles the following errors:

"Access violation", "Array bounds exceeded", "Datatype misalignment", "Float: Denormal operand", "Float: Divide by zero", "Float: Inexact result", "Float: Invalid operation", "Float: Overflow", "Float: Stack check", "Float: Underflow", "Illegal instruction", "In page error", "Integer: Divide by zero", "Integer: Overflow", "Privileged instruction", "Stack overflow", "Breakpoint"*, "Single step"*, "Noncontinuable exception", "Invalid disposition", "Guard page", and "Invalid handle". (The two with *'s are actually invoked when you're running the program in the debugger; we actually don't try to catch those.)

It contains the value of every register, the full stack trace, and extra values related to the type of error. So, for example, our code for handling an access violation extracts the location that the code attempted to write to thus:

    if (record.ExceptionCode == EXCEPTION_ACCESS_VIOLATION && record.NumberParameters == 2){

        os << ": Attempted to " << (record.ExceptionInformation[0] == 0 ? "read from" : "write to") <<

           " address 0x" << setw(8) << record.ExceptionInformation[1];

    }

Although having a bug in your code is undesirable, we've found it's better to be upfront about it and not having the program die taking all of the data generated so far with it goes a long way to overcoming the negative impression. If you encapsulate the operation properly so that no matter what went wrong at what stage, everything else is still OK, the biggest problem from the user's point of view is that they are unable to perform that particular operation (at least with the parameters or data they attempted to perform it with).

The std::exception stuff is more "normal" and can include things like running out of memory (although you may well have a "catch (const std::bad_alloc& e)" closer to the site where the memory was actually being used if there's a chance something else can be done about it, while letting all other standard exceptions through to the keeper).

>I don't see a compelling argument for exceptions
>compared to setjmp/longjmp (and signal handling for the
>OS stuff). Exceptions fit better in languages with
>garbage collection.

On the contrary, I think languages with GC are far worse for exception handling.

GC typically implies non-deterministic object destruction. Non-deterministic object destruction implies RAII cannot be used. Not being able to use RAII makes it nearly impossible to write exception-safe code.

To give you an example using C-style code (because the standard C++ equivalents use RAII internally already), consider the following code using scopeguard:

    char* ptr = (char*) malloc(10);

    if (ptr == NULL)

        return false; // or throw, or whatever

    ON_BLOCK_EXIT(free, ptr); // free(ptr) is *guaranteed* to be called when this block exits, no matter what.



    FILE* fp = fopen("test","r");

    if (fp == NULL)

        return false; //or throw, or whatever

    ON_BLOCK_EXIT(fclose, fp); // fclose(fp) is *guaranteed* to be called when this block exist, no matter what.

This not only simplifies code (no nested if statements to handle resource acquisition and release -- e.g. you can safely return or throw if you fail to open the file in the second case without having to worry about the memory being freed) but it also makes it more robust, because (as the comments suggest) the "undo" operations (free and fclose) are guaranteed to be called no matter what -- even if you trigger a CPU exception.

(Of course, the C++ equivalent would be:

    auto_ptr ap(new char[10]);



    ifstream ifs("test");

    if (!ifs)

        return false; //or throw, or whatever

because, as I said, the standard library classes already use RAII themselves.)

>And even the benefit is questionable:
>with modern cpu's, checking a return code and taking an
>extremely-predictable branch usually costs nothing,
>so exceptions don't make the code any faster.

It's not about speed. It's about making errors hard to ignore (e.g. failing to allocate memory in the C++ example above will cause an exception to be thrown) and taking care of the housekeeping should you wish to handle the error at a much different level to the one that caused the error.

In the coffee making example, if anything goes wrong with the coffee making operation the important result is that the user does not get a cup of coffee, so it's reasonable to put a catch-all at the top level of that operation that apologises profusely and suggests a cup of tea instead. However, if there is an error in the coffee-making process that can be recovered from at a lower level, then the programmer can selectively handle that case at the appropriate level and the high-level code will be none the wiser.

Importantly, nobody has to get all the error handling and propagating code just right at all the levels between where the error occurred and where the error can be reasonably handled because the compiler will take care of the tedious and error-prone housekeeping for you.

>And the
>frequent - maybe usual - consequence of separating out
>the "exceptional" case from the normal case is that the
>code for the "exceptional" case never gets written at
>all ...

And how is that more likely than the return value from the function not being checked every single time it is called? You have to make sure you check the result of every malloc or risk undefined behaviour; with new, you can safely have a whole series of allocations handled by a single catch if all of them should be considered "atomic" in the success of the operation (i.e. you only bother dealing with a particular one at the location it occurs if there is something useful you can do to recover in that instance).

>>Not surprisingly, then, I actually find it quite useful. :-) The two big benefits
>>over the old equivalents are type safety (mismatching format specifiers with actual
>>parameter types)
>
>gcc/g++ can provide warnings for printf format-vs-type
>mismatches, which is handy.

That is nice. There is also a Boost Format library that implements a type-safe replacement for printf, although I don't really like the syntax.

>>as built-in classes (you can't add support for your class >to printf's format string).
>
>No, but you could write a char* Foo::Text(void); method
>and use a %s string format specifier. So the difference
>is minimal.

But there. I like languages where user-defined classes are indistinguishable from build-in classes, and if we ignore the legacy C portions of C++ then C++ has that.

Besides, I like lexical_cast as a way of transferring data between types, and that's built on streams.

int i = lexical_cast(str);

string s = lexical_cast(i);

// s == str