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

[Mateusz Loskot]

On 9 May 2016 at 16:47, Kurt Schwehr <schwehr at gmail.com> wrote:
> There are lots of implicit style things in GDAL that I have been
> trying to bend my coding to, but I find clashing styles in the same file all
> the time, so it is hard to get what I do to match.

Just choose the one of the two you like more.

> On Mon, May 9, 2016 at 5:59 AM, Mateusz Loskot <mateusz at loskot.net> wrote:
>> On 8 May 2016 at 07:01, Kurt Schwehr <schwehr at gmail.com> wrote:
>>
>> - make the stack/heap usage more configurable
>
>
> No.  Not configurable.  I propose to get large objects off the stack unless
> a particular case severely impacts performance.

Yes, I got it,
I meant coding/compile-time configurable, if necessary, with
standard container/custom allocator/traits, etc.
There could even be a #define to control that all current T buffer[12345]
become heap-based or stay stack-based buffers.
However, actual realisation does not matter at this point.

>> - use new C++ features to introduce widely recommended idioms
>
> No.  I do not propose using any C++ features new to GDAL.  This is just the
> old vector size with initializer constructor.

As one of your argument, I have seen RAII proposed.

>> > Please read the proposal as just looking at the possibilities.
>> > Please try not to care about C++ language version when
>> > trying to do a first round review of ideas.
>>
>> I have and as far as I can see, there are just two objectives:
>> 1. Make GDAL stack-friendly by preferring heap for arrays.
>>     How? Use standard containers and smart pointers.
>
>
> That is 3 statements:
>
> a) Make GDAL stack-friendly by preferring heap for arrays.
>
> Yes.

OK,

> b)  How? Use standard containers
>
> Yes.  I propose this

OK

> c) and smart pointers
>
> No.  In this case, a smart pointer looks to be less attractive (to me).
>
>> 2. Introduce RAII across the whole codebase.
>>     How? Use smart pointers and other related techniques.
>
>
> No!  Out of scope of this proposal.  (For another proposal, then yes).

Again, I have seen arguments like this
https://lists.osgeo.org/pipermail/gdal-dev/2016-May/044355.html

But, OK, I assume it is no longer part of your proposal.

>> That's all I can see from most of the content there.
>> (The many fine-grained details are not critical to make the actual
>> 'big' decisions, those will come into play later.)
>>
>> So, as I have already mentioned, great.
>> Now, let's decide wheter we switch to C++11 to get the necessary tools or
>> implement our own tools, e.g. as part of CPL.
>
> No.  Please do not do that with my proposal.  That is way way too far out of
> scope of what I intended for *this* proposal.

I'm not doing anything with it.
I'm just asking questions and stating my understanding of your goal,
some I might have got wrong.

>  Can we start with just this simple proposal?

Sure. I have got my issues cleared, thanks.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net