µl4에서는 모든 것을 맹세합니다. µl5에서는 << 및 >> 작업에서만 맹세합니다. 이는 매우 논리적입니다. 과부하 논리가 우선 순위가 할당된 논리와 매우 다르기 때문입니다. 이러한 경고는 반복적으로 나를 도왔거나 적어도 나를 많이 짜증나게 하지 않았습니다. 글쎄, 그리고 코드의 논리를 결정하는 논리 연산 && 및 || 대괄호로 구분해야 하는 등등...
나도 프로는 아니지만 그런 추가 경고 수십 개(때로는 수백 개) 중에 정말 중요하고 필요한 경고를 잃어버렸기 때문에 그런 경고가 반복적으로 저를 방해했습니다.
브래킷을 모든 곳에 배치하면 어떤 경고가 표시될 수 있는지 명확하지 않습니까? 그리고 다른 경우와 관련된 경우 모든 것을 한 더미에 혼합 할 필요가 없습니다.
일반적으로 발생하는 상황은 일부 조건을 신속하게 수정해야 한다는 것입니다. 예를 들어, &&가 한 곳에 쓰여진 상태에서 실수를 했는데 ||로 대체해야 했습니다. 수정하고 F7을 눌렀습니다. 그리고 여기에 경고가 옵니다. 주의 깊게 살펴보니 실제로 현재 변경 사항의 결과가 예상과 같지 않습니다. 정확합니다 - 모든 규칙. 저것들. 컴파일러는 그의 메시지로 많은 도움을 주었습니다.
경고가 너무 많으면 코드를 더 신중하게 작성하십시오. 아니면 근본적으로 수정하지 않고, 그것이 틀렸다는 것을 기계에 증명하고 있습니까?
추가 브래킷이 있기 때문에 방해가됩니다. 그러나 아무도이 사업을 좋아하는 사람들에게 추가 브래킷을 두는 것을 귀찮게하지 않으며 가장 중요한 것은 모든 사람에게 적합하다는 것입니다.
나는 이것이 스튜디오에서 구성 가능한지 의심스럽습니다. 아마도 잊어버린 괄호에 대한 불필요한 경고가 없기 때문입니다(적어도 기본적으로). 이는 설정 항목이 없음을 의미합니다
완전히 동의 해. 그는 자신을 프로그래머라고 불렀기 때문에 친절하고 작업의 우선 순위를 가르치고 적어도 그들이 있다는 것을 기억하십시오. 여기에 최근에 로봇에게 추가해달라고 해서 init(), start()도 있는데, 언제 썼냐고 물어보니 일주일 전이라고 답했다. 따라서 "인코더"가 여전히 있지만 그러한 인코더에 대해 추가 경고를 남겨서는 안됩니다.
완전히 동의 해. 그는 자신을 프로그래머라고 불렀기 때문에 친절하고 작업의 우선 순위를 가르치고 적어도 그들이 있다는 것을 기억하십시오. 여기에 최근에 로봇에 추가해달라고 해서 init(), start()도 있는데 이거 언제 썼냐고 물어보니 일주일 전이라고 답했다. 따라서 "인코더"가 여전히 있지만 그러한 인코더에 대해 추가 경고를 남겨서는 안됩니다.
우선 순위에 대한 지식은 경고와 관련이 없습니다. 나는 천천히 코드를 작성하고 스스로를 프로그래머라고 부르지 않습니다.
"일반 프로그래머는 곱셈표와 같이 C++ 연산자 우선 순위 를 기억합니다"에 관해서는,
정확히! 프로가 아니라 그런 경고가 100배나 도움이 되었습니다.
나도 프로는 아니지만 그런 추가 경고 수십 개(때로는 수백 개) 중에 정말 중요하고 필요한 경고를 잃어버렸기 때문에 그런 경고가 반복적으로 나를 방해했습니다.
그리고 모든 곳에 대괄호를 배치하면 어떤 경고를 받을 수 있는지 명확하지 않습니까? 그리고 다른 경우와 관련된 경우 모든 것을 한 더미에 혼합 할 필요가 없습니다.
이 개념을 컴파일러에서 구현할 수 있습니다. 아무도 추가 대괄호를 넣는 것을 금지하지 않습니다. 추가 경고 문제
음, 스튜디오에서는 레벨에 따라 조정됩니다.
실제로 컴파일러가 좋아하도록 코드를 변경하여 이러한 경고를 제거하는 사람은 아무도 없습니다.
음, 스튜디오에서는 레벨에 따라 조정됩니다 .
실제로 컴파일러가 좋아하도록 코드를 변경하여 이러한 경고를 제거하는 사람은 아무도 없습니다.
추가 괄호가 나타나기 때문에 방해가됩니다. 그러나 아무도이 사업을 좋아하는 사람들에게 추가 브래킷을 두는 것을 귀찮게하지 않으며 가장 중요한 것은 모든 사람에게 적합하다는 것입니다.
나는 이것이 스튜디오에서 구성 가능한지 의심스럽습니다. 아마도 잊어버린 괄호에 대한 불필요한 경고가 없기 때문입니다(적어도 기본적으로). 이는 설정 항목이 없음을 의미합니다
난 상관 없어. 이러한 경고를 이전/새 MQL4에 그대로 두십시오.
그래서 그들은 중요한 부분으로 남아 있습니다
µl4에서는 모든 것을 맹세합니다. µl5에서는 << 및 >> 작업에서만 맹세합니다. 이는 매우 논리적입니다. 과부하 논리가 우선 순위가 할당된 논리와 매우 다르기 때문입니다. 이러한 경고는 반복적으로 나를 도왔거나 적어도 나를 많이 짜증나게 하지 않았습니다. 글쎄, 그리고 코드의 논리를 결정하는 논리 연산 && 및 || 대괄호로 구분해야 하는 등등...
나도 프로는 아니지만 그런 추가 경고 수십 개(때로는 수백 개) 중에 정말 중요하고 필요한 경고를 잃어버렸기 때문에 그런 경고가 반복적으로 저를 방해했습니다.
브래킷을 모든 곳에 배치하면 어떤 경고가 표시될 수 있는지 명확하지 않습니까? 그리고 다른 경우와 관련된 경우 모든 것을 한 더미에 혼합 할 필요가 없습니다.
일반적으로 발생하는 상황은 일부 조건을 신속하게 수정해야 한다는 것입니다. 예를 들어, &&가 한 곳에 쓰여진 상태에서 실수를 했는데 ||로 대체해야 했습니다. 수정하고 F7을 눌렀습니다. 그리고 여기에 경고가 옵니다. 주의 깊게 살펴보니 실제로 현재 변경 사항의 결과가 예상과 같지 않습니다. 정확합니다 - 모든 규칙. 저것들. 컴파일러는 그의 메시지로 많은 도움을 주었습니다.
경고가 너무 많으면 코드를 더 신중하게 작성하십시오. 아니면 근본적으로 수정하지 않고, 그것이 틀렸다는 것을 기계에 증명하고 있습니까?
추가 브래킷이 있기 때문에 방해가됩니다. 그러나 아무도이 사업을 좋아하는 사람들에게 추가 브래킷을 두는 것을 귀찮게하지 않으며 가장 중요한 것은 모든 사람에게 적합하다는 것입니다.
나는 이것이 스튜디오에서 구성 가능한지 의심스럽습니다. 아마도 잊어버린 괄호에 대한 불필요한 경고가 없기 때문입니다(적어도 기본적으로). 이는 설정 항목이 없음을 의미합니다
완전히 동의 해. 그는 자신을 프로그래머라고 불렀기 때문에 친절하고 작업의 우선 순위를 가르치고 적어도 그들이 있다는 것을 기억하십시오. 여기에 최근에 로봇에게 추가해달라고 해서 init(), start()도 있는데, 언제 썼냐고 물어보니 일주일 전이라고 답했다. 따라서 "인코더"가 여전히 있지만 그러한 인코더에 대해 추가 경고를 남겨서는 안됩니다.
완전히 동의 해. 그는 자신을 프로그래머라고 불렀기 때문에 친절하고 작업의 우선 순위를 가르치고 적어도 그들이 있다는 것을 기억하십시오. 여기에 최근에 로봇에 추가해달라고 해서 init(), start()도 있는데 이거 언제 썼냐고 물어보니 일주일 전이라고 답했다. 따라서 "인코더"가 여전히 있지만 그러한 인코더에 대해 추가 경고를 남겨서는 안됩니다.
우선 순위에 대한 지식은 경고와 관련이 없습니다. 나는 천천히 코드를 작성하고 스스로를 프로그래머라고 부르지 않습니다.
스튜디오에서 설정한 것인지 의심스럽습니다.
프로젝트 속성에 있습니다. 우리는 프로젝트 중 하나에 철칙이 있었습니다 - 일부 편집증적인 W4를 포함하여 릴리스 버전에 대한 모든 경고 수정
https://docs.microsoft.com/en-us/cpp/build/reference/compiler-option-warning-level?view=vs-2017
나에 관해서는 - 경고가 많을수록 적어도 어떻게 든 정당화되고 끌 수 있다면 더 좋습니다.
경고가 너무 많으면 코드를 더 신중하게 작성하십시오. 아니면 근본적으로 고쳐서 그것이 틀렸다는 것을 기계에게 증명하지 않습니까?
저는 주로 C++ 호환 코드(종종 단일 파일)를 사용합니다. C ++에서는 그렇지 않으며 여기에 이미 언급된 것처럼 추가 대괄호는 이해하기 어렵게 만듭니다.