C++ Logo


Advanced search

Re: [std-proposals] Attaching and detaching memory from std::vector or std::string

From: Tom Honermann <tom_at_[hidden]>
Date: Mon, 1 Jan 2024 18:52:43 -0500
The ability to transfer allocated memory between std::vector,
std::string, and other contiguous container/string types was discussed
in LEWG and SG16 back in 2018 in the context of P1072
(basic_string::resize_and_overwrite) <https://wg21.link/p1072>. No
consensus for a design emerged at that time but I think a well
researched paper that includes motivation based on real world use cases
would have a good chance of being adopted. Any such paper would ideally
compare and contrast the proposed design with the existing node handle
support added for associative containers in C++17 (I tend to think of
std::vector and std::string as being single-node containers; which
differs from other random-access containers like std::deque).


On 12/22/23 11:15 AM, ஜெய்கணேஷ் குமரன் via Std-Proposals wrote:
> Hello all,
> At the moment there appeärs to be no way to create a std::vector or std::string from an existing memory buffer, or take ownership of the memory owned by std::vector or std::string.
> This is very limiting in interoperability scenarios where you may not be able to expose a std::vector or std::string directly.
> Technically, a custom allocator could be used that provides existing memory but still the actual objects cannot are not considered.
> I propose having .attach and .detach member functions on std::vector and std::string.
> They should take in or return the following respectively, in a structure perhaps: pointer to the data (.data), count of the elements (.size/length), capacity of the buffer (.capacity) and the allocator instance.
> Note: I do not have the time to participate in standardisation in order to open formal proposals, but I wish someöne else does based on my ideas.
> Thanks,
> Jaiganésh Kumaran.

Received on 2024-01-01 23:52:44