さようならロボット - こんにちはマラスムス - MQL4 and MetaTrader 4 - MQL4アルゴリズム取引フォーラム

削除済み 2014.09.22 12:22 #101

変数名の非表示について。

インテルのコンパイラについては、すでにsimpleton さんが書かれていますし、gccやclangも同じような状況です。非常に厳密なモード（メッセージの有無）でコンパイルする場合。

gcc(clang) -Wall -Wextra

の場合、コンパイラはこの問題について文句を言いません。非表示に関する苦情は、別のオプション -Wshadow で有効にします。つまり、c++コンパイラ(MSVCを除く)では、チェックそのものは難しくありません。しかし、-Wshadow がデフォルトで有効になっている ide (gcc ベース、例えば qt creator、code blocks ...) を見たことがありません。

なぜ？おそらく、ほとんどの人にとって、このメッセージの有用性は疑問だからです。

Renat Fatkhullin 2014.09.22 12:29 #102

Pavlick:

変数名の非表示について。

インテルのコンパイラについては、すでにsimpleton さんが書かれていますし、gccやclangも同じような状況です。非常に厳密なモードでコンパイルする場合（メッセージの有無に関して）。

静的解析器を使ったことがないため、誤解を招きやすい「ストリクトコンパイラモード」と実際の作業を混同しているようですね。

コンパイラは1〜2分でコンパイルが完了するが、アナライザは同じコードに数時間（PVS Studio）、数十時間（CPP Check）作業する。それゆえ、結果の質も深みもまるで違うのです。

Дмитрий 2014.09.22 15:45 #103

皆様にご挨拶申し上げます。

MQL4のイノベーションの「狂気」と「マラスムス」が止まらないまま、もうすぐ1年が経ちますね。"そして "まだある!(с).

以前は言葉遣いの悪さを「メタクォーツ」のせいにしていましたが、今は「水」が多すぎることを「メタクォーツ」のせいにしています。問題は減少していません。

私からは次のように付け加えられます。

トレーダー、ノンプログラマー、初心者プログラマーのために、簡単なアルゴリズムとコードを実装することができます。

もし、新しいビルドでコンパイルできないインデックスやフクロウなどの大規模なベースがあるのなら、よく調べて「財源を揺さぶる」ことは意味があることだと思います。最も有用なものは必ず保存し、新しいビルドのために書き直したりデバッグしたりする時間を惜しんではいけません。

本当のベテランプログラマー、あるいはプログラマーを目指す人は、常にイノベーションを追い求め、バグや不具合は彼らの糧となる。バグのないコードを書くことこそ、良いプログラミングと言えるでしょう。もし、あなたが「Metakvot」のすべての革新を把握するエネルギー、時間、可能性、欲求がないのであれば、あなたが流暢に話せる言語を使いましょう。DLLは廃止されたわけではなく、独自の微調整されたアルゴリズムをプラグインすることができます。

削除済み 2014.09.22 19:38 #104

Andrei01:

テスト環境は、ソフトウェア製品において、コード品質への要求が非常に高いソフトウェアチップ設計の機能検証のために広く利用されています。さらに、チップの設計コード開発には、機能シェルが欠かせません。それは、このようなテストをゼロから書くと、プロジェクトそのものを書くよりも時間がかかってしまい、高品質のコードを書くことが要求される場合や、同じプロジェクトに多くのバージョンがある場合にのみ正当化されるからである。一方、テスト環境をうまく構築することで、デバッグやコード検証の時間を大幅に短縮することができます。

静的解析も行われますが、非常に表面的で初期的な構文チェックとしてのみ行われます。

テスト環境はテスト環境です。テスト環境は、テストする製品に「限定」されている。

一般的なツール、つまり分析対象の製品について「何も知らない」ので、どんな製品でも分析し、問題を発見することができるツールという意味です。

削除済み 2014.09.22 20:30 #105

Renat:

単純な奴だな、何をバカなことを。

"何を馬鹿な "というのは、完全に意識の不一致を意味しているようです。

レナット：

総合的な品質管理のレベルに達して、初めて理解できるようになるのです。しかし、一方で、あなたが一人の利己的なプログラマーの認識レベルにとどまっている限り、あなたは「私をコントロールしないのが合理的だ、コントロールは別の実行されないユーティリティにさせよう」と考え続けるでしょう。

では、なぜ「総合的品質管理」は、このような低レベルの品質管理を許してしまうのでしょうか。

例えば、こんな感じです。

#property strict

/******************************************************************************/
class A {
private:
  A() { Print("A::A()"); }

public:
  static void method1() {
    //A a; // 'A::A' - cannot call private member function      3.mq4   10      7
  }

  static void method2() {
    A *a = new A; // А здесь private member function великолепно вызывается
    delete a;
  }
};

/******************************************************************************/
void OnStart() {
  A::method1();
  A::method2();
}

コンストラクタは、method2 でオブジェクトが生成されるときに呼び出されます。

00:50:23 Script 3 EURUSDm,M5: loaded successfully
00:50:23 3 EURUSDm,M5: initialized
00:50:23 3 EURUSDm,M5: A::A()
00:50:23 3 EURUSDm,M5: uninit reason 0
00:50:23 Script 3 EURUSDm,M5: removed

オブジェクトが動的に生成されるときはすべて順調、つまりオブジェクトのメソッドからプライベートコンストラクタを利用できるのに、オブジェクトが自動的に生成されると、突然プライベートコンストラクタを利用できなくなるのはなぜですか？

私自身は、MQLでシンプルより少し複雑なことをするのは、私にとって非常に難しく、いつもうまくいかないことにぶつかってしまうので、あきらめました。

しかし、C/C++コンパイラでは、そのような問題はありません。

そして、「私をコントロールしないことが合理的である、コントロールは決してユーティリティを実行しないことを別にさせる」という問題は、心理学に直接関係しています。ここでは、この心理を回避するために技術を心理に合わせようとするのではなく、プログラマーが無理なくできるように心理を修正する必要があるのです。

私が作ったわけではなく、目の前のユーティリティがうまく常用され、その結果も後でうまくバグを解消しているものもあるのです。

レナット：

不具合との戦いですが、並行して多くの追加・改善を行っています。

おそらく、品質を犠牲にして、追加・改良する方向に優先順位がシフトしているのでしょう。しかし、そうなると、もはや完全にコントロールすることはできません。

レナット：

金曜日には、実行速度とテストが明確に改善されたMT4がリリースされます。

この場合、オブジェクトを動的に生成する場合だけでなく、オブジェクトのメソッドからプライベートなコンストラクタを利用できることを意味していますが、言語の操作性の向上はあるのでしょうか？

レナット：

C++とは異なり、MQLは生リンクを拒否するため（dllに出力がない場合）絶対安全であり、一般的に - 管理された言語であることです。

よし、「C++は危険で自殺行為だ」「MQLは絶対安全だ」と仮定しよう。

なぜ、自分の望んだものから安全性の基準からかけ離れた言語をMQLのベースとするのか、つまり、「危険で自殺的」な言語をまさにベースにして「絶対安全」な言語を作ろうとするのか。

pansa 2014.09.23 05:06 #106

Pavlick:

いい？

Pavlikさん、こんにちは。

また俺だパンサだ！

スクリプトを呼び出すコードを別のmt4でテストしてみました。

そして、不思議なことがわかりました。

あなたのコードはMT4ビルド670で問題なく動作します by Pepperston

(オーストラリア)ですが、MT4 build 670 Alpariでは動作しません!

alpariでuser32.dllが変に呼ばれる!

最初の2つのDLLが呼び出される（これはコードにはなかったが！）。

とすると、user32.dll が呼び出されますが、ライブラリに投げ込まれてしまいます!

が、ライブラリから呼び出すことも必要です

アルパリは通話に苦労しているようです。

つまり、明らかなコードの干渉があるのです!

比較のために2枚の写真を添付します

成功を祈ります。

パンザ

すごいなー

MT4-Pepperstone-user32.dll

MT4-Alpari-KERNEL32.dll,GDI.dll,E:\metaQuotesTerminal﹑F.............OBO-MQL4ⒸLibrariesⒸuser32.dll

Renat Fatkhullin 2014.09.23 07:09 #107

simpleton:

"What nonsense" - これはどうやら、完全に立場の不一致を意味しているようです。

つまり、競合する市場に対して複数のソフトウェア製品のリリースを指示することに、より経験豊富な人が故意にいることを意味します。

なぜ「総合的品質管理」では、このような低レベルの品質管理が許されるのでしょうか？

一般的な品質管理の原則の議論から、特定のソリューションの具体的な欠点に移行する必要はないのです。なぜなら、どんな製品にも必ず欠陥が見つかるからです。

例えば、こんな感じです。

コンストラクタは、method2 でオブジェクトが生成されるときに呼び出されます。

オブジェクトが動的に生成されるときは、オブジェクトのメソッドから private-constructor が利用できるのに、オブジェクトが自動的に生成されると、突然 private-constructor が利用できなくなるのはなぜですか？

これは、「静的なクラスメソッドはクラスの中身に入る権利がない」という過保護の結果に過ぎません。この場合、アクセス制御を緩める必要がありますが。

私自身は、MQLでシンプルより少し複雑なことをするのはとても難しく、いつもうまくいかないことにぶつかってしまうので、あきらめています。

わざと捻じ曲げてアクセスを閉じてからボーダーラインの行動をアピールし始めた」というケースではなく、実用例を教えてください。

C/C++のコンパイラでは、そのような問題は起きないのですが。

そこでの問題は、別の種類のものだ。しかも、静的解析器を使わないことを考慮すれば、承知の上で桁違いの大きさになっている。

そして、「私をコントロールしないことが合理的である、コントロールは決してユーティリティを実行しないことを別にさせる」という問題は、心理学に直接関係しています。ここでは、この心理を回避するために技術を心理に合わせようとするのではなく、プログラマーが無理なくできるように心理を修正する必要があるのです。

私が作ったわけではなく、個々のユーティリティが目の前で正常に常用され、その結果、バグを排除するためにその後も正常に使用されているのです。

おそらく、品質を犠牲にして、追加・改良する方向に優先順位がシフトしているのでしょう。しかし、そうなると、もはや完全にコントロールすることはできません。

もう、ただの言葉遊びです。あなたの立場は、すでに先ほど「私はコントロールできない」と明確に説明されたので、そう「誰かの前では、どこかで使っているが、誰も私の上に棒を持って立っていないし、私は使っていない」のです。

また、言語の操作性の向上、この場合、動的なオブジェクト生成の場合だけでなく、オブジェクトメソッドからプライベートコンストラクタを利用できるようにすることですが、すでにあるのでしょうか？

そして、「コンストラクタをprivateで隠して、staticメソッドを作り、それを使って隠したコンストラクタにチカラを入れる」というように、「シンプルな」プログラムの中で意図的にトリップする仕掛けを作るのが好きなんですね。

よし、「C++は危険で自殺行為だ」「MQLは絶対安全だ」と仮定しよう。

なぜ、安全という基準からかけ離れた言語をMQLのベースとするのか、つまり、まさに「危険で自殺行為」の言語をベースに「絶対安全」な言語を作るのか。

一般的な言語とは「違う根拠」を打ち出せているのでしょうか？

そうすれば、他のすべてのプログラマーが、この言語を与えられ、数時間後には喜んで書き始め、嫌気がさして叱られて投げ出さないようになるのではないでしょうか？トレーダーはEasy Languageを見て捨ててしまったが、MQL4/MQL5は喜んで使われ、開発されている。

一般的に使われている言語の多くは、C/C++のようなコンストラクトの基本原則に基づいている。そこで、よく知られたフレームワークを利用し、リンクで最も危険なものを取り除き、DRMを追加し、安全でセキュアな言語を受け取りました。

その結果、私たちは上昇気流に乗り、競合他社は間違った、しかし安い方向に進んでいると、彼らは考えているのです。

削除済み 2014.09.23 20:04 #108

Renat:
つまり、競争の激しい市場で多くのソフトウェア製品のリリースを管理する経験が豊富な人がいるということです。

ところで、経営者としての経験について。5年前、mql5フォーラムでMT5の展望について議論しましたが、そのとき私は「時間が解決してくれるだろう」と言いました。5年が経過し、コミュニティがMT5を拒否したことがわかります。マネジメントの経験は、失敗を保証するものではありません。経験がある分野でも、失敗することはある。最後の最後に競合する市場、というか競争相手の話について。

しかし、この場合、多くのソフトウェア製品での経験ではなく、製品の品質、特にコンパイラと高品質を実現するためのツールや方法が問われる。

レナート
一般的な品質管理の原則から、特定のソリューションの具体的な欠陥に議論を移すべきではないでしょう。どの製品にも必ずあらゆる欠点が見つかる可能性があるから、無理なんです。

これは、「静的なクラスメソッドはクラスの中身に入る権利がない」という過保護の結果に過ぎません。この場合、アクセス制御を緩める必要がありますが。

翻訳、一般原則、理論......理論そのものではなく、実際に応用するためのものなんです。同じC/C++コンパイラでも、これほど深刻な「欠点」はないだろう。

この場合、「静的なクラスのメソッドにはクラスの中身に入り込む権利がない」というなら、なぜ動的なオブジェクト生成の場合には、すでにこの権利があるのでしょうか？

非静的なメソッドも全く同じように動作するというのはどうでしょうか？

#property strict

/******************************************************************************/
class A {
private:
  A() { Print("A::A()"); }
  ~A() { Print("A::~A()"); }

public:
  void method() { // Метод - обычный, никакой не статический
    A a;
  }

};

/******************************************************************************/
void OnStart() {
}

同じエラーです。

'3.mq4' 3.mq4   1       1
'A::~A' - cannot call private member function   3.mq4   11      7
'A::A' - cannot call private member function    3.mq4   11      7
2 error(s), 0 warning(s)                3       1

よし、「授業の中身に入り込む」ことの禁止を考えてみよう。

#property strict

/******************************************************************************/
class A {
private:
  A() { Print("A::A()"); }
  ~A() { Print("A::~A()"); }
  A(const A &a) { Print("A::A(const A &)"); }
  void operator =(const A &a) { Print("A::operator =()"); }
  void f() { Print("A::f()"); }

public:
  static void assign(A &l, const A &r) {
    l = r;
  }

  static void method() {
    A *p = new A, b(p);

    b = p;
    b.f();
    delete p;
  }

};

copyコンストラクタを呼び出してオブジェクトbを生成し、"operator ="を呼び出して代入を行い、メソッドf()を呼び出し、これらのコンストラクタ、演算子、メソッドはすべてprivateであり、静的メソッドのメソッド()は「クラスをあやす」ことが許されていることを意味しています。

00:59:18 Script 3 EURUSDm,M5: loaded successfully
00:59:18 3 EURUSDm,M5: initialized
00:59:18 3 EURUSDm,M5: A::A()
00:59:18 3 EURUSDm,M5: A::A(const A &)
00:59:18 3 EURUSDm,M5: A::operator =()
00:59:18 3 EURUSDm,M5: A::f()
00:59:18 3 EURUSDm,M5: A::~A()
00:59:18 3 EURUSDm,M5: A::~A()
00:59:18 3 EURUSDm,M5: uninit reason 0
00:59:18 Script 3 EURUSDm,M5: removed

もう一つ、最初の例と非常に近い例を見てみましょう。

#property strict

/******************************************************************************/
class A {
private:
  A(int i = 0) { Print("A::A(int i = ", i, ")"); }
  ~A() { Print("A::~A()"); }
public:

  static void method() {
    A a;
  }
};

/******************************************************************************/
void OnStart() {
  A::method();
}

コンパイルエラー - コンストラクタとデストラクタの両方が使用できません。

'3.mq4' 3.mq4   1       1
'A::~A' - cannot call private member function   3.mq4   11      7
'A::A' - cannot call private member function    3.mq4   11      7
2 error(s), 0 warning(s)                3       1

ここで、全く何も変えずに、コンストラクタでデフォルト値とは異なる値でa変数を初期化します。

#property strict

/******************************************************************************/
class A {
private:
  A(int i = 0) { Print("A::A(int i = ", i, ")"); }
  ~A() { Print("A::~A()"); }
public:

  static void method() {
    A a(1);
  }
};

/******************************************************************************/
void OnStart() {
  A::method();
}

これで、サンプルがコンパイルされて実行されるようになりました。

