Исправление abcq, (текущая версия) :
Это только самые вопиющие,
простота использования за повышенное внимание.
которые оказывают прямое влияние на стабильность и безопасность.
следствие отсутствия внимания.
Есть еще такие замечательные вещи, как высокая сложность парсинга кода Си, которая вызвана фундаментально кривой реализацией макросов и существованием типов с пробелами в именах, хотя весь язык построен на отсутствии пробелов:
А зачем вам его парсить? Как парсинг языка сказывается на его типовом использовании?
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?
Все это до сих пор спорные механизмы которые в принципе заменяются колбеками и шаблонами проектирования. Скажем так, были альтернативы, почему вы считаете что альтернативы приведенные вами лучше?
Исходная версия abcq, :
Это только самые вопиющие,
простота использования за повышенное внимание.
которые оказывают прямое влияние на стабильность и безопасность.
следствие отсутствия внимания.
Есть еще такие замечательные вещи, как высокая сложность парсинга кода Си, которая вызвана фундаментально кривой реализацией макросов и существованием типов с пробелами в именах, хотя весь язык построен на отсутствии пробелов:
А зачем вам его парсить? Как парсинг языка сказывается на его типовом использовании?
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?
Все это до сих пор спорные механизмы которые в принципе заменяются колбеками и шаблонами проектирования. Скажем так, были альтернативы, почему вы считаете что альтернативы приведенные вами лучше?