[language-agnostic] GOTO는 여전히 해로운 것으로 간주됩니까? [닫은]

다음 내용은 일반화입니다. 예외를 항소하는 것이 항상 가능하지만 일반적으로 (나의 경험과 겸손한 의견으로는) 위험의 가치가 없습니다.

1. 메모리 주소 (GOTO 또는 원시 포인터)를 제한없이 사용하면 쉽게 피할 수있는 실수를 할 수있는 기회가 너무 많습니다.
2. 코드에서 특정 “위치”에 도달하는 방법이 많을수록 시스템의 상태에 대한 확신이 줄어 듭니다. (아래 참조)
3. 구조화 된 프로그래밍 IMHO는 “GOTO를 피하는 것”이 ​​아니라 코드의 구조를 데이터의 구조와 일치시키는 것에 관한 것입니다. 예를 들어, 반복적 인 데이터 구조 (예를 들어, 배열, 순차 파일 등)는 반복되는 코드 단위에 의해 자연스럽게 처리된다. 내장 구조 (예를 들어, 동안, 동안, 각, 등)를 가짐으로써 프로그래머는 동일한 진부한 코드 패턴을 반복하는 지루함을 피할 수 있습니다.
4. GOTO가 저수준 구현 세부 사항 (항상 그런 것은 아닙니다!)이더라도 프로그래머가 생각 해야하는 수준보다 낮습니다. 원시 바이너리로 개인 수표 책의 균형을 잡는 프로그래머는 몇 명입니까? 데이터베이스 엔진에 키를 제공하는 대신 디스크의 어떤 섹터에 특정 레코드가 포함되어 있는지 걱정하는 프로그래머는 몇 명입니까 (실제 디스크 섹터로 모든 프로그램을 실제로 작성하면 문제가 발생할 수있는 방법은 몇 가지입니까)?

위의 각주 :

포인트 2와 관련하여 다음 코드를 고려하십시오.

a = b + 1
/* do something with a */

코드의 “무언가”지점에서 a보다 큰 확신을 가지고 진술 할 수 있습니다 b. (예, 트랩되지 않은 정수 오버플로의 가능성을 무시하고 있습니다. 간단한 예를 보지 않겠습니다.)

반면에 코드가 이런 식으로 읽은 경우 :

...
goto 10
...
a = b + 1
10: /* do something with a */
...
goto 10
...

라벨 10에 도달하는 다양한 방법 은 그 시점 a과 b그 시점 의 관계에 대해 확신하기 위해 훨씬 더 열심히 노력해야한다는 것을 의미합니다 . (실제로 일반적인 경우 결정 불가능합니다!)

포인트 4와 관련하여 코드에서 “어딘가에 가고있다”는 전체 개념은 은유 일뿐입니다. 전자와 광자 (폐열에 대한 것)를 제외하고 CPU 내부에는 실제로 “가는”것이 없습니다. 때때로 우리는 더 유용한 다른 하나에 대한 은유를 포기합니다. 나는 수십 년 전에 언어를 만나는 것을 기억합니다.

if (some condition) {
  action-1
} else {
  action-2
}

가상 머신에서 action-1 및 action-2를 라인 외부 매개 변수없는 루틴으로 컴파일 한 다음 조건의 부울 값을 사용하여 하나의 다른 인수를 사용하는 단일 2 개의 인수 VM opcode를 사용하여 가상 머신에서 구현되었습니다. 그 개념은 단순히 “여기에 가거나 거기에 가라”보다는 “지금 무엇을 부를 것인지 선택”이었습니다. 다시, 은유의 변화.

답변

if (f() == false) goto err_cleanup;
if (g() == false) goto err_cleanup;
if (h() == false) goto err_cleanup;

return;

err_cleanup:
...

for{
  for{
    for{
      for{
        for{
          if(stuff){
            GOTO ENDOFLOOPS;
          }
        }
      }
    }
  }
}

ENDOFLOOPS: