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

Subject: Re: [boost] Boost review of the Convert library is ongoing
From: alex (alexhighviz_at_[hidden])
Date: 2014-05-19 11:41:49

>Vladimi Batov writes
>> alex <alexhighviz <at> hotmail.com> writes:
>

>TODO: Provide "rich and advanced" stringstream_based converter.

I actually already consider the stringstream_based converter rich and
advanced, my suggestion was that you would incorporate this behaviour into
what you call the "contract" for conversion

>
>RE#2: Basic things that I would expect from a *generic* converter are not
>offered by the Convert library.
>
>REPLY-PART#1: Clearly there is no code that would satisfy every user's
need.
>Far from it. *Currently* we are at the "consideration/evaluation" stage to
>see if that is the correct/valid/promising/sustainable *path* to go ahead
>and to implement all those bells and whistles.
>

These are not specific bells and whistles I want. 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. Conversion to/from string requires a different contract than
conversion between types, encryption or conversion from Celsius to
Fahrenheit. 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. 

> force a *contract* between the user (service consumer) and the converter
developer
>(service provider). 

My problem is that the contract hardly specifies anything, and what it does
specify is only partly necessary. 

> That's why to this point I am not exactly sure if such an
>"administrative" proposal really belongs in Boost where it is overwhelmngly
>about clever code.

To me it sounds a lot like Boost Property Map that also seems to derives its
value from being a useful contract, rather than a clever implementation.

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

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

I am sorry to be sounding so critical. To remind you: I would use this
library, because I like the functionality.