[gdal-dev] Starting a discussion on style and coding guidelines
schwehr at gmail.com
Mon May 9 07:47:26 PDT 2016
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
> 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
> So, in order to achive the above, you are proposing switch to newer C++
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.
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
> 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>
> >> 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
> > etc.
> In GDAL? e.g. streams are not used or they use is marginal.
find . -name \*cpp | xargs grep include | grep stream | wc -l
find . -name \*cpp | xargs grep -h include | grep stream | sort -u
> >> 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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gdal-dev