Re: in/out arguments
on Sun Apr 15 2012, "James K. Lowden" <jklowden-AT-speakeasy.net> wrote:
On Sat, 14 Apr 2012 23:27:49 -0700 (PDT)
Dave Abrahams <dave@boostpro.com> wrote:
If you want to live in a world where you can dismiss mutation of
state as rare, you should be programming in Haskell. (**)
I didn't mean to imply that mutation is rare. I meant to state that
the syntax and idiom of C++ makes the use of i/o parameters --
syntactic, explicit parameters -- rare. Not vanishingly rare, but
rare enough that I see no need for them to expressly denoted in the
syntax.
Agreed.
Looking at Jonathan Thornburg's reasonable example
sqrt_of_big_vector(std::vector<double>& v);
it might also be expressed as
sqrt_of_big_vector(v.begin(), v.end());
or
transform(v.begin(), v.end(), v.begin(), sqrt);
or
big_vector::sqrt()
Not really. s/::/./
depending on whether or not function is applied element-wise. I
think you'll agree the last version is preferable if, for reasons of
internal consistency, the operator must be an all-or-nothing
transformation.
Not really
inplace_sqrt(big_vector);
is preferable from many points of view.
If the operator had to be all-or-nothing in some circumstances, and
the elementwise sqrt could throw (it can't with double), I would
handle it externally:
{
vector<BigNum> t = v;
inplace_sqrt(t);
swap(t,v);
}
I would never burden every caller of inplace_sqrt with the cost of
copy/swap.
Finally, if I really wanted optimal efficiency, I'd do something with
expression templates and write something like this:
v = sqrt(v);
Acknowledged, Jonathan's version also works. The OO school says
functions that act on one type should be members. (Why, then, does
the STL have a sort function?
You should read what Stepanov has to say about OO sometime. I doubt
the OO school's sayings would have much influence. And IMO he's
right.
Because it works on POD types, which themselves exist because, as
Stroustrup likes to remind us, C++ isn't only an OO language.)
That's not why we have PODs, but that's probably not too relevant here
anyway.
I think it's notable, actually, that the STL does
not provide sort<vector<T>>.
What in particular do you think is notable about it?
It's notable because the committee evidently felt it was redundant,
insofar as the standard was released (and presumably considered
complete) without it.
I don't think you have a very clear appreciation of committee
dynamics. There was no group decision that such an interface was
redundant. There was only so much time, the standard was late, and
the STL was a very late addition. At some point you just have to
decide to stop working on the document and publish it.
Because acting on the whole set is a specific case of acting on a
subset, the STL satisfies both by providing just the general
interface. By example it encourages others to do the same.
Yes.
the committee is actively considering adding it.
If you have a favorite paper explaining why we we need a function
like that, I'd be interested to read it.
I don't, but there are lots of good arguments for a range-based
interface. Check out Andrei Alexandrescu's BoostCon keynote:
http://blip.tv/boostcon/boostcon-2009-keynote-2452140
Like you, I was younger when the STL first made its appearance. ;-)
I thought the lack of stuff like sort<vector<T>> was an obvious
oversight, and I wrote lots of little wrappers for them. Over the
years, as you might guess, I stopped bothering. I know, it's
possible to pass the begin() of one container and the end() of
another. Very exciting, too! And, since I haven't made that
particular mistake in 10 years, I'm probably due for one.
There are reasons other than correctness to do this. For example,
expressivity:
http://www.boost.org/doc/libs/1_49_0/libs/range/doc/html/range/introduction.html
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]