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

누구나 편집자에게 보낸 Dijkstra의 편지를 알고 있습니다 : 유해한 것으로 간주되는 진술 ( 여기서는 .html 스크립트 및 .pdf)로 이동 하십시오 . goto를 사용하여 유지 관리 할 수없는 거대한 코드를 생성 할 수는 있지만 최신 프로그래밍 언어로 유지 됩니다 . Scheme 의 고급 연속 제어 구조 조차도 정교한 goto로 설명 할 수 있습니다.

어떤 상황에서 goto를 사용해야합니까? 언제 피하는 것이 가장 좋습니까?

후속 질문 : C는 setjmp와 longjmp의 한 쌍의 함수를 제공하여 현재 스택 프레임뿐만 아니라 호출 프레임 내에서도 이동할 수 있습니다. 이것들은 goto만큼 위험한 것으로 간주되어야합니까? 더 위험한?

Dijkstra는 자신이 책임을지지 않은 제목을 후회했습니다. 의 끝에서 EWD1308 (또한 여기 .PDF) 그가 쓴 :

마지막으로 레코드에 대한 짧은 이야기. 1968 년 ACM의 커뮤니케이션은 " 유해한 것으로 간주되는 goto 성명서 "라는 제목으로 내 텍스트를 출판 했다. 제목은 템플릿이되어 내 명성의 초석이되었습니다. "Dijkstra는 유해한 것으로 간주"라는 제목을 포함하여 거의 모든 X에 대해 "X는 유해한 것으로 간주"라는 제목의 모든 기사를 볼 수 있습니다. 그러나 무슨 일이 있었습니까? 제목이 ' 고토 진술에 대한 사례 '인 논문을 제출했습니다 .", 출판 속도를 높이기 위해 편집자는"편집자에게 편지 "로 바뀌었고, 그 과정에서 그는 자신의 발명품에 새로운 제목을 부여했습니다! 편집자는 Niklaus Wirth였습니다.

Dijkstra의 주제와 일치하는이 주제에 대해 잘 알려진 고전 논문은 Donald E. Knuth의 Statements to go with Statements로 구성된 Structured Programming입니다 . 두 가지를 모두 읽으면 상황에 대한 맥락과 비 도움적인 주제에 대한 이해를 회복하는 데 도움이됩니다. 이 백서에서이 사례에 대한 Dijkstra의 의견이보고되었으며 더욱 강력합니다.

Donald E. Knuth : 저는 그러한 견해를 제시함으로써 Dijkstra의 아이디어에 대해 최근에 다음과 같은 글을 썼기 때문에 실제로 동의하지 않는 것은 아니라고 생각합니다. ] 문으로 이동합니다. 내가 프로그래밍의 개념 문제를 규율을 코딩 간단한 형태로, 하나의 속임수에 의해 해결 될 수 있다면 다른 사람이, 그것의 종교를하고 있다는 불편한 느낌이! "

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

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를 사용하여 가상 머신에서 구현되었습니다. 그 개념은 단순히 "여기에 가거나 거기에 가라"보다는 "지금 무엇을 부를 것인지 선택"이었습니다. 다시, 은유의 변화.

내 동료가 GOTO를 사용하는 유일한 이유는 당신이 구석 구석까지 자신을 프로그래밍 할 수있는 유일한 방법이라고 말했다. 다시 말해, 적절한 디자인을 미리하고 나중에 GOTO를 사용할 필요가 없습니다.

나는이 만화가 아름답게 "프로그램 흐름을 재구성하거나 작은 'GOTO'를 대신 사용할 수있다"고 설명했다. 디자인이 약한 경우 GOTO는 약한 방법입니다. Velociraptors는 약점을 먹습니다 .

때때로 단일 함수 내에서 예외 처리에 대한 대안으로 GOTO를 사용하는 것이 유효합니다.

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

return;

err_cleanup:
...

COM 코드는이 패턴에 상당히 자주 빠지는 것 같습니다.

goto를 사용하여 한 번만 기억할 수 있습니다. 나는 일련의 5 개의 중첩 된 루프를 가지고 있었고 특정 조건에 따라 초기부터 전체 구조를 깨뜨릴 수 있어야했습니다.

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

ENDOFLOOPS:

부울 브레이크 변수를 쉽게 선언하고 각 루프에 대한 조건부로 사용했지만 GOTO가 실용적이고 읽기 쉬운 것으로 결정했습니다.

벨로시 랩터가 나를 공격하지 않았습니다.

우리는 이미이 토론을 했고 나는 내 입장을 고수 합니다 .