00:20:35 Script 3 EURUSDm,M5: loaded successfully
00:20:35 3 EURUSDm,M5: initialized
00:20:35 3 EURUSDm,M5: A::A(int i = 1)
00:20:35 3 EURUSDm,M5: A::~A()
00:20:35 3 EURUSDm,M5: uninit reason 0
00:20:35 Script 3 EURUSDm,M5: removed

スタティックなメソッドが、なぜ突然「クラスの中身に入り込む」ことが許されるようになったのでしょうか？

この場合、「過剰保護」ではなく、些細なバグであることは一目瞭然です。トータル・クオリティ・コントロールとは、かなりうるさい言い方だが、事実は頑固なものである。

レナート
わざとそうやって捻じ曲げて、アクセスを閉じて、境界の振る舞いをアピールし始めた」というケースではなく、実用例を挙げてください。

古典的なシングルトン、すなわちリンク先のC++の例のセクションで説明されているMyersのシングルトンをお願いします。

class OnlyOne
{
public:
        static const OnlyOne& Instance()
        {
                static OnlyOne theSingleInstance;
                return theSingleInstance;
        }
private:        
        OnlyOne(){};
        OnlyOne(const OnlyOne& root);
        OnlyOne& operator=(const OnlyOne&);
};

新たにオープンした機能でMQL4++への翻訳も可能です。

#property strict

/******************************************************************************/
class OnlyOne
{
public:
        static OnlyOne *Instance()
        {
                static OnlyOne theSingleInstance(1);
                return GetPointer(theSingleInstance);
        }
private:        
        OnlyOne(int i = 0) { Print("Создан"); };
        ~OnlyOne() { Print("Уничтожен"); };
        OnlyOne(const OnlyOne &);
        void operator=(const OnlyOne &);
};

/******************************************************************************/
void OnStart() {
  OnlyOne *p = OnlyOne::Instance();
}

コンパイルして実行する。

01:31:49 Script 3 EURUSDm,M5: loaded successfully
01:31:49 3 EURUSDm,M5: Создан
01:31:49 3 EURUSDm,M5: initialized
01:31:49 3 EURUSDm,M5: uninit reason 0
01:31:49 3 EURUSDm,M5: Уничтожен
01:31:49 Script 3 EURUSDm,M5: removed

OnlyOne::Instance() を呼び出す以外の方法でオブジェクトを作成しようとすると、コンパイルエラーになります。

また、「物事を意図的に捻じ曲げ、アクセスを閉じ、そして境界行動を訴え始めた」という件ですが、何か不適切な使い方をされたのでしょうか？

言語にはメカニズムがある。言語が許容する範囲内で、私にはそれを好きに使う権利がある。少なくとも、C++コンパイラではそうなっている。

言語の実装に誤りがあれば、まあ、そうですね、誤りです。MQL4+コンパイラは、C++コンパイラと同じようにエラーを見つけにくくするために、実装上のミスをなくすような工夫をしています。私は、パーサーが、私が実証したようなエラーを取り除くのに役立たないと今でも思っています。

レナート
また、「コンストラクタをprivateに隠し、staticメソッドを作成し、そこから隠されたコンストラクタにチッソをかける」という意図的な足跡を「シンプル」なプログラムに入れることが好きなのでしょうか？

好き嫌いの問題じゃないんです。道具がある。なぜ、その機能をすべて使うことを拒まなければならないのか。

この場合、「好き」でもないんです。もっとも、そんなに好きなのはマイヤーズなんですけどね。そして、なぜか誰も、C++コンパイラを「意図的に陥れようとした」と非難しようとしない。

レナート
汎用的な言語に対して、「別の枠組み」を思いつくことができるのか。

そうすれば、他のすべてのプログラマーが、ある言語を与えられて、数時間後には喜んでその言語で書き始め、嫌悪感やお叱りを受けて投げ出すようなことはなくなるのではないでしょうか？トレーダーはイージーランゲージを見て捨ててしまったが、MQL4/MQL5は喜んで使われ、開発されている。

広く普及している言語の多くは、C/C++のようなコンストラクトの基本原則に基づいている。そこで、使い慣れたフレームワークを使い、リファレンスで最も危険なものを取り除き、DRMを追加し、セキュアで安全な言語を手に入れたのです。

