About simplifying sortElements in pdfiprocessor (sdext)

[Julien Nabet]

Hi,

I noticed this part in PDFIProcessor::sortElements from 
sdext/source/pdfimport/tree/pdfiprocessor.cxx:

     700     // HACK: the stable sort member on std::list that takes a
     701     // strict weak ordering requires member templates - which we
     702     // do not have on all compilers. so we need to use 
std::stable_sort
     703     // here - which does need random access iterators which the
     704     // list iterators are not.
     705     // so we need to copy the Element* to an array, stable sort 
that and
     706     // copy them back.
     707     std::vector<Element*> aChildren;
     708     while( ! pEle->Children.empty() )
     709     {
     710         aChildren.push_back( pEle->Children.front() );
     711         pEle->Children.pop_front();
     712     }
     713     std::stable_sort( aChildren.begin(), aChildren.end(), 
lr_tb_sort );
     714     for (auto const& child : aChildren)
     715         pEle->Children.push_back(child);

(see 
https://opengrok.libreoffice.org/xref/core/sdext/source/pdfimport/tree/pdfiprocessor.cxx#688)

1) Using directly sort method of std::list and get rid of intermediary 
vector

The comment has been put in 2008 (see 
969aac0edf437ec0cad0baadfde46188c4822161)

Is the comment still right for some compilers or may we use the sort 
method of std::list now ?

2) Useless recursion?

This function takes bDeep as parameter and can call itself if bDeep is 
equal to true.

However, Opengrok shows that:

- default value for bDeep is false

- this function is never called with the value true

See 
https://opengrok.libreoffice.org/search?project=core&q=sortElements&defs=&refs=&path=&hist=&type=

Julien