goto를 사용하는 것이 가치가 있습니까?

goto거의 보편적으로 낙담했습니다. 이 진술을 사용하는 것이 가치가 있습니까?

이것은 스택 오버플로에서 여러 번 논의되었으며 Chris Gillum 은 다음과 같은 용도를 요약했습니다goto .

기능을 완전히 종료

종종 함수에서 자원을 할당하고 여러 곳에서 종료해야 할 수도 있습니다. 프로그래머는 함수의 끝 부분에 리소스 정리 코드를 넣어 함수의 모든 "종료 지점"이 정리 레이블로 이동하여 코드를 단순화 할 수 있습니다. 이런 식으로 함수의 "종료 지점"마다 정리 코드를 작성할 필요가 없습니다.

중첩 루프 종료

중첩 루프에 있고 모든 루프에서 분리해야하는 경우 goto는 break 문 및 if-check보다 훨씬 깨끗하고 간단하게 만들 수 있습니다.

저수준 성능 개선

이것은 per-critical 코드에서만 유효하지만 goto 문은 매우 빠르게 실행되며 함수를 이동할 때 부스트를 줄 수 있습니다. 그러나 컴파일러는 일반적으로 gotos가 포함 된 코드를 최적화 할 수 없기 때문에 양날의 검입니다.

다른 많은 사람들이 주장 하듯이,이 모든 경우에 사용은 goto자신을 코딩 한 구석에서 벗어날 수있는 수단으로 사용되며 일반적으로 리팩토링 될 수있는 코드의 증상이라고 주장합니다.

높은 수준의 제어 흐름 구성은 문제 영역의 개념에 해당하는 경향이 있습니다. if / else는 일부 조건에 따른 결정입니다. 루프는 어떤 동작을 반복적으로 수행하라고 말합니다. 브레이크 선언조차도 "우리는 이것을 반복적으로하고 있었지만 이제는 멈춰야한다"고 말합니다.

반면에 goto 문은 문제 영역이 아닌 실행중인 프로그램의 개념에 해당하는 경향이 있습니다. 프로그램 의 특정 지점 에서 실행을 계속한다고 말합니다 . 코드를 읽는 사람 은 문제 영역과 관련하여 그 의미 를 추론 해야합니다.

물론 모든 상위 레벨 구조는 gotos 및 간단한 조건부 분기로 정의 할 수 있습니다. 그렇다고해서 변장 한 것만은 아닙니다. 그것들을 제한된 gotos 라고 생각하십시오 -그것들을 유용하게 만드는 것은 제한입니다. break 문은 둘러싼 루프의 끝으로 점프하는 것으로 구현되지만 루프 전체에서 작동하는 것이 더 좋습니다.

다른 모든 것은 동일하다. 구조가 문제 영역의 구조를 반영하는 코드는 읽고 유지하기가 더 쉽다.

goto 문이 절대적으로 필요한 경우는 없지만 ( 그 효과에 대한 정리 가 있음) 가장 나쁜 해결책이 될 수있는 경우가 있습니다. 이러한 경우는 언어가 지원하는 상위 구조에 따라 언어마다 다릅니다.

예를 들어 C에서는 goto가 적합한 세 가지 기본 시나리오가 있다고 생각합니다.

1. 중첩 루프에서 벗어나기 언어에 레이블이 지정된 break statement가 있으면 불필요합니다.
2. 오류 또는 기타 예상치 못한 이벤트가 발생하는 경우 코드 (일반적으로 함수 본문)에서 벗어나기. 언어에 예외가있는 경우에는 불필요합니다.
3. 명시 적 유한 상태 머신을 구현합니다. 이 경우 goto는 문제 도메인의 개념에 직접 대응하여 한 상태에서 지정된 다른 상태로 전환하며 현재 상태는 현재 실행중인 코드 블록으로 표시됩니다. .

한편, 명시 적 유한 상태 머신은 루프 내부의 switch 문으로도 구현할 수 있습니다. 이것은 모든 상태가 코드에서 같은 위치에서 시작한다는 장점이 있는데, 예를 들어 디버깅에 유용 할 수 있습니다.

