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

新しいコメント
 
A100:

はい、ありがとうございます。ソースコードを簡略化したのは私のミスです。

混乱を避けるため、前のものを削除しました。

ひどい話だ、本当にひどい話だ、生きるってのは...

--

聞いてくれ、何の得がある？ 秘密でなければ

Lispでアドバイザーを書いているんですか、すごいですね、でもHaskellに変えたらどうですか？

;-)

 
MetaDriver:

いいか、何のために必要なんだ？ 秘密でなければ

MQL5にはインライン関数がないので、代わりにパラメトリックマクロを使っていますが、これは型制御ができないので、ちょっと正しくないですね
 
A100:
MQL5には（フォームに）インライン関数がないので、代わりにパラメトリックマクロを使っています。

はい、私も使っています、ただ、それほど不気味な巣ではありませんが ))))

参考までに、mql5はすべての小関数をインライン置換に変換します。 つまり、すべてのユーザー定義関数にはデフォルトで「inline」というキーワードが入っていると考えてよいでしょう。

マクロで代用するか、関数にコンパイルするかは、最終的にはコンパイラが決定します（ちなみにC++と同じです）。だから、そんな方法で高速化しようとしても意味がない。どうせ簡単な関数は全部インライン化されているのだから。

// ところで - タイプコントロール付き!:)

 

MetaDriver:

参考までに、mql5はすべての小さな関数をインライン置換に変換します。 つまり、すべてのユーザー関数にはデフォルトで「inline」というキーワードが入っていると考えてよいでしょう。

速くするためではなく、利便性を考えてのことです。本質的にはインラインであっても、形としてはインラインではない（！）。.mqhでinlineを定義し、それを複数の.ex5で使用する場合、困難が生じます。これからリンク先を探してみます。

https://www.mql5.com/ru/forum/1111/page1013#comment_520221

int B() { return ( A( 0 ) ); }

1.mqhの B()はインラインのはずですが、全部合わせても正常にコンパイルされず、別々にしかできません。サービスデスクは、電話の曖昧さに言及し、問題の本質に深く入り込まず、別の方法でプロジェクトを編成するよう勧めました。どうすれば、もっと違うことができるのか。.mqhから.ex5へのB()の実装を削除したときのみ、すべてが動作します。では、インラインフォームとは何でしょうか？

ちなみに、MQL4では、B()は実際にはインラインではなく、形式的にインラインですが、この例はエラーなく動作します。

 
A100:

しかも、スピードのためではなく、利便性のために。要するに、インラインにはなっても、フォームにはならない（！）のです。

そして、その形はどうでしょう。

" スタッドベーカーとは何者か？あなたのスタッドベーカーの親戚ですか？君のパパは スタッドベーカー？

.mqhでinlineを定義し、それを複数の.ex5で使用する場合、困難が生じます。

論理的な間違いをせず、コンパイラの仕組みをきちんと理解すれば、難しいことはありません。

今すぐリンク先を探してみる

https://www.mql5.com/ru/forum/1111/page1013#comment_520221

ここでのB()関数は、基本的にインラインです。

同じパラメータを持つオーバーロードされた関数へのあいまいな呼び出し」といったエラーはまだ取り除けませんが、別の.ex5に入れなければ発生しませんでした。

ソースコードレベルでは、本質的に認識できない再帰性があります。 コンパイラは、情け深くも、正しいメリットで、あなたを顰蹙（ひんしゅく）しました。あなたは、あなたがコンパイルしているのと同じinluderを定義しているlibuに接続しようとしているのです。で、何が欲しいんだ？もし、あなたがコンパイラーだったら、どうしますか？

初耳かもしれませんが、DLLに書かれたインライン関数は、そのDLLの外では 決してマクロとして使うことはできません。 // 実行時にはソースコードはもはや存在しないのです。

mql(4, 5)のすべてのライブラリは動的にリンクされています。それがDLLの本質です。

結論：実はあなたは、リブから自分自身への言及、自分自身への言及、自分自身への言及......などを行おうとしていたのですね。

同意します。もし、すべてが異議なくコンパイルされ、実行時に lib がメモリ不足になるまで再帰的に自分自身をロードしようとしたら、もっとひどいことになります...。:))

?

そのため、C/C++ではinlineキーワードが存在するのです

全然理由になってませんね。 リンク先の例はC++ではコンパイルできないでしょうし。

// もし私が再帰的に構成されたソースコードの構築方法を理解していなければ、コンパイラもそれを理解できないでしょう。

 
A100:

ちなみに、この例はMQL4でエラーなく動作します。

しかし...関数のリロードがないため、コンパイラは間違ったリロードをほのめかそうともせず、ただ愚かにも繰り返される定義を無視するのかもしれません。
 
MetaDriver:
しかし......そこに関数のオーバーロードがないので、もしかしたらコンパイラはそこで間違ったオーバーロードをほのめかそうとはせず、ただ愚かにも繰り返される定義を無視するのかもしれません。

MQL4（！）でも、B()の前にinlineで書けばC/C++でもコンパイルできます。

そこには再帰性は全くなく、実際には

int A( int ) および #define B() A( 0 )

関数の宣言と実装を分けるだけで、とてもシンプルになります。）

 
A100:

1.mqhの B()はインラインのはずなのですが、全部合わせても正常にコンパイルされず、別々にしかコンパイルできません。ServiceDeskは、コールのあいまいさに言及し、問題の核心に深く入り込んでおらず、別の方法でプロジェクトを編成することを推奨しています。それ以外の方法は？

自分で答えただけです。


.ex5の.mqhからB()の実装を削除した場合のみ、動作します。では、インラインフォームとは何でしょうか？

そこで問題になるのは、インラインB()ではなく、その再定義です。 libはDLLなので、それに含まれるインルーダの情報（名前）は、再コンパイル時にすでに欠落しています1。mqh (最初のコンパイルは lib が形成された時) なので、インラインのコンパイル時に再定義された B() 関数が見つかり、パラメータが同じなので、コンパイラはこれを関数を再ロードしようとする誤り (不正確) とみなします。 彼には権利があります。 とても丁寧に、彼は悪びれることもできたはずです。
 
MetaDriver:
自分の質問に自分で答えただけだろ。
インラインは正常で、問題はB()の非正規性ではなく、その再定義にある。

ただ、C/C++はこれが再定義でないことを（inlineキーワードを使って）理解し、MQL5はコンパイルしたモジュール名と#importで指定したモジュール名で区別することができますが、そうではありません。MQL4がどう理解しているのかわからない。

要するに、.mqhで関数の実装を定義して、どの.ex5でも問題なく使えるということはないのです。

 
A100:
その通りです。ただ、C/C++はこれが再定義ではないことを理解していますが、MQL5ではそうではありません。

C/C++では、ソース名の情報はオブジェクトファイルに保存されるため、静的 ライブラリのコンパイル時のみ、これを理解することができます（再コンパイルを認識するだけです）。

動的リンクされたライブラリでは、これはうまくいきません。うまくいくとしても、再実装の検出ではなく、現在のソースとDLLの名前の一致に関する「優先ルール」のためです。 いくつかの言語にはこのルールがあります（特にDelphi、おそらくいくつかのC/C++コンパイラもそうでしょう）。

1...100910101011101210131014101510161017101810191020102110221023...3185
新しいコメント