C 프로그래머가 C++ 프로그래머 되기

저같은 경우엔 컴파일러를 gw->qb->tc->vc 식으로 넘어왔습니다. 게임프로그래머가 목적이였기 때문에 항상 게임만들다가 필요하면 그때그때 배우는 방식이였죠. 그냥 하다보면 언젠가 객체지향이고 oop고 필요하다고 느껴지실때가 있을껍니다. 제가 생각하기엔 그때 배우셔도 늦지 않을꺼 같네요. : )

로그인하라는데.. 뭘해야될지..

암튼 글 잘읽었습니다.

저는 중3짜리 애송인데..

c언어두 모르구 c++두 모르겠어요,..

책사서 해보는데.. 이해가 될듯..안될듯..

학원 다녀야하나요? 뽀대나는 프로그램을

만들어보고싶습니다. 어떻게 공부하셨는지

좀 알려주세요

제 메일주소는 sinsummer@hanmail.net

입니다. 도움도는 말은 무조건 환영입니다.

언어에 대해 나름대로 배태랑이고, 세계 Top 그룹과 어께를 견줄만한다고 스스로 자부하며 살고 있는 사람입니다.

가끔 스트로스트럽의 C++ 책을 읽으면 읽을 수록 뭔가 새록새록한 느낌이 들듭니다.
이 책은 단지 C++을 구문을 말해주려는 것이 아니라 C++을 철학을 일깨워 줍니다.

아무리 Class를 사용하고, C++에 맞게 코딩을 하지만 어딘지 모르게 C 느낌이 납니다. 이건 저 뿐만아니라 절차적 언어에 익숙한 모든 프로그래머가 그러할 것입니다.

단지 구문만 C++의 것을 사용하고 그냥 Class좀 사용한다고 어느날 갑자기 C++ 프로그래머가 되지는 않습니다.

많은 시간을 투자해서 OOP적으로로 설계를 한다고 하는데도 프로그램이 복잡해지면 복잡해질수록 OOP 느낌은 온데간데 없습니다.

일단은 하향식 설계의 버릇을 완전 제거해야 하는데 이게 말처럼 쉽지가 않습니다. 즉 대개 일단 큰 틀을 만들어 놓고 만들다가 필요한 부분이 생기면 그때 그 부분을 만드는데 이렇게 나가면 OOP는 집어쳐야 합니다.
물론 이렇게 만들면서도 큰 틀을 수정하고 나중에 마치 OOP인양 코드를 재구성을 할 수는 있습니다만 아주 쓸데 없는 짓이지요. 눈가리고 아웅하는 짓거리와 비슷.

그런데 상향식 설계는 말처럼 그리 쉬운게 아닙니다. 추상적인 모양새 만드는 것부터가 쉬운 일이 아니지요.

아직도 갈 길이 멀기에 더 말하면 무식이 들통이 날 것 같군요.

암튼 저의 커다란 프로그램이 각각 Class로 구성되어 있고, 각 Class들이 상속관계가 분명한 그런 프로그램 한번 만들어 보고 싶습니다.

선배님들 질문하나 드릴께요..
전공을 하고있긴하지만 참부끄럽기 짝이없는 질문인데,
함수포인터 예제를 보면 이해가 되긴 하지만 그것이 어느정도의
재사용성과 모듈화를 보장한다는거에대한 확신을 가지는 그런
예제를 한번 보여주셨으면 합니다. 커널소스가 관련 syscall
을 부르는 구조가 그렇게 되어있다고 들어서 새삼 충격을 먹고
다시 K&R책도 한번 뒤적거려보고 뉴스그룹도 뒤적거려보고 하고
있는데, 제가 구할수 있는 범위내에서는 그저 퀵소트에 인자들어간
정도 밖에 모르겠습니다. ㅜㅜ
비슷한 코드의 중복 방지는 일반함수로도 어느정도 가능하지 않은지..
고수님들 가르침을 부탁드릴게요..

저 같은 경우에도 처음에는 C++ 부분을 보다가 덮어버리기 일쑤였습니다. 클래스 없이도 잘 되는데 왜 이렇게 해야 하나 싶어서요... 그런데, 자바를 공부한 다음에는 아하! 싶었습니다. ^^
다른 프로그램을 보는것도 도움이 되지 않을까 싶네요.

경험상 C++의 객체지향적인 성격이 큰 도움이 되지는 않더군요. OOP의 장점으로 익히 알고 잇는 점이 여러가지 현실적인 문제로 살아나지 않네요. 라이브러리 형태로 잘 만들어 놓으면 모를까 그냥 소스를 쉽게 재사용하는 장점은 존재하지 않는 것 같습니다.

혼자서 작업할때는 자기가 만든 소스니 할많ㄴ데 여럿이 할 경우는 특히 그렇더군요.

C언어로 자료구조를 정의할 때 struct를 사용하고
구조체에 정의된 변수들을 함수에서 원하는 바데로
조작하지요.
다른 말로 C언어는 자료정의와 이를 처리하는
함수가 분리된 절차지향언어(?)라고 할까...

C++에서 class는 C에서 struct구문과 비슷한 면은
struct처럼 class안에 변수들을 정의하지만 ,
아울러 변수들를 처리하는 메쏘드(함수)라는 것도
묶어서 정의하는 것이 struct구문과 다른 점이지요.

