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

6 Dec 2019

      On 2019-12-06 01:28, Peter Koch Larsen wrote:
...
On Thu, Dec 5, 2019 at 9:45 AM Andrey Semashev via Boost
 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 _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> 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.