Здравствуйте, 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? Я не нашел внятного ответа на этот вопрос в свое время и всегда детачил копию контейнера перед тем как ее в сигнал засовывать. Ну это пока еще использовал эти контейнеры вообще.
Ладно, объясню, но только один раз. И спорить не буду.
Делается ли deep или shallow copy и в каком потоке это делается, если emit сигнала и вызов слота происходят в разных потоках? Есть ли гарантия, что это делается единообразно во всех релизах Qt начиная с N.K? Я не нашел внятного ответа на этот вопрос в свое время и всегда детачил копию контейнера перед тем как ее в сигнал засовывать. Ну это пока еще использовал эти контейнеры вообще.
