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

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

macro conventions

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

Contents

  macro conventions "Bill Cunningham" <nospam@nspam.invalid> - 2011-05-13 12:56 -0400
    Re: macro conventions pete <pfiland@mindspring.com> - 2011-05-13 13:08 -0400
    Re: macro conventions Shao Miller <sha0.miller@gmail.com> - 2011-05-13 13:14 -0400
      Re: macro conventions Keith Thompson <kst-u@mib.org> - 2011-05-13 11:41 -0700
        Re: macro conventions "Bill Cunningham" <nospam@nspam.invalid> - 2011-05-14 23:08 -0400
    Re: macro conventions ralph <nt_consulting64@yahoo.net> - 2011-05-13 13:15 -0500
      Re: macro conventions "Bill Cunningham" <nospam@nspam.invalid> - 2011-05-14 23:11 -0400
      Re: macro conventions "Bill Cunningham" <nospam@nspam.invalid> - 2011-05-15 04:00 -0400
        Re: macro conventions Angel <angel+news@spamcop.net> - 2011-05-15 11:15 +0000
          Re: macro conventions Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-16 04:36 +0300
            Re: macro conventions Ike Naar <ike@sverige.freeshell.org> - 2011-05-16 09:56 +0000
              Re: macro conventions Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-16 19:00 +0300
              Re: macro conventions Seebs <usenet-nospam@seebs.net> - 2011-05-16 19:10 +0000
                Re: macro conventions Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-22 21:27 +0300
      Re: macro conventions Keith Thompson <kst-u@mib.org> - 2011-05-15 06:50 -0700
        Re: macro conventions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-15 08:29 -0700
          Re: macro conventions Ian Collins <ian-news@hotmail.com> - 2011-05-16 07:40 +1200
            Re: macro conventions "osmium" <r124c4u102@comcast.net> - 2011-05-15 14:52 -0500
        Re: macro conventions ralph <nt_consulting64@yahoo.net> - 2011-05-16 02:22 -0500
          Re: macro conventions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-16 14:18 +0100
            Re: macro conventions David Resnick <lndresnick@gmail.com> - 2011-05-16 08:03 -0700
              Re: macro conventions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-16 17:32 +0100
          Re: macro conventions Keith Thompson <kst-u@mib.org> - 2011-05-16 08:43 -0700
            Re: macro conventions Michael Press <rubrum@pacbell.net> - 2011-05-16 14:47 -0700

Page 1 of 2  [1] 2  Next page →

#3906 — macro conventions

    In defining macros it is of course proper style to use all caps for 
example:

#define AVG 14

    There are other conventions too. In trying to learn what is the 
diference in having one underscore and two underscores in front of or behine 
a macro? For example:

#define __FILE__

Two underscores if front of and behind the define. And here:

#define _GNU_SOURCE

One underscore in front and no underscores at the end. I hope this is clear. 
I want to be sure of these things.

Bill

[toc] | [next] | [standalone]

#3907

Bill Cunningham wrote:
> 
>     In defining macros it is of course proper style
> to use all caps for
> example:
> 
> #define AVG 14
> 
>     There are other conventions too. In trying to learn what is the
> diference in having one underscore and two underscores
> in front of or behine a macro? For example:
> 
> #define __FILE__
> 
> Two underscores if front of and behind the define. And here:
> 
> #define _GNU_SOURCE
> 
> One underscore in front and no underscores at the end.
> I hope this is clear.
> I want to be sure of these things.

The more important thing, 
is to realise that your C implementation uses
some macro conventions which you are not supposed to use.
Macros with leading underscores are an example of that.

ISO/IEC 9899:1999 (E)

7.1.3 Reserved identifiers
    1 Each header declares or defines all identifiers listed
      in its associated subclause, 
      and optionally declares or defines identifiers listed
      in its associated future library directions subclause 
      and identifiers which are always reserved either
      for any use or for use as file scope identifiers.

     — All identifiers that begin with an underscore 
       and either an uppercase letter or another underscore 
       are always reserved for any use.


-- 
pete

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

