a wrote:
> 
> Russell Borogove wrote:
> > The only major point I have against your case is that the "no virtuals" restriction on structs seems more arbitrary than the "no member functions" restriction (even though it's not, particularly).
> 
>         Virtual functions and polymorphism in general have a performance and
> memory penalty associated with them.  Member functions are merely an
> organizational tool that helps encourage the development better APIs for
> dealing with a datatype, making the use and maintenance of the type
> safer.

I agree; there's a certain high-level programming mentality that isn't concerned with performance and memory penalties, though, which is why I say that the no-virtuals rule "seems" arbitrary.

> > [1] There's some weak analogy here of the Unix tradition of giving root only the sh shell rather than any of the fancy shells -- you're doing something out of the ordinary, so it's kept deliberately uncomfortable so you stay alert.
> 
>         Funny, my Linux systems gave root bash.  I have a nasty habit of giving
> him tcsh where ever I go.  I probably wouldn't have replied, but I saw
> this statement and it reminded me of C++'s casts.  The committee had the
> same reasoning you did.  I've always felt I and everyone else who has
> had to do a cast in C++ deserved an apology from someone for C++'s
> casts.

Let me clarify that this isn't necessarily _my_ reasoning.

-RB

Russell Borogove wrote:

> You can still encapsulate your struct manipulations, class-wise, using composition instead of inheritance:
>
> struct _hardware_registers_
> {
>    ...
> };
>
> class HardwareAccess
> {
> public:
>    void DiddleSomeRegisters( void );
>    ...
>
> private:
>    _hardware_registers_*   m_Registers;
>    ...
>
> };
>
> This isn't particularly arduous. You can even make the pointer to the registers a class-static if that's advantageous.

Really, there's no reason the compiler can't allow direct inheritance of structs into classes (though obviously not vice-versa).

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Russ Lewis wrote:

> Really, there's no reason the compiler can't allow direct inheritance of structs into classes (though obviously not vice-versa).

	Well, structs are supposed to preserve member organization in memory.
Inheritance would suggest that you are going to preserve that layout so
it can still be passed to function that expect the C layout.  Classes in
D do not promise to preserve to maintain data layout for optimization
reasons.  This type of inheritance would provide a screwy end run around
the optimization.
	Also, most OO infrastructures put some header info (a vtable) in the
class to help with polymorphism.  This could make compiler issues more
complicated that Walter might like.
	Neither of these are show stoppers really, but they seem to fly in the
face of what Walter planned for D.
Dan

a wrote:

> Russ Lewis wrote:
>
> > Really, there's no reason the compiler can't allow direct inheritance of structs into classes (though obviously not vice-versa).
>
>         Well, structs are supposed to preserve member organization in memory.
> Inheritance would suggest that you are going to preserve that layout so
> it can still be passed to function that expect the C layout.  Classes in
> D do not promise to preserve to maintain data layout for optimization
> reasons.  This type of inheritance would provide a screwy end run around
> the optimization.
>         Also, most OO infrastructures put some header info (a vtable) in the
> class to help with polymorphism.  This could make compiler issues more
> complicated that Walter might like.
>         Neither of these are show stoppers really, but they seem to fly in the
> face of what Walter planned for D.

From a theorhetical programmer sense (where I normally come from), you're right. However, in a technical sense I don't think it's a problem.  My understanding is that in inheritance, the base class is included into the derived one as a complete, intact element.  Then the various additional member variables and vtable entries would be added around it.  In that sense, it's no problem to derive classes from structs.  The compiler includes the struct as-is, directly as a (unnamed) member of the class. Accesses to its data (or member variables) access the member struct variable; others (declared by the class) obviously access other elements of the class.

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Russ Lewis wrote:
> This is an interesting point.  Removing virtuals means that there is no need for a vtable...thus, adding member functions adds to the functional code in the compiled image, and does not interfere with struct's binary-mapping nature.

Ah, here's the thing we were overlooking: all member functions are virtual in D. Obviously, that rule could be altered for struct, but at the cost of complicating the language definition.

-RB