누가 gtk가 객체 지향 적이라 할 수 있을까요...

onemind555의 이미지

하나도 안 객체 지향 적이더군요..

소스를 보니 함수 하나가 수백줄이나 되고 완전히 if 문의 남발로 되어가지고 못 알아 보겠는 왜 이걸 객체 지향 적이라고 하죠...

maddie의 이미지

gtk--가 gtk쪽에서 객체를 쓰는 것으로 알고 있습니다.
객체지향쪽으로 가면 qt가 더 낫지 않나요?

힘없는자의 슬픔

onemind555의 이미지

XLib의 예제를 함 볼려고 gtk 소스를 분석 해봤는데... 이건 완전 스파게티 소스 입니다.

함수 하나가 몇백줄이나 되고 어떤 특별한 개념도 없이 XLib의 함수 이름에 GTK만 붙여 놓은 느낌 밖에 안 듭니다. 오히려 소스를 더 꼬아 놓아 알아 보지도 못하게 한 느낌입니다..

잘 되 있는건 코딩 컨벤션은 잘 지켜져 있더군요..

가끔 누구의 글을 보면 gtk가 객체 지향 적이라고 그러는데.. 내가 보기에는 객체 지향 하고 상당히 거리가 먼 스파게티 소스 밖에 안 됩니다..

-----------^^ ^^ ^^ ^^ ^^ ----------
..........................................................

fibonacci의 이미지

C로 객체를 구현했기때문에 복잡하게 보일수밖에 없습니다.
C가 싫다면, 링크에서 원하는 바인딩을 골라보세요.
거의 모든 언어별로 바인딩이 있습니다.

http://www.gtk.org/bindings.html

C++ 바인딩인 gtkmm 추천합니다.

Gtkmm2 튜토리얼입니다. 읽어보세요.
만족할수 있을만한 수준일겁니다.

http://www.gtkmm.org/gtkmm2/docs/tutorial/html/index.html

No Pain, No Gain.

onemind555의 이미지

C로 객체를 구현 했기 때문에 복잡 한게 아닌 것 같습니다..
함수 하나가 수백 라인 되는데 어떻게 안 복잡 하겠어요...

-----------^^ ^^ ^^ ^^ ^^ ----------
..........................................................

fibonacci의 이미지

참고하세요.
GTK+에서 C로 객체를 구현한 것에 대한 정보입니다.

http://developer.gnome.org/doc/GGAD/cha-objects.html

No Pain, No Gain.

iolo의 이미지

글쎄요... 기분 나쁘게 들리실지도 모르겠지만...
지금 하시는 얘기는... 본인이 GTK정도의 라이브러리를 짜본적이 있는(혹은 짤 정도의 수준이 되는) 사람이 할 수 있는 얘기 아닐까요?

수많은 개발자가 참여해서 만들었고, 수많은 개발자가 사용하고 있는 라이브러리를 비난하시는 것은 상당한 책임감(혹은 위험부담)이 요구되는 일이라고 생각됩니다.

자칫 잘못하면, GTK를 만든/사용한/하는 사람들을 무시하는 결과가 될 수도 있으니까요.

그런 결과를 원하시는 게 아니려면 좀 더 구체적인 접근이 필요합니다.
그냥 함수 하나가 몇백줄이라고 해서 OOP가 아니다라고 하는 것은 넌센스입니다.

GTK의 OOP를 이해하기 위해서는 GLib-Object시스템에 대한 이해가 선행되어야 합니다. GLib-Object시스템은 OOP의 기본적인 요구사항을 모두 만족하고 있습니다.

C언어의 문법이 지원하지 않기때문에 어쩔수 없는 타입캐스팅과 반복적인 인자전달, 사전 등록 절차들이 필요한것을 GTK가 OOP가 아니라고 하시는 것인가요?

예를 들어:

GtkWidget* label = gtk_label_new(...);
gtk_label_set_text(GTK_LABEL(label), ...);
gtk_widget_show(button);
gtk_widget_destroy(button);

위의 코드가:

GtkLabel* label = new GtkLabel(...);
label->setText(...);
label->show();
delete label;

라고 되어 있으면 객체지향이라고 하시겠습니까?

그건 표기법의 차이일뿐 객체지향과는 무관한 이지요. 물론 GTK에서 아래처럼 쓸수도 있지만, C의 제약으로 인해 많은 타이핑이 필요하고 gtk_widget_show라는 편의함수를 만들어 놓은 것 뿐입니다.

어떤 것이 OOP가 아닌 지 몇가지만이라도 예를 보여주시면 좋겠습니다.
그럼 이만...[/code]

----
the smile has left your eyes...

sugarlessgirl의 이미지

왜 gtk 는 C 로 만들어졌나 궁금했었는데..
위에 링크된 글에 나와있네요..

Quote:
The answer is that C is more portable and standardly available than any other language

짧군요..;;

crimsoncream의 이미지

bbs에 불 한번 질러보자라는 의도가 아니시라면 좀 더 읽는 사람들에게 많은 정보를 제공해주십시요.
어떤 모듈에 속한 어떤 함수가 보니 수백라인이더라. 이 함수의 목적은 이러이러한 것인데 이건 요렇게 저렇게 나누는게 더 좋지 앉겠냐.
이게 힘들면 어떤 녀석인지만이라도 알고 싶군요.

그리고 정당한 이유가 있다면 함수 하나가 수백라인아니라 수만라인인들 어떻습니까. 저도 clarity를 위해서는 simplicity를 희생시킬 수 있다고 생각하는 축에 속해서 가끔 늘여쓰는 경우도 있습니다.

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

체스맨의 이미지

iolo wrote:

그냥 함수 하나가 몇백줄이라고 해서 OOP가 아니다라고 하는 것은 넌센스입니다.

동의합니다.
- 함수 하나를 왜 몇백줄이나 되게 만들고 if 가 남발되어 있는가
- OOP 냐 아니냐
라는 두 논제는 전혀 관계가 없습니다.

어떤 분들은 함수의 길이를 기계적으로 몇 줄 이내로 해야한다고
못박기도 하지만, 저 개인적으로는 '상황에 따라' 라고 생각하기 때문에,
gtk 소스의 상황을 봐야겠군요.

Orion Project : http://orionids.org

akbar의 이미지

....

offree의 이미지

저는 OOP 에 대해 그냥 개념적으로 알고있는 정도이지만..

C++, Java 는 객체지향적으로 개발하도록 되어있고..
C는 구조적(?)으로 개발하도록 되어 있다.
라고 생각이 됩니다.

각각의 반대의 경우로 사용하기 위해서는 상당한 노력이 든다.
라고 생각이 들고요.

GTK 가 C 로 객체지향적으로 설계가 되어 있다면.. 정말 상당한 실력가들이지 않을까 합니다.

저 같은 실력이라면 왜 이렇게 했을까 하고 이해를 못 하고 있을 것 같습니다. ^^

사용자가 바꾸어 나가자!!

= about me =
http://wiki.kldp.org/wiki.php/offree , DeVlog , google talk : offree at gmail.com

iolo의 이미지

akbar wrote:

다른 무엇보다도 외부에서 알 필요가 없는 멤버를 프로그래머가 잘 파악할 수 없다는 것입니다.
만약 gtk_IsButtonShowd 라는 구조체안에 멤버 함수 포인터가 있을 때
이 gtk_IsButtonShowd 라는 함수 포인터가 외부에서 임의로 접근해도
되는 함수인지 아닌지를 판별하기가 매우 어렵다는 것이죠
C++ 에서 몇 개의 키워드로 외부접근을 순식간에 지정할 일을
C 에서는 특별한 코딩컨벤션으로 밖에는 지켜나가기가 힙듭니다.
C 도 전문가들에게는 객체지향 설계가 가능하지만 그 완성도에 있어
C++ 전문가들에게는 상당부분 못미칠 수 밖에 없습니다.
gtk 가 C++ 로도 포팅되어 있으니 C++ 플머에게도 불만은 없겠지만
기존 C gtk 소스를 C++ 로 감싸는 과정에서
처음부터 C++ 로 작성되었더라면 설계하지 않아도 되었을 여러 사정때문에
(특히 구조체 안의 함수 포인터) 소스부분을 보자면
최종적으로 C 소스를 볼 수 밖에 없는데
이때 '어지럽다'는 느낌을 지울 수가 없는 것이죠
함수의 줄 수 가지고 OOP 다 아니냐를 따지는 것도 안되겠지만
GTK C 기반의 객체설계 이상으로 객체지향적으로 설계할 수 있구나 하는 인식을
갖는 것도 중요할 것 같습니다.

glib object시스템에도 private이 있습니다. C의 범위내에서 구현한 것이지요.
간단히 예를 들면:

gtkwidget.h:

typedef struct _priv;

struct _GtkWidget {

  struct _priv* priv;

  /*public ...*/
  gtk_widget_show();
...
}

gtkwidget.c:

struct _priv {
/*private */
...
}

라고 되어 있다고 하면

사용자 어플리케이션에서:

#include <gtkwidget.h>

GtkWidget* widget = gtk_widget_new()
widget->priv->xxx = yyy;

가 불가능하죠(컴파일 에러겠죠).
인용한 글을 쓰신 분이 언급하신 어지러울 수 없는 부분이라는 게 이러한 것을 말씀하시는 건가요?

그런데 glib object system에는 이런 하드한 방법외에 property시스템이 따로 존재합니다. 이 경우에는 각 프로퍼티에 대한 setter/getter를 구현하고, 그것을 등록하는 형식입니다. 물론 등록은 타입(C++의 class)에 대해서 한번만 하면 됩니다. 그리고 등록은 해당 객체의 최초의 인스턴스가 생성될때 자동으로 이루어지도록 되어 있습니다.

확실히, OOP를 문법상에서 지원하는 것 처럼 깔끔하진 않습니다.
하지만 gtk개발자들이 쉬운 길을 두고 어려운 길을 갔기 때문에 얻는 이점이 많이 있습니다.

위에 어느 분이 hp의 글을 한 줄 인용하셨는데,
한가지만 덧붙이면 다른 고급언어와의 바인딩을 만들기 쉽다는 점입니다.
객체에 대한 정보를 외부에서도 접근할 수 있기 때문에(introspection) 새로운 위젯이 생긴다고 하드코딩으로 바인딩을 만들지 않아도 됩니다.

물론 위에분이 말씀하신것 처럼 glib object system보다 좋은 C언어용 객체지향 프레임웍이 있을지도 모릅니다.(전 정말 모릅니다) 저도 비슷한 프레임웍을 만들어서 쓴적이 있지만, glib의 그것을 보고는 생각을 완전히 접었습니다.

다시 주제로 돌아가면...
GTK는 객체지향이 아니고 스파게티 코드라고 하시고 싶으시면:
객체지향이 아니라면 어떤 부분인지? 어떻게 하면 객체 지향인것인지?
스파게티라면 어떤것이 스파게티고 어떻게 하면 스파게티가 아닌지?
이런 얘기를 해주시면 좋겠습니다.

저는 어느 쪽이냐 하면:
이 주제의 제목에 동의하지 못하기 때문에 그렇지 않다는 것을 얘기하고, 부족하지만 나름대로 객관적인 근거를 제시할려고 노력하고 있습니다.

----
the smile has left your eyes...

akbar의 이미지

...

체스맨의 이미지

akbar wrote:

데이타 은닉 뿐만 아니라
생성자 소멸자 문제도 C 차원에서 어째어째 해결했다고 치죠
그렇게 어려운 길을 갔기 때문에 얻는 이점이 많이 있다면
쉬운 길을 갔을 때도 역시 많은 잇점이 있는 것입니다.