또한, 나는 고급 언어 구조를 " goto변장 중" 으로 묘사하는 사람들에게 지겨워한다. 왜냐하면 그들은 전혀 요점 을 얻지 못했기 때문이다 . 예를 들면 다음과 같습니다.

Scheme의 고급 연속 제어 구조조차도 정교한 goto로 설명 할 수 있습니다.

그건 말도 안되는 말이야 모든 제어 구조는 관점에서 구현 될 수 goto있지만이 관찰은 전혀 사소하고 쓸모가 없습니다. goto긍정적 인 효과로 인해 유해한 것으로 간주되지는 않지만 부정적인 결과로 인해 구조화 된 프로그래밍에 의해 제거되었습니다.

마찬가지로“GOTO는 도구이며 모든 도구가 사용하고 남용 할 수 있습니다”라는 문구가 완전히 표시되지 않습니다. 현대의 건설 노동자는 바위를 사용하지 않고“도구”라고 주장하지 않습니다. 바위는 망치로 대체되었습니다. goto제어 구조로 대체되었습니다. 만약 건설 노동자가 망치없이 야생에서 좌초된다면, 그는 대신 바위를 사용할 것입니다. 프로그래머가 기능 X가없는 열등한 프로그래밍 언어를 사용해야하는 경우에는 물론 goto대신 사용해야 합니다. 그러나 적절한 언어 기능 대신 다른 곳에서 사용하면 언어를 제대로 이해하지 못하고 잘못 사용합니다. 정말 간단합니다.

Goto는 그것을 위해 프로그램에 포함시킬 것들의 목록이 매우 낮습니다. 그렇다고 받아 들일 수없는 것은 아닙니다.

Goto는 상태 머신에 적합 할 수 있습니다. 루프의 switch 문은 (일반적으로 중요한 순서대로) 다음과 같습니다. (a) 실제로 제어 흐름을 나타내지 않음, (b) 못생긴, (c) 언어 및 컴파일러에 따라 잠재적으로 비효율적입니다. 따라서 상태 당 하나의 함수를 작성하고 "return NEXT_STATE;"와 같은 작업을 수행하게됩니다. 심지어 고토처럼 보입니다.

물론 상태 머신을 이해하기 쉬운 방식으로 코딩하는 것은 어렵습니다. 그러나 이러한 어려움 중 어느 것도 goto를 사용하는 것과 관련이 없으며 대체 제어 구조를 사용하여 줄일 수는 없습니다. 귀하의 언어에 '상태 기계'구성이없는 한. 광산은 그렇지 않습니다.

드문 경우에 알고리즘이 더 구체적인 제어 흐름 (루프, 조건부, 그렇지 않은 것)이 아닌 제한된 허용 가능한 전환 세트 (고 토스)로 연결된 일련의 노드 (상태)를 통한 경로로 가장 이해하기 쉬운 경우 ), 코드에서 명시 적이어야합니다. 그리고 당신은 예쁜 다이어그램을 그려야합니다.

setjmp / longjmp는 예외 또는 예외와 유사한 동작을 구현하는 데 유용 할 수 있습니다. 보편적으로 칭찬되지는 않지만 예외는 일반적으로 "유효한"제어 구조로 간주됩니다.

setjmp / longjmp는 올바르게 사용하기가 어렵다는 점에서 goto보다 '더 위험합니다'.

나쁜 코드를 작성하는 것이 가장 어려운 언어는 없었습니다. -도널드 크 누스

C에서 고토를 복용하는 것이 쉬워 C.에서 사실 좋은 코드를 작성하지 것이다, 오히려 C가되는 시점을 놓칠 되어 영광 어셈블러 언어의 역할을 할 수 있어야한다.

다음은 "유해한 것으로 간주되는 포인터", "유해한 것으로 간주되는 덕 타이핑"입니다. 그러면 안전하지 않은 프로그래밍 구조를 제거 할 때 누가 당신을 변호해야합니까? 뭐라고?

에서 리눅스 : 커널 코드에서 고토를 사용하여 커널 트랩에, 리누스 토발즈 (Linus Torvalds)와 리눅스 코드 GOTOs의 사용에 대한 "새로운 남자"와 토론이있다. 거기에 아주 좋은 점이 있으며 Linus는 일반적인 오만을 입었습니다. :)

일부 구절 :

Linus : "아니, 당신은 Niklaus Wirth가 실제로 자신이 무슨 말을하는지 알고 있다고 생각하는 CS 사람들에 의해 세뇌를당했습니다. 그는 몰랐습니다.

-

Linus : "고토는 괜찮고, 많은 양의 들여 쓰기보다 더 읽기 쉽다고 생각합니다."

-

Linus : "물론 레이블을 설명 할 수없는 파스칼과 같은 어리석은 언어에서는 goto가 잘못 될 수 있습니다."

C에서는 goto현재 함수의 범위 내에서만 작동하며 잠재적 인 버그를 지역화하는 경향이 있습니다. setjmp그리고 longjmp복잡하고 구현에 의존, 로컬이 아닌되고, 훨씬 더 위험하다. 그러나 실제로는 많은 문제를 일으키기에는 너무 모호하고 흔하지 않습니다.

나는 gotoC에서 의 위험 이 크게 과장 되었다고 믿는다 . 원래의 goto주장은 초보자가 다음과 같이 스파게티 코드를 작성하는 구식 BASIC과 같은 언어 시대에 다시 발생했습니다.

3420 IF A > 2 THEN GOTO 1430

여기 리누스의 적절한 사용을 설명 goto: http://www.kernel.org/doc/Documentation/CodingStyle (7 장).

오늘날 GOTO"구조화 된 프로그래밍"사람들이 대부분 토론에서 이기고 오늘날의 언어는 피할 수있는 충분한 제어 흐름 구조를 가지고 있기 때문에 오늘날이 성명서 에 대해 많은 것을 이해하기는 어렵습니다 GOTO.

goto현대 C 프로그램에서 의 수를 센다 . 지금의 수를 추가 break, continue그리고 return문을. 또한, 사용 횟수 추가 if, else, while, switch또는 case. GOTODijkstra가 그의 편지를 썼을 때 1968 년에 FORTRAN 또는 BASIC으로 글을 쓰면 프로그램 에 얼마나 많은 것들이 있었는지에 관한 것입니다.

당시 프로그래밍 언어에는 제어 흐름이 부족했습니다. 예를 들어, 원래 Dartmouth BASIC에서 :

• IF진술은 없었다 ELSE. 원한다면 다음과 같이 작성해야합니다.

  100 IF NOT condition THEN GOTO 200
  ...stuff to do if condition is true...
  190 GOTO 300
  200 REM else
  ...stuff to do if condition is false...
  300 REM end if
  

• 귀하의 경우에도 IF문이 필요하지 않았다 ELSE, 그것은 여전히 일반적으로 구성되어 한 줄에 제한되었다 GOTO.

• DO...LOOP진술 은 없었다 . 비 FOR루프의 경우 명시 적 GOTO또는 IF...GOTO처음으로 돌아가서 루프를 종료해야했습니다 .

• 없습니다 SELECT CASE. 을 사용해야했습니다 ON...GOTO.

그래서, 당신은 함께 결국 많은 의 GOTO프로그램에의. 그리고 당신은 GOTO단일 서브 루틴 내에서 의 s 의 제한에 의존 할 수 없었기 때문에 ( GOSUB...RETURN그러한 약한 서브 루틴 개념 이기 때문에 ) 이것들 GOTO은 어디든 갈 수 있습니다 . 분명히 이것은 제어 흐름을 따르기가 어려워졌습니다.

이것이 바로 반 GOTO운동이 시작된 곳 입니다.

Go To는 경우에 따라 "실제"예외 처리를위한 일종의 독립형을 제공 할 수 있습니다. 치다:

ptr = malloc(size);
if (!ptr) goto label_fail;
bytes_in = read(f_in,ptr,size);
if (bytes_in=<0) goto label_fail;
bytes_out = write(f_out,ptr,bytes_in);
if (bytes_out != bytes_in) goto label_fail;

분명히이 코드는 공간을 덜 차지하도록 단순화되었으므로 세부 사항에 너무 매달리지 마십시오. 그러나 goto 사용을 피하기 위해 코더가 부당한 길이로 이동하여 프로덕션 코드 에서 너무 많이 본 대안을 고려하십시오 .

success=false;
do {
    ptr = malloc(size);
    if (!ptr) break;
    bytes_in = read(f_in,ptr,size);
    if (count=<0) break;
    bytes_out = write(f_out,ptr,bytes_in);
    if (bytes_out != bytes_in) break;
    success = true;
} while (false);

이제 기능적으로이 코드는 똑같은 일을합니다. 실제로 컴파일러가 생성 한 코드는 거의 동일합니다. 그러나 프로그래머가 Nogoto (두려운 학문적 견책의 신) 를 달래려는 열의 에서이 프로그래머는 while루프가 나타내는 근본적인 관용구를 완전히 깨뜨 렸고 코드의 가독성을 실제로 평가했습니다. 이것은 좋지 않습니다.

따라서 이야기의 도덕은 goto 사용을 피하기 위해 정말로 바보 같은 것에 의지한다면 발견하지 마십시오.

Donald E. Knuth는 1992 년 CSLI의 "Literate Programming"책에서이 질문에 답변했습니다. 에 p. 17 " goto 문으로 구조화 된 프로그래밍 "(PDF) 에세이가 있습니다. 나는 그 기사가 다른 책에서도 출판되었을 것으로 생각합니다.

이 기사는 Dijkstra의 제안과 이것이 유효한 상황을 설명합니다. 그러나 그는 또한 구조화 된 루프만으로는 쉽게 재현 할 수없는 많은 카운터 예제 (문제 및 알고리즘)를 제공합니다.

이 기사에는 문제에 대한 완전한 설명, 기록, 예제 및 카운터 예제가 포함되어 있습니다.

도움이되는 것으로 간주됩니다.

1970 년대 프로그래머에게 "고토는 해로운 것으로 간주된다"는 말은 현대적인 제어 구조를 가진 새로운 프로그래밍 언어가 시도해 볼 가치가 있다고 말했다. 우리는 새로운 언어를 시도했습니다. 우리는 빨리 회심했다. 우리는 다시는 돌아 오지 않았습니다.

우리는 다시는 돌아 오지 않았지만, 만약 당신이 더 어리다면 처음에는 그곳에 가본 적이 없습니다.

이제 고대 프로그래밍 언어의 배경은 프로그래머의 나이를 나타내는 지표를 제외 하고는별로 유용하지 않을 수 있습니다. 그럼에도 불구하고, 젊은 프로그래머에게는 이러한 배경이 없기 때문에 "유해한 것으로 간주된다"라는 슬로건 이 소개 될 당시 의도 된 청중에게 전달 된 메시지를 더 이상 이해하지 못합니다 .

이해하지 못하는 슬로건은 그다지 밝지 않습니다. 그런 구호를 잊어 버리는 것이 가장 좋습니다. 그러한 슬로건은 도움이되지 않습니다.

그러나이 특정 슬로건 인 "고토는 해로운 것으로 간주했다"는 그 자체의 언데드 생활을 취했다.

학대를 당할 수 없습니까? 답 : 물론입니다. 그렇다면 무엇입니까? 실제로 모든 프로그래밍 요소 가 남용 될 수 있습니다. bool예를 들어 겸손 은 우리 중 일부가 믿고 싶어하는 것보다 더 자주 학대를받습니다.

대조적으로, 나는 1990 년 이래로 실제 단일 고토 ​​남용 사례를 만나는 것을 기억할 수 없습니다.

goto의 가장 큰 문제는 아마도 기술적 인 것이 아니라 사회적 일 것입니다. 많이 알지 못하는 프로그래머는 때때로 goto를 사용하지 않으면 스마트하게 들린다 고 생각하는 것 같습니다. 때때로 그러한 프로그래머를 만족시켜야 할 수도 있습니다. 그런 삶입니다.

오늘날 goto의 최악의 점은 충분하지 않다는 것입니다.

Jay Ballou가 대답을 추가하여 끌면 £ 0.02를 추가하겠습니다. Bruno Ranschaert가 아직 그렇게하지 않았다면 Knuth의 "GOTO 문으로 구조화 된 프로그래밍"기사를 언급했을 것입니다.

내가 보지 못한 것 중 하나는 정확히 공통적이지는 않지만 Fortran 교과서에서 가르치는 일종의 코드입니다. DO 루프의 확장 된 범위 및 오픈 코드 서브 루틴과 같은 것 (Fortran 77 또는 90이 아닌 Fortran II 또는 Fortran IV 또는 Fortran 66 임)을 기억하십시오. 구문 세부 사항이 정확하지 않을 가능성이 있지만 개념은 충분히 정확해야합니다. 각 경우의 스 니펫은 단일 기능 내에 있습니다.

Kernighan & Plauger가 쓴 훌륭하지만 날짜가 적힌 (그리고 인쇄되지 않은) 책 ' The Programming of Style of Style, 2nd Edn '에는 당시의 교과서 프로그래밍 (후기 70 년대)에서 GOTO를 남용한 실제 사례가 포함되어 있습니다. 그러나 아래 자료는 그 책이 아닙니다.

DO 루프를위한 확장 된 범위

       do 10 i = 1,30
           ...blah...
           ...blah...
           if (k.gt.4) goto 37
91         ...blah...
           ...blah...
10     continue
       ...blah...
       return
37     ...some computation...
       goto 91

그런 말도 안되는 이유 중 하나는 구식 펀치 카드였습니다. 레이블 (정식 스타일이기 때문에 순서가 잘못되었습니다!)은 1 열에 있으며 (실제로 1-5 열에 있어야 함) 코드는 7-72 ​​열에 있습니다 (6 열은 연속 임) 마커 열). 열 73-80에는 순서 번호가 주어졌으며 펀치 카드 데크를 순서 번호 순서로 정렬하는 기계가있었습니다. 시퀀싱 된 카드에 프로그램이 있고 루프 중간에 몇 개의 카드 (라인)를 추가해야한다면, 여분의 라인 다음에 모든 것을 다시 시작해야합니다. 그러나 하나의 카드를 GOTO로 교체 한 경우 모든 카드를 다시 시퀀싱하지 않아도됩니다. 루틴 끝에 새 카드를 새 시퀀스 번호로 넣었습니다. '그린 컴퓨팅'의 첫 번째 시도라고 생각하십시오.

아시다시피, 속이는 소리가 나지 않습니다. Fortran IV는 모두 대문자로 작성되었습니다.

오픈 코드 서브 루틴

       ...blah...
       i = 1
       goto 76
123    ...blah...
       ...blah...
       i = 2
       goto 76
79     ...blah...
       ...blah...
       goto 54
       ...blah...
12     continue
       return
76     ...calculate something...
       ...blah...
       goto (123, 79) i
54     ...more calculation...
       goto 12

레이블 76과 54 사이의 GOTO는 계산 된 goto의 버전입니다. 변수 i의 값이 1이면 목록의 첫 번째 레이블 (123)로 이동하십시오. 값이 2이면 두 번째 등으로 이동하십시오. 76에서 계산 된 goto 로의 조각은 오픈 코드 서브 루틴입니다. 서브 루틴처럼 실행되는 코드 조각이지만 함수 본문에 작성되었습니다. (Fortran에는 또한 한 줄에 맞는 내장 함수 인 명령문 함수가있었습니다.)

계산 된 goto보다 구조가 잘못되었습니다. 레이블을 변수에 할당 한 다음 할당 된 goto를 사용할 수 있습니다. Googling이 할당 한 goto 는 그것이 Fortran 95에서 삭제되었다고 알려줍니다. Dijkstra의 "GOTO로 간주되는 유해한"서한이나 기사를 통해 공개적으로 시작될 수있는 구조화 된 프로그래밍 혁명을위한 초크.

Fortran (및 대부분의 길가에 제대로 빠진 다른 언어)에서 수행 된 일에 대한 지식이 없으면, 새로 온 사람들이 Dijkstra가 다루고있는 문제의 범위를 이해하기 어렵습니다. 도대체 그 편지가 출판 된 후 10 년이되기 전까지는 프로그래밍을 시작하지 않았습니다.

GOTO가 해로운 것으로 간주하는 것은 없습니다 .

GOTO는 도구이며 모든 도구로서 사용 및 남용 될 수 있습니다 .

그러나 프로그래밍 세계에는 많은 도구 가 사용되는 것보다 남용 되는 경향이 있으며 GOTO가 그 중 하나입니다. 델파이 의 WITH 문은 또 다른 것입니다.

개인적으로 나는 전형적인 코드 중 어느 것도 사용하지 않지만 보증 된 GOTO 와 WITH 의 이상한 사용법을 사용 했으며 다른 솔루션에는 더 많은 코드가 포함되어 있습니다.

가장 좋은 해결책은 컴파일러가 키워드가 오염 되었음을 경고하고 경고문을 없애기 위해 명령문 주위에 pragma 지시문을 채워야한다는 것입니다.

아이들에게 가위로 달리지 말라고하는 것과 같습니다 . 가위는 나쁘지 않지만 일부 사용법은 건강을 유지하는 가장 좋은 방법은 아닙니다.

당신이 스스로 생각할 수있는 한 결코 그렇지 않았습니다.

리눅스 커널에서 몇 가지 일을 시작했기 때문에 gotos는 한 번처럼 나를 귀찮게하지 않습니다. 처음에 나는 그들이 (커널 녀석들) 내 코드에 gotos를 추가 한 것을보고 무서웠다. 그 이후로 일부 제한된 상황에서 고 토스 사용에 익숙해졌으며 이제는 때때로 직접 사용할 것입니다. 일반적으로 함수의 여러 위치에서 동일한 정리 및 구제를 복제하는 대신 일종의 정리 및 구제를 수행하는 함수의 끝으로 이동하는 goto입니다. 그리고 일반적으로 다른 함수로 넘길 정도로 크지 않습니다. 예를 들어 일부 로컬 (k) malloc'ed 변수를 해제하는 것이 일반적인 경우입니다.

