[gdal-dev] Minimum supported C and C++ standards

[Andrew Bell]

On Sat, May 7, 2016 at 2:00 PM, David Strip <gdal at stripfamily.net> wrote:

> On 5/7/2016 11:10 AM, Kurt Schwehr wrote:
>


> This is cart before the horse but... as fast as I can so expect typos.
> Now just think of a ~1K long function or method with tons of instances and
> lots of places to bailout successfully or as failures.

This is why starting with zero features and working our way up with a white
> list gives examples of correct usage.  It looks like a lot of GDAL
> development happens by copy-paste-tweak, so good examples are key.  And for
> every issue, we have solutions that are valid C/C++03/C++11/C++14... the
> best solution is not necessarily in any particular one.
>
> Amen.
>
>
> auto poInstance = std::make_unique<GDALMyBigObj>(arg1, arg2, arg3);
>
>
I think that some of you may be talking about features of a language that
you really aren't comfortable with.  The notion of disallowing language
features because someone thinks they aren't useful or are confusing isn't
the way to go, IMO.  C++, more than most other languages, goes through
pains before features are introduced.  Nobody has to use all the features,
but all are useful to a subset of users and their proper use either makes
the code more clear, more efficient or less prone to bugs.  (Yes, auto_ptr
was awful, but nobody uses auto_ptr anymore). Regardless of the language or
language feature, code can be clear or unclear and it's not the fault of
the feature for the lack of clarity.  It may be that the reader hasn't seen
the use before or it may be that the writer didn't use feature in the best
way possible, but to make lists because Fred or Sam don't like this or that
isn't productive.

This example is more powerful than just the elimination of the
> opportunities for memory leaks. Kurt has snuck in the use of the
> GDALMyBigObj constructor, which makes the initialization of the object more
> transparent (and in fact assures that it occurs.) And if I correctly
> understand std::make_unique, by making poinstance const, we can go farther
> and guarantee that this pointer isn't assigned to another pointer, so that
> the object will be destroyed at the end of current scope. (If the pointer
> is assigned to another std::make_unique ptr, the scope of that pointer will
> control when the object is destroyed).
>

As someone else said, GDAL code looks like C code, not like well-structured
C++.  That's OK.  But the notion of shoe-horning this or that feature into
the codebase seems fraught.  If you're going to say that C++ 11 is OK, then
fine, use C++ 11 where appropriate in ways that make the code more
readable, more efficient or smaller.  The reason to disallow a feature
shouldn't be about the whims of a developer or two, it should be because
compilers you are targeting don't support them or because you have ABI
issues.  Reviewing code as it's submitted for clarity and efficiency is a
much better way to ensure quality code than is coming up with a
semi-arbitrary list of acceptable language features.  Yes, sometimes even
"goto" is a good thing.

I also don't agree that more features mean more bugs.  More features means
a language that takes more care to learn, but it doesn't mean more bugs.
If you're uncomfortable with move constructors, don't use them.  But they
are useful at certain times for optimization.  The provided example is just
confusing and useless code, not an indictment of move constructors.  There
are plenty of newer language features that make code LESS susceptible to
bugs, when used properly.

P.S. - The above would just normally be written:

std::unique_ptr<GDALMyBigObj> obj(new GDALMyBigObj(arg1, arg2, arg3));

although without context, it's unclear that this is good bad or neither.
If I saw this code without a comment, I'd be tempted to change it to:

GDALMyBigObj obj(arg1, arg2, arg3);

because, hey, why not put it on the stack?  The important bit here is that
someone needs to add a comment that it was put on the heap for a reason --
to keep the stack small.

P.P.S - I used to think lambdas were confusing, useless things.  Having now
seen and written enough code containing lambdas, I'm happy to admit that I
was wrong.

-- 
Andrew Bell
andrew.bell.ia at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160507/4abf641a/attachment.html>