Как правильно создать наследника QObject?

[Shilo]

Почитал про QPointer. Безопасность его применения заключается в том, что при удалении временной переменной cs закрытй член curCoordinateSystem не будет показывть "пальцем в небо" а обнулится. А мне надо, чтобы после удаления cs в curCoordinateSystem данные сохранились. Ну то есть эти данные надо скопировать. Применять оператор = класса QPointer тоже нельзя.

QPointer<T> & QPointer::operator= ( const QPointer<T> & p )

Assignment operator. This guarded pointer will now point to the same object that p points to.

Копируется адрес а не данные. Опять же не решается проблем с доступом к закрытому члену класса через временную переменную.

[spirit]

в таких случаях клонируют объект. сделай метод clone в CoordinateSystem,
который будет конструировать новый объект, но с такими же параметрами как и исходный и тогда в методе ProjectProperties::setCoordinateSystem клонируй его.

[Shilo]

в таких случаях клонируют объект. сделай метод clone в CoordinateSystem,
который будет конструировать новый объект, но с такими же параметрами как и исходный и тогда в методе ProjectProperties::setCoordinateSystem клонируй его.

Вот эта идея мне нравится. То есть в методе ProjectProperties::setCoordinateSystem я сначала присваиваю члену curCoordinateSystem адрес параметра newCoordinateSystem затем клонирую curCoordinateSystem. Таким образом в нем уже содержится другой адре. Далее удаляю временную переменную и освобождаю занятую ею память, а мне не страшно . Ведь эта переменная и curCoordinateSystem уже указывают на разные адреса!!!
Если я не прав, поправте меня.

[spirit]

все верно, только при клонировании нужно не ошибиться с парентом,
если в качестве парента указать целевой объект,
то клонированный объект разрушится при разрушении целевого объекта.

[Shilo]

все верно, только при клонировании нужно не ошибиться с парентом,
если в качестве парента указать целевой объект,
то клонированный объект разрушится при разрушении целевого объекта.

Предпологается, что метод CoordinateSyste::clone(parent* QObject) будет вызываться в методе ProjectProperties::setCoordinateSystem. Тогда если в качестве парента указать this, то парентом клонированного объекта будет объект класса ProjectProperties. Кажись так...
А вообще, не могли бы вы написать прототип метода clone(). Я его себе представляю так

Код

C++ (Qt)
CoordinateSystem* CoordinateSystem::clone(parent* QObject, CoordinateSystem* oldCS);
 

Это правильно?

[spirit]

да можно и так, только сигнатура чуть другая будет

Код

C++ (Qt)
CoordinateSystem* CoordinateSystem::clone(QObject *parent, CoordinateSystem* oldCS);
 

[SASA]

еще раз повторю -- тролли не просто так заприватили оператор присваивания.

Прошу пояснить подробнее.

Я копирую объекты, присваиваю, храню их в списках, запихиваю QVarint. Негативных последствий я не наблюдал. Не видел я и указаний то, что наследников QObject нельзя копировать. Может я чё упустил?

[Shilo]

да можно и так, только сигнатура чуть другая будет

Код

C++ (Qt)
CoordinateSystem* CoordinateSystem::clone(QObject *parent, CoordinateSystem* oldCS);
 

Ну конечно! Это просто я запарился малость.
Чтож, полагаю найдено элегантное и безопасное решение наследования от QObject. По сути метод clone() будет заменой скрытому оператору = и конструктору копирования. Огромное спасибо за помощь.

[spirit]

Я копирую объекты, присваиваю, храню их в списках, запихиваю QVarint. Негативных последствий я не наблюдал.

это справедливо для объектов, которые не являются потомками QObject.

Не видел я и указаний то, что наследников QObject нельзя копировать. Может я чё упустил?

из сырцов

Код

C++ (Qt)
...
private:
    Q_DISABLE_COPY(QObject)
...
 

а вот теперь подумай, что будет, если присвоить одному виджету другой, если бы операции копирования и присваивания были открыты. 

[Shilo]

Я копирую объекты, присваиваю, храню их в списках, запихиваю QVarint. Негативных последствий я не наблюдал. Не видел я и указаний то, что наследников QObject нельзя копировать. Может я чё упустил?

Полагаю, что в случае с QObject (и его потомками тоже) вы копируете не объекты, а адреса объектов. Ибо в противном случае такой код просто не скомпилируется. Нельзя использовать закрытые члены классов. А конструктор копирования и оператор = в QObject объявлены private.

[spirit]

вот, кстати, и вытяжка из ассистанта

No copy constructor or assignment operator
QObject has neither a copy constructor nor an assignment operator. This is by design. Actually, they are declared, but in a private section with the macro Q_DISABLE_COPY(). In fact, all Qt classes derived from QObject (direct or indirect) use this macro to declare their copy constructor and assignment operator to be private. The reasoning is found in the discussion on Identity vs Value on the Qt Object Model page.
The main consequence is that you should use pointers to QObject (or to your QObject subclass) where you might otherwise be tempted to use your QObject subclass as a value. For example, without a copy constructor, you can't use a subclass of QObject as the value to be stored in one of the container classes. You must store pointers.

[ритт]

а мне вообще вся эта ветка видится притянутой за уши. нельзя копировать объект? - ну и х?? с ним. тебе ведь всё-равно не нужно копировать нутря объекта - а только твои кастомные данные, подцепленные к этому объекту...
QSharedData не спасёт отца русской демократии?

[SASA]

Полагаю, что в случае с QObject (и его потомками тоже) вы копируете не объекты, а адреса объектов.

Я прекрасно понимаю отличия объекта от адреса объекта.

это справедливо для объектов, которые не являются потомками QObject.

Объекты являются потомкаим QObject, с переопределёнными конструкторами копирвания и присваивания.
Причины запрещения копирования у QObject из того же ассистанта.

might have a unique QObject::objectName(). If we copy a Qt Object, what name should we give the copy?

has a location in an object hierarchy. If we copy a Qt Object, where should the copy be located?

can be connected to other Qt Objects to emit signals to them or to receive signals emitted by them. If we copy a Qt Object, how should we transfer these connections to the copy?

can have new properties added to it at runtime that are not declared in the C++ class. If we copy a Qt Object, should the copy include the properties that were added to the original?

У меня объекты - хранилища неких данных. И берут/кладут эти данные через кутешные проперти. Иногда вызывают у этих объектов слоты.

- Мне пофиг на имена объектов.
- Они не законктены ни с кем.
- В конструторе копирования я чётко указываю парента.
- Динамические проперти не использую.

Почему мне нельзя копировать объекты?

[SASA]

нельзя копировать объект? - ну и х?? с ним.

Для меня это вопрос принципиальный. Может мне придётся переписывать 10 метров исходников

[spirit]

да копируй на здоровье, я только говорю почему тролли от этого отказались и их код можно считать эталонным.