юнионы в C++

Я и не говорил, что это хорошо.

Может не очевидно, но основная претензия - дисбаланс между demo::demo и demo::~demo.

Но это есть. И такие вещи нужно принимать во внимание когда заходит речь о const в C++.

Как мы неоднократно здесь упоминали - есть очень много способов различной степени извращённости как отстрелить себе ногу. Кмк, искусство в том чтобы научиться использовать доступные возможности инструмента себе во благо наиболее эффективно (уточню - в Вас я нисколько не сомневаюсь).

Может не очевидно, но основная претензия - дисбаланс между demo::demo и demo::~demo.

Тут, кстати, отдельный и открытый вопрос о том, сколько усилий нужно приложить, чтобы написать корректный код, который бы правильно удалял старый экземпляр и создавал бы новый экземпляр в области памяти старого. Особенно с учетом обеспечения exception safety.

Так что это, скорее, антипаттерн, который должен применяться в исключительных случаях. В частности, в ситуациях, когда demo – это trivially destructible. В этом случае разницей между количеством конструкторов и деструкторов можно пренебречь.

Любимое занятие программистов на крестах - обсуждение, что получится, если сделать так, как делать не надо.

Могу говорить только за себя. Из моего опыта следует, что прикладной код на C++, как правило, пишется совсем не так, как пишутся C++ные библиотеки (особенно библиотеки общего назначения, типа реализации контейнеров, регулярных выражений, парсеров и т.д.)

Прикладной код пишется «в лоб», без использования каких-либо наворотов и шаблонной магии. Разве что эти самые навороты и магию приплетают для того, чтобы расшить узкие места или избавиться от дублирования однотипного кода. Да и то, делают это далеко не все и не всегда.

А вот при написании библиотек ситуация меняется. И меняется, зачастую, из-за того, что где-то библиотеку попытались применить не совсем так и вылезли какие-то нюансы.

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

Отсюда и разговоры из категории «приколитесь, как можно».

Т.е. если убрать из рассмотрения неофитов, которые с упоением упарываются какой-нибудь новой фичей (в конце-концов многих из нас покусал Александреску и не все оправились от этого), то в большинстве случаев это все-таки из категории «не мы такие, жизнь такая».

ИМХО, конечно же.

«Нетранзитивность константности», то бишь невозможность в C++ явно специфицировать на уровне типов константность/мутабельность всех вложенных данных

Тут ошибка в слове «вложенных». Ссылка и указатель говорят о том, что данные не вложеные, а независимые.

предлагаю покурить вот такой пример:

Реплика непривязанная к const:

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

Не удержался.

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

Да, крышу сносит :)

Опять 25, я ведь уже постил «транзистивную константносту» юнионы в C++ (комментарий). Вам чего надо, чтобы простейшую обёртку на 5 строк освятил комитет, и помазал лично Страуструп? Кому надо - сделает, но на самом деле это нафиг особо не надо в реальности и примеры Букози - скорее говнокод с какими-то лютыми перекрёстными ссылками.

Обычно они приходят к выводу «кресты - говно, потому что если сделать как не надо, то получится ХЗ что».

Неа. Куда чаще вывод такой, что «неосиляторам» тут делать нечего, а вот профессионалы без этих трюков прожить не смогут.

А что случится с профессионалом, который откажется выполнять этот трюк? Его выгонят из цирка?

Конечно. Выгонят с позором писать на расте.

Ну хоть не похоронят без обеих ног.

Тут, кстати, отдельный и открытый вопрос о том, сколько усилий нужно приложить, чтобы написать корректный код, который бы правильно удалял старый экземпляр и создавал бы новый экземпляр в области памяти старого. Особенно с учетом обеспечения exception safety.

Я считаю - без внешней индикации «объект существует» (std::optional в случае отдельных объектов, size vs capacity в vector’е etc) это тупо невозможно.

Так что это, скорее, антипаттерн, который должен применяться в исключительных случаях. В частности, в ситуациях, когда demo – это trivially destructible. В этом случае разницей между количеством конструкторов и деструкторов можно пренебречь.

