Портабельность кода поисковой машины и С++ библиотеки

English

Матрица совместимости платформ

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

² В некоторых случаях проверялась работа на английских версиях ОС.

³ Установка сервис-паков не является необходимой для функционирования программ, и в тоже время более строгий подход к обеспечению безопасности в XP SP2 не мешает нормальному функционированию поисковиков.

Пояснения

В данном разделе рассматривается два аспекта:

1. возможность компилировать исходные тексты программ Проекта современными компиляторами в рамках одного семейства ОС;

2. возможность компилировать программы в разных ОСях.

Эти задачи тесно связаны. Работа над проектом начиналась почти десять лет назад в среде MSDOS, главным компилятором был поначалу Borland C++ 2.0. Там еще не было шаблонов, исключений, ... да много чего не было. Потом появилась возможность перейти на Borland C++ 3.1 (в нем появились шаблоны). И примерно в то же время удача в виде компилятора Watcom C++ улыбнулась Проекту – в 1996 году это был самый мощный транслятор для MSDOS (им компилировался первый DOOM). Он давал возможность использовать всю оперативную память системы. К тому времени барьер 640Kb сильно тормозил расширение Проекта – стало ясно, что потребуются мегабайты оперативной памяти для манипулирования гигантскими сложноорганизованными списками.

Именно с этого момента я стал пристально следить за вопросами портабельности. Borland C++ 3.1 генерил 16-битный код, в котором int имел длину 2 байта. Watcom C++ создавал полноценный 32-битный код, с 4-х байтным int. Первые же прогоны программ выявили массу багов, возникавших из-за неявных преобразований целочисленных данных, с расширением знака и без... Примерно такая же ситуация складывается сейчас, в связи с наметившимся переходом к 64-битным процессорам. Огрехи в проектировании (да скажем прямо, глупые решения) теперь выходят боком: часть контейнеров работает с 32-битными знаковыми индексами (тип signed int) вместо полагающегося в этих случаях size_t. Может показаться, что это – мелочь. Но в среде Borland C Builder 6.0 тип size_t объявлен как signed. А, к примеру, в GCC 3.2.1 – как unsigned int. В результате фрагмент

for( size_t i=10; i>=0; i-- ) ...

в BCB будет отлично работать, а в GCC – выдавать в лучшем случае Segmentation fault. Потребовалось несколько часов плаванья в линуховом отладчике, чтобы еще раз убедиться, что нельзя пренебрегать азбучными Cишными истинами по поводу портабельности программ.

Точно так же потребовалось несколько дней отладки, чтобы выяснить, что в компиляторе GCC очередной версии размер wchar_t - не 2, а 4 байта. Справедливости ради отмечу, что ошибка в связи с неявный преобразованием wchar_t к boost::int16_t обнаружилась лишь в одном месте.

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

Совместимость с компиляторами

Итак, в настоящее время Проект (за исключением некоторых изначально непортабельных модулей) гарантированно компилируется и исполняется в средах:

Windows 98...XP компиляторы Borland C Builder 6.0, Microsoft Visual Studio.NET 2003, Minimalist GCC for Win

Linux Mandrake 9.2/10.0 компилятор GCC 3.2

Вероятно, не будет особых проблем с портированием на другие платформы. Слабым звеном является компилятор. Именно по этой причине невозможно использовать OpenWatcom 1.1 – он категорически несовместим с современным стандартом C++ (начиная с отсутствия namespace'ов, заканчивая многочисленными багами в реализации шаблонов - особенно при частичной подстановке параметров шаблонов).

Собственно Проект (то есть его ядро) написаны на полностью стандартном C++, с широким использованием обобщенного программирования, библиотек STL и BOOST C++. Большое значение имеет поддержка исключений – в нескольких случаях генерация-перехват исключений используется как более-менее нормальное поведение программы (основной пример – генерация исключения в ходе грамматического анализа фразы по причине явно затягивающегося процесса, то есть по тайм-ауту, с перехватом этого исключения далеко в вызвавшем коде с тем, чтобы принять стратегическое решение – стоит ли продолжать работу с предложением и т.п.).

Очень важна нормальная реализация работы с шаблонами. Partial specialization используется без оглядки - поэтому, к примеру, компиляция Проекта в MS Visual Studio версий до 2003 года вызывает проблемы (спасибо группе разработки компиляторов Мелкомягких - это надо было постараться ввести в C++ множество уродливых расширений в виде managed кода и не реализовать нормальную работу с шаблонами). Поддержка шаблонов в OpenWatcom'е также впечатляет - логики в его отступлениях от стандарта выяснить не удалось, а переписывать большую часть кода Проекта для поддержки мертвого диалекта языка - слишком большая роскошь. Подождем, пока ребята из группы развития этого проекта поправят свой продукт.

Взаимодействие ядра с прикладным кодом выполняется через виртуальные потоки, которые могут вести и на текстовую консоль, и в листбокс окна, и в дисковый файл. Так или иначе, все замыкается на сишный FILE и функции fopen/fread/fwrite/fclose.

Вообще максимально широкое использование стандартных инструментов - контейнеров, обобщенных алгоритмов и так далее, вместо собственных аналогов, поставлено целью в последний год.

Хочется отметить, что термин ядро употребляется только удобства ради. Процедуры ядра Проекта не являются каким-либо привилегированным процессом ОС. Более того, они являются частью кода прикладной программы, поскольку попросту прикомпилируются к ней.

Есть также ряд программ, которые четко привязаны к определенной платформе – типа Отладчика (модуль DEBUGGER, см. описание здесь), который создан с помощью дизайнера форм Borland C Builder'а и работает под Windows. Задача написания портабельных инструментов стоит в Проекте достаточно давно, но на ее реализацию нет времени.

см. список ссылок на полезные ресурсы по данной теме ►

последние изменения 10.08.2007