Re: [boost] [operators] The Dangling Reference Polarization

Subject: Re: [boost] [operators] The Dangling Reference Polarization
From: Daniel Frey (d.frey_at_[hidden])
Date: 2013-04-25 18:14:07

On 26.04.2013, at 00:01, Steven Watanabe <watanabesj_at_[hidden]> wrote:

> On 04/25/2013 01:40 PM, Daniel Frey wrote:
>> <snip>
>> 
>> c) It rely's on the fact that it extends the lifetime of a returned temporary value. The rules of the C++ standard that allow this are quite clear, and hence it's the users responsibility to make sure that there actually is a temporary value whose lifetime can be extended. It has always been an error if the expression returned a reference and not a value. Consider
>> 
>>  const std::string& oops = std::vector<std::string>(1, "hello, world" ).front();
>> 
>> This compiles are creates a dangling reference, as the standard says that front() returns a reference and not a value. It's not 100% comparable as in this case the standard guarantees a bug, but the main point for C++ has always been which guarantees are given and not about a certain expectation one might have.
> 
> The designer of a component should try to make sure that
> the guarantees provided match user expectations.  Anything
> that's clever, but has subtly different semantics is
> likely to be a source of bugs.

I think one should try to match a users expectation and intuitions as much as possible, but only if there is no reason to diverge from it. I'm not ignoring the users reasonable expectations, I just thought that there is a good reason to consider an alternative.

>> e) The alternative needs to prove its claimed/theoretical efficiency in practice. Too often I have heard about "sufficiently smart compilers", but I'm more the prove-it-in-the-real-world type.
> 
> Um... I think that argument goes the other way.
> As the person introducing an optimization, it's
> your responsibility to show that it actually helps.

In my initial post from 2013-04-22T21:46 I gave an example program which shows/proves the benefit of my technique over the alternative for todays compilers. I was referring to the claimed efficiency of the alternative from Dave Abraham's article on that topic (and especially the "Reality Bites" section).

But I guess most of it is mood now since Andrew Ho pointed out range-based for loops…

BR, Daniel