Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Vicente BOTET (vicente.botet_at_[hidden])
Date: 2011-05-04 14:07:54

> Message du 04/05/11 19:50
> De : "Phil Endecott" 
> A : boost_at_[hidden]
> 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/html/index.html), 

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