В чём принципиальная разница между языками С и Паскаль?

[_Ivana]

Желающие не только высказать свое мнение, а еще и узнать, как оно на самом деле, могут посетить специализированные форумы.
На ассемблере пишется сейчас крайне незначительная часть кода для МК, в основном на С. Использование ассемблера должно быть оправдано. На асме, например, я писал код, который должен выполняться блоками строго определенное количество тактов процессора, для точного замера времени, и т.п. задач, что не гарантирует Си. Для других задач, еще нужно постараться переплюнуть компилятор с оптимизаций, генерируя ассемблерный код. Хотя, немало и тех, кто пишет на С, потом допиливает напильником сгенерированный компилятором ассемблерный код, и сдает заказчику именно последний
С становится на МК, у которого есть хоть капелька ОЗУ, а есть простейшие МК только с флешем, регистрами и может быть ЕЕПРОМом. Но и на такие МК вполне влезают именно ассемблерные стандартные библиотеки, от арифметики плавающей запятой в формате IEEE 754 или другом, и прочие функции.

[Taus]

(Оффтоп)

bin в сообщении #824466 писал(а):

Cредства для многопоточности, например, это не НЕстандартные библиотеки: мьютексы и семафоры - стандарные приемы параллельного программирования вне зависимости от языка и платформы. В отличие от Delphi в С++ с этим проблемы, поэтому сделали костыль TBB.

Начиная со стандарта 11 года в STL включена поддержка потоков и многопоточного программирования. Реализация конкретной многопоточной модели зависит от библиотеки. И этих библиотек очень много: boost, TBB, POSIX threads, Qt...

[rockclimber]

x51 в сообщении #824251 писал(а):

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

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

x51 в сообщении #824251 писал(а):

Вообще C или Pascal это знаменитый холивар. Я вам одно скажу: программист знающий паскаль может найти только одну специальность: учитель информатики. И то, если осилит педагогический.

В современном прикладном программировании гораздо большее значение имеет знание смежных вещей: предметной области, баз данных, веб-технологий и пр. Знания в "глубину" (алгоритмы всякие и т. д.) мало нужны, так как все уже давно реализовано в тех же базах данных, наборах компонентов в разных IDE и т. п.
А конкретно для любителей паскаля существует PL/SQL

x51 в сообщении #824251 писал(а):

P.S. паскаля не знаю, и не знал никогда. да и не узнаю видимо.

"Не читал, но осуждаю"?

А еще непонятно, что является принципиальным отличием? Уж как по мне, принципиальных отличий у них нет никаких. Принципиально отличаются от Си и паскаля языки с принципиально другим назначением - функциональные языки, или например, тот же PL/SQL.

[Joker_vD]

PL/SQL — для любителей Кобола.

[Alexu007]

rockclimber в сообщении #824908 писал(а):

А еще непонятно, что является принципиальным отличием? Уж как по мне, принципиальных отличий у них нет никаких. Принципиально отличаются от Си и паскаля языки с принципиально другим назначением - функциональные языки, или например, тот же PL/SQL.

Тем не менее, Си победил Паскаль.

А что даёт проверка выхода за границы массива во время выполнения? Ессно уменьшение быстродействия. Более удобную отладку - правильно написанная прога перед смертью выдаст табличку с причиной краха. Для конечного пользователя это мало что значит: какая разница, программа тихо умрёт или перед смертью выдаст: "произошло обращение по некорректному адресу 0000:0256"? Это программисту только интересно.

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

[Joker_vD]

Alexu007 в сообщении #824946 писал(а):

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

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

[Alexu007]

Joker_vD в сообщении #825005 писал(а):

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

Какие ремни безопасности? Они что, помогут аварийной программе продолжить выполнение и получить правильный результат - т.е. ремни безопасности помогут выжить? Да ничего подобного. Они только разработчику программы могут подсказать, где ошибка, из-за чего программа свалилась. Юзеру они 100% бесполезны.

P.S. То-то иногда при крахе программы окошко выскакивает: "попытка чтения/записи по адресу ...". Ну очень помогает!

