Будущее g++

Мешает то, что завернут, патчи то пожалуйста, но это все равно в основную ветку не войдет.

Никак. Тезис был в том что

Им и сейчас ничего не мешает писать свои модули на любимых язычках

Разработчики ядра со своим нестабильным API мешают.

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

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

Можно и обратную совместимость не ломать. Ломать придётся только систему сборки. Например можно добавить ключевое слово import и писать вроде import stdio, stdlib;. При компиляции как в паскале сохранять объявления в бинарный файл объявлений который будет читаться при импорте. Можно даже совместимость с #define сделать. К сожалению комитет стандартизации C/C++ почему то не хочет менять систему сборки.

Ну это и так понятно, но на С модули все равно пишут...

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

Я имею ввиду что обратная совместимость исходных текстов полностью сохраняется. Меняется только система сборки.

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

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

Имхо еще один С++ не нужен. Уж лучше кактус.

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

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

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

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

В С есть модули, просто никто не использует.

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

https://clang.llvm.org/docs/Modules.html#objective-c-import-declaration

Язык Objective-C является надмножеством языка Си, поэтому Си-код полностью понятен компилятору Objective-C.

https://ru.wikipedia.org/wiki/Objective-C

Так что нельзя сказать что комитеты не хотят, хотят, но не могут.

У них какие то странные ограничения на механизм сборки, они не хотят, чтобы модули искались по имени файла и генерировались дополнительные файлы. Давно пора выкинуть систему сборки C/C++, самую кривую систему сборки из известных. Заодно выкинуть кривой и устаревший autotools. Cmake, Meson, Scons и прочие системы сборки можно будет адаптировать под использование модулей.

Это не решит проблемы, поможет только Hello World'ам, но для них можно посмотреть examples от meson.

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

Ну тут можно сказать только одно, те вещи которые вы называете слабыми сторонами С они и сильные стороны С

Это только самые вопиющие, которые оказывают прямое влияние на стабильность и безопасность. Есть еще такие замечательные вещи, как высокая сложность парсинга кода Си, которая вызвана фундаментально кривой реализацией макросов и существованием типов с пробелами в именах, хотя весь язык построен на отсутствии пробелов: short int, unsigned long int — и при этом там уже в самых первых компиляторах был полный бардак с размером этих типов.

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

Да, паскаль дает все возможности Си, но не нужно забывать, что на паскале такой код будет выглядеть как минимум странно. Потому что на паскале в принципе нет аналога какого-нибудь «int *». И также в паскале есть опциональная проверка границ массивов во время выполнения, чего в принципе нельзя сделать в Си. потому что там (почти) нет границ массивов. В Си некорректный код пишется легко и непринужденна, а неординарные усилия нужно прикладывать для того, чтобы написать корректный код.

Если выделять сырую память аллокатором, то получится такая же картина скорее всего как и в С

Да, GetMem и malloc очень похожи, но ровно после их вызова сходство заканчивается — в паскале обычно результат сразу оборачивается в безопасную переменную. Часто это динамический массив, который держит в себе размер памяти.

Предъявы к С задним числом с позиции нынешних реалий конечно же не совсем правильны, язык неплохой, но очень ручнозакатывательный

Давай начнем с того, что Algol W, который на 90% паскаль, имел спецификацию уже в 1968 году, когда не было не то что C — даже B еще не было, был только BCPL. Разницу можно было увидеть в сроках релиза: C релизнут в 1972, паскаль релизнут где-то в 1975. То есть, грамотно спроектированный язык отстал — это и есть преимущество методики херак-херак, которая использует готовые решения даже там, где они совсем не подходят.

Кстати что такое аномальные операция с числами? Это про какой-то вид переполнения? Если да, это тоже есть в паскале

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

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

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

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

Ее позвезли в Modula со спецификацией в 1976. Позже эти фичи перенесли в компиляторы паскалей, а до этого, да, были такие же инклуды, как в Си: {$I filename} — они до сих пор сохранились, к слову.

Опять же ругается препроцессор как костыль, а какие были варианты у альтернатив в 70e? Препроцессор хоть и не знает ни черта ни о синтаксисе, ни о семантике, но тем не менее здорово бустит язык по возможностям и в мету(кодоген) и в любые другие подстановки, что предлагал паскаль в те годы?

