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

[Kurt Schwehr]

See also for googletest on travis-ci:

https://github.com/google/googletest/blob/master/.travis.yml

And there is libgtest-dev on ubuntu, but the project stopped doing point
releases a long time ago (~2005).

https://github.com/easylogging/easyloggingpp/blob/master/.travis.yml
https://amodernstory.com/2015/07/27/upgrading-travisci-build-scripts/

On Mon, May 9, 2016 at 11:38 AM, Kurt Schwehr <schwehr at gmail.com> wrote:

> 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 <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
>>
>> --
>>
>


-- 
--
http://schwehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160509/8465749f/attachment-0001.html>