Wide, narrow strings - API criticism / suggestion

Question

Guys,

I’ve been playing with the library for a couple of days and I like it, thank you!

But, I think it lacks some consistent strategy when dealing with various character types.

Some methods accept only wstring, others string and wstring, some only http:uri::encoded_string.

e.g uri_builder constructor:

    _ASYNCRTIMP uri_builder(const std::wstring &scheme, const uri::encoded_string &host, const int port);

One must remember to provide a wide string for the first argument and encoded string for the second, like this:

        http::uri_builder ub(L"http", http::uri::encoded_string("foo.org"), 80);

It would be better if it were possible to write:

        http::uri_builder ub(L"http", L"foo.org", 80); // wide strings

OR

        http::uri_builder ub("http", "foo.org", 80); // narrow strings

--

Next, it looks most of the library types have to_string and to_wstring,

but  http::uri::encoded_string has only to_string(), that returns a wide string instead of std::string.

--

There are lots of places like this through the code, e.g. differences in bind for uri_tokenizer and http_headers:

uri_tokenizer:

    template<typename _char_t, typename _t>

    bool bind(const std::basic_string<_char_t> &text, _t &ref); // 1st arg -- any string

http_headers:

    template<typename _t>

    bool bind(const std::wstring &text, _t &ref) const; // 1st arg -- only wstring

...

Please be consistent.

e.g. make every member function a template that accepts any character string, like:

template <typename Source>

void func(const Source& src);

template <typename Source, typename T>

bool bind(const Source& src, T& ref);

template <typename Source>

_ASYNCRTIMP uri_builder(const Source &scheme, const Source &host, const int port);

That will simplify the usage, reduce public interface and make library users happy :)

Or select some other strategy. But be consistent.

Thank you!

Answer 1

Thanks for your input (once again :-)) !

We are both acutely aware and embarrassed by these inconsistencies.

Yes, this is one of the blemishes on our libraries. We started out with single-byte strings, then started a migration to wide-char strings but didn't have time to finish it before releasing and we decided not to hold up the release.

Hopefully, it won't turn you completely off. It is something we will address.

Niklas

Answer 2

yeah, that's ok,

thank you for reply!

Answer 3

since the domain (web services) is dominated by utf-8 encoding, and the vision is to become a de-facto/standard cross-platform library (I really hope so!), wouldn't be better to have everywhere in the API interface just std::string expecting utf-8 encoded text?

By the way, thank you for Casablanca and keep up with the good work!