그러니까 그렇게 설계한 이유를 묻는거죠

왜그렇게만들었는지를 묻는거지 누가만들었는지를 묻는게아니에요

자동차의 바퀴가 왜 4개인가요 ?? 2륜구동 4륜구동 6~10륜구동도있어요 

왜 4개인가 안정성을위해서 

왜 4개가안정성이있는가 버티고있는 기둥이 4개가되기때문이다 이렇게 간략하게나마 설명할수있잖아요 ??

그렇게만들어서 ? 그럼 사람들은 자동차바퀴가 왜 4개인지도모르고 그냥그렇게만들었으니까 ㅇㅇ 

자동차살때도 아무거나사서 이거안좋아라고하면 아그냥그렇게만들었으니까 ㅇㅇ 

이런반응이아닙니다.

님이대답한거는

내이름은 아무개다 

그이유가뭐냐 라고물어봣을때

몰른다 아빠가지어줘쓰니까 이유는 아빠가알겠지

라고대답하는거랑 다를게없습니다.

말씀하신 요지가 좀 틀린거 같습니다만..

질문글에 단일상속이나 이런것을 빼고 개발자가 아닌 일반인에게 이해시킬수 있는 글을 원하셨다고 적으셔서

위와 같이 답변을 적은것입니다.

바퀴4개가 존재하는 이유는 그당시 기술력으로 가장 저렴하고 안정적인 바퀴의 갯수가 4개였을 뿐입니다.

바퀴는 많을수록 더 안정적이죠

제임스가 설계했을 당시도 동일합니다. 본인이 생각하기에 메모리, 실행속도, 편의성 등등을 따져서 만든것이라 생각됩니다.

참고로, 전 편의성때문이라고 판단됩니다.

그러니 편의성도 어떤편의성

다른언어에비해서 뭐가편하고 어째서편하냐 이거겠지요

그당시 기술력으로 가장저렴하고 안정적인 바퀴의 갯수가 4개다

이건 전문가가아닌 일반인이라도 이해할수있는말을 하신겁니다

설명할수있잖아요 ??

이것또한 어떠한편의성 예를들어서 설명한다면 남들도 쉽게이해할수있겠죠

뭐그게문제가아니고

확실히 무엇인지 파악했는지부터 알아본다고 생각하면되는겁니다.

나는 다른개발자들에 비해서 이걸알고있는가

난이렇게생각하는대 다른사람들은 어떨까의 중심이 저것으로 정했다고 보시면됩니다.

자동차와 바퀴는 일반인들이 자주접하는 물건이라 그나마 저렇게라도 이야기할 수 있습니다만..

일반인들에게 객체와 형변환, 객체추론 등에 대해서는 저는 설명을 못할꺼 같습니다.

저희회사 신입들도 클래스와 객체에 대해 구분을 못하는 이가 태반이더군요....

이런 상황에서 일반인에게 설명한다는건...불가능에 가깝습니다.

일단.. 몇부분을 제외하고 말씀에 전반적으로 동의 못하겠습니다.

 C++은 C에서 점진적으로 발전하지 않았습니다. Assembly -> C 로 점프하듯이 태어났다고 봐야죠.  

언어의 우수성을 이야기하고자 하는건 아닙니다.

창시자인 Bjame Stroustrup(비얀 스트로스트럽)이 Simula67을 참고해서 C에 문법을 첨가해서 어느날 태어난겁니다. 

(그냥 어느날이라고 표현합니다. 물론 학계 논의 정도는 있을꺼라고 생각하는데 찾아보지는 않았습니다.)

데니스 리치가 Assembly 를 사용하다가 B를 참고해서 더 읽기 좋은 고급 언어인 C를 만들어 낸것 처럼 말이죠. 

그리고 최상위 객체가 없는건, C++이 표준에 범용 자료형을 지원하는 SDK 형태의 라이브러리는 C++의 언어 대상에서

고려하지 않았고 실행 시간에 형추론도 표준에 들어가지 않습니다. 그래서 필요가 없습니다. 

객체가 상속마다 가상 테이블이 생기는 구조인데, 필요없는데 구지 넣을 필요는 없죠. 

이 출발점에서 발생하는 다양한 자료에 대한 데이터 구조에 지원은, STL이 표준화 되면서, Template 기법을 이용해서 

Generic, Meta Programming 로 풀었습니다. 

그리고 C++은 만들어지다 보니, 객체 지향 특성을 가졌다기보다는, 보다 애초에 Multi-paradigm 을 

들고나온 범용 언어 입니다. 

그래서 C를 거의 다 포용하고 (실질적으로는 모두), Template을 도입해서 Generic, Meta 까지 포용합니다. 

작성하시면서 깨달으신거 같네요. ;; 

그리고 C++은 생김새가 확장에 가깝기는 하지만, C의 모든걸 포용한다기 보다는 둘은 다른 언어 입니다. 

예를들어, Objective-C 는 문서 시작할때 C의 완전한 Super set 이라고 하지만, C++은 그렇지는 않습니다. 

이론적으로는 다른 언어 이지만 컴파일러 구현 생각은 그렇지 않죠. 어찌 보면 이제는 오히려 C 전용 

컴파일러가 없는 상황이네요 ;;

실제로 C99의 초기화 코드는 C++0x가 제정되기 전에 나와서 호환되지 않기도 했는데, 

컴파일러들이 알아서 구현했습니다. 

Java는 애초에 객체 지향으로 설계한건 동의하지만, 애초 제임스 고슬링이 Embeded 시스템에 들어갈걸 생각해서

구체적인 로직 작성 문법은 C에서 가지고 왔습니다. (이게 위에 다른 분이 말씀하신 코드명 오크(Oak) 에서 시작되었죠. )

그래서 패키징 시스템은 잘 조직해놨는데, 객체지향이면 들어가야 함직한 기본 자료형(Primitive Types)에  

대한 객체화 같은건 빠졌습니다. String, 배열도 좀 사용 일관성이 이상하구요. 

이후 Java 1.2 , 1.3 등장하면서 많이 변했음에도 구 호환성 때문에 현재 처럼 유지되었구요. 

Generic 부분도 타입을 지워버리는 것도 그렇고, Auto boxing 개념도 그렇고, 결국 다소 어정쩡하게 구성된 면이 있습니다.

다만, 처음 언어가 정의될때 SDK가 언어의 범위 걸쳐서 포함되고, 범용 자료형에 대한 데이터 지원이 필요하기 떄문에

위에 언급된 최상위 객체는 필연적으로 도입되었습니다. 

MFC 의 CObject는 Template 기법이 컴파일러에 채택되기 전에 MFC 내부의 자료형들에 대한 데이터를 다루는 SDK

를 제공하기 위해서 도입되었습니다. 하지만 아무래도 객체별 함수 테이블(virtual table) 부하 문제 때문에 이후에 

Template 을 도입한 ATL이 많이 쓰이게 되었고, 지금은 손떈지 오래되서 경향은 잘모르겠네요. 

----

최상위 객체의 개념의 유무가 객체지향을 결정짓는다고 생각하지 않습니다. 

최상위 객체를 가지게되는 주요 이유가 해당 언어의 제정 당시에 데이터 구조를 다루는 SDK 까지 고려해서 

언어가 설계되는가에 영향을 많이 주었다고 생각합니다. 

다행히(?) C/C++ 이외에 대부분의 강타입(Strong Typed) 언어들이 객체 지향을 도입할때  최상위 객체 개념을 

두어서 편하게 쓸수 있게 해두었죠. 대부분 형추론 관련해서 RTTI나 Reflection 도 도입해 두었구요. 

----

제가 이런 장문의 글을 붙이는 이유는, 위의 글이 약간의 오해를 부를만한 부분이 있을것 같기 때문입니다.

커뮤니티에 오는 분들 중 기초를 물어보시는 분들이 종종 있는데, 다소 다른 견해로 검색이나 찾아볼꺼리가 많다는

생각을 주고 싶습니다. 

이런 이론적인건 간단하기는 한데, 생각이 모이기 까지 상당히 많은 논의와 이야기들이 있거든요. ;;

----

원글에 대한 답변

최상위 객체를 설명하기위해 '의견수렴'한다는 표현이 재미있군요. 최상위 객체가 존재하는건 대부분 실행시간에 

형추론(RTTI or Reflection)을 하거나, 데이터 구조를 다루는 범용 라이브러리 코드를 제공하기 위함입니다. 

이렇게 명확한 필요에 의해서 지정해 둔거고, 글짓기 하듯이 의견을 받아서 논의할만한 대상은 아니라 생각합니다.

'왜 필요한가?'를 알기위해서는 그냥 최상위 객체들이 제공하는 기능들을 보면 알수 있습니다. 

