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

[Tim Keitt]

http://www.keittlab.org/

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.

THK


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