Emil Dotchevski wrote:
What's wrong with the following call syntax:
boost::convert<target>( source const & [,arg1,arg2,...] )
that is, the caller provides the target type for the conversion, then the first argument is considered the source (deduced automatically), and the rest of the arguments configure the conversion.
Going back to my uuid example, uuid.hpp could simply say:
#include <string>
namespace user { class uuid; template <class Target> Target convert( uuid const & ); template <> std::string convert<std::string>( uuid const & ); }
(no need to include anything.)
Now, the user of uuid.hpp can also #include "boost/convert.hpp" when making calls to convert. This could provide generic overloads that support common conversion options, which would bind only if uuid.hpp doesn't provide overloads itself (which would obviously be more specialized and the overload resolution will prefer them over the convert.hpp generics.)
Sorry, I can't imagine how the generic convert.hpp could provide support for additional conversion options for user::uuid. It is my understanding that such options should be supported by the user::uuid implementer and should not be part of Boost.Convert. I may not understand your point well, though. Could you produce an illustrating code sample?