並列処理の観点からすればイテレータの形で提供すること自体なんだか微妙で、hashmap.for_each([](int key, int value){ });みたいに、各要素に対する操作をラムダ式で書かせる形が良いんじゃないかと勝手に思ってますがメソッドチェーンどうしよう。
2011-03-09 01:45:57@pepshiso それの多段化でrangeと同様の事を提供できるんでしょうか range使い倒してないのでありがたみがよくわからないのです。
2011-03-09 01:49:07@pepshiso あ、for_each()の戻り値が更にfor_each可能な何かの列挙な型になればいけそうな気がしてきました!ってそれはrangeそのものや…!
2011-03-09 01:55:15@pepshiso 書き方としてはそれに近くなると嬉しいですが、その書き方が簡潔さ以外にどこが嬉しいのか知りません。データ構造としては外部にイテレータを持たせない構造の方が取り回しやすいのですが、begin(),end()抜きでそれにどこまで近づくと合格なのか測りかねてます。
2011-03-09 02:02:41@kumagi イテレータを外に出せなくなると、一部の要素だけ操作するのが面倒になると思います。半分の要素だけとか、1個飛ばしに関数を作用させるのにはイテレータがあると便利です。添字で高速にアクセス出来れば問題ありませんが、常に出来るとは限りません。
2011-03-09 02:13:50@pepshiso 一部の要素にアクセス、という事自体が大変に高価な要求であって、データのアクセス順がad-hocになるほどにデータ構造側のロック管理が面倒な事になるのです。
2011-03-09 02:21:02@pepshiso 例えば一個置きアクセスならint i=0; [&](key& k){if(++i & 1) {return;} else { t.pushback(k); } }のようなラムダな記述でどうにか出来ます。並行データ構造側からできる最大限の譲歩なんじゃないかと。
2011-03-09 02:22:34concurrentHashmapだとiteratorを返すのは簡単でも受け手にiteratorが渡った瞬間にもうその参照先の寿命は保証出来ないので、iteratorを外部に渡すんじゃなくて、処理を内部に渡してくれれば処理結果の集合を吐き出して返しますよ、という
2011-03-09 01:58:11この実装方法でいいなら、key集合を得るなんて動作もstd::vector<key> t; hashmap.for_each([&](const key& k, value& v){t.push_back(k);})でユーザに書かせれて素敵!MessagePackもできる!
2011-03-09 02:05:42まあインターフェースをC++風にするという意味でBoost.Range風のfor_eachとかをオーバーロードするといいのではないでしょうか。
2011-03-09 02:30:27まぁイテレータを外に出したくない気持ちは分かるなぁ。メソッドチェーンというより関数オブジェクトの合成演算子があれば良いような気がしてきた
2011-03-09 02:19:16@kumagi @pepshiso 例えば、GPUのメモリを舐めるイテレータがあった時に、RandomAccessを許してしまうと、割と残念な実装をしないといけない…。とかもありえます。
2011-03-09 02:23:34@fjnli データレベルの並列性がある物に対して無理に順序関係を記述出来るようにする事自体、使い道が無い上に中身が残念になりがちでしょうねぃ。並行データ構造も「自分だけの所有物じゃないんだ」っていう意識で触ってほしいものです。
2011-03-09 02:27:53@kumagi ここからここまでの要素に関数fを適用と書ける方がいいかもですね。もはやイテレータですらないですが。というか、無理してまでイテレータ(のインターフェイス)に拘る必要はないと思います。
2011-03-09 02:30:13@fjnli ここからここまで、ってのを指定させる為にはやはりkeyに順序関係を定義する必要があったりするんでしょうか。あ、filterもデータ構造側に持たせればいいんですかね?
2011-03-09 02:36:29