<div dir="ltr">Søren,<div><br></div><div>Bas already referred you to another relevant thread from 2018. But for completeness,</div><div>please let me quote my own concluding remark from that thread, which I in the meantime</div><div>have had no reason to regret:</div><div><br></div><div><pre style="white-space:pre-wrap;color:rgb(0,0,0)">Even><i style="font-family:Arial,Helvetica,sans-serif"> OK let me try to summarize my thoughts in a bullet list fashion</i></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">Thomas:</pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">... 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).
</pre></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den tor. 7. maj 2020 kl. 18.31 skrev Søren Holm <<a href="mailto:sgh@sgh.dk">sgh@sgh.dk</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thank you for the answers Martin and Howard.<br>
<br>
I realy like that the precision of proj has increase comparing to earlier proj <br>
versions. Also the readyness for future evolution is great. I did not question <br>
any of that.<br>
<br>
I do however not understand why the precision and future evolution readiness - <br>
which are features in inself - is brough into a purely language oriented <br>
question. I'm quite sure that using C or C++ without the stuff that makes it <br>
slow can be just as precise as anything else. <br>
<br>
I clearly I do not compile PROJ all the time, but that kind of standpoint <br>
leads to ever increasing compiletimes for developers and users.<br>
<br>
Lastly I just want to say that I did not write these email to start a <br>
discussion. It was a mere combination of:<br>
<br>
"Hey, thing thing is takes 10 times longer to compile, Why is that?" <br>
<br>
      and <br>
<br>
"If my software projects compile time increased 10 fold I would see it as a <br>
bug."<br>
<br>
<br>
<br>
-- <br>
Søren Holm<br>
<br>
<br>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div>