C++0x 11

0001デフォルトの名無しさん

2010/10/01(金) 07:04:54

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

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

前スレ: C++0x 10
http://hibari.2ch.net/test/read.cgi/tech/1275375522/

0002デフォルトの名無しさん

2010/10/01(金) 07:07:40

0003デフォルトの名無しさん

2010/10/01(金) 07:11:10

C++学園で最近話題の人々

○禿
校長先生。
現在、ヒゲは剃っている模様。
ヒゲのない校長先生のいる学校は流行らないという迷信があるため、
学園の未来のために、ヒゲ剃りを窓から投げ捨てることが期待されている。

○コンセプトさん
もはや噂すらされない伝説の幽霊。
どのような容姿だったすら、もはや誰も覚えていない

○range-based for文さん
最近、C++学園のGCC校舎に通学しているところを見かけるようになった。
しかし、全く話題に登らない影の薄い子。

○アライメントさん。
近い将来、制服が変わる予定である。
何と贅沢にも、新しくデザインされた服を支給されるらしくて大はしゃぎ。
多くの生徒から羨望のまなざしで見つめられている。

○final, override, hiding三姉妹
アライメントさんと同じく、新しくデザインされた制服を支給される予定だが、どうも服のセンスがよろしくない。
退学にこそはならないものの、今後の立ち位置が不明で、しばらく自宅待機中。

0004デフォルトの名無しさん

2010/10/01(金) 07:14:17

○ムーブさん
最近、生徒会の役員に抜擢された期待の新人。
もう単なる一生徒ではないと大いばり。

○lvalue、rvalueさん
これまで二人の姉妹と思われてきたが、
実は、lvalue、xvalue、prvalueという双子が、代わりばんこに登校していたことが、
校長先生の推理により判明。
片想いのconstなlvalueリファレンス君もこれにはびっくり。
今までxvalueさんとprvalueさんのどちらが好きだったのか戸惑っている模様。

○lvalueさん
事実判明の後も、あまり変わらず。

○rvalueさん
実は不純だった！

○xvalueさん
自分の存在を隠しつつ、こっそりと通学していた影の役者。
校長先生によって、なんだかややこしい名前をつけられてしまった。

○prvalueさん
rvalueさんとはうって変わって、ピュアな心の持ち主であると、
校長先生自ら、全校生徒の前で褒めた評判の生徒。

0005デフォルトの名無しさん

2010/10/01(金) 21:48:31

○attributeさん
最近になって任されていた仕事が次々に剥奪された。
今は死んだ魚のような目で「のーりたーん」と呟くばかり。

○deleted定義さん
その秘めた力が最近ようやく認識されるようになってきた。
彼女にはきっとスターになる素質がある。

○default定義さん
deleted定義さんと扱いに差が付き始めた。
今後の運命はムーブさんとの仲をどれほど生かせるかにかかっている。

○constexprさん
彼女の一族「定数式」の正体が掴めないと嘆く校長先生。
生徒からの人気は高いようだが、一体どうなってしまうのか…

○noexceptさん
まるでずっと昔からそこにいたかのような貫禄で、throwさんを着々と追い落としている。
急な台頭は反感を買わないか心配である。

○threadさんファミリー
相変わらず揉めているらしいが、端からは何で揉めているのかさっぱり分からない。

○Raw String Literalさん
また頭とお尻の飾りが変わりました。よかったね。

○ユーザー定義リテラルさん
私、まだいるよ。

○Blocksさん
大量のリンゴと共にときどき学園に侵入するラムダさんの親戚。
最近リンゴが豊作で調子に乗っている。

0006デフォルトの名無しさん

2010/10/01(金) 22:04:27

attributeさんは可哀そうだな

0007デフォルトの名無しさん

2010/10/01(金) 22:10:09

最近追ってなかったけど
attributeの機能が軒並みキーワード化されるのか？

0008デフォルトの名無しさん

2010/10/01(金) 22:16:21

align,final,override,hiding,base_checkがキーワード化される見込みらしい
あとはnoreturnとcarries_dependencyしか残らない

0009デフォルトの名無しさん

2010/10/01(金) 22:34:29

残りも時間の問題か

0010デフォルトの名無しさん

2010/10/01(金) 22:34:59

なんだかしらないけどぼくにはべんりになるならなんでもいいとおもう
むずかしいことはかんがえたくないからぜんぶまかせます

0011デフォルトの名無しさん

2010/10/01(金) 22:36:38

未だにこんなに変更多くて
本当に0x内に仕様固まるんだろうか

0012デフォルトの名無しさん

2010/10/01(金) 22:45:04

その他特に動きのないお馴染みの人たち

○ラムダさん
服装はすっかり見慣れ、能力の良さも知られ、さらにもっとひどい服の従姉妹が暴れているため
もはや誰も何も言わなくなった。本人は少し寂しがっている。

○右辺値参照さん
rvalueさんのゴタゴタにもかかわらず、何変わらず涼しい顔。
xvalue参照に改名することもないようだ。

○initializer_listさん
特に何も変わってないが、入学手続きが難航しているらしい。
不用意な準備で入れると大変なことになるから仕方ないのだが。

○テンプレート可変長引数さん
最近initializer_listさんと手を組んで良からぬイタズラを考えてるらしい。
この2人と__VA_ARGS__さんがつるむと色々危ないので注視したい。

○autoさん
相変わらず生徒達の絶対的な支持を受け続ける新入生のアイドル。
D組で腐ってるregisterさんが妬みを募らせているのも今まで通り。

○decltypeさん
結局、服で性格が変わる悪癖は直す気があるのだろうか。
人気者なのは間違いないが、懸念もそのまま。

○nullptrさん
通学が確認された。ただそれだけ。

○ライブラリ科の皆さん
色々細かい揉め事はあるようだが、面倒なので省略。

0013デフォルトの名無しさん

2010/10/01(金) 23:52:24

>>8
おお！それは願ったりかなったりだな。

アトリビュートってC#の[フラグ]見たいなのだろ。あんな考えなしに属性を増やせそうな仕様は弊害ばかりで障害にしかならないと思う。

0014デフォルトの名無しさん

2010/10/02(土) 00:01:48

>>12
ラムダさんはもう実装されてる処理系があるから変えにくいよね。でもだからといっても必要ならかえる勇気も必要かも。
ラムダとautoはマジ便利なんでもう散々使ってるけど、より良い仕様になるなら非互換も我慢する

decltypeの同じ式を２度書く必要になるのはどうにかならないかな。

0015デフォルトの名無しさん

2010/10/02(土) 00:21:48

先走って実装したり使用している人への配慮はしなくても良いと思うんだぜ。

2009年どころか2010年にすら仕様がまとまらなさそうだなあ。。

0016デフォルトの名無しさん

2010/10/02(土) 00:30:56

2010とかもう㍉
2011ですら怪しい

0017デフォルトの名無しさん

2010/10/02(土) 00:34:34

このすれって11スレ目なの？17スレ目なの？紛らわしくない？

0018デフォルトの名無しさん

2010/10/02(土) 00:39:29

>>17
紛らわしいけど
どっちでもいい

0019デフォルトの名無しさん

2010/10/02(土) 01:34:19

投げやりな感じがイイ

0020デフォルトの名無しさん

2010/10/02(土) 01:35:44

カンガルーが袋鼠目に分類されるみたいなもんだな

0021デフォルトの名無しさん

2010/10/02(土) 01:36:56

何を言っているのかと思ったら
0x11
に見えるってことかw

++を演算すれば
D言語の17スレ目に見えるな。

0022デフォルトの名無しさん

2010/10/02(土) 01:39:59

C++0xが2011年になるなら
Conceptさん復活できるんじゃないか。

0023デフォルトの名無しさん

2010/10/02(土) 03:58:20

むしろ、conceptをドラフトからそぎ落とすために、規格制定が当初の予定より一年遅れているんだよ。

0024デフォルトの名無しさん

2010/10/02(土) 08:27:27

それ以外のことも話し合っているように思えるんだが

0025デフォルトの名無しさん

2010/10/02(土) 08:39:05

>>22
Conceptさんは欲しかったな。
Conceptさん無しのテンプレートプログラミングはとても人に勧められたものじゃねえ。エラーメッセージの解読が難しすぎるだろう。

0026デフォルトの名無しさん

2010/10/02(土) 11:48:24

decltypeさんの括弧の有無の件は、妥当な仕様の気もするが、マクロ科との相性が最悪だよねたぶん。

0027デフォルトの名無しさん

2010/10/03(日) 12:41:41

必死になってC++0xを生み出すよりC#を機械語にコンパイルできるようにしてくれたほうが世の為だよねJK

0028デフォルトの名無しさん

2010/10/03(日) 12:56:37

ネイティブコードの需要はなくなることはないからな。
だけど、Cの腐った設計を補う機能を補う機能を補う機能を……というのが続いているような気がするので
C資産を無理なく併合できさえすればD路線の方が未来はある気がする

ただCの.hはまともな言語から見るとカオスに程があるので
やっぱりCの拡張形以外に道はない……残念ながら……

0029デフォルトの名無しさん

2010/10/03(日) 13:03:19

D言語こそ理想だけど
仕様が固まってもっと多くの人が使える様になってくれないとなぁ。
結局現実的に使えない言語は美しくても存在意義が無い。

> decltypeさんの括弧の有無の件は、妥当な仕様の気もするが、マクロ科との相性が最悪だよねたぶん。
プリプロセッサ組は、落ちこぼれだとも、最強だともいわれている、変わったクラス。
って前スレにあったけど、その通りで、プリプロセッサ組マクロ科をばりばりに使う人なら
なんとか解決できるでしょう。

0030デフォルトの名無しさん

2010/10/03(日) 13:07:31

ていうか別にDじゃなくても、1978年のModula-2とかでも
メタプログラミングができないことを除けば、D言語と比べても遜色ないだけの機能を持ってたんだけどな。

UNIXとWindowsが両方とも開発言語にCを採用してしまったのは、悪貨は良貨を……の見本だよなあ。

0031デフォルトの名無しさん

2010/10/03(日) 13:12:06

>>30
君の表現の場合、

　悪貨は良貨を駆逐する
悪化＝C言語
良貨＝他の言語

ってこと？？

0032デフォルトの名無しさん

2010/10/03(日) 13:13:58

　メタプログラミングこそ正義ィィッ！　メタプログラミングに不可能はないィィッ！

某ブログのこの言葉に現代の流行が集約されている気がする。

0033デフォルトの名無しさん

2010/10/03(日) 13:14:23

>>30
C++は実通貨
他の言語、ゲーム内通貨

0034デフォルトの名無しさん

2010/10/03(日) 13:19:19

>>31
他の言語なら何でもいいってわけじゃないよ。
ただ、C++路線で進化させるにしても、ベースになってるのがCより少しましな言語でさえあれば
?++ももう少しましになってただろう、ってぐらい。
メタプログラミングなんかはその後に生まれた概念なんで、当時の言語に求めるのは筋違いだし
広く使われるようになっていればC++同様に拡張されてただろうし。

>>33みたいなことを言う奴もいるけどさ、今のC++と比べるから現実味が無いように思えるだけで
++も無かった当時のCと他の構造化言語を比べると、差はそんなになかった。

0035デフォルトの名無しさん

2010/10/03(日) 13:30:14

禿は、オブジェクト指向とシステムプログラミングに使える言語が欲しかったわけだ。
「アセンブリを除いて、C++より低級層を挟まない」
他の言語をシステムプログラミングに対応させるより、汚いCにクラスを付け加えるほうが楽だった。

また、プログラマはどんな汚い文法でも覚える、とも言っているな。
綺麗だが目的が実現できない言語と、目的は実現できるが汚い言語なら、
汚い言語の方がマシだ。

0036デフォルトの名無しさん

2010/10/03(日) 14:01:59

いや、C++を勧める人はそう言うけどさ、実際DもModulaもそれより下はアセンブリしか低級層なんてないぞ

0037デフォルトの名無しさん

2010/10/03(日) 14:23:54

DはGCがいるよ
いなくすることも出来るけど大変だよ

0038デフォルトの名無しさん

2010/10/03(日) 14:25:31

記述レイヤを挟まない、ということではなく、ランタイムライブラリによる支援を
必要とする言語機能は却下、ではなかったか？

0039デフォルトの名無しさん

2010/10/03(日) 14:27:50

>>38
dynamic_castとかあるのにそれはない。
そもそもFPUがCPUに内蔵されるのが一般化するまでは、浮動小数点演算すらランタイムの仕事だったぞ

0040デフォルトの名無しさん

2010/10/03(日) 14:49:36

32ビットOSが一般化するまではlongの演算すら

組み込みはまた別の話だが

0041デフォルトの名無しさん

2010/10/03(日) 20:26:30

>>30
頭が幸せな発想だな

0042デフォルトの名無しさん

2010/10/03(日) 20:31:06

>>38
ランタイムライブラリが必要なのはC++も同じ。
C++はCPUの動作に直結しているのがメリットでもありデメリットでもある。

0043デフォルトの名無しさん

2010/10/03(日) 20:58:49

>>37
GCうらやましす。
GCとshared_ptrのデストラクタによる手動管理を両立させることもできるんでしょ、想像だけど。

でもなんでもいいからC++0xをまともな仕様にしてほしい。

0044デフォルトの名無しさん

2010/10/03(日) 21:11:54

>>43
そげぶ

0045デフォルトの名無しさん

2010/10/03(日) 21:25:14

そのためのscopeです

0046デフォルトの名無しさん

2010/10/03(日) 21:27:51

C#のusingとかリソース管理方法を呼ぶ側で決めるとかバグの巣窟だろうに

0047デフォルトの名無しさん

2010/10/03(日) 21:55:22

え？！

0048デフォルトの名無しさん

2010/10/04(月) 05:19:37

Dはscopeクラスにすることでscope変数にすることを強制できるからC#とは違うな

0049デフォルトの名無しさん

2010/10/04(月) 10:21:04

autoさんは中退歴があるが新入生には違いないか

0050デフォルトの名無しさん

2010/10/04(月) 12:51:13

range-based forさんって、autoさんがいればいらない子なのかな。

0051デフォルトの名無しさん

2010/10/04(月) 12:58:32

そんなことはない。しかしコンセプトさんが消えたため邪悪な子になってしまった。

0052デフォルトの名無しさん

2010/10/04(月) 15:26:59

[理想]コンセプトさんとキャッキャウフフのバラ色の学園生活！
ーーーーーーーーーーーーーーーーーーーーーーーーーーーー
[現実]もういないコンセプトさんを求め続けるあまりヤンデレ化

0053デフォルトの名無しさん

2010/10/04(月) 15:31:19

>>49
実はこの子同姓同名の別人じゃね

0054デフォルトの名無しさん

2010/10/04(月) 16:48:47

>>49
修行して最強になって返ってきたって考えればまさに王道パターン

0055デフォルトの名無しさん

2010/10/04(月) 19:34:23

コンセプトさんは結局なんでダメになったの

0056デフォルトの名無しさん

2010/10/04(月) 21:34:57

「コンセプトさんはみんなのものだ！誰でも自由にお近づきになれるんだ！」派と
「コンセプトさんはそんな尻軽じゃない！正式に告白した相手としか付き合わないんだ！」派で
職員室が戦争になったから

0057デフォルトの名無しさん

2010/10/04(月) 21:57:21

仕様が１つにまとまらなかったから外したのか
もったいなさ過ぎる

0058デフォルトの名無しさん

2010/10/04(月) 22:03:19

>>57
しかし変な仕様で固まったらそれこそC++0xの未来が本気で
閉ざされるぞ。

0059デフォルトの名無しさん

2010/10/04(月) 22:38:27

他の仕様は未だに手が入ってるし
もう2000年代に出すの諦めたというか無理だったんだから
粘っても良かった気がする

0060デフォルトの名無しさん

2010/10/04(月) 22:51:45

>>59
>もう2000年代に出すの諦めた
次はC++3000か

0061デフォルトの名無しさん

2010/10/04(月) 22:53:28

C++3000だったらどんだけ進歩しているんだろうなww

0062デフォルトの名無しさん

2010/10/04(月) 22:59:21

目的を自然言語で入力するとアプリがビルドされる

0063デフォルトの名無しさん

2010/10/04(月) 23:15:36

それってどこまで曖昧な内容で指示していいんだろうか

0064デフォルトの名無しさん

2010/10/04(月) 23:22:37

g++ -ask "それってどこまで曖昧な内容で指示していいんですか？"

って聞くとg++(ver 7849.03.827)が懇切丁寧に教えてくれる。

0065デフォルトの名無しさん

2010/10/05(火) 00:32:13

禿の人格を移植するぐらいの勢い

0066デフォルトの名無しさん

2010/10/05(火) 00:32:24

Python3000とか大した事無いよ？

0067デフォルトの名無しさん

2010/10/05(火) 01:35:03

最近VC10導入したんだがautoとunique_ptrとlambdaだけでもう全然違うな
STLのコンテナとか右辺値参照のオーバーロードで
既存のテンプレートライブラリに適合できないとかインパクトあったわ
これ本格的な移行期は大変そうだね

0068デフォルトの名無しさん

2010/10/05(火) 09:04:30

一番夢を感じるのは可変長天ぷら

0069デフォルトの名無しさん

2010/10/05(火) 16:45:16

　　　,.、,､,..,､､,..,､､,..,､､,..,､､,..,､､.,､,､､..,_　　　　　　／i
　　;'｀;、､:、. .:、. .:、. .:、. .:、. .:、:,　:,.: ::｀ﾞ:.:ﾞ:｀''':,'.´ -‐i
　　'､;: ...: ,:. : ,:. : ,:. : , :. : ,:. :.､.:',.: .:: _;.;;..; :..‐'ﾞ￣￣

0070デフォルトの名無しさん

2010/10/05(火) 16:50:57

　　　,.、,､,..,､､,..,､､,..,､､,..,､､,..,､､,..,､､,..,､､.,､,､､..,_　　　　　　／i
　　;'｀;、､:、. .:、. .:、. .:、. .:、. .:、:,　.:、. .:、:,:,.: ::｀ﾞ:.:ﾞ:｀''':,'.´ -‐i
　　'､;: ...: ,:. : ,:. : ,:. : , :. : ,:. :.､.:',.: .:: _;.;;..; :.:.､.:',.: .:: _.‐'ﾞ￣￣

0071デフォルトの名無しさん

2010/10/05(火) 17:10:51

夢あふれるな

0072デフォルトの名無しさん

2010/10/05(火) 17:27:25

>>69を書いておいて何だけとエビフライって天ぷらじゃないよね

0073デフォルトの名無しさん

2010/10/05(火) 17:31:12

ワロタw

0074デフォルトの名無しさん

2010/10/05(火) 20:13:34

そこに気づくとは…やはり天才か…

0075デフォルトの名無しさん

2010/10/05(火) 20:21:43

エビ天じゃなかったのか！

0076デフォルトの名無しさん

2010/10/05(火) 20:27:15

そろそろC++0x業務で使っていい？
今後ドカンと仕様変更されるかも…なんてことはないよね？

0077デフォルトの名無しさん

2010/10/05(火) 20:29:48

ガンガン変わってるよ

0078デフォルトの名無しさん

2010/10/05(火) 20:32:46

FCDとは一体何だったのか

0079デフォルトの名無しさん

2010/10/05(火) 21:13:59

>>78
ただのまやかしである。

もう一度0から仕様を考え直した方がいいんでないか。

0080デフォルトの名無しさん

2010/10/06(水) 01:29:58

C++ 改

0081デフォルトの名無しさん

2010/10/06(水) 01:33:24

C++Z

0082デフォルトの名無しさん

2010/10/06(水) 02:06:52

C++乙

0083デフォルトの名無しさん

2010/10/06(水) 02:36:36

最近ダイテルのC++買っちゃったけど今から始めてもまぁ良いよね・・・

0084デフォルトの名無しさん

2010/10/06(水) 03:44:48

>>78
First Committee Draft の略じゃね

0085デフォルトの名無しさん

2010/10/06(水) 13:10:45

>>84
いくつまであるんだーーーwww

>>83
ダイテルってなぁに？

0086デフォルトの名無しさん

2010/10/06(水) 20:21:27

Deitel一族

0087デフォルトの名無しさん

2010/10/06(水) 20:46:52

http://www.amazon.co.jp/C-%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E3%80%88Vol-1%E3%80%89-Computer-Science-Textbook/dp/489471115X/ref=sr_1_3?s=books&ie=UTF8&qid=1286365594&sr=1-3

0088デフォルトの名無しさん

2010/10/06(水) 21:05:19

大照さん

0089デフォルトの名無しさん

2010/10/06(水) 23:12:31

>>87
どうせ暫く仕様固まらないからその間に勉強したら良いだろ。

0090デフォルトの名無しさん

2010/10/07(木) 02:35:29

>>87
良書

0091デフォルトの名無しさん

2010/10/11(月) 12:16:42

usingをスコープ付きのエイリアスみたいな機能にすれば便利なのに

0092デフォルトの名無しさん

2010/10/11(月) 12:17:48

>>91
参照との違いは？

0093デフォルトの名無しさん

2010/10/11(月) 13:11:25

余計なポインタ持たなくていいじゃない

0094デフォルトの名無しさん

2010/10/11(月) 13:17:05

>>93
参照≠ポインタ

0095デフォルトの名無しさん

2010/10/11(月) 13:35:57

そりゃ言語仕様上はそうでも、実装する時は結局何か指し示すもの渡さないといけないだろ
結局ポインタだよ

0096デフォルトの名無しさん

2010/10/11(月) 13:43:24

必ずしもポインタを介する必要が無いし、ポインタ必須の箇所ではusingは使えないし

0097デフォルトの名無しさん

2010/10/11(月) 14:07:52

何の話よ？usingは参照ともポインタとも全く違うだろ
異次元にあるものをごっちゃにするな

0098デフォルトの名無しさん

2010/10/11(月) 14:25:15

だいたい、どのusingだよ？
usingキーワードを使う文法はみっつもあるぞ。

0099デフォルトの名無しさん

2010/10/11(月) 14:38:18

typedefで事足りるんじゃないの

0100デフォルトの名無しさん

2010/10/11(月) 16:31:44

typedefじゃ関数や変数やテンプレートの別名がつけられない
参照やポインタではコストがかかるかもしれない
マクロは安全性に犠牲がでる
一番良いのはマクロと同じ機能をプリプロセスではなく言語でサポートしてスコープの概念を付け加えること

0101デフォルトの名無しさん

2010/10/11(月) 17:46:52

そんなのがあると今度はtypedefがいらなくなるなw

0102デフォルトの名無しさん

2010/10/11(月) 19:20:32

using template とは違うんだよね?
必要になる場面が思いつかないな

0103デフォルトの名無しさん

2010/10/11(月) 20:02:24

いや、D言語ではなんでもかんでもaliasで別名作れるんだけど、確かにすごい便利だぞ。
恐らくC++に導入されても、usingやらtypedefやら参照やらを一掃する勢いになる。
実際Dではtypedefが消滅した。

0104デフォルトの名無しさん

2010/10/11(月) 20:06:33

C++ 0x FAQにunique_ptrははいかなる形の動的チェックも提供しないってあるけど
auto_ptrやscoped_ptrと同じで動的削除子がないって理解でいいのかな？
pimplで試したら、デストラクタを定義しないとコンパイルできなかった

0105デフォルトの名無しさん

2010/10/11(月) 20:15:33

std::smart_ptrのような動的なデリーターはないね。
テンプレート実引数として指定する、静的なデリーターならあるけど。

0106デフォルトの名無しさん

2010/10/11(月) 20:27:25

std::smart_ptrってどこのパチモンだよ

0107デフォルトの名無しさん

2010/10/11(月) 20:34:52

>>105
ありがとうございます
以前どっかのスレで動的削除子があるような書き込みがあったので
一応確認してみました

0108デフォルトの名無しさん

2010/10/11(月) 21:01:35

[.hpp]
class Handle
{
private:
class Body;
unique_ptr<Body, function<void(Body*)>> pimpl;
public:
Handle(void);
};
-------
[.cpp]
Handle::Handle(void) : pimpl(new Body, Deleter<Body>())
{
}

なんということでしょう！

0109デフォルトの名無しさん

2010/10/11(月) 21:19:52

shared_ptrだったｗ

0110デフォルトの名無しさん

2010/10/11(月) 22:41:03

ttp://ja.wikipedia.org/wiki/C%2B%2B0x
> ...演算子を型名の左側におく場合、これは"pack"演算子
> ...演算子が型名の左側にある場合は、"unpack"演算子

これ、両方*左側*になってるんだけど、
まちがいだよね？

0111デフォルトの名無しさん

2010/10/11(月) 22:47:19

wikipediaの情報は大抵間違っているから信用するな。
とくに、日本語版は最悪で、暇人の自治厨が仕切っているからな。

0112デフォルトの名無しさん

2010/10/11(月) 23:00:32

プログラム関係はそもそも過疎っているので、あんまり自治厨は見かけない気がする。
もちろん、大抵間違っていることは変わりない。過疎、つまり直す人もいないということでもある。

0113デフォルトの名無しさん

2010/10/11(月) 23:27:32

>>111
あそこは事実や真実より声の大きい奴が勝つ場所だからどもならん

0114110

2010/10/11(月) 23:43:25

>>110 に書いたページを、結構、楽しく読んでから来てみれば
>>111-113 こんな書き込みw

じゃ、ほっとくか。

今、C++ 勉強してるんですが、
wikipedia の C++0xのページで触れられていることが、
100%嘘って事も無いと仮定すると、C++0xがでると、
プログラムの書き方が、かなり変わってくるんでしょうか？

で、Effective C++ 第4版を、読むことになると。

0115デフォルトの名無しさん

2010/10/12(火) 00:08:53

C++0xみたいなやつの場合、書いた時点では正しくても、
その後の変化に記事が追いついていないということもよくある。

それにしても、あの記事よく楽しく読めるね。
直訳調で、自分なんか読むのに疲れてくるんだけど。

まあ個々の内容はともかく、C++0xの記事の目次にある事柄自体は
だいたい本当なので、C++0xの新機能をばんばん使ったらかなり変わってくるだろうことは間違いない。

0116デフォルトの名無しさん

2010/10/12(火) 00:43:32

>>114
＞プログラムの書き方が、かなり変わってくるんでしょうか？
パラダイムシフトするかっていう意味なら変わらないと思う、ただ新しい書き方を適用可能になるのでより意図を伝えやすくなるコードを書けるようになる
なのでプログラマの意識次第だと思うぞ