저는 gtk 가 C 로 OOP 를 구현했다 해서, 그것이 쉬운길을 두고
어려운 길을 갔다고 생각하지 않습니다. 그냥 C 로 할 수 있는 일을
했다고 봅니다. 그래서 어째 어째 해결했다는 말씀은 마치
온갖 편법을 동원했을 여지가 있다는 것 같아 동의하기 어렵군요.

득실에 대해 주관적이라 말씀하시지만, 현실적인, 그리고 객관적인 예로,
성공한 사례인 Windows API 가 있습니다. 이들 역시 C 로 구현된 OOP
이고, 데이터 은닉, 생성자, 소멸자 등을 잘 구현하고 있습니다.

또한, C 로 작성된 API 를 기반으로 C++ MFC 라이브러리를 지원하듯이
gtk 를 기반으로 C++ 용 라이브러리를 지원하고 있지요.

akbar wrote:

-- GTK C 기반의 객체설계 이상으로 객체지향적으로 설계할 수 있구나 하는
-- 인식을 갖는 것도 중요할 것 같습니다.

요컨에 마인드를 좀 넓히자는 것입니다.
GTK C 기반의 객체설계에만 치중하는 듯한 태도보다는
그 이상으로 객체설계할 수 있다는 인식을 갖고 임하는 것이
좀 더 미래 지향적이 아닌가 합니다.

마인드를 넓히자는 것과, GTK 이상으로 OOP 설계가 가능(C 를 사용해서)
하다는 것에 동의 합니다만, 현재 토론이 GTK 의 객체 설계가 최상의
방법인 것처럼 치중된 면은 없습니다. 단지 그 설계가 어떠한가 정도만
다루어졌을 뿐이죠.

Orion Project : http://orionids.org

wildkuz의 이미지

:twisted:

객체지향적으로 설계됐을 때 코드상의 가장 큰 변화는 바로 if나 switch 문이 사라진다는 것입니다. 처음 글 쓰신 분은 gtk안에 if 문의 남발만 보아도 전혀 객체지향적으로 설계된 구조가 아니란 것을 지적하고 싶으신 걸 겁니다. 당연히 코드도 길어졌을테구요. 아마 디자인 패턴을 공부하신 분이라면 제가 어떤 패턴을 암시하는지도 아실 겁니다.

예전에 제가 학교 다닐 때 Lippman책을 들고, 왜 subclassing과 subtyping을 구분하지 않느냐고 교수님께 따진적이 있습니다. 그 때 교수님께서 왈, Lippman은 C++전문가지 객체지향 전문가는 아니다라고 대답하시더군요.

어쨌든 gtk같은 괴물이 오픈소스화 되어 있다는게 놀랍고 고맙지 않나요. 좀 불편해도 감사하는 마음으로 씁시다.

You may say I'm a dreamer.
But I'm not the only one.

akbar의 이미지

...

sugarlessgirl의 이미지

음.. 논의된 내용들을 쭉 보면서 스스로 생각을 정리해봤는데요,

c 로 짜여진 gtk 는 그 자체가 목적물이 아닌 거군요.
gtk 의 다른 언어 지원은 c 버젼 gtk 와는 별개로 만들어진 것인줄 알았는데 그건 아닌가보네요.
왜 binding 이라는 용어를 사용했는지 이제 이해가 가네요.

c 로 짜여진 gtk 는 다른 언어로 최대한 바인딩되기 쉽게 만든 핵심이라고 보면 되겠군요.

이제야 "The answer is that C is more portable and standardly available than any other language" 이 말과 위에 어느분께서 말씀하신 "고급 언어로의 바인딩이 쉽다." 라는 말의 뜻이 뭔지 조금 알겠네요.

그러니까 gtk 가 C 로 만들어진 것은 C 로 객체지향을 구현하는게 좋아서가 아니라, gtk 에 언어제한성을 최대한 줄이고자 하는 의도인 것이라고 생각하면 되겠군요.

이제 Mono 프로젝트도 이해가 가네요.
'가려운 곳을 긁어주었다' 라는 말을 들었는데, 바로 .NET 의 다양한 언어 지원을 두고 한 말이었군요.

음 멋지군요..

쩝 근데.. C++ 말고는 타 언어 바인딩이 그리 잘 되있지 못한게 문제라면 문제인듯.. -_-;

혹시 제가 잘못 이해한 부분이 있으면 지적 부탁드립니다.
남들 다 아는 이야기 혼자 흥분해서 떠든것 같네요.. :oops:

여러분들 덕에 많이 배웠네요.

iolo의 이미지

제가 akbar님의 의도를 정확히 파악하지 못하고 있는것 같습니다만,
glib object system을 사용해 보시고(눈으로 라도) 하는 얘기라고 보기 힘드네요.
glib object system에는 인스턴스 생성자/소멸자, 클래스 생성자/소멸자, 상속, 인터페이스는 물론이고 가상함수도 구현되어 있습니다. 여기에 property, signal 시스템이 더해진 것이죠.
물론 표준 ANSI C만으로 입니다. 편법이라고 한다면 '교묘한 매크로' 들이겠죠.
QT가 C++을 쓰면서도 문법을 프리컴파일러로 확장한 것과는 좀 대조되는 면이있죠.
다음엔 어떤 객체지향의 특성이 빠져있다고 하고 싶으십니까?
한번에 말씀해주시면 한번에 있다 없다로 정리하도록 하죠. 지금처럼 예를 제시할때마다 하나씩 '이것도 없잖아?'라고 하시니 '태클을 위한 태클'처럼 보입니다.

glib object system이 최고의 객체시스템은 아닙니다.
전 자바로 밥먹고 살고 있고, 자바의 객체시스템이 더 좋습니다. 물론, 자바가 최고라고 생각하지도 않습니다.

그러나, 제가 알고 있는 많은 오픈소스 프로젝트(C를 사용하는)들이 나름의 객체 프레임웍을 갖고 있습니다만(같은 gnome계열인 libxml이나 gdome조차도!), glib object system만큼 포괄적이고 조직화된것은 아직 찾지 못했습니다.

C++의 OOP가 더 좋은데 왜 굳이 C였냐고 한다면,
자바나 C#의 그것이 더 좋은데... 왜 굳이 어렵게 C++로 하느냐고 말하고 싶군요. 결국 적당한 선에서 결론을 내려야 하는 것이고, GTK는 C, QT는 C++, SWT는 자바라고 결론은 내린 것이겠지요. GTK가 그 결론을 내린 근거는 앞에서 얘기한 바 있습니다.

제 생각은:
모두가 OOP를 할 필요는 없습니다. C에서 OOP를 사용해야 하는 상황이라면, glib object system은 충분히 좋다고 생각합니다.

GTK는 glib object system 덕분에 각각의 위젯을 여러사람이 나누어서 구현하고 상속을 통해 재사용하고 있습니다. 그러면 GTK에서의 glib object system의 목적은 달성된 것이지요.

C++의 객체 시스템을 이해하지 못하고 짠 코드는 C 코드보다 더 나쁩니다.
컴파일 시간만 잡아먹을 뿐이죠. 그런데, C++의 객체 시스템을 이해하지 못하고, C++로 짠 코드를 보면서 이건 스파게티다라고 한면 더 나쁩니다.
GTK의 객체 시스템에 대한 이해없이 GTK 코드를 보고 스파게티다라고 하시는 것은 '수박껍데기의 무늬가 어지러우니 이 수박은 맛이 없소'라고 하는 거죠. 그 수박속을 채우기 위해 일년동안 땀을 흘린 농부의 노동은 무시하고 말이죠.
남의 노동을 부정하고 싶으면 그 만한 근거가 있어야 하는 겁니다. 역시 제일 쉬운 근거는 난 돈이 많이 많으니, 맛없는(을것같은) 수박은 내가 다 사서 땅에 파묻어 버리겠소! 하는 거죠. 이 짠 코드를 보시오! 이것이 바로 객체지향이오!

이런 쓰레드의 마지막이 늘 그래왔던 것처럼,
"그래 그렇다면 잘난 니가 한번 더 좋게 만들어봐"라고 끝내길 바라지 않습니다.
그러나, "이건 이렇게 나쁘고, 저건 저렇게 고치면 좋을 것 같다"는 정도는 나와야 하지 않겠습니까?

목록이 좀 더 길어졌지만:
함수가 길어서, if문이 많아서, C로 만들어서 나쁘다는 건 넌센스입니다.(논리학에서 성급한 일반화의 오류라고 배운거 같은데 오래되서 가물가물하네요)
private이 없어서, 생성자/소멸자/상속이 없어서는 해당 사항없습이군요. 다 있습니다.(논리학에선 거짓원인의 오류이던가요?)

저도 이 쓰레드 덕분에 glib object system을 다시 보게 되니 좋습니다 :D

마지막으로 마인드를 넓히자는 것은 이 쓰레드의 범위를 넓히자는 얘기인가요?
예를 들면 '어떤 코드가 객체지향인가' 이런 제목으로 말입니다.
그렇다면 새 제목으로 쓰레드를 열면 됩니다.

이 쓰레드는 'GTK는 객체지향이 아닌, 스파게티코드인가?'에 대한 쓰레드입니다.

----
the smile has left your eyes...

세벌의 이미지

onemind555 wrote:
하나도 안 객체 지향 적이더군요..

소스를 보니 함수 하나가 수백줄이나 되고 완전히 if 문의 남발로 되어가지고 못 알아 보겠는 왜 이걸 객체 지향 적이라고 하죠...

이 글만 봤을 때는 플레임으로 갈 가능성이 많겠다고 생각했는데, 다행히 그렇게 되지는 않는군요.

alfalf의 이미지

break wrote:
쩝 근데.. C++ 말고는 타 언어 바인딩이 그리 잘 되있지 못한게 문제라면 문제인듯.. -_-;

PyGTK 사용해 보십시오. Python의 개체지향적 특징을 너무나 잘 활용하여 윈도우 프로그램밍을 가능하게 해줍니다.
제 경우엔 PyGTK 사용하다 필요한 일이 생겨 C로 gtk 프로그래밍 하려니 너무 힘이 들더군요. :wink:

하여간 처음 공부하기 힘들어서 그렇지 gtk 같이 굉장한 놈을 만든 여러분께 감사하며 사용하고 있습니다.

serialx의 이미지

Delphi/Kylix 용으로 있는것도 동작 잘합니다.

(사실 델파이는 작동 안했는데 수정하니까 되더군요.)

이런걸 해보면서 항상 gtk 가 왜 c 로 되었을까에 대한 의구심이 풀립니다.

제 생각에는 좀더 gtk 를 공부해보고 나서 gtk 를 평가하는게 좋지 않을가 합니다.

그리고 말그대로 C++ 로 oop 를 하려면 gtk-- 를 쓰면 되지 왜 잘 하지도 못하는 c 를 쓰시는지 이해하질 못하겠 습니다.

말그대로 자기에게 가장 잘맞는 언어를 사용하면 되는거 아닙니까. gtk 는 그것을 잘 충족시켜주고 있구요.

저야 델파이가 맞아서 델파이에 바인딩 시켜 씁니다.

gtk 가 c 로 된건 오히려 잘된일 아닌가요?

kuma의 이미지

저도 종종 길게 늘여서 천줄이상의 함수를 만들기도 합니다.

남들이 보면 구적적 프로그래밍도 이해 못한 사람이 짜놓았다고 생각할 정도입니다.

하지만 저는 저 나름데로의 핑계를 가지고 만들곤 합니다.

오직 한번 불려지는 함수를 줄수가 늘여진다는 이유로 함수 1개를 추가한다면 시스템에 필요없는 코드가 붙어지게 되고 이는 시스템의 속도를 저하하게 되는 유

또한 몇번의 대형 프로젝트를 거치면서 함수에 함수를 뛰어 넘어가는순간 프로그램의 분석은 무척 어려워진다는 사실을 경험하게 되었습니다. 그래서 프로그램은 위에서 밑으로 읽어 내려갈 수 있을때가 가장 쉬운 프로그램이라고 생각하게 되었지요.