P.SS. Если окошко ещё пишет типо "ошибка 234", и у программиста есть список, что это и где это - тогда хоть в отладке поможет. Информация "обращение по адресу XXXX:YYYY" ессно в ексешнике - практически бесполезна и программисту. Паскаль случаем не так пишет?

[Joker_vD]

Alexu007 в сообщении #825018 писал(а):

Какие ремни безопасности? Они что, помогут аварийной программе продолжить выполнение и получить правильный результат - т.е. ремни безопасности помогут выжить? Да ничего подобного. Они только разработчику программы могут подсказать, где ошибка, из-за чего программа свалилась. Юзеру они 100% бесполезны.

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

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

Alexu007 в сообщении #825018 писал(а):

Информация "обращение по адресу XXXX:YYYY" ессно в ексешнике - практически бесполезна и программисту.

Если вы не умеете пользоваться отладчиком — то да, вам она бесполезна.

[x51]

Joker_vD в сообщении #825005 писал(а):

Alexu007 в сообщении #824946 писал(а):

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

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

Надо понимать что пишешь. И не "прострелить себе ногу".

rockclimber в сообщении #824908 писал(а):

В современном прикладном программировании гораздо большее значение имеет знание смежных вещей: предметной области, баз данных, веб-технологий и пр. Знания в "глубину" (алгоритмы всякие и т. д.) мало нужны, так как все уже давно реализовано в тех же базах данных, наборах компонентов в разных IDE и т. п.

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

[Taus]

(Оффтоп)

x51 в сообщении #825035 писал(а):

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

Как IDE могут замусоривать код? IDE это только продвинутый текстовый редактор с дополнительными фичами в виде отладчика, средств автоматической сборки, CVS...

[Alexu007]

Joker_vD в сообщении #825028 писал(а):

Если вы не умеете пользоваться отладчиком — то да, вам она бесполезна.

Отладчиком на уровне машинных кодов - каюсь, не умею.

Допустим, мы записываем что-либо в A[B]. Ошибка возникает, когда в переменную B помещается неправильное значение, а обнаруживается в лучшем случае (в Паскале?), когда мы пробуем записать/прочитать в A[B]. В худшем - ещё дальше. Но всё равно не тогда, когда она действительно возникает - в результате неправильного вычисления значения B

[Xaositect]

Я не помню, как в Паскале обрабатываются присваивания интервальным типам, возможно, если правильно объявлять типы индексов, отловится как раз там, где Вы сказали.

Моя мечта, конечно, чтобы в несложных случаях оно отлавливалось на этапе компиляции.

[Taus]

Xaositect в сообщении #825049 писал(а):

Моя мечта, конечно, чтобы в несложных случаях оно отлавливалось на этапе компиляции.

А для этого существуют статические анализаторы кода

[Joker_vD]

x51 в сообщении #825035 писал(а):

Надо понимать что пишешь. И не "прострелить себе ногу".

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

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

Alexu007 в сообщении #825047 писал(а):

Допустим, мы записываем что-либо в A[B]. Ошибка возникает, когда в переменную B помещается неправильное значение, а обнаруживается в лучшем случае (в Паскале?), когда мы пробуем записать/прочитать в A[B]. В худшем - ещё дальше. Но всё равно не тогда, когда она действительно возникает - в результате неправильного вычисления значения B

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

x51 в сообщении #825035 писал(а):

vim и gcc, остальное лишнее.

...вы прямо на контролере запускаете vim, что ли? Обычно такие штуки пишут на нормальном компьютере, в нормальном редакторе, а потом кросс-компилируют.

Xaositect в сообщении #825049 писал(а):

Моя мечта, конечно, чтобы в несложных случаях оно отлавливалось на этапе компиляции.

H. Xi, F. Pfenning "Eliminating Array Bound Checking Through Dependent Types". В целом, там рисуется система линейных неравенств и решается в целых числах.

[EtCetera]

Taus в сообщении #825057 писал(а):

Xaositect в сообщении #825049 писал(а):

Моя мечта, конечно, чтобы в несложных случаях оно отлавливалось на этапе компиляции.

А для этого существуют статические анализаторы кода

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