<html><head></head><body><div>
<div>
<div>I don’t typically work in C++, so I’m not sure how commonplace this is, but I’ve seen a library that used the PImpl pattern to try to provide ABI stability: https://en.cppreference.com/w/cpp/language/pimpl</div>
<div><div style="display: none; border: 0px; width: 0px; height: 0px; overflow: hidden; visibility: hidden;"><img src="https://r.superhuman.com/n36Ay3melmo-emhV9oaqZRK_OF8jhoDUlb5cGIxcv-7Ho-WlqnDEpahjDDmN1ziC0OlbxhAJ_OqNMXVEtMO0VcBhrl2CWj3Qq8gqDqZkSedRAqGQkuKU-4hysgXDfSxfWVjjsARpRNC1pGUk6Dmf4CwelbUm352ElySf9TChSPbw2u_5GBzahV5EEW0Urg.gif" alt=" " width="1" height="0" style="display: none; border: 0px; width: 0px; height: 0px; overflow: hidden; visibility: hidden;"/><!-- --></div>
<br/>
<div class="gmail_signature">
<div style="clear:both">Sent via <a href="https://sprh.mn/?vip=andrew.d.hershberger@gmail.com" target="_blank" class="sh-link">Superhuman iOS</a></div><br/>
</div>
</div>
<div class="gmail_extra">
<br/>
<div class="gmail_quote">
On Tue, Dec 6 2022 at 5:04 PM, Daniel Baston
<<a href="mailto:dbaston@gmail.com" target="_blank">dbaston@gmail.com</a>>
wrote:
<br/>
<blockquote class="gmail_quote" style="margin:0 0 0.8ex; border-left: 1px #ccc solid; padding-left: 1ex;">
<div><div dir="ltr"><div>Hi All,</div><div><br/></div><div>The "Priority 1" item in this list has been completed, and I've been chipping away at items #3 and #5 as well as many bug fixes and opportunistic optimizations. While there is plenty to keep busy with along this track, I want to be responsive to the needs of the broader GEOS community. If you are using GEOS in your application or library, please be a squeaky wheel and create GitHub issues with your requests (or reply to this email.)<br/></div><div><br/></div><div>I'm particularly interested in some feedback on the "defining a C++ API" item, which is now ticketed at <a href="https://github.com/libgeos/geos/issues/755">https://github.com/libgeos/geos/issues/755</a>. Does anyone have an example of a library that has a good system for designating stable methods while allowing continual changes in the internals?</div><div><br/></div><div>Dan<br/></div><div><br/></div></div><br/><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 7, 2022 at 1:09 PM Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca">pramsey@cleverelephant.ca</a>> wrote:<br/></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">All,<br/>
<br/>
Below is the list of priorities for GEOS improvement work that Dan will be attacking under the funding provided from the GDAL project. I think these all meet the general definition of being generally infrastructural and unlikely to be dealt with in the ordinary course of affairs: aka good targets for infra funding. As the project contact for the GDAL funding, I can approve this list, and it looks fine to me, so this is mostly a FYI, with an added layer of "hopefully not missing anything obvious". <br/>
<br/>
ATB,<br/>
P<br/>
<br/>
------<br/>
<br/>
> Howard Butler requested that I provide you with a proposed statement of work describing maintenance to be performed on the GEOS library under a grant from the GDAL project. Specifically, he requested that the proposed work target performance improvements and API enhancements that do not typically attract external funding.<br/>
> <br/>
> The specific changes made to the library will be identified during the course of the work based on code review and community input. However, based on past discussions with the community and experience contributing to the library since 2015, I recommend the areas of focus listed below.<br/>
> <br/>
> Priority 1: Improving storage and access of Coordinates. Like JTS, GEOS requires all coordinates to contain three dimensions and be stored in a container that implements the CoordinateSequence interface. A stated purpose of the CoordinateSequence interface is to allow different underlying representations to be used for coordinate storage, such as an array of XYZ values or parallel arrays of X, Y and Z values. This flexibility comes with a cost of slow Coordinate access through virtual methods. However, other assumptions of GEOS code effectively require the XYZ representation. The result is that GEOS pays a performance penalty without gaining a commensurate amount of implementation flexibility. Converting CoordinateSequence into a concrete class backed by a vector of Coordinates is expected to improve performance throughout the library. Further, many commonly used operations only support two-dimensional coordinates. A CoordinateSequence backed by a vector of doubles, mimicking the P<br/>
ostGIS POINTARRAY type, may also provide improved performance while removing the storage penalty of Z and/or M values where they are not required.<br/>
> <br/>
> Priority 2: Exploring applications of non-exclusive object ownership. Unlike JTS, GEOS generally relies on an exclusive ownership model whereby an object such as a GeometryCollection has exclusive ownership over its component Geometry objects, which in turn have exclusive ownership over their CoordinateSequences. While this provides simple and predictable memory management, it may also result in extra copies of objects being generated so that they can be used by an operation that may need to modify them (e.g., noding) or by an operation that requires a specific input representation (e.g., unary union). Using const shared pointers may provide opportunities to reduce copying in a way that mimics JTS. However, the need to expose raw pointers through the C API may limit the application of this technique.<br/>
> <br/>
> Priority 3: Removing inheritance from portions of the code where it may reduce performance, such as in SegmentString classes. This would need to be done in coordination with JTS and would be contingent on the availability of Martin Davis during the project period. No work is proposed for classes supporting spatial predicates, as it is expected that these will be replaced in a future release of JTS.<br/>
> <br/>
> Priority 4: Reorganization of the C API such that reentrant and non-reentrant versions of a function are in the same translation unit, thereby allowing the compiler to inline trivial functions.<br/>
> <br/>
> Priority 5: Removing remaining usage of raw pointer types in favor of managed pointers that communicate lifecycle and ownership.<br/>
> <br/>
> Priority 6: Defining a C++ API that can feasibly remain stable between releases. It is challenging for projects to incorporate GEOS via C++ because the library does not promise API or ABI stability between versions. It is not possible to maintain complete API and ABI stability while closely following JTS code without using cumbersome patterns such as PIMPL. However, GEOS could improve its usability for C++ clients by clearly defining limited portions of the API for which the project can support a stability contract (e.g., methods of Geometry) and avoiding the export of internal classes that are not intended for external use.<br/>
> <br/>
> As needed, work may also include tasks such as researching and resolving issues reported to GitHub, reviewing pull requests, and supporting projects such as GDAL and shapely in their use of GEOS.<br/>
> <br/>
> Proposed changes to GEOS will be described in GitHub issues and/or GitHub pull requests.<br class="sh-signature"/>
<br class="sh-signature"/>
<br class="sh-signature"/>
_______________________________________________<br class="sh-signature"/>
geos-devel mailing list<br class="sh-signature"/>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank" class="sh-signature">geos-devel@lists.osgeo.org</a><br class="sh-signature"/>
<a href="https://lists.osgeo.org/mailman/listinfo/geos-devel" rel="noreferrer" target="_blank" class="sh-signature">https://lists.osgeo.org/mailman/listinfo/geos-devel</a><br/>
</blockquote></div>
<div><p><br/>
_______________________________________________
<br/>
geos-devel mailing list
<br/>
geos-devel@lists.osgeo.org
<br/>
https://lists.osgeo.org/mailman/listinfo/geos-devel</p></div></div>
</blockquote>
</div>
</div>
</div></div></body></html>