From: Joaquin M Lopez Munoz (joaquin_at_[hidden])
Date: 2006-06-07 18:00:05
Prashant Thakre <prashant.thakre <at> gmail.com> writes:
>
> Hi,
> Guess, I should have given a code snippet :(
>
> >But, how are you planning to actually implement this?
> >Certainly you can't do the following:
> struct element
> {
> public:
> boost::tuple<t0,t1,...tn> tp;
> // ...
> };
>
> As per your first suggestion:
> >1. If the maxium number of keys of the composite_key is bounded
> >then you can use that maximum and later on, at run-time, take
> >advantage of only the first N key slots.
> struct element
> {
> //Assumption: no more than 10 elements, a reasonable limit I guess.
> //
> boost::tuple<t0,t1,...t9> tp;
> const std::string & tuple_element(const int ind) const {
> return tp.get<ind>;
> }
> //...
> };
Well, this can't work as is, cause tp.get<ind> requires
that ind be a compile-time constant, which is not (it is
an argument to tuple_element). Actually, I think it
would be hard (though not impossible) to treat tuples,
whose dimension is compile-time, as run-time sized objects.
Let's turn to the second approach:
> As per this suggestion:
> >2. You can have std::vector<> as the key, the comparison semantics
> >of this container in some ways resembles that of an infinite-length
> >composite key.
> struct element
> {
> std::vector<const std::string > tp;
> const std::string & tuple_element(const int ind) const {
> return tp[ind];
> }
> //...
> };
OK, here, instead of a composite_key instantiation,
you can take advantage directly of std::vector comparison
semantics (you don't really need tuple_element):
typedef multi_index_container<
element,
indexed_by<
hashed_unique<
member<element,std::vector<const std::string>,&element::tp>
>
// other indices, maybe
>
> element_collection;
Now, you can use n-sized vectors everywhere, where n is
determined at run-time. Does this suit your needs?
JoaquÃn M López Muñoz
Telefónica, Investigación y Desarrollo