deleteLater вещь хорошая, но она решает симптомы, а не причину. По сути это garbage collection — мы не знаем когда можем удалять объект, так давай те удалим его как-нибудь потом. Хотя признаюсь — сам иногда пользуюсь им.
если говорить о времени выполнения, то аллокация (хоть одного байта) неизвестно сколько времени будет занимать. Неизвестно как сравнивать с линейным кодом без аллокаций.
По поводу рекурсии согласен — можно сделать без нее.
Но вот с weak_ptr тоже не все в порядке — недавно была заметка на reddit, о том что weak_ptr не позволяют освободить память под объектом, если объект был создан с помощью make_shared (что активно советуют делать). И если объекты большие то мы получаем почти классический garbage collection — объекта уже нет, а память под ним освободится непонятно когда.
void Button::DoClick()
{
// do some stuff
...
// emit signal
click.invoke();
// do some other stuff
// здесь this может быть удален каким-то обработчиком click
// и мы упадем
...
}
Что бы отловить проблему и понять кто удаляет нас можно написать:
void Button::DoClick()
{
// мы должны жить до конца функции
rsl::track::pointer<const Button, assert_on_dangle> guard(this);
// do some stuff
...
// emit signal
click.invoke();
// do some other stuff
// здесь this может быть удален каким-то обработчиком click
// и мы упадем
...
}
Вы какими средствами пользуетсь для решения подобных проблем?
Как уточнял коллега выше — shared_ptr не панацея.
Полностью согласен с обоими утверждниями.
Возможно такие указатели были бы полезны только в режиме отладки, как например сделано с итераторами в MS C++, когда указывая нужный DEBUG_LEVEL можно получать кучу ошибок времени исполнения при неправильном использовании итератором.
Когда такое только завезли в MS C++, реально посыпались ошибки в нескольких местах.
А в релизном режиме все превращается обратно в голые быстрые указатели без проверок.
Не читал, спасибо за ссылку. Если вы его читали, вопрос, как решать проблему с висячими ссылками и почему нет ничего подобного в стандартной библиотеке?
По поводу сборки мусора, вы же конечно понимаете, что не удалять объект пока на него есть хотя бы одна ссылка и занулять указатели (или еще как-то реагировать) при удалении объекта — это две большие разницы: о)
Если вы программируете на С++, то понятие dangling pointer вам должно быть знакомо. Коротко — в С++ нет средств для отлова ситуаций, когда у нас есть указатель на удаленный объект.
Подскажите пожалуйста, как можно «расширять» Appium?
Например, у меня есть библиотека кастомных контролов под windows, могу ли я для этих контролов реализовать методы доступа к их кастомному состоянию и специфичные для них воздействия?
Жалко только, что QAbstractProxyModel слишком «абстрактный».
Если он предназначен для пересортировки и фильтрации исходной модели, почему бы не дать опциональную возможность запоминать перестановку строк и их видимость.
А так, приходится эти маппинги из исходной модели в изменённую каждый раз реализовывать заново (ну или делать свой базовый класс).
Да… похоже мульён записей обрабатывать QML будет тяжело.
Еще в QML есть одна проблема (или достоинство) JS — слабо-типизированный язык — компилятор почти не следит за корректностью типов.
Эта же проблема есть в Model/View framework — все данные идут через QVariant — полностью обезличивая их на этапе компиляции.
Да, в последнее время стало легко смешивать десктопные виджеты и QML-ные.
Я решал задачи для инженерных приложений, там большие объемы данных нужно отображать, так что производительность — необходимое условие.
Подскажите, содержимое QML контролов можно выводить на печать или экспортировать как изображение в файл?
Спасибо, статья действительно полезная.
Сам, в своё время, пытался разбираться в системе MSBuild для этого.
Ничего путного не нашёл в сети — делал по аналогии с примерами.
deleteLater вещь хорошая, но она решает симптомы, а не причину. По сути это garbage collection — мы не знаем когда можем удалять объект, так давай те удалим его как-нибудь потом. Хотя признаюсь — сам иногда пользуюсь им.
Но вот с weak_ptr тоже не все в порядке — недавно была заметка на reddit, о том что weak_ptr не позволяют освободить память под объектом, если объект был создан с помощью make_shared (что активно советуют делать). И если объекты большие то мы получаем почти классический garbage collection — объекта уже нет, а память под ним освободится непонятно когда.
Что бы отловить проблему и понять кто удаляет нас можно написать:
Вы какими средствами пользуетсь для решения подобных проблем?
Как уточнял коллега выше — shared_ptr не панацея.
Возможно такие указатели были бы полезны только в режиме отладки, как например сделано с итераторами в MS C++, когда указывая нужный DEBUG_LEVEL можно получать кучу ошибок времени исполнения при неправильном использовании итератором.
Когда такое только завезли в MS C++, реально посыпались ошибки в нескольких местах.
А в релизном режиме все превращается обратно в голые быстрые указатели без проверок.
А вот по поводу плюшек верно. И одной из таких плюшек явно не хватает.
По поводу сборки мусора, вы же конечно понимаете, что не удалять объект пока на него есть хотя бы одна ссылка и занулять указатели (или еще как-то реагировать) при удалении объекта — это две большие разницы: о)
Правда некоторые примеры не работают
Еще интересует транслятор QML в C++, можно немного подробнее.
Например, у меня есть библиотека кастомных контролов под windows, могу ли я для этих контролов реализовать методы доступа к их кастомному состоянию и специфичные для них воздействия?
Жалко только, что QAbstractProxyModel слишком «абстрактный».
Если он предназначен для пересортировки и фильтрации исходной модели, почему бы не дать опциональную возможность запоминать перестановку строк и их видимость.
А так, приходится эти маппинги из исходной модели в изменённую каждый раз реализовывать заново (ну или делать свой базовый класс).
Обработка данных — это обычно сортировка или фильтрация, где перебираются все данные.
Гонять туда-сюда данные через QVariant и JS — это пока не для инженерных приложений, которыми я занимаюсь.
А вот оживить приложение анимациями используя стандартные Qt items widgets почти невозможно. По крайней мере я не знаю как.
Еще в QML есть одна проблема (или достоинство) JS — слабо-типизированный язык — компилятор почти не следит за корректностью типов.
Эта же проблема есть в Model/View framework — все данные идут через QVariant — полностью обезличивая их на этапе компиляции.
Я решал задачи для инженерных приложений, там большие объемы данных нужно отображать, так что производительность — необходимое условие.
Подскажите, содержимое QML контролов можно выводить на печать или экспортировать как изображение в файл?
Сам, в своё время, пытался разбираться в системе MSBuild для этого.
Ничего путного не нашёл в сети — делал по аналогии с примерами.