0117デフォルトの名無しさん

2010/10/12(火) 00:55:01

また新しい定石みたいなもんが増えんのかねめんどくさい

0118110

2010/10/12(火) 01:41:33

レス、どうも。

>>115
> それにしても、あの記事よく楽しく読めるね。

新しい機能について、「うへぇー、こんな表記認めるんだー」
とか、いう感じで読んでるんで、表現は気にならないです。

ちょっと前に boost regex とか見て、正規表現リテラルが無いことを知ったから、
それが、raw って仕組みで解決されてるとことか…、
その他色々、ちょうど個人的にタイムリーで

>> 116
> パラダイムシフトするかっていう意味なら変わらないと思う

C++(とC)の、面倒くさいと言われている事の一つ、メモリ管理が、
shared_ptr とか、unique_ptr とかで簡単になるとして、
auto とかの表記を使って、型指定する面倒くささを軽減出来たら、
スクリプト言語並とは言わないまでも、ぐっと使いやすくなって、
楽チンになるのかなぁーと。

確かD言語は、スクリプト的にも使えるようになってたし、
C++0xのページに GC の事に触れられていたから、
ガラッと変わってくるのかと、期待と不安で質問してみました。

>>117
> で、Effective C++ 第4版を、読むことになると。

0119デフォルトの名無しさん

2010/10/12(火) 02:30:58

Effective C++0xか
そろそろ常人には手がつけられなくなりそうな

0120デフォルトの名無しさん

2010/10/12(火) 03:05:55

もうすでに…
ここまでついてきてる奴には、さほど問題なかろう。

しかし、自分が今から０から学ぶとか考えたらぞっとするなーw

0121デフォルトの名無しさん

2010/10/12(火) 09:03:51

ウィキペディアは間違ってたら直せよ。

直しても基地外が間違った状態に戻すようだったら文句言えよ。
俺の経験では10%もないぞそういうことは。

0122デフォルトの名無しさん

2010/10/12(火) 09:08:50

憂国の戦場な記事以外はだいたいあってるよな

0123デフォルトの名無しさん

2010/10/12(火) 12:08:06

直そうにも、現状で多くのISPのIPは、自治厨によって永久にBANされている。
ログインしない限り書き込めない。
しかし、アカウントを作るためには、BANされていないIPが必要。

こんな態度のWikipediaに、わざわざ一手間かけてアカウントを作ってまで、直してやる義理もない。

0124デフォルトの名無しさん

2010/10/12(火) 12:22:10

お前どんな悪行を働いたんだ……

0125デフォルトの名無しさん

2010/10/12(火) 12:44:42

>>124
俺じゃねーよ。
同じISPを使っている（使っていた）誰かだよ。

0126デフォルトの名無しさん

2010/10/12(火) 15:19:09

ムーブさんの立場が微妙なことに……
http://cpp-next.com/archive/2010/10/implicit-move-must%c2%a0go/

0127デフォルトの名無しさん

2010/10/12(火) 16:21:53

C++学園の黒歴史の面々

○禿
校長先生。
かつては、校舎の設計と建築に加えて、カリキュラムの構築までもこなし、さらには自身で教鞭をもとった。
しかし、最近、校舎の建築はしていない模様。

○ムーブさん
最近、正式に生徒会の役人に選ばれて有頂天になっていたが、
上級生の反発により、暗黙的な権限が大幅に制限される模様。
「互換性なんてクソだ」とつぶやいているとか。

○asm宣言校舎
C++学園創立の時、asm宣言の実習のために、急遽建てられたプレハブ小屋。
あまりに使い勝手が悪いので、誰からも使われることがなく放置されている開かずの校舎となっている。
かわりに、独自の校舎が乱立している。

○動的例外指定さん
自宅謹慎処分は受けていないものの、だいぶ教室のすみっこに追いやられた。

○exportさん
退学

○文字列リテラルに対するconst性を取り除く標準型変換の校則
生徒会による投票により、削除された。

○リンケージ指定事務員
広く他の学校と姉妹提携を結ぶという業務内容を担っていたが、C言語学園以外との姉妹提携は結ばれなかった。

○range-based forさん
いまだに話題に登らない影の人。
conceptさん亡き今となっては、不遇である。

0128デフォルトの名無しさん

2010/10/12(火) 16:29:48

暗黙のコピー「暗黙のムーブがやられたようだな」
暗黙のデフォコン「ククク…奴は四暗黙の中でも最弱…」
標準型変換「互換性ごときに負けるとは暗黙界の面汚しよ…」

0129デフォルトの名無しさん

2010/10/12(火) 17:12:52

>>128
そりゃあ、創立メンバーの3人と比べりゃなｗ

0130デフォルトの名無しさん

2010/10/12(火) 17:22:02

暗黙のデストラクタ「……」

0131デフォルトの名無しさん

2010/10/12(火) 18:00:16

暗黙なんて何一つ要らない

0132デフォルトの名無しさん

2010/10/12(火) 18:40:45

昔は俺もそう思ってたけど、暗黙のコピーコンストラクタ、代入演算子を積極的に使うように変わってきた。

0133デフォルトの名無しさん

2010/10/12(火) 18:44:58

演算子って暗黙の関数呼び出しですか？

0134デフォルトの名無しさん

2010/10/12(火) 18:45:02

暗黙のコピーコストラクターがないと・・・

struct S
{
int a001, a002, a003, ... a999 ;
S( S const & s ) : a001(s.a001), a002(s.a002), a003(s.a003), ... a999(s.a999) { }
} ;

0135デフォルトの名無しさん

2010/10/12(火) 18:57:12

そんな糞構造体を書くプログラマは暗黙のうちに解雇して良い

0136デフォルトの名無しさん

2010/10/12(火) 19:14:52

>>134
うわぁ…

0137デフォルトの名無しさん

2010/10/12(火) 19:41:55

>>134
ステキな例

0138デフォルトの名無しさん

2010/10/12(火) 19:42:48

>>134
ちなみにboost.preprocessorライブラリでそれを書けば
暗黙のコピーコストラクターがなくても
もっと簡単に記述できるのかな、と。

0139デフォルトの名無しさん

2010/10/12(火) 19:52:15

暗黙コピコンがないとCの構造体コピーがコンパイル通らないだろ
これも互換性のための汚い仕様

0140デフォルトの名無しさん

2010/10/12(火) 20:01:15

暗黙のコピーコンストラクターが無かったら、全てのメンバー変数をコピーするコードを間違えないように書かなくちゃならないじゃないか
メンバー増やしたときに追加忘れすると面倒なバグになるじゃないか

0141デフォルトの名無しさん

2010/10/12(火) 20:04:25

>>140
うわぁ

0142デフォルトの名無しさん

2010/10/12(火) 20:21:06

デフォルトコピーコンストラクタで、メンバ変数のコピーコンストラクターが自動的に呼ばれるけど違った？

0143デフォルトの名無しさん

2010/10/12(火) 20:34:57

>>140
面倒か？
コンパイルエラーになるだけなら大したことないと思うが

0144デフォルトの名無しさん

2010/10/12(火) 20:38:41

初期化子書き漏らししてもエラーになら無い場合があるし

0145デフォルトの名無しさん

2010/10/12(火) 22:05:53

現状の暗黙のコピーコンストラクタと同等の物を明示的に作成する構文があればいいんだろ。
俺はそんな物を作るくらいならコピーコンストラクタの自動生成でいいと思うけど。

0146デフォルトの名無しさん

2010/10/12(火) 22:10:50

default定義さん「……」

0147デフォルトの名無しさん

2010/10/12(火) 22:12:04

=defaultって毎回書くのめんどいから
class Hoge
{
public:
default{
Hoge();
Hoge(const Hoge &);
Hoge(Hoge &&);
}
};
これ通るようにするべき

0148デフォルトの名無しさん

2010/10/12(火) 22:14:04

default定義でググるとSQLのCREATE TABLE文ばっかりヒットするしなあ……

0149デフォルトの名無しさん

2010/10/12(火) 22:15:13

