Russian Qt Forum
Март 28, 2024, 21:35 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: 1 [2] 3 4 5   Вниз
  Печать  
Автор Тема: Ненулевые указатели  (Прочитано 28923 раз)
ViTech
Гипер активный житель
*****
Offline Offline

Сообщений: 858



Просмотр профиля
« Ответ #15 : Ноябрь 12, 2019, 16:56 »

Функции отдали во владение объект, сказали делай с ним что хочешь. Выше по стеку этот объект никому не нужен.
Только функции решать, что сделать с этим объектом. Если нужно отдать дальше, то она не будет его удалять.

Кого мы пытаемся ограничить этим функционалом, писателя функции? Улыбающийся

С точки зрения вызывающей функции да, неважно, что потом произойдёт с этим указателем, раз уж отдали владение объектом. Тут нужно выяснить, что в вызываемой функции будут делать с этим указателем. Запрет на release мне тоже не очень понятен: если можно перемещать указатель, то объект можно удалить раньше времени и без release/reset, переместив во временный указатель not_null_unique_ptr{move(p)}, в той же строке объект и помрёт Улыбающийся. Но это совсем не отменяет полезность not_null указателей Улыбающийся.
Записан

Пока сам не сделаешь...
Old
Джедай : наставник для всех
*******
Online Online

Сообщений: 4349



Просмотр профиля
« Ответ #16 : Ноябрь 12, 2019, 17:00 »

Но это совсем не отменяет полезность not_null указателей Улыбающийся.
А я нигде про не полезность not_null не говорил. Улыбающийся
Я был не очень согласен с претензиями к перемещаемому юнику.
Записан
Авварон
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 3257


Просмотр профиля
« Ответ #17 : Ноябрь 12, 2019, 17:42 »

С перемещаемым юником всё хорошо) проблема с его мутабельностью - либо он мутабельный и перемещаемый, либо немутабельный и неперемещаемый.

На самом деле, с юником проблемы "нулевого" указателя обычно нет - он обычно создается через make_unique и если избегать явных вызовов .reset(), то всё будет хорошо.
Записан
Old
Джедай : наставник для всех
*******
Online Online

Сообщений: 4349



Просмотр профиля
« Ответ #18 : Ноябрь 12, 2019, 18:06 »

С перемещаемым юником всё хорошо) проблема с его мутабельностью - либо он мутабельный и перемещаемый, либо немутабельный и неперемещаемый.
У меня вызывает большие сомнения потребность в перемещаемом и немутабельном указателе. Улыбающийся
Я не вижу сферу его применения.

Да и not_null мне будет полезен только с поддержкой компиляторами, когда они будут бесплатными. Сейчас мне приходится писать assert.
А не будет поддержки, ну и ладно, обойдусь без not_null. Улыбающийся
Записан
ViTech
Гипер активный житель
*****
Offline Offline

Сообщений: 858



Просмотр профиля
« Ответ #19 : Ноябрь 12, 2019, 18:35 »

Да и not_null мне будет полезен только с поддержкой компиляторами, когда они будут бесплатными. Сейчас мне приходится писать assert.

А в чём сейчас платность gsl::not_null для сырых указателей (да и для умных, если его доделать по уму)? И чем not_null_unique_ptr будет платнее текущего std::unique_ptr? И что должно появиться в компиляторе, чтобы избежать этих плат? Улыбающийся
Записан

Пока сам не сделаешь...
Old
Джедай : наставник для всех
*******
Online Online

Сообщений: 4349



Просмотр профиля
« Ответ #20 : Ноябрь 12, 2019, 18:46 »

А в чём сейчас платность gsl::not_null для сырых указателей (да и для умных, если его доделать по уму)? И чем not_null_unique_ptr будет платнее текущего std::unique_ptr? И что должно появиться в компиляторе, чтобы избежать этих плат? Улыбающийся
Так сейчас это тот же assert по сути. Платим проверкой. Причем проверка эта на каждое разименование. У меня assert один раз выполняется. Улыбающийся
А если компилятор будет их выкидывать, то это будет хоть что-то. Улыбающийся

У меня не стоит остро проблема проверки указателей на nullptr. Я очень активно использую ссылки, стараюсь продумывать владения, время создания и разрушения объектов. Поэтому, как-то для меня это не проблема. Улыбающийся
« Последнее редактирование: Ноябрь 12, 2019, 18:59 от Old » Записан
ViTech
Гипер активный житель
*****
Offline Offline

Сообщений: 858



Просмотр профиля
« Ответ #21 : Ноябрь 12, 2019, 19:01 »

Так сейчас это тот же assert по сути. Платим проверкой. Улыбающийся
А если компилятор будет их выкидывать, то это будет хоть что-то. Улыбающийся

Дело там не только в assert. Некоторые операции удалены. Например, конструктор по умолчанию, конструктор из nullptr, оператор присваивания из nullptr, и т.п. Т.е. уже на этапе compile-time можно многие вещи уладить, не дожидаясь, когда в run-time assert выбьет. И выразительность кода намного выше, по сигнатуре функции понятно, какая сущность ей нужна, assert'ы внутри функции могут быть и не видны читателю.

Нагрузка на компилятор, скорей всего, возрастёт, но в оптимизированный release run-time может выйти уже без платы.
Записан

