Richard Cownie (tich@pobox.com) on 8/24/09 wrote:
---------------------------
>Best example would be separate compilation of templates
>(and the "export" keyword), which no-one uses because no
>compiler AFAIK has ever implemented it.

Hmm... I actually thought gcc implemented it, essentially by reading in the C++ file behind-the-scenes.

Strictly speaking you can use separate compilation of templates with definitions in a separate .cpp file (and only declarations in the header, just like a normal class) even without using the export keyword, it's just not very practical. (You e.g. declare a variable for each specialisation you wish to use in the .cpp file where the template is defined, invoking each method you wish to use, etc., so the linker will find them. As I said, not very practical.)

Compilers like VC++ that support compilation in the linker could easily be updated to support export, but MS have stated that they are not going to.

>But it's in the
>C++ standard. Which shows that some stuff in standards
>is aspirational rather than practical or usable.

Actually, export was one of the few things that were added without already being an existing practice, and because of the lessons learned from that the standards body has just rejected concepts, which was meant to be in the next standard but was taken out again at the last minute, because there isn't sufficient experience with it yet.

C++ is one of the least "theory-driven" languages out there in that sense. A lot of the stuff in it that many people don't like (especially those from a Java background) are there precisely because of practicality and usability considerations.

>But other stuff I find pretty dodgy, and completely avoid,
>would be multiple inheritance,

I don't use it very much, if at all, but I appreciate that the language gives the option. It can be useful to implement Java-style interfaces, and it can also be the most natural way to implement objects that belong to two independent inheritance hierarchies. The problem is that its complexity doesn't scale well.

>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. In keeping with C++'s general philosophy, however, you need to have RTTI enabled in order for it to work.

We often use it instead of static_cast in debug builds.

>exceptions (because exceptions screw up the assumptions of
>pre-existing code that *doesn't* use exceptions;

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.

Writing exception-safe code is hard, but doing so is worth it.

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.

>and
>the godawful iostream stuff, because it's ugly and offers
>no significant benefit over the old FILE/fprintf.

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) and the fact that user-defined classes can have the same interface as built-in classes (you can't add support for your class to printf's format string).

Early implementations were huge, though. These days it doesn't seem to add any more bloat than normal C IO.

>And as time goes on, I actually get *more* skeptical about
>the benefits of C++ over C. You start off thinking
>classes and virtual methods will be really helpful, and
>then over time you find it's costing you quite a bit
>(in 64bit, an 8byte header on each object with virtual
>methods) and it isn't really giving you much more than
>function pointers.

Note to Java proponents: that's exactly why virtual is not the default behaviour in C++.

I agree that inheritance and dynamic polymorphism are overrated. They have a place, and can be useful, but not everything is best modelled that way.

>These days probably my favorite
>feature is the more liberal rules about where you can
>declare variables, which is trivial but really handy.
>As for the other stuff, in *any* language you get
>precisely as much abstraction and data hiding as you're
>prepared to carefully design and enforce, and language
>features don't do much more than give a gentle nudge in
>particular directions.

Agreed.