I don't see any particular reason why you can't provide all of them, though (even the implicit conversion), as different things are going to feel more natural to different people, particularly in different contexts.
There's a problem with implicit conversion. imagine the overloads function: void foo(std::string const& s); The we have a "joining engine" with various useful implicit conversions: struct engine { operator std::string const& () const; operator std::string_view () const; operator const char*() const; }; We have the code: foo(join(...)); And all is well. The string conversion is chosen. Then because of user performance concerns around the construction of strings, the author of the foo library adds some useful overloads: void foo(std::string_view s); void foo(const char* s); Now the above code will not compile, because there are 3 ambiguous overloads. So users are forced to modify their code to: foo(std::string_view(join(...))); or foo(to_string_view(join(...))); or, much as I dislike the idea, foo(join(...).strview()); The moral of the story is that if we are going to provide conversion operators, they need to be explicit anyway. If you're going to have explicit conversion operators, it is just as expressive to have the to_xxx free functions. It's no more typing, because what you lose in typing to_, you gain in not having to prefix the type with std:: (no-one uses using namespace std; here, right? It doesn't play well with boost). In return, you get decoupling. This means that if you later want to convert the formatted text to a vector (say) or a vector of terms, you can simply provide the free function overloads to_vector(), to_vector_of_strings() and so on. Template specialisations of free functions are always a bad idea - they don't play nicely with ADL. So I would not recommend convert<std::string>(join(...)) etc. R On 25 January 2017 at 23:55, Gavin Lambert <gavinl@compacsort.com> wrote:
On 26/01/2017 05:23, Christof Donat wrote:
to_string(x) is better than x.str() is better than implicit conversion.
Maybe it is just my strong distaste of the name to_string(), which at the moment is just a feeling, no good reasons. It just feels clumsy to me, while .str() is in line with regular expression matches, and stringstreams in the standard library.
Clumsy or not, it's in the standard now. [1]
str() is shorter, of course. I don't see any particular reason why you can't provide all of them, though (even the implicit conversion), as different things are going to feel more natural to different people, particularly in different contexts.
[1] http://en.cppreference.com/w/cpp/string/basic_string/to_string
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost