Re: [boost] Re: New patch for operators.hpp uploaded

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2002-10-24 11:00:33

Andrei Alexandrescu wrote:
> 
> "Daniel Frey" <daniel.frey_at_[hidden]> wrote in message
> news:3DB7F6B3.AAB353CC_at_aixigo.de...
> >The question is, why 'X x( f() );' is different from 'X x = f();'.<
> 
> Yes. The latter is equivalent to X x = X(f()) so it is allowed to create an
> extra copy.

Yeah, but this doesn't explain why it's exactly vice-versa! The
EDG-compilers had an extra copy for 'X x( f() );' but not for 'X x =
f();'. I still don't understand why...

> >> Every compiler outputs nothing for X( f() ) and X( g() ).
> 
> >This is the most surprising result, at least to me. As all compilers
> seem to agree, I wonder if I missed some fundamental point. I would not
> expect that compilers are allowed to remove the objects completly. Is it
> allowed?<
> 
> I suggest we do the measurement with main() in one file and everything else
> in another file, so the compiler can't inline the calls.

In theory this shouldn't make a difference :o) But we have seen that in
practice almost everything is different, so this is a good idea. I'm
still in the company and can't do any testing right now. If someone
(Dave, Marc) would be so kind so run the tests once again... :)) 

> >For boost (as a lame attempt to make it on-topic for this list :) should
> we add 'X x = f(); is preferable over 'X x( f() );' to the coding
> guidelines?<
> 
> I put it into my team's coding standards three years ago. It was by far the
> least popular guideline. Looks awful, but we were using it because we knew
> it can be more efficient. Then, one day when we changed compilers, we hit
> the declaration-vs-construction well-known ambiguity. We said some bad, bad
> words and we ditched the guideline off.

So you currently have no guideline for it at all?

> The whole state of affairs with temporaries is terrible, in both syntax and
> semantics.

:)) Yes, true words!

> Ah, and while we're at it, anyone else hates the syntax and
> semantics of member initializers?

Well, it doesn't look very nice, but is there any real problem with it?

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