Open jm4R opened 3 years ago
Personally I don't believe this falls within the scope of the library, but I'd like to see what @vinniefalco and/or @pdimov have to say on the matter.
static_cstring
might be useful, but its interface should probably be slightly different.
Without taking an opinion on whether the functionality is in scope, I would say that a new class is preferable to adding more template parameters to the existing class. In any event, we're in the middle of a release cycle so now might not be the best time to add anything :)
Current design doesn't guarantee anything about space occupied by
static_string<N>
. User can't assume thatsizeof(basic_static_string<N, CharT>) == (N+1) * sizeof(CharT)
(norsizeof(basic_static_string<N, CharT>) == N * sizeof(CharT)
asN
doesn't take final null-terminator into account) because the class stores additionalsize_
field. This is a good thing forstd::string
compatibility which doesn't assume that stored string can't have null characters.On the other hand, there are still situations where null-terminated cstring-wrapper could be handy. To show the example, we can have a pseudo-POD structure with standarized layout:
Such structures requires using non-modern C functions (like
std::strncpy
) to fill it. This could be replaced with something more handy:...where
boost::cstring
is a working name of a hypothetical specific class with a strong guaranty that underlying object stores only aCharT
array of sizeN+1
(orN
, depending on further design) and therefore that objects of that class are trivially copyable.Implementation of such class doesn't seem to be a hard work - most of existing code could be reused, only
static_string_base
should be conditional. To ilustrate possible design:Wandbox link
The question is: could such new functionallity be in scope of this library? Would you accept PR with such extension?