ベータ版530での配列リサイズの不具合 - ページ 5

 
angevoyageur:

他の端末のアップデートを回避し、テストしたい場合は、以下のフォルダを削除する必要があります。

  • Windows 7の場合。 C:\ Windows 7 : C: ¦ProgramData ¦MetaQuotes ¦WebInstal 更新成功後、テスト端末から他の端末に更新されない。
  • Windows XP : C: ♪Documents and Settings ♪All Users ♪Application Data ♪MetaQuotes ♪Webinstall ♪です。

この情報(おそらくロシアのフォーラムから引用)はもう最新ではありません。v534以降、Win7+でのアップデートは%programdata% ではなく %appdata%metaquotes***webinstall に入れられるようになりました。

以降のバージョンではまた変更される可能性があります。

 
cyclops993:

この情報(おそらくロシアのフォーラムから得たもの)は、もはや最新ではありません。v534以降、Win7+でのアップデートは%programdata%</metaquotes></metaquotes></webinstallではなく、%appdata%</metaquotes></webinstallに入れられるようになりました。

以降のバージョンではまた変更される可能性があります。

ありがとうございました。
 
angevoyageur:

私はプロのプログラマーなので、おそらく良い例ではないでしょう。私はプロのプログラマーですから、これは私にとって大きな努力ではありませんし、新しいプログラミング言語を学ぶのが好きなのです。oopの経験もあります。

.. . . .

私はソフトウェアエンジニアではありませんが、mql5に少し手を出していて、自分が書いたコードでOOPを使う必要はありませんでした ... ... しかし、他の人のコードを読んで理解することで多くを学びます。
 
RaptorUK: 私はソフトウェアエンジニアではありませんが、mql5に少し手を出しましたが、私が書いたコードでOOPを使う必要はありませんでした ... しかし、私は他の人のコードを読んで理解することで多くを学びます。OOPの背後にある原理を理解しなければ、いくつかのmql5コードを追うことは難しいかもしれません。

OOPは、Encapsulation、Abstraction、Inheritance、Polymorphismを信じることです。抽象化したからといって、他人のコードを「追える」ようになるとは思えません。必要なのは、それが何をするかということだけです。 。もっと真面目な話をすると、OOPは、言語とIDEによって強制され、サポートされる組織化/カタログ化のレベルを提供すると私は信じています。プログラマは、あまりに多くの組織を持つことはできません。これはおそらく、ほとんどのプログラマにとって、将来のプロジェクトで 時間を節約することになるでしょう。

 

このような状況下で、このような弊害が発生した場合、どのように対処すればよいのでしょうか?

 

私がEAを作成する場合、通常は本の内容と同じように、現在の状況を蓄積し、その情報をグローバル配列に格納する中央ハブ関数と、その配列の情報を使って何をすべきかを決定する周辺関数で囲まれ、それぞれがロットサイズなどを計算する他のヘルパー関数を呼び出すという形になります。start()関数は、最初に中央のハブ関数を呼び出し、その後、優先順位の高い順に周辺関数を呼び出すだけです。この基本的な構造はとてもうまく機能していますが、全体が配列へのグローバルなアクセスに集中しているという事実は、あまり好きではありません。言い換えれば、十分に機能しているので、直そうとは思わなかったということです(笑)。

Oopのアプローチはこれとどう違うのか、またその利点は何なのかを知りたいのです。

 
SDC: 私がEAをコーディングするときは、たいていこの本のような形になります。中央のハブ関数が現在の状況を蓄積し、その情報をグローバル配列に格納し、周辺関数がその配列の情報を使って何をするかを決め、それぞれがロットサイズなどを計算する他のヘルパー関数を呼び出します。start()関数は、最初に中央のハブ関数を呼び出し、その後、優先順位の高い順に周辺関数を呼び出すだけです。この基本的な構造はとてもうまく機能していますが、全体が配列へのグローバルなアクセスに集中しているという事実は、あまり好きではありません。言い換えれば、十分に機能しているので、修正しようとは思わなかったということです(笑)。

