C++ 매니아 여러분... 답변좀 부탁 드립니다...
글쓴이: kpserv / 작성시간: 토, 2006/10/28 - 1:24오후
C++ 왜 그리들 열광을 하는지..
한번 빠지면 완전 빠돌이(죄송-_-)가 되더군요!!
저는 C만 쭈욱 해왔습니다...
이번에 C++ 프로젝트가 있어서...
라이브러리 역쉬.. C++로 만드는게 났겠다고 생각하고 C++로 작업을 했습니다...
헌데... 오널 당일 C로 바꿔서 만들어 볼까하고... 만들어 봤는뎅..-_-;;
역쉬 쓰던 언어인 C 가 훨씬 편하고 코딩도 더 잘되구요!!
제가 C만 해와서 그런것 같습니다...
혹 대단한 C++ 소스나... 역쉬 이래서!! 라는 감탄사가 쏟아 질만한 조언좀 부탁 드립니다.
Forums:
STL
비슷한 것은 Java Collection Framework 가 있지만 역시 STL 이 쓰기 좋더군요.
C 에도 비슷한 string 함수들이 있지만...
c언어는 oop가
c언어는 oop가 안되죠..
물론 되도록 삽질을 하는 방법은 있지만.. 그건 삽질일뿐 그게 c++보다 더 편하다든가 성능이 좋다든가 하진 않을겁니다.
c++의 빠돌이는 아니지만 어떤 언어든지 목적에 맞게 사용하는게 제대로된 사용 방법이니까요..
-------------------------------------------------------------------------------
It's better to appear stupid and ask question than to be silent and remain stupid.
-------------------------------------------------------------------------------
It's better to appear stupid and ask question than to be silent and remain stupid.
"C++ 코딩의 정석"(Herb
"C++ 코딩의 정석"(Herb Sutter, Andrei Alexandrescu 공저. 양질의 번역서 있음) 추천드립니다.
ps. 제가 C++에 열광하게 된 이유가 10살때 봤던 이 소스 코드 때문입니다.
#include <algorithm> #include <fstream> #include <iterator> #include <string> using namespace std; void fileCopy(string inFileName, string outFileName) { copy(istreambuf_iterator<char>(ifstream(inFileName)), istreambuf_iterator<char>(), ostreambuf_iterator<char>(ofstream(outFileName))); }하도 옛날에 봤던 소스 코드라 기억이... 잘...
Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.
템플릿...
C에 비한다면... C++은 자료 구조와 알고리즘이 서로를 몰라도 되기 때문이 아닐까요...
블로그: http://turtleforward.blogspot.com
그렇지만
하나의 언어, 하나의 패러다임에만 매여있는 것도 좋지는 않다고 봅니다.
특정 언어에 대한 speciality 가 있는것도 좋지만, 다양한 관점을 가지긴 힘들지 않을까요.
저는 C/C++ 중에서 주로 C++을 쓰는데, 문제에 대한 oop적 접근이 가능하다는것과 stl을 사용할 수 있다는게 C++의
매력이라고 생각합니다.
---------------------
Weird, huh?
http://janbyul.com
C++은 너무
C++은 너무 언어자체가 복잡하고 방대해서 마음에 들지 않습니다.
C의 언어명세서가 500쪽인데 비해 C++은 700쪽입니다. 단순비교로는 200쪽 차이지만, C++이 C에 의존하는 부분이 크기 때문에 실제로는 두배 이상 차이가 난다고 보면 됩니다. 그리고 C++의 언어 명세서는 보고있으면 얼렁뚱땅인 듯한 느낌이 많이 들죠.
effective 류의 책을 보면 아시겠지만, 그 덕분에 프로그래머가 익히고 갈고닦아야 할 테크닉이 너무 방대합니다.
이런 자잘한 테크닉들을 익히는게 재미있으신 분들은 좋을지 모르겠으나, 저로써는 언어 자체는 좀 간결하게 잘 정의가 되어 있어서 문제 해결 자체에만 집중하게 되어 있는 언어가 있으면 좋겠습니다.
현재로써는 C가 거기에 가장 근접한 언어이긴 한데, 유감스럽게도 OOP를 지원하질 않는군요. 그래서 최근에는 Objective-C에 대해 알아보는 중입니다. 일단 대충 살펴본 바로는 C의 완전한 superset인데다가 문법도 간결하고 좋더군요. 실제로 쓸만한지 아닌지는 좀 더 살펴봐야 겠습니다만...
간단하게, OO에 대한
간단하게, OO에 대한 접근을 할 수 있어서라고 보여집니다.
아무래도, 자료가 복잡해지고, 함수 종류가 많아지면 일종의 종류별 packaging이 어느정도 필요하게 됩니다만.
C에서는 모든 함수들이 global하게 정의됩니다.
하지만 C++ 에서는 class의 member function 으로 묶어버릴 수 있기 때문에, 전반적으로 간략하게 보기 쉽죠...
물론 STL 역시 한몱 합니다.
물론, OO에 대해 열광하시는 분들은 반대의 목소리가 당연히 클 것이라고 봅니다만.
실리적으로 볼 때 이의 장점이 가장 크다고 보여집니다.
개인적으로,
C의 struct 에 member function (virtual function 은 없어도 됩니다..) 과,
Template 지원, 그리고, inline 지원 정도만 있어도,
C자체의 메리트는 매우 클 것이라고 봅니다....
(개인적으로 C를 사용할수도.. C++은 자잘하게 신경쓰이는것이 많아서리...)
WOW Wow!!!
Computer Science is no more about computers than astronomy is about telescopes.
-- E. W. Dijkstra
플레임성이 되기 쉬운 글타래인듯 하지만...
플레임성이 되기 쉬운 글타래인듯 하지만, 제가 C++을 좋아하는 이유는 딱 두가지입니다.
STL과 virtual function으로 구현되는 함수 다형성입니다.
STL은 알고리즘을 표준화하였기 때문이고(삽질 최소화), 다형성을 좋아하는 것은 결국 C 로 하던 일이 모두 엔진을 만들고, 재 사용을 하기 위해 하는 일이 많은데, 그것을 멋있게(?) 언어로 승화하였기 때문입니다.
---
http://coolengineer.com
현재 C++에서 가장
현재 C++에서 가장 아쉬운 부분이 nested function 인듯 합니다.
무론 nested class 로 어느정도 해결하고 있기는 합니다만, 뭔가 2% 부족한 느낌이....
WOW Wow!!!
Computer Science is no more about computers than astronomy is about telescopes.
-- E. W. Dijkstra
WOW Wow!!!
Computer Science is no more about computers than astronomy is about telescopes.
-- E. W. Dijkstra
중첩 함수의 활용도..
딴지는 아니고 그냥 궁금해서입니다.
제가 파스칼같은 중첩함수를 지원하는 언어를 한번도 안써봐서일수도 있는데, 중첩함수로 쓸수 있는 멋진 테크닉이 뭐가있을까요? 중첩으로 함수를 쓴다는것은 함수하나에 그 중첩함수가 종속된다는 이야기일것인데, 제 경우 이런게 필요한것은 함수내에서 다중상속객체를 암시적인터페이스로 제어하기 위한 템플릿함수일 경우였고, 사실 이것도 그냥 private member function으로 때려넣어서 크게 나빠보이지 않았거든요...
제경우 C++의 내부클래스를 POD형의 구조체로만 쓰는데, 자바처럼 내부클래스가 외부클래스의 private에 접근을 하지 못해서 내부클래스 메쏘드를 쓰기에는 무척 불편하더군요..
또하나, 아쉬운것중의 하나는 string에 format기능이 없는것.. boost를 안쓰고 이 기능이 구현된 작은 클래스나 함수 없을까요..
poklog at http://poksion.cafe24.com/poklog/
poklog at http://poksion.cafe24.com/poklog/
음.. 지금 바로 그
음.. 지금 바로 그 예제를 생각해야 한다는 중압감이.. ^^;
template[class VALUE] class CTree { class CNode { VALUE value; ... }; const CNode& Find(VALUE value) const { // nested function const CNode& FindRec(const CNode& node) { if(node.value == value) return node; const CNode::children::iterator iter; const CNode::ChildrenType children = node.children(); for(iter=children.begin(); iter!= childdren().end(); iter++) { const CNode& child = *iter; const CNode& found = FindRec(child); if(found != CNode::null) return found; } return CNode::null; } // major function context return FindRec(Root()); } }머 대강 위와같은 함수가 대표적인 예에 해당되겠죠..
물론 nested function 이 있다고 가정한 것이고, 그러한 활용중에서 대표적인 간단한 것만 뽑았습니다.
실제로 FindRec 부분에 대해서 외부에서 알 필요가 없습니다. 더구나, CTree 개발자라 할지라도, 저러한 세부적인 일회성의 코드를 노출시키는건 그리 보기좋은 모습은 아니구요... 하지만, 어쩔 수 없이 비록 private 혹은 protected 라도 함수를 CTree의 member function으로 만들어야 합니다. 더구나, Find(VALUE value) 이외의 다른 Find 함수가 필요할 경우(역시 리커전이 필요할 경우), 역시 필요없는 리커젼 함수를 노출시켜야 하죠..
물론 피해가는 방법이 있습니다.
그리고, 개인에따라 재활용의 측면을 얘기하시는 분도 있을 듯 하구요..
혹은, 다형성을 이유를 드는 분이 있을수도 있구요...
(하지만, 저런경우 FindRec의 재활용성 혹은 다형성이 필요하지 않겠죠.. ??)
WOW Wow!!!
Computer Science is no more about computers than astronomy is about telescopes.
-- E. W. Dijkstra
WOW Wow!!!
Computer Science is no more about computers than astronomy is about telescopes.
-- E. W. Dijkstra
파스칼에서는 저런 예를 자주 볼 수 있죠..
파스칼에서는 저런 예를 자주 볼 수 있죠.. 그나마 밖에 내어서 써도 되긴 하기 때문에 nested function이 없어서 많이 답답하다는 느낌은 안 들었어요...
블로그: http://turtleforward.blogspot.com
아... 이런게 nested
아... 이런게 nested function이군요.. 저도 자주 클래스에서 일회성 함수를 만들며
사용하면서 굳이 이걸 아무리 private로 하더라도 노출을 시킬필요가 있을까 하며 좋은 방법이 없나 싶었는데..
이런게 c++에 포함이 된다면 좋을것 같습니다.:)
-------------------------------------------------------------------------------
It's better to appear stupid and ask question than to be silent and remain stupid.
-------------------------------------------------------------------------------
It's better to appear stupid and ask question than to be silent and remain stupid.
나름 요령이 있기는
나름 요령이 있기는 합니다.
template[class VALUE] class CTree { class CNode { VALUE value; ... }; const CNode& Find(VALUE value) const { // nested function class CFunc { static const CNode& FindRec(const CNode& node) { ... } // case 1 const CNode& FindRec(const CNode& node) { ... } // case 2 } func; // major function context return CFunc::FindRec(Root()); // case 1 return func.FindRec(Root()); // case 2 } }이런식으로 nested class 로 피해가는 방법이 있기는 합니다만.
좀 지저분하죠 ???
객체지향언어의 장점은
객체지향언어의 장점을 한마디로 하자면 아무래도
"upcasting을 이용한 다형성" 아닐까요. ^^
전 그 안에 OOP의 모든 특징이 다 들어있다고 생각하는데...
제가 C++을 좋아하는
제가 C++을 좋아하는 이유
1. C++는 멀티패러다임 언어이다.
Procedural, Object-Oriented, Template MetaProgramming, etc.
2. STL
초강력라이브러리 STL!
3. C++은 C의 superset이다.
C++ TR1에 의해 C++ = C99 + β
Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.
설득력이 좀
설득력이 좀 떨어지는 애기들 있어서 한마디 쓰는데..
객체지향, 제너릭, 라이브러리 지원은 C++에만 있는건가요?
전 솔직하게 C++로 프로그래밍 할 줄 안다고 하면 대단하게 생각하는 사람들이 많아서 그것 때문에 C++를 합니다.
다른 언어 개발자들은 은근히 열등감 같은게 있더군요. 남들 5분만에 만들어내는거 30분만에 만들어내놔도 C++이라서 인정해주고 넘어갑니다.
고백하나 하자면 저는 델파이하는 사람들중에 뛰어난 프로그래밍 실력을 가진 사람들을 많이 봐왔습니다.
하지만 C++ 개발자라고 하는 사람들.. 솔직히 한심스럽다 못해서 아이큐가 두자리는 되는지 의심스러운적이 한두번이 아닙니다.
응용력이 떨어져서 책에 나온 틀과 달라버리면 머리회전이 안되는건지
템플릿은 어디에다 쓰는건지 알기나 하는건지.. 짜놓은거 보면 내눈은 못속이기에 같은 개발자입장에서 기가차지만 옆자리 델파이하는 사람은 아는지 모르는지 조용하게 자기 할 일을 착실하게 잘해냅디다.
주제에대한 제 글의 핵심은
C++로 프로그래밍 할 줄 안다고 하면 대단하게 생각하는 사람들이 많아서 그것 때문에 C++를 합니다.
입니다.
축하합니다. 남들
축하합니다.
남들 5분만에 만들어내는거 30분만에 만들어내고
아이큐가 두자리는 되는지 의심스러우며
머리회전도 안되는 부류에 속하신 것을요.
C++ 프로그래머들의
C++ 프로그래머들의 실력의 편차가 상대적으로 크다는 것은 인정합니다. 하지만, 님 주변의 C++프로그래머들만 가지고 'C++ 개발자라고 하는 사람들.. 솔직히 한심스럽다 못해서 아이큐가 두자리는 되는지 의심스러운적이 한두번이 아닙니다.' 정도의 성급한 일반화는 너무 심하시군요.
제 주변의 C프로그래머들이 이삼일만에 C++ 필요한 부분만 익히고 평소에 몇시간 정도 걸려야 짜던 것을 30분만에 짜는 경우는 봤습니다만. (아 MFC는 아니고 C++빌더였습니다;;; 델파이이야기를 하시는 것으로보아 GUI프로그래밍 말씀하시는 것 같은데, 설마 5분vs30분에서 델파이랑 MFC를 비교하셨던 건 아니겠지요?)
아이큐 3자리 이상 C++프로그래머들은 SI프로그래밍보다는 게임프로그래머들 중에서 많을 것 같군요. 그쪽도 제대로된 C++프로그래머가 없어서 한숨을 푹푹 내쉬고 있긴 하지만요.
다음 글도 한 번 읽어주세요.
http://agile.egloos.com/2633261
전 C++ 한다고 말을
전 C++ 한다고 말을 안하면 밥벌이가 힘들어서 C++한다고 말합니다. -0-;;;;
저도 비슷한 경험을 많이 했는데, 주위에선 황당한 C++ 개발자들을 많이 봤습니다만
인터넷에선 헉... 소리 나오게 코딩 하시는 분들도 많이 있습니다.
doldori님이 그중에 한분입니다. 한번 그분이 써놓은 글을 찾아 보시길 권합니다.
저도 예전 비파동에서 여덕수님이 써놓으신 글을 읽다 보면 지금도 감탄하고 있는 사람중의 하나 입니다.
높이 날다 떨어지면.
아푸다 ㅡ,.ㅡ
C와 C++에 대한 얘기 아닌가요?
C라는 언어에 비하여 C++이 가지는 장점이 본 주제 같은데요.
C도 물론 객체지향디자인이 가능하지만.
언어자체에서 객체지향기능을 지원하지는 않고 있어서(C는 객체지향언어가 아니고...)
상속이라던지 그걸 이용한 upcasting으로 다형성이라던지...
C보다 C++로 하는게 많이 편합니다.
C로 객체지향디자인할때 상속 한번 해보세요.
upcasting도 염두에 두고 말이죠...
코드제네레이터 같은 도구가 필요할 정도일껄요...
그렇다면 그게 C의 장점일까요? 코드제네레이터의 장점일까요?
역시 이런 주제는 플레임워로 진화하는군요.
돼지군 씨의 나이가 궁금하네요.
10살때 봤던 code 라고 하셨는데 상당한 수준의 code 네요.
통상 잘 안 쓰는 stream buffer iterator 를 쓰는 것이 나와서 놀랬습니다.
STL 이 Visual C++ 6 가 주류를 이루던 당시 암흑기였다는 것을 생각하면 저 code 가
한국에서 많은 사람들이 알기에는 5년도 채 안되었을 거라는 생각이 드네요.
돼지군 씨는 이 방면에 상당히 빠르면서도 C++ 를 선도하는 분일 거라고 생각되네요.
돼지군은 그 천재
돼지군은 그 천재 초등학생 아닌가요? 이름이 뭐더라..
======================
BLOG : http://superkkt.com
======================
BLOG : http://superkkt.com
언어의 선택은
언어의 선택은 실무와도 연관이 있는 것 같습니다.
저는 (알고 계시는 분도 계시겠지만) In-Memory DBMS를(최근에 Hybrid) 개발하는
개발자입니다.
회사 초창기 개발언어를 결정할 때 큰 고민없이 C++로 결정하고, 현재까지 이 언어로
서버 엔진, 클라이언트 라이브러리 까지 개발하고 있습니다.
수천라인 정도의 응용 프로그램이라면 사실 특정 언어의 진면목을 발견하기는 쉽지 않지요.
그 이후 약 2년 정도 지나고, 고객의 수십곳을 넘어가고, 소스코드가 50만 라인을 넘어가는 때부터
서서히 C++라는 언어의 본색을 발견하게 되었습니다.
특정 기능(template)의 아주 떨어지는 호환성 혹은 이식성, 의도하지 않은 내부 동작,
커지는 바이너리(거의 쓰이지 않는 라이브러리의 링크..) .
.그리고 지금까지도 개발팀을 괴롭히고 있는
컴파일러 버젼에 따른 정확한 object 또는 library version shipping 등등이
나타나기 시작하더군요.
물론 이것은 C++의 문제라기 보다는 저희 application domain에 적절하지 않은
언어를 사용하기 때문입니다.
제가 내린 결론은 소스코드의 양이 많고, 많은 플랫폼에 문제 없이 포팅되어야 하며,
시스템 레벨의 프로그램이라면 C++과 같은 언어 자체에서 제공해주는 기능이 많은
언어보다는 C와 같은 간결한 것이 낫다는 것입니다.
그래서, 2007년도에서는 모든 소스코드를 C++에서 C로 변환하는 계획이 내부적으로(이거 말해도 되나?)
있습니다.
물론, 반론도 있겠지만, 저는 일반 경험자로서 말씀드리는 것이고,
동료중의 한명도 비숫한 이야기를 하더군요.
자기가 한때 BeOS에 심취해서 개발을 많이 했는데 그놈의 시스템 라이브러리가 모두 C++로
되어 있는데...어느 한계에 다다르니 구조가 복잡해서 더이상 발전하기 힘들더라는...(이것도
사견이겠지만).
저 개인적으로는 C와 C++의 중간인 C+ 정도가 적절할 것 같습니다.
고도의 추상화, 극도의 구체화, 에디슨을 그리워하다.
고도의 추상화, 극도의 구체화, 에디슨을 그리워하다.
C+
C와 C++ 사이의 언어라······.
왠지 매력적인데요?
그 언어에는 C++의 기능 중 어떤 기능이 없고 어떤 기능이 있으면 적절할까요? :)
이것은 언어의 본색이라기 보다는
>특정 기능(template)의 아주 떨어지는 호환성 혹은 이식성, 의도하지 않은 내부 동작,
>커지는 바이너리(거의 쓰이지 않는 라이브러리의 링크..) .
>.그리고 지금까지도 개발팀을 괴롭히고 있는
>컴파일러 버젼에 따른 정확한 object 또는 library version shipping 등등이
>나타나기 시작하더군요.
언어의 본색이라기 보다는 이식성이 있는 코드로 작성했느냐의 문제인것 같습니다.
C 언어로 해도 동일하거나 더 좋지(?) 않은 문제들이 발생할 겁니다
(특히, Portability issues: Unspecified behavior, Undefined behavior, Implementation-defined behavior, etc).
이번 기회에 C++ 언어가 갖는 문제들을 정리하는 것이 좋지 않을까 생각합니다.
예를 들자면, 혼동의 방지 차원의 규칙들(Naming, 함수 선언 또는 클래스 선언, namespace의 적절한 naming 및 분배)을
좀 더 유심히 살펴보는 것이 좋을 것 같습니다.
추가적으로 위 경험들이 문서화 되었다면 커다란 자산이 되지 않을까 여겨집니다.
> 언어의 본색이라기
> 언어의 본색이라기 보다는 이식성이 있는 코드로 작성했느냐의 문제인것 같습니다.
마치 그렇게 할 수 있는데도 불구하고 개발자들의 능력이 부족해서 그렇게 하지 못했다는 소리로 들리는군요? C++ 구현체들의 완성도가 충분하지 못한 현 상황에서는 이상론일 뿐입니다. 사실, C 조차도 이식성을 위해서는 많은 hack과 트릭을 써야되는게 현실입니다.
> C 언어로 해도 동일하거나 더 좋지(?) 않은 문제들이 발생할 겁니다
> (특히, Portability issues: Unspecified behavior, Undefined behavior, Implementation-defined behavior, etc).
예로 드신 것들은 코드의 이식성에는 단점으로 작용할지 몰라도 C언어 자체의 이식성에는 큰 장점으로 작용합니다. 확실히 정의해야 될 부분과 그렇지 않은 부분을 주의깊게 분리함으로써(위에서 적으신 대로 무려 3단계로 구분하고 있습니다) 각 환경에 최적화될 수 있도록 배려하고 있죠. 그 덕분에 갖가지 환경에서 최적화되어 돌아가는 다양한 C 구현체들이 존재하는 거고... 모든 환경에서 단일한 코드로 동작할 수 있는 잘 정의된 언어라고 해도 막상 실제로 구현된 컴파일러가 없거나 성능이 수준 이하이면 이식성이고 뭐고 말짱 헛거 아니겠습니까?
게다가 김상진 님이 제기하신 문제는 C++ 구현체의 완성도가 떨어진다는 점인데 undefined behavior를 얘기하시는 것은 동문서답 같군요.
프로그래밍 언어와 구현체의 관계들
프로그래밍 언어와 구현체(각 벤더들의 컴파일러)가 갖는 문제점의 한 단면인데, 제가 글을 올바르게 쓰지 못했군요.
그리고 개발자의 능력에 관한 문제로 비쳐졌다면 사과 드립니다.
>> 언어의 본색이라기 보다는 이식성이 있는 코드로 작성했느냐의 문제인것 같습니다.
>
>마치 그렇게 할 수 있는데도 불구하고 개발자들의 능력이 부족해서 그렇게 하지 못했다는 소리로 들리는군요? C++ 구현체들의 완성도가 충분하지 못한 현 상황에서는 이상론일 뿐입니다. 사실, C 조차도 이식성을 위해서는 많은 hack과 트릭을 써야되는게 현실입니다.
>
>> C 언어로 해도 동일하거나 더 좋지(?) 않은 문제들이 발생할 겁니다
>> (특히, Portability issues: Unspecified behavior, Undefined behavior, Implementation-defined behavior, etc).
>
>예로 드신 것들은 코드의 이식성에는 단점으로 작용할지 몰라도 C언어 자체의 이식성에는 큰 장점으로 작용합니다. 확실히 정의>해야 될 부분과 그렇지 않은 부분을 주의깊게 분리함으로써(위에서 적으신 대로 무려 3단계로 구분하고 있습니다) 각 환경에 최적화될 수 있도록 배려하고 있죠. 그 덕분에 갖가지 환경에서 최적화되어 돌아가는 다양한 C 구현체들이 존재하는 거고... 모든 환경에서 단일한 코드로 동작할 수 있는 잘 정의된 언어라고 해도 막상 실제로 구현된 컴파일러가 없거나 성능이 수준 이하이면 이식성이고 뭐고 말짱 헛거 아니겠습니까?
>
>게다가 김상진 님이 제기하신 문제는 C++ 구현체의 완성도가 떨어진다는 점인데 undefined behavior를 얘기하시는 것은 동문서답 같군요.
c와 c++ 의 차이라고 하면
무엇보다도 절차적 언어와 객체 지향 개발 언어의 차이 아닐까요.
객체 지향 개발이라는 게 제대로 사용하려면 알아야 할게 제법 많죠. C++ 기본 문법에, UML, design pattern, 등등. 거기다 C++은 template을 지원하면서 generic programming 까지 할 수 있게 합니다.
따라서 C++을 어설프게 안 상태에서 대충 사용하게 되면, 그로 인해 비싼 댓가(?)를 치르게 되기도 쉽습니다. 그렇지만, 이해도가 높고 잘 숙련되어 있는 개발자나 설계자가 잘 사용하게 되면, 다양한 변경 요청에의 대응이, 절차적 언어에 비해 훨씬 용이하다고 생각합니다. 그리고 UML이나 디자인 패턴 등을 알면 개발자 간의 의사 소통도 보다 효율적으로 할 수 있는 부수적인 장점도 있구요.
제 경험으로 보면 C++, UML, 디자인 패턴이나 generic programing에 있어서 비교적 고른 숙련도를 갖춘 4 ~ 6명 정도의 팀이 꾸려지게 되었을 때, 정말 좋은 결과물을 낼 수 있었던 것 같습니다. 다만, 그 단계에 이르는 것이 쉽지 않을 뿐더러, 새로운 사람이 들어오게 되면 협업에 필요한 최소한의 수준에 이를 때까지 상당한 시간과 비용이 들게 되는 것도 상당한 부담으로 작용합니다.
이전 회사에서 한 4년동안 단계적으로 기능이 추가, 확장되는 프로젝트를 3개 정도 진행 했었는데, 8명이 2년 -> 6명이 1년 -> 4명이 반년 이런 식으로 되었던 것 같습니다. 처음에는 대부분의 멤버가 C++을 C처럼 짜는 상태였다가, 짬짬이 UML이나 디자인 패턴 같은 것을 같이 익혀 나가며 시행 착오를 제법 많이 거치면서, 한 프로젝트 끝나고 다음 프로젝트 준비때 기존의 안 좋은 코드들을 좀더 나은 구조로 바꿔 갔습니다. 그러다 보니, 기능은 많아졌지만, 개발기간도 짧아 지고, 변경 요청 시의 대응이 용이해 지는 경험을 가지고 있습니다. 그 과정에서 개인적으로 이런 C++이나 객체 지향 개발에 훨씬 많이 끌리게 되었고요.
대부분의 개발자가 이러한 객체 지향 개발을 수행할 여력이 되어 있지 않다거나, 하드웨어 사양이 그다지 높지 않아 실행 바이너리 크기가 몇 십 kb 줄이는게 중요하다든지, 이런 경우라면 C++로 개발을 진행하기가 쉽지 않을 테죠. 이에 비해 소프트웨어의 규모가 어느 정도 크고, 사양 변경이 비교적 잦은 경우라면, 거기에다 숙련된 개발자들의 비율이 어느 정도 된다면 C++로 개발하는 것이 좋을 듯 싶습니다.
그리고 제 경험으로 봤을 때, C로 오래 프로그래밍을 하신 분의 경우라면 C++로 개발한다는 게 어떻게 보면 프로그래밍의 사고 방식을 바꾼다고 해야하나... 설계나 개발하는 패러다임을 바꾸어야 하는 정도로 다른 작업일 수 있다는 생각이 듭니다. (오히려 비베 경험이 있는 분이 객체 지향 개념 자체는 더 쉽게 받아 들이는 것 같습니다.)
그래서 C 경험이 많은 분이라면 너무 급하게 C++로 바꾸려고 하는 것 보다는, 객체 지향 개발 관련된 개념을 먼저 익히고, 그 과정에서 C로 할 때 부족했다거나 불편한 것을 보완할 수 있겠구나를 생각하는 식으로 단계적으로 가는 게 좋을 듯 싶습니다.
C++ 좋아하는 사람의
C++ 좋아하는 사람의 일원으로서, "C++을 C처럼 짠다"는 표현은 적절치 못하다고 생각합니다.
C++은 멀티패러다임 언어이며, 절차지향, 객체지향, 일반화프로그래밍 템플릿메타프로그래밍등을 지원하는 언어이기 때문에,
C++을 소위 "C처럼"(절차지향적으로) 짜는 것 역시 C++의 원래 목표에 부합된다고 봅니다.
Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.
"원래 목표"가 C++ 의
"원래 목표"가 C++ 의 optimal use 를 이야기한다면, BS 가 이야기하는
바는 다릅니다. (돼지군님이 이 부분을 오해하고 계신 것 같네요)
C++ 를 C 처럼 (절차지향적 프로그래밍을 위해) 사용하는 것도 C++ 의 원래
목표가 아니며, Smalltalk 처럼 순수 OOP 를 위해 사용하는 것도 C++ 의
원래 목표가 아니라 합니다.
그렇다면 어케?? --; "멀티" 패러다임이니 "멀티"답게 사용하는 것이
optimal use 라는 것이죠. 그만큼 BS 가 생각하는 C++ 의 "원래 목적"에
부합하려면 다양한 패러다임의 프로그래밍 방식을 익히고 있는 상태에서
각 세부 문제에 가장 적합한 방식을 골라 C++ 의 다양한 기능을 활용해
공략할 수 있어야 (--;;;;) 가능해 진다는 뜻입니다. BS 본인은 C++ 을
optimal 하게 사용할 수 있을지 의심스럽군요. ^^
--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org
--
Jun, Woong (woong at gmail.com)
http://www.woong.org
저의경우 C에 한표
저의경우 C에 한표 하신분에게 동의표를 보냅니다.
물론 C++에서 polymorphism 에 의한 손쉬운 확장이라는 말을 인정합니다.
하지만, 그 polymorphism 이란것이 양날의 검에 해당합니다.
쉬운만큼 비싼 대가를 지불하기 쉽다는 것이죠...
C의 경우에는 각 명령의 동작이 매우 명확합니다.
그렇기에, 프로그램 작성시에 적절한 추상화와 그로인한 행동의 예측이 쉽습니다.
하지만 C++의 경우에는 그 추상화의 정도를 매우 복잡하게까지 할 수 있습니다.
하지만, 그만큼 추상화가 복잡하게 진행될 수록, 사고할 수 있는 복잡도를 넘어가기 쉽죠.
이런생각을 해 보시기 바랍니다.
C언어의 경우에는 절차적 프로그래밍 이라는 방법만으로 많은것을 커버할 수 있습니다.
(어떤면에서는, 이 도구 하나면 충분하죠.. 나머지는 개발자의 경험에 시너지를 받죠...)
하지만, C++의 경우에는 아직 너무 많은 문제점을 가지고 있습니다.
이 문제점을 해결하기 위해서, 무수히 많은 방법이 나오고, (refectoring, Design Pattern 등...)
그러한 방법이 나오는 중에 새로운 편리한 방법이 나오고 이를 보완하기 위한 방법이 또 나옵니다...
(Generic programming 등...)
이를 보면, 어떤면에서는...
C의 경우, 간단명료해서 그다지 복잡한 방법론과 툴이 필요없지만...
C++의 경우, 자신의 문제점을 해결하기 위한 툴과 방법론이 xx년이 지난 지금까지도 혼란스럽죠..
혹시 소스화일만 몇십만 라인이 넘어가는...
클래스만 3600 개가 넘는 프레임웍을 만져보신적이 있는지 궁금합니다.
상속도 깊이만, 5-10 단계가 넘어가는 것들을...
머 장단점이 있습니다.
그리고, 디자인을 잘 못해서 그렇다고도 하구요.
하지만 확실한건, C++의 경우 C에 비해서 쓸데없는 복잡성을 증가시키는 경향이 있습니다.
물론 다형성에 의한 편리함 역시 있지만요...
추가로.
개인적으로 C에 추가로 있었으면 하는게...
struct 에 함수추가기능(상속, virtual function, operator overloading, constructor, destructor 등 없어도 됩니다. 단순히 this를 내부적으로 처리해주는 함수만...)
nested function 가능기능.
(상속 등 과같은)복잡한 것전혀없는 심플한 template function, struct template
정도이지 않겠습니까???
아. 추가로... 짧게
아. 추가로...
짧게 개발하고 -> 내보내고,
다시 그 기반으로 다시 짧게 개발하고 -> 새로운데 내보내고,
다시 그 기반으로 다시 짧게 개발하고 -> 새로운데 내보내고, ...
등의 작업을 하는경우에는 C++의 다형성이 좋을 수 있습니다.
그만큼 refactoring을 할 수 있는 cycle이 짧고, 코드정리하기에 좋으니깐요..
또한, 그 프로젝트 환경에 맞는 필요경험을 축적->활용 할 수 있으니깐요...
하지만,
한번 개발하고 (v1),
그걸 업그레이드 하고 (v2),
그걸 또 업그레이드 하고 (v3), ...
등의 작업을 하는 경우에는...
여의치 않은것이 사실입니다.
이전버전과의 호환성을 유지해야 하기때문에,
코드를 많은부분 손댈수가 없죠.
더구나, 핵심적인 부분의 변화가 있었다 하면,
다형성으로인해, 내부적으로 짬뽕되기 정말 쉽고,
코드에 의한 행동예측이 어려운 경우도 많기 때문이죠...
(특히나, 프로그램이 비대/거대해졌을 경우에는...)
연산자 오버로딩
C에 연산자 오버로딩이 있으면 어떨 것 같습니까?
저도 C++보다는 C를 좋아하지만 C++의 STL은 너무너무 부럽더군요. +_+
operator overloading 이
operator overloading 이 나름 편리하긴 합니다만.
그로인해 생기는 복잡성 또한 은근히 많거든요...
이것들이 주로, 상속(다단계 상속 & 다중상속) 관련지어서 생기는 복잡성 입니다만.
상속이 없다는 전제하에,
construtor, destructor, operator overloading
정도는 나름 편할 듯 합니다.
솔직히 어떤면에서는 STL 땜시, C++을 사용하는점도..
C++만 잘 쓰면
C++만 잘 쓰면 정보올림피아드에서 다른 사람들이 직접 자료구조 알고리즘 짜고 있을때 그냥 include 한번으로 해결할 수 있게 되죠.
Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.
물론 list, vector 등을
물론 list, vector 등을 쉽게 해결할 수 있는것이 주는 편리함 도 있습니다.
하지만, 그게 다는 아니죠...
C로도 라이브러리만 만들어놓구 사용하면, 똑같이 편리하게 사용할 수 있습니다.
함수
음······.
하지만 함수로 접근해야 하지 않습니까?
물론 vectorA[i]라고 써도 안에서는 오버로딩된 함수를 호출하겠지만
at(vectorA, i)라고 쓰는 것보다는 보기 편하지 않습니까?
C는 잘하는편이
C는 잘하는편이 아니라도 상속관계니 머니 그저 아무것도 몰라도 떨렁 함수만쓰면 다되죠..ㅡ,.ㅡ;;
C++은 목적과 수단이 전도된듯한느낌을 받아 좀 안좋아합니다.
이런얘기하면 또 반론이 무수히나올텐데..
무엇을 구현하면 결과를 봐야지.. 그구현수단에 왜그리 말들이 많으며 그것에 에너지를 소비하는지..
그런다고 그게 다음에또 그에대한 보상이 바로 나오는것도 아니고.
글쎄요.. 수단과 방법도 중요하지만 그에대해 너무 소모적이란생각이듭니다..
---------------------------
초호화 점보여객기가 있습니다..
깔끔한옷을 차려입고 각종여행용품을 꼼꼼히 챙기고 없는것없이 모두준비된 상태의 까다롭고 복잡하지만 수속절차도 철저히밟고
여행을 다녀올수도 있겠죠...물론 이런 것에 맞는 여행계획이 있습니다...
그러나. 대부분의 사람들은 그저 출퇴근에 고향집이나 가까운곳의 여행이 대부분입니다..
사용하지 않은것까지 모두준비시키고 완벽하다 필요없으면 사용하지 않으면된다 라는말로
언제나 점보여객기로만 행동할수 없습니다.
저라면 대부분의 수단으로 자가용을택하고 특별한경우만 점보여객기를 이용하겠습니다.
비행기의 조종석이 훨씬 세련되고 잘정돈되고 이치에 맞을지몰라도..
자동차를 조종하는게 훨씬 쉽습니다.또한안전하죠.
복잡한조종판의 키가 어디에 붙었는지 복잡한형태의 규정이나 틀안에 짜맞추고 쉽게 찾는다 할지몰라도..
바로 눈앞에 다보이는 자동차가 더쉬우며 현재 가려하는곳이 자동차만으로도 충분한데 궂이 그러한 복잡한규정을따른 조종판이 필요치 않는경우가 많더군요.
----------------------------------------------------------------------------
폭격도 가능하고,
폭격도 가능하고, 요격도 가능하고, 장거리 비행에 고속 순항 까지 가능한 다기능 전투기가 자동차 보다 운전이 쉬울리가 없겠죠? :)
높이 날다 떨어지면.
아푸다 ㅡ,.ㅡ
감솨합니당..^^
많은 사람들이 답변을 달아주어서 감사합니다..
앞으로도 객체지향에 대해서 심도 있게 공부해봐야 겠습니다...
많은 도움 됬습니다~^^
※추가 답변 환영입니다...
#define DEBUG printf( "%s, %s, %d\n", __FILE__, __FUNCTION__, __LINE__ );
그다지 좋은점이 있나..??
좋은점
1. /* 대신 // 가 된다.
2. 변수 선언이 아무데서나 된다
3. OOP 흉내를 내볼수있다
4. STL 에서 vector 를 쓸수있다..(나머지 stl 은 솔직히 활용도가 떨어져서..)
5. 생각보다 빠르다..
나쁜점
1. OOP 에 대해 잘못된 개념을 잡을수있다.
instance 와 method 가 binding 된 message 의존 방식은 유연성 및 수정이 매우 어렵다.
CLOS 에서 사용하는 class에 의해 자동실행되는 방식이 훨씬 유연하고 쓰기쉽다.
2. private, protected 등등 뭐가 그렇게 복잡한지.
3. DLL로 만들면 이름이 뒤섞여(name mangling) 다른언어와 붙이기 까다롭다.
4. 발음하기 어렵다. 씨뿔뿔..씨플러스플러스.
LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr
Reference
덧붙여서 Reference가 있는 것도 참 좋군요.
블로그: http://turtleforward.blogspot.com
reference 있는게
reference 있는게 어느면에서는 편리합니다만.
실제로 복잡한 문제를 일으키는 경우도 많습니다.
그 레퍼런스라는 놈이, 순수한 포인터의 대변자인 경우도 있지만,
경우에따라, 내부적으로 객체를 생성해서 레퍼런스 하는 경우도 있어서...
이놈이 문제시될 때에는, 대략 문제점을 잡기가 힘든경우가 있습니다...
(분명히, 포인터대변자 로 보이는데, 실제로는 그렇지 않거든요..)
(이런경우에는, 함수로 호출되기 전의 객체의 주소와, 호출된 후의 객체의 주소 확인 및...)
(그 객체가 내부에서 동적으로 할당한 변수의 주소까지 확인해가며 문제를 잡아야 하는경우도...)
그런경우가 흔하지 않을 뿐더러,
일단 경우가 좀 복잡하고,
외우기 어려운 경우에 해당하기 때문에...
당장 예를 보이기는 힘들군요...
레퍼런스
음... 그래서 reference를 단지 reference라고 생각하고 씁니다. 포인터 대변자라는 생각은 전혀 하지 않고 쓰고 있거든요... (이런 것들은 레퍼런스라는 개념으로 추상화 된 것의 내부니까요...) 그래서 레퍼런스는 어떤 것인지 language에서 specify 되어 있는 것 이상으로 넘겨 짐작하지 않습니다.
저는 const 키워드도 마음에 들어요. (쓸데없이 코딩의 복잡성을 증가시킬 수도(?) 있겠지만요...)
블로그: http://turtleforward.blogspot.com
장점 1,2번은 C에서도
장점 1,2번은 C에서도 됩니다
흉내
하하, 흉내내는 것 뿐이라면 3번도 되지 않을까요. :)
흉내가 아니라 원래
흉내가 아니라 원래 되죠..
----------------------------------------------------------------------------
템플릿
게다가 템플릿의 일부도 C의 영역에 들어가지 않을까요?? (벌써 들어간건가...)
C도 자꾸 확장되고 있으니까요...
블로그: http://turtleforward.blogspot.com
C+는 말이죠.
C++ 에서 이것 저것 잘 이해하지 못한 기능 빼고 확실히 이해한 것만 빼서 쓰면 되는 거 아닐까요? 그게 C+이고, 곧 C++이기도 하죠.
모든 문법을 C문법으로 쓰고 변수만 아무대서나 정의해서 써도 C++이죠.
필요할 때 vector나 map 같은 것만 가져다 써도 C++이구요.
자기가 필요한 수준에 맞게 C++ 기능 찾아서 쓰면 됩니다. 그러다가 하나씩 하나씩 C++에 존재하는 기능이 왜 필요한지 깨닫고 나면 그때부터 그 기능 쓰면 되구요. 깨달을 일 없이 잘 해나갈 실력이 있으면 굳이 그럴필요 없구요.
저같은 경우에도 한창때 괜히 느리고 덩치만 크게 짤 필요없다고 C++쓰는 사람들 비웃으며 C로 다된다고 주장하고 다녔는데, 제가 지능이 좀 떨어져서 그런지 C로 만라인 넘어가는건 apache, bind 소스 분석해가면서 방법론을 배워도 도저히 제대로 설계를 못하겠더군요.
한창 막막할때 심심해서 리눅스 C++ 하우투 문서 읽으며 짜던 쏘스에 c++ class문법만 도입해보니 정말 좋더군요. virtual private이런 키워드는 신경도 안썼고 상속같은 것도 무시했죠. 그냥 class a{ public: .. 해서 구조체+네임스페이스 개념으로만 썼죠. 퍼포먼스가 중요해서 일일이 속도 비교해보니 C로 컴파일한 바이너리랑 비교해도 정말 무의미한 차이였구요.
그때부터 전 C++에 빠지기 시작했죠. 2만줄정도 되는 c코드에 class만 쓰다가 virtual도 써보고 상속도 해보고 template도 써보고 exception도 STL도... 똑같은 코드 6번 새로 짰던 것 같습니다. 이런식으로 C++에 빠져보세요. 첨부터 C++책 전체를 모조리 이해하고 모든 언어적 요소를 다 쓰려고 하지 마시구요.
좋은 말씀 해 주신 듯...
좋은 말씀 해 주셨네요.!!!
블로그: http://turtleforward.blogspot.com
동감합니다... 요즘들
동감합니다...
요즘들어 C++ 삼매경에 빠져있습니다 ^^
C++ 의 매력이 배우면 배울수록 코드가 달라진다는 거였습니다.
저도 거의 10년간 C 를 했는데 요즘은 C++ 로 전향하려고 노력중입니다..
그렇다고 C 로 간단히 짤것을 C++ 로 무조건 하겠다는것은 아니고요
C 와 C++ 충분히 같이 쓰고 해도 좋은데요..
가자 해외로 ~ .. 돈 벌러.
C 나 C++ 이나 참 좋은 툴인데..
특히 C++ 로 클래스 기반으로 프로그램을 제작한경우 한참 작업을 하다
어..클래스구조가 이건아닌데 싶어바꾸려고 하면..작업량이 너무많아 포기하게 됩니다.
Refactoring 이 너무 어렵다는게 가장큰 문제가 아닐런지..
LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr
동감입니다.
동감입니다. 그래서 뭔가 리팩토링을 하는 방법론을 프로그래밍에 추가시킬 수는 없을까요... 고민 또 고민...
블로그: http://turtleforward.blogspot.com
C++의 장점이라면...
일단 세가지 외치고 들어갑니다 ^^;
1. STL!!
2. Boost!!
3. ACE!!
-_-; 저 3가지가 있어서 일단 C++쓰는게 행복합니다 ㅎㅎㅎ (그러고보니...단순히 C++ 라이브러리?;;)
그리고...다형성도 좋고...템플릿 있는것도 좋구요. (좋긴 좋나봅니다..자바, C#에서도 도입하더군요.)
리팩토링 어렵다고 하는부분...C도 똑같죠. 그건 언어를 떠난 문제라고 봅니다.
얼마나 다른 함수(or class? 여튼 전체적인 관점에서 봤을때) 들과 얼마나 밀접한 관계를 가지느냐에 따라서
리팩토링의 난이도는 결정된다고 봅니다. 매우 general한 클래스라면 인터페이스도 매우 간략할것입니다.
이제...여기서 문제가 하나 생기는데요 ^^; 간략한 인터페이스를 제공하면 클래스 사용자측에서 좀 많은 작업을 해줘야되고,
강력한 함수를 제공한다면 컴퍼넌트 간에 강력한 밀접도 때문에 클래스 사용자가 사용하긴 쉽지만, 리팩토링을 하려면
힘듭니다. 저같은 경우는 전자쪽에 한표 던지는 편입니다.
좀더 general 한 클래스를 만들어둠으로써, 클래스끼리의 결합도를 낮춤으로써 나중에 어찌될지 모르는 부분에 대한 여지를
남겨두자는거지요. 그리고...이건 OOP의 장점인데...자료형과 알고리즘의 분리가 가능합니다.
즉...일반적으로 (전 UI가 있는걸 잘 안만들어용 ^^;;) 보통 비즈니스 로직은 input data -> processing -> output data
형식이죠. (물론 프로세싱 안에 또 저런 구조가 막 들어가겠죠?) 그렇다면...저 프로세싱 과정을 data 저장부분과 따로
떼내어 구현합니다. 프로세싱 하는 방법론이 여러개가 있어야된다구요? 그럼 더욱 C++이라서 행복해지는겁니다~
strategy 패턴을 구현하세요. virtual table 생성으로 많이 느려질꺼 같나요? 그럼 template로 구현하는겁니다!!
전혀 느릴것도 없고 아주 깔끔하지요 ^_____________^ (다만..템플릿을 모르는 동료에게 설명하기가 힘들순 있습니다;;;)
머 이런저런 이유로...아직 전 C++이 좋습니다~
------------------------------------------
Let`s Smart Move!!
http://kalstein.tistory.com/
댓글 달기