エラー、バグ、質問 - ページ 1572

 

MT4/950/32。プロファイル変更時の桁落ち

ツールバーのアイコンでプロファイルを変更すると、すぐに価格目盛りの桁が消えてしまいます(左の写真)。その後、別のタブを選択してチャートを変更すると、桁が元に戻ります(右の図)。Windows 8.1/32。解像度1024x768、1280x1024も試してみました。目盛りは125%です。4文字で1桁、5文字で2桁が失われた。

MT4でフォントサイズを 大きくしてMT5にした直後からでしょうか。

 

CHART_SHIFT_SIZE がトレンドで機能しない

void OnStart()
{
        ::ChartSetInteger( 0, CHART_SHIFT, true );
        for ( int i = 50; i >= 10; i-- )
        {
                ::ChartSetDouble( 0, CHART_SHIFT_SIZE, (double)i );
                ::ChartRedraw();
                ::Sleep( 100 );
        }
}
test391.ex5のようなダイナミクスが期待されました。
ファイル:
Test391.ex5  5 kb
 

MT4エディターでウェアハウスからファイルを ダウンロードできない - エラーが表示される

2016.05.05 15:11:05.427 Storage failed to read http data (storage.mql5.com:443 read failed [12152])
 
Karputov Vladimir:

MT4エディ ターでウェアハウスからファイルを ダウンロードできない - エラーが表示される

また、エラーは1つのエディタにのみ発生します。同じコンピュータの別のフォルダにMT4とそのエディタは、簡単にストアからコードをダウンロードしました。
 
開発者の皆さん、C言語のような名前空間を導入してください。
 

ビルドを更新するたびにコードがコンパイルできなくなるなんて、いつまで続くんだ! しかも、コンパイルできたとしても、同じようには動かない(もっとひどい)。 こんなプログラミング言語、誰が必要とするんだ?

あのバグを丹念に調べながら、A100の忍耐力に感心する、呆れてしまう。

上でA100がコンパイラを検証するためのテストを作るべきという意見がありましたが、この問題に対処しなければならないのはコンパイラ開発者ではなく、ユーザーであるというのはおかしな話です。

何より、これだけのことは猿真似です。 プログラマーチームの何年もの作業(つまり大金)と、何度もコードを書き直さなければならないユーザーの何年もの作業、そのすべてが何のためにあるのでしょうか?オープンソースのコンパイラを使い(あるいは購入し)、数ヶ月で自分のニーズに合うように修正するのではなく、「C++コンパイラ」という車輪を(少し修正を加えて)再発明することです。

しかし、いや、単純な方法は私たちには向いていない...。それよりも、自分たちが良いヒゲを持っていることを誇らしく自慢することが大切で、新しく作るたびに、少しずつ自転車を作り直しています。


また、具体的な話をすると、A100さんの、例えば、最適化をオフにして、多くの本物のコンパイラのようにDebugモードとReleaseモードを作ることができるというアイデアを、私は全面的に支持します。

個人的には、あなたが賞賛しているこの最適化のおかげで、私のプロジェクトは ビルド1159で2秒でコンパイルでき、それ以降のビルドでは20秒でコンパイルできるので、まだビルド1159に固執しています。 多少のパフォーマンスアップでは何も解決しません。 私の時間のほとんどは、開発とプログラム編集に費やされています。

 
Alexey Navoykov:

個人的には、あなたが賞賛しているこの最適化のために、私はまだビルド1159を使っています。私のプロジェクトはそこで2秒でコンパイルでき、それ以降のビルドでは20秒でコンパイルできるからです。 小さなパフォーマンスの向上は、私にとって何の解決にもなりません。 ほとんどの時間は、開発とプログラムの編集に費やされています。

100Kbのソースコードを持つプロジェクトは、1325回のビルドで1秒未満でコンパイルされます。堅実なOOP、多くの仮想関数と オーバーロード、テンプレート、ポインタ、(可能な限り)const修飾子。DLLとOpenCLはありません。

ラグの原因を突き止めたい。コンパイラが早く最適化できるようにするための制約なのかもしれませんね。ラグに遭遇したことは一度もありません。遅くなるkodobaseのソースコードを提供してください。

コンパイルした自分の自転車について。他人のプロジェクトを修正することは、長所と短所があります。メリットとデメリットを総合的に判断して、最初は自分のバイクに傾倒していたと思います。もちろん、このような決定がなされたとき、言語・コンパイラのタイミングや能力にこれほどの伏兵がいるとは誰も思っていなかっただろう。自分の力を過大評価しているのか、あるいは課題の複雑さを過小評価しているのか。もちろん、このバイクの開発には多くの資金が投入されました。

 
Anton Zverev:

ラグの原因を突き止めたい。おそらく、コンパイラが素早く最適化できるようにするための制約なのだろう。ラグに遭遇したことがない。お願いだから、遅くなるkodobaseのソースコードを教えてくれ。

テキストスプールのような巨大な機能を備えていることがほとんどです。

オプティマイザは、このようなコード断片を何度も通過させ、何度も改善しなければならないのです。オプティマイザが劇的にスピードアップするのは、関数のサイズを小さくすることで十分なんです。

最新のビルドでは、品質と速度の両方を常に向上させていますので、ぜひ最新のビルドに切り替えてください。

 
Renat Fatkhullin:

スプールのような形で巨大な機能を持つことになりそうです。

オプティマイザーは、このような断片を何度も通過させ、何度もコードを改善しなければならない。オプティマイザが劇的にスピードアップするのは、関数のサイズを小さくすることで十分なんです。

最新のビルドでは、品質と速度の両方を常に向上させていますので、ぜひ最新のビルドに切り替えてください。

文章の切れ端も問題なのでしょう。少なくとも私は、持っていません。

以前、国際プログラミングオリンピックの入賞者から、「関数は最大20行(条件付き)」と聞いたことがあります。それ以上であれば、アーキテクチャ上/アルゴリズム上、最適とは言えません。

ローマン・イェリザロフ氏の 資料を見ると、野生のネストを使ったシンプルな関数が大量にあります。しかも、そのほとんどが5行までの長さです。この知的な塊に比べれば、私など芋虫のようなものだ...。だから、自分の時代にいくら頑張っても、そんなにカッコよくはならないんです。

Роман Елизаров
Роман Елизаров
  • www.lektorium.tv
Занимается профессиональной разработкой ПО для биржевой и брокерской деятельности более 12 лет. Координатор группы проектов в компании Devexperts, участвует в разработке торговой платформы thinkorswim. Эксперт по...
 

重なっているオブジェクトにカーソルを合わせると、一番上のオブジェクトではなく、背景のオブジェクトの説明が表示されるようにしました。OBJ_EVENTオブジェクトで発音される。赤が見えますが、説明は青からです。