gtk 뿐만 아니라 윈도우즈 프로그래밍을 해보신분이라면 아마 별로 이상하게 생각하지 않았을 코드일것 같습니다. 왜냐하면 구루나 기타 사이트에 올라온 윈도우즈용 화려한 콘트롤들은 대부분 극심한 노가다의 극치임을 봐왔을테니 이런 생각이 안들었을것이라고 생각합니다.

결코 짧은 코드만이 아름다운것은 아닙니다.

코드는 그 성격에 부합될때가 가장 아름답다고 생각합니다.

saxboy의 이미지

Quote:
하나도 안 객체 지향 적이더군요..

소스를 보니 함수 하나가 수백줄이나 되고 완전히 if 문의 남발로 되어가지고 못 알아 보겠는 왜 이걸 객체 지향 적이라고 하죠...

Quote:
XLib의 예제를 함 볼려고 gtk 소스를 분석 해봤는데... 이건 완전 스파게티 소스 입니다.

함수 하나가 몇백줄이나 되고 어떤 특별한 개념도 없이 XLib의 함수 이름에 GTK만 붙여 놓은 느낌 밖에 안 듭니다. 오히려 소스를 더 꼬아 놓아 알아 보지도 못하게 한 느낌입니다..

잘 되 있는건 코딩 컨벤션은 잘 지켜져 있더군요..

가끔 누구의 글을 보면 gtk가 객체 지향 적이라고 그러는데.. 내가 보기에는 객체 지향 하고 상당히 거리가 먼 스파게티 소스 밖에 안 됩니다..

flamewar 로 발전하기 딱 좋아보이는군요.

함수 하나가 수백줄인것과, if의 남발과 객체지향이 어떤 관계가 있는지 저는 잘 모르겠습니다. glib, gdk, gtk 로 연결되는 abstraction layer들이나 gtk나 xlib자체의 "철학"에 대해서 전혀 생각해보지 않으셨다고밖에는 상상이 되질 않는군요.

gtk에 첫눈에 보아서는 이해하기 힘든 hack들이 많긴 합니다만, 몇가지만 대강 알고 나면 아마 qt나 mfc 같은 위짓의 소스들보다 훨씬 읽어보기가 쉽습니다. 거짓말같겠지요. :D

aero의 이미지

krisna의 이미지

onemind555 wrote:
어떤 특별한 개념도 없이 XLib의 함수 이름에 GTK만 붙여 놓은 느낌 밖에 안 듭니다.

코드를 잘 읽어 보셨다면 gtk가 아니라 gdk를 붙였다는 것을 아셨을 텐데요 8)

gtk가 oop적이지 않다는 말은 좀 안타깝군요.
C를 이용해서 나름대로 개체지향적으로 구현하려고 노력한 코드입니다.

그리고 if를 사용하는 것과 OOP는 서로 상관관계가 없는 것 같군요.
(없다고 쓰고 싶지만 이렇게 말끝을 흐리지 않으면 위험하더군요 :)
C++로 만들어진 Qt의 코드를 보셨는지 모르겠는데요, Qt도 if문 많이 씁니다.

앞에서도 다른 분이 잘 지적하셨지만, C로 OOP를 구현하면 C++보다 복잡해 보이는 것이지,
복잡하다고 해서 그것이 OOP가 아닌것은 아닙니다.

이한길의 이미지

이 토론 읽어보니 젬있었습니다.
저도 GTK소스를... 윈도우즈에서 윈API를 함께 사용하기 위해서...
뒤져본 경험이 있습니다.. 그때 인스턴스 핸들과 윈도우 핸들을 얻을라구...
무지 노력했습니다.. 소스 뒤져봤습니다.. 뒤져보면서 느낀건데...
참 잘 썼다는 것이었습니다. 처음 뒤질때 무척 힘듭니다..
처음 접하면 보통 복잡해보이는게 아닙니다..
최소한 저한테는 그랬습니다..

하지만 열심히 뒤지다보니까... 조금씩 느껴진건데.. 물론 지금은..ㅜㅜ;) 생각 안납니다.
무척 잘 썼습니다. 특히 그 코드를 가지고 프로그래밍 하면 참 좋습니다..
사실 객체지향프로그래밍 방식이 아주 잘 맞는 분야중 하나가 GUI프로그래밍입니다.
다들 아시겠지만 눈에 보이는 부분에서는 객체지향이 딱 떨어집니다..
사실 객체지향 설명할때 예로써 사람이나 자전거 자동차같이 눈에 딱 떨어져 보이는 것에 대해서 말합니다.
하지만 내부적인 것들에 대해서 즉 눈에 보이지 않는 것에 대해서는 객체지향개념을 적용하려면 많은 훈련이 필요합니다.

결국 생각해보면 GUI부분은 객체지향적으로 구성하고 나머지는 전처럼 절차지향적으로 구성하면 편리합니다.
그런점에 있어서 GTK+는 참 잘 생각한 라이브러리라는 생각이 듭니다.

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

fender의 이미지

if/switch가 많으면 객체지향적이지 않다기 보다, 객체지향적이 아닌 절차지향적인 사고방식으로 프로그래밍 하고 있을 지 모른다는 의심을 할 수 있는 근거가 됩니다.

대표적인 경우가 커맨드 패턴, 추상화 팩토리, 스테이트 패턴 등이 반복적인 if 문을 대체할 수 있는 디자인 패턴이지만 모두 각각의 고유한 쓰임새가 있으며 아무 때나 if가 많다고 무조건 이들 패턴을 대입할 수 있는 건 아닙니다.

Gtk에 대해선 자세히 모르지만 Gtk의 소스에 if가 많다면 이는 언어 자체적으로 상속이나 오버라이딩, 접근 제어 등 객체지향 개념이 없는 C 언어로 객체지향적 개념을 구현하다보니 불가피한 부분이 아닌가 싶습니다. 이는 분명 자바나 C++로 코딩하면서 위에서 언급한 패턴으로 대치할 수 있는 if 절을 길게 쓰는 것과는 구분해야할 부분입니다.

크게 보면 '객체지향'이란 것도 C언어 입장에서 보면 하나의 디자인 패턴입니다. 해당 언어를 가지고 객체지향의 개념을 얼마나 잘 구현했는지가 중요한 것이지 if가 많고 적음은 그렇게 중요한게 아니라고 생각합니다.

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

morning의 이미지

본 토론을 읽다 보니 GTK를 공부하고 싶다는 생각이 듭니다.
그 동안 GTK에 대한 부정적인 견해들을 접해 보았는데
몰랐던 장점도 많다는 것을 알게되었습니다.
임베디드 쪽으로 보면 QT가 대세라고 여겼는데...
GTK도 많은 가능성과 저력이 있겠다 싶습니다.

조르바와 함께 춤을....

akbar의 이미지

...

fender의 이미지

akbar wrote:
iolo 님은 어쨋거나 다소 제한적인 객체로 밖에는 프로그래밍 할 수 없는
JAVA 를 주로 써서 그런지는 몰라도 JAVA 의 객체설계라는
테두리 안에서 벗어나지 못했다고 밖에는 생각할 수 없습니다.

좀 토론 주제와는 벗어나지만 어떤 점에서 자바의 객체지향 설계가 제한적이라고 생각하시는지요? 이야기가 길어 진다면 별도 쓰레드로 답글 다셔도 좋습니다.

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

saxboy의 이미지

Quote:
ANSI C 에서는 역시 상속이 없기 때문에 상속을 구현하려면
구조체 안에 구조체 멤버나 구조체 멤버포인터를 설계해야 하는데
이것은 상속이 아니고 포함입니다.
즉 is-a 관계로 표현하면 좋을 것을 오로지 has-a 관계로만
표현해야 한다는 것입니다.

정확합니다. 저도 C로 OO코드를 구현할때의 큰 단점 중의 하나가 바로 이놈이라고 생각합니다. 특히 이런 특성상 initialization과 finalization이 C++에서처럼 자동으로 이루어지지 못한다는 것은 생각보다 꽤 불편한 일이 되지요.
개념 그대로의 derivation 이 아닌 composition 이 되어야 한다는 것은 C의 약점이라고 해도 좋겠습니다. 하지만 이사실을 "이해하지 못하기 때문에" GTK 는 스파게티 코드라고 이야기 하는 것은 조금 문제가 있겠지요. 물론 akbar님께서 이런 뜻으로 이 내용을 언급하셨다고는 생각하지 않습니다. :-)

ps. 물론 이런 형태의 코드이기 때문에 솔직히 말하면 코드를 쓰는 입장에서는 피곤하지만 코드를 읽는 입장에서는 더 쉽습니다. :-)

iolo의 이미지

akbar wrote:

1) 데이타 은닉:

아래 코드에서


struct _GtkWidget GtkWidgetObj;
void* pVoid=GtkWidgetObj.priv;

라는 접근을 막을 수 있습니까.
이것이 데이타를 은닉한 겁니까.

은닉한것입니다.
GtkWidgetPriv라는 클래스는 .h파일에 선언되어 있지 않습니다.
.h에는 typedef를 통해서 이것이 구조체다라고만 얘기할뿐 구조체 멤버에 대해서는 언급하지 않았습니다.
그것을 void*로 접근(혹은 바이트배열로)한다는 것을 막을 수 없다고 데이터 은닉이 아니라고 한다면 C++에서도 별반 다르지 않습니다.
priv데이터를 다른 접근 불가능한 세그먼트에 넣어놓고 접근할때면 컨텍스트 스위칭해야 데이터 은닉이라고 하시고 싶으십니까?

akbar wrote:

2) 생성자 :

생성자함수는 객체를 선언할 때 수행되어야 하는데 그렇다면 gtk C 에서는
메크로를 통해 객체생성과 함께 생성자를 호출해야지 생성자만 정의함으로써
생성자가 호출되도록 할 수는 없습니다.
소멸자의 경우에 이 자동호출은 다시 애기를 하겠습니다.


됩니다. alloca에 대해서 좀더 찾아보시면 좋겠네요.
C++의 new/delete도 결국 따져보면 malloc/free에 불과한겁니다.
제한적인 객체밖에 사용할수없는(?) 자바의 경우처럼 VM(혹은 CPU)가 new인스트럭션을 지원하지 않는다면 별 뾰족한 수가 없죠. 과거 도스 시절의 터보파스칼처럼 런타임이 힙을 OS로 부터 한번에 할당받아서 독자적으로 관리하는 경우도 있겠군요.(결국 JVM이 하는 짓과 비슷하군요)

akbar wrote:

3) 가상함수:

가상함수는 함수포인터 배열이니 구현하는데 별로 어렵지 않습니다.
단 은폐하고 싶을때는 어떻게 하시렵니까.
은폐야 구현이 안되어도 아주 약간만 불편할 뿐이므로
이 부분은 자세히 언급하지 않고 넘어 가겠습니다.


가상함수를 단순 포인터 배열 정도로 하고 넘어간다면 오버라이딩 부터 여러갖 문제가 생깁니다. glib의 가상함수는 그 이상의 것입니다. boxing과 mashaling같은 C++에서도 지원하지 못하는 것까지 하고 있습니다. boxing만해도 java 1.5에와서야 지원되는 거죠.

akbar wrote:

4) 상속:
...
클래스 E 객체에서 클래스 A 의 멤버 m_a 에 접근할 일이 있을 때
E.m_a 하면 될 것을
E.m_D.m_C.m_B.m_a 처럼 써야 된다는 것이죠
메크로를 통해서 이 방법을 간단히 해놓았겠지만
상속을 우회적으로 구현하는 "포함" 이지 제대로 된 상속이 아닙니다.
상속을 쓸 곳에 포함이 있게 되면 제대로 된 설계가 아니며
C++ 플머들은 피곤해지가 십상입니다.
이것은 gtk C 가 OOP 가 아니라는 것은 아니며 플머에 따라
어지러울 수 있음을 지적하는 것입니다.
...

