RS
разделение устраняет неправильное их использование
Size: a a a
2017 April 27
RS
там где ожидается Хлеб нужно дать Хлеб, а не Соль))
DK
чото какой-то джава-подход мне кажется
DK
ну короче тогда только страдать
DK
но, могу сказать честно, я бы за подобный код в наших проектах отрубил бы руки. Причем скорее всего по элементам
ШВ
а чем Q_GADGET то не устроил?
RS
по сути особого желания всё в QObject делать тож нет, поскольку у QObject overhead большой
DK
вот гаджет можно
DK
да
DK
наверно
ШВ
я вот не могу понять как в Qt лучше всего реализовать composition...
предположим есть у нас
и внутри этой композиции у нас member "id" типа
поскольку QObject не копируется придётся хранить указатель на this.id и в указателе хранить под-обьект. Однаку тут я вижу опасный момент...
предположим есть у нас
Metadata : public QObject
и внутри этой композиции у нас member "id" типа
Identifier : public QObject
поскольку QObject не копируется придётся хранить указатель на this.id и в указателе хранить под-обьект. Однаку тут я вижу опасный момент...
Metadata meta(.....);
meta.id().deleteLater() //piздец
и я чет вопрос не понял, зачем deleteLater?
RS
Q_GADGET честно впервые слышу
ШВ
meta.id().deleteLater() <- вот это непонятное совсем
RS
и я чет вопрос не понял, зачем deleteLater?
дело в том что deleteLater позволяет легко, нечаянно сломать композицию из QObject
AK
он для этих целей и нужен - когда необходимо видеть объект на стороне qml при этом не затаскивая QObject
DK
дело в том что deleteLater позволяет легко, нечаянно сломать композицию из QObject
а еще можно сделать четко выверенный memcpy внутрь объекта
AK
Насколько я помню для этого ему необязательно быть наследником от QObject. Погугли в сторону Q_GADGET
ШВ
а delete не ломает?
AK
а delete не ломает?
видимо не так ))
RS
а delete не ломает?
я уже писал что указатели в принципе опасные, но smart pointer использовать с Qt parent based garbage collection тоже опасно