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.lu...@suse.cz _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice