Boost logo

Boost :

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


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));


> 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
>> 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:



Boost list run by bdawes at, gregod at, cpdaniel at, john at