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

[Kurt Schwehr]

Mateusz,

Thanks for calling out the confusion!  Are meaning to say that my proposal
<https://docs.google.com/document/d/1Y9flzxj3Uz1vTEPCBmlswgi470m8i-oepGutVkbowfc/pub>
is
vague?  I rephrased the status to be more clear that the C++11/14 focus is
the GDAL community (AKA the majority of this thread), not the proposal.
Hopefully it is clearer now.  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.

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.
>
> Simply, the initial proposal was quite confusing.
>
> The 'title' said indicated it was "mostly focused on C++11/14 & C99/11",
> while the content mentioned mostly the std::vector as malloc'ed arrays
> replacement.
>

That was just a status I added after the fact.  I worded it poorly.


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

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.

I'm not sure if the facts mentioned in the proposal, namely
> "Want to focus on maintainability and readability of code",
> is meant to be a fact or a goal.
>

That would be a goal.  And readability is going somewhat be subjective.


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


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


> Surely, the override and final will help compiler to catch potential bugs.
> Also, C++11/14 compilation mode is generally stricter, so it might
> help to catch bugs.
>
> Simply, the whole proposal is becoming vague.
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160507/95579084/attachment.html>