그리고, 그냥 저는 이를 프로그래밍을 모르는 일반 분들에게 설명하는 상황 자체를 만들지 않는게 좋을 것 같습니다. 

그래서 설명해야 한다면, '이해'보다 '암기'를 추천합니다.

범용 데이터 형 지원과 형추론을 설명하려면 당연히 객체지향에서 상속과 다형성에 대한 이해가 전제되어야 하고,

강타입(Strong typed) 언어에 대한 이해도 기본되어야 합니다. 

즉, '모든 객체는 Object를 상속한다.' 라는걸 설명하기 위해서 너무 많은걸 이야기 하게 되죠. 

뭐 그만큼쉽게 설명할수있는 방법이있냐 라는거지

구지 설명하려고하는건아니에요 ㅎㅎ

그냥 개발하는형들이랑 술먹다가 왜 자바에는 오브젝트클레스가있고 그게왜 최상위냐

C++도 객체지향아니냐 라고 이야기도나와서 

그러면 그걸 누구나 이해할수있도록 그만큼 기초를 잡은 자바개발자가 몇몇이나될까 등등 이야기나오다보니 ㅋㅋ

최대한 쉽게 설명할수도록 일반인도 이해할수있을만큼 설명할수있는사람이있을까해서 그런글을남긴거지 ㅋㅋㅋ

일반인한태 이런말할일이없죠 ㅠㅠ 제가강사가아닌이상 ㅠㅠ

제가 잘못 이해했기 보다 본문안에 ? 로 끝난 많은 부분 때문에 글을 시작한 김에 그냥 모든것에 답변한 겁니다. 

그에 관해서 설명하실 필요는 없을 것 같습니다. 

더 좋은 질문을 하기 위해 http://wiki.kldp.org/wiki.php/DocbookSgml/Ask-TRANS 일독 추천합니다. 

우선 저는 정통한 지식이 없음을 밝힙니다.^^;;

(단지, 학부시절 교수님께 여쭈어 들은 것과

 제 얕은 지식 내에서 머리를 굴려나온 결론들 뿐이라는 점 참고해주시길 바랍니다.)

1.

MFC의 경우, 매우 깊은 상속이기 때문에

그것(설계) 자체만으로도 런타임 부하가 심하구요.

따라서, 말씀하신 함수테이블의 중복(?)은 부차적인 문제라 생각됩니다.

2.

C와 C++, Java와의 관계에 대해서..

저는 C와 C++이 같다고 말하지는 않았습니다.

다만? 'C와 C++이 다른 언어다' 라고 생각하기에도 무리가 있어보이네요.

단지, 규모의 차이 때문에 그렇게 생각하시는 것인지 여쭙고 싶습니다.

(교수님께서 C와 C++의 규모는 과장해서 1:100 이라는 표현을 쓰셨습니다.)

[ C-절차언어 / JAVA-객체지향언어 ] 라고 한다면, 

C++는 절차언어에 객체지향을 모방한 언어라고 생각합니다.

말씀하신대로, 객체지향 자체만을 보고 설계된 언어가 아니기 때문에,

고려하지 않은 것들에 대한 구조상의 여러가지 문제점이 발생하고 있습니다.

그렇다고, 그게 단점이 될 수는 없고, 단지 C++의 특징이겠죠.

학계 정설이 어떠하느냐를 떠나서,

프로그래머 개개인마다 언어의 특성을 어떻게 이해하느냐가 논점인 듯 싶습니다.

정에약한마음님께서 술자리에서 논의하시던 상황역시 이 문제에서 파생됩니다.

물론, 정설이라는 것도 주류들의 (논의를 통한) 생각의 집합이겠죠. (+언어설계자의 정의)

이것은 팀원으로서 공용화기(언어)를 사용하기에 앞서

같은 청사진을 갖기 위한 상당히 적절하고 현명한 논의라고 생각합니다.

3.

최상위 객체에 대한 말씀은 제가 모르던 부분입니다.

모르던 부분이기에 당연한 부분에 대해서 추론하여 대답했뿐인데, (본문에서 논의를 권유하셨기에)

알고보니 그런 명확한 이유가 있었군요. 감사합니다^^

교수님을 몇번 언급한 것은 맹신이 아니라, 제가 알고있는게 그것 밖에 없어서입니다ㅋㅋ;;

