Нет принудительной блокировки файлов, но оператор >> безопасен, оператор> небезопасен. Таким образом, ваша практика безопасна.
Лучше всего использовать предварительно скомпилированные заголовки для максимально быстрой компиляции.
Вы также можете использовать предварительно скомпилированные заголовки в gcc. См. Здесь .
Скомпилированный предварительно скомпилированный заголовок будет иметь расширение, добавленное как .gch
вместо .pch
.
Так, например, если вы предварительно компилируете stdafx.h у вас будет предварительно скомпилированный заголовок stdafx.h.gch
, который будет автоматически выполняться при каждом включении stdafx.h
Пример:
stdafx.h:
#include <string>
#include <stdio.h>
a.cpp:
#include "stdafx.h"
int main(int argc, char**argv)
{
std::string s = "Hi";
return 0;
}
Затем скомпилируйте как:
> g ++ -c stdafx.h -o stdafx.h.gch
> g ++ a.cpp
> ./a.out[12145estiveYour компиляция будет работать, даже если вы удалите stdafx.h после шага 1.
В последний раз я использовал вариант 3 , когда мне нужно было сделать то же самое. Мой проект был довольно маленьким, но он отлично работал.
Я без проблем выполнил вариант 2 (#ifdef) и вариант 4 (PCH для gcc) для кроссплатформенного кода.
Я считаю, что gcc компилируется намного быстрее, чем VS, поэтому предварительно скомпилированные заголовки обычно не так важны, если вы не ссылаетесь на какой-то огромный заголовочный файл.
Я бы выбрал вариант 4 или вариант 2. Я экспериментировал с предварительно скомпилированными заголовками как в различных версиях VS, так и в GCC в Linux (сообщения об этом в блоге здесь и здесь ). По моему опыту, VS намного более чувствителен к длине путей включения, количеству каталогов в пути включения и количеству включаемых файлов, чем G ++. Когда я измерял время сборки, правильно расположенные предварительно скомпилированные заголовки оказали бы огромное влияние на время компиляции в VS, тогда как G ++ это почти не впечатлило.
Фактически, исходя из вышеизложенного, что я сделал в последний раз, когда работал над проектом, где это было необходимо для сдерживания времени компиляции, чтобы предварительно скомпилировать эквивалент stdafx.h под Windows, где это имело смысл, и просто использовать его как обычный файл под Linux.