Когда можно опустить расширение файла в директиве #include?

Если файл называется tuple, вам необходимо #include <tuple> если он называется tuple.h, то вам нужен #include <tuple.h>

Это так просто. Вы не пропускаете никаких расширений.

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

Предполагаемый стандарт для включаемых файлов C++ - называть их без расширения .h; многие разработчики библиотек следуют этому стандарту (STL и т. д.), но некоторые нет.

Насколько я понимаю, кортеж #include будет «указывать» на tuple.h.

Проверьте это: iostream против iostream.h

Стандартные заголовки C++ не имеют суффикса «.h». Я считаю, что причина в том, что существовало множество различных предварительных стандартных реализаций, которые стандарт нарушил бы. Поэтому вместо того, чтобы требовать, чтобы поставщики изменили свой выходящий заголовок «iostream.h» (например), чтобы он соответствовал стандартам (что нарушило бы код их существующего пользователя), комитет по стандартам решил, что они уберут суффикс (который, я считаю, нет тогда существующая реализация уже была сделана).

Таким образом, существующие нестандартные программы будут продолжать работать с использованием нестандартных библиотек поставщика. Когда пользователь хотел привести свои программы в соответствие со стандартами, одним из шагов, которые он предпринял, было изменение директивы «#include», чтобы удалить суффикс «.h».

Так

#include <iostream>     // include the standard library version
#include <iostream.h>   // include a vendor specific version (which by 
                        //      now might well be the same)

Как уже упоминалось в других ответах, авторы нестандартных библиотек могут выбрать любое соглашение об именах, но я думаю, что они захотят продолжить использование «.h» или «.hpp» (как это сделал Boost) по нескольким причинам:

1. если & когда библиотека будет стандартизирована, стандартная версия не будет автоматически отменять предыдущую нестандартную (что, по всей вероятности, приведет к нарушению пользовательского кода)
2. Кажется, это соглашение (более или менее), что заголовки без суффикса являются стандартными библиотеками, а те, у которых есть суффикс (кроме старых заголовков C), нестандартны.

Обратите внимание, что аналогичная проблема возникла, когда комитет пошел, чтобы добавить хэш-карты в STL - они обнаружили, что уже существует много (разных) реализаций hash_map, поэтому вместо того, чтобы придумывать стандартную, которая ломает много вещей сегодня стандартная реализация называется «unordered_map». Пространства имен должны были помочь предотвратить этот тип прыжков через обручи, но, похоже, он не работал достаточно хорошо (или использовался достаточно хорошо), чтобы позволить им использовать более естественное имя, не нарушая большого количества кода.

Обратите внимание, что для заголовков «C» C++ позволяет включать либо вариант <cxxxxxx>, либо вариант <xxxxxx.h>. Тот, который начинается с 'c' и не имеет суффикса ".h", помещает свои объявления в пространство имен std (и, возможно, глобальное пространство имен), те, которые имеют суффикс ".h", помещают имена в глобальное пространство имен (некоторые компиляторы также поместите имена в пространство имен std - мне неясно, соответствует ли это стандарту, хотя я не вижу вреда).

Ничего особенного не происходит. Имя файла просто tuple.

Причина этого ... что заголовки стандартной библиотеки не имеют расширения файла из-за namespace.

Пространства имен были добавлены к стандарту C++ в конце игры со стандартом C++ 98, включая пространство имен std, в котором находятся все объекты стандартной библиотеки.

Когда стандартная библиотека была перемещена в пространство имен std, это означало, что весь существующий код C++ сломается, поскольку все предполагалось, что библиотека будет в глобальном пространстве имен. Решение заключалось в том, чтобы оставить старые файлы заголовков «dot-h» в покое и предоставить библиотеку с пространством имен в файлах без расширения.

Таким образом, старый код, который будет #include<iosteam.h>, мог ожидать глобального cout, а новый код мог ожидать #include<iostream> и ожидать std::cout.

В дополнение к уже опубликованным прекрасным ответам следует отметить, что стандарт C++ не требует директивы «#include <iostream>» для чтения файла с именем «iostream» или даже «iostream.h». Его можно было бы назвать «пушистым комком». Или соответствующий файл может не существовать, и определения должны быть встроены в компилятор и активированы директивой include.

Близкие,

Я думаю, что сделка такова: #include <lib> всегда предварительноpends / lib / include в путь поиска (подразумевается .h), тогда как #include <lib.h> выполняет поиск только -I <pathname>.

Обратите внимание, что я могу ошибаться ... Я думаю, это так и работает (в Forte cc на Solaris).