1. Forum
  2. Usenet
  3. COMP.LANG.C++

  • Returning small strings as std::array

    From Marcel Mueller@21:1/5 to All on Sat Mar 9 11:09:12 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paavo Helde@21:1/5 to All on Sun Mar 10 16:35:57 2024
    09.03.2024 12:09 Marcel Mueller kirjutas:
    Is it reasonable to return small strings a std::array to avoid copying?

    No, I believe it's not reasonable as it would complicate the code and
    make it less readable, probably without any measurable benefit whatsoever.

    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?


    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.

    Seems like a perfect example of premature optimization. If your
    application really requires to win these hypothetical nanoseconds, then
    you should probably write your own string class tuned to maximum
    performance for that particular application.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marcel Mueller@21:1/5 to All on Sun Mar 10 17:17:35 2024
    Am 10.03.24 um 15:35 schrieb Paavo Helde:
    std::string might require allocation if it has no small string
    optimization build in.

    All mainstream C++ implementations are using small string optimization nowadays.

    Yes, it seems so.
    Several years ago it was not implemented on platform.

    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.


    Marcel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paavo Helde@21:1/5 to All on Sun Mar 10 18:43:01 2024
    10.03.2024 18:17 Marcel Mueller kirjutas:

    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.

    Your information is out of date for 13 years formally, and more than
    that in practice. The C++11 standard added a guarantee that the string
    internal buffer is contiguous, and it also added a non-const overload of data(), so you can write freely in the string via str.data(). One can
    even write the terminating zero at str.data()[str.length()] (but no
    other value), meaning one can even use strcpy() for writing.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrey Tarasevich@21:1/5 to Marcel Mueller on Mon Mar 11 22:57:41 2024
    On 03/09/24 2:09 AM, Marcel Mueller wrote:
    std::string might require allocation if it has no small string
    optimization build in.

    True. SSO is not required, but virtually all competent implementations
    do it.

    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]`).

    You can pre-`resize()` an `std::string`, pass its `data()` (and `size()`
    ) to a C function, determine the resultant length based on zero
    terminator's location, and then `resize()` it to the new length.

    Done.

    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?

    If you are sure that they will always fit into the pre-determined (at
    the compile time) size, then perhaps it might be reasonable. Basically,
    the main benefit I can see here is that it allows one to extend SSO-like behavior beyond the boundary used by the existing `std::string`
    implementation. I.e to avoid involving dynamic memory for a greater
    range of string lengths.

    --
    Best regards,
    Andrey

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marcel Mueller@21:1/5 to All on Thu Mar 14 20:42:54 2024
    Am 12.03.24 um 06:57 schrieb Andrey Tarasevich:
    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]`).

    Thanks, I was not aware of the latter!

    The application is restricted to C++11. (I forgot to mention.)


    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.

    Yes, if the C-API has a size parameter, I am quite sure. ;-)


    Marcel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)