M
Malcolm McLean
I don't even use makefiles any more. Just gcc *.c -lm.cr88192 said:
A
Al Balmer
I'm well aware of who Rob Pike is
The notes you reference werewritten in disagreement of practices espoused by Brian Kernighan and
P. J. Plauger. (I suppose you know who they are?)
While I respect Mr. Pike and the contributions he's made, IMO he's all
wet on this issue. He apparently expects that the programmer read
every header before using it, or at least inspects it for comments
specifying its prerequisites. The only benefit he offers is saving
work for the compiler. Perhaps compilers have gotten better since
1989, but I don't find that a compelling reason to make such a mess.
R
Richard Tobin
Al Balmer said:
While I don't use this style myself, it makes slightly more sense if
headers correspond directly to libraries. On most systems you're
going to have to find out what the header/library uses anyway, so that
you can specify it to the linker.
-- Richard
F
fnegroni
So why is it that a standard header never includes another standard
header?
Why should mylib.h, a third party file which I should not have to
modify, include <stdio.h> just because it uses FILE ?
Surely I can supply my own header which defines a compatible but
otherwise different implementation of FILE * that satisfies the
requirements of mylib (and mylib.h). Why should mylib.h override my
definition of FILE ?
A
Al Balmer
If you worked here, I would give you a very practical reason. Your
code would be rejected at review, and you would be told to fix it and
not do something like that again.
M
Malcolm McLean
Version one of mylib.h does no IO. Someone decides to provide load / savesfnegroni said:
for version 2, and the functions take FILE * parameters. So your code could
easily break.
If you start defining your own FILE type I suggest we are very rapidly going
into the woods. However the whole dependency problem is very difficult.
We expect savecomplex() and loadcomplex() to be in complex.h. On the other
hand, we expect the complex routines to be independent of the IO we use.
F
Flash Gordon
cr88192 wrote, On 29/01/08 01:14:
I've seen this happen. The larger the application and the longer it is
under maintenance the more likely it is that the person who finds the
bug will not know the code has been duplicated.
<shrug> I have had to go back to code years after the last time anyone
looked at it. There is also a good chance that I was not the original
author, or if I was the author there is a good chance someone else will
have to look at it (I wrote code in the 80s that I heard in the late 90s
was planned to be in use for more than another decade, and I've since
left the company).
I use tools and documentation to manage dependancies and don't find it a
problem.
Well, I've not had to work on projects that size, so perhaps the balance
changes.
Well, since this was talking about whether to split the code out in to a
separate library or not I don't believe people were talking about 3rd
party libraries.
I would have said that splitting it apart in to libraries makes that easier.
If the library is only 10kloc and depends on another library which is
5kloc then that is only 15kloc you have to consider. You might still
decide to extract the code from the original library if you only want a
small subset of it, and I don't see how having it as a library would
make it any harder than finding all the correct parts from amongst 10kloc.
Or use tools to identify what parts depend on it.
Ah, so you assume that if your 100kloc is not split in to libraries then
people will remember all of it (you say above "theoretically we have
enough brains to know just what the hell we wrote..."), but if it is
they won't remember it and won't read the documentation.
Since the earlier talk was about whether to split a library in to
separate libraries this is a bogus argument. If you have not split it
then you have to port one library with all the code to each port of
interest, if you have then you have to port the same amount of code
except it is in two libraries. The only difference is that for another
reason you might already have ported some of it.
I've seen this happen. The larger the application and the longer it is
under maintenance the more likely it is that the person who finds the
bug will not know the code has been duplicated.
<shrug> I have had to go back to code years after the last time anyone
looked at it. There is also a good chance that I was not the original
author, or if I was the author there is a good chance someone else will
have to look at it (I wrote code in the 80s that I heard in the late 90s
was planned to be in use for more than another decade, and I've since
left the company).
I use tools and documentation to manage dependancies and don't find it a
problem.
Well, I've not had to work on projects that size, so perhaps the balance
changes.
Well, since this was talking about whether to split the code out in to a
separate library or not I don't believe people were talking about 3rd
party libraries.
I would have said that splitting it apart in to libraries makes that easier.
If the library is only 10kloc and depends on another library which is
5kloc then that is only 15kloc you have to consider. You might still
decide to extract the code from the original library if you only want a
small subset of it, and I don't see how having it as a library would
make it any harder than finding all the correct parts from amongst 10kloc.
Or use tools to identify what parts depend on it.
Ah, so you assume that if your 100kloc is not split in to libraries then
people will remember all of it (you say above "theoretically we have
enough brains to know just what the hell we wrote..."), but if it is
they won't remember it and won't read the documentation.
Since the earlier talk was about whether to split a library in to
separate libraries this is a bogus argument. If you have not split it
then you have to port one library with all the code to each port of
interest, if you have then you have to port the same amount of code
except it is in two libraries. The only difference is that for another
reason you might already have ported some of it.
R
Richard Tobin
fnegroni said:
Not in standard C you can't.
If you're not concerned about sticking to the letter of standard C,
you can almost certianly arrange for mylib.h's #include <stdio.h>
to get your version.
-- Richard
F
fnegroni
Sure.
Next?
I
Ian Collins
Malcolm said:
Indeed, imagine the arse ache if mylib.h is included in scores or even
hundreds of files, all of which have to be updated...
A
Al Balmer
There wouldn't be a next ;-)
J
John Bode
[snippage]
I will *happily* trade longer build times for less work. *Happily*.
First of all, in practice, whatever time this adds to a build is not
that big a deal. IME, it's the link phase that's the most time-
consuming aspect of a build, not lexical analysis. Secondly, making
the header files idempotent eliminates stupid errors like not
including files in the right order (or forgetting to include a file
altogether).
I won't deny this was issue in 1989 (I worked on one Encore mini where
it took on the order of 6 hours to rebuild the world, although that
was Ada, not C), but I like to think we've made *some* progress over
the last couple of decades.
I will *happily* trade longer build times for less work. *Happily*.
First of all, in practice, whatever time this adds to a build is not
that big a deal. IME, it's the link phase that's the most time-
consuming aspect of a build, not lexical analysis. Secondly, making
the header files idempotent eliminates stupid errors like not
including files in the right order (or forgetting to include a file
altogether).
I won't deny this was issue in 1989 (I worked on one Encore mini where
it took on the order of 6 hours to rebuild the world, although that
was Ada, not C), but I like to think we've made *some* progress over
the last couple of decades.
R
Richard Tobin
fnegroni said:
Er no. This might have been true 25 years ago, but it isn't now.
To achieve good code on modern processors requires a lot of work.
Please show me this "good compiler" where lexical analysis is the
a significant proportion of the compile time. (Hint: if it's true,
the compiler will be blindingly fast.)
-- Richard
F
fnegroni
Indeed, imagine the arse ache if mylib.h is included in scores or even
And you would do that manually? Ever heard of sed?
This is a recurring issue even with header files that include other
header files, where your code compiled even if you forgot to include a
file yourself, cause it was included by some other include, and no
warning was flagged up, and then that include file changed, no longer
including the include file you thought you did.
Anyway, it is a matter of opinion, since the standard does not impose
a rule on us, and it is part of what people call "coding practice".
Which is just a custom.
Considering how many wars have been started debating the merits/
demerits of curly bracket positioning and tab alignment or spaces, I
think C programmers tend to believe there is only one way of doing
things, and never move on.
If that was the case, many programs we all know (e.g. linux) would not
exist since they explicitly use some extension of the gcc compiler to
achieve their goals.
I am not posting here to tell *you* what to do (unlike some of you
telling *me* what to do. Heck, if you still are doing code reviews, it
is time to move on in your career).
I am just saying there are people who beg to differ in their opinion,
and those opinions have their merits.
You disagree with me, fine. Just don't tell me to shut up or get a job
somewhere else, because that just sounds to me like you just need a
fix.
And you would do that manually? Ever heard of sed?
This is a recurring issue even with header files that include other
header files, where your code compiled even if you forgot to include a
file yourself, cause it was included by some other include, and no
warning was flagged up, and then that include file changed, no longer
including the include file you thought you did.
Anyway, it is a matter of opinion, since the standard does not impose
a rule on us, and it is part of what people call "coding practice".
Which is just a custom.
Considering how many wars have been started debating the merits/
demerits of curly bracket positioning and tab alignment or spaces, I
think C programmers tend to believe there is only one way of doing
things, and never move on.
If that was the case, many programs we all know (e.g. linux) would not
exist since they explicitly use some extension of the gcc compiler to
achieve their goals.
I am not posting here to tell *you* what to do (unlike some of you
telling *me* what to do. Heck, if you still are doing code reviews, it
is time to move on in your career).
I am just saying there are people who beg to differ in their opinion,
and those opinions have their merits.
You disagree with me, fine. Just don't tell me to shut up or get a job
somewhere else, because that just sounds to me like you just need a
fix.
F
fnegroni
Building our product on a mere quad core xeon with 4GB ram only takes
a mere 2 hours.
But then we compile our code on 26 platforms, some are even slower...
F
fnegroni
BTW, 2 hours if using incremental linking and ccache.
I
Ian Collins
*Please* don't quote signatures.
It's still a pain in the arse compared with updating one file.
People tend to disagree with you because your arguments are based on
decades old issues which have little relevance to contemporary tools and
machines. For example, with many compiles, including all of your
headers in one "umbrella" header will speed up compilation significantly
through the use of precompiled headers.
I didn't, I don't care one way or the other, if a client works one way
I'll do as they ask. But if you are going to argue based on anything
other than personal opinion, at least argue valid points.
It's still a pain in the arse compared with updating one file.
People tend to disagree with you because your arguments are based on
decades old issues which have little relevance to contemporary tools and
machines. For example, with many compiles, including all of your
headers in one "umbrella" header will speed up compilation significantly
through the use of precompiled headers.
I didn't, I don't care one way or the other, if a client works one way
I'll do as they ask. But if you are going to argue based on anything
other than personal opinion, at least argue valid points.
D
David Tiktin
I don't agree with the no-including-headers-in-headers view, but
this is a good question which I don't see has been answered. It has
always seemed odd to me that, for instance, NULL is defined in more
than one standard header file. Why wasn't it put in, say, stddef.h
with stddef.h then #included in stdio.h, stdlib.h, etc.? (It seems
to violate the DRY principle, which is something *I* never do ;-)
I'll bet this is covered in P.J. Plauger's Standard C Library, but
my copy is at home. Is it just a historical artifact? Anyone care
to explain?
Dave
R
Richard Tobin
fnegroni said:
And most of this is lexical analysis, right?
-- Richard
F
Flash Gordon
David Tiktin wrote, On 29/01/08 23:58:
Where I have looked at system headers they include other (often private)
headers. The standard does not say that a system header cannot include
another header, it says that it must behave as if it does not include
any of the other headers defined by the standard.
Where I have looked at system headers they include other (often private)
headers. The standard does not say that a system header cannot include
another header, it says that it must behave as if it does not include
any of the other headers defined by the standard.