Dela via

Förkompilerade huvudfiler

När du skapar ett nytt projekt i Visual Studio läggs en fördefinierad rubrikfil med namnet pch.h till i projektet. (I Visual Studio 2017 och tidigare hette stdafx.hfilen .) Syftet med filen är att påskynda byggprocessen. Alla stabila rubrikfiler, till exempel standardbiblioteksrubriker som <vector>, bör inkluderas här. Den förkompilerade rubriken kompileras endast när den, eller alla filer som den innehåller, ändras. Om du bara gör ändringar i projektets källkod hoppar bygget över kompilering för det förkompilerade huvudet.

Kompilatoralternativen för förkompilerade rubriker är /Y. På projektegenskapssidorna finns alternativen under Konfigurationsegenskaper>C/C++>Förkompilerade rubriker. Du kan välja att inte använda förkompilerade rubriker och du kan ange namnet på huvudfilen och namnet och sökvägen för utdatafilen.

Anpassad förkompilerad kod

För stora projekt som tar lång tid att skapa kan du överväga att skapa anpassade förkompilerade filer. Microsoft C- och C++-kompilatorerna tillhandahåller alternativ för förkompilering av C- eller C++-kod, inklusive infogad kod. Med den här prestandafunktionen kan du kompilera en stabil kodtext, lagra kodens kompilerade tillstånd i en fil och under efterföljande kompileringar kombinera den förkompilerade koden med kod som fortfarande är under utveckling. Varje senare kompilering går snabbare eftersom den stabila koden inte behöver kompileras om.

När du ska förkompilera källkoden i förväg

Förkompilerad kod är användbar under utvecklingscykeln för att minska kompileringstiden, särskilt om:

  • Du använder alltid en stor kodtext som ändras sällan.

  • Programmet består av flera moduler, som alla använder en standarduppsättning med inkluderingsfiler och samma kompileringsalternativ. I det här fallet kan alla inkluderingsfiler förkompileras till en fördefinierad rubrik. Mer information om nyare sätt att hantera inkluderingsfiler finns i Jämför rubrikenheter, moduler och förkompilerade rubriker.

Den första kompilering (den som skapar den förkompilerade huvudfilen) tar lite längre tid än efterföljande kompileringar. Efterföljande kompileringar kan gå snabbare genom att inkludera den förkompilerade koden.

Du kan förkompilera både C- och C++-program. I C++-programmering är det vanligt att dela upp information om klassgränssnittet i huvudfiler. Dessa huvudfiler kan senare ingå i program som använder klassen. Genom att förkompilera dessa rubriker kan du minska den tid ett program tar att kompilera.

Anmärkning

Även om du bara kan använda en fördefinierad rubrikfil (.pch) per källfil kan du använda flera .pch filer i ett projekt.

Två alternativ för förkompilering av kod

Du kan förkompilera valfri C- eller C++-kod. du är inte begränsad till att bara förkompilera huvudfiler.

Förkompilering kräver planering, men det ger mycket snabbare kompileringar om du förkompilerar annan källkod än enkla huvudfiler.

Förkompilera kod när du vet att dina källfiler använder vanliga uppsättningar med huvudfiler, eller när du vill inkludera källkod i din förkompilering.

De förkompilerade sidhuvudalternativen är /Yc (Skapa förkompilerad rubrikfil) och /Yu (Använd förkompilerad rubrikfil). Använd /Yc för att skapa en fördefinierad rubrik. När du använder den valfria hdrstop pragma /Yc kan du förkompilera både huvudfiler och källkod. Välj om du /Yu vill använda en befintlig fördefinierad rubrik i den befintliga kompilering. Du kan också använda /Fp tillsammans med alternativen /Yc och /Yu för att ange ett alternativt namn för den förkompilerade huvudfilen.

Kompilatoralternativet refererar till artiklar för /Yu och /Yc diskuterar hur du kommer åt den här funktionen i utvecklingsmiljön.

