Date: Mon, 23 Jun 2025 19:24:47 +0100
To keep the "object model" people happy, there could be a standard library
type as follows:
std::basic_string_nocopy;
Its constructor could be:
template<size_t N>
consteval basic_string_nocopy( value_type const (&arg)[N] );
And it could have a member function called "str" which returns a reference
to a const std::string.
The standard could simply mandate that when the string_nocopy object is
created, an std::string object is also created, and the lifetime of the
std::string object is the same as the lifetime of the string_nocopy object.
Furthermore the standard could mandate that explicitly calling the
std::string destructor on the enclosed std::string object is undefined
behavior, just in case any wild west gun slinger tries something like:
string_nocopy obj("Hello");
string const &s = obj.str();
const_cast<string&>(s)->~string();
type as follows:
std::basic_string_nocopy;
Its constructor could be:
template<size_t N>
consteval basic_string_nocopy( value_type const (&arg)[N] );
And it could have a member function called "str" which returns a reference
to a const std::string.
The standard could simply mandate that when the string_nocopy object is
created, an std::string object is also created, and the lifetime of the
std::string object is the same as the lifetime of the string_nocopy object.
Furthermore the standard could mandate that explicitly calling the
std::string destructor on the enclosed std::string object is undefined
behavior, just in case any wild west gun slinger tries something like:
string_nocopy obj("Hello");
string const &s = obj.str();
const_cast<string&>(s)->~string();
Received on 2025-06-23 18:24:50