C 2011에서 가변 길이 배열을 선택적으로 만든 이유는 무엇입니까?


12

CLA가 C 1999에 도입되었을 때, VLA가 언어에 큰 혁신이라고 생각했습니다. 그러나 C 2011에서 옵션으로 선택되었다는 사실을 알게 된 후 상태가 어떻게 바뀌 었는지 궁금해하며 실제로 기능이 더 이상 사용되지 않는 경우가 있습니다. 그렇다면, 동적으로 크기가 조정 된 데이터를 대체 할 것으로 간주되는 자동 관리 개념과 동등한 개념이 있습니까?

C 2011 근거 문서를 찾으려고했지만 아직 게시되지 않은 것 같습니다.


입양 부족?
Ryan Reich

@RyanReich : 아마도 벤더의 저항은 무엇일까요?
jxh

답변:


8

"일부 작은 실수는 VLA없이 C11을 준수 할 수 있어야하므로 선택 사항이어야 함"에서 "처음에는 실수"까지 다양한 범례를 들었습니다. 그래도 나는 이것에 대한 진실하고 확실한 대답을 한 번도 얻지 못했습니다. 궁극적으로, 나는 (내 오래된 검색이 진행되는 한) (공식이 있다고 가정하고) 가정 된 적이 없기 때문에 누군가가 실제로 하나를 가지고 있다고 생각하지 않습니다.


국제 표준-프로그래밍 언어-C 5.10 (2003)의 이론적 근거 4 장 (13 페이지)부터

표준은 수용하는 프로그램과 관련하여 적합한 구현을 정의함으로써, 적합한 구현의 일부로서 광범위한 확장을위한 문을 열어 둡니다. 표준 호스팅 준수 및 독립 실행 형 구현을 모두 정의함으로써 표준은 운영 체제 및 ROM 기반 응용 프로그램뿐만 아니라보다 일반적인 호스팅 응용 프로그램과 같은 프로그램을 작성하는 데 C를 사용한다는 것을 인식합니다. 이 두 가지 수준의 계획 외에도 C89위원회는 너무 많은 수준이 표준의 효과를 희석한다고 강하게 느끼기 때문에 C에 대한 추가 하위 설정이 정의되지 않았습니다 .

강조합니다. 이 결정은 자신의 이론적 근거에 위배됩니다. 그러나 또 다른 것은 선택 사항이었습니다. 이제 __STDC_NO_VLA__VLA 지원 을 받거나받을 수 있습니다 . 매우 이상한 결정입니다.


@jxh조차 보지 못했습니다. 지적 해 주셔서 감사합니다. 더 명확하고 덜 모호한 표현으로 변경되었습니다. 일부 상황에서는 주제를 동기와 목표의 동의어로 보았지만 예술적 시나리오에서만 일반적이라고 생각합니다.
Bernardo Sulzbach

두 가지 수준의 체계 만 갖는 문제는 광범위하지만 보편적으로 지원되지 않는 유용한 기능과 보장이 많으며 일부 유형의 프로그램이 가능한 것보다 훨씬 효율적으로 작성 될 수 있다는 것입니다. 이러한 기능의 가용성에 대한 표준 테스트 수단이 없기 때문에 많은 분야의 실질적인 프로그램의 대다수가 표준에 포함 된 것 이상의 보증을 사용할 필요가없는 경우 상당한 부분이 필요하며 결정하기가 어렵습니다. 특정 여부에 대한 확실성
supercat

... 프로그램은 특정 구현에서 작동합니다. 다양한 옵션 기능을 정의하고 지원을 거부하거나 거부 할 수있는 구현을 보장하려면 (컴파일을 거부하여) 요구 사항을 올바르게 지정하는 프로그램이 플랫폼에서 올바르게 작동하는지 테스트하는 좋은 표준 방법을 사용할 수 있습니다. 그것을 구축합니다. 그것이 구축되면 작동합니다. 그렇지 않다면 분명히 그렇지 않습니다. 성공적인 빌드가 성공적인 운영을 보장 할 수있는 프로그램의 일부를 늘리는 것은 ...
supercat

... 표준에서 요구하는 것 이상의 기능과 보장을 얻지 못하는 소수의 프로그램을 처리 할 수있는 컴파일러의 수를 최대화하는 것보다 훨씬 더 가치가있을 것입니다.
supercat

4

공개위원회 문서 (특히 N1395 ) 에서 결정할 수있는 한, VLA (복잡한 산술 및 스레딩과 함께)를 선택적으로 만드는 주요 이유 중 하나는 소형 임베디드 프로세서에 적합한 C 컴파일러를 만들 수있게하는 것이 었습니다.

추세는 임베디드 시스템을 대상으로하는 컴파일러 공급 업체가 고객이 요구하지 않은 큰 기능의 도입으로 인해 C90 표준을 유지하고 있다는 것이 었습니다.


많은 경우에, "제외하고 싶다"고했다. 이러한 기능을 활성화 할 때 RAM 풋 프린트 변경을 살펴보면 일부 사람들이 원하지 않는 이유가 분명해집니다. 프로세서 비용을 두 배로 늘릴 수 있으며 이는 시스템에서 가장 비싼 부분이 될 수 있습니다.
Ⴖ uі

1
@JerryCoffin : 예. 그러나 sizeof ()가 실제로 배열에서 사용될 때만 코드가 생성됩니다. 컴파일러는 올바른 코드를 생성 할 수 있도록 정보를 추적해야하지만 해당 정보는 VLA의 메모리에 표시 될 필요는 없습니다.
jxh

2
@jxh : 원래 계획 한대로 독립 실행 형 및 호스팅 된 구현은 동일한 핵심 언어를 사용했습니다. 차이점은 라이브러리로 제한되었습니다. VLA의 경우 언어 자체에는 차이가 있으며 (적어도 일부 공급 업체는 느꼈던) 소규모 임베디드 시스템에는 적합하지 않다고 생각합니다. 크기를 포함시키는 한 : 아니오, 절대적으로 절대 필요한 것은 아니지만 가장 쉬운 방법 일 수 있습니다 (예 : 크기에 대한 몇 바이트의 스토리지는 크기를 계산하기 위해 많은 바이트의 코드를 피할 수 있습니다).
Jerry Coffin

1
@ supercat : C 라이브러리 기능을 선택하는 체리의 논리를 볼 수 있지만 언어 기능을 "선택적"으로 만드는 것은 다중 플랫폼 C 코드를 작성하려는 사람에게는 결정적으로 도움이되지 않는 것 같습니다. 그것은 사용 C가 쉽게 다른 컴파일러와 다른 하드웨어 플랫폼에 목표로 삼을 수있는 프로그래밍 금속 시스템에 가까운에 대한 분명한 선택이었다고 할 수 있습니다. 이제는 그렇게 분명하지 않습니다.
jxh

1
@supercat : 스택 폭격은 VLA에 고유하지 않습니다. 비정상적으로 큰 자동 객체 또는 제한되지 않은 함수 호출 스택에는 비슷한 문제가 있습니다. 표준에서 이러한 경우의 장애를 감지하는 수단을 정의하면 VLA에서도 작동 할 수 있습니다. 선택적인 측면에서, 여러 공급 업체의 컴파일러를 사용하여 여러 플랫폼에서 작업해야하는 새 프로젝트의 새 C 코드에서 새 C 기능을 사용하기가 더 어려워집니다.
jxh
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.