mastercho님께서 설명을 달지 않으셔서 어떤 이유에서 그런지 궁금하네요.

to. mastercho

제말씀을 잘못 이해하셨는지 제가 정말 답답한 말을 했는지 모르겠습니다. 저는 C++을 제대로 알지 못하고 사용했을 경우 매우 문제가 되는 코드를 만들어 낼 수 있으며 그러한 요소는 차라리 배제하는 것이 났다는 의미해서 불필요한 요소를 포함하고 있다고 쓴 것이었습니다.

제가 생각하는 C++의 가장 큰 문제점은 C의 표준 함수를 더블어 사용할 수 있고 그로 인해 야기되는 문제들입니다. 그렇다고 아예 사용하지 않을 수 있는지 의문입니다.

부탁드리겠습니다.

-------------------------------------------------------------------
이하는 위에 분이 언급하셔서 다시 편집했습니다.

일반적으로 자기가 좋아하며 연구하는 언에 대해 자부심을 가지게 마련입니다

따라서 제가 C++를 좋아한다고 해서 C#, 자바를 완벽히 알지도 못하면서 폄하 하면 안되듯이 , 이런분야의 말일수록 쉽게 말해서는 곤란하다고 생각합니다

지금 제가 바로 답글 단것을 피한것은 "어느 언어가 좋은지"에 대한 불필요한 논쟁을 불러 일으킬수도 있기때문에 자제한것이고

위에 글 쓰신분에게 잘못된 이야기를 수정하도록 요구하는 것입니다

마침 위에 답글을 다셨군요 ,그럼 인용해서 답글을 달도록 하지요

C++을 좋아하는 분이셨군요. 저도 C++을 싫어하지는 않습니다. 그렇다고 나쁜 언어라고 쓴것은 아닙니다. 언급했듯이 제대로 알지 못했을때 문제가 있다는 말씀입니다. 위험요소를 내제하고 있다는 것은 좋아하시는 입장에서도 동감하시리라 생각합니다만... 어떠신지 모르겠습니다.

이성을 가지고 이제 차근 차근 위에 대한 생각에 대한 반박글을 남기도록 하겠습니다

-알지 못했을때 위험한것은 어떤 언어든 마찬가지 입니다 , 굳이 C++에서만 위험한것은 아니라고 봅니다

- C++에서는 여러가지로 프로그램밍을 할수 있습니다 , 알지 못하면 쓰지 않으면 되고 그렇게 하더라도 프로그래밍이 됩니다 , 저도 아직까지 템플릿을 명확히 이해하고 많이 쓰지 못하고 있는데, 제대로 아는 만큼만 쓰면 되지 , 알지도 못하면서 쓰는건 당연히 아니지요...

이문제는 , 다시 말씀 드리지만 어떤 언어든 마찬가지 입니다
[불필요한 요소와 단순함에 대해서는 밑어 더 글이 남아 있습니다]

제가 C++를 쓰면서 C만 쓰는 분의 C++ 이야기를 들었을때 일반적으로 어처구니 없다는 생각을 많이 하게 됩니다, 왜냐하면 C++에서도 당연히 문제가 안되는것이고 오히려 C에서 문제가 되던것이 C++에서 대부분 해결된게 많습니다, 가장 답답한것은 C++를 공부해봤다면
전혀 문제가 없다는것을 알텐데 , 모르니까 "C++에서는 문제가 되지 않을까?"라는 생각을 한다는 것입니다

위에 말씀 하신 내용중 C의 표준함수를 더블어 사용됨으로써 발생하는 문제를
찍어주시면 좋겠습니다 , C++ 상식선상 C++에서 C표준함수를 쓴다고해서 전혀 문제가 되지 않습니다

지금부터는 처음 남기신 글에 대한 반박을 하겠습니다

정말 답답하게 느낀 대목이 바로 유지보수에 관한 내용입니다
객체지향이 왜 나왔는지 충분히 아시리라 믿습니다, 바로 유지보수및
코드[꼭 코드가 아니더라도]의 재활용이라는것에 큰 의미가 있습니다

C++에서는 클래스를 이용해 캡슐화를 하고 이로부터 유지보수의 엄청난 장점을 얻습니다
또한 클래스내부에서 private를 이용하여 유지보수를 위한 리펙토링이 손쉽게 할수 있는 장

점도 있습니다, 또한 class를 유틸리티나 라이브리러로 컴포턴트화 하면 , 다음 프로젝트때

도 쉽게 써먹을수도 있죠
굳이 객체지향을 들먹이지 않아도 충분히 이해하셨으리라 봅니다
말씀하신 유지 보수 불가같은것은 C++을 이용해서 엉터리로 프로그래밍하는 경우에나 나오

는것인데, 그것은 언어의 문제가 아니라 사람의 문제라고 보여지고 , C++이 아니라 어떤 언

