By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,220 Members | 1,588 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,220 IT Pros & Developers. It's quick & easy.

Rob Pike's simple Include rule

P: n/a
In Rob Pike's style guide he urges the following:

Simple rule: include files should never include include
files. If instead they state (in comments or implicitly)
what files they need to have included first, the problem of
deciding which files to include is pushed to the user
(programmer) but in a way that's easy to handle and that,
by construction, avoids multiple inclusions.

I was startled by this guideline, since it's not what I think of
as the usual practice, i.e., brute-force idempotency through
header guards in the headers.

I have three questions about this advice, for those who use a
similar style:

1. Is following this guideline facile or hassle? I converted a
simple two-header program over to this style, making several
errors along the way. I clearly don't have experience
with it.

2. How does a header state implicitly what it requires for
headers? I assume he means that you gleen this information by
reading the header file, but I want to make sure I'm not missing
something interesting.

It seems like a good candidate for automation.

--
Neil Cerutti
"Do you wanna see 'em?"
"See what?"
"The corpses. They're in the basement." --_Return of the Living Dead_.
Nov 14 '05 #1
Share this Question
Share on Google+
44 Replies


P: n/a
Neil Cerutti wrote:
Simple rule: include files should never include include
files.

Is following this guideline facile or hassle?


Definitely a hassle, and the only real gain is to avoid polluting the
namespace; the quoted benefit (prevention of multiple inclusion) does
not matter one whit, as you can accomplish it with some pre-processor
directives, as you note.

For the real problem (namespace pollution), one should document which
headers are included by each.

--
++acr@,ka"
Nov 14 '05 #2

P: n/a
On 22 Apr 2004 18:52:12 GMT, Neil Cerutti <ho*****@yahoo.com> wrote:
In Rob Pike's style guide he urges the following:

Simple rule: include files should never include include
files. If instead they state (in comments or implicitly)
what files they need to have included first, the problem of
deciding which files to include is pushed to the user
(programmer) but in a way that's easy to handle and that,
by construction, avoids multiple inclusions.

I was startled by this guideline, since it's not what I think of
as the usual practice, i.e., brute-force idempotency through
header guards in the headers.
FWIW, I disagree with Rob Pike on this issue. I believe an include
file should include whatever other headers it itself needs. However,
it shouldn't include any others. Finding after the first compile that
some header file needed another header included in front of it is
legitimate grounds for cursing the author.
I have three questions about this advice, for those who use a
similar style:

1. Is following this guideline facile or hassle? I converted a
simple two-header program over to this style, making several
errors along the way. I clearly don't have experience
with it.

2. How does a header state implicitly what it requires for
headers? I assume he means that you gleen this information by
reading the header file, but I want to make sure I'm not missing
something interesting.

It seems like a good candidate for automation.


What's the third question? :-)

--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 14 '05 #3

P: n/a
"Neil Cerutti" <ho*****@yahoo.com> wrote in message
news:c6************@ID-60390.news.uni-berlin.de...
In Rob Pike's style guide he urges the following:

Simple rule: include files should never include include
files. If instead they state (in comments or implicitly)
what files they need to have included first, the problem of
deciding which files to include is pushed to the user
(programmer) but in a way that's easy to handle and that,
by construction, avoids multiple inclusions.

I was startled by this guideline, since it's not what I think of
as the usual practice, i.e., brute-force idempotency through
header guards in the headers.


Header guards are cheap and don't require extra vigilance on the part of the
programmer using your library. I've worked on a couple open-source projects
where include dependencies were a nightmare until I added header guards to
all the files and just brute-force included things in headers as needed.

What are the counter-cases where header guards are NOT the most efficient
solution?

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

Nov 14 '05 #4

P: n/a
Neil Cerutti wrote:
In Rob Pike's style guide


http://www.chris-lott.org/resources/...pikestyle.html

I just read Rob Pikes style guide
and I recommend that you ignore it.

Nov 14 '05 #5

P: n/a
In article <u4********************************@4ax.com>, Alan
Balmer wrote:
On 22 Apr 2004 18:52:12 GMT, Neil Cerutti <ho*****@yahoo.com> wrote:
In Rob Pike's style guide he urges the following:

Simple rule: include files should never include include
files.

I have three questions about this advice, for those who use a
similar style:

1. Is following this guideline facile or hassle?

2. How does a header state implicitly what it requires for
headers?


What's the third question? :-)


Oops.

3. What is the average air-speed velocity of an unladen sparrow?

--
Neil Cerutti
"Do you wanna see 'em?"
"See what?"
"The corpses. They're in the basement." --_Return of the Living Dead_.
Nov 14 '05 #6

P: n/a
Neil Cerutti wrote:
In Rob Pike's style guide he urges the following:

Simple rule: include files should never include include
files. If instead they state (in comments or implicitly)
what files they need to have included first, the problem of
deciding which files to include is pushed to the user
(programmer) but in a way that's easy to handle and that,
by construction, avoids multiple inclusions.

I was startled by this guideline, since it's not what I think of
as the usual practice, i.e., brute-force idempotency through
header guards in the headers.


In our shop we have the types
UINT8, UINT16, UINT32
defined a unsigned integers with the given bitwidth.

