MQL 프로그램은 특정 가상 머신에서 실행됩니다. Renat는 이것에 대해 아무렇지도 않게 그리고 한 번 이상 썼습니다.
자동으로 할당 해제되는 클래스의 인스턴스를 정의할 수 있습니다. 따라서 이러한 인스턴스를 추적하고 필요한 경우 해제하는 몇 가지 메커니즘이 있습니다. 가비지 컬렉터가 아니면 무엇입니까?
적절하게 할당 해제되지 않은 포인터를 통해 초기화된 모든 인스턴스는 프로그램이 종료될 때 누수된 개체로 표시됩니다. 해당 번호와 낭비된 메모리의 총량이 인쇄됩니다. 메모리 누수가 있는 프로그램은 시장에서 검증조차 통과하지 못합니다. 따라서 수동으로 선택한 모든 개체를 포함하여 모든 개체가 고려되고 알려지며 시스템이 인식합니다. 이것은 가비지 수집기가 해결하는 고전적인 작업 중 하나입니다.
에뮬에 가비지 수집기가 없다는 하나의 충분하고 철저한 신호가 있습니다. 새로 만든 후에 삭제해야 합니다.
에뮬에 가비지 수집기가 없다는 하나의 충분하고 철저한 신호가 있습니다. 새로 만든 후에 삭제해야 합니다.
내가 기억하는 한 개발자 중 한 명이 가비지 수집기가 존재한다고 인정했습니다. 그러나 사용자에게는 "그렇지 않은 것처럼"입니다.
글쎄, 새 삭제 쌍에 대해 - 나는 절대적으로 찬성입니다. 일반적으로 요청된 리소스는 이러한 리소스가 요청한 개체를 담당해야 합니다. "객체 공장"과 같은 예외가 있지만 생성된 객체에 대한 책임은 공장에서 이러한 객체를 요청한 사람에게 있다고 특별히 가정합니다.
나는 new가 있고 delete가 필요하지 않은 언어의 상황이 정말 싫다. 그들은 "시스템이 불필요한 것을 제거 할 것입니다."라고 말합니다. 이것은 작업 효율성을 감소시킬 뿐만 아니라(불필요한 개체가 아직 제거되지 않은 경우) 인코더를 낙담시켜 그가 자신의 행동의 결과를 따르지 않도록 합니다.
나는 new가 있고 delete가 필요하지 않은 언어의 상황이 정말 싫다. 그들은 "시스템이 불필요한 것을 제거 할 것입니다."라고 말합니다. 이것은 작업 효율성을 감소시킬 뿐만 아니라(불필요한 개체가 아직 제거되지 않은 경우) 인코더를 낙담시켜 그가 자신의 행동의 결과를 따르지 않도록 합니다.
반대로 생산성은 일반적으로 증가합니다. 수동 삭제는 메인 스레드에서 많은 시간이 걸립니다. + 요소별로 삭제가 발생합니다. 예를 들어 이 항목에서 두 가지 버전의 스크립트를 비교합니다. 속도의 차이는 몇 배입니다. 메모리 효율성도 증가합니다. 가비지 수집기가 개체를 서로 압축하여 이동하기 때문입니다. 수동 제어를 사용하면 메모리에 빈 구멍이 형성되어 더 이상 재사용하기 쉽지 않습니다. 또한 수집기는 다른 흐름에서 작동합니다. 주요 시간은 낭비되지 않습니다. 일반적으로 몇 가지 장점이 있습니다.
반대로 생산성은 일반적으로 증가합니다. 수동 삭제는 메인 스레드에서 많은 시간이 걸립니다. + 요소별로 삭제가 발생합니다. 예를 들어 이 항목에서 두 가지 버전의 스크립트를 비교합니다. 속도의 차이는 몇 배입니다. 메모리 효율성도 증가합니다. 가비지 수집기가 개체를 서로 압축하여 이동하기 때문입니다. 수동 제어를 사용하면 메모리에 빈 구멍이 형성되어 더 이상 재사용하기 쉽지 않습니다. 또한 수집기는 다른 흐름에서 작동합니다. 주요 시간은 낭비되지 않습니다. 일반적으로 몇 가지 장점이 있습니다.
Vasily, 미안하지만 지금 당신이 말하려는 것에 대해 전혀 이해하지 못하고 있습니다. 전혀.
Wikipedia는 최소한 가비지 수집기가 무엇인지 읽습니다. 주요 기능은 통신이 두절된 개체를 제거한다는 것입니다.
이 경우에만 가비지 수집기라고 합니다. 이 두 스크립트는 다른 오페라에서 가져온 것입니다. 스크램블 에그와 함께 신의 선물을 혼동해서는 안됩니다.
그리고 수집가에서 갑자기 생산성이 증가하는 것은 무엇입니까? 이것은 유용한 코드와 하드웨어 사이의 또 다른 개스킷이며 약한 것이 아닙니다.
반대로 생산성은 일반적으로 증가합니다. 수동 삭제는 메인 스레드에서 많은 시간이 걸립니다. + 요소별로 삭제가 발생합니다. 예를 들어 이 항목에서 두 가지 버전의 스크립트를 비교합니다. 속도의 차이는 몇 배입니다. 메모리 효율성도 증가합니다. 가비지 수집기가 개체를 서로 압축하여 이동하기 때문입니다. 수동 제어를 사용하면 메모리에 빈 구멍이 형성되어 더 이상 재사용하기 쉽지 않습니다. 또한 수집기는 다른 흐름에서 작동합니다. 주요 시간은 낭비되지 않습니다. 일반적으로 몇 가지 장점이 있습니다.
흠... 가비지 컬렉터에서 삭제는 필수 요소인가요? 말할 것도 없이 다른 스레드는 여유 코어가 없을 때 동일한 코어의 힘에 의해 수행되어 메인 스레드의 속도를 늦춥니다.
제 생각에는 일반적인 경우에 신중하게 접근하면 수집기에서 제거하는 것보다 항상 사용자에 의한 가비지 수집이 더 효과적입니다. 그러나 부주의한 접근 방식을 사용하면 가비지 수집기가 확실히 이깁니다.
이것이 내가 수집가를 좋아하지 않는 이유입니다. 이는 자원을 매우 부주의하게 처리하도록 조장합니다.
이것은 아마도 작업이 끝날 때 메모리 누수에 대한 메시지를 제공하는 "수집기"일 것입니다.
아마도 버려진 물건을 삭제하기도 합니다. 그러나 그가 그것들을 제거하더라도 큰
차이점 - 작업 완료 시에만 삭제합니다. 그리고 수천 개의 사이클에서 생성하는 경우
새로운 물건? 프로그램이 작동하지 않고 메모리가 충분하지 않습니다.
실제 수집기는 프로그램이 실행되는 동안 고아 개체를 제거합니다.
완료 시에만. 따라서 다음과 같은 특별한 스타일의 프로그래밍을 허용합니다.
어떤 조건과 수량에서도 물체를 생산하는 것이 가능합니다.
괜찮은. 이것이 내가 수집기와 함께 작업하는 것을 좋아하지 않는 이유입니다. 사용자는 그가 생성한 개체의 수와 위치에 관심을 멈춥니다.
원칙적으로 개발은 어딘가에서 단순화됩니다. 바쁜 것을 삭제하는 것을 기억할 필요가 없습니다. 수집기 자체는 아무도 개체를 참조하지 않는 순간을 결정하고 자체적으로 삭제합니다. 그러나, 이 입장은 나를 역겹게 한다. 이러한 위치 덕분에 우리는 점점 더 느리게 작동하는 프로그램을 갖게 되었으며, 유사한 복잡성의 작업을 위해 점점 더 강력한 하드웨어 리소스가 필요하게 되었습니다.
Vasily, 미안하지만 지금 당신이 말하려는 것에 대해 전혀 이해하지 못하고 있습니다. 전혀.
Dmitry, 실례합니다. mukl 이외의 프로그래밍 언어를 하나 이상 알고 있습니까? 아니, 당신은하지 않습니다. 그리고 그들은 여전히 객체와 포인터로 작업하는 방법을 배우지 못했습니다. 이것은 여러분이 게시한 몇 가지 코드와 기사에서도 분명합니다. 그래서 저는 이 천박하고 솔직하게 바보 같은 댓글에 진지하게 대답조차 할 수 없습니다. 글쎄, 마지막으로 Wikipedia나 뭔가를 읽고, 가비지 수집기가 무엇인지, 어떻게 작동하는지 읽고, 참조하려는 내용을 한 번 이상 읽으십시오. 그 동안에는 모든 것이 캐러밴에서 개가 짖는 것처럼 보입니다. 무분별하고 무자비합니다.
공식적으로 그렇습니다. 비공식적으로 많은 것들이 그가 여전히 존재함을 나타냅니다.
에뮬에 가비지 수집기가 없다는 하나의 충분하고 철저한 신호가 있습니다. 새로 만든 후에 삭제해야 합니다.
에뮬에 가비지 수집기가 없다는 하나의 충분하고 철저한 신호가 있습니다. 새로 만든 후에 삭제해야 합니다.
내가 기억하는 한 개발자 중 한 명이 가비지 수집기가 존재한다고 인정했습니다. 그러나 사용자에게는 "그렇지 않은 것처럼"입니다.
글쎄, 새 삭제 쌍에 대해 - 나는 절대적으로 찬성입니다. 일반적으로 요청된 리소스는 이러한 리소스가 요청한 개체를 담당해야 합니다. "객체 공장"과 같은 예외가 있지만 생성된 객체에 대한 책임은 공장에서 이러한 객체를 요청한 사람에게 있다고 특별히 가정합니다.
나는 new가 있고 delete가 필요하지 않은 언어의 상황이 정말 싫다. 그들은 "시스템이 불필요한 것을 제거 할 것입니다."라고 말합니다. 이것은 작업 효율성을 감소시킬 뿐만 아니라(불필요한 개체가 아직 제거되지 않은 경우) 인코더를 낙담시켜 그가 자신의 행동의 결과를 따르지 않도록 합니다.
나는 new가 있고 delete가 필요하지 않은 언어의 상황이 정말 싫다. 그들은 "시스템이 불필요한 것을 제거 할 것입니다."라고 말합니다. 이것은 작업 효율성을 감소시킬 뿐만 아니라(불필요한 개체가 아직 제거되지 않은 경우) 인코더를 낙담시켜 그가 자신의 행동의 결과를 따르지 않도록 합니다.
반대로 생산성은 일반적으로 증가합니다. 수동 삭제는 메인 스레드에서 많은 시간이 걸립니다. + 요소별로 삭제가 발생합니다. 예를 들어 이 항목에서 두 가지 버전의 스크립트를 비교합니다. 속도의 차이는 몇 배입니다. 메모리 효율성도 증가합니다. 가비지 수집기가 개체를 서로 압축하여 이동하기 때문입니다. 수동 제어를 사용하면 메모리에 빈 구멍이 형성되어 더 이상 재사용하기 쉽지 않습니다. 또한 수집기는 다른 흐름에서 작동합니다. 주요 시간은 낭비되지 않습니다. 일반적으로 몇 가지 장점이 있습니다.
반대로 생산성은 일반적으로 증가합니다. 수동 삭제는 메인 스레드에서 많은 시간이 걸립니다. + 요소별로 삭제가 발생합니다. 예를 들어 이 항목에서 두 가지 버전의 스크립트를 비교합니다. 속도의 차이는 몇 배입니다. 메모리 효율성도 증가합니다. 가비지 수집기가 개체를 서로 압축하여 이동하기 때문입니다. 수동 제어를 사용하면 메모리에 빈 구멍이 형성되어 더 이상 재사용하기 쉽지 않습니다. 또한 수집기는 다른 흐름에서 작동합니다. 주요 시간은 낭비되지 않습니다. 일반적으로 몇 가지 장점이 있습니다.
Vasily, 미안하지만 지금 당신이 말하려는 것에 대해 전혀 이해하지 못하고 있습니다. 전혀.
Wikipedia는 최소한 가비지 수집기가 무엇인지 읽습니다. 주요 기능은 통신이 두절된 개체를 제거한다는 것입니다.
이 경우에만 가비지 수집기라고 합니다. 이 두 스크립트는 다른 오페라에서 가져온 것입니다. 스크램블 에그와 함께 신의 선물을 혼동해서는 안됩니다.
그리고 수집가에서 갑자기 생산성이 증가하는 것은 무엇입니까? 이것은 유용한 코드와 하드웨어 사이의 또 다른 개스킷이며 약한 것이 아닙니다.
내가 기억하는 한 개발자 중 한 명이 가비지 수집기가 존재한다고 인정했습니다. 그러나 사용자에게는 "그렇지 않은 것처럼"입니다.
///
이것은 아마도 작업이 끝날 때 메모리 누수에 대한 메시지를 제공하는 "수집기"일 것입니다.
아마도 버려진 물건을 삭제하기도 합니다. 그러나 그가 그것들을 제거하더라도 큰
차이점 - 작업 완료 시에만 삭제합니다. 그리고 수천 개의 사이클에서 생성하는 경우
새로운 물건? 프로그램이 작동하지 않고 메모리가 충분하지 않습니다.
실제 수집기는 프로그램이 실행되는 동안 고아 개체를 제거합니다.
완료 시에만. 따라서 다음과 같은 특별한 스타일의 프로그래밍을 허용합니다.
어떤 조건과 수량에서도 물체를 생산하는 것이 가능합니다.
반대로 생산성은 일반적으로 증가합니다. 수동 삭제는 메인 스레드에서 많은 시간이 걸립니다. + 요소별로 삭제가 발생합니다. 예를 들어 이 항목에서 두 가지 버전의 스크립트를 비교합니다. 속도의 차이는 몇 배입니다. 메모리 효율성도 증가합니다. 가비지 수집기가 개체를 서로 압축하여 이동하기 때문입니다. 수동 제어를 사용하면 메모리에 빈 구멍이 형성되어 더 이상 재사용하기 쉽지 않습니다. 또한 수집기는 다른 흐름에서 작동합니다. 주요 시간은 낭비되지 않습니다. 일반적으로 몇 가지 장점이 있습니다.
흠... 가비지 컬렉터에서 삭제는 필수 요소인가요? 말할 것도 없이 다른 스레드는 여유 코어가 없을 때 동일한 코어의 힘에 의해 수행되어 메인 스레드의 속도를 늦춥니다.
제 생각에는 일반적인 경우에 신중하게 접근하면 수집기에서 제거하는 것보다 항상 사용자에 의한 가비지 수집이 더 효과적입니다. 그러나 부주의한 접근 방식을 사용하면 가비지 수집기가 확실히 이깁니다.
이것이 내가 수집가를 좋아하지 않는 이유입니다. 이는 자원을 매우 부주의하게 처리하도록 조장합니다.
이것은 아마도 작업이 끝날 때 메모리 누수에 대한 메시지를 제공하는 "수집기"일 것입니다.
아마도 버려진 물건을 삭제하기도 합니다. 그러나 그가 그것들을 제거하더라도 큰
차이점 - 작업 완료 시에만 삭제합니다. 그리고 수천 개의 사이클에서 생성하는 경우
새로운 물건? 프로그램이 작동하지 않고 메모리가 충분하지 않습니다.
실제 수집기는 프로그램이 실행되는 동안 고아 개체를 제거합니다.
완료 시에만. 따라서 다음과 같은 특별한 스타일의 프로그래밍을 허용합니다.
어떤 조건과 수량에서도 물체를 생산하는 것이 가능합니다.
괜찮은. 이것이 내가 수집기와 함께 작업하는 것을 좋아하지 않는 이유입니다. 사용자는 그가 생성한 개체의 수와 위치에 관심을 멈춥니다.
원칙적으로 개발은 어딘가에서 단순화됩니다. 바쁜 것을 삭제하는 것을 기억할 필요가 없습니다. 수집기 자체는 아무도 개체를 참조하지 않는 순간을 결정하고 자체적으로 삭제합니다. 그러나, 이 입장은 나를 역겹게 한다. 이러한 위치 덕분에 우리는 점점 더 느리게 작동하는 프로그램을 갖게 되었으며, 유사한 복잡성의 작업을 위해 점점 더 강력한 하드웨어 리소스가 필요하게 되었습니다.
Vasily, 미안하지만 지금 당신이 말하려는 것에 대해 전혀 이해하지 못하고 있습니다. 전혀.
흠... 가비지 컬렉터에서 삭제는 필수 요소인가요? 말할 것도 없이 다른 스레드는 여유 코어가 없을 때 동일한 코어의 힘에 의해 수행되어 메인 스레드의 속도를 늦춥니다.
제 생각에는 일반적인 경우에 신중하게 접근하면 수집기에서 제거하는 것보다 항상 사용자에 의한 가비지 수집이 더 효과적입니다. 그러나 부주의한 접근 방식을 사용하면 가비지 수집기가 확실히 이깁니다.
이것이 내가 수집가를 좋아하지 않는 이유입니다. 이는 자원을 매우 부주의하게 처리하도록 조장합니다.
피커가 어떻게 작동하는지 추측하기 보다는 객체 자동 삭제와 수동 삭제 속도를 비교하면 됩니다. 모든 환상은 즉시 사라질 것입니다.
개체의 자동 삭제와 수동 삭제의 속도를 비교합니다.
즉시 답변하는 것이 바람직합니다. 실험할 시간이 항상 있는 것은 아닙니다.