Förkompilerade regler för sidhuvudkonsekvens

Eftersom PCH-filer innehåller information om datormiljön och information om programmets minnesadress bör du bara använda en PCH-fil på datorn där den skapades.

Konsekvensregler för användning per fil av förkompilerade rubriker

Med /Yu kompileringsalternativet kan du ange vilken PCH-fil som ska användas.

När du använder en PCH-fil förutsätter kompilatorn samma kompileringsmiljö som gällde när du skapade PCH-filen, såvida du inte anger något annat. Kompileringsmiljön innehåller kompilatoralternativ, pragmas och så vidare. Om kompilatorn identifierar en inkonsekvens utfärdar den en varning och identifierar inkonsekvensen där det är möjligt. Sådana varningar indikerar inte nödvändigtvis ett problem med PCH-filen. de varnar dig bara för eventuella konflikter. Konsekvenskrav för PCH-filer beskrivs i följande avsnitt.

Konsekvens för kompilatoralternativ

Följande kompilatoralternativ kan utlösa en inkonsekvensvarning när du använder en PCH-fil:

  • Makron som skapats med alternativet Preprocessor (/D) måste vara samma mellan kompileringen som skapade PCH-filen och den aktuella kompileringen. Statusen för definierade konstanter kontrolleras inte, men oförutsägbara resultat kan uppstå om dessa makron ändras.

  • PCH-filer fungerar inte med /E alternativen och /EP .

  • PCH-filer måste skapas med antingen alternativet Generera bläddra information (/FR) eller alternativet Exkludera lokala variabler (/Fr) innan efterföljande kompileringar som använder PCH-filen kan använda dessa alternativ.

C 7.0-kompatibel (/Z7)

Om det här alternativet gäller när PCH-filen skapas kan senare kompileringar som använder PCH-filen använda felsökningsinformationen.

Om alternativet C 7.0-Kompatibel (/Z7) inte gäller när PCH-filen skapas, kommer senare kompileringar som använder PCH-filen och /Z7 utlöser en varning. Felsökningsinformationen placeras i den aktuella .obj filen och lokala symboler som definieras i PCH-filen är inte tillgängliga för felsökningsprogrammet.

Inkludera sökvägskonsekvens

En PCH-fil innehåller inte information om headerfilens inkluderingssökväg som gällde när den skapades. När du använder en PCH-fil använder kompilatorn alltid den inkluderingssökväg för headerfiler som anges i den aktuella kompileringen.

Källfilsamstämmighet

När du anger alternativet Använd förkompilerad rubrikfil (/Yu) ignorerar kompilatorn alla förprocessordirektiv (inklusive pragmas) som visas i källkoden som ska förkompileras. Kompilering som anges i sådana förprocessordirektiv måste vara densamma som den kompilering som används för alternativet Skapa förkompilerad rubrikfil (/Yc).

Pragmakonsekvens

Pragmas som bearbetas när en PCH-fil skapas påverkar vanligtvis den fil som PCH-filen senare används med. Pragmerna comment och message påverkar inte resten av kompilering.

Dessa pragmas påverkar endast koden i PCH-filen. de påverkar inte kod som senare använder PCH-filen:

comment
linesize

message
page

pagesize
skip

subtitle
title

Dessa pragmas behålls som en del av en fördefinierad rubrik och påverkar resten av en kompilering som använder den förkompilerade rubriken:

alloc_text
auto_inline
check_stack
code_seg
data_seg

function
include_alias
init_seg
inline_depth

inline_recursion
intrinsic
optimize
pack

pointers_to_members
setlocale
vtordisp
warning

Konsekvensregler för /Yc och /Yu

