C++0x 5

The C++ Standards Committee
http://www.open-std.org/jtc1/sc22/wg21/

wikipedia
http://ja.wikipedia.org/wiki/C%2B%2B0x

C++0x
http://pc11.2ch.net/test/read.cgi/tech/1149440647/
C++0x 2
http://pc11.2ch.net/test/read.cgi/tech/1191842951/
C++0x 3
http://pc11.2ch.net/test/read.cgi/tech/1204808027/
C++0x 4
http://pc11.2ch.net/test/read.cgi/tech/1214407525/

　　　　　　　　　 　 　　　　　　　　　　　　　　　　rへ ＿＿　 __
　　　　　　　　　 　 くヽ　　l^ i　　　　　　　　　／: : : : : : : : Y: :ヽ
　 ┏┓　 ┏━━┓＼＼l　 l.　　　　　　　／: :.／ l: :.lヽ: : :ヽ: : :ヽ.　　　　　 　 　 ┏┓┏┓┏┓
┏┛┗┓┃┏┓┃　 ＼＼.l　　　　　　 //: :/ノ　 l: :ト､ヽ: : :',: : :. ',　　　 　 　 　 ┃┃┃┃┃┃
┗┓┏┛┃┗┛┃┏━ ＼＼━━━/ l: :/ ○　丶l ○ l: : :ﾊ: : : :',━━━━┓┃┃┃┃┃┃
┏┛┗┓┃┏┓┃┃　　　 ＼＼. ＿/: :l: :l＠┌‐┐ ＠ l: :/: :l: : : :.',.　　　　　┃┃┃┃┃┃┃
┗┓┏┛┗┛┃┃┗━━━ ＼/:::::::＼ヽl.＼ | 　 !　　 /:/／ l: : : :..ｉ ━━━┛┗┛┗┛┗┛
　 ┃┃ 　　 　 ┃┃ 　 　 　　 　 {:::::::::::::::::`Ｔ７└‐┴‐＜　　　 ｌ: : : :. ｌ　　　　　　┏┓┏┓┏┓
　 ┗┛ 　　 　 ┗┛ 　 　 　 　 　 `r──‐┼-/l／l／/ 01i,　　l: : : : : l.　　　　　 ┗┛┗┛┗┛
　　　　　　　　　　　　　　　　　　　 /: : : : : : | /:/: l: : : :Y:::::::l　　l: : : : : :.l
　　　　　　　　　　　　　　　　　　　,': : : : : :.／ /: /: : : : l:::::::::l.　 l: : : : : : l
　　　　　　　　　　　　　　 　 　 　 i: : : : : く／レへ: : : : l::::::::::',.　!: : : : : : l
　　　　　　　　 　 　 　 　 　 　 　 l: : : : : : :＼:::::::::::ヽ イ:::::::::::::〉l: : : : : : : l
　　　　　　　　　　　　　　　　　　 l: : : : : : : : :ト､:::::::::::::::>ｔｊｔｊｔｊﾉ l: : : : : : : :l
　　　　　　　　　　　　　　　　　　 ',: : : : : : : :/├‐┤|─ '"|　　 l: : : : : : : :l
　　　　　　　　　　　　　　　　　　　ヽ: : : : ／　.l:::::::| l:::::::::::l　　 ',: : : : : : :,'
　　　　　　　　　　　　　　　　　　　　 ＼:/　 　 l:::::::l |::::::::::l　　　ヽ:: : : : /

janeの隠し機能

１．書き込みウィンドウを出し半角入力に切り替える
２．Wキーを押しっぱなしにする
３．Wキを押しっぱなしにしながらsageのチェックするところをおもむろにクリック

mailing 2008
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/

最新ドラフト
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf

Status of Experimental C++0x Support in GCC 4.3
http://gcc.gnu.org/gcc-4.3/cxx0x_status.html
ConceptGCC
http://www.generic-programming.org/software/ConceptGCC/

Boost
http://www.boost.org

試してないけど、スレに書き込みされるんかな
いつもAlt+Wで書き込んでるんでたまに普通のブラウザ使うと一瞬戸惑う

/　　　//　　　/　　　//　　　 ______　　　　　/　　　//　　　/
　/　// 　 /| 　 r'7＼　,.ﾍ‐'"´iヾ､／＼ﾆ''ｰ- ､.,　　 /　　　　/
　　/ 　 ／　|　 |::|ｧ'⌒',ヽ:::ヽrﾍ_,,.!-‐-'､二7-ｧ'´|､__
`'ｰ-‐''"　　 ヽ､_'´　　`|　|:::::|'"　　　　　　　二.,_> ,.へ_
　　　　　　　　 /　 ／/__/／　/ ／　／　 　　 　`ヽ7::/
　か　っ　も　 |　 ／　/／　メ,/_,,. /./　/| 　 i　　　Y　　　//
　ァ　 て　う.　 |'´/ ∠. -‐'ｧ'"´'`iヽ./／ ﾒ､,_ﾊ　 ,　 |〉
　 |　 約　ク　 ヽ! Ｏ .|/。〈ﾊ､　rﾘ　'´ 　 ,ｧ=;､`| ,ﾊ　|､　　/
　 |　 束　ソ　　　>　　o　 ゜,,´￣　　　. 　ﾄ i 〉.ﾚ'i　iヽ|ヽ､.,____
　 | 　し　 ス　　/　　 ハ |　u 　 ,.--- ､ 　`' ゜o Ｏ/､.,___,,..-‐'"´
　 |　 た　 レ　 |　　/ 　ハ, 　 /　　　　〉　"从　 ヽ!　　/
　 |　 じ　 は 　|,.イ,.!-‐'-'､,ﾍ. !､_ 　 _,/　,.ｲﾍ. `　　ヽ.
　ッ　.ゃ　.立 　 |／　　　　 ヽ!7＞ｒｧ''7´|　/　',　 〉`ヽ〉
　! !　な 　て　　 .',　　　　　　`Y_,/､レ'ﾍ/ﾚ'　　ﾚ'
　　　い 　.な　 　 ヽ､_　　　　　!:::::ﾊiヽ.　　　//　　 /
　　　で 　 い　　　.／‐r'､.,_,.イ＼/_」ヽ ', 　　　　　 /　 /
　　　す　 　　　　/　　　 `/:::::::/　/,」:::iﾝ､ /　　　 /
　　　　 　　　　 〈　 ,,..-‐''"´￣￣77ｰ--､_＼.,__　　/
　　　　　　,.:'⌒ヽ ´ 　 　　　　　 | |　 , i |ﾉ　　 `ヾr-､

なんと失敬な！
スレがクソな訳じゃない。クソなのは（以下閲覧済み

閲覧済みって何だよ
とセルフ突っ込み。

俺は閲覧したね！

conceptの前に閲覧が来る！
これは乙じゃないんだからね！

【あたらしいきのう】

・こんせぷと！
　テンプレートひきすうをせいげんするぞ！
　constのつけわすれでエラーメッセージが1000ぎょうもでなくなる！
　でもむずかしすぎてだれもじっそうできてないよ！　

・らむだしき！
　みんながまってたインラインかんすうオブジェクト！
　STLがすっごくべんりになるよ！
　でもこうぶんがすっごくグロいよ！

・うへんちさんしょう！
　いちじオブジェクトをさすためのさんしょうだ！
　いらないおぶじぇくとをぶっこわしてポインタをごうだつする！
　それがむーぶせまんてぃくす！かこいい！

エラーメッセージは置いとくとして0xから現行C++への変換は簡単にできそうだな。

concept_map使ったコードは無理だろ。

　　　　　　　／/
　　　　　／　 /　　　ﾊﾟｶｯ
　　　　 //⌒)∩＿＿∩
　　　　/.|　.| ノ　　　　　ヽ
　　　 /　|　| 　●　　　● | 　　　　
　　　/ 　|　彡　　( _●_)　ミ 　まピョーん☆
　　 /　　|　ヽ　　|∪|　　/＿
　　/／　│　　　ヽノ　　＼／
　　"￣￣￣￣￣￣￣（..ノ

　 , ._., ...
　‘^^’

>>13
ラッパークラスを仕込むようにすれば何とか

C++0xってC++のマクロなんでしょ？
C++ってCのマクロなんでしょ？
Cってアセンブリのマクロなんでしょ？
アセンブリって機械語のマクロなんでしょ？
機械語って演算回路のマクロなんでしょ？
演算回路って電子の移動のマクロなんでしょ？
電子の移動ってクォークの作用のマクロなんでしょ？
クォークの作用って量子論のマクロなんでしょ？

＞演算回路って電子の移動のマクロなんでしょ？
ここから先が全然違う

ごめんね

電子はレプトンだろw

演算回路ー論理回路ーNANDゲート-電子回路

wwwwwwwwwwwwwwwwwwwwwwwww

>>19でごめんねって出てるだろ。赦してやれよ。それともこんなジャンキーな書き込みすら無視できないほどお前らは小さい人間なのか？
まぁ俺が>>19だけどね。

>>23
許す

かどうかは金しだい。

>>17
> クォークの作用って量子論のマクロなんでしょ？
これはちゃわんか？

それ以前に全部違う

＞C++ってCのマクロなんでしょ？
こんな超越的マクロが有るんだったらほしいかもな

まっくろクロ助は何のマクロですか？

どっちかっていうとミクロ。

thisポインタをスマートポインタにする機能が欲しいよな！

>>31
enable_shared_from_thisで我慢してください。

一番根元にクラスしこむのは自作でもやったことあるんだが
いまいちスマートじゃないんだよなぁ。

C++0xってフランケンシュタインみたいだよね

もうCOBOLを笑えないよ

なぜ？

型理論的にも最先端なんだが
COBOLと違って

Lisp最強でいいよ^^

>>37
そんなの現場は望んでない。
最先端で効率が下がったらいみねーよ

>>39
つ COBOL

理論のおかげで効率はよくなってる。

ことさら「理論」を敬遠するのは日本「現場」の悪い傾向だよな。

×最先端
○最末端

多分、頭数だけたくさん用意しといて
人月で積算するときの「効率」だろ。

だからJava or C#最強なんですね

>>41
ソースは？
ソース出せよ！

だから、Java or C# が普及してるだろ。

JavaもC#も実用している現場見たこと無いな。
研究用のおもちゃとしてなら使うこともあるけど。

おまえ、ケータイもみたことないのかよ。

Javaってあのfinallyとかいう劣化デストラクタを毎回毎回手で書いてる間抜けな言語？

いいえ。あれは劣化デストラクタですらない、Cでfreeをきちんと書くのと同じこと。
C#のusingこそ（いい意味で）劣化デストラクタと呼べる存在だ。後発だけあってJavaより賢い。

Cで言えばgotoでエラー処理ルーチンに飛ばすようなもの

いや例えないでいいから

>>47
最近、サーバーサイドの案件はほとんどJavaかC#よ。
Windows Server 使えるならC# 1択。

あと、社内ツールとかには .NET 使ってる人多い。
お客様にランタイムインストールしてもらわなきゃとか気にしなくていいし。

>>50
usingがいいのはわかる。
でも、インデントつかブロックが深くなって
しまうーところがかなりイヤ。

やっぱりC++の真デストラクタこそが最強！

D の scope キーワード最強だろ。

>>47
脳内の現場や脳内の研究の話をされても…

>>56
一方的に脳内認定されてもな。

速度とメモリ効率考えると、実用するコードは
fortran,C,C++くらいしか選びようが無い分野も
多いとおもうんだけど。少なくとも自分の周りは
何処いっても同じようなもの。

普通に書いたCやC++とほぼ同等レベルの
速度で動けば十分な用途だとjavaやC#でもいいんだろうけど、
この辺で目指しているのは最終手段として
インラインアセンブラでベクトル化することもあるからな。

>>55
Dってだけでよわい。

>>57
＞自分の周りは 何処いっても同じようなもの。
もっと見聞を広めたほうがいい。

でなければ、黙って脳内認定を受け入れろ。

>>57
実行速度とメモリ効率だけならFORTRAN以外の選択肢は無いな…
C/C++含めて、FORTRAN以外が選択されることがあるのは、それだけが言語の選択基準じゃないってことだと思うんだが

でも最近はC++も見直されつつあると思う

>>60
Pascal

JAVAが実用じゃないといってる時点でもアウトだろ。

でもJavaは嫌い

つーかcontrol invocation syntaxがC++にも欲しい。
Javaより先に入れちゃえと言いたいところだけど、
もう閉じちゃったから10年後なんだよな orz

>>47だけみて誤解されているようだけど、別にJavaやC#が
実用的でないといっている訳ではないよ。

C++使えない、0xなんて現場で必要とされていないみたいな流れで、
逆にJavaやC#を使っていない・適用しづらい分野もあると
表明したかっただけ。

>>66
「分野による」って話だと、
.NET やら Java VM 移植されてない環境だってあるわけだし、
組み込みだと未だCだし、
>>47 みたいな書き方するまでもなく、自明な話なんだが。

>>65
いらん。
これ以上、デブにしてどうするよ？

デブに穴欄よ

語れるほど経験を積んでないのに無理するから

GCC 4.3.3 の tr1 見たらもうバリバリ Variadic Template 使ってんのな

それがどうしたハゲ。

誰がハゲだと！？もう一度言ってみろ！！

>>73
0x対応の第4版早く書けハゲ

そんなに褒めてやるなよ。

メタプログラミング厨が喜びそうな機能を真っ先に入れるあたりはやっぱりGCC

ハゲがデブい言語を御所望ですね。
臭くね？

>>53
> お客様にランタイムインストールしてもらわなきゃとか気にしなくていいし。
なぜかVBのランタイムなら入れてやってもいいという客が多い。

どうも、「.netはカスだ」と言い張った営業マンの戦略に乗せられている例も多いらしい。
要は、その営業マンの所属するソフト屋が新しい技術についていけないだけなんだけどね。
その所為か、某官庁のシステムは未だにVB6が使われていたり。

vbに比べたら.netの方がマシだな。作る側としては。
使う側としては.netの方がランタイムが大きい分、抵抗ありそう。

色々思うところはあるがスレ違いはそろそろ・・・

あぶねえ。
.netランタイムは複数バージョンを同居させないといけないのが気に食わない
と書いてしまうところだった。
サンクス>>81

VBに比べたらC++/CLIのほうがましだといいたいんですね、わかります。

C++/CLIは割と良くできてると思うんだ

^ とか勘弁して欲しい

__gc*よりはましだぜ。

C++/CLI 使った事無いんだけど

Hoge^ hoge;
Hoge^* phoge = &hoge;
Hoge^*& rphoge = phoge;

って可能なの？

できるけど、そのままだと安全じゃないよ

広義の弱い参照になるって話？
まあ、ダングリングポインタ自体は元々危険だから
改めて気にすることは無いと思うけど。

C++/CLI使ってるやついないだろ。川俣もC#に戻ったし。

MSオンリーでなければ手を出すんだがな。
プロパティーとか、属性とかMS臭いすぎる仕様が気に食わん。

プロパティはもともとデルファイのものでは。
属性は Java にも Annotation 付いたし。
MSはほんと後だしじゃんけんでいい物作るよ。

C#はもともとMSがDelphiの開発者を引き抜いてきて作ったものだからな

MSに引き抜かれた技術は全部「MS臭い」といわれるんですね。
分かります。

ウンコなすりつけられた奴が全員ウンコ臭いのは事実

MSの属性は元を辿ればMIDLだろう。
その後、いつだか忘れたけど、ATL属性プログラミングといって、MIDLの属性の構文をVC++に持ち込んだ。
その構文がマネージドC++やC++/CLIにも引き継がれて今に至る。

F#やIronPythonやIronRubyがあるからOCamlやPythonやRubyもMS臭いのですね

>>66
最初から誤解される書き方しかできない知能しか持ち合わせていないカスが、プログラミング言語を語るとは・・・
コンピューターの前に座ってばっかりじゃなくて、たまには人間と会話した方がいいぞ

で、0ｘの次の標準の主なネタは何？

まず念願のGCだな
あと多重ディスパッチとかyieldとか
メタコンセプトもどうせ作るんだろうな
あとは何だ

標準ライブラリの完全なconcept化

tr2てのはC++0xの次って事でいいの？

ThreadとかNetworkとかDatetimeとかFilesystemとか
実用的なのが多いね

正直、これ以上 C++ を高機能化しても仕方が無いと思う。
C++ は構文解析と意味解析が複雑に入り組んでいる事で悪名高いから、
これらが完全に分離された言語に一旦整理し直した、別言語を作るべき。
あくまで C++ と機能的には変わりのない範囲で。

それは他の人／団体／企業がやってるよ。

意味はあるだろ
C++を使ってる俺が嬉しい

コンパイラ作る側がひぃひぃ言って
サポートが遅れてもあんまり意味が無いからなあ

>>103
何そのD言語

MS付きのC++/CLIでさえあの体たらくだというのに…

D言語もGCあるからなあ・・・
常に scope を使えばいいのかもしれないが、なんだかな・・・

>>109
D言語でもGCを止めて、C++のように書くことはできる。

スコープにとらわれないタイミングで delete できるの？

>>111
普通にC++のようにdeleteすればいい。

delete できるのか。
いいね、それ。

C++はそろそろコンストラクタとデストラクタの前と後に呼び出される処理をデフォルトで追加するべきだな。
ファクトリー関数とかだるすぎる。

スマートポインタをコンストラクタ内で作れなくてもいいから、コンストラクトが終わった後になんか呼び出してくれ。

>>114
before-daemon, after-daemonｷﾀｰ!

コントラクトとかアスペクトとか、
そういうのは入らんのか。
テンプレートにちょっといろいろ
たすだけでできそうだが。

その辺研究した上でconceptに昇華された。
AspectJ, Eiffel, ML, Haskell辺りの型システムを、
型の専門家が研究した成果を取り入れてる。

さあ！みんなDゲンガーになろう！

>>117
conceptはtraitのちょっとした拡張くらいに
思ってたけど、違うんだ？
# 詳しくはまだ見てないんす。orz

何かの言語で、処理（関数）の前後とかに
別途定義する処理を定型的にねじ込む
機能を見たとき、すげぇ超うらやましい！
と思ったんだけど、あれが使えるのかな。

C++って、もともとCのソースをつくるだけだったんだぜ。

例外で破綻したけどな

>>103
C++の構文解析って、今はすべて手書きらしいね
こういうことがC++の将来に悪い影響を与えそうな気がする
構文を書き換える時期に来ているのかもしれない

たしかに、C++は複雑だからという理由も大いにあるだろうけど、
ほかの綺麗な言語でも高速な解析を目指せば自ずと自前で解析するだろうし、
何より今更そんな気にすることか？と思う。

確か、IronPythonとかも手書きって話だったと。

使わない仕様とか、勝手にエゴで古いコードの書き方を意味もなく変えたり。
バカだなぁと思う。

特にifとカッコの間にスペース開ける奴。
騙されてるよなぁー、と思う。

なぜ？

>>126
カッコまでが言語仕様だから。
カッコなしで通るなら、スペースを開けるのが正しいと思う。

いやお前の文章の意味が分からん。
「騙されてる」の主語は誰だよ？
「ifとカッコの間にスペース開ける奴」が「騙されてるよなぁー」だと思ったぞ。

>>128
スペース開けてる奴は、騙されてるよ。

恥ずかしい言語仕様を隠すためだけに、権威筋が言い始めたのを真に受けて従ってるわけだろ？
騙されてなけりゃ、単なるバカ。

自分の口からだだ漏れ状態の上から目線に興奮冷めやらぬのはわかったけど、
もうちょっと具体的に説明しないとただの電波さんｗ

どう見てもただの基地外さんだろ。 文章の意味が全く通っていない。

いやぁ、どう説明しても只の電波だろ。片や「騙されてる」と言いながら、片や「正しいと思う」だし。

その辺はスルーして、
C++の構文解析は自然言語構文解析並みwと書いた人が以前いたが、
(g++のMLだったか?)
最近手でパーザを書くのが結構流行っているのは、
エラー処理をきちんとやりたいから。

g++のパーザはすごくわかりやすい。
gccのパーザはbisonの出力したCコードから派生しているけど、
これも以外にもすごくわかりやすい。
v8(Javascript)の手書きパーザもすごく綺麗。

>>134
理屈はわかるが、いざ自分がそのパーサを書く係になったらと思うとぞっとするな。

エラー処理、得にエラー表示は、UIに属することだからね。
GUIで、入力足りないと、ダイアログウィンドウ出して、
入力してないフィールドを赤く表示して入力を促し、
側に警告も表示するっての似て、手間ばかり多いね。

ちなみにg++のパーザは2万行w (gccは8千行)
C++で書けばいいのに…
conceptg++のパーザは+1400行ですね。

// というかgcc本家のconcept branch放置されてる…

手で書かなくてもエラー処理をまともにする方法はある気はするんだけどなぁ
parser combinatorとか使ってコード量を10分の1ぐらいにできないのかなぁ

>>125
あなたはreturnにカッコを付ける人ですね
分かります

相談室もだが、今日は変なやつがいるな
もしかして同じ人？

>>137
簡単なんでいいから一回パーサーを
書いてみろ。
気のきいたエラー処理がどれだけ
めんどくさいものか体感するべき。

>>139
最近あちこちで電波垂れ流してる脳内住人が出没してる。
ここのスレにも、見てわかるとおり。多分同一人物だろうな。

パーサのエラー処理は地獄だよ

エラー1つ検出して終わりなら大分楽だが
今時そんなコンパイラじゃ誰も使ってくれないだろう。

むしろコンパイル速度さえ爆速であればエラーを一つ検出して終わりというコンパイラもアリだと思う。

this -> m_Hoge = 10;

これでも通るんだし別にいいんじゃね。

>>144
連鎖的にエラーが出る事が多いから、
結局最初の１つくらいしか見ないとか多いしな。
そこ直したらもっかいコンパイルした方がエラーが見やすいし。

権威にはからきし弱い、太鼓持ち。

じゃあ柔軟なエラー処理ができ、かつ簡潔で速度もそこそこ出るパーザの実装手法を考案して有名になってやる

期待してるよ

このスレで宣言するからにはC++0xのパーザも。

しかし改めて思うがひっでー文法だな
特にdeclarationまわり

varとかtypeとかfunctionとかのキーワードがないのに合わせて、
typedefが止めを刺した感じ。
classやtemplateやcoceptはキーワード付けてくれて本当に良かったよ。

>>152
何かで見たけど、キーワードはできるだけ
追加しないってのがポリシーなんだよね。

>>138
わかってないな。
省略できるから、つけようがつけまいが自由なんだぞ。
単にあのかっこも、一時期のバグ回避だし。

どうでもいいことで盛り上がるなこのスレ

馬鹿が必死になるから挑発しないでくれ

というか、どうでもいいことだから盛り上がる

ごめんなさい…

>>154
へー、そんな理由がねぇ。
おいらてっきり、void return(x);的な関数に見せかけたいが為に
やってんだと思ってた。あんま関係ないけど
int(main)(int(argc),char**(argv))なんて所にも括弧付けれるね。
まぁ、当方returnですらカッコ付けたことは無いから付ける輩の気持ちは解らんけど。

return って、20年以上前の大昔には実際に関数だったとかじゃなかったっけ？
ANSI 以前の。

大昔の良書（今となっては歴史的資料）がANSI以前の文法で書かれてたりするせいで、
それが正しい書式だと思ってる人が絶えなかった。

未だにflex/bisonみたいな古いツールの解説では旧形式の関数定義があったりするな。

>>160
＞return って、20年以上前の大昔には実際に関数だったとかじゃなかったっけ？
それはない。exit()の実装と勘違いしていないか?

>>160
このレスは全て間違い。以下無視するように。

C FAQを当たってみたけど、
ttp://www.kouno.jp/home/c_faq/c20.html#0
> 20.19:
> returnの後ろに来る式をくくるカッコは本当に省略可能か。
> A:
> 省略可能だ。
> 大昔、Cの初期には、必要であった。そのころにCを学んだ人がたくさんいるし、
> そのころ書かれたコードが今でも世の中に出まわっている。 それでカッコが
> 今でも必要であるという考えが広まっている。
ということで、昔は必要だった(が関数ではない)ってのが正しいようだ。

ifとかwhileが関数ではないけど括弧が要るってのと同じことだったんだと思う。

統一性を考えたらカッコが必要なままでもよかった気がする。
つか、不要にするならするで if や while もカッコ不要にして統一しろよ。

>>166
ifやwhileは括弧があっても、タイプミスをするとコンパイル時に検出できるが、
returnに括弧があるとそうはいかない。

>>166
retrun() でハマるというネタが

>>166
つーか
統一するという言葉自体に惹かれても意味ないし
第一、統一する理由がない

括弧無しでも文法としては作れるよね？
そうしろっていってるんじゃなくて、ふとした疑問で

return-statement := return EXP
と定義すれば既に統一されてるじゃん
空白や(は識別子に含めないからそこで打ち切られてreturnが認識され、
以降の式が続けて認識される

>>166
break continue sizeof系統だからある意味統一されてるだろ。

>>172
sizeofちと違う

>>170
ついでにifなどにぶら下がる文を複文限定にして、中括弧必須にしてくれればいいのにと思う。

P e r l 化 決 定

#define begin {
#define end }

>>176
嘘のような、本当の話。

昔々のはなしじゃねーか。
つーか、ゴテゴテ強化してJAVAより遅くなってたら笑える。

>>176
STL コンテナと一緒に使えますか？

#defineはコンパイル以前に発現するのでSTLと一緒には使えません。

えー

#define private public

#define privata public

#define mein main
#define retrun return
#define cahr char

#define itn int
#define sohrt short
#define unsgied unsigned
#define long lgon
#define vodi void
#define defien define
#define incldue include
#define thrwo throw

#define unsinged unsigned がないのはおかしい

^t

結局、単なるデブ言語か。
テンプレートでarray使うと、C#より遅くなるんだからたまらん。

>>188
え〜。コンパイル時に最適化掛けてないとかそんな話じゃないよね？

「テンプレートで」とか、馬鹿に決まってるから相手にするな。

すいませんでした。いや、数年前に、
知り合いで大学院で C++ でシミュレーションをしていた奴が、
遅くて困るんだよね... といってたから最適化オプションはどうしてる？と聞いたら
何もしらなくて、調べてみるとなんとデバッグオプションつきで
inline 展開も無しだったという恐ろしい話があったのでね...

188はコンパイルが遅いって話かと思った

遅いなら速くすればいいじゃない

コンパイルが遅いならDをｔ（ｒｙ

,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww

いやいや、三次元配列だとすで使っても遅いぞ。

mailing2009来てるじゃん

スレッドのバグが山のように報告されてて吹いた

constexpr の再帰が復帰してるっぽ。

停止判定できないのはテンプレートも同じだからな

結局コンパイラ側で制限かけるんじゃね？

そういう問題じゃない。

final class に相当するものは導入されてんの？
const class とかでキーワード導入しなくても大丈夫そうな気がするんだけど。

されてない

意見すら出なかったのだろうか

0x はそういう小手先の便利さとかとは掛け離れた大きいものを狙っている気がする。

小手先の便利さはライブラリやコーディングテクで補うのが禿と愉快な仲間たちの趣味です。

あるあるw

>>202
[[final]]っていうオーバーライド禁止属性が入る

class hoge [[final]] ってのは入る事になったの？
virtual member function にたいしてだけ？

N2800では入ってる
効果はクラスの全仮想関数に[[final]]を付けるのと同じ

>>210
継承禁止ならともかく仮想関数オーバーラード禁止してどうするの？
virtual付けなきゃ良いだけじゃない。

豚脂の摂り過ぎは禁止じゃないけど控えた方がいいだろうな。

>>211
> virtual付けなきゃ良いだけじゃない。
（　ﾟдﾟ）ﾎﾟｶｰﾝ

>>211
俺に言われても困るが、virtual付き関数のオーバーライドさえ封じておけば
基底クラスの機能を派生側で変更できなくなるんだから十分だろう

virtualにしないという手は、基底クラスから受け継いだ仮想関数がある場合には使えない
クラス付き[[final]]はそういうのにも効いてくれるから意味がある

>>214
やっぱりそういう事なんだ。成るほどね。
>>202に「final classに相当するもの」って書いてあったから、
Javaと同系統の機能なのかと混乱したよ。

Java の final メソッドと同じだな

どうせクラスと関数でセマンティクスが変わるのが嫌だったんだろうけど
やっぱりキッパリと「派生クラス作ったらアウト」にして欲しかったな

仮想デストラクタ作らないと派生禁止にできないのは本末転倒な気がする

デフォルトがアーリーバインディングのC++で
final が必要なケースのほとんどは悪い設計の尻拭いでしょ

そんなことより早く仕様Fixして欲しいよ

安全性より速度側に倒すC++だからこそ
finalが必要なんだろう。

統一関数構文周りがここへ来てまた愉快なことになってるからな
今年中には無理だな

統一関数構文とかって、英語話者なら前から読んでわかりやすいかもしらんが
日本語だとあんまり C のとかわらなくね？
function of int i and int j which returns array of pointers to function of int i
とかそのままになる？んだろうけど日本語の語順とは全然ちがうよね。

まあ戻り値を引数列の後ろに置きたいための変更で
読みやすさのためじゃないからな

しっかし既存の宣言に無理矢理押し込むためにこれ→[]を型扱いしようとしたり
この期に及んで関数とラムダを完全統合しようと派手に文法いじくり回したり
迷走がひどい

てかC++使いに自然言語的可読性気にする奴いるのかね？
最早ここまで崩れたら英語圏だろうどこの人間でも
気にする気にもならんと思うんだが。

統一関数構文は別言語でやってくれって感じだ。
C++にいれるには無理がある。

最初に思い切ってfuncdefでも予約語にすると決定すれば良かったんだ

いや、あれは必要だ。
とくにdecltypeがあるC++0xにとっては。

shared_ptrが付いたのはいいけど、やっぱり演算子にならないといまいち使えないよなー。構文長くなりすぎだし。
[*]とか何か導入できなかったのかな。バカだなー。

最大の問題はstd::shared_ptrがboost::shared_ptrと同じように使えるとは限らないこと
dynamic deleterが要件に入ってないとか何なの？死ぬの？

そんなあほな

>>224
入れないほうが無理があるよw
俺はあのスタイルは好きじゃないけれど、
なんか入れないと>>226の言う通りで破綻する。

C++って何がしたいの？

>>228
どこ読んでそう思ったの？
n2800 見たけど、 get_deleter() とかあるし、 template 引数には静的な deleter 型は無いよ。
これなら deleter については boost::shared_ptr と同じでしょ。

>>226
関数の戻り値の型は前置しても
以降の部分を考慮できるようにはできないんだろうか。

デブが集うスレ。

時間が経ってみるとこの構文も悪くない気がして来た
[] func(int arg) -> void {}

いい具合に洗脳されてきてますね

何を今更。C++0x最高！

>>232
コンストラクタで明示的に指定するdeleterの話じゃないぞ
boost::shared_ptr<Base> p(new Derived);
が（~Base()が仮想じゃなくても）デストラクタで~Derived()を呼んでくれるのがdynamic deleterだけど

N2800のtemplate<class Y> explicit shared_ptr(Y* p);の説明をよく読んでくれ

4 Requires: p shall be convertible to T*. Y shall be a complete type. The expression delete p shall
be well formed, shall have well defined behavior, and shall not throw exceptions.
5 Effects: Constructs a shared_ptr object that owns the pointer p.
6 Postconditions: use_count() == 1 && get() == p.

ポインタpを所有したshared_ptrを作るとは書いてあるが、Y*として所有するとは書いてない
pはT*に変換できなければならないし、事後条件で出てくるget()の戻り値型はT*だし
T*として所有する実装は十分にありうる

そして~shared_ptr()の説明には（deleterを指定していなければ）所有するポインタpに対して
delete p;を呼ぶとしか書いてない
つまり、Y*を持ってるshared_ptrならdelete (Y*)p;を呼んで欲しい（そしてboostはそうなってる）のに、
stdの方はdelete (T*)p;を呼びやがる可能性がある（そして破滅が待ってる）

というわけで、shared_ptr<Base> p(new Derived);の解体に~Base()を呼び
shared_ptr<void>は使い物にならずpimplに使うと鼻から悪魔を呼ぶ「標準準拠」のshared_ptrがありうるわけだ
恐ろしい話だと思わないか

Y* として delete pとなるようにすべきである、
というように書いてあるような気がするんだけど。


仮にそこが保障されなかったとしてもdeleterを指定できるんだから、
ファクトリ関数ひとつ書くだけですべてうまくいくような気がするんだけど。

>>231
とにかく最強を目指す
ただし何が最強かは重要ではない

>Constructs a shared_ptr object that owns the pointer p.
「このポインタpを所有するshared_ptrオブジェクト」とあるから T*では
条件を満たさないんじゃね？

>>239
どこに書いてる？
コンストラクタの説明ではdelete pがwell formed/well defined behaviorじゃなきゃダメだとは書いてるけど
デストラクタの説明には「そのdelete p」を呼ぶとは書いてない（pの真の型については何も触れてない）
それにget()の説明を見ると「stored pointer」はT*であるというようにも見える
Y*で持ってY*で解体しろと強制してる箇所は見あたらないと思うんだけどなぁ

deleter指定すればどうにかなるってのは関係ない話
boost::shared_ptrはそんなものなくても上手くいってるんだから

>>241
そこがハッキリしないんだよなぁ
「ポインタ」がアドレス値の情報だけなら別の型のポインタで持ったっていい訳だし
型も含めて全部保存しろとなると、今度はboostの方アウトになるような気がする
確か内部的にはvoid*で持ってるから

[] func(int arg) -> void {}
と
auto func(int arg) -> void {}

どちらが正式になりそう？

unified function syntaxが入るなら前者で、入らないなら後者なわけだが。
俺としては、後々のことも考えて、統一して欲しいところなんだが、（今回は規格に入らないlocal functionとかnamed lambdaなどを入れる際に簡単）
でもなー、実際に書かれたコードを読むと、後者のほうがぱっと見に分かりやすいんだよね。

あと一年時間があれば間違いなく[]が正式になっただろうけど、今の状況だと微妙だな
autoが意味持ちすぎだから[]の方がいいと思うけどね

いや、こんな調子じゃ、あと一年ぐらいじゃ規格制定までは無理だろ。
まだ数年かかるんじゃない？
x == 9にはならんだろう。

>>242
>Y*で持ってY*で解体しろと強制してる箇所

だから
Requires: p shall be convertible to T*. Y shall be a complete type. The expression delete p shall
be well formed, shall have well defined behavior, and shall not throw exceptions.
これでしょ？

デストラクタのところに書いてあるわけないじゃん。


>deleter指定すればどうにかなるってのは関係ない話
deleter指定したら確実にうまくいくんだから、関係無くはないだろ。
お前もギャーギャー騒ぐ必要がなくなる。

>>248
pがT*に変換できて、Yが完全型で、「delete p」の形式が適格で定義済みの振る舞いをして例外を投げない
としか書いてないように見えるんだけど、どこで「Y*で持ってY*で解体しろと強制してる」の？

それにdeleter指定するだけでいいとは言うけど、
boost::shared_ptrを使ってる所を全部探して適切なdeleter作って書き直すのと
ただboost::shared_ptrをstd::shared_ptrに置換するだけで済むのでは全然違うと思うんだがね

pimplで使うことを考えるとY==Tだとしても問題だしな

Yのデストラクタがvirtualでなければならないとはどこかに書いてあるのかな？
書いてなければ、delete p がwell formedになるためには、一体どうすればいいんだろうな。

>pがT*に変換できて、Yが完全型で、「delete p」の形式が適格で定義済みの振る舞いをして例外を投げない

delete p;の形式についてだけ適格で定義済みの振る舞いを要求していて、
delete (T*)p; の形式については適格で定義済みの振る舞いを要求していない以上、
実装がY*として解体するのはもう強制でしょ。

>deleter作って書き直す
いちいち個別にdeleter作る必要は無いけどね。

>ただboost::shared_ptrをstd::shared_ptrに置換するだけで済む
ちょっと頭使った置換じゃないと確かにうまくいかんかもなー。

Yが基底クラス持たなければ常に適格だな
それがどうした

Tがvoidのとき適格じゃないけど。

これの話だろ？
http://d.hatena.ne.jp/Cryolite/20060108

問題は保存してるポインタの型じゃなくて呼ばれるデストラクタがいつ決まるか
N2800には何も書いてない

書いてるって

素朴な疑問
1) どうしてここまでして C++ 使いたいんだ?
2) 型に厳格な関数型言語で十分じゃね?

とにかく最強を目指す
ただし何が最強かは重要ではない

>>257
スレ違いどころか板違いです。

>>256
だからどこに？

コンストラクタではdelete pがwell definedでもデストラクタでdelete pが未定義になりうるってのが
pimplでの問題なんだけど

>>260
Requires: p shall be convertible to T*. Y shall be a complete type. The expression delete p shall
be well formed, shall have well defined behavior, and shall not throw exceptions.

>>261
だからそれはコンストラクタでしょ
shared_ptrのコンストラクタではimplクラスの完全な定義が見えてなきゃならないから、
その位置ではdelete p;はwell definedになるけど、
外側のデストラクタが自動生成だった場合にimplクラスの定義が見えてなくて
shared_ptrのデストラクタが呼ぶdelete p;が未定義になりうるんだが、
それを禁じる要件はshared_ptrのデストラクタの説明には書いてない

わかる？

そういう仕様のアラを突き上げるのが去年の集まりだったんだよなあ。
今年もやるらしいから、そんとき誰かが言えば、委員会の人まで話が届くぞ。

>>262
デストラクタにdeleterを持つときは、d(p)となると書いてある。

ここでは明確に書かれていないが
template<class Y> explicit shared_ptr(Y* p);
は、Y*として解体するdeleterを設定しなければ仕様を満たせない。

