char*萌えブーム

だれかrope萌えって奴はいないのかー!!　いや、そんな変態いても困るけど。なんだかchar*萌え人口が多いのでちょっと戯言を。
まあ、c++になってstringクラスが出来るまでは文字列といえばchar*だったのだけれども。stringはいろいろ操作できるが、そういったコンテナ的機能よりもスマポ的な役割が非常に大きいと思うんですよ。char*はそのあたりが非常に大変な場所だと思います。
関数で文字列を返したいときの実装って、大きく２つあると思うんですよ。

void CharPointerMOE( char** pp, DWORD* pdwSize );
void CharPointerMOE( char*  p,  DWORD   dwSize );

なんだか間違い探しみたいですけどこの二つは全然違います。前者は内部でメモリ確保してその先頭ポインタとサイズを返すタイプで後者はこちらからメモリ領域を指定してそこにコピーしてもらうタイプ。どちらも一長一短があります。前者は関数の結果の文字列が事前に予測できない場合に有効だが、当然メモリは動的確保になるので開放し忘れてしまう可能性がある。一方、後者はその逆でリークの心配はないがあらかじめサイズがわかっている必要がある。WakanaArcは前者が多くてWinAPIは後者が多いようですね。ちなみに私は前者のタイプは速攻で自作のsmart_arrayにぶち込んでしまいます。

char* p;
DWORD dwSize;
void CharPointerMOE( &p, &dwSize );
smart_array< char > acCharMoe( p, dwSize );

これでリークの心配はないので欠点が消えます。というわけで前者マンセーなわけなんです。

一方、stringを用いた場合はどうでしょうか？

void StringMOE( std::string& st );
std::string StringMOE();

前者だけでもいい気もしますが、後者はいじったのを返すというのが一目でわかるという利点があります。引数が一つで済むのはリークの心配やサイズ固定というchar*の弱点部分をstringがサポートしているからですね。ここで大きいのはやはりリークの心配がないということだと思います。つまり、string自体が一種のスマートポインタなんですよね。サイズ所得とか文字列操作の機能とかよりもまずこのスマポ機能が一番大きいと思います。
とはいえ、リーク対策というだけで重いstringを使うのも気が引けるのでここは是非smart_arrayを。(て宣伝デスカ)
ちなみに、stringの欠点はコンパイラによって内部実装が違う可能性があるというのがありますね。なのでオープンソースでないライブラリでstringを関数の引数や戻り値に利用するのは危険です。ライブラリ側と実装側の開発環境が違うと使えない場合がありますので。ただ、ライブラリの内部的に利用するのは問題ないでしょう。

ついでに、char*版の数値→数字変換関数の実装例を・・・と言いたいところだが激烈に面倒くさそうだから割愛します（ぉぃ