>> 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. _______________________________________________ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
