Re: [boost] Variadic append for std::string

Subject: Re: [boost] Variadic append for std::string
From: Richard Hodges (hodges.r_at_[hidden])
Date: 2017-01-26 04:47:54

> 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_at_[hidden]> 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
>