Я являюсь адептом #pragma once, использую эту директиву во всех своих проектах и поощряю других к тому же. Тем не менее время от времени приходится натыкаться на код с использованием header guards, причём код относительно свежий, без налёта 20-го века. Сей факт меня, как представителя homo sapience (с акцентом на sapience) не перестаёт удивлять.
Я честно поднял для себя этот вопрос, попытался проанализировать, что же движет программистами обоих кланов. Список достоинств и недостатков обоих методов получился примерно следующим:
1. header guards - это хак и как любому хаку в коде ему не место. Более того, это хак в квадрате из-за использования макросов, что сами по себе есть зло. Логика подсказывает, что если же хак превращается в правило - проблему нужно решать на глобальном уровне, причём стандарт должен минимизировать побочные эффекты к нулю. Именно отсюда и родился #pragma once - тот самый стандарт, призванный решить существовавшие проблемы с включением заголовочников.
2. Конфликт имён. Если вы в своём коде добавили util.h с #define UTIL_H внутри, рано или поздно вы наткнётесь на конфликт с 3rdparty-библиотекой с таким же макросом. Единые правила для выбора имён макросов дискредитируют саму их идею - если все будут их придерживаться, то в результате они породят те же конфликты. Остаётся надеяться на генераторы мусорных суффиксов, которые а) идут вразрез с идеей того, что код должен писаться для человека и б) привет, рефакторинг! то-есть, пока... переименовав один заголовочник в другой или просто скопировав код получаем чёрти что.
3. Поощрение к хитростям. Если макрос объявлен, значит его можно и удалить, чтобы потом попробовать включить заголовочник снова. Или смешная до коликов в животе попытка «ускорить» компиляцию следующим хаком:
#ifndef UTIL_H
#include "util.h"
#endifКоторая не только ни на грамм не быстрее, но ещё и вынуждает следить по всему коду, чтобы макрос совпадал.
Конечно подкованный кодер к подобным хитростям чужд, максимум кого ими можно обхитрить - самого себя. Тем не менее неоднозначная семантика header guards вынуждает молодого программиста задуматься - а вдруг таки можно? Однозначная семантика #pragma once решает эту проблему на корню, минимизируя возможные хаки и ошибки к нулю.
4. Распространённость и поддержка компиляторами. Как известно, чем проще код - тем легче его сопровождать. Аргумент сложности реализации #pragma once для меня вообще смешон, поддержка реализуется примерно следующим алгоритмом:
int include_or_not_the_header( const char * path )
{
if ( pragma_onced_headers_cache_contains( path ) )
return DONT_INCLUDE_THIS_HEADER;
if ( does_header_contain_pragma_once( path ) )
pragma_onced_headers_cache_add( path );
return INCLUDE_THIS_HEADER_PLEASE;
}Если кто сможет назвать хоть один компилятор (помимо мирно лежащих в гробах) без поддержки #pragma once - будьте добры. Мой гугл находит только кивания, что суслик как бы есть, но в глаза его никто не видел.
5. Миф о проблемах с символическими ссылками в #pragma once. Давно развеян с тех пор, как в GCC в кеш (см. пример выше) стали ложить не символические ссылки на файлы, а сами файлы.
6. Достоинства header guards. Здесь прочерк.
Итого я пришёл к выводу, что header guards продолжают пользоваться:
1) Осознанно. Бородатые программисты с бородатыми компиляторами со специфичным кодом под специфичные устройства.
2) Неосознанно - все остальные.
Отчасти на пункт 2 повлияли два фактора - ISO и GCC. Первый, насколько я понимаю, до сих пор жмётся, чтобы добавить директиву в стандарт. Второй долгое время выдавал warning на эту директиву, мол deprecated и вообще ай-яй-яй. Пользователи при этом балансировали на грани, а многие поддались общей панике и устроили крестовые походы набеги на #pragma once, насаждая всюду религию header guards. И видимо по инерции не заметили, как ещё в 2004-м году (!!) в GCC 3.4 официально убрали любые комплексы по этому поводу, оставив #pragma once навсегда в списке поддерживаемых директив.
Аргументы за и против, а также список компиляторов без поддержки #pragma once - приветствуются. Примеры сотен кода, в которых используются header guards без аргументации почему - можете оставить себе.
