영향력있는 사람들의 OOP에 대한 평가들.

프로그래밍 일반에 관한 포럼입니다.

Moderator: 류광

Locked
비회원

제 생각은 그렇습니다...

Post by 비회원 »

그건 MFC 의 문제이지 C++ 의 문제가 아닙니다. 본래 글은 OOP 의 문제를 C++만의 문제로 끌어오셨던 같고 지금의 비원님께서는 MFC 를 문제를 C++ 로 끌어오신던거 같습니다.

MS 도 이러한 MFC 의 진입 장벽에 대한 문제를 고민했습니다. (당연히..)
.NET 프레임워크를 소개하기 위한 그래프로, 기간에 따른 숙련도를 그래프로 보여줬는데....

MFC 는 처음에는 거의 배우는 것이 없다가 어느 시간에 가서 갑작스럽게 숙련도가 높아지는 계단형 그래프로 표기를 했습니다. 반면 .NET 은 그것을 최대한 일직선이 되도록 방향을 잡은 것이지요.

여하튼, MFC 의 문제점은 MS 도 개선하려고 노력했던 부분입니다. C++ 과는 전혀 관계가 없습니다.(C# 은 MFC 가 없는걸로 알고 있습니다. - 틀리다면 지적해주세요 - 애당초 MFC 의 문제를 개선한 .NET 프레임으로 시작한 것인데... 그걸 언어적 비교로 비교를 하시면 좀 곤란할 것 같습니다.)
그 부분에 있어서 알려드리자면 MFC의 진입장벽에 대한 이야기가 아니라 다른 플랫폼
으로 옮겼을 때 지식이 0으로 리셋된다는걸 의미한다는 그래프였습니다. 즉 VB를 하다가
MFC를 하면 단지 언어가 바뀌었음에도 불구하고 기존 지식은 거의 제대로 써먹을 수가
없었죠. 그래서 닷넷 플랫폼이 나온 이유중에 하나가 그 지식을 리셋하지 않고 점진적으로
나아갈 수 있다는게 핵심이었습니다. 이건 닷넷 플랫폼 만든 사람한테 들은겁니다. :^)



C++ 빌더는 UI만들때 아주 좋다고 합니다
하지만 , 여기서 C++ 빌더의 장점이 , C++ 언어가 좋아서 그런것일까요? 아님 라이브러리가 좋아서 일까요?
C++의 자유와 더불어 툴이 좋았습니다. VB는 툴은 좋았는데 자유가 없었지요.


책임과 비용

일단 이 책임에 대해 곰곰히 생각해 보면, 도구(언어, 실천 방법) 사용자의 비용 문제로 이어집니다. 즉 다중패러다임을 표방하는 C++에 학습 비용이 크다고 불평합니다. 하지만 다른언어도 생각해보면 OOP의 실천방법을 알아야 하는 비용은 똑같습니다.
OOP 디자인중 중복된것을 일반화해 보급된 Pattern이라는 것이 있습니다. 이것도 모르면 실천할수 없는 도구입니다(물론 몰라도 경험에 따라 자연스럽게 쓰고있는 경우도 많습니다). 여기서 OOP를 실천하는 도구들(Pattern, Refactoring등)을 활용하는데에는 비용이 따른다는것을 알수 있습니다. 다른 언어라고 비용이 따르지 않을까요? C++이 OOP의 실천방법들을 사용자가 수행하는데 어떠한 제약을 가하고 있지 않는다는점에서 위의 인용부분을 공감하기 힘듭니다. 무엇이 허술한것 일까요.
사실 패턴은 언어에 아주 많이 종속적입니다. 만일 언어에서 패턴을 지원하면 특별히 그 패턴을 구현하기 위해서 해주어야 할 것이 없지요. 그래서 C++이 요새 나온 다른 언어들에 비하면 불편한것이 사실입니다. 즉, 이 말은 비용은 따르지만 C++과는 상당한 차이가 날 수도 있습니다. (C#으로 옵저버 패턴 구현하는 것과 C++로 구현하는데 최소 2배 이상의 시간 차이가 걸립니다. 단순히 타이핑으로 쳐도 말이죠.)

앞의 몇 분의 지적에서 암시되어 있듯이 C++에 공통 조상(common ancestor)이 없다.라는 말은 좀 부정확한 표현이고(원한다면 예를 들어 class Object {..} 하나 만들면 되므로) 좀 더 구체적으로 말하면 다음 두 가지 중 하나일 것입니다.

1. 언어 자체의 내장 공통 조상 클래스가 없다. (이는 이를테면 int는 없어야 하며 대신 Object::Int 같은 것이 있어야 한다 같은 주장과도 관련이 있겠습니다.)

2. 단일한 공통 조상에서 시작하는 단일한 클래스 계통구조(hierarchy)를 가지는 표준 클래스 라이브러리를 제공하지 않는다.

이 두 가지 제약이 C++에서 OOP를 하는데 어느 정도나 걸림돌이 되는지를 각각 구체적으로 논의해 보면 좋을 것 같습니다.
공통 조상은 필요에 따라 없으면 만들어서 넣고 언어에서 제공하면 (C#이나 자바) 그냥 쓰면 됩니다. C++은 없으니 필요에 따라 구현해서 쓰면 됩니다. 그리고 경험상 C#으로 코딩할 때 상당히 유용하게 써먹을 수가 있었습니다. 예를 들자면 객체의 해쉬 코드를 얻을 때, 문득 "이 객체가 아까 그 객체인지 어떻게 체크하지?"와 같은 질문이 생겼을 때 그냥 해쉬 코드로 비교해주면 끝입니다. 물론 C++에는 없으니 구현해서 써야겠지요. :^)
그리고 성능으로 치자면 아주 미세한 수준입니다. 차기 C++에서 언어 수준으로 제공되면 아주 편할것 같습니다.

- 물론 그럴 가능성은 거의 제로라고 보입니다.


"OOP를 실천하는 도구들(Pattern, Refactoring등)" 이라고 하셨는데 Refactoring 은 외부에 영향을 주지 않고 코드를 개선하는 방법일 뿐, OOP 와 별다른 관계가 없다고 봅니다. 물론 'OOP 코드 역시 Refactoring 으로 개선할 수 있다' 정도의 관계는 성립하겠습니다. Pattern 에 대해서는... 제가 Pattern 을 바라보는 시각은 OOP 를 실천하는 도구가 아니라 그저 "몇몇이 모여서 남들이 잘 써오고 있던 일반적인 문제 해결 방법들에 - 자기들 마음대로 - 이름을 붙여놓은것" 입니다. 그래서 "OOP 디자인중 중복된것을 일반화해 보급된 Pattern이라는 것" 이라는 문장, 특히 "보급" 이라는 단어는 적절한 표현이 아니라고 생각합니다. 아, '이름을 보급했다' 라는 관점에서는 적절한 표현일 수 있겠습니다. :)
맞습니다. 1~20년 지나고 보면 웃음만 나오는 분도 계실겁니다. 프로그램 만드는데 패턴과 리펙토링이 꼭 필요한것이 아닙니다. 리펙토링은 이미 모든 프로그래머가 써온것이었고, 패턴도 이미 쓰고 있던겁니다. 유용한 도구임에는 확실하나 그 이상은 아닙니다.

제가 C++ 에 대해 이야기 하는것은 '필요 이상으로 프로그래머에게 많은것을 요구한다' 라는것입니다. (그리고 그런 노력으로 얻게 된 것들중 많은 부분들이 'C++ 에서 한발자국만 벗어나면 쓸모없는 노력과 경험이 된다' 라는 것이 불쾌합니다.) 이것은 '성능을 위해서는 수고를 감수해야 한다' 라는 일반론으로 해명될만한 수준이 아닙니다. 성능을 위해서 10 의 노력만 기울여도 충분할것을 C++ 은 100의 노력을 요구하고 있으니까요. '선택의 자유를 준다' 라는 옹호도 저는 부당하다고 봅니다. 저에게는 운동장에 비행기 부품을 늘어놓고 '이제 당신은 날 수 있다' 라고 말하는 것과 다를바 없다고 느껴집니다.
그래서 닷넷 플랫폼이 나왔습니다. 물론 여전히 C++은 어렵습니다. 저도 C++을 좋아하진 않지만 가장 즐겨쓰는 언어입니다. 제가 생각하기에 C++이 사용되는 이유는 딱 하나입니다. 프로그래머는 자유를 원하지만 다른 언어에 비해서 C++이 그나마 자유가 있기 때문입니다.

필요 이상으로 많은것을 요구한 만큼 , 그 만큼 제값을 한다고 생각합니다
그리고 C++ 한발자굳만 벗어나면 쓸모없는 노력과 경험이라는 건, 극단적인 비약을 하신거라 생각합니다

C++를 배워서 파이썬, 루아, 자바를 배울때 도움이 됐었고 , C++의 로우레벨적인 요소때문에
다른 언어의 구현 내부도 예측가능하게 되었습니다

[여러 언어를 배우는 목적중에 , 다른 언어의 방식으로 문제를 해결할수 있는 방법을 배우는것이 큰데
C++의 다양한 해결방식은 , 문제 해결 방식의 폭도 더 키워줄수 있다고 생각합니다 ]
파이썬을 배우고 싶으면 파이썬을 배우면 되는 것이고 자바를 배우고 싶으면 자바를 공부하면 됩니다. 어려운 C++을 해서 다행히(?) 파이썬도 쉽게 배우고 자바를 쉽게 배웠기 때문에 C++에 쏟은 내 노력이 아깝지 않다. 라는건 저같은 사람에게는 이해하기 힘듭니다. C++때문이 아니라 본인께서 득도(?)를 하신것이고 많은 고민을 통해서 언어를 바라보는 시각이 달라진 것이지 C++에서 배웠던 지식이 파이썬이나 자바를 공부할 때 도움이 된다는 것은 말이 안됩니다. 예를 들어서 C++에서 배웠던 const자리에 따른 값상수, 주소상수 구분법 같은건 솔직히 공부하면서도 웃겼습니다. 그리고 로우 레벨에 대한 것은 C++은 아무것도 가르켜 주지 않습니다. C++은 프로그래밍 언어이고 로우 레벨에 대한 것은 그 관련 분야를 C++언어로 작성하면서 터득했기 때문입니다. 그러므로 C++과는 아무런 관련이 없습니다.

특정 상황에 맞는 가장 적합한 도구를 선택해야지 C++이 만능이 아닙니다
맞습니다. 이것만 알면 지금 이렇게 서로 길게 말하지 않고 프로그램 만들 시간을 벌 수 있었을 겁니다. 솔직히 지금 시간 아깝지 않나요... (저도 아깝습니다.)
류광
Posts: 3805
Joined: 2001-07-25 09:00
Location: GPGstudy
Contact:

Re: 영향력있는 사람들의 OOP에 대한 평가들.

Post by 류광 »

Testors wrote: 확장을 위해서 상속, 위임, 결합도, 그리고 계층등에 관해 고민해야 한다고 하셨는데 C++ 이 아닌 일부 언어에서는 확장이 필요하다면 그저 mix-in 을 이용하면 그만입니다. 객체의 관계가 중요할까요? duck typing 에 대해서는 어떻게 생각하시는지요? duck typing 에서는 객체의 타입이나 관계따위에 신경쓰지 않습니다. 개와 고양이가 이종교배해서 태어난 녀석이 꽥꽥 울고 뒤뚱거리며 걷는다면 그냥 그걸 오리라고 간주해 버리니까요. 참고로 duck typing 을 기저에 깔고 있는 Ruby 는 "Pure Object Oriented Programming Language" 라고 평가받습니다. 류광님의 "오히려 C++에서는 템플릿 덕분에 그런 거대한 상속 구조를 둘 필요가 없다는 점을 장점으로 칩니다." 라는 글을 곱씹어 보시기 바랍니다.
현실적으로 개와 고양이의 이종교배는 불가능합니다. C++은 그런 사악한(^^) 프로그램을 컴파일 시점에서 미리 잡아낼 수 있는 능력에 중점을 두고 있다고 할 수 있습니다. 그리고 그런 능력은 다른 언어에서도 바람직한 경우가 있습니다. 예를 들어 Python의 Rails라 할 수 있는 Django에는 이런 코드가 있습니다. ( http://code.djangoproject.com/browser/d ... ginator.py )

Code: Select all

 def validate_page_number(self, page_number):
        try:
            page_number = int(page_number)
        except ValueError:
            raise InvalidPage
        if page_number < 0 or page_number > self.pages - 1:
            raise InvalidPage
        return page_number
try - except 부분은 C++이라면 그냥 validate_page_number(self, int page_number): 로 해결될 문제입니다. unsigned int로 한다면 if 문의 page_number < 0 역시 생략할 수 있고요.

자신의 프로그램에서 이런 점검이 얼마나 필요한가는 역시 통계적인 문제일 것입니다. "특정 상황에 맞는" 이라는 언급이 적용되는 부분이기도 하고요. 크게는 지금 하는 일이 시스템 프로그래밍에 가까운지 최종 응용 프로그래밍에 가까운지가 중요한 기준이 될 것입니다. 예를 들어 mix-in이나 소위 monkey patching 등은 최종 응용 프로그래밍에서는 아주 강력한 도구가 되겠지만, 유연함보다는 정확성이 더 중요한 시스템 프로그래밍에서는, 그리고 협동적인 개발에서는 커다란 혼란을 야기할 수 있습니다. 지금 보고 있는 이 클래스가 내가 알고 있는 그 클래스인지 확신할 수 없으니까요.... (이런 비판은 Rails 커뮤니티 내부에서도 제기되었다고 알고 있습니다.)

그리고 Testors님의 100의 노력 대 10의 노력 관련 언급에 대해서는.... 과도한 일반화가 아닐까요? 그런 부분이 대다수인지 소수인지 과반수인지 등을 어느 정도는 구체적인 사례를 제시하면서 이야기하지 않는다면 논의가 계속 이어지기 힘들 것 같습니다.

한편으로 이 부분은 다른 사람들이 10의 노력만으로 일을 할 수 있도록 90의 노력을 미리 들이는 사람이 될 것인가라는 좀 더 개인적인 질문으로도 이어질 것입니다.

그리고
비회원 wrote:
특정 상황에 맞는 가장 적합한 도구를 선택해야지 C++이 만능이 아닙니다
맞습니다. 이것만 알면 지금 이렇게 서로 길게 말하지 않고 프로그램 만들 시간을 벌 수 있었을 겁니다. 솔직히 지금 시간 아깝지 않나요... (저도 아깝습니다.)
만일 이 논의가 그런 일반론으로 끝난다면 정말로 시간 낭비일 것입니다. 다행히 지금까지는 그렇지 않았다고 봅니다.
비회원

흥미롭네요.

Post by 비회원 »

어려운 C++을 해서 다행히(?) 파이썬도 쉽게 배우고 자바를 쉽게 배웠기 때문에 C++에 쏟은 내 노력이 아깝지 않다. 라는건 저같은 사람에게는 이해하기 힘듭니다. C++때문이 아니라 본인께서 득도(?)를 하신것이고 많은 고민을 통해서 언어를 바라보는 시각이 달라진 것이지 C++에서 배웠던 지식이 파이썬이나 자바를 공부할 때 도움이 된다는 것은 말이 안됩니다. 예를 들어서 C++에서 배웠던 const자리에 따른 값상수, 주소상수 구분법 같은건 솔직히 공부하면서도 웃겼습니다. 그리고 로우 레벨에 대한 것은 C++은 아무것도 가르켜 주지 않습니다. C++은 프로그래밍 언어이고 로우 레벨에 대한 것은 그 관련 분야를 C++언어로 작성하면서 터득했기 때문입니다. 그러므로 C++과는 아무런 관련이 없습니다.
const 위치에 따란 상수 구분이 왜 웃겼는지 개인적으로 궁금합니다. 저는 굉장히 감동 받았거든요.

로우 레벨에 대한 것이 C++이 아무것도 가르켜 주지 않았고 단지 C++로 작성하면서 터득했기에 C++과 아무런 관련이 없다라고 하시는 건 괴변이라 생각이 듭니다. C++ 아무 것도 가르쳐 주지 않지도 않았겠지만 그렇다고 하더라도 터득할 수 있게 할 수 있는 계기를 마련 해준 것이 C++이지 않습니까?

앞서 Testor님이 비유하신 10의 노력/100의 노력의 문제처럼 누군가가 이미 90을 만들어 놓았기 때문에 10의 노력으로 무언가를 할 수 있다는 말은 나머지 90을 하게 되므로 얻는 지식을 얻는 수고를 함으로서 파이썬, 자바와 같은 언어에 더 쉽게 접근 할 수 있다고 생각합니다.
myevan
Posts: 1314
Joined: 2003-03-04 10:21
Contact:

Re: 영향력있는 사람들의 OOP에 대한 평가들.

Post by myevan »

류광 wrote:
Testors wrote: 예를 들어 Python의 Rails라 할 수 있는 Django에는 이런 코드가 있습니다. ( http://code.djangoproject.com/browser/d ... ginator.py )

Code: Select all

 def validate_page_number(self, page_number):
        try:
            page_number = int(page_number)
        except ValueError:
            raise InvalidPage
        if page_number < 0 or page_number > self.pages - 1:
            raise InvalidPage
        return page_number
try - except 부분은 C++이라면 그냥 validate_page_number(self, int page_number): 로 해결될 문제입니다.
이것은 류광님이 생각하신 것과는 조금 다른 문제라고 생각됩니다.

위에서 page_number 는 gpg 페이지 주소를 예를 들때
http://gpgstudy.com/forum/posting.php?m ... [u]p=95956[/u] 중
p=95956 에 해당하는 개념입니다.

이부분은 사용자 입력 부분이기 때문에 page_number 에는 숫자 대신 p=abkchbxhlbhadgh 이런것들이 올수 있습니다.

그러므로 C++ 에서는 함수내에서 page_number 를 체크하기에 앞서
함수밖에서 page_numbr 가 숫자인지 체크하는 부분이 필요합니다.

Code: Select all

bool ToNumber(const char* arg, int arg_len, int* ret_page_number);
일단 이런 함수를 만들고 나서야 validate_page_number 함수를 호출할 수 있습니다.

Code: Select all

if (!ToNumber(arg, arg_len, &page_number))
{
    throw InvalidPage;
}

page_number = validate_page_number(page_number);
이걸로 끝일까요? 아닙니다.예외가 발생하므로 관련 코드중에
메모리 릭부분이 생길부분은 없는지 검토해야 할 것입니다.

-----------------------------------------------------------------------------

C++ 로 만들면 왠지 좀더 쉬울것 같았지만 훨씬더 복잡해져버렸습니다.

이것이 Testors 님께서 이야기하시는 C++ 의 한계입니다.
OOP 문제를 왈가불가하기전에 기본적인 단계에서 헤메야 한다는 것이 핵심적인 문제입니다.

C++ 을 사용해서 대규모의 안정성 있는 프로그램을 만들 수는 있습니다.
하지만 엄청난 노력과 시행착오 그리고 사전지식이 필요합니다

-----------------------------------------------------------------------------

결론은
저같은 일반적인 프로그래머에게 C++ 로 (OOP를 비롯해서)대형 프로그램 전체를 작성하는건
그다지 추천할만한 일이 아니라고 생각합니다.

Java나 Python 이나 Ruby 등으로 대부분 구조를 작성하고
성능이 중요한 코어 부분만 C++ 로 작성하는 형태가 훨씬 바람직하다는게
제 개인적인 생각입니다.
빗자루네 http://www.myevan.net >_<b
류광
Posts: 3805
Joined: 2001-07-25 09:00
Location: GPGstudy
Contact:

Post by 류광 »

아 그런 것이었군요~

그러나 동적 언어에서도 형식 점검이 필요한 부분이 존재한다는 지적으로는 여전히 유효한 예라고 생각합니다. 그리고 C++라고 해도 개발자가 매번 ToNumber를 다시 만들 필요는 없고요(스트림).
이것이 Testors 님께서 이야기하시는 C++ 의 한계입니다.
OOP 문제를 왈가불가하기전에 기본적인 단계에서 헤메야 한다는 것이 핵심적인 문제입니다.

C++ 을 사용해서 대규모의 안정성 있는 프로그램을 만들 수는 있습니다.
하지만 엄청난 노력과 시행착오 그리고 사전지식이 필요합니다 ~(-_-)~
이 예나 지금까지의 사례들만으로는 좀 비약인 것 같습니다.
비회원

Re: 흥미롭네요.

Post by 비회원 »

후훗~ 의도대로 되었군요.

위에서 MFC와 C#의 억지 비교를 한 사람입니다. 사실 OOP보다는 C++에 대해 애기해 보고 싶었습니다.

가끔은, 소모적이지 않는 한에서는 이런 토론도 꽤나 즐겁습니다.

비회원 wrote:

const 위치에 따란 상수 구분이 왜 웃겼는지 개인적으로 궁금합니다. 저는 굉장히 감동 받았거든요.

로우 레벨에 대한 것이 C++이 아무것도 가르켜 주지 않았고 단지 C++로 작성하면서 터득했기에 C++과 아무런 관련이 없다라고 하시는 건 괴변이라 생각이 듭니다. C++ 아무 것도 가르쳐 주지 않지도 않았겠지만 그렇다고 하더라도 터득할 수 있게 할 수 있는 계기를 마련 해준 것이 C++이지 않습니까?

앞서 Testor님이 비유하신 10의 노력/100의 노력의 문제처럼 누군가가 이미 90을 만들어 놓았기 때문에 10의 노력으로 무언가를 할 수 있다는 말은 나머지 90을 하게 되므로 얻는 지식을 얻는 수고를 함으로서 파이썬, 자바와 같은 언어에 더 쉽게 접근 할 수 있다고 생각합니다.
저는 C부터 배운 사람입니다. 그러나, C보다는 C++플머에 가깝습니다. 과제가 주워지면, C++로 생각하니까요.

그러나, 로우레벨적인 건 C로 배웠습니다. 로우레벨적인 것(운영체제나 자료구조론, 컴파일러등으로 이해했음)은 언어와 상관 없습니다.

일례로 자료구조론은 파스칼로 배웠습니다. 단지 어떤 언어를 선택했냐의 차이일 뿐입니다.


PS: UP~~
myevan
Posts: 1314
Joined: 2003-03-04 10:21
Contact:

Re: 영향력있는 사람들의 OOP에 대한 평가들.

Post by myevan »

류광 wrote:. 예를 들어 mix-in이나 소위 monkey patching 등은 최종 응용 프로그래밍에서는 아주 강력한 도구가 되겠지만, 유연함보다는 정확성이 더 중요한 시스템 프로그래밍에서는, 그리고 협동적인 개발에서는 커다란 혼란을 야기할 수 있습니다. 지금 보고 있는 이 클래스가 내가 알고 있는 그 클래스인지 확신할 수 없으니까요.... (이런 비판은 Rails 커뮤니티 내부에서도 제기되었다고 알고 있습니다.)
지금보고 있는 이 클래스가 내가 알고 있는 그 클래스인지 확신할 수 없는 정도로 시스템 프로그래밍을 못한다면
C언어로는 시스템 프로그래밍이 아예 불가능할것입니다. ( void* 형과 강제 캐스팅이 남발되는게 c언어니까요 ~(-_-)~ )

또한 지금보고 있는 이 클래스가 내가 알고 있는 그 클래스인지 확신할 수 있다는것은
정적 타이핑 언어를 사용하는 프로그래머의 착각입니다.

실제로 프로그램을 돌리다가 버퍼 오버플로우나 아웃오브바운드 문제가 발생해서
스택이나 메모리가 오버라이트되면 모든것은 확신할 수 없게 됩니다.
이로 인해 하루 내내 디버깅해도 해결할 수 없는 문제가 생기곤 합니다.
(어쩌다 생기는 문제라고 하기에는 너무 자주 발생하죠 ~(-_-)~ )

오히려 동적 타이핑 언어에서는 RTTI 를 기본으로 채택하고 있기 때문에
해당 클래스가 무엇인지 100% 정확히 알 수 있으며
스택이나 메모리가 오버라이트가 되지 않는다는 확신이 있으므로
빠른 시간내에 문제 해결이 가능합니다.


ps. 사실 min-in 방식을 사용할 경우에는 그 클래스인지 확신할 필요가 없습니다.
필요한 메소드만 존재하면 문제없기 때문이죠 ~(-_-)~
문제가 생기면 그때가서 해결하면 됩니다.

왜냐면 그냥 그부분 작동만 잠시 안될뿐이지
'알수없는 에러'로 인해 프로그램 실행이 완전 중지되지는 않거든요 : )
빗자루네 http://www.myevan.net >_<b
myevan
Posts: 1314
Joined: 2003-03-04 10:21
Contact:

Post by myevan »

류광 wrote:아 그런 것이었군요~

그러나 동적 언어에서도 형식 점검이 필요한 부분이 존재한다는 지적으로는 여전히 유효한 예라고 생각합니다. 그리고 C++라고 해도 개발자가 매번 ToNumber를 다시 만들 필요는 없고요(스트림).
C++ 프로그래머는 성능을 중요시하기 때문에
일반적인 ToNumber 함수를 만들 가능성이 적은데다
해당 코드에 대한 의존성 문제가 발생해버립니다. (ToNumber.cpp, ToNumber.h 를 들고 다니는 것도 애매한 일이죠; )

결국 만들고 또 만들고 하는것이죠 : )
이것이 Testors 님께서 이야기하시는 C++ 의 한계입니다.
OOP 문제를 왈가불가하기전에 기본적인 단계에서 헤메야 한다는 것이 핵심적인 문제입니다.

C++ 을 사용해서 대규모의 안정성 있는 프로그램을 만들 수는 있습니다.
하지만 엄청난 노력과 시행착오 그리고 사전지식이 필요합니다 ~(-_-)~
이 예나 지금까지의 사례들만으로는 좀 비약인 것 같습니다.
가장 큰 C++ 의 약점은 다들 아시겠지만 메모리 관리 문제입니다

많은 C++ 프로그래머들이 프로그래밍을 만들때
- 메모리 할당/해제
- 버퍼오버플로우
- 아웃오브바운드 문제
등등으로 머리를 움켜쥐고 있다는건 누구나 인정하는 사실입니다.

하지만 이문제를 언어차원으로 해결하는 순간 그것은 C++ 이 아닌것이죠 : )

위에서 이미 언급했지만 C++ 의 사용범위를 최대한 줄이는 것이
올바른 길이라고 생각합니다.
빗자루네 http://www.myevan.net >_<b
mastercho
Posts: 587
Joined: 2004-05-09 20:37

Post by mastercho »

myevan wrote: 가장 큰 C++ 의 약점은 다들 아시겠지만 메모리 관리 문제입니다

많은 C++ 프로그래머들이 프로그래밍을 만들때
- 메모리 할당/해제
- 버퍼오버플로우
- 아웃오브바운드 문제
등등으로 머리를 움켜쥐고 있다는건 누구나 인정하는 사실입니다.

하지만 이문제를 언어차원으로 해결하는 순간 그것은 C++ 이 아닌것이죠 : )

위에서 이미 언급했지만 C++ 의 사용범위를 최대한 줄이는 것이
올바른 길이라고 생각합니다.
메모리 관리에 있어서는 스마트 포인터를 사용했고, 자원획득시 초기화기법를 사용하는방법을
이용함으로써 , 제 코드에 메모리 릭이 없다고 확신하기 시작한지가 좀 오래되었습니다 :)
게다가 STL 자료구조를 이용하면서
메모리 할당 문제를 신경써야 할일이 있었는가?를 생각해보면 , 신경 쓸일이 전혀 없었습니다
[ new 말고도 C방식의 Create Delete용 헨들도, 스마트 포인터로 관리 가능합니다 :) ]


버퍼 오버플로우는 1메가 짜리 이상 되는 객체 혹은 데이터를 아무 생각없이 함수 스택에 넣어서 발생한
[그 즉시 바로 알수 있음] 경우와 , vector를 쓰지 않거나 실수로 배열 크기를 잘못써넣어서 발생한
경우인데 , 역시 큰 문제는 되지 않습니다

아웃오브바운드 이런것, 역시 포인터을 이용하는부분에서 포인터를 잘 알지 못해 오용하는 경우에 발생합니다
myevan wrote: 또한 지금보고 있는 이 클래스가 내가 알고 있는 그 클래스인지 확신할 수 있다는것은
정적 타이핑 언어를 사용하는 프로그래머의 착각입니다.
잘못 캐스팅하거나 다른곳에서 메모리 침범해 뻑나지 않았다면 그 클래스인지 확신할수 있습니다
그게 컴파일 타임 언어의 장점입니다
[그래서 Effective C++ 같은 책에서는 C++이 reinterpret_cast, const_cast , static_cast등등
C처럼 하면 쉽게 캐스팅하는것을 어렵게 캐스팅 하게끔 만들어놓을것을두고 , 캐스팅은
왠만하면 하지 말아라는 의미로 받아 들이라는 농담을 하죠]

예를 들어주시면 좀더 좋은 토론이 될거 같네요


사실상 C++ 보다, 낫다고 강조하는 C++ 파생 언어들의 강점들은
[ 가비지 컬랙션, 스트링처리 , 강력한 자료구조 ]
C++ 표준라이브러리 차원에서 이미 해결되었고 , 더 강력하게 사용가능합니다

물론 라이브러리를 공부해야하는 수고는 해주셔야합니다
비회원

음...

Post by 비회원 »

const 위치에 따란 상수 구분이 왜 웃겼는지 개인적으로 궁금합니다. 저는 굉장히 감동 받았거든요.

로우 레벨에 대한 것이 C++이 아무것도 가르켜 주지 않았고 단지 C++로 작성하면서 터득했기에 C++과 아무런 관련이 없다라고 하시는 건 괴변이라 생각이 듭니다. C++ 아무 것도 가르쳐 주지 않지도 않았겠지만 그렇다고 하더라도 터득할 수 있게 할 수 있는 계기를 마련 해준 것이 C++이지 않습니까?

앞서 Testor님이 비유하신 10의 노력/100의 노력의 문제처럼 누군가가 이미 90을 만들어 놓았기 때문에 10의 노력으로 무언가를 할 수 있다는 말은 나머지 90을 하게 되므로 얻는 지식을 얻는 수고를 함으로서 파이썬, 자바와 같은 언어에 더 쉽게 접근 할 수 있다고 생각합니다.
저걸로 감동 받으셨다는건가요... 저는 기분이 나빴습니다. 제가 이해 잘 이해 안되는것도 기분이 나빴고 여러 책들에서 그걸 설명하기 위해서 여러 가지 방법으로 설명을 하는데 그게 더 넌센스였습니다. 그리고 말씀하신 논리대로라면 어셈블러가 최고라고 봅니다. 간단한 정수 -> 실수 변환으로도 상당히 많은 부분을 처리해주어야 하는데 언어가 지원하지 않음으로써 공부를 했으니 C++이 좋다는건가요? 그건 말이 안된다고 봅니다. 요새 시대에는 실수가 어떻게 처리되는지 자세한 내막을 모르고도 거의 대부분 프로그래밍이 가능합니다. (처음부터 알고 했다면 대단한 프로그래머고요.) 그렇기에 프로그램이 나올 수 있었던 겁니다. 지금까지 계속 어셈블러였다면 생산성은 완전히 최악이었을 겁니다. 그걸 C, C++이 엄청나게 해소해 주었고 요새에는 자바나 C#이 나오게 된 것입니다. (솔직히 자바나 C#이나 거의 똑같지만) 아무리해도... 어렵게 배운 덕택에 역시 C++ 쌩큐. 이런건 아니라고 봅니다. (그래도 저는 C++씁니다 ^^)

그리고 다른 예로 메소드에 const가 붙는 형태. 이거 정말 최악입니다. 아마 제가 여기서 물어보면 아는 사람 10%도 안될겁니다. 물론 나머지 90%가 C++을 안다는 가정하에서요. (그리고 testors님의 의견에 저도 찬성합니다. 확실히... 저도 이런걸 공부하면서 기분이 좋은적은 없네요. "왜 이렇게 헷갈리게 만들었지?" 같은 생각만 들었죠.)

잘못 캐스팅하거나 다른곳에서 메모리 침범해 뻑나지 않았다면 그 클래스인지 확신할수 있습니다
그게 컴파일 타임 언어의 장점입니다
[그래서 Effective C++ 같은 책에서는 C++이 reinterpret_cast, const_cast , static_cast등등
C처럼 하면 쉽게 캐스팅하는것을 어렵게 캐스팅 하게끔 만들어놓을것을두고 , 캐스팅은
왠만하면 하지 말아라는 의미로 받아 들이라는 농담을 하죠]
C++에서 안되니까 많은 선지자들이 해놓은것이지 그게 없는 상태에서 본인이 회사에서 일하고 있었다면 직접 고생하면서 구현하셔야 될 것입니다. 아마 그때에는 C++이 여전히 좋다라고는 말씀하기 힘들겁니다. 그때에는 불평이 늘겠죠. 다른 누군가를 위해서 C++에 관련된 라이브러리름 만들어본 경험이 있으신지요? 그걸 하다 보면... "내가 이걸 왜 하지... C#에는 당연히 있는건데..."하는 기분이 들겁니다. C++이 없어서 그런것이지만 뭐 그렇다고 C++이 욕을 얻어 먹어야 할 이유가 없는건 사실이죠.




하지만 이문제를 언어차원으로 해결하는 순간 그것은 C++ 이 아닌것이죠 : )

위에서 이미 언급했지만 C++ 의 사용범위를 최대한 줄이는 것이
올바른 길이라고 생각합니다.
더 이상 메모리 관리자 같은거에 신경쓰고 싶지 않습니다. ^^

만일 이 논의가 그런 일반론으로 끝난다면 정말로 시간 낭비일 것입니다. 다행히 지금까지는 그렇지 않았다고 봅니다.
생각이 바뀌었습니다. 그냥 이렇게 끝나면 안될것 같네요. :)
yagur
Posts: 47
Joined: 2003-06-25 02:09
Location: Impression
Contact:

Post by yagur »

매번 장문이 되어 죄송합니다.
비회원 wrote: 사실 패턴은 언어에 아주 많이 종속적입니다. 만일 언어에서 패턴을 지원하면 특별히 그 패턴을 구현하기 위해서 해주어야 할 것이 없지요. 그래서 C++이 요새 나온 다른 언어들에 비하면 불편한것이 사실입니다. 즉, 이 말은 비용은 따르지만 C++과는 상당한 차이가 날 수도 있습니다. (C#으로 옵저버 패턴 구현하는 것과 C++로 구현하는데 최소 2배 이상의 시간 차이가 걸립니다. 단순히 타이핑으로 쳐도 말이죠.)
패턴에 관한 사용자의 견해는 정말 많습니다 =).
이 인용문에 한가지 제 생각을 적어보자면 패턴은 언어 종속적이 아니라, 디자인 해법입니다. 도구인 디자인 해법을 언어 차원에서 지원해야할 이유를 느끼지 못합니다. 이전 논의를 보면 도구에 관한 이야기가 있습니다. 도구를 언어에 종속시키는것은 개인적으로 반대입니다. IDE에 Refactoring 기능이 들어가있는 것(Eclipse의 Java, Smalltalk)들이 있습니다. 즉 IDE의 도구로서 존재하는 것이지요. 패턴도 같다고 생각합니다. 패턴이 특정 IDE의 도구나 지원 패키지로서 존재는 환영이나, 언어의 기능으로서 둔다는것은 와닿지 않습니다.

디자인 해법과 타이핑의 비용을 비교하는것은 조금 힘듭니다. 옵저버 패턴을 예로 드셨느데, 혹시 시간이 되신다면 제가 전 글에 예로든 "Apple"을 생각해봐주시길 바랍니다. 이름으로서의 패턴이 존재하는것인지, 아니면 의미를 지닌 해법으로서 존재하는것인지 말이지요.
여기서 더 생각해 볼수 있는것은 패턴을 사용하기 위해 프로그램을 맞추는 것인지, 아니면 문제점 해결을 위해 패턴을 채용하는지 입니다. '디자인 해법으로서 패턴 채용'과 '타이핑 비용'의 가치 비교는 사용자 몫 입니다.

아시는 부분이겠지만 혹시나 의문을 품은 분들을 위해 적습니다. 옵저버 패턴의 가치는 객체간의 적절한 관계 맺음에 있습니다. 결합과 재사용성 면으로 볼수있는 부분입니다. 예를 들자면 Model과 View가 하나의 객체로서 단단한 결합(tight coupling)을 하고 있다면 재사용성이 떨어지는것을 느낄수 있습니다. 이 둘의 결합도를 줄이기 위해 관찰자와 관찰대상을 두는것이고 변경 전파(change-propagation) 메커니즘으로서 좀더 일반화된 형태를 띄게 되는것입니다. 이 디자인 해법으로서의 가치는 경직성(하나의 변경으로 다른것도 변경됨)의 해소이며, 좋은 기능을 지니는 것입니다.

Java 같은 경우엔 java.util.Observer와 java.util.Observable을 지니고 있는것으로 알고있습니다(Java를 예로 들려 한것은 아니지만, C++ 외의 예를 들기 위함입니다). 물론 언어 차원이 아닌 지원 패키지입니다. C++도 이를 만든다고 해서 =) 타이핑을 많이 하는것이 아니죠. 몇분 안걸릴것 같습니다.
전 타이핑의 비용과 해법이 주는 이로움의 가치와 비교했을때, 이로움의 가치에 좀더 무게를 두겠습니다. 이것은 찬양이 아닌 해법으로서 접근 비용 대비 실용성을 생각해봤을때의 제 기준입니다. 위의 것들을 ㅤㅂㅘㅅ을때 '도구로서 가치'와 '언어의 가치'는 좀 별개의 문제이며, 연관이 있다해도 영향력은 미비한 수준이라 생각합니다.
비회원 wrote: 맞습니다. 1~20년 지나고 보면 웃음만 나오는 분도 계실겁니다. 프로그램 만드는데 패턴과 리펙토링이 꼭 필요한것이 아닙니다. 리펙토링은 이미 모든 프로그래머가 써온것이었고, 패턴도 이미 쓰고 있던겁니다. 유용한 도구임에는 확실하나 그 이상은 아닙니다.
유용한 도구임은 확실하나 그 이상은 아니란것이라고 하셨는데, 비회원님이 어떤 가치를 두고 있는지 유추하기 힘이 듭니다. 유용하니 알고 쓰는것이 좋다는것인지, 인용하신 Testor님 의견과 일치하는 견해를 가진것인지 혼란스럽군요.
제 생각엔 1~20년 후에도 이들의 이름과 해법, 원리에 의한 효과같은 지혜와 지식는 존재할것이며, 더 발전할것이라고 생각합니다. 웃음이 나오는것이 아니라 끊임없는 학습과 탐구가 진행 될것이며, 컴퓨터 공학의 중요한 학문으로서 자리를 잡을것 같습니다. 다른 예측을 하실수도 있습니다. =)
이름만 알고 쓰는것, 의미와 효과를 알고 쓰는것, 공통 어휘로서의 역활에 대해서는 Testor님과의 논의에도 있고 이 글의 시작점에도 일부 있습니다.
비회원 wrote: 맞습니다. 이것만 알면 지금 이렇게 서로 길게 말하지 않고 프로그램 만들 시간을 벌 수 있었을 겁니다. 솔직히 지금 시간 아깝지 않나요... (저도 아깝습니다.)
위의 인용에 대한 생각은, 음... 논의의 목적을 어디에 두셨는지 궁금합니다. 전 좀 오바해서 말하면, 제가 그동안 해왔던 프로그래밍의 철학이나 방법을 되돌아 보기위해 이 논의에 끼어들었습니다. 다른 분들의 지혜도 빌릴겸 해서이죠. 논쟁이긴 하지만 너무 공격적이 되지 않았으면 하는 바램입니다.
논쟁의 방향만 올바르다면 얻는것은 많다고 생각합니다. 그리고 인용하신 글처럼 C++을 만능이고 가장 우월한 언어라고 논쟁을 진행해온 분은 보지 못한듯 합니다만. 나쁜 뜻은 아닙니다. 생산활동에 방해와 시간 낭비를 지적하셨는데, 엔지니어(?)들의 의견차에서 생기는 흔한 현상에서 나온 말로 받아들이겠습니다.
myevan wrote: 지금보고 있는 이 클래스가 내가 알고 있는 그 클래스인지 확신할 수 없는 정도로 시스템 프로그래밍을 못한다면
C언어로는 시스템 프로그래밍이 아예 불가능할것입니다. ( void* 형과 강제 캐스팅이 남발되는게 c언어니까요 ~(-_-)~ )
myevan wrote: 오히려 동적 타이핑 언어에서는 RTTI 를 기본으로 채택하고 있기 때문에
해당 클래스가 무엇인지 100% 정확히 알 수 있으며
류광님과 myevan님의 'C++의 OOP'와 'mix-in과 타입 검사'에 관한 이야기 논의으로 알고있습니다. C의 void* 정적 캐스팅이 C++에서 사용될순 있지만, 아직 까지 거의 못본듯합니다. 만약 그러하다면 말(C++)하는 방법에 문제가 있는것은 아닐까요? =) 멀티 패러다임이니긴 하나 C++의 OOP패러다임을 따르는 사람은 void* 케스팅과 C-Style 스태틱 캐스팅 지양하는것으로 알고 있습니다.
한가지 첨언하자면 dynamic_casting은 RTTI를 C++이 지원하기때문에 이루어집니다 =)
myevan wrote: 또한 지금보고 있는 이 클래스가 내가 알고 있는 그 클래스인지 확신할 수 있다는것은
정적 타이핑 언어를 사용하는 프로그래머의 착각입니다.
추상화된것에 의존하는것은 C++(혹은 정적 타이핑 언어)의 문제라기 보다 OOD의 원칙중 하나입니다. Concrete 객체 보단 Abstract 객체에 의존하는것 혹은 Interface에 의존하는것이 나쁜 원칙은 아니라 생각합니다만.
그리고 착각하기 원하지 않고, 전 정말 추상적인것에 의존하는 프로그램 방법을 사용하고 싶습니다.
리스코프 교체(Liskov Substitution), 의존 관계 역전, 인터페이스 격리 원칙등을 한번 고려해보시면 어떠하실지요.
myevan wrote: C++ 프로그래머는 성능을 중요시하기 때문에
일반적인 ToNumber 함수를 만들 가능성이 적은데다
해당 코드에 대한 의존성 문제가 발생해버립니다. (ToNumber.cpp, ToNumber.h 를 들고 다니는 것도 애매한 일이죠; )
결국 만들고 또 만들고 하는것이죠 : )
이건 Modularity와 관계 있는 부분이군요. 라이브러리의 개념을 생각해보시면 어떠할까요. 중복의 분리는 어떠할까요.
Bertland Meyer의 Object Oriented Software Construction의 Modularity에 좋은 부분이 하나 있는데, 어떤 생각을 하실지는 모르겠습니다.
Bertrand Meyer wrote: Decomposability: if some work has already been done to analyze the modular
structure of the problem domain, it may provide a good starting point for the modular
decomposition of the software.
어리숙하지만 해석이 귀찮은분들을 위해... 남깁니다.
분해력 : 몇몇 작업들이 문제 영역 모듈의 구조를 분석을 위하여 이미 완료되어있다면, 소프트웨어의 모듈 분해의 좋은 시작점을 제공하는 것이다.

이미 완료되어 재사용될수 있는 부분은 분리 해내 하나의 라이브러리로 만드는것은 비단 C++만이 아니라 모든 Modularity를 원하는 언어의 필요사항입니다. Andrew Hunt의 D.R.Y(Don't Repeat Yourself) 원칙도 같은 맥락으로 적용될수 있습니다.
전 해당 ToNumber이나 비슷한 성질의 것들끼리 응집력(Cohesive) 있게 모듈화 하는것을 추천합니다. 매번 소스파일을 들여올 필요는 없습니다. 일종의 copy & paste와 다를게 없기 때문이죠.
특히 변하지 않는 부분을 분리해내거나 격리시키는것을 전 추천합니다.
myevan wrote: 가장 큰 C++ 의 약점은 다들 아시겠지만 메모리 관리 문제입니다.
... 중략 ...
mastercho wrote: 메모리 관리에 있어서는 스마트 포인터를 사용했고, 자원획득시 초기화기법를 사용하는방법을 ... 중략 ...
Mastercho님이 이미 예를 들으셨지만 C++에 관용구(Idiom)란 도구가 존재합니다. 스마트 포인터, 레퍼런스 카운팅, Scope관련 등등 모두 관용구에 해당합니다. 다른 언어에서도 채용할수 있는 관용구들도 많으며, 내장된 기능들도 있습니다. 이것은 도구 선택이란 제 이전 논의와 같은 문제입니다.
언어로 좀 길게 표현할수도 있고, 관용구를 통해 표현할수도 있습니다. 공통 어휘의 문제와 일맥상통합니다. 제 생각엔 도구를 사용하게 되는 시점이 C++이 주는 자유로움의 혼란을 줄이는 좋은 시점이라 생각합니다.
Myevan wrote: 하지만 이문제를 언어차원으로 해결하는 순간 그것은 C++ 이 아닌것이죠 : )
위에서 이미 언급했지만 C++ 의 사용범위를 최대한 줄이는 것이
올바른 길이라고 생각합니다.
'언어 차원에서 해결' 부분이 조금 모호하지만, C++의 언어가 만들어낸 관용구와 같은 도구를 사용한다고 해서 C++이 아닌것이 되진 않습니다.
dyks
Posts: 79
Joined: 2004-09-23 14:41
Location: Andromeda Galaxy

Post by dyks »

음. 화두를 던져놓고 저만 빠져 있는 것 같아 죄송합니다.

비회원님께서 언급하셨던 것 처럼, 저도 개인적으로 이 논의가 일반론으로 종결될거라고 생각했습니다만, 정말 그래서는 안될 것 같군요.^^
논의의 참여에 별로 적극적이지 않았던 것에 사과드리면서 말을 이어갈까 합니다.

The Mother of All Classes(Common Ancestor라는 단어를 제가 처음 언급하긴 했습니다만, 류광님께서 언급하신대로 명확한 표현을 위해서라면 저 단어가 더 좋을 듯 하네요.) 를 처음 언급했던 이유는, OOP를 기저에 깔고 있는 다른 강타입 언어들이 가지고 있는 요소였고, 성능의 희생없이도 구현이 가능한 부분이라고 생각했기 때문입니다. 그리고 지금까지의 이슈를 제 나름대로 정리해보자면, 성능이 지금 논의의 절대적인 지표는 아닌 것 같습니다.

사실 성능에 대한 부분을 조금만 양보한다면, 다른 언어를 선택함으로써 취할 수 있는 잇점이 훨씬 더 늘어난다고 생각합니다. (이것은 지금까지 논의에서 이어져 온 다른 분들의 의견과 맥을 같이합니다.) 하나의 예로 yagur님께서 C++에서의 void*와 C type캐스팅의 문제를 드셨는데, 그렇다면 왜 void*을 막고 RTTI가 기본으로 켜져 있으면 안되는 걸까요. 왜 코딩을 하는데 제가 사용하는 것이 UNICODE String인지 아닌지, UNICODE String이라면 인코딩은 어떻게 되었는지 알아야 할까요. 왜 플랫폼이 x64인지 Win32인지 알아야 할까요. 조금 더 나아가, 왜 제가 사용하는 클래스나 상속받는 클래스가 어디에서 상속받아 왔는지 알아야 할까요.

이 글에서 이어져 온 대로, C++은 다양한 라이브러리를 제공합니다. 혹은 yagur님께서 말씀하신 것 처럼 제가 나름대로 모듈화를 통해 라이브러리를 만들 수도 있을겁니다. 하지만 그것들은 소스차원에서 제공됨에도 불구하고, 위의 제약조건에 영향을 너무나도 많이 받습니다. 간단한 예로, tostring을 포함해 나름대로의 string 라이브러리를 만들었다고 해보죠. 하지만 그것은 환경이 변하는 순간 무용지물로 변해버릴 가능성이 큽니다.

라이브러리를 가져다 쓰는 경우도 마찬가지 입니다. 수많은 라이브러리가 존재하지만, 그 중 저러한 모든 환경에 독립적인 라이브러리가 존재할 가능성은 희박합니다. 최근 스크립트 임베딩 작업을 할 일이 있었는데, x64를 지원하고 UTF-16을 사용하며 custom memory manager를 사용할 수 있는 임베딩 가능한 스크립트 언어를 찾을 수 없어 결국 처음부터 만들어야 했습니다.(제 검색실력이 부족해서 일 수도 있습니다만.) 그리고 저런 제약조건의 변화는 기존 스크립트 언어를 가져다 '조금만' 수정하는 선에서 해결되지 않습니다. 만약에 저러한 것들을 프로그래머가 몰라도 되는 환경이라면 전 아마 다른 스크립트 언어를 쉽게 가져다 사용할 수 있었을 겁니다.

객체의 추상화 역시, 강타입 언어에서 OO를 지원하기 위한 방편일 뿐이라고 생각합니다. 중요한 건 그 객체가 어떤 메소드를 가지고 있는가(어떤 메시지를 받을 수 있는가)이지 그 객체의 타입이 무엇인지 식별하는 것은 아니라고 생각하거든요. 객체 타입의 식별은 강타입 언어에서 그 객체가 어떤 메시지를 받을 수 있는지를 알 수 있는 유일한 방법이긴 하지만, 반드시 필요하다고 생각하지 않습니다. 그게 오리이든, 아니면 개와 고양이의 이종교배의 결과이든, 제가 원하는 것이 그게 꽥꽥 거리기를 바라는 것이라면 상관없는 것이죠.

Code: Select all

 def validate_page_number(self, page_number):
        try:
            page_number = int(page_number)
        except ValueError:
            raise InvalidPage
        if page_number <0> self.pages - 1:
            raise InvalidPage
        return page_number
위의 예제에 대한 제 생각도 그렇습니다. 류광님께서는 동적언어에서도 형식 점검이 필요한 하나의 예라고 하셨는데, (Python을 공부한 적이 없어 int(...)부분이 어떻게 동작하는지는 잘 모르겠습니다만)위의 예제를 제가 바라보는 방식은, page_number가 integer인가 그렇지 않은가를 검사하는 예제가 아니라, page_number 객체가 원하는 범위의 숫자를 뱉어내는 메소드를 구현했는가 그렇지 않은가로 보입니다. page_number가 integer든 string이든 오리든 개든 고양이든 원하는 범위의 숫자를 뱉어낼 수 있으면 그만입니다.

어떤 언어를 사용했을 때의 효율성에 대한 문제는, 매우 가까운 곳에서 찾을 수 있다고 생각합니다. 지금 많은 게임 프로그램들이(서버든 클라이언트든) UI와 AI 그리고 기타 여러 목적으로 스크립트 언어들을 임베딩 하고 있습니다. 그리고 그러한 언어의 대부분은 OO를 어느정도 기저에 깔고 있는 동적 언어들입니다. 구조적으로 생각할 수 있는 기획자들에게 쉽고 빠르게 자신의 의도를 드러낼 수 있는 프로그램을 만들 수 있도록 하기 위한 가장 좋은 길이 OO를 지원하는 동적 타입언어라는 것의 반증이 아닐까요.

