C 프로그래밍 언어 (C언어의 문제점)
(hut.mearie.org)- 메모리 문제: GC, 정적 분석 등 어떤 도구의 도움을 받지 않음.
- 미정의 동작: 저수준 환경 위주로 쓰이게 되며 최적화의 요구가 많았고 최적화를 위해 미정의 동작이 늘어남. 저수준 성능과 이식성의 두마리 토끼를 잡지 못함.
- 대규모 프로그래밍에 부적합: 모듈, 패키지 관리자의 부재. #pragma once 등의 널리쓰이는 것도 표준이 없음.
좋은 글 공유 감사합니다. 다만 사소하게 의아한 점이 있어 댓글을 남깁니다.
- 아마 처음 작성하신 2011년도에는 없던 것 같지만, 이젠 C 패키지 매니저가 몇개 나왔습니다. Conan도 있고요, MS의 vcpkg도 있습니다. npm에 비해 몇 가지 부족한 점이 있지만(vcpkg는 버전관리가 아직 베타딱지가 붙어있고, conan은 vcpkg보다 자료가 적습니다.) 없던 시절보단 훨씬 좋아졌습니다.
글 쓴 사람입니다(하하...). 현재 사이트는 소프트 릴리스 상태로 실험적으로 글을 작성하고 있는 터라 내용은 지속적으로 수정될 수 있음을 양해 바랍니다. 직접 트래킹도 하고 있지만 이메일로 의견 보내 주시는 것도 받으니 참고해 주세요.
vcpkg는 말씀하신 대로 현재 가장 유망한 패키지 매니저로 보이고, Conan도 사실 꽤 옛날부터 있던 프로젝트입니다(원 작성 시점과 그다지 멀지 않습니다). 하지만 이들 프로젝트의 가장 큰 특징은 스스로는 빌드 시스템이 존재하지 않는 메타 빌드 시스템이라는 것입니다. (주요 지원 타겟인 CMake 자체가 메타 빌드 시스템이라는 걸 생각하면 메타-메타 빌드 시스템일지도...) 따라서 빌드 시스템 자체에서 생기는 문제를 딱히 해결하긴 어렵습니다. vcpkg는 좀 더 고려한 흔적이 보이는데, 예를 들어서 같은 의존성의 다른 버전이 (서로 다른 의존성 경로를 통해) 한 프로젝트에서 필요할 경우 enlistment를 쪼개는 것이 가능합니다만, 이건 빌드 시스템 자체의 한계를 우회하는 방법에 지나지 않지요. 이를테면 Rust와 Cargo는 이 경우 두 버전 모두 빌드해서 한 crate에서 참조하는 데 지장이 없습니다.
또한 vcpkg는 현재 Visual Studio에서는 NuGet 수준의 도구 통합조차 되어 있지 않은 것 같고(오로지 MSBuild 통합만...), 리눅스/BSD 배포판의 패키지 관리자와의 통합도 그다지 되어 있지 않은 것 같습니다. 이 문제는 현재 언어별 패키지 매니저가 직면한 가장 큰 문제이기도 한데 Rust 같은 신생 언어들은 각개격파해서 해결하고 있습니다만, C/C++ 패키지 매니저라면 무조건 기존 시스템과의 통합을 지향해야 할 것인데 그게 아직 지지부진합니다. 이 부분이 해결되고 나서야 비로소 vcpkg 류가 C/C++ 개발에서 보편적으로 사용 가능한 도구가 되었다 할 수 있을 것입니다. 그렇지 않은 것이 제가 글에서 패키지 시스템을 저평가한 주된 이유입니다. (글에서 제시한 single-file library의 범람 또한 vcpkg 류의 시스템이 그렇게 어필하지 못하고 있다는 간접적인 증거이기도 하죠.)
상세한 답변 감사합니다. 하긴 근본이 = ㅁ=.. 빌드라서 npm이나 여타 패키지 매니저와 다르게 따라갈 수 없는 벽이 있겠네요. vcpkg는 버전에 관해 고민이 요즘 많아보이는데, 극복하기가 쉽지 않을 것 같군요.
C++20의 모듈 시스템이 이 문제의 해답이 되지 않을까. 싶기도 하지만... 그러면 범위가 C언어를 넘어버리니(...). C언어는 가시밭길밖에 안 남아있겠네요. 이제와서 C20을 제정한다고 하더라도 C++처럼 버전 전환율이 그렇게 높지는 않을거고..
좋은 의견 감사합니다.
제 개인적인 생각은 이렇습니다. C 패키지 매니저가 몇 개 있는 것은 좋은 현상이지만, 문제는 이런 패키지 매니저가 많이 쓰이지 않는다는 점 같습니다. 좀더 정확히는 이미 C의 레거시가 엄청나기 때문에, 위에서 언급한 문제점을 해결하기엔 너무 멀리 오지 않았나 싶습니다. 그래서 더욱 Rust와 같은 새로운 언어로 옮기려는 시도가 많지 않을까요.
말씀을 듣고 다시 생각해보니 위 패키지 매니저들의 C언어의 생명연장보다는 C언어를 사용해야만 하는 프로그래머의 생명연장에 초점이 맞춰진 것 같습니다.
이제 새로운 집(C++, Rust...)으로 이사해야 할 때 옛날 집에 있던 OpenGL이라던가, Lua 같은 가구들이 필요해질 때, 패키지 매니저가 없으면 손으로 옮겨야 했는데 ( 링킹하고, make하고, DLL이나 lib 버전 안 맞아서 머리가 빠지고... LNK 에러 보다가 뛰어내리고... ) 이젠 패키지 매니저가 있으니 포장이사처럼 깔끔하게 옮길 수 있게 되었죠. 만들어 둔 게 워낙 많으니 새로운 집에서도 써야 할 때도 있을테고...
이젠 언어 자체의 장점보다는 지금까지 싸여온 짬의 메리트가 더 큰 걸 보면 정말 죽어가는 언어라는 게 체감되네여(...
여러모로 Rust 가 next C/C++ 의 이미지를 가장 강하게 가지고 있는 듯 합니다. (next 로 취급되는 몇가지 언어들 중 상대적으로 가장 복잡하다는 이미지도... ㅋㅋ)