Nie sądzę, aby powód był tak bardzo związany z wydajnością, jak z interoperacyjnością. Język C ++ jest bardziej złożony niż język C, ale z punktu widzenia wydajności nie powinno być zauważalnych różnic w obu przypadkach. Niektóre konstrukcje C ++ są szybsze niż ich odpowiedniki w C ( std::sortsą szybsze niż qsort) i prawdopodobnie istnieją dobre przykłady odwrotnej sytuacji.
EDYCJA: Po stronie interoperacyjności ...
Zasadniczo standard C ++ nie definiuje niektórych rzeczy, które mogą być potrzebne do łatwego współdziałania między plikami binarnymi utworzonymi za pomocą różnych kompilatorów / wersji. Najbardziej zauważalną kwestią byłaby konwencja nazewnictwa symboli w systemie binarnym. W języku C język definiuje pojedyncze mapowanie z każdego symbolu w kodzie na nazwę symbolu binarnego. Wywołana funkcja my_functionutworzy symbol w wywołanym pliku binarnym my_function. Z drugiej strony, ze względu na cechy takie jak przeciążanie funkcji, nazwy funkcji C ++ muszą zostać zniekształcone(przetłumaczone na różne symbole funkcji w pliku binarnym, kodujące typy argumentów i typy zwracane), a standard nie definiuje, w jaki sposób odbywa się zniekształcanie. To z kolei oznacza, że ta sama funkcja w C ++ może być skompilowana do różnych symboli w zależności od kompilatora (chyba że extern "C"jest używana do wymuszenia współdziałania C dla tych funkcji w C ++).
Pod koniec dnia interfejs między językiem skryptowym a rodzimym kodem i tak musiałby być interfejsem C, nawet jeśli szczegóły dotyczące jego wewnętrznej implementacji mogłyby być C / C ++ / jakimkolwiek innym językiem ojczystym.
(Celowo nie chcę wdawać się w płomienną wojnę o preferencje językowe, C ++ jest naprawdę potężny, ale jest też trochę przerażający, ponieważ jest znacznie bardziej złożonym językiem niż C, a niektóre rzeczy, które wyglądają na proste, mogą mieć wpływ na wydajność)