또한 순수한 객체 지향 개념에서
class는 상속이라든지하는 특성등이 있어서
잘 이용하면 객체지향의 진수를 알 수 있지여^^

제 짧은 생각으로 OOP에서 가장 중요한 것은 상속같은 class 사이의 관계입니다.
예를 한번 생각해 볼까요?
동영상 player를 만들고 있다고 생각합시다.
그럼 가장 간단한(?) 동영상 codec인 MPEG1을 지원하는 player를 우선 만들어서 테스트하는 것이 좋겠다는 생각이 들었습니다.
그래서 MPEG1 codec을 들고 와서 이리저리 닭짓을 해서 file을 열고 볼 수 있도록 만들었네요.
오 잘된다는 것을 알고 그럼 MPEG2 codec을 지원해야 겠다고 생각하고 모든 소스를 들고와서 작업을 하려고 보았더니, 이런 파일 열고 MPEG1 codec이랑 interface했던 소스를 그대로 쓸 수 없네요.
이럴 줄 알았으면 함수 포인터등을 이용해서 코딩해 둘걸이라는 후회와 함께, 그래도 적당히 소스를 바꾸어서 지원하도록 하자고 결정하고 다시 코딩해서 성공을 했습니다.
그러자 윗사람이 요즘 divx하고 mpeg4가 많은데 그것도 지원하자고 해서 또 생각해 보았더니 으아~ 또 닭짓을 계속해야 하는 구나.
역시 함수 포인터를 이용했어야 했어란 후회와 함께 또 닭짓을 하겠죠.

결국 닭짓이 계속되는 이유는 무언가 통일된 interface(C언어에서는 함수포인터 등)이 없어서라는 것을 깨닫게 됩니다.
그런 것을 처음부터 잘 생각해서 코딩했으면 계속되는 닭짓은 없었겠죠.
이렇게 interface를 통일하고 싶을때 C 언어의 함수 포인터등을 생각하는 것처럼 C++에서는 Class의 상속 등을 생각하게됩니다.

C++이 C보다는 interface에서 많은 유연성을 준다고 볼 수 있습니다.
"바나나, 사과의 superclass는 과일이다."라는 실제 일과는 전혀 상관없는 예제를 백날 들여다 봐야 아무 소용없다는 것이 제 생각입니다.
처음 부터, 이 프로그램을 작성하는데 계속 업데이트가 필요한 부분이 어떤 부분이고, 그것들을 위해 어떤 어떤 class가 존재해야 하고 그 class사이의 관계가 이렇게 되면 이런 면이 좋아진다는 식의 생각이 필요합니다.
그런 갖가지 class사이의 관계들을 일목 요연하게 정리해 놓은 책이 Design Patterns라는 책이죠.
아무 생각없이 읽으면 머리에 남는 건 전혀 없죠.

결론은 처음부터 열라 생각을 많이 해야 한다.
대신 열라 생각을 많이 하면 당연히 mpeg1만을 play하는 player를 만들때에는 일의 생산성이 조금은 저하된 듯한 느낌이 듭니다.
숙달된다면 빨라지겠지만...적어도 저는 그렇습니다.

OOP가 당장 와닿지 않아도 STL이나 개선된 문법 등, C++은 C와 다른은 점이 많습니다.
그런것들을 익혀가셔도 좋을거 같구요.

C스타일 프로그래밍에서 OOP로 전향하는 것은 그렇게 쉬운 일은 아닌거 같습니다.
저를 비롯한 제 주위의 많은 사람들이 그것에 많은 시간을 투자했고, 지금도 하고 있습니다.

OOP를 익히시려만 차라리 업무 외 시간에 smalltalk나 java같은 언어로 장난감 같은걸 만들어 보시는 것도 좋을거 같습니다.
C++을 사용하다 보면 프렌치카페에 많이 빠지더라구요... ^^;

아 그리고 역시 그 두권의 책은 꼭 읽으세요.

간단히 말하면 C++은 라이브러리를 개발하는 것에 초점을 맞춘 언어입니다. C는 어플리케이션을 개발하는 것에 초점을 맞춘 언어이지요. C++을 어플리케이션을 개발하는데 초점을 맞추고 그렇게 생각한다면 접근하기가 쉽지 않을겁니다.

초보자들에게서 흔히 나타나는 현상인데 OOP언어를 배운다고 OOP로 코딩을 해야한다고 믿는 OOP과잉 증세라는 것이 있습니다.

세상에... HelloWorld를 같은 간단한 코드도 클래스로 만들어서 쓰더군요. 그런 클래스는 결로 바람직하지 않은데.

디자인 패턴이 만능은 아니지만,
디자인 패턴을 조차도 제대로 이해하지 못한 상태에서 만든 클래스는 오히려 프로젝트를 말아먹기 쉽상이죠.

앞에서 예를든 HelloWorld의 경우도 만약 10개국어를 동시에 지원해야 한다면 각 국별로 별도의 클래스를 만들어야 하는데, 잘못하면 일관성을 상실하게 되죠. 예를 들어 이럴때 각 클래스가 동일성을 유지하기 위해 Factory Pattern을 써야 하는데, 글쓴이는 이런정도의 내공을 가진 것은 아닌것 같더군요.

그냥 구조화 언어식으로 코딩하다가 내공을 쌓아서 천천히 객체지향언어로 건너가시기 바랍니다.