2006-04-01

FirefoxはデフォルトでSerifが選ばれていたりしますが、Windowsでは、標準で入っている唯一の明朝体であるMS明朝はビットマップが埋めこまれていますので、WindowsXPでClearTypeを利かせていますとあまりありがたくないのです。MS明朝もさざなみ明朝もIPA明朝も、よく使いそうなサイズに限ってビットマップを埋めこんでくれているのは、大きなサイズで見える奇麗な明朝体を、そのまま小さいサイズで奇麗に見せるのが難しいからですね。サイズが小さくなるほど1ピクセルを調整するために移動させなければならない量が増え、逆に拡大時のバランスが悪くなるというわけです。グラフィックスに使われたり印刷に使われたりと考えると小さいサイズでしかもディスプレイという荒いデバイスでの表示を犠牲にするのは仕方ないでしょう。
…でも使う方はそのディスプレイでの小さいサイズでの表示が一番多いわけで。折角のClearTypeなんですからどうにかしたい。
それでもゴシック体は、結構奇麗なフォントがあるんです。Officeに付いてくるHGゴシックEだってブラウザやエディタに使えるぐらいです。明朝は、上記3フォント以外は何万円もするものを除けばディスプレイ表示用途には壊滅的に思えます。私は今までHG正楷書体-PROでごまかしていましたが、楷書体をブラウザに使うのは何か違うような気がします。
この3つのフォントからビットマップを抜けばどうなるでしょうか？とりもなおさずガタガタで読めたものじゃなかったのですが、問題なのはClearType上での表示です。ClearTypeを効かせると、それなりに見えたりは…しません。特にさざなみ明朝なんか薄すぎて判別不可能になっちゃいます。しかし、IPA明朝は、ベースラインこそガタガタですが、個々の文字はそこそこには奇麗なんじゃないかとも思えました。
そこで微調整をかけてみました。ClearType以外での表示や、拡大時の表示がとても汚くなってますが、気にしてはいけません。
…4/1に公開する意義は特に無いです。

舌の根も乾かぬうちから比較話をします。ごめんなさい。「そこまでするなら〜」だけは書かないように気をつけますです。
さて、Move Semanticsってなんなのかと思ってちょっと見てみたわけです。名前からしてAda2005のbuild-in-place相当の機能がC++0xにも入るのかなと思ったら違ってました。でも目指すところは近いっぽいです。
例としては、文字列がわかりやすいです。
Delphiの参照カウンタ管理されるAnsiStringも、同じメモリイメージになるようにC++で実装されたC++BuilderのAnsiStringも、全く同じもののはずではあります。ところが実際にはDelphiのほうが遥かに効率よく文字列を扱えます。
Delphi側は、組み込みであるが故に、参照カウンタを増減させなくて良いケースその他、処理をすっ飛ばせる場面をコンパイラが把握できるからですね。一方C++側では規格どおりにコンストラクタ、デストラクタ、コピーコンストラクタが走るわけです。

function Cat(const A, B: string): string; 
begin 
  Result := A + B;
end;

AnsiString Cat(AnsiString const &A, AnsiString const &B)
{ 
  return A + B; 
}

引数は参照でコピーを抑えることができますが、返値については、"+"演算子の返値の一時オブジェクト、Cat関数の返値の一時オブジェクト、呼び出し側の変数それぞれについて、生成し破棄し生成し破棄し。
C++の規格でも最適化は認められているらしいですが、限度はありますので、こんな風に書いてしまうとほぼお手上げになります。

AnsiString Cat(AnsiString const &A, AnsiString const &B)
{
  AnsiString Result; 
  Result = A + B; 
  return Result;
}

一方Delphiのほうは、結合結果がそのまま呼び出し元まで運ばれてそれで終わりです。
外付け実装ですと、コンパイラは、一時オブジェクトとはいえ他から参照されていない確信を持てませんので、返値用の領域や例外ハンドラがどうのこうの。
というわけで、後からいくら頑張っても組み込み型にはかなわないのです。
それでMove Semanticsですが、それでももうちょっと頑張ろう、という話っぽいです。
まずtemplateメタプログラミング先行らしく、ようするにauto_ptrによくにたmove_ptrというのがあってていすうなのかへんすうなのかをせいてきにはんべつしたうえでこぴーをはっせいさせずにあたいをうけわたしていくことができるらしいです。
つーかC++に疎い私が今日知ったばかりのことを説明するよりも、ずっと追っかけられておられる方の日記を引用した方が早いのでそうします。
http://d.hatena.ne.jp/Cryolite/searchdiary?of=5&word=move%20semantics
…こうして普段から説明を投げてると、段々説明下手になっていっている自分がいるので良く無さげなのですが。
で、そのままではかなりややこしいことになってるみたいで、テクニックを駆使したあげくそれでも使うのが難しいみたいな。それをスマートに実現するべく、C++0xへmove_ptrの実装を楽にする機能を言語機能として追加しようという話らしいです。参照の新種となるようです。

void foo(A&&);
A&& source_rvalue_ref();
A&& rra = a;

…コンパイラ作る人お疲れ様です。まあポインタが"*"の時点でA * B = C;が式なのか宣言なのかを区別するにはAが型なのか変数なのかを見るしか無さげといえばそうなのですが、"&"が加わり、"&&"が加わり…。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htmを読んだ感じでは適切にオーバーロードを書けるようにするためのマーキングの意味合いが強いような。コピーコンストラクタで「移動」を明示的に書かないといけないような…？勘違い？…いや、operator +も3種類オーバーロードする例が出てますからその通りなんでしょう。HaskellのIOというかCleanの一意型のほうが適切なのか、まあその辺のように、機械語レベルで見たら意味が無いマーキングを付けておいて、使われ方をMove Semanticsが実現できるよう限定する手助けをコンパイラがしてくれる、という感じっぽい。
あくまで詳細は書かせるあたりがC++か。値型を作ろうと思えば書かなければいけないものがT(T const &), T(T const &&), operator=(T const &), operator=(T const &&)とふたつが4つに増えたわけですね…あくまでMove Semanticsを実現するための助けとなる機能であって、move_ptrそのものを言語に組み込むとかまたはそういったものが不要なように言語を調整するとかの方向には行かないあたりもC++か。しかも標準ライブラリが…C++のバージョンを選ぶコンパイラスイッチが頭をよぎり…コンパイラ作る人お疲れ様です。
templateメタプログラミングもそうですが、当然インライン化にも限度がありますし、実行ファイルサイズ膨らませるとロードも遅くなるしキャッシュミスも増えますしで、効率よくしようとして逆に悪くしてなければいいんですが、なんて思ってしまう私は貧乏性なのでしょうか。std::arrayなんてものを必要とする言語がどこまで自身の機能の組み合わせ爆発に耐えられるかは見てみたいものがあります。
あとModern C++ Designでぼやかれていた&に&は、もちろん&&のMove Semantics、じゃなくて、&ひとつの単なる参照になるっぽいです。A & & BとA && Bが式と宣言それぞれで別の意味となる面白構文増えたなとニヤニヤ。
さてこれ、同じ型の値でも二通りのオーバーロードができるようになったということで、Move Semanticsを無視した別の使い方がなにかできそうなのですが…。例えば書式化関数と出力関数を分けるような場合にどんな風に書式化されたかを出力関数まで静的に教えてやるとかどうでしょうか。うーむ、何を考えてもLokiとBoostで既出な気がしてしまう私はC++知らず。
関係ないですがreturnよりもResult方式のほうがif(...) return A; else return B;なんて書かれない分最適化はずっと有利なんじゃないかと。だからもうちょい頑張れDelphi、inlineで文字列の結合までできてるのにどうして_LStrAsg呼ぶのよ！？(←たわごと)

Note

IPA明朝は結構奇麗なんです

Move Semantics

Modula-2