Здравствуйте, 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, то вы удивитесь тому, насколько много скажет "нет".
