Changeset View
Standalone View
src/personssortfilterproxymodel.h
| Show First 20 Lines • Show All 44 Lines • ▼ Show 20 Line(s) | |||||
| 45 | public: | 45 | public: | ||
| 46 | explicit PersonsSortFilterProxyModel(QObject *parent = nullptr); | 46 | explicit PersonsSortFilterProxyModel(QObject *parent = nullptr); | ||
| 47 | ~PersonsSortFilterProxyModel() override; | 47 | ~PersonsSortFilterProxyModel() override; | ||
| 48 | 48 | | |||
| 49 | QStringList requiredProperties() const; | 49 | QStringList requiredProperties() const; | ||
| 50 | void setRequiredProperties(const QStringList &props); | 50 | void setRequiredProperties(const QStringList &props); | ||
| 51 | 51 | | |||
| 52 | bool filterAcceptsRow(int source_row, const QModelIndex &source_parent) const override; | 52 | bool filterAcceptsRow(int source_row, const QModelIndex &source_parent) const override; | ||
| 53 | 53 | | |||
broulik: Can you just forward the entire thing:
```
Q_INVOKABLE void sort(int column, Qt::SortOrder… | |||||
broulik: ... which people say is ABI-compatible | |||||
"You can ... reimplement virtual functions defined in the primary base class hierarchy (that is, virtuals defined in the first non-virtual base class, or in that class's first non-virtual base class, and so forth) if it is safe that programs linked with the prior version of the library call the implementation in the base class rather than the derived one. This is tricky and might be dangerous. Think twice before doing it. Alternatively see below for a workaround." broulik: "You can ... reimplement virtual functions defined in the primary base class hierarchy (that is… | |||||
Approximately no one uses C++ virtual classes (which are a separate feature from virtual methods which we are used to). Basically, reimplementing a virtual function that's already defined in a base class can be binary compatible for already-compiled programs because it doesn't change the size or calling convention of the virtual table: there was already a slot in the virtual table to call the base class's implementation of a virtual function, and we replaced the pointer in the virtual table to instead call the newly-implemented virtual function in the derived class. The catch is that already-compiled code is not guaranteed to call the derived class implementation (due to inlining or other optimizations, for instance) so you cannot absolutely rely on your new implementation being called. If you have to think too hard about whether it's safe or not, it's best to assume it's not. In this case we're literally just calling the original implementation anyways, and Q_INVOKABLE is just to register it to the meta-object system, so I think this should be fine. But if we want to use a separate method I'd label it as "KF6 TODO" or something similar so that we can go back and fix it up. mpyne: Approximately no one uses C++ virtual classes (which are a separate feature from virtual… | |||||
| 54 | Q_INVOKABLE void sort(int column, Qt::SortOrder order = Qt::AscendingOrder) override; | ||||
| 55 | | ||||
| 54 | private: | 56 | private: | ||
| 55 | Q_DISABLE_COPY(PersonsSortFilterProxyModel) | 57 | Q_DISABLE_COPY(PersonsSortFilterProxyModel) | ||
| 56 | 58 | | |||
| 57 | QScopedPointer<PersonsSortFilterProxyModelPrivate> const d_ptr; | 59 | QScopedPointer<PersonsSortFilterProxyModelPrivate> const d_ptr; | ||
| 58 | Q_DECLARE_PRIVATE(PersonsSortFilterProxyModel) | 60 | Q_DECLARE_PRIVATE(PersonsSortFilterProxyModel) | ||
| 59 | }; | 61 | }; | ||
| 60 | 62 | | |||
| 61 | } | 63 | } | ||
| 62 | 64 | | |||
| 63 | #endif // PERSONSSORTFILTERPROXYMODEL_H | 65 | #endif // PERSONSSORTFILTERPROXYMODEL_H | ||
Can you just forward the entire thing: