Что делает директива include в связке с pragma once?

Здравствуйте,

Запутался совсем.

Что делает команда #include ?

Ну судя по тому, что говорит гугл - это простейшая операция скопировать-вставить, то есть берется весь код файла .cpp или .h и просто вставляется туда, где вызван #include - типа на этапе "препроцессора".

Вроде бы понятно. Непонятен другой момент - есть необязательная для с++ команда компилятора "pragma once" или из стандарта:
Который как бы должен не позволять включать код из файла два раза.

Я не могу понять, эти команды не позволять включать код более, чем один раз в любой файл, в котором вызван #include ?

Я это к тому, что говорят, что Only Header либы раздувают код, но ведь есть эти команды препроцессора, которые не позволяют включать код более одного раза ?

0

Сообщение от Optimus11 Only Header либы раздувают код

С чего бы это?
Я бы сказал, что наоборот, уменьшают код.

0

Сообщение от Optimus11 Что делает команда #include ?

препроцессор заменяет эту строку на содержимое файла, который указан в директиве

а #pragma once и/или гарды предотвращают повторные инклуды одного и того же файла внутри единицы трансляции

0

Сообщение от Optimus11 Я не могу понять, эти команды не позволят включать код более, чем один раз в любой файл, в котором вызван #include ?

В те файлы где инклюд обрамлён логическим блоком проверяющим определение стража включения.

Сообщение от Optimus11 Only Header либы раздувают код

Optimus11, обратите внимание на 2-й ответ:
"//**********************/questions/1165740/почему-не-все-c-библиотеки-header-only"

сайт не даёт опубликовать ссылку на стек оверфлоу)
тогда фраг:

Недостатки использования header-only библиотек: Вы не можете скрыть детали реализации, как этого можно добиться при разделении библиотеки на интерфейс в виде .h файла и файла реализации поставляемого например в виде .lib, .dll. Большинство изменений в библиотеке потребует перекомпиляции всех единиц компиляции, использующих эту библиотеку. Более длительное время компиляции, так как компилятор должен видеть реализацию всех компонентов во включенных файлах, а не только их интерфейсы. усложняется чтение кода, так как клиенту проще видеть только интерфейс используемого функционала и не отвлекаться на реализацию (спорное утверждение). Нельзя слинковать динамически = нельзя заменить/обновить библиотеку в уже скомпилированной программе.

1

Сообщение от Алексей1153 а #pragma once и/или гарды предотвращают повторные инклуды одного и того же файла внутри единицы трансляции

Не могу понять, что значит "повторные инклуды одного и того же файла внутри единицы трансляции".
"Единица трансляции" - это просто один файл ? Если да, то как внутри одного файла может оказаться несколько одинаковых нуклиидов?

0

разбухание - от необходимости компилировать определение в каждой единице трансляции. У чистых шаблонов (без финтов с явным инстанцированием) нет адреса, это не объекты кода и их нельзя связать.

0

Сообщение от Optimus11 то как внутри одного файла может оказаться несколько одинаковых нуклиидов

да запросто

1.cpp
#include "1.h"
#include "1.h"
#include "1.h"

Добавлено через 31 секунду

Сообщение от Optimus11 нуклиидов

0

Сообщение от Optimus11 Не могу понять, что значит "повторные инклуды одного и того же файла внутри единицы трансляции".

Optimus11, я уже мого раз повторял вам, - практикуйте и поймёте. Программирование нельзя выучить как букварь. Чтение текстов и просмотры видео не помогут.
На практике, повторное включение угрожает тогда когда есть ромбовидная структура включений. Один хедер включён в другой, а потом и он и другой включены в в какой-то сорс. Для исключения лишнего включения срабатывает страж.

1

Сообщение от Алексей1153 да запросто 1.cpp #include "1.h" #include "1.h" #include "1.h"

Ну блин - это ошибка программиста, какой смысл от этого защищать.

Наверное все таки от такого случая:


Чтобы в my_cpp_2 дважды не включился код из header_1.h, через включение файла my_cpp_1.cpp ?

0

Сообщение от Алексей1153 заменяет эту строку на содержимое файла

на содержимое заголовка.
заголовок может и не быть файлом.

1

Сообщение от Optimus11 это ошибка программиста, какой смысл от этого защищать.

нет, это не ошибка, такой инклуд может придти, будучи в составе другого инклуда, вложенного ещё в три инклуда. И от этого требуется защита

Сообщение от Optimus11 #include "my_cpp_1.cpp"

а так делать не нужно

0

Сообщение от Алексей1153 а так делать не нужно

Почему ?

0

Optimus11, инклудят заголовки, а единицы трансляции для этого не предназначены

0

Сообщение от Optimus11 Почему ?

