Поддержу MasterZiv'а

С традиционно точки зрения, "единица трансляции" это то, что превращается компилятором в объектный файл.
Однако, более общее определение: "минимальный блок исходного текста, который физически можно оттранслировать". Без уточнения оттранслировать во что конкретно...

С другой стороны, если вспомнить о существовании "прекомилированных заголовков", то заголовочные файлы неожиданно превращаются в "единицу трансляции" даже в формальном С (или С++).

Ну а так-как MOC делает трансляцию (.+).h в moc_$1.h и moc_$1.cpp, то получается что файлы перечисленные в HEADERS это действительно "единицы трансляции".

NekZMasterZiv[
С этой точки зрения заголовок QT -- тоже единица трансляции.
Ни разу. В данной формулировке на первом месте идёт "source file", который является корнем для translation unit'а, в который включаются остальные файлы путём директив #include.
В случае Qt хедэра, он вообще логически "оторван" от соответсвующего moc_$1.cpp файла и не удовлетворяет требованию "source file". Это moc_$1.cpp является translation unit'ом, так как инклудит хедэр и имплементит часть его функциональности.
Что значит "оторван"??? Это просто много-шаговая компиляция.
А вообще странно, автогенерацией исходников мы занимаеся уже черти-сколько лет. Некоторые языки вообще не компилируются напрямую а выдают код на Си, который уже и отдается в gcc. OCaml и Haskell например. И что ты назовешь единицей трансляции там?

NekZПредыдущее утверждение базируется строго на основе стандарта C++, мы о нём и говорим сейчас.
Оторван -- значит, что Qt-хедер ничего не знает про moc_$1.cpp (в нём нет директивы #include <moc_$1.cpp>, так?),эээ... а когда это заголовочный файл знал о .cpp файлах??? Или если уж на то пошло, то с чего вдруг .cpp файл должен знать о полученном из него .o файле???
NekZ соответственно, с точки зрения стандарта C++, он не является компилируемой единицей, он не подаётся на вход компилятору. УСЁ!Еще раз напоминаю, что заголовочные файлы могут быть "прекомпилированы", и результат прекомпиляции это вполне себе объектный файл.

NekZВ проект можно понапихать ещё кучу генерённых файлов (из XML в CPP, например), но называть их единицами трансляции -- придумывание никому ненужной терминологии и внесение путаницы. Даже в той же Википедии так написано. Натягивать давно устоявшиеся термины на реальность не нужно.Генерированные файлы, это генерированные файлы. А вот то из чего они сгенерированны и факт что исходники прошли через процесс генерации по отдельности и делает эти исходные файлы единицами трансляции.

NekZWhite OwlГенерированные файлы, это генерированные файлы. А вот то из чего они сгенерированны и факт что исходники прошли через процесс генерации по отдельности и делает эти исходные файлы единицами трансляции.
Если удариться в крайность, то давай представим, что .cpp файлы генерируются на основе окружения, такое ведь может быть. Так что, теперь считать окружение единицей трансляции?То что подается на вход компилятору.


И кстати, если внимательно читать тот кусок стандарта который ты процитировал, то все что включается через #include так же входит в определение.

NekZ,

Думай как хочешь...

Но помни, что: "как вы яхту назовете, так она и поплывет".
И перечитай первый пост этого топика. Как минимум один человек имел проблемы от того что не достаточно точно называл свою яхту.

NekZMasterZivЛЮБЫЕ хедеры НЕ ЯВЛЯЮТСЯ.
QT-шные хедеры, поскольку по ним генерируется код -- ЯВЛЯЮТСЯ.
Ещё раз, как бывший инженер инженеру. Представь крайний случай, что код генерируется на основании окружения ОС или на основе фазы луны из данных обсерватории.
Теперь, окружение ОС и фаза луны теперь тоже являются единицами трансляции?Если они проходят через процесс отдельной компиляции, то да являются.

NekZТы часто оперируешь словом "проект" в своих объяснениях. Однако, в рамках стандарта нет такого понятия.В рамках стандарта очень много чего нет. В стандарте описан только один единственный язык, только один единственный способ использования языка.

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

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

NekZНет, спасибо, я уже вышел из IT и возвращаться не хочется.??? Тогда зачем ты споришь о терминологии?
Причем люди которые этим занимаются профессионально ежедневно говорят "это так", и вдруг человек "вышедший из IT" начинает утверждать "нет, это не так". Ты прокачиваешь скилл тролля?

SiemarglВообще то нет. QT это moc-язык.Не думаю что один дополнительный компилятор имеет право давать название всему языку. Чем uic хуже? Да и через linguist'а тоже можно все исходники прогонять, тогда как через moc только заголовки, так почему не linguist-язык?
Я определяю Qt просто как язык основанный на С++.

SiemarglWhite Owlпропущено...
Не думаю что один дополнительный компилятор имеет право давать название всему языку. Чем uic хуже? Да и через linguist'а тоже можно все исходники прогонять, тогда как через moc только заголовки, так почему не linguist-язык?
Я определяю Qt просто как язык основанный на С++.
Ну вот не знаю, а где проводить границу - С++/прочее, основанное на С++.Расширение языка - это то, что добавляет новый синтаксис в язык. И да, Борланды-Микрософты-ВсеОстальные создавая свой диалект по сути просто расширяют язык.

SiemarglQT moc считать C++? Конечно нет. Это всего-лишь утилита. Компилятор из "расширенного синтаксиса" в классический С++ код.
Когда я говорю что Qt это по существу уже отдельный язык основанный на С++ я базируюсь не только на существовании moc и uic, но и на доступности мета-информации, на существовании сигнально-слотовой системы, на наличии системных синглтонах... Много там всякого есть чего нету в С++, и в чем нужно разобраться чтобы успешно писать на Qt. Но в то-же время, вся стандартная библиотека std уже просто не нужна, так-же нафиг идут все стандарты С++ добавленные в 21-ом веке...
Да, знать базовые принципы С++ для успешного написания приложений на Qt необходимо. Но и не дальше базовых.

Siemarglnim считать С++ ?
rust считать С++ ?Конечно нет. Это самостоятельные языки, для которых (возможно временно) не существует прямых компиляторов в машинный код или в код какой-либо VM.

SiemarglPro*C считать С++ ?А вот этот использует тот-же подход что и Qt с дополнительными внешними прекомпиляторами. В сценарии сборки proc занимает ту-же самую нишу что и moc. Точно так-же как с moc, человек правит один файл, а в с++ компилятор уходит совсем другой.
В то-же время, код в .pc очень похож на стандартный Си и потому, многие считают это расширением языка...

SiemarglКак человек, которому не надо прогибаться под изменчивый мир (с), я просто все отклонения от ISO считаю ересью.

Это конечно не помешает мне применять удобные мне решения =)Считать нечто ересью и использовать это нечто - это не продуктивно.
Во всяком случае, я считаю ересью то, что вызывает у меня отторжение, мне не приятно писать на таких языках и я их ни за что не использую.
А если я что-то применяю, то это уже автоматически переходит из разряда ереси в просто неудобный язык :)