oopのアプローチはそれとどう違うのか、どんな利点があるのか知りたいです。

あなたはプログラムの流れを説明しているのだと思います。それはOOPの背後にある大きな理念ではないと思います。(OOPは以下のような問題を解決しようとするものです。私はOOPの素人ですが、世界観を形成しています。

1)関数は グローバル変数から独立しているか?言い換えれば、その関数は独立したオブジェクトなのか?カプセル化

2) その関数はローカル変数名のような詳細を隠しているか?画面上のコード量が少なくなっていないか?抽象化

3) 変更のために自分自身の複製を作成する機能を備えているか?独自のデータ型を作成する機能とか?継承です。

4) オンザフライで変更する機能があるか?例:double_arrayだけでなく、integer_arrayも扱えるか?ポリモーフィズム。

OOPがEAの構築に役立つ方法は、EA_Builderがプログラマーでない人がエキスパート・アドバイザーを構築するのに役立つ方法と似ています。好きなOrder_Accounting_Function -> Data_Function -> Event Tracking Function -> Volume Defining Function -> Trading Criteria Defining Function -> Trade Functions -> Error Processing Functionを使うだけです。これでExpert_Advisorの出来上がりです。長年培った取引基準定義関数を簡単に入れ替えることができるのです。

例えば、私のExpert Advisorを変更したい場合、私のグローバル変数がどこに適用され、どの関数がそれに依存しているか(ステートやステータス配列のように)を研究する必要があります。OOP はそれを Accounting(Option_3); Display(Option_1); Caption(Option_5); TradingSys(Option_7); VolumeSize(Option2); OrderType(Option_2) と単純にし、それがエキスパート全体となるようにする。

こうすることで、他の人があなたのライブラリのセットを使うことが容易になり、通常、他の人のために機能するものは、将来的にあなたのためにも機能するようになるのです。他に何もなければ、組み立てライン上のスタンドアロンオブジェクトを考えてみてください :)

 
***Ps:(これは忘れたくないのですが)。確かに、私たちのほとんどは、自分が使っているコードの中身がわからないというのは嫌なものです。あるいは、他の人のコードを理解しようとすることで頭がいっぱいになり、そうでなければ、おそらくそれを使うことはないでしょう。しかし、mql4のNative関数(例えばOrderSend())のほとんどは、私たちから見ればオブジェクトです。私たちはそのコードを見ることはできませんが、それを受け入れることができます。私は、このような他者のライブラリの受け入れは、大規模なプロジェクトに携わるプロのプログラマーが受け入れなければならないものだと考えています。そうでなければ、車輪の再作成に行き詰まるでしょう。
 

私のEAの最新バージョンはそれに近づきつつあり、今ではすべてインクルードファイルになっていますが、少なくともいくつかの修正なしにそのまま使えるほど強固なものではありません。私がよく犯す間違いは、曖昧であるべき関数に 基準を特定するコードを書いていることに、後になって気がつくことです。また、それらはグラバル配列に依存しすぎています。

 
ubzen:
***Ps:(これは忘れたくないのですが)。確かに、私たちのほとんどは、自分が使っているコードの中身がわからないというのは嫌なものです。あるいは、他の人のコードを理解しようとすることで頭がいっぱいになり、そうでなければ、おそらくそれを使うことはないでしょう。しかし、mql4のNative関数(例えばOrderSend())のほとんどは、私たちから見ればオブジェクトです。私たちはそのコードを見ることはできませんが、それを受け入れることができます。私は、このような他者のライブラリの受け入れは、大規模なプロジェクトに携わるプロのプログラマーが受け入れなければならないものだと考えています。そうでなければ、車輪の再作成に行き詰まるでしょう。
違いがあるんです. 私が注文をしたい場合、OrderSend()を使用する以外の選択肢はありません. 私は他の人のライブラリを使うかどうかの選択権を持っています ... ...たとえソースが尊重されていても、私はそれを使おうとする前にそれを理解しようとします