Во-первых, давай начнем с того, что на самом деле макросы весьма ограничены — они не предоставляют возможностей конкретизации функций, вроде условий по типу данных или их размеру (sizeof). При этом все прелести работы с универсальным типом по сравнению с кучей перегруженных функций с лихвой компенсируются трудностью. поиска ошибки в коде с такими макросами. По этой причине многие задачи макросов в паскале были взяты на себя простыми функциями, в том числе вложенными — последних тупо не было в Си. Макрос нельзя было передать как параметр куда-то, при этом вложенные функции - можно было, потому в паскале тех лет уже были замыкания  — в каком году они появились в С++? В 2015?

Модульность в паскале была изначально включая UCSD Pascal

Справедливости ради, модульности в UCSD изначально не было.

Почему не могли написать на паскале? Потому же, почему они используют питон — проще найти массовых индусов с рынка

Точно, ядра и системные сервисы же индусы пишут

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

Раскрою тайну непопулярности паскаля, не всем он нравится, и не лучше он чем С/C++, вот так просто, ну а ты его фанат

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

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

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

Так ОС разные, и места разные. И бинарники могут быть собранными по разному. Если бы библиотеки были просты и лежали в одном месте то проблем бы и у С/C++ не было. #pragma lib и вперед

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

Это потому что их не используют %) В С/C++ таких проблем из за самого языка тоже нету

Есть как минимум проблема со strict aliasing.

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

С такой логикой можно считать, что в Си есть классы, потому что Cfront — это рисширение Си.

Так что нельзя сказать что комитеты не хотят, хотят, но не могут

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

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

Если бы в 1968 комитет принял паскаль (проект «Algol W»), который поддерживали такие немногочисленные и мелкие фигуры, как сам Вирт и Хоар, то вопроса о создании языка Си, скорее всего, просто бы не возникло. Но комитет не принял паскаль, а принял другой язык под именем Алгол-68, и в итоге кучу лет Вирт малыми силами дорабатывал язык и писал реализацию.

Макрос нельзя было передать как параметр куда-то

Макрос можно передать как параметр в другой макрос.

Это только самые вопиющие,

простота использования за повышенное внимание.

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

следствие отсутствия внимания.

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

А зачем вам его парсить? Как парсинг языка сказывается на его типовом использовании?

short int, unsigned long int — и при этом там уже в самых первых компиляторах был полный бардак с размером этих типов.

Решение которое не нравится вам, предпочли бы вне зависимости от архитектуры постоянный размер?

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

Собственно как и наоборот.

Потому что на паскале в принципе нет аналога какого-нибудь «int *»

Разверните мысль, так как ^integer вроде как существует.

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

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

Да, GetMem и malloc очень похожи, но ровно после их вызова сходство заканчивается — в паскале обычно результат сразу оборачивается в безопасную переменную. Часто это динамический массив, который держит в себе размер памяти.

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

Давай начнем с того, что Algol W, который на 90% паскаль, имел спецификацию уже в 1968 году, когда не было не то что C — даже B еще не было, был только BCPL. Разницу можно было увидеть в сроках релиза: C релизнут в 1972,

Официальный коридор реализации датируют 1969-1973гг для С. С таким же успехом тот же Ричи в своих интервью и публикациях никогда не отрицал того факта что они брали из других языков все показавшиеся им удачными решения, можно сказать что С на какой-то процент Algol W, это странная постановка доказательства.

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

Тут как обычно спорно, уже было сказано выше, что то что делается просто в С делается сложно в паскале и наоборот. Разные векторы удобства.

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

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

Например, предлагаю вспомнить, что тип char — это и число, и символ. Паскаль делает явное разграничение, не давая работать с числом как с символом и с символом как с числом.

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

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

Можно еще политоту пообсуждать.

Ее позвезли в Modula со спецификацией в 1976. Позже эти фичи перенесли в компиляторы паскалей, а до этого, да, были такие же инклуды, как в Си: {$I filename} — они до сих пор сохранились, к слову.

Это мы уже обсудили, да вторая половина 70х, но прошлого уже не вернуть.

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

вы просто пересказали другими словами то, на что отвечаете, какой смысл в этом?

По этой причине многие задачи макросов в паскале были взяты на себя простыми функциями, в том числе вложенными — последних тупо не было в Си. Макрос нельзя было передать как параметр куда-то, при этом вложенные функции - можно было, потому в паскале тех лет уже были замыкания — в каком году они появились в С++? В 2015?

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

