Здравствуйте, Кодт, Вы писали:
К>Идея топикстартера в том, чтобы не руками заполнять stdafx.h, а автоматически.
идея гнилая имхо, ибо такие неявные (автоматические) инклюды могут сломать компилябельность кода и повлиять на работоспособность программы.
чтобы доводить до автоматизма такие идеи их прежде всего следует опробовать, то есть собрать такой мега-хедер и оценить, есть ли ускорение сборки
мой опыт подсказывает, что скорость сборки можно увеличить с помощью:
1) параллельная сборка (как внутри одного проекта, так и нескольких проектов)
2) SSD диск
3) настроенный stdafx.h для каждой библиотеки
On 14.03.2014 00:03, Кодт wrote:
> Смысл в том, что файл разбивается на "до прагмы" и "после прагмы", и то, > что до прагмы, не перекомпилируется каждый раз.
> Вообще, штука удобная, и использовалась ещё в борланд С++.
Ну, я как бы "боевой таракан", но тем не менее hdrstop никогда
сознательно не пользовался, и немного потерял.
Вообще, класть что-то изменяемое в данном проекте в stdafx.h -- это
как-то неправильно. Возможно, существуют какие-то резоны для этого,
но я их не знаю.
Так я о том и говорил. Если stdafx.h включается условно, например, в
зависимости от платформы, то второй #include <vector> уже "сработает"
(раскроется в код) и модуль будет компилироваться.
> Идея топикстартера в том, чтобы не руками заполнять stdafx.h, а > автоматически.
Я её до сих пор не понял.
Я могу представить только один сценарий, когда это нужно (как было у
нас) -- тонны кода, неверно оформленного, и хочется выкинуть
существующие stdafx.h и заполнить их заново. Но кстати это не всегда
будет работать -- если модули "третьего рода", как это называлось в
Rational Rose, то нужные заголовки могут быть только в старом stdafx.h.
> На машине разработчика, где некоторые хедеры библиотечные, а некоторые > часто меняются, наполнить allheaders.h (или stdafx.h напрямую) > зависимостями — это значит перекомпилировать каждый раз вообще всё.
Это вот как-то похоже уже на ересь... Зачем использовать разные
заголовки ? Не потерпеть девелоперу в первый раз 20 секунд лишних ?
Не понимаю...
Здравствуйте, uzhas, Вы писали:
U>Здравствуйте, Кодт, Вы писали:
К>>Идея топикстартера в том, чтобы не руками заполнять stdafx.h, а автоматически. U>идея гнилая имхо, ибо такие неявные (автоматические) инклюды могут сломать компилябельность кода и повлиять на работоспособность программы. U>чтобы доводить до автоматизма такие идеи их прежде всего следует опробовать, то есть собрать такой мега-хедер и оценить, есть ли ускорение сборки U>мой опыт подсказывает, что скорость сборки можно увеличить с помощью: U>1) параллельная сборка (как внутри одного проекта, так и нескольких проектов) U>2) SSD диск
тут вы заблуждаетесь. Даже RamDrive дает всего 14% производительности: http://habrahabr.ru/post/117670/
искать фразу "Весь проект — на RamDrive" U>3) настроенный stdafx.h для каждой библиотеки
это как? для каждого проекта в решении — можно. так и планируется. даже есть идея для эксперимента в stdafx включить только внешние h и использовать единый pch для всех проектов, коих в решении за 300. но C++ где-то до 200.
Кстати, все в решении около 2800 h файлов и около 2500 cpp файлов, итого около 5 400 h+cpp файлов
U>ну и замедляется сборка от шаблонов, как ни крути
Здравствуйте, MasterZiv, Вы писали:
>> Идея топикстартера в том, чтобы не руками заполнять stdafx.h, а >> автоматически.
MZ>Я её до сих пор не понял. MZ>Я могу представить только один сценарий, когда это нужно (как было у MZ>нас) -- тонны кода, неверно оформленного, и хочется выкинуть MZ>существующие stdafx.h и заполнить их заново. Но кстати это не всегда MZ>будет работать -- если модули "третьего рода", как это называлось в MZ>Rational Rose, то нужные заголовки могут быть только в старом stdafx.h.
сейчас stdafx нет вообще, precompiled headers not used.
Кстати, как реализуются pch на других компиляторах, вроде xcode? будут ли работать pch для студии на каком-нибудь xcode?
Здравствуйте, uzhas, Вы писали:
U>Здравствуйте, Кодт, Вы писали:
К>>Идея топикстартера в том, чтобы не руками заполнять stdafx.h, а автоматически. U>идея гнилая имхо, ибо такие неявные (автоматические) инклюды могут сломать компилябельность кода и повлиять на работоспособность программы. U>чтобы доводить до автоматизма такие идеи их прежде всего следует опробовать, то есть собрать такой мега-хедер и оценить, есть ли ускорение сборки
...
эксперименты в ручном режиме проводились на прошлой работе и результат был — ускорение Build в разы. но там были небольшие проекты, правда в большом количестве. небольшие у меня это до 50 cpp файлов
Здравствуйте, SVV, Вы писали:
SVV>тут вы заблуждаетесь. Даже RamDrive дает всего 14% производительности: http://habrahabr.ru/post/117670/ SVV>искать фразу "Весь проект — на RamDrive"
я не могу заблуждаться в своем личном опыте
речь не про проект на RamDrive, а про проект и система на SSD
беда с невозможностью параллельной линковки остается
Здравствуйте, uzhas, Вы писали:
U>Здравствуйте, SVV, Вы писали:
SVV>>тут вы заблуждаетесь. Даже RamDrive дает всего 14% производительности: http://habrahabr.ru/post/117670/ SVV>>искать фразу "Весь проект — на RamDrive"
U>я не могу заблуждаться в своем личном опыте U>речь не про проект на RamDrive, а про проект и система на SSD
я недавно специально приносил SSD на работу для тестов. исходники и выходные файлы были на SSD. скорость не увеличилась. запуск билда — скриптом. другое дело что паралельная с билдом работа сильно тормозит компьютер в случае обычного HDD и все ok когда есть SSD.
У меня на рабочем компьютере 16 Гб памяти и компиляция была повторная (но после clean), соответственно совсем все могло быть закэшировано.
U>беда с невозможностью параллельной линковки остается
даже для разных проектов?
On 14.03.2014 13:21, SVV wrote:
> сейчас stdafx нет вообще, precompiled headers not used. > Кстати, как реализуются pch на других компиляторах, вроде xcode? будут > ли работать pch для студии на каком-нибудь xcode?
GCC вроде не поддерживает (gcc вообще достаточно медленно компилирует --
парни не паряца, и в общем, правильно).
Intel-овый вроде бы поддерживает и эмулирует функционал MS C.
