Delphi vs. C++

[alexey_ar]

Интересно на чем основываются те кто утверждают что C/C++ это языки, "близкие к системе", "для системного программирования", "в котором надо четко понимать организацию памяти и CPU", и самое интригующее - "C/C++ позволяет получить наиболее быстрый/компактный код"... Какие то лично проведенные пробы, тесты, сравнения? Или только ссылки на бесконечное количество статей "для начинающих программистов" с примерно таким же содержанием?

ps В качестве контрпримера - могу привести ту самую всеми оплеванную Delphi(7) - с одним знакомым (компетенция которого в рамках обсуждаемого вопроса у меня не вызывает сомнений - так как он начинал с ассемблера еще на 8086/286, через несколько лет начал программировать нс СИ, не забывая ассемблер. Сейчас программирование микроконтроллеров и создание высокопроизводительного кода под win32 на Си/Асм (чаще всего - драйвера в ring0) - его хлеб и масло.)
Дак вот с этим товарищем, являющимся можно сказать фанатом Си/Асм, мы регулярно дискутируем по поводу того что у меня написано выше - он утверждает что это истина - я - что это ложь
Ранее дискуссии были весьма бурные, сейчас практически прекратились ввиду того что все придуманные нами проверки подтверждали только мою правоту. В двух словах о том что из себя представляли эти проверки:
1) Быстродействие компилируемых программ - реализация на C и Delphi различных алгоритмов - от банального quicksort на массиве целых 8-битных чисел до FFT на 64-битных числах с плавающей запятой на C и Delphi _без ассемблерных вставок_ и последующие: сравнение ассемблерного кода генерируемого компилятором с подсчетом тактов, бенчмарки на одинаковых входных данных в одинаковых условиях, сравнение объемов ассемблерного кода
2) Близость к системе и системное программирование - как ни старались, не придумали НИЧЕГО, что можно было бы реализовать под win32 на С и невозможно на Delphi - опять-таки от "hello world" и вызова стандартных API из DLL OS через сервис, прямую работу с памятью объектов и до драйвера в ring0 (который если уж возможно сделать - то возможно все).
В обоих случаях Delphi ни в чем не уступал C - попеременные (в разных задачах) небольшие (в пределах 2-3%) обгоны одного языка другим - факт совершенно не заслуживающий внимания - особенно потому что Delphi оказывался на эти 2-3% отстающим ничуть не реже чем обгоняющим. А в рядех случаев - просто тождественные результаты из-за тождественного asm-кода
3) По поводу понимания архитектуры ЭВМ - точно так же - если использовать Delphi не на уровне "положить на форму кнопку, ткнуть 'compile'" - это точно так же нужно как и в С (к сожалению)
4) Еще одно интересное упражнение в исходе которого в отличие от других мы не сомневались - это время затраченное на решение одной и той же прикладной задачи. Здесь С ни разу не оказался в лидерах, несмотря на то что я считаю что знаю Delphi хуже чем мой оппонент знает С.

Да, и еще - по поводу обучения - изредка встречается мнение что паскаль сложнее чем С... с этим я просто не знаю как спорить - доказать что 2+2=4 и то проще
Разве что статистикой да тем аргументом что в одно руководство по С влезет 5 руководств по Delphi

Итог - Delphi просто более универсален так как позволяет программировать и на уровне "кнопочничества" тоже - в отличие от С в Delphi можно сваять за 5 минут работающее приложение с кнопкой не зная _ничего_. Видимо из-за этого расплодилось множество "программистов" на Delphi, основываясь на грудах поделок которых был вынесен вердикт "Delphi - отстой". На самом деле если его изучать всерьез - то _в рамках OS win32_ такой же полноценный и серьезный язык как и С - просто с другим синтаксисом и в некоторых местах с другой идеологией - но с такими же возможностями.
(мда... "ps" получился длиннее основного текста... извиняюсь если кого утомил )

[незваный гость]

alexey_ar писал(а):

Интересно на чем основываются те кто утверждают что C/C++ это языки, "близкие к системе", "для системного программирования", "в котором надо четко понимать организацию памяти и CPU", и самое интригующее - "C/C++ позволяет получить наиболее быстрый/компактный код"... Какие то лично проведенные пробы, тесты, сравнения? Или только ссылки на бесконечное количество статей "для начинающих программистов" с примерно таким же содержанием?

Готов сослаться на личный опыт. У меня моя квалификация тоже сомнения не вызывает. Дальше что?

Я как-то нахожу и свои и Ваши аргументы легковесными, несерьезными.

Я уважаю Delphi, C, C++, и все остальное. И пользуюсь по мере подходящести к задаче. Для бизнес-приложений Delphi подходит, а для управления микроконтролером — слаб. Паскаль — прост, но умоляю: не называйте входной язык Delphi Паскалем. Вирт бы, ну не обиделся бы, но очень удивился. И покажите мне как в Паскале (а не в Delphi) вызвать функцию ядра системы (внешней библиотеки).

