C++은 C의 확장?

처음에 구현한 언어가 중요한 것이 아닙니다. 현재의 C언어가 C++의 subset이 되지 못한다는 것이 중요합니다.

문자열상수와 struct, const를 다루어보겠습니다.

int가 2byte인 시스템에서 int x='hi'는 c에서는 맞는 말입니다. 문자열 상수도 c언어에서는 int형으로 정의되어 있습니다. 'hi'와 "hi"는 다릅니다. 하나는 int형의 크기이고 하나는 3byte이지요. c에서 문자열 상수는 int형의 자료를 표현하는 용도를 같이 가지기 때문입니다. 반면에 c++에서는 char형은 1 bye입니다. 당연하듯이 c++에서는 trucate해버립니다. 위에서 말했든 "hi"로 'hi'를 대체할수 없습니다. 더 비싼 비용 또는 코드의 변경이 필요합니다.

struct move {
  struct position {
    int m;
  };
};

struct move gundam; // c, c++
move gundam; //c++
struct position man; //c
move:position man; //c++

c++유저들이 많이 쓰는 형태인 struct,class의 생략형은 당연히 호완되지 않고 중첩된 struct는 완벽하게 호완되지 않습니다. 이런 경우가 드물게 나타난다면 아래의 소스를 참고 하십시요.

int nice = 50;

int main(void)
{
  struct nice
  {
    int cn;
  };
  nice = 40;
  return EXIT_SUCCESS;
}

이 코드는 c언어에서는 정확한 코드입니다. 하지만 c++에서는 아닙니다. c언어에서는 당연히 nice라는 것은 tag입니다만 c++에서는 class의 명칭과 같은 namespace를 먹는 object의 이름이 되어버립니다. c와 c++은 충분히 다른세계입니다. c++에서의 struct는 디폴트가 public인 class일뿐입니다. 많은 프로그래머들이 private가 필요하지 않은 클래스 구현을 위해서 struct를 사용합니다.

상수 수식과 lvalue정의가 c와 c++은 다르게 정의되어 있고 그래서 const의 구현이 다르게 되어있습니다. 모습과 역활이 비슷해도 다른 방법을 통해서 구현이 되어 있는 것입니다. lvalue도 c언어에서는 좌변값이 아니라 locate value입니다. 구현이 달라서 다르게 먹히는 예로서는 const를 먹힌 int로 배열을 정의해보면 알수가 있습니다.

템플릿 같은 것을 도입한다면 언어의 형식은 늘어나서 표현력은 늘어나게 되지만 컴파일러든 프리프로세서든 자료형에 맞춰서 함수와 클래스를 몇개 더 만들어 주면 되는 문제입니다. VM이나 컴파일러의 구조적인 변경없이 기능을 향상시킬수 있다면 표현력의 방향이나 VM과 컴파일러의 안정성의 측면이나 환영받을 수 있습니다. 하지만 C++은 C컴파일러의 구조적인 변화 없이 불가능하고 난해합니다. c++의 export와 같은 키워드는 Bobby Schmid가 장문의 글로 악평을 할만큼 좋지 못합니다.

C++의 패러다임이 명확했다면 vc++도 표준을 지켰을겁니다. 현재는 gcc조차도 지키지 못하고 있습니다.

PS: 김재우씨의 이름을 잘못적어서 중간에 수정을 했습니다. 죄송합니다.

C++에서 자부심을 느낄만한 특징은 템플릿이 전부라고 생각합니다. 나머지는 다소 다루기 힘든 ... 괴물같다고 할까요?

개인적으로 C에 템플릿만 추가된다면, 시스템 프로그래머는 더이상 바랄것이 없을것 같습니다.

기본적인 입장에서 차이가 있네요. mastercho님은 사용자는 실수를 안한다는 가정을 하신듯 하구요, 반대의견은 그 가정자체에 문제가 있다는것이네요. 누가 맞다 틀리다 할 문제가 아닌것 같네요. 별도로 주제를 만든다 하더라도 의미없는 토론이 될것 같습니다. 아마 이정도까지만 봐도, 각자 알아서 판단을 할 수 있을것 같습니다.

다른 얘기는 이제 그만하지요. :)
토론 주제와 다른 얘기를 떠들어서 죄송합니다. :oops:

jj님의 말씀이 옳다고 다시 말해서 mastercho님이 사용자는 실수를 안한다고 가정하시고 말씀하신다면 딱히 할말이 없군요. 그러나 실수를 안할 수는 없는 일이고 실수를 하지 않더라도 불필요하게 고려할 사항이 발생하는 것이 C++이라는 언어의 특징입니다.

ps. 저도 C++을 공부하는 입장입니다. 앞으로도 계속 공부할 생각입니다. 사실 저에게 프로그래밍이 무엇인지 알려준 형에게도 C++도 할것을 권할정도로 필요성은 인식합니다. 하지만 좀더 개선된 컴파일 가능한 객체지향 언어가 있었으면 하는 바램입니다.

논쟁의 주제가 몬지는 잘 모르겠지만서두요..

본 토론이 분리되어 주제가 C++이 C의 확장이냐 논의는 별로 할 필요가 없을것 같습니다.

결론적으로 말해서 C++은 C의 확장이기 때문입니다.

어차피 C++ 언어를 만든사람 ( Stroustrap )의 책내용에서 Historical Note에 보면 C++은 C with Class로 처음에 불려졌으며 추후 C++로 부르게 된이유가 C에서 기능을 더한 + 결국 C+로 부르려다가 C+라는게 C에서 syntax error이기때문에 C++로 하였고...

D가 아닌 C++로 부른 이유는 C의 확장이기때문이다.. 라고 나왔있습니다..

추후 계속 읽어보면 결국 C++의 기본 언어로 C를 택한 이유도 나와있습니다..

그러니 결국 C++이 C의 확장이니 아니니의 논란은 할 필요가 없을것 같습니다.

만약 확장이 아니라면 C++만든사람이 상당히 우울할듯 보입니다. ^^;

글쎄요.. 저는 hangulee님께서 말씀하시는 c++의 위험요소란 것은 결국 c++이 갖는 범용성의 반대급부라고 이해되는되요.. 이를테면 C 스타일의 코드와 c++ 스타일의 코드가 혼재될 수 있고, 또 한 프로젝트 내에서도 사람에 따라 코딩 스타일이 많이 달라져서 유지보수가 어려울 수 있다는 것, 이런 것은 바꿔 말해 C++이 그만큼 C로 된 기존의 API도 잘 지원하고, 여러가지 프로그래밍 패러다임을 지원한다는 뜻이 아닐까요?

애초에 기존의 C legacy 코드들이나 OOP, Generic Programming등 다양한 프로그래밍 패러다임을 지원하는 것을 목표로 설계된 언어에 대해, 여러 스타일들이 섞일 수 있으므로 위험하다..고 치부하는 건 좀 곤란하다고 봅니다. 그러한 C++의 특성은 개발자/프로젝트 관리자의 역량에 따라 빛을 발하는 장점이 될 수도 있고 치명적인 실패를 초래하는 단점이 될 수도 있는 것이겠지요. 예로 드신 malloc과 new의 혼용은 조금이라도 마인드가 있는 개발자라면 충분히 피할 수 있는 문제이고, 팀원 간 코딩 스타일이 상이한 것은 적절한 코딩 규약의 도입으로 충분히 해결될 수 있는 문제이지, 결코 다른 언어로 대체되어야만 할만큼 심각한 결함인 것 같지는 않습니다.

물론 Smalltalk, Java와 같은 단일 패러다임 언어들이나 ML, Eiffel등의 훌륭한 언어들은 그러한 추가적인 관리비용이 적게 들고 개발자의 학습곡선도 효율적이겠지만 C++은 나름대로 그런 언어들이 넘볼 수 없는 장점을 가지고 있으니까요.. C 이외에 C++만큼 기존의 방대한 C API들을 잘 지원하는 언어는 없잖습니까?

hangulee님께서 말씀하시는 C++을 대체할만한 네이티브 컴파일러를 지닌 언어..가 등장하려면 최우선적으로 그 부분을 극복해야만 할 겁니다.

C++ 보다는 Objective-C가 더 잘 지원합니다. 전혀 차이가 없죠. C에다가
Smalltalk 방식의 객체 방식을 추가했을 뿐이니까...

좋은 지적입니다. Objective-C는 C언어의 완벽한 Superset입니다. C의 의미구조를 동일하게 사용하면서 객체등의 추가된 개념에 대해서는 다른 방법으로 접근하니깐요. 다른 패러다임을 섞을대는 Objective-C나 GJ같이 섞어야 한다고 봅니다.

하지만 컴퓨터에 한가지 언어만 깔수 있다면 Objective-C보다는 C++을 선택하겠습니다. :-)

C++이 늘 좋은 언어냐 나쁜 언어냐하는 얘기가 나오는 데,
결국은 사용자의 절제-_-를 믿느냐 마느냐에 달린 것 같네요.

그런데 좀 상황을 보면
프로젝트들이 작을때는 사실 별 문제가 없지만,
방대해지면 방대해질수록 사람은 믿기 어렵다는게
기정 사실이 되어가고 있지 않나요 ?

자바나 C#같은 언어가 굳이 대두되고 있는 건
( 자바는 뭐 어디서나 실행하자, 라는 게 목적이었을진 몰라도 )
결국 사람을 믿기 어렵다는 부분이 많지 않은가 싶습니다.
컴퓨터가 많은 것을 자동화해주면 해줄수록 문제가 적어진다는 전제 하에
가베지 콜렉션도 하는 것이고,
OOP 형태도 다중 상속을 절제하는 형태로 바꾼 것이고요.
사람이 완벽히 해낸다면 왜 이런 쪽으로 흘러갈지요 ? -_-a

사실 코딩하는 입장에서 편한게
productivity의 향상으로 이어질 수 있다는 걸 감안하면,
자바나 C#같은 차세대 언어들이 점차 상승세를 타잖을까 생각합니다.

C++가 C의 Subset이고 아니고는 별로 중요하지 않은것 같네요.
어차피 걷는 길이 완전히 다른 언어니까요.

그나저나 무슨 언어가 좋다 나쁘다 가지고
감정 운운하며 얘기하는 분위기는 별로 좋지 않은것 같습니다.
커뮤니티 사람들과의 관계가 언어의 장단보다 더 중요하지 않은가요 -_-a

이 부분은 좀 논란의 여지가 있다고 봅니다. 소프트웨어 시장이 꼭 최종 사용자를 대상으로 하는 데스크탑 어플리케이션으로만 구성된다는 전제는 잘못 된 것입니다.

커널이나 시스템 관련, 리얼타임이나 임베디드 어플리케이션, 혹은 대규모 분산환경 어플리케이션 등등의 분야마다 주로 사용되는 언어가 다릅니다. 또한 프로젝트 마다 차이도 무시할 수 없습니다.

항상 언어 논란이 있으면 나오는 말이지만 정답은 'right tool for the right job'이 아닐까 싶습니다.

저는 두 언어를 모두 좋아하기 때문에, 쓰레드를 흥미롭게(?) 지켜보고 있습니다만, C와 C++의 관계에 대해서는 이거다 저거다 말을 못할 것 같습니다.

저는 Unix/Linux 에서 5년정도 C/C++로 서버 프로그래밍을 한 경험이 있습니다.

경험을 비추어 두 언어를 비교해보면, C++ 를 깊게 이해할수록 객체의 생성/삭제/소유권 등의 문제등에 자연스러운 이해가 됩니다.
C++을 C로 구현해야하는 귀찮은 일들을 일소하는 도구로 사용할때가 있는데,

- 생성/소멸자의 존재가 C에서는 struct안의 struct들을 해제할 경우 삽질을 해야하는 경우에 대해 간편한 도구로 사용됩니다.

- Virtual Function Table 이라는 개념으로 구현된 virtual member function 들은 C 에서 함수 포인터 구조체를 통해 구현되는 Interface 제작에 상당한 노력을 절감하여 줍니다.

- 상당수 stl을 사용하여 제작하게 되는 set, vector등은 list 제작에 신경쓰지 않아도 됩니다. 생각이 자유로워진다고나 해야할까요?

C 로 개발할 경우가 있는데, 이 때는 주로 method 들이 위주가 되어 있는 간단한 utility 들을 만들때 입니다.

- class 를 일단 쓰기 시작하면 섬세한 작업과 귀찮은 libstdc++ linking 문제에 신경쓰이지 않아서 좋습니다.

- 가볍다는 생각에 기분이 좋죠. 게다가 nm 으로 출력되는 심볼들의 간결함이 늘 기분좋습니다.

C++의 강력한 타입체크 기능에 익숙하게 되면, C의 코드가 더 풍부해지는 것을 경험합니다.

두 언어는 어느 것이 다른 한쪽의 subset은 아니고 상당히 많은 교집합 대부분의 C 기능이 C++에 들어가는 형태로 생각되는 것이 옳다고 생각됩니다.
C++은 상당수 C의 노가다를 줄여주는 일로 사용되는 것이 제가 둘을 섞어 쓰는 이유인 듯하군요.

본 주제하고는 약간 벗어난 질문성 글을 올려서 죄송합니다만.

다른 언어 (ex. Java, Smalltalk, Object C) 등에서는 위와 같은 상황에서 어떤 식으로 처리가 되는지 궁금합니다.

예를 들어 Java의 경우 어떤 class의 member가 바뀌거나 새로운 method가 추가되는 경우 그 class를 reference하는 java 파일들은 재컴파일 필요 없는 건가요?
만약 그렇다면 method가 추가되는 경우는 납득이 가지만 method가 삭제되는 경우는 문제가 발생할 수도 있을 것 같아서요.
일단 javac가 method가 추가되는 경우와 삭제되는 경우를 나누어서 다른 처리를 할만큼 똑똑할 수 있을것 같지도 않고, 따라서 삭제되는 경우도 해당 java 파일만 재컴파일 될텐데 그러면 runtime에서 에러가 발생하겠죠?
그럼 method를 삭제하는 경우는 사용자가 알아서 make clean, make 하는 식의 작업을 한다음 거기서 나오는 에러들을 수정해야 한다는 이야기인데, 그럼 오히려 c++의 경우보다 상황이 더 악화되는게 아닌가 해서요.
첫째, 개발자가 어떤 class의 interface를 수정했을 때 이 class를 reference하는 java 파일들에 대해서도 재컴파일을 해야 하는 수정인지를 판단해야 할테고.
둘째, c++의 경우 그 class를 reference하는 파일들만 재컴파일하는게 아니라 개발자가 적당히 선택한 불특정 다수의 java 파일에 대해 재컴파일을 해야 할테니까요.

저도 주로 c++로 개발을 하는 사람인데, 항상 지적하신 2가지 문제때문에 많은 파일들을 재컴파일 할 때마다 더 좋은 방법은 없을까 많이 고민을 했었습니다 ^^
그래서 다른 언어에서는 이 문제들을 어떻게 처리하는지 더 궁금해지는군요.

Java의 경우는 Instance Variable이 추가 되거나 바뀐다고 재 컴파일을
할 필요는 없는 것으로 알고 있습니다(확실한지는 잘 모르겠네요...) 그리고
Smalltalk은 당연히 관계가 없고, Objective-C는 같은 문제가 있습니다만
posing을 이용해서 해결을 할 수 있습니다. 이것은 Subclass가 Superclass
를 대신해서 그 역할을 할 수 있도록 하는 것입니다. 또다른 방법으로는
Class Cluster를 이용하는 방법인데 이건 퍼블릭한 추상 클래스를 쓰고
Concrete Subclass를 그 추상 클래스가 사용하게 하는 방법입니다.
이 모든 경우에 대해서 재컴파일은 당연히 필요 없습니다. 실제로는
위헤서 말한 그냥 클래스의 Instance Var을 바꾸는 경우에도 변경 이전에
비해서 크기가 작으면 상관이 없습니다. (Objective-C는 C의 슈퍼셋일
뿐입니다.) 처음의 방법을 빼고는 원래의 클래스의 소스가 필요없습니다.

메소드의 추가 삭제에 대해서는 여러가지 경우를 나눠서 볼 수 있습니다.
기존의 클래스에 메소드를 추가 하거나 변경하는 경우가 있을 수 있습니다.
이 경우 Objective-C의 경우에는 기존의 클래스의 소스에 변경이 없이
추가가 가능합니다, Smalltalk의 경우도 마찬가지입니다. Java의 경우는
소스코드가 있어야 되는 것으로 알고 있습니다. 그러나 그 때문에 다른
의존하는 프로그램을 재 컴파일 할 필요는 없습니다. Objective-C의 경우
에는 위에서 말한 posing을 이용할 수도 있습니다. 이 경우도 당연히 재
컴파일은 필요가 없습니다.
삭제의 경우에는 문제가 있을 수 있습니다. 그 메소드가 사용되지 않던
것이라면 관계가 없습니다만, 사용되고 있다면 문제가 될 수 있습니다.
이 경우는 forwarding을 이용해서 처리가 가능합니다만 미치지 않고서야
다른데서 쓰는 메소드를 제거하지는 않겠죠? :-)

C++의 문제점들, 특히 유지보수관련은 C++가 정적이라는 데서 연유하는
것이 많습니다. 이 때문에 Alan Kay가 OOP라는 말은 어울리지 않는다고
했던 것이고요(실제로는 OOP라는 말은 자신이 창안을 했을 때는 C++와
같은 언어에는 어울릴 수 없다고 했습니다.) 같은 문제를 Java도 좀 가지고
있기는 한데, 정적 형검사를 위해서 OOP를 위한 기능을 희생한 비율이 잘
조화가 되어 있는 편이죠.

여담으로, 80년대말 90년대 초 NeXT가 Objective-C를 유행 시켰을 때
많은 회사들이 고려를 했다가 위와 같은 특징 때문에 쓰지 않았다는 말이
있습니다. 이건 Smalltalk과 같은 문제인데, 라이브러리를 주면 그 설계가
노출이 되는 것은 관계가 없다하더라도 배포되는 실행파일에 따라가는
프레임워크의 사용을 막는 것이 어려워서 돈벌이에 애로가 있어서 말이죠.
실제로 Smalltalk의 경우에도 (때문에)상당히 비싼 라이센스를 받았었고
NeXT도 같은 식이었습니다.(물론 자사의 OS를 쓰는 경우에는 아니었죠.
그리고 지금은 싸게 내렸습니다. 거의 1/20로 말이죠.) 이건 그냥 여담
입니다 :-)

사실 C++에서 가장 원망(?)스러운것중하나가.. name mangling에 대한 기준이 없다는 것인데, 이것때문에 발생하는 것은 compiler 독립적인 바이너리가 생산되지 않는 것에 있습니다.

거의 모든 class member 함수가 exportable symbol로 잡히는데 이것은 상속에 의한 calling이 가능하기 때문에 어쩔 수 없는 상황이라하여도, C의 export symbol의 간결함에 비하면 정말 약간은 답답한 구석이 있는 부분입니다.

c++filt 나 nm의 -C option이 있기는 하지만, 여전히 디버깅을 위한 것일뿐 입니다.
다른 컴파일러나 언어와 link를 위한 구석이 없다고해도 과언이 아닙니다. 결국 export "C"를 써서 name mangling을 없애는 방향으로 가는 수밖엔 없지요.

모든 언어가 그렇긴 하지만, C++의 경우 Object symbol에 대한 표준(?)이 없는 것이 오히려 그런 상황을 초래하지 않았나 싶습니다.

아뭏든 C/C++은 적절한 trade off 범위내에서 선택하는 것이 항상 고민입니다.

주절주절..

사실 전 언어에 대한 애착이 그리 많지도 않고
언어에 대해 특별히 연구하는 것도 없고 해서 공감이 힘들긴 합니다만.
( 파스칼은 좀 좋아하긴 합니다. 흐 -_- )

여기서 C++의 단점에 대해 얘기하시는 분들은
일반적으로 알려져있는 C++의 단점들을 논하시는 것 같은데요.
단점이 아닌 걸 가지고 단점이라고 하시는 분은 별로 없는것 같은데,
설마 C++가 완전무결한 언어라고 생각하시는지요 ?

그리고 C에서 자유가 마구 허용되는 것과
C++에서 자유가 마구 허용되는 것은 아주 다르다고 생각합니다.
C는 탄생 자체가 OS 제작과 밀접한 관련이 있었고,
최대한 시스템 레벨에서 작업을 할수 있도록 하는 것이 매우 중요한 요소입니다.
이전 다른 토론에서도 "C는 portable한 assembly language"라는 얘기가
많이 나왔었던 것으로 기억합니다.
C++는 용도가 크게 다르죠.

C++가 C보다는 일반 어플리케이션 개발 및 유지보수에 있어
어느 정도 우위에 있다고 볼 수 있겠습니다만,
최근에 나오고 있는 C#이나 Java 등에 비해서도 그렇다고 말하기는
다소 어려움이 있지 않나 생각합니다.
제가 생각하는 C++가 여전히 많이 사용되고 있는 까닭은
기존에 배포된 자료 및 라이브러리가 많이 있고
binary code가 직접 나오며, 그로 인해 퍼포먼스가 높다는 것 같네요.
( 분석이 상대적으로 쉬운 중간 코드를 생성하지 않으니 소스를 숨긴다는 측면에서도 좋겠죠. )
하지만 이것이 언어 구조 자체의 장점이라고 생각하지는 않습니다.
C#이나 Java 등 다른 언어 관련 자료도 상대적으론 적지만 축적되어가고 있고,
JIT 기술이 발전하고 시스템들이 빨라져가면서 퍼포먼스의 중요도가 낮아져가고 있으니까요.
( 퍼포먼스가 극단적으로 중요한 경우도 있겠습니다만. )

C++가 적당한 diet를 했으면 좋겠다는 생각은
비단 저만의 생각일런지요.

OS Level에서 세세한 조작이 가능한 것은
사용자에게 득이 되는 경우가 많지만,
Language Level에서 세세한 조작이 가능한 것은
System Programmer에게는 득이 되는 경우가 많아도
그 외에는 그렇지 않은 경우가 대부분입니다.
특히 유지보수의 측면에서요.

점차 프로그램이 방대해져가는 지금
언어가 다양한 기능을 제공하는 것도 중요하겠지만,
언어 자체가 최대한 버그를 줄여줄 수 있는 구조인가도 상당히 중요하잖을까요.
( 옛날엔 당연히 해야했던 메모리 deallocation같은 것들이, 요즘은 신경쓰기 아주 짜증나더군요. -_-; )

...

Vector나 List같이 많은 사람들이 쓰는 부분은
STL의 존재가 참 편하긴 한데,
직접 만들어 써야 하는 경우가 좀 -_-;
어쨌든 다른 언어들과 비교해볼 때,
Template은 C++만이 가진 확실한 장점인 것 같습니다.

그나저나 퍼포먼스에 대한 문서가 하나 보여서,
이 토론과 상관이 없는 것도 같지만 글 쓰는 김에 링크해봅니다. -_-a

http://www.devdept.com/prg/docs/wdn200313.pdf

아침에 들어와보니... 새로운 글들이 많이 올라와 있네요..
지나가려다가 저에게 직접 남기신 글이 있어서 답변 드립니다.

제가 마구보드에 들어가는 ListDatabase.php라는 소스 코드를 작성한지는 상당히 오래되었습니다. 제가 대학교 1학년에 들어와서 작성한거구요.. 그때가 PHP를 시작한 때였습니다. 더욱이 문제가 되는것은 고등학교다니면서 C로 구현한것을 옮긴것이었습니다. 거의 이론없던 시절에.. 그리고 객체지향적인 프로그래밍을 하기 전에 작성된 것입니다. 더구나 PHP4에서는 객체지향을 제대로 지원하지 않고 있지요.

그리고 그 상태에서 일반적인 단순한 게시판 운영을 할정도가 된다고 생각되었기 때문에 그리고 많은 분들이 저에게 어떤 방법으로 만든거냐시기에 설명을 써야겠다 싶었는데 마침 마소에 그런 코너가 있어서 거기에 적은 것이었습니다.

아시겠지만 PHP라는 언어로 제대로된 데이터처리를 하는것은 상당히 어렵습니다. 특히 인터프리터로 처리되는 언어이기 때문에 실행속도도 코딩하면서 고려할 사항이 많습니다. PHP를 해보셨다면 여쭙지요..

$A['A']
$A["A"]
$A[A]

어느게 가장 빠를거라고 생각하십니까? $A[A]는 다른 두개에 비해 상당히 느린 속도를 보입니다. 제가 예전에 테스트해본 경험으로는 $A['A']가 가장 빠릅니다. 모두 같은 처리를 하면서도 이렇게 차이를 보이는 것은 코딩에 상당한 주의를 기울이게 합니다.

앞에서도 언급했듯이 자신있게 C++을 잘한다고 말씀드리기에는 무리가 있습니다. 하지만 저도 C++이라는 언어가 어떠하다는 것은 알고 있으며 객체지향이라는 개념을 매우 좋아합니다. 저는 C++이 자바 이상의 객체지향 설계가 어렵다는 이야기가 아니었고 그 이하의 설계가 가능하며 그렇게 될 가능성때문에 의견을 이야기한것이었습니다. 잘 사용했을때 C++의 가능성은 인정합니다.

물론 앞에서도 말씀드렸듯이 제가 C++에 대해 "대체"해야 한다고 생각한다는 조금 과격한 말을 한것에 대해서는 C++을 좋아하시는 분들께는 미얀하다는 말씀을 드립니다.

맞는 말씀입니다.

옛날에... (고등학교 때인지 대학 때인지 잘 기억이 안납니다만8)) 어느 무식한 월간지에서... 아주 심플한 C와 C++의 비교를 한적이 있었던것같습니다.
삼천 라인인지 오천 라인인지 기억이 잘 안납니다만, 여튼 코드의 양이 그 이상이 되면 C++이 더 낫다는 황당한 기사를 본적이 있었죠.

그때는 그런가 보다 하고 넘어갔었지만 지금 생각해보면 아주 웃긴 이야기였던 것같습니다.

언제가 되었건 이런 논의들이 웃겼었다고 이야기 할 수 있을 때를 기다리며......

창시자이긴 하니 Stroustrup씨의 말도 중요하겠지만,
실제로 시장에서 어떻게 쓰이고 있는가가 더 중요하지 않을까요.

C++은 C에 비해 다양한 칩이나 기기에 쓰이는 데는 좀 부담스럽죠.
( 개발 환경이 갖춰져있는 x86같은 특정 플랫폼들만 다룬다면 모르겠습니다만. )
portability도 C에 비해 떨어진다고 생각하는데요.
( 아무래도 simple하다보니, C compiler가 없는 platform은 드물죠. )
시스템 프로그래머들이 바보라서 C를 고집한다고 생각하진 않습니다.

저도 Stroustrup씨의 책을 보고는 있습니다만 -_-;
Stroustrup씨의 말들을 보면 종종 C++에 대한 애착(?)이 과하다는 생각이 들더군요.

...

앞에 좋은 글들이 많은거 같은데...
제가 더 이상 길게 말씀을 드리긴 그렇고^^
제가 아는 단편적인 c++은 c의 struct 구조에 변수뿐만 아니라...
함수가 들어가는 구조가 c++이다라는 것...
이건 c++의 창조자가 고안한 것이기도 하고요...

<어떠한 역경에도 굴하지 않는 '하양 지훈'>

시중에 쓰이는 STL의 종류는 생각보다 많지 않습니다. STLPORT는 SGI STL에서 나왔고 이 둘의 지배력은 매우 크니깐요. 상업용 C++컴파일러에서도 STLPORT를 쓰는 곳이 많습니다. (B사의 컴파일러에 들어있는 것도 많은 사람들은 모르더군요.)

vacancy님이 첨부한 문서는 아직 읽어보지 못했는데 STL의 퍼포먼스라니깐 의문점이 생기는 부분이 있습니다. (오후에 충분한 시간을 두어서 첨부된 문서를 읽어보겠습니다.) STL의 퍼포먼스라면 컨테이너와 제너릭 알고리즘의 퍼포먼스일텐데요. STL의 컨테이너의 특성을 고려하고 테스트를 하는 것인지 궁금합니다. STL의 할당자는 공간이 부족하면 공간을 2배로 잡고 복사생성자들을 대거 호출하지 않습니까? 하지만 C#이나 Java의 라이브러리들은 단순히 언어자체의 성질을 이용해서 그대로 할당받고 제거될텐데요. 충분히 크게 할당한다면 복사생성자가 실행되지 않아서 속도는 향상될테지요. 반면에 공간은 늘어날테지만요.
PS:

약간은 위의 이야기가 벗어납니다만 C++라이브러리의 퍼포먼스에 사람들이 덜 관심을 갖는 것 같습니다. iostream같은 경우에도 이론만큼 최적화되지 못하였습니다. 단순히 c++라이브러니는 더 추상화되었으니깐 느려도 만족해. 정도의 시선이 많은것 같습니다.

전 이 부분에서 동의하기가 좀 힘든 면이 있습니다.

1. 퍼포먼스

선뜻 동의하기 어려운 부분이 퍼포먼스를 위해서 클래스 조차도 싫어하는 사람들에게는 C++의 많은 특성들은 그림의 떡일겁니다. 그런데 그런 특성들을 안 쓴다면 C++이라고 보기는 힘들죠. 그런 분들에게는 C++은 사치로 여겨질겁니다.

2. 이식성

C언어의 특성은 C++보다 사려깊지 않게 만들어진 것이 아니라 보다 많은 하드웨어에 이식되기 위해서 노력합니다. 그래서 사람이 쓰기에는 불편한 부분이 여러가지지만 컴파일러를 만드는데는 그만큼 편한 언어는 드뭅니다. 현실적으로 C가 깔릴수 없는 환경이라면 매우 열악해서 어셈블리와 기계어 밖에 되지 않는 환경일 가능성이 큽니다. 그래서 C는 C++보다 더 넓은 플랫폼을 포용합니다.

또 이식성의 발목을 잡는 것은 네임 맹글링입니다. C++에서 네임 맹글링이 규격이 없는 것 때문에 C++은 시스템 프로그래밍에서 범용성이 떨어집니다. 먼저 네임맹글링의 표준이 없다는 이유하나로 컴파일된 오브젝트 화일은 다른 링커파일에서 처리하기 무척이나 어렵습니다. 이건 코드 수준인데 소스 수준의 문제도 야기합니다. 표준 C와 혼합을 할 필요가 있다면 일정한 키워드가 필요합니다. 하지만 네임 맹글링 자체의 표준이 없기 때문에 혼합하기 위한 사용한 키워드 역시 비표준입니다. 그 소스는 지극히 플랫폼 종속적이게 되지요. 이 문제를 피할 방법은 분명히 있을겁니다. 하지만 순수 C언어로 시스템 프로그래밍을 하는 것보다는 비용이 많이 들겠지요.

어플리케이션 프로그래밍에서 C++대신에 C를 선택하면 훌륭한 구조와 생산성, 유지보수를 잡을 방법은 분명히 있을겁니다. 하지만 대게는 C++보다 비싸게 먹히겠지요. 시스템 프로그래밍에서는 C++이 C보다 비싸니깐 현실적으로 안쓰는 것입니다. 현실을 무시하고서는 뱌네 스트로스트룹도 권위가 없을 것 같습니다.

PS: Bjarne Stroustrup의 발음 적으려고 무척이나 고심했습니다. Bjar-ne Strou-strup이 자신의 발음을 표기한것으로 BJ어디에도 강세가 없다고 하고 각각 2음절이라고 하니 이정도가 괜찮을 것 같습니다.

http://www.research.att.com/~bs/pronounciation.wav

본인이 직접 얘기하고 있습니다.
네이티브 발음은 비야네 스꽁스꾸(우?) 정도로 들리는군요.
영어로는 비야네 스트루스트럽 혹은 스트라우스트럽 이라고 합니다.
하지만 대부분 '비얀'으로 표기하는 걸로 알고 있는데 아마
우리말이 억양이 적기에 그것이 더 비슷하게 들리는지 모르겠습니다.

NeXTSTEP/OpenStep은 FoundationKit위에 AppKit이 사용자 어플리케이션
을 프로그래밍 하는 것을 가능하게 하는 구조로 되어 있습니다. 그러나
AppKit은 FoundationKit의 베이스 클래스의 기능을 확장하거나(Categorizing) 또는 덮어버리기도(Posing) 합니다. 그렇다고 해서
성능의 이상이 생기지는 않습니다. EOF, WebObjects도 마찬가지입니다.
당연히 Smalltalk에서 베이스 클래스에 인터페이스를 추가했다고
성능에 영향을 준다는 이야기는 못들었습니다.

요는 변화하지 않는 설계는 있을 수 없으며, 변화에 잘 적응을 할 것을 우선시
하느냐(ObjC) 성능을 위해서 적응력을 떨어뜨리고 필요하다면 새롭게 갈
것인가의 차이일 것 같습니다.

B. Cox가 비교한 대로 정적인 언어와 동적인 언어의 차이는 그냥 아기와
스키모양의 발을 가지고 태어난 아기의 차이와 같다고 생각됩니다. 스키
아기는 스키는 잘 타겠지만 눈길이 아니면 아주 힘들 인생을 살아야 할 것
이고, 그냥 아기는 스키를 스키 아기만큼은 못 타겠지만 필요한 환경에 따라
스키를 탈 수도 비행기를 탈 수도 있겠지요. :-)

짧은 문장을 제가 잘못받아들여서 생기는 오류가 있을 것 같기 때문에 몇가지 질문을 던져봅니다.

이 부분에서 약간의 의문이 생깁니다. C++ 임플리먼트의 네임맹글링이 없는 C++은 C++의 반을 버리게 되는 것이 아닌가요?