setjmp / longjmp를 한 번만 사용하는 코드를 작성했습니다. MIDI 드럼 시퀀서 프로그램에있었습니다. 재생은 모든 사용자 상호 작용과는 별도의 프로세스로 수행되었으며 재생 프로세스는 UI 프로세스와 공유 메모리를 사용하여 재생에 필요한 제한된 정보를 얻었습니다. 사용자가 재생을 멈추고 싶을 때, 재생 과정은 사용자가 멈추기를 원할 때 실행되는 곳의 복잡한 풀기보다는 longjmp를 "처음으로 돌아 가기"로 시작했습니다. 그것은 훌륭하게 작동했고 간단했으며 그 경우 관련된 문제 나 버그가 없었습니다.

setjmp / longjmp는 그들의 장소를 가지고 있지만 그 장소는 당신이 방문하지 않을 것이지만 아주 오랫동안 한 번입니다.

편집 : 방금 코드를 보았습니다. 실제로는 longjmp가 아닌 사용하는 siglongjmp ()였습니다.

C로 VM을 작성하는 경우 (gcc)를 사용하여 다음과 같이 계산해야합니다.

char run(char *pc) {
    void *opcodes[3] = {&&op_inc, &&op_lda_direct, &&op_hlt};
    #define NEXT_INSTR(stride) goto *(opcodes[*(pc += stride)])
    NEXT_INSTR(0);
    op_inc:
    ++acc;
    NEXT_INSTR(1);
    op_lda_direct:
    acc = ram[++pc];
    NEXT_INSTR(1);
    op_hlt:
    return acc;
}

루프 내부의 기존 스위치보다 훨씬 빠르게 작동합니다.

goto혼란스러운 메타 프로그래밍에 사용할 수 있기 때문에

Goto둘 다 높은 수준 과 낮은 수준의 제어 표현, 그 결과 단지 대부분의 문제에 적합한 적절한 디자인 패턴이없는가.

그것은이다 낮은 수준의 고토가 원시적 작업이라는 의미에서 더 높은 같은 구현 뭔가 while나 foreach또는 뭔가.

그건 높은 수준의 특정 방법으로 사용할 때 명확한 순서에서 실행이 중단 방식으로, 구조화 된 루프를 제외하고 그 코드를 취한다는 의미에서, 그리고 그것을 충분히 함께있는 논리의 조각으로 변경 goto의, 복 논리의 -bag는 동적으로 재 조립되고 있습니다.

따라서에 대한 찬성 과 악한 면이 goto있습니다.

산문 측은 상향 포인팅 고토 완벽하게 합리적인 루프를 구현할 수 있고, 아래 방향 고토 완벽하게 합리적인 할 수 있다는 것 break또는 return. 물론 가난한 사람은 큰 그림을 얻기 위해 효과를 시뮬레이션 할 필요가 없기 때문에 실제 while, break또는 return훨씬 더 읽기 goto쉽습니다. 일반적으로 나쁜 생각입니다.

악마 측 루틴이 동안, 휴식, 또는 반환에 대한 고토를 사용하지만,라고하는 것에 대해 사용하지 않을 포함 스파게티 로직 . 이 경우 goto-happy 개발자는 goto의 미로에서 코드 조각을 작성하고 있으며 그것을 이해하는 유일한 방법은 전체적으로 정신적으로 전체를 시뮬레이션하는 것입니다. 내 말은, 코드 else가 정확하게 반대의 코드 가 아닌 if곳에서 중첩 된 ifs가 외부 if등에 의해 거부 된 것들을 허용 할 수있는 코드를 평가하는 문제를 상상해보십시오 .

마지막으로, 주제를 실제로 다루기 위해, 기본적으로 Algol을 제외한 모든 초기 언어는 단일 버전의 if-then-else. 따라서 조건부 블록을 수행하는 유일한 방법 goto은 역 조건부를 사용하는 것입니다. 미쳤지 만, 나는 오래된 사양을 읽었습니다. 첫 번째 컴퓨터는 바이너리 머신 코드로 프로그래밍되었으므로 어떤 종류의 HLL도 생명의 은인이라고 생각합니다. 나는 그들이 가지고있는 HLL 기능에 대해 너무 까다 롭지 않았다고 생각합니다.

goto내가 " 모든 순수 주의자들을 귀찮게하기 위해" 쓴 모든 프로그램에 하나를 붙이는 데 사용했던 모든 것을 말 했었다 .

프로그래머에게 GOTO 문 사용을 거부하는 것은 목수에게 망치로 망치를 쓰지 말라고 망치로 쓰지 말라고 말하는 것과 같습니다. 실제 프로그래머는 GOTO 사용 방법과시기를 알고 있습니다. 나는 소위 '구조화 된 프로그램 (Structured Programs)'의 일부를 따랐다. 나는 프로그래머를 쏠 수있는 GOTO 사용을 피하기 위해 그러한 Horrid 코드를 보았다. 좋아, 다른 쪽을 방어하기 위해, 나는 진짜 스파게티 코드를 여러 번 보았습니다. 그 프로그래머들도 총에 맞아야합니다.

