리눅스에서 C와 C++중 어느것이 더 나은지....

geekforum의 이미지

오랜 역사와 산업표준으로 인정받고 있는 누가 뭐래도 이 시대의 최고의 언어인 C , 그리고 고전적인 C의 문제점인 객체지향적 플밍의 문제점을 보완한 C++ 하지만 아직까지 표준화 작업의 미비와 여러가지 문제점(가상함수, 클래스,코드의 불분명함,배우기 어려움)이 남아있다.

리눅스는 커널부터 C로 쓰여져 있고, 거의 표준이 C로 되고 있으나 요즘들어 객체지향적인 라이브러리의 가세(Qt,KDE)로 C++의 위치또한 높아져 가고 있는 상태이다.

그럼 대체 어느것이 더 나은 것일까?

어느것이 더 생산성 향상과 개발자들에게 나은 코드를 생성시키는가?

댓글

익명 사용자의 이미지

저는 별로C++을 좋아하지 않읍니다. 나쁘다는 소리가 아니고요(그럴 자격이 없읍니다).
예전에 C++이 한창유행할때 조금배우다 포기했는데, 지금생각해보면 어렵다는 생각밖에 없읍니다...
만약 제가 추천한다면 C + Python or Java
C를 왜 배워야 하는지는 두말하면 잔소리죠...
어떤프로그래밍을 하던지 결국어느정도의 시스템프로그래밍에 대한 이해는 필수라고 생각합니다. 아닌가요!
뿐만 아니라 C를 배운다는건 프로그래밍의 기본적인 원리를 배운다는 소리와 같읍니다.
물론 C++로도 가능하지만 C보다 배우기어려우니...
그러면 자바 아니면 파이썬인데...
저는 자바보다는 파이썬을 배우라고 권하고 싶읍니다.
왜냐면요... 쉬우면서도 재미있느니까!!!
배워보시면 왜 파이썬광신도(?)가 될수 밖에 없는지 이해가 갈겁니다...
오해하실것같아서 그러는데 저의 직업은 노가다디스무리하고 취미는 컴퓨터프로그래밍입니다.
취미프로그래머가 무엇을 추구하겠읍니까...
돈을? 명예를?...
재미죠... 재미있으면 하고 재미없으면 안합니다.
그런저가 거의 일년이 다되도록 파이썬을 붙들고 있다니 제가생각해도 놀랍네요...

익명 사용자의 이미지

i815칩셋.... C가 더 휠신 유리할듯....

익명 사용자의 이미지

쓰이는곳이 다르겠죠?

C는 하드웨어 직접접근에 유리하고.

C++은 어플리케이션 개발에 유리하겠죠?

C++ 로 짜면 나중에 한눈에 보이고 수정이 용이하잖아요.

white23의 이미지

난 무조건 C가 좋아~~~
아님... Assembly도 좋아~~~

음... 근데...
이건 백 날, 천 날 얘기를 해도 결론은 오직 하나...
\"나는 내가 써고 싶은거 썬다... 불만 있나???\"
이 이상의 결론이 나올려면 아마도 백만년은 더 걸릴 듯...^^

<어떠한 역경에도 굴하지 않는 \'하양 지훈\'>

어떠한 역경에도 굴하지 않는 '하양 지훈' - It's Now or Never!!!

익명 사용자의 이미지

제가 가입한 리눅스 동호회에 올라온 글입니다.
물론 믿기는 힘들것 같지만.. 그래두 뭔가 생각하게
하네요..

정말일까 의심은 가지만 한번 읽어 보기를....

-------- C++ 은 장난이었다 -------------------------------------

1998. 1. 1., Bjarne Stroustrup는 IEEE Computer지와 인터뷰 했다.
자연스럽게 편집자는 그가 C++을 창조한 당사자로서 7년간의
object-oriented 설계에 대한 종합적인 의견을 보여주리라 생각했다.
인터뷰가 끝날 즈음, Interviewer는 그의 기대 이상의 것을 알게 되었고,
편집자는 \'산업계의 이익\'을 위해 그 내용을 편집하기로 하였으나,
세상 만사가 그렇듯이 비밀은 없다.
다음은 편집되지 않은 완전한 대화 내용이며, 따라서 인터뷰 계획만큼 정리
되어 있진 않다.

Interviewer: 예, 당신이 소프트웨어 설계의 세계를 바꾼지도 수년이 지난
지금 어떻게 생각하십니까?

Stroustrup: 사실 당신이 도착하기 전 그것을 생각하고 있었죠.
기억하십니까? 모든 사람들이 \'C\'를 사용하고.. 문제는 그들이 아주
전문가였다는 점입니다. 대학에서도 C를 매우 훌륭히 가르쳤습니다.
졸업생들은 아주 *유능*했습니다. 이것이 문제가 되었습니다.

Interviewer: 문제요?

Stroustrup: 예. 모든 사람들이 코볼을 쓰던 시절을 기억하십니까?

Interviewer: 물론이죠.

Stroustrup: 글쎄요, 초창기에 이들은 거의 신이었죠. 높은 보수와 귀족
대우를 받았습니다.

Interviewer: 그런 시절이었죠.

Stroustrup: 그래요. 그래서 어떻게 되었습니까? IBM은 이것에 불만이었고
프로그래머들의 교육에 수백만불을 투자하여 마침내 백여명 정도의
인원을 길렀습니다.

Interviewer: 그게 바로 제가 그만둔 이유입니다. 보수가 1년만에
저널리스트 보다 적은 수준으로 떨어졌습니다.

Stroustrup: 그렇습니다. \'C\'프로그래머에게도 마찬가지 일이 일어났죠.

Interviewer: 그렇군요, 근데 요점이 무었입니까?

Stroustrup: 글쎄요, 하루는 제 사무실에 앉아서 보다 균형을맞게 하기
위한 작은 계획에 대해 생각했습니다. 이런 생각을 했죠.\'무척 배우기
힘든 복잡한 언어가 있다면.. 그래서 아무도 감히 프로그래머가
되려고 하지 않을 만큼.. 과연 어떨까?\' 실제로 많은 아이디어를
X 윈도우(X10)에서 가져왔습니다.
이 형편없는 그래픽 시스템은 Sun 3/60에서만 돌았습니다.
제가 원하는 모든 요소가 여기 있었죠. 우스꽝스러울 만큼 복잡한
문법, 애매한 함수, pseudo-OO 구조. 지금도 아무도 순전한 X 윈도우
코드를 작성치 않습니다. 제정신이라면 Motif만이 유일한 도구이죠.

Interviewer: 진심입니까..?

Stroustrup: 사실입니다. 실제로 다른 문제도 있었습니다. 유닉스가 C로
씌어졌지요, 즉 어떤 C 프로그래머도 쉽게 시스템 프로그래머가 될
수 있단 의미지요. 한때 메인프레임의 시스템 프로그래머가 얼마나
벌었는지 기억하십니까?

Interviewer: 물론입니다, 제가 한때 시스템 프로그램을 했었죠.

Stroustrup: 좋습니다, 따라서 유닉스와 언어를 결합하는 모든 시스템
콜들을 감춤으로써, 새로운 언어는 유닉스와의 결별하도록 해야
했습니다. 이는 DOS만 아는 사람들도 왠만한 소득을 벌 수 있게끔
했습니다.

Interviewer: 믿을 수 없는 예기군요...

Stroustrup: 글쎄요, 이미 시간이 지났지만 지금쯤은 사람들이 스스로
C++가 시간 낭비였다는 것 깨달았을 겁니다. 제 생각보다 훨씬
뒤늦은 일이지만요...

Interviewer: 그래서 실제로 어떤 식으로 하였습니까?

Stroustrup: 사실 단지 장난이었을 뿐이었습니다, 사람들이 제 책을
진지하게 받아들이리라 생각치 않았습니다. 두뇌가 반이라도 있다면
object-oriented 프로그래밍이 반직관적이고, 비논리적이고
비효율적이란 걸 알 수 있습니다.

Interviewer: 뭐라구요?
Stroustrup: 또 \'재사용 가능 코드\'를 보세요. 한번이라도 코드를
재사용하는 회사에 대해 들어 보셨습니까?

Interviewer: 글쎄요, 아니요, 하지만...

Stroustrup: 그렇습니다. 초기에 소수 회사가 시도는 했었죠. 오레곤의

Mentor Graphics사가 90, 91년도에 모든 코드를 C++로 재작성 하다가
크게 혼난적이 있습니다. 이에 대해 진심으로 유감스럽게 생각했었죠.
다만, 우리는 실수로부터 배워야 한다고 생각했습니다.

Interviewer: 물론입니다. 그래서 사람들이 교훈을 얻었습니까?

Stroustrup: 천만에요. 문제는, 대부분 회사들이 중요 실수들을 감추려
든다는 겁니다. 3천만불 손실을 주주들에게 설명하는 걸
어려워하지요. 그래도 공이 아주 없는 것은 아닙니다. 결국에는 뭔가
해내었지요.

Interviewer: 그래요? 글쎄, 그렇다면, OO가 성공했다는 거네요.

Stroustrup: 글쎄요, 거의.. 실행코드가 매우 컸습니다. 128MB RAM의
HP 웍스테이션에서 로드하는 데 5분 걸렸습니다. 실행는 더 엄청
오래 걸렸습니다. 실제 이것이 중요한 장애물이 되리라 생각했고
1주안에 모두 이를 알아차릴 것으로 짐작했습니다만, 아무도 신경쓰지
않더군요. Sun과 HP는 엄청난 파워의 머신을 판매하는 데 신이났죠,
단지 작은 프로그램들을 실행키 위해 엄청난 리소스를 필요로 하는..
AT&T에서 첫 C++ 컴파일러를 가지고 \'Hello world\'를 컴파일 하고
2.1MB라는 믿을 수 없는 크기의 실행코드가 나왔었죠.

Interviewer: 네? 글쎄요, 컴파일러는 많이 개선되었죠, 그 이후로..

Stroustrup: 그럴까요? 최신 버젼의 g++에서 한번 해보세요. 1/2 메가
이상은 될겁니다. 또한, 세계 각지의 최근의 예들도 많습니다.
British Telecom이 큰 위기를 당할뻔 했으나 운좋게 벗어나서 다시
시작할 수 있었습니다. 이들은 Australian Telecom보다 운이 좋았죠.
지금은 지멘스가 공룡을 만들고 있다는 군요. 실행코드를 저장하기
위한 하드웨어가 점점 커짐에 따라 우려도 커지고 있다고 합니다.
이래도 multiple inheritance가 좋습니까?

Interviewer: 예, 하지만 C++는 기본적으로 적절한 언어이지요.

Stroustrup: 그걸 믿습니까? 한번이라도 C++ 프로젝트를 해본 적이
있습니까? 사정은 이렇습니다: 아주 소규모의 프로젝트만이 첫 시도에
성공할 만큼 함정을 많이 만들었습니다. 연산자 overloading을
봅시다. 프로젝트가 끝날 무렵, 거의 모든 모듈에서 이걸 사용합니다.
보통, 사람들은 교육 과정에서 그랬듯이, 그래야만 한다고 생각하기
때문이죠. 같은 연산자가 각각의 모듈에서 제각기 다른 의미를 갖게
됩니다. 전부 모아 놓으면 백여개의 모듈이 됩니다.
이제 data hiding을 봅시다. 각 모듈들이 서로 대화하게 함으로써
문제를 만들어 내는 회사들을 보면 웃지 않을 수 없습니다.
\'synergistic\'이란 말은 프로젝트 관리자의 가슴을 후벼파기 위해
만들어 진 게 아닌가 합니다.

Interviewer: 정말 어처구니 없군요. 프로그래머의 보수를 높이기 위해
이 모든 걸 했다구요. 한심하군요.

Stroustrup: 꼭 그렇지만 않습니다. 누구나 선택이 있습니다. 이렇게
까지 문제가 커질 줄은 몰랐습니다. 어쨌든, 저는 기본적으로
성공했습니다. C++는 이제 죽어가고 있습니다. 하지만 프로그래머들은
여전히 높은 보수를 받습니다. 특히 이 모든 문제들을 관리하는
불쌍한 사람들은요.. 당신이 실제로 작성한 게 아니면, 방대한 C++
소프트웨어 모듈을 관리하는 게 불가능 한 것을 알겁니다.

Interviewer: 어떻게요?

Stroustrup: 아는지 모르겠군요, typedef 기억하세요?

Interviewer: 그럼요.

Stroustrup: 변수 \'RoofRaised\'가 double precision 이란걸 겨우 찾아내기
위해 얼마나 오래 헤더 화일들을 뒤져야 하는지 아시죠? 대형
프로젝트에서 모든 클래스들에 있는 implicit한 typedef들을 찾는데
얼마나 걸릴지 생각해 보세요.

Interviewer: 그래서 어떻게 해서 성공했다는 거죠?

Stroustrup: 평균적인 \'C\' 프로젝트의 기간이 어느 정도 걸리죠? 약 6개월
입니다. 부인과 아이들이 있는 사람이 여유있게 살만큼 충분한 기간이
아닙니다. 동일한 프로젝트를 C++로 설계하면 어떨까요? 1년 내지 2년
입니다. 대단하지요? 잘못된 결정이 이 모든 안정된 직업을 가져온
셈입니다.
또 있습니다. 오랜 기간 대학에서 C를 가르치지 않은 결과, 이제
훌륭한 C 프로그래머가 부족합니다. 특히 Unix 시스템 프로그래밍의
전문가가요. 오랫동안 \'new\'을 써온 지금, \'malloc\'을 제대로 사용할
줄 아는 사람이 몇명이나 될까요? return 값을 체크하느라 신경쓰는
일도 없죠. 실제로 대부분 C++프로그래머들은 return값을 그냥
내버립니다. \'-1\'을 쓰는 일은 이제 추억이 되었습니다. 적어도
\'throw\', \'catch\', \'try\' 같은 걸 쫓아다니지 않고도 에러가 있다는
걸 알 수 있던 시절이었죠.

Interviewer: 하지만 inheritance는 시간 절약을 해주지 않습니까?

Stroustrup: 그럴까요? C프로젝트 계획과 C++프로젝트 계획의 차이를
아십니까? C++ 프로젝트의 계획 단계가 3배는 길게 걸립니다. 어떤
부분이 inherit를 해야 하고어떤 부분이 안되는지 정확히 가려내야
합니다. 그리고 나서는, 여전히 뭔가 잘못되어있지요. C 프로그램에서
memory leaks이 있을 수 있습니까? 지금은 이걸 찾는 게 회사들의
중요 일이 되었습니다. 대부분 회사들이 포기하고는 그냥 제품을
내놓습니다. leak이 있다는 걸 다 알면서도 단지 그걸 찾아내는
비용을 줄이기 위해서 입니다.

Interviewer: 그걸 해주는 tool들이 있쟎아요...

Stroustrup: 그것들의 대부분도 C++로 작성되었죠.

Interviewer: 이 인터뷰가 출판되면, 당신은 아마 린치를 당할 겁니다.
안그렇습니까?

Stroustrup: 글쎄요. 말씀 드렸듯이 C++는 이제 전성기를 지났습니다.
정상적인 회사라면 선행 시도(pilot trial)을 안해보고 C++
프로젝트를 착수하지 않을 겁니다. 이를 통해서 재앙으로 가는
길이라는 걸 확인할 수 있어야 합니다. 그렇지 못하다면 그 결과는
그들의 책임입니다.
제가 Dennis Ritchie에게 C++로 Unix를 재작성토록 하려 했단 걸
아시죠?

Interviewer: 뭐라구요. 그가 뭐라고 했습니까?

Stroustrup: 다행히 그는 유머 감각이 있습니다. 그와 Brian이 제가 무슨
짓을 하고 있는지 알아냈다고 생각합니다. 그는 제가 좋아한다면,
C++ 버젼의 DOS를 작성하는 걸 돕겠다고 했습니다.

Interviewer: 흥미가 있으셨습니까?

Stroustrup: 실제로 C++로 DOS를 작성했습니다. 끝나는 대로 demo를
드리겠습니다. 컴퓨터실의 Sparc 20상에서 실행시키고 있습니다.
4 CPU에서 엄청난 속도로 실행되고, 70메가 정도의 디스크를
차지합니다.

Interviewer: PC에서는 어떻습니까?

Stroustrup: 농담이십니까? Windows 95아시죠? 저는 Windows 95를 저의
최대 성공으로 생각합니다. 비록 제가 준비하기도 전에 시합을 끝낸
셈이지만요.

Interviewer: Unix++에 대한 아이디어는 정말 생각해볼만 합니다.
어디선가 누군가 시도를 하겠지요.

Stroustrup: 이 인터뷰를 읽은 다음엔 포기하겠죠.

Interviewer: 죄송합니다만, 이 인터뷰를 출판할 수 있을 것 같지 않군요.

Stroustrup: 하지만 이것은 세기의 스토리입니다. 제가 동료
프로그래머들을 위해 한 일로 인해 제가 기억되기를 바랄 뿐입니다.
오늘날 C++ 프로그래머들이 얼마나 버는지 아십니까?

Interviewer: 제가 알기로, 제일 잘나가는 프로그래머는 시간당
칠팔십불정도이지요.

Stroustrup: 그렇죠? 그 정도 될겁니다. 제가 C++에 집어넣은 모든 기능을
파악하는게 보통 일이 아닙니다. 그리고 전에 말씀드렸듯이, 모든
C++프로그래머들이 어떤 프로젝트를 하던지, C++의 그 모든 빌어먹을
요소들을 다 사용해야 한다는 강박관념 같은 걸 느낍니다. 이건 가끔
저를 화나게 합니다, 그게 아무리 저의 처음 의도 였지만요. 결국
저는 C++언어를 좋아합니다.

Interviewer: 전엔 좋아하지 않았습니까?

Stroustrup: 싫어했었죠. 심지어 C++가 지저분하지 않습니까? 하지만 책의
인세가 들어오기 시작하면서... 글쎄요, 아시겠지요?

Interviewer: 잠깐요. reference는 어떤가요? C 포인터보다 개선된 것
아닙니까?

Stroustrup: 음.. 그거에 대해 항상 의문이었습니다. 처음엔 개선이라고
여겼습니다. 근데, 하루는 C++를 처음부터 써온 친구와 얘기할 기회가
있었습니다. 그는 변수들이 reference되었는지 dereference되었는지
도무지 기억 할 수가 없어서 항상 포인터를 쓴다더군요. \'*\'덕분에
쉽게 알 수 있다더군요.

Interviewer: 글쎄요, 보통 이때쯤이면 \'대단히 고맙습니다\'라고 말하게
되는데 오늘은 그렇기 힘들겠는데요.

Stroustrup: 인터뷰를 출판해 주십시오. 요새 제 양심이 많이 좋아지고
있습니다.

Interviewer: 나중에 알려드리겠습니다만, 편집장께서 뭐라고 할지 알 수
있습니다.

Stroustrup: 어쨌든 누가 믿겠습니까? 테입 복사한 걸 보내주실 수
있습니까?

Interviewer: 그럼요.

정말 충격이죠? ^^
- > 여기가 끝입니다. 이런글 보신적 있으신가요/
웅 개인적으로 c++을 괜찮다구 생각했는뎁..
암튼... 이런 글이 중요한것은 아닌것 같네요..
그럼..

익명 사용자의 이미지

저도 처음에 속았었지요.
이런글을 딴데서 읽었었거든요.
충격...

헌데 알고보니 거짓이더군요.
하지만, 일부 수긍가는면도 분명 있는것 같습니다.

수우_의 이미지

쩌어기 밑에 AmesianX 님이..
들리는 소문에.....

하면서 쓰신글 내용이 증명(?)되는 글이네요..-_-;;

큭.. 사실일까-_-???
거참 잼있네 ㅋㅋ

익명 사용자의 이미지

저는 프로그래밍에 대해선 잘 모르지만 이글이 정말
사실이라면 충격이네요. 그런데 믿어야 하나 말아야하나!!!!

익명 사용자의 이미지

지금은 4월이 아닙니다. 12월 입니다.

만우절 농담은 만우절에 해야죠.

익명 사용자의 이미지

C와 C++이라.....

참 묘한 공방이네요......

뭐.,...제 생각엔 짜기 나름인거 같습니다.....

개인적으로 C와 어셈의 연동을 제일 좋아합니다....

뭐 익숙하니깐요.....--;;

짜기 나름인듯.......예!! 짜기 나름인거 같네요

C로 못짜는거 없는데......--;;

C++로 짜면 좀 이쁘죠.....뭐.......

oop개념만 빡세게 잡힘...C++도 좋은듯.........

결론은......짜기 나름이란겁니다......

이런생각 가지게 된건...

새터, 더그 브라운이 쓴 C 프로그래머를 위한 C++이란 책 한번 보세요.....--;

아마 제 결론이 이해 되실듯..

익명 사용자의 이미지

여기 Linux Focus에서 취재한 내용중에서 발췌한 내용임다.

Dennis M. Ritchie와의 인터뷰 중

L.F.: UNIX가 과거와 현재의 운영체제라면, 최근 객체지향언어가 등장함
에도 불구하고, C는 별다른 논란없이 대표적인 "프로그래밍 언어"
라고 할 수 있습니다. Dennis씨는 C++와 Java를 어떻게 보시는지
요? 그리고 C 프로그래머와 C++프로그래머 사이의 흔히 등장하는
논쟁에 대해서는 어떻게 생각하시는지요?

Dennis: C는 C++이 성장하기 전에도 상당히 많은 부분을 수용했고, C++은
C를 새로운 언어를 만드는 기반으로 그리고, 그것의 컴파일러를
만드는 수단으로 삼았기 때문에, C는 C++ 에게 큰 유익을 주었다
고 할 수 있습니다. C는 이식가능한 어셈블리 언어라고 말할수 있
다.(좋기도하고 때로는 나쁘기도 하지만) 그리고,C++는 그 수준을
객체지향언어로 올리려하고 있고, 더욱 추상적인 프로그래밍을
하도록 합니다. 그 두개의 단점은 (최근에 만들어진 기준에 의하
면) 너무 장식적이고, 자질구레한 것이 많다는 것입니다. Java가
포인터를 통한 작업과 같은 C의 유산을 없애고, 기계독립적인
object 화일을 만드는 (새롭지 않은, 그러나 이제서야 구현 가능
하게 된) 아이디어를 더한, C++의 후손이라는 것은 명백합니다.
그것은 Sun과 Microsoft 사이의 음모에 붙잡혀 있고 (물론 그것도
나름의 장식물로 인한 문제가 있지만), 앞으로 어떻게 될 것인지
는 추측하기 힘듭니다.

<-- 자세한 내용은 여기에
http://www.linuxfocus.org/Korean/articles/article26.html
http://www.linuxfocus.org/English/July1999/article26.html

C has been characterized (both admiringly and invidiously)
as "a Portable Assembly Language", and C++ tries to lift its
level to object orientation and a more abstract approach
to programming

익명 사용자의 이미지

제목 그대로입니다.
MFC은 C++이 아닙니다. 그저, 마이크로소프트의 라이브러리이지요.
다들 알고 계시겠지만 STL을 따르지 않는 같은 이름의 함수들이
얼마나 많던가요.
MFC와 C++을 같이 논한다는 것 자체부터 이상한 것 같습니다.

C++이 나쁘기만 한것은 아니죠.
객체지향으로 코딩하는 것과, 그렇지 않은 것은 설계단계에서 결정해야하
는 프로그래머의 맡은 바 입니다.
C++로 객체지향적으로만 코딩하라는 법도 없구요.
STL을 잘 사용하면, C에서 저지르기 쉬운 메모리 관리나, 스트링 제어를
아주 직관적인 코드로 만들 수 있지요. 약간 사이즈는 커지고, 속도는 느
려질 지 모르지만, 프로그램의 성격에 따라 감수 할 수 있는 문제라고 생
각합니다.

물론 C++로 접근하기 어려운 부분도 많습니다.
단적으로 커널도 C로 만들어진 객체지향적 프로그램이지 않습니까.
거기다 C++로 접근하기란 두번 일을 하게되는 결과를 낳지요.
굳이 C++로 하겠다면 할 수 없지만..^^

어떤 언어이든, 프로젝트의 성격과 프로그래머의 역량에 따라 교과서와는
전혀 다른 방향으로 사용되기도 합니다.

리눅스 전체에 C/C++을 비교하는 질문은 적절치 못하다는 것이 저의 의견
입니다.
그럼...^^

익명 사용자의 이미지

이런 논의가 올라오면 언제나 나오는 얘기가 씨로 못하는 게
없는데 왜 바꾸어야 하느냐와, 씨의 압도적인 실행속도, 그리고
씨뿔뿔을 제대로 구사하기 어려움 등등인 거 같네요...

지금은 어짜피 객체지향이나 디자인 패턴, 코드 가독성,
재사용성, 유지 용이성... 등등이 강조되는 시기죠. 왜 씨를 바꾸어야
하느냐는 질문은 여지껏 쌓여온 곤란과 고민들, 또 그에 대한 대답으로
제출된 여러 성과물들을 외면해 보겠다는 얘기 밖에 안됩니다.

씨의 실행속도는 이제 더 이상 압도적인 장점이 되지 못하지요.
그것도 자바랑 비교하는 것도 아니고 씨뿔뿔과 비교한다면 그 차이는
대부분의 경우 무의미할 겁니다.

씨에서 씨뿔뿔로 옮아가는 것은 확장자를 하나 덧붙인다던지
주석 형태를 바꾼다든지 하는 거와는 본질적으로 다른 얘깁니다.
요부분에서는 당연히 개발자들의 공부를 요구하고 있지요, 당근!

암튼 시스템 플밍이 아니라면 리눅스에서의 일반 어플은 이제
씨뿔뿔같은 현대적 개념이 적용된 언어로 개발되어야 하는 게
낫다고 생각합니다. 현대적인 개념이 적용된 언어가 코딩을 짧게
해준다든지, 혹은 쉽게 해준다든지, 혹은 수행능력을 좋게 해주는
마법을 부리지는 못하지만, 플밍을 코딩에서 디자인의 단계로 끌어
올려주죠. 절묘한 재치를 우아한 아름다움으로 바꾸어 주죠.
잘만 설계되면 다른 코드 손 볼 것 없이 추가적인 기능들을 쉽게
짜넣을 수 있지요. 개발 이후의 싸이클을 생각하면 씨는 이젠
정말 구닥다립니다.- 우아함이 실용성을 대체할 순 없다고들 하지만,
이제는 우아함이 곧 실용성인 시대 아닙니까?

횡설수설...

익명 사용자의 이미지

뭔가 잘못 생각하시는 듯 하군요...
전 C++의 편도, C의 편도 들지 않는 사람입니다.

OO가 등장한 이유를 뭐라고 생각합니까??
단디 코딩의 우아함을 위해 등장한 것이 아닙니다.
바로 코딩을 쉽게 하기 위해서입니다..!!
C처럼 구조적 프로그래밍만 가지고는 커다란 프로젝트를 수행하는 것이
한계대 다다랐다고 생각을 했고, 코드의 재사용성과 효율성을 극대화하기
위해서 등장한 것입니다. (물론 지금도 C로도 커다란 프로젝트가
많이 진행되고 있고, 잘 진행되고 있습니다.)

그런데 사실상 C++은 C보다 쉬운 방법을 제공하지만은 않습니다.
C++의 객체지향의 냄새가 휙 풍기는 여러 GUI프로그래밍이나
좀 덩치가 큰 그런 프로젝트는 OO를 이용하는 것이 유리할 수 있습니다.

그 외에 간단한 프로그램이나 하드웨어를 컨트롤 하는 디바이스 드라이버,
커널 등(C++은 이미 하드웨어쪽을 위한 언어에서는 많이 벗어났습니다.)
을 OO개념을 도입해 C++로 만든다는 것은 무리가 있습니다.

또, C는 C++보다 훨씬 많은 호환성을 제공하고 OO적으로 프로그래밍이
불가능한 것은 아닙니다. 그리고 사실 C++은 C를 너무나도 수용하려고
들었기 때문에 여타 다른 OO언어 (JAVA같은)보다 배우기가 어렵고,
구조적 프로그래밍과 혼동하기 쉬운 단점이 있습니다. 그것도 C를 선호하게
되는 이유가 되겠죠..
그 C의 호환성때문에 프로젝트 자체는 C로 하고 C++로의 바인딩만을
제공하는 경우도 있죠.(GTK+과 gtkmm 처럼)

UNIX는 거의 완벽한 C 프로그래밍 환경(IDE가 아닌, 시스템 프로그래밍을
위한 환경)을 제공하고, 또한 작은 것이 아름답다는 철학을 가지고 있기에,
그런 곳에서 궂이 C++를 주장하는 것은 정말로 어리석은 일입니다.
(GUI분야같은 곳은 제외입니다..)

한마디로 각각 쓰일 데가 있다는 것입니다. 하나만 주장하는 것은
옳지 않습니다..

마지막으로 하나만 얘기하자면 우아함이 실용적인 시대는 아닙니다.
우아함도 실용적이어야 쓸만한 것입니다. C++이 실용적이지 못하는게 아니고,
C++을 잘 쓰면 우아하면서 실용적으로 쓸 수 있습니다. 그게 바로
OO를 만든 목적인 것입니다. 실용적이지 못하면서 우아하기만 한 것은
실전에 쓸 수가 없습니다. 연구의 목적에 어울리는 것이지..

익명 사용자의 이미지

제가 우아함이란 말을 쓴 건 씨의 문맥에서죠.
씨란 언어는 성능을 위해 언어적인 우아함을 적잖이 외면한 편이죠.
우아함이란 공학적인 일관성이니까요.

코딩에 있어서도 성능을 따질 수도 있고 우아함을 추구할 수도 있죠.
그러나 지금은, 성능을 위해 암호같은 코드를 중첩해서 쓰는 것보다는
가독성을 위해 펼쳐 놓은 코드가 더 생산성이 있는 시대라는 거죠.

그리고 오오피의 등장이 코딩을 쉽게 해주기 위해서...라고 했는데
별로 동의하지 않습니다. 물론 코딩이란 작업에 대한 개념 설정이
먼저 있어야 겠죠(코딩을 쉽게 해준다는 말... 글쎄 펄이나 파이썬
같은 스크립트 언어는 코딩을 쉽게 해준다고 할 수 있겠나요?).
그러나 그런 걸 말하는 건 너무 번잡하고, 적어도
현재 스코어 오오피가 코딩의 과업을 쉽게 해주었다는 얘기는, 저는
듣지 못하고 있습니다. 저의 견해로는 오오피는 플밍에 디자인적인
요소를 도입하여 그 효과를 보자는 전략일 뿐이니까요.
물론 오오적이지 않은 언어로도 비슷한 효과를 얻을 수 있겠지요.
다만, 얼마나 우아하게 그것을 해낼 수 있느냐는 거지요. 당근
오오적인 개념을 구현하기 위해 만든 언어들이지요.

또하나 유닉스 세계는 결국 씨 공화국이란 거, 그것도 당근이지요.
리눅스도 시스템적인 요소들은 거의 100% 씨로 작성되어 있으니
시스템 플밍을 하려면 씨로 할 수 밖에 없지요. 그러나 일반 어플을
작성하려 한다면 리눅스가 씨로 작성되어 있다고 해서 굳이 씨를
잡을 필요는 없지요. 일반 어플은 주로 구이 환경을 지원해야 하는데
그렇담 구이 플밍에 적합한 언어가 더 낫지요.

저도 유닉스의 작은 것이 아름답다는 철학을 좋아합니다. 사실 이 말은
오오의 격언이 되기도 하지요. 하나의 객체는 너무 많은 기능을 담고
있으면 안되니까요. 그러면 복잡해지고 중첩되니까. 복잡한 건 날씬
하게 하고, 중첩된 건 따로 떼서 따로 객체를 만들어야죠.
어느 플랫폼에는 오오 적용이 억지스럽다는 건 이해가 안되는
말이라는 거죠...

씨냐, 씨뿔이냐에 대한 일방 선택은 없겠죠.어짜피 두 언어 다
익혀야 하는 거니까요. 그나 제 생각은, 상대성이론이 어렵다고
뉴턴 역학에만 머물수는 없는 거란 얘기죠. 어짜피 일상에서는
뉴턴의 방정식을 풀더라도 상대성이란 개념은 회피될 수 없는 거니까.
오오가 그 정도로 대단한 개념이란 생각은 전혀 없지만, 그렇게
회피되어도 좋을 기술 역시 아닐 거라고 확신합니다.