어를 쓰더라도 부족한 능력의 사람이 쓰면 유지 보수는 불가합니다

C++의 객체지향을 사용하면 오히려 객체지향적인 요소를 강요하는면이 있기때문에
위에 말씀하신것은 전혀 동의 할수 없는 내용이라 보아집니다

또 C의 장점으로 단순하니까 C++보다 낫지 않냐는 말이 있는데
C++의 확장성과 방대함에 대한 불만이라고 보겠습니다
하지만 이것이 단점이라 생각하는건 크나큰 오해라고 볼수 있습니다

한가지 자료를 들어 말씀 드리자면
마이크로 소프트웨어의 2002년 01월호에 실려 있는
"더 높은 프로그래밍의 세계 Haskell로 가자" 라는 글이 있습니다
[이글을 쓴분은 김재우라는 분으로 많은 언어에 대한 이해를 가지고
자바와 다른 언어만을 고집하는 사람들에게 일침을 놓은분입니다]

거기서 글을 보면 이런 대목이 있습니다

이 말에서도 볼수 있듯이 언어가 확장되고 방대하다고 해서 언어가 나뻐진다는 생각은
잘못된 생각입니다
C++은 언어적인 측면에서 C를 확장하고 수많은 패러다임을 흡수한것뿐이며,
언어적인면에서 엄청난 발전을 이루었다고 볼수 있는것이지
이렇게 방대하게 느껴지는것을 , 언어적인 측면에서 단순하지 않다며 나쁘다고
주장하는것은 잘못됐다고 봅니다

심지어 김재우라는분은 이런말까지 합니다

위글에 주장하는 바에 따르면
C++에서는 C의 수많은 단점을 극복해주었고 , 모자라는 부분을 엄청나게 채워줬음에
틀림없습니다
또한 호환성도 거의 문제가 안되죠
[미세한 차이는 거의 문제가 안됨으로 넘어갑니다]
또 다시 이야기 하게 되지만쓰기 힘들면 그 부분에 대한 내용은 안쓰면 되는것입니다

따라서 저로썬 , 말씀 하신 내용을 전혀 수긍할수 없는것입니다

이의가 있다면 답글 달아주십시오

사실 흥분한된 상태였기때문에 , 거친 답글이 나와
자칫 기분 나쁜 감정 싸움으로 바로 이어질거 같아서

생각좀 정리 하는 편이 좋을거 같아 그랬던거 같습니다

물론 반박하시오 라는 대답이 나올지 예상은 했고요

:) 흥분된것을 가라 앉히는 시간 벌기 용이었던거 같네요

C++언어에 대한 자부심이 강하다보니

오해가 있던면에서는 양해를 부탁드립니다

어째튼 흥분을 가라 안 히고 답글을 남기느라 좀 애먹었습니다 ~ :oops:

우선 C++는 언어적으로 C를 확장한 것이 아닙니다. struct나 const등 같은 키워드는 비슷할 가능성이 있지 호완되지 않습니다. C90이상의 C로 짜여진 대형 프로젝트를 C++으로 옮길때 문제점이 발생할수 있습니다. 김재우씨가 좋다고 주장하시는 Haskell의 경우는 얕게봐서 잘 모르겠습니다만 적어도 C++은 언어의 알맹이가 뒤틀리거나 흐트러지지 않으며 불어나지도 않는다는 것과는 거리가 있습니다. C++의 템플릿같은 기능들은 매우 훌륭하다고 생각하지만 export와 같은 키워드는 컴파일러가 지원해도 쓰고 싶지 않습니다. C++이 방대해지면서 장점과 단점을 가졌는데 저희는 장점을 골라써야 한다고 봅니다. C++은 쌍절곤 같다고 봅니다. 말의 뼈를 부술정도로 강하고 매력적이지만 미숙하면 자신이 다칠수 도 있는...

위에서 김재우씨가 말한 GJ가 문제가 되지 않는 것은 템플릿과 같은 것은 자료형에 맞게 그 명칭에 맞는 함수나 클래스를 더 만들어주면 해결되는 문제라서 실질적으로 Java 자체가 수정되는 것은 없습니다. GJ같은 것은 도입해도 좋은 것이지요. 그것과 C++는 논외라고 봅니다.

C에서 확장한것이 아니라고 하신다면 어떤면에서 확장한게 아니라고
보시는지요?
객체지향 패러다임? C++은 처음에 C언어로 구현되었습니다
C언어를 확장에서 C++이 현재 추구하는 패러다임에 맞게끔 수정한것이지요
[물론 지금은 거의 독립되었습니다만은 ,C++의 발전사 자료를 찾아보시면 C에서 확장한 내용을 쉽게 찾을수 있다고 봅니다]

이부분은 오해의 여지가 남아있기때문에 , 딱히 모라 할순 없겠지만
단순히 단답형으로 , "아니다"라고 말씀하시는것에대해 불만이 있네요

다음으로
C에서 쓰인 const나 struct이 호환되지 않는다고 말씀하셨는데
어디서 호환이 되지 않는다는것인지요?
C++에서 C로 넘어간다면 문제가 되지 C에 있는 문법이 C++로 넘어가면서
문제가 되는 경우는 극히 드뭅니다
어떻게 문제가 되는지 예를 들어주셨으면 합니다

그리고
C90이상 에서 짜여진 대형 프로젝트가 C++로 넘어가면 , 문제의 소지가
전혀 없을수는 없을것입니다 , 하지만 문제의 경우가 타입 강화로 인한부분같은 부분에서 문제라면 문제가 될수 있지만 ,이건 오히려 프로그램을 C보다 더 견고하게 해주는 C++적인 면이기때문에 , 문제 삼기는 조금 곤란하다 생각합니다
따라서 어떤면에서 심각한 문제가 발생하는지 궁금합니다

C++은 논외로 붙이셨는데 , 왜 논외로 붙이셨는지 정확한 말씀을 해주셔야 이해가 갈거 같습니다
C++의 패러다임은 분명 명확하고 , 그것내에서 충실히 확장이 이루어지고 있다고 생각합니다

K&R의 머릿말과 같이,

그런데 C++은 작아 보이지는 않네요. :(

객체 지향은 좋지요. :)

얻는 것이 있으면 잃는 것도 있지 않을까요?

그리고 김재우씨의 글이 언급되었는데, 그 글이 Haskell을 쓰자는, 그러니까 Functional Programming의 패러다임을 받아들이자는 글이 아닐까라는 생각이 듭니다. 그런 글에서 C나 C++과 같은 옛 패러다임을 옹호했다는 것이 약간 이해가 되지 않습니다. (제가 아는 Functional Programming Mania들과 약간 달라 보여서요.)

처음에 구현한 언어가 중요한 것이 아닙니다. 현재의 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: 김재우씨의 이름을 잘못적어서 중간에 수정을 했습니다. 죄송합니다.

의견을 피력한데에 대해 민감하게 반응하지 않으셨으면 좋겠네요. 어디 무서워서 말이나 꺼내겠습니까? :)

이쯤에서 이런 류의 Flame전쟁의 이정도 시점에 항상 등장하는 Bjarne Stroustrup의 말을 한마디 인용해보는것도 재미있을것 같습니다. C++이 완벽하다면 그 이후의 프로그래밍 언어의 개발은 아예 없었겠지요. 그죠? :)

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

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

제가 말을 잘못 꺼내서인지 Risapapa님이 꺼내신 주제와 다른곳으로 글이 흘러가버렸습니다. 죄송하구요.. 단순히 몇자만 언급하고자 합니다. 지금 시간이 없어서 .. 그리고 좀더 깊이 논의하자면 다시 주제를 올리는 것이 바람직 하다고 생각됩니다.

아주 간단한 예로 C의 표준 함수중 malloc와 같은 메모리 할당함수를 C++에서 사용하게 되면 상당히 심각한 문제가 발생합니다. 그렇다고 사용하지 않을수도 없습니다. realloc가 필요할 때도 있으니까요. new로 메모리를 할당하고 realloc로 크기를 변경할수는 없지요. 그렇기때문에 둘을 섞어 쓰다보면 코드가 그다지 바람직하지 않은 방향으로 흘러가게 됩니다.

다음으로.. 제가 C++로 제대로 된 프로젝트를 해보지는 않았지만 팀으로 구성을 해서 간단히 프로젝트를 해봤습니다. 인정하셨듯이 C++의 범위가 커서 그런지 각자가 같은 것을 구현해도 다른 방법을 사용하게 되기도 합니다. 이것은 팀프로젝트에 그다지 좋지 않은 영향을 줍니다. 결국 한명이 반 이상을 뜯어 고쳤습니다. 물론 제대로 알지 못한 사람들이 시작해서 이런 문제가 일어났다고 할수도 있겠지만 자바나 C는 이렇게까지 문제가 커질만큼을 허용하지 않습니다.

저는 템플릿을 좋아합니다. C++에서는 이 템플릿이 가장 매력이 있는 것 같습니다. 물론 자바에서 Object클래스를 상속해서 거의 해결할 수 있는 문제고 이 방향이 더 적절하다고 생각되지만 C++에서 템플릿 역시 매력적인 요소입니다. 저 역시도 C에 적절한 형태로 템플릿 기능이 추가된다면 좋겠다는 생각을 합니다.

