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

Groups > comp.lang.c++ > #8302 > unrolled thread

Macro does not work in source code.

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

Contents

  Macro does not work in source code. Nephi Immortal <immortalnephi@gmail.com> - 2011-07-28 17:36 -0700
    Re: Macro does not work in source code. Sam <sam@email-scan.com> - 2011-07-28 20:41 -0500
    Re: Macro does not work in source code. red floyd <no.spam.here@its.invalid> - 2011-07-28 23:45 -0700
      Re: Macro does not work in source code. Juha Nieminen <nospam@thanks.invalid> - 2011-07-29 10:01 +0000
        Re: Macro does not work in source code. "Alf P. Steinbach" <alf.p.steinbach:usenet@gmail.com> - 2011-07-29 13:31 +0200
    Re: Macro does not work in source code. MJ_India <mail.mohitjain@gmail.com> - 2011-07-29 23:41 -0700
      Re: Macro does not work in source code. Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-07-30 12:58 +0000
        Re: Macro does not work in source code. Brian Casiello <bcasiello@gmail.com> - 2011-07-30 11:39 -0400
          Re: Macro does not work in source code. Paul Brettschneider <paul.brettschneider@yahoo.fr> - 2011-07-31 18:12 +0200
            Re: Macro does not work in source code. Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-07-31 18:30 +0000
              Re: Macro does not work in source code. "Alf P. Steinbach" <alf.p.steinbach:usenet@gmail.com> - 2011-08-01 00:48 +0200
                Re: Macro does not work in source code. "Alf P. Steinbach" <alf.p.steinbach:usenet@gmail.com> - 2011-08-01 00:52 +0200
                  Re: Macro does not work in source code. Paul Brettschneider <paul.brettschneider@yahoo.fr> - 2011-08-01 08:58 +0200
                    Re: Macro does not work in source code. "Alf P. Steinbach" <alf.p.steinbach:usenet@gmail.com> - 2011-08-01 10:11 +0200
                      Re: Macro does not work in source code. James Kanze <james.kanze@gmail.com> - 2011-08-07 11:00 -0700
                        Re: Macro does not work in source code. "Alf P. Steinbach" <alf.p.steinbach:usenet@gmail.com> - 2011-08-07 22:50 +0200
                          Re: Macro does not work in source code. Ian Collins <ian-news@hotmail.com> - 2011-08-08 09:15 +1200
                  Re: Macro does not work in source code. Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-08-01 12:09 +0000
                    Re: Macro does not work in source code. Miles Bader <miles@gnu.org> - 2011-08-02 14:53 +0900
                Re: Macro does not work in source code. Ian Collins <ian-news@hotmail.com> - 2011-08-01 10:55 +1200
        Re: Macro does not work in source code. James Kanze <james.kanze@gmail.com> - 2011-08-07 10:47 -0700
          Re: Macro does not work in source code. Marc <marc.glisse@gmail.com> - 2011-08-07 18:13 +0000

Page 1 of 2  [1] 2  Next page →

#8302 — Macro does not work in source code.

I created macro in all header and source codes.  The TEST condition
must always be true in demo.cpp, but error message displays

Main.obj : error LNK2001: unresolved external symbol "char * _MSG_" (?
_MSG_@@3PADA)
C:\My Projects\RGB\Debug\RGB.exe : fatal error LNK1120: 1 unresolved
externals

It means that main.cpp tries to link char _MSG_, but the definition in
demo.cpp is not found because the TEST condition is set to false.

Why macro does not work?


// Demo.h
#ifdef DEMO_H

#if defined( TEST )
	extern char _MSG_[ 256 ];
#else
	extern wchar_t _MSG_[ 256 ];
#endif

#endif // DEMO_H


// Demo.cpp
#if defined( TEST )
	char _MSG_[ 256 ] = "This is char type.";
#else
	wchar_t _MSG_[ 256 ] = L"This is wchar_t type."
#endif

// main.cpp

#define TEST
#include "Demo.h"


int main()
{
#ifdef TEST
	char *p = _MSG_;
#else
	wchar_t *p = _MSG_;
#endif
}

[toc] | [next] | [standalone]

#8304

[Multipart message — attachments visible in raw view] — view raw

Nephi Immortal writes:

> I created macro in all header and source codes.  The TEST condition
> must always be true in demo.cpp, but error message displays

There's nothing in the sample code you posted that indicates that the TEST  
macro is set in demo.cpp

>
> Main.obj : error LNK2001: unresolved external symbol "char * _MSG_" (?
> _MSG_@@3PADA)
> C:\My Projects\RGB\Debug\RGB.exe : fatal error LNK1120: 1 unresolved
> externals
>
> It means that main.cpp tries to link char _MSG_, but the definition in
> demo.cpp is not found because the TEST condition is set to false.

The sample code you posted always defines the _MSG_ symbol in demo.cpp,  
whether or not the TEST macro is set. The only difference the presence of  
the TEST macro makes is whether or not the symbol gets declared as a char[]  
or as a wchar_t[].

I see nothing in the code that you posted that suggests that TEST gets set  
when you build Demo.cpp, therefore Demo.cpp declares _MSG_ as a wchar_t[].

In your main.cpp, you explicitly set the TEST macro, and via the inclusion  
of Demo.h, you now defining and referencing _MSG as a char[].

Based on the code that you posted, you are compiling one translation unit  
which defines an object as a wchar_t[], then you are compiling another  
translation unit that references the same symbol as a char[]. This is  
undefined behavior. I find a link failure to be a plausible outcome of this  
kind of undefined behavior.

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

#8310

On 7/28/2011 5:36 PM, Nephi Immortal wrote:
> I created macro in all header and source codes.  The TEST condition
> must always be true in demo.cpp, but error message displays
>
> Main.obj : error LNK2001: unresolved external symbol "char * _MSG_" (?
> _MSG_@@3PADA)
> C:\My Projects\RGB\Debug\RGB.exe : fatal error LNK1120: 1 unresolved
> externals
>
> It means that main.cpp tries to link char _MSG_, but the definition in
> demo.cpp is not found because the TEST condition is set to false.
>
> Why macro does not work?
>
>
> // Demo.h
> #ifdef DEMO_H
>
> #if defined( TEST )
> 	extern char _MSG_[ 256 ];
> #else
> 	extern wchar_t _MSG_[ 256 ];
> #endif
>
> #endif // DEMO_H
>

Aside from Sam's comments, your code is ill-formed.  Any identifier
beginning with an underscore followed by an uppercase letter (such
as, _MSG_) is reserved to the implementation, and may not be defined
for use by the program.

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

#8313

red floyd <no.spam.here@its.invalid> wrote:
> Aside from Sam's comments, your code is ill-formed.  Any identifier
> beginning with an underscore followed by an uppercase letter (such
> as, _MSG_) is reserved to the implementation, and may not be defined
> for use by the program.

  I thought it's any identifier beginning with an underscore, period.

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

#8317

On 29.07.2011 12:01, Juha Nieminen wrote:
> red floyd<no.spam.here@its.invalid>  wrote:
>> Aside from Sam's comments, your code is ill-formed.  Any identifier
>> beginning with an underscore followed by an uppercase letter (such
>> as, _MSG_) is reserved to the implementation, and may not be defined
>> for use by the program.
>
>    I thought it's any identifier beginning with an underscore, period.

No. The three main cases are

  1. Beginning with underscore followed by uppercase.
  2. Two consecutive underscores anywhere in the name.
  3. For the global namespace only, beginning with underscore.

However, the common use of unqualified names means that one should 
better not define names that begin with underscore even in class scope.

It gives the wrong signal to a reader of the code...


Cheers & hth.,

- Alf

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

#8327

On Jul 29, 9:36 am, Nephi Immortal <immortalne...@gmail.com> wrote:
> I created macro in all header and source codes.  The TEST condition
> must always be true in demo.cpp, but error message displays
>
> Main.obj : error LNK2001: unresolved external symbol "char * _MSG_" (?
> _MSG_@@3PADA)
> C:\My Projects\RGB\Debug\RGB.exe : fatal error LNK1120: 1 unresolved
> externals
>
> It means that main.cpp tries to link char _MSG_, but the definition in
> demo.cpp is not found because the TEST condition is set to false.
>
> Why macro does not work?
>
> // Demo.h
> #ifdef DEMO_H
>
> #if defined( TEST )
>         extern char _MSG_[ 256 ];
> #else
>         extern wchar_t _MSG_[ 256 ];
> #endif
>
> #endif // DEMO_H
>
> // Demo.cpp
> #if defined( TEST )
>         char _MSG_[ 256 ] = "This is char type.";
> #else
>         wchar_t _MSG_[ 256 ] = L"This is wchar_t type."
> #endif
>
> // main.cpp
>
> #define TEST
> #include "Demo.h"
>
> int main()
> {
> #ifdef TEST
>         char *p = _MSG_;
> #else
>         wchar_t *p = _MSG_;
> #endif
>
>
>
>
>
>
>
> }

