deprecated начиная с v4.0, просто вопрос был немного в другой плоскости, как, соответственно и ответ .


Почти не сказывается при использовании PCH .

Добавлено через 39 секунд
На всякий случай: PCH - это precompiled headers .

  ну, я, например, precompiled headers не юзаю. Имхо, слишком много геморроя и неоднозначностей.


Так что +много, и + проект "чище".

К примеру? 0_о
Я знаю только одну с ними проблему(точнее баг, и тот, скорее всего, уже исправлен в более свежих версиях).

давно как-то раз связался. И потом наткнулся на очень странные сообщения компилятора - то файл он не находит, то ещё что-то. Уже не помню.
Бага, не бага, но пока я с ними связываться не хочу.
субъективная психологическая установка, если хотите

M archimed7592

Сообщения разделены из темы [QT4] компилится но не работает

Добавлено через 3 минуты и 1 секунду

Ммм... Просто для использования PCH есть несколько простых правил. При их соблюдении - ну, программировать, что ли приятней, когда build не занимает 2-3 минуты(у меня сейчас, к сожалению, очень слабенькая машина - бывает и по 5-7 минут :().

M archimed7592

Тема перенесена из С/С++: Кроссплатформенное программирование, QT/Gtk+/wxWidgets

Ну, как нибудь на досуге надо будет ещё раз попробовать .

Дам пару наводочек(в принципе, всё это можно прочитать в мануале GCC) .
1. В PCH суют уже готовые библиотеки(т.е. "рабочие" заголовки туда засовывать не нужно, ибо при их модификации будет происходит rebuild PCH, что, само по себе, операция достаточно долгая - сравнимо с минутой).
2. Может быть только один PCH.
2. include "PCH.hpp" должно идти первой строчкой(в идеале, ДО первого C/C++ token'а).
3. Компилировать PCH нужно с теми же define'ами и теми же опциями компилятора.

Вот, собственно и всё . Прилагаю архивчик с используемым мною PCH.

PS. Ах, да, чуть не забыл - у qmake есть прекрасная переменная: PRECOMPILED_HEADER(assistant тебе в помощь) .


Присоединённый файл ( Кол-во скачиваний: 15 )
 PCH.rar 1,17 Kb

Собрал свой проект с использованием pch:
real    1m12.063s
user    1m2.440s
sys     0m12.277s

И без использования:
real    1m49.846s
user    1m40.698s
sys     0m13.381s

Процентов 30% экономии времени. Правда, обнаружилась проблема с <boost/bind.hpp> (при линковке куча проблем с _1, _2...) и <boost/date_time/time.hpp> (при создании pch gcc 4.1.2 что-то не понравилось со скобкой в этом файле)

Спасибо за инфу и вообще за обращение внимание на возможность использования PCH...

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

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

Хех. А ты попробуй теперь изменить один файл и опять сделать make ;).



Вот об этой проблеме я и говорил . Только у меня она проявлялась для boost::lambda::.., а с bind никаких проблем нет.
Баг, насколько я понимаю, в обработке gcc анонимных пространств имён. Значит в gcc-4 проблемы с pch тоже остались? А жаль :(.

Добавлено через 2 минуты и 49 секунд

Фишка в том, что схавает он это один раз. В последующем компилировать сами модули будет также быстро, как и msvc(субъективная оценка).

Кстати, у меня gcc pch делал порядка 10 секунд для этого:

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

А вот, когда каждые 40 минут приходится по 5 минут ждать пока каждый модуль "родит" - вот это уже "страшно" .

У меня на слабых машинах другая проблема - 5 минут жду, пока слинкуется   

К сожалению, prelinked headers пока не изобрели .

Правда, я помню долго ждал линковки только один раз, когда, в отладочных целях, поставил ключик -fkeep-inline-functions .

Еще помогает ключик компилятора, который компиляцию распараллеливает (например, -j для gcc). Ну это совет для счастливых обладателей многоядерных систем (ну или хотя бы Р4 с HT). Вот у меня библиотека собиралась где-то полторы минуты, а когдя я про этот ключик узнал, стала за 10 секунд собираться, ибо в машине два четырехъядерных ксеона.
А еще компиляцию по сети распараллеливать можно....


Это сообщение отредактировал(а) SaDFromSpb - 25.11.2007, 02:32

SaDFromSpb, этот ключик имеет какой-нибудь смысл при компиляции одного модуля? Или только когда все модули скопом компилируешь помогает?
Просто, я точно такой же ключик использую, только относительно make - он одновременно запускает компиляцию сразу нескольких модулей(точнее использовал - сейчас p3-1GHz + 768RAM делать этого не позволяют :( ).

А!! блин! Спать уже пора мне! Естественно, этот ключ к make'у относится! Распараллеливается по объектникам, на сколько я могу судить. Следовательно, при компиляции одного - смысла не имеет.

ПыСы: Знатный исходничек должен быть, чтобы единственный объектник из него значительное время компилился.

По make targets, если быть точнее .



Не обязательно. В случае неиспользования PCH необходимо приличное время на парсинг хэдеров. Т.е. вот у меня, даже при размере одного модуля не более 250 строк, он без PCH компилится 15-40 секунд. Вот и посчитай сколько времени у меня идёт пересборка проектика из 50-60 модулей. C PCH 1-2 секунды на модуль. Разница совсем не 30% .

Ага.   


Хм.. Однако ж..  

замеряем. [тесты  приложу в аттаче]

разница ощутима.


теперь пробуем с лямбдой и биндом, #include которых вынесен из pch.hh в *.cpp:
[мне было в ломы читать доку о том как заставить компилить .hpp в .gch и йа тупо переименовал файл]

ыыыы. 

Однако как-то неприятно что boost.bind, помещенный в pch.hpp приводит к ошибкам линковки. 
Вот допустим, изменили мы исходники, компилируем, линкуем, и тут оп-па. ошибки. 
Вот сиди как дурак и думай, это ты накосячил, или pch.


Зато изобрели incremental link  


Это сообщение отредактировал(а) Mayk - 25.11.2007, 06:43

Присоединённый файл ( Кол-во скачиваний: 4 )
 pch.tar.bz2 7,49 Kb

а я придерусь к

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


все это не мои идеи, а нагло спертые с книги "Шаблоны C++ Справочник разработчика" 

Это сообщение отредактировал(а) Alek86 - 25.11.2007, 08:48

Alek86, ограничение в один PCH накладывает qmake.

Добавлено через 3 минуты и 17 секунд

У меня такого ключика нет. Но тормозит так дико именно на сборке проекта для отладки (хотя, релиз там собирать не пробовал).

Не только .


Видишь ли... Ты можешь насоздавать с десяток PCH, но если взять произвольный модуль, то в нём должен использоваться только один PCH. Это очень ясно прописано в мануале GCC(и ограничение qmake тут не при чём - более одного PCH не позволяет и MSVC).

цитата из "Cpp Templates The Complete Guide" глава 6.5

я неправильно прочел? тут другой смысл?

Смысл тут такой, что делать слои из PCH.
Я же говорил о следующей ситуации: допустим, ты отдельно прекомпильнёшь std.hpp, отдельно Qt.hpp и напишешь в модуле

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

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



почему нельзя чужие? они ж тоже меняются (но намного реже) - их прекомпилять и надо

Я не пробовал использовать "слоевую" организацию PCH - если при компиляции рабочих хэдеров действительно получится reuse'ить уже готовый PCH, содержащий std,Qt,Boost и пр. либы, которые, то это просто прекрасно(тогда понимаю, почему bsa сказал, что ограничение на один PCH - это у qmake).


Да... не всегда намного реже . Зависит от политики делания commit'ов.

Я просто посмотрел, команду компиляции g++ с использованием PCH и без. Отличие только одно - добавляется -include debug/projectname.gch, где debug/projectname.gch - это такой каталог, в котором создается файл "c++", размером под сотню мегабайт. В описании опции -include в мане gcc сказано, что она аналогична инструкции препроцессора #include в тексте программы. Отсюда напрашивается вывод, что можно указывать больше директив компилятора -include для каждого набора заголовков... Но что-то мне подсказывает, что для одного модуля не стоит использовать более одного прекомпилированного заголовка.

http://gcc.gnu.org/onlinedocs/gcc/Precompi...ompiled-Headers

Там же ещё несколько правил, относительно корректного использования pch.

Не понял это где в хидере или реализации?

В реализации.

в случае с gcc, на сколько я понял, делать #include "pch.hpp" совсем не обязательно. Если сделать, то хуже не будет (если "стражи" не забыты).

под windows да
под linux почему-то не работает(может ключики какие-то нужны?)

dix75, что именно не работает? не работает, когда нет #include  "pch.hpp"?

bsa, 
Я под виндой ничего не добавлял 
т.е. не добавлял #include  "pch.hpp" эту строчку в реализации
но под linux так неполучалось
Сейчас все заработало