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
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
