MFC(C++)でHTTP通信。

あんまり的テキトーなことは書きにくい雰囲気になっちゃったけど、まあ自分のブログやし家で書いてるんやからエエかと。

最近仕事ではC#ばっかり書いてる。家での調べ物もC#関連が多い。よりはっきり書いちゃえばWPFとかXAMLとか。
ちょっと前はTPL(Task Parallel Library)を真剣に調べてたけど、これは仕事でやってるから家でちょこっとやるより進歩が早いんで、もうだいたい解った気分。

で、表題の件になる。
JavaScriptでもJavaEEでも、C#でもRubyでも近代的なプログラミング言語、動作環境であればsubmitベースの行ってこいでもAjaxでもHTTP通信するだけのネットワークプログラミングはかんちんに書ける。
俺っちが人生で初めてHTTP通信をC++で書いてみよっかな？とか思った頃は、まだまだソケット(WinSock)とかってな低レベルなAPIを使わなアカンかった頃で超大変やってずばり挫折した。
つーかさ、レガシーなWin32 APIの世界ではマルチバイト文字列（日本語）を扱うだけでも、メッチャ苦労したんだぜ？その状況で、MS932(Shift JIS)じゃ無い文字コードを扱う（変換する）とか・・・悪夢やんか。ねー。

それ以前にネットワークプログラミングに興味もあんま無くて、知識も全然無かったわけやけどさ。

なんで今さらC#じゃ無くてC++なのさ！ってことなんやけど、まあ深い事情があってそうしか選択肢が無い。深い事情・・・でも無いかな。Windows APIのコアのところは変化してなくてCOMとC++が支配するゴリゴリの低レベルな世界なんで、.NET Frameworkの近代的なハッピーな世界とは景色が違う。
実際問題としてはHTTP通信自体はCOMもC++も関係ないんでC#で書いても全く問題無いんやけどManagedとUnmanagedが混在するのは避けたい。ついでに言えばOLE Automationみたいなプロセス間通信とかを使ってのアプリケーション連携なんてのはもっと避けたい。時代遅れのテクノロジー。

と言うわけで、Windows8.1がリリースされるかってタイミングながら近々C++の世界に舞い戻らなアカン。
昔ほど大変じゃ無いのと、自分自身がネットワークプログラミングの知識も随分増えたし、知識もネット上のサンプルプログラムを沢山あるんで問題無いとは思ってる。
ただただ面倒くさいのと、エラーハンドリングとテストが大変っつーことぐらいかな。Bounds Checker*1みたいなツールってまだ売ってるんかな？

近々実験コード書くところからスタートする。やっぱアプリケーションを書くのって楽しいんだよね。家で趣味プロやってストレス発散せんでも良いぐらいに。
まとまりないけど、このままアップする。

*1:DevPartner Studio