Нужна ли нам замена языка C?

Original author: Erik Engheim
  • Translation
Язык программирования C даже сегодня находится в списке наиболее популярных используемых языков, несмотря на то, что он был выпущен аж в 1972 году и по современным стандартам имеет довольно много ограничений и изъянов.


Популярность языков программирования в 2020 по индексу TIOBE

И это основная причина, по которой C нужно заменить. На C/C++ написано слишком много критически важного ПО, что имеет обширные последствия. Один из примеров — баги в библиотеках наподобие OpenSSL. Язык C печально известен возникновением таких проблем, как переполнения буфера. C — это язык, позволяющий выстрелить себе в ногу слишком большим количеством способов.

Такое заявление со стороны активного поклонника динамических языков может показаться странным. Однако проблема здесь заключается в безопасности типов. Динамические языки наподобие Python и Julia обычно обнаруживают неправильное применение типов, например, использование integer в конструкции if. Возможно, динамические языки не отлавливают проблемы на этапе компиляции, но если у них есть система сильной типизации, то многие проблемы обнаруживаются во время выполнения. Это особенно важно для защищённости. Уязвимости защиты по большей мере сводятся к созданию неопределённого поведения, а не к контролируемому завершению.

Но если C настолько плох, то почему его ещё не заменили? На то есть множество причин. Частично его уже заменили. Java, C#, C++ и многие другие языки уже взяли на себя задачи, которые раньше выполнялись на C.

То есть вопрос больше в оставшемся ПО, в котором C по-прежнему доминирует:

  • Ядра операционных систем, например, Linux.
  • Микроконтроллеры
  • Видеокодеки
  • Общие низкоуровневые библиотеки наподобие OpenSSL
  • Инструменты командной строки Unix наподобие ls, cat и git

Почему C по-прежнему доминирует в этих областях? Потому что до недавнего времени альтернативы были не особо хороши. Многие языки 90-х, такие как Java, C#, VB.NET и F#, казалось, в основном сосредоточены на создании управляемых языков со сборкой мусора. А это не особо подходящее решение для перечисленных выше примеров.

В 80-х и 90-х начали появляться и другие языки, такие как Perl, Python, Ruby, JavaScript, но ни один из них не подходит для этих задач.

Разумеется, всегда существовали и другие языки со статической типизацией, например, Ada, Modula-2 и т.п. Однако они чаще всего не стремились подстроиться под уже имеющийся у программистов набор навыков или их нельзя было удобно использовать с уже существующими библиотеками C.

Были языки наподобие D, но он имеет уровень сложности C++, что, вероятно, непривлекательно для разработчиков на C. Кроме того, для него изначально требовалась сборка мусора, из-за чего он неприменим во многих упомянутых областях. Никому не нужно, чтобы сборщик мусора срабатывал, когда вы стремитесь поддерживать постоянную частоту кадров.

Go и Rust демонстрируют потенциал


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

LLVM: недостающий кусок пазла


Я считаю, что большая часть возможностей по созданию альтернативы C существует сегодня благодаря зрелости LLVM. Существование LLVM означает, что решена сложная задача генерирования высокопроизводительного кода и многоплатформенности. Благодаря нему разработка языков программирования становится доступнее гораздо большему количеству людей.

И Go, и Rust дают нам некоторое представление о том, как можно переосмыслить C/C++; сейчас начинает возникать небольшая кустарная отрасль возможных альтернатив на замену C, вооружённая этим представлением и LLVM:

  • Zig, который я довольно подробно описывал здесь.
  • Odin — замена C, во многом похожий на Go.
  • Язык V. Ещё один C-подобный язык, разработчики которого сильно вдохновлялись Go и Rust.

Что такое язык на замену C?


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

  • Простота использования уже имеющихся библиотек C. Ada, Modula-2 и прочие провалились в основном потому, что их нельзя эффективно использовать с огромной экосистемой C.
  • Создание языка на основе устоявшихся знаний и договорённостей. Go очень быстро набирает популярность, потому что, несмотря на некоторые изменения синтаксиса, API и способ кодинга очень знакомы программисту на C.
  • Нет сборки мусора/ручное управление памятью. C доминирует в областях, где требуется тщательный контроль над использованием памяти. В эту нишу сборка мусора просто не уместится. Именно это помешало Go полностью заменить C.
  • Малый размер получающихся двоичных файлов. Как и C, Zig, например, позволяет создавать очень маленькие двоичные файлы. Если вы хотите создать альтернативный язык для сферы встроенных устройств, то нельзя взять язык наподобие Go, создающий большие двоичные файлы.
  • Дружественность на уровне систем. Требуется возможность манипулирования битами и байтами. Нужны хорошие бинарные операторы и указатели. Во многих языках, появившихся за последние десятилетия, нет нужной реализации указателей. В Java слово «указатель» превратилось в ругательство, но в Go они частично вернулись.
  • Постепенная замена кода на C. Наличие превосходной двоичной совместимости с C.

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

При помощи языков наподобие Zig это реализовать довольно легко.

Вывод


Есть множество причин, по которым нам нужно заменить C, а основная причина того, что это не было сделано раньше — отсутствие внимания к этой теме и недостаток подходящих инструментов. И не факт, что на такой шаг обязательно решится крупная организация. Чтобы попытаться это сделать, нужна лёгкость, которой обладает кустарная отрасль, состоящая из отдельных людей. Имея на руках инструмент наподобие LLVM и Go в качестве источника вдохновения, сегодня это вполне можно реализовать.

Считаю ли я лично, что C нужно заменить? Я бы не стал надеяться на быстрые перемены. Это длительный процесс, и у нас пока нет явных победителей. Большие организации не будут переходить на Zig, Odin, V или что-то другое, пока альтернатива не сформируется полностью.

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

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



На правах рекламы


Эпичные серверы для разработчиков и не только! Дешёвые VDS на базе новейших процессоров AMD EPYC и хранилища на основе NVMe дисков от Intel для размещения проектов любой сложности, от корпоративных сетей и игровых проектов до лендингов и VPN. Вы можете создать собственную конфигурацию сервера в пару кликов!

VDSina.ru
Серверы в Москве и Амстердаме

