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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#150217

On 25/02/2020 00:24, Thiago Adams wrote:
> 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 
> 

That is one way to handle pragma once (modulo concerns about the
uniqueness of "full paths", as Keith covered in his reply).  However, it
is not the only way to do it.  Identical text is another way that is
used, identical inodes (only applicable on some OS's, obviously) is
another way.

What about :

// a.h
#pragma once
#include "b.h"

// b.h
#ifdef PROBLEM
#define FOO 1
#else
#define FOO 2
#endif


// c.c
#define PROBLEM
#include "a.h"
int foo1 = FOO;
#undef FOO
#undef PROBLEM
#include "a.h"
int foo2 = FOO;


The text included for "a.h" should have very different effects the two
times it is included.  For some compilers, the "#pragma once" will mean
the second "#include "a.h"" is skipped and FOO remains undefined.  For
others, it will be considered a different file and included a second time.


In most realistic use-cases, "#pragma once" will just work - it will do
what you expect.  But it is not standardised, and not well-defined for
unusual situations or corner cases.  If you are careful only to use it
in cases where it is blindingly obvious what it should do, then it will
work fine.  In more complex situations you really want to stick to
include guards, where the details are clear and unambiguous.

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

#150216

> As you have said elsethread.
> But "almost any compiler" is not "EVERY compiler"

Those who can't are exotic compilers which aren't relevant.

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

#150218

On 25/02/2020 08:12, Bonita Montero wrote:
>> As you have said elsethread.
>> But "almost any compiler" is not "EVERY compiler"
> 
> Those who can't are exotic compilers which aren't relevant.
> 

Maybe these "exotic" compilers aren't relevant to you, but they are very
relevant to people who use them.  If you think the world revolves around
Windows programming with MSVC, go to an MSVC-specific forum.  This is
comp.lang.c, where any kind of C compiler is as relevant as any other.

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

#150220

> Maybe these "exotic" compilers aren't relevant to you, but they are very
> relevant to people who use them.  If you think the world revolves around
> Windows programming with MSVC, go to an MSVC-specific forum.  This is
> comp.lang.c, where any kind of C compiler is as relevant as any other.

And I've never seen anyone here who reported to use such an exotic
compiler.

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

#150231

On 25/02/2020 10:35, Bonita Montero wrote:
>> Maybe these "exotic" compilers aren't relevant to you, but they are very
>> relevant to people who use them.  If you think the world revolves around
>> Windows programming with MSVC, go to an MSVC-specific forum.  This is
>> comp.lang.c, where any kind of C compiler is as relevant as any other.
> 
> And I've never seen anyone here who reported to use such an exotic
> compiler.
> 

I have used "exotic compilers" regularly over the years - as have a good
many people in this group.  I have maybe 10-15 different C compilers
installed on my machines, not counting different versions.  A couple
were bought on 5¼" floppies.  I don't use the older ones much, but
occasionally I need to maintain ancient projects - I keep them all
available.

But here's the thing - I don't know which ones support "pragma once" or
not.  I don't care.  It is utterly pointless to use an unnecessary
non-standard feature that some compilers support, when there is a
perfectly good standard feature that /all/ compilers support.  (I've
nothing against using compiler-specific features if they are useful and
portability is not a concern.)

"Pragma once" is, at most, marginally more convenient than an include
guard - and comes with much vaguer semantics and lower portability.  If
MSVC (where "pragma once" is apparently noticeably faster than include
guards) is all you ever see and use, and "pragma once" works for your
projects, then you use it.  Just don't expect that the rest of the C
programming world to follow suit.

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

#150234

> I have used "exotic compilers" regularly over the years - as have a good
> many people in this group.  I have maybe 10-15 different C compilers
> installed on my machines, not counting different versions.  A couple
> were bought on 5¼" floppies.  I don't use the older ones much, but
> occasionally I need to maintain ancient projects - I keep them all
> available.

Maybe years ago, but today almost any compiler supports #pragma once.

> "Pragma once" is, at most, marginally more convenient than an include
> guard - ..

With #pragma once theres no need to preprocess-parse the header for an
#endif, so compiling is faster.

> guard - and comes with much vaguer semantics and lower portability.  If
> MSVC (where "pragma once" is apparently noticeably faster than include
> guards) is all you ever see ...

https://en.wikipedia.org/wiki/Pragma_once#Portability

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

#150242

On 25/02/2020 13:50, Bonita Montero wrote:
>> I have used "exotic compilers" regularly over the years - as have a good
>> many people in this group.  I have maybe 10-15 different C compilers
>> installed on my machines, not counting different versions.  A couple
>> were bought on 5¼" floppies.  I don't use the older ones much, but
>> occasionally I need to maintain ancient projects - I keep them all
>> available.
> 
> Maybe years ago, but today almost any compiler supports #pragma once.
> 

You really have no idea, do you?  Most C programmers use one of the 
major compilers (which, as Wikipedia says and you accept without any 
personal experience, support "pragma once").  Most C compilers, on the 
other hand, probably don't support it.  That will include C compilers 
written or bought /today/ as well.  Most C compilers are small, niche 
products for unusual targets or unusual needs.

>> "Pragma once" is, at most, marginally more convenient than an include
>> guard - ..
> 
> With #pragma once theres no need to preprocess-parse the header for an
> #endif, so compiling is faster.

Big, serious compilers have particularly fast handling of include 
guards, and will not pre-process the file beyond matching up the #endif. 
  For #pragma once, the compiler has to make sure it is dealing with the 
same file - depending on how that is determined (since it can be handled 
in many ways - there is no standard here) that can mean generating and 
comparing hashes for the files.  It is unlikely that you will get any 
measurable difference either way.

The exception, perhaps, is MSVC - which (AFAIUI) handles "pragma once" 
measurably faster than include guards.  And even there I think this only 
applies to older versions of the compiler, meaning there is even less 
point is using non-standard and unreliable #pragma once.

(In practice, speed issues only apply to C++, since C headers are 
generally too small to be relevant in the timing.)

> 
>> guard - and comes with much vaguer semantics and lower portability.  If
>> MSVC (where "pragma once" is apparently noticeably faster than include
>> guards) is all you ever see ...
> 
> https://en.wikipedia.org/wiki/Pragma_once#Portability

Yes, I have seen it.  It covers a tiny fraction of the C compilers that 
people use (though it does cover the compilers that a large fraction of 
C programmers use).  But even if it is supported by the compiler, why 
use it?  Include guards are simple, standard, well-defined and efficient.

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

#150243

> You really have no idea, do you?  Most C programmers use one of the 
> major compilers (which, as Wikipedia says and you accept without any 
> personal experience, support "pragma once").  Most C compilers, on the 
> other hand, probably don't support it.

You're guessing.

> Big, serious compilers have particularly fast handling of include 
> guards, ...

No, they handle it like every other #ifdef.

> For #pragma once, the compiler has to make sure it is dealing with the 
> same file - depending on how that is determined (since it can be handled 
> in many ways - there is no standard here) that can mean generating and 
> comparing hashes for the files.  It is unlikely that you will get any 
> measurable difference either way.

Matching the path is sufficient in a clean project.

> The exception, perhaps, is MSVC - which (AFAIUI) handles "pragma once" 
> measurably faster than include guards.

Every compiler that does support #pragma once is significantly faster
here.

> Yes, I have seen it.  It covers a tiny fraction of the C compilers that 
> people use (though it does cover the compilers that a large fraction of 
> C programmers use).

It covers almost the complete distributuion of used compilers.
There's a list of C-compilers in the Wikipedia also, but for these
exotic compilers there's mostly not even the guarantee of conformance
to any standard. So what ?

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

#150244

On 25/02/2020 18:38, Bonita Montero wrote:
...

Read the Wikipedia article yourself to see why pragma once can be a bad 
idea.  Time it yourself to see if it is faster than include guards for 
/your/ code with /your/ compiler.

This is the end of a pointless branch of this thread.

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

#150245

> Read the Wikipedia article yourself to see why pragma once can be a bad 
> idea.

That's unlikely.

> Time it yourself to see if it is faster than include guards for  /your/ code with /your/ compiler.

I don't need to time it. With include-guards the compiler would parse
the whole header for preprocessor-directives and there's no short-cut
you suggested. With #pragma once the compiler will only need to parse
the first line of the header.

> This is the end of a pointless branch of this thread.

This is a list of C-compilers:
https://en.wikipedia.org/wiki/List_of_compilers#C_compilers
Which compiler in this list is beyond that in the former list
and relevant today ?

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

#150247

On 25/02/2020 17:46, Bonita Montero wrote:
>> Read the Wikipedia article yourself to see why pragma once can be a 
>> bad idea.
> 
> That's unlikely.
> 
>> Time it yourself to see if it is faster than include guards for  
>> /your/ code with /your/ compiler.
> 
> I don't need to time it. With include-guards the compiler would parse
> the whole header for preprocessor-directives and there's no short-cut
> you suggested. With #pragma once the compiler will only need to parse
> the first line of the header.

Probably not even the first line. If it has already seen a header H with 
its '#pragma once' the first time, and compiled that header, then if the 
program includes H again, it will already know not to process it again.

In any case, '#pragma once' need not be on the first line; it can be 
anywhere in the file, incuding at the end. (And, ironically, can be 
specified more than once.)

(FWIW my own C compiler ignores '#pragma once'. Although it doesn't need 
it because parsing headers is very fast anyway, with or without guards, 
there can be problems when programs /rely/ on '#pragma once' to avoid 
compile errors.

So I may add it when I've got some time.)

 > I don't need to time it. With include-guards the compiler would parse
 > the whole header for preprocessor-directives and there's no short-cut

The way I do it, false blocks of #if/#ifdef do not need normal parsing; 
tokenising is sufficient. But even then, it can use streamlined 
tokenising as it is only interested in the next #-directive to see if it 
is a matching #else, #elif or #endif.

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

#150250

On 25/02/2020 20:35, Bart wrote:
> On 25/02/2020 17:46, Bonita Montero wrote:
>>> Read the Wikipedia article yourself to see why pragma once can be a 
>>> bad idea.
>>
>> That's unlikely.

Unlikely that you'll read the article?  Yes, I can agree on that.  Your 
eyes might glaze over it, but understanding will escape you.

>>
>>> Time it yourself to see if it is faster than include guards for 
>>> /your/ code with /your/ compiler.
>>
>> I don't need to time it. With include-guards the compiler would parse
>> the whole header for preprocessor-directives and there's no short-cut
>> you suggested. With #pragma once the compiler will only need to parse
>> the first line of the header.
> 
> Probably not even the first line. If it has already seen a header H with 
> its '#pragma once' the first time, and compiled that header, then if the 
> program includes H again, it will already know not to process it again.

Yes. that seems likely.

> 
> In any case, '#pragma once' need not be on the first line; it can be 
> anywhere in the file, incuding at the end. (And, ironically, can be 
> specified more than once.)
> 
> (FWIW my own C compiler ignores '#pragma once'. Although it doesn't need 
> it because parsing headers is very fast anyway, with or without guards, 
> there can be problems when programs /rely/ on '#pragma once' to avoid 
> compile errors.
> 
> So I may add it when I've got some time.)

It is probably a good idea to throw an error on it if you don't 
implement it in a way that people expect.  You have the choice (in the 
sense of "the C standard says") of ignoring such unrecognised or 
unimplemented pragmas, or claiming you recognize them and they have the 
implementation-defined behaviour of halting with an error.

> 
>  > I don't need to time it. With include-guards the compiler would parse
>  > the whole header for preprocessor-directives and there's no short-cut
> 
> The way I do it, false blocks of #if/#ifdef do not need normal parsing; 
> tokenising is sufficient. But even then, it can use streamlined 
> tokenising as it is only interested in the next #-directive to see if it 
> is a matching #else, #elif or #endif.

Exactly.  This will be done very quickly by most serious compilers. 
Even gcc :-)

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

#150260

> In any case, '#pragma once' need not be on the first line; it can be 
> anywhere in the file, incuding at the end. (And, ironically, can be 
> specified more than once.)

I've seen #pragma once often, and it was always at the beginning.

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

#150249

Bonita Moreno wrote:
> Matching the path is sufficient in a clean project.

Perhaps that's part of your definition of a "clean project",
but if so, there's a lot of dirty projects out there. During
a previous discussion of this issue, some participants
created some scripts to check for such things. They found
that many, probably most, typical Unix-like platforms have
hundreds of cases where exactly the same header file could
be found using many different full paths. This was due to
hard file links, sybolic file links, sybolic directory links
on one or more of the path components, or even just simple
file copies. This isn't a problem for #include directives,
which explains why such things exist. It would be a problem
for #pragma once, if it only uses path matching.

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

#150248

David Brown wrote:
> On 25/02/2020 13:50, Bonita Montero wrote:
[Restoring attribution missing from Bonitas message
> David Brown wrote:
>>> I have used "exotic compilers" regularly over the years - as have a good
>>> many people in this group.  I have maybe 10-15 different C compilers
>>> installed on my machines, not counting different versions.  A couple
>>> were bought on 5¼" floppies.  I don't use the older ones much, but
>>> occasionally I need to maintain ancient projects - I keep them all
>>> available.
>>
>> Maybe years ago, but today almost any compiler supports #pragma once.
>>
> You really have no idea, do you?  Most C programmers use one of the
> major compilers (which, as Wikipedia says and you accept without any
> personal experience, support "pragma once").  Most C compilers, on the
> other hand, probably don't support it.  That will include C compilers
> written or bought /today/ as well.  Most C compilers are small, niche
> products for unusual targets or unusual needs. 

You yourself said earlier that you weren't sure which of the many
compilers you have access to supported #pragma once. It shouldn't
be difficult to check, and posting the results from such an
investigation would help your case significantly. Of couse,
Bonita will dismiss any compiler you identify as unimportant, but
the rest of us will know you've made you point.

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

#150251

On 25/02/2020 20:55, James Kuyper wrote:
> David Brown wrote:
>> On 25/02/2020 13:50, Bonita Montero wrote:
> [Restoring attribution missing from Bonitas message
>> David Brown wrote:
>>>> I have used "exotic compilers" regularly over the years - as have a good
>>>> many people in this group.  I have maybe 10-15 different C compilers
>>>> installed on my machines, not counting different versions.  A couple
>>>> were bought on 5¼" floppies.  I don't use the older ones much, but
>>>> occasionally I need to maintain ancient projects - I keep them all
>>>> available.
>>>
>>> Maybe years ago, but today almost any compiler supports #pragma once.
>>>
>> You really have no idea, do you?  Most C programmers use one of the
>> major compilers (which, as Wikipedia says and you accept without any
>> personal experience, support "pragma once").  Most C compilers, on the
>> other hand, probably don't support it.  That will include C compilers
>> written or bought /today/ as well.  Most C compilers are small, niche
>> products for unusual targets or unusual needs.
> 
> You yourself said earlier that you weren't sure which of the many
> compilers you have access to supported #pragma once. It shouldn't
> be difficult to check, and posting the results from such an
> investigation would help your case significantly. Of couse,
> Bonita will dismiss any compiler you identify as unimportant, but
> the rest of us will know you've made you point.
> 

I am very confident that some of my oldest compilers won't support 
"pragma once" - that includes a compiler for the HPC46003, one for the 
COP8, and a poor PIC compiler I have somewhere.  I have an AVR compiler 
from ImageCraft that I strongly doubt supports it - I can't easily test 
that one without digging out an ancient hard drive with the correct 
serial number (for the software license checks).  Of my more modern 
obscure tools, I expect my Metrowerks compilers do support it, but I am 
a lot less sure about my TI compilers.

In my daily work, I use gcc most of the time these days - I have access 
to all the other tools for supporting existing projects, but activating 
them just to test for a feature I will never use is more effort than it 
is worth.

I have colleagues that make more use of limited compilers, and I know 
there are all sorts of really odd compilers around.  I have used 
compilers for devices with 24-bit int, and compilers for devices with no 
ram.  I have used one that didn't come with any header files or standard 
library files - these are all built into the monolithic 
compiler-assembler-linker tool.  (To my knowledge, that is still the 
best compiler available for the microcontroller in question - a family 
that is still made and sold today.)

As I say, most of these I only have for maintaining old code.  For new 
code, "pragma once" would work fine for me - but give no advantage.  But 
there are other people who do use such tools for code written now.

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

#150256

David Brown <david.brown@hesbynett.no> writes:
>On 25/02/2020 10:35, Bonita Montero wrote:
>>> Maybe these "exotic" compilers aren't relevant to you, but they are very
>>> relevant to people who use them.  If you think the world revolves around
>>> Windows programming with MSVC, go to an MSVC-specific forum.  This is
>>> comp.lang.c, where any kind of C compiler is as relevant as any other.
>> 
>> And I've never seen anyone here who reported to use such an exotic
>> compiler.
>> 
>
>I have used "exotic compilers" regularly over the years 

David, please don't feed the troll.

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

#150257

On 26/02/2020 02:39, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 25/02/2020 10:35, Bonita Montero wrote:
>>>> Maybe these "exotic" compilers aren't relevant to you, but they are very
>>>> relevant to people who use them.  If you think the world revolves around
>>>> Windows programming with MSVC, go to an MSVC-specific forum.  This is
>>>> comp.lang.c, where any kind of C compiler is as relevant as any other.
>>> And I've never seen anyone here who reported to use such an exotic
>>> compiler.
>>>
>> I have used "exotic compilers" regularly over the years
> David, please don't feed the troll.

Where is fun in that?

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

#150294

On Tuesday, February 25, 2020 at 7:02:29 PM UTC-8, Real Troll wrote:
> On 26/02/2020 02:39, Scott Lurndal wrote:
> > David Brown <david.brown@hesbynett.no> writes:
> >> On 25/02/2020 10:35, Bonita Montero wrote:
> >>>> Maybe these "exotic" compilers aren't relevant to you, but they are very
> >>>> relevant to people who use them.  If you think the world revolves around
> >>>> Windows programming with MSVC, go to an MSVC-specific forum.  This is
> >>>> comp.lang.c, where any kind of C compiler is as relevant as any other.
> >>> And I've never seen anyone here who reported to use such an exotic
> >>> compiler.
> >>>
> >> I have used "exotic compilers" regularly over the years
> > David, please don't feed the troll.
> 
> Where is fun in that?

Pull my finger.

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

#150207

On Mon, 2020-02-24, 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?

Yes.  The cost is low, and it's the least surprising and most safe
thing to do.

(Then there's the people who advocate #pragma only ...)

/Jorgen

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

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web