[Proj] Use of C++

[Thomas Knudsen]

> 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
> new
> C API
> - existing proj C API still available through the plans exposed in the
> past.
>
> The first 3 bullets are quite similar to how GDAL handles things.
>
> 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.osgeo.org/pipermail/proj/attachments/20180523/d97f4df5/attachment.html>