#pragma once

[Myriachan]

I think that #pragma once should be standardized - at least partially/optionally/conditionally-supported.  Every major compiler implements it with identical or nearly-identical semantics.

Defining what it means for a file to be a repeat is rather simple: On platforms supporting symlinks and hard links, use unique inode numbers (+ device if needed).  On other platforms, use the filename.  Compilers may assume that files don't change while compiling (i.e. if the filename matches, it can be assumed to be identical).  On platforms where there exist special links to the same or parent directory, like "./" or "../" on NT and POSIX, this assumption can be extended to collapse these.

By the way, why don't _Pragma and #line support concatenating multiple strings in their respective string parameters?

Melissa

[Vittorio Romeo]

+1. It's superior to header guards in terms of maintainability, readability and (sometimes) performance. Why isn't it standard?

Vittorio Romeo

http://vittorioromeo.info

[Chet]

It has been determined that it is more difficult to implement than you would think:

http://stackoverflow.com/questions/23696115/is-pragma-once-part-of-the-c11-standard

http://stackoverflow.com/questions/1695807/why-isnt-c-cs-pragma-once-an-iso-standard

The Modules proposal aims to solve the problems of include files in a better way:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4047.pdf

--Chet

[Christopher]

By the way, why don't _Pragma and #line support concatenating multiple strings in their respective string parameters?

String concatenation happens later (Phase 6). For _Pragma, this is not too bad if you're willing to build up unquoted pp-tokens and pass them to a wrapper-macro:

#define RAW_TOKENS_PRAGMA2(...)  _Pragma(#__VA_ARGS__)
#define RAW_TOKENS_PRAGMA(...)   RAW_TOKENS_PRAGMA2(__VA_ARGS__)

[Myriachan]

On Tuesday, October 21, 2014 1:32:00 PM UTC-7, Chet wrote:

It has been determined that it is more difficult to implement than you would think:

http://stackoverflow.com/questions/23696115/is-pragma-once-part-of-the-c11-standard

http://stackoverflow.com/questions/1695807/why-isnt-c-cs-pragma-once-an-iso-standard

I had read the second one before I posted.  The only bad case I see so far is ambiguous remote mounts.  Why not just say that the behavior is unspecified if two files of different names are, in fact, the same file in a way in which the implementation cannot reliably determine?
 

The Modules proposal aims to solve the problems of include files in a better way:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4047.pdf

--Chet

Sure, but that's years off if ever, and there are billions of lines of code in projects using #pragma once now.

Melissa

[Myriachan]

Could we then define _Pragma as taking one or more string parameters (not separated by anything but possibly whitespace) that are interpreted concatenated?

Melissa

[Christopher]

Could we then define _Pragma as taking one or more string parameters (not separated by anything but possibly whitespace) that are interpreted concatenated?

I'm really curious about the original design intent: why does _Pragma take a stringized argument in the first place? When it was first added in C99, why wasn't it specified to take non-stringized tokens like the #pragma directive or MSVC's __pragma extension?

[Thiago Macieira]

On Tuesday 21 October 2014 19:01:36 Myriachan wrote:
> Sure, but that's years off if ever, and there are billions of lines of code
> in projects using #pragma once now.

So why do we need to change anything? If that code is already working, it's
working. If it's not working, then it won't magically begin working tomorrow
-- at best, it would become valid from next year on and projects wishing
compatibility would then begin using it in 2016 or 2017.

They may as well simply use include guards if they need compatibility.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[Olaf van der Spek]

On Tuesday, October 21, 2014 10:32:00 PM UTC+2, Chet wrote:

It has been determined that it is more difficult to implement than you would think:

http://stackoverflow.com/questions/23696115/is-pragma-once-part-of-the-c11-standard

http://stackoverflow.com/questions/1695807/why-isnt-c-cs-pragma-once-an-iso-standard

The Modules proposal aims to solve the problems of include files in a better way:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4047.pdf

Is it really that difficult?

If the name doesn't match an already seen file but the size does one could hash the contents and check the hash.

 

[Peter Koch Larsen]

On 10/22/14, Thiago Macieira <thi...@macieira.org> wrote:
> On Tuesday 21 October 2014 19:01:36 Myriachan wrote:
>> Sure, but that's years off if ever, and there are billions of lines of
>> code
>> in projects using #pragma once now.
> So why do we need to change anything? If that code is already working, it's
> working. If it's not working, then it won't magically begin working tomorrow
> -- at best, it would become valid from next year on and projects wishing
> compatibility would then begin using it in 2016 or 2017.
> They may as well simply use include guards if they need compatibility.

I agree with Thiago. Even if both my compilers support the once pragma
I stick to include guards. They work if you provide a meaningful name
(I include my initials and the date of construction so something like
... _PKL_2014_10_22). I believe it would save me sixty seconds to
write #pragma instead.
If include guards make your compilation slow, you should complain to
your vendor.

/Peter

[Thiago Macieira]

Just out of curiosity, why does it need to be that complex?

The include guard can be based on a rule of formation based on how the header
itself gets #included. You can't have two of such files getting included in the
same translation unit anyway.

[Peter Koch Larsen]

On Wed, Oct 22, 2014 at 4:52 PM, Thiago Macieira <thi...@macieira.org> wrote:
> On Wednesday 22 October 2014 12:39:15 Peter Koch Larsen wrote:

<snip>

>> I agree with Thiago. Even if both my compilers support the once pragma
>> I stick to include guards. They work if you provide a meaningful name
>> (I include my initials and the date of construction so something like
>> ... _PKL_2014_10_22). I believe it would save me sixty seconds to
>> write #pragma instead.
>> If include guards make your compilation slow, you should complain to
>> your vendor.
>
> Just out of curiosity, why does it need to be that complex?

You mean why I add my initials and a date? It is in my fingers - perhaps that is
the best answer. But if you include stuff from others and they are not
as rigoreous
as e.g. boost, there is a risk that a "FORMAT_HPP" is not unique. I have been
bitten by that once - even if it was a very long time ago.

/Peter

>
> The include guard can be based on a rule of formation based on how the header
> itself gets #included. You can't have two of such files getting included in the
> same translation unit anyway.

You mean something like BOOST_DETAILS_LEXICAL_CAST? You could also do
that (I am not sure this is a proper boost macro, btw). But I know
that I never create
two include-files on the same day with the same name.

/Peter

[Bo Persson]

On 2014-10-22 09:04, Olaf van der Spek wrote:
> On Tuesday, October 21, 2014 10:32:00 PM UTC+2, Chet wrote:
>
> It has been determined that it is more difficult to implement than
> you would think:
> http://stackoverflow.com/questions/23696115/is-pragma-once-part-of-the-c11-standard

> <http://stackoverflow.com/questions/23696115/is-pragma-once-part-of-the-c11-standard>
> http://stackoverflow.com/questions/1695807/why-isnt-c-cs-pragma-once-an-iso-standard

> <http://stackoverflow.com/questions/1695807/why-isnt-c-cs-pragma-once-an-iso-standard>
>
> The Modules proposal aims to solve the problems of include files in
> a better way:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4047.pdf
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4047.pdf>
>
>
> Is it really that difficult?
> If the name doesn't match an already seen file but the size does one
> could hash the contents and check the hash.
>

It really IS that difficult.

On my work computer I have mounts to several departmental servers
(located in different cities), some NAS devices that I don't even know
where they are, a ClearCase system on a Unix machine, and the file
system on a z/OS mainframe. Add a local hard disk, a DVD and some
USB-devices, and you get a real world system.

How is the standard supposed to specify what a unique file means? And
how useful is it for every existing compiler to support this?


Bo Persson

[Olaf van der Spek]

On Wed, Oct 22, 2014 at 8:29 PM, Bo Persson <b...@gmb.dk> wrote:
>> Is it really that difficult?
>> If the name doesn't match an already seen file but the size does one
>> could hash the contents and check the hash.
>>
>
> It really IS that difficult.
>
> On my work computer I have mounts to several departmental servers (located
> in different cities), some NAS devices that I don't even know where they
> are, a ClearCase system on a Unix machine, and the file system on a z/OS
> mainframe. Add a local hard disk, a DVD and some USB-devices, and you get a
> real world system.
>
> How is the standard supposed to specify what a unique file means?

See above

> And how
> useful is it for every existing compiler to support this?

