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

[Kurt Schwehr]

For stack ranking, see the "alternatives" section of this (and I did not
include my preferred std::vector solution in the list):

https://docs.google.com/document/d/1Y9flzxj3Uz1vTEPCBmlswgi470m8i-oepGutVkbowfc/pub

BTW, Someone pointed out that I originally listed autoptr (which just won't
work) when I mean to say scoped_ptr.h.  I chatted with the original author
of scoped_ptr last year and have permission to share the latest version
from inside Google should that somehow become the solution of choice for
any particular issue, but I really think we should avoid scoped_ptr when
unique_ptr exists, is a standard and is more robust.  std::vector was not
the first solution I came up with for this issue.

On Fri, May 6, 2016 at 2:37 PM, Tim Keitt <tkeitt at utexas.edu> wrote:

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


-- 
--
http://schwehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160506/50d33aa8/attachment.html>