class A
{};
class B : public A
{};
voidOnStart()
{
A* ab = new B;
A* aa = new A;
B* bb = ab; // ok
B* ba1 = dynamic_cast<B*>(aa);
Print(ba1 ? "ba1 ok" : "ba1 bad cast"); // bad cast
B* ba2 = aa; // здесь неконтролируемый вылетPrint(ba2 ? "ba2 ok" : "ba2 bad cast");
}
注意力がないんですね。
あなたでもいい、本題に入ろう。
私は、明日(10年後ではない)でも実装可能で、C++と同じようなものになるような、最も単純な変形を提案しました(そうでなければ、なぜ全く何も変えないのか)。また、operator*()が実装されず、今後も実装されないのであれば(フォーラムに情報がありました)、なぜいきなりoperator->()が実装されるのか不明です(両者は同じ順序です)。
明日や10年後にこの形が必要なわけではありません。そして、外見的な類似性ではなく、機能が必要なのです。
C++からSTLを少なくとも部分的に移植すること。ここで問題になっているのは、オペレーター->だけでなく、もっと多くのものが必要です。
operator->は、スマートポインタへの第一歩となるでしょう。
実は、今の暗黙の了解のようなものは、すべてうまくいっていない。
ダイナミックキャストが暗黙のキャストに含まれていることがわかる
BUT
まず、ダイナミックキャストが明示的に言語内に存在するにもかかわらず、なぜそれが含まれているのかがわかりません。
なぜなら、関数のダイナミックキャストエラーは制御可能ですが(不正なポインタの出力)、暗黙のキャストは制御不能な例外を投げるからです。
2018.11.23 20:31:47.348 test (AUDNZD,M5) 'test.mq5' (17,11) のポインタのキャストに誤りがありました。
何の効果もない。
関数として無効なポインタを与えるか、暗黙のキャストから動的キャストを除外してコンパイルエラーを 出すか、どちらかです。
そう、この問題があると、OOPでの作業はコントロールが悪く、信頼性に欠ける。 どこかプログラムの一箇所で型を変更すると、それがどこだかわからないところで爆発する。 これらの例では、単純なポインタの割り当てがあり、すべてが目の前にあるので、松葉杖を使って何とかやり過ごせる。 しかし一般に、ある関数にポインタが渡されて動的に知らないものにキャストすると、それをコントロールする方法がないのである。
ポイントとは、MQLにおける普遍的な演算子である。
それは、見方次第です。オブジェクトとポインタの両方で動作する、普遍的なものだと言えるでしょう。
と言うこともできます。はオブジェクトに対してのみ動作し,ポインタに対しては,そのポインタが暗黙のうちにオブジェクトにキャストされる限りにおいてのみ動作します。
エントリ
は、しないに等しい。
a
こんな構造もあるんだ
OrdersInfo orderという変数があるのですが、これをファイルに書き込もうとすると
コンパイラは次のように出力します: 'order' - オブジェクトを含む構造体は許可されません。
何が問題なのでしょうか?
こんな構造もあるんだ
OrdersInfo orderという変数があるのですが、これをファイルに書き込もうとすると
コンパイラは次のように出力します: 'order' - オブジェクトを含む構造体は許可されません。
何が問題なのでしょうか?
こちら
https://www.mql5.com/ru/docs/files/filewritestruct
には、制限事項が記載されています。
MT4on UPUの トラフィックがマイナス、ダウンロードした履歴のカウンターが増加し始めた ...