czw., 11 lut 2021 o 18:26 Maciej Polanski via Std-Discussion
<std-discussion_at_[hidden]> napisał(a):
>
>
> On 2021-02-11 12:06, Marcin Jaczewski via Std-Discussion wrote:
> >
> > My favorite is:
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1029r3.pdf
> > It make effecitve "destructive move" using AS-IF rule becasue moved
> > out object dectructor is noop.
> > In case of vector you can simply `memcpy` data and only deallocate old memory
> > (same effect as value init all old memory and then calling destructor
> > and deallocation).
>
> Thanks, I didn't know this proposal!
>
> But I do not think it allows me to freely "memcpy", as elison depends on
> compiler optimization and I do not know result of it.
>
> It seems that having "bitcopies" constructor does not guarantee empty
> destructor, nor lack of side effects of destructing empty object. It had
> to be found by compiler during optimization.
>
> Correct me if I am wrong, but if I was a library programmer, I wouldn't
> be able to find if I am allowed to memcpy of given class or not. Solely
> having "bitcopies" constructor is not enough.
>

Yes, on its own you cannot know if this enabled,
but this proposal add needed functionality:
```
std::is_move_constructor_bitcopying<T>
```

With this you can ask compiler if given type supports this.


Overall destructor can be complex as much you want (or even virtual function)
but it need be effective noop for default constructed object,
otherwise you will get UB.

Another thing is that this allows copying objects through pure C.


> Thanks,
> Maciej
>
>
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion