정말 놀라운 결과입니다! - 페이지 7

 
MuruFigi >> :

글쎄요, 나는 두 번째 페이지에서 동의했습니다. 그렇다면 컴파일러의 버그가 아니라 개발자 두뇌의 버그에 대해 이야기해야 합니다. 실례가 되지 않습니다. 저는 이 주제를 더 웃기기 위해 만들었습니다.

지금 이해가 안되는 부분이 있습니다.

MQL 컴파일러는 무엇을 기반으로 합니까? 결국 일반 언어로 개발했다면 곱셈과 덧셈 연산이 우선순위가 같다는 사실에 프로그래머들은 애초에 흔들렸을 것이다. 그들은 어떻게 이것을 놓칠 수 있었습니까? 필요한 부분과 필요하지 않은 부분에 대괄호를 두는 것은 무엇입니까? 그런데 괄호가 많으면 코드의 가시성이 나빠집니다. 그리고 프로그래머가 2 + 3 * 4와 같은 산술 연산을 시작하면 2 + (3 * 4)도 작성합니다. 그렇지 않으면 C++ 컴파일러에서 버그가 발생하고 하나의 표현은 수동으로 계산된 행복이어야 합니다:)

이것은 C, Java, Fortran, MathCad 등 개발자의 마음에 있는 버그입니다. 등. 등.


어떻게 아직도 이해하지 못합니까!


추신


고백하지만, 이것을 깨닫는 데도 시간이 걸렸습니다.

 
sol писал(а) >>

고백하지만, 이것을 깨닫는 데도 시간이 걸렸습니다.

이제서야 일부 논리적 조합이 제대로 수행되기를 원하지 않는 이유가 명확해졌습니다. 인공 브래킷을 추가해야 했습니다.

이전에는 아무것도 설명할 수 없었습니다. 그러나 그는 주제도 꺼내지 않았다. 무작위로 올바른 솔루션을 찾았습니다. 하지만 모든 것을 찌르려면 얼마나 찌르셔야 합니까?

 
nen >> :

이제서야 일부 논리적 조합이 제대로 수행되기를 원하지 않는 이유가 명확해졌습니다. 인공 브래킷을 추가해야 했습니다.

이전에는 아무것도 설명할 수 없었습니다. 그러나 그는 주제도 꺼내지 않았다. 무작위로 올바른 솔루션을 찾았습니다. 하지만 모든 것을 찌르려면 얼마나 찌르셔야 합니까?

RTFM


*로플*

 
MuruFigi >> : 왜 모든 사람들은 필요한 곳에 괄호를 넣고 필요하지 않은 곳에 괄호를 씁니까?

물론 모든 것은 아니지만 항상 내기합니다. 그리고 순전히 습관적으로 이 "개발자의 머리에 있는 버그"에 대해 알기 훨씬 전에 설치했습니다. 대괄호 없이도 할 수 있는 경우 우선 순위를 명확히 하기 위해 도움말로 다시 올라가야 하는 이유는 무엇입니까? 따라서 나를 위해이 "버그"는 나를 즐겁게했지만 재앙이되지 않았습니다.

그리고 이전에는 C로 boolean을 작성할 때 우선 순위에 대해 의심의 여지가 없었지만 설정도 했습니다. 그리고 솔직히 말해서 괄호가 없는 복잡한 부울 표현식은 가독성이 좋지 않은 표현이라고 생각합니다.

추신만 부탁드립니다. 2 + 3 * 4와 같은 바보 같은 예는 하지 마시기 바랍니다. 우선순위가 있는 그러한 트릭이 산술 연산에 대해 발생했다면 나는 후회 없이 그것을 진짜 버그라고 부를 것입니다.

그런데:

  1. 분포 법칙(괄호 여는 것):
    x 1 또는 (x 2 및 x 3 ) = (x 1 또는 x 2 ) 및 (x 1 또는 x 3 )
    x 1 및 (x 2 또는 x 3 ) = (x 1 및 x 2 ) 또는 (x 1 및 x 3 )
  2. ...

