[multiindex] combination with boost::tuple
Hi! I'd like to use boost::tuple in a list-replacing multiindex and use the first entry in the tuple as key. The following fails to compile. Could you please provide a correction? #include <boost/tuple/tuple.hpp> #include <boost/multi_index_container.hpp> #include <boost/multi_index/sequenced_index.hpp> #include <boost/multi_index/key_extractors.hpp> namespace bm = ::boost::multi_index; class C { typedef boost::tuple<std::string, std::string> data_t; template <typename T> struct mutable_value { mutable_value(const T& t):t(t){} operator T&()const{return t;} private: mutable T t; }; typedef bm::multi_index_container <mutable_value<data_t>, bm::indexed_by <bm::sequenced<>, bm::ordered_unique <bm::mem_fun<data_t, std::string, &data_t::get<0> > > > > storage_t; storage_t storage_; }; int main() { C c; }
Hi! Even for the more correct typedef I get lost: typedef bm::multi_index_container <data_t, bm::indexed_by <bm::sequenced<>, bm::ordered_unique <bm::const_mem_fun<data_t, std::string const &, &data_t::get<0> > > > > storage_t; this fails due to probably disallowed standard conversions (or a cobfused gcc-4.0.3): Cleaned up error message: '&boost::tuples::cons<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::tuples::cons<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::tuples::null_type> >::get' is not a valid template argument for type 'const std::string& (boost::tuples::tuple<string, string, ...>::*)()const' because it is of type 'const string& (boost::tuples::cons<string, boost::tuples::cons<string, boost::tuples::null_type> >::*)()const' note: standard conversions are not allowed in this context
Markus Werle ha escrito:
Hi!
Even for the more correct typedef I get lost:
typedef bm::multi_index_container <data_t, bm::indexed_by <bm::sequenced<>, bm::ordered_unique <bm::const_mem_fun<data_t, std::string const &, &data_t::get<0> > > > > storage_t;
this fails due to probably disallowed standard conversions (or a cobfused gcc-4.0.3): Cleaned up error message:
[...] Hello Markus, This particular problem of using tuple fields as key extractors is discussed at the following thread: http://lists.boost.org/boost-users/2005/12/16087.php Please take a look at it and come back if anything's not clear: summing it up, what you get will work when Boost 1.34 comes out or if using a CVS snapshot, except that you have to write data_t::inherited when declaring the extractor's base class: bm::const_mem_fun< data_t::inherited, std::string const &, &data_t::get<0>
And the other solution is to write a user-defined extractor as explained in the aforementioned thread. HTH, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín Mª López Muñoz <joaquin <at> tid.es> writes:
Thanks for the insight. If only boost::tuples::element<N,Tuple>::type was a documented feature ... The inheritance problem you describe is another proof that inheritance should not be used to extend interfaces in generic code and that containment is the superior approach (religious flamewars or very good arguments against this appreciated).
And the other solution is to write a user-defined extractor as explained in the aforementioned thread.
Your post to comp.std.c++ had no response (thread "Pointer to member contravariance and template non-type arguments") Do you have any new insight on DR or not DR? Markus
Markus Werle ha escrito:
JoaquÃn Mª López Muñoz <joaquin <at> tid.es> writes:
Thanks for the insight. If only boost::tuples::element<N,Tuple>::type was a documented feature ...
It's documented, although it's a little hard to find: go to "Advanced features" from Boost.Tuple docs main page.
The inheritance problem you describe is another proof that inheritance should not be used to extend interfaces in generic code and that containment is the superior approach (religious flamewars or very good arguments against this appreciated).
And the other solution is to write a user-defined extractor as explained in the aforementioned thread.
Your post to comp.std.c++ had no response (thread "Pointer to member contravariance and template non-type arguments") Do you have any new insight on DR or not DR?
No, unfortunately nobody answered. My feeling is that this is a defect, but I don't feel competent enough to file a DR withouht some prior discussion with an expert in the standard. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (2)
-
Joaquín Mª López Muñoz -
Markus Werle