제 얇팍한 지식이 한 없이 드러나는 댓글이 아닐 수 없네요ㅋㅋㅋㅋㅋㅠ_ㅠ

방금 MFC에대해서 조금알았네요 ㄱ-

꼴에 개발자라는놈이 안드로이드말고 아는지식이 하나도없다니 ㅠㅠ

저도 C는 절차언어다 C++객체지향이다 라고만알지

속은몰라요 ㅋㅋㅋ 그냥 안드로이드에서 자바쓰길래 하는거지 ...더배워야하는대 ㄱ-

책보고공부하는건 너무제타입이아니라서 공부도힘들공 미치겠근여 ㅠㅠ 

1

소스보면 virtual table 을 피하는건 매우 중요한 문제라는걸 알수 있습니다. MFC 가 이를 

virtual table을 피하기 위해 온갖 매크로와 기법들을 동원합니다. 

01~02년도에 관심있어서 소스를 읽었을때  가장 인상깊었던 몇 부분이라서 아직도 

그 부분을 읽었을때 전율이 기억납니다. 

각설하고, 말씀하신대로 '매우 깊은 상속'이기 때문에 virtual table 포인팅 부하 우려가 관심사였습니다. 

MFC 첫 구현 시점은 Windows 3.1 이전입니다. (1992) 그리고 가장 많이 배포시작된 

4.x 대가 Windows 95 부터 같이 패키징 되어서 나왔습니다. 

이때 즈음은 C++에서 상속으로 가지고 오는 virtual table의 성능 저하가 이슈 사항이었습니다. 

그외 라이브러리가 데이터 구조와 UI가 분리되어 배포되지 않아서 매우 크다는 문제도 있지만 생략합니다. 

2. 

전 그냥 단순히 해당 팀원들의 관심 부족이라고 생각합니다. 

자명한 스펙이 있는 상황과, 이미 멀티 페러다임으로 설계된 언어에서, 아이디어 회의나 

비지니스의 공유 비전(Shared vision) 처럼 논의해서 정설을 만들어 나가는건 불필요하지 않을까 싶어요. 

이러한 논의가 '좀 더 정확한 문서나 사례를 찾아보자'라는 걸로 결론나야 한다고 생각해요. 

위에서 C++이 같다고 말하지 않은 부분에 인지하고 있지만, 저는 '비슷한 언어, 확장한 언어'라는

관점에 동의하지 않는다는 겁니다. 애초 저자가 다른 언어라고 인터뷰 했었고, 발전 모습을 지켜보면 확연해요.

namespace, Template 도입 이후 확실히 좀 더 다른 모습을 보이고 있습니다. 

C++0x 에서는 lambda 가 들어가는 만큼 확연히 다른 코드를 보실수 있으니 점차 동의하는 부분이 

생기리라 봅니다.  

그 교수님 표현한건 더 동의하기 힘들군요. 왜 그런 표현을 한건지 전후 맥락이 없어서 이해하기 힘듭니다. 

제가 말하는건 C++을 C의 연장선 관점에서 이해되는 것에 대한 경계입니다. 

다시 말씀드리자만, 격하게 반대하는게 아닙니다. 

전 다르게 이해하는 것에는 큰 관심은 없습니다. 

어차피 외국어라서 저도 잘못 이해하고 쓰는게 부지기수일테니까요. 

하지만, 제가 구지 답변을 이어가는건, 이 커뮤니티에 꽤 많은 초보자 분들이 본다고 느끼고, 

첫 글이 의견이라기보다 전문가가 단정적으로 작성했다고 느끼기 때문입니다. 

그 지식이 노출될때, 기본적인 생각꺼리가 있다는 점을 알려주고 싶습니다. 

불편해하지 않으셨으면 합니다. 

3. 생략합니다.

----

그리고 글이 밀리면서 더이상 지켜보기 힘듭니다. 

이후 댓글이 없더라도 이해해 주세요. 

제가 확실하지 않은 생각을 너무 단정지어 말 한 것을 우려하셨군요.

초보자 분들은 보통 논의에는 여러 관점이 있다고 생각치 않고,

사실로 받아들이는 경향이 있으므로, 제 글이 충분히 문제가 될 법 합니다.

좋은 지적 감사드리고, 다행히 저는 지식의 옳고 그름에 대해 불편해하는 타입은 아닙니다^^

위와 같은 문제로 제 댓글(사실이 아닌 부분)들은 삭제하도록 하겠습니다. 창피하네요ㅋㅋ;