QRangeModel Class

Detaillierte Beschreibung

QRangeModel kann die Daten in jedem sequentiell iterierbaren C++-Typ für das Model/View-Framework von Qt verfügbar machen. Dies erleichtert die Anzeige vorhandener Datenstrukturen in den Elementansichten Qt Widgets und Qt Quick und ermöglicht es dem Benutzer der Anwendung, die Daten über eine grafische Benutzeroberfläche zu manipulieren.

Um QRangeModel zu verwenden, instanziieren Sie es mit einem C++-Bereich und legen es als Modell für eine oder mehrere Ansichten fest:

std::array<int, 5> numbers = {1, 2, 3, 4, 5};
QRangeModel model(numbers);
listView.setModel(&model);

Konstruieren des Modells

Der Bereich kann ein beliebiger C++-Typ sein, für den die Standardmethoden std::begin und std::end implementiert sind und für den der zurückgegebene Iteratortyp std::forward_iterator erfüllt. Bestimmte Modelloperationen funktionieren besser, wenn std::size verfügbar ist und wenn der Iterator std::random_access_iterator entspricht.

Der Bereich muss beim Erstellen des Modells angegeben werden; es gibt keine API, um den Bereich später festzulegen, und es gibt keine API, um den Bereich aus dem Modell abzurufen. Der Bereich kann als Wert, Referenz-Wrapper oder Zeiger angegeben werden. Wie das Modell konstruiert wurde, bestimmt, ob Änderungen durch die Modell-API die ursprünglichen Daten verändern.

Wenn es nach Wert konstruiert wurde, erstellt das Modell eine Kopie des Bereichs, und QAbstractItemModel APIs, die das Modell ändern, wie setData() oder insertRows(), haben keine Auswirkungen auf den ursprünglichen Bereich.

QRangeModel model(numbers);

Da es keine API gibt, um den Bereich erneut abzurufen, ist die Konstruktion des Modells aus einem Bereich nach Wert meist nur für die Anzeige schreibgeschützter Daten nützlich. Änderungen an den Daten können mit Hilfe der vom Modell ausgegebenen Signale überwacht werden, z. B. dataChanged().

Damit sich Änderungen am Modell auf den ursprünglichen Bereich auswirken, geben Sie den Bereich entweder durch einen Zeiger:

QRangeModel model(&numbers);

oder durch einen Referenz-Wrapper:

QRangeModel model(std::ref(numbers));

In diesem Fall ändern die APIs von QAbstractItemModel, die das Modell ändern, auch den Bereich. Methoden, die die Struktur des Bereichs ändern, wie insertRows() oder removeColumns(), verwenden die Standard-C++-Container-APIs resize(), insert(), erase(), zusätzlich zur Dereferenzierung eines mutierenden Iterators zum Setzen oder Löschen der Daten.

Der Aufrufer muss sicherstellen, dass die Lebensdauer des Bereichs die Lebensdauer des Modells überschreitet.

Verwenden Sie intelligente Zeiger, um sicherzustellen, dass der Bereich nur gelöscht wird, wenn alle Clients damit fertig sind.

auto shared_numbers = std::make_shared<std::vector<int>>(numbers);
QRangeModel model(shared_numbers);

QRangeModel unterstützt sowohl gemeinsame als auch eindeutige Zeiger.

Schreibgeschützt oder veränderbar

Für Bereiche, bei denen es sich um konstante Objekte handelt, bei denen der Zugriff immer konstante Werte ergibt, oder bei denen die erforderlichen Container-APIs nicht verfügbar sind, implementiert QRangeModel Schreibzugriffs-APIs, die nichts tun und false zurückgeben. In dem Beispiel, das std::array verwendet, kann das Modell keine Zeilen hinzufügen oder entfernen, da die Anzahl der Einträge in einem C++-Array fest ist. Aber die Werte können mit setData() geändert werden, und der Benutzer kann die Bearbeitung der Werte in der Listenansicht auslösen. Dadurch, dass das Array const ist, werden die Werte auch schreibgeschützt.

const std::array<int, 5> numbers = {1, 2, 3, 4, 5};

