www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Struct polymorphism?

reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
  As I'm looking over the bottlenecks in speed and useage I'm 
finding that classes are much too bulky for the subrecords I'll 
be needing. This poses a problem. The average subrecord is 
something like 64bytes, and the data structure for the class by 
itself is over 300 (last I saw somewhere), plus the virtual table 
and declared variables. Keep in mind I'll likely be working with 
well over 400,000 entries, so memory and speed become an issue 
the larger this scales up with classes. (My tests on a 80Mb input 
file became over 500Mb and took a while to load)

  As I'm thinking about this, I wonder if I can trim that to a 
minimum. Let's consider this (posted on another forum as notes 
mostly):

[code]
enum Type { normal, FRMR, LAND }
struct SubRecord {
   Type polyMorph;

   //other data
   string generateID();
}

struct FRMR {
   SubRecord root;
   alias root this; //subtyping

   //no new data is added, only methods/behavior

   string generateID() { //overrides original subrecord's
          //generate string
          //or if i use root.generateID(), i get the original
          return "";
   }
}
struct LAND {
   SubRecord root;
   alias root this; //subtyping
}

  union {
    SubRecord subrecord;
    FRMR frmr;
    LAND land;
  }

  subrecord.generateID(); //legal
  if (subrecord.polymorph == Type.FRMR)
    frmr.generateID(); //get FRMR behavior at no cost!
  if (subrecord.polymorph == Type.LAND)
    frmr.generateID(); //get FRMR behavior at no cost!
[/code]

  Now as long as you're willing to check for individual subrecords 
(and there's only 5 or so so it isn't a huge issue), but growth 
to polymorphism quickly could escalate it to be large and 
annoying. To make it truly poly-morphic then perhaps the 
following.

[code]
  struct SubRecord {
   Type polymorph;

   string generateID() {
     if (polymorph)
           return polymorphed!(polymorph, "generateID");

     string ID;
     //generate normal SubRecord ID
     return ID;
   }

   auto polymorphed(poly, string call, Vars[] ...)() {
     string typeName; //convert somewhere in here.

     mixin("return (cast(" ~ typeName ~ ") this)." ~ call ~ "(" ~ 
Vars ~ ");");
   }
  }
[/code]

  now I'm sure the template calling is likely wrong (as poly's 
value is runtime), but re-arranging it so it separates out the 
enums at runtime and then calls static versions of them you can 
get the wanted effect.

  Now assuming you get the code above working then...

[code]
   SubRecord sr, sr2;

   sr2.Type = Type.FRMR;

   sr.generateID();
   sr2.generateID(); //FRMR version! Minimal cost!
[/code]


  Thoughts? Ideas? Does this seem feasible? Potential issues down 
the road? I'll be experimenting to see if I can indeed do this. 
If someone is already done or failed at this I wouldn't mind 
reading their attempts on it.
Oct 06 2012
parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
  Perhaps someone can help explain this mystery. I've got a 
working system, except when it's coming to an unknown function 
inside my structs.

  Perhaps to note opDispatch is added via a mixin template, not 
sure if that makes a difference.

Error: function expected before (), not 
'this.polyBase.opDispatch!("orig")'

   struct Base {
     PolyMorph polyBase;
     alias polyBase this;

     string callsOrig() {
       return orig(); //dies here
     }
   }

   //opDispatch signature
   auto ref opDispatch(string fun, Args ...)(auto ref Args args);
Oct 08 2012
parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Monday, 8 October 2012 at 15:23:58 UTC, Era Scarecrow wrote:

 Error: function expected before (), not 
 'this.polyBase.opDispatch!("orig")'


   I think this is a compiler bug. It complains about calling 
opDispatch, however it doesn't complain if you explicitly call 
'this'. Should adding 'this' be required? I am using the 
-property switch so it's a little more strict, but that doesn't 
seem to change the results. I can't just start adding 'this' to 
all my function as outside normal functions/variables won't ever 
be seen.

struct S {
   Something polyBase;
   alias polyBase this;  //opDispatch

   string callsOrig() {
     return orig;        //works but misleading
     return orig();      //breaks
     return orig(1);     //breaks too
     return this.orig(); //works
   }
}

struct Something {
   auto ref opDispatch(string fun, Args ...)(auto ref Args args) 
 property;
}

   My experiments concentrating on this part rather than with 
arguments, those will come later when this works.
Oct 08 2012
next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 10/08/2012 03:19 PM, Era Scarecrow wrote:

 On Monday, 8 October 2012 at 15:23:58 UTC, Era Scarecrow wrote:

 Error: function expected before (), not
 'this.polyBase.opDispatch!("orig")'


 I think this is a compiler bug. It complains about calling opDispatch,
 however it doesn't complain if you explicitly call 'this'. Should adding
 'this' be required?


