Hi,
Gerrit Voss wrote:
> On Thu, 2008-06-19 at 18:06 -0500, Carsten Neumann wrote:
>> can somebody remember or think of a reason for the GraphOp d'tor being
>> protected?
>
> Because they were move to be reference counted so that the don't leak
> memory.
oh, nice, but see below.
>> AFAIKS this means it is impossible to delete GraphOps
>
> not quite ;-)
>
>> GraphOp *go = GraphOpFactory::the()->create("MyGraphOp");
>> delete go;
>>
>> complains about the delete and the factory does not want them back either ;)
>
> try subref(go);
ok.
Hm, can we not simply suggest users store these with boost:shared_ptr?
I think we should try and reduce the number of ref counting schemes the
user deals with (currently: MemoryObject, FieldContainer,
boost::shared_ptr for the handles).
Grepp'ing through the code, I can find the following uses of MemoryObject:
- SharedObject
- MPBase
- ClusterNetwork
- ChangeList
- GraphOp
- GraphOpSeq
- StatCollector
- TextFace
- NavigatorEngine
boost:shared_ptr is currently used for the FieldHandles and in two files
of Contrib/BackgroundLoader
So, what does everybody think about moving (at least) GraphOp,
GraphOpSeq, StatCollector, TextFace and NavigatorEngine to shared_ptr ?
Thanks,
Carsten
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core