Каждая система программирования — это плод бессонных ночей и мучительных компромисов. У каждой — своя область применения. Поэтому делать тест вне этой области — смешно. Насколько легко написать обработчик прерывания или ядро ОС на Delphi Паскале? А для С++ есть десятки систем, оптимизированных именно под это. Не говорите, что можно поменять Паскаль. Можно. А С не нужно менять. Но это не делает его лучше. В ряде смыслов, С хуже. Ну и что?

И еще. Давайте сравним качество оптимизации Delphi, скажем, для ColdFire. У C++ — очень даже неплохо. А если считать на Intel, дык какой Вы компилятор берете? MS?

[alexey_ar]

незваный гость писал(а):

Я как-то нахожу и свои и Ваши аргументы легковесными, несерьезными.

В общем-то если у вас (и у других желающих) иногда бывает немного свободного времени, и есть интерес попробовать получить весомые аргументы, можно устроить примерно то же, о чем я писал в пред. посте - придумываем задачки (по возможности быстро реализуемые, но предоставляющие компиляторам простор для оптимизаций) и реализуем их на C++ и на Delphi с определенными условиями - в качестве первого могу предложить НЕ использовать ассемблерные вставки и/или подпрограммы. (Ессно это будет весьма небыстрый процесс - тк времени на забавы у всех по разному, и в основном немного - но мы никуда и не торопимся)

незваный гость писал(а):

Для бизнес-приложений Delphi подходит, а для управления микроконтролером — слаб.

Вот вот, пожалуйста, если не затруднит - что вы понимаете под управлением микроконтроллером? Прошивать в микрокнтроллер что-то сваянное на Delphi? Тут я и не спорю - Delphi не то что слаб - это просто дурость
А вот если вы имеете ввиду общение Delphi-приложения работающего на PC из-под win32 и общающегося с микроконтроллером через com/lpt/usb/isa/pci/что_угодно - то тут хотелось бы дополнительных пояснений - в чем "слабость" Delphi для такой задачи?

незваный гость писал(а):

И покажите мне как в Паскале (а не в Delphi) вызвать функцию ядра системы (внешней библиотеки).

А я про Паскаль ничего не говорил... Все что у меня написано в предыдущем посте - про Delphi. А Паскаль... в принципе будет справедливо сказать что я просто не знаю этого языка. Я знаю Delphi и говорю про Delphi (еще конкретнее - про IDE Delphi7)

незваный гость писал(а):

Насколько легко написать обработчик прерывания или ядро ОС на Delphi Паскале? А для С++ есть десятки систем, оптимизированных именно под это. Не говорите, что можно поменять Паскаль. Можно. А С не нужно менять.

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

незваный гость писал(а):

И еще. Давайте сравним качество оптимизации Delphi, скажем, для ColdFire. У C++ — очень даже неплохо. А если считать на Intel, дык какой Вы компилятор берете? MS?

Про coldfire опять-таки плохой пример - только x86, мало того - только win32. Про остальное я и не заикался. По поводу компилятора С - Intel С++/С 7.0 и VC++ 6.0 в зависимости от задачи (видимо интеловский он использовал там где были чисто алгоритмические тесты - то есть где не тестировалась работа с GUI например - а это мы тоже пробовали )

[незваный гость]

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

Во-вторых, когда пишут о языке, пишут о языке. Когда сравнивают системы программирования, говорят о системах программирования. Вы же смешали все в кучу, сравнивая систему программирования (Delphi) с языком С. На что Вам и было иронически указано в предыдущем посте (например, ссылками на ColdFire, обработчики прерываний).

Обработчик прерывний — понятие куда более общее, чем DOS, на который Вы ссылаетесь. Есть они даже(!) в Windows, с ними сталкиваются те, кто пишут драйверы. Ну, хотя бы драйвер контролера прерываний. Но во встроенных системах, особенно небольших — важная часть кода.

Управлять микроконтроллером, я, разумеется, имел в виде прошивку. То, что делается с ПК, я обычно называю коммуникацией. Поэтому, суммируя Вашу и мою точку зрения (включая OS, ядра): Delphi не подходит для встроенных приложений. Вспоминая язык Паскаль, можно призвать на помощь авторитетов. Никлаус Вирт считал, что Пасколь не подходит для написания ОС и сделал новый язык — Modula-2. Итого, какой из языков ближе к железу: С или Delphi Паскаль?

Ограничив же себя wintel'ом, трудно говорить о какой-либо близости к железу. Там все далеки (пока драйверы писать не начинают). Я, обычно, вообще игнорирую скорость, когда речь идет о GUI. В таких случаях мне важна только скорость разработки, и я брал VB. Что сейчас буду брать — не знаю.

alexey_ar писал(а):

Интересно на чем основываются те кто утверждают что C/C++ это языки, "близкие к системе", "для системного программирования", "в котором надо четко понимать организацию памяти и CPU", …

Теперь я готов ответить на этот вопрос. На опыте программирования, заметно более широком, чем в Win32. Т.е. на том, что Вы исключили из рассмотрения.

P.S. Я готов привести пример, о котором мне было бы интересно услышать Ваше мнение. Я даже не хочу говорить заранее, что Delphi хуже или лучше. Как бы Вы реализовали на Delphi какое-нибудь управление памятью (memory manager), скажем, с таким интерфейсом:

class MemPool {
public:
  MemPool(size_t initialSize = 0, size_t increment = 0);
  ~MemPool();

  template<class T>
   T* alloc();
  
  void free(void* ptr);
}

При создании пула должна захватываться начальная область initialSize MB, если очередной alloc() не может быть удовлетворен — то добавлено increment MB. alloc() выделяет кусок области, free() возвращает выделенное. alloc() типизирован, free() — атипно. Дело понятное, чем быстрее работает, тем лучше.

Я (упаси Боже) не жду программу. Может быть, интерфейс в Delphi. В любом случае, Ваши мысли — что удобно делать, что неудобно. Например, как организовать данные внутри. Путь С понятен — адресная арифметика. Какой будет путь Delphi?

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

[alexey_ar]

незваный гость писал(а):

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

Ээх... опять вы читаете невнимательно
Обратите внимание что я предложил запретить использовать только АССЕМБЛЕРНЫЕ вставки и подпрограммы - потому что если это разрешить - все сведется к тому что все будет написано на ассемблере и будет функционировать абсолютно одинаково. Обычные подпрограммы на основном языке используйте сколько вашей душе угодно. Наоборот, вызов подпрограмм - это один из весьма показательных тестов.

незваный гость писал(а):

Во-вторых, когда пишут о языке, пишут о языке. Когда сравнивают системы программирования, говорят о системах программирования. Вы же смешали все в кучу, сравнивая систему программирования (Delphi) с языком С. На что Вам и было иронически указано в предыдущем посте (например, ссылками на ColdFire, обработчики прерываний).

