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

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

Hi,

Am 23.01.2017 19:26, schrieb Olaf van der Spek:
> On Mon, Jan 23, 2017 at 5:32 PM, Christof Donat <cd_at_[hidden]> wrote:
>> 1. scope for formatting tags:
>> 
>> concat(format::hex<int>, 42, " is hex for ", concat(42)).str();
>> 
>> Here the inner concat will convert the 42 to its decimal 
>> representation,
>> while the outer one converts the first 42 to its hex representation.
> 
> Wouldn't concat(hex(42), " is hex for", 42) make more sense?

That is a valid approach for concat() and format(), but suboptimal for 
join(). Think of this example:

join(hex<int>, separator(" "), my_nums);

Here all the numbers are converted to their hex representation. With 
your approach this would look like:

join(separator(" "),
      my_nums | transform([](int i) -> int {
                              return hex(i);
                          }));

That is much more difficult to understand.

Since for join() tag parameters to define the conversion is, to me, the 
superior choice, I think, we should use it for concat() and format() as 
well, for consistency.

>> 2. concat() in calls to format():
>> 
>> format("%|1$40t|%2%", concat(first_name, " ", last_name),
>> phone_number).str();
> 
> Why not fold the name concat into the format string?

In this example I want the full name to take up 40 characters, no matter 
if the first name is long or short. With format strings as used by 
boost::format I don't know how that could be achieved, and extending the 
format language, of course, makes the interpreter slower and more 
complex.

>>> If "concat" is the outer layer anyway, I would return a std::string
>>> directly for convenience. It is easy to forget the trailing .str() 
>>> and
>>> it does not look elegant.
>>> 
>> 
>> Of course better proposals are welcome :-) Would you prefer the 
>> implicit
>> conversion? If so, why?
> 
> Implicit is problematic with auto..

That is one of the reasons, I prefer the explicit str() function. It 
also fits well to other factory functions, we might prefer to have as 
well, like e.g. concat(...).append_to(my_string), or 
concat(...).overwrite(my_string).

Christof