Media Log

카카오톡의 채용 공고를 재밌게 읽다가 밑에 달린 댓글을 보고 폭소하였다.


[채용공고]

카카오팀에서 모바일의 미래를 함께 만들어 갈 만렙 엔지니어를 찾습니다

카카오톡을 전 우주 통신규약으로 만들려는 음모를 가진 카카오팀에 합류할 실력자를 찾고 있습니다.

...하략...



으하하. 아직 음모를 잃지 않은 만랩 엔지니어들은 한번 지원해보기 바란다. 전체 공지 내용은 여기에서 볼 수 있다.

저작자 표시 비영리 동일 조건 변경 허락
크리에이티브 커먼즈 라이선스
Creative Commons License

http://www.benjaminlog.com/trackback/277 관련글 쓰기

submit

한 때 윈도우 프로그래밍의 교과서로 불리우던 찰스 펫졸드의 Programming Windows 가 6판이 되어 돌아온다. 추가되는 내용은 윈도8의 메트로 앱개발.


아직 정식 책이 나오려면 많이 기다려야 하기 때문에 매트로앱에 대한 내용만을 담아서 전자책으로 10$에 파는 이벤트를 진행 한다고 한다. 5월 17일 ~ 5월 31일 사이에만 살 수 있다.


더 자세한 내용은 그의 블로그에서.

http://www.charlespetzold.com/blog/2012/04/2-4-6-8-10.html

저작자 표시 비영리 동일 조건 변경 허락
크리에이티브 커먼즈 라이선스
Creative Commons License

http://www.benjaminlog.com/trackback/276 관련글 쓰기

submit



저작자 표시 비영리 동일 조건 변경 허락
크리에이티브 커먼즈 라이선스
Creative Commons License

'디지털보단 아날로그' 카테고리의 다른 글

전자책 이야기  (3) 2012/08/20
카카오톡 음모론  (0) 2012/04/26
Write in C  (0) 2012/04/23
Devon 2011, 왜 김택진이 욕을 먹어야 하는가  (2) 2011/11/28
안철수연구소 오픈 하우스 이벤트  (0) 2011/10/22
플라워 바이 겐조  (0) 2011/07/12

http://www.benjaminlog.com/trackback/275 관련글 쓰기

submit

살다보면(?) 매크로에서 받는 가변 인자를 또 다른 매크로로 쑤셔넣고 싶은 경우가 있다.

#define MACRO_1(abcfn(a, b, c) #define MACRO(...) MACRO_1(__VA_ARGS__)

짠, 이렇게 하면 된다.

그렇다. 아무 테크닉이 필요없이 그냥 쑤셔넣으면 된다.

그런데 위 코드는 GCC에서는 잘 동작하지만 VC에서는 동작하지 않는다. 그렇다고 해서 가변인자는 다른 매크로로 건넬 수가 없구나 하고 오해하면 안된다. 이것은 그냥 비주얼 스튜디오의 버그일 뿐이다.

#define MACRO_1(abcfn(abc)
#define MACRO_1_(args_listMACRO_1 args_list
#define MACRO(...) MACRO_1_((__VA_ARGS__))

비주얼 스튜디오에서는 위와 같은 얍삽이를 통해서 이를 회피할 수 있다. __VA_ARGS__ 주위를 한 겹 더 괄호로 둘러싸서 또 다른 매크로로 넘기는 것을 주의해서 봐야한다.


그래서 내가 하고 싶은 말은,


이 버그가 정말 거지 같다고 생각된다면

http://connect.microsoft.com/VisualStudio/feedback/details/380090/variadic-macro-replacement

여기 가서 upvote를 해주세요.

저작자 표시 비영리 동일 조건 변경 허락
크리에이티브 커먼즈 라이선스
Creative Commons License

http://www.benjaminlog.com/trackback/273 관련글 쓰기

submit

내 피드리더에는 등록되어있는 블로그가 700여개 쯤 있다.

그 중에는 새로운 글이 올라올 때마다 가슴이 설레는 몇몇 블로그들이 있다. 그 중 우리나라 저자가 운영하는 3개의 블로그를 소개하려고 한다.


1. 메아리 저널