#3908

On 5/13/2011 12:56, Bill Cunningham wrote:
>      In defining macros it is of course proper style to use all caps for
> example:
>
> #define AVG 14
>
>      There are other conventions too. In trying to learn what is the
> diference in having one underscore and two underscores in front of or behine
> a macro? For example:
>
> #define __FILE__
>
> Two underscores if front of and behind the define. And here:
>
> #define _GNU_SOURCE
>
> One underscore in front and no underscores at the end. I hope this is clear.
> I want to be sure of these things.
>

 From the C99 draft with filename 'n1265.pdf' and its section 6.10.8, 
point 4, we find that "Any other predefined macro names shall begin with 
a leading underscore followed by an uppercase letter or a second 
underscore."

In section 7.1.3, point 1, we find that "All identifiers that begin with 
an underscore and either an uppercase letter or another underscore are 
always reserved for any use" as well as "All identifiers that begin with 
an underscore are always reserved for use as identifiers with file scope 
in both the ordinary and tag name spaces."

I don't think there's anything special about underscores beyond that, 
but I could be mistaken.

The two following underscores you noted in '__FILE__' are not special, 
as far as I know; they're merely part of that standard macro name.

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

#3914

Shao Miller <sha0.miller@gmail.com> writes:
[...]
>  From the C99 draft with filename 'n1265.pdf' and its section 6.10.8, 
> point 4, we find that "Any other predefined macro names shall begin with 
> a leading underscore followed by an uppercase letter or a second 
> underscore."
[...]

You mean n1256.pdf, not n1265.pdf.

It's available at <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#3993

Keith Thompson wrote:

> You mean n1256.pdf, not n1265.pdf.
>
> It's available at
> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>.

    All right got it. Thanks Keith.

Bill

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

#3912

On Fri, 13 May 2011 12:56:20 -0400, "Bill Cunningham"
<nospam@nspam.invalid> wrote:

>    In defining macros it is of course proper style to use all caps for 
>example:
>
>#define AVG 14
>
>    There are other conventions too. In trying to learn what is the 
>diference in having one underscore and two underscores in front of or behine 
>a macro? For example:
>
>#define __FILE__
>
>Two underscores if front of and behind the define. And here:
>
>#define _GNU_SOURCE
>
>One underscore in front and no underscores at the end. I hope this is clear. 
>I want to be sure of these things.
>
>Bill
>

In general:

The use of two underscores ('__') followed by an uppercase letter in
identifiers is reserved for the compiler's internal implementation.

The use of one Underscore ('_') followed by either an upper or lower
case letter in identifiers are reserved for the vendor's
implementation or extensions to the language.

Traditionally macros are all caps to make them more visible within
code made up of mostly lower case characters. There are several nasty
side-effects and nuances associated with macros that makes anything
you can do to make them stand-out useful.

The actual 'rules' and conventions are more complicated and others
will be along shortly to quote chapter and verse. However, in order to
avoid collisions, best practice is simply never create a macro with an
underscore for your own use and use always use uppercase.

-ralph

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

#3994

ralph wrote:

> The actual 'rules' and conventions are more complicated and others
> will be along shortly to quote chapter and verse. However, in order to
> avoid collisions, best practice is simply never create a macro with an
> underscore for your own use and use always use uppercase.

    Thanks.

Bill

>
> -ralph 

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

#4002

ralph wrote:

> The actual 'rules' and conventions are more complicated and others
> will be along shortly to quote chapter and verse. However, in order to
> avoid collisions, best practice is simply never create a macro with an
> underscore for your own use and use always use uppercase.
>
> -ralph

    Isn't there also some conventions used in kernel source code. The Linux 
kernel source that I have looked at (and its been awhile) has some pretty 
different uses in declaring macro names too. But if I am understanding you 
and others in this thread for anything I will be dealing with just the all 
caps will do.

Bill

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

#4004

On 2011-05-15, Bill Cunningham <nospam@nspam.invalid> wrote:
>
>     Isn't there also some conventions used in kernel source code. The Linux 
> kernel source that I have looked at (and its been awhile) has some pretty 
> different uses in declaring macro names too. But if I am understanding you 
> and others in this thread for anything I will be dealing with just the all 
> caps will do.

Kernel programming is very different from normal application
programming on many levels.

For example, you cannot use any of the standard libraries, so
you cannot use the usual printf() or malloc(). (The kernel source does
provide kprintf() and kalloc() though, but they don't work quite the
same.)

And yes, the kernel also has its own macro conventions.


-- 
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c

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

#4046

Angel <angel+news@spamcop.net> writes:

> On 2011-05-15, Bill Cunningham <nospam@nspam.invalid> wrote:
> >
> >     Isn't there also some conventions used in kernel source code. The Linux 
> > kernel source that I have looked at (and its been awhile) has some pretty 
> > different uses in declaring macro names too. But if I am understanding you 
> > and others in this thread for anything I will be dealing with just the all 
> > caps will do.
> 
> Kernel programming is very different from normal application
> programming on many levels.

Bill Cunningham is very different from normal usenet posters on many levels.

Just killfile him, his indistinguishability from a troll has reached epsilon.

Please.

Phil
-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle." -- Matthew Vernon

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

#4058

On 2011-05-16, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
> Just killfile him, his indistinguishability from a troll has reached epsilon.

Killfile someone who doesn't appear to be a troll?

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

#4080

Ike Naar <ike@sverige.freeshell.org> writes:
> On 2011-05-16, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
> > Just killfile him, his indistinguishability from a troll has reached epsilon.
> 
> Killfile someone who doesn't appear to be a troll?

What's weird about that? I think my killfile is about 75% idiots and 50% trolls.
His posts are noise, the replies to them are mostly noise.

Phil
-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle." -- Matthew Vernon

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

#4105

On 2011-05-16, Ike Naar <ike@sverige.freeshell.org> wrote:
> On 2011-05-16, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
>> Just killfile him, his indistinguishability from a troll has reached epsilon.

> Killfile someone who doesn't appear to be a troll?

I think that should have been "distinguishability" or something.

A friend of mine had a wonderful mathematics joke:

	Let epsilon be less than zero...

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#4518

Seebs <usenet-nospam@seebs.net> writes:
> On 2011-05-16, Ike Naar <ike@sverige.freeshell.org> wrote:
> > On 2011-05-16, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
> >> Just killfile him, his indistinguishability from a troll has reached epsilon.
> 
> > Killfile someone who doesn't appear to be a troll?
> 
> I think that should have been "distinguishability" or something.

Hmmm, yeah. I was trying to measure closeness using a distance.

> A friend of mine had a wonderful mathematics joke:
> 
> 	Let epsilon be less than zero...

Too subtle. Take a large negative epsilon ...

Phil
-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle." -- Matthew Vernon

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

#4017

ralph <nt_consulting64@yahoo.net> writes:
[...]
> The actual 'rules' and conventions are more complicated and others
> will be along shortly to quote chapter and verse. However, in order to
> avoid collisions, best practice is simply never create a macro with an
> underscore for your own use and use always use uppercase.

TO be clear, it's leading underscores that should be avoided.  FOO_BAR,
for example, is perfectly ok.  Trailing underscores are also ok, though
I wouldn't use them without a good reason.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#4021

On May 15, 4:50 pm, Keith Thompson <ks...@mib.org> wrote:
> ralph <nt_consultin...@yahoo.net> writes:
>
> TO be clear, it's leading underscores that should be avoided.  FOO_BAR,
> for example, is perfectly ok.  Trailing underscores are also ok, though
> I wouldn't use them without a good reason.
>
One problem with underscores is that they are not pronounced. So it
can be hard to remember whether it's FOO_BAR or FOOBAR. Also,
experience with websites has shown that people prefer words
runtogetherratherthan separated_out_by_underscores, if spaces aren't
an option.

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

#4033

