One of the mantras of C++ design was "you don't pay for what you don't use".
If you're not using polymorphism or exceptions then C++ will use no more memory and generate no more code than C.
And ... even without those things you still gain an awful lot: eg. Objects make code a lot cleaner and easier to re-use.
If you're not using classes, it's a dialect of C, not C++. Once you start using classes, every object drags with it a table of pointers to all the methods, public and private. If you inherit from a base class, you have a table of pointers to a table of pointers in the base class. I watched a bunch of UI programmers merrily design objects with 4 & 5 antecedent classes even though there was no need for it. "Design Patterns" had just come out and they were hot to be using the latest jargon. Aside from the increased memory footprint, that's a lot of constructors which have to be run to instantiate an object.
I warned them at the start of the project (I was strictly doing scientific codes) to keep an eye on their linker dependencies by way of a page from "Large-Scale C++ Program Design" by John Lakos posted on my door. This was ignored until the compile times became intolerable and they had to stop work while they refactored the mess they had made. I was quite startled when one of them pulled a copy of that page out of his desk. He *had* paid attention.
I've seen a good bit of "C++" which was actually just C with C++ semantics. In that case the compiler may or may not generate the same code. It depends upon whether the code touches an edge case where the two languages differ.
This is the reason for the staggering code bloat. The Vivado FPGA suite from Xilinx is a 20 GB download! Firefox has a runtime memory footprint of over a GB.
A well designed and documented library in any language is easy to reuse. C++ requires that you include all the antecedent libraries even if the particular object you are using doesn't reference them. An old FORTRAN code has the minimum possible dependencies as is also the case for assembly and C.
In case it's not obvious, I am what Fred Brooks described as a language lawyer. Not only will I tell you that section 8.3.5 says that upon return from a function or subroutine named common may be undefined, I'll also explain that that behavior was included to allow FORTRAN 77 to run on the Burroughs 5000 which was the first stack based machine. It also was a tagged architecture machine. Every word in memory had a a set of bits that recorded the type of the value stored at that location. I'm not aware of any other hardware that implemented that feature though I've read a great many expositions of the virtues of a tagged architecture.