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