[Proj] Use of C++

[Andrew Bell]

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?

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.

On Wed, May 23, 2018 at 1:11 PM, Thomas Knudsen <knudsen.thomas at gmail.com>
wrote:

> > 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
>>
>
>
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>



-- 
Andrew Bell
andrew.bell.ia at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20180523/e86da4c6/attachment.htm