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.