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

Tim Keitt tkeitt at utexas.edu
Fri May 6 14:37:28 PDT 2016


On Fri, May 6, 2016 at 1:55 PM, Kurt Schwehr <schwehr at gmail.com> wrote:

> I was not intending for C++11 to be a big part of the discussion as it is
> a much more complicated topic, but I do appreciate the discussion.  I
> picked the stack + memset -> std::vector(nSize, initialValue) to do first
> because I thought it was a simpler issue than most and we could use it to
> figure out how to go about these sorts of discussions.  It's not a show
> stoper, but it is a real need.
> At this point, I think it would be good if we could pause the C++11
> discussion for a bit and back up to the original question.
> I'd like to ask folks a couple of things:
> - If you could stack rank (all or some) the options assuming that C++14
> was available

What are the options and for what purpose? (I have not followed the thread
in detail.) I'd like to see pointer types banished or if necessary wrapped
with std::auto_ptr (or whichever variant makes sense).

> - Is your top pick far better than the rest or just a little better?
> - Are there any options that you think should not be used in GDAL?
> - Are there any reasons to be for or against any particular alternative
> that we need to call out?

Always prefer vanilla standard library over others.

> My belief is that for this particular proposal, we should not have the
> C++11/14 discussion unless the best overall solution requires a newer
> version of C++.  The solution I propose to be the best works in C++03 and
> newer.

I have longed for GDAL to be a modern C++ library that follows the STL, so
any move in that direction would be terrific in my opinion. It would be
nice to have the latest and greatest C++ bits, but I would be very happy
with C++03. I strongly suggest maximizing use of the STL to avoid
reinventing the wheel. If you need custom allocation, use a custom
allocator with an STL data structure. I would also recommend judicious use
of Boost where appropriate.


> On Thu, May 5, 2016 at 2:25 PM, Even Rouault <even.rouault at spatialys.com>
> wrote:
>> > I misinterpreted this thread because of the title.  It seems this isn't
>> > really about code style or C++ 11.
>> I agree this thread mixes different topics, which causes some confusion.
>> The
>> word C++11 appearing in a doc has created some passion, whereas it is
>> probably
>> not the heart of the subject.
>> Kurt has contributed to a lot of cleanup in the code base over the last
>> months, mostly in applying stricter formatting rules, bool'ifying,
>> const'ifying when possible, moving variable declarations close to their
>> initialization, etc.. (Kurt, correct me if I'm wrong.), also addressing a
>> bunch of Covertiy Scan warnings, etc.
>> I've actually encouraged him to share his thoughts regarding cleanups
>> with the
>> rest of the community so that we can decide which are worth to be rules
>> that
>> apply to the project as a whole, and if some tooling is needed to
>> automate/enforce them.
>> > It's really about Google wanting to use
>> > heap over stack because of its particular use of the library.  There is
>> no
>> > need for C++ 11 for that and it would seem that doing a compile-time
>> > policy-based array isn't too hard (proof of concept below).  Perhaps
>> Google
>> > could flush something like this out to its liking and replace current
>> stack
>> > allocations that cause it issues.
>> This use case is probably shared by other actors that use GDAL for massive
>> data processing, and if the solution to reduce stack usage doesn't hurt
>> more
>> mundane use cases, we probably don't need the #ifdef complication.
>> --
>> Spatialys - Geospatial professional services
>> http://www.spatialys.com
> --
> --
> http://schwehr.org
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160506/77221523/attachment-0001.html>

More information about the gdal-dev mailing list