[PROJ] The state of PROJ C++ 2020

Thomas Knudsen knudsen.thomas at gmail.com
Thu May 7 12:29:38 PDT 2020


Søren,

Bas already referred you to another relevant thread from 2018. But for
completeness,
please let me quote my own concluding remark from that thread, which I in
the meantime
have had no reason to regret:

Even>* OK let me try to summarize my thoughts in a bullet list fashion*

Thomas:

... 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).


Den tor. 7. maj 2020 kl. 18.31 skrev Søren Holm <sgh at sgh.dk>:

> Thank you for the answers Martin and Howard.
>
> I realy like that the precision of proj has increase comparing to earlier
> proj
> versions. Also the readyness for future evolution is great. I did not
> question
> any of that.
>
> I do however not understand why the precision and future evolution
> readiness -
> which are features in inself - is brough into a purely language oriented
> question. I'm quite sure that using C or C++ without the stuff that makes
> it
> slow can be just as precise as anything else.
>
> I clearly I do not compile PROJ all the time, but that kind of standpoint
> leads to ever increasing compiletimes for developers and users.
>
> Lastly I just want to say that I did not write these email to start a
> discussion. It was a mere combination of:
>
> "Hey, thing thing is takes 10 times longer to compile, Why is that?"
>
>       and
>
> "If my software projects compile time increased 10 fold I would see it as
> a
> bug."
>
>
>
> --
> Søren Holm
>
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20200507/94cf3996/attachment.html>


More information about the PROJ mailing list