게다가 제 기억이 맞다면, 이것은 이전에 발생하지 않았습니다. 즉, 가볍게 말해서, 특히 프로그래머의 "편의성"을 위해 추가되었지만 기존 코드의 불변성을 위반하는 "기능"입니다. 이전 초기화 규칙). 따라서 새 버전의 소프트웨어와 이전 코드의 호환성을 유지한다는 흔들리지 않는 원칙은 가능한 한 존중되지 않습니다.
새로운 기능과 최적화에 반대하는 사람은 아무도 없습니다. 그러나 오래된 코드를 깨뜨리지 않도록 왜 만들지 않습니까? 특히 이러한 새로운 초기화의 경우 #property strict와 유추하여 추가적인 전처리기 명령을 할당하는 것이 상당히 가능했습니다. 예를 들어 #property lazyinit를 만들고 프로그래머가 코드에 지정한 경우(즉, 명시적으로, 이는 그가 mql의 새로운 초기화를 알고 있음을 의미함) 최적화된 최적화에 만족합니다. 그리고 지정하지 않으면 이전 코드가 전역 변수 가 남을 수 있는 곳을 삽질하거나 잡는 일 없이 안정적으로 작동하게 되어 기쁩니다. 이제는 선언할 뿐만 아니라 OnInit에서 별도로 초기화해야 합니다. 이러한 각 변수에 대해 한 줄의 코드 대신 2개가 있습니다.
게다가 제 기억이 맞다면, 이것은 이전에 발생하지 않았습니다. 즉, 가볍게 말해서, 특히 프로그래머의 "편의성"을 위해 추가되었지만 기존 코드의 불변성을 위반하는 "기능"입니다. 이전 초기화 규칙). 따라서 새 버전의 소프트웨어와 이전 코드의 호환성을 유지한다는 흔들리지 않는 원칙은 가능한 한 존중되지 않습니다.
새로운 기능과 최적화에 반대하는 사람은 아무도 없습니다. 그러나 오래된 코드를 깨뜨리지 않도록 왜 만들지 않습니까? 특히 이러한 새로운 초기화의 경우 #property strict와 유추하여 추가적인 전처리기 명령을 할당하는 것이 상당히 가능했습니다. 예를 들어 #property lazyinit를 만들고 프로그래머가 코드에 지정한 경우(즉, 명시적으로, 이는 그가 mql의 새로운 초기화를 알고 있음을 의미함) 최적화된 최적화에 만족합니다. 그리고 지정하지 않으면 이전 코드가 전역 변수 가 남을 수 있는 곳을 삽질하거나 잡는 일 없이 안정적으로 작동하게 되어 기쁩니다. 이제는 선언할 뿐만 아니라 OnInit에서 별도로 초기화해야 합니다. 이러한 각 변수에 대해 한 줄의 코드 대신 2개가 있습니다.
저는 topikstarter를 100% 지지합니다. MQ는 최근 네 방향으로 점점 더 많은 함정을 던졌습니다.
몇 가지 새로운 기능을 제공하는 경우 모든 프로그램 수준에서 모든 구성 요소의 작동을 확인해야 합니다.
무한 루프, 타이머 등을 사용했는지 여부는 중요하지 않습니다. MQ에 결함이 있을 때 나쁜 프로그래밍 스타일에 대해 이야기하는 것은 여기에서 부적절합니다.
이 창에서 매개변수를 사용하여 작업한 MQ 개발자는 MQL 프로그램에서 사이클을 사용할 수 있다고 생각조차 하지 못했습니까?
MQ 개발자들이 자신의 존재를 원칙적으로 모른다는 말씀이신가요? 아니면 조정 후에 단순히 소프트웨어를 테스트하지 않습니까?
그냥 그런 느낌입니다.
나는 우리가 어떤 실수나 지연도 용납하지 않는 Forex 시장과 협력한다는 것을 모두에게 상기시키고 싶습니다.
따라서 절대적으로 모든 버그(정보 상호 작용 프로세스 위반) 및 이 경우 USER와 TRADING ROBOT 간의 연결이 명확하게 끊어지는 것이 CRITICALLY IMPORTANT입니다.
하나는 생 5가 기성품 및 디버그 4(삶은 우유는 생우유로 희석됨)에 부은 느낌을 받고 이제 모두가 부풀려집니다.