Affects of breaking code into more .h files?

Started by
2 comments, last by Frequency 18 years, 7 months ago
Hey, I'm going into my first attempt at coding Win32 - which isn't really relevant - and I've just thought that with all these messy Window/Dialog procs, it might be easier to make a whole new file for each dialog proc or maybe just group them into files. This might end up being a pretty large number of files, though, and I was wondering if this would have any negative effects or (I suspect) positive effects. With code broken into more files, Dev-Cpp/g++ (my IDE&Compiler) should recognize which files need to be recompiled and which not to, so compile times would actually be faster, right? Is the time the linker takes to put these files together negligible or would it outweigh any gain from selective compilation? Thanks! It probably won't matter much, but I'm kind of curious.
It only takes one mistake to wake up dead the next morning.
Advertisement
You're right. It matters how lazy you are for the benefit of having your build system remake everything each time. If you work with a lot of people on a large project then you will want a lot of separate files so you can each work on a part with less merging issues, but I suspect that won't feature for you.
I haven't done any large programs, but using multiple source files usually decreases compilation time somewhat (yeah, those few seconds) in my experience.
Note that in DEV-C++ you can recompile the whole thing with Ctrl+F11. Actually, I found that sometimes this was neccesary for a bugfix to work. I still don't get it.
Anyway, this article was a help to me:
Organizing code files in c and c++
Ahh, I see. Thank you both very much. Seems like it will be just fine and dandy to use lots of files. :) After reading that article, though, I think maybe I should be renaming some of my .h's to .cpp's...oops.
It only takes one mistake to wake up dead the next morning.

This topic is closed to new replies.

Advertisement