Согласен по всем пунктам. Более того - знаю места в нашем prod коде где это встречается. Решили не тратить на это время (хотя поправить было несложно) именно по причине «не выстрелит» - всегда имеются гораздо более приоритетные задачи где выхлоп будет реально ощутим (я думаю - у остальных примерно то же самое, в конве choose your fight wisely).

Любимое занятие программистов на крестах - обсуждение, что получится, если сделать так, как делать не надо.
Обычно они приходят к выводу «кресты - говно, потому что если сделать как не надо, то получится ХЗ что»

Ты ходишь по тонкой грани. Шаг в сторону — и вот уже внезапно 95% всей индустрии делает «так, как делать не надо». Если делать так, как надо делать, то получается что-то подозрительно похожее на Rust, только без настоящих лайфтаймов и контроля мутабельности.

Вроде бы там главный невменяемый по Nemerle, VladD2, всю эту историю со своей колокольни описывал.

С VladD2 я особо не общался, но много переписывался со вторым активным разработчиком Немерле - hardcase на форуме codenet (даже как-то раз его вживую видел). Основными фичами Немерле были паттерн-матчинг и хвостовая рекурсия. Были ещё и гигиенические макросы, и прочие незначительные свистелки. Но вопрос был как всё это продать обычным кодерам.

Например, паттерн-матчинг обычный кодер воспринимает как какой-то продвинутый case, типа того, что был в Паскале. И это было бы хорошо иметь в качестве альтернативы убогому сишному switch-case. Но классический паттерн-матчинг в отличие от case на вход получает не одну переменную, а список (массив данных), который он делит на две части. И далее рекурсией мы список делим на кусочки. Но при огромных списках мы можем получить проблемы с рекурсией, поэтому так важна хвостовая рекурсия, которая преобразуется в цикл.

Это всё круто, если мы реализуем парсер языка программирования. Но такие задачи большинство программистов на регулярной основе не делают. Пропагандисты Немерле говорили, что оно хорошо и при парсинге логов, например. Но в данном случае достаточно более простых инструментов.

Если говорить конкретно про language workbench, типа Nitra, то это штука которую ещё сложнее продать обычному программисту. Ибо инструкции по их использованию напоминают известный совет по рисованию совы: нарисуй круг, нарисуй сову. А здесь получается так: создай калькулятор, создай свой супер-пупер язык программирования.

Zig, Nim и даже Nemerle

Из этих трёх сейчас только у Nim есть своя ниша. И связана она не с какими-то уникальными синтаксическими фичами. Судя по комментариям пользователей, они используют устройства, в которых Python или C# будут избыточны, либо непонятно, как их установить. Разработчикам предоставляется только компилятор C или, в лучшем случае, C++. А хочется чего-то более удобного, гибкого и лаконичного. И тут Nim выручает, ибо транслируется в эти языки. Но на этом всё. Других ниш нет.

Если авторы Nim скажут, что теперь вместо трансляции в Си будут использовать llvm (а такие намёки были), то лишатся всех своих пользователей.

Основными фичами Немерле были паттерн-матчинг и хвостовая рекурсия. Были ещё и гигиенические макросы

Для меня, да и не только для меня, главной фичей Nemerle были именно гигиенические макросы, т.к. они позволяли делать DSL-и под свои задачи. Если не ошибаюсь, даже некоторая часть самого языка Nemerle была сделана посредством макросов.

Грубо говоря, если в C# для реализации LINQ пришлось язык расширять, то в Nemerle аналог LINQ можно было бы сделать на гигиенических макросах (вроде как даже RSDN-еры это и пытались делать).

Собственно, именно это и пытались продавать. Мол, каждый разработчики сможет сделать на Nemerle крутой комбайн под свою задачу.

Только в реальности прикладным разработчикам в 99.9% не хочется делать какие-либо комбайны. Посему и крутизна Nemerle им пофигу.

Любимое занятие программистов на крестах - обсуждение, что получится, если сделать так, как делать не надо.

Надо же ещё знать, как делать правильно. Не просто же так появляются книжки типа «С++. 101 правило и рекомендация». И тут есть множество ловушек, которые можно разделить на две группы:

1. Наследие Си. Строки, заканчивающихся нулем, необходимый break в case, присвоение в if и прочее. Ну тут уже компилятор на многое выдаст предупреждение.
2. Сложные иерархии и взаимоотношения классов, как в Java, но без сборщика мусора. Например, тот же полиморфизм потребует использования указателей, что уже вносит некоторый риск. Умные указатели может и выручат, но их ещё надо изучить, набив шишек в процессе.

DSL-и под свои задачи

Здесь речь про внутренние DSL, о которых я забыл, да. У Nemerle были инструменты для создания и внешних, и внутренних DSL. Этого не отнять.

в C# для реализации LINQ пришлось язык расширять

Это интересный пример. Для LINQ действительно есть встроенный DSL, синтаксис которого напоминает SQL. Но я опрашивал программистов C# - большинство их них используют альтернативный способ использования LINQ на методах. Соответственно, специальный синтаксис для LINQ оказался невостребованным.

сорян если запоздало, только дочитал все, и вроде это уже отмечали, но лепить много кода в конструкторах и деструкторах не очень правильное дело, это порицается в джаве и в джаваскрипт технологиях. Даже конфигурирование экземпляра обычно делегируется какой-нибудь фабрике, билдеру или иок-контейнеру. Про RAII видимо лучше забыть как об очередном антипаттерне, коих сейчас много популяризируется или оставить только там где требуется элегантное оборачивание ресурсов. Важно что-бы конструирование у вас была конкретно определено в методе или классе, а не происходило абы как как обычно сделано в процедурном коде отрицателей ООП. По своему опыту могу отметить, что на приличной инфраструктуре типа Qt, Wt, Poco выстрелы в ногу не являются поведением по умолчанию, а некоторые неоднозначности в С++ объясняются историческим развитием, а не вредительским умыслом создателей как во многих популярных языках, в т.ч. «убийцах» С++ и убийцах убийц. Если С++ позволяет делать приемлемо при прямых руках, значит он предпочтительнее технологий безусловно навязывающих антипаттерны к коим относится и процедурный код без ООП.

Кто просил, зачем телега - вот она:

1-я часть

https://disk.yandex.ru/d/4x7CZqf5SIH-bA

2-я часть

https://disk.yandex.ru/i/K_Fo6ibSy--fFg

посмотрел видео и как-то я не понял почему ты думаешь что уязвимости заносятся специально, и что их не будет в отечественном форке линукса если не будем принимать патчи с запада.

Я думаю что уязвимостей будет гораздо больше, так как меньше человек => меньше ревью кода => больше ошибок.

посмотрел видео и как-то я не понял почему ты думаешь что уязвимости заносятся специально

Заносятся специально, потому что Сноуден, Крипто АГ, сообщения об эксплуатации уязвимостей провластными группировками для преследования инакомыслия, в т.ч. в Европе, а также разный криминал. Не все уязвимости заносятся специально, но некоторая доля, которая неизвестна.

Я думаю что уязвимостей будет гораздо больше, так как меньше человек => меньше ревью кода => больше ошибок.

Их и так больше, чем допустимо. И конкретная уязвимость может пережить, скажем, 20 выпусков ядра. Значит, ревью кода в том виде, в котором оно сейчас есть, не работает. Но можно принимать меры, чтобы их было меньше, а можно обзываться мастурбирующими обезьянами.

1-я часть именно, можн https://disk.yandex.ru/d/4x7CZqf5SIH-bA

На фразе «…Поздно уже. Сейчас уже нужно делать что-то другое. Я знаю что делать, я могу рассказать.» захотелось узнать в какой палате у нас сейчас Наполеон.

Где конкретно про C++? Можно пальцем тыкнуть?

Где конкретно про C++? Можно пальцем тыкнуть?

во втором видео, начиная с 40:20

https://disk.yandex.ru/i/K_Fo6ibSy--fFg

Не все уязвимости заносятся специально, но некоторая доля, которая неизвестна.

Насколько я понимаю процесс разработки Linux, любой васян на этапе ревью патча может сказать: «Пацаны, стопе! Тут уязвимость!»

