C++ Logo


Advanced search

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

From: Sébastien Bini <sebastien.bini_at_[hidden]>
Date: Mon, 5 Sep 2022 14:29:04 +0200
Hi Edward,

Thank you for the thorough explanation. That should keep me busy for
quite some time :)

Unfortunately, I and the company I work for (Stormshield) are not
affiliated with any standards organization. Would you or anyone on this
list have some documents describing that standardization process?

This being my first proposal, and quite a large one, it would be a gargantuan
task to carry it on my own. I hope that, as it gets more light, more people
(hopefully standardization champions) will bring their support (just like
you have been doing).

Thank you for your help with this proposal. I'll gladly contact you when I
have a complete draft. Thank you again!

Best regards,

On Mon, Aug 29, 2022 at 6:42 PM Edward Catmur <ecatmur_at_[hidden]>

> On Wed, 24 Aug 2022 at 09:59, Sébastien Bini <sebastien.bini_at_[hidden]>
> wrote:
>> Well, unless I am missing something, it looks like we clarified all the
>> blocking points so far? Thanks for your help in moving this forward!
>> What are the next steps? I guess another revision of the proposal needs
>> to be written?
> Yes, another revision of the proposal, ensuring that it covers:
> - acknowledgement of and references to previous and current proposals
> in the space
> - motivations (performance, safety/correctness, composability) with
> explanation why other proposals fall short
> - justification for each of the subfeatures: relocating constructor,
> relocating assignment operator, reloc keyword, try-with-init
> - specification of special member functions when (a) unspecified, (b)
> declared as defaulted, (c) defined as defaulted, (d) deleted, (e)
> user-defined; their interactions with the presence and noexcept
> qualification of the other special member functions; and the behavior of
> the user-defined relocating constructor for bases-and-members not specified
> - specification of reloc operator with regard to: loops; gotos;
> branches; sequencing within expressions; logical and ternary conditional
> expressions; hiding; error detection (making subsequent use ill-formed, not
> just UB); discarded-value expressions; function parameters vs. local
> variables
> - discussion of ABI implications and steps taken to ensure that ABI
> does not break unexpectedly and that Standard Library (and third-party
> library) implementations can attain as much benefit as possible consistent
> with preserving ABI
> - discussion of implementation techniques for relocating assignment
> operator: destroy-and-rebuild, copy-and-swap (and Just Swap), union
> technique (for the overconfident)
> - suggestions for type traits and concepts
> - suggestions for additional API for Library containers to make use of
> this feature (e.g. optional::pop, T vector::pop_back,
> make_from_tuple(prvalue))
> - suggestions for internal changes to Library (e.g. vector making use
> of trivial relocation to reallocate) possibly affecting Library API in
> visible ways (e.g. noexcept)
> - identification of further direction: defaultable swap (with Library
> interaction), perfect forwarding of prvalues
> - example code, written in terse, non-motivating style (single-letter
> or meaningless class, variable and function names) suitable for insertion
> into the Standard to clarify points and serve as implementer test cases
> Ideally we would also have a sample/reference implementation, compiler and
> standard library, along with test cases; I may be able to devote some time
> to this.
> Hopefully it goes without saying that the proposal should have its source
> text version-controlled and be typeset in a recognized style; many people
> use Bikeshed (https://tabatkins.github.io/bikeshed/) which takes Markdown
> and outputs HTML, while others use LaTeX outputting to PDF (I'm not sure
> exactly what styles they use).
> With regard to motivation, I would suggest starting with the existence of
> types that are (trivially) relocatable but not movable, e.g.
> gsl::non_null<std::unique_ptr<T>>, noting that these types are currently
> practically unusable despite being important to correctness, then noting
> that while the other outstanding proposals for trivial relocation would
> make some uses possible, they would no longer be composable with other (non
> trivially-relocatable) types, the situation requiring a relocation
> operation with appropriate (memberwise) behavior for aggregate (Rule of
> Zero) class types and the possibility of user-defined behaviors (e.g. for
> std::string). Then noting the additional requirement of a relocating
> assignment operation (since the copy and move assignment operations require
> the source object to be left in a destroyable state), and arguing for
> relocating constructor and assignment operator with respective signatures
> of T(T) and T& operator=(T) by parallel with the tripartite classification
> of value categories, and apologetics for the parameter aliasing its
> argument. Then demonstration of how this syntax can be used to accomplish
> the (mostly performance) goals of trivial relocatability (by defaulting the
> relocating constructor at declaration). Then discussion of why the reloc
> keyword is necessary to work with relocatable non-movable values, and
> demonstration of how it adds value by preventing bugs (use of moved-from
> variables, when used in place of std::move). Justification of
> try-with-init can probably wait until specification of the relocating
> assignment operator.
> Finally, are you affiliated with ISO/IEC JTC1 SC22 WG21, possibly via your
> National Body (NB, your national standards organization)? While supposedly
> not an absolute necessity, in practice it's essential for a proposal
> (especially one as wide-ranging as this one) to have (multiple) champions
> with formal affiliation and a record of participation, ideally both au fait
> with the standardization process and having prior experience successfully
> getting features into the Standard.
> Feel free to contact me here or off-list to write or review parts of the
> proposal; for assistance getting it published; or if you have thoughts
> about a sample/reference implementation. Good luck!
> Ed Catmur

Received on 2022-09-05 12:29:17