Boost logo

Boost :

Subject: Re: [boost] [review] string convert
From: Vicente BOTET (vicente.botet_at_[hidden])
Date: 2011-05-03 02:54:18

> Message du 03/05/11 04:37
> De : "Vladimir Batov"
> A : boost_at_[hidden]
> Copie à :
> Objet : Re: [boost] [review] string convert
> > Gordon Woodhull> writes:

> > I also want to mention type-to-type conversion, which Vicente Botet has
> > thought out much more thoroughly in his Conversion library. This library
> > offers type-to-type conversion seemingly as an afterthought, just because the
> > syntax allows it.
> I have to disagree. Again I consider 'convert' to be more of a conversion
> framework rather than a library. Indeed, 'convert' does not provide much more
> beyond string-to-type conversions because I personally did/do not need more.
> However, it does not mean I/we should deny that possibility to others as their
> needs may differ. Therefore, 'convert' was designed with that in mind. If
> Vicente needs type-to-type conversion functionality, I think he might consider
> implementing that functionality within the 'convert' framework by extending the
> 'convert' library for everyone's benefit.

Vladimir, as you know I started Boos.Conversion as a more generic response to type-to-type conversion. Your design was limited to string conversion and your library was named StringConvert. Then you redesigned your library so now you are able to make type-to-type conversions also, but the interface is not satisfactory for me, for my taste.

> > I'd really like to know why you think it's necessary to do convert::from(s)
> > rather than the much more familiar and easy-to-grasp string_convert(s).
> I am not sure if I managed to explain that above. The reason why TypeIn and
> TypeOut need to be separated is that if we have specialization for, say,
> string-to-type enabled with
> template
> typename boost::enable_if, TypeOut>::type
> convert_to(StringIn const&)
> {...}
> then, say, string-to-bool further specialization/optimization won't be possible
> template
> bool
> convert_to(StringIn const&)
> {...}
> It won't compile as both "specializations" will match. It did not work for me.
> If you can get it to work by some other means, I'll be only happy.

I think the way Boost.Conversion is designed allows such overloading. It use a dummy parameter taking the type of the return type.

typename boost::enable_if, TypeOut>::type
convert_to(const StringIn& from, boost::dummy::type_tag const&);

convert_to(const StringIn& from, boost::dummy::type_tag const&);

The library provides a convert_to function that adds the specific dummy parameter. I recognize this is tricky and that the overloading seems not natural from the user perspective but it works at least for the cases I have tested.


Boost list run by bdawes at, gregod at, cpdaniel at, john at