"Robert W. Cunningham" wrote:
> I would advocate using C++ at *least* as "a better C". Maybe even use
> "light-weight" classes: They would provide a convenient means to bundle
> structs and functions - but we would have to avoid implicit constructors
> and destructors (explicit is fine), no multiple inheritance (and
> probably not even single inheritance), no C++ exceptions, no virtual
> functions (and thus no vtables), and certainly no RTTI. This means that
> STL and similar class libraries are gone as well.
I do like some of the asthetics you get with very light-weight use
of C++. If we want some parts of code (especially the device emulation)
to potentially interface in monitor space, it has to be C.
There are some real design flaws in C++. For example, the 'this'
pointer, passed as an implicit 1st arg to functions. Envision
the following scenario. You want to have a class, which handles
something that is done on the order of a million Hz. So you
certainly don't want to be pushing that damn this pointer all
the time. OK, so you make all the class functions static, so
and then the compiler doesn't emit the 'this' pointer push,
but expects class data accesses to be prefixed with the
actual instance name.
So how do you code this, so that in one high-performance
case you don't have the 'this' pointer pushed. But perhaps
in a lower performance case, you have more than one
instance (like cosimulation in bochs where you have 2 CPU
simulations running head-to-head), in which case the 'this'
pointer is necessary and not so much of a problem.
// high performance case: all static member functions
void
some_class:some_function(unsigned a)
{
some_instance.xyz = a;
}
// low performance case: this pointer available
void
some_class:some_function(unsigned a)
xyz = a;
-or-
this->xyz = a;
}
Had the C++ designers thought of this, they could have easily
added a directive that would let you bind a specific instance
name to the class for the static case. The address of that
instance would then effectively be the 'this' pointer. And
no nasty #define hacks would be necessary.
Handling high performance callbacks suffers similar problems.
I remember from my days of reading through the Stroustrup book
and even taking a C++ class, there were some real _major_
f*#! ups in the design, but they were all in features you talk
about eliminating.
But, rather than go into a rant about C++, I leave off with the
following quote"
"C makes it easy to shoot yourself in the foot. C++ makes it harder,
but when you do, it blows away your whole leg." - Bjarne Stroustrup
-Kevin
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Kevin Lawton [EMAIL PROTECTED]
MandrakeSoft, Inc. Plex86 developer
http://www.linux-mandrake.com/ http://www.plex86.org/
