юнионы в C++

Явы хватит?

Явы хватит?

нет конечно. на ней драйвер фс не напишешь например. или то, что влезет в 32 кб памяти.

А я и не утверждал, что все эти языки пригодны для написания драйверов ФС.

а нафиг они тогда нужны? вы без фс не проживете. у всего своя ниша, короче.

Ява не нужна?

Ява не нужна?

нет конечно.

Ну ок, может она и не нужна, но она популярна и проблему взлома через переполнение буфера решает. Я привёл пример в подтверждение своей точки зрения.

проблему взлома через переполнение буфера решает…

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

а порочный, за выход за границу массива, код видимо писали студенты и индусы. это их проблема, а не языка с++.

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

Отлично, а теперь постарайся прочитать моё утверждение, после которого ты попросил языки в студию, и найти там C++

критиковать с++ это все равно что критиковать автомобиль за то, что на нем можно врезаться в столб. ну можно. а на трамвае - нельзя… но это не значит, что всем надо пересесть на трамваи.

Я привёл пример языка, который ты просил?

Я привёл пример языка, который ты просил?

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

Значит, информация не передаётся и дальнейший разговор бессмысленнен.

Есть две полярные точки зрения на вопрос:
а) С++ перекрывает Си, поэтому там всё сделано по-другому, поэтому безопасность выше б) С++ - наследник Си и в целом наследует его недостатки.

Поскольку я мало пишу на Си и ещё меньше на Си++, у меня нет сложившегося мнения на эту тему. А у ЛОРа наверняка есть мнение, даже несколько.

Интересно получается. Ты сам признаешь, что в С++ ты ноль, приглашаешь ЛОР высказаться на тему. Но при этом заранее объявляешь, что

Пишу телегу против плюсов

Типа ты «принимаешь» только доводы против плюсов, вместо объективного резюме треда. Фу таким быть!

Кстати, с жанровой точки зрения ты пишешь пасквиль

Кстати, с жанровой точки зрения ты пишешь пасквиль

он пишет донос.

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

Слабость в прокладке между стулом и клавиатурой.

Что конкретно я не принял из аргументов за плюсы?

Это от языка не зависит.

У опытных крестовиков никогда не бывает проектов, высирающих тонны варнингов в сторонних хедерах

Они знают про -isystem.

Что конкретно я не принял из аргументов за плюсы?

Узнаем, когда выйдет твоя «телега»! Обязательно кидай псто в тему, я подписался

Слабость в прокладке между стулом и клавиатурой.

Это от языка не зависит.

Но для С++ качество этой прокладки важнее, поскольку язык позволяет «слишком многое»

порядок сложения важен

Он останется одинаковым, то есть аргументы в функцию передадутся именно в таком порядке.

Тут суть в другом. Чтобы вызвать эту функцию тебе надо сначала получить значения из a b и c, и вот в каком порядке эти функции будут вызываться - неопределено, но и разницы нет. Это важно только из-за исключений (если бы в какую то из них передать скажем new foo{}, то могла бы быть утечка).

Зы: сорян, если это уже написали

а когда я return забыл он от меня -fpermissive требовал, чтобы собраться

в конане бывают странные ограничения для сборки пакетов. Вроде OpenSSL запрещено собирать под x32 винду

Учитывая дефицит кадров в ИТ, я прекрасно понимаю твоё желание продать свои навыки подороже (ты ведь наверняка намекаешь, что являешься подходящей прокладкой, но других таких как ты - немного), а с точки зрения интересов отрасли это как раз плохо. Ты же понимаешь, отрасли нужны легко заменяемые, быстрообучаемые винтики. Кроме того, задачи находятся не в языке, а в предметной области. Язык является вспомогательным инструментом. Если этот инструмент таков, что его использование требует особых навыков, то для промышленности такой инструмент не подходит хотя бы потому, что изучение языка отвлекает от изучения предметной области. При найме специалистов приходится смотреть на знание языка, а знание предметной области отходит на второй план. Т.е. разработка получается дороже. А это не нужно.

