[Proj] Use of C++

[Kristian Evers]

Figured I’d chime in on this subject as well. As one of the co-signers of gdalbarn.com<http://gdalbarn.com/>
I am obviously on board with the switch to include the use of C++ in PROJ. And from
the responses so far it seems the community is largely behind the effort as well,
apart from a few skeptics. I agree that the inclusion of C++ in the project is not as
“dangerous" as it might initially sound like. The only real issue that’s been highlighted
so far is complications with compilation on microcontrollers but those claims still haven’t
been backed up by real world examples, so I would say we are good to go on this.

Like Thomas, I am not particularly well-versed in C++ so I am not one to talk about
best practices. For this reason I would ask that some of the C++ experts in the
community come up with a set of coding guidelines for the C++ parts of the code
base. Lately the lack of code formatting conventions in PROJ has been frustrating
to several contributors. With the addition of the new C++ parts of the code we have
the chance to at least include conventions for the C++ code. I know this has been
a topic for GDAL recently and since we have a big overlap with the GDAL community
perhaps we can benefit from their experiences. Kurt and Even, I believe you’ve been
involved in improving the GDAL code formatting rules, would one of you be willing to
suggest something that we can use in PROJ? A good starting point, I guess, would
be https://trac.osgeo.org/gdal/wiki/rfc69_cplusplus_formatting.

I know this is poking the hornets nest and there’s a risk that my request can result in
yet another heated discussion about code style. Please keep the discussion civil
and keep in mind that this is meant as a preemptive strike to avoid future flame
wars.

/Kristian

On 23 May 2018, at 12:25, Even Rouault <even.rouault at spatialys.com<mailto:even.rouault at spatialys.com>> wrote:

Hi,

As announced previously, and given that the SQLite related thread has calmed
down (except license related discussions that aren't directly related to it),
this is the second potentially controversial topic I wanted to discuss.

To be able to handle WKT v1 and WKT v2, relying on the
object modeling of CRS, coordinate transformations and related concepts,
detailed in the ISO 19111:2018 / OGC 18-005r1 "OGC Abstract Specification:
Topic 2: Referencing by coordinates" seems an appropriate start.
See http://www.opengeospatial.org/standards/requests/166 (note: access to the
draft docx requires OGC membership currently)

ISO 19111:2018 will soon replace the current ISO 19111:2007 / OGC 08-015r2 :
http://portal.opengeospatial.org/files/?artifact_id=39049

This updated specification brings new concepts, particularly the
concept of dynamic geodetic reference frames (dynamic datums) that are going
to be fundamental for current (ITRF, WGS84) or future datums (NATRF2022 that
will replace NAD83 in the USA, ATRF in Australia ...)
In the coming months, there will be revision of WKT 2 to catch up with this
evolution of ISO 19111.
Future versions of the EPSG database will also later adapt to this.
ISO 19111 exposes the concepts with UML modelling. We also have GeoAPI
( http://www.opengeospatial.org/standards/geoapi ) that
offers Java (and in progress Python) class hierarchies. In the PROJ context,
it seems natural to opt for C++. Part of that new API will be exposed to C ,
the exact scope remains to be determined depending on the needs. To be clear,
this would not impact the status of existing proj C API, and the already
announced retirement plans of projects.h and proj_api.h.

On a more practical note, this is also the opportunity to reuse existing C++
code from GDAL (WKT tree node building).

I know that this choice of C++ could be perceived as an obstacle for
portability of PROJ, but I don't think this is an actual concern in practice.
Compilers most of us use today (gcc / mingw, clang, Visual Studio, ICC) are
all C++ capable. To build current versions of gcc, you even need a C++98
compatible compiler. For CLang, a C++11 capable one. So platforms that aren't
legacy have all a C++ compiler available. And I believe people that will be
ready to adopt proj 6 are unlikely to do so on legacy systems where no C++
compiler would be available.

Regarding which C++ flavour, I'd like to push for C++11. It brings upon C++98
a number of useful features. A few that come to mind for the work to come
would be the override keyword (to make sure virtual functions are properly
deriving from their base defintions), std::unique_ptr (to simplify memory
management).
C++11 means gcc >= 4.8, clang >= 3.3 and Visual Studio >= 2015.
We switched to C++11 requirement for GDAL for the latest GDAL 2.3.0 version,
and up to now, I haven't heard strong complaints related to that.

As the functional scope of PROJ is extended (historically proj was a
'projection calculator', which was enriched with early-binding datum
transformation capabilities, reworked with all the new PROJ 5 capabilities
paving the road for late-binding capabilities, and, with the planned work,
becoming a kind of 'libcrs'), it seems natural to use the appropriate tools to
implement those enhanced capabilities.

I think allowing C++ could be an opportunity to modernize other parts of the
existing code base: like the implementation of transformations/projections as
C++ objects instead of the current function pointer approach. But that's a bit
beyond my current objectives. Just wanted to mention this as an opportunity.

Thoughts ?

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Proj mailing list
Proj at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20180527/0f19a879/attachment.htm