많은 작은 기능을 병합하는 매우 좋은 인라이너가 있으므로 속도 손실이 없음을 잊지 마십시오.
또한 대부분의 경우 vtable을 통한 가상 함수 호출은 직접 호출로 최적화됩니다. 이것은 효과적인 옵티마이저 방법 중 하나입니다. 다중 인라인과 결합되어 복잡한 다중 수준 호출을 거의 완전히 제거하고 코드를 평면 보기로 전환할 수 있습니다.
:) 미소를 지었다. 그리고 컴파일러가 코드를 완벽하게 최적화한다고 주장하는 사람은 아무도 없습니다. 저는 친구에게 제가 왜 SB 앞에 절하지 않는지에 대한 아이디어를 가져왔습니다.
좋습니다. 몇 가지 예를 들어보겠습니다.
class CiCustom : public CIndicator : public CDoubleBuffer
пользуется включением class CSeries : public CArrayObj который в свою очередь
пользуется включением class CArrayDouble : public CArray и
class CArrayObj : public CArray ну и конечно куда как без
включения class CArray : public CObject который включает
class CObject и #include "StdLibErr.mqh"
실제로는 간단한 표준 함수로 대체됩니다.
CopyBuffer (...);
우리는 예술을 위한 예술을 가지고 있습니다. 그리고 무언가를 수행하는 각 요소에 대해 계속 진행됩니다(나머지는 최종 요소가 작동하도록 작성되었습니다).
예, 보편성에 동의합니다. 예, 잘 구성된 코드에 동의합니다(연구용 샘플을 말할 수 있음).
그리고 요점은 무엇입니까? 그리고 결론은 이 라이브러리는 주로 "MQL5 Wizard"와 OOP에 대한 교과서로 필요하다는 것입니다.
나는 단지 내 친구에게 내가 왜 안전보장이사회 앞에 엎드려 절하지 않는지에 대한 아이디어를 가져왔습니다.
예, 예, 다시 한 번 강조하겠습니다. 귀하의 주장에 대해 심각한 이의가 없습니다. 이 문제에 대한 논쟁은 객관적이기보다는 종교적일 것입니다.
여기, 귀하 자신의 예에서 개인적으로, 그리고 내 경우에는 코드의 첫 번째 버전이 더 수용 가능한 것처럼 보입니다. 정확히는 모든 인터페이스와 표시기의 보편성과 호환성을 제공하는 이러한 모든 다단계 포함으로 인해 더 적합합니다. CObject', 그리고 CiCustom'om으로 끝납니다. 이 개체는 이러한 수준 중 하나로 작업하는 방법을 알고 있는 모든 사용자에게 전달할 수 있으며 추가 노력이 필요하지 않습니다.
그러나 다른 한편으로 내 모든 시계열 및 표시기는 요청에 따라 생성되고 단일 컬렉션에 적합하며 모든 사용자가 사용할 수 있습니다. 그리고 버퍼를 한 번 복사해야 할 때 - 문제가 발생합니다 - 울타리 정원은 어떻습니까?
그러나 이 버퍼의 사용자가 12명이라면 어떻게 될까요? 제 경우에는 모두 버퍼에 적용되며 첫 번째 요청에서 버퍼가 생성되고 다른 모든 사람들은 단순히 버퍼에 대한 링크를 받습니다. 그리고 "이마에" CopyBuffer()를 사용하면 하나가 아닌 10개의 복사본이 생깁니다. CopyBuffer()를 더 미묘하게 사용하면 누가, 어떤 버퍼가 할당되었는지 추적하는 종소리와 휘파람을 얻을 수 있으며, 이는 언급한 캡슐화 비용과 상당히 비슷합니다.
개인적으로 저는 합리성을 지지합니다. 한 곳에서 OOP로 정원을 울타리로 묶는 것은 의미가 없습니다. 사용자가 많으면 OOP 접근 방식이 정당하다고 생각합니다.
많은 작은 기능을 병합하는 매우 좋은 인라이너가 있으므로 속도 손실이 없음을 잊지 마십시오.
또한 대부분의 경우 vtable을 통한 가상 함수 호출은 직접 호출로 최적화됩니다. 이것은 효과적인 옵티마이저 방법 중 하나입니다. 다중 인라인과 결합되어 복잡한 다중 수준 호출을 거의 완전히 제거하고 코드를 평면 보기로 전환할 수 있습니다.
많은 작은 기능을 병합하는 매우 좋은 인라이너가 있으므로 속도 손실이 없음을 잊지 마십시오.
또한 대부분의 경우 vtable을 통한 가상 함수 호출은 직접 호출로 최적화됩니다. 이것은 효과적인 옵티마이저 방법 중 하나입니다. 다중 인라인과 결합되어 복잡한 다중 수준 호출을 거의 완전히 제거하고 코드를 평면 보기로 전환할 수 있습니다.
:) 미소를 지었다. 그리고 컴파일러가 코드를 완벽하게 최적화한다고 주장하는 사람은 아무도 없습니다. 저는 친구에게 제가 왜 SB 앞에 절하지 않는지에 대한 아이디어를 가져왔습니다.
좋습니다. 몇 가지 예를 들어보겠습니다.
실제로는 간단한 표준 함수로 대체됩니다.
CopyBuffer (...);우리는 예술을 위한 예술을 가지고 있습니다. 그리고 무언가를 수행하는 각 요소에 대해 계속 진행됩니다(나머지는 최종 요소가 작동하도록 작성되었습니다).
예, 보편성에 동의합니다. 예, 잘 구성된 코드에 동의합니다(연구용 샘플을 말할 수 있음).
그리고 요점은 무엇입니까? 그리고 결론은 이 라이브러리는 주로 "MQL5 Wizard"와 OOP에 대한 교과서로 필요하다는 것입니다.
나는 단지 내 친구에게 내가 왜 안전보장이사회 앞에 엎드려 절하지 않는지에 대한 아이디어를 가져왔습니다.
예, 예, 다시 한 번 강조하겠습니다. 귀하의 주장에 대해 심각한 이의가 없습니다. 이 문제에 대한 논쟁은 객관적이기보다는 종교적일 것입니다.
여기, 귀하 자신의 예에서 개인적으로, 그리고 내 경우에는 코드의 첫 번째 버전이 더 수용 가능한 것처럼 보입니다. 정확히는 모든 인터페이스와 표시기의 보편성과 호환성을 제공하는 이러한 모든 다단계 포함으로 인해 더 적합합니다. CObject', 그리고 CiCustom'om으로 끝납니다. 이 개체는 이러한 수준 중 하나로 작업하는 방법을 알고 있는 모든 사용자에게 전달할 수 있으며 추가 노력이 필요하지 않습니다.
그러나 다른 한편으로 내 모든 시계열 및 표시기는 요청에 따라 생성되고 단일 컬렉션에 적합하며 모든 사용자가 사용할 수 있습니다. 그리고 버퍼를 한 번 복사해야 할 때 - 문제가 발생합니다 - 울타리 정원은 어떻습니까?
따라서 간단한 경우에 - 확실히 CopyBuffer() 를 사용하는 것이 훨씬 쉬울 것입니다.
그러나 이 버퍼의 사용자가 12명이라면 어떻게 될까요? 제 경우에는 모두 버퍼에 적용되며 첫 번째 요청에서 버퍼가 생성되고 다른 모든 사람들은 단순히 버퍼에 대한 링크를 받습니다. 그리고 "이마에" CopyBuffer()를 사용하면 하나가 아닌 10개의 복사본이 생깁니다. CopyBuffer()를 더 미묘하게 사용하면 누가, 어떤 버퍼가 할당되었는지 추적하는 종소리와 휘파람을 얻을 수 있으며, 이는 언급한 캡슐화 비용과 상당히 비슷합니다.
개인적으로 저는 합리성을 지지합니다. 한 곳에서 OOP로 정원을 울타리로 묶는 것은 의미가 없습니다. 사용자가 많으면 OOP 접근 방식이 정당하다고 생각합니다.
그런 다음 하나의 코드가 mql4와 mql5 모두에서 컴파일될 수 있도록 예외를 도입할 때입니다.
통일의 문제는 그것이 어떻게 만들어지는가이다.
여기에서는 두 언어를 결합할 때 #ifdef와 같은 조건부 컴파일 지시문이 절대적으로 필요하다고 생각했습니다. 이는 두 플랫폼 간의 코드 통합을 크게 단순화하고 플랫폼 종속 API는 컴파일 단계에서 결정됩니다.
불행하게도. 테스터는 MQL5 Cloud Network 없이 단일 스레드로 유지됩니다.
많은 작은 기능을 병합하는 매우 좋은 인라이너가 있으므로 속도 손실이 없음을 잊지 마십시오.
또한 대부분의 경우 vtable을 통한 가상 함수 호출은 직접 호출로 최적화됩니다. 이것은 효과적인 옵티마이저 방법 중 하나입니다. 다중 인라인과 결합되어 복잡한 다중 수준 호출을 거의 완전히 제거하고 코드를 평면 보기로 전환할 수 있습니다.
아... 이제 내가 프로그램을 작성할 때 가장 흔히 저지르는 실수 중 하나가 "함수는 본체를 가져야 한다"는 것인 이유를 이해합니다.
이 인라이너는 ... 그렇지 않으면 나에게 놀랐습니다. 함수 헤더가 모듈을 컴파일하기에 충분한 것처럼 보이지만 ... 당신은 바디가 필요합니다 ...
글쎄, 좋아.
아... 이제 내가 프로그램을 작성할 때 가장 흔히 저지르는 실수 중 하나가 "함수는 본체를 가져야 한다"는 것인 이유를 이해합니다.
이 인라이너는 ... 그렇지 않으면 나에게 놀랐습니다. 함수 헤더가 모듈을 컴파일하기에 충분한 것처럼 보이지만 ... 당신은 바디가 필요합니다 ...
모두 올바르게 작성되지만 옵티마이저와 관련이 없습니다.
클래스 함수의 프로토타입 이 설명되면 본문이 있어야 합니다. 비어 있더라도.
Renat , 터미널의 일반 매개변수가 아니라 각 차트에 대해 별도로 차트의 위치 가시성을 제어하기 위해 MT4에서 제안합니다(MT5에서 수행된 것처럼).
이 문제에 대한 SD에 대한 나의 신청은 두 번째 달 동안 움직이지 않고 있습니다.
Renat , 터미널의 일반 매개변수가 아니라 각 차트에 대해 별도로 차트의 위치 가시성을 제어하기 위해 MT4에서 제안합니다(MT5에서 수행된 것처럼).
이 문제에 대한 SD에 대한 나의 신청은 두 번째 달 동안 움직이지 않고 있습니다.