C++은 C의 확장?

mastercho의 이미지

관리자 알림 메시지: 이 글은 RisaPapa님의 http://bbs.kldp.org/viewtopic.php?t=27203 로부터 분리한 글입니다.

Quote:
C++은 위험적인 요소나 불필요한 요소를 많이 포함하고 있다고 생각됩니다. 제가 말하는 위험적인 요소는 프로그램 설계를 할때 후에 유지 보수면을 함께 고려하는 것이 쉽지 않고 한번 결정한 것으로 인해 유지보수를 할 수 없어 페기할수밖에 없는 최악의 상황이 나오지 않을까 하는 염려입니다. 아직까지 실력이 부족한 탓인지도 모르겠습니다. 반면에 C의 구문은 상대적으로 단순하고 특별히 고려해줄 필요가 없습니다. 하지만 C++에 비하면 재활용성이 아무리 고려를 하고 구상을 해도 많이 떨어지는 것 같습니다. 두 언어 모두 현재 널리 쓰이고 다른 언어가 굳이 필요할 만큼 나쁘지는 않지만 개선의 여지가 있고 약간 개선되었으면 하는 바램이 있습니다.

이말씀은 C++를 잘 몰라서 하는 말씀으로 이해하겠습니다

위에서 주장하신 말씀은 너무나 답답한 말씀이어서 ,
말이 튀어나갓다간 , 감정이 섞일수 있는 관계로 그만두겠습니다만

C++를 스스로 거의 잘 모른다고 말씀하시면서 너무나 잘아시는것처럼
단점을 꼽으셨는데 , 사실 그런 단점이 있는지 제대로 아시는지 궁금하네요
[꼽은셨던 단점은 오히려 C의 단점으로써 C++에서 오히려 극복이 된점입니다]

모르면 차라리 말을 하지 않는것만 못하다고 생각합니다

[원하시면 하나 하나 인용해서 반박해 드리겠습니다]

그럼

File attachments: 
첨부파일 크기
PDF icon J16.pdf193.41 KB
PDF icon n1457.pdf1.15 MB
파일 main.c72바이트
파일 lib.cpp3.53 KB

댓글

alfalf의 이미지

mastercho님께서 설명을 달지 않으셔서 어떤 이유에서 그런지 궁금하네요.

mushim의 이미지

Quote:
위에서 주장하신 말씀은 너무나 답답한 말씀이어서 ,
말이 튀어나갓다간 , 감정이 섞일수 있는 관계로 그만두겠습니다만

이미 감정이 섞여 있군요.

Quote:
[원하시면 하나 하나 인용해서 반박해 드리겠습니다]

그냥 인용해서 반박하시면 됩니다. 감정적인 사족 필요없이...
이한길의 이미지

to. mastercho

제말씀을 잘못 이해하셨는지 제가 정말 답답한 말을 했는지 모르겠습니다. 저는 C++을 제대로 알지 못하고 사용했을 경우 매우 문제가 되는 코드를 만들어 낼 수 있으며 그러한 요소는 차라리 배제하는 것이 났다는 의미해서 불필요한 요소를 포함하고 있다고 쓴 것이었습니다.

제가 생각하는 C++의 가장 큰 문제점은 C의 표준 함수를 더블어 사용할 수 있고 그로 인해 야기되는 문제들입니다. 그렇다고 아예 사용하지 않을 수 있는지 의문입니다.

mastercho wrote:
[원하시면 하나 하나 인용해서 반박해 드리겠습니다]

부탁드리겠습니다.

-------------------------------------------------------------------
이하는 위에 분이 언급하셔서 다시 편집했습니다.

----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.springnote.com
http://hangulee.egloos.com

mastercho의 이미지

일반적으로 자기가 좋아하며 연구하는 언에 대해 자부심을 가지게 마련입니다

따라서 제가 C++를 좋아한다고 해서 C#, 자바를 완벽히 알지도 못하면서 폄하 하면 안되듯이 , 이런분야의 말일수록 쉽게 말해서는 곤란하다고 생각합니다

지금 제가 바로 답글 단것을 피한것은 "어느 언어가 좋은지"에 대한 불필요한 논쟁을 불러 일으킬수도 있기때문에 자제한것이고

위에 글 쓰신분에게 잘못된 이야기를 수정하도록 요구하는 것입니다

마침 위에 답글을 다셨군요 ,그럼 인용해서 답글을 달도록 하지요

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

이한길의 이미지

C++을 좋아하는 분이셨군요. 저도 C++을 싫어하지는 않습니다. 그렇다고 나쁜 언어라고 쓴것은 아닙니다. 언급했듯이 제대로 알지 못했을때 문제가 있다는 말씀입니다. 위험요소를 내제하고 있다는 것은 좋아하시는 입장에서도 동감하시리라 생각합니다만... 어떠신지 모르겠습니다.

----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.springnote.com
http://hangulee.egloos.com

mastercho의 이미지

이성을 가지고 이제 차근 차근 위에 대한 생각에 대한 반박글을 남기도록 하겠습니다

Quote:
언급했듯이 제대로 알지 못했을때 문제가 있다는 말씀입니다. 위험요소를 내제하고 있다는 것은 좋아하시는 입장에서도 동감하시리라 생각합니다만... 어떠신지 모르겠습니다.

-알지 못했을때 위험한것은 어떤 언어든 마찬가지 입니다 , 굳이 C++에서만 위험한것은 아니라고 봅니다

Quote:
제말씀을 잘못 이해하셨는지 제가 정말 답답한 말을 했는지 모르겠습니다. 저는 C++을 제대

로 알지 못하고 사용했을 경우 매우 문제가 되는 코드를 만들어 낼 수 있으며 그러한 요소는

차라리 배제하는 것이 났다는 의미해서 불필요한 요소를 포함하고 있다고 쓴 것이었습니다

- C++에서는 여러가지로 프로그램밍을 할수 있습니다 , 알지 못하면 쓰지 않으면 되고 그렇게 하더라도 프로그래밍이 됩니다 , 저도 아직까지 템플릿을 명확히 이해하고 많이 쓰지 못하고 있는데, 제대로 아는 만큼만 쓰면 되지 , 알지도 못하면서 쓰는건 당연히 아니지요...

이문제는 , 다시 말씀 드리지만 어떤 언어든 마찬가지 입니다
[불필요한 요소와 단순함에 대해서는 밑어 더 글이 남아 있습니다]

Quote:
제가 생각하는 C++의 가장 큰 문제점은 C의 표준 함수를 더블어 사용할 수 있고 그로 인해

야기되는 문제들입니다. 그렇다고 아예 사용하지 않을 수 있는지 의문입니다.

제가 C++를 쓰면서 C만 쓰는 분의 C++ 이야기를 들었을때 일반적으로 어처구니 없다는 생각을 많이 하게 됩니다, 왜냐하면 C++에서도 당연히 문제가 안되는것이고 오히려 C에서 문제가 되던것이 C++에서 대부분 해결된게 많습니다, 가장 답답한것은 C++를 공부해봤다면
전혀 문제가 없다는것을 알텐데 , 모르니까 "C++에서는 문제가 되지 않을까?"라는 생각을 한다는 것입니다

위에 말씀 하신 내용중 C의 표준함수를 더블어 사용됨으로써 발생하는 문제를
찍어주시면 좋겠습니다 , C++ 상식선상 C++에서 C표준함수를 쓴다고해서 전혀 문제가 되지 않습니다

지금부터는 처음 남기신 글에 대한 반박을 하겠습니다

Quote:
C++은 위험적인 요소나 불필요한 요소를 많이 포함하고 있다고 생각됩니다. 제가 말하는 위

험적인 요소는 프로그램 설계를 할때 후에 유지 보수면을 함께 고려하는 것이 쉽지 않고 한

번 결정한 것으로 인해 유지보수를 할 수 없어 페기할수밖에 없는 최악의 상황이 나오지 않

을까 하는 염려입니다. 아직까지 실력이 부족한 탓인지도 모르겠습니다. 반면에 C의 구문은

상대적으로 단순하고 특별히 고려해줄 필요가 없습니다. 하지만 C++에 비하면 재활용성이 아

무리 고려를 하고 구상을 해도 많이 떨어지는 것 같습니다.
습니다

정말 답답하게 느낀 대목이 바로 유지보수에 관한 내용입니다
객체지향이 왜 나왔는지 충분히 아시리라 믿습니다, 바로 유지보수및
코드[꼭 코드가 아니더라도]의 재활용이라는것에 큰 의미가 있습니다

C++에서는 클래스를 이용해 캡슐화를 하고 이로부터 유지보수의 엄청난 장점을 얻습니다
또한 클래스내부에서 private를 이용하여 유지보수를 위한 리펙토링이 손쉽게 할수 있는 장

점도 있습니다, 또한 class를 유틸리티나 라이브리러로 컴포턴트화 하면 , 다음 프로젝트때

도 쉽게 써먹을수도 있죠
굳이 객체지향을 들먹이지 않아도 충분히 이해하셨으리라 봅니다
말씀하신 유지 보수 불가같은것은 C++을 이용해서 엉터리로 프로그래밍하는 경우에나 나오

는것인데, 그것은 언어의 문제가 아니라 사람의 문제라고 보여지고 , C++이 아니라 어떤 언

어를 쓰더라도 부족한 능력의 사람이 쓰면 유지 보수는 불가합니다

C++의 객체지향을 사용하면 오히려 객체지향적인 요소를 강요하는면이 있기때문에
위에 말씀하신것은 전혀 동의 할수 없는 내용이라 보아집니다

또 C의 장점으로 단순하니까 C++보다 낫지 않냐는 말이 있는데
C++의 확장성과 방대함에 대한 불만이라고 보겠습니다
하지만 이것이 단점이라 생각하는건 크나큰 오해라고 볼수 있습니다

한가지 자료를 들어 말씀 드리자면
마이크로 소프트웨어의 2002년 01월호에 실려 있는
"더 높은 프로그래밍의 세계 Haskell로 가자" 라는 글이 있습니다
[이글을 쓴분은 김재우라는 분으로 많은 언어에 대한 이해를 가지고
자바와 다른 언어만을 고집하는 사람들에게 일침을 놓은분입니다]

거기서 글을 보면 이런 대목이 있습니다

Quote:
"자바 프로그래머중에는 GJ[자바언어의 확장] 제안을 받아들이는 경우 자바의 단순함이나
간결함을 해칠것이라 걱정하는 이들이 있는데, 이는 틀린 생각이다, 어떤 언어의 표현력이

늘었다고 해서 그 언어의 의미 체계를 고쳐써야 한다면, 그 책임은 그런 기법에 있는게 아니

라 언어 자체에 있다, 정말 좋은 언어라면 표현력을 더하기 위해 언어를 확장해도 기본이 되

는 언어의 알맹이가 뒤틀리거나 흐트러지지 않으며 불어나지도 않는다"

이 말에서도 볼수 있듯이 언어가 확장되고 방대하다고 해서 언어가 나뻐진다는 생각은
잘못된 생각입니다
C++은 언어적인 측면에서 C를 확장하고 수많은 패러다임을 흡수한것뿐이며,
언어적인면에서 엄청난 발전을 이루었다고 볼수 있는것이지
이렇게 방대하게 느껴지는것을 , 언어적인 측면에서 단순하지 않다며 나쁘다고
주장하는것은 잘못됐다고 봅니다

심지어 김재우라는분은 이런말까지 합니다

Quote:
"자바가 잘 설계된 언어라면 GJ제안은 부담이 아니라 불편하고 모자라는 부분을 채워주는 치

료제가 될 것이 틀림없고,더구나 그것이 GJ제안이라면 추가된 특징을 쓰지 않는 바이너리와
완전한 호환성을 보장하는 기술이라 큰 문제가 없다"

위글에 주장하는 바에 따르면
C++에서는 C의 수많은 단점을 극복해주었고 , 모자라는 부분을 엄청나게 채워줬음에
틀림없습니다
또한 호환성도 거의 문제가 안되죠
[미세한 차이는 거의 문제가 안됨으로 넘어갑니다]
또 다시 이야기 하게 되지만쓰기 힘들면 그 부분에 대한 내용은 안쓰면 되는것입니다

따라서 저로썬 , 말씀 하신 내용을 전혀 수긍할수 없는것입니다

이의가 있다면 답글 달아주십시오

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

kookooo의 이미지

mastercho wrote:
지금 제가 바로 답글 단것을 피한것은 "어느 언어가 좋은지"에 대한 불필요한 논쟁을 불러 일으킬수도 있기때문에 자제한것이고

우려하시고 나름대로 글을 쓰신거지만 그게 오히려 역효과를 가져올 소지가 다분한 답글이었다고 생각됩니다.
오히려 감정이 배제된 기술위주의 답변을 적는게 오히려 나은 듯하고..
그것이 혹 감정의 싸움이 된다고 해도.. 역시 많은 기술적 자료들이 나올테니 전체적으로는 나을 수도 있다고 생각되는군요..
mastercho의 이미지

사실 흥분한된 상태였기때문에 , 거친 답글이 나와
자칫 기분 나쁜 감정 싸움으로 바로 이어질거 같아서

생각좀 정리 하는 편이 좋을거 같아 그랬던거 같습니다

물론 반박하시오 라는 대답이 나올지 예상은 했고요

:) 흥분된것을 가라 앉히는 시간 벌기 용이었던거 같네요

C++언어에 대한 자부심이 강하다보니

오해가 있던면에서는 양해를 부탁드립니다

어째튼 흥분을 가라 안 히고 답글을 남기느라 좀 애먹었습니다 ~ :oops:

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

죠커의 이미지

mastercho wrote:
Quote:
"자바 프로그래머중에는 GJ[자바언어의 확장] 제안을 받아들이는 경우 자바의 단순함이나
간결함을 해칠것이라 걱정하는 이들이 있는데, 이는 틀린 생각이다, 어떤 언어의 표현력이

늘었다고 해서 그 언어의 의미 체계를 고쳐써야 한다면, 그 책임은 그런 기법에 있는게 아니

라 언어 자체에 있다, 정말 좋은 언어라면 표현력을 더하기 위해 언어를 확장해도 기본이 되

는 언어의 알맹이가 뒤틀리거나 흐트러지지 않으며 불어나지도 않는다"

이 말에서도 볼수 있듯이 언어가 확장되고 방대하다고 해서 언어가 나뻐진다는 생각은
잘못된 생각입니다
C++은 언어적인 측면에서 C를 확장하고 수많은 패러다임을 흡수한것뿐이며,
언어적인면에서 엄청난 발전을 이루었다고 볼수 있는것이지
이렇게 방대하게 느껴지는것을 , 언어적인 측면에서 단순하지 않다며 나쁘다고
주장하는것은 잘못됐다고 봅니다

우선 C++는 언어적으로 C를 확장한 것이 아닙니다. struct나 const등 같은 키워드는 비슷할 가능성이 있지 호완되지 않습니다. C90이상의 C로 짜여진 대형 프로젝트를 C++으로 옮길때 문제점이 발생할수 있습니다. 김재우씨가 좋다고 주장하시는 Haskell의 경우는 얕게봐서 잘 모르겠습니다만 적어도 C++은 언어의 알맹이가 뒤틀리거나 흐트러지지 않으며 불어나지도 않는다는 것과는 거리가 있습니다. C++의 템플릿같은 기능들은 매우 훌륭하다고 생각하지만 export와 같은 키워드는 컴파일러가 지원해도 쓰고 싶지 않습니다. C++이 방대해지면서 장점과 단점을 가졌는데 저희는 장점을 골라써야 한다고 봅니다. C++은 쌍절곤 같다고 봅니다. 말의 뼈를 부술정도로 강하고 매력적이지만 미숙하면 자신이 다칠수 도 있는...

mastercho wrote:

심지어 김재우라는분은 이런말까지 합니다

Quote:
"자바가 잘 설계된 언어라면 GJ제안은 부담이 아니라 불편하고 모자라는 부분을 채워주는 치

료제가 될 것이 틀림없고,더구나 그것이 GJ제안이라면 추가된 특징을 쓰지 않는 바이너리와
완전한 호환성을 보장하는 기술이라 큰 문제가 없다"

위글에 주장하는 바에 따르면
C++에서는 C의 수많은 단점을 극복해주었고 , 모자라는 부분을 엄청나게 채워줬음에
틀림없습니다
또한 호환성도 거의 문제가 안되죠
[미세한 차이는 거의 문제가 안됨으로 넘어갑니다]
또 다시 이야기 하게 되지만쓰기 힘들면 그 부분에 대한 내용은 안쓰면 되는것입니다

따라서 저로썬 , 말씀 하신 내용을 전혀 수긍할수 없는것입니다

이의가 있다면 답글 달아주십시오

위에서 김재우씨가 말한 GJ가 문제가 되지 않는 것은 템플릿과 같은 것은 자료형에 맞게 그 명칭에 맞는 함수나 클래스를 더 만들어주면 해결되는 문제라서 실질적으로 Java 자체가 수정되는 것은 없습니다. GJ같은 것은 도입해도 좋은 것이지요. 그것과 C++는 논외라고 봅니다.

mastercho의 이미지

CN wrote:

우선 C++는 언어적으로 C를 확장한 것이 아닙니다. struct나 const등 같은 키워드는 비슷할 가능성이 있지 호완되지 않습니다. C90이상의 C로 짜여진 대형 프로젝트를 C++으로 옮길때 문제점이 발생할수 있습니다. 김재우씨가 좋다고 주장하시는 Haskell의 경우는 얕게봐서 잘 모르겠습니다만 적어도 C++은 언어의 알맹이가 뒤틀리거나 흐트러지지 않으며 불어나지도 않는다는 것과는 거리가 있습니다. C++의 템플릿같은 기능들은 매우 훌륭하다고 생각하지만 export와 같은 키워드는 컴파일러가 지원해도 쓰고 싶지 않습니다. C++이 방대해지면서 장점과 단점을 가졌는데 저희는 장점을 골라써야 한다고 봅니다. C++은 쌍절곤 같다고 봅니다. 말의 뼈를 부술정도로 강하고 매력적이지만 미숙하면 자신이 다칠수 도 있는....

C에서 확장한것이 아니라고 하신다면 어떤면에서 확장한게 아니라고
보시는지요?
객체지향 패러다임? C++은 처음에 C언어로 구현되었습니다
C언어를 확장에서 C++이 현재 추구하는 패러다임에 맞게끔 수정한것이지요
[물론 지금은 거의 독립되었습니다만은 ,C++의 발전사 자료를 찾아보시면 C에서 확장한 내용을 쉽게 찾을수 있다고 봅니다]

이부분은 오해의 여지가 남아있기때문에 , 딱히 모라 할순 없겠지만
단순히 단답형으로 , "아니다"라고 말씀하시는것에대해 불만이 있네요

다음으로
C에서 쓰인 const나 struct이 호환되지 않는다고 말씀하셨는데
어디서 호환이 되지 않는다는것인지요?
C++에서 C로 넘어간다면 문제가 되지 C에 있는 문법이 C++로 넘어가면서
문제가 되는 경우는 극히 드뭅니다
어떻게 문제가 되는지 예를 들어주셨으면 합니다

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

CN wrote:

위에서 김우재씨가 말한 GJ가 문제가 되지 않는 것은 템플릿과 같은 것은 자료형에 맞게 그 명칭에 맞는 함수나 클래스를 더 만들어주면 해결되는 문제라서 실질적으로 Java 자체가 수정되는 것은 없습니다. GJ같은 것은 도입해도 좋은 것이지요. 그것과 C++는 논외라고 봅니다.

