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

[Kurt Schwehr]

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

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.


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160506/571e5fac/attachment.html>