Здравствуйте, netch80, Вы писали:

V>>Когда компилишь либы с опцией link-time code generation, то бинарники таких библиотек резко больше исходников получаются.
V>>А это примерно оно и есть.
N>Это не "примерно то", это совсем иное — фактически вшиты распарсенные исходники (ну, возможно, во всяких IR).

О чем и речь, в модулях будет аналогично, иначе как ты шаблонные/инлайные/auto-функции сохранишь в модуле?


V>>Где в исходнике при вызове шаблонного метода используется автовыводимый тип аргумента, который явно нигде не упоминается, там в бинарнике многоэтажное декорированное имя типа выражения присутствует явно.
N>В секции имён, на которую стоит смещение (пусть 8 байт всегда). Или в COFF иначе?

Все эти шаблонные имена по большей части одноразовые в модуле.
Т.е. есть кучерявое имя автовыведенного типа, его аттрибуты, его хранение где-то в модуле и ссылка на него указателем 8 байт или индексом 4 байт из метаинформации аргумента.

Т.е., куча модулей, использующих, допустим, стандартную либу, использует один и тот же vector с одними и теми же типами-аргументов и всю эту кучерявую шаблонность каждый модуль будет у себя повторять. В то время как при компиляции их же h-файлами одинаковые определения "склеиваются".

Собсно, при реализации известной "модульной" технологии на С++ — COM, они с похожим столкнулись сразу же в плане vtable, что MS даже ввела в С++ __declspec(selectany), чтобы подавлять ругань линковщика на бесконечные доступные варианты одного и того же.

Здравствуйте, netch80, Вы писали:

V>>Когда компилишь либы с опцией link-time code generation, то бинарники таких библиотек резко больше исходников получаются.
V>>А это примерно оно и есть.
N>Это не "примерно то", это совсем иное — фактически вшиты распарсенные исходники (ну, возможно, во всяких IR).

О чем и речь, в модулях будет аналогично, иначе как ты шаблонные/инлайные/auto-функции сохранишь в модуле?


V>>Где в исходнике при вызове шаблонного метода используется автовыводимый тип аргумента, который явно нигде не упоминается, там в бинарнике многоэтажное декорированное имя типа выражения присутствует явно.
N>В секции имён, на которую стоит смещение (пусть 8 байт всегда). Или в COFF иначе?

Все эти шаблонные имена по большей части одноразовые в модуле.
Т.е. есть кучерявое имя автовыведенного типа, его аттрибуты, его хранение где-то в модуле и ссылка на него указателем 8 байт или индексом 4 байт из метаинформации аргумента.
И всё это в сравнении с отсутствующим упоминанием типа в исходнике. ))

Еще. Куча модулей, использующих, допустим, стандартную либу, использует один и тот же vector с одними и теми же типами-аргументов и всю эту кучерявую шаблонность каждый модуль будет у себя повторять, т.е. при загрузке определения модулей в памяти скорее всего будет много дублирующей информации. В то время как при компиляции их же h-файлами одинаковые определения "склеиваются".

Собсно, при реализации известной "модульной" технологии на С++ — COM, они с похожим столкнулись сразу же в плане vtable, что MS даже ввела в С++ __declspec(selectany), чтобы подавлять ругань линковщика на бесконечные доступные варианты одного и того же.