# [C++] File organisation, every function in one file?

This topic is 2634 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I'm following a course on C++ at the moment. Being an experienced (though not advanced) C++ programmer, the first part(s) aren't too interesting. But I still follow them, I can only get _more_ experienced, even with simple stuff.

On some of his remarks on my homework I don't fully agree though. Those are mostly style remarks and don't really interest me. He's also a bit of an "old one", loves (old distro of) Linux, despises IDE's, strongly advices against debuggers, etc. There is nothing against those opinions / uses of course, though I don't mind the help of some 'modern' habits.

However, one of his obligations is that each and every function should be defined in a new file. The declarations of several functions would go together into one header file where you have a header file for external use, and an internal header for internal use only, which may contain 'using' etc...not 100% sure how this is meant though. All the definitions would have one separate file. This also applies to member functions. A whole class or bundle of functions would reside in one directory.

So for the following class:
class Object{public:    Object();    void a();    void b();    void c();};

You'd have the following directory listing:
object/  - object.h  - object.ih  - object.cc  - a.cc  - b.cc  - c.cc

Overloaded functions would have an underscore and a unique number appending the file name.

His reasons were that the code would be a) maintainable (as opposed to _not_ maintainable) and b) would reduce the size of the executable.

a) Can be true, beside the enormous amount of files you'll get for any reasonable library, some functions might just be a few lines...and I find one file per class (one .hpp and one .cpp) very maintainable actually.

b) Only applied to me when compiling to a static library and not just object files. It saved me a few hundred bytes on a ~450 kB executable. Besides, I don't find the size too interesting...as long as it doesn't get really big of course.

What are your thoughts on this matter? I value the pragmatic experts on this forum highly and countlessly read that programming teachers aren't always experts...

##### Share on other sites
Putting one method definition per file is definitely not maintainable, and I'm really curious what sort of logic could produce such an assumption. Roughly speaking, a class should consist of code suited for one purpose, which implies that the methods for that class should also be, in aggregate, suited for that single purpose. There's no point in splitting them out, because if you are making tweaks to how an object is handling that purpose, then you are interested in the entire set of functionality around that purpose. Splitting a single class's functionality across several files just means you have to open each of them to change that functionality.

##### Share on other sites
Quote:
 Original post by DecriusHowever, one of his obligations is that each and every function should be defined in a new file.

It's a throwback to mainframe programming, when poor versioning systems and editors, inconvenient and slow compilation, and prevailing documentation processes made it useful.

Quote:
 His reasons were that the code would be a) maintainable (as opposed to _not_ maintainable)
"Maintainable" is a very hand-wavy word. You should only wear red hats -- they're more maintainable. Sorry, I can't come to the meeting today, it just wouldn't be maintainable. But if you hated IDEs, then yes, it would probably be easier to have everything in its own file.

Quote:
 and b) would reduce the size of the executable.
I suppose that putting them in different files could disallow inlining. Turning off inlining would accomplish the same thing. In both cases, the practice can have the most remarkable effects on your execution speed. Incidentally, though, it could also make your executables a lot bigger, by forcing greater repetition of static objects.

Quote:
 What are your thoughts on this matter? I value the pragmatic experts on this forum highly and countlessly read that programming teachers aren't always experts...
Your teacher's strictions are based on the context of a kind of programming that is not practiced by modern professional programmers. Consider with a critical eye how widely applicable they are in other contexts.

##### Share on other sites
It's not maintainable, it increases the number of files you need to open/modify to make nontrivial changes to an interface. I can see an argument for it being easier to browse code organized like this if you don't use a modern IDE, but that in itself is folly. As is, I suspect, his "advice" regarding not using a debugger. If you cannot, that's one thing, if you choose to eschew modern useful tools, that's your own (or his, in this case) problem.

The link process tends to be linear on the number of input files, too, so by creating this many translation units you're going to be seriously bloating your link times.

Also, if your compile cannot do link-time code generation, splitting up TUs like this might actually increase executable size, since less code will be inlined. It will do nothing to reduce executable size, so it's not a win there. The size differential you saw in your trials could be attributed to a number of things.

Basically, his justifications are all either factually wrong or subjectively off-base and lost in the realm of archaic thought processes. They are patently irrelevant to modern software design, so consider the rest of what issues from his lectures with that in mind.

One header/source pair per class/interface/unit of functionality is a far more sane, common approach. That said, if he's going to take points off your assignments, do what he wants.

##### Share on other sites
Jpetrie said everything I came in here to sya

##### Share on other sites
Quote:
 I'm following a course on C++ at the moment.

I guess it would be useful to know where to find the course. Just to point someone to this thread if he/she suggests taking that course.

Quote:
 countlessly read that programming teachers aren't always experts...

Long live self-teaching. :)
Btw, it's logical that teachers aren't experts - they might (and usually do) lack real life coding (or teaching) experience in an environment/situations that we have today.

##### Share on other sites
Great responses, thanks.

I think his reasons behind the executable size argument is that the linker would skip out any unused object files and wouldn't be able to leave out a specific function from an object file.

I'll just do as he says during the course but try to verify the habits with the more pragmatic approaches and there upon decide what to keep and what to lose.

Quote:
 Original post by snake5I guess it would be useful to know where to find the course. Just to point someone to this thread if he/she suggests taking that course.

I don't prefer to besmirch people openly on the internet, but it's not far from my location as stated in my profile ^^

Quote:
 Btw, it's logical that teachers aren't experts - they might (and usually do) lack real life coding (or teaching) experience in an environment/situations that we have today.

Well, he's been teaching for years and wrote two books. I don't consider him incapable...he's just a more theoretical programmer (it's at the university after all) with (probably) a fixed community of uniform views he is active at...

##### Share on other sites
Quote:
Original post by snake5
Quote:
 I'm following a course on C++ at the moment.

I guess it would be useful to know where to find the course. Just to point someone to this thread if he/she suggests taking that course.

Agreed.

If this is an accredited school, you might also want to TACTFULLY discuss it with administrators. Telling students to follow practices that applied to other old languages from the '60s, not following practices that have been industry standard for 30 years, and blatantly misguiding student by "strongly [advising] against debuggers" is simply not acceptable in that environment. It is very important for instructors to provide correct, accurate, current information. If the instructor is giving incorrect or outdated guidance the institution needs to take corrective action.

##### Share on other sites
Quote:
 I think his reasons behind the executable size argument is that the linker would skip out any unused object files and wouldn't be able to leave out a specific function from an object file.

Linker skips functions, not just object files anyway. :) At least, any modern linker written for the more often used platforms.
Think of object files as pieces of the same code you have in your source files, just in a different language and format.

##### Share on other sites
Hmm, let me see if I can do the math. I think there is a guideline that functions should not be too long, so lets say max 100 lines of code for each function. With a 100k loc project that is roughly 1000 to 2000 files. And since we don't use any form of IDE with right click -> find declaration(/implementation) we open all those 1500 files up at once in - say notepad.

Yeah, that seems practicable.

Quote:
 Long live self-teaching

Agreed

##### Share on other sites
Haha "strongly advise against IDE and debuggers"? Wow. He may have a point for students that are just learning. Maybe. For anything beyond toy programs that quickly becomes non-viable. When you get to 100k+ lines you not only need IDE/debuggers, but code analysis tools as well.

A coworker once told me about a job he had back in the early 90's where it was straight C and the company insisted on 1 function per file. He still complains about it to this day ...

Quote:
 Original post by Ohforf sakeI think there is a guideline that functions should not be too long, so lets say max 100 lines of code for each function.

In addition to line limits many projects will also enforce a cyclomatic complexity limit per function:

http://en.wikipedia.org/wiki/Cyclomatic_complexity

Which is reasonable since the more control statements in a single function, the more complex it is to read, understand, and debug. If you put a hard limit on cyclomatic complexity it forces you to modularize everything. Here's an example of a coding standard used by ATT, Lockheed and a few other companies, that dictates a function size and cyclomatic complexity limits:

http://www2.research.att.com/~bs/JSF-AV-rules.pdf

I worked on a project that used those guidelines and it is literally impossible to enforce those without an IDE and static analysis tools.

[Edited by - EJH on October 1, 2010 6:51:41 PM]

##### Share on other sites

This topic is 2634 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.