Здравствуйте, sergii.p, Вы писали:

SP> Rust наступает

SP>уже 20 (10) лет этот код приводит к UB
SP>

SP>std::unique_ptr<Foo> f;
f->>foo();
SP>

SP>и "современный" подход заключается в том, чтобы закрыть глаза на этот вид проблем.

А какого поведения хотелось бы? Втихую не вызывать foo()? Что в этом хорошего? Кидать исключение из operator-> тоже себе такое. Хуже чем UB имхо. Имхо, вообще непонятно, почему STL в этом месте должна какими-то помочами обеспечивать писателей такого кода.

Здравствуйте, ononim, Вы писали:

O>Ну я отчегото подумал что вы за все хорошее и хотите std::uniqnue_ptr всегда возвращал поинтер на валидный объект, сконструированный дефолтным конструктором например.
ок, причём что ниже B0FEE664 понял тоже самое. Видимо, я совсем неудачно выразился
Лично я против оператора -> в принципе. Как по мне, надо перерабатывать интерфейс вовсе. Я бы хотел видеть что-то типа map

unique_ptr<SomeObj> obj;
obj.map(&SomeObj::SomeMethod).map_empty(logError);

Кто-то скажет, что многословно. Но в любом случае, кода меньше, чем при проверке вручную. А проверять надо всегда!
В общем классическая монада. Обёртка над объектом, которая не даёт непосредственный доступ к объекту, а допускает только ограниченный набор действий.
Понятно, что в stl на такое не решатся. Но можно хотя бы было бросить исключение NullPtrError. Но коммитет посчитал, что UB — лучшее из возможных вариантов.

Те же самые нарекания на std::optional. Недавно тут проскакивала тема. Точно не помню, но что-то вроде этого:

return isValue || intOpt ? *intOpt : 0;

всё из-за того, что дали прямой доступ к объекту.

В общем, после такого идут мысли, что некоторые объекты stl неудачны и их надо менять. И тут от гугла почти благословение... То есть не я один такой д'Артаньян, а есть такие же придурки.

p.s Ну и заметим, что топик рекламный. Он рекламирует статические анализаторы кода. Я даже не хочу туда влазить. Только смотрю то, что можем поменять сами.

Здравствуйте, Ip Man, Вы писали:

SP>> Rust наступает

IM>

видимо, вы так не думаете. Завидую. А мне кажется, что Rust лучше моего любимого языка тупо по Парето. И вытеснение неизбежно. Из-за этого страдаю.

Здравствуйте, ononim, Вы писали:

O>Что за чудесный указатель и зачем он нужен если есть shared_ptr и std::make_shared?

Это который приводит к утечкам на циклических ссылках и требует атомарного счётчика?

O>>Что за чудесный указатель и зачем он нужен если есть shared_ptr и std::make_shared?
TB>Это который приводит к утечкам на циклических ссылках и требует атомарного счётчика?
А чудесный не приводит и не требует и не GC? Тогда и впрямь чудесный.

Здравствуйте, ononim, Вы писали:

O>А чудесный не приводит и не требует и не GC? Тогда и впрямь чудесный.
Юника достаточно в 90% случаев. Да, не приводит, не требует, не GC.

O>>А чудесный не приводит и не требует и не GC? Тогда и впрямь чудесный.
TB>Юника достаточно в 90% случаев. Да, не приводит, не требует, не GC.
Ну про юник то я и сам знаю, сорри что мой изначальный посыл был недостаточно очевиден. А он такой — нафига нужен гугловский MiraclePtr если автопоинтеры имеются в std:: ?

Здравствуйте, ononim, Вы писали:

O>Ну про юник то я и сам знаю, сорри что мой изначальный посыл был недостаточно очевиден. А он такой — нафига нужен гугловский MiraclePtr если автопоинтеры имеются в std:: ?

Не знаю, я статью не читал.

Здравствуйте, sergii.p, Вы писали:

IM>>

SP>видимо, вы так не думаете. Завидую. А мне кажется, что Rust лучше моего любимого языка тупо по Парето. И вытеснение неизбежно. Из-за этого страдаю.

Я не знаю, сколько лет вы занимаетесь коммерческой разработкой, но индустрия так не работает. Если сотни миллионов строк написаны на C++, его будут продолжать использовать и класть с прибором на даже лучшие языки. Тем более, что в последние годы C++ активно развивается (пусть даже добавляя больше UB )

Здравствуйте, sergii.p, Вы писали:

SP>уже 20 (10) лет этот код приводит к UB
SP>

std::unique_ptr<Foo> f;
f->foo();

Не усложняй, вот так проще:

Foo * f;
f->foo();

Наличие удобных механизмов не лишает тебя возможности прицельно стрелять себе в ногу.

Здравствуйте, sergii.p, Вы писали:

SP>Лично я против оператора -> в принципе. Как по мне, надо перерабатывать интерфейс вовсе. Я бы хотел видеть что-то типа map
SP>

SP>unique_ptr<SomeObj> obj;
SP>obj.map(&SomeObj::SomeMethod).map_empty(logError);
SP>

SP>Кто-то скажет, что многословно. Но в любом случае, кода меньше, чем при проверке вручную.
Ээээ... И что будет возвращать logError в качестве результата вызова SomeMethod для пустого указателя?

SP> А проверять надо всегда!
Это зачем всегда проверять? Мне обычно такого не надо, достаточно ассертов:

std::unique_ptr<SomeObj> ptr = ...;
assert(nullptr != ptr);

SP>В общем классическая монада. Обёртка над объектом, которая не даёт непосредственный доступ к объекту, а допускает только ограниченный набор действий.
SP>Понятно, что в stl на такое не решатся. Но можно хотя бы было бросить исключение NullPtrError. Но коммитет посчитал, что UB — лучшее из возможных вариантов.
Хотите исключение, бросайте исключение, вам никто не мешает:

template <class T>
class MyUniquePtr
{
  ....
    std::unique_ptr<T>& operator -> ()
    { 
       if ( nullptr == m_ptr )
       {
          throw std::runtime_error("null ptr"); 
       }
       return m_ptr;
    }
  private:
    std::unique_ptr<T> m_ptr;
};

Здравствуйте, sergii.p, Вы писали:

SP>уже 20 (10) лет этот код приводит к UB
SP>

SP>std::unique_ptr<Foo> f;
f->>foo();
SP>

SP>и "современный" подход заключается в том, чтобы закрыть глаза на этот вид проблем.

современный подход это взять нормальный аналайзер/санитайзер и доточить его если нужно, а не изобретать велосипеды на ровном месте, да тот же гугель в прошлом году в рамках gsoc делал такое: https://vrnithinkumar.github.io/2020/08/31/gsoc-report/