Two blunders in the code are:
1. #ifdef DEMO_H is masking all the code of file demo.h
Are you sure you don't want to write
#ifndef DEMO_H
#define DEMO_H
....
#endif
[Prefer to use #pragma once instead of ifndef guards]
2. wchar_t _MSG_[ 256 ] = L"This is wchar_t type." , semicolon is
missing.

After fixing above 2, you should be able to compile and link but
needless to say
code is very ill formatted. Read above posted replies carefully to
understand why?

-Mohit

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

#8331

On Sat, 2011-07-30, MJ_India wrote:
> On Jul 29, 9:36 am, Nephi Immortal <immortalne...@gmail.com> wrote:

...

> 1. #ifdef DEMO_H is masking all the code of file demo.h
> Are you sure you don't want to write
> #ifndef DEMO_H
> #define DEMO_H
> ....
> #endif

> [Prefer to use #pragma once instead of ifndef guards]

That last sentence -- is that supposed to be an advice? I've never
seen anything other than the include guard stuff you described above.
And my compiler (g++) doesn't seem to have a pragma named "once".

/Jorgen

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

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

#8332

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:

> On Sat, 2011-07-30, MJ_India wrote:
>> On Jul 29, 9:36 am, Nephi Immortal <immortalne...@gmail.com> wrote:
>
>> [Prefer to use #pragma once instead of ifndef guards]
>
> That last sentence -- is that supposed to be an advice? I've never
> seen anything other than the include guard stuff you described above.
> And my compiler (g++) doesn't seem to have a pragma named "once".

It's a Microsoft Visual-C++ thing, it means the header should only be
opened and read once. It's effectively equivalent to include guards and
may speed up compiles as long as you know your code is and will always
be VC++ specific (it depends on other Microsoft-isms), or if you
don't care that your code will only compile efficiently with Visual C++.

I suppose you could use both, and get the MS speed tweak and
portability.

--
Brian

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

#8361

Brian Casiello wrote:

> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
> 
>> On Sat, 2011-07-30, MJ_India wrote:
>>> On Jul 29, 9:36 am, Nephi Immortal <immortalne...@gmail.com> wrote:
>>
>>> [Prefer to use #pragma once instead of ifndef guards]
>>
>> That last sentence -- is that supposed to be an advice? I've never
>> seen anything other than the include guard stuff you described above.
>> And my compiler (g++) doesn't seem to have a pragma named "once".
> 
> It's a Microsoft Visual-C++ thing, it means the header should only be
> opened and read once. It's effectively equivalent to include guards and
> may speed up compiles as long as you know your code is and will always
> be VC++ specific (it depends on other Microsoft-isms), or if you
> don't care that your code will only compile efficiently with Visual C++.

I'm pretty sure that Jorgen was being facetious and knows about this 
proprietary extension.

> I suppose you could use both, and get the MS speed tweak and
> portability.

Have you actually done any speed measurements? One would think that include 
guards are so common that any decent compiler would recognize them and treat 
them exactly like this #pramga. Looks like a relic from the dark ages. :)

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

#8362

On Sun, 2011-07-31, Paul Brettschneider wrote:
> Brian Casiello wrote:
>
>> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>> 
>>> On Sat, 2011-07-30, MJ_India wrote:
>>>> On Jul 29, 9:36 am, Nephi Immortal <immortalne...@gmail.com> wrote:
>>>
>>>> [Prefer to use #pragma once instead of ifndef guards]
>>>
>>> That last sentence -- is that supposed to be an advice? I've never
>>> seen anything other than the include guard stuff you described above.
>>> And my compiler (g++) doesn't seem to have a pragma named "once".
>> 
>> It's a Microsoft Visual-C++ thing, it means the header should only be
>> opened and read once. It's effectively equivalent to include guards and
>> may speed up compiles as long as you know your code is and will always
>> be VC++ specific (it depends on other Microsoft-isms), or if you
>> don't care that your code will only compile efficiently with Visual C++.
>
> I'm pretty sure that Jorgen was being facetious and knows about this 
> proprietary extension.

I *suspected* it was a MS thing, but I had to look in the g++ manual
before posting.

/Jorgen

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

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

#8365

On 31.07.2011 20:30, Jorgen Grahn wrote:
> On Sun, 2011-07-31, Paul Brettschneider wrote:
>> Brian Casiello wrote:
>>
>>> Jorgen Grahn<grahn+nntp@snipabacken.se>  writes:
>>>
>>>> On Sat, 2011-07-30, MJ_India wrote:
>>>>> On Jul 29, 9:36 am, Nephi Immortal<immortalne...@gmail.com>  wrote:
>>>>
>>>>> [Prefer to use #pragma once instead of ifndef guards]
>>>>
>>>> That last sentence -- is that supposed to be an advice? I've never
>>>> seen anything other than the include guard stuff you described above.
>>>> And my compiler (g++) doesn't seem to have a pragma named "once".
>>>
>>> It's a Microsoft Visual-C++ thing, it means the header should only be
>>> opened and read once. It's effectively equivalent to include guards and
>>> may speed up compiles as long as you know your code is and will always
>>> be VC++ specific (it depends on other Microsoft-isms), or if you
>>> don't care that your code will only compile efficiently with Visual C++.
>>
>> I'm pretty sure that Jorgen was being facetious and knows about this
>> proprietary extension.
>
> I *suspected* it was a MS thing, but I had to look in the g++ manual
> before posting.

No, "#pragma once" is not an MS thing.

And as I'm testing now MinGW g++ 4.x supports "#pragma once".

It's a de facto standard: AFAIK the C++ standardization committee is the 
only actor who has not adopted it.

<url: http://gcc.gnu.org/onlinedocs/gcc-2.95.3/cpp_1.html#SEC8>
<url: http://en.wikipedia.org/wiki/Pragma_once>

However, the GNU docs references above says "#pragma once" is obsolete.

That's a pretty weird statement.


Cheers & hth.,

- Alf

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

#8366

On 01.08.2011 00:48, Alf P. Steinbach wrote:
> On 31.07.2011 20:30, Jorgen Grahn wrote:
>> On Sun, 2011-07-31, Paul Brettschneider wrote:
>>> Brian Casiello wrote:
>>>
>>>> Jorgen Grahn<grahn+nntp@snipabacken.se> writes:
>>>>
>>>>> On Sat, 2011-07-30, MJ_India wrote:
>>>>>> On Jul 29, 9:36 am, Nephi Immortal<immortalne...@gmail.com> wrote:
>>>>>
>>>>>> [Prefer to use #pragma once instead of ifndef guards]
>>>>>
>>>>> That last sentence -- is that supposed to be an advice? I've never
>>>>> seen anything other than the include guard stuff you described above.
>>>>> And my compiler (g++) doesn't seem to have a pragma named "once".
>>>>
>>>> It's a Microsoft Visual-C++ thing, it means the header should only be
>>>> opened and read once. It's effectively equivalent to include guards and
>>>> may speed up compiles as long as you know your code is and will always
>>>> be VC++ specific (it depends on other Microsoft-isms), or if you
>>>> don't care that your code will only compile efficiently with Visual
>>>> C++.
>>>
>>> I'm pretty sure that Jorgen was being facetious and knows about this
>>> proprietary extension.
>>
>> I *suspected* it was a MS thing, but I had to look in the g++ manual
>> before posting.
>
> No, "#pragma once" is not an MS thing.
>
> And as I'm testing now MinGW g++ 4.x supports "#pragma once".
>
> It's a de facto standard: AFAIK the C++ standardization committee is the
> only actor who has not adopted it.
>
> <url: http://gcc.gnu.org/onlinedocs/gcc-2.95.3/cpp_1.html#SEC8>
> <url: http://en.wikipedia.org/wiki/Pragma_once>
>
> However, the GNU docs references above says "#pragma once" is obsolete.
>
> That's a pretty weird statement.

Oh, the more recent GNU docs, for version 4.6, do not say obsolete:

http://gcc.gnu.org/onlinedocs/gcc-4.6.1/cpp/Alternatives-to-Wrapper-_0023ifndef.html#Alternatives-to-Wrapper-_0023ifndef


Cheers & hth.,

- Alf

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

#8370

 wrote:

> On 01.08.2011 00:48, Alf P. Steinbach wrote:
>> No, "#pragma once" is not an MS thing.
>>
>> And as I'm testing now MinGW g++ 4.x supports "#pragma once".
>>
>> It's a de facto standard: AFAIK the C++ standardization committee is the
>> only actor who has not adopted it.
>>
>> <url: http://gcc.gnu.org/onlinedocs/gcc-2.95.3/cpp_1.html#SEC8>
>> <url: http://en.wikipedia.org/wiki/Pragma_once>
>>
>> However, the GNU docs references above says "#pragma once" is obsolete.
>>
>> That's a pretty weird statement.
> 
> Oh, the more recent GNU docs, for version 4.6, do not say obsolete:
> 
> http://gcc.gnu.org/onlinedocs/gcc-4.6.1/cpp/Alternatives-to-Wrapper-
_0023ifndef.html#Alternatives-to-Wrapper-_0023ifndef

Isn't "[W]e recommend you do not use them in new programs" a mild form of 
saying just that?

I have nothing against extensions (for example no_return or format string 
specifiers in C-like IO functions are very useful), but if there is no 
advantage over the standard way, I fail to see the point. Especially in this 
case were it was suggested up-thread to use include guards *and* the 
#pragma. That's one more line for nothing. Old cruft like this should be 
supported for compatibility reasons, but also deprecated to make a point.

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

#8374

On 01.08.2011 08:58, Paul Brettschneider wrote:
>   wrote:
>
>> On 01.08.2011 00:48, Alf P. Steinbach wrote:
>>> No, "#pragma once" is not an MS thing.
>>>
>>> And as I'm testing now MinGW g++ 4.x supports "#pragma once".
>>>
>>> It's a de facto standard: AFAIK the C++ standardization committee is the
>>> only actor who has not adopted it.
>>>
>>> <url: http://gcc.gnu.org/onlinedocs/gcc-2.95.3/cpp_1.html#SEC8>
>>> <url: http://en.wikipedia.org/wiki/Pragma_once>
>>>
>>> However, the GNU docs references above says "#pragma once" is obsolete.
>>>
>>> That's a pretty weird statement.
>>
>> Oh, the more recent GNU docs, for version 4.6, do not say obsolete:
>>
>> http://gcc.gnu.org/onlinedocs/gcc-4.6.1/cpp/Alternatives-to-Wrapper-
> _0023ifndef.html#Alternatives-to-Wrapper-_0023ifndef
>
> Isn't "[W]e recommend you do not use them in new programs" a mild form of
> saying just that?
>
> I have nothing against extensions (for example no_return or format string
> specifiers in C-like IO functions are very useful), but if there is no
> advantage over the standard way, I fail to see the point.

The pragma is generally safer than include guards, it gives less visual 
clutter, and, being higher level, can even be faster.

The reason for the generally improved safety is that it does not rely on 
the programmer selecting a truly unique header guard symbol.

There is one situation where instead include guards can be safer, namely 
in the context of symbolic links to files. But that's a rare situation, 
and mostly it's just a question of Quality of Implementation. g++ once 
had a problem here, but it was fixed.


> Especially in this
> case were it was suggested up-thread to use include guards *and* the
> #pragma. That's one more line for nothing. Old cruft like this should be
> supported for compatibility reasons, but also deprecated to make a point.

On the contrary, "#pragma once" is probably what one should use for new 
code  --  IN SPITE OF NOT BEING FORMALLY STANDARD. ;-)


Cheers & hth.,

- Alf

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

#8547

On Aug 1, 9:11 am, "Alf P. Steinbach"
<alf.p.steinbach:use...@gmail.com> wrote:
> On 01.08.2011 08:58, Paul Brettschneider wrote:
> >   wrote:

> >> On 01.08.2011 00:48, Alf P. Steinbach wrote:
> >>> No, "#pragma once" is not an MS thing.

> >>> And as I'm testing now MinGW g++ 4.x supports "#pragma once".

> >>> It's a de facto standard: AFAIK the C++ standardization
> >>> committee is the only actor who has not adopted it.

Except for all of the others.  Most of the C++ compilers I've
used in the past didn't support it.  (The only C++ compilers I
use currently are VC++ and g++.)

> >>> <url:http://gcc.gnu.org/onlinedocs/gcc-2.95.3/cpp_1.html#SEC8>
> >>> <url:http://en.wikipedia.org/wiki/Pragma_once>

> >>> However, the GNU docs references above says "#pragma once" is obsolete.

> >>> That's a pretty weird statement.

> >> Oh, the more recent GNU docs, for version 4.6, do not say obsolete:

> >>http://gcc.gnu.org/onlinedocs/gcc-4.6.1/cpp/Alternatives-to-Wrapper-
> > _0023ifndef.html#Alternatives-to-Wrapper-_0023ifndef

> > Isn't "[W]e recommend you do not use them in new programs" a mild form of
> > saying just that?

> > I have nothing against extensions (for example no_return or format string
> > specifiers in C-like IO functions are very useful), but if there is no
> > advantage over the standard way, I fail to see the point.

> The pragma is generally safer than include guards, it gives less visual
> clutter, and, being higher level, can even be faster.

The pragma isn't nearly as safe as include guards, since it
doesn't work generally.  If you want your code to be portable,
you need the include guards.  And once you have the include
guards, the pragma doesn't buy you anything.

FWIW, the standards committee rejected it because it can't be
made to work reliably on networked machines.  (I'm not sure I
agree with their decision.  The cases where it doesn't work
reliably are pretty perverse, and would probably cause problems
for the humans managing the system.  On the other hand, trying
to find standardese which let the implementation off the hook in
such cases doesn't seem trivial.)

> The reason for the generally improved safety is that it does not rely on
> the programmer selecting a truly unique header guard symbol.

That's a different problem.  For starters, there's no reason why
the programmer should be selecting the guard symbol.  That's the
environment's job, and it's relatively simple for the
environment to come up with something at least as unique as the
name of an unnamed namespace.  I'm using vim, hardly the most
state of the art editor, and when I open a new .hh file, I get
the include guards already generated, with a lot of truly random
letters at the end.

> There is one situation where instead include guards can be safer, namely
> in the context of symbolic links to files. But that's a rare situation,
> and mostly it's just a question of Quality of Implementation. g++ once
> had a problem here, but it was fixed.

Symbolic links are easy, since you can resolve them to the true
name.  Hard links are more difficult; you need to keep track of
the device and inode number.  And remote mounted files are
impossible.

> > Especially in this
> > case were it was suggested up-thread to use include guards *and* the
> > #pragma. That's one more line for nothing. Old cruft like this should be
> > supported for compatibility reasons, but also deprecated to make a point.

> On the contrary, "#pragma once" is probably what one should use for new
> code  --  IN SPITE OF NOT BEING FORMALLY STANDARD. ;-)

Only if you don't care if your code works on machines other than
Windows and Linux.

--
James Kanze

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

#8556

On 07.08.2011 20:00, James Kanze wrote:
> On Aug 1, 9:11 am, "Alf P. Steinbach"
> <alf.p.steinbach:use...@gmail.com>  wrote:
>> On 01.08.2011 08:58, Paul Brettschneider wrote:
>
>>> Especially in this
>>> case were it was suggested up-thread to use include guards *and* the
>>> #pragma. That's one more line for nothing. Old cruft like this should be
>>> supported for compatibility reasons, but also deprecated to make a point.
>
>> On the contrary, "#pragma once" is probably what one should use for new
>> code  --  IN SPITE OF NOT BEING FORMALLY STANDARD. ;-)
>
> Only if you don't care if your code works on machines other than
> Windows and Linux.

I think, if one needs to support a compiler that doesn't support 
`#pragma once`, then one is in about the same kind of boat as one who is 
targeting a 16-bit char system: one is not writing portable code.

So, big difference between formal and practice. :-)

But here's the crucial thing: if up-front generation of include guards 
is feasible, and it is, then for those special compilers (like 16-bit 
Digital Signal Processor compiler) it's no big deal to preprocess the 
source replacing `#pragma once` with traditional include guards.

I.e. one accepts a little special-casing for the special case, to keep 
the general case clean.

That's like having a sports car for general go-abouting, and bringing in 
the help of e.g. tractor for plowing fields, where the sports car isn't 
good tool. Using or bringing along the tractor in all cases, just 
because it's needed in one special case that may or may not arise, well 
that strikes me as awkward. :-O)

Cheers,

- Alf

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

#8557

On 08/ 8/11 08:50 AM, Alf P. Steinbach wrote:
> On 07.08.2011 20:00, James Kanze wrote:
>> On Aug 1, 9:11 am, "Alf P. Steinbach"
>> <alf.p.steinbach:use...@gmail.com>   wrote:
>>> On 01.08.2011 08:58, Paul Brettschneider wrote:
>>
>>>> Especially in this
>>>> case were it was suggested up-thread to use include guards *and* the
>>>> #pragma. That's one more line for nothing. Old cruft like this should be
>>>> supported for compatibility reasons, but also deprecated to make a point.
>>
>>> On the contrary, "#pragma once" is probably what one should use for new
>>> code  --  IN SPITE OF NOT BEING FORMALLY STANDARD. ;-)
>>
>> Only if you don't care if your code works on machines other than
>> Windows and Linux.
>
> I think, if one needs to support a compiler that doesn't support
> `#pragma once`, then one is in about the same kind of boat as one who is
> targeting a 16-bit char system: one is not writing portable code.
>
> So, big difference between formal and practice. :-)
>
> But here's the crucial thing: if up-front generation of include guards
> is feasible, and it is, then for those special compilers (like 16-bit
> Digital Signal Processor compiler) it's no big deal to preprocess the
> source replacing `#pragma once` with traditional include guards.

Well my day to day compiler (Sun CC) does not use `#pragma once` and I 
have never seen it used in Unix, Linux or embedded system headers.

In a way, `#pragma once` is an anachronism.  The preprocessor can keep 
track of open headers with include guards and not reopen the file.  Both 
Sun CC and gcc appear to be doing this.

It is probably a worthwhile optimisation, I bet most of the headers 
encountered in a typical build are system or third party library headers 
that do no use `#pragma once`.

-- 
Ian Collins

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

#8386

On Sun, 2011-07-31, Alf P. Steinbach wrote:
> On 01.08.2011 00:48, Alf P. Steinbach wrote:
>> On 31.07.2011 20:30, Jorgen Grahn wrote:
>>> On Sun, 2011-07-31, Paul Brettschneider wrote:
>>>> Brian Casiello wrote:
>>>>
>>>>> Jorgen Grahn<grahn+nntp@snipabacken.se> writes:
>>>>>
>>>>>> On Sat, 2011-07-30, MJ_India wrote:
>>>>>>> On Jul 29, 9:36 am, Nephi Immortal<immortalne...@gmail.com> wrote:
>>>>>>
>>>>>>> [Prefer to use #pragma once instead of ifndef guards]
>>>>>>
>>>>>> That last sentence -- is that supposed to be an advice? I've never
>>>>>> seen anything other than the include guard stuff you described above.
>>>>>> And my compiler (g++) doesn't seem to have a pragma named "once".
>>>>>
>>>>> It's a Microsoft Visual-C++ thing, it means the header should only be
>>>>> opened and read once. It's effectively equivalent to include guards and
>>>>> may speed up compiles as long as you know your code is and will always
>>>>> be VC++ specific (it depends on other Microsoft-isms), or if you
>>>>> don't care that your code will only compile efficiently with Visual
>>>>> C++.
>>>>
>>>> I'm pretty sure that Jorgen was being facetious and knows about this
>>>> proprietary extension.
>>>
>>> I *suspected* it was a MS thing, but I had to look in the g++ manual
>>> before posting.
>>
>> No, "#pragma once" is not an MS thing.
>>
>> And as I'm testing now MinGW g++ 4.x supports "#pragma once".
>>
>> It's a de facto standard: AFAIK the C++ standardization committee is the
>> only actor who has not adopted it.
>>
>> <url: http://gcc.gnu.org/onlinedocs/gcc-2.95.3/cpp_1.html#SEC8>
>> <url: http://en.wikipedia.org/wiki/Pragma_once>
>>
>> However, the GNU docs references above says "#pragma once" is obsolete.
>>
>> That's a pretty weird statement.
>
> Oh, the more recent GNU docs, for version 4.6, do not say obsolete:
>
> http://gcc.gnu.org/onlinedocs/gcc-4.6.1/cpp/Alternatives-to-Wrapper-_0023ifndef.html#Alternatives-to-Wrapper-_0023ifndef

Oh -- it didn't occur to me to look in the cpp manual (although it
should have).

