On 18 Sep, 21:35, David Abrahams <d...@boostpro.com> wrote:
> but you can get a (partial) preview in Bjarne's paper at
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2904.pdf

This change can break some existing code. For example, here

class X
{
public:
   X(char const *s) : m_last(m_data)
       { construct_aux(s); }
   X(X const &x) : m_last(m_data)
       { construct_aux(x.m_data); }
   char const *begin() const
       { return m_data; }
   char const *end() const
       { return m_last; }
private:
   void construct_aux(char const *s)
       { while (*m_last++ = *s++) {} }
   char m_data[256];
   char *m_last;
};

proposed implicitly defined move-ctor simply copies m_last that has
inappropriate value for new object.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Sep 25, 7:42 pm, Nikolay Ivchenkov <ts...@mail.ru> wrote:
> On 18 Sep, 21:35, David Abrahams <d...@boostpro.com> wrote:
>
> > but you can get a (partial) preview in Bjarne's paper at
> >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2904.pdf
>
> This change can break some existing code. For example, here
>
> class X
> {
> public:
>    X(char const *s) : m_last(m_data)
>        { construct_aux(s); }
>    X(X const &x) : m_last(m_data)
>        { construct_aux(x.m_data); }
>    char const *begin() const
>        { return m_data; }
>    char const *end() const
>        { return m_last; }
> private:
>    void construct_aux(char const *s)
>        { while (*m_last++ = *s++) {} }
>    char m_data[256];
>    char *m_last;
>
> };
>
> proposed implicitly defined move-ctor simply copies m_last that has
> inappropriate value for new object.

The above proposal is rather out-dated. Considering the most recent
update

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2953.html

you will observe that above example class would no longer break,
because it has a user-declared copy constructor. Any such beast
is supposed to prevent a compiler-generated move constructor.

HTH & Greetings from Bremen,

Daniel Kr   gler


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In draft C++0x, the move constructor and move assignment operator are
not special functions, hence not eligible for use with "=default".  It
seems reasonable to me that these functions are not generated by
default (i.e., are not special member functions), but the use of
"=default" with them does seem reasonable:  the corresponding
implementations would perform memberwise moves.   Does anybody know
whether this idea was considered?  (I seem to recall a similar query
regarding "=default" with operator== and operator!=.)

Are there technical reasons why there's no shorthand way to say "this
class supports move construction by memberwise move" (and similarly
for move assignment)?

Thanks,

Scott


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

on Thu Sep 17 2009, Scott Meyers <smeyers-AT-aristeia.com> wrote:

> In draft C++0x, the move constructor and move assignment operator are
> not special functions, hence not eligible for use with "=default".  It
> seems reasonable to me that these functions are not generated by
> default (i.e., are not special member functions), but the use of
> "=default" with them does seem reasonable:  the corresponding
> implementations would perform memberwise moves.   Does anybody know
> whether this idea was considered?  (I seem to recall a similar query
> regarding "=default" with operator== and operator!=.)
>
> Are there technical reasons why there's no shorthand way to say "this
> class supports move construction by memberwise move" (and similarly
> for move assignment)?

Actually, there probably will be.  An upcoming article in this series at
http://cpp-next.com/archive/2009/09/making-your-move/ will cover it in
more detail, but you can get a (partial) preview in Bjarne's paper at
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2904.pdf

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Hi,

Scott Meyers schrieb:

    Are there technical reasons why there's no shorthand way to say "this
    class supports move construction by memberwise move" (and similarly
    for move assignment)?

Howard Hinnant considers this issue to be a FAQ. See

http://groups.google.de/group/comp.std.c++/browse_thread/thread/d27708b80758757b/f614be5ac67bde61?hl=de&#f614be5ac67bde61

and the discussion between him and me. However I have no idea how this
issue has evolved since then.


Best regards
Olaf Krzikalla

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]