From: Howard Hinnant (hinnant_at_[hidden])
Date: 2002-10-12 18:55:48
On Saturday, October 12, 2002, at 05:31 PM, Beman Dawes wrote:
> As a result of pre-review comments, the Filesystem Library just
> reviewed had const stuck on a bunch of member functions which return
> by value but take no arguments. For example:
> const iterator begin() const;
> What is your take on that? Any different from the case where the
> returned value is a modified pass through of an argument?
Disclaimer: I have not looked at the Filesystem Library (and probably
should have before posting).
In my defense I just read the thread (for the first time) "filesystem
library const usage".
Still not familiar with a Filesystem::iterator, I'm guessing it holds
no resources and has a dirt cheap copy constructor. If that is the
case, then there is probably not a lot of difference between returning
const iterator and iterator. const iterator is slightly safer, and
clients can make a non-const copy without too much penalty (which they
almost always want to do anyway).
Perhaps this is analogous to 3 point safety belts vs 4 point safety
belts. Aircraft pilots (at least commercial and military) usually wear
4 point safety belts. This is the best you can do safety wise. You
are strapped in! But quite frankly, 4 point safety belts are too much
of a PITA for your day to day automobile occupant. 3 points belts are
almost as safe and twice as easy to use. If 4 point belts were
introduced into your everyday automobile, my guess is that there would
be widespread abuse of the system.
And hopefully not going to far off track here: The automatic shoulder
strap belts that try to help by automatically placing the shoulder
strap around you, while leaving you with the job of attaching the lap
belt, are a menace to safety and I can't believe that they ever made it
into public use.
That last point was mainly added to point out that any safety system
(software or otherwise) should either be very safe, or get out of the
way. Never do a half way job that can lull your client into a false
sense of security.
This is essentially a classic flexibility (ease of use) vs safety
issue. I've personally never been burned by a non-const return value,
and I have taken advantage of non-const return values. If the reverse
were true, I'm sure I would be very much in favor of const return
values. But as it is, I'm in the camp that one should default to
return by non-const T unless you can see a compelling reason to add the
const. Maybe Filesystem::iterator is such a case that is better served
by const return values, I don't know. Fwiw, I've used --c.end() and am
not sorry for it! :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk