Date: Tue, 11 Feb 2020 10:14:36 +0200
This is of somewhat limited use - only for the case when one needs to move
*all* members *and* do some work afterwards.
I am afraid, considering it is almost equivalent of having a base, this
will add further complexity that will not repay itself.
I also think the syntax might be confusing and in the case of operator=,
way to easily, lead to inf. recursion.
FWIW something like this is, I think, more clear
widget(widget&& o)
: default(std::move(o))
{
foo(a, b, c);
}
On Mon, Feb 10, 2020 at 10:36 PM Joseph Thomson via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> There are times when I wish to augment the default copy/move operations
> (e.g. logging; profiling; tracking the object as it's moved/copied).
> Currently, it's only possible to replace them completely, which means
> having to maintain the code that copies/moves the data members (and base
> classes).
>
> widget(widget&& o)
> : a(std::move(o.a))
> , b(std::move(o.b))
> , c(std::move(o.c))
> {
> foo(a, b, c);
> }
>
> widget& operator=(widget&& o)
> {
> a = std::move(o.a);
> b = std::move(o.b);
> c = std::move(o.c);
> foo(a, b, c);
> return *this;
> }
>
> Why not allow delegating to a compiler generated implementation? For
> example (tentative syntax):
>
> widget(widget&& o)
> : default widget(std::move(o))
> {
> foo(a, b, c);
> }
>
> widget& operator=(widget&& o)
> {
> default operator=(std::move(o));
> foo(a, b, c);
> return *this;
> }
>
> Of course, there are existing workarounds, like moving the data members
> into a separate struct or base class. But such boilerplate seems
> unnecessary when the compiler could (and would otherwise) easily generate
> it for you.
>
> Just floating the idea to see what people think.
>
> p.s. I did see a recent thread
> <https://lists.isocpp.org/std-proposals/2019/12/0810.php> proposing a
> similar idea, to automatically copy/move specific data members only. But my
> suggestion is about invoking the default behaviour wholesale rather than
> picking pieces of it. I believe the use cases are quite different.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
*all* members *and* do some work afterwards.
I am afraid, considering it is almost equivalent of having a base, this
will add further complexity that will not repay itself.
I also think the syntax might be confusing and in the case of operator=,
way to easily, lead to inf. recursion.
FWIW something like this is, I think, more clear
widget(widget&& o)
: default(std::move(o))
{
foo(a, b, c);
}
On Mon, Feb 10, 2020 at 10:36 PM Joseph Thomson via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> There are times when I wish to augment the default copy/move operations
> (e.g. logging; profiling; tracking the object as it's moved/copied).
> Currently, it's only possible to replace them completely, which means
> having to maintain the code that copies/moves the data members (and base
> classes).
>
> widget(widget&& o)
> : a(std::move(o.a))
> , b(std::move(o.b))
> , c(std::move(o.c))
> {
> foo(a, b, c);
> }
>
> widget& operator=(widget&& o)
> {
> a = std::move(o.a);
> b = std::move(o.b);
> c = std::move(o.c);
> foo(a, b, c);
> return *this;
> }
>
> Why not allow delegating to a compiler generated implementation? For
> example (tentative syntax):
>
> widget(widget&& o)
> : default widget(std::move(o))
> {
> foo(a, b, c);
> }
>
> widget& operator=(widget&& o)
> {
> default operator=(std::move(o));
> foo(a, b, c);
> return *this;
> }
>
> Of course, there are existing workarounds, like moving the data members
> into a separate struct or base class. But such boilerplate seems
> unnecessary when the compiler could (and would otherwise) easily generate
> it for you.
>
> Just floating the idea to see what people think.
>
> p.s. I did see a recent thread
> <https://lists.isocpp.org/std-proposals/2019/12/0810.php> proposing a
> similar idea, to automatically copy/move specific data members only. But my
> suggestion is about invoking the default behaviour wholesale rather than
> picking pieces of it. I believe the use cases are quite different.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2020-02-11 02:17:27