Индекс производительности труда показывает изменение объема выпущенной продукции, приходящегося на одного работника. Этот показатель полезен для предсказания инфляции и прироста объема производства. Если стоимость труда увеличивается соответственно увеличению производительности, и, кроме того, маловероятно увеличение производственных издержек...
// Для МТ4 - возвращает otfFilingType.
// Для МТ5 - возвращает тип исполнения ордера, равный otfFilingType, если он доступен на символе strSymbol, иначе - корректный вариант.
ENUM_ORDER_TYPE_FILLING CSymbolInfo::GetTypeFilling(string strSymbol,ENUM_ORDER_TYPE_FILLING otfFilingType = ORDER_FILLING_FOK)
{
#ifndef __MQL5__
return(otfFilingType);
#else // __MQL5__
// Функцию предложил fxsaber. Серьезной проверки не было - полагаемся на его авторитет.
const ENUM_SYMBOL_TRADE_EXECUTION steExeMode = (ENUM_SYMBOL_TRADE_EXECUTION)::SymbolInfoInteger(strSymbol, SYMBOL_TRADE_EXEMODE);
const int iFillingMode = (int)::SymbolInfoInteger(strSymbol, SYMBOL_FILLING_MODE);
私のスタイルの一例？
例えばこれ。
100個の関数があり、それぞれがそのようなレコードを返すと想像してください。これらのエントリーの中から、エラーを探すのです。検索にかかる時間はどれくらいですか？
例えばこれ。
100個の関数があり、それぞれがこのレコードを返すと想像してください。これらのエントリーの中から、エラーを探すのです。検索にかかる時間はどれくらいですか？
特に、このスタイルのレコードでは、数十以上の関数を「1つの画面」に表示できるので、コードでの作業がしやすくなりますから、数分以上検索することはないでしょう
例えばこれ。
100個の関数があり、それぞれがこのレコードを返すと想像してください。これらのエントリーの中から、エラーを探すのです。見つけるのに、どのくらい時間がかかりますか？
私がそのような文章を書くのは、スタイルや簡潔さの原則のためではなく、その方が本当に楽だからです。
一番シンプルな方法を挙げていますね。正直なところ、何が少しもわかりにくいのか理解できません。
正直なところ、私はC++のコードを全く知らないので読めません。でも、みんな書き込んでいるんですよ。だから、無知でいいんです。
このように書くのは、スタイルや簡潔さのためではなく、私にとっては本当に簡単なことなのです。
最もシンプルな言葉を引用していますね。正直なところ、何が少しもわかりにくいのか理解できません。
正直なところ、私はC++のコードを全く知らないので読めません。でも、みんな書き込んでいるんですよ。だから、無知でいいんです。
おそらく、コードのシンプルさについての考え方が違うのでしょう。
あなたはプログラミングの偉大なプロフェッショナルであると理解しています。しかし、すべてにおいて最高の生産性を追求するとき、忘れてはならないのが労働生産性 である。それは、コードの可読性から始まります。コードの可読性を犠牲にしてまでコードを圧縮したいという衝動がなぜ正当化されるのか、私にはよくわかりませんが、大規模な（独立した）プロジェクトではかなり受け入れがたいことなのでしょう。
正直なところ、C++は読めなさすぎて嫌いです。存在を容易に回避できる存在を積み重ねたため。そして、これからもっと良くなっていくのです。広々としている。
SZU. 開発においては、可読性を犠牲にするのではなく、できるだけ可読性を残しつつ、よりよい解決策を見出すために、コードを圧縮するべきだと考えています。コード理解のスピードは、自分の生産性に大きく影響します。
ZSY スレッドが素晴らしい。ありがとうございます。
整数の外に何が出るか考えてみてください。
したがって、LONG_MAX- のチェックは double を long に変換する前に行う必要があります。 明らかに、丸め関数は整数に収まらない値に対して設計されていません。そして、それは問題を変えるものではありません。
もし関数がdoubleを返してlongに変換すれば、同じようにオーバーフローの危険に直面することになります。
個人的には、丸める直前 - 境界値のアサートチェックを常に行い、さらにプログラムのロジック - 変換が整数の最大値以上になることがないように常に気を配っています。
特にこのスタイルで書くと、数十以上の関数を「1つの画面」に表示できるので、コードを扱うのが楽になりますから
何か怪しいな。
以下は、実行の種類を返す私の関数の実際のコードです（このコードはfxsaberから 提案されたもので、私は彼にとても感謝しています）。
この機能は本当によくできています。何度も確認したが、エラーは発生しなかった。しかし、このひどい返しの中で、どのように結果が形成されるのか、私自身はわりと良い経験をしているにもかかわらず、未だに理解できていません。 しかも、fxsaber さん自身が覚えていないと回答しています。
Vitalyさん、このコードがどのように動作するのか、もしあなたにとってそれほど難しくなく、このスタイルで「数分で理解できる」のであれば教えてください !
私なら、return演算 子に「括弧を開けて」、「質問」をすべて「if」に置き換え、見つかった値を論理的に「or」で返します。 個人的には、「質問」演算子がまったくないのは困りますが。同じようなifと全く同じコードが得られるが、可読性はずっと悪くなる。
という疑問があるんです。
以下は、実行タイプを返す私の関数の実際のコードです（このコードはfxsaber さんに提案していただいたもので、とても感謝しています）。
この機能は本当によくできています。何度も確認したが、エラーは発生しなかった。しかし、私自身はむしろ良い経験をしているにもかかわらず、この恐ろしいほどのリターンで結果が形成されることが未だに理解できない。 しかも、fxsaberは 彼自身がそれを覚えていないことを質問に答えている。
Vitalyさん、このコードがどのように動作するのか、もしあなたにとってそれほど難しくなく、このスタイルで「数分で理解できる」のであれば教えてください !
私なら、return演算 子の括弧を開け、questionを全てifに置き換え、見つかった値を論理的にorで返します。 個人的には、question演算子が全くないのは困るのですが。同じようなifと全く同じコードを生成しますが、可読性はかなり悪くなります。
コードの解釈はしませんが、以前、私のテンプレートから作品を投稿したことがありますが、似たようなやり方がありますね。モニターの2つのスクロールにifを伸ばすのは好きではありません。
仕事の生産 性も忘れてはいけません。それは、コードの可読性から始まります。
私のコードの例です。今、私は全く理解していません。そして、あなたがよく理解しなければならない要素がたくさんあります。
トレーディング、自動売買システム、ストラテジーテストに関するフォーラム
Init()とDeInit()の実行シーケンス
fxsaber さん 2017.04.14 23:35
ご覧のように、コード/スタイルは非常にシンプルです。しかし、私は同じコードを書き直すことができたときにのみ、それのエラーまたはその不在を検出することができるようになります。問題を完全に理解する必要があるので、本当に多くの時間がかかります。
そのため、複雑なものは作成段階でクリーンアップ（ストレステストを書く）し、mqhを差し込むことでシンプルな形で利用することを原則としています。このように、複雑さは必ずしもスタイルや簡潔さによって決まるものではありません。
また、純粋に言語的な構成要素であるTypeToBytesの例もある。そこでの理解力の複雑さは、まったく別次元です。そして、ここはマクロがなければ枯れてしまうところです。マクロがあるからこそ、ソースコードに素早く入り込むことができるのです。なぜなら、マクロは簡潔さのためではなく、理解するために使われることが多いからです。
そして、単純ではないが忘れがちな落とし穴をたくさん考えなければならない場合もある。これは、MT4Ordersの場合です。だから、そこにあるセリフには、自分だけに向けたコメントが添えられていたりする。コードを理解するのに役立ちます。
しかし、これらはすべてmqhであり、手を出す必要がないことに注意してください。そして、TCのコードはmqhで書かれており、非常にシンプルです。通常のiHighの機能のソースコードを覗くことはありません。そして、彼らはまさにモンスターなのです。使うだけなんですね。ライブラリも同じようにした方がいい。同じジェネリック・バイブルを使うにしても、完全に理解する必要はない。
MT4 EAとそのMT5移植版のQBを見てください。MT5のポートは理解するのがギリギリです。簡潔さに近い匂いがしないだけでなく（コードはオリジナルの何倍も大きい）、mqh-filesに説明されていないMT5の落とし穴がゴロゴロしています。
コードの解釈はしませんが、以前、私のテンプレートから作品を投稿したことがありますが、似たようなやり方がありますね。私は、2つのモニタースクロールにifを伸ばすのは好きではありません。
この場合、関数を使うのが賢明です。
コードの解釈をしていないということは、その仕組みもすぐにはわからないということですね。括弧、まさに「問い」、論理的な「または」を徹底的に分析する必要があるのです。しかし、このような「積み上げ」は、プログラムの「ボトルネック」に、より効率的なコードを使えるようになる場合など、非常に限られたケースで許容されます。この場合、実行型の取得がボトルネックになることはありえず、このようなコードはここでは望ましくない。私は、fxsaberの権威と自己テストを繰り返したことだけを頼りに使っています。しかし、これは例外的なことです。原則として、自分で詳しく調べていないコードは使いません。
この機能は本当によくできています。何度も確認したが、エラーは発生しなかった。しかし、私は、十分な経験があると思うのですが、この恐ろしいリターンで結果がどのように形成されるのか、いまだに理解できません。 しかも、fxsaberさん 自身が、自分では覚えていないと回答しているのです。
帰国子女のことではありません。同じ論理をif-elseの形で説明されても、理解は深まらないでしょう。これは、「Unsupported filling」の問題を取り上げて深く研究してみると、まさにその通りなのです。関連するストレスコードをたくさん書き、さまざまなトーラスサーバーでたくさんのアカウントを開設し、すべてのシンボルを競争させなければならないのです。国旗のさまざまな組み合わせの中からパターンを見つける。そして最後に、すべてのテーブルを同じ分母にすること。ここで「覚えられない」が出てくる。
問題が発生しなくなり、安全に忘れ去られることを達成した。一度書いたコードに戻らなくていいというのは素晴らしいことです。動く......というのが最大のポイントです。