이부분에 관한부분은 어쩔수 없다고 생각되네요, Wanning이나 컴파일러 에러를 찾아 수정을 할수 밖에 없다고 생각이 됩니다
C++의 기능을 쓰기 위해 변경하는거라면 , 이정도는 어쩔수 없이 감수해야 한다고 봅니다
[제눈에는 문자열 상수를 int형 썼다면 오히려 더 안좋은 프로그래밍처럼보이네요, 차라리 수정하는것만 못할거 같습니다, ]

물론 C와 C++은 다른 세계라는것에 동감을 합니다 , 다만 C의 코드가
C++ 컴파일러에서 수정없이 컴파일 되며 결국 C컴파일러에서 컴파일한거와
같이 똑같이 작동을 해준다는 의미였습니다 [100%는 아니죠]
당연히 C++에서 사용하는 방식이나 의미가 C로가는 방향으로는 성립하지
않습니다 ,
그말이 C++이 C와 호환성이 있다는거지 C가 C++과 호환성이 있다는 말은
전혀 아니었습니다, 저도 전에 글에도 말씀드렸던걸로 기억되네요

C++ 표준이 100% 명확하진 못합니다 , Effective STL에서 보면
표준화 의원들이 vector<bool>에 대해 잘못 정의했다고 말을 합니다
의미나 명확성이, 성립할수 없는것을 표준화 시켰다는것이지요
하지만 이것이 패러다임과는 무관한것이라 보이네요
이건 패러다임이 아니라 , 기술적인 부분에 관한 부분이라 볼수 있습니다

그리고 이미 표준에 99.81% 부합하는컴파일러는 존재합니다
intel C++ 컴파일러도 99.51%지키고 있습니다
VC++ 7.1또한 98%이상 지키고 있고요

gcc가 표준을 완벽히 지원하지 못하는건 순전히 GNU쪽에서
완벽히 지원하기에 여력이 없는것이지, 패러다임이 명확하지
못해서는 아니라고 봅니다 [하지만 버전이 올라갈수록 표준에 완벽히
가까워지고 있는데, 이것은 어떻게 설명이 될까요? 3.3은 96%이상 지키고 있습니다]

게다가 VC++ 6.0이 표준을 지키지 못한건 VC++상업성을 이용한 비표준 방향으로 컴파일러를 만들었기때문기때문이고 , 표준 자체가 워낙 방대해서
완전히 만족시키기 어렵기 때문이기도 합니다,
[언어가 방대해지면 컴파일러 만들기는 원래 어렵습니다,표준과 패러다임과의
관계를 잘못 연결시킨게 아닌가 싶네요, 자바에 GJ가 제안한 표준을 추가한다면
자바 역시 문법을 지키기위해 컴파일러가 좀더 복잡해 질것입니다,]

이건 비단 C++만의 표준 문제가 아닌걸로 보입니다

표준화에 대해 더 말씀 드리자면 posix 표준도 사실 , 완벽하지 않으며
오류또한 있는걸로 알고있습니다,따라서
posix 표준도 계속 발전하고 있습니다
C++도 마찬가지라 보이고요
C언어도 예전 표준 대신 , C99표준이 나온것 역시 기존의 표준에 부족한점이 많기때문에 나온게 아닌가 싶습니다

말씀하신 패러다임과 표준을 연결시키기에는 무리가 있는거 같네요

혼란을 가진것은 C++을 가지고 C++과 C스타일 둘다 씀으로써 발생한다고
볼수 있는데, 이건 언어의 문제가 아니라 사람의 문제라 다시 말씀 드릴수 있습니다 , C++로 그렇게 부정확하게 쓴다면 , C로 짜는게 나을지도 모릅니다
분명 C++에서 쓰는것과 C에서 쓰는것을 섞어 쓰면 곤란한경우가 있습니다
이럴때는 그부분을 완전히 C스타일로 가던가 C++스타일로 가야합니다
밑에 인용과 더블어 추가적으로 더 설명을 드리겠습니다

C코드와 C++코드가 100%는 물론 아니기때문에 이정도는 감수해야 할거로
보입니다 ,그리고 malloc를 사용해서 메모리를 사용했다면 거기에다가는
C표준 함수만 사용하면 됩니다, 예를들어 malloc으로 할당한것을 free하지 않고 delete를 한다면 이건 사용자 문제가 됩니다 , 굳이 꼭 C++에서
제대로 섞어 쓰기가 지원되지 않는다는것은 오해의 여지가 있습니다
윈도우 C API 에서 HANDLE를 만드는 함수를 호출하고 해제할때
CloseHandle로 닫지 않고 다른 함수를 호출해 해제한다고 한다면
그것역시 문제가 될것입니다 , 이건 사용자에 대한 책임 문제로 봐집니다

C++에서도 C함수를 섞어써도 문제는 없지만
C++연산자와 C함수를 비매칭해 써도 된다는건 아니죠
정확히 매칭되는것끼리 쓰면 문제가 안됩니다

엄연히 다른 함수를 연결해 사용했다고 볼수 있는데 , 문제가 될수 있는건
당연한거기도 하지요,이것은 C++를 전혀 모르는 사람이 C++연산자와
C함수를 비매칭한 경우이고

이건 C++에 대한 이해 부족에서 나오는 상황이므로 다시 말씀 드리진 않겠습니다 , 언어의 문제가 아니라 사람의 이해 부족에서 나오는거니까요
[realloc이 필요하다면 malloc만을 쓰면 되고 , C++ 방식으로 하자면 재할당하는 수밖에 없습니다,C++방식을 써서 해결하던 C방식으로 해결하던 이건 선택일뿐입니다,이것을 썪어 쓸라고 하니까 문제가 되는것이지요 ]

자부심을 느낄만한것이 템플릿밖에 없다고 느끼셨다니 개인적으로 안타깝네요

그리고 주제와 다른 방향으로 흘러갔는데 , 기왕이면 다른 주제로 글을 올리는것이 좋지 않을까 싶습니다 , 주제를 보고 글을 보러 오는 분들에게 혼란을 줄거 같네요

제 생각입니다만, C++의 범위가 커서 프로젝트가 좋은 영향을 받지 못한 게 아닙니다. 다만 C++ 언어가 다양한 방법으로 표현될 수 있기 때문에 팀 원들이 서로 구현한 내용이 다를 수 있는 것입니다. 결과가 같다고 해서 중간 과정이 같다고 보는 것이 무리인 것과 같은 의미입니다.

프로젝트를 진행하는 것은 팀원간의 꾸준한 협의가 필요한 일입니다. 다양한 문제점에 대해 논의하고 의견을 맞춰가면서 진행하는 것입니다. 개개인의 코드가 결과물에 맞지 않는 다면 언어적인 문제로 볼 것이 아닌것 같습니다.

한명이 반 이상을 뜯어 고쳤다는 말은 다른 사람이 쓴 코드가 내부적으로든 외부적으로든 전체 프로젝트에 적합하지 않아서 고쳤다는 말로 들립니다. 이 말은 언어의 범위가 크다는 것과는 별개로 보입니다. 안 그렇습니까?

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

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

글 읽고 있었는데 나누어졌네요.. 잠시 하고 싶은 말을 하겠습니다.

계속 언어문제가 아니라 사람 문제라고 말씀하시고 계십니다. 제가 확실히 드리는 말은 앞에서도 말씀드렸듯이 C나 자바는 이렇게까지 허용하지 않는다는 것입니다. 조금 다른 형태의 언어이긴 하지만 꽤 잘 설계되었다고 보여지는 ML에서도 가능할까요? 제가 생각할때는 거의 불가능입니다.

ML에서도 객체지향이 가능하며 특히 ML은 type이 미리 정의되지 않은 Generic type을 사용할 수 있기 때문에 템플릿같은 것도 굳이 필요하지 않습니다. 물론 언어를 비교한다는 것은 바른 행동은 아니지만 굳이 말씀드리자면 C++은 이에 비하면 비효율적으로 설계되었습니다. 다시한번 말씀드리건데 사람이 문제가 되기도 하지만 언어는 어느정도 그런 문제를 막아줄 수 있습니다.

사실 엄밀히 말하면 C를 C++에서 섞어 쓸 수 있도록 한것은 컴파일러 개발자들 탓도 있습니다. 제 눈에는 이런것들이 C++의 탓으로 들어왔지만 객관적으로 고려해볼때 컴파일러 제공자들이 C라이브러리도 사용할 수 있도록 제공해왔기 때문이기도 합니다. 그리고 그럴 수 밖에 없었던 것은 당시 상황이었으며 또한 C++의 완벽성 부재라고 볼 수 있습니다. 말씀대로 완벽할수는 없습니다. 하지만 이런 일반적인 사용자들 특히 저같은 사람에게도 문제로 다가올 정도라면 재고해봐야지 않을까 하는 생각이 듭니다.

그리고 제가 보기엔 이 토론 주제가 좀 잘못 된것 같습니다. C는 C++의 확장이 아니라는 것은 자명한 사실입니다. 하지만 그렇다고 완전히 불리된 다른것으로 생각하기에는 제공되고 있는 컴파일러들에 의하면 무리가 있습니다. 둘 사이는 조금 불편한 관계이지요.

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++만든사람이 상당히 우울할듯 보입니다. ^^;

역시 토론에서 얻는 것은 단순한 결론보다 새로운 대안으로 발전해 나가기 위함이 아닐까 싶네요.
저의 결론: 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++는 C보다 못할 때가 많습니다. 특히 Class를
이용한 캡슐화의 부분에서인데...

