그리고 그것들을 우회할 수는 있지만, 질문은 왜, 다른 현대 PL에는 그러한 문제가 없다면?
다른 EP에서는 모든 것이 다르게 구성됩니다. 예를 들어 Java에는 전역 변수와 상수가 없지만 선언된 클래스 의 정적 변수를 대신 사용할 수 있습니다. 그러나 이것의 본질은 변경되지 않습니다. 왜냐하면 다른 클래스에서 복제되는 정적 변수의 이름을 지정하면 컴파일러는 패키지와 그것이 속한 클래스의 이름을 명확히 하도록 요청할 것이기 때문입니다. 컴파일 과정에는 텔레파시 능력이 없습니다. 수업도 마찬가지입니다. 다른 패키지에서 중복되는 클래스 또는 인터페이스 이름을 지정하면 컴파일러에서 패키지 이름을 명확히 하도록 다시 요청합니다.
즉, 생성하지 않는 방법은 무엇입니까? 모든 프로그래밍 언어에서 전역 변수는 자유롭게 사용되며 이는 정상이지만 여기에서는 컴파일러가 맹세합니다. 그리고 오류가 치명적이지는 않지만 여전히 불편합니다.
포인트 변수는 1포인트의 가격을 보고하며 표준 포인트를 대체합니다. MarketInfo(EA_Symbol(), MODE_POINT) 함수는 모든 상품의 1포인트 가격을 제공합니다. 또한 point 변수는 전역 변수라면 어드바이저 본문의 모든 기능에서 사용할 수 있습니다. 그러한 경우는 특정 불편함을 유발하고 꽤 자주 발생한다는 점에 동의합니다(물론 MQL 프로그래밍 경험이 있는 경우 제외). 그리고 그것들을 우회할 수는 있지만, 질문은 왜, 다른 현대 PL에는 그러한 문제가 없다면?
포인트 변수는 전역 변수 가 될 수 없습니다. 상품마다 포인트 가격이 다르기 때문입니다(일반적으로 포인트 가격은 동일하지만). 따라서 포인트 가격은 특정 기호에 대해 거래되는 특정 Expert Advisor 내에서만 계산할 수 있으며 다른 것은 없습니다.
예, 이것은 실수가 아니므로 .. 오히려 알림. 일부 언어에는 이런 표기법조차 없습니다. 로컬 지역의 무언가가 상위 레벨에서 무언가를 차단했습니다. 글쎄요. 그래서 그것은 의미합니다. 어떤 경우에는 그러한 경고가 매우 유용하지만.
예를 들어 전역 변수 는 MQL과 아무 관련이 없으며 다음과 같이 옆으로 사용하지 않는 것이 좋습니다.
여러 범위를 만듭니다.
그리고 가드, 우리는 최대 2개의 경고를 받습니다.
따라서 결론 -
1) 이런 종류의 경고 무시 2) 아래/위 범위에서 같은 이름을 만들지 마십시오. 3) 이 알림을 쓸모없는 것으로 제거하도록 서비스 데스크를 설득합니다.
글쎄, 같은 범위에서 같은 이름을 가진 2개의 변수는 내장이 아니며 모든 프로그래머가 이것을 알고 있습니다. 그러나 문제는 이 범위가 일반 프로그래머가 변경하지 않을 표준 모듈로 확장된다는 것입니다. 자신을 개발자라고 생각하지 않습니다. 경고를 제거하는 것도 옵션이 아닙니다. 같은 방식으로 주의를 기울이지 마십시오. 이는 순전히 불편하기 때문입니다. 중요한 경고를 놓칠 수 있습니다.
여기에 문제를 해결하기 위한 2가지 옵션이 있습니다.
1. 명시적으로 지정하지 않는 한 플러그인이 플러그인을 보지 않도록 합니다.
2. 개발자가 구문을 변경하고 싶지 않다면 클래스 필드와 유사하게 함수에서 매개변수를 선언하는 규칙을 도입하십시오. 예를 들어 매개변수 이름은 i 또는 i_(Alg. Input에서)로 시작해야 하므로 표준에서 모든 매개변수를 수정해야 합니다. 모듈
Mihail Matkovskij :
그리고 그것들을 우회할 수는 있지만, 질문은 왜, 다른 현대 PL에는 그러한 문제가 없다면?
그리고 오류가 치명적이지는 않지만 여전히 불편합니다.
예, 이것은 실수가 아니므로 .. 오히려 알림. 일부 언어에는 이런 표기법조차 없습니다. 로컬 지역의 무언가가 상위 레벨에서 무언가를 차단했습니다. 글쎄요. 그래서 그것은 의미합니다. 어떤 경우에는 그러한 경고가 매우 유용합니다.
예를 들어 전역 변수 는 MQL과 아무 관련이 없으며 다음과 같이 옆으로 사용하지 않는 것이 좋습니다.
여러 범위를 만듭니다.
그리고 가드, 우리는 최대 2개의 경고를 받습니다.
따라서 결론 -
1) 이런 종류의 경고 무시
2) 아래/위 범위에서 같은 이름을 만들지 마십시오.
3) 이 알림을 쓸모없는 것으로 제거하도록 서비스 데스크를 설득합니다.
3) 이 알림을 쓸모없는 것으로 제거하도록 서비스 데스크를 설득합니다.
모든 바보가 서비스 데스크에 이 규칙이나 저 규칙을 제거하도록 설득한다면 그의 관점에서 볼 때 그것은 쓸모가 없으며 곧 언어는 원시적인 쓰레기로 전락할 것입니다.
즉, 생성하지 않는 방법은 무엇입니까? 모든 프로그래밍 언어에서 전역 변수는 자유롭게 사용되며 이는 정상이지만 여기에서는 컴파일러가 맹세합니다. 그리고 오류가 치명적이지는 않지만 여전히 불편합니다.
포인트 변수는 1포인트의 가격을 보고하며 표준 포인트를 대체합니다. MarketInfo(EA_Symbol(), MODE_POINT) 함수는 모든 상품의 1포인트 가격을 제공합니다. 또한 point 변수는 전역 변수라면 어드바이저 본문의 모든 기능에서 사용할 수 있습니다. 그러한 경우는 특정 불편함을 유발하고 꽤 자주 발생한다는 점에 동의합니다(물론 MQL 프로그래밍 경험이 있는 경우 제외). 그리고 그것들을 우회할 수는 있지만, 질문은 왜, 다른 현대 PL에는 그러한 문제가 없다면?
불행히도 숙련된 프로그래머만이 그러한 경고의 유용성과 중요성을 이해합니다.
글쎄, 나는 다른 모든 사람들이 컴파일러의 이러한 수준의 도움을 즐기고 실수를 수정하도록 권장합니다. 이것은 잠재적인 오류의 실제 위치이며 초보 개발자가 배우는 것이 중요합니다.
색 구성표를 환영합니다. 따라서 편집기에서 텍스트 및 배경 색상이 변경될 뿐만 아니라 다른 창에서도 변경됩니다.
클래스의 데이터 멤버는 이름이 일치할 때 입력 변수의 색상으로 칠해지지 않도록 합니다.
이미 여러 번 작업 일을 끝내고 프로그램, 브라우저 등의 창을 닫고 최적화 모드 에서 작동하는 MT5 터미널을 실수로 닫았습니다. 저것. 모든 결과가 사라졌습니다. 다시 시작하면 모든 것이 처음부터 시작됩니다.
많은 프로그램에서 클릭하여 창을 닫을 때 닫는 것이 맞는지 다시 묻고 저장하지 않은 데이터가 손실될 수 있습니다.
터미널이 최적화되어 있다면 이렇게 하는 것이 좋을 것입니다.
예, 이것은 실수가 아니므로 .. 오히려 알림. 일부 언어에는 이런 표기법조차 없습니다. 로컬 지역의 무언가가 상위 레벨에서 무언가를 차단했습니다. 글쎄요. 그래서 그것은 의미합니다. 어떤 경우에는 그러한 경고가 매우 유용하지만.
예를 들어 전역 변수 는 MQL과 아무 관련이 없으며 다음과 같이 옆으로 사용하지 않는 것이 좋습니다.
여러 범위를 만듭니다.
그리고 가드, 우리는 최대 2개의 경고를 받습니다.
따라서 결론 -
1) 이런 종류의 경고 무시
2) 아래/위 범위에서 같은 이름을 만들지 마십시오.
3) 이 알림을 쓸모없는 것으로 제거하도록 서비스 데스크를 설득합니다.
글쎄, 같은 범위에서 같은 이름을 가진 2개의 변수는 내장이 아니며 모든 프로그래머가 이것을 알고 있습니다. 그러나 문제는 이 범위가 일반 프로그래머가 변경하지 않을 표준 모듈로 확장된다는 것입니다. 자신을 개발자라고 생각하지 않습니다. 경고를 제거하는 것도 옵션이 아닙니다. 같은 방식으로 주의를 기울이지 마십시오. 이는 순전히 불편하기 때문입니다. 중요한 경고를 놓칠 수 있습니다.
여기에 문제를 해결하기 위한 2가지 옵션이 있습니다.
1. 명시적으로 지정하지 않는 한 플러그인이 플러그인을 보지 않도록 합니다.
2. 개발자가 구문을 변경하고 싶지 않다면 클래스 필드와 유사하게 함수에서 매개변수를 선언하는 규칙을 도입하십시오. 예를 들어 매개변수 이름은 i 또는 i_(Alg. Input에서)로 시작해야 하므로 표준에서 모든 매개변수를 수정해야 합니다. 모듈
컴파일러는 올바르게 작동하고 있으며 이러한 경고는 절대적으로 정확합니다.
유일한 탈출구는 변수가 겹치지 않도록 하고 다른 사람들이 이 권리를 존중하도록 요구함으로써 실수할 권리를 유지하려고 하지 않는 것입니다.
컴파일러는 올바르게 작동하고 있으며 이러한 경고는 절대적으로 정확합니다.
유일한 탈출구는 변수가 겹치지 않도록 하고 다른 사람들이 이 권리를 존중하도록 요구함으로써 실수할 권리를 유지하려고 하지 않는 것입니다.