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<typename ITER> 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<int> try_parse_int(std::string s) { int i; bool success; parse_int(s.begin(),s.end(),i,success); return success ? i : optional<int>(); }
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.
<sarcasm>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.</sarcasm> 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. Regards, Phil.