 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| Putting it all together: How to best arrange C source and header files |
|
 |
Sneftel Moderator - Consoles, PDAs, and Cell Phones Member since: 7/7/2001 From: Philadelphia, PA, United States |
|||
 Posted - 7/7/2001 7:36:33 PM |
||||
| This is a good introductory way to get a few advantages of multiple source files. However, it does not offer one of the biggest advantages, namely partial recompilation. Since all source files depend, indirectly, on all header files, changing a single header file will result in your entire project having to be recompiled. For example, adding a method in a class encapsulating a soundcard results in your having to rebuild your keyboard control class, regardless of whether the capabilities of the first are used in any way by the second. adding #includes for each class you plan to make use of in a source file is a bit of an extra hassle, but the implicit "indexing" it creates is worth it for any project of moderate or large size. |
||||
|
||||
 |
Anonymous Poster |
|||
 Posted - 7/9/2001 3:02:06 AM |
||||
| I do it the 'one header' way, and have found that if you make a change in this header, MSVC will only recompile source files affected by the change. I don't know if other compilers will do this though. |
||||
|
||||
|
Anonymous Poster |
|||
 Posted - 7/24/2002 10:05:32 AM |
||||
| MSVC "attempts" to recompile only the affected files, but often it gets it wrong, forgets some of them (worst case), or re-compiles things that really dont need it, but it does try. but what good is a system that you can't trust. i often need to delete all the /Debug and /Release files and recompile completely. |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 12/10/2002 10:45:14 PM |
||||
quote: Or you could just choose 'Rebuild All' from the build menu. I've only had it not recompile everything correctly a few times, it usually gets it right. |
||||
|
||||
|
Luvman79 Member since: 6/21/2001 From: USA |
|||
|
Posted - 8/21/2003 9:37:07 AM |
||||
| I just did this article for my program. I'm not to far into it and I went and compiled and I get LNK Errors all over the place. My lib files are in place and I have the program setup exactly like this article recommended. Why all the LNK errors. renderscene.obj : error LNK2005: "int screenBpp" (?screenBpp@@3HA) already defined in directinputdevices.obj g_bfullscreen@@3_NA) already defined in directinputdevices.obj directinputdevices.obj : error LNK2001: unresolved external symbol "struct IDirectInputDeviceA * m_keyboard" (?m_keyboard@@3PAUIDirectInputDeviceA@@A) Debug/Traffic Jam.exe : fatal error LNK1120: 4 unresolved externals Error executing link.exe. I don't get it. I have dxguid.lib, dinput8.lib, opengl32.lib, glu32.lib and glaux.lib. Any ideas? |
||||
|
||||
|
rioki Member since: 7/6/2006 From: Karlsruhe, Germany |
|||
|
Posted - 7/6/2006 7:30:17 AM |
||||
| Ok this article / tutorial is about 6 years old, but still hanging around and I believe that it is misleading and bad coding style. The problem is that it is "targeted at beginners" and they event learn it wrong. The general rule for creating files is, that every source file (cpp, cc, cxx, ...) has one header file (h, hpp, hh, ...). The implementation goes in the source file and the interface goes in the headers. The exception to this rule is in the case of inlining and templates, where the implementation goes in the header, but that is a deficiency of the compiler and the language. Since you are hopefully programming object oriented, there is a natural scheme for files, every class has its own header and source file. Although this can create a good number of files, it is the best for compilation, since only those parts get recompiled that need to. If you where to program C you would use a similar scheme, you would break it up in so called modules. If you are going seriously to program you should go and look at things like patterns. Global variables or even worse macros are generally bad coding style since they are not flexible, get compiled in and are static. If your really need a central instance of something, consider using a singleton. Though I must again ask you not to use singletons, since a design requiring global objects is not a good one. The key point here is the ability to exchange modules or services in your software. This makes life so much easier if you want to profile or test your application. Not to mention the ability to try out multiple solutions, even swapping them at run time. |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
