Templated json::value?

Jun 3, 2015 at 4:25 PM
It seems that making utility::string_t a wide character string on Windows and not providing JSON facilities for narrow strings there hurts this platform. HTTP responses contain narrow strings on each platform, including Windows. And most of JSON parsing is done on data contained in these responses. While std::string to/from utility::string_t conversion is free for other platforms, it causes totally unnecessary run-time overhead on Windows.

Wouldn't it be beneficial to have all JSON classes, including the parser, templated? Then, both narrow and wide string based JSON can be processed without any string type conversion overhead.

Are there any arguments against this (besides the work needed to be done)?
Shouldn't Microsoft help their own platform? ;-)

Jun 3, 2015 at 6:32 PM
Hi Boris,

Back at the beginning of this project a design decision was made that strings would be UTF-16 on Windows. I completely agree that in most cases strings coming across the network are going to be UTF-8. Ideally we'd have equal support for both UTF-8 and UTF-16. In some portions of the API we've made these changes. For example in with the HTTP portions of the library we have support for both UTF-8 and UTF-16 regardless of platform. The http_response class contains methods (extract_utf8string, extract_utf16string) for retrieving the message body.

The JSON portions of the library have not received such updates. Underneath the parsing already handles both UTF-8 and UTF-16. I'm not sure that making json::value be a template is the best option for making that change now as it would break nearly every existing program already using the C++ REST SDK, but yes I agree there is no reason we wouldn't like to have UTF-8 supported on Windows. If you wanted to take a look at making improvements the changes would gladly be welcomed.

Jun 3, 2015 at 8:07 PM
Edited Jun 3, 2015 at 8:41 PM
Hi Steve,

Thank you for explaining the design rationale.

I think your concerns that templatizing JSON classes would break source code compatibility are unsubstantiated.
It should be pretty easy to introduce a new template, then create an alias matching the old, non-template, name.
For example:
namespace web {
  namespace json {
      template<typename CHART> class valueT {
      using value        = valueT<wchar_t>;
      using narrow_value = valueT<char>;
The existing code with web::json::value will still compile and work as before.

Jun 5, 2015 at 1:11 AM
Hi Boris,

Yes potentially something like that could be done. It would have to be a bit more complex as the utility::string_t type is different depending on the platform. The json::value type needs to stay the same, but two additional types to be explicitly UTF-8 and UTF-16 could be created. Something like the following:
using value = valueT<utility::string_t::value_type>;
using valueutf8 = valueT<char>;
using valueutf16 = valueT<utf16char>;