Hello, Somebody here insists that all the program's definitions will be stored in one large header file that all C modules include, rather that keeping the declarations distributed among specific header files. That sounds pretty crappy to me - but how bad it is really? will it have a very negative impact on build time?
I think that's not true:
It takes skill & care to make something beautiful; I think it's far more likely that something which has been made with such skill & care will be stable than something that hasn't.
Or maybe it was about women...
A while ago I thought about putting up my own little poster:
"You're a thinker, not a doer"
Why?
One weekend a couple of years ago I though I'd save some money by buying a hedge trimmer and tidy the hedges around our garden myself.
Big mistake ... I managed to get a very numb arm from swinging the trimmer up high and down low for a long period.
So I went to the doctor, explained what I had done and he responded (without even looking at my arm):
"It's rubbing nerves. The trouble is that you haven't realised that you're a thinker and not a doer".
Really didn't know whether to take it as a compliment or an insult.
Anyway ... I don't think I'll try to save money in that way again.
Anyone want to buy a hedge trimmer? - It's only been used once!
Today, who cares if a build takes 3 or 5 seconds.
this is true. but it can make a lot of difference in a debugging session, that requires some fine tunning. I think the difference in build time, in a large project, will be much more than 2 seconds...
I have never seen more than 5 seconds for a ~48k project
Erik
Fine, but some products have dependencies other than pure C: header files might have to be parsed for other external tools for intermediate processing, and some products can consist of multiple components (i.e. binaries) that depend on one another...
and in either case you ca nuse one header file or multiple.
In my opinion one or mutiple header files is a matter of shop standards (hopefully not just personal preference), either has (dis)advantages. Either will work if properly implemented.
Either will work, but the big one means that any change to the header file will always force a full rebuild. If you have a couple of hundred source files, and are building with full optimization, you are likely to have to wait far longer than 5 seconds.
Why have a header file at all? Just put it all in one a single C file! Issue solved!
What issue? Everything in a single C file will still leave the issue (but this time worse) that any little change results in a full rebuild.
Yes, but you only have to rebuild 1 file!
only have to rebuild 1 file
That use of the word "only" is misleading, because you've changed the meaning of "1 file". The only thing even more unwieldy than a project glued into a single contiguous lump of code by a common header file, is a project glued into an less structured, solid heap of code in a single file.
I hope no one actually thought I was serious. It would be a terrible mistake to put all the C code into 1 file. At the same time it would be a terrible mistake to put all the header information into 1 file.
I will spend most of my time working on "follow on projects" and not the project I am currently working on. I need generic pieces of code from this project that I can use on the next project. Pick and choose the pieces that I need. I don't want a GLOB of an .h file that I need to cut and recompile and hope I haven't either left something in that I don't want or taken something out that I do need. (And the GLOB of a C file is not less horrendous). SO, unless this is the last project you will ever do, don't even consider putting all of you header information into a single file. If it is your last project ever, congratulations and who cares how much trouble the next guys has, its his problem.
View all questions in Keil forum