2011 년 C 프로그래밍 [닫기]

여러 달 전에 저는 주로 광범위한 OS (Linux, * BSD, HPUX, VMS ...)를 지원하는 POP3 서버를 유지하면서 C 코드를 잘라 냈습니다.

C 기술을 녹여 내고 간단한 FORTH를 C로 코딩하여 언어 구현에 대해 조금 배울 계획입니다.

하지만 2000 년 이래로 C 세계에서 어떻게 변화했는지 궁금합니다. C를 생각할 때, 저는 ...

1. comp.lang.c
2. 가능한 경우 ANSI C (그러나 C99로서 C89는 널리 지원되지 않음)
3. gcc -Wall -ansi -pedantic 정적 분석 도구 대신
4. 이맥스
5. 태그
6. Autoconf + make (VMS, HP-UX 등의 장점에 대해서는 포인트 2 참조)

지난 11 년 동안 C 로 글을 쓰는 사람이 몇 년 동안 어떤 변화가 있었는지 알려줄 수 있습니까?

(다른 소식으로, 거룩한 쓰레기, 나는 10 년 이상 이것을 해왔다).

"10 년 전과 같은 C 프로그래밍은 무엇입니까?"와 같은 시간을 거슬러 생각하기는 정말 어렵지만, 내가 다르게하고있는 일에 대해 이야기 할 수 있습니다.

• 일반적으로 comp.lang.c에서 Peter Seebach와 같은 누군가를 소환하여 언어와 관련이 있다고 생각되는 구피 버그에 대한 도움을받을 수 있지만, 모든 C 프로그래밍 질문에 스택 오버플로에 대한 예외적 인 답변이있는 것은 아닙니다.

• 정적 분석은 여전히 ​​고통 스럽습니다. Splint (적어도 내가 아는 한)는 C99를 잘 처리하지 못하므로 적용 범위 그래프는 여전히 약간의 고통입니다. GCC 경고는 사용자가 요청한 사람에 따라 다르기 때문에 따옴표로 상당히 개선되었습니다.

• Valgrind는 모든 메모리 오류 검사기의 성자이며 일반적으로 정적 분석 도구로는 찾을 수없는 코드의 문제를 가리 킵니다. 100 % 완벽하지는 않지만 그럴 수는 없다고 생각합니다. 나는 요즘 GDB를 거의 다루지 않아도된다. 개인적으로는 아무것도 아니다. Valgrind 대산 괴 도구는 정말 멋진 힙 프로파일 러입니다.

• GCC에는 항상 새로운 확장 기능이 있으며 그중 일부는 미묘 하므로 이식성이 큰 문제라면 페달을 타는 것이 좋습니다. 초보자 / 녹슨 프로그래머에게는 확장 기능을 '숨겨진'언어 기능과 혼동하기 쉽습니다.

• CCAN이 나타 났으며 (CPAN을 생각하지만 C를 생각하십시오) 이륙하기 시작했습니다. 멋진 테스트 도구 인 TAP의 적용을 포함하여 유용한 보석이 많이 있습니다. C의 문자열은 여전히 ​​흡연하지만 라이브러리를 처리하는 데 도움이되는 라이브러리의 수와 품질은 지난 10 년 동안 분명히 증가했습니다.

• SCons와 CMake는 빌드 구성에 대한 인기가 높아지고 있습니다. Autoconf / Automake / Libtool은 여전히 ​​널리 사용되지만 많은 사람들이 M4에 의해 너무 제한적이라고 생각합니다. 그래도 사용하려는 시스템이라면 Autoconf 매크로 아카이브가 여전히 유효합니다.

• 오늘날에는 더 많은 편집자가 있습니다. 나는 C와 함께 일할 때 방해가되지 않는 "IDE"를 아직 찾지 못했지만, 아마도 나는 단순함을 위해 낡고 비참한 Sanka 마시는 전도자이기 때문일 것이다.