C++이 가지는 장점과 단점은, myevan님께서 인용하신 첫 통계가 보여주고 있다고 봅니다. 많은 것을 할 수 있기 때문에 극단적인 성능이 필요로 한 시스템 프로그래밍이나 게임 프로그래밍 등의 분야에서는 강세를 보이지만(같은 장점을 가지고 있는 C에 밀리긴 하지만요.), 성능을 양보할 수 있는 분야에서는 Java등의 언어에게 자리를 내줄 수 밖에 없습니다. 이는 어떤 언어로 프로그래밍 해야 하는가에 대한 제 생각과도 일치합니다. 사용하지 않을 수 있다면, 구현 목표에 집중할 수 있는 다른 언어를 사용하는 것이 답이라고 생각합니다.
류광
Posts: 3805
Joined: 2001-07-25 09:00
Location: GPGstudy
Contact:

Post by 류광 »

myevan wrote:
류광 wrote:아 그런 것이었군요~

그러나 동적 언어에서도 형식 점검이 필요한 부분이 존재한다는 지적으로는 여전히 유효한 예라고 생각합니다. 그리고 C++라고 해도 개발자가 매번 ToNumber를 다시 만들 필요는 없고요(스트림).
C++ 프로그래머는 성능을 중요시하기 때문에
일반적인 ToNumber 함수를 만들 가능성이 적은데다
해당 코드에 대한 의존성 문제가 발생해버립니다. (ToNumber.cpp, ToNumber.h 를 들고 다니는 것도 애매한 일이죠; )

결국 만들고 또 만들고 하는것이죠 : )
그러한 가정이 가능하다면 반대쪽의 가정도 가능할 것입니다 즉, Django 류의 C++ 프레임워크라면 toInt()나 operator int()를 제공하는 HttpRequest 클래스 역시 갖추고 있다고 기대해도 무리가 아닐 것입니다 :)
myevan wrote: 가장 큰 C++ 의 약점은 다들 아시겠지만 메모리 관리 문제입니다

많은 C++ 프로그래머들이 프로그래밍을 만들때
- 메모리 할당/해제
- 버퍼오버플로우
- 아웃오브바운드 문제
등등으로 머리를 움켜쥐고 있다는건 누구나 인정하는 사실입니다.

하지만 이문제를 언어차원으로 해결하는 순간 그것은 C++ 이 아닌것이죠 : )
앞의 vector 초기화 문제와 비슷한 반론이 가능합니다. 즉.. 프로그래머가 메모리 관련 어려움을 겪고 있다면 그것은 단순히 "객체를 만들어서 사용한다"라는 문제가 아니라 "객체를 위한 메모리를 꼭 필요한만큼만, 꼭 필요한 동안만 사용한다"라는 더 어려운 문제를 풀고 있는 것이 아닌가 하는 것입니다. 가장 간단한 수준인 "객체를 만들어 사용하고 그냥 잊어버린다"에서 가장 어려운 수준인 "꼭 필요한 만큼만, 꼭 필요한 동안만" 사이에도 여러 난이도 수준들이 존재할 것이고, 이에 대한 여러 해법들은 mastercho님이 앞에서 몇 가지 언급하셨습니다. 한가지 더 추가하자면 아예 모든 것을 값으로 전달할 수도 있습니다 :)
myevan wrote: 위에서 이미 언급했지만 C++ 의 사용범위를 최대한 줄이는 것이
올바른 길이라고 생각합니다.
주어진 목적에 가장 잘 맞는 언어를 사용한다는 일반적인 취지에서 동감합니다만, 지금 맥락에서는 (이전에 나온 Testors님 답글의 '진작에'와 비슷하게) '최대한' 역시 좀 더 구체적인 논의가 필요합니다. 언어 전체적으로 본다면 역시 통계적인 문제겠으나 우리가 C++ 언어 전체적인 통계를 얻기는 힘들 것이고요. myevan님의 첫 답글( viewtopic.php?p=95627#95627 )이나 위의 dyks님 글 마지막 부분에 암시된 것처럼, 슬슬 "게임 프로그래밍"으로 논의를 국한할 때가 된 것 같기도 합니다...
mastercho
Posts: 587
Joined: 2004-05-09 20:37

Post by mastercho »

dyks wrote:
사실 성능에 대한 부분을 조금만 양보한다면, 다른 언어를 선택함으로써 취할 수 있는 잇점이 훨씬 더 늘어난다고 생각합니다. (이것은 지금까지 논의에서 이어져 온 다른 분들의 의견과 맥을 같이합니다.) 하나의 예로 yagur님께서 C++에서의 void*와 C type캐스팅의 문제를 드셨는데, 그렇다면 왜 void*을 막고 RTTI가 기본으로 켜져 있으면 안되는 걸까요. 왜 코딩을 하는데 제가 사용하는 것이 UNICODE String인지 아닌지, UNICODE String이라면 인코딩은 어떻게 되었는지 알아야 할까요. 왜 플랫폼이 x64인지 Win32인지 알아야 할까요. 조금 더 나아가, 왜 제가 사용하는 클래스나 상속받는 클래스가 어디에서 상속받아 왔는지 알아야 할까요.
RTTI를 기본적으로 켜져 있으면 안되냐는건 컴파일러 옵션에서 선택사항인데
이걸 왜 무조건 키고 있지 않냐고 물으시는건 , C++의 기본철학을 아직도 이해를 못하고 계시는겁니다

C++은 객체지향으로만 프로그래밍 할수 있는 언어가 아니기 때문입니다
필요가 없는데 굳이 가지고 있는건 낭비라 할수 있죠
[ RTTI 정보로 인해 프로그래밍 크기가 커질수 밖에 없습니다 ]

유니코드 문제는 C++만의 문제가 아닙니다, 인코딩 문제는 어떤 언어를쓰더라도 인코딩 포멧을 알아야 쓸수 있습니다. [물른 게중에는 자바처럼 유니코드로만 짤수 있게 해서 방법을 통일 시킨곳도 있을수 있습니다
하지만 , 자바처럼 반드시 유니코드를 써야 할 필요가 없는곳도 있을거라 봅니다 ,
조엘온 소프트웨어에서 나온 이야기지만 알파벳권 문화권에선 문자열에 쓸때없이 2바이트를 쓰다고 용납할수 없다는 단체도 있다고 합니다 ;) , 사실 유니코드를 완전히 제대로 다르려면 4바이트를 써야하죠; ]

그리고 C++이 표준대로 쓴다면 반드시 특정 플레폼을 알아야 할 이유는 없습니다

물론 64비트 컴퓨터에서 , int long 타입 크기가 달라질수 있는건 typedef로 컴파일러 회사들이 극복하고 있는데 , 표준으로 크기를 아예 정해 놓으면 더 좋지 않을까하는 아쉬움은 저도 들더군요

저도 멀티플레폼으로 라이브러리를 작성해봤는데 표준 C++과 멀티플레폼용 라이브러리들을 사용하면
[ x64 에선 해본적이 없으므로 ]
큰 문제 없이 멀티플레폼용 라이브러리와 프로그램을 만들수 있었습니다
왜 제가 사용하는 클래스나 상속받는 클래스가 어디에서 상속받아 왔는지 알아야 할까요.
이 말은 잘 이해가 안가네요
dyks wrote: 이 글에서 이어져 온 대로, C++은 다양한 라이브러리를 제공합니다. 혹은 yagur님께서 말씀하신 것 처럼 제가 나름대로 모듈화를 통해 라이브러리를 만들 수도 있을겁니다. 하지만 그것들은 소스차원에서 제공됨에도 불구하고, 위의 제약조건에 영향을 너무나도 많이 받습니다. 간단한 예로, tostring을 포함해 나름대로의 string 라이브러리를 만들었다고 해보죠. 하지만 그것은 환경이 변하는 순간 무용지물로 변해버릴 가능성이 큽니다.
.
대부분이 특정 플레폼에 의존적으로 코드를 짜기 때문이고 , 표준적인 코드를 짜도록 노력하지 못한면이
많기때문이라고 생각합니다. 그리고 string 라이브러리나 꼭 필요한 핵심 라이브러리는 다시 말하지만
이미 STL이나 boost에서 대부분 제공하고 있고 , 거의 모든 플레폼에서 사용가능합니다
그래서 Effective C++ 저자는 항상 표준과 표준에 상응하는 라이브러리를 쓰라고 강조합니다

dyks wrote: 라이브러리를 가져다 쓰는 경우도 마찬가지 입니다. 수많은 라이브러리가 존재하지만, 그 중 저러한 모든 환경에 독립적인 라이브러리가 존재할 가능성은 희박합니다. 최근 스크립트 임베딩 작업을 할 일이 있었는데, x64를 지원하고 UTF-16을 사용하며 custom memory manager를 사용할 수 있는 임베딩 가능한 스크립트 언어를 찾을 수 없어 결국 처음부터 만들어야 했습니다.(제 검색실력이 부족해서 일 수도 있습니다만.) 그리고 저런 제약조건의 변화는 기존 스크립트 언어를 가져다 '조금만' 수정하는 선에서 해결되지 않습니다. 만약에 저러한 것들을 프로그래머가 몰라도 되는 환경이라면 전 아마 다른 스크립트 언어를 쉽게 가져다 사용할 수 있었을 겁니다.
.
다른 언어를 써보시면 현재 다른언어들은 어떤가를 다시 생각하실수 있을겁니다
, 다른 언어가 내세우는 플레폼 독립적이라는 소리가 얼마나 터무니 없는
소리인지 아시게 될겁니다

자바를 쓰려면 자바 머신이 돌아가야 자바를 쓸수 있는거고, C#은 닷넷 환경이 설치되어야 쓸수 있습니다
C++ 역시 C++ 컴파일러가 들어야 쓸수 있지요

그래도 C++은 gcc부터 시작해 소스도 공개되어 있고 역사가 깁니다, 그래서 C 다음 C++를 부분적으로
대부분 지원하죠

하지만 c# , 자바같은 것들은, 자기네 돈되는 플레폼만 가상 머신을 개발하고 , 다른 곳 플레폼은 부실하기 짝이 없습니다. 기대했던 라이브러리 커녕 컴파일러 혹은 가상 머신조차 존재 하지 않은 경우도 많습니다
[ 나름 유명 OS 인데 단지 오픈소스에 돈 안된다는 이유로 말이죠 ]

다른 언어에 대한 환상이 지나치신거 같습니다



