Re: [boost] Re: Re: Zero Unnecessary Temporary Objects: A Revolution

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).

</philosophical on/>

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.

</philosophical off/>

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! :-)

-Howard