You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, basic_json expects one string type, which is used for everything - arguments, temporary strings, etc. This may be inefficient if data is available as some sort of a "string view". For example, if a C API offers a const char* value and a length integer, then it is possible to wrap these in a boost::string_ref instance. Since the JSON parser does not modify the source string, it would be possible to allow for specifying something like boost::string_ref as a "StringView" template typename, and std::string as a "String" type, which is then used internally.
The net gain is that a copy is avoided. In the example mentioned above, I have to create a temporary std::string and do a copy of the source string. With a StringView typename, I could avoid that copy.
The text was updated successfully, but these errors were encountered:
Currently, basic_json expects one string type, which is used for everything - arguments, temporary strings, etc. This may be inefficient if data is available as some sort of a "string view". For example, if a C API offers a const char* value and a length integer, then it is possible to wrap these in a boost::string_ref instance. Since the JSON parser does not modify the source string, it would be possible to allow for specifying something like boost::string_ref as a "StringView" template typename, and std::string as a "String" type, which is then used internally.
The net gain is that a copy is avoided. In the example mentioned above, I have to create a temporary std::string and do a copy of the source string. With a StringView typename, I could avoid that copy.
The text was updated successfully, but these errors were encountered: