C++의 미래는 어떻게 되는가

senah의 이미지

안녕하세요.

보통 *nix 환경에서 C++은 그다지 환영 받는 언어는 아닌 것으로 아는데.. C++ 자체가 워낙 C와의 자료형 호환성에 개체지향 특성에 일반화 프로그래밍 특성까지 이것저것 합쳐져서 속된 말로 '돼지에 다리 8개 붙이고 날개 단..'로도 표현하죠. 제가 C/C++ 개발자이기는 하지만, C++에 대한 이런 평가를 애써 부정하지 않습니다.

제가 느낀 바로는, 순수한 개체 지향 특성만으로 따진다면 C++은 C#이나 자바와 같은 언어의 간결성은 따라가지 못합니다. 개체지향으로 코드를 작성하고자 하면, 다른 언어로는 간단히 표현되는 것도 복잡하게 표현되는게 많죠. 물론 C++은 부족한 부분은 만들어 쓸 수 있긴 하지만..

개인적으로, (개인적입니다. 정말로) 최근 들어 C++에 다시 호감을 가지는 이유는 boost::MPL과 같은 메타 프로그래밍 기법이 크게 발전하고 있고, 초창기 C++에는 곁다리로 느껴졌던 STL에서 도입된 일반화 프로그래밍이 점차 C++의 가장 강력한 특징이 되는 것 같아서 입니다. 어떻게 보면 미래의 C++은 개체 지향 언어라기보다는 일반화 프로그래밍 언어라고 불러야 할지도 모를 정도로요.

그런데, 이런 특징들은 자바나 C#에서 구현되기 난감한 면이 없지 않습니다. 물론, template과 비슷한 기능들은 이들 언어에도 있습니다. 그러나, 이 언어들의 일반화 프로그래밍 기법은 보통 초창기 template이 쓰였던 기법 정도이고, 현대 C++에서 구현하고 있는 고급 TypeTraits와 같은 기법과는 본질적으로 어울리기 힘듭니다. (컴파일 시점에 타입 정보를 파악하기 때문에) Windows에서의 CLR도, C++/CLI에서 template으로 구현한 클래스들은 다른 .NET 개체들과 달리 외부에 노출되기가 불가능하다고 알고 있습니다.

그래서, 어찌보면 세상에서 가장 넓은 사용자층을 가지는 Windows에서는 과거 Win32 API에서의 MFC, ATL/WTL과 같은 C/C++ 방법론은 이제 더이상 유효하지 않게 될 것 같습니다.

과연 C++은 어떻게 될까요? C++은 원체 유닉스에서 그다지 환영 받는 언어는 아니고, Windows 플랫폼에서의 C++/CLI를 살펴보면 관리형 코드와 네이티브 코드를 묶어주는 효과적인 수단이 될 것 같지만, 위에서 말한 template에서의 제한 사항 때문에, Windows에서의 C++은 앞으로의 C++ 발전 방향을 고려해본다면 거의 절름발이 언어가 되지 않을까 합니다. template 부분 특화나 TypeTraits 기능이 불완전한 C++을 쓰느니 차라리 C#을 쓰는게 낫겠다는 생각이 들거든요. 아니, 정확하게 말하면 되기는 하겠지만 .NET 환경에서는 이렇게 구현된 기능들이 외부로 노출되지 않기 때문에 의미가 없다고 하는게 더 맞겠군요.

혹시 이쪽과 관련해서 어떤 좋은 이야기거리를 가지신 분 없나요? 예를 들면 Win64 API 팀에서 MFC와 비견될만한 C/C++ Framework를 만든다는 근거없는 루머라든가.. ;)

/
/
/
/
/
/

*언어 전쟁은 사양. 일거리에 가장 잘 맞는 언어를 선택하면 그게 최고! :)

/
/
/
/

*이 포스트는 토론이 종료된 것으로 생각하고 싶습니다!! 이미 많은 분들께서 충분히 좋은 토론을 해주셨고, 여기에 대한 다른 뉴스가 나오면 그에 맞는 다른 글타래를 생성해서 토론하는게 좋을 것 같습니다.

feanor의 이미지

파이어폭스, 웹킷, 오픈오피스, KDE가 C++로 작성되어 있습니다. C++이 유닉스(내지는 자유 소프트웨어)에서 환영받지 못한다는 근거는 무엇인가요?

senah의 이미지

유닉스 프로그래머들이 하드웨어에 대한 가급적 얇은 레이어를 유지하려고 한다는 경향이 있다는 이야기를 읽었기 때문입니다.

C++가 완전히 비호감이라서 유닉스 세계에서 환영받지 못한다는 뜻이 아니라, 잘 이식되고 간결한 표현을 선호하는 문화에 공룡 같은 C++ 언어는 잘 어울리지 않는다는 뜻입니다. 즉, 예로 드신 GUI 쪽이나, 게임과 같은 프런트엔드 분야를 제외하면 C에 비해서 그렇게 활발하게 시스템 프로그래밍에 적용되고 있지 않다고 알고 있습니다. (Eric Raymond, The Art of Unix Programming)

토발즈가 C++을 'horrible' 하다고 이야기한 것과 조금 비슷한 이야기일까요.

그러고보니 다짜고짜 환영받지 못한다고 쓰는 것보다 좀 더 구체적으로 쓸 걸 그랬네요.

klara의 이미지

시스템 프로그래밍에 안쓰인다고 환영받지 않는다고 하면, 사실상 거의 대부분의 고급언어는 환영못받을 듯한데, C++만 특별할 이유는 없어보이는데요...
반대로 말씀하신 '시스템 프로그래밍' 분야에서, 고급언어중에 C 말고 환영 받는 언어가 있는지 궁금해지네요.

senah의 이미지

확실히 C를 제외하고는 그다지 환영 받는 언어는 없죠.

그런데 C와의 호환성을 해치지 않고 새로운 특징을 부가한 C++이 시스템 프로그래밍의 왕좌를 차지했냐면.. 그것도 아닙니다. 이유는 여러가지 있겠지만 위에서 했던 이야기는 The Art of Unix Programming에서 읽었던 내용이라 제가 다시 쓰기 멋적네요. 저는 C++을 비하하는 것도 아니고, (저는 C/C++ 기반입니다) 이야기가 이쪽으로 흐르는 것은 처음에 제대로 글을 적지 않은 제 실수입니다.

아무튼, 유닉스 쪽에서는 Windows에서의 CLR 환경과 같은 것 위에서 돌아가야 하는게 아니므로 저 역시 유닉스 플랫폼에서 C++의 미래는 어둡게 보지 않습니다. 다른 플랫폼도 그렇게 문제가 될거라고 보지 않습니다. C++ 컴파일러는 많은 플랫폼을 가지는 컴파일러 중 하나니까요. 문제는 가장 많은 사용자층을 가지고 있는 Windows 플랫폼이죠.

아직 제가 C++/CLI을 제대로 이해하고 있지 않지만, 간단히 살펴본 바로는 template 기능이 .NET 환경에서 골칫거리입니다. 순수하게 네이티브 코드로만 작성하면 큰 문제는 없지만, CLR 환경에서는 다음 C++ 표준에서 포함되는 발전 방향을 제대로 살리기 힘듭니다. 그리고 관리되는 코드 / 네이티브 코드에서의 차이점 때문에 가뜩이나 복잡한 C++ 문법이 더욱 복잡해진 것 같습니다. 게다가, Microsoft에서 과거 MFC나 ATL과 같은 C++ 라이브러리를 내놓을 움직임도 딱히 있는 것은 아닙니다. 그래서, Windows 플랫폼에서 C++ 개발자는 어떻게 해야 하는가..라는 고민에서 올린 글입니다. C++ 개발자라는 직함을 유지하기 위해 Microsoft가 자체 확장한 C++/CLI와 전통적인 C++ 모두에 통달하려면 아마 미쳐버릴 겁니다.

그냥 C#이 Windows 환경에서는 가장 잘 맞겠지만, C++을 버리기에는 너무 아까워서 그럽니다.

imyejin의 이미지

C++개발자라는 직함을 가지려면 왜 윈도우즈 프로그래밍을 해야 하는거죠? 리눅스/유닉스에서 C++로만 개발하면서 먹고사는 사람은 C++ 개발자로 안쳐준단 말인데 이 무슨 말도 안되는?

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

senah의 이미지

에고. 앞에 'Windows에서' 라는 말이 빠진 듯 하네요.

제가 가장 많이 다뤄 본 플랫폼이 Windows라서 이런 걱정하는 것이지만, 저는 무슨 플랫폼이 최고다, 어느 언어가 최고다.. 이런 논쟁 싫어하는 사람입니다. 아주 싫어해요.

혹시 제 글이 Windows 플랫폼이 최고다!라는 뜻으로 보였으면 전적으로 제 불찰입니다.

senah의 이미지

후.. 그런데 제가 언제 리눅스/유닉스에서 C++ 개발자들을 C++ 개발자로 쳐주지 않는다고 했던가요.. 말썽많은 .NET과 C++이 잘 맞지 않아서 C++/CLI와 오리지널 C++을 모두 잘 알려면 피곤하다는 이야기만 했을 뿐인데..

가만히 생각해보니 굳이 앞의 댓글을 달지 않아도 제가 그런 식의 이야기를 하려고 했던 것은 아니라는 점은 아실 수 있지 않으신가요..

아무리 조심해도 역시 민감한 사안..

sliver의 이미지

"C++ 개발자라는 직함을 유지하기 위해 Microsoft가 자체 확장한 C++/CLI와 전통적인 C++ 모두에 통달하려면 아마 미쳐버릴 겁니다."
이 부분 때문인 듯 합니다.

semmal의 이미지

윈도즈라도 GPL or LGPL 라이브러리 쓰면 다른 플랫폼과 별 차이 없습니다. 윈도즈에서 밥먹고 살지만 MFC/ATL로 개발 안한지 몇년되어서 말이죠. 유지보수는 가끔 합니다만...
MFC는 버렸지만 C++를 버릴 일은 없을 것 같네요.
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

서지원의 이미지

저도 별로 많이 안쓰이는줄 알았는데, 꽤 쓰이더라구요...

웹킷같은 브라우저 엔진도 C++을 쓰고, HotSpot도 C++로 구현되어 있고... tracemonkey도 C++이고... 다 시스템 프로그램이네요. (웹 브라우저도 요즘은 엄청 거대해져서 거의 os 역할을 하기 때문에 브라우저 시스템이라고 불러도 될 듯..)

senah의 이미지

유닉스는 확실히 개발자들이 뭔가 하기에 너무 좋죠. 문화 자체가 사용자보다는 개발자들이 만든 문화라서 처음에는 조금 불편한듯 보여도 익숙해지면 동일한 메타포로 모든게 표현되어 있어 정말 좋습니다. 그리고 저는 지금까지 유닉스와 친하지 않은 개발 언어를 본 적은 없습니다. :)

C++이 환영받지 못한다는 것은 C++이 버린 자식 취급을 받는다는게 아니라, 공식적으로 C의 후계자임에도 불구하고 C가 누렸던 압도적인 인기를 누리고 있지는 못하다는 뜻도 있습니다.

semmal의 이미지

C++는 공식적인 C의 후계자가 아닙니다. 그저 비슷해보이는(사실 너무나도 다르지만) 언어일 뿐이죠.
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

dudungsil의 이미지

C++로 먹고 살지만 C++의 미래를 밝게 보고 있지는 않습니다. 그 이유가 senah님과는 좀 다르지만요.

C++은 지금도 너무 복잡하고 앞으로 더 복잡해질 예정이죠. 복잡도가 높아져서 생기는 일중에 좋은 일은 없습니다. 가끔 면접에 들어가는데 지금도 C++ 문법으로만 면접보러 온 사람을 좌절시킬 수 있습니다.

Visual Studio같은것도 SP가 나오면 visual c++ 패치 목록이 다른 모든걸 합한것보다 더 많죠. 언젠가 C++은 자신의 복잡함에 묻혀 스스로 쓰러지지 않을까 생각이 듭니다. 하위 호환성을 무시하고 다 잘라버리지 않는다면 말입니다.

ps.
managed에 대해서 말하면 서로 노리는 바가 다르죠. 둘이 그냥 수평으로 계속 갈 수밖에 없습니다.

----
산넘어 산

산넘어 산

senah의 이미지

조금 더 구체적으로 말하면, .NET에서는 C/C++ 개발이 그다지 쓸모 있어 보이지 않습니다. C#도 괜찮은 언어이지만 다른 플랫폼에서도 Windows 플랫폼만큼 힘을 발휘할지 의문이고, 그렇다고 C/C++ 방법론으로 뭘 하자니 상당히 피곤해 보입니다. 이전에는 Visual C++만 할 수 있는 영역이 있었지만, 지금은 그렇게까지 대단한 장점으로 보이지 않는군요. C++/CLI만 할 수 있는 영역이 있다고 하지만 그것은 과도기적인 것이라 보여집니다.

Windows 플랫폼에서 C/C++ 개발자들은 어떻게 움직여야 할지.. 다른 분들은 어떤가요? 다들 C#으로 전환하는 분위기?

semmal의 이미지

말씀하시는 부분은 플랫폼 문제가 아니라 쓰시는 라이브러리 문제라고 보는데요.

C에 대한 호환성과 성능을 유지할 수 있는 C++가 C#이나 자바보다 더 나은 점도 분명하게 있습니다.

그렇지 않다면 trolltech이 팔린게 이상한 일이지요.
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

oomymy의 이미지

약 3년 정도 C++을 이용한 프로젝트(리눅스, 시스템/네트워크 프로그래밍)를 해본 경험을 토대로 한 마디 거들면요. (지극해 개인적인 생각입니다)

일단, C와의 호환성을 가져간 측면에서는 좋은 점수를 주고 싶으나, 여러 프로그래밍 패러다임, 다양한 표현방법등을 죄다 녹여내느라 너무 복잡해진 언어가 아닌가 생각합니다.

특히 senah님이 말씀하신 것 처럼 진화에 진화를 거듭해서 이제는 Generic Programming 언어로 나아가는 C++을 보면 점점 매니아들을 위한 언어가 되어 가고 있는 것이 아닌가 싶은 우려가 들더군요 (개인적으로 Generic programming쪽 책을 짬짬히 보고는 있습니다만, 여전히 어렵더군요.)

즉, C++은 표현의 다양성을 추구하느라 지나치게 복잡해진 면이 있으며, 그것이 너무 다양한 지식을 프로그래머들에게 요구하게 되고, 프로그래밍할 때 수많은 주의사항, 고려사항을 신경쓰도록 하고 있습니다.

오히려 smalltalk의 냄새가 많이 풍기는 Objective C, 그리고 Java와 같은 언어가 언어적 측면에서 봤을 때는 간결성 vs 표현의 다양성에서 적절한 중간점을 찾은 것이 아닌가 생각됩니다.

하지만, 요새 들어서는 생각이 좀 바뀌고 있는게요. (다년간 Java 프로젝트를 하다가 최근 다시 Linux/C프로젝트를 하고 있습니다)

결국 언어는 도구일 뿐이며, 무슨 언어를 가져다 줘도 실력있는 프로그래머들은 간결하면서 가독성 높고 유지보수하기 쉬운 직관적인 코드를 짜내더군요.

imyejin의 이미지

자바에도 이제 제너릭이 들어가 있고요, 또 자바에는 C++에는 없는 리플렉션이나 다이나믹 클래스 로딩이나 여러가지 기능들이 있습니다. 처음 자바를 만들었을 때야 아직 덜 집어넣었으니까 간단하단 이야기가 나왔지 요즘도 자바가 간단하다는 주장을 하는 사람은 거의 없는 걸로 아는데요. 라이브러리가 많고 VM을 많이 포팅해 놓은 걸 장점으로 내세우죠.

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

senah의 이미지

ㅇㅇ 맞습니다. 그러나 아무리 그래도 자바는 끔찍한 C++보다 간단합니다. 그리고 이미 잘 구현되어 돌아가고 있다는 엄청난 장점도 있고요.

다만, 해괴한 C++에 시간을 투자했던 불쌍한 사람들은, 지금 대단히 애매해졌다는 거죠.

oomymy의 이미지

자바 제네릭과 Generic Programming은 다릅니다. Generic Programming은 Template Meta Programming이라고도 불리지요.

자바에 C++과 비슷한 Template이 있다곤 하나 이걸로는 Meta programming을 하기에는 택도 없죠.

그리고 자바가 간다하지 않다고 주장하시는 분들은 이전 자바에 비해 간단하지 않다는 것일 뿐, C++에 비해선 아직도 훨씬 간단합니다.

myueho의 이미지

GP가 TMP를 포함합니다만. GP가 TMP는 아닙니다.

oomymy의 이미지

제가 잘 모르고 둘을 혼용해서 썼군요.

좀 더 자세한 설명을 해주시면 감사드리겠습니다. ^^;

senah의 이미지

메타 프로그래밍을 하는 유일한 방법이 C++ template인 것은 아니지 않나요? generic programming과 meta programming은 조금 다른 것으로 알고 있는데.. C++ meta programming도 우연히 발견된 것이고요. generic programming의 개념을 충실히 구현했다고 하면 아무래도 STL이 가장 대표적이죠. Stepanov도 Ada, Eiffel, Dylan, Java와 같은 언어로 generic programming을 할 수 있을거라고 이야기했고요.

메타 프로그래밍이라는게, 제가 지식이 짧아서 구체적으로 쭉 이야기할 수는 없지만, 컴파일 시점에서 붕어빵 틀처럼 코드를 찍어내도록 지시하는 생성기로 작용하는 특징과 맞물려 우연히 발견되었고 Haskell과 같은 언어의 특징을 조합하면서 많이 연구가 된 것으로 아는데..

자바나 C#의 특성상 이렇게 코드 자체를 찍어내도록 조작하는 meta programming 기법이 힘들어보이기는 하지만.. meta programming을 구현하는게 꼭 generics나 template 같은 것에만 의존하는 것은 아니죠.

oomymy의 이미지

말씀 감사합니다.

Java Generics는 자료구조의 타입 안전성을 위해 추가된 개념이라고 봐도 무방하지 않을까 생각됩니다. 물론 그것만 있는 것은 아니나, C++ template과 같이 코드를 찍어내는 기능을 하는 것이 아니기 때문이죠. 예를 들어 Java Generics를 이용해서 Traits같은 개념을 만들어 보려고 노력했지만, 안 되더군요 (혹시 아시는 분은 답변 부탁드립니다)

아마도 제가 generic programming, meta programming등에 대한 정의를 정확히 모르고 단지 C++ template으로 현란하게(?) 짜놓은 코드들이 Java Generic으로는 안 되는 걸 보고 그렇게 말씀드린 것 같군요.

어느 분께서 좀 정리를 해주셨으면 좋겠습니다.

hongminhee의 이미지

KLDP의 글타래는 아니지만, 다음 글도 읽어보세요. http://langdev.net/post/58

홍민희 (VLAAH, LangDev)

senah의 이미지

요즘은 C++ 개체지향 특성을 이용하는 것보다 메타 코드를 더 적극적으로 활용하는 것에 매료되어 있습니다. 그런 코드들은 template partial specialization을 적극 활용하는데, .NET에서는 이런 template 코드들이 문제입니다. 대신 generics을 활용하라고 하는데, generics는 메타 프로그래밍 활용 정도에 있어서 template과 비할 바가 아니죠.

무엇보다 컴파일 시점에 런타임 시점에서 비용을 지불할 필요없이 대단히 빠른 코드를 생성할 수 있다는 장점이, 실행 시점에서 실제적인 실행 코드를 만드는 자바나 CLR과 본질적으로 잘 맞지 않습니다. 물론, 해묵은 실행 시점에서의 성능 논란은 서로가 분명한 이유가 있으니 여기서는 다루지 않겠습니다. VM을 사용하는 것이 정적인 바이너리를 생성하는 것보다 좀 더 최적화된 코드를 생성할 가능성도 있고, 다른 한편으로는 직접 바이너리 코드를 생성하는 쪽을 선호하는 것도 나름대로 이유가 있으니까요. (이 이야기로 싸우는건 절대 절대 사양..)

다만, 예전의 구조화된 프로그래밍 언어들보다 개체 지향 프로그래밍 언어들이 어떤 문제에 있어서는 좀 더 효과적인 표현력을 자랑했던 것과 마찬가지로, 기존의 순수한 개체 지향 프로그래밍 언어로는 대단히 길고 복잡한 표현이 메타 프로그래밍 기법으로는 대단히 놀랍고 압축적으로 표현할 수 있기 때문에 그렇습니다.

그런데, 가장 널리 쓰이는 플랫폼에서는 정책상의 이유로 잘 지원되지 않고, C++/CLI와 같은 엄청 복잡한 물건만 하나 덜렁 나왔으니, 상당히 아쉬워서 그럽니다.

oomymy의 이미지

전 런타임 vs 컴파일타임으로 말씀드렸던 건 결코 아니고요. 둘 다 나름의 장점이 있다고 생각하기에 잘 판단해서 선택해야 한다는 주의죠.^^;

전 다만 이제는 C++의 언어 진입장벽이 너무 높아져 가는게 아니냐는 걸 우려스럽게 보는 편이라 그런 글을 쓴 겁니다.

아마 보셨으리라 생각됩니다만, 유명한 책 'Modern C++ Design'을 봐도 이게 C++인지, C++을 기반으로 한 새로운 언어인지 모를 정도로 현란(?)하죠.

그런 메타프로그래밍(자꾸 용어를 바꿔써서 죄송합니다. Java Generics와 혼동을 막기 위해 바꿨습니다)으로 짠 코드가 잘만 설계되어 있다면 말씀하신 대로 정말 놀랍고 압축적이며, 재사용성 높은 코드를 만들어 낼 수 있죠. (저도 그에 매료되어서 열심히 책을 봤습니다.)

하지만, 여전히 그 진입장벽이 높다는 점에는 많은 분들이 동감하시리라 생각합니다. 메타프로그래밍, 템플릿 관련 책 조금 봤다고 해서는 거의 '범접'하기 힘들 정도로 그쪽으로 경험이 많지 않은 한 메타프로그래밍을 자유자재로 구사하기는 상당히 힘들지 않을까 생각합니다. (제 내공이 낮아서 그런 것일수도 있죠 ^^;)

youlsa의 이미지

C++는 UI용 툴킷 비슷한걸 만들때에는 여전히 제일 좋은 것 같습니다.
눈에 보이는 UI 요소들을 그대로 객체로 표현하면 깔끔하기도 하고요, 저수준 언어의 특징도 어느 정도 포함하고 있어 퍼포먼스도 그럭저럭 괜찮고요.

다만, 실무에 들어가서 "XXX라는 목표를 이루자!"라는 시점에서 C++는 각종 해법을 찾는 방향성을 잃게 하는 경우가 종종 있는 것 같습니다. 절차적으로 해결을 해야 수월한 경우도 있고 객체적으로 해결을 해야 좋은 문제가 있는데요, C++의 경우에는 C++ 자체의 카리스마(?)에 의해 좀 일을 오리무중으로 만들 수가 있는 것 같습니다. 물론 객사파(객체사상파) 사람들의 얘기로는 "너의 수양(또는 믿음 ^^)이 부족해서 그래"라고 하지만요...

어쨌거나 근래 들어 C++의 입지가 조금 애매모호한 것 같기는 합니다.

=-=-=-=-=-=-=-=-=
http://youlsa.com

=-=-=-=-=-=-=-=-=
http://youlsa.com

winterprincess의 이미지

전 커널 모듈을 개발중이지만...
C++은 전혀... 이용하지 않게 됩니다.
예전 MFC할때 잠깐 한거 외엔... (그것도 윈도우잖습니까...)
JAVA는 아예 손도 안댔기에 어떤 언어인지 조차도 모릅니다만...

리눅스 오픈 소스에서 C++이 많이 배제되어 있다는 느낌을 받습니다. 특히 시스템 쪽은 심하죠..
그래도 nateon이라던가 기타 KDE같은 경우엔 C++로 사용하잖습니까...

윈도우 플랫폼.NET에서는 C#이 압도적이라는걸 느낍니다.
참 간결하지 않습니까?
저도 얼마 공부하지 않아 조금 밖에 모릅니다만 정말 간결하고 쉽고 빠르게 코딩할 수 있는 언어라는 점에서 마음에 들었습니다.

얼마전 2006년 개발자 사용 언어 현황을 본적이 있었는데,
퍼센트는 잘 기억 안나지만 JAVA가 압도적으로 많이 있더군요.
하지만 C/C++을 합치면 JAVA보다 약 1.5배 많이 사용하는 것으로 기억됩니다.
아직은 C 뒤에 C++이 있어 아직은 C++로 개발하는 분들이 많은 것으로 보입니다. (물론 3년전 자료지만 말이죠;;)

오직 겨울 공주를 위하여.

-----------------------------------------------------------------------------------

오직 겨울 공주를 위하여.

beebee의 이미지

MS 도 C++ 을 버릴려고 하는듯 보입니다.

현재 C#에만 올린 하는듯 보이고요.

일단 MFC나 C++ 로 만든 dll 들을 닷넷에서 직접 불러오지 못하고요..

C스타일로 재컴파일 해야 한답니다.

그리고 새로나온 VC++ 2009는 MFC가 두배정도로 늘어나고 복잡해졌다고도 하고요..

VC++ 6 사용자들을 버리고 간다는 느낌입니다.

삼성멀티캠퍼스 강사가 그러더군요 MS는 어렵고 복잡한 C++을 버리려고 한다고요.

내 혼에 불을 놓아 ..

beebee의 이미지

MS 도 C++ 을 버릴려고 하는듯 보입니다.

현재 C#에만 올린 하는듯 보이고요.

일단 MFC나 C++ 로 만든 dll 들을 닷넷에서 직접 불러오지 못하고요..

C스타일로 재컴파일 해야 한답니다.

그리고 새로나온 VC++ 2009는 MFC가 두배정도로 늘어나고 복잡해졌다고도 하고요..

VC++ 6 사용자들을 버리고 간다는 느낌입니다.

삼성멀티캠퍼스 강사가 그러더군요 MS는 어렵고 복잡한 C++을 버리려고 한다고요.

내 혼에 불을 놓아 ..

ifree의 이미지

MS가 C++ 을 버린다니 어처구니 없는 소릴 듣네요.

당장 Visual Studio 2010 에서 멀티 쓰레딩을 위한 C++ 라이브러리의 보강이라던가, 복잡한 C++ 프로그래밍의 지원 도구 등을 보면 C# 못지 않게 신경을 쓴 것을 알 수 있습니다.

C++ 의 입지가 축소되기는 하겠지만 상당기간 필수불가결한 언어로 남아 있을것으로 생각합니다.

mirheekl의 이미지

가급적 높은 퍼포먼스를 꾀하면서 어느정도 개체지향도 노릴 수 있는 게 C++말고 또 있는지 궁금합니다.
(물론 특정상황에서 C++로 직접 프로그래밍을 하는것보단 준비되어있는 라이브러리를 사용하는 타 언어가 더 퍼포먼스가 나을 가능성도 있겠지요. 그냥 일반적인 상황 얘깁니다.) 오브젝트C라는게 비슷한 성격인것 같습니다만 직접 써보지 않아서 뭐라고 말씀은 못드리겠습니다.^^;; 그놈의 퍼포먼스가 C++에 전혀 뒤지지않고 시스템프로그래밍에 결격사유가 없다면, 당연히 C++을 대체할 가능성이 있겠지요. C++/CLI라는 것도 마찬가지고요. C와 근접한 수준의 네이티브함을 유지하면서 개체지향 기능이 있는 언어라면 그놈의 이름이 무엇이든지간에 그냥 C++와 동일하게 봐도 된다고 생각합니다. 딱 현재 쓰이는 C++자체가 계속 유지될거냐 물어본다면야 답하기 힘들겠지요. ㅎㅎ 다만 이러한 성격을 가진 언어 자체를 통틀어 말하고 싶은 것입니다.

반대로 퍼포먼스보다 개체지향이나 기타 설계, 빠른 개발속도, 관리 부분 등에 더 중점을 둔다면야 이제는 대체할 게 많겠지요. 이것이 C++이 과거 C처럼 인기를 끌지 못하는 이유인것 같고요. 옛날에는 하도 시스템이 느려서 퍼포먼스가 무조건 최우선 미덕이었고 타언어와의 속도차이도 엄청났는데, 지금은 하드웨어의 발달로 일부 시스템프로그래밍 이외에는 굳이 그런 극한의 퍼포먼스를 찾아야 할 분야가 많이 줄어든 듯 합니다. 혹시 하드웨어가 더 발달하면 이게 "0%"까지 내려갈 수 있을까요? 만약 그렇다면, C++도 사장되는 날이 오겠지만, 저로서는 그렇게까지는 상상을 못하겠습니다. "유닉스에서는 C만 갖고도 시스템프로그램 잘만 하고 있지 않느냐"하시면.. 글쎄요. 제 업무만 봐도 C로만 작업하라고 하면 차라리 속도를 희생하고 다른 언어를 쓰고 말지 C로는 안짜겠습니다. 능력문제일수도 있지만, 프로젝트의 목적이나 설계방식에 더 좌우되는 문제라고 생각합니다.

제 생각엔, C++이 사라지지는 않고, 지금처럼 각종 다른 언어와 연계하는 방법과, 귀찮거나 버그가 잘 발생할 만한 부분들을 해결하는 각종 기법들이 계속 발달하리라 봅니다. 앞서 말씀드렸듯, C++특유의 장점을 대체할 만한 것이 저는 아직 없다고 생각하거든요. 클라이언트 프로그래밍만 하려고 C++을 배우셨다면야 입지가 애매해졌을수도 있겠지만, 그런 분들은 아마 벌써 다른 언어 다 배워서 함께 실무에 적용하고 계실 겁니다. 전부 다 어느정도 관계가 있는 것들이라, 옮겨가는게 그닥 어렵지는 않으니까 말이죠.

그리고 MFC하고는 관계없는 문제라고 봅니다. MFC야 뭐 태생부터 한계가 있던 것이라.

--
This is for you new people. I have just one rule :
Everyone fights, no one quits. If you don't do your job, I'll shoot you myself. Do you get me?

--

senah의 이미지

하긴.. 기괴한 C++/CLI에 시간 투자하는 것보다는 그 플랫폼에 맞는 깔끔한 언어로 새로 작성하는게 더 낫긴 하죠.

그리고 MFC? 으음? 제가 이 문제와 MFC를 연관지었었나요? ;)

mirheekl의 이미지

다른 분들이 하신 얘기에 대한 내용이었습니다~ 제 포스트 자체가 senah님의 원문에 대해서만 작성한 것이 아닙니다. 혼란을 끼쳐드려 죄송합니다.^^

--
This is for you new people. I have just one rule :
Everyone fights, no one quits. If you don't do your job, I'll shoot you myself. Do you get me?

--

NN의 이미지

POSIX 기반(여기선 이 용어를 unix & linux를 통칭하는 용어로 쓰겠습니다.) 의 C++로 만든 응용 프로그램들이 있다는것과 C++의 철학이 POSIX 철학과 일관된다는건 별개의 얘기입니다. senah님은 후자를 언급하신것인데 몇몇 분들이 전자를 언급하면서 여기에 지나치게 민감하게 반응하는것 같네요.

어쨋든 C++의 "크고 복잡한" 특성이 유닉스의 철학과 맞질 않는다는건 이미 잘 알려진 사실이죠.

그러나 저는 senah님이 관심을 갖는 부분과는 다른 영역에 방점을 찍고 있습니다. 과거에는 랭귀지가 큰 힘을 발휘했지만 이제는 플랫폼 vs 랭귀지 전쟁에서 플랫폼이 랭귀지를 이끌고 있는 양상이란 말이죠. 그래서 C++이 어떻게 변해갈것인가..혹은 그 위상이 어떨것인가 하는건 C++이라는 단일 랭귀지차원의 문제가 아니라 각 플랫폼간의 경쟁과 거기에 참여하는 다양한 참가자들간의 게임이 중요한 결정 요인이 될거라는 생각입니다. senah님도 이 부분을 언급하고 계시지만 논의의 방점을 "C++"에 찍고 있어서 상대적으로 이 부분이 부각되어 있지는 않아보입니다.

이러저러한 이유로 저는 특정 랭귀지가 시대를 이끌어간다는 생각을 포기하는것이 현재 보다 적응적인 개발자로 살아남는 비법이라고 생각합니다. 좀 더 비관적으로는, 시간이 지나면서 점차 랭귀지는 플랫폼의 하수인으로 전락해간다는 생각을 하게 됩니다.

senah의 이미지

플랫폼이 언어를 이끈다라.. 조엘 온 소프트웨어를 읽어보면, Microsoft 정도면 중력을 만들 수 있는 회사라고 언급하고 있습니다. 만약 Microsoft가 아닌 다른 회사가 .NET과 같은 비슷한 물건을 만들고, (예를 들어) D#이 대세입니다!라고 주장한다면 조금 이야기가 다르겠죠. 여튼 Microsoft의 Windows 플랫폼이 꽤나 많이 퍼져 있으니 '플랫폼이 언어를 이끈다'는 것은 무리가 없어 보입니다. (제가 다른 플랫폼 무시하는게 아닙니다. 그냥 수치로만 받아들이자구요, 수치로만. 물론 개발이란게 숫자로만 측정할 수 없는 것이지만, 주먹구구식으로)

그러고보면 멀티플랫폼을 뛰어야 하는 프로그래머는 한 층 더 피곤한 삶을 살지도 모르겠군요..

ifree의 이미지

+

jachin의 이미지

저로서는 C++이 C만큼 일반화되지 않을까 생각합니다.

Qt 라이브러리도 있지만,
Application Software에
적합한 구조로 일반화하지 않을까 생각합니다.
====
하나는 전부, 전부는 하나

yielding의 이미지

제가 예전에 모 생명보험 회사의 PM과 코볼에 대해 이야기를 할 기회가 있었습니다. 메인프레임에서도 C/C++가 아주 깔끔하게 잘 돌아가는데 왜 코볼을 아직 계속 쓰냐고.. 선배 말씀이 잘돌아가는 천만 라인 이상의 코볼 코드를 수백억 넘게 들여서 만들어놨는데 단순히 코볼이라는 이유로 C++로 포팅하는게 현실적으로 의미가 없다고 하시더군요. 같은 이유가 C++에도 적용된다고 봅니다.

C++이 성공할 수 있었던 결정적인 이유 중 하나가, 완벽하지는 않지만, C와의 하위 호환성 이지요. D의 경우는 C++의 성공요인을 잘 분석했다고 봅니다. 언젠가 C++처럼 어떤 순간에 모멘텀을 받아서 크게 사용자를 늘릴 수 생각이 들기도 합니다.(C++ 커뮤니티에서 나름 유명한 Andrei Alexsandrescu 이 친구가 D언어에서 활약을하고 있더군요)

C++의 가장 논란이 되는 문제점은 복잡함인데, 이 복잡함을 사랑하고 즐기는 사람과 (boost, C++0x등의 방향) 이게 지저분하고 싫다고 느끼는 사람들의 논란은 계속될듯합니다.

Life rushes on, we are distracted

Scarecrow의 이미지

