정적 변수가 상수로 초기화되면 이 초기화는 이전과 같이 전역 초기화 단계에서 발생합니다. 그렇지 않으면(호출 또는 변수에 의한 초기화) 정적 변수는 첫 번째 호출에서 초기화됩니다(C ++에서와 유사함). 이러한 호출 자체는 암시적 전역 변수 / 플래그 가 있는 조건으로 래핑됩니다. 예를 들어
MQL 코드의 경우:
class CFoo { };
void func( bool f)
{
if (f)
{
static CFoo foo;
foo.MakeMeHappy();
}
}
매개변수의 유형이 다른 경우 해당 유형으로 여러 오버로드된 메소드 를 만드는 것이 논리적입니다. 여전히 함수에서 어떻게든 분리해야 합니다. 따라서 얼굴이없는 유형을 취하는 발보를 울타리보다 별도의 기능으로 나누는 것이 좋습니다. 실수로 무엇이든 전달하면 라이브러리 내부에서 윙윙거리지 않는 컴파일 오류가 발생할 수 있습니다. 아니면 얻지 못할 수도 있습니다. 이는 두 배로 좋지 않습니다)
요컨대 본격적인 OOP에서 템플릿 기능은 버팀목 입니다(드문 예외가 있음).
그리고 MQL에는 본격적인 OOP가 없습니다 ... 목발도 사라졌습니까? 나는 아무것도 이해하지 못한다.
왜, 지점은 아주 적합합니다. MQL 언어의 기능에 대해 논의 중이며 다중 상속이 없는 것이 상당한 기능입니다)
물론 기본은 다형성이지만 별도의 인터페이스가 없으면 사용하기가 편리하지 않습니다. 이것은 종종 객체가 인터페이스가 아니라 템플릿 인수로 전달되어야 한다는 사실로 이어집니다.
여기에서 여러 인터페이스를 시뮬레이션하는 버전에 대해 설명했습니다. 따라서 내 클래스는 다음과 같이 선언할 수 있습니다.
제 생각에는 모든 것이 그렇게 나쁜 것은 아닙니다. 제 생각에는 동일한 C#에 기본 메인 인터페이스가 많지 않기 때문에(저는 C# 전문가가 아닙니다.) 따라서 해당 메소드는 하나의 기본 수퍼클래스로 축소된 다음 누구에게나 상속될 수 없습니다.
추신 여러 IMHO를 구현하기 위해 <<<<>>>>와 같은 구성을 통해 이것은 어떻게든 한 곳을 통해 이루어집니다. 예를 들어 a==b는 a.compareto(b)를 호출하고 a[comparer]==b는 comparer.compare(a,b)를 호출하는 등 연산자를 통해 기능을 수행하는 것이 좋습니다.
우리가 간다
방법은 다음과 같습니다.
정적 변수가 상수로 초기화되면 이 초기화는 이전과 같이 전역 초기화 단계에서 발생합니다.
그렇지 않으면(호출 또는 변수에 의한 초기화) 정적 변수는 첫 번째 호출에서 초기화됩니다(C ++에서와 유사함). 이러한 호출 자체는 암시적 전역 변수 / 플래그 가 있는 조건으로 래핑됩니다. 예를 들어
MQL 코드의 경우:
다음 의사 코드가 생성됩니다.
CFoo static_func_foo={}; // zeromem only bool static_func_foo_init= false ; void func( bool f) { if (f) { if (!static_func_foo_init) { static_func_foo.CFoo(); // constructor call static_func_foo_init= true ; } static_func_foo.MakeMeHappy(); } }여전히 함수에서 어떻게든 분리해야 합니다.
반드시 그런 것은 아니며 항상 그런 것도 아닙니다. 가지를 어지럽히지 않도록 예를 제시하지 않겠습니다.
방법은 다음과 같습니다.
예, 그런 것입니다. MQL에는 본격적인 OOP가 없기 때문입니다 . 게다가 정기적으로 보고하지만 소용이 없는 버그가 많이 있습니다. 그리고 벌레에 대해 목발로 자신을 방어해야 합니다. 무엇을 할 수 있습니까?
당신은 나를 완전히 혼란 시켰습니다. 만약 ... 당신의 말을 읽으십시오
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
mql5 언어의 특징, 미묘함 및 작업 방법
알렉세이 나보이코프 , 2019.01.25 11:44
매개변수의 유형이 다른 경우 해당 유형으로 여러 오버로드된 메소드 를 만드는 것이 논리적입니다. 여전히 함수에서 어떻게든 분리해야 합니다. 따라서 얼굴이없는 유형을 취하는 발보를 울타리보다 별도의 기능으로 나누는 것이 좋습니다. 실수로 무엇이든 전달하면 라이브러리 내부에서 윙윙거리지 않는 컴파일 오류가 발생할 수 있습니다. 아니면 얻지 못할 수도 있습니다. 이는 두 배로 좋지 않습니다)
요컨대 본격적인 OOP에서 템플릿 기능은 버팀목 입니다(드문 예외가 있음).
MQL에서 다중 상속이 추가되면( 적어도 인터페이스의 경우 그렇지 않으면 현재 형식에서 완전히 쓸모가 없음 ) 일반적으로 이상적입니다.
따라서 인터페이스는 일반 OOP의 기초입니다. 그리고 동시에 MQL에서는 모든 것이 괜찮다고 말합니다.
따라서 인터페이스는 일반 OOP의 기초입니다. 그리고 동시에 MQL에서는 모든 것이 괜찮다고 말합니다.
일반 OOP의 기본은 인터페이스가 아니라 다형성입니다. 인터페이스는 정의된 클래스 구조 의 기초입니다. 일반적으로 이 주제에 대해 이야기하고 싶지만 이 스레드는 그런 주제가 아닙니다.
일반 OOP의 기본은 인터페이스가 아니라 다형성입니다. 인터페이스는 정의된 클래스 구조 의 기초입니다. 일반적으로 이 주제에 대해 이야기하고 싶지만 이 스레드는 그런 주제가 아닙니다.
왜, 지점은 아주 적합합니다. MQL 언어의 기능에 대해 논의 중이며 다중 상속이 없는 것이 상당한 기능입니다)
물론 기본은 다형성이지만 별도의 인터페이스가 없으면 사용하기가 편리하지 않습니다. 이것은 종종 객체가 인터페이스가 아니라 템플릿 인수로 전달되어야 한다는 사실로 이어집니다.
여기에서 여러 인터페이스를 시뮬레이션하는 버전에 대해 설명했습니다. 따라서 내 클래스는 다음과 같이 선언할 수 있습니다.
왜, 지점은 아주 적합합니다. MQL 언어의 기능에 대해 논의 중이며 다중 상속이 없는 것이 상당한 기능입니다)
물론 기본은 다형성이지만 별도의 인터페이스가 없으면 사용하기가 편리하지 않습니다. 이것은 종종 객체가 인터페이스가 아니라 템플릿 인수로 전달되어야 한다는 사실로 이어집니다.
여기에서 여러 인터페이스를 시뮬레이션하는 버전에 대해 설명했습니다. 따라서 내 클래스는 다음과 같이 선언할 수 있습니다.
제 생각에는 모든 것이 그렇게 나쁜 것은 아닙니다. 제 생각에는 동일한 C#에 기본 메인 인터페이스가 많지 않기 때문에(저는 C# 전문가가 아닙니다.) 따라서 해당 메소드는 하나의 기본 수퍼클래스로 축소된 다음 누구에게나 상속될 수 없습니다.
추신 여러 IMHO를 구현하기 위해 <<<<>>>>와 같은 구성을 통해 이것은 어떻게든 한 곳을 통해 이루어집니다. 예를 들어 a==b는 a.compareto(b)를 호출하고 a[comparer]==b는 comparer.compare(a,b)를 호출하는 등 연산자를 통해 기능을 수행하는 것이 좋습니다.