<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:thr="http://purl.org/syndication/thread/1.0">
  <title type="html">김 용묵의 절대공간 - 블로그: MFC-메뉴에 달린 최근 댓글/트랙백 목록</title>
  <id>http://moogi.new21.org/tc/</id>
  <link rel="alternate" type="text/html" hreflang="ko" href="http://moogi.new21.org/tc/" />
  <subtitle type="html">철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.</subtitle>
  <updated>2022-01-21T02:44:10+09:00</updated>
  <generator>Textcube 1.7.8 : Con moto</generator>
  <entry>
    <title type="html">김재주님의 댓글</title>
    <link rel="alternate" type="text/html" href="http://moogi.new21.org/tc/824#comment3853" />
    <author>
      <name>(김재주)</name>
    </author>
    <id>http://moogi.new21.org/tc/824#comment3853</id>
    <published>2013-04-29T19:03:52+09:00</published>
    <summary type="html">이제 사실상 윈도 API를 직접 사용해서 C로 코딩해야 하는 상황은 커널에 붙어서 동작해야 할 드라이버 말고는 없다고 봐야겠죠. 아직까지는 Native Code가 performance 측면에서 장점을 가지고 있기 때문에 MFC와 C++이 여전히 쓰이고 있습니다만 C#과 JAVA로 대세가 넘어가는 것은 시간 문제가 아닐까 저는 생각하고 있습니다.

이미 JIT 컴파일러가 실시간으로 profile을 통해 생성해내는 바이너리 코드가 static하게 생성된 프로그램을 뛰어넘는 경우가 보고되고 있으니까요. 특히 입력의 특성에 따라서 그때그때 분기의 흐름이 아주 다양하게 변화할 수 있는 프로그램의 경우엔 static profile guided optimization의 성능이 dynamic 버전을 따라가기 어려우니까요. 물론 이 방법에도 단점은 존재하지만...</summary>
  </entry>
  <entry>
    <title type="html">Lyn님의 댓글</title>
    <link rel="alternate" type="text/html" href="http://moogi.new21.org/tc/824#comment3854" />
    <author>
      <name>(Lyn)</name>
    </author>
    <id>http://moogi.new21.org/tc/824#comment3854</id>
    <published>2013-04-29T19:40:25+09:00</published>
    <summary type="html">jit은 이론상 스태틱한 컴파일러의 성능을 뛰어 넘고 실제로 최근들어 그런 강력한 jit 컴파일러들이 속속 등장하고 있지만 GC가 속도 다 까먹고있죠 (...)

뭐 요즘은 드라이버나 펌웨어도 C++로 짜니...</summary>
  </entry>
  <entry>
    <title type="html">Lyn님의 댓글</title>
    <link rel="alternate" type="text/html" href="http://moogi.new21.org/tc/824#comment3855" />
    <author>
      <name>(Lyn)</name>
    </author>
    <id>http://moogi.new21.org/tc/824#comment3855</id>
    <published>2013-04-29T19:45:44+09:00</published>
    <summary type="html">그나저나 UI 프로그램을 전혀 안하다보니 저런것들이 다른지는 몰랏네요</summary>
  </entry>
  <entry>
    <title type="html">사무엘님의 댓글</title>
    <link rel="alternate" type="text/html" href="http://moogi.new21.org/tc/824#comment3856" />
    <author>
      <name>(사무엘)</name>
    </author>
    <id>http://moogi.new21.org/tc/824#comment3856</id>
    <published>2013-04-29T23:20:30+09:00</published>
    <summary type="html">김재주, Lyn: 요즘은 MFC를 비롯해 C/C++의 라이브러리들 오버헤드도 너무 커져 보인다는 게 함정.
그러니 차라리 그런 공통된 오버헤드를 운영체제가 미리 다 담당하고 있는 더 상위 계층의 프레임워크의 존재 명분도 섭니다.
하지만 IME 쪽은 만년 네이티브 코드 강세 지대랍니다. ^^;;