dyks wrote: 어떤 언어를 사용했을 때의 효율성에 대한 문제는, 매우 가까운 곳에서 찾을 수 있다고 생각합니다. 지금 많은 게임 프로그램들이(서버든 클라이언트든) UI와 AI 그리고 기타 여러 목적으로 스크립트 언어들을 임베딩 하고 있습니다. 그리고 그러한 언어의 대부분은 OO를 어느정도 기저에 깔고 있는 동적 언어들입니다. 구조적으로 생각할 수 있는 기획자들에게 쉽고 빠르게 자신의 의도를 드러낼 수 있는 프로그램을 만들 수 있도록 하기 위한 가장 좋은 길이 OO를 지원하는 동적 타입언어라는 것의 반증이 아닐까요.
.
스크립트언어와 컴파일러언어의 특징을 계속해 주장하는건 , 진행되는 토론 내용과 맞지 않다고 생각됩니다
dyks wrote: C++이 가지는 장점과 단점은, myevan님께서 인용하신 첫 통계가 보여주고 있다고 봅니다. 많은 것을 할 수 있기 때문에 극단적인 성능이 필요로 한 시스템 프로그래밍이나 게임 프로그래밍 등의 분야에서는 강세를 보이지만(같은 장점을 가지고 있는 C에 밀리긴 하지만요.), 성능을 양보할 수 있는 분야에서는 Java등의 언어에게 자리를 내줄 수 밖에 없습니다. 이는 어떤 언어로 프로그래밍 해야 하는가에 대한 제 생각과도 일치합니다. 사용하지 않을 수 있다면, 구현 목표에 집중할 수 있는 다른 언어를 사용하는 것이 답이라고 생각합니다.
맞습니다 C++이 맞지 않는곳에 굳이 우격다짐으로 쓰면서 C++이 엉망이라 욕할 필요는 없는것이죠
Last edited by mastercho on 2008-03-08 19:12, edited 5 times in total.
류광
Posts: 3805
Joined: 2001-07-25 09:00
Location: GPGstudy
Contact:

Post by 류광 »

dyks wrote:

Code: Select all

 def validate_page_number(self, page_number):
        try:
            page_number = int(page_number)
        except ValueError:
            raise InvalidPage
        if page_number < 0 > self.pages - 1:
            raise InvalidPage
        return page_number
위의 예제에 대한 제 생각도 그렇습니다. 류광님께서는 동적언어에서도 형식 점검이 필요한 하나의 예라고 하셨는데, (Python을 공부한 적이 없어 int(...)부분이 어떻게 동작하는지는 잘 모르겠습니다만)위의 예제를 제가 바라보는 방식은, page_number가 integer인가 그렇지 않은가를 검사하는 예제가 아니라, page_number 객체가 원하는 범위의 숫자를 뱉어내는 메소드를 구현했는가 그렇지 않은가로 보입니다. page_number가 integer든 string이든 오리든 개든 고양이든 원하는 범위의 숫자를 뱉어낼 수 있으면 그만입니다.
try ... except 부분은 page_number가 실제로 int 형식인가를 점검하는 부분이 맞습니다. 값의 범위는 그 다음에서 점검하고요.

좀 더 직접적인 예라면 isinstance 구문이 쓰이는 부분들입니다. 예를 들어 http://code.djangoproject.com/browser/d ... idators.py 에는 다음과 같은 코드가 있습니다.

Code: Select all

    def __init__(self, message):
        "ValidationError can be passed a string or a list."
        if isinstance(message, list):
            self.messages = [force_unicode(msg) for msg in message]
        else:
            assert isinstance(message, (basestring, Promise)), ("%s should be a string" % repr(message))
            self.messages = [force_unicode(message)]
그리고 dyks님 글 앞부분에 대해서는... 유니코드의 인코딩을 알아야 한다거나 플랫폼이 x64인지 Win32인지를 알아야 하는 것은 안타깝지만 어쩔 수 없는 일이 아닐까 싶습니다. 일부에서 말하는 "우아한 해답이 없다면 문제를 잘못 선택한 것이다" 같은 말은 멋있기는 하지만 비현실적이라고 생각합니다. 어려운 문제가 주어지지 않으면 좋겠지만 이미 주어졌다면 어쩔 수 없습니다. 그 문제에 대한 해답을 누군가가 미리 만들어 두지 않았다면 자신이 해결할 수밖에요. 예를 들어 이 스레드에서 myevan님은 C++을 강하게 비판하셨지만, PyTinker를 만들고 공개하신 분도 myevan님입니다(물론 C++ 사용을 최소화하려는 목적이셨겠지만요 :) )
dyks
Posts: 79
Joined: 2004-09-23 14:41
Location: Andromeda Galaxy

Post by dyks »

류광 wrote:
dyks wrote: 좀 더 직접적인 예라면 isinstance 구문이 쓰이는 부분들입니다. 예를 들어 http://code.djangoproject.com/browser/d ... idators.py 에는 다음과 같은 코드가 있습니다.

Code: Select all

    def __init__(self, message):
        "ValidationError can be passed a string or a list."
        if isinstance(message, list):
            self.messages = [force_unicode(msg) for msg in message]
        else:
            assert isinstance(message, (basestring, Promise)), ("%s should be a string" % repr(message))
            self.messages = [force_unicode(message)]
음. assert를 위해 type을(조금 더 정확히는 받을 수 있는 메시지를) 검사하는 것은 좀 다르다고 생각합니다만^^ 그리고 개인적인 의견으로는 message list와 message를 동시에 받을 수 있는 메소드 구조가 더 이상해보이는군요.

Code: Select all

messages = [msg.string for msg in message]
위 메소드와

Code: Select all

messages = message.string
는 구분이 되던가, 혹은 list로 통일해서 넘기는 편이 더 나았다고 보입니다.
류광 wrote:그리고 dyks님 글 앞부분에 대해서는... 유니코드의 인코딩을 알아야 한다거나 플랫폼이 x64인지 Win32인지를 알아야 하는 것은 안타깝지만 어쩔 수 없는 일이 아닐까 싶습니다. 일부에서 말하는 "우아한 해답이 없다면 문제를 잘못 선택한 것이다" 같은 말은 멋있기는 하지만 비현실적이라고 생각합니다. 어려운 문제가 주어지지 않으면 좋겠지만 이미 주어졌다면 어쩔 수 없습니다. 그 문제에 대한 해답을 누군가가 미리 만들어 두지 않았다면 자신이 해결할 수밖에요. 예를 들어 이 스레드에서 myevan님은 C++을 강하게 비판하셨지만, PyTinker를 만들고 공개하신 분도 myevan님입니다(물론 C++ 사용을 최소화하려는 목적이셨겠지만요 :) )
항상 우아한 해답만을 기대하는 건 저도 역시 비현실적이라고 생각합니다. 누군가는 진흙탕에 손을 담궈야 할 필요가 있겠죠. 하지만 C++은 겪어본 바로는 너무 많은 사람이 진흙탕에 손을 담궈야 합니다. 누군가 비슷한 문제로 진흙탕에 손을 담궜어도, 약간의 제약 조건 변화로 같은 진흙탕에 또 손을 담궈야 합니다.
xevious7
Posts: 175
Joined: 2006-03-30 17:31
Contact:

Post by xevious7 »

mastercho wrote:
myevan wrote: 가장 큰 C++ 의 약점은 다들 아시겠지만 메모리 관리 문제입니다

많은 C++ 프로그래머들이 프로그래밍을 만들때
- 메모리 할당/해제
- 버퍼오버플로우
- 아웃오브바운드 문제
등등으로 머리를 움켜쥐고 있다는건 누구나 인정하는 사실입니다.

하지만 이문제를 언어차원으로 해결하는 순간 그것은 C++ 이 아닌것이죠 : )

위에서 이미 언급했지만 C++ 의 사용범위를 최대한 줄이는 것이
올바른 길이라고 생각합니다.
메모리 관리에 있어서는 스마트 포인터를 사용했고, 자원획득시 초기화기법를 사용하는방법을
이용함으로써 , 제 코드에 메모리 릭이 없다고 확신하기 시작한지가 좀 오래되었습니다 :)
게다가 STL 자료구조를 이용하면서
메모리 할당 문제를 신경써야 할일이 있었는가?를 생각해보면 , 신경 쓸일이 전혀 없었습니다
[ new 말고도 C방식의 Create Delete용 헨들도, 스마트 포인터로 관리 가능합니다 :) ]

....
안녕하세요.

언어자체가 메모리관리를 지원해주는 것과 언어를 이용하여 메모리관리를 구현하는것은
완전히 다른 문제가 아니지 않습니까? 이렇게 따지면 C언어로 만으로도 라이브러리나
언어 자체를 사용한 구현으로 다른언어의 모든것을 할 수 있기 때문입니다. 당연한 이야기지만 말입니다.

C++이 C#이나 Python같은 언어에 비하여 (언어자체를 의미합니다.) 메모리관리 어렵다는
것은 언어자체에서의 특징여부를 말하는 것이 아닐까요?

물론 스마트포인터를 쓰는것은 전혀 어려운 작업이 아니기 때문에
충분히 무시할 문제일 수 있다고 생각할수 있지만 , 기본적으로 언어자체의 지원이 아닌
언어를 통한 구현으로의 해결은 또 다른 문제라고 생각됩니다.

만약 스마트포인터가 관용구라서 언어자체에서 지원하는 것이다라고 하신다면 ,

어떤 언어이든지 단점은 구현으로 다 해결되어질 수 있는 문제가 아닐까요?
myevan
Posts: 1314
Joined: 2003-03-04 10:21
Contact:

Post by myevan »

mastercho wrote:
myevan wrote: 가장 큰 C++ 의 약점은 다들 아시겠지만 메모리 관리 문제입니다

많은 C++ 프로그래머들이 프로그래밍을 만들때
- 메모리 할당/해제
- 버퍼오버플로우
- 아웃오브바운드 문제
등등으로 머리를 움켜쥐고 있다는건 누구나 인정하는 사실입니다.

하지만 이문제를 언어차원으로 해결하는 순간 그것은 C++ 이 아닌것이죠 : )

위에서 이미 언급했지만 C++ 의 사용범위를 최대한 줄이는 것이
올바른 길이라고 생각합니다.
메모리 관리에 있어서는 스마트 포인터를 사용했고, 자원획득시 초기화기법를 사용하는방법을
이용함으로써 , 제 코드에 메모리 릭이 없다고 확신하기 시작한지가 좀 오래되었습니다 :)
게다가 STL 자료구조를 이용하면서
메모리 할당 문제를 신경써야 할일이 있었는가?를 생각해보면 , 신경 쓸일이 전혀 없었습니다
[ new 말고도 C방식의 Create Delete용 헨들도, 스마트 포인터로 관리 가능합니다 :) ]


버퍼 오버플로우는 1메가 짜리 이상 되는 객체 혹은 데이터를 아무 생각없이 함수 스택에 넣어서 발생한
[그 즉시 바로 알수 있음] 경우와 , vector를 쓰지 않거나 실수로 배열 크기를 잘못써넣어서 발생한
경우인데 , 역시 큰 문제는 되지 않습니다

아웃오브바운드 이런것, 역시 포인터을 이용하는부분에서 포인터를 잘 알지 못해 오용하는 경우에 발생합니다
어느정도 프로그래밍을 오래하셨다면 자신의 코드에 메모리 관련 문제가 없다고 확신하실 수 있을겁니다.
하지만 내가 작성한 코드가 아닌 경우는 어떨까요? 프로그래밍을 하면서 다른 사람이 작성한 라이브러리를
사용해야하는 경우는 매우 많습니다.

사용자입장에서 해당 라이브러리에 대해서 소스 코드 레벨에서 100% 이해하지 못했다면 문제가 발생할 가능성이
높습니다. 반대로 제작자가 사용자의 상황을 100% 반영해서 만들 수 있는것이 아니기 때문에 문제가 발생할 수
있습니다.

조엘온소프트웨에에서 언급되는 널 레퍼런스 문제가 바로 이것입니다.
레퍼런스에 NULL 포인터를 일부러 집어 넣는 바보는 많지 않을겁니다.
그럼에도 불구하고 크래쉬 리포트를 받아보면 심심찮게 비슷한 문제들이 발생하는 것을 볼 수 있습니다.

내가 만들어서 내가 사용하는 작은 프로그램에서는 충분히 확신하실 수 있을지 모르겠지만...
다른 사람에 의해 만들어진걸 사용하고, 내가 만든걸 다른 사람이 사용하는 상황에서도 과연 확신할 수 있을까요?
다들 확신 못하기 때문에 클라이언트 코드내 스택 워커랑 미니 덤프를 넣어두는 것 아닐까 합니다 ~(-_-)~

------------------------------------------------------------------
myevan wrote: 또한 지금보고 있는 이 클래스가 내가 알고 있는 그 클래스인지 확신할 수 있다는것은
정적 타이핑 언어를 사용하는 프로그래머의 착각입니다.
잘못 캐스팅하거나 다른곳에서 메모리 침범해 뻑나지 않았다면 그 클래스인지 확신할수 있습니다
그게 컴파일 타임 언어의 장점입니다
[그래서 Effective C++ 같은 책에서는 C++이 reinterpret_cast, const_cast , static_cast등등
C처럼 하면 쉽게 캐스팅하는것을 어렵게 캐스팅 하게끔 만들어놓을것을두고 , 캐스팅은
왠만하면 하지 말아라는 의미로 받아 들이라는 농담을 하죠]

예를 들어주시면 좀더 좋은 토론이 될거 같네요
잘못캐스팅하지 않고, 다른 곳에서 메모리 침범을 안할거라고 생각하는게 바로 핵심적인 착각입니다.

예상가능하고 정상적인 상황만 가정한다면
솔직히 타입 체크를 전혀하지 않아도 잘 돌아갑니다.

초기 c코드 보세요!
그냥 무작정 캐스팅하지만 잘 돌아갑니다!

덕타이핑도 개인적으로는 강력한 타입체킹에 대한 조소라고 생각됩니다.
전혀 엉뚱한 타입을 넣어도 꽥꽥 거리기만 하면 잘 돌아갑니다!
마치 이렇게 외치는 것 같습니다

"컴파일러군 ~(-_-)~ 뭘 그리 타입체킹을 하고 있나? 인생 한번 잘못 미끄러지면 뻑인게지 - o-)y- ~ "


하지만 예상이 불가능한 상황(라이브러리 코드를 볼 수 없거나, 라이브러리에 대한 이해가 충분하지 않거나
자신을 비롯한 누군가가 피폐해진 정신으로 코딩을 했던적이 있다면 ) 이야기는 달라집니다.
분명히 컴파일러 에러는 발생하지 않았고
난 정말 완벽하게 프로그래밍했다고 자신하지만
프로그램은 죽어나갈 수 있습니다.

명태눈깔 L도 깔끔하게 해치웠던 됐어노트의 라이토도 ~(-_-)~
잠깐 실수로 무너지고 마는 것처럼 말입니다.

------------------------------------------------------------------

강력한 타입 체크는 예상 가능한 상황과 좁은 범위내에서라면 매우 좋은 도구입니다.
하지만 인간의 두뇌는 2MB 짜리 게임 클라이언트 조차 모두 머리에 정확히 담아두기에는 역부족입니다.
더구나 프로젝트 기간이 6개월을 넘겨버리고 중간에 휴가라도 갔다오면 조엘씨 말대로 끝장이죠 ~(-_-)~

현실이 이렇다면 에러를 내더라도 치명적이지 않고 수습가능하게 프로그램을 만드는것이
훨씬 정신건강에 이롭다는게 제 의견입니다 ~(-_-)~


ps. 저도 C++ 좋아합니다. 부품(멋지게 말하면 '코어') 만들때만 한정한다면 말입니다 -◇-)~
빗자루네 http://www.myevan.net >_<b
myevan
Posts: 1314
Joined: 2003-03-04 10:21
Contact:

Post by myevan »

dyks wrote:[qㅁuote="류광"]
dyks wrote: 좀 더 직접적인 예라면 isinstance 구문이 쓰이는 부분들입니다. 예를 들어 http://code.djangoproject.com/browser/d ... idators.py 에는 다음과 같은 코드가 있습니다.

Code: Select all

    def __init__(self, message):
        "ValidationError can be passed a string or a list."
        if isinstance(message, list):
            self.messages = [force_unicode(msg) for msg in message]
        else:
            assert isinstance(message, (basestring, Promise)), ("%s should be a string" % repr(message))
            self.messages = [force_unicode(message)]
음. assert를 위해 type을(조금 더 정확히는 받을 수 있는 메시지를) 검사하는 것은 좀 다르다고 생각합니다만^^ 그리고 개인적인 의견으로는 message list와 message를 동시에 받을 수 있는 메소드 구조가 더 이상해보이는군요.

Code: Select all

messages = [msg.string for msg in message]
위 메소드와

Code: Select all

messages = message.string
는 구분이 되던가, 혹은 list로 통일해서 넘기는 편이 더 나았다고 보입니다.
이런 메소드 구현이 이상해 보이실 수 있습니다.
하지만 사용자 측면에서 생각해보면 확실히 아무거나 넣을 수 있는쪽이 편합니다.

요리사 '제이미'가 나오는 프로를 보면 이런 상황이 종종 나옵니다.
출연객: 음 난 올리브 오일을 넣고 싶은데 넣어도 될까?
제이미: 그냥 넣고 싶은데로 넣으세요~ (올리브 오일을 병째 뒤집어 음식에 두른다)
출연객: 햐-ㅁ- 정말 맛있겠는데!
이런 마인드를 가지고 있으면 심지어 메시지에 이미지를 넣고 싶다는 말을 들어도 화내지 않게 됩니다 : )


ps. 이쯤 되면 다시한번 이런 질문을 하고 싶어집니다.
- 대체 OOP 프로그래밍은 왜하는걸까요?
- 유연한 코드란 대체 무엇일까요?
- 당신의 코드에는 제(고객)가 원하는 말도 안되는 요구를 얼마나 쉽고 깔끔하게 집어넣으실 수 있습니까?
- 아. 저(고객)의 마음이 바뀌었습니다. 방금 넣은건 없에기로 하죠. 괜찮겠죠?
만약 고객의 간단한 요구에 전체 구조를 들쑤셔야 한다면 당신의 OOP 프로그래밍은 잘못된것입니다.

태초에 Object 가 있었습니다. 그리고 Object의 아들은 누구, 그의 아들은 누구식의
Class Hierarchy 를 좋아한다면 피를 더럽히거나, 삼대를 멸족시킬 가능성이 높습니다.

Testors 님은 아마 이점을 문제 삼으신 것일겁니다.


ps2.
OOP를 처음 접했을때 저는 BaseClass 를 DerivedClass 의 '조상'이라고 생각했습니다.

하지만 최근 들어서 BaseClass 란 여러가지 Object 의 필요에 의해 발견되는 공통 분모('이상')라는 사실을 깨달았습니다.
빗자루네 http://www.myevan.net >_<b
비회원

Post by 비회원 »

xevious7 wrote:
안녕하세요.

언어자체가 메모리관리를 지원해주는 것과 언어를 이용하여 메모리관리를 구현하는것은
완전히 다른 문제가 아니지 않습니까? 이렇게 따지면 C언어로 만으로도 라이브러리나
언어 자체를 사용한 구현으로 다른언어의 모든것을 할 수 있기 때문입니다. 당연한 이야기지만 말입니다.

C++이 C#이나 Python같은 언어에 비하여 (언어자체를 의미합니다.) 메모리관리 어렵다는
것은 언어자체에서의 특징여부를 말하는 것이 아닐까요?

물론 스마트포인터를 쓰는것은 전혀 어려운 작업이 아니기 때문에
충분히 무시할 문제일 수 있다고 생각할수 있지만 , 기본적으로 언어자체의 지원이 아닌
언어를 통한 구현으로의 해결은 또 다른 문제라고 생각됩니다.

만약 스마트포인터가 관용구라서 언어자체에서 지원하는 것이다라고 하신다면 ,

어떤 언어이든지 단점은 구현으로 다 해결되어질 수 있는 문제가 아닐까요?

관용적 용법이든 , 언어 자체가 지원하든 , 중요한건 메모리 관리를 자동으로 한다는게 중요한게 아닌가요?

C 에서 어떤짓을 하든 자동으로 관리 할 방법이 있나요?

있다해도 , 그 비용은 상상할수 없을만큼 클겁니다, C++은 언어 자체는 아니지만 이미 스마트포인터
기법으로 그 문제를 해결할수 있는 관용구가 boost 에서, 아니 이젠 표준으로 나오게 되었습니다

중요한게 무언가요?
반드시 가상머신이 달려서 처리해줘야 하는 방식이어야 한다는 건가요?
Locked