>> Well, for some it poses a problem to have multiple header files, for
>> others, such as myself, it is a blessing. A recent check of my files
>> turns up 60,000 lines of code (with an additional 10,000 blank lines -
>> and I use a compressed code format - my own format of indentation which
>> reduces line count by at least half - rather than the standard that
>> CircleMUD ships in). My compiler, CodeWarrior Pro 2, also reports total
>> lines it processes for each file, and the total lines processed in a
>> compile. My average file processes 20,000 lines... and I have the
>> original "structs.h", "db.h", etc, files broken down into about 12 more
>> seperate files, half of which are included in every file. The fewer
>> header files, the more code in each file, the greater the chance that any
>> given code file will have to be recompiled if any given header file is
>> modified. Thus more files must be recompiled whenever a piece of a
>> header file is changed.
>
>This has been pointed out to be. My own code base is organized into
>structs.h, protos.h (generated automatically on demand; very useful,
>if anyone would like the simple script or makefile entry, say so), and
>externs.h. You and George are right that this does significantly
>increase the compile size; however, it simplifies the coding.
>Further, compiling a header takes a LOT less time than compiling
>normal code. They are declarations, not executable code. A 20k
>header compiles significantly faster than a 20k code file.
I don't think that was the point that was being made. The point was that
with less header files, you have to compile more of the files more often.
For example, if I wanted to add a function to handler.c to return a
character of a certain name who is wearing a helmet on their head
(get_char_with_helmet :)) I put in the prototype in handler.c and a few
files are recompiled. Not all, but a lot. If I want to add a new trap
object handling function to the MUD, I add it to traps.c, and to traps.h.
Because traps.h is only #included in maybe 5 files, I only need to
compile those 5. If all the headers were rolled into maybe 3 files, then
every time you add something to them, or change it (no matter how trivial
it is) you will probably end up compiling a lot of files that really have
nothing to do with what you just added. One released code base
(Forgotten Lands) was going in the opposite direction. Instead of just
one structs.h file, it was split down into rooms.h, character.h, and
objects.h. In this way, if you want to modify code that JUST deals with
objects, it's easier. The Death Gate Code was going the same way in the
source files, making db.scripts.c, db.object.c, etc. Also, Chris' main
point is valid, with bigger .h files, it means bigger memory requirements
PER FILE. Even if it's just a small file, like in my traps.c file, the
compiling memory requirements would go way up, even if it is just
defines, macros, and such. I know it's a matter of personal opinion, but
I'd rather have header files that are split so that the file only
references them if it NEEDS to, not because it's got everything it
absolutely need in it.
---
"One hundred years from now, none of this will matter because you and I
will be dead -- unless the Grim Reaper has switched his record-keeping to
a Windows 95-based system, in which case we all might live forever. "
-- Associated Press
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST