cbeck88
commented
6 years ago Another minor issue with frozen::string that we have encountered at tesla:
- We are now often using
frozen::stringto hold tables of configuration info. Sometimes, that includes strings that we need to be able to pass to C libraries. - However,
frozen::stringdoes not have ac_strmember function. It hasdata(), but the interface doesn't guarantee that thefrozen::stringis 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.)
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 parsingstd::regex: for frozen regex string parsingMaybe we could write a frozen implementation and see how it compares to the runtime version. What do you think ?