/******************************************************************************/class A {
private:
class B { };
};
/******************************************************************************/voidOnStart() {
A a;
B b;
}
これはエラーなくコンパイルされます。
'3.mq4' 3.mq4 1 1
0 error(s), 0 warning(s) 1 1
しかし、このコードは2つの理由でC++ではコンパイルできないことがわかります。
$ clang -c 3.cpp
3.cpp:10:3: error: unknown type name 'B'
B b;
^
1 error generated.
ところで、経営者としての経験について。5年前、mql5フォーラムでMT5の展望について議論しましたが、そのとき私は「時間が解決してくれるだろう」と言いました。5年が経過し、コミュニティがMT5を拒否したことがわかります。
翻訳、一般原則、理論、-理論そのものではなく、実践での応用のためです。同じC/C++コンパイラでも、これほど深刻な「欠点」はないだろう。
この場合、「静的なクラスのメソッドにはクラスの中身に入り込む権利がない」というなら、なぜ動的なオブジェクト生成の場合には、すでにその権利があるのでしょうか？
過保護だ、直そう」と言ったのです。理論的には簡単な条件ですが、実際にはスタティック／ダイナミックの実装が異なるため、矛盾が生じます。
静的でない実装が全く同じ動作をするのはどうなんでしょう？
そうなんです、自分たちで一から書いたコンパイラのエラーやミスなんです。これが通常の熊手の集め方なんですね。
総合的品質管理とは、バグを発見することに明確に焦点を当て、体系的に取り組むことである。それこそが、私たちの仕事です。それに対してあなたは、強制には反対で、技術的な手段による厳密なコントロールは望んでいないと述べています。
好き嫌いの問題ではありません。道具がある。なぜ、その可能性をすべて拒まなければならないのか。
この場合、「好き」ということですらありません。もっとも、そんなに好きなのはマイヤーズなんですけどね。そしてなぜか誰も、C++コンパイラを「わざと陥れようとした」と非難しようとはしない。
すぐに解決できるような簡単なことではありません。ここで、小さな努力ではなく、ある程度の努力をしなければなりません。MQLユーザーの大半はプログラマーではありません。そして、このことは言語設計において考慮されなければならない。でも、この課題は解決できるはずです。
どちらかというと、MQL4+で行われたように、古いMQL4にいくつかの構造を追加して、操作に対する優先順位などをきれいにすれば十分で、それが妥当な妥協点でしょう。MT4の成功は、言語に「賢さ」がなかったことが大きな要因です。今はそうではありません。また、MQL4+は昔のMQL4よりもずっと複雑で、開発チームもほとんど変わっていないため、コンパイラの実装に誤りがあることが多くなっています。
ここは私も同感ですが、競合他社が理解できないことをやっているのが主な原因だと思います。
私たちは、この14年間に5つの取引プラットフォームを一から書き直しました。
古いロバにホバーレンガを積むより、本当にかっこいいものを作るには、この方法がいいんです。ですから、MT5のリリースも、新しいMQL5も、これからさらに10年先の大きな未来を私たちに与えてくれたのです。
しかし、「手に鳥を持たせて、要は新しいプロジェクトを始めて失敗してもクビにならないように」と考えて、居座り、古いプロジェクトを積み重ねて いる人は、経営者の尊敬を失い、非力と書かれて、徐々に現場から去っていくのです。
情報が不足しているのですね。私たちは、自分の顧客基盤や導入事例を宣伝することはありません。
前バージョン、つまりMT4の公開情報とサポートで判断しています。
MT4が登場したとき、MT3はあっという間にサポートや提供を終了し、みんなMT4に乗り換えました。MT4とMT5のペアでは、かなり時間が経過しているにもかかわらず、このようなことは起こりませんでした。そして、まだMT4に明らかに偏っています。
MT5からMT4への移植もコンパイラを含めて行っていますね。MT4からMT3へ、発売から4年経って何か移植したのでしょうか？
そして、彼らはそれを実行し、著者に報告までしてくれました。
しかし、現代のC/C++コンパイラでは、MQL4+よりも数百倍、いや数千倍もエラーを見つけるのが難しいという違いがあるのです。
昔は「過保護、直そう」と言っていたんですけどね。理論的には簡単な条件ですが、実際にはスタティック／ダイナミックの実装が異なるため、矛盾が生じます。
同じことです。"private means private" というルールが "make exception for constructor/destructor" というルールに優先してしまいます。 修正いたします。
そうなんです、自分たちで一から書いたコンパイラのバグや不整合なんです。これが通常の熊手拾いのやり方なんですね。
総合的品質管理とは、バグを発見することに明確に焦点を当て、体系的に取り組むことである。それこそ、私たちの仕事です。
特別な「エンジン」を必要としない、通常のリグレッションテストを適用するだけで十分なのです。言語内のクラス/構造体にアクセス制御がある - コンパイル可能なMQLプログラムの形でそのためのテストを一度書いてみてください。あるものは正常にコンパイルされるはずですし、あるものはある種のエラーでコンパイルされるはずです。それが、この特別な場所でのトータルな品質管理なのです。たしかに、アクセスコントロールの機能をすべて網羅するようなテストを先に書かなければなりませんね...。
これに対して、あなたは強制に反対で、技術的な手段による厳密なコントロールを望まない、と言っていますね。
その逆ではありません。MQLプログラム用のMQLコンパイラーは、デフォルトで警告と一部のC++コンパイラーがリマークと呼ぶものの両方を含むようにすることができます。しかし、私は少なくとも発言は無効化すべきと「述べている」だけです。MQLプログラム用のMQLコンパイラで。そして現在、MQL4+コンパイラでは、この意味で無効化できるものはありません。
特にMQLコンパイラは間違いが発見されやすいので、実装時の品質管理も不十分です。MQLプログラムの厳格な品質管理とはどういうことですか？
「これはC++言語ではなく、MQL4/MQL5に特化したものです」という説明をしています。したがって、そのすべてをサポートする義務はない」。しかし、いずれにせよ、動作はできる限り使い慣れたC/C++に落とし込む。
素晴らしい。すべてをサポートするわけではないんですね。しかし、サポートされるものは、最も単純な基本構成にそれほど多くの誤りを含んでいてはならないのです。
クラス/構造体メンバへのアクセス 制御をサポートしていますか？最も単純な基本構成で、少なくともすべての基本ケースを誤りなくサポートすること。
同じアクセス制御を、最もシンプルな基本構成で考えてみましょう。
これはエラーなくコンパイルされます。
しかし、このコードは2つの理由でC++ではコンパイルできないことがわかります。
クラスBはクラスAの内部で定義されているので、OnStart()ではA::Bとして参照されるはずです。
しかし、それだけではありません。修正したコードは、まだC++コンパイラーでコンパイルできません。
MQL4+のアクセス制御は、一般的にメソッドとデータ、つまりクラスのメンバーに対しては機能しますが、タイプに対してはなぜか機能しません。
BクラスのスコープをA::Bと指定した場合、MQL4++コンパイラで以下のエラーが発生します。
なぜこの「構造体メンバが未定義」なのですか？
繰り返しますが、C++コンパイラは、クラス内の型についても、何らかの問題を抱えているわけではありません。しかし、MQL4+コンパイラはそうなっています。
これらのエラーは、Myers singletonを実装しようとしたときに偶然発見されたものです。私が発見したエラーもあれば、他のディスカッション参加者が発見したエラーもあります。MQL4+でプログラミングする際に、いかにコンパイラの実装エラーにつまずきやすいかを示しています。また、意図的にエラーを探さなければ躓くこともなく、ただ課題を解いてみるだけでいいのです。
これらはすべて、MQL4+を真剣に使用するための致命的なエラーであることに注意してください。
当然ながら、少なくともMQL4+コンパイラが動作するかどうかを確認するための単純なアクセス制御については、上に述べたようなタイプのリグレッションテストはありません。そうでなければ、今頃はすべて検出され、修正されているはずです。
私たちはこの14年間で、5つの取引プラットフォームを一から書き直したことがあります。
その方が、古いロバにホバーレンガを積むよりも、本当にクールなものを作ることができるのです。だからこそ、MT5のリリースも、新しいMQL5のリリースも、これからさらに10年先の大きな未来を感じさせてくれたのです。
しかし、「手に鳥を持たせて、要は新しいプロジェクトを始めて失敗してもクビにならないように」と考えて、古いプロジェクトに腰を据えて打ち込んでいる人は、経営者の尊敬を失い、非力と書かれて、徐々に現場から離れていくのである。
革新的なタイプの開発で積極的に行動することが最も重要な要素であることは同意しますが、それだけではありません。そして、蜜柑の樽もハエがいれば台無しになるのです。
そのような色合いのひとつに、明らかに質の低さがあります。MQLで何かを作る理由は、そのせいで失われてしまうのです。
私はSSE2について、多分テーマではなく、また喜びで、何かを聴いた。
パソコンの1台を変えなければならない、全部ではないが、開発のためでもなく、取引のためでもなく、掲示板を読む以外に話題が散漫になるのだ。
フォーラムユーザーの皆様、こんにちは。
mt5にアップグレードして、次のことをしたいです。
をパブリクに聞く。
パブリック、見かけたらメッセージください。
r.klassen.ruit@web.de
パンサー
もし、新しいビルドでコンパイルされない耽溺やフクロウなどの大規模なベースがあるならば、よく見て「胸を揺さぶる」ことに意味があるのです。有用なものはすべて残し、新しいビルドのために書き直したりデバッグしたりする時間を惜しんではいけません。
ある瞬間、飽きた）。
真のベテランプログラマー、あるいはプログラマーを目指す人は、常にイノベーション、バグ、グリッチを自分の糧にしています。バグのないコードを書くことこそ、良いプログラミングと言えるでしょう。もし、あなたが「Metakvot」のすべての革新を把握するエネルギー、時間、可能性、欲求がないのであれば、あなたが流暢に話せる言語を使いましょう。DLLは廃止されたわけではなく、独自の微調整されたアルゴリズムをプラグインすることができます。
本物のトレーダー、あるいはトレーダーを目指す人たちは、どのようなことを実践しているのでしょうか。MTの主な機能であるオートトレードは、忘却の彼方に沈み、無数のビルドの絶え間ない革新の中で失われてしまった...プログラミングへのより真剣なアプローチによって利用できるオートトレードのオプションは、言ってみれば - "です。 私自身はMTに小さな事実上忘れられたアカウントしか持っていないのです。今日、MTツールのリハビリに2時間費やしましたが、見たところ、あと10倍は必要そうです。必要かどうかわからない、もしかしたらまたやるかもしれない、というより「昔の記憶から」という感じです。基本的に、私は決心しています。
MTの最大の特徴である自動売買は、忘却の彼方に沈み、無数のビルドの絶え間ない革新の中に紛れ込んでしまいました... プログラムへのより真剣なアプローチによって利用できる自動売買オプションは、言うなれば「ある」のです。 私自身、MTには事実上忘れられた小さな口座だけが残されています。今日、MTツールのリハビリに2時間費やしましたが、見たところ、あと10倍は必要そうです。必要かどうかわからない、もしかしたらまたやるかもしれない、というより「昔の記憶から」という感じです。基本的に、私は決心しています。
いつの間にか飽きてしまった)
誰かのせいでクソみたいなコードになってるのは誰のせいだ？
Figar0:
基本的に、私は決心しています。誰かが我慢しているのでしょうか？投げ縄で固定？
誰のせいで、誰かがクソみたいなコードを持っているんだ？
クソコードがどうしたって？いくつかの基本的なことが変わりました