И уязвимость не попадёт в ядро Linux.

Так что разработчики РФ, которым важна безопасность, могли бы обезопасить Linux для всех.

Если они ревьювили и не заметили, то значит они могли написать точно также для решения той же задачи и такая же уязвимость была бы в выдержанном безопасном форке Linux 2.6

Спасибо.

Если вы смогли отсмотреть обе эти части целиком, то решпект и уважуха, мне бы такое терпение.

Заносятся специально, потому что Сноуден, Крипто АГ, сообщения об эксплуатации уязвимостей провластными группировками для преследования инакомыслия, в т.ч. в Европе, а также разный криминал. Не все уязвимости заносятся специально, но некоторая доля, которая неизвестна.

Окей. Однако, это по Вашему является поводом для увеличения количества (-> качество) надзора над кодом или для его уменьшения?

Если говорить об OpenSource, то ничего лучше «чем больше глаз, тем лучше», вы тут не найдёте. Причём, глаза д.б. желательно максимально разные: географически, профессионально, и политически. То есть старая модель всё ещё самая лучшая.

Если говорить про Closed Source, работает тот же принцип, только в рамках некого замкнутого коллектива. С каким успехом - ну, зависит от.

А вот какой принцип сработает «хорошо», так это брать уже отревьюенный опенсорс и накладывать свои патчи от т-ща майора, которые обратно сообществу уже не показывать.

И, это уже чисто стилистическое, выкладывать два начитанных часовых доклада даже без минимальной текстовой аннотации, это как-то не ок. Мы всё-таки не на ютубе

По сути дела там конкретно про C++ ничего нет. Оно сбоку приклеилось к Си. В рамках данной темы для меня достаточно было того, что C++ не закрывает полностью дыр Си. Там ещё многое не упомянуто, например, Ява, на которой тоже пишут подобие ОС (например, по-слухам, в сим-картах подобие Явы) и которой тоже можно плюсиков в табличке наставить.

Согласен, постараюсь исправить. Хотя вторая часть вообще кажется неудачной и нужно её повторить.

Так что разработчики РФ, которым важна безопасность, могли бы обезопасить Linux для всех

Они это и пытаются делать, правда, за денежку. Я вроде не говорил, но в одном из вариантов у меня было, что безопасность для всех не бывает. Безопасность бывает только для кого-то и упирается в вопрос доверия к людям, а не к технологиям. Поэтому безопасный линукс от РусБиТеха возможен только для тех, кто доверяет РусБиТеху. Т.е. Минобороны России может быть его и купит, а минобороны США - нет. Не потому, что в РусБиТехе плохие специалисты, а потому что другая страна.

А то, что за денежку - тут сложно их винить. Безопасность стоит усилий.

Но ведь ничто не мешает любому количеству васянов объединиться в стаю и сделать безопасный линукс без Торвальдса. Но этого не случилось. Почему? Вопрос не ко мне.

Окей. Однако, это по Вашему является поводом для увеличения количества (-> качество) надзора над кодом или для его уменьшения?

• безопасность должна быть в приоритете над функционалом, если мы хотим безопасную ОС
• в частности, если уж линукс, то хотя бы старый, потому что больше глаз по нему прошлось
• в частности, технологии должны быть отличающиеся от Си, и вообще, приоритет безопасности над быстродействием. Т.е. отключаем оптимизации, включаем санитайзеры, пишем вместо Си на чём-то другом.
• нужно не больше или меньше надзора, а достаточный надзор. Т.е. ситуация как на картинке из второго доклада заставляет подозревать, что даже РусБиТех поработал над безопасностью недостаточно хорошо, раз они закрывают дыры не сами, а после того как спустя 10 лет их нашёл кто-то другой. Получается, задача обеспечения безопасности не решена. Но это с оговоркой про их архитектурные примочки, которые в теории могут снижать опасность таких дыр до нуля (но это не проверено). Если линукс так устроен, что за ним нельзя осуществить достаточный надзор, то не нужно пытаться делать из него безопасную ОС
• должна быть реальная ответственность за дыры

