On 2/16/2014 3:56 PM, Vladimir Batov wrote:
Addressed all three comments... I think. Checked in.
This looks good. I think you have successfully focused on what is needed for a more flexible lexical_cast-like version this time.
On 02/16/2014 02:58 AM, Edward Diener wrote:
On 2/14/2014 2:16 PM, Vladimir Batov wrote:
On 02/15/2014 01:46 AM, Edward Diener wrote:
On 2/13/2014 11:01 PM, Vladimir Batov wrote:
... Finished the docs. The whole thing is at https://github.com/yet-another-user/boost.xtra.
Is the library called "xtra" or "convert" ? The library si still called the same "convert". Housed it in the "boost.xtra" dir to distinguish it from the real boost dir.
The library should be in modular-boost structure. You have it in the old SVN structure. OK. I'll look into it.
Running b2 in the doc directory gives all sorts of errors because you are still using the old SVN structure. So it is impossible to see the documentation.
Yes, did not check all (duh!) docs yesterday. Fixed now.
These lines in the doc look wrong. The expression 'convert<int>result' does not look possible in C++. I think this should be 'convert<int>::result'.
convert<int>result r1 = boost::convert<int>(str1, cnv); // Does not throw on conversion failure convert<int>result r2 = boost::convert<int>(str2, cnv); // Does not throw on conversion failure
I think you need to be precise in what a user-defined type needs to provide in order to be 'convertible from' and 'convertible to' within the convert framework. If that is too complicated in a design as a general form of using convert, then limit the library to conversion either to and from a std::basic_string<T> and specify what the single type being converted from or to a std::basic_string<T> needs to supply in order to work with convert. I actually see nothing wrong with such a limitation if it is necessary to accomplish more easily what you envision. I did not understand this information from the docs. Perhaps you have worked this out but you need to explain it quite methodically.
I would also suggest that callables ( std::function types ) be used instead of hardcoded function names when supplying user-defined conversion functionality. This provides a much more flexible ability to provide conversion for a user-defined type since the full retinue of functor creation within the standard C++ library and from within Boost can be used by the end-user to provide appropriate conversion routines. Once you hardcode some conversion member function within a class you are throwing out all this functor creation ability. Of course if such a design is too complicated based on your own design for convert then stay with what you currently have, but at least consider it if you understand the power of C++ callables to provide user-defined functionality.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost