Are there any aspects to the C++ programming language where the code is known to be slower than the equivalent C language? Obviously this would be excluding the OO features like virtual functions and vtable features etc.
I am wondering whether, when you are programming in a latency-critical area (and you aren't worried about OO features) whether you could stick with basic C++ or would C be better?
Nothing in the C or C++ language standards specifies the speed of any construct (C++ does specify the time complexity of some operations applied to containers, but that's outside the scope of your question). The speed of the code generated for a given construct depends on the compiler used to compile it, and on the system it runs on.
For a given code construct that's valid C and valid C++ with the same semantics, there's no fundamental reason why either should be faster than the other. But it's likely that one will be faster than the other if the developers of the compiler were a little more clever.
That depends on what you mean by "equivalent". If you compare C's stdio.h with C++'s iostream, stdio.h operations are generally faster (quite a bit faster in some situations). But if you are talking about code written in the subset of C++ that also compiles as valid C, the generated machine code will likely be identical.
For one example, C++ lacks the keyword restrict. Used correctly that sometimes allows the compiler to produce faster code.
restrict, but it happens,restrict apply, and act accordingly, even though the keyword isn't used,restrict or __restrict as an extension anyway.But occasionally (or quite commonly in some domains), restrict is a really good optimization, which I'm told is one of the reasons for still using Fortran. It's certainly one of the reasons for the strict aliasing rules in both C and C++, which give the same optimization opportunity as restrict for a more limited set of circumstances.
Whether you "count" this depends to an extent what you consider "equivalent code". restrict never changes the meaning of a program that uses it validly -- compilers are free to ignore it. So it's not a stretch to describe the program that uses it (for the eyes of the C compiler) and the program that doesn't (for C++) as "equivalent". The version with restrict took more (perhaps only slightly more) programmer effort to create, since the programmer has to be sure that it's correct before using it.
If you mean, is there a program that is valid C and also valid C++, and has the same meaning in both, but implementations are somehow constrained by the C++ standard to run it slower than C implementations, then I'm pretty sure the answer is "no". If you mean, are there any potential performance tweaks available in standard C but not in standard C++, then the answer is "yes".
Whether you can get any benefit from the tweak is another matter, whether you'd have got more benefit for the same amount of effort with a different optimization available in both languages is another, and whether any benefit is big enough to base your choice of language on is still another. It's laughably easy to interoperate between C and C++ code, so if you have any reason at all to prefer C++, then like any optimization that alters your preferred way of coding, switching to C would normally be something you'd do when your profiler tells you your function is too slow, and not before.
Also, I'm trying to convince myself one way or the other whether the potential for exceptions costs performance, assuming that you never use any type that has a non-trivial destructor. I suspect that in practice it probably can (and that this is a contradiction to the "don't pay for what you don't use" principle), if only because otherwise there'd be no point gcc having -fno-exceptions. C++ implementations bring the cost down pretty low (and it's mostly in rodata, not code), but that doesn't mean it's zero. Latency-critical code may or may not also be binary-size-critical code.
Again it might depend what you mean by "equivalent" code -- if I have to compile my so-called "standard C++ program" using a non-standard compiler (such as g++ -fno-exceptions) in order to "prove" that the C++ code is as good as the C, then in some sense the C++ standard is costing me something.
Finally, the C++ runtime itself has a start-up cost, which is not necessarily identical to the C runtime start-up cost for the "same" program. You can generally hack about to reduce the cost of both by removing things you don't strictly need. But that is effort, implementations don't necessarily do it for you completely every time, so it's not strictly true that in C++ you don't pay for what you don't use. That's the general principle, but achieving it is a quality of implementation issue.
Contrary to what many C programmers like to think, one can often write tighter and faster code in C++ all without having to sacrifice a great deal in design.
I can't think of anything in C++ that is slower than its counterpart in C. Virtual functions NOT excluded.
Does Latency critical mean as fast as possible or does it simply mean that everything has to run in predictable time?
If it is the second case, then the only things that don't run in predictable time are new, delete and try/catch. In embedded programming there are directives to avoid such calls. In other cases, especially in C++11 you might notice some things are faster (std::sort is faster than C's sort() ) and some are marginally slower.
But what you gain over C++ is higher abstraction levels and you don't get the C-style bugs (like the typical malloc() without a corresponding free() )
There is no code in C++ whose direct equivalent in C is faster- or, indeed, more maintainable.
If you're using the language that's the intersection of C and C++, then any difference in performance when compiling that code with a C compiler versus a C++ compiler is purely a quality-of-implementation issue; there's no reason one should be faster than the other.
Of course in the real world, if you're using C++ you program using both the additional features that C++ has over the intersection of C and C++ and using different idioms than you would in C. And conversely, if you're using C, you at least use very different idioms from what you would use in C++, and you may also be using additional features of the modern C language which C++ does not have, like, as Steve mentioned, the restrict keyword, or VLAs or pointer-to-VLA types, or compound literals. These features could give major performance benefits in some situations, but in my experience they're not the reasons most people who choose C over C++ do so.
In my mind, the main difference really is idioms. In C, it's idiomatic to make a linked list by putting the next/prev pointers directly in the structure that's being kept in a list, rather than using a separate wrapper object for the list and list nodes. In C, it's idiomatic to iterate directly over the elements of a string as a character array. In C, it's idiomatic to work with objects that exist entirely in automatic storage whenever possible rather than allocating dynamic storage. And so on. These idiomatic differences are the main ways C code tends to be faster and lighter than C++.
Of course if you want, you can use the same idioms in C++, since most of the language constructs needed for most C idioms exist in the intersection of C and C++. And then you can also use the additional features of C++ when appropriate. But you'll be writing non-idiomatic C++ code, and you might receive a lot of criticism from other C++ programmers...
