스택 1을 통해 동적 개체를 관리한다는 것은 각 개체에 대해 추가로 24바이트의 메모리를 할당하는 것을 의미합니다(이는 "스택 포인터" + 개체 자체에 대한 참조가 "가중"되는 양입니다). 또한 속도에 대한 시간 비용은 작지 않고 강력합니다. 종합하면 안타까운 일이다. 그러나 이것 역시 특별히 필요하지 않습니다. 두려움은 그들이 말했듯이 큰 눈을 가지고 있습니다. 우리가 여기에서 우주 정거장을 프로그래밍한다면 물론 엄격한 통제 없이는 할 수 없습니다. 따라서 제대로 작동하는 클래스 시스템이 있으면 모든 것이 잘 작동합니다.
아니요, 가비지 수집기에 관한 것이 아니라 스마트 포인터에 관한 것입니다. unique_ptr, shared_ptr(참조 카운팅 포함), RAII는 Google에서 쉽게 찾을 수 있습니다. 일반적으로 메모리(래퍼 == 포인터 크기) 측면에서 unique_ptr에 대한 추가 지불이 없으며 호출이 최적화되지만 모든 것이 µl로 표시됩니다. 그러나 이것은 여기에서 필요하지 않습니다(스마트 포인터).
자폭? - 이것은 새로운 것입니다 :).
네, 자폭합니다. 이것이 "스택" 개체와 동적 개체의 차이점을 알고 있다고 가정합니다. 삭제해야 할 때 묻지 않고 상위 프로그램 블록을 종료할 때 삭제합니다. :)
복사/이동 생성자/연산자에 대해 들어보셨을 겁니다. 맞죠?:
obj o; { obj q; o = q; o = move(q); // С++ вариант, более эффективный }복사/이동 생성자/연산자에 대해 들어보셨을 겁니다. 맞죠?:
즉, 우리는이 결정적인 순간을 지키고있을 것입니다. 우리가 늦지 않는다면 여전히 그것을 복사 할 것입니까? :ㅋㅋㅋ:
우리가 OOP를 정말 싫어해서 그런 걸까요, 아니면 다른 숨겨진 이유가 있는 걸까요?
즉, 우리는이 결정적인 순간을 지키고있을 것입니다. 우리가 늦지 않는다면 여전히 그것을 복사 할 것입니까? :ㅋㅋㅋ:
우리가 OOP를 정말 싫어해서 그런 걸까요, 아니면 다른 숨겨진 이유가 있는 걸까요?
당연하지만 다른 방법은? 괜찮은 프로그래머라면 스택 객체(RAII 기술)를 통해 동적 객체도 관리해야 합니다.
{ unique_ptr<Class> p( new Class); ... // ой, самоуничтожение :) }당연하지만 다른 방법은? 괜찮은 프로그래머라면 스택 객체(RAII 기술)를 통해 동적 객체도 관리해야 합니다.
가비지 컬렉터 말씀하시는건가요? ))) 또는 링크 수에 대한 설명. 나는 최근에 이 칩들을 다루었다. 그러나 이러한 모든 접근 방식의 성능은 불행히도 μl에서 절름발이입니다.
아니요, 가비지 수집기에 관한 것이 아니라 스마트 포인터에 관한 것입니다. unique_ptr, shared_ptr(참조 카운팅 포함), RAII는 Google에서 쉽게 찾을 수 있습니다. 일반적으로 메모리(래퍼 == 포인터 크기) 측면에서 unique_ptr에 대한 추가 지불이 없으며 호출이 최적화되지만 모든 것이 µl로 표시됩니다. 그러나 이것은 여기에서 필요하지 않습니다(스마트 포인터).
또는 템플릿을 사용하여 다음과 같이 작성할 수 있습니다.
https://www.mql5.com/ru/forum/295485/page18#comment_9971363
버튼은 또한 다형성 및 인터페이스 없이 세부 사항에 의존하지 않습니다. 다형성에는 자체 틈새 시장이 있지만 그들이 말하는 것보다 훨씬 좁습니다.
물론 이러한 단순화된 예에서는 템플릿이 더 편리해 보입니다. 실제로 하나의 인스턴스만 있기 때문에 템플릿이 필요하지 않습니다.
물론 이러한 단순화된 예에서는 템플릿이 더 편리해 보입니다. 실제로 하나의 인스턴스만 있기 때문에 템플릿이 필요하지 않습니다.
가상 으로 w를 통한 램프 버튼:
해킹된 예.