C++Talk.NET

ppliu · Guest

to Dave:
There's some other questions about the move proposal:

First:
--------------
struct X{};

void f(X&& );

void use()
{
X x;
f(x); //should this result in a compile error?
}
Anyway, a lvalue should *not* be *implicitly* moved(movable)!
And,actually,I think,the example you gave,which only has "f(S&&)"
declared,is a kind of

design flaw.
By keep lvaue from being implicitly *bind*(not cast,because in current
language rule,lvalue

can be implicitly casted to rvalue on the fly) to rvalue reference,some
design error can be

forbidden,for example:
void f(A&& a)
{
pilfer a ,but if there's only this "f" ,it will pilfer lvalue
too!!
so this kind of desin should be forbidden!
}
By the "lvalue not implicitly bind to rvalue reference" rule,resource
of some object will

not be pilfered unexpectly.

This rule can be stated like this:
When some object binds to a rvalue reference,It's because of two
(and only two) reason:
1). the object *requests* to be moved!
2). the object is a temporary object(rvalue),so it *can* be
moved absolutely!
In 1),the object is explicitly casted to a rvalue,and in 2),the
object is rvalue

itself.In both case,the object must be a rvalue.

And, I got another consideration:

If only a move constructor like
A(A&&);
was declared, Should the implicitly generated copy constructor
A(A const& ); or A(A&);
be erased?

For example:
class A
{
public:
A(A&& )
{
// move
}
}
Should this class have a default generated copy constructor?

Here's my opinion:
If we don't generate default copy ctor for a class having a move
ctor,there're such

consequences:

1). If this is a design flaw or oversight of the lib author,when the
object of this class

was to be copied ,a compile error will occur,which says that "can't
bind a lvalue to rvalue

reference" which reminds the author of the error!

2).A class which is movable may have resources almost all the time,such
a class needs deep

copy! By this rule,if one declares move constructor only,and try to
copy construct,compile

error will occur,which reminds the one to modify his class!

[Note! In rare case,some class will be movable and default copyable,in
such cases,users

should add a copy constructor manually. for example:
class A
{
vector<X> xv;
public:
A(A&& a): xv(move(a.xv) )
{}
//should we generate a default copy constructor here?
//if not,the author should add it here,otherwise compile error may
occur.
}
]

3). This may always be a design error,except that It's on purpose.
So,If this is on purpose,the lib author means that objects of this
class are not

copyable but movable,if users try to copy ,compiler error occurs.
BTW,this should rarely happen.

And if we generate default copy ctor for those class which hava move
ctor declared only,the

consequences are:

1). "move construction" and "copy construction" are semantically
separated.
A class that is movable can still be default copy constructable.
If it needs deep copy , the author should declare it explicitly ,which
is always the case in

current language.
If the author forgot to declare a copy constructor in these
situations,as it always be , he

will got a rumtime error in most case.

2). some classes that own its resources by a smart container won't need
a copy constructor

explicitly declared(the defaultly generated one will fits well)while it
has move constructor

declared.
Definitely the move constructor should be declared manually no matter
whether it's *trivial*

or not , here "trivial* means that it delegates all the moving task to
the smart container.

3). In rare case,the author wants to forbid copy construct,and enable
move constructor

meanwhile,he can *only* declare the class like this:
class A
{
public:
A(A&& a);
private:
A(const A& ); // forbid copy constructor *explicitly*
};
This show's the purpose explicitly!

So,what should we do?

Similar problem to operator =.

Also,please correct me if I have misunderstood , and, if not, is this a
rule worth adding to

the c++0x?

At last,
A more subtle problem is : should we generate a default move
constructor for some class?

for example :
class A
{

vector <X> x;
my_container<Y> y;
// other user defined class or std:: class only
}

class B
{

X* px;
Y* py;
}
class A and class B are treated separately,we can introduce two
status:
1). classes without "naked" pointers like X*
2). classes with "naked" pointers

for 1),we can generate a default move constructor and delegates all the
moving task to the

class members.
for 2).we can't,unless we emitt such code for each member pointers:
pointer_name = other.pointer_name;
other.pointer_name = 0;
But there's a problem with it: a pointer may not be for resource
management at all,with
this being the case,we could not generate the code above.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Howard Hinnant · Guest

In article <cie37o$2h0 (AT) odak26 (DOT) prod.google.com>,
"ppliu" <pp_liu (AT) msn (DOT) com> wrote:

David Abrahams · Guest

"ppliu" <pp_liu (AT) msn (DOT) com> writes:

James Hopkin · Guest

David Abrahams <dave (AT) boost-consulting (DOT) com> wrote

Howard Hinnant · Guest

In article <a0368c9c.0409200155.263b2293 (AT) posting (DOT) google.com>,
[email]jhopkin (AT) reflectionsinteractive (DOT) com[/email] (James Hopkin) wrote:

James Hopkin · Guest

Howard Hinnant <hinnant (AT) metrowerks (DOT) com> wrote

David Abrahams · Guest

[email]jhopkin (AT) reflectionsinteractive (DOT) com[/email] (James Hopkin) writes:

Howard Hinnant · Guest

In article <a0368c9c.0409220653.36e31f64 (AT) posting (DOT) google.com>,
[email]jhopkin (AT) reflectionsinteractive (DOT) com[/email] (James Hopkin) wrote:

James Hopkin · Guest

Howard Hinnant <hinnant (AT) metrowerks (DOT) com> wrote

Howard Hinnant · Guest

In article <a0368c9c.0409230921.70bfca54 (AT) posting (DOT) google.com>,
[email]jhopkin (AT) reflectionsinteractive (DOT) com[/email] (James Hopkin) wrote: