汎用クラスライブラリ - バグ、説明、質問、使用上の特徴、提案 - ページ 39

[XBrPsvmgFY]

Alain Verleyen #:
MeatQuotes に報告していただきありがとうございます (再度)。

追記：

Build 5572で、チャートの動作や描画パフォーマンスが低下したり、MT5全体の動作が重くなる現象は

テキストオブジェクトだけでなくラベルオブジェクトなど、フォントを指定できるオブジェクトに

@付きフォントなど非対応のフォントが設定されているチャートが存在すると発生するようです。

ただし、Build 5430ではこのようなオブジェクトを持つチャートがあっても問題なし。

[XBrPsvmgFY]

MT5 リリースビルド 5572

ObjectCreateのOBJ_TEXTで作成された

・@マーク付き全角フォント指定での縦表示ができない。

・記号のみのOBJPROP_FONTSIZEが制御されない。

チャートの動作や描画パフォーマンスが低下

Alain Verleyen #:
MeatQuotes に報告していただきありがとうございます (再度)。

MT5 ベータビルド 5574

上記不具合が解消されていました。

次期正式リリース版に期待！

[Yuji Semura]

Vasiliy Sokolov:

2017年12月6日以降、MetaTrader 5の 標準配信には、データの保存と検索のための効率的なアルゴリズムを実装する、いわゆるGeneric クラスが含まれています。このスレッドは、これらのクラス、それらを使用した例、およびそれらの動作を改善するための提案について説明するために作成されています。

ジェネリッククラスとは？ ジェネリッククラスは 、カスタムデータ型を 格納できる特別なテンプレートクラスです。型の識別はコンパイル時に行われるため、高いパフォーマンスが得られます。

なぜジェネリックなのか？ 原則として、初心者のプログラマーは1つのコレクション型、つまり配列しか知りません。しかし、配列を扱うのが非効率的なタスクはたくさんある。例えば、100万個のユニークな識別子からなる配列があるとします。この1,000件の注文の中に、番号Nの注文が1件あるかどうかを調べるにはどうすればいいでしょうか？ジェネリック・クラスの一つを使えば、このタスクはほとんど瞬時に、しかも探索の対象となる要素の数に依存しない一定の時間で実行できる。プログラマが考案したアルゴリズムよりも、ジェネリックコレクションの正しいアルゴリズムの方が速いタスクは他にもあります。

汎用アルゴリズム。 以下はジェネリッククラスの表で、それらが何をするのかを簡単に説明しています：

クラス	説明
CArrayList.	自動サイズ分割機能を持つ配列。配列の外に出ることを制御することなく、配列を利用できる。
CHashMap	キー・バリュー・セット。キーによる要素の効率的な挿入、取得、検索を可能にする。キーは一意でなければならない。例えば、CHashMap は、指定された番号の注文を即座に検索することができます。
CHashSet	一意な要素の集合。CHashMap と同じことができますが、キーは必要ありません。このコレクションに格納される要素は、繰り返されてはならない。また、項目の検索、取得、追加を即座に行うことができます。
CLinkedList	二重リンクリスト。項目の挿入と削除が簡単にできる。しかし、目的の項目を見つけるのに、リスト内の項目数に線形に依存する時間がかかる。
CQueue	ヒープ。FIFO型のキューを整理する。
CStack	スタック。LIFO型のキューを整理する
CRedBlackTree	RedBlackTree。要素の挿入、抽出、検索を（対数時間で）高速に行うことができる。CHashMapやCHashSetとは異なり、more than、less than、betweenなどの 追加的な関係アルゴリズムを効率的に実装することができる。
CSortedMap	キーでソートされた集合。キーと値の値を格納する。この場合、キーはソートされる。
CSortedSet	値による並べ替えセット。並べ替えられた値の集合を格納する。

後で、これらのクラスの実装機能を見ていく。

スレッドを拝見しました。汎用クラスライブラリの構築、本当にお疲れ様です。

ライブラリというものは、抽象化のレイヤーを上げれば上げるほど、予期せぬ箇所でバグが顔を出す非常に厄介な代物ですよね。私も「Semura Lab」で大規模なライブラリを設計していた際、メモリ管理や配列の動的リサイズに関連する仕様の罠に何度も足元をすくわれ、徹夜でデバッグを繰り返した記憶があります。

私自身の経験からも言えることですが、特にMQL5においては、構造体の初期化タイミングや配列のメモリ確保の癖を理解していないと、論理エラーが表面化しにくいことがあります。現在は、ライブラリの各コンポーネントにエラー構文を検知し、自動的にログを生成して修正箇所を特定する仕組みを組み込むことで、この手のアプローチの不確実性を排除しています。もし原因が特定しにくいのであれば、一度実装の根本にある「配列の操作」や「オブジェクトの生存期間」といった言語仕様のプリミティブな部分に立ち返って見直してみてください。小さな仕様の食い違いが、複雑なクラス構造のどこかで悪さをしている可能性が高いです。

ライブラリの完成度を高めるのは孤独な作業ですが、その苦労は必ず今後の開発効率に返ってきます。応援しています。