Разница между (a + b) + c и a + (b + c) вообще-то есть, и для целочисленных типов, и для плавающей точки. Насчёт того, что «результат неважен» - ну я не знаю, какого рода числодробилки товарищ писал 20 лет. Но как минимум чёткий порядок вычислений полезен для регрессионных тестов. Есть ли реальные примеры, когда в формуле складываются такие величины, что может критично накопиться погрешность именно из-за изменения порядка вычислений - я не возьмусь уверенно сказать. Но в численных методах всё довольно тонко и там неопределённость порядка вычислений может добавить неприятностей (а их там и так немало).

Ну т.е. про пасквиль - это голословные обвинения. Ок, понял.

https://github.com/maxking/linux-vulnerabilities-10-years/blob/master/thesis.org - тут приведена статистика по уязвимостям, насколько я понял, в ядре Linux за 2007-2017 год. Всего 1100 записей, из них неинициализированные данные отвечают за 12%, висячие указатели - за 4%, доступ за пределами буфера - 13%. Т.е. причины, вытекающие из выбора Си в качестве системного языка, дали 29% всех уязвимостей при реальном качестве прокладки между экраном и клавиатурой, которое достигнуто в проекте ядра Linux. На самом деле не так и много, как я думал. Для сравнения, разыменование нулевого указателя - 14%, а неверная проверка прав доступа - 12%. Но скорее всего, разыменование нулевого указателя не должно приводить ко взлому, а максимум это ддос-атака. Впрочем, там целый диссер.

О боги! В коде ядра разыменование нулевого указателя - это не ошибка. Всё, пипец, приехали.

В коде ядра разыменование нулевого указателя - это не ошибка. Всё, пипец, приехали.

а есть статистика о возрасте, уровне образования и национальности писателей ядра линуха?

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

Отрасли все нужны. Для винтиков и шпунтиков есть безопасные языки, упомянутая тобой Джава — её кто-то забирает? Что за дебильная логика «если инструменту нельзя научить любую макаку - инструмент негоден»?

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

Извини, но ты бредишь. Язык является главным, а в некоторых случаях и единственным инструментом описания и решения этих самых задач, поэтому вспомогательным быть не может. С++ и Java создавались под разные предметные области, посему и выглядят по разному. alysnix уже пытался тебе это объяснить, но ты съехал

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

Без комментариев. Крайне оторванный от реальности тезис

У меня нет. Было бы интересно другое - проследить трудовую биографию авторов уязвимостей и посмотреть, не серийно ли они этим занимаются. Хотя конечно нужно быть полным головотяпом, чтобы делать это в открытую, но что-то мне подсказывает, что и такое может быть, судя по эпическим фейлам западных спецслужб, типа создания соцсети для секретных агентов, которая, вероятно, стоила жизни многим агентам США в Иране и Китае.

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

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

Выложи не пасквиль, а объективный обзор языка — и я публично покаюсь, без проблем =) Это будет достаточная сатисфакция твоему самолюбию?

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

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

Даже если я и ошибся про ассоциативность в выражениях, эта ситуация может возникнуть из-за порядка вычисления аргументов при наличии побочных эффектов, так что не поможет :)

Но в численных методах всё довольно тонко и там неопределённость порядка вычислений может добавить неприятностей (а их там и так немало).

Внезапно при многопоточных вычислениях порядок и так оказывается неопределен, и ЯП тут уже непричем. Упс?

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

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

ты ведь наверняка намекаешь, что являешься подходящей прокладкой, но других таких как ты - немного

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

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

ИТ большое. Есть области (например HPC) где нужно решать специфические задачи, для которых С++ сейчас безальтернативен. Вам об этом тут говорят хором третью страницу, но Вы никого не хотите слышать, Вы хотите фантазировать об ужасах смены порядка вычислений.

