The geodata-API should be used to contain easy and complex geographical data. It consists currently of three main types:
GeoDataPlacemark placemark;
GeoDataFeature placemarkAsFeature = placemark;
GeoDataPlacemark other = placemarkAsFeature;
return (placemark == other); // should return true
GeoDataPlacemark placemark;
QList<GeoDataFeature> m_vector;
m_vector.append( placemark );
GeoDataFeature placeMarkAsFeature = m_vector.last();
GeoDataPlacemark other = placemarkAsFeature;
return (placemark == other); // should return true
The GeoDataFeature and GeoDataGeometry classes do use 
implicit-sharing which means that after copying, only a shallow copy is done. Only 
after a write access to the data of the object (calling a non-const function) a 
copy of the whole data is done. This makes copying those data structures rather 
cheap, even if they contain a lot of other GeoDataObjects (as without 
writing there is not much more copying done than with a pointer.
As done already now, there is a private class which contains all the data members 
and gets accessed from the main classes accessor functions. This way you can keep 
binary compatibility over a long time without being restricted to the data members 
you chose in the beginning. When copying a d-pointer'ed class, you must put a 
new private class object on the stack though and copy the values from its origin.
Implicit sharing now means, that in the moment of copying, you only copy the 
address of the private d pointer but you increment the reference counter of that
object. After that there are two objects with the same private class object. If 
somebody tries to change something in one of those two objects, he must call 
a non-const function which in return will call a function called 
void detach(). This function copies the private object and decrements 
the reference counter. If one of the base objects gets deleted, it decrements the 
reference counter too as long as there are more objects connected to this private 
object. If the counter reaches 0 again, the private object gets deleted too.
This is mostly hidden by QSharedData/QSharedDataPointer 
so that you don't have to worry about that.
The problems arise, when you try to derive from an implicitly shared 
class. The detach() function is not virtual in the current implementation of 
QList and thus will not call the function from the derived class if 
changes occur through the interface of the base class. This leads to both GeoDataContainer
and GeoDataMultiGeometry not inheriting QList but rather rebuilding the interface.
As described above, we can't use QSharedData directly if we want 
to use implicit sharing and derivation. Instead we do this on our own.
Our Private classes are all contained in a *_p.h header file. They are derived 
from the private class of the base class (of the current class).
Besides the data members, each private class contains a function void *copy()
 which returns a new copy of the private object. As needed an assignment 
operator may occur. The private classes also do contain a function 
virtual EnumFeatureId featureId() const / virtual EnumGeometryId geometryId() const
but those are mostly a convenience solution to provide a way to check the type 
of your data when it is contained in the base class.
Each of the base classes contains a void* pointer which holds the address of the 
private d pointer. Instead of having one d pointer per derivation step, we only 
have one per object. With a function p() which is contained by each derived class
a pointer casted to the Private class of the class is returned. All of the private 
classes are derived from each other, in the same way as their connected classes.
In the base class (in this case GeoDataFeature and GeoDataGeometry) a function 
void detach() is implemented which calls the void* copy() function of the private class.
This way a copy will always result in the same type as the original, even though 
it might occur in a different wrapper (one of the type classes e.g.).
Above mentioned reference counting is done in the detach function.
The idea of a full serialization of GeoData-API is to use that for saving and
reloading binary representations of GeoData-objects. For this to happen you simply
need to call the pack() or unpack() function for the base
GeoDataDocument providing a QDataStream. As the saved
amount in space, is very small, Marble itself still uses a lossy implementation
for that.