C++은 논외로 붙이셨는데 , 왜 논외로 붙이셨는지 정확한 말씀을 해주셔야 이해가 갈거 같습니다
C++의 패러다임은 분명 명확하고 , 그것내에서 충실히 확장이 이루어지고 있다고 생각합니다

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

envia의 이미지

K&R의 머릿말과 같이,

Quote:
C is not a big language, and it is not well served by a big book.

그런데 C++은 작아 보이지는 않네요. :(

객체 지향은 좋지요. :)

얻는 것이 있으면 잃는 것도 있지 않을까요?

그리고 김재우씨의 글이 언급되었는데, 그 글이 Haskell을 쓰자는, 그러니까 Functional Programming의 패러다임을 받아들이자는 글이 아닐까라는 생각이 듭니다. 그런 글에서 C나 C++과 같은 옛 패러다임을 옹호했다는 것이 약간 이해가 되지 않습니다. (제가 아는 Functional Programming Mania들과 약간 달라 보여서요.)

----

It is essential, if man is not to be compelled to have recourse, as a last resort, to rebellion against tyranny and oppression, that human rights should be protected by the rule of law.
[Universal Declaration of Human Rights]

죠커의 이미지

mastercho wrote:
C에서 확장한것이 아니라고 하신다면 어떤면에서 확장한게 아니라고
보시는지요?
객체지향 패러다임? C++은 처음에 C언어로 구현되었습니다
C언어를 확장에서 C++이 현재 추구하는 패러다임에 맞게끔 수정한것이지요
[물론 지금은 거의 독립되었습니다만은 ,C++의 발전사 자료를 찾아보시면 C에서 확장한 내용을 쉽게 찾을수 있다고 봅니다]

처음에 구현한 언어가 중요한 것이 아닙니다. 현재의 C언어가 C++의 subset이 되지 못한다는 것이 중요합니다.

mastercho wrote:

다음으로
C에서 쓰인 const나 struct이 호환되지 않는다고 말씀하셨는데
어디서 호환이 되지 않는다는것인지요?

문자열상수와 struct, const를 다루어보겠습니다.

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

mastercho wrote:

CN wrote:

위에서 김재우씨가 말한 GJ가 문제가 되지 않는 것은 템플릿과 같은 것은 자료형에 맞게 그 명칭에 맞는 함수나 클래스를 더 만들어주면 해결되는 문제라서 실질적으로 Java 자체가 수정되는 것은 없습니다. GJ같은 것은 도입해도 좋은 것이지요. 그것과 C++는 논외라고 봅니다.

C++은 논외로 붙이셨는데 , 왜 논외로 붙이셨는지 정확한 말씀을 해주셔야 이해가 갈거 같습니다
C++의 패러다임은 분명 명확하고 , 그것내에서 충실히 확장이 이루어지고 있다고 생각합니다

템플릿 같은 것을 도입한다면 언어의 형식은 늘어나서 표현력은 늘어나게 되지만 컴파일러든 프리프로세서든 자료형에 맞춰서 함수와 클래스를 몇개 더 만들어 주면 되는 문제입니다. VM이나 컴파일러의 구조적인 변경없이 기능을 향상시킬수 있다면 표현력의 방향이나 VM과 컴파일러의 안정성의 측면이나 환영받을 수 있습니다. 하지만 C++은 C컴파일러의 구조적인 변화 없이 불가능하고 난해합니다. c++의 export와 같은 키워드는 Bobby Schmid가 장문의 글로 악평을 할만큼 좋지 못합니다.

Quote:
해결되어야 할 문제는 해결되지 않고, 실제로는 이 문제를 더 악화시키며, 번역 단위의 구문과 이름 확인을 손상시키고, 미래의 언어 혁신을 어렵게 하고, 완전히 지정하기가 불가능해 보이며, 실제로는 구현하기에 비용이 많이 듭니다. 정말 끔찍한 일입니다.

C++의 패러다임이 명확했다면 vc++도 표준을 지켰을겁니다. 현재는 gcc조차도 지키지 못하고 있습니다.

PS: 김재우씨의 이름을 잘못적어서 중간에 수정을 했습니다. 죄송합니다.

youlsa의 이미지

의견을 피력한데에 대해 민감하게 반응하지 않으셨으면 좋겠네요. 어디 무서워서 말이나 꺼내겠습니까? :)

이쯤에서 이런 류의 Flame전쟁의 이정도 시점에 항상 등장하는 Bjarne Stroustrup의 말을 한마디 인용해보는것도 재미있을것 같습니다. C++이 완벽하다면 그 이후의 프로그래밍 언어의 개발은 아예 없었겠지요. 그죠? :)

Quote:
C makes it easy to shoot yourself in the foot.
C++ makes it harder, but when you do, you blow away your whole leg!

=-=-=-=-=-=-=-=-=
http://youlsa.com

jj의 이미지

mastercho wrote:
...저도 아직까지 템플릿을 명확히 이해하고 많이 쓰지 못하고 있는데...

mastercho wrote:
...C++언어에 대한 자부심이 강하다보니...

오해가 있던면에서는 양해를 부탁드립니다

C++에서 자부심을 느낄만한 특징은 템플릿이 전부라고 생각합니다. 나머지는 다소 다루기 힘든 ... 괴물같다고 할까요?

개인적으로 C에 템플릿만 추가된다면, 시스템 프로그래머는 더이상 바랄것이 없을것 같습니다.

--
Life is short. damn short...

이한길의 이미지

제가 말을 잘못 꺼내서인지 Risapapa님이 꺼내신 주제와 다른곳으로 글이 흘러가버렸습니다. 죄송하구요.. 단순히 몇자만 언급하고자 합니다. 지금 시간이 없어서 .. 그리고 좀더 깊이 논의하자면 다시 주제를 올리는 것이 바람직 하다고 생각됩니다.

아주 간단한 예로 C의 표준 함수중 malloc와 같은 메모리 할당함수를 C++에서 사용하게 되면 상당히 심각한 문제가 발생합니다. 그렇다고 사용하지 않을수도 없습니다. realloc가 필요할 때도 있으니까요. new로 메모리를 할당하고 realloc로 크기를 변경할수는 없지요. 그렇기때문에 둘을 섞어 쓰다보면 코드가 그다지 바람직하지 않은 방향으로 흘러가게 됩니다.

다음으로.. 제가 C++로 제대로 된 프로젝트를 해보지는 않았지만 팀으로 구성을 해서 간단히 프로젝트를 해봤습니다. 인정하셨듯이 C++의 범위가 커서 그런지 각자가 같은 것을 구현해도 다른 방법을 사용하게 되기도 합니다. 이것은 팀프로젝트에 그다지 좋지 않은 영향을 줍니다. 결국 한명이 반 이상을 뜯어 고쳤습니다. 물론 제대로 알지 못한 사람들이 시작해서 이런 문제가 일어났다고 할수도 있겠지만 자바나 C는 이렇게까지 문제가 커질만큼을 허용하지 않습니다.

저는 템플릿을 좋아합니다. C++에서는 이 템플릿이 가장 매력이 있는 것 같습니다. 물론 자바에서 Object클래스를 상속해서 거의 해결할 수 있는 문제고 이 방향이 더 적절하다고 생각되지만 C++에서 템플릿 역시 매력적인 요소입니다. 저 역시도 C에 적절한 형태로 템플릿 기능이 추가된다면 좋겠다는 생각을 합니다.

----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.springnote.com
http://hangulee.egloos.com

mastercho의 이미지

CN wrote:

문자열상수와 struct, const를 다루어보겠습니다.

int가 2byte인 시스템에서 int x='hi'는 c에서는 맞는 말입니다. 문자열 상수도 c언어에서는 int형으로 정의되어 있습니다. 'hi'와 "hi"는 다릅니다. 하나는 int형의 크기이고 하나는 3byte이지요. c에서 문자열 상수는 int형의 자료를 표현하는 용도를 같이 가지기 때문입니다. 반면에 c++에서는 char형은 1 bye입니다. 당연하듯이 c++에서는 trucate해버립니다. 위에서 말했든 "hi"로 'hi'를 대체할수 없습니다. 더 비싼 비용 또는 코드의 변경이 필요합니다.

이부분에 관한부분은 어쩔수 없다고 생각되네요, Wanning이나 컴파일러 에러를 찾아 수정을 할수 밖에 없다고 생각이 됩니다
C++의 기능을 쓰기 위해 변경하는거라면 , 이정도는 어쩔수 없이 감수해야 한다고 봅니다
[제눈에는 문자열 상수를 int형 썼다면 오히려 더 안좋은 프로그래밍처럼보이네요, 차라리 수정하는것만 못할거 같습니다, ]

CN wrote:

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로 배열을 정의해보면 알수가 있습니다.

물론 C와 C++은 다른 세계라는것에 동감을 합니다 , 다만 C의 코드가
C++ 컴파일러에서 수정없이 컴파일 되며 결국 C컴파일러에서 컴파일한거와
같이 똑같이 작동을 해준다는 의미였습니다 [100%는 아니죠]
당연히 C++에서 사용하는 방식이나 의미가 C로가는 방향으로는 성립하지
않습니다 ,
그말이 C++이 C와 호환성이 있다는거지 C가 C++과 호환성이 있다는 말은
전혀 아니었습니다, 저도 전에 글에도 말씀드렸던걸로 기억되네요

CN wrote:

C++의 패러다임이 명확했다면 vc++도 표준을 지켰을겁니다. 현재는 gcc조차도 지키지 못하고 있습니다.

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

그리고 이미 표준에 99.81% 부합하는컴파일러는 존재합니다
intel C++ 컴파일러도 99.51%지키고 있습니다
VC++ 7.1또한 98%이상 지키고 있고요

gcc가 표준을 완벽히 지원하지 못하는건 순전히 GNU쪽에서
완벽히 지원하기에 여력이 없는것이지, 패러다임이 명확하지
못해서는 아니라고 봅니다 [하지만 버전이 올라갈수록 표준에 완벽히
가까워지고 있는데, 이것은 어떻게 설명이 될까요? 3.3은 96%이상 지키고 있습니다]

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

이건 비단 C++만의 표준 문제가 아닌걸로 보입니다

표준화에 대해 더 말씀 드리자면 posix 표준도 사실 , 완벽하지 않으며
오류또한 있는걸로 알고있습니다,따라서
posix 표준도 계속 발전하고 있습니다
C++도 마찬가지라 보이고요
C언어도 예전 표준 대신 , C99표준이 나온것 역시 기존의 표준에 부족한점이 많기때문에 나온게 아닌가 싶습니다

말씀하신 패러다임과 표준을 연결시키기에는 무리가 있는거 같네요

hangulee wrote:
다음으로.. 제가 C++로 제대로 된 프로젝트를 해보지는 않았지만 팀으로 구성을 해서 간단히 프로젝트를 해봤습니다. 인정하셨듯이 C++의 범위가 커서 그런지 각자가 같은 것을 구현해도 다른 방법을 사용하게 되기도 합니다. 이것은 팀프로젝트에 그다지 좋지 않은 영향을 줍니다. 결국 한명이 반 이상을 뜯어 고쳤습니다.

혼란을 가진것은 C++을 가지고 C++과 C스타일 둘다 씀으로써 발생한다고
볼수 있는데, 이건 언어의 문제가 아니라 사람의 문제라 다시 말씀 드릴수 있습니다 , C++로 그렇게 부정확하게 쓴다면 , C로 짜는게 나을지도 모릅니다
분명 C++에서 쓰는것과 C에서 쓰는것을 섞어 쓰면 곤란한경우가 있습니다
이럴때는 그부분을 완전히 C스타일로 가던가 C++스타일로 가야합니다
밑에 인용과 더블어 추가적으로 더 설명을 드리겠습니다

hangulee wrote:
아주 간단한 예로 C의 표준 함수중 malloc와 같은 메모리 할당함수를 C++에서 사용하게 되면 상당히 심각한 문제가 발생합니다. 그렇다고 사용하지 않을수도 없습니다. realloc가 필요할 때도 있으니까요. new로 메모리를 할당하고 realloc로 크기를 변경할수는 없지요. 그렇기때문에 둘을 섞어 쓰다보면 코드가 그다지 바람직하지 않은 방향으로 흘러가게 됩니다.

C코드와 C++코드가 100%는 물론 아니기때문에 이정도는 감수해야 할거로
보입니다 ,그리고 malloc를 사용해서 메모리를 사용했다면 거기에다가는
C표준 함수만 사용하면 됩니다, 예를들어 malloc으로 할당한것을 free하지 않고 delete를 한다면 이건 사용자 문제가 됩니다 , 굳이 꼭 C++에서
제대로 섞어 쓰기가 지원되지 않는다는것은 오해의 여지가 있습니다
윈도우 C API 에서 HANDLE를 만드는 함수를 호출하고 해제할때
CloseHandle로 닫지 않고 다른 함수를 호출해 해제한다고 한다면
그것역시 문제가 될것입니다 , 이건 사용자에 대한 책임 문제로 봐집니다

C++에서도 C함수를 섞어써도 문제는 없지만
C++연산자와 C함수를 비매칭해 써도 된다는건 아니죠
정확히 매칭되는것끼리 쓰면 문제가 안됩니다

엄연히 다른 함수를 연결해 사용했다고 볼수 있는데 , 문제가 될수 있는건
당연한거기도 하지요,이것은 C++를 전혀 모르는 사람이 C++연산자와
C함수를 비매칭한 경우이고

이건 C++에 대한 이해 부족에서 나오는 상황이므로 다시 말씀 드리진 않겠습니다 , 언어의 문제가 아니라 사람의 이해 부족에서 나오는거니까요
[realloc이 필요하다면 malloc만을 쓰면 되고 , C++ 방식으로 하자면 재할당하는 수밖에 없습니다,C++방식을 써서 해결하던 C방식으로 해결하던 이건 선택일뿐입니다,이것을 썪어 쓸라고 하니까 문제가 되는것이지요 ]

jj wrote:
C++에서 자부심을 느낄만한 특징은 템플릿이 전부라고 생각합니다. 나머지는 다소 다루기 힘든 ... 괴물같다고 할까요?

개인적으로 C에 템플릿만 추가된다면, 시스템 프로그래머는 더이상 바랄것이 없을것 같습니다.

자부심을 느낄만한것이 템플릿밖에 없다고 느끼셨다니 개인적으로 안타깝네요

그리고 주제와 다른 방향으로 흘러갔는데 , 기왕이면 다른 주제로 글을 올리는것이 좋지 않을까 싶습니다 , 주제를 보고 글을 보러 오는 분들에게 혼란을 줄거 같네요

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

berise의 이미지

hangulee wrote:

다음으로.. 제가 C++로 제대로 된 프로젝트를 해보지는 않았지만 팀으로 구성을 해서 간단히 프로젝트를 해봤습니다. 인정하셨듯이 C++의 범위가 커서 그런지 각자가 같은 것을 구현해도 다른 방법을 사용하게 되기도 합니다. 이것은 팀프로젝트에 그다지 좋지 않은 영향을 줍니다. 결국 한명이 반 이상을 뜯어 고쳤습니다. 물론 제대로 알지 못한 사람들이 시작해서 이런 문제가 일어났다고 할수도 있겠지만 자바나 C는 이렇게까지 문제가 커질만큼을 허용하지 않습니다.

제 생각입니다만, C++의 범위가 커서 프로젝트가 좋은 영향을 받지 못한 게 아닙니다. 다만 C++ 언어가 다양한 방법으로 표현될 수 있기 때문에 팀 원들이 서로 구현한 내용이 다를 수 있는 것입니다. 결과가 같다고 해서 중간 과정이 같다고 보는 것이 무리인 것과 같은 의미입니다.

프로젝트를 진행하는 것은 팀원간의 꾸준한 협의가 필요한 일입니다. 다양한 문제점에 대해 논의하고 의견을 맞춰가면서 진행하는 것입니다. 개개인의 코드가 결과물에 맞지 않는 다면 언어적인 문제로 볼 것이 아닌것 같습니다.

한명이 반 이상을 뜯어 고쳤다는 말은 다른 사람이 쓴 코드가 내부적으로든 외부적으로든 전체 프로젝트에 적합하지 않아서 고쳤다는 말로 들립니다. 이 말은 언어의 범위가 크다는 것과는 별개로 보입니다. 안 그렇습니까?

jj의 이미지

mastercho wrote:
...언어의 문제가 아니라 사람의 문제...
...이건 사용자 문제가 됩니다...
...이건 사용자에 대한 책임 문제로 봐집니다...

기본적인 입장에서 차이가 있네요. mastercho님은 사용자는 실수를 안한다는 가정을 하신듯 하구요, 반대의견은 그 가정자체에 문제가 있다는것이네요. 누가 맞다 틀리다 할 문제가 아닌것 같네요. 별도로 주제를 만든다 하더라도 의미없는 토론이 될것 같습니다. 아마 이정도까지만 봐도, 각자 알아서 판단을 할 수 있을것 같습니다.

다른 얘기는 이제 그만하지요. :)
토론 주제와 다른 얘기를 떠들어서 죄송합니다. :oops:

--
Life is short. damn short...

이한길의 이미지

글 읽고 있었는데 나누어졌네요.. 잠시 하고 싶은 말을 하겠습니다.

계속 언어문제가 아니라 사람 문제라고 말씀하시고 계십니다. 제가 확실히 드리는 말은 앞에서도 말씀드렸듯이 C나 자바는 이렇게까지 허용하지 않는다는 것입니다. 조금 다른 형태의 언어이긴 하지만 꽤 잘 설계되었다고 보여지는 ML에서도 가능할까요? 제가 생각할때는 거의 불가능입니다.

ML에서도 객체지향이 가능하며 특히 ML은 type이 미리 정의되지 않은 Generic type을 사용할 수 있기 때문에 템플릿같은 것도 굳이 필요하지 않습니다. 물론 언어를 비교한다는 것은 바른 행동은 아니지만 굳이 말씀드리자면 C++은 이에 비하면 비효율적으로 설계되었습니다. 다시한번 말씀드리건데 사람이 문제가 되기도 하지만 언어는 어느정도 그런 문제를 막아줄 수 있습니다.

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

그리고 제가 보기엔 이 토론 주제가 좀 잘못 된것 같습니다. C는 C++의 확장이 아니라는 것은 자명한 사실입니다. 하지만 그렇다고 완전히 불리된 다른것으로 생각하기에는 제공되고 있는 컴파일러들에 의하면 무리가 있습니다. 둘 사이는 조금 불편한 관계이지요.

----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.springnote.com
http://hangulee.egloos.com

이한길의 이미지

jj wrote:
mastercho님은 사용자는 실수를 안한다는 가정을 하신듯 하구요

jj님의 말씀이 옳다고 다시 말해서 mastercho님이 사용자는 실수를 안한다고 가정하시고 말씀하신다면 딱히 할말이 없군요. 그러나 실수를 안할 수는 없는 일이고 실수를 하지 않더라도 불필요하게 고려할 사항이 발생하는 것이 C++이라는 언어의 특징입니다.

ps. 저도 C++을 공부하는 입장입니다. 앞으로도 계속 공부할 생각입니다. 사실 저에게 프로그래밍이 무엇인지 알려준 형에게도 C++도 할것을 권할정도로 필요성은 인식합니다. 하지만 좀더 개선된 컴파일 가능한 객체지향 언어가 있었으면 하는 바램입니다.

----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.springnote.com
http://hangulee.egloos.com

이한길의 이미지

