2016-05-25 2 views
0

Golangのマップはどのようにキーを比較しますか?何らかの理由で、内部に2つの値を持つキーとして構造体を持つ必要があります。私は最初の値だけでなく、秒で比較するマップをしたい。 2番目は私の用法です。 Javaの場合と同様に、私はequalsメソッドをカスタマイズすることができますので、マップ内にはlogically equalキーしかかかりません。それを行う方法はありますか?Golangでは、構造体をキーとしてキー比較をカスタマイズできますか?

編集:これを行う方法がないように見えます。だからここで私の問題を解決しています。私に「Go-way」で考えさせてください。

したがって、キーの挿入時間を追跡する「タイムマップ」を実装したいと考えています。つまり、値を受け入れて処理するマップがあります。今、マップのデータが特定の時間間隔よりも古い場合、私はそれをクリアする必要があります。

私は、idとtimestampを持つキー構造体を持つと考えました。新しいキーが来ると、mapはidとcurrentTimeInMillisでそれをとります。キーがすでに存在する場合、マップは最初の挿入時間を保持し、値配列のみを更新します。

処理するには、マップをループし、特定のキーがしきい値を超えているかどうかを確認してから、クリアします。このタイムスタンプを値配列に含めることはできますが、それも独自のタイムスタンプを持つので、もう1つを入れると他の人を混乱させる可能性があります。

何かお勧めします。

+1

いいえ、マップのハッシュ方法を変更することはできません。 – JimB

+0

ああ、それは悪いニュースです。私はいくつかの選択肢を見つける必要があります。ゴランは非常に限られています。 :-( – theGamblerRises

+4

@theGamblerRisesあなたは何をしたいのですか?golangにJavaコードを実装しないでください。 – khrm

答えて

0

あなたの価値に時間をかけてください。データの構造化の例をいくつか示します。

type DataObj struct { 
    Id int 
    Updated time.Date 
    // other fields 
} 

m := map[int]DataObj{} 
m[d.Id] = d // assign using the id as your key 

for k, v := range m { 
    if time.Since(v.Updated) > duration { 
     delete(m, k) // remove the stale item 
    } 
} 

// some logic like this for adding/overwriting 
v, ok := m[newObj.Id] 
if ok { // an element with this id existed 
    if time.Since(v.Updated) > duration { 
      m[v.Id] = newObj // assign new value over old one 
    } 
} 

私は、あなたが働くためのコードを持っていないので、はるかに具体的なものは提供できません。タイマーで動かすために(削除ビットのような)これのいくつかをおそらく望んでいるようです。これを行うには、関数をゴルーチンとして呼び出し、タイマーを使用してX秒ごとにブロックを解除し、マップから項目を削除します。これを行う場合は、バックグラウンドを実行しているremove関数が古い項目を除外している間に、呼び出しスコープがマップにアクセスしないようにミューテックスを使用する必要もあります。

上書きビットは本当に単純ですが、項目がマップにあるかどうかをテストし、タイムスタンプをチェックします。しきい値を超えた場合は新しい値を割り当てます。

ここで取り除くべき主なものは、キーの構造体を使用しないことです。オブジェクトの等価性を行う理由はありません。オブジェクトにはIDがあります。キーとして使用します。あなたが気にしているものはすべて、値で保持することができます(キー自体でさえ)。誰かが指摘しているように、これはJavaではなく、たとえそれがあったとしても、C#とJavaの平等のオーバーライドは、文字通り大変な悪夢です。

+0

ありがとう。私は値のタイムスタンプで行くつもりです。私は私の解決策で更新します。それ以外は、Javaでの等価オーバーライドは非常に便利です。私はgolangが好きです。それは簡単で処理が速いからです。しかしJavaは私にとってとても美しく、**個人的な見解です**。 – theGamblerRises

+0

@theGamblerRisesはい、オーバーライドを嫌うのは単なる意見です。彼らはコードを見栄え良くすることができますが、大規模なプロジェクトでは維持するのが難しくなります。後ほど参照を比較する必要がある場合は、かなり荒い場所に置かれます。 – evanmcdonnal

関連する問題