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

Answers to answers inline :) On 24 January 2017 at 12:17, Christof Donat wrote:

Hi,

Am 24.01.2017 11:29, schrieb Richard Hodges:

...

On 24 January 2017 at 10:45, Christof Donat 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