Скорость компиляции в линукс на с++

самая примитивная программа компилится секунд 30.

можешь показать код программы, я замеры проведу у себя.

phc

Какой смысл, если у тебя i7, а у меня старенький i3 c 4 гигабайтами?

самая примитивная программа компилится секунд 30

Не хватает времени кофе попить? Тогда попробуй подключить boost.

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

Просто посмотреть, сколько времени будет компилироваться

1. обычно

2. используя PCH

3. используя модули

Попробуй использовать PCH (или если доступны C++20 модули), это должно сильно помочь…

используя PCH

Это что?

Вот эти все системные шаблоны типа «string», «vector» и проч. они компилятся один раз и лежат в кеше

Нет.

Я думаю, что основное время компиляции уходит на шаблоны, если самая примитивная программа компилится секунд 30.

Да, так и есть.

Скорость компиляции в линукс на с++

А при чём тут линукс? Плюсы везде одинаковые.

1. precompiled headers

2. многопроцессорная параллельная сборка («make -jN»)

3. конпелять в tmpfs

4. Купить процессор для конпеляции, чем больше ядер, тем лучше

Ну цель же обобщить. Иначе пришлось бы под каждый тип данных переписывать портянки кода, а так хочешь целые хранишь в очереди, хочешь строки, хочешь можешь сложные структуры туда же запихнуть.

Хотя по поводу скорости причина в частности в библиотеках и требованиях к шаблонам, в стандартных очень жёстко ставку делают в т.ч. на метапрограммирование, а это может быть весьма приличная вложенная цепочка мета-развёрток.

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

Precompiled header.

1. Выносишь все заголовочники, которые стандартные и из используемых библиотек, то есть те которые не будут меняться во время разработки программ в отдельный файл pch.hpp

2. В каждый cpp файл инклюлишь этот заголовочник первым файлом.

3. Компилируешь заголовочник pch.hpp с теми же оптимизациями как и обычную программу.

g++ -x c++-header -O3 -o pch.hpp.gch -c pch.hpp

4. Компилируешь cpp файлы как обычно и линкуешь как обычно.

Только теперь они будут собираться быстрее, чем без pch.

См. мономорфизация. Академики термин специальный придумали для этого случая.

Понятно, спасибо.

Плюсы везде разные, т.к. зависят от реализации не ОС, а компилятора и библиотек, вспомнить тот же вечнодогоняющий стандарты msvc и часто забагованный gcc и звёздочку clang от которой порой аж голова болит, когда переносишь на неё код, а она умудряется склепать сломаный исполнимый файл.

Какой смысл, если у тебя i7, а у меня старенький i3 c 4 гигабайтами?

вот тут ты написал:

Я думаю, что основное время компиляции уходит на шаблоны

Не мешало бы фактецев, а «я думаю» - это так себе основание. С GCC можно посмотреть при помощи -ftime-report.

Вот у меня, например, на коде со средней степенью «зашаблонности», при компиляции GCC7 самая долгая фаза компиляции - парсинг. А инстанциирование шаблонов - только второй боттлнек, при чем по-разному от файла к файлу, может быть 26%, а может и 44%. Но допустим, в среднем 35% времени. Т.о., если ты как-то соптимизируешь эту долю до 5%, у тебя будет не 30сек, а грубым счетом 20сек. Ну и что, это реально тебе поможет? Спасет отца русской демократии?

возможно это поможет - запрос к гуглу «с++ compilation speed» дает 2.600.000 статей.

Вот эти все системные шаблоны типа «string», «vector» и проч. они компилятся один раз и лежат в кеше, или каждый раз заново?

Мне очень импонирует ваше стремление. Но вынужден разочаровать вас, все обстоит несколько иначе. Если бы вы иногда задумывались над этим, все сразу встало бы на свои места.

Владимир

О модулях. Вообще как будет работать (когда они наконец нормально появятся), компилишь обычным способом

gcc -c q.cc -std=c++2.

и получаешь на выходе модуль? Или какая-то доп многостадийная возня вроде той, которая сейчас в clang? Т.е. в планах - модуль замена объектным .o файлам?

