C++ Ramble

[Boost][Python]Boost.PythonのビルドでのPythonのバージョン指定

http://www.boost.org/libs/python/doc/building.html
お〜.Pythonのバージョン指定するやりかたが分からなかったんだけれどこれでビルドが通る.
以下はWindows環境でPythonのインストール先がC:\Python23,versionが2.3.xの場合のビルドコマンドの例.

bjam "--with-python-root=C:\Python23" "-sPYTHON_VERSION=2.3"

('Д')y ─┛~~<Boost.Pythonで遊ぶためだけにPython入れてる自分に惚れるぜ

[Boost][Build]jamfileの空白

http://thread.gmane.org/gmane.comp.lib.boost.build/8005
(boost.build)

all most of you know, Jam is sensitive to spaces. A typical first user's error is:

  exe a : a.cpp;

あるあるw.っていうか自分の最初のエラーも確かこれだったはずw.
一旦「空白を空けない限り独立したトークンとして識別されない」って覚えればそれはそれで一貫してるから楽なんだけれど.

[Boost][Range]range algorithms and adaptors

http://thread.gmane.org/gmane.comp.lib.boost.devel/116779
演算子オーバーロード使うのか.個人的には好きじゃないんだけどなぁ.・・・ってこれだとadaptorを前方から適用する書き方に出来るのか.これは(゜д゜)ウマーかも.

[Boost][Interface]Boost.Interface

http://thread.gmane.org/gmane.comp.lib.boost.devel/116845

  • Current applications include:
    • Non-intrusive dynamic polymorphism - interfaces can often be used in place of abstract base classes, and are sometimes much faster.

うむ.Christopher Diggins氏は"High Performance Alternative to MI of virtual functions"って表現してるけど,やっぱりMI(Multiple Inheritance: 多重継承)に対する強力な代替手段という意識が第1にあるのかな?

    • Dynamic inheritance - allows function calls to be forwarded automatically to an object specified at runtime.

他の言語で言うところのdelegationかな?他の言語のこと良く知らないとこういうときに困る・・・.

    • Smart Interface Pointers - smart pointers which can manage the lifetime of any object whose type implements a given interface.

これと既存のスマポとの差分はなんなんだろうか?
#ABIの制御?

    • Smart References - like smart interface pointers, but the managed object is accessed using the dot operator.

インターフェースクラスのオブジェクトってそのまんまで(通常のC++における抽象基底クラスの)参照として振舞うはずだから,これにlifetime/ownership管理を付ければほらスマートリファレンスの出来上がり♪ってところかな?

    • The Object Oriented Template Library, a project in the initial stages of development, by Christopher Diggins.

これは文脈を追ってないからよく分からん.

  • Planned future applications include:
    • Runtime reflection - will allow an interface's functions to be enumerated and looked up by name at runtime

うひょ.っていうか特有の記述言語で書かせる以上,これは最低限つけて欲しいよな.

    • Aspect Oriented Programming as described in a August 2004 Dr. Dobb's Journal article by Christopher Diggins.

AOPとのつながりがイマイチよく分からない・・・.

  • Possible future applications include:
    • Integration with component architectures such as COM and CORBA.

これは良く知らないからパス.
#最初よく分からなかったけれど,ABI周りにおけるBILの重要性を認識するとこれもかなり重要と思い始めるのだった.

    • Boost.Names - by abstracting the various uses of identifiers in C++ into preprocessor generated types called names, C++ classes and functions can be constructed in a straightforward manner using template metaprogramming.

???面白そうだけれど,イマイチピンとこない.
#って,実装覗いてみたらまず名前(識別子)を表現する型らしきものがある.これだけでも口あんぐり.というのも文字列リテラルをテンプレート引数として取ることができないはずなので("C++ Templates"には出来るって書いてあるけれど文字列リテラルは内部リンケージ持ちなので規格上ダメなはず)どうやっているのか不思議.まさかMPLのsequenceに持たせているんじゃ(どうやって?).あるいはsizeofハックで固有整数に対応させているのか(これならまだ分かる.自分でも出来そう).IDLの裏で識別用のタグをこっそり定義しているのかも.それに加えてこの名前(識別子)を表現する型とクラスを引数にとって,対応するメンバのoffsetを取得しているっぽいメタ関数も発見.( ゜∀゜)アハハ八八ノヽノヽノヽノ \ / \/ \.もはやintrospectionとかいう次元の話じゃねぇ・・・.

