- 질문 게시판입니다.
| Date | 19/04/19 19:48:06 |
| Name | 듣보잡3 |
| Subject | C언어 관련 책 추천 부탁드립니다. |
|
"C 기반 개발이 C++ 기반 개발에 비해 갖는 우위들이 [최근] (=2018~19) 시점에서도 아직 존재하는가? 그렇다면 그러한 우위들은 어느 상황에서 유효한가? 그 우위를 최대한 활용하기 위한 테크닉들과 주의점은 무엇인가?" 라는 질문에 "이미 C로 짜져있는 수십만 라인의 코드를 지금 와서 C++로 뜯어고칠 순 없기 때문에" 라는 답 말고 다른 쪽의 상세한 답을 해주는 책을 찾고 있습니다. 고전 명저인 K&R, K&K는 알고 있지만 너무 오래된 책인 것 같고, 인터넷 검색으로 나오는 토막글들은 검증되지 않았거나 현시점에 맞지 않는 경우가 많고 체계적이지 않은 것 같고, cppreference는 자주 활용합니다만 여기는 책보다는 사전에 가까운 곳이라고 생각해서요. 미리 감사드립니다. 0
이 게시판에 등록된 듣보잡3님의 최근 게시물
|
|
이미 읽어보셨겠지만 C++대가께서 이제는 아에 다른언어라고 하신 글이 있습니다..
https://minjang.github.io/2016/03/21/talk-with-stroustrup/
https://minjang.github.io/2016/03/21/talk-with-stroustrup/
몇 년 전에 토발즈에게 누가 왜 커널을 계속 C로 개발하냐고 물어보니, 자기는 C++ 컴파일러의 최적화를 아직 100% 믿지 않는다 라고 대답했던 것 같아요. 결국 C가 경쟁력이 있는 부분은 HW 레벨까지 내려가야 하는 코드들인 것 같습니다.
1~2년쯤 된 단편적인 기억이라 뭐라고 콕 집어서 말하기는 어렵습니다만, 로직을 극한으로 쥐어짜면 심지어는 x86에서도 C가 C++보다 더 뛰어난 성능을 보이긴 합니다. 단지 퍼포먼스를 극한으로 끌어올려야 되는 상황이 아니라면 그 성능 차이를 체감하기 어려운게 현실이죠(일반적인 경우에는 성능 향상이 있다고는 해도 1/1000초 미만...... -_-). 그렇다면 굳이 느끼지도 못할 성능 차이를 위해 C를 쓸 이유가 없습니다. 유지보수가 훨씬 쉬운 다른 환경을 사용하는게 여러모로 이득이죠.
단, 위에서 말씀하신 것처럼 OS는 좀 예외입니다. 여기는 CPU time slice를 위해 소요되는 수 ns의 시간조차 느리다고 뭐라고 하는(-_-; ) 사람들이 모인 곳이고, 실제로 그런 부분들이 쌓이고 쌓이면 OS의 overhead cost가 올라가는 측면이 있으므로, C++보다 C를 선호하는 것으로 알고 있습니다.
단, 위에서 말씀하신 것처럼 OS는 좀 예외입니다. 여기는 CPU time slice를 위해 소요되는 수 ns의 시간조차 느리다고 뭐라고 하는(-_-; ) 사람들이 모인 곳이고, 실제로 그런 부분들이 쌓이고 쌓이면 OS의 overhead cost가 올라가는 측면이 있으므로, C++보다 C를 선호하는 것으로 알고 있습니다.
어셈블리 상으로 보면 c++은 메소드를 찾아가기 위해 virtual관련 처리를 해야해서 점프가 두번 발생하는걸로 알고 있습니다. 메모리 레퍼런스는 캐시됐다고 가정하면 그렇게 큰 문제는 아닐것 같네요.
근데 뭐 임베디드에서 OOP를 빡세게 쓸것 같지도 않고 c랑 다름없는 cpp를 짜게 될것 같은데 굳이 cpp를 고집할 이유가 있나요? 임베디드 깊게 들어가면 어셈블리를 써야되는 대목이 나오는데 아무래도 리눅스 만드는 분들이 해놓은 삽질이 많아서 c가 좀더 자연스러울거에요.
그리고 C도 개발자들 이런저런 언어에서 좋은거 많이 배워와서 매크로 흑마법 개쩔어요. 결국 파일럿이 문제지 언어가 문제는 아닌것 같아요.
근데 뭐 임베디드에서 OOP를 빡세게 쓸것 같지도 않고 c랑 다름없는 cpp를 짜게 될것 같은데 굳이 cpp를 고집할 이유가 있나요? 임베디드 깊게 들어가면 어셈블리를 써야되는 대목이 나오는데 아무래도 리눅스 만드는 분들이 해놓은 삽질이 많아서 c가 좀더 자연스러울거에요.
그리고 C도 개발자들 이런저런 언어에서 좋은거 많이 배워와서 매크로 흑마법 개쩔어요. 결국 파일럿이 문제지 언어가 문제는 아닌것 같아요.
| 목록 |
|
