[Boost-users] 'standard' free functions for operators, etc

From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2006-06-22 01:39:57

In many parts of boost, free functions are used as customization points for
various things, better explained with examples:
   intrusive_ptr_add_ref()
   advance/increment/etc in boost iterator library
   etc

Are there other examples?

Now consider my example:
   template<T, U>
   myclass_assign(T *t, U const & u)
   {
      t->operator=(u);
   }

That forms the default implementation, but clients can define their own
specializations (for cases where T is a simple type and not an object at
all).
At first I thought that 'myclass_assign' should just be 'assign' since the
assignment should be the same, just based on type (not on the circumstances
of why 'myclass' is doing the assign), but (just while writing the email) I
saw a problem there:  in the case of, say:

typedef int RecordID;

assign(RecordID id, SomeValue const & value)
{
   // do the assignment
}

But of course, RecordID is just a typedef, not a 'strong typedef', so it
could be just one example of many assign(int, SomeValue), completely
unrelated to each other.

So how should that be handled?  Specific naming (using 'myclass_') lowers
the chances of a problem, but doesn't remove it.  Which means that, in
theory at least, intrusive_ptr has the same problem:

intrusive_ptr_add_ref(some_typedef_that_is_really_an_int)
{ ... }

intrusive_ptr_add_ref(some_OTHER_typedef_that_is_also_an_int)
{ ... }

Should myclass, and also intrusive_ptr instead use a policy-based approach,
similar to boost iterator?

intrusive_ptr<T, policy = legacy_policy>
{
...
}

Is there some other approach that I'm not considering (ie runtime
boost::functions instead of compile time policy functions)?

Tony