스레드 지원없이 Windows에서 GCC가 종료됩니까? [닫은]

31

의견이 필요합니다. GCC는 항상 훌륭한 컴파일러 였지만 최근에는 "호소력"을 잃고 있습니다. 방금 Windows GCC에서 std::thread지원 이 없다는 것을 알았 습니다. 가장 흥미로운 기능이 여전히 없기 때문에 Windows 사용자가 다른 컴파일러를 사용하도록 강요했습니다.

그러나 왜 실제로 GCC가 여전히 Windows에서 스레드를 지원하지 않습니까? 라이센스 문제? ABI 비 호환성? (부스트, POCO, SDL, wxwidgets 등 멀티 스레딩을 사용하는 여러 플랫폼 간 라이브러리가 이미 있습니다. GCC 릴리스를 출하하는 대신이 구멍에 맞는 기존 코드 및 MIT / libpng 라이센스를 사용하는 것이 간단하지 않습니까? 스레드 지원이 없습니까?)

최근 컴파일러 비교를 살펴보면 GCC는 다른 컴파일러와 관련하여 C ++ 11 기능을 가장 광범위하게 지원합니다. 단, Windows에서는 원자, 뮤텍스 및 스레드가 여전히 없기 때문에 이것이 사실이 아니라는 사실을 제외하고는 : /

이 주제에 대해 더 알고 싶지만 찾을 수있는 유일한 것은 다음과 같은 이유로 도움을 요청하는 사람들입니다.

std 네임 스페이스에 "스레드"가 없습니다

GCC / TDM-GCC의 티켓 추적 및 메일 토론을 살펴보면 2009 년 이후 스레드 지원 요청이있었습니다. 4 년이 지난 후에도 여전히 해결책이 없습니까? 진짜 무슨 일이야?

c++11  support  multithreading  gcc 
— 게임 개발자
소스
8
gcc는 최근에 알게 된 내용에 관계없이 여전히 좋습니다.
— ott--
1
방금 std :: thread를 좋아했습니다. 그것은 구현하기 어려운 기능이 아니 었습니다. Variadics 템플릿과 SDL 스레드와 같은 클래스를 사용하면 std :: thread : /
— GameDeveloper
12
나는 일반 프로그래머가 신뢰할 수있는 멀티 스레드 응용 프로그램을 작성할 수 없다는 점을 감안할 때 거의 스레드 지원이 보너스가 아닙니다 .....
— mattnz
3
특히 컴파일러가 아닌 라이브러리에 대해 불평하고 있습니다.
— wirrbel
2
GCC는 인기가 있습니다. 그러나 나는 항상 "아주 좋은 컴파일러"라고 말하지는 않을 것이다. 오래 전에 사람들은 GCC에서 생성 한 느리고 부풀린 바이너리 때문에 Linux에서 ICC를 실험하고있었습니다. 모든 주요 오픈 소스 프로젝트 인 OTOH는 VS를 사용하여 코드의 Windows 버전을 다시 컴파일합니다.
— vartec

답변:

23

나는 GCC를 유지하는 사람들이 다소 오만 해졌고 LLVM이 여기에 있고 사람들이 발로 투표하고 있기 때문에 GCC가 유리하지 않다는 것을 이해했습니다.

Slashdot는 LLVM의 C ++ 11에 대한 새로운 지원에 대해 논의했습니다 . _merlin의 말 :

오, 나는 그것이 악하다고 생각하지 않는다고 생각합니다. 단지 관대함보다는 순수한 자기 이익이라는 것입니다. GCC의 경이적인 인기로 인해 관리자는 자존심이 커지고 총계 [ * *** ] 처럼 행동했습니다 . 버그는 Red Hat보다 빠르게 도입되며 Apple은 패치를 받아 들일 수 있으며 버그 보고서를 보지 않고 실제로 수정하지 않고 비 활동으로 인해 종료되는 습관이 있습니다.

4 년 지연에 대한 당신의 관찰과 흡사합니다.

