In einer Datenstruktur möchte ich einige Objekte, die eindeutig sein identifizierbar sein sollen.

Diese Objekte haben einen Namen, der vom Nutzer festgelegt werden kann.
Um nun das Problem mit Mehrdeutigkeiten zu umgehen, habe ich eine Art ID hinzugefügt, welche im Konstruktor stets erhöht wird. Also jedes neue Objekt hat eine automatisch um 1 erhöhte ID.
Was ich nicht bedacht habe:

Das ganze soll abgespeichert werden können, und die Objekte können voneinander abhängen.

Ums mal ganz einfach zu machen soll eine abgespeicherte Datei in etwa so aussehen:

Objekt(Werte, Name, ID, Verweis auf anderes Objekt [bisher durch ID])

Das ganze soll aber auch wieder geladen werden können. Bei Programmstart ist die erste ID die vergeben wird immer 0. Werden nun zuerst andere Objekte erzeugt und dann eine Liste geladen besteht das Problem dass die Objekte wieder nicht eindeutig sein können.

Beispiel:

Objekt x; // <- erhält ID 0;
LadeListe(list);

list:
Objekt(12, "Hugo", 0, 1), Objekt(21, "Oskar", 1, -1)

Im Konstruktor von Objekt wird bisher ID nur über eine Klassenvariable festgelegt, also
Objekt(ID i) gibt es nicht.

class Objekt
{
public:
    static int IDC;
    int id;
    Objekt(): id(IDC) { IDC ++};
}

in etwa.

Nun möchte ich aber wieder sicher gehen können dass Objekte eindeutig sind, aber auch dass alle Referenzen in bereits gespeicherten Listen richtig aufgelöst werden können.

Meine Ideen:

1. Auf das Hilfskonstrukt ID verzichten und statt dessen einen eindeutigen Namen verlangen und im Notfall zu ladende Objekte umbennen lassen.

2. Da IDC ja nur ein Wert ist könnte ich vor dem Laden einer Liste diese zunächst durchgehen und alle IDs und ID-verweise um IDC erhöhen, dadurch fügt sich die Liste in den bisherigen Verlauf wieder ein und alles bleibt eindeutig.

3. Irgendwas hatte ich noch... vergessen

Nachtrag:
Normalerweise sollte der Fall dass eine Liste geladen wird wenn bereits Objekte existieren kaum vorkommen, aber Ignorieren des Problems ... ist das eine Lösung?

Lars

Eine einfache Lösung für so einen Fall wäre deine Datenhaltungsklasse als friend in deiner Objekt-Klasse zu deklarieren.

Das wäre eine einfache, aber sicher nicht besonders schöne/gute Lösung. Die Kapselung mittels friend zu zerbröseln sollte eigentlich das letzte sein, was man versucht, vor allem für reine Datenhaltung.
Wenn die Klasse dazu gedacht ist, eine Datenhaltung zu ermöglichen, sollte sie eine entsprechende Schnittstelle anbieten und selber darüber entscheiden können, welche Attribute für die Datenhaltung überhaupt benötigt werden. Auf die Schnittstelle kann dann jede geeignete Datenhalterklasse zugreifen, statt dass eine ausgewählte Datenhalterklasse in den Eingeweiden der Klasse frei herumwühlen kann.