[boost] Re: Reference documentation

From: Kevin S. Van Horn (Kevin.VanHorn_at_[hidden])
Date: 2002-10-31 10:35:06

Noah Stein writes:

>> Kevin S. Van Horn:
>
>> Does it matter to the user whether the signature of f is
>> "void f(foo_t)" or "void f(foo_t const &)"?  [...]
>
> Isn't a function signature in the API part of the interface and not the
> implementation?

I used to think so, but my experience with generic programming and 
some of Andrei's comments on this list have caused me to modify my 
opinion.  From GP we learn that what is important is the _valid 
expressions_ -- that is, the syntax and semantics of component usage -- 
rather than the component's declaration.  For example, all we care is that 
vector<int>::iterator is a valid type expression (along with requirements 
on objects of this type); we don't care whether it's a nested class of 
vector<int> or just a typedef.  

> I would think that whether an object is copy constructed or
> not would have an influence on what you pass in to the function.  I know
> that it would make a very big difference for me in the products I work on.
> Anything large that I wanted to pass into f would almost be required to be
> behind a handle or smart pointer of some sort.  Since the original signature
> didn't take a const foo_t, I'd also want to ensure that it supported some
> kind of COW, unless I'm multi-threading then maybe I don't want COW.

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 (see
Andrei's stuff on Mojo and move constructors), in which case no amount of use
of handles, smart pointers, COW, etc. will help -- an independent copy is
going to get made one way or another.