mql5におけるOOP、テンプレート、マクロ、微妙な使い分け - ページ 12 1...5678910111213141516171819...28 新しいコメント Ilya Malev 2019.01.25 21:08 #111 Alexey Navoykov: でも、抽象的なメソッドについては考えておくべきです。 それがないと、すべてが非常に信頼できないものに見えてしまいます。私は、明示的な型付けを一切しない、そういうサブ言語の方向で考えています。実行時のみ。この種のアーキテクチャをうまくチューニングすれば、エラーになることはないと思うのですが。 Алексей Тарабанов 2019.01.25 21:18 #112 この種のアーキテクチャをうまくチューニングすれば、エラーが発生することはないと思っています。それはどういうことですか？ Ilya Malev 2019.01.25 21:19 #113 Алексей Тарабанов:この種のアーキテクチャをうまくチューニングすれば、エラーが発生することはないと思っています。それはどういうことですか？これは、ランタイムエラーは 良いプログラムデバッグのためのベンチマークとしてはあまりにも信頼性が低いという同志の懸念についてです Alexey Navoykov 2019.01.25 21:30 #114 Ilya Malev:私は、明示的な型付けを一切しない、そういうサブ言語の方向で考えています。実行時のみ。この種のアーキテクチャをうまくチューニングすれば、エラーになることはないと思います。 そうですね、間違っていますね。類型化の不在は悪である。もちろん、そうでない言語もありますが、これは避けるべきものであって、目指すべきものではありません。 コンパイラが悪態をつけばつくほど、それは正しい道を歩んでいることを意味します。 Алексей Тарабанов 2019.01.25 21:32 #115 Ilya Malev:これは、ランタイムエラーが 品質の高いプログラムデバッグのためのベンチマークとしてあまりにも信頼性に欠ける、という同志の懸念についてですイリヤ、デバッグするものがあれば...。 Ilya Malev 2019.01.26 03:43 #116 Alexey Navoykov: しかし、これは無益な指摘です。タイピング不足は悪である。コンパイラが悪態をつけばつくほど、それは正しい道を歩んでいるということなのです。私たちはここで軌道制御ステーションを書いているのではなく、単純で、ステレオタイプで、定型的なソリューションを書いているのであり、お互いにほとんど違いはありません。その中で、厳密な型式管理を行わず、最大限の利便性を追求したことは、まさにドクターの指示通りです。各種ニューラルネットワークやGPUの演算支援のファンの方は安心してください。最高のパフォーマンスを追求する熟練者も同様です。 Alexey Navoykov 2019.01.26 10:45 #117 Ilya Malev:その中で、厳格な型式管理を行わず、最大限の利便性を追求したことは、まさにドクターの指示通りですところで、MQLはすでにポインタの型チェックを欠いており、ベースポインタが暗黙のうちに派生ポインタにキャストされてしまいますが、これは起こってはならないことです。 Philipp Negreshniy 2019.01.26 11:59 #118 Ilya Malev:私たちはここで軌道制御ステーションを書いているのではなく、単純で、ステレオタイプで、定型的なソリューションを書いているのであり、お互いにほとんど違いはありません。その中で、厳密な型式管理を行わず、最大限の利便性を追求したことは、まさにドクターの指示通りです。各種ニューラルネットワークやGPUの演算支援のファンの方は安心してください。最大生産性の熟練者たちも同様です。 問題は型付けそのものにあるのではなく、その表現方法と、ニューラルネットワークやGPUなどを使った複雑なプロジェクトの 見通しにある。Pythonのような動的型付けを持つ言語は、明らかなプログラミングの困難さはなく、一方、Cのような静的型付けとコンパイラの頭痛を持つ言語は、オールドボーイズ、すなわち年金生活者の中に残るだろう) Alexey Navoykov 2019.01.26 12:38 #119 Philipp Negreshniy: Pythonのような動的型付けを持つ言語では、ニューラルネットワークやGPUなどを使った複雑なプロジェクトが想定され、明示的なプログラミングの困難さがないこと。 このような言語は、実際にはシェルに過ぎず、通常のプログラミング言語で書かれた何らかのコードを呼び出しているに過ぎないのです。 Philipp Negreshniy 2019.01.26 13:12 #120 Alexey Navoykov: このような言語は、基本的にシェルであり、通常のプログラミング言語で書かれた何らかのコードを呼び出しているに過ぎないのです。 私はただ、このブランチとサイトが対象としている、普通の、応用的なプログラマーとプログラムについて言いたかっただけで、言語を書く人たち、システムの人たちのことですね、ここでは何かをハックする以外は何もすることはないようです) 1...5678910111213141516171819...28 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
でも、抽象的なメソッドについては考えておくべきです。 それがないと、すべてが非常に信頼できないものに見えてしまいます。
私は、明示的な型付けを一切しない、そういうサブ言語の方向で考えています。実行時のみ。この種のアーキテクチャをうまくチューニングすれば、エラーになることはないと思うのですが。
この種のアーキテクチャをうまくチューニングすれば、エラーが発生することはないと思っています。
この種のアーキテクチャをうまくチューニングすれば、エラーが発生することはないと思っています。
これは、ランタイムエラーは 良いプログラムデバッグのためのベンチマークとしてはあまりにも信頼性が低いという同志の懸念についてです
私は、明示的な型付けを一切しない、そういうサブ言語の方向で考えています。実行時のみ。この種のアーキテクチャをうまくチューニングすれば、エラーになることはないと思います。
これは、ランタイムエラーが 品質の高いプログラムデバッグのためのベンチマークとしてあまりにも信頼性に欠ける、という同志の懸念についてです
イリヤ、デバッグするものがあれば...。
しかし、これは無益な指摘です。タイピング不足は悪である。コンパイラが悪態をつけばつくほど、それは正しい道を歩んでいるということなのです。
私たちはここで軌道制御ステーションを書いているのではなく、単純で、ステレオタイプで、定型的なソリューションを書いているのであり、お互いにほとんど違いはありません。その中で、厳密な型式管理を行わず、最大限の利便性を追求したことは、まさにドクターの指示通りです。各種ニューラルネットワークやGPUの演算支援のファンの方は安心してください。最高のパフォーマンスを追求する熟練者も同様です。
その中で、厳格な型式管理を行わず、最大限の利便性を追求したことは、まさにドクターの指示通りです
ところで、MQLはすでにポインタの型チェックを欠いており、ベースポインタが暗黙のうちに派生ポインタにキャストされてしまいますが、これは起こってはならないことです。
私たちはここで軌道制御ステーションを書いているのではなく、単純で、ステレオタイプで、定型的なソリューションを書いているのであり、お互いにほとんど違いはありません。その中で、厳密な型式管理を行わず、最大限の利便性を追求したことは、まさにドクターの指示通りです。各種ニューラルネットワークやGPUの演算支援のファンの方は安心してください。最大生産性の熟練者たちも同様です。
Pythonのような動的型付けを持つ言語では、ニューラルネットワークやGPUなどを使った複雑なプロジェクトが想定され、明示的なプログラミングの困難さがないこと。
このような言語は、基本的にシェルであり、通常のプログラミング言語で書かれた何らかのコードを呼び出しているに過ぎないのです。