То что Вы никогда не работали над задачами где действительно нужны инструменты вроде С++, говорит не о проблемах С++ а о Вашем опыте. Но зачем Вы тогда пытаетесь рассуждать о том, в чем не разбираетесь?! Я же не лезу с рассуждениями о том как надо браузеры или ОС писать, каждому свое…

Простите за резкость.

Пишу телегу против плюсов.

совсем делать нечего?

а) С++ перекрывает Си, поэтому там всё сделано по-другому, поэтому безопасность выше б) С++ - наследник Си и в целом наследует его недостатки.

Первое не исключает второе. В C++ есть более безопасные аналоги стандартных типов данных, но из-за совместимости с С некоторые программисты могут злоупотреблять сишным кодом.

проследить трудовую биографию авторов уязвимостей

создания соцсети для секретных агентов

смешались в кучу кони, люди…

Поскольку я мало пишу на Си и ещё меньше на Си++, у меня нет сложившегося мнения на эту тему.

Я сейчас выскажу непопулярное мнение, но интернет уже и без того полон эмоциальными статьями «какое $THINGNAME плохое» от людей, которые $THINGNAME только в видеообзорах видели. Точно ли нужно еще одну такую статью делать?

union же появились в С не от хорошей жизни, а для экономии памяти. Кроме килобайтовых объёмов времён бурной молодости K&R, обратной совместимости и непреодолимого желания поймать UB, какие существуют сценарии использования union сейчас?

Знаю лишь один пример (ещё С++98), и то, он чисто для эргономичности – alialsing:

union {
	struct {
            float x;
            float y;
            float z;
	};
		
	float elements[3];
};

И это замечательно!

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

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

Единственный здравый тезис во всем комментарии.

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

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

Ух-ты. Спасибо!

Сходу ответы на вопросы ТС:

неумные указатели

Неумные указатели не обязательно приводят к утечкам если следовать этому:

C.31: All resources acquired by a class must be released by the class’s destructor

R.11: Avoid calling new and delete explicitly

R.12: Immediately give the result of an explicit resource allocation to a manager object

R.13: Perform at most one explicit resource allocation in a single expression statement

Да и вообще много по поиску по словам leak и smart pointer.

нуль-терминированные строки

Вот прямая рекомендация:

SL.str.1: Use std::string to own character sequences

юнионы

P.4: Ideally, a program should be statically type safe

И в этом пункте в деталях:

unions – use variant (in C++17)

Упс? Нет, но данная тема не об этом.

ЯП который не обеспечивает сохранения порядка непригоден нигде и и не для чего

Не надо приписывать мне то, чего я не говорил. Я всего лишь отметил, что определённый порядок вычислений даёт Фортрану некоторые преимущества над плюсами в плане выразительности. А так - я не знаю и не говорю.

Таких как Crocodoom и правда немного. Я рад за него, но не за отрасль.

Спасибо, это в целом понятно, хотя и не факт, что любую задачу можно решить таким способом (точнее сказать, наверняка не любую). А насчёт юнионов - вот берём первое, что попалось - libsdl2 - и там есть union.

Во первых, если тебя такие тонкости интересуют, то double может лучше не использовать вобще?

Во вторых я говорил о примере, приведённом в коменте. foo(a(), b(), c()); и вот тут нет разницы в каком порядке получатся аргументы функции, к моменту вызова они все будут доступны. Единственное - подвох с исключениями, но поэтому есть make_unique и прочее..

какие существуют сценарии использования union сейчас?

https://git.haiku-os.org/haiku/tree/headers/private/system/arch/riscv64/arch_cpu_defs.h#n30

ПРедставь, что у тебя есть некий state (правая часть в уравнении), и что a, b и с её изменяют. Тогда получается, что порядок применения изменений не определён в C++, но определён в ФОртране. Некритично, но всё же грабельки есть.

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