Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk