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

Subject: Re: [boost] Variadic append for std::string
From: Christof Donat (cd_at_[hidden])
Date: 2017-01-24 06:17:01

Hi,

Am 24.01.2017 11:29, schrieb Richard Hodges:
> On 24 January 2017 at 10:45, Christof Donat <cd_at_[hidden]> wrote:
>> Sorry for the unfinished mail. I just was unable to handle my mail 
>> client
>> correctly :-(
>> 
>> Am 24.01.2017 10:07, schrieb Richard Hodges:
>> 
>>> It seems to me that since c++17 is going to have string_view, and 
>>> boost
>>> already does, then there should be a to_string_view free function to
>>> return
>>> the view of a temporary.
>> 
>> But where will the temporary live then? Someone will have to free the
>> memory.
> 
> Imagine a function:
> 
> void foo(std::string_view s);
> 
> which we then call with:
> 
> foo(join("the answer to life, the universe and everything is: ", 
> hex(42)));

Did you mean

foo(concat(hex<int>, "the answer to life, the universe and everything 
is: ", 42));

? SCNR.

> The generator returned by join would stay alive until the end of the
> function foo, so there would be no need to construct a string, only to 
> take
> a string_view of it. We could use the string_view implicit in the 
> joiner
> object. This saves us an allocation and a copy.

I see. So the string would live inside the string factory as a member 
object, when we implicitly convert to a string_view. With C++17 
std::string will have an implicit conversion operator to 
std::string_view. So this will be sufficient:

foo(std::string{concat("the answer to life, the universe and everything 
is: ", hex(42))});

>> basic ADL interface something like this:
>> 
>> I didn't get that part. What exactly does ADL stand for?
> 
> ADL stands for Argument Dependent Lookup. It means that when you call a
> free function, the namespaces of its arguments are searched for that
> function. This means that you can write operator<<, to_string, 
> hash_code
> etc in the namespace of your custom object and the compiler will select 
> the
> correct one.

Ah, I see. Thank you. I was aware of the mechanism, but not of the name.

>>> Furthermore, since the entire web is now (thankfully) UTF8, I 
>>> strongly feel
>>> that there should be a utf8 version, which accepts wide and narrow 
>>> strings
>>> and emits them correctly.
>> 
>> UTF-8 is 8 bits only. Just some characters take more than a single 
>> byte.
>> See https://en.wikipedia.org/wiki/UTF-8
>> 
>> Anyway, I agree, that we should have a wide char version as well for
>> UTF-16 support.
> 
> I have no problem with a u16 version (UTF-16) for the windows crowd and 
> a
> u8 version (UTF-8) for everyone else. The standard supports this idea 
> in
> its unicode specialisations of std::string - std::u16string and
> std::u32string. A utf-8 string is just a std::basic_string<char> with
> utf-aware traits type.

Yes, but I don't get why you want wide string versions for 
UTF-8-support. I sit about converting wide string to utf8? Like this:

std::string{concat(my_wide_string)};

Christof