Потому что cpp-файл - это основа для единицы трансляции в нем обычно находятся определения. ЕТ компилируется совместно со всеми include-ами, которые в нее добавили. Если вы включили cpp-файл через include, то получите две единицы трансляции с одинаковыми определениями (например в 1.cpp включили 2.cpp, следовательно содержимое 2.cpp будет скомпилировано два раза: первый раз в составе 1.cpp, а второй - когда уже сам 2.cpp будет компилироваться как ЕТ), а это приведет к нарушению ODR: в лучшем случае к ошибке линкера, а в худшем все соберется, но работать может неправильно.
Я же вот вам в 20-м году давал ссылку, где все это разъясняется. Вы ее не смотрели?

1

Так много написано, и ни одного простого понятного примера. Сплошная терминология для тех, кто и так знает ответ.

Добавлено через 10 секунд
--1.h--
--2.h--

--main.cpp--
И вот при компиляции main.cpp (это и есть "единица трансляции") получается, что при включении 2.h изнутри него будет повторно включаться 1.h
Чтобы это предотвратить - и добавляют указанные защиты.

Второй вариант - без защит - внимательно следить за руками и не включать заголовки те, которые уже есть во включеных h-файлах.

Вообще, это философский вопрос: правильно (допустимо ли) инклудить одни h-файлы в другие?
Я встречался с двумя школами:

1) да, в h-файл следует включить все те h-файлы, от которых он зависит. Это упрощает подключение h-файлов при использовании в cpp

2) категорически недопустимо использовать #include в р-файлах! Резон как раз в том, чтобы
а) не было проблем с повторными включениями
б) не раздувать код вот этими неочевидными вложенными включениями всего и вся.

Теоретически я считаю, что подход школы 2) более правильный. Но он осложняется необходимостью очень хорошо проектировать h-файлы и необходимостью хорошо понимать в каком порядке требуется включать h-файлы в cpp, иначе если включить не в том порядке - то на момент компиляции 2.h мы еще не будем знать про Calss1 (в терминах приведённого выше примера), значит получим ошибку компиляции.

Поэтому на практике чаще видим подход школы 1), это проще в использовании и не требует аккуратности при проектировании h-файлов.

1

Сообщение от KSergey9 Теоретически я считаю, что подход школы 2) более правильный. Но он осложняется необходимостью очень хорошо проектировать h-файлы необходимостью хорошо понимать в каком порядке требуется включать h-файлы в cpp.

Вот допустим ситуация: есть класс, в котором есть поле std::string. Вопрос, как без включения #include <string> описать этот класс в своем заголовочном файле?
Насколько я понимаю, вы предлагаете делать так:
Да? Если да, то чем же это лучше? Это невероятно сложный и ошибкоопасный микроконтроль за каждой единицей трансляции, где всегда нужно вручную учитывать порядок включения h-файлов.
Или вы что-то другое имели в виду?

0

Сообщение от KSergey9 1) да, в h-файл следует включить все те h-файлы, от которых он зависит

это правильный вариант

0

Сообщение от DrOffset Я же вот вам в 20-м году давал ссылку, где все это разъясняется. Вы ее не смотрели?

Однако у Вас память. Если в 2020 и смотрел, то скорее всего ничего не понял. Попробую еще раз теперь.

Добавлено через 4 минуты

Сообщение от DrOffset Или вы что-то другое имели в виду?

Если я правильно понял, то KSergey9 имел ввиду такое:

0

Сообщение от DrOffset Да? Если да, то чем же это лучше?

Да.
Это принуждает к порядку.

Сообщение от DrOffset и ошибкоопасный микроконтроль

Я не вижу опасности (вот именно опасности), ибо все проблемы вылезают на этапе компиляции.
Проблем при добавлении нового include - добавляет, да.

Добавлено через 27 секунд

Сообщение от Алексей1153 это правильный вариант

Зависит от научной школы, которая на данный момент платит вам зарплату

0

Сообщение от KSergey9 Это принуждает к порядку.

В большом проекте это превратится в ад. Беспорядок уже будет на уровне cpp, где первые несколько экранов будут только перечислены заголовочные файлы от которых он зависит, причем в строго определенном порядке, иначе все сломается.
А, допустим, изменение заголовочного файла приведет к ручному изменению всех cpp, куда он добавлен, опять же со строгим соблюдением порядка.

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

Короче говоря, в классической системе раздельной компиляции С\С++ этому подходу почти нет места. В серьезных проектах он выльется в колоссальные трудозатраты по сопровождению кода, потому что по сути мы забрали у компилятора его работу и делаем ее теперь вручную.

Сообщение от KSergey9 Зависит от научной школы

В мире, где такими вещами заправляет "школа" (почти как секта), а не обоснованная техническая потребность, лучше находиться как можно меньше.

Добавлено через 1 минуту

Сообщение от Optimus11 Если я правильно понял, то KSergey9 имел ввиду такое:

Как он сам выше подтвердил, он имел в виду прямо противоположное.

2