템플릿 매개변수가 있는 컴파일러 버그 = void* - 페이지 3

새 코멘트
 
fxsaber :

이것은 대괄호의 필요성 / 쓸모에 관한 것입니다 ...

그런 주제가 없습니다. 컴파일러가 경고를 통해 부과하려고 하는 추가 괄호의 주제( 불필요하게 코드를 복잡하게 만드는 것)만 있습니다.
 
A100 :
그런 주제가 없습니다. 컴파일러가 경고를 통해 부과하려고 하는 추가 괄호(코드를 불필요하게 복잡하게 함)에 대한 주제만 있습니다.

우리는 이 주제에 대한 서로의 의견을 알고 있습니다.

 
fxsaber :

우리는 이 주제에 대한 서로의 의견을 알고 있습니다.

이것은 제 의견이 아닙니다. 이것은 특히 이 문제에 대한 Visual Studio 접근 방식으로 구현된 수십만 명의 프로그래머(저는 프로그래머가 아닙니다)의 의견입니다. 그리고 나는 그를 믿는다
 
A100 :
이것은 제 의견이 아닙니다. 이것은 특히 이 문제에 대한 Visual Studio 접근 방식으로 구현된 수십만 명의 프로그래머(저는 프로그래머가 아닙니다)의 의견입니다. 그리고 나는 그를 믿는다

의심해야 할 때 프로그래머 수의 임계 값은 어디인지 궁금합니다. 5 - 소수. 1000은 충분하지 않습니다. 10,000 - 생각하십시오. 그리고 마지막으로 N - 나는 믿습니다. 그러나 당시 (N-1)-아직도 믿지 않았다.

"수십만 마리의 파리가 틀릴 수 없다"는 감정적 인식이 아닌 논리를 켜십시오.

 
fxsaber :

"수십만 마리의 파리가 틀릴 수 없다"는 감정적 인식이 아닌 논리를 켜십시오.

가장 간단한 논리가 있습니다. 대괄호는 우선 순위를 지정하지 않고 변경만 합니다. 괄호가 있으면 우선 순위가 변경되고 괄호가 없으면 기본 우선 순위가 적용됩니다.

모든 것이 대괄호로 결정된다는 접근 방식을 사용하면 우선 순위가 전혀 필요하지 않습니다.

 
A100 :

대괄호가 있으면 우선순위가 변경 되고, 대괄호가 없으면 기본 우선순위가 적용됩니다.

비논리적인 주장.

 
fxsaber :

비논리적인 주장.

모순은 무엇입니까?
 
A100 :
모순은 무엇입니까?

괄호의 존재는 기존 우선 순위의 변경을 전혀 나타내지 않습니다.

 
fxsaber :

괄호의 존재는 기존 우선 순위의 변경을 전혀 나타내지 않습니다.

따라서 코드에서 대괄호는 아무 의미가 없으며 ... 문은 비논리적이며 대괄호가 있는 경우 우선 순위/순서가 실제로 변경되었는지 여부와 내 코드에서 대괄호를 파악해야 합니다. 그 자체로 우선 순위/순서의 변경을 의미합니다(이미 괄호의 존재/부재가 명확함)

괄호
 fxsaber
 A100
있다
 불분명
 작업 우선 순위가 변경됨
아니요
 작업 우선 순위가 변경되지 않았습니다.
 작업 우선 순위가 변경되지 않았습니다.
 
A100 :
그런 주제가 없습니다. 컴파일러가 경고를 통해 부과하려고 하는 추가 괄호의 주제( 불필요하게 코드를 복잡하게 만드는 것)만 있습니다.

이 링크를 직접 읽어 보셨습니까? Slava는 이전 MQL4에서 우선 순위가 뒤죽박죽이었기 때문에 이것이 왜 그렇게 되었는지 널리 설명합니다. 그래서 지금 관심을 받는 것이 중요합니다. 경고일 뿐이라는 것조차 안타까운 일입니다. 오류가 있으면 더 좋을 것입니다.

12345678910...20
새 코멘트