yade-dev team mailing list archive
-
yade-dev team
-
Mailing list archive
-
Message #00978
Re: shared_ptr<PhysicalAction>
>> Hi there, any reason PhysicalActionContainer contains shared_ptr's?
>> Wouldn't it be better to contain just array of PhysicalActions? It would
>> allow for very fast resetting with
>> memset(action[0],0,sizeof(thisAction)) and perhaps would save some
>> shared_ptr overhead we have currently. V.
> I thought it would be used for parallelisation. If not, I'm all for
> removing shared_pointers when it is possible.
I think that for cases where it is clear who is responsible for
allocation/deletion && it is always done just in one place, we could
eliminate shared_ptr's. The lock-free access control Janek mentioned
only affects access to the pointer itself (like reference counting), but
not the the pointed object.
Physical actions are allocated and deleted by the container, engines
just modify their contents. And we can make sure that the container
doesn't leak, since it is just small piece of code.
For other things, shared_ptr's are quite handy; for example python proxy
objects reference an engine, and it still is a valid reference even if
the simulation was already unloaded. That is nice.
I would like to know what the overhead of shared_ptr's is, but we will
probably never know that, since its methods are, I bet, almost always
inlined and therefore contribute to the calling function. Someone
volunteering to take a few weeks and try shared_ptr-free yade? ;-)
V.
References