Variadic append for std::string

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
107 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

Variadic append for std::string

Olaf van der Spek-3
Hi,

One frequently needs to append stuff to strings, but the standard way
(s += "A" + "B" + to_string(42)) isn't optimal due to temporaries.
A variadic append() for std::string seems like the obvious solution.
It could support string_view (boost and std), integers, maybe floats
but without formatting options..
It could even be extensible by calling append(s, t);

append(s, "A", "B", 42);

Would this be useful for the Boost String Algo lib?


--
Olaf

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Variadic append for std::string

Billy O'Neal (VC LIBS)
Pretty please?


Also concat(stringy_things...)


Billy3
________________________________
From: Boost <[hidden email]> on behalf of Olaf van der Spek <[hidden email]>
Sent: Tuesday, December 27, 2016 6:47:33 AM
To: [hidden email]
Subject: [boost] Variadic append for std::string

[This is one of the first messages you've received from [hidden email]. Learn how we recognize email senders at http://aka.ms/LearnAboutSenderIdentification]

Hi,

One frequently needs to append stuff to strings, but the standard way
(s += "A" + "B" + to_string(42)) isn't optimal due to temporaries.
A variadic append() for std::string seems like the obvious solution.
It could support string_view (boost and std), integers, maybe floats
but without formatting options..
It could even be extensible by calling append(s, t);

append(s, "A", "B", 42);

Would this be useful for the Boost String Algo lib?


--
Olaf

_______________________________________________
Unsubscribe & other changes: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.boost.org%2Fmailman%2Flistinfo.cgi%2Fboost&data=02%7C01%7Cbion%40microsoft.com%7Ce8f9415a3f87491e848d08d42e675b57%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636184468831322908&sdata=wqjhaHLHfaeV0rw9xGlLdY2zHIWLtZdnew%2FwP%2F%2Fyf7A%3D&reserved=0

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Variadic append for std::string

Yakov Galka
In reply to this post by Olaf van der Spek-3
On Tue, Dec 27, 2016 at 4:47 PM, Olaf van der Spek <[hidden email]> wrote:

> One frequently needs to append stuff to strings, but the standard way
> (s += "A" + "B" + to_string(42)) isn't optimal due to temporaries.
>

Can't we already write it through (((s += "A") += "B") += to_string(42))?
This is the time I think that assignment operators, other than =, should
have had left associativitiy... pity they don't.


--
Yakov Galka
http://stannum.co.il/

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Variadic append for std::string

Nat Goodspeed-2
On Dec 28, 2016 7:20 PM, "Yakov Galka" <[hidden email]> wrote:

On Tue, Dec 27, 2016 at 4:47 PM, Olaf van der Spek <[hidden email]> wrote:

> One frequently needs to append stuff to strings, but the standard way
> (s += "A" + "B" + to_string(42)) isn't optimal due to temporaries.
>

Can't we already write it through (((s += "A") += "B") += to_string(42))?
This is the time I think that assignment operators, other than =, should
have had left associativitiy... pity they don't.


I think what's desired here is a two-pass approach in which append() or
concat() or whatever first figures out the final length required, allocates
that much storage, then appends into it with no further expansion.

When we say it should understand two kinds of string_view, etc., I assume
that the catch-all case for each arg would be "anything that can be treated
as a range of char_type."

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Variadic append for std::string

Olaf van der Spek-3
In reply to this post by Yakov Galka
On Thu, Dec 29, 2016 at 1:19 AM, Yakov Galka <[hidden email]> wrote:
> On Tue, Dec 27, 2016 at 4:47 PM, Olaf van der Spek <[hidden email]> wrote:
>
>> One frequently needs to append stuff to strings, but the standard way
>> (s += "A" + "B" + to_string(42)) isn't optimal due to temporaries.
>>
>
> Can't we already write it through (((s += "A") += "B") += to_string(42))?
> This is the time I think that assignment operators, other than =, should
> have had left associativitiy... pity they don't.

We can, but it's ugly and I'd like to avoid the explicit to_string. It
also wouldn't allow the two-pass optimization to calculate the final
length before allocation.


--
Olaf

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Variadic append for std::string

Olaf van der Spek-3
In reply to this post by Nat Goodspeed-2
On Thu, Dec 29, 2016 at 1:43 AM, Nat Goodspeed <[hidden email]> wrote:
> I think what's desired here is a two-pass approach in which append() or
> concat() or whatever first figures out the final length required, allocates
> that much storage, then appends into it with no further expansion.
>
> When we say it should understand two kinds of string_view, etc., I assume
> that the catch-all case for each arg would be "anything that can be treated
> as a range of char_type."

Sounds good.. but if you've got an input range (not readable twice)
then you can no longer apply the two-pass optimization.
The interface certainly allows it.


--
Olaf

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Variadic append for std::string

Andrey Semashev-2
In reply to this post by Olaf van der Spek-3
On 12/29/16 11:54, Olaf van der Spek wrote:

> On Thu, Dec 29, 2016 at 1:19 AM, Yakov Galka <[hidden email]> wrote:
>> On Tue, Dec 27, 2016 at 4:47 PM, Olaf van der Spek <[hidden email]> wrote:
>>
>>> One frequently needs to append stuff to strings, but the standard way
>>> (s += "A" + "B" + to_string(42)) isn't optimal due to temporaries.
>>>
>>
>> Can't we already write it through (((s += "A") += "B") += to_string(42))?
>> This is the time I think that assignment operators, other than =, should
>> have had left associativitiy... pity they don't.
>
> We can, but it's ugly and I'd like to avoid the explicit to_string. It
> also wouldn't allow the two-pass optimization to calculate the final
> length before allocation.

I already mentioned in the std-proposals discussion that I don't think
formatting should be dealed with by std::string or a function named
append(). If formatting is to be involved I'd suggest creating a
formatting library, but at that point you should provide clear
advantages over the other formatting libraries we have in Boost.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Variadic append for std::string

Olaf van der Spek-3
On Thu, Dec 29, 2016 at 2:53 PM, Andrey Semashev
<[hidden email]> wrote:

>>>> One frequently needs to append stuff to strings, but the standard way
>>>> (s += "A" + "B" + to_string(42)) isn't optimal due to temporaries.
>>>>
>>>
>>> Can't we already write it through (((s += "A") += "B") += to_string(42))?
>>> This is the time I think that assignment operators, other than =, should
>>> have had left associativitiy... pity they don't.
>>
>>
>> We can, but it's ugly and I'd like to avoid the explicit to_string. It
>> also wouldn't allow the two-pass optimization to calculate the final
>> length before allocation.
>
>
> I already mentioned in the std-proposals discussion that I don't think
> formatting should be dealed with by std::string or a function named
> append().

It'd be helpful if you include *why* you think so..

> If formatting is to be involved I'd suggest creating a formatting
> library, but at that point you should provide clear advantages over the
> other formatting libraries we have in Boost.




--
Olaf

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Variadic append for std::string

Andrey Semashev-2
On 12/31/16 20:36, Olaf van der Spek wrote:
> On Thu, Dec 29, 2016 at 2:53 PM, Andrey Semashev
> <[hidden email]> wrote:
>>
>> I already mentioned in the std-proposals discussion that I don't think
>> formatting should be dealed with by std::string or a function named
>> append().
>
> It'd be helpful if you include *why* you think so..

I've already explained my opinion in the std-proposals discussion. For
the sake of completeness, here's a short version:

It's simply not std::string's job to do the formatting, IMO. This class
should be nothing more than a container of characters (well, it is
slightly more now, but I don't consider that a good thing). I guess,
that's mostly because I believe one class should be responsible for
doing only one thing, and in case of std::string it's storing a string.
Adding formatting functionality to std::string would increase the class'
bloat in terms of interface and implementation and likely add new
dependencies. Though, this is probably not an argument against a
separate non-intrusive library.

Back to the proposal for Boost, I don't mind if there is a standalone
function or library that does the formatting, as long as it offers some
advantage over the existing libraries. The proposed function though
should not be named `append` IMO because it's not the primary thing the
function does. I would expect an `append` algorithm to be generic and
compatible with any container, i.e. something that does nothing more
than `c.insert(c.end(), x)` or `c.append(x)`, for `x` being every
argument in the list of arguments to be appended. I.e. this should work:

   std::list< double > c{ 1.0, 2.0, 3.0 };
   append(c, 10.0, 20.0, 30.0); // calls c.insert()

As well as this:

   std::string s{ "Hello" };
   append(s, ", world!", " Happy 2017! :)"); // calls s.append()

This, however:

   append(s, 47);

should result not in appending "47" but in appending "/" (a character
with code 47). I can see how this could be confusing to someone, but
that is what you'd get from calling `s.insert()` manually, and what I'd
expect from a function called `append`.

If formatting is required I would prefer to be required to spell my
intent more clearly, like this:

   print(s, 47);

or:

   format(s) << 47;

Also, I'm not clear enough about the intended use cases of the proposed
library. Is the goal just to optimize memory allocation? Is that at all
possible when formatting is involved? Would it be better than snprintf
into a local buffer?

Does the library open new use cases? For example, someone suggested in
the std-proposals discussion something similar to this:

   throw std::runtime_error(format(std::string()) << "Error " << 47);

(I wrapped the default-constructed std::string() into format(), because
I don't think overloading operator<< for std::string is an acceptable
approach for the same reasons I mentioned above.)

I think, something with one line capability like that would be useful.
Would the library allow something like this?

Would the library support targets other than std::string? E.g. would I
be able to format into an `std::array< char, 10 >`?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Variadic append for std::string

Olaf van der Spek-3
On Sun, Jan 1, 2017 at 12:21 AM, Andrey Semashev
<[hidden email]> wrote:
> If formatting is required I would prefer to be required to spell my intent
> more clearly, like this:
>
>   print(s, 47);

I'd expect print to output to cout.. wouldn't you?
sprint then?

> or:
>
>   format(s) << 47;

I'd expect format to accept modifiers which this proposal explicitly
doesn't support.

> Also, I'm not clear enough about the intended use cases of the proposed
> library. Is the goal just to optimize memory allocation?

No, the goal is also to provide a better and simpler way to handle integers.

> Is that at all
> possible when formatting is involved?

Yes, as manually calling reserve beforehand is always possible.
How to optimally implement this is still an open question but that's
kind of an implementation detail.

> Would it be better than snprintf into
> a local buffer?

The resulting code certainly looks simpler to me.

> Does the library open new use cases? For example, someone suggested in the
> std-proposals discussion something similar to this:
>
>   throw std::runtime_error(format(std::string()) << "Error " << 47);
>
> (I wrapped the default-constructed std::string() into format(), because I
> don't think overloading operator<< for std::string is an acceptable approach
> for the same reasons I mentioned above.)

I disagree.. I really don't see the benefit, especially for the user,
of the format wrapper.

operator<< would be a different proposal but throw
runtime_error(append(string(), "Error ", 47)); might work.

> I think, something with one line capability like that would be useful. Would
> the library allow something like this?
>
> Would the library support targets other than std::string?

Yes, probably.

> E.g. would I be
> able to format into an `std::array< char, 10 >`?

No, as array is fixed-size you can't append to it..
vector<char> might work though.

--
Olaf

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Variadic append for std::string

Olaf van der Spek-3
In reply to this post by Yakov Galka
On Thu, Dec 29, 2016 at 1:19 AM, Yakov Galka <[hidden email]> wrote:
> On Tue, Dec 27, 2016 at 4:47 PM, Olaf van der Spek <[hidden email]> wrote:
>
>> One frequently needs to append stuff to strings, but the standard way
>> (s += "A" + "B" + to_string(42)) isn't optimal due to temporaries.
>>
>
> Can't we already write it through (((s += "A") += "B") += to_string(42))?
> This is the time I think that assignment operators, other than =, should
> have had left associativitiy... pity they don't.

<< does the trick:

s << "A" << "B" << 42;

std::string& operator<<(std::string& os, std::string_view v)
{
    return os += v;
}

std::string& operator<<(std::string& os, long long v)
{
    return os += std::to_string(v);
}



--
Olaf

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Variadic append for std::string

Dominique Devienne
In reply to this post by Andrey Semashev-2
On Thu, Dec 29, 2016 at 2:53 PM, Andrey Semashev <[hidden email]>
wrote:

> On 12/29/16 11:54, Olaf van der Spek wrote:
>
>> On Thu, Dec 29, 2016 at 1:19 AM, Yakov Galka <[hidden email]>
>> wrote:
>>
>>> On Tue, Dec 27, 2016 at 4:47 PM, Olaf van der Spek <[hidden email]>
>>> wrote:
>>>
>>> One frequently needs to append stuff to strings, but the standard way
>>>> (s += "A" + "B" + to_string(42)) isn't optimal due to temporaries.
>>>>
>>>>
>>> Can't we already write it through (((s += "A") += "B") += to_string(42))?
>>> This is the time I think that assignment operators, other than =, should
>>> have had left associativitiy... pity they don't.
>>>
>>
>> We can, but it's ugly and I'd like to avoid the explicit to_string. It
>> also wouldn't allow the two-pass optimization to calculate the final
>> length before allocation.
>>
>
> I already mentioned in the std-proposals discussion that I don't think
> formatting

should be dealt with by std::string or a function named append(). If
> formatting

is to be involved I'd suggest creating a formatting library, but at that
> point you should

provide clear advantages over the other formatting libraries we have in
> Boost.


Or that exist elsewhere, e.g. https://github.com/fmtlib/fmt --DD

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Variadic append for std::string

Andrey Semashev-2
In reply to this post by Olaf van der Spek-3
On 01/03/17 13:14, Olaf van der Spek wrote:
> On Sun, Jan 1, 2017 at 12:21 AM, Andrey Semashev
> <[hidden email]> wrote:
>> If formatting is required I would prefer to be required to spell my intent
>> more clearly, like this:
>>
>>   print(s, 47);
>
> I'd expect print to output to cout.. wouldn't you?
> sprint then?

sprint works for me as well.

>> Also, I'm not clear enough about the intended use cases of the proposed
>> library. Is the goal just to optimize memory allocation?
>
> No, the goal is also to provide a better and simpler way to handle integers.
>
>> Is that at all
>> possible when formatting is involved?
>
> Yes, as manually calling reserve beforehand is always possible.
> How to optimally implement this is still an open question but that's
> kind of an implementation detail.

But you would have to either overallocate memory or perform the
formatting to determine its length. And while overallocating might be
possible for standard types such as integers and FP numbers (assuming
C-locale format), that does not seem possible for user's types. Or are
you not planning to support user-defined types?

>> I think, something with one line capability like that would be useful. Would
>> the library allow something like this?
>>
>> Would the library support targets other than std::string?
>
> Yes, probably.
>
>> E.g. would I be
>> able to format into an `std::array< char, 10 >`?
>
> No, as array is fixed-size you can't append to it..
> vector<char> might work though.

My intent was to format into a local/preallocated buffer, without any
additional allocations, but I assume that won't work because
`std::array` is lacking APIs for insertion. That probably means that you
have to define a concept of the possible target, what operations it must
support.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Variadic append for std::string

Olaf van der Spek-3
On Tue, Jan 3, 2017 at 1:32 PM, Andrey Semashev
<[hidden email]> wrote:
>> Yes, as manually calling reserve beforehand is always possible.
>> How to optimally implement this is still an open question but that's
>> kind of an implementation detail.
>
>
> But you would have to either overallocate memory or perform the formatting
> to determine its length.

True

> And while overallocating might be possible for
> standard types such as integers and FP numbers (assuming C-locale format),
> that does not seem possible for user's types. Or are you not planning to
> support user-defined types?

Supporting such types in one big call to sprint would be nice but it
does complicate the proposal.
One could always call sprint(s, <udt>) 'manually'. Or maybe the
two-argument version could be the extension point.

Maybe a sprint_max_size(s, <udt>) could be used (if defined) to
estimate the size required.

> My intent was to format into a local/preallocated buffer, without any
> additional allocations, but I assume that won't work because `std::array` is
> lacking APIs for insertion. That probably means that you have to define a
> concept of the possible target, what operations it must support.

Right, if we opt for a generic version. It would again complicate the
proposal though.


--
Olaf

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Variadic append for std::string

Christof Donat
In reply to this post by Andrey Semashev-2
Hi,

Am 01.01.2017 00:21, schrieb Andrey Semashev:
>   throw std::runtime_error(format(std::string()) << "Error " << 47);

How would that differ from

   throw std::runtime_error((std::ostringstream{} << "Error " <<
47).str());

Christof

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Variadic append for std::string

Olaf van der Spek-3
On Tue, Jan 3, 2017 at 2:19 PM, Christof Donat <[hidden email]> wrote:

> Hi,
>
> Am 01.01.2017 00:21, schrieb Andrey Semashev:
>>
>>   throw std::runtime_error(format(std::string()) << "Error " << 47);
>
>
> How would that differ from
>
>   throw std::runtime_error((std::ostringstream{} << "Error " << 47).str());

Simpler syntax, better performance


--
Olaf

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Variadic append for std::string

Christof Donat
Hin

Am 03.01.2017 14:20, schrieb Olaf van der Spek:

> On Tue, Jan 3, 2017 at 2:19 PM, Christof Donat <[hidden email]> wrote:
>> Am 01.01.2017 00:21, schrieb Andrey Semashev:
>>>
>>>   throw std::runtime_error(format(std::string()) << "Error " << 47);
>>
>>
>> How would that differ from
>>
>>   throw std::runtime_error((std::ostringstream{} << "Error " <<
>> 47).str());
>
> Simpler syntax, better performance

I see the chances for better performance, but for the syntax I don't
really see
any remarkable improvements.

If performance matters, I'd try with boost::spirit::karma. The syntax
will be
less concise, but I am not aware of a faster generic solution.

   auto message = std::string{10}; // <- preallocate enough memory for
the message
   if( !karma::generate(std::begin(message), ascii::space, "Error " <<
karma::uint_, 47) ) {
       // formating the error message failed. throw something else.
   }
   // since this is the exit of the function, the compiler might apply
copy elision.
   throw std::runtime_error(message);

If you have multiple places like that in your code, I guess, you'd like
to wrap it
into a generic function and you have a similar API to the "append()"
proposal. Now
I see, how it might be useful, thanks. I think, append() should rely on
karma
generators then, instead of yet another int to string implementation,
because we
only already have five dozens.

Christof

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Variadic append for std::string

Olaf van der Spek-3
On Tue, Jan 3, 2017 at 3:16 PM, Christof Donat <[hidden email]> wrote:

> Hin
>
> Am 03.01.2017 14:20, schrieb Olaf van der Spek:
>>
>> On Tue, Jan 3, 2017 at 2:19 PM, Christof Donat <[hidden email]> wrote:
>>>
>>> Am 01.01.2017 00:21, schrieb Andrey Semashev:
>>>>
>>>>
>>>>   throw std::runtime_error(format(std::string()) << "Error " << 47);
>>>
>>>
>>>
>>> How would that differ from
>>>
>>>   throw std::runtime_error((std::ostringstream{} << "Error " <<
>>> 47).str());
>>
>>
>> Simpler syntax, better performance
>
>
> I see the chances for better performance, but for the syntax I don't really
> see
> any remarkable improvements.

The extra parentheses and the .str() part are annoying.. same goes for
boost::format.

How about this one?

throw std::runtime_error("Error "s << 47);

> If performance matters, I'd try with boost::spirit::karma. The syntax will

Performance matters but it's not the only thing that matters.
What solution do you think someone new to C++ understands better?

> If you have multiple places like that in your code, I guess, you'd like to
> wrap it
> into a generic function and you have a similar API to the "append()"
> proposal. Now
> I see, how it might be useful, thanks. I think, append() should rely on
> karma
> generators then, instead of yet another int to string implementation,
> because we
> only already have five dozens.

It's an implementation detail but yes, it might be useful.


--
Olaf

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Variadic append for std::string

Christof Donat
Hi,

Am 03.01.2017 15:23, schrieb Olaf van der Spek:
> On Tue, Jan 3, 2017 at 3:16 PM, Christof Donat <[hidden email]> wrote:
> The extra parentheses and the .str() part are annoying.. same goes for
> boost::format.

I see. For me that is not a big issue, but people are different.

> How about this one?
>
> throw std::runtime_error("Error "s << 47);

Uh. How does that work with

   std::cout << "Error "s << 47;

Will that be

   (std::cout << "Error "s) << 47;

or

   std::cout << ("Error "s << 47);

Also I'd expect a std::string to behave like a stream then and try to
use e.g. manipulators. Maybe that would be acceptable with a different
operator. e.g. like in SQL:

  throw std::runtime_error("Error "s || 47);

Now this is explicit:

   std::cout << "Error "s || 47; // versus
   std::cout << "Error "s << 47;

But then again this might behave surprisingly:

  throw std::runtime_error("Error "s || 47 || 11);

I still don't feel comfortable with it.

>> If performance matters, I'd try with boost::spirit::karma. The syntax
>> will
>
> Performance matters but it's not the only thing that matters.
> What solution do you think someone new to C++ understands better?

I think, mixing the notion of strings and streams, but not for e.g.
manipulators would confuse people a lot. I am a big fan of overloading
operators and expression templates, wherever they improve the expression
of intent. In this particular case my gut feeling tells me, that it will
harm the expression of intent more often, than it will improve.

Christof

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Variadic append for std::string

Andrey Semashev-2
In reply to this post by Olaf van der Spek-3
On 01/03/17 17:23, Olaf van der Spek wrote:

> On Tue, Jan 3, 2017 at 3:16 PM, Christof Donat <[hidden email]> wrote:
>> Hin
>>
>> Am 03.01.2017 14:20, schrieb Olaf van der Spek:
>>>
>>> On Tue, Jan 3, 2017 at 2:19 PM, Christof Donat <[hidden email]> wrote:
>>>>
>>>> Am 01.01.2017 00:21, schrieb Andrey Semashev:
>>>>>
>>>>>
>>>>>   throw std::runtime_error(format(std::string()) << "Error " << 47);
>>>>
>>>>
>>>>
>>>> How would that differ from
>>>>
>>>>   throw std::runtime_error((std::ostringstream{} << "Error " <<
>>>> 47).str());
>>>
>>>
>>> Simpler syntax, better performance
>>
>>
>> I see the chances for better performance, but for the syntax I don't really
>> see
>> any remarkable improvements.
>
> The extra parentheses and the .str() part are annoying.. same goes for
> boost::format.
>
> How about this one?
>
> throw std::runtime_error("Error "s << 47);

Well, if we're using UDLs, we might as well use my `format` proposal or
a stream or Boost.Format behind the scene.

   throw std::runtime_error("Error "fmt << 47);
   throw std::runtime_error("Error "strm << 47);
   throw std::runtime_error("Error %d"fmt % 47);

Each of the UDL operators would create a wrapper that implements
formatting and is convertible to std::string. No need to infect
std::string itself with formatting.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
1234 ... 6