size_tは現在のシステムによっては32ビットまたは64ビットになる可能性があるので、常にsize_tを参照またはconst参照として関数に渡すのがベストです4バイト？ （8バイトの場合はコピーを作る必要があります）私が見たオープンソースのコードはたくさんありますが、コンパイラが64ビットの整数をサポートしている場合、これらの64ビットの整数は常に参照として渡されます。なぜ彼らはsize_tに対してこれをしないのですか？あなたの意見は何ですか？引数としてsize_tを渡す「効率」
すべてのプリミティブ型をコピーするのに必要な操作は、通常は単なるアセンブリ命令であるため、すべてのプリミティブ型を値渡しすることが慣例です。したがって、値でsize_tを渡すことは、参考としてsize_tを渡すよりも好ましい。
私はあなたのロジックにかなり従っていません。参照渡しの場合、現在のシステムによっては、アドレスは32ビットまたは64ビットのいずれかになります。
いずれにしても、私は参考としてそれを渡す利点がありません。
size_tは、メモリに割り当てることができるオブジェクトのサイズをバイト単位で保持できることが保証されています。これは通常、ポインタと同じサイズであることを意味する傾向があります。これは、通常はCPUレジスタのサイズです。
参照渡しは役に立ちません。ポインタはほぼ確かに少なくとものsize_tに相当します（そうでない場合、問題なくsize_tを小さくすることができます）。そして、いずれの場合でも、ほとんどの64ビットABIは64ビットレジスタに整数引数を渡すため、スタックフットプリントに違いはありません。
size_tのほとんどの実装では、オブジェクトへのポインタとオブジェクトへの参照はまったく同じサイズです。この方法それの
思う：size_tは任意のオブジェクトのサイズを保持することができますし、任意のオブジェクト内の任意のバイトに対処するためにchar*を使用することができますので、それはsize_tとchar*が密接に関連大きさを持たなければならないことを意味します。したがって、あなたのアイデアはほとんどの実装で意味をなさない。
'sizeof（char *）'は 'sizeof（size_t） 'より大きくてもよいことに注意してください。単一のオブジェクトがセグメントのサイズよりも大きくなることはできないが、ポインタは複数のセグメントを指すことができるはずのセグメント化されたメモリシステムでは、 – musiphil
参照渡しの問題は、コンパイラが値をメモリに格納し、その格納された値のアドレスを参照として渡す必要があることです。 64ビットアーキテクチャでは、メモリに値を格納することなく、レジスタ（6つのレジスタ）にもっと多くの情報を渡すことができるため、小さな値を参照渡しすることで最適化を禁止します。あなたはconstの参照が64ビットシステム上の4つのバイトがあると信じていますなぜ
http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/
http://en.wikipedia.org/wiki/X86_calling_conventions#x86-64_Calling_Conventions
：
この質問へのより多くがあり、あなたがで開始したいのでしょうか？そして、4バイトの参照と64ビットのsize_tを持つのはどのような意味ですか？ –
ああ、私はそれを忘れていたとは思っていません。今質問を削除したい – Marlon
'size_t'は64ビット、ポインタは32ビットになるシステムは？ – Mikel