여기 내가 찾은 작은 코드 예제가 있습니다.

  YORN = ''
  LOOP
  UNTIL YORN = 'Y' OR YORN = 'N' DO
     CRT 'Is this correct? (Y/N) : ':
     INPUT YORN
  REPEAT
  IF YORN = 'N' THEN
     CRT 'Aborted!'
     STOP
  END

-----------------------또는----------------------

10:  CRT 'Is this Correct (Y)es/(N)o ':

     INPUT YORN

     IF YORN='N' THEN
        CRT 'Aborted!'
        STOP
     ENDIF
     IF YORN<>'Y' THEN GOTO 10

"이 링크에서 http://kerneltrap.org/node/553/2131 "

아이러니하게도 goto를 제거하면 버그가 발생했습니다. spinlock 호출이 생략되었습니다.

원본 논문은 "무조건 GOTO는 유해한 것으로 간주 됨"으로 생각해야합니다. 특히 초기 코드에 공통적 인 테스트 및 점프보다는 조건부 ( if) 및 반복 ( while) 구문을 기반으로하는 프로그래밍 형식을 옹호했습니다 . goto적절한 제어 구조가없는 일부 언어 또는 환경에서 여전히 유용합니다.

Goto 가 사용할 수 있는 유일한 장소 는 오류를 처리해야 할 때이며 오류가 발생하는 각 특정 지점에는 특별한 처리가 필요합니다.

예를 들어 리소스를 잡고 세마포어 또는 뮤텍스를 사용하는 경우 순서대로 가져와야하며 항상 반대 방식으로 해제해야합니다.

일부 코드는 이러한 리소스를 잡는 매우 이상한 패턴이 필요하며 교착 상태를 피하기 위해 이러한 리소스를 잡아서 해제하는 것을 올바르게 처리하기 위해 쉽게 유지 관리되고 이해되는 제어 구조를 작성할 수는 없습니다.

goto없이 올바르게 수행하는 것이 항상 가능하지만이 경우 몇 가지 Goto는 실제로 가독성과 유지 관리 성을 위해 더 나은 솔루션입니다.

-아담

현대의 GOTO 사용법 중 하나는 C # 컴파일러에서 수익률 반환으로 정의 된 열거자를위한 상태 머신을 만드는 것입니다.

GOTO는 프로그래머가 아닌 컴파일러가 사용해야하는 것입니다.

C와 C ++ (다른 범인들 사이에서)이 중단을 표시하고 계속할 때까지 goto는 계속 역할을 수행 할 것입니다.

GOTO 자체가 악한 경우 컴파일러는 JMP를 생성하기 때문에 악할 수 있습니다. 특히 포인터를 따르는 코드 블록으로 점프하는 것이 본질적으로 악한 경우 RETurn 명령은 악합니다. 오히려 악은 악용 될 가능성이 있습니다.

때때로 나는 각 객체가 이벤트에 대한 응답으로 복잡한 상태 시퀀스를 따라야하는 많은 객체를 추적 해야하는 앱을 작성해야했지만 모든 것이 분명히 단일 스레드였습니다. 의사 코드로 표시되는 일반적인 상태 순서는 다음과 같습니다.

request something
wait for it to be done
while some condition
    request something
    wait for it
    if one response
        while another condition
            request something
            wait for it
            do something
        endwhile
        request one more thing
        wait for it
    else if some other response
        ... some other similar sequence ...
    ... etc, etc.
endwhile

나는 이것이 새로운 것이 아니라고 확신하지만 C (++)에서 처리하는 방식은 일부 매크로를 정의하는 것이 었습니다.

#define WAIT(n) do{state=(n); enque(this); return; L##n:;}while(0)
#define DONE state = -1

#define DISPATCH0 if state < 0) return;
#define DISPATCH1 if(state==1) goto L1; DISPATCH0
#define DISPATCH2 if(state==2) goto L2; DISPATCH1
#define DISPATCH3 if(state==3) goto L3; DISPATCH2
#define DISPATCH4 if(state==4) goto L4; DISPATCH3
... as needed ...

그런 다음 (상태가 처음에 0이라고 가정) 위의 구조적 상태 머신은 구조적 코드로 바뀝니다.

{
    DISPATCH4; // or as high a number as needed
    request something;
    WAIT(1); // each WAIT has a different number
    while (some condition){
        request something;
        WAIT(2);
        if (one response){
            while (another condition){
                request something;
                WAIT(3);
                do something;
            }
            request one more thing;
            WAIT(4);
        }
        else if (some other response){
            ... some other similar sequence ...
        }
        ... etc, etc.
    }
    DONE;
}

