[gdal-dev] Minimum supported C and C++ standards

Kurt Schwehr schwehr at gmail.com
Mon May 9 11:38:42 PDT 2016


Agreed on the 11 v 14 issues.

On Mon, May 9, 2016 at 11:17 AM, Even Rouault <even.rouault at spatialys.com>
wrote:

> Le lundi 09 mai 2016 19:28:48, vous avez écrit :
> > Here is my current take on language standards
> >
> > - I am working on a C++11/14 C99/11 proposal.  I despirately want to be
> > able to use C++11 to make GDAL more robust
>
> C++11 is probably OK, but C++14 support is really "new". For Linux
> distros, we
> should try to make GDAL compilable on the current LTS and probably in the
> case
> of Ubuntu last-1 LTS with their default compiler.
>
> For example RHEL 7 ships with gcc 4.8.X, Ubuntu 14.04 too.
> I've checked that gcc 4.8 refuses -std=c++14. It accepts -std=c++1y
> though, so
> some features of C++14 might be available.
>
> At least for the sake of our CI environements : Travis has no immediate
> plans
> for now to ship with with Ubuntu 16.04 (
> https://github.com/travis-ci/travis-
> ci/issues/5821 )
>
> > - As it stands I will vote >>>against<<< my proposal any time soon -
> until
> > with have a bunch of proposals for changes to GDAL that require new
> > language versions or someone rewrites my proposal to be much more
> > compelling -

Which proposal exactly ? AFAICS in this thread, it was more about polling
> opinions.
>

I have not sent out the doc yet.



>
> > We have lots of work that we can do to make GDAL maintenance
> > / debugging easier that does not require newer language versions
> > - We have successfully ( at least in my opinion ) stuck a toe in the
> C++11
> > world with CPL_FINAL, CPL_DISALLOW_COPY_ASSIGN, NULL_AS_NULLPTR, and
> > my std::lock_guard<std::mutex> experiments.  We can probably do a bit
> more
> > if we are careful.
> > - I think having an experimental autotest2 C++11/14 only testing tree
> might
> > be the way to start.  Those who want to can try it out or look through
> what
> > is possible and it won't impact the main tree or the existing C++ tests.
> >
> >
> > I would be happy to start contributing to
> > https://trac.osgeo.org/gdal/browser/trunk/autotest2, especially if we
> call
> > it experimental and I can get help with adding a build system.  I have
> >
> > >5000 lines of C++ in 32 test files that mostly cover the port directory
> >
> > right now.  I got hung up on trying to create a working initial version
> in
> > a separate github tree.  Adding it to the existing svn tree would get me
> > around that issue (it's an internal work thing).  Here is
> > cpl_string_test.cc... it's super boring.
> >
> >    https://gist.github.com/schwehr/02128959ee78d56b553defa0a527bdf2
> >
> > It's written using the Google C++ style guide and is based on gunit,
> gmock
> > and glog.
> >
> > - https://google.github.io/styleguide/cppguide.html
> > - https://github.com/google/googletest
> > - https://github.com/google/glog
>
> Are those available as ready to be installable packages ? (thinking about
> integration with CI)
>
>
The people who maintain gunit/gmock prefer that projects package the gunit
code inside their repos.

git clone git at github.com:google/googletest.git
cd googletest
find . -type f | wc -l
     340

du -hs
8.9M .

e.g. for libais, I just made third_party and put them in side that...

https://github.com/schwehr/libais/tree/master/third_party


> >
> > On Mon, May 9, 2016 at 2:33 AM, Mateusz Loskot <mateusz at loskot.net>
> wrote:
> > > On 7 May 2016 at 19:10, Kurt Schwehr <schwehr at gmail.com> wrote:
> > > >> If we move to a later C++ standard, or even use features of C++98 we
> > > >> currently
> > > >> don't use, I'd advocate for using things that are obviously making
> the
> > > >> code
> > > >> better / more readable. Honestly who finds that
> > > >> "std::unique_ptr<int *, std::function<void(char *)>>
> > > >> Vals(CPLCalloc(256, 0),
> > > >> CPLFree);" is obviously more readable, efficient and less error
> prone
> > >
> > > than
> > >
> > > >> "std::vector Vals(256,0)" ?
> > > >
> > > > This is cart before the horse but... as fast as I can so expect
> typos.
> > >
> > > Now
> > >
> > > > just think of a ~1K long function or method with tons of instances
> and
> > >
> > > lots
> > >
> > > > of places to bailout successfully or as failures.  We have > 9K
> > > > free/CPLFree/CPLdelete/CPLDestroys that could be < ~100.
> > > > [...]
> > >
> > > ...the very long story short, your desire is to introduce the RAII
> idiom
> > > across GDAL codebase. Awesome!
> > > I'm sure 99% of GDAL committers will welcome this idea.
> > > Then, **next** question is how we want to implement it:
> > > using C++11+ features, home-brewed smart pointer class(es), etc.
> > >
> > > Upgrading to C++11+ just for the sake of upgrade, makes little sense to
> > > me. Especially if folks are not certain about it, don't use those
> > > features daily,
> > > don't feel comfortable...it may cause more harm.
> > >
> > > Best regards,
> > > --
> > > Mateusz Loskot, http://mateusz.loskot.net
>
> --
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160509/2b5a0884/attachment.html>


More information about the gdal-dev mailing list