virtual foo() = 0; って毎回書くのめんどいから(ry

0150デフォルトの名無しさん

2010/10/12(火) 22:16:14

>>146
いやあごめんごめん。コンストラクタさんとも仲良しってことをすっかり忘れてたよ。

0151デフォルトの名無しさん

2010/10/12(火) 22:17:54

>>149
class Hoge
{
public:
virtual {
void foo();
void bar();
void baz();
} = 0;
};
最高にクールだな

0152デフォルトの名無しさん

2010/10/12(火) 22:20:39

そんなことよりなんでラムダ式に呼び出し規約を指定できないんだよ。
C#みたいにラムダをコールバック関数として使いたいのに。
しょうもないコールバックのためにわざわざ非メンバ関数やグローバル変数を
定義するのはいやだお。

0153デフォルトの名無しさん

2010/10/12(火) 22:43:03

>>152
ラムダ式は関数じゃなくて関数オブジェクトだから呼び出し規約はないだろう

0154デフォルトの名無しさん

2010/10/12(火) 22:46:16

関ポに出来るなら関ポになるんじゃなかったっけ

0155デフォルトの名無しさん

2010/10/12(火) 22:46:54

呼び出し規約？
MSVCにおける__stdcallとかか？
そんな規格外のことを言われてもな。
規格的にいえば、attributeで実装して欲しいところだが、
規格を守る気のないMSがやるかなぁ？

0156デフォルトの名無しさん

2010/10/12(火) 22:47:46

>>153
一応、何もキャプチャーしてないと、単なる関数ポインターに変換可能。

0157デフォルトの名無しさん

2010/10/12(火) 22:51:53

まずは、API関数をラップして、好きなファンクションオブジェクトを引数に取れるラッパを作ればいい。
そしたら、ラムダ式でも何でも渡し放題だ。
ってのをWinSTLとかやっていないかなあ？

0158デフォルトの名無しさん

2010/10/12(火) 23:09:11

gccのトランポリンは外のローカル変数に触ってても普通にstdcallでコールバックできるし、clangのblocksとかもあるし
ラムダめいたことに関してはC言語の独自拡張の方がC++よりもずっと進んでる

0159デフォルトの名無しさん

2010/10/12(火) 23:11:47

独自拡張は独自拡張でしかないからなぁ…
一生窓やリンゴだけ食って生きてく覚悟があればいいんだろうけど

0160デフォルトの名無しさん

2010/10/12(火) 23:14:07

blocksはちょっと色々とアレなとこが・・・

0161デフォルトの名無しさん

2010/10/13(水) 01:52:43

>>158
トランポリンはスタック全部に実行可能属性が付く気持ち悪い仕様

0162デフォルトの名無しさん

2010/10/13(水) 02:13:09

Windowsでは、呼び出し規約が統一された64bitコードにさっさと移行しろってことだろ。
まあ、それが出来れば苦労しないんだろうがな。

0163デフォルトの名無しさん

2010/10/13(水) 05:44:06

呼び出し規約自体独自拡張なんだから、
[](int x) [[ __stdcall ]] -> { return x; } みたいに
attribute さんに仕事をあげればいいのに

0164デフォルトの名無しさん

2010/10/14(木) 01:59:52

気持ち悪さに磨きかかっちゃってる・・・

0165デフォルトの名無しさん

2010/10/14(木) 03:01:37

どうせならラムダの最初の[]の中にattributeを書くようにすればいいのに……。

0166デフォルトの名無しさん

2010/10/14(木) 04:20:16

同名の変数が有ったらどうすんだよ

0167デフォルトの名無しさん

2010/10/14(木) 07:45:34

class Hoge
{
public:
　const {
　　void foo();
　　void bar();
　　void baz();
　};
};

0168デフォルトの名無しさん

2010/10/14(木) 11:36:19

class Hoge
{
public:
　const {
　　void {
　　　{ foo, bar, baz }();
　　}
}
};

0169デフォルトの名無しさん

2010/10/14(木) 18:13:56

>>166

[[[ __stdcall ]]](int x) { return x; }

0170デフォルトの名無しさん

2010/10/14(木) 20:14:27

キモさに磨きがかかるな

0171デフォルトの名無しさん

2010/10/14(木) 20:49:15

>>168
便利すぎてやばいな
これ考えたやつは天才だと思う

0172デフォルトの名無しさん

2010/10/14(木) 20:51:01

>>167
ってOKなの？

0173デフォルトの名無しさん

2010/10/15(金) 07:24:12

いや夢語りだろう。

0174デフォルトの名無しさん

2010/10/16(土) 19:29:55

VBのWithに通じるクソっぷりを感じる

0175デフォルトの名無しさん

2010/10/16(土) 20:52:23

>>174
何行も前を確認しないと関数の定義がわからないとか駄目すぎるね。

0176デフォルトの名無しさん

2010/10/16(土) 21:13:15

何行も前を確認しないと関数のアクセスレベルがわからないなんて……

0177デフォルトの名無しさん

2010/10/16(土) 21:36:54

class Hoge
{
public virtual Hoge const & { foo, bar, baz } (void) const throw() = 0;
};

う、美しい。。。

0178デフォルトの名無しさん

2010/10/16(土) 21:37:50

何行も前を確認しないとクラスの名前がわからないなんて……

0179デフォルトの名無しさん

2010/10/16(土) 21:46:34

C#みたいに全メンバにアクセス修飾子がついたクラスなら見たことがある。

0180デフォルトの名無しさん

2010/10/16(土) 21:47:42

それはメンバの再配置期待してるんだろ
たまにやるよ

0181デフォルトの名無しさん

2010/10/16(土) 21:53:00

メンバのre-orderしてくれんなら俺もやろうかな

0182デフォルトの名無しさん

2010/10/16(土) 22:54:22

他はともかく、staticだけはpublic:なんかと同類でグループ指定にしたほうが分かりやすい気はするな

0183デフォルトの名無しさん

2010/10/17(日) 09:03:47

メンバの再配置って class A { public: char a; public: int b; public: char c; };
のメンバが b,a,c の順にメモリに並んでくれるのかと思ったけど、そうじゃないね。

0184デフォルトの名無しさん

2010/10/17(日) 10:04:52

>>183
PODにすれば記述順配置になるんじゃなかった？

0185デフォルトの名無しさん

2010/10/17(日) 12:09:51

別にPODでなくても、publicなメンバ同士、protectedなメンバ同士、private:なメンバ同士は
それぞれ記述順に配置される

0186デフォルトの名無しさん

2010/10/17(日) 16:12:35

あれ、記述順になるのは同じラベルじゃなかったっけ
class A { public: char a,b; private: char c,d; protected: char e; public: int f;};
ならaがbの後、cがdの後、それ以外はunspecified（なので親切なコンパイラなら再配置してくれるかもしれない）
例えばf,a,c,b,e,dとかの順でもいい
PODは全メンバのアクセス指定が同じという条件があるので記述順になる

だと思ってたけど規格見るとはっきりしないな
same access controlなら記述順とは書いてるけど（N3126の9.2-13）
"access control"とは何なのかハッキリ定義されてないからどっちにも読める

0187デフォルトの名無しさん

2010/10/17(日) 18:08:48

なるほど。the same access control って、
(a,b,f) (c,d) (e) が同じって意味だと思ってたけど
(a,b) と (f) は違うって解釈もできるのね…

0188デフォルトの名無しさん

2010/10/18(月) 22:26:36

これ↓を見ると
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2172.html

9.2 ¶12 Class members [class.mem]
Nonstatic data members of a (non-union) class
<del>declared without an intervening access-specifier</del>
<ins>with the same access control (clause 11)</ins>
are allocated so that later members have higher addresses within a class object.

となっているから、
　class A { public: char a; public: int b; public: char c; };
の a, b, c は、このときまでは並べ替えてよかったけど、
今は並べ替えてはいけなくなったようだ。(ついでにPODになった)

0189デフォルトの名無しさん

2010/10/18(月) 22:45:34

ですよねー。。。

0190デフォルトの名無しさん

2010/10/18(月) 23:48:46

なんだダメになってたのか
それにしても修正入れた割には曖昧な文言だな

0191デフォルトの名無しさん

2010/10/18(月) 23:59:22

最適化するしないで互換性が無くなるクラスとか有ったら死ねる

0192デフォルトの名無しさん

2010/10/19(火) 11:10:46

というか配置順変えていた実装あるんかいな。

0193デフォルトの名無しさん

2010/10/19(火) 15:30:28

sunのコンパイラが宣言と逆順に配置してたよ

0194デフォルトの名無しさん

2010/10/20(水) 04:50:52

若干スレ違いな感じもしますが、新しい規格ということで・・・

C99のfenv.hあるいはC++0xのcfenv
のマニュアルはたくさんあるのですが、具体例がなかなか見つかりません。
英語でも書籍でもいいので、ご存知の方いらっしゃいませんか？

try catchと連携させて
double x = 1.0/10;
try {
fetestexcept(FE_ALL_EXCEPT);
x = sqrt(-x);
if (fetestexcept(FE_ALL_EXCEPT)) throw runtime_error("fpe exception!");
} catch (const runtime_error& e) {
cerr << e.what() << endl;
exit(-1);
}
こんな感じで使いたいのですが、いかんせん自己流で自信ないのです。
#define _GNU_SOURCE
は必要ないのか？とか、環境依存性は？とか、色々気になります。

0195デフォルトの名無しさん

2010/10/20(水) 05:04:29

>>194
なんで _GNU なんてついたマクロが必要かもしれないなんて思うのか、わからない。
「環境依存性は？」と言われても仕様を見たとおり、としか言えない。

何か気に入らないところがあるとか、具体的な不満や要件を挙げてもらわないと、
話にならないね。

「自己流で自信が無い」と言うが、ここで名無しさんが何か言ってくれたら自信が付くわけ
でもないだろう。

0196194

2010/10/20(水) 05:35:57

ttp://linux.die.net/man/3/fenv
とかを見ると、細かい設定をglibc拡張でやれるって話みたいでした。
色々混乱しててすみません。

C99とか0xの範囲なら環境依存するはずないですよね。

0197デフォルトの名無しさん

2010/10/20(水) 21:57:29

ムーブさん先行き不安だな…

0198デフォルトの名無しさん

2010/10/20(水) 22:59:21

moveは仕様をきっちり作り込むのが難しいよね。

0199デフォルトの名無しさん

2010/10/20(水) 23:11:49

ムーブさんはコンセプトさんと似たような泥沼に入りかけてる気がしてならない

0200デフォルトの名無しさん

2010/10/20(水) 23:32:13

コンセプトさんが憑いたのか

0201デフォルトの名無しさん

2010/10/21(木) 04:22:42

右辺値参照さんまさかの入学取り消しあるで

0202デフォルトの名無しさん

2010/10/21(木) 12:08:14

内定取り消しか…胸が熱…(´;ω;)ｳｯ

0203デフォルトの名無しさん

2010/10/21(木) 15:12:05

右辺値さんmixiで調子乗ってなんかやらかしたんだってさ

0204デフォルトの名無しさん

2010/10/21(木) 19:52:22

おまえら全員留年な

0205デフォルトの名無しさん

2010/10/22(金) 08:17:45

>>201
詳細求む

0206デフォルトの名無しさん

2010/10/23(土) 14:36:01

デフォルトムーブコンストラクタの件じゃないのか？うまく折り合いをつけて採用してほしいところ。

いまさら右辺値さん取り消したら、unique_ptrさんも道連れだよ。
unique_ptrさんマジ便利。いまさらなくせないだろう。

0207デフォルトの名無しさん

2010/10/23(土) 15:57:02

range-based for文さんを道連れに消えていったコンセプトって子がおってな

0208デフォルトの名無しさん

2010/10/23(土) 16:32:37

【スキャンダル】入学審査で不正疑惑が【椿事】

0209デフォルトの名無しさん

2010/10/23(土) 17:14:43

>>207
あたらしい転校生のBOOST_FOREACHさん。,さんが苦手。

0210デフォルトの名無しさん

2010/10/23(土) 19:57:52

というか、range-based forいらねーよ。
その次の規格でconceptと一緒に入れてくれよ。

0211デフォルトの名無しさん

2010/10/24(日) 13:50:19

そうか？
使ってみると、意外と便利だぞ。
まあ確かに、今のような糞なイテレート方式じゃなくて、concept使って欲しかったところだが。

0212デフォルトの名無しさん

2010/10/24(日) 13:55:55

range based forぐらい自分でパチもん実装できるからいいじゃん
つーかboostもあるし

0213デフォルトの名無しさん

2010/10/24(日) 14:07:26

そんなこと言ってたらC++0xが要らなくなるだろ

0214デフォルトの名無しさん

2010/10/24(日) 14:11:00

polymorphic lambdaがない以上、以下のコードがうまくいかないんだよな。

std::vector<int>v = { 1, 2, 3 } ;
for ( auto i : v ) { }

0215デフォルトの名無しさん

2010/10/24(日) 14:18:01

どううまくいかないの?
一見して問題なさそうだけど。
実際、gcc4.6 ではエラーにならない。

0216214

2010/10/24(日) 14:26:36

いや、ちがうちがう。
パチもんが実装できないということ。

0217デフォルトの名無しさん

2010/10/24(日) 15:37:59

range-based forって一つの書き方で多くの範囲オブジェクトをカバーできるところが大きな魅力になってるの？
俺はよく使うコンテナクラスにそれぞれ特化したforを定義して使ってるんだけど

0218デフォルトの名無しさん

2010/10/24(日) 15:55:39

>>217

vector<int> v;
int s=0;
for(vector<int>::iterator i=v.begin();i!=v.end();++i)
s+=*i;

が

vector<int> v;
int s=0;
for(int x:v)
s+=x;

になるんだぜ。これは欲しいな。

あとBOOST_FOREACHで同じよことができるし、autoも使えるし

0219デフォルトの名無しさん

2010/10/24(日) 16:31:44

>>218
いいな
俺はvから元クラス参照でそこから::iteratorでもいいんだけどね
要するに元の宣言vector<int> をvからひきだしたいだけなんだけど
コードの中にtypdef宣言いれないでmapとかの長い宣言作ると::iteratorの書式が長くて嫌いなんだよね

0220デフォルトの名無しさん

2010/10/24(日) 16:51:47

>>219
auto使えばいいんじゃね？

0221デフォルトの名無しさん

2010/10/24(日) 19:04:44

理想は>>218がこうなればいいんだけどな
int s = std::accumulate(v, 0);

0222デフォルトの名無しさん

2010/10/24(日) 19:13:44

>>220
foreach(auto x:v){}
だな。
BOOST_FOREACH(auto x,v){}
でもOK
>>221
boost::range や Ovenがそれの役目だな。

0223デフォルトの名無しさん

2010/10/24(日) 19:56:57

標準ライブラリのコンセプト対応で可能になるはずだったのにね・・・

0224デフォルトの名無しさん

2010/10/24(日) 20:04:43

おまいらには、頭が下がります.
物覚えが良くないので, 0x の変態構文にはもうついていけんわ
# つか, テンプラの時から思ってたんだが,
# lisp の ` と , を知ると何とか整理してくれやぁ！！！になる

0225デフォルトの名無しさん

2010/10/24(日) 20:09:39

>>223
コンセプトがあればエラーメッセージがまだ判りやすくなるのにな。
意味不明のエラーメッセージは新規ユーザにとってかなりハードル高いな。
boost conceptcheckでもかなり改善になるから採用されないかな。

0226デフォルトの名無しさん

2010/10/24(日) 20:11:13

>>224
いえいえ、御代官様の括弧式ほどでは。ふっふっふ

0227デフォルトの名無しさん

2010/10/24(日) 23:33:55

禿げよ。

xrvalueとかprvalueとかもういいかげんにしてくれる？
みんな、お前ほど賢くないんだから話を複雑にしないでくれ。

ただでさえ、C++は複雑で、経験が少ない社員が含まれる
プロジェクト開発では敬遠されるのに。それでjavaやC#が
流行ったのに。

まったく、学習してないんだな、このタコは。

みなはお前みたいに言語を趣味にしてるんじゃないぞ。

0228デフォルトの名無しさん

2010/10/24(日) 23:42:44

xrvalue → xvalue

0229デフォルトの名無しさん

2010/10/24(日) 23:55:02

>>227
互換性を無視していいなら、同等以上の機能を遥かにシンプルに定義できるっしょ。
xvalueも、規格の文面を全面書き換えするのを避けた結果なんだっけ？

0230デフォルトの名無しさん

2010/10/25(月) 09:59:31

禿曰く、

いまさらlvalue、rvalueといった用語を廃止するわけには行かない。
この用語は、1950年代から使われていたのだから。

そもそも、値というものには、二つの意味がある

・ユーザーが識別可能であるかどうか
識別可能というのは、具体的な変数名が付いていたり、アドレスが与えられていたりすること。
識別不可能というのは、関数の戻り値などの一時オブジェクト。

・ムーブできるかどうか

この二種類を組み合わせると、
・識別可能でムーブ可能：xvalue
・識別可能でムーブ不可能：lvalue
・識別不可能でムーブ可能：prvalue
・識別不可能でムーブ不可能：該当なし

という四種類の値が出来上がる。
このうち、「識別不可能でムーブ不可能」という値は、C++においては、意味が無い。
そういうわけで、C++における根本的な値は、三種類ある。
その値に名前を割り振ったわけだ。

0231デフォルトの名無しさん

2010/10/25(月) 13:01:11

for(vector<int>::iterator i=v.begin();i!=v.end();++i)
は auto さんがいたら
for(auto i=v.begin();i!=v.end();++i)
と書けるわけで、ことさら range-based for さんを導入する動機が
やっぱりわからん

0232デフォルトの名無しさん

2010/10/25(月) 13:32:01

beginとendと*itを書く事すらめんどくさいから

0233デフォルトの名無しさん

2010/10/25(月) 13:32:37

あとはアダプタ噛ませるときに便利だから

0234デフォルトの名無しさん

2010/10/25(月) 19:10:38

>>230
例えばxvalue, lvalue, prvalueには具体的にそれぞれどんなものが該当するの？

0235デフォルトの名無しさん

2010/10/25(月) 20:11:01

>>231
配列だと .begin() とか書けないから

0236デフォルトの名無しさん

2010/10/25(月) 21:10:36

さすがに右辺値と左辺値の区別くらいはついてないと、コンパイルエラーも読めないんじゃないか？

0237デフォルトの名無しさん

2010/10/25(月) 21:16:54

lvalueは今まで通りのlvalue
prvalueは今まで通りのrvalue
xvalueは右辺値参照のこと

使う時はこれくらいの理解でおｋ

0238デフォルトの名無しさん

2010/10/25(月) 21:36:13

lやrまではまだいいとして、pとかxとかわかんねえだろ
分かりやすくするという気はないのかね？

0239デフォルトの名無しさん

2010/10/25(月) 21:43:57

お前がわかりやすい名称を提案すればいいんじゃないかな？

0240デフォルトの名無しさん

2010/10/25(月) 21:57:11

省略するからだめなんだよ

0241デフォルトの名無しさん

2010/10/25(月) 22:02:00

prvalueって見た目通りpointer rvalueなんすか？

0242デフォルトの名無しさん

2010/10/25(月) 22:02:34

pureだろう

0243デフォルトの名無しさん

2010/10/25(月) 23:34:26

「ムーブ可能」ってどういうこと？定義あるの？

処理前のオブジェクトの束縛が、処理後に無くなっても問題ないってことでおｋ？

0244デフォルトの名無しさん

2010/10/25(月) 23:39:32

>>238
名前がどうのこうの言う前に概念理解してないだろ。
素直になれ。名前なんて単なる名前だ。酷い命名でもないし。

0245デフォルトの名無しさん

2010/10/26(火) 00:02:22

>>243
もう必要ないから中身を好きなようにぶち壊してよい物体のこと

0246デフォルトの名無しさん

2010/10/26(火) 00:03:24

>>244の書いたコードが見てみたいな

0247デフォルトの名無しさん

2010/10/26(火) 05:42:21

>>234
lvalueはC++03から何も変わらない。
名前のついている変数やポインターのdereferenceやリファレンスなど。
rvalueリファレンスの変数も、もちろんlvalueとなる。
lvalueは、安全にムーブできない（ユーザーがどのように使うか分からないため）

prvalue(pure rvalue)は、主に一時オブジェクト。
名前がなく、ストレージが確保されている保証もない値。
リファレンス型以外の関数の戻り値とかがこれに該当する。
prvalueは、安全にムーブできる（ユーザーは自由に利用できないため）

xvalue(eXpiring value)は、ユーザーが意図的に作り出すもの。
つまり、lvalueやprvalueを、ユーザーが意図的にxvalueにキャストして、ムーブ可能であることを示す。
static_cast<T &&>(t)や、関数の戻り値の型がrvalueリファレンスの場合、xvalueとなる。

ほかにも、return文でローカル変数をオペランドに渡したときとか、暗黙にムーブが発生することとかがある。

>>244
内部で動的に確保した、何らかのリソースをぶんどってもよいかどうか。
コピー先のオブジェクトが、コピー元を使えない状態にしてもいいかどうか。
std::auto_ptrのようなもの。auto_ptrの場合、コピー後、コピー元は妥当なポインターを持たなくなる。
rvalueリファレンスができたおかげで、auto_ptrはめでたくdeprecatedになったけど。

0248デフォルトの名無しさん

2010/10/26(火) 06:41:16

>>231
autoって大昔のcのころの機能イメージがあってちょっとコードみててもにょるのが難点

0249デフォルトの名無しさん

2010/10/26(火) 11:14:46

>>247

>prvalue(pure rvalue)は、主に一時オブジェクト。
>名前がなく、ストレージが確保されている保証もない値。
>リファレンス型以外の関数の戻り値とかがこれに該当する。
>prvalueは、安全にムーブできる（ユーザーは自由に利用できないため）

こめん、上の2行目と4行目の記述が矛盾しているように見える。
｢ストレージが確保されている保証もない値｣なら｢安全にムーブ｣でき
ないと思うけど。

｢ストレージが確保されている保証もない｣が｢メモリが、名前のある
ポインタ変数によって管理されていない｣という意味ならわからんでも
ないが。

｢Move(移動)｣とは、右辺値オブジェクト(一時オブジェクト)が(そのデータ
メンバであるポインタを通して)管理している動的メモリを、左辺値オブジ
ェクトが管理している動的メモリとswapすることだと勝手に解釈してたけど、
これって間違い？

両者の動的メモリのアドレスをswapすれば、メモリのコピーも必要ないし、
右辺値オブジェクトはどうせ破壊されるから問題ないと思ってたけど。

0250デフォルトの名無しさん

2010/10/26(火) 11:26:20

int x = 0 ; int y = 0 ;
int z = x + y ;

ここで、x + yという式を評価した場合、その結果を表す一時オブジェクトが生成されるが、
この一時オブジェクトは、具体的なストレージを持たなくてもよい。

ただし、xvalueにされたときは、具体的なストレージが必要となる。

int && rref = x + y ;

ムーブは、言語的にいえば、ムーブコンストラクターかムーブ代入演算子を呼び出すこと。
ライブラリ的にいえば、仮引数の型がrvalueリファレンスな関数も、ムーブしていると言える。

ムーブの具体的な実装は、好きにすればいい。
体一、コピーの具体的な実装も、好きにしていいのだから。
もちろん、デフォルトのコピー、ムーブコンストラクターや代入演算子の定義はあるけどね。

0251デフォルトの名無しさん

2010/10/26(火) 16:40:54

ストレージってメモリ上ってこと？
それなら、その保証がないのはlvalueだってアドレス参照されない限り
同じなのでは?

0252デフォルトの名無しさん

2010/10/26(火) 18:20:59

「常に可能であること」を「保証されている」と日本語では言う。
e.g. 常にアドレス参照可能

0253デフォルトの名無しさん

2010/10/26(火) 20:32:07

VC++2010なんだけど、ムーブ後なのにf1()もf2()も普通に呼べちゃうのはなんで？

#include <functional>

int main()
{
std::function<void()> f1 = [&]() { std::cout << "1" << std::endl; };
std::function<void()> f2 = std::move(f1);
f1();
f2();

return 0;
}

0254デフォルトの名無しさん

2010/10/26(火) 20:51:18

ムーブコンストラクタが無いから参照になってるんじゃ

0255デフォルトの名無しさん

2010/10/26(火) 20:52:40

ムーブ後の変数は使える保証はなくなるけど、必ずしも使えなくなる
わけじゃないよね。

0256デフォルトの名無しさん

2010/10/26(火) 20:53:22

deleteされた領域を参照すると値が残ってたりするのと一緒

0257デフォルトの名無しさん

2010/10/26(火) 21:04:53

あくまでも高速化のための機能だから、nullで埋めるなんてことはしてくれないんだね。

0258デフォルトの名無しさん

2010/10/26(火) 22:50:42

[&]() { std::cout << "1" << std::endl; };

これやっぱ何回見ても気持ち悪いわ
C++0xで最も汚いのはラムダ式だと思う

0259デフォルトの名無しさん

2010/10/26(火) 23:01:48

代替案を出さなかったのが悪い

0260デフォルトの名無しさん

2010/10/26(火) 23:13:36

ラムダさんは使いつづけてると
やっぱりこの形しかないかなぁと思えてくるよ

0261デフォルトの名無しさん

2010/10/26(火) 23:21:52

int x;
lambda(int a) { vcap.x = a; } //値キャプチャ
lambda(int a) { rcap.x = a; } // 参照キャプチャ

0262デフォルトの名無しさん

2010/10/26(火) 23:37:31

C++0x版のD&Eが今から楽しみだな
ビャーネ・ストロヴストルップ先生のブツクサ文句が山ほど書かれていると思うと・・・

0263デフォルトの名無しさん

2010/10/26(火) 23:46:16

弾道軌道からの眺めも書いてくれるかな

0264デフォルトの名無しさん

2010/10/26(火) 23:47:03

俺はEC++0xが楽しみ

0265デフォルトの名無しさん

2010/10/26(火) 23:52:46

>>253
VC++2010もってないしstd::moveも引数に何とるのか解らんけど、
std::moveがMove Constractorと同じ意味合のものだとしたらマズくね？
なんで名前が使えるものを渡されてコンパイルエラーにならないんだ？

0266デフォルトの名無しさん

2010/10/26(火) 23:58:21

>>265
std::moveでキャストしてるからコンパイルエラーにならない

0267デフォルトの名無しさん

2010/10/27(水) 00:02:05

std::move() ってのが一種のキャストというか、無理を押し通すための道具だから。

0268デフォルトの名無しさん

2010/10/27(水) 00:03:16

>>258
もうすっかり慣れっこになったけど、時々C#のラムダ式を書くとき混乱する。

0269デフォルトの名無しさん

2010/10/27(水) 00:58:59

>>267
んなもん何のために使うのかさっぱりわからんなぁ。
const_castを全く使わんからかもしれんけど。
(旧C互換で定数をchar*で渡す関数にしか使ったこと無い)

0270デフォルトの名無しさん

2010/10/27(水) 01:06:26

左辺値を強制的に右辺値に変更する働きをする
これで意味が分からなかったらぐぐれ

0271デフォルトの名無しさん

2010/10/27(水) 01:12:37

コピーコンストラクタとムーブコンストラクタに限らず、左辺値参照と右辺値参照を取る
オーバーロードがあって、しかも効率の差が大きい場合、

void hoge(int &x);　// 左辺値を渡しても安全だけど遅い
void hoge(int &&x); // 左辺値を渡すと安全は保証されないけど速い

左辺値をどうしても下の関数に渡したい時に使う。

0272デフォルトの名無しさん

2010/10/27(水) 01:14:49

>>255-256
つまり、VC++2010のムーブの実装はswapじゃないってこと？

0273デフォルトの名無しさん

2010/10/27(水) 01:20:10

>>272
つうか、おそらく単なる参照渡し。
ムーブ後の抜け殻に触った結果はどうせ未定義なんだから、仕様は満たしてるよね。

0274デフォルトの名無しさん

2010/10/27(水) 01:34:14

こんなんなってた

11: std::function<void()> f1 = [&]() { std::cout << "1" << std::endl; };
00411750 xor eax,eax
00411752 mov byte ptr [ebp-121h],al
00411758 movzx ecx,byte ptr [ebp-121h]
0041175F push ecx
00411760 lea ecx,[ebp-2Ch]
00411763 call std::tr1::function<void __cdecl(void)>::function<void __cdecl(void)><`anonymous namespace'::<lambda0> > (41104Bh)
00411768 mov dword ptr [ebp-4],0
12: std::function<void()> f2 = std::move(f1);
0041176F lea eax,[ebp-2Ch]
00411772 push eax
00411773 call std::move<std::tr1::function<void __cdecl(void)> &> (41110Eh)
00411778 add esp,4
0041177B push eax
0041177C lea ecx,[ebp-4Ch]
0041177F call std::tr1::function<void __cdecl(void)>::function<void __cdecl(void)> (411096h)
00411784 mov byte ptr [ebp-4],1
13: f1();
00411788 lea ecx,[ebp-2Ch]
0041178B call std::tr1::_Function_impl0<void>::operator() (41126Ch)
14: f2();
00411790 lea ecx,[ebp-4Ch]
00411793 call std::tr1::_Function_impl0<void>::operator() (41126Ch)

0275デフォルトの名無しさん

2010/10/27(水) 01:35:31

>>272
中身がただの関数ポインタになってて、ポインタのムーブはただのコピーが最善手
ってことじゃないかな？

0276デフォルトの名無しさん

2010/10/27(水) 06:41:36

というか、std::moveは、単にrvalueリファレンスにキャストするだけだ。
std::move(t)と書くのは、static_cast<T &&>(t)と書くのと同じだ。
別にムーブと同等の処理は、非constなlvalueリファレンスを引数に取る関数でもできる。
単に所有権の移動と考えろ。

クラスのオブジェクト自体が魔法のようになくなったりはしない。

0277デフォルトの名無しさん

2010/10/27(水) 09:17:19

右辺値参照を受け取る側は元の値を「気兼ねなく破壊できる」ってだけで
破壊する義務はないってことか。

0278デフォルトの名無しさん

2010/10/27(水) 09:44:10

rvalueリファレンスは、あくまでただの「リファレンス」だからな。
rvalues(xvalueとprvalue)で初期化しなければならないこと以外は、lvalueリファレンスと何ら変わらない。
もちろん、rvalueリファレンスの変数自体を評価するとlvalueだ。

int && ref = 0 ;// OK、0はprvalue
int && aho = rref ; // エラー、rrefはlvalue

0279デフォルトの名無しさん

2010/10/27(水) 18:10:59

>>278
rvalueリファレンスの変数を評価したらxvalueじゃないの？

0280デフォルトの名無しさん

2010/10/27(水) 18:14:08

Non

0281デフォルトの名無しさん

2010/10/27(水) 19:01:24

>>253
そのラムダ式の()は不要だよね。
ネットで見かけるコードだと、相当な上級者の書いたコードでも()が
ついてるけど、なんでみんな書きたがるのか。
でもさすがに某標準化委員は書いてなかった。

0282デフォルトの名無しさん

2010/10/27(水) 19:03:24

規格を読まず他人のコードを読むから

0283デフォルトの名無しさん

2010/10/27(水) 19:06:16

別に書いちゃいかんというルールもないし。

0284デフォルトの名無しさん

2010/10/27(水) 19:25:30

省略するのはなんか気持ち悪いじゃん
慣れの問題だろうけど

0285デフォルトの名無しさん

2010/10/27(水) 19:46:57

引数有る無しで書き方を変えるのが変わるのが嫌、とか

0286デフォルトの名無しさん

2010/10/27(水) 19:48:43

ラムダの時に()を省略できるなら、普通の関数宣言でも()を省略できてもいいじゃない

0287デフォルトの名無しさん

2010/10/27(水) 20:33:52

こうなのか？
std::function<void()> f1 = [&]{ std::cout << "1" << std::endl; };

やっぱり括弧つけようよ

0288デフォルトの名無しさん

2010/10/27(水) 20:48:04

#include <iostream>
いやいやこれで十分でしょう。

int main()
{
[]{ std::cout << "1" << std::endl; }();
return 0;
}

なるほど、ファンクタクラスを作るシンタックスシュガーなんだなあ。

0289288

2010/10/27(水) 20:49:04

しまった。行が入れ替わったｗ

0290デフォルトの名無しさん

2010/10/27(水) 21:05:45

#include <iostream>
//いやいやこれで十分でしょう。

int main()
{
[]{ std::cout << "1" << std::endl; }();
return 0;
}

0291デフォルトの名無しさん

2010/10/27(水) 21:11:48

#include <iostream>
//つまりこれと等価ということか

struct x {
void operator()() { std::cout << "1" << std::endl; }
};

int main() {
x()();
return 0;
}

0292デフォルトの名無しさん

2010/10/27(水) 21:23:59

Delphi/C#のpropertyみたいなものは導入されないんですか？

0293デフォルトの名無しさん

2010/10/27(水) 21:27:34

知らずに0x使うと爆死するようなトラップ要素って右辺値参照さんのほかになんか有りますか？

0294デフォルトの名無しさん

2010/10/27(水) 21:33:20

>>292
Javaには入る。
C++はもっとprimitiveな機構に分解できれば入ると思う。

0295デフォルトの名無しさん

2010/10/27(水) 21:39:49

>>292
n1615みたいなのは(作れば)あるけど規格には入らないだろうね

0296デフォルトの名無しさん

2010/10/27(水) 21:53:39

>>291
// #1-n と #2-n は等価。
int main()
{
　using namespace std;
　{ // #1
　　int i = 0;
　　auto x1 = [] { cout << "#1-1. " << endl; };
　　auto x2 = [i] { cout << "#1-2. " << i << endl; };
　　auto x3 = [i]() mutable { cout << "#1-3. " << ++i << endl; };
　　auto x4 = [&i] { cout << "#1-4. " << ++i << endl; };
　　x1(); x2(); x3(); x4();
}
　{ // #2
　　int i = 0;
　　struct { void operator()() const { cout << "#2-1. " << endl; } } const x1 = {};
　　struct { int const i; void operator()() const { cout << "#2-2. " << i << endl; } } const x2 = {i};
　　struct { int mutable i; void operator()() const { cout << "#2-3. " << ++i << endl; } } const x3 = {i};
　　struct { int & i; void operator()() { cout << "#2-3. " << ++i << endl; } } x4 = {i};
　　x1(); x2(); x3(); x4();
}
}

0297デフォルトの名無しさん

2010/10/27(水) 21:54:01

そう言えばVCに__declspec(property)ってあったよな。

0298デフォルトの名無しさん

2010/10/28(木) 15:55:58

ラムダ関数を変数に格納する場合、インスタンスと参照、どちらを格納したことになるんでしょう？

1: auto func=[](int x,int y){return x+y;};
2: {
3: 　　func=[](int x,int y){return x-y;};
4: }
5: std::cout<<func(2,1);　　　//出力：1

3行目にfuncにラムダ関数を代入していますが、
これが参照なら5行目はスコープ外ですから動作が不定になりそうです
g++4.5.1では1が出力されたのですが

0299デフォルトの名無しさん

2010/10/28(木) 16:02:10

インスタンスという認識でいいと思うよ

0300デフォルトの名無しさん

2010/10/28(木) 16:04:58

参照でもinfinite extentなら問題ない。
どうせimmutableなんだから。

0301デフォルトの名無しさん

2010/10/28(木) 16:10:42

ありがとうございます
std::function,queueと組み合わせてタスクキュー的なものを作りたくて

関数が変数みたいに使えるって便利ですね

0302デフォルトの名無しさん

2010/10/28(木) 16:17:32

>>298
何もキャプチャーしてないが、typoか？

0303デフォルトの名無しさん

2010/10/28(木) 17:33:02

>>302
何かをキャプチャしなければならないというルールはないよ

0304デフォルトの名無しさん

2010/10/28(木) 18:03:58

typoを修正してくれるライブラリ。Boost.Typoみたいな感じで誰か作ってくれないかな

0305デフォルトの名無しさん

2010/10/28(木) 18:41:57

なにもかもがBoost.Typoの意図通りに捻じ曲げられそう…

0306デフォルトの名無しさん

2010/10/28(木) 21:23:21

main
{

0307デフォルトの名無しさん

2010/10/28(木) 21:24:14

あとはboost::typoにお任せるぜ

0308デフォルトの名無しさん

2010/10/29(金) 01:05:17

>>293
右辺値参照がどうやって「爆死するようなトラップ要素」になるの？

0309デフォルトの名無しさん

2010/10/29(金) 01:14:33

class Hoge
{
int * p;
public:
Hoge(int n) : p(new int(n)) {}
Hoge(Hoge const & o) : mp(new int(*o.p)) {}
~Hoge(void) { delete p; }
};
こういうクラスで暗黙にmoveされたらテンポラリとmove先両方でdeleteされてまずくない？

0310デフォルトの名無しさん

2010/10/29(金) 01:17:45

>>309
そんなわけで暗黙のムーブコンストラクタは無しになったのさ。 >>126 参照。

ちなみにそのクラス定義だと現行の C++ でも代入で死ぬよ。

0311デフォルトの名無しさん

2010/10/29(金) 08:39:40

まだなくなると決まったわけじゃない。
特に、禿がひいきにしているからな。
禿によると、そもそも暗黙のコピーも、ユーザー定義デストラクターがあった場合、
暗黙に生成されないべきなんだとさ。

0312デフォルトの名無しさん

2010/10/29(金) 09:43:48

まあ=defaultで明示的にってのは悪くない考えだけど、いまさらなあ…

0313デフォルトの名無しさん

2010/10/29(金) 12:23:29

しかし今までのコードと互換性が無くなったらストレスで俺たちがハゲになっちまう

0314デフォルトの名無しさん

2010/10/29(金) 12:46:22

もういっそC++++作れよ

0315デフォルトの名無しさん

2010/10/29(金) 12:46:55

本物の C++ 使いはハゲを恐れない。

0316デフォルトの名無しさん

2010/10/29(金) 17:22:33

というかもう殆ど禿げてる
まだ２０なかばなのに

0317デフォルトの名無しさん

2010/10/29(金) 17:42:17

>>316
いつ新しい言語を設計するんですか？
C++と同等に使えて、evalも用意されている言語をお願いします。

0318デフォルトの名無しさん

2010/10/29(金) 18:37:26

>>317
evalはちょっと欠陥品だろう。
頼むからもうちょっとまともな仕様の言語が欲しい。

0319デフォルトの名無しさん

2010/10/29(金) 18:56:45

まあC++1xでconcept入ってしばらくしたら、
その辺の成果を全部生かした言語も作られるんじゃないでしょうか。

0320デフォルトの名無しさん

2010/10/29(金) 19:27:58

いい加減新しい言語作って若いもんに覚えさせたほうが人類のためになるよね
人類はいつまでC系列にしがみつく気なんだろう

0321デフォルトの名無しさん

2010/10/29(金) 19:32:42

プリプロセッサまわりが汚すぎて、既存のライブラリを確実に移植する方法が
手作業以外に無いんだから仕方ない。
OSのAPIから新言語で提供されていれば話は違うんだろうけど、それも既にModulaが通った道だ。

0322デフォルトの名無しさん

2010/10/29(金) 20:24:03

>>320
だからお前がまず代替案を出せよ

C++0xのラムダ式も誰も代替案を出さないからあの汚い形のままなんだぞ

0323デフォルトの名無しさん

2010/10/29(金) 20:26:09

functionとかキーワード化したいよなぁ。
というか、将来のために基本的な英単語を予約しておかなかったのが、そもそもの間違いだった。

0324デフォルトの名無しさん

2010/10/29(金) 20:27:49

functionって毎回書くの長ったらしくないか？

0325デフォルトの名無しさん

2010/10/29(金) 20:31:17

>>320
事情はx86CPUと似ていると思うよ
アーキテクチャがいかに汚くなろうと、過去の財産を大事にすると生き残る

0326デフォルトの名無しさん

2010/10/29(金) 21:00:41

互換性を窓から投げ捨てろ
つうか生き残らなくていいからどんどん新しい物を作って破って捨てろ

0327デフォルトの名無しさん

2010/10/29(金) 21:12:09

お前がこのスレに要らん

0328デフォルトの名無しさん

2010/10/29(金) 21:22:46

>>309
デフォルトコピーコンストラクターが使えないクラスにデフォルトムーブコピーコンストラクタを望むのが間違ってるよ。
デフォルトコピーコンストラクタが可能なクラスなら、おそらくデフォルトムーブコンストラクタが可能じゃないか？こいつらはセットだよ
コピーコンストラクタもムーブコンストラクタも定義されていないクラスのみデフォルトコピーコンストラクタとデフォルトムーブコンストラクタを許可すればすむと思うが、どうか？

0329デフォルトの名無しさん

2010/10/29(金) 21:25:30

>>324
typedef function<int(int,int,int)> func_type;してから使うから気にしない。

0330デフォルトの名無しさん

2010/10/29(金) 21:26:36

>>326
互換性を捨てるならＣ＋＋である必要はなく、ＤでもＥでもＦでも作ればいいんじゃね？

0331デフォルトの名無しさん

2010/10/29(金) 22:00:22

最近の新言語ってJavaもどきとLLと関数型ばっかりでつまらん
結局代わりになる言語を誰も作ろうとしないのよね

0332デフォルトの名無しさん

2010/10/29(金) 22:37:42

>>331
> 結局代わりになる言語を誰も作ろうとしないのよね
頭おかしいのww
作ろうとした人ならめっちゃくちゃ居るよ。

成功した人がいないだけだ。

0333デフォルトの名無しさん

2010/10/29(金) 22:55:40

つくろうとしても既存のコミュニティが受け入れずに潰されるからね

0334デフォルトの名無しさん

2010/10/29(金) 23:10:03

>>329
基本autoでよくね？

enum classってusing enum EnumName;とかって名前空間みたいな書き方できないのかな？
現行でこんな書き方してるから、置き換えられるんなら置き換えたい。

namespace EnumName //列挙型の識別名
{
enum Enum
　{
VALUE1,
VALUE2
};
}

{
using namespace EnumName;
switch(x)
{
case VALUE1:break;
}
}

0335デフォルトの名無しさん

2010/10/29(金) 23:50:01

C++は変態言語だから生き延びたのよ

0336デフォルトの名無しさん

2010/10/29(金) 23:59:29

>>333
それは単なる被害妄想。

0337デフォルトの名無しさん

2010/10/30(土) 01:39:14

>>323
逆じゃないかなぁ。
ユーザーコードで基本的な英単語が変な心配しないで使えるように、
キーワードこそ多少不自然な省略なりしたものを使ったほうがいいんじゃ
ないか？

0338デフォルトの名無しさん

2010/10/30(土) 02:17:36

成功が広く使われることならば、
最近成功したのはLLとObjective-Cだけでしょ。
俺はOmegaや<it>G</it>なんかも面白かったけど。

0339デフォルトの名無しさん

2010/10/30(土) 03:05:23

＞Objective-C
え？

0340デフォルトの名無しさん

2010/10/30(土) 03:46:08

糊インタプリタも軽量言語もC/C++もアセンブラも混ぜこぜで１ソースで書けて且つ一緒クタにコンパイル/リンクが行えて且つ構文エラーやら警告も一緒クタに吐いてくれる環境の標準化シテ欲しいね

0341デフォルトの名無しさん

2010/10/30(土) 07:05:07

>>340
つD

0342デフォルトの名無しさん

2010/10/30(土) 10:47:05

Obj-Cって別に最近出来た訳じゃないだろ

今最もホットな言語なのは間違いないが

0343デフォルトの名無しさん

2010/10/30(土) 12:41:09

禿がポックリ逝ったらC++0xはどうなるんだよ？

いや、それでもいいか

0344デフォルトの名無しさん

2010/10/30(土) 13:06:03

別な誰かが禿げる。

0345デフォルトの名無しさん

2010/10/30(土) 13:09:08

画像をウィンドウの前に表示するためにはどうすればいいですか？

0346デフォルトの名無しさん

2010/10/30(土) 13:15:27

そのウィンドウの前に画像を表示するウィンドウを出してください

0347デフォルトの名無しさん

2010/10/30(土) 13:47:30

禿げが死んでもC++は生き残るさ
２ｃｈはひろゆきが死んだら終わりなんだっけ？

0348デフォルトの名無しさん

2010/10/30(土) 14:06:06

2chはもうどっかの外資が支配してるからひろゆきは関係ないよ

0349デフォルトの名無しさん

2010/10/30(土) 15:28:40

>>347
むしろ禿げが死んだらC++は衰退し、
２ｃｈはひろゆきの手を離れてもこうして続いている。

0350デフォルトの名無しさん

2010/10/30(土) 20:24:42

C++は滅びぬ、何度でも蘇るさ
C++の力こそ人類の夢だからだ

0351デフォルトの名無しさん

2010/10/30(土) 21:00:03

C++は糞言語かもしれないが、あまりに多大な時間と労力を掛け過ぎ、
しかも関わった人が多すぎた
今更白紙に戻す事はできないってのが実情でしょう

0352デフォルトの名無しさん

2010/10/30(土) 21:43:06

>>351 世の中には「語ってはいけない真実」ってのがあるってしってるか?

0353デフォルトの名無しさん

2010/10/30(土) 23:36:46

禿げはA級戦犯ってことか

0354デフォルトの名無しさん

2010/10/30(土) 23:58:09

EXEやDLL、a.out、soのサイズがCに比べて格段に大きくなる傾向があるので
DLLとsoは必須だな

但しx86はコールゲートを通すと滅茶遅くなるんだよなあ
そこは我慢か

0355デフォルトの名無しさん

2010/10/31(日) 00:52:49

>>351
お前がNo.1だ

0356デフォルトの名無しさん

2010/10/31(日) 00:59:08

C++がこのまま肥大化する一方で、PL/Iの悲劇を繰り返さなければいいのだが
まあパソコンのスペックが上がってHDDもテラバイト時代なので、多少大きくても
楽々入ってしまうけどな

0357デフォルトの名無しさん

2010/10/31(日) 01:57:57

こういう問題のある基盤に大量のものが乗っかった状況を改善する一般的手法ってないの
結構そういう状況って他にも溢れてると思うんだけど

0358デフォルトの名無しさん

2010/10/31(日) 02:36:33

>>357
あるとしたらC99とかD言語だけど、知っての通り単なるマニア向け言語に
なってしまっただろ？

Cがあれだけ広く使われてしまったらもう引き返せないんだと思うよ
Cの上に乗っているC++もC++0xも結局同じ道を半ば強制的に辿らされる

他のLL言語は遅くて使い物にならないしな

C#も糞だって分かってしまったし
ただC#やJavaは開発コストと時間を大幅に削減出来るので、一度立ち上げて
しまえば滅多にシャットダウンしない、速度もそんなにカリカリ必要ないデータベース
にはこれからも使われていくだろう

0359デフォルトの名無しさん

2010/10/31(日) 07:38:56

段階的にやるなら、C99で暗黙のintが禁止されたように、じわじわと締め付けていって
・配列からポインタへの暗黙の変換を禁止
・#defineのソース置換を禁止して条件コンパイル用に限定(enumやinlineに移行させる)
・enum/struct/unionのタグとスコープの関係の明確化
あたりを整理。strictモードでコンパイルすれば警告が出るようにして、段々と曖昧な書き方をされた
.hを駆逐していくしかないだろう。
今でも関数ポインタではなくて関数型そのものをtypedefしてる糞.hが山ほどある。

現存する膨大な.h資産から曖昧な部分が無くなれば、C++もこのへんの互換性を残す必要も無くなるし、
他の(LLやVM向けではなくCと同分野の)言語(Modula/Fortran/D……)に向けて.hを自動変換するのも楽になる。

C1xでもそんな話は一切でてないけどな……。

0360デフォルトの名無しさん

2010/10/31(日) 08:04:32

>>359
> 今でも関数ポインタではなくて関数型そのものをtypedefしてる糞.hが山ほどある。

むしろなんで関数型を typedef せずにポインタまでつけた typedef しか提供しないんだ糞が、
それじゃ関数宣言の照合にも使えないし function にも使えないだろうが糞が、とか思うんだけど、
なんでポインタで typedef しないと糞なの？

0361デフォルトの名無しさん

2010/10/31(日) 08:28:23

>>359
C99 を策定したことで古い C のコードの書き換えが進んだりしてないでしょ。
新しい規格の締め付けで古いコードの駆逐なんて期待はできないよ。

コードが準拠してる規格のバージョンを明記することで危険な変換が禁止される
ようになる、とかすればいいのかな？

using "C++2003";
int x = ...;
unsigned int y = x; // ok, but unsafe

using "C++2020";
int x = ...;
unsigned int y = x; // error

0362デフォルトの名無しさん

2010/10/31(日) 08:34:27

>>360
値として使えない型を導入してしまうから。
いやもちろん、今のsyntaxだとパーサレベルでは関数型を扱わないといけないんだけど。

>>361
-Werrorで充分じゃ……。

0363デフォルトの名無しさん

2010/10/31(日) 09:06:46

>>361
実際問題暗黙のintはかなり減った、というよりほぼ全く見なくなったでしょ。
C99というよりC++の功績とは思うけど。

0364デフォルトの名無しさん

2010/10/31(日) 09:17:38

>>362
値として使えない型を導入されると、糞というほど困るの？なんで？

0365デフォルトの名無しさん

2010/10/31(日) 09:33:00

>>362
不完全型の typedef なんぞ腐るほどあるなあ

>>363
long long

0366デフォルトの名無しさん

2010/10/31(日) 09:33:47

>>364
とりあえず現状のCには関数宣言の照合やfunctionの類の機能が全くないので
あってもまるで嬉しくないのに、sizeofその他の例外をvoid以外に増やしてしまう。
(voidの値もダミー値として扱いたいと思ってるクチ、
ついでにvoidをunitに改名して"void"は正しくnoreturnの意味にならないかね)

C++で必要だから導入して、Cがそれを互換性のために追認というならまだしも
現状本当に何の意味もなくただコンパイラが通すからってだけで関数型がtypedefされてるのは
普通に関数ポインタと思って使ったらエラーになったりする……糞が、って思うぐらいで
全く利点がないだろ。

0367デフォルトの名無しさん

2010/10/31(日) 09:38:36

>>366
関数宣言の照合がない C って K&R C か？
a();
void a(void) { } /* error */

0368デフォルトの名無しさん

2010/10/31(日) 09:42:47

>>366
> とりあえず現状のCには関数宣言の照合やfunctionの類の機能が全くないので
×全くない
○全く知らない

typedef int f_type(int);

f_type f;
void f(int); // error

0369デフォルトの名無しさん

2010/10/31(日) 09:45:35

>>368
想像図を書くなら
typedef int f_type(int a);
f_type f { return a; }
だろ

関数定義に「突然」出てくる a は型情報ではないので
確かに気持ち悪い

0370デフォルトの名無しさん

2010/10/31(日) 09:45:43

>>366
> 普通に関数ポインタと思って使ったらエラーになったりする……糞が、って思うぐらいで

ただの思い込みで逆切れとか、ひどいな。

↓どっちが関数ポインタに見えるかって、見りゃわかるだろうに。
Function p;
Function* p;

0371デフォルトの名無しさん

2010/10/31(日) 09:46:43

>>367
>>360が言ってるのは、(仮にこんな文法があるとして)

void a(void);
typedef void f(void);
static_assert(a is f);
template<typename x> class t { operator x ...//変換演算子

みたいな話と解釈したけど。typedefの話なんだから。

0372デフォルトの名無しさん

2010/10/31(日) 09:53:58

>>371
それを実際にやるのが >>368 なわけだが。

0373デフォルトの名無しさん

2010/10/31(日) 09:54:48

って、今試してみたら>>368って通るんだな。これは知らなかった。
これについては俺の間違いだ。ごめん。

0374デフォルトの名無しさん

2010/10/31(日) 09:56:16

>>371
static_assert(typeid(a) == typeid(f));
という話ならわからんでもないが
operator が出てくるのは何？

0375デフォルトの名無しさん

2010/10/31(日) 09:59:09

>>374
関数にキャストできるtemplateで何かできそうだと思って書きかけてやめたんだが消し忘れたようだ。無視してくれ。

0376デフォルトの名無しさん

2010/10/31(日) 10:11:43

>>375
それは構文上はＯＫで、意味でＮＧという（であるべき）話じゃないか？
int a(int);
int b()(int); //OK. b returns int(int)
int b()(int) { return a; } //NG. expression has incomplete type
int a(int c) { return c; } //if a was complete...
int d()(int) { return a; } //NG. d cannot copy from a to rv

0377デフォルトの名無しさん

2010/10/31(日) 10:18:04

そうですね

0378デフォルトの名無しさん

2010/10/31(日) 10:39:32

>>368
それプロトタイプ宣言ではできるけど
関数定義の方では使えないんだよな（できたとしても引数名も分からないし）
プロトタイプ宣言と関数定義の表記が揃ってないと読み辛いし
結局役に立たない

0379デフォルトの名無しさん

2010/10/31(日) 10:43:19

>>361
Cコードの書き換えが進まないのは
単にコンパイラベンダがC99に対応しないからだな

0380デフォルトの名無しさん

2010/10/31(日) 10:53:30

>>310
= default でデフォルトのムーブコンストラクタを作る事もできないのかな？

0381デフォルトの名無しさん

2010/10/31(日) 11:22:02

コンパイルオプションでバージョン指定できるようにすればええやん
互換性なんて気にすることあらへんのや

0382デフォルトの名無しさん

2010/10/31(日) 11:27:44

そこで#pragmaですよ

0383デフォルトの名無しさん

2010/10/31(日) 11:28:26

>>381 それだと古いライブラリコードを新しいコードから使いたいときに困る。

0384デフォルトの名無しさん

2010/10/31(日) 19:22:57

メジャーどころでC99に非対応なのは MSVC だけかと思ってたけど違うのか

0385デフォルトの名無しさん

2010/10/31(日) 19:33:28

C99って可変長配列が使えるらしいけど、開放のタイミングが謎だよな。
むしろ、可変長配列があったらＣとは呼べないんじゃないか？

0386デフォルトの名無しさん

2010/10/31(日) 19:45:18

C99の可変長配列はalloca()のシンタックスシュガーだよ

0387デフォルトの名無しさん

2010/10/31(日) 19:47:04

C++コンパイラはC++0x対応で精一杯だろうからC99の対応には消極的だろう。
Cコンパイラはコストを掛けてまで対応してもメリットはないだろうし

0388デフォルトの名無しさん

2010/10/31(日) 20:00:00

>>384
それが致命的すぎ

0389デフォルトの名無しさん

2010/10/31(日) 20:16:13

>>385
謎とか、規格にちゃんと書いてあるだろ

0390デフォルトの名無しさん

2010/10/31(日) 20:18:06

>>389
C99ってstructに可変長配列宣言してmallocしても機能するの？

0391デフォルトの名無しさん

2010/10/31(日) 20:28:32

そんなもんは宣言できない

0392デフォルトの名無しさん

2010/10/31(日) 20:33:03

寝言は寝て言え

0393デフォルトの名無しさん

2010/10/31(日) 20:53:15

過去の遺産を使えるけど、でもまともな綺麗な言語仕様を持つ言語、
俺には到底つくれないので、誰か天才さん作ってください！！

0394デフォルトの名無しさん

2010/10/31(日) 21:03:55

可変長配列ってlongjmpですっ飛ばしたら解放されない可能性があるとか読んだ覚えがある

0395デフォルトの名無しさん

2010/10/31(日) 21:05:39

可変長って訳語が悪いなあ。
動的に初期サイズ決定するってだけで、
後からサイズを変えられるわけじゃない。

0396デフォルトの名無しさん

2010/10/31(日) 21:23:49

これが可能になるって事？
int n=10;
int array[n];

微妙な拡張よりも拡張子cppに変えてvector使ったほうがメリットあるだろうね。

0397デフォルトの名無しさん

2010/10/31(日) 21:28:44

>>354
stl とか boost 入ると shared library つかっても object サイズはしゃれにならん
strip 後の size みて, "何, これ?" 状態

おまえら使うのやめろや, template !!!

# でも, 俺は使うけどなw

0398デフォルトの名無しさん

2010/10/31(日) 21:50:17

>>394
確か最初はC++はCへのトランスレータの形で実現されていたけど、例外処理を
取り込んだ時点でどうしてもC++のネイティブコンパイラが必要になったそうだな

longjmp()とsetjmp()だけだと例外処理を実現出来ないんだと

0399デフォルトの名無しさん

2010/10/31(日) 21:57:19

かなーり近いもん書けてるけどねー
むしろキツかったのはマングリングとテンプレート方面だろ

0400デフォルトの名無しさん

2010/10/31(日) 22:23:42

テンプレートは例外処理の後で出て来たしな
もうすっかりネイティブ一色になった後だった

ARMには並べて書いてあるけど

0401デフォルトの名無しさん

2010/10/31(日) 22:27:51

>>399
try/chatch のセマンティクスからだと, longjmp は戻り先が固定なので,
使えないんだよ.
いまでも, 例外はオーバーヘッドでかいけど, コンパイラ/実行コードともに,
使い物にならないくらいのオーバーヘッドがあったらしい.

0402デフォルトの名無しさん

2010/10/31(日) 22:31:05

throw; とか実現できないしな

0403デフォルトの名無しさん

2010/10/31(日) 22:33:44

>>402 throw も setjmp したところの dictionary 作って実現してたっぽいけどな

0404402

2010/10/31(日) 22:38:47

補足:
C++ よりずっと前に kcl(lisp->c のトランスレータ的実装) が lisp の
例外を実装してたんだから， lisp 例外の劣化コピーの C++ の例外が
実装できないはずはないし, ちゃんと考えて実装すれば
拡張 setjmp/longjmp で何とかなったとは思われる.

0405デフォルトの名無しさん

2010/10/31(日) 22:59:33

>>401
戻り先が固定？？　もしかして jmp_buf をグローバルにしてるのか？？？
throw; が実現できないとか噴飯ものだ

0406402

2010/10/31(日) 23:12:31

>>405
一つの setjmp に一つの longjmp が対応している
単純に考えれば, longjmp から戻ったときに再度 dispatch
素朴な実装だと try/catch のように積極的に使うと, dispatch table (が|で)あふれる

0407デフォルトの名無しさん

2010/10/31(日) 23:22:13

>>401
例外はオーバーヘッドでかいって、何のこと言ってるの？

例外が実際に投げられない限り実行時間のオーバーヘッドは
ほぼゼロになる実装がすでに主流になってると思うんだけど。

0408デフォルトの名無しさん

2010/10/31(日) 23:24:44

投げた時の話だろ

0409デフォルトの名無しさん

2010/10/31(日) 23:28:52

>>406
ド素人ですが
ごく単純に考えれば、単なるjmp_bufのスタックでよくないですか？
tryブロック毎にpush、ブロック出たらpop
throwはスタックトップにlongjmp
スタックはスレッド毎に必要でしょうけど

0410デフォルトの名無しさん

2010/10/31(日) 23:40:25

それSjLj

0411デフォルトの名無しさん

2010/10/31(日) 23:54:37

>>409
Cならそれでスタック巻き戻せるからいいけど、C++はデストラクタ呼ばなくちゃならないのがめんどくさいところ

0412デフォルトの名無しさん

2010/10/31(日) 23:55:43

>>411
そこは承知していますが、出来る出来ないで言えば、この方針で出来るでしょう

上でlongjmpの飛び先が一つなので出来ないという議論をしている意味が
全く理解できなかったものですから

0413デフォルトの名無しさん

2010/11/01(月) 00:03:09

tryブロックのたびにpush、popは結構なオーバーヘッドになるのです。
実際、昔のC++はそのような方法をとっていたようですが、いまは別の方法のようです。

0414デフォルトの名無しさん

2010/11/01(月) 00:06:48

細かい話なのでいちいち書きませんでしたが、
デストラクタ呼び出しが必要な全ての箇所をtry{}finally{}で仮想的に
囲み、デストラクタ呼び出しコードをfinally{}ブロックに埋め込めば
実現可能と考えます（C++にfinallyはありませんが、通じると思います）

さらに自明と思って書きませんでしたが、例外をハンドルしない場合の
リレーは、次のトップにlongjmpするだけです

素人考えなので素朴極まりないのですが、可能不可能で言えば
実現は十分可能に見えます

0415デフォルトの名無しさん

2010/11/01(月) 00:06:55

push みたいな write サイクルを含む命令を jmp_buf の宣言だけで使うかよ
setjmp は必要な範囲だけに限定できるし、そもそも「オーバーヘッド」って何のことだよ

0416デフォルトの名無しさん

2010/11/01(月) 00:13:50

>>412
longjmpのアドレスの保存先ってstrtokのポインタの保存先と同じで、ライブラリ内に
一つしかないんじゃないの？

0417デフォルトの名無しさん

2010/11/01(月) 00:16:18

>>416
そんなことはありません
jmp_bufについて調べてください

0418デフォルトの名無しさん

2010/11/01(月) 00:16:35

>>416
てめーで少しでいいから使ってみろタコ

0419デフォルトの名無しさん

2010/11/01(月) 00:19:15

いまさらlongjmpなんか使わないでしょう

0420デフォルトの名無しさん

2010/11/01(月) 00:23:18

>>419
使ってからいいな

0421デフォルトの名無しさん

2010/11/01(月) 00:26:57

longjmpと例外の実装方法の違いを論ずるならともかく、なんでそんなにlongjmpに御執心なの？

0422デフォルトの名無しさん

2010/11/01(月) 00:31:29

>>421
自分への質問でしたら、>>398あたりの流れ

> longjmp()とsetjmp()だけだと例外処理を実現出来ないんだと

これについて疑問を持ったから意見を述べたまでで、
別にlongjmp()自体はどうでもいいです

0423デフォルトの名無しさん

2010/11/01(月) 11:26:01

>>414
君の考えで間違いない。

大体今でもフロントエンド形式のコンパイラはあるし。
アセンブリも使っているとはいえ。

0424デフォルトの名無しさん

2010/11/01(月) 18:36:48

今だと表引き法なのかな?

0425デフォルトの名無しさん

2010/11/01(月) 19:25:11

gccでもconfigure時に--enable-sjlj-exceptions付けたら今でもlongjmpじゃね？

0426デフォルトの名無しさん

2010/11/01(月) 21:28:59

C++だとlongjmpは使用禁止だけどな

0427デフォルトの名無しさん

2010/11/01(月) 21:34:39

そりゃ、明示的にユーザーコードでlongjmp使ったら、デストラクタ飛ばしちゃうだろ。
コンパイラが裏で例外の実装としてlongjmpを使う分にはなんの問題もない。

0428デフォルトの名無しさん

2010/11/01(月) 21:49:31

区別出来ないアホはほっとけ

0429デフォルトの名無しさん

2010/11/01(月) 21:53:30

http://codepad.org/PtHh60zX
VC++だとデストラクタが実行されるのに、g++だと飛ばされるんだ。知らんかった。

0430デフォルトの名無しさん

2010/11/01(月) 21:55:12

C++でlongjmp使うなyo

0431デフォルトの名無しさん

2010/11/01(月) 21:55:28

何でそんなこともしらないやつがC++0xスレいるの？
>>398とか。背伸びしすぎw

0432デフォルトの名無しさん

2010/11/01(月) 22:00:37

>>429
WindowsのSEHはスタック上でリンクリストを作ってるから、動的に辿るのも簡単だしね。
g++はデフォルトZCXの上にlongjmpにも切り替え可だから両対応は難しい(んだと思う)。不可能ではないだろうけど。

0433デフォルトの名無しさん

2010/11/01(月) 22:03:10

ああそうか、WindowsはOS自体が構造化例外機構を持ってるんだった。

0434デフォルトの名無しさん

2010/11/01(月) 22:15:10

一概に使うなとか言ってる奴は論外
委細をわかっていて使う使わないを選択する人用の言語だかんな

0435デフォルトの名無しさん

2010/11/01(月) 22:26:20

>>425
今でもlongjmp()なんだ
SjLjはthrowされたらpersonalityとlongjmp()する場所を記録したリストを型判定しながらたどって
何とかとかいう構造体でcatchできる型と判定したらsetjmp()した所に帰るとかだったような
随分前に本で読んだ記憶あるがほとんど覚えてないw

0436デフォルトの名無しさん

2010/11/01(月) 22:29:02

>>435
流石にlongjmpそのものではなくて、unwind.hで定義された関数使うけどな。
その中がlongjmpか同等の何かまでは知らん。
personalityは、ハンドラが受け取る例外の種類を判定するための関数だね。

0437デフォルトの名無しさん

2010/11/01(月) 22:43:27

>>435
> 今でもlongjmp()なんだ

今でもも糞も「SjLj」なんだよ！
使わないならLjじゃねえ！

0438デフォルトの名無しさん

2010/11/01(月) 23:19:05

setjmpとlongjmpの関係をnear/farポインタ的なものだと思ってた時期もありました…

ペアで使うような名前には見えないよねこれら

0439デフォルトの名無しさん

2010/11/01(月) 23:27:30

longjmp を使うのに #include <csetjmp> が必要でもか？

0440デフォルトの名無しさん

2010/11/01(月) 23:28:01

何言ってんだこいつ

0441デフォルトの名無しさん

2010/11/01(月) 23:29:45

わからないならレスしないで下さい
ウザいだけです

0442デフォルトの名無しさん

2010/11/01(月) 23:35:11

>>438は単に、なんでgetjmpじゃないんだと言いたいだけだろう。
あと同一ヘッダーに関係ない関数が収録されてる例なんて山ほどあるので>>439も言いたいことはわかるがやや変。

実際名前の対応は取れてないしな。set_longjmpとexecute_longjmpとかならどうだろう。

0443デフォルトの名無しさん

2010/11/01(月) 23:35:57

>>441
わからないならレスしないで下さい
ウザいだけです

0444デフォルトの名無しさん

2010/11/01(月) 23:57:42

>>442
ラベルと goto が１：ｎの関係なのは考えるまでもないことで
ロクに使いもせずに毛嫌いしたばかりに setjmp と longjmp の関係を誤解した間抜けが
藁にもすがる思いで識別名のせいにしただけだろ

0445デフォルトの名無しさん

2010/11/02(火) 00:05:02

なるほどC++0xの話題ですねw

0446デフォルトの名無しさん

2010/11/02(火) 00:06:56

言語の基本
ここがわかんないまま議論しても砂上の楼閣だ

0447デフォルトの名無しさん

2010/11/02(火) 00:09:25

>>437
言われてみればｗ
本当にすみませんでした

0448デフォルトの名無しさん

2010/11/02(火) 00:33:52

>>444
まあいくら御託を並べても名前がクソってことに変わりはないけどなw

0449デフォルトの名無しさん

2010/11/02(火) 21:23:09

それよりも禿げは･･･

0450デフォルトの名無しさん

2010/11/03(水) 08:50:13

さーって、右辺値参照を勉強するか。

ううーーむ、わからん

0451デフォルトの名無しさん

2010/11/03(水) 09:19:19

いつものように0xと関係ない話題になると伸びが早いな

0452デフォルトの名無しさん

2010/11/03(水) 11:09:36

VC10使ってる人とか少ないのかな？lambdaとか右辺値参照とかかなり有益なものが入ってるのに

0453デフォルトの名無しさん

2010/11/03(水) 11:32:37

まだ仕様変わってるし、あまり触りたくない
VC6の悪夢が・・・

0454デフォルトの名無しさん

2010/11/03(水) 12:57:47

右辺値参照の何が難しいのかわからん。

void f(int &x) { puts("L"); }
void f(int &&x) { puts("R"); }

int main()
{
int a = 1;
func(a); // こうやって呼ぶと"L"
func(1); // こうやって呼ぶと"R"
}

これだけのことではないか。

0455デフォルトの名無しさん

2010/11/03(水) 13:09:10

VCというかWindowsがない
俺なんでこのスレ見てるんだろ

0456デフォルトの名無しさん

2010/11/03(水) 13:11:52

こうじゃないの？

void fanku(int &x){ std::cout << "reference" << std::endl; }
void fanku(int &&x){ std::cout << "uhennti sannsyou" << std::endl; }

int main(){
int a = 1;
fanku(a);
fanku(int(a));
}

0457デフォルトの名無しさん

2010/11/03(水) 13:32:22

どっちもあってる

0458デフォルトの名無しさん

2010/11/03(水) 13:40:44

これに
void fanku(int)が加わればどうなるの？

0459デフォルトの名無しさん

2010/11/03(水) 14:24:26

右辺値参照がわかりにくいのは、Standard のどこを読んだらいいのか
いまいちはっきりしないからだと思うけど
rvalue と rvalue reference が違うことを念頭に置いて
以下の原文を読むとわかる…かもしれない。

3.10-1 lvalue,xvalue,prvalue の図

5-6　名前付き右辺値参照は lvalue になる。
　　　名前なしの(関数の戻り値とかの)右辺値参照は xvalue になる。
　　　関数への右辺値参照は、名前のあるなしにかかわらず lvalue になる。

8.3.2-2 左辺値参照と右辺値参照は違う型だが、
　　　　明示的に注記されない限り両者は意味論的に同じ。

13.3.3.2-3
　　　(暗黙の変換S1とS2がありうるとき、S1のほうが適用される条件)
　　　- S1 と S2 が参照束縛で、
　　　　S1 は rvalue (つまり xvalueかprvalue)を右辺値参照に束縛し、
　　　　S2 は左辺値参照を束縛するとき。
　　　- S1 と S2 が参照束縛で、両者が同じ型を参照していて、
　　　　S1 のほうが const/volatile の修飾が少ないとき。
　　　　(片方が参照で、片方が値のときはあいまい)

ついでに
13.3.1-4 と -5 あたりで
　　struct A { void hage(); void hige()&; void hoge()&&; };
の違いがわかるはず。

0460デフォルトの名無しさん

2010/11/03(水) 14:33:46

いや、この程度のことならいいけど。
ところで、int(a)は型キャストだと思うが、これも右辺値？

constが絡んでくるとどうなの？
参照返しがなされたときは？
一時オブジェクトであってもそのオブジェクトを受けた関数側に
参照引数が使ってある場合、その関数内では左辺値になるよね？

こういうことがゴチャゴチャしていてC++は複雑なんだよ。

0461デフォルトの名無しさん

2010/11/03(水) 14:45:58

static_cast（他）もtypenameのキャストも右辺値を返すよ。

0462デフォルトの名無しさん

2010/11/03(水) 14:46:20

＞ところで、int(a)は型キャストだと思うが、これも右辺値？
キャストは一時オブジェクトを作るので右辺値

＞constが絡んでくるとどうなの？
constの右辺値参照引数は意味がない（壊せない右辺値なんて…）ので考えなくていい
const T& と (non-const)T&& でオーバーロードするのが基本

＞参照返しがなされたときは？
戻り値の事なら戻り値の型どおり
左辺値参照なら左辺値、右辺値参照ならxvalue

＞一時オブジェクトであってもそのオブジェクトを受けた関数側に
＞参照引数が使ってある場合、その関数内では左辺値になるよね？
関数内ならそれも引数の型どおり
左辺値参照なら左辺値、右辺値参照ならxvalue

別にゴチャゴチャしてないと思うが
というか右辺値参照の評価が左辺値だったりした昔に比べればずいぶんスッキリした

0463デフォルトの名無しさん

2010/11/03(水) 15:06:42

>>462

あんたはそう言うけどさ、一般の人間にはついていけんよ。
右辺値、左辺値なんて言葉は昔から使ってあったと言うけど
誤解を招くから使わない方が良いと思う。

(1) どういう場合に無名の一時オブジェクトが生成されるのか？
(2) 無名オブジェクトでも名前つきオブジェクトとして扱われる
ケースがあるが、それはどのようなケースか？

で箇条書きしてくれた方がまだまし。

みたいなもので
そのケースを箇条書きで示してくれた方がまだす。

そして一時オブジェクトであっても関数側の参照引数で受け取られた
ときは名前つきオブジェクトになってしまう
されたときには
で参照引数として

0464デフォルトの名無しさん

2010/11/03(水) 15:08:09

↑ああ、ゴミ消すのを忘れた。

0465デフォルトの名無しさん

2010/11/03(水) 15:49:15

実体として存在するのは、
3.10-1
・lvalue (名前付き変数/&戻り値) と
・xvalue (&&戻り値) と
・prvalue (即値/値で戻ってきた戻り値)

だけで、glvalue とか rvalue とかいうのは
上記3つのうち二つをまとめて呼ぶときの略称みたいなもの。

「左辺値には lvalue と xvalue があって、
　右辺値には xvalue と prvalue がある…??」

のように思ってしまうと、訳が分からなくなる。
そうじゃなくて、無機質に、rvalue は xvalue と prvalue の総称なんだな、と考える。

そして左辺値参照と右辺値参照も、上の用語とは切り離して考える。

「rvalue」という用語が出てきたとき、「右辺値参照」を連想してはいけない。
この二つはカテゴリが違う概念だから。
「rvalue」と言われたら、「xvalue か prvalueだな」と思って読む。

ちなみに、参照に関しては↓のようになっている。
8.5.3-5
　・左辺値参照は lvalue を受け取れる
　・特にconst左辺値参照は、なんでも受け取れる
　・右辺値参照は、xvalueとprvalueを受け取れる。

0466デフォルトの名無しさん

2010/11/03(水) 15:57:14

質問する側の分際で横柄だな
別にいいけど

(2)はxvalueのことだから、右辺値参照型の変数が評価される時だけだな

(1)はめんどくさいな
・組み込みリテラル
・組み込み演算子の結果、ただし以下の左辺値を生ずる物は除く
　・前置++、--
　・単項*
　・[]
　・メンバの参照 . .* -> ->*
　・=および+=の類
・関数（オーバーロード演算子とユーザー定義リテラルを含む）の戻り値、ただし左辺値参照型を返す場合を除く
・キャストおよびコンストラクタ呼び出し、ただし左辺値参照型への変換を除く

きっと何か忘れてる

0467465

2010/11/03(水) 16:04:35

何を言いたかったかというと、

> (2) 無名オブジェクトでも名前つきオブジェクトとして扱われる
> ケースがあるが、それはどのようなケースか？

こういう疑問が生じるのは多分
「右辺値は無名だけど右辺値参照は名前付きで…???」
みたいに用語の混乱を生じているからであって

「prvalue か xvalue は rvalue reference で受け取ることができて、
rvalue reference で宣言された変数は lvalue だ」

と言えば混乱はない。

0468デフォルトの名無しさん

2010/11/03(水) 16:17:03

＞rvalue reference で宣言された変数は lvalue だ
xvalueじゃないの？

0469デフォルトの名無しさん

2010/11/03(水) 16:17:18

xvalueってstd::moveで生成する以外だとどんなのがあるの？

0470デフォルトの名無しさん

2010/11/03(水) 16:18:39

あ、右辺値参照の引数もか

0471デフォルトの名無しさん

2010/11/03(水) 16:27:00

>>468
5章の第6段落に書いてあるけど、
名前付き&&参照は lvalue。
関数の戻り値とか、名前のない&&参照は xvalue。

だからf(int&& a) の引数 a は lvalue。

0472デフォルトの名無しさん

2010/11/03(水) 16:32:03

そうだったのか
じゃあこれって合法なの？

int &&x = 0;
x = 42;

なんだかなあ

0473デフォルトの名無しさん

2010/11/03(水) 16:40:43

>>472
一時変数が作られてるから合法のようだね。
まあ、右辺値参照と明確に指示したんだからしかたなくね

0474デフォルトの名無しさん

2010/11/03(水) 16:55:34

STLに右辺値参照使うのはいいんだけど、関数の種類が増えて実行ファイルが肥大しない？

0475デフォルトの名無しさん

2010/11/03(水) 17:23:54

おお！何だこの難解なレスの伸びは。。。

みんな静かに見てるんだな、怖ひ

0476デフォルトの名無しさん

2010/11/03(水) 17:28:09

そりゃ主要なコンパイラがじわじわと対応してきているからね

0477デフォルトの名無しさん

2010/11/03(水) 18:01:03

>>474
インライン展開されるし、ムーブのコードのほうが小さいだろう。でなければ右辺値参照は使わない。

0478デフォルトの名無しさん

2010/11/03(水) 22:40:07

>>462
> 関数内ならそれも引数の型どおり
> 左辺値参照なら左辺値、右辺値参照ならxvalue

右辺値参照引数には関数内なら名前がついてるんで、
lvalue になるんじゃないの？
move なりなんなりかまさないと xvalue にはならないと
思うんだけど。

0479デフォルトの名無しさん

2010/11/03(水) 23:40:52

>>478
レスが入り乱れててわかりづらいけど
それはもう訂正済み

0480デフォルトの名無しさん

2010/11/04(木) 00:32:03

ごめん分からなくなってきた
名前のない&&参照って例えばどんなの？

0481デフォルトの名無しさん

2010/11/04(木) 01:06:35

>>480
T&& move()
↑こんなのとか。

static_cast<T&&>(t)
↑こんなのとか。

0482デフォルトの名無しさん

2010/11/04(木) 08:21:17

現状、ムーブコンストラクタって明示的に書かないと駄目なんだっけ？

0483デフォルトの名無しさん

2010/11/04(木) 11:26:20

このスレずっと見てきて、右辺値参照がようやくわかってきた。
みなさん、ありがとう。

特に、>>465 >>467 さんの明確な説明が参考になりました。

右辺値参照やmoveを説明した英文の和訳を読んでも(訳がまずいという
のではなく、オリジナルの英文自体の説明がわかりにくい)、
なかったが、このスレを拾い読みしたら

0484デフォルトの名無しさん

2010/11/04(木) 13:59:14

コンセプトさん復活したの？

0485デフォルトの名無しさん

2010/11/04(木) 19:23:25

>>482
現状Yes

0486デフォルトの名無しさん

2010/11/04(木) 20:02:20

>>484
現状No

0487デフォルトの名無しさん

2010/11/05(金) 16:02:03

じゃあコンセプトさん使えるコンパイラは0xではなく独自の仕様ということか・・・

0488デフォルトの名無しさん

2010/11/05(金) 18:11:43

曲がりなりにもコンセプトさん使えるコンパイラって
今のところConceptGCCしかないだろ
開発中止だけど

0489デフォルトの名無しさん

2010/11/05(金) 20:55:35

ConceptGCCが開発中止となり
もうこの世にまともなConceptを実装したコンパイラはありません。

Conceptさんの復活を祈る。
祈るだけで何が出来るわけではないが。

0490デフォルトの名無しさん

2010/11/05(金) 22:55:07

右辺値参照とコンセプトは車の両輪みたいなもの
片方がないと、大変悲しい

// 次の３行分はよく理解できる
int a1 = 0;
int& a2 = a1;
int&& a3 = 0;

// 次の２行はどうなるんだろう？
int& a4 = a3;
int&& a4 = a2;

// もう訳分からん。。
int& a5 = a4;
int&& a6 = a5;
int& a7 = a6;

0491デフォルトの名無しさん

2010/11/05(金) 23:02:36

rvalue referenceとconceptは、あんまり関係がないように思えるがな。

一体何が分からないのか分からん。

int& a4 = a3; // a3はlvalueなのでOK
int&& a4 = a2; // a2はlvalueなのでエラー

int& a5 = a4; // a4はlvalueなのでOK
int&& a6 = a5; // a5はlvalueなのでエラー
int& a7 = a6; // a6はlvalueなのでエラー

0492デフォルトの名無しさん

2010/11/05(金) 23:03:00

>>490
どこにコンセプトが関係するのさ

0493デフォルトの名無しさん

2010/11/05(金) 23:17:00

>>491
a7はa4と同じだからOKじゃね？

0494デフォルトの名無しさん

2010/11/05(金) 23:30:42

>>493
&を読み間違えた。

0495デフォルトの名無しさん

2010/11/05(金) 23:35:42

必要なのはコンセプトよりも、変な記号を置き換えるわかりやすい予約語だよな……。

0496デフォルトの名無しさん

2010/11/05(金) 23:41:56

>>491
>>492
右辺値参照とコンセプトが C++0x の
２本柱のように自分にとって見えたので

車の両輪は良くない比喩でした。すまん

>>491
エラーになる理由について詳しく教えてください。
N3126 から該当部分を指摘して貰えるとありがたいです。

以前GCCで試したら、エラーにならなかったような記憶が
あるのですが、皆さんの処理系ではどうですか？

0497デフォルトの名無しさん

2010/11/05(金) 23:46:10

Conceptさん・・・。。。

0498デフォルトの名無しさん

2010/11/05(金) 23:46:59

記憶違いだと思うぞ
VC++2010は正しくエラー

0499デフォルトの名無しさん

2010/11/05(金) 23:53:55

ずっと、疑問に思っていたので、２つ質問。
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2027.html
にある２つ目のコード例：
A a;
A&& a_ref2 = a; // an rvalue reference
は、エラーになる旨が書いてないけど、不適切な例？

また、
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm#References%20to%20References
では
the reference collapsing rules are:
* A& & -> A&
* A& && -> A&
* A&& & -> A&
* A&& && -> A&&
とあるが、あらゆる参照の参照がエラーにならないことを前提にしている？

いずれも古い文書だから、現在のドラフトの内容と合わないのかもしれません

0500デフォルトの名無しさん

2010/11/06(土) 00:18:12

古いね
右辺値参照をlvalueで初期化するのが禁止されたのは最近だったと思う

参照の参照のルールは今も生きてる
そのproposalにも書いてるけど、テンプレートで発生する事があるので取り決められた

template<class T> class Foo{ T &&x; };

Foo<int&> foo; //foo.xはint& &&だからint&

0501デフォルトの名無しさん

2010/11/06(土) 00:25:52

>>496
＞エラーになる理由

・5章6段落(p85)　　　(何がxvalueか)
・8.5.3節5段落(p206)　(参照は何を初期化子に取れるか)
を読んで。読むのが面倒だったらスレのちょっと上のほうに説明されてる。

>>499

> A a;
> A&& a_ref2 = a; // an rvalue reference
> は、エラーになる旨が書いてないけど、不適切な例？
これは今はもう不適切。いつから変わったかは知らない。

> the reference collapsing rules are:

は n3126 では 8.3.2節6段落に同じことが書かれてるから、
今もルールは変わってない模様。

> あらゆる参照の参照がエラーにならないことを

参照の参照はそもそも、あってはいけない(8.3.2節5段落)と書かれてる。
あくまでただの collapsing rule。

0502デフォルトの名無しさん

2010/11/06(土) 02:29:08

Win32API質問箱からきました。
C++0xでは、basic_string のバッファの連続性が保証されるようになったわけですが、
現実問題として、わざわざ不連続バッファを使うような実装が存在するのでしょうか。

0503デフォルトの名無しさん

2010/11/06(土) 03:03:12

>>502
その質問だと、存在しないことの証明はできない、としか言えないね。
ほんとうに聞きたいことはそんなことじゃないんだろうけど。

0504デフォルトの名無しさん

2010/11/06(土) 03:11:59

vectorよりdequeのが性能良かったりするし

0505デフォルトの名無しさん

2010/11/06(土) 03:33:05

dataとc_strが定数時間で行われる必要があるので
非連続な実装って不可能じゃね

0506デフォルトの名無しさん

2010/11/06(土) 03:40:06

>>505 complexity の要件が追加されるのも C++0x から。

0507デフォルトの名無しさん

2010/11/06(土) 08:19:06

>>502
文字列を+=するときに、バッファーを取り直して伸張するのではなく、新たにバッファを追加して複数のバッファーを使うのは
ありそうだけど、[ ]の効率を考えたら取り直すほうを選択するだろう。

0508デフォルトの名無しさん

2010/11/06(土) 08:35:40

初めて取り出すまでは不連続にしたほうが効率的だよね

0509デフォルトの名無しさん

2010/11/06(土) 09:29:25

確かにそうなんだけど、ここ最近、マルチスレッド化でそうとは限らなくなったね。
constメンバー関数で参照しようとしたときにでも文字列オブジェクトの内部が変化してしてしまう。
内部的にこっそり直してもいいんだけど、マルチスレッド下では再入の保護のためにmutexが必要になる。
過去の文字列クラスは、参照カウンタでバッファーを共有する実装もあったけど、マルチスレッド化で共有での実装も見かけなくなってきたね。

0510デフォルトの名無しさん

2010/11/06(土) 11:15:01

basic_stringでないなら、不連続な実装としてropeがある

0511デフォルトの名無しさん

2010/11/06(土) 11:35:13

>>500
>>501

よくわかりました。ありがとうございます

0512デフォルトの名無しさん

2010/11/06(土) 15:11:16

>>502
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530

0513デフォルトの名無しさん

2010/11/06(土) 17:01:15

pod class Hoge
{
public:
int x;
// NoPod nopod; error
};
void func(pod Hoge & hoge);
そろそろこの指定子が欲しい

0514デフォルトの名無しさん

2010/11/06(土) 17:07:25

lvalue、 prvalue、 xvalue のことや右辺値参照について、このスレの
おかげである程度理解できましたが、まだ完全にわかっていません。

うまく言えないのですが、

(1) std::moveは、右辺値参照で受け取ることができるようにlvalueや
prvalueをxvalueに型変換するだけ。

(2) オブジェクト a と b が持っている(ポインタa.pとb.pで管理して
いる) 動的メモリの交換をポインタのswap(a.p, b.p)の形で行う、
と言うのがmove semantics。

(3) move semanticsは、コピーコンストラクタと代入演算子を右辺値参照
でオーバーロードした、次の関数をユーザ(あるいはライブラリ)が定義する
ことによって実現する。

X(X&& x); // moveコンストラクタ
X& X::operator=(X&& x); // move semanticsによる代入

これらが用意されてなければ、従来のコピーコンストラクタと代入演算子

X(const X& x);
X& X::operator=(const X& x);

が呼ばれてしまう。の理解でいいでしょうか？

0515デフォルトの名無しさん

2010/11/06(土) 17:09:47

>>272
>つうか、おそらく単なる参照渡し。
>ムーブ後の抜け殻に触った結果はどうせ未定義なんだから、仕様は満たしてるよね。

抜け殻のオブジェクトでも消滅するときはデストラクタが呼ばれ、デストラクタ内
では delete p; みたいなものがあると思うのですが。

>>459
>関数への右辺値参照は、名前のあるなしにかかわらず lvalue になる。
｢関数への右辺値参照｣の意味を解説していただけるとありがたいです。

>struct A { void hage(); void hige()&; void hoge()&&; };
hige()&; hoge()&& ってどういう意味でしょうか？

0516デフォルトの名無しさん

2010/11/06(土) 17:27:02

>>513
static_assert(std::is_pod<Hoge>::value);

0517デフォルトの名無しさん

2010/11/06(土) 18:13:17

>>515
> ｢関数への右辺値参照｣の意味
#include <cstdio>
int hage(){ return 1; }
void test(int (& )()) { std::puts("lvalue!"); }
void test(int (&&)()) { std::puts("xvalue!"); }
int main(){ test(static_cast<int (&&)()>(hage)); }

↑を実行すると "lvalue!" と表示される。
だから
auto xval() -> int(&&)() { return static_cast<int (&&)()>(hage); }
は戻り値の型に return がバインドできなくてエラー。

何のために存在するのか不明…。誰か教えて。

> struct A { void hage(); void hige()&; void hoge()&&; };
のメンバ関数は、内部的には
　void hage(A& this); void hige(A& this); void hoge(A&& this);
のように扱われるんだけど、このうち禿だけは特別扱いで、
　A().hage(); // 引数 A& this に prvalue をバインドしてる
みたいな呼び出しが可能。ヒゲは禿に似てるけど、そういう特別扱いされない。

0518デフォルトの名無しさん

2010/11/06(土) 18:18:40

>>517
関数型の xvalue を言語要素として排除するためのルールじゃないかな？
これで少しは考えることが減るのかも。

0519デフォルトの名無しさん

2010/11/06(土) 20:58:00

>>515前半
class ptr {
int *p;
public:
ptr() : p(new int) {}
ptr(ptr const& y) : p(new int(*y.p)) {}
ptr& operator =(ptr const& y) {ptr(y).swap(*this); return *this;}
~ptr() {delete p;}
void swap(ptr& y) {std::swap(p, y.p);}
};
こんなよくありそうなクラスにムーブ構築・代入を定義する場合、
パッと考えつくだけでも2とおりある（ここでは代入で書いたけど、コンストラクタでも同じ）。
ptr& operator =(ptr&& y) {
swap(y);
return *this;
}
ptr& operator =(ptr&& y) {
delete p;
p = y.p;
y.p = nullptr;
return *this;
}
ムーブした後、yがどうなっているか違うけど、どっちでもムーブとしての挙動は行われるはず。
もちろん、yはデストラクタが呼ばれても問題ないのも同じ。

こういう話でいいのかな。

0520デフォルトの名無しさん

2010/11/07(日) 11:46:26

>>519

x=std::move(y); の代入演算子の定義で

(1) x.pとy.p間でswapを行う。
(2) delete x.p; x.p=y.p; y.p=nullptrを行う。

のいずれかの処理が実行されているのなら、デストラクタが呼ばれた
場合も納得できます。

しかし、>>272 に対する

>>273 (272ではなくて273でした)
>つうか、おそらく単なる参照渡し。

>>275
>中身がただの関数ポインタになってて、ポインタのムーブはただのコピーが最善手

のレスを読んで混乱しました。まさか、x.p = y.p 相当の処理だけが実行されている
んでは？と思ってしまいました(そんなわけないか！)。

>>272の質問のきっかけになった >>253 も単なる関数ポインタのコピーであって、
オブジェクトのムーブではないのではないか？という気がします。

0521デフォルトの名無しさん

2010/11/07(日) 12:01:40

ムーブコンストラクタが呼び出されるって事とムーブコンストラクタの実装が元を破壊しない実装ってのは別々の話でしょ

0522デフォルトの名無しさん

2010/11/07(日) 17:20:48

export キーワードの新しい使い道を考えてみた：
以下のように、スコープを脱出しても有効になるようにできる。
export--extern でやりとりする。

　{
　　export int i = 0;
　　export typedef int INT;
　}

　using extern int i;
　using extern typename INT;

　INT n = 0;
　++i;
　assert(i == 1);

たとえば、
　try {
　　　int i = 0;
　　　export int j = 42;
　　　using export INT = int; // export typedef int INT;
　　　std::cout << i << ' ' << j << '\n'; // 0 42
　　　throw "Foo"
　} catch (...) {
　　　int i = 1;
　　　using extern int j;
　　　using extern typename INT;

　　std::cout << i << ' ' << j << '\n'; // 1 42
　　throw INT();
　}
みたいに使えたら便利だなあ。以上、妄想でした。

0523デフォルトの名無しさん

2010/11/07(日) 17:29:26

デストラクタいつ呼ばれんだよ。

0524デフォルトの名無しさん

2010/11/07(日) 17:53:52

スコープ抜けるところでコピーされて、元のはデストラクトでは。

0525デフォルトの名無しさん

2010/11/07(日) 23:11:50

スコープの外で変数宣言したほうがわかりやすいと思うけどな。

0526デフォルトの名無しさん

2010/11/07(日) 23:58:22

初期化される前に例外投げられた場合の仕様が必要になる事は間違いない
フラグ自分で立てて判断、ってんじゃ面倒くさいからな

まあ try-catch 時に try 内の変数を使いたい場合はよくあるので欲しい所だが、
export やら extern やら無くてもそのままアクセスできたのでも良いと思う

0527デフォルトの名無しさん

2010/11/09(火) 17:13:01

>>522
try export E {
　　　int i = 0;
　　　int j = 42;
　　　using INT = int; // typedef int INT;
　　　std::cout << i << ' ' << j << '\n'; // 0 42
　　　throw "Foo"
　} catch (...) {
　　int i = 1;
　　std::cout << i << ' ' << E::j << '\n'; // 1 42
　　throw E::INT();
　}
とした方が面倒くさくなくていい

0528デフォルトの名無しさん

2010/11/09(火) 17:44:46

簡単な内容のメソッドが多いため、クラス直下のメソッドを減らすために
使用範囲の限られるメソッドをメソッド内に格納したところ、
次のようになってしまいました
class hoge{
/*...*/
　void fuga{
　　auto piyo=[this](...){
　　　auto piyopiyo[this](...){　//VC++ではエラー
　　　　/*...*/
　　　}
　　　/*...*/
　　}
　}
}
g++ 4.5.1ではコンパイルが通るのですが、VC++2010ではエラーが出ます
thisポインタを二重にキャプチャするのは規約違反なんでしょうか

0529デフォルトの名無しさん

2010/11/09(火) 19:41:14

class typedef int Hoge;

でstrong typedefとかどうよ

0530デフォルトの名無しさん

2010/11/10(水) 08:00:59

>>528
5.1.2-12
　変数が「キャプチャされる」とは、明示的もしくは暗黙的にキャプチャされることだ。
　(中略)
　もし this がラムダ式にキャプチャされるなら、
　そのラムダ式を囲んでいる一番内側の関数は、非静的メンバ関数でないとだめ。

って書いてある。

同じ個所に、ラムダの中のラムダを [this] じゃなくて [&] にすることで
this をもう一度キャプチャさせる例が載っていて、
実際 VC でもそれはできるので

『外側のラムダ式を「一番内側の関数」だと思って
　それが非静的メンバ関数じゃないからエラー』
というわけではなさそう。

「キャプチャされる」ことを「キャプチャリストに現れる」ことだと誤読すれば
VC の挙動も説明できるけど、多分 g++ が正しい。

0531デフォルトの名無しさん

2010/11/10(水) 18:14:04

2つ目のthisがpiyoを指してると認識してんだろうなあVC++は

0532デフォルトの名無しさん

2010/11/10(水) 18:32:11

なるほどラムダオブジェクトを指してると思ってる訳か・・・

0533デフォルトの名無しさん

2010/11/13(土) 20:13:57

auto s=[](int x){return x*2.0;};
typedef decltype(s) m;
これを、VC10で１行にまとめて下のようにすると、error C3477: ラムダは評価されていないコンテキストでは使用できませんエラーが出ます
typedef decltype([](int x){return x*2.0;}) mm;
autoの関数定義に使いたいんですけど、１行にまとめる方法はないですか？

0534デフォルトの名無しさん

2010/11/13(土) 20:16:12

現行仕様のでもいいから完全に準拠したC++コードをMVC++に変換するコンパイラがあってもいいはずだ

0535デフォルトの名無しさん

2010/11/13(土) 20:35:33

ラムダのtypedefとか基本的に無茶だろ
そういう風に使うもんじゃない

0536デフォルトの名無しさん

2010/11/13(土) 21:00:48

std::function使え

0537デフォルトの名無しさん

2010/11/13(土) 21:04:53

template <class X> X identify(X);
typedef decltype(identify([](){}) type;

試したことはない

0538デフォルトの名無しさん

2010/11/13(土) 21:29:40

decltype とか sizeof とかにラムダ式入れちゃいけないきまりになってる

0539デフォルトの名無しさん

2010/11/13(土) 22:06:07

>>535-538 ありがとうです。
>>537の方法で通りましたです。この抜け穴で何とかなりそうです

0540デフォルトの名無しさん

2010/11/13(土) 22:39:42

>>539
リビルドしたら通らなくなった？？？なぜに？

0541デフォルトの名無しさん

2010/11/13(土) 23:00:18

もし通ることかあるとすれば、そのほうが間違いっぽいんだけど

0542デフォルトの名無しさん

2010/11/13(土) 23:26:23

内部的にはラムダ式はそれぞれ固有の型として処理されるから、
＞typedef decltype([](int x){return x*2.0;}) mm;
これが仮に通ったとしても、mm型は何にも使えないぞ
だからラムダ式じゃなくstd::functionを使うのが正しい
typedef std::function<int(int)> mm;
ってしろこれなら
＞mm a=[](int x){return x*2.0;};
って宣言・代入できる

0543デフォルトの名無しさん

2010/11/14(日) 01:00:24

functionはboostやtr1でおなじみだと思いきや
C++系のスレ見ててもあまり使われてない感じがする
結構便利なのに

0544デフォルトの名無しさん

2010/11/14(日) 01:02:58

パッと見中で何やってんのか想像できないライブラリってなんか抵抗あるんだよね

0545デフォルトの名無しさん

2010/11/14(日) 02:22:39

ラムダ式を使う場合、大抵はラムダ式を直接渡せば事足りるからな。

0546デフォルトの名無しさん

2010/11/14(日) 03:24:32

functionとlambdaで事実上関数内関数が作れるのはよい

0547デフォルトの名無しさん

2010/11/14(日) 03:28:06

>>544
単に共通の非テンプレートなベースクラスを継承したテンプレートなクラスを作ってるだけ。
まあ、vtable自前とか変態的な実装もあるけど。

0548デフォルトの名無しさん

2010/11/14(日) 03:30:17

ラムダは夢が広がるね。
BOOST_SCOPE_EXITの見た目すっきりの代替品とかいろいろ出てきてる。

0549デフォルトの名無しさん

2010/11/14(日) 07:15:45

関数オブジェクトの戻り型をhoge::result_typeで貰ってるんだけど、lamdaはresult_typeがないから面倒だな。

0550デフォルトの名無しさん

2010/11/14(日) 08:14:47

>>546
見やすくなるよな

0551デフォルトの名無しさん

2010/11/14(日) 08:59:11

>>541
簡易ビルドが効いてて、変更が反映されてなくて通ってたっぽい。リビルドでそれがリセットされた。

0552デフォルトの名無しさん

2010/11/16(火) 22:25:48

ムーブさんの問題がついにコピーさんに飛び火してしまった
一体どうなるのか

0553デフォルトの名無しさん

2010/11/16(火) 22:28:30

いったん0xはなかった事にするのがいいと思う

0554デフォルトの名無しさん

2010/11/16(火) 22:32:22

0x以前を無かったことにしろ

0555デフォルトの名無しさん

2010/11/16(火) 22:37:42

C++を放り投げてネイティブC#であらゆる問題が解決するんだよね

0556デフォルトの名無しさん

2010/11/16(火) 22:44:23

>>552
規格策定がさらに1～2年伸びるわけですね、わかります

0557デフォルトの名無しさん

2010/11/17(水) 00:06:00

絵に描いたような矛と盾。

0558デフォルトの名無しさん

2010/11/17(水) 00:09:07

ちょっとムーブさんとコピーさんの関係まとめてよ

0559デフォルトの名無しさん

2010/11/17(水) 00:15:06

ムーブさんのせいで家庭崩壊の危機に陥って、ムーブさんの立ち入り禁止を命ずる裁判所命令で
解決したかに見えたが、土壇場で旦那が実はコピーさんが家のことを勝手にあれこれやるのも快く思ってなかったとか
言い出したせいで、示談で落ち着くはずが混迷化(いまここ)

0560デフォルトの名無しさん

2010/11/17(水) 00:34:15

ムーブさんの行動が上級生の邪魔になるというのでムーブさんの権限を一部剥奪することになったが、
校長先生が「上級生のコピー君も今まで同じことをしておった喃」とか言い出して、コピーさんの
権限まで制限されることになってしまった。

0561デフォルトの名無しさん

2010/11/17(水) 02:49:00

よっしゃー。優等生がいなくなって学級世紀末覇者も時間の問題。

0562デフォルトの名無しさん

2010/11/17(水) 06:46:44

暗黙のコピーさんと暗黙の方変換は昔から挙動が怪しかったが、周りがあわせることで事なきを得た。
ムーブさんもそうなってほしい。

0563デフォルトの名無しさん

2010/11/17(水) 07:16:04

暗黙のコピーはCの構造体との互換性のため必須だったんじゃ

0564デフォルトの名無しさん

2010/11/17(水) 08:28:47

互換性は関係ないだろ。
これはユーザー定義のデストラクターが定義されている場合、
暗黙のコピーコンストラクターの生成されないべきという話なんだから。

0565デフォルトの名無しさん

2010/11/17(水) 09:53:31

autoさん「互換性なんて投げ捨てろよｗｗｗ」

0566デフォルトの名無しさん

2010/11/17(水) 10:28:27

auto使っても型違い警告出るとこあるよな

0567デフォルトの名無しさん

2010/11/17(水) 12:51:53

仮にいちゃもん付けられる前までのコピーについて>>1-のテンプレで書くとしたらどんなのになる？

0568デフォルトの名無しさん

2010/11/17(水) 13:43:29

今までの暗黙のコピーは、
今まさにうんこしているやつがいるのに、便器の掃除を始めるようなものかな。

0569デフォルトの名無しさん

2010/11/17(水) 17:47:49

いや
下手に便所を奪ったら先に用たしてた奴がそこらじゅうに糞便まき散らす恐れがあるから
後発で便意をもよおした奴は隣に便所作ってウンコするみたいな様子

0570デフォルトの名無しさん

2010/11/17(水) 17:50:31

この業界ってそのまま説明すればいいのにわざわざ分かりにくい例えしてくるオナニスト大杉やでしかし

0571デフォルトの名無しさん

2010/11/17(水) 17:53:45

もどかしさと被害の表現がえらく的を得てるようだが

0572デフォルトの名無しさん

2010/11/17(水) 18:21:34

的は射るものです

0573デフォルトの名無しさん

2010/11/17(水) 18:35:20

的を射るのはいいけど得たらダメとかおさわり禁止みたいなこというなよ

0574デフォルトの名無しさん

2010/11/17(水) 18:44:36

>>564
なるほどそういう事か
まあ = default あるし、別にいいんじゃない、と思うね
boost::noncopyable とか不要になるし、
そもそもコピー可能かどうかちゃんと考えてないクラスは
コピー禁止すべきだと思うし

0575デフォルトの名無しさん

2010/11/17(水) 19:34:12

不要にはならないだろ
deprecatedなだけで無くなりはしないんだから自衛は必要

0576デフォルトの名無しさん

2010/11/17(水) 19:58:37

古いコードで警告が数百数千と出るようになるだけ。

0577デフォルトの名無しさん

2010/11/17(水) 22:26:54

>>572
的を得るで合ってる

0578デフォルトの名無しさん

2010/11/17(水) 22:29:50

まさに2ch的日常

0579デフォルトの名無しさん

2010/11/17(水) 22:33:47

>>572
的を射るで会ってる

0580デフォルトの名無しさん

2010/11/17(水) 23:58:58

>>577
wwww

0581デフォルトの名無しさん

2010/11/18(木) 00:13:17

的を得るでぐぐれ

0582デフォルトの名無しさん

2010/11/18(木) 00:32:09

賞を射止めるとかあるように
的を得るでもいいのではないだろうか、射的を制する的な意味合いで

0583デフォルトの名無しさん

2010/11/18(木) 00:41:17

プログラマならあいまいな表現は使うな
以上

0584デフォルトの名無しさん

2010/11/18(木) 02:24:02

C++0x風にいうと
「的を得る」は独自拡張であり
正式に導入されるまでは
コンパイルエラー。

的を得るが正しいとか頑張って涙目で主張してもコンパイルエラーは
許してくれないことは思い知っているはず、

0585デフォルトの名無しさん

2010/11/18(木) 02:54:06

例えとか要らないからボケカスアホンダラ

0586デフォルトの名無しさん

2010/11/18(木) 11:30:19

「的を得る」あたりだと規格には入っていないが主要なコンパイラはデフォルトでサポートしている状態
原理主義者が必死にコンパイラオプション指定して「的を得る」はコンパイルエラーにしなければならない
とか喚いている感じ

のように変な例えから変な例えが派生して話がわけわかめになるわけだな。

0587デフォルトの名無しさん

2010/11/18(木) 11:58:37

的を得る/的を失するは別に誤用じゃないんだけどな

0588デフォルトの名無しさん

2010/11/18(木) 13:52:44

自然言語スレになったん？

0589デフォルトの名無しさん

2010/11/18(木) 16:00:39

言語マニアの多いから

0590デフォルトの名無しさん

2010/11/18(木) 16:03:13

日本語0x

0591デフォルトの名無しさん

2010/11/18(木) 17:00:57

自然言語に例えると英語と中国が混ざったようなスレだな

0592デフォルトの名無しさん

2010/11/19(金) 00:41:00

J++とな

0593デフォルトの名無しさん

2010/11/19(金) 21:54:54

>>591
C++/CLIの悪口はやめて！

0594デフォルトの名無しさん

2010/11/19(金) 21:56:58

>>593
だってそれC++じゃないじゃん

0595デフォルトの名無しさん

2010/11/19(金) 22:25:52

BOOST mplやlamadaやspiritはC++に見えないけど確実にC++だしな

0596デフォルトの名無しさん

2010/11/19(金) 22:34:04

あれはC++ではなくてboostという名のなにかだよ

0597デフォルトの名無しさん

2010/11/20(土) 00:50:33

boostの悪口言うなよ
C++0xに標準として取り入れられるライブラリがいくつかあるんだから

0598デフォルトの名無しさん

2010/11/20(土) 00:50:59

ここはObjective-C++の出番か

0599デフォルトの名無しさん

2010/11/20(土) 01:17:47

もしもObjective-C++/CLIが出たら…

0600デフォルトの名無しさん

2010/11/20(土) 01:31:44

Objective-C++0x/CLIを待つしか無いな

0601デフォルトの名無しさん

2010/11/20(土) 15:52:59

vector<int> v;
v::size_type s;

みたいに出来れば素敵なのに
次の規格には入れてくれよな校長

0602デフォルトの名無しさん

2010/11/20(土) 16:19:19

decltype使えばいいんじゃね？

0603デフォルトの名無しさん

2010/11/20(土) 16:22:39

decltypeって長々とうつのめんどくさいじゃん
typedefの手間もいらないしこれ出来ればかなり便利だと思うんだよね

0604デフォルトの名無しさん

2010/11/20(土) 16:33:58

カスだな

0605デフォルトの名無しさん

2010/11/20(土) 16:38:12

>>528
https://connect.microsoft.com/VisualStudioJapan/feedback/details/621572/
＞修正しない
＞Unfortunately we will not have time to fix this issue for the next release of Visual Studio.

(ノ∀`)タハー

