MQL5におけるOOPに関する質問 - ページ 85

新しいコメント
 
MQLでOOPを使うのは、どうしても必要なときだけ、しかもコードのある部分だけにした方がいいと思ったのは、これが初めてではありません。
 
Pavel Verveyko:
MQLでは、緊急に必要な場合のみ、特定のコードセクションでのみOOPを使用するのが良いと考えている自分に気づいたのは、今回が初めてではありません。
いったい誰がそんなバカなことを考えたんだ？猫が嫌いな人は、単に料理ができないだけです))))
 

どこかで読んで、そのような構造の例がフォーラムに現れました。

delete &this;

どなたか簡単な例を作っていただけませんか？

this delete &this deletesの内容が気になる。

 
Igor Makanu:

どこかで読んで、そのような構造の例がフォーラムに現れました。

どなたか簡単な例を作っていただけませんか？

このdelete &thisが何を削除するのかに興味があります。

自分で削除してしまう)))

 
Vladimir Simakov:

勝手に削除される)))

然もありなん

が、要はスタティックなメソッドで 使いたいのではと推測しています

テストする必要があるのですが、その方法がわからないのです。


UPD: 昨日このトピックをググったら、プライベートデストラクタについての言及がたくさんあった。

 
Igor Makanu:

1)ですが、"delete &this; "がポイントなのでは？-staticメソッドとの 併用
 2) 昨日このトピックをググったら、private destructorへの言及が多く、それが何を提供できるのか考える必要がある。

1) 静的メソッドからの、アクセスは禁止する。
"delete &this; "はどこだ？- https://stackoverflow.com/questions/447379/what-is-the-use-of-delete-this

2) プライベートデストラクタは、スタック上にオブジェクトを作成することを禁止していますが、new演算子を通して、今度はヒープ上にオブジェクトを作成することは可能です。

class A{
   ~A(){printf(__FUNCSIG__);}
public:
    void Delete(){
        delete &this;
    }
};

void OnStart() {
   A* a_ptr = new A();
   a_ptr.Delete();
}

ここで、delete &thisのもう一つの使い方を紹介します。

 
Sergey Dzyublik:

1) 静的メソッドからの、アクセスは禁止する。
どこで "delete &this;" をするのか- https://stackoverflow.com/questions/447379/what-is-the-use-of-delete-this

2) プライベートデストラクタはスタック上にオブジェクトを作成することを禁じているが、new 演算子によって、今度はヒープ上にオブジェクトを作成することができる。

ここで、delete &thisのもう一つの使い方を紹介します。

何かを使って何かをすることはいつでもできる。しかし、何が言いたいのでしょうか？

名前を考案して、デザインパターンとして宣言して......。ということで、終了です。ただ「何かを削除する」のではなく、コードをたくさん書くというのはとてもクールです。

 
プライベートデストラクタは、あなたの開発したものをディレッタントから保護します。結局、OOPを使えるのは、newとdeleteという大人しい方法だけなんです。ところで、「柄」の名前はもう考えているのですか？
 
Dmitry Fedoseev:
本当に適切なニックネームですね ))
 
Igor Makanu:

どこかで読んで、そのような構造の例がフォーラムに現れました。

どなたか簡単な例を作っていただけませんか？

この削除とこの削除が何を削除するのかに興味があります。

これは、現在のオブジェクトへのポインタである。

通常、delete this構文はnewによってオブジェクトが生成される場合に使用されるが、削除の責任はオブジェクト自身にある。この場合、オブジェクトは不要になったと判断すると、初期化関数を呼び出し、次のように自分自身を削除します。

私見ですが、これは非常に危険な行為であり、オブジェクトへの参照を自らカウントし、その数がゼロになったら自ら削除できるようなスマートポイントの場合のみ許容されると思います。しかし、この場合でも、発見しにくいメモリリークのエラーが発生する余地があるように思います。

私の考えでは、削除の責任は、それを作成した同じオブジェクトにあるべきだと思います。作成時にオブジェクトファクトリーパターンを使用することもできますが、削除はやはり新しいオブジェクトを作成したオブジェクトの責任であるべきです。

1...787980818283848586878889909192...96
新しいコメント