Is it reasonable to return small strings a std::array to avoid copying? std::string might require allocation if it has no small string
optimization build in. Furthermore it cannot be initialized from old C
style APIs that require char* buffer and size_t buffer_size.
The idea is to return std::array<char,10> or something like that. This causes no allocation and the compiler should be able to optimize the
return value to emplace the result into the callers storage.
Any other idea?
Marcel
Is it reasonable to return small strings a std::array to avoid copying?
std::string might require allocation if it has no small string
optimization build in.
Furthermore it cannot be initialized from old C
style APIs that require char* buffer and size_t buffer_size.
The idea is to return std::array<char,10> or something like that. This causes no allocation and the compiler should be able to optimize the
return value to emplace the result into the callers storage.
std::string might require allocation if it has no small string
optimization build in.
All mainstream C++ implementations are using small string optimization nowadays.
Furthermore it cannot be initialized from old C style APIs that
require char* buffer and size_t buffer_size.
Cannot really understand this statement. Are you worrying about the
overhead of initializing 10 bytes in a std::string before calling a C
style API? Can you actually measure this overhead?
Furthermore it cannot be initialized from old C style APIs that
require char* buffer and size_t buffer_size.
Cannot really understand this statement. Are you worrying about the
overhead of initializing 10 bytes in a std::string before calling a C
style API? Can you actually measure this overhead?
The other way around. The C-API cannot write to a std::string because std::string once created with sufficient size can no longer be converted
to char*. So I always need a temporary char array to create std::string. AFAIR using &str.front() to write the string is not allowed.
std::string might require allocation if it has no small string
optimization build in.
Furthermore it cannot be initialized from old C
style APIs that require char* buffer and size_t buffer_size.
The idea is to return std::array<char,10> or something like that. This causes no allocation and the compiler should be able to optimize the
return value to emplace the result into the callers storage.
Is it reasonable to return small strings a std::array to avoid copying?
On 03/09/24 2:09 AM, Marcel Mueller wrote:
Furthermore it cannot be initialized from old C style APIs that
require char* buffer and size_t buffer_size.
That is not true.
A non-const version of `std::string::data()` was added in C++17
specifically to support this usage model. (But even before that you
could gain non-const access to its internal buffer through `&str[0]`).
Is it reasonable to return small strings a std::array to avoid copying?
If you are sure that they will always fit into the pre-determined (at
the compile time) size, then perhaps it might be reasonable.
Sysop: | Tetrazocine |
---|---|
Location: | Melbourne, VIC, Australia |
Users: | 6 |
Nodes: | 8 (0 / 8) |
Uptime: | 25:56:00 |
Calls: | 45 |
Files: | 21,492 |
Messages: | 63,126 |