MQL5의 OOP에 대한 질문 - 페이지 85

새 코멘트
 
일반적으로 MQL OOP가 긴급한 경우에만 코드의 특정 섹션에서만 사용하는 것이 더 낫다고 생각한 것은 이번이 처음이 아닙니다.
 
Pavel Verveyko :
일반적으로 MQL OOP가 긴급한 경우에만 코드의 특정 섹션에서만 사용하는 것이 더 낫다고 생각한 것은 이번이 처음이 아닙니다.
누가 그런 어리석은 말을 했습니까? 고양이를 좋아하지 않는다면 고양이를 요리하는 방법을 모를 뿐입니다.)))
 

나는 어딘가에서 읽었고 여기에 그러한 디자인의 예가 포럼에 나타났습니다.

 delete & this ;

간단한 예를 누구나 이것으로 할 수 있습니까?

이 삭제를 삭제하는 질문에 관심이 있습니다. &this;

 
Igor Makanu :

나는 어딘가에서 읽었고 여기 포럼에 그러한 디자인의 예가있었습니다.

간단한 예를 누구나 이것으로 할 수 있습니까?

이 삭제를 삭제하는 질문에 관심이 있습니다. &this;

자신을 삭제

 
Vladimir Simakov :

자신을 삭제

논리적이다

하지만 요점은 정적 메서드 와 함께 사용하는 것이라고 생각합니다.

테스트를 해봐야 하는데 방법을 몰라서 여쭤보니


UPD: 어제 나는 이 주제를 빠르게 구글링했습니다. 개인 소멸자에 대한 언급이 많이 있으므로 이것이 무엇을 줄 수 있는지 생각해야 합니다.

 
Igor Makanu :

1) 그러나 나는 "delete & this;"의 요점을 의심합니다. - 정적 메서드 와 함께 사용
2) 어제 나는 이 주제를 빠르게 구글링했는데, private 소멸자에 대한 언급이 많기 때문에 그것이 줄 수 있는 것에 대해 생각해야 합니다

1) 정적 메서드에서는 이에 대한 액세스가 금지됩니다.
"delete & this;"라고 말하는 곳 - https://stackoverflow.com/questions/447379/what-is-the-use-of-delete-this

2) private 소멸자는 스택에 객체를 생성하는 것을 금지하지만, 이전과 같이 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) private 소멸자는 스택에 객체를 생성하는 것을 금지하지만, 이전과 같이 new 연산자를 통해 이번에는 힙에 객체를 생성할 수 있습니다.

다음은 delete &this의 또 다른 용도입니다.

무언가는 항상 무언가와 함께 할 수 있습니다. 의미는 어떻습니까?

이름을 정하고 디자인 패턴으로 선언한 다음 ... 해야 합니다. 정말 멋집니다. 한 번에 "무언가 삭제"하는 대신 많은 코드를 작성합니다.

 
그리고 private 소멸자는 아마추어 빨판으로부터 개발을 보호합니다. 결국, OOP는 new 및 delete와 함께 성인 방식으로 만 사용할 수 있습니다. 그건 그렇고, 당신은 아직 "패턴"의 이름을 생각한 적이 있습니까?
 
Dmitry Fedoseev :
정말 딱 맞는 별명을 가지고 계시네요))
 
Igor Makanu :

나는 어딘가에서 읽었고 여기 포럼에 그러한 디자인의 예가있었습니다.

간단한 예를 누구나 이것으로 할 수 있습니까?

이 삭제를 삭제하는 질문에 관심이 있습니다. &this;

이것은 현재 개체에 대한 포인터입니다.

일반적으로 delete 이 구문은 new에 의해 객체가 생성되는 경우 사용되지만 삭제에 대한 책임은 객체 자체에 있습니다. 이 경우 객체가 더 이상 필요하지 않다고 판단 하면 초기화 해제 함수를 호출하여 이러한 방식으로 자신을 삭제합니다.

내 생각에 이것은 매우 위험한 관행이며 스마트 포인터의 경우에만 유효합니다. 스마트 포인터는 자체적으로 개체에 대한 참조를 계산하고 참조 수가 0이 되면 스스로 삭제할 수 있습니다. 하지만 이 경우에도 미묘한 메모리 누수 오류가 발생할 여지가 있는 것 같습니다.

제 생각에는 삭제에 대한 책임은 그것을 생성한 동일한 객체에 있어야 합니다. 생성되면 객체 팩토리 패턴을 사용할 수 있지만 삭제는 새 객체를 생성한 객체에서 계속 관리해야 합니다.

1...787980818283848586878889909192...96
새 코멘트