extern은 MS DOS 시절로 돌아가 모든 것이 컴파일된 단위와 완벽하게 연결되었습니다.
이 대화가 왜? - 관리자가 나타나서 extern 키워드가 MQL에서 구현되는 방법과 이유를 설명하고 extern 수식어와 함께 전역 변수를 사용하여 교환에 대한 제 의견을 썼습니다 - 사용하지 않는 것이 좋습니다
그리고 도서관은 어떻습니까? 그리고 당신의 단위는 어떻습니까? - 단위, 이것은 컴파일러의 미묘함으로 알 필요가 없으며 잘못된 결론을 내리지 않도록 모르는 것이 훨씬 좋습니다. 그리고 관리자가 어제 명확하지 않은 설명은 무엇입니까? 그것이 어떻게 포함과 가져오기를 구별할 수 없는지 명확하지 않습니다. 포함 및 수입은 여전히 차르 완두콩 아래 있었고 지금처럼 작동했습니다.
전체 농담은 extern이 단순히 필요하지 않다는 것입니다. 모든 프로젝트 파일의 전역 수준에서 선언된 변수는 모든 파일에서 사용할 수 있습니다. 무엇 때문에? 제작자에게 질문합니다.
그럼 따로 작업을 하는 과정에서 따로 파일을 컴파일 할 수 있도록 하기 위해서다. 매번 다른 파일로 건너뛰는 대신 전체 프로젝트 가 컴파일될 때까지 기다리지 마십시오.
예제가 필요합니다. 라이브러리에서 extern을 사용해 보았습니다. 작동하지 않습니다. https://www.mql5.com/en/forum/316795/page2#comment_12259472
따라서 결국 라이브러리에서 선언된 전역 변수는 이 라이브러리를 제외하고는 어디에서도 볼 수 없습니다. 그들이 라이브러리에서 전역 변수를 선언하고 왜 그것이 어디에도 표시되지 않는지 의아해한다면. #가져오기는 #include가 아닙니다
따라서 결국 라이브러리에서 선언된 전역 변수는 이 라이브러리를 제외하고는 어디에서도 볼 수 없습니다. 그들이 라이브러리에서 전역 변수를 선언하고 왜 그것이 어디에도 표시되지 않는지 의아해한다면. #가져오기는 #include가 아닙니다
extern은 MS DOS 시절로 돌아가 모든 것이 컴파일된 단위와 완벽하게 연결되었습니다.
이 대화가 왜? - 관리자가 나타나서 extern 키워드가 MQL에서 구현되는 방법과 이유를 설명하고 extern 수식어와 함께 전역 변수를 사용하여 교환에 대한 제 의견을 썼습니다 - 사용하지 않는 것이 좋습니다
extern은 MS DOS 시절로 돌아가 모든 것이 컴파일된 단위와 완벽하게 연결되었습니다.
이 대화가 왜? - 관리자가 나타나서 extern 키워드가 MQL에서 구현되는 방법과 이유를 설명하고 extern 수식어와 함께 전역 변수를 사용하여 교환에 대한 제 의견을 썼습니다 - 사용하지 않는 것이 좋습니다
그리고 도서관은 어떻습니까? 그리고 당신의 단위는 어떻습니까? - 단위, 이것은 컴파일러의 미묘함으로 알 필요가 없으며 잘못된 결론을 내리지 않도록 모르는 것이 훨씬 좋습니다. 그리고 관리자가 어제 명확하지 않은 설명은 무엇입니까? 그것이 어떻게 포함과 가져오기를 구별할 수 없는지 명확하지 않습니다. 포함 및 수입은 여전히 차르 완두콩 아래 있었고 지금처럼 작동했습니다.