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

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2019-12-05 00:01:04

On 2019-12-05 02:45, Andrey Semashev wrote:
> On 2019-12-05 02:30, Peter Koch Larsen wrote:
>> On Thu, Dec 5, 2019 at 12:07 AM Andrey Semashev via Boost
>> <boost_at_[hidden]> wrote:
>>>
>>> C compatibility beyond zero termination of strings is non-existant. You
>>> have that special convention, and that is fine, but that convention is
>>> not standard and only you know and follow it. No C function would be
>>> able to use that extra information without explicit support. You special
>>> use case does not make an argument for designing a general utility like
>>> fixed_string.
>> It is not a convention. It is a question of enforcing a memory size
>> and a layout.
>> For embedded systems, this can be important. We have types that are
>> required to be standard layout and have a alignment of 1 - something
>> that we enforce programmatically.
> 
> When you need a specific memory layout, you should use a specialized 
> structure or direct byte-wise memory accesses. No general purpose 
> utility guarantees any particular binary representation, and neither 
> should fixed_string.
> 
>> I believe that fixed_string is sufficiently specialised to also take
>> embedded development into consideration.
> 
> 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.
> 
>>> Â  From the space standpoint, there is little difference between N and 
>>> N+1
>>> or even N+4 or N+8 bytes for a fixed_string<N> object. Given this, it is
>>> preferable to choose a data layout that is more efficient in terms of
>>> memory accesses and computation complexity on typical use.
>> It is not just N + 4 or N + 8. Considering alignment restrictions it
>> could be N + 7 or N + 15. This is significant and also a waste of
>> cache.
> 
> If you place the size before the array, you will normally not have 
> unused space between the size and the storage because the alignment of 
> the storage is less than that of the size. You can only have alignment 
> gap up to 3 bytes if the size alignment is lower than that of the 
> character type (i.e. that means the worst case of fixed_string<N, 
> char32_t> will have size of N+4, if the size is represented by 1 to 4 
> bytes, and N+8, if it is 8).

Sorry, that should be N*sizeof(char32_t)+4 and N*sizeof(char32_t)+8, 
respectively.