Re: [review][fixed_string] End of review periodapproaching and a plea

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2019-12-06 00:17:08

On 2019-12-06 01:28, Peter Koch Larsen wrote:
> On Thu, Dec 5, 2019 at 9:45 AM Andrey Semashev via Boost
> <boost_at_[hidden]> wrote:
>>
>> On 2019-12-05 06:09, Gavin Lambert via Boost wrote:
>>> On 5/12/2019 12:45, Andrey Semashev wrote:
>>>> fixed_string can be optimized for speed or space considerations, which
>>>> may play in favor of embedded systems, but it should not be
>>>> specialized to embedded systems, let alone to a specific memory layout.
>>>
> What do you mean by specialized? It is designed to also favour embedded systems.

"Specialized" means catered to a specific use case.

You can implement fixed_string many ways, and as long as it doesn't 
perform dynamic memory allocations I would call it "favoring embedded 
systems". Requiring it to have a specific binary representation is 
something else entirely.

>>> But when one of the stated design goals is to target "embedded
>>> environments without a free store", it seems reasonable to consider the
>>> memory layout of the type quite closely.
>>
>> Yes, but only from the implementation efficiency perspective, which is
>> my point.
> 
> Why? There are two goals: usability and efficiency. You should weight
> these and not just unconditionally focus on one aspect.
> In practice I believe that efficiency will not suffer measurably no
> matter how you represent the length.

I'm not discussing usability because from the API perspective, usability 
is the same regardless of how you store the size internally.

>>> Wouldn't it be nice if you could replace "d" with a fixed_string<32> (or
>>> <31>, depending on how you count the null terminator), and preserve all
>>> of those properties, while gaining the string methods?
>>
>> No, unless you write your own fixed_string, which guarantees the
>> specific memory representation you require.
> 
> Or it is provided by boost?

If you name it <your_representation_name_here>_string and document it as 
a string that is targeted specifically to your use case, and there are 
enough reviewers interested in it - sure. Though personally I don't 
think Boost would be the right place for such a component since Boost 
libraries tend to be general purpose, even if within their specific domains.

fixed_string, as I understand it, is a more or less generic string, 
which is basically a counterpart of static_vector, that's it. Don't try 
to make it something else, please.

>> You can't replace it with a
>> general purpose fixed_string, which was not written for your specific
>> use case and is not required to maintain your required memory
>> representation. Just as well as you can't replace ImportantData with a
>> std::tuple<int32_t, int16_t, int16_t, std::array<char, 32>> and expect
>> it to preserve the memory layout. It may actually do preserve, but by a
>> pure coincidence.
> 
> There is not such a guarantee for std::tuple. This is not a surprise -
> we program against a standard.

Right. IMO, there shouldn't be such a guarantee for fixed_string either.