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

Subject: Re: [boost] Variadic append for std::string
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-01-23 18:14:58

On 24/01/2017 07:26, Olaf van der Spek 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?

+1.  If you like persistent formatting states (and all the unexpected 
fun they cause when you forget to cancel them), use iostreams instead.

>> 3. results from concat() in a boost::range that is passed to join():
>>
>> join(separator("\n"),
>>      my_files | transformed([](const std::filesystem::path& f) -> auto {
>>                                 return concat(f.filename, ": ",
>> std::filesystem::file_size(f));
>>                             })).str();

Maybe I missed something, but what was the intended distinction between 
concat() and join()?

To me, as vocabulary words, concat() implies "concatenate without 
separator" and join() implies "concatenate with separator"; as such it 
seems unnecessary to explicitly decorate the separator here since it's a 
required parameter.

(Both should accept either variadics or ranges, if that's not too 
complicated to arrange, though it's likely for join() to be used more 
often on ranges; concat() might be more evenly split, though probably 
leaning toward variadics.)

Although I suppose 
http://www.boost.org/doc/libs/1_63_0/doc/html/string_algo/reference.html#header.boost.algorithm.string.join_hpp 
and 
http://www.boost.org/doc/libs/1_63_0/libs/range/doc/html/range/reference/utilities/join.html 
might not entirely agree on this vocabulary...

(Loads the bikeshed on the back of a bike and rides away.)

>>> 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..

While that's true, I think the flexibility of returning a factory from 
concat() is more useful than the discomfort of either remembering the 
str() or using std::string explicitly as the type instead of auto (or 
using auto combined with explicit std::string construction).