0

I would like to have a composite key for a multi index container of boost and would like to have a static comparator function passed to it (something like the code below). I also would like to avoid the solution given here to avoid the overhead of creating stack objects upon comparing every two elements as I'm working with a huge amounts of data. 

bool func(const foo& lhs, const foo& rhs) {
    if (lhs.count >= lhs.threshold && rhs.count < rhs.threshold ||
        lhs.count < lhs.threshold && rhs.count >= rhs.threshold) {
        return lhs.count < lhs.threshold;
    } else if (lhs.time != rhs.time) {
        return lhs.time < rhs.time;
    } else {
        return lhs.count < rhs.count;
    }
}

typedef boost::multi_index_container<
    foo,
    boost::multi_index::indexed_by<
        boost::multi_index::ordered_unique<
            boost::multi_index::composite_key<foo, member, member>,
            func
        > 
    > 
> MultiIndexSet;
Community
  • 1
  • 1
mkmostafa
  • 3,071
  • 2
  • 18
  • 47
  • Could you please elaborate on the "stack object" concern? For all purposes, passing a comparison _functor_ (a `struct` with appropriately overloaded `operator()`) is maximally efficient, i.e. there's no difference vs. passing a comparison _function_ in terms of memory consumption. – Joaquín M López Muñoz Feb 24 '16 at 18:25
  • I dont mean memory I mean time concerns. As far as I know that per comparing two items an object functor must be constructed then comparing function called then object destroyed and this will happen for each compare or Is there something I'm missing?? – mkmostafa Feb 25 '16 at 10:11
  • 1
    This is not the case, and even if it were it wouldn't have any impact on execution time, since this is the kind of things that compilers optimize away. In fact, providing a functor rather than a function gives the compiler more opportunities for optimization, so I'd bet a functor is actually faster. – Joaquín M López Muñoz Feb 25 '16 at 11:16

0 Answers0