1. Base Class의 Instance Variable이 바뀌면 전부 컴파일을 해야한다.
때문에 원 베이스의 소스가 항상 필요합니다. 처음에 설계를 잘 하면
이런 경우가 없다라고 주로 반박을 하는데 실제로 그런일은 없습니다. 관련
논문들은 보시면 FBC Problem에 대해서는 대체로 동의하고 있습니다.

2. Base Class에 새로운 Method를 추가하면 전부 새로 컴파일을 해야
한다. 역시 1과 마찬가지의 문제가 있죠.

C++이 좋지 않으므로 절대 써서는 안된다는 말은 틀린 말입니다. 그러나
그 목적에 따라서 좋지 않을 수도 있고 특히 위와 같은 경우가 가정 중요한
목표라면 C++는 선택대상이 아닙니다.

객체 스타일의(Alan Kay가 말한 것 처럼 저도 C++가 OOP라는 말을 들을
수 있기에는 너무 모자랍니다. 아니면 너무 멀리 있거나...) 프로그래밍을
적당히 이용을 하되 정적인 형검사가 중요하고 성능이 꽤, 그러나
최고의 목표는 아닌, 그런 경우가 가장 C++가 적절한 경우가 아닐까 합니다.

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

C언어는 보다 지원이 좋지 못한 환경에서도 널리 쓰입니다. C언어의 표준은 그런 좋지 못한 환경을 감안해서 만들어집니다.

위에서 C언어의 소스가 C++에서 되지 않는 경우도 보여드렸습니다. 주석으로 C와 C++에서 같은 의미를 다르게 표현하는 경우를 표시해두었습니다. c언어에서 struct는 tag가 같더라도 다른 자료형으로 인식하고 tag는 자료형의 namespace와 별개로 운영됩니다. 당장에 c소스들의 확장자를 cpp로 바꿔도 namespace의 충돌로 문제가 되는 프로그램들이 많습니다.

c++의 대부분의 특성에서 기술적인 문제점을 찾을 수 있습니다. 심지어 템플릿이나 예외에서도 찾을수가 있습니다. c++의 표준조차도 깔끔하게 정의를 내리지 못하는 부분들도 많습니다. 그리고 패러다임은 매력적으로 보이지만 실제로는 나쁜 부분도 있습니다. RTTI같은 개념들은 그 자체로 나쁘다고 봅니다.

출처가 어떻게 되는 지 궁금합니다. 제가 아는 VC++ 7.1에서 안되는 것들은 적어도 아래의 것들이 있습니다. 98% 이상이란 것에 선뜻 동의하기 힘들군요.

Bobby Schmid는 Microsoft쪽의 사람입니다. VC++ 6.0시절때 아직 안되는 기능과 개선해야 할점과 표준에서 지키지 말아야할 나쁜 점을 지적했습니다. 그는 템플릿, RTTI, 예외, 네임스페이스 등 c++의 대부분의 부분에서 기술적인 오류에 대해서 비판했습니다. 표준이 방대한 것만이 이유는 아니라고 봅니다.

언어가 방대해지면 컴파일러를 만들기 어렵다는 것에 동의하지만 템플릿과 같은 개념들은 구조적으로 컴파일러의 큰 변경을 필요로 하지 않습니다. 컴파일러는 오버로딩등을 감안해서 클래스, 함수의 네임을 자의적으로 변경시킵니다. 템플릿 하나가 끼어든다고 네임스페이스가 혼란해지거나 컴파일러의 구조가 바뀌지는 않습니다.

표준의 불 완정성에 대해서는 동의 합니다. 하지만 많은 c++의 패러다임은 ad hoc인 부분이 있습니다. c++은 강력하지만 잘 사용해야 하는 언어이죠..

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

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

저는 템플릿 밖에 라기 보다... 템플릿 씩이나... 라고 생각을 하고 있습니다. :)

사실 저도 C++을 잘하지는 못하지만 요즘 계속 파이썬 코드를 C++로 포팅하면서 의외의 심플함에 놀랐습니다.

아시다시피 파이썬의 편리함은 이루 말 할 수 없습니다. 그래서 처음 작업을 맡았을 때는 무척 두려웠습니다만... 이럴 때 STL이 정말 힘을 주더군요. 결과적으로 실제 코드량이 파이썬과 크게 차이가 나지 않았습니다.

그리고 항상 뜨거운 감자인 다중상속... 이게 템플릿을 쓰니 필요해지더군요. Morden C++ Design에 사용 예가 나오더군요.

템플릿 메타프로그래밍이나 다양한 주제들이 아직 C++은 더 공부해볼만한 가치가 있는 언어라는 희망을 주고 있습니다. 심지어 boost에 labda까지 구현한 분이 계시더군요.(정말 놀랐습니다 :shock: )

C++이 위험요소를 내포하고 있다기 보단 너무 많은 것들을 허용해 줘서 프로그래머가 위험요소를 내포하게 만드는 것이 아닌가 싶습니다. 필요 이상의 포인터 남발만 자제하면 위험요소나 메모리 누수 같은 문제들도 크게 걱정은 없을 것 같습니다. 전 오히려 가베지컬렉션 기능이 좀 찝찝하더군요. :D