C/C++은 요즘 인기있는 언어들(C#, Java, Python, Ruby, ...)과 달리
모든 걸 compile time에 해내려합니다. 그리고 그렇게 합니다.

물론 C++도 dynamic이 필요한 부분에서는
그런 요소를 사용하지만 되도록 최소화하려는 느낌이 강합니다.
그래서 C++은 다른 객체지향 언어와 달리 reflection같은 기능이 없습니다.

이것을 C++의 단점이라고 주장할 수도 있겠지만
오히려 장점이자 특색이라고 볼 수 있습니다.
성능적인 측면에서 매우 잇점이 있기 때문입니다.
아마도 C++의 미래 역시 이런 특화를 유지하리라 봅니다.

그리고 원글에서는 C++보다는 C++/CLI를 고려하는 느낌인데...
C++과 C++/CLI는 다른 언어라고 생각합니다.
또한 C++/CLI는 CLI의 dynamic한 부분을 적극적으로 사용하고 있습니다.

한 예로 Boost의 TypeTraits은 compile time에 이뤄지지만
C++/CLI의 TypeTraits은 dynamic입니다.

senah의 이미지

예, C++과 C++/CLI는 서로 다른 언어라고 생각하고 있습니다. 문제는 C++/CLI가 C++의 복잡함에 CLR 환경까지 고려해야 하기 때문에 한층 더 복잡해진 반면, 표준 C++에 따라, 특히 템플릿 코드를 적극 이용한 코드를 작성했을때 .NET 환경에서 커다란 이점이 없기 때문입니다.

그러니까 플랫폼에 상관없이 표준대로 C++ 코드를 작성했을 때 어디서나 같은 결과를 얻기를 원하지만 Windows 환경에서는 이게 쉽지 않다는 뜻이죠. 그렇다고 C++/CLI에 맞춰주자니 동일한 코드 베이스를 유지하기 힘들어집니다. 더구나 가장 많은 사용자층을 가진 플랫폼에서 문제가 이렇다면 C++ 앞날이 결코 순탄치 않다는 생각이 들어서 이런 토론 주제를 올린 것입니다.

가급적이면 표준 C++ 코드가 .NET 환경에서도 그대로 먹혔으면 하는 바램이 큽니다. (특히 템플릿 기능을 적극 활용한 코드로 만들어진 .NET 개체를 외부에서 사용할 수 있다면 더 바랄 나위가 없지만) 가장 좋은 것은 MS가 .NET과 별개로 오래된 MFC를 대체하는 Windows C++ 라이브러리를 만들어주는 것이지만 이건 현실성 0에 수렴하는 이야기이고, WTL과 같은 것만 바라봐야 하는 입장이 답답하기 그지없죠.. WTL 엄청 괜찮은 라이브러리임에도 불구하고 공식적으로 지원하는게 아니다보니..

istree의 이미지

다른건 몰라도 자바에서 제일 부러운점이 import 입니다.

제가 아직 잘 못해서 그러는지 include로 하면 좀 꼬일때도 있고 깔끔하지 않을때도 있고 그렇습니다.

C++도 비슷한걸 지원해줬으면 하는 바램입니다.

반복문 쓸때 좀 더 깔끔하게 코딩할수 있는 문법을 추가했으면 하고 STL에서 가비지컬렉터 같은걸 지원해줬으면 좋겠습니다.

앞으로 어셈처럼 점점 사용자가 줄어들어서 특정분야에서만 쓰이게 될것같다는 것이 개인적인 의견입니다.

뭐 어떤 언어의 VM같은걸 만든다던가.. OS를 만든다던가.. 그런용도로 계속 쓰일듯 합니다.

-------------------------------------------------------------------------------------------
너의(yours) 프로그램 : 똑똑한체하는 트릭과 부적절한 주석이 넘치는 혼란 그자체.

나의(my) 프로그램 : 간결하며 효율적인 측면과 다음 개발자들을 위해서 완벽하게 주석을 단 최고로 균형잡힌 정교한 코드의 결정체

- Stan Kelly-Bootle

너의(yours) 프로그램 : 똑똑한체하는 트릭과 부적절한 주석이 넘치는 혼란 그자체.

나의(my) 프로그램 : 간결하며 효율적인 측면과 다음 개발자들을 위해서 완벽하게 주석을 단 최고로 균형잡힌 정교한 코드의 결정체

- Stan Kelly-Bootle

Scarecrow의 이미지

Quote:
반복문 쓸때 좀 더 깔끔하게 코딩할수 있는 문법을 추가했으면 하고

http://en.wikipedia.org/wiki/C%2B%2B0x#Range-based_for-loop

Quote:
STL에서 가비지컬렉터 같은걸 지원해줬으면 좋겠습니다.

http://en.wikipedia.org/wiki/C%2B%2B0x#Transparent_garbage_collection
또한 tr1이 라이브러리에 포함되었으므로
std::tr1:shared_ptr같은 스마트포인터를 사용하면 효과를 볼 수 있습니다.

C++의 미래라면 당연히 C++0x에 관한 내용이어야 할텐데...
글이 C++/CLI쪽으로 얘기를 하고 있어 이런 얘기는 나오지 않는 듯 합니다.

senah의 이미지

그러니까 C++0x의 발전 방향과 C++/CLI과 서로 동떨어져 간다는거죠. 가장 많은 사용자층을 가지는 플랫폼에서 C++은 좀 어정쩡하게 되어버리니 문제 아니겠습니까.

std::tr1에서 추가되는 boost 라이브러리들은 템플릿의 특징을 활용하여 구현된 경우가 많은데, 이렇게 템플릿을 적극 활용한 코드들은 .NET 환경에서 제대로 외부로 노출되지 않으니 답답한거죠. C++은 앞으로도 발전하고 넓리 사용될 언어지만, 대중적인 플랫폼에서 C#에 밀리다보면 그야말로 희귀 언어가 되어버리지 않을까 염려하는 겁니다.

위에서도 썼지만 여튼 윈도우 플랫폼이 가장 말썽..

Scarecrow의 이미지

자바 플랫폼이 널리 쓰인다고 해서 C++ 개발자가 JNI까지 걱정해야 하는 것인지 이유를 잘 모르겠습니다.

C++/CLI야 자바의 JNI같은 역할이 주목적일테고
더군다나 그것은 라이브러리형태도 아니고
문법적인 요소까지 추가되면서 C++과는 비슷하게 생긴 다른 언어죠.

템플릿을 적극 활용한 코드들은 .NET 환경에서 제대로 외부로 노출되지 않으니 답답할 필요도 없어보입니다.
C++의 기존 라이브러리도 활용이 가능할뿐이지 결국은 다른 언어니까 말이죠.

semmal의 이미지

Windows에서 C++로 먹고 살고 있는 입장에서 전혀 동감할 수가 없네요.
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

loias의 이미지

요즘 인기있는 perl / python / ruby 같은 스크립트언어들이랑 비교했을때.

C++은 좀 무거운것 같습니다. 모든것을 컴파일타임에 하다보니.

유연성도 떨어지는 것 같기도 하고, 복잡하고,

위에 어느분 말마따나 GUI를 표현하기위해서 빼고는 사실 크게 의미가 없는 듯합니다.

OOP라는 패러다임 조차도 의문을 가지는 시대입니다.

정말로 OOP라는게 필요한가요??

LISP에서 나오는 list processing, reference의 파생버젼이 아닐까도 생각을 해봅니다.

vacancy의 이미지


어떤 언어가 오래 살아남으려면
다른 신생 언어가 대신하기 어려운 무언가가 있어야한다고 보는데요.
Java, C# 등 최근 잘나가는 신생 언어들이
가장 대체하기 쉬운 자리가 C++의 자리가 아닌가 싶습니다.
( 사실 각종 언어 순위 사이트를 보면 Java가 이미 C++를 앞지른지 오래죠. )

C++에만 있는, 개발자에게 아주 중요한 기능이 제가 보기엔 딱히 없어서요.
OOP가 가능한, 그리고 VM 위에서 돌아가지 않는
남들이 많이 쓰는 컴파일러 구현이 필요하다, 정도랄까요 ?
사실 이건 언어 자체의의 장점이라고 보기는 어려운데다가
시스템이 빨라지고 VM의 성능이 올라갈수록 중요하지 않은 문제가 되어가겠죠.

C++로 개발도 좀 했었지만 (여전히 종종 하고요.)
요즘은 Java나 C#으로 개발하는게 아무래도 편하게 느껴지고
에러 메세지 이해하기도 쉽고-_- 생산성도 더 높은 것 같고;
플랫폼 라이브러리의 지원을 받는 것도 즐겁고 그렇네요.
자잘한 것까지 신경쓰는 게 점점 귀찮아져서요. ;; 안그래도 짤 게 많은데 ..
( STL도 방대하긴 하지만 왠지 쓰면서 찝찝할 때가 있더군요. -_-; )

이제는 스펙도 점차 복잡해져가고,
심지어 C++의 표준을 전부 따르는 컴파일러 구현을 찾기도 힘들고 하니
( gcc만해도 .. http://gcc.gnu.org/gcc-4.5/cxx0x_status.html .. 아직이죠. )
과연 C++가 언제까지 살아남을 수 있을까, 하는 생각만 듭니다.

C++이 아직 죽지는 않았지만, 코볼처럼 되는 데 긴 시간이 걸리지는 않을 것 같네요.
C는 유닉스가 있는 한 살아남겠지만요.

klara의 이미지

Quote:
가장 대체하기 쉬운 자리가 C++의 자리가 아닌가 싶습니다.
( 사실 각종 언어 순위 사이트를 보면 Java가 이미 C++를 앞지른지 오래죠. )

전반적으로 많은 순위 사이트에서 Java가 C++보다 높다는 것은 인정합니다.
'순위가 높다 = 대체하였다'는 아닙니다. 정말로 Java가 C++을 대체하였다고 생각하시나요?
Java가 서버사이드에서 맹활약중인건 알고 있습니다.
하지만 데스크탑용 어플리케이션에서 Java랑 C++이랑 비교해도 Java가 C++을 대체할수 있나요?
제가 경험이 적어서 그런지 모르겠지만, C++로 만든 어플리케이션은 많이 봐도, Java로 만든 어플리케이션은 비교가 안될정도로 적습니다.
저는 경험만 이야기해놓고 뭐합니다만, 혹시 관련된 자료 알고 계신거 있으시면 알려주시면 감사하겠습니다.

Quote:
심지어 C++의 표준을 전부 따르는 컴파일러 구현을 찾기도 힘들고 하니
( gcc만해도 .. http://gcc.gnu.org/gcc-4.5/cxx0x_status.html .. 아직이죠. )

이 링크는 무슨 뜻으로 달으신건가요?
표준을 따르는 컴파일러 구현을 찾기 어렵다고 하시고, 링크는 표준도 아닌 내용의 지원에 대한 거네요.
vacancy의 이미지

서버 시장에서는 기존에 C++이 별로 쓰이지 않았나보네요 ?
제가 알기로는 기존에 C++가 서버 시장에서도 많이 쓰인 것으로 아는데요.
서버 시장에서의 대체는 대체가 아닌가요 ? -_-a
제가 보기엔 데스크탑에서 아직이니 아직이다, 라고 생각하시는 게 이상합니다.
서버 시장에서 대체되고 있는 데는 이유가 있는 것이 아닌가요 ?
그리고 제가 알기로 서버 시장 외에 모바일 시장에서도
Java가 꽤 많이 사용되고 있는 것으로 압니다.
이 역시 예전에는 C++이 많이 사용되는 분야였겠죠.

해당 링크는 어제 밤에 쓰다보니 별 생각없이 찾다가 잘못 찾은 것 같네요.
최종 표준을 C++03으로 기억하고 있었어서 저기 해당되는 줄 알았나봅니다.
죄송하고요. 링크는 무시해주시면 되겠습니다.

하지만 현재 gcc조차 C++03(C++98)를 전부 포함하고 있지 않은 것으로 압니다.
표준 나온지 10년이 다 되어가는데도요. (그 전에 draft 공개된 기간도 꽤 길었겠죠.)
제가 아는 한은 Intel 컴파일러도 아직이고요. (지원이 시작된 것도 오래되지 않았고요.)
MS Visual C++도 마찬가지인 것으로 압니다.
제가 본지는 좀 됐지만 검색해보시면 쉽게 찾으실 수 있을 겁니다.

지리즈의 이미지

VM에서 실행되는 언어와 바이너리의 간극이 줄어 들면...
확실히 C++이 타격을 입을 것 같긴 하네요.

하지만, 제 생각에는 그래도 C++이 장수할 것 같은 생각이...
C를 같이 쓸 수 있다는 점때문입니다.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.