It is not "entirely up to you" unless you're the only person on your project, or unless you're empowered to behead infidels on your team.
Unfortunately, that's exactly the argument I've heard from every C++ evangelist on every project I've ever seen converted to C++. Six months later, the project compile time has gone from 30 seconds to half an hour, the number of lines of code in the project has gone up by an order of magnitude, and the codebase is almost functionally back to where it was when the project was converted from C.
There's nothing intrinsically wrong with C++ when it's used properly. The problem is that all the features that C++ adds to C encourage abuse, and it's hard to find programmers with self control.
On one game console (PS2) project I worked on, for example, the system was converted to C++ partway through the life of the project. One of the guys decided that it would be an excellent idea to wrap the whole project in a class, so he could create an instance of the game and stick all the init code in the constructor. And of course, it had to be a singleton class, so it had extra frippery in it to conform to the design pattern.
It didn't change the functionality at all, it just added crud to the code and the runtime to satisfy someone's broken idea of elegance.
On the same project, we needed to take debug input from the keyboard. There was a small API for that; it should have (and later was) just a matter of calling that API with a little custom command shell. The first crack at it, though, was taken by another of our C++ guys, who decided that the *real* problem was that we needed a key input-handling class hierarchy with templating and several levels of inheritance before we finally got down to a singleton class wrapping the API. I presume if we'd let him continue he'd have given similar treatment to the command shell. Instead, I ripped out (IIRC) 6 files and more than 50K lines of code (before template expansion) and replaced it with about 20 lines of functionally equivalent C.
Even in the hands of good programmers, C++ has nonobvious costs. One of the biggest performance problems on modern hardware is memory access speed; the more you can keep things operating out of cache, the faster things go. C++ template programming and STL encourage a programming style that ignores this. STL in particular is egregious for performance costs due to cache thrashing.
The problem is, someone will go and write a pair of simple programs, one of which does a string sort in C, and one of which does the equivalent in STL. The two will run at about the same speed, if the programmer is competent and honest. The erroneous conclusion that gets drawn from this is that the two have identical performance characteristics.
The C++ program will be larger, and will eat more cache. In a toy benchmark program that isn't particularly noticeable, but once you've scaled up to the size and functionality of a full program it becomes a serious performance hit. Cache thrashing kills you. Making things worse, the problem will likely have metastasized to the point where it's not even obvious what happened. The interwoven class hierarchy and (usually) STL dependency of the project makes it impossible to even contemplate simplifying.