sorted_vector, constness, pointers, and structs

[Lubos Lunak]

On Thursday 19 of July 2012, Stephan Bergmann wrote:
> On 07/18/2012 08:09 PM, Lubos Lunak wrote:
> >   What you want is broken. It is definitely broken from the theoretical
> > point of view, since modifying the items may change the sort order.
>
> While one can argue that it is broken, in practice I would not bother
> trying too hard to make the code safe against shooting-in-one's-foot at
> the expense of simplicity.  Whether or not making non-const element
> access available for sorted_vector<T,C> is safe depends on both T
> (element type) and C (comparison function), and e.g. adding a
> specialization so that sorted_vector<T*> only gives access to T const*
> can be OK or overly restrictive.
>
> Quoting an answer I inadvertently only sent to Noel directly:
>
> "Yeah, the 'only give const element access to avoid element
> modifications that invalidate container invariants' strategy is
> apparently not perfect.
>
> "If you do need non-const access, there's no way around it than to offer
> it---and being careful not to accidentally invalidate the container's
> sortedness."

 Famous last words ... who's ever seen developers being always careful, 
huh :) ?

 If it's really impractical to have anything else than direct access that 
might possibly break the whole container, then the container really could use 
a checking code that would assert the correctness. I think it'd be enough to 
do it in insert() and erase(), and given it's a vector, it wouldn't matter 
much for performance even when enabled in debug builds.

-- 
 Lubos Lunak
 l.lunak at suse.cz