Re: C++ & Templates was Re: Question about programming techniques

[Miroslav Silovic <silovic zesoi fer hr>]

Miles Egan <cullen@best.com> writes:

> I suppose this really isn't the place for this discussion, but I just have
> to say that all of my experiences with the STL have been extremely
> positive.  I've gotten a lot of mileage out of the vector, list and queue
> classes, and the map class is EXTREMELY handy.  Performance hasn't been an
> issue at all and I haven't observed any serious code bloat ( this is with
> Visual C++, unfortunately, maybe things are different with gcc ).

This is because you haven't looked in the right place. glib.so is a
shared library, right? Well... Try to compile STL into a shared lib.
Problematic, isn't it?

> Constructors and references can be a little bit confusing, I'll agree, but
> you're going to have to initialize your data sometime.  Why not let the
> computer do it for you?  That's the kind of thing computers excel at.  It
> may take a bit of work to get it right in the first place, but once you
> do, it's all automatic.

I am not at all confused by constructors or destructors. In fact,
their effect is perfectly clean to me:

1) each block with constructor/destructor pair requires safe stack
unwind when you leave it. This means that each function call /and/
each entry into the block with constructors requires an equivalent of
unwind-protect around it (unwind-protect means: trap all the errors
that occur in this block, run the 'cleanup' code and rethrow the
error). Now when you compile, say, ACE toolkit with exception
handling, you get 1.3 MB library. Without, you get 1 MB. And exception
handling is VERY useful - and generally implementable with a simple
stack pointer bump in any language with automatic memory managent.

2) C++-style stack unwinds also prevent tail-call optimization. This
means that programmers that like recursion (such as myself) may meet
some nasty surprises.

Constructors are undoubtedly useful, but not in the way C++ does them.
Specifically, tying them to the program blocks, and silently adding
cleanup code, makes c++ inferior to pretty much any *real* OO
language.

On another note, I implemented a modified version of Paul Wilson's
garbage collector into my own general-purpose container lib (with
mixed-type containers, thankyouverymuch). It proved a
nightmare. First, inheritance in C++ is implementented *badly* and may
cause vtable pointers to end up in all the wrong places when you cast
things around. dynamic_cast<> wasn't helpful - there just isn't a way
to point to an object of a completely unknown class in such a way that
you can be assured that pointer looks into a meaningful type
information. Secondly, much worse, it turned out that C++, in its HUGE
list of features, somehow neglected to implement a way to determine
any type information on the object except by doing a virtual method
call - you can't even put class-dependant attributes into a vtable
(this would've been trivial to implement) - much less do ObjC style
queries (ObjC can give you complete list of properties and methods,
along with their type info - you can have distributed ObjC objects
without ever worrying about IDL).

I also find it worrysome that nobody remembered to notice that C++
name mingling means a huge bother when you try to use C++ libs in
anything non-C++. Can you call C++ functions from FORTRAN... without
writing one glue function per exported function whose sole purpose is
to unbreak the namespace?

-- 
I refuse to use .sig