Ненулевые указатели

[ViTech]

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

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

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

[Old]

Но это совсем не отменяет полезность not_null указателей .

А я нигде про не полезность not_null не говорил.
Я был не очень согласен с претензиями к перемещаемому юнику.

[Авварон]

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

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

[Old]

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

У меня вызывает большие сомнения потребность в перемещаемом и немутабельном указателе.
Я не вижу сферу его применения.

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

[ViTech]

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

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

[Old]

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

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

У меня не стоит остро проблема проверки указателей на nullptr. Я очень активно использую ссылки, стараюсь продумывать владения, время создания и разрушения объектов. Поэтому, как-то для меня это не проблема.

[ViTech]

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

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

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

[Авварон]

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

[Old]

Т.е. уже на этапе compile-time можно многие вещи уладить, не дожидаясь, когда в run-time assert выбьет.

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

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

Да, выразительность хорошая.

[ViTech]

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

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

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

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

[ViTech]

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

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

[Old]

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

Я только за помощь компилятора + он эти проверки может сделать эффективней меня.
Будет поддержка в компиляторе буду всеми руками использовать.

[_Bers]

Но это совсем не отменяет полезность not_null указателей .

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

[ViTech]

Но это совсем не отменяет полезность not_null указателей .

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

А затем.

[_Bers]

А затем.

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

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

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