C++의 상속은 어떻게 구현되고 있다고 생각하십니까?
유감스럽지만 똑같습니다. 언어적으로 감추어준것 뿐이죠.
E.m_D.m_C.m_B.m_a = 123처럼 해야 하나요?
그냥 B(e).m_a = 123이라고 하면 그만이죠.
C++과의 차이는 B()라는 타입캐스팅이 필요하다는 거죠.
C에서는 부모클래스 타입 포인터에 자식클래스 포인터를 대입할 수 없으니까요.
GTK에서 많이 나오는(어지러운?) 타입캐스팅은 이 때문입니다.
그러나 그 사실을 이해하면 결코 어렵지도 않을뿐더러...
그 덕분에 실질적인 RTTI를 구현할 수 있습니다.
g_assert(GTK_IS_BUTTON(widget))이라고 한다고 단순히 매크로 일꺼라고 판단하지 마십시오.
GTK_IS_BUTTON은 실제로 RTTI를 수행하는 함수입니다.

akbar wrote:

5) 소멸자 :

소멸자는 C++ 의 경우 플머가 정의해 놓으면
객체의 수명이 다할 때 자동 호출됩니다.
ANSI C 에서는 소멸자 역할을 하는함수를 구현할 수 있을 망정
객체의 수명이 다할 때 자동 호출될 수는 없습니다.
사용자가 기억하고 있다가 어느 시점에 호출해 줘야 합니다.
C++ 의 소멸자는 컴파일하면 (리눅스의 경우) 실행 파일의 fini 영역에
잡히고 로더가 이 영역을 읽어서 메모리로 올리게 됩니다.
ANSI C 의 경우 소멸자라는 것이 없으므로 fini 영역도 필요가 없고
그래서 객체의 수명이 다할 때 자동 호출되는 경우란 것이
컴파일러 차원에서 지원하지 않는 한

절대로! 있을 수가 없습니다.!
-- 참고로 GCC 의 경우 이 문제를 해결하기 위해 fini 영역에
-- 실행 코드를 둘 수 있는 다음의 방법을 제공합니다.

    __attribute__ ((destructor)) void MyFinalize() 
    {
        /* 이곳에 종료코드를 넣으세요  */
    }    

반복합니다. ANSI C 에서는 소멸자 기능이 "불~~~가능합니다."


C++의 무엇이 자동으로 호출됩니까? C++에 가베지 콜랙션이라도 있다고 하시고 싶으신겁니까?
C++도 객체를 동적으로 할당한 경우에는 어차피 수동으로 해제해야 합니다.
참조계수를 관리해주는 라이브러리(직접 만들어도되고)를 쓴다면 그것을 사용한 경우에 한해서는 반자동 GC를 할 수도 있겠죠. 이것은 gtkmm(C++로 만든 녀석이죠)에서도 사용하는 방법입니다.
동적으로 할당하지 않은... 그러니까 스택이나 BSS에다 인스턴스를 직접할당하는 방법은 GTK에서는 불가능합니다.
그러니까
GtkLabel global;

func(){
GtkLabel local;
...
gtk_label_set_text(&global, ...)
gtk_label_set_text(&local, ...)
}

같은건 애초에 불가능합니다. OOP랑 관계 있는 문제인가요?
동적으로 할당된 경우라면 완전히 얘기가 다르죠.
이때는 최초의 인스턴스가 만들어질때 해당 클래스의 initializer가 호출되고,
해당 인스턴스의 생성자(constructor)가 호출됩니다.
물론 해제될때 finalizer가 호출됩니다. C++과 무엇이 다르죠?

akbar wrote:

iolo 님은 어쨋거나 다소 제한적인 객체로 밖에는 프로그래밍 할 수 없는
JAVA 를 주로 써서 그런지는 몰라도 JAVA 의 객체설계라는
테두리 안에서 벗어나지 못했다고 밖에는 생각할 수 없습니다.

그렇다면 akbar님께서는 어떤 강력한 OOP언어를 쓰십니까?
스몰토크가 아니라면 JAVA에게 객체에 대해서 딴지를 걸만한 언어가 얼마나 될까요?

akbar wrote:

자, 저는 이제 gtk 는 잘 만든 OOP 이긴 한데
(과장해서) 소스는 스파게티 같다고 말하겠습니다.

iolo wrote:

이 짠 코드를 보시오! 이것이 바로 객체지향이오!

이 짠 코드를 보시오! 이것이 바로 객체지향이지만 스파게티요! --- (과장법..)


예 그 코드를 보여주세요. 저는 왜 코드를 안보여주냐고 하지 마십시오.
여기에 GTK소스를 올릴수는 없는 일 아닙니까? 그렇다고 골라서 보여주면 잘된거 골라서 보여준다고 하실테니.. 무의미한 일이지요.
하지만 스파게티를 보여주는 건 쉬운일 아닙니까?
만줄 중에 제일 스파게티 100줄만 찾으면 되는 일이니...

akbar wrote:

-- 근데 어느분 말처럼 gtk C 가 잘짜여진 OOP 이니 자꾸 분석하다보면
-- MFC 보다 쉽게 친해질 것 같습니다.

위에서 저렇게 말씀을 안하셨으면 좋은 얘기일 것을... 윗글을 읽고 나니 이 마지막 멘트가 비아냥 거림으로 들리는 군요.

매번 드리는 말씀이시만 위에 sangu님이 올려주신 url따라가서 glib object system의 겉핥기라도 하시는게 어떻겠습니까?
MFC와 GTK를 비교할만한 성격의 것은 아닙니다만...
GTK와 비교하시고 싶으시면 그냥 win32 api이죠.
MFC와 비교하시고 싶으시면 bekery/gtkmm라는 녀석이 따로 있습니다.

저도 꼬리에 한마디 더하죠.
GTK는 널리 쓰이는 좋은 라이브러리입니다. 그걸 스파게티든 라면이든 비판하고 싶으면 대단한 자신감과 이를 뒷받침하는 실력, 그리고 체계적인 접근이 필요한 겁니다. akbar님도 상당한 경력을 가진 분으로 보입니다만, 스스로를 오웬타일러 정도라고 생각하십니까? 저도 20년을 이짓으로 용돈벌고 학비대고 밥먹고 살고 있지만 오웬을 보고 있으면 까마득하고 어지럽네요...
(오웬을 모르면 인신공격이 될수도 있겠네요. 그런 의도는 전혀 없습니다.)

----
the smile has left your eyes...

yundream의 이미지

iolo wrote:

저도 꼬리에 한마디 더하죠.
GTK는 널리 쓰이는 좋은 라이브러리입니다. 그걸 스파게티든 라면이든 비판하고 싶으면 대단한 자신감과 이를 뒷받침하는 실력, 그리고 체계적인 접근이 필요한 겁니다. akbar님도 상당한 경력을 가진 분으로 보입니다만, 스스로를 오웬타일러 정도라고 생각하십니까? 저도 20년을 이짓으로 용돈벌고 학비대고 밥먹고 살고 있지만 오웬을 보고 있으면 까마득하고 어지럽네요...
(오웬을 모르면 인신공격이 될수도 있겠네요. 그런 의도는 전혀 없습니다.)

여기 글들을 읽다 보면 자주 이런얘기가 나오는군요.. 자신감과 실력이 없으면 논하지 마라..
전 그렇게 생각하지 않습니다.
GTK초급 사용자라면 그나름대로,, 고급 사용자라도 그 나름대로 GTK에 대한 의견이 있을 수 있는 겁니다.
반드시 GTK의 모든 소스코드르 꿰뚫고 그정도 만들 실력이 되어야만 GTK에 대해서 비판할 수 있는 건 아니라고 생각됩니다.
만약 그렇다고 한다면 국회의원들이 당신들은 정치도 모르면서 참견하지 말고 지켜보기나 하라고 말하는 것과 다른게 뭐가 있습니까.
플밍 초보라면 초보인데로, 고급 플머라면 또한 그 나름대로, 설사 GTK는 단지 GNOME를 통해서 맛만본 Windows환경 개발자라 할지라도 그 수준에서 충분한 비판이 나올 수 있다고 생각됩니다. 특정 작은 부분만을 놓고 본다면 비록 초보 플머라 할지라도 고급플머보다 나은 제안을 하는 경우도 흔히 볼 수 있구요...

kukuman의 이미지

Quote:
여기 글들을 읽다 보면 자주 이런얘기가 나오는군요.. 자신감과 실력이 없으면 논하지 마라..
전 그렇게 생각하지 않습니다.
GTK초급 사용자라면 그나름대로,, 고급 사용자라도 그 나름대로 GTK에 대한 의견이 있을 수 있는 겁니다.

이 부분은 동감합니다만... (이건 정말 그렇긴 하죠)

Quote:
하나도 안 객체 지향 적이더군요..

Quote:
XLib의 예제를 함 볼려고 gtk 소스를 분석 해봤는데... 이건 완전 스파게티 소스 입니다.

Quote:
가끔 누구의 글을 보면 gtk가 객체 지향 적이라고 그러는데.. 내가 보기에는 객체 지향 하고 상당히 거리가 먼 스파게티 소스 밖에 안 됩니다..

이런 정도의 글은 좀 심하지 않았나요...
의견이라기 보다는 폄하의 내용쪽에 가까운 듯 보입니다...
그것도 적절한 논거도 없이요... (특히 이 부분이 크죠...)

Be at a right place at a right time...

iolo의 이미지

yundream wrote:

여기 글들을 읽다 보면 자주 이런얘기가 나오는군요.. 자신감과 실력이 없으면 논하지 마라..
전 그렇게 생각하지 않습니다.
GTK초급 사용자라면 그나름대로,, 고급 사용자라도 그 나름대로 GTK에 대한 의견이 있을 수 있는 겁니다.
반드시 GTK의 모든 소스코드르 꿰뚫고 그정도 만들 실력이 되어야만 GTK에 대해서 비판할 수 있는 건 아니라고 생각됩니다.
만약 그렇다고 한다면 국회의원들이 당신들은 정치도 모르면서 참견하지 말고 지켜보기나 하라고 말하는 것과 다른게 뭐가 있습니까.
플밍 초보라면 초보인데로, 고급 플머라면 또한 그 나름대로, 설사 GTK는 단지 GNOME를 통해서 맛만본 Windows환경 개발자라 할지라도 그 수준에서 충분한 비판이 나올 수 있다고 생각됩니다. 특정 작은 부분만을 놓고 본다면 비록 초보 플머라 할지라도 고급플머보다 나은 제안을 하는 경우도 흔히 볼 수 있구요...

자신감과 실력이 없으면 무엇인가 근거라도 있어야 합니다.
그게 아니면 그냥 비방일 뿐, 토론이 될리가 없죠.
저는 나름대로 GTK를 옹호하는 입장에서 근거를 제시했다고 생각합니다.
''모르면 빠져...''나 ''그렇게 잘났으면 니가 한번 만들어봐''라고 한게 아닙니다.
모르면 모른다고 하고, 잘못된것 있으면 짚어보자는 거죠 .

정치를 모르면 참견하지 않는게 맞겠지요. 근데 자본주의 사회에 살면서 정치를 모르는게 가능할까요? 적어도 자기와 관련된 사안에대해선 얘기할 수 있죠.
누가 ''한국정치는 되먹지 못했어''라고 하면 어떤가요? 초등학교 어린이라도 역사에 대한 인식이 뒷받침이 되어서 하는 얘기라면 들을 수 있습니다. 그렇지 않다면 70먹은 할아버지가 해도 공염불이죠.

밥먹고 합시다~

----
the smile has left your eyes...

정태영의 이미지

akbar wrote:
1) 데이타 은닉:

아래 코드에서