0606デフォルトの名無しさん

2010/11/20(土) 17:39:16

まあどうせ未完成なんだし
そこだけ凝っても仕方ないわな

0607デフォルトの名無しさん

2010/11/21(日) 12:25:11

>>601
v.iterator begin(){return v.begin();}
て書くのか？混乱するだろう。同じ目的に複数の記述方法があるとあいまいになるだろ。
>>603
多少のタイプ量を減らすよりtypedefして型を明確にしたほうが読みやすいぜ。

0608デフォルトの名無しさん

2010/11/21(日) 12:28:47

大抵はautoで大丈夫じゃね
メンバ変数とかは無理だが

0609デフォルトの名無しさん

2010/11/21(日) 12:29:46

>>607
v::iterator it = v.begin(), end = v.end();
って書くんだよ

0610デフォルトの名無しさん

2010/11/21(日) 17:59:18

int main(){[](){}();}

0611デフォルトの名無しさん

2010/11/21(日) 18:01:00

Perl以下の糞文法でゲソ

0612デフォルトの名無しさん

2010/11/21(日) 18:02:03

Perlには敵わないんでなイカ？

0613デフォルトの名無しさん

2010/11/21(日) 20:14:52

ラムダ式っておでんっぽい

0614デフォルトの名無しさん

2010/11/21(日) 20:18:37

