|
Boost : |
From: Glen Knowles (gknowles_at_[hidden])
Date: 2002-11-01 01:21:57
From: David Abrahams [mailto:dave_at_[hidden]]
> "Kevin S. Van Horn" <Kevin.VanHorn_at_[hidden]> writes:
> > What you're missing here is that if I, as the implementor, declare
> > the argument to bee foo_t const &, it will be because I do not
> > intend to make a copy, and there are then no copy efficiency
> > concerns for you, the user, to worry about. On the other hand, if I
> > declare it to be foo_t, this will only be because I need to create
> > _and_ _take_ _ownership_ _of_ an actual copy
> I think you're confused. The copy is owned by the virtual machine,
> since it gets created on the stack. Usually, "take ownership of" only
> applies to heap objects whose lifetimes can be managed by their
> owners.
He said "take ownership of a copy" which I assume to mean something he
can modify as opposed to a const ref which he can only look at.
But I see little point, is there any practical difference between:
void f(const T& a) {
T work(a);
// play with work copy
}
and
void f(T work) {
// play with work
}
for types where const T& would be considered? (larger then a pointer
and/or with an explicit constructor). Both forms copy construct "work".
Glen
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk