Message du 04/05/11 19:50 De : "Phil Endecott" A : boost@lists.boost.org Copie à : Objet : Re: [boost] [review] string convert
Matthew Chambers wrote:
On 5/4/2011 10:32 AM, Phil Endecott wrote:
But per my last posts, anyone can easily write those in whatever style they want, if they have the core function, e.g.
template void parse_int(ITER begin, ITER end, int& i, bool& success) { .... }
int must_parse_int(std::string s) { int i; bool success; parse_int(s.begin(),s.end(),i,success); if (!success) throw ParseError(); return i; }
optional try_parse_int(std::string s) { int i; bool success; parse_int(s.begin(),s.end(),i,success); return success ? i : optional(); }
int parse_int_with_default(std::string s, int def) { int i; bool success; parse_int(s.begin(),s.end(),i,success); return success ? i : def; }
It's not clear what complexity you're eliding and what you are really excluding.
I don't think I understand what you're saying. Do you mean, "what is hidden in the '....' in the first function above"?
I don't think completely non-generic overloads like you've suggested will fly in boost.
Yes, you're right, Boost tends to prefer things that use every available feature of the language even when not needed - after all, the project exists mainly to find obscure bugs in compilers.
Seriously though: what on earth is wrong with just functions that do things, with names that say what they do?
It also seems to emphasize string->type. What about int->string?
Well I have something like this, which uses printf()-style format specifiers:
std::string format(const char* fmt, ...);
Once again, I would not want to impose this on other people since it comes down to personal preferences, and anyone can write their own set of conversion functions once they have the right building blocks. I see no reason why conversions in both directions (i.e. parsing and formatting) should be rolled into a single function; it just complicates things.
Phil. I encourage you to read the motivation of Boost.Conversion. (https://svn.boost.org/svn/boost/sandbox/conversion/libs/conversion_ext/doc/h...), the problem with naming functions like parse_int and not parse is that you are unable to use them in templates. Who would you name a function that parse a std::pair of int? and how to name to parse a std::pair of int and bool? or a std::pair of T and U? Generic names is the response, and it is not personal preference, but a need of generic programming Best, Vicente