int main(){<|()[]-;}

0615デフォルトの名無しさん

2010/11/21(日) 20:26:17

int main(){[=]()->O{}();}

0616デフォルトの名無しさん

2010/11/21(日) 20:29:38

int main(){くコ:彡;}

0617デフォルトの名無しさん

2010/11/24(水) 17:50:12

auto main() -> int { auto final = [](){}() ; }

0618デフォルトの名無しさん

2010/11/24(水) 17:54:02

実行したらダメだろ
autoがvoidに推測される

0619デフォルトの名無しさん

2010/11/29(月) 08:54:09

結局OpenCVとかC++で書かれたものは、そのまま使えるの？

0620デフォルトの名無しさん

2010/11/29(月) 09:23:43

ほぼ使えるよ

0621デフォルトの名無しさん

2010/11/29(月) 10:17:28

decltypeすごく便利
ラムダ式もようやく慣れて来た
早く規格が固まらないかねえ

0622デフォルトの名無しさん

2010/12/05(日) 20:35:22

先月分のペーパーが公開されたか。

noexceptたんやっぱうぜーって言われてる?

0623デフォルトの名無しさん

2010/12/05(日) 23:03:38

contextual keywordってマジでやるのか
勘弁して

0624デフォルトの名無しさん

2010/12/05(日) 23:22:29

