이제 사실상 윈도 API를 직접 사용해서 C로 코딩해야 하는 상황은 커널에 붙어서 동작해야 할 드라이버 말고는 없다고 봐야겠죠. 아직까지는 Native Code가 performance 측면에서 장점을 가지고 있기 때문에 MFC와 C++이 여전히 쓰이고 있습니다만 C#과 JAVA로 대세가 넘어가는 것은 시간 문제가 아닐까 저는 생각하고 있습니다.
이미 JIT 컴파일러가 실시간으로 profile을 통해 생성해내는 바이너리 코드가 static하게 생성된 프로그램을 뛰어넘는 경우가 보고되고 있으니까요. 특히 입력의 특성에 따라서 그때그때 분기의 흐름이 아주 다양하게 변화할 수 있는 프로그램의 경우엔 static profile guided optimization의 성능이 dynamic 버전을 따라가기 어려우니까요. 물론 이 방법에도 단점은 존재하지만...
김재주, Lyn: 요즘은 MFC를 비롯해 C/C++의 라이브러리들 오버헤드도 너무 커져 보인다는 게 함정.
그러니 차라리 그런 공통된 오버헤드를 운영체제가 미리 다 담당하고 있는 더 상위 계층의 프레임워크의 존재 명분도 섭니다.
하지만 IME 쪽은 만년 네이티브 코드 강세 지대랍니다. ^^;;
그리고 아무리 성능 크리티컬한 환경이라도 요즘 어지간해서는 C++조차도 없이 C로만 코딩을 해야 하는 곳은 진짜 거의 없어지지 않았을까 싶네요.
라디오 체크 모양의 차이는 저도 최근에 발견하고는 흥미로워서 블로그 글로 정리했습니다.
IME 개발하려면 운영체제의 기본 UI하고는 쫙 밀착을 해야 한답니다. =_=
ARM을 쓰는 환경이라도 정말 천차만별이라.. 플래시 메모리 카드 같이 칩을 엄청 소형화해야 하는 경우에는 메모리와 CPU마저도 원칩에 통합시켜야 할 경우가 있습니다. 모바일 DRAM으로는 커버가 안 될 정도로요. 이 경우 SRAM을 사용해야 하는데 보통 96KB(!) 정도를 사용합니다.
C++을 크로스 컴파일해서 코드를 생성하는 것 자체는 가능한데, 이런 환경에서는 가상 생성자라든지 아무튼 C++에서 지원하는 고급 프로그래밍 언어 기술을 사용하기 위해서 구조체에 추가적으로 붙게 되는 그 약간의 공간마저도 상당히 아깝다는 거죠.
그리고 이런 칩에 들어가는 프로그램들은 말 그대로 어떤 특수한 목적을 위한 전용 코드에 가깝기 때문에 OOP를 사용해도 그다지 이점이 없다는 것도 있습니다. 기껏해야 수천에서 수만줄밖에 안되는 프로그램이니까요.