template<class Y> explicit shared_ptr(Y* p);
の仕様に
The expression delete (T*)p shall
be well formed, shall have well defined behavior, and shall not throw exceptions.
という一文が無い限りは。

>>264
やっぱりわかってなかったのな

pimplの時の問題だと言ってるだろう
Y==Tの場合だ
shared_ptr<impl>をimpl*で作った時に呼ばれるimplのデストラクタの話をしてるんだぞ

>>265
いや、それでも同じ話ですけど。

適切なdeleterがなされなければ、仕様を満たさないでしょ

なくても満たしちゃうだろ、と言ってるんだけど
もう一度言うけどY==Tでの話だぞ

N2800で言う所のdeleterってのは
template<class Y, class D> shared_ptr(Y* p, D d);の形のコンストラクタで渡されるdのことであって
template<class Y> explicit shared_ptr(Y* p);は「deleterを所有」しない

結局pimplにshared_ptr使っていいの？

>>238
> template<class Y> explicit shared_ptr(Y* p);
> Effects: Constructs a shared_ptr object that owns the pointer p.

> ~shared_ptr();
> Effects:
（略）
> ? Otherwise, *this owns a pointer p, and delete p is called.

ここでイタリックになってる "owns" を厳密な用語として読めばつながる。

つまり
　int* p = new int;
　shared_ptr<void> x(p);
によって x は p を「所持」する。 (void*)p を「所持」するのではない。
このまま x のデストラクタが実行されるとき、 x は deleter を持たず
p を「所持」しているので、 delete p が実行される。何も問題ない。

そっちの話は終わってるだろ

問題はデストラクタテンプレートの実体化時点でpが不完全型ポインタになってる時に
「delete p」が未定義動作にならないような仕掛けが規格で強制されてるかどうか

>>233
できるよ。現にD言語ではそうなってるし。
単に実装面倒だからコンパイラベンダが反対してるだけでしょ。

Dだと、こんなふうにかける：
　typeof(T+U) add(T, U)(T t, U u) { return t + u; }

もっと簡単に
　auto add(T, U)(T t, U u) { return t + u; }
ともかけるけど。

>>271
そういうことか。

なるほど。今の記述だとはっきりしないね。

Effects の記述は boost のドキュメントと同じだけど、 boost のほうには
template<class Y> explicit shared_ptr(Y * p) について注釈が添えられている。
> The destructor will call delete with the same pointer, complete with its original type, even when T does not have a virtual destructor, or is void.

規格にもこれが必要（できればもっとはっきり強制する書き方で）ってことだね。
早めに DR 挙げてくれ。

>>272
実装が面倒っての、ここまですでに複雑な言語だと、結構な問題では。

あと、C# 使いとして言わせてもらうと、
T Add<T>(T x, T y) の最初の T でインテリセンスが利かないのはかなりのストレス。

×C#使い
○VisualStudio使い
◎MS迎合派

こんなデブで非実用的な言語なんか使えねー

まあC++使ってない携帯電話探す方が難しいけどな。

Embedded C++（笑）

Embedded C++0xを予想するスレ

とりあえずラムダは真っ先に消される
コンセプトはテンプレートがないんだから入るわけがないな
右辺値参照はどうかな、組み込みでこそ必要だと思うけど消しそうだなｗ

それ以前にEmbedded C++はフリースタンディング環境で
ライブラリがないから特殊用途以外は既に死んでる。
DarwinのI/O Kitですらnamespaceはありになってるし。

C++にはフリースタンディングの規格は元々あるけど、
Embeddedって日本独自の規格だっけ？
製品化されてる実装なんてあるの？

>>281
>Embeddedって日本独自の規格だっけ？
事実上日本独自規格
C++のまともな処理系が作れないから、作りやすい縮小規格を作ったってだけ

>製品化されてる実装なんてあるの？
GHS C++なんかはサポートしてるみたい

>>281
http://www.dinkumware.com/
> ・a full implementation of EC++, the widely used embedded subset of Standard C++
彼は"Embedded Systems Programming"にコラム書いていて、
よくコンサルもやってた。http://www.plauger.com/esp.html
メイヤーさんも組み込み屋相手によくレクチャーしてる。EC++はやってるかどうかしらんが。

使い物になるやつを頼む。
C#より早いやつを頼むよ。

コンパイル速度の速さなら一生かなわない自信がある。

EC++のほうがC++より幾分ましだよ。
言語オタクにはわからんだろうが。

とにかく必要なモノは実用品だ。

EC++のページ見に行ったけど、2002年で更新止まってるしURL削ったら会社潰れたとか書いてるし
もう死んでるようにしか見えないんだけどどうなの
どっかで亡霊みたいに生き延びてるの？

生き延びてたとしたら俺が殺しにいくかもしれない。

なんで日本のこういうジャンルはクソなもんばかりなんだろうな？
うまいこと行ったのはRubyぐらいか？
てか著名なソフトの作者は大体医者だったりする所が泣ける。

rubyも最近は面白くなさそうだけどな。

>>289
これが止め刺したから必要ない。
C++ - TR 18015
Technical Report on C++ Performance
http://www.open-std.org/jtc1/sc22/wg21/docs/18015.html
要約すると「フルセットのC++でもパフォーマンスに問題なんかねえよ、屑」

>>269
問題としては >>271,273 が残ってるだけなので、生成時に deleter として
std::default_delete<Y>() を渡しとけば現状のドラフトの記述でも動作保証はできる。
しかし激しくダルイな。

現実としては記述に不備があるだけで、未定義動作の可能性は本来の意図では
無いし実装としても boost のやつを持ってくれば問題ないはずだから、あんまり
心配しなくていいと思う。

>>292
わざわざそんなドキュメントを出されなくても
フツーに考えたら、C++がパフォーマンスで
劣るハズがないのに。
世間はバカなの？死ぬの？

ECは、パフォーマンス優先なのでrestrict
ポインタを実装必須にするとかなら、
一理あると思うし、覚悟もわかるんだけど。

>>292
てかEC++はパフォーマンスなんて謳ってたの？
速度なら、例外とnew deleteぐらい、容量なら
templateとinline関数とランタイム。実際には、
それぞれ自前で調整できるからまったく問題ないのは
バカでも解ると思うが。

利点しかない新形式キャストを全部消してるあたり（多分RTTIとdynamic_cast消す時に巻き添え食らったんだろう）
C++を理解してない奴らが作ってたのは明白

>>294
かわいそうな人。
バカじゃね？

現時点でもパフォーマンスにもんだいあんのによ。

>>293
でもちゃんと規定しておいてくれないとvectorの連続性保証みたいなことになるからな
はっきり書いてない要件はやっぱり信用できない
たとえ事実上全部の実装がそうなってたとしても

バカ専用にしょぼい言語つくろうって話なんだからｗ

同じ事ができるならシンプルな方が正しい。

百歩譲ってシンプルな事は認めても、同じ事(表現)はできないだろ

EC++は名前空間さえ残してれば単なるC++サブセットでほぼ済んだのに
なんでわざわざ互換性捨てちゃったんだろうな

いらないから。
やたら短い関数名つけて検索性下げるバカとか普通に多いから。

EC++のメリットがパフォーマンスとか言っちゃうやつらに何いってもね。

日本の企業が中心になって決めたから。

>>300
それは大きなカンチガイ。
このバカ。

シンプルだと言うにも視点はそれぞれだからね
短かく書ければシンプルであるというわけでもない

ああ、三項演算子がバグの元とかいうアレですね