attribute何とかの嵐よりはマシ

0625デフォルトの名無しさん

2010/12/05(日) 23:23:52

本物の予約語にして「identifierにも使えるけどdeprecatedです」じゃダメなの？

0626デフォルトの名無しさん

2010/12/06(月) 00:09:33

暗黙デフォルトムーブさんはマジで退学。
defaulted定義のときだけ召喚されるんだね。

>>625
もう予約語追加しないって言っちゃったんじゃなかったっけ?FCDで。

0627デフォルトの名無しさん

2010/12/06(月) 00:11:51

わざわざstd::moveで食わせないといけなくなったのか？

0628デフォルトの名無しさん

2010/12/06(月) 01:07:26

退学は妥当な処置だな

0629デフォルトの名無しさん

2010/12/06(月) 11:06:31

C++0x好きだわー
こうやって何回も議論を重ねると論理の穴を塞いだ規格が出来上がる
一人で作った言語とは大違い

0630デフォルトの名無しさん

2010/12/06(月) 11:22:58

LLバトロイスレ逝け

0631デフォルトの名無しさん

2010/12/06(月) 13:06:48

>>629
その代わり覚えなければならない事が山ほど増えるぞ
初心者向け言語ではますますなくなる

0632デフォルトの名無しさん

2010/12/06(月) 13:27:17

範囲ベースの for ループはどうやって
範囲の長さがわかるんですか？

0633デフォルトの名無しさん

2010/12/06(月) 13:58:17

stdを特別にassociated namespaceに付け加えたADLで、range式を引数に取るbeginとendを探して呼び出す。
配列の場合は、特別に何も#includeしなくても使える。
配列以外の場合は、<iterator>もしくは関連するヘッダーを#includeしなければならない。
std名前空間には、あらかじめbeginとendが定義されていて、これはクラスのメンバー関数、beginとendを呼び出す。

つまり、自作クラスをrange-base forに対応させるためには、
STLのコンテナのようにイテレーターを返すbegin、endという名前のメンバー関数を実装するか。
そのクラスを引数として、イテレーターを返す、begin、endという名前の関数を、
ADLで呼び出せるように実装しておけばいい。

0634デフォルトの名無しさん

2010/12/06(月) 21:52:04

>>633
フリー関数とメンバ関数と、両方固められたらもう予約語級の名前空間汚染度だなぁ。
ってそんな議論もきっと通った上での話しなんだろうなぁ。でもでも、もしかしたら
Concept が抜けたことで、ふさいでたつもりの穴がうっかり空いてたりしそうで怖いなぁ。

0635デフォルトの名無しさん

2010/12/06(月) 23:52:28

暗黙デフォルトコピーも退学にしてくれ

0636デフォルトの名無しさん

2010/12/06(月) 23:57:42

>>635
それはこまるなー。
プロトタイプ作ってるときは効率なんて考えないから、そういう便利機能はありがたい。
関数型ライクというかなんというか。

0637デフォルトの名無しさん

2010/12/07(火) 00:06:55

退学じゃないけどD組行きだろ

0638デフォルトの名無しさん

2010/12/07(火) 00:30:23

n3225だと、暗黙デフォルトムーブさんは退学してなくね？
一部D組に堕ちた暗黙デフォルトコピーと、同じくらいの穏便な処置で済んでるよ。

0639デフォルトの名無しさん

2010/12/07(火) 09:27:05

デフォルトコピーとかユーザーによって反応がまちまちの機能は
コンパイルオプションで決めれるように仕様に明記すれば良いのに

0640アクセス宣言

2010/12/07(火) 10:27:40

わたし、n3225で退学だって・・・ショック。
何よ、そりゃusing宣言ちゃんの方がすこし可愛いかもしれないけどさ。
八方美人っていうの？　わたしからすれば尻軽だけどぉ。

0641デフォルトの名無しさん

2010/12/07(火) 14:46:53

>>639
人の書いたコードと混ぜられなくなるだろ。
言語によってはソースファイル毎に指定できたりもするが、C++は#includeというものがあるし。

0642デフォルトの名無しさん

2010/12/07(火) 15:08:35

コンパイルオプションでそんな動作変わるとかPHPじゃないんだから・・・

0643デフォルトの名無しさん

2010/12/07(火) 15:16:11

キモイ
private "C++0x" extern "C" {
}
private "C99" {
}

0644デフォルトの名無しさん

2010/12/07(火) 16:05:17

>>642
#includeの無い言語ではそんな珍しいものでもないぜ。
FreePascalの、GNU Pascal互換モードとDelphi互換モードなんか、見た目にも別の言語だw

0645デフォルトの名無しさん

2010/12/07(火) 21:04:09

C99の#pragma STDCでも使って切り替えられればいいのに

0646デフォルトの名無しさん

2010/12/07(火) 22:31:07

もう2010年も終わろうとしてるのにまだ0xと言い張るか

0647デフォルトの名無しさん

2010/12/07(火) 22:38:54

2015年が終わるまでは

0648デフォルトの名無しさん

2010/12/07(火) 22:45:41

C++0xの0xは20xy年のまんなか2桁をとったんだよ!
よしこれでこれで2100年まで延々と規格策定を続けられる

0649デフォルトの名無しさん

2010/12/07(火) 22:46:43

ならコンセプトさん復活させようぜ！

0650デフォルトの名無しさん

2010/12/08(水) 01:19:22

もう秒単位で変わる規格にしようぜ！

0651デフォルトの名無しさん

2010/12/08(水) 01:35:21

もう新規さんは出てこないだろうから別に規格とかどーでもいいんじゃないかな
MSとGNU間で摺合の機会を持てば十分でしょ

0652デフォルトの名無しさん

2010/12/08(水) 18:15:19

林檎の人たちを忘れてますよ

彼らは摺り合わせとか応じないだろうなぁ

0653デフォルトの名無しさん

2010/12/08(水) 19:22:41

Symantec C++やWatcom C++がやる気なくしてBorland C++が変な方向へ疾走しだした頃から規格なんてベンダへ押し付ける努力目標になってるからなー

0654デフォルトの名無しさん

2010/12/08(水) 20:35:29

HTML5のように規格厨が蔓延るよりなんぼかマシだわ。

0655デフォルトの名無しさん

2010/12/08(水) 21:48:17

でも規格がないとD言語になっちゃうからな

0656デフォルトの名無しさん

2010/12/09(木) 00:40:09

有能なコンパイラ屋が相次いで離反する「信者を持てない言語」だな

0657デフォルトの名無しさん

2010/12/09(木) 00:46:49

規格はMSとGNUで決めればOK
規格制定委員会なんてイラン

0658デフォルトの名無しさん

2010/12/09(木) 00:48:22

C++0xがこのざまなのは、全て禿げが悪いんだよね

0659デフォルトの名無しさん

2010/12/09(木) 05:49:33

>>652
林檎はgcc使ってるだけじゃん。

0660デフォルトの名無しさん

2010/12/09(木) 05:50:50

>>654
あれほど実装にすりよってもまだそんなこと言われるの
XHTML2厨が聞いたら卒倒しそうだな

0661デフォルトの名無しさん

2010/12/09(木) 06:40:47

C++規格がHTML5規格にように書かれるならば、
すべての実装はMSVC拡張とgcc拡張に加えて、POSIXとWin32 APIとx86インラインアセンブラをサポートしなければならなくなるな。

0662デフォルトの名無しさん

2010/12/09(木) 13:59:53

autoとかめんどくさいこと言わずに最初に代入か初期化された型になるで良いじゃん
そんで初期化されるまでは不定でアクセスするとコンパイルエラーになる

0663デフォルトの名無しさん

2010/12/09(木) 14:02:01

変数は使うときに宣言すればいいだろ。
まさかC言語厨か？
あれだろ、お前は関数の冒頭に変数を全部宣言しておく口だろ。

0664デフォルトの名無しさん

2010/12/09(木) 14:03:18

ちげーよ。なんでそうなるんだよ。ふんころがしは黙ってろ

0665デフォルトの名無しさん

2010/12/09(木) 14:29:01

>>662
うーん良く分からん
最初の代入で型を決めるという実装だと
unsigned x = 0;
void hoge(){
x = 0;
}
このときにローカル変数のxを宣言して初期化なのか、
グローバル変数のxに代入なのか区別つかん気がする。

これを解決するためには結局autoに近いものが必要だよね(javascriptのvarとか)

0666デフォルトの名無しさん

2010/12/09(木) 15:07:53

x( 100 ) ; // グローバルのint xを100で初期化
void hoge()
{
x = 200; // グローバルのxに200を代入
x(300); // ローカルのint xを300で初期化
x = 400; // ローカルのxに400を代入
y = 500; // 型不明でエラー
for( i(v.begin()) , e(v.end()); i!=e; ++i){} // ok
}

こんな感じならautoはいらないかもね

0667デフォルトの名無しさん

2010/12/09(木) 15:14:16

extern x = 0;
x = 1;
void hoge(){
　x = 2;
　assert(extern x == 0 && ::x == 1 && x == 2);
}

0668デフォルトの名無しさん

2010/12/09(木) 15:20:27

なんか B への原点回帰みたいだな

0669デフォルトの名無しさん

2010/12/09(木) 15:51:44

後のStroustrupの語るところによれば、「BCPLに比べれば、C言語は超高級な言語に見えた」ということである。

0670デフォルトの名無しさん

2010/12/09(木) 16:09:03

>>666
なにこれきめぇ

0671デフォルトの名無しさん

2010/12/09(木) 16:40:57

>>666
struct foo{
foo(int);
void operator()(int);
}

とかあるとややこしいことになるな

0672デフォルトの名無しさん

2010/12/09(木) 18:37:21

初期化の代入は := にするとか

0673デフォルトの名無しさん

2010/12/09(木) 18:43:15

それなんてIo

0674デフォルトの名無しさん

2010/12/09(木) 19:00:33

:=とか[a,b)とか使えたらさぞや気持ち良いだろうな

0675デフォルトの名無しさん

2010/12/09(木) 19:36:07

:=はともかく[a,b)はパーサが死にそうw

0676デフォルトの名無しさん

2010/12/09(木) 19:52:43

>>662
ローカル変数の事だと思うけど、
適当な文をコメントアウトしただけで挙動が変わりそうで怖いし、
結局キャストが必要で宣言したんでいいじゃんなケースも多いと思うし、
配列どうすんのって感じだし、
アドレスとる分にはコンパイルエラーになるケースが皆無だし、
C++として全然駄目だと思うぞ

0677デフォルトの名無しさん

2010/12/09(木) 19:53:29

forの後限定、整数限定とかなら実装も簡単だし、実用性も高い

0678デフォルトの名無しさん

2010/12/09(木) 20:01:45

既存の変数を使った場合、同名の新しい変数が使われるのか、
それとも新規の変数が使われるのか分からない

0679デフォルトの名無しさん

2010/12/09(木) 20:02:35

同じ事言ってしまったw

既存の変数を使った場合、同名の新しい変数が使われるのか、
それとも既存の変数が使われるのか分からない

だ

0680デフォルトの名無しさん

2010/12/09(木) 22:31:30

Rubyスレかと思った

0681デフォルトの名無しさん

2010/12/09(木) 22:35:51

a = [1,2,3]
a.each{|a| p a}

1
2
3

こういうことか

0682デフォルトの名無しさん

2010/12/10(金) 16:18:43

>>681
古いバージョンではその後の a の値が 3 になるが、
新しいバージョンでは [1,2,3] のままになる。

クロージャのある言語で変数宣言的な構文がないと
こういう問題がある。

C++ は宣言もあるし、lambda にキャプチャリストもあるんで
関係ないけど。

0683デフォルトの名無しさん

2010/12/10(金) 19:12:02

ああ、さらにそのあとp aしないと意味なかったか

やはり宣言ないとスコープ分かりにくいな

0684デフォルトの名無しさん

2010/12/10(金) 23:15:33

制御ブロック専用のauto予約語を作ればいいんだな
afor,awhile,doa

0685デフォルトの名無しさん

2010/12/10(金) 23:55:54

do (int n) {
　n = ...;
} while (n == m);

みたいなことはやりたいと思う

0686デフォルトの名無しさん

2010/12/11(土) 00:22:27

do {
　int n;
　n = ...;
} while (n == m);

と何が違うんだ？

0687デフォルトの名無しさん

2010/12/11(土) 00:22:46

whileはブロックの外だからnにアクセスできない

0688デフォルトの名無しさん

2010/12/11(土) 00:35:28

http://codepad.org/EpMG6m1l

きもいコードだが

0689デフォルトの名無しさん

2010/12/11(土) 01:17:59

{
　　int n;
　　do {
　　　n = ...;
　　} while (n == m);
}
で良いじゃないか

0690デフォルトの名無しさん

2010/12/11(土) 10:12:50

>>687
アクセスできる仕様になれば良いんだな

>>688
ifを使うとはwww

>>689
ブロックがウザい

0691デフォルトの名無しさん

2010/12/11(土) 10:32:47

do { int n; do{
～
} while(0); }while(n==m);

0692デフォルトの名無しさん

2010/12/11(土) 10:37:44

いや、逆だろ

0693デフォルトの名無しさん

2010/12/11(土) 10:44:40

#define DO(decl) for(bool DO_ = true; DO_; ) for(decl; DO_; DO_ = false) do

DO(int n) {
　n = ...;
} while (n == m);

0694デフォルトの名無しさん

2010/12/11(土) 10:46:39

さすがプリプロセッサさんや

0695デフォルトの名無しさん

2010/12/11(土) 12:20:46

while条件がスコープの中なら万事解決なのに
なんでdoの時は外されるの？

0696デフォルトの名無しさん

2010/12/11(土) 12:48:52

0xではスコープ変わったりしてないの？

0697デフォルトの名無しさん

2010/12/11(土) 12:56:13

N3225では変わってない

よく読むと条件部って「宣言された名前が内側のスコープに入る」(3.3.3-4)だけで
条件部自体がスコープに入ってるわけではないのね
do-whileの条件で宣言なんかしても意味ないから（そもそも出来ないけど）、スコープに入らないわけか
納得した

0698デフォルトの名無しさん

2010/12/11(土) 13:06:19

while( int i = 1 )
{
i = 0 ;
}

宣言は出来る
でも永久ループする

0699デフォルトの名無しさん

2010/12/11(土) 13:25:00

いや、それは当然できるよ
do{
...
}while(int i=0);

が出来ないって事
普通のwhileの条件はconditionで、do-whileの条件はexpressionだからね

0700デフォルトの名無しさん

2010/12/11(土) 20:40:10

まあそれ以降使える所がないしな

0701デフォルトの名無しさん

2010/12/11(土) 20:45:22

do statement while(expression); だっけ？
{ } は必須じゃなくて do-while とは無関係だから
スコープを広げるという仕様を加えにくいんだろうね

0702デフォルトの名無しさん

2010/12/11(土) 20:59:57

その辺はifやforも一緒だから問題ない

do-whileの場合はstatementの中の名前を条件部に導入するっていう
他と逆の話になるのが問題なんだろう

0703デフォルトの名無しさん

2010/12/11(土) 21:08:42

全然違う
if, for, while の場合はスコープを狭めるだけなのに対して、
do-while の場合はブロックの外にスコープを広げる仕様になるわけで

