|
![](/i/fill.gif) |
Christopher James Huff <cja### [at] earthlink net> wrote:
> Argh...forget about virtual functions. They are an artifact of C++,
> which does everything statically by default. I specifically said no
> static binding. No virtual functions, because everything is dynamically
> bound.
What do you mean "no virtual functions"? If every function is dynamically
bound, then *every* member function is virtual.
At least you should be able to specify a default implementation for
a member function or live it as purely virtual.
If you leave all the member functions as purely virtual, then what
you have is an interface.
> > A class is abstract if it has pure virtual functions (that is,
> > the class does not implement the virtual function(s) and thus cannot
> > be instantiated because of this; it can only be used through
> > inheritance so that the derived class implements the virtual
> > function(s) in question).
> Again, I'm talking about single inheritance. Multiple inheritance is not
> necessary, and is needlessly complex.
Who is talking about multiple inheritance here? I'm not.
And multiple inheritance may be complex from the point of view of
the interpreter/compiler, not from the point of view of the user.
Why should that be a limit?
> Abstract classes are not as useful
> in single inheritance models, interfaces cover their functionality.
I don't understand what you are saying.
Why have *two* types of classes when you can have just one?
And why abstract classes are not useful in single inheritance model?
> Interfaces render multiple inheritance + multiple abstract root classes
> obsolete, not the other way around.
Interfaces are a poor way of making multiple inheritance. They have
all the logical problems of multiple inheritance and they force you
to make code repetition.
I have never understood what's so good about interfaces.
> > That's right. *You*. But that's ok only for as long as you don't
> > distribute that library of yours containing public member variables...
> > Someone will inevitably use it in the wrong way and his code can then
> > break with an updated version of the library.
> That's their fault
You can't design libraries with that principle.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
![](/i/fill.gif) |