musiphil의 이미지

이와 같은 논쟁이 생기면 곧잘 보이는 이해하기 어려운 반응이,
사람들은 Perl을 칭찬할 때는 "문자열 처리가 편하다, 골치
아프게 메모리 관리에 신경쓸 필요가 없다"는 식으로 얘기하면서,
C와 C++를 비교할 때는 "C는 작고 빠른데 C++는 무겁고 느리다,
어렵고 안에서 무슨 일이 일어나는지 모르겠다"는 식으로
이야기한다는 것입니다.
세부 사항에 신경을 쓰지 않아도 내부적으로 알아서 잘 해 주는
특징, 이것이 Perl에서는 장점이 되고 C++에서는 단점이 됩니다.
왜 그런가요?

그런 의미에서 Stroustrup이 쓴 "Learning Standard C++
as a New Language"라는 글을 소개하고자 합니다.
http://www.research.att.com/~bs/new_learning.pdf

물론 저자의 의견이지, 전적으로 제 의견은 아닙니다. :-)
주제를 간단히 요약해 보자면,
1. C++로 C보다 더 짧고 간단한 코드를 만들 수 있다.
2. C++로 C보다 더 빠른 코드를 만들 수 있다.
3. C++가 C보다 더 배우기 쉬울 수 있다. (특히 초보자들에게)
이 정도가 되겠군요.

반대하시는 분들도 계시겠지만, 실제로 C++로는 몇 줄이면 되는
간단한 일을 하기 위한 C 코드가 얼마나 대책없이 길어질 수
있는지, C++의 템플릿이 속도 면에서 얼마나 유리할 수 있는지
보여주는 예들은 무척 인상적이었습니다.

아울러, 한 가지 덧붙이고 싶은 것은, 어떤 프로그램을 짜기
위해서 언어의 모든 기능을 사용하려고 할 필요는 전혀 없다는
것입니다. 많은 분들이 상속이 어렵다고 C++를 비판하시는데,
그런 개념은 필요한 곳에서 적절하게 쓰면 되지 상속 때문에
C++라는 언어 자체를 포기할 필요는 없지 않겠습니까? 또한
그런 개념이 필요한 곳에서는 비슷하게 흉내를 내는 것보다는
언어 자체에서 직접 지원하는 것이 훨씬 효율적일 테고요.

익명 사용자의 이미지

우리 모두.. 컴퓨터 언어를 이야기하기 전에
모국의 국어 틀린 것이나 좀 수정하고 이야기 하는 것이 어떨까요? -_-

단 한 분만이 철자 틀린 것을 지적하시고, 나머지 분들은 역시
틀린 그대로 '낳은'을 이용해서 쓰시는군요.

"C가 C++보다 낫다. C가 더 나은 언어이다" 와 같은 표현이 올바른 철자법
을 사용한 표현인줄 압니다.

컴퓨터 랭귀지를 습득하기 전에, 네츄럴 랭귀지의 철자를 한번 더 확인하
는 것은 어떨런지? -_-

익명 사용자의 이미지

언어 사용시의 버그(?)는 항상 존재하지요...
동의하시죠?
님은 물론이거니와, 모든 사람이 그렇지 않을까요?

그냥 그러려니... 하고 넘어갈 수 있는 아량의 부족이 안타깝습니다.
쩝....

musiphil의 이미지

김충환 wrote..
: 우리 모두.. 컴퓨터 언어를 이야기하기 전에
: 모국의 국어 틀린 것이나 좀 수정하고 이야기 하는 것이 어떨까요? -_-
:
: 단 한 분만이 철자 틀린 것을 지적하시고, 나머지 분들은 역시
: 틀린 그대로 '낳은'을 이용해서 쓰시는군요.
:
: "C가 C++보다 낫다. C가 더 나은 언어이다" 와 같은 표현이 올바른 철자법
: 을 사용한 표현인줄 압니다.
:
: 컴퓨터 랭귀지를 습득하기 전에, 네츄럴 랭귀지의 철자를 한번 더 확인하
: 는 것은 어떨런지? -_-

지당한 말씀이기는 합니다만, "Re: xxx"라는 제목은
"xxx라는 제목의 글에 대한 답글"이라는 뜻일 뿐이지
그 이상도 이하도 아닙니다. 처음의 xxx가 잘못되었으면
뒤따르는 글들도 모두 잘못된 xxx를 달고 있는 것이
이상할 것이 없는데, 답글을 달면서 모든 사람들이 일일이
원제목의 맞춤법을 고쳐야 한다는 것은 무리가 아닙니까?

그리고 국어 토론장이 아닌 이상 남의 맞춤법 실수를
지적하는 것은 (다들 알긴 해도) 일종의 금기 내지는
꺼려지는 일이 아니었던가 싶은데.. 그래서 다른 분들도
일부러 지적 안 하고 넘어가신 것 같으니, 그냥 그러려니
하고 생각하시는 것이 좋을 것 같습니다.

익명 사용자의 이미지

저도 물론 많은 분들이 알면서 그냥 넘어가신다는 것..
어찌 모르겠습니까?

제가 처음 토론 주제를 보고 나서 며칠 후에 위의 글을 올린 것은
단순히 reply에 올라가는 제목의 글 그대로 뿐만 아니라,
그 후에 토론으로 올리시는 내용중에서도 계속해서 '낳은'으로
표기하면서 글을 쓰시는 분들이 많으시기에 올린 것입니다.

네티즌들이 가장 많이 틀리는 맞춤법이 '나은' 인 것 같아서
안타까운 생각에 블랙 코메디 식으로 올린 글이지요.

이런것은 제가 일일이 뭐 따지고 비난하자는 것이 아니고,
너무 열을 올리고 진지하게 토론하는것 같아서 씁쓸하게 나마
웃고 넘어가자는 의도로 올린 글입니다.
그러니 무슨 그냥 넘어가는 아량과 같은 것과는 별로 상관이 없다고
생각하고요.

네, 맞춤법 하나 틀린 것은 전혀 중요하지 않습니다.
하지만 앞으로도 계속 틀린 것이 올바른 표현인줄 알고 사용하시면
얼마나 많은 실수가 기다리겠습니까?
혹시나 헷깔리는 분들이 있을까 해서 올린 것일뿐이지요.

별로 진지하게 받아드릴 필요는 없습니다.
그냥 틀렸으면 '아차차~ 그랬군~ 담에는 틀리지 말아야지~' 하고
넘어가면 되죠. 뭐.. 이미 아시는 분들은 신경쓸 것도 없겠고요.

익명 사용자의 이미지

저는 개인적으로는 C++ 가 중대형 프로젝트에는 더 적합하고 좋은 언어라고
생각합니다. 그러나 그건 제 개인적인 생각일 뿐, 아무리 좋은 언어라도
어렵다든지 속도의 문제라든지등으로 실제 프로그래머들이 사용을 하지
않는다면 그 언어는 높은 가치를 가질 수 없다고 생각합니다.
그래서 제가 알고 싶은 것은 현재 중대형 프로젝트에서 실제 국내외
프로그램 개발업체에서 c 와 c++ 가 어느정도 비율로 사용되고 있느냐
하는 것입니다. 만일 연도별로 이런 자료가 있다면, 중대형 프로젝트에
있어서 향 후 c 와 c++ 의 사용가능성을 예측하는데에 많은 도움이 되리라고
생각합니다. 특히 프로그램머가 되기 위해 언어를선택하여 공부하려는
사람들에게는 좋은 자료가 될 것으로 생각됩니다.

PS. A 지점에서 B 로 이동하는 방법에는 여러가지가 있을 수 있겠지요.
1. 걸어서 2. 차를 타고 3. 비행기를 타고. 4. 배를 타고 5. 수영을 해서
바로 옆집에 가는데 비행기를 탈 사람은 없겠죠.
부산에서 제주도에 가는데에도 원리적으로는 사람에 따라서 수영을 해서도
갈 수 있을 겁니다. 그러나 그걸 권하는 건 좀...
윈리적으로 치면, 어셈블리어로 모든 일을 할 수가 있겠지요. 그러나
어셈블리어로 중대형프로젝트를 수행한다는 사람은 아직 보지 못 했습니다.

익명 사용자의 이미지

아래의 글들을 죽 읽어 보니 객체라는 말이 많이 나오더군요.
그런데 객체가 맞나요? 개체 아닌가요?

subject - object
주체 - 객체

object의 의미를 생각하지 않고 영어 사전에
나온 뜻풀이 중 하나를 골라 번역한 거 아닌가요?
object에는 개체라는 뜻도 있는데...
object가 객체라면 oop에 주체라는 개념도 있는 건가요? ^^

익명 사용자의 이미지

C냐 C++이냐?????

C? 그놈으로 만들면 작고 빠릅니다. C로 구현 못할것 없습니다.

C++? 그놈 참 확장성 있고 유지보수 하지 좋습니다. 그리고 만들고 나서
(?) 보면 참 보기 좋습니다. 그림(^^)을 그려도 멋있습니다.

Library? 그놈은 그 놈을 만드는 놈의 재량입니다. C/C++ Lib똑 같이 만
들 수 있습니다.

상속? 그놈 좋아하면 C하지 마십쇼. 그럼 그만 입니다.

(^-^) (^0^) (-.-;) (T.T) -- catHJ9N --

익명 사용자의 이미지

개발할 프로그램에 특성에 맞춰서 골라 사용하면 딱인듯.

익명 사용자의 이미지

