텍스트 지향 운동의 취지

codian.net도 텍스트 지향 운동에 동참합니다. 뒤늦은 감은 있지만…

지난 포스트에서 소개한 파서 생성기 Coco/R로 만들어진 스케너(lexical analyser)는 각 토큰이 어떤 토큰인지 지정하는 인덱스 값을 참조해 어떤 토큰인지 구분해 낼 수 있습니다.

하지만 스케너가 자체 생성해 낸 인덱스 값으로 토큰을 구분한다는 것은 매우 불편합니다. 또한 스케너 자체만으로 토큰들의 의미있는 그룹핑(토큰분류)을 할 수도 없습니다.

토큰을 분류할 수 있도록 Coco/R의 토큰 정의 문법과 파서 생성기 코드를 수정해 봤습니다.

자세한 내용은 여기에서 확인하세요.

PDC2005의 BOF 세션을 신청한 Mono의 Miguel de Icaza 의 제안은 PDC 2003에 이어 마이크로소프트에 의해 개무시 되고 있습니다.

우려되고 있는 Mono의 미래가 현실이 되는건 아닌가 싶습니다. CLI와 C#을 표준화한 마이크로소프트가 모노를 적극 지원해야 하지 않나 싶은데 말이죠. 정말 이해할 수 없는 일입니다.

복도가 되었던 근처 호텔이 되었건 Mono 미팅이 성사되길 기대해 봅니다.

윈도우 개발팀의 하위호환성을 위한 노력은 이미 조엘 온 소프트웨어 에서도 나와있 듯이 대단하다고 합니다.

윈도우 95 개발 무렵 윈도우 95 개발 관리자는 픽업 트럭을 몰고가 소프트웨어 판매점에 있는 모든 종류의 PC 소프트웨어 한 카피씩을 사다가 개발 팀원들에게 테스트를 시켰다고 합니다. (Buying an entire Egghead Software store - The Old New Thing)

그렇게 해도 회사에서는 돈을 잘 내주는가 보죠?

C++에 bool 타입이 빌트인으로 추가되기 이전에는 boolean을 나타내기 위해 값과 타입을 정의하여 사용했었습니다. 다음은 Win32에서 사용하는 boolean 정의입니다.

#ifndef FALSE
#define FALSE  0
#endif

#ifndef TRUE
#define TRUE  1
#endif

typedef int BOOL;

저도 그동안 당연히(!) bool의 사용을 더 선호해 왔습니다. BOOL과 거의 다름없이 사용할 수 있을 뿐만 아니라 컴파일러에서 지원하는 타입이므로 type-safty은 당연히 따라오는 장점이겠지요.

BOOL 과 bool의 차이점이라면 bool을 BOOL로 타입 변환할 때 컴파일러에서 성능 경고를 낸다는 정도로만 알고 무심히 사용해 오다 데이터 표현을 위한 메모리 사용이 틀리다는 사실을 알았습니다. BOOL의 경우 int로 정의되어 있으므로 당연히 4바이트, bool의 경우는 1바이트의 공간에 잡히게 된다는 것입니다.

사실 이런 차이는 크게 신경쓸 만한 것도 못되지만 다음과 같은 경우에는 심각한 버그를 만들어 낼 수 있습니다.

닷넷 P/Invoke 에서 System.Boolean을 BOOL로 마샬링할 것이냐 bool로 마샬링할 것이냐에 따라 MarshalAs 속성값을 다르게 지정해야 합니다. BOOL로 마샬링하기 위해서는

[[StructLayout(LayoutKind.Sequential)]
protected struct MyStruct {
    [MarshalAs(UnmanagedType.Bool)]
    public bool aBool;
};

과 같이 기본적으로 제공되는 UnmanagedType.Bool을 사용할 수 있지만 bool의 경우에는

[[StructLayout(LayoutKind.Sequential)]
protected struct MyStruct {
    [MarshalAs(UnmanagedType.I1)]
    public bool aBool;
};

과 같이 UnmanagedType.I1을 적어주는 세심한 주의가 필요합니다.

일반적인 Interop/마샬링 관련 문서들에 설명되어 있는 데로 UnmanagedType.Bool을 사용하게 되면 bool 타입 변수에는 true나 false에 상관없이 항상 false가 전달됩니다.

코드에 이런 버그가 들어 있다면 찾아내기 힘들지 않겠습니까? 저는 이 버그를 찾는데 2~3시간 정도 허비한 것 같습니다. ㅠ_ㅠ