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

Hi, Am 24.01.2017 10:07, schrieb Richard Hodges:

For what it's worth, in my view join and/or concat should return a generator.

To me the idiomatic way to convert it to a string would be and ADL function to_string(generator) -> std::string.

Then why not use the std::string constructor instead? That would be the case with the implicit conversion: auto generator = concat(...); auto my_str = std::string{generator};

The generator itself should be streamable to at least a basic_ostream via ADL operator<<

Yes, that looks like a good idea to me as well. The simple and straight forward implementation (using the std::string constructor) might be: auto operator << (std::basic_ostream<...>& stream, generator g) -> std::basic_ostream<...>& { }

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. The result will be that string construction is then only necessary when the user wants it.

basic ADL interface something like this:

#include <memory> #include <iostream> #include <string> #include

namespace boost { template struct join_engine_type { // implementation of joiner here };

template auto operator<<(std::basic_ostream& os, const join_engine_type& eng) -> std::basic_ostream& { // impementation here return os; };

template auto allocate_string(const join_engine_type& eng) -> std::basic_string& { // note that the allocator is copied, so if the joiner has a memory pool // allocator, the strings will share the memory pool // impementation here };

template auto to_string(const join_engine_type& eng) -> std::basic_string& { // note that the standard allocator is used. Strings are now independent. // impementation here };

template auto to_string_view(const join_engine_type& eng) -> std::experimental::basic_string_view& { // note that the standard allocator is used. Strings are now independent. // impementation here }; }

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.

On 24 January 2017 at 02:59, Jeff Garland wrote:

...

So let me just say that this is a bike shed topic -- I've been in the shed a decade ago on the subject -- but hey why not :) I dropped the proposal below bc it was clear to me that no agreement was possible on the topic. The proposal in isn't variadic because that feature didn't exist at the time, but you can see how it would be trivially changed to be -- why it is begging to be variadic. It brings together many of the discussed libraries format, string_algo, regex into an interface that is simple and clear. It allows for both formatting and appending. Extremely small sample

super_string <http://www.crystalclearsoftware.com/ libraries/super_string/classbasic__super__string.html> s(" (456789) [123] 2006-10-01 abcdef "); s.to_upper(); cout << s << endl;

s.trim(); //lop off the whitespace on both sides cout << s << endl;

double dbl = 1.23456; s.append(dbl); //append any streamable type s+= " "; cout << s << endl;

date d(2006, Jul, 1); s.insert_at(28, d); //insert any streamable type cout << s << endl;

super_string s; double dbl = 1.123456789; int i = 1000; s.append_formatted <http://www.crystalclearsoftware.com/libraries/super_string/ classbasic__super__string.html#67740abfd6224fab0402b3dd7076f216>(dbl, i , dbl, i, "a string", "%-7.2f %-7d %-7.2f %-7d %s"); //s == "1.12 1000 1.12 1000 a string"

//other overloadings available with less parameters super_string s1; s1.append_formatted <http://www.crystalclearsoftware.com/libraries/super_string/ classbasic__super__string.html#67740abfd6224fab0402b3dd7076f216>(dbl, "This is the value: %-7.2f"); //s1 == "This is the value: 1.12"

main page http://www.crystalclearsoftware.com/libraries/super_string/index.html

My justification for *why* I did this as a type against all the *standard judgement* of the c++ experts http://www.crystalclearsoftware.com/libraries/super_string/index. html#why_type

My original post in 2006 http://lists.boost.org/Archives/boost/2006/07/107087.php

Jeff

On Mon, Jan 23, 2017 at 4:14 PM, Gavin Lambert wrote:

...

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.algo rithm.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).

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

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

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