· KLDP.org · KLDP.net · KLDP Wiki · KLDP BBS ·
CAndCPlus Plus토론


from 다큐먼트모드, 문서구조조정 진행중입니다. 다큐먼트모드중 NoSmoke:OneLinersFight'''는 특별한 일 없는 한 지양되었으면 좋겠습니다. 해당 글 작성자 분들이 다큐먼트모드로 진행해주신다면 더욱 더 정확한 문서가 되리라 생각합니다.

혹시 원저자의 본래 의도가 훼손되었다고 생각되시는 분은 위키의 특성을 살려서 바로 보완해주신다면 모두에게 좋은 글이 되리라 생각합니다.

회의 방법중 '상대방의 의견에 반대는 할수 없고 개선만 가능한 회의'가 있다고 합니다. 그러한 방법으로 개선된다면 더욱 더 좋을 것 같습니다.

  • 일부러 존칭어는 생략하고 문체를 좀 건조하게 해봤습니다. 건조한 대신 사실 중심으로 표현될것 같아서..(추측입니다.;)
  • 진행중 입니다.

1. C 의 장점

  • 언어가 간결하다.
  • 구문이 상대적으로 단순하고 특별히 고려해줄 필요가 없다.
(from 이한길)

C 로 개발할 경우가 있는데, 이 때는 주로 method 들이 위주가 되어 있는 간단한 utility 들을 만들때 입니다. - class 를 일단 쓰기 시작하면 섬세한 작업과 귀찮은 libstdc++ linking 문제에 신경쓰이지 않아서 좋습니다. - 가볍다는 생각에 기분이 좋죠. 게다가 nm 으로 출력되는 심볼들의 간결함이 늘 기분좋습니다. (from pynoos)

2. C 의 단점

  • C++에 비하면 재활용성이 떨어진다.
(from 이한길)

3. C++ 의 장점

클래스를 이용해 캡슐화를 하고 이로부터 유지보수 상 장점을 얻을 수 있다. 클래스내부에서 private를 이용하여 유지보수를 위한 리펙토링이 손쉽게 할수 있다. class를 유틸리티나 라이브리러로 컴포턴트화 하면 , 다음 프로젝트때 재사용하기 용이하다. (from mastercho)

생성/소멸자의 존재가 C에서는 struct안의 struct들을 해제할 경우 삽질을 해야하는 경우에 대해 간편한 도구로 사용된다. Virtual Function Table 이라는 개념으로 구현된 virtual member function 들은 C 에서 함수 포인터 구조체를 통해 구현되는 Interface 제작에 비해 상당한 노력을 절감하여 준다. 상당수 STL을 사용하여 제작하게 되는 set, vector등은 직접 list 등의 자료구조 구현에 신경쓰지 않아도 된다. 생각이 자유로워진다는 느낌을 받는다. C++의 강력한 타입체크 기능에 익숙하게 되면, C의 코드가 더 풍부해지는 것을 경험한다. (from pynoos)

4. C++ 의 단점

  • C의 표준 함수를 더블어 사용할 수 있고 그로 인해 야기되는 문제들이있다.

유지보수의 측면에서의 Class를 이용한 캡슐화의 부분.
  • Base Class의 Instance Variable이 바뀌면 전부 컴파일을 해야한다. 때문에 원 베이스의 소스가 항상 필요하다. 처음에 설계를 잘 하면 이런 경우가 없다라고 주로 반박을 하는데 실제로 그런일은 없다. 관련 논문들은 보시면 FBC Problem에 대해서는 대체로 동의하고 있다.
  • Base Class에 새로운 Method를 추가하면 전부 새로 컴파일을 해야 한다. 역시 위와 마찬가지의 문제.
(from chunsj)

이는 현업 개발에서도 꽤나 걸림돌이 된다. 대규모 프로젝트의 경우 당장 컴파일 타임의 증가만 해도 짜증이 날 정도이다.

약간의 노력과 생각으로 이 문제를 최소화 할 수 있으리라 생각한다.
  1. 상속의 경우 C++에서 friend 다음으로 결합도가 높다. 아예 안 쓸 수는 없지만 최대한 상속의 사용을 줄이는 것이 좋다고 본다. 가상함수를 이용한 추상화의 경우를 제외하곤 가급적 Composition을 쓰는 것이 좋다는 얘기도 있다.
  2. Composition의 경우 역시 의존도 문제가 발생한다. 멤버에 수정이 가해지는 경우인데, 이런 경우도 Hubb Sutter의 Compiler Firewall Idiom으로 최소화 할 수 있다. 덤으로 private멤버를 아예 헤더에서 없앨 수도 있다.
(from corba)

자유라기 보다는 C++의 문제를 돌아가는 방법이라 본다. 상속을 쓰는 것을 피해야 한다면, 그건 깊은 상속을 마구 사용하는 것 만큼이나 위험하다 생각한다. 차라리 언어가 개선이 되는게 나은 방향이 아닐까. (from chunsj)

5. 언어의 표현력, 양날의 검?

{{| "자바 프로그래머중에는 GJ(자바언어의 확장) 제안을 받아들이는 경우 자바의 단순함이나 간결함을 해칠것이라 걱정하는 이들이 있는데, 이는 틀린 생각이다, 어떤 언어의 표현력이 늘었다고 해서 그 언어의 의미 체계를 고쳐써야 한다면, 그 책임은 그런 기법에 있는게 아니라 언어 자체에 있다, 정말 좋은 언어라면 표현력을 더하기 위해 언어를 확장해도 기본이 되는 언어의 알맹이가 뒤틀리거나 흐트러지지 않으며 불어나지도 않는다" -- 김재우, (마이크로 소프트웨어의 2002년 01월호 "더 높은 프로그래밍의 세계 Haskell로 가자" 중) |}} 언어가 확장되고 방대하다고 해서 언어가 나빠지진 않는다. C++은 언어적인 측면에서 C를 확장하고 수많은 패러다임을 흡수한것뿐이며, 언어적인면에서 엄청난 발전을 이루었다고 볼수 있는것이지 이렇게 방대하게 느껴지는것을 , 언어적인 측면에서 단순하지 않다며 나쁘다고 주장하는것은 잘못됐다고 본다. {{| "자바가 잘 설계된 언어라면 GJ제안은 부담이 아니라 불편하고 모자라는 부분을 채워주는 치료제가 될 것이 틀림없고,더구나 그것이 GJ제안이라면 추가된 특징을 쓰지 않는 바이너리와 완전한 호환성을 보장하는 기술이라 큰 문제가 없다" -- 김재우 (즉, Generic Progamming 은 여전히 Type-Strong 이기 때문에, 컴파일러의 역할이 추가될 뿐이지 바이너리 상으로는 차이가 없게 된다.) |}} 위글에 주장하는 바에 따르면 C++에서는 C의 수많은 단점을 극복해주었고, 표현력 상 모자라는 부분을 채워준 것이다. 쓰기 힘든 기능에 대해서는 사용하지 않으면 된다. (mastercho 님 글중)

C++로 제대로 된 프로젝트를 해보지는 않았지만 팀으로 구성을 해서 간단히 프로젝트를 해보았다. C++의 범위(표현방법, 페러다임)가 커서 그런지 각자가 같은 것을 구현해도 다른 방법을 사용하게 되기도 한다. 이것은 팀프로젝트에 그다지 좋지 않은 영향을 준다. 결국 한명이 반 이상(조금 과장해서)을 뜯어 고쳤다. 물론 제대로 알지 못한 사람들이 시작해서 이런 문제가 일어났다고 할수도 있겠지만 자바나 C는 이렇게까지 문제가 커질만큼을 허용하지 않는다. 나는 템플릿을 좋아한다. C++에서는 이 템플릿이 가장 매력이 있는 것 같다. 물론 자바에서 Object클래스를 상속해서 거의 해결할 수 있는 문제고 이 방향이 더 적절하다고 생각되지만 C++에서 템플릿 역시 매력적인 요소이다. C에 적절한 형태로 템플릿 기능이 추가된다면 좋겠다는 생각을 한다. (from 이한길 님 글중)

C++의 범위가 커서 프로젝트가 좋은 영향을 받지 못한 게 아니라 본다. 다만 C++ 언어가 다양한 방법으로 표현될 수 있기 때문에 팀 원들이 서로 구현한 내용이 다를 수 있는 것이다. 결과가 같다고 해서 중간 과정이 같다고 보는 것이 무리인 것과 같은 의미이다. 프로젝트를 진행하는 것은 팀원간의 꾸준한 협의가 필요한 일이다. 다양한 문제점에 대해 논의하고 의견을 맞춰가면서 진행하는 것이다. 개개인의 코드가 결과물에 맞지 않는 다면 언어적인 문제로 볼 것이 아닌것 같다. 한명이 반 이상을 뜯어 고쳤다는 말은 다른 사람이 쓴 코드가 내부적으로든 외부적으로든 전체 프로젝트에 적합하지 않아서 고쳤다는 말로 들린다. 이 말은 언어의 범위가 크다는 것과는 별개로 보인다. (from berise)

처음 시작할때 서로간의 인터페이스까지 모두 정의를 하고 시작했다. 하지만 그럼에도 불구하고 나중에 수정할때에는 단순한 작업이 아니였다. 물론 서로 자주 이야기를 하고 작업을 한쪽에서는 그런 문제가 특별히 발생하지는 않았습니다. 언어의 범위가 크다는 것도 문제가 된다. 구현의 방법에 있어서 의외로 차이가 나게 되기도 하기 때문이다.

C나 자바는 이렇게까지 허용하지 않는다. 조금 다른 형태의 언어이긴 하지만 꽤 잘 설계되었다고 보여지는 ML에서 또한 거의 불가능이다.

ML에서도 객체지향이 가능하며 특히 ML은 type이 미리 정의되지 않은 Generic type을 사용할 수 있기 때문에 템플릿같은 것도 굳이 필요하지 않다. C++은 이에 비하면 비효율적으로 설계되었다. 사람이 문제가 되기도 하지만 언어는 어느정도 그런 문제를 막아줄 수 있다.

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

사용자는 실수를 안한다고 가정하시고 말씀하신다면 할말이 없다. 그러나 실수를 안할 수는 없는 일이고 실수를 하지 않더라도 불필요하게 고려할 사항이 발생하는 것이 C++이라 생각한다. (from 이한길)

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

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

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

요즘 계속 PythonLanguage 코드를 C++로 포팅하면서 STL이 큰 힘이 되었으며 C++ 의 의외의 심플함에 놀랐다. 결과적으로 실제 코드량이 파이썬과 크게 차이가 나지 않았다. 그리고 논란이 많은 다중상속의 경우도 템플릿 프로그래밍을 하면서 필요성을 느끼게 되었다. (이에 대한 예제가 Morden C++ Design 에 언급되어있다.)

템플릿 메타프로그래밍이나 다양한 주제들이 아직 C++은 더 공부해볼만한 가치가 있는 언어라는 희망을 주고 있다. 심지어 boost에 lambda(Functional Programming 에서 사용) 까지 구현한 분도 있다. C++이 위험요소를 내포하고 있다기 보다는 너무 많은 것들을 허용해 줘서 프로그래머가 위험요소를 내포하게 만드는 것이 아닌가 한다. 필요 이상의 포인터 남발만 자제하면 위험요소나 메모리 누수 같은 문제들도 크게 걱정은 없을 것 같다. 난 오히려 가베지컬렉션 기능이 찝찝하다. (from corba)

결국은 사용자의 절제(?)를 믿느냐 마느냐에 달린 것 같다. 그런데 프로젝트들이 작을때는 사실 별 문제가 없지만, 방대해지면 방대해질수록 사람은 믿기 어렵다. 자바나 C#같은 언어가 굳이 대두되고 있는 건 (자바는 뭐 어디서나 실행하자, 라는 게 목적이었을진 몰라도) 결국 사람을 믿기 어렵다는 부분이 많지 않은가 싶다. 컴퓨터가 많은 것을 자동화해주면 해줄수록 문제가 적어진다는 전제 하에 가베지 콜렉션도 하는 것이고, OOP 형태도 다중 상속을 절제하는 형태로 바꾼 것으로 해석해볼 수도 있다. 사람이 완벽히 해낸다면 이런쪽으로 흘러갈 필요가 있을까? (from vacancy)

5.1. Generic Programming 의 도입과 관련한 컴파일러 구현문제

재인용 {{| "자바 프로그래머중에는 GJ바언어의 확장 제안을 받아들이는 경우 자바의 단순함이나 간결함을 해칠것이라 걱정하는 이들이 있는데, 이는 틀린 생각이다, 어떤 언어의 표현력이 늘었다고 해서 그 언어의 의미 체계를 고쳐써야 한다면, 그 책임은 그런 기법에 있는게 아니라 언어 자체에 있다, 정말 좋은 언어라면 표현력을 더하기 위해 언어를 확장해도 기본이 되

는 언어의 알맹이가 뒤틀리거나 흐트러지지 않으며 불어나지도 않는다" -- 김재우, (마이크로 소프트웨어의 2002년 01월호 "더 높은 프로그래밍의 세계 Haskell로 가자" 중) |}} 언어가 확장되고 방대하다고 해서 언어가 나빠지진 않는다. C++은 언어적인 측면에서 C를 확장하고 수많은 패러다임을 흡수한것뿐이며, 언어적인면에서 엄청난 발전을 이루었다고 볼수 있는것이지 이렇게 방대하게 느껴지는것을 , 언어적인 측면에서 단순하지 않다며 나쁘다고 주장하는것은 잘못됐다고 본다. {{| "자바가 잘 설계된 언어라면 GJ제안은 부담이 아니라 불편하고 모자라는 부분을 채워주는 치료제가 될 것이 틀림없고,더구나 그것이 GJ제안이라면 추가된 특징을 쓰지 않는 바이너리와 완전한 호환성을 보장하는 기술이라 큰 문제가 없다" -- 김재우 |}}


위에서 김재우씨가 말한 GJ가 문제가 되지 않는 것은 템플릿과 같은 것은 자료형에 맞게 그 명칭에 맞는 함수나 클래스를 더 만들어주면 해결되는 문제라서 실질적으로 Java 자체가 수정되는 것은 없다. GJ같은 것은 도입해도 좋다. 하지만 그것과 C++는 논외이다. 템플릿 같은 것을 도입한다면 언어의 형식은 늘어나서 표현력은 늘어나게 되지만 컴파일러든 프리프로세서든 자료형에 맞춰서 함수와 클래스를 몇개 더 만들어 주면 되는 문제이다. VM이나 컴파일러의 구조적인 변경없이 기능을 향상시킬수 있다면 표현력의 방향이나 VM과 컴파일러의 안정성의 측면이나 환영받을 수 있다. 하지만 C++은 C컴파일러의 구조적인 변화 없이 불가능하고 난해하다. c++의 export와 같은 키워드는 Bobby Schmid가 장문의 글로 악평을 할만큼 좋지 못하다. C++의 패러다임이 명확했다면 vc++도 표준을 지켰을 것이지만, 현재는 gcc조차도 지키지 못하고 있다. (from CN 님 글중)

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

현재 표준에 99.70% 부합하는 C++ 컴파일러가 존재한다. intel C++ 컴파일러도 99.51% 지키고 있으며 VC++ 7.1또한 98%이상 지키고 있다. gcc가 표준을 완벽히 지원하지 못하는건 순전히 GNU쪽에서 완벽히 지원하기에 여력이 없는것이지, 패러다임이 명확하지 못해서는 아니라 본다. 하지만 버전이 올라갈수록 표준에 완벽히 가까워지고 있는데, 3.3은 96%이상 지키고 있다. (http://anubis.dkuug.dk/jtc1/sc22/wg21/)

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

표준화에 대해 더 말씀 드리자면 posix 표준도 사실 완벽하지 않으며 오류또한 있는걸로 알고 있다. 따라서 posix 표준도 계속 발전하고 있다. C++도 마찬가지라 본다. C언어도 예전 표준 대신 C99 표준이 나온것 역시 기존의 표준에 부족한점이 많기때문에 나온게 아닌가 생각한다. 패러다임과 표준을 연결시키기에는 무리가 있다고 본다. (from mastercho 님 글중) (CN 님 글중 표준과 페러다임 연결시킨 글을 못찾음. 내용을 찾거나, 내용을 못찾았을 경우 관련 의견 삭제 필요)

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

5.2. C++ 은 C 의 확장인가?

5.2.1. 호환성 문제 - 문자열 상수, struct, const

int가 2byte인 시스템에서 int x='hi'는 c에서는 맞다. 문자열 상수도 c언어에서는 int형으로 정의되어 있다. 'hi'와 "hi"는 다르다. 하나는 int형의 크기이고 하나는 3byte이다. c에서 문자열 상수는 int형의 자료를 표현하는 용도를 같이 가지기 때문이다. 반면에 c++에서는 char형은 1 byte이다. 당연하듯이 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로 배열을 정의해보면 알 수 있다. (from CN 님 글중)

저러한 코드에 관한부분은 어쩔수 없다고 생각된다. Wanning이나 컴파일러 에러를 찾아 수정을 할수 밖에 없다고 생각이 든다. C++의 기능을 쓰기 위해 변경하는거라면, 이정도는 어쩔수 없이 감수해야 한다고 본다. 하지만, 문자열 상수를 int형으로 썼다면 오히려 더 안좋은 프로그래밍처럼 보인다. (from mastercho 님 글중)

C언어는 보다 지원이 좋지 못한 환경에서도 널리 쓰인다. C언어의 표준은 그런 좋지 못한 환경을 감안해서 만들어진다. (from CN 님 글중)


C와 C++은 다른 세계라는것에 동감을 한다. 다만 C의 코드가 C++ 컴파일러에서 수정없이 컴파일 되며 결국 C컴파일러에서 컴파일한거와 같이 똑같이 작동을 해준다는 의미다. (100%는 아니지만) 당연히 C++에서 사용하는 방식이나 의미가 C로가는 방향으로는 성립하지 않는다. C++이 C와 호환성이 있다는거지 C가 C++과 호환성이 있다는 말은 아니다. (from mastercho 님 글중)


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

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

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

표준의 불 완정성에 대해서는 동의한다. 하지만 많은 c++의 패러다임은 ad hoc인 부분이 있다. c++은 강력하지만 잘 사용해야 하는 언어다. (from CN 님 글중)

5.3. 비정리 (정리 추가)

NoSmoke:BjarneStroustrup의책내용에서 Historical Note에 보면 C++은 C with Class로 처음에 불려졌으며 추후 C++로 부르게 된 이유가,C에서 기능을 더한 + 결국 C+로 부르려다가 C+라는게 C에서 syntax error이기때문에 C++로 하였다고 한다. (from nightfog)

C++는 언어적으로 C를 확장한 것이 아니다. struct나 const등 같은 키워드는 비슷할 가능성이 있지 호환되지 않는다. C90이상의 C로 짜여진 대형 프로젝트를 C++으로 옮길때 문제점이 발생할수 있다. C++의 템플릿같은 기능들은 매우 훌륭하다고 생각하지만 export와 같은 키워드는 컴파일러가 지원해도 쓰고 싶지 않다. C++이 방대해지면서 장점과 단점을 가졌는데 장점을 골라써야 한다. 현재의 C언어는 C++의 subset이 되지 못한다.

C++은 처음에 C언어로 구현되었다. C언어를 확장에서 C++이 현재 추구하는 패러다임에 맞게끔 수정한 것이다. 지금은 거의 독립되었습니다만은 ,C++의 발전사 자료를 찾아보시면 C에서 확장한 내용을 쉽게 찾을수 있다고 본다. 이부분은 오해의 여지가 남아있기때문에, 딱히 모라 할순 없겠지만 단순히 단답형으로 "아니다"라고 말하기엔 불만이 있다.

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

(from mastercho 님 글중)

6. 기타

6.1. C 이외의, C API 를 지원하는 언어

C++ Objective-C

C++ 보다는 Objective-C가 더 잘 지원한다. 전혀 차이가 없다. C에다가 Smalltalk 방식의 객체 방식을 추가했다. (from chunsj 님 글중)

Objective-C는 C언어의 완벽한 Superset이다. C의 의미구조를 동일하게 사용하면서 객체등의 추가된 개념에 대해서는 다른 방법으로 접근한다. 다른 패러다임을 섞을때에는 Objective-C나 GJ같이 섞어야 한다고 본다. 하지만 컴퓨터에 한가지 언어만 깔수 있다면 Objective-C보다는 C++을 선택하겠다. ;) (from CN 님 글중)

6.2. 기타

C++이 아니라 어떤 언어를 쓰더라도 부족한 능력의 사람이 쓰면 유지 보수는 불가하다. (from astercho 님 글중)

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

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

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

좋은 표현을 찾았는데, 다중 패러다임이 필요한 경우에는 C++가 C언어 비슷한 계열중에서 가장 훌륭합니다. 이게 독이 될 수도, 득이 될 수도 있지만, 짧은 경험으로도 이런 것들이 필요할 때가 있었습니다. - chunsj

6.3. 문서구조조정 작업 의견


GnomeKorea:RenameThisPage to CAndCPlusPlus or CAndCPlusPlusIssues ?
KLDP Wiki의 경우 아직 Naming Rule 이 명확하지 않은 중이여서, 어떤것이건 괜찮을 것 같습니다. (CAndCPlusPlusDiscussion? ;)

저자 이름이 전부 없는데요. 저의 경우 위의 글이 완전한 Document Mode 가 아니라 생각됩니다.(즉, 글을 쓴 사람 내에 다같이 공감하는 부분이 Document Mode 로서 일반화되겠죠) 또는 개개인들의 경험들도 있겠고요. 그러한 부분은 그냥 저자분들의 이름을 남겨두는것이 바람직하지 않을까 생각합니다. --1002
DeleteMe 그렇네요. 그것도 맞는 말씀입니다. --hey
일단 이전 스타일로 돌려보았습니다. 특별히 반론이 제기되지 않은 부분에 대해 삭제하면 될듯 합니다. --1002

문서일지

Contributors는 이 문서 작업에 직접 참여하지 않은 사람을 쓰면 안되겠죠. 글쓴이는 각 인용에 표기되어 있으므로 쓸 필요 없겠구요. Contributors는 애매한 점이 있으므로, 좀 더 설명적으로 문서일지 (혹은 문서바뀐점)라고 하여 맨 하단에 쓰는 것으로 하겠습니다. --WkPark




sponsored by andamiro
sponsored by cdnetworks
sponsored by HP

Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2004-12-13 18:51:03
Processing time 0.0421 sec