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

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2002-10-13 10:50:14

Gabriel Dos Reis wrote:
> 
> Daniel Frey <daniel.frey_at_[hidden]> writes:
> 
> | It's not really unsafety, but it limits you in development,
> 
> Really?  Right now, it doesn't.

Exactly :)) Right now, it doesn't. But it will limit you in the future,
when you need to optimize the code - which is typically done during a
very busy period when the customer is testing the product's release
candidate for the first time and it is too slow. If you can change a
function from returning a reference instead of a copy, it can be a good
optimization, but it's very ugly if you have to change code which relies
on the function to return a real (modifiable) object. This may not be
relevant in projects with 10.000 lines of code, but the bigger the
project, the bigger you problem will be.

> Well, I would say it is that change that may be a limit since I expect
> an iterator to be an _object_ -- from all the various definitions I've
> worked with, iterators were values.

Ask yourself: What is a "value"? To me, it is something that I can read.
It's different from an "object", which is something you can change. You
expect the function to return a value? Good, as this means a 'const
iterator&' would be sufficient. It behaves like a value, as you can read
it, but it's not an object. Some functions return "objects" and they are
meant to do this, so I won't return a 'const T', but if the semantics
are to return a "value", I prefer the 'const T'. And for operators, I
expect a "value", as I expect a "value" from begin()/end().

Regards, Daniel

--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: [phone], fax: [phone]
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de