безопасность должна быть в приоритете над функционалом, если мы хотим безопасную ОС

Не должна быть, зачем вы вообще ставите такую дихотомию?

в частности, если уж линукс, то хотя бы старый, потому что больше глаз по нему прошлось

Это глупость какая-то, если уж очень надо, можно заморозить какую-нибудь одну (свежую) версию линукса и её уже визировать. Зачем старьё брать, чтобы просто меньше кода читать?

в частности, технологии должны быть отличающиеся от Си, и вообще, приоритет безопасности над быстродействием. Т.е. отключаем оптимизации, включаем санитайзеры, пишем вместо Си на чём-то другом

Ну можно на расте написать. Только оптимизации отключать не надо, пожалуйста 🙏

Хотя я понимаю, к чему вы клоните. Што ш, если выйдет ОС на каком-нибудь лиспе, это тоже будет интересно

должна быть реальная ответственность за дыры

По-подробнее, пожалуйста

P.S. А ещё у вас очень живописные теги, аж слышу, как берёзки зашумели

Избранные теги: славянское по, яос, яр

Не должна быть, зачем вы вообще ставите такую дихотомию?

Я верно понял, что Вам неочевидно, что требования расширения функционала и улучшения безопасности несколько мешают друг другу и требуются пояснения? Кто ещё присоединяется к запросу пояснений или все уже давно разбежались из темы?

Это глупость какая-то, если уж очень надо, можно заморозить какую-нибудь одну (свежую) версию линукса и её уже визировать. Зачем старьё брать, чтобы просто меньше кода читать?

Если Вы что-то не поняли, то глупость, возможно есть. Но не обязательно там, где она видится именно Вам. Там же на графике всё показано. Примерно 20 релизов ядра содержали dirty pipe или dirty cow. Чем больше времени прошло с момента внесения уязвимости, тем выше вероятность её обнаружения. При этом средний срок жизни серьёзной уязвимости до её обнародования исчисляется 3-5 годами (на примере уязвимостей с графика). Т.е. если мы сегодня начнём визировать свежую версию линукса, то мы всем миром где-то через 10-15 лет этот процесс более-менее закончим (найдём, скажем, 2/3 или 9/10 всех дыр и можно будет условно считать, что теперь-то этот «новый» линукс стал относительно безопасным). Это то, что непосредственно следует из рассмотрения графика.

Если же мы возьмём старую версию линукса, то внезапно выяснится, что весь мир уже 10-15 лет занят её визированием.

Если Вы хотите предложить какой-то способ кардинально ускорить процесс нахождения дыр, то я весь внимание, однако сначала подумайте, почему же этот процесс ещё никто не применил? Или где результаты его применения? Если бы кто-то применил этот процесс и опубликовал бы его результаты, то график выглядел бы не так - на нём не было бы дыр, остававшихся неизвестными широкой публике на протяжении 8 лет, а их находили бы, скажем, за 1 год (при 8-кратном ускорении процесса нахождения дыр).

Ведь график из второго видео - это результат всемирных усилий добросовестных разработчиков и исследователей, которые, найдя дыру, не бросаются её эксплуатировать в криминальных или военных целях, а сообщают о ней разработчикам. Т.е. вот всем тысячам глаз потребовалось 6 или 8 лет, чтобы найти dirty pipe/dirty cow.

Если же мы возьмём старую версию линукса, то внезапно выяснится, что весь мир уже 10-15 лет занят её визированием.

Ты уверен? Мне кажется, что весь мир смотрит только последние версии. И если находит уязвимость в новом ядре и она присутствует в старых ядрах, то бекпортируют исправление и для старых ядер.

Ну собственно любое программное обеспечение существует не для обеспечения некоей абстрактной безопасности, а для решения вполне конкретных проблем. Соответственно первично именно создание некоторых возможностей. И только после этого - обеспечение безопасности при выполнении работ с этими возможностями. Так что на мой взгляд функционал-безопасность это не дихотомия, а скорее необходимая связка. Причем именно в таком порядке

