Проблема многих традиционных «учебных» реализаций заголовков конфигурации (где все варианты конфигурации находятся в одном «монолитном» заголовке) заключается в том, что они нарушают определенные фундаментальные принципы разработки программного обеспечения, которые могут сделать повышение более хрупким, более трудным для обслуживания и более трудным для безопасного использования. Вы можете найти описание принципов из следующей статьи .
Рассмотрим ситуацию, в которой вы одновременно развиваетесь на нескольких платформах. Затем рассмотрите возможность добавления новой платформы или изменения определений платформы существующей платформы. Что происходит? Все, и это буквально означает все, перекомпилируется. Разве не абсурдно, что добавление новой платформы, которая не имеет абсолютно ничего общего с ранее существующими платформами, означает, что весь код на всех существующих платформах должен быть перекомпилирован?
Фактически, существует навязанная физическая зависимость между платформами, которые не имеют ничего общего друг с другом. По сути, традиционное решение, используемое заголовками конфигурации, не соответствует принципу открытого закрытия:
Модуль должен быть открыт для расширения, но закрыт для модификации.
Расширение традиционного заголовка конфигурации подразумевает изменение существующего кода.
Кроме того, следует учитывать сложность и хрупкость кода обнаружения платформы. Что делать, если простое изменение нарушает обнаружение на какой-то незначительной платформе? Что, если кто-то случайно или намеренно (в качестве обходного пути для какой-то другой проблемы) определяет некоторые зависящие от платформы макросы, которые используются кодом обнаружения? Традиционный заголовок конфигурации является одним из самых изменчивых заголовков всей библиотеки, и от него будут зависеть более стабильные элементы Boost. Это нарушает принцип стабильной зависимости:
"Зависит от направления устойчивости".
После даже незначительного изменения традиционного заголовка конфигурации на одной второстепенной платформе почти все на каждой платформе должно быть протестировано, если мы будем следовать практике разработки звукового программного обеспечения.
Другой важный вопрос заключается в том, что не всегда возможно представить изменения в <boost/config.hpp>. Некоторые пользователи в настоящее время работают на платформах, используя инструменты и библиотеки, которые находятся под строгими соглашениями о неразглашении. В этой ситуации невозможно представить изменения в традиционном монолитном заголовке конфигурации, вместо этого должен быть предоставлен некоторый способ, с помощью которого пользователь может вставить свой собственный код конфигурации.
Подход, используемый заголовками конфигурации boost, состоит в разделении конфигурации на три ортогональные части: компилятор, стандартная библиотека и платформа. Каждый компилятор/стандартная библиотека/платформа получает свой мини-заголовок конфигурации, так что изменения конфигурации одного компилятора (например) не влияют на другие компиляторы. Кроме того, существуют меры, которые могут быть приняты как для пропуска кода обнаружения компилятора / стандартной библиотеки / платформы (чтобы добавление поддержки на новую платформу не нарушало зависимости), так и для полного замораживания конфигурации; обеспечивая почти полную защиту от изменений зависимостей.
