Not being able to mutate elements through non-const iterators is surprising enough that I forget about it every time I use Boost.MultiIndex. Part of the reason for this is that this information is buried under section "multi_index/doc/tutorial/basics.html#seq_indices". I suggest that the following paragraph: "That is, iterators of a sequenced index (of all types of indices, actually) point to constant elements. This limitation might come as a surprise, but it is imposed by the way multi_index_containers work; if elements were allowed to be changed in this manner, we could introduce inconsistencies in other ordered indices of the multi_index_container. Element modification can nevertheless be done by means of update operations." be moved under "multi_index/doc/tutorial/basics.html#iterator_access" as a call-out.
Mostafa <mostafa_working_away <at> yahoo.com> writes:
Yes, this has bitten many users over the years. Updated doc along your suggestion: https://github.com/boostorg/multi_index/ commit/e18ece1ec13a8050aa5e75a522b8833dc37df37c Does this look any better? Joaquín M López Muñoz Telefónica
On Tue, 11 Nov 2014 12:30:17 -0800, Joaquin M Lopez Munoz <joaquin@tid.es> wrote:
Yes, thanks! I just have two nitpicks: 1) line 1076: I think the following: "sequenced index iterator's value_type is <i>constant</i>" is a little more clear. IMO the previous wording gave the impression that only const_iteratorS are available. 2) I'm kind of leery about picking out sequenced_index for special treatment since the same thing also applies to all other indices, so why isn't the same thing repeated for them also? HTH, Mostafa
Mostafa <mostafa_working_away <at> yahoo.com> writes:
Well, "constant iterator" is standardese for precisely what it's meant. Anyway, changed to make it more clear: https://github.com/boostorg/multi_index/ commit/f471d61d0b76aba27154a9a738e73271d03ec040
For key-based indices there is no need to stress this as the containers they are inspired on (std::[multi]set and std::unordered_[multi]set) behave the same (constant iterators). For random access indices, the initial explanation is that they're modeled after sequenced indices, so this restriction must be assumed also --besides, by this point the issue has been mentioned twice and the user is expected to be familiar enough with the lib (random access indices are not for the newcomer) that no further explanations on this particular detail should be needed (IMHO). Joaquín M López Muñoz Telefónica
participants (2)
-
Joaquin M Lopez Munoz -
Mostafa