Quite useful, nearly 99.99% of the headers probably need an include
guard or something better.

[Bo Persson]

One advantage of an include guard is that YOU can fix the conflicts you
run into. If the compiler's #pragma once fails to include a file, what
do you do about that?

And should the standard require all compiler developers to have a
mainframe in their test environment, so I can be sure that the pragma
works on my system?


Bo Persson

[Olaf van der Spek]

On Wed, Oct 22, 2014 at 8:43 PM, Bo Persson <b...@gmb.dk> wrote:
> One advantage of an include guard is that YOU can fix the conflicts you run
> into. If the compiler's #pragma once fails to include a file, what do you do
> about that?

File a bug report and fall back to include guards (or something else).

> And should the standard require all compiler developers to have a mainframe
> in their test environment, so I can be sure that the pragma works on my
> system?

Of course :p

[Sean Middleditch]

On Tuesday, October 21, 2014 11:02:35 PM UTC-7, Thiago Macieira wrote:

On Tuesday 21 October 2014 19:01:36 Myriachan wrote:
> Sure, but that's years off if ever, and there are billions of lines of code
> in projects using #pragma once now.

So why do we need to change anything? If that code is already working, it's

Well, there's value to having de facto standards match the de jure standard. See exported templates and their eventual removal as an example specific to C++. It's unfortunate when large codebases depend on a non-standard feature that "works" but is non-standard and then new tools that more closely follow the standard without extensions can't handle the codebase. Happens all the time with game engines in my experience, including specifically #pragma once issues.

That said, #pragma once couldn't be added to the standard any sooner than C++17, and #pragma once _isn't_ a de facto standard because different implementations work differently, and there's the problems with complex source directories Bo mentions, and... I think all the reasons why this won't work were already clearly enumerated in the last thread on this very topic that came up some months ago.

A feature similar to #pragma once that simplifies include guards could make sense, but it'll depend on the modules stuff. I'm personally very unimpressed with any of the current modules proposals so perhaps there _is_ value in such a new feature, but it's literally not possible to just standardize #pragma once without forcing most implementations to change their semantics. It would probably have to become something like:

   #once <tag> // must be first directive in file

   /* rest of file */

which essentially expands to

   #if !defined(<tag>)

   #define <tag>

   /* rest of file */

   #endif

but maybe with <tag> being a separate namespace from preprocessor macros (or not). And perhaps <tag> is optional and an implementation-defined one is created based on canonical file path, though that leaves one open to the problems Bo described.

Again, it all depends on modules and when they're implemented and how useful they end up being in practice

[Myriachan]

On Wednesday, October 22, 2014 12:03:31 PM UTC-7, Sean Middleditch wrote:

Well, there's value to having de facto standards match the de jure standard. See exported templates and their eventual removal as an example specific to C++. It's unfortunate when large codebases depend on a non-standard feature that "works" but is non-standard and then new tools that more closely follow the standard without extensions can't handle the codebase. Happens all the time with game engines in my experience, including specifically #pragma once issues.

^ This (except I'd reverse de facto and de jure for clarity).
 

That said, #pragma once couldn't be added to the standard any sooner than C++17, and #pragma once _isn't_ a de facto standard because different implementations work differently, and there's the problems with complex source directories Bo mentions, and... I think all the reasons why this won't work were already clearly enumerated in the last thread on this very topic that came up some months ago.

#pragma once's behavior among compilers only really differs when the source tree is in a traditional directory structure without any weirdness happening.  Most of the other behavior is obvious: identify files by their (volume ID, inode) pair.

I would specify #pragma once's behavior to be unspecified (but either include or not include) in the event that the implementation cannot reliably determine whether two files coincide.  If you want your code to work, don't create a situation where you expect a file to not be double-included when the codebase accesses it through two different mount points for which the OS cannot identify them as identical or overlapping.

Sometimes #include guards have problems.  You can easily run into cases where two unrelated headers think they're both the same name.

That said, Bo does have a point about the inability to work around mistakes, or do sneaky tricks.  For example, how <cstdint> in at least one Linux installation I saw is implemented as #undefining <stdint.h>'s #include guard, #define-ing __STDC_CONSTANT_MACROS, and #include-ing <stdint.h>.

Melissa

[Thiago Macieira]

On Wednesday 22 October 2014 14:27:56 Myriachan wrote:
> I would specify #pragma once's behavior to be unspecified (but either
> include or not include) in the event that the implementation cannot
> reliably determine whether two files coincide. If you want your code to
> work, don't create a situation where you expect a file to not be
> double-included when the codebase accesses it through two different mount
> points for which the OS cannot identify them as identical or overlapping.

Sorry, but I don't think that's useful. If you leave the behaviour unspecified,
it isn't useful because we can't guarantee it will work.

I can't mandate where people should store my source code. Therefore, I can't
guarantee that the source code I write will work on their computers. That
means the feature is useless.

> Sometimes #include guards have problems. You can easily run into cases
> where two unrelated headers think they're both the same name.

That can't happen, since you can't #include two different headers with the same
name (#include_next doesn't count).

Each include should have its canonical #include mechanism. If you a header is
#include'd with <module/header.h>, then the include guard should have both the
words "module" and "header" in the include guard.

[Germinolegrand]

Seriously, I'm fed up with debugging those kind of errors no compiler can even diagnose properly ! Just helped a (not so) beginner stuck with this one :

#ifndef CSCWRITER_H_
# define CSVWRITER_H_

Erreur 88 error C2995: 'CSV::Writer &CSV::operator <<(CSV::Writer &,const T &)' : modèle de fonction déjà défini CSVWriter.hxx 12

When you have a lot of experience you can at least think to verify those sort of stuff, but hey, when you have under 2 years experience this means hours of trying to debug a link error that's in fact a quite unvisible typo in a header guard.

I myself also encounter errors myself when i copy a header to start another one (without having to recode all the #include and all the namespace a{namespaceb b{ boilerplate), and thanks to murphy I forget to change the header guard name, and I do not run into any problem until i eventually include both headers indirectly in one compile unit. If you just wrote the second, you often remember to watch the header guards for this error, but when you did it two weeks ago, have a good day.

"It's complicated to implement from a compiler point of view so let the programmer type a lot of super-murphy piece of code instead."

Seriously ? Are we talking about C or ... ?

Header guards are not superior to anything the compiler can do with a #pragma once equivalent, it's only a trade-off. And i would trade easily sneaky link errors due to preprocessing issues for safety and simplicity.

No matter how hard it is to implement, since it's perfectly feasible (as an ultimate resort, just compare the files content).

Although #pragma once would be nice since it's in large use, #once would at least solve half the problem.

[Agustín K-ballo Bergé]

On 10/23/2014 6:04 AM, Germinolegrand wrote:
> Seriously, I'm fed up with debugging those kind of errors no compiler
> can even diagnose properly ! Just helped a (not so) beginner stuck with
> this one :
>
> #ifndef CSCWRITER_H_
> # define CSVWRITER_H_
>
>
> Erreur 88 error C2995: 'CSV::Writer &CSV::operator <<(CSV::Writer
> &,const T &)' : modèle de fonction déjà défini CSVWriter.hxx 12
>

Clang 3.4 says:

prog.cc:1:9: warning: 'CSCWRITER_H_' is used as a header guard here,
followed by #define of a different macro [-Wheader-guard] #ifndef
CSCWRITER_H_ ^~~~~~~~~~~~

prog.cc:2:10: note: 'CSVWRITER_H_' is defined here; did you mean
'CSCWRITER_H_'? # define CSVWRITER_H_ ^~~~~~~~~~~~ CSCWRITER_H_ 1
warning generated.

Live demo here: http://melpon.org/wandbox/permlink/4ZNSw5ijsqIoTrOp

Regards,
--
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com

[Germinolegrand]

I wish so much I could use clang... such a great compiler :-).
But when a compiler has to analyse code patterns, I believe those should at least be turned into a "language" feature, #once <tag>.
Anyway, this leaves us with the other half, still unsolved even on clang.

[Jean-Marc Bourguet]

Le jeudi 23 octobre 2014 11:04:00 UTC+2, Germinolegrand a écrit :

"It's complicated to implement from a compiler point of view so let the programmer type a lot of super-murphy piece of code instead.

The issue is not that it is complex to implement, the issues are first that it is complex to define what should be the same file, and second

that if pragma once does not allows to solve all the problems in all the situations include guards are currently used, you'll still have to use

