Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #150198 > unrolled thread

Concerning the necessity of include guards

Back to article view | Back to comp.lang.c

Contents

  Concerning the necessity of include guards Anton Shepelev <anton.txt@gmail.com> - 2020-02-24 22:08 +0300
    Re: Concerning the necessity of include guards Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-24 20:28 +0100
    Re: Concerning the necessity of include guards Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-24 19:40 +0000
      Re: Concerning the necessity of include guards David Brown <david.brown@hesbynett.no> - 2020-02-24 22:37 +0100
        Re: Concerning the necessity of include guards Anton Shepelev <anton.txt@g{oogle}mail.com> - 2020-02-25 14:13 +0300
          Re: Concerning the necessity of include guards David Brown <david.brown@hesbynett.no> - 2020-02-25 13:03 +0100
            Re: Concerning the necessity of include guards Anton Shepelev <anton.txt@gmail.com> - 2020-02-29 01:14 +0300
              Re: Concerning the necessity of include guards Bart <bc@freeuk.com> - 2020-02-28 22:36 +0000
                Re: Concerning the necessity of include guards Anton Shepelev <anton.txt@gmail.com> - 2020-02-29 13:28 +0300
              Re: Concerning the necessity of include guards Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-29 00:08 +0000
              Re: Concerning the necessity of include guards Richard Damon <Richard@Damon-Family.org> - 2020-02-29 07:05 -0500
              Re: Concerning the necessity of include guards David Brown <david.brown@hesbynett.no> - 2020-03-01 15:01 +0100
    Re: Concerning the necessity of include guards Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-02-24 14:52 -0500
      Re: Concerning the necessity of include guards Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-24 21:19 +0100
        Re: Concerning the necessity of include guards Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-02-24 15:48 -0500
          Re: Concerning the necessity of include guards Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-24 21:53 +0100
            Re: Concerning the necessity of include guards Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-02-24 17:26 -0500
              Re: Concerning the necessity of include guards David Brown <david.brown@hesbynett.no> - 2020-02-25 00:08 +0100
                Re: Concerning the necessity of include guards Thiago Adams <thiago.adams@gmail.com> - 2020-02-24 15:24 -0800
                  Re: Concerning the necessity of include guards Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-24 22:20 -0800
                  Re: Concerning the necessity of include guards David Brown <david.brown@hesbynett.no> - 2020-02-25 09:52 +0100
              Re: Concerning the necessity of include guards Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-25 08:12 +0100
                Re: Concerning the necessity of include guards David Brown <david.brown@hesbynett.no> - 2020-02-25 09:55 +0100
                  Re: Concerning the necessity of include guards Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-25 10:35 +0100
                    Re: Concerning the necessity of include guards David Brown <david.brown@hesbynett.no> - 2020-02-25 13:13 +0100
                      Re: Concerning the necessity of include guards Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-25 13:50 +0100
                        Re: Concerning the necessity of include guards David Brown <david.brown@hesbynett.no> - 2020-02-25 18:33 +0100
                          Re: Concerning the necessity of include guards Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-25 18:38 +0100
                            Re: Concerning the necessity of include guards David Brown <david.brown@hesbynett.no> - 2020-02-25 18:42 +0100
                              Re: Concerning the necessity of include guards Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-25 18:46 +0100
                                Re: Concerning the necessity of include guards Bart <bc@freeuk.com> - 2020-02-25 19:35 +0000
                                  Re: Concerning the necessity of include guards David Brown <david.brown@hesbynett.no> - 2020-02-25 21:18 +0100
                                  Re: Concerning the necessity of include guards Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-26 06:40 +0100
                            Re: Concerning the necessity of include guards James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-25 12:12 -0800
                          Re: Concerning the necessity of include guards James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-25 11:55 -0800
                            Re: Concerning the necessity of include guards David Brown <david.brown@hesbynett.no> - 2020-02-25 21:37 +0100
                      Re: Concerning the necessity of include guards scott@slp53.sl.home (Scott Lurndal) - 2020-02-26 02:39 +0000
                        Re: Concerning the necessity of include guards Real Troll <real.troll@trolls.com> - 2020-02-25 23:10 -0400
                          Re: Concerning the necessity of include guards chad <cdalten@gmail.com> - 2020-02-27 05:39 -0800
    Re: Concerning the necessity of include guards Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-24 22:23 +0000
    Re: Concerning the necessity of include guards Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-24 21:17 -0800
      Re: Concerning the necessity of include guards Guillaume <message@bottle.org> - 2020-02-25 13:03 +0100

