C99 Standard에서 추가된 것

[JongAm]

보통 C++은 약 96년 이후에 추가된 표준 사항을 많이 쓰고 있는 형편입니다. 물론 그 추가 사항이 꼭 필요한가에 대한 의견이 분분하긴 하지만 말입니다.

그런데 C는 그렇지 않죠. 예전의 표준을 그대로 쓰고 있습니다.
그런데 오늘 Objective-C를 보다가 이상한 점을 발견해서 C의 표준을 살펴보았는데.. 이런 99년도에 새로운 표준이 채택되었더군요.
많이들 쓰지는 않고 있고, 호환성 때문에라도 이 새로운 표준사항을 피하는 입장이고, GNU C에서도 표준의 하나로 설명하기 보다는 GNU C의 extension이라는 식으로 설명하고 있습니다.
아무래도 C++에 비해서 C는 바꾸지 말자 쪽의 묵시적인 행동이 더 많은 것 같습니다.

암튼.. 이렇게 바뀐 C때문에 Objective-C에서 허용하는 것들이 있습니다.

C99

After the ANSI standardization process, the C language specification remained relatively static for some time, whereas C++ continued to evolve. (Normative Amendment 1 created a new version of the C language in 1995, but this version is rarely acknowledged.) However, the standard underwent revision in the late 1990s, leading to the publication of ISO 9899:1999 in 1999. This standard is commonly referred to as "C99". It was adopted as an ANSI standard in March 2000.

The new features in C99 include:

- inline functions

- variables can be declared anywhere (as in C++), rather than only after another declaration or the start of a compound statement

- several new data types, including long long int (to reduce the pain of the looming 32-bit to 64-bit transition), an explicit boolean data type, and a complex type representing complex numbers

- variable-length arrays

- support for one-line comments beginning with //, like in BCPL or C++, and which many C compilers have previously supported as an extension

- several new library functions, such as snprintf()

- several new header files, such as stdint.h

Interest in supporting the new C99 features appears to be mixed. Whereas GCC and several other compilers now support most of the new features of C99, the compilers maintained by Microsoft and Borland do not, and these two companies do not seem to be interested in adding such support.

이외에도 복소수 표현이 가능한 것도 있습니다.
근데 variable length array가 된다는 것은 충격이네요.

즉

int n = 10;

float test[n];

이게 된다는 말입니다. run time시에....
malloc의 상당수를 없앨 수 있겠습니다만, 과연 이게 무슨 의미일지 모르겠습니다. 쉬운 동적 메모리 비스무레는 되겠지만, C의 장점이 빠르다인데.. 이런 것을 넣어 버리다니... 어차피 malloc쓸꺼, 더 쉽게 쓰자라는 취지로는 이해가 됩니다만..
아마 그래서인지 그다지 이 C99을 잘 받아들이지 않는지도 모르겠습니다.

암튼.. Objective-C에서는 이런 것을 다 받아 들이고 있으니, 알아두면 좋겠죠.

[han9kin]

[taewon]

[JongAm]

그게.. 얼른 얼른 짜서 테스트해 볼 때는 좋은데, 다 짜고 나서 뭔가 정리를 할때는 좋지 않죠.

그래서 전 대신에 에디터가 한 View를 둘로 나눌 수 있는 것을 좋아합니다
위의 view에는 선언부나 클래스를 볼 수있게 해 놓고, 아래 view는 실지로 코딩하고 있는 부분을 보고..

[chunsj]

[JongAm]

말씀마따나 stack을 이용한다면 더 빠르긴 할겁니다. malloc을 이용하는 것보다..
그런데.. 언어의 feature를 늘리면.. 더군다나.. 처리하는 것이 좀 runtime시에 결정이 되어주어야 하니까.. 그런 면에서 느려지지 않을까 싶습니다.
stack을 써서 빨라지는 것과 그런 구조로 인해서 느려지는것이 상쇄되면 어떨까 모르겠습니다.

[[..']]

런타임시에 배열 크기를 맘대로 줄였다 늘였다 하는게 아니라면

1. 소스에 배열 크기가 상수로 지정되면 옛날처럼 그냥 스택에다 넣고
2. 소스에 배열 크기가 변수로 지정되면 힙에다 만들고

하면 컴파일러를 수정하는 것이 문제이지 생성된 코드는 별 차이 없지 않나요?

malloc+포인터 연산으로 할일을 깔끔한 신텍스로 처리할 수 있으니 전 좋아보이는데요.
이른마 'syntactic sugar'로 생각됩니다만.
_________________
[..'] Let them talk. Just leave me alone while I'm coding.

[JongAm]

[chunsj]