Макрос можно передать как параметр в другой макрос

Да, это односторонняя сочетаемость.

простота использования за повышенное внимание

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

которые оказывают прямое влияние на стабильность и безопасность

следствие отсутствия внимания

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

А зачем вам его парсить? Как парсинг языка сказывается на его типовом использовании?

Здрасти, а полтреда у нас о чем была? Парсинг языка инструментами — это абсолютно обязательное действие для программ сложнее hello world.

Решение которое не нравится вам, предпочли бы вне зависимости от архитектуры постоянный размер?

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

Потому что на паскале в принципе нет аналога какого-нибудь «int *»

Разверните мысль, так как ^integer вроде как существует

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

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

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

А что разворачивать? Можно включить проверку границ строк, границ массивов, в том числе динамических. Ничего этого нету В Си в принципе.

Да, GetMem и malloc очень похожи, но ровно после их вызова сходство заканчивается — в паскале обычно результат сразу оборачивается в безопасную переменную. Часто это динамический массив, который держит в себе размер памяти.

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

И как ты помешаешь мне сделать array[invalid_index]? В принципе, можно заставлять пользователя весь доступ делать через функции get/set. Но когда ты потом посмотришь на такую программу на Си, а потом на аналог на паскале, то однозначно скажешь, что такой Си не нужен.

можно сказать что С на какой-то процент Algol W

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

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

есть и в паскале расширяющее про неявное приведение, проверки за выход насколько я помню там нет

В паскале проверка границ чисел была с самого начала.

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

Тут как обычно спорно, уже было сказано выше, что то что делается просто в С делается сложно в паскале и наоборот

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

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

Не знаешь, потому что твою программу скомпилируют на машине с «char» длиной 9 байт.

Например, предлагаю вспомнить, что тип char — это и число, и символ. Паскаль делает явное разграничение, не давая работать с числом как с символом и с символом как с числом

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

Претензия не принимается, паскалевы безопасные строки работают в том числе с нулевыми накладными расходами, и даже быстрее сишных строк на таких штуках, как конкатенция строк. То есть, Си оказывается медленный и опасный, его ущербность не оправдана никакой оптимизированностью под быстрое выполнение. Эту проблему пришлось решать, реализуя некорректные и опасные оптимизации в компиляторах (volatile, strict aliasing) — будто язык был недостаточно опасен без них.

Опять же ругается препроцессор как костыль, а какие были варианты у альтернатив в 70e? Препроцессор хоть и не знает ни черта ни о синтаксисе, ни о семантике, но тем не менее здорово бустит язык по возможностям и в мету(кодоген) и в любые другие подстановки, что предлагал паскаль в те годы?

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

вы просто пересказали другими словами то, на что отвечаете, какой смысл в этом?

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

Все это до сих пор спорные механизмы которые в принципе заменяются колбеками и шаблонами проектирования

Да, и потому макросы в Си бесполезны.

А что разворачивать? Можно включить проверку границ строк, границ массивов, в том числе динамических. Ничего этого нету В Си в принципе.

AddressSanitizer, UndefinedBehaviorSanitizer

AddressSanitizer

On average, the instrumentation increases processing time by about 73% and memory usage by 240%

Отличные истории.

UndefinedBehaviorSanitizer

Вот это уже ближе. Правда, неоднозначность сишной программы ограничивает возможности проверки и делает проверку более поздней «время выполнения вместо времени компиляции). Да, здесь можно спорить о том, что программу на паскале со всеми явными объявлениями превращений писать дольше, чем на Си.

Разверните мысль, так как ^integer вроде как существует

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

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

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

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

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

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

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

Эту проблему пришлось решать, реализуя некорректные и опасные оптимизации в компиляторах (volatile, strict aliasing) — будто язык был недостаточно опасен без них.

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

Не знаешь, потому что твою программу скомпилируют на машине с «char» длиной 9 байт.

Выдуманный довод с char в 9 байт. С таким же успехом тогда может существовать реализация паскаля и железа где размерности не соответствуют ожиданиям.

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

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

В паскале проверка границ чисел была с самого начала.

Не знаю о какой проверке вы говорите, но переполнение так прекрасно работает, также как и везде.

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

Конечно можно, и конечно заимствовали. Все у друг друга заимствуют идеи. Реализация не имеет особой роли, если вы под заимствованием подразумеваете ее.

И как ты помешаешь мне сделать array[invalid_index]? В принципе, можно заставлять пользователя весь доступ делать через функции get/set. Но когда ты потом посмотришь на такую программу на Си, а потом на аналог на паскале, то однозначно скажешь, что такой Си не нужен.

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

А что разворачивать? Можно включить проверку границ строк, границ массивов, в том числе динамических. Ничего этого нету В Си в принципе.

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

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

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

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

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

Здрасти, а полтреда у нас о чем была? Парсинг языка инструментами — это абсолютно обязательное действие для программ сложнее hello world.

Ну возможно у вас пол треда об этом было, но парсинг языка это узконаправленная задача, делать какие-то выводы о языке и его применимости на основе этого тоже довольно странная вещь. Это попытка отрицать что есть куча сложного большого по на С где никто не парсит С, о каких hello world речь?

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

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

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

Хотя для своего софта можно и паскалем пользоваться, инструментарий для него не такой богатый как для С и С++, но тут и сам язык помогает.

Не знаю о какой проверке вы говорите, но переполнение так прекрасно работает, также как и везде.

В паскале есть ключи: -Co : для проверки переполнения, и -Cr для проверки границ массива, и всякие другие проверки.(там можно и прагмами в коде включать, но я не помню их). Вообще со всеми проверочными ключами паскаль почти так же хорошо проверяет как и Sanitizers, только аналога ThreadSanitizer нет, насколько мне известно.

https://pascal.godbolt.org/z/Mnzx48

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

Это давным-давно сформулировано короче и точнее: Си — это переносимый ассемблер.

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

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

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

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

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

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

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

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

В этом то и дело, что паскаль не мог предложить такого же механизма

Как принц Чарльз не мог предложить отведать свежегнилой тыквы из мусорного бака.

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

Паскаль опередил даже C++ лет на сорок (2015-1975). В кресты напихали гору мусорных фич. а действительно важные и полезные, которое позволяют писать сложный код коротко и чисто, только сейчас пытаются вводить. Это я про лямбды и модули.

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

Еще раз повторяю, что не было никакого «намеренно», у разрабов не было никакого плана, не было никакой архитектуры, они просто тащили готовые решения отовсюду и кое-как их компоновали. Прежде всего давай вспомним, зачем вообще нужен был новый язык? До самой середины 80-х системный софт часто писали на чистом асме. K&R хотели делать быстрее херак-херак, чтобы можно было минимальными усилиями, не парясь, не оптимизируя, не используя возможности железа запускать одну системную софтину на разных машинах. Я специально подчеркиваю здесь, что ранний Си — это ни разу не быстро. Это был весьма медленный язык, на уровне старых кобола-фортрана. И это не просто проблема примитивности компиляторов — язык принципиально тяжело оптимизировать из-за отсутствия архитектуры. Из-за этого неизбежно нужны были асмовые вставки, а на Си уже писался достаточно высокоуровневый код. Внезапно. А нынче этот сценарий повторил питон, и мухи безошибочно сделали выбор.

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

Если ты вспомнишь, что конкатенция — это в том числе printf/snprintf/etc, то выяснится, что эдак 90% всех операций изменения строк — это формы конкатенции. А если еще ты вспомнишь, что для произвольного чтения строки нужно знать ее границу, то выяснится, что тебе неизбежно нужно знать размер строки и при чтении. Потому нуль-терминированность ни разу не естественна, а возникла она искуственно, как результат случайным образом сложившейся практики злоупотребления директивой ASCIZ, существовавшей во вполне конкретном асме для PDP-10/11, на которых говнокодили K&R. Вот тебе пруф, асм 1973 год для MCS 8, нет никаких нуль-терминированных строк:

http://www.bitsavers.org/components/intel/MCS8/MCS_8_Assembly_Language_Progra...

И одна из первых вещей. которую сделали при создании C++ — это заменили нуль-терминированные строки нормальными.

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

Эту проблему пришлось решать, реализуя некорректные и опасные оптимизации в компиляторах (volatile, strict aliasing) — будто язык был недостаточно опасен без них.

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

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

Выдуманный довод с char в 9 байт. С таким же успехом тогда может существовать реализация паскаля и железа где размерности не соответствуют ожиданиям

И они прекрасно работали. Напоминаю, что UCSD Pascal (1977) и Mesa (1976) — это языки, из которых произошла Java.

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

Пока что я не вижу рациональных причин, с которыми бы я согласился. Надеюсь, что после этого сообщения у тебя их тоже не останется. Си принят по той же причине, почему приняты Python и Jira: сложнее и глюкавее, но «больше фич», то есть, больше галочек в таблице «поддерживаемые функции» — и не важно, что те же задачи можно решить меньшим числом функций проще и дешевле — сложность лучше продается. И ты сейчас демонстрируешь попадание в ту же ловушку. Во-первых, потому что наличие макросов тебе всё еще кажется потенциальным достоинством вместо ничем не оправданной фичесложности. А во-вторых:

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

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

В паскале проверка границ чисел была с самого начала.

Не знаю о какой проверке вы говорите, но переполнение так прекрасно работает, также как и везде

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

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

Конечно можно, и конечно заимствовали. Все у друг друга заимствуют идеи. Реализация не имеет особой роли, если вы под заимствованием подразумеваете ее

Я тебе просто пишу о том, что Си был говном еще до своего релиза, поскольку были паскаль и PL/M — последний хоть и уступал паскалю, но все равно был намного грамотнее спроектирован, чем Си, в плане синтаксиса и структур данных. Напомню, что именно на PL/M написана CP/M, которая MS-DOS.

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

Как? Как будут называться твои функции и что они будут делать? За миром во всём мире — это к гуманитариям, а у нас тут одни технари сидят.

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

Я бы полностью согласился, если бы в Си не существовало типов данных. Типы данных нужны для проверки корректности работы с данными на этапе компиляции... но не нужны, как оказывается. А всё дело в том, что в BCPL/B не было никаких типов данных — именно на этом фундаменте и построен Си, в Си типы данных — это просто досадная нелепость. В оригинальном Си от K&R ведь даже не было объявлений аргументов функций — были только указатели на адрес начала кода, как в асме.

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

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

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

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

Это логично, аппаратные платформы шагнули на пол века вперед, и для того чтобы писать сейчас на С нужно либо писать на С++ который лучший С хоть и костыль, или хотя бы на С в его gnu реализации и на наработках из последних стандартов которые предлагают какие-то альтернативы и улучшения

И, тем не менее, в книге K&R за 1978 год уже есть 32-битные int/long/float, и 64-битные double. Сильно с тех пор платформы поменялись?

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

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

Это давным-давно сформулировано короче и точнее: Си — это переносимый ассемблер

Да, такие же отмазы лепит Гвидо, вроде «объекты питона и операторы — это язык для описания программы, а не вспомогательные структуры в ней». А то, что алгол-60, алгол-68, PL/M, и паскаль все в какой-то степени исполняли функцию переносимых асемблеров — это никого не волнует. «Переносимый ассемблер» — это оправдание для любого рода трэша:
-- Почему у вас такой неюзабельный Brainfuck?
-- Дык это же переносимый ассемблер. Просто количество инструкций ограничено, так даже переносимее, а там гляди будут RRRISC архитектуры суперсверхскалярных процессоров, и язык Brainfuck станет топовым языком.

И, тем не менее, в книге K&R за 1978 год уже есть 32-битные int/long/float, и 64-битные double. Сильно с тех пор платформы поменялись?

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

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

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

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

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

Я бы полностью согласился, если бы в Си не существовало типов данных. Типы данных нужны для проверки корректности работы с данными на этапе компиляции… но не нужны, как оказывается. А всё дело в том, что в BCPL/B не было никаких типов данных — именно на этом фундаменте и построен Си, в Си типы данных — это просто досадная нелепость. В оригинальном Си от K&R ведь даже не было объявлений аргументов функций — были только указатели на адрес начала кода, как в асме.

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

Как? Как будут называться твои функции и что они будут делать? За миром во всём мире — это к гуманитариям, а у нас тут одни технари сидят.

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

Я тебе просто пишу о том, что Си был говном еще до своего релиза, поскольку были паскаль и PL/M — последний хоть и уступал паскалю, но все равно был намного грамотнее спроектирован, чем Си, в плане синтаксиса и структур данных. Напомню, что именно на PL/M написана CP/M, которая MS-DOS.

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

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

В компилтайме и С умеет предупреждения валить, какие проблемы?

<source>:3:18: warning: integer constant is too large for its type

    3 |     short test = 9999999999999999999999999;

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

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

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

Пока что я не вижу рациональных причин, с которыми бы я согласился. Надеюсь, что после этого сообщения у тебя их тоже не останется. Си принят по той же причине, почему приняты Python и Jira: сложнее и глюкавее, но «больше фич», то есть, больше галочек в таблице «поддерживаемые функции» — и не важно, что те же задачи можно решить меньшим числом функций проще и дешевле — сложность лучше продается. И ты сейчас демонстрируешь попадание в ту же ловушку. Во-первых, потому что наличие макросов тебе всё еще кажется потенциальным достоинством вместо ничем не оправданной фичесложности. А во-вторых:

А я не вижу причин хейтить С и его экосистему, она мало того что ничем не уступает по сути, так еще и исторический победитель. А так же предлагаю подумать если все было так хорошо с pascal и он даже скажем начинал использоваться крупными игроками рынка в виде MC и Эпл, да и борланд не малый игрок, так по какой причине мы вновь и вновь возвращаемся к С и С наследию, инертность скажите вы, возможно… А возможно оно не так уж и плохо.

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

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

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

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

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

На C++ — можно, на Си — нет, потому что «безопасные типы и подходы» — это неизбежно указатели, а как они могут быть безопасны? Это в паскале были динамически выделяемые контейнеры, близкие к примитивным объектам-контейнерам C++ — вот это безопасные типы. А в Си ты написал «=» вместо «==» или скобку возле плюса не поставил — и всё, ты по уши в дерьме со своим законным неопределенным поведением.

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

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

нынешний паскаль и с++ имеют намного больше общего чем отличий в плане того как они относятся к попыткам сделать написательство кода безопасным и удобным

Кобол, фортран, лисп?

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

Хорошо, тогда задаю вопрос прямо: ты когда-то писал хотя бы проект среднего размера, 10-100 тыс строк?

дизайн С его создатели посчитали что так им будет удобно, и оказалось что они не промахнулись хоть и всем известной ценой

Ну правильные же мысли пишешь, я от том же пишу. Создатели Си, действительно, посчитали, что им будет удобнее сделать херак-херак компилятор, поскольку писать большие куски кода без структур — это боль, а на реализацию нормальной архитектуры компилятора нужно время. Они «не промахнулись» в том, что релизнули свои поделия в исходных кодах, а дареному коню в зубы не смотрят. Даже такие куски дерьма, как PHP, Python, MySQL, MongoDB, Docker, Jira будут популярными — просто потому, что они бесплатны и в исходных кодах. Имея это в виду, можно понять, что вообще не важно было, как бы K&R написали свой язык, пока самый прямой конкурент, PL/M, имеет коммерческий компилятор.

bounded array из boost посмотрите как чтобы приблизительно представить как это выглядит на С

Это не Си.

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

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

В компилтайме и С умеет предупреждения валить, какие проблемы?
<source>:3:18: warning: integer constant is too large for its type
3 | short test = 9999999999999999999999999;

Молодец, а теперь сделай то же самое для типа с верхней границей 2^14.

А я не вижу причин хейтить С и его экосистему, она мало того что ничем не уступает по сути, так еще и исторический победитель. А так же предлагаю подумать если все было так хорошо с pascal и он даже скажем начинал использоваться крупными игроками рынка в виде MC и Эпл, да и борланд не малый игрок, так по какой причине мы вновь и вновь возвращаемся к С и С наследию, инертность скажите вы, возможно… А возможно оно не так уж и плохо

Я могу привести пример проще и понятнее, который можно описать вполне конкретной одной цифрой. А именно, процентом отказов в год. Я пишу про жесткие диски. Компания Seagate производила худшие по надежности диски, при этом оказалась лидером рынка. «Возможно, оно не так уж и плохо» — только для кого? Для потребителя, который через 5 лет пользования узнает, что его жесткий диск сдох?

Model Family:     Hitachi Deskstar 7K1000.C
Device Model:     Hitachi HDS721025CLA382
  1 Raw_Read_Error_Rate       0
  2 Throughput_Performance    92
  3 Spin_Up_Time              195 (Average 195)
  4 Start_Stop_Count          961
  5 Reallocated_Sector_Ct     0
  7 Seek_Error_Rate           0
  8 Seek_Time_Performance     33
  9 Power_On_Hours            66134
 10 Spin_Retry_Count          0
 12 Power_Cycle_Count         561
192 Power-Off_Retract_Count   1256
193 Load_Cycle_Count          1256
194 Temperature_Celsius       37 (Min/Max 7/48)
196 Reallocated_Event_Count   0
197 Current_Pending_Sector    0
198 Offline_Uncorrectable     0
199 UDMA_CRC_Error_Count      00

А Hitachi, тем временем, сдохло и было выкуплено WD. Вот такая вот она, рука рыночка: говно оказывается коммерчески успешным, а годнота — в убытках. Си еще долго будет коммерчески успешным, потому что еще долго нужно будет поддерживать и латать глюкавый сишный софт. Примерно та же ситуация с PHP. Я спустя много лет понял однажды сказанную руководителем солидной индусоконторы фразу «надо было делать так, чтобы работа всегда оставалась» — вот он, рецепт успеха кодера. Зачем писать программу на паскале, которая просто работает?

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

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

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

Насколько я понял кроме разницы в технических деталях лицензия gcc требует линковки с открытыми библиотеками (открытый исходный код), а лицензия clang позволяет линковать в любом разрезе с чем угодно … поэтому clang юзается в проприетарных проэктах типа яндекса и т.д … в общем gcc копирастам не подходит …)))

Я тут специально посмотрел сколько был character в alto mesa, он был «стандартные» для того времени 8 бит.

написал «=» вместо «==» или скобку возле плюса не поставил

скобку возле плюса пример о чем вы был бы неплох, = и == отлавливается в компилтайме, так же как и баунды и лимиты на типы не могу сказать что это делается на любой тип так как не проверял, но скорее всего на базовые работает. Естественно это все работает на текущих версиях компилятора С, старые рыть где-то не с руки, да и там скорее всего этого ничего нет. Вообще у меня возникает закономерный вопрос к вам, я уже который раз нахожу подтверждение того, что ваши претензии к языку несостоятельны прямо по вашим же и приведенным примерам, зачем вы их тогда вообще приводите даже если не проверяете свои слова? Я ваши слова, о том, что якобы паскаль полувековой давности что-то умел, на деле тоже проверить не могу как и вы, да остались какие-то старые исходные тексты паскаля, остались какие-то мануалы по старым языкам, но вы же прекрасно понимаете что ни вы не я запустить и проверить ничего из этого не будем, так же как и читать тот исходный код. И тех аппаратных платформ на которых это все исполнялось тоже ни у вас ни у меня нет.

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

bounded array из boost посмотрите как чтобы приблизительно представить как это выглядит на С

Это не Си.

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

Опять же, давайте заглянем в тот bounded array из boost, а видим мы там следующее, внутренне представление это обычный массив С.

    private:
        size_type size_;
        BOOST_UBLAS_BOUNDED_ARRAY_ALIGN value_type data_ [N];

Вот уж не C так не С. Это даже не умный указатель (которые тоже нашлепка на С указатели), а тип данных как и описано в его описании располагается на стеке.

Да тип запудрен С++, так же там для индексирования используются итераторы и функции которые принимают итераторы. К слову сказать никогда особо не интересовался как работают итераторы в С++, но учитывая что все функции в stl где на вход можно передать итератор запросто принимают указатель как начало и указатель + смещение как конец, что-то я подозреваю что итератор пудра над адресной арифметикой С. Опять же это так же можно пронаблюдать на реализации этого bounded array, такое использование там везде и повсюду.

        BOOST_UBLAS_INLINE
        array_adaptor (size_type size, const value_type &init):
            size_ (size), own_ (true), data_ (new value_type [size]) {
            std::fill (data_, data_ + size_, init);
        }

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

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

Молодец, а теперь сделай то же самое для типа с верхней границей 2^14.

Опять какой-то нестандартный тип который вы выдумали чтобы оправдать свои слова как и с char в 9 байт. Вы же понимаете что вы хотите странного в рамках реализации С?

Я тут специально посмотрел сколько был character в alto mesa, он был «стандартные» для того времени 8 бит

https://en.wikipedia.org/wiki/36-bit_computing

написал «=» вместо «==» или скобку возле плюса не поставил

скобку возле плюса пример о чем вы был бы неплох, = и == отлавливается в компилтайме

«getdata(cell+2)» вместо «getdata(cell)+2» — и привет, ты даже в рантайме скорее всего не получишь ошибку сразу.

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

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

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

Открываешь самый первый пример асма для PDP-10, и видишь объявление константы в первой же строке:

http://pdp10.nocrew.org/docs/instruction-set/Program.html

Что ты еще выдумываешь? Константы нужны не для того, чтобы хранить данные в read-only блоке и читать их оттуда неизменными — они нужны для того, чтобы транслировать эти числа в цельные команды, вроде «mov 1, 100» — записать число «100» в ячейку с адресом «1». Даже асм это мог, но Си — не мог, потому в каком-то смысле Си был шагом назад по сравнению с асмом.

bounded array из boost посмотрите как чтобы приблизительно представить как это выглядит на С

Это не Си.

Увы или нет, это С, просто в его прямом продолжении, но от этого он С меньше не становится

С таким же успехом я могу говорить, что Python — это и есть Си, «просто в его прямом продолжении; все тоже самое можно и на С без питона переписать; там те же Си структуры под капотом». Можно, но это будет совсем не то, совсем не того уровня надежности, читаемости, и поддерживаемости.

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

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

Молодец, а теперь сделай то же самое для типа с верхней границей 2^14

Опять какой-то нестандартный тип который вы выдумали чтобы оправдать свои слова как и с char в 9 байт. Вы же понимаете что вы хотите странного в рамках реализации С?

Хорошо, если тебе не нравится так — покажи мне проверку long на попадание в рамки 2^32 на любой платформе, в том числе той, где long 64 бита.

Я тут специально посмотрел сколько был character в alto mesa, он был «стандартные» для того времени 8 бит

https://en.wikipedia.org/wiki/36-bit_computing

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

«getdata(cell+2)» вместо «getdata(cell)+2» — и привет, ты даже в рантайме скорее всего не получишь ошибку сразу.

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

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

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

Открываешь самый первый пример асма для PDP-10, и видишь объявление константы в первой же строке:

http://pdp10.nocrew.org/docs/instruction-set/Program.html

Что ты еще выдумываешь? Константы нужны не для того, чтобы хранить данные в read-only блоке и читать их оттуда неизменными — они нужны для того, чтобы транслировать эти числа в цельные команды, вроде «mov 1, 100» — записать число «100» в ячейку с адресом «1». Даже асм это мог, но Си — не мог, потому в каком-то смысле Си был шагом назад по сравнению с асмом.

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

С таким же успехом я могу говорить

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

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

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

Молодец, а теперь сделай то же самое для типа с верхней границей 2^14

Опять какой-то нестандартный тип который вы выдумали чтобы оправдать свои слова как и с char в 9 байт. Вы же понимаете что вы хотите странного в рамках реализации С?

Хорошо, если тебе не нравится так — покажи мне проверку long на попадание в рамки 2^32 на любой платформе, в том числе той, где long 64 бита.

Очевидно, что вы просто тратите мое время, сходите на godbolt.org да сами проверьте на тех вариантах платформ и ос что там предоставлены (я проверил на 5 случайных с разной ос и разной разрядностью, везде вы получаете ворнинг), на любой требовать вы не можете, потому что на любой и ваш паскаль не работает. Т.е. по сути эту претензию тоже отбили.

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

в принципе? )

https://github.com/antirez/sds - динамические строки с проверкой границ массива. никто не мешает реализовать и свое что-нибудь эдакое. код прост как прикроватная тумбочка. чистый С.

на С делается абсолютно любой инструмент, под задачу.

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

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

Если посмотреть на бустовый bounded array видно, что и статические можно, просто это будет неудобная ерунда которая никому не нужна, а так и в паскале все эти строки пляска вокруг выделения памяти getmem’ом, и работой с указателем, + рекорд + в какой-то из реализаций счетчик ссылок всобачили. Ой ли не С, ой ли строки с терминатором не похожи на просто куски памяти из под getmem.

Тут вообще непонятно с чем спорит человек, если снизу все выглядит одинаково +/-, меняется только синтаксис.