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

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2002-10-13 12:02:49

Gabriel Dos Reis wrote:
> 
> How can you know that will me limit me?  Answer:  You can't :-)
> You showed a hypothetical example, but I don't see any concrete
> situation where that modification would make sense for the project at
> hand.

I had this numerous times, but of course it depends on your problem
domain and lots of other factors.

> When optimizing code, I use a profiler that tells me the hot spot.
> And I can't see any situation where your hypothetical example would be
> any optmization or improvement.

It is a common thing when you start using a cache and instead of
creating objects (and having the 'create'-function return them), you
have i.e. a map where you look for the appropriate object an return a
reference to this object from the create-function. This leads to
significiant speedups if the construction of an object is e.g. reading
it from the database.

> We're specifically talking of *iterators* I've yet to see an
> implementation of an iterator where your example would be any
> improvement.

I was talking about returning T or const T in general. I think we should
collect the pro/cons as there are IMHO good arguments for *both* sides,
although I prefer to return 'const T'.

> | To me, it is something that I can read.
> 
> Interesting.  So you can read a reference.  How?

I knew it was going in the wrong direction :) I mean the sematic of
"value" against the semantic of "object". I don't refer to the standard
here, but to the meaning of these words in the natural language (of a
C++ programmer :). 

> | It's different from an "object", which is something you can change.

An example: 42 is a value. An 'int' which holds the value 42 is an
"object", as you can modify it. You modify the object so it represents a
different value. Hm... it hard to express what I mean as english is not
my native language, but I hope you get the idea anyway :)

> No.  I except a function to return (i) nothing, (ii) a value or (iii) a
> reference.

It seems that I mean (ii) to be called an object and (iii) a value. I
know these may not be the correct technical terms. Anyway I don't want
to say the all functions should return values, but I mean that functions
should decide on (ii) or (iii) based on the sematic. When you implement
a function which semantically return (ii), you return a T. If you have a
function which semantically returns (iii), it can be 'const T' or 'const
T&', thus it allows you to return a 'const T' for a first implementation
and if you later need to return a 'const T&', it is a transparent change
for the users. It does place some burden on the users as they have to
make a copy of these return values before they can modify them, but from
my point of view, this is intentionally.

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