Здравствуйте, 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 имеет свою парадигму управления памятью, без использования вумных указателей. Правильно ли это с вашей точки зрения?
Здравствуйте, Shmj, Вы писали:
S>Вот, в QT QObject имеет свою парадигму управления памятью, без использования вумных указателей. Правильно ли это с вашей точки зрения?
С моей точки зрения Qt это абоминация, если смотреть на неё, как на С++ библиотеку.
Здравствуйте, Shmj, Вы писали:
S>Вот, в QT QObject имеет свою парадигму управления памятью, без использования вумных указателей. Правильно ли это с вашей точки зрения?
S>
03.10.23 12:19: Очередной вопрос без указания конкретной цели — SaZ
Сорри, надо перенести в "компьютерные священные войны, немного ошибся веткой.
Здравствуйте, Shmj, Вы писали:
S>Вот, в QT QObject имеет свою парадигму управления памятью, без использования вумных указателей. Правильно ли это с вашей точки зрения?
просто очередной костыль в управлении памятью, примерно как Release/Retain/Autorelease в ObjectiveC, который красиво спрятался за синтаксическим сахаром под названием ЯП Swift
Здравствуйте, vsb, Вы писали:
S>>Вот, в QT QObject имеет свою парадигму управления памятью, без использования вумных указателей. Правильно ли это с вашей точки зрения? vsb>С моей точки зрения Qt это абоминация,
что имелось в виду? описание из словаря по смыслу не очень подходит.
Здравствуйте, 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 не поменялся. Собственно это различие раздражает.
Здравствуйте, sergii.p, Вы писали:
S>>Вот, в QT QObject имеет свою парадигму управления памятью, без использования вумных указателей. Правильно ли это с вашей точки зрения?
SP>в Qt чувствуется влияние Java.
Только вот Qt начали делать еще когда про Java за пределами Sun Microsystems не знали...
Здравствуйте, so5team, Вы писали:
S>Все еще проще: на момент начала работ над Qt эксперименты Степанова и Ли над тем, что потом станет STL, только-только получили широкую известность. Ну а допилили STL от Степанова до того STL, что мы получили в C++98, только во время работы над первым стандартом (т.е. где-то реально в промежуток между 1994-м и 1998-м годом). Т.е. авторы Qt были вынуждены делать свою "стандартную" библиотеку. Чем, впрочем, тогда многие занимались (что-то похожее было и в MFC, и в wxWindows, и в OWL).
Да, но vsb говорил про Qt4, первый релиз в 2005-м. В теории контейнеры типа QVector можно было бы заменить, но на практике, наверное было много проблем, а бенефитов от этого особо нет.
QString и ко не заменить.
Здравствуйте, Skorodum, Вы писали:
S>Да, но vsb говорил про Qt4, первый релиз в 2005-м. В теории контейнеры типа QVector можно было бы заменить, но на практике, наверное было много проблем, а бенефитов от этого особо нет.
QVector это тоже COW (по крайней мере был)
заменить особо не на что
Здравствуйте, vsb, Вы писали:
vsb>Единственная фича С++, которую может быть разумно не использовать это исключения из-за их нетривиальной реализации. Если программа работает на микроконтроллере, эту цену может не захотеться платить. Но Qt не работает на таких слабых платформах.
Сейчас Cortex A7 достаточно.
vsb>Исторические нюансы я понимаю, но моего мнения это не меняет, в 2023 году код на Qt выглядит чужеродно.
Шаблонов мало или camelCase не любишь?
SP>C точки зрения С++, первое — явная ересь с утечкой памяти и следует предпочесть второй путь, а с точки зрения Qt всё ровно наоборот.
Вообще-то с точки зрения С++ второй вариант — ересь
Здравствуйте, Skorodum, Вы писали:
S>Да, но vsb говорил про Qt4, первый релиз в 2005-м. В теории контейнеры типа QVector можно было бы заменить, но на практике, наверное было много проблем, а бенефитов от этого особо нет.
Это вряд ли, поломалась бы совместимость с тем, что было написано ранее. А перевод с Qt3 на Qt4 был не такой уж и болезненный, из главного вспоминается разве что другое именование заголовочных файлов. В своих концепциях же Qt не менялся в то время вообще.
SP>C точки зрения С++, первое — явная ересь с утечкой памяти и следует предпочесть второй путь, а с точки зрения Qt всё ровно наоборот.
Где тут утечка? Первый случай корректный, вы создали объект и передали владение в лэйаут. Теперь это забота лэйаута.
Второй случай — вы создали объект на стеке, поместили в лэйаут, и тут же удалили при выходе из скоупа (функции). Тоже всё корректно.
SP>Подытоживая, сейчас парадигма Qt выглядит неправильно.
Неправильно относительно чего? Это просто другая парадигма управления памятью, которая тоже имеет место быть. И во многих случаях тут куда меньше оверхеда, чем со смартпоинтерами.
То что в stl есть только unique/shared вовсе не значит что нельзя использовать другие парадигмы. Лично мне для GUI очень нравится подход — создал, указал куда всунуть (парент), забыл. И всё само работает.
Теоретически можно было бы всё перефигачить на rvalue + std::move, но зачем? Это получился бы новый фреймворк.
Здравствуйте, night beast, Вы писали:
NB>QVector это тоже COW (по крайней мере был) NB>заменить особо не на что
Мне кажется это куда менее полезная фича в целом. (Лично я старался никогда не полагаться на то, что не будет копирования массивов.)
Есть пример кода, где оно реально полезно, и по другому сложно сделать?
Здравствуйте, Skorodum, Вы писали:
NB>>QVector это тоже COW (по крайней мере был) NB>>заменить особо не на что S>Мне кажется это куда менее полезная фича в целом. (Лично я старался никогда не полагаться на то, что не будет копирования массивов.)
это оптимизация
S>Есть пример кода, где оно реально полезно, и по другому сложно сделать?
Здравствуйте, SaZ, Вы писали:
SaZ>То что в stl есть только unique/shared вовсе не значит что нельзя использовать другие парадигмы. Лично мне для GUI очень нравится подход — создал, указал куда всунуть (парент), забыл. И всё само работает.
безотносительно Qt мне нравится принцип питона: "явное лучше, чем неявное"
то есть я смотря только на код должен не влезая во внутреннее устройство понимать, что происходит с владением объекта
Первый вариант — выглядит вполне корректно и логично (как для C++, так и для Qt).
Второй вариант — выглядит стрёмно: сохранили адрес локальной (стековой) переменной.
Он, как и сама переменная, потеряет смысл после выхода из метода (функции).
SP>C точки зрения С++, первое — явная ересь с утечкой памяти и следует предпочесть второй путь,
Почему же?
Адрес объекта в куче сохранён в коллекции.
Что не так?
Что мешает впоследствии удалить этот объект?
SP>Подытоживая, сейчас парадигма Qt выглядит неправильно.
Она и сейчас весьма актуальна, просто появились новые инструменты (прежде всего — для GUI developing).
SaZ>Где тут утечка? Первый случай корректный, вы создали объект и передали владение в лэйаут. Теперь это забота лэйаута.
+100500
SaZ>Второй случай — вы создали объект на стеке, поместили в лэйаут, и тут же удалили при выходе из скоупа (функции). Тоже всё корректно.
Какой смысл действий в этом случае?
Мёртвый указатель в лейоуте...
Здравствуйте, Shmj, Вы писали:
S>Вот, в QT QObject имеет свою парадигму управления памятью, без использования вумных указателей. Правильно ли это с вашей точки зрения?
Эта парадигма — имеет значение.
При этом, для разработки на Qt, она имеет популярность.
Это совсем не исключает применение других парадигм, например smart-pointers.
В правильном применении — используем каждую парадигму в своём месте.
Здравствуйте, AlexGin, Вы писали:
SaZ>>Второй случай — вы создали объект на стеке, поместили в лэйаут, и тут же удалили при выходе из скоупа (функции). Тоже всё корректно. AG>Какой смысл действий в этом случае? AG>Мёртвый указатель в лейоуте...
Здравствуйте, night beast, Вы писали:
NB>Здравствуйте, AlexGin, Вы писали:
SaZ>>>Второй случай — вы создали объект на стеке, поместили в лэйаут, и тут же удалили при выходе из скоупа (функции). Тоже всё корректно. AG>>Какой смысл действий в этом случае? AG>>Мёртвый указатель в лейоуте...
NB>уберется при вызове деструктора l
Да, но время жизни этого объекта l ограничено функцией: addLabelToLayout — после выхода из этой функции: объект разрушен; указатель адресует мусор
Здравствуйте, Shmj, Вы писали:
A>>Потому, что стандартная библиотека — говно.
S>А обоснование? Ведь ее делают лучшие умы мира можно сказать, а QT всего лишь незначительный коммерческий продукт — один из многих.
Ну вот видишь — ты судишь по авторитетам. Если что-то сделали всемирно известные... умы, значит это что-то хорошее. А я наоборот: смотрю на результат. Если результат говно, значит те, кто его сделал — сам понимаешь кто.
Там же выше есть примеры, в т.ч. QString. Посмотри на него. Через него ты можешь сделать со строкой всё, что тебе надо. Как, собственно, во всех удобных стандартных библиотеках. На этом фоне каким надо быть архитектурным астронавтом, чтобы включать в стандартную библиотеку класс, который нужен ТОЛЬКО для стандартизации.
Здравствуйте, AlexGin, Вы писали:
NB>>уберется при вызове деструктора l AG>Да, но время жизни этого объекта l ограничено функцией: addLabelToLayout — после выхода из этой функции: объект разрушен; указатель адресует мусор
сейчас нет возможности проверить, но по всей логике, после выхода из функции в layout не будет указателя на этот объект.
Здравствуйте, Alekzander, Вы писали:
A>Там же выше есть примеры, в т.ч. QString. Посмотри на него. Через него ты можешь сделать со строкой всё, что тебе надо. Как, собственно, во всех удобных стандартных библиотеках. На этом фоне каким надо быть архитектурным астронавтом, чтобы включать в стандартную библиотеку класс, который нужен ТОЛЬКО для стандартизации.
Если вы проведете опрос среди большого количества C++ разработчиков о том, хотят ли они видеть в стандартной библиотеке C++ один большой класс для работы со строками по типу QString, то вы удивитесь тому, насколько много скажет "нет".
Здравствуйте, AlexGin, Вы писали:
AG>Первый вариант — выглядит вполне корректно и логично (как для C++, так и для Qt).
сейчас для передачи владения в С++ семантика перемещения и только она выглядит логично. А когда вы передаёте голый указатель, то не можете гарантировать, что будет происходить дальше. Не, конечно можно лазить по документациям, но это мартышкин труд.
Это похоже на спор с чистым С. Ты им говоришь, что передавать указатель в С++ идеологически неверно, а они не понимают. Это как же, деды передавали и мы будем.
Здравствуйте, sergii.p, Вы писали:
SP>Это похоже на спор с чистым С. Ты им говоришь, что передавать указатель в С++ идеологически неверно, а они не понимают. Это как же, деды передавали и мы будем.
передавать голый невладеющий указатель вполне нормально
Здравствуйте, sergii.p, Вы писали:
SP>Здравствуйте, AlexGin, Вы писали:
AG>>Первый вариант — выглядит вполне корректно и логично (как для C++, так и для Qt).
SP>сейчас для передачи владения в С++ семантика перемещения и только она выглядит логично.
Но это зависит от задачи.
Например: зачем мне перемещать объект, если он нужен именно эдесь?
Вот пример:
m_pMainWidget = new MainWidget(this);
m_pVBoxLayout->addWidget(m_pMainWidget);
...
m_pMainWidget->setGeometry(...);
SP>А когда вы передаёте голый указатель, то не можете гарантировать, что будет происходить дальше.
Гарантировать, что будет дальше — ни в каком случае не возможно. Даже, если кажется, что от всех ошибок защитился!
SP>Не, конечно можно лазить по документациям, но это мартышкин труд.
Не понял, к чему Вы относите данную фразу?
SP>Это похоже на спор с чистым С. Ты им говоришь, что передавать указатель в С++ идеологически неверно, а они не понимают. Это как же, деды передавали и мы будем.
Идеология — это другое.
Ну передавай ссылку, а не указатель.
Однако, не везде это прокатит: нулевой ссылки, в отличие от Java и .NET, в C++ быть не может.
Здравствуйте, AlexGin, Вы писали:
AG>Но это зависит от задачи. AG>Например: зачем мне перемещать объект, если он нужен именно эдесь?
потому что вы отдали владение Компонент может запросто грохнуть ваш объект или скопировать в другую область памяти. У вас же не возникает вопросов почему здесь UB
std::vector<int> v = {0, 1, 42};
auto& front = v.front();
v.push_back(43);
std::cout << front;
Rust ваш код тоже не пропустит дальше. Это базовая проверка валидности кода. Если она провалена, то можно придумать кучу случаев когда код сломается.
Опять же в Java всё ок. Вот почему у меня и претензии к Qt. Он ласково шепчет, что можешь обо всём забыть и работать как в Java. Но по факту ты по-прежнему в С++. А тут такое беззаботное отношение к владению недопустимо.
AG>Гарантировать, что будет дальше — ни в каком случае не возможно. Даже, если кажется, что от всех ошибок защитился!
можно конечно, если придерживаться простых правил. Core guidline не просто так придумывали. Одно из таких правил — не использовать голые указатели.
SP>>Не, конечно можно лазить по документациям, но это мартышкин труд. AG>Не понял, к чему Вы относите данную фразу?
имел в виду, что эту работу можно было не делать, если бы фукнция была спроектирована как-то так
void addWidget(std::unique_ptr<Widget> w);
Здесь не нужна документация чтобы понять, что владение теряется. Сигнатура фукнции должна сама документировать, что происходит внутри.
AG>Ну передавай ссылку, а не указатель. AG>Однако, не везде это прокатит: нулевой ссылки, в отличие от Java и .NET, в C++ быть не может.
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, night beast, Вы писали:
NB>>Здравствуйте, AlexGin, Вы писали:
SaZ>>>>Второй случай — вы создали объект на стеке, поместили в лэйаут, и тут же удалили при выходе из скоупа (функции). Тоже всё корректно. AG>>>Какой смысл действий в этом случае? AG>>>Мёртвый указатель в лейоуте...
NB>>уберется при вызове деструктора l AG>Да, но время жизни этого объекта l ограничено функцией: addLabelToLayout — после выхода из этой функции: объект разрушен; указатель адресует мусор
Какой указатель? Какой мусор? Объект будет удалён сразу по выходу из функции. Если в Qt удаляется дочерний объект, то он всегда оповещает об этом родителя. Тут не важно как он был создан, в куче или на стеке.
Здравствуйте, night beast, Вы писали:
NB>Здравствуйте, SaZ, Вы писали:
SaZ>>То что в stl есть только unique/shared вовсе не значит что нельзя использовать другие парадигмы. Лично мне для GUI очень нравится подход — создал, указал куда всунуть (парент), забыл. И всё само работает.
NB>безотносительно Qt мне нравится принцип питона: "явное лучше, чем неявное" NB>то есть я смотря только на код должен не влезая во внутреннее устройство понимать, что происходит с владением объекта
Всегда надо понимать что вы делаете. Вам концепцию шаред поинтеров тоже же пришлось изучать — как минимум прочитать доку и понять что такое счётчик ссылок. Так же и в кутэ, один раз читаем доку про их модель владения, понимаем что вместо счётчика ссылок тут надо указать экземпляр родитель и всё, дальше всё явно. Объект живёт, пока мы его не удалим или пока не удалим его родителя.
Здравствуйте, SaZ, Вы писали:
NB>>безотносительно Qt мне нравится принцип питона: "явное лучше, чем неявное" NB>>то есть я смотря только на код должен не влезая во внутреннее устройство понимать, что происходит с владением объекта
SaZ>Всегда надо понимать что вы делаете. Вам концепцию шаред поинтеров тоже же пришлось изучать — как минимум прочитать доку и понять что такое счётчик ссылок.
ты не понял основной мысли.
речь не о концепциях, а о когнитивной нагрузке, испытываемой при чтении произвольного фрагмента пользовательского кода
есть две функции:
void add(Object* a);
void add(own<Object*> a);
обе функции делают одно и то же (забирают владение у вызывающего кода)
только во втором случае ты об этом знаешь, а в первом тебе нужно представлять какие процессы происходят в add
SaZ>Так же и в кутэ, один раз читаем доку про их модель владения, понимаем что вместо счётчика ссылок тут надо указать экземпляр родитель и всё, дальше всё явно. Объект живёт, пока мы его не удалим или пока не удалим его родителя.
проблема в том, что ты нифига не знаешь, захватывает addWidget владение, или нет
Здравствуйте, Shmj, Вы писали:
S>Вот, в QT QObject имеет свою парадигму управления памятью, без использования вумных указателей. Правильно ли это с вашей точки зрения?
Как минимум опасность есть от функций, которые принимают несколько голых владеющих указателей.
doSomething(new QLabel("1"), new QLabel("2"));
Если new выбросит bad_alloc или один из конструкторов, то есть вероятность возникновения утечки.
Конкретно, если исключение будет выкинуто вторым по порядку вызова new, то результат первого new утечет.
Какой new будет вычисляться первым, а какой вторым — по стандарту нет гарантии на порядок вычисления аргументов функции.
Здравствуйте, night beast, Вы писали:
NB>... NB>проблема в том, что ты нифига не знаешь, захватывает addWidget владение, или нет
Можно, пожалуйста, пример, где в кутэ не захватывается владение?
Мой основной посыл в том, что местами это непривычно (впрочем есть и определённый оверхед), но плюсы такого подхода разительно перевешивают минусы. В контексте программирования на этом фреймворке, разумеется.
Здравствуйте, sergii.p, Вы писали:
SP>потому что вы отдали владение Компонент может запросто грохнуть ваш объект или скопировать в другую область памяти.
Это аргументация уровня: "shared_ptr может не удалить объект". Навреное, в теории может, если это какой-то сильно кривой shared_ptr.
В Qt стандартный паттерн: дети живут пока родители живут. Понять проще, чем shared_ptr.
Здравствуйте, SaZ, Вы писали:
NB>>проблема в том, что ты нифига не знаешь, захватывает addWidget владение, или нет
SaZ>Можно, пожалуйста, пример, где в кутэ не захватывается владение?
да не проблема
открой хидеры и смотри функции, которые принимают указатели. по названию пытайся понять, захватывают или нет
например:
void QWidget::stackUnder(QWidget* w);
SaZ>Мой основной посыл в том, что местами это непривычно (впрочем есть и определённый оверхед), но плюсы такого подхода разительно перевешивают минусы. В контексте программирования на этом фреймворке, разумеется.
мой основной посыл не в плюсах или в минусах кютешного подхода (я об этом явно указал в сообщении
), а в том что код должен быть понятен без дополнительного знания контекста
Вот в том и основная проблема стиля с голыми указателями, не понятно, когда функция забирает владение, а когда — нет.
Например, в MFC также была куча функций с голыми указателями (CWnd::SetParent(CWnd*)), но не припомню чтобы там забиралось владение.
Т.е. стиль кодирования, когда голый указатель (возможно с const) выполняет роль опциональной ссылки с поддержкой значения nullptr, но никогда не отвечает за владение — это норм имхо.
Здравствуйте, qaz77, Вы писали:
Q>Здравствуйте, Shmj, Вы писали:
S>>Вот, в QT QObject имеет свою парадигму управления памятью, без использования вумных указателей. Правильно ли это с вашей точки зрения?
Q>Как минимум опасность есть от функций, которые принимают несколько голых владеющих указателей.
Q>
Q>doSomething(new QLabel("1"), new QLabel("2"));
Q>
doSomething(new QLabel(this, "1"), new QLabel(this, "2"));
Так утечки не будет.
Все Qt объекты умеют получать родителя первым аргументом, именно для решения этой проблемы.
Здравствуйте, Shmj, Вы писали:
S>Вот, в QT QObject имеет свою парадигму управления памятью, без использования вумных указателей. Правильно ли это с вашей точки зрения?
- Гиви, ты памыдоры лубиш?
— Есть лублу, а так — нэт!
Здравствуйте, so5team, Вы писали:
A>>Там же выше есть примеры, в т.ч. QString. Посмотри на него. Через него ты можешь сделать со строкой всё, что тебе надо. Как, собственно, во всех удобных стандартных библиотеках. На этом фоне каким надо быть архитектурным астронавтом, чтобы включать в стандартную библиотеку класс, который нужен ТОЛЬКО для стандартизации.
S>Если вы проведете опрос среди большого количества C++ разработчиков о том, хотят ли они видеть в стандартной библиотеке C++ один большой класс для работы со строками по типу QString, то вы удивитесь тому, насколько много скажет "нет".
Здравствуйте, Alekzander, Вы писали:
S>>Если вы проведете опрос среди большого количества C++ разработчиков о том, хотят ли они видеть в стандартной библиотеке C++ один большой класс для работы со строками по типу QString, то вы удивитесь тому, насколько много скажет "нет".
A>Ага, знаем. Нет спроса — нет привоза.
А как-то вменяемо свою точку зрения озвучить можно или мозгов хватает только на эмоции в стиле "все, что мне не нравится -- говно"?
Тот же QString выглядит как god object, в который впихнули все что могли, потому что кому-то это может понадобиться. Вот, скажем, QString::arg, зачем он именно в классе строки, если такую функциональность удобнее было бы иметь в той части библиотеки, которая отвечает за форматирование (по типу fmt::format, std::format, Boost::format), чтобы результат форматирования можно было хоть в строку, хоть в ostream, хоть в memory buffer отправлять.
Да, можно понять ленивые задницы пользователей, которые хотят из коробки все и сразу. Но все равно непонятно, зачем иметь leftJustified, setNum, simplified или localeAwareCompare прямо в классе "строка" и почему нельзя все это вынести в свободные функции? С этой точки зрения QString хорошо спроектированным классом не выглядит от слова совсем. И включать такое в стандартную библиотеку языка, на котором пишется далеко не только GUI, еще более ужасная идея, чем иметь там std::basic_string.
Здравствуйте, qaz77, Вы писали:
Q>До выполнения тела функции doSomething2 дело не доходит и результат new утекает.
doSomething2 тут не при чем. После этого выражения
new QLabel(this, "1")
объект QLabel уже в списке дочерних у объекта this и будет удален при удалении this (что и произойдет при раскручивании стэка при выбросе исключения).
Здравствуйте, so5team, Вы писали:
S>>>Если вы проведете опрос среди большого количества C++ разработчиков о том, хотят ли они видеть в стандартной библиотеке C++ один большой класс для работы со строками по типу QString, то вы удивитесь тому, насколько много скажет "нет".
A>>Ага, знаем. Нет спроса — нет привоза.
S>А как-то вменяемо свою точку зрения озвучить можно или мозгов хватает только на эмоции в стиле "все, что мне не нравится -- говно"?
А ты думаешь, много желания с тобой, таким вежливым, вступать в долгие разговоры? Ладно, объясню, но только один раз. И спорить не буду.
Чтобы планировать эксперименты, нужно уметь хотя бы немного пользоваться головой. Дурак, он ведь как: проведёт опрос среди пользователей Интернета, и опрос покажет, что 100% опрошенных пользуются Интернетом. И ничего его не смутит.
. Хотя автор пишет, что он никаких опросов проводить не собирался, а просто у него пригорело (хорошо его понимаю). Из 16 опрошенных 14 поддержали автора в том, что C++ упорот, и он не зря ушёл в C#. Вот это и есть честный ответ, чего хотят разработчики. А если возьмём и проведём опрос среди "большого количества C++ разработчиков" (то есть, в данном случае, тех двоих, которые остались на C++), он, конечно же, покажет, что C++ прекрасен, стандартная библиотека восхитительна, а менять ничего не надо. Такие люди остались, что на прикладной код (для написания которого гораздо лучше подходит QString) им наплевать, им подавай извращения
, за которые в нормальных местах просто увольняют.
При этом, заметь, что RSDN это место, где тусуют мамонты. Очень приверженные старым привычкам. И даже если *тут* счёт 14:2, то представь себе, что говорят там, где тусит молодёжь (я это знаю, потому что бываю).
Короче, ограничься лучше профильным форумом, где на твой сиплюсплюсный ум есть спрос. Социология и опросы просто не твоё.
Здравствуйте, Alekzander, Вы писали:
A>Дурак, он ведь как: проведёт опрос среди пользователей Интернета, и опрос покажет, что 100% опрошенных пользуются Интернетом. И ничего его не смутит.
A>Из 16 опрошенных 14 поддержали автора в том, что C++ упорот, и он не зря ушёл в C#.
A>Социология и опросы просто не твоё.
Вообще-то я вел речь о чисто технической стороне дела. К QString есть претензии, которые станут фатальными, если попытаться добавить такой класс в стандарт. Вы же решили перевести беседу в сторону "сам дурак". Ну OK. Мне тут даже ничего добавлять не придется.
Здравствуйте, Skorodum, Вы писали:
Q>>До выполнения тела функции doSomething2 дело не доходит и результат new утекает. S>doSomething2 тут не при чем. После этого выражения S>
S>new QLabel(this, "1")
S>объект QLabel уже в списке дочерних у объекта this и будет удален при удалении this (что и произойдет при раскручивании стэка при выбросе исключения).
Подождите, подождите. Вот у нас есть выражение:
f(new A(), g());
Это выражение может вычисляться следующим образом:
* выполняется new A() и полученный указатель компилятором где-то сохраняется;
* выполняется вызов g() и из g() вылетает исключение.
Вы хотите сказать, что в этом случае компилятор выполнит откат операции new A()?
Здравствуйте, so5team, Вы писали:
S>Вы хотите сказать, что в этом случае компилятор выполнит откат операции new A()?
откат -- нет. передача владения произойдет в конструкторе А
поэтому А будет жить пока не умрет родитель (this)
но у этого объекта можно будет сменить родителя в doSomething
да, не очень очевидно, но без утечек.
Здравствуйте, night beast, Вы писали:
S>>Вы хотите сказать, что в этом случае компилятор выполнит откат операции new A()?
NB>откат -- нет. передача владения произойдет в конструкторе А NB>поэтому А будет жить пока не умрет родитель (this) NB>но у этого объекта можно будет сменить родителя в doSomething NB>да, не очень очевидно, но без утечек.
Ну т.е. если у нас this -- это какой-то QObject, то конструкция new QLabel(this, "1") создаст QLabel и добавит его в список дочерних для this. При этом указатель на QLabel потеряется, т.к. его передача куда-то не состоится из-за исключения.
И этот QLabel будет жить до тех пор пока живет this.
Но this не обязательно будет удален в результате исключения, как это было сказано: "будет удален при удалении this (что и произойдет при раскручивании стэка при выбросе исключения)"
Т.е. если this переживет исключение, то QLabel останется существовать и когда-то умрет. Но до тех пор будет "фантомом", т.к. к нему никто, по сути, доступа не будет иметь и ничего полезного с ним не сделает.
Здравствуйте, so5team, Вы писали:
S>Ну т.е. если у нас this -- это какой-то QObject, то конструкция new QLabel(this, "1") создаст QLabel и добавит его в список дочерних для this. При этом указатель на QLabel потеряется, т.к. его передача куда-то не состоится из-за исключения.
не совсем. насколько помню, раньше родителем для виджета произвольный QObject быть не мог, только QWidget.
S>И этот QLabel будет жить до тех пор пока живет this. S>Но this не обязательно будет удален в результате исключения, как это было сказано: "будет удален при удалении this (что и произойдет при раскручивании стэка при выбросе исключения)"
если предположить что это все происходит в конструкторе, то будет )
S>Т.е. если this переживет исключение, то QLabel останется существовать и когда-то умрет. Но до тех пор будет "фантомом", т.к. к нему никто, по сути, доступа не будет иметь и ничего полезного с ним не сделает.
доступ к нему получить можно, но суть приблизительно такая, да
поэтому в качестве родителя надо подсовывать не произвольный QObject, а что-то более подходящее
Здравствуйте, so5team, Вы писали:
NB>>доступ к нему получить можно, но суть приблизительно такая, да S>Ок, теперь картинка соответствует тому, что было у меня в памяти.
там чуть подредактировал
если все это происходит в конструкторе, то соответственно, и this почистится
Здравствуйте, so5team, Вы писали:
S>Т.е. если this переживет исключение, то QLabel останется существовать и когда-то умрет. Но до тех пор будет "фантомом", т.к. к нему никто, по сути, доступа не будет иметь и ничего полезного с ним не сделает.
Да, но для этого надо написать сильно не каноничный код. Если есть обработка исключений, которая позволяет this жить дальше, то ничто не мешает удалить ставшим ненужным объект.
Главное, что по умолчанию утечки не будет.
Здравствуйте, night beast, Вы писали:
NB>откат -- нет. передача владения произойдет в конструкторе А
так не для всего parent задают в конструкторе
Возьмём функцию QLayout::replaceWidget(QWidget* from, QWidget* to) и представим такой код
layout->replaceWidget(findWidgetByDesc("test"), new QWidget());
допустим что findWidgetByDesc бросит исключение в случае если не найлен. Мы уже как бы создали widget, к паренту привязать не успели и улетели с исключением.
Здравствуйте, sergii.p, Вы писали:
SP>допустим что findWidgetByDesc бросит исключение в случае если не найлен. Мы уже как бы создали widget, к паренту привязать не успели и улетели с исключением.
Вы изменили пример. Добавьте this в конструктор QWidget и утечки не будет.
Здравствуйте, night beast, Вы писали:
NB>Здравствуйте, SaZ, Вы писали:
NB>>>проблема в том, что ты нифига не знаешь, захватывает addWidget владение, или нет
SaZ>>Можно, пожалуйста, пример, где в кутэ не захватывается владение?
NB>да не проблема NB>открой хидеры и смотри функции, которые принимают указатели. по названию пытайся понять, захватывают или нет NB>например: NB>
NB>void QWidget::stackUnder(QWidget* w);
NB>
SaZ>>Мой основной посыл в том, что местами это непривычно (впрочем есть и определённый оверхед), но плюсы такого подхода разительно перевешивают минусы. В контексте программирования на этом фреймворке, разумеется.
NB>мой основной посыл не в плюсах или в минусах кютешного подхода (я об этом явно указал в сообщении
), а в том что код должен быть понятен без дополнительного знания контекста
Наверное да. Тут как с цмейком — надо привыкнуть к инструменту.
Я задумался, походу действительно надо читать документацию и запоминать. Просто лично у меня с этим проблем не возникало, может просто за счёт большого стажа с кутэ.
Когда я пишу компоненты, то обычно проверяю — если парент у того что передали в setXXXX присутствует — я просто сохраняю указатель в QPointer. Если парента нет — то беру себе владение.
Здравствуйте, Skorodum, Вы писали:
S>Стандартная библиотека не поддерживает(ла) COW...
Повезло с этим имхо. Беда это в многопоточке. В лучшем случае мьютекс, где его не ждёшь. Корова — кутешечкин фейл имхо. Одна из трудноисправимых ошибок дизайна.
Здравствуйте, andyp, Вы писали:
A>Повезло с этим имхо. Беда это в многопоточке. В лучшем случае мьютекс, где его не ждёшь. Корова — кутешечкин фейл имхо. Одна из трудноисправимых ошибок дизайна.
В Qt потоко-безопастность классов хорошо документирована: Reentrancy and Thread-Safety
Если для передачи данных между потоками используются сигналы и слоты и данные передаются по значению, то данные копируются и дополнительно явно ничего делать не надо.
Здравствуйте, Skorodum, Вы писали:
S>Если для передачи данных между потоками используются сигналы и слоты и данные передаются по значению, то данные копируются и дополнительно явно ничего делать не надо.
Что ты под копированием данных для объектов с COW имеешь в виду? Звучит так же мутно, как и qtшная документация Делается ли deep или shallow copy и в каком потоке это делается, если emit сигнала и вызов слота происходят в разных потоках? Есть ли гарантия, что это делается единообразно во всех релизах Qt начиная с N.K? Я не нашел внятного ответа на этот вопрос в свое время и всегда детачил копию контейнера перед тем как ее в сигнал засовывать. Ну это пока еще использовал эти контейнеры вообще.
Здравствуйте, andyp, Вы писали:
A>Что ты под копированием данных для объектов с COW имеешь в виду? Звучит так же мутно, как и qtшная документация Делается ли deep или shallow copy и в каком потоке это делается, если emit сигнала и вызов слота происходят в разных потоках? Есть ли гарантия, что это делается единообразно во всех релизах Qt начиная с N.K? Я не нашел внятного ответа на этот вопрос в свое время и всегда детачил копию контейнера перед тем как ее в сигнал засовывать. Ну это пока еще использовал эти контейнеры вообще.
Здравствуйте, Alekzander, Вы писали:
vsb>>2. Куча классов, дублирующих стандартную библиотеку. QString, QList и подобное.
A>Потому, что стандартная библиотека — говно.
Здравствуйте, Marty, Вы писали:
vsb>>>2. Куча классов, дублирующих стандартную библиотеку. QString, QList и подобное.
A>>Потому, что стандартная библиотека — говно.
M>Нормальная библиотека. Всё на ней делаю
А с какими ещё библиотеками общего назначения ты работал, если не секрет? С чем сравниваешь? Работал с Standard Libraries? (Если кто-то скажет, что неспортивно сравнивать Object-иерархию для виртуальной машины и крестики, я целую пачку майкрософтовских библиотек на C++ могу вспомнить, которые обладают тем же (вменяемым) дизайном).
Здравствуйте, Alekzander, Вы писали:
A>>>Потому, что стандартная библиотека — говно.
M>>Нормальная библиотека. Всё на ней делаю
A>А с какими ещё библиотеками общего назначения ты работал, если не секрет? С чем сравниваешь?
дот нетом не балуюсь. Как-то давно, лет 15 назад, пописывал — так себе. На джаве пописывал — тоже такое ещё
A>(Если кто-то скажет, что неспортивно сравнивать Object-иерархию для виртуальной машины и крестики, я целую пачку майкрософтовских библиотек на C++ могу вспомнить, которые обладают тем же (вменяемым) дизайном).
Здравствуйте, Marty, Вы писали:
A>>А с какими ещё библиотеками общего назначения ты работал, если не секрет? С чем сравниваешь?
M>wxWidgets, Qt, MFC, WTL. Boost.
И тебе правда норм писать .push_back() после .Add()? Или std::chrono::system_clock::now().time_since_epoch().count() после CTime::GetCurrentTime()?
Здравствуйте, vsb, Вы писали:
S>>Вот, в QT QObject имеет свою парадигму управления памятью, без использования вумных указателей. Правильно ли это с вашей точки зрения? vsb>С моей точки зрения Qt это абоминация, если смотреть на неё, как на С++ библиотеку.
Просто устарела слегка...
Вопрос, наверно, в следующем — может ли позволить себе осовремениться?
Бо не на всех платформах пока мест поддержка последних стандартов плюсов.
Здравствуйте, vdimas, Вы писали:
V>Вопрос, наверно, в следующем — может ли позволить себе осовремениться? V>Бо не на всех платформах пока мест поддержка последних стандартов плюсов.
Здравствуйте, Shmj, Вы писали:
V>>Вопрос, наверно, в следующем — может ли позволить себе осовремениться? V>>Бо не на всех платформах пока мест поддержка последних стандартов плюсов. S>Вроде 11 стандарт то есть абсолютно везде.
Здравствуйте, Marty, Вы писали:
M>>>wxWidgets, Qt, MFC, WTL. Boost.
A>>И тебе правда норм писать .push_back() после .Add()?
M>Нормас. Автокомплит рулит
Ты слишком буквально воспринял слово "писать" . "Писать" это для меня ещё и думать, как потом это кто-то будет читать.
M>А Add — он куда добавляет, в начало, в конец, или ещё куда-то?
Добавляют всегда в конец. В начало или ещё куда-то вставляют. Это, кстати, неплохой пример астронавтики, потому что асимметрия этих операций со стороны пользователя очевидна. Что не помешало степанову сделать их симметричными. Если бы он проектировал коробоку передач, он бы, чего доброго, сделал пять вперёд и пять назад. Он же сам про это рассказывал — как он додумался алгоритмы деинкапсулировать. Цель, мол, была сделать так, чтобы программист мог легко и просто писать свои алгоритмы. То, что типичному программисту писать свою велосипедную сортировку за всё карьеру может не понадобиться ни разу, а вот вызывать ему станет неудобно, и что большинство программистов заплатит неудобством за удобство крайне небольшого меньшинства, на это ему было наплевать. Поэтому все прикладники и разбежались.
A>>Или std::chrono::system_clock::now().time_since_epoch().count() после CTime::GetCurrentTime()?
M>Хроно не использовал как-то, не было нужны. Да и не везде он есть, так что я по старинке
По старинке это ::time(null)? Ну ведь это же нездоровая фигня. В конце концов, для чего ещё нужна стандартная библиотека, как не для простоты записи таких вещей, как GetCurrentTime().Format("%H:%M").
. "Писать" это для меня ещё и думать, как потом это кто-то будет читать.