QSharedDataPointer Class

Ausführliche Beschreibung

`QSharedDataPointer` ist eine Template-Klasse, bei der der Template-Parameter ` T ` den Typ der gemeinsam genutzten Datenklasse angibt, die von ` QSharedData` abgeleitet ist.

QSharedDataPointer<T> erleichtert das Schreiben eigener implizit gemeinsam genutzter Klassen. QSharedDataPointer implementiert eine threadsichere Referenzzählung und stellt so sicher, dass das Hinzufügen von QSharedDataPointers zu Ihren reentranten Klassen diese nicht nicht-reentrant macht.

Die implizite Freigabe wird von vielen Qt-Klassen genutzt, um die Geschwindigkeit und Speichereffizienz von Zeigern mit der Benutzerfreundlichkeit von Klassen zu kombinieren. Weitere Informationen finden Sie auf der Seite „Shared Classes “.

Angenommen, Sie möchten eine „ Employee “-Klasse implizit gemeinsam genutzt machen. Die Vorgehensweise ist wie folgt:

• Definieren Sie die Klasse ` Employee ` so, dass sie ein einziges Datenelement vom Typ ` QSharedDataPointer<EmployeeData>` enthält.
• Definieren Sie die Klasse „ EmployeeData “, die von „ QSharedData “ abgeleitet ist, so, dass sie alle Datenelemente enthält, die Sie normalerweise in die Klasse „ Employee “ aufgenommen hätten.

Um dies in der Praxis zu veranschaulichen, sehen wir uns den Quellcode der implizit gemeinsam genutzten Klasse „ Employee “ an. In der Header-Datei definieren wir die beiden Klassen „ Employee “ und „ EmployeeData “.

#include <QSharedData>
#include <QSharedDataPointer>
#include <QString>

class EmployeeData : public QSharedData
{
public:
    EmployeeData() : id(-1) {}
    EmployeeData(const EmployeeData &other)
        : QSharedData(other), id(other.id), name(other.name) {}
    ~EmployeeData() = default;

    int id;
    QString name;
};

class Employee
{
public:
    Employee() { d = new EmployeeData; }
    Employee(int id, const QString &name) {
        d = new EmployeeData;
        setId(id);
        setName(name);
    }
    Employee(const Employee &other) = default;
    Employee &operator=(const Employee &other) = default;

    Employee(Employee &&other) = default;
    Employee &operator=(Employee &&other) = default;

    ~Employee() = default;

    void setId(int id) { d->id = id; }
    void setName(const QString &name) { d->name = name; }

    int id() const { return d->id; }
    QString name() const { return d->name; }

private:
    QSharedDataPointer<EmployeeData> d;
};

Beachten Sie in der Klasse „ Employee “ das einzige Datenelement, einen Zeiger „d“ vom Typ „ QSharedDataPointer<EmployeeData> “. Alle Zugriffe auf Mitarbeiterdaten müssen über den Zeiger „d“ auf „ operator->() “ erfolgen. Bei Schreibzugriffen ruft „ operator->() “ automatisch „ detach()“ auf, wodurch eine Kopie des gemeinsam genutzten Datenobjekts erstellt wird, wenn dessen Referenzzähler größer als 1 ist. Dadurch wird sichergestellt, dass Schreibvorgänge an einem „ Employee “-Objekt keine Auswirkungen auf andere „ Employee “-Objekte haben, die dasselbe „ EmployeeData “-Objekt gemeinsam nutzen.

Die Klasse „ EmployeeData “ erbt von „ QSharedData “, das den Referenzzähler im Hintergrund bereitstellt. „ EmployeeData “ verfügt über einen Standardkonstruktor, einen Kopierkonstruktor und einen Destruktor. Normalerweise sind einfache Implementierungen dieser Konstruktoren alles, was in der Datenklasse für eine implizit gemeinsam genutzte Klasse benötigt wird.

Die Implementierung der beiden Konstruktoren für die Klasse ` Employee ` ist ebenfalls unkompliziert. Beide erstellen eine neue Instanz von ` EmployeeData ` und weisen sie dem Zeiger `d` zu.

Employee() { d = new EmployeeData; }

Employee(int id, const QString &name) {
    d = new EmployeeData;
    setId(id);
    setName(name);
}

Beachten Sie, dass die Klasse ` Employee ` auch einen trivialen Kopierkonstruktor definiert hat, der in diesem Fall streng genommen nicht erforderlich ist.

Employee(const Employee &other) = default;
Employee &operator=(const Employee &other) = default;

Employee(Employee &&other) = default;
Employee &operator=(Employee &&other) = default;

~Employee() = default;

Der Kopierkonstruktor ist hier nicht zwingend erforderlich, da die Klasse „ EmployeeData “ in derselben Datei wie die Klasse „ Employee “ enthalten ist (employee.h). Es ist jedoch nicht üblich, die private Unterklasse von „ QSharedData “ in derselben Datei wie die öffentliche Klasse einzubinden, die den „QSharedDataPointer“ enthält. Normalerweise besteht der Ansatz darin, die private Unterklasse von QSharedData vor dem Benutzer zu verbergen, indem man sie in einer separaten Datei unterbringt, die nicht in die öffentliche Datei eingebunden wird. In diesem Fall würden wir die Klasse EmployeeData normalerweise in eine separate Datei auslagern, die nicht in employee.h eingebunden wird. Stattdessen würden wir die private Unterklasse EmployeeData in employee.h einfach auf folgende Weise vorerklären:

class EmployeeData;

Hätten wir es hier so gemacht, wäre der gezeigte Kopierkonstruktor erforderlich. Da der Kopierkonstruktor trivial ist, kann man ihn genauso gut immer einfügen.

