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

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

upper case enumerator

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

Contents

  upper case enumerator Mark <ma740988@gmail.com> - 2019-09-27 19:37 -0700
    Re: upper case enumerator Ian Collins <ian-news@hotmail.com> - 2019-09-28 14:43 +1200
    Re: upper case enumerator Louis Krupp <lkrupp@nospam.pssw.com.invalid> - 2019-09-27 23:48 -0600
    Re: upper case enumerator Bo Persson <bo@bo-persson.se> - 2019-09-28 10:06 +0200
    Re: upper case enumerator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-09-28 21:58 +0100
    Re: upper case enumerator Öö Tiib <ootiib@hot.ee> - 2019-09-28 17:10 -0700
      Re: upper case enumerator Vir Campestris <vir.campestris@invalid.invalid> - 2019-09-29 21:45 +0100
        Re: upper case enumerator Manfred <noname@add.invalid> - 2019-09-29 23:29 +0200
        Re: upper case enumerator Ian Collins <ian-news@hotmail.com> - 2019-09-30 16:36 +1300
          Re: upper case enumerator Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-09-30 12:25 +0000
            Re: upper case enumerator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-09-30 14:55 +0100
    Re: upper case enumerator James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-09-30 01:11 -0400
    Re: upper case enumerator Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-09-30 01:34 -0700

#68722 — upper case enumerator

[code]


# ifndef XXX_YYY
# define XXX_YYY

//# pragma once //this is what you should do today and beyond (all things being equal .. compiler support)
# include <cstddef>
# include <iostream>

 namespace foo
 {
   enum kFavoriteWine { kMoscato, XXX_YYY } ;
 }


# endif

auto main() -> int
{
  using namespace foo ;
  kFavoriteWine xx  = XXX_YYY ;

}
Why does the upper case enumerator collided with the preprocessor macro even though the macro is wrapped in a namespace?   Can someone point me to some standard verbiage saying why that's wrong

[/code]

[toc] | [next] | [standalone]

#68723

On 28/09/2019 14:37, Mark wrote:
> 
> [code]
> 
> 
> # ifndef XXX_YYY
> # define XXX_YYY
> 
> //# pragma once //this is what you should do today and beyond (all things being equal .. compiler support)
> # include <cstddef>
> # include <iostream>
> 
>   namespace foo
>   {
>     enum kFavoriteWine { kMoscato, XXX_YYY } ;
>   }
> 
> 
> # endif
> 
> auto main() -> int

Horrid style..

> {
>    using namespace foo ;
>    kFavoriteWine xx  = XXX_YYY ;
> 
> }
> Why does the upper case enumerator collided with the preprocessor
> macro even though the macro is wrapped in a namespace?   Can someone
> point me to some standard verbiage saying why that's wrong

A macro is a simple text substitution performed by the preprocessor, so 
your code is changed to something like

  namespace foo
  {
    enum kFavoriteWine { kMoscato, } ;
  }

auto main() -> int
{
   using namespace foo ;
   kFavoriteWine xx = ;

}

before it is compiled.

-- 
Ian.

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

#68724

On Fri, 27 Sep 2019 19:37:29 -0700 (PDT), Mark <ma740988@gmail.com>
wrote:

>
>[code]
>
>
># ifndef XXX_YYY
># define XXX_YYY
>
>//# pragma once //this is what you should do today and beyond (all things being equal .. compiler support)
># include <cstddef>
># include <iostream>
>
> namespace foo
> {
>   enum kFavoriteWine { kMoscato, XXX_YYY } ;
> }
>
>
># endif
>
>auto main() -> int
>{
>  using namespace foo ;
>  kFavoriteWine xx  = XXX_YYY ;
>
>}
>Why does the upper case enumerator collided with the preprocessor macro even though the macro is wrapped in a namespace?   Can someone point me to some standard verbiage saying why that's wrong
>
>[/code]

To expand on Ian's post, it doesn't collide. I don't know if this is
in the standard, but if you're using the preprocessor that comes with
gcc and g++, "#define <macro>" with no text gets you an empty
definition:

https://stackoverflow.com/questions/13892191/are-empty-macro-definitions-allowed-in-c-how-do-they-behave

Louis

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

#68726

On 2019-09-28 at 04:37, Mark wrote:
> 
> [code]
> 
> 
> # ifndef XXX_YYY
> # define XXX_YYY
> 
> //# pragma once //this is what you should do today and beyond (all things being equal .. compiler support)
> # include <cstddef>
> # include <iostream>
> 
>   namespace foo
>   {
>     enum kFavoriteWine { kMoscato, XXX_YYY } ;
>   }
> 
> 
> # endif
> 
> auto main() -> int
> {
>    using namespace foo ;
>    kFavoriteWine xx  = XXX_YYY ;
> 
> }
> Why does the upper case enumerator collided with the preprocessor macro even though the macro is wrapped in a namespace?   Can someone point me to some standard verbiage saying why that's wrong
> 
> [/code]
> 

The preprocessor doesn't care about namespaces, it just replaces 
everything, everywhere.

One common way to avoid this problem is to reserve all-uppercase 
identifiers for the preprocessor, and not use those for anything else.


     Bo Persson

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

#68740

Mark <ma740988@gmail.com> writes:

> # define XXX_YYY
<cut>
>  namespace foo
>  {
>    enum kFavoriteWine { kMoscato, XXX_YYY } ;
>  }

<cut>
>   using namespace foo ;
>   kFavoriteWine xx  = XXX_YYY ;

> Why does the upper case enumerator collided with the preprocessor
> macro even though the macro is wrapped in a namespace?  Can someone
> point me to some standard verbiage saying why that's wrong

To expand yet again on the other answers...

The verbiage is section 2.2 Phases of Translation.  It explains the
logical sequence in which source files are processed.  Macros are
expanded in phase 4, whereas what we usually think of a parsing happens
in phase 7.  By phase 7 there is no identifier 'XXX_YYY' -- they all
vanished in phase 4.

-- 
Ben.

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

#68746

On Saturday, 28 September 2019 05:37:42 UTC+3, Mark  wrote:
> 
> # ifndef XXX_YYY
> # define XXX_YYY

Be more explicit in include guard name about what it is.
Use XXX_YYY_HPP_INCLUDED and the trouble disappears.

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

#68764

On 29/09/2019 01:10, Öö Tiib wrote:
> On Saturday, 28 September 2019 05:37:42 UTC+3, Mark  wrote:
>>
>> # ifndef XXX_YYY
>> # define XXX_YYY
> 
> Be more explicit in include guard name about what it is.
> Use XXX_YYY_HPP_INCLUDED and the trouble disappears.
> 
Our coding standard says to use a sensible name - and then stick a 
random 8-digit hex value after it. It even tells you how to derive the 8 
digits if like most of us you are on Linux.

Andy

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

#68765

On 9/29/2019 10:45 PM, Vir Campestris wrote:
> On 29/09/2019 01:10, Öö Tiib wrote:
>> On Saturday, 28 September 2019 05:37:42 UTC+3, Mark  wrote:
>>>
>>> # ifndef XXX_YYY
>>> # define XXX_YYY
>>
>> Be more explicit in include guard name about what it is.
>> Use XXX_YYY_HPP_INCLUDED and the trouble disappears.
>>
> Our coding standard says to use a sensible name - and then stick a 
> random 8-digit hex value after it. It even tells you how to derive the 8 
> digits if like most of us you are on Linux.
> 
> Andy

Just to remind a very common habit, the "sensible name" is often some 
reformat (often uppercase) of the filename, which has the nice feature 
of being unique at least within a directory (modulo perverse naming 
habits of source files).

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

#68766

On 30/09/2019 09:45, Vir Campestris wrote:
> On 29/09/2019 01:10, Öö Tiib wrote:
>> On Saturday, 28 September 2019 05:37:42 UTC+3, Mark  wrote:
>>>
>>> # ifndef XXX_YYY
>>> # define XXX_YYY
>>
>> Be more explicit in include guard name about what it is.
>> Use XXX_YYY_HPP_INCLUDED and the trouble disappears.
>>
> Our coding standard says to use a sensible name - and then stick a
> random 8-digit hex value after it. It even tells you how to derive the 8
> digits if like most of us you are on Linux.

Are there any mainstream compilers that don't support #pragma once?  It 
makes life much simpler.

-- 
Ian.

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

#68774

On Mon, 2019-09-30, Ian Collins wrote:
> On 30/09/2019 09:45, Vir Campestris wrote:
>> On 29/09/2019 01:10, Öö Tiib wrote:
>>> On Saturday, 28 September 2019 05:37:42 UTC+3, Mark  wrote:
>>>>
>>>> # ifndef XXX_YYY
>>>> # define XXX_YYY
>>>
>>> Be more explicit in include guard name about what it is.
>>> Use XXX_YYY_HPP_INCLUDED and the trouble disappears.
>>>
>> Our coding standard says to use a sensible name - and then stick a
>> random 8-digit hex value after it. It even tells you how to derive the 8
>> digits if like most of us you are on Linux.
>
> Are there any mainstream compilers that don't support #pragma once?  It 
> makes life much simpler.

Life is already simple; I think this thread exaggerates the problem.
In a header foo/bar.h in project someproj:

  #ifndef SOMEPROJ_FOO_BAR_H

The include guard will be unique (as an include guard) and very
unlikely to clash with anything else.

/Jorgen

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

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

#68779

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

> On Mon, 2019-09-30, Ian Collins wrote:
>> On 30/09/2019 09:45, Vir Campestris wrote:
>>> On 29/09/2019 01:10, Öö Tiib wrote:
>>>> On Saturday, 28 September 2019 05:37:42 UTC+3, Mark  wrote:
>>>>>
>>>>> # ifndef XXX_YYY
>>>>> # define XXX_YYY
>>>>
>>>> Be more explicit in include guard name about what it is.
>>>> Use XXX_YYY_HPP_INCLUDED and the trouble disappears.
>>>>
>>> Our coding standard says to use a sensible name - and then stick a
>>> random 8-digit hex value after it. It even tells you how to derive the 8
>>> digits if like most of us you are on Linux.
>>
>> Are there any mainstream compilers that don't support #pragma once?  It 
>> makes life much simpler.
>
> Life is already simple; I think this thread exaggerates the problem.
> In a header foo/bar.h in project someproj:
>
>   #ifndef SOMEPROJ_FOO_BAR_H
>
> The include guard will be unique (as an include guard) and very
> unlikely to clash with anything else.

A handy tip is to start with the H_:

  #ifndef H_SOMEPROJ_FOO_BAR

because SOMEPROJ might begin with E and, at least in C, macro names
beginning with E are reserved for future library versions.

-- 
Ben.

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

#68767

On 9/27/19 10:37 PM, Mark wrote:
> 
> [code]
> 
> 
> # ifndef XXX_YYY
> # define XXX_YYY
> 
> //# pragma once //this is what you should do today and beyond (all things being equal .. compiler support)
> # include <cstddef>
> # include <iostream>
> 
>  namespace foo
>  {
>    enum kFavoriteWine { kMoscato, XXX_YYY } ;
>  }
> 
> 
> # endif
> 
> auto main() -> int
> {
>   using namespace foo ;
>   kFavoriteWine xx  = XXX_YYY ;
> 
> }
> Why does the upper case enumerator collided with the preprocessor macro even though the macro is wrapped in a namespace?   Can someone point me to some standard verbiage saying why that's wrong

The key point is that preprocessing (including the expansion of macros)
occurs during translation phase 4 (5.2p4). Namespaces aren't recognized
as such until translation phase 8 (5.2p8), and therefore have no effect
on preprocessing.

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

#68768

On Saturday, September 28, 2019 at 3:37:42 AM UTC+1, Mark wrote:
>
> # ifndef XXX_YYY
> # define XXX_YYY
> 
> //# pragma once //this is what you should do today and beyond (all things being equal .. compiler support)
> # include <cstddef>
> # include <iostream>
> 
>  namespace foo
>  {
>    enum kFavoriteWine { kMoscato, XXX_YYY } ;
>  }
> 
> 
> # endif
> 
> auto main() -> int
> {
>   using namespace foo ;
>   kFavoriteWine xx  = XXX_YYY ;
> 
> }
> Why does the upper case enumerator collided with the preprocessor macro even though the macro is wrapped in a namespace?   Can someone point me to some standard verbiage saying why that's wrong
> 


Every source code file (.c, .cpp) in your project gets all of its header files added into it, and the preprocessor performs substitutions. What you're left with is called a translation unit.

source file (and it's headers) ------> PREPROCESSOR -------------> translation unit

It is the translation units that are then fed into the compiler:

translation unit -----------------> COMPILER -------------------> object file

And then it is the object files that are fed into the linker:

object files -----------------> LINKER --------------------> executable file

[toc] | [prev] | [standalone]

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

csiph-web