Other functions where CharAttribList::ResortAttribs() is called seem to
not guarantee that. So your fix would only help where the entire array
is already sorted, not where only partial sorting is to be retained.
Would be good to know if ContentNode::ExpandAttribs() and
ContentNode::CollapsAttribs
Hi Muthu,
On Tuesday, 2012-06-19 09:41:08 +0530, Muthu Subramanian K wrote:
> This doesn't seem to be a problem on 3.6+,
Maybe the boost::ptr_vector::sort() used there happens to be stable, I'm
not sure at the moment if it really is.
> so we need this
> workaround only on <=3.5. May be we can l
Hi Eike,
This doesn't seem to be a problem on 3.6+, so we need this workaround
only on <=3.5. May be we can live that? If so, it would be nice to
commit this to the 3.5 branch, please?
That said, there could still be cases (in any version) that the order is
changed by sort() (may be some co
Hi Muthu,
On Thursday, 2012-06-14 20:02:38 +0530, Muthu Subramanian K wrote:
> qsort seems to change the order of the elements even if the elements
> are sorted.
Yes, qsort and std::sort are not stable and preexisting relative
ordering is not preserved for equivalent elements.
> (Technically th
