C++ Logo


Advanced search

Re: [std-proposals] Relocation in C++

From: Edward Catmur <ecatmur_at_[hidden]>
Date: Mon, 2 May 2022 20:02:29 +0100
On Mon, 2 May 2022 at 16:35, S├ębastien Bini <sebastien.bini_at_[hidden]>

> > 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