いいかげんgccのコナピルまんどくせ

昔gccにあったSignatureいつか次期C++で復活しないかなぁ。
interfaceなんかより遥に便利そうなんだけど何で廃止されかなぁ。

>>303
逆にループ変数にわざわざcounterとかつけてたり、引数に関数名が入ってたりするアホも見たことがある

>ループ変数にわざわざcounter
いや、それは別にいいんでねーの。
最近はディスプレイの解像度も上がったし、MSのインテリセンスに代表されるように、
エディタには補完機能があって便利だし。
変数一覧でiとかcntなんて表示されるよりよほど分かりやすそうだ。

引数に関数名ってのがよくわからんが。
こういうのか？

void hoge( int hoges_first_argument, int hoges_second_argument ) ;

そんなん
ループ変数の方はアホはいい過ぎだったな

>>306
それはシンプルという言葉から、アインシュタイン言うところの
「単純化せよ。ただし単純化しすぎてもいけない」
の後者のケースばかり思い出すから出てくる反応で、
前者を完全スルーするお前の姿勢がカンチガイってオチじゃないの？

>>314
アインシュタインはプログラマーか？

つーか、シンプルとか言えたのはアインシュタインが最後だって知ってたか？
このバカ！

simplicityとかいった形で数値化できればいいのにな
でさらにある法則に沿って変形していったらsimplicityがmonotonically decreasingになっていってそれを使って機械的にコードを変形して云々

アインシュタインのその言葉を引用するには致命的なほど具体性にかけているな。

w

wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww

>>310
concept来たやん

クラス作る時にコンセプト使って
InputIterator my_iterator{/*...*/};
とかやって要件満たしてなかったらエラー出してくれるみたいな使い方ができればよかったのに

表記が違うだけで出来るやん

いや、そりゃやろうと思えばできるけどさ
こんな風になるのかな

class my_iterator{/*...*/};

template<InputIterator T> class InputIteratorChecker{};

static_assert(sizeof(InputIteratorChecker<my_iterator>));

めんどくさくね？

>>315
主旨だけシンプルに書きましょう。
わめいて逃げてるようにしか見えませんｗ

>>323
Only required,
> requires InputIterator

>>325
それでどうやって簡単に書くんだ？
requiresってテンプレートとコンセプトの中でしか使えないだろ

my_iteratorは、template<〜> iteratorとは無縁のクラス、
まったく別のsignatureってわけですか?
だったらconcept_map書くしかないですね。

めんどくさい誤解招いてるみたいだからInputIteratorやめる

auto concept HasFoo<class T>{
void foo();
};

があるときに

HasFoo Hoge{void foo(){}}; //OK
HasFoo Fuga{}; //NG

とかできたらいいなー、というのが>>321の趣旨

fooにT型の関与なしかあ。

auto concept HasFoo<>{
void foo();
};
template<> class Hoge {
void foo();
};
template<> concept_map HasFoo<Hoge> {
void foo() {}
};
〜 Hoge<> 〜

でいいのかなあ。

めんどくさいなぁ

やりたいことはただ自作クラスがHasFooコンセプト満たしてるかどうかチェックしたいだけだってのに
チェックするためだけにテンプレート化すんの？
馬鹿げてる

これでいいじゃん
template<> class Hoge {
void foo();
requires HasFoo<Hoge>;
};

auto concept HasFoo<typename T>{
void foo(T);
};
だと、
template<typename T> class Hoge {
requires HasFoo<T> void foo(T) {}
}
って書けるけど。
template<> class Hoge {
requires HasFoo<> void foo() {}
}
はいけるかどうかわからん。もう一回ドラフト読まんと。

間違えた。
class Hoge {
requires HasFoo<> void foo() {}
}
これは駄目だった。
>>331
ああそだね。

>>332
それ以前の問題として

HasFooは簡単なコンセプトだからいいけど
これがもし10個の型名と20個の関数を要求するコンセプトだったら
Hogeの型名と関数全部にそのrequires付けて回る気か？

>>323の方が楽だわ

直接こう書ければなんの問題もないのにな
class Hoge {
void foo();
requires HasFoo<Hoge>;
};

C++ってほんとに糞言語ですね☆

C++がwadlerとかにボロ糞に貶されるところを見てみたい

class Hoge : public HasFoo<Hoge> {
void foo();
};

こう書かせろよ。めんどくさいな

>>320
配列で使えんやん

>>338
class Hoge requires HasFoo {
void foo();
};
ならあり得るかも。

>>339
concept_map ?

>>341
concept_mapってsignatureのようなことできる様になるの？
便利やね。
struct A
{
　//・・・
　void Method();
};
struct B
{
　//・・・
　void Method():
};
signature Sig
{
　void Method();
};
Sig array[]={new A(),new B()};//継承関係の無いオブジェクトを代入
array[0].Method();//それぞれ正しいメンバーが呼び出される

↓がg++4なら通るけどVC9などintがint&に変えられなくて駄目といって通らない。
これって自分何か勘違いしてますか？VC9のバグってことはありませんか？

struct MyClass {
int value;
void set_value(int v) { value = v; }
int get_value(void) const { return value; }
};
vector<shared_ptr<MyClass> > v;
...vに適当に要素を入れる...
for_each(v.begin(), v.end(), bind(&MyClass::set_value, _1, bind(&MyClass::get_value, _1))); // 駄目子ちゃん

あ、bindは<functional>のstd::tr1::bind、_1はstd::tr1::placeholders::_1です。

スレ違いな気がしてきた。C++スレへ行きます。すみません。

さあもう一度アインシュタインでなにか例え話してみれば？

誰もアインシュタインで例えたことなんて無いと思うが。

誰かアインシュタインclass作れよ

__declspec(dllimport) class Einstein * __stdcall BangEinstein(void);
class Einstein *Albert=BangEinstein();

assert(E==mc2)

アインシュタインタンジェント

もう拡張メソッドも組み込んじゃえよ

C++に拡張メソッドは色々と面倒で厄介な問題があるから無理

もうちょっと説明ｸﾚ
抽象的な言い方では判らないよ

ヒント：拡張メソッドはメンバ関数もどきを提供するんだから
当然ポインタから->を通して呼ぶこともできるべきだよな、C++的に考えて

ここから思いつく面倒ごとに思いを馳せれば現実的じゃないという結論には簡単にたどり着く

>>355
テンプレートメンバ関数の特殊化と同じような方法で実装すればいいんじゃね？
あれも新しいメンバ関数をクラスの定義の外で作ってるわけだし。

なんか演算子余ってないの？
p->>func() を func(p) の糖衣構文として扱うとかそんなんでいいんだが

>>356
特殊化はシグネチャを変えているわけじゃない。

>>357
->* とか?
でも (p->*func)() みたいに括弧が必須なのが面倒。

