Маленькие вещи, которые в Delphi сделаны верно

Это перевод Little things Delphi gets right. Автор: Mason Wheeler.

Для тех, кто ещё этого не видел: разработчики StackOverflow создали по популярным просьбам новый сайт, называемый programmers.stackexchange.com - сайт для субъективных программистских вопросов, которым не место на StackOverflow. Некто недавно опубликовал опрос: какой ваш любимый язык. Вы, вероятно, можете угадать, каков был мой ответ:

Delphi
Это язык со стандартной, императивной, объектно-ориентированной парадигмой, с которой знакомы большинство программистов. Но в нём сделаны правильно некоторые небольшие вещи, которые в большинстве языков семейства C делаются неверно. Плюс, последние версии языка получили поддержку некоторых концепций функционального программирования без применения уродливых инверсий абстрации, которые обычно сопровождают функциональные языки.

Мне написали множество интересных комментариев. Кто-то спросил: “чтобы оправдать наезд на C (чтобы они вас не избили!), и удовлетворить моё любопытство: о каких "маленьких деталях" идёт речь?”

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

Давайте начнём со слона в комнате.

Безопасность!!!

Не существует хорошей причины, чтобы человек когда-либо при любых обстоятельствах писал сетевую программу с требованиями по безопасности (типа операционной системы или web-браузера) на C, C++ или Objective-C. Мы знаем, что прошло уже 22 года, с тех пор как Роберт Моррис выпустил своего Интернет-червя, который использовал переполнение буфера в ОС Unix для парализации около 10% Интернета, что привело к ущербу в десятки миллионов долларов (в то время это было очень маленький Интернет. Сегодня ущерб измеряется в сотнях миллиардов долларов, а может и больше - если вы просуммируете ущерб от ошибок переполнения буфера с другими, специфичными для C уязвимостями, эксплуатируемыми в последние два десятилетия).

Тут должен "прозвенеть звонок". Вы не можете писать программы с надёжной безопасностью в языке, который был спроектирован без единой мысли о ней! По крайней мере, не с любой степенью согласованности. Просто посмотрите, как много патчей выпускается сегодня для Windows, Linux, OSX, iOS и различных Интернет служб и Web-браузеров - большая часть из которых происходит из-за переполнения буфера. И это становится всё хуже. Люди говорят о компьютеризации энергосистемы, что имеет смысл в теории, но на практике, вероятнее всего, просто откроет несколько сотен миллионов новых уязвимостей для террористов (кто не смотрел Крепкий орешек 4.0 (Live Free Or Die Hard)? Кто-нибудь хочет жить в их мире, только без Брюса Уиллиса и этого парнишки “I’m a Mac”, которые так удобно спасают мир?).

Одна и та же старая проблема повторяется снова, и снова, и снова. Она продолжает существовать, потому что она просто не может быть решена в C без разрушения обратной совместимости. В любом разумном мире, язык C вымер бы к 1989 (червь Морриса показал, что он просто не подходит для своей цели: постройки операционной системы), и наши компьютеры стали бы безопаснее. Нельзя сказать, что тогда не было никаких альтернатив. К этому времени Apple уже несколько лет делала самую продвинутую ОС того времени - на Паскале. Продолжить писать Internet-программы на C (или C++ или Objective-C) - должно рассматриваться как акт преступной халатности.

В Delphi, с другой стороны, у нас есть настоящий строковый тип - самый продуманный из всех, что я видел в других языках. У него есть счётчик ссылок и он меняет размер строки сам по мере необходимости, что освобождает программиста от мук с размером строк и памяти для строк. Он проверяет на допустимость индекса и он не живёт на стеке, поэтому не существует способа использовать переполнение буфера строки для эксплоита типа stack-smashing. Аналогично и для других типов данных: у Delphi есть настоящий динамический массив, который также проверяем на допустимость индекса. Фактически, у нас есть два типа массивов (индексы проверяемы у обоих), и тот, размер которого не фиксирован (самый опасный из двух), также не живёт на стеке. У нас также есть подпрограмма форматирования строк, которая не использует varargs (переменное число аргументов), а код вывода строк не предполагает, что его данные являются форматируемой строкой, что делает Delphi программы нечувствительными к атакам на строки форматирования.