Die Werte sind auch schreibgeschützt, wenn der Elementtyp const ist, wie in

std::array<const int, 5> numbers = {1, 2, 3, 4, 5};

In den obigen Beispielen mit std::vector kann das Modell Zeilen hinzufügen oder entfernen, und die Daten können geändert werden. Wird der Bereich als konstanter Verweis übergeben, wird das Modell schreibgeschützt.

QRangeModel model(std::cref(numbers));

Zeilen und Spalten

Die Elemente im Bereich werden als Zeilen des Modells interpretiert. Je nach dem Typ dieser Zeilenelemente stellt QRangeModel den Bereich als Liste, Tabelle oder Baum dar.

Wenn die Zeilenelemente einfache Werte sind, wird der Bereich als Liste dargestellt.

QList<int> numbers = {1, 2, 3, 4, 5};
QRangeModel model(numbers); // columnCount() == 1
QListView listView;
listView.setModel(&model);

Wenn der Typ der Zeilenelemente ein iterierbarer Bereich ist, z. B. ein Vektor, eine Liste oder ein Array, dann wird der Bereich als Tabelle dargestellt.

std::vector<std::vector<int>> gridOfNumbers = {
    {1, 2, 3, 4, 5},
    {6, 7, 8, 9, 10},
    {11, 12, 13, 14, 15},
};
QRangeModel model(&gridOfNumbers); // columnCount() == 5
QTableView tableView;
tableView.setModel(&model);

Wenn der Zeilentyp die Standard-C++-Container-APIs resize(), insert(), erase() bereitstellt, können Spalten über insertColumns() und removeColumns() hinzugefügt und entfernt werden. Alle Zeilen müssen die gleiche Anzahl von Spalten haben.

Strukturen und Gadgets als Zeilen

Wenn der Zeilentyp the C++ tuple protocol implementiert, dann wird der Bereich als Tabelle mit einer festen Anzahl von Spalten dargestellt.

using TableRow = std::tuple<int, QString>;
QList<TableRow> numberNames = {
    {1, "one"},
    {2, "two"},
    {3, "three"}
};
QRangeModel model(&numberNames); // columnCount() == 2
QTableView tableView;
tableView.setModel(&model);

Eine einfachere und flexiblere Alternative zur Implementierung des Tupel-Protokolls für einen C++-Typ ist die Verwendung des Meta-Objektsystems von Qt, um einen Typ mit Eigenschaften zu deklarieren. Dies kann ein Wertetyp sein, der als gadget deklariert ist, oder eine QObject Unterklasse.

class Book
{
    Q_GADGET
    Q_PROPERTY(QString title READ title)
    Q_PROPERTY(QString author READ author)
    Q_PROPERTY(QString summary MEMBER m_summary)
    Q_PROPERTY(int rating READ rating WRITE setRating)
public:
    Book(const QString &title, const QString &author);

    // C++ rule of 0: destructor, as well as copy/move operations
    // provided by the compiler.

    // read-only properties
    QString title() const { return m_title; }
    QString author() const { return m_author; }

    // read/writable property with input validation
    int rating() const { return m_rating; }
    void setRating(int rating)
    {
        m_rating = qBound(0, rating, 5);
    }

private:
    QString m_title;
    QString m_author;
    QString m_summary;
    int m_rating = 0;
};

Die Verwendung von QObject Unterklassen ermöglicht es, Eigenschaften zu binden oder Änderungsbenachrichtigungen zu senden. Die Verwendung von QObject Instanzen für Elemente hat jedoch einen erheblichen Speicher-Overhead.

Die Verwendung von Qt Gadgets oder Objekten ist bequemer und kann flexibler sein als die Implementierung des Tupel-Protokolls. Diese Typen sind auch direkt von QML aus zugänglich. Allerdings ist der Zugriff über das Eigenschaftssystem mit einem gewissen Laufzeit-Overhead verbunden. Für leistungskritische Modelle sollten Sie die Implementierung des Tupel-Protokolls in Betracht ziehen, um den Zugriffscode zur Kompilierzeit zu generieren.

Elemente mit mehreren Rollen

Der Typ der Elemente, auf die die Implementierungen von data(), setData(), clearItemData() usw. zugreifen, kann für das gesamte Modell gleich sein - wie im obigen Beispiel gridOfNumbers. Der Bereich kann aber auch unterschiedliche Elementtypen für verschiedene Spalten haben, wie im Fall numberNames.

Standardmäßig wird der Wert für die Rollen Qt::DisplayRole und Qt::EditRole verwendet. Die meisten Ansichten erwarten, dass der Wert convertible to and from a QString ist (aber ein benutzerdefinierter Delegat könnte mehr Flexibilität bieten).

Assoziative Container mit mehreren Rollen

Wenn das Element ein assoziativer Container ist, der int, Qt::ItemDataRole oder QString als Schlüsseltyp und QVariant als zugeordneten Typ verwendet, dann interpretiert QRangeModel diesen Container als die Speicherung der Daten für mehrere Rollen. Die Funktionen data() und setData() geben den zugeordneten Wert im Container zurück und ändern ihn, während setItemData() alle bereitgestellten Werte ändert, itemData() alle gespeicherten Werte zurückgibt und clearItemData() den gesamten Container löscht.

using ColorEntry = QMap<Qt::ItemDataRole, QVariant>;

const QStringList colorNames = QColor::colorNames();
QList<ColorEntry> colors;
colors.reserve(colorNames.size());
for (const QString &name : colorNames) {
    const QColor color = QColor::fromString(name);
    colors << ColorEntry{{Qt::DisplayRole, name},
                        {Qt::DecorationRole, color},
                        {Qt::ToolTipRole, color.name()}};
}
QRangeModel colorModel(colors);
QListView list;
list.setModel(&colorModel);

Der effizienteste Datentyp, der als Schlüssel verwendet werden kann, ist Qt::ItemDataRole oder int. Bei Verwendung von int gibt itemData() den Container so zurück, wie er ist, und muss keine Kopie der Daten erstellen.

Gadgets und Objekte als Multi-Rollen-Elemente

Gadgets und QObject Typen können auch als Multi-Role-Elemente dargestellt werden. Die Eigenschaften dieser Elemente werden für die Rolle verwendet, zu der name of a role passt. Wenn alle Elemente denselben Typ von Gadget oder QObject enthalten, gibt die Implementierung roleNames() in QRangeModel die Liste der Eigenschaften dieses Typs zurück.

class ColorEntry
{
    Q_GADGET
    Q_PROPERTY(QString display MEMBER m_colorName)
    Q_PROPERTY(QColor decoration READ decoration)
    Q_PROPERTY(QString toolTip READ toolTip)
public:
    ColorEntry(const QString &color = {})
        : m_colorName(color)
    {}

    QColor decoration() const
    {
        return QColor::fromString(m_colorName);
    }
    QString toolTip() const
    {
        return QColor::fromString(m_colorName).name();
    }

private:
    QString m_colorName;
};

Bei Verwendung in einer Tabelle ist dies die Standarddarstellung für Gadgets:

QList<QList<ColorEntry>> colorTable;

// ...

QRangeModel colorModel(colorTable);
QTableView table;
table.setModel(&colorModel);

Wenn sie in einer Liste verwendet werden, werden diese Typen jedoch standardmäßig als mehrspaltige Zeilen dargestellt, wobei jede Eigenschaft als separate Spalte dargestellt wird. Um zu erzwingen, dass ein Gadget als mehrspaltiges Element in einer Liste dargestellt wird, deklarieren Sie das Gadget als mehrspaltigen Typ, indem Sie QRoleModel::RowOptions spezialisieren, wobei eine static constexpr auto rowCategory Member-Variable auf MultiRoleItem gesetzt wird.

class ColorEntry
{
    Q_GADGET
    Q_PROPERTY(QString display MEMBER m_colorName)
    Q_PROPERTY(QColor decoration READ decoration)
    Q_PROPERTY(QString toolTip READ toolTip)
public:
    ...
};
template <>
struct QRangeModel::RowOptions<ColorEntry>
{
    static constexpr auto rowCategory = QRangeModel::RowCategory::MultiRoleItem;
};

