Есть ли разница между операторами и другими методами для создания inline в С++? Я искал его, но это не общий вопрос, как я вижу. У кого-то есть сильная причина использовать его или избежать? Заметьте: я имею в виду встроенные операторы, когда они малы.
Являются ли встроенные операторы хорошими?
Ответ 1
Хотя это может различаться между компиляторами, я бы ожидал, что с точки зрения компилятора оператор - это еще одна функция с несколько необычным именем, которое позволяет синтаксису исходного кода выглядеть немного по-другому.
Тем не менее, к моменту, когда часть генератора кода компилятора работает, я ожидаю, что исчезнет какая-либо разница между перегруженным оператором и другой функцией (которая сделала то же самое).
Таким образом, объявление его как inline
или определение его внутри тела определения класса будет иметь столько же (немного, в зависимости от вашей точки зрения), с перегрузкой оператора, как и любая другая функция. Обычно я ожидаю, что эффект будет минимальным в обоих случаях - по крайней мере, когда оптимизация включена, большинство компиляторов в значительной степени игнорируют ключевое слово inline
и принимают собственное решение о том, как расширить встроенную (и что не делать) на их собственных.
Обратите внимание, что в некотором роде компилятор не может игнорировать ключевое слово inline
, хотя есть некоторые специальные изменения в "одном правиле определения", которое должно соблюдаться, независимо от того, действительно ли функция фактически развернута в строке или нет.
Ответ 2
Вы можете использовать ключевое слово inline
, чтобы предложить компилятору, чтобы функция была встроена.
Компилятор не обязан выполнять этот запрос.
Операторы похожи - они могут быть или не быть встроены.
Поскольку компилятор не может быть принудительно подключен, вероятно, нет серьезных оснований для использования или предотвращения использования подсказок. Потому что это все, что они: подсказки.
В Visual С++ вы можете использовать ключевое слово __forceinline
для принудительной вставки, результатом является больший код и потенциальная потеря производительности. Это распространено в хорошо разработанных системах, которые устраняют варианты (заставляя вещи), часто приводят к снижению производительности. Даже если вы используете это ключевое слово, не каждая функция может быть успешно выполнена.
Вложение в GCC обсуждается здесь.
Ответ 3
Как упоминалось ранее, если компилятор "встроил" метод или нет, обычно не от вашего имени, в отношении использования ключевого слова inline
и стратегии оптимизации компилятора.
Итак, я думаю, что более важным аспектом является читаемость заголовочных файлов, а методы operator
могут появляться в виде наборов, например. арифметические операции, где простые преобразования могут быть использованы для их создания. Поэтому, если мне нужно заглянуть в такой заголовочный файл, мне бы хотелось увидеть логически связанные наборы сигнатур метода метода, чтобы получить обзор того, что применимо или нет.
Очень простой пример - реализация operator==()
и operator!=()
:
class A
{
public:
// Equality tests
//-----------------------------------------------------------------------
// This may involve some mor complex code that'll look ugly here
bool operator==(const A& rhs) const;
// Fine, this is a one liner. Code appears 'inline' (and is likely to be
// chosen for inlining by the compiler, no matter if inline keyword or not)
bool operator!=(const A& rhs) const { return !A::operator==(rhs); }
};