Subject: Re: [boost] Boost review of the Convert library is ongoing
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2014-05-21 20:04:50
On 05/20/2014 09:15 PM, alex wrote:
>>
>>> Conversion to/from string requires a different contract than
>>> conversion between types, encryption or conversion from Celsius to
>>> Fahrenheit.
>> I fail to see how/why these mentioned different type
>> conversions/transformations "require different contracts".
> Perhaps it is better to say 'would benefit from different contracts'.
>
> For instance:
>
> type-to-type converters would benefit from contracts that specify mechanisms
> for checking for reversibility, loss of precision, overflow, etc.
> type-string converters would benefit from contracts that specify mechanisms
> for giving formatting instructions
> unit-to-unit converters would benefit from all kinds of consistency and
> equivalence test... see the Boost Unit library
> encryptions converters would benefit from contracts that specify mechanisms
> to specify/query encryption strength
I am not arguing against interface/behavior specifications (a.k.a.
"contracts") for converters. I only feel that "convert"'s purpose is far
more modest -- to only specify how to deploy various converters and what
to expect when we do. It seems far beyond my capabilities and expertise
to come up with "contracts" you listed.
>
>>> The user still needs to supply a Default Construction function it is just
>>> not the default constructor. I can see that this requirement follows from
>>> the stringstream implementation.
>> No, it's not a requirement of std::sstream but rather imposed by
>> boost::convert::from.
>>
> Yes, but why? Isn't the underlying reason that sstream requires a reference?
>
> my_type val;
> stream >> val;
I feel it's a generic converter requirement -- they all need a "place"
to write the result to. We might say -- every converter for itself. On
the other hand, that seemed like a generic enough requirement that the
"framework" might care providing uniformly to every converter.
>
>>> But it does not seem a reasonable
>>> requirement for a generic converter (nor is the requirement of Copy
>>> Constructible). All you can reasonably require is some function that
> creates
>>> a TypeOut from a TypeIn.
>>
Well, I feel you are not avoiding requirements but merely shifting them
around from boost::convert() down to converters. A converter will still
need to be able to create and TypeOut instance somehow and in a generic
way. So, I feel, we'll be back where we are now with the burden of every
converter having to do it itself.
>
>> I was not able to come up with a better implementation that would not have
>> those requirements. If you have such an implementation, I'll incorporate
>> it gladly.
>>
> How about reducing the API to the following? The only requirement on TypeOut
> would be the requirements put by boost::optional (or your closely related
> result-type).
>
> api.hpp
> #include <boost/optional.hpp>
> namespace boost
> template<typename TypeOut> struct convert
> template<typename TypeIn, typename Converter>
> static boost::optional<TypeOut> from(TypeIn const& in, Converter const&
> converter)
> {
> boost::optional<TypeOut> out;
> converter(in, out);
> return out;
> }
> };
> }
>
> In sstream.hpp you would have(with some simplification)
>
> template<typename T> struct convert_default_maker
> {
> static T make() { return T(); }
> };
That seems like a 0-gain game as we still have all the same requirements
and all the same code, right? We still ned to be able to create a
TypeOut instance somehow generically. Although the code above forces
every converter to do that by themselves, right? Although passing
boost::optional into a container might have its benefits... I had it at
one point... will have to re-visit again.
>
> // in sstream.hpp
> template<TypeIn, TypeOut>
> void boost::basic_stringstream_converter::operator()(const TypeIn& in,
> boost::optional<TypeOut>& out)
> {
> TypeOut out_value = boost::convert_default_maker<TypeOut>::make();
> stream_.str(std::basic_string< char_type>());
> stream_ << in;
> stream_ >> out_value;
> out = boost::make_optional(!stream_.fail(), out_value);
> }
That's something I'll have to think about. What jumps at me though is
what I'd call "blur of responsibilities" -- now converter not only
cares for conversion but for allocation as well. Secondly, in the
current "convert" design converters know nothing about boost::convert
"framework". The implementation above seems to require the converter to
know/deploy boost::converter_default_maker which is either part of the
"convert" infrastructure or converter's own code, i.e. the converter has
to have either additional "knowledge"/coupling or additional code. In
both cases I do not like the "additional" bit. :-)