Вот, в QT QObject имеет свою парадигму управления памятью, без использования вумных указателей. Правильно ли это с вашей точки зрения?

Здравствуйте, Shmj, Вы писали:

S>Вот, в QT QObject имеет свою парадигму управления памятью, без использования вумных указателей. Правильно ли это с вашей точки зрения?

Речь видимо о родительских и дочерних объектах.

QObject поддерживают информацию о дереве дочерних объектов. Когда Вы создаете QObject в качестве родителя другого объекта, то объект автоматически добавит себя в список дочерних объектов children(). Родитель принимает в собственность свои дочерние объекты, т.е. дочерние объекты будут автоматически удалены в деструкторе объекта-родителя.

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

По сути это древовидная структура данных из объектов, а не просто управление памятью одного объекта. Это не отменяет указателей с ручным управлением памятью или тем более умных указателей. Особенно это становится очевидным, если применять другие структуры данных, например, на основе шаблонов C++.

Здравствуйте, Shmj, Вы писали:

S>Вот, в QT QObject имеет свою парадигму управления памятью,
Родители удаляют детей
S>без использования вумных указателей.
За родителем всё равно надо следить и лучше через умный указатель, std, boost, Q*Pointer
S>Правильно ли это с вашей точки зрения?
Да, это удобно, и deleteLater тоже нужен когда в своем слоте нужно самоуничтожиться.

Здравствуйте, Shmj, Вы писали:

S>Вот, в QT QObject имеет свою парадигму управления памятью, без использования вумных указателей. Правильно ли это с вашей точки зрения?

Нравится или правильно? Ты уж определись.

И да, прикинь, везде по разному бывает. Хотя я понимаю, что тебе от догматизма уже не избавится

Здравствуйте, Shmj, Вы писали:

S>Вот, в QT QObject имеет свою парадигму управления памятью, без использования вумных указателей. Правильно ли это с вашей точки зрения?

Конкретно для ui это удобная фича.

Здравствуйте, Shmj, Вы писали:

S>Вот, в QT QObject имеет свою парадигму управления памятью, без использования вумных указателей. Правильно ли это с вашей точки зрения?

С моей точки зрения Qt это абоминация, если смотреть на неё, как на С++ библиотеку.

S>Вот, в QT QObject имеет свою парадигму управления памятью, без использования вумных указателей. Правильно ли это с вашей точки зрения?

Нет такого — правильно или нет. Работает — значит правильно.

А в плане удобства лично мне очень нравится.

Здравствуйте, Shmj, Вы писали:

S>Вот, в QT QObject имеет свою парадигму управления памятью, без использования вумных указателей. Правильно ли это с вашей точки зрения?

S>

03.10.23 12:19: Очередной вопрос без указания конкретной цели — SaZ

Сорри, надо перенести в "компьютерные священные войны, немного ошибся веткой.

Здравствуйте, Shmj, Вы писали:

S>Вот, в QT QObject имеет свою парадигму управления памятью, без использования вумных указателей. Правильно ли это с вашей точки зрения?

просто очередной костыль в управлении памятью, примерно как Release/Retain/Autorelease в ObjectiveC, который красиво спрятался за синтаксическим сахаром под названием ЯП Swift

S>Правильно ли это с вашей точки зрения?

А какие критерии у этой правильности?

Здравствуйте, Muxa, Вы писали:

M>А какие критерии у этой правильности?

Хотя бы согласованность с STL

Здравствуйте, vsb, Вы писали:

S>>Вот, в QT QObject имеет свою парадигму управления памятью, без использования вумных указателей. Правильно ли это с вашей точки зрения?
vsb>С моей точки зрения Qt это абоминация,

что имелось в виду? описание из словаря по смыслу не очень подходит.

Здравствуйте, Shmj, Вы писали:

S>Вот, в QT QObject имеет свою парадигму управления памятью, без использования вумных указателей.

нет
см. например https://doc.qt.io/qt-6/qsharedpointer.html

S>Правильно ли это с вашей точки зрения?

где-то уместно, где-то нет.

Здравствуйте, night beast, Вы писали:

S>>>Вот, в QT QObject имеет свою парадигму управления памятью, без использования вумных указателей. Правильно ли это с вашей точки зрения?
vsb>>С моей точки зрения Qt это абоминация,

NB>что имелось в виду? описание из словаря по смыслу не очень подходит.

Сразу скажу, что плотно работал с Qt 4. С тех пор возможно что-то стало лучше.

1. Исходники обрабатывались препроцессором moc. Т.е. код был уже не на C++, а на некоем диалекте, который препроцессировался в С++.

2. Куча классов, дублирующих стандартную библиотеку. QString, QList и подобное.

3. Сигналы и слоты связывались не через стандартные С++ конструкции, а через какой-то свой механизм. Вроде в том числе moc это и делал. Вроде этот пункт в современных Qt переделали.

4. Обработка ошибок не через исключения. А исключения там по-моему вообще приводили к каким-то плохим последствиям.

5. Код вообще не выглядел каноничным С++.

В итоге для работы с Qt нужно было учить не С++, а C++ с Qt-шным налётом, так сказать. Причём это может быть и не так уж плохо, лично мне С++ не особо нравится, но всё же я считаю — если берёшь язык, нужно библиотеку писать так, как на этом языке принято писать. А не менять язык под свою библиотеку. Поэтому и назвал абоминацией. Взяли куски из С++, сшили их какими-то своими нитками.

Здравствуйте, vsb, Вы писали:

vsb>Сразу скажу, что плотно работал с Qt 4. С тех пор возможно что-то стало лучше.
vsb>5. Код вообще не выглядел каноничным С++.