Нет, здесь вы тоже неправильно поняли. Я предложил вам в среде OS win32 сравнить Delphi7 с ЛЮБОЙ Си-шной "системой программирования" - можете выбирать в качестве "оппонента" любую - от notepad+intel compiler до MSVC++2005. Кроме того преимущества IDE идут в ход когда речь идет о разработке больших проектов. Я же предложил сравнить эффективность компиляторов на миниатюрных программах в которых будут использоваться наиболее общие моменты, которые являются кирпичиками в любом большом проекте. Тот же алгоритм quicksort или любой другой - мало какой большой проект обходится без сортировки чего-либо. В этом смысле вобщем-то непринципиально - с чем сравнивать Delphi7 - с отдельным компилятором С или с монстром типа VC+2005 (кстати могу вас заверить что VC++2005 проиграет intel'овскому компилятору в задаче quicksort - так что то что я предлагаю сравнить IDE (Delphi7) с отдельным оптимизированным компилятором (intel) - это существенная фора для С )

незваный гость писал(а):

Обработчик прерывний — понятие куда более общее, чем DOS, на который Вы ссылаетесь. Есть они даже(!) в Windows, с ними сталкиваются те, кто пишут драйверы. Ну, хотя бы драйвер контролера прерываний. Но во встроенных системах, особенно небольших — важная часть кода.

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

незваный гость писал(а):

Управлять микроконтроллером, я, разумеется, имел в виде прошивку. То, что делается с ПК, я обычно называю коммуникацией. Поэтому, суммируя Вашу и мою точку зрения (включая OS, ядра): Delphi не подходит для встроенных приложений. Вспоминая язык Паскаль, можно призвать на помощь авторитетов. Никлаус Вирт считал, что Пасколь не подходит для написания ОС и сделал новый язык — Modula-2. Итого, какой из языков ближе к железу: С или Delphi Паскаль?

Про встроенные приложения - см выше и внимательно пред. пост... Под ДОС - C ближе чем паскаль (неужели вы так невнимательно читали мой пост, раз доказываете мне то, что я сам написал выше? ). Под win32 С и Delphi равноудалены от железа - прослойкой между ними железом и C/Delphi всегда стоит asm.

незваный гость писал(а):

Теперь я готов ответить на этот вопрос. На опыте программирования, заметно более широком, чем в Win32. Т.е. на том, что Вы исключили из рассмотрения.

Угу. Если брать что-то вне win32 - тогда да, С требует больших знаний железа - с этим и не спорю

незваный гость писал(а):

P.S. Я готов привести пример, о котором мне было бы интересно услышать Ваше мнение. Я даже не хочу говорить заранее, что Delphi хуже или лучше. Как бы Вы реализовали на Delphi какое-нибудь управление памятью (memory manager).
...skipped...
В любом случае, Ваши мысли — что удобно делать, что неудобно. Например, как организовать данные внутри. Путь С понятен — адресная арифметика. Какой будет путь Delphi?

В Delphi путей несколько - можно как и в С заняться адресной арифметикой с getmem() freemem() и рукописным менеджером - высокая скорострельность, можно пойти несколько более простым путем и использовать потоки (у них можно вызывать read() и write() для чего угодно - от байт до экземпляров классов - организация данных внутри stream - это головная боль не моя а Delphi7 - хотя можно и взять ее на себя) - будет работать помедленнее, можно пойти самым простым путем - использовать динамические массивы, при этом элементом массива опять-таки может быть все что угодно - от byte до экземпляров каких-либо монстрообразных классов - правда работает медленнее всего.

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

var a:array of tclientsocket;
begin
  setlength(a,1000);
  ....работа с соединениями....
  a:=nil;
end;

10 секунд - и готово... Никаких утечек памяти, никакого слежения за памятью, ее выделением, размещением в ней своих объектов и тд... Хотя конечно setlength() работает в 2-3 раза медленнее чем getmem(). А если нужна скорость - пожлауйста - адресная арифметика как и в С всегда к вашим услугам

ps хотя даже сложнотипизированные динамические массивы работают вполне на уровне по скорости - например выделение памяти setlength() под 1000 tclientsocket занимает на P4 2.0 чуть больше 1мкс - то есть 2000 тактов - это со всеми потрохами - вызовом setlength() и ее работой - вычислениями требуемых размеров, проверкой доступности требуемого объема, обработкой исключительных ситуаций и инициализацией всей выделенной памяти (от заполнения нулями в случае выделения под массив байт до заполнения кострукциями в случае выделения например под массив тех же tclientsocket) - что называется - попробуйте сделать быстрее (а если и сделаете... 1мкс или 0.7мкс... велика ли разница при разовом выполнении? )

pps То есть если говорить об удобстве, предоставляемом языком - то я не знаю что может быть удобнее Delphi - тк вариантов реализации - от рукописного менеджера памяти по аналогии с С, до реализации задачи в двух строчках динамическими массивами. Если же говорить о скорости - то вот вам и первый вариант программы для сравнения эффективности компиляторов - выделение памяти в Delphi и в C. При этом наверняка сами по себе getmem() в Delphi и alloc() в С компилируются в идентичный asm-код и скорость будет одинакова, а вот с какими трудозатратами и насколько скорострельный код получится в случае выделения памяти под сложные типы - это (если вы не против немного попрограммировать с целью установления истины ) можно сравнить (рукописный менеджер на С и перечисленные мной три варианта на Delphi).

[незваный гость]

alexey_ar писал(а):

Ээх... опять вы читаете невнимательно

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

Столь же безосновательны и Ваши претензии к ссылам на не win32. Напомню Ваш первоначальный вопрос:

alexey_ar писал(а):

Интересно на чем основываются те кто утверждают что C/C++ это языки, "близкие к системе", "для системного программирования", "в котором надо четко понимать организацию памяти и CPU", и самое интригующее - "C/C++ позволяет получить наиболее быстрый/компактный код"... Какие то лично проведенные пробы, тесты, сравнения? Или только ссылки на бесконечное количество статей "для начинающих программистов" с примерно таким же содержанием?

Что-то в нем не видно ссылок на win32 .

alexey_ar писал(а):

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

Это Вас кто-то крепко обманул. Просто надул, беззащитного. Или грехи молодости спать не дают. На ассемблере обработчики прерываний писали до конца 80х – начала 90х, по-моему. С тех пор обходятся С, Паскалем, … в общем, что под руку попадется. Только вот на Python пока не видел. Но я не отчаиваюсь. Может быть, конечно, кто-то и сейчас на ассемблере пишет. Где-то ведь и огонь трением добывают…

Что касается ответа на мой вопрос об управлении памятью, то большая часть Вашего ответа втуне. Поскольку вопрос был отнюдь не «какие есть средства управления памятью в Delphi». А как бы Вы написали класс с вполне определенным интерфейсом. И с указанной семантикой. (Например, можете считать, что решение писать уже принято.) Между прочим, Ваша идея с использованием потоков для управления памятью весьма интересна. Может быть, расскажете подробнее? А с динамическими массивами я тоже не понял — мой alloc() возвращает указатели на объекты заказанного типа. Я просто пишу в вызове, что мне нужно:

MyClass* pmc = mm.alloc<MyClass>();
YourClass* pyc = mm.alloc<YourClass>();
mm.free(pmc);
mm.free(pyc);

Как тут Вы используете динамические массивы?

alexey_ar писал(а):

(если вы не против немного попрограммировать с целью установления истины)

Против. Времени нет на то, что я считаю не важным. У меня когда-то была опубликована статья о сравнении компиляторов и языков, так что я делать это умею. Но на данный момент меня совершенно не интересует сравнение компиляторов на PC. Под wintel это моя самая последняя забота, так как выбор языка определяется совсем иными нуждами проекта. Если я буду считать, что какой-то кусок не Delphi можно ускорить, переписав на С, я так и поступлю. Если же меня не интересует производительность, то мне тем более все равно. А для очень многих проектов я выберу Python, хоть он и проиграет по скорости раз в десять. Зато усилия на разработку и сопровождение сократятся.

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

Позвольте напомнить вопрос темы:

photon писал(а):

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

Я понял Ваше мнение: Delphi самая быстрая система программирование в wintel.

[alexey_ar]

незваный гость писал(а):

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

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

if (a && b || c)

которое вы, если исходить из вашей логики, не должны знаеть как воспринять

(a &&b) || c

или

a && (b || c)

( и не надо вспоминать про то что

&&

приоритетнее

||

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

a && b

либо

b || c

.
То есть в приложении к русскому языку, паскаль бы не допустил такой вот фразы, в котрой вы усмотрели неоднозначность, и потребовал бы от меня вот примерно такой коррекции: НЕ использовать ассемблерные (вставки и/или подпрограммы).

незваный гость писал(а):

Столь же безосновательны и Ваши претензии к ссылам на не win32.

А я вам спешу напомнить что в конце того поста было указано: _в рамках OS win32_ (правда вы по-видимому это в тот раз опять применили лишь к какой-то части поста... Уточняю - это было сказано в отношении всего поста )

незваный гость писал(а):

Это Вас кто-то крепко обманул. Просто надул, беззащитного. Или грехи молодости спать не дают. На ассемблере обработчики прерываний писали до конца 80х – начала 90х, по-моему. С тех пор обходятся С, Паскалем, … в общем, что под руку попадется.

Если нужна скорость, то всегда обработка прерываний пишется на asm... А когда на чем попадется - дак такие прожки и работают потом... Как попадется (И кстати не только обработка прерываний - в ring0 вообще львиная доля кода написана на asm)

незваный гость писал(а):

Может быть, конечно, кто-то и сейчас на ассемблере пишет. Где-то ведь и огонь трением добывают…

А вот с такими высказываниями следует быть осторожней Когда-то я тоже думал что написать на asm приложение под win32 с окошками иконками, скинами и прочими фенечками - это адова работа. В результате в один прекрасный день мне утерли нос сделав example такого приложения на masm под win32 на моих глазах меньше чем за час . Секрет оказался прост - просто весь исходник на 40% состоял из вызовов API-функций. А на С++ люди иногда по нескольку дней с этим умудряются возиться - особенно если mfc юзают . Еще например видел достаточно функциональный proxy-сервер под винду, написанный целиком на masm - опять таки на 1-2 странички asm-кода почти две странички вызовов API. Весит в скомпилированном виде 38кб, по скорости и размерам ни на Delphi ни на С за ним не угнаться как ни старайся. При этом временнЫе затраты на написание - практически такие же . В общем почитайте про win32 masm... Много неожиданного и интересного узнаете будет судя по "Где-то ведь и огонь трением добывают…"

незваный гость писал(а):

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

Странный вопрос... если вам нужен точно такой же интерфейс - ну дак тогда просто берется этот менеджер памяти, написанный на С++ и один к одному забивается в Delphi, заменяя "malloc" на "getmem", "{ }" на "begin end" и тд. Все получается один к одному. Скорость работы скомпилированного кода будет одинаковая. В чем тогда смысл вопроса, если не в доступных вариантах реализации какой-либо задачи? В С++ есть еще какие-нибыть варианты кроме такого класса? Я просто показал что Delphi вот есть... Но имхо абсолютно не прикладная задача, если не сказать надуманная и бесполезная - см ниже почему.

незваный гость писал(а):

А с динамическими массивами я тоже не понял — мой alloc() возвращает указатели на объекты заказанного типа. Я просто пишу в вызове, что мне нужно:

MyClass* pmc = mm.alloc<MyClass>();
YourClass* pyc = mm.alloc<YourClass>();
mm.free(pmc);
mm.free(pyc);

Как тут Вы используете динамические массивы?

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

var
  p1,p2:pointer;
begin
//создание экземпляра класса tmyclass
  getmem(p1,sizeof(tmyclass));
  tmyclass(p1^):=tmyclass.create;
//обращение к полям экземпляра класса:
  tmyclass(p1^).my_class_int_field:=12;

//создание экземпляра класса tyourclass
  getmem(p2,sizeof(tyourclass));
  tyourclass(p2^):=tyourclass.create;
//обращение к полям экземпляра класса:
  tyourclass(p2^).your_class_char_field:='r';

уничтожение экземпляров:
  tmyclass(p1^).free;
  tyourclass(p2^).free;
end;

Все. Не вижу смысла городить огород с "менеджером памяти" только ради того чтобы вместо доп. строчки "getmem(a,b)" писать доп. вставку "mm.alloc"... Изобретать колесо - оно знаете ли... Неблагодарное занятие

незваный гость писал(а):

Против. Времени нет на то, что я считаю не важным. <skipped> А для очень многих проектов я выберу Python, хоть он и проиграет по скорости раз в десять. Зато усилия на разработку и сопровождение сократятся.

Увы... В последнее время этот подход (в духе "плевать на скорость, лишь бы код писался приятно") получил прямо-таки характер эпидемии... Особенно меня .net в этом смысле пугает... Когда банальное окошко с настройками драйвера видяхи открывается на P4 5-6 секунд судорожно дрыгая винтом, особенно в сравнении с тем как оно открывалось субъективно мгновенно без обращений к винту в пред. версии драйвера... Ничего кроме полного недоумения "ЗАЧЕМ?".

незваный гость писал(а):

На мой взгляд, эпоха священных войн за языки программирования отошла в прошлое. <skipped>

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

незваный гость писал(а):

Я понял Ваше мнение: Delphi самая быстрая система программирование в wintel.

Нет, у меня нет такого мнения У меня есть мнение что в wintel Delphi и С++ - абсолютно равноценные языки (в том смысле что в плане реализации нет ничего что было бы возможно в одном языке, и невозможно или существенно более коряво и тормозно - в другом). Разница между ними лишь в том что Delphi проще в освоении, зато для С-шников в MSDN родной синтаксис - да и то эти два преимущества имхо практически уравновешивают друг друга . Если же я встречаю обратное утверждение (см выше) - то мне всегда интересно подискутировать с его обладателем.

ps Хотя по поводу священных войн - никто не сидит в танке, а все до сих пор залазят на коней и хватают флаги и шашки если речь заходит о том, какой синтаксис лучше . Опыт показывает (кстати см начало поста ) что независимо от того что говорят про стандарты и удобства сишного, нюансов, исключений, сложночитаемых элементов, двусмысленных трактовок и прочих "удобств" в нем существенно больше - на опыте это выливается в более высокое количество ошибок на тот же объем кода и на более трудоемкий их поиск и исправление, нежели в паскаль/Delphi

pps Когда просматривал другие топики этого раздела форума (да и любого другого по программированию) - очень много веселых минут доставило чтение неиссякаемых вопросов про то, а как бы избавиться от утечек памяти в С/C++, как их отслеживать, как надежнее отлавливать эти утечки и как бы писать код чтобы их было как можно меньше - и при этом серьезные обдуманные ответы с разными вариантами без всяких "RTFM" - то есть эта проблема в С видимо не считается уделом новичков, а остается актуальной и в программах професионалов тоже . Это так... к слову

[worm2]

alexey_ar писал(а):

А вот с такими высказываниями следует быть осторожней Когда-то я тоже думал что написать на asm приложение под win32 с окошками иконками, скинами и прочими фенечками - это адова работа. В результате в один прекрасный день мне утерли нос сделав example такого приложения на masm под win32 на моих глазах меньше чем за час .

Реинкарнация Александра Усова, однако!
Правда, сейчас он вроде бы эту идею уже не продвигает. И больше уважал TASM, но это не важно.

[Егор]

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

На C++ можно написать класс Vector<Field>, который будет моделировать элементы конечномерного векторного пространства над полем Field. Используя этот класс с разными значениями параметра Field, можно будет создавать и обрабатывать не только векторы со стандартными элементами (double или complex<double>), но также векторы дробей или векторы вещественных чисел произвольной точности. Слышал, будто подобный подход (перегрузка операций плюс статическая типизация) есть и в языке Haskell, но оформляется совсем по-другому - акцент делается на функции.

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

Можно ли написать универсальный класс Vector на Object Pascal?

[alexey_ar]

Егор писал(а):

В C++ важную роль играют шаблоны и перегрузка операций. Мне показалось, что незванный гость имел в виду применение этих средств языка для особенного управления памятью, чтобы создавать в нужной области памяти объекты заказанных типов. Предлагаю рассмотреть более тривиальный пример.
...skipped...
Можно ли написать универсальный класс Vector на Object Pascal?

про object pascal не знаю В delphi перегрузка методов есть, означает то же самое что в С++ и работает так же. Шаблонов нету именно в том виде, в котором они есть в С++ нету. Есть интерфейсы - функционально вещь достаточно близкая к шаблонам в С++. Подробнее можете почиать здесь: http://www.delphikingdom.com/asp/viewitem.asp?catalogid=1202.

по поводу универсального класса - лично для меня не составит труда (в случае надобности) просто сделать у этого класса прегрузку методов:

 function mymethod(a,b:single):single; overload;
 function mymethod(a,b:double):double; overload;
 function mymethod(a,b:extended):extended; overload;

и скопипастить трижды код этой функции, убедившись в каждом случае что функция работает корректно.
А на С++ еще большой вопрос не возникнет ли проблем - например если программист изначально при написании функции будет думать только о single и где-то внутри использует промежуточные переменные типа single, а потом через полгодика она ему понадобится для double и он (слава шаблонам) одним нажатием кнопки использует код этой функции с переменными a,b типа double (благополучно забыв что внутри функции весь счет идет в переменных single). Что полчится? Конечно же чушь

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

[Егор]

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

alexey_ar писал(а):

В delphi перегрузка методов есть, означает то же самое что в С++ и работает так же.

Но перегрузки операций (например, <, >, + и -), насколько понимаю, нет.

alexey_ar писал(а):

Шаблонов нету именно в том виде, в котором они есть в С++ нету. Есть интерфейсы - функционально вещь достаточно близкая к шаблонам в С++. Подробнее можете почиать здесь: http://www.delphikingdom.com/asp/viewitem.asp?catalogid=1202.

Любопытно, есть ли в Delphi интерфейсы, связанные с арифметическими операциями? Что-нибудь типа "ISummable", "IMultiplicable" и т. п.? Пишут ли на Delphi или Java универсальные библиотеки для работы с векторами и матрицами (для произвольных типов элементов), подобные MTL на C++? Есть ли в Delphi библиотеки для работы с числами произвольной длины?

Слышал, будто движки к игрушкам чаще всего пишут на C++. Так ли это и почему?

Встречались ли кому-нибудь хорошие статьи о сравнении шаблонов, интерфейсов и generics? P. S. Кое-что нашёл: http://www.xoltar.org/misc/static_typing_eckel.html.

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

[alexey_ar]

Егор писал(а):

Но перегрузки операций (например, <, >, + и -), насколько понимаю, нет.

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

 a,b,c:integer;
 d,e,f:single;
 g,h,i:string;
 j,k,l:boolean;
..... 
 c:=a+b;
 f:=d+e;
 i:=g+h;
 l:=j+k;
 //кроме того возможно и
 f:=d+e+a+b;

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

Егор писал(а):

Любопытно, есть ли в Delphi интерфейсы, связанные с арифметическими операциями? Что-нибудь типа "ISummable", "IMultiplicable" и т. п.?

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

Егор писал(а):

Пишут ли на Delphi или Java универсальные библиотеки для работы с векторами и матрицами (для произвольных типов элементов), подобные MTL на C++?

Универсальные библиотеки для работы с векторами и матрицами с типами элементов от byte до extended (80-битное с плавающей запятой) есть - я например использую нередко vectorgeometry (из набора esbmath). Библиотеки для работы с векторами и матрицами с другими типами переменных тоже есть, но вполне логично выполнены отдельно - так как идея мешать в одну кучу вычислительные функции и функции работы с текстовыми таблицами думаю не пойдет на пользу

Егор писал(а):

Есть ли в Delphi библиотеки для работы с числами произвольной длины?

Видел наборы функций для работы с 128-битными целыми и с плавающей запятой - где дело ограничивалось простыми арифметическими операциями. Что-либо более серьезное (имхо впрочем как и простые арифметические операции) начисто лишено смысла - так как во-первых надо очень коряво поставить а потом решать задачу, чтобы возникла необходимость в числах бОльшей разрядности чем 64бит, а во-вторых, обычный FPU в настольном P4/Athlon работает (от арифметики до логарифмов и тригонометрии) с числами разрядности опять-таки до 64бит включительно. Работа с числами бОльшей разрядности означает например что тот же синус числа будет вычисляться в CPU разложением в ряд или подобным извращением - скатываемся по быстродействию к 386. Не лучше ли усовершенствовать метод решения задачи чем так мучить комп?
Кстати могу добавить что помимо стандартного набора single(32bit)/double(64bit) в Delphi существует (без доп. библиотек - в стандартной поставке) тип чисел Extended - это тоже число с плавающей запятой как и double - но разрядностью 80bit. Работа с этим типом реализована так же полно как и с double - от арифметики до тригонометрии/логарифмирования но, увы, в CPU (с single/double вычисления в delphi выполняются в FPU). Работает с extended естественно медленнее чем с double - но вполне приемлемо для использования на тех участках где нужна высокая точность. Если этого мало - то для подобных задач уже лучше задуматься о фортране, да и вообще о другой платформе

Егор писал(а):

Слышал, будто движки к игрушкам чаще всего пишут на C++. Так ли это и почему?

Так сложилось исторически Если кратко - дело в том что С использовался при написании win32, для него существует мощный msdn, поэтому когда win32 вышла, под нее сразу стали писать на С. Когда же Delphi появилась и доросла до С++ (первые версии были существенно более бедными по возможностям на фоне С++) - у девелоперских фирм уже было столько наработок и библиотек на С++, что переход на Delphi уже был фактически невозможен - никто не захочет повторять снова работу выполненную в течение последних 5 лет
Кроме того отчасти видимо справедливо предположение, что в головах многих людей - от топ-менеджеров и руководителей до простых программистов утвердилась мысль что "C++ это круто, профессионально и серьезно, а все остальное - и особенно Delphi - забавы для студентов" - во многом сформировавшееся благодаря тому что после выхода Delphi появились толпы "программистов", научившихся кидать на форму пару кнопок и тыкать кнопку компиляции. Глядя на них люди естественно (к сожалению) переносили свое мнение об "игрушечности и тяп-ляпстве" и на среду разработки - особенно если сами с ней были не знакомы.

Егор писал(а):

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

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

ps в продолжение темы про неестественность синтаксиса языка С/С++: случайно наткнулся на вот эту статейку про Аду http://www.computer-museum.ru/histsoft/ada20.htm, где в частности упоминается что в качестве прототипа для Ады был выбран Паскаль. И что в среднем одна и та же программа при реализации на Аде имеет в 9 раз меньше дефектов чем она же, реализованная на C/C++ (видимо под дефектами подразумеваются не только и не столько прямые глюки, сколько потенциально опасные места). Ну и вообще интересная позновательная статья для тех кто считает что С достаточно быстрый, удобный и надежный для встроенных систем

[нг]

Тема выделена из «Разные языки. Преимущества и недостатки».

[Егор]

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

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

alexey_ar писал(а):

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

Имел в виду арифметические операции для типов, не встроенных в язык: векторов, матриц, комплексных чисел, обыкновенных дробей, чисел произвольной точности и т. п. Да, сложение можно обозначать и по-другому (s:=sum(a,b), s:=a.add(b), add(s,a,b) и даже push(a);push(b);call(add)), но это менее удобно.

alexey_ar писал(а):

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

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

alexey_ar писал(а):

Универсальные библиотеки для работы с векторами и матрицами с типами элементов от byte до extended (80-битное с плавающей запятой) есть - я например использую нередко vectorgeometry (из набора esbmath).

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

alexey_ar писал(а):

Видел наборы функций для работы с 128-битными целыми и с плавающей запятой - где дело ограничивалось простыми арифметическими операциями. Что-либо более серьезное (имхо впрочем как и простые арифметические операции) начисто лишено смысла - так как во-первых надо очень коряво поставить а потом решать задачу, чтобы возникла необходимость в числах бОльшей разрядности чем 64бит...

Числа произвольной точности бывают нужны: в теории чисел, криптографии, комбинаторике, в некоторых специальных исследованиях по методам вычислений. Не зря же в Maple и Mathematica можно ставить произвольную точность, а библиотека GMP (GNU Multi Precision) имеет интерфейсы на десятке языков программирования. Кстати, есть и паскалевский интерфейс (моя вина, что сразу не посмотрел), с процедурным синтаксисом: "mpz_add(s,a,b)".

Конечно, подавляющее большинство задач можно решать с помощью типов int и double, без всяких multi precision. Google выдаёт всего лишь десятки или сотни тысяч страниц на запросы типа "GNU MP" и "arbitrary precision arithmetic"; для сравнения, на запросы "Borland Delphi", "Graphical User Interface" и "Windows API" - миллионы страниц.

alexey_ar писал(а):

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

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

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

[незваный гость]

alexey_ar писал(а):

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

Увольте. Я Вам про Ерему, а Вы мне про Фому.

alexey_ar писал(а):

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

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

alexey_ar писал(а):

Шаблонов нету именно в том виде, в котором они есть в С++ нету. Есть интерфейсы - функционально вещь достаточно близкая к шаблонам в С++.

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

alexey_ar писал(а):

Что-либо более серьезное (имхо впрочем как и простые арифметические операции) начисто лишено смысла - так как во-первых надо очень коряво поставить а потом решать задачу, чтобы возникла необходимость в числах бОльшей разрядности чем 64бит, а во-вторых, обычный FPU в настольном P4/Athlon работает (от арифметики до логарифмов и тригонометрии) с числами разрядности опять-таки до 64бит включительно. Работа с числами бОльшей разрядности означает например что тот же синус числа будет вычисляться в CPU разложением в ряд или подобным извращением

Это — апология невежества. То, что я не знаю, не существует. Кроме win32, ничего в рассмотрение не принимаем… Поскольку я не встречался с задачами, требующими арифметики неограниченной точности, это никому не нужно. И т.д. (Чем-то мне это Маршака напоминает. «О чем разговаривали лошади, хомяки и куры». До боли напоминает.)

alexey_ar писал(а):

Увы... В последнее время этот подход (в духе "плевать на скорость, лишь бы код писался приятно") получил прямо-таки характер эпидемии... Особенно меня .net в этом смысле пугает... Когда банальное окошко с настройками драйвера видяхи открывается на P4 5-6 секунд судорожно дрыгая винтом, особенно в сравнении с тем как оно открывалось субъективно мгновенно без обращений к винту в пред. версии драйвера... Ничего кроме полного недоумения "ЗАЧЕМ?".

Вы, по всей видимости, живете в счастливом мире, оторванном от экономики. Для большинства же участников этого процесса, программирование — это чисто экономический процесс. Им важно не только что делает программа, но и когда. Не только насколько хороша новая идея, но и сколько процентов продаж она принесет. Например, MS не интересуют русские пираты Dev Studio. MS интересую банки и страховые компании, покупающие сотни (и тысячи) лицензий за раз. А банки (и страховки) не интересует быстрый код. Их интересует понятный код. Их интересует код быстро сделанный и надежно работающий. А 4-5 секунд — это не важно. Через год-два это станет 200-300 мс, и все… На это деньги тратить никто не хочет.

Егор писал(а):

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

Браво! Добавлять ничего и не надо

alexey_ar писал(а):

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

Достаточно быстрый — да. Удобный — в общем, достаточно. Надежный — тоже. Статья, оно, конечно неплохая. Но все эти сравнения всегда — с чем? Ада — (предположим) классный язык. Мне это по барабану, если нет компилятора для моего процессора. Рабочее место программиста на С++ для встроенных систем легко стоит 5-10 тысяч долларов. Сколько оно стоит для Ады? Есть ли вообще Ада для этого процессора? Какие у нее запросы? Она сможет работать в 48 КБ оперативной памяти? В 4 КБ? Как она ложится на конкретную RTOS? Я должен сам делать порт? Плюс, неизвестные дополнительные затраты на все стандартизованные радости?

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

Между прочим, я читал как-то любопытную статью. Автор долгие годы работал на IBM/360 и т.п. Язык, вестимо, PL/1. Он вспоминает, что за всю историю не было ни одного переполнения буфера. Потому, что операции автоматически отсекали по размеру буфера.

С (и С++) можно долго и скучно ругать за то, что они не защищают программиста. Как остро заточенные ножи. Но любой повар знает — нож должен быть острым. Большим поварским ножом (20-25 см) охватить себе пол-пальца совершенно не проблема. Вина ли это ножа? Или неумехи–повара?