berise wrote:
한명이 반 이상을 뜯어 고쳤다는 말은 다른 사람이 쓴 코드가 내부적으로든 외부적으로든 전체 프로젝트에 적합하지 않아서 고쳤다는 말로 들립니다. 이 말은 언어의 범위가 크다는 것과는 별개로 보입니다. 안 그렇습니까?

어느정도 말씀도 맞습니다만 처음 시작할때 서로간의 인터페이스까지 모두 정의를 하고 시작했습니다. 하지만 불행하게도.. 그리고 사실 반이라는건 조금 과장된 표현이긴 합니다만... 단순한 작업이 아니었기에...

물론 서로 자주 이야기를 하고 작업을 한쪽에서는 그런 문제가 특별히 발생하지는 않았습니다.

언어의 범위가 크다는 것도 문제가 됩니다. 구현의 방법에 있어서 의외로 차이가 나게 되기도 하기 때문입니다.

----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.springnote.com
http://hangulee.egloos.com

nightfog의 이미지

논쟁의 주제가 몬지는 잘 모르겠지만서두요..

본 토론이 분리되어 주제가 C++이 C의 확장이냐 논의는 별로 할 필요가 없을것 같습니다.

결론적으로 말해서 C++은 C의 확장이기 때문입니다.

어차피 C++ 언어를 만든사람 ( Stroustrap )의 책내용에서 Historical Note에 보면 C++은 C with Class로 처음에 불려졌으며 추후 C++로 부르게 된이유가 C에서 기능을 더한 + 결국 C+로 부르려다가 C+라는게 C에서 syntax error이기때문에 C++로 하였고...

D가 아닌 C++로 부른 이유는 C의 확장이기때문이다.. 라고 나왔있습니다..

추후 계속 읽어보면 결국 C++의 기본 언어로 C를 택한 이유도 나와있습니다..

그러니 결국 C++이 C의 확장이니 아니니의 논란은 할 필요가 없을것 같습니다.

만약 확장이 아니라면 C++만든사람이 상당히 우울할듯 보입니다. ^^;

즐겁게 삽시다~

Vadis의 이미지

역시 토론에서 얻는 것은 단순한 결론보다 새로운 대안으로 발전해 나가기 위함이 아닐까 싶네요.
저의 결론: c와 c++의 특성이 머리 뼈속까지 스며드네요.이상

좋은 날 즐거운 날....

buelgsk8er의 이미지

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

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

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

hangulee님께서 말씀하시는 C++을 대체할만한 네이티브 컴파일러를 지닌 언어..가 등장하려면 최우선적으로 그 부분을 극복해야만 할 겁니다.

chunsj의 이미지

유지보수의 측면에서는 C++는 C보다 못할 때가 많습니다. 특히 Class를
이용한 캡슐화의 부분에서인데...

1. Base Class의 Instance Variable이 바뀌면 전부 컴파일을 해야한다.
때문에 원 베이스의 소스가 항상 필요합니다. 처음에 설계를 잘 하면
이런 경우가 없다라고 주로 반박을 하는데 실제로 그런일은 없습니다. 관련
논문들은 보시면 FBC Problem에 대해서는 대체로 동의하고 있습니다.

2. Base Class에 새로운 Method를 추가하면 전부 새로 컴파일을 해야
한다. 역시 1과 마찬가지의 문제가 있죠.

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

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

mastercho wrote:
이성을 가지고 이제 차근 차근 위에 대한 생각에 대한 반박글을 남기도록 하겠습니다

정말 답답하게 느낀 대목이 바로 유지보수에 관한 내용입니다
객체지향이 왜 나왔는지 충분히 아시리라 믿습니다, 바로 유지보수및
코드[꼭 코드가 아니더라도]의 재활용이라는것에 큰 의미가 있습니다

C++에서는 클래스를 이용해 캡슐화를 하고 이로부터 유지보수의 엄청난 장점을 얻습니다
또한 클래스내부에서 private를 이용하여 유지보수를 위한 리펙토링이 손쉽게 할수 있는 장

점도 있습니다, 또한 class를 유틸리티나 라이브리러로 컴포턴트화 하면 , 다음 프로젝트때

도 쉽게 써먹을수도 있죠
굳이 객체지향을 들먹이지 않아도 충분히 이해하셨으리라 봅니다
말씀하신 유지 보수 불가같은것은 C++을 이용해서 엉터리로 프로그래밍하는 경우에나 나오

는것인데, 그것은 언어의 문제가 아니라 사람의 문제라고 보여지고 , C++이 아니라 어떤 언

어를 쓰더라도 부족한 능력의 사람이 쓰면 유지 보수는 불가합니다

chunsj의 이미지

4r7yc0d3 wrote:
C 이외에 C++만큼 기존의 방대한 C API들을 잘 지원하는 언어는 없잖습니까?

C++ 보다는 Objective-C가 더 잘 지원합니다. 전혀 차이가 없죠. C에다가
Smalltalk 방식의 객체 방식을 추가했을 뿐이니까...

죠커의 이미지

mastercho wrote:
[제눈에는 문자열 상수를 int형 썼다면 오히려 더 안좋은 프로그래밍처럼보이네요, 차라리 수정하는것만 못할거 같습니다, ]

C언어는 보다 지원이 좋지 못한 환경에서도 널리 쓰입니다. C언어의 표준은 그런 좋지 못한 환경을 감안해서 만들어집니다.

mastercho wrote:

당연히 C++에서 사용하는 방식이나 의미가 C로가는 방향으로는 성립하지
않습니다 ,
그말이 C++이 C와 호환성이 있다는거지 C가 C++과 호환성이 있다는 말은
전혀 아니었습니다, 저도 전에 글에도 말씀드렸던걸로 기억되네요

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

mastercho wrote:

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

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

mastercho wrote:

그리고 이미 표준에 99.81% 부합하는컴파일러는 존재합니다
intel C++ 컴파일러도 99.51%지키고 있습니다
VC++ 7.1또한 98%이상 지키고 있고요

출처가 어떻게 되는 지 궁금합니다. 제가 아는 VC++ 7.1에서 안되는 것들은 적어도 아래의 것들이 있습니다. 98% 이상이란 것에 선뜻 동의하기 힘들군요.

Quote:
* Exception Specifications
* Dependent Names
* The export keyword
* Syntax checking
* Some Unicode support
* TC1 Issues

mastercho wrote:

게다가 VC++ 6.0이 표준을 지키지 못한건 VC++상업성을 이용한 비표준 방향으로 컴파일러를 만들었기때문기때문이고 , 표준 자체가 워낙 방대해서
완전히 만족시키기 어렵기 때문이기도 합니다,

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

mastercho wrote:

[언어가 방대해지면 컴파일러 만들기는 원래 어렵습니다,표준과 패러다임과의
관계를 잘못 연결시킨게 아닌가 싶네요, 자바에 GJ가 제안한 표준을 추가한다면
자바 역시 문법을 지키기위해 컴파일러가 좀더 복잡해 질것입니다,]

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

mastercho wrote:

표준화에 대해 더 말씀 드리자면 posix 표준도 사실 , 완벽하지 않으며
오류또한 있는걸로 알고있습니다,따라서
posix 표준도 계속 발전하고 있습니다
C++도 마찬가지라 보이고요
C언어도 예전 표준 대신 , C99표준이 나온것 역시 기존의 표준에 부족한점이 많기때문에 나온게 아닌가 싶습니다

말씀하신 패러다임과 표준을 연결시키기에는 무리가 있는거 같네요

표준의 불 완정성에 대해서는 동의 합니다. 하지만 많은 c++의 패러다임은 ad hoc인 부분이 있습니다. c++은 강력하지만 잘 사용해야 하는 언어이죠..

죠커의 이미지

chunsj wrote:
4r7yc0d3 wrote:
C 이외에 C++만큼 기존의 방대한 C API들을 잘 지원하는 언어는 없잖습니까?

C++ 보다는 Objective-C가 더 잘 지원합니다. 전혀 차이가 없죠. C에다가
Smalltalk 방식의 객체 방식을 추가했을 뿐이니까...

좋은 지적입니다. Objective-C는 C언어의 완벽한 Superset입니다. C의 의미구조를 동일하게 사용하면서 객체등의 추가된 개념에 대해서는 다른 방법으로 접근하니깐요. 다른 패러다임을 섞을대는 Objective-C나 GJ같이 섞어야 한다고 봅니다.

하지만 컴퓨터에 한가지 언어만 깔수 있다면 Objective-C보다는 C++을 선택하겠습니다. :-)

corba의 이미지

저는 템플릿 밖에 라기 보다... 템플릿 씩이나... 라고 생각을 하고 있습니다. :)

사실 저도 C++을 잘하지는 못하지만 요즘 계속 파이썬 코드를 C++로 포팅하면서 의외의 심플함에 놀랐습니다.

아시다시피 파이썬의 편리함은 이루 말 할 수 없습니다. 그래서 처음 작업을 맡았을 때는 무척 두려웠습니다만... 이럴 때 STL이 정말 힘을 주더군요. 결과적으로 실제 코드량이 파이썬과 크게 차이가 나지 않았습니다.

그리고 항상 뜨거운 감자인 다중상속... 이게 템플릿을 쓰니 필요해지더군요. Morden C++ Design에 사용 예가 나오더군요.

템플릿 메타프로그래밍이나 다양한 주제들이 아직 C++은 더 공부해볼만한 가치가 있는 언어라는 희망을 주고 있습니다. 심지어 boost에 labda까지 구현한 분이 계시더군요.(정말 놀랐습니다 :shock: )

C++이 위험요소를 내포하고 있다기 보단 너무 많은 것들을 허용해 줘서 프로그래머가 위험요소를 내포하게 만드는 것이 아닌가 싶습니다. 필요 이상의 포인터 남발만 자제하면 위험요소나 메모리 누수 같은 문제들도 크게 걱정은 없을 것 같습니다. 전 오히려 가베지컬렉션 기능이 좀 찝찝하더군요. :D

주제에 벗어난 글 올린점 죄송하게 생각합니다만 저 역시 C++을 좋아하는 한 사람으로서 올린 글이니 너그러이 용서해 주십시오. :wink:

vacancy의 이미지

C++이 늘 좋은 언어냐 나쁜 언어냐하는 얘기가 나오는 데,
결국은 사용자의 절제-_-를 믿느냐 마느냐에 달린 것 같네요.

그런데 좀 상황을 보면
프로젝트들이 작을때는 사실 별 문제가 없지만,
방대해지면 방대해질수록 사람은 믿기 어렵다는게
기정 사실이 되어가고 있지 않나요 ?

자바나 C#같은 언어가 굳이 대두되고 있는 건
( 자바는 뭐 어디서나 실행하자, 라는 게 목적이었을진 몰라도 )
결국 사람을 믿기 어렵다는 부분이 많지 않은가 싶습니다.
컴퓨터가 많은 것을 자동화해주면 해줄수록 문제가 적어진다는 전제 하에
가베지 콜렉션도 하는 것이고,
OOP 형태도 다중 상속을 절제하는 형태로 바꾼 것이고요.
사람이 완벽히 해낸다면 왜 이런 쪽으로 흘러갈지요 ? -_-a

사실 코딩하는 입장에서 편한게
productivity의 향상으로 이어질 수 있다는 걸 감안하면,
자바나 C#같은 차세대 언어들이 점차 상승세를 타잖을까 생각합니다.

C++가 C의 Subset이고 아니고는 별로 중요하지 않은것 같네요.
어차피 걷는 길이 완전히 다른 언어니까요.

그나저나 무슨 언어가 좋다 나쁘다 가지고
감정 운운하며 얘기하는 분위기는 별로 좋지 않은것 같습니다.
커뮤니티 사람들과의 관계가 언어의 장단보다 더 중요하지 않은가요 -_-a

corba의 이미지

chunsj wrote:
유지보수의 측면에서는 C++는 C보다 못할 때가 많습니다. 특히 Class를
이용한 캡슐화의 부분에서인데...

1. Base Class의 Instance Variable이 바뀌면 전부 컴파일을 해야한다.
때문에 원 베이스의 소스가 항상 필요합니다. 처음에 설계를 잘 하면
이런 경우가 없다라고 주로 반박을 하는데 실제로 그런일은 없습니다. 관련
논문들은 보시면 FBC Problem에 대해서는 대체로 동의하고 있습니다.

2. Base Class에 새로운 Method를 추가하면 전부 새로 컴파일을 해야
한다. 역시 1과 마찬가지의 문제가 있죠.

말씀하신 대로 이런 문제가 있습니다. 현업 개발에서도 꽤나 걸림돌이죠. 대규모 프로젝트의 경우 당장 컴파일 타임의 증가만 해도 짜증날 정도지요.

하지만 약간의 노력과 생각으로 이 문제를 최소화 할 수는 있지 않을까 싶네요.

1. 상속의 경우 C++에서 friend 다음으로 결합도가 높습니다. 아예 안 쓸수는 없지만 최대한 상속의 사용을 줄아는 것이 좋다고 봅니다. 가상함수를 이용한 추상화의 경우를 제외하곤 가급적 Composition을 쓰는 것이 좋다는 얘기도 있습니다.

2. Composition의 경우 역시 의존도 문제가 발생합니다. 멤버에 수정이 가해지는 경우겠지요. 이런 경우도 Hubb Sutter의 Compiler Firewall Idiom으로 최소화 할 수 있습니다. 덤으로 private멤버를 아예 헤더에서 없앨 수도 있어 마음에 듭니다.

결국 100% 없앨 수는 없지만 최대한 줄일 수는 있다고 봅니다. 역시 C++에는 많은 자유가 있다고 해야 할까요. :D

mastercho의 이미지

CN wrote:
mastercho 씀:

그리고 이미 표준에 99.81% 부합하는컴파일러는 존재합니다
intel C++ 컴파일러도 99.51%지키고 있습니다
VC++ 7.1또한 98%이상 지키고 있고요

출처가 어떻게 되는 지 궁금합니다. 제가 아는 VC++ 7.1에서 안되는 것들은 적어도 아래의 것들이 있습니다. 98% 이상이란 것에 선뜻 동의하기 힘들군요.

자세한것들은 이제 서서히 다른분들이 답변을 해주고 있는 상태이므로
굳이 더 이상 글을 길게 쓰지 않고 , 자료만 일단 드리도록 하겠습니다

[위에 CN님이 말씀하신 문법상의 약간의 차이는 충분히 감안할수 있는 내용으로 보여지네요,C++로 오면서 더 견고해지거나 명확해지는 면이라 생각합니다,특히 const 같은 경우에는 더욱요]

참고로 99.81%라고 한게 있는데 실수 인거 같습니다 99.70%네요

이건 데브피아 노영선님이 올리신 자료입니다

