NULL 終了文字列 (SZ) を使用するか、プレフィックス付き長さ文字列 (LPS) を使用するかは、ホットな話題のようです。実際、そのトピックに関する質問もここにあります。
それで、何かが私に起こりました。両方を少し使うことはできますか？つまり、明らかに、LPS & SZ (LPSZ?) ストリングは、どちらか一方の優れた点を削除せずには作成できません。
ただし、SZ の最大の不満は、弦の長さの測定に時間がかかるため、操作に時間がかかることです。私はそれについて考えていました：
すべての弦を SZ にします。ただし、文字列の長さ mod 256 (つまり: len % 256) を文字列の前の 1 バイトに格納することもできます。操作の複雑さが軽減されるわけではありませんが、1 バイト余分に犠牲にして、速度が大幅に向上する可能性があります。
このスキームの主な利点は次のとおりです。
- 特定のサイズに制限されない
- 通常の SZ より高速 (最大 256x)
- すべての異なるメモリ サイズ間で互換性があります
- 小さい文字列は、スペース効率が非常に高い (で無駄なバイトがない
len) - エンディアンの問題なし
- マシン間で移植可能 (3 & 5 を参照)
これは、strlen ()このスキームの下でどのように見えるかです (明らかに、別のライブラリを作成するため、別の名前を付けます):
size_t ppsz_strlen (const char *s) {
// get LPS
size_t = ((uint8_t *) s)[-1];
// check for SZ across every 256 byte interval
for (x = x; s[x]; x += 256)
continue;
return x;
}
適切な名前は、PPSZ (部分的にプレフィックス付きの Null 終了文字列) です。
私には、これは妥当なトレードオフのように思えます: かなり大きな加速に対して 1 バイトです。もちろん、2 バイト、4 バイト、または 8 バイトではないのかと尋ねる人もいるかもしれません。私の答えは、プログラムのほとんどの文字列は大きくなりすぎず、65536、16777216、2 ** 32またはでスキップする2 ** 64と価値が高くなりすぎるということです。これらのケースのいくつかでは、文字列の分割を検討するのに実際に良い時期かもしれません. 特に、1 つの文字列が 64 ビット アドレス空間のサイズを超えてオーバーフローしている場合。
とにかく、他の誰かがコンセプトについて何か考えを持っているかどうか疑問に思っていました. これまで実際にその概念を見たことがなかった理由について、おそらく見逃しているものがあると確信しています。
提案や問題が見つかった場合は、ありがとうございます。