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-24 06:52:25

Answers to answers inline :)

On 24 January 2017 at 12:17, Christof Donat <cd_at_[hidden]> wrote:

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

I probably meant:
foo(to_string_view(concat("the answer to life, the universe and everything
is: ", hex(42))));
or
foo(to_string_view(join(separator(' '), "the answer to life, the universe
and everything is:", hex(42))));

The idea being to avoid the construction of any un-necessary string
objects. The generator already contains a buffer (or could) so it seems
wasteful to me to create a string temporary simply to view its buffer.

I personally prefer the limited-scope manipulators. They feel more portable
and less surprising when, for example, refactoring or merging code.

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

A string, a string-like buffer, or a reference to a string. I feel that the
generator should be able to work on a supplied string reference so that it
can be used to extend an existing string without reallocations or copies if
required.

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

Maybe to_utf8(concat(...)); would be better. It's again explicit and could
be given options to control behaviour. It also decouples the concept of
UTF8 from the concept of concatenation. This adheres more to the c++ way of
only paying for what you need.

>
>
> Christof
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman
> /listinfo.cgi/boost
>