När du använder en förkompilerad huvudfil som skapats med /Yc eller /Yu, jämför kompilatorn den aktuella kompileringsmiljön med den som fanns när du skapade PCH-filen. Se till att ange en miljö som är konsekvent med den föregående (med konsekventa kompilatoralternativ, pragmas och så vidare) för den aktuella kompileringen. Om kompilatorn identifierar en inkonsekvens utfärdar den en varning och identifierar inkonsekvensen där det är möjligt. Sådana varningar indikerar inte nödvändigtvis ett problem med PCH-filen. de varnar dig bara för eventuella konflikter. I följande avsnitt förklaras konsekvenskraven för förkompilerade rubriker.

Konsekvens för kompilatoralternativ

Den här tabellen innehåller kompilatoralternativ som kan utlösa en inkonsekvensvarning när du använder en fördefinierad rubrik:

Alternativ Namn Regel
/D Definiera konstanter och makron Måste vara samma mellan kompileringen som skapade det förkompilerade huvudet och den aktuella kompileringen. Tillståndet för definierade konstanter är inte kontrollerat. Oförutsägbara resultat kan dock uppstå om filerna är beroende av värdena för de ändrade konstanterna.
/E eller /EP Kopiera förprocessorutdata till standardutdata Förkompilerade rubriker fungerar inte med /E alternativet eller /EP .
/Fr eller /FR Generera Microsoft Source Browser-information /Fr För att alternativen och /FR ska vara giltiga med /Yu alternativet måste de också ha varit i kraft när det förkompilerade huvudet skapades. Efterföljande kompileringar som använder det förkompilerade huvudet genererar också källwebbläsareinformation. Webbläsarinformation placeras i en enda .sbr fil och refereras av andra filer på samma sätt som CodeView-information. Du kan inte åsidosätta placeringen av källwebbläsarens information.
/GA, /GD, /GE, /Gweller /GW Alternativ för Windows-protokoll Måste vara samma mellan kompileringen som skapade det förkompilerade huvudet och den aktuella kompileringen. Kompilatorn genererar en varning om dessa alternativ skiljer sig åt.
/Zi Generera fullständig felsökningsinformation Om det här alternativet gäller när det förkompilerade huvudet skapas kan efterföljande kompileringar som använder förkompileringen använda den felsökningsinformationen. Om /Zi inte gäller när det förkompilerade huvudet skapas utlöser efterföljande kompileringar som använder förkompileringen och /Zi alternativet en varning. Felsökningsinformationen placeras i den aktuella objektfilen och lokala symboler som definierats i det förkompilerade huvudet är inte tillgängliga för felsökningsprogrammet.

Anmärkning

Den förkompilerade huvudfilen är endast avsedd att användas i C- och C++-källfiler.

Använda förkompilerade rubriker i ett projekt

Föregående avsnitt innehåller en översikt över förkompilerade rubriker: /Yc och /Yu, alternativet /Fp och hdrstop pragma. I det här avsnittet beskrivs en metod för att använda de manuella förkompilerade sidhuvudalternativen i ett projekt. det slutar med en exempel makefile och den kod som den hanterar.

En annan metod för att använda manuella förkompilerade rubrikalternativ i ett projekt finns i en av de makefiles som finns i MFC\SRC katalogen som skapas under standardinställningen för Visual Studio. Dessa makefiles använder en liknande metod som den som visas i det här avsnittet. De använder makron för Microsoft Program Maintenance Utility (NMAKE) och ger större kontroll över byggprocessen.

PCH-filer i byggprocessen

Kodbasen för ett programvaruprojekt finns ofta i flera C- eller C++-källfiler, objektfiler, bibliotek och huvudfiler. Vanligtvis samordnar en makefile kombinationen av dessa element till en körbar fil. Följande bild visar strukturen för en makefile som använder en fördefinierad rubrikfil. NMAKE-makronamnen och filnamnen i det här diagrammet överensstämmer med exempelkoden som finns i Exempelmakefil för PCH och Exempelkod för PCH.

Bilden använder tre diagrammatiska enheter för att visa flödet i byggprocessen. Namngivna rektanglar representerar varje fil eller makro. de tre makrona representerar en eller flera filer. Skuggade områden representerar varje kompilerings- eller länkåtgärd. Pilar visar vilka filer och makron som kombineras under kompilerings- eller länkningsprocessen.

Struktur för en makefile som använder en fördefinierad rubrikfil:

Diagram som visar exempel på indata och utdata för en makefile som använder en fördefinierad rubrikfil.

Från och med början överst i diagrammet är både STABLEHDRS och BOUNDRY NMAKE-makron där du listar filer som sannolikt inte behöver omkompileras. Dessa filer kompileras av kommandosträngen

CL /c /W3 /Yc$(BOUNDRY) applib.cpp myapp.cpp

endast om den förkompilerade huvudfilen (STABLE.pch) inte finns eller om du gör ändringar i filerna som anges i de två makrona. I båda fallen innehåller den förkompilerade huvudfilen endast kod från de filer som anges i makrot STABLEHDRS . Visa en lista över den sista filen som du vill förkompilera i makrot BOUNDRY .

De filer som du listar i dessa makron kan vara antingen huvudfiler eller C- eller C++-källfiler. (En enda PCH-fil kan inte användas med både C- och C++-källor.) Du kan använda makrot hdrstop för att stoppa förkompileringen någon gång i BOUNDRY filen. Mer information finns i hdrstop.

Nästa i diagrammet APPLIB.obj representerar den supportkod som används i ditt slutliga program. Den skapas från APPLIB.cpp, filerna som listas i makrot UNSTABLEHDRS och förkompilerad kod från den förkompilerade headern.

MYAPP.obj representerar din slutliga applikation. Den skapas från MYAPP.cpp, filerna som listas i makrot UNSTABLEHDRS och förkompilerad kod från den förkompilerade headern.

Slutligen skapas den körbara filen (MYAPP.EXE) genom att länka ihop de filer som anges i makrot OBJS (APPLIB.obj och MYAPP.obj).

Exempel på makefile för PCH

Följande makefile använder makron och en !IFkommandostruktur !ELSE!ENDIF för kontrollflöde för att förenkla anpassningen till projektet.

# Makefile : Illustrates the effective use of precompiled
#            headers in a project
# Usage:     NMAKE option
# option:    DEBUG=[0|1]
#            (DEBUG not defined is equivalent to DEBUG=0)
#
OBJS = myapp.obj applib.obj
# List all stable header files in the STABLEHDRS macro.
STABLEHDRS = stable.h another.h
# List the final header file to be precompiled here:
BOUNDRY = stable.h
# List header files under development here:
UNSTABLEHDRS = unstable.h
# List all compiler options common to both debug and final
# versions of your code here:
CLFLAGS = /c /W3
# List all linker options common to both debug and final
# versions of your code here:
LINKFLAGS = /nologo
!IF "$(DEBUG)" == "1"
CLFLAGS   = /D_DEBUG $(CLFLAGS) /Od /Zi
LINKFLAGS = $(LINKFLAGS) /COD
LIBS      = slibce
!ELSE
CLFLAGS   = $(CLFLAGS) /Oselg /Gs
LINKFLAGS = $(LINKFLAGS)
LIBS      = slibce
!ENDIF
myapp.exe: $(OBJS)
    link $(LINKFLAGS) @<<
$(OBJS), myapp, NUL, $(LIBS), NUL;
<<
# Compile myapp
myapp.obj  : myapp.cpp $(UNSTABLEHDRS)  stable.pch
    $(CPP) $(CLFLAGS) /Yu$(BOUNDRY)    myapp.cpp
# Compile applib
applib.obj : applib.cpp $(UNSTABLEHDRS) stable.pch
    $(CPP) $(CLFLAGS) /Yu$(BOUNDRY)    applib.cpp
# Compile headers
stable.pch : $(STABLEHDRS)
    $(CPP) $(CLFLAGS) /Yc$(BOUNDRY)    applib.cpp myapp.cpp

