Включить все, отделить с помощью

Question

Я занимаюсь разработкой библиотеки C ++. Это заставило меня задуматься о способах обработки Java и C #, включая различные компоненты библиотек. Например, Java использует «import», чтобы разрешить использование классов из других пакетов, в то время как C # просто использует «using» для импорта целых модулей.

Мои вопросы: будет ли хорошей идеей включить #include все в библиотеке в одно массивное включение, а затем просто использовать директиву using для импорта определенных классов и модулей? Или это было бы просто безумием?

EDIT: Хорошие ответы пока, вот несколько смягчающих факторов, которые я чувствую добавить к этой идее:

1) Внутренние # включаются как обычно (короткие и точечные)
2) Файл, который включает в себя все, по желанию поставляется с библиотекой для тех, кто хочет его использовать
3) При желании вы можете сделать большой включаемый файл частью предварительно скомпилированный заголовок

Answer 1

Вы путаете назначение #include операторов в C ++. Они не ведут себя как операторы импорта в Java или операторы в C #. #include делает то, что говорит; а именно, загружает и анализирует весь указанный файл как часть текущего модуля перевода. Причина отдельных включений заключается в том, что не нужно тратить время на компиляцию всей стандартной библиотеки в каждом файле. Напротив, утверждения, которые вы пытаетесь заставить #include вести себя как, предназначены просто для целей организации программиста.

#include для управления процессом компиляции; не для разделения использования. (На самом деле, вы не можете использовать отдельные заголовки для принудительного использования отдельно, потому что это нарушит правило одного определения)

tl; dr -> Нет, вы не должны этого делать. #include как можно меньше. Когда ваш проект станет большим, вы поблагодарите себя, если не будете ждать много часов, чтобы скомпилировать свой проект.

Answer 2

Лично я бы рекомендовал включать заголовки только тогда, когда они вам нужны, чтобы явно показать, какие функции требует ваш файл. В то же время это не позволит вам получить доступ к функциям, которые вам могут не понадобиться, например, к функциям, не связанным с целью файла. Конечно, это не страшно, но я думаю, что легче поддерживать и изменять код, когда у вас нет доступа к ненужным функциям / классам; это просто делает его более простым.

Answer 3

Возможно, за это проголосуют, но я думаю, что у вас возникла интересная идея. Вероятно, это немного замедлит компиляцию, но я думаю, что концепция изящна.

Пока вы используете using экономно - только для нужных вам пространств имен - другие разработчики смогут понять, какие классы использовались в файле, взглянув на верхнюю часть. Это не было бы так детально, как просмотр списка #include d файлов, но действительно ли просмотр списка включенных заголовочных файлов действительно очень полезен? Я так не думаю.

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

Answer 4

Я думаю, это будет сбивать с толку. Когда вы пишете на C ++, вы должны избегать того, чтобы он выглядел как Java или C # (или C :-). Я действительно удивляюсь, почему ты это сделал.

Предоставление файла include-all на самом деле не так уж и полезно, поскольку пользователь может легко создать его самостоятельно с использованием фактически используемых частей библиотеки. Затем может быть добавлен в предварительно скомпилированный заголовок, если он используется.

Answer 5

Как сказал @Billy ONeal, главное, что #include - это директива препроцессора , которая вызывает код "^ C, ^ V" (копирование-вставка) кода, что приводит к времени компиляцииувеличение.

Лучшей политикой в ​​C ++ является предварительное объявление всех возможных классов в файлах ".h" и просто их включение в файл ".cpp".Он изолирует зависимости, так как проект C / C ++ будет каскадно перестраиваться при изменении зависимого включаемого файла.

Конечно, компиляторы M $ и его предварительно скомпилированные заголовки, как правило, делают противоположное, заключая в себе то, что вы предлагаете.Но любой, кто пытался перенести код на эти компиляторы, хорошо знает, насколько он вонючий.

Некоторые библиотеки, такие как Qt, широко используют предварительные объявления.Посмотрите на него, чтобы понять, нравится ли вам его вкус.