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

Mateusz Loskot mateusz at loskot.net
Mon May 9 05:59:47 PDT 2016


On 8 May 2016 at 07:01, Kurt Schwehr <schwehr at gmail.com> wrote:
>
> Are meaning to say that my proposal is vague?

Yes, I called that on the course of the discussion, it has become less and less
clear to me: what is the actual goal?
- make the stack/heap usage more configurable
- use new C++ features to introduce widely recommended idioms
- make the code shorter, hence clearer/more readable/maintainable
- make the code more C++  than C by allowing wide use of C++ standard features
...
So, in order to achive the above, you are proposing switch to newer C++ version?

> 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.
2. Introduce RAII across the whole codebase.
    How? Use smart pointers and other related techniques.

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.

I believe, much of the discussion would have gained more focus if the problem
was stated like that.

> On Fri, May 6, 2016 at 2:47 PM, Mateusz Loskot <mateusz at loskot.net> wrote:
>>
>> On 6 May 2016 at 21:55, Kurt Schwehr <schwehr at gmail.com> wrote:
>> > 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.
>>
>> Considering current codebase, GDAL is written in C and compiled in C++.
>> The only major C++ feature used in GDAL is classes and polymorphism.
>
>
> I agree that GDAL has a strong feel of C compiled with C++ right now.

Since that is a fact, there is nothing to agree about.
Please, notice, I'm not speaking here about my personal preferences,
just the state of the art.

> I disagree about C++ feature use.  I see algorithm, iostream, map, list,
> sstream, a few exceptions, std::string (mostly in the form of CPLString),
> vector, localization of variables, some templates, #define to static consts,
> etc.

In GDAL? e.g. streams are not used or they use is marginal.


>> If you ask any seasoned C programmer for opinion, I bet she will
>> consider GDAL codebase as clear and readable.
>> If you ask a C++ programmer, the answer might be different.
>>
>> IMO, I doubt any C++11/14 feature will increase the current code,
>> unless it is considered to ditch many of CPL features and replace
>> them with C++ standard features (string bashing operations, string
>> containers,
>> containers for other types, threading API, etc.).
>>
>
> "increase the current code" <- Did you mean increase the reliability?  Or
> size? Or complexity?

Sorry, sloppy typing. I meant code clarity, readability.

>> Certainly, any new line to be written may benefit from auto,
>> constexpr, using, nullptr, range loops - but for a "C with classes"
>> codebase as GDAL, it would be cosmetic improvement, if any.
>>
>
> I disagree that C++11/14 changes would be cosmetic.  But this is the wrong
> thread for this part of the discussion.

IMHO, you are missing one important point.
I'm not arguing that shifting from C with classes mode to C++11-17
is not going to increase software quality. Of course it is, if applied
properly and *at all*.

Have you considered current maintainers might not be willing to start using
the latest and the greatest C++11-17 features?
If they are not...changes will be rather cosmectic.

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


More information about the gdal-dev mailing list