INASOFT 管理人のひとこと

ListView to CSVの主な動作には3つの動作モードがあります。

• ファイル出力
• クリップボード出力
• 開く

ではなく

• ファイル出力
• クリップボード出力
• サンプルウィンドウ出力

です。（「開く」は、ファイル出力の後に指定アプリケーションを開く動作となるため、実は「ファイル出力」と同じルートを辿ります）

上記3つの動作は、それぞれ動作効率化施策が異なるため、違う動作モードとならざるを得ません。

ファイル出力の場合、約64KBごとにバッファしてファイルへ出力するため、64KB程度の固定メモリを確保しておいて、文字列を溜め込んでいます。

（さっき気づいたのですが、実際にはUnicodeの文字換算だったので、上記の2倍のバッファが準備されていました。まぁ、微々たる差です）

次にクリップボード出力の場合は、std::wstring 型の文字列変数に文字をどんどん溜め込んでいき、最後にクリップボード転送用のグローバルメモリへ一気にコピーします。

従って、メモリ効率化施策は （VC++実装の）basic_string のメモリ確保の方法に従うことになり、また、最終的にはグローバルメモリ分とローカルメモリ分の2倍のメモリ容量を必要とします。あまり効率が良いとは言えないかもしれません。

最後に「サンプルウィンドウ出力」ですが、こちらもクリップボードの場合と同様ですが、最後にはローカルメモリからサンプルウィンドウのEDIT BOXへ文字列を渡すだけとなっています。効率の善し悪しはクリップボードの場合と同じです。

というわけで、クリップボード出力の場合のメモリ確保効率化を行いたいところです。

どこが悪いのかというと、std::wstring は内部的に、あらかじめ確保したバッファが足りなくなった際、「新しく2倍のサイズのメモリ領域を別に準備し、そちらへコピーする」という動きをします（2倍かどうかは実装による）。この再確保とコピーは、それなりに時間がかかりますし、一時的に無駄な領域を必要としますし、なによりもメモリ内にフラグメントが発生し得ます。

なので、文字列を溜め込むときはstd::list<std::wstring>かなんかの形にしておいて、メモリ再確保時の無駄がなるべく発生しないようにしてみたい。

とりあえずそんなことを考え中です。