Sie können solche Typen auch in ein Einzelelement-Tupel verpacken, wodurch die Liste zu einer Tabelle mit einer einzigen Spalte wird:

const QStringList colorNames = QColor::colorNames();
QList<std::tuple<ColorEntry>> colors;

// ...

QRangeModel colorModel(colors);
QListView list;
list.setModel(&colorModel);

In diesem Fall ist zu beachten, dass der direkte Zugriff auf die Elemente in den Listendaten über std::get erfolgen muss:

ColorEntry firstEntry = std::get<0>(colors.at(0));

oder alternativ eine strukturierte Bindung:

auto [firstEntry] = colors.at(0);

Zeilen als Werte oder Zeiger

In den bisherigen Beispielen haben wir QRangeModel immer mit Bereichen verwendet, die Werte enthalten. QRangeModel kann auch mit Bereichen arbeiten, die Zeiger enthalten, einschließlich intelligenter Zeiger. Dadurch kann QRangeModel mit Bereichen von polymorphen Typen arbeiten, z. B. mit QObject Unterklassen.

class Entry : public QObject
{
    Q_OBJECT
    Q_PROPERTY(QString display READ display WRITE setDisplay NOTIFY displayChanged)
    Q_PROPERTY(QIcon decoration READ decoration WRITE setDecoration NOTIFY decorationChanged)
    Q_PROPERTY(QString toolTip READ toolTip WRITE setToolTip NOTIFY toolTipChanged)

public:
    Entry() = default;

    QString display() const
    {
        return m_display;
    }

    void setDisplay(const QString &display)
    {
        if (m_display == display)
            return;
        m_display = display;
        emit displayChanged(m_display);
    }

signals:
    void displayChanged(const QString &);
    ...
};
std::vector<std::shared_ptr<Entry>> entries = {
    ...
};
QRangeModel model(std::ref(entries));
QListView listView;
listView.setModel(&model);

Wie bei Werten definiert der Typ der Zeile, ob der Bereich als Liste, Tabelle oder Baum dargestellt wird. Zeilen, die QObjects sind, stellen jede Eigenschaft als Spalte dar, es sei denn, die Vorlage QRangeModel::RowOptions ist so spezialisiert, dass der Typ als Multi-Role-Element deklariert ist.

template <>
struct QRangeModel::RowOptions<Entry>
{
    static constexpr auto rowCategory = QRangeModel::RowCategory::MultiRoleItem;
};
std::vector<std::shared_ptr<Entry>> entries = {
    std::make_shared<Entry>(),
    ...
};

QRangeModel model(std::ref(entries));

Unterklassifizierung von QRangeModel

Die Unterklassifizierung von QRangeModel ermöglicht es, praktische APIs hinzuzufügen, die den Datentyp und die Struktur des Bereichs berücksichtigen.

class NumbersModel : public QRangeModel
{
    std::vector<int> m_numbers;

public:
    NumbersModel(const std::vector<int> &numbers)
        : QRangeModel(std::ref(m_numbers))
        , m_numbers(numbers)
    {
    }

Fügen Sie dabei den Bereich als privates Mitglied hinzu und rufen Sie den QRangeModel-Konstruktor mit einem Referenz-Wrapper oder Zeiger auf dieses Mitglied auf. Dadurch werden die Daten ordnungsgemäß gekapselt und ein direkter Zugriff vermieden.

    void setNumber(int idx, int number)
    {
        setData(index(idx, 0), QVariant::fromValue(number));
    }

    int number(int idx) const
    {
        return m_numbers.at(idx);
    }
};

Fügen Sie Memberfunktionen hinzu, um einen typsicheren Zugriff auf die Daten zu ermöglichen, und verwenden Sie die API QAbstractItemModel, um alle Operationen durchzuführen, die den Bereich verändern. Der Nur-Lese-Zugriff kann direkt auf die Datenstruktur wirken.

Datenbäume

QRangeModel kann eine Datenstruktur als Baummodell darstellen. Eine solche Baumdatenstruktur muss homomorph sein: Auf allen Ebenen des Baums muss die Liste der untergeordneten Zeilen genau dieselbe Darstellung verwenden wie der Baum selbst. Darüber hinaus muss der Zeilentyp eine statische Größe haben: entweder ein Gadget- oder QObject -Typ oder ein Typ, der das {C++ Tupel-Protokoll} implementiert.

