Наличие подобного проекта в портфолио выгодно отличает вас среди других кандидатов при поиске работы, демонстрируя ваш уровень владения языком и умение разрабатывать сложные системы.
Провал. Даже если не провал и это каким-то образом дотянут до реальности, то так будет лишь хуже.
Питон станет ещё медленнее, ещё кривее, ещё сложнее. Никто серьёзный это использовать не станет, будут брать старую версию питона и многопроцесность, просто потому что беря эту версию "питона" они будут получать замедление в десяток раз в каждом потоке. Брать лок на обращение к втейблу / референс каунту 'true'... Ух
Из изначального кода в статье можно просто удалить лишнее - конструкторы, заменить iostream на format, получится буквально тот код который вы и с кинули (только без непонятного shapes ~=)
(и лишнюю функцию он вырезал, в отличие от плюсов).
кто это сказал, что она лишняя? Добавите флаг, чтобы он мержил одинаковые функции - он будет мержить, иначе это некорректно например из-за адресов функций.
Если у вас появляются функции с одинаковым содержанием, то вы что-то делали не так
Процессорные. typeinfo достаточно часто кладётся компилятором прямо рядом с vtbl, так что попадает и засоряет, если vtbl используется. А там и имя типа, например, есть, которое может занимать килобайты в случае какой-нибудь темплейтной хренотени.
интересное у вас понимание кешей, наверное процессор сидит и думает, ну вот втейбл же, наверное надо и имя загрузить, целиком, ну на всякий случай
хаскеле в виде TH
В хрусте
В языках с QTT в 0-аннотированном фрагменте
какое потрясающее перечисление широкоиспользуемых языков
Ему про модули говоришь, а он всё в терминах хедеров и текстового препроцессора думает.
в статье чётко написано, "Глобальный неймспейс" "непересекающиеся имена, что вам что их написать что ли"
ill-formed, no diagnostic required.
в условиях одного TU эта проблема как раз исчезает, т.к. компилятор может диагностировать всё
то тут где вопрос компилятору?
всё что вы перечислили это команды для нахождения каких то файлов, которые к языку никакого отношения не имеют. Уже потом билд система спрашивает у компилятора какие зависимости у конкретного .cpp файла
параллельная (независимая) компиляция, отсутствие перекомппиляции всего, если ты изменил реализацию, гибкость - можно пожертвовать инкрементальной компиляцией и ускорить сборку
эх если бы вы знали, что наоборот система сборки спрашивает компилятор что является зависимостями проекта. Иначе, например, поведение языка зависело бы от системы сборки, а не от компилятора
Ворнинг скажет, что модульимпортируется дважды, и второй импорт не нужен
а он нужен, не все хедеры pragma once, у них гораздо больше применений
То же, что сейчас в языках с более-менее нормальной модульной системой.
и что же там? Ах да, скриптовые языки там, вот что. Либо всё очень плохо с инкрементальностью
Потому что тогда и инкрементальной компиляции не будет, и с анонимными неймспейсами надо быть сильно аккуратнее.
в вашей системе тоже не будет, юнити сбокра нужна для одноразового билда, а уж про неймспейсы с вашей системой "глобальности" всех имён среди всех хедеров и говорить нечего
и откуда компилятор узнает кто у вас составляет "локальный проект"? А про хедеры подключаемые несколько раз что он скажет? Что будет с инкрементальной компиляцией? И почему вы при таком подходе не сделаете unity сборку, которая соберёт все .cpp в один файл?
С одной стороны это хорошо, ведь это можно эффективно использовать как ключ с эффективным сравнением - нам не нужно проверять две строки посимвольно, достаточно сравнить указатель.
изменить стратегию компиляции? Решение буквально очевидно
расскажете "очевидное" решение? Стратегия компиляции из С проста и гениальна, у неё куча преимуществ. Я так понимаю автор предлагает какой то "глобальный неймспейс" в котором, видимо, весь С++ код мира собран, иначе откуда компилятор поймёт что там есть неизвестно
Проблемы со специализациями решаются элементарным правилом, не делать специализации хрен знает где в .cpp файле, а делать либо в том файле где объявлен тип, либо в том где объявлено то что специализируют
это прямая цитата из статьи
Наличие подобного проекта в портфолио выгодно отличает вас среди других кандидатов при поиске работы, демонстрируя ваш уровень владения языком и умение разрабатывать сложные системы.
Провал. Даже если не провал и это каким-то образом дотянут до реальности, то так будет лишь хуже.
Питон станет ещё медленнее, ещё кривее, ещё сложнее. Никто серьёзный это использовать не станет, будут брать старую версию питона и многопроцесность, просто потому что беря эту версию "питона" они будут получать замедление в десяток раз в каждом потоке. Брать лок на обращение к втейблу / референс каунту 'true'... Ух
Из изначального кода в статье можно просто удалить лишнее - конструкторы, заменить iostream на format, получится буквально тот код который вы и с кинули (только без непонятного shapes ~=)
так писать не надо, в этом и суть
потому что смотрите на годболте (где показывается аутпут компилятора, а не всего процесса компиляции) и не прокинули флаг линкеру
этим занимается линкер, ему флаг и передавайте, со стороны компилятора -ffunction-sections
неправильном коде
это не IFNDR, а undefined behavior
кто это сказал, что она лишняя? Добавите флаг, чтобы он мержил одинаковые функции - он будет мержить, иначе это некорректно например из-за адресов функций.
Если у вас появляются функции с одинаковым содержанием, то вы что-то делали не так
интересное у вас понимание кешей, наверное процессор сидит и думает, ну вот втейбл же, наверное надо и имя загрузить, целиком, ну на всякий случай
какое потрясающее перечисление широкоиспользуемых языков
куча связана с тем что есть независимые TU, немного связано с формальностями в шаблонах, вот и всё
в статье чётко написано, "Глобальный неймспейс" "непересекающиеся имена, что вам что их написать что ли"
в условиях одного TU эта проблема как раз исчезает, т.к. компилятор может диагностировать всё
всё что вы перечислили это команды для нахождения каких то файлов, которые к языку никакого отношения не имеют. Уже потом билд система спрашивает у компилятора какие зависимости у конкретного .cpp файла
параллельная (независимая) компиляция, отсутствие перекомппиляции всего, если ты изменил реализацию, гибкость - можно пожертвовать инкрементальной компиляцией и ускорить сборку
эх если бы вы знали, что наоборот система сборки спрашивает компилятор что является зависимостями проекта. Иначе, например, поведение языка зависело бы от системы сборки, а не от компилятора
а он нужен, не все хедеры pragma once, у них гораздо больше применений
и что же там? Ах да, скриптовые языки там, вот что. Либо всё очень плохо с инкрементальностью
в вашей системе тоже не будет, юнити сбокра нужна для одноразового билда, а уж про неймспейсы с вашей системой "глобальности" всех имён среди всех хедеров и говорить нечего
и откуда компилятор узнает кто у вас составляет "локальный проект"? А про хедеры подключаемые несколько раз что он скажет? Что будет с инкрементальной компиляцией? И почему вы при таком подходе не сделаете unity сборку, которая соберёт все .cpp в один файл?
ну, вообще-то нет...
расскажете "очевидное" решение? Стратегия компиляции из С проста и гениальна, у неё куча преимуществ. Я так понимаю автор предлагает какой то "глобальный неймспейс" в котором, видимо, весь С++ код мира собран, иначе откуда компилятор поймёт что там есть неизвестно
Проблемы со специализациями решаются элементарным правилом, не делать специализации хрен знает где в .cpp файле, а делать либо в том файле где объявлен тип, либо в том где объявлено то что специализируют
а если на С++ написать функцию которая это делает, то окажется можно сделать за одну строку:
make_what_we_need();
люди как будто не понимают, что этот дсл надо ещё реализовать
это какой то уже бред в активной стадии, под перфоманс написать свой язык и компилятор
в прошлый раз когда этот код появлялся в комментариях уже предлагали
но видимо код был идеален и поэтому не изменился
предложенный подход вовсе никак не решает проблемы, где нужно распараллеливание. Это совсем другие задачи и мьютексов с кондварами там быть не должно