One header for multiple cpp-files
I've read this, and think I understand the problems that may arise later. However, despite all this I believe my problem might be a special case and I'm wondering if anyone has a DIFFERENT suggestion.
I've been working on a server and client for a long time, and what was originally supposed to be the all-encompassing "CommandManager" class has become a terrible monster. It was designed to intercept the messages received from possibly hundreds of clients, parse it out, figure out what the command is, and send it to the required function in the right class.
This is done by filtering out the message after decoding the header, then by matching the "plain text" command received to an std::map pre-loaded with all the commands.
This means for every different command I implement, I need a matching member function. This worked out fine originally.. but now I'm at over 100 commands, and I'm not even close to done. I'm reaching 4,000 lines of code in the .cpp file, and I'm starting to have issues keeping track of it all. Despite having decent naming standards, it's becoming a catch-all for a lot of code that I would have preferred to spread out.
I still consider myself a big novice in programming in general and C++.
Has anyone else ran into these problems in the past while designing a large project, and what have they done to fix these issues?
(...) what was originally supposed to be the all-encompassing "CommandManager" class has become a terrible monster.
This often happens with so-called "manager" classes. From experience, I'd say the word "manager" alone typically suggests that you are unsure what the exact purpose of the class is, eventually allowing the class to evolve into what you are describing here.
This worked out fine originally.. but now I'm at over 100 commands, and I'm not even close to done. I'm reaching 4,000 lines of code in the .cpp file, and I'm starting to have issues keeping track of it all.
Sounds quite bad.
Has anyone else ran into this problems in the past while designing a large project,
Yes, everyone. It's a very common problem. And although everyone has experienced the problem before, the sad truth is that most developers out there would not recognise it as a problem. Which means that you are no longer a "big novice in programming" but have already made an important step forward.
and what have they done to fix these issues?
Redesign the program, splitting the big class into smaller classes with more specialised functionality.
The fact that all of the complexity now lives in one file is just a symptom for the real problem, and that real problem is the existence of a monolithic class. Technically, C++ places no restrictions on how many function definitions should go into a single translation unit (read: "into a single *.cpp file"). But I think in your case splitting the implementation into multiple files does not really solving anything but will only add to the complexity. YMMV.
Note that the C++ standard does have an annex about implementation quantities, but it's an informative one. It's Annex B, and it says:
Because computers are finite, C++ implementations are inevitably limited in the size of the programs they can successfully process.
(...)
The bracketed number following each quantity is recommended as the minimum for that quantity. However, these quantities are only guidelines and do not determine compliance.
The one interesting guideline for you would be:
Members declared in a single class [4 096].
So, as you can see, you are still far from hitting the number of members where things could become critical. You have a style, or program-design problem, not a hard technical one.