Well, I spent the past few hours today trying to hack something together, and have run into a few issues.<br><br>After adding typing to Arg, I set off on setting member offsets. I initially went with my MEMBER_OFFSET() method with the intent of changing it later, and almost immediately, it dawned on me that we don't need a dummy instance of the class at all. In fact, all we need is the type and the member, and we find the offset by taking the address of the member dereferenced from a null pointer ( e.g. offset = ((int)&((type*)0)->member) ). I even learned that this operation is built into C/C++ itself with the offsetof(type,member) operator. Who knew?<br>
<br>Unfortunately, this does not solve our problems because offsetof will only work on "Plain Ol' Data" (POD) classes (e.g. no virtual bases). This is indeed a problem causing crashes when I tried it. gcc complains about its use on node types too.<br>
<br>Another problem that I thought of is member variables of base classes may not be located in the same spot relative to the this pointer in the derived class as they were in the base class. e.g. Node::m_ID might be at offset 0 in Node, but offset 50 in RasterNode depending on how the compiler feels like laying out the memory. Thus, in order to correctly determine the offset of a member, we would have to do so relative to the most derived class where private members of base classes are not accessible! I may have made an error in my thought process here, so please correct me if you disagree with anything :)<br>
<br>Finally, I have been able to put my finger on my design-reservations about this feature: it breaks encapsulation.<br><br>I have included my changes in case you want to play with them, but I am close to convinced that what we want to do is not possible. What do you think?<br>
<br>Nick Hebner<br>