extern "C"만이 표준일텐데 실제 프로젝트에서는 비표준적인 네임맹글링 제거법을 많이 보았습니다. 문법적으로 비표준적인 방법외에는 C++의 특성을 유지한채 C++ 임플리먼트의 네임맹글링을 제거하는 것은 불가능한것이 아닌가요?

그렇다면 C++은 적어도 네임맹글링의 이유로도 시스템 프로그래밍에 부적합한게 아닐까요?

오랜만에 좋은 토론인 거 같아서 기분 좋습니다...

물론, 몇몇 분들께서 감정적인 쪽으로 흐르는 것이 좀 그렇기는 하지만, 뭐... 평소에 많은 분들이 생각하지 않고 있는 이야기들이 나오는 것은 언제라도 좋다고 생각합니다...

가끔 생각해 보죠... 언어를 사용하면서 끊임없이 언어에 대한 생각을 하는 것이 아니고 그냥 타성에 젖어서 사용하고 있는 것은 아닌지요...

그런 의미에서 이런 식의 토론은 상당히 유익하다고 생각합니다...

그럼 이제 제가 하려던 이야기를 해야 겠네요...

물론, C++에 국한된 이야기는 아닙니다... 그냥 언어와 사용자의 관계에 대한 글이라고 생각해 주시면 좋겠네요...

위 글들 중에 '그런 식의 Code는 언어의 문제가 아니라 사용하는 사람들의 문제가 아니냐...' 라는 의견을 보이신 분들이 계셨습니다...
그러나 제 생각은 약간 다릅니다...
그런 비정상적인 사용법이 가능한 거 자체는 언어의 문제라고 생각합니다...

뭐... 다들 아시는 거 겠지만요...
예를 들어 초기에 C가 만들어 질 때는 위와 같은 개념이 약해서 Array의 Bound를 넘어가는 인자가 들어와도 어떻게 할 수가 없었습니다...Compile Time에는 Error가 나지 않고 실행중에도 요행히 Error가 안 날 수도 있습니다... 보통은 Sigmentation Fault가 나겠지만요... 그런 Code가 가능한 것이죠... 그러나 Java와 그런 수준의 언어들에서는 가능하면 Compile Time에 아니면 실행 중에도 Exception으로 잡아낼 수 있습니다...

이런 식으로 언어가 사용자에게 지원하는 환경이 사용자의 실수나 부주의한 사용으로 Program 전체의 동작에 피해를 줄 수 있는 부분이 크다면, 그걸 사용자의 문제라고만은 볼 수 없을 거라는 겁니다...

int i = 'hi'와 같은 Code를 사용하는 사용자도 문제지만, 그런 것이 가능한 거 자체가 더 문제 아니겠습니까???

비유하자면, 마치 법이 없는 세계에서 범죄를 저지르면 그게 무조건 범죄를 저지른 사람 잘못이라고 하는 것과 같은 거라고 봅니다...
이런 경우에 대락 법이 없는 사회가 문제라는 말이 더 많이 나오겠죠...

언어에서도 그런 부분은 있다고 봅니다...

예전에 C#이 처음 나왔을 때, Java 측과 MS 측에서 언어의 정의에 대해서 말이 많았습니다... 물론, 아직도 결정난 문제는 아니고 결정날 수 있는 사안은 아니라고 봅니다...

이런 문제였죠... Java에서는 Programmer가 'Explicitly' Pointer를 사용할 수 없습니다... 그건 Java를 만든 Architect들의 철학이 담긴 문제지요... Pointer의 Explicit한 사용이 많은 Program들을 오동작하게 하고 있으며, 짧은 시간에 끝낼 수 있는 Logic이 memory 관리로 인하여 길어지고 Logic에 집중하기 보다는 Memory 사용의 Debugging에 더 많은 시간이 투자되는 것을 원천적으로 봉쇄하자... 이런 식의 철학이죠...
그래서 Java에서는 Explicit한 Pointer의 사용이 없습니다...

그러나 C#의 경우 기본적으로는 Java와 같으나 특수한 경우에는 Pointer를 Explicit하게 사용할 수 있도록 하고 있습니다...

이런 C#의 정의에 대해서 한 쪽에서는 Bug를 만들어 낼 수 있는 정의다... 아니다 이건 좀 더 자유로운 사용을 위한 특수 Case다... 이런 식으로 열띤 토론이 있었습니다...

이와 같이 언어의 정의는 사용자와 나중에 생성된 Program의 질적인 측면에 있어서 상당히 중요한 부분입니다...

무조건 사용자의 사용에만 맡겨두고 나몰라라 할 수는 없는 것이라는 거죠...

뭐... 제 글이 처음 시작하신 분의 논지와 좀 어긋나는 점이 있다는 점은 인정하겠습니다... 하도 간만에 이런 논쟁이 있어서 저도 좀 참여 하고 싶은 마음이 들어서라고나 할까요...

실은 저는 Specific한 부분은 잘 모릅니다... ㅎㅎㅎ -____-

그럼 즐겁고 유익한 토론이 계속 되었으면 합니다...

음냐,, gcc가 표준이 아니었나요?
그럼 표준은 대체 무엇인가요?
에겅,, 머리야,,

맞습니다. 필요이상의 상속은 "악"입니다 :-) 그러나 필요할 때 못하는 것도
"악"이죠. 그리고 말씀하신대로 다중 상속이 "기본"에서는 되지 않은
언어의 경우에는 구현의 통합은 안됩니다.(구현의 통합은 다중 상속을 통해서
만 되는 것으로 알고 있습니다.) 그러나 인터페이스의 통합은 가능합니다.
그리고 Smalltalk의 경우에는 다중 상속이 가능하도록 할 수도 있습니다.
(심지어는 Java의 Interface, ObjC의 Protocol같은 것도 가능합니다.)
가상함수의 경우에는 정적인 C++의 특징인데(정적인 바인딩) 제가 알기론
C++에서의 가상함수는 효율이 떨어지는 것으로 알고 있습니다. 가상함수를
많이 써야 되는 구조라면 ObjC를 사용하는 것이 더 낫습니다.(이건 제 경험
입니다. 그리고 Budd의 책에서도 볼 수 있듯이 다른 문제들, 메모리,
테이블 참조 시간등의 증가 및 기타...의 안좋은 점도 있습니다.)

