[gdal-dev] Starting a discussion on style and coding guidelines

[Peter Halls]

I am a humble geologist, rather than a Computer Scientist, and do not
pretend to understand all the ins-and-outs of this type of discussion - and
hence read, in the hopes of learning, but otherwise keep quiet!

I suspect that I am also something of a 'throw-back' in that I continue to
use Simula as my primary programming language.  Today's Simula compilers
are 'cross-compilers', in that they generate code in c, which is then
compiled and linked with an appropriate c compiler (it actually makes
providing software for multiple platforms a lot easier ...).

Having said that, my only concern with the use of (C++) Vector structures,
rather than c Arrays, would be the mappability required between application
language and implementation language.  If the C++ structures are universal,
fine.  If not, then either interface code (needing maintenance) or c
alternatives would be needed.  My example is based on Simula: it would be
interesting to know how Java or Python might interact.

Best wishes,

Peter


On 5 May 2016 at 00:45, Even Rouault <even.rouault at spatialys.com> wrote:

> Le jeudi 05 mai 2016 00:51:28, Mateusz Loskot a écrit :
> > On 4 May 2016 at 23:30, Kurt Schwehr <schwehr at gmail.com> wrote:
> > > To start off the conversation, I wrote up a doc on changing large C
> > > arrays on the stack to std::vectors to get this data off of the stack
> > > and to simplify initialization.
> >
> > Since many, if not most, of the ideas rely on availability of the C++11
> > features,
> > it might be a good idea to first agree on C++11 as the lowest
> > required C++ compilation mode.
> >
> > Let's poll if there are any users who require C++03 at all.
>
> I think there are different topics in what Kurt proposes :
> - style and other changes that are not bound to a particular compiler
> version
> - changes potentially dependant of the C++ version
>
> Of the potential issues with requiring C++11, I can think of OSGeo4W. It is
> mostly(completely?) built with Visual Studio 2010. And from
> https://msdn.microsoft.com/en-us/library/hh567368.aspx , support of C++11
> is
> only partial in VS 2010
>
> Regarding the current use of VS2010 in OSGeo4W, this is discussed here :
> https://lists.osgeo.org/pipermail/discuss/2016-February/015658.html
>
> Potentially we could imagine having GDAL compiled with a later VS version
> and
> have the rest using VS2010, since most (all?) other software in OSGeo4W
> use it
> probably through its C API. Hum, actually that must not be true for OTB
> that
> uses the C++ API I think. Perhaps Jürgen has something to add regarding
> this
> compiler issue ?
>
> On the other hand regarding dependencies of GDAL, the binary propritary
> SDKs
> with a C++ API could be a problem, although they will likely move on too.
> - FileGDB SDK 1.4: available for VS2010, VS2012, VS2013
> - ECW SDK 5.2.1: available for VS2010, VS2012, VS2013
> - MrSID SDK: I didn't check. Perhaps Kirk can tell us ?
> But I'm not sure about the compatibility of C++11 build against non-C++11
> builds in the VS realm : can a GDAL C++11 build link against a library
> built
> without C++11 enabled ? Will not there be ABI problems ?
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev




-- 
----------------------------------------------------------------------------------------------------------------
Peter J Halls, PhD Student, Post-war Reconstruction and Development Unit
(PRDU),
                      University of York

Snail mail: PRDU, Derwent College, University of York,
                Heslington, York YO10 5DD
This message has the status of a private and personal communication
----------------------------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160505/8d0af450/attachment.html>