Я думаю, что основное время компиляции уходит на шаблоны, если самая примитивная программа компилится секунд 30.

IMHO, это не из-за шаблонов, а из-за отсутствия модульности. В плюсах, как и в б-жественной сишечке, до сих пор вместо модулей костыли на препроцессоре из начала 70-х. Препроцессор делает кучу портянок текста, компилятор компилирует каждую из этих портянок в объектник с кучей неразрешённых зависимостей. и наконец, линкер все эти зависимости разрешает. Методом грубого тыка. С тем, что там было в заголовочных файлах, это разрешение никак не связано.

Даже в примитивном по современным меркам Турбо Паскале образца 1990 года были нормальные модули с явным заданием, что откуда импортируется.

В последнем стандарте плюсов модули, наконец, продавили, но думаю, что захватывать мир они будут ещё лет 10, если не больше. Унаследованный код — это не шутка.

А precompiled headers — это тоже костыли ещё те.

А precompiled headers — это тоже костыли ещё те.

Да это ведь те же модули по сути.

Ещё забыл сказать, что если заголовочники в отдельной папке (типа include), то скомпилированный заголовочник должен лежать в той же папке.

Пример:

g++ -x c++-header -O3 -o include/pch.hpp.gch -c include/pch.hpp

Потом компилируем как будто pch.hpp.gch и не существует…

g++ -O3 -c src/main.cpp -Iinclude -o build/main.o
g++ -O3  build/main.o -o bin/test.exe

используя модули

В STL не завезли. В C++23 только планируют

Тут смотря что понимать под «примитивная программа». Вот у меня есть лаба в, практически, 500 строк, звучит примитивно. Используется std::forward_list, итераторы по std::forward_list, iostream и iomanip

[georgii@snake 7]$ wc -l seven.cpp 
474 seven.cpp
[georgii@snake 7]$ time g++ seven.cpp -g

real	0m0,669s
user	0m0,604s
sys	0m0,064s

Редко нужно пересобирать много, чаще меняются один или два файла - и тогда тормозит линкер
У мну (на уже старом железе) и ~100М итоговом файле с дебугами - линковка идет 6 сек и на голд-линкере 3 сек, что тоже много (ssd)

комитет тоже так решил и в новом С++20 появились модули

target_precompile_headers()

И еще ccache и icecream

Исправь.

чем больше ядер, тем лучше

Типичная ламерская чушь. В компиляции ядра например 16ядерный оптерон капитально сливается 4ядерному zen2, 32ядерный epyc 7532 сливается 24ядерному epyc 7F72.

Как и в компиляции llvm, впрочем.

IMHO, это не из-за шаблонов, а из-за отсутствия модульности.

Нет. Модульность - это примитивная херня попросту не совместимая с нормальным языком.

В плюсах, как и в б-жественной сишечке, до сих пор вместо модулей костыли на препроцессоре из начала 70-х.

Никаких костылей нет. Инклюды - самый совершенный и мощный тип модулей. Там есть пару проблем, но идеальная реализация модулей будет в качестве инклюдов, но не через препроцессор.

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

Объектник для колхозников. Никто в С++ эту чушь не использует, только легаси-дерьмо. А когда создавался си - никаких модулей нигде не было.

К тому же, какая связь между объектниками и инклюдами? Связи никакой нет.

и наконец, линкер все эти зависимости разрешает.

Нет, подобной хернии в С++ нет. Это, опять же, легаси-мусор.

Методом грубого тыка. С тем, что там было в заголовочных файлах, это разрешение никак не связано.

Опять же, зачем пытаться говорить о С++ ничего не зная о С++?

Даже в примитивном по современным меркам Турбо Паскале образца 1990 года были нормальные модули с явным заданием, что откуда импортируется.

В этом и проблема. Ты всё перепутал. Модули - это примитивная херня, которая ваяется за пол часа.

И именно в том, что модули - это мусор - они и есть только в нелепой скриптухи. Когда как С++ скриптухой не является и примитивные модули в нём существовать не могут.

