Си или Паскаль. Что можно и что нет.
Модератор: Модераторы
Мутирую ~>
=)
=)
Для прикладного программирования, ПМСМ, ответ очевиден- Паскаль. Для системного- тоже (впрочем, в этом случае у Си появляются другие сильные конкуренты).
Да и тезис "разрешено всё, что не запрещено"- не совсем корректен.
Для решения типичных косяков, вызванных языком могут использоваться даже аппаратные средства- NX-бит, например.В Delphi переполнение буфера- это даже маленькая задачка. В Си (где всё разрешено) - это типичная ситуация
Да и тезис "разрешено всё, что не запрещено"- не совсем корректен.
Для решения типичных косяков, вызванных языком могут использоваться даже аппаратные средства- NX-бит, например.В Delphi переполнение буфера- это даже маленькая задачка. В Си (где всё разрешено) - это типичная ситуация
Практика показывает, что С и С++ меньше всего подходят для написания системного ПО, т.к. 99% дыр в безопасности - это следствие слабых строн языка С.
Но разработчики компиляторов Паскаля по какой-то причине приогнорировали тематику системного ПО, то есть не была создана возможность писать драйвера и некоторые другие модули, которые трубуют специального режима компиляции. Например, в драйвере должен применяться другой менеджер кучи (память нужно выделять по другому или вообще применять статическое выделение памяти для последующего использования ее менеджером кучи). Отсюда системное ПО оказалось сугубо полем С, который меньше всего годится именно для этих задач. Вот в прикладных задачах, на С++ уже возможно применение безопасных приемов программирования, а в системном все зациклино на внимательность и адекватность программиста.
Но разработчики компиляторов Паскаля по какой-то причине приогнорировали тематику системного ПО, то есть не была создана возможность писать драйвера и некоторые другие модули, которые трубуют специального режима компиляции. Например, в драйвере должен применяться другой менеджер кучи (память нужно выделять по другому или вообще применять статическое выделение памяти для последующего использования ее менеджером кучи). Отсюда системное ПО оказалось сугубо полем С, который меньше всего годится именно для этих задач. Вот в прикладных задачах, на С++ уже возможно применение безопасных приемов программирования, а в системном все зациклино на внимательность и адекватность программиста.
-
Рождённый_в_СССР
- новенький
- Сообщения: 65
- Зарегистрирован: 08.08.2007 01:03:26
- Откуда: Саратов
Практика показывает, что С и С++ меньше всего подходят для написания системного ПО, т.к. 99% дыр в безопасности - это следствие слабых строн языка С.
Чья практика? Создателей языка C--?
о каких 99% дырах идёт речь? отсутствие сборщика мусора? этого нет и в fpc, куча синтаксического сахара? остутствие контроля указателей? о каких 99% дырах речь? я впервые слышу это... C и C++ - разные вещи... лучшее на сегодняшний день для системного программирования чем C - только ассмеблер и какой-нить AHDL (но там свои тараканы)
Рождённый_в_СССР писал(а):о каких 99% дырах идёт речь? отсутствие сборщика мусора? этого нет и в fpc, куча синтаксического сахара? остутствие контроля указателей? о каких 99% дырах речь? я впервые слышу это... C и C++ - разные вещи... лучшее на сегодняшний день для системного программирования чем C - только ассмеблер и какой-нить AHDL (но там свои тараканы)
О тех, которые ежемесячно в качестве багов поступают в обновления всех видов ОС (Винда, Линухи, Юниксы и т.п.), всех вариантов браузеров и т.п.
А вот сборщик мусора в системных задачах штука принципиально не применимая.
-
Kemet
- постоялец
- Сообщения: 241
- Зарегистрирован: 10.02.2010 18:28:32
- Откуда: Временно оккупированная территория
- Контактная информация:
alexey38 писал(а):ора в системных задачах штука принципиально не применимая.
Есть куча ОС, написанных на типобезопасных языках, с использованием сборщика мусора.
Например SPIN - написана на Модуле-3,
Виртовская Оберон - написана на Оберон
A2, она же Bluebottle, она же AOS - написана на Активном Обероне (Active Oberon)
список можно продолжать...
Kemet писал(а):список можно продолжать...
Можно.
Теперь от вас список реального применения этих ОС.
В промышленности? Может в планшетах? Или в телефонах? Ещё где?
-
Kemet
- постоялец
- Сообщения: 241
- Зарегистрирован: 10.02.2010 18:28:32
- Откуда: Временно оккупированная территория
- Контактная информация:
sign писал(а):Теперь от вас список реального применения этих ОС.
В промышленности? Может в планшетах? Или в телефонах? Ещё где?
Если персонально вам они не нужны, ну и ради бога.
Лично мы используем A2 - направление роботизация. Систему, основанную на Native Oberon, используем для управления производственной линией.
ОС Оберон и производные также используют
Где-то на сайте ETH был более подробный список.
В любом случае, речь шла не о чьём-то персональном использовании, а о наличии и возможности использования типобезопасных языков с использованием сборщика мусора для построения минималистичных и надежных операционных систем.
Kemet писал(а):с использованием сборщика мусора
Кстати не нужно путать функцию автоматического удаления строки или объекта при выходе из зоны видимости (что есть в паскале в строках, динамических массивах и ком-объектах) со сборщиком мусора который живет своей жизнью, оторвавшись от бизнес-логики. Для реальной ОС должно быть очевидным время выполнения конкретной функции, не должно быть так, что в этот раз мы память не очистим, а в другой раз очистим.
Kemet писал(а):Есть куча ОС, написанных на типобезопасных языках, с использованием сборщика мусора.
Например SPIN - написана на Модуле-3,
Виртовская Оберон - написана на Оберон
A2, она же Bluebottle, она же AOS - написана на Активном Обероне (Active Oberon)
список можно продолжать...
Проект Singularity. А также его потомки Cosmos и Fantom. Написаны не только на типобезопасном языке, но и использует "управляемый" код. По производительности и надежности дадут фору многим современным коммерческим поделкам.
Я, например, немного чувствую дискомфорт в фрипаскале из-за его строгости. Часто хочется объявлять переменные в любом месте, иногда удобно тело функции написать при объявлении типа. и т.д.. Думал даже препроцессор написать чтоб добавить такие возможности. В fpc естественно есть свои плюсы..
-
serbod
- постоялец
- Сообщения: 449
- Зарегистрирован: 16.09.2016 10:03:02
- Откуда: Минск
- Контактная информация:
carrots писал(а):Я, например, немного чувствую дискомфорт в фрипаскале из-за его строгости. Часто хочется объявлять переменные в любом месте, иногда удобно тело функции написать при объявлении типа.
Это типичное впечатление новичков при написании программы с нуля. Поэтому новички так любят Python и JavaScript, где нет "бюрократии".
Но когда проект разростается до десятков модулей и тысяч функций/методов, то возникает проблема навигации и рефакторинга. И вот тут паскаль со своими предварительными объявлениями и строгой типизацией рулит и педалит. А в других языках придумывают костыли для типизации и оглавления, которые непонятны новичкам. =)
Паскаль не может рулить на «больших проектах», потому что в Паскале ПРИНЯТО использовать низкоуровневые штучки вроде взятия УКАЗАТЕЛЕЙ на элементы динамических массивов, приведения через простой (не as) каст классов, которые ТОЧНО-ТОЧНО ПРИВОДИМЫ и т. д. Или вот, по крайней мере, в среде Delphi по непонятной мне причине есть ТРАДИЦИЯ слишком привязываться к платформе — как среди программистов, так и разработчиков самой Delphi. Вспомните, например, зачем были введены интерфейсы, или как объяснялись изменения в компиляторе под iOS. FreeAndNil, официально НЕ ПРОВЕРЯЮЩИЙ тип параметра — это вообще вышка (пропускает незамеченной смену типа FreeAndNil'ящейся переменной с объекта на интерфейс, массив или запись — что там про типизацию?). Всё это — мины замедленного действия, в отличие от Питона — с неопределённым поведением.
runewalsh писал(а):Питона
Питон и его синтаксис бред сумасшедсшего. Популярный потому что гуглу захотелось в него поиграть.