따라서 부울 대수의 관점에서 연산 또는 및 및는 동일한 우선 순위를 갖습니다.

Andrey, 부울 대수에서 이러한 연산의 우선 순위가 동일하다는 것을 정확히 무엇에서 추론했습니까? 반례:

for=1, b=0, c=0

(a 또는 b) 및 c = (1 또는 0) 및 0 = 0

a 또는 (b 및 c) = 1 또는 (0 및 0) = 1

 
개발자가 외국인이라면 토픽 스타터는 적어도 버그를 찾아준 것에 대해 감사할 것입니다. 그리고 수정 작업이 이미 한창 진행 중이라는 사실을 언급하면서 주제를 빠르게 다룰 것입니다. 그들은 평판을 중요하게 생각합니다(많은 비용이 듭니다). 그리고 우리는 "바보 그 자신"이라고 말하고 문서, 사양, 표 등을 읽습니다. 자, 만약 MT4에 대한 경쟁이 있었다면 완전히 달라졌을 것입니다.
 
MuruFigi >> :

MQL 컴파일러는 무엇을 기반으로 합니까? 결국 일반 언어로 개발했다면 곱셈과 덧셈 연산의 우선순위가 같다는 사실에 프로그래머들은 애초에 당황했을 것이다. 그들은 어떻게 이것을 놓칠 수 있었습니까?

자, 여기 또 다른 왜곡의 예가 있습니다. 그리고 동시에 토픽 스타터는 그가 재미삼아 토픽을 시작했다고 보고하고, 이 시점에서 그는 여전히 문서를 읽고 있습니다.

 
Rosh >> :

자, 여기 또 다른 왜곡의 예가 있습니다. 그리고 동시에 토픽 스타터는 그가 재미삼아 토픽을 시작했다고 보고하고, 이 시점에서 그는 여전히 문서를 읽고 있습니다.

Doprikalovsya :-) 완전히 다른 목표를 가지고 위대한 발견을 쉽게 한다는 것은 사실일 수 있습니다.

 
Galaxy >> :

Doprikalovsya :-). 완전히 다른 목표를 가지고 위대한 발견이 자연스럽게 이루어진다는 것은 사실일 수 있습니다.

이 "발견"은 위대한 것을 언급하는 데 거의 의미가 없습니다. 사실을 말하고 잊어 버리는 것만 가치가 있습니다. 그리고 일반적으로 부울 연산의 우선 순위에 대한 주제는 너무 뻔합니다. 개발자가 괄호 없이 다른 연산으로 부울 표현식을 작성하는 것을 단순히 금지하고 그러한 구성이 잘못된 것으로 간주하는 것이 더 저렴할 것입니다.

 
Mathemat >> :

Andrey, 부울 대수에서 이러한 연산의 우선 순위가 동일하다는 것을 정확히 무엇에서 추론했습니까? 반례:

for=1, b=0, c=0

(a 또는 b) 및 c = (1 또는 0) 및 0 = 0

a 또는 (b 및 c) = 1 또는 (0 및 0) = 1

= 아름답다

b = 똑똑하다

c = 부자

x= a && b && c ;

y = a || ㄴ || 씨;


Andrey가 무엇을 선호하는지 궁금합니다. x = 1 또는 y = 1 ?

 
Mathemat >> :

Andrey, 부울 대수에서 이러한 연산의 우선 순위가 동일하다는 것을 정확히 무엇에서 추론했습니까?

작업의 대칭에서. 그리고 작업의 대칭은 선택한 공식에서 직접 따릅니다.

대칭 작업 중 하나가 다른 작업보다 우선할 수 없습니다.

갤럭시 >> :

Andrei가 무엇을 선호할지 궁금합니다. x = 1 또는 y = 1 ?

나는 에릭이 개인적으로 비꼬지 않고 논쟁하는 것을 선호합니다.

_______________________________________

나는 무엇을 위해

표현식 A && B의 결과 || C는 부울 대수의 관점에서 정의되지 않습니다.