그리고 아무리 성능 크리티컬한 환경이라도 요즘 어지간해서는 C++조차도 없이 C로만 코딩을 해야 하는 곳은 진짜 거의 없어지지 않았을까 싶네요.

라디오 체크 모양의 차이는 저도 최근에 발견하고는 흥미로워서 블로그 글로 정리했습니다.
IME 개발하려면 운영체제의 기본 UI하고는 쫙 밀착을 해야 한답니다. =_=</summary>
  </entry>
  <entry>
    <title type="html">김재주님의 댓글</title>
    <link rel="alternate" type="text/html" href="http://moogi.new21.org/tc/824#comment3857" />
    <author>
      <name>(김재주)</name>
    </author>
    <id>http://moogi.new21.org/tc/824#comment3857</id>
    <published>2013-05-01T11:42:21+09:00</published>
    <summary type="html">임베디드 쪽에선 아직 C로 짜야 하는 일이 흔합니다. 예를 들어 SD나 CF카드 내부의 FTL같은 곳이 그렇죠. 이쪽은 RAM도 SRAM이고 1메가에도 턱없이 모자라는 메모리 위에서 동작하는데다 턱없이 적은 소비전력만으로 동작해야 하니까요..

PC에서라면 말씀하신 것처럼 이제 C만으로 코딩할 일은 정말 없겠죠.</summary>
  </entry>
  <entry>
    <title type="html">Lyn님의 댓글</title>
    <link rel="alternate" type="text/html" href="http://moogi.new21.org/tc/824#comment3858" />
    <author>
      <name>(Lyn)</name>
    </author>
    <id>http://moogi.new21.org/tc/824#comment3858</id>
    <published>2013-05-02T09:04:48+09:00</published>
    <summary type="html">PC가 아니라 어지간한데도 다 ...

이미 예전에 임베디드라고 불리던 급의 기계들도 다 범용 OS 깔리게된지 한참이니 ...</summary>
  </entry>
  <entry>
    <title type="html">사무엘님의 댓글</title>
    <link rel="alternate" type="text/html" href="http://moogi.new21.org/tc/824#comment3860" />
    <author>
      <name>(사무엘)</name>
    </author>
    <id>http://moogi.new21.org/tc/824#comment3860</id>
    <published>2013-05-02T09:44:39+09:00</published>
    <summary type="html">음, 그런데 자원이 너무 열악해서 C++ 컴파일러조차 돌릴 수 없는 모바일이라 해도 크로스 컴파일은 가능하지 않을까요? 그것조차도 안 돼서 C만 써야 하면 정말 암울할 듯.</summary>
  </entry>
  <entry>
    <title type="html">김재주님의 댓글</title>
    <link rel="alternate" type="text/html" href="http://moogi.new21.org/tc/824#comment3862" />
    <author>
      <name>(김재주)</name>
    </author>
    <id>http://moogi.new21.org/tc/824#comment3862</id>
    <published>2013-05-03T13:11:47+09:00</published>
    <summary type="html">ARM을 쓰는 환경이라도 정말 천차만별이라.. 플래시 메모리 카드 같이 칩을 엄청 소형화해야 하는 경우에는 메모리와 CPU마저도 원칩에 통합시켜야 할 경우가 있습니다. 모바일 DRAM으로는 커버가 안 될 정도로요. 이 경우 SRAM을 사용해야 하는데 보통 96KB(!) 정도를 사용합니다.

C++을 크로스 컴파일해서 코드를 생성하는 것 자체는 가능한데, 이런 환경에서는 가상 생성자라든지 아무튼 C++에서 지원하는 고급 프로그래밍 언어 기술을 사용하기 위해서 구조체에 추가적으로 붙게 되는 그 약간의 공간마저도 상당히 아깝다는 거죠. 

그리고 이런 칩에 들어가는 프로그램들은 말 그대로 어떤 특수한 목적을 위한 전용 코드에 가깝기 때문에 OOP를 사용해도 그다지 이점이 없다는 것도 있습니다. 기껏해야 수천에서 수만줄밖에 안되는 프로그램이니까요.</summary>
  </entry>
</feed>
