www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - No struct extending?

reply Steve Horne <stephenwantshornenospam100 aol.com> writes:
In C++, 'struct' is (almost) a synonym for 'class'. More a declaration
of intent than a different thing. One useful side-effect of this is
that you can declare structs as extensions of other structs. This can
be useful even for plain-old-data. e.g. data structures with several
node types, but some shared fields. Inheritance doesn't always imply
virtual tables and stuff.

Of course you can handle this using...

  struct s_Branch
  {
    s_Common m_Common;

    ... (branch specific stuff)
  }

But all that 'pointer.m_Common.actual_member' is a pain.

Adding a union...

  union u_Variant
  {
    s_Common m_Common;
    s_Branch m_Branch;
    s_Leaf   m_Leaf;
  }

just means you have to specify 'm_Branch' or 'm_Leaf' for the
non-shared fields too.

Anonymous structs and unions can save on these extra dots and
identifiers, but they do a different job. They can't give you a family
of structs. Only a single struct/union combo - a variant record.

Plus, one thing I have in mind is templates that build up in layers
(mix-in layers pattern), and there will be an arbitrary number of
extensions applied. For example, if you want ordered keys, you apply
the 'gimme-keys' template as a mixin layer, and it extends whatever
structures, classes and methods it needs to.

This can still be handled - you just compose an access class in
parallel along with the structs. But it's a hassle.

Now, truth told, this mix-in layers bit isn't important. 'static if'
probably means I'm better off specifying things using mix-in layers
(setting up flags and aliases), but putting most of the final code in
one big template. It will be a lot more readable and maintainable that
way. The mix-in layers pattern is then mostly a way of avoiding having
too many parameters for one template.

I could use a D mixin to define the common fields, of course. And
whatever approach I take, there's pointer casting based on the
run-time type so that's not a big deal, though the C++ approach is
nice in that casting to the 'base struct' is implicit.

What bothers me is the chance of this happening...

  struct c_Common
  {
    mixin(common fields)
  }

  struct c_Leaf
  {
    int m_Misplaced_Field;  //  whoops!
    mixin(common fields)
  }

Or, for that matter, the same just using nested structs.

  struct s_Branch
  {
    int      m_Misplaced_Field;  //  whoops!
    s_Common m_Common;
  }

That is, there is no rule forcing the shared part into matched
locations in all structures, so when you do the union/pointer
casts/whatever you can end up looking at the wrong memory.

So - am I being paranoid?

It's a small thing, especially given the amount of work that D has
already saved me. And I'm not even convinced it's real. The node
layouts above, for instance, will all be part of the same module and
maintained together anyway. The odds of a misplaced field like that
should be next to zero, and the same probably applies in any family
tree of related structs.

I just thought I'd raise it and see what others think.

-- 
Remove 'wants' and 'nospam' from e-mail.
Sep 08 2006
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Steve Horne wrote:
 In C++, 'struct' is (almost) a synonym for 'class'. More a declaration
 of intent than a different thing. One useful side-effect of this is
 that you can declare structs as extensions of other structs. This can
 be useful even for plain-old-data. e.g. data structures with several
 node types, but some shared fields. Inheritance doesn't always imply
 virtual tables and stuff.

I can imagine that such a feature could be useful indeed. However, the approach you propose has a caveat. 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 class Qwert : Yuiop or enum Asdfg : int you can keep any Qwert in a variable of type Yuiop, or any Asdfg in a variable of type int, without losing any information. This won't be true of structs if we did what you're suggesting. Of course, it would at least make sense to somebody coming from a C++ background. But it will be necessary to know whether something's a struct or a class in order to be sure whether converting it to the base type would lead to loss of data. <snip>
 Adding a union...
 
   union u_Variant
   {
     s_Common m_Common;
     s_Branch m_Branch;
     s_Leaf   m_Leaf;
   }
 
 just means you have to specify 'm_Branch' or 'm_Leaf' for the
 non-shared fields too.

In a union? Doesn't seem to make sense. But an idea would be to have a means whereby a defined struct can be used as an anonymous struct. It would also be handy if a struct instance could be both anonymous and named, if you know what I mean. But you remind me of an idea I've had for a while, which is being able to derive a union from a union or struct. This would be used to wrap a structure from an external API and give it methods or alternative views of the data. 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.
Sep 08 2006
parent reply Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Fri, 08 Sep 2006 20:20:29 +0100, Stewart Gordon
<smjg_1998 yahoo.com> wrote:

