Re: [boost] [review] string convert

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

> Message du 07/05/11 07:49
> De : "Vladimir Batov" 
> A : boost_at_[hidden]
> Copie à : 
> Objet : Re: [boost] [review] string convert
> 
> > From: "Stewart, Robert" 
> > ...
> >> int i = boost::convert::to(str);
> >
> > That's good.
> 
> How about we simplify the API down to just:
> 
> T convert::to(S, boost::parameter-list);

As Robert said, the name of a free function must be readable when introducing a using namespace. Or is convert a class?

> Then we specialize it for convert::result type so that
> 
> convert::result convert::to>(S, boost::parameter-list);

I don't see any inconvenient in introducing a special overload.

I guess a user needs to call it as follows

convert::result r = convert::to>(S, boost::parameter-list);

> In fact, if there is a lot of resistance to incorporate that into the lib., 
> I can simply implement that locally. The "bool convert::try_to<>(S, T&)" API 
> is for those who prefer that style. Then, a most-functionality-covering 
> example might look like
> 
> // The predictable. Throws on failure
> int i = convert::to("FF", (format_ = std::hex))

Would this overload exist only when the source parameter is string? Sorry, but I don't see how it could be used for type-to-type conversions

int i = convert::to(aValue, (format_ = std::hex))

Would the std::hex be applied to the output or the input stream?

ios << aValue;
ios >> std::hex >> i;

or

ios << std::hex << aValue;
ios >> i;

Are these equivalent?

I think the interface must state clearly when these manipulators are applied.

> There is no converter exposure. The expected Target type is returned. No 
> implicit conversions whatsoever. When I need convert::result, I'll ask for 
> it explicitly. Seems like that might turn nay-sayers (or no-voters) to happy 
> customers. 'convert' would be fairly easy to re-shape like that. Or Vicente 
> might beef-up his library and get all the fame (oooh, jealous).

Vladimir, as I said you my library doesn't pretend to take care of string conversions or conversions via a stream. My library will specialize the convert_to function when one of the parameters is a string and call the best library providing it. The current code is calling your library. Other candidates are possible depending on which libraries will be there, lexical_cast, yours, construe (using Spirit parser).

I'm just suggesting some alternative design to your interface, that would cover the same functionality in a less bloated way. Up to you to take whatever is better for you.

While the fallback feature can be associated to a conversion constructor with a fallback parameter, it can not be associated to a conversion operator, as it doesn't allows additional parameters. The same applies to the no throw feature. While the language allows to state at compile time that a constructor or a conversion operator will not throw, there is no constructor or conversion operator that can signal at run-time (without a throw exception) if the conversion succeeded or not.

I don't know yet if I will introduce the fallback and the no throw features in my library as the default behavior intends to use the throw conversions and protect it with a try-catch clause. If I or someone else find a default behavior for these features that doesn't use a try-catch block then I will surely introduce them. Anyway, if Boost.Conversion introduce other functions, they should also be customizable as convert_to and assign_to are now. 

The string specific conversion library (as the yours was at the beginning) could have a more different design and define the throwing functions using the no throwing ones. 

Resuming. My Boost.Conversion needs a string conversion that more efficient than lexical_cast, but I could use lexical_cast if there is no better choice. If your library reach to manage type-to-type conversion in general, then Boost.Conversion will be a no sense and I will withdraw it with no problem.

Good luck with your library, I need it (at least for the string part :)

Best,
Vicente