Почему C / C++"#pragma once " не является стандартом ISO?

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

тем не менее ,это не так, и вы в основном застряли с использованием включить охранников. Что сказал:#pragma once довольно широко поддерживается, поэтому вы можете уйти с его помощью.

лично я решаю вашу 1-ю проблему (аналогично названные файлы include) с помощью добавление GUID в Include guard. Это уродливо, и большинство людей ненавидят его (поэтому я часто вынужден не использовать его на работе), но ваш опыт показывает, что идея имеет некоторую ценность - даже если она ужасно уродлива (но опять же, вся вещь include guard - это своего рода Хак-почему бы не пойти всей свиньей?):

#ifndef C_ASSERT_H_3803b949_b422_4377_8713_ce606f29d546
#define C_ASSERT_H_3803b949_b422_4377_8713_ce606f29d546

// blah blah blah...

#endif

Я слышал, что компиляторы на самом деле не открывают файлы заголовков, которые включают guards (они научились распознавать идиому). Я не уверен, что это правда (или в какой степени это правда); я никогда не измерял его. Я также не беспокоюсь об этом, но мои проекты не настолько огромны, чтобы это было проблемой.

мой GUID hack в значительной степени решает пункты 1, 5 и 6. Я просто живу с пунктами 2, 3 и 4. Фактически, для элемента 2 Вы можете жить без переименования макроса include guard при переименовании файла, поскольку GUID гарантирует, что он останется уникальным. На самом деле, нет никаких причин включать имя файла вообще с GUID. Но я знаю - традиция, я полагаю.

1. Как часто вам нужно добавлять файл include в этот проект? Действительно ли так сложно добавить dirname_filename в guard? И всегда есть GUIDs.
2. вы действительно переименовываете файлы так часто? Когда-нибудь? Кроме того, размещение охранника в #endif так же раздражает, как и любой другой бесполезный комментарий.
3. Я сомневаюсь, что ваши 1000 заголовочных файлов guard определяют даже небольшой процент от количества определений, генерируемых вашими системными библиотеками (особенно на Windows.)
4. Я думаю, что MSC 10 для DOS (20+ лет назад) отслеживал, какие заголовки были включены, и если бы они содержали охранников, пропустил бы их, если бы они были включены снова. Это старая техника.

5. пространства имен и шаблоны не должны охватывать заголовки. Боже мой, только не говорите мне, что вы это делаете!--12-->

   template <typename foo>
   class bar {
   #include "bar_impl.h"
   };
   

6. ты это уже говорил.

Как уже отмечалось, стандарт C++ должен учитывать различные платформы разработки, некоторые из которых могут иметь ограничения, делающие поддержку #pragma невозможной для реализации.

с другой стороны, поддержка потоков не была добавлена по аналогичной причине ранее, но более новый стандарт C++ все же включает потоки. И в последнем случае мы можем кросс-компиляции для платформы, но разработка ведется на полноценной платформе. Поскольку GCC поддерживает это расширение, я думаю, реальный ответ на ваш вопрос заключается в том, что нет заинтересованной стороной в продвижении этой функции в стандарт C++.

с практической точки зрения, включение охранников вызвало у нашей команды больше проблем, чем несоответствие директивы #pragma once. Например, GUID в include guards не помогает в случае, если файл дублируется, а затем обе копии включены. При использовании только #pragma, как только мы получим дубликат ошибки определения и можем потратить время на унификацию исходного кода. Но в в случае include guards проблема может потребовать тестирования во время выполнения, например, это происходит, если копии отличаются аргументами по умолчанию для параметров функции.

Я избегаю использования Include guards. Если мне придется перенести свой код в компилятор без поддержки #pragma, я напишу сценарий, который добавит Include guards ко всем файлам заголовков.

проблема возникает, когда у вас есть заголовки с тем же именем в разных каталогах.

Итак, у вас есть два заголовка, которые называются ice_cream_maker.h в вашем проекте, оба из которых имеют класс под названием ice_cream_maker определенный в них, который выполняет ту же функцию? Или вы вызываете каждый класс В вашей системе foo?

тем не менее определение включено один раз, компилятор по-прежнему открывает заголовок каждый раз, когда он встречает заголовок включение.

отредактируйте код, чтобы не включать заголовки несколько раз.

для зависимых заголовков (а не основного заголовка для библиотеки) я часто использую заголовочные ограждения, которые выглядят так:

#ifdef FOO_BAR_BAZ_H
#error foo_bar_baz.h multiply included
#else
#define FOO_BAR_BAZ_H

// header body

#endif

IIRC, #pragma ничего не является частью языка. И это часто проявляется на практике.

(edit: полностью согласен с тем, что система включения и связывания должна была быть больше ориентирована на новый стандарт, поскольку это одна из самых очевидных слабостей в "le this day and age")

вы, вероятно, можете избежать столкновения имен, не прибегая к случайным строкам, установив Include guard, чтобы содержать имя класс и пространство имен это в файл.

кроме того, #pragma когда-то поддерживается как компиляторами MS, так и GCC в течение некоторого времени, так почему вас беспокоит, что это не на стандарте ISO?

прагматичное решение:

1) Выберите некоторую согласованную политику именования защиты (например, путь относительно корня проекта + Имя файла или что-то еще вы выбираете). Включить возможные исключения для кода третьей стороны.

2) напишите программу (простой скрипт python), чтобы рекурсивно пройти исходное дерево и проверить, что все охранники соответствуют политике. И всякий раз, когда охранники ошибаются, выведите diff (или сценарий sed, или что-то еще), что пользователь может легко применить для исправления. Или просто попросите подтверждение и внесите изменения из той же программы.

3) заставьте всех в проекте использовать его (скажем, перед отправкой в систему управления версиями).

Я думаю, что правильный способ разрешить делать несколько include только со специальной прагмой и запретить несколько include по умолчанию например:

#pragma allow_multiple_include_this_file

так как вы спросили, почему. Вы отправили свое предложение разработчикам standart? :) Я тоже не посылаю. Может быть причина?