0704デフォルトの名無しさん

2010/12/11(土) 21:17:48

だったらこれでいいんでない？

do
　declaration-list;
　statement;
while (expression);

do int i; { i = ... } while (i == 0);

0705デフォルトの名無しさん

2010/12/11(土) 21:34:18

これで良いだろ
do:
......
if( xxx ) goto do;

0706デフォルトの名無しさん

2010/12/11(土) 22:08:27

予約語ってラベルに出来たっけ？

0707デフォルトの名無しさん

2010/12/11(土) 22:12:11

できるわけないだろ。
プリプロセッサーのマクロの識別子にも使えないから注意しろよ。
今回、newキーワードの再利用で、
#define new(x) ....
とかやってるマクロがぶっ壊れるからな。
自業自得だ。

0708デフォルトの名無しさん

2010/12/11(土) 22:33:42

new(...) という形式の構文が追加されたの?

0709デフォルトの名無しさん

2010/12/11(土) 22:46:12

追加も何もC++03でもplacement newがありますが

0710デフォルトの名無しさん

2010/12/11(土) 22:55:34

そうかnewマクロが軒並み壊れるのか
MSVCには絶対採用されない機能になったな

0711デフォルトの名無しさん

2010/12/11(土) 23:00:47

そもそも、C++98の時点で、使えないとされているからな。
newキーワードの再利用の時の議論に、この問題があがったらしいけれど、
そもそもplacement newすらぶっ壊れるじゃん。自業自得だと論破された。

0712デフォルトの名無しさん

2010/12/11(土) 23:08:01

そんな事言われてもMFC使っちゃってるプログラムは現にごまんとあるんだよ
どうせcontextual keyword作るならhidingでいいじゃんかよ
勘弁してくれ

0713708

2010/12/11(土) 23:11:20

>>709
あいや、それは知ってるんだわ。
707で「今回newの再利用で」とあるので、新規に()が続く形式も追加されたのか
と思っただけ。
メンバー関数の上書き指定の文脈依存語では new() の形は挙がってなかった
と思ったんで。

0714デフォルトの名無しさん

2010/12/11(土) 23:17:11

プリプロセッサーの識別子に、
キーワードと新しく追加される文脈依存キーワードを使ってはならないというのは、
ライブラリ実装者からしても当然のルールだよ。
そんなことを許してしまうと、コンパイラ側で、すべてのキーワードに対して、
アンダースコアで始まる同等な意味を持つ独自キーワードでも提供しない限り、
安全にライブラリを実装することができなくなってしまう。

ライブラリ自ら、そんなアホなことやってるのは、自分で首を絞めているようなもんだ。

0715デフォルトの名無しさん

2010/12/11(土) 23:30:24

俺はMFC使わないしどうでもいいんだが
予約語を前処理で置換する事の道義的な是非は別として
new() 形式の構文が追加されても、それらについて明示的に「手で」マクロ
展開を抑制することは出来るし、特別 new() マクロだけ使えなくなるという
ことは無さそうに見える。

0716デフォルトの名無しさん

2010/12/11(土) 23:38:30

>>714
あなたの言ってる事は全く正論だし完全に正しいと思うが
そんなアホな事をやってるライブラリが実際に存在して、
しかもそれは世界一普及したOSの重要なライブラリであって、極めて広く使われているという現実を
無視してはいけないと思うんだ

0717デフォルトの名無しさん

2010/12/12(日) 09:48:13

VC6時代は
#define for if(0); else for
とか普通にやってたよね
forが腐ってる時点で規格云々話す意味ないけど

0718デフォルトの名無しさん

2010/12/12(日) 09:53:23

それもATLのヘッダが腐ってたせいでなかなか修正できなかったんだよな

0719デフォルトの名無しさん

2010/12/12(日) 09:55:43

結局、諸悪の根源はMSだな。

0720デフォルトの名無しさん

2010/12/12(日) 10:25:20

必要悪だからどうにも出来ないけどな。

0721デフォルトの名無しさん

2010/12/12(日) 18:50:55

for i in x, y, z do …
的なこと0xだと出来るんだっけか？

0722デフォルトの名無しさん

2010/12/12(日) 19:04:51

range-based forですね

0723デフォルトの名無しさん

2010/12/14(火) 10:37:44

>>665
そういえばboost.fusionが後から型を変更できるのだろうか

0724デフォルトの名無しさん

2010/12/14(火) 11:10:05

MFCは糞

0725デフォルトの名無しさん

2010/12/14(火) 21:18:46

マクドナルドフライドチキン？

0726デフォルトの名無しさん

2010/12/14(火) 23:36:22

麻雀格闘倶楽部。

0727デフォルトの名無しさん

2010/12/15(水) 20:52:11

マイケルファックチャイルド

0728デフォルトの名無しさん

2010/12/19(日) 16:10:47

で、右辺値参照はその後どうなった？

0729デフォルトの名無しさん

2010/12/19(日) 17:29:22

どうにもならなかった

0730デフォルトの名無しさん

2010/12/19(日) 19:52:17

暗黙のムーブコンストラクタが
暗黙のコピーコンストラクタを巻き込んで
弄ばれてるんじゃなかったっけ

0731デフォルトの名無しさん

2010/12/20(月) 07:34:52

何で今頃になってそんな話してるんだよ

0732デフォルトの名無しさん

2010/12/20(月) 12:08:13

コピコンを使用禁止にしておいて
ムブコンだけでいいような設計がベストだよ。

0733デフォルトの名無しさん

2010/12/20(月) 12:12:07

言語仕様をこんなに複雑にしちゃって大規模アプリで運用できるのかなぁ

0734デフォルトの名無しさん

2010/12/20(月) 12:34:06

>>733
ライブラリを使う側の人には、大して複雑になってないと思うけど。
キモい見た目のアレはコーディング規約とかでゴニョゴニョすればいいし。

0735デフォルトの名無しさん

2010/12/20(月) 13:19:04

> キモい見た目のアレはコーディング規約とかでゴニョゴニョすればいいし。
lambda なんてものは、あれば使いたくなるのが人情ってもんだろ？
コーディング規約でゴニョゴニョしてもキモイ見た目は変わらない

0736デフォルトの名無しさん

2010/12/20(月) 14:28:16

見慣れないものはキモイ、
そうやって差別や偏見がはじまっていくのだろうな・・・

0737デフォルトの名無しさん

2010/12/20(月) 14:57:08

見た目なんて気にしてたら何時まで経ってもコーディングできないだろ

0738デフォルトの名無しさん

2010/12/20(月) 21:27:10

lambdaはキモいって事になってんの？
結構使い勝手良いし、見た目もわかりやすいと思うけど

0739デフォルトの名無しさん

2010/12/20(月) 21:31:44

ランバダ

0740デフォルトの名無しさん

2010/12/20(月) 22:06:58

キモくないと思えるのは幸せだね・・・

0741デフォルトの名無しさん

2010/12/21(火) 02:27:26

http://www.news.janjan.jp/government/0702/0702090742/1.php

0742デフォルトの名無しさん

2010/12/21(火) 03:21:47

λはいつの間にか使ってるものだな
自然に使ってしまう

0743デフォルトの名無しさん

2010/12/21(火) 05:01:43

>>738
他の言語のlambdaを使い熟れてるとキモサ爆発だわな
まぁ、あれば使うけど

0744デフォルトの名無しさん

2010/12/21(火) 22:42:25

このまえpythonのスレをちらっとみたら、他の言語は
サブルーチンのネストができないから、しかたなくあんなもん(ラムダ)を
導入してるんだ。
やっぱpythonはスジがいいね!

ってことで意見がまとまってた。

0745デフォルトの名無しさん

2010/12/22(水) 01:45:49

（ﾟдﾟ）

0746デフォルトの名無しさん

2010/12/22(水) 07:29:57

pythonはラムダっぽいことはできないのか

0747デフォルトの名無しさん

2010/12/22(水) 09:45:49

ラムダをつかっていると無性にランバダを踊りたくなるな。

0748デフォルトの名無しさん

2010/12/22(水) 13:17:21

>>746
lambdaそのものは存在するがローカル関数の方が好まれるのであまり使われない。

0749デフォルトの名無しさん

2010/12/22(水) 16:55:41

boost.lambdaとC++0xのlambdaって同じ？

0750デフォルトの名無しさん

2010/12/22(水) 16:57:48

continuationとdelay forceは導入されないの？

0751デフォルトの名無しさん

2010/12/22(水) 19:47:43

>>749
かなり違う
C++0xの方が後発だけあって変数のキャプチャが出来たり変数を定義する事が出来たり
参照で渡せたりまあいろいろと便利かな

0752デフォルトの名無しさん

2010/12/22(水) 19:53:24

yieldなんて予約語は死んでも使えないC++が
どんな奇妙な構文を導入してくるか興味ある

0753デフォルトの名無しさん

2010/12/22(水) 19:56:48

>>749
boost.lambdaはpolymorphicだけどC++0xのlambdaは違う

0754デフォルトの名無しさん

2010/12/22(水) 19:57:22

互換性を維持しながら後発言語の機能を全部追加するなんて無茶だと思うの

0755デフォルトの名無しさん

2010/12/22(水) 21:36:48

>>754
C++ がアイデア借りまくってる LISP も SmallTalk も ML も C++ より先発なんだが

0756デフォルトの名無しさん

2010/12/22(水) 22:23:51

>>752
yieldはしんでも採用して欲しくないな。

0757デフォルトの名無しさん

2010/12/23(木) 07:51:11

>>738
引数がlamdaを返すlambdaな関数のprototypeを定義してみそ

0758デフォルトの名無しさん

2010/12/24(金) 08:52:48

C++0xになってもboost.lambdaは使えるってことでＯＫ？

0759デフォルトの名無しさん

2010/12/24(金) 09:02:35

おｋ
別に競合するもんじゃねーしな

0760デフォルトの名無しさん

2010/12/24(金) 13:21:17

boostは標準ライブラリーではないよ。

0761デフォルトの名無しさん

2010/12/24(金) 13:59:31

なにを突然言い出してんだ

0762デフォルトの名無しさん

2010/12/24(金) 14:22:07

我々はアマチュアではないよ。

0763デフォルトの名無しさん

2010/12/24(金) 14:27:02

どこの誤爆だ？

0764デフォルトの名無しさん

2010/12/29(水) 20:09:08

>>758
boost.lambdaが使えなくなっていいぐらい互換性を壊して良いなら
C++0xはもっと早く決まっているだろう。

0765デフォルトの名無しさん

2011/01/03(月) 13:11:02

さて、仕様が決まらないまままた年が明けた訳だが

0766デフォルトの名無しさん

2011/01/03(月) 23:27:31

今年も仕様が決まらないまま年末を迎えるんだろうな

0767デフォルトの名無しさん

2011/01/03(月) 23:46:11

仕様なんてそこらへんのルンペンに押し付ければいいんだ

0768デフォルトの名無しさん

2011/01/04(火) 00:31:54

shared_ptrとかコンパイラ変えなくても実装できるものは先に規格化するとか段階的にできないの？

shared_ptrマジ必要。

0769デフォルトの名無しさん

2011/01/04(火) 00:33:13

>>768 そこで Boost ですよ。

0770デフォルトの名無しさん

2011/01/04(火) 00:54:15

C++が悠長に仕様策定している間に他の言語のコード資産はどんどん増えていく
プログラミング言語は道具に過ぎないのに手段と目的が逆になってきてるよな

0771デフォルトの名無しさん

2011/01/04(火) 00:57:34

相互に互換性のない俺スマポが世界中で生まれては消えるんだよね。

だがスマポの設計は一度はやっておくといい経験にはなるのではあるが・・・・

0772デフォルトの名無しさん

2011/01/04(火) 01:03:09

大量のオブジェクトを一斉削除したときスマートポインタの限界を思い知った

0773デフォルトの名無しさん

2011/01/04(火) 03:25:47

ガベコレでもきっと限界を思い知るよ

0774デフォルトの名無しさん

2011/01/04(火) 03:36:28

ガーベジコレクションで困るのって組込くらいじゃね？

0775デフォルトの名無しさん

2011/01/04(火) 03:42:43

ガベージコレクションなんかが使い物になるのってPCくらいじゃね？

0776デフォルトの名無しさん

2011/01/04(火) 03:46:22

ガベコレはゲームで困る

0777デフォルトの名無しさん

2011/01/04(火) 03:51:28

普通のアプリでもたまに困る

0778デフォルトの名無しさん

2011/01/04(火) 08:46:04

>768
TR1 があるじゃん。

0779デフォルトの名無しさん

2011/01/04(火) 09:32:37

大量のオブジェクトを一斉削除したらスマートポインタじゃなくても結局同じ事になるような･･･？

0780デフォルトの名無しさん

2011/01/04(火) 17:42:40

ガベコレは他のスレッドの邪魔をしないように動くのが普通

0781デフォルトの名無しさん

2011/01/04(火) 18:32:10

そうあってほしいがそれほど普通でもない
理想と現実は区別しなければならん

0782デフォルトの名無しさん

2011/01/04(火) 18:44:26

みんなそんなにクリティカルな仕事してるの？

0783デフォルトの名無しさん

2011/01/04(火) 18:46:21

エロいこと言うな

0784デフォルトの名無しさん

2011/01/04(火) 18:47:01

クリティカルだからC/C++なんだよ
効率どうでもいいならもっと便利な言語がいっぱいあるし

0785デフォルトの名無しさん

2011/01/04(火) 18:50:59

クリティカルな仕事って、原子炉の掃除とか、骨折バイトとかのことだろ？

0786デフォルトの名無しさん

2011/01/04(火) 19:19:49

>>780 処理系依存だ
>>784 ほかの言語がマシン語はいてくれたらC++は要らない子の筆頭だ
>>785 ハードリアルタイムが必要な処理系あるんだな
臨界値越えなきゃいいって極めておおらかな世界 < 原子炉の掃除
# で、人間系がこけると最悪なことになる

0787デフォルトの名無しさん

2011/01/04(火) 19:26:37

「ハードリアルタイムが必要な処理系」での仕事を「クリティカルな仕事」とは言わないと暗に言ってるのでは。

0788デフォルトの名無しさん

2011/01/04(火) 19:27:54

骨折バイトって骨のくっつき方を調べるためにわざと骨折するみたいなバイト?
痛そう

0789デフォルトの名無しさん

2011/01/04(火) 19:30:50

そんな都市伝説信じてるやついんの？

0790デフォルトの名無しさん

2011/01/04(火) 19:31:45

ミッションクリティカルと混同してたわすまん

0791デフォルトの名無しさん

2011/01/04(火) 19:37:21

そういう仕事だと例外処理も嫌がられるってほんと？

0792デフォルトの名無しさん

2011/01/04(火) 19:38:45

まあ、原子炉の掃除はルーチンワークで済ませたいだろ

0793デフォルトの名無しさん

2011/01/04(火) 19:40:50

ミッションクリティカルな基幹系では例外処理使いまくり。

0794デフォルトの名無しさん

2011/01/04(火) 19:41:04

いいかげんに、C++の機能はそのままに、フロントエンドの文法だけ変更した言語が欲しい。
宣言文とかテンプレートとかの曖昧になる可能性のある文法をどうにかして欲しい。

0795デフォルトの名無しさん

2011/01/04(火) 19:43:29

>>794
【超高速】C/C++に代わる低級言語を開発したい 7
http://hibari.2ch.net/test/read.cgi/tech/1275235018/

0796デフォルトの名無しさん

2011/01/04(火) 19:44:18

>>791
ハードリアルタイムに関してはそう
つか、例外処理悪阻杉だろ > C++

0797デフォルトの名無しさん

2011/01/04(火) 19:45:37

そんなジャパニーズのためにEmbedded C++があります。

0798デフォルトの名無しさん

2011/01/04(火) 20:30:38

>>796
そもそも例外処理って使ってる？

0799デフォルトの名無しさん

2011/01/04(火) 20:50:28

>>798 C++の例外を、ハードリアルタイムな組み込みで、使うわけないじゃん

0800デフォルトの名無しさん

2011/01/04(火) 20:53:05

嫌がれる以前に使わないだろ？という話じゃないの

0801デフォルトの名無しさん

2011/01/04(火) 21:32:37

ハードとかリアルとかってレーザーラモンのことだろ

0802デフォルトの名無しさん

2011/01/04(火) 21:37:10

ソフトだけで保証できるタイミングの範囲は笑っちゃうくらいどんくさい
たとえ全部アセンブラでも

0803デフォルトの名無しさん

2011/01/04(火) 21:39:34

その心は

0804デフォルトの名無しさん

2011/01/04(火) 21:44:52

>>802 「それをいっちゃあ、おしめぇよ」な、発言だろwWW

0805デフォルトの名無しさん

2011/01/04(火) 22:26:36

>>779
ガベコレの実装次第。
たとえばコピーGCなら、一回のGCにかかる時間は生きているオブジェクト数に比例するから
一度に大量のオブジェクトが死のうが関係ない。

0806デフォルトの名無しさん

2011/01/04(火) 22:34:12

>>805 destructorの処理コストを言ってるんじゃないか？
GC まかせでボチボチやったとしても、
でかいallocation要求来ればGCがアップアップするわな

0807デフォルトの名無しさん

2011/01/04(火) 23:50:17

実装次第だな。

0808デフォルトの名無しさん

2011/01/05(水) 00:41:06

>>807

file close とかも GC 側でめんどうみるだろ？
OS の特性として close より open が重ければアウトじゃん
GC だけで解決できる問題とはおもえへん

明確な例を提示してほしいいな

0809デフォルトの名無しさん

2011/01/05(水) 00:57:30

スマートポインタで、デストラクタの走るタイミングを
上手いことズラしてくれるような物は無いの？

0810デフォルトの名無しさん

2011/01/05(水) 01:10:59

>>889:2 error: '上手いこと' undeclared

0811デフォルトの名無しさん

2011/01/05(水) 01:11:33

>>809
プログラムのセマンティックスかわっちゃうからムリだろ

0812デフォルトの名無しさん

2011/01/05(水) 01:34:39

即解放して欲しいものと、そのうち適当に解放してくれればいい物を区別しておくんだな

あれ？

0813デフォルトの名無しさん

2011/01/05(水) 02:10:06

>>809
デアロケータに適当なの渡して別スレッドに後始末押し付ければ

0814デフォルトの名無しさん

2011/01/05(水) 02:59:16

デストラクタのタイミング変わったらだめだよな
C#だってディスポーザはちゃんとタイミング決めて走るわけで
じゃあデストラクタの後にもう一度廃棄処理が走れば・・・ってそれはC++/CLIじゃなイカ？

0815デフォルトの名無しさん

2011/01/05(水) 17:40:38

デストラクタとファイナライザの役割分担か
ありがちすぎて胸が熱くなるな

0816デフォルトの名無しさん

2011/01/05(水) 19:19:48

大量のオブジェクトを一斉に削除すると
スマートポインタのデストラクタが一遍に呼ばれて(deleteが呼ばれて)処理が滞るということから
GCの優位性を主張する奴がいただけなのにどうしてこうなった

0817デフォルトの名無しさん

2011/01/06(木) 00:05:57

>>816
実装依存なものを優位性とか言い出すから荒れるのでは？
リソース開放処理の負荷分散したいんなら>>813のような
設計にすればよいだけ。

C++の速度優位性（JavaC#にくらべ）もコンパイラ(最適化・癖）や
ＣＰＵ（キャッシュヒット等）の実装依存だけど、負荷分散の為の
ＧＣ実装への依存よりはよっぽどましな気がする。
程度問題だけど。

0818デフォルトの名無しさん

2011/01/06(木) 23:10:00

C#でタイマーやソケットのオブジェクトへの参照を切っても、いつまでもオブジェクトがデストラクトされずにイベントが垂れ流しだったりソケットが閉じなかったり。GCっていい加減なものでGC任せにはできないな。

0819デフォルトの名無しさん

2011/01/06(木) 23:14:26

>>780
その普通ができている実装ってあるのか？

0820デフォルトの名無しさん

2011/01/06(木) 23:33:17

ttp://www32.ocn.ne.jp/~ons/text/CPP0xFAQ.html.ja
年末に、更新してくれたみたい。

0821デフォルトの名無しさん

2011/01/06(木) 23:57:22

>>818
知らないことはあんまり叩かないほうがよくね？

.NETのファイナライザの実行タイミングはGCまかせだから
メモリ以外のリソース解放をファイナライザで行うのは稀
ていうか、ファイナライザ自体GCに負荷をかけるから推奨されてない

リソースは使用した箇所のfinally句で解放するのが.NETのルールで
C#には糖衣構文も用意されている

てかC++書けるくせに.NET書けないとか不勉強すぎだろ

0822デフォルトの名無しさん

2011/01/07(金) 00:26:22

disposeあるし、、、usingもあるからましなほうだろ。
818はjavaでも同じようなことやるだろw
いっしょに仕事したくないですw

0823デフォルトの名無しさん

2011/01/07(金) 01:32:04

Javaでも「原則使うな」なのがファイナライザ
というより、ファイナライザを積極的に使う言語なんてあるのか？

0824デフォルトの名無しさん

2011/01/07(金) 13:05:28

Stringを継承してデフォルトデストラクターが呼ばれないことが防げるよ。

0825デフォルトの名無しさん

2011/01/08(土) 11:17:17

C#のDisposeはもっと書きやすくして下さい

0826デフォルトの名無しさん

2011/01/09(日) 01:05:46

enum classについて言及が無いけどswitchでcaseに列挙子書くとき
型名省略できたりとかできないの？

0827デフォルトの名無しさん

2011/01/09(日) 09:20:48

>>821
じゃあC#も結局リソースの破棄は手動か？何のためのGCだか。
finallyとかusingとか呼ぶ側で対処するとかダサくない？

0828デフォルトの名無しさん

2011/01/09(日) 09:42:59

C++なら例えばunique_ptrつかえば、finallyやusingなくても確実にデストラクトできる。
finallyやusingは書き損じのリスクを人がチェックしなきゃならないのがデメリット

0829デフォルトの名無しさん

2011/01/09(日) 09:58:57

書き損じのリスク程度なら静的解析ツールに診断させりゃいいだけじゃね？

0830デフォルトの名無しさん

2011/01/09(日) 10:29:02

viだけで書けるようにしてくれ

0831デフォルトの名無しさん

2011/01/09(日) 11:36:13

>>827
>>818もそうだけど、GCはあくまでメモリ管理の機能だってことわかってないだろ

言語にかかわらずOSリソースは自前で開放しなきゃいけない事を認識するべき
ダサすぎるわ

0832デフォルトの名無しさん

2011/01/09(日) 11:44:14

C++はデストラクタで解放されるわけだが

0833デフォルトの名無しさん

2011/01/09(日) 11:47:04

C#もネイティブリソースの扱いには色々頑張っていて
CriticalFinalizerObject
とかあるわけですよ

0834デフォルトの名無しさん

2011/01/09(日) 12:12:39

C++だとメモリはリソースの一種という扱いだからねぇ

0835デフォルトの名無しさん

2011/01/09(日) 13:42:13

C++0xこそガラパゴスだよな。
進化の袋小路にはまって未来がない。

0836デフォルトの名無しさん

2011/01/09(日) 13:45:31

>>835が未来のある言語を教えてくれるらしいぞ

0837デフォルトの名無しさん

2011/01/09(日) 13:46:23

Java以上のガラパゴスなんかねーよ

0838デフォルトの名無しさん

2011/01/09(日) 13:51:50

C++に未来がないとしたら、理由はどちらかというと互換性のしがらみだと思うが
move騒動然り

0839デフォルトの名無しさん

2011/01/09(日) 13:58:33

>>838
だから、互換性捨てろよ
lambda ちゃんだってキーワードひとつでもっとこぎれいな制服になってたはずだ

0840デフォルトの名無しさん

2011/01/09(日) 14:00:19

キャプチャ考えると結局こんなもんって気もするけどね

0841デフォルトの名無しさん

2011/01/09(日) 14:28:33

その辺はD&Eを100回読めということで

0842デフォルトの名無しさん

2011/01/09(日) 14:37:02

むしろラムダは他にやりようあんまりない気がする
参照キャプチャを全く無しにするなら全部コピーキャプチャのみにすることで簡略化できるが

0843デフォルトの名無しさん

2011/01/09(日) 15:29:47

>>838
互換性のしがらみからの脱却果てしないDを見習おう。

0844デフォルトの名無しさん

2011/01/09(日) 16:34:10

ユーザーが全くいなければ互換性のしがらみもないな

0845デフォルトの名無しさん

2011/01/09(日) 16:49:19

つまりＤ言語最強

0846デフォルトの名無しさん

2011/01/09(日) 16:56:03

Dはいつ本気出すんだよ

0847デフォルトの名無しさん

2011/01/09(日) 16:56:54

明日

0848デフォルトの名無しさん

2011/01/09(日) 17:07:46

Dはいつも全開だよ
目指す方向が間違ってるだけで

0849デフォルトの名無しさん

2011/01/09(日) 17:14:24

間違ってないよメジャーになる気がないだけだよ

0850デフォルトの名無しさん

2011/01/09(日) 18:26:24

Dは完成したらメジャーになれると信じている

0851デフォルトの名無しさん

2011/01/09(日) 18:35:39

いつ完成するんだよ。

0852デフォルトの名無しさん

2011/01/09(日) 20:10:45

明日

0853デフォルトの名無しさん

2011/01/09(日) 20:13:10

完成したらDじゃないだろう

0854デフォルトの名無しさん

2011/01/09(日) 20:23:32

明日っていつだよ

0855デフォルトの名無しさん

2011/01/09(日) 20:36:07

あしたっていまさッ！

0856デフォルトの名無しさん

2011/01/09(日) 21:02:34

まあキャプチャリストの必要性も分かるんだが…なんというか、
boost lambda の (*_1 < *_2) みたいなインパクトが無いんだよなあ

0857デフォルトの名無しさん

2011/01/15(土) 15:34:55

禿げの理屈っぽさにはウンザリ

いいかげんに仕様をきめやがれ

0858デフォルトの名無しさん

2011/01/15(土) 16:26:06

DやるくらいならC#やってるよ

0859デフォルトの名無しさん

2011/01/15(土) 18:39:05

>>857
理屈っぽさ自体はいいと思う（禿本おもろいし）
結論がきれいにまとまらないことがもどかしいだけ

0860デフォルトの名無しさん

2011/01/17(月) 21:37:23

Conceptのちゃぶ台ひっくり返した時も
理屈理屈で笑ってしまったがw

0861デフォルトの名無しさん

2011/01/17(月) 22:20:40

禿を論破して黙らせるくらいの人材が足りない

0862デフォルトの名無しさん

2011/01/17(月) 22:27:26

人材を待つより、自動命題論破システムを構築

0863デフォルトの名無しさん

2011/01/17(月) 22:28:18

俺がやってもいいけど

0864デフォルトの名無しさん

2011/01/18(火) 20:31:05

期間と予算は？

0865デフォルトの名無しさん

2011/01/18(火) 22:05:52

>>864
そんなもん、 (期間無 == 限大 && 予算 == ゼロ) にきまっtるじゃん

0866デフォルトの名無しさん

2011/01/19(水) 09:55:58

理屈はC++が、というか
あるプログラミング言語がまともな言語として
存在するためには必須だろう。

禿がそれを考えていてくれるんだからいいじゃないか。

俺としては
C++0xを2段階に分けてリリースしてほしいけど。
難しそうな所は第2段階目に置いておいて、
ひとまず有用そうで簡単そうなところだけを第1段階目としてリリースしてほしい。

リリースっていう単語の使い方がおかしいか。策定とでもいうべきか。

0867デフォルトの名無しさん

2011/01/19(水) 20:59:22

C++1x否定ですか

0868デフォルトの名無しさん

2011/01/19(水) 21:01:15

難しそうなconceptは先送りになったでしょ

0869デフォルトの名無しさん

2011/01/19(水) 21:07:19

現実はどうあれ98を置き換える規格を作ってるんだから小出しリリースとかアホすぐる発言はよし玉枝

0870デフォルトの名無しさん

2011/01/19(水) 21:31:59

先などあるのだろうか

0871デフォルトの名無しさん

2011/01/19(水) 21:37:29

>>866
それやるとコンパイラベンダが文句を付けて来ないか
今も規格が固まってないのに当たり障りない部分から対応してきてるけど

0872デフォルトの名無しさん

2011/01/20(木) 14:30:45

今でも使わない機能が山盛りなのにこれ以上増やしてどうするのかと思う。
俺達に必要なのは間違えなくC++ーーだ。
C++0xなんか要らない。

0873デフォルトの名無しさん

2011/01/20(木) 14:50:02

>>872
つ EC++

0874デフォルトの名無しさん

2011/01/20(木) 21:31:22

あれ気持ちはわかるんだけど極端すぎたのが敗因だな
template や多重継承は残して、virtual や new のほうを何とかして欲しかった
関数ポインタで片付くところはそれでいいしゼロオーバーヘッド原則を有名無実化されるのがいや

言語そのものが巨大オブジェクトのアンチパターンまっしぐらなのがどうもね
これ C++ に限ったことじゃないけど

0875デフォルトの名無しさん

2011/01/20(木) 22:52:03

>>874
( ﾟдﾟ)ﾎﾟｶｰﾝ

0876デフォルトの名無しさん

2011/01/21(金) 00:52:51

>>872
全員が全部を使う必要なんて無い。
ライブラリを作る人、使う人、カーネル寄りのコードを書く人、それぞれ使う部分使わない部分が違う。
ただ 0x の追加のそれなりの部分は誰にとっても便利だけど。

0877デフォルトの名無しさん

2011/01/21(金) 06:28:01

てゆーか0xの追加機能っておおむね簡単便利な機能ばっかだと思うんだけど
単純に機能山盛りという意味ではC#の方が遥かに仕様でかいじゃん

0878デフォルトの名無しさん

2011/01/21(金) 09:47:43

>>872
たとえば使わない機能ってなにさ？

右辺値参照はライブラリ屋さんは必須項目だけとアプリ技術者は特に気にする必要はないし。

0879デフォルトの名無しさん

2011/01/21(金) 11:01:54

>>877
Move semanticsは今もいろいろバタバタしてるよ、簡単とは言えない。

0880デフォルトの名無しさん

2011/01/21(金) 11:16:43

使わない筆頭のautoは出世したな

0881デフォルトの名無しさん

2011/01/21(金) 11:22:35

>>879
決めるのにゴタついてるだけで、決まった後にそれを使うのが難しいようなものじゃないだろ

0882デフォルトの名無しさん

2011/01/21(金) 11:33:57

>>878
＞右辺値参照はライブラリ屋さんは必須項目だけとアプリ技術者は特に気にする必要はないし。

アプリ技術者でも、既存のソース読んだり、自分でクラス作ろうと思ったら知る必要あるのでは？
C++0x はまだ使ってないけど、最近 C++ のプロジェクトに新人が入ってきて、引数の値（コピー）渡しと参照渡しの使い分けとか、いろいろ教えるのが大変すぎる。

>>872
C++ の機能はほとんどが密接に関連してるから、部分的に削るとかは無理。

0883デフォルトの名無しさん

2011/01/21(金) 11:38:32

>>881
ええっ！？

0884デフォルトの名無しさん

2011/01/21(金) 15:18:52

C++0x後を見越したTR2ってその後どうなったんだろう。
並行してC++1xに取りかかってほしい。

0885デフォルトの名無しさん

2011/01/21(金) 19:24:19

0xがFixしたあとだろ

0886デフォルトの名無しさん

2011/01/21(金) 21:55:46

もう最初からC++2xと言うべき

0887デフォルトの名無しさん

2011/01/21(金) 23:18:18

VC10のbasic_stringってメモリの連続性保証されてるのでしょうか？

0888デフォルトの名無しさん

2011/01/21(金) 23:26:18

0xでbasic_string何か変更あったっけ

0889デフォルトの名無しさん

2011/01/21(金) 23:53:21

21.4.1 basic_string general requirements の 5:
The char-like objects in a basic_string object shall be stored contiguously. That is, for any basic_string
object s, the identity &*(s.begin() + n) == &*s.begin() + n shall hold for all values of n such that 0
<= n < s.size().

0890デフォルトの名無しさん

2011/01/22(土) 13:15:33

あとC++0xでは、arrayとvectorも "The elements ... are stored contiguously," となる。

0891デフォルトの名無しさん

2011/01/22(土) 14:30:56

vectorはC++03から
arrayはTR1から
"The elements ... are stored contiguously,"だと思うけど

0892デフォルトの名無しさん

2011/01/22(土) 16:02:34

TRはその名の通りreportでまだ規格の一部じゃない

0893デフォルトの名無しさん

2011/01/22(土) 23:46:04

>>882
アプリ屋さんでも右辺値参照を知っていれば効率的なコードが書けるね。
まあ、知らなくても十分だけどな。

0894デフォルトの名無しさん

2011/01/22(土) 23:50:35

constのうんかす

0895デフォルトの名無しさん

2011/01/23(日) 01:16:44

右辺値参照＋コンテナ＋unique_ptr＝最強

0896デフォルトの名無しさん

2011/01/23(日) 14:34:59

>>894
constは必須だろうJK

0897デフォルトの名無しさん

2011/01/23(日) 15:51:00

constは必須というか、Javaはなんでfinalをあんな設計にしちまったんだと思う

0898デフォルトの名無しさん

2011/01/25(火) 00:34:25

C土土

0899デフォルトの名無しさん

2011/01/25(火) 08:26:49

やろうと思えばC#のように新しい言語を作って定着させる事は出来る
結局だれも本気でC++の代わりを欲しがってるわけではないんだ

0900デフォルトの名無しさん

2011/01/25(火) 08:31:30

D is for DoomsDay

0901デフォルトの名無しさん

2011/01/25(火) 08:58:26

最近の美少女中学生はいろんな意味のC++をしたくてたまりませんヒャッホォウ！(*´Д`)

0902デフォルトの名無しさん

2011/01/25(火) 09:34:20

いやC++の代わりは本気で欲しい。
シンプルで高速な奴。わりとCが違いが機能が足らん。

0903デフォルトの名無しさん

2011/01/25(火) 10:16:13

下位互換を保ったままコンパイル時シンボル解決をお利口にすることはできなかったのかなぁ
コンパイル遅くなってもいいからinclude順でウダウダするのはもうやめにして欲しかった
あとはGCの標準が欲しかったくらいかな

C++0xと比べた時にJavaやC#がうらやましく感じるのって個人的にはこれくらいしかない

0904デフォルトの名無しさん

2011/01/25(火) 11:19:22

include 順については同意だが
GC は死んでもいらん typeid と同類

「言語自身で表現できることは言語に組み込まない」という方針をきっちり貫いて欲しい

placement-new だのファクトリパターンを使うと
普通の new すら邪道に見える

0905デフォルトの名無しさん

2011/01/25(火) 11:25:49

GCはライブラリを作るためのメカニズムが入った。
include順は今のままで問題ない。

0906デフォルトの名無しさん

2011/01/25(火) 11:25:50

GCはライブラリの方の標準として欲しかったよ
shared_ptrは便利だけどちょっと力不足で結局俺俺intrusive_ptr作ってる人多いよね
循環回収保障付shared_ptr/intrusive_ptrとかあっても良かったと思うんだ

0907デフォルトの名無しさん

2011/01/25(火) 11:26:38

>>906
C++0x準拠のコンパイラ出たら出てくるんじゃないの？

0908デフォルトの名無しさん

2011/01/25(火) 11:27:59

>>907
出てくるだろうけどまたboostでwって話にならんか？

0909デフォルトの名無しさん

2011/01/25(火) 12:33:25

ええやん！

0910デフォルトの名無しさん

2011/01/25(火) 12:45:56

>>903
C#のpropertyは割と本気で欲しい

0911デフォルトの名無しさん

2011/01/25(火) 15:08:43

今どきGCのない言語とか血尿が出るレベル。
これだけで使う気にならない

0912デフォルトの名無しさん

2011/01/25(火) 15:23:34

そういう人が使う言語じゃない。
ある程度レベル以上の人が使う言語。
C++じゃないと無理な領域(e.g.システムソフトウェア)もあるし。

0913デフォルトの名無しさん

2011/01/25(火) 16:30:10

結局C/C++やそれ以下の低水準言語でしか
まともなOSとか作れてないんだよね。

低能者、例えば>>911とかだと発狂するのかもしれないけど。

0914デフォルトの名無しさん

2011/01/25(火) 16:32:40

いやー、やっぱりGCは便利だよ
ただ全てにおいてGCを強要されると逆の意味で血尿が出るが

0915デフォルトの名無しさん

2011/01/25(火) 16:35:02

>>914
> いやー、やっぱりGCは便利だよ

そういう話じゃないだろw
昔、System VのIPCもGC使って実装してあったよ。

0916デフォルトの名無しさん

2011/01/25(火) 16:42:53

血尿かと思っていたら初潮を知らなかっただけで悩んで誰にも相談できない美少女中学生ヒャッホォウ！(*´Д`)

0917デフォルトの名無しさん

2011/01/25(火) 18:52:12

まだ0xなの？

0918デフォルトの名無しさん

2011/01/25(火) 19:11:22

C++書くやつって変態多いよな
プリムラ大好きとか言うから園芸やってんのかと思ったらエロゲのキャラだったし

0919デフォルトの名無しさん

2011/01/25(火) 19:33:42

ガベコレ導入するなら言語レベルで寿命管理を出来る仕組み入れて欲しいね。
register指定を高度にしたみたいな

0920デフォルトの名無しさん

2011/01/25(火) 20:21:35

簡単に無効に出来て、無効設定でうっかり使おうとしたらコンパイルエラーになることが保証されてるような
ガベコレならあってもいい

0921デフォルトの名無しさん

2011/01/25(火) 22:02:46

GCは次のバージョンで入るんじゃないの？

0922デフォルトの名無しさん

2011/01/25(火) 22:20:21

ないね
校長先生が生きてる間は

0923デフォルトの名無しさん

2011/01/25(火) 23:23:54

うむ
C++にGCとかマジ勘弁
メモリコストに鈍感なアホが増えるだけだ

GCを使いたい局面ではC++以外を使えば良いよ

0924デフォルトの名無しさん

2011/01/25(火) 23:29:53

ライブラリならいいだろ？

0925デフォルトの名無しさん

2011/01/25(火) 23:31:41

C# の unsafe のように、gc 走る部分は safe つけるとか。
あまり実用性が見えないけど。

0926デフォルトの名無しさん

2011/01/25(火) 23:40:09

GCほしけりゃDやれD

0927デフォルトの名無しさん

2011/01/26(水) 02:13:23

>>922
うろ覚えだが、D&Eでは割と好意的な評価じゃなかったっけ？

0928デフォルトの名無しさん

2011/01/26(水) 02:54:07

ロリコンはまたさっさとアク禁にならねーかな。
しばらく平和だったのに。

0929デフォルトの名無しさん

2011/01/26(水) 08:27:08

>>927
GCは有用であり考慮に値するが、GCを使わないプログラムの表現力が制限されてはいけない。
理想的なGCが存在するならパフォーマンス問題もなく、またそうする事は可能だと思われる。
しかしそれを考えるのも簡単な仕事ではないので、ユーザのGCに対する関心が高まってくれば
試験的な実装も出てくるだろうから、それを見てから考えよう。
要約するとこんな感じ。

0930デフォルトの名無しさん

2011/01/26(水) 08:33:59

C++にGC実装なんて可能なの？
ポインタ操作を追跡できるとは思えないんだけど

0931デフォルトの名無しさん

2011/01/26(水) 09:08:03

>>930
ポインタは回収しなければいい
要するにただの「循環参照回収保障付きshared_ptr」みたいなもの

0932デフォルトの名無しさん

2011/01/26(水) 12:04:01

保守的GCなら既にあるよな、Gaucheやw3mなどが使ってるBoehm GCとか
Cとの組み合わせでは十分実用になってると思うけど
保守的なのでゴミが残る可能性がある
C/C++の言語仕様ではExactなGCはたぶん無理じゃないの、知らんけど

0933デフォルトの名無しさん

2011/01/26(水) 12:08:00

マシンがタグアーキテクチャなら可能性はある。

つまり現行の普通のマシンでは絶望的だろう、ということだけど。

0934デフォルトの名無しさん

2011/01/26(水) 13:30:08

C++はなんでもオーバーロードできるが
ポインタ操作だけはオーバーロードできない
絶望的だと言うのは、つまりそういうことだよな

0935デフォルトの名無しさん

2011/01/26(水) 14:01:18

え、ていうか既存のポインタがそのままGCで回収されるような話だったの？
てっきりstd::managed_ptr<Hoge> pみたいな話かと思ってたんだが

0936デフォルトの名無しさん

2011/01/26(水) 18:50:34

シングルトン的なGCを設置してそいつにインターフェース食わせるってかんじになるんかな？？

0937デフォルトの名無しさん

2011/01/26(水) 23:05:59

>>931
weak_ptrがあるから循環参照も解決できるね。
weak_ptrは所有者をはっきりできるからわかりやすくなるね。

0938デフォルトの名無しさん

2011/01/27(木) 10:17:27

現状*_ptrがあれば全く困らないな

0939デフォルトの名無しさん

2011/01/27(木) 16:40:36

GCはこの後全く進んでない。二年たってる。

N2586 Minimal Support for Garbage Collection and Reachability-Based Leak Detection (revised) H.-J. Boehm, M. Spertus, C. Nelson
N2587 Minimal Garbage Collection Status API M. Spertus, H.-J. Boehm

面白いとは思う。

0940デフォルトの名無しさん

2011/01/27(木) 21:45:57

次世代のGCは、仮想化支援の命令をハイパーバイザから使ってるから、VMのないC++には向かないかな。
根拠は不明。

0941デフォルトの名無しさん

2011/01/27(木) 21:52:19

GC専用のコアを積んでいると仮定した方がよくね？
言語仕様の中だけでやろうとするとどうしてもC#とかJavaとかDめいてくる

0942デフォルトの名無しさん

2011/01/27(木) 21:54:44

コアそのものの記述にも使う言語でか

0943デフォルトの名無しさん

2011/01/27(木) 22:00:15

PauselessGC
http://www.infoq.com/jp/news/2010/06/azul_ori
ちなみにこれは商用の興味引くためのハリボテプロジェクトの可能性あり。
別のが実装されても、vmが必要ならclang+llvm経由かなーと思う。

0944デフォルトの名無しさん

2011/02/02(水) 03:32:01

C1xの方もCD投票に向けたドラフトが出てた
ttp://www.open-std.org/jtc1/sc22/wg14/
こっちはスレ立てるほど注目されてないかな

0945デフォルトの名無しさん

2011/02/02(水) 07:24:51

どうせまたC2xにすればよかったって事になるんだろ

0946デフォルトの名無しさん

2011/02/02(水) 19:05:38

C99が既に半分死に規格なんだから今さらだな

0947デフォルトの名無しさん

2011/02/02(水) 19:33:26

とりあえず立ててみた。
http://hibari.2ch.net/test/read.cgi/tech/1296642667/

0948デフォルトの名無しさん

2011/02/02(水) 19:41:42

そういえば、このスレもそろそろ次スレの時期だな。
まあ、この流れだと、まだしばらく大丈夫そうだけど。

0949デフォルトの名無しさん

2011/02/02(水) 21:13:41

ttp://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50372
>Target publication date: 2012-02-28

あと一年ちょい。

0950デフォルトの名無しさん

2011/02/03(木) 19:13:20

1年後にも後1年って言ってそうだな

0951デフォルトの名無しさん

2011/02/03(木) 19:14:44

いやconcept外して軽くなったし、まとまるでしょ。

0952デフォルトの名無しさん

2011/02/03(木) 19:28:03

本の虫氏が参考書を発売するのもそのころだな。

0953デフォルトの名無しさん

2011/02/03(木) 19:39:16

そのころにはまた変わってるんだろうな

0954デフォルトの名無しさん

2011/02/04(金) 07:53:50

永久に本も完成しないのか

0955デフォルトの名無しさん

2011/02/04(金) 07:58:54

あんまり伸びると本の虫氏が餓死しかねん

0956デフォルトの名無しさん

2011/02/04(金) 12:48:54

その時には、C++0x本に「本の虫死追討」という帯を着けるよ。

0957デフォルトの名無しさん

2011/02/04(金) 13:33:06

追い討ちをかけるなよw

0958デフォルトの名無しさん

2011/02/04(金) 23:57:54

何も完成版じゃなくても、策定途中版でも出せばいいのにな。

何で完成版にこだわるのか意味不明だ。

0959デフォルトの名無しさん

2011/02/05(土) 00:13:30

途中で仕様が変わってゴミになるかもしれないのに
そんなの買う人いるの？

0960デフォルトの名無しさん

2011/02/05(土) 00:22:21

ゴミになるかもしれない知識に10960のレスが付いているわけだ。

0961デフォルトの名無しさん

2011/02/05(土) 00:32:57

最終的な仕様ではなく途中経過にも価値はある罠

0962デフォルトの名無しさん

2011/02/05(土) 00:56:55

買う気がない人は何とでもいえるだろう

0963デフォルトの名無しさん

2011/02/05(土) 01:02:09

できれば紙の本として\5,000くらいで出てくれるとありがたいんだが。

0964デフォルトの名無しさん

2011/02/05(土) 01:12:06

ロングゲートから出るの?

0965デフォルトの名無しさん

2011/02/05(土) 03:32:02

>>958
VC6の悪夢を繰り返してはならない・・・と言いたいが
既に2010で同じ事が起こりそう

0966デフォルトの名無しさん

2011/02/05(土) 09:23:55

とっとと実装しろ派 vs 中途半端な物を実装するな派
に挟まれて苦悶するMS

0967デフォルトの名無しさん

2011/02/05(土) 09:44:15

お前らは参考書の話をしているのか、それともコンパイラの話をしているのかどっちなんだ。

0968デフォルトの名無しさん

2011/02/05(土) 10:28:18

VCのC++0x機能対応一覧表みたいなのってなかったっけ

0969デフォルトの名無しさん

2011/02/05(土) 13:49:08

>>968
http://wiki.apache.org/stdcxx/C++0xCompilerSupport

0970デフォルトの名無しさん

2011/02/06(日) 13:40:23

>>968
http://www.aristeia.com/C++0x/C++0xFeatureAvailability.htm
の一番下の"Language"をクリック。

0971デフォルトの名無しさん

2011/02/20(日) 21:20:31.02

ここもすっかり静かになってしまったな。ところで校長先生の本はまだかな。去年の年末に校了という話を見たんだが。

0972デフォルトの名無しさん

2011/02/22(火) 11:47:50.44

ラムダ関数で自己再帰関数が出来ません。
どうやったらできますか？
お願いします。

0973デフォルトの名無しさん

2011/02/22(火) 12:26:31.20

>>972
ラムダは関数ではなくて式です。諦めな。
どうしてもやりたいなら、
_ = lambda x: x if x == 0 else _(x-1)
_(3)
とか。

0974デフォルトの名無しさん

2011/02/22(火) 13:40:59.53

>>973
後半のコードの説明お願いします。

0975デフォルトの名無しさん

2011/02/22(火) 14:32:50.12

なにこれPython？

0976デフォルトの名無しさん

2011/02/22(火) 14:34:13.35

どうみてもPythonです本当に

0977デフォルトの名無しさん

2011/02/22(火) 14:47:03.10

>>972
named lambdaがない現状では、キャプチャーするstd::functionのオブジェクトに、クロージャーオブジェクトを入れておくしかない。

std::function<void(void)> f ;
f = [&]() -> void { f() ; } ;
f() ;

0978デフォルトの名無しさん

2011/02/22(火) 19:29:48.70

引数に自分自身のラムダを渡すとか？

0979デフォルトの名無しさん

2011/02/22(火) 19:57:46.27

C++0xF

0980デフォルトの名無しさん

2011/02/23(水) 01:50:49.15

質問です。
右辺値とかmoveとかをあまりよく分かっていないのですが、
ヘッダとソースで宣言と定義を分けられている関数で
クラスのインスタンスを戻り値で返したい場合に、
大抵の場合でパフォーマンス的に妥当な
C++0x時代の書き方というのはあるのでしょうか？
実体返しで良くなったとかいう話を目にしたりするのですが、
でもそれってインライン展開される場合だけの話？ですよね？

今は全て↓のように書いています。
std::shared_ptr<Hoge> Moge::getHoge()
{
auto hoge = std::shared_ptr<Hoge> (new Hoge());
hoge->hige();
return hoge;
}

0981デフォルトの名無しさん

2011/02/23(水) 02:13:09.81

>>980
new が入ってる時点でオーバーヘッドもクソもあんのか？
とは思うけど、 std::make_shared() 使うとか、あるいは std::unique_ptr 使うとかして
軽くすることはできそうに見える。

0982デフォルトの名無しさん

2011/02/23(水) 04:05:37.83

すみません、内部でnewしているのは確かに全く頓珍漢な例でした。
あと先の場合はstd::unique_ptrで良いのですね。ありがとうございます、勉強になりました。

ごめんなさい。書き直します。
以下のような値返しの非インライン関数を、呼び出し元へ最も処理コストを少なく返したい場合、
この関数または呼び出し元などで、C++0xでの特別な書き方が必要になるのでしょうか？

Hoge Moge::getHoge()
{
Hoge hoge;
hoge->hige();
return hoge;
}

0983デフォルトの名無しさん

2011/02/23(水) 04:25:04.71

Hogeがmove可能ならばNRVOが行われないときmoveされるので
そのままでいい

0984デフォルトの名無しさん

2011/02/23(水) 12:48:21.58

shared_ptrと違って、weak_ptrは比較演算子が無いの？
現在の規格上そうなっている？うーん、利用側で勝手に定義していいもの？

0985デフォルトの名無しさん

2011/02/23(水) 13:42:07.05

weak_ptrはそのまま使うものじゃねえよ
shared_ptrに格上げしてから使うもんだ

0986デフォルトの名無しさん

2011/02/23(水) 13:56:21.31

weak_ptrのままだと比較演算してる最中に消滅してもおかしくないわけだしな

0987デフォルトの名無しさん

2011/02/23(水) 18:52:19.89

メンバーもしくは、クラスの外に吐き出すならshared
ローカルから全く出る可能性がないならweakでいいんじゃねえの？
ついでに聞くけど、自動変数として確保したオブジェクトを
管理してくれるスマポって無いの？
自動変数が解放されそうになったら、ヒープにコピーしてくれるとか。

0988デフォルトの名無しさん

2011/02/23(水) 19:05:37.48

最初からヒープに確保するのじゃダメなのか

0989デフォルトの名無しさん

2011/02/23(水) 19:22:30.68

>>972
thisポインタ経由じゃできないのかな？
this->operator()とか

0990デフォルトの名無しさん

2011/02/23(水) 19:33:09.67

>>988
argvのような引き渡される形のポインタがあって400万とかデータが
入ってる。こんなもんコピーしたく無いじゃん。
でもこれをスマポを引数に取るクラスに渡したいんだよ。
状況によっては、スマポを引き渡すオブジェクトは、
オブジェクトを生成した関数の中で死ぬ。
最初からヒープにコピーするの無駄じゃん?

0991デフォルトの名無しさん

2011/02/23(水) 19:40:40.05

>>990
最初にデータを用意するところから全部ヒープでやれって話では？

0992デフォルトの名無しさん

2011/02/23(水) 20:14:45.84

argcが400万とか胸が熱くなるな

0993デフォルトの名無しさん

2011/02/23(水) 20:21:06.89

vectorとかで内部的にはヒープに確保されてるとかそんなオチな気がする
make_shared<T>(std::move(...))とかでヒープにmoveさせればいんじゃね？

0994デフォルトの名無しさん

2011/02/23(水) 21:08:32.91

>>987
こういう用途ならunique_ptrが適当に見えるけどね。
返り値にしなければ自動破棄されるし、返り値にすればmoveされるだろう。
もちろんデータのメモリはヒープにおくことになるが。

0995デフォルトの名無しさん

2011/02/23(水) 21:14:31.97

argc400万ワロタ

0996デフォルトの名無しさん

2011/02/23(水) 21:42:43.50

ラッパクラス作ってそれを動的に確保すればいいんじゃないの

0997デフォルトの名無しさん

2011/02/23(水) 22:05:39.41

そもそも400万とかスタックに入らんだろ

0998デフォルトの名無しさん

2011/02/23(水) 22:51:08.52

argvだけで16MBか

0999デフォルトの名無しさん

2011/02/23(水) 23:11:47.20

つか次スレは？

1000デフォルトの名無しさん

2011/02/23(水) 23:21:07.04

C++0x 12
http://hibari.2ch.net/test/read.cgi/tech/1298470844/

1001１００１

Over 1000Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。