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

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

  faind Integra
  Консольная поисковая утилита
описание
настольный поиск для Win32
описание
Windows 98 SE OK  
Windows Me OK  
Windows NT 4.0 (SP6) 1,3
для корректной работы интерфейса желательно установить последнюю версию Internet Explorer, например 6.1
OK OK
Windows 2000 (SP4) 1,3 OK OK
Windows XP (SP1 и SP2) 1,2,3 OK OK
Windows 2003 Server 1,2,3 OK OK
Linux Mandrake 10.0 (ядро 2.6.3) OK  

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

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

3 Установка сервис-паков не является необходимой для функционирования программ, и в тоже время более строгий подход к обеспечению безопасности в 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

  © Mental Computing 2010