[gdal-dev] Starting a discussion on style and coding guidelines
mateusz at loskot.net
Mon May 9 09:21:02 PDT 2016
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
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.
> b) How? Use standard containers
> Yes. I propose this
> 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
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.
Mateusz Loskot, http://mateusz.loskot.net
More information about the gdal-dev