その結果、私たちはトップに立ち、競合他社は間違った方向へ、しかし安く、と考えているような状態です。

簡単なことではありませんし、すぐに解決できるものではありません。ここで、小さな努力ではなく、ある程度の努力をしなければなりません。MQLユーザーの大半はプログラマーではありません。このことを考慮して、言語設計を行う必要があります。でも、この課題は解決できるはずです。

どちらかというと、MQL4+で行われたように、古いMQL4にいくつかの構造を追加して、操作に対する優先順位などをきれいにすれば十分で、それが妥当な妥協点でしょう。MT4の成功は、言語に「賢さ」がなかったことが大きな要因です。今はそうではありません。また、MQL4+は昔のMQL4よりもずっと複雑で、開発チームもほとんど変わっていないため、コンパイラの実装のミスもずっと多い。

レナート
その結果、競合他社が間違った方向に進んでいるのに対し、私たちは上昇気流に乗っていますが、彼らが信じているように、より安いのです。

ここからは同感ですが、主に競合他社がわけのわからないことをやっているからだと思います。

pansa 2014.09.24 05:20 #109

Renat:
つまり、競合する市場への多くのソフトウェア製品のリリースを指示する経験が、故意に豊富な人がいるということです。

一般的な品質管理の原則の議論から、特定のソリューションの具体的な欠陥の議論に話題を移す必要はないのです。なぜなら、どんな製品にも必ず欠陥が見つかるからです。

これは、「静的なクラスメソッドには、クラスの中身に入り込む権利はない」という過保護の結果に過ぎないのです。この場合、アクセス制御を緩める必要がありますが。

わざと全部ひねって、アクセスをロックして、境界動作のアピールを始めた」なんてケースではなく、実用例を教えてください。

そこでの問題は、別の種類のものだ。しかも、静的解析器を使わないことを考慮すれば、承知の上で桁違いの大きさになっているのです。

これはもう言葉遊びでしかないですね。あなたの立場は、先ほどから「コントロールできない」とはっきり言われていますが、そう「誰かの前で、どこかで使っていても、誰も棒を持って私の上に立っていないし、使っていない」のです。

コンストラクタをprivateに隠して、staticメソッドを作り、そこから隠されたコンストラクタをチッソする」という意図的な足跡を「単純な」プログラムに入れるのが好きなのでしょうか？

コモンプラン語の「違う根拠」を思いつくことができるのか？

そうすれば、他のすべてのプログラマーが、ある言語を与えられて、数時間後には喜んでその言語で書き始め、嫌気がさして叱られて投げ出さないようになるのではないでしょうか？トレーダーはイージーランゲージを見て捨ててしまったが、MQL4/MQL5は喜んで使われ、開発されている。

広く普及している言語の多くは、C/C++のような構築の基本原則に基づいている。そこで、よく知られたフレームワークを利用し、リンクで最も危険なものを取り除き、DRMを追加して、安全でセキュアな言語を手に入れました。

その結果、私たちはトップに立ち、競合他社は間違った方向へ、しかし安く、と考えているような状態です。

pansa 2014.09.24 05:21 #110

フォーラムの皆さん、こんにちは。

このスレッドにレナーテがいることを利用したい

MT4を改善するための提案をしたい!

MT4は時間が経つとどんどん動作が悪くなるのは誰でも知っていることです。

を実行すると、マウスに従わなくなります。

新しいMT4に移行して、削除する必要があります。

あらゆるもの（インジケータ、エックスパート）を!

これは1日がかりの仕事です!

今はDLL、Dreverなどの修復プログラムがありますが・・・。

MT4用のコンパイラを作ったらどうですか？

2つのМТ4（1つは有効、もう1つは有効）が必要です。

と定期的に比較し、稼働中のMT4でエラーを修正します。

2つ目の提案は、価格チャートだけでなく

価格と数量を掛け合わせた成長グラフを作成

そうすれば、何が起こっているのか（実際の取引や現金化）がすぐにわかります。

碑文）

理解度の高い人には簡単だと思います。

パンザ

さようならロボット - こんにちはマラスムス - ページ 11