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 Telefónica Digital ________________________________ 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: http://www.tid.es/ES/PAGINAS/disclaimer.aspx