On Sat, Feb 28, 2009 at 2:55 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
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.)
I can't imagine how the generic convert.hpp could provide support for additional conversion options for user::uuid.
Additional conversion options that are specific to converting user::uuid to string shouldn't be a concern for the generic convert framework. The caller can pass such additional arguments if user::uuid provides overloads that take them; if not then the caller will get a compile error, which is also appropriate. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode