> I answered the question you asked which, frankly, is a poor question.
> "Can" is easy to answer and "will" is a ridiculous question.
Every large C++ project I've ever worked on has had long compilation times. It's a consequence of the design of the language. Every file in a C++ project must do the same work over and over for #include directives. A single #define could change the meaning of everything. This means that compilation times for C++ projects tend to be O(n^n), where n = number of files.
It's not a ridiculous question to ask "will my compile times be longer if I port project X to C++." The answer is almost certainly yes. Does it matter? Depends on what project X is.
C's limitations are its virtue. It enforces a consistent low-level, performance-sensitive style. Above all, C tends to encourage simplicity, the programmer's best friend.
My biggest problem with C++ is a philosophical one. It blurs the lines between high-level components and low-level ones. You often see this confusion in the minds of C++ advocates. They ask why C isn't good for implementing user interfaces, or parsing text files. The answer is that it isn't supposed to be good for those things. Those are the things that you write another component for-- a cleanly separated component that uses a nice API to talk to the rest of the system.
There is no room for C++ in this world because C++ itself is a layering violation, a hack. When performance was super-duper critical it was ok to have this layering violation. But in the coming years, performance is going to be less and less of an issue and people will move to more cleanly structured systems.