C++ Ramble

http://www.boost.org/more/logo_contest.htm

わ〜い.新しいロゴだぁ〜.

Closure Function

http://thread.gmane.org/gmane.comp.lib.boost.devel/121844
Closure FunctionならBoost.Bind + Boost.Functionで十分ってことか.

Boost Version History

http://redshift-software.com/~grafik/boost/more/version_history.html
Boostの長い歴史(あくまでこの業界の感覚で)を垣間見ることができますな.

構文が有効かどうかを判定するtraits

http://thread.gmane.org/gmane.comp.lib.boost.devel/121890
operator<<のように非メンバ関数として(も)宣言できる演算子(より一般には非メンバ関数)の場合なら,存在するか否かをほぼ判定できるtraitsを書く技法はあるっちゃあるんだけれど.

// pre-incrementが可能かどうかを判定するtraitsの定義.
// ユーザ定義変換によるオーバーロード発見の優先順位が
// 他のオーバーロードより低いことを利用しているため,
// ユーザ定義変換を通してoperator++が見つかるような型に対しては
// 使えない.(オーバーロードが曖昧になる)
// 演算子関数なのでこういう限界がある(引数の個数が限定される)が,
// 一般の非メンバ関数の存在判定なら可変長引数関数のオーバーロードを
// 使ったほうがより安全.
// (ユーザ定義変換を通じたオーバーロードの優先順位よりさらに低いため)
// ちなみにわざわざカンマ演算子(operator,)を使っているのは
// 戻り値がvoidの場合でも機能するようにするため.
// pre-incrementではあまり意味がないが,戻り値がvoidな非メンバ関数の
// 存在判定をやる場合には必須.
#include <boost/mpl/assert.hpp>
#include <boost/mpl/not.hpp>
#include <boost/mpl/bool.hpp>
#include <boost/config.hpp>

namespace detail{

struct anything
{
  template<class T>
  anything(T const volatile &);
};

struct not_exists_tag
{ };

not_exists_tag operator++(anything);

struct rhs_of_comma
{ };

template<class T>
char operator,(T const volatile &, rhs_of_comma);

typedef char (&no_t)[2];

no_t operator,(not_exists_tag, rhs_of_comma);

template<class T>
struct is_pre_incrementable_impl
{
  static T &x;
  BOOST_STATIC_CONSTANT(
      bool, value = sizeof(++x, detail::rhs_of_comma()) == 1
    );
  typedef boost::mpl::bool_<value> type;
};

} // namespace detail

template<class T>
struct is_pre_incrementable
  : public detail::is_pre_incrementable_impl<T>
{ };


////////// ここまでライブラリコード //////////
//////////   ここからユーザコード   //////////


struct A{
  A &operator++();
};

struct B{ };

B &operator++(B &);

struct C{ };

BOOST_MPL_ASSERT((is_pre_incrementable<A>));
BOOST_MPL_ASSERT((is_pre_incrementable<B>));
BOOST_MPL_ASSERT((boost::mpl::not_<is_pre_incrementable<C> >));

int main()
{
  return 0;
}

でもメンバ関数の存在判定ができないんだよな〜.ここで書いてることができたら(というかこれがやりたいがためにああいうことを考えていた)fallback用の関数宣言を混ぜ込んで上とほぼ同じ手法でメンバ関数の存在判定ができるのにぃ〜〜〜.う〜〜〜.

Network Library

http://thread.gmane.org/gmane.comp.lib.boost.devel/121691
http://thread.gmane.org/gmane.comp.lib.boost.devel/121712
http://thread.gmane.org/gmane.comp.lib.boost.devel/122093
何かまとめっぽいポストが2つあるけれど読んでるひまない〜〜〜.興味はあるのにぃ〜〜〜.恐らく次々回(次回じゃないよ?)の標準ライブラリ改訂の1つの目玉になるはず(後述)なだけに・・・む〜ん.

IRC channel for Boost

http://thread.gmane.org/gmane.comp.lib.boost.devel/122269
む,IRCか・・・.今度覗いてみようっかな?英語の訓練かねて.

Design by Contract

http://thread.gmane.org/gmane.comp.lib.boost.devel/121931
面白そうだけれど読んでるヒマがにゃーい!

多相的な型を保持するコンテナ

http://thread.gmane.org/gmane.comp.lib.boost.devel/122622
コンテナが多相的な型を持つにはポインタを持たせたないといけないけれど,それはメモリの面倒見るのがしんどいし,かといってshared_ptr使うのは重過ぎる場合があるだろうし・・・.Move Semanticsをきちんと扱えるコンテナ実装を書いてmove_ptr使うっていう選択肢も提供してくれるのが理想なんだけれどなぁ〜.でも,そもそもMove Semanticsの是非の議論がまだまだだしな.自分で書いたMove Semantics付きコンテナと借り物のmove_ptrでぽちぽち試すしかないのかな・・・.

aligned_storage

http://thread.gmane.org/gmane.comp.lib.boost.devel/122272
アラインメント周りの話はあんまり分かってないから勉強がてらここら辺の議論読んでみようかな.あんまり深く突っ込むとハードの話に逝きそうだけれどそれはあくまで見ない方向で.

copyability

http://thread.gmane.org/gmane.comp.lib.boost.devel/122603
うひゃあ,こりゃまた超基本的かつ超深遠な議論ですな.「ライブラリがコピーを提供するべきかどうか」って,基本過ぎて逆に見落としてたーよ.でも汎用ライブラリ・汎用プログラミングというのはそういう超基本的な部分から抑えていかないといけないわけで・・・.

Boost to the rescue

http://thread.gmane.org/gmane.comp.lib.boost.devel/121833
おぉ.こういう話はここでしか聞けないし,だからこそ一番聞きたいし,聞いてて非常に面白いのだ.
http://article.gmane.org/gmane.comp.lib.boost.devel/122866
お?お?お?

TR2

ようやくTR1の実装が出てきたと思ったらすぐにこれだもんな〜.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1810.html
どれどれ,ちょっと覗いて・・・

The committee especially welcomes proposals in the following areas:

 -Unicode
 -XML and HTML
 -Networking
 -Usability for novices and occasional programmers

うぉっ!何この「クイズC++ユーザ100人に聞きました.今のC++標準ライブラリに足りないものといったら何?」*1の上位8位ぐらいに入りそうなリスト.(GUIとかFilesystemとかThreadとか他にも色々あるので上位8位ぐらい止まりのはず・・・)
ところで"Usability for novices"は分かるけれど,"Usability for occasional programmers"って何だろ?


「あ,ちょっとこれスクリプトで書いてみよっと.」
「ちょ〜っと待ったぁ〜!!」
「誰だっ!?」
「ちょっとしたプログラミングにスクリプト.そんな安易な考えで良いのだろうかっ!?これからの時代はちょっとしたプログラミングにもC++!スタティ〜ックなタイプとコンパイルタイムカルキュレイションがあなたのオケイジョナルプログラミングライフをより豊かにっ!これが最新のトレンドッ!ナウなヤングにもバカウケッ!」
・・・ナンカチガウ?
#っていうかこれだと"occasionla programming"か."occasional programmers"だからまた違うな.むしろ下のような感じか?

「プログラム書かないといけないんだけれど,イマイチプログラミングって分っかんないだよな〜.とりあえず簡単な言語で・・・」
「ちょ〜っと待ったぁ〜!!」
「誰だっ!?」
「プログラムを書かなければならないけれど,イマイチプログラミングが良く分かっていない.そんなときこそC++!(途中の説明は長いので省略)ナウなヤングにもバカウケッ!」
・・・コレモチガウ?

*1:全然関係けれどこれを自分で読み直した時に自分の年齢を感じた