주제에 벗어난 글 올린점 죄송하게 생각합니다만 저 역시 C++을 좋아하는 한 사람으로서 올린 글이니 너그러이 용서해 주십시오. :wink:

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

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

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

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

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

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

말씀하신 대로 이런 문제가 있습니다. 현업 개발에서도 꽤나 걸림돌이죠. 대규모 프로젝트의 경우 당장 컴파일 타임의 증가만 해도 짜증날 정도지요.

하지만 약간의 노력과 생각으로 이 문제를 최소화 할 수는 있지 않을까 싶네요.

1. 상속의 경우 C++에서 friend 다음으로 결합도가 높습니다. 아예 안 쓸수는 없지만 최대한 상속의 사용을 줄아는 것이 좋다고 봅니다. 가상함수를 이용한 추상화의 경우를 제외하곤 가급적 Composition을 쓰는 것이 좋다는 얘기도 있습니다.

2. Composition의 경우 역시 의존도 문제가 발생합니다. 멤버에 수정이 가해지는 경우겠지요. 이런 경우도 Hubb Sutter의 Compiler Firewall Idiom으로 최소화 할 수 있습니다. 덤으로 private멤버를 아예 헤더에서 없앨 수도 있어 마음에 듭니다.

결국 100% 없앨 수는 없지만 최대한 줄일 수는 있다고 봅니다. 역시 C++에는 많은 자유가 있다고 해야 할까요. :D

자세한것들은 이제 서서히 다른분들이 답변을 해주고 있는 상태이므로
굳이 더 이상 글을 길게 쓰지 않고 , 자료만 일단 드리도록 하겠습니다

[위에 CN님이 말씀하신 문법상의 약간의 차이는 충분히 감안할수 있는 내용으로 보여지네요,C++로 오면서 더 견고해지거나 명확해지는 면이라 생각합니다,특히 const 같은 경우에는 더욱요]

참고로 99.81%라고 한게 있는데 실수 인거 같습니다 99.70%네요

이건 데브피아 노영선님이 올리신 자료입니다

인정합니다만은... "언어가 좋다 나쁘다"로 싸운다는 식으로
글을 보신것은 , 잘못 보신걸로 압니다

그리고 ,정확하지도 않고 ,
잘못된 판단으로 여기지는 부분으로 자기가 좋아하고 연구하는 언어를
폄하할때는 , 이런 문제가 충분히 발생할수 있지 않나 싶네요

제가 만약 C언어의 단점이 아닌것을 가지고 단점으로 치부하며
포인터를 쓰는 C는 유지보수도 불가능하고, 구조적 절차로 프로그래밍하는
안좋은 언어라고 글을 쓴다면 어떨까요?

또
리눅스를 연구하는 사람에게 리눅스의 문제가 아닌 문제로 걸고 넘어지며,
윈도우보다 후져..... 이랬다면 결과가 어떻게 나오냐는것이지요
문제는 거기에 있었다고 봅니다
그렇게 입장을 바꿔 생각하면 좋을듯 싶네요

그리고 말씀하신 시선으로 이 토론을 굳이 바랄볼필요는 없을듯 싶은데요?
이미 그런 수준에서 오고가는 토론이 아닌듯 싶습니다,

위는 문제가 발생한 제 글을 인용한 것입니다. 하지만 저는 C++이 단순히 나쁘다고 하기 위함이 아니었습니다. 제 생각에는 개선할 필요가 있다는 것이었지요. 제가 좀 말을 심하게 했는지도 모르겠습니다. 대체라는 단어를 썼기 때문입니다.

mastercho님은 저와 언어를 바라보는 시각이 다르기 대문에 문제가 발생한것 같습니다. 저는 어느 언어를 좋아하거나 좋아하지 않기는 해도 그 언어에 대한 자부심과 매달리는 것은 없습니다. 언어는 단지 도구이기 때문이지요. 어느사람이 하나의 망치로 못질을 하기 좋다고 해서 그 망치를 좋아한다고 해서 그 망치가 없어진다고 못질을 못하지 않듯이 해당 언어가 없어진다고 해서 프로그래밍을 못하지도 않습니다. 저는 개인적으로 C와 JAVA를 좋아합니다. 특히 JAVA를 좋아하는데 단점을 지적해주신다면 인정할 수 있습니다. 그리고 OS는 리눅스를 좋아하는데 단점이 있는것은 사실입니다. 이런 단점을 개선한다는 것은 좋은 일이라고 생각합니다.

