> -----Original Message-----
> From: Kevin.Lewis@stripped [mailto:Kevin.Lewis@stripped]
> Sent: Monday, October 06, 2008 9:27 PM
> To: falcon@stripped
> Subject: Re: Understanding RefCounts in Falcon
>
> >> Kevin Lewis wrote;
> >> The advantage of targeted reference counting is performance.
> >> The advantage of smart pointers is stability.
>
> > On Mon, Oct 6, 2008 at 11:12 AM, Vladislav Vaintroub <wlad@stripped>
> wrote:
> > I'm about to give up. All discussions during Boston meeting are in
> vain.
> > References are non-existent feature of C++ and it is not possible to
> prevent
> > copying and object when it is passed as function parameter. Therefore
> smart
> > pointers are slow.
>
> Vlad, your sarcasm may have been misunderstood. C++ does support
> passing references and this can be done to smart pointers without
> causing an interlocked increment between functions. But I was talking
> about multiple copies of pointers within functions and using them for
> some duration of time, even in sub-functions. Targeted reference
> counting can reduce interlocked increments even if passing pointers by
> reference.
>
> Do you think this is negligible or can be worked around somehow?
>
Sorry for sarcasm. But it has been discussed once and I had the impression
people understood that, but would not like to change lots of existent code.
I believe the impression was wrong.
> about multiple copies of pointers within functions and using them for
> some duration of time, even in sub-functions.
Now sure I understand all use cases.
tmp objects within a function?
Consider
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?.
> --
> Falcon Storage Engine Mailing List
> For list archives: http://lists.mysql.com/falcon
> To unsubscribe: http://lists.mysql.com/falcon?unsub=1