-----
   http://www.kangaroologic.com/interfaces/

(For fun, click on "Online Documentation" and then on the Boost logo.)

くそ,飲み物吹いたやないけw.

-----

http://article.gmane.org/gmane.comp.lib.boost.devel/116863
うひょひょ〜,鼻血物のスレッドが大量にいぃ〜.

-----

"ABC"っつーアクロニムがしょっちゅう出てきて一体何のことかと思ったけれど,"Abstrct Base Class"の略か.

[Boost][Interface]Boost.InterfaceによるApplication Binary Interface (ABI)互換性制御

http://article.gmane.org/gmane.comp.lib.boost.devel/116907

Most importantly, I wanted full control of the ABI.

実装覗いてみて,どうやってApplication Binary Interface (ABI)を制御しようとしているのか調べてみたり.
(っていうか最初これの実装覗いたときは本気でめまいがしたw.Lambda, MPL, Spiritあたりの実装なら何とか読もうという気になれたけれど,これの実装は最初一見しただけで本気で読むの断念しようかと思ったw.ちなみに全然関係ないけれどMPLはpreprocessedファイルがあるので実は読みやすかったり)
とりあえず,一般にC++でABI互換性を崩す可能性のある項目を以下に挙げてinterfaceではどうなるかを考察してみた.

  • Object Layout

interfaceはPOD-struct*1なのでC++のobject layoutの問題というよりはCにおけるstruct layoutの問題に問題の領域が狭まる.なので考慮すべきABIの問題はアラインメントと各メンバのサイズのみ.しかしDavid Abrahams氏のcomp.std.c++のポストにあるテクニック(http://groups-beta.google.com/group/comp.std.c++/msg/85af30a61bf677e4)を基調としているのならばinterfaceが保持しているメンバはオブジェクトへのポインタとvtblへのポインタ(vptr)の2つのみからなる(これを"fat pointer"と呼んでいる)のでアラインメントに関してはほぼ無問題のはず.ポインタのサイズが非コンパチな可能性があるはずだけれど,これはどうするんだろうか?ライブラリのコンパイル時にヘッダにコンパイル時のポインタサイズを書き込んで,static assertionかけるとか?ってかみなさんはこれどうやってるんだろう?ソース中にポインタのサイズを強制的に大きくする類のコードがあったけれどこれも関係してる可能性が高いにゃあ.

  • Virtual Functions

仮想関数周りのABIは標準では全く規定されていないので普通はこれがバイナリ互換性のネックになる.しかしinterfaceは仮想関数を全く用いていないので,仮想関数周りのABI互換性には全く左右されない.超(゜д゜)ウマー.

  • Calling Conventions & Mangling

"full control"って書いてあるからCリンケージ + 手動マングリングぐらいのことはやってるんだろうと思ったけれど,そこまではやってないっぽい.てかそこまでは出来ないのかな?それだとメンバ関数呼べないだろうし.
#あとでよくよく考えてみればあんま関係なかった.
manglingの問題は問題にならないというか,ライブラリ側からクライアントのクラスのメンバ関数を関数ポインタ経由で呼ぶんだから関係ないはず.非常に楽な手間で,C++のクラスでかつ動的多相性付きちぅのが超(゜д゜)ウマー.あまつさえクライアントのクラスが特定の基底クラスを継承する必要なし,と.
唯一,メンバ関数のcalling conventionがthiscallで統一されているのかどうかだけが今手元の資料だけでは確認できない.統一されてましたっけ?
こうやって考察してみるとABI互換性の文脈におけるinterfaceの役割は素晴らしいですにゃ.てか,むちゃくちゃアピールポイントじゃないけ?こういうことは詳細かつ積極的にアピールして欲しいぞなもし.
#デストラクタが正しくコールされるかどうかという疑問に思い至ったけれど,そのためにスマポとスマートリファレンスが強調されるわけか.で,「スマートリファレンスだと所有権の所在がコード上で明示できない」 -> 「move semanticsを明示する何かが要る」 -> 「moveの実装がある」のかにゃ?
#ってことはあれですな.interfaceをやりとりするCリンケージ関数を書けばほぼ完全なバイナリ互換性で(゜д゜)ウマー,バリバリモジュール書けて至る先はここ・・・とか?(ちゃんと文脈知らないからなんか全然見当違いなこと言ってるかも)

[Boost][Range]char * const &に対してboost::begin/endが適用できない

http://thread.gmane.org/gmane.comp.lib.boost.devel/116960
結局これただ単に抜けてただけだったのねん.

[Boost][SmartPointers]boost::shared_ptrは重いっ!!

という意見.
http://thread.gmane.org/gmane.comp.lib.boost.devel/116983
っていうか,これしょっちゅう聞くなぁ.自分の場合,これに対する回答の方は理解は出来るものの納得は出来ないんだよなぁ.policy_ptrのデフォルトとして提供するという立場ならすごい納得するんだけれど.でも,標準化する以上はシンプルでないといけないんだろうなぁ.でも余分なテンプレート引数があっても良いと思うんだけどな.そういうのが欲しい人はpolicy_ptr使うか自分で実装しなさいってことなんだろうな.
将来的にはtemplate template引数はメタ関数クラスに置き換わる(と個人的には思っている)ので,余計なテンプレート引数がtemplate templateで検出されるという問題は,もはや重要ではなくなると思っているんだけれどどうなんだろうか?まぁ,標準ライブラリ(の少なくとも既存のクラステンプレート)はこの点に関しては遅きに失してしまっているのでどうしようもないけれど.
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#94
これに関する実例として,例えばHPのSTLの実装では存在したdequeのノード毎の要素数を決定するパラメータが標準C++STLにはなかったり.
ユーザ定義の特殊化も影響を受ける可能性があるって書いてあるけれど,これはどういう状況なんだろうか?

-----

これに関して,ポリシーをメタ関数クラスで指定するスマポの提案をcomp.std.c++で見た覚えが・・・と思ったら見つけた.
http://tinyurl.com/4kjj7

This was especially important when support for template template arguments was flaky across a large number of compilers. Even though support is decidedly better, it turns out that metafunction classes are more flexible anyway (for instance, they are polymorphic w.r.t. template arity), and the next version of MPL allegedly has built-in meta-lambda, which means that it should also be possible to pass in lambda-ized templates as well, without me having to modify the policy adaptor.

#・・・って今読み返してみて気が付いたけれど,n1681ってメタ関数クラスを鎖状継承しようって提案しているのかw.MIによるbloatを嫌ってるのかな?

[Boost][TypeTraits]Type Traitsライブラリに変更が

http://thread.gmane.org/gmane.comp.lib.boost.devel/117026

  • 新規追加
    • has_virtual_destructor - っていうかどうやって実装するのかが非常に気になるw*2
    • is_member_object_pointer - メンバ関数ポインタかどうかのテストはあったのでそれに合わせる形かな
    • is_signed - 今まで無かったのが不思議
    • is_unsigned - 同上
    • rank - ランクって何? int -> 0, int -> 1, int[] -> 2な感じ?
    • remove_all_extents - int -> intとかかな?
  • 名前変更
    • remove_bounds -> remove_extent
    • is_base_and_derived -> is_base_of
    • is_float -> is_floating_point

[Boost]CVSからsubversionへ乗り換え?

http://thread.gmane.org/gmane.comp.lib.boost.devel/116994
Boostのリポジトリ管理をsubversionへ乗り換えませんか?という流れになってる.

[Boost]アトミックなカウンタクラス

<boost/detail/atomic_count.hpp>とゆー便利なヘッダ(・∀・)ハケーン.マルチプラットフォームな(実装を切り分けた)アトミックカウンタ(スレッドセーフなカウンタ)の実装です.アトミックな参照カウンタの重要性は"More Exceptional C++"で取り上げられてましたな.
ちなみに自分はマルチスレッドプログラミングに関しては全くのど素人です.わっはっは.ソースのコメント読んで初めてRead Memory Barrier (RMB)っつー概念があることを知ったり.スレッドプログラミングの入門書的な本を何か読んでみようかなぁ・・・.

[Boost][MPL]MPLで中置記法演算子

http://thread.gmane.org/gmane.comp.lib.boost.devel/117077
お,来た来た.個人的にMPL + typeofで中置記法演算子っつーのをすっごく見たかったのだ.
http://thread.gmane.org/gmane.comp.lib.boost.devel/77267
一瞬「おっ!?」と思ったけれど・・・マクロかぁ.マクロなぁ・・・.

[Boost]1.33 (1.32.2)

http://thread.gmane.org/gmane.comp.lib.boost.devel/117049
次って確かserializationの共有ライブラリ化が入る予定なんだっけか.さすがにあのサイズのライブラリがstatic libraryのみっちぅのはつらいからにゃあ.
やっぱBoostのテストコードってBoost.Testに依存したの多いのか.テストコードはあんまし覗いたことがないから知らなかった.

[Boost][Range]iterationできるrange

http://thread.gmane.org/gmane.comp.lib.boost.devel/117153
影響を受けているのかどうかは分からないけれど,John Torjo氏のIterable Rangeと同じコンセプトですな.
http://www.torjo.com/rangelib/
便利なのは分かるけれど個人的にはイマイチ好きになれないかも.

-----

http://article.gmane.org/gmane.comp.lib.boost.devel/117378

Furthermore, can do all the same things with free functions that don't intrude on the purity of the range "concept". If you really like these idioms,

  using namespace range_operators;

could be enough to make them available.

うひょーっ!!この指摘には流石にシビレた.やっぱりっていうかなんていうか・・・スゲエとしか言いようがない.要するに以下のようにしろってことですな.

namespace range_operators{

range &operator++(range &)
{
  .....
}

}

range r;

// rangeに対するsyntax sugarを導入
using namespace range_operators;

for(; ++r;){
  .....
}

クラスに対する侵入的なコンセプトを最小限に限りつつ,syntax sugarへの対応も出来る.すげえすげえ!!これでこそ汎用プログラミングっ!!これぞ自由関数の威力っ!!ですな.言われればどうってことないテクニックなんだけれど.
っていうか,これ早速参考にさせてもらいますわ,すわすわ!!

-----

こういうのを見ているとやっぱり最近のBoostなどのコミュニティでは「侵入的なメソッド定義を最小限に,それ以外の(他のメソッドで実装できる)メソッドは自由関数として外部で定義する」という流れが強いように思える.例としてはstd::basic_stringとかか.これは侵入的なメソッド定義が肥大化しすぎていて,標準委員会のchairにすら"Monoliths Unstrung"なんて皮肉られている(?)ぐらいだし.そして実際この流れからBoost.StringAlgorithmsなんかが出てきたんだろうし.

[Boost]BOOST_ASSERT

http://thread.gmane.org/gmane.comp.lib.boost.devel/117155
BOOST_ASSERTっつー要するにassertマクロがあるんですがドキュメントが孤立しているのであんま知られていない.
http://www.boost.org/libs/utility/assert.html
標準のassertのon/offと独立している(こちらはNDEBUGでon/off)のと,翻訳単位でassertion時の挙動が変えられるのが(゜д゜)ウマーってところかな?
てか自分はなぜかすでに使っていたというw.

[Boost]なんでgraph_traitsが必要なのか

http://thread.gmane.org/gmane.comp.lib.boost.devel/117190
そのためのtraitsだしにゃ.まぁ,少なくともBoost.Graphで定義されているグラフクラスはgraph_traitsが提供しているのと同じ内部型を持っている(というかgraph_traitsのデフォルトの定義はそれらを取るようになっている)ので,それだけに限定するなら楽できるんですけどね.逆に言うとgraph_traitsと同じ内部型を定義したグラフクラスを作ればそれだけでgraph_traitsを特殊化することなくgraph_traits,ひいてはグラフアルゴリズムに対応可能になるわけで.

[Boost]ロゴコンテスト

http://boost.org/more/logo_contest.htm
むちゃくちゃ楽しげですなw.

[Boost]schemeっぽい,というかscheme

http://thread.gmane.org/gmane.comp.lib.boost.devel/117172

For instance where in Scheme you might write a factorial function as:

 (define factorial
   (lambda (n)
     (if (zero? n)
         1
         (* n (fact (- n 1))))))

In Unimperative you could write it as:

   Function Factorial =
     (If,
       (Eq, _1, 0),
       1,
       (Mult, _1, (Eval, self, (Dec, _1))));

あぁそうか.確かにこうすりゃschemeと同じ書き方が出来るなっ!素晴らしいぞ,この変態!!('A`)
#昔空白をオーバーロードできるようにするという議論をどこかで読んだ覚えがある(D&Eだったっけか?Stroustrap本人が言ってたハズ)けど,もしそれがあったら・・・(((( ;゜Д゜)))ガクガクブルブル

[Boost]Associative Vector

http://thread.gmane.org/gmane.comp.lib.boost.devel/117149
Associative Vectorっていつの間に"ready to review"になってたんだろ?っていうかどこにあるんだ?File Section?後で探しとこっと.
Associative Vectorと従来のset/mapとの間のトレードオフとなる項目は

  • 空間効率
  • 挿入・削除速度
  • 検索速度
  • 列挙(iteration)速度

あたりかにゃ?よく勘違いされる(というか自分も勘違いしていたんだけれど)のは,ほとんどの場合検索速度はset/mapの方に軍配が上がるってところかな?
http://www.tietew.jp/cppll/archive/5647
後,あんま気にされないマイナーなトレードオフ項目として要素に対するiterationの速度がありますな.マイナーっつても実際これがネックでAssociative Vector自分で組んだ,という経験あったけど.

-----

Singletonも実装がすでに"ready to review"なのか.ちぅか「しんぐるトン」どころか「まるちトン」なる議論やってるぐらいだからなぁw.
http://thread.gmane.org/gmane.comp.lib.boost.devel/116772

[Boost][Interface]

http://article.gmane.org/gmane.comp.lib.boost.devel/117173
Boost.Namesと後いろんなintrospection系のハック組み合わせたら線形継承タプル使ってマクロ使わずTMPの範囲内でInterface書けるのでは?とふと思ってみたり・・・思っただけですよ?
ちゃんと自由関数への委譲もサポートしてるんですな.まぁしてて当たり前なのかも知れないけど.

http://article.gmane.org/gmane.comp.lib.boost.devel/117383
あのえげつないマクロに何度か泣かされた記憶がw.インクルードしたらそのマクロ群が導入されたりとかするし・・・.

[TR1]alined_storage

TR1にalined_storageってあるんですな.uninitializedな空間確保用ですな.てか,uninitializedな空間のアラインメントの問題ってこれ(とalignment_of)使うだけで解決する?

[Boost]プロファイリングライブラリ

http://thread.gmane.org/gmane.comp.lib.boost.devel/117379
キタ━━━━(Д゜(○=(゜∀゜)=○)Д゜)━━━━━!!!!最近プロファイリング至上主義な自分にとっては切望のライブラリ!!

*1:簡単にいうとPODのメンバのみからなる構造体のこと.ただしPODの定義に注意.特に「PODでない型へのポインタ型」はPODであることとメンバへのポインタはPODになる(ISO/IEC 14882:1998では違うがISO/IEC 14882:2003で修正された)ことに注意が必要

*2:ちなみにboost::is_abstractは非標準ながら抽象クラスの配列を生成しようとする際のSFINAEを利用している