합리적으로 현대적인 언어 (if / else 및 루프를 지원하는 언어)에서 goto의 주요 용도는 언어에서 누락 된 제어 흐름 구성을 시뮬레이션하는 것입니다.

확실히 그것은 프로그래밍 언어에 달려 있습니다. goto논쟁의 여지가 있었던 주된 이유 는 컴파일러가 너무 자유롭게 사용할 수있을 때 발생하는 악영향 때문입니다. 예를 들어 goto초기화되지 않은 변수에 액세스하거나 다른 방법으로 이동하여 호출 스택을 망칠 수있는 방식으로 사용할 수있는 경우 문제가 발생할 수 있습니다 . 무의미한 제어 흐름을 허용하지 않는 것은 컴파일러의 책임입니다.

Java는이 문제를 goto완전히 금지 함으로써이 문제를“해결”하려고 시도했습니다 . 그러나 Java를 사용하면 블록 return내부에서 사용할 finally수 있으므로 예외가 실수로 삼키게됩니다. 동일한 문제가 여전히 존재합니다. 컴파일러가 작업을 수행하지 않습니다. goto언어에서 제거해도 문제 가 해결되지 않았습니다.

C #에서, goto안전뿐만 같다 break, continue, try/catch/finally와 return. 초기화되지 않은 변수를 사용할 수 없으며 finally 블록을 뛰어 넘을 수 없습니다. 컴파일러가 불평합니다. 이것은 실제 문제를 해결하기 때문입니다. 이것은 내가 무의미한 제어 흐름이라고 말한 것과 같습니다. goto명확한 할당 분석 및 기타 합리적인 컴파일러 검사를 마술처럼 취소하지 않습니다.

예. 루프가 여러 수준으로 중첩 된 경우 내부 루프를 우아하게 분리 할 수 goto있는 유일한 방법입니다. 다른 옵션은 플래그를 설정하고 해당 플래그가 조건을 만족하는 경우 각 루프에서 분리하는 것입니다. 이것은 실제로 추악하고 오류가 발생하기 쉽습니다. 이 경우 goto단순히 더 좋습니다.

물론 Java의 레이블이 지정된 break명령문은 동일한 작업을 수행하지만 코드에서 임의의 지점으로 이동할 수 goto없으므로 악의적 인 것을 허용하지 않고 문제를 깔끔하게 해결할 수 있습니다.

낙담의 대부분은 60 년대 초반에 다음과 같은 무차별적인 힘에 대해 설득력있는 신 지크 스트라 (Jaikstra) 신에게 큰 소리로 창조 된 일종의 "종교"에서 나온다.

• 어떤 코드 블록 으로든 뛰어들 수 있습니다.
  • 처음부터 기능이 실행되지 않음
  • 처음부터 실행되지 않은 루프
  • 건너 뛴 변수 초기화
• 가능한 정리없이 코드 블록에서 벗어나십시오.

이것은 goto현대 언어 의 진술 과 더 이상 관련이 없으며 , 존재하는 언어 이외의 코드 구조의 생성을 지원하기 위해 존재합니다.

특히 위의 첫 번째 주요 지점은 더 이상 허용되고 두 번째 주요 지점은 청소됩니다 ( goto블록에서 스택을 가져 오면 스택이 올바르게 풀리고 모든 적절한 소멸자가 호출 됨)

goto를 사용하지 않는 코드조차도 읽을 수없는 방법을 알기 위해이 답변 을 참조 할 수 있습니다. 문제 자체가 아니라 잘못 사용하는 것입니다.

if그냥 사용하지 않고 전체 프로그램을 작성할 수 있습니다 for. 물론, 읽기 어렵고, 어색하고 불필요하게 복잡하지는 않습니다.

그러나 문제는 아닙니다 for. 나야

