새로운 C 프로젝트는 오래된 C 표준 (> 20 세, 즉 C89)을 언제 대상으로해야합니까?

때때로 나는 매우 오래된 C 표준 (일반적으로 C89)을 목표로하는 비교적 새로운 주요 오픈 소스 C 프로젝트를 본다. 예가 체계화되어 있습니다. 이 프로젝트에는 현명한 사람들이 있기 때문에 내가 알지 못하는이 결정의 근거가 될 수 있습니다. 의심의 여지가 있지만, 근거는 "더 오래되고 표준화 된 것이 항상 더 휴대 가능하고 더 좋다"는 것처럼 보입니다. 논리적 인 결론은 FORTRAN이 C보다 낫고 COBOL이 FORTRAN보다 낫다는 논리적 인 결론 일 것입니다.

새로운 C 프로젝트가 매우 오래된 C 표준을 목표로하는 것이 언제, 왜 정당한가?

사용자 시스템이 C 컴파일러를 절대 업데이트해서는 안되지만 새로운 소프트웨어를 자유롭게 설치할 수있는 시나리오를 상상할 수 없습니다. 예를 들어 데비안의 LTS 버전에는 C99와 일부 C11을 지원하는 gcc 4.6 패키지가 있습니다. 나는 이상한 시나리오가 존재해야하며 systemd와 같은 프로그램이 그러한 사용자를 대상으로하고 있다고 생각합니다.

내가 상상할 수있는 가장 합리적인 사용 사례는 사용자가 C89 컴파일러 만 사용할 수 있는 이국적인 아키텍처를 기대 하지만 새로운 소프트웨어를 완전히 설치하려는 경우입니다. 명령어 세트 아키텍처의 다양성이 줄어든다는 것은 과도하게 가정적인 시나리오처럼 보이지만 확실하지 않습니다.

... "더 오래되고 표준화 된 것은 항상 더 휴대 성이 뛰어나고 더 낫습니다".

그 진술은 더 나아질 때 말도 안되게되었고 , 그것은 완전히 주관적이다. 마지막 모임에서 사람들의 절반이 사용했기 때문에 프로젝트의 언어와 표준을 선택하지 않았습니다. 해결하려는 문제를 연구하고 이해하고 그것이 업무에 적합한 도구라고 판단했기 때문에 선택합니다.

일반적으로 표준의 경우, 이식성을 위해 일부 프로젝트에 대해 사례를 만들어야하는 경우가 있으며, 이전 버전을 선택하면 이점이 있습니다. 이것은 다른 사람의 목적을위한 수단 인 라이브러리를 제품으로 개발할 때 특히 그렇습니다. 마지막으로하고 싶은 일은 아직 만난 적이없는 고객이 사용할 수없는 컴파일러가 필요하기 때문에 팔 수없는 것을 작성하는 것입니다. 임베드 된 세계에 대한 필립 켄달의 의견은 주목할 만하다. 사람들은 여전히 ​​안정적이고 안정적인 플랫폼을 위해 새로운 코드를 작성해야하거나 추가 기능의 이점을 얻지 않고 최신 컴파일러를 얻지 못하는 플랫폼을 사용하기 때문에 많은 문제가 발생합니다. 프로젝트의 모든 측면을 완벽하게 제어 할 수 있습니다.

특히 C의 경우 최신 표준을 준수하는 것과 교환하여 얻는 것에 대한 의문이 있습니다. K & R에서 C89 로의 전환은 이전 코드를 정리하는 데 많은 노력이 필요했지만 궁극적으로 많은 성과를 거둔 큰 변화였습니다. C99 와 C11 의 변화비교가 적고 최근에 개발 된 CI 발생의 대부분은 새로운 기능을 사용하지 않기 때문에 여전히 C89를 통과합니다. 한 줄 주석을 지원하고 기본 부울 데이터 형식이 있으며 가변 길이 배열을 수행 할 수 있기 때문에 C89보다 C99를 수정하는 것이 옳은 것이라고 주장하기는 어렵습니다. 주석과 부울은 추악한 해결 방법이 있으며 VLA는 약간 덜 효율적인 다른 방식으로 처리 할 수 ​​있습니다. C11은 VLA를 선택 사항으로 강등했으며, 이는 구현에 눈에 띄게 나타나는 경우 이전 C99를 선택하는 데 정당화 될 수 있습니다.

광범위한 플랫폼에서 이식성이 중요한 경우. 여기에는 사용되지 않는 플랫폼 및 미니멀리스트 컴파일러 만 사용할 수있는 많은 임베디드 프로세서가 포함될 수 있습니다.

C89가 "가장 낮은 공통 분모"라는 의미도 있습니다. 제대로 표준화 된 최초의 버전이었으며 오늘날 사용중인 거의 모든 컴파일러가 C89의 일부 슈퍼 세트를 구현한다고 가정 할 수 있습니다.

C 모드에서 Microsoft Visual C ++는 C ++ 표준을 유지하는 것이 비교적 좋았지 만 C89에서 오랫동안 C89에 머물러 있다는 문제도 있습니다. 따라서 최신 Visual Studio를 사용하지 않는 사람은 모두 C89로 제한 될 수 있습니다.

필자는 주로 Microsoft 때문에 의사 C89 코드 (완전 C99 호환 아님)를 작성하고 있음을 인정해야합니다. 나는 Windows 측의 MSVC에 크게 의존하고 있으며 C99와 완전히 호환되지 않고 대신 C ++ 17 이상에 중점을 둡니다.

그 외에도 많은 플러그인 개발자가 플러그인 개발을 위해 MSVC를 사용하고 일부는 MSVC 2010을 사용하는 C SDK를 개발 중입니다. 그래서 여전히 인기가 많은 컴파일러가 플랫폼에서 널리 사용되지 않습니다. 아직 C99를 완전히 구현하지 않은 Windows exotic). 가장 큰 범위의 컴파일러 (C ++이 아닌 C로 작성된 주요 이유 중 하나)와의 광범위한 호환성을 목표로 할 때 여전히 많은 사람들이 사용하고 있습니다 (적어도 MSVC). C 지원에 관해서. C99 이후 거의 수십 년이 지났으며 MSVC AFAIK와 같이 VLA가 아직 없습니다 (MSVC 2017에서는 아직 확인하지 않았지만 C에 대한 Microsoft의 입장에서는 C99와 훨씬 더 호환됩니다) .

따라서 불행히도 여전히 완전히 C99 호환되지 않는 우수한 옵티 마이저 및 디버거로 실제로 매우 우수한 새로운 컴파일러가 있습니다. 물론 이것이 아니라면 C11을 뛰어 넘을 것입니다.

플러그인 및 MSVC와의 소스 호환성 외에도 다른 언어와의 상호 운용성이 있습니다. 일부 다른 언어는 FFI를 통해 SDK를 사용하며 일부 FFI는 C89 만 이해합니다. dylib에서 함수를 가져올 때 이해하지 못 bool하거나 _Bool간단한 예일 수 있습니다 int.

그렇습니다. 이식성에 대한 주장은 사실이지만 문제는 실제로 C89 컴파일러 만 사용할 수 있지만 새로운 소프트웨어 배포판을 컴파일하는 비가 설적 시스템이 있는지에 대한 것입니다. 즉, 새 C 프로젝트를 시작하는 경우 C89를 준수하면 잠재 사용자 수가 증가 할 수 있는지 어떻게 알 수 있습니까?

방금이 하나이지만 에코 Blrfl가 발생했습니다 .C99와 C11을 사용하면 생산성이 크게 향상되지 않지만 사람들이 MSVC에서 플러그인을 작성할 수있는 기능을 잃는 것은 막대한 비용이 될 수 있습니다 (특히 내가 일하는 제품 이후) on은 Windows 측면에서 시장 점유율이 가장 높으며 평균 사용자는 종종 많은 타사 플러그인을 구매하고 다운로드합니다. 내가 작업하는 제품의 종류는 프로그래머 / 스크립트 작성자를위한 개발 환경과 아티스트를위한 사용자 엔드 제품 사이의 거의 절반에 지나지 않습니다. 많은 사람들이 새로운 기능을 허용하고 새로운 기능을 허용하기 위해 그 위에 새로운 것을 개발하기를 원하기 때문입니다. 친절한 사람들은 아직 보지 못했습니다. 제 경우에는 실제로 SDK에 대해 C89를 선호하는 것은 매우 간단한 결정이었습니다.

주변 컴파일러를 살펴보고 대상 인구 통계를 파악하려고한다고 가정합니다. Windows 용 플러그인 아키텍처를 개발하지 않거나 임베디드 프로그래밍을 수행하지 않거나 가장 광범위한 컴파일러 및 언어에서 사용할 수있는 소프트웨어 개발 키트를 작성하려는 경우 C99 +에 쉽게 도달 할 수 있습니다. 떨어져. 또한 C99 양식을 얼마나 많이 생산성 향상시킬 수 있는지 생각해보십시오. 데이터가 맞을 때 스택을 사용하고 그렇지 않으면 힙을 사용할 수있는 간단한 방법에 의존하기 때문에 VLA와 같은 이점은별로 없습니다.

그러나 MSVC와 같은 인기있는 컴파일러에서 다른 언어의 FFI에 이르기까지 많은 것들이 있습니다. 다른 언어에서는 dylib에서 직접 C 함수를 가져오고 호출 할 수 있다는 의미에서 시원하지만 조금 뒤에있을 수도 있습니다. 타임스. 따라서 도메인에 따라 단순히 오래된 미학을 선호하고 어떤 종류의 미학을 선호하는 것보다 훨씬 더 실용적인 비즈니스 사항이 있습니다.