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

24 Jan 2017

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

? 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