>Vladislav Vaintroub wrote:
> a) string tmp = object1->object2->object3->str; //copy constructor
> involved
> b) string &tmp = object1->object2->object3->str; //no copy, tmp can be
> changed
> c) const string &tmp = object1->object2->object3->str; // no copy, tmp
> is
> immutable
>
> In case b) and c) no copy is involved.
>
> I believe there are basically 3 cases where copies can be created:
> 1) passing via function parameter -> copy/increment can and must be avoided
> 2) tmp copy inside a function -> copy/increment can and must be avoided
> 3) passing object to the constructor of another object -> copy/increment may
> be done. Depends on lifecycle of another object, if it can outlive current
> object - copy necessary , if not, copy not necessary.
> 4) reading object from containers (list/queue) shared between threads ->
> copy/increment must be done
>
> Can you think of something else?.
Both 3 and 4 involve holding a pointer to an object for longer periods
of time. And you seem to think that the code could be designed with
smart pointers so that the unnecessary increments can be avoided. I
would love to see an example of that.
I think the DeferredIndex objects are a great place to start. The long
term locations for pointers to a DI object are;
Index:: Queue<DeferredIndex> deferredIndexes;
Transaction:: DeferredIndex *deferredIndex;
DeferredIndexWalker:: DeferredIndex *deferredIndex;
WalkDeferred:: DeferredIndex *deferredIndex;
Currently the Index::deferredIndexes location is not being refcounted.
Chris and I think it probably should, but no bugs indicate the need for
it. The transaction is the primary owner and the code is prepared,
after Bug#39846, for the index to go away sooner than the transaction.
Anyway, that would be a great place to propose a smart pointer solution
for us to evaluate. If it has the same number of interlocked increments
and decrements as the current code, then it should be more stable and
maintainable.
Kevin
