ENUM_POSITION_TYPE및ENUM_POSITION_TYPE 대신 long 및 long
36자(대문자도 가능) 대신 8자(눈을 감고 입력 가능)! 그 밖에도 그 자체로는 말이 되지 않는 다양한 정보들. 이것은 불필요한 작성과 불필요한 정보 모두에서 좋은 프로그래밍 스타일이 아닙니다.
이 경우 Mikhail은 절대적으로 옳습니다 (Mikhail의 프로그래밍 스타일에 대한 혐오감에도 불구하고).
그리고 여기서 요점은 잠재적인 경고가 아니라 문자 수에서 더욱 그렇습니다. 그러나 강력한 타이핑 입니다. ENUM_POSITION_TYPE 열거형은 고유한 데이터 유형입니다. ENUM_POSITION_TYPE과 같이 long도 정수도 아닙니다. 그리고 ENUM_POSITION_TYPE으로만 사용해야 합니다. 그리고 열거형을 길게 입력하면 이미 3번째 문자에서 자동완성이 켜져있고, 이것은 전혀 문제가 되지 않습니다. 그리고 문제는 long을 사용하는 데 있습니다. 왜냐하면 거의 모든 것이 가능하지만 ENUM_POSITION_TYPE은 그렇지 않기 때문입니다.
o_o :
MQL은 비교할 때 명시적 캐스팅이 필요하지 않습니다.
처음에는 필요한 것을 썼는데 나중에 "비교할 때"라는 단어를 보았습니다. 실제로 MQL이 이를 암시적으로 수행하기 때문에 비교할 때 명시적 캐스트가 필요하지 않습니다. 그리고 결과가 종종 불확실하기 때문에 그가 이것을 전혀 하지 않는 것이 더 나을 것입니다. 그러나 다른 일반 강력한 형식 언어에서는 명시적 형식 캐스팅이 항상 필요합니다.
추신 Mikhail은 얼마 동안 유능한 대답을했지만 여기에서도 습관적으로 썩음을 퍼뜨리기 시작했습니다. 그러나 헛되이, 왜냐하면 이 경우 그는 옳다.
이것은 당신의 말이며 경고는 없지만 실제로는
당신은 어떤 세상에 살고, 무엇을 피우고, 공유합니까?
저것들. 당신은 당신이 보지 못하는 내 코드에 대해 너무 대담하게 주장합니까? 버섯이 잘못?
바보가 아니라 모든 것을 이해했습니다. 특히 MQ에서 개인적으로 경고가없는 특수 컴파일러가 있습니다.
PS: 나도 하나 갖고 싶어, 삼촌 나 놀게 해줘
제공한 코드가 올바르지 않습니다!
다음과 같아야 합니다.
정확하지 않습니다. 비교가 있기 때문입니다.
아니오, 옳지 않습니다.
그것은 그것과 아무 관련이 없습니다.
코드 작성자는 안전하게 재생했거나 어딘가에서 유형 캐스트 를 복사하여 붙여넣었습니다.
사실은
코드
오류나 경고를 제공하지 않습니다.
MQL은 비교할 때 명시적 캐스팅이 필요하지 않습니다.
추신. 논쟁을 시작하기 전에 가정을 테스트하십시오.
아주 나쁜 예입니다. 비교를 놓친 다음 오류가 발생합니다.
추신. 논쟁을 시작하기 전에 가정을 테스트하십시오.
아니, 옳지 않다.
그것은 그것과 아무 관련이 없습니다.
코드 작성자는 안전하게 재생했거나 어딘가에서 유형 캐스트 를 복사하여 붙여넣었습니다.
사실은
코드
오류나 경고를 제공하지 않습니다.
MQL은 비교할 때 명시적 캐스팅이 필요하지 않습니다.
추신. 논쟁을 시작하기 전에 가정을 테스트하십시오.
오오!
맞다 틀리다....
남이 쓰는 글은 전혀 읽지 않는 것 같습니다!
프로그래밍 규칙에 따르면:
함수의 수신 변수는 이 함수의 반환 유형과 동일한 유형이어야 합니다!
모두!
이 생각을 끝낼 시간입니다.
왜 다음과 같이 쓰지 않았습니까?
예, 함수가 항상 LONG을 반환한다는 것을 알고 있기 때문에
그리고 도움말은 PositionGetInteger() 함수의 POSITION_TYPE 인수에 대해 반환
LONG이 아닌 ENUM_POSITION_TYPE 값
캐스팅 유형을 연습하려면 다음과 같이 작성하십시오.
컴파일러에서 오류가 발생하지 않는다고 해서 올바르게 작성했다는 의미는 아닙니다!
그것은 컴파일러의 "자유"에 대해서만 이야기합니다! (LONG과 INTEGER를 비교할 수 있음)
이 상황에서 올바르게 다음을 수행해야 합니다.
아주 나쁜 예입니다. 비교를 놓친 다음 오류가 발생합니다.
유형의 강제로 추가에 대해 어디선가 본 적이 있습니까? 대화의 다른 주제를 언급하여 논문을 정당화하지 마십시오.
비교에 대해서만 연설하고 이 경우에만 long - enum.
당신은 이미 뚫을 수 없는 생각의 정글 속으로 헤매고 있었습니다. 비록 질문은 직접적이었지만, 그 대답은 정수로 주어졌습니다.
넥스터257 :
말해줘, 이게 무슨 비교인지 이해가 안 가?
if(유형==(긴) POSITION_TYPE_BUY )
POSITION_TYPE_BUY 앞에 (긴)이 있는 이유는 무엇입니까?
즉석 변경이 있는 유형 변경입니다.
ENUM_POSITION_TYPE 및 ENUM_POSITION_TYPE 대신 long 및 long
36자(대문자도 가능) 대신 8자(눈을 감고 입력 가능)! 그 밖에도 그 자체로는 말이 되지 않는 다양한 정보들. 이것은 불필요한 작성과 불필요한 정보 모두에서 좋은 프로그래밍 스타일이 아닙니다.
이 경우 Mikhail은 절대적으로 옳습니다 (Mikhail의 프로그래밍 스타일에 대한 혐오감에도 불구하고).
그리고 여기서 요점은 잠재적인 경고가 아니라 문자 수에서 더욱 그렇습니다. 그러나 강력한 타이핑 입니다. ENUM_POSITION_TYPE 열거형은 고유한 데이터 유형입니다. ENUM_POSITION_TYPE과 같이 long도 정수도 아닙니다. 그리고 ENUM_POSITION_TYPE으로만 사용해야 합니다. 그리고 열거형을 길게 입력하면 이미 3번째 문자에서 자동완성이 켜져있고, 이것은 전혀 문제가 되지 않습니다. 그리고 문제는 long을 사용하는 데 있습니다. 왜냐하면 거의 모든 것이 가능하지만 ENUM_POSITION_TYPE은 그렇지 않기 때문입니다.
MQL은 비교할 때 명시적 캐스팅이 필요하지 않습니다.
처음에는 필요한 것을 썼는데 나중에 "비교할 때"라는 단어를 보았습니다. 실제로 MQL이 이를 암시적으로 수행하기 때문에 비교할 때 명시적 캐스트가 필요하지 않습니다. 그리고 결과가 종종 불확실하기 때문에 그가 이것을 전혀 하지 않는 것이 더 나을 것입니다. 그러나 다른 일반 강력한 형식 언어에서는 명시적 형식 캐스팅이 항상 필요합니다.
추신 Mikhail은 얼마 동안 유능한 대답을했지만 여기에서도 습관적으로 썩음을 퍼뜨리기 시작했습니다. 그러나 헛되이, 왜냐하면 이 경우 그는 옳다.