Date: Mon, 2 May 2022 20:02:29 +0100
On Mon, 2 May 2022 at 16:35, Sébastien Bini <sebastien.bini_at_[hidden]>
wrote:
> > Yes, I recognize the issue. This can be resolved by stating that
> implementations may refuse to relocate function parameters, and providing a
> mechanism (e.g. an attribute) for the author to switch ABI to
> callee-destroy.
>
> It's more complicated than that. If relocation also destructs objects,
> then you allow for a new category of unmovable objects to support
> relocation. For example, std::lock_guard could be relocatable with no
> change.
> Then how do you deal with this?
>
> void foo(lock_guard<mutex> lg);
> void fwd_to_foo(lock_guard<mutex> lg) { foo(reloc lg); }
> void bar(mutex& m)
> {
> std::lock_guard lg{m};
> fwd_to_foo(reloc lg);
> }
>
> This code will work fine if reloc avoids the destructor call. But it will
> not if "implementations refuse to relocate", as lock_guard is not movable.
>
That's why I suggested there could be a mechanism to switch to
callee-destroy, perhaps at function declaration or single argument level.
We cannot have code optionally compile depending on which ABI we pick, can
> we?
>
This would hardly be unprecedented; I would suggest reviewing the index of
implementation-defined behavior <http://eel.is/c++draft/impldefindex>.
wrote:
> > Yes, I recognize the issue. This can be resolved by stating that
> implementations may refuse to relocate function parameters, and providing a
> mechanism (e.g. an attribute) for the author to switch ABI to
> callee-destroy.
>
> It's more complicated than that. If relocation also destructs objects,
> then you allow for a new category of unmovable objects to support
> relocation. For example, std::lock_guard could be relocatable with no
> change.
> Then how do you deal with this?
>
> void foo(lock_guard<mutex> lg);
> void fwd_to_foo(lock_guard<mutex> lg) { foo(reloc lg); }
> void bar(mutex& m)
> {
> std::lock_guard lg{m};
> fwd_to_foo(reloc lg);
> }
>
> This code will work fine if reloc avoids the destructor call. But it will
> not if "implementations refuse to relocate", as lock_guard is not movable.
>
That's why I suggested there could be a mechanism to switch to
callee-destroy, perhaps at function declaration or single argument level.
We cannot have code optionally compile depending on which ABI we pick, can
> we?
>
This would hardly be unprecedented; I would suggest reviewing the index of
implementation-defined behavior <http://eel.is/c++draft/impldefindex>.
Received on 2022-05-02 19:02:42