Steve Horne wrote:
 In C++, 'struct' is (almost) a synonym for 'class'. More a declaration
 of intent than a different thing. One useful side-effect of this is
 that you can declare structs as extensions of other structs. This can
 be useful even for plain-old-data. e.g. data structures with several
 node types, but some shared fields. Inheritance doesn't always imply
 virtual tables and stuff.

I can imagine that such a feature could be useful indeed. However, the approach you propose has a caveat. 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.
     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. 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? It's not just C++ oriented thinking. It's a wider issue, in principle. Call it database-style object orientation. An object oriented database basically provides heirarchies of related record structures, after all.
In a union?  Doesn't seem to make sense.

I'm saying that every time I access a field, I have to specify a qualifier for each layer... pointer.m_Branch.m_Field instead of... pointer.m_Field Nothing profound or anything - just saying that while anonymous unions can be used to get variants without needing extra qualifiers, it doesn't help in this case.
But an idea would be to have a means whereby a defined struct can be 
used as an anonymous struct.  It would also be handy if a struct 
instance could be both anonymous and named, if you know what I mean.

Kind of. Like using 'mixin' with a struct as the source instead of a template. Could be handy. But in the cases I have in mind, that's just a minor shorthand to one of the options I described anyway - mixin the base struct itself, rather than defining a separate template and mixing that into all structs. It doesn't tell the compiler anything new about my intent. In itself.
But you remind me of an idea I've had for a while, which is being able 
to derive a union from a union or struct.  This would be used to wrap a 
structure from an external API and give it methods or alternative views 
of the data.

Maybe. Actually, scratch all the inheritance stuff. It's just a special case of another requirement anyway, with structs. Aligning members. Not in the 'alignof' sense, but in terms of field positioning. Perhaps if I could write... struct s_Branch { at 0: s_Common m_Common; } Still have the dotted qualifiers to deal with, but that's just a minor irritation. The point is that the qualifier has this declaration of intent - where the embedded field should be. 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. 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? And then, how about something like... group (x, y) { struct s_Block_1 { at x : int32_t m_1; int32_t m_2; at y : float m_3; } struct s_Block_2 { at x : int32_t m_1; float m_2; at y : float m_3; } } That is, the (presumably in-memory-only) structs have common parts which must be at the same offset in each struct, but not specifying an exact location. Each 'at' offset would be set to the minimum value possible given the field sizes and alignment. And there'd be no possibility of packing later fields into earlier gaps, on the principle of least surprise. Another approach might be same-field-name-implies-same-offset within a group of structs. This is, of couse, in the field of obscure requirements and long-term possible futures. But an explicit field position sounds more immediately useful. -- Remove 'wants' and 'nospam' from e-mail.
Sep 09 2006
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Steve Horne wrote:
 On Fri, 08 Sep 2006 20:20:29 +0100, Stewart Gordon
 <smjg_1998 yahoo.com> wrote:

 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?

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.
Sep 09 2006
parent Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Sat, 09 Sep 2006 23:58:34 +0100, Stewart Gordon
<smjg_1998 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?

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.
Sep 10 2006
prev sibling next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Steve Horne wrote:
 In C++, 'struct' is (almost) a synonym for 'class'. More a declaration
 of intent than a different thing. One useful side-effect of this is
 that you can declare structs as extensions of other structs. This can
 be useful even for plain-old-data. e.g. data structures with several
 node types, but some shared fields. Inheritance doesn't always imply
 virtual tables and stuff.
 
 Of course you can handle this using...
 
   struct s_Branch
   {
     s_Common m_Common;
 
     ... (branch specific stuff)
   }
 
 But all that 'pointer.m_Common.actual_member' is a pain.
 
 Adding a union...
 
   union u_Variant
   {
     s_Common m_Common;
     s_Branch m_Branch;
     s_Leaf   m_Leaf;
   }
 
 just means you have to specify 'm_Branch' or 'm_Leaf' for the
 non-shared fields too.
 
 Anonymous structs and unions can save on these extra dots and
 identifiers, but they do a different job. They can't give you a family
 of structs. Only a single struct/union combo - a variant record.
 
 Plus, one thing I have in mind is templates that build up in layers
 (mix-in layers pattern), and there will be an arbitrary number of
 extensions applied. For example, if you want ordered keys, you apply
 the 'gimme-keys' template as a mixin layer, and it extends whatever
 structures, classes and methods it needs to.
 
 This can still be handled - you just compose an access class in
 parallel along with the structs. But it's a hassle.
 
 Now, truth told, this mix-in layers bit isn't important. 'static if'
 probably means I'm better off specifying things using mix-in layers
 (setting up flags and aliases), but putting most of the final code in
 one big template. It will be a lot more readable and maintainable that
 way. The mix-in layers pattern is then mostly a way of avoiding having
 too many parameters for one template.
 
 I could use a D mixin to define the common fields, of course. And
 whatever approach I take, there's pointer casting based on the
 run-time type so that's not a big deal, though the C++ approach is
 nice in that casting to the 'base struct' is implicit.
 
 What bothers me is the chance of this happening...
 
   struct c_Common
   {
     mixin(common fields)
   }
 
   struct c_Leaf
   {
     int m_Misplaced_Field;  //  whoops!
     mixin(common fields)
   }
 
 Or, for that matter, the same just using nested structs.
 
   struct s_Branch
   {
     int      m_Misplaced_Field;  //  whoops!
     s_Common m_Common;
   }
 
 That is, there is no rule forcing the shared part into matched
 locations in all structures, so when you do the union/pointer
 casts/whatever you can end up looking at the wrong memory.
 
 So - am I being paranoid?
 
 It's a small thing, especially given the amount of work that D has
 already saved me. And I'm not even convinced it's real. The node
 layouts above, for instance, will all be part of the same module and
 maintained together anyway. The odds of a misplaced field like that
 should be next to zero, and the same probably applies in any family
 tree of related structs.
 
 I just thought I'd raise it and see what others think.