Um solche Daten als Baum darzustellen, muss QRangeModel in der Lage sein, die Datenstruktur zu durchlaufen: für jede beliebige Zeile muss das Modell in der Lage sein, die übergeordnete Zeile und die optionale Spanne der Kinder abzurufen. Diese Traversalfunktionen können implizit über den Zeilentyp oder über einen expliziten Protokolltyp bereitgestellt werden.

Implizites Baum-Traversal-Protokoll

class TreeRow;

using Tree = std::vector<TreeRow>;

Der Baum selbst ist ein Vektor von TreeRow Werten. Siehe Tree Rows as pointers or values für die Überlegungen, ob Werte oder Zeiger für die Zeilen verwendet werden sollen.

class TreeRow
{
    Q_GADGET
    // properties

    TreeRow *m_parent;
    std::optional<Tree> m_children;

public:
    TreeRow() = default;

    // rule of 0: copy, move, and destructor implicitly defaulted

Die Zeilenklasse kann ein beliebiger, oben beschriebener Typ mit fester Größe sein: ein Typ, der das Tupelprotokoll implementiert, ein Gadget oder ein QObject. In diesem Beispiel wird ein Gadget verwendet.

Jedes Zeilenelement muss einen Zeiger auf die übergeordnete Zeile sowie einen optionalen Bereich von untergeordneten Zeilen enthalten. Dieser Bereich muss mit der für den Baum selbst verwendeten Bereichsstruktur identisch sein.

Den Zeilentyp standardmäßig konstruierbar zu machen, ist optional und ermöglicht es dem Modell, neue Zeilendatenelemente zu konstruieren, zum Beispiel in den Implementierungen insertRow() oder moveRows().

    // tree traversal protocol implementation
    const TreeRow *parentRow() const { return m_parent; }
    const std::optional<Tree> &childRows() const { return m_children; }

Das Protokoll zur Durchquerung des Baums kann dann als Mitgliedsfunktionen des Zeilendatentyps implementiert werden. Eine Funktion const parentRow() muss einen Zeiger auf ein const-Zeilenelement zurückgeben; und die Funktion childRows() muss einen Verweis auf eine const std::optional zurückgeben, die den optionalen Kindbereich enthalten kann.

Diese beiden Funktionen reichen aus, damit das Modell den Baum als schreibgeschützte Datenstruktur navigieren kann. Um dem Benutzer die Möglichkeit zu geben, Daten in einer Ansicht zu bearbeiten, und dem Modell zu ermöglichen, sich ändernde Modell-APIs wie insertRows(), removeRows() und moveRows() zu implementieren, müssen wir zusätzliche Funktionen für den Schreibzugriff implementieren:

    void setParentRow(TreeRow *parent) { m_parent = parent; }
    std::optional<Tree> &childRows() { return m_children; }

Das Modell ruft die Funktion setParentRow() und die veränderbare Überladung childRows() auf, um Zeilen in einen bestehenden Baumzweig zu verschieben oder einzufügen und um den übergeordneten Zeiger zu aktualisieren, wenn der alte Wert ungültig geworden ist. Die non-const Überladung von childRows() bietet zusätzlich Schreibzugriff auf die Zeilendaten.

    ...
    // Helper to assembly a tree of rows, not used by QRangeModel
    template <typename ...Args>
    TreeRow &addChild(Args &&...args)
    {
        if (!m_children)
            m_children.emplace(Tree{});
        auto &child = m_children->emplace_back(std::forward<Args>(args)...);
        child.m_parent = this;
        return child;
    }
};

Der Rest der Klassenimplementierung ist für das Modell nicht relevant, aber eine addChild() -Hilfsfunktion bietet uns eine bequeme Möglichkeit, den Anfangszustand des Baums zu konstruieren.

Tree tree = {
    {"..."},
    {"..."},
    {"..."},
};

// each toplevel row has three children
tree[0].addChild("...");
tree[0].addChild("...");
tree[0].addChild("...");