Quote:
DDJ (Dr. Dobb's Jounal 11월호에 테스트 결과가 나왔더군요.

http://anubis.dkuug.dk/jtc1/sc22/wg21/

여기에 나오는 표준 관련 문제점들 위주로 411개의 테스트 케이스를 만들어서 테스트했답니다.

(위 사이트는 무지 느려서 거의 접속이 안 됩니다.)

결과..

edg 3.2 99.70%

Comeau 4.2 99.55%

Intel 7.1 99.55%

PGCC 4.1-2 99.11%

VC++ 7.1 98.22%

gcc 3.3 96.14%

Borland 6.0 92.73%

Watcom 1.0 78.49%

작년 6월에 테스트한 걸 보면, VC 6.0은 83.43% 네요. gcc 2.95.2는 92.60%

최소한 gcc 3.3 은 돼야 템플릿을 맘 놓고 쓸 수 있을듯합니다.

Quote:
그나저나 무슨 언어가 좋다 나쁘다 가지고
감정 운운하며 얘기하는 분위기는 별로 좋지 않은것 같습니다.
커뮤니티 사람들과의 관계가 언어의 장단보다 더 중요하지 않은가요 -_-a

인정합니다만은... "언어가 좋다 나쁘다"로 싸운다는 식으로
글을 보신것은 , 잘못 보신걸로 압니다

그리고 ,정확하지도 않고 ,
잘못된 판단으로 여기지는 부분으로 자기가 좋아하고 연구하는 언어를
폄하할때는 , 이런 문제가 충분히 발생할수 있지 않나 싶네요

제가 만약 C언어의 단점이 아닌것을 가지고 단점으로 치부하며
포인터를 쓰는 C는 유지보수도 불가능하고, 구조적 절차로 프로그래밍하는
안좋은 언어라고 글을 쓴다면 어떨까요?


리눅스를 연구하는 사람에게 리눅스의 문제가 아닌 문제로 걸고 넘어지며,
윈도우보다 후져..... 이랬다면 결과가 어떻게 나오냐는것이지요
문제는 거기에 있었다고 봅니다
그렇게 입장을 바꿔 생각하면 좋을듯 싶네요

Quote:
사람이 호랑이를 죽이려고 할 때에는 이를 스포츠라고 한다. 호랑이가 사람을 죽이려고 할 때에는 이를 흉악한 사고라고 한다. < B. 쇼 >

그리고 말씀하신 시선으로 이 토론을 굳이 바랄볼필요는 없을듯 싶은데요?
이미 그런 수준에서 오고가는 토론이 아닌듯 싶습니다,

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

이한길의 이미지

Quote:
제는 가끔 개인적으로 C++을 대체할 만한 바이너리 코드 생성이 가능한 객체 지향 언어가 필요하다는 생각입니다. 사실 C++을 접한지 그렇게 오래되지도 않았고 제대로 된 프로그래밍을 해보지도 않았지만 C++은 위험적인 요소나 불필요한 요소를 많이 포함하고 있다고 생각됩니다. 제가 말하는 위험적인 요소는 프로그램 설계를 할때 후에 유지 보수면을 함께 고려하는 것이 쉽지 않고 한번 결정한 것으로 인해 유지보수를 할 수 없어 페기할수밖에 없는 최악의 상황이 나오지 않을까 하는 염려입니다.

위는 문제가 발생한 제 글을 인용한 것입니다. 하지만 저는 C++이 단순히 나쁘다고 하기 위함이 아니었습니다. 제 생각에는 개선할 필요가 있다는 것이었지요. 제가 좀 말을 심하게 했는지도 모르겠습니다. 대체라는 단어를 썼기 때문입니다.

mastercho님은 저와 언어를 바라보는 시각이 다르기 대문에 문제가 발생한것 같습니다. 저는 어느 언어를 좋아하거나 좋아하지 않기는 해도 그 언어에 대한 자부심과 매달리는 것은 없습니다. 언어는 단지 도구이기 때문이지요. 어느사람이 하나의 망치로 못질을 하기 좋다고 해서 그 망치를 좋아한다고 해서 그 망치가 없어진다고 못질을 못하지 않듯이 해당 언어가 없어진다고 해서 프로그래밍을 못하지도 않습니다. 저는 개인적으로 C와 JAVA를 좋아합니다. 특히 JAVA를 좋아하는데 단점을 지적해주신다면 인정할 수 있습니다. 그리고 OS는 리눅스를 좋아하는데 단점이 있는것은 사실입니다. 이런 단점을 개선한다는 것은 좋은 일이라고 생각합니다.

----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.springnote.com
http://hangulee.egloos.com

mastercho의 이미지

hangulee wrote:
mastercho님은 저와 언어를 바라보는 시각이 다르기 대문에 문제가 발생한것 같습니다. 저는 어느 언어를 좋아하거나 좋아하지 않기는 해도 그 언어에 대한 자부심과 매달리는 것은 없습니다. 언어는 단지 도구이기 때문이지요. 어느사람이 하나의 망치로 못질을 하기 좋다고 해서 그 망치를 좋아한다고 해서 그 망치가 없어진다고 못질을 못하지 않듯이 해당 언어가 없어진다고 해서 프로그래밍을 못하지도 않습니다. 저는 개인적으로 C와 JAVA를 좋아합니다. 특히 JAVA를 좋아하는데 단점을 지적해주신다면 인정할 수 있습니다. 그리고 OS는 리눅스를 좋아하는데 단점이 있는것은 사실입니다. 이런 단점을 개선한다는 것은 좋은 일이라고 생각합니다.

저도 hangulee님에게 개인적인 감정은 없습니다
다만 제가 , 문제가 아니다고 느낀것을 문제 삼아 말씀하시기에 저도 모르게
발끈 한거 같네요,
사실 은근슬쩍 hangulee님 처럼 평소에 이렇게 생각하는 분들이
생각보다 많았고 , 그거에 대해 저도 모르게 불만이 잠재해 있었던거 같습니다
감정이 상하지 않으셨으면 좋겠습니다 :(

Quote:
그리고 OS는 리눅스를 좋아하는데 단점이 있는것은 사실입니다. 이런 단점을 개선한다는 것은 좋은 일이라고 생각합니다.

물론 명백한 단점이라면 고쳐져야 되겠지만, 단점이 아니라.... 오히려
장점이 될수 있수도 있다는것에 대해서도 생각을 해봐야 할거 같습니다

윈도우에서 리눅스보다 GUI가 쉽게 된다고 윈도우가 무조건 더 좋은게 아니듯이요

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

asheap의 이미지

일단 현재 C++의 주요한 사용처를 대체하는 언어는 등장하지 않고 있다는 전제에 동의를 요구하는 데서 시작하겠습니다. 왜냐하면 최적화된 성능이 필요한 초대형 상업용 소프트웨어(최신 윈도우 운영체제나 오피스 소프트웨어-오픈 오피스까지도, 그리고 대부분의 게임소프트웨어들 이곳을 참조하세요: http://www.research.att.com/~bs/applications.html ) 는 현재까지 거의 대부분이 C++을 사용해서 제작되고 있기 때문입니다. 물론 apache bind gimp등등 c만을 사용해서 작성되는 소프트웨어들이 있지만, 상용이 아니라는 점에서 빼겠습니다. 프로그래머가 스스로 작성한 소프트웨어를 판매 그자체로 먹고 살 수 있는 소프트웨어만을 대상으로 하겠습니다.
C++ 자체의 효용성과 성능은 초대형 상업용 소프트웨어가 당연한 듯이 C++로 만들어지고 있는 상황을 보면 어느정도는 확신을 가져도 된다고 생각합니다. 문제는 언어 자체가 프로그래머가 정말 공들여 작성해야 쓸만한 코드가 나오고, 언어자체에 대한 제대로된 학습이 부족한 상황에서 작성한 코드는 정말 유지보수가 불가능해지는 경우가 많다는 점인 것 같습니다.(물론 다른 대부분의 언어도 비슷하기는 합니다. 하지만 유독 C++만 이 문제점이 자주 그리고 맹렬하게 지적되더군요.) 이 문제점으로 인하여 C++의 단점만을 잡고 보면 정말 엄청나게 후진 언어로 보이지만, 현재 상황에서 정말 그 프로그램 가지고 제대로 먹고 살 수 있는 소프트웨어를 만드는 데는 C++을 쓸 수 밖에 없는 상황입니다. (애플사등 몇몇 소수의 플래폼에서 운용되는 전용 소프트웨어에 관해서는 일단 빼고 생각하겠습니다.)
결국 C++이 정말 좋지 않다고 생각하는 사람들이 뜻을 함께모아서 C++을 사용하지 않고도 초대형 상업 소프트웨어 작성 및 유지보수가 가능하다는 것을 보여준다면 이후 새로운 언어가 C++의 자리를 대체할 가능성이 생기리라고 봅니다. 그런 일이 생기려면 일단 ms가 확실히 C++ 대신 다른 언어를 사용하여 윈도 운영체제를 작성한다면 좋을 것 같습니다.
프로그래머 사회에서 C++이 많이 사용되는 만큼 C++에 관한 비판이 매우 자주 올라오고 그것에대해서 C++ 매니아들이 노이로제가 걸려있는 만큼 이 이야기만 나오면 분위기가 험악해지는 것 같습니다. C++을 비판은 좋지만, C++ 매니아들의 기분을 상하게 할 수 있는 단점만을 들쑤시는 글들은 좋지 않은 것 같습니다.
C++을 사용하시고, 또 C++에대한 생각과 느낌을 적고 싶으신 분들은 최소한 다음의 홈페이지에 나오는 수많은 글과 인터뷰을 보시고 혹시 자신이 생각하던 단점에 대해 직접 C++창시자에게 질문한 글이 있는지 확인해 보십시오. 저같은 경우도 약 2년간을 C++을 조금만 안채로 C++을 비난하고 거부하면서 보냈지만, 지금은 열렬한 C++매니아입니다. 스트라웁씨의 홈페이지에서 저는 많은 것을 새로 알고 생각을 바꿀 수 있었습니다.
http://www.research.att.com/~bs/homepage.html
이곳에서 언급되지 않은 내용은 C++에 관한 수많은 명서들에서 해답과 이유를 얻을 수 있었습니다만 그 내용은 여기에 연결할 수 없으니 포기하겠습니다.
물론 C++을 정말 많이 아시고, 또한 그것을 제대로 사용한 소프트웨어를 작성하신 다음 비판하시는 분들에 대해서는 그 비판을 잘 읽고 받아들일 수 밖에 없을 것 같습니다.
제대한 환경에서 시간에 쫓기며 글을 써서 한번 읽어보고 정리도 못한 채로 올리게 되어 글이 왔다갔다일 것 같은 데 좀 이해해 주시기 바랍니다.

fender의 이미지

asheap wrote:
현재 상황에서 정말 그 프로그램 가지고 제대로 먹고 살 수 있는 소프트웨어를 만드는 데는 C++을 쓸 수 밖에 없는 상황입니다
.......
C++ 자체의 효용성과 성능은 초대형 상업용 소프트웨어가 당연한 듯이 C++로 만들어지고 있는 상황을 보면 어느정도는 확신을 가져도 된다고 생각합니다.

이 부분은 좀 논란의 여지가 있다고 봅니다. 소프트웨어 시장이 꼭 최종 사용자를 대상으로 하는 데스크탑 어플리케이션으로만 구성된다는 전제는 잘못 된 것입니다.

커널이나 시스템 관련, 리얼타임이나 임베디드 어플리케이션, 혹은 대규모 분산환경 어플리케이션 등등의 분야마다 주로 사용되는 언어가 다릅니다. 또한 프로젝트 마다 차이도 무시할 수 없습니다.

항상 언어 논란이 있으면 나오는 말이지만 정답은 'right tool for the right job'이 아닐까 싶습니다.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

죠커의 이미지

mastercho wrote:
[위에 CN님이 말씀하신 문법상의 약간의 차이는 충분히 감안할수 있는 내용으로 보여지네요,C++로 오면서 더 견고해지거나 명확해지는 면이라 생각합니다,특히 const 같은 경우에는 더욱요]

const같은 경우는 c가 c++에서 키워드를 받아들였는데 의미는 다릅니다. 의미가 견고해진다는 것보다는 선택의 문제라고 생각합니다. struct같은 경우도 c언어에서는 tag를 정의하는 것이니 같은 형을 만드는데 typdef가 필요하지만 c++에는 명칭 자체를 선언합니다. 그것도 선택의 문제겠지요. c위원회는 의식적으로 c가 c++다워지는 것과 c가 무거워 지는 것을 경계한다고 알고 있습니다. 선택의 문제겠지요.

제가 알고 있는 VC++ 7.1이 지원못하는 문제들을 가진채 99.70%라는게 특이하군요. 언제 DDJ를 살펴봐야겠습니다. 흥미로운 과제를 던져주셔서 감사하군요.

pynoos의 이미지

저는 두 언어를 모두 좋아하기 때문에, 쓰레드를 흥미롭게(?) 지켜보고 있습니다만, C와 C++의 관계에 대해서는 이거다 저거다 말을 못할 것 같습니다.

저는 Unix/Linux 에서 5년정도 C/C++로 서버 프로그래밍을 한 경험이 있습니다.

경험을 비추어 두 언어를 비교해보면, C++ 를 깊게 이해할수록 객체의 생성/삭제/소유권 등의 문제등에 자연스러운 이해가 됩니다.
C++을 C로 구현해야하는 귀찮은 일들을 일소하는 도구로 사용할때가 있는데,

- 생성/소멸자의 존재가 C에서는 struct안의 struct들을 해제할 경우 삽질을 해야하는 경우에 대해 간편한 도구로 사용됩니다.

- Virtual Function Table 이라는 개념으로 구현된 virtual member function 들은 C 에서 함수 포인터 구조체를 통해 구현되는 Interface 제작에 상당한 노력을 절감하여 줍니다.

- 상당수 stl을 사용하여 제작하게 되는 set, vector등은 list 제작에 신경쓰지 않아도 됩니다. 생각이 자유로워진다고나 해야할까요?

C 로 개발할 경우가 있는데, 이 때는 주로 method 들이 위주가 되어 있는 간단한 utility 들을 만들때 입니다.

- class 를 일단 쓰기 시작하면 섬세한 작업과 귀찮은 libstdc++ linking 문제에 신경쓰이지 않아서 좋습니다.

- 가볍다는 생각에 기분이 좋죠. 게다가 nm 으로 출력되는 심볼들의 간결함이 늘 기분좋습니다.

C++의 강력한 타입체크 기능에 익숙하게 되면, C의 코드가 더 풍부해지는 것을 경험합니다.

두 언어는 어느 것이 다른 한쪽의 subset은 아니고 상당히 많은 교집합 대부분의 C 기능이 C++에 들어가는 형태로 생각되는 것이 옳다고 생각됩니다.
C++은 상당수 C의 노가다를 줄여주는 일로 사용되는 것이 제가 둘을 섞어 쓰는 이유인 듯하군요.

chunsj의 이미지

자유라기 보다는 C++의 문제를 돌아가는 방법이겠죠 :-) 상속을 쓰는 것을
피해야 한다면, 그건 깊은 상속을 마구 사용하는 것 만큼이나 위험합니다.
물론 깊은 상속을 해도 되는 랭귀지들이 있기는 하지만 적어도 C++은
아닙니다. 차라리 언어가 개선이 되는게 나은 방향이 아닐까요?(물론
가능한지는 모르겠습니다 :-)

corba wrote:
chunsj wrote:
유지보수의 측면에서는 C++는 C보다 못할 때가 많습니다. 특히 Class를
이용한 캡슐화의 부분에서인데...

1. Base Class의 Instance Variable이 바뀌면 전부 컴파일을 해야한다.
때문에 원 베이스의 소스가 항상 필요합니다. 처음에 설계를 잘 하면
이런 경우가 없다라고 주로 반박을 하는데 실제로 그런일은 없습니다. 관련
논문들은 보시면 FBC Problem에 대해서는 대체로 동의하고 있습니다.

2. Base Class에 새로운 Method를 추가하면 전부 새로 컴파일을 해야
한다. 역시 1과 마찬가지의 문제가 있죠.

말씀하신 대로 이런 문제가 있습니다. 현업 개발에서도 꽤나 걸림돌이죠. 대규모 프로젝트의 경우 당장 컴파일 타임의 증가만 해도 짜증날 정도지요.

하지만 약간의 노력과 생각으로 이 문제를 최소화 할 수는 있지 않을까 싶네요.

1. 상속의 경우 C++에서 friend 다음으로 결합도가 높습니다. 아예 안 쓸수는 없지만 최대한 상속의 사용을 줄아는 것이 좋다고 봅니다. 가상함수를 이용한 추상화의 경우를 제외하곤 가급적 Composition을 쓰는 것이 좋다는 얘기도 있습니다.

2. Composition의 경우 역시 의존도 문제가 발생합니다. 멤버에 수정이 가해지는 경우겠지요. 이런 경우도 Hubb Sutter의 Compiler Firewall Idiom으로 최소화 할 수 있습니다. 덤으로 private멤버를 아예 헤더에서 없앨 수도 있어 마음에 듭니다.

결국 100% 없앨 수는 없지만 최대한 줄일 수는 있다고 봅니다. 역시 C++에는 많은 자유가 있다고 해야 할까요. :D

clhitter의 이미지

chunsj wrote:
유지보수의 측면에서는 C++는 C보다 못할 때가 많습니다. 특히 Class를
이용한 캡슐화의 부분에서인데...

1. Base Class의 Instance Variable이 바뀌면 전부 컴파일을 해야한다.
때문에 원 베이스의 소스가 항상 필요합니다. 처음에 설계를 잘 하면
이런 경우가 없다라고 주로 반박을 하는데 실제로 그런일은 없습니다. 관련
논문들은 보시면 FBC Problem에 대해서는 대체로 동의하고 있습니다.

2. Base Class에 새로운 Method를 추가하면 전부 새로 컴파일을 해야
한다. 역시 1과 마찬가지의 문제가 있죠.

본 주제하고는 약간 벗어난 질문성 글을 올려서 죄송합니다만.

다른 언어 (ex. Java, Smalltalk, Object C) 등에서는 위와 같은 상황에서 어떤 식으로 처리가 되는지 궁금합니다.

예를 들어 Java의 경우 어떤 class의 member가 바뀌거나 새로운 method가 추가되는 경우 그 class를 reference하는 java 파일들은 재컴파일 필요 없는 건가요?
만약 그렇다면 method가 추가되는 경우는 납득이 가지만 method가 삭제되는 경우는 문제가 발생할 수도 있을 것 같아서요.
일단 javac가 method가 추가되는 경우와 삭제되는 경우를 나누어서 다른 처리를 할만큼 똑똑할 수 있을것 같지도 않고, 따라서 삭제되는 경우도 해당 java 파일만 재컴파일 될텐데 그러면 runtime에서 에러가 발생하겠죠?
그럼 method를 삭제하는 경우는 사용자가 알아서 make clean, make 하는 식의 작업을 한다음 거기서 나오는 에러들을 수정해야 한다는 이야기인데, 그럼 오히려 c++의 경우보다 상황이 더 악화되는게 아닌가 해서요.
첫째, 개발자가 어떤 class의 interface를 수정했을 때 이 class를 reference하는 java 파일들에 대해서도 재컴파일을 해야 하는 수정인지를 판단해야 할테고.
둘째, c++의 경우 그 class를 reference하는 파일들만 재컴파일하는게 아니라 개발자가 적당히 선택한 불특정 다수의 java 파일에 대해 재컴파일을 해야 할테니까요.

저도 주로 c++로 개발을 하는 사람인데, 항상 지적하신 2가지 문제때문에 많은 파일들을 재컴파일 할 때마다 더 좋은 방법은 없을까 많이 고민을 했었습니다 ^^
그래서 다른 언어에서는 이 문제들을 어떻게 처리하는지 더 궁금해지는군요.

이한길의 이미지

제가 논란을 일으킨만큼 토론에서 말을 마치기 전에 글을 남기려 합니다.

nightfog wrote:
결론적으로 말해서 C++은 C의 확장이기 때문입니다.

어차피 C++ 언어를 만든사람 ( Stroustrap )의 책내용에서 Historical Note에 보면 C++은 C with Class로 처음에 불려졌으며 추후 C++로 부르게 된이유가 C에서 기능을 더한 + 결국 C+로 부르려다가 C+라는게 C에서 syntax error이기때문에 C++로 하였고...

D가 아닌 C++로 부른 이유는 C의 확장이기때문이다.. 라고 나왔있습니다..

위와같은 말씀도 있었는데... 저는 그런 책까지 읽어보진 않았기 때문에 뭐라 말씀드리기는 어렵습니다만... 지금 와서 봤을때 확장에서 나왔으나 별개가 되었다고 저는 생각하고 있습니다.

mastercho wrote:
다만 제가 , 문제가 아니다고 느낀것을 문제 삼아 말씀하시기에 저도 모르게
발끈 한거 같네요,

앞으로 조심하겠습니다. 이렇게까지 C++을 좋아하시는 분이 계시다는 사실에 놀라웠고 또 많은점을 생각해보게 되었습니다.

한가지 생각나는 것이 있습니다. 예전에 한 사이트의 포럼에 D언어에 대한 주제를 올렸습니다. 이야기 하다가 왜 D언어가 널리 사용되지 않는 것인지에 대한 이야기가 나왔는데 결론은 'C++로 충분하기 때문이다.' 였습니다. 굳이 C++에서 D언어로 갈 이유가 없다는 것이지요.

"pynoos"님 말씀대로 각각 사용될 곳이 따로 있는것 같네요. 그리고 이처럼 약간은 소모적인 토론이 발생하도록 한것에 대해서 미얀한 생각이 듭니다. 앞으로 특정 랭귀지에 대한 개인적 견해 피력에는 조심을 해얄것 같네요.

----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.springnote.com
http://hangulee.egloos.com

chunsj의 이미지

Java의 경우는 Instance Variable이 추가 되거나 바뀐다고 재 컴파일을
할 필요는 없는 것으로 알고 있습니다(확실한지는 잘 모르겠네요...) 그리고
Smalltalk은 당연히 관계가 없고, Objective-C는 같은 문제가 있습니다만
posing을 이용해서 해결을 할 수 있습니다. 이것은 Subclass가 Superclass
를 대신해서 그 역할을 할 수 있도록 하는 것입니다. 또다른 방법으로는
Class Cluster를 이용하는 방법인데 이건 퍼블릭한 추상 클래스를 쓰고
Concrete Subclass를 그 추상 클래스가 사용하게 하는 방법입니다.
이 모든 경우에 대해서 재컴파일은 당연히 필요 없습니다. 실제로는
위헤서 말한 그냥 클래스의 Instance Var을 바꾸는 경우에도 변경 이전에
비해서 크기가 작으면 상관이 없습니다. (Objective-C는 C의 슈퍼셋일
뿐입니다.) 처음의 방법을 빼고는 원래의 클래스의 소스가 필요없습니다.

메소드의 추가 삭제에 대해서는 여러가지 경우를 나눠서 볼 수 있습니다.
기존의 클래스에 메소드를 추가 하거나 변경하는 경우가 있을 수 있습니다.
이 경우 Objective-C의 경우에는 기존의 클래스의 소스에 변경이 없이
추가가 가능합니다, Smalltalk의 경우도 마찬가지입니다. Java의 경우는
소스코드가 있어야 되는 것으로 알고 있습니다. 그러나 그 때문에 다른
의존하는 프로그램을 재 컴파일 할 필요는 없습니다. Objective-C의 경우
에는 위에서 말한 posing을 이용할 수도 있습니다. 이 경우도 당연히 재
컴파일은 필요가 없습니다.
삭제의 경우에는 문제가 있을 수 있습니다. 그 메소드가 사용되지 않던
것이라면 관계가 없습니다만, 사용되고 있다면 문제가 될 수 있습니다.
이 경우는 forwarding을 이용해서 처리가 가능합니다만 미치지 않고서야
다른데서 쓰는 메소드를 제거하지는 않겠죠? :-)

C++의 문제점들, 특히 유지보수관련은 C++가 정적이라는 데서 연유하는
것이 많습니다. 이 때문에 Alan Kay가 OOP라는 말은 어울리지 않는다고
했던 것이고요(실제로는 OOP라는 말은 자신이 창안을 했을 때는 C++와
같은 언어에는 어울릴 수 없다고 했습니다.) 같은 문제를 Java도 좀 가지고
있기는 한데, 정적 형검사를 위해서 OOP를 위한 기능을 희생한 비율이 잘
조화가 되어 있는 편이죠.

여담으로, 80년대말 90년대 초 NeXT가 Objective-C를 유행 시켰을 때
많은 회사들이 고려를 했다가 위와 같은 특징 때문에 쓰지 않았다는 말이
있습니다. 이건 Smalltalk과 같은 문제인데, 라이브러리를 주면 그 설계가
노출이 되는 것은 관계가 없다하더라도 배포되는 실행파일에 따라가는
프레임워크의 사용을 막는 것이 어려워서 돈벌이에 애로가 있어서 말이죠.
실제로 Smalltalk의 경우에도 (때문에)상당히 비싼 라이센스를 받았었고
NeXT도 같은 식이었습니다.(물론 자사의 OS를 쓰는 경우에는 아니었죠.
그리고 지금은 싸게 내렸습니다. 거의 1/20로 말이죠.) 이건 그냥 여담
입니다 :-)