Hinter den Kulissen erhöht QSharedDataPointer automatisch die Referenzanzahl, sobald ein „ Employee “-Objekt kopiert, zugewiesen oder als Parameter übergeben wird. Es verringert die Referenzanzahl, sobald ein „ Employee “-Objekt gelöscht wird oder den Gültigkeitsbereich verlässt. Das gemeinsam genutzte „ EmployeeData “-Objekt wird automatisch gelöscht, sobald die Referenzanzahl 0 erreicht.

In einer nicht-konstanten Memberfunktion von ` Employee` ruft `QSharedDataPointer` automatisch ` detach()` auf, sobald der Zeiger `d` dereferenziert wird, um sicherzustellen, dass die Funktion auf ihrer eigenen Kopie der Daten arbeitet.

void setId(int id) { d->id = id; }

void setName(const QString &name) { d->name = name; }

Beachten Sie, dass, wenn ` detach()` in einer Memberfunktion aufgrund mehrerer Dereferenzierungen des Zeigers `d` mehr als einmal aufgerufen wird, ` detach()` – wenn überhaupt – erst beim ersten Aufruf eine Kopie der gemeinsam genutzten Daten erstellt, da beim zweiten und allen folgenden Aufrufen von ` detach()` der Referenzzähler wieder 1 beträgt.

Beachten Sie jedoch, dass im zweiten Konstruktor von ` Employee `, der eine Mitarbeiter-ID und einen Namen entgegennimmt, sowohl `setId()` als auch `setName()` aufgerufen werden, diese jedoch kein „Copy-on-Write“ auslösen, da die Referenzanzahl für das neu erstellte ` EmployeeData `-Objekt gerade auf 1 gesetzt wurde.

In den const-Mitgliedsfunktionen von Employee führt die Dereferenzierung des Zeigers d nicht dazu, dass detach() aufgerufen wird.

int id() const { return d->id; }

QString name() const { return d->name; }

Beachten Sie, dass für die Klasse ` Employee ` kein Kopierkonstruktor und kein Zuweisungsoperator implementiert werden müssen, da der vom C++-Compiler bereitgestellte Kopierkonstruktor und Zuweisungsoperator die erforderliche flache Kopie von Mitglied zu Mitglied durchführen. Das einzige zu kopierende Mitglied ist der Zeiger `d`, bei dem es sich um einen `QSharedDataPointer` handelt, dessen ` operator=() ` lediglich die Referenzanzahl des gemeinsam genutzten Objekts ` EmployeeData ` erhöht.

Implizites vs. explizites Teilen

Implizites Sharing ist für die Klasse „ Employee “ möglicherweise nicht geeignet. Betrachten wir ein einfaches Beispiel, in dem zwei Instanzen der implizit gemeinsam genutzten Klasse „ Employee “ erstellt werden.

#include "employee.h"

int main()
{
    Employee e1(1001, "Albrecht Durer");
    Employee e2 = e1;
    e1.setName("Hans Holbein");
}

Nachdem der zweite Mitarbeiter „e2“ erstellt und ihm „e1“ zugewiesen wurde, verweisen sowohl „ e1 “ als auch „ e2 “ auf Albrecht Dürer, Mitarbeiter 1001. Beide „ Employee “-Objekte verweisen auf dieselbe Instanz von „ EmployeeData “, deren Referenzzähler den Wert 2 hat. Anschließend wird e1.setName("Hans Holbein") aufgerufen, um den Namen des Mitarbeiters zu ändern. Da die Referenzanzahl jedoch größer als 1 ist, wird vor der Namensänderung ein „Copy-on-Write“ durchgeführt. Nun verweisen e1 und e2 auf unterschiedliche EmployeeData -Objekte. Sie haben unterschiedliche Namen, aber beide die ID 1001, was wahrscheinlich nicht Ihrem Wunsch entspricht. Sie können natürlich einfach mit ` e1.setId(1002)` fortfahren, wenn Sie wirklich einen zweiten, eindeutigen Mitarbeiter anlegen möchten. Wenn Sie jedoch lediglich den Namen des Mitarbeiters überall ändern wollen, sollten Sie in der Klasse ` Employee ` die Verwendung von ` explicit sharing ` anstelle der impliziten gemeinsamen Nutzung in Betracht ziehen.

Wenn Sie den Zeiger `d` in der Klasse ` Employee ` als ` QExplicitlySharedDataPointer<EmployeeData>` deklarieren, wird explizites Sharing verwendet und „Copy-on-Write“-Operationen werden nicht automatisch durchgeführt (d. h., ` detach()` wird in Nicht-const-Funktionen nicht aufgerufen). In diesem Fall hat sich nach dem Aufruf von ` e1.setName("Hans Holbein")` der Name des Mitarbeiters geändert, aber sowohl `e1` als auch `e2` verweisen weiterhin auf dieselbe Instanz von ` EmployeeData`, sodass es nur einen Mitarbeiter mit der ID 1001 gibt.

In der Dokumentation zu Mitgliedsfunktionen verweist der Zeiger `d` immer auf den internen Zeiger auf das gemeinsam genutzte Datenobjekt.

Leistungsoptimierung für die Verwendung in Qt-Containern

Sie sollten in Erwägung ziehen, Ihre implizit gemeinsam genutzte Klasse mithilfe des Makros ` Q_DECLARE_TYPEINFO()` als verschiebbaren Typ zu kennzeichnen, wenn sie der oben genannten Klasse ` Employee ` ähnelt und einen `QSharedDataPointer` oder einen ` QExplicitlySharedDataPointer ` als einziges Mitglied verwendet. Dies kann die Leistung und die Speichereffizienz bei der Verwendung von Qt-Containerklassen verbessern.