gtkwidget.h: 

typedef struct _priv; 

struct _GtkWidget
{ 

  struct _priv* priv; 

  /*public ...*/ 
  gtk_widget_show(); 
... 
} 

gtkwidget.c: 

struct _priv { 
/*private */ 
... 
} 

라고 한다면


struct _GtkWidget GtkWidgetObj;
void* pVoid=GtkWidgetObj.priv;

라는 접근을 막을 수 있습니까.
이것이 데이타를 은닉한 겁니까.

실제로 pango와 gtk소스를 참고해서 막 이상한짓을 하다보면 -_-;;
c소스에서 구조체의 멤버로 분명 어떤 변수가 있는데 -_-;;

접근하지 못합니다..
..

글쎄요 c로 구현하는 OOP는 정확히 어떤 식으로 그런 게 가능하게 하는지는 모르겠습니다만은.. 예전에 pango layout 을 이용해서.. 현재 string이 그려질때 가로길이를.. 어느정도 이하로 되게.. 하고 나머지는 생략하는걸 구현할때..

좀 더 나은 방법이 있을거 같어서 -_-;; 멤버에 직접 접근해서.. 하려고 했었는데.. 하여튼 그 멤버변수에 접근할 수가 없어서.. 실패했던 기억이 납니다..

요는 데이타 은닉이 실제로 구현되어져 있다는 거죠..
C++이 아닌 c레벨에서 구현한 OOP로도요..

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

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

akbar의 이미지

...

iolo의 이미지

그럼 좋은 C++많이 쓰십시오.
고생많이 하셨습니다.

----
the smile has left your eyes...

akbar의 이미지

...

mastercho의 이미지

onemind555 wrote:
XLib의 예제를 함 볼려고 gtk 소스를 분석 해봤는데... 이건 완전 스파게티 소스 입니다.

함수 하나가 몇백줄이나 되고 어떤 특별한 개념도 없이 XLib의 함수 이름에 GTK만 붙여 놓은 느낌 밖에 안 듭니다. 오히려 소스를 더 꼬아 놓아 알아 보지도 못하게 한 느낌입니다..

잘 되 있는건 코딩 컨벤션은 잘 지켜져 있더군요..

가끔 누구의 글을 보면 gtk가 객체 지향 적이라고 그러는데.. 내가 보기에는 객체 지향 하고 상당히 거리가 먼 스파게티 소스 밖에 안 됩니다..

제 눈에는 리펙토링이 안되어 있다는 생각 밖에 안드네요 :oops:

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

akbar의 이미지

...

gilsion의 이미지

아 짜증나.
이런쓰래드는 안잠그나요?

ps. 옆사람이 욕은 속으로 하라고 다그치는군요 :evil:

fender의 이미지

이런 걸 보면 게시판이 엉망이 되는 이유는 정치와 같은 특정 주제를 선택했기 때문이아니라 무슨 주제든 간에 논지와도 관계없이 인신공격을 일삼는 일부가 물을 흐리기 때문이라는 걸 알 수 있습니다.

그런 몰지각한 일부 때문에 이렇게 건설적인 방향으로 갈 수 있는 쓰레드 전체를 잠궈서 여러사람이 피해를 보게 하는 것보다는 그 때마다 적절히 관리자가 나서서 주의를 주거나 글을 삭제하는게 더 낫다고 봅니다.

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

neocoin의 이미지

해당 분야를 배우고 싶다는 생각이 드네요.
어쩌다 저렇게 인신공격으로 발전할 꺼리들이 있는지 확인해 보고 싶네요

thedee의 이미지

플레임성으로 시작해서 약간 안좋게 끝나긴 했지만 참 배울 것이
많았던 스레드 같습니다. 긴장감도 있고~
좋은 정보 많이 얻고 갑니다.

advanced의 이미지

akbar wrote:
iolo wrote:
그럼 좋은 C++많이 쓰십시오.
고생많이 하셨습니다.

... 그리구 이쯤에서 끝내는 것은 판단 잘 하신겁니다.
이 이상 얕은 C++ 경험으로 C++ 이 뭐 어때내 ... 운운 했더라면
다른 C++ 플머들한테 무슨 창피를 당할 지 모르는 위태로운 상황이었습니다.


흠...다시 자신의 글을 읽어보세요

부끄럽지 않으십니까?

- advanced -

akbar의 이미지

...

crimsoncream의 이미지

뭐 감정적인 면이 부각되기는 했지만 내용들은 재밌지 않았나요.
외적인 규제가 없더라도 이런 경우가 몇번 반복되면 쓰시는 분들이 알아서 체력적으로나 정신적으로나 소모적인 면은 빼고 쓰시게 되지 않을까 싶네요.
적극성 표출의 사이드이펙트 쯤으로 여기고 넘어갑시다. 이거저거 다잠그면 예의바른 농담따먹기만 넘치는 사이트가 될까바 무섭습니다.

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

onemind555의 이미지

제가 쓰레드를 달았는데 꽤 많은 글이 올라 왔더군요...

제 글에는 감정적인 판단이 들어있는건 사실입니다.

제가 왜 저런 글을 쓰게 되어냐 하는 정황을 말하겠습니다..
XLib의 특정 기능의 사용법을 알기 위해 gtk에서 어느 특정한 부분의 소스를 분석 하려고 gtk소스를 분석 했습니다. 특정한 툴은 사용 하지 않았고 오직 편집기가지고 함수명을 검색해서 인간 디버그가 되어 분석 했습니다. 이리 저리 보다가 3시간 가까이 넘겼습니다. 동작은 알아도 소스를 보면 알아 먹지를 못하겠더군요. 정말 무의미한 행동을 하고 있다고 생각 하니 짜증나서 글을 올린 겁니다.
3시간 정도 가지고 뭐 그러냐 하는 사람도 있겠죠.. 3 - 4시간이면 QT라이브러리의 white page 50페이지짜리 간단한 문서 읽을 수 있는 시간 입니다.

gtk 라이브러리의 외부 (User 가 접근 하는 부분)는 물론 객체 지향 개념을 적용 했다는 것은 인정합니다. 그리고 gtk++이라고 해서 여러 언어로 적용 한 것도 대단 하다고 생각합니다..

그렇지만 . gtk라이브러리의 내부 소스는 정말 뭐 이런 소스가 있냐! 짜증 낼 만한 소스는 맞습니다. 반론 하고 싶으면 구석 구석 gtk소스 분석 해보시고 반론 하시기 바랍니다. GObject같은 핵심 부분만 보고 잘짜여진 소스라고 하지 마시기 바랍니다. 핵심적인 부분은 손이 많이 가기 때문에 잘 짜여져 있습니다.

지금은 qt소스를 보고 있습니다. qt도 if문 남발의 느낌을 주기는 하지만 알아 먹을 만 하더군요. 세상에 완벽한 소스는 없겠지만 그래도 다른 사람이 알아 먹게는 짜놔야 하는것 아닌가요.

마지막으로....
종종 어떤 글을 보면 " C로 객체 지향을 구현한 소스를 보려면 gtk를 보세요" 라는 글이 올라오던데 이글에 반론 하면 "디자인 패턴 몇개 구현 하려고 객체 지향이라는 개념이 생긴게 아닙니다. 소스의 유지 보수를 쉽게 하고 개발 속도를 올리는 것이 객체 지향이라는 개념이 생긴 거라고 생각 합니다..즉 유지 보수가 쉽지 않는 소스는 객체 지향적인 소스가 아닙니다."

-----------^^ ^^ ^^ ^^ ^^ ----------
..........................................................

fibonacci의 이미지

onemind555 wrote:
마지막으로....
종종 어떤 글을 보면 " C로 객체 지향을 구현한 소스를 보려면 gtk를 보세요" 라는 글이 올라오던데 이글에 반론 하면 "디자인 패턴 몇개 구현 하려고 객체 지향이라는 개념이 생긴게 아닙니다. 소스의 유지 보수를 쉽게 하고 개발 속도를 올리는 것이 객체 지향이라는 개념이 생긴 거라고 생각 합니다..즉 유지 보수가 쉽지 않는 소스는 객체 지향적인 소스가 아닙니다."

리플들을 제대로 읽어보셨으면 합니다. GTK+를 구현한 소스가 복잡한 것과, GTK+가 OOP를 지향한 것은 별개의 문제입니다. 즉 OOP언어가 아닌 C를 이용하여, 생성, 소멸, 상속등의 OOP개념을 구현할수 있다는 것이 GTK+가 OOP적인 것이라는 의미입니다. 사람들이 GTK+를 참고하라는 것도, C에서 부족한 OOP적 문법을 대체하는 부분을 어떤 개념을 도입하여 구현하였는지를 참고하라는 것입니다. GTK+ 라이브러리를 이용하는 프로그래머에게 GTK+가 OOP이면 되는것이지, GTK+ 자체를 뜯어 고치는 사람에게 OOP일 이유는 없습니다. OOP를 구현하기 위한 소스 자체가 OOP라고 생각하셨다면 잘못 생각하신것입니다.

No Pain, No Gain.

krisna의 이미지

onemind555 wrote:

XLib의 특정 기능의 사용법을 알기 위해 gtk에서 어느 특정한 부분의 소스를 분석 하려고 gtk소스를 분석 했습니다. 특정한 툴은 사용 하지 않았고 오직 편집기가지고 함수명을 검색해서 인간 디버그가 되어 분석 했습니다. 이리 저리 보다가 3시간 가까이 넘겼습니다. 동작은 알아도 소스를 보면 알아 먹지를 못하겠더군요. 정말 무의미한 행동을 하고 있다고 생각 하니 짜증나서 글을 올린 겁니다.
3시간 정도 가지고 뭐 그러냐 하는 사람도 있겠죠.. 3 - 4시간이면 QT라이브러리의 white page 50페이지짜리 간단한 문서 읽을 수 있는 시간 입니다.

지금은 qt소스를 보고 있습니다. qt도 if문 남발의 느낌을 주기는 하지만 알아 먹을 만 하더군요. 세상에 완벽한 소스는 없겠지만 그래도 다른 사람이 알아 먹게는 짜놔야 하는것 아닌가요.

gtk를 많이 쓰는 저로서는 쓰레드가 gtk가 후졌다는 방향으로 흘러가는 것 같아서 좀 서운하긴 합니다 :)

구체적으로 Xlib의 어떤 기능을 알기 위해서 gtk의 어떤 부분과 qt의 어떤 부분을 참고 하셨는지 알려 주시면 좋겠습니다. 저도 어떤 차이가 있는지 제대로 한번 보고 싶습니다.

logout의 이미지

akbar wrote:

그랬었나요. 근데 제 손으로 차마 제 글을 지울 용기는 나지 않습니다.
게시판 관리자님이 제글을 모두 지워주셨으면 합니다.

쓸데없이 또 쓰레드의 글을 군데군데 지워서 죄없는 쓰레드까지
누더기로 만드는 경우는 만들지 마시기 바랍니다. 그리고 다음부터는
인신공격성 발언은 자제하시기 바랍니다.

"I conduct to live,
I live to compose."
--- Gustav Mahler

mastercho의 이미지

fibonacci wrote:
onemind555 wrote:
마지막으로....
종종 어떤 글을 보면 " C로 객체 지향을 구현한 소스를 보려면 gtk를 보세요" 라는 글이 올라오던데 이글에 반론 하면 "디자인 패턴 몇개 구현 하려고 객체 지향이라는 개념이 생긴게 아닙니다. 소스의 유지 보수를 쉽게 하고 개발 속도를 올리는 것이 객체 지향이라는 개념이 생긴 거라고 생각 합니다..즉 유지 보수가 쉽지 않는 소스는 객체 지향적인 소스가 아닙니다."

리플들을 제대로 읽어보셨으면 합니다. GTK+를 구현한 소스가 복잡한 것과, GTK+가 OOP를 지향한 것은 별개의 문제입니다. 즉 OOP언어가 아닌 C를 이용하여, 생성, 소멸, 상속등의 OOP개념을 구현할수 있다는 것이 GTK+가 OOP적인 것이라는 의미입니다. 사람들이 GTK+를 참고하라는 것도, C에서 부족한 OOP적 문법을 대체하는 부분을 어떤 개념을 도입하여 구현하였는지를 참고하라는 것입니다. GTK+ 라이브러리를 이용하는 프로그래머에게 GTK+가 OOP이면 되는것이지, GTK+ 자체를 뜯어 고치는 사람에게 OOP일 이유는 없습니다. OOP를 구현하기 위한 소스 자체가 OOP라고 생각하셨다면 잘못 생각하신것입니다.

MFC와 비슷한 경우네요.......

속은 완전 API로 짜여진 -_-;.................

그렇다고 MFC가 객체지향 프레임웍이 아닌건 아니니까요......

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

logout의 이미지

krisna wrote:

gtk를 많이 쓰는 저로서는 쓰레드가 gtk가 후졌다는 방향으로 흘러가는 것 같아서 좀 서운하긴 합니다 :)

구체적으로 Xlib의 어떤 기능을 알기 위해서 gtk의 어떤 부분과 qt의 어떤 부분을 참고 하셨는지 알려 주시면 좋겠습니다. 저도 어떤 차이가 있는지 제대로 한번 보고 싶습니다.

gtk+ 소스까지 볼 실력은 안되지만.. 저도 그 부분이 무척 궁금합니다. gtk+ 소스를 보지 않고서는 달리 분석할 방법이 없었나요?

"I conduct to live,
I live to compose."
--- Gustav Mahler

blacknblue의 이미지

왕초보가 이런말 하면 안되겠지만..
이 쓰레드를 통해 많은거 알게 된건 감사하지만
쓰레기 같은 상황 목도하게 된건 하나도 감사 안하네요...

뭐가 그렇게 각박하게 만드는건지...

정치 사이트에 들어가서 하듯이 육두문자 날리고 싶은 충동...
참아야 하네요..

힘든세상 조금씩만 살피며 가자고요....

에효...

agolta의 이미지

누가 분명히 올려놨죠. GTK를 C로 만든 이유에 대해서(다른 언어와의 바인딩)... 그 이유가 C++로 만들어야 하는 타당성보다 크기 때문이겠죠.(Trade off)
당연히 C++로 구현된 객체시스템이 객체개발에 여러모로 편리합니다. 하지만 GTK를 C로 만든 이유가 더 크기 때문이겠지요?

이 토론을 지켜보면서 이런생각이 들더군요...
C++ 컴파일러 소스를 보면 어떨까?
하나도 객체지향적이지 않은 컴파일러 소스가 사람을 열받게 하지 않을까?

컴파일러 소스의 객체지향성은 컴파일러 제작자가 아니면 신경쓸 일 없습니다.
대다수 일반 프로그래머들은 컴파일러가 제공하는 문법을 가지고 설계사상에 맞게 설계하고 개발할 뿐이죠...

일반적인 객체지향 이론을 이해하고 있는 일반 프로그래머들이라면 GTK로 객체지향 개발을 하는데 별 무리가 없다고 생각됩니다.(약간의 문법의 번거로움은 언어상의 차이라고 보면 문제가 없습니다. C++ 객체문법보다 자바나 Python 객체문법이 훨씬 편하고, C++은 왜이리 사람을 귀찮게 하는 문법으로 구성되어 있냐고 불평할 수도 있다는 것이지요. 그렇다고 C++로 자바나 Python보다 객체지향개발을 못한다는 것은 아니니까요. 불편할 뿐이지 불가능한게 아니죠. 그리고 그 불편함을 택하는 이유는 Trade off 때문이지요.)

논의 주제는
1. GTK를 사용해서 객체지향 개발을 할 수 있느냐?
2. GTK 자체가 객체지향적으로 개발되어 있느냐?

둘중의 하나일텐데, 처음 글타래를 시작한 사람은 2번으로 올린 것이고, 이어지는 글타래들은 1번과 2번이 혼동되어 있군요.

A. C++로 객체지향 개발을 할 수 있느냐?
B. C++자체가 객체지향적으로 개발되어 있느냐?

이런 두가지 주제와 일맥상통한다 볼 수 있을 것 같습니다.
사실 B의 주제가 무슨 의미가 있겠습니까? 어짜피 컴파일러 수준의 소스라면 이해할 수 있는 사람도 극소수일테고, 저수준의 코드가 남발되어 있을텐데, 객체지향적이냐 아니냐가 의미가 있을까요?

객체지향이 나온 이유는 결국 은닉성의 필요성이 발단이 되었죠. 블랙박스화 시키고 인터페이스만 제공해서 프로그래머들이 블랙박스 안의 내용을 볼 필요가 없게 만든다는 것이죠. GTK도 그런 목적을 충분히 달성하고 있고, 블랙박스안의 내용을 전혀 보지 않아도 투명하게(Transparent) 프로그램하는데 전혀 문제가 없습니다. 그런데도 굳이 블랙박스 안을 들여다 보겠다면 그 이유가 있어야 겠지요. 잘난척을 하고 싶다던지, 이런 기능을 어떻게 구현했는지 배우고 싶다던지, 아니면 블랙박스의 기능을 추가하고 싶다던지...
블랙박스 안을 들여다 볼려면 블랙박스를 사용하던 시각과는 다르게 들여다 봐야 하지 않을까요? 즉 위의 2나 B의 관점으로는 접근이 불가능 하다는 것이죠.

별로 논쟁거리가 되지 않을 만한 주제인데 서로 주제가 겹치면서 난장판이 된 것 같군요.

madhatter의 이미지

agolta wrote:
별로 논쟁거리가 되지 않을 만한 주제인데 서로 주제가 겹치면서 난장판이 된 것 같군요.
별로 난장판인 듯한 생각은 안드는데요. :)
주제는 GTK 가 객체지향이냐...에서 시작했지만 ANSI C로 얼마만큼 객체지향을 구현할 수 있는가, GTK에 있어서 그것이 효율적이었는가, GTK가 효율적으로 객체지향을 구현했는가 정도로 받아들이면 별 무리가 없을 것 같습니다.
여기서 각 언어에 대한 애착과 자긍심이 겹쳐져서 중간에 이상한 방향으로 흐르긴 했지만 배운 것도 많고 나름대로 의미도 있었다고 생각합니다.
세벌의 이미지

처음엔 플레임으로 가기 딱 좋은 글로 시작되었는데 생각과는 다르게 좋은 방향으로 진행되고(물론 중간 중간에 읽기 껄끄러운 내용도 있었지만) 배울 만한 내용도 많이 있었던 것 같네요.

명예의 전당에 올릴 만한 글이라 생각되는데...
어? 그런데 명예의 전당 만들었다가 참여가 없어서 도로 없앴나요? :roll:

agolta의 이미지

madhatter wrote:
agolta wrote:
별로 논쟁거리가 되지 않을 만한 주제인데 서로 주제가 겹치면서 난장판이 된 것 같군요.
별로 난장판인 듯한 생각은 안드는데요. :)
주제는 GTK 가 객체지향이냐...에서 시작했지만 ANSI C로 얼마만큼 객체지향을 구현할 수 있는가, GTK에 있어서 그것이 효율적이었는가, GTK가 효율적으로 객체지향을 구현했는가 정도로 받아들이면 별 무리가 없을 것 같습니다.
여기서 각 언어에 대한 애착과 자긍심이 겹쳐져서 중간에 이상한 방향으로 흐르긴 했지만 배운 것도 많고 나름대로 의미도 있었다고 생각합니다.

ANSI C의 객체지향 효율성이 당연히 떨어진다는 것은 상식이죠...
GTK 객체 시스템으로 개발할때는 객체지향의 개념을 충실히 반영하여 번거롭지만 불가능하지 않다는 것도 당연한 상식이죠.
과연 그 번거로움과 ANSI C로 구현했을때의 장점(다언어 바인딩)의 Trade off의 가치가 어떨까하는 쪽으로 논쟁이 흘러갔으면 좋았을 뻔 했습니다.

GTK를 C++로 개발했을때의 GTK를 사용한 개발의 편의성과 다언어 바인딩상의 문제점.
자바나 Python으로 개발했을때의 개발편의성과 다언어 바인딩상의 문제점.
그래서 종합적으로 개발편의성을 희생하고 다언어 바인딩을 위해 GTK를 ANSI C로 개발했어야 하는 필연성... 이런식으로요.(훨씬 가치있고 배울게 많은 논쟁이지 않을까요?)

그냥 상식적인 사항을 가지고 상식을 확인하기 위한 감정적인 논쟁이라 소모적으로 느껴졌습니다.

iolo의 이미지

흠 쓰레드의 한 가운데 있었던 사람이니 제가 정리할 수 있는 건 정리해보겠습니다.

이 쓰레드의 주제는 쓰레드를 시작한 본인이 말한대로
GTK는 객체지향이 아니고, 스파게티 코드인가?였습니다.

저는 아니라고 생각했고, 거기에 대해서 짧으나마 아는 것들을 덧붙였습니다.
C++이 더 객체지향적인지 자바가 더 객체지향적인지에 대해서 얘기하고 싶은 의도는 없었습니다.

객체지향을 얘기할때 늘 나오는 세가지가 은닉성, 상속성, 다형성를 놓고 본다면, glib object system(GTK가 아니라는 것을 강조하기 위해서 계속 이렇게 썼습니다)은 위의 세가지를 충분히 만족하고 있다라는 것입니다.

이것이 객체지향적이 못하다라는 주장에 대한 반론 근거들은 충분히 제시되었다고 생각합니다. 납득을 못한다고 해서 서로가 끝없는 논쟁을 계속할 이유는 없죠. 자기 지식/논리를 바꾸기 싫다면 그대로 있으면 되는 거죠. 자기 주장을 납득하지 않는다고 바보 멍청이라고 하지 마십시오.

이 쓰레드를 보시는 분들 중에서
- 절차지향언어에서 객체지향을 어떻게 성취해 나가나는가, 혹은 그 결과물을 이용할수 없을까가 목적이라면,
GTK 전체를 보실 필요는 없습니다. 앞에 sangu님께서 올려주신 url에 좋은 글들(특히 GObject tutorial)을 보시면 됩니다.

- 객체지향이 아닌 Xlib(혹은 다른 호스팅 GUI)을 어떻게 객체화 했는가가 관심이라면, Gdk라는 래핑 레이어(gdk는 x11, win32등의 다양한 호스팅 GUI위에 놓여집니다; 이것은 객체지향적이라기보다는 말그대로 래퍼입니다.)를 보시고(xlib을 잘 아시는 분이라면 볼것도 별로 없을겁니다.), 이에 대한 객체 모델링인 GTK를 보시면 됩니다.

다시 정리하면:
- glib object system의 구현 자체는 전혀 객체지향적이 아닙니다. 철저히 오늘날의 C로 만든 C컴파일러가 있기 위해선 최초에 어셈블리어로 만든 무언가가 있었던 겁니다. 물론 그전에 기계어로 만든(핸드 어셈블한) 어셈블러가 있었겠죠.

- gdk도 그다지 객체지향이 아닙니다. 래핑 레이어일 뿐입니다. x11의 구조체에 대한(혹은 win32 gdi에 대한) 박스 객체들(혹은 구조체들)일 뿐입니다.

- gtk는 glib과 gdk가 돌아간다는 전제하에 만들어진 객체지향 GUI 툴킷입니다.