I don't know all of the design decisions behind opDispatch, but I would 
be happier to have to type "this." when inside the struct. Otherwise, 
any struct that defined opDispatch would miss out on compiler's static 
name checking.

What if orig() has actually been a mistyped free-standing function name? 
Being forced to type this.orig() makes it explicit. And to me, this 
seems even better:

     return polyBase.orig(1);


 I can't just
 start adding 'this' to all my function as outside normal
 functions/variables won't ever be seen.


Sorry, I can't understand the problem that you describe in that sentence.

Ali
Oct 08 2012
parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Monday, 8 October 2012 at 22:57:04 UTC, Ali Çehreli wrote:

 I don't know all of the design decisions behind opDispatch, but 
 I would be happier to have to type "this." when inside the 
 struct. Otherwise, any struct that defined opDispatch would 
 miss out on compiler's static name checking.

 What if orig() has actually been a mistyped free-standing 
 function name? Being forced to type this.orig() makes it 
 explicit. And to me, this seems even better:

     return polyBase.orig(1);


  Yes likely this is what will happen.. Just seems like it isn't 
needed.


 I can't just start adding 'this' to all my function as outside 
 normal functions/variables won't ever be seen.


 Sorry, I can't understand the problem that you describe in that 
 sentence.


  Hmmm added a this.writeln() and it worked fine without calling 
opDispatch. How odd. Still seems like a compiler bug to me.

  The idea behind that i'm experimenting with is in reality the 
struct contained two functions. So..

struct S {
   Something polyBase;
   alias polyBase this;  //opDispatch

   string orig() {
     return "some string";
   }

   string callsOrig() {
     return orig();
   }
}

  With that everything is happy. Now if I rename orig to 
Poly_orig, then callsOrig complains and the issue comes up. The 
polyBase will check among the rules it has and adds Poly_ to the 
functions while it's checking them (among other ones), before 
finally calling S.Poly_orig() with all it's arguments.

So it will look something like this.

struct Data {
   string msg;
}
struct Something {
   Data data;  //shared data
   auto ref opDispatch(string op, Args ...)(auto ref Args args) {
     static if (op == "orig") {
       return (cast(S) data).Poly_orig();
     } else {
       static assert(0, op ~ " - Not found"); //205
     }
   }
}

struct S {
   Something polyBase;
   alias polyBase this;  //opDispatch

   //string orig() {    //statically assigned
   string Poly_orig() { //opDispatch calls now
     return "some string";
   }

   string callsOrig() {
     return orig(); //220
     return this.orig();
     return polyBase.orig();
   }

   string oddball() {
     //asserts can't find blarg or Poly_blarg in opDispatch
     return blarg();  //227
     return this.blarg(); //228
   }
}

test.d(220): Error: function expected before (), not 
'this.polyBase.opDispatch!("orig")'
test.d(227): Error: function expected before (), not 
'this.polyBase.opDispatch!("blarg")'
test.d(205): Error: static assert  "blarg - Not found"
test.d(228):        instantiated from here: opDispatch!("blarg",)

   I'd rather have where once I get my code debugged for a struct 
that I don't have to suddenly add this. or polyBase to all my 
functions after I rename the functions to Poly_. If it's a 
necessary evil than I'll accept it.
Oct 08 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-09 00:19, Era Scarecrow wrote:


    I think this is a compiler bug. It complains about calling
 opDispatch, however it doesn't complain if you explicitly call 'this'.
 Should adding 'this' be required? I am using the -property switch so
 it's a little more strict, but that doesn't seem to change the results.
 I can't just start adding 'this' to all my function as outside normal
 functions/variables won't ever be seen.


As far as I understand it, opDispatch needs a receiver, i.e. this.foo() 
or obj.foo(). I asked the same question a while ago and got that answer, 
it's by design.

-- 
/Jacob Carlborg
Oct 08 2012
parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Tuesday, 9 October 2012 at 06:53:54 UTC, Jacob Carlborg wrote:

 As far as I understand it, opDispatch needs a receiver, I.e. 
 this.foo() or obj.foo(). I asked the same question a while ago 
 and got that answer, it's by design.


  I've also tried adding a opDispatch in the same struct and the 
error still comes up. Guess it doesn't qualify opDispatch as 
known at compile-time unless you explicitly say so.

  Mmm.. I'm not satisfied with that, but it's a lesser evil we can 
live with.
Oct 09 2012
parent "mysyljr" <805600352 qq.com> writes:
It's having possibilities,I mean polymorphism for struct,and
without a enum declaring thus it can be more scalable if you
should use virtual call in a delegate class,cause it's just what
virtual call is designed for.Since you record the Type all the
time,you get rid of virtual call but lose scalability.I'm
interesting in struct polymorphism because I can choose no
virtual call when no runtime polymorphism is needed but not when
I need
Mar 15 2013