Я читаю документ A Module System для C++, чтобы понять модули C++, предлагаемую функцию для C++.
Я не могу полностью понять, как шаблоны будут экспортироваться этой архитектурой модуля.
Есть идеи?
Я читаю документ A Module System для C++, чтобы понять модули C++, предлагаемую функцию для C++.
Я не могу полностью понять, как шаблоны будут экспортироваться этой архитектурой модуля.
Есть идеи?
В настоящее время C++ реалии действительно имеют только две "вещи", которые соответствуют коду: исходный код, который мы записываем и редактируем человеком, и сборку, которую компилятор вырывает на основе источника.
Поскольку шаблоны C++ "подтверждены", отдельная сборка выплетается для каждого экземпляра шаблона. По этой причине сборка не может быть произведена там, где определены шаблоны, но только там, где они используются. Вот почему шаблоны должны быть в заголовочных файлах, поэтому они могут в основном копироваться в точку использования (что все #include действительно).
Идея состоит в том, чтобы иметь третье представление кода. Представьте, что внутренне компилятор имеет какое-то внутреннее представление после того, как он проанализировал код, но до того, как он начнет сборку. "Вещь", которую он производит, в конечном итоге представляет собой некоторое представление абстрактного синтаксического дерева (AST). Это в основном именно ваша программа, отображаемая из самой простой для людей формы, в форму, которая проще всего для компьютеров.
Это очень приблизительная идея модулей (или, по крайней мере, их реализация). Вы берете свой код и выплевываете какой-то файл, представляющий АСТ. Этот АСТ является полным представлением вашей программы, поэтому он полностью без потерь. Он знает все о шаблонах, которые вы объявили, и так далее. Когда модуль загружен, он просто загрузит этот файл, и компилятор сможет использовать его точно так же, как если бы у него был весь доступный источник. Но шаг превращения человеческого читаемого источника в этот АСТ - довольно дорогостоящий шаг. Начиная с АСТ может быть намного быстрее.
Если у вас есть только одна единица перевода, это будет медленнее. В конце концов, синтаксический анализ → codegen все еще быстрее, чем синтаксический анализ → serialize → deserialize → codegen. Но скажите, что у вас есть 10 единиц перевода, которые все #include vector. Вы будете анализировать код в векторе 10 раз. На данный момент дополнительные затраты на сериализацию/десериализацию компенсируются тем фактом, что вам нужно разобрать один раз (и десериализация может выполняться намного быстрее, чем синтаксический анализ, этот формат данных будет разработан специально для быстрого десериализации, тогда как исходный код предназначенные для чтения, обратной совместимости и т.д.).
Предварительно скомпилированные заголовки в некотором смысле представляют собой предварительный просмотр модулей: https://clang.llvm.org/docs/PCHInternals.html