[Proj] Use of C++
knudsen.thomas at gmail.com
Wed May 23 12:11:00 EST 2018
> OK let me try to summarize my thoughts in a bullet list fashion
... misread that as "thoughts in a bullshit fashion" :-)
Although I will probably never grow up to actually *love* C++,
I occasionally fall in love with the "the much smaller and cleaner
language struggling to get out" (as C++ creator Bjarne Stroustrup
stated it) .
I do, however, *love* the thought of seeing libproj supporting
WKT2, ISO19111 and friends. And if embracing C++ is the way
you can implement that fastest and most efficiently, I believe that
is what should be done.
I have spent 2 years of my life working towards a libproj more
suitable for handling general geodetic transformations, while
staying within the bounds set by C89. This really makes me want
to see a less restrictive environment for your important next step.
Also, I would love to see a more clearly defined delineation of
where PROJ stops and GDAL takes over. Obviously, this will
only happen by applying an overall architectural restructuring,
involving both C and C++ code, from both PROJ and GDAL.
I believe, as accuracy expectations grow, PROJ will have to
evolve into not only a libcrs, but into a lib-general-geodesy,
to stay relevant. Doing that without introducing sharper tools
will result in an unmaintainable mess.
So enough of my "thoughts in bullshit fashion" - just let me
summarize by saying that I believe that introducing C++
elements in libproj will be necessary to achieve the goals
set forward in the gdal barn raising, and hence not really a
decision to consider, but just an inevitable bullet to bite
(or candy to enjoy, for those so inclined).
2018-05-23 14:05 GMT+02:00 Even Rouault <even.rouault at spatialys.com>:
> On mercredi 23 mai 2018 13:50:53 CEST Jürgen E. Fischer wrote:
> > Hi Even,
> > On Wed, 23. May 2018 at 12:25:12 +0200, Even Rouault wrote:
> > > 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.
> > Internally, but with a (alternative?) C-API to the outside?
> > Or also C++ as
> > the (only) external interface?
> OK let me try to summarize my thoughts in a bullet list fashion :-)
> - C++ as mostly for internal use for new code to be added, related to CRS
> modelling and WKT managment
> - Part of that C++ code as possibly externally accessible
> - Part of that C++ externally accessible API might also be exposed through
> C API
> - existing proj C API still available through the plans exposed in the
> The first 3 bullets are quite similar to how GDAL handles things.
> Spatialys - Geospatial professional services
> Proj mailing list
> Proj at lists.maptools.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Proj