<div dir="ltr"><div>>
OK let me try to summarize my thoughts in a bullet list fashion</div><div><br></div><div>... misread that as "thoughts in a bullshit fashion" :-)</div><div><br></div><div>Although I will probably never grow up to actually *love* C++,</div><div>I occasionally fall in love with the "the much smaller and cleaner</div><div>language struggling to get out" (as C++ creator Bjarne Stroustrup</div><div>stated it)
.</div><div><br></div><div>I do, however, *love* the thought of seeing libproj supporting</div><div>WKT2, ISO19111 and friends. And if embracing C++ is the way</div><div>you can implement that fastest and most efficiently, I believe that</div><div>is what should be done.</div><div><br></div><div>I have spent 2 years of my life working towards a libproj more</div><div>suitable for handling general geodetic transformations, while</div><div>staying within the bounds set by C89. This really makes me want</div><div>to see a less restrictive environment for your important next step.</div><div><br></div><div>Also, I would love to see a more clearly defined delineation of</div><div>where PROJ stops and GDAL takes over. Obviously, this will</div><div>only happen by applying an overall architectural restructuring,</div><div>involving both C and C++ code, from both PROJ and GDAL.<br></div><div><br></div><div>I believe, as accuracy expectations grow, PROJ will have to</div><div>evolve into not only a libcrs, but into a lib-general-geodesy,</div><div>to stay relevant. Doing that without introducing sharper tools</div><div>will result in an unmaintainable mess.</div><div><br></div><div>So enough of my "thoughts in bullshit fashion" - just let me</div><div>summarize by saying that I believe that introducing C++</div><div>elements in libproj will be necessary to achieve the goals</div><div>set forward in the gdal barn raising, and hence not really a</div><div>decision to consider, but just an inevitable bullet to bite</div><div>(or candy to enjoy, for those so inclined).</div><div><br></div><div><br></div><div><br></div>
</div><div class="gmail_extra"><br><div class="gmail_quote">2018-05-23 14:05 GMT+02:00 Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On mercredi 23 mai 2018 13:50:53 CEST Jürgen E. Fischer wrote:<br>
> Hi Even,<br>
> <br>
> On Wed, 23. May 2018 at 12:25:12 +0200, Even Rouault wrote:<br>
> > I know that this choice of C++ could be perceived as an obstacle for<br>
> > portability of PROJ, but I don't think this is an actual concern in<br>
> > practice.<br>
<br>
> Internally, but with a (alternative?) C-API to the outside? <br>
> Or also C++ as<br>
> the (only) external interface?<br>
<br>
</span>OK let me try to summarize my thoughts in a bullet list fashion :-)<br>
- C++ as mostly for internal use for new code to be added, related to CRS <br>
modelling and WKT managment<br>
- Part of that C++ code as possibly externally accessible<br>
- Part of that C++ externally accessible API might also be exposed through new <br>
C API<br>
- existing proj C API still available through the plans exposed in the past.<br>
<br>
The first 3 bullets are quite similar to how GDAL handles things.<br>
<div class="HOEnZb"><div class="h5"><br>
Even<br>
<br>
-- <br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
______________________________<wbr>_________________<br>
Proj mailing list<br>
<a href="mailto:Proj@lists.maptools.org">Proj@lists.maptools.org</a><br>
<a href="http://lists.maptools.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">http://lists.maptools.org/<wbr>mailman/listinfo/proj</a><br>
</div></div></blockquote></div><br></div>