clhitter wrote:
chunsj wrote:
유지보수의 측면에서는 C++는 C보다 못할 때가 많습니다. 특히 Class를
이용한 캡슐화의 부분에서인데...

1. Base Class의 Instance Variable이 바뀌면 전부 컴파일을 해야한다.
때문에 원 베이스의 소스가 항상 필요합니다. 처음에 설계를 잘 하면
이런 경우가 없다라고 주로 반박을 하는데 실제로 그런일은 없습니다. 관련
논문들은 보시면 FBC Problem에 대해서는 대체로 동의하고 있습니다.

2. Base Class에 새로운 Method를 추가하면 전부 새로 컴파일을 해야
한다. 역시 1과 마찬가지의 문제가 있죠.

본 주제하고는 약간 벗어난 질문성 글을 올려서 죄송합니다만.

다른 언어 (ex. Java, Smalltalk, Object C) 등에서는 위와 같은 상황에서 어떤 식으로 처리가 되는지 궁금합니다.

예를 들어 Java의 경우 어떤 class의 member가 바뀌거나 새로운 method가 추가되는 경우 그 class를 reference하는 java 파일들은 재컴파일 필요 없는 건가요?
만약 그렇다면 method가 추가되는 경우는 납득이 가지만 method가 삭제되는 경우는 문제가 발생할 수도 있을 것 같아서요.
일단 javac가 method가 추가되는 경우와 삭제되는 경우를 나누어서 다른 처리를 할만큼 똑똑할 수 있을것 같지도 않고, 따라서 삭제되는 경우도 해당 java 파일만 재컴파일 될텐데 그러면 runtime에서 에러가 발생하겠죠?
그럼 method를 삭제하는 경우는 사용자가 알아서 make clean, make 하는 식의 작업을 한다음 거기서 나오는 에러들을 수정해야 한다는 이야기인데, 그럼 오히려 c++의 경우보다 상황이 더 악화되는게 아닌가 해서요.
첫째, 개발자가 어떤 class의 interface를 수정했을 때 이 class를 reference하는 java 파일들에 대해서도 재컴파일을 해야 하는 수정인지를 판단해야 할테고.
둘째, c++의 경우 그 class를 reference하는 파일들만 재컴파일하는게 아니라 개발자가 적당히 선택한 불특정 다수의 java 파일에 대해 재컴파일을 해야 할테니까요.

저도 주로 c++로 개발을 하는 사람인데, 항상 지적하신 2가지 문제때문에 많은 파일들을 재컴파일 할 때마다 더 좋은 방법은 없을까 많이 고민을 했었습니다 ^^
그래서 다른 언어에서는 이 문제들을 어떻게 처리하는지 더 궁금해지는군요.

mastercho의 이미지

CN wrote:
제가 알고 있는 VC++ 7.1이 지원못하는 문제들을 가진채 99.70%라는게 특이하군요. 언제 DDJ를 살펴봐야겠습니다. 흥미로운 과제를 던져주셔서 감사하군요.

VC++ 7.1 은 98.22% 네요

다시 확인 부탁드립니다
:o

Quote:
edg 3.2 99.70%

Comeau 4.2 99.55%

Intel 7.1 99.55%

PGCC 4.1-2 99.11%

VC++ 7.1 98.22%

gcc 3.3 96.14%

Borland 6.0 92.73%

Watcom 1.0 78.49%

hangulee wrote:
이렇게까지 C++을 좋아하시는 분이 계시다는 사실에 놀라웠고 또 많은점을 생각해보게 되었습니다.

C++ 언어가 사실 좀 어렵기때문에 메니아틱한 느낌이 나는것도 사실입니다
[사실 쓰는 사람도 많지 않으니(제대로?) 희귀성??같은거에 더욱 매력을 느끼기도 하지요]

적절한 비유가 될지는 모르겠지만 이거와 비슷하지 않나 싶네요

여기 리눅스를 사용하는분들중 상당분들이 ,
윈도우의 간편함이나 숨겨짐? 같은거에 혐오감?마저 느끼는 형편이고
리눅스는 아무나 쉽게 못만진다는 자부심?같은게 있는줄 압니다
윈도우 보다 세세한 조작까지 가능하다보니
윈도우 쓰는 사람보다는 웬지 리눅스 쓰는 사람들이 뭔가 있어보이기도 하고
그런게 아닌가 싶습니다
이런 시점에서
"윈도우서버를 쓰고 리눅스 조금 써봤는데 , 리눅스는 서버로써 별 가치가 없어"
이런 이야기를 들은 심정같은 심정이었던거 같습니다

어째튼 조금 감정적인면이 나온거 같아서 다시 한번 글쓸때 조심해야겠다는
생각이 드네요

그럼

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

pynoos의 이미지

사실 C++에서 가장 원망(?)스러운것중하나가.. name mangling에 대한 기준이 없다는 것인데, 이것때문에 발생하는 것은 compiler 독립적인 바이너리가 생산되지 않는 것에 있습니다.

거의 모든 class member 함수가 exportable symbol로 잡히는데 이것은 상속에 의한 calling이 가능하기 때문에 어쩔 수 없는 상황이라하여도, C의 export symbol의 간결함에 비하면 정말 약간은 답답한 구석이 있는 부분입니다.

c++filt 나 nm의 -C option이 있기는 하지만, 여전히 디버깅을 위한 것일뿐 입니다.
다른 컴파일러나 언어와 link를 위한 구석이 없다고해도 과언이 아닙니다. 결국 export "C"를 써서 name mangling을 없애는 방향으로 가는 수밖엔 없지요.

모든 언어가 그렇긴 하지만, C++의 경우 Object symbol에 대한 표준(?)이 없는 것이 오히려 그런 상황을 초래하지 않았나 싶습니다.

아뭏든 C/C++은 적절한 trade off 범위내에서 선택하는 것이 항상 고민입니다.

주절주절..

akbar의 이미지

...

vacancy의 이미지

Quote:
그리고 ,정확하지도 않고 ,
잘못된 판단으로 여기지는 부분으로 자기가 좋아하고 연구하는 언어를
폄하할때는 , 이런 문제가 충분히 발생할수 있지 않나 싶네요

제가 만약 C언어의 단점이 아닌것을 가지고 단점으로 치부하며
포인터를 쓰는 C는 유지보수도 불가능하고, 구조적 절차로 프로그래밍하는
안좋은 언어라고 글을 쓴다면 어떨까요?

사실 전 언어에 대한 애착이 그리 많지도 않고
언어에 대해 특별히 연구하는 것도 없고 해서 공감이 힘들긴 합니다만.
( 파스칼은 좀 좋아하긴 합니다. 흐 -_- )

여기서 C++의 단점에 대해 얘기하시는 분들은
일반적으로 알려져있는 C++의 단점들을 논하시는 것 같은데요.
단점이 아닌 걸 가지고 단점이라고 하시는 분은 별로 없는것 같은데,
설마 C++가 완전무결한 언어라고 생각하시는지요 ?

그리고 C에서 자유가 마구 허용되는 것과
C++에서 자유가 마구 허용되는 것은 아주 다르다고 생각합니다.
C는 탄생 자체가 OS 제작과 밀접한 관련이 있었고,
최대한 시스템 레벨에서 작업을 할수 있도록 하는 것이 매우 중요한 요소입니다.
이전 다른 토론에서도 "C는 portable한 assembly language"라는 얘기가
많이 나왔었던 것으로 기억합니다.
C++는 용도가 크게 다르죠.

C++가 C보다는 일반 어플리케이션 개발 및 유지보수에 있어
어느 정도 우위에 있다고 볼 수 있겠습니다만,
최근에 나오고 있는 C#이나 Java 등에 비해서도 그렇다고 말하기는
다소 어려움이 있지 않나 생각합니다.
제가 생각하는 C++가 여전히 많이 사용되고 있는 까닭은
기존에 배포된 자료 및 라이브러리가 많이 있고
binary code가 직접 나오며, 그로 인해 퍼포먼스가 높다는 것 같네요.
( 분석이 상대적으로 쉬운 중간 코드를 생성하지 않으니 소스를 숨긴다는 측면에서도 좋겠죠. )
하지만 이것이 언어 구조 자체의 장점이라고 생각하지는 않습니다.
C#이나 Java 등 다른 언어 관련 자료도 상대적으론 적지만 축적되어가고 있고,
JIT 기술이 발전하고 시스템들이 빨라져가면서 퍼포먼스의 중요도가 낮아져가고 있으니까요.
( 퍼포먼스가 극단적으로 중요한 경우도 있겠습니다만. )

C++가 적당한 diet를 했으면 좋겠다는 생각은
비단 저만의 생각일런지요.

Quote:
C++ 언어가 사실 좀 어렵기때문에 메니아틱한 느낌이 나는것도 사실입니다
[사실 쓰는 사람도 많지 않으니(제대로?) 희귀성??같은거에 더욱 매력을 느끼기도 하지요]

적절한 비유가 될지는 모르겠지만 이거와 비슷하지 않나 싶네요

여기 리눅스를 사용하는분들중 상당분들이 ,
윈도우의 간편함이나 숨겨짐? 같은거에 혐오감?마저 느끼는 형편이고
리눅스는 아무나 쉽게 못만진다는 자부심?같은게 있는줄 압니다
윈도우 보다 세세한 조작까지 가능하다보니
윈도우 쓰는 사람보다는 웬지 리눅스 쓰는 사람들이 뭔가 있어보이기도 하고
그런게 아닌가 싶습니다
이런 시점에서
"윈도우서버를 쓰고 리눅스 조금 써봤는데 , 리눅스는 서버로써 별 가치가 없어"
이런 이야기를 들은 심정같은 심정이었던거 같습니다

OS Level에서 세세한 조작이 가능한 것은
사용자에게 득이 되는 경우가 많지만,
Language Level에서 세세한 조작이 가능한 것은
System Programmer에게는 득이 되는 경우가 많아도
그 외에는 그렇지 않은 경우가 대부분입니다.
특히 유지보수의 측면에서요.

점차 프로그램이 방대해져가는 지금
언어가 다양한 기능을 제공하는 것도 중요하겠지만,
언어 자체가 최대한 버그를 줄여줄 수 있는 구조인가도 상당히 중요하잖을까요.
( 옛날엔 당연히 해야했던 메모리 deallocation같은 것들이, 요즘은 신경쓰기 아주 짜증나더군요. -_-; )

정태영의 이미지

asheap wrote:
일단 현재 C++의 주요한 사용처를 대체하는 언어는 등장하지 않고 있다는 전제에 동의를 요구하는 데서 시작하겠습니다. 왜냐하면 최적화된 성능이 필요한 초대형 상업용 소프트웨어(최신 윈도우 운영체제나 오피스 소프트웨어-오픈 오피스까지도, 그리고 대부분의 게임소프트웨어들 이곳을 참조하세요: http://www.research.att.com/~bs/applications.html ) 는 현재까지 거의 대부분이 C++을 사용해서 제작되고 있기 때문입니다. 물론 apache bind gimp등등 c만을 사용해서 작성되는 소프트웨어들이 있지만, 상용이 아니라는 점에서 빼겠습니다. 프로그래머가 스스로 작성한 소프트웨어를 판매 그자체로 먹고 살 수 있는 소프트웨어만을 대상으로 하겠습니다.
C++ 자체의 효용성과 성능은 초대형 상업용 소프트웨어가 당연한 듯이 C++로 만들어지고 있는 상황을 보면 어느정도는 확신을 가져도 된다고 생각합니다. 문제는 언어 자체가 프로그래머가 정말 공들여 작성해야 쓸만한 코드가 나오고, 언어자체에 대한 제대로된 학습이 부족한 상황에서 작성한 코드는 정말 유지보수가 불가능해지는 경우가 많다는 점인 것 같습니다.(물론 다른 대부분의 언어도 비슷하기는 합니다. 하지만 유독 C++만 이 문제점이 자주 그리고 맹렬하게 지적되더군요.) 이 문제점으로 인하여 C++의 단점만을 잡고 보면 정말 엄청나게 후진 언어로 보이지만, 현재 상황에서 정말 그 프로그램 가지고 제대로 먹고 살 수 있는 소프트웨어를 만드는 데는 C++을 쓸 수 밖에 없는 상황입니다. (애플사등 몇몇 소수의 플래폼에서 운용되는 전용 소프트웨어에 관해서는 일단 빼고 생각하겠습니다.)
결국 C++이 정말 좋지 않다고 생각하는 사람들이 뜻을 함께모아서 C++을 사용하지 않고도 초대형 상업 소프트웨어 작성 및 유지보수가 가능하다는 것을 보여준다면 이후 새로운 언어가 C++의 자리를 대체할 가능성이 생기리라고 봅니다. 그런 일이 생기려면 일단 ms가 확실히 C++ 대신 다른 언어를 사용하여 윈도 운영체제를 작성한다면 좋을 것 같습니다.
프로그래머 사회에서 C++이 많이 사용되는 만큼 C++에 관한 비판이 매우 자주 올라오고 그것에대해서 C++ 매니아들이 노이로제가 걸려있는 만큼 이 이야기만 나오면 분위기가 험악해지는 것 같습니다. C++을 비판은 좋지만, C++ 매니아들의 기분을 상하게 할 수 있는 단점만을 들쑤시는 글들은 좋지 않은 것 같습니다.
C++을 사용하시고, 또 C++에대한 생각과 느낌을 적고 싶으신 분들은 최소한 다음의 홈페이지에 나오는 수많은 글과 인터뷰을 보시고 혹시 자신이 생각하던 단점에 대해 직접 C++창시자에게 질문한 글이 있는지 확인해 보십시오. 저같은 경우도 약 2년간을 C++을 조금만 안채로 C++을 비난하고 거부하면서 보냈지만, 지금은 열렬한 C++매니아입니다. 스트라웁씨의 홈페이지에서 저는 많은 것을 새로 알고 생각을 바꿀 수 있었습니다.
http://www.research.att.com/~bs/homepage.html
이곳에서 언급되지 않은 내용은 C++에 관한 수많은 명서들에서 해답과 이유를 얻을 수 있었습니다만 그 내용은 여기에 연결할 수 없으니 포기하겠습니다.
물론 C++을 정말 많이 아시고, 또한 그것을 제대로 사용한 소프트웨어를 작성하신 다음 비판하시는 분들에 대해서는 그 비판을 잘 읽고 받아들일 수 밖에 없을 것 같습니다.
제대한 환경에서 시간에 쫓기며 글을 써서 한번 읽어보고 정리도 못한 채로 올리게 되어 글이 왔다갔다일 것 같은 데 좀 이해해 주시기 바랍니다.

MS window는 C++이 아닌 C로 작성된 걸로 알고 있습니다..

그리고 대형 프로젝트에서.. C가 아닌 C++을 사용한 경우가 많은건...
유지보수에서의 장점 때문이지 성능 때문이 아닙니다..

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

akbar의 이미지

...

akbar의 이미지

...

vacancy의 이미지

Vector나 List같이 많은 사람들이 쓰는 부분은
STL의 존재가 참 편하긴 한데,
직접 만들어 써야 하는 경우가 좀 -_-;
어쨌든 다른 언어들과 비교해볼 때,
Template은 C++만이 가진 확실한 장점인 것 같습니다.

그나저나 퍼포먼스에 대한 문서가 하나 보여서,
이 토론과 상관이 없는 것도 같지만 글 쓰는 김에 링크해봅니다. -_-a

http://www.devdept.com/prg/docs/wdn200313.pdf

mastercho의 이미지

vacancy wrote:
Vector나 List같이 많은 사람들이 쓰는 부분은
STL의 존재가 참 편하긴 한데,
직접 만들어 써야 하는 경우가 좀 -_-;
어쨌든 다른 언어들과 비교해볼 때,
Template은 C++만이 가진 확실한 장점인 것 같습니다.

그나저나 퍼포먼스에 대한 문서가 하나 보여서,
이 토론과 상관이 없는 것도 같지만 글 쓰는 김에 링크해봅니다. -_-a

http://www.devdept.com/prg/docs/wdn200313.pdf

이런 이런 VC 6.0으로 테스트가 됐네요 -_-;

VC 6.0의 STL은 한마디로 표준에 부합하지도 않고 , 엉망으로 만들어진거라
알고 있습니다
[앗 자세히 보니 STLPort네요 --; 이것은 쓸만하다고 들은.. 음]

게다가 STL의 내부 구현은 컴파일러 회사마다 구현이 엄청다르고
기타 여러기자 최적화나 코드에 따라 컴파일러차이가 클수 있기때문에
위의 테스트 경우 -_-; 별로 신뢰가 가지 않습니다

뭔가 아쉽네요

자세히 보니 다 감안한 이야기군요 -_-; C와 C++에 대한 구체적인 비교를 했다기 보단 C#, 자바 C계열 언어 비교라고 하는게 더 어울릴듯

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

mastercho의 이미지

vacancy wrote:
그리고 C에서 자유가 마구 허용되는 것과
C++에서 자유가 마구 허용되는 것은 아주 다르다고 생각합니다.
C는 탄생 자체가 OS 제작과 밀접한 관련이 있었고,
최대한 시스템 레벨에서 작업을 할수 있도록 하는 것이 매우 중요한 요소입니다.
이전 다른 토론에서도 "C는 portable한 assembly language"라는 얘기가
많이 나왔었던 것으로 기억합니다.
C++는 용도가 크게 다르죠.

C++ 창시자인 Bjarne Stroustrup 이렇게 말했었죠
C++은 , C로 시스템 프로그래밍을 하는 사람을 위해 나온거라 볼수 있다고요
그래서 시스템 프로그래머에게도 많이 권한걸로 아는데
어지간이도 C만을 고집하는 하는 프로그래머가 많자
이렇게 말했습니다

Bjarne Stroustrup wrote:
"늙은 개에게 새로운 트릭을 가르키는 것은 힘들다"

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

meteors의 이미지

aqua0125 wrote:

MS window는 C++이 아닌 C로 작성된 걸로 알고 있습니다..

MS Windows (NT 계열)은 C와 C++가 같이 사용되었습니다. 물론 핵심 부분은 C입니다.

이한길의 이미지

아침에 들어와보니... 새로운 글들이 많이 올라와 있네요..
지나가려다가 저에게 직접 남기신 글이 있어서 답변 드립니다.

akbar wrote:
To hangulee:
hangulee 님은 언젠가 마소 잡지에 데이타 베이스프로그램을 사용하지 않는 웹게시판을 연재했었죠.
그런데 동시성 처리라든가 또란 검색에 있어서 반드시 필요한 B-Tree 처리가 전혀 되있지 않았었죠. 꼭 B-tree 가 아니더라도 검색에 필요한 자료구조 설계를 했어야 비로서 게시판으로 봐줄 수가 있었을 텐데...
그 게시판에서 채용한 방식은 절차지향적으로 짜여져 있었죠. 평소에 객체지향방식을 많이 접하지 않은 듯 하네요 그런분이 자바 이상으로 객체지향 설계를 할 수 있는 C++ 에 대하여 언급한 것은 성급했다고 보아요.
C 에 들인 공만큼 C++ 에도 투자해 보시길 바래요

제가 마구보드에 들어가는 ListDatabase.php라는 소스 코드를 작성한지는 상당히 오래되었습니다. 제가 대학교 1학년에 들어와서 작성한거구요.. 그때가 PHP를 시작한 때였습니다. 더욱이 문제가 되는것은 고등학교다니면서 C로 구현한것을 옮긴것이었습니다. 거의 이론없던 시절에.. 그리고 객체지향적인 프로그래밍을 하기 전에 작성된 것입니다. 더구나 PHP4에서는 객체지향을 제대로 지원하지 않고 있지요.

그리고 그 상태에서 일반적인 단순한 게시판 운영을 할정도가 된다고 생각되었기 때문에 그리고 많은 분들이 저에게 어떤 방법으로 만든거냐시기에 설명을 써야겠다 싶었는데 마침 마소에 그런 코너가 있어서 거기에 적은 것이었습니다.

아시겠지만 PHP라는 언어로 제대로된 데이터처리를 하는것은 상당히 어렵습니다. 특히 인터프리터로 처리되는 언어이기 때문에 실행속도도 코딩하면서 고려할 사항이 많습니다. PHP를 해보셨다면 여쭙지요..

$A['A']
$A["A"]
$A[A]

어느게 가장 빠를거라고 생각하십니까? $A[A]는 다른 두개에 비해 상당히 느린 속도를 보입니다. 제가 예전에 테스트해본 경험으로는 $A['A']가 가장 빠릅니다. 모두 같은 처리를 하면서도 이렇게 차이를 보이는 것은 코딩에 상당한 주의를 기울이게 합니다.

앞에서도 언급했듯이 자신있게 C++을 잘한다고 말씀드리기에는 무리가 있습니다. 하지만 저도 C++이라는 언어가 어떠하다는 것은 알고 있으며 객체지향이라는 개념을 매우 좋아합니다. 저는 C++이 자바 이상의 객체지향 설계가 어렵다는 이야기가 아니었고 그 이하의 설계가 가능하며 그렇게 될 가능성때문에 의견을 이야기한것이었습니다. 잘 사용했을때 C++의 가능성은 인정합니다.

물론 앞에서도 말씀드렸듯이 제가 C++에 대해 "대체"해야 한다고 생각한다는 조금 과격한 말을 한것에 대해서는 C++을 좋아하시는 분들께는 미얀하다는 말씀을 드립니다.

----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.springnote.com
http://hangulee.egloos.com

akbar의 이미지

...

M.W.Park의 이미지

fender wrote:
항상 언어 논란이 있으면 나오는 말이지만 정답은 'right tool for the right job'이 아닐까 싶습니다.

맞는 말씀입니다.

옛날에... (고등학교 때인지 대학 때인지 잘 기억이 안납니다만8)) 어느 무식한 월간지에서... 아주 심플한 C와 C++의 비교를 한적이 있었던것같습니다.
삼천 라인인지 오천 라인인지 기억이 잘 안납니다만, 여튼 코드의 양이 그 이상이 되면 C++이 더 낫다는 황당한 기사를 본적이 있었죠.

그때는 그런가 보다 하고 넘어갔었지만 지금 생각해보면 아주 웃긴 이야기였던 것같습니다.

언제가 되었건 이런 논의들이 웃겼었다고 이야기 할 수 있을 때를 기다리며......

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

asheap의 이미지

meteors wrote:
aqua0125 wrote:

MS window는 C++이 아닌 C로 작성된 걸로 알고 있습니다..

MS Windows (NT 계열)은 C와 C++가 같이 사용되었습니다. 물론 핵심 부분은 C입니다.

물론 그렇겠지요. 하지만 거의 대부분의 C++을 사용한 프로그램에서 최대한의 성능이 요구되는 부분은 C++내의 C subset의 기능을 이용해서 짜게 됩니다. 결국 C++로 짠 거의 모든 프로그램이 "C++을 사용했지만 핵심 부분은 C입니다."라고 말할 수 있겠지요.
즉 "C++을 사용하여 만들었다"는 말에는 일부분은 C를 사용했다라는 말이 암시적으로 포함됐다고 보는게 옳을 것 같습니다.
이름에 괜히 C가 있겠습니까? ^^

vacancy의 이미지

mastercho wrote:
vacancy wrote:
그리고 C에서 자유가 마구 허용되는 것과
C++에서 자유가 마구 허용되는 것은 아주 다르다고 생각합니다.
C는 탄생 자체가 OS 제작과 밀접한 관련이 있었고,
최대한 시스템 레벨에서 작업을 할수 있도록 하는 것이 매우 중요한 요소입니다.
이전 다른 토론에서도 "C는 portable한 assembly language"라는 얘기가
많이 나왔었던 것으로 기억합니다.
C++는 용도가 크게 다르죠.

C++ 창시자인 Bjarne Stroustrup 이렇게 말했었죠
C++은 , C로 시스템 프로그래밍을 하는 사람을 위해 나온거라 볼수 있다고요
그래서 시스템 프로그래머에게도 많이 권한걸로 아는데
어지간이도 C만을 고집하는 하는 프로그래머가 많자
이렇게 말했습니다

Bjarne Stroustrup wrote:
"늙은 개에게 새로운 트릭을 가르키는 것은 힘들다"

창시자이긴 하니 Stroustrup씨의 말도 중요하겠지만,
실제로 시장에서 어떻게 쓰이고 있는가가 더 중요하지 않을까요.

C++은 C에 비해 다양한 칩이나 기기에 쓰이는 데는 좀 부담스럽죠.
( 개발 환경이 갖춰져있는 x86같은 특정 플랫폼들만 다룬다면 모르겠습니다만. )
portability도 C에 비해 떨어진다고 생각하는데요.
( 아무래도 simple하다보니, C compiler가 없는 platform은 드물죠. )
시스템 프로그래머들이 바보라서 C를 고집한다고 생각하진 않습니다.

저도 Stroustrup씨의 책을 보고는 있습니다만 -_-;
Stroustrup씨의 말들을 보면 종종 C++에 대한 애착(?)이 과하다는 생각이 들더군요.

corba의 이미지

chunsj wrote:
자유라기 보다는 C++의 문제를 돌아가는 방법이겠죠 :-) 상속을 쓰는 것을
피해야 한다면, 그건 깊은 상속을 마구 사용하는 것 만큼이나 위험합니다.
물론 깊은 상속을 해도 되는 랭귀지들이 있기는 하지만 적어도 C++은
아닙니다. 차라리 언어가 개선이 되는게 나은 방향이 아닐까요?(물론
가능한지는 모르겠습니다 :-)

컴파일 타임을 위해서 결합도를 낮추는 것은 돌아가는 방법이기도 합니다만 일반적으로 좋은 디자인으로 가는 길이라고 생각합니다.

이것은 C++만의 문제가 아닌 객체지향 언어의 문제라고 생각합니다.

베이스 클래스의 private멤버가 바뀌면 C++에서 재컴파일만 필요하겠지만 pulbic멤버나 가상함수의 인터페이스가 바뀌게 되면서 발생하는 혼란은 어떤 객체지향 언어에서나 존재하는 문제가 아닐까 합니다.

이런 이유로 근대 객체지향 디자인에선 추상화 외의 상속은 자제하고 있다고 들었습니다.

오히려 다르게 생각하면 C++의 문제라고 생각하는 부분이 장점이 될 수도 있다고 생각합니다. C++의 그런 특성이 프로그래머에게 어느정도 좋은 디자인을 강제하게 하는 요소가 있다고 생각합니다. Java의 Import는 #include에 비해 훨씬 강력하고 편하다고 생각합니다.(개념이 전혀 다르긴 합니다만 :D) 하지만 그런 이유로 저는 #include를 쓸때 한번 더 생각을 하게 되는 습관이 생겼습니다. 그래서 최대한 불필요한 결합과 상속을 줄이려고 노력하고 있습니다.(물론 아직까지 갈길은 멉고 험합니다만. :oops: )

P.S : C++의 대체용 언어로 D언어가 마음에 들긴 합니다만. 시장성이 있을지 모르겠습니다.

akbar의 이미지

...

pynoos의 이미지

overloading과 overriding 문제에 있어서 전자는 naming mangling에 argument type을 encoding하고, 후자는 대개의 구현이 virtual function table로 되어 있는데, 이 table을 사용하는데 index를 취하여 interface를 만들고 있습니다.

vft를 사용하지 않는 방식으로 만들어지게 되면, 성능상 runtime function binding에 에 들어가는 비용이 많이 들어가게되고, 그다지 성능면에서 좋지 않게 됩니다.

과연 base가 바뀌는데 재컴파일이 필요하지 않으면서 성능문제도 괜찮은 설계가 있을 수 있을까요?

서지훈의 이미지

앞에 좋은 글들이 많은거 같은데...
제가 더 이상 길게 말씀을 드리긴 그렇고^^
제가 아는 단편적인 c++은 c의 struct 구조에 변수뿐만 아니라...
함수가 들어가는 구조가 c++이다라는 것...
이건 c++의 창조자가 고안한 것이기도 하고요...

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

#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);

akbar의 이미지

...

죠커의 이미지

시중에 쓰이는 STL의 종류는 생각보다 많지 않습니다. STLPORT는 SGI STL에서 나왔고 이 둘의 지배력은 매우 크니깐요. 상업용 C++컴파일러에서도 STLPORT를 쓰는 곳이 많습니다. (B사의 컴파일러에 들어있는 것도 많은 사람들은 모르더군요.)

vacancy님이 첨부한 문서는 아직 읽어보지 못했는데 STL의 퍼포먼스라니깐 의문점이 생기는 부분이 있습니다. (오후에 충분한 시간을 두어서 첨부된 문서를 읽어보겠습니다.) STL의 퍼포먼스라면 컨테이너와 제너릭 알고리즘의 퍼포먼스일텐데요. STL의 컨테이너의 특성을 고려하고 테스트를 하는 것인지 궁금합니다. STL의 할당자는 공간이 부족하면 공간을 2배로 잡고 복사생성자들을 대거 호출하지 않습니까? 하지만 C#이나 Java의 라이브러리들은 단순히 언어자체의 성질을 이용해서 그대로 할당받고 제거될텐데요. 충분히 크게 할당한다면 복사생성자가 실행되지 않아서 속도는 향상될테지요. 반면에 공간은 늘어날테지만요.
PS:

약간은 위의 이야기가 벗어납니다만 C++라이브러리의 퍼포먼스에 사람들이 덜 관심을 갖는 것 같습니다. iostream같은 경우에도 이론만큼 최적화되지 못하였습니다. 단순히 c++라이브러니는 더 추상화되었으니깐 느려도 만족해. 정도의 시선이 많은것 같습니다.

asheap의 이미지

vacancy wrote:
Vector나 List같이 많은 사람들이 쓰는 부분은
대한 문서가 하나 보여서,
이 토론과 상관이 없는 것도 같지만 글 쓰는 김에 링크해봅니다. -_-a
http://www.devdept.com/prg/docs/wdn200313.pdf

한번 간단히 요약하겠습니다. 테스트 코드는 위에 연결된 문서를 참조해 주십시오.

C, C++ 컴파일러를 digital mars사의 것과 intel의 것을 사용했는데, digital mars사의 컴파일러는 무료이고 실험대상인 D언어 컴파일러를 만든 회사라 정확한 비교를 위해서 사용했다고 합니다. 하지만 전 불만이군요. ms꺼나 안되면 gcc/g++을 사용할 것이지... 컴파일러들은 대략 최신버전을 사용한듯 합니다.

float to int 변환성능
(단 C#은 정확도에서 떨어진다고 함.)

    C(intel) 1.6
    C++(intel) 1.9
    C# 100
    D 167.4
    C(dm) 167.8
    C++(dm) 167.9
    JAVA 259.5

int to float

    C(intel) 9.7
    C++(intel) 22.6
    JAVA 95.6
    D 95.7
    C(dm) 96.4
    C++(dm) 97.3
    C# 100

int to str 1
여기서 C++이 stream라이브러리를 사용해서 매우 좋지 않은 결과가 나왔는데요. interger_to_string<> 템플릿을 사용한 결과는 좋습니다. 이결과를 포함시켜서 리스트를 내보지요. stream 라이브러리 사용한 것은 그래프1에 포함되있고 옆에 그래프가 하나 더 있습니다. 그게 템플릿 쓴것

    C++(intel template) 28.8
    JAVA 41.7
    C++(dm template) 93
    C# 100
    D 112.3
    C(dm) 113.2
    C(intel) 151.8
    C++(dm stream) 387.9
    C++(intel stream) 506.7

이 그래프가 마스터조님이 좀 잘못보신 것 같은데, C++을 좋아하는 프로그래머가 즐거워할 결과군요. -_-; 하지만, 결국 C++을 잘 알고 쓰는 것과 모르고 쓰는 것의 차이가 이만큼 크다는 것을 나타내는 결과입니다.

시간이 없는 관계로 10%이내의 비슷비슷한 결과가 나온것은 생략하고 좀 차이가 크다거나 한것만 정리하지요.

str2i

C와D는 atoi사용했구요. (c++에서 atoi못쓰란 법은 없지만... 머 사실 더 좋은게 있으니)
이결과도 그래프만 보면 c++/stl이 충격적으로 후진 것으로 보이지만, 실상은 다릅니다. --;
atoi를 능가하는 interger_to_string<>류의 라이브러리가 있다고 하는 군요. 하지만 테스트에는 포함되지 않았습니다.

    C(intel) 12.2
    C(dm) 18.8
    D 23.6
    JAVA 76.6
    C++(dm) 254.8
    C++(intel) 968.0

strcat은 다양한 구현 방법과 테스트 방식으로 비교했는데 각 언어당 최고의 방법을 사용했을경우를 정리해봤습니다. 사실 이런 식으로 비교하면 안될 것 같긴 하지만, 어짜피 그 언어
(실행시간ms)

    C++(dm) 2378
    C(dm) 2761
    C# 3410.5
    C++(intel) 3794
    D 2939.5
    C(intel) 5250
    JAVA 7790.5

으윽 결론까지 정리 못했는데 시간이 부족하네요. 정해진 시간만 인터넷을 쓸 수 있는 환경이라... 밤에 계속할 수 있을듯.

[/][/][/][/][/]
mastercho의 이미지

읽어볼 시간이 없어서 , 그냥 대충 눈에 보이는것만 봐성
--; , 보이는 결과만..... 어째튼 재미나네요

근데
C#이나 자바는 라이브러리때문에 속도를 다 잡아먹는다고 본거 같던데요, 라이브러리가 후지다고 본거 같은 -_-;

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

fender의 이미지

mastercho wrote:
근데 C#이나 자바는 라이브러리때문에 속도를 다 잡아먹는다고 본거 같던데요, 라이브러리가 후지다고 본거 같은 -_-;

참고로 저 벤치마크의 출처는 MS 개발자들을 위한 잡지이고, 결론은 "C#은 쓸만하다"입니다 :)

실제 어플리케이션 개발에 있어 raw performance를 측정하는 벤치마크는 크게 의미가 없습니다. 예를들어 단순 수학 계산 루프를 몇만번 돌렸더니 자바나 C#이 C보다 100배 느리다고 가장하면, 여기서 곧장 "역시 C가 최고야"라는 결론이 나오는게 아닙니다.

왜냐하면 중요한 건 어떤 언어가 다른 언어보다 몇 배 빠른지가 아니라 실제 해당 프로젝트에 적용했을 때 허용 가능한 범위의 성능을 보장할 수 있는 지 없는 지이기 때문입니다.

예를들어, 아까의 경우 C가 C#보다 100배가 빠르다고 했는데, 만일 어떤 클라이언트 어플리케이션에서 특정 대화창을 띄우는데 C가 0.001초, C#이 0.1초 걸렸다면 이는 대부분의 경우 최종 사용자 입장에서는 전혀 의미가 없는 차이입니다.

하지만 만약 그런 어플리케이션을 만드는데 C가 개발자 2명이 3개월, C#이 개발자 1명이 1개월이 걸렸다면 당연히 C#을 이용해 개발하는 것이 이익이 될 것입니다.

자바의 경우도 느리다는 편견을 가진 사람들이 많지만, 엔터프라이즈 시장에서 가장 널리 쓰이는 언어 중에 하나라는 것도 raw performance가 큰 의미를 가지지 못함을 보여줍니다. 이는 대부분 서버 어플리케이션에서 중요한 건 scalability이고, 언어 자체의 실행 속도 보다는 대부분 네트워크에서 오버헤드가 발생하기 때문입니다.

다시 강조하지만 "right tool for the right job", 즉 하려는 작업에 가장 적합한 언어가 좋은 언어입니다. 이런 문맥을 떠나서 무조건 어느 언어가 최고이니 무조건 성능 좋은 언어가 좋으니 하는 건 다 무의미 합니다.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

죠커의 이미지

mastercho wrote:
C++ 창시자인 Bjarne Stroustrup 이렇게 말했었죠
C++은 , C로 시스템 프로그래밍을 하는 사람을 위해 나온거라 볼수 있다고요
그래서 시스템 프로그래머에게도 많이 권한걸로 아는데
어지간이도 C만을 고집하는 하는 프로그래머가 많자
이렇게 말했습니다

Bjarne Stroustrup wrote:
"늙은 개에게 새로운 트릭을 가르키는 것은 힘들다"

전 이 부분에서 동의하기가 좀 힘든 면이 있습니다.

1. 퍼포먼스

선뜻 동의하기 어려운 부분이 퍼포먼스를 위해서 클래스 조차도 싫어하는 사람들에게는 C++의 많은 특성들은 그림의 떡일겁니다. 그런데 그런 특성들을 안 쓴다면 C++이라고 보기는 힘들죠. 그런 분들에게는 C++은 사치로 여겨질겁니다.

2. 이식성

C언어의 특성은 C++보다 사려깊지 않게 만들어진 것이 아니라 보다 많은 하드웨어에 이식되기 위해서 노력합니다. 그래서 사람이 쓰기에는 불편한 부분이 여러가지지만 컴파일러를 만드는데는 그만큼 편한 언어는 드뭅니다. 현실적으로 C가 깔릴수 없는 환경이라면 매우 열악해서 어셈블리와 기계어 밖에 되지 않는 환경일 가능성이 큽니다. 그래서 C는 C++보다 더 넓은 플랫폼을 포용합니다.

