Thread: Curiosity: including .cpp files

Originally Posted by ChaosEngine

(i.e. manutd belief that templates don't require an entire book)

Hehe

Originally Posted by Mr_Miguel

I'd still have to separate prototypes from implementations.

Believe it or not, that's a good thing. It's a place where all function headers are grouped together, so if I need to look up how to call a function, I can do it there. With no source code to get in my way. (I use Java a lot. I know from experience how annoying source code is.)
And don't tell me to use a reference for that. Typically, this is my own code, and it doesn't have any reference beyond well-commented code.

I hate separating prototypes from functions.

You better learn appreciating it.

Have you ever imagined a project where you'd have 7 files, each requiring prototypes? You'd need 7 extra files, just for the prototypes! I don't know about you, but in my opinion, it looks ugly.

I have written projects that had 30 headers or more, for that many source files. And I consider those projects small to medium-sized. I think it looks neat.

@ChaosEngine:

My approach isn't necessarily wrong. It works as long as I keep track of function duplicates. Driving on the wrong side of the road is way dangerous than driving on the right one (I do have a driver's license, by the way), but doing this the way I did isn't necessarily dangerous. Then again, it may bite me like you said, but I guess I'll have to find out for myself. When something feels right to me, I can't just take it out of my head.

@CornedBee:

If you ask me, the reason why I like my approach better is because I learned Java before I got myself into C++. However, I strongly prefer C++ to Java, many reasons involved in my preference which I shall not disclose. Learning Java before C++ might be behind the reason why I like grouping source code with prototypes. And besides, I always keep prototypes at the top, so it isn't a problem at all if I need some kind of reference. You also said you THINK it looks neat with all of those 30 headers of yours. The keyword here is THINK. It is a matter of opinion once again.

@All who participated in this topic:

There is no need for further posts. I asked a question, you gave me your answers. I got your points, despite the fact that I don't exactly feel the same way. I say it again: if I have to pay the price of separating prototypes from implementations, so be it. At least now I know why people tell beginners and the like that they should only include header files, which means something good came out of all of this. Thank you all for your participation. Over and out.

Originally Posted by 7stud

Then I declare jihaad against you. You must die.

ROFL!!!

Originally Posted by Mr_Miguel

Have you ever imagined a project where you'd have 7 files, each requiring prototypes? You'd need 7 extra files, just for the prototypes! I don't know about you, but in my opinion, it looks ugly.

Some of my projects have well over 50 .cpp and 50 .h files I usually put no more than one major class per .h/.cpp file (I'll put helper classes that are used only in conjunction with the main class, though).

It actually really helps readability in my opinion. If I want to know the interface of my class, I can look at the .h and see everything very quickly; if I am want to look at implementation, I have the .cpp.

Most of the time when I code I have one .cpp file open and many .h files, as I am coding one section and referring back to the public interfaces of my other classes.

Breaking apart the interface and implementation can actually give a very large compile-time boost, too, especially on large projects. A change to a .CPP file (implementation) typically means only that .cpp needs to be recompiled, where a change in the .h means everything that includes that header must be recompiled.