Page 1 of 3  [1] 2 3  Next page →

#150198 — Concerning the necessity of include guards

Hello all,

A reviewer has recently declared it a fault in my library
that its .h file does not use an include guard, whereas I
deliberately decided not to use one, because the library
exports only functions, but no types.  Its header file is
therefore designed for inclusion into .c files, but not into
other .h files.

What is your opinion?  Is it good practice to wrap each and
every header file in an include guard?

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [next] | [standalone]

#150199

"#pragma once" is widely supported ([*]). Use it.

[*] https://en.wikipedia.org/wiki/Pragma_once#Portability

[toc] | [prev] | [next] | [standalone]

#150201

Anton Shepelev <anton.txt@gmail.com> writes:

> A reviewer has recently declared it a fault in my library
> that its .h file does not use an include guard, whereas I
> deliberately decided not to use one, because the library
> exports only functions, but no types.  Its header file is
> therefore designed for inclusion into .c files, but not into
> other .h files.

What "export" means is not 100% clear in C.  You mean, I think, is that
the .h file declares, and possibly defines, only functions.  If it only
declares functions (probably the usual meaning of "export"), then I
can't see how it can matter if someone includes it in another .h file.

> What is your opinion?  Is it good practice to wrap each and
> every header file in an include guard?

If there are no definitions at all, I think I wouldn't bother.  But I'd
understand if someone wants it done as a matter of habit.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#150206

On 24/02/2020 20:40, Ben Bacarisse wrote:
> Anton Shepelev <anton.txt@gmail.com> writes:
> 
>> A reviewer has recently declared it a fault in my library
>> that its .h file does not use an include guard, whereas I
>> deliberately decided not to use one, because the library
>> exports only functions, but no types.  Its header file is
>> therefore designed for inclusion into .c files, but not into
>> other .h files.
> 
> What "export" means is not 100% clear in C.  You mean, I think, is that
> the .h file declares, and possibly defines, only functions.  If it only
> declares functions (probably the usual meaning of "export"), then I
> can't see how it can matter if someone includes it in another .h file.
> 
>> What is your opinion?  Is it good practice to wrap each and
>> every header file in an include guard?
> 
> If there are no definitions at all, I think I wouldn't bother.  But I'd
> understand if someone wants it done as a matter of habit.
> 

It should not make any difference to any code using this header.  But as 
you say, many people would feel it looks more like a complete and 
ready-to-user header file if the guards are included.  Certainly it will 
be useful if other features (types, macros, etc.) are added at a later date.

Include guards also make the compilation more efficient (many compilers 
have very fast skipping of duplicate headers with include guards).  I 
can't imagine the effect will be measurable if you just have a few 
function declarations, but it can be a reason people have for such habits.

To the OP - why did you choose not to have a guard?

[toc] | [prev] | [next] | [standalone]

#150227

David Brown:

> It should not make any difference to any code using this
> header.  But as you say, many people would feel it looks
> more like a complete and ready-to-user header file if the
> guards are included.  Certainly it will be useful if other
> features (types, macros, etc.) are added at a later date.
>
> Include guards also make the compilation more efficient
> (many compilers have very fast skipping of duplicate
> headers with include guards).  I can't imagine the effect
> will be measurable if you just have a few function
> declarations, but it can be a reason people have for such
> habits.
>
> To the OP -- why did you choose not to have a guard?

To keep header as lean and clean as possible.  These guards
are mechanical boilerplate that contaminate the
declarations.  Nevertheless, I have now been reconvinced and
will add the guard to my header.  Thanks to everybody for
your replies.

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#150229

On 25/02/2020 12:13, Anton Shepelev wrote:
> David Brown:
> 
>> It should not make any difference to any code using this
>> header.  But as you say, many people would feel it looks
>> more like a complete and ready-to-user header file if the
>> guards are included.  Certainly it will be useful if other
>> features (types, macros, etc.) are added at a later date.
>>
>> Include guards also make the compilation more efficient
>> (many compilers have very fast skipping of duplicate
>> headers with include guards).  I can't imagine the effect
>> will be measurable if you just have a few function
>> declarations, but it can be a reason people have for such
>> habits.
>>
>> To the OP -- why did you choose not to have a guard?
> 
> To keep header as lean and clean as possible.  These guards
> are mechanical boilerplate that contaminate the
> declarations. 

I can appreciate that.  But I think it is easier to view the guard as
simply a standard part of a C header.

A lot of headers need more than function declarations.  You have types
to declare, and maybe macros.  You have include files to include - I
almost invariably need <stdbool.h> and <stdint.h> as a minimum.  (These
have their own include guards, so don't require guards in a header that
uses them.)  To me, a header without include guards would stand out as
being odd, as most need them.

> Nevertheless, I have now been reconvinced and
> will add the guard to my header.  Thanks to everybody for
> your replies.
> 

[toc] | [prev] | [next] | [standalone]

#150342

David Brown:

> To me, a header without include guards would stand out as
> being odd, as most need them.

From what you and others have written in this thread, it
seems to me that C would be better if it implied an include
guard by default for each header, letting the programmer
occasionally to resort to the current behavior of C in the
very rare cases when it is desired.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#150344

On 28/02/2020 22:14, Anton Shepelev wrote:
> David Brown:
> 
>> To me, a header without include guards would stand out as
>> being odd, as most need them.
> 
>  From what you and others have written in this thread, it
> seems to me that C would be better if it implied an include
> guard by default for each header, letting the programmer
> occasionally to resort to the current behavior of C in the
> very rare cases when it is desired.
> 

You might need a guard for an actual header. But not necessarily for an 
include file that is designed to be included multiple times in a source 
file.

C can't tell what is a header, and what is just an include file.

[toc] | [prev] | [next] | [standalone]

#150351

Bart to Anton Shepelev:

> > From what you and others have written in this thread, it
> > seems to me that C would be better if it implied an
> > include guard by default for each header, letting the
> > programmer occasionally to resort to the current
> > behavior of C in the very rare cases when it is desired.
>
> You might need a guard for an actual header. But not
> necessarily for an include file that is designed to be
> included multiple times in a source file.
>
> C can't tell what is a header, and what is just an include
> file.

But the programmer can.  And since, in your terminology, the
majority of include files are headers, single inclusion
should be the default behavior, and multiple inclusion a
special case needing explicit indication. Ergonomy requires
that the most frequest use shall be the simplest, shortest,
and defaultest.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#150346

On Fri, 2020-02-28, Anton Shepelev wrote:
> David Brown:
>
>> To me, a header without include guards would stand out as
>> being odd, as most need them.
>
> From what you and others have written in this thread, it
> seems to me that C would be better if it implied an include
> guard by default for each header, letting the programmer
> occasionally to resort to the current behavior of C in the
> very rare cases when it is desired.

Yes, perhaps a tiny bit better.  But we have to live with the
language as it is now (and was, for the past fifty years).

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#150353

On 2/28/20 5:14 PM, Anton Shepelev wrote:
> David Brown:
> 
>> To me, a header without include guards would stand out as
>> being odd, as most need them.
> 
>  From what you and others have written in this thread, it
> seems to me that C would be better if it implied an include
> guard by default for each header, letting the programmer
> occasionally to resort to the current behavior of C in the
> very rare cases when it is desired.
> 

One big issue with trying to make include guards implicit by default is 
that there are times when you don't want them, and while the base C 
language easily supports the mechanism for explicitly adding an include 
guard using the standard C processor statement, if would be difficult to 
define a way to 'opt out' of an implicit include guard without adding to 
the language.

