On Thu, Feb 26, 2009 at 12:07 PM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
On Thursday, February 26, 2009 3:03 PM Emil Dotchevski wrote:
If I'm the maintainer of class uuid and I am asked to provide a to-string conversion, you'll find it very difficult to convince me that it makes sense to replace this:
#include <string>
namespace user { class uuid; std::string to_string( uuid const & ); }
with all of this:
#include <boost/mpl/and.hpp> #include <boost/mpl/bool.hpp> #include <boost/typeof/typeof.hpp> #include <boost/utility/enable_if.hpp> #include <boost/type_traits/is_integral.hpp> #include <boost/parameter/keyword.hpp>
#include <kitchen_sink.hpp>
namespace user {
struct uuid { unsigned char value_[16]; };
struct uuid_to_string_tag {};
template< typename ToT > typename boost::enable_if< boost::conversion::is_string< ToT >, uuid_to_string_tag
::type get_conversion_tag(uuid*, ToT*);
} // namespace user
namespace boost {
namespace conversion {
template< typename ToT > struct converter_impl< ToT, user::uuid_to_string_tag > { typedef ToT result_type;
template< typename ArgsT > ToT operator() (ArgsT const& args) const { .... } };
} // namespace conversion
} // namespace boost
That's a bit unfair, don't you think? I know that you only wish to support std::string conversions, but the more complex machinery shown in the latter variant supports open ended formatting options and various target types.
I understand that the design direction I would take for the framework is different, but I think you're missing the point of my previous message. Let's assume that converting to all kinds of target types with open-ended formatting options in a single convert<> function is desirable. Within that assumption, we need to provide reasonable support for the case when the conversion of an uuid object to std::string requires no parameters. You can do this by requiring uuid.hpp to include all kinds of headers and template goodness, learn your complex argument forwarding framework -or- you can design your framework in a way that allows it to bind simple function declarations or even member functions and expose them through the generic convert<> interface. I prefer the latter. Do you really find this unfair? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode