[libavg-devel] Dynamic Node Creation Enhancements

[Ulrich von Zadow]

Hi,

I need a bit of time to look this over, because I still think it should 
work. Member variables of base classes never move in derived classes 
(even with multiple inheritance), as long as you always use a pointer to 
the base class. For simple single inheritance, the pointer to an object 
shouldn't change either in a cast from base to derived class and back. 
offsetof(), while technicaly undefined, _should_ work for these objects 
in all sane implementations of C++ (For discussions of this, see 
http://gcc.gnu.org/ml/gcc/2003-11/msg00279.html and 
http://carcino.gen.nz/tech/cpp/multiple_inheritance_this.php).

It might take a moment for me to get around to it, though, so getting 
the first patch into svn would be great.

Cheers,

   Uli

Nick Hebner wrote:
> Well, I spent the past few hours today trying to hack something together,
> and have run into a few issues.
> 
> 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?
> 
> 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.
> 
> 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 :)
> 
> Finally, I have been able to put my finger on my design-reservations about
> this feature: it breaks encapsulation.
> 
> 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?


-- 

Ulrich von Zadow | +49-172-7872715
Jabber: cocacoder at jabber.berlin.ccc.de
Skype: uzadow