sorted_vector, constness, pointers, and structs

[Lubos Lunak]

On Wednesday 18 of July 2012, Noel Grandin wrote:
> On Wed, Jul 18, 2012 at 7:23 PM, Lubos Lunak <l.lunak at suse.cz> wrote:
> >  But it is correct that you get an error in the second case and you
> > ideally should be getting one in the first case as well. You cannot
> > modify the elements of the vector because that might modify what defines
> > their position in their sorted order, isn't that so? That is exactly the
> > reason for those changes as suggested by David and Stephan.
>
> Ummm. No.
> The sorted_vector class is not intended for storing primitive values.
> Virtually all of the use-cases create a custom comparator operation.
>
> Almost all of time, we are storing complex structs/classes in these
> vectors, and they have numerous fields that can and do need to be
> easily modifiable.
> Returning const-only references defeats that.

 Nevertheless that is exactly the reason why David and Stephan suggested those 
changes, and the rest of my mail still applies as well.

> So we end up having to cast away the const-ness most of the time,
> which makes the supposed protection worthless.

 You didn't read further than that part above, did you?

 What you want is broken. It is definitely broken from the theoretical point 
of view, since modifying the items may change the sort order.

 Another alternative, if the explicit accessor is not practical, might be to 
store the item as a pair, the sort key and the item itself. In that case 
modifying the item would not alter the sort key, so it would be safe again. 
In that case however you might have a problem if modifying an item actually 
should change the sorting order. And if that is the case, then I think it's 
asking for trouble no matter how you look at it, it'll be just about how 
likely it will be to actually run into it.

-- 
 Lubos Lunak
 l.lunak at suse.cz