И да, даже они не будут поддерживать совместимость бесконечно
Они будут поддерживать совместимость бесконечно. Потому что задачи у них немного другие. Не постоянная расширяемость и обновляемость, а поддержка тех стандартов, что указаны в README.
P.S. если не ошибаюсь, то именно эту ошибку я вижу у половины пакетов которые выкидывают из тестируемого дебиана.
Можно примеры названий таких пакетов? Я без подколки, мне правда интересно, что за код с функциями без прототипов сумел дожить до Debian Testing 20-аж-24 года.
-ffast-math опасна, и прятать её за -Ofast не лучший вариант.
ЛОЛ, а что из названия fast-math как-то имплицитно понятно что «она опасна»? Я понимаю что в документации написано, но там про fast написано. Так-то и за -O3 много чего спрятано.
Если твой код не соответствует никакому стандарту, это проблема только твоего кода.
Нифига подобного. Ещё скажите, что K&R кода не существует. Хотя в то время никакого стандарта не было, а правильно/неправильно определялось по соответствию книги «The C programming language».
А вот если в стандарте написана хрень, как это бывает очень часто, он должен игнорироваться. Можете в туалете воспользоваться его листами.
Нифига подобного. Ещё скажите, что K&R кода не существует. Хотя в то время никакого стандарта не было, а правильно/неправильно определялось по соответствию книги «The C programming language».
Не знаю, что такое K&R код, но если компилятору передают флажок -std=c99 то компилятор справедливо ожидает код в соответствующем стандарте. В мануале gcc ничего не написано про поддержку K&R, поэтому любителям археологии, возможно, не повезло.
А вот если в стандарте написана хрень, как это бывает очень часто, он должен игнорироваться. Можете в туалете воспользоваться его листами.
Главное убедить в этом разработчиков gcc, они-то так не считают.
Был подобный случай на первой работе, я полдня с ума сходил. Функция в return возвращала одно (видно было и принтами, и отладчиком), а на принимающей стороне оказывалось другое. Тот же implicit int оказался.
Главное убедить в этом разработчиков gcc, они-то так не считают.
У кого-то есть сомнения, что текущие авторы gcc творят хрень? Так вы вспомните, как сильно их любит, например, финский босс.
gcc более-менее был где-то до 3.x включительно. ЕМНИП начиная с 5.x зачем-то Сишный код (который не переписывали и оставили идеологически сишным) засунули в классы C++. И теперь даже скомпилировать компилятор C без компилятора C++ нельзя. ЧТО ЭТО ЗА ЕРУНДА?
В мануале gcc ничего не написано про поддержку K&R, поэтому любителям археологии, возможно, не повезло.
Это не правда. Gcc частично совместим с K&R C. Читай про -traditional.
У кого-то есть сомнения, что текущие авторы gcc творят хрень? Так вы вспомните, как сильно их любит, например, финский босс.
У меня есть.
gcc более-менее был где-то до 3.x включительно. ЕМНИП начиная с 5.x зачем-то Сишный код (который не переписывали и оставили идеологически сишным) засунули в классы C++. И теперь даже скомпилировать компилятор C без компилятора C++ нельзя. ЧТО ЭТО ЗА ЕРУНДА?
Видимо им удобней писать на С++.
Это не правда. Gcc частично совместим с K&R C. Читай про -traditional.
-traditional
-traditional-cpp
Try to imitate the behavior of pre-standard C preprocessors, as opposed to ISO C preprocessors. See the GNU CPP manual for details.
Note that GCC does not otherwise attempt to emulate a pre-standard C compiler, and these options are only supported with the -E switch, or when invoking CPP explicitly.
Всё, что делает этот флаг - немного меняет поведение препроцессора. Не думаю, что это правильно называть частичной совместимостью.
Хз, Armadillo детектит и ругается, если fast_math включена. Где-то находит обоснование. Ну и… я ещё не видел «не говнокода» ;-) везде, рано или поздно что-то всплывает, как в Сене.
Я думаю, что это твои закидоны просто. Если бы они не умели программировать, gcc бы не оставался одним из лидирующим компиляторов на протяжение десятилетий.
Сишный код в классах ничуть не лучше, наоборот, это уже не Си, но еще и не Си++.
Если код для компиляции требует g++, значит это С++. То, что он не нравится тебе лично - это только твои проблемы. Я, к примеру, считаю, что 50% С++ фич вредны, но это не делает оставшиеся 50% бесполезными. Поэтому оптимальный способ использовать С++ это как раз писать в стиле С, но дополняя его в нужных местах отсутствующими фичами.
То правильно делает, что ругается. Это «числодробилка» там «быстрая математика» может выстрелить. Но и там если есть уверенность что не получишь субнормальные числа, то заюзать можно. Хотя я бы сиканул такое в «прод» врубать))
Ну и… я ещё не видел «не говнокода»
Да хоть тот же Qt. У них в «окошках» QPoint это целое, а для промежуточных вычислений QPointF используется, который float. Тут надо умудриться чтобы что-то «всплыло»))
От этого выкинули все пакеты, которые без него не могут. Разработчики дистрибутива не готовы брать на себя ответственность за софт, за который даже авторы не ручаются.
В С функции являются первичным строительным блоком. Дизайн программы строится исходя из функциональной декомпозиции задачи. Классы используются только там, где они действительно нужны. В С++ всё с точностью до наоборот. Дизайн программы строится исходя из ООП декомпозиции задачи. Классы натягиваются на всё, что движется, а на то, что не движется - натягиваются синглтоны.
В С++ есть ублюдочная стандартная библиотека и не менее ублюдочный буст. В стиле С она не используется, классы коллекций пишутся по месту при необходимости.
Среди поклонников С++ есть мода на вычисления во время компиляции. Когда из шаблонов делается второй недоязык и программы начинают писать на этом недоязыке. На С так не делают. Если нужно сгенерировать программу программой, то пишут программу, генерирующую код программы. Но нужно это крайне редко. Единственная причина использовать шаблоны это написать класс типа ring_buffer или функцию max.
В С++ любят имитировать бурную деятельность, создавая 10 видов указателей, 5 кастов и прочую чушь. В С так не делают. Указатель это указатель. Каст это каст. Программа на С опасна, полна уязвимостей и это хорошо. Это просто принимается за реальность, исправляя по мере возможности, а не пытаются с этим бороться.
Ещё не слишком формализуемый признак, но всё же. В С каждая строчка делает очевидную вещь. Ничего неочевидного, скрытого не происходит. В C++ в одной строчке легко может скрываться что угодно. В C не используют оператор битового сдвига для ввода/вывода, к примеру. Для ввода-вывода есть функции read/write. В C++ даже запятая может быть перегружена и вызывать код произвольной сложности.