정말 엄청난 실력을 가진 해커이다. 특정 플랫폼이나 언어에 상관없이 여러 주제로 재밌는 글을 쓴다. 가끔 기괴한 코드 골프 내용이 올라오기도 하는데 그런걸 쳐다보고 있다 보면 자괴감에 빠지기도 한다.

어쨌거나 나는 그의 글이 너무나도 좋아서 언젠가는 주말 이틀 동안 내내 방구석에 누워서 2004년부터인가 썼던 모든 글을 다 읽어본 적도 있었다. 가끔씩 이상한 오락실 얘기도 쓰고는 하는데 그런 글조차 재밌다. 블로그에 댓글로 피드백을 할 수가 없어서 애독자로서 좀 아쉽긴 하지만 본인이 그에 대해 많이 고민해 본 듯하니 어쩔 수 없는 일이다.


2. art.oriented

프로그래머가 몰랐던 멀티코어 CPU 이야기를 쓴 저자이다. 주로 윈도 프로그래밍이나 시스템 프로그래밍 이야기를 다루는데 글들이 재밌을 뿐더러 배울 점도 많다. 이 블로그 역시 거의 모든 글을 다 읽었다. 아마 프로그래밍 기술을 다루는 우리나라 블로그들 중 가장 피드백이 많이 왔다갔다 하고 방문자 수도 많은 블로그가 아닐까 싶다.


3. 김용묵의 절대 공간

이 블로그는 비교적 최근에 알게되었다. 글들은 아주 오래전부터 꾸준히 작성되어 왔는데 써있는 글의 질과 양에 비해 일방문자수는 상당히 적다. 윈도 프로그래밍에 대해서만 다룬다. 윈도 역사에 대해서 글을 쓸 때는 레이몬드 첸을 보는 느낌이 들기도 한다. 철도와 종교 이야기도 종종 꺼내는데 나는 그런 주제는 관심이 없어서 건너 뛰고 읽는다.


그러고보니 이 블로그들 이상으로 예전에 정말 좋아했던 블로그가 있었다. 바로 방준영의 블로그. 2009년도 즈음이었던가? 어느 날 아침에 그의 블로그를 발견하고는 오아시스라도 발견한 것 처럼 기뻤던 날이 있었다. 거의 매일 같이 좋은 글들이 올라와서 정말 행복하게 읽어가고 있었는데 언제부터인가 새 글이 더 이상 올라오지 않았고 심지어는 기존에 썼던 글마저 사라져 버렸다. 안타까운 일이다. 준영님. 혹시라도 이 글을 보신다면 돌아와주세요. 엉엉.


나는 미투데이나 트위터가 싫다. 페이스북도 싫다. 이 잡 것들이 나오고 나서 사람들은 블로그에 글을 잘 쓰지 않는다.

돌아오라 블로거들이여. 맛집 블로거 말고 프로그래머들 말이여.

그럼에도 불구하고 영어 블로그는 여전히 좋은 블로그들이 엄청나게 많다. 하지만 영어 블로그를 읽는 것은 정말 고통스러운 일이다. 내 피드 리더에는 나중에 읽으려고 마킹해둔 글들이 잔뜩 쌓여있는데 그것들 대부분은 영어 포스트이다. 한 번 읽으려면 크게 심호흡부터 하며 각오를 단단히 하고는 한다. 그리고 나는 그렇게 심호흡을 자주 하지 않기 때문에 오늘도 마킹만 해두는 글들이 계속 늘어간다.

그러니 이렇게 우리말로 좋은 글을 써주는 사람들이 어찌 고맙지 않겠는가. 좋은 국내 블로그들이 더 많이 생겼으면 좋겠다.

저작자 표시 비영리 동일 조건 변경 허락
크리에이티브 커먼즈 라이선스
Creative Commons License

