template<typename TKey,typename TValue>
class CHashMap: public IMap<TKey,TValue>
{
protected:
int m_buckets[];
Entry<TKey,TValue>m_entries[];
int m_count;
int m_free_list;
int m_free_count;
IEqualityComparer<TKey>*m_comparer;
bool m_delete_comparer;
.................................
//+------------------------------------------------------------------+//| Gets the element at the specified index. |//+------------------------------------------------------------------+template<typename T>
bool CArrayList::TryGetValue(constint index,T &value) const
素晴らしい理論的な例です実際に、何千ものトランザクションを操作したことがある人はいますか？
P.S.私は、それがガラクタであり、誰もそれを必要としないことを証明しようとはしていません。リアルトレードのための価値を理解しようとしている。私は一般的な理論家ではなく、純粋な実践家です。
CHashMapの 現在の実装について簡単に説明します。
まず、Entry<TKey,TValue>とは 何かについて説明します。
基本的にはCLinkedListのようなNodeで、これを含んでいます。
m_entries[] - 追加されたキーと値、hash_code、next が配置される "セル" の配列。アレイの大きさは容量に相当します。
m_count - m_entries の最初の未使用セルのインデックスを指定する。初期値は0であり、Capacityまで成長し、次にCapacityと全アレイのサイズを増加させながら全アレイをリビルドする。
m_buckets[] - m_entries[] のインデックス配列．初期値は-1である。アレイサイズは容量に相当する。
衝突しない、CHashMap コンテナに一意な値を追加する。
CHashMap コンテナのキーで値を取得する。
衝突を解決する
衝突、CHashMap コンテナのキーで値を取得する。
CHashMap コンテナから値を削除する。
ハッシュテーブルの再構築（容量を増やすための処理）:
トレーディング、自動売買システム、ストラテジーテストに関するフォーラム
Generic Class Library - バグ、説明、質問、使用法、提案。
セルゲイ・デジブリク さん 2017.12.09 01:12
CHashMapの 実装を知りました
正直、気に入りました。
いくつかの改善案があります。
1) 私の率直な意見ですが、この実装では、ハッシュテーブルを再構築する際に、初期サイズ3とそれ以降のサイズの両方について、容量の選択がかなり正しくありません。
そうですね、分布の均一化のために素数を選ぶというのは正しいです。
しかし、CPrimeGeneratorの実装は期待に沿うものではなく、素数の抜けがある。
このような「ジェネレータ」の目的は明確で、素数の自動生成で1.2桁の増加率を提供することである。
しかし、これでは係数が小さすぎるのでは？C++でベクトルを扱う場合、この係数はライブラリにもよりますが、通常1.5〜2.0です（演算の平均的な複雑さに強く影響するため）。
この場合、定数係数の後、素数リストの2進法検索で素数に丸めるという 方法が考えられます。
それに初期サイズが3というのは小さすぎる、前世紀に生きているわけではないのだから。
2) 現在、ハッシュテーブルの再構築（Resize）は、容量が100%になったとき（m_entries[]がすべて埋まったとき）にのみ行われています。
このため、あまり均等に配置されていない鍵では、かなりの量の衝突が発生する可能性があります。
オプションとして、ハッシュテーブルの再構築を行うために必要な制限値で100%を削減するフィルファクターの導入を検討する。
実際のところ、数千件のトランザクションを操作したことがある人はいますか？
そう、1パスで数百万回のヒストリーコールは、多くの人が実践しているのです。
オン・フォート・エブリファースト
クリアです。
hftアルゴリズムでオーダーを送る ことと、それを拾って分析することは別物です。これらのハッシュは送信には必要なく、また解析にも必要ない。
だから、悪気はないんです。理論も必要です。
クリアです。
hftアルゴリズムでオーダーを送ることと、後でピックアップして解析することは別物です。送信にはこれらのハッシュは必要ありませんし、解析にも必要ありません。なぜなら、解析されるのはそのようなものではないからです。
だから、悪気はないんです。また、理論も必要です。
食器洗い乾燥機は使わず、スポンジを使っています。
悪気はないんです。食器洗い機なんてダサい、何のためにあるんだ。
クリアです。
hftのアルゴリズムで命令を出すのと、後で解析のために上げるのは別物です。このハッシュは提出するのに必要ありませんし、その後で別のものを解析するので、解析には必要ありません。
だから、悪気はないんです。また、理論も必要です。
何の恨み？松葉杖を書き続けてください。
現在のCHashMapの 実装について簡単に説明します。
ありがとうございます、ソースコードを解析するときに使ってみます。
何の恨み？松葉杖を書き続けてください。
ありがとうございます。ソースを解析するときに使ってみます。
新しいキーと値のペアを追加する際に、コンテナ内のキーが存在するかどうかのチェックを省略し、最初に実行しました。
でも、そんなことはどうでもいいんです。
ジェネリック全体でこのようなことを修正してください。