글쎄, 내 생각에 이것은 사적이고 기괴하게 단순화 된 경우입니다. 필드의 값을 변경하려면 못을 박고 새 개체를 생성해야 하도록 절대적으로 변경할 수 없는 개체를 만듭니다...
그리고 몇 가지 개체 필드를 변경해야 하는 경우 다른 필드에 필요한 정보를 남겨두시겠습니까? IMHO - 재채기를 할 때마다 총을 들고 앉아서 토끼를 쏘는 것보다 각 개체의 상호 작용성과 제어 가능성을 관리하는 것이 좋습니다(다행히 상속이 있음).
그러나 공정하게 말하면 때로는 많은 수 중에서 필요한 것을 찾아서 변경하는 것보다 새 것을 만들고 만드는 것이 더 빠릅니다. 글쎄, 이것은 물론 그것에 대한 직접 주소 지정이 구성되지 않은 경우 ...
흠, 음, 당신은 거절했습니다 .... 그래서,하지만 그렇지는 않습니다))))
편리하게 사용하세요! - 하지만 "최초의 C++ 교과서"에 있는 이러한 예제는 내 경험에 따라 평생 끌 수 있습니다 .... 예를 들어 @fxsaber 코드의 적절한 부분을 분류하고 #define을 최대로 사용하도록 강요했습니다. - 코드가 더 짧아졌을 뿐만 아니라 읽기도 더 쉽고 맞춤법도 틀립니다. - C++ 책에서 이것을 많이 가르쳐 줍니까? ;)
Artyom Trishkin :
그러나 공정하게 말하면 때로는 많은 수 중에서 필요한 것을 찾아서 변경하는 것보다 새 것을 만들고 만드는 것이 더 빠릅니다. 글쎄, 이것은 물론 그것에 대한 직접 주소 지정이 구성되지 않은 경우 ...
글쎄, 책 같은 기본에 대해 ... 프로그래밍에서 "좋은 형식"의 규칙에 따라 다음이 필요합니다. 변수 선언 - 즉시 초기화(디버깅 중에 버그가 제외되는 방식) OOP에서 생성자는 이러한 역할을 합니다. 목적 - 객체를 생성하고 모든 것을 초기화할 만큼 친절합니다.
"단순한 개체 뒤에 있는 모든 코드를 가져오려면" 클래스의 모든 필드를 다시 초기화하는 메서드가 필요합니다. 왜 이것을 복제합니까? - 죽임 / 창조 = 결과 .... 그러나 다시, 취향과 종교의 문제
통제되지 않은 파괴가 항상 편리한 것은 아니지만 확인해야 할 것입니다. 아마도 내가 틀릴 수 있습니다. - 나는 CObject를 거의 사용하지 않습니다.
그러나 목록을 사용합니다. 그리고 거기 - 같은 것. 글쎄, FreeMode() 메모리 관리 플래그가 목록에 대해 재설정되지 않는 한 - 이 경우 터미널은 추적하지 않습니다 - 사용자가 모든 것을 처리합니다. 그러나 이 상황은 목록의 복사본으로 변경, 삭제, 정렬 및 다른 작업을 수행할 수 있도록 하기 위해 필요합니다. 결국 목록은 개체에 대한 포인터로 만들어지고, 하나의 새 목록 복사본을 만드는 경우 목록의 개체를 변경하고 새 목록 개체에서 변경을 시작하면(개체에 대한 포인터가 있음) 원래 목록의 개체도 변경됩니다(포인터로 작업하기 때문에). 여기에서 원본을 그대로 두고 복사본에서 모의하려면 복사본에 대한 메모리 관리 플래그를 재설정해야 합니다. 원본에 영향을 줍니다. 그리고 우리가 터미널 서브시스템에서 list-copy의 후크를 해제했기 때문에 이제 우리 자신이 목록 객체를 삭제할 책임이 있음을 기억하십시오. 이를 추적하고 OnDeinit()에서 삭제할 수 있습니다. 가장 간단한 경우이며 복사 목록을 미리 알고 있거나 항상 새로 생성된 목록을 배치할 목록 개체를 만들 수 있습니다. 수동 메모리 관리 플래그로 미리 알려지지 않은 것. 그런 다음 터미널은 이 목록 개체를 추적하고 여기에 포함된 목록을 올바르게 삭제합니다.
우리는 어딘가에서 새로운 객체를 생성하고 그것에 대한 포인터를 받았다면 이 포인터로 이 객체를 삭제해야 합니다. 수단 - 포인터를 추적해야 합니다. 이것은 SB에서 제공되는 객체에 대한 포인터의 목록 또는 배열이 매우 적합한 것입니다. 그러나 새로 생성된 개체를 직접 추적하고 제어할 수 있습니다. 하지만 이미 제공되는 코드를 엄청나게 많이 작성해야 하는 이유는 무엇입니까?
편리하게 사용하세요! - 하지만 "최초의 C++ 교과서"에 있는 이러한 예제는 내 경험에 따라 평생 끌 수 있습니다 .... 예를 들어 @fxsaber 코드의 적절한 부분을 분류하고 #define을 최대로 사용하도록 강요했습니다. - 코드가 더 짧아졌을 뿐만 아니라 읽기도 더 쉽고 맞춤법도 틀립니다. - C++ 책에서 이것을 많이 가르쳐 줍니까? ;)
글쎄, 책 같은 기본에 대해 ... 프로그래밍에서 "좋은 형식"의 규칙에 따라 다음이 필요합니다. 변수 선언 - 즉시 초기화(디버깅 중에 버그가 제외되는 방식) OOP에서 생성자는 이러한 역할을 합니다. 목적 - 객체를 생성하고 모든 것을 초기화할 만큼 친절합니다.
"단순한 개체 뒤에 있는 모든 코드를 가져오려면" 클래스의 모든 필드 를 다시 초기화하는 메서드가 필요합니다. 왜 이것을 복제합니까? - 죽임 / 창조 = 결과 .... 그러나 다시, 취향과 종교의 문제
나는 개체의 완전한 재초기화에 대해 말하는 것이 아니라 부분적인 것에 대해 이야기하고 있습니다. 몇 개의 필드를 변경해야 하고 나머지 수십 개의 필드가 여전히 필요한 정보를 저장하는 경우... 여기에서 "당신이 원하는 대로", 그러나 필드를 변경하는 방법이 필요합니다. 다시 말하지만 필드가 하나인 단순한 개체에 대해 이야기하지 마십시오. 둘 이상이 있는 경우 이미 하나를 변경하고 나머지는 변경하지 않은 상태로 둘 필요가 있을 수 있습니다.
삭제를 작성하지 마십시오. 모든 것이 올바르게 작동합니다. 이 죄(미신에 대해 이야기하고 있습니다)))가 터미널을 인수하고 "48바이트의 누출된 메모리" 로그에서 중얼거린 다음 "2개의 CX 유형의 개체가 남습니다" 및 "삭제되지 않은 개체가 남음"
추신: 표시기 생성 템플릿에는 Deinit()이 없습니다.
포인터 대신 객체를 생성하지 않는 이유는 무엇입니까? 그러면 그는 중얼거리지 않을 것입니다. 터미널 하위 시스템이 그를 추적하여 필요할 때 죽일 것입니다.
삭제하지 않고도 작동하지만 요점은 무엇입니까? 그러나 터미널이 이 문제를 처리합니까? 메모리 누수만 보고하지만 동일한 개체를 할당하지 않습니다.
ArrayObj, List 등과 같이 터미널에 알려진 객체에 객체에 대한 포인터가 추가되면 터미널은 new에 의해 생성된 객체 삭제를 처리합니다.
포인터 대신 객체를 생성하지 않는 이유는 무엇입니까? 그러면 그는 중얼거리지 않을 것입니다. 터미널 하위 시스템이 그를 추적하여 필요할 때 죽일 것입니다.
왜냐하면 https://www.mql5.com/ru/forum/85652/page7#comment_12329866
ArrayObj, List 등과 같이 터미널에 알려진 객체에 객체에 대한 포인터가 추가되면 터미널은 new에 의해 생성된 객체 삭제를 처리합니다.
통제되지 않은 파괴가 항상 편리한 것은 아니지만 확인해야 할 것입니다. 아마도 내가 틀릴 수 있습니다. - 나는 CObject를 거의 사용하지 않습니다.
왜냐하면 https://www.mql5.com/ru/forum/85652/page7#comment_12329866
글쎄, 내 생각에 이것은 사적이고 기괴하게 단순화 된 경우입니다. 필드의 값을 변경하려면 못을 박고 새 개체를 생성해야 하도록 절대적으로 변경할 수 없는 개체를 만듭니다...
그리고 몇 가지 개체 필드를 변경해야 하는 경우 다른 필드에 필요한 정보를 남겨두시겠습니까? IMHO - 재채기를 할 때마다 총을 들고 앉아서 토끼를 쏘는 것보다 각 개체의 상호 작용성과 제어 가능성을 관리하는 것이 좋습니다(다행히 상속이 있음).
그러나 공정하게 말하면 때로는 많은 수 중에서 필요한 것을 찾아서 변경하는 것보다 새 것을 만들고 만드는 것이 더 빠릅니다. 글쎄, 이것은 물론 그것에 대한 직접 주소 지정이 구성되지 않은 경우 ...
글쎄, 내 생각에 이것은 사적이고 기괴하게 단순화 된 경우입니다. 필드의 값을 변경하려면 못을 박고 새 개체를 생성해야 하도록 절대적으로 변경할 수 없는 개체를 만듭니다...
그리고 몇 가지 개체 필드를 변경해야 하는 경우 다른 필드에 필요한 정보를 남겨두시겠습니까? IMHO - 재채기를 할 때마다 총을 들고 앉아서 토끼를 쏘는 것보다 각 개체의 상호 작용성과 제어 가능성을 관리하는 것이 좋습니다(다행히 상속이 있음).
그러나 공정하게 말하면 때로는 많은 수 중에서 필요한 것을 찾아서 변경하는 것보다 새 것을 만들고 만드는 것이 더 빠릅니다. 글쎄, 이것은 물론 그것에 대한 직접 주소 지정이 구성되지 않은 경우 ...
흠, 음, 당신은 거절했습니다 .... 그래서,하지만 그렇지는 않습니다))))
편리하게 사용하세요! - 하지만 "최초의 C++ 교과서"에 있는 이러한 예제는 내 경험에 따라 평생 끌 수 있습니다 .... 예를 들어 @fxsaber 코드의 적절한 부분을 분류하고 #define을 최대로 사용하도록 강요했습니다. - 코드가 더 짧아졌을 뿐만 아니라 읽기도 더 쉽고 맞춤법도 틀립니다. - C++ 책에서 이것을 많이 가르쳐 줍니까? ;)
그러나 공정하게 말하면 때로는 많은 수 중에서 필요한 것을 찾아서 변경하는 것보다 새 것을 만들고 만드는 것이 더 빠릅니다. 글쎄, 이것은 물론 그것에 대한 직접 주소 지정이 구성되지 않은 경우 ...
글쎄, 책 같은 기본에 대해 ... 프로그래밍에서 "좋은 형식"의 규칙에 따라 다음이 필요합니다. 변수 선언 - 즉시 초기화(디버깅 중에 버그가 제외되는 방식) OOP에서 생성자는 이러한 역할을 합니다. 목적 - 객체를 생성하고 모든 것을 초기화할 만큼 친절합니다.
"단순한 개체 뒤에 있는 모든 코드를 가져오려면" 클래스의 모든 필드를 다시 초기화하는 메서드가 필요합니다. 왜 이것을 복제합니까? - 죽임 / 창조 = 결과 .... 그러나 다시, 취향과 종교의 문제
왜냐하면 https://www.mql5.com/ru/forum/85652/page7#comment_12329866
통제되지 않은 파괴가 항상 편리한 것은 아니지만 확인해야 할 것입니다. 아마도 내가 틀릴 수 있습니다. - 나는 CObject를 거의 사용하지 않습니다.
그러나 목록을 사용합니다. 그리고 거기 - 같은 것. 글쎄, FreeMode() 메모리 관리 플래그가 목록에 대해 재설정되지 않는 한 - 이 경우 터미널은 추적하지 않습니다 - 사용자가 모든 것을 처리합니다. 그러나 이 상황은 목록의 복사본으로 변경, 삭제, 정렬 및 다른 작업을 수행할 수 있도록 하기 위해 필요합니다. 결국 목록은 개체에 대한 포인터로 만들어지고, 하나의 새 목록 복사본을 만드는 경우 목록의 개체를 변경하고 새 목록 개체에서 변경을 시작하면(개체에 대한 포인터가 있음) 원래 목록의 개체도 변경됩니다(포인터로 작업하기 때문에). 여기에서 원본을 그대로 두고 복사본에서 모의하려면 복사본에 대한 메모리 관리 플래그를 재설정해야 합니다. 원본에 영향을 줍니다. 그리고 우리가 터미널 서브시스템에서 list-copy의 후크를 해제했기 때문에 이제 우리 자신이 목록 객체를 삭제할 책임이 있음을 기억하십시오. 이를 추적하고 OnDeinit()에서 삭제할 수 있습니다. 가장 간단한 경우이며 복사 목록을 미리 알고 있거나 항상 새로 생성된 목록을 배치할 목록 개체를 만들 수 있습니다. 수동 메모리 관리 플래그로 미리 알려지지 않은 것. 그런 다음 터미널은 이 목록 개체를 추적하고 여기에 포함된 목록을 올바르게 삭제합니다.
터미널에 알려진 객체(예: ArrayObj, List 등)에 객체에 대한 포인터가 추가되면 터미널은 new에 의해 생성된 객체 삭제를 처리합니다.
그러면 누출에 대한 메시지가 표시되지 않습니다.
그러면 누출에 대한 메시지가 표시되지 않습니다.
예, 그렇지 않습니다. 누수가 되지 않기 때문에
우리는 어딘가에서 새로운 객체를 생성하고 그것에 대한 포인터를 받았다면 이 포인터로 이 객체를 삭제해야 합니다. 수단 - 포인터를 추적해야 합니다. 이것은 SB에서 제공되는 객체에 대한 포인터의 목록 또는 배열이 매우 적합한 것입니다. 그러나 새로 생성된 개체를 직접 추적하고 제어할 수 있습니다. 하지만 이미 제공되는 코드를 엄청나게 많이 작성해야 하는 이유는 무엇입니까?
그런 다음 주어진 포인터에서 이 객체를 삭제해야 합니다.
하지만 이미 제공되는 코드를 엄청나게 많이 작성해야 하는 이유는 무엇입니까?
우리는 몇 톤에 대해 이야기하고 있습니까? 간과 된 모든 것, 모든 것이 터미널에 의해보고 될 것입니다. 삭제 장소도 알려져 있습니다. - OnDeint() .... 대화가 진공 상태의 구형 말에 대한 토론으로 축소 되었습니까? )))
흠, 음, 당신은 거절했습니다 .... 그래서,하지만 그렇지는 않습니다))))
편리하게 사용하세요! - 하지만 "최초의 C++ 교과서"에 있는 이러한 예제는 내 경험에 따라 평생 끌 수 있습니다 .... 예를 들어 @fxsaber 코드의 적절한 부분을 분류하고 #define을 최대로 사용하도록 강요했습니다. - 코드가 더 짧아졌을 뿐만 아니라 읽기도 더 쉽고 맞춤법도 틀립니다. - C++ 책에서 이것을 많이 가르쳐 줍니까? ;)
글쎄, 책 같은 기본에 대해 ... 프로그래밍에서 "좋은 형식"의 규칙에 따라 다음이 필요합니다. 변수 선언 - 즉시 초기화(디버깅 중에 버그가 제외되는 방식) OOP에서 생성자는 이러한 역할을 합니다. 목적 - 객체를 생성하고 모든 것을 초기화할 만큼 친절합니다.
"단순한 개체 뒤에 있는 모든 코드를 가져오려면" 클래스의 모든 필드 를 다시 초기화하는 메서드가 필요합니다. 왜 이것을 복제합니까? - 죽임 / 창조 = 결과 .... 그러나 다시, 취향과 종교의 문제
나는 개체의 완전한 재초기화에 대해 말하는 것이 아니라 부분적인 것에 대해 이야기하고 있습니다. 몇 개의 필드를 변경해야 하고 나머지 수십 개의 필드가 여전히 필요한 정보를 저장하는 경우... 여기에서 "당신이 원하는 대로", 그러나 필드를 변경하는 방법이 필요합니다. 다시 말하지만 필드가 하나인 단순한 개체에 대해 이야기하지 마십시오. 둘 이상이 있는 경우 이미 하나를 변경하고 나머지는 변경하지 않은 상태로 둘 필요가 있을 수 있습니다.
하지만 아마도 우리는 다른 것에 대해 이야기하고 있습니까?