— bj
소스
당신은 또한 찾을 수 있습니다 developers.slashdot.org/... GCC와 비 리눅스 용으로 컴파일과 다른 문제를 지적하고 (또한 _merlin에 의해).
3
그것은 LLVM 일뿐 만 아니라 Visual Studio Express Edition은 또 다른 실행 가능한 무료 대안입니다 (질문은 std::threadVS2012 EE에서 지원되는 Windows에 관한 것입니다)
— MSalters
1
너무 나쁜 VS2012는 std :: thread를 완벽하게 지원하지 않습니다 (예 : thread_local변수 없음 )
— alrikai
현대에 이것이 전혀 바뀌 었습니까?
— Hashim
29

GCC의 인기와 유용성은 의심의 여지가 없습니다.

https://stackoverflow.com/questions/12210102/does-gcc-4-7-1-support-threads mingw build from http://code.google.com/p/mingw-builds/downloads/list 에서 스레드 지원 .

그러나 중요한 고려 사항은 라이센스입니다.

FreeBSD는 GPL과 불안한 관계를 가지고 있습니다. BSD 라이센스 옹호자들은 진정한 자유 소프트웨어에는 사용 제한이 없다고 생각합니다. GPL 지지자들은 소프트웨어의 자유를 보호하기 위해 제한이 필요하며, 특히 자유 소프트웨어로부터 자유 소프트웨어가 아닌 소프트웨어를 만드는 능력은 자유가 아니라 부당한 형태의 힘이라고 생각합니다. 가능한 경우 FreeBSD 프로젝트는 GPL 사용을 피하려고합니다 (자세한 내용은 https://unix.stackexchange.com/questions/49906/why-is-freebsd-deprecating-gcc-in-favor-of-clang- llvm )

다른 중요한 고려 사항

에서 http://clang.llvm.org/comparison.html#gcc

  • Clang AST와 디자인은 관련된 언어에 익숙하고 컴파일러 작동 방식에 대한 기본 지식을 가진 사람이라면 누구나 쉽게 이해할 수 있습니다. GCC에는 매우 오래된 코드베이스가있어 새로운 개발자에게 가파른 학습 곡선을 제공합니다.
  • Clang은 처음부터 API로 설계되어 소스 분석 도구, 리팩토링, IDE 등을 비롯하여 코드 생성에 재사용 할 수 있습니다. GCC는 모 놀리 식 정적 컴파일러로 구축되어 API로 사용하고 다른 도구에 통합하기가 매우 어렵습니다. 또한 역사적인 디자인과 현재 정책으로 인해 프런트 엔드를 나머지 컴파일러에서 분리하기가 어렵습니다.
  • 다양한 GCC 설계 결정으로 인해 재사용이 매우 어렵습니다. 빌드 시스템을 수정하기 어렵고 여러 대상을 하나의 이진으로 연결할 수 없으며 여러 프런트 엔드를 하나의 이진으로 연결할 수 없으며 사용자 정의 가비지 수집기, 전역 변수를 광범위하게 사용하고 재진입 또는 다중 판독 가능하지 않습니다. Clang에는 이러한 문제가 없습니다.
  • clang은 모든 토큰에 대해 작성된 위치 및 매크로와 관련된 경우 궁극적으로 확장 된 위치에 대한 정보를 추적합니다. GCC는 소스 코드를 구문 분석 할 때 매크로 인스턴스화에 대한 정보를 추적하지 않습니다. 따라서 소스 재 작성 도구 (예 : 리팩토링)가 (심지어 단순한) 매크로가있는 상태에서 작동하기가 매우 어렵습니다.
  • Clang은 GCC처럼 코드를 구문 분석 할 때 암시 적으로 코드를 단순화하지 않습니다. 이렇게하면 소스 분석 도구에 많은 문제가 발생합니다. 간단한 예로, 소스 코드에 "xx"를 쓰면 GCC AST에 '0'이 포함되고 'x'는 언급되지 않습니다. 'x'의 이름을 바꾸려는 리팩토링 도구에는 매우 나쁩니다.
  • Clang은 AST를 디스크로 직렬화하고 다른 프로그램으로 다시 읽을 수있어 전체 프로그램 분석에 유용합니다. GCC는 이것을 가지고 있지 않습니다. GCC의 PCH 메커니즘 (컴파일러 메모리 이미지의 덤프 일뿐)은 관련이 있지만 아키텍처 적으로 덤프를 생성 한 것과 동일한 실행 파일로 덤프를 다시 읽을 수만 있습니다 (구조화 된 형식이 아님).
  • Clang은 GCC보다 훨씬 빠르며 훨씬 적은 메모리를 사용합니다.
  • Clang은 매우 명확하고 간결한 진단 (오류 및 경고 메시지)을 제공하고 표현 진단을 지원합니다. GCC의 경고는 때때로 용인 될 수 있지만 종종 혼란스럽고 표현 진단을 지원하지 않습니다. Clang은 또한 진단에서 typedef를 일관되게 유지하여 매크로 확장 및 기타 여러 기능을 보여줍니다.
  • Clang은 LLVM을 백엔드로 사용하여 중간 코드에 대한 바이트 코드 표현 지원, 플러그 가능 옵티 마이저, 링크 시간 최적화 지원, JIT (Just-In-Time) 컴파일, 여러 코드 생성기에서의 링크 기능 등 여러 기능을 상속합니다. .
  • C ++에 대한 Clang의 지원은 여러 가지면에서 GCC보다 더 적합합니다 (예 : 적합한 2 단계 이름 조회).

에서 http://www.linuxquestions.org/questions/slackware-14/gcc-vs-llvm-931034/

  • llvm / clang의 장점은 모듈 식 디자인으로,
    예를 들어 점점 더 중요 해지는 정적 코드 분석 도구 (예 : 정적 코드 분석 도구)를 작성하기 위해 인터페이스되고 사용될 수 있습니다.

에서 http://clang.debian.net/

  • clang은 이제 프로덕션 용 소프트웨어 (C, C ++ 또는 Objective-C 용)를 구축 할 준비가되었습니다. 이 컴파일러는 gcc와 동일한 레거시를 전달하지 않으면 서 gcc 제품군보다 더 많은 경고와 흥미로운 오류를 제공합니다.
— Md Mahbubur Rahman
소스
2
최고의 답변!
— Vorac
3
최신 정보 : GCC는 4.8 이후 매크로 확장을 추적하며,이 옵션 -ftrack-macro-expansion은 현재 기본적으로 활성화되어 있습니다 :)
— Morwenn
구문 분석시 소스 트리를 단순화하려는 또 다른 문제점은 약간의 구문이 코드를 생성하지 않지만 허용되는 최적화에 영향을 미치는 상황이 많이 있다는 것 입니다. 만약 foo및 moo필드가 둘 다 다른 구조 형식에 대한 포인터입니다 bar작성 초기 시퀀스의 일부로서, *&foo->bar독서 *&moo->bar(가) 하나의 액세스에 사용되는 유일한 효과적인 유형의 유형이기 때문에, 쓰기를보고 읽을 초래한다은 bar. GCC는, 그러나, 밖으로 필터링하는 것 *&때문에 유형 스며 foo과 moo...
— supercat
... 표준 주소에서 찾을 수있는 것으로 정당화되지 않은 주소 연산자를 통해.
— supercat
11

시간이 많이 걸리는 이유는 헤더를 구축 할 수있는 견고한 기반을 얻기 위해 많은 노력이 필요하기 때문입니다. mingw-w64가 보인 것처럼 보이는 방법은 Windows에서 견고한 pthreads와 같은 라이브러리를 작성하는 것입니다. Windows API의 기본 스레딩에 대한 종속성을 도입하는 것보다 업스트림 심술이 적습니다.

mingw-w64 <thread>는 자신의 winpthreads라이브러리 위에 구현 하고 다른 C ++ 11 헤더를 구현 합니다. 이것은 Mingw-builds와 rubenvb의 mingw-w64 툴체인 배포판에서 테스트 할 수 있어야합니다. 기본 Windows GCC 작업에 대한 대부분의 작업이 수행되는 위치를 추적하려면 mingw-w64 메일 링리스트를 따르는 것이 좋습니다.

Qt 프로젝트에는 현재 권장 사항을 자세히 설명하는 wiki 페이지와 Windows의 GCC 툴체인에 대한 개요가 있습니다. 이 Qt 프로젝트 wiki 페이지를 참조하십시오 .

— 라스 비클 룬드
소스
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.