The implicit include guard also runs into all the problems of
#pragma once, in that the compiler needs to figure out if a given file 
has been included more than once, especially in the face of some not so 
unusual practices with things like file structure links (so files with 
different paths might be the same file) and the possibility of multiple 
independent copies wanting to be considered 'the same' because some 
library has made its own copy of some third library, but two files with 
the same name might NOT be considered the same (which becomes a 
namespace problem for the include guards, solvable but not trivial).

[toc] | [prev] | [next] | [standalone]

#150356

On 28/02/2020 23:14, Anton Shepelev wrote:
> David Brown:
> 
>> To me, a header without include guards would stand out as
>> being odd, as most need them.
> 
>  From what you and others have written in this thread, it
> seems to me that C would be better if it implied an include
> guard by default for each header, letting the programmer
> occasionally to resort to the current behavior of C in the
> very rare cases when it is desired.
> 

Many programming languages do exactly that (and C++ will, with modules).

But it is a lot easier to define the language to require something like 
the include guards to me added manually, than to define it in a way that 
has them by default but has additional mechanisms for the occasions when 
you want multiple includes.  It is not always easy to get a system that 
does the expected thing by default but is flexible enough for odd 
situations.  (There have been attempts to do this in C, with "#import". 
They failed.)  When C was conceived, this was solved by using a very 
simple and clear mechanism for #include that means adding guards 
manually.  In a new language written today, other mechanisms would 
likely be used.

[toc] | [prev] | [next] | [standalone]

#150202

Anton Shepelev wrote:

> Hello all,
> 
> A reviewer has recently declared it a fault in my library
> that its .h file does not use an include guard, whereas I
> deliberately decided not to use one, because the library
> exports only functions, but no types.  Its header file is
> therefore designed for inclusion into .c files, but not into
> other .h files.
> 
> What is your opinion?  Is it good practice to wrap each and
> every header file in an include guard?

The term "good practice" is fairly nebulous as it means different things to 
different people. I try to stay away from terms like "good practice" unless 
I have an agreement with my audience about what it means /this time/.

Having said that, I do not think it is /necessary/ to "wrap each and every 
header file in an include guard"; doing so is a short-cut to ensure that the 
header has no harmful side-effects if #include'd more than once.

If I can assert with confidence that a header will cause no detremental 
side-effects if #include'd more than once, I see no need to add a header 
guard. However, if I have any uncertainty, then I add a header guard; it 
costs next to nothing, reduces my extra work (to prove no side-effects), and 
reduces the chances that my wrong evaluation would cause errors down the 
line.

[toc] | [prev] | [next] | [standalone]

#150203

> If I can assert with confidence that a header will cause no detremental
> side-effects if #include'd more than once, I see no need to add a header
> guard. ...

A header-guard makes including the header more than once faster.
And "#pragma once" makes it even more faster because there is no
need to find a matching #endif.

[toc] | [prev] | [next] | [standalone]

#150204

Bonita Montero wrote:

>> If I can assert with confidence that a header will cause no detremental
>> side-effects if #include'd more than once, I see no need to add a header
>> guard. ...
> 
> A header-guard makes including the header more than once faster.
> And "#pragma once" makes it even more faster because there is no
> need to find a matching #endif

Perhaps, but if I read the C11 standard correctly,
1) any pragma that doesn't include, as it's first token, STDC, "causes the
   implementation to behave in an implementation-defined manner"
   Your
     #pragma once
   and the equivalent
     _pragma once
  invokes "implementation-defined behaviour", including to /completely
  ignore/ the content or intent of the pragma, and
2) "once" (as in "#pragma once" ) is not one of the three STDC pragma
   tokens that the standard dictates that all standard-compliant compilers
   must recognize. They are, (again, according to the C11 standard)
     FP_CONTRACT
     FENV_ACCESS
   and
     CX_LIMITED_RANGE

So, your #pragma suggestion will only work on /certain/ C compilers, not 
/all/ C compilers. However, the procedural standard of guarding C headers 
with "#ifndef / #endif" should always work, so long as the compiler supports 
standard C.

If the header is for internal use, and you can guarantee the specifics of 
the compiler, I see no real problem using #pragma. However, if the header is 
for general release, or you cannot guarantee that the target compiler 
supports your "#pragma once", then it would be wise to use the more accepted 
alternative of "#ifndef / #endif" header guard.

