#następująca składnia dla włączających strażników w C++

Question

Aktualnie studiuję na końcowym egzaminie z kursu CS i natknąłem się na mniejszy (być może poważny?) Problem dotyczący składni C++ #ifndef.

Szukałem w składni #infndef podczas używania go jako #include straży, a najbardziej w sieci wydaje się mówić:

#ifndef HEADER_H 
#define "header.h" 
... 
#endif 

Ale slajdy TUTORIAL moja klasa pokazują przykłady jak:

#ifndef __HEADER_H__ 
#define "header.h" 
... 
#endif 

Zastanawiam się, co (jeśli w ogóle) różnica między nimi. Egzamin najprawdopodobniej poprosi mnie o napisanie # strażnika, a ja wiem, że konwencjonalna mądrość polega właśnie na tym, co mówi prof/tutor, ale jeśli podczas kompilacji jest różnica, chciałbym to wiedzieć.

Answer 1

Powszechnie stosowaną praktyką jest nie wpisywanie żadnego z nich i umieszczenie w nim pliku w pliku nagłówkowym, ponieważ redukuje on liczbę powtórzeń. np .:

header.h

#ifndef HEADER_H 
#define HEADER_H 

// Rest of header file contents go here 

#endif 

Dokładnie to, czego użyć jako nazwę makra jest w dół do konkretnego standardu kodowania. Istnieją jednak subtelne reguły w standardach C i C++, które uniemożliwiają korzystanie z identyfikatorów zaczynających się od podkreśleń, , więc powinieneś unikać __HEADER_H__, aby być po bezpiecznej stronie.

Warto również wspomnieć, że powinieneś wybrać coś, co raczej nie koliduje z niczym innym w bazie kodu. Na przykład, jeśli zdarzyło Ci się mieć zmienną o nazwie HEADER_H w innym miejscu (mało prawdopodobne, zdaję sobie z tego sprawę), to skończyłoby się na kilku irytujących błędach.

---

_{1. Zobacz np. sekcja 7.1.3 normy C99.}

Answer 2

Nie ma różnicy, jeśli nie użyjesz podkreślenia w nazwach zmiennych gdziekolwiek indziej, to tylko konwencja nazewnictwa.

Wystarczy umieścić coś wyjątkowego.

Answer 3

Nazwy zaczynające się od podwójnego podkreślenia są zarezerwowane dla implementacji, więc odradzam używanie __SOMETHING w twoich załącznikach. Spróbuj także wybrać nazwy, które sprawiają, że starcia są mało prawdopodobne. Wygląda więc na to, że tutoriale twojej klasy są błędne przynajmniej na dwa razy. Zobacz na przykład: humorous article.

Answer 4

Argumentem za umieszczeniem osłon włączających w pliku, który zawiera nagłówek, a nie w samym nagłówku, jest to, że jeśli plik został już dołączony, kompilator (konkretnie preprocesor) nie musi otwierać i czytać ponownie dołącz plik.

To jest słaby argument. W praktyce zaoszczędzony czas jest banalny, a potencjał błędu jest duży.

W przykładzie:

#ifndef HEADER_H 
#include "header.h" 
... 
#endif 

nie pokazują nam #define HEADER_H. Czy to gdzieś w header.h?Jeśli tak, to skąd wiadomo, że autor header.h wybrał użycie nazwy HEADER_H jako nazwy makra obsługującego zabezpieczenia? Co się stanie, jeśli później zmieni się coś innego?

Jeśli zdecydujesz się umieścić obejmują strażnika w tym pliku, należy zdefiniować makro również tam:

#ifndef HEADER_H 
#include "header.h" 
#define HEADER_H 
#endif 

Ale, jak inne odpowiedzi już powiedziałem, to dużo lepiej umieścić strażnik w nagłówku samego:

header.h:

#ifndef HEADER_H 
#define HEADER_H 
/* contents of header.h */ 
#endif 

a następnie obejmuje po prostu:

#include "header.h" 

i ma o jeden mniej informacji martwić się.