http://www.benjaminlog.com/trackback/272 관련글 쓰기

  1. Favicon of http://hongyver.tistory.com BlogIcon hongyver at 2012/04/13 08:38 [edit/del]

    제 피드리더에도 많은 블러그가 등록되어 있는데 그중에 한분이십니다. ^^
    평소 글 잘 읽고 있습니다.
    (영어 블러그는 마킹할 생각도 못하고 그냥 지나칠때가 많아요.)

    Reply
  2. Sobbungi at 2012/04/15 03:02 [edit/del]

    님도 저 세 블로그 만큼이나 충분히 훌륭하십니다..
    가끔 올라오는 글들 유용하게 잘 읽고 있습니다..
    계속 좋은 글 부탁드립니다~~.

    Reply
  3. Favicon of http://moogi.new21.org/tc BlogIcon 사무엘 at 2012/05/14 08:23 [edit/del]

    안녕하세요? 제 블로그에 흔적을 남겨 주신 것에 감사드리며, 저와 제 지인의 블로그를 소개해 주셔서 또 감사합니다. ^^

    '1. 메아리 저널의 운영자'는 저의 학교 후배이고 저와도 아주 친한 사이입니다.
    '엄청난 실력을 가진 해커' ← 사람 보는 안목이 정확하십니다. ㄷㄷ

    짐작하신 대로 저는 아주 좁은 제 전문 분야만 빼면 딱히 다른 IT 기술이나 플랫폼이나 전산학의 발전에는 큰 관심이 없는 타입이에요.
    그에 반해 진정한 전산학 덕후/해커가 어떤 사람인지를 저 친구를 보면서 저는 절실히 느낀답니다. ^^

    김민장 님 블로그는 운영자께서 대학원 생활에 너무 바쁘셔서 유명세에 비해 글이 너무 뜸하게 올라온다는 것만이 유일한 단점인 듯하고...

    제 블로그는 설치형이어서 메타블로그에 딱히 노출되는 게 없습니다. 그래서 예전부터 제가 개발한 프로그램을 사용해 온 분이나 너무 매니악한 블로그 주제에 질리지 않은 분들만 오느라 방문자수가 적은 것 같습니다. ^^;; 2년 전이나 지금이나 비슷한 수입니다.
    블로그 주제가 꽤 이상한 혼합형 타입이죠? ㅋㅋㅋㅋ
    URL에서 tc를 빼고 도메인만 입력해서 접속하면 대문 페이지도 나오는데, 그것도 보셨나 궁금합니다.

    Reply
    • Favicon of http://www.benjaminlog.com BlogIcon 김재호 at 2012/05/14 10:14 [edit/del]

      예, 메아리 저널이나 절대공간 글은 하도 많이 읽어서 친한 사이라는 것은 알고 있었습니다. 당연히 대문 내용도 읽어보았었고요.
      만나서 반가워요. 앞으로도 좋은 글 많이 써주세요.

  4. 박우석 at 2012/05/16 01:45 [edit/del]

    자괴감 블로그 보고 왓는데
    난 누구인가 여긴 어디인가
    귓속을 맴도네요 ㅋㅋ

    Reply
  5. 이매` at 2013/01/25 18:51 [edit/del]

    네이트온이메일좀 알려주세용 ㅋ

    Reply
  6. busim at 2013/02/28 06:44 [edit/del]

    와~우! 글을 너무 재미있게 써서 귀에 쏙 들어옵니다 잘 놀다 갑니다 종종 들어와도 될까요?

    Reply
  7. 해비 at 2014/05/03 12:58 [edit/del]

    좋은 내용 및 링크들 감사합니다

    다만 이해가 가는듯 안가는듯(실제로는 이쪽 ㅜㅜ) 좀 정독하며 파 봐야 겠어요

    5년째 개발중(SI + SM + 기타)인데 난 뭐했나 싶을 정도로 자괴감만 드네요

    Reply

submit

CString 의 비밀

2012/04/12 11:55 | Programming
다음 코드를 실행시켜보면 "abc"가 잘 출력이 될까?

CString s = L"abc";

wprintf(L"%s", s);


그렇다. 잘 출력된다.

대부분의 사람들은 이 부분을 원래 그런거 아니었어? 하고 대수롭지 않게 넘어간다.


어잉, 그런가?


그렇다면 다음 코드는 어떨까? 이번엔 CString이 아니라 std::wstring을 사용했다.

std::wstring s = L"abc";

wprintf(L"%s", s); // this is wrong


컴파일은 잘 되지만 이번엔 제대로 출력되지 않는다. 형식 문자열에 포인터를 넣지 않고 wstring 객체 자체를 쑤셔 넣었기 때문이다. 사람들이 흔하게 하는 실수이며, 경험있는 프로그래머들이 형식 문자열을 사용하지 말라고 하는 이유이다.


제대로 출력하려면

wprintf(L"%s", s.c_str());

이렇게 써주어야 한다.


아니 그런데 왜 CString은 그냥 넣어도 잘 되고 std::wstring은 .c_str() 함수를 호출해야만 되는걸까. CString에 뭔가 비밀이 있는건가.


있다.


조금 더 주의 깊은 사람들은 CString의 구현을 살펴보고 LPCWSTR에 대한 형변환 연산자가 정의되어 있는 것을 발견해낸다. 아, 형변환 연산자가 있기 때문에 자동으로 형 변환이 되는거구나.


하지만 이는 형변환 연산자 때문이 아니다.


가변 인자 함수로 들어갈 때는 형변환이 발생하지 않는다. 함수 파라메터가 '가변'이고 무슨 타입이 들어올지도 적혀 있지 않는데 어떤 타입으로 형변환을 하는가?


CString의 코드가 잘 동작할 수 있는 비밀은 CString의 멤버 변수가 실제 문자열 데이터를 가리키고 있는 포인터 m_pszData 하나 밖에 없기 때문이다. 가상 함수도 없다. 객체의 맨 앞에 포인터를 가지고 있다는 것이 중요하다.


그림으로 그려보면 이렇게 생겼다.

재밌지 않은가? 문자열 클래스가 문자열 길이를 위한 변수도 가지고 있지 않고 달랑 WCHAR* 하나만 가지고 있다니.

하지만 CString의 은밀한 곳에서는 메모리를 조금 더 할당해서 문자열 길이나 레퍼런스 카운트를 저장하고 CString에게는 pszData 하나만 노출시켜 놓는다. 그리고 이렇게 설계한 이유는 사람들이 저런 실수를 하더라도 잘 동작하도록 만들고 싶었기 때문일 것이다.


하지만 잘 동작한다고 해서 그렇게 쓰는 것이 옳다는 것은 아니다. 가변인자의 파라메터로는 POD 만 들어갈 수 있다. NON-POD 타입이 들어갈 경우에는 모두 undefined behaviour이다. 나중에는 컴파일러의 구현 변경에 따라 동작하지 않게 될 수도 있다는 뜻이다. -말은 이렇게 하지만 그런 일은 좀처럼 발생하지 않는다.


어쨌거나,

wprintf(L"%s", (LPCWSTR)s); 또는

wprintf(L"%s", s.GetString());


이라고 써주어야 올바른 C++ 문장이다.


저작자 표시 비영리 동일 조건 변경 허락
크리에이티브 커먼즈 라이선스
Creative Commons License

http://www.benjaminlog.com/trackback/271 관련글 쓰기

  1. 스비 at 2012/04/12 13:42 [edit/del]

    유익한 내용 잘 배우고 갑니다. 항상 재밌게 글 읽고 있습니다. 고맙습니다.

    Reply
  2. BlogIcon Scavenger at 2012/05/27 11:02 [edit/del]

    유익한 내용 잘 보고 배웁니다.. 흥미로운 내용이네요^^

    Reply
  3. 이준배 at 2012/06/18 17:22 [edit/del]

    배우고 갑니다 글 남겨주셔서 감사합니다

    Reply
  4. Favicon of http://action713.tistory.com BlogIcon 예쁜꽃이피었으면 at 2014/09/04 12:38 [edit/del]

    CString 을 어떻게 출력해야하나 찾다가 오게되었습니다. 좋은 내용 감사합니다.
    담아갈게요~

    Reply

submit

ICopyHook은 윈도에서 제공하는 COM 인터페이스이다. 이 인터페이스를 구현해서 시스템에 등록시키면 쉘을 통한 파일 오퍼레이션이 발생할 때 내가 설치해 놓은 코드가 실행되도록 할 수 있다.

구현해야 할 함수는 이런 모양으로 생겼다.

UINT CopyCallback(
  [in, optional] HWND hwnd,
  UINT wFunc,
  UINT wFlags,
  [in] PCTSTR pszSrcFile,
  DWORD dwSrcAttribs,
  [in, optional] LPCTSTR pszDestFile,
  DWORD dwDestAttribs
);

파일 오퍼레이션을 잡아챌 수 있다고 해서 이 훅을 사용해 파일 삭제 등을 감시하는 모니터 용도로 사용하려는 아이디어는 좋지 못하다. 이 기능은 모든 파일 시스템 오퍼레이션에 훅을 제공하는 것이 아니라 폴더 삭제와 같은 특정한 몇몇 동작에 대해서만 동작하기 때문이다. 어떤 파일 오퍼레이션이 발생하는가 궁금한 거라면 파일 시스템에서 제공하는 파일 변경 알림 기능을 사용하는 것이 올바른 방법이다.

그럼 이 인터페이스는 도대체 어디에 쓰라고 만든 물건이고.

윈도우 탐색기에서 폴더를 삭제하게 되면 탐색기는 폴더 안에 있는 파일들부터 모두 지우고 마지막에 폴더를 삭제한다. 이는 NTFS 같은 파일 시스템이 폴더에 파일이 있으면 삭제하지 못하도록 하고 있기 때문이다. RemoveDirectory 함수를 호출했을 때 해당 디렉터리 내에 파일이 존재한다면 파일 시스템 드라이버는 STATUS_DIRECTORY_IS_NOT_EMPTY 에러를 돌려주도록 구현해야 한다.
윈도 탐색기의 이런 동작은 네트워크 파일 시스템 위에서는 치명적이다. 로컬 파일 시스템이라면 Irp가 몇 백번쯤 왔다갔다해도 금새 끝나겠지만 레이턴시가 긴 네트워크 파일 시스템 같은 경우는 저 멀리 미국까지 백 번 천 번을 왔다 갔다 해야 할 수도 있는 것이다.

ICopyHook 을 사용하면 이런 폴더 삭제나 이동 명령들을 먼저 잡아채서 내 마음대로 원하는 동작을 수행 한 뒤 ID_NO를 리턴함으로서 쉘에게는 더 이상 오퍼레이션을 하지 않도록 할 수 있다. 예를 들어 네트워크 파일 시스템 드라이버를 만든다면 쉘에서 폴더 삭제 같은 오퍼레이션이 발생할 때 이를 잡아채서 서버로 폴더 삭제 명령을 딱 한번만 보낼 수 있는 것이다. 물론 서버는 하위에 파일들이 있더라도 폴더를 삭제할 수 있는 기능을 지원해야 한다.
다른 많은 경우들에도 이 기능을 응용할 수 있을 것이다. 상상의 나래를 잘 펼친다면.

주의 해야 할 점은 내 훅이 실행될 때 어떤 에러가 발생하면 에러메세지를 사용자에게 보여주는 것도 내 책임이 된다는 것이다. ID_NO를 리턴하면 쉘은 해당 오퍼레이션에 대해서 더 이상 신경쓰지 않는 것을 기억하라. 함수의 첫 번째 인자로 들어오는 HWND는 바로 그런 사용자 인터랙션을 위해서 존재한다.

ICopyHook을 구현하면서 코드에 버그를 같이 넣어놓는다면 사용자는 윈도 탐색기 프로세스가 자꾸 비정상 종료되는 경우를 겪을 수 있다. 이는 사용자뿐 아니라 개발자들에게도 귀신이 곡할 노릇일 수 있다. 어떤 머신에서는 잘 동작하는데 특정 컴퓨터에만 가면 내 응용 프로그램이 파일 오퍼레이션을 할 때마다 윈도 탐색기가 죽어버리니 말이다. 경험이 어느 정도 있는 개발자라면 먼저 윈도 탐색기에 ICopyHook이나 쉘 확장 플러그인이 설치되어 있는지를 먼저 살펴보겠지만, 잘 모르고 있다면 크래시 덤프를 눈으로 보면서도 원인을 모를 수 있다. FOFX_NOCOPYHOOKS 플래그를 사용하면 훅을 완전히 무시하고 오퍼레이션을 수행할 수도 있다.


저작자 표시 비영리 동일 조건 변경 허락
크리에이티브 커먼즈 라이선스
Creative Commons License

http://www.benjaminlog.com/trackback/270 관련글 쓰기

submit