1

ハッシュテーブルを作成しています。各値は文字列です。文字列を格納するためにどの構造を使用するかを決める問題があります。直感的に と を考えstd::stringましchar*た。しかし、

1)、std::string文字列が短い場合はスタックを使用するようです。つまり、ハッシュ テーブルが非常に大きい場合、これは適切な選択ではありません。
2)、char*次に使用する場合、値を変更したい場合に何を返すかわかりません。たとえば、次のような状況です。myTable[i] = changedString;この場合、新しい文字列クラスを実装する必要があるようです。しかし、私はそれがstd::stringそこに必要ではないだろうと感じています.

誰か提案やコメントをいただけますか？ありがとう！

4

3 に答える 3

1

unordered_map (HW?) を実装しようとしており、これが使用しない理由だと思います。

std::vector または std::string を使用する必要がありますが、配列は使用しないでください。

また、スタックを使用した std::string の問題があるのはなぜですか?

于 2013-11-02T14:00:11.163 に答える
0

によって引き起こされるオーバーヘッドstd::stringは最小限であり、実際には、文字列の内部バッファーへのポインターを除いて、sizeとcapacityのメンバーだけがあり、両方のタイプsize_tがあり、(環境に依存します) 文字列あたり 8 バイトとしましょう。したがって、100 の配列がある場合000 個の文字列を追加すると、約 780KB のオーバーヘッドが発生しますが、厳密なメモリ制限のある環境にいる場合を除き、これについて心配する必要はありません。

文字列の長さが固定されているか、最小限の方法で変化する場合 (2 ～ 4 文字としましょう)、自動保存期間を持つ配列を使用する方が合理的です。

struct X {
    ...
    char code[4]; // up to 4 characters
};

次の方法でインスタンスをコピーしている場合でも、これは正常に機能します。

X x1, x2;
...
x2 = x1;

ただし、現時点でこれについて心配する十分な理由がない場合は、この時点で行うことはほとんど時期尚早の最適化です。

于 2013-11-02T14:10:56.693 に答える
0

ハッシュ テーブルを作成することが目標である場合は、その特定のタスクをより複雑にするような気を散らすものを排除するように努める必要があります。そのため、テーブル内の変更可能な値に std::string を使用する必要があるため、char* の割り当てと割り当て解除に開発努力を費やす必要はありません。

ハッシュ テーブルが正しく機能するようになったら、char* に移行する理由がある場合は、後でいつでも変更できます。最も優先度の高い目標であるハッシュ テーブルに集中し、最初の目標に到達するまで std::string のパフォーマンスを打ち負かすことに時間を費やさないでください。いずれにせよ、 std::string を打ち負かすことは価値がないかもしれません。

于 2013-11-02T14:11:46.883 に答える