We have one file, let's say types.h, which defines those types
for various platforms.

So if I write a function:
UINT8 Public_Function(UINT16 variable)
{
/* ... */
}

and I want to make it public, I put it into a header file
my_functions.h:
UINT8 Public_Function(UINT16 variable);

Now, since it uses the UINT8 and UINT16 in the declaration,
those identifiers must be resolved before this function
declaration.

According to the style guide, a programmer must include
the types.h file before the my_functions.h file.

If the my_functions.h file has the statements:
#ifndef UINT8
#include "types.h"
#endif
before the function declaration, the user only has to
worry about including one function. The header file
takes care of its own declaration issues.
--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

Nov 14 '05 #7

P: n/a
Neil Cerutti wrote:
Alan Balmer wrote:
Neil Cerutti <ho*****@yahoo.com> wrote:
In Rob Pike's style guide he urges the following:

Simple rule: include files should never include include
files.

I have three questions about this advice, for those who use a
similar style:

1. Is following this guideline facile or hassle?

2. How does a header state implicitly what it requires for
headers?


What's the third question? :-)


Oops.

3. What is the average air-speed velocity of an unladen sparrow?


Approximately 27 kilofurlongs per fortnight.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #8

P: n/a
On Fri, 23 Apr 2004 16:19:41 GMT, Thomas Matthews
<Th****************************@sbcglobal.net> wrote:
According to the style guide, a programmer must include
the types.h file before the my_functions.h file.

If the my_functions.h file has the statements:
#ifndef UINT8
#include "types.h"
#endif
before the function declaration, the user only has to
worry about including one function. The header file
takes care of its own declaration issues.


Exactly. But you say this is contrary to your style guide?

Better yet, imo, if the types.h file had a header guard, the
#ifndef/#endif in my_functions.h would be unnecessary.

--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 14 '05 #9

P: n/a
Alan Balmer wrote:
On 22 Apr 2004 18:52:12 GMT, Neil Cerutti <ho*****@yahoo.com> wrote:

In Rob Pike's style guide he urges the following:

Simple rule: include files should never include include
files. If instead they state (in comments or implicitly)
what files they need to have included first, the problem of
deciding which files to include is pushed to the user
(programmer) but in a way that's easy to handle and that,
by construction, avoids multiple inclusions.

I was startled by this guideline, since it's not what I think of
as the usual practice, i.e., brute-force idempotency through
header guards in the headers.

FWIW, I disagree with Rob Pike on this issue. I believe an include
file should include whatever other headers it itself needs. However,
it shouldn't include any others. Finding after the first compile that
some header file needed another header included in front of it is
legitimate grounds for cursing the author.
I have three questions about this advice, for those who use a
similar style:

1. Is following this guideline facile or hassle? I converted a
simple two-header program over to this style, making several
errors along the way. I clearly don't have experience
with it.

2. How does a header state implicitly what it requires for
headers? I assume he means that you gleen this information by
reading the header file, but I want to make sure I'm not missing
something interesting.

It seems like a good candidate for automation.

What's the third question? :-)

Conjecture: The source of Pike's guideline may not
have been addressing C-language per se, but rather
external factors, such as the "make" program.
(Which makes this OT in c.l.c, I guess.)

The earliest versions of "make" only checked for
explicit dependencies as specified in the "makefile".

Thus, if a.c included a.h which included b.h *and*
b.h was not an explicit dependency in the makefile,
then a.c would not get recompiled when b.h changed.
At best, you got a compile-time error. At worst,
you got undefined behavior or a core-dump after
delivery to the customer.

Developers were usually good about finding all the
#include directives in their own code in order to
create the makefile, but hardly ever checked whether
or not there were nested includes within other files.
This /may/ have been the reason for the guidelines
noted above.

More modern versions of "make" do this checking
for you. So if you have those versions, it has been
automated already.

--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
Nov 14 '05 #10

P: n/a
In <c6************@ID-60390.news.uni-berlin.de> Neil Cerutti <ho*****@yahoo.com> writes:
In Rob Pike's style guide he urges the following:

Simple rule: include files should never include include
files. If instead they state (in comments or implicitly)
what files they need to have included first, the problem of
deciding which files to include is pushed to the user
(programmer) but in a way that's easy to handle and that,
by construction, avoids multiple inclusions.

I was startled by this guideline, since it's not what I think of
as the usual practice, i.e., brute-force idempotency through
header guards in the headers.

I have three questions about this advice, for those who use a
similar style:

1. Is following this guideline facile or hassle?
It's a nightmare for both the implementor and the user. Consider
things like size_t and NULL, that are supposed to be available in
several headers: if the implementor wants to change one of them, he
must take care to change *all* the headers defining/declaring the
identifier in question.
2. How does a header state implicitly what it requires for
headers?


If you see the following in a header:

void foo(FILE *);

then this header implicitly states that <stdio.h> must be included first.

I guess Pike was either drunken or stoned when he suggested that the
users of a header actually read the header in order to figure out its
dependencies.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #11

P: n/a
CBFalconer <cb********@yahoo.com> writes:
Neil Cerutti wrote:
Alan Balmer wrote:
Neil Cerutti <ho*****@yahoo.com> wrote:

In Rob Pike's style guide he urges the following:

Simple rule: include files should never include include
files.

I have three questions about this advice, for those who use a
similar style:

1. Is following this guideline facile or hassle?

2. How does a header state implicitly what it requires for
headers?

What's the third question? :-)


Oops.

3. What is the average air-speed velocity of an unladen sparrow?


Approximately 27 kilofurlongs per fortnight.


Actually, it's about 60 to 66 kilofurlongs per fortnight
(10 to 11 meters/second).

<http://www.style.org/unladenswallow/>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 14 '05 #12

P: n/a
In article <c6***********@sunnews.cern.ch>, Da*****@cern.ch (Dan Pop)
wrote:
In <c6************@ID-60390.news.uni-berlin.de> Neil Cerutti
<ho*****@yahoo.com> writes:
In Rob Pike's style guide he urges the following:

Simple rule: include files should never include include
files. If instead they state (in comments or implicitly)
what files they need to have included first, the problem of
deciding which files to include is pushed to the user
(programmer) but in a way that's easy to handle and that,
by construction, avoids multiple inclusions.

I was startled by this guideline, since it's not what I think of
as the usual practice, i.e., brute-force idempotency through
header guards in the headers.

I have three questions about this advice, for those who use a
similar style:

1. Is following this guideline facile or hassle?


It's a nightmare for both the implementor and the user. Consider
things like size_t and NULL, that are supposed to be available in
several headers: if the implementor wants to change one of them, he
must take care to change *all* the headers defining/declaring the
identifier in question.
2. How does a header state implicitly what it requires for
headers?


If you see the following in a header:

void foo(FILE *);

then this header implicitly states that <stdio.h> must be included first.

I guess Pike was either drunken or stoned when he suggested that the
users of a header actually read the header in order to figure out its
dependencies.


I prefer the rule that

#include "header.h"

as the first line in a source should compile without error for every
header file, and that changing the order of "#include"s should not make
any difference.
Nov 14 '05 #13

P: n/a
"Nick Landsberg" <hu*****@NOSPAM.att.net> wrote in message
news:jZ********************@bgtnsc05-news.ops.worldnet.att.net...
Alan Balmer wrote:
On 22 Apr 2004 18:52:12 GMT, Neil Cerutti <ho*****@yahoo.com> wrote:

In Rob Pike's style guide he urges the following:

Simple rule: include files should never include include
files. If instead they state (in comments or implicitly)
what files they need to have included first, the problem of
deciding which files to include is pushed to the user
(programmer) but in a way that's easy to handle and that,
by construction, avoids multiple inclusions.

/snip/
Conjecture: The source of Pike's guideline may not
have been addressing C-language per se, but rather
external factors, such as the "make" program.
(Which makes this OT in c.l.c, I guess.)

The earliest versions of "make" only checked for
explicit dependencies as specified in the "makefile".

Thus, if a.c included a.h which included b.h *and*
b.h was not an explicit dependency in the makefile,
then a.c would not get recompiled when b.h changed.
At best, you got a compile-time error. At worst,
you got undefined behavior or a core-dump after
delivery to the customer.


I would think that most developers using MAKE would
have added a dependency line specifying that a.h
depends on b.h, with a "touch" command that will
make a.h current (thus trigging a compile for a.c).
Nov 14 '05 #14

P: n/a
Keith Thompson wrote:
CBFalconer <cb********@yahoo.com> writes:
Neil Cerutti wrote:
.... snip ...

3. What is the average air-speed velocity of an unladen sparrow?


Approximately 27 kilofurlongs per fortnight.


Actually, it's about 60 to 66 kilofurlongs per fortnight
(10 to 11 meters/second).

<http://www.style.org/unladenswallow/>


I was that far off huh. Not too bad for a blind stab with no
furlong sparrows frolicing outside my window for the past
fortnight.

What about max. accelleration, in kf/fn^2?

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

Nov 14 '05 #15

P: n/a
Christian Bau wrote:


I prefer the rule that

#include "header.h"

as the first line in a source
should compile without error for every header file, and that
changing the order of "#include"s should not make any difference.


This is equivalent to saying that header files should be

1. self sufficient and
2. idempotent.

Nov 14 '05 #16

P: n/a
In article <jZ********************@bgtnsc05-news.ops.worldnet.att.net> hu*****@NOSPAM.att.net writes:
Conjecture: The source of Pike's guideline may not
have been addressing C-language per se, but rather
external factors, such as the "make" program.
(Which makes this OT in c.l.c, I guess.)
I do not know from what time Pike's guideline comes, but I think it
is an old guideline, and indeed made sense with old versions of make
without additional tools.
The earliest versions of "make" only checked for
explicit dependencies as specified in the "makefile".

Thus, if a.c included a.h which included b.h *and*
b.h was not an explicit dependency in the makefile,
then a.c would not get recompiled when b.h changed.
At best, you got a compile-time error. At worst,
you got undefined behavior or a core-dump after
delivery to the customer.


That is why already quite early the command 'makedepend' was created
which would get all dependencies and add them to the makefile.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Nov 14 '05 #17

P: n/a
CBFalconer <cb********@yahoo.com> writes:
Keith Thompson wrote:
CBFalconer <cb********@yahoo.com> writes:
Neil Cerutti wrote:
... snip ...
3. What is the average air-speed velocity of an unladen sparrow?

Approximately 27 kilofurlongs per fortnight.
Actually, it's about 60 to 66 kilofurlongs per fortnight
(10 to 11 meters/second).

<http://www.style.org/unladenswallow/>


I was that far off huh. Not too bad for a blind stab with no
furlong sparrows frolicing outside my window for the past
fortnight.


I see now that I didn't read your original question carefully enough.
You asked about sparrows, not swallows. Since sparrows are much
slower than swallows, you may have been pretty close. (27 kf/fn is
about 10 mph or 4.5 meters/second, which seems plausible for a
sparrow, though I don't have any actual figures.)
What about max. accelleration, in kf/fn^2?


Sorry, maximum acceleration of sparrows and swallows is off-topic.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 14 '05 #18

P: n/a
xarax wrote:
"Nick Landsberg" <hu*****@NOSPAM.att.net> wrote in message
news:jZ********************@bgtnsc05-news.ops.worldnet.att.net...
Alan Balmer wrote:

On 22 Apr 2004 18:52:12 GMT, Neil Cerutti <ho*****@yahoo.com> wrote:

In Rob Pike's style guide he urges the following:

Simple rule: include files should never include include
files. If instead they state (in comments or implicitly)
what files they need to have included first, the problem of
deciding which files to include is pushed to the user
(programmer) but in a way that's easy to handle and that,
by construction, avoids multiple inclusions.

/snip/

Conjecture: The source of Pike's guideline may not
have been addressing C-language per se, but rather
external factors, such as the "make" program.
(Which makes this OT in c.l.c, I guess.)

The earliest versions of "make" only checked for
explicit dependencies as specified in the "makefile".

Thus, if a.c included a.h which included b.h *and*
b.h was not an explicit dependency in the makefile,
then a.c would not get recompiled when b.h changed.
At best, you got a compile-time error. At worst,
you got undefined behavior or a core-dump after
delivery to the customer.

I would think that most developers using MAKE would
have added a dependency line specifying that a.h
depends on b.h, with a "touch" command that will
make a.h current (thus trigging a compile for a.c).


<OT>
"Most" does not include "all" by definition.

(Not being sarcastic, just realistic.) All it takes
is one developer who doesn't do it and the house of cards falls.

I have personally rapped the knuckles of those
who did not in the days when I was the "integrator".

Actually, it's easier to change the makefile to
have a dependency on both a.h and b.h rather than
use the "touch" command.
</OT>

--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
Nov 14 '05 #19

P: n/a
In article <40**************@jpl.nasa.gov>,
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:
Christian Bau wrote:


I prefer the rule that

#include "header.h"

as the first line in a source
should compile without error for every header file, and that
changing the order of "#include"s should not make any difference.


This is equivalent to saying that header files should be

1. self sufficient and
2. idempotent.


Bugger off, you idiot.
Nov 14 '05 #20

P: n/a
Christian Bau <ch***********@cbau.freeserve.co.uk> writes:
I prefer the rule that

#include "header.h"

as the first line in a source should compile without error for every
header file, and that changing the order of "#include"s should not make
any difference.


Personally, I recently began enforcing this rule in my own code
by making every file.c include its own file.h as its very first
#include. (I got this suggestion from _Large-Scale C++ Design_,
if I recall correctly.)
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}
Nov 14 '05 #21

P: n/a
Christian Bau <ch***********@cbau.freeserve.co.uk> writes:
In article <40**************@jpl.nasa.gov>,
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:
Christian Bau wrote:
> I prefer the rule that
>
> #include "header.h"
>
> as the first line in a source
> should compile without error for every header file, and that
> changing the order of "#include"s should not make any difference.


This is equivalent to saying that header files should be

1. self sufficient and
2. idempotent.


Bugger off, you idiot.


I think that ERT is actually correct in this case.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x1f6},*p=
b,x,i=24;for(;p+=!*p;*p/=4)switch(x=*p&3)case 0:{return 0;for(p--;i--;i--)case
2:{i++;if(1)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}
Nov 14 '05 #22

P: n/a
In article <87************@blp.benpfaff.org>,
Ben Pfaff <bl*@cs.stanford.edu> wrote:
Christian Bau <ch***********@cbau.freeserve.co.uk> writes:
In article <40**************@jpl.nasa.gov>,
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:
Christian Bau wrote:
> I prefer the rule that
>
> #include "header.h"
>
> as the first line in a source
> should compile without error for every header file, and that
> changing the order of "#include"s should not make any difference.

This is equivalent to saying that header files should be

1. self sufficient and
2. idempotent.


Bugger off, you idiot.


I think that ERT is actually correct in this case.


I didn't say he was incorrect. I said he was an idiot.
Nov 14 '05 #23

P: n/a
On Fri, 23 Apr 2004 20:03:42 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:
CBFalconer <cb********@yahoo.com> writes:
Neil Cerutti wrote:
>
> 3. What is the average air-speed velocity of an unladen sparrow?
Approximately 27 kilofurlongs per fortnight.


Actually, it's about 60 to 66 kilofurlongs per fortnight
(10 to 11 meters/second).


Keith, when you can find me a sparrow that can fly continuously for a
fortnight, I;ll go with your figure rather than CBF's...
<http://www.style.org/unladenswallow/>


since when were sparrows swallows? :-)
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #24

P: n/a
"Neil Cerutti" <ho*****@yahoo.com> wrote in message
news:c6************@ID-60390.news.uni-berlin.de...
What's the third question? :-)


Oops.

3. What is the average air-speed velocity of an unladen sparrow?


<OT>

The Bridgekeeper in Monty Python and the Holy Grail actually asks...

What... is the air-speed velocity of an unladen swallow?

</OT>

--
Peter
Nov 14 '05 #25

P: n/a
Mark McIntyre <ma**********@spamcop.net> writes:
On Fri, 23 Apr 2004 20:03:42 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:
CBFalconer <cb********@yahoo.com> writes:
Neil Cerutti wrote:
>
> 3. What is the average air-speed velocity of an unladen sparrow?

Approximately 27 kilofurlongs per fortnight.


Actually, it's about 60 to 66 kilofurlongs per fortnight
(10 to 11 meters/second).


Keith, when you can find me a sparrow that can fly continuously for a
fortnight, I;ll go with your figure rather than CBF's...


When you successfully argue in traffic court that you weren't really
driving 80 miles/hour because you were only doing it for 10 minutes,
I'll take that argument seriously. (Convert units as necessary for
non-US traffic courts.)

However ...
<http://www.style.org/unladenswallow/>


since when were sparrows swallows? :-)


I acknowledged my error elsethread.

"This is getting silly." -- Graham Chapman

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 14 '05 #26

P: n/a
Da*****@cern.ch (Dan Pop) wrote in message news:<c6***********@sunnews.cern.ch>...
In <c6************@ID-60390.news.uni-berlin.de> Neil Cerutti <ho*****@yahoo.com> writes:
In Rob Pike's style guide he urges the following:

Simple rule: include files should never include include
files. If instead they state (in comments or implicitly)
what files they need to have included first, the problem of
deciding which files to include is pushed to the user
(programmer) but in a way that's easy to handle and that,
by construction, avoids multiple inclusions.

1. Is following this guideline facile or hassle?


It's a nightmare for both the implementor and the user. Consider
things like size_t and NULL, that are supposed to be available in
several headers: if the implementor wants to change one of them, he
must take care to change *all* the headers defining/declaring the
identifier in question.
2. How does a header state implicitly what it requires for
headers?


If you see the following in a header:

void foo(FILE *);

then this header implicitly states that <stdio.h> must be included first.

I guess Pike was either drunken or stoned when he suggested that the
users of a header actually read the header in order to figure out its
dependencies.

Dan


I didn't read Pike's original statements but I guess I am exposed to
an even stricter style guide: within a client company of mine there is
the rule that every header file has to have an "PRIVATE" section which
defines (not declares!) all file-global objects. Below there needs to
be a "PUBLIC" (or EXTERN, I don't remember) and a "COMMON" section
which declare the respective "purely extern" objects which are
exported by this module (whatever that means) and the shared objects.
Yes, I am still talking C, though the creator admits that his
construct is influenced by a C++ class definition. For a clearer idea
let me picture a typical header file as it is required to be:
foo.h (accompanying header file to foo.c)

typedef int bar; // common section for all
#ifdef _PRIVATE
#undef _PRIVATE
// used inside foo.c
bar Global;
bar foo(void);
#else
// used outside of foo.c
extern bar Global;
extern bar foo(void);
#endif

foo.c has to include foo.h as the last header file, with a preceding
#define _PRIVATE

And yes, the "no include includes others"-rule is in effect too.
Aside from the bad but sometimes inevitable global variables, I
consider this style ultimately evil, but I lack the proper verbal
ammunition to sink it. Anyone who can help with a list of unbeatable
arguments against it?

Mark
Nov 14 '05 #27

P: n/a
In article <40********@news.rivernet.com.au>, Peter Nilsson wrote:
"Neil Cerutti" <ho*****@yahoo.com> wrote in message
news:c6************@ID-60390.news.uni-berlin.de...
> What's the third question? :-)


Oops.

3. What is the average air-speed velocity of an unladen sparrow?


<OT>

The Bridgekeeper in Monty Python and the Holy Grail actually asks...

What... is the air-speed velocity of an unladen swallow?

</OT>


I apologize for being a dodo and cocking up the joke.

--
Neil Cerutti
"Where do they get all the corpses with perfect teeth?"
--_Return of the Living Dead_.
Nov 14 '05 #28

P: n/a
On Fri, 23 Apr 2004 13:47:40 -0400, "Xenos"
<do**********@spamhate.com> wrote:

"Nick Landsberg" <hu*****@NOSPAM.att.net> wrote in message
news:jZ********************@bgtnsc05-news.ops.worldnet.att.net...
The earliest versions of "make" only checked for
explicit dependencies as specified in the "makefile".

Thus, if a.c included a.h which included b.h *and*
b.h was not an explicit dependency in the makefile,
then a.c would not get recompiled when b.h changed.
At best, you got a compile-time error. At worst,
you got undefined behavior or a core-dump after
delivery to the customer.

Developers were usually good about finding all the
#include directives in their own code in order to
create the makefile, but hardly ever checked whether
or not there were nested includes within other files.
This /may/ have been the reason for the guidelines
noted above.

More modern versions of "make" do this checking
for you. So if you have those versions, it has been
automated already.

--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
This is untrue. I know of no make tool (gnu, ms, or otherwise) that will
take it upon itself to examine your code for dependencies.


makedepend. While it may not be the same executable as make (and then
again, it may be), it's part of the same tool chain and closely
integrated, and no one actually cares what executable it's in, so long
as it does its job.
Make has no
knowledge of C will not examine #include lines, nor do a transitive closure
on them for dependency information. Some modern compilation systems with do
this type of thing (gcc with the -M option, Visual Studio, gnatmake for Ada,
etc.). But make itself will not.

DrX


--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 14 '05 #29

P: n/a
> makedepend. While it may not be the same executable as make (and then
again, it may be), it's part of the same tool chain and closely
integrated, and no one actually cares what executable it's in, so long
as it does its job.
-- Al Balmer
Balmer Consulting
re************************@att.net


makedepend is not part of make. Its a tool separate tool (and not part of
any "tool chain") use to modify existing makefiles to add target
dependencies to the end of the file. Modify the makefile is not something
I'd recommend. I'd much prefer someithing like:
http://make.paulandlesley.org/autodep.html.

Someone will care if they need a separate tool, like makedepend, automake,
etc., to build your software and they don't have it.
DrX
Nov 14 '05 #30

P: n/a
Alan Balmer wrote:
On Fri, 23 Apr 2004 13:47:40 -0400, "Xenos"
<do**********@spamhate.com> wrote:

"Nick Landsberg" <hu*****@NOSPAM.att.net> wrote in message
news:jZ********************@bgtnsc05-news.ops.worldnet.att.net...

The earliest versions of "make" only checked for
explicit dependencies as specified in the "makefile".

Thus, if a.c included a.h which included b.h *and*
b.h was not an explicit dependency in the makefile,
then a.c would not get recompiled when b.h changed.
At best, you got a compile-time error. At worst,
you got undefined behavior or a core-dump after
delivery to the customer.

Developers were usually good about finding all the
#include directives in their own code in order to
create the makefile, but hardly ever checked whether
or not there were nested includes within other files.
This /may/ have been the reason for the guidelines
noted above.

More modern versions of "make" do this checking
for you. So if you have those versions, it has been
automated already.

[SNIP first instance of signature line]

This is untrue. I know of no make tool (gnu, ms, or otherwise) that will
take it upon itself to examine your code for dependencies.

makedepend. While it may not be the same executable as make (and then
again, it may be), it's part of the same tool chain and closely
integrated, and no one actually cares what executable it's in, so long
as it does its job.


Agreed Alan,

On a project a long, long time ago, we got bit.
Started using "makedepend", but, as usual, some
developers forgot and the same problems occurred.
We found a version of "make" out of Bell-Labs
research which actually subsumed the functionality
of makedepend. It was called "nmake", I believe,
and it is still used on many a project. I believe
it is available (for a price), to folks on the
outside. So, whether it's called makedepend, or
integrated into the functionality of "make" does not
matter. As you say, as long as it does it's job

Make has no
knowledge of C will not examine #include lines, nor do a transitive closure
on them for dependency information. Some modern compilation systems with do
this type of thing (gcc with the -M option, Visual Studio, gnatmake for Ada,
etc.). But make itself will not.

DrX


--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
Nov 14 '05 #31

P: n/a
Note sure I agree with the rule. The rules we use can be found at
the link:

http://www.eventhelix.com/RealtimeMa...dePatterns.htm

The rules here are for C++ but they apply equally well to C if forward
declarations are used.

Sandeep
--
http://www.EventHelix.com/EventStudio
EventStudio 2.0 - Real-time and Embedded System Design CASE Tool
Nov 14 '05 #32

P: n/a
EventHelix.com wrote:
Note sure I agree with the rule. The rules we use can be found at
the link:

http://www.eventhelix.com/RealtimeMa...dePatterns.htm

From the above link.

| a.h:
|
| #ifndef _a_h_included_
| #define _a_h_included_
....
| #endif

Identifiers starting with "_" should not be used.
See http://oakroadsystems.com/tech/c-predef.htm
for details.

Best regards,
Robert Bachmann
--
Ro*************@rbdev.net |) |)
http://rb.rbdev.net |\.|).

Nov 14 '05 #33

P: n/a
Robert Bachmann <Ro*************@rbdev.net> wrote:
EventHelix.com wrote:
Note sure I agree with the rule. The rules we use can be found at
the link:

http://www.eventhelix.com/RealtimeMa...dePatterns.htm From the above link.

| a.h:
|
| #ifndef _a_h_included_
| #define _a_h_included_
...
| #endif Identifiers starting with "_" should not be used.
See http://oakroadsystems.com/tech/c-predef.htm
for details.


It is perfectly legal as long as the leading underscore is not
followed by an upper-case character.

--
Alex Monjushko (mo*******@hotmail.com)
Nov 14 '05 #34