그러나 전반적으로 (C가가는 한) 삶이 10 년 전과 크게 다르다고는 말할 수 없습니다. 그러나 여러면에서 실제로는 조금 더 쉽습니다. 그러나 경험보다 도구를 사용하기는 어렵습니다.

glib 는 "새로운 표준 라이브러리"일 수 있습니다. 플랫폼 독립적 스레딩 및 네트워킹, 컨테이너 데이터 구조 등과 같이 표준에서 벗어난 많은 느낌을 제공합니다. 물론 모든 곳에 적용 할 수는 없지만 사용할 수 있으면 많은 시간이 절약됩니다.

1. StackOverflow ;)
2. 저는 주로 Microchip의 마이크로 컨트롤러 용 펌웨어를 작성하는 데 C를 사용하고, 컴파일러는 GCC 기반이므로 C99를 사용합니다 (그러나 추가 기능이 필요하지 않습니다. 주로 스택의 루프 변수 및 동적 배열 범위를 제한하는 것입니다). 파이썬 확장을 작성할 때 누군가가 MSVC로 컴파일 해야하는 경우를 대비하여 C89를 고수합니다. 나는 다른 사람들이 무엇을 사용하는지 모른다.
3. 부목 (C89, C99하지에 작품), 그리고 연타의 정적 분석기 - 둘 다 매크로 무거운 펌웨어 코드에 질식 때문에,하지만, 나는이없는 대규모 그들과 경험의 양을. 실제로, LLVM의 많은 것들이 C 괴짜에게는 꽤 흥미 롭습니다.
4. 좋아, 이것은 단지 거룩한 전쟁 미끼입니다. : P
5. Ctags를 사용한 적이 없지만 Doxygen의 일부입니다.
6. 신 나는 Autoconf를 싫어한다. 나는 너무 싫어. 나는 처음부터 Autoconf ball-of-mud를 만들지 못했습니다. 프로젝트에 이미 프로젝트가 있으면 이미 존재하는 모든 것을 헛소리하는 것입니다. 내가 뭔가 새로운 것을 쓰고 있다면, 나는 고집을 부리고 대안을 찾는다. 비록 내가 고집하고있는 것을 발견하면 저주를 받는다. 마지막으로이주기를 거쳤을 때 SCons를 사용했는데 다시 사용할 수 있습니다.

2)와 3)이 변경되었습니다. C99는 주류이며 C90은 점점 더 쓸모 없어지고 있습니다. gcc -Wall -std=c99 -pedantic.

그 외에도 다른 답변에서 아직 다루지 않은 가장 주목할만한 두 가지 변경 사항은 다음과 같습니다.

• C11. ISO 9899 : 2011.
• MISRA-C : 2004.

C 프로그래밍 언어는 가장 최근의 연구 / 조사에서 Dobb 박사의 일지에있는 상위 2 개 또는 3 개의 프로그래밍 언어로 만들어졌습니다.

언어 구현과 관련하여 C는 Go (golang.org)라는 Google에 구축중인 새로운 언어를 구현하는 데 사용됩니다.

최근 몇 년 동안 C의 유즈넷 그룹을 따르지 않았습니다. Freenode IRC 채널을 자주 방문합니다. 그것은 많은 사람들에 의해 활발하고 빈번합니다.

새로운 프로그램이 C로 작성되고 있지만, 1999 년과 같이 올해 들어 왔던 것처럼 홍보를 얻지 못했습니다.

이것들은 마음의 맨 위에 오는 것입니다. 더 많은 것이있을 수 있지만 프로그래머 모자와 연락을 유지하기를 바랍니다.하지만 모자의 C 모델을 자주 사용하지는 않았을 것입니다. :)

C99 지원이 생각보다 낫다고 생각합니다. Visual Studio는 그것을 지원하지 않지만, 내가 생각할 수있는 다른 모든 컴파일러는 그것을 지원합니다 (아마도 여기 저기 생략). VS와의 호환성이 필요하지 않은 경우 C89 IMHO보다 작성하는 것이 훨씬 즐겁기 때문에 C99를 사용한다고 말하고 싶습니다.