C와 C++ 둘중에 무엇이 더 낳은가를 묻는다면 저는 C라고 말하고 싶습니
다. 이유는 배우기가 C++처럼 추상적인 개념이 많이붙는 언어보다는
실제적이라고 말하고 싶습니다. 저는 C++과 자바 등등을 이미 오래전에
독학했지만 너무도 추상적인 개념이 많이 들어가는 것 같아서 실제로
프로그래밍 할때는 머리속에 있는 것들을 또다시 추상화 시키는 어려움
이 있는데 비해 C로 프로그래밍할때는 그다지 그런 스트레스는 없었습
니다. 물론 C++에는 코드의 재활용(?.... 재사용..) 등등 그리고 상당히
유용성이 있다고 판단이 되는 객체지향이라는 점이 있긴 하지만 C언어도
그점은 별 무리없이 커버할 수 있는 프로그래밍이 가능하다고 봅니다.
(물론 코드가 더 많이 추가 될 수도 있겠지만은...안 그럴수도 있고..)
제가 지금까지 C와 C++ 둘다 다룰줄 알고 C++을 한다는 사람치고 제대로
된 C++을 구사하는 사람을 별로 본적이 없답니다. 비주얼 C++같은 변태
말고요... 대부분은 C언어를 하면서 C++을 한다고 깝추는 수준이더군요..
진짜 C++의 진수를 보여주는 프로그래밍을 하는 사람은 드물고 C언어라고
보기에 짝이없는 그런 수준들 이었습니다. 말만 C++ 한다고 그러면서 클래
스만 쓰면 다 C++인줄 아는 족속들이었습니다. 물론 그렇다고 C언어만 강
추하는 것은 결코 아닙니다. 다만 지금까지 C++을 맹목적으로 더 좋다고
생각하는 사람들은 한번 생각해 보십시오.. 내가 하는 프로그래밍이 C++
로 짜는 것이 더 유용한지 아니면 오리지날 C로 짜는 것이 더 쉽고 유용한
지를 말입니다. C++을 사용하게 되는 것은 클래스위주, 상속의 개념을 써
야하는 객체지향이나 클래스와 비스무리한 C언어의 구조체에서는 사용할
수 없는 함수를 포함하고 있는 클래스 같은 것들이 필요할때 등등 대부
분 방대한 양의 프로그램을 설계하고 짤때나 골라서 써야할 것이라고
생각합니다. 여러분도 아시다시피 게임프로그래밍 같은데서는 API를 그대
로 사용한다는 것 아시죠? 속도때문이지요... 게임 프로그래밍에 클래스
쓰는것은 그다지 많이 사용 안하지요... 그외 응용 프로그램을 만들때는
또 유용하게 쓰이는 것이 C++이잖습니까.. 뭐가 더 좋고 어쩌고 저쩌고는
자기 취향이 있지만 그때그때 맞는 것을 골라서 쓰는것이 더 좋은 프로그
래밍 습관이라고 생각합니다.

마지막으로 제 개인적인 소견으로는 C++이 더 난해한 언어임에는 틀림없
다는 것과 C가 배우기에는 더 수월하다는 것.. 그리고 이왕할꺼면 순서대
로 밑에서부터 기어올라가야 한다는 것(C언어 배우고 C++을 배우자..~)
만들 프로그램에 맞도록 그때그때 적합한 개발방식을 찾아야 한다는 것
입니다. ( 소문에 듣자하니 C언어는 천재들의 장난이라고 하는데 구라인
지 사실인지는 모르겠습니다. C언어를 만든 천재들은 프로그래머들이
매우쓰기 어려운 언어를 만들기 위해서라고 했고 프로그래머들이 자신들
이 만든 C언어를 익히자 더 쓰기 어렵게 하기위해 C++을 만들었다고 합
니다. 이게 사실이면 C++은 쓰레기 언어가 되는 거라고 생각해야 겠군요..
C언어는 장난감 정도이고요.. ^^;

익명 사용자의 이미지

우선 제목의 '낳은'은 '나은'으로 바뀌어야 할 것 같군요.
낳은 -> bear, 나은 -> better
라고 생각되는데, 혹시 국어사전 찾아보신 분 계신가요?
제가 잘못 알고 있는 건지도 모르겠군요. -_-;

그동안 kldp 토론 게시판을 보면서 느꼈던 점은 글을 올리시는
분들 중 상당히 많은 분들이 자신의 박식함을 널리 알리고자
너무나도 애쓴다는 것입니다.
'자신이 이 분야에서 얼마나 종사했다는 둥, 내가 이 분야는
많이 알고 있다는 식의 표현으로 일단 상대를 압도해 보겠다는
의도가 보이는 글들이 너무 많습니다.'
이런 결과로 토론이 제대로 이루어지기 보다 글 올리는 분들의
자기 자랑으로 끝나는 경우를 종종 보았습니다.

이 토론도 예외는 아니라는 생각이 드는군요.
제가 보기에 이 토론의 주제를 제기하신 '하정수'님은 C나 C++
중에서 어떤 언어가 최고의 언어냐(즉, 둘 중의 하나가 현존하는
언어중 최고이다)를 이야기하고 싶은 게 아니라, C와 C++,
이 두 언어를 비교하는 의견을 듣고 싶다는 의도이신 거 같은데,
아래에 글을 쓰신 많은 분들은 자신이 잘 사용한다고 생각되는
언어를 최고의 언어인 것처럼 말하느라 토론의 주제를 벗어난 말을
늘어놓고 있군요. 심지어는 뜬금없이 자바나 펄, php와 같은 언어
의 우월함을 말하며, 자신의 지식을 뽐내려고 하고 있습니다.
(왜 ada나 lisp같은 언어는 없는지...)

'언어는 목적에 따라 다른 것을 선택해서 사용할 수 있다'라는
'프로그래밍 언어'를 공부한 사람이라면 수업 첫시간에 들어봄직한
말로 토론의 무용론을 펼치는 사람이나, 책 도입 부분에나 나올 법한
각종 언어들의 특징을 들어 마치 특정 언어가 최고인양 주장하는
모습은 정말로 안타깝게 느껴집니다.

자기 자랑 하지 말고, 생산적인 토론합시다.

kldp 방문자 중 많은 분들이 리눅스에 호의적인 성향을 가진 걸로
알고 있는데, 소위 오픈소스의 산물인 리눅스를 사랑한다는 분들이
왜 이렇게 닫힌 마음을 가지고 있을까 답답하기만 합니다.

여린칼날_의 이미지

거...좋~~~잖아요...?

"아, 물론...당신 자유다. 채널을 돌리든, 닥치라고 소리치면서 TV를 꺼버
리든, 사실, 그렇게 할 수 있는 세상이 더 좋은 거라고 난 생각한다."

제가 좋아하는 김혜린님의 "아라크노아"라는 작품에서 나온 대사 중 하나
죠. 가수인 인물이 자신의 콘서트를 TV에 중계하면서 한 첫번째 엔트입니
다.

흠.. 님의 말대로 사람들이 자기자랑만 하는 것처럼 보이고, 그것 때문에
님께서 용기를 내어 비판의 글을 적으신 것두 좋아요... 그렇지 않으면 발
전두 없을테니까.

근데, 글들의 성격이 님이 걱정하신 것 만큼 심각하지는 않은 것 같다고
생각합니다. 만약 사람들이 자기 자랑을 하기 좋아한다면, 그것두 좋지
않을까요..? 자기 자랑을 하면서, 또는 자기가 좋아하는 언어를 빗대어
가면서 비교한 글을 보면... 저처럼 모르는 사람이 보고 '아... 그런 특징
이 있었구나..' 할 수도 있지요.

저는 이런 식의 토론이 좋다고 봐요. 이 토론에서 가장 쓸모 없는 글은
제 글이 되겠죠. 그렇게 되었으면 좋겠어요.. 이렇제 주제에 벗어나는
글은 없어졌으면... 합니다. 다른 분들의 글들이 어떤 내용을 담고 있든,
이렇게 주제에 벗어나는 글만 아니라면 당당히 자신의 목소리를 대변할
수 있는, 그렇게 되었으면 좋겠습니다.

...그런 의미에서 이 글은 가까운 시일 내에 자폭시키도록 하겠슴다...

모두들 좋은 하루 되세요~

익명 사용자의 이미지

긴 말이 필요 없습니다.

c++이 더 좋습니다.

c++로 더 아름다운 프로그램 짤 수 있는거 모르세요?

그럼 도전해 보시죠!

예전에 프로그램을 시작하신 분들은

c가 좋다는 생각을 많이 하시죠

"c로 못할거 없어!", "골치아픈 c++ 필요없어!"

c++이 골치아픈건 프로그래머 실력 부족 탓이라고 봅니다.

저도 아직 실력이 부족해서 아름다운 프로그램을 짜지는 못하지만

한발 한발 다가감을 느낄 때 정말 프로그래머로써의 기쁨을 느낌니다.

...............................................초보가

ps. 언어가 무슨 상관이리~

익명 사용자의 이미지

C 로도, C++ 못지않은 객체지향을 할 수 있습니다.
gtk 라이브러리가 좋은 예입니다.

그러나... C++ 의 장점 또한 무시 못하겠죠...
개인적으로, 마이크로소프트의 MFC 를 상당히 잘 만든
클래스 라이브러리라고 생각하고 있습니다.
물론, 내부의 코드는... (제가 볼 때도 좀 '누더기'적인 면이 있지만..)

그렇다 치더라도, 개발자가 사용하리라고, 예상하고, 인터페이스를
제공하는 부분에서는 상당히 괜찮게 모델링 되었고,
편리하게 되어 있습니다. (물론, 제공하지 않는 기능을 건드리려면
골치가 아프지만요... -_-;)

소프트웨어 개발 방법론...
쩝.. 저도 뭐, 잘 알지는 못하지만...
거기에 맞는 이상적(100% 만족하지는 못하지만)인 랭귀지가
c++ 혹은 자바와 같은 언어라고 생각합니다.
멋지지 않나요? '객체' 라는 개념...

제 생각은, c 나 c++ 이나, 각각에 맞는 쓰임이 있다고 생각합니다.
C++ 의 경우는 코딩 이전의 설계 단계에서
아주 많은 시간이 필요하고, 또, 그만큼 설계의 단계가
중요하겠죠...
C 의 경우는... 물론, 확장성 있게 설계를 잘 하려면,
물론 설계의 단계가 중요하겠습니다만...
C++ 의 경우보다는 그 중요성이 덜하다고 생각되네요...

쩝......
먼 말을 주절거렸지.. -_-;
그러나... hello world 나 port scanner 같은 간단한 프로그램을
짜는데, 굳이 C++ 을 가지고 접근할 필요는 없겠죠? ^^;
대규모 프로젝트에, 많은 인원이 참가한다면...
C++ 이 더 나을지도...

쩝... 결론이 뭐지? -_-;

musiphil의 이미지

여기에 많은 분들이 써 주신 글들을 읽어보니,
왜 사람들이 언어를 종교에 비유하는지 알 듯하네요. :-)

안타깝게도 별로 생산적인 토론은 못 되고 있는 듯합니다..

익명 사용자의 이미지

별루 생산성이 없는 논쟁이라는 점에서는 저도 같은 생각이네요.. ^^;
C 와 C++ 어느 것이 리눅스에서 더 개발에 적당하냐는 것은 식탁에 김치
를 올릴까아니면 깍두기를 올릴까하는 것과 비슷하네요. 우리가 쓰는 언어
와 마찬가지로 프로그래밍언어 역시 각 각의 특성이 있습니다. 그래서 개
발의 특성과 언어의 특성을 서로 비교해서 개발에 가장 알맞는 언어를 선
택하고 개발하는 것이지 무턱대고 어떤 언어가 가장 좋다 그러니 개발은
그 언어로 하자라는 식은 프로그래머가 할 말이 아니라고 생각되네요.

white23의 이미지

하하핫...

당근입니다.
전 입이 짧아 사족은 달지 않겠습니다.
근데 이 얘기는 어느 사이트(특히 C언어 사이트)에 가나 논쟁 거리인데...
당근 C입니다.
당근... 말밥으로...

<어떠한 역경에도 굴하지 않는 '하양 지훈'>

추신_이에 반하시는분... C로 할수없는거 하나만 예를...

어떠한 역경에도 굴하지 않는 '하양 지훈' - It's Now or Never!!!

