Сообщение Re[7]: Нужна ли защита от повторного включения от 21.01.2022 20:33
Изменено 21.01.2022 21:02 Андрей Тарасевич
Re[7]: Нужна ли защита от повторного включения
Здравствуйте, VladFein, Вы писали:
У>>>Теоретически, pragma once должна быть быстрее, так как компилятор даже не будет открывать повторно этот файл, а в случае с гардами таки надо препроцессировать. Поэтому — pragma once. А гарды — на всякий случай, вдруг попадётся компилятор, в котором её нет. Хотя, конечно, это маловероятно, поэтому я стал ленится делать гарды
АТ>>`#pragma once` не выжила именно именно потому, что в %99.9 случаев использование include guards является тотальным по отношению к включаемому файлу, то есть полностью функционально эквивалентным `#pragma once`. Такое использование include guards легко распознается препроцессором, который в такой ситуации не будет делать никакого "повторного открытия" и ничего препроцессировать заново не будет.
АТ>>Другими словами, если препроцессор в состоянии реализовать предполагаемую функциональность `#pragma once`, то он в состоянии реализовать все это и без `#pragma once`- на основе умной обработки include guards. Именно потому от `#pragma once` и отказались.
VF>Вы говорите, что компилятор "хранит" пре-процессед инклуды?
Не понял. Я не знаю, что делает ваш компилятор. И зачем "хранить пре-процессед инклуды"? Что такое "хранить пре-процессед инклуды"?
Я лишь говорю, что вся идея, вся суть `#pragma once` заключается именно и только в том, чтобы хранить имена уже просмотренных в данной единице трансляции инклудов и не открывать и не парсить их второй раз. Как же еще? Хранить нужно только условные идентификаторы файлов, то есть "имена". Никакие "пре-процессед инклуды" хранить не нужно.
Если какой-то компилятор умеет такое делать для `#pragma once`, то он прекрасно сумеет это сделать и для тривиальных применений include guards. То есть никакого преимущества `#pragma once` не предоставляет (кроме того, что в include guards нужно придумывать уникальный идентификатор).
VF>Я не понимаю такой момент: когда компилятор встречает
VF>#include "x.h"
VF>он ДОЛЖЕН открыть этот файл? И, встретив #ifdef — должен найти парный #endif?
VF>И это все — даром (по времени)?
Кому "должен"?
См. выше. Если компилятор уверен, что этот `#include "x.h"` ссылается на уже пропарсенный в этой единице трансляции файл и в этом файле содержится `#pragma once` или тривиальные include guards, то он может второй раз его не открывать и не парсить. Зачем?
Но это все — вопрос качества реализации, которые пользователя не касаются. Вы просто не будете знать, открывал он его второй раз или нет. Вам это не нужно знать.
У>>>Теоретически, pragma once должна быть быстрее, так как компилятор даже не будет открывать повторно этот файл, а в случае с гардами таки надо препроцессировать. Поэтому — pragma once. А гарды — на всякий случай, вдруг попадётся компилятор, в котором её нет. Хотя, конечно, это маловероятно, поэтому я стал ленится делать гарды
АТ>>`#pragma once` не выжила именно именно потому, что в %99.9 случаев использование include guards является тотальным по отношению к включаемому файлу, то есть полностью функционально эквивалентным `#pragma once`. Такое использование include guards легко распознается препроцессором, который в такой ситуации не будет делать никакого "повторного открытия" и ничего препроцессировать заново не будет.
АТ>>Другими словами, если препроцессор в состоянии реализовать предполагаемую функциональность `#pragma once`, то он в состоянии реализовать все это и без `#pragma once`- на основе умной обработки include guards. Именно потому от `#pragma once` и отказались.
VF>Вы говорите, что компилятор "хранит" пре-процессед инклуды?
Не понял. Я не знаю, что делает ваш компилятор. И зачем "хранить пре-процессед инклуды"? Что такое "хранить пре-процессед инклуды"?
Я лишь говорю, что вся идея, вся суть `#pragma once` заключается именно и только в том, чтобы хранить имена уже просмотренных в данной единице трансляции инклудов и не открывать и не парсить их второй раз. Как же еще? Хранить нужно только условные идентификаторы файлов, то есть "имена". Никакие "пре-процессед инклуды" хранить не нужно.
Если какой-то компилятор умеет такое делать для `#pragma once`, то он прекрасно сумеет это сделать и для тривиальных применений include guards. То есть никакого преимущества `#pragma once` не предоставляет (кроме того, что в include guards нужно придумывать уникальный идентификатор).
VF>Я не понимаю такой момент: когда компилятор встречает
VF>#include "x.h"
VF>он ДОЛЖЕН открыть этот файл? И, встретив #ifdef — должен найти парный #endif?
VF>И это все — даром (по времени)?
Кому "должен"?
См. выше. Если компилятор уверен, что этот `#include "x.h"` ссылается на уже пропарсенный в этой единице трансляции файл и в этом файле содержится `#pragma once` или тривиальные include guards, то он может второй раз его не открывать и не парсить. Зачем?
Но это все — вопрос качества реализации, которые пользователя не касаются. Вы просто не будете знать, открывал он его второй раз или нет. Вам это не нужно знать.
Re[7]: Нужна ли защита от повторного включения
Здравствуйте, VladFein, Вы писали:
У>>>Теоретически, pragma once должна быть быстрее, так как компилятор даже не будет открывать повторно этот файл, а в случае с гардами таки надо препроцессировать. Поэтому — pragma once. А гарды — на всякий случай, вдруг попадётся компилятор, в котором её нет. Хотя, конечно, это маловероятно, поэтому я стал ленится делать гарды
АТ>>`#pragma once` не выжила именно именно потому, что в %99.9 случаев использование include guards является тотальным по отношению к включаемому файлу, то есть полностью функционально эквивалентным `#pragma once`. Такое использование include guards легко распознается препроцессором, который в такой ситуации не будет делать никакого "повторного открытия" и ничего препроцессировать заново не будет.
АТ>>Другими словами, если препроцессор в состоянии реализовать предполагаемую функциональность `#pragma once`, то он в состоянии реализовать все это и без `#pragma once`- на основе умной обработки include guards. Именно потому от `#pragma once` и отказались.
VF>Вы говорите, что компилятор "хранит" пре-процессед инклуды?
Не понял. Я не знаю, что делает ваш компилятор. И зачем "хранить пре-процессед инклуды"? Что такое "хранить пре-процессед инклуды"?
Я лишь говорю, что вся идея, вся суть `#pragma once` заключается именно и только в том, чтобы хранить имена (или внутренние уникальные идентификаторы) уже просмотренных в данной единице трансляции инклудов и не открывать и не парсить их второй раз. Как же еще? Хранить нужно только уникальные идентификаторы файлов (имена, inode иди что-то в этом роде). Никакие "пре-процессед инклуды" хранить не нужно.
Если какой-то компилятор умеет такое делать для `#pragma once`, то он прекрасно сумеет это сделать и для тривиальных применений include guards. То есть никакого преимущества `#pragma once` не предоставляет (кроме того, что в include guards нужно придумывать уникальный идентификатор).
VF>Я не понимаю такой момент: когда компилятор встречает
VF>#include "x.h"
VF>он ДОЛЖЕН открыть этот файл? И, встретив #ifdef — должен найти парный #endif?
VF>И это все — даром (по времени)?
Кому "должен"?
См. выше. Если компилятор уверен, что этот `#include "x.h"` ссылается на уже пропарсенный в этой единице трансляции файл и в этом файле содержится `#pragma once` или тривиальные include guards, то он может второй раз его не открывать и не парсить. Зачем?
Но это все — вопрос качества реализации, которые пользователя не касаются. Вы просто не будете знать, открывал он его второй раз или нет. Вам это не нужно знать.
У>>>Теоретически, pragma once должна быть быстрее, так как компилятор даже не будет открывать повторно этот файл, а в случае с гардами таки надо препроцессировать. Поэтому — pragma once. А гарды — на всякий случай, вдруг попадётся компилятор, в котором её нет. Хотя, конечно, это маловероятно, поэтому я стал ленится делать гарды
АТ>>`#pragma once` не выжила именно именно потому, что в %99.9 случаев использование include guards является тотальным по отношению к включаемому файлу, то есть полностью функционально эквивалентным `#pragma once`. Такое использование include guards легко распознается препроцессором, который в такой ситуации не будет делать никакого "повторного открытия" и ничего препроцессировать заново не будет.
АТ>>Другими словами, если препроцессор в состоянии реализовать предполагаемую функциональность `#pragma once`, то он в состоянии реализовать все это и без `#pragma once`- на основе умной обработки include guards. Именно потому от `#pragma once` и отказались.
VF>Вы говорите, что компилятор "хранит" пре-процессед инклуды?
Не понял. Я не знаю, что делает ваш компилятор. И зачем "хранить пре-процессед инклуды"? Что такое "хранить пре-процессед инклуды"?
Я лишь говорю, что вся идея, вся суть `#pragma once` заключается именно и только в том, чтобы хранить имена (или внутренние уникальные идентификаторы) уже просмотренных в данной единице трансляции инклудов и не открывать и не парсить их второй раз. Как же еще? Хранить нужно только уникальные идентификаторы файлов (имена, inode иди что-то в этом роде). Никакие "пре-процессед инклуды" хранить не нужно.
Если какой-то компилятор умеет такое делать для `#pragma once`, то он прекрасно сумеет это сделать и для тривиальных применений include guards. То есть никакого преимущества `#pragma once` не предоставляет (кроме того, что в include guards нужно придумывать уникальный идентификатор).
VF>Я не понимаю такой момент: когда компилятор встречает
VF>#include "x.h"
VF>он ДОЛЖЕН открыть этот файл? И, встретив #ifdef — должен найти парный #endif?
VF>И это все — даром (по времени)?
Кому "должен"?
См. выше. Если компилятор уверен, что этот `#include "x.h"` ссылается на уже пропарсенный в этой единице трансляции файл и в этом файле содержится `#pragma once` или тривиальные include guards, то он может второй раз его не открывать и не парсить. Зачем?
Но это все — вопрос качества реализации, которые пользователя не касаются. Вы просто не будете знать, открывал он его второй раз или нет. Вам это не нужно знать.