저도 hangulee님에게 개인적인 감정은 없습니다
다만 제가 , 문제가 아니다고 느낀것을 문제 삼아 말씀하시기에 저도 모르게
발끈 한거 같네요,
사실 은근슬쩍 hangulee님 처럼 평소에 이렇게 생각하는 분들이
생각보다 많았고 , 그거에 대해 저도 모르게 불만이 잠재해 있었던거 같습니다
감정이 상하지 않으셨으면 좋겠습니다 :(

윈도우에서 리눅스보다 GUI가 쉽게 된다고 윈도우가 무조건 더 좋은게 아니듯이요

일단 현재 C++의 주요한 사용처를 대체하는 언어는 등장하지 않고 있다는 전제에 동의를 요구하는 데서 시작하겠습니다. 왜냐하면 최적화된 성능이 필요한 초대형 상업용 소프트웨어(최신 윈도우 운영체제나 오피스 소프트웨어-오픈 오피스까지도, 그리고 대부분의 게임소프트웨어들 이곳을 참조하세요: http://www.research.att.com/~bs/applications.html ) 는 현재까지 거의 대부분이 C++을 사용해서 제작되고 있기 때문입니다. 물론 apache bind gimp등등 c만을 사용해서 작성되는 소프트웨어들이 있지만, 상용이 아니라는 점에서 빼겠습니다. 프로그래머가 스스로 작성한 소프트웨어를 판매 그자체로 먹고 살 수 있는 소프트웨어만을 대상으로 하겠습니다.
C++ 자체의 효용성과 성능은 초대형 상업용 소프트웨어가 당연한 듯이 C++로 만들어지고 있는 상황을 보면 어느정도는 확신을 가져도 된다고 생각합니다. 문제는 언어 자체가 프로그래머가 정말 공들여 작성해야 쓸만한 코드가 나오고, 언어자체에 대한 제대로된 학습이 부족한 상황에서 작성한 코드는 정말 유지보수가 불가능해지는 경우가 많다는 점인 것 같습니다.(물론 다른 대부분의 언어도 비슷하기는 합니다. 하지만 유독 C++만 이 문제점이 자주 그리고 맹렬하게 지적되더군요.) 이 문제점으로 인하여 C++의 단점만을 잡고 보면 정말 엄청나게 후진 언어로 보이지만, 현재 상황에서 정말 그 프로그램 가지고 제대로 먹고 살 수 있는 소프트웨어를 만드는 데는 C++을 쓸 수 밖에 없는 상황입니다. (애플사등 몇몇 소수의 플래폼에서 운용되는 전용 소프트웨어에 관해서는 일단 빼고 생각하겠습니다.)
결국 C++이 정말 좋지 않다고 생각하는 사람들이 뜻을 함께모아서 C++을 사용하지 않고도 초대형 상업 소프트웨어 작성 및 유지보수가 가능하다는 것을 보여준다면 이후 새로운 언어가 C++의 자리를 대체할 가능성이 생기리라고 봅니다. 그런 일이 생기려면 일단 ms가 확실히 C++ 대신 다른 언어를 사용하여 윈도 운영체제를 작성한다면 좋을 것 같습니다.
프로그래머 사회에서 C++이 많이 사용되는 만큼 C++에 관한 비판이 매우 자주 올라오고 그것에대해서 C++ 매니아들이 노이로제가 걸려있는 만큼 이 이야기만 나오면 분위기가 험악해지는 것 같습니다. C++을 비판은 좋지만, C++ 매니아들의 기분을 상하게 할 수 있는 단점만을 들쑤시는 글들은 좋지 않은 것 같습니다.
C++을 사용하시고, 또 C++에대한 생각과 느낌을 적고 싶으신 분들은 최소한 다음의 홈페이지에 나오는 수많은 글과 인터뷰을 보시고 혹시 자신이 생각하던 단점에 대해 직접 C++창시자에게 질문한 글이 있는지 확인해 보십시오. 저같은 경우도 약 2년간을 C++을 조금만 안채로 C++을 비난하고 거부하면서 보냈지만, 지금은 열렬한 C++매니아입니다. 스트라웁씨의 홈페이지에서 저는 많은 것을 새로 알고 생각을 바꿀 수 있었습니다.
http://www.research.att.com/~bs/homepage.html
이곳에서 언급되지 않은 내용은 C++에 관한 수많은 명서들에서 해답과 이유를 얻을 수 있었습니다만 그 내용은 여기에 연결할 수 없으니 포기하겠습니다.
물론 C++을 정말 많이 아시고, 또한 그것을 제대로 사용한 소프트웨어를 작성하신 다음 비판하시는 분들에 대해서는 그 비판을 잘 읽고 받아들일 수 밖에 없을 것 같습니다.
제대한 환경에서 시간에 쫓기며 글을 써서 한번 읽어보고 정리도 못한 채로 올리게 되어 글이 왔다갔다일 것 같은 데 좀 이해해 주시기 바랍니다.