Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 46
Без форматирования код почти нечитаем. Есть тег для кода.
Ну, т.е. вся статья сводится к тому, что QScopedPointer не производит отключение сигналов, ок.
А разве сигналы не отключаются в ~QObject()?
Отключаются, но тут вопрос в последовательности:
При использовании QObject(parent) перед удалением родителя сначала происходит отключение всех детей, потом уже их удаление.
В случае QScopedPointer он просто пытается удалить, сокет в своем деструкторе кладет сообщение, мол, состояние поменялось, только после этого происходит удаление.
Видимо, перед удалением QObject он сначала обрабатывает деструктор, только потом — пришедшие сообщения. Хотя это странно, вдруг я уже что-то удалил, а потом попытаюсь без задней мысли использовать?
При использовании QObject(parent) перед удалением родителя сначала происходит отключение всех детей, потом уже их удаление.
В случае QScopedPointer он просто пытается удалить, сокет в своем деструкторе кладет сообщение, мол, состояние поменялось, только после этого происходит удаление.
Видимо, перед удалением QObject он сначала обрабатывает деструктор, только потом — пришедшие сообщения. Хотя это странно, вдруг я уже что-то удалил, а потом попытаюсь без задней мысли использовать?
Никак не могу определиться, режет ли мне слух словосочетание «смарт-поинтеры» или «умные указатели».
Отформатируйте, пожалуйста, исходники. Читать невозможно.
А где особенности то? Вполне нормальное и ожидаемое поведение.
Хоть б написали, что это за «смарт-поинтеры» такие, и зачем они нужны…
Это основы. Если программируете на С++, то об умных указателях нужно обязательно знать. Начните вот отсюда. А если читаете на буржуинском, то обязательно поройтесь в доках буста, загляните на С++ FAQs Lite в раздел container classes и почитайте ответы на вопросы в stackoverflow.
Если это не встроенно в язык или стандартную библиотеку, как это может быть основами? Бустом не пользуюсь, а вот Qt люблю.
auto_ptr — это пример смарт-поинтера, и он встроен в стандартную библиотеку. Ну и вообще, писать на С++ в 2011 году и не знать, что такое смарт-поинтеры — это даже как-то неприлично, что-ли.
Это основы, поверьте. Буст давно стал инкубатором для std::, смартпойнтеры уже введены в стандарт. Займитесь их изучением, разберитесь в RAII и т.д. Эти вопросы — база, которую спрашивают на любом относительно серьезном собеседовании. Paul выше назвал auto_ptr — один из вопросов — это о его семантике владения и что происходит при присваивании одного auto_ptr другому. Разберитесь в этом, сразу поймете почему понадобились другие пойнтеры. Еще один из вопросов — почему auto_ptr устроен именно так и для чего он предназначается. Если человек не в состоянии ответить, не понятно чем он занимался последние годы — это и тренд, и тема, охватывающая огромное количество вещей и техник, позволяющих писать более устойчивый код, и давно уже просто правила хорошего тона. К тому же старые как бивни мамонта. Я где-то с 2004 года знаю об этих указателях. В общем, не поленитесь, уделите время.
встроено, в tr1 и С++0x, особенно радует 0x с его std::unique_ptr
> Это основы. Если программируете на С++, то об умных указателях нужно обязательно знать. Начните вот отсюда.
Там кусок обсуждения, без всякой теории об объектах владения (ресурсах) и объектах-владельцев. Соответственно, ни одного внятного примера.
Пишу из 2020 года — до сих пор на русском языке нет нормального, полноценного описания теории умных указателей и практики их использования. Только по кускам, только по крупицам надо собирать осколки знаний. А прошло уже 9 лет с момента публикации.
Там кусок обсуждения, без всякой теории об объектах владения (ресурсах) и объектах-владельцев. Соответственно, ни одного внятного примера.
Пишу из 2020 года — до сих пор на русском языке нет нормального, полноценного описания теории умных указателей и практики их использования. Только по кускам, только по крупицам надо собирать осколки знаний. А прошло уже 9 лет с момента публикации.
Автор, без исходников статья почти ни о чем. Отформатируйте хотя бы сурцы.
Technical Report 1 не поддерживает scoped_ptr proof
Если в проекте юзается такая гигантская либа как QT, то подключайте уже и буст и пользуйтесь scoped_ptr из него. В QT-шной версии пойнтера есть как минимум одна вещь, которая ведет к багам — operator bool(). Ну и синтаксис scoped_ptr компактнее.
И да здравствует секс со сборкой в винде!
Я не юзаю QT, но помню читал в официальном руководстве, что буст можно смешивать с QT, в сети не раз видел примеры. К тому же чему там в пойнтерах конфликтовать?
Смартпоинтеры полностью в хедерах, в чем проблема со сборкой в винде?
Речь не о конкретной части boost, а о библиотеке в целом. Втыкать даже фрагмент ради функционала, который уже есть, и который не хуже не лучше, ИМХО не вижу смысла.
Врядли если появится буст, то будут юзать только пойнтеры. По моему опыту, он постепенно завоюет позиции на проекте. Обычно то, что аргумент «зачем на буст только ради хххх» не слишком хорош понимаешь только спусть некоторое время. Это можно сказать каждый раз, когда возникает идея что-то заюзать из него. А в целом, после, скажем, полугода или года использования оказывается, что заюзаны и tuples, и bind, и format, и regex, и пойнтеры, и function, и any, и lexical catst и т.д. Отсутствие буста могло как минимум породить бесчсиленное множество велосипедов. Ну и Qt пойнтеры бажные, я ниже писал об этом. Буст не тащит за собой dll, не создает страшных оверхедов, менее бажный, убережет от велосипедов, тоже кросплатформенный. Почему не заюзать?
Так в том то и дело же, что хуже. Читайте выше про operator bool(). А если не хочется тащить весь boost, есть bcp.
А в чём там проблема?
Вот здесь самя хорошая статья по теме. Там очень подробно все расписано. Вкратце, из-за operator bool становится возможной компиляция логически бессмысленного кода:
Вот это все скомпилится, но смысла особого не имеет. Если юзать safe bool, то такое не случится. Конечно, подобный код никто не напишет будучи в здравом уме, но он может появиться по невинимательности и компилятор его не отловит. Сама по себе идиома safe bool выглядит как костыль, поэтому в С++ 0х ввели explicit conversion operators.
struct test
{
opearator bool() const {rreturn true;}
};
test instance;
int ivar = instance;
cout << test;
Вот это все скомпилится, но смысла особого не имеет. Если юзать safe bool, то такое не случится. Конечно, подобный код никто не напишет будучи в здравом уме, но он может появиться по невинимательности и компилятор его не отловит. Сама по себе идиома safe bool выглядит как костыль, поэтому в С++ 0х ввели explicit conversion operators.
Перетрудился. cout << instance; конечно же.
Лучше перегружать оператор void *
(в добавок к ниженаписанному).
(в добавок к ниженаписанному).
можно будет написать
test instance;
delete instance;
Это еще веселее :)
test instance;
delete instance;
Это еще веселее :)
Если следовать везде RAII, то таких delete нигде не будет. И да, мы тут о Smart Pointer, какие delete :)
Ну так и инту присваить смартптр это бред. Какой-нить джуниор возьмет и удалит. Вон вверху человек, котороый вообще никогда не слышал о смартптр. Вообще, я согласен, это паранойя. И даже большая, чем по повду operator bool. Но если изобрели safe bool, то заем этот void*? Лучше уж safe bool пользоваться.
Тема QWeakPointer'ов не раскрыта.
Перенесите, плиз, в блог Qt. Так при необходимости будет легче найти. Если вдруг кому-то понадобится…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Особенность работы со смарт-поинтерами в Qt