Конкретная «проблема»: «безопасно скопировать файл». В том смысле, что без доказанной безопасности (не обращайте внимания на абсурд конкретной формулировки) проблема не является решенной (исходя из её формулировки). Т.е. вставить cp... и убежать со словами «Безопасностью потом займёмся…» не принимается «от слова совсем».

Не знаю, что смотрит мир, однако, когда находят 8-летнюю уязвимость в последней версии, то проверяют, что она работает и для старых версий (см. базы БДУ и CVE). И тем самым, ищут в последней - находятся сразу в пачке (5 версий за год - значит, в 40 версиях). Т.е. сумма работ над каждой версией увеличивается даже после того, как эта версия объявляется устаревшей. К старой версии не выпустят патч, однако по сравнению со стоимостью поиска дыры стоимость патча - это копейки.

Што ш, если выйдет ОС на каком-нибудь лиспе, это тоже будет интересно

Ни на расте, ни на лиспе ОС не выйдет до тех пор, пока люди не поймут, что с линуксом что-то не в порядке. Точнее, она может выйти, но никто не будет ей пользоваться. Пока что нормальность линукса (он плохой, но лучше сделать нельзя) принята, как религиозная догма. Именно над развенчанием данной догмы я и работаю, потому что это ложь, угрожающая безопасности России (да и в общем-то, всех других стран тоже, ведь русские точно так же могут завербовать разработчиков ядра и заплатить им за закладки, которые будут известны только русским, а идеальных способов быстро найти закладки ни у кого в мире нет).

Так телега в итоге против плюсов или против линукса?

Против всего мира, за все хорошее, и что только den73 знает как нужно. По крайне мере так следует из тех 20 минут, что я смог осилить.

Я попозже сделаю видео с разметкой на какой-нибудь платформе и выложу здесь ссылку. Понимаю, что сил смотреть 2 часа не у всех хватит.

«Рабинович напел»

«Рабинович напел»

Ваши же слова: «Сейчас уже нужно делать что-то другое. Я знаю что делать, я могу рассказать.»

Или это вы Рабиновича цитировали?

Осилить 20 минут из 2 часов и на основании этого делать выводы о содержании - это и значит напевать, как Рабинович. Если с материалом не ознакомились, то какой смысл рассказывать о его содержании? Показать Ваш общий подход к работе с информацией? Но такой подход надо не показывать, а скрывать.

Осилить 20 минут из 2 часов и на основании этого делать выводы о содержании - это и значит напевать, как Рабинович.

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

Я тут уже несколько раз дискутировал с вами и получил представление о вашей упорото своеобразности. Так что перед просмотром видео уже предполагал уровень качества. Именно это и получил. Уж проссыте, что не смог осилить все два часа вашего унылого потока сознания.

Пожалуй, главная вещь, которую хочется у вас уточнить в связи с этим: вам когда-нибудь приходилось организовывать процесс разработки программного продукта? Если да, то какого масштаба и сколько людей было у вас в подчинении?

Если у тебя есть тухлое яйцо, понюхай его ещё раз.

Ну собственно любое программное обеспечение существует не для обеспечения некоей абстрактной безопасности, а для решения вполне конкретных проблем. Соответственно первично именно создание некоторых возможностей.

Допустим, мы создаём защищённый канал связи для передачи секретных сведений. У него может быть 3 варианта состояний в системе координат «функционал, безопасность»

• отсутствует функционал - используем фельдъегерскую почту, голубей или что мы там раньше использовали до компьютеров
• присутствует функционал, но отсутствует безопасность - самый плохой вариант, мы проиграем войну и нас убьют. Поэтому, если это выявляется, то привлекаем к ответственности того, кто нам это впарил, и переходим на почтовых голубей (если нас не успеют поубивать до этого момента)
• присутствует функционал и обеспечена безопасность - только тогда можно пользоваться.
• присутствует безопасность, отсутствует функционал - так не бывает.

Вариант четвертый - пока кто то занят бесконечной разработкой требований при отсутствии самого протокола противник использует любой разработанный им протокол и постепенно доводит его до ума. И при этом выигрывает. Потому что а) у него уже есть решение б) у вас такого решения нет