Если бы я хотел использовать, например, только std::string
, не был бы импорт (теоретического) std::string
модуля более производительным, чем импорт всей стандартной библиотеки?
Это для простоты использования, поскольку вам придется самостоятельно создавать стандартный библиотечный модуль, а встраивание каждого отдельного компонента в модуль будет утомительным?
Или это связано с какими-то накладными расходами при создании модуля (любого размера), где, если вы импортируете достаточно меньших модулей, это в конечном итоге будет дороже, чем просто импорт одного большого?
std::string используйте std::allocator, например. размещение нового оператора означает, что вам понадобится вся стандартная библиотека C++. Вы можете связать его статически, чтобы окончательный исполняемый файл содержал только функции, которые он действительно использует, в любом случае это не рекомендуется. Разделение стандартной библиотеки C++ на наименьшие модули является предложением стандарта C++ 25.
Оказывается, import std;
на самом деле быстрее, чем одиночный #include
! Насколько я понимаю, компилятор не загружает все в память, а только «каталог», чтобы найти части, которые вы можете использовать позже.
Это явно заговор людей <bits/stdc++.h>
А еще комитет мог бы согласиться, что import std;
следует импортировать все. У них не было времени договориться о том, какие именно модули меньшего размера мы хотели бы использовать. Возможно, позже...
Все, что вы видите, это то, что стандарт развивается, а некоторые его части находятся в стадии разработки. Стандартная библиотека C++ через #include
допускала включение подмножеств начиная с (ранее) C++98. Модули — относительно новая функция, и работа над разрешением импорта подмножеств стандартной библиотеки находится в стадии разработки. Процесс стандартизации для добавления/изменения/удаления частей стандарта не происходит по щелчку пальцев – это обязательный процесс, который начинается с предложения, рассмотрения и развития этого предложения, включения в проект стандарта и, в конечном итоге, ратификация.
Я склонен рассматривать модули как современную, стандартную и гибкую замену предварительно скомпилированных заголовков. Поэтому я счел естественным поместить всю библиотеку STL в один модуль.
ОП, твой вопрос какой-то расплывчатый. Было бы хорошо увидеть два разных оператора импорта/включения, которые вы сравниваете, вместо того, чтобы просто говорить о них в абстрактных терминах.
@DavidGrayson Я имею в виду только один тип оператора импорта - import
. Я сравнивал import std;
и гипотетический import std.string;
.
Долгое время MSVC опережал gcc и clang в реализации модулей. Не уверен, что это все еще так. Что касается import std;
, Microsoft говорит следующее: «Теперь можно импортировать стандартную библиотеку как модуль, а не как набор файлов заголовков. Это намного быстрее и надежнее, чем включение файлов заголовков, модулей заголовков или предварительно скомпилированных заголовков (PCH )" [Выделено нами.]
Согласно новому стандарту вам просто нужно импортировать std. Но это не означает, что в ваш двоичный файл будет добавлен весь STL. Ваш компилятор должен оптимизировать его и «обрезать» все бесполезные ссылки.
Если бы я хотел использовать, например, только std::string, не был бы импорт (теоретического) модуля std::string более производительным, чем импорт всей стандартной библиотеки?
Модули работают не так. Импорт модуля не похож на включение заголовка. Стоимость импорта модуля не пропорциональна количеству содержимого в этом модуле.
Импорт модуля означает, что компилятор считывает некоторые двоичные данные, сообщающие доступные имена. Но весь скомпилированный код модуля не обязательно читать только при импорте. Когда вы используете объект, имя которого экспортируется модулем, компилятор может перейти к этой части скомпилированного файла модуля, чтобы узнать, что в нем находится.
Есть ли ссылка на это конкретное поведение?
@PasserBy: ссылка в стандарте? Стандарт диктует видимое поведение, а не производительность. Так что это выходит за рамки стандарта. Однако в предложении поместить все в один модуль было упомянуто, что именно так реализуется импорт модулей, и что они протестировали его на нескольких реализациях и не заметили заметной потери производительности.
Я знаю, что в стандарте ничего не будет, я имею в виду такие вещи, как предложения или, возможно, выступления авторов компиляторов. И я спрашиваю, потому что вы думаете, что это важная особенность, о которой люди должны знать.
В целом разница в скорости должна быть незначительной. Примечание: это просто объявление (и предварительно проанализированное, поэтому больше нет #include, который читает много файлов и требует большого количества анализа). Речь идет не о связывании и добавлении кода в конечную программу.