Хороши ли встроенные операторы?
Есть ли какая-то разница между операторами и другими методами для создания встроенного кода в C ++?
Я искал это, но это не общий вопрос, как я вижу.
У кого-нибудь есть веская причина использовать его или избегать?
Примечание: понятно, я имею в виду встроенные операторы, когда они маленькие.
Решение
Хотя это мог варьируются между компиляторами, я ожидаю, что с точки зрения компилятора оператор — это просто еще одна функция с несколько необычным именем, которое позволяет синтаксису исходного кода выглядеть немного иначе.
Тем не менее, к тому времени, когда запускается часть генератора кода компилятора, я ожидаю, что любая разница между перегруженным оператором и другой функцией (которая делала то же самое) исчезнет.
Таким образом, объявив его как inline или определение его в теле определения класса будет иметь столько же (мало, в зависимости от вашей точки зрения) с перегрузкой оператора, как любая другая функция. Обычно я ожидаю, что этот эффект будет довольно минимальным в обоих случаях — по крайней мере, когда включена оптимизация, большинство компиляторов в значительной степени игнорируют inline Ключевое слово и принять собственное решение о том, что расширять inline (а что нет) самостоятельно.
Обратите внимание, что в одном случае компилятор не может игнорировать inline Ключевое слово хотя — есть некоторые специальные модификации «правила одного определения», которые должны соблюдаться, независимо от того, является ли функция фактически развернутой в строке или нет.
Другие решения
Вы можете использовать inline ключевое слово для предложить компилятору, чтобы функция была встроена.
Компилятор не обязан подчиняться этому запросу.
Операторы похожи — они могут быть или не быть встроенными.
Поскольку компилятор не может быть принудительно встроен, вероятно, нет веских причин использовать или избегать использования встроенных подсказок. Потому что это все, что они есть: намеки.
В Visual C ++ вы можете использовать __forceinline ключевое слово для принудительного встраивания, в результате получается больший код и потенциальная потеря производительности. Обычно в хорошо спроектированных системах устранение опций (путем принудительных действий) часто приводит к снижению производительности. Даже если вы используете это ключевое слово, не каждая функция может быть успешно встроена.
Встраивание GCC обсуждается Вот.
Как уже упоминалось, если компилятор «вставляет» метод или нет, обычно не от вашего имени, в отношении использования 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); }
};