mql_coder>> : 보호에 유용할 것입니다. EX5 라이브러리는 인터페이스(가상 기능이 있는 클래스)를 반환합니다. 나와 함께 "일관되지 않는" 사용의 경우 스텁 인터페이스를 반환합니다(계산에서 명확하지 않은 잼이 있음).
가치가 있다면 해킹할 것입니다. 여기서 깨끗한 인간형 인터페이스는 도움이 되지 않습니다. :)
따라서 보호는 다른 모든 곳과 같습니다. 즉, 코드에 대한 물리적 액세스가 부족하고 특정 TS에 트랜잭션 검토가 필요한 지연이 필요합니다(자본은 투자자에게 실시간으로 제공될 수 있음).
뭐, Expert Advisors의 OOP는 이벤트를 시작으로 유능한 지원 및 개선 가능성 등 매우 귀중한 것입니다. 물론 C#이 적합하지 않은 이유는 명확하지 않습니다. 명확한 네임스페이스 선언이 있는 MQL5 프레임워크의 부족과 언어의 비표준 + 미성숙으로 인해 처음에 권장하는 것보다 더 많은 노력이 필요하기 때문입니다. :(
그것들은 이미 비 OOP를 기반으로 합니다(절대 OOP는 실제로 편리하지 않지만). 처음에는 추상 클래스를 만들고 상속과 다형성을 사용하여 실제 개체에 도달해야 했습니다. 예를 들어 추상 메서드 및 속성이 있는 사용자 지정 표시기의 기본 추상 클래스입니다. 간단히 말해서, 계층적 클래스 트리를 구축하십시오. 그래픽 개체, 계정 작업, 차트 및 시계열 액세스 등을 위한 고유한 트리입니다. 그리고 미리 정의된 절차와 기능은 속도가 필요한 기본 루틴만 남겨둡니다. 그런 다음 모든 추상화 수준에서 플랫폼의 기능을 확장하는 것이 가능하여 코드를 크게 줄이고 가독성을 높이고 다른 프로그래머가 쉽게 이해할 수 있습니다. 그리고 MT5에서는 절차 수준(사실, 전체 플랫폼을 사용할 준비가 된 상태)에서 상당히 복잡한 것들이 이미 구현되어 있으며 생성된 내부 구조의 설명자에 대한 포인터로 액세스할 가능성을 보지 못했습니다. 가능성을 제한하십시오 (도움으로 판단). 그리고 일반적으로 OOP의 필요성은 의심스럽습니다. 이러한 구현을 통해 구조 및 동적 배치로 제한할 수 있었습니다. OOP는 분기된 클래스 계층 구조에 의해 아래에서 지원되어야 합니다. 임하
네. 여기 나는 거의 동일합니다. IMHO가 수행되는 방식은 그다지 유용하지 않을 것입니다. 무엇과 주제를 위해. 그러나 그럼에도 불구하고 다른 의견이있을 수 있습니까?
명명된 공백(네임스페이스)이 없으면 정상적인 지원을 제공하는 것이 완전히 현실적이지 않습니다.
작은 소프트웨어에서 이 최신 과시 없이는 가능합니다. 그러나 적어도 Windows와 관련하여 ' 인터페이스 라이브러리 '와 같은 부드럽고 부드러운 기능 없이는 할 수 없습니다. 일반적으로 MT 개발자가 무덤에 대한 흔들리지 않는 충성심으로 작고 부드러운 사람들에게 맹세하고 다른 모든 것에주의를 기울이지 않는 것은 유감입니다. 나는 이미 Vine을 통해 Linux에서 완전히 죄가 없는 MT5를 작동시키는 것이 치질이 될 것이라고 직감합니다. 걱정 마세요. 엄마.
우선순위를 두는 것이 필요합니다. Windows의 점유율은 얼마이고 Linux의 점유율은 얼마입니까? 시장 애플리케이션용 Windows의 점유율은 얼마이며 시장 애플리케이션용 Linux의 점유율은 얼마입니까? 등. 다음으로 Windows 및 Linux에 대한 구현 경제성을 계산해야 합니다. 판매 후 지원을 잊지 마십시오. 결과는 Linux를 선호하는 것과는 거리가 멉니다. 그리고 그것은 단지 단어가 아닙니다. 리소스 분산은 Windows 및 Linux 응용 프로그램의 품질에 영향을 미칩니다. 자원이 소진되더라도 메타쿼트가 시장에 남을 것이라는 것은 사실이 아닙니다. 이제 주요 우선 순위는 Windows용 MT5 릴리스입니다. 이 프로젝트 는 시장에 나와야 합니다. 그런 다음 리소스가 허용하는 경우 다른 운영 체제에 대해 생각하십시오. 세 가지 운영 체제(현재)에 대한 MT4의 동시 유지 관리에도 막대한 리소스가 필요합니다. 또한 MT5의 개발. 인내합시다. MQL5의 OOP는 큰 발전입니다. 또한 MT4에는 없는 다른 많은 기능도 있습니다. OOP가 수요가 있는지 여부 ... 그것은 ... 우리는 대량 적용에 대해 이야기하고 있지 않습니다 ... 그리고 그러한 작업은 없었습니다 - 대중에게 OOP. 소수의 일류 애플리케이션으로도 엄청난 시장 점유율을 확보할 수 있습니다. 그리고 그러한 응용 프로그램이 존재할 것이라는 데는 의심의 여지가 없습니다.
우선순위를 두는 것이 필요합니다. Windows의 점유율은 얼마이고 Linux의 점유율은 얼마입니까? 시장 애플리케이션용 Windows의 점유율은 얼마이며 시장 애플리케이션용 Linux의 점유율은 얼마입니까? 등. 다음으로 Windows 및 Linux에 대한 구현 경제성을 계산해야 합니다. 판매 후 지원을 잊지 마십시오. 결과는 Linux를 선호하는 것과는 거리가 멉니다. 그리고 그것은 단지 단어가 아닙니다. 리소스 분산은 Windows 및 Linux 응용 프로그램의 품질에 영향을 미칩니다. 자원이 소진되더라도 메타쿼트가 시장에 남을 것이라는 것은 사실이 아닙니다. 이제 주요 우선 순위는 Windows용 MT5 릴리스입니다. 이 프로젝트 는 시장에 나와야 합니다. 그런 다음 리소스가 허용하는 경우 다른 운영 체제에 대해 생각하십시오. 세 가지 운영 체제(현재)에 대한 MT4의 동시 유지 관리에도 막대한 리소스가 필요합니다. 또한 MT5의 개발. 인내합시다. MQL5의 OOP는 큰 발전입니다. 또한 MT4에는 없는 다른 많은 기능도 있습니다. OOP가 수요가 있는지 여부 ... 그것은 ... 우리는 대량 적용에 대해 이야기하고 있지 않습니다 ... 그리고 그러한 작업은 없었습니다 - 대중에게 OOP. 소수의 일류 애플리케이션으로도 엄청난 시장 점유율을 확보할 수 있습니다. 그리고 그러한 응용 프로그램이 존재할 것이라는 데는 의심의 여지가 없습니다.
글쎄, 적어도 MQL4를 마스터하는 것은 헛되지 않을 것입니다. 일반 지표만 사용했다면 제가 알기론 리메이크는 그리 어렵지 않을 것입니다.
그래서 평균적인 세미프로 프로그래머는 MQL5에서 OOP가 필요하지 않을 것이라고 생각합니다.
일반적으로 첫 번째 근사치에서 - 속도가 모든 것에서 눈에 띄게 증가하면 - 그것은 좋지만 큰 문제를 해결하기 위해 장점을 실제로 보지 않습니다. 다시 말하지만 저는 전문가가 아닙니다.
이제 애호가들이 MQL5의 원시 수프에서 생명의 기원을 시뮬레이션할 수 있지만? ;)
P/S 잊어버렸습니다. 이벤트 처리 기능 . 좋은.
... 라이브러리는 인터페이스(가상 함수가 있는 클래스)를 반환합니다. 나와 함께 "일관되지 않는" 사용의 경우 스텁 인터페이스를 반환합니다(계산에서 명확하지 않은 잼이 있음).
매트 없이 가능한가요? 여기, 때때로 여성이 포럼에 옵니다.
보호에 유용할 것입니다. EX5 라이브러리는 인터페이스(가상 기능이 있는 클래스)를 반환합니다. 나와 함께 "일관되지 않는" 사용의 경우 스텁 인터페이스를 반환합니다(계산에서 명확하지 않은 잼이 있음).
가치가 있다면 해킹할 것입니다. 여기서 깨끗한 인간형 인터페이스는 도움이 되지 않습니다. :)
따라서 보호는 다른 모든 곳과 같습니다. 즉, 코드에 대한 물리적 액세스가 부족하고 특정 TS에 트랜잭션 검토가 필요한 지연이 필요합니다(자본은 투자자에게 실시간으로 제공될 수 있음).
뭐, Expert Advisors의 OOP는 이벤트를 시작으로 유능한 지원 및 개선 가능성 등 매우 귀중한 것입니다. 물론 C#이 적합하지 않은 이유는 명확하지 않습니다. 명확한 네임스페이스 선언이 있는 MQL5 프레임워크의 부족과 언어의 비표준 + 미성숙으로 인해 처음에 권장하는 것보다 더 많은 노력이 필요하기 때문입니다. :(
그것들은 이미 비 OOP를 기반으로 합니다(절대 OOP는 실제로 편리하지 않지만). 처음에는 추상 클래스를 만들고 상속과 다형성을 사용하여 실제 개체에 도달해야 했습니다. 예를 들어 추상 메서드 및 속성이 있는 사용자 지정 표시기의 기본 추상 클래스입니다. 간단히 말해서, 계층적 클래스 트리를 구축하십시오. 그래픽 개체, 계정 작업, 차트 및 시계열 액세스 등을 위한 고유한 트리입니다. 그리고 미리 정의된 절차와 기능은 속도가 필요한 기본 루틴만 남겨둡니다. 그런 다음 모든 추상화 수준에서 플랫폼의 기능을 확장하는 것이 가능하여 코드를 크게 줄이고 가독성을 높이고 다른 프로그래머가 쉽게 이해할 수 있습니다. 그리고 MT5에서는 절차 수준(사실, 전체 플랫폼을 사용할 준비가 된 상태)에서 상당히 복잡한 것들이 이미 구현되어 있으며 생성된 내부 구조의 설명자에 대한 포인터로 액세스할 가능성을 보지 못했습니다. 가능성을 제한하십시오 (도움으로 판단). 그리고 일반적으로 OOP의 필요성은 의심스럽습니다. 이러한 구현을 통해 구조 및 동적 배치로 제한할 수 있었습니다. OOP는 분기된 클래스 계층 구조에 의해 아래에서 지원되어야 합니다. 임하
네. 여기 나는 거의 동일합니다. IMHO가 수행되는 방식은 그다지 유용하지 않을 것입니다. 무엇과 주제를 위해. 그러나 그럼에도 불구하고 다른 의견이있을 수 있습니까?
Whistles'n'Bells , 확실히. 그러나 외부 개체에 대한 최소한의 지원이 있는 경우 이는 직감입니다.
명명된 공백(네임스페이스)이 없으면 정상적인 지원을 제공하는 것이 완전히 현실적이지 않습니다.
명명된 공백(네임스페이스)이 없으면 정상적인 지원을 제공하는 것이 완전히 현실적이지 않습니다.
작은 소프트웨어에서 이 최신 과시 없이는 가능합니다. 그러나 적어도 Windows와 관련하여 ' 인터페이스 라이브러리 '와 같은 부드럽고 부드러운 기능 없이는 할 수 없습니다. 일반적으로 MT 개발자가 무덤에 대한 흔들리지 않는 충성심으로 작고 부드러운 사람들에게 맹세하고 다른 모든 것에주의를 기울이지 않는 것은 유감입니다. 나는 이미 Vine을 통해 Linux에서 완전히 죄가 없는 MT5를 작동시키는 것이 치질이 될 것이라고 직감합니다. 걱정 마세요. 엄마.