x-like

generic programming
In computer science, generics is a technique that allows one value to take different datatypes (so-called polymorphism) as long as certain contracts such as subtypes and signature are kept. The programming style emphasizing use of this technique is called generic programming. – via wikipedia

사실, Generic Programming(이하 GP)은 C++이나 Java, C#등의 타입이 중요한 언어에서 로직의 타입에 대한 종속성을 줄이기 위해 유용하게 사용될 법한 기법이다. 그래서 저 말이 유용하게 들린다. 하지만, 막상 문서를 작성하다보면 머리가 좀 아플때가 있다.

C++을 주로 사용하기 때문에, C++을 예로 들면, process_event라는 메소드를 정의한 객체를 매개형식으로 받아야 오류가 발생하지 않습니다. 라는 말을 하고 싶은데 저 말을 딱히 줄여서 간단하게 쓸 방법이 도무지 떠오르질 않았었다. GP가 아니라 Object-Oriented Programming(이하 OOP)였다면 저런 경우 상위클래스를 뽑아놓고, 상위클래스의 포인터를 받는다고 써주면 되기 때문에 큰 문제가 발생하지 않지만, 다형성(polymorphism)을 GP를 이용해 구현하기로 했다면, 적절한 용어가 없어서 고민하게 된다.

이런 일로, 어떻게 써줘야하나 고민하고 있었는데, 불현듯 전에 잠깐 공부하던 pygame의 문서가 생각났다. 가장 인상적이었던 표현은 바로 rect-like object였는데, (top, left, width, height)의 튜플형태로 evaluate되는 모든 객체를 의미하는 거였다. 즉, 진짜로 저런 튜플을 넘겨주거나, 저런 튜플로 할 수 있는 연산을 미리 정의한 클래스라면 상관없다는 이야기. 즉, X-like 였던거다. X이거나 X와 동일하게 컴파일/실행 될 수 있는 타입!

iterator-like, int-like, short-like, stream-like등 활용예가 많아졌다. 🙂 – 위에서 예로 들었던 process_event를 정의한 객체같은 경우는 state machine-like가 되시겠다. –

여기까지 생각하다가 좀 더 생각이 나갔는데, GP는 말이 좀 어렵지 않나라는 생각이 들었다. 타입을 중시하는 언어에서나 적용될 법한 개념이기도 하니 말이다. x-like programming. 뭔가 좀 명확해보이긴 하나 역시 모호하긴 매한가지라는 생각도 들었다.

이젠 x-like라는 말로 간단하게 문서를 정리할 수 있을 것 같다.

ps1. STL같은 경우는 매개변수의 이름을 통해서 정리를 해주는 경향이 있다. iterator 혹은 그와 동일하게 evaluate되는 타입일 경우는 IteratorT와 같은 형태로 많이 쓴다. InputIteratorT, OutputIteratorT.

ps2. Boost MPL에서는 Concept이란 용어도 사용한다. 하지만, 그 컨셉에 맞는 객체를 표현하는 용어는 딱히 정해진게 없는 듯 하다.

Skype를 믿으십니까?

Skype의 위험성에 관해.

네트워크 프로토콜 분석을 업으로 삼아 살아가고 있는 터라, 보통 1년에 10~15개정도의 프로토콜을 분석하는 편입니다. (물론 이거 말고도, 제품 엔진 작업이나 기타 여러 작업이 있는터라 프로토콜 분석쪽에 전념하고 있는 것은 아니지요.)

다양하고도 많은 프로토콜을 접하게 되는지라, 여러 프로토콜을 보고 있노라면 참 많은 생각이 듭니다. 정말 무식하게 짠 프로토콜도 있고, 감동을 먹을정도로 멋진 프로토콜도 있지요. 물론, 감사할 정도로 쉬운 녀석도 있는가하면, 진절머리가 날 정도로 복잡하고 어려운 프로토콜도 있답니다. (빌어먹을 오라클, MSN)

네트워크 프로토콜은 의외로 과도한 보안이 보안을 해치는 경우가 있습니다. 네트워크 솔루션은 그 통신내역에 의해 어느정도 투명성을 보장받지요. 솔루션 자체가 비밀정보나 프라이버시를 외부로 빼돌릴수 있으며, 이 가능성은 해당 네트워크 솔루션이 어떤 내용의 통신을 하고 있는지를 보면 어느정도 판단이 가능합니다. 리버스 엔지니어링에 의한 솔루션의 Clearness 보장이지요. 물론, 통신내역을 볼 수 있다는 것 자체가 개인정보의 유출 가능성을 항상 내재하고 있는 것이긴 합니다만, 솔루션 자체에 의한 정보유출 역시 무시할 수 없습니다. (Sony에서 발매된 CD에 들어있는 백도어를 생각해보면…)
더 보기 “Skype를 믿으십니까?”

요즘 작업/고민중인 funcode #1

1. DistCL
MSVC의 cl.exe 대체품. 분산 컴파일을 위해 작업중인 코드. with Python.

2. downcast_overloader
결과타입 처리하는 것 때문에 고민중. with C++

3. XML Template Library
element+는 libxml2기반으로 작업했더니 너무 libxml2에 의존적이 되어버렸당.
expat기반으로 xml pull parser를 만들어 작업하는 방안 고민. 이름도 고민.

downcast overloading.

회사의 코드들이 상당히 계층적으로 묶여있는 상속관계… 즉, 결과와 관련된 모든 클래스는 ResultInterface라는 순수 가상 클래스(즉, 인터페이스)를 상속받고 있는 관계로 dynamic_cast를 if문으로 쭈욱 연결해서 해당 함수를 호출하는 코드가 일반적이었다.
더 보기 “downcast overloading.”

std::list를 통해 보는 STLPort vs. MSVC STL(Dinkumware)

회사에서 작업하던 중간에….

동료: 이거 너무 느린데?
까막: 응? 좀 보자.
(잠시후)
까막: 우욱. size()는 O(n)이잖아. 뭔 배짱으로 쓰는거냐.
동료: O(1)이잖아. 확인 했는데?
까막: linked list로 구현이 되어 있을테니 O(n)이지.
동료: 응?
더 보기 “std::list를 통해 보는 STLPort vs. MSVC STL(Dinkumware)”