상황이 좋아 break, continue, throw, bool needed=true; while(needed) {...}, 등의 이상 지적하는 가장 무도회 goto -50 년 현대 laguages-의 발명 이후 여전히 포로를 원하는의 Djikstrarian 광신자의 scimitars에서 멀리 탈출. 그들은 지크 스트라가 말한 것을 잊었고, 단지 그의 음표의 제목 만 기억하고 (GOTO는 해로운 것으로 간주되었고 그의 제목도 아니었다 : 편집자에 의해 변경되었다) 4 순서대로 배치 된 편지.

2011 년 : Djikstra가 강요 goto한 GOTO진술 을 다루지 않은 것을 이해해야 할 때 입니다.

함수가 지역적으로 존재하는 한 여기 저기의 이상한 이동은 가독성을 크게 해치지 않습니다. 이 코드에는 다소 드문 제어 구조를 사용해야하는 비정상적인 문제가 있다는 사실에주의를 기울임으로써 종종 이점이 있습니다.

(로컬) gotos가 가독성을 크게 손상시키는 경우 일반적으로 goto를 포함하는 함수가 너무 복잡해 졌다는 신호입니다.

내가 C 코드에 넣은 마지막 goto는 한 쌍의 연동 루프를 만드는 것이 었습니다. "허용되는"goto 사용의 일반적인 정의에는 맞지 않지만 결과적으로 함수는 훨씬 작고 명확 해졌습니다. 고토를 피하기 위해서는 특히 지저분한 DRY 위반이 필요했을 것입니다.

나는이 모든 문제가 잘못된 나무를 짖는 사례라고 생각합니다.

GOTO는 나에게는 문제가되지 않지만 오히려 종종 스파게티 코드의 실제 죄의 증상입니다.

GOTO가 유량 제어 라인의 주요 교차점을 유발하면 기간이 좋지 않습니다. 흐름 제어 라인을 통과하지 않으면 무해합니다. 그 사이의 회색 영역에는 루프 구제 금융과 같은 것들이 있지만 모든 합법적 인 회색 사례를 다루는 구문을 추가하지 않은 언어가 여전히 있습니다.

내가 몇 년 동안 실제로 그것을 사용하는 유일한 사례는 결정 지점이 루프의 중간에있는 루프의 경우입니다. 중복 코드, 플래그 또는 GOTO가 남아 있습니다. GOTO 솔루션이 3 가지 중 최고라고 생각합니다. 흐름 제어 라인이 교차하지 않으며 무해합니다.

예, goto는 개발자의 경험에 도움이 될 수 있습니다 : http://adamjonrichardson.com/2012/02/06/long-live-the-goto-statement/

그러나 강력한 도구 (포인터, 다중 상속 등)와 마찬가지로 도구를 사용하여 훈련해야합니다. 링크에 제공된 예제는 PHP를 사용하는데, goto 구문의 사용법을 동일한 함수 / 방법으로 제한하고 새로운 제어 블록 (예 : loop, switch 문 등)으로 건너 뛰는 기능을 비활성화합니다.

언어에 따라 다릅니다. 예를 들어 여전히 Cobol 프로그래밍에서 널리 사용됩니다. 또한 Barionet 50 장치에서 작업했습니다. 펌웨어 프로그래밍 언어는 초기 기본 방언이며 Goto를 사용해야합니다.

나는 아니오라고 말할 것입니다. GOTO를 사용할 필요가 있다면 코드를 다시 디자인해야 할 것입니다.

goto레거시 어셈블러 코드를 C로 포팅 할 때 유용 할 수 있습니다. 첫 번째 경우, goto어셈블러 branch명령을 대신 하여 C 로의 명령 별 변환 은 매우 빠른 포팅을 가능하게합니다.

나는 주장하지 않을 것이다. 그것들은 항상 goto가 해결하는 데 사용되는 문제에 대해 더 구체적인 도구로 대체되어야합니다 (귀하의 언어로 제공되지 않는 한). 예를 들어, break 문과 예외는 루프 이스케이프 및 오류 처리의 이전에 해결 된 문제를 해결합니다.