Re: Implicit move constructor rules in c++0x still badly broken?
On 22.02.2011 20:16, Howard Hinnant wrote:
On Feb 22, 6:39 am, Stephen Howe<stephen.h...@kantarmedia.com> wrote:
The ironic thing is that the link you site has not yet offered a code
example that gets broken.
-Howard
Follow the links Howard.
You arrive at Scott Meyers
example:http://cpp-next.com/archive/2010/10/implicit-move-must-go/
which does break in the destructor as v[0] is undefined.
This link was written prior to the 2010 Fall standards meeting in
Batavia which fixed the problem in this link.
No, it did *not* fix it.
This thread is no longer about the implicit generation of move
constructors. It is about implicitly considering the expression of a
return statement when that expression is eligible for RVO.
This thread here - maybe. But not the post by David Abrahams.
There is *way* too much confusion and mis-information in this thread.
I agree about the confusion.
I *strongly* encourage all participants to post code, to post the
results from having actually compiled/tested that code, and to post
what compiler was used to obtain those results.
Which compiler (version) that I could easily use on Windows already
implements the lates std draft?
I stand by my statement:
http://cpp-next.com/archive/2011/02/w00t-w00t-nix-nix/
has not posted code that actually breaks.
I do not claim that such code doesn't exist. I only wish to have this
discussion based in fact, not in fud.
http://cpp-next.com/archive/2010/10/implicit-move-must-go/
lists the example tweak#2 - class has no ctor but still a class
invariant. (I'll re-post the code at the end.)
Per the new rules
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3203.htm
If the definition of a class X does not explicitly
declare a move constructor, one will be implicitly
declared as defaulted if and only if
* X does not have a user-declared copy constructor,
* X does not have a user-declared copy assignment operator,
* X does not have a user-declared move assignment operator,
* X does not have a user-declared destructor, and
* the move constructor would not be implicitly defined as deleted.
this example *still* breaks.
Note again: I'm not saying implicit-move-ctors should necessarily be
removed completely, I'm just saying that Dave *does* have a point.
cheers,
Martin
- - -
Code Example Tweak#2 from David's post @
http://cpp-next.com/archive/2010/10/implicit-move-must-go/
- - -
#define _GLIBCXX_DEBUG
#include <iostream>
#include <vector>
// An always-initialized wrapper for unsigned int
struct Number
{
Number(unsigned x = 0) : value(x) {}
operator unsigned() const { return value; }
private:
unsigned value;
};
struct Y
{
// Invariant: length == values.size(). Default ctor is fine.
// Maintains the invariant
void resize(unsigned n)
{
std::vector<int> s(n);
swap(s,values);
length = Number(n);
}
bool operator==(Y const& rhs) const
{
return this->values == rhs.values;
}
friend std::ostream& operator<<(std::ostream& s, Y const& a)
{
for (unsigned i = 0; i < a.length; ++i)
std::cout << a.values[i] << " ";
return s;
};
private:
std::vector<int> values;
Number length;
};
int main()
{
std::vector<Y> z(1, Y());
Y a;
a.resize(2);
z.push_back(a);
std::remove(z.begin(), z.end(), Y());
std::cout << z[1] << std::endl;
};
- - -
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]