[Proj] C++ coding practices w.r.t object ownership

Even Rouault even.rouault at spatialys.com
Tue May 29 03:10:30 PDT 2018


> I think that the "CI_", "EX_" and "MD_" prefixes can be omitted. They
> duplicate namespaces/packages in C++/Java and recent ISO/TC211 policy
> (in my understanding) is to drop them in newer standards. For example
> "Datum" in ISO 19111:2018 was "CD_Datum" in ISO 19111:2007.

Yes, sounds reasonable

> 
> PositionalAccuracy (currently in "common" namespace) belong to
> "metadata" namespace too.

OK

> 
> Regarding the object ownership discussion, one more criterion that may
> be worth to consider is whether the proposed alternatives support cyclic
> references. For example ProjectedCRS.conversion references a Conversion
> object, which could in turn reference back the ProjectedCRS in its
> Conversion.targetCRS attribute. ISO 19111 allows to break this
> circularity by allowing Conversion.source/targetCRS to be null in such
> cases. But I find convenient to nevertheless provide the reference value
> when the language/framework support cyclic references since it makes
> easier to use a Conversion instance without carrying extra information
> about its context.

Yes, that's an annoying point I noticed yesterday when looking more closely at 
this, since cyclic references are unfriendly with shared pointers.

The solution is that CoordinateOperation stores sourceCRS and targetCRS as 
std::weak_ptr internally. In the sourceCRS() and targetCRS() getters, those 
weak pointers are converted to shared pointers with .lock() (the 
shared_pointer being then potentially null if the owning ProjectedCRS has been 
destroyed in between). So users of the API only see shared pointers. And add  
a documentation note of sourceCRS() and targetCRS() about the particular case 
of ProjectedCRS.derivingConversion.

Bonus point: when the CoordinateOperation is created in all other contexts 
than the derivingConversion of a ProjectedCRS, then CoordinateOperation can 
also have internal shared_ptr so as to make sure than the source and target 
CRS are kept alive, and the weak_ptr conversion to a shared_one always return 
a non null pointer.

Attached a POC (simplified but representative of the above situation) that 
works pretty well: no memory leak, and safe pointer usage.


> Circularity may also happen in ISO 19115 metadata,
> e.g. between Platform and Instrument classes.

OK. I don't think I'll need those ones. Enough classes for now !

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testweak.cpp
Type: text/x-c++src
Size: 2387 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20180529/816dafd2/attachment.cpp>


More information about the Proj mailing list