tree[1].addChild("...");
tree[1].addChild("...");
tree[1].addChild("...");

tree[2].addChild("...");
tree[2].addChild("...");
tree[2].addChild("...");

Ein QRangeModel, das mit einer Instanz eines solchen Bereichs instanziiert wird, stellt die Daten als Baum dar.

// instantiate the model with a pointer to the tree, not a copy!
QRangeModel model(&tree);
QTreeView view;
view.setModel(&model);

Protokoll für die Baumdurchquerung in einer separaten Klasse

Das Tree Traversal Protocol kann auch in einer separaten Klasse implementiert werden.

struct TreeTraversal
{
    TreeRow newRow() const { return TreeRow{}; }
    const TreeRow *parentRow(const TreeRow &row) const { return row.m_parent; }
    void setParentRow(TreeRow &row, TreeRow *parent) const { row.m_parent = parent; }
    const std::optional<Tree> &childRows(const TreeRow &row) const { return row.m_children; }
    std::optional<Tree> &childRows(TreeRow &row) const { return row.m_children; }
};

Übergeben Sie eine Instanz dieser Protokollimplementierung an den QRangeModel-Konstruktor:

QRangeModel model(&tree, TreeTraversal{});

Tree Rows als Zeiger oder Werte

Der Zeilentyp des Datenbereichs kann entweder ein Wert oder ein Zeiger sein. Im obigen Code haben wir die Baumzeilen als Werte in einem Vektor verwendet, wodurch wir eine explizite Speicherverwaltung vermeiden. Ein Vektor als zusammenhängender Speicherblock macht jedoch alle Iteratoren und Verweise ungültig, wenn der Speicher neu zugewiesen werden muss oder wenn Elemente eingefügt oder entfernt werden. Dies wirkt sich auf den Zeiger auf das übergeordnete Element aus, d. h. auf die Position der übergeordneten Zeile innerhalb des Vektors. Die Sicherstellung, dass dieses übergeordnete Element (und die Instanzen von QPersistentModelIndex, die sich auf Elemente innerhalb dieses Elements beziehen) gültig bleibt, kann zu einem erheblichen Leistungs-Overhead führen. Die QRangeModel-Implementierung muss davon ausgehen, dass alle Verweise auf den Bereich ungültig werden, wenn der Bereich geändert wird.

Alternativ können wir auch einen Bereich von Zeilenzeigern als Baumtyp verwenden:

struct TreeRow;
using Tree = std::vector<TreeRow *>;

In diesem Fall müssen wir alle TreeRow-Instanzen explizit mit dem Operator new zuweisen und den Destruktor so implementieren, dass alle Elemente im Vektor der Kinder delete sind.

struct TreeRow { Q_GADGETpublic: TreeRow(const QString &value = {}) : m_value(value) {} ~TreeRow() { if (m_children)            qDeleteAll(*m_children);
    } // nur verschiebenTreeRow(TreeRow &&) = default; TreeRow &operator=(TreeRow &&) = default; // helper zum Auffüllen der Vorlage <typename ...Args>TreeRow *addChild(Args &&...args) { if (!m_children) m_children.emplace(Tree{}); auto *child =  m_children->emplace_back(new TreeRow(std::forward<Args>(args)...));  child->m_parent = this; return child; }private: friend struct TreeTraversal;    QString m_value; std::optional<Tree> m_children; TreeRow *m_parent = nullptr; }; Tree tree = { new TreeRow("1"), new TreeRow("2"), new TreeRow("3"), new TreeRow("4"),}; tree[0]->addChild("1.1");
tree[1]->addChild("2.1");
tree[2]->addChild("3.1")->addChild("3.1.1");
tree[3]->addChild("4.1");

Bevor wir ein Modell konstruieren können, das diese Daten als Baum darstellt, müssen wir auch das Protokoll für die Baumüberquerung implementieren.

struct TreeTraversal
{
    TreeRow *newRow() const { return new TreeRow; }
    void deleteRow(TreeRow *row) { delete row; }

