Re: (OT) Re: memory management

[Bert Peers <rat@larian.com>]

Steve Baker wrote:

> You misunderstand why Kernel's and major libraries like OpenGL are not
> written
> in C++...well, actually they might be written in C++ - but the API's are
> never
> in C++.
> The reason for this is simple.  A major service API must be written so
> it
> can be accessed from C, C++, Fortran, Cobol, you name it.  There is no
> way
> that C programs could run portably if (for example) the UNIX interface
> layers were object-oriented with C interfaces.

That's not really true.  An object in C++ is basically nothing more
than a structure with a vtable tucked in front of it.  As everybody who's
been doing DirectX programming in C for The Other OS knows,
passing a pointer to a struct as the this into a C++ api works perfectly.
It looks cumbersome but I'm not sure if it is any better or worse than
the troubles a C++ coder has to go through to use a C lib properly (ie write
an OO wrapper for it -- although the reasonability of that is a whole other
question).  COM and CORBA both define a binary standard starting
from the C++ pov, and then just give samples of how an API adhering to
it can be accessed from within C; basically you do what the C++ compiler
would do for you (laying out vtables etc.)

> However, it's easy to avoid features that are bad - just as good C
> programmers
> avoid 'goto'.

I've been using goto.  You surely don't want to design your algorithms
with weird spaghetti jumps in mind, but when time comes for the actual
implementation it's possible that on rare occasions the good old Evil
Opcode has it's use... Similarly I believe that most designers understand
that violating the interface with friends is bad at the Analysis or Design
level, but it might just boost an immense speed up at the implementation
level.  If it's documented properly, it's cool for me.  The problem is most
code has friends and other interface violations (//protected: \n public: )
all over the place, making it the OO equivalent of spaghetti code, without
documenting them...

> Overloading is OK - (great in fact) - but OPERATOR overloading is evil
> because
> it can result in people writing code that leads you to believe you
> understand
> it when in fact you don't.

Hm, that doesn't sound like a problem of the tool, but a problem of the use
of the tool.  Matrices, vector algebra etc are perfect for operator overloading,
no ?  Smart pointers are another example, with built in reference counting
to prevent one of the largest gaps in the C++ language, the mem leaks..
If I'd dismiss every feature in every language I've seen abused by the lesser
coders amongst us... I could probably stick to direct opcode editing :)

> Templates generate code 'behind your back' - and technology of current
> linkers
> an debuggers doesn't make them very stable in practical implementations.

Well, I can't comment on that, but the STL seems to be stable enough for the
Clanlib guys (they're throwing out their Common class set), and so far I never
encountered any troubles with templates either (under VC++)...
I'm not sure why templates would be harder to debug and maintain than a
tenfold implementation of the same functionality, once for integers, once for class
Foo, class Bar, char* etc :^)

Bert
--

-=<Short Controlled Bursts>=-