멀티 패스에 관해서 - 나는 서두르고 순진하게도 µl이 이것을 허용할 것이라고 생각했습니다.
여기 변수가 있습니다. 그러나 기능을 사용하면 예, 다중 통과로 밝혀 지므로 모든 것이 올바르게 말했습니다. 문제는 정확히 함수 초기화 순서 때문에 발생합니다. 간단히 말해서 C++에는 변수, 함수 및 유형에 적용되는 엄격한 단일 순서가 있습니다. 그러나 MQL에서는 모든 것이 다릅니다.
Alexey Navoykov : Ну вот я с этого и начинал разговор тут . Планировал тоже заменять все статики на глобалы (хоть это и жесть конечно). Но как показано выше, с шаблонами такое не прокатит. С макросами тоже. А я всё это широко применяю. Поэтому и сделал свою реализацию. Хотя она конечно не решает всех проблем. Динамические массивы по-прежнему нельзя инициализировать, константные типы тоже. Поэтому их однозначно придётся выносить на глобальный уровень
또한 템플릿과 매크로를 광범위하게 사용하지만 동시에 자유 기능은 아키텍처의 보조(원칙적으로 일반적으로 바람직하지 않은) 요소로만 간주합니다. 전체 구현이 객체 내부에 패킹되고 정적이 클래스 수준에서만 선언되면 성가신 잼은 때때로 컴파일러가 맹세하지 않도록 선언의 올바른 순서의 논리를 이해하기 어렵다는 사실과 함께 나타납니다. ..
Alexey Navoykov : 여기 변수가 있습니다. 그러나 기능을 사용하면 예, 다중 통과로 밝혀 지므로 모든 것이 올바르게 말했습니다. 문제는 정확히 함수 초기화 순서 때문에 발생합니다. 간단히 말해서 C++에는 변수, 함수 및 유형에 적용되는 엄격한 단일 순서가 있습니다. 그러나 MQL에서는 모든 것이 다릅니다.
다중 전달은 어떤 경우에도 좋지 않습니다 - 재귀, 교착 상태 등. 그러나 결국 플러스로 앞으로 선언하는 것이 가능합니다. 따라서 마음만 조심스럽게(명시적 정방향 선언) 다중 패스 컴파일러에서는 지금과는 다릅니다. 마치 어떤 함수에 대해 정방향 선언이 이루어진 것처럼 조만간 이 갈퀴가 이마에 부딪힐 것입니다.
다중 전달은 어떤 경우에도 좋지 않습니다 - 재귀, 교착 상태 등. 그러나 결국 플러스로 앞으로 선언하는 것이 가능합니다. 따라서 현명하고 신중하게 다중 패스 컴파일러를 사용하는 지금과는 다릅니다. 마치 어떤 함수에 대해 전방 선언이 이루어진 것처럼 조만간 이 갈퀴가 이마에 부딪힐 것입니다.
동의한다. 이 주제는 조금 더 일찍 한 번 논의되었습니다. 여기 언어로 이렇게 많은 사람들이 함수 선언의 순서를 귀찮게 할 수 없습니다. 예, 솔직히 말해서, 나 자신도 한때 이것에 만족했습니다) 그리고 플러스로 그의 지루함이 짜증났습니다. 그러나 경험과 함께 이해가 옵니다.
또한 템플릿과 매크로를 광범위하게 사용하지만 동시에 자유 기능은 아키텍처의 보조(원칙적으로 일반적으로 바람직하지 않은) 요소로만 간주합니다. 전체 구현이 객체 내부에 패킹되고 정적이 클래스 수준에서만 선언되면 성가신 잼은 때때로 컴파일러가 맹세하지 않도록 선언의 올바른 순서의 논리를 이해하기 어렵다는 사실과 함께 나타납니다. ..
모든 것이 OOP로 명확하게 구축되면 무료 기능뿐만 아니라 템플릿 메서드도 필요하지 않다는 데 동의합니다. 예, 여기에서만 우리는 C ++와 C # 간의 저개발 하이브리드를 다루고 있습니다. 그래서 목발로 많이 구현해야 함)
인터페이스는 약간 다릅니다. 동일한 코드가 매개변수 클래스에 따라 다른 유형으로 동일한 작업을 수행하도록 하려면(추가 클래스를 선언하지 않고) 인터페이스가 도움이 되지 않습니다.
매개변수의 유형이 다른 경우 해당 유형으로 여러 오버로드된 메소드 를 만드는 것이 논리적입니다. 여전히 함수에서 어떻게든 분리해야 합니다. 따라서 얼굴이없는 유형을 취하는 발보를 울타리보다 별도의 기능으로 나누는 것이 좋습니다. 실수로 무엇이든 전달하면 라이브러리 내부에서 윙윙거리지 않는 컴파일 오류가 발생할 수 있습니다. 아니면 얻지 못할 수도 있습니다. 이는 두 배로 좋지 않습니다)
글쎄, 그것이 내가 여기서 대화를 시작한 곳입니다. 나는 또한 모든 정적을 전역으로 대체할 계획이었습니다(물론 이것은 어렵지만). 그러나 위에 표시된 것처럼 템플릿 에서는 작동하지 않습니다. 매크로도. 그리고 나는 그것을 널리 사용합니다 . 그것이 내가 구현을 만든 이유입니다. 물론 모든 문제를 해결하는 것은 아닙니다. 동적 배열은 여전히 초기화할 수 없으며 상수 유형도 초기화할 수 없습니다. 따라서 그들은 확실히 글로벌 수준으로 가져와야합니다.
멀티 패스에 관해서 - 나는 서두르고 순진하게도 µl이 이것을 허용할 것이라고 생각했습니다.
Ну вот я с этого и начинал разговор тут . Планировал тоже заменять все статики на глобалы (хоть это и жесть конечно). Но как показано выше, с шаблонами такое не прокатит. С макросами тоже. А я всё это широко применяю. Поэтому и сделал свою реализацию. Хотя она конечно не решает всех проблем. Динамические массивы по-прежнему нельзя инициализировать, константные типы тоже. Поэтому их однозначно придётся выносить на глобальный уровень
또한 템플릿과 매크로를 광범위하게 사용하지만 동시에 자유 기능은 아키텍처의 보조(원칙적으로 일반적으로 바람직하지 않은) 요소로만 간주합니다. 전체 구현이 객체 내부에 패킹되고 정적이 클래스 수준에서만 선언되면 성가신 잼은 때때로 컴파일러가 맹세하지 않도록 선언의 올바른 순서의 논리를 이해하기 어렵다는 사실과 함께 나타납니다. ..
여기 변수가 있습니다. 그러나 기능을 사용하면 예, 다중 통과로 밝혀 지므로 모든 것이 올바르게 말했습니다. 문제는 정확히 함수 초기화 순서 때문에 발생합니다. 간단히 말해서 C++에는 변수, 함수 및 유형에 적용되는 엄격한 단일 순서가 있습니다. 그러나 MQL에서는 모든 것이 다릅니다.
다중 전달은 어떤 경우에도 좋지 않습니다 - 재귀, 교착 상태 등. 그러나 결국 플러스로 앞으로 선언하는 것이 가능합니다. 따라서 마음만 조심스럽게(명시적 정방향 선언) 다중 패스 컴파일러에서는 지금과는 다릅니다. 마치 어떤 함수에 대해 정방향 선언이 이루어진 것처럼 조만간 이 갈퀴가 이마에 부딪힐 것입니다.
다중 전달은 어떤 경우에도 좋지 않습니다 - 재귀, 교착 상태 등. 그러나 결국 플러스로 앞으로 선언하는 것이 가능합니다. 따라서 현명하고 신중하게 다중 패스 컴파일러를 사용하는 지금과는 다릅니다. 마치 어떤 함수에 대해 전방 선언이 이루어진 것처럼 조만간 이 갈퀴가 이마에 부딪힐 것입니다.
동의한다. 이 주제는 조금 더 일찍 한 번 논의되었습니다. 여기 언어로 이렇게 많은 사람들이 함수 선언의 순서를 귀찮게 할 수 없습니다. 예, 솔직히 말해서, 나 자신도 한때 이것에 만족했습니다) 그리고 플러스로 그의 지루함이 짜증났습니다. 그러나 경험과 함께 이해가 옵니다.
또한 템플릿과 매크로를 광범위하게 사용하지만 동시에 자유 기능은 아키텍처의 보조(원칙적으로 일반적으로 바람직하지 않은) 요소로만 간주합니다. 전체 구현이 객체 내부에 패킹되고 정적이 클래스 수준에서만 선언되면 성가신 잼은 때때로 컴파일러가 맹세하지 않도록 선언의 올바른 순서의 논리를 이해하기 어렵다는 사실과 함께 나타납니다. ..
모든 것이 OOP로 명확하게 구축되면 무료 기능뿐만 아니라 템플릿 메서드도 필요하지 않다는 데 동의합니다.
OOP가 OOP가 아니더라도 반복적인 코드를 많이 작성하고 싶지 않다면 템플릿 메서드가 필요합니다. 자유 함수는 또 다른 문제입니다. 이미 다른 프로그래밍 스타일입니다.
OOP가 OOP가 아니더라도 반복적인 코드를 많이 작성하지 않으려면 템플릿 메서드가 필요합니다.
OOP에서는 이를 위해 인터페이스가 발명되었습니다.
인터페이스는 여전히 약간 다릅니다. 동일한 코드가 매개변수 클래스에 따라 다른 유형으로 동일한 작업을 수행하도록 하려면(추가 클래스를 선언하지 않고) 인터페이스가 도움이 되지 않습니다.
인터페이스는 약간 다릅니다. 동일한 코드가 매개변수 클래스에 따라 다른 유형으로 동일한 작업을 수행하도록 하려면(추가 클래스를 선언하지 않고) 인터페이스가 도움이 되지 않습니다.
매개변수의 유형이 다른 경우 해당 유형으로 여러 오버로드된 메소드 를 만드는 것이 논리적입니다. 여전히 함수에서 어떻게든 분리해야 합니다. 따라서 얼굴이없는 유형을 취하는 발보를 울타리보다 별도의 기능으로 나누는 것이 좋습니다. 실수로 무엇이든 전달하면 라이브러리 내부에서 윙윙거리지 않는 컴파일 오류가 발생할 수 있습니다. 아니면 얻지 못할 수도 있습니다. 이는 두 배로 좋지 않습니다)
요컨대 본격적인 OOP에서 템플릿 기능은 버팀목입니다(드문 예외가 있음).
요컨대, 본격적인 OOP에서 템플릿 기능은 목발 입니다.
우리가 간다
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
mql5 언어의 특징, 미묘함 및 작업 방법
알렉세이 나보이코프 , 2019.01.25 10:11
글쎄, 그것이 내가 여기서 대화를 시작한 곳입니다. 나는 또한 모든 정적을 전역으로 대체할 계획이었습니다(물론 이것은 어렵지만). 그러나 위에 표시된 것처럼 템플릿 에서는 작동하지 않습니다. 매크로도. 그리고 나는 그것을 널리 사용합니다 . 그것이 내가 구현을 만든 이유입니다. 물론 모든 문제를 해결하는 것은 아닙니다. 동적 배열은 여전히 초기화할 수 없으며 상수 유형도 초기화할 수 없습니다. 따라서 그들은 확실히 글로벌 수준으로 가져와야합니다.