처음 OOP는 동적이며 적응성에 중점을 둔 것으로 시작 된 것 같습니다.(물론
Simula와 같은 것들도 있었지만 논외로 하고....) 그러다가 C++이 나오면서
(이게 Simula의 영향을 많이 받은 것 같습니다. 아마 OOP보다는 더 좋은
C에 목표가 있었기 때문이겠지요.), 정적인 검사에 중점을 두는 쪽의 방향도
나오게 된 것 같습니다.

위에서 C++은 C로 시스템 프로그래밍을 고집하는 사람을 위해나왔다는 말과
그에 관한 글을 여러 댓글도 읽었습니다만,

다른글을 찾아보다가 그와 관련된 언급이 있어 첨부합니다.

뭐..지금 주제는 약간 다른쪽으로 흘러가는거 같지만...
암튼 생각나는김에...^^..첨부

http://bbs.kldp.org/viewtopic.php?t=20960&highlight=%B8%B6%C0%CC%C5%A9%B7%CE+%C4%BF%B3%CE
위글을 보면 솔라리스 수석 엔지니어와의 대화내용이 올라와있는데,

7. 30 years after UNIX was recoded in C, most people still use C (or in some cases a little bit of C++) for the OS kernel. Is C perfectly adequate, or do they see some of the newer languages (C#, Java, or even modern C++ paradigms) being applied to OS design?

Andy Tucker: 이 분야에서 다양한 실험이 있었습니다. 예를 들면 썬은 C++ (SpringOS)와 자바(JavaOS)로 운영체제를 만들었습니다. 오브젝트 오리엔티드 언어가 고수준 프로그래밍 추상화를 위한 쉬운 개발의 관점에서 보면 장점이 많지만 OS 커널 개발에도 그만한 혜택을 주는 것은 아닙니다. 커널은 하드웨어와 가장 직접적으로 상호 작용하는 소프트웨어이기 때문에 메모리 재활용(garbage collection)과 템플릿 등의 쉬운 개발을 위한 기능보다는 언어와 기계의 명령(instruction) 사이에서 간단하게 사상(map)되는 데서 얻는 이익이 더 큽니다. 언어 의존적이고 광범위한 런타임 지원 요구도 있습니다. 대신 오브젝트 오리엔티드 언어의 개념(예: 다형성)을 빌리거나 비-OO 언어(C)로 그것을 구현하는 방법을 찾기도 합니다.

위와 같은 부분이 있네요~

중간쯤에 나온 시스템프로그래밍에서의 C or C++에 대해 조금 코멘트를
달겠습니다. 저는 C, C++ 둘다 편견없이 사용하고 있습니다.

Device Driver를 C++로 만들고 싶다고 할때 그는 OOP와 encapsulation의
장점을 이용한 프로그래밍을 하고 싶은 것이겠죠. 하지만 이에 따라 발생 할
수 있는 단점으로 위에 여러분들이 이야기 하셨던 C++를 잘 모름에 있어서
생기는 보이지 않는 overhead가 있겠지요. virtual function 문제라든지
copy constructor 등등. C++이라는 무기를 사용하기 위해서는 일정이상
의 무기 숙련도가 필요한것이라고 생각하면 됩니다. 문제 해결 방법은 inline
keyword를 적절히 사용하고, virtual function도 그 함수를 많이 호출하지만
않으면 성능상에 문제는 없습니다. 이들에 대해서 명확히만 알고 대처할 수
있다면 C보다 우수한 type checking 이라든지 syntax나 OOP 코딩 테크닉
을 이용한 시스템 프로그래밍을 할 수 있을 것입니다. STL을 쓸 수 없다?
Kernel level에서 사용할 수 있도록 포팅된 STL도 있습니다.
(물론 돈주고 사야겠죠)

누가 뭐라 해도 난 C++이 싫다. 이럴때는 그냥 C를 쓰면 됩니다.
C를 쓰나 C++을 쓰나 성능은 프로그래밍 하는 사람의 내공에 달려있는
것입니다. C로 시스템 프로그램을 만드는 사람이 C++로 만든 사람에게
"넌 왜 그런 거지같은 언어로 만들고 있냐?" 라고 하면 보여주십시오. 그
사람이 C로 코딩한 프로그램 보다 더 간결한 디자인에 더 빠르게 동작하
는 모습을. 물론 그 반대의 경우도 성립합니다. :)

c++로 그것도 oo로 만들어진 디바이스드라이버라.
꼭 보고싶은데요. 공개된 것이 있다면 꼭 좀 알려주셨으면 합니다.
제 생각에는 oo가 하드웨어적으로 완전히 표준화가 됐거나 드라이버개발자가 스펙을 정하는 디바이스거나 efi처럼 표준적인 인터페이스를 가진 layer 위에서가 아니면 장점을 가지지 못할 거라고 생각되는데요. 이 경우조차도 가벼운 c가 좀 더 괜찮을 것 같은데.
c++이 무겁다는 건 실행속도나 memory footprint만을 말하는 건 아니고요. 위에 어떤 분이 쓰신 인터뷰에서처럼 개념적으로 디바이스와의 mapping이 간결하다는 의미에서 c가 더 가볍다는 겁니다. 물론 탁월한 c++프로그래머에겐 이것이 작은 차이이겠지만 제 주위에는 그런 경우가 없어서 정말 보고 싶군요.