sprintf / sscanf / std::regex frozen version

[jaydee-io]

Recently, I was writing a simple Syslog viewer. Basicaly, it's a simple UDP server receiving syslog packets, which are parsed with a regex, formatted using constant format string and then displayed to the console. To avoid parsing the constant format string on each packet, I wrote a custom constexpr formatter taking constexpr formatting string and building at compile time a list of 'formatting action' that are executed at runtime for each packet. For now, I didn't check if it's more efficient than parsing the format string on each packet.

But it makes me wonder that it could be worthy to have frozen implementation of :

• sprintf / snprintf / sscanf : for frozen format string parsing
• std::regex : for frozen regex string parsing

Maybe we could write a frozen implementation and see how it compares to the runtime version.
What do you think ?

[cbeck88]

Another minor issue with frozen::string that we have encountered at tesla:

• We are now often using frozen::string to hold tables of configuration info. Sometimes, that includes strings that we need to be able to pass to C libraries.
• However, frozen::string does not have a c_str member function. It has data(), but the interface doesn't guarantee that the frozen::string is actually null terminated.
• That's very awkward -- we basically only use it with string literals, and so we end up using data() and assuming that the pointer is to a null terminated string, but it's not really very safe.

We are implementing a completely different class now, following a Stackoverflow answer by Nicol Bolas: https://stackoverflow.com/questions/41286898/using-stdstring-view-with-api-what-expects-null-terminated-string/41288372#41288372

The idea is that zstring_view the same as string_view, except that it promises that the string is null-terminated, and doesn't allow operations that could break that guarantee -- or, it may allow them, but yield string_view instead of zstring_view if the guarantee would be lost. Then, zstring_view::c_str() strings are always safe to pass to C apis.

And, zstring_view can be constexpr just like frozen::string.

After we have that, I can't see that there's any use-case for frozen::string, since we almost always use a frozen::string with string literals, and indeed, the frozen::string doesn't own its const char *, it is basically the same as string_view anyways.

I think frozen::string might have a niche to exist if it were like a fixed_string that owned a character array as a class member, and so guaranteed that the pointer would not go out of scope. If it doesn't work like that, it's going to be pretty hard to implement a formatting library based on frozen::string anyways, since how do you concatenate two strings for instance and make a new frozen string that points to the result? You can't just make a dynamic allocation inside a constexpr function. It would have to be pretty complicated if it is possible.

I think if I had to do this, I would attempt to basically convert a frozen string to a hana::string at compile-time, which means you get a new object where the characters are lifted to be template parameters, then concatenate them using variadic templates, then use variable templates to allocate a character array big enough to hold the result, and make the new frozen::string point to that. But that is a lot of work for the compiler. Using a fixed_string class is probably a lot better in terms of constexpr compile-times, not to mention readability and maintainability. (Also I don't know if this plan would actually work out.)