コンセプトを使ったRangeライブラリの提案。イテレーターのペアを扱うよりも、Rangeという単位で簡単に扱うことができる。ユーザーにわかりやすい恩恵としては、algorithmにイテレーターのペアではなくコンテナーを渡せるようになる。使う際にはコンセプトを意識する必要はない。Extensionsvector<bool>のようなプロクシーイテレーターをRangeに対応させるためにRange提案を修正する提案。既存のiter_swapに加えて、iter_moveを追加して、プロクシーイテレーターのためのカスタマイゼーションポイントとする。コンセプトにマップがあればもっと楽になるのに。TSを、標準規格に取り入れるべきだという提案。TSの実装経験は豊富であり、C++17に加えるに足る。TSは、たとえば、以下のようにvector<int>の各要素に処理を加えるコードがある。;}このコードは、以下のように変更を加えるだけで、並列実行させることができる。...このように、既存のalgorithmに並列実行版のオーバーロードを加える。並列計算用のnumericが用意されている。TSを公に実装している。valueがmin_valueより小さいならmin_valueを、max_valueより大きいならmax_valueを、そうでなければvalueを返す。comp)も追加される。forはコンテナーの各要素に対する処理を簡単に書くことができる。;}しかし、現実では、複数のコンテナーのそれぞれの各要素を先頭から同時にアクセスしたいことがよくある。いう場合、古典的なforループを使わざるを得ない。forを拡張して、セミコロンで区切ることで、複数のRangeを受け取れるようにする。}レンジの要素の数が同じではない場合、要素数が少ないレンジの終端に達した時点でループが打ち切られる。Types名前付きの型を作り出す機能の提案。typedef名は、型に別名をつけることができる。}問題は、typedef名はあくまで別名であって、新しい型ではない。そのため、double型を渡すことができる。;}これを解決して、論理的に間違っている場合にコンパイルエラーを出すためには、新しい型を作り出す必要がある。;提案では、何らかの新しいキーワード(仮にnewtype)を使って新しい型名を宣言する文法を提案している。具体的な文面案がないので、どのようになるかは詳しく書かれていない。少なくとも、暗黙の型変換は阻害されて欲しいし、テンプレート実引数で異なる特殊化をされてほしい。提案は先行事例としてAdaを挙げている。int(0...130)のような案も漏らしている。attributesattributeは、アノテーションを記述するのに便利なので、すでによく使われている。Applicationsでは、attributeを使って、GPUやDSPに処理をオフロードするアノテーションを記述できる。問題は、inとかoutとかの短くてわかりやすい単語を使いたいが、他の実装依存のattributeとかぶるとまずいため、attribute名前空間を用いている。これは記述を煩雑にする。do_task();}そこで、同一のattribute内であるattribute名前空間内のattributeトークンをグローバルスコープに持ち込むための機能を提案している。Hashingunorderedコンテナーのキーは、ハッシュ値を計算できる必要がある。基本型と標準ライブラリの型はstd::hashでハッシュ値が計算できる。ユーザーがハッシュ計算可能な型を組み合わせたクラスを作った場合、標準ライブラリはそのような型にハッシュ値を計算させる簡単な方法を提供していない。ユーザーが独自の方法でハッシュ値を計算しなければならない。ハッシュ値の計算は素人には難しい。そこで、既存のハッシュ計算可能な型のオブジェクトを任意個ぶち込めばハッシュを計算してくれるライブラリhash_valueとhash_combineを提案している。}このようにすれば、Foo型はstd::hashでハッシュ計算ができるようになり、unorderdコンテナーのキーとして使うことができるようになる。ドワンゴ広告この記事はドワンゴ勤務中に書かれた。ドワンゴは本物のC++プログラマーを募集しています。said...レンジ関係がちょっと面白そうですね。ユーザーがカスタムの範囲を記述できるように内容的仕様も明示してほしいかな。それと、地味にNewTypeが気になってます。ユーザー定義リテラルと合わせることで現実にあるメトリクスの相関関係を記述できるようになるんじゃないかって期待です。何らかのいいところに落ちてほしいですね。クランプが地味に議論続いてますね。仕様に入ったもんだと思ってましたがまだやってましたか。現在の引数列は割と好みです。パラレリズム関係は、さっさと標準の記述方法を確立してほしいですかね。ミューテックスやロック関係と合わせてうまく落としてほしいです。イデオンなどの環境でスレッド立てるの大変なのでもうちょっと簡単になってほしい。スレッドを立てつつさらにレンジで区切って区間をSIMDで処理とかも普通にあると思うのでそれらが簡単に立てれればいいですね。メトリクスの相関関係そのソリューションは非現実的ですね。65kg;これでいろんな変換がすんでしまいます。本来必要とされる数学や科学方面に強くなると思いますし、プログラムになじみのない研究者程便利になると思うのですが、なぜ非現実的に至ったのか自分には詠むことができませんでした。said...単位ごとに全部別の型にして演算子を全部オーバーロードするつもりなんですか?少しは頭を使いましょうよ。said...そんな馬鹿な話ですかねぇ。現実的にそれだけの単位が存在するからリアルを記述したい欲求なんですが。一回書けばメンテを除いて得られる恩恵は大きいと思いますがねぇ。単位とはつまり型とほとんど同義だと思いますよ。said...小学校の算数の宿題ならそれでもいいかもしれませんね。boost.unitsとか調べてみましょうや。違うかあなたに分かるでしょうか。自分で丸出しって分からないようじゃ不安ですけど。said...狭いですねぇ。そんなに躍起になって可能性をつぶすのが流行りなんですか?数学や物理はもっと一般的になるべきなんです。簡単になるべきなんです。ないとエンターテインメントは死んでしまいます。そのためのツールキットとしてのnewtypeに期待したかったのですが。話が通じないですねぇ。必要な人が必要な変換を書いて収集できればいいなー程度に思っています。ちなみにバカは美徳ですよ。賢者は頭で考えて手を出さない。それでは世界は開発できない。said...だってあなた実際手を動かしてないじゃないですかw((基本の型の数+1)×単位の数)!×演算子の数のオーバーロードが必要なんですけど、あなた、ちょっとでも考えました?複素数やら多倍長実数やら、新しい型も増える。一個追加するたびにオーバーロードは幾何級数的に増えていく。何年も前にみんなが捨てた可能性なんです。あなた、boostにある先行事例すら見つけられなかったでしょう。あなたはバカの名にすら値しないようですね。自白をありがとうございます。said...2つ上の人は話にならないですね。手の抜き方を知らないようだ。型の数全部網羅して何に使うんですか。基本的にdoubleや多倍長精度実数があれば必要十分でしょう。型の数は4つもあれば実用上の問題はほとんどないでしょう。それと定義されていない演算も無数にあるのでその数は正しくない。必要な人が必要な変換を書く。一回書けば受けられる恩恵は大きいと。非正規な演算については普通にstatic_castすればいいの級数的な数にはならないはずです。この人、何と戦ってるのかよくわからないです。said...NewTypeは是非とも実現して欲しいですね。アプリケーションハンガリアンでやろうとしていたことがコンパイラに任せられるので。said...>基本的にdoubleや多倍長精度実数があれば必要十分それが罷り通るなら、C++にも、doubleと多倍長精度実数があれば必要十分という事になりませんか?そして「必要な人が必要な変換を書く」で済ませられる話なら、標準ライブラリに入れなくていいんです、必要な人が書いてライブラリ公開すればいいんですから。「必要な人が必要な変換を書かなくて済む」ようにあるのが標準ライブラリでしょう。この辺、ユーザー定義リテラルの合成機能があれば楽なんですけどねぇ......。ll)」が定義される、みたいな。f);」......が定義できそうで便利。(Atom)C++11参考書C++11の参考書、アマゾンお気に入りリストを公開中。アマゾンの江添のほしい物リストC++11の参考書、C++の文法と機能をGitHubで公開中。EvangelistC++標準化委員会の委員ドワンゴ社員C++11本を執筆した。株式会社ドワンゴで働いている。江添のほしい物リスト筆者にブログのネタを提供するために、直接に品物を送りたい場合、住所をメールで質問してください。Texts.ただし、必要である範囲において他の著作物を引用していることがあります。