そのため、行列 ArrayResizeMx(A, n, m) に対してのみ、ArrayResize と同様の関数を作成するようお願いしたいです。 そして、おそらく多次元的なものに対しても。つまり，行列をオブジェクトとして扱うのではなく，C言語流に言えば通常の配列として扱えるようにするのです． 特に行列を視覚的に表現するために、ArrayPrint(A, 0) 関数は、オブジェクトからではなく、配列から行列を表示します。
そのため、動的行列を扱う関数が開発元からすぐに提供される必要があるのです。 開発者は対象をよりよく理解し、ラッパーを使わないメモリ割り当ての方がずっとよく、速く見える。 少なくとも1つの関数ArrayResizeMx(A, n, m, k)があれば、オブジェクトではなく、C言語のスタイルで配列を扱う可能 性が開けるでしょう。
開発者ではありませんが、コメントさせていただきます。
静的配列の 場合、コンパイラはコンパイル時に一定数のバイトをメモリに確保する必要があります。
コンパイル時にrowとcolが未知の場合、コンパイラはどの程度のメモリを確保すべきでしょうか？
呼び出し時にパラメータが省略された場合のみ、初期値が使用される。実際のパラメータは、実行時にしかわからない。
だから、ギミックはなく、言語を学ぶこと。
これはちょっと皮肉な話ですが、どちらかというと開発者へのアピールの意味合いが強いですね。
だからズロイ、悪く思わないでね。
動的な行列は、オブジェクトか構造体を通してしか扱えないことが判明した。もうひとつの松葉杖は、一般に作成されているものです。
mqlには変数へのポインタがないので、ポインタが利用できるオブジェクト・アプローチを利用する必要があります。
ですから、ダイナミックマトリクスを使うためには、ユーザーはOOPとポインタの扱い、さらにはMQLの実行に精通していなければなりません。
この知識を持っている人はどれくらいいるのでしょうか？答えは自分で分かっているはずです。オブジェクトアプローチを理解するのに苦労はしないが、OOPを知らない人には
特に動的な行列を扱うときに、この言語を使うための人工的な敷居を高くしてしまうのです。
私が思うに、開発者は逆に、言語を複雑にするのではなく、使いやすくすることに関心を持つべきでしょう。
つまり、ユーザーがその言語を快適に使うために必要な機能を開発することです。
ましてや、数値計算方法のほぼ基本である行列ではなおさらだ。
そのため、行列 ArrayResizeMx(A, n, m) に対してのみ、ArrayResize と同様の関数を作成するようお願いしたいです。
そして、おそらく多次元的なものに対しても。つまり，行列をオブジェクトとして扱うのではなく，C言語流に言えば通常の配列として扱えるようにするのです．
特に行列を視覚的に表現するために、ArrayPrint(A, 0) 関数は、オブジェクトからではなく、配列から行列を表示します。
2012年、動的な多次元配列の問題を解決することに成功した...。
関連スレッドはこちら：https://www.mql5.com/ru/forum/6729
テンプレートに対応することで、コードの改良が可能になりました。
2012年、動的な多次元配列の問題を解決することに成功した...。
関連スレッドはこちら：https://www.mql5.com/ru/forum/6729
テンプレートに対応することで、コードの改良が可能になりました。
スレッド全体を読むと、ありがたいことに短いです。
というわけで、話題のスターター、技を明かさず!
なんかあざとい、話題の餌食になって消えた。
そして再びPLOに飛び込み、誰も立ち入ることができない。
ユーリは自分の解答を挙げたが、その真偽のほどは誰にもわからない。
それを、私たちは修正していかなければならない。誰がやるんだ？ まだ完成していないので、誰もやらない。
そのため、動的行列を扱う関数が開発元からすぐに提供される必要があるのです。
開発者は対象をよりよく理解し、ラッパーを使わないメモリ割り当ての方がずっとよく、速く見える。
少なくとも1つの関数ArrayResizeMx(A, n, m, k)があれば、オブジェクトではなく、C言語のスタイルで配列を扱う可能 性が開けるでしょう。
そしてこれまたOOPに没頭、誰も立ち入ることができない。
そのため、ダイナミックマトリクスを使用するためには、ユーザーはOOPを理解し、ポインターを操作し、MQLの実行においても同様に操作する必要があります。
そのような知識を持っている人はどれくらいいるのでしょうか。答えは自分で分かっているはずです。オブジェクトアプローチを理解するのに苦労はしないが、OOPを知らない人には
特に動的な行列を扱うときに、この言語を使うための人工的な敷居を高くしてしまうのです。
開発者は逆に、言語を複雑にするのではなく、使いやすくすることに関心を持つべきと思われます。
意外かもしれませんが、今の若いプログラマーは、手続き型プログラミングよりOOPの方が簡単なプログラミングだと考えているんです。
25年前を基準に考えているのでしょう。今の若者は、母乳でOOPを吸収しています。トレンドに乗りたければOOPを学び、そうでなければ不平不満ばかりを言うことになる。
意外かもしれませんが、今の若いプログラマーは、手続き型プログラミングよりOOPの方が簡単なプログラミングだと考えているんです。
関数型プログラミングに比べたら？
意外かもしれませんが、今の若いプログラマーは、手続き型プログラミングよりOOPの方が簡単なプログラミングだと考えているんです。
25年前という単位で考えるのですね。今の若者は、母乳でOOPを吸収しています。流行に乗りたければOOPを学べ、そうでなければ不平不満ばかりを言うことになる。
そうですね、PLOは理解していますよ。
これは不平不満ではなく、建設的な提案です。
開発者が2つのmallocを割り当てるために1つの関数を書く必要がないように、彼らはユーザーにOOPを勉強することを強制する。
これは確かにその進歩、開発、言語の普及である。彼らがいかにOOPを愛し、理解しているかは、ここでもわかります。
ほら、ニコライさん、ラップされているものはすべて実行される必要のないコードなんですよ。
最近の最適化コンパイラについては言わずもがな、どのような命令が適用されるかはわからない。
また、アメリカのプログラマーでさえ、手続き型で書くことを好むのは、OOPが悪いからではなく、コードがよりシンプルで速いからだということも、驚かれるかもしれません。
また、プロジェクトに オブジェクトのタスクがない場合、なぜラッパーを使うのか、なんとか理解しなければならない、若い人向け ))
だから、若い人が熱心にOOPを吸収するというのは納得いかないんですよね。
mql言語のロジックが構築されているC言語で考えているのです。
Cは1972年生まれだから48歳か ))
しかし、とにかくCは最も速い言語の一つである。なぜかわかりますか？クラスラッパーを持たないからです。
機能的なものと比べてもいいかも？
プロシージャルな機能 :)
それはないと思います。ここに特別なトピックがあります :https://www.mql5.com/ru/forum/40295
特にMQL4用なので、最後まで見たことがない。
マーケットが閉じているときは、サーバーはシンボルクォートを送信すべきでは ないと思います。
私のロボットは、マーケットが「オープン」した後、ティックが入ってくると、トレンドやその反転を分析し、それには時間がかかるので、あまり影響を受けません。この間、マーケットがオープンします。
しかし、この時間帯に手動で取引を行いたい場合には、邪魔になるのです。マーケットドリブンの場合、マーケットが開くまで保留となり、当然ながら現在の価格で執行されます。
シンボル名を受け取り、true/false（市場のオープン/クローズ）を返す直接関数が明らかに欠落している。
見積もりと取引セッションがあります。検索、20回ほど説明されています。
もう一つ、何らかのバッジを追加してください。
4.お金
一日に受け取ったすべての資金の合計（市場、フリーランスなど）が表示される場所、それは非常に便利だろう、そして今、このためには、利用可能な残高を見ることができ、プロファイルに移動する必要があります。
もし、そんなに定期的に来るなら、クローム用のプラグインを注文しても良いですね ;)
クォートセッションとトレーディングセッションがあります。調べてみてください、20回以上噛み砕かれていますよ。
VC++からMQL5に乗り換えるのに数日しかかかりませんでした。こんなに長く探したのは初めてです。
取引中に 「Market closed」という メッセージが表示された場合、「キロメートル単位」の複雑なコードを書くのではなく、この状態を判断する簡単な方法を用意しなければなりません。
そんなアドバイスしないでよ。