Re: [boost] [move] problem with msvc and BOOST_MOVABLE_BUT_NOT_COPYABLE

Subject: Re: [boost] [move] problem with msvc and BOOST_MOVABLE_BUT_NOT_COPYABLE
From: David Abrahams (dave_at_[hidden])
Date: 2010-05-28 15:26:36

At Fri, 28 May 2010 21:03:24 +0200,
Thomas Klimpel wrote:
> 
> David Abrahams wrote:
> > You are claiming that some aspect of that signature causes RVO not
> > to happen?  What aspect?
> 
> I understand you want to comment on what could be FUD, but why do
> you ask about the "signature" then?

Because that's all you showed in the first message?  There was no
body.

> > A static member function is just a function to the compiler.  AFAIK,
> > the only compiler in recent memory that doesn't have NRVO (yet) is
> > Clang.  And they're working on it.  What compiler are you talking
> > about?
> 
> Same here, I appreciate it that you try to clarify my
> misconceptions, but I was talking about RVO here, not NRVO.

In the function you wrote in your previous message:

  X X::create()
  {
      X x;
      return x; // passing value form static memeber-fn
  }

x is named.  Its name is “x” :-).  Optimizing away the copy requires
the Named Return Value Optimization (NRVO), not the Unnamed Return
Value Optimization (URVO).  “RVO” by itself refers to both of them.

> Please also understand my position that everybody is allowed to make
> mistakes, but he shouldn't blame Boost.Move or its documentation for
> it. The linker had complained about a missing symbol, and this means
> that it had indeed generated the corresponding constructor
> call. This might be related to compiling in debug mode with
> msvc-9.0. I don't know whether gcc-4.5 or msvc-10.0 implement NRVO
> even in debug mode. However, this should be easy to find out if it's
> important for this discussion.

Sorry, I haven't followed the rest of the discussion so the above
doesn't mean much to me.

-- 
Dave Abrahams           Meet me at BoostCon: http://www.boostcon.com
BoostPro Computing
http://www.boostpro.com