Boost Users :
Subject: Re: [Boost-users] [multi_index] sorted iteration of values
From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2013-09-04 04:12:58
El 04/09/2013 9:41, Mathieu Champlon escribió:
> On 04/09/2013 08:15, Joaquín Mª López Muñoz wrote:
>> In fact, you can get rid of index #2: when using a composite key you
>> can search by providing only the first m fields of the key, so for
>> all practical purposes index #2 is redundant with #0.
> With #2 I can erase by doing :
> units_.get< 2 >().erase( &publisher );
> With #0 it seems I need to do :
> auto range = units_.equal_range( &publisher );
> units_.erase( range.first, range.second );
> Or is there a shorter way ?
Well, erase is the only lookup function where you can't provide a
partial specification of the
composite key, so you have to do it as you write above.
> Also if my use case rarely uses #0 but uses #1 a lot (for instance #0
> is for adding/erasing
> while #1 is used to perform some operations very often), would it be
> more efficient to invert
> the indices or is it just a matter of whichever is the more convenient
> to write ?
Efficiency is not affected, it's just a matter of convenience (#index 0
can be used directly
without using get<0>().)
(In reality, efficiency can be affected, but probably in a negligible
way: when inserting an
element, Boost.MultiIndex inserts it first in index #0, then in #1,
etc., and if some index
fails (because of unicity constraints), previous insertions are undone.
So, if index A is more
likely to ban insertions than index B, it potentially pays off to have
index A at a lower
position than B.)
Joaquín M López Muñoz
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net