C++ In The Kernel?
글쓴이: 권순선 / 작성시간: 화, 2004/02/03 - 10:30오전
http://www.kerneltrap.org 를 읽다 흥미있는 기사가 있어 올립니다. 리눅스 커널을 C++로 만들자는 내용에 대한 Linus의 의견입니다.
Quote:
"In fact, in Linux we did try C++ once already, back in 1992. It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA."The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed: 1) the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels. 2) any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. 3) you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++."
커널을 C++로 작성하는 것에 대해 어떻게 생각하시는지요? 이 게시판이 하도 썰렁한 것 같아 하나 올려 봅니다. :-)
댓글
C는 유닉스의 로망아니던가요. 흐흐... 다른것보다도 저는 "we
C는 유닉스의 로망아니던가요. 흐흐...
다른것보다도 저는 "we did try C++ once already" 라는 말이 믿기지가 않는군요. 2번 그리고 특히 3번에 올인합니다.
저는 찬성인데요.
내용을 보니 컴파일러가 C++의 몇 가지 기능을 잘 지원하지 않고,
만든 코드도 일정하지 않다고 적혀 있는듯 하네요.
http://osx86.org/study/os/kernel/wrtkernelcpp.txt
을 요즘 보는데 흥미 있네요
kernel을 C++로 작성? 멋진 생각 같은데요? 새로운 OS가 하나
kernel을 C++로 작성? 멋진 생각 같은데요? 새로운 OS가 하나 태어나는 거 아닐까요?
세벌 https://sebuls.blogspot.kr/
3번 항목에 있는 것 처럼 2.6에서 많은 부분에서 (특히 디바이스 드라
3번 항목에 있는 것 처럼 2.6에서 많은 부분에서 (특히 디바이스 드라이버 부분) 객체지향 기법을 도입했습니다. C로 하는 객체지향, 함수마다 오브젝트에 대한 포인터를 물고 다니는..
리누스가 C++을 싫어하는건 유명합니다. 혹시 C++에 익숙하지 못해서 그런건 아닐까 하는 생각이... :) 리누스가 커널 작업을 시작한 이후로 커널 이외의 프로그래밍을 거의 안한걸루 아는데, 그렇다면 1991년 이후의 개발 트렌드는 (커널에 관련된 것을 제외하고는) 수박 겉핥기 식으로만 알고 있을것 같습니다.. 이미 작성해놓은 부분들도 많고 C로 작성하는게 더 심플하다고 생각해서 그렇게 하고 있겠지요.
리누스가 하는 짓을 보면 모든게 심플 그 자체인 것 같습니다. 심지어는 에디터의 탭도 8칸으로 한다네요. 깊이가 탭 두세칸만 넘게 들어가도 복잡한 코드라고 코드 정리를 한답니다.
=-=-=-=-=-=-=-=-=
http://youlsa.com
이건 커널
이건 커널 개발자로서는 당연한 듯 보이네요...
그만큼 정확히 동작하고 누가 보아서도 명확한 코드를 만들어야 하니깐요...
C언어 옹호세력 - C++을 커널에서 사용하는건 도끼를 망치처럼 사용하는
C언어 옹호세력 - C++을 커널에서 사용하는건 도끼를 망치처럼 사용하는것과 같다. 즉 용도에 맞지 않는 일이다.
C++ 옹호세력 - C++에서 (no exceptions, RTTI, non-trivial descructors, etc) 몇부분을 제외하고 사용하면 C++의 장점 (polymorhism, inheritance, encapsulation을 통한 깔끔한 디자인과 쉽게 확장가능한 프레임워크)를 얻을 수 있지 않겠느냐.
C언어 옹호세력 - 그게 C++ 이냐 그정도는 C로도 다 된다. 그리고 Linux Kernel에서 C++ 로 커널 모듈 짜는것도 쉽지 않다. header도 손봐야 하고 원래의 C++ 과는 좀 다르게 코딩해야 한다. 신경쓸게 많다. 즉 귀찮다.
사실 저 논쟁의 처음은 Click(http://www.pdos.lcs.mit.edu/click/)이라는 커널 모듈이 C++로 작성되어 있는데 현재 2.2와 2.4 버전만 지원합니다. 그래서 2.6에서 컴파일 되게 하려면 어떻게 해야 되느냐는 질문이었는데 커널 전체를 C++로 하자는 말까지 나오게 된것 같네요.
Click은 C++로도 이쁘게 커널 모듈을 만들 수 있다는걸 보여주는 좋은 예인것은 확실합니다. 하지만 Windows Driver를 작성할때도 Numega 같은 툴의 도움 없이는 C++ 로 작성하기가 매우 귀찮습니다. Linux에는 그런 툴이 없으므로 Linus와 커널메인개발자들이 갑자기 C++이라는 도구에 반하지 않는 이상 Kernel 소스코드에서 C++을 보는건 드문 일이 아닐까 생각합니다. :)
C++로 만든다는건
C++로 만든다는건 득보다 실이 클것같습니다.
궂이 C++로 해서 차후 더쉽게 커널을 개발할수 있을것같지도 않고
속도가 더빨리지기는거녕 더느려질것같고
커널 프로그래밍에 최하위소스 안봐도 되는일이 아닌데...
클레스나 함수가 한단계 더 포장되어 있다는건 그만큼 한단계 더따라가야하니 소스보기도 그냥 C가 더좋을것같군요.
----------------------------------------------------------------------------
C Library Development Project
----------------------------------------------------------------------------
[quote="youlsa"]리누스가 하는 짓을 보면 모든게 심플 그
tab 사이즈 8 character는 Unix Coding style의 전통 일겁니다. ^^
제목이...
내용과는 상관없지만,
C++ in the kernel 이 아니라
Kernel in the C++ 이 아닌가요?
후후 재밌는
후후 재밌는 발상이신것 같네요.
영어 문제를 제기하신 것이 아니라, C++와 Kernel 의 포함관계를 말씀해주신 것으로 이해됩니다.
본 글타래의 context상으로는 C++ in the Kernel 이 맞을 수 있겠지만,
정말 C++ 언어 자체를 옹호 하시는 그룹에서는 Kernel in C++로 주장(?!) 하실 만한 내용이네요. ㅎㅎ~
...
...
[quote="akbar"]3) 번의 --3) you can writ
3번은 2번의 심각성을 인식한다면 자연스럽게 도출되는 결론입니다.
저도 딱히 리누스를 좋아하지는 않고 리누스가 자기 한계를 넘으려 하는지 아닌지는 모르겠지만 커널을 만드는데 뭐가 중요한지는 확실히 아는 인물이라는 생각이 드는군요.
oo가 필요하면 필요한 만큼 구현해 쓰면 됩니다. c++을 도저히 따라갈 수 없다라. 따라갈 필요가 없는데 왜 따라가야 하는지, 혹시 한계를 넘기 위해서 :shock:
c++이 가지는 모호함 블랙박스 지향의 oo라고 불러볼까요? 이 모호함 때문에 오브젝트간의 관계설정이나 인터그레이션에 드는 비용이 커지니까 결국 패턴이 나 stl이 나오는거 아닌가요? 커널에서 그런 배보다 배꼽이 커지는 짓을 해야 하나요? 어차피 커널과 모듈의 관계는 화이트 박스로 충분할 텐데요. 물론 c++로도 그렇게 할 수 있겠죠. 근데 왜? 단순히 몇몇 편리한 피쳐들 때문인가요?
그런 소소한 편리함 때문에 portability나 reliablity를 포기하고 넘을 한계라면 안넘는게 좋을 것 같습니다. 언젠가 c++이 c의 대체물이 된다면 커널은 그 맨 마지막 날에 c++로 바뀌는게 인류 공공의 이익을 위해 좋은 일일것 같은데요.
오늘 우리는 동지를 땅에 묻었습니다. 그러나 땅은 이제 우리들의 것입니다.
아직도 우리의 적은 강합니다. 그러나 우리는 그들보다 많습니다.
항상 많을 것입니다.
정확히 동감입니다.
무엇을 개발하든 최적이라고 생각하는 방법을 사용하는 것이
안그래도 발생할 수 있는 수많은 개발 시의 문제점들을 조금이라도
줄이는 길이 아닌가요.
2) any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. <-- 개인적으로는 이 말이 문제의 핵심을 정확히 집어낸 말이 아닐까 생각됩니다.
C++ 로 커널 작성시, OS 의 장점은 무엇인지 궁금해 지는군요.
C++ 로 커널 작성시, OS 의 장점은 무엇인지 궁금해 지는군요.
-------------------
나는 Copy&Paster 이다. 나의 화려한 기술 조합에 모두들 나를 두려워 한다. 나도 코드 Maker 이고 싶다.
Re: 제목이...
C++ in the [Linux] kernel: [리눅스] 커널에 C++로 만든 부분을 포함시키는 것
A kernel in C++: C++로 짠 커널
위와 같은 차이가 있습니다.
[quote="akbar"]3) 번의 --3) you can writ
저도 C++컴파일러에 상당히 실망을 해서 리누스씨의 생각에 공감하는편입니다.
사실 c++로 짠다는것이 문제라기 보다는 C++컴파일러 자체를 못믿겠다는것입니다.
<FONT face="Times New Roman" size=4>שלום צליכם מאת ארוננו ישוצ המשיח</FONT>
다른 무거운 기능들은 다빼고 봤을 때..reference와 inl
다른 무거운 기능들은 다빼고 봤을 때..
reference와 inline 기능은 성능향상에 도움이 될 수 있을 것 같습니다.
C89에는 저런 항목이 없는데..
그리고 컴파일러는 아직도 여전히 문제가 되는걸까요?
Re: C++ In The Kernel?
1) exception handling을 사용하지 않으면 됩니다.(사실 실제로 사용하는 사람도 있습니다: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=_rVPb.263235%24_x2.529611%40zonnet-reader-1&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26q%3DSEH%26meta%3Dgroup%253Dalt.os.development )
2) operator new와 operator delete를 재정의하면 됩니다.
3) C로 OO를 구현하는게 오히려 crap이 아닌지-_-;;
Re: C++ In The Kernel?
-_-;;; 그렇게 쓰는 사람들 많습니다. GTK+가 모두 그렇게 되어 있고, 심지어 윈도우의 기반을 이루는 Win32 API도 그렇죠.
=-=-=-=-=-=-=-=-=
http://youlsa.com
-_-;;
OO program is slower than non-OO programs...because of OO features like dynamic bindings...etc....etc.
....from my college concept of programming textbook -_-;;;;
우선 c++로 kernel을 작성했을 때의 이점이라는 것이 분명하지 않습
우선 c++로 kernel을 작성했을 때의 이점이라는 것이 분명하지 않습니다. 성능 상의 이점보다 코딩이 깔끔해진다라는 것을 드는데.. 과연 c++가 c보다 얼마만큼 깔끔한지는 의문입니다.
c++로 작성한다는 것은 기본적으로 oo 개념을 쓰겠다는 겁니다. oo가 적당하게 들어가는 곳이 있을 수 있습니다. 모듈 같은 경우에 특히 그런 개념을 쓰면 모듈에 대한 접근이 쉬워질 수 있습니다. 하지만 그 외의 경우에서 oo를 위한 추상화나 클래스 계층을 잡기가 참 애매합니다.
그리고 무엇보다도 현재 많은 시스템 프로그래머, 커널 프로그래머, 그리고 임베디드 시스템용 소프트웨어 등이 모두 c에 익숙하다는 점입니다. 당장 Linux의 새로운 커널이 c++로 짜여진다면 임베디드 시스템으로의 포팅도 어려워집니다.
명확한 성능 상의 이점이 있지 않은 이상 커널을 c++로 포팅해야 할 이유는 보이지 않습니다. 다만, 바깥과의 인터페이스를 하는 부분을 c++로 작성하거나 c++을 쉽게 물릴 수 있는 구조를 한다면 괜찮을 것 같습니다.
C++ 과 커널의 관계라 ...
제가 보기에도 그리 썩내키는 조합은 아닌 것 같군요.
리누스가 그런 선택을 내리는 것은 단순히 C++ 과 친하지 않거나
자신의 한계같은 이야기와는 전혀 관계가 없을 듯 합니다.
(물론 제 개인적인 의견입니다. ^^; 실제로 그런지는 리누스만이 알겠죠.)
C++ 에서도 FreeStanding 환경에서 필요한 것들을 지원하기위한
작업들을 하고 있다는 소문을 듣기는 했습니다만 ... (정확하지는 않음.)
지원한다고 치더라도 ... 굳이 FreeStanding 환경 프로그래밍에
적합하다고 느껴지는 C 가 아닌 C++ 을 사용 할 이유가 별로 없다고
생각되는군요.
제 생각에는 썩 나쁘지는 않은 것 같습니다. 특히 [b]커널에 GUI나
제 생각에는 썩 나쁘지는 않은 것 같습니다. 특히 커널에 GUI나 멀티미디어 관련 부분을 집어넣는다면 개체 중심 프로그래밍의 장점을 발휘할 수 있을 겁니다. BeOS는 개체 중심 언어로 써진 마이크로커널 기반 운영체제이지만 꽤나 좋아 보였습니다.
리누스 타넨바움 논쟁과 같은 리눅스의 역사를 생각해 볼 때 커널을 C++로 다시 쓸 가능성은 거의 없다고 생각하지만, 제가 운영체제를 만들 능력이 된다면 꼭 C++은 아니더라도 개체 중심 언어를 쓸 겁니다. 장기적으로 볼 때 코드가 깔끔하다는 것도 상당히 중요합니다.
----
It is essential, if man is not to be compelled to have recourse, as a last resort, to rebellion against tyranny and oppression, that human rights should be protected by the rule of law.
[Universal Declaration of Human Rights]
[quote="windy96"]우선 c++로 kernel을 작성했을 때의
C++ 로 짜면 의문의 여지없이 깔끔해집니다. 만약 C++ 로 짰는데도 깔끔하지 않다면 그것은 능숙한 C++ 프로그래머가 아닙니다.
kernel 전체를 C++로 다시 짤 것이냐? kernel 전체를 C로
kernel 전체를 C++로 다시 짤 것이냐? kernel 전체를 C로 짤 것이냐?
라는 식의 극단적인 생각에서 벗어나,
C++가 적절한 부분은 C++로, C가 적절한 부분은 C로 한다면 어떻게 되나요?
어떤 부분을 C로 짜는 것과 C++로 짜는 것 중 어느 게 적절한 것인가 판단하는 게 또 문제가 되려나?
세벌 https://sebuls.blogspot.kr/
C++의 화려한 코드속에는 그 어미를 찾아 다녀야 하는 난해함이 있습니다
C++의 화려한 코드속에는 그 어미를 찾아 다녀야 하는 난해함이 있습니다.
어미를 알지 못하고선, 그 자식을 알수 없기 때문이죠.
그렇지만, C++로 커널 작성시...
위에서 말한 자식들의 재작성으로 인한 새로운 커널이 탄생이 기하급수적으로
늘어나지 않을까 생각됩니다.
다만, 어미 찾기 놀이가 지겨울 뿐이지요.
-------------------
나는 Copy&Paster 이다. 나의 화려한 기술 조합에 모두들 나를 두려워 한다. 나도 코드 Maker 이고 싶다.
[quote="akbar"][quote="windy96"]우선 c++로
하시고픈 말씀은 알겠으나.. 동의는 못 하겠습니다. perl이나 아예 지저분함을 목적으로 작성된 언어를 제외하고..
모든 언어에 대해서 능숙한 사람이 짜면 깔끔해 보입니다.
문제는 그 깔끔함이 자기 자신만 이해할 수 있는 깔끔함인지.. 문서를 참조하지 않고도 적절히 이해할 수 있는 것인지 등의 문제이지요.
c++가 readability가 좋다라는 것은 절대 동의 못 하겠습니다. c#이나 java 등 c++ 이후에 나온 언어들과 비교한다면 너무 가혹한가요.
단적으로 지저분해질 수 있는 코드를 template으로 쓰면 깔끔해 보이지요. 하지만 역으로 왜 java나 c#에서 template이 없는가를 생각해보면 그 깔끔함에 대해서 의문을 가질 수 밖에 없습니다.
황당하군요.
황당하군요. :embarrassed:
전혀 수긍할 수 없군요.
정말 펄에 능숙한 사람이 작성한 코드를 보신적이 있긴 하신가요?
P.S.
답글달고 난 뒤 보니 3년은 된 글이군요... :-|
---------------------------
Smashing Watermelons~!!
Whatever Nevermind~!!
Kim Do-Hyoung Keedi
----
use perl;
Keedi Kim
흠.
C++ 을 잘 모릅니다.
다만 특히 파일시스템 부분을 보면서 이건 절대로 OOP 를 쓴다고 해서 나아질게 아니란걸 느꼈습니다.
커널에 C++ / C++을 커널에 ...
제 개인적인 견해지만 똑같은 노력을 들였을때
C++ 로 작성한 코드가 C 코드보다 퍼포먼스가 좋다고 생각하지 않습니다.
그리고 C++ 을 사용함으로 인해 주어지는 여러가지 제약들을
생각해볼때 그리 적합하지 않은것 같습니다.
그 제약들을 해결하기 위해 C++ 표준 자체에 어떤 다른 표준적인 내용을
추가한다는 것 자체도 약간 아이러니 하구요.
C++ 컴파일러들이 생성하는 코드 자체도 사실 C 코드보다는
커널에 사용하기에는 그다지 좋은 코드를 생성하지는 않는 것 같습니다.
편의와 깔끔함을 추구하기 위해 C++ 을 사용한다고 해도 ...
그다지 어울린다고 생각은 안드네요 ...
제가 생각하는 OS 는 무엇보다도 사용자의 편의나 그외 유저입장을
배제하고 단순히 개발자적 입장으로 볼때 퍼포먼스나 안정성의 문제를
생각하게 되는데, 전 C++이나 C에 대해서 그리 잘 아는편은 아닙니다만
그런 면에선 C가 나을듯 싶습니다.
혹시라도 커널에 C++ 을 활용해 기존 C 로 작성한 커널과
비슷한 퍼포먼스에 C++ 만의 깔끔함 ...
그 외에 C++ 을 사용했을때 얻을 수 있는 이점을 실제 OS 커널로
증명한 사례가 있는지에 대한 링크나 자료가 있으시다면 좀 첨부를
부탁드립니다. ^^;
사실 일전에도 외국에서 이런논의가 많았지만 대체적으로 C++ 에 대해서
회의적인 면이 많았습니다. 그래서 C++ 언어를 만든 "머시기 스트럽(?)"
인가 하는 사람이 먼가를 지원한다고 하기도 했었는데 최근에
관련 자료를 찾아본적이 없습니다. ^^; 혹시나 이부분에 대해서도
실제로 추가된 부분이 있다면 링크나 첨부문서를 리플 좀 달아주세요 ^^;
PS. 내용이 두서가 많이 없네요. C++ 에 대해서도 무지하고 아는바가 별로
없어서 그러니 이해해 주시기 바랍니다.
[quote="windy96"][quote="akbar"][quote="
OS X 의 드라이버가 BSD 기반에 C++로 되어있죠. 일부 업무관련
OS X 의 드라이버가 BSD 기반에 C++로 되어있죠. 일부 업무관련 분야 부분을 봤는데, 가독성이나 유지보수성이 C에 비해 좋아졌다고 별로 느껴지지 않더군요. 성능이야 뭐 많이 차이날 이유도 없을테구요. 한 3-4년전에 본것이라 지금은 어떻게 바뀌었을지 모르겠네요.
설령 가독성이나 유지보수성이 엄청 좋아졌다 하더라도 커널 개발자들을 설득해서 C++ 를 쓰게 한다는것은 좀 무리가 아닐지... 특히나 회사에 고용되서 일하는 사람도 아니고 오픈소스 개발자들에게라면 더욱 더. 제 주위만 해도 커널개발자들은 C++ 아예 안써본 사람이 대부분이고요. 게다가 똑똑한 사람들은 'reinventing the wheel' 같은 일은 본능적으로 거부감을 느끼겠죠.
C++ 로 kernel 개발은 어디까지나 실험적일 거 같네요.
C++ 로 작성하는 것이 좋다면 그것은 Reinventing The Wheel 이 아니라 Improvement 가 되겠습니다만 성공적으로 C++ 로 작성된 kernel 을 찾아볼 수 없으니...
C++ 지지자들이 한번 kernel 개발해서 보여주지 않는 이상 어려울 것 같다고 생각합니다.
저는 커널개발을 해본 적이 없어서 구체적으로 어떠한 제가 알지못하는 문제
저는 커널개발을 해본 적이 없어서 구체적으로 어떠한 제가 알지못하는 문제점이 있는지는 모르겠습니다..
하지만 토발즈가 제기한 문제점들을 한번 보자면..
exception은 쓰기 싫으면 안쓰면 그만인 거고..
컴파일러 문제는 C++표준이 확립되기 훨씬전인 92년도 얘기니깐.. 2004년도에도 문제가 되는지 모르겠네요.. C++컴파일러도 이미 충분히 검증되었을 것이라고 생각합니다.
C로도 OOP를 할 수 있다라.. 물론 할 수 있습니다. C로 OOP하기에 대한 책도 있습니다.
하지만 똑같은 기능의 OO로 된 코드를 만든다고 할 경우에.. C로는 함수포인터 등으로 복잡하게 해야하는 것을 C++에서는 class로 아주 간단하게 할 수 있습니다. 컴파일 된 후에는 성능차도 나지 않을 것이구요.
그리고 여기에 올라온 수많은 답변들을 보면..
~~해 보입니다, ~~~게 느껴지더군요, ~~~게 생각합니다 는 식으로 쓰신글들.. 이 많고.. 구체적인 C++의 문제에 대한 언급이 없는 것 같습니다.
소스를 C++로 해도 C와 별 차이가 없다라는 얘기는 확실하게 틀린 얘기라고 생각합니다. 어설픈 C++개발자가 개발했다면 모르겠지만.. 제대로 개발을 한 경우 C++초보가 아닌 이상 C보다 파악하기가 훨씬 쉬워집니다.
그리고 성능문제..
컴파일된 파일의 성능이란.. 메모리,CPU,OS,컴파일러 등에 따라서 예상과는 다른 결과가 얼마든지 나올 수 있습니다. 이런 것들은 정확한 profiling에 의해서 판단해야하는 것이지 막연하게 C++로 하면 느릴 것이다라고 생각하면 안되는 문제겠지요.
일단은 구조적으로 깔끔하게, 변경하기 쉽게 코딩을 한 후 profilling해본 결과 병목현상이 발생하고 있는 부분을 발견하는 경우엔 dynamic한 부분을 없애고 static하게 코드를 만든다던지 Assembly를 이용하던지 해서 바꿔주면 되는 것입니다. (이 것은 무슨 언어를 사용하던지간에 공통적으로 해당되는 부분이겠지요)
지금부터 커널의 맨 밑바닥부터 C++로 다시 짜는 것은 아무래도 무리가 있을 겁니다.. 하지만 새롭게 추가될 요소 중 상대적으로 critical하지않은 부분부터 차츰차츰 적용해 나간다고 하면 문제가 되지 않을 것이라고 생각합니다.
C++ 을 커널 개발에 사용할때의 문제점
아래와 같은 특징을 바로 쓸수 없는걸로
======================
- Built in functions
- Run Time Type Information
- Exception handling
- The C++ standard library
- global / static objects
======================
알고 있습니다. 전 C++ 을 거의 모르지만 저정도로도
C++을 사용한 작업을 하기에는 충분히 귀찮은 일이라고 생각하며 ...
저 기능들을 지원하기 위해 또 다른 코드를 만들어내야 하는일도 -_-;
그다지 좋은 발상 같지는 않네요.
또한 기존의 C 와 ASM 으로 된 코드자체가 가독성을 떨어뜨린다고
별로 생각이 안드는군요. 요즘 에디터들 기능도 참 많고 좋기두하구요.
컴파일러 문제는 이전보다 나아진것 같지만
아직도 불평불만이 많은걸로 알고 있습니다.
자세한 내용은 구글링을 해보시면 금방이라도 하루동안 읽어도
다 읽기힘든 량의 내용들이 나올것으로 생각되므로
참조링크는 걸지 않겠습니다.
다른 전제조건이 모두 같다고 가정했을때 C++ 코드를 작성했을 경우
C 보다 느려지는 결과를 낳을 것이 당연하다고 생각합니다.
C++보다는 Objective C 를 생각해보는게 어떨까
하고 조심스레 생각해봅니다.
그리고 부분적인 C++ 의 적용을 하기위해
위에서 언급된 작업이나 기타 C++을 사용하기 위해 필요한
여러가지 작업들을 C++ 을 활용했을때 얻을 수 있는
이점이 없다면 특별한 이유없이 커널 개발자들이 하려하지
않을것이라고 생각되기도 하구요.
그들은 C와 ASM 으로 작성된 커널 코드가 난해하거나
가독성을 떨어뜨린다는 생각은 하지 않고 있으리라 생각합니다.
제 생각 또한 그렇구요. 실제로도 그다지 가독성이 떨어진다고 생각은 안드네요.
(태클을 걸기위한 내용은 아닙니다. ^^; 제 생각은 이렇다 라는것뿐예요.)
^^;
네이버의 이준호 교수님도 탭 3칸 이상 들어가면 코드 정리하라고 하십니다^^;
함수라인도 30-50라인 이상 넘어가지 말라고;;;한다는;;;
아..주제랑 다른 리플을 해버렸네요^^;;ㅋㅋ
-----------
청하가 제안하는 소프트웨어 엔지니어로써 재미있게 사는 법
http://sozu.tistory.com
Re: C++ 을 커널 개발에 사용할때의 문제점
이 중에
- Run Time Type Information
- Exception handling
- The C++ standard library
이 3 개는 커널 프로그램시에는 거의 불필요 합니다.
가독성이라는 것은 단순히 보기 쉽다를 넘어 유지 보수할 때
어떤 기능을 어디에서 고치면 어떻게 동작할 것이다라는 예측가능성을
보장해야 하는 것입니다.
사소한 예를 들어
C 에서 메모리를 해제하는 루틴의 경우
"이 메모리는 어디쯤에서 반드시 해제해 주어야 한다" 고 프로그래머가 기억하고 작업하는 것과
C++ 에서 "이 메모리는 해당 클래스의 소멸자가 알아서 해제해준다 그러므로 신경쓸 필요가 없다" 라고 하면서 작업하는 것과 어느 쪽이 유지 보수에 도움이 되겠습니까.
다른 전제조건이 모두 같다고 가정했을때 C++ 코드를 작성했을 경우
C 보다 느려지는 결과가 나오는 경우가 많을 것도 같습니다.
그러나 능숙한 C++ 프로그래머에게는 이 말도 해당되지 않습니다.
자세하게 구체적인 예를 들지 않겠지만
객체 설계를 하면서 (속도가 중요한 부분에서) C 보다 느리게 짜는 프로그머가 있다면 아직 C++ 을 더 연구해야 합니다.
^^;
제가 C++ 에 대해서 좀더 깊이있게 안다면 더 토론이 가능할지도 모르겠습니다만 ... 제가아는 C++ 의 깊이가 얕은지라 ^^;
akbar 님 고견에 감사드립니다.
Re: ^^;
저도 그 수업을 들었지만, 그 수업에 나온 과제의 크기를 고려해서 그런듯 싶네요..: )
많이들 사용하고 있는 GUI 라이브러리(GTK, Java, MFC 등등)들 소스 코드를 보면 30-50라인이 넘는 것도 많고, 탭도 3칸 이상 되는 것들도 많죠.
그건 그렇고, C++ 또는 C 를 사용을 하던간에 결국 원하는 목적에 부합되는 언어를 사용하는게 맞는걸로 생각되어 지네요. 언어와 프로그래밍 패러다임하고는 별개이니까요. 최종적으로 나오는건 기계어니까요, 기계어로도 객체 중심의 프로그램을 구현 할수 있다는 말이 되겠죠? ^^ 가능성의 얘기일뿐이지만요..^^
흐음...
Re: C++ 을 커널 개발에 사용할때의 문제점
제가 보기에는 C++이 커널 프로그래밍에 불필요 합니다.
그것을 제작자의 의도대로 하지 못하는게 제대로 된 커널은 결코 아니라고 생각합니다. C++의 hidden cost에 의존하는 것은 운영체제의 구현이 제작자에게 의존되는 것이 아니라 컴파일러에 의존하게 됩니다. 어느 쪽이 유지 보수에 도움이 될 것인지는 생각해봐야 할겁니다.
능숙한 C++프로그래머라고 해서 C보다 느리지 않게 짤 수 있다고 생각하지 않습니다. 객체와 상속이 포함된 클래스가 C의 함수보다 빠른 것을 생각하시는 것은 불가능에 가깝습니다. 혹자는 inline 키워드를 말하기도 합니다만.. inline 키워드는 그 함수가 inline화가 되는 것을 보장하지 않는다고 알고 있습니다. 더 나아가 클래스 속에 있는 inline은 아예 무시하도록 구현된 환경이 많습니다. 가상 함수로 설정된 경우 잠재적인 위험이 있을 가능성이 있어서 아예 배제하는 것이지요.
아니면 퍼포먼스를 위해서 함수객체와 템플릿으로 채울까요. 함수객체로 채운다면 오히려 생산성이 떨어질 것을 확신합니다. 함수형 언어와는 달리 C++에서는 함수객체가 자연스럽게 쓰이기가 힘들다고 생각합니다.
그리고 힘들게 C와 비슷한 퍼포먼스가 나오게 짤바에 자연스러운 C언어의 구문을 이용하는 것이 합리적일 겁니다. 커널에서 C++을 사용할 이유는 없다고 생각합니다.
- 죠커's blog / HanIRC:#CN
Re: C++ 을 커널 개발에 사용할때의 문제점
C++ 이 커널 프로그래밍에 불필요하다면 C 도 불필요 합니다.
C++ 로 짜면 제작자의 의도대로 될 수가 없는가요. 성급한 판단입니다.
C++ 이라면 상속을 굳이 써야 한다는 생각은 편견이 아닐가요
C++ 같은 객체지향 언어의 최대목표는 훌륭한 객체를 만드는 것입니다.
훌륭한 객체란 보통 재사용성이 높아야 한다고 생각하기 쉽지만
그외에도 부품화, 교체가능성 등으로 그 질을 판단할 수 있는 것이지요
요즘들어 프로그램 개발 방법론으로 부품화를 논할 때 교체가능성도 같이 얘기를 하더군요
그리고 객체란 무엇입니까. 관련있는 자료의 집합이 아닙니까.
이렇게 관련있는 자료를 모아서 외부의 간섭없이 하나의 그릇에 담아서 서로간에 유기적으로 사용해서 원하는 결과를 얻는다면 그것으로 객체설계의 1차 목적은 달성된 것입니다.
그것으로 상속을 하느냐 안하느냐, 어느 멤버 함수는 가상이어야 하느냐는 나중 문제입니다.
커널 개발의 특성상 상속이나 가상함수는 많이 억제하는 것이 옳습니다.
그러면 이렇게 되물을 것입니다.
"상속이나 가상함수가 빠진 C++ 이 무슨 C++ 이냐? 차라리 C 를 쓰지."
위에서 이미 얘기했지만 객채지향언어의 1 차 목적은 객체를 설계하는 데 있으며 상속이나 가상등등의 이야기는 선택사항입니다.
그러면 또 혹자는
"그 정도의 객체 설계는 C 로도 할 수 있다."
고 할지도 모르지만 C 가 C++ 수준의 객체설계를 할 수 있을 것 같았으면 C++ 이 나오지도 않았을 것입니다.
요즘은 게임프로그램의 핵심엔진도 C 에서 C++ 로 점차 옮겨가는 추세입니다.
규모가 커질 수록 C 로는 유지 보수에 있어서 점점 더 버거워지는게 현실인 것 같습니다.
inline 이 그렇게 문제가 된다면 매크로를 씁시다.
inline 에 문제가 있는 것이 C++ 이 커널 개발에 걸림돌이 된다는 것은 좀 비약인 것 같습니다.
"함수객체로 채운다면 오히려 생산성이 떨어질 것을 확신한다" 고 하셨는데 이것은 저도 마찬가지입니다. 단 함수객체를 쓰냐 안쓰냐도 선택사항입니다.
그러나
inline 키워드나 상속, 가상함수 등등을 억제한다고 해서 "힘들게" C와 비슷한 퍼포먼스가 나오게 짜는 것인가요
C++ 을 쓰면 "자연스러운" 구문이 나오지 못한다는 뜻인가요
그렇게 믿는다면 할 수 없지만
톰슨과 리치가 기계어로 OS 를 짜던 게 당연하던 시대에 C 로 만들어 새물결을 일으켰듯이
누군가가 C 로 OS 를 짜던 게 당연하던 시대에 C++ 로 만들어 새물결을 일으키기를 기대해 봅니다.
Re: C++ 을 커널 개발에 사용할때의 문제점
객체가 각 플랫폼마다 언제 생성되고 언제 소멸되는지 예측할수 있을까요? 예측할 수 있다고 단정짓는게 성급한 판단이라고 생각합니다.
일단 C++이 다 패러다임 언어인데 객체지향 언어라고 규정짓는 것은 위험하겠지요.
객체는 재사용성을 높이기 위해서 상속을 하는 것이 아니라고 생각합니다. 객체답게 쓰기 위해서 상속을 하는 것이죠. 상속하지 않고 어떻게 객체 설계를 이루어 내실건지 제가 궁금합니다. 어떤 클래스가 상속하지 않느냐 가상함수로 둘꺼냐를 나중에 둔다는 것은 냄새가 나는 객체들만 만들 꺼라고 생각합니다.
객체라 보다는 정보를 모아둔 모듈에 가깝다고 생각이 듭니다.
akbar님이 말하실려는 클래스를 쓰면서 느려지지 않는 방법으로 제시할 것이 inline이나 함수객체가 아닐까란 생각에서 말했습니다.
class를 함수만 들어간 구조체로 쓰는 형태라면 메소드에는 클래스를 가르키는 포인터외에는 추가되는게 없을테니 속도 저하는 적겠군요. 딱 C에서 함수쓰는 정도로 메소드를 호출한다면 성능저하는 적겠군요. 성능저하에가 적겠지만 그렇게 까지 해서 클래스를 선언해야 하는가는 의문이 듭니다.
akbar님이 퍼포먼스가 떨어지면 c++을 제대로 쓰시는 개발자가 아니라고 하셨던걸로 기억합니다.
제대로 c++답게 설계를 하면서 퍼포먼스를 걱정한다면 함수객체, 상속, 가상함수, 템플릿 등들의 테크닉을 생각하면서 기교적으로 짤수 밖에 없지 않을까요?
akbar님의 글을 보면서 더 확신이 든 것은 class 단위로 자료와 함수만 묶어두고는 c처럼 프로그래밍을 하는 것 같다는 생각이 듭니다.
그렇게 짤려면 왜 c++을 써야 할까 저는 여전히 의문이 듭니다. 약간의 불편만 감안하면 c 컴파일러에서 컴파일될텐데요. 룰을 깨트려서 얻는 이익이 과연 클까요?
- 죠커's blog / HanIRC:#CN
Re: C++ 을 커널 개발에 사용할때의 문제점
객체가 전역객체로 사용되는 경우 각 플랫폼마다 언제 생성되고 언제 소멸되는지 예측할 수는 없습니다.
그러나 객체를 꼭 전역변수로 사용하나요,
또한 그렇다고 해서 크게 문제가 되나요
만약 문제가 된다면 C 로도 마찬가지 문제입니다.
정적 객체 문제는 이미 토론 게시판의 "C++ 은 C 의 확장" 편에서
C 인테페이스 함수를 객체를 사용한 C++ 로 만들어 좀 자세하게
의사코드를 보여드렸습니다.
대개의 경우 99% 는 과연 상속까지 고려해야만 객체다운 설계일 것입니다.
그렇다고 속도라는 특수한 문제로 상속을 고려하지 않는다고 해서 객체다운 객체가 아닐까요.
C 프로그래머들이 하는 말 중에 C 도 객체설계가 가능하다고 합니다. 그렇다면
C 에서는 상속이란 개념없이 어떻게 객체 설계를 이루어 내고 있는 지 저도 궁금합니다.
C++ 활용도 면에 있어서 불만족 스럽기는 하지만
"딱 C에서 함수쓰는 정도로 메소드를 호출한다" 고 해보겠습니다.
정의 부분의 코드가 1000 줄되는 함수 large() 가 있습니다.
그런데 이 함수가 기능적으로 몇 개의 부분으로 나뉘어 질 수 있다고 할 때
C 프로그래머는 이렇게 합니다.
large() 함수 외부에 기능별로
large1()
large2()
large3()
등의 함수를 만들어 놓고
large() 함수에서 large1(),large2(),large3() 를 차례로 호출합니다.
C++ 프로그래머라면
large1(),large2(),large3() 를 private 멤버함수로 만들어 놓고
large() 만 전역 멤버로 설정하든가 아니면
large() 함수 내에 클래스를 정의하고 이 클래스의 멤버 함수로
large1(),large2(),large3() 를 만들어서 이 멤버함수 들을
large() 함수 내에서 차례로 호출함으로써 해결을 할 것입니다.
이 둘 중에서 어느 쪽의 설계에 점수를 줄 수 있을 까요.
속도야 차이가 없겠지만 데이타 은닉화 면에서는 후자 쪽에 점수를 주어야 할 것입니다.
데이타 은닉화는 C 로는 달성할 수 없는 중요한 요소입니다.
class 단위로 자료와 함수만 묶어둔다고 해도 C++ 의 클래스라는 녀석은
함수 외부에서든 내부에서든 심지어 다른 클래스의 내부에까지 침투하여
사용할 수 있는 것입니다. 이 침투한 C++ 클래스는 자료를 기능별로 나누고
밖에서는 알 필요가 없는 함수들은 밖으로 정체를 알리지도 않습니다.
이것을 과연 C++ 을 쓰는 이유가 안된다고 말할 수 있을 까요.
"C++ 은 C 의 확장" 토론에서
게임프로그래밍은 c++으로 짜는게 당연하다고 생각하시는데
게임의 핵심엔진 부분에 있어서 이런 경향은
오래 된 것은 아닙니다. 이전에는 어셈이나 C 가 당연했습니다.
이런 추세에서 C++ 로 옮겨지고 있는 것은 C 로는 아무래도 버겁기 때문일 것입니다.
리눅스 커널을 C++로 만들자는 의견이 나온 것도 이런 반증이 아닐 까요
게다가
윈도우 NT 개발 시에 빌 게이츠는 개발 초기에
NT 코드를 C++ 로 작성하라는 지시를 내렸습니다.
이것이 완벽하게 지켜지지는 않았지만
역시 왜 C++ 이 필요한가에 대한 하나의 답변일 수 있습니다.
약간의 불편만 감안하면 C++ 컴파일러에서 컴파일될텐데요.
C++ 을 사용한다면 많은 C++ 프로그래머가 커널 개발에 참여할 수 있는 데서 오는 반사 이익이 과연 작을까요.
(물론 C++ 프로그래머가 C 를 잘 다루지 못한다는 말은 아닙니다.
아무래도 C++ 이 익숙하다 보니까 관심이 더 가게 되겠죠)
akbar 씀:정의 부분의
궁금한 것이 있는데요. 저 위의 예에서 무슨 데이터를 은닉한 것인지 잘 이해가 되지 않네요.
블로그: http://turtleforward.blogspot.com
블로그: http://turtleforward.blogspot.com
Re: C++ 을 커널 개발에 사용할때의 문제점
적어도 C에서는 모든 부분에서 통제가 가능합니다. 생성자와 소멸자를 사용하는 것은 커널레벨에서는 제작자가 모든 부분을 예상하는 것은 불가능합니다. 또한 전역객체가 아니더라도 생성자와 소멸자의 모든 작용을 제작자가 예상하는 것은 힘들다고 봅니다.
그때나 지금이나 akbar님과는 의견차이가 좁혀지지 않는 것 같습니다.
가상함수나 상속의 수준을 흉내낸 구현도 있습니다. 그리고 상속을 고려하지 않은 클래스라면 여러가지 트릭으로서 C가 커버하기가 더 쉬운 부분이라고 생각됩니다.
C프로그래머라면 large1, large2, large3의 헤더와 코드를 분리시켰을겁니다. 이 부분을 배포하지 않는다면 충분히 가능한 부분입니다. 훌륭한 OOP 프로그래머 중에서 private 메소드를 안쓰는 분도 계십니다.
현재의 게임들은 api를 사용하는 측면에서 프로그래밍되고 있습니다. 과거처럼 vesa 그래픽 카드를 접근하기 위해서 메모리 관리를 최적화하기 위해서 자원을 최대한 얻기 위해서 어셈블리/C를 사용하는 시대는 지났습니다. 현재의 게임 프로그래밍은 저수준 프로그래밍이 아닙니다. 커널과 게임 프로그래밍을 동급으로 보시는 것은 잘못된 거라고 봅니다.
embeded의 자바 프로그래머를 보셨는지 모르겠습니다. 자바가 지원하는 기능들을 퍼포먼스를 계산하면서 의도적으로 피해가면서 짜고 있습니다. 님이 주장하시는 C++ 커널 프로그래밍이 C++의 특성들을 피해가면서 프로그래밍을 하시는 것이라고 생각하지 않으십니까? 자연스러운 C++프로그래밍이 아니라고 생각합니다. 프로그램을 짜면서 이것은 하지 말아야지. 이것은 하지 말아야지 하는 것이 효율적일까요? 커널 프로그래밍에는 여전히 C가 효율적입니다.
룰을 깨트릴때는 깨어서 얻는 이득이 더 클때만 깨어야 합니다. 여전히 깨어서 얻을수 있는 이득은 더 크지 않다고 생각합니다.
이번 글을 마지막으로 이 논쟁에서 빠져나갈려고 합니다. akbar님과의 저번의 c/c++ 논쟁에서 중간에 멈추었던 것과 같은 이유인데 지금 이 쓰레드를 저와 akbar님이 독점하고 있군요. 저희 둘만의 토론을 계속 할려고 한다면 차라리 메일이 낫지 않을까 합니다.
- 죠커's blog / HanIRC:#CN
[quote="skjk"]다른 무거운 기능들은 다빼고 봤을 때..
reference는 그냥 포인터 연산을 한단계 숨긴 것에 불과합니다. 생성되는 코드면에선 아무 차이가 없죠. inline은 이미 C 표준이고, 리눅스 커널 안에서도 많이 씁니다.
한국 BSD 사용자 포럼
저기 이거 여기 어울리는 글이 아닐 지도 모르지만...윈도우 커널은
저기 이거 여기 어울리는 글이 아닐 지도 모르지만...
윈도우 커널은 대체적으로 어떤 언어로 되어 있을까요?
위에서 NT부터는 C++이 많이 사용됐다는데... 어떤지 알수가 없군요... 아뭏튼...윈도우 어플리케이션은 VC++로 작성되는 것으로 알고 있고...MFC 자체도 ...
물론 Win32 API가 근간이긴 한데... MS Press의 책들의 저자들은 WIn32 API를 그다지 좋아 하는거 같지는 않더군요... 심지어... Ugly Code라고 까지쓴걸 본적이..;; 암튼 MS 넘들은 C++에 남다른 애정을 가지고 있는거 같던데... 과연 커널프로그래밍 영역에서도 그럴지는 모르겠군요...
...
...
다른것 보단 현재의 C로만 된 API와 함께 C++로 된 API 도 지원
다른것 보단 현재의 C로만 된 API와 함께 C++로 된 API 도 지원 했으면 좋겠습니다.
현재 처럼 C API를 warpper 한게 아닌 형태로 말입니다.
無心
이 쓰레드는 좀 이해가 안됩니다.왜 C++과 C의 장단점 자체가
이 쓰레드는 좀 이해가 안됩니다.
왜 C++과 C의 장단점 자체가 문제가 되고 있는 것인지 모르겠네요. 제가 C와 C++을 둘다 잘 모르지만 문맥만으로는 다소 억지스러운 부분들이 상당히 보이네요.
C++이 좋다 C가 좋다라고만 서로를 비교하기 보다는 커널에서 어떤 언어를 어느 부분에 적용할때 어떠한 이득을 얻을 것이다.
그렇다면 그 비율은 얼마나 되고 전체적으로 봤을때는 어떠한 이득을 얻을 수 있을 것이다가 아니고...
이러한 개념을 프로그래밍에 적용하면 좋아진다.
이러한 개념은 필요가 없다.
커널에 이러한 개념을 적용하면 프로그램하기 좋아진다.
이런류더군요. 좀 더 현실적인 토론이었으면 좋겠습니다.
제가 잘못 생각하는 것일수도 있겠지만 지금까지의 글을 읽은 제 느낌은 그렇습니다.
잔뜩 기대하고 커널의 발전가능성을 엿보려 했으나...
------------------
나는 바보
운영체제를 c++로 작성하는 프로젝트들이 예전부터 많이 있었던 것으로 알
운영체제를 c++로 작성하는 프로젝트들이 예전부터 많이 있었던 것으로 알고 있습니다. 기술적으로도 가능하며 완성도가 높은것들도 있는걸로 알고 있습니다.
그러나 리눅스 커널을 c++로 작성하려 한다면 차라리 새로운 커널을 c++로 첨부터 작성하는것이 낳다고 봅니다. 현재의 리눅스 커널에 c++를 넣어서 사용하는것은 오히려 비효율적인 결과를 초래할것 같습니다. 불필요한 코드가 많이 추가될 것으로 보이며 따라서 바람직하다고 보기가 힘듭니다.
"커널을 c++로 작성하는 것에 대해 어떻게 생각하시는지요?" 라는 질문에는 "흥미는 있으나 저라면 c를 사용하겠습니다." 입니다. 역시나 운영체제를 c++로 직접 한번 만들어 봐야 알것 같은데 경험하신분의 글중에 고통스러웠다라고 말한 글이 보이네요. 물론 개인적인 입장에서 쓴 글이라 생각하니다만..
C++로 만드는 커널은 다음 사이트를 참조 하세요.http://l
C++로 만드는 커널은 다음 사이트를 참조 하세요.
http://l4ka.org/
주소이름을 보면 아시겠지만 마이크로 커널 종류 입니다.
無心
BeOS가 망한 이유 중
BeOS가 망한 이유 중 하나가 C++ 을 선택했기 때문이라죠.
그냥..
그냥.. c++옹호론자분이 리눅스를 c++로 한번 포팅해주시면 게임끝 아닐까요?
전 개발자가 아니라서 모르겠는데...
유틸리티 만들려고 하는 사람들은 C++써도 괜찮은 거죠?
전 실력이 딸려서 어려운 C 는 잘 못할거 같아서 C++을 타겟으로 잡았는데...
뭘 해야 할지 솔직히 몰라서...C 냐 C++이냐 아직 고르지 못했어요.ㅠㅠ
---------------------------------------------------
1t의 생각보다 1g의 실천이 낫다.
BLOODY STUPID IDEA
BLOODY STUPID IDEA <==== ㅋㅋㅋㅋ
영국식으로 하면
BLOODY Hell인가 그럴겁니다.
쓸데없는 논쟁 하고 계시군요 ㅡ.ㅡ;
C++로 만들어보면 뭐가 답답한지 알수 있습니다. c코드처럼 함수가 메모리와 1:1 매핑이 되지 않으면 개발할때 삽질을 해야합니다. 혹은 그런 툴을 만들어야 하는데 그 툴이 OS만드는 노력보다 더 어렵다면 굳이 그럴 필요가 있을까요.. lowlevel로 커널을 디버깅 해보시면 왜 아직도 C로 코딩하고 있는지 알수 있습니다.
윗분 말씀처럼...
메모리랑 1대 1로 매핑되서 디버깅 하기 쉬운건 확실이 C인듯 싶습니다.
C++을 로우레벨로 디버깅 하기에는 C보다 더 많은 노력과 시간이 소비될듯 싶은데.....
그나저나 C++ 컴파일러가 표준화 된게 10년이 채 안되지 않았나요? 아닌가....?
음... C++ 이라...
H/W 사양이 무척 좋아지다보면-
필요없는 코드가 많이 내제되어 불필요한 행동을 많이 하고,
Stack 의 생성과 해제가 심하더라도 그것이 상관없을 만큼의 속도를 내는 때가 오겠죠...^^
아니면 컴파일러가 무척 똑똑해져서 Compact 하며, Smart 한 바이너리를 생성해 내던가...
그렇지 않다면 시기 상조가 아닐까 싶습니다만...
지나가다...
임베디드 분야에서 C++ 컴파일러를 사용할 수 있게된 이유와 견주어 생각해 봅니다.^^
C++로 구현된 Symbian이라는 OS가 있습니다.
커널이 C++로 구현되었고요 EKA2 라는 이름으로 불립니다.
Symbian은 세계 스마트폰 시장의 60%이상을 점유하고 있고, 유럽에서는 잘 알려지고 안정성에 있어도 높이 평가 받는 OS 입니다.
실제 커널 소스는 공개되어 있지만 라이센스를 가져야지만 소스를 얻을 수 있습니다.
물론 그 비용은 비싸구요.
다음은 TInterrupt 라고 하는 클래스 인데 이를 상속 받아서 커널단의 인터럽트 서비스 루틴 구현 가능합니다. 정확히 말해서는 특정 하드웨어 인터럽트에 바인드 하여 해당 인터럽트가 발생했을 때 드라이버 개발자가 구현한 순수 가상 함수가 호출되도록 하는 동작을 합니다.
http://www.symbian.com/developer/techlib/v70docs/sdl_v7.0/doc_source/reference/cpp/InterruptArchitecture/TInterruptClass.html#%3a%3aTInterrupt
사람마다 생각이 다르겠지만 저는 C++로 구현한 Symbian 커널이 linux의 그것 보다는 더 세련되고 좋아보였습니다.
개인적으로는 C++을 어떻게 쓰냐에 따라 C와 C++ 사이의 퍼포먼스 차이는 없다고 봅니다.
DThread* thread=Kernel::GetCurrentThread();
thread->Suspend();
newThead->Resume();
위는 실제 커널 소스는 아니지만 그냥 적어 봤습니다. 만약 C로 구현하라면 대충 다음과 같겠죠?
DThread* thread=Kernel::GetCurrentThread();
thread_suspend(thread);
thread_resume(newThread);
인터럽트는 대충 다음과 같이 구현할 겁니다.
class TMyInterrupt: public TInterrupt
{
private:
virtual void Service()
{
// my interrupt service routine
}
};
TMyInterrupt* int=new TMyInterrupt();
int.Bind(EMyHardwareInterrupt);
C로 구현한다면 위의 Service 순수 가상 함수 대신에 함수 포인터를 사용하겠죠...
그리고 개인적으로 리눅스 커널이 C++로 개발되면 좋겠다는 생각을 합니다.^^;
지금 까지 진행해온
지금 까지 진행해온 상황은 최소에서 > 최대로 뻗어 나가는 입장이었습니다.
그러나 지금에 와서 보았을때는
그 당시와는 하드웨어 적인 부분도 엄청나게 발전했으니
여분의 자원을 낭비 할일 없이 큼지막하게 나가자는 말인거 같습니다.
물론 동시에 업그레이드 되어가겠지만
유닉스 개발자들의 로망은 무너 지겠지요..
C++ 괜찮습니다만..
우리나라 개발자들 많이 사라지겠네요..
이제야 갭이 생기려나..후훗......
laziness, impatience, hubris
不恥下問 - 진정으로 대화를 원하면 겸손하게 모르는 것은 모른다고 말하는 용기가 필요하다.
laziness, impatience, hubris
不恥下問 - 진정으로 대화를 원하면 겸손하게 모르는 것은 모른다고 말하는 용기가 필요하다.
위에 언급된 Click modular router project도 좋은 예가 될 듯 합니다.
http://www.pdos.lcs.mit.edu/click
현재는 공식적으로는 2.6.19.2 까지 지원하고 비공식적으로는 2.6.24 까지 지원하고 있습니다.
2.6.24 패치는 아직 commit 되기를 기다리고 있는 상태이고요
https://pdos.csail.mit.edu/pipermail/click/2008-April/006937.html
장단점이 있겠지만 저는 장점을 더 많이 경험했고 저도 어느정도 참여하고 있는데 무엇보다 재미있습니다^^
x86 계열에서 C 와 C++ 로 시스템 프로그래밍을 해보다 몇번 삽질한 경험을 얘기해봅니다...
파티션 매직같이 부팅후에 OS 없이 32비트 보호모드 전환후 프로세스 몇개 동작시켜야 하는 미니커널 정도를 만들어본경험이 있는데요..
실제 리눅스나 윈도우 같은 제대로된 커널하고는 다르기 때문에, 잘못된 생각일 가능성이 많겠지만 얘기해봅니다.
토발즈가 C++ 로 개발하는것을 무척 부정적으로 언급한 부분은 아마 호환성측면에서 언어적인 요소를 그대로 가져간다고 가정했을때의 불만인듯 합니다.
개발이 가능하냐 불가능하냐에 대한 답은 확실히 가능하다고 생각합니다. 당연한 얘기지만 C++ 은 태생적으로 고급 어셈블리어로서의 C 모습을 그대로 가져왔고 거기에 OOP 적인 요소들을 충분히 추가했다고 생각합니다.
문제는 효율성 측면인데요.
이부분에서 전 C의 손을 확실히 들어주고 싶네요.
C++ 은 언어적으로 너무 복잡합니다.
어플리케이션 작성시 에도 고려해야 할 것들이 많은데, 생성되는 코드 한줄한줄 확실히 파악해야 하는 커널의 경우, 코드 생성에 관한 표준이 확실히 없기 때문에, 컴파일러 하나 딱 정해서 한다면 모를까, 그렇지 않다면 이에 대한것을 고려하기가 쉽지 않다고 생각듭니다.
예를 들어 예외처리를 빼려면 예외처리코드만 빼면되는것이 아니고, 대부분 구현이 예외처리 매커니즘 보조코드들이 코드 여기저기 숨겨져(컴파일옵션에서 예외처리를 꺼도~~) 있어서, 순수하게 작성된 코드끼리만 링크하려해도 문제가 생기더군요. 물론 지식이 모자라서 그런것일수도 있습니다. 근데 모든 개발자들이 사용하는 C++ 컴파일러의 벤더 종속적인 부분을 잘 알거라고 생각안합니다.
비트필드자료형은 어째서 그렇게 컴파일러마다 틀린지..컴파일러 바꿀때마다 역어셈해서 생성된 코드 확인하다가 의미없겠다 싶어서 포기하고 그냥 C의 구조체정의에서 지원하는 비트필드 사용했습니다.
같은 이유로 템플릿못씁니다.
그럼 C++ 로 개발해서 사용할만한건 클래스 및 클래스와 관련된 상속 , 가상함수 등이 있겠네요.
위에 어느분이 이들 클래스 관련 특성들이 무척 유용하게 사용될수 있다고 얘기했는데, 전 부정적으로 생각합니다.
대부분의 순수 커널 구현( 커널 서비스를 제외한) 이 하드웨어에 의존합니다. 하드웨어에서 프로세스를 스위칭해주고 프로세스 자료구조가 100바이트로 정해져 있다면(프로세스나 쓰레드를 소프트웨어적으로 구현할수도 있지만 예를든겁니다), 데이터를 거기에 맞춰야 하는데 C++ 의 클래스는 상속받은 하위 클래스가 가상함수를 정의하면 VTBL (가상함수테이블에대한포인터)이 자동적으로 할당됩니다. 클래스를 100바이트로 맞추어도 실제로 "sizeof(VTBL) + 100바이트" 로 클래스크기가 설정됩니다. 크기도 문제지만 그보단 가장 앞의 프로세스 관련데이터가 있어야 하는데, 엉뚱한 데이터가 들어가게 되죠. 이걸 방지하려면, C++ 메모리 메모리 할당자로 동적/정적으로 어딘가 복사본을 생성해서 실제 프로세스 데이터만 정해진 엔트리에 복사해야합니다.(2배이상 느리죠?) 아니면 또다른 트릭을 지저분(?) 하게 집어 넣어야 하겠죠.
따라서 가상함수 탈락...자동적으로 다형성의 이점은 못씁니다 (물론 별별 트릭다써서 사용가능하게 할수 있습니다만...그렇게 해야 할이유가..없습니다. 누군가 커널을 읽기 좋게 하기위해? 읽기 더 힘듭니다 ...)
남은건 클래스 와 클래스 상속인데, C++ 의 클래스나 C의 구조체나 생성자/소멸자를 빼면 다를게 없고, 상속은 C 에서도 포인터 하나로 손쉽게 구현가능합니다. 즉 다형성을 빼버린 상속은 전혀 메리트가 없습니다.
반론의 여지가 있지만, OOP는 일부 자료(UI가 대표적이죠) 에 대한 설계의 자연스러움과 일부의 경우 코딩의 편리함이 대표적인 특징이라고 생각합니다
일단 순수 커널은 설계시 OOP 가 전혀 도움안되는 설계형태라고 생각하고요( 하드웨어에 밀접한 자료구조가 많죠~) ,
코딩의 편리함 측면에서 예를 들어본다면, 만약 3개의 파라미터를 설정해야 하는 인터페이스에서 OOP 가 코딩시에 명시해야할 파라미터를 한개만 하고 나머지는 디폴트값을 줄수 있다면(캡슐화라고 얘기하죠) 커널에선 거의 대부분 3개의 파라미터를 항상 다르게 일일이 설정해 줘야 하는경우가 대부분 입니다.
C++ 로 개발이 된 커널이 몇개 있는걸로 아는데, 제가 생각하기에는 리눅스 같은 모놀리식커널은 C++ 이 큰 메리트가 못되고,
마이크로 커널이라면, 순수 커널은 C로 작성하고 나머지 커널 서비스 부분들(파일시스템등등), 서브시스템등은 C++ 로 작성할수도 있겠네요~.
공감~
공감~
..
아예 조금 더 나가서 XML을 쓰는 것은 어떨까요 -_-? 요즘 드라이버 코드를 보다 보면 드라이버 모델 때문에 이름이나 주소 스트링만 바뀌는 경우가 많은 것 같습니다. 뭔가 major, minor number 같은 개념은 잊혀진지 오래인 것 같습니다.
A rose is a rose is a rose..
댓글 달기