Static str

[SlaaneshChosen]

There is a special kind of string, static_string, which behaves almost same as 'std::string' except that it has a fixed capacity. This kind of string is used for better performance, for it usually uses compile-fixed buffers and is POD. Here is an example, boost.static_string.

When applying static_string in glaze, however, thery are usually recognized as string_t. When we try to read static_string in glaze, an optimization static constexpr auto string_padding_bytes = 8; tryies to reserve extra memories for alignment, which may exceed the capacity of the 'static_string'. These behavior will cause some undefined behaviors and the program will crash.

In this PR, I try to show the usage of 'static_string' and fix this issue.

[sjanel]

I think we need to add resizable<T> && has_data<T>. It has fixed capacity, but not fixed size.

[sjanel]

data() should be added

[SlaaneshChosen]

To be more strict, you are right.

[SlaaneshChosen]

I have updated the concept; please check it.

[stephenberry]

Thanks for working on this. Glaze will treat a std::array<char, N> as a static string. But, I can see how support for custom static string types could be useful.

One thing that I think would be good to change is to rework the is_static_helper. I tend to think it is best to add fields to the glz::meta specialization, so that a single glz::meta can set multiple options like this and it consolidates template specializations to just glz::meta.

So, this:

template <size_t N>
 struct glz::detail::is_static_helper<naive_static_str_t<N>>: std::true_type{};

Would change to:

template <size_t N>
struct glz::meta<naive_static_str_t <N>>
{
   static constexpr auto glaze_static_string = true;
};

I try to also allow these definitions locally, so the naive_static_str_t class could define: static constexpr auto glaze_static_string = true;

You can make this change, or I can make it when I'm able. Thanks so much for this pull request!

[SlaaneshChosen]

yes, I think using 'glz::meta' is a more elegant way, for defining 'is_xxx_helper' classes arbitrarily will cause code's fragmentation. I have switched the concept implementation.

[stephenberry]

Thanks for the updates! I'll merge this in.