마지막으로 광고하나 하죠~.~
GTK가 맘에 안들고 어떻고에 무관하게. glib(glib object system말고!)은 매우 좋은 라이브러리 입니다. 매우 많은 플랫폼에서 잘 굴러가고, C의 시스템 의존적인 부분들을 깔끔하고 효율적인 방법으로 감싸 줍니다. GTK가 필요없다, 쓰지않겠다고 하더라도 glib은 한번 들여다 볼만합니다. 윈도에서 프로그래밍하더라도 말이죠~.~

----
the smile has left your eyes...

akbar의 이미지

...

whiterock의 이미지

iolo wrote:

마지막으로 광고하나 하죠~.~
GTK가 맘에 안들고 어떻고에 무관하게. glib(glib object system말고!)은 매우 좋은 라이브러리 입니다. 매우 많은 플랫폼에서 잘 굴러가고, C의 시스템 의존적인 부분들을 깔끔하고 효율적인 방법으로 감싸 줍니다. GTK가 필요없다, 쓰지않겠다고 하더라도 glib은 한번 들여다 볼만합니다. 윈도에서 프로그래밍하더라도 말이죠~.~

저도 이부분에 공감합니다. C로 프로젝트를 진행하신다면 한번 참조 해보고 응용해볼만합니다. 제가 일하는 곳에서 프로젝트 구현시 C를 이용을 하는데 glib을 참고로 해서 멀티 플랫폼 라이브러리를 구축을 해서 사용을 하죠...: )

흐음...

mastercho의 이미지

akbar wrote:

빌 게이츠가 윈도우 NT 개발 초기에 C 로 얼마간 진행이 되었던 도중에
C++ 로 짜라고 지시를 내렸읍니다.
이 지시에 거부에 한 사람이 몇명있습니다.
그 중 한 사람이 DEC 사에서 근무하면서 높은 명성을 날린,
그리고 그리고 빌게이츠가 직접 스카우트했던
NT 개발팀 총책임자 데이빗커틀러입니다.
C 로도 잘해왔는데 굳이 C++ 이냐는 것입니다.

전 이 생각에 반대합니다
지금까지 하던대로 잘해왔는데........ 바꿀필요가 없다는 사고는
궁극적으로 발전이라는것을 더디게 만듭니다

물론 불필요한 것으로 바꾼다면.... 말이 안되지만

바꿀 필요가 있는데도...... 여태 옛날 방법으로 잘해왔다는 것으로......

합리화 시키는 경우가 많더군요

하지만 시간은 세상을 변화시키고 변화를 무시한 옛날 방법이 계속 합리적인 방법이 될거라는 믿음은 사람을 도퇴시킵니다
많은 경우에서 이런것을 볼수 있죠

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

onemind555의 이미지

Quote:
MFC 는 객체설계가 좀 잘못되엇다고 하는 얘기를 들었는데
처음에 그게 무슨 얘기인지 몰랐으나 지금은 MS 사의 "성급한 소스" 로 볼때
"개발자에 따라서 그렇게 보일 수도 있다" 고 생각하고 있습니다.

MFC같은건 객체 지향 소스라고 할 수도 없습니다.. MFC 책에서만 떠드는 얘기죠..
MFC가 객체 지향 개념을 조금 도입했다고는 말 할 수 있습니다..

-----------^^ ^^ ^^ ^^ ^^ ----------
..........................................................

ssggkim의 이미지

mastercho wrote:
akbar wrote:

빌 게이츠가 윈도우 NT 개발 초기에 C 로 얼마간 진행이 되었던 도중에
C++ 로 짜라고 지시를 내렸읍니다.
이 지시에 거부에 한 사람이 몇명있습니다.
그 중 한 사람이 DEC 사에서 근무하면서 높은 명성을 날린,
그리고 그리고 빌게이츠가 직접 스카우트했던
NT 개발팀 총책임자 데이빗커틀러입니다.
C 로도 잘해왔는데 굳이 C++ 이냐는 것입니다.

전 이 생각에 반대합니다
지금까지 하던대로 잘해왔는데........ 바꿀필요가 없다는 사고는
궁극적으로 발전이라는것을 더디게 만듭니다

물론 불필요한 것으로 바꾼다면.... 말이 안되지만

바꿀 필요가 있는데도...... 여태 옛날 방법으로 잘해왔다는 것으로......

합리화 시키는 경우가 많더군요

하지만 시간은 세상을 변화시키고 변화를 무시한 옛날 방법이 계속 합리적인 방법이 될거라는 믿음은 사람을 도퇴시킵니다
많은 경우에서 이런것을 볼수 있죠

결과물을 정해진 시간내에 문제없이(없을 수는 없겠지만...) 내야하는 기업의
입장에서는 어쩔 수 없는 경우도 많이 있죠. :oops:

mastercho의 이미지

onemind555 wrote:
Quote:
MFC 는 객체설계가 좀 잘못되엇다고 하는 얘기를 들었는데
처음에 그게 무슨 얘기인지 몰랐으나 지금은 MS 사의 "성급한 소스" 로 볼때
"개발자에 따라서 그렇게 보일 수도 있다" 고 생각하고 있습니다.

MFC같은건 객체 지향 소스라고 할 수도 없습니다.. MFC 책에서만 떠드는 얘기죠..
MFC가 객체 지향 개념을 조금 도입했다고는 말 할 수 있습니다..

어떤면에서 객체지향 소스라 볼수 없는지 궁금하네요

제가 알기론 고전전인 객체지향을 충실히 따른 프레임웍으로 보입니다

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

iolo의 이미지

akbar wrote:

"그런 몰지각한 일부" 였던 제가 한 번 정리를 하겠습니다.
이 쓰레드의 주제는 GTK는 객체지향이 아니고, 스파게티 코드인가? 였습니다
그런데 엉뚱하게도

-- GTK는 객체지향이고, 스파게티 코드도 아니다 -- 라는 주장과
-- GTK는 객체지향이지만, 스파게티 코드처럼 복잡해 보일 수 있다 --
는 주장이 대립했었습니다.


동의합니다. 저도 좀 이상하게 흐른다는 생각을 했었으니까요.
기본적으론, 발제자가 쓰레드에 참여하여 방향을 유도하지 않았기 때문이고, 저나 akbar님이 오바(?)한거죠.... 마지막 오바는 차라리 안하는 것이 나았겠습니다. -.-;

akbar wrote:

지금 생각해 보면 제가 주장하고 싶었던 것은

-- 객체지향이건 아니건 복잡하지 않고 깔끔해서
-- 알아보기 쉬운 코드가 훌륭한 코드이다.

라는 것입니다.


여기에서 제가 주장하고 싶었는 것은
'나름대로의 원칙을 갖고 만들어진것은, 그 원칙을 모르면 복잡해 보이지만, 그 원칙을 알고나면 쉬워진다'입니다.
리스프를 모르는 사람에겐 리스프의 끝없는 괄호 조차도 어지러워 보이겠죠.

off topic:
전 커틀러를 좋아하는 사람입니다. 지금의 3.51이후의 NT와 그 후손들보다는 NT(3.5)가 훨씬 잘 만들어졌고 좋았다고 생각합니다. 역시 사람마다 다를 수 밖에 없겠죠? ^^;

----
the smile has left your eyes...

카二리의 이미지

akbar wrote:

boxing 을 C++ 이 지원하지 못한다구요. 푸하하하(^^^)
이 대목에 이르러서는 응대할 가치를 못느끼겠습니다.
C++ 을 겉핥기만 하셨네요.
boxing 은요 제가 C++ 초보 시절에도 그렇게 써 왔던 것입니다.
알고 보니 대단한 기능이군요
java 가 1.5 대에 이르러 겨우 지원되었다니
대단한 걸 알게 해주셔서 감사합니다.

궁금해서 그러는대요
제가 알기론 boxing은

int x = 10;
Integer i = new Integer(x);
int y = i.intValue();

요런거인걸로 아는대요
객체지향 언어이지만 기본 자료형이 객체가 아닌 언어에서
기본 자료형을 랩핑 클래스로 한번 감싸서 객체로 취급하게 해줄수 있는걸로
알고 있는대
자바 1.5에서 들어간 새로운 기능은 AUTOboxing 이라는
저 위의 코드와 같은걸
int x = 10;
Integer i = x;
int y = i;

이렇게 쉽게 쓸수 있는 기능으로 알고 있습니다.
그런대 제가 알고 싶은건 auto boxing이야 그렇다 치고
boxing이 가능 하려면 언어 자체의 표준 런타임같은 것에서 지원하는 랩핑 클래스 같은것이 있어야 하는대 C++에 그런 랩핑 클래스가 존재하나요?

전 자바 실력도 허접하고 C++ 실력도 허접해서 - _-; 글을 보다가 제가 C++을 하면서 경험해보지 못한것이 나와서...

혹 탬플릿 같은걸로 boxing을 예기 하시는건가요?

새 생각 :)

wafe의 이미지

class IntClass
{
  IntClass(int arg)
  {
    ...
  }
  ...
};

IntClass ic = 10;

이런게 가능하다는 것인줄로 압니다. 적절한 생성자가 있다면 자동으로 생성자를 호출해주는거죠.

Heejoon Lee

akbar의 이미지

...

세벌의 이미지

죠커의 이미지

akbar wrote:
1) 데이타 은닉:

아래 코드에서

gtkwidget.h: 

typedef struct _priv; 

struct _GtkWidget
{ 

  struct _priv* priv; 

  /*public ...*/ 
  gtk_widget_show(); 
... 
} 

gtkwidget.c: 

struct _priv { 
/*private */ 
... 
} 

라고 한다면


struct _GtkWidget GtkWidgetObj;
void* pVoid=GtkWidgetObj.priv;

라는 접근을 막을 수 있습니까.
이것이 데이타를 은닉한 겁니까.

Common Lisp의 CLOS는 결코 OOP가 아니군요?

akbar wrote:
카二리 wrote:
akbar wrote:

boxing 을 C++ 이 지원하지 못한다구요. 푸하하하(^^^)
이 대목에 이르러서는 응대할 가치를 못느끼겠습니다.
C++ 을 겉핥기만 하셨네요.
boxing 은요 제가 C++ 초보 시절에도 그렇게 써 왔던 것입니다.
알고 보니 대단한 기능이군요
java 가 1.5 대에 이르러 겨우 지원되었다니
대단한 걸 알게 해주셔서 감사합니다.

궁금해서 그러는대요
제가 알기론 boxing은

int x = 10;
Integer i = new Integer(x);
int y = i.intValue();

요런거인걸로 틈쨈肉?
객체지향 언어이지만 기본 자료형이 객체가 아닌 언어에서
기본 자료형을 랩핑 클래스로 한번 감싸서 객체로 취급하게 해줄수 있는걸로
알고 있는대
자바 1.5에서 들어간 새로운 기능은 AUTOboxing 이라는
저 위의 코드와 같은걸
int x = 10;
Integer i = x;
int y = i;

이렇게 쉽게 쓸수 있는 기능으로 알고 있습니다.
그런대 제가 알고 싶은건 auto boxing이야 그렇다 치고
boxing이 가능 하려면 언어 자체의 표준 런타임같은 것에서 지원하는 랩핑 클래스 같은것이 있어야 하는대 C++에 그런 랩핑 클래스가 존재하나요?

전 자바 실력도 허접하고 C++ 실력도 허접해서 - _-; 글을 보다가 제가 C++을 하면서 경험해보지 못한것이 나와서...

혹 탬플릿 같은걸로 boxing을 예기 하시는건가요?


아닙니다. 형변환 연산자를 얘기하는 것입니다.

형변환 연산은 boxing이 아닙니다.

akbar의 이미지

...

progcom의 이미지

akbar wrote:
그러면 JavaScript 도 OOP 겠네요 ?

말꼬리 잡는 느낌이 들지만.. JavaScript는 OOP가 가능하도록 되어있습니다. 실제로 쓰는 경우는 자주 볼 수 없지만요. (JavaScript를 가볍게 보고 깊게 공부하는 사람이 없다는 점으로 인해, 편견이 생기는 경우가 꽤 많이 보입니다)
추가: 데이터 은닉이 OOP의 '필수' 조건은 아닙니다.

