C 언어 ¶
- C 는 1972년 벨 연구소에서 데니스 리치(Dennis Ritchie)에 의해서 개발되었다. 이 언어는 우연히 개발된 것이 아니라 많은 컴퓨터에서 사용되는 유닉스 운영 체계를 제작하는데 사용한다는 특별한 목적을 가지고 개발되었다. 즉, C 언어는 처음부터 프로그래머들이 작업을 완료하는데 유용하게 사용할 수 있도록 고안되었다. 이처럼 C언어는 뛰어난 기능과 융통성을 제공해 주었으므로, 오래지 않아 벨 연구소 뿐만 아니라 다른 여러 곳으로 빠르게 보급되었다.
- ISO - C 언의의 표준
많은 프로그래머들은 모든 프로그램을 작성하기 위해서 C 언어를 사용하기 시작했다. 그러나 서로 다른 곳에서 C 언어를 사용하는 프로그래머들은 C 언어를 약간씩 수정하여 각자 자신만의 독특한 환경을 구성하기 시작했고, 결과적으로 C 언어로 작성된 프로그램들 간에는 미묘한 차이가 생기게 되었으며, 그로 인해 많은 프로그래머들은 다른 곳에서 작성된 프로그램을 정상적으로 실행하기 위해 다시 수정해야 하는 상황이 발생했다. 이러한 문제점을 해결하기 위해서 국제 표준협회(ISO)의 지휘아래 미국의 국가 표준 협회(ANSI : American National Standard Institute)는 C에 대한 표준을 만들기 위해서 1983년 위원회를 결성했고, ANSI 표준 C(ANSI Standard C)라고 알려진 표준안을 발표했다. 그후 ANSI C 표준을 국제 표준협회(ISO)에서 인준했다. 그리고 새로운 표준은 이제 ISO를 중심으로 만들어진다. 따라서 이제 ANSI C는 낡은 표현이다. ISO C가 새로운 표준이다. 최근의 표준은 99년도에 제정된 C99이다.
- C 언어 이름의 기원
C언어는 이전에 사용되던 B언어를 게승한다는 점에서 'C'라는 이름을 가지게 되었다. B언어도 벨 연구소의 켄 톰슨에 의해서 개발된 것이다.
윈도우 프로그래밍에선 CppLanguage을 많이 쓰던데 C는 어디에서 많이 쓰이나요? 설마 이제 C는 안쓰나요 ? --kidfriend
윈도우 프로그래밍에서도 win32 api programming은 C를 사용합니다. 유닉스/리눅스 등에선 아직도 C를 많이 사용합니다. --이호재
C를 어디에 쓰느냐는 질문은 좀 이상할 것 같습니다. 못 쓰는 곳이 없으니깐요. 과거의 어셈블리어가 적용되던 부분이 거의 C로 바뀌었고, 속도를 요구한다거나 하드웨어 관련, 임베디드(Embedded) 등에서는 C가 주축이 됩니다. 현재가 OOP의 세상인 듯 보여도 아직도 C 스타일의 설계와 코딩을 즐기며 살아가는 이들도 있습니다. 윈도우 프로그래밍이라면... 리눅스의 X용 GUI 툴킷인 GTK+도 C용 API입니다. 또 한가지 적자면, 현재의 프로그래밍은 하나의 언어로만 하는 것이 아니라고 하죠. high-level의 언어로 코딩하다가 속도를 요하는 부분이 있으면 이 부분만 C로 코딩해서 컴파일해서 모듈처럼 적재해서 사용하는 등에서도 많이 쓰입니다. 아직 C가 사라지기에는 세상이 너무 험악합니다. --하이레느
음...그렇다면 C를 사용할 때 어떤점이 C++을 사용하는 경우보다 좋은거지요? -- 초초초보kidfriend
전화기나 PDA 에서도 여전히 C를 사용하지요. --지양바이너리가 빠르고 코드가 단순하죠. 유닉스 계열이나 임베디드 시스템으로 가면 전부 C언어입니다. 언젠간 다른 언어로 넘어가야겠지만 최소한 10년안에는 씨언어가 대세일 것 같군요.-- RedPain
C를 어디에 쓰느냐는 질문은 좀 이상할 것 같습니다. 못 쓰는 곳이 없으니깐요. 과거의 어셈블리어가 적용되던 부분이 거의 C로 바뀌었고, 속도를 요구한다거나 하드웨어 관련, 임베디드(Embedded) 등에서는 C가 주축이 됩니다. 현재가 OOP의 세상인 듯 보여도 아직도 C 스타일의 설계와 코딩을 즐기며 살아가는 이들도 있습니다. 윈도우 프로그래밍이라면... 리눅스의 X용 GUI 툴킷인 GTK+도 C용 API입니다. 또 한가지 적자면, 현재의 프로그래밍은 하나의 언어로만 하는 것이 아니라고 하죠. high-level의 언어로 코딩하다가 속도를 요하는 부분이 있으면 이 부분만 C로 코딩해서 컴파일해서 모듈처럼 적재해서 사용하는 등에서도 많이 쓰입니다. 아직 C가 사라지기에는 세상이 너무 험악합니다. --하이레느
음...메트릭스 계산등에는 포트란이 더 빠르다는 이야기를 들은적이 있는데...사실인가여?--timelesstime
따지자면 C는 어셈블리(Assembly language) 코딩도 가능합니다. 뭐 그건 아니더라도 C에서는 다양한 방법의 함수 호출형태나 메모리 모델을 사용할 수 있습니다. 즉 포트란에서 되는것은 모두 C에서 가능하다고 생각되는데요? 어디까지나 제 생각이예요 --픽하튜
따지자면 C는 어셈블리(Assembly language) 코딩도 가능합니다. 뭐 그건 아니더라도 C에서는 다양한 방법의 함수 호출형태나 메모리 모델을 사용할 수 있습니다. 즉 포트란에서 되는것은 모두 C에서 가능하다고 생각되는데요? 어디까지나 제 생각이예요 --픽하튜
C언어에서 어셈블리 코딩이 가능하다는 것은 인라인 어셈블리를 말하시는 건가요? 인라인 어셈블리란 C언어의 틀안에서는 해결할 수 없는 문제를 해결하기 위해 지원되는 것이지 그것이 C언어라고 보기는 어려울 것 같군요. 그것을 C언어라고 한다면 어셈블리어가 C언어안에 포함되는 것일 테니까요. 그리고 다양한 방법의 함수 호출형태나 메모리 모델을 사용할 수 있다는 것은 어떤 말씀이신 지 궁금합니다. 조금만 자세히 설명해 주실 수는 없을까요? --RedPain
으아...다시보니 참 바보같은 질문을 했었군요. 부끄러워라... --kidfriend네 인라인 어셈블리 말한거였는데 그건 아니다란 것이었고요. 다양한 함수 호출형태란 함수를 호출할때 파라미터를 넘기는 방식등에 따라 여러 형태가 있습니다. 그것을 말한 것이고 메모리 모델 역시, 옵션에서 지정해 줄수 있는 것이지요. C는 하이레벨인 언어인 동시에 로우레벨이므로 실질적으로 어셈블리를 쓰지 않아도 왠만큼은 커버가 되는것 같습니다. --픽하튜
포트란과 C언어의 속도차이를 유발시키는 가장 큰 이유가 함수를 호출할 때 파라미터를 스택에 push했다가 pop해서 참고하는 방식 때문에 생기는 것으로 알고 있습니다. 저는 C언어라면 당연히 함수호출시 스택을 이용해 파라미터를 넘기는 줄 알았습니다. 어떤 다른 방법이있나요? ANSI C에서는 inline 함수는 지원하지 않는 것으로 알고 있습니다. 그리고 메크로를 사용하면 함수를 사용하는 척하면서 스택에 의해 생기는 오버헤드를 줄일 수 있겠지만 함수를 호출했다고 할 수는 없죠. 메모리 모델은 무엇을 말씀하시는 건 지 아직도 전혀 모르겠습니다. 스테틱한 것은 당연히 실행파일에 있다가 실행파일이 메모리에 로드되면 그 실행파일의 위치에 있는 것이고 다이나믹한 것은 결국은 시스템 콜을 써서 커널에게서 메모리 영역의 한 곳을 할당 받게 되는 것일 텐데요. 모르는 게 너무 많아 죄송합니다. ^_^;; --RedPain
저도 자세히는 몰라서 죄송합니다 ^^. 씨에서는 함수호출방식이 여러가지지만 일단 스택을다사용합니다. 그런면에선 포트란보다 느리겠군요. 제가 포트란을 써본적이 없기 때문에 잘 모르겠는데, C에서도 push,pop을 안써도 함수인척 하는방법은 있으니 결과적으로 포트란과 비교할때 그점에서 느린건 없을것같습니다. 포트란, 씨둘다 잘하시는분 답변 요망^ ^ --픽하튜
포트란은 어떤지 모르겠지만 왓컴 C컴파일러는 레지스터를 사용 하기도 합니다. 언어명세에는 파라메터는 어떤 식으로 넘겨야 한다는 건 아마도 안나와 있을 겁니다. 그건 컴파일러 구현하는 사람 맘이죠. 사실 A언어가 B언어보다 빠르다라는 것 자체가 말이 안됩니다. 언어명세만 가지고 어떤게 더 빠른지 어떻게 판단할 수 있을까요? see 가장좋은프로그래밍언어 --응주
포트란은 어떤지 모르겠지만 왓컴 C컴파일러는 레지스터를 사용 하기도 합니다. 언어명세에는 파라메터는 어떤 식으로 넘겨야 한다는 건 아마도 안나와 있을 겁니다. 그건 컴파일러 구현하는 사람 맘이죠. 사실 A언어가 B언어보다 빠르다라는 것 자체가 말이 안됩니다. 언어명세만 가지고 어떤게 더 빠른지 어떻게 판단할 수 있을까요? see 가장좋은프로그래밍언어 --응주
언어명세만으로는 어떤 언어가 빠른지 판단할수 없다는데는 동의 합니다.속도자체만을 따지면 최적화된 C도 포트란의 속도에 미치지 못하는 경우가 많습니다. 반면에 포트란을 쓰면 잃어버리는 것도 많지요 --씨엔
ISO C99에서는 (페이지의 윗쪽을 참고하세요.:-) inline 함수가 사용가능합니다. --씨엔CLanguage에서 변화비용(요구사항 변경에 따라 코드를 바꾸는데 드는 비용)을 낮출 수 있을까? 있다고 생각한다. Separation of Concerns와 Information Hiding(이에 관해서는 David Parnas의 논문들을 강력히 추천한다)을 잘 지키면 가능하다고 생각한다. 꼭 OOP를 흉내내지 않고도 모듈라 프로그래밍이 가능하다. 데이비드 핸슨의 C Interfaces and Implementaionts: Techniques for Creating Reusable Software(0201498413 )에서 많은 영감을 얻을 수 있다. --김창준
개인적인 생각이지만, 분명 C는 우수한 언어입니다. 탄탄한 구조적 언어 표현이 가능하고, 심지어는 Low-Level 단위의 간단한 표현 지원이 쉽죠. 언어적으로는 우수하다고 생각됩니다. 하지만, 역시 한계가 있다고 생각하는데, 바로 프로젝트 규모에 따른 문제점 이라고 할 수 있을까요? 규모가 커지면, 제 아무리 작게 단순하게 만들어도, 결국 복잡한 모양을 갖출 수 밖에 없고, 표현 방법에 제한적 요소가 많이 걸리게 되죠.
그 대안점으로 나온것이 CppLanguage로 객체지향적 방법을 택했다고 생각하거든요. 뭐 그 외에 재사용이나 기타 코드의 생산적 요소등이 결점처럼 부각되지만, 잘 되돌아 보면 C++도 그 문제 100% 해결은 안된다고 생각되네요. 어떤 언어가 우수하다고 판단하기 앞서 용도에 따라 그 효용적 가치를 생각해 결정을 해야 할듯. 편중적 언어 선호는 분명 아니다라고 생각합니다. -- NeoHind
일반적으로 프로그래밍 언어 전문가들은 C언어를 퇴보로 평가합니다. 리차드 가브리엘의 유명한 WorseIsBetter라는 아티클에서 "worse"는 C언어를 지칭합니다. 프로그래밍 언어론적으로 보았을 때 C언어는 문제가 많고 지난 수십년간의 성과를 되돌려놨습니다. 하지만 오히려 이렇게 어설프기 때문에 더 쉽게 스며들 수 있지 않았나 생각합니다.
절대주의는 반드시 피해야 합니다. 그렇지만 절대적 상대주의에 빠지는 오류도 피해야 할 것입니다. 분명 언어를 비교했을 때 이것보다 저것이 더 진보했다고 평가할 수 있는 부분이 있습니다.
--김창준
네.. 확실히 C언어는 절대로 하이레벨 언어도 아니고, 언어적으로 안좋습니다. 많은 프로그래밍언어 학자들이 말하는 사실입니다. (CppLanguage도 마찬가지구요. CppLanguage는 C에 대한 Macro와 그다지 다르지 않습니다. C는 어셈블리어의 Macro라고 보는 관점도 많습니다) 하지만, 항상 가장 좋은 것이 1등이 아닌 것처럼(1등이 가장 좋은 것도 아닌 것 처럼).. 그런 것 같아요. '컴퓨터'를 다가가는 두가지 관점 - 기계와 인간 - 이 있다고 볼 때, C는 기계쪽에서 접근하기 좋은 언어라고 봅니다. 기계의 메커니즘이 그대로 언어에 녹아있고, 모든 프로그래밍의 책임을 인간에게 돌리니까요. 사람의 관점에서 다가서는 언어는 Haskell이나 ML과 같은 함수형언어나 Java나 C#과 같은 현대적인 언어겠지요. 프로그램의 많은 부분을 시스템에게 맡길 수 있으니까요. 김창준님 말씀처럼 진보와 현대적인 기술에 대한 평가는 이해해야합니다. 각 언어마다 그 용도는 다를 수 있겠지요. 진정한 하이레벨 언어로 OS를 작성한다는 것은 쉬운 일이 아닙니다. 일반적으로 C보다는 Fortran이나 Pascal이 더 빠르다는 이야기를 들을 수 있는데, 그것이 평가의 기준 - 내지는 선호의 기준 - 이 되지는 않는 것처럼 말이죠.
-- Selmo