Почему писать на С - извращение?

DO-254 и DO-178C гугли. Еще IEC/МЭК 61508 вот в них применяется. Т.к. прогать с доказухой на диалекте ады SPARK проще чем на Ц.

а мой код на C работает на нескольких электростанциях, пусть и не на атомных

В качестве чего? или как пруфается на соответствие стандартам безопасности? Если код... э... не требует сертификации в силу ниши применения (есть и такие ниши и на АЭС... или рядом) — ну какбэ может даже FoxPro под MS-DOS работать где-то рядом, например в АСУП (бухгалтерия и документооборот) целлюлознобумажного комбината лично видел (а софт на АСУТП того же предприятия, управляющий технологичеаким процессом, разумеется подкреплен чем-то кроме честного слова разрабов и даже кроме честного слова вендоров оборудования :)

А уровень топиков в /dev всё продолжает расти, я смотрю.

Прочитал первую страницу. И до сих пор нету обсуждения препроцессора и языка B. Странно. Ведь с этого всё и начиналось, с defines.

если все ворнинги включить, будет похоже на misra ?

Нет :) misra путь боле.. Более жестких (само)ограничений.

Существует, например, MISRA C, подход к разработке, позволяющий писать именно безопасные программы на C.

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

«misra путь боле..»

Собственно, это примерно все что нужно знать про такие «подходы» :) 

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

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

Это всё не про C. Назвать C простым языком может только тот, кто никогда стандарт этого языка не читал.

К слову, забавный факт: сейчас нет ни одного «промышленного» компилятора C, написанного на нём самом. Ну так, к слову.

Что такое «промышленный»? Почему gcc им не является?

Похоже же. Ну если так, даже, почитал про мисра, у меня ошибок выдавать не должна. Ну вообще, нужно будет посмотреть.

Потому что gcc не написан на С.

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

Язык Си это язык прямого оперирования с памятью и числами посредством использования синтаксиса для организации логики оперирования памятью и числами.

Но все от него хотят совсем другое. Зачем? Непонятно. Это как предъявлять претензии повару, зачем варить суп из десятка ингридиентов? Будет мусор, шелуха от лука, очистки, всё это утечёт память просыплется, столько телодвижений хоспади зааачееем!!? Ведь можно просто заварить дошик и всё, там всё готово, всё в контейнерах пакетиках, просто добавь своей логики в три строчки воды и всё!

:D

А на чём он написан (gcc как часть GCC)? Просто gfortran в основном написан на C. Сам проект GCC почти наполовину написан на C плюс куски на разных языках для фронтэндов, входящих в состав GCC.

По-моему там везде С++.

https://github.com/gcc-mirror/gcc/tree/master/gcc

https://github.com/gcc-mirror/gcc/tree/master/gcc/fortran

и даже тут: https://github.com/gcc-mirror/gcc/tree/master/gcc/rust

По расширению файлов определил?

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

dron@gnu:~/Рабочий-стол/псс/gcc-10-10.4.0$ ls -R ./ | grep "\.cc" | wc -l
9217
dron@gnu:~/Рабочий-стол/псс/gcc-10-10.4.0$ ls -R ./ | grep "\.c" | wc -l
52606
dron@gnu:~/Рабочий-стол/псс/gcc-10-10.4.0$ 

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

да. сс не похож на с

Врать не хорошо, гцц и на С и на С++. Там нет доминирования С++ кода. Хотя если брать чисто прям чисто компилятор и игнорировать всё без чего его собрать невозможно, то да. Ладно

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

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

Но всякие lib* (включая libgcc) на Си. большей частью. На C++, так на C++. Его на pascal писали. А почему это так важно?

А почему это так важно?

не знаю

Там и то что в файлах .сс простой код си. Почему это важно. Это просто дешёвый троллинг, от функциональщиков и крестовиков.

Местами там есть namespace и class.

Ну там есть немного.

Потому что gcc на плюсах.

Язык Си это язык прямого оперирования с памятью и числами посредством использования синтаксиса для организации логики оперирования памятью и числами.

Хахахахахахахахах! Особенно при том, что компилятор выкидывает обращения к памяти на любой чих. Ага. Не гони ересь тут.

Ну и ладно. Надо писать на том, на чём удобнее в конкретном случае.

Жду компилятор C на JavaScript. Сейчас на нём всем удобно писать.

Жди. Можешь даже приступить к написанию.

Напиши нормально я ничего не понял. Какой компилятор? Причём тут компилятор.

В чём проблема вот https://github.com/Captainarash/CaptCC по первому же запросу. Есть интерпретаторы си, в чём вообще проблема и как это относится к языку? Интерпретатор/компилятор Си можно и на sh написать.

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

Или использовать Glib, где всё это есть?🤔 Да не, бред какой-то.

