On Sun, Jan 1, 2017 at 12:21 AM, Andrey Semashev
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