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().
-- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk