[poppler] Question on policy w.r.t. code modernization
Albert Astals Cid
aacid at kde.org
Mon Dec 28 09:55:44 PST 2015
El Friday 25 December 2015, a les 14:38:12, Adam Reichold va escriure:
> Hello,
>
> remembering how I tried to push some minor optimizations to GooString
> some time ago, I wanted to ask about the project's policy on how to
> handle code modernizations in the future.
>
> To me, it seems like stuff that is pervasive like GooList or GooString
> is unlikely to be changed with the currently available man power due to
> the risk of regressions. One way of resolving this is IMHO to try to
> remove the code completely and replace it with externally maintained and
> highly optimized components, e.g. using std::vector and std::string from
> the standard library instead of GooList and GooString. But this will
> probably make it rather hard to merge xpdf changes in the future. Then
> again, this seems to be hardly happening as is.
Do we actually get any benefit for using std::string instead of GooString?
I can only see it creating regressions and lots of work for what is probably a
very marginal speed improvement (happy to be proven wrong) and also the class
does not give us any maintainance overhead since it's "done".
If we're going to diverge for the sake of modernizing the source code i think
that makes more sense adding overrides to overriden functions, adding const to
const functions and making sure that classes that should not be copied/
assigned by value have the copy constructor and assignment operators deleted.
> So I guess that basically, my question is on the opinions of the
> maintainers to detach the Poppler code base from the xpdf code base as a
> prerequisite to thoroughly modernizing it. Related to this is the
> question on whether raising the language standard to C++11 or C++14 is
> considered possible.
>
> Best regards, Adam.
More information about the poppler
mailing list