--- Tom St Denis <tstdenis@xxxxxxxxxxxxxxxx> wrote: > Duft Markus wrote: > > Hi! > > > > I assume, that all strategies discussed here are > targeted at C. now what > > about C++, how do things behave there? As far as i > know C++ is much > > different, and requires completely different > thinking with regards to > > splitting source in more files, etc. > > > > I don't know enough about C++ linking but there is > no reason you can't > put methods in seperate .C files. The problem is > most C++ developers > want to inline all of their methods and put quite a > bit of actual code > in their .H files instead, which is just a > maintenance nightmare. > Well, that MAY be true of kids still wet behind the ears, but it isn't true of experienced C++ developers I know. I prefer C++ for high performance code: in fact my best C++ code is faster than my best fortran code, but that is another story. I routinely split my C++ classes across multiple compilation units, sometimes to the point of one function per compilation unit. But sometimes there are a handful of member functions that are sufficiently closely related to warrant placing them in the same compilation unit. I put only that code in a header file that could rationally be inlined. There are, in fact, a handful of best practices that have developed over the years regarding helping the compiler determine which functions to consider inlining. The only exception to this is how we need to handle template classes. I deal with this, though, by keeping my template classes as small as practicable (and perhaps using a small family of related template classes rather than a single catchall). My experience, though, is that once you start working with template classes, especially with state of the art template metaprogramming, compilation times increase dramatically anyway, so you just bite the bullet and deal with it. But this gets into an area where I wouldn't hand the task to a junior developer anyway. They just don't have the experience needed to do it well. I'd instead want to spend some time giving them on-the-job training for a few years, before letting them run with a template metaprogramming task (I know of a few college programs where C++ programmers aren't given so much as 5 minutes on generic programming, so the inability of most junior C++ programmers to understand it isn't a surprise). > The benefits of code factoring are hardly limited to > C or C++. They > equally apply to Java applications (with the sad > exception, hehehe, that > your class has to be in one file, but you can > refactor into smaller > classes, etc), pascal, assembler, etc. > Yeh, but it is a mistake to implement high performance code in Java anyway, so neither compilation speed or runtime performance is a major factor in choosing to use it (rather, in my experience, it is the ease of use and time to complete the coding for certain types of application). While it has improved over the years, it still doesn't come close to C++ or fortran. Where Java has the edge is the ease with which distributed programming can be done, and this is because of the wealth of libraries supplied in the J2SE and J2EE SDKs. I generally agree with the rest of what you said. Anyone who has been doing this a while, and learned from that experience, will be using version control, well factored compilation units (thought about rather than just mindlessly munging things together or dividing them), &c. Dividing a class into multiple compilation units gets you only so far. If one of your edits requires a change to the header file containing the class declaration, then all the files depending on it must be recompiled also, even though you didn't touch them. You have to think about how to distribute your code, not just put it all into a single file or distribute among countless files. Both ideas, mindlessly applied, are bound to get you into trouble with a hard to maintain project. Cheers, Ted