익명 사용자의 이미지

#include "MyString.h"

void main()
{
MyString A,B,C;
A = "Hello";
B = "World";
C = A+","+B;

C.echo();
}

결과

Hello,World

애플(8bit)시절에.. 베이직을 베우고나서..
어셈블리어를 막 시작했을때.. 변수에 관한 개념이
다른점을 이해하고 나서.. 문자열 처리가 정말로
귀찮은 일이라는걸 깨달았죠..
베이직은 문자열에 대한 연산을 기본적으로 제공하거든요.

그리고 좀있다. C를 배웠는데...
문자열만은 역시나 좀 귀찮더군요.

C++은 이런 자료형을 다루기 쉬운 형태들로 만들 수 있죠..
뭐 C++의 객체지향적인 성질을 C에서 자료형을 굉장히
정교하게 만들고... 함수포인터등을 쓰고 하면
커버할 수 있지만.

Complex, String같은 자료형이라든지..
Matrix.. 같은거는 잘만 선언하면 MatLab에 맞먹는
파워를 보여주기도 합니다.
그러니까.. Matrix..자료형 선언하고 컨버터를 돌려버리면..
메트렙의 m파일을 돌릴 수 있는 수준입니다. -_-;;

자바요? 글쎄 자바의 바이트 코드 생성 때문에 사람들이
시도해보지를 앉지만.. 애플릿을 올릴 수 있는
클래스들이 선언되면.. 로컬에 바로 띄워볼 수 있겠죠..

C++에 대해서 많은 사람들이.. 비꼬는 투로..
better C 라고 하기는 하지만.. C의 확장성에 객체지향적인
힘을더한 강력한 언어로 볼 수 있죠..

방랑자_의 이미지

음..인터넷뒤져보시면, C++표준화문서를

수십$ 에 구입하실수 있을것입니당..

익명 사용자의 이미지

매우 오래전부터 많은 논의가 되오던 내용인것 같군요.

이곳에 올라오는 토론주제들과 내용을 가끔 읽어가곤 하는데요.
많은 공감이 갈때도 더러 있더군요.

C가 좋으냐. C++이 좋으냐는 개인이 알아서 할 문제인것 같군요.
(회사나 발주업체에서 강요(?)를 하는 것을 제외하구요.)
어느분의 대답처럼 C++을 사용하면서 OOP를 제대로 사용하지 않는다면 차
라리 C가 낳겠지요.
같은 로직과 수행결과를 내는 같은 프로그램을 C와 C++로 작성해서 비교
해보면 확실히 컴파일된 코드의 크기나 수행속도면에서 C언어로 작성된
프로그램이 우수한 성능을 냅니다.

그러나 타인의 소스를 분석해야 한다거나 계속되는 유지보수를 해야하는
프로그램이라면 OOP의 개념을 제대로 반영한 C++프로그램이 더욱 우수하
다는 것이 제 개인적인 생각입니다.
그러한 프로그램들을 모아서 함 분석해보십시요.
(함수에대한 이차원포인터를 기본적으로 사용하는 소스를 분석해보신 적
있습니까?)
물론 두언어에 대한 이해가 있어야한다는 전제가 붙겠지만...

C언어로 코딩을 하는 사람중에도 C의 기능을 제대로 활용하는 사람 별로
못봤습니다
(C++은 더욱더 그렇습니다.)
제 친구는 SCO UNIX상에서 돌아가는 TextBBS를 유지보수하는 일을 했
던 친구가 있었는데요.
개인적으로 C를 매우 능숙하게 다룬다고 생각했지요. 그렇게 보였으니
까...
특히나 VI는 정말 잘 다룹니다. 손가락이 보이지 않을 정도입니다. ^.^
그러나 둘이 같이 프로젝트를 해야하는 일이 있었을때 코드를 공유하면서
일을 하다가 매우 놀랐습니다.
포인터를 절대로 안쓰겠다는 것입니다! 문자열을 쓸때는 어떻게 하냐고
했더니 배열을 매우 크게 선언한다고 하더군요.(사실 배열도 포인터지만
논외로 치지요) 따라서 malloc() 이 있는지조차 모르더군요. -.-;
자신이 필요로하는 기능을 만드는데 지금까지 그렇게 사용할 필요성을 못
느꼈다고 하더군요.

OOP라는 것은 단시간에 습득될 수 있는 것이 아닙니다.
그것은 기본적인 사고방식 자체를 바꾸어야만 하는 매우 큰 작업에 해당합
니다.
Database 설계작업에 많이 참여했던 사람이라면 OOP에 적응하는것이 매
우 빠를것입니다.
기본적으로 가장먼저 생각하는 것이 Data설계니까요. 그러나 학교다닐때
취미삼아 했던 사람에게는 고문에 가깝습니다. 그렇게 하지않더라도 충분
히 할 수 있는것을 왜 바꾸어야만 하느냐는거지요.

참 밑에 어떤분이 string처리를 하는 것에 대하여 말씀하셨는데요.
string처리를 할 때, C가 많이 불편한 것이 사실입니다. 그러나 자신의
함수를 만들거나 원하는 라이브러리를 구해서 사용하면 편하게 사용이 가
능합니다.
C++이라면 아주 편하게 작성할 수 있습니다.
string 라이브러리에는 string객체가 있으며 string객체에는 string처
리를 하는 많은 method가 있습니다.
그래서 문법이 틀릴뿐이지 perl이나 tcl처럼 편하게 사용할 수 있습니
다.
string처리를 아주 독특하게 하고싶으시면 클래스를 하나 만드시면 처음
만 힘들뿐이지 이후에는 편하게 사용할 수 있을 것입니다.
(perl보다는 타이핑을 더 하긴 하겠군요...)

그리고 이 주제를 올리신 분이 C++의 단점에 대해서 적은신것을 보면 가
상함수나 표준의 미비가 문제점이라고
하셨는데요. 그것이 문제라면 다른것으로 우회해서 작성하시면 되겠군
요. 또한 표준이 아닌 부분들은 아예 안쓰시면 됩니다. 클래스와 배우기
가 어렵다는 것이 문제점이라고 지적하신 것은 OOP에 대한 정확한 이해
가 미진하기 때문입니다. 의지가 있으시다면 공부하시고 지금의 상황에
만족하신다면 그냥 C로 작성을 하십시요.

공부하시는 분이라면, 그리고 언어에 대해서 관심이 많으시다면, 그리고
코더를 직업으로 가지고자 하시는 분은 가급적 많은 언어를 공부해보십시
요.
때에 따라서 하루에 약 네가지 이상의 언어를 동시에 사용하며 코딩을 해
야할때도 있습니다.
(아주 고역입니다. 기본적인 변수 할당 할때 조차도 실수를 가끔하지요.)

사용빈도가 높은 언어는 그만큼 그나름대로의 장점이 있어서입니다.
그러한 장점과 단점을 알고자 하신다면 다양한 언어로 코딩을 해보는 것
이 정답일 것 같군요.
hello world!!! 몇줄을 출력해보는 간단한 프로그램으로는 알수가 없겠
지요.

PS. 자신이 애용하는 언어가 가장 우수하다는 것은 넌센스입니다.
그것은 자기 마누라가 젤 이쁘다고하는 남자의 주장과 같겠군요. 개인차
입니다.

rainlood의 이미지

무조건 python.
C와 C++만이 전부가 아니랑께

익명 사용자의 이미지

C 와 C++ 에 대한 개인적인 생각입니다.
시스템프로그래밍과 같이 수행속도와 코드의 크기등이 중요한 문제가 되
는 경우에는 c 가 여전히 중요한 언어로 역할을 할 것으로 생각되지만,
많은 인원이 개발에 참여하는 대형 프로젝트의 경우에는 c++ 를
채택하는 것이 유리할 것으로 생각됩니다.
C++ 를 사용하여 프로그램을 작성하는 경우 코드의 크기가 다소 커지고
수행속도가 늦어질 수 있지만, 하드웨어가 급속도로 발달하는 현재의
추세로 본다면, 개념적으로 우수한 c++ 가 앞으로 더욱 더 많은
프로그래밍에 적용될 것으로 생각됩니다.

익명 사용자의 이미지

하지만,구별은 해야 된다 생각하는데...

그래야,언어의 발달이 집중적으로 이뤄지니까여...

새언어가 나오면 프로그래머들이 매우 힘드니까....

CGI는 PHP,windows 환경하엔 Visual c++ 이런식으로...

제생각엔 둘다 필요하네요...GNU C/C++라...웬지 어감이 좋네요...^^;;

익명 사용자의 이미지

어떤게 정확하게 더 좋다고는 말 못하겠죠..
하지만 LINUX던가..? UNIX던가를 C++로 포팅하는 작업이
거의 마무리 단계까지 갔다가 마지막에 포기되었다는
이야기를 들었습니다.. 꽤 오래전 이야기지요..
C++로 짠 코드가 너무 무거워서 그렇다더군요..
꼭 신기술 이라고 좋은것은 항상 아니겠지요..
하지만 배보다 배꼽이 더 커져버리는 상황이 되면 안되겠지요..
개인적으로는 C가 더 좋습니다만.. ^^;

익명 사용자의 이미지

어느것이 좋다 나쁘다는 별로 의미가 없다고 봅니다.
다 아시다 시피 리눅스는 대부분이 C언어로 코딩되어 있습니다.
하지만 C언어로 코딩되어 있다고 해서 C언어가 최고의 언어는
아닙니다.
어짜피 컴퓨터가 알아 들을수 있는것은..
01010이런 기계어밖에 못알아 들으니까요..
어떤 컴파일러가 인간의 언어(?)를 기계어로 최적화 시키느냐가..
중요하죠...

하지만 C보다는 C++이 많이 쓰이니(뭐 꼭 그런건 아닙니다..)
코드의 재활용이 쉽고 C보다는 조금이나마 구체화적인
프로그래밍이 가능한 C++이 낫다고도 생각하지만..
그거야 뭐 프로그래머가 익숙해져있는 언어에 따라
다르니..
...그럼 이만..

-대한민국은 내가 지킨다..
육군말년 병장 장병장-

정규현의 이미지

웹 어플리케이션 개발을 위해 어떤 언어가 가장 좋은가?
펄, 파이썬, C, ASP, 델파이, PHP, JSP, CFM 어느게 제일 좋지?
언어에 도대체 우열이라는게 존재하나?
그때 그때 필요한 경우에 맞는 언어가 다르다.

마찬가지다.
리눅스에서 "뭘" 개발하느냐에 따라 알맞는 언어가 다르다.
레드햇 배포판의 인스톨러는 파이썬으로 만들어졌다.
상당수의 어플리케이션은 펄로도 만들어진다.
리눅스 커널은 C로 만들어졌다.
자바로 만들어진 어플리케이션도 있다.

이런 토론해서 대체 뭘 하자는 건가?
C++이 객체지향개념이 있고, 그래서 재사용가능하니
C보다 더 언어상으로 우수하다는 말을 하고 싶은건가?
(사실 프로젝트 해보면 별로 그렇지도 않다.
C++ 쓰면서 제대로 객체지향개념으로 하는 사람 본적없다.
심지어는 자바도 C식으로 쓰는 사람 무수히 봤다.)

익명 사용자의 이미지

물론 문맥에 따라 그에 적당한 언어들이 있지요.
펄이나 피에치피처럼 특화된 언어가 있으니까요.
그나 이번 질문은 그런 것이 아니라고 봅니다.

예컨대 씨가 처음 개발될 당시에도 분명 이런 논쟁이 있었을
겁니다. 시스템 플밍에 씨냐 어셈이냐... 이런 논의를 무의미하다고
할 수 있을까요? 당근 아니지요.
어셈과 씨에 대한 논의는 언어가 적용되는 도메인에 대한 것이
아니지요. 둘은 일단 일치하니까요. 또 수행 능력에 대한 것도
아닙니다. 당근 어셈이 월등하니까요. 문제는 문제에 대한 접근 방식
이라는 거지요!
이번 경우도 마찮가지입니다. 씨나 씨뿔뿔이나 비슷한 문제 영역을
갖고 있고, 비슷한 수행능력(대체로 말해서)을 보입니다. 개발속도
등도 많은 경우 개발자의 역량에 달린 것이니 별 차이가 있다고
생각할 순 없지요. 즉, 제가 생각키에 이 문제는 리눅스 플밍에 씨를
쓰느냐, 씨뿔을 쓰느냐가 관건인 것이 아닌 겁니다.
관건은 오오피 등등의 현대적인 개념들을 플밍에 이용할 것이냐,
말 것이냐 하는 것이라고 전 생각합니다.
사실 이런 개념들을 제외한다면 씨뿔뿔은 조금 편한 씨에 불과한 거
아닙니까?
토론을 보면 씨뿔에 대해 거부감을 보이신 분들은 거의 오오피적인
개념에 난감해 하시는 것 같습니다. - 오오피가 만병통치약이거나
완성된 개념이거나 한 건 아니지만, 많은 장점을 가지고 있고,
소프트웨어 개발에 많은 유연성을 준다는 건 이미 객관화된 사실
이지요. 또 회피될 수 없는 주류로 다가오고 있다는 것도 현실이고요.
그걸 단지 공부하기 난해해서 접어둔다는 건 문제가 있는 거지요.

어셈과 씨의 논쟁에서라면 씨를 권했어야죠. 왜냐면 그것이 대세가
될 것이 눈에 보이니까요. 단지 새로 언어를 익히기가 힘들다고
어셈에 머물고 말아서는 안되죠.
이번도 마찮가지 아닐까요? 씨는 어느 정도 구닥다리고, 장래 기술의
주류는 역시 오오피적인 개념, 혹은 그 고민에 기반해 있을 것이라고
분명하게 지적해 주어야 하는 것 아닐까요? 씨가 낫다 씨뿔이 낫다는
유치한 얘기를 떠나서 말입니다.-도대체 어떤 언어가 낫다는 둥의
바보같은 논쟁은 없어져야지요. 단 각 언어에 대한 객관적인 특단점에
대한 논의마저 거부되어서는 안되겠고요...

익명 사용자의 이미지

말씀하신 바와 같이 어떤 상황이냐가
아주 구체적으로 전제되지 않는 한
무의미한 질문이라고 생각합니다.


도대체 콩나물과 두부 중에서 어떤 것이 좋은 반찬거린지
답이 있을 수가 없지 않습니까?

익명 사용자의 이미지

토론 제목에 대해서 비꼬는 것은 절대 아닙니다.

어릴적에 마징거 제트와 테권브이가 싸우면 누가 이기나로

친구와 말다툼을 한게 생각나네요.

각 언어의 특정한 부분을 가지고 우위를 얘기한다면 몰라도

그냥 전체적인 우위를 말한다는 것은 결론이 없다고 생각합니다.

익명 사용자의 이미지

무의미 하다니요...^^;

각 환경에 적합한 언어가 있다?

그럴리가요...^^;

절대 그럴리는 없지요...

다만 쉽게 개발할수 있도록 나온것이 있을 뿐이져....^^;

쉽다고 다 좋은것은 아니라는 것을 알지요?

PHP로는 죽었다 깨어나도 구현하지 못하는 부분이 있을수 밖에 없다는것..

이게 쉬운 언어들의 한계지요.....^^; 다 아시리라 믿습니다..

하지만 C 나 C++로는 대부분 계발이 가능하지요.. 에플릿을

제외하고는요...

C 와 C++의 가능성은 무한하다고 판단을 할수 있지요..

제가 볼땐 C도 좋고 C++도 좋지만....

개발 속도면에선 C++ 이 좋고, 디버깅하는데는 C가 아무래도 좋고요..

실행 속도와 디버깅 측면에서 생각할때 개인적으로는 C++보다는 C가

바람직 한거 같아요...

그리고 다른 유닉스나 다른 운영체게로의 포팅 또한 C가 C++보다는

어느정도 쉽게 이루어 질수 있다고 생각을 해요...^^;

결론은 둘다 좋아요... (솔직히 C나 C++에 도전을 할 수 있을 만한 언어

는 자바 정도 밖에......^^ 없다라고 생각을 해요....)

다른 언어들을 C나 C++과 비교를 한다는 것 은 좀 무리가 있지 않은가

생각을 합니다...

다즐링의 이미지

어떤 언어든 어디에서든쓸수 잇습니다..

IRC에서 이야기하는데 어느분이 그러시더군요

"PHP는 웹랭기지자나요"

정말 PHP가 웹 랭기지 일까요?

본인은 php를 쉘에서 실행하여서 시스템 관리툴로 쓰고잇습니다.

"perl은 CGI전용 아닌가요?"

perl(제가 가장 사랑하는 랭귀지죠)은 기본적으로 여러분의

아파치를 띠워줍니다 CGI에서 클래스터링까지 머든 가능합니다.

자 그럼 언어의 차이는 머가 있을까요?

밑에분이 적으신것처럼 1줄이나 2줄이냐 정도 차이라고 생각되는군요.

물론 속도도 틀리겟지요 :)

그리고 설계나 구현등에서 어떤것이 자신에게 편하고 작업해야되는

목표에 편한가를 생각해보아야 하겟지만요 :)

ps. Perl 같은 경우엔 CPAN이 엄청난 매리트죠 :)

------------------------------------------------------------------------------------------------
Life is in 다즐링

익명 사용자의 이미지

그건 좀 아니라고 생각합니다.

php를 이용해서 물론 시스템 관리툴을 만들수도 있겠지만, 그건 결국 조잡한 시스템 콜 기능밖에 없는 프로그램 입니다.

Perl의 경우는 조금 다르긴 하지만, 역시 Perl로 클러스트링을 한다는 건 조금 무리가 있습니다.

하지만, C로 할 경우엔 다릅니다.

허접한 시스템 콜로 구성된 조각누더기 프로그램이 아닌, 순수 오리지널 프로그램 제작이 가능하기 때문이죠. (의미상이 아닌 기능상으로 구현할 수 있는 범위 자체가 다릅니다)

님께서 말씀하신 건 이렇게 들리네요.

주걱으로도 밥 잘 먹는데, 왜 굳이 숟가락을 고집하느냐...

물론 하면 합니다. 하지만 좀 더 깊은 의미와, 단순한 언어를 넘어서, 언어가 돌아가는 프로세스의 세계에 대해서 깊이있는 이해가 필요할 것 같습니다.

익명 사용자의 이미지

그렇치 않습니다.
그럼 이언어는 쓸모없나여?
역시 그렇치 않습니다.
포트란이 얼마나 많은곳에서 쓰이는지 알면,
놀라는 분도 있을겁니다. 저 처럼여...

정규현의 이미지

C/C++이 대단히 깊숙한 시스템레벨을 건드릴수 있는
언어이고 따라서 일반적인 어플리케이션 레벨이 아닌
시스템레벨의 개발에 있어 타의 추종을 불허하는 언어란것에는
동의합니다.

그러나 세상에 시스템레벨의 개발만이 있는것은 아닙니다.
(아니 오히려 시스템레벨의 개발은 얼마 안됩니다.)
시스템이 아무리 잘 되있어도 어플리케이션이 없으면
시스템은 아무리 소용없는법.

예를 들어 특정 스트링을 다른 스트링으로 교체한다거나(subsitute)
구분자를 이용해 분해(split,join)하는 경우 펄이나 PHP로
단 1~2줄로 끝나는걸 C/C++을 이용하면 10여줄가까이 적어줘야 합니다.

운영체제를 펄로 만들수는 없지만,
어플리케이션 만드는데 있어 단 2줄이면 간단히 끝나느데, 굳이
10줄이상을 써가면서 코딩해야하는 이유가 있습니까?

웹사이트 만드는데, 파라메터 디코딩을 위해서
PHP나 ASP사용하면 단 1줄로(정확히 말하면 디코딩루틴이 필요없죠)
끝나는데, C/C++의 경우 별로 라이브러리(qDecoder같은거)쓰고도 3~4줄은
적어줘야 됩니다.

대부분의 개발에 있어서 가베지 컬렉션이나 포인터, 메모리 관리
같은 로우레벨의 사항들을 알아야 할 이유가 뭡니까?
오히려 그런것들을 신경씀으로 해서 정작 사용자가 원하는
비즈니스 로직이 제대로 안되지 않습니까?

시스템레벨의 개발이 고급기술이고 어플리케이션레벨의 개발이
그보다 저급한 기술이라는 일부 기술자들의 주장에 동의하지 않습니다.
그건 엄연히 다른 분야입니다.

웹사이트 만드는데 적합한 언어와 윈도우 어플리케이션 만드는데
적합한 언어, 운영체제나 디바이스 드라이버 만드는데 적합한
언어는 다를수 밖에 없습니다.

C/C++이 현대 거의 대부분 언어의 어머니이긴 하지만,
거기까지만 했으면 좋겠습니다. C/C++는 전제군주가 아닙니다.

익명 사용자의 이미지

대체 이언어 왜 만들었는지 궁굼하다. C++ 제작자 스트라우스트럽씨.. -_-

이름도 부르기 어렵구먼, 이 아저씨의 머리속엔 대체 뭐가..

차라리 C의 객체지향적인 언어의 발전이라면 자바가 C의 확장판이다.

우선 짜증나도록 배우기 디럽게 어렵다..

실제적으로 C++의 C에서 없는 개선된 사항들..

this 포인터 가상함수 클레스를 자유자제로 진짜 OOP적으로 하는 사람

내가 회사에서 학교에서 전산분야로 10년은 보았지만 못봤다.

거의 C++을 단순히 C의 이름만 다른 컴파일러정도로밖에 사용못한다.

그리고 클레스도 구조체랑 별다를게 없이 사용한다. -_-

