MQL5ではOOPは需要になるのでしょうか? - ページ 6 123456789 新しいコメント Hide 2009.09.27 09:13 #51 なんならインタプリタであるBASICにもOOPはある。 インジケーターやExpert Advisor、スクリプトなどでOOPがどれだけ需要になるか、様子を見る必要がありそうですね。そして、実際にどうなのかを判断するために、事実に基づいて。 TheXpert 2009.09.27 09:35 #52 HideYourRichess писал(а) >> インジケーターやEA、スクリプトでOOPがどれだけ需要になるかは、もう少し様子を見た方がいいと思います。そして、実際にどう動くかを決める。 今のところ、インジケータでデータバッファのコピーを全て自動化しようとしています。リファレンスがない、パラメータ付きのコンストラクタ(RAIIは実現不可能)など、いつも問題に直面し、大変な作業です。 それに似たようなものが付いていても満足できないんです。そんなことはありません。 C-4 さんが書き込みました >>1 Z.U. ほとんどの人は、OOPというと特定のプログラミング言語であるC++を連想します。 なぜかというと、実装が悪いのです。なかなか良い実装だと思います。他の普通のオブジェクト指向言語と同じように。 MQ5はOOPです。 しかし、機能的には貧弱です。 C言語でもOOPは存在するのですが、なぜか知らない人が多く、これも表面的な知識の話になってしまいます。 この点について、もう少し詳しく説明してください。 Hide 2009.09.27 09:39 #53 TheXpert >> : 今、インジケータに付随する全てのバッファデータのコピーを自動化しようとしています。難しくなってきた、複雑になってきた、リファレンスがない、パラメータ付きのコンストラクタ(RAIIは実現不可能)など、常に壁にぶつかっている状態です。 それに似たようなものが付いていても満足できないんです。そんなことはありません。 実を言うと、私もそれを試してみたんです。特別なことは何もなく、ただぼんやりとしたものでした。何もいいことないって諦めたよ。私がたくさん再トレーニングする必要があるか、OOPを拡張する必要があるかのどちらかです。どちらもまだ期待できません。一般的に、私はレーキを越えて、私はこのような愚か者であるか、または技術サポートにチケットを送信する必要があります理解していない、 - 私は当分の間、すべてをあきらめた。 Vasiliy Sokolov 2009.09.27 11:08 #54 お願いします、詳しく説明します。 INCAPSULATION: struct mail { int zipcode; char adr[50]; char comment[10]; ... } 構造物が存在するだけで、無防備なカプセル化になってしまう静的ポリモーフィズム。 double d=3.12, c; int i=5; c=d+i; (異なるデータ型は同じ演算子で合計される)動的ポリモーフィズム void qsort(void *buf, size_t st, size_t s,int (*compare) (const void *, const void *)); qsort 関数は、比較サブ関数 の種類によって、異なる挙動をします。インクリプレーション 動的ポリモーフィズムと同じ例で、この場合、qsort 関数はcompare()の性質を 受け継いでいるようなものです。 Will OOP be in MetaTrader拡張モジュール(DLL)の作成 名前付き定数 - 定義済みマクロ代入 TheXpert 2009.09.27 11:22 #55 C-4 >> : お願いします、詳しく説明します。 こんなのを期待してたんだ。静的ポリモーフィズムのみカウントされます。このテーマ(OOP in C)で議論を続けることに意味はないと思うので、やめます。 本当に驚かせてくれると思っていました。 Vasiliy Sokolov 2009.09.27 11:42 #56 関数などの 古典的なオーバーロードの ようなものを見たい場合は、LCCなどの最新のCコンパイラをダウンロードして調べてみてください。例えばLCCは、規格外ではあるが、古典的なOOPをサポートしている。 Петр 2009.09.27 13:29 #57 非常に予備的な結果をまとめると、メタクォートの実装におけるOOPは、経験豊富なプログラマーにさえ受け入れられていない、と言えるでしょう。おそらく、実装のせいでしょう。慣れてくれば、本当にOOPが便利になるのかもしれません。しかし、今のところ、私たちは持っているものを持っています。ない方が便利なようです。つまり、書くことはできるだろうが、OOPのためだけで、使い勝手や書くスピードはもちろんのこと、コード自体のパフォーマンスも、PPに対してはとにかく遅くなるのである。 そんなこんなで...。 Sergey Kravchuk 2009.09.27 16:47 #58 私にとっては、トレーダーやプログラマーの作業を容易にする新しい取引機能やサービス機能がどのように登場し、それがどのように実装されるかの方がはるかに重要です。 MQL5がOOP標準に準拠しているという証明書を少なくとも10枚見せてくれればいいのですが、インジケータによる オブジェクトの作成がなければ、どんなOOPも画面に単純なテキストを表示する複雑さからあなたを救ってはくれないでしょう。このチャートオブジェクトで一般的なリストホイールさえ使えないのでは、OOPの誇らしい使い方とは言えないでしょう。 チェックボックスとして機能するボタン、標準のコンボボックスがないため、例えばExpert Advisorでは計算のためにタイムフレームを選択するだけでよく、複数のオブジェクトを1つにグループ化できる。 自動売買のために開発したプラットフォームなので、対話フォームのエディターの話でもないのですが...。:( IMHO: MQL5では、古典的なOOPに内在する可能性を(かなり)切り詰めたものしか存在しません。開発者の方々は素晴らしい仕事をされ、確かにソースコードを書くのは簡単ですが、それはすべて無駄なことで、私はまだタクシーが欲しいのです。) Петр 2009.09.27 17:49 #59 ForexTools >> : しかし、OOPの需要はそれほど重要なのでしょうか? 私にとっては、トレーダーやプログラマーの仕事を容易にする新しい取引機能やサービス機能がどのように登場し、それらがどれだけうまく/完全に実装されるかの方がずっと重要なことなのです。 はい、もちろんです。そして、このことについては、該当スレッドでいろいろと語られています。例えば、三菱商事は古い問題を解決するのではなく、イノベーションによってその解決をより複雑にしてきたとしか思えないのです。 今、OOPの話はしていないんです。しかし、この機能に費やしたエネルギーは、実際に役に立つもの、需要のあるものに使うことができた可能性が非常に高いのです。 Hide 2009.09.28 04:09 #60 Svinozavr >> : はい、もちろんです。そして、関連スレッドでいろいろと語られています。例えば、三菱商事は旧来の問題を整理するのではなく、革新的な技術で解決を複雑にしているようにしか見えません。 今のPLOのことではありません。しかし、この機会に費やしたエネルギーを、本当に役に立つこと、需要のあることに使うことは十分可能でしょう。 本当に単純な質問ではないですね。実際、そうなんです。サーバーの設計変更は見当たりません。インターネット上の大雑把な情報によると、涼しくなっているそうです。確かに私たち、DTには向かないものばかりですが、逆にサービスが向上するかもしれませんね、一般的には。 123456789 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
なんならインタプリタであるBASICにもOOPはある。
インジケーターやExpert Advisor、スクリプトなどでOOPがどれだけ需要になるか、様子を見る必要がありそうですね。そして、実際にどうなのかを判断するために、事実に基づいて。
HideYourRichess писал(а) >>
インジケーターやEA、スクリプトでOOPがどれだけ需要になるかは、もう少し様子を見た方がいいと思います。そして、実際にどう動くかを決める。
今のところ、インジケータでデータバッファのコピーを全て自動化しようとしています。リファレンスがない、パラメータ付きのコンストラクタ(RAIIは実現不可能)など、いつも問題に直面し、大変な作業です。
それに似たようなものが付いていても満足できないんです。そんなことはありません。
C-4 さんが書き込みました >>1
Z.U. ほとんどの人は、OOPというと特定のプログラミング言語であるC++を連想します。
なぜかというと、実装が悪いのです。なかなか良い実装だと思います。他の普通のオブジェクト指向言語と同じように。
MQ5はOOPです。
しかし、機能的には貧弱です。
C言語でもOOPは存在するのですが、なぜか知らない人が多く、これも表面的な知識の話になってしまいます。
この点について、もう少し詳しく説明してください。
今、インジケータに付随する全てのバッファデータのコピーを自動化しようとしています。難しくなってきた、複雑になってきた、リファレンスがない、パラメータ付きのコンストラクタ(RAIIは実現不可能)など、常に壁にぶつかっている状態です。
それに似たようなものが付いていても満足できないんです。そんなことはありません。
実を言うと、私もそれを試してみたんです。特別なことは何もなく、ただぼんやりとしたものでした。何もいいことないって諦めたよ。私がたくさん再トレーニングする必要があるか、OOPを拡張する必要があるかのどちらかです。どちらもまだ期待できません。一般的に、私はレーキを越えて、私はこのような愚か者であるか、または技術サポートにチケットを送信する必要があります理解していない、 - 私は当分の間、すべてをあきらめた。
お願いします、詳しく説明します。
INCAPSULATION:
struct mail
{
int zipcode;
char adr[50];
char comment[10];
...
}
静的ポリモーフィズム。
double d=3.12, c;
int i=5;
c=d+i;
動的ポリモーフィズム
void qsort(void *buf, size_t st, size_t s,int (*compare) (const void *, const void *));
インクリプレーション
動的ポリモーフィズムと同じ例で、この場合、qsort 関数はcompare()の性質を 受け継いでいるようなものです。
お願いします、詳しく説明します。
こんなのを期待してたんだ。静的ポリモーフィズムのみカウントされます。このテーマ(OOP in C)で議論を続けることに意味はないと思うので、やめます。
本当に驚かせてくれると思っていました。
非常に予備的な結果をまとめると、メタクォートの実装におけるOOPは、経験豊富なプログラマーにさえ受け入れられていない、と言えるでしょう。おそらく、実装のせいでしょう。慣れてくれば、本当にOOPが便利になるのかもしれません。しかし、今のところ、私たちは持っているものを持っています。ない方が便利なようです。つまり、書くことはできるだろうが、OOPのためだけで、使い勝手や書くスピードはもちろんのこと、コード自体のパフォーマンスも、PPに対してはとにかく遅くなるのである。
そんなこんなで...。
私にとっては、トレーダーやプログラマーの作業を容易にする新しい取引機能やサービス機能がどのように登場し、それがどのように実装されるかの方がはるかに重要です。
MQL5がOOP標準に準拠しているという証明書を少なくとも10枚見せてくれればいいのですが、インジケータによる オブジェクトの作成がなければ、どんなOOPも画面に単純なテキストを表示する複雑さからあなたを救ってはくれないでしょう。このチャートオブジェクトで一般的なリストホイールさえ使えないのでは、OOPの誇らしい使い方とは言えないでしょう。 チェックボックスとして機能するボタン、標準のコンボボックスがないため、例えばExpert Advisorでは計算のためにタイムフレームを選択するだけでよく、複数のオブジェクトを1つにグループ化できる。 自動売買のために開発したプラットフォームなので、対話フォームのエディターの話でもないのですが...。:(
IMHO: MQL5では、古典的なOOPに内在する可能性を(かなり)切り詰めたものしか存在しません。開発者の方々は素晴らしい仕事をされ、確かにソースコードを書くのは簡単ですが、それはすべて無駄なことで、私はまだタクシーが欲しいのです。)
しかし、OOPの需要はそれほど重要なのでしょうか? 私にとっては、トレーダーやプログラマーの仕事を容易にする新しい取引機能やサービス機能がどのように登場し、それらがどれだけうまく/完全に実装されるかの方がずっと重要なことなのです。
はい、もちろんです。そして、このことについては、該当スレッドでいろいろと語られています。例えば、三菱商事は古い問題を解決するのではなく、イノベーションによってその解決をより複雑にしてきたとしか思えないのです。
今、OOPの話はしていないんです。しかし、この機能に費やしたエネルギーは、実際に役に立つもの、需要のあるものに使うことができた可能性が非常に高いのです。
はい、もちろんです。そして、関連スレッドでいろいろと語られています。例えば、三菱商事は旧来の問題を整理するのではなく、革新的な技術で解決を複雑にしているようにしか見えません。
今のPLOのことではありません。しかし、この機会に費やしたエネルギーを、本当に役に立つこと、需要のあることに使うことは十分可能でしょう。
本当に単純な質問ではないですね。実際、そうなんです。サーバーの設計変更は見当たりません。インターネット上の大雑把な情報によると、涼しくなっているそうです。確かに私たち、DTには向かないものばかりですが、逆にサービスが向上するかもしれませんね、一般的には。