I suspect this is a perfect case of the Square Triangle. Happens to me too. The solution sought being just a notch off the problem, concepts fighting for neurons, and the goal but a mirage, elusive and yet so tempting. And then of course, I may be misunderstanding the whole issue, for all I know. Anyway, as I understood it, you have struct instances (from somewhere, like a C library routine or a file, etc., let's call them ForeignInstances) and you need to glue some new fields to them so that you can process them without needing to write reams of code that keeps track of what YourProperties belong to which item. And this has to work with several (more or less) different, but still conceptually related kinds of ForeignInstances. One could use a concoction of templates, mixins, unions and inheritance to create a module (or a library) which then lets one handle the situation simply and cleanly in main code. (Either in current D, or after Walter makes some needed tweaks.) Carefully writing the module would let one be reasonably sure that the fields align right, maybe even have suitable dynamic and/or static checks and asserts, to (almost) enforce integrity. The end result, or the goal, being that one ends up with in-memory (let's call them) prints, the beginning of which is exactly the same as in YourProperties and the rest the same as ForeignInstances. Having got this far, one can then use functions from the module to handle the non-instance-type-specific manipulation of the ForeignInstances. Presumably one would either already have, or else write specific routines to do all the actual instance type specific stuff (mostly access and assignment). You make it more difficult by bringing up the issue of physical field alignment. (See http://en.wikipedia.org/wiki/Fragile_binary_interface_problem which incidentally is on a wrong page(!!) since it discusses the Fragile Base Class problem. Oh well.) I suspect you wanted to have all this more ambitious? Like having several alternate sets of YourProperties (and of course matching code sets), so that each set could be used for a different purpose, like sorting, selecting, serializing, combining, printing, etc. of the "prints". --- If I got a task like this, I'd probably do it a lot simpler. First, these ForeignInstances have to enter our process somehow. At that point we either have to recognize the specific type of each, or we know it from the context. In both cases, if we wanted to "slap on" our own fields to them, we need to copy them somewhere else in memory. (If we only have a couple of such instances coming one at a time all this effort is a waste, and if they come from a stream or a file then they're too near each other to have room for our fields anyhow.) Thus, one of the main points of physically having our own fields attached to the ForeignInstances disappears: speed. And with sorting, unless they're very small, it will be more practical to sort linked lists of just pointers to them. So it seems some of the performance wins just vanish. The other point for having our and their fields together was "kinda integrity", in other words, we wouldn't have to separately keep track of our and their data. Now, from above, it seems that having our and their data together at all times may actually incur more work for us than more traditional programming. This all means we simply have to have routines for import and export. Now, the issues of machine word width and endianness, only exist when carrying the data (or porting the program) between different architectures. As to the data, simply exactly specifying the record layout takes care of both word size and endianness. (Hey, a .gif file is a .gif file no matter what computer you have.) As to within the program, as long as we access the fields with their names (as opposed to bit twiddling), we're okay. The process of importing or exporting converts between the "file format" and our internal representation (whatever it may be), and that process is where endianness and word size are take care of. Implementation I'd start with simple textbook OO. We (feel entitled to) assume that the various ForeignInstance types do have much in common. This automatically suggests a Base Class that has methods to store, retrieve and manipulate the common fields. It would also have abstract methods that cater for what has to be done with the instance type specific fields, more or less constituting an interface specification in reality. Each ForeignInstance subtype would then just be a sublclass of this base class, implementing only the specifics. Instances of these could then be stored in data structures (arrays, lists, trees) and referenced to as the base type. Thanks to polymorphism, we could then "just use" these instances without worrying which specific type each is. We'd also get adequate performance, without even trying. Clear, concise and KISS. Oh, and way more robust and maintainable. Ok, your original issue (as I understood it anyway) was not one of practical implementation, rather a (in itself very intriguing) thoughlet about the relationship of mixins, structs and their manipulation, both in source code and at runtime. My point (and I apologize) was merely that I can't see a suitable problem for your solution. :-)
Sep 11 2006
parent reply Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Mon, 11 Sep 2006 15:45:19 +0300, Georg Wrede
<georg.wrede nospam.org> wrote:

I suspect this is a perfect case of the Square Triangle. Happens to me 
too. The solution sought being just a notch off the problem, concepts 
fighting for neurons, and the goal but a mirage, elusive and yet so 
tempting.

Hopefully. I mentioned elsewhere that I'm chasing my own tail, refactoring to try to get my interface use patterns to be sane. Not familiar enough yet with having that tool, and not having multiple inheritance. Doesn't mean D is bad. Just means the paradigms need to shift around a bit yet before they stabilise.
Anyway, as I understood it, you have struct instances (from somewhere, 
like a C library routine or a file

No. I need struct instances. The posts have created a bit of haze, since I have covered a bunch of vaguely related issues, but I have one specific application in mind right now which is why I kept going on about branch nodes and leaf nodes. I'm working on a multiway tree container library. The tree has to be able to live in a disk file. Think of it as a database index. Since the basic data structure is essentially a B+ tree, there are two types of nodes - branch and leaf - which share some fields in common. As far as disk blocks are concerned, each block holds one node and in effect uses a union. When a node is read back from the disk, fields in the common part are used to determine the node type. It's an everyday kind of pattern when dealing with file formats and network protocols, as well. Families of block types. Families of message types. There are applications where remoting features can remove the need (server side objects and the like), but someone still has to implement the remoting protocols that achieve this. So I'm building from scratch, but I still have a family of structs that have to be structs. It may seem inappropriate in that there is an apparent polymorphic type, but the compiler cannot resolve the polymorphism for me. The 'struct extending' title comes via two routes. The lesser route is that the leaf nodes and branch nodes are both extensions of the core node. But the more important route came from the idea of using of a mix-in layers pattern to 'compose' the functionality I want. "Mix-in layers" is a template pattern. You basically add features one at a time to what you need. You get to say what requirements you have, and you don't get the overhead from features you don't need. Third parties can even create their own mix-in layers to add support for new features, without needing to start from scratch. The requirements crosscut multiple classes etc. So, in principle, you get to order a library with the options you want - "gimme a multiway tree with ordered keys and efficient subscripting support, hold the non-key data and persistable intelligent iterators. Here's an interface you can use to shove the nodes into a disk file, but there's more than one tree sharing space in the file so I'll handle the free list." kind of thing. There are a few papers available on mix-in layers in C++ - google for Yannis Smaragdakis and Don Batory. They're a lot easier in D because the template support is better. Crosscutting features seem to be a big thing at the moment - aspect orientation is another expression of this, and there are versions of Java and C++ with aspect support.
One could use a concoction of templates, mixins, unions and inheritance 
to create a module (or a library) which then lets one handle the 
situation simply and cleanly in main code.

Overkill. All the struct layouts are known in advance, and the polymorphism is resolved using ordinary data fields in the common part. All I need is a set of small access functions... int Get_Branch_XXX (s_Node_Base* p_Node) { if (Is_Branch (p_Node)) { return (cast(s_Node_Branch*) p_Node).m_XXX; } throw new Exception ("XXX not available for this node."); } Even that's overkill. I'd rather do a one-shot check-and-cast pointer type conversion in most core functions, so the checks don't repeat. Actually, just realised I'm being stupid. Will post the 'easy way' solution separately, once I've checked whether it works.
Now, the issues of machine word width and endianness, only exist when 
carrying the data (or porting the program) between different 
architectures.

Yes, but it is a potential issue for me, and an awkward one, since code can be compiled for multiple platforms and files exchanged between platforms, but my library is inherently generic. It can handle fields that it puts in the nodes (size, flags, child pointers etc) but it doesn't necessarily understand much more about key or data items than how to copy and compare them. It's a 'once the thing works on one platform I'll deal with this' kind of issue. I might even delegate the responsibility to users, along with the 'make sure you only store plain-old-data' thing. Probably I'll have some kind of callbacks called when nodes are read or written, though - kind of 'I don't know how to fix your data, but endian fixes and conversions are needed now'.
 As to the data, simply exactly specifying the record 
layout takes care of both word size and endianness.

No it doesn't, since there is no pre-existing import/export to delegate this task to. I'm writing a low level library, not using a pre-existing one. Any bit twiddling needed is my responsibility, not someone elses.
Implementation I'd start with simple textbook OO.

Yes. That's what I want to do. I just _CANNOT_ use compiler-managed polymorphism for this. Handling the polymorphism has to be my responsibility rather than the compilers, otherwise I'd just use classes. But in principle, inheritance can be useful even without polymorphism. Just as encapsulation can be useful without polymorphism or else why do D structs support methods?
Clear, concise and KISS. Oh, and way more robust and maintainable.

If only it was relevant to the job ;-) -- Remove 'wants' and 'nospam' from e-mail.
Sep 11 2006
parent Steve Horne <stephenwantshornenospam100 aol.com> writes:
OK - I have my solution. It's not perfect, but it's easy enough and
it's good enough.

For the branch nodes and leaf nodes and their common part, the branch
and leaf node can just use property getter/setter functions to give
shorthand access to the shared parts. This didn't occur to me before
because I resist adding methods to structs.

It still doesn't handle the mix-in layers issue, though. I don't know
which layers were mixed in previously, so I can't know which shortcuts
to provide.

But I can say that each member is always at the same offset in a
struct, once the struct is composed, even if that struct gets further
extensions. Non-member functions can take void pointers to the
buffers. They can be passed down through mix-in layers using the
'mixin' keyword...

  template t_Keys_Mixin_Layer (alias PL, class c_Key)
  {
    mixin PL;  //  Mix in definitions from previous layer

    struct c_Leaf
    {
      PL.c_Leaf               m_Previous;
      c_Key[PL.m_Array_Size]  m_Keys;
    }

    c_Key[] Node_Keys (void* p_Node)
    {
      if (Node_Is_Leaf (p_Node))  //  Defined in previous layer
      {
        c_Leaf* l_Leaf = cast(c_Leaf*) p_Node;

        //  Don't know what previous layers defined - depends which
        //  layers the user decided to mix in - but doesn't matter
        //  since I know what is needed now...

        return l_Leaf.m_Keys;
      }

      throw new Exception ("Node is not a leaf");
    }
  }

-- 
Remove 'wants' and 'nospam' from e-mail.
Sep 11 2006
prev sibling parent reply Argon 7 <sadjuuk homeworld.haigara.com> writes:
I think it would be cool if you could convert
a D struct to a D class and a D class to a D struct and vice versa.
Sep 15 2006
parent Mike Parker <aldacron71 yahoo.com> writes:
Argon 7 wrote:
 I think it would be cool if you could convert
 a D struct to a D class and a D class to a D struct and vice versa.

That would serve no purpose. Choosing which to use is a design decision, not a runtime decision.
Sep 15 2006