<div dir="ltr"><div><br></div>If C++ isn't used at the API, isn't this an implementation detail as long as it builds on systems you want to target?<div><br></div><div>That said, the issue I have with the GDAL API, which is mentioned as a model, is that it's complicated in that it's always unclear who owns what and what needs to be freed by the application, etc. It creates bugs and ambiguities. Whether the API is C or C++, allowing the library to manage data to the extent possible is desirable. Looking at the proj 4 API, there are only a few instances where you might need to look at the source code or documentation on this (proj_list..., a few calls that take non-const char * and a few that take char **), so not a bad starting point. If C++ allows a cleaner interface, I'd be a happy user, but if the same effect can be achieved with C, that's fine as well. If a binary-compatible C++ interface is important, hiding the implementation behind a pointer is standard practice and works pretty well.<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 23, 2018 at 1:11 PM, Thomas Knudsen <span dir="ltr"><<a href="mailto:knudsen.thomas@gmail.com" target="_blank">knudsen.thomas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>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="m_3147234337048267226m_3079958126507786562HOEnZb"><div class="m_3147234337048267226m_3079958126507786562h5"><br>
Even<span class="m_3147234337048267226HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a></font></span><span><br>
______________________________<wbr>_________________<br>
Proj mailing list<br>
<a href="mailto:Proj@lists.maptools.org" target="_blank">Proj@lists.maptools.org</a><br>
<a href="http://lists.maptools.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">http://lists.maptools.org/mail<wbr>man/listinfo/proj</a><br>
</span></div></div></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
Proj mailing list<br>
<a href="mailto:Proj@lists.maptools.org" target="_blank">Proj@lists.maptools.org</a><br>
<a href="http://lists.maptools.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">http://lists.maptools.org/mail<wbr>man/listinfo/proj</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_3147234337048267226gmail_signature" data-smartmail="gmail_signature">Andrew Bell<br><a href="mailto:andrew.bell.ia@gmail.com" target="_blank">andrew.bell.ia@gmail.com</a></div>
</div></div></div>