Boost logo

Boost :

Subject: Re: [boost] Boost review of the Convert library is ongoing
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2014-05-19 19:35:41


On 05/20/2014 01:41 AM, alex wrote:
> ... This is about needing to
> specify what the "contract" for a converter is. At the moment all you
> specify is an object that is callable with an input and creates an output.
> To me that is too generic and I do not really see how this "contract" is
> helpful.

I think I see where our disconnect might be. I only apply the term
"contract" to the formalization of how service-consumer (the user) and
service-provider (the converter developer) "interact". That interaction
is defined by boost::convert::from interface. So, that "contract" (in my
interpretation) tells the user -- as long as you deploy various
conversion facilities via agreed interface, you can expect consistent
behavior and you can plug in other compatible converters. Then, to the
service provider it states -- as long as you conform to the agreed
"callable" interface for your converter, it can be used within
boost::convert framework. That's it. You perceive it as "too generic".
To this point to me it seems sufficient -- that allows me, the user, to
replace one converter with another one if/when needed. Say, I started
with strtol-based converter but later due to a requirement change needed
additional formatting. So, I deployed std::sstream-based converter
instead with very little impact on my application code.

In my view there is no "contract for converter"... apart from the
*requirement* it is a "callable" with a certain signature.

> 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". They indeed
require different converters but the consumer-provider contract remains
-- the user deploys converters in the same way and the behavior of
boost::convert::from are the same. An every-day example. The electricity
company provides the electricity and a socket. You get to use that power
with whatever you plug into that socket as long the socket (interface)
matches and the plugged-in device conforms to the requirements. It's
short but it's still an agreement/contract. To the user -- you follow
these rules, you get that... To the provider -- you provide your service
a certain way, you get it used... That's how I see it anyway.

> At the moment you are so generic to cover all these types of
> conversions, but with no (IMHO) added value. If you want to add "bells and
> whistles" at some point you need to be clear about what type of conversion
> you are supporting and what functionality comes with that.

Again, boost::convert::from by itself does not do and does not support
any conversions. It only specifies *how* converters are to be deployed
uniformly. "Bells and whistles" are provided (or not) by the respective
converters. Some converters provide performance but no bells, some other
the other way around. I am not trying to provide all imaginable
conversions. I am only suggesting how to deploy those uniformly.

> ...
>
>> REPLY: The statement above is incorrect. The default-constructible
>> requirement was actually the main reason I was forced to stop using
>> lexical_cast and to develop "convert". Please read "The Default
>> Constructible Type Requirement" chapter.
> 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.

> 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.

I feel you mix up requirements for converters and requirements for
types. The only req. for converters is that they are a callable with a
certain signature. As for requirements for TypeIn and TypeOut, then
those listed requirements are needed for the framework to work. 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.

>
> My issue is not that you require Default Constructible (through a function)
> or Copy Constructible, but that the value-to/from-string library is being
> sold as a generic conversion solution.

No, it is not claimed to be a "generic conversion solution". It is a
framework, policy, guidelines, the interface to deploy actual conversion
solutions (converters) uniformly.

> These are reasonable requirements for
> this particular library, but not for a generic conversion contract.
>
> How would you write an efficient converter for the following?
>
> template<typename T> struct large_vector {
> large_vector(const T& v) : m_vector(v, 10000000) {}
> std::vector<T> m_vector;
> } ;

The proposal does not address how to write an efficient converter. It
offers an interface how to deploy varying conversion facilities uniformly.

> I am sorry to be sounding so critical. To remind you: I would use this
> library, because I like the functionality.
>
Thank you for the remainder. :-) As far as I am concerned, I do not
perceive your comments as critical (in negative sense). I see it as a
normal and healthy technical discussion.


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