Comments 277

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

    Основная причина отсутствие внимания к этой теме? Странно. А может отсутствие внимание и говорит как раз в защиту C! Кто мешает разрабатывать языки? Никто и ничто, разрабатывайте на здоровье. А время покажет станет кто-нибудь из них достойной заменой C.

      +29
      Это Штирлиц. Сейсас будет драка.


      За что вы, прикладники, так не любите С? Ведь вы на нем не пишите. Почему Вы считаете себя в праве ограничивать системщиков в выборе подходящих инструментов? Давайте еще и ассемблер отменим. Он вообще ни разу не кроссплатформенный язык да еще и с типизацией куда как более строгой, чем в том же C.

      Язык C жив до сих пор, потому что в своей области он самый удобный. Везде, где он был неудобен его уже заменили. Но код, непосредственно работающий на железе… Ну пусть пробуют. С прост в освоении и понимании. И, самое главное, самодостаточен. Libc и Posix в общем случае даже знать не надо чтобы писать код для микроконтроллера или процессора (будь то DSP или процессор общего назначения). Кросплатформенный ассемблер. И это ровно тот инструмент, который нужен разработчику. Просто не мешайте работать.
        +15

        Инструмент вытащили далеко за области его применимости, и обнаружили — внезапно! — что он там плохо работает. И решили его заменить. Ну, да, писать либу размера и функциональности как OpenSSL на С — так себе начинание. Насчёт ядра Linux, например, уже нельзя сказать так уверенно. А что-то, что работает без ОС, "оживить" с помощью С — самое то.
        Но ведь это нюансы, о которых мало кто думает. У меня многие знакомые программисты при слове "программировать" не вспоминают embedded даже с подсказкой. Типа "на железках дрова сами заводятся, как мыши в сене".

          +16
          Проблема же не в том, что вы на нем работаете. Проблема очевидно в том, что зачастую получается плохо. Ну или хорошо — но очень медленно (или дорого, или оба сразу). В том, что иногда CVE на CVE сидит, и другим CVE погоняет. Если бы всего этого не наблюдалось в природе — никто бы про замену и не думал.
            0
            Нет, это не Штирлиц!


            Хм. Ошибка выжившего?

            Да ладно! А может наоборот — обилие CVE просто потому что код доступен для анализа и сделаны «best practice»? И стало просто отслеживать. Для остальных языков просто пока нет такого инструментария? Так это только вопрос времени…
              +2
              Ну, не исключено. В смысле, я могу поверить, что хороших измерений, которые бы показали, что число багов в коде на С больше, чем скажем на Rust, сильно больше и они серьезнее — что этих измерений нет. Или они не показывают причины багов — то ли это свойство языка, то ли скажем показатель уровня квалификации пишущего (а это вообще сложно разделить, очень).

              P.S. Минус не мой, если что. Может ваше мнение и неверное — но и мое в общем не более чем экспертная оценка, ни на чем более не основано.
                +2
                Да нет же — это точно был Штирлиц!


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

                Для меня С основной инструмент. И используется он именно в самой низкоуровневой части. И Linux'овой, и FreeRTOS'ной и просто прямо по железу. Я так скажу — сегодня альтернатив ему нет. Нишевые задачи имеют нишевые решения, но пока только С обеспечивает возможность писать относительно быстрый, относительно безопасный, относительно переносимый и относительно хорошо поддерживаемый в будущем низкоуровневый код одновременно. Остальное компромися с явными перекосами в ту или иную сторону.

                Нападки на него не новы. Пока выдерживает. А что до минусов — обычная история. Да, здесь в основном специалисты по «бизнес-логике приложений». Понятно, что нота ДО (С а буквенной записи) вызывает у них священный трепет, граничащий с непониманием. А количество ошибок с их колокольни говорит о проблемах языка. Их право. Но посмотрим что будет, когда их языки получат кодовую базу C. Я тоже человек и тоже могу быть не прав.
                  0

                  Знаете в чём проблема языка С? Что он близок к железу и если ты не знаешь как железо работает, то твой код ПОТЕНЦИАЛЬНО уязвимый. Многие современные языки пытаются быть дружелюным и прощать ошибки, но если в С/С++ ты накосячить с указателями тебе никто об этом не скажет ибо это всё работает и имеет какую-то логику.


                  Даже можно поразвлекаться.
                  Возьми вебмакаку которая никогда не трогала железо и посади её писать программы под DOS на ассемблере и ты узнаешь что никто не понимает как работает железо, будет кучу говнокода и копипаста ибо а как?
                  Тоже самое с FPGA, многие кто приходят кодить под это просто не могут понять что САПР просто выкинет его код на этапе компиляции и не скажет об этом если он не правильный.

                    +5
                    Знаете, мне кажется не стоит. Не стоит бросаться терминами типа «вебмакака». В любой сфере есть гуру. И есть остальные. Вот это «остальные» как раз и включает в себя всю палитру — от «воцерковленных новорегов» решивших что наконец им открылся «неугасимый и все прощающий свет истинны» который надо отстаивать огнем и мечем от «грязных лап неверных», до реальных профессионалов, которые понимаю ограничения того или иного решения. Потому культура прежде всего. По крайней мере со стороны тех, кто может это себе позволить… А неофиты… Так их много, но они всегда разные. Потому как или любой неофит сразу начинает планомерной восхождение до «гуру» или… бесконечно находят «новый свет истинны» разворачивая орудия против того, что вчера еще было непогрешимо. Такие тоже нужны. Без них скучно.

                    А код без багов пишут только программеры-ангелочки в небесном ВЦ. Под ласковым взором главного тимлида. Остальные смертные всегда пишут с багами. Увы, не до всех эта простая истинна доходит.
                      0

                      На счёт багов, тут есть проблема, если мои сокомандникимогут писать под 2К в то и под 5К строк кода в день, то я методично отлаживаю дай бог 800. Ахахахха

                +9

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

                  –2
                  Кухонный нож тоже очень опасен в неумелых руках, давайте все ножи заменим на пластиковые вилки. Если у человека руки ростут не из того места, то на каком бы языке он не программировал, все равно получится сами знаете что и язык Си тут не причем, это всего лишь остро заточенный кухонный нож!
                    +16
                    это всего лишь остро заточенный кухонный нож!

                    У которого обе грани заточены. И рукоятки нет. И оба конца острые. А чтобы им не пораниться при работе, надо либо обматывать его asan/ubsan-тряпочкой перед тем, как взяться, либо брать на работу типа разрезания лука на обычной кухне человека с опытом в 15 лет, который при этом лук будет резать не минуту, а день.


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

                      +2
                      Как автолюбитель не садится за руль Камаза (без обучения и практики вождения большегрузом), так и программисту-прикладнику незачем брать в руки «острый» инструмент под названием С/C++. Как утверждает Дядюшка Боб, недалёк тот день, когда программтистам начнут выдавать лицензии разрешающие или запрещающие использование тех или иных инструментов. Давайте не будем приближать это «счастливый» для нас момент, давайте выбирать инструмент по задаче и «по зубам».
                        +3
                        Как автолюбитель не садится за руль Камаза (без обучения и практики вождения большегрузом), так и программисту-прикладнику незачем брать в руки «острый» инструмент под названием С/C++.

                        Принципиальная разница между Камазом и C++ в том, что Камаз познаваем, а плюсы — нет.


                        И да, десять-пятнадцать лет назад, когда мне нужно было достичь близкой к максимальной производительности, выбор по факту был один ­— плюсы. Сейчас это уже не так, появились другие языки, да и компиляторы уже имевшихся тогда языков стали лучше. И это хорошо. Более того, сегодня, когда мне прям нужна совсем максимальная производительность, я возьму какой-нибудь хаскель и напишу на нём генератор LLVM IR или ассемблера. И это в ряде случаев будет более эффективно.


                        Так и с сями: сегодня нет никаких причин


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

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

                          –1
                          Я бы все же по себе не мерил, прошлая дискуссия яркий пример.
                            +3

                            Яркий пример, что никто не знает плюсы, да.

                            0

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


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


                            Суть лишь в том что сейчас уже никто не работает с железом напрямую, я даже не видел ни одного программиста что бы использовал "гото" хотя с ним компилируемый код в местах становиться на пару сотен тактов быстрее, что бывает крайне критично. А кто нить пользуется "? :"? Это в любом случае генерит инструкцию условного присвоения что впринципе не влияет на производительность. Или может кто-то из кодеров использует дерективы компилятора чтоб "флоаты быстрее считались"?
                            Я не видел никого. Обычно все просто описывали алгоритмы на С, и в этом плане он уже старый.

                              +4
                              Просто чтоб писать на С нужно знать железо, а когда пишешь на иных языках то просто описываешь алгоритм
                              чтобы писать на си нужно знать стандарт языка си. Программа, корректная с точки зрения стандарта и алгоритма, обязана корректно исполняться на любом железе, с поправкой конечно же на редкие баги компилятора и стдлибы. Си не просто так называют «кроссплатформенным ассемблером» — код на нем в первую очередь переносимый, а уже потом низкоуровневый. А если вы пишете не переносимый код, работающий только на конкретной железке, то вы просто закладываете себе больше проблем на будущее.
                                0

                                Хм, прикольное замечание, спс учту на будущие

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

                                Зачем? C от вас скрывает, скажем, ассоциативность кэша, наличие и параметры TLB, и так далее. Более того, С скрывает даже наличие векторных инструкций, и приходится либо использовать интринсики, либо ассемблерные вставки. При этом ни то, ни другое не является куском стандарта C и уж тем более не является кроссплатформенным. При этом в других языках есть кроссплатформенные почти-интринсики, да и при необходимости на ассемблере писать можно хоть в хаскеле.


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

                                И это аргумент в пользу C? Странный аргумент.


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

                                Эм, ну я использовал. Правда, не в C, а в генерируемом коде — прямые джампы на нужную метку.


                                А кто нить пользуется "? :"?

                                Регулярно.


                                Или может кто-то из кодеров использует дерективы компилятора чтоб "флоаты быстрее считались"?

                                Типа -ffast-math? Регулярно.

                                  0

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


                                  Я вообще писал на С только под одну платформу раньше и только недавно перешёл на компухтеры, ткчт без обид)


                                  А на счёт кэша и TLB это 5 с половиной инструкций(шучу) где единственное доступное с ринга пользователя ток кэш. И там почти нету настроек а обычно что-то Типо "флаш кэш" и всё. Интриксы и вставки как раз оно


                                  Ну и на счёт векторных инструкций всё неоднозначно, они вроде и нужны но и не нужны одновременно, тут трудно чего-то сказать
                                  Хотя учитывают тенденцию что разница между 5МБ чистых бинарников и 1МБ не столь важна, то думаю да, С тут сосёт неплохо


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

                                    +5
                                    Хочешь ручками оптимизировать, на те С, хочешь отдаться 4омпилятору и проч используй другие языки.

                                    Нет, C и плюсы не дают максимальной производительности. Хочешь ручками оптимизировать — пиши свой кодогенератор под конкретную задачу (и C тут далеко не лучший выбор).


                                    В сях, например, удачи с написанием обобщённой функции сортировки, которая бы не жрала лишние такты из-за void* и компаратора по указателю (в отличие от std::sort из плюсов, где всё может инлайниться).


                                    В плюсах же, например, мне для такой простой задачи, как «сделать обобщённое хранилище для POD'ов, которое бы использовало mmapнутую память и гарантировало сохранение их значений на диск» пришлось нетривиально приседать с placement new, memcpy и так далее, чтобы правильно начать лайфтайм объекта и не встретиться с UB. При этом приходится надеяться, что компилятор будет достаточно умным, чтобы это вырезать.


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


                                    А на счёт кэша и TLB это 5 с половиной инструкций(шучу) где единственное доступное с ринга пользователя ток кэш.

                                    Но знать про них для написания кода на С не надо.


                                    Ну и на счёт векторных инструкций всё неоднозначно, они вроде и нужны но и не нужны одновременно, тут трудно чего-то сказать

                                    Не понял.

                                      0
                                      Нет, C и плюсы не дают максимальной производительности.
                                      А никто не дает, только остальные еще хуже
                                        +2

                                        Ручное написание кода на асме/интринсиках или кодогенерация под задачу лучше.

                                        0

                                        Ну тип, не всё можно запихнуть в вектора, да и ещё сами векторные инструкции ни без выкрутасов. В районе шуточки что нужно MMX/SSE/AVX и у них разная нагрузка на конвейер, частоты работы и ширина команд. Вам какие вектора)?


                                        Ну вообще я понял почему на лурке написано — "С/С++ ужасный и (вроде) новый функционал строиться на костылях, но увы ничего лучше ещё не придумали"


                                        +о себе скажу что привык к verilog и не умею в "абстракции", мб потому пока ещё не наткнулся на проблемы в этом языке. Хотя работа с ссылками меня откровенно бесит… Ты просто указатель на память со сдвигом так почему я должен тасовать эти типы и писать кучу кода, капеец)))

                                          0
                                          Ну тип, не всё можно запихнуть в вектора, да и ещё сами векторные инструкции ни без выкрутасов. В районе шуточки что нужно MMX/SSE/AVX и у них разная нагрузка на конвейер, частоты работы и ширина команд. Вам какие вектора)?

                                          У обычного скалярного ALU и FPU тоже есть аналогичные проблемы. И ничего, арифметика из C от этого не пропала :]


                                          Ну вообще я понял почему на лурке написано — "С/С++ ужасный и (вроде) новый функционал строиться на костылях, но увы ничего лучше ещё не придумали"

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

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


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

                                      Вообще, никто и никогда не запрещает кодогенератору языка С использовать эти инструкции. Не делает он это отнюдь не потому что не может. Вспомните сколько вою было когда i386 убрали из поддерживаемых архитектур и сказали что теперь i686 минимум. Да и той уже нет. Потому 32-разрядные ARM'ы планомерно превращаются в тыкву следом за десктопными компьютерами. А прикладные программисты, радеющие за прямой доступ к векторным инструкциям и доступом к состоянию кеша… На фол последней надежды в футболе смахивает.

                                      Что ж до «goto» и оператора "?", то по сути это вопрос стиля. И в целом тут не важно какой стиль использовать, важно не смешивать их друг с другом. Как минимум без крайней на то нужды. В случае «goto» и "?" это возможность избавится от лишних ступенек в идейно линейном коде. В этом смысле они хороши. И вполне себе используются. Впрочем, опять же — до понимания плюсов этих операторов надо дожить.

                                      И конечно и безусловно — С (как и любой другой язык) невозможно выучить за 21 день. А предела совершенству нет. Потому чем дольше «точишь» мастерство, тем больше тонкостей применения тебе открывается. Другое дело, что желающих «точить мастерство» остается все меньше и меньше. В мире реальных вещей ценность «ручной работы» опущена ниже плинтуса. Это статусные и брендовые вещи. Пробраться в тот круг начав сегодня практически невозможно. В лучшем случае «сливки» снимут внуки. И то, если «дети» продолжат начато отцом. В программировании пока чуть лучше. Однажды созданная «цифровая» вещь дальше размножается методом почкования с минимальными затратами. Потому здесь еще эпизодически рождаются «штучные» вещи, которые выглядят реально классно на фоне «фабричных» аналогов.

                                      В этом смысле С ушёл. Условному Mediatek нужно буквально пяток сотрудников для того чтобы создать U-Boot под свой новый условный Helio. И еще пяток для того чтоб адаптировать ядро. Все. 10 специалистов по низкоуровневому программированию обеспечат работой тысячи (если не десятки тысяч) прикладников. Начиная с условного Google (Android, PlayMarket, etc...) заканчивая авторами приложений и инди игр (а еще обеспечит работой всяких Youtube- и TikTok- блогеров). Странный парадокс в том, что эти «тысячи и десятки тысяч» разработчиков упорно учат тот самый десяток тому, что С плох и недостоин носить гордое звание языка программирования и вообще скоро умрет. Ну как тут не вспомнить знаменитое «миллионы не могут ошибаться»
                                        +3
                                        Велика сила С(++) ровно в том, что он способен выдать это самое уникальное решение для уникальной задачи.

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


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

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


                                        Потому 32-разрядные ARM'ы планомерно превращаются в тыкву следом за десктопными компьютерами.

                                        Как это следует из ваших слов?


                                        Что ж до «goto» и оператора "?", то по сути это вопрос стиля.

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


                                        В случае «goto» и "?" это возможность избавится от лишних ступенек в идейно линейном коде.

                                        От лишних ступенек с ветвлениями избавляет оператор if, являющийся выражением. Но для C это, конечно, слишком сложно и революционно. Тернарный оператор не только плохо читается, но и ведёт к багам, потому что в C у него крайне неинтуитивный приоритет (в статьях той же PVS-Studio показывалось неоднократно, что это баги таки вызывало). Использование же goto в сишном коде — это либо хреновая замена break/continue, либо замена условных операторов для очистки выделенных ресурсов. В более продвинутых языках задача освобождения ресурсов возложена либо на деструкторы, либо на сборщик мусора и using/with/defer. И даже в C для этого есть GCC-изм attrubute((cleeanup)). Использование голого goto практически никогда не оправдано.


                                        И конечно и безусловно — С (как и любой другой язык) невозможно выучить за 21 день. А предела совершенству нет. Потому чем дольше «точишь» мастерство, тем больше тонкостей применения тебе открывается.

                                        Но в других языках как-то получается учить язык без изучения всё новых способов выстрелить себе в ногу.


                                        Другое дело, что желающих «точить мастерство» остается все меньше и меньше.

                                        Всё больше людей хотят просто программировать и при этом не держать в голове сотни условий, при которых происходит UB. Ну надо же!


                                        В мире реальных вещей ценность «ручной работы» опущена ниже плинтуса. Это статусные и брендовые вещи.

                                        Так ниже плинтуса или статусные?


                                        В этом смысле С ушёл. Условному Mediatek нужно буквально пяток сотрудников для того чтобы создать U-Boot под свой новый условный Helio. И еще пяток для того чтоб адаптировать ядро.

                                        Или условно два сотрудника с использованием условного Rust.


                                        10 специалистов по низкоуровневому программированию обеспечат работой тысячи (если не десятки тысяч) прикладников.

                                        Напомните, сколько людей пилит компиляторы, без которых тот же U-Boot нахрен никому не сдался? Кажется, больше 10 человек. Сильно больше.


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

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

                                          –3
                                          Но в других языках как-то получается учить язык без изучения всё новых способов выстрелить себе в ногу.


                                          А теперь (только предельно честно) — как давно вы учили новый язык? Изучение любого языка начинается с отстреливания себе в ног и рук. И хорошо как ими ограничивается. Ибо чаще всего ломается мозг. А вот починить его до конца практически никогда не возможно. Потому и есть «профессиональная деформация» в связи с используемым языком.

                                          Всё больше людей хотят просто программировать и при этом не держать в голове сотни условий...


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

                                          Или условно два сотрудника с использованием условного Rust.


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

                                          Напомните, сколько людей пилит компиляторы, без которых тот же U-Boot нахрен никому не сдался


                                          К проблеме курицы и яйца в компьютерах подход простой. Кто ближе к розетке того и тапки. U-Boot ближе.

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


                                          Так единственное о чем я прошу — не мешайте мне страдать. Это реально все.

                                          P.S.
                                          И да, C нихрена не простой.

                                          Как говорит мой отец — просто с моста прыгнуть. Головой вниз. Над остальным надо работать.
                                            +1
                                            А теперь (только предельно честно) — как давно вы учили новый язык?

                                            Ровно год назад прочитал Verified Functional Programming in Agda (до этого с агдой вообще не работал) и её отложил в сторону, и снова взял её всерьёз в районе сентября этого года. Почему-то ноги целы и на месте.


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

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


                                            Я вот не гений, attention span у меня маленький, поэтому я в уме могу только прикинуть общий план решения, и потом потихоньку его записывать. И тут чем больше мне помогает компилятор, тем более я производителен (поэтому, в частности, скорость написания кода мной на питоне асимптотически падает, и при объёме уже написанного кода в этак 70 строк неотличима от нуля).


                                            К проблеме курицы и яйца в компьютерах подход простой. Кто ближе к розетке того и тапки. U-Boot ближе.

                                            То есть, когда я под AVR'ки писал, я был ближе (или круче, или фундаментальнее), чем gcc, которым я собирал свой код? Прикольно.


                                            Так единственное о чем я прошу — не мешайте мне страдать. Это реально все.

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

                                              –2
                                              Почему-то ноги целы и на месте.


                                              А вы точно учили язык и продвинулись дальше «hello world»? Perl, TCL, VHDL, Verilog, Rust, да тот же Python мне изрядно попортили конечности. Правда все они были отложены ровно в тот момент, когда они добрались до мозга. Ибо ну его нафиг — меня кормит «хронический С головного мозга» и мне категорически нельзя допускать внеплановых «обRust'рений» других болезней.

                                              Это работает только для тех задач, которые помещаются в уме.


                                              Да ладно. А все методики типа сверху-вниз, ООП и прочее уже отменили?

                                              То есть, когда я под AVR'ки писал, я был ближе (или круче, или фундаментальнее), чем gcc, которым я собирал свой код? Прикольно.


                                              М… А вы компилятор потом непосредственно на AVR'ке запускали? Тогда да — круты и не слабы. Снимаю шляпу.

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


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

                                              Жду… Сильно жду, когда наконец хоть кто-то из страдальцев начнет исправлять ту самую ситуацию когда С в основании стека технологий. Вот, тот же CodeRush (да, магия хабра специально не применена) говорит — тошнит от С, но переписывать UEFI на Rust никто не хочет. Почему? Потому как экономически (пока?) не выгодно. А в качестве pet-проекта… Хороший специалист по работе загружен так, что в качестве pet-проекта у него самый настоящий pet. И никак иначе. Потому бурлим. И пена идет. Но подождем пока все это доварится. Тогда и будем пробовать получившееся блюдо на вкус.
                                                0
                                                Потому бурлим. И пена идет. Но подождем пока все это доварится. Тогда и будем пробовать получившееся блюдо на вкус.

                                                Когда вам станут очевидны преимущества Rust, поезд уже уйдёт.

                                                  –4
                                                  О, да! Мне именно это говорили про Pascal, FoxPro, Delphy, C++, Perl, PHP, Python… Имя им легион. Теперь вот и Rust занял почетное место в этом строю.

                                                  Никогда не поздно начинать. Но преждевременная оптимизация — корень всех бед.
                                                    0
                                                    У меня в черновиках статья по глюкам Раст.
                                                    +1
                                                    А вы точно учили язык и продвинулись дальше «hello world»?

                                                    Ну фиг знает, хелловорлд это или нет, сами судите.


                                                    Ибо ну его нафиг — меня кормит «хронический С головного мозга» и мне категорически нельзя допускать внеплановых «обRust'рений» других болезней.

                                                    Это забавно. Не уверен, что хочу сформулироватЬ, что именно, но забавно, да.


                                                    А все методики типа сверху-вниз, ООП и прочее уже отменили?

                                                    Но в этом случае я не решаю задачу в уме! В этом случае я её решаю итеративно: сначала делаю первый набросок, потом заполняю детали, потом ещё…


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


                                                    Но в голове это всё не помещается.


                                                    М… А вы компилятор потом непосредственно на AVR'ке запускали?

                                                    Нет, а это зачем?


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

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

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

                                                      Но в этом случае я не решаю задачу в уме! В этом случае я её решаю итеративно: сначала делаю первый набросок, потом заполняю детали, потом ещё…


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

                                                      И да, простите. Мне крайне сложно оценить наcколько «Hello, world!» код в вашем репозитарии. Потому просто верю.

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

                                                      Но я сужу по знакомым, которые страдают от дыр в openssl, в ядре линукса, и так далее.


                                                      Если человек страдает, но не предпринимает мер для устранения источника страдания, то он или мазохист или… страдания ничтожны в сравнении с получаемым удовольствием. Ту самую OpenSSL переписали на Rust. Вроде даже работает. Верю — народ страдал. А про ядро… Так мне уже сказали — очень толсто.

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

                                                      Я же не имею ничего против эволюции. Я против революции. Когда пусть и хорошее решение, но навязывается «огнем и мечом». Впрочем, помня возрастной срез аудитории хабра не удивительно что здесь как раз сторонники революционных мер. «До основания, а затем. Мы наш, мы новый мир постоим.» Только вот не дам я «до основания» раньше, чем другой мир появится. И, к счастью, не только я.
                                                        +2
                                                        За очевидный факт о том, что С уже много лет пытаются подвинуть другие языки

                                                        И в куче областей подвинули.


                                                        За очевидный факт о том, что на С написано безумно много кода

                                                        Ну просто этот факт не особо играет роль.


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

                                                        Нет, кобол живучее.


                                                        Впрочем, лично я по всем этим поводам вам минусы не ставил (но и плюсы тоже не ставил).


                                                        И что ж это такое, как не разработка методом сверху вниз?

                                                        Она самая. Только вы ведь написали, что человек сначала должен решить её в уме, а потом писать код. Не начинает решать, а решает. Целиком. «Решить» — совершенная форма.


                                                        Другое дело, что инструменты, которыми пользуетесь Вы реально помогают с математической точностью доказать стабильность решения. И как всегда — вопрос цены. Цены разработки инструмента, цены разработки и сопровождения.

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


                                                        А цена — ну, в моём случае вообще никто от этого не зависит. Цена — лёгкий стыд за ошибку в публикации, не больше.


                                                        Пока подобное произошло (?) в привычных вам финансовых сферах.

                                                        Не произошло, увы. Происходит, скорее, и далеко не везде.


                                                        Только до этого будущего еще большой путь.

                                                        Да, тут я полностью с вами согласен. Только этот путь не пройдётся сам, его надо активно проходить.

                                                          0
                                                          Да. Да. Не уверен. Не владею информацией о живой кодовой базе на Cobol'е. На всякий случай не спорю. И дело не в минусах или плюсах. Дело в отношении. Как же много людей которые мало того, что себе не верят. Страшно за то, что вместо собственного развития и понимания они готовы отдать все на откуп машине. Впрочем, жизнь меняется…

                                                          Не начинает решать, а решает. Целиком. «Решить» — совершенная форма.


                                                          И все же здесь я вынужден настаивать на своей формулировке. Именно решить. Именно совершенная форма. Весь верхний (а лучше несколько верхних) слоев если мы говорим о сверху-вниз.

                                                          Только этот путь не пройдётся сам, его надо активно проходить.


                                                          Так я ж не предлагаю стоять на месте или двигаться назад. Я с интересом наблюдаю за развитием того же Rast'а. Вопрос в том, что подавляющее большинство собеседников похожи на моего старшего сына. Тот тоже подходит с вопросом «папа, а давай сделаем...» подразумевая «папа сделай, а я в лучшем случае рядом постою». Во всяком случае когда дело касается системного программирования. А уж как хотите — возглавлять крестовый поход против С я точно не буду. Пока есть заказчики на код на С (создание, поддержка) я буду писать на нем. Ибо это тот инструмент, навык пользования которым я точил и продолжаю точить. Вот не будет — тогда буду думать. И то, скорее о гидропонной ферме и прудике с карпами в деревне, чем об освоении чего-то диаметрально отличающегося.
                                                            0
                                                            Не владею информацией о живой кодовой базе на Cobol'е.

                                                            В этих наших США как минимум некоторые финансовые системы на нём крутятся.


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

                                                            Почему всё? Только проверку того, что они правы.


                                                            А иначе в любом случае никак, если ваш проект больше сотни строк и если вы не сверхчеловек.


                                                            Именно решить. Именно совершенная форма. Весь верхний (а лучше несколько верхних) слоев если мы говорим о сверху-вниз.

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


                                                            Хотя лично у меня нередко бывает exploratory programming, когда я не до конца понимаю проблему, и открываю редактор и начинаю что-то в нём писать-играться, чтобы лучше эту самую проблему понять.

                                                              0
                                                              Почему всё? Только проверку того, что они правы.


                                                              Хорошо, а что остается от того все?

                                                              Хотя лично у меня нередко бывает exploratory programming, когда я не до конца понимаю проблему, и открываю редактор и начинаю что-то в нём писать-играться, чтобы лучше эту самую проблему понять.


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

                                                              Уверены что скульптора камнетеса хотите заменить на 3D-принтеры просто потому что у тех возможности «накосячить» меньше и повторяемость результата лучше? Мало того — молото с зубилом запретить, скульптуру объявить лженаукой и изгнать из учебных заведений? Есть же море альтернатив. Литье, ковка, лепка, рисование, те же 3D принтеры.
                                                                +3
                                                                Хорошо, а что остается от того все?

                                                                Построение решения задачи.


                                                                Уверены что скульптора камнетеса хотите заменить на 3D-принтеры просто потому что у тех возможности «накосячить» меньше и повторяемость результата лучше? Мало того — молото с зубилом запретить, скульптуру объявить лженаукой и изгнать из учебных заведений? Есть же море альтернатив. Литье, ковка, лепка, рисование, те же 3D принтеры.

                                                                Отличная аналогия! Никто вас за язык не тянул :]


                                                                Для искусства (или хобби-проектов) — кому что нравится, хоть 3D-принтеры, хоть скульптуры (хоть C, хоть раст, хоть whitespace). Для работы — 3D-принтеры или, скажем, вообще фотографии. У меня в паспорте вот не скульптура моей головы, а фото, хотя скульптура передаёт больше информации. И инженеры делают всякие вещи 3D-принтерами, а не скульпторов зовут. Знакомые для своих задач делают массово-габаритные макеты не при помощи услуг скульптора, а на 3D-принтерах. И в металле потом всё это делают на станках с ЧПУ и ещё с какими-то хитрыми вещами, а не зовут кузнеца, который бы им… И форму металла оптимизируют и проверяют в SolidWorks, считая там всякое на сеточках, а не на глазок или натурными испытаниями каждого варианта, как Настоящие Инженеры.

                                                                  0
                                                                  Построение решения задачи.


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

                                                                  Отличная аналогия! Никто вас за язык не тянул :]


                                                                  Превосходно. Только настоящий инженер сначала эскиз рисует. И до реально «железного» изделия обычно бывает множество прототипов. Потому как изделие (особенно тщательно обсчитанное, из выверенного материала, с проверкой на полости и пустоты) стоит денег. Да и в массы оно идет уже не литьем, а ковкой, гибкой, фрезерованием (что мало отличается от скульптуры) и имеет очень много расхождений с первым высчитанным экземпляром. И изделия все равно (как минимум выборочно) проходят натурные испытания.

                                                                  Да, конечно, механика не IT. Детали не размножаются простым копированием. Но если деталь можно сделать ковкой или вырезкой — будьте уверенны никто ее не будет печать на 3D принтере.

                                                                  Про «не скульпторов зовут». Есть такая профессия — макетчик. Это специалист по деланию МАКЕТА изделия из любимых подручных материалов. Кабели — веревки, корпуса — моченые газеты, мелкие детали — пластилин. Незаменимый человек на начальном этапе — проектирования. Когда эмоции бурлят, у каждого свое видение готового изделия. И надо сравнить разные варианты и выбрать самый удобный. И уж только с него инженер начинает что-то считать. А еще с него можно начать готовить кофры, чехлы, встраивать куда-то. Если все это делать 3D принтером то никуда не успеешь и денег не напасешься. Даже автомобили делают из макетной глины. Да и массовое производство… Впрочем, я про него уже писал.

                                                                  Так что не надо мне рассказывать про идеальный мир, сделанный инженерами в SolidWorks. Как и про идеальный мир, где все вообще написано на абсолютно безопасных языках. Я, знаете ли, не хочу чтоб меня «умная дверь» из дома не выпускала на том лишь основании, что без ее надзора я прямо в коридоре споткнусь и коленку расшибу.
                                                                    +1
                                                                    Остался один момент — а есть уверенность, что ответственную задачу можно поручать троечнику, который с трудом понимает граничные для нее условия?

                                                                    Не понял, откуда тут троечники вылезли, ну да ладно.


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


                                                                    Но если деталь можно сделать ковкой или вырезкой — будьте уверенны никто ее не будет печать на 3D принтере.

                                                                    Почему? Потому что ковка проще и дешевле? Тогда к чему вы вспомнили про 3D-принтеры?


                                                                    Про «не скульпторов зовут». Есть такая профессия — макетчик.

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


                                                                    Так что не надо мне рассказывать про идеальный мир, сделанный инженерами в SolidWorks.

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


                                                                    И, кстати, уже минимум несколько лет как проектирование формы колёс вполне успешно поручается ИИ генетическим алгоритмам, например, которые могут минимизировать количество использованного металла (или, эквивалентно, вес) при сохранении характеристик. Это как раз то, что мой хороший знакомый делает в SW, только автоматизированно — если мой знакомый вертит модель колеса в SW и думает «а попробуем тут немножко сделать тоньше… так, запустим расчёт и отойдём на пару часов… о, теперь вот тут нагрузки толком нет, тут тоже можно немного срезать…», то там это делает машина сама.

                                                                      –1
                                                                      Тогда к чему вы вспомнили про 3D-принтеры?


                                                                      Так все же просто. Всегда есть два подхода. Взять заготовку и отсечь все лишнее и взять ничего и «слепить» нечто. До сих пор в основном главенствовал (и главенствует) первый. Но хайп вокруг вторых приводит к тому, что они начинаю применяться где только можно. Местами сильно мешаясь и наоборот замедляя работу. Макет из папье-маше опытный макетчик сделает быстрее и точнее чем 3D распечатает 3D принтер. Часть задач на С надежно решить получится быстрее и не менее качественно, чем описывать ради этого все особенности преобразования типов в них на том жe Rust'е. Я бунтую против Вашего «требую чтоб везде». Я не бунтую против инструментов.

                                                                      А можно я всё же буду?


                                                                      Можно. Только получите в ответ провокационный вопрос. А на чем написан SolidWorks? Как вам может нравиться код, написанный на «рассово не чистых» языках?

                                                                      И потом. В расчетных библиотеках того же Solid'а встречаются ошибки. И ни одна сертификационная лаборатория не поставит штампик только на основании того, что мы «посчитали в Solid'е». А если конечное решение все равно за сертифицирующим центром, то зачем навязывать всем именно Solid. Есть альтернативы. AutoCAD, тот же Компас, кульман в конце-концов. Почему вы считаете себя в праве ограничивать разработчика в выборе инструмента? Более того — вот уже вторую неделю упорно доказывать правоту такого подхода? Ведь весь сыр бор исключительно по этой причине. Или личная неприязнь и предвзятое мнение непосредственно к языку С.
                                                                        0
                                                                        Макет из папье-маше опытный макетчик сделает быстрее и точнее чем 3D распечатает 3D принтер.

                                                                        Это неважно. Для приложений важно лишь то, насколько дешевле и быстрее сделать макет. Если этот опытный макетчик стоит как стопицот 3D-принтеров, то его услуги будут не очень востребованы.


                                                                        Часть задач на С надежно решить получится быстрее и не менее качественно, чем описывать ради этого все особенности преобразования типов в них на том жe Rust'е.

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


                                                                        Можно. Только получите в ответ провокационный вопрос. А на чем написан SolidWorks? Как вам может нравиться код, написанный на «рассово не чистых» языках?

                                                                        Во-первых, это вопрос следующего порядка малости. Мы же не обсуждаем, на чём написаны coq, agda или idris?


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


                                                                        А если конечное решение все равно за сертифицирующим центром, то зачем навязывать всем именно Solid. Есть альтернативы. AutoCAD, тот же Компас, кульман в конце-концов.

                                                                        Хочет с кульманом — пусть делает с кульманом. Но что-то мне подсказывает, что результат будет хуже и дольше, чем в случае CAD'ов.

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


                                                                          Можно подумать во всем этом обсуждении есть хоть один не сомнительный тезис. Да и в целом обсуждение конструктивностью не блещет. И это было просто очевидно с самого начала.

                                                                          Мы же не обсуждаем, на чём написаны coq, agda или idris?


                                                                          Значит ядро и драйвера осуждаем, а остальное нет. Впрочем, да — конструктивности тут ждать не приходится.

                                                                          Если этот опытный макетчик стоит как стопицот 3D-принтеров, то его услуги будут не очень востребованы.


                                                                          Это полит-экономический вопрос. Инженеры их (обычно) сторонятся. Впрочем, имею честь наблюдать результат Solid + 3D принтер сейчас vs приходящий макетчик + дизайнер за кульманом некоторое время назад. Я не конструктор. Но меня всегда зовут на обсуждения конструктивов изделия (причины вынесем за скобки, сказав для простоты что доверяют моему инженерному чутью). Так вот — корпус на принтере получается реально красивым только чистовой. Очень долго и очень дорого. Оперативные корпуса… Нет, «бумажные» однозначно были лучше. И уж точно по совокупности не дороже. А те наработки используются до сих пор, незначительно дотачиваясь под современные. Не родило поколение фанатов 3D принтеров ничего принципиально нового. Впрочем… Возможно их полет фантазии просто сдерживали… И как раз последствия пандемии наконец смогут помочь им показать себя во всей красе… Не ругаю я коллег. А уж тех, с которыми работаю и подавно.

                                                                          Впрочем, есть свои плюсы у печатных. На них проще оценить финальную конструкцию. Реальные платы, разъемы, дисплей, шлейфы… Тут не так важна кривость корпуса, как четкое понимание — состыкуются компоненты или нет. Будет шлейф перекручен или нет. Есть необходимые зазоры или упираемся. Но все равно — будь решение за мной я бы начинал с «бумаги».

                                                                          Но блин — каждому инструменту свое применение. Это единственный конструктив из всей этой темы. Есть спрос на С — будет С. Нет спроса на С — будет что-то другое. Мне хватает заказчиков, которые не так сильно обеспокоены RCE и прочими неприятностями. Хотя… Не скажу что подход когда безопасность решения базируется лишь на том, что «противник не знает систему» мне нравится. И я всячески пытаюсь убедить таких заказчиков в том, что так нельзя. Но и фанатично вкачивать ресурсы в безопасность ради безопасности и неудобства пользования изделием… Так себе удовольствие.
                                                                      +3
                                                                      Остался один момент — а есть уверенность, что ответственную задачу можно поручать троечнику, который с трудом понимает граничные для нее условия? Или что не еще хуже понимает, но не знает как обойтись без «умной машины», которая за него все посчитает?
                                                                      Так а вы что бы выбрали, поручить такую задачу:
                                                                      — троечнику + стреляющий по ногам ЯП;
                                                                      — троечнику + безопасный ЯП?
                                                                        –1
                                                                        — Ты сразу спать пойдешь или сначала зубы почистишь?
                                                                        Детский сад право слово.

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

                                                                        Впрочем, успокойтесь вы уже. Я же сказал — OpenSSL на здоровье. Пусть хоть двоечники переписывают. Нет тут особых требований по скорости — безопасность перевешивает. И себе выбирайте язык, который вам комфортнее. И забирайте от меня часть работы.

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

                                                                Скажите, а вы спеллчекером пользуетесь?

                                                                  0
                                                                  В комментариях обычно нет. А это что-то меняет? Мысль осталась непонятой?
                                                                    +1

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

                                                                      0
                                                                      Где я чего предлагаю? Еще раз — я не против прогресса. Если кто-то готов заменить старичка С — милости просим.

                                                                      Но в целом идея именно такая. Spell check — это компилятор, а уж meaning checks — это строго за человеком. Во всяком случае в тех местах, где производительность не перевешивается безопасностью (хоть safety, хоть security).
                                                                        0
                                                                        Если человек не способен писать грамотно без спеллчекера, то это… ну скажем так, навевает смутные подозрения. В случае с программистом — ещё и грозит смутными последствиями.
                                                      –3
                                                      Популярность C для низкоуровневого программирования — следствие более исторической случайности, нежели каких-то преимуществ C.
                                                      Wtf?
                                                      А что, есть реальный выбор для эмбеддед, ну хотя бы сейчас?

                                                      Ну и исторический взгляд тоже не помешает. На момент создания С +- 5лет

                                                      P.S Или может в области ядер операционных систем случился какой то прорыв, а я пропустил?
                                                        +1
                                                        есть реальный выбор для эмбеддед, ну хотя бы сейчас
                                                        Плюсы, Ада, Forth, подмножество Rust. Форт поменьше и пошустрее, Раст побольше и помедленнее, Ада с плюсами на уровне С.
                                                        Ну и исторический взгляд тоже не помешает
                                                        Если смотреть просто по списку, то выбор был: Forth, Simula, PL. А какая на самом деле была известность, доступность документации и эффективность работы компилятора — это у олдфагов надо спрашивать, кто застал.
                                                          0
                                                          А на практике?
                                                            0

                                                            А на практике плюсы 12 лет назад вполне себе работали. И я знаком с людьми, которые на самом деле использовали Ivory, например.

                                                              0
                                                              Ну я не спорю, что это все работает. Но реальная кодовая база сравнительно мала, и вендоры часто поставляют свои SDK на каком-нибудь С99. И даже если используются плюсы, то это чаще что-то старое и C style. Бегло глянул NRF — gnu++98 / C99.
                                                              0
                                                              In the wild я всё это, кроме Раста, банально видел: чистый С, конечно, чаще, Форт наравне с чистым ассемблером, аду пару раз в стрёмном оборудовании за многоденег.
                                                                –2
                                                                Очень конечно смешно, советовать по форумам… Особенно то, что не видел даже по причине позднерождения, вроде Симулы. Ну или форта, которому нужна фортмашина для конкретного железа.

                                                                Занесу тебя в игнор.
                                                                  +1
                                                                  Не понимаю, почему стоит обижаться на обоснованный ответ на вопрос. Форту, конечно, нужна форт-машина, но и в компилятор надо целевую архитектуру ручками добавлять.
                                                          –6
                                                          Если вы всерьез считаете, что есть какой-то ЯП лучше С, я вам сочувствую!
                                                          А если вы считаете этим ЯПом педеrust, то я вообще в шоке!
                                                          +1
                                                          Слушайте, хап хайпом… Но вот.

                                                          Как уже рядом писали — это не часть языка. Это этакая внешняя библиотека (и не очень совместимая между gcc и clang, по моему опыту).


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

                                                          Как уже рядом писали — нет, это не уникальное решение. Асмовставки можно сделать много где, от раста до хаскеля.


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

                                                          Почему? Прикладным программистам это не нужно?


                                                          У вас как-то очень много отсылок к прикладным программистам с коннотациями, которые я не до конца улавливаю, но иногда возникает такое чувство, что они в вашем мире пишут только опердни и клиенты к СУБД на дельфях.


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

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

                                                            0
                                                            У вас как-то очень много отсылок к прикладным программистам с коннотациями, которые я не до конца улавливаю


                                                            Конечно. Потому как прикладное программирование много шире системного. Потому нет к нему единого отношения. Однако, в подавляющем большинстве случаев для прикладного ПО характерен ответ в стиле «Подумаешь тормозит! Завтра будет новое поколение процессоров и еще больше памяти и будет летать.» Именно этот ответ я получил в ответ на недоумение от факта запуска на Marvell PXA320 с носителем в виде SD карточки под Linux postgreeSQL. Особый шик в том, что это самое «железо» для них делал я (тогда еще сам). И вполне себе отдавал отчет в том, что ни завтра, ни послезавтра я им не выкачу систему, которая на подобное способна. В любом случае системщики себе такое поведение позволить не могут вообще никогда. Собственно, если хорошо подумать, то именно возможность именно такого отношения к задаче делит мир на прикладников (тех, кто может) и системщиков (кто не может).

                                                            Точить мастерство листания и интерпретации стандарта, чтобы понимать, UB передо мной или не UB, можно ли код коммитить...


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

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


                                                            Слушайте, а мы точно про С сейчас говорим? В самом деле. Даже код 20-летней давности (за который немного стыдно) совершенно без проблем компилируется современными компиляторами и выдает рабочий бинарь. По сути это просто возвращает нас к тому самому моменту про оптимизатор. Не надо оставлять свободы оптимизатору и код останется рабочим навсегда. А умение так писать… Ну да, оно точится. И без фокусировки на инструменте (вместо расширения по фронтам и осваивания всего и вся) эта задача нерешаема.

                                                            Отчасти по этой причине я посмотрел на Rust и… отложил его в сторонку. На моей памяти С «воевал» с ассемблером не один десяток лет (попутно отбиваясь от Pascal'я и Basic'а). Вполне достаточно для жизни поколения разработчиков. Пусть молодые разработчики осваивает Rust. Возможно, действительно через некоторое время появится шикарная возможность сменить пяток наСильников на пару Rust'оманов.

                                                            К слову о реально важном. Ау, фанаты Rust! Фиг с ним с ядром — сделайте аналог U-Boot'а для Cortex-A. У этой задачи нет жестких требований по размеру, она не висит в памяти резидентно и весьма востребована. Ибо barabox тоже не сказать что совсем уж торт. У вас сегодня для этого все есть.
                                                              +3
                                                              Однако, в подавляющем большинстве случаев для прикладного ПО характерен ответ в стиле «Подумаешь тормозит! Завтра будет новое поколение процессоров и еще больше памяти и будет летать.»

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


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

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


                                                              Даже код 20-летней давности (за который немного стыдно) совершенно без проблем компилируется современными компиляторами и выдает рабочий бинарь.

                                                              С -O0, небось? Новые компиляторы приносят новые оптимизации, основываясь на новых способах интерпретировать UB.


                                                              По сути это просто возвращает нас к тому самому моменту про оптимизатор. Не надо оставлять свободы оптимизатору и код останется рабочим навсегда. А умение так писать… Ну да, оно точится.

                                                              Давайте я сначала сформулирую такой тезис, с которым, надеюсь, споров не будет:


                                                              Оптимизатор превращает рабочие программы в рабочие программы с неотличимым (с точностью до производительности) поведением. Любое другое поведение оптимизатора — баг, который надо репортить разработчикам компилятора.


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

                                                                0
                                                                С -O0, небось? Новые компиляторы приносят новые оптимизации, основываясь на новых способах интерпретировать UB.


                                                                -O size для контроллеров. Для ПК у меня значимых абсолютно своих проектов нет, но насколько мне известно тот же Linux и U-Boot собирается отнюдь не -O 0.

                                                                Впрочем, для сборки ядра 2.6.35 нужен gcc не выше (не помню) и bunutils не выше (тоже не помню). Так что я не возьмусь утверждать, что в Ваших словах правды нет совсем. Но это тема уже другого разговора. Где тема недостатков языка С уже не будет иметь такой существенной роли.

                                                                Давайте я сначала сформулирую такой тезис, с которым, надеюсь, споров не будет...


                                                                Да ешкин же кот. Конечно. Безусловно. Абсолютно верно. И я разве где-нить выступал против?

                                                                «Вагонные споры последнее дело, когда больше нечего пить» (с) Макаревич

                                                                Причина ж не в этом. И спорим мы с вами не об этом. Ведь весь наш спор идет по сути вокруг одной простой идеи. Вы ратуете за то, что компилятор не должен позволять «говнокодить». Я ратую за то, что разработчик не должен позволять себе «говнокодить». Вы говорите раз компилятор позволяет разработчик обязательно наговнокодит. Я говорю что фантазия разработчика сильно шире и всегда найдутся индивидумы которые обойдут любые ограничения компилятора и все равно наговнокодят. Вы соглашаетесь и ратуете за усиление контроля со стороны компилятора. Я соглашаюсь и ратую за усиление воспитания программиста. И… Опять все сначала.

                                                                "… и каждый пошел своею дорогой, а поезд пошел своей." (с) Он же и там же.
                                                                  +2
                                                                  Вы ратуете за то, что компилятор не должен позволять «говнокодить». Я ратую за то, что разработчик не должен позволять себе «говнокодить»
                                                                  Так в статье про то, каким должен быть хороший ЯП нельзя надеяться, что косяки языка будут компенсированы преподавателями computer science.
                                                                    0
                                                                    Несогласных со статьей расстреливают сразу? Демократию отменили? Огласите список непогрешимых авторов и генеральных идей.

                                                                    Я уже писал. Личное дело каждого в какого бога верить.
                                                                      +1
                                                                      Несогласных со статьей расстреливают сразу?
                                                                      чтобы их не расстреливали они сначала должны предоставить веские причины своей точки зрения, ибо довод «просто пишите код качественнее» не всегда прокатывает в нашем жестоком мире.
                                                                        –1
                                                                        Я бы послушал веское доказательство той точки зрения, которая опровергает АКСИОМУ «просто пишите код качественнее». Есть желающие совершить такое?
                                                                          0
                                                                          Так аксиома «просто пишите код качественнее» не противоречит другой аксиоме «ЯП должен брать на себя максимум бездумной/механической работы человека и оставлять последнему только выполнение бизнес-задач и воплощение требуемой логики».

                                                                          Первой аксиоме учат в учебных заведениях (ну и жизнь тоже учит).
                                                                          А второй должны следовать разработчики очередного ЯП.
                                                                            0
                                                                            Отлично. Но при чем здесь С? Меняйте его современными языками в рамках решения своих «бизнес-задач» и «воплощения требуемой логики» (что бы это не значило). А то [синоним слова говорить] каждый может. А как замените расскажете как было плохо и как стало хорошо (или наоборот). А то смахивает на дележку шкуры неубитого медведя.
                                                                              0
                                                                              То есть вы всегда сначала делаете, а потом думаете, почему так получилось? Или вы все же сначала обдумываете преимущества и недостатки разных подходов, обсуждаете их с другими и только потом приходите к выводу «как делать»?
                                                                                0
                                                                                То есть вы всегда сначала делаете, а потом думаете, почему так получилось?


                                                                                Так кто из нас кричит, что С несовременная, дурно пахнущая субстанция требующая срочной замены повсеместно? Разве я?

                                                                                Я 30 лет назад принял решение и стал электронщиком (схемотехником). С серьезным уклоном в цифровую технику. 20 лет назад понял, что схемотехник вот-вот переплюнет ювелира, а я никак не могу своими руками менять BGA чипы обычным паяльником (да и компоненты типоразмера 0201 мне уже не по силам). Потому переквалифицировался в программиста. Системного. Сначала Assembler, затем C. И до сих пор именно этими знаниями решаю те самые «бизнес-задачи» и «воплощаю требуемую логику» (что бы это не значило). Там где можно. А там где нельзя упорно отговариваю заказчика и уступаю место тем, кто по моему мнению с данной задачей справится лучше. Потому и говорю: «Считаете что можете заменить С в конкретном месте — меняйте. Нет — не [синоним слову говорите] и не мешайте работать.» С OpenSSL же получилось (получается?).

                                                                                Да, я сначала думаю, потом делаю, потом снова думаю и снова делаю. И эта цепочка прерывается ровно в тот момент, когда заказчик говорит — достаточно. Результат меня устраивает.

                                                                                Переформулируйте вопрос.
                                                                                  0
                                                                                  Переформулируйте вопрос
                                                                                  Я думаю, что вы прекрасно сами все поняли. Вот только я одного не пойму, в чем вы упрекаете людей, которые хотят разобраться в преимуществах и недостатках конкретной технологии? А также в возможных альтернативных вариантах (которых может еще и нет).
                                                                                    0
                                                                                    В предвзятом отношении (ну и слюной брызгать поменьше).
                                                                                      0
                                                                                      А можно ссылку на чей-то предвзятый комментарий (а не просто с оценочным суждением)?
                                                                                    0
                                                                                    С OpenSSL же получилось (получается?).
                                                                                    отличный пример библиотеки, печально известной за обилие багов, использование которой вызывает PTSD у бывалых кодеров. Говорят кстати алгоритмы шифрования переписали на безопасном расте.
                                                                                      0
                                                                                      OpenSSL, LibreSSL, rust-openssl. Пришло время. И слава богу. Мне остается только пожелать успехов.
                                                                                      Впрочем, я тут опять слегка накосячил. Думал все же о «хвойных». О Sequoia-PGP.
                                                                                      Но в любом случае — и там и там безоговорочно поле Rust'а. И славненько. Пусть так и будет.
                                                                                        –1
                                                                                        это слабо помогло=)
                                                                                        моя робкая попытка хотя бы скомпилироватьть раст версию зафейлилась (исходники тут)
                                                                          0
                                                                          Если перестараться с «хорошестью» языка, то задачи разделятся на решаемые однозначно и в пару строк средствами языка и на те, для решения которых нужно дёргать библиотеку, написанную на другом языке. Этакий APL 2.0.
                                                                          +3
                                                                          Впрочем, для сборки ядра 2.6.35 нужен gcc не выше (не помню) и bunutils не выше (тоже не помню).

                                                                          Далеко берёте. Я тут несколько месяцев назад 4.12.12 собрал gcc 9.3 и получил небутабельное ядро (хотя оно же с тем же конфигом с 7.чётотам работало отлично годами, а обновить мне на моей машине пришлось потому, что что-то там про релокейшны).


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

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

                                                                            0
                                                                            Далеко берёте...


                                                                            Да просто вспомнилось. Впрочем, радетелям «правильных» языков могу порекомендовать собрать на Ubuntu 20.04 LTS хотя бы AOSP 9.0. И поплеваться с питона. Для меня это вполне свежий пример, показывающий что на определенном этапе развития языка подобные проблемы неизбежны.

                                                                            для говнокодинга достаточно ограниченной внимательности.


                                                                            О да. Этого всегда достаточно. Было. Есть. И будет. При чем чем больше доверия автоматике, тем больше. Именно по этой причине натурные тесты в критических и закритических условиях всегда крайне желательны (а в некоторых областях обязательны).
                                                                              +2
                                                                              При чем чем больше доверия автоматике, тем больше.

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

                                                                                0
                                                                                Хм… А можно примеры из смежных отраслей?

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

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

                                                                                Но… Запрещать на этом основании речные лодки (неустойчивые, требуют собранности и синхронизации рук), гироскутеры (скорость и внимание), велосипеды и моноколеса (ужас — мало того что руками рулятся, так еще и неустойчивые — кошмар то какой), всю малую авиацию (ужас — требуют собранности во все время полета). По моему вы просто хватили лишнего. Но категорически не хотите этого признавать.
                                                                                  +1
                                                                                  Но… Запрещать на этом основании речные лодки (неустойчивые, требуют собранности и синхронизации рук), гироскутеры (скорость и внимание), велосипеды и моноколеса (ужас — мало того что руками рулятся, так еще и неустойчивые — кошмар то какой), всю малую авиацию (ужас — требуют собранности во все время полета). По моему вы просто хватили лишнего.

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

                                                                                    +3
                                                                                    Но машинист все равно остается на месте.

                                                                                    Не везде. Я слышал, в некоторых странах вполне себе есть беспилотные поезда и метро.


                                                                                    Ну и ещё, по опыту разбора пары случаев, где остаются люди, там обычно ещё профсоюзы суетятся, чтобы людей на мороз не выставляли, но это дело десятое.


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


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


                                                                                    Запрещать на этом основании речные лодки (неустойчивые, требуют собранности и синхронизации рук), гироскутеры (скорость и внимание), велосипеды и моноколеса (ужас — мало того что руками рулятся, так еще и неустойчивые — кошмар то какой)

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


                                                                                    всю малую авиацию (ужас — требуют собранности во все время полета)

                                                                                    Вы, кстати, ведь в курсе, что ваши права по полётам сильно ограничены, если у вас нет ADS-B?

                                                                                      0
                                                                                      И тренд на то, чтобы добавлять больше страхующих систем, а не удерживать внимание.


                                                                                      ASLR — да. Неисполнимый стек — да. Тотальный контроль — категорически нет.

                                                                                      Люди, которые ими пользуются, скорее себя угробят, чем других


                                                                                      Владельцы транспортных контор, в парке которых КАМАЗы (или в Вашем случае Freightliner) одобряют. Автобусы и такси тоже не представляют абсолютно никакой опасности для окружающих. А уж свободное хранение (а паче ношение) оружия — вообще абсолютно безопасное затея для окружающих.

                                                                                      Вам жить не страшно? Столько опасностей вокруг. Может в сравнении с ними очередное переполнение буфера в ядре просто безделица?

                                                                                      Вы, кстати, ведь в курсе, что ваши права по полётам сильно ограничены, если у вас нет ADS-B?


                                                                                      Я не знаток авиационных систем. Но в любом случае — это информационная система. Она не перехватывает управление полетом и не устраняет главную причину авиакатастороф. Да, я о человеке.
                                                                                        +2
                                                                                        ASLR — да. Неисполнимый стек — да.

                                                                                        А чего так? Люблю быть, знаете, хакером и исполнять всякое со своего стека.


                                                                                        Автобусы и такси тоже не представляют абсолютно никакой опасности для окружающих.

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


                                                                                        А уж свободное хранение (а паче ношение) оружия — вообще абсолютно безопасное затея для окружающих.

                                                                                        На получение license to carry надо сдать экзамен.


                                                                                        Я не знаток авиационных систем. Но в любом случае — это информационная система. Она не перехватывает управление полетом и не устраняет главную причину авиакатастороф.

                                                                                        Перехватывающие управление системы тоже есть. Разводят самолёты, идущие пересекающимся курсом, например (и они вроде как теперь имеют приоритет над человеком после эпизода с испанским диспетчером в нулевых, хотя тут могу ошибаться). У современных боевых самолётов есть automatic ground collision avoidance system (не знаю, есть ли у гражданских) — вот показательное видео на полторы минуты, где лётчик вырубился после манёвра с высокой перегрузкой, а самолёт его спас. Или вот моя машина, хоть и не самолёт, но будет тормозить сама в некоторых условиях.

                                                                                          0
                                                                                          Поэтому есть такая тема… На получение license to carry надо сдать экзамен.


                                                                                          Хм… А ответственный код значит можно писать не имея на это право?

                                                                                          Люблю быть, знаете, хакером и исполнять всякое со своего стека.


                                                                                          Как вы говорите — да на здоровье. Как хобби или исскусство. И лучше спрятать в запасники музея для специалистов, чтоб не дай бог дети не увидели.
                                                                                            +2
                                                                                            Хм… А ответственный код значит можно писать не имея на это право?

                                                                                            Юридически — да, можно. По крайней мере, экзаменов на тему я не припомню, и это всё на усмотрение работодателя.


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

                                                                                            Вы ведь поняли, что это было аллюзией на ваш аргумент о том, что я знаю, что делаю, поэтому дайте мне сделать это? Ведь ASLR, неисполняемый стек, shadow stack возвратов и так далее, это всё не нужно, если просто писать код аккуратно, без багов и дырок.

                                                                                              –2
                                                                                              всё не нужно, если просто писать код аккуратно, без багов и дырок.


                                                                                              … или (что важнее) использовать код непосредственно для решения задачи. Возможность кода решать поставленную задачу — забота отдела качества и сертификационной лаборатории. Если это выполняется, то какие претензии к инструментам?

                                                                                              Другое дело, что в последнее время стало мало выполнять непосредственно задачу, поставленную перед кодом. Все эти хакеры, и прочие local privileges escalation и remote code execution… И вот это действительно проблема. И у меня нет хорошего пути решения для этой проблемы. Но мне кажется (больше того — я уверен) что решаться она должна не сменой инструмента, а повышением образованности разработчиков. Скорее всего это должно привести к тому, что сильно больше будет специализация разработчика, а популярные нынче варианты «сегодня AVR, завтра front-end, послезавтра Java» потихоньку должны умереть. Ибо именно это не что иное как анархия. В которой некоторое количество сообщений назад обвиняли меня и язык С.
                                                                        –2
                                                                        Ну да. Александреску доточился и свалил в D. Мейерс доточился и свалил из индустрии вообще. Я, конечно, не Мейерс и уж тем более не Александреску, но я тоже доточился. Точить мастерство листания и интерпретации стандарта, чтобы понимать, UB передо мной или не UB, можно ли код коммитить, или я закладываю бомбу, которая может взорваться через пару апгрейдов компилятора, как-то стало всё меньше желания.
                                                                        Надо не путать между «доточился» и «сточился» [в попытках понять].

                                                                        Насчет UB я вообще не понимаю. Практики делают как им надо, остальные ноют про УБ.
                                                                        Здесь я вижу прямую аналогию с ПДД, когда новички ноют про сложность и непонимание, а остальные просто ездят с минимум проблем.
                                                                          +1
                                                                          Практики делают как им надо

                                                                          До первой отладки на пару недель из-за того, что компилятор делает наркоманию на некорректном коде, или починки упавшего прода в пятницу вечером из-за UB, или ещё чего подобного.

                                                                            –2
                                                                            UB это ошибка программера.

                                                                            Нечего на зеркало пенять.
                                                                              +5

                                                                              Я про это и говорю, да. Ошибка программиста. Какой плохой, негодный программист, не обладающий стопроцентной внимательностью!

                                                                                –2
                                                                                А о чем мы говорим?

                                                                                Если про твой последний пример — то там явно перемудрствование на ровном месте.

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

                                                                    Суть лишь в том что сейчас уже никто не работает с железом напрямую

                                                                    Не хочу Вас расстраивать, но таки работают. И на С, и на ассемблере. Даже если есть ОС.

                                                                    0
                                                                    При чем тут плюсы? Статья про Си вообще-то, это совсем другой язык. Плюсы действительно переусложнены и с каждым новым стандартом туда впиливают все больше и больше возможностей выстрелить в ногу. А Си — очень простой и компактный язык. И изучить его можно если не за 21 день — то за пару месяцев точно.
                                                                      +1
                                                                      А Си — очень простой и компактный язык. И изучить его можно если не за 21 день — то за пару месяцев точно.

                                                                      <sarcasm>Главное за эту пару месяцев выучить -fno-strict-alising и -O0 </sarcasm>,


                                                                      а то пару месяцев могут превратиться в несколько лет.

                                                                        +2

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


                                                                        И нет, C нельзя выучить ни за 21 день, ни за пару месяцев — тут я полностью согласен с соседним оратором.

                                                                          0

                                                                          а я не согласен.
                                                                          да, владение C можно улучшать бесконечно.


                                                                          но «выучить» (понять как оно устроено) мне в подростковом возрасте хватило несколько дней чтения k&r. без практики (ибо не на чем было). потому что если знаешь ассемблер, то читаешь k&r и понимаешь почему было так сделано, а логичные вещи и изучаются легко.


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

                                                                            0
                                                                            но «выучить» (понять как оно устроено)

                                                                            Спор о терминах чую я. ИМХО «выучить» — научиться эффективно пользоваться (для некоторого определения эффективности).


                                                                            А то теорию типов тоже можно «выучить» за день (чего там, всего шесть или семь правил для calculus of constructions, она помещается на листе бумаги), но научиться этим эффективно пользоваться занимает несколько больше времени.


                                                                            мне в подростковом возрасте хватило несколько дней чтения k&r

                                                                            В подростковом возрасте я и C++ «выучил» за года этак полтора, от книжки Стивена Праты до Мейерса, Саттера и Александреску, и z даже писал не особо валящийся софт, не подумайте! А ещё через десяток лет понял, что нихрена не знаю. И что никто нихрена не знает.

                                                                  +5
                                                                  … У которого обе грани заточены. И рукоятки нет. И оба конца острые...


                                                                  Простите. Не смог удержаться.
                                                                  image

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

                                                                  На самом деле вопрос-то очень интересный. Я корнями в деревне. По детству, в самых дальних закоулках чердоков находил иконно русскую косу-горбушу. И даже доставал, точил и косить пробовал. Но старички смотрели, хмыкали и говорили — не майся ерундой. Вот тебе нормальная коса (коса литовка). И да, вот ее я освоил. В совершенстве. Площадь, обкосить вокруг кустов, неровная поверхность — все равно. Все будет обкошено. Да так, что травы останется ровно 1,5 сантиметра. Сегодня молодежи уже я хмыкаю и говорю не майтесь ерундой — есть же триммер. И да, триммер быстрее и удобнее. Усталости сильно меньше. Но сам почти всегда достаю привычную литовку. Как так? А вот так. Только ей у меня получается сделать хорошо. После триммера волны. Где-то дерн цепляет, где-то недорезает. А к литовочке настолько привыкла рука, что ей плохо сделать ну никак не получится.

                                                                  К чему весь этот спич? Горбуша — ассемблер с макросами, ибо без макросов серп получится (тоже к слову умею). Литовка — это С. А триммер — все что выше и лучше. Косить гектары даже триммером так себе идея. Тут комбайн нужен. Обкосить канаву литовкой тоже не лучшая идея. Камни, рытвины. Уж лучше триммер. А вот скосить «английский газон» перед домом… Ну ка его, этот триммер. Лучше литовочку. Чтоб результат глаз радовал. Да травку вывезти, а не на месте гнить оставить (привет автоматическим сборщикам мусора). Больше того — в кусту смородины сорняки покосить — так тут и литовки много будет. Тут в сарае серп лежит.

                                                                  Рачительный хозяин любому инструменту применение найдет. Главное понимать где границы применимости.
                                                                    +1

                                                                    Этот комментарий можно сократить до двух слов: "Сперва добейся"

                                                                      +2
                                                                      Ну что Вы. Совсем нет. 0xd34df00d мне хорошо знаком по комментариям в других темах. Уж ему-то точно даже мысли нет отвечать в таком ключе. Как и другим оппонентам в этой теме.

                                                                      Свое отношение я выразил первым комментарием. Могу повторить. Обсуждать недостатки языка С имеет смысл с теми, кто им пользуется на регулярной основе. Только эти люди знают о нем все. Но ведь они, как правило, и не спорят. Больше того — даже не ввязываются. «Собака лает — караван идет».

                                                                      Те же, кто «когда-то подходил к этому снаряду», но по тем или иным причинам не стал им пользоваться как раз и превращаются в ярых противников. Можно сказать что в этот раз еще культурно. Обычно такие споры злее. Массивы и указатели. Указатели на функции. Двойные, тройные указатели. Размерность стандартных типов. time_t разного размера. Опять же errno. Имя им легион. В принципе понятно, что язык С давно требует как минимум глубокой модернизации. Но провести эту модернизацию упорно пытаются со времен D и C++. Местами успешно. В свое время в вебе perl легко подвинул С++ — он был банально удобнее.

                                                                      Сможет ли кто-то из ныне существующих подвинуть C в низкоуровневом программировании? Не знаю. Хабр любит Rust. Мне он не понравился. Я переборол первое впечатление и попробовал его в деле. Нет. Не нравится. Синтаксис. Необходимость переделывания «заголовочных» файлов железок. Итоговый двоичный код. Возможно, это наведенное — следствие плохого первого впечатления. Но для меня показатель еще и в другом. Где работа Rust community? Почему до сих пор на github'е нет синхронизируемого в ванилью репозитария ядра Linux (с переписанными важными частями системы)? Почему нет значимых попыток переписать (U)EFI на Rust? Все ждут пока кто-то за них это сделает? Ну хорошо, пусть ждут. "… Караван идет". А то, что на Хабре очень много решительно настроенных противников С для меня давно не новость. В том же первом комментарии было написано «Это Штирлиц. Сейчас будет драка.» Это было слишком очевидно.
                                                                        +2
                                                                        Почему до сих пор на github'е нет синхронизируемого в ванилью репозитария ядра Linux (с переписанными важными частями системы)?

                                                                        Слишком толсто, попробуйте ещё раз.

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

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


                                                                          Почему до сих пор на github'е нет синхронизируемого в ванилью репозитария ядра Linux (с переписанными важными частями системы)?

                                                                          В ядре линукса, кстати, раст не так давно разрешили.

                                                                            +1
                                                                            Вьедливы Вы. Но, как всегда справедливы. Конечно. Те, кто пользовался довольно долго (есть успешные проекты в продукте, с количеством в штуках порядка нескольких десятков тысяч). Те, кто сопровождал свой код на С несколько лет, но сегодня сменил род деятельности. Да и вообще — я, вроде, никому рот не затыкаю. В этой теме я скорее «адвокат дьявола». А прокуроров хватает.

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

                                                                              Да, безусловно, здесь я полностью с вами согласен. И знание C++ не сделает из вас хорошего программиста на C (собственно, поэтому я говорю, что как-то там знаю плюсы, но не знаю C), но при этом знание проблем C++ вместе с ограничениями C позволяет сделать выводы о проблемах C.

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

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

                                                                                Впрочем, справедливости ради стоит заметить — сегодня объем кода, производимого компиляторами С едва ли подберется к 1% от кода с других языков. И это соотношение весьма внушительно. Можно сколько угодно кричать о том, что прочность цепи это прочность самого слабого звена. Можно пенять на С говоря смотрите — CVE на CVE сидит и CVE погоняет. Но где хоть какие-то гарантии того, что в оставшихся 99% дырок меньше. Просто нашему 1% уделяется самое пристальное внимание. В первую очередь именно по причине того, что типовые заморочки очень хорошо известны и довольно легко обнаруживаемы.

                                                                                Согласен — ситуация не нормальная. Только вот обвинить язык С в том, что именно на нем лежит вся вина… Что он провоцирует написание кривого кода… Что он генетически неправильный… Да ну, нафиг. По мне это перекладывание ответственности с программиста на язык… Не правильно это как-то. Впрочем, оценка комментариев как раз говорит о том, что мнение это на хабре не популярно. И я теряюсь в догадках, популярно ли ему обратное. Что любая кухарка должна уметь управлять государством писать любые программы, а уважающий себя язык должен ей в этом помогать, четко и однозначно указывая на проблемы. Этакая диктатура языка, вплоть до исправления алгоритма решения. Нет уж. Мне больше по душе демократия С.
                                                                                  +5
                                                                                  У меня нет никаких проблем контролировать переполнение

                                                                                  Интересно, как вы это делали, если переполнение знаковых целых в C — неопределённое поведение.


                                                                                  А возможность разыменовывания любого указателя (а равно арифметика указателей) позволяет весьма эффективно управлять аппаратурой.

                                                                                  Ага, например, писать в порт для чтения и читать из порта для записи.


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

                                                                                  [citation needed]


                                                                                  Можно пенять на С говоря смотрите — CVE на CVE сидит и CVE погоняет. Но где хоть какие-то гарантии того, что в оставшихся 99% дырок меньше. Просто нашему 1% уделяется самое пристальное внимание.

                                                                                  Ну так-то не 1 процент, а где-то 70.


                                                                                  Только вот обвинить язык С в том, что именно на нем лежит вся вина… Что он провоцирует написание кривого кода…

                                                                                  Именно что провоцирует. Всякие телодвижения со стороны программиста, способствующие написанию лучшего кода, дополнительные по сравнению с хреновым умолчанием. В частности, C провоцирует:



                                                                                  Нет уж. Мне больше по душе демократия С.

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

                                                                                    0
                                                                                    Ну ведь уже обсуждалось неоднократно. Неопределенное поведение… Ну да. Вопрос в том, что если в определенной точке ОЖИДАЕТСЯ переполнение, то его можно уловить либо расширениями компилятора (как в gcc) либо опусканием на уровень ассемблера и контроля флага переполнения. А если не ожидается, то и пережить его не получится — алгоритмическая ошибка. Про порты — язык С позволяет все, что может процессор. Порт — не часть процессора. Порт часть устройства. Более того, есть практика борьбы с частью названных проблем с помощью const (но лично я ее не поддерживаю). Ах да, простите. Хороший компилятор и алгоритмические ошибки выщучивать должен. Жеваный доширак, который ленивому программисту еще и помочь проглотить надо. Может проще дождемся когда ИИ начнет код писать? С такими компиляторами это не так уж и сложно.

                                                                                    [citation needed]

                                                                                    [ignored] Считаем авторскими мыслями. Раз цитата не приведена.

                                                                                    Про 70%… Ну читайте внимательнее. По сути это говорит о последствиях взрывного роста популярности C++. Авторы той статьи сильно больше спровоцировали приход «кодеров» в свои продукты «выкатив» такие надстройки над WinAPI как MFC. Так ведь еще раз — на свете ничего не дается бесплатно.

                                                                                    Да и список ваш. Тот, который на НЕ начинается. Целиком и полностью выдает ровно то, о чем я говорю с 0xd34df00d Все перечисленные проблемы сильно мешают в плюсах. В обычном С память по нулевому адресу это просто память по нулевому адресу. Ее можно читать, ее можно писать. Никто не может ограничивать конституционную свободу автора читать и писать из любого места (а равно делать что хочешь, не противоречащее закону). А все, что противоречит тут же прибивается с помощью SIGBUS/SIGILL, DATA_ABORT_HANDLER, PREFETCH_ERROR_HANDLER и множества других механизмов специфичных для разных платформ. Меня как раз радует возможность писать что-то типа
                                                                                    switch (fn(a,b,c)) {
                                                                                      case x:
                                                                                      case y:
                                                                                        do_required_prepare();
                                                                                      case z:
                                                                                         do_required_job();
                                                                                         break;
                                                                                      case_t:
                                                                                        do_nothing();
                                                                                        break;
                                                                                      default:
                                                                                        err("WTF!\n");
                                                                                    }


                                                                                    И строго по мне, все остальное либо «коммунизм в отдельно взятой песочнице» интерпретируемых языков, либо «олигархический капитализм». Для меня компилятор — партнер и советчик. А не надзиратель в тюрьме. И именно за это любят язык С.

                                                                                    Впрочем, воображение уже рисует цветастую картину. Ночью, под завешенными шторами, на отключенном от интернета компьютере ковыряем залоченный загрузчик myPhone 200 и запускаем на нем код, написанный на находящемся вне закона языке С. Впрочем, завязываю шутить. Есть у моих шуток дурацкое свойство — через некоторое время оказываться пророчествами.
                                                                                      +3
                                                                                      Хороший компилятор и алгоритмические ошибки выщучивать должен.

                                                                                      А разве нет?


                                                                                      Я вот сейчас кое-какой код пишу, и там компилятор off-by-one-ошибки вот регулярно за меня ловит (потому что я так типы сформулировал, что обращение не туда просто не проходит тайпчекинг). Ловил он и не то что ошибки в алгоритмах, а ошибки в спеке, когда я случайно сформулировал то, что не имеет смысла.


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

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


                                                                                      В обычном С память по нулевому адресу это просто память по нулевому адресу. Ее можно читать, ее можно писать.

                                                                                      Как хорошо, что стандарт обычного C публично доступен! Так вот, 6.3.2.3/3 (страница 47 по внутренней нумерации) намекает, что это не так.


                                                                                      Кстати, у меня там глаз вниз скользнул (до 6.3.2.3/7) — прикольно, я не знал, что одна лишь конвертация указателя на неполный тип в указатель на другой неполный тип является UB, если выравнивание для целевого типа некорректно. Я думал, его только разыменовывать потом нельзя, а оно вона как. А вы знали?


                                                                                      Более того, сноска в 6.5.3.2/4 прямо говорит, что вы неправы: «Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer, [...]»


                                                                                      Ну так что мы будем с вашим тезисом делать?


                                                                                      Никто не может ограничивать конституционную свободу автора читать и писать из любого места (а равно делать что хочешь, не противоречащее закону).

                                                                                      Стандарт ограничивает. Более того, стандарт запрещает даже вещи типа


                                                                                      typedef struct Foo
                                                                                      {
                                                                                        int a, b;
                                                                                      } Foo;
                                                                                      
                                                                                      void doSmth(Foo foo)
                                                                                      {
                                                                                          int *ptr = &foo.a;
                                                                                          ptr[1] = 10; // типа пытаемся установить b
                                                                                      }

                                                                                      Поиск соответствующих мест в стандарте предлагается читателю в качестве упражнения.


                                                                                      Более того, вы не то что читать или писать не можете, всё ещё хуже. Вы формировать указатели можете не всегда! Например,


                                                                                      int arr[10];
                                                                                      int *ptr = arr + 11;

                                                                                      уже UB.


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

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


                                                                                      Под айфончиком-то запускать, в принципе, не страшно. Мне даже для attiny писать код было не страшно. Или для личного опенсорс-хобби-проекта, где ну навернётся моё приложение — хрен с ним. Даже на почти всех работах было писать на плюсах не страшно — ну навернётся, ну в худшем случае кто-то получит 500 internal server error из-за того, что мой бэк упал.


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


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

                                                                                        +1
                                                                                        Не… Давайте не передергивать.

                                                                                        вы ж сами пишете, что на раст вам перекатываться лень (синтаксис там непривычный, заголовочные файлы конвертировать надо…)


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

                                                                                        Более того, сноска в 6.5.3.2/4 прямо говорит, что вы неправы:


                                                                                        Хороший вопрос. У меня есть чипы, на которых ROM размещается с нуля. И вектор сброса там. И как его тогда читать непонятно. И не менее непонятно, чем мне могут помочь в этом плане другие языки (ассемблер — вас это не касается). Потому, неверное, плакать. И страдать. Или, что более вероятно, плюну на эту сноску как это сделали разработчики компиляторов. Но в целом вопрос на пятерку.

                                                                                        Стандарт ограничивает. Более того, стандарт запрещает даже вещи типа...


                                                                                        Да. Но еще раз — компилятор друг. Поэтому ругнется Warning'ом (а может даже и Error'ом). Но никак не запретит мне использовать явное приведение типов. «Ну, раз ты уверен — я не возражаю». А я лишний раз проверю не перемудрил ли я с такими конструкциями и нельзя ли сделать проще и понятнее.

                                                                                        Вообще я смотрю на те примеры, которые приводе Вы и диву даюсь. "Доктор, откуда у Вас такие картинки"?

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

                                                                                        А вас не смущает необходимость следовать всяким там MISRA C при написании кода на сях для автомобилей, например?


                                                                                        Знаете, как все связанное с С — больная тема. Я безусловно признаю полезность MISRA. Вот просто безусловно. Больше того, когда судьбинушка заносит в IAR обязательно ставлю эту галку как минимум на «посмотреть на грабли». Но… Уж очень разные чипы. Уж очень по разному устроена кодогенерация у разных компиляторов (даже не смотря на простоту внутреннего мира С). Потому временами рекомендации MISRA сильно ухудшают читаемости (а значит сопровождаемость) и скорость кода. Потому если нет жестких требований, то «поверю, посмотрю на вывод, где сам считаю нужным поправлю». К счастью (или несчастью) у меня пока не было ни одного проекта где MISRA была бы в обязательных требованиях.

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

                                                                                        Но потом я пришёл на работу, где люди моим кодом будут торговать на бирже, и где есть реальная ответственность, от материальной на много-много денег до уголовной...


                                                                                        Вы вот упомянули автомобильные системы. Да, там MISRA. Но и там жизнь и здоровье. При чем еще неизвестно где больше. Впрочем, мне вот интересно, а BIOS в тех вычислительных системах, на которых крутой и верифицированный код работает на чем написан?

                                                                                        Опять же речь о применимости инструментов. Об ограничении одних сверху, других снизу. Я совсем не хочу «С везде».
                                                                                          +4
                                                                                          И как его тогда читать непонятно.

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


                                                                                          И не менее непонятно, чем мне могут помочь в этом плане другие языки (ассемблер — вас это не касается).

                                                                                          В других языках не обязана быть аналогичная сноска про null pointer.


                                                                                          Или, что более вероятно, плюну на эту сноску как это сделали разработчики компиляторов.

                                                                                          Одного конкретного компилятора под одну конкретную систему.


                                                                                          Давайте напишем очень простой сишный код


                                                                                          int foo(int *ptr)
                                                                                          {
                                                                                              int val = *ptr;
                                                                                              return ptr ? 1 : 0;
                                                                                          }

                                                                                          и соберём его под x86_64: тыц. С оптимизациями gcc собирает такой код:


                                                                                          foo:
                                                                                                  mov     eax, 1
                                                                                                  ret

                                                                                          (clang, надо признать, проверку оставляет, но от неё легко избавиться, если использовать val — видимо, optimization pass'ы по-разному расположены).


                                                                                          Заметьте, никакой проверки аргумента! Компилятор решил, что ptr нулевым не бывает. А если убрать int val = *ptr; (которая в результирующий бинарь всё равно не вошла), оставив только строку с return? Тогда проверка возвращается:


                                                                                          foo:
                                                                                                  xor     eax, eax
                                                                                                  test    rdi, rdi
                                                                                                  setne   al
                                                                                                  ret

                                                                                          И в ядре, кстати, не так давно из-за этого было CVE. И в моей практике из-за схожих вещей не так давно были всякие интересные, гм, проблемы.


                                                                                          Вы там дальше пишете про ворнинги. Будут ли они здесь? Нет, не будут. Даже с -Wall -Wextra или -Weverything. Ну, кроме ворнинга о неиспользуемой переменной, который отношения к делу не имеет. Статический анализатор, в принципе, ругнуться может, но это дело ненадёжное, и пропадает с повышением сложности кода.


                                                                                          Поэтому ругнется Warning'ом (а может даже и Error'ом).

                                                                                          Нет, не ругнётся. И у меня из-за этого в проде был баг.


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

                                                                                          Зачем? Там типы одинаковые. Стриггерить проявимое UB в этом конкретном случае у меня не получилось, но есть другой интересный: тыц (компиляторы снова молчат как партизаны).


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


                                                                                          #include <string.h>
                                                                                          
                                                                                          int foo(void)
                                                                                          {
                                                                                              int x = 0, y = 1;
                                                                                              int *py_bad = &x + 1;
                                                                                              int *py = &y;
                                                                                          
                                                                                              if (memcmp(&py, &py_bad, sizeof(py)) == 0)
                                                                                                  *py_bad = 11;
                                                                                          
                                                                                              return *py;
                                                                                          }

                                                                                          Компилятор оптимизирует это в чистый return 1;, и запись в py_bad его совершенно не волнует. Но это только цветочки. Давайте проверим, равны ли адреса? А то вдруг они не равны, и компилятор всё правильно делает?


                                                                                          #include <string.h>
                                                                                          
                                                                                          int foo(void)
                                                                                          {
                                                                                              int x = 0, y = 1;
                                                                                              int *py_bad = &x + 1;
                                                                                              int *py = &y;
                                                                                          
                                                                                              if (memcmp(&py, &py_bad, sizeof(py)) == 0)
                                                                                                  *py_bad = 11;
                                                                                          
                                                                                              return memcmp(&py, &py_bad, sizeof(py));
                                                                                          }
                                                                                          
                                                                                          int main()
                                                                                          {
                                                                                              printf("%d", foo());
                                                                                          }

                                                                                          Программа печатает -1 — хм, вроде как не равны. Неужто я ошибся? Ну не знаю, давайте зачем-нибудь закомментируем if, превратив foo() в


                                                                                          int foo(void)
                                                                                          {
                                                                                              int x = 0, y = 1;
                                                                                              int *py_bad = &x + 1;
                                                                                              int *py = &y;
                                                                                          
                                                                                              return memcmp(&py, &py_bad, sizeof(py));
                                                                                          }

                                                                                          Теперь равны! Магия, не иначе (на самом деле не магия, а вполне объяснимый и понятный оптимизатор на UB — в предыдущем случае компилятор считает, что memcpy не может вернуть ноль, поэтому по какой-то своей наркоманской логике выбирает -1 как другой вариант).


                                                                                          Много релевантных ворнингов от компилятора видите?


                                                                                          Вообще я смотрю на те примеры, которые приводе Вы и диву даюсь. "Доктор, откуда у Вас такие картинки"?

                                                                                          Это редуцированные примеры того, с чем я сталкивался и что приводило к проблемам в продакшене. Могу ещё мноооооого таких примеров привести.


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

                                                                                          Стандарт не требует никакого «чёткого подтверждения». Стандарт такие конструкции вообще запрещает, но при этом как раз говорит «no diagnostic required» (program is ill-formed, no diagnostic required — это одна из альтернативных формулировок UB). То есть, компилятор вам не поможет. Ворнинги вам не помогут. Ничего вам не поможет, счастливой отладки!


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

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


                                                                                          Впрочем, мне вот интересно, а BIOS в тех вычислительных системах, на которых крутой и верифицированный код работает на чем написан?

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

                                                                                            0
                                                                                            А что ты хочешь доказать?
                                                                                              +4

                                                                                              Что C — язык небезопасный, что компилятор C вам не друг, и что запрет чего-то в стандарте — не что-то хорошее, а скорее наоборот.

                                                                                              –3
                                                                                              Это редуцированные примеры того, с чем я сталкивался и что приводило к проблемам в продакшене. Могу ещё мноооооого таких примеров привести.


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

                                                                                              Что до так пугающих множественных UB — так их количество растет вместе с ростом вычислительной техники. Сначала endian-, потом align-, потом многоядерность-многопоточность. Везде, где нельзя гарантировать одинаковый результат на разных платформаю рисуется UB. И это меньшее зло, чем отдавать предпочтение одной платформе и «давить» другую.

                                                                                              Чуть хуже дело обстоит с оптимизацией. Впрочем, я уже говорил в других темах. Основная борьба — это борьба с оптимизатором. Вот тут да… Но, блин — ведь я за это должен быть благодарен как раз прикладникам. Это их стараниями появились странные оптимизации и принудительным inline-ингом или наоборот выносом кода в отдельные функции. Потому привычка писать с "-O none" и в крайнем случае использовать "-O size" давно и неискоренимо выработана. Борьба за размер или скорость — это моя борьба. Я и ее не хочу доверять компилятору.

                                                                                              Ничего вам не поможет, счастливой отладки!


                                                                                              Спасибо. Именно за уничтожение этого кактуса методом сгрызания мне деньги и платят. Больше того — у меня в ряде случаев нет даже отладчика или debug-консоли. И тем не менее, я продолжаю считать С лучшим НИЗКОУРОВНЕВЫМ языком.

                                                                                              Много релевантных ворнингов от компилятора видите?


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

                                                                                              а вот кардиостимулятор я бы предпочёл ...


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

                                                                                              На сях… и это не моя головная боль.


                                                                                              Ну так я снова и снова предлагаю вернуться к началу. Может не надо мешать нам грызть кактус. Тем более, что рецептура текилы нам давно известна. Мы рады, что нам сочувствуют. Но менять особо ничего не хотим.
                                                                                                +1
                                                                                                Самое обидное, это то, что ни в одной из прочитанных книг не говорилось прямо: код, собранный с -Os, может проходить тесты, а код -O3 их может проваливать, даже если программа написана с соблюдением стандарта. В такие моменты ценность тестов особенно чувствуется :)
                                                                                                  –2
                                                                                                  И все же это чисто плюсовая заморочка. Ну не пишут более-менее толковые разработчики на голом С код, который может быть выкинут оптимизатором. Особенно в ядре, драйверах и под контроллеры. А вот плюсы… С их «кодом на все случаи жизни». Сначала научили компилятор выкидывать не нужный в проекте код, максимально обдумывать код уже на этапе компиляции, потом установив высокую оптимизацию дали ему полный карт-бланш — делай что сочтешь нужным. Он и делает ровно то, что попросили. Потом почему-то обижаются — что ж он такое понаделал… А виноват в итоге оказывается вообще язык прародитель. Да нет, ребята. Не надо на зеркало обижаться. И инструменты, которыми работаем знать надо.

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

                                                                                                  А вот что с этим делать? А ничего не делать. Жить как живется. И не писать «мертвый» код по возможности.
                                                                                                    0

                                                                                                    Вы говорите скорее о типа-фреймворках, где вы ожидаете от компилятора удаления неиспользуемых функций, тогда как дело скорее в инлайнинге вещей вроде тех же STL'ных алгоритмов.


                                                                                                    Вот я использую std::any_of, чтобы проверить, есть ли какой-то элемент в массиве. Там нет ни строчки мёртвого кода, просто оптимизатор позволяет свернуть 350 строк порнографии и вызовов функций в 10 строк адекватного и оптимизированного кода. Кстати, с SIMD, и в любом случае быстрее, чем выхлоп компилятора для руками написанного цикла, но без оптимизаций.

                                                                                                  +5
                                                                                                  Интересно код в продукт каким путем шел.

                                                                                                  Где-то — потому что его писали свежие выпускники вузов, которые C++ видели второй год в жизни. Где-то — потому что его писали несвежие «опытные» «хакеры», которые считали, что это всё очень умные трюки.


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


                                                                                                  Везде, где нельзя гарантировать одинаковый результат на разных платформаю рисуется UB. И это меньшее зло, чем отдавать предпочтение одной платформе и «давить» другую.

                                                                                                  Конечно. Но проблема не в этом, а в том, что no diagnostic required.


                                                                                                  Потому привычка писать с "-O none" и в крайнем случае использовать "-O size" давно и неискоренимо выработана. Борьба за размер или скорость — это моя борьба. Я и ее не хочу доверять компилятору.

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


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

                                                                                                  Не, мне тоже в своё время платили во многом потому, что ко мне можно было обратиться либо с наркоманским вопросом по плюсовым шаблонам, либо по отладке какого-нибудь упоротого бага, и я в подавляющем большинстве случаев проблему решал, но… что-то мне это надоело.


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

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


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

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


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


                                                                                                  Тяжела жизнь прикладника.

                                                                                                  Это что же, прикладникам сложнее, чем системникам? :]


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

                                                                                                    0
                                                                                                    Я грозился завязывать. И завязываю. Но не спокойно на душе, когда остались «висящие в воздухе» вопросы. Потому не смотря на ясность позиций, все же отвечу. Не столько Вам, сколько окружающим (судя по выставляемым оценкам тему все еще считают интересной).

                                                                                                    — И это меньшее зло, чем отдавать предпочтение одной платформе и «давить» другую.
                                                                                                    — Конечно. Но проблема не в этом, а в том, что no diagnostic required.


                                                                                                    Ну так я нигде и не говорил, что С это золотой червонец, который обязан нравится всем. Вы приводили ссылку на стандарт. Мне страшно представить насколько обесценятся предупреждения компилятора, если на каждый чих оттуда выдавать Warn'инг. Кому это реально важно — есть статические анализаторы. Более того, «no diagnostic required» у «хороших» компиляторов не превращается в «diagnostic no required» (странная русско-английская игра слов, призванная сказать что часть компиляторов диагностику таки выдает).

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


                                                                                                    В частности IAR очень любит поругаться на выравнивания. Местами даже не по делу. Нет у меня под рукой единственного проекта где я его Warning не смог побороть, потому привести его не могу. Уж поверьте на слово — ругается. GCC сильно не любит смесь знаково-беззнаковых операндов, способных привести к потере знака в результате. Опять без примеров. Просто потому, что под рукой нет. Но сталкивался. Clang фанатично выверяет форматную строку. Это из самых известных. Вообще, хорошая тема для отдельной статьи. Я, пожалуй, попробую выкроить на нее время. Оно того точно стоить будет.

                                                                                                    Но пока у меня выход ядра 5.10(.1) каким-то боком поломал загрузку на I.MX6. Как минимум наблюдаются проблемы с видео и сетью. Видимо удаление платформенного кода не прошло даром. Надо разбираться… Пока не гонят, но когда гнать начнут у меня уже решение должно быть.

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


                                                                                                    Нет же. Я уважаю коллег по цеху и далек от мысли о том, что оптимизатор «глючный и бажный». Да и вопрос что в Вашем понимании «хакерский код». Мне кажется, хакерский код — это лаконичный, понятный, самодокументирующийся код. Посмотрите на код ядра Linux. В подавляющем большинстве случаев он предельно прост, понятен и не оставляет особого простора оптимизатору. Потому его выключение мало на что влияет. Можно и включить — только это приведет лишь к увеличению времени компиляции. Больше того — временами я делаю тестовые сборки со всеми возможными уровнями. Ровно затем, чтоб убедиться — не ломается.

                                                                                                    [OFFTOPIC] В одной из тем я наловил минусов, пытаясь объяснить за что ж я не люблю ST Microelectronics. Так вот как раз за это. CamelCode, излишняя многословность. А когда начинал знакомство с ними еще и зависимость от уровня оптимизации. С моей колокольни фу-фу-фу. [/OFFTOPIC]

                                                                                                    Ну и тут есть ещё такой аспект, что… ну, короче, дети же смотрят!


                                                                                                    Да. Только вот у нас очень разный подход к этому факту. Я пытаюсь сказать — учите. Начать очень просто, а дальше сами поймете. А вы отпугиваете излишними сложностями. Впрочем, это даже хорошо. Запретный плод всегда сладок. И манит он как раз самых любопытных и любознательных. Потому альфа и омега, лед и пламень, ангелы и демоны… Но именно в паре. Нельзя чтоб одна сторона перевешивала. Надеюсь у меня получилось.

                                                                                                    А вообще странное разделение, я его перестал понимать.


                                                                                                    Да. Водораздел здесь не очевидный. И каждый его ставит себе сам (если ставит, конечно). Для меня, все что непосредственно взаимодействует с железом — то системное. Остальное — прикладное со своим делением. Но это, конечно, условность. Потому как разработка компиляторов, обработчики протоколов в ядре, стеки типа mac802.11 — безусловно системное программирование, а непосредственно железа вроде не касается.

                                                                                                    Впрочем, я стараюсь не отнимать хлеб у прикладников (по своей классификации). И, боже упаси, учить их правильному подходу к программированию. Соответственно ровно такого же отношения ожидаю к себе.
                                                                                                      0
                                                                                                      Ну так я нигде и не говорил, что С это золотой червонец, который обязан нравится всем. Вы приводили ссылку на стандарт. Мне страшно представить насколько обесценятся предупреждения компилятора, если на каждый чих оттуда выдавать Warn'инг. Кому это реально важно — есть статические анализаторы.

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

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

                                                                                                        Абсолютно верно. И в этом проблема.


                                                                                                        В частности IAR очень любит поругаться на выравнивания. Местами даже не по делу. Нет у меня под рукой единственного проекта где я его Warning не смог побороть, потому привести его не могу. Уж поверьте на слово — ругается. GCC сильно не любит смесь знаково-беззнаковых операндов, способных привести к потере знака в результате. Опять без примеров. Просто потому, что под рукой нет. Но сталкивался. Clang фанатично выверяет форматную строку. Это из самых известных.

                                                                                                        Я же просил: «который здесь скажет что-нибудь полезное». Вот в этом конкретном месте.


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

                                                                                                        Ну поставщики, не умеющие писать код — это вообще классика.


                                                                                                        Для меня, все что непосредственно взаимодействует с железом — то системное.

                                                                                                        Ну вот когда я руками пишу у себя в коде какой-нибудь vpcmpestrm, или соответствующий интрисник, то я взаимодействую с железом?


                                                                                                        Потому как разработка компиляторов [...] — безусловно системное программирование

                                                                                                        Ура, хаскель к системному программированию готов!

                                                                                                    –1
                                                                                                    И, между прочим, заметьте как же прав компилятор в каждом из ваших примеров.

                                                                                                    int foo(int *ptr)
                                                                                                    {
                                                                                                        int val = *ptr;
                                                                                                        return ptr ? 1 : 0;
                                                                                                    }


                                                                                                    Чистая единица. val — локальна, и нигде за пределами функции не живет, но раз в нее есть запись из указателя, который не проверяется, значит указатель не NULL — а значит ну его к лешему — return 1 и нафиг. А если убрать присвоение (не вошедшее в бинарь, но участвующее в кодогенерации) проверка вернется. Потому как тогда указателю веры нет.

                                                                                                    Можно я второй пример разбирать не буду? Там поведение компилятора ровно так же очевидно. Вся фигня с этими примерами — время жизни локальный переменных. Правда отягощенное высосанным из пальца странным доступом к рядом расположенной переменной. Потому со всей ответственностью — притянуто за уши.

                                                                                                    Вопрос подачи материала. Эмоционально и с матами у Вас или взвешенно и с пониманием у меня.

                                                                                                    Вообще, кинули бы личкой подобного. Хорошие вопросы для собеседования кандидатов и обучения молодежи. На знание и понимание особенностей работы компиляторов в языка С. Я, в силу склада характера, подобного даже придумать не смогу.
                                                                                                      0
                                                                                                      Чистая единица. val — локальна, и нигде за пределами функции не живет, но раз в нее есть запись из указателя, который не проверяется, значит указатель не NULL — а значит ну его к лешему — return 1 и нафиг. А если убрать присвоение (не вошедшее в бинарь, но участвующее в кодогенерации) проверка вернется. Потому как тогда указателю веры нет.

                                                                                                      Именно. Это и была демонстрация того, что разыменование нулевого указателя — UB, и компилятор может им пользоваться.


                                                                                                      Потому со всей ответственностью — притянуто за уши.

                                                                                                      Нет. Редуцированный пример, опять же.


                                                                                                      Вопрос подачи материала. Эмоционально и с матами у Вас или взвешенно и с пониманием у меня.

                                                                                                      Да я тоже понимаю, тащем-та. А за эмоции извините, просто каждый из этих примеров в своё время требовал часы, дни или недели не очень тривиальной отладки, так что воспоминания приносят определённые эмоции. Ну и легко говорить, что тут всё очевидно (кстати, нет, не всё), когда перед вами 10 строк minimal reproducing example, а когда перед вами проект на сотню-другую тыщ строк, который писали не вы — всё становится немного веселее.


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

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


                                                                                                      Я, в силу склада характера, подобного даже придумать не смогу.

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

                                                                                                        –1
                                                                                                        А это, кстати, интересная тема…


                                                                                                        Да проще все… Вы сильно увлеченный человек. Ваше право. Я, лет до 25 таким же был. Потом дошло — жизнь программированием не начинается и не заканчивается. Есть и другие темы. Важные и интересные. Да и объять необъятное не получится. Закон качалки гласит — всегда найдется человек, который твоим весом только разминается. Потому плюнул и стал сильно спокойнее относится к тому, что на свете много людей куда более умных, нежели моя наглая морда.

                                                                                                        Одна беда — в религиозные споры типа этого не влезать так и не обучился.

                                                                                                        А статью жду. И, думаю, все же стоит закругляться. Тут, пожалуй, все уже сказано.
                                                                                              0
                                                                                              Ага, например, писать в порт для чтения и читать из порта для записи.
                                                                                              Емнип, битбэнг на avr как раз так и работает.
                                                                                      +1
                                                                                      Обсуждать недостатки языка С имеет смысл с теми, кто им пользуется на регулярной основе. Только эти люди знают о нем все.

                                                                                      Не верю. Кто-то может и знает. Но большинство по-моему просто делает -fno-strict-aliasing и вперёд с песней.

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

                                                                            Вот хороший пример кода на С, обмазанного достаточным количеством кода на AstraVer для того, чтобы доказать его корректность. Написание всего этого кода (весь проект — гарантированно безопасный загрузчик PE-образов для UEFI) заняло у двух не самых глупых товарищей полгода, а я такой же загрузчик на том же С (но уже без каких-либо гарантий, кроме «от фаззинга не падает» и «мамой клянусь») написал в 2016 году за три дня. В итоге программировать на С так, чтобы гарантировать отсутсвие ошибок, могут себе позволить только те, кто сидит на финансировании из бюджета, и потому по времени практически не ограничен, а коммерческие компании вынуждены бежать, сломя голову, только чтобы на своем месте оставаться, и потому практически весь их код на С не выдерживает никакой критики с точки зрения безопасности.

                                                                            В итоге недостатки слишком много позволяющего языка пытаются чинить в железе, уже занесли туда теневой стек (Intel CET), подписывание указателей (ARM PAC), тегирование памяти (ARM MTE), и теперь работают над заносом туда же контрактов, которые будет расставлять компилятор, потому что программиста это делать невозможно заставить (CHERI).

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

                                                                            Короче, если у вас пока что на С все работает и жрать не просит — смело продолжайте на нем писать. А у нас вот давно уже от С геморрой сплошной, а заменить его толком не на что, потому что C++ — это такое же хтоническое чудовище, вид сбоку, а внедрение Rust пока буксует по экономическим причинам (дорого переучивать всю ораву, дорого писать клей, дорого переписывать то, что не получилось приклеить, а дело делать надо уже сейчас).
                                                                              0
                                                                              Драка


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

                                                                              Проблема современного С, как то не странно — это его стандартная библиотека. Вот она явно требует пересмотра. Все эти errno при фиксированном возврате -1. Даже в ядре возвращается -ERRNO, что сильно более разумно. Все эти странные флаги и параметры времен расцвета железных терминалов и перфокарт. Впрочем, если заменить ее умрет язык. Убьем священную корову обратной совместимости. Этого не простят. Потому, увы, но… Кактус этот еще грызть и грызть… Боюсь, тут даже Rust не поможет. Впрочем, применительно к UNIX, я готов согласиться — init и выше уже не тема для языка С. А вот ядро и ниже — еще какая тема.

                                                                              А уж для контроллеров — так вообще безальтернативно. Сегодняшний Rust для них — это тот же С, только с непривычным синтаксисом. Да и опять контроллеры — это минимальное время, а минимальное время никак не вяжется с безопасностью. Триада скорость, понятность, безопасность. Как всегда — максимум два из трех. Впрочем, по мне именно С разумный компромис для всех трех. Опять же — может просто потому что для меня это привычный инструмент.

                                                                              А про большие проекты, с программированием на скорость. Ну да, тут сложно. С одной стороны не поспоришь. Все так. С другой стороны — а разве можно сравнивать анархию с С и порядок и тестирование на других языках. Чертов «человеческий фактор» всегда самый главный. И уж следом идут средства разработки. Впрочем я повторюсь про «init и выше». Время, когда всю систему необходимо было писать на низкоуровневых языках типа С давно прошло. И, если честно, нет о нем особых сожалений.
                                                                                +11
                                                                                Проблема именно в языке как таковом. Язык оказался принципиально не совместим с человеками, потому что человеки делают на нем ошибки (они неизбежны по человеческой природе), а ошибки эти имеют непредсказуемые последствия. Вот такие, например, последствия имеет банальное переполнение буфера даже с учетом всех вообще технологий предотвращения эксплуатации. И это на платформе, в безопасность которой ежегодно вкладываются сотни миллионов долларов, а в результате все равно одна небольшая ошибка (забыли добавить новое значение в switch, отчего сработал слишком разрешительный default) приводит к получению полного контроля над удаленным устройством без участия его владельца.

                                                                                Хорошо сделанная система, которая взаимодействует с людьми, должна учитывать ограничения этих самых людей, и минимизировать как количество ошибок, как и глубину распространения эффектов от них, а в С вместо этого половина конструкций языка — это undefined behavior, а из другой половины разного рода острые грани торчат, про которые никто толком не знает, пока эти грани в очередной раз не разорвут всю безопасность на немецкий крест. Хороший язык должен по умолчанию следить за тем, чтобы пользователь не творил ерунды, а если ему надо ее творить, чтобы это творение было явным, и чтобы у каждого такого места «пошел в пень, компилятор, я лучше знаю» обязательно стояла табличка «ОСТОРОЖНО, РАБОТАЮТ ЛЮДИ!». А в С эту табличку надо программисту на лбу рисовать перманетным маркером.
                                                                                  –1
                                                                                  Убить всех человеков!

                                                                                  Слушайте, я не могу ничего возражать. Безусловно, во всех современных бедах виноваты люди. Это они изобрели атомное оружие, это они устроили глобальное потепление и озоновую дыры. Может чего тут мелочитьсся — всего-то запрещать писать на С (а паче на ассемблере — там косячат даже самы опытные). Я не верю в возможность написания программ без ошибок вообще. Во всяком случае живыми людьми. Не стоит недооценивать изобретательность отдельных индивидов.
                                                                                    +7
                                                                                    Не надо ничего запрещать, но необходимо улучшать инструменты, чтобы делать меньше ошибок. Никто не говорит ни о запрете (написал же выше, нравится — пользуйтесь на здоровье), ни о полном решении проблемы ошибок. Я тут говорю о том, что нужно бороться с постулатом из известной шутки про то, что «если бы строители строили так, как программисты программы пишут, то первый же залетевший дятел разрушил бы всю цивилизацию». Улучшать инструменты, обучать человеков пользоваться ими, искать замену технологиям, которые доказали свою принципиальную сложность и непознаваемость.
                                                                                      0
                                                                                      Так с этим-то как раз никто не спорит. И даже я, фанатичный сторонник языка С, согласился бы сменить его на что-то более удобное в работе. Бог с ним контролирующее, но хотя бы рассказывающее во время сборки о потенциальных граблях.

                                                                                      Другое дело, что на сегодня я не вижу достойных альтернатив. Как в самолете — тошнит, а выйти не получится. Впрочем, меня уже не тошнит. Тошнило от необходимости писать на ассемблере. Вот тут да. Пришедший ему на смену C казался раем земным.

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

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

                                                                                        Компилятор, который испрааляет код, это как раз таки случай C/C++, где вместо того, чтобы не дать вам скомпилировать UB, компилятор соберет то, что ему будет удобнее, иногда даже не предупредив вас об этом

                                                                                          0
                                                                                          Логика работы оптимизатора в общем-то понятна: модификация неиспользуемого значения выкидывается, проверка, которая при соблюдении стандарта, всегда даёт 0 или 1, к ним и приводится. Но если для первого случая есть предупреждение unused variable, то флага -Widontrememberthestandartbyheart к моему огромному сожалению не завезли.
                                                                                      +2
                                                                                      Я не верю в возможность написания программ без ошибок вообще. Во всяком случае живыми людьми. Не стоит недооценивать изобретательность отдельных индивидов.

                                                                                      Но вполне возможно писать программы, доказуемо следующие спецификации. Тогда все ошибки будут максимум в спеке, а это вопрос немного другого рода.

                                                                                        +1

                                                                                        Тогда может сразу из спеки бинарь генерить? :)

                                                                                          –1

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

                                                                                            0

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

                                                                                              0
                                                                                              либо язык Х позволяет написать программу не для любой спеки.

                                                                                              Да, это так, и это хорошо — не все спеки имеют смысл. Например, для утверждения (спеки) «4 — простое число» не существует программ, его доказывающих (реализующих это спеку).

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

                                                                                                  Эта неполнота по Тьюрингу не сильно мешает на практике. Причём, даже для тех задач, где программа не завершается «никогда», типа какого-нибудь сервера.


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

                                                                                  +1
                                                                                  потому что C++ — это такое же хтоническое чудовище, вид сбоку
                                                                                  тем не менее не допускать ошибки в плюсах намного легче. Если не писать на «си с классами» конечно же
                                                                                    +1

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


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

                                                                                    +1
                                                                                    Для меня странно, что в разрезе «потоковой разработки» никто не упомянул систему include/library. Она, конечно, позволяет делать всякие хитрые штуки — но даже с «примочками» вроде CMake и autoconf требует значительных усилий для поддержания CI/CD и релиз-конвейеров — что в свою очередь затрудняет автоматические тесты и анализ кода.
                                                                                +2

                                                                                Я в общем-то согласен с тезисом про границы применимости и инструменты для системщиков. Жил бы С только как кроссплатформенный ассемблер — не было бы проблем.
                                                                                Однако для меня как прикладиника основную головную боль представляет именно просачивание С туда, где не совсем хочется его видеть. И начинается всё тут с C interface для большого количества чисто прикладных библиотек. И вообще использования С как lingua franca.


                                                                                К примеру, заголовочные файлы. Почти всегда с макро-константами. Иногда с "особо альтернативными" макро-константами или вообще кусками кода, засунутыми в макросы. Вроде первичной инициализации структур. Если нужно сделать из этого богатства биндинги для чего-то, не являющегося С или С++, приходится либо искать генератор, умеющий такое парсить, или писать руками. Особенно весело для больших библиотек с заголовочными файлами на несколько тысяч строк.
                                                                                Связанная проблема — макро-константы для условной компиляции. Опять же, решение или надо тщательно искать (если вообще есть), или писать руками.
                                                                                Ещё одна связанная проблема — зоопарк целочисленных типов. Fixed-width integers появились только в C99.
                                                                                Короче говоря, я хотел бы видеть в качестве языка описания бинарных интерфейсов что-то более строго типизированное и без макросов.

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

                                                                                  WASM?

                                                                                    0

                                                                                    Он вроде немного не про то. Я не уверен, что интерфейс какой-нибудь user32.dll можно будет записать в виде WASM-файла, не создавая лишних прокладок. Если вы про инициативу WASI, она про создание и стандартизацию некоего аналога POSIX, доступного на любой не-браузерной реализации WASM.

                                                                                +1
                                                                                Ммм,
                                                                                «Dynamic languages may not catch problems at compilation time but if they have a strong type system»
                                                                                Звучит как-то странно, учитывая что динамическая типизация и строгость/слабость системы типов ортогональные характеристики.
                                                                                Думал, ошибка перевода, но и в оригинале такая же фигня.
                                                                                Был же более-менее хороший разбор habr.com/ru/post/161205

                                                                                Имхо, с С классическая проблема «бросить жалко». Так много времени и денег в его экосистему вложено, что ёжики будут плакать, колоться, но продолжать жрать кактус.
                                                                                  +9
                                                                                  Вот как раз экосистема у него кошмарнейшая. Она уже устарела на полвека. Чего стоит одна только проблема с зависимостями. Там, где в любом современном языке зависимости подтягиваются автоматически, причём сразу нужных версий, в случае C каждый городит свой велосипед. Или не городит, и тогда зависимости искать и собирать приходится вручную.
                                                                                  Система сборки — отдельный ужас. Ох как «весело» шерстить на предмет ошибок makefile размером в 250Кб, где к тому же значительная часть кода по 15 раз повторяется. Дублирование кода — это настолько явный антипаттерн, что смело позволяет считать make дерьмом. Именно поэтому поверх него практически во всех мало-мальски крупных проектах набрасывают дополнительные скрипты. В итоге чтобы уверенно собирать чужие проекты на C, вам мало знать синтаксис make-файлов. Вам ещё потребуются знания bash, Perl и Python на уровне, достаточном, чтобы разобраться в проблемах, когда сборка упадёт.
                                                                                    –2
                                                                                    (минус не мой)

                                                                                    Вы как-то узко понимаете термин «экосистема». На и под С написаны, наверное, миллионы библиотек для тысяч устройств, и, наверное, все типы возможных задач — и это всё тоже экосистема.

                                                                                    Я бы, например, был бы рад иметь бесплатный вариант github.com/coin-or/Ipopt на обычно используемом мной .net, да ещё чтобы с хорошим кодом, но это так не работает.

                                                                                    Если я правильно помню слова коллеги, у нас до сих пор используется версия, где .net обёртка над ipopt, внутри которой c, с которым сконнекчены куски фортрана, потому что изначально ipopt наполовину на фортране написан.
                                                                                      0
                                                                                      Насчет конкретно ipopt не знаю, но большинство библиотек не проблема собрать как so\dll библиотеку и использовать с любым языком который умеет загружать библиотеки. Это не требует писать ни строчки кода на С, поэтому эти библиотеки можно с тем же успехом считать частью экосистемы для остальных языков.
                                                                                      0

                                                                                      Потому от makefile и уходят, где могут, благо CMake (в разы лучше, хоть и не без своих затей) есть, и учить только его и придётся. Не вижу смысла использовать make в новых проектах совсем.


                                                                                      Ещё есть QMake и Meson, но с теми мне сталкиваться не приходилось особо.

                                                                                        +4
                                                                                        CMake еще хуже. Шаг влево-вправо — баг на баге.

                                                                                        Советую попробовать собрать FLTK для Windows, или попробовать вписать в Cmake свой тулчейн.
                                                                                          0

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

                                                                                      +1
                                                                                      «Dynamic languages may not catch problems at compilation time but if they have a strong type system»
                                                                                      Звучит как-то странно, учитывая что динамическая типизация и строгость/слабость системы типов ортогональные характеристики.
                                                                                      Думал, ошибка перевода, но и в оригинале такая же фигня.
                                                                                      Был же более-менее хороший разбор habr.com/ru/post/161205
                                                                                      Зависит от терминологии. В определениях приведённой статьи — да, в определениях из, например, TAPL(книга), скорее нет, т.к. типы там определяются как статически гарантируемые свойства программы, а динамическая типизация — оксюморон.
                                                                                      +4
                                                                                      Уже 3000 раз говорилось что TIOBE показывает только хайповость языка. Как часто делали запросы с ним. Проплатите какой то говорящей голове на крупном медиа и рейтинг поползет вверх. Так что ни о чем серьезном рассуждать нельзя опираясь на их данные, а уж темболее о замене С.
                                                                                      Косвенно и ± километр из TIOBE можно прикинуть сколько людей пытается изучать тот или иной язык(программистами они вообще никогда могут не стать, но на статистику повляют) и насколько язык удобен в использовании.
                                                                                      Гуглил недавно как в Java добить строку нулями слева до фикс длинны. Я искал что то вроде String.leftPad, но не нашел сам. Через гугл я конечно выяснил что это делается через String.format. Но я увидел и большое количество людей которые делают это руками сами в разных вариациях, вплоть до цикла со сложением строк через "+". Очевидно что вот в этом месте проблема. И я поднял рейтинг языку, просто на пустом месте. Вы скажете — «Ты субьективен! Проблема только у тебя и вообще ты никто.». А вот нифига, во всех библиотеках она примерно так и называется как я и ожидал. Значит люди ждут именно это, а не String.format который пришлось гуглить.
                                                                                        +1
                                                                                        И я поднял рейтинг языку, просто на пустом месте.

                                                                                        Нет, не подняли. Тиобе так не работает. А работает вот так.

                                                                                          0
                                                                                          Теоретически, если он запрос вбивал как
                                                                                          Java programming how pad string with zeros
                                                                                          то повлиял))
                                                                                          Конечно маловероятно, потому что запрос смотрится по дурацки
                                                                                            0

                                                                                            Не запрос.


                                                                                            Tiobe ищет страницы на которых есть текст "java programming". Вот, если бы на форуме спросил, то да, поднял бы рейтинг джавы.

                                                                                        +11
                                                                                        У языка C есть два самых больных места:
                                                                                        — Разыменование невалидных указателей
                                                                                        — Отвратительная реализация строк с возможностью выхода за их границы

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

                                                                                        Любой язык, который сможет решить две этих проблемы без потери преимуществ C потенциально является его «убийцей».
                                                                                          0
                                                                                          Именно так.

                                                                                          Работа со строками, а равно форматная строка printf/scanf — это любимая мозоль любого, активно пишущего на языке C.

                                                                                          Языки типа С++ пытаются побороть строки и абстракции драйверного слоя (что сильно важнее). У Apple даже получилось переписать BSD'шное ядро на плюсах. Microsoft уже довольно давно использует плюсовый код в ядерной части своей ОС. Может быть в этом и есть что-то. Но массового перехода нет. Или «мир еще не дозрел», или… Преимущества ощутимы при «корпоративной» разработке, но плохо работаю с открытыми проектами? Не знаю. Для меня пока факт — используется, но не очень активно.

                                                                                          И да, сам язык не имеет ничего против разыменовывания ЛЮБЫХ указателей. Вообще. Он абсолютно бесприкословно выполнит то, то его попросят.

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

                                                                                          Языки типа Rust борются с ними выстраивая эшелонированную оборону над ресурсами. Т.е. пытаются сделать то, на что разработчики чипов пожалели транзисторов и тактов. Их право. В определенных случаяю, возможно, и стоит сильно пожертвовать скоростью ради безопасности. Но победа Rust над C на низком уровне как раз и будет грозить резким падением производительности на прикладном. Стоит ли оно того? Ну время покажет. Rust активно растет. Правда пока все больше на прикладном уровне, пытаясь конкурировать не столько с С, сколько с С++. Потому ждем.

                                                                                          Так что «недостатки языка» — это кому как. Если скальпель для хирурга очень острый, то возможно не стоит начинать оперировать. Возможно для всех будет лучше, если такой хирург возьмет не такой острый топор и пойдет дрова рубить. А «уязвимости»… Ну, кто сам без греха пусть первым бросит камень. В конце-концов в мире WEB-программирования (где языка С нет чуть больше чем совсем) они весьма и весьма не редки.
                                                                                            +5
                                                                                            Но победа Rust над C на низком уровне как раз и будет грозить резким падением производительности на прикладном.

                                                                                            Почему?

                                                                                              –2
                                                                                              Патомушто!

                                                                                              Дык это — такты конечны. Аппаратных блоков контроля указателей и работы со строками нет. Значит контроль программный. Значит такты. При каждом (ужас) обращении к строке или указателю (массиву). Перед одной-двумя ассемблерными инструкциями для изменения байта в массиве, десяток-другой инструкций допустимости подобной операции. А что есть аргументированные возражения? Я бы послушал…