Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2011-05-04 13:49:16

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.