а ты не меня спрашивай, а тех кто велосипедит весь этот колхоз на C, или ты уверен что 50% проектов на С хотябы использует glib?

Я лично пишу на C++, если мне нужны какие либо новые возможности на старой системе достаточно поставить компилятор поновее из devtoolset (так срабатывает на centos5, centos6, centos7), с glib же все сложнее, системная версионная либа.

Для таких целей придуманы контейнеры. Неужели кто-то до сих пор на хосте разработку ведёт, да ещё и с тулчейном из реп?

почему программисты - копрофилы?

а разве нет?

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

Потому что если у сишника не хватило сил освоить самые азы C++, то он профнепригоден. А преимущества плюсов сразу лезут (при прочих равных!), когда слов в коде становится меньше за счет использования стандартной либы.

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

Но gcc и не совсем Си.

да, именно так, слов меньше для сопоставимой семантики

Си это уже не язык программирования, а язык интерфейсов: https://faultlore.com/blah/c-isnt-a-language/

Ага, все эти многословные касты, ко_елды, неконтролируемый поток const, final, noexept, и т. п. Нагромождения шаблонов, которые спокойно сочетаются в одном проекте с развесистой макроснёй. Потоки геттеров, сеттеров, всего этого бойлерплейта. С++ ужасно многословен.

тебя никто не заставляет на с++20 писать. Все компиляторы, о которых я знаю, поддерживают с++98

в статье словоблудие и нытье. С - язык программирования per se.

Си это уже не язык программирования, а язык интерфейсов

Только для тех кто программирует не на Си, но хочет получить доступ к ядерным подсистемам и библиотекам не на своём языке. Так же как java не является языком программирования для тех кто пишет приложения на Си под android ndk где они так же как и автор статьи вынуждены пользоваться интерфейсом другого языка. И в первом и втором случае Си как и Java как и любой другой язык который приходится использовать не используются как язык программирования, а используются как прослойка для доступа к чему либо. И утверждать что отныне язык XXX теперь не язык просто патамушта я его не использую звучит как-то туповато.

Вот у нас есть сишные интерфейсы ядра, всем приходится с ними считаться, скоро у нас будет два интерфейса Rust и C и придётся считаться с двумя интерфейсами. И чво?

Ладно так и запишу, языков программирования нету. Дальше там конечно есть по делу о том что не могут реализации договорится об общем и всё такое прочее. Но это совсем другая песня. Ой ABI поломано, ой long long везде разный, ну так блин можно писать как переносимый так и непереносимый код, никто не ограничивает, даже переполнение типа является нормой и штатным поведением от которого горит у всех. Нет смысла писать переносимый код для штучного товара, а если нужно перенести, то код переносят и это будет касаться любого языка, ой какой переносимый код на python2 когда на целевой системе есть только трёшка. Внезапно да! =)

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

Появится 9битный или 27 битный компьютер на него можно будет современным/или древним компилятором собрать программу на си с правкой CHAR_BITS, ассемблерных вставок и прочего, не по мановению руки, но можно ибо иерархичная типизация порешает. Да специфичный код под такое железо не будет особо переносим, так же непереносим как и на любом другом языке если не предпринимать предварительных мер.

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

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

Лучше бы какой-нибудь protobuf для этих целей использовали.

Эх, не буду новую тему создавать, я уже не торт, что был раньше, просто тут напишу:

Почему писать на расте это не извращение?

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

Ам. Даже плюсовый ABI нынче вполне стабилен, а уж C-шный и подавно. Я тут намедни пытался пару «безобидных» изменений пропихнуть (Вы в курсе что gcc в 64битах алиасит int64_t на long а не long long? Это вызывает массу ненужных практических проблем). Без шансов - позиция gcc devs - never again…

для тех кто пишет приложения на Си под android ndk где они так же как и автор статьи вынуждены пользоваться интерфейсом другого языка

Ага, как же. Весь JNI описан в терминах сишных структур. При этом даже если пишешь, например, на Rust, в котором есть классы и методы, то будешь общаться с Java через сишные структуры.

Java является таким же интерфейсом только для языков, компилирующихся в JVM. И также программистам, например, на Clojure приходится её изучать, даже если они на ней не собираются писать.

скоро у нас будет два интерфейса Rust и C и придётся считаться с двумя интерфейсами

Да ладно. Неужели появятся системные вызовы, передающие и получающие объекты Rust?

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

Только для склейки всё приходится делать сишкой. В результате нет нормального интерфейса для публикации классов, замыканий, чисел (сишный не всегда совместим даже внутри одной ОС), бесконечных списков, нестрогих функций, …

В питоне есть классы и в Си++ есть классы. Но PyQt работает через сишные структуры.

а уж C-шный и подавно

По ссылке пример про unsigned __int128. Даже в gcc и clang разные байты и разное выравнивание.