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

[Kurt Schwehr]

I was trying to give people an overall sense of my goals for GDAL.

I'm sorry I added the context to the proposal that got the discussion off
the track I intended.  I am more interested in mechanics of the discussion
before hitting huge topics.  I love the discussion, but I feel like I
totally failed at trying to test strategy for the GDAL community to have
discussions and get some basics added to the style guide with some why
attached.  I think we have lots to discuss before tooling and newer
versions of C++.  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 for this proposal... I do let myself get dragged a bit into the C++
version discussion a bit below to try to show that it is off topic of
>>>getting large objects off the stack<<<.

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


No.  Not configurable.  I propose to get large objects off the stack unless
a particular case severely impacts performance.


>

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


> - make the code shorter, hence clearer/more readable/maintainable
>

No.  Shorter wasn't a goal for this one.  It's sorter because my proposed
solution combines the definition and the initialization so as to not have
an uninitialized variable after the definition until the memset.

- make the code more C++  than C by allowing wide use of C++ standard
> features
>

No.


> ...
> So, in order to achive the above, you are proposing switch to newer C++
> version?
>

No.  I was trying to be complete in going through all the options available
inside and out of GDAL.  Only if the community really wanted a feature from
C++ >= 11 would I consider the language version a part of this proposal.


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

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


>
> 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.   Can we start with just
this simple proposal?


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

Yeah, I missed the boat on focus.


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

find . -name \*cpp | xargs grep include | grep stream | wc -l
53

find . -name \*cpp | xargs grep -h include | grep stream | sort -u
#include <fstream>
#include <iostream>
#include "mrsidstream.h"
//#include <sstream>
#include <sstream>
#include <strstream>


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

Yes, I understand this.  If you look at this proposal, you will find that I
was not proposing >= C++11.  I am working on a proposal for newer
versions.  I am thinking gradually.  There are non-cosmetic things that are
not very different but just work way better in the new standards.  And if
we go through a proposal process, you can have/should demand clean
examples.  And I think we should have a vote on these features.  If
maintainers are not ready for a feature, then vote against it!  Try to
think of baby steps.  If we say yes to C++11 being required, I think my
first proposal would be to switch NULL to nullptr (which is typed).  My
experience is that it does catch a number of strange edge case issues.
They are rare, but I have hit them.  While GDAL isn't huge, GDAL is big
enough that NULL might be be hiding these issues or it might happen in
future commits.  I don't think changing NULL to nullptr shouldn't be too
scary to C coders.

Even just switching the C++ version to C++11 would improve checking w.r.t.
the std lib, reduce the testing load on travis-ci, let us drop a couple
macros, and slightly simplify the build system.

But, all that is out of scope of my first proposal.


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



-- 
--
http://schwehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160509/550c5458/attachment-0001.html>