Здравствуйте, ononim, Вы писали:
O>Ну про юник то я и сам знаю, сорри что мой изначальный посыл был недостаточно очевиден. А он такой — нафига нужен гугловский MiraclePtr если автопоинтеры имеются в std:: ?
SP>и "современный" подход заключается в том, чтобы закрыть глаза на этот вид проблем.
Что мешает Google использовать свои умные указатели везде, которые будут проверять такие инварианты и не давать делать инициализацию по умолчанию ?!
Почему тогда они до сих пор пишут так (пример из webrtc.lib):
???
И это типичный Google код из Хрома. Вот пойди разберись что здесь передается как ссылка, а что для захвата владения
Они уже из простого интернет протокола HTTP сделали штуку (HTTP3) которую хрен реализуешь на коленке и будешь вынужден использовать кусок Хрома, причем не важно, нужна тебе секьюрность или нет. WebRTС — монстр, внутри которого наслоения всех протоколов за последние 40 лет. Всё технологии за которые берется Google превращаются в инструмент для решения бизнес задач Google, не пригодными ни для чего другого.
Перевод документа Safer Usage Of C++, выложенного в общий доступ командой Chromium/Chrome из компании Google и активно обсуждаемого на Reddit. Текста много, но, думаю, C++ программистам будет очень полезно почитать.
Здравствуйте, jul_nevermind, Вы писали:
_>Перевод документа Safer Usage Of C++, выложенного в общий доступ командой Chromium/Chrome из компании Google и активно обсуждаемого на Reddit. Текста много, но, думаю, C++ программистам будет очень полезно почитать.
И чего там интересного? Обсуждаются какие-то проблемы прошлого века:
Examples include use after free (UAF), double-free, use before initialization, and use after move (UAM). Temporal safety violations often look like type confusion. For example, the program mistakenly uses a recently-freed Dog object as if it were a Cat object
Смарт указатели даже в стандарте давно. Эти из Google примерно на 20 лет отстают от современных подходов.
Здравствуйте, B0FEE664, Вы писали:
BFE>И чего там интересного? Обсуждаются какие-то проблемы прошлого века:
как минимум гистограмма распределения ошибок. Статистика занятная. Особенно посмотреть на процент data race и процент статей и докладов, как их обходить Я конечно понимаю, что это интереснее, чем проблема протухших ссылок, но тенденция занятная.
BFE>Смарт указатели даже в стандарте давно. Эти из Google примерно на 20 лет отстают от современных подходов.
уже 20 (10) лет этот код приводит к UB
std::unique_ptr<Foo> f;
f->foo();
и "современный" подход заключается в том, чтобы закрыть глаза на этот вид проблем.
BFE>>Смарт указатели даже в стандарте давно. Эти из Google примерно на 20 лет отстают от современных подходов. SP>уже 20 (10) лет этот код приводит к UB SP>[ccode] SP>std::unique_ptr<Foo> f; f->>foo();
Но ведь это не use after free, священную войну против которого объявил гуголь.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, jul_nevermind, Вы писали:
_>Перевод документа Safer Usage Of C++, выложенного в общий доступ командой Chromium/Chrome из компании Google и активно обсуждаемого на Reddit. Текста много, но, думаю, C++ программистам будет очень полезно почитать.
высказана довольно смелая мысль "мы наш, мы новый stl построим". Лично я эту мысль разделяю. Rust наступает, а коммитет каждый год выпускает фичи с тоннами UB.
Здравствуйте, sergii.p, Вы писали:
BFE>>И чего там интересного? Обсуждаются какие-то проблемы прошлого века: SP>как минимум гистограмма распределения ошибок. Статистика занятная. Особенно посмотреть на процент data race и процент статей и докладов, как их обходить Я конечно понимаю, что это интереснее, чем проблема протухших ссылок, но тенденция занятная.
Если набирать по объявлению и код-ревью не делать, то так и будет. Что там занятного?
BFE>>Смарт указатели даже в стандарте давно. Эти из Google примерно на 20 лет отстают от современных подходов. SP>уже 20 (10) лет этот код приводит к UB SP>
SP>std::unique_ptr<Foo> f;
f->>foo();
SP>
SP>и "современный" подход заключается в том, чтобы закрыть глаза на этот вид проблем.
Вообще-то смарт указатели не ограничиваются стандартом:
... safe_ptr::operator ->()
{
if ( nullptr == m_ptr )
{
m_ptr = new T{};
}
return m_ptr;
}
однако если вам такое надо, значит процесс тестирования у вас поставлен криво.
Здравствуйте, ononim, Вы писали:
O>Но ведь это не use after free, священную войну против которого объявил гуголь.
я и не говорил, что это UAF. Гугл заявил, что в стандарте дофига UB. Причём иногда просто необоснованного. Точнее обоснованного как раз: не хотели производительность просаживать. Вот из-за этих плёвых проверок мы отстреливаем ноги по сей день.
Здравствуйте, velkin, Вы писали:
SP>>"мы наш, мы новый stl построим".
V>Для всего остального есть Boost.
так буст же — калька stl (точнее наоборот). Что он делает лучше? Итераторы отлично инвалидируются в обоих библиотеках, use after move прекрасно себя чувствует что при белых, что при красных. В общем, скрипач boost не нужен
SP>я и не говорил, что это UAF. Гугл заявил, что в стандарте дофига UB. Причём иногда просто необоснованного. Точнее обоснованного как раз: не хотели производительность просаживать. Вот из-за этих плёвых проверок мы отстреливаем ноги по сей день.
И чем лучше подстановка пустого объекта? Тем что апликуха не упадет в данном конкретном месте, а юзер будет потом недоумевать, куда пропали его данные?
С тем же успехом можно заменять на NULL guard page в адресном пространстве на RW регион, вечно заполненный нулями.
Как много веселых ребят, и все делают велосипед...
SP>чего? Мне кажется, вы додумываете какие-то высказывания за меня и с ними же спорите
Ну я отчегото подумал что вы за все хорошее и хотите std::uniqnue_ptr всегда возвращал поинтер на валидный объект, сконструированный дефолтным конструктором например.
Ну а насчет UB.. UB при обращении к нулевому указателю конечно плохо. Надо чтоб поведение было достаточно четко определено — в таком случае апликуха должна падать
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>Ну я отчегото подумал что вы за все хорошее и хотите std::uniqnue_ptr всегда возвращал поинтер на валидный объект, сконструированный дефолтным конструктором например. O>Ну а насчет UB.. UB при обращении к нулевому указателю конечно плохо. Надо чтоб поведение было достаточно четко определено — в таком случае апликуха должна падать
В Debug скорее всего assert вылетит
Ну и самому надо, когда получаешь что-то неизвестно откуда, по-хорошему всё тоже assert'ами обкладывать
Здравствуйте, Videoman, Вы писали:
У>>В Debug скорее всего assert вылетит
V>Тоже так думал, проверил — во всяком случае MSVC, тупо разыменовывает нулевой указатель, что является UB. Интересно, почему нет assert ?
Ну, под виндой будет системное исключение, а не UB
V>>Тоже так думал, проверил — во всяком случае MSVC, тупо разыменовывает нулевой указатель, что является UB. Интересно, почему нет assert ? У>Ну, под виндой будет системное исключение, а не UB
В линуксах тоже. Но фишка в том, что изза того что формально это UB, то компилятор может творить разную чернуху, например, видя что разыменовываемый указатель точно равен nullptr, — он теоретически может выкинуть нафиг код обращения, как ретурн в соседнем топике
SP>и "современный" подход заключается в том, чтобы закрыть глаза на этот вид проблем.
А какого поведения хотелось бы? Втихую не вызывать foo()? Что в этом хорошего? Кидать исключение из operator-> тоже себе такое. Хуже чем UB имхо. Имхо, вообще непонятно, почему STL в этом месте должна какими-то помочами обеспечивать писателей такого кода.
Здравствуйте, ononim, Вы писали:
O>Ну я отчегото подумал что вы за все хорошее и хотите std::uniqnue_ptr всегда возвращал поинтер на валидный объект, сконструированный дефолтным конструктором например.
ок, причём что ниже B0FEE664 понял тоже самое. Видимо, я совсем неудачно выразился
Лично я против оператора -> в принципе. Как по мне, надо перерабатывать интерфейс вовсе. Я бы хотел видеть что-то типа map
Кто-то скажет, что многословно. Но в любом случае, кода меньше, чем при проверке вручную. А проверять надо всегда!
В общем классическая монада. Обёртка над объектом, которая не даёт непосредственный доступ к объекту, а допускает только ограниченный набор действий.
Понятно, что в stl на такое не решатся. Но можно хотя бы было бросить исключение NullPtrError. Но коммитет посчитал, что UB — лучшее из возможных вариантов.
Те же самые нарекания на std::optional. Недавно тут проскакивала тема. Точно не помню, но что-то вроде этого:
return isValue || intOpt ? *intOpt : 0;
всё из-за того, что дали прямой доступ к объекту.
В общем, после такого идут мысли, что некоторые объекты stl неудачны и их надо менять. И тут от гугла почти благословение... То есть не я один такой д'Артаньян, а есть такие же придурки.
p.s Ну и заметим, что топик рекламный. Он рекламирует статические анализаторы кода. Я даже не хочу туда влазить. Только смотрю то, что можем поменять сами.
O>>Что за чудесный указатель и зачем он нужен если есть shared_ptr и std::make_shared? TB>Это который приводит к утечкам на циклических ссылках и требует атомарного счётчика?
А чудесный не приводит и не требует и не GC? Тогда и впрямь чудесный.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>А чудесный не приводит и не требует и не GC? Тогда и впрямь чудесный.
Юника достаточно в 90% случаев. Да, не приводит, не требует, не GC.
O>>А чудесный не приводит и не требует и не GC? Тогда и впрямь чудесный. TB>Юника достаточно в 90% случаев. Да, не приводит, не требует, не GC.
Ну про юник то я и сам знаю, сорри что мой изначальный посыл был недостаточно очевиден. А он такой — нафига нужен гугловский MiraclePtr если автопоинтеры имеются в std:: ?
Как много веселых ребят, и все делают велосипед...
Здравствуйте, sergii.p, Вы писали:
IM>>
SP>видимо, вы так не думаете. Завидую. А мне кажется, что Rust лучше моего любимого языка тупо по Парето. И вытеснение неизбежно. Из-за этого страдаю.
Я не знаю, сколько лет вы занимаетесь коммерческой разработкой, но индустрия так не работает. Если сотни миллионов строк написаны на C++, его будут продолжать использовать и класть с прибором на даже лучшие языки. Тем более, что в последние годы C++ активно развивается (пусть даже добавляя больше UB )
Здравствуйте, sergii.p, Вы писали:
SP>Лично я против оператора -> в принципе. Как по мне, надо перерабатывать интерфейс вовсе. Я бы хотел видеть что-то типа map SP>
SP>Кто-то скажет, что многословно. Но в любом случае, кода меньше, чем при проверке вручную.
Ээээ... И что будет возвращать logError в качестве результата вызова SomeMethod для пустого указателя?
SP> А проверять надо всегда!
Это зачем всегда проверять? Мне обычно такого не надо, достаточно ассертов:
SP>В общем классическая монада. Обёртка над объектом, которая не даёт непосредственный доступ к объекту, а допускает только ограниченный набор действий. SP>Понятно, что в stl на такое не решатся. Но можно хотя бы было бросить исключение NullPtrError. Но коммитет посчитал, что UB — лучшее из возможных вариантов.
Хотите исключение, бросайте исключение, вам никто не мешает:
Здравствуйте, 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/