P: n/a
Alex Monjushko<mo*******@hotmail.com> wrote:
Robert Bachmann <Ro*************@rbdev.net> wrote:
EventHelix.com wrote:
Note sure I agree with the rule. The rules we use can be found at
the link:

http://www.eventhelix.com/RealtimeMa...dePatterns.htm

From the above link.

| a.h:
|
| #ifndef _a_h_included_
| #define _a_h_included_
...
| #endif

Identifiers starting with "_" should not be used.
See http://oakroadsystems.com/tech/c-predef.htm
for details.


It is perfectly legal as long as the leading underscore is not
followed by an upper-case character.


It's not.

ISO/IEC 9899:1999
7.1.3 Reserved identifiers
1 [...]
- 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.

Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html
Nov 14 '05 #35

P: n/a
In <c6************@ID-190529.news.uni-berlin.de> Alex Monjushko<mo*******@hotmail.com> writes:
Robert Bachmann <Ro*************@rbdev.net> wrote:
EventHelix.com wrote:
Note sure I agree with the rule. The rules we use can be found at
the link:

http://www.eventhelix.com/RealtimeMa...dePatterns.htm

From the above link.

| a.h:
|
| #ifndef _a_h_included_
| #define _a_h_included_
...
| #endif

Identifiers starting with "_" should not be used.
See http://oakroadsystems.com/tech/c-predef.htm
for details.


It is perfectly legal as long as the leading underscore is not
followed by an upper-case character.


Is it?

- 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.

This basically limits the usage of such identifiers to block local
variables. Why bother at all?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #36

P: n/a
Mark Piffer wrote:
.... snip ...
I didn't read Pike's original statements but I guess I am exposed
to an even stricter style guide: within a client company of mine
there is the rule that every header file has to have an "PRIVATE"
section which defines (not declares!) all file-global objects.
Below there needs to be a "PUBLIC" (or EXTERN, I don't remember)
and a "COMMON" section which declare the respective "purely
extern" objects which are exported by this module (whatever that
means) and the shared objects. Yes, I am still talking C, though
the creator admits that his construct is influenced by a C++
class definition. For a clearer idea let me picture a typical
header file as it is required to be: foo.h (accompanying header
file to foo.c)

typedef int bar; // common section for all
#ifdef _PRIVATE
#undef _PRIVATE
// used inside foo.c
bar Global;
bar foo(void);
#else
// used outside of foo.c
extern bar Global;
extern bar foo(void);
#endif

foo.c has to include foo.h as the last header file, with a
preceding #define _PRIVATE

And yes, the "no include includes others"-rule is in effect too.
Aside from the bad but sometimes inevitable global variables, I
consider this style ultimately evil, but I lack the proper
verbal ammunition to sink it. Anyone who can help with a list
of unbeatable arguments against it?


Uqh. To start with, it is a complete misuse of header files,
which should be used solely to expose the appropriate portions of
the .c file.

Anything private can be made so by the simple (and defined) use of
the word 'static'. This also makes maintenance easier, because
there is no need to look for occurences outside the .c file.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #37

P: n/a
Neil Cerutti wrote:
1. Is following this guideline facile or hassle? I converted a
simple two-header program over to this style, making several
errors along the way. I clearly don't have experience
with it.


It's more of a hassle, but for a really good reason: Each time a header file
is read, disk I/O is incurred. Even if you put header guards to prevent
multiple definition, there's still disk I/O involved in reading the header
file (even if it's in the kernel's cache.)

Yes, things get complicated with forward definitions and various types of
dependencies between headers. But any acyclic graph can be reduced to a
tree.

Once upon a time, though, disk buffers were a premium, so extraneous disk
I/O really had a time cost penalty associated with it. Today, it's not so
bad. But Pike's premise is still a relatively good idea (despite Bob
Tisdale's wanks to the contrary.) If it's good enough for BSD headers, it's
probably just a really good idea.
-scooter
Nov 14 '05 #38

P: n/a
Neil Cerutti wrote:
1. Is following this guideline facile or hassle? I converted a
simple two-header program over to this style, making several
errors along the way. I clearly don't have experience
with it.


It's more of a hassle, but for a really good reason: Each time a header file
is read, disk I/O is incurred. Even if you put header guards to prevent
multiple definition, there's still disk I/O involved in reading the header
file (even if it's in the kernel's cache.)

Yes, things get complicated with forward definitions and various types of
dependencies between headers. But any acyclic graph can be reduced to a
tree.

Once upon a time, though, disk buffers were a premium, so extraneous disk
I/O really had a time cost penalty associated with it. Today, it's not so
bad. But Pike's premise is still a relatively good idea (despite Bob
Tisdale's wanks to the contrary.) If it's good enough for BSD headers, it's
probably just a really good idea.
-scooter
Nov 14 '05 #39

P: n/a
-wombat- wrote:
Neil Cerutti wrote:
1. Is following this guideline facile or hassle? I converted a
simple two-header program over to this style, making several
errors along the way. I clearly don't have experience
with it.
It's more of a hassle, but for a really good reason:
Each time a header file is read, disk I/O is incurred.
Even if you put header guards to prevent multiple definition,
there's still disk I/O involved in reading the header file
(even if it's in the kernel's cache.)


