Ваша оболочка будет встроена, однако ваши вызовы методов к библиотеке C обычно не выполняются. (Это потребовало бы оптимизации времени соединения, которая технически возможна, но в лучшем случае для AFAIK в современных инструментах)
Как правило, вызов функции как таковой не очень дорогой. Стоимость цикла значительно снизилась за последние годы, и ее можно легко предсказать, поэтому штраф за вызов как таковой незначителен.
Однако встраивание открывает двери для дополнительных оптимизаций: если у вас есть v = a + b + c, ваш класс-оболочка вызывает генерацию переменных стека, тогда как для встроенных вызовов большая часть данных может храниться в FPU стек. Кроме того, встроенный код позволяет упростить инструкции, учитывая постоянные значения и многое другое.
Так что, хотя мера до того, как вы инвестируете , остается в силе, я бы ожидал здесь некоторого улучшения.
Типичное решение состоит в том, чтобы привести реализацию C в формат, который можно использовать либо как встроенные функции, либо как тело "C":
// V3impl.inl
void V3DECL v3_add(VECTOR3 *out, VECTOR3 lhs, VECTOR3 rhs)
{
// here you maintain the actual implementations
// ...
}
// C header
#define V3DECL
void V3DECL v3_add(VECTOR3 *out, VECTOR3 lhs, VECTOR3 rhs);
// C body
#include "V3impl.inl"
// CPP Header
#define V3DECL inline
namespace v3core {
#include "V3impl.inl"
} // namespace
class Vector3D { ... }
Это, вероятно, имеет смысл только для избранных методов со сравнительно простыми телами. Я бы переместил методы в отдельное пространство имен для реализации C ++, так как они вам обычно не нужны напрямую.
(Обратите внимание, что inline - это просто подсказка компилятора, он не заставляет метод быть встроенным.
Но это хорошо: если размер кода внутреннего цикла превышает кеш инструкций, встраивание легко снижает производительность)
Возможность разрешения передачи / возврата по ссылке зависит от силы вашего компилятора, я видел много где
foo (X * out)
заставляет переменные стека, тогда как
X foo ()
сохраняет значения в регистрах.