또 이식성의 발목을 잡는 것은 네임 맹글링입니다. C++에서 네임 맹글링이 규격이 없는 것 때문에 C++은 시스템 프로그래밍에서 범용성이 떨어집니다. 먼저 네임맹글링의 표준이 없다는 이유하나로 컴파일된 오브젝트 화일은 다른 링커파일에서 처리하기 무척이나 어렵습니다. 이건 코드 수준인데 소스 수준의 문제도 야기합니다. 표준 C와 혼합을 할 필요가 있다면 일정한 키워드가 필요합니다. 하지만 네임 맹글링 자체의 표준이 없기 때문에 혼합하기 위한 사용한 키워드 역시 비표준입니다. 그 소스는 지극히 플랫폼 종속적이게 되지요. 이 문제를 피할 방법은 분명히 있을겁니다. 하지만 순수 C언어로 시스템 프로그래밍을 하는 것보다는 비용이 많이 들겠지요.

어플리케이션 프로그래밍에서 C++대신에 C를 선택하면 훌륭한 구조와 생산성, 유지보수를 잡을 방법은 분명히 있을겁니다. 하지만 대게는 C++보다 비싸게 먹히겠지요. 시스템 프로그래밍에서는 C++이 C보다 비싸니깐 현실적으로 안쓰는 것입니다. 현실을 무시하고서는 뱌네 스트로스트룹도 권위가 없을 것 같습니다.

PS: Bjarne Stroustrup의 발음 적으려고 무척이나 고심했습니다. Bjar-ne Strou-strup이 자신의 발음을 표기한것으로 BJ어디에도 강세가 없다고 하고 각각 2음절이라고 하니 이정도가 괜찮을 것 같습니다.

죠커의 이미지

corba wrote:

P.S : C++의 대체용 언어로 D언어가 마음에 들긴 합니다만. 시장성이 있을지 모르겠습니다.

D언어의 홈페이를 가봤지만 시장성없는 회사가 운영하는 페이지라서 자세히 살펴보지 않았습니다.

D언어를 아신다면 두가지 궁금한 점이 있습니다.

문법상으로 D언어는 C++의 superset입니까?
어떤 패러다임을 D언어는 가지고 있습니까? (작은질문:C언의 패러다임도 포함합니까?)

mastercho의 이미지

vacancy wrote:
여기서 C++의 단점에 대해 얘기하시는 분들은
일반적으로 알려져있는 C++의 단점들을 논하시는 것 같은데요.
단점이 아닌 걸 가지고 단점이라고 하시는 분은 별로 없는것 같은데,
설마 C++가 완전무결한 언어라고 생각하시는지요 ?

저는 완전 무결하다고 말한적이 없습니다
단점이라 생각할수 없는것이 단점이라 불린다고 했지요 [ 처음 글 쓰신분이
주장하던 단점을 잘 살펴 보시기 바랍니다]

제가 주장하는 바를 아직 이해 못하셨다니 조금 유감이긴 합니다
다시 비유를 들자면
"윈도우 서버만 거의 사용하던 관리자가 , 리눅스는 너무 세세하게 조작해야 하고 다루기 힘들어서 별로 좋지 않아, 모두 윈도우서버 로 대체하는게 좋을거 같다 ...."
는 주장과 별반 다를봐 없다고 생각합니다

리눅스를 좋아하고 잘 다루는분에게는 인정하기 힘든분이겠지요?
그렇다고 제가 C++를 아주 잘! 다루는건 아닙니다 [좋아한다고 다 잘 다룰순 없겠죠... :D ]

C++이 여기서는 리눅스가 되겠지요?

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

chunsj의 이미지

지적하신 문제는 정적인 언어에서만 보이는 문제점들입니다.(물론 정적인 언어
는 프로그래머에게 제공하는 편의를 희생하고 성능을 보장하기 위해서 그런
선택을 한 경우가 많습니다. Java는 아닌 것 같습니다만... Java는 더 많은
사람들이 쓴다는 이유로 C++식의 문법을 택하고 Smalltalk, Objective-C의
특징을 주로 채택을 했다고 (만든이가) 말했습니다만, 비판자들이 하듯이
가장 중요한 특징인 동적인 속성의 포기와 잘못된 문법의 선택으로 C++의
위차를 가지게 되었다고 볼 수도 있습니다. :-) 그런 언어상의 문제로 인해서
말씀하신 "트릭"을 구사할 필요가 있는 것입니다. 초기에 나온 Smalltalk을
기본으로한 OOP책이나 Pattern책을 보시면 제 말씀을 더 잘 아실 것이라
생각합니다. 그리고 상속은 추상화를 위해서 주로 사용되지만 기능의 통합을
위해서도 잘 사용됩니다. 물론 C++에서는 힘든 이야기 입니다. Collection
을 생각하시면 됩니다.

[quote="corba컴파일 타임을 위해서 결합도를 낮추는 것은 돌아가는 방법이기도 합니다만 일반적으로 좋은 디자인으로 가는 길이라고 생각합니다.

이것은 C++만의 문제가 아닌 객체지향 언어의 문제라고 생각합니다.

베이스 클래스의 private멤버가 바뀌면 C++에서 재컴파일만 필요하겠지만 pulbic멤버나 가상함수의 인터페이스가 바뀌게 되면서 발생하는 혼란은 어떤 객체지향 언어에서나 존재하는 문제가 아닐까 합니다.

이런 이유로 근대 객체지향 디자인에선 추상화 외의 상속은 자제하고 있다고 들었습니다.

seldom의 이미지

Quote:

PS: Bjarne Stroustrup의 발음 적으려고 무척이나 고심했습니다. Bjar-ne Strou-strup이 자신의 발음을 표기한것으로 BJ어디에도 강세가 없다고 하고 각각 2음절이라고 하니 이정도가 괜찮을 것 같습니다.

http://www.research.att.com/~bs/pronounciation.wav

본인이 직접 얘기하고 있습니다.
네이티브 발음은 비야네 스꽁스꾸(우?) 정도로 들리는군요.
영어로는 비야네 스트루스트럽 혹은 스트라우스트럽 이라고 합니다.
하지만 대부분 '비얀'으로 표기하는 걸로 알고 있는데 아마
우리말이 억양이 적기에 그것이 더 비슷하게 들리는지 모르겠습니다.

vacancy의 이미지

mastercho wrote:
제가 주장하는 바를 아직 이해 못하셨다니 조금 유감이긴 합니다
다시 비유를 들자면
"윈도우 서버만 거의 사용하던 관리자가 , 리눅스는 너무 세세하게 조작해야 하고 다루기 힘들어서 별로 좋지 않아, 모두 윈도우서버 로 대체하는게 좋을거 같다 ...." 는 주장과 별반 다를봐 없다고 생각합니다

리눅스를 좋아하고 잘 다루는분에게는 인정하기 힘든분이겠지요?
그렇다고 제가 C++를 아주 잘! 다루는건 아닙니다

C++이 여기서는 리눅스가 되겠지요?

C : C++ = Windows : Linux 내지는,
Java or C# : C++ = Windows : Linux 라는 말씀이신데요.

C++가 여타 Language들에 비해 오히려 Popular하고,
( 저도 C++로 코딩해야 할 일이 더 많습니다. :cry: )
C++의 단점이 '세세하게 조작해야 하며 다루기 힘들다'는 것도 아니고 한데
어떤 점에서 위의 비유가 성립되는 것인지 잘 모르겠네요.
( C++가 다른 Language들에 비해 어렵다고 생각하진 않습니다만. :( )

그리고 궁금한 점이 있는데요.
C++를 좋아하시고 잘 다루신다는 건 알겠는데요.
C로는 프로그래밍을 해보셨을 것 같고,
혹시 Java나 C#로도 프로그래밍을 해보셨는지요.

chunsj의 이미지

NeXTSTEP/OpenStep은 FoundationKit위에 AppKit이 사용자 어플리케이션
을 프로그래밍 하는 것을 가능하게 하는 구조로 되어 있습니다. 그러나
AppKit은 FoundationKit의 베이스 클래스의 기능을 확장하거나(Categorizing) 또는 덮어버리기도(Posing) 합니다. 그렇다고 해서
성능의 이상이 생기지는 않습니다. EOF, WebObjects도 마찬가지입니다.
당연히 Smalltalk에서 베이스 클래스에 인터페이스를 추가했다고
성능에 영향을 준다는 이야기는 못들었습니다.

요는 변화하지 않는 설계는 있을 수 없으며, 변화에 잘 적응을 할 것을 우선시
하느냐(ObjC) 성능을 위해서 적응력을 떨어뜨리고 필요하다면 새롭게 갈
것인가의 차이일 것 같습니다.

B. Cox가 비교한 대로 정적인 언어와 동적인 언어의 차이는 그냥 아기와
스키모양의 발을 가지고 태어난 아기의 차이와 같다고 생각됩니다. 스키
아기는 스키는 잘 타겠지만 눈길이 아니면 아주 힘들 인생을 살아야 할 것
이고, 그냥 아기는 스키를 스키 아기만큼은 못 타겠지만 필요한 환경에 따라
스키를 탈 수도 비행기를 탈 수도 있겠지요. :-)

pynoos wrote:
overloading과 overriding 문제에 있어서 전자는 naming mangling에 argument type을 encoding하고, 후자는 대개의 구현이 virtual function table로 되어 있는데, 이 table을 사용하는데 index를 취하여 interface를 만들고 있습니다.

vft를 사용하지 않는 방식으로 만들어지게 되면, 성능상 runtime function binding에 에 들어가는 비용이 많이 들어가게되고, 그다지 성능면에서 좋지 않게 됩니다.

과연 base가 바뀌는데 재컴파일이 필요하지 않으면서 성능문제도 괜찮은 설계가 있을 수 있을까요?

akbar의 이미지

...

죠커의 이미지

짧은 문장을 제가 잘못받아들여서 생기는 오류가 있을 것 같기 때문에 몇가지 질문을 던져봅니다.

akbar wrote:
네임맹글링 때문에 범용성이 떨어진다구요 그렇다면 네임맹글링을 안시키면 그만입니다.

이 부분에서 약간의 의문이 생깁니다. C++ 임플리먼트의 네임맹글링이 없는 C++은 C++의 반을 버리게 되는 것이 아닌가요?

extern "C"만이 표준일텐데 실제 프로젝트에서는 비표준적인 네임맹글링 제거법을 많이 보았습니다. 문법적으로 비표준적인 방법외에는 C++의 특성을 유지한채 C++ 임플리먼트의 네임맹글링을 제거하는 것은 불가능한것이 아닌가요?

그렇다면 C++은 적어도 네임맹글링의 이유로도 시스템 프로그래밍에 부적합한게 아닐까요?

vacancy의 이미지

akbar wrote:
복사생성자라든가 대입연산자중첩함수 등등 C++ 객체라면 보통 프로그래머가 재정의해서 쓰는 함수등은 아예 설계하지 않는다던가(디버그 모드에서는 둘 수 있겠죠), 가상함수를 아예 쓰지 않는다던가, STL 도 쓰지 않는다던가 하는 것들 말이죠. 그렇게 하면 실행코드도 C 나 거의 차이가 없죠.

네임맹글링 때문에 범용성이 떨어진다구요 그렇다면 네임맹글링을 안시키면 그만입니다.

네임맹글링을 안쓴다는 얘기는 overloading를 쓰지 않겠다는 얘기 같은데요.
overloading도 안쓰고 virtual function도 stl도 안쓰고 -_-; 하면,
C++에서 절반은 없는 셈 치는 것 같네요.
게다가 비표준이니 컴파일러든 무엇이든간에 추가적인 수정이 필요하고요.
( 이런 수정에 드는 비용도 적잖다고 생각합니다만. )

이쯤 되면 추가적인 비용을 감수하면서 C++를 쓰는 메리트가 없지 않나요. :?

sDH8988L의 이미지

오랜만에 좋은 토론인 거 같아서 기분 좋습니다...

물론, 몇몇 분들께서 감정적인 쪽으로 흐르는 것이 좀 그렇기는 하지만, 뭐... 평소에 많은 분들이 생각하지 않고 있는 이야기들이 나오는 것은 언제라도 좋다고 생각합니다...

가끔 생각해 보죠... 언어를 사용하면서 끊임없이 언어에 대한 생각을 하는 것이 아니고 그냥 타성에 젖어서 사용하고 있는 것은 아닌지요...

그런 의미에서 이런 식의 토론은 상당히 유익하다고 생각합니다...

그럼 이제 제가 하려던 이야기를 해야 겠네요...

물론, C++에 국한된 이야기는 아닙니다... 그냥 언어와 사용자의 관계에 대한 글이라고 생각해 주시면 좋겠네요...

위 글들 중에 '그런 식의 Code는 언어의 문제가 아니라 사용하는 사람들의 문제가 아니냐...' 라는 의견을 보이신 분들이 계셨습니다...
그러나 제 생각은 약간 다릅니다...
그런 비정상적인 사용법이 가능한 거 자체는 언어의 문제라고 생각합니다...

뭐... 다들 아시는 거 겠지만요...
예를 들어 초기에 C가 만들어 질 때는 위와 같은 개념이 약해서 Array의 Bound를 넘어가는 인자가 들어와도 어떻게 할 수가 없었습니다...Compile Time에는 Error가 나지 않고 실행중에도 요행히 Error가 안 날 수도 있습니다... 보통은 Sigmentation Fault가 나겠지만요... 그런 Code가 가능한 것이죠... 그러나 Java와 그런 수준의 언어들에서는 가능하면 Compile Time에 아니면 실행 중에도 Exception으로 잡아낼 수 있습니다...

이런 식으로 언어가 사용자에게 지원하는 환경이 사용자의 실수나 부주의한 사용으로 Program 전체의 동작에 피해를 줄 수 있는 부분이 크다면, 그걸 사용자의 문제라고만은 볼 수 없을 거라는 겁니다...

int i = 'hi'와 같은 Code를 사용하는 사용자도 문제지만, 그런 것이 가능한 거 자체가 더 문제 아니겠습니까???

비유하자면, 마치 법이 없는 세계에서 범죄를 저지르면 그게 무조건 범죄를 저지른 사람 잘못이라고 하는 것과 같은 거라고 봅니다...
이런 경우에 대락 법이 없는 사회가 문제라는 말이 더 많이 나오겠죠...

언어에서도 그런 부분은 있다고 봅니다...

예전에 C#이 처음 나왔을 때, Java 측과 MS 측에서 언어의 정의에 대해서 말이 많았습니다... 물론, 아직도 결정난 문제는 아니고 결정날 수 있는 사안은 아니라고 봅니다...

이런 문제였죠... Java에서는 Programmer가 'Explicitly' Pointer를 사용할 수 없습니다... 그건 Java를 만든 Architect들의 철학이 담긴 문제지요... Pointer의 Explicit한 사용이 많은 Program들을 오동작하게 하고 있으며, 짧은 시간에 끝낼 수 있는 Logic이 memory 관리로 인하여 길어지고 Logic에 집중하기 보다는 Memory 사용의 Debugging에 더 많은 시간이 투자되는 것을 원천적으로 봉쇄하자... 이런 식의 철학이죠...
그래서 Java에서는 Explicit한 Pointer의 사용이 없습니다...

그러나 C#의 경우 기본적으로는 Java와 같으나 특수한 경우에는 Pointer를 Explicit하게 사용할 수 있도록 하고 있습니다...

이런 C#의 정의에 대해서 한 쪽에서는 Bug를 만들어 낼 수 있는 정의다... 아니다 이건 좀 더 자유로운 사용을 위한 특수 Case다... 이런 식으로 열띤 토론이 있었습니다...

이와 같이 언어의 정의는 사용자와 나중에 생성된 Program의 질적인 측면에 있어서 상당히 중요한 부분입니다...

무조건 사용자의 사용에만 맡겨두고 나몰라라 할 수는 없는 것이라는 거죠...

뭐... 제 글이 처음 시작하신 분의 논지와 좀 어긋나는 점이 있다는 점은 인정하겠습니다... 하도 간만에 이런 논쟁이 있어서 저도 좀 참여 하고 싶은 마음이 들어서라고나 할까요...

실은 저는 Specific한 부분은 잘 모릅니다... ㅎㅎㅎ -____-

그럼 즐겁고 유익한 토론이 계속 되었으면 합니다...

pynoos의 이미지

저도 왠만하면 오래된 주제로 논쟁하는 것은 싫어 합니다만, 이 주제는 좀 건전하게(?) 흐르는 것 같아서.. 댓글 성격은 아니지만.. 토론할 거리를 던져주고자...
오브젝트 크기에 대해 얘기하자면..

C++ 로 작성하면 프로그램 크기가 커진다는 말에 경험을 얘기 하자면, 디버깅 심볼을 다 집어 넣었을 때, 10메가까지 되는 바이너리가 나오는 것을 본적이 있습니다. 같은 소스로 linux는 2메가정도였는데 hpux에서는 그정도 나오더군요.
물론 strip을 하면 1메가 이하로 줍니다. 놀랍죠.. 10메가 바이너리가 1메가도 안되는 본체를 가지고 나머지는 다 디버깅 정보라니.... 1메가가 안되는 바이너리도 상당한 크기임에는 부인할 수 없습니다.

특히 stl의 심볼길이가 워낙 길고, throw라도 쓸라치면, stack 청소하는 코드 들어가는 것 때문에 왠 함수를 종료하고서도 한참 코드가 붙는지 원...
멤버 뒤에 모든 코드에 throw () 를 붙이는 것도 참 꼴불견중에 하나입니다. 하지만 최적화를 위해서는 써야하는 것은 맞습니다.

c++로 개발은 하지만, exception handling을 잘 사용하지 않습니다. 물론 그놈은 코드를 상당히 이쁘게 만들어주는 역할을 합니다만...

그리고, g++ 2.95 버전에서의 exception이 완벽하지 않은 것으로 문서에 나와 더욱더 망설여지더군요.

(컴파일러에 -fno-exception 옵션을 넣어서 불필요한 코드 증가를 막습니다.)

C++가 시스템 프로그램이나 임베드 환경에도 적절하게 사용되려면, 컴파일러의 최적화와 더불어 오브젝트가 커지는 방법은 피해가며 최대한 코드를 작성해야한다고 생각합니다. 물론 그에 앞서 사이즈 작은 코드가 나오도록 컴파일러가 좋아져야겠지요.

C++의 상속과 예외등을 본격적으로 자유롭게 사용하여 설계한다면, 어플리케이션 수준에서 사용 도메인이 한정되지 않을까싶고, 오브젝트크기가 작은 분야에 쓰이려면, 설계방식에 따른 산출 코드량의 차이를 신중히 고려하지 않으면 어렵다고 보아집니다.

오브젝트 크기... 어쩔수 없죠... 비슷한 일을 C로 하려면 그만큼 귀찮고.. 그정도는 감수해야하지 않을까합니다. 결국엔... 늘 같은 주제로 끝나는 군요.. 필요한 곳에 가져다가 쓰라...

bh의 이미지

음냐,, gcc가 표준이 아니었나요?
그럼 표준은 대체 무엇인가요?
에겅,, 머리야,,

--
이 아이디는 이제 쓰이지 않습니다.

corba의 이미지

chunsj wrote:
지적하신 문제는 정적인 언어에서만 보이는 문제점들입니다.(물론 정적인 언어
는 프로그래머에게 제공하는 편의를 희생하고 성능을 보장하기 위해서 그런
선택을 한 경우가 많습니다. Java는 아닌 것 같습니다만... Java는 더 많은
사람들이 쓴다는 이유로 C++식의 문법을 택하고 Smalltalk, Objective-C의
특징을 주로 채택을 했다고 (만든이가) 말했습니다만, 비판자들이 하듯이
가장 중요한 특징인 동적인 속성의 포기와 잘못된 문법의 선택으로 C++의
위차를 가지게 되었다고 볼 수도 있습니다. :-) 그런 언어상의 문제로 인해서
말씀하신 "트릭"을 구사할 필요가 있는 것입니다. 초기에 나온 Smalltalk을
기본으로한 OOP책이나 Pattern책을 보시면 제 말씀을 더 잘 아실 것이라
생각합니다. 그리고 상속은 추상화를 위해서 주로 사용되지만 기능의 통합을
위해서도 잘 사용됩니다. 물론 C++에서는 힘든 이야기 입니다. Collection
을 생각하시면 됩니다.

베이스 클래스의 변경으로 인한 혼란은 정적언어만의 문제만은 아니라고 생각합니다. 단지 신경을 더쓴다면 C++같은 정적 언어에선 더 좋지 않을까 해서요.

저도 스몰톡을 조금씩 공부하고 있긴 합니다만 하수라서... :oops: 하지만 패턴에 관한 제 느낌은 필요 이상의 상속은 자제하고 있어서 멋지다... 라는 생각이 듭니다. 실제 GOF패턴들을 보면 가상함수를 통한 상속이 80%인거 같더군요.

그리고 상속에 의한 기능통합의 경우 단일상속만 지원하는 언어의 경우는 오히려 컴포지션이 받쳐주지 않으면 기능통합이 힘들지 않나 생각되구요. 뜻밖에도 C++에서 템플릿과 함께한 다중상속(소스를 보는 사람 입장에선 최악의 조합이죠 :wink:)이 효율적이더라구요.

음... 얘기가 길어진것 같지만 초창기의 OOP와 현재를 비교해서 변천과정을 지켜 보는 것도 꽤나 재밌을듯 합니다.

P.S : 이 토론 주제가 상당히 마음에 듭니다. 지나치게 감정적으로 빠지지 않으면서 좋은 내용들이 많이 올라오고 있는거 같아요. 여러 고수분들의 의견이 많은 도움이 되고 있습니다.

mastercho의 이미지

이번것은 바로... 의도 한 바는 아니지만 :oops:

제가 원래 토론다운 토론을 하는것 자체가 KLDP의 주된 활동이긴 합니다

어째튼 긍정적인 토론으로 간다니 다행이라는 생각이 드네요

[생각보다 많은 재미난 정보가 공개가 되지 않았나요 ? ^^]

이 주제의 열의가 꺼지면

다른 주제를 가지고 토론을 해볼려고 합니다 :)

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

