[gdal-dev] Misc. subjects : OSGeo Vienna code sprint, release plans, GDAL 2.0

[Even Rouault]

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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html