    const TreeRow *parentRow(const TreeRow &row) const { return row.m_parent; }
    void setParentRow(TreeRow &row, TreeRow *parent) { row.m_parent = parent; }
    const std::optional<Tree> &childRows(const TreeRow &row) const { return row.m_children; }
    std::optional<Tree> &childRows(TreeRow &row) { return row.m_children; }
};

Eine explizite Protokollimplementierung für veränderliche Zeigerbäume muss zwei zusätzliche Mitgliedsfunktionen bereitstellen: newRow() und deleteRow(RowType *).

int main(int argc, char **argv)
{
    QApplication app(argc, argv);

    Tree tree = make_tree_of_pointers();

    QRangeModel model(std::move(tree), TreeTraversal{});
    QTreeView treeView;
    treeView.setModel(&model);
    treeView.show();

    return app.exec();
}

Das Modell ruft diese Funktionen beim Anlegen neuer Zeilen in insertRows() und beim Entfernen von Zeilen in removeRows() auf. Wenn das Modell Eigentümer der Daten ist, löscht es außerdem alle Zeilen der obersten Ebene bei der Zerstörung. Beachten Sie, dass wir in diesem Beispiel den Baum in das Modell verschieben, so dass wir keine Operationen mehr an ihm durchführen müssen. QRangeModel, wenn es durch Verschieben von Baumdaten mit Zeilenzeigern konstruiert wird, übernimmt das Eigentum an den Daten und löscht die Zeilenzeiger in seinem Destruktor.

Die Verwendung von Zeigern als Zeilen bringt einen gewissen Overhead bei der Speicherzuweisung und -verwaltung mit sich. Die Verweise auf die Zeilenelemente bleiben jedoch stabil, auch wenn sie innerhalb des Bereichs verschoben werden oder der Bereich neu zugewiesen wird. Dies kann die Kosten für Änderungen an der Struktur des Modells bei Verwendung von insertRows(), removeRows() oder moveRows() erheblich reduzieren.

Jede Wahl hat unterschiedliche Kompromisse bei der Leistung und dem Speicher-Overhead. Die beste Option hängt vom genauen Anwendungsfall und der verwendeten Datenstruktur ab.

Das C++ Tupel-Protokoll

Wie im obigen Beispiel numberNames zu sehen ist, kann der Zeilentyp ein Tupel sein, und zwar jeder Typ, der das Tupelprotokoll implementiert. Dieses Protokoll wird durch die Spezialisierung von std::tuple_size und std::tuple_element und das Überladen der unqualifizierten Funktion get implementiert. Tun Sie dies für Ihren benutzerdefinierten Zeilentyp, um vorhandene strukturierte Daten für das Model/View-Framework in Qt verfügbar zu machen.

struct Book
{
    QString title;
    QString author;
    QString summary;
    int rating = 0;

    template <size_t I, typename T>
        requires ((I <= 3) && std::is_same_v<std::remove_cvref_t<T>, Book>)
    friend inline decltype(auto) get(T &&book)
    {
        if constexpr (I == 0)
            return std::as_const(book.title);
        else if constexpr (I == 1)
            return std::as_const(book.author);
        else if constexpr (I == 2)
            return std::forward_like<T>(book.summary);
        else if constexpr (I == 3)
            return std::forward_like<T>(book.rating);
    }
};

namespace std {
    template <> struct tuple_size<Book> : std::integral_constant<size_t, 4> {};
    template <size_t I> struct tuple_element<I, Book>
    { using type = decltype(get<I>(std::declval<Book>())); };
}

In der obigen Implementierung werden die Werte title und author des Typs Book als const zurückgegeben, so dass das Modell Elemente in diesen beiden Spalten als schreibgeschützt kennzeichnet. Der Benutzer wird nicht in der Lage sein, die Bearbeitung auszulösen, und setData() tut nichts und gibt false zurück. Für summary und rating gibt die Implementierung dieselbe Wertkategorie wie das Buch zurück. Wenn also get mit einem veränderbaren Verweis auf Book aufgerufen wird, gibt es einen veränderbaren Verweis auf die entsprechende Variable zurück. Das Modell macht diese Spalten editierbar, sowohl für den Benutzer als auch für den programmatischen Zugriff.