Чтобы быть честным, я, конечно же, должен сказать, что, как и в любом языке, использующем указатели, в Delphi возможно написать небезопасный код. Но для этого вам надо сильно извернуться; это не нормальное состояние для языка, как это имеет место быть для C! (полное удаление указателей из языка также привносит больше проблем, чем решает. Вот почему и в Java и в C# есть явные небезопасные возможности: потому что они необходимы для выполнения важных задач).

Синтаксис и семантика

OK, хватит о безопасности. Давайте перейдём и к другим вещам. Много проблем с безопасностью в C решены в управляемых языках типа C# и Java. Но что они не могут сделать - так это исправить синтаксис, по крайней мере, не разорвав свои общие корни с C, которые являются мощным инструментом маркетинга.

К примеру, в C нет логического типа. Некоторые из его наследников его имеют, но поскольку они вынуждены быть с ним совместимыми, то проблемы отсутствия логического типа никуда не пропадают. Поскольку в C нет Boolean, то что угодно может трактоваться как логическое условие.

Недавно я услышал действительно ужасную игру слов: Торт может быть ложью, но Пи всегда истина (потому что Пи не равно нулю, а в C любое значение, отличное от нуля, считается истинным логическим значением). Когда у вас что угодно является логическим выражением, включая операцию присваивания, вы не можете безопасно написать if x = 5 - и не важно, как разумно и интуитивно это выглядит. Также, когда у вас всё является логическим типом, включая числа, если вы попробуете выполнить операцию and между двумя выражениями, то компилятор не знает, имели ли вы в виду логическую или побитовую операцию - поэтому вам нужно два варианта каждого логического оператора. А если вы ошибётесь, то или ваш код может работать или у вас будет ошибка, которую-хрен-найдёшь.

Java, JavaScript и C# всё ещё имеют две версии операторов. И я знаю, что проблема с if x = 5 всё ещё существует в JavaScript (мне сказали, что компилятор не пропустит такое в C#. Не уверен, как тут обстоят дела в Java).

В Delphi логический тип - это логический тип, а число (или строка или объект) - это не логический тип. Это значит, что у нас есть одно and, одно or, одно xor и одно not, а компилятор знает, какую операцию нужно применить (логическую или побитовую), просто смотря на типы операндов. А если вы попробуете сделать что-то странное, типа and между логическим значением и числом, то компилятор просто не пропустит это, вместо молчаливой генерации не имеющего смысла кода.

И пока мы не отошли от операторов, кто из вас может сказать мне, что делают * или & в C? “Ну, это зависит от того, ...” Ох, да. Фундаментальные синтаксические элементы, чьё значение определяется по контексту. Как мило. В Delphi, “a * b” означает умножение и ничего иного. А для взятия адреса и разыменования у нас есть операторы @ и ^ соответственно, которые имеют мнемонический смысл.

А потом - ООП. Модель объектов в C++ - это большой беспорядок. Нет базового объектного типа. Что означает, что вы не можете написать подпрограмму, принимающую любой объект. Это также означает, что нет стандартного способа получить информацию об объекте в run-time (в Delphi это называется RTTI). А объекты являются value-типами - т.е. хранящимися (по-умолчанию) на стеке (или внедрёнными в другой объект), а передаются по коду по значению (по-умолчанию). Это сводит на нет наследование и полиморфизм.

Например, что выведет эта программа? Если вы измените сигнатуру функции Foo, чтобы она передавала объект по ссылке - изменит ли это вывод программы?

#include <iostream>

class Parent
{
public:
        int a;
        int b;
        int c;

        Parent(int ia, int ib, int ic) {
                a = ia; b = ib; c = ic;
        };

        virtual void doSomething(void) {
                std::cout << "Parent doSomething" << std::endl;
        }
};

class Child : public Parent {
public:
        int d;
        int e;

        Child(int id, int ie) : Parent(1,2,3) {
                d = id; e = ie;
        };
        virtual void doSomething(void) {
                std::cout << "Child doSomething : D = " << d << std::endl;
        }
};

void foo(Parent a) {
        a.doSomething();
}

int main(void)
{
        Child c(4, 5);
        foo(c);
        return 0;
}

Если вам пришлось остановиться и поразмышлять об этом коде - это показательный признак. Я попросил нашего эксперта C++ посмотреть на код и сказать, что он делает. Он изучал его несколько минут, пришёл к логично-звучащему выводу о том, что он должен делать. После чего он прогнал код через компилятор, чтобы быть уверенным (и это человек, который профессионально писал на C++, когда я ещё учился в университете. И он очень хорош в нём. Но даже со всем своим опытом, у него не было полной уверенности без пробного прогона).

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

Внешний код

Для всего вышеперечисленного хотя бы есть технические причины. Но вот кое что действительно эксцентричное, чему я пока не слышал хорошего объяснения. Как-то мне надо было отладить DLL, написанную на C, которую вызывала моя Delphi программа. Я открыл эту DLL в Visual Studio и попытался скомпилировать. Хотя всё было синтаксически верным и компилировалось отлично, но сборка проваливалась на фазе линковки, потому что линкёр не мог найти .lib-файл для второй DLL, которую требовала эта DLL.

.lib-файл? Что, во имя Тьюринга, есть .lib-файл?!? Ну, оказывается, что это файл, который описывает …что-то… о другой DLL, так что линкёр может правильно прицепить это …что-то…. Я не представляю, почему это является необходимым. Раньше мне не приходилось с ними работать. В Delphi, если тебе надо прицепить другую DLL, ты объявляешь в коде заголовок функции, указываешь, что это внешняя функция, и предоставляешь имя DLL, в которой находится функция - вот и всё.

У кода C есть вся та же информация: .h-файл, содержащий заголовок функции и … ооохх, постойте-ка. Теперь я вижу, что происходит! Ведь это фактически тот же самый .h-файл, который используется в DLL, с которой я связываюсь. Поэтому он не указывает, ни что эти функции являются внешними, ни где их искать. Эта информация, хотя и является важной частью кода, должна быть предоставлена отдельно - в .lib-файле, двоичном контейнере, сгенерированном компилятором по той самой внешней DLL, который к тому же не читабелен человеком и плохо переносит версионный контроль (а если ваша внешняя DLL не была написана на языке семейства C, то вас ожидает ещё больше веселья в попытках сделать .lib-файл для неё).

Всё это сводится к тому, что, по какой-то странной причине, Delphi делает работу со ссылками на библиотеку C более беспроблемной, чем это делает сам C. Это же не имеет никакого смысла, но так и есть. Delphi может говорить с внешним кодом C легче, чем C!

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

Примечание переводчика:
Вот ещё два примера вещей, которые получили бешеную популярность, несмотря на техническое превосходство конкурентов: архитектура x86, Windows. В частности, в связи с упоминанием выше переполнения буфера, хочу особо ткнуть сюда (это одновременно и ещё один пример, как более технически совершенная платформа ia64 проиграла платформе Amd64).