Для новичков про stdafx.h

    StdAfx.h, Precompiled headers
    Статья рассчитана на людей, которые знакомятся со средой Visual Studio и пытаются компилировать в ней свои Си++-проекты. В незнакомой среде всё кажется странным и непонятным. Особенно новичков раздражает файл stdafx.h, из-за которого возникают странные ошибки во время компиляции. Очень часто всё заканчивается тем, что новичок долгое время везде старательно отключает Precompiled Headers. Чтобы помочь людям разобраться что к чему, и была написана эта статья.

    Для чего нужны Precompiled Headers


    Precompiled headers предназначены для ускорения сборки проектов. Обычно программисты начинают знакомиться с Visual C++, используя крошечные проекты. На них сложно заметить выигрыш от precompiled headers. Что с ними, что без них, на глаз программа компилируется одинаковое время. Это добавляет путаницы. Человек не видит для себя пользы от этого механизма и решает, что он для специфичных задач и ему никогда не понадобится. И иногда считает так многие годы.

    На самом деле, precompiled headers весьма полезная технология. Пользу от него можно заметить, даже если в проекте всего несколько десятков файлов. Особенно выигрыш становится заметен, если используются такие тяжёлые библиотеки как boost.

    Если посмотреть *.cpp файлы в проекте, то можно заметить, что во многие включаются одни и те-же наборы заголовочных файлы. Например, <vector>, <string>, <algorithm>. В свою очередь, эти файлы включают другие заголовочные файлы и так далее.

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

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

    На самом деле, делается ещё ряд шагов. Можно хранить не просто текст, а более обработанную информацию. Я не знаю, как именно устроено в Visual C++. Но, например, можно хранить текст уже разбитый на лексемы. Это ещё больше ускорит процесс компиляции.

    Как работают Precompiled Headers


    Файл, который содержит precompiled headers, имеет расширение ".pch". Имя файла обычно совпадает с названием проекта. Естественно, это и другие используемые имена можно изменить в настройках. Файл может быть весьма большим и зависит от того, как много заголовочных файлов в нём раскрыто. Например, в проекте PVS-Studio он занимает около 3 мегабайт.

    Файл *.pch возникает после компиляции stdafx.cpp. Файл собирается с ключом "/Yc". Этот ключ как раз и говорит компилятору, что нужно создать precompiled headers. Файл stdafx.cpp может содержать одну строчку: #include «stdafx.h».

    В файле «stdafx.h» находится самое интересное. Сюда нужно включить заголовочные файлы, которые будут заранее препроцессироваться. В качестве примера, вот файл stdafx.h, используемый нами в PVS-Studio (файл сокращён для статьи):
    #include "VivaCore/VivaPortSupport.h"
    //For /Wall
    #pragma warning(push)
    #pragma warning(disable : 4820)
    #pragma warning(disable : 4619)
    #pragma warning(disable : 4548)
    #pragma warning(disable : 4668)
    #pragma warning(disable : 4365)
    #pragma warning(disable : 4710)
    #pragma warning(disable : 4371)
    #pragma warning(disable : 4826)
    #pragma warning(disable : 4061)
    #pragma warning(disable : 4640)
    #include <stdio.h>
    #include <string>
    #include <vector>
    #include <iostream>
    #include <fstream>
    #include <algorithm>
    #include <set>
    #include <map>
    #include <list>
    #include <deque>
    #include <memory>
    #pragma warning(pop) //For /Wall

    Директивы "#pragma warning" нам нужны, чтобы избавиться от предупреждений, выдаваемых на стандартные библиотеки.

    Теперь во все файлы *.c/*.cpp следует включить «stdafx.h». Заодно стоит удалить из этих файлов заголовки, которые уже включаются с помощью «stdafx.h».

    А что делать, если используются хотя и похожие, но разные наборы заголовочных файлов? Например, такие:
    • Файл A: <vector>, <string>
    • Файл B: <vector>, <algorithm>
    • Файл C: <string>, <algorithm>
    Нужно делать отдельные precompiled headers? Так сделать можно, но не нужно.

    Достаточно сделать один precompiled header, в котором будут раскрыты <vector>, <string> и <algorithm>. Выигрыш от того, что при препроцессировании не надо читать множество файлов и вставлять их друг друга намного больше, чем потери на синтаксический анализ лишних фрагментов кода.

    Как использовать Precompiled Headers


    При создании нового проекта Wizard в Visual Studio создаёт два файла: stdafx.h и stdafx.cpp. Именно с помощью них и реализуется механизм precompiled headers.

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

    В *.c/*.cpp файле можно использовать только один precompiled header. Однако, в одном проекте может присутствовать несколько разных precompiled headers. Пока будем считать, что он у нас только один.

    Итак, если вы воспользовались wizard-ом, то у вас уже есть файлы stdafx.h и stdafx.cpp. Плюс выставлены все необходимые ключи компиляции.

    Если в проекте не использовался механизм precompiled headers, то давайте рассмотрим, как его включить. Предлагаю следующую последовательность действий:
    1. Во всех конфигурациях для всех *.c/*.cpp файлов включаем использование precompiled headers. Это делается на вкладке «Precompiled Header»:
      1. Выставляем для параметра «Precompiled Header» значение «Use (/Yu)».
      2. Для параметра «Precompiled Header File» указываем «stdafx.h».
      3. Для параметра «Precompiled Header Output File» указываем "$(IntDir)$(TargetName).pch".
    2. Создаём и добавляем в проект файл stdafx.h. В дальнейшем, в него мы будем включать те заголовочные файлы, которые хотим заранее препроцессировать.
    3. Создаём и добавляем в проект файл stdafx.cpp. В нём одна единственная строка: #include «stdafx.h».
    4. Во всех конфигурациях меняем настройки для файла stdafx.cpp. Выставляем для параметра «Precompiled Header» значение «Create (/Yc)».
    Вот мы и включили механизм precompiled headers. Теперь, если мы запустим компиляцию, то будет создан *.pch файл. Однако, затем компиляция остановится из-за ошибок.

    Для всех *.c/*.cpp файлов мы указали, что они должны использовать precompiled headers. Этого мало. Теперь в каждый из файлов нужно добавить #include «stdafx.h».

    Заголовочный файл «stdafx.h» должен включаться в *.c/*.cpp файл самым первым. Обязательно! Иначе всё равно возникнут ошибки компиляции.

    Если подумать, в этом есть логика. Когда файл «stdafx.h» находится в самом начале, то можно подставить уже препроцессированный текст. Этот текст всегда одинаков и ни от чего не зависит.

    Представьте ситуацию, если бы мы могли включить до «stdafx.h» ещё какой-то файл. А в этом файле возьмём и напишем: #define bool char. Возникает неоднозначность. Мы меняем содержимое всех файлов, в которых упоминается «bool». Теперь просто так нельзя взять и подставить заранее препроцессированный текст. Ломается весь механизм «precompiled headers». Думаю, это одна из причин, почему «stdafx.h» должен быть расположен в начале. Возможно, есть и другие.

    Life hack


    Прописывать #include «stdafx.h» во все *.c/*.cpp файлы достаточно утомительно и не интересно. Дополнительно получится ревизия в системе контроля версий, где будет изменено огромное количество файлов. Нехорошо.

    Ещё одно неудобство вызывают сторонние библиотеки, включаемые в проект в виде файлов с кодом. Править эти файлы нет смыла. По правильному для них нужно отключить использование «precompiled headers». Однако, если используется несколько мелких сторонних библиотек, это неудобно. Программист постоянно спотыкается об precompiled headers.

    Есть вариант, как использовать precompiled headers легко и просто. Способ подойдёт не везде и всегда, но мне он часто помогал.

    Можно не прописывать во все файлы #include «stdafx.h», а воспользоваться механизмом «Forced Included File».

    Идём на вкладку настроек «Advanced». Выбираем все конфигурации. В поле «Forced Included File» пишем:

    StdAfx.h;%(ForcedIncludeFiles)

    Теперь «stdafx.h» автоматически будет включаться в начало ВСЕХ компилируемых файлов. PROFIT!

    Больше не потребуется писать #include «stdafx.h» в начале всех *.c/*.cpp файлов. Компилятор сделает это сам.

    Что включать в stdafx.h


    Это очень важный момент. Бездумное включение в «stdafx.h» всего подряд не только не ускорит компиляцию, но и наоборот замедлит её.

    Все файлы, включающие «stdafx.h», зависят от его содержимого. Пусть в «stdafx.h» включен файл «X.h». Если вы поменяете хоть что-то в «X.h», это может повлечь полную перекомпиляцию всего проекта.

    Правило. Включайте в «stdafx.h» только те файлы, которые никогда не изменяются или меняются ОЧЕНЬ редко. Хорошими кандидатами являются заголовочные файлы системных и сторонних библиотек.

    Если включаете в «stdafx.h» собственные файлы из проекта, соблюдайте двойную бдительность. Включайте только те файлы, которые меняются очень-очень редко.

    Если какой-то *.h файл меняется раз в месяц, это уже слишком часто. Как правило, редко удаётся сделать все правки в h-файле с первого раза. Обычно требуется 2-3 итерации. Согласитесь, 2-3 раза полностью перекомпилировать весь проект — занятие неприятное. Плюс полная перекомпиляция потребуется всем вашим коллегам.

    Не увлекайтесь с неизменяемыми файлами. Включайте только то, что действительно часто используется. Нет смысла включать <set>, если это нужно только в двух местах. Там, где нужно, там и подключите этот заголовочный файл.

    Несколько Precompiled Headers


    Зачем в одном проекте может понадобиться несколько precompiled headers? Действительно, это нужно не часто. Но приведу пару примеров.

    В проекте используются одновременно *.c и *.cpp файлы. Для них нельзя использовать единый *.pch файл. Компилятор выдаст ошибку.

    Нужно создать два *.pch файла. Один должен получаться при компилировании C-файла (xx.c), а другой при компилировании C++-файла (yy.cpp). Соответственно, в настройках надо указать, чтобы в С-файлах использовался один precompiled header, а в С++-файлах — другой.

    Примечание. Не забудьте указать разные имена для *.pch файлов. Иначе один файл будет перетирать другой.

    Другая ситуация. Одна часть проекта использует одну большую библиотеку, а другая часть другую большую библиотеку.

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

    Логично сделать два precompiled headers и использовать их в разных участках программы. Как уже отмечалось, можно задать произвольные имена файлов, из которых генерируются *.pch файлы. Да и имя *.pch файла тоже можно изменить. Всё это, конечно, требуется делать аккуратно, но ничего сложного в использовании двух precompiled headers нет.

    Типовые ошибки при использовании Precompiled Headers


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

    Fatal error C1083: Cannot open precompiled header file: 'Debug\project.pch': No such file or directory


    Вы пытаетесь скомпилировать файл, который использует precompiled header. Но соответствующий *.pch файл отсутствует. Возможные причины:
    1. Файл stdafx.cpp не компилировался и, как следствие, *.pch файл ещё не создан. Такое может быть, если, например, в начале очистить проект (Clean Solution), а потом попробовать скомпилировать один *.cpp файл (Compile Ctrl-F7). Решение: скомпилируйте проект целиком или как минимум файл stdafx.cpp.
    2. В настройках ни указано ни одного файла, из которого должен генерироваться *.pch файл. Речь идёт о ключе компиляции /Yc. Как правило, такая ситуация возникает у начинающих, которые захотели использовать precompiled headers для своего проекта. Как это сделать описано выше в разделе «Как использовать Precompiled Headers».

    Fatal error C1010: unexpected end of file while looking for precompiled header. Did you forget to add '#include «stdafx.h»' to your source?


    Сообщение говорит само за себя, если его прочитать. Файл компилируется с ключом /Yu. Это значит, что следует использовать precompiled header. Но в файл не включён «stdafx.h».

    Нужно вписать в файл #include «stdafx.h».

    Если это невозможно, то следует не использовать precompiled header для этого *.c/*.cpp файла. Уберите ключ /Yu.

    Fatal error C1853: 'project.pch' precompiled header file is from a previous version of the compiler, or the precompiled header is C++ and you are using it from C (or vice versa)


    В проекте присутствуют как C (*.c), так и C++ (*.cpp) файлы. Для них нельзя использовать единый precompiled header (*.pch файл).

    Возможные решения:
    1. Отключить для всех Си-файлов использование precompiled headers. Как показывает практика, *.с файлы препроцессируются в несколько раз быстрее, чем *.cpp файлы. Если *.c файлов не очень много, то, отключив precompiled headers для них, вы ничего не потеряете
    2. Завести два precompiled headers. Первый должен создаваться из stdafx_cpp.cpp, stdafx_cpp.h. Второй из stdafx_c.c, stdafx_c.h. Соответственно, в *.c и *.cpp файлах следует использовать разные precompiled headers. Имена *.pch файлов естественно тоже должны различаться.

    Из-за precompiled header компилятор глючит


    Скорее всего, что-то сделано не так. Например, #include «stdafx.h» расположен не в самом начале.

    Рассмотрим пример:
    int A = 10;
    #include "stdafx.h"
    int _tmain(int argc, _TCHAR* argv[]) {
      return A;
    }

    Этот код не скомпилируется. Компилятор выдаст на первый взгляд странное сообщение об ошибке:
    error C2065: 'A' : undeclared identifier

    Компилятор считает, что все, что указано до строчки #include «stdafx.h» (включительно), является precompiled header. При компиляции файла компилятор заменит все, что до #include «stdafx.h» на текст из *.pch файла. В результате теряется строчка «int A = 10».

    Правильный вариант:
    #include "stdafx.h"
    int A = 10;
    int _tmain(int argc, _TCHAR* argv[]) {
      return A;
    }

    Ещё пример:
    #include "my.h"
    #include "stdafx.h"

    Содержимое файла «my.h» не будет использоваться. В результате, нельзя будет использовать функции, объявленные в этом файле. Такое поведение очень сбивает программистов с толку. Они «лечат» его полным отключением precompiled headers и потом рассказывают байки о глючности Visual C++. Запомните, компилятор — это один из наиболее редко глючащих инструментов. В 99.99% случаев надо не злиться на компилятор, а искать ошибку у себя (Proof).

    Чтобы таких ситуаций не было, ВСЕГДА пишите #include «stdafx.h» в самом начале файла. Комментарии перед #include «stdafx.h» можно оставить. Они всё равно никак не участвуют в компиляции.

    Ещё один вариант — используйте Forced Included File. См. выше раздел «Life hack».

    Из-за precompiled headers проект постоянно перекомпилируется целиком


    В stdafx.h включён файл, который регулярно редактируется. Или случайно включён автогенерируемый файл.

    Внимательно проверьте содержимое файла «stdafx.h». В него должны входить только заголовочные файлы, которые не изменяются или изменяются крайне редко. Учтите, что включённые файлы могут не меняться, но внутри они ссылаются на другие изменяющиеся *.h файлы.

    Творится что-то непонятное


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

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

    Это ОЧЕНЬ редкая ситуация. Но она возможна и про неё надо знать. Я за многие годы программирования сталкивался с ней только 2-3 раза. Помогает полная перекомпиляция проекта.

    Проект, использующий precompiled headers не удаётся проверить с помощью PVS-Studio


    Это наиболее частая ситуация, с которой к нам обращаются в поддержку. Подробности изложены в документации: "Устранение неисправностей при работе PVS-Studio". Здесь опишу ситуацию кратко.

    Если решение (solution) компилируется, это вовсе не значит, что оно правильно устроено. Часто одно решение (solution) содержит множество проектов. В каждом проекте используются свои precompiled headers (имеется свой stdafx.h и stdafx.cpp).

    Возникают проблемы, когда начинают использовать файлы из соседнего проекта. Это удобно и так часто делается. Вот только забывают, что в *.cpp файле написано: #include «stdafx.h».

    И, какой из stdafx.h подхватится, это интересный вопрос. Но раз программа компилируется — программисту везёт.

    К сожалению, нам сложно повторить поведение, которое возникает при использовании *.pch файла. «Честный» препроцессор работает по-другому.

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

    За подробностями вновь делаю отсылку к документации. Плюс, если что-то всё равно не ясно, мы подскажем в поддержке.

    Заключение


    Как вы увидели, ничего сложного в precompiled headers нет. Все «многочисленные глюки компилятора», с которыми сталкивается программист при их использовании, на самом деле, являются непониманием принципов работы. Надеюсь, эта статья поможет устранить непонимание.

    Precompiled headers являются очень полезным механизмом, позволяющим существенно увеличить скорость компиляции проектов.
    PVS-Studio
    531.60
    Static Code Analysis for C, C++, C# and Java
    Share post

    Similar posts

    Comments 31

      +9
      Спасибо, за интересную статью. Вот именно из-за отсутствия объяснения подобных вещей я и не освоил C++ в свое время, потому что всех книгах пишут КАК надо написать, а не ПОЧЕМУ так надо написать. А сейчас и не сильно нужно. Жду еще интересных статей о раскрытии магии С++.
        +4
        stdafx.h это не С++ — это привет от microsoft и его жутко настраиваемого монстра в лице студии
          +2
          А почему Вы думаете что только в MS VS это есть? К примеру в 3.20 Using Precompiled Headers или я Вас неправильно понял?
            –2
            Нет, есть конечно, но только VS генерирует подобный файл при создании проекта.
              0
              И правильно делает! ;) Это очень удобная технология и ее знать надо!
                0
                Делает это без объяснений и сильно преждевременно, вот и возникают у новичков траблы с компиляцией и не пониманием нафиг это чудо-юдо нужно
                • UFO just landed and posted this here
                    0
                    Эх… не все новички читают вообще, что в этом визарде написано, и, думаю, не все новички способны провести параллель между флажком «Precompiled Headers» и файлом stdafx.h
        +3
        Спасибо за отличный ликбез.
          +3
          Кроме VS еще кто-то умеет такое?
            +5
            gcc умеет. Если собирать хедеры как-нить так gcc -с xxx.h, то получится на выходе xxx.h.gch, его потом думаю можно аналогично использовать. Но мне всетаки кажется это преждевременной оптимизацией, которая все запутывает.
              +2
              +1
              Спасибо за статью. Хотелось бы уточнить несколько вопросов касательно темы:
              • Как по вашему, допустимо ли в stdafx.h использование конструкции using namespace?
              • Как насчет запихнуть туда (в stdafx.h) набор любимых макросов?
              • Нужно ли делать include guard, для stdafx.h?
                +1
                Как по-вашему, допустимо ли в stdafx.h использование конструкции using namespace?

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

                Как насчет запихнуть туда (в stdafx.h) набор любимых макросов?

                Если они везде нужны, то можно и полезно. Например, у нас в stdafx.h был свой макрос для подавления предупреждений о неиспользуемых переменных. Потом он превратился в функцию, но смысл не поменялся. Функция также живёт в stdafx.h, так как используется повсеместно:
                // UNREFERENCED_PARAMETER от Герб Саттера
                template void PVS_UNREFERENCED_PARAMETER( const T& ) { }

                Нужно ли делать include guard, для stdafx.h?

                Как-то никогда не задумывался над этим вопросом. По идеи, два раза stdafx.h включаться не должен. Он ведь включается один раз в начале *.c/*.cpp файлов. У нас на всякий случай написано "#pragma once". Думаю, лишняя защита не повредит.
                  0
                  В студии есть штатный макрос DBG_UNREFERENCED_LOCAL_VARIABLE(var) и UNREFERENCED_PARAMETER
                  Мы его вставляли в паре сотен мест, когда убирали варнинги 4 уровня в проекта в пару миллионов строк :)
                    0
                    Да, есть такие макросы. Но мы собирали анализатор не только в Visual C++.
                    0
                    GCC и clang ругаются на "#pragma once" в хедере, если он помечен как используемый для precompiled

                    Так что лучше делать так:

                    // pragma once in precompiled header causing a warning in non-MSVC compilers
                    #ifdef _MSC_VER
                    #pragma once
                    #endif // _MSC_VER
                    
                    0
                    Как по вашему, допустимо ли в stdafx.h использование конструкции using namespace?

                    Использование using namespace в любом *.h файле ведет к приятным часам компиляции.
                    У вас есть
                     qq::foo; ww::foo; 
                    потом вы написали
                    using namespace qq; 
                    using namespace ww;
                    а используете просто как foo.

                    Какой из foo должен выбрать компилятор?
                    +2
                    Помню у нас большой проект даже с precompiled headers собирался 45 минут, и я вот тут подумал: а как в Qt? Что там делают, чтобы огромные проекты не собирались неделями?
                      0
                      А там все хорошо, вы точно также можете использовать precompiled headers.
                        +1
                        А почему они должны собираться неделями? Что вы такое собираете?

                        У нас в проекте Chromium для тестов собирается с особыми ключами, там порядка десяти тысяч файлов, сборка с нуля занимает порядка 10 минут, есть сколько-то precompiled headers в third party code, но с ними собирается меньше одного процента файлов.

                        Правда есть одно но: в качестве основной платформы для разработки у нас Linux, а не Windows, в частности потому, что Windows какими примочками не натирай — сборка занимает много больше, чем под Linux. Этак разика в три, если не в пять. Хотя машинки идентичны (Dual Xeon CPU E5-2690, 64GiB RAM).
                          0
                          Странно, что под винду ощутимо дольше сборка. Насколько помню, у Chromium просто гигантская кодовая база, если это все собирается 10 мин — просто чудо)
                          P.S. я говорил про проект, на движке которого, фактически, работали первые версии ДубльГис, в этом внутреннем продукте делалось все: рисование карты, внесение фирм, рекламы, ведение рубрикатора, полный технологический цикл в общем, просто это все было разбито на проекты. Классов примерно 3000.
                            0
                            Не странно. Собираем clang под Windows и под RedHat на одинаковых машинах — под виндой действительно дольше раза в два-три.
                            По поверью, дело в реализации дисковой подсистемы, которая в Windows (изначально интерактивной ОС) оптимизирована под latency, а в Linux (изначально пакетной ОС) — под throughput.
                              0
                              Это не чудо, это норма. А вот тормоза под Windows — это беда. Когда Chrome собирается под Linux, то почти всё время все 32 процессора заняты на 95-99%. Когда же Chrome собирается под Windows, то часто работой загружены 3-5 процессоров, а остальные простаивают. Бог знает чем это чудо в этот момент занято: компиляторов в обоих случаях запущены десятки (ninja всё-таки и там и там), только под Windows они периодически останавливаются «покурить».
                              0
                              Свершилось: PVS-Studio для Linux.
                            +1
                            Отличный ликбез. уверен, что он будет полезен не только новичкам, но и более матерым программистам!
                              +7
                              1. Отличный ликбез.

                              2. Замеры скорости сборки с и без Precompiled Headers будут?

                              3.
                              Идём на вкладку настроек «Advanced». Выбираем все конфигурации. В поле «Forced Included File» пишем:
                              StdAfx.h;%(ForcedIncludeFiles)
                              Теперь «stdafx.h» автоматически будет включаться в начало ВСЕХ компилируемых файлов. PROFIT!
                              Больше не потребуется писать #include «stdafx.h» в начале всех *.c/*.cpp файлов. Компилятор сделает это сам

                              Отличный совет тем, кому потом программу портировать на другую платформу/ос/компилятор…

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

                              Очень громкое заявление, которое ничем не подкреплено. Если разместить проект в оперативной памяти (RAMDisk), то чтение будет очень быстрым. Тем более, что в файл нужно подставить только один инлюд, а с Precompiled Headers будет вставлено очень много мегабайт текста, который нужно еще скомпилировать.

                              5. При наличие большого кол-во проблем, связанных с Precompiled Headers возникает вопрос об их целесобразности. Ну да, они дают N% ускорения, но есть же и другие способы повысить скорость компиляции, которые дадут больше ускорения. Например, если если система сборки cmake, то вместо того чтобы генерировать «MS Solution» можно сгенерировать ninja файл и собрать 1.5 раза*(из личного опыта на большом проекте) быстрее. Разместите файлы на RAMDisk, и вот еще прибавка к скорости, не меняя исходников.

                              6. А если нужно провести рефакторин, то нужно планировать и рефакторинг хидеров, так как они будут либо часто пересобираться либо вообще не нужны. Что опять же усложнит процесс разработки.

                              итого: я не против Precompiled Headers, я призываю подумать 100500 раз и доказать себе, что оно нужно в конкретном проекте и без него совсем ни как.
                                0
                                Хм, а есть замеры скорости сборки с RAMDisk?

                                Из личного опыта: на не очень маленьком проекте с использованием boost, который компилировался около 5 минут, перенос проекта с с boost-ом и другими библиотеками на RamDisk практически не ускорил проект (ускорил, но на еле-еле). О таком же поведении когда-то упоминали на StackOverflow… Операционные системы отлично кэшируют. Ускорял компиляцию другими методами
                              0
                              Спасибо, отличная статья; добавлю в must read для своих подопечных учеников.
                                0
                                Спасибо, интересно.

                                Only users with full accounts can post comments. Log in, please.