On 05/16/11 03:29 AM, Malcolm McLean wrote:
> On May 15, 4:50 pm, Keith Thompson<ks...@mib.org>  wrote:
>> ralph<nt_consultin...@yahoo.net>  writes:
>>
>> TO be clear, it's leading underscores that should be avoided.  FOO_BAR,
>> for example, is perfectly ok.  Trailing underscores are also ok, though
>> I wouldn't use them without a good reason.
>>
> One problem with underscores is that they are not pronounced. So it
> can be hard to remember whether it's FOO_BAR or FOOBAR.

They are pounced as a space or pause, FOO_BAR is pronounced as FOO BAR, 
not FOOBAR.

> Also,
> experience with websites has shown that people prefer words
> runtogetherratherthan separated_out_by_underscores, if spaces aren't
> an option.

Citation?  I could understand runTogetherRatherThan.

-- 
Ian Collins

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

#4034

"Ian Collins" wrote:

> On 05/16/11 03:29 AM, Malcolm McLean wrote:


>> [E]xperience with websites has shown that people prefer words
>> runtogetherratherthan separated_out_by_underscores, if spaces aren't
>> an option.
>
> Citation?  I could understand runTogetherRatherThan.

I share your skepticism, but a citation wouldn't really help, would it? 
This is subjective, social sciences kind of stuff.  And this is Usenet. 
sometiomespeoplesimplymakethingsup. 

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

#4055

On Sun, 15 May 2011 06:50:54 -0700, Keith Thompson <kst-u@mib.org>
wrote:

>ralph <nt_consulting64@yahoo.net> writes:
>[...]
>> The actual 'rules' and conventions are more complicated and others
>> will be along shortly to quote chapter and verse. However, in order to
>> avoid collisions, best practice is simply never create a macro with an
>> underscore for your own use and use always use uppercase.
>
>TO be clear, it's leading underscores that should be avoided.  FOO_BAR,
>for example, is perfectly ok.  Trailing underscores are also ok, though
>I wouldn't use them without a good reason.

Thanks for that catch. I did make it sound like underscores should be
avoided throughout an identifier, when they are in fact OK. 

It should also be amplified that double underscores "_ _" are reserved
even within or trailing an identifier

     FOO_BAR is OK, FOO__BAR or FOOBAR__ is not.

Luckily most collisions are grievous enough to become quickly
identified during development. Real trouble often comes about, not
from using underscores per se, but from using certain keywords,
letters, or library tags as prefixes. For example, many years back I
remember a team getting tangled up with macros beginning with "E_",
"SIG_", "XL_", and "H_".

The problem in that case was not the few hours lost to development to
go back and clean it up. It was the endless ugliness that came about
because some pointed-hair boss decided that to avoid all future
collisions, all macros would be defined as ...

      ABC_Co_FOO_BAR,
      ABC_Co_Inventory_FOO_BAR,
      ABC_Co_Errors_FOO_BAR,
      ABC_Co_HeaderFile_FOO_BAR
      ...

Moral of the story: If you are working on a team and have a collision
- fix it AND keep your mouth shut. <bg>

-ralph

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

#4067

ralph <nt_consulting64@yahoo.net> writes:

> On Sun, 15 May 2011 06:50:54 -0700, Keith Thompson <kst-u@mib.org>
> wrote:
>
>>ralph <nt_consulting64@yahoo.net> writes:
>>[...]
>>> The actual 'rules' and conventions are more complicated and others
>>> will be along shortly to quote chapter and verse. However, in order to
>>> avoid collisions, best practice is simply never create a macro with an
>>> underscore for your own use and use always use uppercase.
>>
>>TO be clear, it's leading underscores that should be avoided.  FOO_BAR,
>>for example, is perfectly ok.  Trailing underscores are also ok, though
>>I wouldn't use them without a good reason.
>
> Thanks for that catch. I did make it sound like underscores should be
> avoided throughout an identifier, when they are in fact OK. 
>
> It should also be amplified that double underscores "_ _" are reserved
> even within or trailing an identifier
>
>      FOO_BAR is OK, FOO__BAR or FOOBAR__ is not.

What's your source?

<snip>
-- 
Ben.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web