Le mardi 01 avril 2014 00:18:11, David Strip a écrit : > On 3/31/2014 1:03 PM, Even Rouault wrote: > > Hi Etienne, > > > > Thanks for your ideas. > > > >> Hi all, > >> > >> I have a few suggestions for gdal 2.0, based on my personal experience > >> in learning to use, enhance and maintain gdal/ogr code. > >> > >> - replace cpl/csl/string/xml code with a mainstream, modern > >> cross-platform toolkit such as QT, boost, etc. > > > > QT is certainly a dependency we wouldn't want to draw. Too big for some > > embededded usage, and it would make GDAL to be practially bound by the > > LGPL. I guess standard C++ libraries classes, or perhaps boost, should > > do the job for what you mention below. > > +1 for the idea of moving to either well-supported toolkits or more > extensive use of the std library or features of C++11 > > >> While cpl/csl classes are robust and "do the job", they are not well > >> documented and not very intuitive for a new gdal coder. This is from my > >> personal experience, some may not agree. > >> They are also not used outside gdal, as such do not benefit from > >> enhancements as other toolkits. > > > > Well, at least, MapServer uses a few CPL functions : CPL minixml, > > CPLMalloc/CPLFree, CPLReadDir, CPLFormFilename, CPLGetFilename, > > CSLInsertString, etc.. > > To the extent that these remain necessary, making them a thin wrapper of > whatever standard lib/toolkit is adopted would both improve the > effective documentation, as well as make them compatible with the > library/toolkit (esp memory allocation)
Honestly, on that point, the migration cost vs the benefit does not seem obvious to me. > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Geospatial professional services http://even.rouault.free.fr/services.html _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
