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.

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. 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? Naively I would like to write: class array : public proto::extends< proto::terminal< array >::type, array > { [...] }; though this is not possible since the extends mechanism makes the expr class a member of the extending class, and thus the class would have to contain itself in the end, which is, of course, impossible. -- --- Daniel Oberhoff Fraunhofer FIT Schloss Birlinghoven 53754 Sankt Augustin, Germany Tel.: +49-(0)-2241-14-3486 Fax.:+49 (0) 2241/14-2080