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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk