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

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 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 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.