1. I've only dabbled with Poco, and that was some number years ago. It's always desireable to split an application into smaller chuncks, but how you do it varies.
If the data that the parts used can be passed as complete parameters to seperate programs, then that's fine, but it's often not the case. Often, code is moved into shared libraries that can be loaded and unloaded at runtime. That would achieve your goal of reduced a footprint, but the cost is increased complexity for you to manage these pieces.
Anyway, let me go thru your points.
|should I split it into different scripts and call them inside the main with system calls and passing arguments with argv[x]?|
That way, it becomes easier to share classes and only load the one necessary.
If you can get away with doing that, you should. It sorts of begs the question, why were they part of one app to begin with.
|But, is it safe ? Is this approach efficient, fast and reduce memory footprint ?|
You'd have a smaller footprint, but each program would still pull in the framework, runtime libs, ... it may not be much smaller; and if the libs can't be shared, you'll end up with something bigger.
|My concern is that we will improve it a lot so many compilations ahead.|
Have you heard of Make?
|I thought that a code that doesn't need to be recompiled with the rest would execute this task faster.|
There's no such relationship.
|One big file might be a urge for us. Or is there any ability to build parts of a code only leaving untouched the others ?|
You obviously haven't heard of Make.
|In php, you can create a new instance of a class with "new" operator...|
Maybe you should learn the basics of C++ and get your head around its philosophy. You can't dabble in C++, you have to understand the basics. It's a low-level language designed to let you control the machine in some detail; it gives you power, but in return you must exercise control and you can't do that if you have no idea what the language is.