include guards, you'll still have to teach about them and you'll have an additional issue "When to use include guards and when to use

pragma once".

Currently include guards are used portably among vastly different systems (and so leaving the same file definition to the implementation

won't help, they still would have to agree), with linked include files (symbolic or hard link), build system copying include files to cache them

but  where the original is still in the include path and both can in fact both be found in the same CU (due to #include "module/file.hpp" and

#include "file.hpp" finding each one or due to #include "" searching in the current directory), mounted file systems, VCS masquerading as

file systems, and so on.

I'm not saying it is impossible to get a usable definition solving those issues.  I'm not saying that they all need to be solved to get a

pragma once in the standard.  I've just not seen a proposal at all (I just went through the last 10 years of papers searching for once and

preprocessor in the titles and found nothing relevant; if I've missed it, just give me the paper number) and a proposal should at least:

- shows what problems it solve (standardizing current state while fixing corner cases is useful, standardizing current state and leaving corner

cases differ between implementations brings nothing IMHO)

- shows how it is fundamentally better than the current states

- at least list the above cases and states what it proposes for it, why it proposes so.

Note that the fact there is progress made on a feature which tackles the root cause (i.e. the lack of a module system in C++) instead of a symptom

increases for me the need of a proof that the pragma would be more useful than the current situation and not just put a "Standard" stamp on

a unchanged situation.

[Thiago Macieira]

On Thursday 23 October 2014 05:41:53 Germinolegrand wrote:
> I wish so much I could use clang... such a great compiler :-).
> But when a compiler has to analyse code patterns, I believe those should at
> least be turned into a "language" feature, #once <tag>.

I completely disagree. Taking what you said to the extreme would change the
language completely.

Clang is very good at providing warnings, like "you're memcpying to an object
with virtual table". There are few reasons why you'd want to do that, but they
exist, so it's the correct solution for the compiler to warn you instead of
making it an error.

[con...@ncomputers.org]

Melissa,

I agree with you. I use GNU compiler and have source files that are included more than one time.

Because it is harder to write preprocessor directives with an equivalent functionality than to press Ctrl + C and Ctrl + V, I prefer to copy and paste all the files inside a giant file for the compilers, which doesn't support #pragma once, than to write the preprocessor directives for each source file, that is included more than one time.

PF, ncomputers

[gmis...@gmail.com]

Hypothetical:

Ignoring compatibility problems....

imagine if #pragma once was the default and some other kind of statement existed to change the default where needed e.g. #pragma multiple or even #include multiple <x>....

Now imagine if something like this extension was implemented in clang...

First, what to people think would be the effort (in days) to implement that change in the clang compiler itself (i.e. to support the new semantics and keywords),?

then what do people think would be the effort (in days) to convert the project itself to use that extension... (i.e. add the keywords where the default #once doesn't work)?

then finally what do people think would be the speed up (in % build time), if clang (or any project like it) were compiled using that extensions?

[gmis...@gmail.com]

then what do people think would be the effort (in days) to convert the project itself to use that extension... (i.e. add the keywords where the default #once doesn't work)?

 

To try to be clearer here.., I'm talking about changing clang to support an extension, then changing the clang project to use the extension and then comparing build times of building the clang project with clang (or any compiler really that supports those extension) and what might we expect to see as a % speed up.

[Daniel Gutson]

Why any speedup at all should be expected?

After all, it is just a cpp directive that saves to write other three.

If *you* want to write an extension, write the shorthand equivalent, e.g.

#guard guardname
...
#endguard

being a shorthand of

#ifdef guardname
#define guardname
...
#endif

which is still of doubtful usefulness (and if so, only in terms of writing one less line and avoiding errors because of typos, but not in terms of building speedup).

---

From: gmis...@gmail.com

Date: Thu, 30 Oct 2014 16:59:57 -0700 (PDT)

To: <std-pr...@isocpp.org>

ReplyTo: std-pr...@isocpp.org

Cc: <gmis...@gmail.com>

Subject: [std-proposals] Re: #pragma once

then what do people think would be the effort (in days) to convert the project itself to use that extension... (i.e. add the keywords where the default #once doesn't work)?

 

To try to be clearer here.., I'm talking about changing clang to support an extension, then changing the clang project to use the extension and then comparing build times of building the clang project with clang (or any compiler really that supports those extension) and what might we expect to see as a % speed up.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

[Richard Smith]

On Thu, Oct 30, 2014 at 4:54 PM, <gmis...@gmail.com> wrote:

Hypothetical:

Ignoring compatibility problems....

imagine if #pragma once was the default and some other kind of statement existed to change the default where needed e.g. #pragma multiple or even #include multiple <x>....

Now imagine if something like this extension was implemented in clang...

First, what to people think would be the effort (in days) to implement that change in the clang compiler itself (i.e. to support the new semantics and keywords),?

Small (a day or so).

 

then what do people think would be the effort (in days) to convert the project itself to use that extension... (i.e. add the keywords where the default #once doesn't work)?

Small (a day or so; we have a lot of textually-included headers, and we build tools that generate headers, all of which would need to be updated).

 

then finally what do people think would be the speed up (in % build time), if clang (or any project like it) were compiled using that extensions?

I would not expect any measurable difference. We already detect include guards and get all the performance benefits of #pragma once from them.

On Wednesday, October 22, 2014 8:29:21 AM UTC+13, Myriachan wrote:

I think that #pragma once should be standardized - at least partially/optionally/conditionally-supported.  Every major compiler implements it with identical or nearly-identical semantics.

Defining what it means for a file to be a repeat is rather simple: On platforms supporting symlinks and hard links, use unique inode numbers (+ device if needed).  On other platforms, use the filename.  Compilers may assume that files don't change while compiling (i.e. if the filename matches, it can be assumed to be identical).  On platforms where there exist special links to the same or parent directory, like "./" or "../" on NT and POSIX, this assumption can be extended to collapse these.

By the way, why don't _Pragma and #line support concatenating multiple strings in their respective string parameters?

Melissa

--

[gmis...@gmail.com]

On Friday, October 31, 2014 1:54:20 PM UTC+13, Richard Smith wrote:

On Thu, Oct 30, 2014 at 4:54 PM, <gmis...@gmail.com> wrote:

Hypothetical:

Ignoring compatibility problems....

imagine if #pragma once was the default and some other kind of statement existed to change the default where needed e.g. #pragma multiple or even #include multiple <x>....

Now imagine if something like this extension was implemented in clang...

First, what to people think would be the effort (in days) to implement that change in the clang compiler itself (i.e. to support the new semantics and keywords),?

Small (a day or so).

 

then what do people think would be the effort (in days) to convert the project itself to use that extension... (i.e. add the keywords where the default #once doesn't work)?

Small (a day or so; we have a lot of textually-included headers, and we build tools that generate headers, all of which would need to be updated).

 

then finally what do people think would be the speed up (in % build time), if clang (or any project like it) were compiled using that extensions?

I would not expect any measurable difference. We already detect include guards and get all the performance benefits of #pragma once from them.

Thanks Richard!

ok, so does that mean then that making #pragma once Standard does nothing for performance, it just adds a nice convenience of not having to have #include guards but one still has to be mindful of multiple inclusion each time. Making #pragma once Standard would also helps by making some existing code, Standard code.

By contrast,  #pragma multiple (or whatever) as a new feature, would mean breaking some existing code, but even for pretty large projects, fixing it would only be a days work and some of that time would be recouped by the fact that nobody would need to write or fix a broken include guard ever again in the project, or any new one ever...

I don't imagine anyone would ever go for that contrasting option, but I thought it was worth throwing it out there to see if it was viable.

[Olaf van der Spek]

On Fri, Oct 31, 2014 at 3:02 AM, <gmis...@gmail.com> wrote:
> By contrast, #pragma multiple (or whatever) as a new feature, would mean
> breaking some existing code, but even for pretty large projects, fixing it
> would only be a days work and some of that time would be recouped by the
> fact that nobody would need to write or fix a broken include guard ever
> again in the project, or any new one ever...
>
> I don't imagine anyone would ever go for that contrasting option, but I
> thought it was worth throwing it out there to see if it was viable.

#pragma multiple sounds quite nice. How many headers can be included
multiple times? cassert maybe

A warning to warn about files without header guards would allow such
files to be easily detected.



--
Olaf