[Boost-users] [multi_index] const_mem_fun with an inherited member function

From: Matt Steele (steelerm_at_[hidden])
Date: 2005-12-31 02:21:23

I am trying to use Boost.Multi-index (version 1.33.0) to store a set of
boost::tuples, and it appears that const_mem_fun has some difficulties
when the desired member function is inherited from a base class. The
following typedef

  typedef multi_index_container<
    tuple<int>,
    indexed_by< ordered_non_unique< const_mem_fun< tuple<int>,
                                                   const int&,
                                                   &tuple<int>::get<0>
                                                 >
              >
    >
  > my_tuple_container_type;

yields this error (edited for clarity) on my compiler (g++ 4.0.3):

  &TupleBaseClass<int>::get' is not a valid template argument for type 
  'const int& (tuple<int>::*)()const' because it is of type 
  'const int& (TupleBaseClass<int>::*)const'
  note: standard conversions are not allowed in this context

Now the declaration of boost::tuple has something like this:

template <class T>
class tuple : public TupleBaseClass<T> {
public:
  typedef typename TupleBaseClass<T> inherited;
...
};

(Also, as far as I can tell, get<0>() is declared and implemented in
TupleBaseClass, not tuple).  The public typedef 'inherited' looked
promising, so I modified my code as follows:

  typedef multi_index_container<
    tuple<int>,
    indexed_by< ordered_non_unique< const_mem_fun< tuple<int>::inherited,
                                                   const int&,
                                                   &tuple<int>::get<0>
                                                 >
              >
    >
  > my_tuple_container_type;

and that compiles.

I have a few questions/comments about all this.  First of all, is my
compiler correct to generate the error for the first case?  Secondly, is
the above workaround satisfactory?  My opinion is that it's a little
ungainly; it appears to me that boost::tuple is a derived type for
implementation reasons, and I'd rather not have to know about that fact.

Thank you.

Matt Steele