vsb>В итоге для работы с Qt нужно было учить не С++, а C++ с Qt-шным налётом, так сказать. Причём это может быть и не так уж плохо, лично мне С++ не особо нравится, но всё же я считаю — если берёшь язык, нужно библиотеку писать так, как на этом языке принято писать. А не менять язык под свою библиотеку. Поэтому и назвал абоминацией. Взяли куски из С++, сшили их какими-то своими нитками.

тут в основном вопрос что считать каноничным С++
кто-то использует из плюсов шаблоны, стандартную библиотеку, исключения и вот это все
а кто-то применяет как Си с классами

второй подход тоже вполне распространен, и я бы не сказал что Qt в этом плане какой-то особенный (если не учитывать моки)
причем, в те времена, когда qt создавался (публичный релиз в мае 1995), народ в основном использовал именно объектный подход

Здравствуйте, vsb, Вы писали:

vsb>1. Исходники обрабатывались препроцессором moc. Т.е. код был уже не на C++, а на некоем диалекте, который препроцессировался в С++.
Там всего несколько ключевых слов и выражений над обычным С++.

vsb>2. Куча классов, дублирующих стандартную библиотеку. QString, QList и подобное.
Стандартная библиотека не поддерживает(ла) COW, UTF-8, интернационализацию и т.п.

vsb>3. Сигналы и слоты связывались не через стандартные С++ конструкции, а через какой-то свой механизм. Вроде в том числе moc это и делал. Вроде этот пункт в современных Qt переделали.
Синтаксис подключения сигналов и слотов сейчас сейчас через стандартный С++.

vsb>4. Обработка ошибок не через исключения. А исключения там по-моему вообще приводили к каким-то плохим последствиям.
Qt ортогональна исключениям. В том, что сама библиотека исключения не использует никакой проблемы вообще нет, ровно наоборот: в GUI обычно нет необходимости передавать информцию об ошибке через несколько уровней.

vsb>5. Код вообще не выглядел каноничным С++.
Ровно наооборот: Qt одной из первых определила вменяемый и последовательный стиль для плюсового кода. Собственно их сейчас 2: а-ля stl_boost и Qt.

vsb>В итоге для работы с Qt нужно было учить не С++, а C++ с Qt-шным налётом, так сказать. Причём это может быть и не так уж плохо, лично мне С++ не особо нравится, но всё же я считаю — если берёшь язык, нужно библиотеку писать так, как на этом языке принято писать. А не менять язык под свою библиотеку. Поэтому и назвал абоминацией. Взяли куски из С++, сшили их какими-то своими нитками.
Если решать задачи для которых Qt создана, то ощущение будет совсем другое.

Здравствуйте, night beast, Вы писали:

NB>тут в основном вопрос что считать каноничным С++
NB>кто-то использует из плюсов шаблоны, стандартную библиотеку, исключения и вот это все
NB>а кто-то применяет как Си с классами

NB>второй подход тоже вполне распространен, и я бы не сказал что Qt в этом плане какой-то особенный (если не учитывать моки)
NB>причем, в те времена, когда qt создавался (публичный релиз в мае 1995), народ в основном использовал именно объектный подход

Для меня каноничный С++ это всё, что там есть + буст. С с классами — не каноничный С++.

Единственная фича С++, которую может быть разумно не использовать это исключения из-за их нетривиальной реализации. Если программа работает на микроконтроллере, эту цену может не захотеться платить. Но Qt не работает на таких слабых платформах.

Исторические нюансы я понимаю, но моего мнения это не меняет, в 2023 году код на Qt выглядит чужеродно.

Здравствуйте, Skorodum, Вы писали:

vsb>>2. Куча классов, дублирующих стандартную библиотеку. QString, QList и подобное.
S>Стандартная библиотека не поддерживает(ла) COW, UTF-8, интернационализацию и т.п.

Все еще проще: на момент начала работ над Qt эксперименты Степанова и Ли над тем, что потом станет STL, только-только получили широкую известность. Ну а допилили STL от Степанова до того STL, что мы получили в C++98, только во время работы над первым стандартом (т.е. где-то реально в промежуток между 1994-м и 1998-м годом). Т.е. авторы Qt были вынуждены делать свою "стандартную" библиотеку. Чем, впрочем, тогда многие занимались (что-то похожее было и в MFC, и в wxWindows, и в OWL).

На счет COW: до выхода C++11 вроде бы COW строки были в реализации STL от GCC. Но C++11 на этом поставил жирную точку.

Здравствуйте, Shmj, Вы писали:

S>Вот, в QT QObject имеет свою парадигму управления памятью, без использования вумных указателей. Правильно ли это с вашей точки зрения?

в Qt чувствуется влияние Java. Всё есть указатель, наследование от одного объекта, подобие сборки мусора. На момент создания это было нормально. До 11 года многие держали в векторе только указатели. Иначе resize бил по производительности. А вот после 11, ситуация немного поменялась. Теперь держать указатели в векторе без необходимости считается дурным тоном. И вообще С++ всё больше подталкивает не использовать указатели вовсе. А Qt не поменялся. Собственно это различие раздражает.

void addLabelToLayout(QLayout& layout) {
    layout.addWidget(new QLabel("my label"));
}

void addLabelToLayout(QLayout& layout) {
    QLabel l = QLabel("my label");
    layout.addWidget(&l);
}

C точки зрения С++, первое — явная ересь с утечкой памяти и следует предпочесть второй путь, а с точки зрения Qt всё ровно наоборот.

Подытоживая, сейчас парадигма Qt выглядит неправильно.

Здравствуйте, sergii.p, Вы писали:

S>>Вот, в QT QObject имеет свою парадигму управления памятью, без использования вумных указателей. Правильно ли это с вашей точки зрения?

SP>в Qt чувствуется влияние Java.

Только вот Qt начали делать еще когда про Java за пределами Sun Microsystems не знали...