В последнем стандарте плюсов модули, наконец, продавили, но думаю, что захватывать мир они будут ещё лет 10, если не больше. Унаследованный код — это не шутка.

Опять же, неверно. Модули в плюсах - это те же инклюды.

А precompiled headers — это тоже костыли ещё те.

Уровень поражает. Модули, которые являются ничем иным как pch - это хорошо, а сами pch - нет. Ну да, если базворда нет - уже всё плохо. Как же иначе.

Повторю ещё раз. Модули -примитивная херня. В С++ их нет(и никогда не будет) потому, что эта примитивная херня не совместима с нормальным языком. То, что вам где-то рассказывали, то, что вы где-то слышали - ничего общего с реальностью не имеет.

С++ требует импортировать всё ast, как и любой нормальный язык(правда таких почти нет). А импорт всего ast - это инклюд. Единственное, что здесь можно сделать - просто распарсить код и импортировать сразу ast. Это, конечно, не особо что-то даёт. Но хоть что-то.

Поэтому никакие pch не прекомпиленные, а просто распаршенные и не более того.

Полная чушь. Модули никаким образом не влияют и не могут влиять на скорость компиляции. Это убогая мифология.

О модулях. Вообще как будет работать (когда они наконец нормально появятся), компилишь обычным способом

По разному.

и получаешь на выходе модуль?

Нет, очевидно. Это же не бездарная скриптуха.

Или какая-то доп многостадийная возня вроде той, которая сейчас в clang?

Это так и работает, а шланг тут непричём.

Т.е. в планах - модуль замена объектным .o файлам?

Нет, очевидно.

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

Далее идёт херня. Модуль можно разбить на несколько частей. Очевидно, что сам модуль не имеет смысла компилировать - он уже итак инклюдится.

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

Если ты используешь С++ на колхозном уровне(там с объектниками и прочей хернёй) - для тебя ничего не изменится. Будешь создавать модуль-заголовок - будет его собирать так же как pch. Далее один/несколько подмодулей с реализацией. Будешь их так же собирать как cpp. С линковкой всё то же.

Да, мнение студента-эникея все очень сильно волнует. Иди в пистон - что ты здесь забыл?

А нафига, ведь их никто менять не будет.

Срочно в школу за букварь. Они меняются сами.

Я думаю, что основное время компиляции уходит на шаблоны, если самая примитивная программа компилится секунд 30.

Полная и нелепая чушь. К тому же, показывай другой язык с теми же возможностями, который не компилируется 30 маня-секунд. Не сможешь? Ты опозорился.

Я в модули сильно не погружался (толку то, какая-то многолетняя история :) ), но была надежда - что планируется уход от модели отдельной реализиациии от интерфейса (cpp от hh), всё в одно модуле с последущей его компиляцией (постройка AST, да чего угодно). Дальше линкуем main.cc+модули. Тут была бы важная плюшка - возможность оптимизировать код между модулями из коробки. Понятно, что можно все inline + template. Тогда хз чего у народа такая эйфория от слова модули, ожидал большего.

всё в одно модуле с последущей его компиляцией (постройка AST, да чего угодно). Дальше линкуем main.cc+модули.

ты можешь такое делать. забить на разделение, и делать только main.cc + модули.

От того, что ты 4 раза повторил слова «примитивная херня», истиной они не станут.

И именно в том, что модули - это мусор - они и есть только в нелепой скриптухи. Когда как С++ скриптухой не является и примитивные модули в нём существовать не могут.

