C++0x、国際標準として承認される 26
ストーリー by hylom
そのパワーをフル活用できる人はどれだけいるのだろう…… 部門より
そのパワーをフル活用できる人はどれだけいるのだろう…… 部門より
あるAnonymous Coward 曰く、
長きにわたって議論されていたC++の次期標準規格、通称「C++0x」が、ついに国際標準規格として承認されたそうだ（Faith and Brave — C++で遊ぼう、Herb Sutter氏のブログ）。
この規格は「200X年には承認される」という見込みで「C++0x」と呼ばれていたが、結局2000年代には承認が完了しなかった（そのため、のちに0xは16進数だということになった）。今回の承認により、今後この新規格は「C++11」と呼ばれることになるだろう。
喉元過ぎたので (スコア:3, 興味深い)
また末尾2桁使う。
そして2111へ…
# さすがにそんな先にC++はない、というか自分も生きてないのでどうでもいい
Re:喉元過ぎたので (スコア:1, おもしろおかしい)
Re: (スコア:0)
Re: (スコア:0)
Re:喉元過ぎたので (スコア:1)
来年承認すればC++Cという回文になったのに。
＃あとは16年おきに同じことを言っていればいいんですよ
Re:Ã¥ÂÂå ÂéÂÂãÂÂãÂÂã®ã§ (スコア:0)
I love reading these articles beacsue they're short but informative.
「C++11」 (スコア:2, おもしろおかしい)
Re: (スコア:0)
何が問題だったの？ (スコア:0)
Re:何が問題だったの？ (スコア:5, 参考になる)
ここに承認遅延に関する大まかな流れが書かれてます。
http://japan.internet.com/column/developer/20100806/26.html?rss [internet.com]
コンセプト削除に伴う修正が理由の１つに挙げられています。
ボリュームかな？ (スコア:1, 興味深い)
期日に拘って納得いかない仕様を盛り込んだり、不足したりするのを潔しとしなかったことかな？
Fortran も 6x は 66 になり、7x は 77 になり、野心的な仕様の 8x は 90 になりました。
その後は 95, 2000, 2003, 2008 と続いていますね。
Re:ボリュームかな？ (スコア:1, 興味深い)
これだけ揉めた巨大仕様に基づいて現実の処理系を作ったら、混入するバグの数もハンパじゃないはずだろう？
（冗談じゃなく本気でそう思うぞ）
Re:ボリュームかな？ (スコア:2, 興味深い)
それはLISPなどのプログラミング言語ではなくて形式手法の領域だと思います。VDM++であればコード生成までできるので考え方としてはありな気がしますが、VDM++で言語仕様を表現できるかはちょっとわかりません。
言語処理系に限らず一般的なシステムでも形式手法を使えば数桁バグの数が減るとは思うのですが、如何せん難しいのでなかなか一般的なところではお目にかかれませんね。組込方面では比較的よく利用されているらしいのですが。
Re:ボリュームかな？ (スコア:2, 興味深い)
モデレートされたのでついでに追記。
プログラミング言語で仕様を表現するのと形式手法で仕様を表現するのとで(仮に両方とも実現できたとして)一番の違いは、仕様の矛盾を検証できるかという点です。
通常のプログラミング言語では書かれた内容に矛盾があるかはわかりません。書かれたとおりに動くだけで、その書かれた内容がプログラム中の他の部分と矛盾があるかは判断できません。それに対して形式手法は、私の知っている限り仕様の矛盾などを検証器にかけることで自動的にあぶりだすことができます。形式手法からのコード生成は基本的にはおまけと考えていいでしょう。
また、当たり前のことですがプログラミング言語と形式手法で使われる言語では抽象度が違います。とはいっても、コード生成ができるようなVDM++などはかなりプログラム言語に近い感じを受けますが。
Eiffelは言語仕様としてDbCを取り入れていますが、ほんのさわりだけですがEiffel・VDM++両方を見た感じではとても似ていました。Eiffelの作者であるBertrand Meyer氏は元々形式手法を研究していたそうなので、その点でも影響はあるのかなと思います。
Re:ボリュームかな？ (スコア:1, 興味深い)
自然言語で仕様を記述するのが難しい訳ではなく、仕様を練るのに掛かった時間なので関係ないと思いますよ。
仕様上未定義な部分が無いかとか、矛盾しないかとか･･･
リファレンス実装を基にすれば未定義はなくせますが、そうするとバグの検証が必要になり、バグの検証には仕様の検討が必要になり、結局元に戻ります。
Re: (スコア:0)
＞仕様上未定義な部分が無いかとか、矛盾しないかとか･･･
ソース記述そのものを定義とすれば、少なくとも矛盾は無くなります．
＞リファレンス実装を基にすれば未定義はなくせますが、そうするとバグの検証が必要になり、バグの検証には仕様の検討が必要になり、結局元に戻ります。
ソース記述そのものを定義とすれば、バグの検証など不要です． 他の方法で記述した仕様を
Re: (スコア:0)
それだと仕様上の矛盾や予期できない挙動が定義になるだけだー
それは矛盾や予期できない挙動であってバグではないっていわれても使いにくいのには変わらない
javascriptみたいに仕様決まってるけど実装されてない（コンパイラならまだしも、エンジンがわの実装状況がまちまちで結局使えないとかより）とかよりずっとましだけどさ
Re:ボリュームかな？ (スコア:1)
よくある「バグではありません. 仕様です」ってのが確定的になるだけですね.
Re: (スコア:0)
私の知り合いと同じ事を言ってますね。
彼は、仕様書を書くのが面倒くさいから先にプログラムを作ってくれと仰っていました。
Re: (スコア:0)
次は8ですね！
全会一致で承認 (スコア:0)
なんでC++0bじゃないの？ (スコア:0)
T/O
永遠の十代 (スコア:0)
0x1F歳までは十代として認める派としてはぜひとも0bにしてほしいもんですな。
Re: (スコア:0)
0b「説明しよう！」
人差し指立ててるように見えるからじゃね？
周知徹底が不足しているようなので (スコア:0)
Re: (スコア:0)