이에 대한 변형으로 CALL 및 RETURN이있을 수 있으므로 일부 상태 머신은 다른 상태 머신의 서브 루틴처럼 작동 할 수 있습니다.

특이한가요? 예. 관리자의 입장에서 약간의 학습이 필요합니까? 예. 그 학습은 돈을 지불합니까? 나도 그렇게 생각해. 블록으로 뛰어 드는 GOTO없이 할 수 있습니까? 아니.

동료 / 관리자가 의심 할 여지없이 코드 검토 또는 넘어 질 때 사용에 의문을 제기하기 때문에 그것을 피합니다. 내가 사용한다고 생각하지만 (예 : 오류 처리 사례)-어떤 종류의 문제가있는 다른 개발자를 무시할 것입니다.

그것은 가치가 없어.

실제로이 코드를 작성하는 더 나은 (빠른) 방법을 생각할 수 없기 때문에 실제로 goto를 사용해야한다는 것을 알았습니다.

나는 복잡한 물건을 가지고 있었고, 그것에 대한 작업이 필요했습니다. 객체가 하나의 상태에 있으면 작업의 빠른 버전을 수행 할 수 있고, 그렇지 않으면 작업의 느린 버전을 수행해야했습니다. 문제는 느린 작동 중에는 빠른 작동으로 수행 할 수 있다는 것을 알 수있었습니다.

SomeObject someObject;    

if (someObject.IsComplex())    // this test is trivial
{
    // begin slow calculations here
    if (result of calculations)
    {
        // just discovered that I could use the fast calculation !
        goto Fast_Calculations;
    }
    // do the rest of the slow calculations here
    return;
}

if (someObject.IsmediumComplex())    // this test is slightly less trivial
{
    Fast_Calculations:
    // Do fast calculations
    return;
}

// object is simple, no calculations needed.

이것은 실시간 UI 코드의 속도에 중요한 부분이므로 GOTO가 여기에 정당하다고 생각합니다.

휴고

goto를 사용할 수있는 거의 모든 상황에서 다른 구문을 사용하여 동일한 작업을 수행 할 수 있습니다. 어쨌든 컴파일러는 Goto를 사용합니다.

나는 개인적으로 그것을 절대로 사용하지 않으며, 절대로 필요하지 않습니다.

나는에서 볼 수없는 한 것은 어떤 여기에 대한 답변은 '고토'솔루션은 종종 있다는 것입니다 보다 효율적으로 자주 언급 구조화 된 프로그래밍 솔루션보다.

많은 if(breakVariable)섹션 대신 'goto'를 사용하는 것이 분명히 더 효율적인 많은 중첩 루프 사례를 고려하십시오 . 솔루션 "루프를 함수에 넣고 리턴을 사용하십시오"는 종종 불합리합니다. 루프가 로컬 변수를 사용하고있을 가능성이있는 경우 이제 함수 변수를 통해 모든 변수를 전달하여 잠재적으로 그로 인해 발생하는 추가 두통을 처리해야합니다.

이제 필자가 자주 사용했던 정리 사례를 생각해 보자. 많은 언어에서는 사용할 수없는 try {} catch {} 구조에 대해 책임이있는 것으로 추정된다. 동일한 작업을 수행하는 데 필요한 검사 및 추가 변수의 수는 점프를 수행하는 하나 또는 두 개의 명령보다 훨씬 나쁘며 추가 기능 솔루션은 전혀 솔루션이 아닙니다. 더 관리하기 쉽고 읽기 쉽다고 말할 수 없습니다.

이제 코드 공간, 스택 사용 및 실행 시간은 많은 프로그래머에게 많은 상황에서 충분하지 않을 수 있지만, 2KB의 코드 공간으로 작업 할 수있는 임베디드 환경에있는 경우 명확하게 정의 된 코드를 피하기위한 50 바이트의 추가 명령 'goto'는 웃을 수 있으며, 이는 많은 고급 프로그래머가 믿는 것처럼 드문 상황이 아닙니다.

'고토는 해롭다'는 말은 구조화 프로그래밍이 항상 과도하게 생성 되었음에도 불구하고 구조화 된 프로그래밍으로 나아가는 데 매우 도움이되었습니다. 이 시점에서 우리는 그것을 사용하는 것에 대해 조심해야한다고 들었습니다. 그것이 작업에 가장 적합한 도구 일 때, 우리는 그것을 두려워 할 필요가 없습니다.

깊게 중첩 된 루프를 해제하는 데 사용할 수 있지만 대부분의 경우 깊게 중첩 된 루프없이 코드를 더 리팩토링 할 수 있습니다.