추가: 혹시 혼란이 있을까봐 덧붙이지만, OOP-Language와 OOP는 다릅니다. C가 OOPL은 아니자만, GTK는 C로 OOP를 구현한것입니다. 그리고 아니라는 듯이 말하신 JavaScript는 OOPL입니다. :(

akbar의 이미지

...

progcom의 이미지

akbar wrote:
C 의 형변환 연산은 boxing 이 될 수가 없습니다.
C++ 의 형변환 연산도 boxing 이 아닙니다.
C++ 의 형변환 연산은 boxing 그 이상의 것이기 때문이지요.
그런데 그런 뜻으로 쓴 것 같지는 않고...
많은 C 플머들이 C 식으로C++ 을 생각한다는데
또 한 번 장님 코끼리 만지는 경우를 보게 되네요.
코끼라야! 그런 장님은 냅다 걷어 차주거라!

코끼리 어쩌고 하시는것보다, akbar님이 말씀하시는 boxing의 의미가 무엇인지가 궁금합니다. 위에서는 형변환 연산자가 boxing이라고 주장하시더니, 여기서는 그 이상의 것이라고 하시니, 혼동이 옵니다. 제가 알고 있는 boxing과는 다른 의미로 쓰신 것 같아서 문의드립니다.

Quote:
Boxing is a way to wrap objects with primitive types over object types so that they can be used like objects. Examples are Integer class for integer type in Java. Some languages require programmers to do boxing manually, while some support autoboxing/unboxing.
익명 사용자의 이미지

boxing 이
"Boxing is a way to wrap objects with primitive types over object types ..." 이상의 의미가 있는 것이 아니고
C++ 에서 지원하는 형변환연산이 boxing 이상의 의미가 있다 라는 뜻이었습니다.

akbar의 이미지

...

finejo의 이미지

akbar wrote:
boxing 을 C++ 이 지원하지 못한다구요. 푸하하하(^^^)
이 대목에 이르러서는 응대할 가치를 못느끼겠습니다.
C++ 을 겉핥기만 하셨네요.
boxing 은요 제가 C++ 초보 시절에도 그렇게 써 왔던 것입니다.

akbar wrote:
Quote:
혹 탬플릿 같은걸로 boxing을 예기 하시는건가요?

아닙니다. 형변환 연산자를 얘기하는 것입니다.

akbar wrote:
C 의 형변환 연산은 boxing 이 될 수가 없습니다.
C++ 의 형변환 연산도 boxing 이 아닙니다.
C++ 의 형변환 연산은 boxing 그 이상의 것이기 때문이지요.

akbar wrote:
boxing 이
"Boxing is a way to wrap objects with primitive types over object types ..." 이상의 의미가 있는 것이 아니고
C++ 에서 지원하는 형변환연산이 boxing 이상의 의미가 있다 라는 뜻이었습니다.

제 능력으로는 이 전체가 하나로 이해되지 않습니다.
더 자세한 설명을 부탁드려도 될까요?

인간조

cwryu의 이미지

가끔 보면 어느정도 정리가 되서 몇달, 몇년이 지나서 잘 기억도 안 나는 상태에 있는 스레드에 갑자기 자극적인 댓글을 달아 몹시 읽기 불편한 상태가 되는 경우가 많습니다. 그런 경우에 댓글을 달고 싶은 마음은 이해하지만, 댓글이 하나라도 있으면 새글로 표시하고 그 안에서 구별을 하지 않는 phpBB의 인터페이스때문에 KLDP BBS의 이용을 상당히 어렵게 합니다.

그러한 이유로... 새롭게 벌어지고 있는 댓글의 내용과는 상관없이 감히 이 스레드를 잠그는 데 한표 던집니다.

Prentice의 이미지

잠금에 한 표 더 던집니다. 두표째입니다.

nytereider의 이미지

흠...처음부터 읽어 봤습니다. 역시 플레임워는 흥미진진하고 재미있군요. :)
그나저나 akbar라는 분, 자존심이 좀 상당히 쎄신분 같군요. =ㅅ=; 남들에게 반론당하기를 싫어하는 타입...저도 비슷하지만 (컥;;;)

어떻게 보면 악성 파이썬 질럿과 펄 질럿들 사이의 플레임 워 비슷하게 나가는 듯 하군요. 몇몇 악질 파이썬 질럿 중, 펄을 보고 "펄은 TIMTOWTDY때문에 코드도 더럽고 객체지향을 고려하지 않아서 꽝이다"라고 주장하는 사람들처럼... 그런데 사실 개인 취향일 따름일뿐...펄이 오히려 더 편한 사람도 분명 있는겁니다. (저같은 인간)

블루스크린의 이미지

잠금에 한 표 더 던집니다. 세표째입니다.

좋은 글들 잘 보았습니다

-------------------------------------------------------------------------------
이 댓글(comment)의 수정 및 삭제를 위해 이 글에 답글(reply)을 쓰지 말아 주십시요.
의견이 있으시면 원 글에 댓글(comment)로 써 주세요.

akbar의 이미지

...

익명 사용자의 이미지

위에 잠금 표를 쓰시는 분들이 있는데... 스레드 분위기는 둘째치고 boxing에 관한 내용은 궁금하네요.
커뮤니티의 화기애애한 분위기보다 궁금하고 새로운 사실에 주목하는 것. 그게 개발자 커뮤니티의 본모습 아니겠습니까? :)
기분좋게 놀 수 있는 놀이터 같은 분위기는 자유게시판만 지키면 된다고 생각합니다. 그래도 개발자 커뮤니티인데 살벌한 분위기 정도는 기본이라고 봐야 하지 않을까요.

잠금 표를 던지신 분이 그건 이런거다! 라고 명쾌하게 결론을 내고 잠금 표를 던진다면 저도 동의하겠지만 보기 안좋다고 그러는건 토론 게시판에 바람직한 자세가 아닌 것 같습니다.

Prentice의 이미지

무효표(?) 철회(?)합니다.

카二리의 이미지

제가 C++을 잘 못하기에..
저로썬.. 도저히 아직도 이해가지 않습니다..

그래서 akbar님에게 다시 묻겠습니다..

말씀 해주신 형변환 연산자가 type casting 연산자를 말씀하시는 건가요?

// class type-casting
#include <iostream.h>

class CDummy {
    int i;
};

class CAddition {
	int x,y;
  public:
	CAddition (int a, int b) { x=a; y=b; }
	int result() { return x+y;}
};

int main () {
  CDummy d;
  CAddition * padd;
  padd = (CAddition*) &d;
  cout << padd->result();
  return 0;
}

이런걸 말씀 하시는 건가요?
혹은 다음과 같은것?
int x = 10;
cout << "x = " << x << endl;

cout은 method <<에 오버로딩으로 여러 인자를 받는 것으로 알고 있는대.. (틀리다면 지적 바랍니다.)

제가 알고 있는 boxing이란.. 형을 변환 하는게 아니라...
말그대로 한번 감싸는것.. 변수의 값을 가지고 있는 있는 Instance를 생성하는걸로 알고 있는대요..

형변환 연산자로 어떻게 boxing을 하는건지 설명을 좀 해주시기 바랍니다..

저로써는 C++에 형변환 연산자로 boxing이 충분히 가능하다면..
.net 이후에 나온 C++ management 에서 __box keyword가 왜 나온건지 조차 이해가 안되려고 해서 ... 심히 혼란스럽습니다..

새 생각 :)

doldori의 이미지

저도 플레임성 쓰레드는 좋아하지 않지만 boxing에 관한 내용은 궁금하네요.
관심있게 보는 사람도 있다는 것을 알아주시면 좋겠습니다.

ps. 검은해님, 두 표를 행사하셨는데 그거 반칙 아닙니까?

죠커의 이미지

아래의 코드는 C#에서 테스트 했기 때문에 Java에서도 그대로 통용되는지 모르겠습니다. 하지만 이 코드는 boxing / unboxing이 단순한 형 변환과는 다르다는 것을 알려주고 있습니다.

int value = 123;
object o = value;
long value2 = (long) o;  // error.
long value3 = (long)(int) o; // no error.

boxing / unboxing이 단순한 형변환이라면 3번째 줄의 코드가 에러인 이유와 4번째 코드와 같은 삽질을 해야 하는 이유를 설명할 수 없습니다. 사실 boxing / unboxing은 위와 같은 이유 때문에 사용해야 하는 것이 아닙니다.

smalltalk는 reference type으로 모든 자료형이 구성되어 있습니다. 하지만 현재의 객체지향 언어의 대부분은 value type과 reference type 모두를 가지고 있습니다. 이유는 기본적으로는 성능에 대한 생각이 밑 바탕에 있습니다. 그래서 대부분의 언어에서 이 둘은 다른 문법체제를 가지고 다른 형태로 다루고 있습니다. 이런 두 가지 type에 대한 자세는 혼동의 여지와 함께 기능성의 제약을 일으켰다는 비판도 있습니다. 이것을 해결하기 위해서 나온 컨셉이 boxing / unboxing입니다.

boxing / unboxing 의 개념은 JAVA보다 C#에 더 잘구현되어 있다고 볼 수 있습니다. boxing / unboxing은 primitive type을 wrap해주는 것이라는 것보다는 value type과 reference type 간의 가교 역활을 해줍니다. 자바에서는 value type는 primitive type이기 때문에 제한적인 boxing 과 unboxing이 사용된다고 할 수 있습니다.

Hashtable t = new Hashtable();
t.Add(0, "zero");
t.Add(1, "zero");

Hashtable의 add는 2개의 object를 받고 있습니다. 키를 받기 위한 것이 첫번째이고 값을 받기 위한 것이 두번째 입니다. object는 모든 refetence type들의 부모이기 때문에 "zero"와 "one"은 문자열 객체로 인식 받아 object로 받을 수 있습니다. 반면에 0과 1은 순수하게 숫자인데 이것을 reference type인 객체로서 object가 받아들이고 있습니다. 이것이 가능한 것은 boxing과정을 통해서 value type은 reference type으로 변환이 가능하기 때문입니다.

value type을 reference type으로 바꾸는 과정이기 때문에 심지어 가상 함수 호출도 가능합니다. 얕은 지식으로는 C++에서 value type을 polymophsm을 이용하기 위해 dynamic binding할 방법을 모르겠습니다.

CLOS 이야기를 꺼낸 것은 CLOS는 하지 말아야 할 것은 불편하게 해두는 방식으로 객체지향을 구현했기 때문입니다. 포인터를 이용해서 불편하게 캡슐화를 뚫어 보는 것이 과연 현실적인 이야기인가를 얘기해보고 싶었습니다. 제대로 C++을 이해하고 응용하지 못한 프로그램이 느리다는 말을 가끔 듣습니다. 포인터로 우회할 수 있기 때문에 캡슐화가 제대로 안되었다는 것과 C++의 특징을 제대로 이용하지 못했기 때문에 느린 프로그램이 되었다는 이야기가 모두 비슷한 이야기로 들립니다.

마지막으로 이 쓰레드가 잠겨야 하는 이유를 모르겠습니다. 간단한 글로 이 쓰레드를 다시 연 것은 akbar님이 어떤 생각을 하고 있는지 의문이 든 부분이 있었기 때문이었습니다. 그리고 이 쓰레드에서 논쟁이 사라진 것이 아니라 akbar님의 이야기에 대한 답을 다른 사람이 하지 않은 것이였습니다. 이야기를 더 진행해서 발전적으로 나가는 방향이 잘 못된 것인가요? 요즘의 KLDP에서는 논쟁이 보다는 잠금 한표가 더 폭력적인게 아닌가 생각합니다.

페이지