標準的な機能/アプローチの代替実装 - ページ 9

[Georgiy Merts]

fxsaber:

問題が発生しないところまで行き、無事忘れることができました。一度書いたコードに戻らなくていいというのは素晴らしいことです。それが最大のポイントです。

そうなんです。いつも自分でやっています（今回もご覧の通りです）。

問題は、何かが急に変わったときに発生します。コードが明確で、明白でない場所がきちんとコメントされていれば、ある変更点でのエラーの原因を見つけるのは簡単です。しかし、このような「忘れ物」の場合、訂正することは非常に困難です。

ええ、もちろんレアケースであることは間違いないのですが...。でも、こういう非常に稀なケースは......個人的には非常に不安です。ですから、そういうときはできるだけわかりやすいコードを書き、わかりにくいところは細かくコメントするようにしています。

[Реter Konow]

fxsaber:

私のコードの例です。今、私は全く理解していません。そして、非常によく理解する必要がある多くの要因があります。

ご覧のように、コード/スタイルは非常にシンプルです。しかし、同じコードを繰り返し書けるようになって初めて、その誤りや不在を発見することができるのです。完全に問題に入り込む必要があるため、本当に時間がかかってしまいます。

そのため、複雑なものは作成段階でクリーンアップ（ストレステストを書く）し、mqhを差し込むことでシンプルな形で利用することを原則としています。このように、複雑さは必ずしもスタイルや簡潔さによって決まるものではありません。

また、純粋に言語的な構成要素であるTypeToBytesの例もある。そこでの理解力の複雑さは、まったく別次元です。そして、ここがマクロなしでは枯れてしまうところです。ソースコードにかなり早く入り込めるのは、マクロのおかげです。なぜなら、マクロは簡潔さのためではなく、理解するために使われることが多いからです。

そして、単純ではないが忘れがちな落とし穴をたくさん考えなければならない場合もある。これは、MT4Ordersの場合です。だから、そこにあるセリフには、自分だけに向けたコメントが添えられていたりする。コードを理解するのに役立ちます。

しかし、これらはすべてmqhであり、手を出す必要がないことに注意してください。そして、TCのコードはmqhで書かれており、非常にシンプルです。通常のiHighの機能のソースコードを覗くことはありません。そして、彼らはまさにモンスターなのです。使うだけなんですね。ライブラリも同じようにした方がいい。同じジェネリック・バイブルを使うにしても、完全に理解する必要はない。

MT4 EAとそのMT5移植版のQBを見てください。MT5のポートは理解するのがギリギリです。簡潔さに近い匂いがしないだけでなく（コードはオリジナルの何倍も大きい）、mqh-filesに説明されていないMT5の落とし穴がゴロゴロしているのです。

正直、ここで反論することは何もありません。明らかに、あなたのプログラミングに対するアプローチに基づけば、すべてが正しいのですが（たぶん、過剰で不当なコード圧縮のケースを除いて）、私のアプローチに従えば、多くのことが間違っています。

1. もちろん、非常にシンプルに書かれたコードであっても、見つけにくいエラーが隠れていることがあります。しかし、書きにくいコードではさらに難しい。意味を解き明かすための精神的な労力を考えてみてください。大量の作業（大量の関数を書く、新しい仕組みを作る、既存の仕組みにうまく組み込む）が必要な場合、時間と労力の節約は最大のポイントになります。コードの「美しさ」が目的ではありません。スタイルについてではなく。夜中に読んで、できるだけ早く理解できるようなコード構成にする必要があります。自分にとって最大の成果を得るために、理想的なコーディングの方法を模索し始めるのです。そして、それを見ていること。

return((int)((Value > 0) ? Value / Points[digits] + HALF_PLUS : Value / Points[digits] - HALF_PLUS) * Points[digits]);

このように書くと、デメリットばかりが目につく。

1.たくさんのキャラクターが登場します。

2.過剰な「詰め込み」。

3. コメントのない数学演算

起きている間は、このコードを扱うことはできません。また、過労で非常に疲れている状態でも、対処することは困難です。毎日このような仕事をしていると想像してください。そんなコードには、すぐに目を背けてしまう。

2.他人のコードを見ずに、そのまま差し込む？

私は、大規模で本格的な、そして何よりも質の高いプログラムは、他人のブロックを組み合わせただけでは作れないと考えています。 一部だけ作ってあとはくっつけるだけでは、効率的なプログラムは作れません。ごちゃごちゃ」になってしまう。

それは可能だし、うまくいくだろう。しかし、これらは「その場しのぎ」のプログラムです。

私は、ブロックから組み立てられた（開発者が見てもいない）プログラムの有効性を信じていない。これはフィクションです。プログラムはいい加減で、解決策も効果的でないでしょう。いろいろな問題が出てくるでしょう。プログラマーがチームとなって共通の課題を解決するのであれば良いのですが、異なる人の異なるプログラムの間で「浮く」（調べもしない）ソリューションが使われているのであれば、効率という観点からは何の意味もないのです。

