intまたはunsignedintまたは任意のPODを受け入れる関数シグネチャを想像してみてください。あなたがそれらから読んでいるだけなら、それらをconstする利点はありますか>?
私が考えることができる唯一のことは、あなたが誤ってそれを台無しにして割り当てないようにすることですか?
void f( const type x )
ポインテッド/リファードオブジェクトの定数ではなく、のようにトップレベルの修飾子について話していると想定しています。その場合、関数の引数の最上位のconst-volatile修飾子が関数のシグネチャから削除されると言語が判断することに注意することが重要です。つまり、次のように同じ関数を宣言します。
void f( int );
void f( const int );
void f( volatile int );
void f( const volatile int );
その観点から、宣言ではcv-qualifiersを追加する意味はありません。定義では、cv-qualifiersは実際にコンパイラーによってチェックされ、その場合、引数への変更にエラーのフラグが立てられます。const
間違いを見つけるために定義で使用すべきではないことを提案する人もいれば、使用すべきではないことを提案する人もいますが、私が見たほとんどのコードでは使用されてconst
いません。
私が考えることができる唯一のことは、あなたが誤ってそれを台無しにして割り当てないようにすることですか?
はい、それがポイントですconst
。そのため、関数の目的と正確さを分析して推論する方が簡単です。
それでも、パブリックAPIで値による(つまり、非ポインター/非参照)引数を作成することは一般的に悪い習慣と見なされconst
ます。後で実装でそれらを変更する場合は、次のいずれかを選択する必要があります。-パブリックヘッダーを編集するを削除するconst
と、クライアントコードの再コンパイルがトリガーされる可能性があります(ファイル変更のタイムスタンプ駆動型make
ルールで一般的です)-const
実装からを削除しないと、できるようにするためだけに、さらに別の変数への非効率的なコピーを作成せざるを得なくなる可能性があります値を変更するには....-宣言と定義を異ならせることで、プログラマーが2つの間をフリックするのを混乱させる可能性があります(どこかでconstを見たことを覚えているが、それが実装ではない場合、間違っていると判明する仮定を行う可能性があります-同じ危険はありません」非のために存在しますconst
実際の宣言const
-最悪の場合、変数の現在の状態を見つけるために不必要に注意深くチェックします)。
したがって、実装ファイルの内部にある関数のconst
場合は、付加価値があると思われる場合は使用しますが(場合によっては、冗長性で気にならない場合もあります)、パブリックヘッダーファイルでは積極的に避けてください。
例外的なC++では、ハーブサッターは次のことを推奨しています。
「関数宣言でconstの値渡しパラメーターを使用しないでください。変更しない場合は、同じ関数の定義でパラメーターconstを作成してください。」
constの正当性は、関数の引数で使用する場合の最適化のツールとしてではなく、より多くの契約で使用する必要があります。
これにより、使用法がより直感的になり、正直なプログラマーがエラーを起こすのを防ぐことができます。ただし、現代のコンパイラーは、必要な最適化を適用するのに十分な能力を備えています。
1つのことを明確にしましょう。ポインターはPODと見なされ、ポインターを宣言するのが一般的な方法const
です。
慣例として、整数および浮動小数点パラメーターは、関数がその本体内でそれらを変更する意図がない場合でも、constとして宣言されることはありません。変更は関数自体のコンテキスト内でのみ行われ、呼び出し元に伝播されることはありません。したがって、関数のパブリックインターフェイスの観点からは、変更を宣言することconst
は冗長です。
intまたはuintparamをconstで装飾する必要はありません。
このようにして、値が渡されました。このintまたはuintのコピーが生成され、関数に渡されます。関数内では、変更はこの外部のintまたはunitには影響しません。
ポインタパラメータでconstを使用します。