상속?? 이거도 물론 할려면 윗단계부터 클레스와 함수를 잘 만들어놔야 되
는데 그러질 못해서 똑같은거 비슷한거 또만들고 또만들고.. 부지기수다.

차라리 자바는 크로스 플랫폼이기나 하지..

C++은 속도가 빠르길 하나 개발의 편이성도 없고 디버깅도 어렵고,

포팅도 어렵고 대체 뭐가 이득이란건지 비쥬얼씨++로 M$의 전략대로 놀아
나는 윈도 프로그래머들때문에 C++이 많이 쓰이는 것뿐이다.

대체 쓸데가 없다. 그시간에 딴언어 완벽히 배우는게 낳다.

파이썬같은 거나 Perl도 좋다.

musiphil의 이미지

신근철 wrote..
:
: 차라리 자바는 크로스 플랫폼이기나 하지..

얼마 전에 들었던 인상적인 말 하나 소개하려고 합니다.

"Java is not platform-independent;
it is a platform."

몇 년 전부터 신문에서는 내일이라도 금방 자바가 세상을 장악할 것처럼
떠들었었지만, 지금 결과는...

익명 사용자의 이미지

C++은 객체지향을 흉내낼려다가 망해가는 언어일뿐이다.

왜냐고?? 지금 상황을 보라.

C++이 많이 쓰이는 건 단순히 윈도 플랫폼의 MFC때문이다.

리눅스? 유닉스?? 타 플랫폼을 보라.

어느곳에서 C++이 시스템 프로그래밍이나 어플에 쓰이는가?

단지, GUI 프레임웍 라이브러리인 Qt밖에 안쓰인다.

객체지향으로 따지자면 같은 GUI 라이브러리인 Gtk가 낳다.

C로 작성되었지만 객체지향적으로 설계되었다.

그리고 함수가 훨씬 알기 쉽고 코딩하기 쉽게 되어있다.

이게 객체지향적이지 않은가? 객체를 프로그래머가 쉽게 다뤄서

코딩하기 편하면 그만인것이다. 이게 진정한 OOP적이다.

괜히 클레스에 쑤셔넣고 상속하느니 마느니 하면서..

머리 싸맬 필요가 없다.

이건 차라리 라이브러리 하나 작성해서 넣어버리는게 진짜 상속이지.

언어는 프로그래머에게 편하게 되어야 한다.

그러면에서 파이썬이 낳다고 한것이다.

또한 씨의 진정한 객체지향적 확장 언어는 오브젝티브 씨 이다.

기존의 C 프로그래머라면 단지 몇일 문법 좀 외우고..

아니 좀 시간내면 단 하루만에도 완벽히 익혀서 쓸수가 있다.

옛날 NeXTSTEP의 기본 개발 언어였다.

이말만으로도 이유는 충분하리라 본다.

처음으로 객체지향적인 개발을 기본 OS에 적용시킨 넥스트스텝이란 OS.

익명 사용자의 이미지

나는 학교에서 회사에서 ..
한 13년정도 있었는데,

c++을 OOP적으로 하는 사람
적지 않게 봤는데...

c++이라는 language를 그렇게 함부로 평가할 자격은 있으신 건지?

혹시, 10년정도 있었다는 그 학교나 회사가
안좋은건 아닌지?

박응주의 이미지

스트라우스트럽인가... C++만들 아저씨가 그랬죠.
첨에는 C++이 제공하는 C의 확장기능(inline이나...)등만 사용하고
그담에는 stl같이 남들이 만들어 놓으거 사용하고
그담에는 자기도 클래서 같은 거 만들어서 짜고....

저도 별로 C++을 좋아하지는 않지만 위의 말이 맞다고 생각합니다.
C++이 제공하는 모든 기능을 다 이해하고 사용할려고 하니까 어려운거지
자기가 필요한 만큼만 조금씩 배워 나간다면 C++도 나름대로 괜잖을 것
같은데...

리눅스에서도 QT와 관련되지 않은 프로그램들은 아직도 대분분 C로
작성되죠..
그라고 glib1.3부터는 gtk에서 쓰이던 객체시스템을 glib로 옮겼다고 합
니다.

berise의 이미지

신근철 wrote..
: 우선 짜증나도록 배우기 디럽게 어렵다..

자신이 싫어하면 당연히 어렵게 느껴지고 하기실은 것 아닌강?
자기가 어렵다고 언어가 꾸지다고 말을 하는데 이건 논의할 의사가 없다는
게 아닌가요?

: 실제적으로 C++의 C에서 없는 개선된 사항들..
: this 포인터 가상함수 클레스를 자유자제로 진짜 OOP적으로 하는 사람
: 내가 회사에서 학교에서 전산분야로 10년은 보았지만 못봤다.

개선된 사항들... 해서는 this 만 가지고 예를 들었을까요? 게다가 this는
C++이 가진 특성과는 거의 관계가 없는 self-reference를 위한 것인데.
예를 들고 싶으면 좀 더 자세한 지식으로 드는게 어떨까요?

하지만 진짜 OOP적으로라는 말은 동감합니다. OOP적으로 작성하는 게 무척
이나 어려운 일이죠, 그래서 클래스를 계속 고쳐가며 개선해 나가는 거죠.
이건 C 함수 고치는 거랑 다를 바 없는 거죠.

: 거의 C++을 단순히 C의 이름만 다른 컴파일러정도로밖에 사용못한다.
: 그리고 클레스도 구조체랑 별다를게 없이 사용한다. -_-

별 다른게 없습니다.
struct func { void hello(); };
class func { void hello(); };
두 코드는 차이가 없습니다.

: 상속?? 이거도 물론 할려면 윗단계부터 클레스와 함수를 잘 만들어놔야 되
: 는데 그러질 못해서 똑같은거 비슷한거 또만들고 또만들고.. 부지기수다.

하나의 C 라이브러리가 만들어질 때까지 계속 고쳐나가는 게 정상이 아닌가요?
좋은 C++ 라이브러리 역시 계속 고쳐나가며 버전-업 해 나가는게 정상입니다.
버전-업 하면서 상속 상태도 좋아지고 하는게 아닌가?

:
: 차라리 자바는 크로스 플랫폼이기나 하지..

hello_world.cpp 를 UNIX계열이나 윈도 계열이나 맥이나 동일한 결과를
출력합니다. 자바의 크로스 플랫폼은 하위 VM이 포팅되기 때문이죠. 따라서
hello_world.cpp는 c/c++ 컴파일러가 있는 플랫폼에서 다 정상적으로
컴파일 되고 수행됩니다.

상식적으로 생각해서 java VM 이 더 많이 포팅되었습니까? 아니면 c/c++
컴파일러가 더 많은 플랫폼으로 포팅되었습니까? 잘 생각해 보시길.

: C++은 속도가 빠르길 하나 개발의 편이성도 없고 디버깅도 어렵고,
: 포팅도 어렵고 대체 뭐가 이득이란건지 비쥬얼씨++로 M$의 전략대로 놀아
: 나는 윈도 프로그래머들때문에 C++이 많이 쓰이는 것뿐이다.

이건 도대체가 반박할 여지가 없군요. 말도 안되는 글 뿐이라. 함수 트레이싱
해 보세요, c++에서는 제대로 따라가지 않나?

일반적으로 실행 코드면에서는 C가 빠르죠
하지만 일반적으로 C++을 이용한 어플리캐이션의 개발 속도가 더 빠르답니다.

: 대체 쓸데가 없다. 그시간에 딴언어 완벽히 배우는게 낳다.
: 파이썬같은 거나 Perl도 좋다.

python이나 perl로 시스템 프로그래밍을 할 수 없습니다. 하지만 c++로는 가
능하지요. 게다가 linux나 NT 같은 종류는 디바이스 드라이버까지 c++로
가능하답니다.

한줄 한줄 반박하는 게 저도 맘에 안 들지만 어쩔 수 없습니다. 신근철님의
글이 너무나 마음에 들지 않기 때문입니다.

berise.

익명 사용자의 이미지

소프트웨어 공학 프로세스 성숙수준이 낮을수록 C++을 별거
아닌걸로 생각하는 경향이 있는것 같다.
개 노가다 코딩만 하는 사람이 C++의 객체지향을 알아서
뭐할까.. 어차피 걍 되는대로 만들겠지.
어느수준 이상으로 올라가면 확실히 C++의 장점을
볼 수 있게된다..
C++을 C의 뽀록개선판이라고 폄하하는건 그만큼의 수준에 아직
올라있지 않다는 증거다.

익명 사용자의 이미지

: 차라리 C의 객체지향적인 언어의 발전이라면 자바가 C의 확장판이다.

맞는말 인거 같습니다.

: 우선 짜증나도록 배우기 디럽게 어렵다..
저도 c++을 배웠지만 너무 어렵더군요

: 포팅도 어렵고 대체 뭐가 이득이란건지 비쥬얼씨++로 M$의 전략대로 놀

: 나는 윈도 프로그래머들때문에 C++이 많이 쓰이는 것뿐이다.
:
: 대체 쓸데가 없다. 그시간에 딴언어 완벽히 배우는게 낳다.
:

저도 같은 생각입니다.

P.S C++은 싫어 합니다.

익명 사용자의 이미지

C++에 적용된 개념은 Class 밖엔 없습니다. 그이외의 특성은 대부분
문법에 기인한 것이지요.

C++도 표준은 따로 존재하고 수많은 컴파일러들이 존재합니다. 특히
나 C++이 많이 쓰이는 곳이 windogs에서 MFC들을 이용하기 위해 나
온 개발툴인 Visual C++이겠지요.

하지만 C++을 볼때 자바하고 무엇이 크게 어려운 가요? 기존의 C사용
자라면야 응당 해주어야 할 memory관리 에서 low level access까지
일일히 신경써주는 것이 몸에 베었을 테고, class 관리만 제대로 하면
되는 것 아닐까 하는 생각이 듭니다. 다중상속과 같이 복잡한 부분들
은 오히려 혼동을 불러일으키는 소지가 될 테니 사용을 줄이면 될테
고.

하지만 C가 더 좋은 이유는 역시 빠르기 때문이겠죠. C++에서 지원되
는 표준 클래스들이 편한 장점이 있는 반면 너무 sizing에서 많은 데
미지를 주니깐.. 홋홋.. 아닌가요? 전 내내 똑같던데. 하지만 지금은
java를 씁니다. -_-;;

결국 회사에 매인 몸들은 자기의 의지와는 상관없이 개발을 하지요.

익명 사용자의 이미지

각각의 언어가 적용시 최고의 성능의 낼수 있는 파트가 있는데 굳이 이런 토론
을 하는 이유를 모르겠군요. 윗분들 중에도 비슷한 의견 가진 분들이 있던
데... 만약 둘중에 하나가 잘나서 하나만 써도 뭐 나쁘지는 않겠지만 각각의
장정의 잘 살려서 개발한다면 더 낫지 않을까요? 첫 제의의 대한 저의 의견은
둘다 좋다. 입니다. 자 그러니 개발에나 집중하시죠?

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.