Just my two cents worth.

[toc] | [prev] | [next] | [standalone]

#150205

>     Your
>       #pragma once
>     and the equivalent
>       _pragma once
>    invokes "implementation-defined behaviour", including to /completely
>    ignore/ the content or intent of the pragma, and

"#pragma once" is supportet by almost any compiler:
https://en.wikipedia.org/wiki/Pragma_once

[toc] | [prev] | [next] | [standalone]

#150208

Bonita Montero wrote:

>>     Your
>>       #pragma once
>>     and the equivalent
>>       _pragma once
>>    invokes "implementation-defined behaviour", including to /completely
>>    ignore/ the content or intent of the pragma, and
> 
> "#pragma once" is supportet by almost any compiler:
> https://en.wikipedia.org/wiki/Pragma_once

As you have said elsethread.

But "almost any compiler" is not "EVERY compiler"

-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#150210

On 24/02/2020 23:26, Lew Pitcher wrote:
> Bonita Montero wrote:
> 
>>>      Your
>>>        #pragma once
>>>      and the equivalent
>>>        _pragma once
>>>     invokes "implementation-defined behaviour", including to /completely
>>>     ignore/ the content or intent of the pragma, and
>>
>> "#pragma once" is supportet by almost any compiler:
>> https://en.wikipedia.org/wiki/Pragma_once
> 
> As you have said elsethread.
> 
> But "almost any compiler" is not "EVERY compiler"
> 

And the Wikipedia link shows some potential pitfalls of "#pragma once". 
For example, it is not clear how it should work if you have two copies 
of the same file in your project.  With the include guards, you know 
exactly where you stand.

I think "#pragma once" is particularly popular amongst MSVC programmers 
on Windows, because that compiler does not have as efficient short-cuts 
for include guards as many other compilers do - and when you are using 
big C++ header files, build-time efficiency is important.

[toc] | [prev] | [next] | [standalone]

#150211

On Monday, February 24, 2020 at 8:08:26 PM UTC-3, David Brown wrote:
> On 24/02/2020 23:26, Lew Pitcher wrote:
> > Bonita Montero wrote:
> > 
> >>>      Your
> >>>        #pragma once
> >>>      and the equivalent
> >>>        _pragma once
> >>>     invokes "implementation-defined behaviour", including to /completely
> >>>     ignore/ the content or intent of the pragma, and
> >>
> >> "#pragma once" is supportet by almost any compiler:
> >> https://en.wikipedia.org/wiki/Pragma_once
> > 
> > As you have said elsethread.
> > 
> > But "almost any compiler" is not "EVERY compiler"
> > 
> 
> And the Wikipedia link shows some potential pitfalls of "#pragma once". 
> For example, it is not clear how it should work if you have two copies 
> of the same file in your project.  With the include guards, you know 
> exactly where you stand.


Two copies in different paths? 
I have implemented pragma once in my transpiler and
the full path is the unique key.
When including some header I need to search it 
normally (respecting the order of directories), and 
after to find the file I check its full path against
previously "pragma once" added files 

[toc] | [prev] | [next] | [standalone]

#150215

Thiago Adams <thiago.adams@gmail.com> writes:
> On Monday, February 24, 2020 at 8:08:26 PM UTC-3, David Brown wrote:
[...]
>> And the Wikipedia link shows some potential pitfalls of "#pragma once". 
>> For example, it is not clear how it should work if you have two copies 
>> of the same file in your project.  With the include guards, you know 
>> exactly where you stand.
>
> Two copies in different paths? 
> I have implemented pragma once in my transpiler and
> the full path is the unique key.
> When including some header I need to search it 
> normally (respecting the order of directories), and 
> after to find the file I check its full path against
> previously "pragma once" added files 

But it's not always clear what "different paths" means, particularly in
the presence of symbolic links, hard links, mount points, systems on
which some file systems might be case-sensitive and some might not be,
and so forth.  Perhaps it's easy enough to avoid such issues in
practice.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web