|
|
| (4 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| 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.
| | {{ Moved To Community }} |
| 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: | |
| | |
| === 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.
| |
Latest revision as of 17:44, 25 October 2016
