Hi Friedrich, Good question. When we started to use "building bricks" from the KML design inside Marble the idea was to be able to pass on snippets of information in an easy efficient manner. Implicit sharing looked like a good efficient "all-purpose" solution at that point. The idea was that one would be able to pass on coordinates, linestrings, linear rings, polygons and styles in a manner that doesn't force us to think about ownership and in a manner that would allow us to copy them in a memory efficient way. So at that point we introduced the concept of implicit sharing whereever possible.
However as soon as we started to put those building bricks into a hierarchy in order to use them in an object tree we started to realize that the concept of having a parent-child relationship in parallel to implicit sharing would clash and not even work in some cases. It took a bit of trial and error in order to realize in which cases each of the technologies would fit best: GeoDataCoordinates are clearly a value class where implicit sharing makes sense. For elements like Folders and Placemarks which are an integral part of the object tree and not so much value classes the concept of implicit sharing doesn't fit. This leaves some classes like linestrings, linear rings and polygons which could be conveniently seen as value classes in the spirit of QPolygon. Then again in KML they are supposed to have a parent so that would make the concept of implicit sharing impractical for the main use cases. So at one point we've basically allowed for both cases: being able to use them on the Stack and pass them as a value without having to worry about ownership AND in other cases pass them by pointer with a parent as entries in an object tree where they are owned by the parent. This still turned out to be a bit of a burden that would not work well. So you might be right that these days we don't make use of implicit sharing in the geometry classes at all anymore. A similar case might be the styles. So it might be indeed useful to remove the implicit sharing in cases where it's practically redundant - and just leave implicit sharing in place for the actual value classes (like GeoDataCoordinates). Dennis: any thoughts on this? Torsten -----Original-Nachricht----- Betreff: GeoDataFeature & GeoDataGeometry: implicit sharing vs. owner pointers? Datum: 2016-10-07T19:20:22+0200 Von: "Friedrich W. H. Kossebau" <[email protected]> An: "[email protected]" <[email protected]> Hi, GeoDataFeature & GeoDataGeometry and their subclasses are implemented to do "implicit sharing" between object copies. src/lib/marble/geodata/data/ README.html reasons: "Each derived class can be stored in its base class and can later be transformed back again. [...] This feature is useful so that you can easily store classes which inherit GeoDataFeature in a QVector<GeoDataFeature> [...]" At the same time though the data objects belonging to those two classes and their subclasses get a pointer set to their "parent" object. Which poses a challenge: for objects implicitely shared, what is the parent object? E.g. think of lifetime of the parents: Foo b; { Foo a; a.addObjectAndMarkSelfAsParent(o); b = a; } // a goes out of scope Grepping through the code it seems though that GeoDataFeature & GeoDataGeometry almost everywhere are handled by pointer, not by value. And the current code in many places after a detach does not go over all owned objects and properly updates the parent. So I wonder if the application of implicit sharing for the cited motivation never worked out due to the given challenge and all code simply escaped into using pointers, but no-one ever got around to also dump that implicit sharing code? Does it make sense to start to try to remove that implicit sharing code? What have I missed possibly? Cheers Friedrich