>>359
肛門を指してるように見えた俺は逝ったほうがいいんだろうな orz

　)*(

>>352
拡張メソッドのメリットって何？

>>361
むしろ梅干し食べてる感じ

>>356
難しく考えすぎ

普通に第一引数がthisでそれ以外が普通の関数の定義と同じようになるようにすれば良い。
たとえば
class foo {}; // 定義
class foo { int bar(int baz) { return baz; } }; // 拡張メソッド(C#風)
って書いたら
int foo_extended_method_bar(foo* this, int baz) { return baz;}
って書くのと同じようになるようにすればいい。
でも継承したらどうなるかとかは知らん

>>362
使ったこと無いからわかんないなぁ
rubyのサンプルコードで良く見るけど

>>364
なにその生産性の低い記述は。

あくまで後から擬似的にメンバメソッドを追加できるようにするシンタックスシュガーでしょ。
あんまりいい例じゃないけど、なんでこの行列クラス、固有値求められないんだよ…ってときに：

#include "matrix"
// class Matrix;
#include "eigenvalues"
// vector<double> eigenvalues(const Matrix& this);

Matrix m;
auto es = m.eigenvalues(); // eigenvalues(m); と同等

Matrix* pm;
pm->eigenvalues(); // eigenvalues(*pm);

比較的簡単な処理の流れはメソッドチェイン出来ると楽ってだけかと
ただC++だと例外を軽く使えないからエラー処理をどうしようってことでMaybeモナドが欲しくなる

>>366
例が悪すぎます

>>366
Matrixをテンプレートの型パラメータで渡したときなんか拡張メソッドの定義includeの読み込み順で拡張メソッドが適用されたりされなかったりするのかな

oven(egg)のpipableは拡張メソッドっぽい

ソースが短くなるだけで、生産性の低い、動きがトロい、そんなバイナリーができそうだな。
現状のSTLも遅いし。

拡張メソッドの解決は動的ポリモルしなければコンパイル時に行うことができるんでそうとも言いきれない

第一引数を前に出す、単なる糖衣構文だから、バイナリが遅くなるなんてことはないわ

C++だとただの糖衣じゃ済まないから注意しないとオーバーヘッドはかかるな

operator.ぐらいの糖衣

generic functionがあるのに必要ですかね。

>>372
それが問題なんでねぇかい

テンプレートメンバ関数はその辺上手く逃げたよなぁ

普通のオーバーロード解決でなんか問題あるんか。

>>378
kwsk

objがfuncメソッドを持ってなくて、スコープにfunc拡張関数がある場合、
obj.func(args) を func(obj, args) と字面上同義みなすってことでは？

generic functionがあるのに必要ですかね。

必要です。目的が違います。

ほとんど変らないんじゃない？
virtualにならないんだし。

generic functionて何。

あるオブジェクトに対して行う処理を
まずオブジェクト名から入力できるとインテリセンスとかで楽できるんだよね
候補が狭まるから

あほくさ

今時インテリセンスも使いこなせない奴がいるのか・・・

0xの次で多重ディスパッチが入れば一緒に入るんじゃないかい＞拡張メソッド

汎関数の多重ディスパッチは既にある。

おっぱいを大きく見せたくて多重ブラジャーする美少女中学生

久々に上がってるんで見に来てみたら…

この前、時間が作れたんでようやくmailing2009-02を少し読めた。
久々の単独署名のDouglas Gregorの"Concepts and Ref-qualifiers"、
いやーやはりRvalue Referencesは難しいですね。

それからDouglas GregorってAppleに就職したんだな。(2008/10)
古くはIOKit、今はWebKitとC++結構使ってるからな。

0xって本当に0xに出せるの?

残念ながら1xがほぼ決定

でも未完成のまま強引に0xに出しそうな気もする
やめてほしいけど

ISOの手続きのスケジュールの都合で無理なのでは？
それがなかったとしても十分09に間に合いそうもないが。

もう出しても意味ネーよ。

>>391
auto concept HasAssign<typename T, typename U> {
typename result_type;
result_type T::operator=(U) &; // ←Rvalue reference!
}
ﾜﾛｽ

>>395 そうきいている

autoっぽいものを現行のC++で実現するマクロってあったような気がするんですがマクロ名を知りませんか

BOOST_AUTOのこと？

gccのtypeofかなぁ？

僕は言語仕様の問題のほか、現実的な理解者とコンパイラがいつ現れるかも
気になる。現行のSTLやBoostですらコンパイルエラー、ワーニングが長すぎて
解読困難なのに、これ以上になるのかと思うと気が重くなる。

しまった・・・sage忘れた・・・

C++0xのconceptにはエラーメッセージを簡易にする目的もあります。

俺を含む凡人以下からすれば
「まずはまともな処理系を出してくれ、話はそれからだ」
だからな
WGにいる仕様書だけでコードを書いてあーだこーだ議論してる奴等は化け物に思えてくる

>>404
一般的な開発者がその恩恵を受けられるのは、
どんなに早くても2012年頃かと思われますw

concept については厳しいだろうけど他の機能についてはちょこちょこ実装されつつあるじゃん。

可変長テンプレートとか右辺値参照とかばっかり先行してて
可読性を良くする機能はことごとく後回しにされてるけどな

可変長テンプレートはありがたいだろ。
TEMPL1(X)
TEMPL2(X1, X2)
TEMPL3(X2, X2, X3)
：
TEMPL20(X1, X2, X3 .. X20)
とかもうイヤだよ。

そりゃそうだけど、ソースが読みやすくなる訳じゃないじゃん
エラーメッセージは多分もっとわかりにくくなるだろうし

可変長テンプレートが「可読性を良くする機能」ではないとすると、
後回しにされてる機能って何のこと言ってるの？

>>410
そりゃまあ一般論としてはそうかな。
ただ俺は馬鹿だからか、機械生成しなかったのが悪いのか、
5引数のやつだけ書き間違えて大填まりしたことあるわ。
気づくわけないっての

http://www.open-std.org/jtc1/sc22/wg21/
News 2009-03-24: The 2009-03 post-Summit mailing is available
News 2009-03-24: The C++ Standard Core Language Issues List (Revision 62) is available
News 2009-03-24: The C++ Standard Library Issues List (Revision 63) is available

というわけで最新のWorking DraftはN2857ですか。

あんまり面白くねーな
ラムダ関係がボロボロで全面書き直しって事くらいか
あと日本からのコメントrejectされまくり

結局ラムダ式って Monomorphic なやつだけしか入らんの？
型名書くのだりーよ…
結局 Boost.Lambda のほうが便利じゃんってオチ？

>>416
何言ってるのかわからん。 Boost.Lambda のどんな用法のことを言ってるの？
C++0x のラムダ式で置きかえらない用法があるってことなんだよね？

>417
単に引数の型書くのが面倒という話では？
_1 + 1
[] (int n) { return n + 1; }

もともともラムダ式の提案では引数の型を指定しないでよいものも込みだったんだけど、
分割して型を指定するものだけ先に持ってきたのが Monomorphic なラムダ式のはず。

[] (auto x) { (ry }とか[] (x) { (ry }とかでできないのかな？

>>417
Boost.Lambda は多相じゃん。
(_1 + _2)(1, 1) // -> int 2
(_1 + _2)(1.0, 1.0) // -> double 2.0
単相にして保持したければ
　function<double(double, double)> f = (_1 + _2);
f(1, 1) // double 2.0
とかもできるし。

ちょっと調べてみたら n2529 で、
　(n2329 にあるように higher implementation cost なんで)
　"We do not propose generic lambda functions for C++0x."
って書いてあるな… これはダメっぽい。

range based algorithmの採用も却下されたことだし
まだまだboostの役目は終わらないということだな

boostの肝心な機能を骨抜きにしたのが標準だな
結局みんなboostを使い続け、std名前空間を汚染するゴミが残るだけという

という意見をぜひ comp.std.c++ あたりに投稿してくれ

日本の総意ってことで

> range based algorithmの採用も却下されたことだし
（ ﾟдﾟ）

配列初期化の記述だけはサッサと実現してほしい。

関数型言語とC/C++の関数ってどういう関係？

特に関係はない

ちょっと確認。
cout<<boolalpha<<uppercase<<true;
ってした場合でも、TRUE(大文字)とは出力されないんだっけ？
それで規格どおり？

>>427
そんなこともないだろ。両方関数だし。

じゃあC/C++の関数が関数型言語とどう関係あるのか教えてよ

関数型言語の関数は、数学的な関数ほぼそのもののことを指している。

Cとかの関数は、それから来ている名前ではあるけど、(サブ)ルーチンのことを
そう呼んでるだけ。たまに数学的な関数のような性質を持ってることもある。

>>431
いや>>426は「関数型言語における関数と、C/C++における関数」の性質の違いを
知りたがっているのではなくて、「関数型言語」と「C/C++の関数」の関係を知りたがってる。
葉巻型UFOと日本たばこ産業の関係を質問するくらい、わけのわからない質問ではあるが。

＞関数型言語の関数は、数学的な関数ほぼそのもののことを指している。
＞たまに数学的な関数のような性質を持ってることもある。
ん？どう違うの？

つ http://ja.wikipedia.org/wiki/%E3%82%B5%E3%83%96%E3%83%AB%E3%83%BC%E3%83%81%E3%83%B3

さすがwikipedia

つまり状態の使用や副作用をおこさなければ関数型言語と等価ということですね。

>>436
基本的には Yes.
ただし、状態も副作用もない関数を書くとしても、
手続き的な考え方だとローカル変数を値を変えながらループして計算したりするのに対し、
関数型言語的な考え方だとローカル変数に一度束縛したら値を変えず、ループのかわりに再帰とか集合演算とかを使う。
そこらへんの美学の違いは理解すべきかな。

>>428
真偽値を表す文字列をnumpunctから取得して、
ストリームへ「インサートする」って書いてあるから、
uppercaseは適用されないね。
取得した文字列を再度operator<<するわけじゃないから。

それで自分流のnumpunctを定義する方法は、
22.2.8.13に例が挙げてある。

その筋の用語では「参照透明性」な

ぷ

美少女中学生のおなら？

>>438-439
ありがと。
規格の該当パラグラフも確認しました。

locale関連になっちゃうのね。。。
そのあたりの深入りは避けたいので、簡単に文字列として
出力しようと思いますた。

そうそう。
結局、os << b ? "TRUE" : "FALSE";を関数にまとめればいいやというとこに落ち着いちゃうんだよね。

本来の主旨とちょっと違ってくるけど、
マイ書式には引数付きマニュピュレーター使って
その中で出力しちゃってる。

けどこれC++0xの話題じゃないじゃんw

美少女中学生の話題をしようぜ！

女子中学生をいじったら汁が出てきたよ（＾−＾）

>>445
あー、たしかにマニピュレータはよさそう。
また機会があったらオレもそうしよ。

>けどこれC++0xの話題じゃないじゃんw
そうだった。ｗ
でも、C++で規格ガチの話ってこのスレが一番じゃね？

>>448
C++相談室でいいよ。だいたい規格ガチで文句言われるスレなんてないだろ。

ここは標準化委員会の迷走を横目で生暖かく見守るスレです

そんなんだから日本からのコメントがrejectされまくるんだよ。

あれは結構な割合で、rejectされるだろうけど一応送っておくか、的な雰囲気のものが入っていた気がする。

どーせ仕事じゃ誰も使わないよ。

>>452
Unicode関係とか結構気合い入れて議論してたんじゃないの？
サックリrejectされてて笑ったが

あんなコメント読まされる方もたまったもんじゃない。
かなり基本的な部分でUTF-8前提にしろとかもうアホかと。

ttp://ja.wikipedia.org/wiki/ビャーネ・ストロヴストルップ

ビャーネ・ストロヴストルップ（Bjarne Stroustrup, 1950年6月11日 - ）は、
デンマークのオーフス生まれのコンピュータ科学者。
本人による自身の名前の発音は「びよーねすっぽすっぽ」に近い。

ttp://www.research.att.com/~bs/bs_faq.html#pronounce
ttp://www.research.att.com/~bs/pronounciation.wav

どのへんが近いんだ？

そうだよな、「すっぽすっぽ」じゃなくて「すぽっすぽっ」だろ？

JPのコメントにすぽすぽも呆れとったわ

とりあえず提案だけは出しておこうってのはどう考えても間違いだったな
無理なものは無理と委員会で止めるべきだった

説明が足りてるか、表現が正確か、おかしな解釈が出来てしまわないか、あたりの確認なのに
JPだけ変な気合い入れて新機能の提案みたいなことしてて明らかに浮いてる
恥ずかしいわ

そんなことに恥ずかしがるのはJPだけ
みんな言いたいこと言ってる

「スドゥハウっスドホッブ」を「すっぽすっぽ」のリズムで読めば良い。
strou と strup の間の「っ」(stød) で声門を絞めるのが肝

肛門が閉まりました。
つーか読みにくい時は、呼び名つけるだろ？
てきとうに、太郎とかつけりゃいいんだよ。

禿

そんな議論はどこで読めるんですか？

>>457
ほんとだ、「びや〜ね=すぽっすぽっ」に聞こえる。

あまりの卑猥さに美少女中学生も赤面！！！！！！１１１１

生粋のデニッシュには言いやすい発音なんだろうな

C++0x出たらJAVAとかいらなくなるんだよね？
またCさえあればいい時代が来るってことか

Javaがどうなるかは知らんが、0xはGC付き言語の代わりにはならんよ

Javaと対抗になるのはC#とC++/CLIだわな

D…いやなんでもない

>>473
Delphiですね、わかります

C# vs Java
F# vs Scala
C++ vs D…いやなんでもない

>>473-475
おまいらとは別スレであってるような気がしてならない

>>458
http://twitter.com/finalfusion/status/1469586480

http://blogs.wankuma.com/episteme/archive/2009/04/08/171040.aspx
http://d.hatena.ne.jp/faith_and_brave/20090408

> 税込2,940円

高い！

淫鳥

まあ、どうせ某所にうpされるだろうし
そうなったら眺めてみるか

C++でこの手の本を書くと、バッドノウハウの詰め合わせみたいになるのは必至だろ…

だがそれがいい

びよーんすぽっすぽっ

誰も名前だとは気づかないな

バッドでもナンでも成程と思わせる何かが含まれてるかどうか
邦人の著者は入門レベルでお茶濁すパターンの繰り返しだからねぇ

>>484
「びよーん」じゃないよ「びや〜ね」だよ。

MC++Dの焼き直しみたいな本じゃなけりゃいいけどな

参考書買ったつもりが
中身は校正不足な教科書崩れですタ
みたいな

入門書はもういいよ

ガチガチの数学選書みたいにまともなコンパイラもない今の時点での0xの応用を書いてある本がほしいです。

どうせ著者のブログ記事の焼き直しでしょ

誰も仕事じゃ使わんだろ。

>>490
つ　規格書

規格書に応用なんて書いてないだろ。

wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww

wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww

　　　 _, ._
　　（ ・ω・）
　　○=｛=｝〇,
　 　|:::::::::＼, ', ´
.ｗｗし ｗ`（.＠）ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
　　 ~~~~~

テンプレートクラスを入れ子にすると>>演算子が優先されてエラーになることが何度かあったんだが
これって次で直るかなぁ？　演算子の優先度の問題だから無理だよな・・・？

>>498
C++0xでは vector<vector<int>> も大丈夫

ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html
これな
gcc 4.3では取り込まれてる

まあ、読みづらいから俺は空白であけるけどな

ビルド通らないから空白あけてるけどさｗ
3つ以上入れ子にすると逆に見づらいというか、typedefつかえってことか。

そんなに入れ子にしたら、遅くてたまらんだろ。

それほどでもない

いや遅いって。
javaや.netよりかなり遅くなるぞ。

遅いってコンパイルの話じゃなかったの？

何だそりゃ？

javaや.netよりかなり遅くなるって何のネタだよｗ

コンパイルの時間の話なら、そんな入れ子にしなくても元から十分遅いし。

コンパイルはC++よりC#の方が速いって話でしょ。実行速度の話じゃない
でもMPLでもやらない限りテンプレートはあまり関係ないと思うけどね

MPL = MetaProgramming Library な。

TMP!TMP!

vectorを三つ入れ子にしたら、実行速度は確かにスゲー遅くなるだろうな。

MPL() { 笑 };

実行速度の話だろ？
バカなのか？お前らは。

誰が真の馬鹿なのかは、俺の心の中にしまっておくよ。

そこでしか生きられない言い分だものな。

みんなでシャドーボクシング

じゃあこの山括弧をくっつけて動くようにしろよ！

　　　　 lヽ ﾉ l　　　　　　　　ｌ l　ｌ ヽ　　 ヽ
　 )'ｰーノ(　 |　|　 | ､　　　　　 / l｜ ｌ　ハヽ　　|ｰ‐''"ｌ
　/　M　　|　|　|／| ﾊ　　/ / ,/ /|ﾉ /l /　ｌ l ｌ|　ｌ　 M ヽ
　l 　 ･　　i´ |　ヽ､| |ｒ|| |　//--‐'" 　 ｀'メ､_ｌﾉ| /　 ・　 /
　|　 P　　l　 トー-トヽ| |ノ　''"´｀　　　ｒｰ-/// |　 P　｜
　|　 ･　　 |／　　 　 | l ||､　''"""　 j　""''/ | |ヽｌ 　・　｜
　|　 L 　 |　　 　 　 | l |　ヽ,　 　― 　 ／　| |　ｌ　 L　 |
　| 　 !!　 |　　 　 /　| | |　　 ` ｰ-‐ ' ´||　,ﾉ| |　|　　!!　｜
ノｰ‐---､,|　 　 /　│ｌ､l　　　　　　 　 |ﾚ' ,ﾉﾉ　ﾉハ､_ノヽ
　/ 　　 　 　 ／　ノ⌒ヾ､　 ヽ　　　 ノハ,　　　 　 |
,/ 　 　　　,イーｆ'´ /´　　＼　| ,／´ ｜ヽl　　　 　 |
　　　　 ／-ト、|　┼―- ､_ヽﾒr'　, -=ｌ''"ハ　　　　|　 ｌ
　　 ,／　 　|　ヽ 　＼　　_,ノｰｆ' ´　　ﾉノ　 ヽ　 　｜　|
､_　　　 _ ‐''ｌ　　`ー‐―''" ⌒'ｰ--‐'´｀ヽ､_ 　　_,ノ　ノ
　 ￣￣　　 |　　　　　　　　　　 ／　 　　　　

プロプロセッサ・メタプログラミングもお忘れなく。

c++で何でわざわざ遅いプログラムつくらなあかんのか。
メタなんて価値なしのオナニーだよな。

はいはいクマクマ

JVM向けのコンパイラ書く奴いねぇかなぁ。
そしたら、ワザワザJavaに書き換える事もなくなって便利なんだが。

ところで、いつのまにやら入れ子クラスから外のクラスにアクセス
出きるようになったんだな。BCC5.5だったか、CL8.0だったか
対応してなくて、ずっとそういうもんだと思い込んでfriend使ってたわ。

>>519
なるよ。

VECTOR３つでも用途によるだろ。
いまどき遅いといっても知れてるわ。

数えられる程度にしか回らないコード部分なら結果が正しければ少々何しようと勝手だよな

まったくだ
とはいえ、vectorを三つも入れ子にするようなコードが
数えられる程度にしか回らないケースって少ないような気もするけどな

>>513は知恵おくれだろ
馬鹿馬鹿しいからスルー推奨

>>528
知恵遅れはお前だろカスだな。

本人登場。幼稚なオウム返しによって相手の見方が正しいと証明してしまいました。

読み書きの速度は配列と変わんないですよね？
サイズ変更は起こらないケースで

違う。配列とは別物なんだから変わってもおかしくない。コンパイラの頑張り次第。

コンパイラ？

コンパイラ∋オプティマイザ

>>532
別物なんですか？どう違うんですか？

同じだよ。

配列とvectorは全く同じというわけではない。
でも要素を指すポインタの配置だとかの制限が多々あって、
vectorの内部構造は配列を使うことが多い。
その場合、最適化次第で配列とほぼ同じ速度で動かせる。

どちらかというと
たいていの場合はまったく同じ速度で動かせる、のが正しいだろ

なんだよほぼ同じ速度ってｗ

operator[]をいちいち呼び出すかもしれないって事でわ？

実測しろ。

vectorは連続性が保証されているから、&[0]で先頭アドレスを取って配列として使うなら、配列と同速度であろうことは想像できる。
ただ、配置される場所がヒープかスタックによっても速度は変わるかもしれない。

実測、実測って、様々なプラットフォームで実行するプログラムはどうするんだよ。
何でもアホみたく実測する前に、一般論で考察しろ。

>>541
様々なプラットフォームで実測して、場合によっては最適な実装を
コンパイラスイッチで切り替えるぐらいはしてもいいんじゃない。

一般論で考察して済むようなら、最初から速度が問題になるような箇所じゃないってことだよ。

実測馬鹿

なんちゃってー！カクカクカクカクカク！

544 名前：デフォルトの名無しさん[sage] 投稿日：2009/04/18(土) 15:34:52
なんちゃってー！カクカクカクカクカク！

激烈バカとはなつかしい

カクカクと聞いていやらしいことを想像してしまった美少女中学生がこのスレにいます！

>>540
保証されてない

されてるよ。

当初03の規格には入ってなかったんだけど
後から委員会のほうで「そういう風に作ってね」って付け加えたんだっけか。
いずれにしても現在では保証されてたはず。

23.2.4.1(2003年版)に
> The elements of a vector are stored contiguously, meaning that if v is
> a vector<T, Allocator> where T is some type other than bool, then it
> obeys the identity &v[n] == &v[0] + n for all 0 <= n < v.size().
と明記されているのでれっきとした仕様です。1998年版にはありませんでした。

まあ、むやみに大きさかえまくってたら遅いだろうけど、そういう場合はlist使うだろうし
どっちにしろ入れ子にしなきゃならんものは、Cで書いてもそれなりに重い処理になる。

ということは、使った方が手軽で安全ということになるな。

伸びてたから期待して来たのにこんな流れかよ…
ムーブセマンティクスがどう効くかとかarrayと比べてどうとかいう話かと思ったのに
03以前だけの話ならSTLスレでやれよ

548 名前：デフォルトの名無しさん[sage] 投稿日：2009/04/18(土) 23:16:36
>>540
保証されてない

>>552
それはないだろ。

3重vectorの話がでてたけど、
vectorってムーブセマンティクスやCOW
の実装あるんだっけ？

あるよ。

素朴な疑問すまん。
C++0xってx=9になるの?
それともなんかしくじって、
C++1xに続くの?

もう09にはならないはず

C++0xAでも0xBでもいいから早く出て来い。

>>558
八進数なのに9はない。

なんで八進数なんだろね。
K&Rもビット演算で八進数使うんだよね。
二進数と十六進数しかなじみのなかった自分は
ちょっとデカルチャーだった。

wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww

C言語 → UNIX → PDP-11
後はもう分かるな？

わからない

1バイト9ビットのマシンだと八進法も使う機会があると聞いたことがあるけど、PDP-11は違うよね？

二進数ベースの数値を10キー(の数字)だけで二進数直打ちよりは楽に入力できるからだよ。

x == 10 (ローマ数字)という
無理矢理解釈で2010年リリースか？

昔はコンソールにテンキーしかない計算機たくさんあったから。
だから昔の人は基本8進数と10進数。
古いアセンブラの仕様を漁れば分かる。

それはない

>>561
標準化まえのCの処理系では'\91'(=73)とかできたらしい。

例えテンキー入力でも 「8」 「9」キーででもシフト管理すれば簡単に 16進打ち 可能じゃん
char get(char k){
static char f=0;
if(k==9){f=8;return 16}
if(k==8){f=0;return 16}
if(k>=0&&k<=7) return k|f;
つらつら;
}

>>572
歴史も現場も知らない人間の机上の発想だな。同様のことを考えた人はいたかもしれんが表に出て主流になることはなかった、ってのはそういうことだ。

歴史を知っていると、10キーのカンマや演算子をa-fに割り当てる入力ツールを思い出せるんだけどね。
まぁ、>569はどうかと思うけれど。

10キー使わないし

俺もテンキー嫌いだし一生使うことは無いと思ってたが、
携帯のせいでテンキー的なものを強要されるようになったな。

>>568
ローマに0はなかった…

>>576
やっぱりテレビのチャンネルを変えるときは本体のを回したりするんですね

そういう人は、チャンネルを「変える」じゃなくて、
「回す」って言うらしいぞ。

>>569
当時は逆にテンキーがなかったんじゃ。
タイプライターにはテンキーなんかないし、
今と違ってスイッチいっこが高かった
だろうし。

8進数のいいわけはなんかで見た記憶が
ある。古いCかUNIXかの本だったか。

テンキーしかないコンピュータってのはマイコンキットとかだな。

>>569はど素人

>>578
携帯やパソコンのテンキーは少なくとも一秒に３タイプくらいは出来ないと効率悪すぎるし、
テレビのリモコンは３０分に１タイプできれば十分事足りるからな。
それとこれとは話が全然違うだろうとマジレスしておく。

玄人はこんなスレに来ません

回される想像をしてドキドキしている美少女中学生がこのスレにいる！

>>581
大丈夫、マイコンキットならきっと16キーだ。

>>566
マジレスするとインストラクションの基本形式が
16bit を 1+3, 3+3, 3+3 に分解して使ってたから
octal の方が表現しやすかった.

いつまで続けるんだ

単にioが四ビットだった名残だろ。

4ビットなら8進より16進の方が都合いいだろ

それだったら別に8じゃなくても16でもいいはず。

8進数なら九九の代わりに七七を覚えれば暗算できるけど、16進でffとなると厳しいと思うぞ。

>>592
インドに行って来い

インドでは99*99まで暗記するらしいな

19*19らしいぞ？
そして、なんと小学校の必須科目に「プログラム」があるそうだ。

しかし、インドはカースト制度のせいで
奴隷同然の生活を送っている子供たちも多数。

偉大な文明は多数の労働力を隷属させることにより築かれるものなのだ

いつの時代の話？

そろそろスレ違い過ぎてる

すれ違いの恋ばかりの美少女中学生・・・

>>594
サンスクリット語は数体系が複雑すぎて、
99×99まで暗記しないとろくに計算できないというのが実情らしいけど。

日本語みたいに、21を素直に「2 じゅう 1」って読めない。

>>600
どうやらそのようだな。
100まで暗記が必要らしい。
ttp://www.sf.airnet.ne.jp/~ts/language/number/hindij.html

外から見ると、インド人すげー、99×99覚えるんだ
実際を見ると、言葉が使いにくいからやむなく覚えてる

それなんてC++？

っていうか、インドは言語の数があまりに多いのと
学問に向いてないのとで、大学では英語でしょ？
小学校でも英語の授業があるらしいし。

日本語だって日付の読み方とか不規則で滅茶苦茶だけど日本人はみんな普通に読めてるし
ネイティブにはそれくらいあんまり気にならないと思うけどなぁ

残念、ヒンズーを筆頭にフランス語も暗算には向かない数の読み上げ方をするんだ。
例えばフランス語の99の読み上げを直訳すると、「4つの20と9足した10」になるらしい。

一方、日本語はエスペラントに準じて綺麗な読み上げ方をする言語なんだけどね。

>>605
99 は 4つの20と10-9 だとおもう (quatre-vingts-dix-neuf.)
93 とかのほうがひどい。(quartre-vingts-treize は 4x20+"3+10".)
フランス語地域でもスイス/ベルギーは nonante-neuf,
nonante-cinq に変えたはず。

>>604
数システムが複雑な言語では、暗算できない子供が多いみたいな統計もあるらしいけど。
フランス語もその筆頭。

中国が漢字を一定量覚えないと
手紙もまともにかけないという現状を憂慮して
簡体字を導入したように、
おフランスも暗算が簡単になるように数字の読みを
国策で変更すべき＾＾

インドは小学校の授業にプログラムを導入するに当たって
理解しやすい独自の言語を開発したそうな。

その頃日本では、三桁のかけ算とか普通は電卓使うから別に教えなくていいよね、とかやってたわけだな。

イギリスにも正字運動があったし、日本にもローマ字化運動があった。

>>608
繁体字のままの台湾との比較の論文があればみてみたい。

>>609
そろばん塾に行ってれば、三桁x三桁の掛け算は暗算で出来る。

「正字運動」でググったら、そうゆう流れもあるのかって思った。
おもしろい。

なんだこの流れｗｗｗｗｗｗ
正式版が出たgcc4.4のc++0x対応の話とか出てないのかｗｗｗｗ

GCCで盛り上がってるかと思ったのに…
なんじゃこりゃ

このスレに日本語情報の少ない0xについて語れる奴なんていないよ

まあ、われわれ下々のものは、ちゃんと提供されてそれ以外選択肢がなくなってからが出番だ。

これくらい張ってもバチは当たんないよな。
http://gcc.gnu.org/gcc-4.4/cxx0x_status.html

Conceptが入ってないから基本的にどうでもいいな。
Variadic templateは既に使ってるけど。4.4の前からあるからね。

差分はこっちの方が見やすい
http://gcc.gnu.org/projects/cxx0x.html

・auto
・Initializer list
・Unicode文字型＆リテラル
・enum class
・メンバ関数のdefault/delete指定

あたりが大きい追加かな
とうとうauto main(int argc, char *argv[]) -> int とか書けるようになってしまった

これなんて虫？
http://2sen.dip.jp/cgi-bin/upgun/up1/source/up26459.jpg

グロ注意

おもちゃ。

ムカデ

独習デザインパターンC++は参考になるね。

ムカデじゃなくヤスデの仲間だな

ムカデは各節に一対 -( )-
ヤスデは各節に二対 =( )=

オライリー本でこんなのがあったら
さすがに売り上げ減るだろなｗ

ページめくって実写とかだったら悲鳴まで出るに違いない。

ヤスデのグロ画像からオライリー本の話に行くところが素敵だ。

最近トビケラとカワゲラとカゲロウを見分ける勉強を始めた俺に隙は無かった

> 最近トビケラとカワゲラとカゲロウを見分ける勉強を始めた
なんでだよｗ佃煮でも作るのか？

言語仕様にPascalで可能な関数内関数を導入するように標準化委員会に言ってくれ。

ラムダ式と新関数構文を統合してついでにローカル関数も入れようという壮大な提案がある(N2825)

無理だと思うけど

もう無茶苦茶だな

C++の関数内関数はもう20年も前から提案されたり採用されなかったり
してるよね。

なんでローカル関数一つが採用できないのかわからん。

ただ己の欲求を満たすだけのために仕様作ってんだろ。
こんなの仕事で使えるか！

関数内クラスで用満たせるから

関数内関数を実現するためだけに定義された関数内構造体を何度見てきたことか…

関数内関数の実現は面倒なんだよ。内側の関数から外側の関数のローカル変数を
参照していて、内側の関数へのポインタを他に渡してる場合。
Usenix-88-lexic.pdf でも嫁

関数内クラスならstaticメンバ関数のポインタを関数外に出してもローカル変数には触れられないしコンパイラ作る方は楽だな

ラムダ式がちゃんと導入できれば副産物として簡単に実装できるはずなんだがな

>>631に戻る

>>638
とりあえずレキシカルクロージャ抜きで関数だけでも定義させてくれれば良いのに…

ローカル関数何に使うの？

プログラム書くのに使う

C++/Cでもみんなプログラム書いてるよ

ローカル変数にアクセスできるインライン(のみの)関数が一番いいと思う

グローバル変数にアクセスできない関数とかってないの？

>>643
sortに渡す比較関数とか即席で作りたいことあるじゃん。

ローカルクラスはテンプレート引数に渡せないからなぁ

>>648
正直どうでもいいな

無名関数でおｋ

関数内クラスを活用しだすと
関数の中身が九割九分クラスになって残りはチョロっとしたループや分岐だけに成ったりするが
これが不思議とメンテしやすいんだょな・・

おぞましいコード書いて悦にはいってんなょ

高度なコードは理解できないという理由で拒絶する奴が出てくるのが困りもの

高度なコードと聞いてケラケラと笑う美少女中学生

お前の勘違いぶりは犯罪者級

しかし、それが適性あり。

三項演算子はバグの元。

条件演算子と呼べって美少女中学生が嘆いてた

条件演算子以外の三項演算子ってどんなのがあるのさ?:

参考に聞かせてもらおうか、ですね わかります

それは演算子なのか？

>>658
君はプログラミングやめた方がいい

>>663
俺が言ったことじゃなくて、人から言われたことです

>>664
なんの免罪符にもなってない

C言語の話ではないがCを参考にした演算子系を持ってる言語で第2項に順次式おいたときとか()でくくらずに条件式を項にしたときとかの挙動が信用できない。

>>664
傷口が広がるだけだぜ

>>667
何で？

>>664
ありそうでなかったパターンのいいわけだな。

レベルの低い現場で言われたこと無い？
三項演算子禁止とか。
>653-654の流れで書いたんだが

レベルの低い現場に加わるのは、
それなりのレベルの低さが要求されるので、
残念ながら未体験です。

ああ。やっと流れが飲み込めた。
レベル低くてすまんかった

で、三項演算子が0xで何か変わったのかね？

発端は何気ない美少女中学生のつぶやき

gcc4.4のautoの使い心地とか誰か報告してくれよ

ローカルでstaticでない変数をauto変数って言ってたけど、違う意味になってしまった。

で、使い心地は？

つかったことがありません。

使い心地も何も、新しい機能は何も無くて、自明な宣言の文字数を
省略できるだけだから、何も変らないんじゃね？
後方互換性を気にするなら、愚直に今まで通り宣言するだけだし。

たとえばイテレータを書くときとか便利そうだね。
つかったことないけどね。Auto。。。

結局新機能なんか誰も使わないってことか
そうだよな、互換性考えたら使えるわけないよな

>>681
C++に新たなパラダイムを与えるものならともかく
auto は打つ文字数が減って腱鞘炎が直りました、
ぐらいしか変わらないという意味。

大事じゃねぇか、「腱鞘炎が直りました」。

auto が一般的になればテンプレートの中で演算し放題なパラダイスが訪れるよ。

>>682
でも右辺値参照も誰も使ってないぞ
4.3からだから入ってから大分経つのに

マクロだとautoは便利。

>>684
D言語のように静的に文字列弄れる訳でもなし、戻り値推論(以下)できる訳でもなし、C++0x程度じゃまだまだ。
auto Square(T)(T t)
{
    return t * t;
}

戻り値推論って有れば便利だけどさ、その程度の関数だったら、これでよくね

// 関数の文法は統一されるはずだと信じてる
template < typename T >
[] Square( T t ) -> decltype(t * t)
{ return t * t ; }

Boost.labmdaみたいな変態的なライブラリを使った変態的な型を返したい場合は、
重複はちょっと面倒だけど。

あと、動的に返す型が変わるような関数はどういう扱いになるの？　コンパイルエラー？

>動的に返す型が変わるような関数
?
returnが二つ以上ある関数のこと言っているなら両方の共通の型になる。

いや、

if(乱数%2) return ほげほげ ;
else return はげはげ ;

みたいな。

共通の型？ javaみたいに暗黙のうちに継承する型とかがあるの？

>>690
動的にって言うけど、それってコンパイル時に静的に解決しなきゃいかん問題だよね。

>>690
C++で>>687は出来ないよ。

>>690
intとlongならlongだし、A派生のBとA派生のCならAだし。

auto func = objf_list<>::choice(any);
auto x = func();

返り値の連鎖は無理臭いけど何が出てくるかわからんワクテカ感は0xでも味わえると思う。

>>688
今でも条件演算子でそういう状況になるので、
そのときどうなるかは決まっている。
それは戻り値推論でもそのまま採用すべきかものどうかは分からないけど。

ラムダ式は簡単な戻り値推論できるから、関数構文と統合されれば
>>688ならこう書けるはず

template < typename T >
[] Square( T t ){ return t * t ; }

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2855.html
Move constructor は例外を投げてはいけない・・・という話から、解決策として
noexcept という関数への修飾キーワードで例外を投げないことを
明示し静的にチェックできるようにしたうえで Move constructor はデフォルトで
noexcept にしよう・・・という話から、ついでにデストラクタもデフォルトで noexcept にしようという話。

今更こんな壮大な変更が取り込まれる可能性があるのか、甚だ疑問ではあるが、
確かにすごく欲しいとは思う。

&&とか、本気なのか？
ワザと誤解して間違いそうな文法考えて、「分かるヤツだけが分かる！」
って、選民意識を得るために作ってるとしか思えん。
もうちょっと分かりやすいのを考えてほしい・・・

>>697
そこでキーワードをnothrowにしないのは意地？

何の意地かは分からんがnothrowの方が分かりやすいのは確かだな

exceptの方が明示的でいいかな
「投げません」って言われても「何を？」って思うけど
「例外無し」って言われると「ああ、例外無いんだ」って思う

nothrowはすでに標準ライブラリに存在している名前だから無理っしょ

>>702
何のための名前空間。

次期標準にしようとしているのに？

みんな使わないのに標準？

>>703
名前空間で対策できるってことは予約語じゃなくて単なる識別子として導入？
そんなきもいのマジ勘弁

throw 1;って例外を投げてることになる？

なる。

>>706
まさにその通り。
operator new 関数に nothrow_t 型を引数として受け取るオーバーロードがある。
で、

struct nothrow_t {};
extern const nothrow_t nothrow;

>>709
いや、それがあるからキーワードとして nothrow を追加するのは無理ってことだろ。

attributeでいいじゃん…とおもったらattributeじゃダメな理由も書いてるな

型システムに入れるとかアホか

C++0xがマトモに使われるとは思えなくなってきた。
C99と同じ道をたどるんじゃ。

initializer_listとかが一部で使われるくらいだろうなぁ

コンセプトとかもう絶対無理

boostの中の人のような変態の為の機能だから普通にC++を使う人が使わないぐらいなら想定内

コンセプトはexport（笑）と同じ道を辿るだろう
誰も実装しない、出来ない

コンセプトは標準ライブラリやBoostの中で使われれば十分だよ。
テンプレートが関わるエラーメッセージの改善という程度のことに役立つと信じて。

いや、exportとは違うさ。
conceptを使うことには利点があるのだから。
exportは、コンパイル時間を多少短くできるってことぐらいしか利点がないから。
conceptなしでは、C++0xは語れないぜ。
C++0xの多くの機能が、conceptを前提にしているんだから。exportとはわけがちがう。

でも実装が出来ないんじゃなぁ
conceptGCCとかいつまでやってんだよ
主な商用コンパイラも軒並みガン無視だし

conceptの実装は時間がかかるぞ。
だいたい、中途半端な実装をリリースして、互換性の問題を引き起こしてもらっても困る。

互換性は諸刃の剣だな

conceptGCCはもう開発してないと思う…
9ヶ月くらい更新止まってるし、その前は1年3ヶ月更新止まってたし
http://www.generic-programming.org/software/ConceptGCC/download.php

>>719
vcの人は1年くらいかかるとか言ってたな
vc11には入るんだろうか…？

本家の concept ブランチでやってるんじゃないの？と思ったら
>At present, the concepts branch provides almost no support for concepts.
ttp://gcc.gnu.org/projects/cxx0x.html
とか書いてあるな、おい。
更新も 10 ヶ月止まってるっぽい。
ttp://gcc.gnu.org/viewcvs/branches/cxx0x-concepts-branch/

GCCが匙を投げたとなると他も追従するかもしれないな
コンセプトｵﾜﾀ

まさに絵に描いた餅ですね

コンパイラ開発者は標準化委員会にいないの？

少数で開発してるD言語にもコンセプト的な何かはあるのに、
GCCが実装できないってのは、C++の言語仕様の複雑さを物語っているようだ。

規模と実装難易度を考えりゃ、Concept以外が全部実装されてからやっと本腰入れてConceptに取りかかるくらいのもんだろう。
4.5で何が実装されるかってだけでもwktk出来るさ。

コンセプトがないと拡張for文もきないしライブラリの作り直しにも本腰入れられないだろ
さっさとしてくれ

言語オタクな連中に規格を作らせるからこんな事になるんだ

そうだよな。実務的な言語がものすごくキモい化物になって行く様は、おぞましい。

現状維持派　→　表に出てこない
変えたい派　→　騒ぐ

止める人がいない

HTML5ワークショップの実務に即した仕様策定がうらやましい

それが真実なら、とうの昔に標準GCが規定されてるはずだ

しかし、本当にjavaより速いプログラムを作るのが難しい言語になって行くなァ。

それはない。

VCが新ライブラリへの対応だけでも迅速に進めてくれればいいや
特に cstdint と regex

>>735
とりあえず
> どんどん〜なっていく
っていうのは無いはず。

i = i++ の結果は未定義なのでしょうか？

未定義じゃないと思う。

a[i++] = i;
の動作は未定義だそうだ

根拠

>>739
http://codepad.org/JCtHYXzj

iは変化しないって思ってたけどそうじゃないんか。
実戦ではつかえないっすねー。

単にその処理系でそうなるだけなのか、C++でそういう定義なのか、分からないだろ。

(´・ω・`)知らんがな
まぁ誰かが調べるまで気長に待てばいいじゃない

未定義というよりは不定なのかな？

C# では
int i = 5;
i = i++;
System.Console.Write(i);
で 5 が出力されるので疑問に思ってちょっと調べてみたんですけど
規格みると副作用とか副作用完了点とかよくわからない

「未定義」と「不定」を区別するならそれぞれの定義を。

とりあえず++演算子は右辺に置くなということで。
「未定義or不定だからヤメロ」って言えれば楽なんすけどねー。

>>746
wktk

区別はここみてそういう区別があるんだと思ったから

http://www.st.rim.or.jp/~phinloda/cqa/cqa7.html

補足
http://www.st.rim.or.jp/~phinloda/cqa/cqa7.html#Q8

未定義だそうだ。

おまえら揃いも揃ってスレタイよめないのか

739程度が一目で未定義とわからない奴らが新規格のスレに何の用だ

>>739-750

何この程度の低い流れ。自演？

>>737
Regexは2008 SP1の時点で登載済み。TR1としてだけど。

TR1との違いってコンセプト対応してるかどうかくらいだっけ？

テンプレくらい読んでから質問しろ

>>752
Sequence pointsすら分からない奴が、
まだ確定してない規格知ろうなんて十年早いよな。

はいはいすごいすごいえらいえらいかしこいかしこい

フィンローダなつかしいなー
あのころはCマガ面白かった

>>736
経験不足のおバカさんだな。

0xとあんま関係ないけど、UNICODEソースは仕様上なんか規程されてるの？
まぁ、サポートされてても日本語でソース書こうなんて思わないけどさぁ。

日本語で書けるなら書きたい

ソースコードに実装依存の文字が使えるということになっている。
まあ、今までも、C++のコンパイラは、ほぼ例外なく実装依存の文字が、少なくとも文字列リテラルやコメント内で使えたし、
いまさら規定しても何も変わらないと思うが。

「実装依存の文字」の話はしていない。
UNICODEの話をしている。

実装依存か・・・。VCでこんなコードも
通るんだが、現場とかで見るよう担ったらヤダなぁ、
変換するのがダリぃ。
int 二乗(int 引数)
{
　return 引数*引数;
}

識別子に漢字が使えるのはC++0xの仕様？
コンパイラーの仕様？

>>764
「ソースコード」の文字列に関しては、何にも規定されてないと思うんだけど。

>>765
知らなかった。プリプロセッサにも使えるんだな。
ということは、ラムダ関数が実装された暁に、λをautoか[]に#defineすれば・・・。
まあ、正直使いたくないな。


>>766
C++0xでは、識別子に、「その他の実装依存の文字」が使えることになってる。
だから漢字が使えても規格上問題ない（ソースコードの移植性はない）

>>767
二点質問があります。
「その他」ではない文字は何ですか?
C++0xに対応したコンパイラーが必ず使えなければいけない(移植性のある)文字セットは何ですか?

その他ではない文字というのは、

識別子の先頭の文字には、
a b c d e f g h i j k l m
n o p q r s t u v w x y z
A B C D E F G H I J K L M
N O P Q R S T U V W X Y Z _

先頭以外ならば、上記に加えて、
0 1 2 3 4 5 6 7 8 9

また、"universal-character-name"というものが使える。
これは、/uもしくは/Uに続く、十六進数で指定する、
/uは4文字、/Uは8文字指定できる。
つまり、/uXXXX もしくは /UXXXXXXXX という形式になる。
その表現する所の文字は、十六進数の値の、ISO/IEC 10646で規定されている値に対応する文字、
つまりはUnicode。

だから、以下のコードは妥当、ということになるはず。この辺は実は詳しくないのだけれど。

//C++0xでは完璧に合法なコード
int /u3042/u3044/u3046 = 0 ;

もし、コンパイラがその他の実装依存の文字を許可するならば、上のコードは、以下と同じ

int あいう = 0 ;

フォワードスラッシュなのか…

間違えたorz バックスラッシュだ。
int \u3042\u3044\u3046 = 0 ;

自然数 エー 配列 代入 ここからゼロ、ワン、ツー、ここまで。
加速繰り返し 括弧 自然数参照 エヌ、エー 国家
ここから
　標準の黒板に　書き出せ　エヌ　書き出せ　標準の行末。
ここまで

JIS X 3014:2003を読むと処理系依存にその他の文字とか全然ないですね。
ソースコードの文字はユニコードにコードポイントがなければならないように
なっています。
コンパイルの一番最初の段階で基本ソース文字集合（A-Za-z_0-9と基本的な
記号と空白類）か\uxxxx,\Uxxxxxxxxと言うようなユニコードの
コードポイントに変換されそのあとに識別子としての解釈があります。
なので\uxxxx,\Uxxxxxxxxだろうとそのままの文字だろうと識別子に使えます。
ただし識別子に使用できる文字はA-Za-z0-9_と規格の付属書(appendix)Eにある
指定されたユニコード文字だけです。
いまこれを書くために読んだ限りですが。。。

>>772
#define駆使すればもっと自然な日本語にもできるぞ。

http://pc12.2ch.net/test/read.cgi/tech/1037458703/942

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/#mailing2009-05

訂正
＞ JIS X 3014:2003を読むと処理系依存にその他の文字とか全然ないですね。
は
「JIS X 3014:2003を読むとその他の文字が処理系依存とか全然ないですね。」

>>773
トライグラフの変換は？

おちんちんがトライグラフ！美少女中学生も赤面！

なんだ誰も mailing の話してないのか

何それ

少ないしあんまり面白いのないんだもん
「for The-C++-After-0x」とかいう気が早すぎる奴くらい

好きな男子との間に生まれた子の名前を考えるほど気が早い美少女中学生の話で盛り上がっております

>>777
トライグラフも同時だよ！

>>781
なにげにあったら便利だね

http://www.open-std.org/jtc1/sc22/wg21/
News 2009-05-08: The C++ Standard Core Language Issues List (Revision 63) is available
News 2009-05-08: The C++ Standard Library Issues List (Revision 64) is available

g++ (GCC) 4.2.4って、C++0x 5対応済みなの？

ここに載ってるのは 4.3 以降だな。
ttp://gcc.gnu.org/projects/cxx0x.html

>>787
Thx

美少女中学生が次のレスはまだかまだかとwktkしています

保守

C++0xって、本当に今年、出るの？
そう言う雰囲気を、ちっとも感じないのだが、
いきなり「出来ました」って出るの？

予定は未定
この世界の納期は破るためにある

Committee draft以降は各国の意見調整をしながら
投票の繰り返しになるから、まあ地味っちゃ地味。
サイトにDISって文字が現れだしたらゴールは近い。

ラムダ周りが各国（日本除く）からフルボッコにされてるから簡単には終わらないと思う

○○○ 2008が2007年に出たりするんだから
c++ 0xが2010年に出てもいいじゃないか

○○○6月号は5月にでるんだから、C++0xは08年までに出さないといけなかった。

0xって16進でしゅ。つまり2015まででしゅよ。by禿げ

それなら0x0xと書くべき

>>798
それだとやっぱり09年までだろ。
オプソ厨のアホさ此処に極まれりだな。

>>799
with whom you are fighting?

英語がわかんなくてあわあわする美少女中学生

C++09 Attributes: Specify Your Constructs' Unusual Properties
ttp://www.devx.com/cplus/Article/41694?trk=DXRSS_LATEST

"[[final]]"ってなんだよ・・・ｗ
かっこはひとつでいいじゃん

それはどんな識別子でもキーワードにできる魔法の括弧だよ。

かっこわるい……

lisp 属の () を笑えない変態構文だらけなんだが
こいつ等にシンタックスシュガーをかませようとか
ってな, 話はでてこない？？？

C++の仕様考えてる人にはもはやLISPを笑わない人しか残ってないってことだろ。

FC++で関数型言語汚染が酷い
mplやpreprocessorで「汚いlisp」汚染が酷い

逆に考えるんだ
LISPこそ、全てのプログラミング言語の最終形態なのだと
全てのプログラミング言語はその進化の果てにLISPと同一化するのだと

LISPは化け物だ。って格言無かったっけ。
すべてを飲み込んでしまうってやつ。

俺は>>807の言う通りの人間だ。
C++0x萌え、CLOS萌え

美少女中学生は余計なかっこつけが嫌いです。

とゆうことは
「美少女中学生はC++0xが嫌いです」
でおけ？

>>810
むしろ寄生虫じぇねーの？
いろんな言語に入り込んでるが、それ自体で使われることが少ないとかさ。

>>814
ほえ？
他の言語が Lisp のアイデアパクリまくってても、それに対して何も言わないが

> それ自体で使われることが少ないとかさ
ここ数年ずっと Lisp で納品物作ってるwW

いまPerlを勉強中
LISPよりしごと多そう

>>815
是非御社で働かせていただきたいでつ ＞＜

>>815
ほえ、じゃねーよ。なめんなよ。

美少女中学生なんじゃねーの？

はにゃ〜ん

和訳：Rvalue References: C++0x Features in VC10, Part 2
http://d.hatena.ne.jp/ntnek/20090210/p1

3ヶ月前じゃん


まあ有用だとは思うが

comp.std.c++ に Scott Mayers がすごい勢いで投稿してるけど
Effective の新版でも書き始めたんかな？

ものすごい勢いでcobol化していくc++。

>>823
どっちかというとC++0xに向けての改正版作成のためっぽい

>>824
COBOLというよりPL/Iの時の悲劇を思い出させる

巨大化しすぎてまともに使いこなせるユーザーがほとんどいなかった

PL/IとMulticsの失敗による教訓からUNIXとC:言語が生まれたが
時代はまた繰り返そうとしている

複雑化する一方のC++とWindows

PL/Iは最初から巨大だったんじゃないのか。
だいたい名前からしてでかすぎるだろ。

現時点でもPL/Iのマクロ＞＞C++のテンプレートくらいですね。

C++0x を教訓により良い言語が生まれるならそれでいいじゃないか

C++を代替可能なC++より良い言語なんてどこにあるんだ
あったら使いたい

　D・・・いやなんでもない

Dのテンプレートで浮動小数点とか文字列引数に取れるのはうらやましい。

もう何年もC++使ってるから新しい仕様にも何とかついていけるが、
今からC++を始める人にとっては相当大変だろうな。
そして、禿はいつ第4版を書くのだろうか。

別に全機能使うことはないだろう。STL使うだけでもわりと幸せ。

Boost.ConceptCheckにはよく世話になってる

STLをまともに使うのも意外と面倒だからな。

Better Cで十分な漏れはなんでこのスレにいるんだろ？ｗ

最初のうちは関数オブジェクトを作る時にstd::unary_functionや
std::binary_functionを継承しなければならない理由がわからなかった

いまでもわからずにやっているので教えてください

STLスレででも聞け

別に継承する必要はないんじゃ

つーか継承前提のくせに仮想デストラクタ持ってない危険なクラスだから使っちゃダメっす

でりげーと

継承前提であっても基底クラスのポインタで多態させるような使い方はしないから問題ないだろ。

という反論が来るのは分かり切ってたが、そんなの言い訳にならないと思うんだよな
unary_function*があらゆる場所で絶対にdeleteされないとどうして言い切れるのか

本来はprotectedな非仮想デストラクタを提供すべきだった

そもそも、unary_functionやbinary_functionは、テンプレート引数に関数オブジェクトを渡す時、
引数や戻り値を得るためのものなんだよ。
そもそもの想定されている使用方法が、ベースクラスで渡すものじゃないんだ。

お前の言い方は、

unique_ptrは、auto_ptrと違い、そのスコープ内のみがオブジェクトの生存期間だと明示できる、というけれど、
「何もしないdeleter」をunique_ptrに渡したら、auto_ptrみたいに使用できるじゃないか、
プログラマが絶対に、「何もしないdeleter」を書かないと、どうして言い切れるのか！

と言っているのと何ら変わりないんだよ。

unary_functionやbinary_functionのやっている事は
実は単なるtypedefなんだけどな

これが無くても平気な関数アダプタはあるが、bind2nd()などは
無いとエラーを吐く

decltypeがもっと早くからあれば、完全にダックタイピングでいけたんだろうか

843みたいなアホがなんでこのスレにいんの？

unary_function/binary_functionは必要なtypedefを書くのをちょっと楽するためだけのもの
しかもbind1st/bind2nd使わないなら不要
さらにC++0xのbindには内部resultテンプレートがあれば引数型は固定でなくてよい
result_of<>はresult_typeもしくは内部resultテンプレートがあれば十分

ところでCallableコンセプトあればresult_ofいらなくね？

>>851
コンセプト使うの前提にすれば、Type Traits系のライブラリなんて全部いらなくね？

クラス組んじゃえばそうだろうけど、関数内でちまっと条件分岐させたいだけとかなら需要はいくらでもあるような。

conceptを検討し始めた時の条件として、
既存のtraits系などと共存出来て、段階的に移行できること、
というのがあった。

>>839のようなケースはconcept_mapに集約されていくのだろうか…

Douglas GregorがApple行ってConceptGCC止めちゃったから、
iteratorを整理したくらいでライブラリのconcept化は止まってるね。

wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww

>>855
C++0xには入らないのだから、
ライブラリのコンセプト化は後回しだろうね。

wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww

　　　　_, ._
　　（　・ω・）
　　○=｛=｝〇,
　 　|:::::::::＼, ', ´
､､､､し ､､､((（.＠）ｗｗｗｗｗｗｗｗｗ

一瞬、ここがGrassスレになったのかと思った。

>>851
not1、not2使うことって多くないのかな？

>>861
多くはないだろ。ｊｋ

みなさん新機能のチェック等に使うコンパイラは何でしょうか？
やはりGCC-4.4が多いのかな？

>>863
gcc version 4.5.0 20090605 (experimental) (GCC)

explicit変換関数が入ってるな

>>834
頭がついていかなくなって、
もう10年近くほとんど使ってないや…。
テンプレートの暗黙的実体化のときに、
constのあるなしで別の型というので、わけわかめ。

自分でテンプレートをばりばり作って
プログラミングしてる人ってどのぐらいいるんだろうか。
型推論自体は便利なんだけど、テンプレートと組み合わさると、
中で何が起こっているのか、わけがわからん。

>>866
> constのあるなしで別の型というので、わけわかめ。

特殊化で最適化したいことがあるから別扱いにします。
面倒だなと思うことの方が多いけど、慣れたらルーチンワークだし。

むしろ、templateって
自分で作ったのしか使えなくね？
boost::ublasとか、デバッグ出来るかよあんなの

テンプレートは全称修飾子

http://atnd.org/events/702

http://124.45.27.25:12086/stream.mp3.m3u
IRCNET #CRYBUTSU

ぶつぶつ会終わったよー

D言語で言うところのLazyがほしい。

ぶつぶつ会って東京タワーの近くでやってるあれのこと？

皮膚病じゃないか？

どうせなら本当の遅延評価が欲しいｗ

徹底的な遅延評価て
ひたすら自己完結で計算するだけの言語ならかまわんけど
処理に紐付けしてのOSと遣り取りが本分のC++には邪魔になるだけだと思うがね

申し訳ないが意味不明

過去のコードとの互換性捨てて言語仕様組み直せばいいのに

世の中にはそういう言語もあるから
そういうのがいい人はそっち使えばいいだけのこと

>>878
それはそれで、Dっていういまいち普及の兆しすら見えないものがあるわけで。

DはGCを（簡単には）取り外せないからC/C++の代わりにはならんよ
あれはどちらかというと出来の悪いC#

DはできそこないのC++/CLIだろう。

D言語は最近導入されたsharedのお陰でC言語/C++以上の最適化ができそうだね。以前gccの分岐の最適化によってLinux kernelでマルチスレッドのバグが起きたけど、これだとそれも防げそうだし。

他にも関数ハイジャック軽減法とか
http://www.kmonos.net/alang/d/2.0/hijack.html
例外安全なプログラミングとか(Boost.ScopeExitの元ネタ)
http://www.kmonos.net/alang/d/2.0/exception-safe.html
契約プログラミングとか
http://www.kmonos.net/alang/d/2.0/dbc.html
有用な提案がいっぱいあるが、C++との互換性の無さとライブラリの貧弱さと破壊的変更が多すぎることで台無し。
でもそれがいい。

>>883
なんていうかありがとう

Dの普及への前望が暗いことはよくわかった
0xと同じくらいには

C++0xは普通に普及するぞ。

しないだろ
最大の肝であるコンセプトを誰も実装できそうにない時点でもう無理
せいぜいSTLの実装で見えない所に右辺値参照が使われる程度に終わると思う

autoとInitializer Listだけでも0x使うわ

autoはイイな
もう糞長い型名を書くのはイヤだ・・・

開発現場では禁止されそうだけどな
C#のverへの拒否反応を見るに

しったか乙

C++03 の正当なコードで C++0x だと不正になっちゃうものってどんなのがあるの？

autoを記憶クラス指定子に使ってたり、
新予約語を変数名や関数名に使ってたり
SFINAEの挙動が変わった影響だったり

それくらい？

>>887
右辺値参照は結構表立って使われると思うけどな
コピー不可のオブジェクトをコンテナに入れられるようにできるし

しっかし、なんでここまで記号大好きなんだろう。
ワケワカめな構文だらけになっちゃって…。
それこそラムダ式なんて、lambdaとか予約語増やせばいいじゃん。

そもそも、デストラクタが「~クラス名」ってのから、
その傾向があったわけだが、もう一から文法考え直したほうがいいよ。
ツギハギだらけでばっちい。

予約語増やすと過去のコードとの互換性が問題になるし
互換性を気にしないならD言語というアプローチがあるし
って、こういう話は1スレ内で10回くらい出てくるね

それが普及しちゃった言語の宿命

後からそれ予約語になりましたとか言われても
困る人がいると

キーワード接頭記号とかつくったらどうだ。
たとえば、「#」で始まる単語は全部キーワード。
#lambda
#funcdef
#null
プリプロセッサは廃止ってことで。

そんなゴミｲﾗﾈ

C99では_Boolみないな変態キーワードが…。

#はだめか。じゃあ、「$」はどうだ。

そんなゴミｲﾗﾈ

$と@は使えません

というか、トライグラフやダイグラフみたいな有害なだけのクソ仕様を
ただ政治的な理由だけで入れざるを得なかったくらい苦労してる言語だぞ
記号関係はCの頃から予約語以上の鬼門

大局的に見て、C++にはもう言語的に拡張性はない、と
素直に過去の資産、一度チャラって言えばいいのに

>トライグラフやダイグラフ
正直アレらは丸ごと削除しても、現実的にあまり影響でないと思う。

Pascalみたいにこういうのどうだ。

auto main(auto argc: int, auto argv: char **) : int

Unicodeが仕様に導入される時代にトライグラフとかナンセンスすぎて笑い事じゃないよな
さっさとdeprecatedにして欲しい
どうせ不思議な力が働くから無理なんだろうけど

uR"[こんにちはrawリテラルです( ??'ω??')
でもトライグラフ様の変換が優先なので上の顔文字は( ^ω^)になります( ??'ω??')
ばかなの??(??= ??'ω??')死ぬの??
]"

何がいけないって、前の標準化もそうだけど、
しめきり間際に、駆け込みで仕様が追加されること。
確かに、その機能自体は有用なんだが、文法のことももっと考えろと。

けど良く考えてしまうと、
templeteを正定数で特殊化できたり、
その後の大爆発を引き起こしてしまう
ポテンホームランがなくなってしまうと思うの。
conceptやめてtraitsで頑張ろうとか。

てかなんで、_Finalとかにしなかったの？
[[final]]きもすぎるだろ。

よし、新しい言語を作ろう。

Ｃ＃やＪａｖａやＶＢ．ＮＥＴはアプリケーションでいうならＩＥだ。
提供されたコンテンツをただ見るだけ。
Ｃ＋＋はＥｘｃｅｌだ。色々データを工夫してがんばる。そこにまた楽しみがある。
本来プログラムはＣ＋＋程度までのものが一番楽しいとおもうんだが・・

これ以上Ｃ＋＋を近代化しないでくれ。俺はＣ＋＋が一番好きだ。

Ｃ＋＋は今のままにして、新しいのは、Reform C++とか別枠にしてください。

C++じゃないC++作るくらいならDでいいじゃん

そして >>880 に戻るｗ

ゼロオーバーヘッドの原則は維持したまま、C++を改良しなおしてほしいなあ。
Objective-Cみたいに、CからC++のメンバ関数を呼び出したり、
クラスの中身をいじくりまわせたりするようになるとうれしい。

0x のスレなのだから、提案されておらず、提出するつもりもない機能の話は、
例えば
C++ではこういう新しい機能が必要だと思う
http://pc12.2ch.net/test/read.cgi/tech/1173238573/l50
こういったような、ヨソのスレでやってくれないか。

あと、
C++は難しすぎ 難易度:4
http://pc12.2ch.net/test/read.cgi/tech/1221557484/l50
とか
C++ に未来はあるか??? そんなものはない!!!
http://pc12.2ch.net/test/read.cgi/tech/1178945996/l50
とか向けの話題もそれぞれのスレでよろしく頼む。

C++ に対する願望を書き込むのに、もう少しふさわしいスレがあったように思うが
落ちてるようだ。

0x への不満や愚痴はココでいいと思うのだけれども。

むしろ class や各種の修飾子を記号にしてほしい。

>>916
俺はむしろC互換じゃなくていい
DやAda95みたいな呼び出しインターフェースはないと困るけどね

で、俺の意見は「じゃあD使え」と言われるわけだ

>>919
なんでないと困るんだ？
困る理由は？

>>920
POSIXやWin32APIにアクセスできなくなるからでしょ
つかこれ系の話題はもういいよ

結論：C++わ最強。

コンパイルすると安全なC++ソースを作ってくれる程度のラッパー言語があればいいのに

必要は発明の母じゃないか
がんばれ！

じゃあ俺は、実数演算専用の言語が欲しい。
謎の技術で、C#とかのメソッド内に、
インラインで最適化されたネイティブコードを埋め込んでくれるやつ。
これがあれば、C++やめる。

C++からCの関数を呼び出せるように、
旧C++を呼び出せる、新C++を作ればいいんだよ。
今だって、同じコンパイラにCモードとC++モードがあるんだから、
過去のコードまで同じモードでコンパイルできる必要ないよ。

>>925
そういう用途には普通はBLASなどのライブラリを使うしそれで十分だろ。

>>925
数値計算するなら OCaml とか使ってたほうがいいだろ

>>928
それは極端すぎ

Ｃ＋＋に＋＋を追加したらＣ＃になったから、Ｃ＃＋＋を作るほうがいいとおもうよ。

C#には今のところ++しなきゃならないようなパラダイムはないと思うけどな

コンセプト？いらんいらん

テンプレート

ジェネリクスはあるから十分だろ
TMPなんか出来ない方がいい

十分じゃねーよ。バーカ

テンプレートの代わりとして、C++のコンパイルの前に超高機能なプリプロセッサとか実行すればいいんじゃね？
hogehoge<foo>って書くと、プリプロセッサのhogehoge関数がfoo引数で呼び出されてC++のコードを生成するみたいな。

0xの次はどうなるんだろうね。

前例から考えたら、五年後に曖昧な部分を明確にするなどの、マイナーな改訂か。
ライブラリとかもっと増やして欲しいけど。

>>918
つ　Perl

UNICODEをちゃんとサポートするんだから、
xmlの標準なライブラリが欲しいなぁ。
バリバリにイテレータとか使いまくってるようなの。

>>935
それはDがCTFEという形で実現してる

まさにD言語のCTFE+文字列mixinだね。
静的に文字列を弄ってコードを作りmixinできる。
デバッグが大変だけど。

そんなことよりevalをですね。

文字列mixinとかIDEやビルドツールを作るのが大変なんだよなぁ。
メンバの有無やimportの依存グラフを作るだけでコンパイラと同等の機能が必要になる。
Dはこの点C++より状況が悪くなっている。

でもそれを実装しているIDEが既にあるからなぁ。

Dの場合はコンパイル速いからIDEでもコンパイラ流用すればいいってかそうしてるんじゃないかね
C++だとそうはいかないかと

いや、そのIDEのコードはJavaで書かれているって話だったような。

そうかだからあんなに重いのか

J++はネイティブコードを吐き出してくれて結構早かったし
Direct Xとかも自在に使えて便利だったのに、どうしてやめたのかしら？

SUNが訴えたから

ずるいよ、SUN･･･

実は最初に実装した人が凄すぎて、誰も後メンテナンスできなくなった…とか利いたような気がするけど、本当かどうか走らない

まあ、結果的にVC#ができて良かった。

つ スレタイ

もっと人間の脳味噌のキャパを超えないような言語を頼む。
できるだけ多くの人に使われなきゃ意味内と思うんだが。

つ C

>>955
その程度ならまだひとのほうがよゆうある。

conceptやスレッド周りが実装されないと全体としては何とも言えないけど
いまgccやvcで使える範囲は全然余裕で使えるよ
むしろ、今まで「何故こう書けないようにしたし」って感じてたところが面白いくらいに解消される
lambdaの変態文法も、使いはじめてみれば普通に使えるっつーか短ければ短いほど使いやすいように感じてくる
使ってる記号([])は意味不明だけどね…

C++は、悪臭を放つような過去の遺産を引き摺り続けてゆく。
悲しむべき事に、これは将来に渡って変わらない、決定事項なのだよ。

C++の過去の遺産を整理するとC#になる。
悲しまずにC#を使えばいい。

C#にはtemplateが無い

なら過去の遺産と一緒にC++を使ってろ

もちろんそうします

genericじゃだめなん？

黒柳徹子もそうしろっていってるしなぁ･･･

C# もコンパイルする前に CFront 通すようにすればいいんでね？

C++をいい感じに整理したらD言ｇ・・
いや何でもない

C#もDもC++とは違うでしょ
GCなしでオブジェクト指向を書ける言語は今もC++くらいしかない

>>957
勘違いも甚だしい意見だな。
その結果出来上がったソースは、標準的な頭脳のキャパを超えてるだろ？
そして、スパゲッティ。

お前みたいなやつがいるから困る。

？
釣りかな……

むしろマ板でやってほしい話題だなそれ

[](){} って (){} とも書けるのん？

[]{} となら書ける

残念

>>957
D言語もGC無しで書けるよ。記述が長くなって面倒だけど。

peRLとc++さえありゃ、大抵のアプリは組めるよ。

美少女中学生はComeauに期待しています

結局、負の遺産とやらを使わずにC++使うのが一番ということか

>>977
言語の境界に触れずに使うのが賢いと思う。

ヘンに先進的な機能も避けるべき。

#include <iostream.h>のことですね、わかりますん。

>>980
先進的ですね。

そういやtemplateも例外も使ってるけど
iostreamはまともに勉強したこと無いわ

export

>>979
お前はマ板にでも行け

そろそろ次スレですよ

じゃあ次スレを0xとするか、1xとするか検討しようか。

だがちょっと待って欲しい。
8進数と2進数の立場がないのは可哀想であろう。

半年で1スレのペースだし0xでいいよ

じゃあ次スレが最後の0xだな。
次スレ最後のコメントがC++2009完成ヤホーイになることを期待して・・・

ほい次スレ
つ





･･･スレ立て規制ではじかれた(>_<)
誰かよろ

ほい
http://pc12.2ch.net/test/read.cgi/tech/1245092251/

う

め

て

い

じ

め

ん

こ

正直期待外れだった

1000ならコンセプトdeprecated逝き

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。