[fxsaber]

Реter Konow:

それは可能だし、うまくいくだろう。しかし、これは、 - プログラムは "彼らの膝の上に "です。

KBで私の出版物を見ることができます。誰かが使っているのでしょう。

自分のため、"土下座 "のためにしか書かない。出版物は副産物である。

[pavlick_]

Georgiy Merts:

したがって、LONG_MAX- のチェックは double を long に変換する前に行う必要があります。 明らかに、丸め関数は整数に収まらない値に対して設計されていません。そして、それは問題を変えるものではありません。

もし関数がdoubleを返し、それをlongに変換しても、同じようにオーバーフローの危険に直面することになります。

個人的には、丸めの直前に境界値のアサートチェックを必ず入れています。また、プログラムのロジックとして、整数の最大値より大きな値が変換に到達することは絶対にないようにしています。

チャーにロングキャストすることが多いのですか？doubleも同じです。doubleは階層の最後の段なので、そこからキャストする必要はありませんし、ほとんどの場合、stdにはそれを扱うためのすべてが備わっています。ヒエラルキーをキャストダウンせず、汗をかかないことです。

LONG_MAX/MINのチェックを追加すると、パフォーマンステストはそれほどバラ色にはならないような気がします。そして、その人はstd置換を目指しているのだから、全範囲の値で動作するはずだ。

[Georgiy Merts]

pavlick_:

チャーにロングキャストすることは多いですか？dablも同じで、階層の一番下の段で、そこからキャストする必要はなく、ほとんどの場合、何もすることがなく、stdにはそれで動作するものがすべてあります。ヒエラルキーにキャストダウンして迷惑をかけないように。

LONG_MAX/MINのチェックを追加すれば、パフォーマンステストはそれほど幸運ではないだろう。それに、この人はstd置換を目指しているのだから、全範囲の値で動作するはずだ。

longからulongへ（またはその逆） - あまりにも頻繁に。

long to char - 滅多にない。

整数演算と浮動小数点演算では結果が大きく異なるため、変換が必要である。整数データの実行速度も速くなると思われる。

範囲チェックについては、ASSERTであること、つまりDEBUG版でしか動作しないことをすでに強調しました。私の場合、すべての入力パラメータは、パブリックファンクションの最初にアサートして有効な範囲かどうか常にチェックされます。RELEASE版は、もちろん、すでに何のチェックもなく動作しています。

[Реter Konow]

fxsaber:

KBで私の出版物を見ることができます。誰かが使っているのでしょう。

自分のために、「土下座」して書くだけです。出版物は副産物である。

あなたの経験やプロフェッショナリズムを疑っているわけではありません。

ただ、数年にわたる日々のプログラミングや開発の過程で、ある特定のコードやソリューション、アプローチの利点を見積もるようになるのです。そして、しばしば非常に奇妙な結論に達する......。奇妙なものだが、多くの練習によって正当化される。

私は自分の見解を述べたまでです。

[pavlick_]

Georgiy Merts:

整数演算と浮動小数点演算では結果が大きく異なるため、変換の必要性が生じる。

どのような場面で吹き替えがうまくいかないのか、想像がつきません。Lua（quikに付属）では、整数型は 全くなく、ダブりしかなく、何もありません。

[fxsaber]

pavlick_:

私は、ダブリングで何かがうまくできないのはどのような状況なのか、悪い予感がします。

カウンター

void OnStart()
{
  const long Num1 = 9007199254967295;
  const long Num2 = Num1 + 1;

  Print(Num1 == Num2); // false
  Print((double)Num1 == (double)Num2); // true
}

ダブルは、すべてのインレンジインフォメーションを失わないが、ロングではそう でもない。

[pavlick_]

fxsaber:

カウンター

まあ、それでもその数まで数えなければならないのですが ))。本当にそうしたいのなら、それは仕方がないことです。

double cnt;
double high_cnt;
if (++ cnt == 1 000 000) {
   ++ high_cnt;
   cnt = 0;
}

[Georgiy Merts]

pavlick_:

まあ、それでもその数まで数えなければならないのですが ))。でも、本当にそうしたいのなら、それは仕方がないことなんです。

ひねくれるのも無理はない。しかし、その価値はあるのだろうか？

私の考えでは、もし変数が整数値しか持てないのであれば、浮動小数点値を書けないようにするために整数値でなければなりません。 変数や戻り値の型そのものが、すでに変数に関する重要な情報を含んでおり、部分的にはアルゴリズムに関する情報も含んでいるのです。あらゆるところで浮動小数点値を使うと、この情報が失われてしまうのです。

そして、整数であっても-私の意見では-アルゴリズムによっては-符号付きか符号なし、そして必ずしもlongではなく、おそらく「短」であると宣言しなければなりません。ただ、コードを見たときに、当該変数がどの範囲の値を 持つことが許されているかがすぐに理解できるようにするためです。

Luaに整数値が存在しないことは、私としては重大なデメリットだと考えています。