Quantcast

Naming of multiple inclusion guards in MinGW headers

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Naming of multiple inclusion guards in MinGW headers

Keith Marshall-3
Guys,

I've noticed that we have some headers guarded by macros named according
to a _FOO_H_ convention (with a trailing underscore), while others
conform to _BAR_H (without the trailing underscore); we really need to
standardize on one or the other.

I have a mild preference for the latter, but can accept the former; I
cannot accept indefinite persistence of the present inconsistency.

Any strong contrary opinions, before I embark on a standardization
campaign?  (If you disagree, and don't speak up *now*, I will begin to
move toward adoption the _BAR_H style, just as soon as I find a window
of opportunity; (which may be two or three months hence).

--
Regards,
Keith.

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Naming of multiple inclusion guards in MinGW headers

Cesar Strauss-2
On 05-17-2015 05:03, Keith Marshall wrote:
> I've noticed that we have some headers guarded by macros named according
> to a _FOO_H_ convention (with a trailing underscore), while others
> conform to _BAR_H (without the trailing underscore); we really need to
> standardize on one or the other.

w32api seem to be almost uniformly using _BAR_H

# Using _FOO_H_
$ grep -ril 'ifndef.*_H_' .|wc -l
4

# Using either _FOO_H_ or _BAR_H
$ grep -ril 'ifndef.*_H' .|wc -l
394

mingwrt prefers _FOO_H_

# Using _FOO_H_
$ grep -ril 'ifndef.*_H_' .|wc -l
43

# Using either _FOO_H_ or _BAR_H
$ grep -ril 'ifndef.*_H' .|wc -l
55

At this point, if you want to harmonize mingwrt and w32api, it seems to
be easier to go with _BAR_H.

Regards,

Cesar

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Naming of multiple inclusion guards in MinGW headers

Keith Marshall-3
On 17/05/15 15:03, Cesar Strauss wrote:
> On 05-17-2015 05:03, Keith Marshall wrote:
>> I've noticed that we have some headers guarded by macros named according
>> to a _FOO_H_ convention (with a trailing underscore), while others
>> conform to _BAR_H (without the trailing underscore); we really need to
>> standardize on one or the other.
>
> w32api seem to be almost uniformly using _BAR_H

Thanks, Cesar.  My focus has been primarily mingwrt, but this info
reinforces my preference for the _BAR_H style.

> # Using _FOO_H_
> $ grep -ril 'ifndef.*_H_' .|wc -l
> 4

Of these, one is a false positive, matching:

  #ifndef __RPCNDR_H_VERSION__

If we confine it more strictly, (with ^I representing TAB):

  $ hg grep -i 'ifndef.*_H_[^I_ ]*$' w32api/
  w32api/include/GL/gl.h:150:#ifndef __gl_h_
  w32api/include/GL/glext.h:150:#ifndef __glext_h_
  w32api/include/GL/glu.h:150:#ifndef __glu_h__

we may observe that the three genuine hits are in headers associated
with the OpenGL implementation, (which BTW, is licensed under the SGI
Free Software License B ... a situation of which we've been somewhat lax
in advising our users).

> # Using either _FOO_H_ or _BAR_H
> $ grep -ril 'ifndef.*_H' .|wc -l
> 394

I'm seeing rather fewer, in my w32api-3.17 source tree:

  $ hg grep -il 'ifndef.*_H' w32api/ | wc -l
  339

(but closer agreement, without '-l'):

  $ hg grep -i 'ifndef.*_H' w32api/ | wc -l
  396

Once again, stricter filtering of false positives yields a reduced count:

  $ hg grep -il 'ifndef.*_H[^I_ ]*$' w32api/ | wc -l
  313

> mingwrt prefers _FOO_H_
>
> # Using _FOO_H_
> $ grep -ril 'ifndef.*_H_' .|wc -l
> 43
>
> # Using either _FOO_H_ or _BAR_H
> $ grep -ril 'ifndef.*_H' .|wc -l
> 55

Here, our respective trees seem to be in complete agreement:

  $ hg grep -il 'ifndef.*_H_' mingwrt/ | wc -l
  43

  $ hg grep -il 'ifndef.*_H' mingwrt/ | wc -l
  55

and the stricter filtering catches two false positives:

  $ hg grep -il 'ifndef.*_H_[^I_ ]*$' mingwrt/ | wc -l
  42

  $ hg grep -il 'ifndef.*_H[^I_ ]*$' mingwrt/ | wc -l
  53

> At this point, if you want to harmonize mingwrt and w32api,

Yes, this is the goal I'd like to achieve, following on from this
discussion.

> it seems to be easier to go with _BAR_H.

Agreed.  And, since this matches my preference anyway, in the absence of
any vehement objections from others, this is the direction in which I
would like to move, when I eventually get around to it.

--
Regards,
Keith.

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Loading...