Vladimi Batov writes
alex
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.