Michael Aaron Safyan has already given a very good answer. I'd like to contribute just a little bit on why object oriented languages sometimes can be associated with slower code.
Real-world demands on us programmers keep forcing us to write more code in shorter time. Given very skilled programmers, assembly language would win every speed record because the programmer codes exactly the operations the machine needs to perform, and very little else. In practice, most programming is not done in assembler because it's so tedious and error prone. Compiled languages make programmers a lot more productive because they let the compiler deal with much of the detail work.
Moving further in the same direction, Delphi works with automatic strings: They are the "right" length whenever they're used; if you concatenate two strings, a new one is produced that is the right length for the combination of the former strings. If you change that string and make it longer, a new string is created and the previous one is discarded automatically. As a C programmer, you could have anticipated what the program will do and allocated enough space for the larger string, so you would not have had to create a new one and discard the old one. So memory management for strings is a convenience for the programmer that's bought at the expense of some CPU time.
Similarly, object orientation allows you to treat groups of related data as homogenous chunks rather than strings and numbers. Sometimes not all of this information is needed, and in a low-level C program you might do without some of the operations and memory use that objects incur. It's once again a matter of programmer convenience over CPU speed.
Finally, some interfaces are considered very complicated, and software companies try to make them approachable by creating object-oriented frameworks with conceptually simpler handling. Rather than making the call to open a window, you may create a window object, usually with a bit of overhead. In a bizarre development, software companies and individual developers often build even further object-oriented frameworks to hide or handle the complexity of other frameworks. Some old projects end up with multiple layers of object oriented frameworks over top of the original functionality, and unsurprisingly, as they spend so much time managing themselves, they show poor performance to the customer while chewing up a lot of memory.
In summary, object oriented code is sometimes associated with poor performance because of how it's being used; but especially in the case of C++, there is nothing directly in the language that makes is "slow".