No struct extending?

Stewart Gordon smjg_1998 at yahoo.com
Sat Sep 9 15:58:34 PDT 2006


Steve Horne wrote:
> On Fri, 08 Sep 2006 20:20:29 +0100, Stewart Gordon
> <smjg_1998 at yahoo.com> wrote:
<snip>
>> The problem is that the extending concepts currently in D - class 
>> inheritance, interface implementation and enum base types - satisfy the 
>> "is a" relationship.  Basically, given
> 
> branch_node isa node
> leaf_node   isa node
> 
> The common part only represents what is associated with node-ness, as
> opposed to specifically branch-nodeness or leaf-nodeness.

But a branch_node isn't a node, if a node is only the little bit that 
two or more types have in common.

>>     class Qwert : Yuiop
> 
>> you can keep any Qwert in a variable of type Yuiop
> 
> Not quite. You can reference any Qwert from a variable of type Yuiop.
> That implicit reference is important. Convert the instance itself and
> you lose data.

It isn't important to the point I am making.  What I basically mean is 
that you can do

     Yuiop asdfg;
     ...
     Qwert hjkl = asdfg;

without any data loss involved in the assignment operation.

> And the kinds of run-time type resolution or binding are exactly the
> same as for nodes. I have to check before downcasting a pointer. You
> have to check before downcasting a reference. You just have some
> built-in compiler support, of course - I'm just working in the
> abstract sense of a heirarchy or classes, as opposed to the specific
> sense supported by this language.
> 
> Branch-node isa node. Why shouldn't that relationship be known to the
> compiler?

I'm not sure what you mean here....

<snip>
> And then of course...
> 
>   struct s_Branch
>   {
>     at 0: mixin (s_Common);  //  s_Common being a struct
>   }
> 
> Now we're getting somewhere!
> 
> Each 'at' clause would be a signal to either add whatever padding to
> the struct is needed, or to report an error if that offset has already
> been passed.

Hmm....

> Could be useful for general file/protocol layout stuff anyway. It can
> be easy to mess up with 'align', for instance. Especially if the
> default align size platform dependent?
<snip>

It probably is.  But if you make sure the alignment of a struct is fully 
specified, when this matters, then you should be OK.

Except that the size of a real is also platform dependent.  As is 
endianness....

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- 
PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.



More information about the Digitalmars-d mailing list