Nonsense!
A good C preprocessor remembers the names of idempotent header files
and won't even open much less read them a second time.
Yes, things get complicated with forward definitions
and various types of dependencies between headers.
But any acyclic graph can be reduced to a tree.

Once upon a time, though, disk buffers were a premium, so
extraneous disk I/O really had a time cost penalty associated with it.
Today, it's not so bad.
But Pike's premise is still a relatively good idea
(despite Bob Tisdale's wanks to the contrary.)
If it's good enough for BSD headers,
it's probably just a really good idea.
No. It's a bad idea.
Check out, for example, the GNU C preprocessor
info cpp 'Header Files' 'Once-Only'

The GNU C preprocessor is programmed to notice when a header file
uses this particular construct and handle it efficiently. If a header
file is contained entirely in a `#ifndef' conditional, then it records
that fact. If a subsequent `#include' specifies the same file, and the
macro in the `#ifndef' is already defined, then the file is entirely
skipped, without even reading it.

If your C preprocessor does not implement this optimization,
it's time to shop around for a better C compiler.

Nov 14 '05 #40

P: n/a
-wombat- wrote:
Neil Cerutti wrote:
1. Is following this guideline facile or hassle? I converted a
simple two-header program over to this style, making several
errors along the way. I clearly don't have experience
with it.
It's more of a hassle, but for a really good reason:
Each time a header file is read, disk I/O is incurred.
Even if you put header guards to prevent multiple definition,
there's still disk I/O involved in reading the header file
(even if it's in the kernel's cache.)


Nonsense!
A good C preprocessor remembers the names of idempotent header files
and won't even open much less read them a second time.
Yes, things get complicated with forward definitions
and various types of dependencies between headers.
But any acyclic graph can be reduced to a tree.

Once upon a time, though, disk buffers were a premium, so
extraneous disk I/O really had a time cost penalty associated with it.
Today, it's not so bad.
But Pike's premise is still a relatively good idea
(despite Bob Tisdale's wanks to the contrary.)
If it's good enough for BSD headers,
it's probably just a really good idea.
No. It's a bad idea.
Check out, for example, the GNU C preprocessor
info cpp 'Header Files' 'Once-Only'

The GNU C preprocessor is programmed to notice when a header file
uses this particular construct and handle it efficiently. If a header
file is contained entirely in a `#ifndef' conditional, then it records
that fact. If a subsequent `#include' specifies the same file, and the
macro in the `#ifndef' is already defined, then the file is entirely
skipped, without even reading it.

If your C preprocessor does not implement this optimization,
it's time to shop around for a better C compiler.

Nov 14 '05 #41

P: n/a
E. Robert Tisdale wrote:
-wombat- wrote:
No. It's a bad idea.
Check out, for example, the GNU C preprocessor
Not on all versions. That's a 3.x enhancement. Not all of us can u/g or use
3.x at the moment.
> info cpp 'Header Files' 'Once-Only'

The GNU C preprocessor is programmed to notice when a header file
uses this particular construct and handle it efficiently. If a header
file is contained entirely in a `#ifndef' conditional, then it records
that fact. If a subsequent `#include' specifies the same file, and the
macro in the `#ifndef' is already defined, then the file is entirely
skipped, without even reading it.


Not on gcc 2.95.4, it doesn't. :-)
If your C preprocessor does not implement this optimization,
it's time to shop around for a better C compiler.


Sometimes, Bob, we have to work with what we have, not what we wish we had.
Of course, the discussion becomes moot if headers can be precompiled and
mmap-ed into the compiler's address space (like what the Digital Mars
Compiler does.)
-scooter

Nov 14 '05 #42

P: n/a
E. Robert Tisdale wrote:
-wombat- wrote:
If your C preprocessor does not implement this optimization,
it's time to shop around for a better C compiler.


IIRC, you, of all people I've known, know the value of economy computing
best. :-)
-scooter
Nov 14 '05 #43

P: n/a
E. Robert Tisdale wrote:
-wombat- wrote:
No. It's a bad idea.
Check out, for example, the GNU C preprocessor
Not on all versions. That's a 3.x enhancement. Not all of us can u/g or use
3.x at the moment.
> info cpp 'Header Files' 'Once-Only'

The GNU C preprocessor is programmed to notice when a header file
uses this particular construct and handle it efficiently. If a header
file is contained entirely in a `#ifndef' conditional, then it records
that fact. If a subsequent `#include' specifies the same file, and the
macro in the `#ifndef' is already defined, then the file is entirely
skipped, without even reading it.


Not on gcc 2.95.4, it doesn't. :-)
If your C preprocessor does not implement this optimization,
it's time to shop around for a better C compiler.


Sometimes, Bob, we have to work with what we have, not what we wish we had.
Of course, the discussion becomes moot if headers can be precompiled and
mmap-ed into the compiler's address space (like what the Digital Mars
Compiler does.)
-scooter

Nov 14 '05 #44

P: n/a
E. Robert Tisdale wrote:
-wombat- wrote:
If your C preprocessor does not implement this optimization,
it's time to shop around for a better C compiler.


IIRC, you, of all people I've known, know the value of economy computing
best. :-)
-scooter
Nov 14 '05 #45

This discussion thread is closed

Replies have been disabled for this discussion.