[gdal-dev] RFC 8 DevGuide Update (was: Best vector driver?)
mateusz at loskot.net
Fri Feb 17 00:40:58 PST 2017
On 16 February 2017 at 16:10, Kurt Schwehr <schwehr at gmail.com> wrote:
> I have been meaning to write up a new RFC for the switch to C++11 as a
> minimum in January and then the flu caught up with me.
I hope you're feeling better now.
> I will try to do that in the next week or two.
No rush. I just write some new GDAL code and I'd like to write
it the 'new way' and avoid the necessary refactoring.
> In my opinion, RFC 8 could use a lot of things and I only got through 2
> documents that could feed into it last year (if I remember correctly). One
> of which was about getting large buffers off of the stack
> (http://goo.gl/vuA3D6). The other was a start on int bFoo -> bool bFoo
Yes, RFC 8 needs an update, otherwise your overhaul will be going infinitely :-)
> Things that I think should be discussed/added off the top of my head in no
> particular order and only things before C++11.
> - When to use bool/true/false versus int/TRUE/FALSE/-1(MAYBE/UNKNOWN?).
> Expand on https://goo.gl/hdzhXD
> - namespaces
> - IWYU
> - When to use #if DEBUG_VERBOSE. Is it okay to check in commented out code?
> After C++11:
> - Avoid bare .*alloc/new and *free/delete
> - NULL -> nullptr
> - constexpr / static_assert
> - std::initializer_list
The list is big and if we really want to document each item above
and what we discussed previously, I think we would be better off
forking https://github.com/google/styleguide and
updating the C++ Style Guidelines for GDAL.
That way, we don't reinvent the wheel in terms of "How",
we go systematic, we rely on a document structure,
which most C++ programmers are familiar with.
Despite I wouldn't mind adopting Google's document,
I, however, think we should consider a compact version of it,
not necessarily resolving all details,
not necessarily giving lots of comparative examples of bad and good code
but document that allows quick start into writing GDAL code.
Curiously, guidelines for XXI C++ programmer don't have to be ;-)
Mateusz Loskot, http://mateusz.loskot.net
More information about the gdal-dev