Förutom makrona STABLEHDRS, BOUNDRYoch UNSTABLEHDRS som visas i bilden "Structure of a Makefile That Uses a Precompiled Header File" (Struktur för en makefil som använder en förkompilerad rubrikfil) i PCH-filer i byggprocessen, tillhandahåller den här makefile ett CLFLAGS makro och ett LINKFLAGS makro. Du måste använda dessa makron för att visa kompilator- och länkalternativ som gäller oavsett om du skapar en felsökningsversion eller en slutlig version av programmets körbara fil. Det finns också ett LIBS makro där du listar de bibliotek som projektet kräver.

Makefile använder !IFockså , !ELSE, !ENDIF för att identifiera om du definierar en DEBUG symbol på NMAKE-kommandoraden:

NMAKE DEBUG=[1|0]

Den här funktionen gör det möjligt för dig att använda samma makefile under utvecklingen och för de slutliga versionerna av ditt program. Använd DEBUG=0 för de slutliga versionerna. Följande kommandorader är likvärdiga:

NMAKE
NMAKE DEBUG=0

Mer information om makefiles finns i NMAKE-referens. Se även MSVC-kompilatoralternativ och MSVC-länkalternativ.

Exempelkod för PCH

Följande källfiler används i den makefile som beskrivs i PCH-filer i byggprocessen och Exempel på makefile för PCH. Kommentarerna innehåller viktig information.

Källfil ANOTHER.H:

// ANOTHER.H : Contains the interface to code that is not
//             likely to change.
//
#ifndef __ANOTHER_H
#define __ANOTHER_H
#include <iostream>
void savemoretime( void );
#endif // __ANOTHER_H

Källfil STABLE.H:

// STABLE.H : Contains the interface to code that is not likely
//            to change. List code that is likely to change
//            in the makefile's STABLEHDRS macro.
//
#ifndef __STABLE_H
#define __STABLE_H
#include <iostream>
void savetime( void );
#endif // __STABLE_H

Källfil UNSTABLE.H:

// UNSTABLE.H : Contains the interface to code that is
//              likely to change. As the code in a header
//              file becomes stable, remove the header file
//              from the makefile's UNSTABLEHDR macro and list
//              it in the STABLEHDRS macro.
//
#ifndef __UNSTABLE_H
#define __UNSTABLE_H
#include <iostream>
void notstable( void );
#endif // __UNSTABLE_H

Källfil APPLIB.CPP:

// APPLIB.CPP : This file contains the code that implements
//              the interface code declared in the header
//              files STABLE.H, ANOTHER.H, and UNSTABLE.H.
//
#include "another.h"
#include "stable.h"
#include "unstable.h"
using namespace std;
// The following code represents code that is deemed stable and
// not likely to change. The associated interface code is
// precompiled. In this example, the header files STABLE.H and
// ANOTHER.H are precompiled.
void savetime( void )
    { cout << "Why recompile stable code?\n"; }
void savemoretime( void )
    { cout << "Why, indeed?\n\n"; }
// The following code represents code that is still under
// development. The associated header file is not precompiled.
void notstable( void )
    { cout << "Unstable code requires"
            << " frequent recompilation.\n";
    }

Källfil MYAPP.CPP:

// MYAPP.CPP : Sample application
//             All precompiled code other than the file listed
//             in the makefile's BOUNDRY macro (stable.h in
//             this example) must be included before the file
//             listed in the BOUNDRY macro. Unstable code must
//             be included after the precompiled code.
//
#include "another.h"
#include "stable.h"
#include "unstable.h"
int main( void )
{
    savetime();
    savemoretime();
    notstable();
}

Se även

Jämför rubrikenheter, moduler och förkompilerade rubriker
C/C++-byggreferens
MSVC-kompilatoralternativ
Översikt över moduler i C++
Självstudie: Importera C++-standardbiblioteket med hjälp av moduler
Genomgång: Skapa och importera rubrikenheter i dina Visual C++-projekt
Genomgång: Importera STL-bibliotek som rubrikenheter