Projects/Marble/GeoData/PointerVsImplicitShare - Revision history

Bholst at 15:09, 31 March 2010

2010-03-31T15:09:47Z

Bholst at 14:26, 31 March 2010

2010-03-31T14:26:44Z

Bholst at 14:12, 31 March 2010

2010-03-31T14:12:54Z

Bholst at 13:29, 31 March 2010

2010-03-31T13:29:44Z

Bholst: Started this page ... first thoughts, multiple possibilities

2010-03-31T13:04:59Z

Started this page ... first thoughts, multiple possibilities

New page

Implicit sharing and storing objects as value is very reasonable for basic data as QStrings, but there are reasonable doubts regarding Placemarks and other GeoData.
There are some possibilities:
* Don't use implicit sharing at all and store all objects on the heap with a pointer to it.
* Use implicit sharing and storing as value for GeoDataCoordinates only.
* Use implicit sharing and storing as value for all GeoData classes.

To find out which is the wisest I try to look at every single class:

@@ Line 7: / Line 7: @@
 To find out which is the wisest I try to look at every single class:
 (please add your thoughts here)
 === Base data ===
@@ Line 49: / Line 46: @@
 ** '''GeoDataStyle'''
 ** '''GeoDataStyleMap''' (QMap<QString, QString>)
 It is possible to group these things in two groups:

← Older revision		Revision as of 14:26, 31 March 2010
Line 59:		Line 59:

	A compromise could be to use the classes of the first group with a pointer and all others as a value.		A compromise could be to use the classes of the first group with a pointer and all others as a value.
		+	In KML all items are children of GeoDataObject (except GeoDataCoordinates). See [http://code.google.com/intl/de-DE/apis/kml/documentation/kmlreference.html#object here].

@@ Line 6: / Line 6: @@
 To find out which is the wisest I try to look at every single class:
 === Base data ===
@@ Line 11: / Line 15: @@
 * '''GeoDataLatLonBox''' (GeoDataObject) It seems to nothing more than a QRect for GeoCoordinates. I'm not sure if it must be derived from GeoDataObject
 ** '''GeoDataLatLonAltBox''' same for this
 === Geometric structures ===
 * '''GeoDataGeometry''' The base class for all geometric. We could want a pointer for this, so using it as data may not be the right way.
 ** '''GeoDataPoint''' This one uses multiple inheritance (GeoDataCoordinates). I don't think that this is semantically correct.
 === views ===
 * '''GeoDataAbstractView''' It's nothing more than a view, this could stay implicitly shared.
 ** '''GeoDataLookAt''' Same for this as this is a child.

← Older revision		Revision as of 13:29, 31 March 2010
Line 6:		Line 6:

	To find out which is the wisest I try to look at every single class:		To find out which is the wisest I try to look at every single class:
		+
		+	=== Base data ===
		+	* '''GeoDataCoordinates''' This one is quite simple. It is not more than a QPoint in GeoCoordinates. This should stay implicilty shared.
		+	* '''GeoDataLatLonBox''' (GeoDataObject) It seems to nothing more than a QRect for GeoCoordinates. I'm not sure if it must be derived from GeoDataObject
		+	** '''GeoDataLatLonAltBox''' same for this
		+
		+	=== Geometric structures ===
		+	* '''GeoDataGeometry''' The base class for all geometric. We could want a pointer for this, so using it as data may not be the right way.
		+	** '''GeoDataPoint''' This one uses multiple inheritance (GeoDataCoordinates). I don't think that this is semantically correct.
		+
		+	=== views ===
		+	* '''GeoDataAbstractView''' It's nothing more than a view, this could stay implicitly shared.
		+	** '''GeoDataLookAt''' Same for this as this is a child.