Пока сам не сделаешь...
Авварон
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 3257


Просмотр профиля
« Ответ #22 : Ноябрь 12, 2019, 19:14 »

Ну в .get() проверка не нужна, так как operator= "реализован" через implicit ктор от T и уже там есть проверка, т.е. нельзя nullptr присвоить.
Я так понял, эта проверка там с давних времен и пока не убрана "как бы чего не случилось".
Так как не ясно что этот get() должен возвращать для вумных указателей - ну а вдруг там будет ссылка на вумный указатель и можно сделать .get().release()?
Так-то да, сейчас эта проверка просто оверхед безо всяких бонусов (так как вумные не поддерживаются до конца).
Записан
Old
Джедай : наставник для всех
*******
Online Online

Сообщений: 4349



Просмотр профиля
« Ответ #23 : Ноябрь 12, 2019, 19:20 »

Т.е. уже на этапе compile-time можно многие вещи уладить, не дожидаясь, когда в run-time assert выбьет.
Я уже и не припомню, когда эти ассерты срабатывали. Ставлю их на автомате.
Вот перебираю в голове свои проекты... в основное массе мест, где точно нужен объект, используются ссылки. А в остальных местах, где используются указатели не представляю, что бы кто-то мог nullptr передать. По именам методов понятно, что например, в append( object_ptr obj ) нет нужды nullptr передавать. Улыбающийся
А если все таки "талант" найдется, то по стеку возвратов после assert он легко находится и бьется. Улыбающийся

И выразительность кода намного выше, по сигнатуре функции понятно, какая сущность ей нужна, assert'ы внутри функции могут быть и не видны читателю.
Да, выразительность хорошая.
Записан
ViTech
Гипер активный житель
*****
Offline Offline

Сообщений: 858



Просмотр профиля
« Ответ #24 : Ноябрь 12, 2019, 19:29 »

Ну в .get() проверка не нужна, так как operator= "реализован" через implicit ктор от T и уже там есть проверка, т.е. нельзя nullptr присвоить.
Я так понял, эта проверка там с давних времен и пока не убрана "как бы чего не случилось".

Способов сломать not_null не так уж и много. Один из - это разыменование указателя после его перемещения. Второй может связан со swap с перемещённым указателем, но это может быть и валидной операцией, по сути то же перемещение, как посмотреть. Про другие способы посильнее задуматься надо Улыбающийся. Но обращение к объекту после перемещение - это общая проблема, и может решаться статическими анализаторами. Когда такие созреют, assert в get можно и убрать. А сейчас он да, "на всякий случай".

Так как не ясно что этот get() должен возвращать для вумных указателей - ну а вдруг там будет ссылка на вумный указатель и можно сделать .get().release()?
Так-то да, сейчас эта проверка просто оверхед безо всяких бонусов (так как вумные не поддерживаются до конца).

Если честно, этот get() я бы вообще убрал Улыбающийся.
Записан

Пока сам не сделаешь...
ViTech
Гипер активный житель
*****
Offline Offline

Сообщений: 858



Просмотр профиля
« Ответ #25 : Ноябрь 12, 2019, 19:43 »

По именам методов понятно, что например, в append( object_ptr obj ) нет нужды nullptr передавать. Улыбающийся
А если все таки "талант" найдется, то по стеку возвратов после assert он легко находится и бьется. Улыбающийся

Имя метода, всё таки, слабоватый аргумент, тип параметра выразительнее и может обеспечить больше гарантий. Это не только к входным параметрам относится, но и к результату. Тогда  и по стеку после assert'ов намного меньше придётся лазить. Не все же такие дисциплинированные, как вы Улыбающийся. Да и профи может устать, а компилятор ему сразу подскажет, где он не прав Улыбающийся.
Записан

Пока сам не сделаешь...
Old
Джедай : наставник для всех
*******
Online Online

Сообщений: 4349



Просмотр профиля
« Ответ #26 : Ноябрь 12, 2019, 20:01 »

а компилятор ему сразу подскажет, где он не прав Улыбающийся.
Я только за помощь компилятора + он эти проверки может сделать эффективней меня.
Будет поддержка в компиляторе буду всеми руками использовать. Улыбающийся
Записан
_Bers
Бывалый
*****
Offline Offline

Сообщений: 486


Просмотр профиля
« Ответ #27 : Ноябрь 28, 2019, 22:27 »

Но это совсем не отменяет полезность not_null указателей Улыбающийся.

и зачем он нужен?



Записан
ViTech
Гипер активный житель
*****
Offline Offline

Сообщений: 858



Просмотр профиля
« Ответ #28 : Ноябрь 29, 2019, 11:55 »

Но это совсем не отменяет полезность not_null указателей Улыбающийся.

и зачем он нужен?

А затем.
Записан

Пока сам не сделаешь...
_Bers
Бывалый
*****
Offline Offline

Сообщений: 486


Просмотр профиля
« Ответ #29 : Ноябрь 29, 2019, 23:43 »


ну и зачем нужно такое "затем"?

если ожидается работа с реальным объектом,
тогда нужно использовать ссылку, а не указатель.

зачем изобретать указатель, который делает вид,
что он ссылка?

Записан
Страниц: 1 [2] 3 4 5   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.065 секунд. Запросов: 22.