No struct extending?

Steve Horne stephenwantshornenospam100 at aol.com
Sun Sep 10 02:58:58 PDT 2006


On Sat, 09 Sep 2006 23:58:34 +0100, Stewart Gordon
<smjg_1998 at yahoo.com> wrote:

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

Next you'll be telling me that apes, dolphins, bats and platypusses
etc aren't mammals, because 'mammal' is just the tiny little bit that
the various types have in common. After all, none of those is a
D-style class either ;-)

There's no reason why shared characteristics shouldn't be limited to
shared member fields in a family of struct layouts, if that's what
happens to be useful. Inheritance is an abstract concept - an idea, a
metaphor. It is not a specific implementation.

Anyway, in D, structs already have one object-oriented feature. They
have encapsulation. They allow member functions.

Personally, if roles reversed, this is exactly where I'd go on the
attack...

"""
With inheritance and methods, you're most of the way to C++ classes!
If you inherit methods, you need to make sure that they still make
sense. That means overriding. And now we have to worry about late
binding and virtual tables. Hell, why not just add multiple
inheritance and virtual inheritance and be done with it!!!!
"""

But methods aren't a fundamental feature of structs. Supporting member
functions is a convenience - a shorthand and a bit of encapsulation.
So why not take the same view as if those functions weren't members at
all? If you don't inherit the methods and you don't allow casting,
they can't do any damage.

Of course there are details, but there's always details. Is it useful
in D? That's the question. I'll put you down as a "no" ;-)

>without any data loss involved in the assignment operation.

I never said there should be an implicit cast between related struct
types. I never said that D should be C++.

>> 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.

I've seen a lot of documentation that give offsets and sizes for
fields within blocks. When you code that, it's easy to make a mistake.
If the offsets were explicit in the code, it would be even easier to
be sure you'd got it right.

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

IEEE 754.

Even if the D spec doesn't guarantee it, it's a fairly safe bet most
of the time. And in any case...

>  As is 
>endianness....

So no-one should ever write an endian-swap function - after all,
struct layouts are platform dependent anyway.

Damn - I broke that law too ;-)

-- 
Remove 'wants' and 'nospam' from e-mail.



More information about the Digitalmars-d mailing list