I note though that (a) I've never seen it used, and (b) on my system
none of the 2800 files in /usr/include use it.

/Jorgen

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

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

#8396

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
> On Sun, 2011-07-31, Alf P. Steinbach wrote:
>>> However, the GNU docs references above says "#pragma once" is obsolete.
>>>
>>> That's a pretty weird statement.
>>
>> Oh, the more recent GNU docs, for version 4.6, do not say obsolete:
>>
>> http://gcc.gnu.org/onlinedocs/gcc-4.6.1/cpp/Alternatives-to-Wrapper-_0023ifndef.html#Alternatives-to-Wrapper-_0023ifndef
>
> Oh -- it didn't occur to me to look in the cpp manual (although it
> should have).
>
> I note though that (a) I've never seen it used, and (b) on my system
> none of the 2800 files in /usr/include use it.

It seems clear that, at least in portable code, the #ifdef... solution
is both idiomatic and the "safe choice" (will work in any compiler),
which seem a good reason to prefer it, especially considering it's
_also_ efficient with many common compilers (dunno about microsoft
compilers).

-Miles

-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

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

#8367

On 08/ 1/11 10:48 AM, Alf P. Steinbach wrote:
>
> No, "#pragma once" is not an MS thing.
>
> And as I'm testing now MinGW g++ 4.x supports "#pragma once".
>
> It's a de facto standard: AFAIK the C++ standardization committee is the
> only actor who has not adopted it.
>
> <url: http://gcc.gnu.org/onlinedocs/gcc-2.95.3/cpp_1.html#SEC8>
> <url: http://en.wikipedia.org/wiki/Pragma_once>
>
> However, the GNU docs references above says "#pragma once" is obsolete.
>
> That's a pretty weird statement.

Not really, the compiler can perform the same optimisations with include 
guards.

-- 
Ian Collins

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web