そもそもこれを行う必要があることを示唆する証拠 (プロファイリング データなど) なしにプログラムを時期尚早に最適化しようとしているように見えるという点で、私は Joachim に同意します。偉大なドナルド・クヌースは、「時期尚早の最適化は諸悪の根源である」と言いました。心に留めておいてください。
それはさておき、2 つ目の問題は、割り当てが高価な操作ではないということです。一般的に言えば、割り当ては O(1) 時間で完了します。実際のエンコード操作は、何倍もコストがかかります。
第三に、はい、あなたの問題に対する解決策があります。しかし、特定のエンコーディングで文字列に必要なバイト数は予測できないため、ポイントがわかりません。これが、(デフォルトで)Encoding
サブクラスが自由に独自のバッファーを割り当てて返すことができる理由です。最初の呼び出しで十分なサイズのバッファーが提供されなかった場合は、より大きなバッファーでメソッドを再度呼び出します。
もう 1 つの問題は、C の null で終わる文字列とは異なり、.NET 文字列は固定長であり、ターミネータがないことです (.NET 文字列には null 文字を含めることができますが、C 文字列には含めることができません)。そのため、バッファを使用するたびにバッファをクリアする必要がある場合があり、これによりプログラムがさらに遅くなります。
使用する必要がある 2 つの方法があります:Encoding.GetBytesCount(String)
またはEncoding.GetBytes(String, Int32, Int32, Byte[], Int32 )
、次のように:
Encoding encoder = ...
Byte[] buffer = new Byte[1024]; // allocating a 1KB-sized buffer which it is hoped is large enough for every possible string
foreach(String str in stringsToEncode) {
buffer.Initialize(); // reset every byte to zero (your program may need this, or it may not; I don't know enough about it).
Int32 bytesWritten;
do {
try {
bytesWritten = encoder.GetBytes( str, 0, str.Length, buffer, 0 );
} catch(ArgumentException) {
bytesWritten = Int32.MaxValue;
buffer = new Byte[ buffer.Length * 2 ];
}
}
while( bytesWritten == Int32.MaxValue )
}
もちろん、このコードにはそれ自体の問題があります。しかし、あなたはアイデアを得る必要があります。