ansaurus

Question

Boost Multi-Index with hashed_unique_index produces compiler error

Answer 1

A:

Okay Let's get working (comments just allow so much).

The problem stems from the invocation of the find method.

The template elected is:

template<
  typename CompatibleKey,typename CompatibleHash,typename CompatiblePred
>
iterator find(const CompatibleKey& k,
              const CompatibleHash& hash,
              const CompatiblePred& eq) const;

With:

KeyFromValue = composite_key<...>
CompatibleKey = unique_property
CompatibleHash = boost::hash<KeyFromValue>
CompatiblePred = equal_to<KeyFromValue>

Apparently, the invocation hash(k) inside the find method fails for the reason cited (could not deduce...), this methods itself invokes:

template<BOOST_MULTI_INDEX_CK_ENUM_PARAMS(typename Value)>
std::size_t operator()(const tuple<BOOST_MULTI_INDEX_CK_ENUM_PARAMS(Value)>& x)const

(Don't be afraid by the macro, it's just some magic Boost.Preprocessor to enumerate the Value from 0 to 9)

Now, from this we can see that the problem is that we try to build tuple<Value0, Value1, ..., Value9> from CompatibleKey ie unique_property and it does not work.

I think you should try:

ProbLocByHugo::iterator pos =
  local_data_structure.get<hugo>().find(boost::make_tuple(tempy));

Here is the example of composite_key from [Boost][1]:

file_system_by_name::iterator it=fs.find(
  boost::make_tuple(current_dir,dir));

boost::tie(it0,it1)=fs_by_size.equal_range(
    boost::make_tuple(current_dir));

As you can see, any invocation of key usage leads to make_tuple.

You could avoid this by providing the right conversion operator for your unique_property class.

operator boost::tuple< int, std::vector<int> const& >() const
  { return boost::make_tuple(my_int, cref(my_vec)); }

Or perhaps a variation...

I have to admit that I am a bit disappointed by this requirement, I would have expected that find would work seemlessly.

[1] http://www.boost.org/doc/libs/1%5F40%5F0/libs/multi%5Findex/example/composite%5Fkeys.cpp

Matthieu M. 2009-11-17 08:33:50

Hi, thank you very much for your time and your solution! I tried your first approach but it didn't work right away. After thinking about your second suggestion I tried the following call: `ProbLocByHugo::iterator pos = local_data_structure.get<hugo>().find(boost::make_tuple(tempy.get_int(),tempy.get_vec()));` And that did the trick! Thank you again for your much appreciated help!! Have a great day!

Dane 2009-11-17 09:33:53

You're welcome, I still don't get why this is not automatic anyway, as you have given the extraction method in template parameter...

Matthieu M. 2009-11-17 10:21:26

Answer 2

A:

Hi, Matthieu hints at the problem but probably does not expclicitly pinpoint it: find() expects a key or a compatible key and you're passing a whole element. How do you extract the key from tempy? There are two ways:

Construct a compatible tuple as Matthieu shows.
Each index provides a key_extractor() member function that returns a copy of the internal key extractor (here, a value of composite_key<...>) for you to use:

ProbLocByHugo::iterator pos = local_data_structure.get<hugo>().find( local_data_structure.get<hugo>().key_extractor()(tempy));

Hope this helps.

Joaquín M López Muñoz 2009-11-17 17:52:03

Hi, thank you for your additional information. But I don't see, how boost is not able to get these information by itself. I mean: I'm saying in the definition of the `composite_key` how to get the necessary members of an element/object of type `unique_property`, why do I have to do it again in any find-statement? On the other hand it is quite useful to be able to put just the necessary parts in a find-statement (if a complete element/object is expensive to build). But I think both ways wouldn't be that hard to implement... But thanks again for your info!

Dane 2009-11-18 08:27:40

I *could* add an overload of `find()` that takes whole elements rather than keys but I prefer to keep it terse becausethis is how STL containers work, they expect keys, not whole elements (cf. `std::map`), and because in some pathological cases, such overload would result in a problem: consider the following element type:`struct element{ const element}; ...private: element* k;};`and a `multi_index_container` with `const_mem_fun<element,const elementc.find(x);`Left as an exercise for the reader :-)

Joaquín M López Muñoz 2009-11-18 20:17:36

ansaurus

tags:

views:

answers:

Boost Multi-Index with hashed_unique_index produces compiler error

related questions