C++ でインライン化する演算子と他のメソッドに違いはありますか? 私はそれを検索しましたが、私が見るように、それは一般的な質問ではありません. それを使用または回避する強い理由がある人はいますか? 注: 明らかに、インライン演算子が小さい場合を意味します。
3 に答える
これはコンパイラによって異なる可能性がありますが、コンパイラの観点からは、演算子は、ソース コードの構文が少し異なって見えるようにするやや変わった名前を持つ単なる別の関数であると予想されます。
それにもかかわらず、コンパイラのコード ジェネレーター部分が実行されるまでには、オーバーロードされた演算子と別の関数 (同じことを行った) との違いはなくなっていると思います。
そのため、クラス定義の本体内で宣言inline
または定義すると、他の関数と同じように (視点によっては少し) 演算子のオーバーロードが発生します。通常、どちらの場合もその影響は最小限であると予想されます-少なくとも最適化が有効になっている場合、ほとんどのコンパイラはinline
キーワードをほとんど無視し、インラインで展開するもの(および展開しないもの)について独自の決定を下します。
ただし、コンパイラがキーワードを無視できない場合があることに注意してくださいinline
。関数が実際にインラインで展開されているかどうかに関係なく、「1 つの定義規則」にはいくつかの特別な変更を加える必要があります。
inline
キーワードを使用して、関数をインラインにすることをコンパイラに提案できます。
コンパイラは、この要求に従う義務はありません。
演算子も同様です。インライン化されている場合とされていない場合があります。
コンパイラにインライン化を強制することはできないため、インライン化ヒントを使用または使用を避ける強い理由はおそらくありません。ヒントはそれだけだからです。
Visual C++ では、__forceinline
キーワードを使用してインライン化を強制できます。その結果、コードが大きくなり、パフォーマンスが低下する可能性があります。適切に設計されたシステムでは、(何かを強制することによって) オプションを排除するとパフォーマンスが低下することがよくあります。このキーワードを使用しても、すべての関数を正常にインライン展開できるわけではありません。
GCC のインライン化については、こちらで説明しています。
他の人が述べたように、コンパイラがメソッドを「インライン化」するかどうかは、通常、inline
キーワードの使用とコンパイラの最適化戦略に関して、あなたに代わっていません。
したがって、より重要な側面はヘッダー ファイルの読みやすさだと思います。operator
メソッドは、単純な変換を使用して構築できる算術演算の実装などのセットとして表示される可能性があります。したがって、そのようなヘッダー ファイルを調べる必要がある場合は、論理的に関連する一連の演算子メソッド シグネチャを一緒に見て、何が適用可能かどうかの概要を把握したいと考えています。
非常に単純な例は、operator==()
andの実装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); }
};