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

Reply via email to