AW: GeoDataFeature & GeoDataGeometry: implicit sharing vs. owner pointers?

Torsten Rahn tackat at t-online.de
Fri Oct 7 18:51:56 UTC 2016


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" <kossebau at kde.org>
An: "marble-devel at kde.org" <marble-devel at kde.org>

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



More information about the Marble-devel mailing list