Even, If a format can have a combination of point, lines, and polygons in a layer, should the layer class set wkbGeometryCollection? And if so, does that imply Z is okay or not okay? I see there is also wkbGeometryCollectionM and wkbGeometryCollectionZM, but no wkbGeometryCollectionZ. And I see wkbGeometryCollection25D is old and shouldn't be used, yes?
poFeatureDefn->SetGeomType(wkbGeometryCollection); Thanks! -kurt On Thu, Feb 16, 2017 at 7:10 AM, Kurt Schwehr <[email protected]> wrote: > Mateusz, > > 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 will try to do > that in the next week or two. And I really appreciate all folks who > commented on that thread. > > 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 ( > https://goo.gl/hdzhXD > > Things that I think should be discussed/added off the top of my head in no > particular order and only things before C++11. And I just overwhelmed > myself. > > - When to use bool/true/false versus int/TRUE/FALSE/-1(MAYBE/UNKNOWN?). > Expand on https://goo.gl/hdzhXD > - namespaces > - IWYU > - Initializing vars and data members. ctor initializer lists > - Don't use goto > - Templates and inlining > - Defining one member per line > - clang-format > - C++ casting > - CPLString versus std::string > - Preferring const var to #define > - Making vars const when possible > - override, explicit, CPL_DISALLOW_COPY_ASSIGN > - Design for testability and what tests to have. e.g. I am working on an > in depth test of jp2kakdataset.cpp. > - static and dynamic analysis. cppcheck, clang static analyzier, compiler > warnings. How and when to tell the tools that they are being dumb > - Examples of good/helpful comments > - What to do about svn keywords and file permissions (e.g. python tests > and shellscripts being executable) > - When to use parens > - Prefer !.empty() and .empty(). When to use CPL_ARRAYSIZE > - Don't convert back to C strings for operations that are available in a > C++ string you already have > - ABS/MIN/MAX -> std::abs/std::min/std::max etc. > - When to use {} in if else (at least be consistent within a block) > - When to use a scope > - char *foo v. char foo[] > - When is it okay to have newlines in CPLDebug and CPLError > - 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 > > > On Thu, Feb 16, 2017 at 1:16 AM, Mateusz Loskot <[email protected]> > wrote: > >> On 15 February 2017 at 17:27, Kurt Schwehr <[email protected]> wrote: >> > >> > Thanks for the pointers. I will do touchups on the driver tutorial as >> I go. >> > [...] >> > What's the cleanest way to setup the driver registration? >> > >> > Should I be deriving from GDALDataset? >> >> Kurt, >> >> BTW, I'd have similar or related question. >> >> Which driver or part of the code is the latest/greatest in >> terms of the new C++ programming guidelines to look up to >> while writing new code for GDAL? >> >> Has there been any agreement on the overall C++ coding guidelines? >> Better, do we need the RFC8 [1] update? >> >> [1] https://trac.osgeo.org/gdal/wiki/rfc8_devguide >> >> Best regards >> -- >> Mateusz Loskot, http://mateusz.loskot.net >> > > > > -- > -- > http://schwehr.org > -- -- http://schwehr.org
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
