Init()およびDeInit()実行シーケンス - ページ 14

新しいコメント
 
Andrey Dik:

OKです。ソケットは残念な例です。

では、もう1つ。ベランダから飛び降りることです。ACはベランダから飛び降りることを禁止しているのですか？- ダメ？- それなら、アドレナリンを出すための練習をすればいいじゃないですか。

どんな目標も、正気の手段で達成されなければならない。そうでなければ、目標は非合理的なものとなる。


バルコニーも悪い例です。バルコニーには手すりがあり、その高さまで建築基準法で決められています。しかし、自分の家では、ベランダから手すりを外すことができ、理解し、ベランダから飛び降りることはありません。
 
Dmitry Fedoseev:

また、バルコニーも残念な例です。バルコニーには手すりがあり、その高さは規定で定められています。自宅でベランダの手すりを外すことができる。 ベランダから飛び降りないことを理解し、飛び降りない。

CCが禁止していないことを話していたんですね。バルコニーから飛び降りることは、CCでは禁止されていない。パソコンの電源ボタンを素早く押すことは、CCで禁止されているわけではありません。ACはいろいろなことを禁止しているわけではありませんが、まともな人はやらないでしょう。

でも、TFを変えたい......ということはよくありますよね。なぜだろう。イギリスが禁止していないだけで、？- が、それは批判であって、MQへの願望ではありません。

 
Andrey Dik:

CCが禁止していないことを話していたんですね。バルコニーから飛び降りることは、CCでは禁止されていない。パソコンの電源ボタンを素早く押すことは、CCで禁止されているわけではありません。CCは多くのことを禁じてはいないが、まともな人はそれをやらないだろう。

でも、TFを変えたい......ということはよくありますよね。なんでだろう！？イギリスが禁止していないだけで、？- しかし、それは批判であって、MQへの願望ではありません。


そんな願いは書いていない。起こりうるということです。家庭の冷蔵庫で、ドアを開けると電球がついたり消えたりするのを想像してください。ドアを開けるには一定のスピードが必要ですが、何があれば正常に動作するのでしょうか。クレチン主義ではないか？

驚きました。設計技術 者ではないのですか？それとも、カルチャーセンターのアマチュアアートグループの代表なのでしょうか？デザインの基本原理を理解していない。

 
Dmitry Fedoseev:


そうなってほしいというようなことは書いていない。事実、起こりうることです。ご家庭にある冷蔵庫を想像してみてください。ドアを開けると電球がついたり消えたり、一定のスピードでドアを開けないとうまく作動しない。クレチン主義ではないか？

驚きました。設計技術者ではないのですか？それとも、カルチャーセンターのアマチュアアートグループの代表なのでしょうか？デザインの基本原理を理解していない。

あなたこそ、設計 原理を理解していないのでは？

"馬鹿にガラス○○を与えると、○○を割って手を切る "という素晴らしい諺があります。

2回目ですが、なぜTFを頻繁に切り替える必要があるのですか？ これらのジェスチャー（プログラムアクション）に実用的な意味はあるのでしょうか？答えは出ていない。

私はエンジニアであってターミネーターではないので、わざと壊したりするようなバカな議論には参加しません。

 
Andrey Dik:

設計の原則を理解していないのは、あなたです。

バカにガラスの○○を与えると、○○を壊し、手を切る」という素晴らしいことわざがあります。

私は2回質問しています：あなたは何のために頻繁にTFを切り替える必要があるかもしれません。 これらのジェスチャー（プログラムアクション）の実用的な意味は何ですか？答えは出ていない。

私はエンジニアであってターミネーターではないので、わざと壊したりするようなバカな議論には参加しません。


高学歴のバッジをつけるようになったのですか？
 
TFを変更する際のdeinitとinitの優先順位に関する建設的な議論に無関係であるとして、投稿125以降のすべてを削除することを提案します。
 
elibrarius:
TFを変更する際のdeinitとinitの順序の問題についての建設的な議論には関係ないとして、投稿125以降をすべて削除することを提案します。

それはもったいない、とても建設的で啓発的な議論だった。
 
Andrey Dik:

設計の原則を理解していないのは、あなたです。

バカにガラスの○○を与えると、○○を壊し、手を切る」という素晴らしいことわざがあります。

私は2回質問しています：あなたは何のために頻繁にTFを切り替える必要があるかもしれません。 これらのジェスチャー（プログラムアクション）の実用的な意味は何ですか？回答がないのですが。

デザインの原理を理解すれば、熊手がないのは良いことで、あるのは悪いことであり、ことわざとの類比は不適切であることは明らかでしょう。

質問について。まず、なぜ「頻繁な切り替え」という言葉にこだわるのか。現在の実装では、周波数は問題に影響しません。これは、シングルスイッチングでも同様に現れます。そして第二に、本質的なことを答えると、例えば、同じスラワさんが、オフラインのチャートをリフレッシュする「モダンな」方法としてChartSetSymbolPeriodの呼び出しを 推奨しています。そのノウハウがチャート上のいくつかの指標に組み込まれ、短時間でトリガーされないという保証はないのです。

状況が変わりそうもないことは理解していますが、せめてこの素敵な現在のロジックを、EAと指標の違い、時間枠による上下切り替え、初期化解除理由コード（特に、ヘルプでは指標に対するコード3がまだ否定されています）などの詳細とともに、ヘルプにすべて明記してもらうようMQに要請しましょう。

 
Stanislav Korotky:

設計原理を理解すれば、「熊手がないのは良いことで、熊手があるのは悪いこと」であり、ことわざとの類推は見当違いであることは明らかでしょう。

質問について。まず、なぜ「頻繁な切り替え」という言葉にこだわるのか。現在の実装では、周波数は問題に影響しません。これは、シングルスイッチングでも同様に現れます。そして第二に、本質的な答えですが、例えば、同じスラワさんが、オフラインのチャートをリフレッシュする「モダンな」方法として、ChartSetSymbolPeriodの呼び出しを 推奨しています。そのノウハウがチャート上のいくつかの指標に組み込まれ、短時間でトリガーされないという保証はないのです。

状況が変わりそうもないことは理解していますが、せめてMQには、エキスパートとインデックスの違い、時間枠の上下切り替え、初期化理由コード（特に、ヘルプではまだインディケータのコード3が否定されています）についての詳細とともに、この美しい現在の論理をすべてヘルプに明記してもらいましょうよ。


TFの頻繁な切り替えは、ディミトリが唯一バカができる感覚で論拠として訴えたものです。ですから、この格言は非常に適切です。
唯一納得できるのは、リファレンスに文書化する必要があることです。そして特に、同じ状況でもプログラムの種類によって挙動が異なる可能性があるものを詳しく説明します。
 
Andrey Dik:

TFの頻繁な切り替えは、ドミトリーが唯一、バカができる感覚で論拠として訴えたものだ。だから、この格言はとても適切なのです。
唯一納得できるのは、リファレンスに文書化する必要があることです。そして特に、同じ状況でもプログラムの種類によって挙動が異なる可能性があるものを詳しく説明します。

実は今、initとdeinitでどうなのかをお伝えしました。

しかし、一般的にエンジニアリングのアプローチはスーパーです。うまくいってもいかなくても、うまくいくときもあれば、いかないときもある）、まったく問題ない、致命的ではないのです。

1...789101112131415161718192021...28
新しいコメント