pragma once – niestandardowa, ale szeroko obsługiwana dyrektywa kompilatora w językach programowania C i C ++. Jest zaprojektowana w celu zapobiegania zawarcia kodu źródłowego wiele razy w jednej kompilacji^[1]. Dyrektywa #pragma once funkcjonuje podobnie jak tzw. multiple include optimization – wzorzec projektowy wykorzystujący standardowe dyrektywy preprocesora^[2], ale z dodatkowymi zaletami, w tym: mniej kodu, unikanie kolizji nazw, a czasem nawet poprawę szybkości kompilacji^[3]. Z drugiej strony, #pragma once niekoniecznie jest dostępna we wszystkich kompilatorach, a jej implementacja jest zawiła i może być zawodna.

Plik „grandparent.h”

#pragma once

struct foo 
{
  int member;
};

Plik „parent.h”

#include "grandparent.h"

Plik „child.c”

#include "grandparent.h"
#include "parent.h"

W tym przykładzie zawarcie grandparent.h zarówno w parent.h jak i child.c zwykle spowodowałoby błąd kompilacji, ponieważ struktura o nazwie foo może być zdefiniowana tylko raz w danej kompilacji. Dyrektywa #pragma once istnieje po to żeby uniknąć wielokrotnego zawarcia pliku grandparent.h.

Użycie#pragma once umożliwia preprocesorowi C dołączenie pliku, gdy jest potrzebny, w przeciwnym razie zignorowanie dyrektywy #include. Ma to wpływ na preprocesor C i pozwala programistom na wyrażanie zależności plików w łatwy sposób, eliminując potrzebę ręcznego zarządzania.

Najczęstszą alternatywą dla #pragma once jest użycie #define do ustawienia makra chroniącego #include, którego nazwa jest wybierana przez programistę i jest unikalna dla danego pliku. Na przykład:

#ifndef GRANDPARENT_H
#define GRANDPARENT_H
... contents of grandparent.h
#endif /* !GRANDPARENT_H */

Takie podejście w minimalnym stopniu gwarantuje, że zawarty plik nie będzie uwzględniony więcej niż raz. Jest to bardziej szczegółowe, wymaga więcej pracy, oraz jest podatne na błędy programisty, ponieważ nie ma dostępnych dla kompilatora mechanizmów zapobiegających przypadkowemu użyciu tej samej nazwy makra w więcej niż jednym pliku, co spowodowałoby, że tylko jeden z plików byłby zawarty przez preprocesor. Takie błędy, pomimo że bardzo prawdopodobne jest ich wykrycie, ale mogą skomplikować raport o błędach kompilatora. Ponieważ sam preprocesor jest odpowiedzialny za #pragma once, programista nie może spowodować kolizji nazw.

W przypadku braku makra zabezpieczającego wokół dyrektyw #include, przy użyciu #pragma once prawdopodobna jest poprawa szybkości kompilacji niektórych kompilatorów, ponieważ jest to wbudowany mechanizm; sam kompilator może porównywać nazwy plików bez konieczności wywoływania preprocesora celu przeszukania nagłówka w poszukiwaniu dyrektyw #ifndef i #endif. Ponieważ jednak makra osłaniające #include pojawiają się bardzo często, a obciążenie związane z otwieraniem plików jest znaczące, kompilatory często optymalizują takie makra, co może spowodować, że będą one tak szybkie, jak #pragma once^[4][5][6].

Identyfikacja tego samego pliku w systemie plików nie jest łatwym zadaniem^[7]. Dowiązania symboliczne, a zwłaszcza dowiązania twarde, mogą powodować, że ten sam plik będzie znajdował się pod różnymi nazwami w różnych folderach. Kompilatory mogą używać metody, która porównuje rozmiar pliku, czas modyfikacji i zawartość. Dodatkowo #pragma once może spowodować problemy, jeśli ten sam plik jest celowo kopiowany do kilku części projektu, np. Podczas przygotowywania kompilacji. W przypadku gdy makra zabezpieczające zawarcie nadal chroniłyby przed wielokrotnymi definicjami, #pragma once może różnie potraktować pliki. Trudności te, wraz z problemami związanymi z określeniem, co stanowi ten sam plik w obecności twardych linków, sieciowych systemów plików itp., dotąd uniemożliwiły standardyzację#pragma once. 

Zastosowanie makra chroniącego umożliwia zależnemu na rozpoznawanie i zareagowanie na różnice w semantyce lub interfejsach konkurencyjnych alternatyw. Na przykład,

#include TLS_API_MACRO /* defined on the command line */

...

#if defined TLS_A_H
... use one known API
#elif defined TLS_B_H
... use another known API
#else
#error "unrecognized TLS API"
#endif

W tym przypadku bezpośrednie określenie, który interfejs API jest dostępny, jest umożliwione przez to, że zawarty plik zadeklarował się za pomocą swojego makra chroniącego.