ASCII/MBCS UNICODE

WindowsAPIのうち文字列を扱う関数には、ASCIIやMBCSを処理する末尾にAが付くものと、UNICODEを処理する末尾にWが付くものがある。アプリケーションではAPIと接する文字列の文字型としてマクロのTCHARを使い、そして末尾にAやWが付かないマクロでAPIを呼び出すように書けば、どちらにも切り替える対応が出来る。（UNICODEに対応していなかったり、UNICODEにしか対応していない、古いWindowsや組み込み向けのWindowsは除く）C++の場合、マクロで切り替えじゃなくてオーバーロードで切り替えた方がcharでもwchar_tでもTCHARでも自動で対応出来るので便利なんだけれど、MSも用意するのが面倒くさいのか用意されてない。クラス使えって事なんだろうけど、たまにダイレクトに使う時にも出来るだけ楽したい。

A系のを呼んだときに、内部ではUNICODE文字列に変換した後にW系のを呼び出し、呼び出し終わった後には結果の文字列が有る場合はUNICODEからASCII/MBCS列に変換したり、必要ない場合はUNICODE文字列を削除したりしているんだろうか？もしそういう実装だと、廻る回数が多いループ内でA系のAPIを呼び出していると結構積み重なるコストが馬鹿にならない気がする。多言語対応の事も考えると、きちんとUNICODEに切り替えられるようにコーディングをした方が良いんだろうなぁ…。

いくつかの理由で、自分はUNICODEに切り替えられないアプリを書き続けてしまっている。

　1つ目の理由として、C++標準の文字列型であるtypdefされたstd::stringを使う事が多いのでASCII/MBCSにか対応しなくなってしまっている。stdafx.hとかでtypedef std::basic_string tstring とかして使うべきなのかなぁ。MS提供のCStringもよく使うけれどこれは内部でTCHAR文字列を使ってるようなものなので大丈夫だろう。CStringの実装の方がstd::basic_stringより効率が良いとしても、標準ではないのであまり使いたくないけど暗黙の変換演算子とかのお陰で便利なので使う。
　あと別の理由としては、ファイルにデータを保存する場合や、通信を経由する際にはUNICODE文字列ではなく、ASCII/MBCS文字列を使うけれど、変換ルーチンを置くのが面倒。（もしUNICODE文字列にASCII文字列を渡していた場合にASCIIからUNICODEに変換させる、またはその逆を行う関数）
　あと古き悪きShiftJISを使い続けるのが古くからの日本語Windowsユーザーの取るべき姿なんじゃないだろうか。途中でデータに使われる文字列のフォーマットを変更するコストを掛けるべき時と掛ける必要が無い時が存在するとしたら、コストを掛ける必要が無いところにまで負担が生じるのは好ましくない。UNICODEへの変化の流れを少しでも遅らせる為にこれからも足を引っ張り続けようと思う。多数派がコストを掛けるより、他のエンコーディングを使っているマイナーな人とか物好きな人に変換のコストを負担して頂いた方が、トータルで必要なコストは低いと思う。全体としての効率は残念ながら上がっていかないけれど。パレートの法則の8割側が好き。