Warum kann ich im Kopierkonstruktor auf private Variablen zugreifen?

Ich habe gelernt, dass ich niemals auf eine private Variable zugreifen kann, nur mit einer get-Funktion in der Klasse. Aber warum kann ich dann im Kopierkonstruktor darauf zugreifen?

Beispiel:

Field::Field(const Field& f)
{
  pFirst = new T[f.capacity()];

  pLast = pFirst + (f.pLast - f.pFirst);
  pEnd  = pFirst + (f.pEnd - f.pFirst);
  std::copy(f.pFirst, f.pLast, pFirst);
}

Meine Erklärung:

private:
  T *pFirst,*pLast,*pEnd;

IMHO, vorhandene Antworten machen einen schlechten Job und erklären das "Warum" davon - konzentrieren sich zu sehr darauf, zu wiederholen, welches Verhalten gültig ist. "Zugriffsmodifikatoren funktionieren auf Klassenebene und nicht auf Objektebene." - Ja aber warum?

Das übergeordnete Konzept hier ist, dass es die Programmierer sind, die eine Klasse entwerfen, schreiben und pflegen, von denen erwartet wird, dass sie die gewünschte OO-Kapselung verstehen und befugt sind, ihre Implementierung zu koordinieren. Wenn Sie also schreiben class X, codieren Sie nicht nur, wie ein einzelnes X xObjekt von Code mit Zugriff darauf verwendet werden kann, sondern auch wie:

• abgeleitete Klassen können damit interagieren (durch optional reine virtuelle Funktionen und / oder geschützten Zugriff) und
• Verschiedene XObjekte arbeiten zusammen , um beabsichtigte Verhaltensweisen bereitzustellen und gleichzeitig die Nachbedingungen und Invarianten Ihres Entwurfs zu berücksichtigen.

Es ist nicht nur der Kopierkonstruktor - eine Vielzahl von Operationen kann zwei oder mehr Instanzen Ihrer Klasse umfassen: Wenn Sie vergleichen, addieren / multiplizieren / dividieren, kopieren, klonen, zuweisen usw., ist dies häufig der Fall Entweder muss es einfach Zugriff auf private und / oder geschützte Daten im anderen Objekt haben oder es soll eine einfachere, schnellere oder allgemein bessere Funktionsimplementierung ermöglichen.

Insbesondere möchten diese Vorgänge möglicherweise den privilegierten Zugriff nutzen, um Folgendes zu tun:

• (Kopierkonstruktoren) verwenden ein privates Mitglied des Objekts "rhs" (rechte Seite) in einer Initialisiererliste, sodass eine Mitgliedsvariable selbst kopierkonstruiert wird, anstatt standardmäßig konstruiert (wenn auch legal) und dann ebenfalls zugewiesen (erneut) falls legal)
• Ressourcen gemeinsam nutzen - Dateihandles, Segmente für gemeinsam genutzten Speicher, shared_ptr s zum Referenzieren von Daten usw.
• Dinge in Besitz nehmen, z auto_ptr<> "verlagert" das Eigentum an dem im Bau befindlichen Objekt
• Kopieren Sie private "Cache" -, Kalibrierungs- oder Statuselemente, die erforderlich sind, um das neue Objekt in einem optimal verwendbaren Zustand zu erstellen, ohne sie von Grund auf neu generieren zu müssen
• Kopier- / Zugriffsdiagnose- / Ablaufverfolgungsinformationen, die in dem zu kopierenden Objekt gespeichert sind und auf die sonst nicht über öffentliche APIs zugegriffen werden kann, die jedoch möglicherweise von einem späteren Ausnahmeobjekt oder einer Protokollierung verwendet werden (z. B. Angaben zu Zeitpunkt / Umständen, zu denen die "ursprüngliche" nicht kopierte Instanz erstellt wurde wurde errichtet)
• Führen Sie eine effizientere Kopie einiger Daten durch: z. B. können Objekte z. B. ein unordered_mapMitglied haben, aber nur öffentlich verfügbar machen begin()und end()iterieren - mit direktem Zugriff auf size()Sie können Sie reserveschneller kopieren. Schlimmer noch, wenn sie nur aussetzen at()und insert()und sonst throw....
• Kopieren Sie Verweise zurück auf übergeordnete / Koordinations- / Verwaltungsobjekte, die für den Clientcode möglicherweise unbekannt oder schreibgeschützt sind

Die Zugriffsmodifikatoren arbeiten auf Klassenebene und nicht auf Objektebene .

Das heißt, zwei Objekte derselben Klasse können auf private Daten des jeweils anderen zugreifen.

Warum:

Vor allem aus Effizienzgründen. Es wäre ein nicht zu vernachlässigender Laufzeitaufwand, bei this == otherjedem Zugriff zu überprüfen, obother.x , ob die Zugriffsmodifikatoren auf Objektebene funktionieren würden.

Es ist auch semantisch logisch, wenn Sie es in Bezug auf den Umfang betrachten: "Wie viel Teil des Codes muss ich beim Ändern einer privaten Variablen berücksichtigen?" - Sie müssen den Code der gesamten Klasse berücksichtigen, und dies ist orthogonal zu den Objekten, die zur Laufzeit vorhanden sind.

^{_{Und es ist unglaublich praktisch, wenn Sie Kopierkonstruktoren und Zuweisungsoperatoren schreiben.}}

Sie können innerhalb der Klasse auf private Mitglieder einer Klasse zugreifen, auch auf solche einer anderen Instanz.

Um die Antwort zu verstehen, möchte ich Sie an einige Konzepte erinnern.

1. Unabhängig davon, wie viele Objekte Sie erstellen, befindet sich für diese Klasse nur eine Kopie einer Funktion im Speicher. Dies bedeutet, dass Funktionen nur einmal erstellt werden. Die Variablen sind jedoch für jede Instanz der Klasse separat.
2. this Der Zeiger wird beim Aufruf an jede Funktion übergeben.

Jetzt ist es wegen der this Zeigers, dass die Funktion in der Lage ist, Variablen dieser bestimmten Instanz zu lokalisieren. egal ob es privat oder öffentlich ist. Innerhalb dieser Funktion kann darauf zugegriffen werden. Wenn wir nun einen Zeiger auf ein anderes Objekt derselben Klasse übergeben. Mit diesem zweiten Zeiger können wir auf private Mitglieder zugreifen.

Hoffe das beantwortet deine Frage.

Der Kopierkonstruktor ist eine Mitgliedsfunktion der Klasse und hat als solche Zugriff auf Datenelemente der Klasse, auch auf solche, die als "privat" deklariert sind.