Pascal, Modula 2, D, Go, Rust. Ты можешь называть их нелепыми, это субъективное определение, но скриптухой они не являются. И во всех этих языках есть модули. (Я уж не буду упоминать Java и C#, поскольку знаю, что начнётся бестолковый спор, что такое скриптуха.)

К тому же, какая связь между объектниками и инклюдами? Связи никакой нет.

Так я об этом и писал. Связи нет, контроля соответственно тоже нет.

Объектник для колхозников. Никто в С++ эту чушь не использует, только легаси-дерьмо

А я вот вижу, как у меня g++ плодит файлы *.o. Это я ЛСД принял, или у тебя g++ тоже «легаси-дерьмо»?

Инклюды - самый совершенный и мощный тип модулей.

Да уж. И проблемы у них не только со скоростью. Распространённая проблема инклюдов — транзитивность. Программист использовал библиотеки A и B, но забыл написать инклюд для B. Но случилось так, что A использовала B, и всё собралось без ошибок. Через полгода обновили версию A, где заголовочники внутри были построены по-другому (хотя внешний интерфейс не поменялся), и B в файле для A не упоминается. Вылезла ошибка.

В том же объектном Паскале (Delphi, fpc), который на ЛОРе принято ненавидеть как «мёртвый язык для школоты», программист бы получил по рукам сразу, поскольку там uses — это не работа с портянками текста, а полноценная конструкция языка, и какой модуль ей указали — строго из него она и импортирует. В виртовской Модуле 2 было ещё круче, там можно было указать конкретно, какие именно имена из модулей импортировать.

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

Тогда это будут уже не инклюды. Суть инклюда — включение одной портянки текста в другую портянку текста без отслеживания, к какой куче кода включаемая куча относится.

но была надежда - что планируется уход от модели отдельной реализиациии от интерфейса (cpp от hh), всё в одно модуле с последущей его компиляцией (постройка AST, да чего угодно).

Проблема в том, что основная ЦА C++ - это легаси-дерьмо. Но проблема даже не в этом, у нас нет нормального компилятора - мы не может запихнуть весь хром в ast. Хотя в какой-то степени это можно сделать даже сейчас, но всю организацию кода нужно переколбашивать. А никто этим заниматься не будет.

Поэтому для рядового легаси-говна и его производных - никак от раздельной компиляции не уйти.

Дальше линкуем main.cc+модули.

Ещё раз, линковка птушный мусор и не может работать в С++. Ты не можешь линковать С++ с С++. Только замангленную сишную дристню с ней же.

А так ты можешь что-то подобное делать. Я об этом говорил выше. Ты можешь точно так же инклюдить модули(хотя они и так все инклюдаться) и просто не разделять их. Точно так же как в ho.

По-сути для тебя модули ничего не поменяют. Будет тоже самое, что ho + pch. Но это даст профит на уровне языка. Т.е. сейчас инклюд не имеет какой-либо семантики на уровне языка. С т.з. языка - это кусок текущего файла. А значит никакие локальные неймспейсы и прочее у тебя не работают.

Модуле же семантически отделены друг от друга. И это позволяет тебе использовать в них локальные неймспейсы и прочие фишки.

Тут была бы важная плюшка - возможность оптимизировать код между модулями из коробки.

Это итак уже есть в ho. И будет в модулях, если ты будешь использовать их как ho.

Тогда хз чего у народа такая эйфория от слова модули, ожидал большего.

Ну это сила пропаганды. Когда все вокруг орут про модули - адепты начинают на них молится.

Могу. Но тут вопрос - рекомендуемый ли это путь или нет? Если да, то по этому пути пойдёт мэйнстрим. И после переезда, например std, бесплатно получим прирост производительность. Иначе просто всего лишь новый формат. Вроде с инкрементальной сборкой + pch всё и так было решаемо.

Pascal, Modula 2, D, Go, Rust.

Всё нелепая скриптуха, вся вместе не обладает и 10% возможностей С++.

Ты можешь называть их нелепыми, это субъективное определение,

Они и есть нелепые. И это объективное определение. Во всех них типизация - примитивное дерьмо. Во всех них нет никаких компилтайм-возможностей. Нету никаких компилтайм-вычислений. Это примитивное дерьмо из 70х.

но скриптухой они не являются.

Являются.

И во всех этих языках есть модули.

Да, потому что модули - примитивное дерьмо. И работает в примитивной скриптухе, коим вся эта нелепость и является.

(Я уж не буду упоминать Java и C#, поскольку знаю, что начнётся бестолковый спор, что такое скриптуха.)

А это ничего не изменит - примитивная херня она везде примитивная херня.

Так я об этом и писал. Связи нет, контроля соответственно тоже нет.

Если связи нет - то какой может быть контроль? Проблема в том, что ты считаешь, что связь есть. И от того рождаются все твои рассуждения. Но её нет, а все твоя представления - не соотносятся с реальностью.

А я вот вижу, как у меня g++ плодит файлы *.o.

И? Во-первых он их не плодит. Во-вторых, очевидно, что гцц совместим с легаси дерьмом и может его плодить. У меня он ничего не плодит.

Это я ЛСД принял, или у тебя g++ тоже «легаси-дерьмо»?

Нет, просто ты не разобрался в теме.

Да уж. И проблемы у них не только со скоростью.

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

Распространённая проблема инклюдов — транзитивность.

Ога.

Программист использовал библиотеки A и B, но забыл написать инклюд для B.

О боже. Я тебе уже сообщил, что никакой нормальный программист никакие библиотеки не использует. Это легаси-говно. С++ с таким не работает и работать не может.

Твои представления несостоятельны.

Но случилось так, что A использовала B, и всё собралось без ошибок.

Никакого отношения не имеет к инклюда. У тебя поломалась методичка. Если ты импортируешь функцию f из модуля, которую он экспортировал из своих кишков из B, то он без проблем может её выпилить и у тебя опять же будет ошибка.

Через полгода обновили версию A, где заголовочники внутри были построены по-другому (хотя внешний интерфейс не поменялся), и B в файле для A не упоминается. Вылезла ошибка.

Как это он поменялся, если поменялся?

В том же объектном Паскале (Delphi, fpc), который на ЛОРе принято ненавидеть как «мёртвый язык для школоты», программист бы получил по рукам сразу, поскольку там uses — это не работа с портянками текста, а полноценная конструкция языка, и какой модуль ей указали — строго из него она и импортирует. В виртовской Модуле 2 было ещё круче, там можно было указать конкретно, какие именно имена из модулей импортировать.

Почему у вас так плохо с логикой. Твои рассуждения примерно эквивалетны следующим. Треснула высотка, приходит колхозник и сообщает - у меня вчера сарай так же треснул. Ну я деревяшку прибил - всё норм. А чего это у тебя проблемы? У меня сарай уже так 40 лет стоит.

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

Тогда это будут уже не инклюды. Суть инклюда — включение одной портянки текста в другую портянку текста без отслеживания, к какой куче кода включаемая куча относится.

Нет, это полная и нелепая чушь. Инклюд - это включение одного куска кода в другой. Та херня, что тебе рассказали где-то про текст - ничего не значит. Абсолютно неважно то, как одно включается в другое.

В конечном итоге у инклюдов в их текущем виде только одна проблема - они не имеют областей видимости. Правда эту проблему никакая мусорная скриптуха не решает - они слишком примитивно, что-бы в ней возникали какие-то проблемы существующие в С++.

И это единственное следствие из их препроцессорной природы.

Могу. Но тут вопрос - рекомендуемый ли это путь или нет? Если да, то по этому пути пойдёт мэйнстрим.

Не пойдёт. Мейнтрим жрёт и всегда жрал дерьмо.

И после переезда, например std, бесплатно получим прирост производительность.

Не получишь. Все адекватные либы, в том числе и std - ho. По другому просто и быть не может. Но мейнтрим продолжает жрать дерьмо.

К тому же, нужно понимать, что все C/С++-адептов обрабатывают легаси и раст(и прочая скриптуха)-сектанты.

В чём суть. Если завтра C++ перейдёт на ho и нормальные модули - всякие говнорасты тут же сдохнут на помойке. Точно так же сдохнет и всё легаси, потому как всякое lto тут же станет ненужно. А т.к. оно пилится С++ для С++, то пилиться перестанет.

Очевидно, что ни те ни другие этого допустить не могут. Поэтому должны оставаться сишная дристня в объектниках, потому как её используют все недоязычки. Все линкеры.

И ни недоязычки, ни легаси - не могут существовать без всего этого. И их задача - убедить тебя в том, что тебе это так же нужно. И нужно жрать дерьмо.

Ты не купился - а 95% С++-адептов купились. Так и живём.

Это те же модули с поправкой на то, что это всё ещё тот же костыль что и модули. Продолжаем ублюдосить на сишечке как и раньше.

Во всех них нет никаких компилтайм-возможностей. Нету никаких компилтайм-вычислений.

Продолжу.

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

Поэтому

Во всех них типизация - примитивное дерьмо.

Вон тебе банальный пример. С++ и его «модули» может жить вне сишной дристни. Т.е. им не нужен линкер, lto, объектики и прочий этот мусор птушный.

Но вот всем упомянутым тобою недоязычкам - всё это нужно. И существуют они лишь потому, что паразитируют на С/С++-инфраструктуре.

В любом случае просто изучи тему и пойми чем отличается скриптуха от С++. Но давай я тебе помогу чутка.

Вот у нас есть функция, f(a, b) => a + b. В любом недоязычке(ну разве что чутка иначе будет в D) - у тебя нету типизации. У тебя уже готовая сигнатура с типами. Во всей этой скриптухе нету вывода типов.

В конечном итоге у тебя есть сигнатура, которую ты импортируешь из модуля. Эта сигнатура валяется где-то в мета-инфе модуля. Это просто птушный символ. А куда-то в объектник кидается уже скомпилированная функция.

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

Но в С++ это так не работает. В С++ есть вывод типов, в С++ есть constexpr - т.е. функция универсальная. В каком-то недорасте есть какая-то пародия на consteval, но оно ничего не может. И ничем не отличается от базового случая. Единственное, что её может исполнить огрызок фронтенда.

Таким образом, все определения в С++ должны быть целиком и полностью доступны. Нельзя свести их к сигнатуре, нельзя их как-то частично компилировать.

У тебя нету никакого выбора - либо ты отказываешься от вывода типов, от типизации, от constexpr. И всего того, что делает С++ С++ и разительно его отличает от скриптухи. И чего нет и никогда не будет в твоей скриптухе.

Т.е. импорт кусков кода, отсутствие компиляции «модулей», «медленная» сборка - это всё следствие не инклюдов как модулей. И никакие модули не могут этого исправить.

И никакие модули из бездарное скриптухе не могут быть использованы в С++. И не используются они в С++ только потому, что это невозможно. А не потому, что их там кто-то не запилил. Они пилятся за пол часа, как я уже говорил.

Во всех них нет компайл-тайм UB

Полная и нелепая чушь.

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

Нет, тебя поимела пропаганда. Никакого UB не существует.

Поэтому

Да, в примитивной скриптухе ничего нет, а тебя поимела пропаганда. Да и многих других.

Допустим никакого УБ не существует и никакого «документированного» поведения тоже. Откуда ты его родил - мне неведомо.

Во всех них нет никаких компилтайм-возможностей. Нету никаких компилтайм-вычислений.

С++ как раз и своровал (после С++98) все компилтайм-возможности из D.

Допустим никакого УБ не существует и никакого «документированного» поведения тоже.

Это твое допущение, ты его должен подтверждать или опровергать.

С++ как раз и своровал (после С++98) все компилтайм-возможности из D.

Нету в D никаких компилтайм-возможностей. К тому же, этот мусор родился во времена 0x, а 0x в крестах прорабатывался ещё с середины нулевых и даже ранее. Меньше жри пропаганды.

Это очередная бездарная скриптуха, которая кое как сваяла примитивную херню и наворовала 0x-идей. Любая из которых на порядок проработанней, чем весь этот недоязычок.

Это твое допущение

Нет, твоё. Иди подтверждай или опровергай. Чего стоишь.

ты его должен подтверждать или опровергать.

Нет, я не должен доказывать отсутствие чего-либо. Это твоя задача. Ретранслируешь пропаганду - отвечай за неё. Не можешь - не болтай.