익명 사용자의 이미지

자바에서는 베이스 클래스가 변경되는것의 심각성에 대해 약간의 장치는 있습니다. (다른 언어는 안다뤄봐서 잘 모르겠습니다.)

개개의 클래스 파일들은 실행시에 실제 클래스와 바인딩되므로 베이스 클래스가 바뀌었다고 연관된 모든 클래스를 새로 컴파일할 필요는 없습니다.
실행시점에 메소드가 없는 경우 예외가 발생하고 이 예외는 잡아낼 수는 있습니다. (그러나 베이스 클래스의 메소드가 사라지는것까지 처리하는건 많은경우 무의미하죠.. 베이스 클래스가 바뀌는건 설계에 심각한 오류가 있다고 생각됩니다.)
메소드를 삭제할 필요가 있으면 일단 @deprecated 를 붙이면 됩니다. 기존 클래스들의 수행에는 문제가 없지만 새로 컴파일하는 모듈은 컴파일시 경고가 발생하지요.
어느날 갑자기 없애는것이 아니라 언젠가 없어질테니 지금부터는 쓰지 말아라 라고 지시하는게 가능하며 이는 여러사람이 개발할때 유용하게 사용될 수 있습니다.
(언젠가 삭제할 메소드라고 당장 삭제해 버리면 해당 메소드를 참조하는 많은 모듈을 즉시 뜯어 고쳐야 하며 이는 개발일정에 차질을 줄 수밖에 없습니다. 삭제할 메소드는 일단 표시만 해두고 차후 일정을 잡아서 한꺼번에 뜯어 고치는 쪽이 좀 더 효율적으로 진행되지 않을까 생각됩니다.)

chunsj의 이미지

맞습니다. 필요이상의 상속은 "악"입니다 :-) 그러나 필요할 때 못하는 것도
"악"이죠. 그리고 말씀하신대로 다중 상속이 "기본"에서는 되지 않은
언어의 경우에는 구현의 통합은 안됩니다.(구현의 통합은 다중 상속을 통해서
만 되는 것으로 알고 있습니다.) 그러나 인터페이스의 통합은 가능합니다.
그리고 Smalltalk의 경우에는 다중 상속이 가능하도록 할 수도 있습니다.
(심지어는 Java의 Interface, ObjC의 Protocol같은 것도 가능합니다.)
가상함수의 경우에는 정적인 C++의 특징인데(정적인 바인딩) 제가 알기론
C++에서의 가상함수는 효율이 떨어지는 것으로 알고 있습니다. 가상함수를
많이 써야 되는 구조라면 ObjC를 사용하는 것이 더 낫습니다.(이건 제 경험
입니다. 그리고 Budd의 책에서도 볼 수 있듯이 다른 문제들, 메모리,
테이블 참조 시간등의 증가 및 기타...의 안좋은 점도 있습니다.)

처음 OOP는 동적이며 적응성에 중점을 둔 것으로 시작 된 것 같습니다.(물론
Simula와 같은 것들도 있었지만 논외로 하고....) 그러다가 C++이 나오면서
(이게 Simula의 영향을 많이 받은 것 같습니다. 아마 OOP보다는 더 좋은
C에 목표가 있었기 때문이겠지요.), 정적인 검사에 중점을 두는 쪽의 방향도
나오게 된 것 같습니다.

corba wrote:
chunsj wrote:
지적하신 문제는 정적인 언어에서만 보이는 문제점들입니다.(물론 정적인 언어
는 프로그래머에게 제공하는 편의를 희생하고 성능을 보장하기 위해서 그런
선택을 한 경우가 많습니다. Java는 아닌 것 같습니다만... Java는 더 많은
사람들이 쓴다는 이유로 C++식의 문법을 택하고 Smalltalk, Objective-C의
특징을 주로 채택을 했다고 (만든이가) 말했습니다만, 비판자들이 하듯이
가장 중요한 특징인 동적인 속성의 포기와 잘못된 문법의 선택으로 C++의
위차를 가지게 되었다고 볼 수도 있습니다. :-) 그런 언어상의 문제로 인해서
말씀하신 "트릭"을 구사할 필요가 있는 것입니다. 초기에 나온 Smalltalk을
기본으로한 OOP책이나 Pattern책을 보시면 제 말씀을 더 잘 아실 것이라
생각합니다. 그리고 상속은 추상화를 위해서 주로 사용되지만 기능의 통합을
위해서도 잘 사용됩니다. 물론 C++에서는 힘든 이야기 입니다. Collection
을 생각하시면 됩니다.

베이스 클래스의 변경으로 인한 혼란은 정적언어만의 문제만은 아니라고 생각합니다. 단지 신경을 더쓴다면 C++같은 정적 언어에선 더 좋지 않을까 해서요.

저도 스몰톡을 조금씩 공부하고 있긴 합니다만 하수라서... :oops: 하지만 패턴에 관한 제 느낌은 필요 이상의 상속은 자제하고 있어서 멋지다... 라는 생각이 듭니다. 실제 GOF패턴들을 보면 가상함수를 통한 상속이 80%인거 같더군요.

그리고 상속에 의한 기능통합의 경우 단일상속만 지원하는 언어의 경우는 오히려 컴포지션이 받쳐주지 않으면 기능통합이 힘들지 않나 생각되구요. 뜻밖에도 C++에서 템플릿과 함께한 다중상속(소스를 보는 사람 입장에선 최악의 조합이죠 :wink:)이 효율적이더라구요.

음... 얘기가 길어진것 같지만 초창기의 OOP와 현재를 비교해서 변천과정을 지켜 보는 것도 꽤나 재밌을듯 합니다.

P.S : 이 토론 주제가 상당히 마음에 듭니다. 지나치게 감정적으로 빠지지 않으면서 좋은 내용들이 많이 올라오고 있는거 같아요. 여러 고수분들의 의견이 많은 도움이 되고 있습니다.

mastercho의 이미지

chunsj wrote:
제가 알기론
C++에서의 가상함수는 효율이 떨어지는 것으로 알고 있습니다.

제가 알기론 자바나 C#이라고 해도 C++의 가상함수의 동작방식과
별반다를봐 없다고 생각이 되는데요?
[다른 언어들 역시 파생 클래스를 위해 내부적으로 함수포인터를 가진다고 봐지는데요?]

자바 같은 경우 오히려 무조건 가상함수가 되는게 아닌가 싶습니다
[더 비효율적으로 보이죠]

추측밖에 할수 없다면 제 가설은 C++에서 파생된 언어들은 결국
C++의 방법과 별반 다를봐 없다는것입니다

C++의 가상함수보다 더 빠르게 동작하는 메커니즘을 알고 계시는지요?

이런 상속구조에서는 어차피 이방법밖에 없다는 생각이 드네요

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

ddoman의 이미지

위에서 C++은 C로 시스템 프로그래밍을 고집하는 사람을 위해나왔다는 말과
그에 관한 글을 여러 댓글도 읽었습니다만,

다른글을 찾아보다가 그와 관련된 언급이 있어 첨부합니다.

뭐..지금 주제는 약간 다른쪽으로 흘러가는거 같지만...
암튼 생각나는김에...^^..첨부

http://bbs.kldp.org/viewtopic.php?t=20960&highlight=%B8%B6%C0%CC%C5%A9%B7%CE+%C4%BF%B3%CE
위글을 보면 솔라리스 수석 엔지니어와의 대화내용이 올라와있는데,

7. 30 years after UNIX was recoded in C, most people still use C (or in some cases a little bit of C++) for the OS kernel. Is C perfectly adequate, or do they see some of the newer languages (C#, Java, or even modern C++ paradigms) being applied to OS design?

Andy Tucker: 이 분야에서 다양한 실험이 있었습니다. 예를 들면 썬은 C++ (SpringOS)와 자바(JavaOS)로 운영체제를 만들었습니다. 오브젝트 오리엔티드 언어가 고수준 프로그래밍 추상화를 위한 쉬운 개발의 관점에서 보면 장점이 많지만 OS 커널 개발에도 그만한 혜택을 주는 것은 아닙니다. 커널은 하드웨어와 가장 직접적으로 상호 작용하는 소프트웨어이기 때문에 메모리 재활용(garbage collection)과 템플릿 등의 쉬운 개발을 위한 기능보다는 언어와 기계의 명령(instruction) 사이에서 간단하게 사상(map)되는 데서 얻는 이익이 더 큽니다. 언어 의존적이고 광범위한 런타임 지원 요구도 있습니다. 대신 오브젝트 오리엔티드 언어의 개념(예: 다형성)을 빌리거나 비-OO 언어(C)로 그것을 구현하는 방법을 찾기도 합니다.

위와 같은 부분이 있네요~

vacancy의 이미지

mastercho wrote:
chunsj wrote:
제가 알기론
C++에서의 가상함수는 효율이 떨어지는 것으로 알고 있습니다.

제가 알기론 자바나 C#이라고 해도 C++의 가상함수의 동작방식과
별반다를봐 없다고 생각이 되는데요?
[다른 언어들 역시 파생 클래스를 위해 내부적으로 함수포인터를 가진다고 봐지는데요?]

자바 같은 경우 오히려 무조건 가상함수가 되는게 아닌가 싶습니다
[더 비효율적으로 보이죠]

추측밖에 할수 없다면 제 가설은 C++에서 파생된 언어들은 결국
C++의 방법과 별반 다를봐 없다는것입니다

C++의 가상함수보다 더 빠르게 동작하는 메커니즘을 알고 계시는지요?

이런 상속구조에서는 어차피 이방법밖에 없다는 생각이 드네요

Performance 적인 측면은 어차피 Java나 C#보다는 빠를테니
굳이 언급할 필요는 없을것 같습니다.
저도 Java에서 상속시 모든 함수가 Virtual Function이 되는 것이 다소 불만입니다만,
Object Pascal이나 C#에서는 그렇지 않죠.
( 같은 사람이 기획한 언어들이라서 그런진 모르겠습니다만, C#은 C++보다는 Object Pascal과 유사점이 많습니다. )

그리고 C++의 다중상속과 Java/C#/Object Pascal의 다중 상속은
확실히 다르다고 생각하는데요.
물론 C++에서 Java/C#/Object Pascal처럼 쓰는 것은 가능하겠습니다만.
예를 들면 C++에서는 Variable들도 다중 상속이 가능하죠.
특히 같은 Name을 가지는 Variable들의 다중 상속은 좀 보기 싫잖나요. -_-;
( 사용자가 쓰기 나름이라고 하시면 이 역시 할말이 없겠습니다만. )
제가 보기엔 Class-Interface model인 Java/C#/Object Pascal 쪽이
좀더 보기 좋다고 생각합니다.

그리고 C++가 Java나 C#에 영향을 많이 주긴 했지만,
Java나 C#이 C++로부터 파생되었다는 말은 다소 과한 것 같네요.

errai의 이미지

중간쯤에 나온 시스템프로그래밍에서의 C or C++에 대해 조금 코멘트를
달겠습니다. 저는 C, C++ 둘다 편견없이 사용하고 있습니다.

Device Driver를 C++로 만들고 싶다고 할때 그는 OOP와 encapsulation의
장점을 이용한 프로그래밍을 하고 싶은 것이겠죠. 하지만 이에 따라 발생 할
수 있는 단점으로 위에 여러분들이 이야기 하셨던 C++를 잘 모름에 있어서
생기는 보이지 않는 overhead가 있겠지요. virtual function 문제라든지
copy constructor 등등. C++이라는 무기를 사용하기 위해서는 일정이상
의 무기 숙련도가 필요한것이라고 생각하면 됩니다. 문제 해결 방법은 inline
keyword를 적절히 사용하고, virtual function도 그 함수를 많이 호출하지만
않으면 성능상에 문제는 없습니다. 이들에 대해서 명확히만 알고 대처할 수
있다면 C보다 우수한 type checking 이라든지 syntax나 OOP 코딩 테크닉
을 이용한 시스템 프로그래밍을 할 수 있을 것입니다. STL을 쓸 수 없다?
Kernel level에서 사용할 수 있도록 포팅된 STL도 있습니다.
(물론 돈주고 사야겠죠)

누가 뭐라 해도 난 C++이 싫다. 이럴때는 그냥 C를 쓰면 됩니다.
C를 쓰나 C++을 쓰나 성능은 프로그래밍 하는 사람의 내공에 달려있는
것입니다. C로 시스템 프로그램을 만드는 사람이 C++로 만든 사람에게
"넌 왜 그런 거지같은 언어로 만들고 있냐?" 라고 하면 보여주십시오. 그
사람이 C로 코딩한 프로그램 보다 더 간결한 디자인에 더 빠르게 동작하
는 모습을. 물론 그 반대의 경우도 성립합니다. :)

chunsj의 이미지

음... Java의 경우는 모르겠습니다만, ObjC는 C++와 다른 방법을 씁니다.
자세한 기술적인 내용은 Brad Cox의 논문이나 책을 보시면 되는데
C++은 가상 함수가 주가 아니기 때문에(수가 작을 것이라고 생각하고)
그 구현이 쉽지만 효율이 떨어지는 방식을 쓰고 있고, ObjC의 경우에는
모든 메시지가 동적인 바인딩을 하기 때문에 다른 방식을 씁니다. C++식으로
하면 그 테이블만으로 메모리를 다 채우고 말겠죠...

mastercho wrote:
chunsj wrote:
제가 알기론
C++에서의 가상함수는 효율이 떨어지는 것으로 알고 있습니다.

제가 알기론 자바나 C#이라고 해도 C++의 가상함수의 동작방식과
별반다를봐 없다고 생각이 되는데요?
[다른 언어들 역시 파생 클래스를 위해 내부적으로 함수포인터를 가진다고 봐지는데요?]

자바 같은 경우 오히려 무조건 가상함수가 되는게 아닌가 싶습니다
[더 비효율적으로 보이죠]

추측밖에 할수 없다면 제 가설은 C++에서 파생된 언어들은 결국
C++의 방법과 별반 다를봐 없다는것입니다

C++의 가상함수보다 더 빠르게 동작하는 메커니즘을 알고 계시는지요?

이런 상속구조에서는 어차피 이방법밖에 없다는 생각이 드네요

crimsoncream의 이미지

c++로 그것도 oo로 만들어진 디바이스드라이버라.
꼭 보고싶은데요. 공개된 것이 있다면 꼭 좀 알려주셨으면 합니다.
제 생각에는 oo가 하드웨어적으로 완전히 표준화가 됐거나 드라이버개발자가 스펙을 정하는 디바이스거나 efi처럼 표준적인 인터페이스를 가진 layer 위에서가 아니면 장점을 가지지 못할 거라고 생각되는데요. 이 경우조차도 가벼운 c가 좀 더 괜찮을 것 같은데.
c++이 무겁다는 건 실행속도나 memory footprint만을 말하는 건 아니고요. 위에 어떤 분이 쓰신 인터뷰에서처럼 개념적으로 디바이스와의 mapping이 간결하다는 의미에서 c가 더 가볍다는 겁니다. 물론 탁월한 c++프로그래머에겐 이것이 작은 차이이겠지만 제 주위에는 그런 경우가 없어서 정말 보고 싶군요.

errai wrote:
중간쯤에 나온 시스템프로그래밍에서의 C or C++에 대해 조금 코멘트를
달겠습니다. 저는 C, C++ 둘다 편견없이 사용하고 있습니다.

Device Driver를 C++로 만들고 싶다고 할때 그는 OOP와 encapsulation의
장점을 이용한 프로그래밍을 하고 싶은 것이겠죠. 하지만 이에 따라 발생 할
수 있는 단점으로 위에 여러분들이 이야기 하셨던 C++를 잘 모름에 있어서
생기는 보이지 않는 overhead가 있겠지요. virtual function 문제라든지
copy constructor 등등. C++이라는 무기를 사용하기 위해서는 일정이상
의 무기 숙련도가 필요한것이라고 생각하면 됩니다. 문제 해결 방법은 inline
keyword를 적절히 사용하고, virtual function도 그 함수를 많이 호출하지만
않으면 성능상에 문제는 없습니다. 이들에 대해서 명확히만 알고 대처할 수
있다면 C보다 우수한 type checking 이라든지 syntax나 OOP 코딩 테크닉
을 이용한 시스템 프로그래밍을 할 수 있을 것입니다. STL을 쓸 수 없다?
Kernel level에서 사용할 수 있도록 포팅된 STL도 있습니다.
(물론 돈주고 사야겠죠)

누가 뭐라 해도 난 C++이 싫다. 이럴때는 그냥 C를 쓰면 됩니다.
C를 쓰나 C++을 쓰나 성능은 프로그래밍 하는 사람의 내공에 달려있는
것입니다. C로 시스템 프로그램을 만드는 사람이 C++로 만든 사람에게
"넌 왜 그런 거지같은 언어로 만들고 있냐?" 라고 하면 보여주십시오. 그
사람이 C로 코딩한 프로그램 보다 더 간결한 디자인에 더 빠르게 동작하
는 모습을. 물론 그 반대의 경우도 성립합니다. :)

오늘 우리는 동지를 땅에 묻었습니다. 그러나 땅은 이제 우리들의 것입니다.
아직도 우리의 적은 강합니다. 그러나 우리는 그들보다 많습니다.
항상 많을 것입니다.

페이지

댓글 달기

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
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.