Daniel Oberhoff wrote:
Daniel Oberhoff a écrit :
I might have gotten the terms wrong. But the way I got it working now is with using proto::lit which turns things into literals. I tried subclassing terminal with my array class, but that way the tree did not keep a reference to the array, and thus could not be evaluated as such.
Just make a array_data class that contains your data and make your user level array class extends terminal
::type. The vec3 example in the doc is exacly this and I used variations of this for like 4 or 5 array like DSEL since proto is available.
Right.
Ok, I looked into that. Works better than my previous approaches. Though I would like it much better if I don't have to split my class into an internal data class and a user interface, since I would like to use the whole interface in the proto evaluators.
Can you give me an example of where this complicates your implementation?
Also, since the extends mechanism makes the data class end up a member of the derived class it is hard to access the derived class from the base class. Is this fundamentally impossible?
I don't know. What are "base" and "derived" referring to in the above paragraph? -- Eric Niebler BoostPro Computing http://www.boostpro.com