Hello Gerrit,

Gerrit Voß wrote:
> On Mon, 2010-06-28 at 17:50 -0500, Carsten Neumann wrote: 
>> The question is how to plug that hole without making it 
>> impossible/inconvenient to write generic code that just follows pointers 
>> to other containers? One (rather big) solution would be to remove the 
>> Pointer{S|M}FieldBase types and operator-> from FieldHandle and instead 
>> expand FieldHandle's interface a bit so that it allows accessing pointer 
>> fields through virtual functions that take/return FieldContainer*.
> 
> hmm, I was thinking about that, but I don't like it that much.
> 
>> Hm, would be nice if there was a way to avoid all that, but especially 
>> for MFields it seems difficult, because PointerMFieldBase hands out 
>> iterators which know nothing about ref counting (they are plain 
>> std::vector<FieldContainer*>::iterator, not the ref counting aware 
>> wrappers used by the actual PointerMField<> template). Any ideas?
> 
> I planned to add custom iterators, all other pointer fields have them
> anyway.

yes, but how do you know which RefCountPolicy to use? The main 
motivation for PointerMFieldBase was not having to know the type or ref 
count details of the specific field. I had thought the (limited) set of 
member functions would be safe, but had overlooked the 
RefCountPolicy::validate() case.
Do you propose to unconditionally go through 
WeakRefCountPolicy::validate() ?

> I fixed the SField part already so that should cover most of
> the use cases (I actually don't remember having a weak mfield
> somewhere).

True, but I'd prefer fixing it for MField anyway ;)

> I just have to find the time ;)

I can take care of the implementation, just wanted to be sure first what 
the preferred way to solve this is - of course carefully thinking this 
through takes time too ;)

        Cheers,
                Carsten

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Reply via email to