今日のBoost

Testing interest for a shared memory/STL library proposal

http://lists.boost.org/MailArchives/boost/msg74410.php
(boost.devel 2004/11/09~)
スレッドセーフなSTL実装?
#2004/12/18訂正:メモリにマップされたストレージを扱うライブラリです.

Library TR draft available

http://lists.boost.org/MailArchives/boost/msg74424.php
(boost.devel 2004/11/09~)
ドラフト落ちてこね〜.大きさだけ見たらpdfで1.5Mもあるし.

There may be editorial (non-substantiative) changes to the final version of the TR document, but this latest draft is believed to be final in terms of technical content. Thus it should be safe for implementors or users to write code based on this latest draft.

と言ってるから読む価値はあるんだろう.知らんけど.
(´-`).。oO(pdf落とすためにいるびねさんのお世話になってるっつーのはどうなんだろうか・・・)

iterator adaptors and const correctness

http://lists.boost.org/MailArchives/boost/msg74469.php
(boost.devel 2004/11/10~)
昔自分も色々ひっかかったことあるな.ちなみに1.32.0からはiterator_adaptor/iterator_facade使うときにあの長ったらしい親クラスのtypedefをする必要がなくなってたり.

License use for non-Boost projects

http://lists.boost.org/MailArchives/boost/msg74487.php
(boost.devel 2004/11/10~)
よ〜し,パパも自作ライブラリにこの著作権表示使っちゃうぞぉ〜,っと.

start preparing the final tarballs

http://lists.boost.org/MailArchives/boost/msg74504.php
(boost.devel 2004/11/11)
どうも向こうの世界での2時間はこちらの世界での24時間(以上)に相当するようだ.ま,気長に気長に.

Named parameters library

http://lists.boost.org/MailArchives/boost/msg74555.php
(boost.devel 2004/11/12~)
キタワ*・゜゜・*:.。..。.:*・゜(n‘∀‘)η゜・*:.。. .。.:*・゜゜・*!!!!
ここら辺のGP/TMPによるトリッキーな実装だと思って以前コード覗いてみたことがあるけれど,実際にはどちらかといえばマクロで力押しな感じ(あくまで「どちらかといえば」).とはいえ,相変わらず演算子オーバーロードを駆使したインターフェースやlazy evaluation, デフォルトテンプレート引数のシミュレートなど相も変わらず圧倒的に変態なんだけれどw.-> id:Cryolite:20040823#p2
旧来から関数の名前付き引数のシミュレーションとして,this*を返すメンバ関数を持った専用のクラスを用意してピリオドでつなげていくやつ(参考:http://www.tietew.jp/cppll/archive/11289)が有名で,Boost周辺でもあっちこっちで見かける.けれど,やっぱC++だから関数の引数はコンマで区切りたいよねっていう.
named_paramsは実装者側がどれだけ楽して書けるかが見所かな?(<実はまだまともに使ったこと無い)

problem in BLL

http://lists.boost.org/MailArchives/boost/msg74479.php
う〜ん.これ変えるってことはsigテンプレートの定義が変わるんだよなぁ.かなり大きな変更になるなぁ.もちろん,type deductionにtuple使うのは冗長すぎるのでさっさと純粋なtype sequenceに置き換えて欲しいのは山々なんだけど.

Boost.Filesystem - 標準化に向けての大きな変更点

http://lists.boost.org/MailArchives/boost/msg74503.php
お,来た来た.ついにI18Nに乗り出すのか.1.32.0でも結構大きく変わったけれど,まだまだ足りないものは多いしにゃあ.

Boost.Rangeあれこれ

iterator pair v.s. range

http://lists.boost.org/MailArchives/boost/msg74340.php
(boost.devel 2004/11/09~)
これ以下の議論が面白いなぁ.普通の感覚で言ったらどっちもどっちなんだけれど.個人的にはどっちの書き方にも慣れているし好きだから良いんだけれど,どちらかといえばrangeな書き方のほうがコード量的に小さいはずなのでそっちかなぁ?

range, container level or iterator level?

http://lists.boost.org/MailArchives/boost/msg74461.php
実はContainer Conceptには一見マイナーな,しかし非常に重要な要求がある.「要素の所有権を保持していなければならない」というヤツだ.従ってコンテナがその範囲を伸ばす・縮めるというのは,それすなわち要素の所有権の放棄・獲得に直結する.
一方,Range Conceptにはこのコンテナにおけるような要素の所有権の制約がないので,いわゆる"view"としてのsementicsを持つことが可能になる.このsemanticsはこれはこれで非常に有益で,rangeが提供する重要な側面の一つだ.もちろんこのsemanticsを持つということは,逆に指しているオブジェクトのlifetimeを考慮しなければいけなくなるわけだけど.
この所有権における差異は,例えばtokenizeを考えてみれば分かる.毎回毎回tokenをコピーして文字列で返すのと,tokenの範囲を示すiteratorのペアを返すのとでは決定的に効率が違ってくる.
具体例として,Boost.Tokenizerではtoken_iteratorというrangeっぽいsemanticsを持ったview(正確に言うと複数のrangeをtraverseするiterator)を定義して使っている.Boost1.32.0から入るBoost.StringAlgoでは,さらにRange Conceptを前面に押し出していて,これらをrangeを受けるアルゴリズムに入れることで文字列のコピーを必要な段階にまで遅延しながら様々な操作が簡単に行えるようになるだろう.・・・知らんけど.<ヲイ
こういう背景からも,今後rangeの活躍の場所は広まると考えられる.