Re: [boost] Boost review of the Convert library is ongoing

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.