Re: [Boost-users] Turning Boost.Multi-Index ordered_non_unique index into ordered_unique one, with custom comparator

Subject: Re: [Boost-users] Turning Boost.Multi-Index ordered_non_unique index into ordered_unique one, with custom comparator
From: Dominique Devienne (ddevienne_at_[hidden])
Date: 2016-03-03 04:52:13

On Thu, Mar 3, 2016 at 10:21 AM, Joaquin M LópezMuñoz <joaquin_at_[hidden]>
wrote:

> Dominique Devienne <ddevienne <at> gmail.com> writes:
> > I would like to support a slightly unusual use-case. [...]
>
> Steven's answer is, as always, correct, and we can leave it at that. But,
> if you want to venture into uncharted lands...
>

it always is indeed. But also terse as well, also as usual :)
I appreciate the hand-holding here Joaquin, I can definitely use it!

> Suppose we use the following:
>
>   template<typename T,T puncture>
>   struct punctured_less
>   {
>     bool operator()(const T& x,const T& y)const
>     {
>        if(x==puncture&&y==puncture)return true;
>

But can we do better? If like in any initial email, you take into account
that the to-be-indexed int is part of a larger struct with other fields,
which can be used to "break ties" between elements who's index
match the "puncture"?

This is why I asked about the comparator accessing the whole element struct.

>        return x<y;
>     }
>   };
>
>   using set=boost::multi_index_container<
>     int,
>     indexed_by<
>       ordered_unique<identity<int>,punctured_less<int,-1>>
>     >
>   >;
>

Stated differently, this is closer to our actual use-case:

struct entry {
  int uid; // real uuid in reality, but enough for our needs here
  int occurence; // the field to be indexed, uniquely "except for -1"
};

struct by_occurence{};
using bmi = boost::multi_index_container<
  entry,
  indexed_by<
    random_access<>,
    ordered_unique<
      tag<by_occurence>,
      identity<entry>,
      magical_occurence_less<entry, -1>
    >
  >
>;

except right now, we have,

    ordered_non_unique<
      tag<by_occurence>,
      member<entry,int,&entry::occurence>
    >

> First thing to notice is: punctured_less<int,-1> is *not* a strict
> weak ordering.

Yes. And that's why I'm asking whether "other" fields can "make it better"
somehow.
I "think" lookups would be resolved then, but I'm unsure that's "sound".
--DD