Я вам даже пример привёл.

так писать не надо, в этом и суть

В моём же примере из предыдущего комментария не помогло.

потому что смотрите на годболте (где показывается аутпут компилятора, а не всего процесса компиляции) и не прокинули флаг линкеру

Не подскажете название? В таких деталях я не спец.

этим занимается линкер, ему флаг и передавайте, со стороны компилятора -ffunction-sections

Вполне нормальная ситуация при 

неправильном коде

 Даже NDR'ность бесконечного цикла без сайд-эффектов

это не IFNDR, а undefined behavior

 (и лишнюю функцию он вырезал, в отличие от плюсов).

кто это сказал, что она лишняя? Добавите флаг, чтобы он мержил одинаковые функции - он будет мержить, иначе это некорректно например из-за адресов функций.

Если у вас появляются функции с одинаковым содержанием, то вы что-то делали не так

Процессорные. typeinfo достаточно часто кладётся компилятором прямо рядом с vtbl, так что попадает и засоряет, если vtbl используется. А там и имя типа, например, есть, которое может занимать килобайты в случае какой-нибудь темплейтной хренотени.

интересное у вас понимание кешей, наверное процессор сидит и думает, ну вот втейбл же, наверное надо и имя загрузить, целиком, ну на всякий случай

 хаскеле в виде TH

В хрусте

В языках с QTT в 0-аннотированном фрагменте

какое потрясающее перечисление широкоиспользуемых языков

Куча NDR описана именно так потому, что их надёжная диагностика (в смысле decision problem) эквивалентна проблеме останова.

куча связана с тем что есть независимые TU, немного связано с формальностями в шаблонах, вот и всё

 Ему про модули говоришь, а он всё в терминах хедеров и текстового препроцессора думает.

в статье чётко написано, "Глобальный неймспейс" "непересекающиеся имена, что вам что их написать что ли"

ill-formed, no diagnostic required.

в условиях одного TU эта проблема как раз исчезает, т.к. компилятор может диагностировать всё

то тут где вопрос компилятору?

всё что вы перечислили это команды для нахождения каких то файлов, которые к языку никакого отношения не имеют. Уже потом билд система спрашивает у компилятора какие зависимости у конкретного .cpp файла

параллельная (независимая) компиляция, отсутствие перекомппиляции всего, если ты изменил реализацию, гибкость - можно пожертвовать инкрементальной компиляцией и ускорить сборку

и откуда компилятор узнает кто у вас составляет "локальный проект"? А про хедеры подключаемые несколько раз что он скажет? Что будет с инкрементальной компиляцией? И почему вы при таком подходе не сделаете unity сборку, которая соберёт все .cpp в один файл?

С одной стороны это хорошо, ведь это можно эффективно использовать как ключ с эффективным сравнением - нам не нужно проверять две строки посимвольно, достаточно сравнить указатель.

ну, вообще-то нет...

 изменить стратегию компиляции? Решение буквально очевидно

расскажете "очевидное" решение? Стратегия компиляции из С проста и гениальна, у неё куча преимуществ. Я так понимаю автор предлагает какой то "глобальный неймспейс" в котором, видимо, весь С++ код мира собран, иначе откуда компилятор поймёт что там есть неизвестно

Проблемы со специализациями решаются элементарным правилом, не делать специализации хрен знает где в .cpp файле, а делать либо в том файле где объявлен тип, либо в том где объявлено то что специализируют

а если на С++ написать функцию которая это делает, то окажется можно сделать за одну строку:

make_what_we_need();

люди как будто не понимают, что этот дсл надо ещё реализовать

это какой то уже бред в активной стадии, под перфоманс написать свой язык и компилятор

в прошлый раз когда этот код появлялся в комментариях уже предлагали

auto [data, lock] = d.modify();

но видимо код был идеален и поэтому не изменился

предложенный подход вовсе никак не решает проблемы, где нужно распараллеливание. Это совсем другие задачи и мьютексов с кондварами там быть не должно

Дальше, ещё конкретнее про реализацию. Совершенно неочевидные наборы перегрузок:

    inline void view(std::function<void(const T&)> block) const {
        LockRead lock(_mutex);
        block(_state);
    }

    template<typename R>
    inline R view(std::function<R(const T&)> block) const {
        LockRead lock(_mutex);
        return block(_state);
    }

вторая перегрузка никогда не выберется (пока вы не проведёте нетривиальные манипуляции), потому что для вывода типа нельзя делать вывод типа. Более того, она вовсе не нужна, достаточно просто

return (R)block(_state) это сработает и с void с и другими типами

https://godbolt.org/z/59cazh9dE

Почему подобной перегрузки с возвращением значения из modify нет - не знаю, кажется очень странным

Не первый раз вижу этот код и снова повторю, во-первых, подход заставляет компилировать вместо N типов данных и K мьютексов все N * K пар мьютекс - данные, но это самая малая проблема.

Ещё такой подход сильно провоцирует гонки апи, когда взяли лок и достали например .empty() у вектора, а дальше сделали лок и .pop_back, а вектор уже пуст. В общем не получится у вас "не думать" когда пишете код

Факт в том, что не должно быть никаких мьютексов в публичном апи, должен быть понятный интерфейс обычного класса, например структуры данных, который этот мьютекс прячет, а уж там вы вряд ли забудете залочить мьютекс + явно подумаете больше над API

Ну и наконец самая главная проблема, что за чертовщина на уровне реализации? Зачем все эти std::function, std::condition_variable_any., прости господи .template extract<packaged_task<....>>? Что с интерфейсом, откуда тут взялись when и подобное? Это что, фьючи?