Реter Konow : 예, 전처리기를 사용한 조작의 도움으로 각 파일을 오류 없이 개별적으로 컴파일할 수 있습니다.
그러나 여기에는 오류가 있습니다. 그것들은 전체의 일부이며 다른 부분으로부터 독립성을 "척"해서는 안됩니다. 실제로, 사용자는 모든 파일이 필요하지 않다고 결정할 수 있습니다. 왜냐하면 그렇게 작동하기 때문입니다.
매우 모호한 의미를 가진 그러한 활동에 시간을 낭비합니까? 내가 누구를 속이려고 합니까? 컴파일러?
"숙련된"동지들은 그의 엄한 목소리를 두려워하고 항상 그를 모든 면에서 옳다고 생각합니다. 그래서 그들은 의미가 없더라도 적응하려고 노력합니다.
상수 앞에 (sring)이 와야 했기 때문에 마크업 언어 코드에 수천 개의 경고가 있었습니다. 각 숫자 앞에 유형에 대한 캐스트가 오면 코드가 어떻게 보일지 상상할 수 있습니다. 그러나 경고는 없었습니다.
여기에서 일부 동지들은 사용 편의성을 위해 메타 편집기 자체의 인터페이스를 약간 변경하는 별도의 소프트웨어를 작성하기 위해 작성합니다!
이 표준은 트위터를 통해 모스 부호를 입력하는 대신 키보드를 사용하는 것과 같습니다. 스텁은 컴파일하는 동안 파일 간의 지속적인 페이징 외에는 변경하지 않습니다. 그러나 스텁은 2줄의 코드입니다. 버튼 하나를 누르기 위해 이 뒤집기에 얼마나 많은 시간을 할애할 것입니까? 그리고 삐걱 거리는 소리를 통해 글자를 채우는 데 인생을 낭비하지 않도록 이렇게 7을 몇 번이나 뒤집을 것인가와 더 합리적이되는 것은 무엇입니까?
이제 우리는 객체나 클래스에 대해 이야기하는 것이 아니라 단순히 시간을 절약하는 것에 대해 이야기하고 있음을 주목하십시오. 당신의 시간의 .. 게다가, 당신은 그것을 스스로 작성하기위한 표준을 생각해 낼 수 있습니다.
Peter, 당신은 당신이 원하는대로 나를 대할 수 있습니다. 이것은 당신의 권리입니다. 그러나 조금 더 경험이 풍부한 동지의 조언을 들으십시오.
GUI_DRIVE.mqh 파일은 코드에 먼저 포함됩니다. 그의 앞에 발표된 것은 없습니다.
직접 컴파일하면 G_CORE가 없다는 오류가 발생하고 이 파일에 배열이 선언되지 않았기 때문에 논리적입니다!
결론? 자, 여기서 결론은 기본입니다. 이 배열은 이 파일에서 선언되어야 합니다. 궁극적으로 이 파일이 "엔진"이기 때문에 이 배열과 함께 작동하는 파일입니다! 따라서 사용 컨텍스트에 따라 배열 자체의 선언이 정확합니다.
다음 파일인 CORES.mqh 에서 배열 자체는 양식 요소에 대한 설명으로 채워집니다.
물론 이러한 파일로 EA 자체를 컴파일할 때 배열이 첫 번째 파일에서 선언되면 두 번째 파일을 컴파일할 때 배열이 이미 프로그램 컨텍스트에 표시되기 때문에 컴파일 문제가 없습니다.
그러나 우리는 각 파일이 오류 없이 컴파일되어야 한다는 사실에 대해 이야기하고 있습니다. 두 번째 파일의 G_CORE 배열은 요소로 채워져 있으므로 배열을 선언 하지 않으면 이 파일을 컴파일할 때 오류가 발생하는 것이 매우 자연스럽습니다.
그리고 여기서 우리는 Alexander가 말했듯이 스텁을 사용합니다.
Peter, 당신은 정의에서 "개를 먹었습니다", 그래서 당신은 속임수가 무엇인지 즉시 이해하게 될 것입니다.
GUI_DRIVE 파일에서 핵심 G_CORE 요소의 전역 배열을 선언하면 파일이 오류 없이 컴파일되어야 합니다.
또한 이 파일에서 정의를 추가합니다.
#define __DRIVE__코어로 넘어갑시다. 배열을 선언하기 전에 컴파일 전처리기를 사용하십시오.
그런 다음 배열 자체를 채웁니다. 물론 선언 없이 배열을 채우려면 배열을 채우는 방식을 약간 변경해야 합니다.
핵심을 파악했다고 생각합니다. CORES 파일이 컴파일되면 __DRIVE__ 정의가 없고 배열 선언 코드가 컴파일되고 모든 것이 정상적으로 작동합니다.
파일이 Expert Advisor의 일부로 컴파일된 경우 첫 번째 포함 파일을 컴파일한 후 정의가 선언되고 두 번째 파일에서는 배열이 선언되지 않습니다. 컴파일러가 이 코드 조각을 "잘라내기" 때문입니다.
나는 내가 명확하게 설명하기를 정말로 바랍니다.
다시 말하지만, 각 파일은 오류 없이 컴파일되어야 합니다. 종속성이 있는 경우 해당 위치를 올바르게 제공하고 필요한 경우 재컴파일 프로세서를 추가해야 합니다.
각 파일이 오류 없이 컴파일되면 전체 시스템의 무결성에 대한 확신이 생깁니다.
그리고 각 파일에 속성을 추가하는 것을 잊지 마십시오:
이 속성은 더 엄격한 코드 검사를 제공합니다.
예, 전처리기를 사용한 조작의 도움으로 각 파일을 오류 없이 개별적으로 컴파일할 수 있습니다.
여기에서 일부 동지들은 사용 편의성을 위해 메타 편집기 자체의 인터페이스를 약간 변경하는 별도의 소프트웨어를 작성하기 위해 작성합니다!
이 표준은 트위터를 통해 모스 부호를 입력하는 대신 키보드를 사용하는 것과 같습니다. 스텁은 컴파일하는 동안 파일 간의 지속적인 페이징 외에는 변경하지 않습니다. 그러나 스텁은 2줄의 코드입니다. 버튼 하나를 누르기 위해 이 뒤집기에 얼마나 많은 시간을 할애할 것입니까? 그리고 삐걱 거리는 소리를 통해 글자를 채우는 데 인생을 낭비하지 않도록 이렇게 7을 몇 번이나 뒤집을 것인가와 더 합리적이되는 것은 무엇입니까?
이제 우리는 객체나 클래스에 대해 이야기하는 것이 아니라 단순히 시간을 절약하는 것에 대해 이야기하고 있음을 주목하십시오. 당신의 시간의 .. 게다가, 당신은 그것을 스스로 작성하기위한 표준을 생각해 낼 수 있습니다.기본적으로 영어 개발 환경에서 차별받는 러시아어 코딩에 대해 이야기하는 것이 아닙니다. 또한 적응하고 당신의 두뇌를 비참한 생산성의 30%로 남겨두는 동안 러시아어에서는 100%를 모두 사용할 수 있습니까?
전문 코드에서는 종종 고유한 데이터 유형 을 사용합니다. 나는 그들이 어떤 언어를 사용하는지 상관하지 않습니다.
그러나 함수가 다음 순서로 정수를 기대한다면: (너비, 높이)를 취합시다.
그리고 이것 대신에 우리는 실수로 섞어서 썼습니다.
(높이, 너비)를 취합시다. 그러면 컴파일러 자체가 여기서 우리가 혼란스러워 한다고 말합니다. 그것이 당신을 위해 작동합니까 - 여기에서도 우리는 언어 나 대상에 대해 이야기하고 있지 않습니다. 그리고 나중에 이 실수를 스스로 찾지 않도록
전문 코드에서는 종종 고유한 데이터 유형 을 사용합니다. 나는 그들이 어떤 언어를 사용하는지 상관하지 않습니다.
그러나 함수가 다음 순서로 정수를 기대한다면: (너비, 높이)를 취합시다.
그리고 이것 대신에 우리는 실수로 섞어서 썼습니다.
(높이, 너비)를 취합시다. 그러면 컴파일러 자체가 여기서 우리가 혼란스러워 한다고 말합니다. 그것이 당신을 위해 작동합니까 - 여기에서도 우리는 언어 나 대상에 대해 이야기하고 있지 않습니다. 그리고 나중에 이 실수를 스스로 찾지 않도록
Peter, 당신은 당신이 원하는대로 나를 대할 수 있습니다. 이것은 당신의 권리입니다. 그러나 조금 더 경험이 풍부한 동료 의 조언을 들어보십시오.
.......
그리고 각 파일에 속성을 추가하는 것을 잊지 마십시오:
이 속성은 더 엄격한 코드 검사를 제공합니다.
이것은 상위 5 위 안에 수행됩니다 - 항상 엄격합니다!
비록 일반적으로 동의합니다. 컴파일 중 많은 경고가 코드의 신뢰성을 증가시키지는 않습니다.
이것은 상위 5 위 안에 수행됩니다 - 항상 엄격합니다!
일반적으로 동의하지만 컴파일하는 동안 많은 경고가 코드의 신뢰성을 증가시키지는 않습니다.