5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

C++0x 11

1 :デフォルトの名無しさん: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/

2 :デフォルトの名無しさん:2010/10/01(金) 07:07:40
C++0x
http://pc11.2ch.net/test/read.cgi/tech/1149440647/
C++0x 2
http://pc11.2ch.net/test/read.cgi/tech/1191842951/
C++0x 3
http://pc11.2ch.net/test/read.cgi/tech/1204808027/
C++0x 4
http://pc11.2ch.net/test/read.cgi/tech/1214407525/
C++0x 5
http://pc12.2ch.net/test/read.cgi/tech/1232460649/
C++0x 6
http://pc12.2ch.net/test/read.cgi/tech/1245092251/
C++0x 7
http://pc12.2ch.net/test/read.cgi/tech/1253280377/
C++0x 8
http://pc12.2ch.net/test/read.cgi/tech/1262874195/
C++0x 9
http://pc12.2ch.net/test/read.cgi/tech/1269623636/

3 :デフォルトの名無しさん:2010/10/01(金) 07:11:10
C++学園で最近話題の人々

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

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

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

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

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

4 :デフォルトの名無しさん:2010/10/01(金) 07:14:17
○ムーブさん
最近、生徒会の役員に抜擢された期待の新人。
もう単なる一生徒ではないと大いばり。

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

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

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

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

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


5 :デフォルトの名無しさん:2010/10/01(金) 21:48:31
○attributeさん
最近になって任されていた仕事が次々に剥奪された。
今は死んだ魚のような目で「のーりたーん」と呟くばかり。

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

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

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

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

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

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

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

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

6 :デフォルトの名無しさん:2010/10/01(金) 22:04:27
attributeさんは可哀そうだな

7 :デフォルトの名無しさん:2010/10/01(金) 22:10:09
最近追ってなかったけど
attributeの機能が軒並みキーワード化されるのか?

8 :デフォルトの名無しさん:2010/10/01(金) 22:16:21
align,final,override,hiding,base_checkがキーワード化される見込みらしい
あとはnoreturnとcarries_dependencyしか残らない

9 :デフォルトの名無しさん:2010/10/01(金) 22:34:29
残りも時間の問題か

10 :デフォルトの名無しさん:2010/10/01(金) 22:34:59
なんだかしらないけどぼくにはべんりになるならなんでもいいとおもう
むずかしいことはかんがえたくないからぜんぶまかせます



11 :デフォルトの名無しさん:2010/10/01(金) 22:36:38
未だにこんなに変更多くて
本当に0x内に仕様固まるんだろうか

12 :デフォルトの名無しさん:2010/10/01(金) 22:45:04
その他特に動きのないお馴染みの人たち

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

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

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

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

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

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

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

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

13 :デフォルトの名無しさん:2010/10/01(金) 23:52:24
>>8
おお!それは願ったりかなったりだな。

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

14 :デフォルトの名無しさん:2010/10/02(土) 00:01:48
>>12
ラムダさんはもう実装されてる処理系があるから変えにくいよね。でもだからといっても必要ならかえる勇気も必要かも。
ラムダとautoはマジ便利なんでもう散々使ってるけど、より良い仕様になるなら非互換も我慢する

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

15 :デフォルトの名無しさん:2010/10/02(土) 00:21:48
先走って実装したり使用している人への配慮はしなくても良いと思うんだぜ。


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



16 :デフォルトの名無しさん:2010/10/02(土) 00:30:56
2010とかもう_
2011ですら怪しい

17 :デフォルトの名無しさん:2010/10/02(土) 00:34:34
このすれって11スレ目なの?17スレ目なの?紛らわしくない?

18 :デフォルトの名無しさん:2010/10/02(土) 00:39:29
>>17
紛らわしいけど
どっちでもいい

19 :デフォルトの名無しさん:2010/10/02(土) 01:34:19
投げやりな感じがイイ

20 :デフォルトの名無しさん:2010/10/02(土) 01:35:44
カンガルーが袋鼠目に分類されるみたいなもんだな

21 :デフォルトの名無しさん:2010/10/02(土) 01:36:56
何を言っているのかと思ったら
0x11
に見えるってことかw

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



22 :デフォルトの名無しさん:2010/10/02(土) 01:39:59
C++0xが2011年になるなら
Conceptさん復活できるんじゃないか。




23 :デフォルトの名無しさん:2010/10/02(土) 03:58:20
むしろ、conceptをドラフトからそぎ落とすために、規格制定が当初の予定より一年遅れているんだよ。

24 :デフォルトの名無しさん:2010/10/02(土) 08:27:27
それ以外のことも話し合っているように思えるんだが

25 :デフォルトの名無しさん:2010/10/02(土) 08:39:05
>>22
Conceptさんは欲しかったな。
Conceptさん無しのテンプレートプログラミングはとても人に勧められたものじゃねえ。エラーメッセージの解読が難しすぎるだろう。

26 :デフォルトの名無しさん:2010/10/02(土) 11:48:24
decltypeさんの括弧の有無の件は、妥当な仕様の気もするが、マクロ科との相性が最悪だよねたぶん。

27 :デフォルトの名無しさん:2010/10/03(日) 12:41:41
必死になってC++0xを生み出すよりC#を機械語にコンパイルできるようにしてくれたほうが世の為だよねJK

28 :デフォルトの名無しさん:2010/10/03(日) 12:56:37
ネイティブコードの需要はなくなることはないからな。
だけど、Cの腐った設計を補う機能を補う機能を補う機能を……というのが続いているような気がするので
C資産を無理なく併合できさえすればD路線の方が未来はある気がする

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

29 :デフォルトの名無しさん:2010/10/03(日) 13:03:19
D言語こそ理想だけど
仕様が固まってもっと多くの人が使える様になってくれないとなぁ。
結局 現実的に使えない言語は美しくても存在意義が無い。

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


30 :デフォルトの名無しさん:2010/10/03(日) 13:07:31
ていうか別にDじゃなくても、1978年のModula-2とかでも
メタプログラミングができないことを除けば、D言語と比べても遜色ないだけの機能を持ってたんだけどな。

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

31 :デフォルトの名無しさん:2010/10/03(日) 13:12:06
>>30
君の表現の場合、

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

ってこと??


32 :デフォルトの名無しさん:2010/10/03(日) 13:13:58
 メタプログラミングこそ正義ィィッ! メタプログラミングに不可能はないィィッ!

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


33 :デフォルトの名無しさん:2010/10/03(日) 13:14:23
>>30
C++は実通貨
他の言語、ゲーム内通貨

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

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

35 :デフォルトの名無しさん:2010/10/03(日) 13:30:14
禿は、オブジェクト指向とシステムプログラミングに使える言語が欲しかったわけだ。
「アセンブリを除いて、C++より低級層を挟まない」
他の言語をシステムプログラミングに対応させるより、汚いCにクラスを付け加えるほうが楽だった。

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

36 :デフォルトの名無しさん:2010/10/03(日) 14:01:59
いや、C++を勧める人はそう言うけどさ、実際DもModulaもそれより下はアセンブリしか低級層なんてないぞ

37 :デフォルトの名無しさん:2010/10/03(日) 14:23:54
DはGCがいるよ
いなくすることも出来るけど大変だよ

38 :デフォルトの名無しさん:2010/10/03(日) 14:25:31
記述レイヤを挟まない、ということではなく、ランタイムライブラリによる支援を
必要とする言語機能は却下、ではなかったか?

39 :デフォルトの名無しさん:2010/10/03(日) 14:27:50
>>38
dynamic_castとかあるのにそれはない。
そもそもFPUがCPUに内蔵されるのが一般化するまでは、浮動小数点演算すらランタイムの仕事だったぞ

40 :デフォルトの名無しさん:2010/10/03(日) 14:49:36
32ビットOSが一般化するまではlongの演算すら

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

41 :デフォルトの名無しさん:2010/10/03(日) 20:26:30
>>30
頭が幸せな発想だな

42 :デフォルトの名無しさん:2010/10/03(日) 20:31:06
>>38
ランタイムライブラリが必要なのはC++も同じ。
C++はCPUの動作に直結しているのがメリットでもありデメリットでもある。

43 :デフォルトの名無しさん:2010/10/03(日) 20:58:49
>>37
GCうらやましす。
GCとshared_ptrのデストラクタによる手動管理を両立させることもできるんでしょ、想像だけど。

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


44 :デフォルトの名無しさん:2010/10/03(日) 21:11:54
>>43
そげぶ

45 :デフォルトの名無しさん:2010/10/03(日) 21:25:14
そのためのscopeです

46 :デフォルトの名無しさん:2010/10/03(日) 21:27:51
C#のusingとかリソース管理方法を呼ぶ側で決めるとかバグの巣窟だろうに

47 :デフォルトの名無しさん:2010/10/03(日) 21:55:22
え?!

48 :デフォルトの名無しさん:2010/10/04(月) 05:19:37
Dはscopeクラスにすることでscope変数にすることを強制できるからC#とは違うな

49 :デフォルトの名無しさん:2010/10/04(月) 10:21:04
autoさんは中退歴があるが新入生には違いないか

50 :デフォルトの名無しさん:2010/10/04(月) 12:51:13
range-based forさんって、autoさんがいればいらない子なのかな。

51 :デフォルトの名無しさん:2010/10/04(月) 12:58:32
そんなことはない。しかしコンセプトさんが消えたため邪悪な子になってしまった。

52 :デフォルトの名無しさん:2010/10/04(月) 15:26:59
[理想]コンセプトさんとキャッキャウフフのバラ色の学園生活!
ーーーーーーーーーーーーーーーーーーーーーーーーーーーー
[現実]もういないコンセプトさんを求め続けるあまりヤンデレ化

53 :デフォルトの名無しさん:2010/10/04(月) 15:31:19
>>49
実はこの子同姓同名の別人じゃね

54 :デフォルトの名無しさん:2010/10/04(月) 16:48:47
>>49
修行して最強になって返ってきたって考えればまさに王道パターン

55 :デフォルトの名無しさん:2010/10/04(月) 19:34:23
コンセプトさんは結局なんでダメになったの

56 :デフォルトの名無しさん:2010/10/04(月) 21:34:57
「コンセプトさんはみんなのものだ!誰でも自由にお近づきになれるんだ!」派と
「コンセプトさんはそんな尻軽じゃない!正式に告白した相手としか付き合わないんだ!」派で
職員室が戦争になったから

57 :デフォルトの名無しさん:2010/10/04(月) 21:57:21
仕様が1つにまとまらなかったから外したのか
もったいなさ過ぎる

58 :デフォルトの名無しさん:2010/10/04(月) 22:03:19
>>57
しかし変な仕様で固まったらそれこそC++0xの未来が本気で
閉ざされるぞ。


59 :デフォルトの名無しさん:2010/10/04(月) 22:38:27
他の仕様は未だに手が入ってるし
もう2000年代に出すの諦めたというか無理だったんだから
粘っても良かった気がする

60 :デフォルトの名無しさん:2010/10/04(月) 22:51:45
>>59
>もう2000年代に出すの諦めた
次はC++3000か

61 :デフォルトの名無しさん:2010/10/04(月) 22:53:28
C++3000だったらどんだけ進歩しているんだろうなww

62 :デフォルトの名無しさん:2010/10/04(月) 22:59:21
目的を自然言語で入力するとアプリがビルドされる

63 :デフォルトの名無しさん:2010/10/04(月) 23:15:36
それってどこまで曖昧な内容で指示していいんだろうか

64 :デフォルトの名無しさん:2010/10/04(月) 23:22:37
g++ -ask "それってどこまで曖昧な内容で指示していいんですか?"

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


65 :デフォルトの名無しさん:2010/10/05(火) 00:32:13
禿の人格を移植するぐらいの勢い

66 :デフォルトの名無しさん:2010/10/05(火) 00:32:24
Python3000とか大した事無いよ?

67 :デフォルトの名無しさん:2010/10/05(火) 01:35:03
最近VC10導入したんだがautoとunique_ptrとlambdaだけでもう全然違うな
STLのコンテナとか右辺値参照のオーバーロードで
既存のテンプレートライブラリに適合できないとかインパクトあったわ
これ本格的な移行期は大変そうだね

68 :デフォルトの名無しさん:2010/10/05(火) 09:04:30
一番夢を感じるのは可変長天ぷら

69 :デフォルトの名無しさん:2010/10/05(火) 16:45:16
   ,.、,、,..,、、,..,、、,..,、、,..,、、,..,、、.,、,、、..,_       /i
  ;'`;、、:、. .:、. .:、. .:、. .:、. .:、:, :,.: ::`゙:.:゙:`''':,'.´ -‐i
  '、;: ...: ,:. : ,:. : ,:. : , :. : ,:. :.、.:',.: .:: _;.;;..; :..‐'゙  ̄  ̄

70 :デフォルトの名無しさん:2010/10/05(火) 16:50:57
   ,.、,、,..,、、,..,、、,..,、、,..,、、,..,、、,..,、、,..,、、.,、,、、..,_       /i
  ;'`;、、:、. .:、. .:、. .:、. .:、. .:、:, .:、. .:、:,:,.: ::`゙:.:゙:`''':,'.´ -‐i
  '、;: ...: ,:. : ,:. : ,:. : , :. : ,:. :.、.:',.: .:: _;.;;..; :.:.、.:',.: .:: _.‐'゙  ̄  ̄


71 :デフォルトの名無しさん:2010/10/05(火) 17:10:51
夢あふれるな

72 :デフォルトの名無しさん:2010/10/05(火) 17:27:25
>>69を書いておいて何だけとエビフライって天ぷらじゃないよね

73 :デフォルトの名無しさん:2010/10/05(火) 17:31:12
ワロタw

74 :デフォルトの名無しさん:2010/10/05(火) 20:13:34
そこに気づくとは…やはり天才か…

75 :デフォルトの名無しさん:2010/10/05(火) 20:21:43
エビ天じゃなかったのか!

76 :デフォルトの名無しさん:2010/10/05(火) 20:27:15
そろそろC++0x業務で使っていい?
今後ドカンと仕様変更されるかも…なんてことはないよね?

77 :デフォルトの名無しさん:2010/10/05(火) 20:29:48
ガンガン変わってるよ

78 :デフォルトの名無しさん:2010/10/05(火) 20:32:46
FCDとは一体何だったのか

79 :デフォルトの名無しさん:2010/10/05(火) 21:13:59
>>78
ただのまやかしである。

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

80 :デフォルトの名無しさん:2010/10/06(水) 01:29:58
C++ 改

81 :デフォルトの名無しさん:2010/10/06(水) 01:33:24
C++Z

82 :デフォルトの名無しさん:2010/10/06(水) 02:06:52
C++乙


83 :デフォルトの名無しさん:2010/10/06(水) 02:36:36
最近ダイテルのC++買っちゃったけど今から始めてもまぁ良いよね・・・

84 :デフォルトの名無しさん:2010/10/06(水) 03:44:48
>>78
First Committee Draft の略じゃね

85 :デフォルトの名無しさん:2010/10/06(水) 13:10:45
>>84
いくつまであるんだーーーwww


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


86 :デフォルトの名無しさん:2010/10/06(水) 20:21:27
Deitel一族

87 :デフォルトの名無しさん: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

88 :デフォルトの名無しさん:2010/10/06(水) 21:05:19
大照さん

89 :デフォルトの名無しさん:2010/10/06(水) 23:12:31
>>87
どうせ暫く仕様固まらないからその間に勉強したら良いだろ。

90 :デフォルトの名無しさん:2010/10/07(木) 02:35:29
>>87
良書

91 :デフォルトの名無しさん:2010/10/11(月) 12:16:42
usingをスコープ付きのエイリアスみたいな機能にすれば便利なのに


92 :デフォルトの名無しさん:2010/10/11(月) 12:17:48
>>91
参照との違いは?

93 :デフォルトの名無しさん:2010/10/11(月) 13:11:25
余計なポインタ持たなくていいじゃない

94 :デフォルトの名無しさん:2010/10/11(月) 13:17:05
>>93
参照≠ポインタ

95 :デフォルトの名無しさん:2010/10/11(月) 13:35:57
そりゃ言語仕様上はそうでも、実装する時は結局何か指し示すもの渡さないといけないだろ
結局ポインタだよ

96 :デフォルトの名無しさん:2010/10/11(月) 13:43:24
必ずしもポインタを介する必要が無いし、ポインタ必須の箇所ではusingは使えないし

97 :デフォルトの名無しさん:2010/10/11(月) 14:07:52
何の話よ?usingは参照ともポインタとも全く違うだろ
異次元にあるものをごっちゃにするな


98 :デフォルトの名無しさん:2010/10/11(月) 14:25:15
だいたい、どのusingだよ?
usingキーワードを使う文法はみっつもあるぞ。

99 :デフォルトの名無しさん:2010/10/11(月) 14:38:18
typedefで事足りるんじゃないの

100 :デフォルトの名無しさん:2010/10/11(月) 16:31:44
typedefじゃ関数や変数やテンプレートの別名がつけられない
参照やポインタではコストがかかるかもしれない
マクロは安全性に犠牲がでる
一番良いのはマクロと同じ機能をプリプロセスではなく言語でサポートしてスコープの概念を付け加えること

101 :デフォルトの名無しさん:2010/10/11(月) 17:46:52
そんなのがあると今度はtypedefがいらなくなるなw

102 :デフォルトの名無しさん:2010/10/11(月) 19:20:32
using template とは違うんだよね?
必要になる場面が思いつかないな

103 :デフォルトの名無しさん:2010/10/11(月) 20:02:24
いや、D言語ではなんでもかんでもaliasで別名作れるんだけど、確かにすごい便利だぞ。
恐らくC++に導入されても、usingやらtypedefやら参照やらを一掃する勢いになる。
実際Dではtypedefが消滅した。

104 :デフォルトの名無しさん:2010/10/11(月) 20:06:33
C++ 0x FAQにunique_ptrははいかなる形の動的チェックも提供しないってあるけど
auto_ptrやscoped_ptrと同じで動的削除子がないって理解でいいのかな?
pimplで試したら、デストラクタを定義しないとコンパイルできなかった

105 :デフォルトの名無しさん:2010/10/11(月) 20:15:33
std::smart_ptrのような動的なデリーターはないね。
テンプレート実引数として指定する、静的なデリーターならあるけど。

106 :デフォルトの名無しさん:2010/10/11(月) 20:27:25
std::smart_ptrってどこのパチモンだよ

107 :デフォルトの名無しさん:2010/10/11(月) 20:34:52
>>105
ありがとうございます
以前どっかのスレで動的削除子があるような書き込みがあったので
一応確認してみました

108 :デフォルトの名無しさん: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>())
{
}

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

109 :デフォルトの名無しさん:2010/10/11(月) 21:19:52
shared_ptrだったw

110 :デフォルトの名無しさん:2010/10/11(月) 22:41:03
ttp://ja.wikipedia.org/wiki/C%2B%2B0x
> ...演算子を型名の左側におく場合、これは"pack"演算子
> ...演算子が型名の左側にある場合は、"unpack"演算子

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


111 :デフォルトの名無しさん:2010/10/11(月) 22:47:19
wikipediaの情報は大抵間違っているから信用するな。
とくに、日本語版は最悪で、暇人の自治厨が仕切っているからな。


112 :デフォルトの名無しさん:2010/10/11(月) 23:00:32
プログラム関係はそもそも過疎っているので、あんまり自治厨は見かけない気がする。
もちろん、大抵間違っていることは変わりない。過疎、つまり直す人もいないということでもある。

113 :デフォルトの名無しさん:2010/10/11(月) 23:27:32
>>111
あそこは事実や真実より声の大きい奴が勝つ場所だからどもならん


114 :110:2010/10/11(月) 23:43:25
>>110 に書いたページを、結構、楽しく読んでから来てみれば
>>111-113 こんな書き込みw

じゃ、ほっとくか。

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

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


115 :デフォルトの名無しさん:2010/10/12(火) 00:08:53
C++0xみたいなやつの場合、書いた時点では正しくても、
その後の変化に記事が追いついていないということもよくある。

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

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

116 :デフォルトの名無しさん:2010/10/12(火) 00:43:32
>>114
>プログラムの書き方が、かなり変わってくるんでしょうか?
パラダイムシフトするかっていう意味なら変わらないと思う、ただ新しい書き方を適用可能になるのでより意図を伝えやすくなるコードを書けるようになる
なのでプログラマの意識次第だと思うぞ


117 :デフォルトの名無しさん:2010/10/12(火) 00:55:01
また新しい定石みたいなもんが増えんのかねめんどくさい

118 :110: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版を、読むことになると。


119 :デフォルトの名無しさん:2010/10/12(火) 02:30:58
Effective C++0xか
そろそろ常人には手がつけられなくなりそうな

120 :デフォルトの名無しさん:2010/10/12(火) 03:05:55
もうすでに…
ここまでついてきてる奴には、さほど問題なかろう。

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

121 :デフォルトの名無しさん:2010/10/12(火) 09:03:51
ウィキペディアは間違ってたら直せよ。

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

122 :デフォルトの名無しさん:2010/10/12(火) 09:08:50
憂国の戦場な記事以外はだいたいあってるよな

123 :デフォルトの名無しさん:2010/10/12(火) 12:08:06
直そうにも、現状で多くのISPのIPは、自治厨によって永久にBANされている。
ログインしない限り書き込めない。
しかし、アカウントを作るためには、BANされていないIPが必要。

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

124 :デフォルトの名無しさん:2010/10/12(火) 12:22:10
お前どんな悪行を働いたんだ……

125 :デフォルトの名無しさん:2010/10/12(火) 12:44:42
>>124
俺じゃねーよ。
同じISPを使っている(使っていた)誰かだよ。

126 :デフォルトの名無しさん:2010/10/12(火) 15:19:09
ムーブさんの立場が微妙なことに……
http://cpp-next.com/archive/2010/10/implicit-move-must%c2%a0go/

127 :デフォルトの名無しさん:2010/10/12(火) 16:21:53
C++学園の黒歴史の面々

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

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

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

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

○exportさん
退学

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

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

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

128 :デフォルトの名無しさん:2010/10/12(火) 16:29:48
暗黙のコピー「暗黙のムーブがやられたようだな」
暗黙のデフォコン「ククク…奴は四暗黙の中でも最弱…」
標準型変換「互換性ごときに負けるとは暗黙界の面汚しよ…」

129 :デフォルトの名無しさん:2010/10/12(火) 17:12:52
>>128
そりゃあ、創立メンバーの3人と比べりゃなw

130 :デフォルトの名無しさん:2010/10/12(火) 17:22:02
暗黙のデストラクタ「……」

131 :デフォルトの名無しさん:2010/10/12(火) 18:00:16
暗黙なんて何一つ要らない


132 :デフォルトの名無しさん:2010/10/12(火) 18:40:45
昔は俺もそう思ってたけど、暗黙のコピーコンストラクタ、代入演算子を積極的に使うように変わってきた。

133 :デフォルトの名無しさん:2010/10/12(火) 18:44:58
演算子って暗黙の関数呼び出しですか?

134 :デフォルトの名無しさん: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) { }
} ;

135 :デフォルトの名無しさん:2010/10/12(火) 18:57:12
そんな糞構造体を書くプログラマは暗黙のうちに解雇して良い

136 :デフォルトの名無しさん:2010/10/12(火) 19:14:52
>>134
うわぁ…

137 :デフォルトの名無しさん:2010/10/12(火) 19:41:55
>>134
ステキな例

138 :デフォルトの名無しさん:2010/10/12(火) 19:42:48
>>134
ちなみにboost.preprocessorライブラリでそれを書けば
暗黙のコピーコストラクターがなくても
もっと簡単に記述できるのかな、と。


139 :デフォルトの名無しさん:2010/10/12(火) 19:52:15
暗黙コピコンがないとCの構造体コピーがコンパイル通らないだろ
これも互換性のための汚い仕様

140 :デフォルトの名無しさん:2010/10/12(火) 20:01:15
暗黙のコピーコンストラクターが無かったら、全てのメンバー変数をコピーするコードを間違えないように書かなくちゃならないじゃないか
メンバー増やしたときに追加忘れすると面倒なバグになるじゃないか

141 :デフォルトの名無しさん:2010/10/12(火) 20:04:25
>>140
うわぁ

142 :デフォルトの名無しさん:2010/10/12(火) 20:21:06
デフォルトコピーコンストラクタで、メンバ変数のコピーコンストラクターが自動的に呼ばれるけど違った?

143 :デフォルトの名無しさん:2010/10/12(火) 20:34:57
>>140
面倒か?
コンパイルエラーになるだけなら大したことないと思うが

144 :デフォルトの名無しさん:2010/10/12(火) 20:38:41
初期化子書き漏らししてもエラーになら無い場合があるし

145 :デフォルトの名無しさん:2010/10/12(火) 22:05:53
現状の暗黙のコピーコンストラクタと同等の物を明示的に作成する構文があればいいんだろ。
俺はそんな物を作るくらいならコピーコンストラクタの自動生成でいいと思うけど。

146 :デフォルトの名無しさん:2010/10/12(火) 22:10:50
default定義さん「……」

147 :デフォルトの名無しさん:2010/10/12(火) 22:12:04
=defaultって毎回書くのめんどいから
class Hoge
{
public:
default{
Hoge();
Hoge(const Hoge &);
Hoge(Hoge &&);
}
};
これ通るようにするべき

148 :デフォルトの名無しさん:2010/10/12(火) 22:14:04
default定義 でググるとSQLのCREATE TABLE文ばっかりヒットするしなあ……

149 :デフォルトの名無しさん:2010/10/12(火) 22:15:13
virtual foo() = 0; って毎回書くのめんどいから(ry

150 :デフォルトの名無しさん:2010/10/12(火) 22:16:14
>>146
いやあごめんごめん。コンストラクタさんとも仲良しってことをすっかり忘れてたよ。

151 :デフォルトの名無しさん:2010/10/12(火) 22:17:54
>>149
class Hoge
{
public:
virtual {
void foo();
void bar();
void baz();
} = 0;
};
最高にクールだな

152 :デフォルトの名無しさん:2010/10/12(火) 22:20:39
そんなことよりなんでラムダ式に呼び出し規約を指定できないんだよ。
C#みたいにラムダをコールバック関数として使いたいのに。
しょうもないコールバックのためにわざわざ非メンバ関数やグローバル変数を
定義するのはいやだお。

153 :デフォルトの名無しさん:2010/10/12(火) 22:43:03
>>152
ラムダ式は関数じゃなくて関数オブジェクトだから呼び出し規約はないだろう

154 :デフォルトの名無しさん:2010/10/12(火) 22:46:16
関ポに出来るなら関ポになるんじゃなかったっけ

155 :デフォルトの名無しさん:2010/10/12(火) 22:46:54
呼び出し規約?
MSVCにおける__stdcallとかか?
そんな規格外のことを言われてもな。
規格的にいえば、attributeで実装して欲しいところだが、
規格を守る気のないMSがやるかなぁ?

156 :デフォルトの名無しさん:2010/10/12(火) 22:47:46
>>153
一応、何もキャプチャーしてないと、単なる関数ポインターに変換可能。

157 :デフォルトの名無しさん:2010/10/12(火) 22:51:53
まずは、API関数をラップして、好きなファンクションオブジェクトを引数に取れるラッパを作ればいい。
そしたら、ラムダ式でも何でも渡し放題だ。
ってのをWinSTLとかやっていないかなあ?

158 :デフォルトの名無しさん:2010/10/12(火) 23:09:11
gccのトランポリンは外のローカル変数に触ってても普通にstdcallでコールバックできるし、clangのblocksとかもあるし
ラムダめいたことに関してはC言語の独自拡張の方がC++よりもずっと進んでる

159 :デフォルトの名無しさん:2010/10/12(火) 23:11:47
独自拡張は独自拡張でしかないからなぁ…
一生窓やリンゴだけ食って生きてく覚悟があればいいんだろうけど

160 :デフォルトの名無しさん:2010/10/12(火) 23:14:07
blocksはちょっと色々とアレなとこが・・・

161 :デフォルトの名無しさん:2010/10/13(水) 01:52:43
>>158
トランポリンはスタック全部に実行可能属性が付く気持ち悪い仕様

162 :デフォルトの名無しさん:2010/10/13(水) 02:13:09
Windowsでは、呼び出し規約が統一された64bitコードにさっさと移行しろってことだろ。
まあ、それが出来れば苦労しないんだろうがな。

163 :デフォルトの名無しさん:2010/10/13(水) 05:44:06
呼び出し規約自体独自拡張なんだから、
[](int x) [[ __stdcall ]] -> { return x; } みたいに
attribute さんに仕事をあげればいいのに

164 :デフォルトの名無しさん:2010/10/14(木) 01:59:52
気持ち悪さに磨きかかっちゃってる・・・

165 :デフォルトの名無しさん:2010/10/14(木) 03:01:37
どうせならラムダの最初の[]の中にattributeを書くようにすればいいのに……。

166 :デフォルトの名無しさん:2010/10/14(木) 04:20:16
同名の変数が有ったらどうすんだよ

167 :デフォルトの名無しさん:2010/10/14(木) 07:45:34
class Hoge
{
public:
 const {
  void foo();
  void bar();
  void baz();
 };
};


168 :デフォルトの名無しさん:2010/10/14(木) 11:36:19
class Hoge
{
public:
 const {
  void {
   { foo, bar, baz }();
  }
}
};

169 :デフォルトの名無しさん:2010/10/14(木) 18:13:56
>>166

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

170 :デフォルトの名無しさん:2010/10/14(木) 20:14:27
キモさに磨きがかかるな

171 :デフォルトの名無しさん:2010/10/14(木) 20:49:15
>>168
便利すぎてやばいな
これ考えたやつは天才だと思う

172 :デフォルトの名無しさん:2010/10/14(木) 20:51:01
>>167
ってOKなの?


173 :デフォルトの名無しさん:2010/10/15(金) 07:24:12
いや夢語りだろう。

174 :デフォルトの名無しさん:2010/10/16(土) 19:29:55
VBのWithに通じるクソっぷりを感じる

175 :デフォルトの名無しさん:2010/10/16(土) 20:52:23
>>174
何行も前を確認しないと関数の定義がわからないとか駄目すぎるね。

176 :デフォルトの名無しさん:2010/10/16(土) 21:13:15
何行も前を確認しないと関数のアクセスレベルがわからないなんて……

177 :デフォルトの名無しさん:2010/10/16(土) 21:36:54
class Hoge
{
public virtual Hoge const & { foo, bar, baz } (void) const throw() = 0;
};

う、美しい。。。

178 :デフォルトの名無しさん:2010/10/16(土) 21:37:50
何行も前を確認しないとクラスの名前がわからないなんて……

179 :デフォルトの名無しさん:2010/10/16(土) 21:46:34
C#みたいに全メンバにアクセス修飾子がついたクラスなら見たことがある。

180 :デフォルトの名無しさん:2010/10/16(土) 21:47:42
それはメンバの再配置期待してるんだろ
たまにやるよ

181 :デフォルトの名無しさん:2010/10/16(土) 21:53:00
メンバのre-orderしてくれんなら俺もやろうかな

182 :デフォルトの名無しさん:2010/10/16(土) 22:54:22
他はともかく、staticだけはpublic:なんかと同類でグループ指定にしたほうが分かりやすい気はするな

183 :デフォルトの名無しさん:2010/10/17(日) 09:03:47
メンバの再配置って class A { public: char a; public: int b; public: char c; };
のメンバが b,a,c の順にメモリに並んでくれるのかと思ったけど、そうじゃないね。

184 :デフォルトの名無しさん:2010/10/17(日) 10:04:52
>>183
PODにすれば記述順配置になるんじゃなかった?

185 :デフォルトの名無しさん:2010/10/17(日) 12:09:51
別にPODでなくても、publicなメンバ同士、protectedなメンバ同士、private:なメンバ同士は
それぞれ記述順に配置される

186 :デフォルトの名無しさん: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"とは何なのかハッキリ定義されてないからどっちにも読める

187 :デフォルトの名無しさん:2010/10/17(日) 18:08:48
なるほど。the same access control って、
(a,b,f) (c,d) (e) が同じって意味だと思ってたけど
(a,b) と (f) は違うって解釈もできるのね…

188 :デフォルトの名無しさん: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になった)


189 :デフォルトの名無しさん:2010/10/18(月) 22:45:34
ですよねー。。。

190 :デフォルトの名無しさん:2010/10/18(月) 23:48:46
なんだダメになってたのか
それにしても修正入れた割には曖昧な文言だな

191 :デフォルトの名無しさん:2010/10/18(月) 23:59:22
最適化するしないで互換性が無くなるクラスとか有ったら死ねる

192 :デフォルトの名無しさん:2010/10/19(火) 11:10:46
というか配置順変えていた実装あるんかいな。

193 :デフォルトの名無しさん:2010/10/19(火) 15:30:28
sunのコンパイラが宣言と逆順に配置してたよ

194 :デフォルトの名無しさん: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
は必要ないのか?とか、環境依存性は?とか、色々気になります。

195 :デフォルトの名無しさん:2010/10/20(水) 05:04:29
>>194
なんで _GNU なんてついたマクロが必要かもしれないなんて思うのか、わからない。
「環境依存性は?」と言われても仕様を見たとおり、としか言えない。

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

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

196 :194:2010/10/20(水) 05:35:57
ttp://linux.die.net/man/3/fenv
とかを見ると、細かい設定をglibc拡張でやれるって話みたいでした。
色々混乱しててすみません。

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

197 :デフォルトの名無しさん:2010/10/20(水) 21:57:29
ムーブさん先行き不安だな…

198 :デフォルトの名無しさん:2010/10/20(水) 22:59:21
moveは仕様をきっちり作り込むのが難しいよね。

199 :デフォルトの名無しさん:2010/10/20(水) 23:11:49
ムーブさんはコンセプトさんと似たような泥沼に入りかけてる気がしてならない

200 :デフォルトの名無しさん:2010/10/20(水) 23:32:13
コンセプトさんが憑いたのか

201 :デフォルトの名無しさん:2010/10/21(木) 04:22:42
右辺値参照さんまさかの入学取り消しあるで

202 :デフォルトの名無しさん:2010/10/21(木) 12:08:14
内定取り消しか…胸が熱…(´;ω;)ウッ

203 :デフォルトの名無しさん:2010/10/21(木) 15:12:05
右辺値さんmixiで調子乗ってなんかやらかしたんだってさ

204 :デフォルトの名無しさん:2010/10/21(木) 19:52:22
おまえら全員留年な

205 :デフォルトの名無しさん:2010/10/22(金) 08:17:45
>>201
詳細求む


206 :デフォルトの名無しさん:2010/10/23(土) 14:36:01
デフォルトムーブコンストラクタの件じゃないのか?うまく折り合いをつけて採用してほしいところ。

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

207 :デフォルトの名無しさん:2010/10/23(土) 15:57:02
range-based for文さんを道連れに消えていったコンセプトって子がおってな

208 :デフォルトの名無しさん:2010/10/23(土) 16:32:37
【スキャンダル】入学審査で不正疑惑が【椿事】

209 :デフォルトの名無しさん:2010/10/23(土) 17:14:43
>>207
あたらしい転校生のBOOST_FOREACHさん。,さんが苦手。


210 :デフォルトの名無しさん:2010/10/23(土) 19:57:52
というか、range-based forいらねーよ。
その次の規格でconceptと一緒に入れてくれよ。

211 :デフォルトの名無しさん:2010/10/24(日) 13:50:19
そうか?
使ってみると、意外と便利だぞ。
まあ確かに、今のような糞なイテレート方式じゃなくて、concept使って欲しかったところだが。

212 :デフォルトの名無しさん:2010/10/24(日) 13:55:55
range based forぐらい自分でパチもん実装できるからいいじゃん
つーかboostもあるし

213 :デフォルトの名無しさん:2010/10/24(日) 14:07:26
そんなこと言ってたらC++0xが要らなくなるだろ

214 :デフォルトの名無しさん:2010/10/24(日) 14:11:00
polymorphic lambdaがない以上、以下のコードがうまくいかないんだよな。

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

215 :デフォルトの名無しさん:2010/10/24(日) 14:18:01
どううまくいかないの?
一見して問題なさそうだけど。
実際、gcc4.6 ではエラーにならない。

216 :214:2010/10/24(日) 14:26:36
いや、ちがうちがう。
パチもんが実装できないということ。

217 :デフォルトの名無しさん:2010/10/24(日) 15:37:59
range-based forって一つの書き方で多くの範囲オブジェクトをカバーできるところが大きな魅力になってるの?
俺はよく使うコンテナクラスにそれぞれ特化したforを定義して使ってるんだけど

218 :デフォルトの名無しさん: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も使えるし

219 :デフォルトの名無しさん:2010/10/24(日) 16:31:44
>>218
いいな
俺はvから元クラス参照でそこから::iteratorでもいいんだけどね
要するに元の宣言vector<int> をvからひきだしたいだけなんだけど
コードの中にtypdef宣言いれないでmapとかの長い宣言作ると::iteratorの書式が長くて嫌いなんだよね


220 :デフォルトの名無しさん:2010/10/24(日) 16:51:47
>>219
auto使えばいいんじゃね?

221 :デフォルトの名無しさん:2010/10/24(日) 19:04:44
理想は>>218がこうなればいいんだけどな
int s = std::accumulate(v, 0);

222 :デフォルトの名無しさん:2010/10/24(日) 19:13:44
>>220
foreach(auto x:v){}
だな。
BOOST_FOREACH(auto x,v){}
でもOK
>>221
boost::range や Ovenがそれの役目だな。

223 :デフォルトの名無しさん:2010/10/24(日) 19:56:57
標準ライブラリのコンセプト対応で可能になるはずだったのにね・・・

224 :デフォルトの名無しさん:2010/10/24(日) 20:04:43
おまいらには、頭が下がります.
物覚えが良くないので, 0x の変態構文にはもうついていけんわ
# つか, テンプラの時から思ってたんだが,
# lisp の ` と , を知ると何とか整理してくれやぁ!!! になる


225 :デフォルトの名無しさん:2010/10/24(日) 20:09:39
>>223
コンセプトがあればエラーメッセージがまだ判りやすくなるのにな。
意味不明のエラーメッセージは新規ユーザにとってかなりハードル高いな。
boost conceptcheckでもかなり改善になるから採用されないかな。


226 :デフォルトの名無しさん:2010/10/24(日) 20:11:13
>>224
いえいえ、御代官様の括弧式ほどでは。ふっふっふ


227 :デフォルトの名無しさん:2010/10/24(日) 23:33:55
禿げよ。

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

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

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

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

228 :デフォルトの名無しさん:2010/10/24(日) 23:42:44
xrvalue → xvalue

229 :デフォルトの名無しさん:2010/10/24(日) 23:55:02
>>227
互換性を無視していいなら、同等以上の機能を遥かにシンプルに定義できるっしょ。
xvalueも、規格の文面を全面書き換えするのを避けた結果なんだっけ?

230 :デフォルトの名無しさん:2010/10/25(月) 09:59:31
禿曰く、

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

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

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

・ムーブできるかどうか

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

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

231 :デフォルトの名無しさん: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 さんを導入する動機が
やっぱりわからん

232 :デフォルトの名無しさん:2010/10/25(月) 13:32:01
beginとendと*itを書く事すらめんどくさいから

233 :デフォルトの名無しさん:2010/10/25(月) 13:32:37
あとはアダプタ噛ませるときに便利だから

234 :デフォルトの名無しさん:2010/10/25(月) 19:10:38
>>230
例えばxvalue, lvalue, prvalueには具体的にそれぞれどんなものが該当するの?

235 :デフォルトの名無しさん:2010/10/25(月) 20:11:01
>>231
配列だと .begin() とか書けないから


236 :デフォルトの名無しさん:2010/10/25(月) 21:10:36
さすがに右辺値と左辺値の区別くらいはついてないと、コンパイルエラーも読めないんじゃないか?

237 :デフォルトの名無しさん:2010/10/25(月) 21:16:54
lvalueは今まで通りのlvalue
prvalueは今まで通りのrvalue
xvalueは右辺値参照のこと

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

238 :デフォルトの名無しさん:2010/10/25(月) 21:36:13
lやrまではまだいいとして、pとかxとかわかんねえだろ
分かりやすくするという気はないのかね?

239 :デフォルトの名無しさん:2010/10/25(月) 21:43:57
お前がわかりやすい名称を提案すればいいんじゃないかな?

240 :デフォルトの名無しさん:2010/10/25(月) 21:57:11
省略するからだめなんだよ

241 :デフォルトの名無しさん:2010/10/25(月) 22:02:00
prvalueって見た目通りpointer rvalueなんすか?

242 :デフォルトの名無しさん:2010/10/25(月) 22:02:34
pureだろう

243 :デフォルトの名無しさん:2010/10/25(月) 23:34:26
「ムーブ可能」ってどういうこと?定義あるの?

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


244 :デフォルトの名無しさん:2010/10/25(月) 23:39:32
>>238
名前がどうのこうの言う前に概念理解してないだろ。
素直になれ。名前なんて単なる名前だ。酷い命名でもないし。

245 :デフォルトの名無しさん:2010/10/26(火) 00:02:22
>>243
もう必要ないから中身を好きなようにぶち壊してよい物体のこと

246 :デフォルトの名無しさん:2010/10/26(火) 00:03:24
>>244の書いたコードが見てみたいな

247 :デフォルトの名無しさん: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になったけど。

248 :デフォルトの名無しさん:2010/10/26(火) 06:41:16
>>231
autoって大昔のcのころの機能イメージがあってちょっとコードみててもにょるのが難点


249 :デフォルトの名無しさん:2010/10/26(火) 11:14:46
>>247

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

こめん、上の2行目と4行目の記述が矛盾しているように見える。
「ストレージが確保されている保証もない値」 なら 「安全にムーブ」 でき
ないと思うけど。

「ストレージが確保されている保証もない」 が 「メモリが、名前のある
ポインタ変数によって管理されていない」 という意味ならわからんでも
ないが。


「Move(移動)」とは、右辺値オブジェクト(一時オブジェクト)が(そのデータ
メンバであるポインタを通して)管理している動的メモリを、左辺値オブジ
ェクトが管理している動的メモリとswapすることだと勝手に解釈してたけど、
これって間違い?

両者の動的メモリのアドレスをswapすれば、メモリのコピーも必要ないし、
右辺値オブジェクトはどうせ破壊されるから問題ないと思ってたけど。

250 :デフォルトの名無しさん:2010/10/26(火) 11:26:20
int x = 0 ; int y = 0 ;
int z = x + y ;

ここで、x + yという式を評価した場合、その結果を表す一時オブジェクトが生成されるが、
この一時オブジェクトは、具体的なストレージを持たなくてもよい。

ただし、xvalueにされたときは、具体的なストレージが必要となる。

int && rref = x + y ;

ムーブは、言語的にいえば、ムーブコンストラクターかムーブ代入演算子を呼び出すこと。
ライブラリ的にいえば、仮引数の型がrvalueリファレンスな関数も、ムーブしていると言える。

ムーブの具体的な実装は、好きにすればいい。
体一、コピーの具体的な実装も、好きにしていいのだから。
もちろん、デフォルトのコピー、ムーブコンストラクターや代入演算子の定義はあるけどね。

251 :デフォルトの名無しさん:2010/10/26(火) 16:40:54
ストレージってメモリ上ってこと?
それなら、その保証がないのはlvalueだってアドレス参照されない限り
同じなのでは?

252 :デフォルトの名無しさん:2010/10/26(火) 18:20:59
「常に可能であること」を「保証されている」と日本語では言う。
e.g. 常にアドレス参照可能



253 :デフォルトの名無しさん: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;
}


254 :デフォルトの名無しさん:2010/10/26(火) 20:51:18
ムーブコンストラクタが無いから参照になってるんじゃ

255 :デフォルトの名無しさん:2010/10/26(火) 20:52:40
ムーブ後の変数は使える保証はなくなるけど、必ずしも使えなくなる
わけじゃないよね。

256 :デフォルトの名無しさん:2010/10/26(火) 20:53:22
deleteされた領域を参照すると値が残ってたりするのと一緒

257 :デフォルトの名無しさん:2010/10/26(火) 21:04:53
あくまでも高速化のための機能だから、nullで埋めるなんてことはしてくれないんだね。

258 :デフォルトの名無しさん:2010/10/26(火) 22:50:42
[&]() { std::cout << "1" << std::endl; };

これやっぱ何回見ても気持ち悪いわ
C++0xで最も汚いのはラムダ式だと思う

259 :デフォルトの名無しさん:2010/10/26(火) 23:01:48
代替案を出さなかったのが悪い

260 :デフォルトの名無しさん:2010/10/26(火) 23:13:36
ラムダさんは使いつづけてると
やっぱりこの形しかないかなぁと思えてくるよ

261 :デフォルトの名無しさん:2010/10/26(火) 23:21:52
int x;
lambda(int a) { vcap.x = a; } //値キャプチャ
lambda(int a) { rcap.x = a; } // 参照キャプチャ

262 :デフォルトの名無しさん:2010/10/26(火) 23:37:31
C++0x版のD&Eが今から楽しみだな
ビャーネ・ストロヴストルップ先生のブツクサ文句が山ほど書かれていると思うと・・・

263 :デフォルトの名無しさん:2010/10/26(火) 23:46:16
弾道軌道からの眺めも書いてくれるかな

264 :デフォルトの名無しさん:2010/10/26(火) 23:47:03
俺はEC++0xが楽しみ

265 :デフォルトの名無しさん:2010/10/26(火) 23:52:46
>>253
VC++2010もってないしstd::moveも引数に何とるのか解らんけど、
std::moveがMove Constractorと同じ意味合のものだとしたらマズくね?
なんで名前が使えるものを渡されてコンパイルエラーにならないんだ?

266 :デフォルトの名無しさん:2010/10/26(火) 23:58:21
>>265
std::moveでキャストしてるからコンパイルエラーにならない

267 :デフォルトの名無しさん:2010/10/27(水) 00:02:05
std::move() ってのが一種のキャストというか、無理を押し通すための道具だから。

268 :デフォルトの名無しさん:2010/10/27(水) 00:03:16
>>258
もうすっかり慣れっこになったけど、時々C#のラムダ式を書くとき混乱する。

269 :デフォルトの名無しさん:2010/10/27(水) 00:58:59
>>267
んなもん何のために使うのかさっぱりわからんなぁ。
const_castを全く使わんからかもしれんけど。
(旧C互換で定数をchar*で渡す関数にしか使ったこと無い)

270 :デフォルトの名無しさん:2010/10/27(水) 01:06:26
左辺値を強制的に右辺値に変更する働きをする
これで意味が分からなかったらぐぐれ

271 :デフォルトの名無しさん:2010/10/27(水) 01:12:37
コピーコンストラクタとムーブコンストラクタに限らず、左辺値参照と右辺値参照を取る
オーバーロードがあって、しかも効率の差が大きい場合、

void hoge(int &x); // 左辺値を渡しても安全だけど遅い
void hoge(int &&x); // 左辺値を渡すと安全は保証されないけど速い

左辺値をどうしても下の関数に渡したい時に使う。

272 :デフォルトの名無しさん:2010/10/27(水) 01:14:49
>>255-256
つまり、VC++2010のムーブの実装はswapじゃないってこと?

273 :デフォルトの名無しさん:2010/10/27(水) 01:20:10
>>272
つうか、おそらく単なる参照渡し。
ムーブ後の抜け殻に触った結果はどうせ未定義なんだから、仕様は満たしてるよね。

274 :デフォルトの名無しさん: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)

275 :デフォルトの名無しさん:2010/10/27(水) 01:35:31
>>272
中身がただの関数ポインタになってて、ポインタのムーブはただのコピーが最善手
ってことじゃないかな?

276 :デフォルトの名無しさん:2010/10/27(水) 06:41:36
というか、std::moveは、単にrvalueリファレンスにキャストするだけだ。
std::move(t)と書くのは、static_cast<T &&>(t)と書くのと同じだ。
別にムーブと同等の処理は、非constなlvalueリファレンスを引数に取る関数でもできる。
単に所有権の移動と考えろ。

クラスのオブジェクト自体が魔法のようになくなったりはしない。

277 :デフォルトの名無しさん:2010/10/27(水) 09:17:19
右辺値参照を受け取る側は元の値を「気兼ねなく破壊できる」ってだけで
破壊する義務はないってことか。

278 :デフォルトの名無しさん:2010/10/27(水) 09:44:10
rvalueリファレンスは、あくまでただの「リファレンス」だからな。
rvalues(xvalueとprvalue)で初期化しなければならないこと以外は、lvalueリファレンスと何ら変わらない。
もちろん、rvalueリファレンスの変数自体を評価するとlvalueだ。

int && ref = 0 ;// OK、0はprvalue
int && aho = rref ; // エラー、rrefはlvalue

279 :デフォルトの名無しさん:2010/10/27(水) 18:10:59
>>278
rvalueリファレンスの変数を評価したらxvalueじゃないの?

280 :デフォルトの名無しさん:2010/10/27(水) 18:14:08
Non

281 :デフォルトの名無しさん:2010/10/27(水) 19:01:24
>>253
そのラムダ式の()は不要だよね。
ネットで見かけるコードだと、相当な上級者の書いたコードでも()が
ついてるけど、なんでみんな書きたがるのか。
でもさすがに某標準化委員は書いてなかった。

282 :デフォルトの名無しさん:2010/10/27(水) 19:03:24
規格を読まず他人のコードを読むから

283 :デフォルトの名無しさん:2010/10/27(水) 19:06:16
別に書いちゃいかんというルールもないし。

284 :デフォルトの名無しさん:2010/10/27(水) 19:25:30
省略するのはなんか気持ち悪いじゃん
慣れの問題だろうけど

285 :デフォルトの名無しさん:2010/10/27(水) 19:46:57
引数有る無しで書き方を変えるのが変わるのが嫌、とか

286 :デフォルトの名無しさん:2010/10/27(水) 19:48:43
ラムダの時に()を省略できるなら、普通の関数宣言でも()を省略できてもいいじゃない

287 :デフォルトの名無しさん:2010/10/27(水) 20:33:52
こうなのか?
std::function<void()> f1 = [&]{ std::cout << "1" << std::endl; };

やっぱり括弧つけようよ

288 :デフォルトの名無しさん:2010/10/27(水) 20:48:04
#include <iostream>
いやいやこれで十分でしょう。

int main()
{
[]{ std::cout << "1" << std::endl; }();
return 0;
}

なるほど、ファンクタクラスを作るシンタックスシュガーなんだなあ。

289 :288:2010/10/27(水) 20:49:04
しまった。行が入れ替わったw

290 :デフォルトの名無しさん:2010/10/27(水) 21:05:45
#include <iostream>
//いやいやこれで十分でしょう。

int main()
{
[]{ std::cout << "1" << std::endl; }();
return 0;
}

291 :デフォルトの名無しさん:2010/10/27(水) 21:11:48
#include <iostream>
//つまりこれと等価ということか

struct x {
void operator()() { std::cout << "1" << std::endl; }
};

int main() {
x()();
return 0;
}

292 :デフォルトの名無しさん:2010/10/27(水) 21:23:59
Delphi/C#のpropertyみたいなものは導入されないんですか?

293 :デフォルトの名無しさん:2010/10/27(水) 21:27:34
知らずに0x使うと爆死するようなトラップ要素って右辺値参照さんのほかになんか有りますか?

294 :デフォルトの名無しさん:2010/10/27(水) 21:33:20
>>292
Javaには入る。
C++はもっとprimitiveな機構に分解できれば入ると思う。

295 :デフォルトの名無しさん:2010/10/27(水) 21:39:49
>>292
n1615みたいなのは(作れば)あるけど規格には入らないだろうね

296 :デフォルトの名無しさん: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();
}
}

297 :デフォルトの名無しさん:2010/10/27(水) 21:54:01
そう言えばVCに__declspec(property)ってあったよな。

298 :デフォルトの名無しさん: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が出力されたのですが

299 :デフォルトの名無しさん:2010/10/28(木) 16:02:10
インスタンスという認識でいいと思うよ

300 :デフォルトの名無しさん:2010/10/28(木) 16:04:58
参照でもinfinite extentなら問題ない。
どうせimmutableなんだから。

301 :デフォルトの名無しさん:2010/10/28(木) 16:10:42
ありがとうございます
std::function,queueと組み合わせてタスクキュー的なものを作りたくて

関数が変数みたいに使えるって便利ですね

302 :デフォルトの名無しさん:2010/10/28(木) 16:17:32
>>298
何もキャプチャーしてないが、typoか?

303 :デフォルトの名無しさん:2010/10/28(木) 17:33:02
>>302
何かをキャプチャしなければならないというルールはないよ

304 :デフォルトの名無しさん:2010/10/28(木) 18:03:58
typoを修正してくれるライブラリ。Boost.Typoみたいな感じで誰か作ってくれないかな

305 :デフォルトの名無しさん:2010/10/28(木) 18:41:57
なにもかもがBoost.Typoの意図通りに捻じ曲げられそう…

306 :デフォルトの名無しさん:2010/10/28(木) 21:23:21
main
{

307 :デフォルトの名無しさん:2010/10/28(木) 21:24:14
あとはboost::typoにお任せるぜ

308 :デフォルトの名無しさん:2010/10/29(金) 01:05:17
>>293
右辺値参照がどうやって「爆死するようなトラップ要素」になるの?

309 :デフォルトの名無しさん: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されてまずくない?

310 :デフォルトの名無しさん:2010/10/29(金) 01:17:45
>>309
そんなわけで暗黙のムーブコンストラクタは無しになったのさ。 >>126 参照。

ちなみにそのクラス定義だと現行の C++ でも代入で死ぬよ。

311 :デフォルトの名無しさん:2010/10/29(金) 08:39:40
まだなくなると決まったわけじゃない。
特に、禿がひいきにしているからな。
禿によると、そもそも暗黙のコピーも、ユーザー定義デストラクターがあった場合、
暗黙に生成されないべきなんだとさ。

312 :デフォルトの名無しさん:2010/10/29(金) 09:43:48
まあ=defaultで明示的にってのは悪くない考えだけど、いまさらなあ…

313 :デフォルトの名無しさん:2010/10/29(金) 12:23:29
しかし今までのコードと互換性が無くなったらストレスで俺たちがハゲになっちまう

314 :デフォルトの名無しさん:2010/10/29(金) 12:46:22
もういっそC++++作れよ

315 :デフォルトの名無しさん:2010/10/29(金) 12:46:55
本物の C++ 使いはハゲを恐れない。

316 :デフォルトの名無しさん:2010/10/29(金) 17:22:33
というかもう殆ど禿げてる
まだ20なかばなのに

317 :デフォルトの名無しさん:2010/10/29(金) 17:42:17
>>316
いつ新しい言語を設計するんですか?
C++と同等に使えて、evalも用意されている言語をお願いします。

318 :デフォルトの名無しさん:2010/10/29(金) 18:37:26
>>317
evalはちょっと欠陥品だろう。
頼むからもうちょっとまともな仕様の言語が欲しい。


319 :デフォルトの名無しさん:2010/10/29(金) 18:56:45
まあC++1xでconcept入ってしばらくしたら、
その辺の成果を全部生かした言語も作られるんじゃないでしょうか。

320 :デフォルトの名無しさん:2010/10/29(金) 19:27:58
いい加減新しい言語作って若いもんに覚えさせたほうが人類のためになるよね
人類はいつまでC系列にしがみつく気なんだろう

321 :デフォルトの名無しさん:2010/10/29(金) 19:32:42
プリプロセッサまわりが汚すぎて、既存のライブラリを確実に移植する方法が
手作業以外に無いんだから仕方ない。
OSのAPIから新言語で提供されていれば話は違うんだろうけど、それも既にModulaが通った道だ。

322 :デフォルトの名無しさん:2010/10/29(金) 20:24:03
>>320
だからお前がまず代替案を出せよ

C++0xのラムダ式も誰も代替案を出さないからあの汚い形のままなんだぞ

323 :デフォルトの名無しさん:2010/10/29(金) 20:26:09
functionとかキーワード化したいよなぁ。
というか、将来のために基本的な英単語を予約しておかなかったのが、そもそもの間違いだった。

324 :デフォルトの名無しさん:2010/10/29(金) 20:27:49
functionって毎回書くの長ったらしくないか?

325 :デフォルトの名無しさん:2010/10/29(金) 20:31:17
>>320
事情はx86CPUと似ていると思うよ
アーキテクチャがいかに汚くなろうと、過去の財産を大事にすると生き残る

326 :デフォルトの名無しさん:2010/10/29(金) 21:00:41
互換性を窓から投げ捨てろ
つうか生き残らなくていいからどんどん新しい物を作って破って捨てろ


327 :デフォルトの名無しさん:2010/10/29(金) 21:12:09
お前がこのスレに要らん

328 :デフォルトの名無しさん:2010/10/29(金) 21:22:46
>>309
デフォルトコピーコンストラクターが使えないクラスにデフォルトムーブコピーコンストラクタを望むのが間違ってるよ。
デフォルトコピーコンストラクタが可能なクラスなら、おそらくデフォルトムーブコンストラクタが可能じゃないか?こいつらはセットだよ
コピーコンストラクタもムーブコンストラクタも定義されていないクラスのみデフォルトコピーコンストラクタとデフォルトムーブコンストラクタを許可すればすむと思うが、どうか?

329 :デフォルトの名無しさん:2010/10/29(金) 21:25:30
>>324
typedef function<int(int,int,int)> func_type;してから使うから気にしない。


330 :デフォルトの名無しさん:2010/10/29(金) 21:26:36
>>326
互換性を捨てるならC++である必要はなく、DでもEでもFでも作ればいいんじゃね?


331 :デフォルトの名無しさん:2010/10/29(金) 22:00:22
最近の新言語ってJavaもどきとLLと関数型ばっかりでつまらん
結局代わりになる言語を誰も作ろうとしないのよね

332 :デフォルトの名無しさん:2010/10/29(金) 22:37:42
>>331
> 結局代わりになる言語を誰も作ろうとしないのよね
頭おかしいのww
作ろうとした人ならめっちゃくちゃ居るよ。

成功した人がいないだけだ。


333 :デフォルトの名無しさん:2010/10/29(金) 22:55:40
つくろうとしても既存のコミュニティが受け入れずに潰されるからね

334 :デフォルトの名無しさん: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;
}
}





335 :デフォルトの名無しさん:2010/10/29(金) 23:50:01
C++は変態言語だから生き延びたのよ

336 :デフォルトの名無しさん:2010/10/29(金) 23:59:29
>>333
それは単なる被害妄想。


337 :デフォルトの名無しさん:2010/10/30(土) 01:39:14
>>323
逆じゃないかなぁ。
ユーザーコードで基本的な英単語が変な心配しないで使えるように、
キーワードこそ多少不自然な省略なりしたものを使ったほうがいいんじゃ
ないか?

338 :デフォルトの名無しさん:2010/10/30(土) 02:17:36
成功が広く使われることならば、
最近成功したのはLLとObjective-Cだけでしょ。
俺はOmegaや<it>G</it>なんかも面白かったけど。

339 :デフォルトの名無しさん:2010/10/30(土) 03:05:23
>Objective-C
え?

340 :デフォルトの名無しさん:2010/10/30(土) 03:46:08
糊インタプリタも軽量言語もC/C++もアセンブラも混ぜこぜで1ソースで書けて且つ一緒クタにコンパイル/リンクが行えて且つ構文エラーやら警告も一緒クタに吐いてくれる環境の標準化シテ欲しいね

341 :デフォルトの名無しさん:2010/10/30(土) 07:05:07
>>340
つD

342 :デフォルトの名無しさん:2010/10/30(土) 10:47:05
Obj-Cって別に最近出来た訳じゃないだろ

今最もホットな言語なのは間違いないが

343 :デフォルトの名無しさん:2010/10/30(土) 12:41:09
禿がポックリ逝ったらC++0xはどうなるんだよ?




いや、それでもいいか

344 :デフォルトの名無しさん:2010/10/30(土) 13:06:03
別な誰かが禿げる。

345 :デフォルトの名無しさん:2010/10/30(土) 13:09:08
画像をウィンドウの前に表示するためにはどうすればいいですか?

346 :デフォルトの名無しさん:2010/10/30(土) 13:15:27
そのウィンドウの前に画像を表示するウィンドウを出してください

347 :デフォルトの名無しさん:2010/10/30(土) 13:47:30
禿げが死んでもC++は生き残るさ
2chはひろゆきが死んだら終わりなんだっけ?

348 :デフォルトの名無しさん:2010/10/30(土) 14:06:06
2chはもうどっかの外資が支配してるからひろゆきは関係ないよ

349 :デフォルトの名無しさん:2010/10/30(土) 15:28:40
>>347
むしろ禿げが死んだらC++は衰退し、
2chはひろゆきの手を離れてもこうして続いている。


350 :デフォルトの名無しさん:2010/10/30(土) 20:24:42
C++は滅びぬ、何度でも蘇るさ
C++の力こそ人類の夢だからだ

351 :デフォルトの名無しさん:2010/10/30(土) 21:00:03
C++は糞言語かもしれないが、あまりに多大な時間と労力を掛け過ぎ、
しかも関わった人が多すぎた
今更白紙に戻す事はできないってのが実情でしょう

352 :デフォルトの名無しさん:2010/10/30(土) 21:43:06
>>351 世の中には「語ってはいけない真実」ってのがあるってしってるか?


353 :デフォルトの名無しさん:2010/10/30(土) 23:36:46
禿げはA級戦犯ってことか

354 :デフォルトの名無しさん:2010/10/30(土) 23:58:09
EXEやDLL、a.out、soのサイズがCに比べて格段に大きくなる傾向があるので
DLLとsoは必須だな

但しx86はコールゲートを通すと滅茶遅くなるんだよなあ
そこは我慢か

355 :デフォルトの名無しさん:2010/10/31(日) 00:52:49
>>351
お前がNo.1だ

356 :デフォルトの名無しさん:2010/10/31(日) 00:59:08
C++がこのまま肥大化する一方で、PL/Iの悲劇を繰り返さなければいいのだが
まあパソコンのスペックが上がってHDDもテラバイト時代なので、多少大きくても
楽々入ってしまうけどな

357 :デフォルトの名無しさん:2010/10/31(日) 01:57:57
こういう問題のある基盤に大量のものが乗っかった状況を改善する一般的手法ってないの
結構そういう状況って他にも溢れてると思うんだけど

358 :デフォルトの名無しさん:2010/10/31(日) 02:36:33
>>357
あるとしたらC99とかD言語だけど、知っての通り単なるマニア向け言語に
なってしまっただろ?

Cがあれだけ広く使われてしまったらもう引き返せないんだと思うよ
Cの上に乗っているC++もC++0xも結局同じ道を半ば強制的に辿らされる

他のLL言語は遅くて使い物にならないしな

C#も糞だって分かってしまったし
ただC#やJavaは開発コストと時間を大幅に削減出来るので、一度立ち上げて
しまえば滅多にシャットダウンしない、速度もそんなにカリカリ必要ないデータベース
にはこれからも使われていくだろう

359 :デフォルトの名無しさん: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でもそんな話は一切でてないけどな……。

360 :デフォルトの名無しさん:2010/10/31(日) 08:04:32
>>359
> 今でも関数ポインタではなくて関数型そのものをtypedefしてる糞.hが山ほどある。

むしろなんで関数型を typedef せずにポインタまでつけた typedef しか提供しないんだ糞が、
それじゃ関数宣言の照合にも使えないし function にも使えないだろうが糞が、とか思うんだけど、
なんでポインタで typedef しないと糞なの?

361 :デフォルトの名無しさん: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

362 :デフォルトの名無しさん:2010/10/31(日) 08:34:27
>>360
値として使えない型を導入してしまうから。
いやもちろん、今のsyntaxだとパーサレベルでは関数型を扱わないといけないんだけど。

>>361
-Werrorで充分じゃ……。

363 :デフォルトの名無しさん:2010/10/31(日) 09:06:46
>>361
実際問題暗黙のintはかなり減った、というよりほぼ全く見なくなったでしょ。
C99というよりC++の功績とは思うけど。

364 :デフォルトの名無しさん:2010/10/31(日) 09:17:38
>>362
値として使えない型を導入されると、糞というほど困るの?なんで?

365 :デフォルトの名無しさん:2010/10/31(日) 09:33:00
>>362
不完全型の typedef なんぞ腐るほどあるなあ

>>363
long long

366 :デフォルトの名無しさん:2010/10/31(日) 09:33:47
>>364
とりあえず現状のCには関数宣言の照合やfunctionの類の機能が全くないので
あってもまるで嬉しくないのに、sizeofその他の例外をvoid以外に増やしてしまう。
(voidの値もダミー値として扱いたいと思ってるクチ、
ついでにvoidをunitに改名して"void"は正しくnoreturnの意味にならないかね)

C++で必要だから導入して、Cがそれを互換性のために追認というならまだしも
現状本当に何の意味もなくただコンパイラが通すからってだけで関数型がtypedefされてるのは
普通に関数ポインタと思って使ったらエラーになったりする……糞が、って思うぐらいで
全く利点がないだろ。

367 :デフォルトの名無しさん:2010/10/31(日) 09:38:36
>>366
関数宣言の照合がない C って K&R C か?
a();
void a(void) { } /* error */

368 :デフォルトの名無しさん:2010/10/31(日) 09:42:47
>>366
> とりあえず現状のCには関数宣言の照合やfunctionの類の機能が全くないので
×全くない
○全く知らない

typedef int f_type(int);

f_type f;
void f(int); // error

369 :デフォルトの名無しさん:2010/10/31(日) 09:45:35
>>368
想像図を書くなら
typedef int f_type(int a);
f_type f { return a; }
だろ

関数定義に「突然」出てくる a は型情報ではないので
確かに気持ち悪い

370 :デフォルトの名無しさん:2010/10/31(日) 09:45:43
>>366
> 普通に関数ポインタと思って使ったらエラーになったりする……糞が、って思うぐらいで

ただの思い込みで逆切れとか、ひどいな。

↓どっちが関数ポインタに見えるかって、見りゃわかるだろうに。
Function p;
Function* p;

371 :デフォルトの名無しさん: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の話なんだから。

372 :デフォルトの名無しさん:2010/10/31(日) 09:53:58
>>371
それを実際にやるのが >>368 なわけだが。

373 :デフォルトの名無しさん:2010/10/31(日) 09:54:48
って、今試してみたら>>368って通るんだな。これは知らなかった。
これについては俺の間違いだ。ごめん。

374 :デフォルトの名無しさん:2010/10/31(日) 09:56:16
>>371
static_assert(typeid(a) == typeid(f));
という話ならわからんでもないが
operator が出てくるのは何?

375 :デフォルトの名無しさん:2010/10/31(日) 09:59:09
>>374
関数にキャストできるtemplateで何かできそうだと思って書きかけてやめたんだが消し忘れたようだ。無視してくれ。

376 :デフォルトの名無しさん:2010/10/31(日) 10:11:43
>>375
それは構文上はOKで、意味でNGという(であるべき)話じゃないか?
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

377 :デフォルトの名無しさん:2010/10/31(日) 10:18:04
そうですね

378 :デフォルトの名無しさん:2010/10/31(日) 10:39:32
>>368
それプロトタイプ宣言ではできるけど
関数定義の方では使えないんだよな(できたとしても引数名も分からないし)
プロトタイプ宣言と関数定義の表記が揃ってないと読み辛いし
結局役に立たない

379 :デフォルトの名無しさん:2010/10/31(日) 10:43:19
>>361
Cコードの書き換えが進まないのは
単にコンパイラベンダがC99に対応しないからだな

380 :デフォルトの名無しさん:2010/10/31(日) 10:53:30
>>310
= default でデフォルトのムーブコンストラクタを作る事もできないのかな?

381 :デフォルトの名無しさん:2010/10/31(日) 11:22:02
コンパイルオプションでバージョン指定できるようにすればええやん
互換性なんて気にすることあらへんのや

382 :デフォルトの名無しさん:2010/10/31(日) 11:27:44
そこで#pragmaですよ

383 :デフォルトの名無しさん:2010/10/31(日) 11:28:26
>>381 それだと古いライブラリコードを新しいコードから使いたいときに困る。

384 :デフォルトの名無しさん:2010/10/31(日) 19:22:57
メジャーどころでC99に非対応なのは MSVC だけかと思ってたけど違うのか

385 :デフォルトの名無しさん:2010/10/31(日) 19:33:28
C99って可変長配列が使えるらしいけど、開放のタイミングが謎だよな。
むしろ、可変長配列があったらCとは呼べないんじゃないか?


386 :デフォルトの名無しさん:2010/10/31(日) 19:45:18
C99の可変長配列はalloca()のシンタックスシュガーだよ

387 :デフォルトの名無しさん:2010/10/31(日) 19:47:04
C++コンパイラはC++0x対応で精一杯だろうからC99の対応には消極的だろう。
Cコンパイラはコストを掛けてまで対応してもメリットはないだろうし


388 :デフォルトの名無しさん:2010/10/31(日) 20:00:00
>>384
それが致命的すぎ

389 :デフォルトの名無しさん:2010/10/31(日) 20:16:13
>>385
謎とか、規格にちゃんと書いてあるだろ

390 :デフォルトの名無しさん:2010/10/31(日) 20:18:06
>>389
C99ってstructに可変長配列宣言してmallocしても機能するの?

391 :デフォルトの名無しさん:2010/10/31(日) 20:28:32
そんなもんは宣言できない

392 :デフォルトの名無しさん:2010/10/31(日) 20:33:03
寝言は寝て言え

393 :デフォルトの名無しさん:2010/10/31(日) 20:53:15
過去の遺産を使えるけど、でもまともな綺麗な言語仕様を持つ言語、
俺には到底つくれないので、誰か天才さん作ってください!!


394 :デフォルトの名無しさん:2010/10/31(日) 21:03:55
可変長配列ってlongjmpですっ飛ばしたら解放されない可能性があるとか読んだ覚えがある

395 :デフォルトの名無しさん:2010/10/31(日) 21:05:39
可変長って訳語が悪いなあ。
動的に初期サイズ決定するってだけで、
後からサイズを変えられるわけじゃない。

396 :デフォルトの名無しさん:2010/10/31(日) 21:23:49
これが可能になるって事?
int n=10;
int array[n];

微妙な拡張よりも拡張子cppに変えてvector使ったほうがメリットあるだろうね。


397 :デフォルトの名無しさん:2010/10/31(日) 21:28:44
>>354
stl とか boost 入ると shared library つかっても object サイズはしゃれにならん
strip 後の size みて, "何, これ?" 状態

おまえら使うのやめろや, template !!!

# でも, 俺は使うけどなw


398 :デフォルトの名無しさん:2010/10/31(日) 21:50:17
>>394
確か最初はC++はCへのトランスレータの形で実現されていたけど、例外処理を
取り込んだ時点でどうしてもC++のネイティブコンパイラが必要になったそうだな

longjmp()とsetjmp()だけだと例外処理を実現出来ないんだと

399 :デフォルトの名無しさん:2010/10/31(日) 21:57:19
かなーり近いもん書けてるけどねー
むしろキツかったのはマングリングとテンプレート方面だろ

400 :デフォルトの名無しさん:2010/10/31(日) 22:23:42
テンプレートは例外処理の後で出て来たしな
もうすっかりネイティブ一色になった後だった

ARMには並べて書いてあるけど

401 :デフォルトの名無しさん:2010/10/31(日) 22:27:51
>>399
try/chatch のセマンティクスからだと, longjmp は戻り先が固定なので,
使えないんだよ.
いまでも, 例外はオーバーヘッドでかいけど, コンパイラ/実行コードともに,
使い物にならないくらいのオーバーヘッドがあったらしい.


402 :デフォルトの名無しさん:2010/10/31(日) 22:31:05
throw; とか実現できないしな

403 :デフォルトの名無しさん:2010/10/31(日) 22:33:44
>>402 throw も setjmp したところの dictionary 作って実現してたっぽいけどな


404 :402:2010/10/31(日) 22:38:47
補足:
C++ よりずっと前に kcl(lisp->c のトランスレータ的実装) が lisp の
例外を実装してたんだから, lisp 例外の劣化コピーの C++ の例外が
実装できないはずはないし, ちゃんと考えて実装すれば
拡張 setjmp/longjmp で何とかなったとは思われる.


405 :デフォルトの名無しさん:2010/10/31(日) 22:59:33
>>401
戻り先が固定?? もしかして jmp_buf をグローバルにしてるのか???
throw; が実現できないとか噴飯ものだ

406 :402:2010/10/31(日) 23:12:31
>>405
一つの setjmp に一つの longjmp が対応している
単純に考えれば, longjmp から戻ったときに再度 dispatch
素朴な実装だと try/catch のように積極的に使うと, dispatch table (が|で)あふれる


407 :デフォルトの名無しさん:2010/10/31(日) 23:22:13
>>401
例外はオーバーヘッドでかいって、何のこと言ってるの?

例外が実際に投げられない限り実行時間のオーバーヘッドは
ほぼゼロになる実装がすでに主流になってると思うんだけど。

408 :デフォルトの名無しさん:2010/10/31(日) 23:24:44
投げた時の話だろ

409 :デフォルトの名無しさん:2010/10/31(日) 23:28:52
>>406
ド素人ですが
ごく単純に考えれば、単なるjmp_bufのスタックでよくないですか?
tryブロック毎にpush、ブロック出たらpop
throwはスタックトップにlongjmp
スタックはスレッド毎に必要でしょうけど

410 :デフォルトの名無しさん:2010/10/31(日) 23:40:25
それSjLj

411 :デフォルトの名無しさん:2010/10/31(日) 23:54:37
>>409
Cならそれでスタック巻き戻せるからいいけど、C++はデストラクタ呼ばなくちゃならないのがめんどくさいところ

412 :デフォルトの名無しさん:2010/10/31(日) 23:55:43
>>411
そこは承知していますが、出来る出来ないで言えば、この方針で出来るでしょう

上でlongjmpの飛び先が一つなので出来ないという議論をしている意味が
全く理解できなかったものですから


413 :デフォルトの名無しさん:2010/11/01(月) 00:03:09
tryブロックのたびにpush、popは結構なオーバーヘッドになるのです。
実際、昔のC++はそのような方法をとっていたようですが、いまは別の方法のようです。

414 :デフォルトの名無しさん:2010/11/01(月) 00:06:48
細かい話なのでいちいち書きませんでしたが、
デストラクタ呼び出しが必要な全ての箇所をtry{}finally{}で仮想的に
囲み、デストラクタ呼び出しコードをfinally{}ブロックに埋め込めば
実現可能と考えます(C++にfinallyはありませんが、通じると思います)

さらに自明と思って書きませんでしたが、例外をハンドルしない場合の
リレーは、次のトップにlongjmpするだけです

素人考えなので素朴極まりないのですが、可能不可能で言えば
実現は十分可能に見えます

415 :デフォルトの名無しさん:2010/11/01(月) 00:06:55
push みたいな write サイクルを含む命令を jmp_buf の宣言だけで使うかよ
setjmp は必要な範囲だけに限定できるし、そもそも「オーバーヘッド」って何のことだよ

416 :デフォルトの名無しさん:2010/11/01(月) 00:13:50
>>412
longjmpのアドレスの保存先ってstrtokのポインタの保存先と同じで、ライブラリ内に
一つしかないんじゃないの?

417 :デフォルトの名無しさん:2010/11/01(月) 00:16:18
>>416
そんなことはありません
jmp_bufについて調べてください

418 :デフォルトの名無しさん:2010/11/01(月) 00:16:35
>>416
てめーで少しでいいから使ってみろタコ

419 :デフォルトの名無しさん:2010/11/01(月) 00:19:15
いまさらlongjmpなんか使わないでしょう

420 :デフォルトの名無しさん:2010/11/01(月) 00:23:18
>>419
使ってからいいな

421 :デフォルトの名無しさん:2010/11/01(月) 00:26:57
longjmpと例外の実装方法の違いを論ずるならともかく、なんでそんなにlongjmpに御執心なの?

422 :デフォルトの名無しさん:2010/11/01(月) 00:31:29
>>421
自分への質問でしたら、>>398あたりの流れ

> longjmp()とsetjmp()だけだと例外処理を実現出来ないんだと

これについて疑問を持ったから意見を述べたまでで、
別にlongjmp()自体はどうでもいいです

423 :デフォルトの名無しさん:2010/11/01(月) 11:26:01
>>414
君の考えで間違いない。

大体今でもフロントエンド形式のコンパイラはあるし。
アセンブリも使っているとはいえ。

424 :デフォルトの名無しさん:2010/11/01(月) 18:36:48
今だと表引き法なのかな?

425 :デフォルトの名無しさん:2010/11/01(月) 19:25:11
gccでもconfigure時に--enable-sjlj-exceptions付けたら今でもlongjmpじゃね?

426 :デフォルトの名無しさん:2010/11/01(月) 21:28:59
C++だとlongjmpは使用禁止だけどな

427 :デフォルトの名無しさん:2010/11/01(月) 21:34:39
そりゃ、明示的にユーザーコードでlongjmp使ったら、デストラクタ飛ばしちゃうだろ。
コンパイラが裏で例外の実装としてlongjmpを使う分にはなんの問題もない。

428 :デフォルトの名無しさん:2010/11/01(月) 21:49:31
区別出来ないアホはほっとけ

429 :デフォルトの名無しさん:2010/11/01(月) 21:53:30
http://codepad.org/PtHh60zX
VC++だとデストラクタが実行されるのに、g++だと飛ばされるんだ。知らんかった。

430 :デフォルトの名無しさん:2010/11/01(月) 21:55:12
C++でlongjmp使うなyo

431 :デフォルトの名無しさん:2010/11/01(月) 21:55:28
何でそんなこともしらないやつがC++0xスレいるの?
>>398とか。背伸びしすぎw

432 :デフォルトの名無しさん:2010/11/01(月) 22:00:37
>>429
WindowsのSEHはスタック上でリンクリストを作ってるから、動的に辿るのも簡単だしね。
g++はデフォルトZCXの上にlongjmpにも切り替え可だから両対応は難しい(んだと思う)。不可能ではないだろうけど。

433 :デフォルトの名無しさん:2010/11/01(月) 22:03:10
ああそうか、WindowsはOS自体が構造化例外機構を持ってるんだった。

434 :デフォルトの名無しさん:2010/11/01(月) 22:15:10
一概に使うなとか言ってる奴は論外
委細をわかっていて使う使わないを選択する人用の言語だかんな

435 :デフォルトの名無しさん:2010/11/01(月) 22:26:20
>>425
今でもlongjmp()なんだ
SjLjはthrowされたらpersonalityとlongjmp()する場所を記録したリストを型判定しながらたどって
何とかとかいう構造体でcatchできる型と判定したらsetjmp()した所に帰るとかだったような
随分前に本で読んだ記憶あるがほとんど覚えてないw

436 :デフォルトの名無しさん:2010/11/01(月) 22:29:02
>>435
流石にlongjmpそのものではなくて、unwind.hで定義された関数使うけどな。
その中がlongjmpか同等の何かまでは知らん。
personalityは、ハンドラが受け取る例外の種類を判定するための関数だね。

437 :デフォルトの名無しさん:2010/11/01(月) 22:43:27
>>435
> 今でもlongjmp()なんだ

今でもも糞も「SjLj」なんだよ!
使わないならLjじゃねえ!

438 :デフォルトの名無しさん:2010/11/01(月) 23:19:05
setjmpとlongjmpの関係をnear/farポインタ的なものだと思ってた時期もありました…

ペアで使うような名前には見えないよねこれら

439 :デフォルトの名無しさん:2010/11/01(月) 23:27:30
longjmp を使うのに #include <csetjmp> が必要でもか?

440 :デフォルトの名無しさん:2010/11/01(月) 23:28:01
何言ってんだこいつ

441 :デフォルトの名無しさん:2010/11/01(月) 23:29:45
わからないならレスしないで下さい
ウザいだけです

442 :デフォルトの名無しさん:2010/11/01(月) 23:35:11
>>438は単に、なんでgetjmpじゃないんだと言いたいだけだろう。
あと同一ヘッダーに関係ない関数が収録されてる例なんて山ほどあるので>>439も言いたいことはわかるがやや変。

実際名前の対応は取れてないしな。set_longjmpとexecute_longjmpとかならどうだろう。

443 :デフォルトの名無しさん:2010/11/01(月) 23:35:57
>>441
わからないならレスしないで下さい
ウザいだけです


444 :デフォルトの名無しさん:2010/11/01(月) 23:57:42
>>442
ラベルと goto が1:nの関係なのは考えるまでもないことで
ロクに使いもせずに毛嫌いしたばかりに setjmp と longjmp の関係を誤解した間抜けが
藁にもすがる思いで識別名のせいにしただけだろ

445 :デフォルトの名無しさん:2010/11/02(火) 00:05:02
なるほどC++0xの話題ですねw

446 :デフォルトの名無しさん:2010/11/02(火) 00:06:56
言語の基本
ここがわかんないまま議論しても砂上の楼閣だ

447 :デフォルトの名無しさん:2010/11/02(火) 00:09:25
>>437
言われてみればw
本当にすみませんでした

448 :デフォルトの名無しさん:2010/11/02(火) 00:33:52
>>444
まあいくら御託を並べても名前がクソってことに変わりはないけどなw

449 :デフォルトの名無しさん:2010/11/02(火) 21:23:09
それよりも禿げは・・・

450 :デフォルトの名無しさん:2010/11/03(水) 08:50:13
さーって、右辺値参照を勉強するか。




ううーーむ、わからん

451 :デフォルトの名無しさん:2010/11/03(水) 09:19:19
いつものように0xと関係ない話題になると伸びが早いな

452 :デフォルトの名無しさん:2010/11/03(水) 11:09:36
VC10使ってる人とか少ないのかな?lambdaとか右辺値参照とかかなり有益なものが入ってるのに


453 :デフォルトの名無しさん:2010/11/03(水) 11:32:37
まだ仕様変わってるし、あまり触りたくない
VC6の悪夢が・・・

454 :デフォルトの名無しさん: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"
}

これだけのことではないか。

455 :デフォルトの名無しさん:2010/11/03(水) 13:09:10
VCというかWindowsがない
俺なんでこのスレ見てるんだろ

456 :デフォルトの名無しさん: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));
}

457 :デフォルトの名無しさん:2010/11/03(水) 13:32:22
どっちもあってる

458 :デフォルトの名無しさん:2010/11/03(水) 13:40:44
これに
void fanku(int)が加わればどうなるの?

459 :デフォルトの名無しさん: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()&&; };
の違いがわかるはず。


460 :デフォルトの名無しさん:2010/11/03(水) 14:33:46
いや、この程度のことならいいけど。
ところで、int(a)は型キャストだと思うが、これも右辺値?

constが絡んでくるとどうなの?
参照返しがなされたときは?
一時オブジェクトであってもそのオブジェクトを受けた関数側に
参照引数が使ってある場合、その関数内では左辺値になるよね?

こういうことがゴチャゴチャしていてC++は複雑なんだよ。

461 :デフォルトの名無しさん:2010/11/03(水) 14:45:58
static_cast(他)もtypenameのキャストも右辺値を返すよ。

462 :デフォルトの名無しさん:2010/11/03(水) 14:46:20
>ところで、int(a)は型キャストだと思うが、これも右辺値?
キャストは一時オブジェクトを作るので右辺値

>constが絡んでくるとどうなの?
constの右辺値参照引数は意味がない(壊せない右辺値なんて…)ので考えなくていい
const T& と (non-const)T&& でオーバーロードするのが基本

>参照返しがなされたときは?
戻り値の事なら戻り値の型どおり
左辺値参照なら左辺値、右辺値参照ならxvalue

>一時オブジェクトであってもそのオブジェクトを受けた関数側に
>参照引数が使ってある場合、その関数内では左辺値になるよね?
関数内ならそれも引数の型どおり
左辺値参照なら左辺値、右辺値参照ならxvalue

別にゴチャゴチャしてないと思うが
というか右辺値参照の評価が左辺値だったりした昔に比べればずいぶんスッキリした

463 :デフォルトの名無しさん:2010/11/03(水) 15:06:42
>>462

あんたはそう言うけどさ、一般の人間にはついていけんよ。
右辺値、左辺値なんて言葉は昔から使ってあったと言うけど
誤解を招くから使わない方が良いと思う。

(1) どういう場合に無名の一時オブジェクトが生成されるのか?
(2) 無名オブジェクトでも名前つきオブジェクトとして扱われる
ケースがあるが、それはどのようなケースか?

で箇条書きしてくれた方がまだまし。

みたいなもので
そのケースを箇条書きで示してくれた方がまだす。

そして一時オブジェクトであっても関数側の参照引数で受け取られた
ときは名前つきオブジェクトになってしまう
されたときには
で参照引数として

464 :デフォルトの名無しさん:2010/11/03(水) 15:08:09
↑ああ、ゴミ消すのを忘れた。


465 :デフォルトの名無しさん: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を受け取れる。

466 :デフォルトの名無しさん:2010/11/03(水) 15:57:14
質問する側の分際で横柄だな
別にいいけど

(2)はxvalueのことだから、右辺値参照型の変数が評価される時だけだな

(1)はめんどくさいな
・組み込みリテラル
・組み込み演算子の結果、ただし以下の左辺値を生ずる物は除く
 ・前置++、--
 ・単項*
 ・[]
 ・メンバの参照 . .* -> ->*
 ・=および+=の類
・関数(オーバーロード演算子とユーザー定義リテラルを含む)の戻り値、ただし左辺値参照型を返す場合を除く
・キャストおよびコンストラクタ呼び出し、ただし左辺値参照型への変換を除く

きっと何か忘れてる

467 :465:2010/11/03(水) 16:04:35
何を言いたかったかというと、

> (2) 無名オブジェクトでも名前つきオブジェクトとして扱われる
> ケースがあるが、それはどのようなケースか?

こういう疑問が生じるのは多分
「右辺値は無名だけど右辺値参照は名前付きで…???」
みたいに用語の混乱を生じているからであって

「prvalue か xvalue は rvalue reference で受け取ることができて、
rvalue reference で宣言された変数は lvalue だ」

と言えば混乱はない。


468 :デフォルトの名無しさん:2010/11/03(水) 16:17:03
>rvalue reference で宣言された変数は lvalue だ
xvalueじゃないの?

469 :デフォルトの名無しさん:2010/11/03(水) 16:17:18
xvalueってstd::moveで生成する以外だとどんなのがあるの?

470 :デフォルトの名無しさん:2010/11/03(水) 16:18:39
あ、右辺値参照の引数もか

471 :デフォルトの名無しさん:2010/11/03(水) 16:27:00
>>468
5章の第6段落に書いてあるけど、
名前付き&&参照は lvalue。
関数の戻り値とか、名前のない&&参照は xvalue。

だからf(int&& a) の引数 a は lvalue。


472 :デフォルトの名無しさん:2010/11/03(水) 16:32:03
そうだったのか
じゃあこれって合法なの?

int &&x = 0;
x = 42;

なんだかなあ

473 :デフォルトの名無しさん:2010/11/03(水) 16:40:43
>>472
一時変数が作られてるから合法のようだね。
まあ、右辺値参照と明確に指示したんだからしかたなくね

474 :デフォルトの名無しさん:2010/11/03(水) 16:55:34
STLに右辺値参照使うのはいいんだけど、関数の種類が増えて実行ファイルが肥大しない?

475 :デフォルトの名無しさん:2010/11/03(水) 17:23:54
おお!何だこの難解なレスの伸びは。。。



みんな静かに見てるんだな、怖ひ

476 :デフォルトの名無しさん:2010/11/03(水) 17:28:09
そりゃ主要なコンパイラがじわじわと対応してきているからね

477 :デフォルトの名無しさん:2010/11/03(水) 18:01:03
>>474
インライン展開されるし、ムーブのコードのほうが小さいだろう。でなければ右辺値参照は使わない。

478 :デフォルトの名無しさん:2010/11/03(水) 22:40:07
>>462
> 関数内ならそれも引数の型どおり
> 左辺値参照なら左辺値、右辺値参照ならxvalue

右辺値参照引数には関数内なら名前がついてるんで、
lvalue になるんじゃないの?
move なりなんなりかまさないと xvalue にはならないと
思うんだけど。

479 :デフォルトの名無しさん:2010/11/03(水) 23:40:52
>>478
レスが入り乱れててわかりづらいけど
それはもう訂正済み


480 :デフォルトの名無しさん:2010/11/04(木) 00:32:03
ごめん分からなくなってきた
名前のない&&参照って例えばどんなの?

481 :デフォルトの名無しさん:2010/11/04(木) 01:06:35
>>480
T&& move()
↑こんなのとか。

static_cast<T&&>(t)
↑こんなのとか。

482 :デフォルトの名無しさん:2010/11/04(木) 08:21:17
現状、ムーブコンストラクタって明示的に書かないと駄目なんだっけ?

483 :デフォルトの名無しさん:2010/11/04(木) 11:26:20
このスレずっと見てきて、右辺値参照がようやくわかってきた。
みなさん、ありがとう。

特に、>>465 >>467 さんの明確な説明が参考になりました。

右辺値参照やmoveを説明した英文の和訳を読んでも(訳がまずいという
のではなく、オリジナルの英文自体の説明がわかりにくい)、
なかったが、このスレを拾い読みしたら



484 :デフォルトの名無しさん:2010/11/04(木) 13:59:14
コンセプトさん復活したの?

485 :デフォルトの名無しさん:2010/11/04(木) 19:23:25
>>482
現状Yes

486 :デフォルトの名無しさん:2010/11/04(木) 20:02:20
>>484
現状No


487 :デフォルトの名無しさん:2010/11/05(金) 16:02:03
じゃあコンセプトさん使えるコンパイラは0xではなく独自の仕様ということか・・・

488 :デフォルトの名無しさん:2010/11/05(金) 18:11:43
曲がりなりにもコンセプトさん使えるコンパイラって
今のところConceptGCCしかないだろ
開発中止だけど

489 :デフォルトの名無しさん:2010/11/05(金) 20:55:35
ConceptGCCが開発中止となり
もうこの世にまともなConceptを実装したコンパイラはありません。

Conceptさんの復活を祈る。
祈るだけで何が出来るわけではないが。


490 :デフォルトの名無しさん:2010/11/05(金) 22:55:07
右辺値参照とコンセプトは車の両輪みたいなもの
片方がないと、大変悲しい

// 次の3行分はよく理解できる
int a1 = 0;
int& a2 = a1;
int&& a3 = 0;

// 次の2行はどうなるんだろう?
int& a4 = a3;
int&& a4 = a2;

// もう訳分からん。。
int& a5 = a4;
int&& a6 = a5;
int& a7 = a6;

491 :デフォルトの名無しさん: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なのでエラー

492 :デフォルトの名無しさん:2010/11/05(金) 23:03:00
>>490
どこにコンセプトが関係するのさ

493 :デフォルトの名無しさん:2010/11/05(金) 23:17:00
>>491
a7はa4と同じだからOKじゃね?

494 :デフォルトの名無しさん:2010/11/05(金) 23:30:42
>>493
&を読み間違えた。

495 :デフォルトの名無しさん:2010/11/05(金) 23:35:42
必要なのはコンセプトよりも、変な記号を置き換えるわかりやすい予約語だよな……。

496 :デフォルトの名無しさん:2010/11/05(金) 23:41:56
>>491
>>492
右辺値参照とコンセプトが C++0x の
2本柱のように自分にとって見えたので

車の両輪は良くない比喩でした。すまん

>>491
エラーになる理由について詳しく教えてください。
N3126 から該当部分を指摘して貰えるとありがたいです。

以前GCCで試したら、エラーにならなかったような記憶が
あるのですが、皆さんの処理系ではどうですか?

497 :デフォルトの名無しさん:2010/11/05(金) 23:46:10
Conceptさん・・・。。。

498 :デフォルトの名無しさん:2010/11/05(金) 23:46:59
記憶違いだと思うぞ
VC++2010は正しくエラー

499 :デフォルトの名無しさん:2010/11/05(金) 23:53:55
ずっと、疑問に思っていたので、2つ質問。
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2027.html
にある2つ目のコード例:
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&&
とあるが、あらゆる参照の参照がエラーにならないことを前提にしている?

いずれも古い文書だから、現在のドラフトの内容と合わないのかもしれません

500 :デフォルトの名無しさん:2010/11/06(土) 00:18:12
古いね
右辺値参照をlvalueで初期化するのが禁止されたのは最近だったと思う

参照の参照のルールは今も生きてる
そのproposalにも書いてるけど、テンプレートで発生する事があるので取り決められた

template<class T> class Foo{ T &&x; };

Foo<int&> foo; //foo.xはint& &&だからint&

501 :デフォルトの名無しさん: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。


502 :デフォルトの名無しさん:2010/11/06(土) 02:29:08
Win32API質問箱からきました。
C++0xでは、basic_string のバッファの連続性が保証されるようになったわけですが、
現実問題として、わざわざ不連続バッファを使うような実装が存在するのでしょうか。

503 :デフォルトの名無しさん:2010/11/06(土) 03:03:12
>>502
その質問だと、存在しないことの証明はできない、としか言えないね。
ほんとうに聞きたいことはそんなことじゃないんだろうけど。

504 :デフォルトの名無しさん:2010/11/06(土) 03:11:59
vectorよりdequeのが性能良かったりするし

505 :デフォルトの名無しさん:2010/11/06(土) 03:33:05
dataとc_strが定数時間で行われる必要があるので
非連続な実装って不可能じゃね

506 :デフォルトの名無しさん:2010/11/06(土) 03:40:06
>>505 complexity の要件が追加されるのも C++0x から。

507 :デフォルトの名無しさん:2010/11/06(土) 08:19:06
>>502
文字列を+=するときに、バッファーを取り直して伸張するのではなく、新たにバッファを追加して複数のバッファーを使うのは
ありそうだけど、[ ]の効率を考えたら取り直すほうを選択するだろう。


508 :デフォルトの名無しさん:2010/11/06(土) 08:35:40
初めて取り出すまでは不連続にしたほうが効率的だよね

509 :デフォルトの名無しさん:2010/11/06(土) 09:29:25
確かにそうなんだけど、ここ最近、マルチスレッド化でそうとは限らなくなったね。
constメンバー関数で参照しようとしたときにでも文字列オブジェクトの内部が変化してしてしまう。
内部的にこっそり直してもいいんだけど、マルチスレッド下では再入の保護のためにmutexが必要になる。
過去の文字列クラスは、参照カウンタでバッファーを共有する実装もあったけど、マルチスレッド化で共有での実装も見かけなくなってきたね。


510 :デフォルトの名無しさん:2010/11/06(土) 11:15:01
basic_stringでないなら、不連続な実装としてropeがある

511 :デフォルトの名無しさん:2010/11/06(土) 11:35:13
>>500
>>501

よくわかりました。ありがとうございます

512 :デフォルトの名無しさん:2010/11/06(土) 15:11:16
>>502
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530

513 :デフォルトの名無しさん:2010/11/06(土) 17:01:15
pod class Hoge
{
public:
int x;
// NoPod nopod; error
};
void func(pod Hoge & hoge);
そろそろこの指定子が欲しい


514 :デフォルトの名無しさん: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);

が呼ばれてしまう。の理解でいいでしょうか?

515 :デフォルトの名無しさん:2010/11/06(土) 17:09:47
>>272
>つうか、おそらく単なる参照渡し。
>ムーブ後の抜け殻に触った結果はどうせ未定義なんだから、仕様は満たしてるよね。

抜け殻のオブジェクトでも消滅するときはデストラクタが呼ばれ、デストラクタ内
では delete p; みたいなものがあると思うのですが。

>>459
>関数への右辺値参照は、名前のあるなしにかかわらず lvalue になる。
「関数への右辺値参照」 の意味を解説していただけるとありがたいです。

>struct A { void hage(); void hige()&; void hoge()&&; };
hige()&; hoge()&& ってどういう意味でしょうか?

516 :デフォルトの名無しさん:2010/11/06(土) 17:27:02
>>513
static_assert(std::is_pod<Hoge>::value);

517 :デフォルトの名無しさん: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 をバインドしてる
みたいな呼び出しが可能。ヒゲは禿に似てるけど、そういう特別扱いされない。


518 :デフォルトの名無しさん:2010/11/06(土) 18:18:40
>>517
関数型の xvalue を言語要素として排除するためのルールじゃないかな?
これで少しは考えることが減るのかも。

519 :デフォルトの名無しさん: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はデストラクタが呼ばれても問題ないのも同じ。

こういう話でいいのかな。

520 :デフォルトの名無しさん: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 も単なる関数ポインタのコピーであって、
オブジェクトのムーブではないのではないか? という気がします。

521 :デフォルトの名無しさん:2010/11/07(日) 12:01:40
ムーブコンストラクタが呼び出されるって事とムーブコンストラクタの実装が元を破壊しない実装ってのは別々の話でしょ

522 :デフォルトの名無しさん: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();
 }
みたいに使えたら便利だなあ。以上、妄想でした。

523 :デフォルトの名無しさん:2010/11/07(日) 17:29:26
デストラクタいつ呼ばれんだよ。

524 :デフォルトの名無しさん:2010/11/07(日) 17:53:52
スコープ抜けるところでコピーされて、元のはデストラクトでは。

525 :デフォルトの名無しさん:2010/11/07(日) 23:11:50
スコープの外で変数宣言したほうがわかりやすいと思うけどな。


526 :デフォルトの名無しさん:2010/11/07(日) 23:58:22
初期化される前に例外投げられた場合の仕様が必要になる事は間違いない
フラグ自分で立てて判断、ってんじゃ面倒くさいからな

まあ try-catch 時に try 内の変数を使いたい場合はよくあるので欲しい所だが、
export やら extern やら無くてもそのままアクセスできたのでも良いと思う

527 :デフォルトの名無しさん: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();
 }
とした方が面倒くさくなくていい

528 :デフォルトの名無しさん:2010/11/09(火) 17:44:46
簡単な内容のメソッドが多いため、クラス直下のメソッドを減らすために
使用範囲の限られるメソッドをメソッド内に格納したところ、
次のようになってしまいました
class hoge{
/*...*/
 void fuga{
  auto piyo=[this](...){
   auto piyopiyo[this](...){ //VC++ではエラー
    /*...*/
   }
   /*...*/
  }
 }
}
g++ 4.5.1ではコンパイルが通るのですが、VC++2010ではエラーが出ます
thisポインタを二重にキャプチャするのは規約違反なんでしょうか

529 :デフォルトの名無しさん:2010/11/09(火) 19:41:14
class typedef int Hoge;

でstrong typedefとかどうよ

530 :デフォルトの名無しさん:2010/11/10(水) 08:00:59
>>528
5.1.2-12
 変数が「キャプチャされる」とは、明示的もしくは暗黙的にキャプチャされることだ。
 (中略)
 もし this がラムダ式にキャプチャされるなら、
 そのラムダ式を囲んでいる一番内側の関数は、非静的メンバ関数でないとだめ。

って書いてある。

同じ個所に、ラムダの中のラムダを [this] じゃなくて [&] にすることで
this をもう一度キャプチャさせる例が載っていて、
実際 VC でもそれはできるので

『外側のラムダ式を「一番内側の関数」だと思って
 それが非静的メンバ関数じゃないからエラー』
というわけではなさそう。

「キャプチャされる」ことを「キャプチャリストに現れる」ことだと誤読すれば
VC の挙動も説明できるけど、多分 g++ が正しい。



531 :デフォルトの名無しさん:2010/11/10(水) 18:14:04
2つ目のthisがpiyoを指してると認識してんだろうなあVC++は

532 :デフォルトの名無しさん:2010/11/10(水) 18:32:11
なるほどラムダオブジェクトを指してると思ってる訳か・・・

533 :デフォルトの名無しさん:2010/11/13(土) 20:13:57
auto s=[](int x){return x*2.0;};
typedef decltype(s) m;
これを、VC10で1行にまとめて下のようにすると、error C3477: ラムダは評価されていないコンテキストでは使用できませんエラーが出ます
typedef decltype([](int x){return x*2.0;}) mm;
autoの関数定義に使いたいんですけど、1行にまとめる方法はないですか?

534 :デフォルトの名無しさん:2010/11/13(土) 20:16:12
現行仕様のでもいいから完全に準拠したC++コードをMVC++に変換するコンパイラがあってもいいはずだ

535 :デフォルトの名無しさん:2010/11/13(土) 20:35:33
ラムダのtypedefとか基本的に無茶だろ
そういう風に使うもんじゃない

536 :デフォルトの名無しさん:2010/11/13(土) 21:00:48
std::function使え

537 :デフォルトの名無しさん:2010/11/13(土) 21:04:53
template <class X> X identify(X);
typedef decltype(identify([](){}) type;

試したことはない

538 :デフォルトの名無しさん:2010/11/13(土) 21:29:40
decltype とか sizeof とかにラムダ式入れちゃいけないきまりになってる


539 :デフォルトの名無しさん:2010/11/13(土) 22:06:07
>>535-538 ありがとうです。
>>537の方法で通りましたです。この抜け穴で何とかなりそうです


540 :デフォルトの名無しさん:2010/11/13(土) 22:39:42
>>539
リビルドしたら通らなくなった???なぜに?

541 :デフォルトの名無しさん:2010/11/13(土) 23:00:18
もし通ることかあるとすれば、そのほうが間違いっぽいんだけど

542 :デフォルトの名無しさん: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;};
って宣言・代入できる

543 :デフォルトの名無しさん:2010/11/14(日) 01:00:24
functionはboostやtr1でおなじみだと思いきや
C++系のスレ見ててもあまり使われてない感じがする
結構便利なのに

544 :デフォルトの名無しさん:2010/11/14(日) 01:02:58
パッと見中で何やってんのか想像できないライブラリってなんか抵抗あるんだよね



545 :デフォルトの名無しさん:2010/11/14(日) 02:22:39
ラムダ式を使う場合、大抵はラムダ式を直接渡せば事足りるからな。

546 :デフォルトの名無しさん:2010/11/14(日) 03:24:32
functionとlambdaで事実上関数内関数が作れるのはよい

547 :デフォルトの名無しさん:2010/11/14(日) 03:28:06
>>544
単に共通の非テンプレートなベースクラスを継承したテンプレートなクラスを作ってるだけ。
まあ、vtable自前とか変態的な実装もあるけど。

548 :デフォルトの名無しさん:2010/11/14(日) 03:30:17
ラムダは夢が広がるね。
BOOST_SCOPE_EXITの見た目すっきりの代替品とかいろいろ出てきてる。

549 :デフォルトの名無しさん:2010/11/14(日) 07:15:45
関数オブジェクトの戻り型をhoge::result_typeで貰ってるんだけど、lamdaはresult_typeがないから面倒だな。

550 :デフォルトの名無しさん:2010/11/14(日) 08:14:47
>>546
見やすくなるよな

551 :デフォルトの名無しさん:2010/11/14(日) 08:59:11
>>541
簡易ビルドが効いてて、変更が反映されてなくて通ってたっぽい。リビルドでそれがリセットされた。


552 :デフォルトの名無しさん:2010/11/16(火) 22:25:48
ムーブさんの問題がついにコピーさんに飛び火してしまった
一体どうなるのか

553 :デフォルトの名無しさん:2010/11/16(火) 22:28:30
いったん0xはなかった事にするのがいいと思う

554 :デフォルトの名無しさん:2010/11/16(火) 22:32:22
0x以前を無かったことにしろ

555 :デフォルトの名無しさん:2010/11/16(火) 22:37:42
C++を放り投げてネイティブC#であらゆる問題が解決するんだよね


556 :デフォルトの名無しさん:2010/11/16(火) 22:44:23
>>552
規格策定がさらに1〜2年伸びるわけですね、わかります

557 :デフォルトの名無しさん:2010/11/17(水) 00:06:00
絵に描いたような矛と盾。

558 :デフォルトの名無しさん:2010/11/17(水) 00:09:07
ちょっとムーブさんとコピーさんの関係まとめてよ

559 :デフォルトの名無しさん:2010/11/17(水) 00:15:06
ムーブさんのせいで家庭崩壊の危機に陥って、ムーブさんの立ち入り禁止を命ずる裁判所命令で
解決したかに見えたが、土壇場で旦那が実はコピーさんが家のことを勝手にあれこれやるのも快く思ってなかったとか
言い出したせいで、示談で落ち着くはずが混迷化(いまここ)

560 :デフォルトの名無しさん:2010/11/17(水) 00:34:15
ムーブさんの行動が上級生の邪魔になるというのでムーブさんの権限を一部剥奪することになったが、
校長先生が「上級生のコピー君も今まで同じことをしておった喃」とか言い出して、コピーさんの
権限まで制限されることになってしまった。

561 :デフォルトの名無しさん:2010/11/17(水) 02:49:00
よっしゃー。優等生がいなくなって学級世紀末覇者も時間の問題。

562 :デフォルトの名無しさん:2010/11/17(水) 06:46:44
暗黙のコピーさんと暗黙の方変換は昔から挙動が怪しかったが、周りがあわせることで事なきを得た。
ムーブさんもそうなってほしい。

563 :デフォルトの名無しさん:2010/11/17(水) 07:16:04
暗黙のコピーはCの構造体との互換性のため必須だったんじゃ

564 :デフォルトの名無しさん:2010/11/17(水) 08:28:47
互換性は関係ないだろ。
これはユーザー定義のデストラクターが定義されている場合、
暗黙のコピーコンストラクターの生成されないべきという話なんだから。

565 :デフォルトの名無しさん:2010/11/17(水) 09:53:31
autoさん「互換性なんて投げ捨てろよwww」

566 :デフォルトの名無しさん:2010/11/17(水) 10:28:27
auto使っても型違い警告出るとこあるよな

567 :デフォルトの名無しさん:2010/11/17(水) 12:51:53
仮にいちゃもん付けられる前までのコピーについて>>1-のテンプレで書くとしたらどんなのになる?

568 :デフォルトの名無しさん:2010/11/17(水) 13:43:29
今までの暗黙のコピーは、
今まさにうんこしているやつがいるのに、便器の掃除を始めるようなものかな。

569 :デフォルトの名無しさん:2010/11/17(水) 17:47:49
いや
下手に便所を奪ったら先に用たしてた奴がそこらじゅうに糞便まき散らす恐れがあるから
後発で便意をもよおした奴は隣に便所作ってウンコするみたいな様子

570 :デフォルトの名無しさん:2010/11/17(水) 17:50:31
この業界ってそのまま説明すればいいのにわざわざ分かりにくい例えしてくるオナニスト大杉やでしかし

571 :デフォルトの名無しさん:2010/11/17(水) 17:53:45
もどかしさと被害の表現がえらく的を得てるようだが

572 :デフォルトの名無しさん:2010/11/17(水) 18:21:34
的は射るものです

573 :デフォルトの名無しさん:2010/11/17(水) 18:35:20
的を射るのはいいけど得たらダメとかおさわり禁止みたいなこというなよ

574 :デフォルトの名無しさん:2010/11/17(水) 18:44:36
>>564
なるほどそういう事か
まあ = default あるし、別にいいんじゃない、と思うね
boost::noncopyable とか不要になるし、
そもそもコピー可能かどうかちゃんと考えてないクラスは
コピー禁止すべきだと思うし

575 :デフォルトの名無しさん:2010/11/17(水) 19:34:12
不要にはならないだろ
deprecatedなだけで無くなりはしないんだから自衛は必要

576 :デフォルトの名無しさん:2010/11/17(水) 19:58:37
古いコードで警告が数百数千と出るようになるだけ。

577 :デフォルトの名無しさん:2010/11/17(水) 22:26:54
>>572
的を得るで合ってる

578 :デフォルトの名無しさん:2010/11/17(水) 22:29:50
まさに2ch的日常

579 :デフォルトの名無しさん:2010/11/17(水) 22:33:47
>>572
的を射るで会ってる


580 :デフォルトの名無しさん:2010/11/17(水) 23:58:58
>>577
wwww

581 :デフォルトの名無しさん:2010/11/18(木) 00:13:17
的を得るでぐぐれ

582 :デフォルトの名無しさん:2010/11/18(木) 00:32:09
賞を射止めるとかあるように
的を得るでもいいのではないだろうか、射的を制する的な意味合いで

583 :デフォルトの名無しさん:2010/11/18(木) 00:41:17
プログラマならあいまいな表現は使うな
以上

584 :デフォルトの名無しさん:2010/11/18(木) 02:24:02
C++0x風にいうと
「的を得る」は独自拡張であり
正式に導入されるまでは
コンパイルエラー。

的を得るが正しいとか頑張って涙目で主張してもコンパイルエラーは
許してくれないことは思い知っているはず、


585 :デフォルトの名無しさん:2010/11/18(木) 02:54:06
例えとか要らないからボケカスアホンダラ

586 :デフォルトの名無しさん:2010/11/18(木) 11:30:19
「的を得る」あたりだと規格には入っていないが主要なコンパイラはデフォルトでサポートしている状態
原理主義者が必死にコンパイラオプション指定して「的を得る」はコンパイルエラーにしなければならない
とか喚いている感じ

のように変な例えから変な例えが派生して話がわけわかめになるわけだな。

587 :デフォルトの名無しさん:2010/11/18(木) 11:58:37
的を得る/的を失する は別に誤用じゃないんだけどな

588 :デフォルトの名無しさん:2010/11/18(木) 13:52:44
自然言語スレになったん?


589 :デフォルトの名無しさん:2010/11/18(木) 16:00:39
言語マニアの多いから

590 :デフォルトの名無しさん:2010/11/18(木) 16:03:13
日本語0x

591 :デフォルトの名無しさん:2010/11/18(木) 17:00:57
自然言語に例えると英語と中国が混ざったようなスレだな

592 :デフォルトの名無しさん:2010/11/19(金) 00:41:00
J++とな

593 :デフォルトの名無しさん:2010/11/19(金) 21:54:54
>>591
C++/CLIの悪口はやめて!

594 :デフォルトの名無しさん:2010/11/19(金) 21:56:58
>>593
だってそれC++じゃないじゃん

595 :デフォルトの名無しさん:2010/11/19(金) 22:25:52
BOOST mplやlamadaやspiritはC++に見えないけど確実にC++だしな

596 :デフォルトの名無しさん:2010/11/19(金) 22:34:04
あれはC++ではなくてboostという名のなにかだよ

597 :デフォルトの名無しさん:2010/11/20(土) 00:50:33
boostの悪口言うなよ
C++0xに標準として取り入れられるライブラリがいくつかあるんだから

598 :デフォルトの名無しさん:2010/11/20(土) 00:50:59
ここはObjective-C++の出番か

599 :デフォルトの名無しさん:2010/11/20(土) 01:17:47
もしもObjective-C++/CLIが出たら…

600 :デフォルトの名無しさん:2010/11/20(土) 01:31:44
Objective-C++0x/CLIを待つしか無いな

601 :デフォルトの名無しさん:2010/11/20(土) 15:52:59
vector<int> v;
v::size_type s;

みたいに出来れば素敵なのに
次の規格には入れてくれよな校長

602 :デフォルトの名無しさん:2010/11/20(土) 16:19:19
decltype使えばいいんじゃね?

603 :デフォルトの名無しさん:2010/11/20(土) 16:22:39
decltypeって長々とうつのめんどくさいじゃん
typedefの手間もいらないしこれ出来ればかなり便利だと思うんだよね

604 :デフォルトの名無しさん:2010/11/20(土) 16:33:58
カスだな

605 :デフォルトの名無しさん: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.

(ノ∀`)タハー

606 :デフォルトの名無しさん:2010/11/20(土) 17:39:16
まあどうせ未完成なんだし
そこだけ凝っても仕方ないわな

607 :デフォルトの名無しさん:2010/11/21(日) 12:25:11
>>601
v.iterator begin(){return v.begin();}
て書くのか?混乱するだろう。同じ目的に複数の記述方法があるとあいまいになるだろ。
>>603
多少のタイプ量を減らすよりtypedefして型を明確にしたほうが読みやすいぜ。

608 :デフォルトの名無しさん:2010/11/21(日) 12:28:47
大抵はautoで大丈夫じゃね
メンバ変数とかは無理だが

609 :デフォルトの名無しさん:2010/11/21(日) 12:29:46
>>607
v::iterator it = v.begin(), end = v.end();
って書くんだよ


610 :デフォルトの名無しさん:2010/11/21(日) 17:59:18
int main(){[](){}();}

611 :デフォルトの名無しさん:2010/11/21(日) 18:01:00
Perl以下の糞文法でゲソ

612 :デフォルトの名無しさん:2010/11/21(日) 18:02:03
Perlには敵わないんでなイカ?

613 :デフォルトの名無しさん:2010/11/21(日) 20:14:52
ラムダ式っておでんっぽい

614 :デフォルトの名無しさん:2010/11/21(日) 20:18:37
int main(){<|()[]-;}

615 :デフォルトの名無しさん:2010/11/21(日) 20:26:17
int main(){[=]()->O{}();}

616 :デフォルトの名無しさん:2010/11/21(日) 20:29:38
int main(){くコ:彡;}

617 :デフォルトの名無しさん:2010/11/24(水) 17:50:12
auto main() -> int { auto final = [](){}() ; }

618 :デフォルトの名無しさん:2010/11/24(水) 17:54:02
実行したらダメだろ
autoがvoidに推測される

619 :デフォルトの名無しさん:2010/11/29(月) 08:54:09
結局OpenCVとかC++で書かれたものは、そのまま使えるの?

620 :デフォルトの名無しさん:2010/11/29(月) 09:23:43
ほぼ使えるよ

621 :デフォルトの名無しさん:2010/11/29(月) 10:17:28
decltypeすごく便利
ラムダ式もようやく慣れて来た
早く規格が固まらないかねえ

622 :デフォルトの名無しさん:2010/12/05(日) 20:35:22
先月分のペーパーが公開されたか。

noexceptたんやっぱうぜーって言われてる?

623 :デフォルトの名無しさん:2010/12/05(日) 23:03:38
contextual keywordってマジでやるのか
勘弁して

624 :デフォルトの名無しさん:2010/12/05(日) 23:22:29
attribute何とかの嵐よりはマシ

625 :デフォルトの名無しさん:2010/12/05(日) 23:23:52
本物の予約語にして「identifierにも使えるけどdeprecatedです」じゃダメなの?

626 :デフォルトの名無しさん:2010/12/06(月) 00:09:33
暗黙デフォルトムーブさんはマジで退学。
defaulted定義のときだけ召喚されるんだね。

>>625
もう予約語追加しないって言っちゃったんじゃなかったっけ?FCDで。

627 :デフォルトの名無しさん:2010/12/06(月) 00:11:51
わざわざstd::moveで食わせないといけなくなったのか?

628 :デフォルトの名無しさん:2010/12/06(月) 01:07:26
退学は妥当な処置だな

629 :デフォルトの名無しさん:2010/12/06(月) 11:06:31
C++0x好きだわー
こうやって何回も議論を重ねると論理の穴を塞いだ規格が出来上がる
一人で作った言語とは大違い

630 :デフォルトの名無しさん:2010/12/06(月) 11:22:58
LLバトロイスレ逝け

631 :デフォルトの名無しさん:2010/12/06(月) 13:06:48
>>629
その代わり覚えなければならない事が山ほど増えるぞ
初心者向け言語ではますますなくなる

632 :デフォルトの名無しさん:2010/12/06(月) 13:27:17
範囲ベースの for ループはどうやって
範囲の長さがわかるんですか?

633 :デフォルトの名無しさん: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で呼び出せるように実装しておけばいい。

634 :デフォルトの名無しさん:2010/12/06(月) 21:52:04
>>633
フリー関数とメンバ関数と、両方固められたらもう予約語級の名前空間汚染度だなぁ。
ってそんな議論もきっと通った上での話しなんだろうなぁ。でもでも、もしかしたら
Concept が抜けたことで、ふさいでたつもりの穴がうっかり空いてたりしそうで怖いなぁ。

635 :デフォルトの名無しさん:2010/12/06(月) 23:52:28
暗黙デフォルトコピーも退学にしてくれ


636 :デフォルトの名無しさん:2010/12/06(月) 23:57:42
>>635
それはこまるなー。
プロトタイプ作ってるときは効率なんて考えないから、そういう便利機能はありがたい。
関数型ライクというかなんというか。

637 :デフォルトの名無しさん:2010/12/07(火) 00:06:55
退学じゃないけどD組行きだろ

638 :デフォルトの名無しさん:2010/12/07(火) 00:30:23
n3225だと、暗黙デフォルトムーブさんは退学してなくね?
一部D組に堕ちた暗黙デフォルトコピーと、同じくらいの穏便な処置で済んでるよ。

639 :デフォルトの名無しさん:2010/12/07(火) 09:27:05
デフォルトコピーとかユーザーによって反応がまちまちの機能は
コンパイルオプションで決めれるように仕様に明記すれば良いのに

640 :アクセス宣言:2010/12/07(火) 10:27:40
わたし、n3225で退学だって・・・ショック。
何よ、そりゃusing宣言ちゃんの方がすこし可愛いかもしれないけどさ。
八方美人っていうの? わたしからすれば尻軽だけどぉ。

641 :デフォルトの名無しさん:2010/12/07(火) 14:46:53
>>639
人の書いたコードと混ぜられなくなるだろ。
言語によってはソースファイル毎に指定できたりもするが、C++は#includeというものがあるし。

642 :デフォルトの名無しさん:2010/12/07(火) 15:08:35
コンパイルオプションでそんな動作変わるとかPHPじゃないんだから・・・

643 :デフォルトの名無しさん:2010/12/07(火) 15:16:11
キモイ
private "C++0x" extern "C" {
}
private "C99" {
}

644 :デフォルトの名無しさん:2010/12/07(火) 16:05:17
>>642
#includeの無い言語ではそんな珍しいものでもないぜ。
FreePascalの、GNU Pascal互換モードとDelphi互換モードなんか、見た目にも別の言語だw

645 :デフォルトの名無しさん:2010/12/07(火) 21:04:09
C99の#pragma STDCでも使って切り替えられればいいのに

646 :デフォルトの名無しさん:2010/12/07(火) 22:31:07
もう2010年も終わろうとしてるのにまだ0xと言い張るか

647 :デフォルトの名無しさん:2010/12/07(火) 22:38:54
2015年が終わるまでは

648 :デフォルトの名無しさん:2010/12/07(火) 22:45:41
C++0xの0xは20xy年のまんなか2桁をとったんだよ!
よしこれでこれで2100年まで延々と規格策定を続けられる

649 :デフォルトの名無しさん:2010/12/07(火) 22:46:43
ならコンセプトさん復活させようぜ!

650 :デフォルトの名無しさん:2010/12/08(水) 01:19:22
もう秒単位で変わる規格にしようぜ!

651 :デフォルトの名無しさん:2010/12/08(水) 01:35:21
もう新規さんは出てこないだろうから別に規格とかどーでもいいんじゃないかな
MSとGNU間で摺合の機会を持てば十分でしょ

652 :デフォルトの名無しさん:2010/12/08(水) 18:15:19
林檎の人たちを忘れてますよ

彼らは摺り合わせとか応じないだろうなぁ

653 :デフォルトの名無しさん:2010/12/08(水) 19:22:41
Symantec C++やWatcom C++がやる気なくしてBorland C++が変な方向へ疾走しだした頃から規格なんてベンダへ押し付ける努力目標になってるからなー

654 :デフォルトの名無しさん:2010/12/08(水) 20:35:29
HTML5のように規格厨が蔓延るよりなんぼかマシだわ。

655 :デフォルトの名無しさん:2010/12/08(水) 21:48:17
でも規格がないとD言語になっちゃうからな

656 :デフォルトの名無しさん:2010/12/09(木) 00:40:09
有能なコンパイラ屋が相次いで離反する「信者を持てない言語」だな

657 :デフォルトの名無しさん:2010/12/09(木) 00:46:49
規格はMSとGNUで決めればOK
規格制定委員会なんてイラン

658 :デフォルトの名無しさん:2010/12/09(木) 00:48:22
C++0xがこのざまなのは、全て禿げが悪いんだよね

659 :デフォルトの名無しさん:2010/12/09(木) 05:49:33
>>652
林檎はgcc使ってるだけじゃん。

660 :デフォルトの名無しさん:2010/12/09(木) 05:50:50
>>654
あれほど実装にすりよってもまだそんなこと言われるの
XHTML2厨が聞いたら卒倒しそうだな

661 :デフォルトの名無しさん:2010/12/09(木) 06:40:47
C++規格がHTML5規格にように書かれるならば、
すべての実装はMSVC拡張とgcc拡張に加えて、POSIXとWin32 APIとx86インラインアセンブラをサポートしなければならなくなるな。

662 :デフォルトの名無しさん:2010/12/09(木) 13:59:53
autoとかめんどくさいこと言わずに最初に代入か初期化された型になるで良いじゃん
そんで初期化されるまでは不定でアクセスするとコンパイルエラーになる

663 :デフォルトの名無しさん:2010/12/09(木) 14:02:01
変数は使うときに宣言すればいいだろ。
まさかC言語厨か?
あれだろ、お前は関数の冒頭に変数を全部宣言しておく口だろ。

664 :デフォルトの名無しさん:2010/12/09(木) 14:03:18
ちげーよ。なんでそうなるんだよ。ふんころがしは黙ってろ

665 :デフォルトの名無しさん:2010/12/09(木) 14:29:01
>>662
うーん良く分からん
最初の代入で型を決めるという実装だと
unsigned x = 0;
void hoge(){
x = 0;
}
このときにローカル変数のxを宣言して初期化なのか、
グローバル変数のxに代入なのか区別つかん気がする。

これを解決するためには結局autoに近いものが必要だよね(javascriptのvarとか)

666 :デフォルトの名無しさん: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はいらないかもね

667 :デフォルトの名無しさん:2010/12/09(木) 15:14:16
extern x = 0;
x = 1;
void hoge(){
 x = 2;
 assert(extern x == 0 && ::x == 1 && x == 2);
}


668 :デフォルトの名無しさん:2010/12/09(木) 15:20:27
なんか B への原点回帰みたいだな

669 :デフォルトの名無しさん:2010/12/09(木) 15:51:44
後のStroustrupの語るところによれば、「BCPLに比べれば、C言語は超高級な言語に見えた」ということである。

670 :デフォルトの名無しさん:2010/12/09(木) 16:09:03
>>666
なにこれきめぇ

671 :デフォルトの名無しさん:2010/12/09(木) 16:40:57
>>666
struct foo{
foo(int);
void operator()(int);
}

とかあるとややこしいことになるな

672 :デフォルトの名無しさん:2010/12/09(木) 18:37:21
初期化の代入は := にするとか

673 :デフォルトの名無しさん:2010/12/09(木) 18:43:15
それなんてIo

674 :デフォルトの名無しさん:2010/12/09(木) 19:00:33
:=とか[a,b)とか使えたらさぞや気持ち良いだろうな

675 :デフォルトの名無しさん:2010/12/09(木) 19:36:07
:=はともかく[a,b)はパーサが死にそうw

676 :デフォルトの名無しさん:2010/12/09(木) 19:52:43
>>662
ローカル変数の事だと思うけど、
適当な文をコメントアウトしただけで挙動が変わりそうで怖いし、
結局キャストが必要で宣言したんでいいじゃんなケースも多いと思うし、
配列どうすんのって感じだし、
アドレスとる分にはコンパイルエラーになるケースが皆無だし、
C++として全然駄目だと思うぞ

677 :デフォルトの名無しさん:2010/12/09(木) 19:53:29
forの後限定、整数限定とかなら実装も簡単だし、実用性も高い

678 :デフォルトの名無しさん:2010/12/09(木) 20:01:45
既存の変数を使った場合、同名の新しい変数が使われるのか、
それとも新規の変数が使われるのか分からない

679 :デフォルトの名無しさん:2010/12/09(木) 20:02:35
同じ事言ってしまったw

既存の変数を使った場合、同名の新しい変数が使われるのか、
それとも既存の変数が使われるのか分からない



680 :デフォルトの名無しさん:2010/12/09(木) 22:31:30
Rubyスレかと思った

681 :デフォルトの名無しさん:2010/12/09(木) 22:35:51
a = [1,2,3]
a.each{|a| p a}

1
2
3

こういうことか

682 :デフォルトの名無しさん:2010/12/10(金) 16:18:43
>>681
古いバージョンではその後の a の値が 3 になるが、
新しいバージョンでは [1,2,3] のままになる。

クロージャのある言語で変数宣言的な構文がないと
こういう問題がある。

C++ は宣言もあるし、lambda にキャプチャリストもあるんで
関係ないけど。


683 :デフォルトの名無しさん:2010/12/10(金) 19:12:02
ああ、さらにそのあとp aしないと意味なかったか

やはり宣言ないとスコープ分かりにくいな

684 :デフォルトの名無しさん:2010/12/10(金) 23:15:33
制御ブロック専用のauto予約語を作ればいいんだな
afor,awhile,doa

685 :デフォルトの名無しさん:2010/12/10(金) 23:55:54
do (int n) {
 n = ...;
} while (n == m);

みたいなことはやりたいと思う

686 :デフォルトの名無しさん:2010/12/11(土) 00:22:27
do {
 int n;
 n = ...;
} while (n == m);

と何が違うんだ?

687 :デフォルトの名無しさん:2010/12/11(土) 00:22:46
whileはブロックの外だからnにアクセスできない

688 :デフォルトの名無しさん:2010/12/11(土) 00:35:28
http://codepad.org/EpMG6m1l

きもいコードだが

689 :デフォルトの名無しさん:2010/12/11(土) 01:17:59
{
  int n;
  do {
   n = ...;
  } while (n == m);
}
で良いじゃないか



690 :デフォルトの名無しさん:2010/12/11(土) 10:12:50
>>687
アクセスできる仕様になれば良いんだな

>>688
ifを使うとはwww

>>689
ブロックがウザい

691 :デフォルトの名無しさん:2010/12/11(土) 10:32:47
do { int n; do{

} while(0); }while(n==m);

692 :デフォルトの名無しさん:2010/12/11(土) 10:37:44
いや、逆だろ

693 :デフォルトの名無しさん: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);

694 :デフォルトの名無しさん:2010/12/11(土) 10:46:39
さすがプリプロセッサさんや

695 :デフォルトの名無しさん:2010/12/11(土) 12:20:46
while条件がスコープの中なら万事解決なのに
なんでdoの時は外されるの?

696 :デフォルトの名無しさん:2010/12/11(土) 12:48:52
0xではスコープ変わったりしてないの?

697 :デフォルトの名無しさん:2010/12/11(土) 12:56:13
N3225では変わってない

よく読むと条件部って「宣言された名前が内側のスコープに入る」(3.3.3-4)だけで
条件部自体がスコープに入ってるわけではないのね
do-whileの条件で宣言なんかしても意味ないから(そもそも出来ないけど)、スコープに入らないわけか
納得した

698 :デフォルトの名無しさん:2010/12/11(土) 13:06:19
while( int i = 1 )
{
i = 0 ;
}

宣言は出来る
でも永久ループする

699 :デフォルトの名無しさん:2010/12/11(土) 13:25:00
いや、それは当然できるよ
do{
...
}while(int i=0);

が出来ないって事
普通のwhileの条件はconditionで、do-whileの条件はexpressionだからね

700 :デフォルトの名無しさん:2010/12/11(土) 20:40:10
まあそれ以降使える所がないしな

701 :デフォルトの名無しさん:2010/12/11(土) 20:45:22
do statement while(expression); だっけ?
{ } は必須じゃなくて do-while とは無関係だから
スコープを広げるという仕様を加えにくいんだろうね

702 :デフォルトの名無しさん:2010/12/11(土) 20:59:57
その辺はifやforも一緒だから問題ない

do-whileの場合はstatementの中の名前を条件部に導入するっていう
他と逆の話になるのが問題なんだろう

703 :デフォルトの名無しさん:2010/12/11(土) 21:08:42
全然違う
if, for, while の場合はスコープを狭めるだけなのに対して、
do-while の場合はブロックの外にスコープを広げる仕様になるわけで

704 :デフォルトの名無しさん:2010/12/11(土) 21:17:48
だったらこれでいいんでない?

do
 declaration-list;
 statement;
while (expression);

do int i; { i = ... } while (i == 0);

705 :デフォルトの名無しさん:2010/12/11(土) 21:34:18
これで良いだろ
do:
......
if( xxx ) goto do;

706 :デフォルトの名無しさん:2010/12/11(土) 22:08:27
予約語ってラベルに出来たっけ?

707 :デフォルトの名無しさん:2010/12/11(土) 22:12:11
できるわけないだろ。
プリプロセッサーのマクロの識別子にも使えないから注意しろよ。
今回、newキーワードの再利用で、
#define new(x) ....
とかやってるマクロがぶっ壊れるからな。
自業自得だ。

708 :デフォルトの名無しさん:2010/12/11(土) 22:33:42
new(...) という形式の構文が追加されたの?

709 :デフォルトの名無しさん:2010/12/11(土) 22:46:12
追加も何もC++03でもplacement newがありますが

710 :デフォルトの名無しさん:2010/12/11(土) 22:55:34
そうかnewマクロが軒並み壊れるのか
MSVCには絶対採用されない機能になったな

711 :デフォルトの名無しさん:2010/12/11(土) 23:00:47
そもそも、C++98の時点で、使えないとされているからな。
newキーワードの再利用の時の議論に、この問題があがったらしいけれど、
そもそもplacement newすらぶっ壊れるじゃん。自業自得だと論破された。

712 :デフォルトの名無しさん:2010/12/11(土) 23:08:01
そんな事言われてもMFC使っちゃってるプログラムは現にごまんとあるんだよ
どうせcontextual keyword作るならhidingでいいじゃんかよ
勘弁してくれ

713 :708:2010/12/11(土) 23:11:20
>>709
あいや、それは知ってるんだわ。
707で「今回newの再利用で」とあるので、新規に()が続く形式も追加されたのか
と思っただけ。
メンバー関数の上書き指定の文脈依存語では new() の形は挙がってなかった
と思ったんで。

714 :デフォルトの名無しさん:2010/12/11(土) 23:17:11
プリプロセッサーの識別子に、
キーワードと新しく追加される文脈依存キーワードを使ってはならないというのは、
ライブラリ実装者からしても当然のルールだよ。
そんなことを許してしまうと、コンパイラ側で、すべてのキーワードに対して、
アンダースコアで始まる同等な意味を持つ独自キーワードでも提供しない限り、
安全にライブラリを実装することができなくなってしまう。

ライブラリ自ら、そんなアホなことやってるのは、自分で首を絞めているようなもんだ。

715 :デフォルトの名無しさん:2010/12/11(土) 23:30:24
俺はMFC使わないしどうでもいいんだが
予約語を前処理で置換する事の道義的な是非は別として
new() 形式の構文が追加されても、それらについて明示的に「手で」マクロ
展開を抑制することは出来るし、特別 new() マクロだけ使えなくなるという
ことは無さそうに見える。

716 :デフォルトの名無しさん:2010/12/11(土) 23:38:30
>>714
あなたの言ってる事は全く正論だし完全に正しいと思うが
そんなアホな事をやってるライブラリが実際に存在して、
しかもそれは世界一普及したOSの重要なライブラリであって、極めて広く使われているという現実を
無視してはいけないと思うんだ

717 :デフォルトの名無しさん:2010/12/12(日) 09:48:13
VC6時代は
#define for if(0); else for
とか普通にやってたよね
forが腐ってる時点で規格云々話す意味ないけど

718 :デフォルトの名無しさん:2010/12/12(日) 09:53:23
それもATLのヘッダが腐ってたせいでなかなか修正できなかったんだよな

719 :デフォルトの名無しさん:2010/12/12(日) 09:55:43
結局、諸悪の根源はMSだな。

720 :デフォルトの名無しさん:2010/12/12(日) 10:25:20
必要悪だからどうにも出来ないけどな。

721 :デフォルトの名無しさん:2010/12/12(日) 18:50:55
for i in x, y, z do …
的なこと0xだと出来るんだっけか?

722 :デフォルトの名無しさん:2010/12/12(日) 19:04:51
range-based forですね

723 :デフォルトの名無しさん:2010/12/14(火) 10:37:44
>>665
そういえばboost.fusionが後から型を変更できるのだろうか

724 :デフォルトの名無しさん:2010/12/14(火) 11:10:05
MFCは糞

725 :デフォルトの名無しさん:2010/12/14(火) 21:18:46
マクドナルドフライドチキン?

726 :デフォルトの名無しさん:2010/12/14(火) 23:36:22
麻雀格闘倶楽部。

727 :デフォルトの名無しさん:2010/12/15(水) 20:52:11
マイケルファックチャイルド

728 :デフォルトの名無しさん:2010/12/19(日) 16:10:47
で、右辺値参照はその後どうなった?

729 :デフォルトの名無しさん:2010/12/19(日) 17:29:22
どうにもならなかった

730 :デフォルトの名無しさん:2010/12/19(日) 19:52:17
暗黙のムーブコンストラクタが
暗黙のコピーコンストラクタを巻き込んで
弄ばれてるんじゃなかったっけ

731 :デフォルトの名無しさん:2010/12/20(月) 07:34:52
何で今頃になってそんな話してるんだよ

732 :デフォルトの名無しさん:2010/12/20(月) 12:08:13
コピコンを使用禁止にしておいて
ムブコンだけでいいような設計がベストだよ。

733 :デフォルトの名無しさん:2010/12/20(月) 12:12:07
言語仕様をこんなに複雑にしちゃって大規模アプリで運用できるのかなぁ

734 :デフォルトの名無しさん:2010/12/20(月) 12:34:06
>>733
ライブラリを使う側の人には、大して複雑になってないと思うけど。
キモい見た目のアレはコーディング規約とかでゴニョゴニョすればいいし。

735 :デフォルトの名無しさん:2010/12/20(月) 13:19:04
> キモい見た目のアレはコーディング規約とかでゴニョゴニョすればいいし。
lambda なんてものは、あれば使いたくなるのが人情ってもんだろ?
コーディング規約でゴニョゴニョしてもキモイ見た目は変わらない


736 :デフォルトの名無しさん:2010/12/20(月) 14:28:16
見慣れないものはキモイ、
そうやって差別や偏見がはじまっていくのだろうな・・・

737 :デフォルトの名無しさん:2010/12/20(月) 14:57:08
見た目なんて気にしてたら何時まで経ってもコーディングできないだろ

738 :デフォルトの名無しさん:2010/12/20(月) 21:27:10
lambdaはキモいって事になってんの?
結構使い勝手良いし、見た目もわかりやすいと思うけど

739 :デフォルトの名無しさん:2010/12/20(月) 21:31:44
ランバダ

740 :デフォルトの名無しさん:2010/12/20(月) 22:06:58
キモくないと思えるのは幸せだね・・・

741 :デフォルトの名無しさん:2010/12/21(火) 02:27:26
http://www.news.janjan.jp/government/0702/0702090742/1.php

742 :デフォルトの名無しさん:2010/12/21(火) 03:21:47
λはいつの間にか使ってるものだな
自然に使ってしまう

743 :デフォルトの名無しさん:2010/12/21(火) 05:01:43
>>738
他の言語のlambdaを使い熟れてるとキモサ爆発だわな
まぁ、あれば使うけど


744 :デフォルトの名無しさん:2010/12/21(火) 22:42:25
このまえpythonのスレをちらっとみたら、他の言語は
サブルーチンのネストができないから、しかたなくあんなもん(ラムダ)を
導入してるんだ。
やっぱpythonはスジがいいね!

ってことで意見がまとまってた。

745 :デフォルトの名無しさん:2010/12/22(水) 01:45:49
( ゚д゚)

746 :デフォルトの名無しさん:2010/12/22(水) 07:29:57
pythonはラムダっぽいことはできないのか

747 :デフォルトの名無しさん:2010/12/22(水) 09:45:49
ラムダをつかっていると無性にランバダを踊りたくなるな。

748 :デフォルトの名無しさん:2010/12/22(水) 13:17:21
>>746
lambdaそのものは存在するがローカル関数の方が好まれるのであまり使われない。

749 :デフォルトの名無しさん:2010/12/22(水) 16:55:41
boost.lambdaとC++0xのlambdaって同じ?

750 :デフォルトの名無しさん:2010/12/22(水) 16:57:48
continuationとdelay forceは導入されないの?

751 :デフォルトの名無しさん:2010/12/22(水) 19:47:43
>>749
かなり違う
C++0xの方が後発だけあって変数のキャプチャが出来たり変数を定義する事が出来たり
参照で渡せたりまあいろいろと便利かな

752 :デフォルトの名無しさん:2010/12/22(水) 19:53:24
yieldなんて予約語は死んでも使えないC++が
どんな奇妙な構文を導入してくるか興味ある

753 :デフォルトの名無しさん:2010/12/22(水) 19:56:48
>>749
boost.lambdaはpolymorphicだけどC++0xのlambdaは違う

754 :デフォルトの名無しさん:2010/12/22(水) 19:57:22
互換性を維持しながら後発言語の機能を全部追加するなんて無茶だと思うの

755 :デフォルトの名無しさん:2010/12/22(水) 21:36:48
>>754
C++ がアイデア借りまくってる LISP も SmallTalk も ML も C++ より先発なんだが


756 :デフォルトの名無しさん:2010/12/22(水) 22:23:51
>>752
yieldはしんでも採用して欲しくないな。


757 :デフォルトの名無しさん:2010/12/23(木) 07:51:11
>>738
引数がlamdaを返すlambdaな関数のprototypeを定義してみそ


758 :デフォルトの名無しさん:2010/12/24(金) 08:52:48
C++0xになってもboost.lambdaは使えるってことでOK?

759 :デフォルトの名無しさん:2010/12/24(金) 09:02:35
おk
別に競合するもんじゃねーしな

760 :デフォルトの名無しさん:2010/12/24(金) 13:21:17
boostは標準ライブラリーではないよ。

761 :デフォルトの名無しさん:2010/12/24(金) 13:59:31
なにを突然言い出してんだ

762 :デフォルトの名無しさん:2010/12/24(金) 14:22:07
我々はアマチュアではないよ。

763 :デフォルトの名無しさん:2010/12/24(金) 14:27:02
どこの誤爆だ?

764 :デフォルトの名無しさん:2010/12/29(水) 20:09:08
>>758
boost.lambdaが使えなくなっていいぐらい互換性を壊して良いなら
C++0xはもっと早く決まっているだろう。



765 :デフォルトの名無しさん:2011/01/03(月) 13:11:02
さて、仕様が決まらないまままた年が明けた訳だが

766 :デフォルトの名無しさん:2011/01/03(月) 23:27:31
今年も仕様が決まらないまま年末を迎えるんだろうな

767 :デフォルトの名無しさん:2011/01/03(月) 23:46:11
仕様なんてそこらへんのルンペンに押し付ければいいんだ

768 :デフォルトの名無しさん:2011/01/04(火) 00:31:54
shared_ptrとかコンパイラ変えなくても実装できるものは先に規格化するとか段階的にできないの?

shared_ptrマジ必要。

769 :デフォルトの名無しさん:2011/01/04(火) 00:33:13
>>768 そこで Boost ですよ。

770 :デフォルトの名無しさん:2011/01/04(火) 00:54:15
C++が悠長に仕様策定している間に他の言語のコード資産はどんどん増えていく
プログラミング言語は道具に過ぎないのに手段と目的が逆になってきてるよな

771 :デフォルトの名無しさん:2011/01/04(火) 00:57:34
相互に互換性のない俺スマポが世界中で生まれては消えるんだよね。

だがスマポの設計は一度はやっておくといい経験にはなるのではあるが・・・・

772 :デフォルトの名無しさん:2011/01/04(火) 01:03:09
大量のオブジェクトを一斉削除したときスマートポインタの限界を思い知った

773 :デフォルトの名無しさん:2011/01/04(火) 03:25:47
ガベコレでもきっと限界を思い知るよ

774 :デフォルトの名無しさん:2011/01/04(火) 03:36:28
ガーベジコレクションで困るのって組込くらいじゃね?

775 :デフォルトの名無しさん:2011/01/04(火) 03:42:43
ガベージコレクションなんかが使い物になるのってPCくらいじゃね?

776 :デフォルトの名無しさん:2011/01/04(火) 03:46:22
ガベコレはゲームで困る

777 :デフォルトの名無しさん:2011/01/04(火) 03:51:28
普通のアプリでもたまに困る

778 :デフォルトの名無しさん:2011/01/04(火) 08:46:04
>768
TR1 があるじゃん。

779 :デフォルトの名無しさん:2011/01/04(火) 09:32:37
大量のオブジェクトを一斉削除したらスマートポインタじゃなくても結局同じ事になるような・・・?

780 :デフォルトの名無しさん:2011/01/04(火) 17:42:40
ガベコレは他のスレッドの邪魔をしないように動くのが普通

781 :デフォルトの名無しさん:2011/01/04(火) 18:32:10
そうあってほしいがそれほど普通でもない
理想と現実は区別しなければならん

782 :デフォルトの名無しさん:2011/01/04(火) 18:44:26
みんなそんなにクリティカルな仕事してるの?

783 :デフォルトの名無しさん:2011/01/04(火) 18:46:21
エロいこと言うな

784 :デフォルトの名無しさん:2011/01/04(火) 18:47:01
クリティカルだからC/C++なんだよ
効率どうでもいいならもっと便利な言語がいっぱいあるし

785 :デフォルトの名無しさん:2011/01/04(火) 18:50:59
クリティカルな仕事って、原子炉の掃除とか、骨折バイトとかのことだろ?

786 :デフォルトの名無しさん:2011/01/04(火) 19:19:49
>>780 処理系依存だ
>>784 ほかの言語がマシン語はいてくれたらC++は要らない子の筆頭だ
>>785 ハードリアルタイムが必要な処理系あるんだな
臨界値越えなきゃいいって極めておおらかな世界 < 原子炉の掃除
# で、人間系がこけると最悪なことになる


787 :デフォルトの名無しさん:2011/01/04(火) 19:26:37
「ハードリアルタイムが必要な処理系」での仕事を「クリティカルな仕事」とは言わないと暗に言ってるのでは。

788 :デフォルトの名無しさん:2011/01/04(火) 19:27:54
骨折バイトって骨のくっつき方を調べるためにわざと骨折するみたいなバイト?
痛そう

789 :デフォルトの名無しさん:2011/01/04(火) 19:30:50
そんな都市伝説信じてるやついんの?

790 :デフォルトの名無しさん:2011/01/04(火) 19:31:45
ミッションクリティカルと混同してたわすまん

791 :デフォルトの名無しさん:2011/01/04(火) 19:37:21
そういう仕事だと例外処理も嫌がられるってほんと?

792 :デフォルトの名無しさん:2011/01/04(火) 19:38:45
まあ、原子炉の掃除はルーチンワークで済ませたいだろ

793 :デフォルトの名無しさん:2011/01/04(火) 19:40:50
ミッションクリティカルな基幹系では例外処理使いまくり。

794 :デフォルトの名無しさん:2011/01/04(火) 19:41:04
いいかげんに、C++の機能はそのままに、フロントエンドの文法だけ変更した言語が欲しい。
宣言文とかテンプレートとかの曖昧になる可能性のある文法をどうにかして欲しい。

795 :デフォルトの名無しさん:2011/01/04(火) 19:43:29
>>794
【超高速】C/C++に代わる低級言語を開発したい 7
http://hibari.2ch.net/test/read.cgi/tech/1275235018/

796 :デフォルトの名無しさん:2011/01/04(火) 19:44:18
>>791
ハードリアルタイムに関してはそう
つか、例外処理悪阻杉だろ > C++


797 :デフォルトの名無しさん:2011/01/04(火) 19:45:37
そんなジャパニーズのためにEmbedded C++があります。

798 :デフォルトの名無しさん:2011/01/04(火) 20:30:38
>>796
そもそも例外処理って使ってる?


799 :デフォルトの名無しさん:2011/01/04(火) 20:50:28
>>798 C++の例外を、ハードリアルタイムな組み込みで、使うわけないじゃん


800 :デフォルトの名無しさん:2011/01/04(火) 20:53:05
嫌がれる以前に使わないだろ?という話じゃないの

801 :デフォルトの名無しさん:2011/01/04(火) 21:32:37
ハードとかリアルとかってレーザーラモンのことだろ

802 :デフォルトの名無しさん:2011/01/04(火) 21:37:10
ソフトだけで保証できるタイミングの範囲は笑っちゃうくらいどんくさい
たとえ全部アセンブラでも

803 :デフォルトの名無しさん:2011/01/04(火) 21:39:34
その心は

804 :デフォルトの名無しさん:2011/01/04(火) 21:44:52
>>802 「それをいっちゃあ、おしめぇよ」な、発言だろwWW


805 :デフォルトの名無しさん:2011/01/04(火) 22:26:36
>>779
ガベコレの実装次第。
たとえばコピーGCなら、一回のGCにかかる時間は生きているオブジェクト数に比例するから
一度に大量のオブジェクトが死のうが関係ない。

806 :デフォルトの名無しさん:2011/01/04(火) 22:34:12
>>805 destructorの処理コストを言ってるんじゃないか?
GC まかせでボチボチやったとしても、
でかいallocation要求来ればGCがアップアップするわな


807 :デフォルトの名無しさん:2011/01/04(火) 23:50:17
実装次第だな。

808 :デフォルトの名無しさん:2011/01/05(水) 00:41:06
>>807

file close とかも GC 側でめんどうみるだろ?
OS の特性として close より open が重ければアウトじゃん
GC だけで解決できる問題とはおもえへん

明確な例を提示してほしいいな


809 :デフォルトの名無しさん:2011/01/05(水) 00:57:30
スマートポインタで、デストラクタの走るタイミングを
上手いことズラしてくれるような物は無いの?

810 :デフォルトの名無しさん:2011/01/05(水) 01:10:59
>>889:2 error: '上手いこと' undeclared

811 :デフォルトの名無しさん:2011/01/05(水) 01:11:33
>>809
プログラムのセマンティックスかわっちゃうからムリだろ


812 :デフォルトの名無しさん:2011/01/05(水) 01:34:39
即解放して欲しいものと、そのうち適当に解放してくれればいい物を区別しておくんだな

あれ?

813 :デフォルトの名無しさん:2011/01/05(水) 02:10:06
>>809
デアロケータに適当なの渡して別スレッドに後始末押し付ければ

814 :デフォルトの名無しさん:2011/01/05(水) 02:59:16
デストラクタのタイミング変わったらだめだよな
C#だってディスポーザはちゃんとタイミング決めて走るわけで
じゃあデストラクタの後にもう一度廃棄処理が走れば・・・ってそれはC++/CLIじゃなイカ?

815 :デフォルトの名無しさん:2011/01/05(水) 17:40:38
デストラクタとファイナライザの役割分担か
ありがちすぎて胸が熱くなるな

816 :デフォルトの名無しさん:2011/01/05(水) 19:19:48
大量のオブジェクトを一斉に削除すると
スマートポインタのデストラクタが一遍に呼ばれて(deleteが呼ばれて)処理が滞るということから
GCの優位性を主張する奴がいただけなのにどうしてこうなった

817 :デフォルトの名無しさん:2011/01/06(木) 00:05:57
>>816
実装依存なものを優位性とか言い出すから荒れるのでは?
リソース開放処理の負荷分散したいんなら>>813のような
設計にすればよいだけ。

C++の速度優位性(JavaC#にくらべ)もコンパイラ(最適化・癖)や
CPU(キャッシュヒット等)の実装依存だけど、負荷分散の為の
GC実装への依存よりはよっぽどましな気がする。
程度問題だけど。


818 :デフォルトの名無しさん:2011/01/06(木) 23:10:00
C#でタイマーやソケットのオブジェクトへの参照を切っても、いつまでもオブジェクトがデストラクトされずにイベントが垂れ流しだったりソケットが閉じなかったり。GCっていい加減なものでGC任せにはできないな。


819 :デフォルトの名無しさん:2011/01/06(木) 23:14:26
>>780
その普通ができている実装ってあるのか?


820 :デフォルトの名無しさん:2011/01/06(木) 23:33:17
ttp://www32.ocn.ne.jp/~ons/text/CPP0xFAQ.html.ja
年末に、更新してくれたみたい。

821 :デフォルトの名無しさん:2011/01/06(木) 23:57:22
>>818
知らないことはあんまり叩かないほうがよくね?

.NETのファイナライザの実行タイミングはGCまかせだから
メモリ以外のリソース解放をファイナライザで行うのは稀
ていうか、ファイナライザ自体GCに負荷をかけるから推奨されてない

リソースは使用した箇所のfinally句で解放するのが.NETのルールで
C#には糖衣構文も用意されている

てかC++書けるくせに.NET書けないとか不勉強すぎだろ

822 :デフォルトの名無しさん:2011/01/07(金) 00:26:22
disposeあるし、、、usingもあるからましなほうだろ。
818はjavaでも同じようなことやるだろw
いっしょに仕事したくないですw

823 :デフォルトの名無しさん:2011/01/07(金) 01:32:04
Javaでも「原則使うな」なのがファイナライザ
というより、ファイナライザを積極的に使う言語なんてあるのか?

824 :デフォルトの名無しさん:2011/01/07(金) 13:05:28
Stringを継承してデフォルトデストラクターが呼ばれないことが防げるよ。

825 :デフォルトの名無しさん:2011/01/08(土) 11:17:17
C#のDisposeはもっと書きやすくして下さい

826 :デフォルトの名無しさん:2011/01/09(日) 01:05:46
enum classについて言及が無いけどswitchでcaseに列挙子書くとき
型名省略できたりとかできないの?

827 :デフォルトの名無しさん:2011/01/09(日) 09:20:48
>>821
じゃあC#も結局リソースの破棄は手動か?何のためのGCだか。
finallyとかusingとか呼ぶ側で対処するとかダサくない?

828 :デフォルトの名無しさん:2011/01/09(日) 09:42:59
C++なら例えばunique_ptrつかえば、finallyやusingなくても確実にデストラクトできる。
finallyやusingは書き損じのリスクを人がチェックしなきゃならないのがデメリット


829 :デフォルトの名無しさん:2011/01/09(日) 09:58:57
書き損じのリスク程度なら静的解析ツールに診断させりゃいいだけじゃね?

830 :デフォルトの名無しさん:2011/01/09(日) 10:29:02
viだけで書けるようにしてくれ

831 :デフォルトの名無しさん:2011/01/09(日) 11:36:13
>>827
>>818もそうだけど、GCはあくまでメモリ管理の機能だってことわかってないだろ

言語にかかわらずOSリソースは自前で開放しなきゃいけない事を認識するべき
ダサすぎるわ

832 :デフォルトの名無しさん:2011/01/09(日) 11:44:14
C++はデストラクタで解放されるわけだが

833 :デフォルトの名無しさん:2011/01/09(日) 11:47:04
C#もネイティブリソースの扱いには色々頑張っていて
CriticalFinalizerObject
とかあるわけですよ

834 :デフォルトの名無しさん:2011/01/09(日) 12:12:39
C++だとメモリはリソースの一種という扱いだからねぇ

835 :デフォルトの名無しさん:2011/01/09(日) 13:42:13
C++0xこそガラパゴスだよな。
進化の袋小路にはまって未来がない。

836 :デフォルトの名無しさん:2011/01/09(日) 13:45:31
>>835が未来のある言語を教えてくれるらしいぞ

837 :デフォルトの名無しさん:2011/01/09(日) 13:46:23
Java以上のガラパゴスなんかねーよ

838 :デフォルトの名無しさん:2011/01/09(日) 13:51:50
C++に未来がないとしたら、理由はどちらかというと互換性のしがらみだと思うが
move騒動然り

839 :デフォルトの名無しさん:2011/01/09(日) 13:58:33
>>838
だから、互換性捨てろよ
lambda ちゃんだってキーワードひとつでもっとこぎれいな制服になってたはずだ


840 :デフォルトの名無しさん:2011/01/09(日) 14:00:19
キャプチャ考えると結局こんなもんって気もするけどね

841 :デフォルトの名無しさん:2011/01/09(日) 14:28:33
その辺はD&Eを100回読めということで

842 :デフォルトの名無しさん:2011/01/09(日) 14:37:02
むしろラムダは他にやりようあんまりない気がする
参照キャプチャを全く無しにするなら全部コピーキャプチャのみにすることで簡略化できるが

843 :デフォルトの名無しさん:2011/01/09(日) 15:29:47
>>838
互換性のしがらみからの脱却果てしないDを見習おう。

844 :デフォルトの名無しさん:2011/01/09(日) 16:34:10
ユーザーが全くいなければ互換性のしがらみもないな

845 :デフォルトの名無しさん:2011/01/09(日) 16:49:19
つまりD言語最強

846 :デフォルトの名無しさん:2011/01/09(日) 16:56:03
Dはいつ本気出すんだよ

847 :デフォルトの名無しさん:2011/01/09(日) 16:56:54
明日

848 :デフォルトの名無しさん:2011/01/09(日) 17:07:46
Dはいつも全開だよ
目指す方向が間違ってるだけで

849 :デフォルトの名無しさん:2011/01/09(日) 17:14:24
間違ってないよメジャーになる気がないだけだよ

850 :デフォルトの名無しさん:2011/01/09(日) 18:26:24
Dは完成したらメジャーになれると信じている

851 :デフォルトの名無しさん:2011/01/09(日) 18:35:39
いつ完成するんだよ。

852 :デフォルトの名無しさん:2011/01/09(日) 20:10:45
明日

853 :デフォルトの名無しさん:2011/01/09(日) 20:13:10
完成したらDじゃないだろう

854 :デフォルトの名無しさん:2011/01/09(日) 20:23:32
明日っていつだよ

855 :デフォルトの名無しさん:2011/01/09(日) 20:36:07
あしたっていまさッ!

856 :デフォルトの名無しさん:2011/01/09(日) 21:02:34
まあキャプチャリストの必要性も分かるんだが…なんというか、
boost lambda の (*_1 < *_2) みたいなインパクトが無いんだよなあ

857 :デフォルトの名無しさん:2011/01/15(土) 15:34:55
禿げの理屈っぽさにはウンザリ

いいかげんに仕様をきめやがれ

858 :デフォルトの名無しさん:2011/01/15(土) 16:26:06
DやるくらいならC#やってるよ

859 :デフォルトの名無しさん:2011/01/15(土) 18:39:05
>>857
理屈っぽさ自体はいいと思う(禿本おもろいし)
結論がきれいにまとまらないことがもどかしいだけ

860 :デフォルトの名無しさん:2011/01/17(月) 21:37:23
Conceptのちゃぶ台ひっくり返した時も
理屈理屈で笑ってしまったがw


861 :デフォルトの名無しさん:2011/01/17(月) 22:20:40
禿を論破して黙らせるくらいの人材が足りない

862 :デフォルトの名無しさん:2011/01/17(月) 22:27:26
人材を待つより、自動命題論破システムを構築

863 :デフォルトの名無しさん:2011/01/17(月) 22:28:18
俺がやってもいいけど

864 :デフォルトの名無しさん:2011/01/18(火) 20:31:05
期間と予算は?

865 :デフォルトの名無しさん:2011/01/18(火) 22:05:52
>>864
そんなもん、 (期間無 == 限大 && 予算 == ゼロ) にきまっtるじゃん


866 :デフォルトの名無しさん:2011/01/19(水) 09:55:58
理屈はC++が、というか
あるプログラミング言語がまともな言語として
存在するためには必須だろう。

禿がそれを考えていてくれるんだからいいじゃないか。




俺としては
C++0xを2段階に分けてリリースしてほしいけど。
難しそうな所は第2段階目に置いておいて、
ひとまず有用そうで簡単そうなところだけを第1段階目としてリリースしてほしい。

リリースっていう単語の使い方がおかしいか。策定とでもいうべきか。


867 :デフォルトの名無しさん:2011/01/19(水) 20:59:22
C++1x否定ですか

868 :デフォルトの名無しさん:2011/01/19(水) 21:01:15
難しそうなconceptは先送りになったでしょ

869 :デフォルトの名無しさん:2011/01/19(水) 21:07:19
現実はどうあれ98を置き換える規格を作ってるんだから小出しリリースとかアホすぐる発言はよし玉枝

870 :デフォルトの名無しさん:2011/01/19(水) 21:31:59
先などあるのだろうか

871 :デフォルトの名無しさん:2011/01/19(水) 21:37:29
>>866
それやるとコンパイラベンダが文句を付けて来ないか
今も規格が固まってないのに当たり障りない部分から対応してきてるけど

872 :デフォルトの名無しさん:2011/01/20(木) 14:30:45
今でも使わない機能が山盛りなのにこれ以上増やしてどうするのかと思う。
俺達に必要なのは間違えなくC++ーーだ。
C++0xなんか要らない。

873 :デフォルトの名無しさん:2011/01/20(木) 14:50:02
>>872
つ EC++

874 :デフォルトの名無しさん:2011/01/20(木) 21:31:22
あれ気持ちはわかるんだけど極端すぎたのが敗因だな
template や多重継承は残して、virtual や new のほうを何とかして欲しかった
関数ポインタで片付くところはそれでいいしゼロオーバーヘッド原則を有名無実化されるのがいや

言語そのものが巨大オブジェクトのアンチパターンまっしぐらなのがどうもね
これ C++ に限ったことじゃないけど

875 :デフォルトの名無しさん:2011/01/20(木) 22:52:03
>>874
( ゚д゚)ポカーン

876 :デフォルトの名無しさん:2011/01/21(金) 00:52:51
>>872
全員が全部を使う必要なんて無い。
ライブラリを作る人、使う人、カーネル寄りのコードを書く人、それぞれ使う部分使わない部分が違う。
ただ 0x の追加のそれなりの部分は誰にとっても便利だけど。

877 :デフォルトの名無しさん:2011/01/21(金) 06:28:01
てゆーか0xの追加機能っておおむね簡単便利な機能ばっかだと思うんだけど
単純に機能山盛りという意味ではC#の方が遥かに仕様でかいじゃん

878 :デフォルトの名無しさん:2011/01/21(金) 09:47:43
>>872
たとえば使わない機能ってなにさ?

右辺値参照はライブラリ屋さんは必須項目だけとアプリ技術者は特に気にする必要はないし。

879 :デフォルトの名無しさん:2011/01/21(金) 11:01:54
>>877
Move semanticsは今もいろいろバタバタしてるよ、簡単とは言えない。

880 :デフォルトの名無しさん:2011/01/21(金) 11:16:43
使わない筆頭のautoは出世したな

881 :デフォルトの名無しさん:2011/01/21(金) 11:22:35
>>879
決めるのにゴタついてるだけで、決まった後にそれを使うのが難しいようなものじゃないだろ

882 :デフォルトの名無しさん:2011/01/21(金) 11:33:57
>>878
>右辺値参照はライブラリ屋さんは必須項目だけとアプリ技術者は特に気にする必要はないし。

アプリ技術者でも、既存のソース読んだり、自分でクラス作ろうと思ったら知る必要あるのでは?
C++0x はまだ使ってないけど、最近 C++ のプロジェクトに新人が入ってきて、引数の値(コピー)渡しと参照渡しの使い分けとか、いろいろ教えるのが大変すぎる。

>>872
C++ の機能はほとんどが密接に関連してるから、部分的に削るとかは無理。

883 :デフォルトの名無しさん:2011/01/21(金) 11:38:32
>>881
ええっ!?

884 :デフォルトの名無しさん:2011/01/21(金) 15:18:52
C++0x後を見越したTR2ってその後どうなったんだろう。
並行してC++1xに取りかかってほしい。

885 :デフォルトの名無しさん:2011/01/21(金) 19:24:19
0xがFixしたあとだろ

886 :デフォルトの名無しさん:2011/01/21(金) 21:55:46
もう最初からC++2xと言うべき

887 :デフォルトの名無しさん:2011/01/21(金) 23:18:18
VC10のbasic_stringってメモリの連続性保証されてるのでしょうか?

888 :デフォルトの名無しさん:2011/01/21(金) 23:26:18
0xでbasic_string何か変更あったっけ

889 :デフォルトの名無しさん: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().

890 :デフォルトの名無しさん:2011/01/22(土) 13:15:33
あとC++0xでは、arrayとvectorも "The elements ... are stored contiguously," となる。

891 :デフォルトの名無しさん:2011/01/22(土) 14:30:56
vectorはC++03から
arrayはTR1から
"The elements ... are stored contiguously,"だと思うけど

892 :デフォルトの名無しさん:2011/01/22(土) 16:02:34
TRはその名の通りreportでまだ規格の一部じゃない

893 :デフォルトの名無しさん:2011/01/22(土) 23:46:04
>>882
アプリ屋さんでも右辺値参照を知っていれば効率的なコードが書けるね。
まあ、知らなくても十分だけどな。


894 :デフォルトの名無しさん:2011/01/22(土) 23:50:35
constのうんかす

895 :デフォルトの名無しさん:2011/01/23(日) 01:16:44
右辺値参照+コンテナ+unique_ptr=最強

896 :デフォルトの名無しさん:2011/01/23(日) 14:34:59
>>894
constは必須だろうJK

897 :デフォルトの名無しさん:2011/01/23(日) 15:51:00
constは必須というか、Javaはなんでfinalをあんな設計にしちまったんだと思う

898 :デフォルトの名無しさん:2011/01/25(火) 00:34:25
C土土


899 :デフォルトの名無しさん:2011/01/25(火) 08:26:49
やろうと思えばC#のように新しい言語を作って定着させる事は出来る
結局だれも本気でC++の代わりを欲しがってるわけではないんだ

900 :デフォルトの名無しさん:2011/01/25(火) 08:31:30
D is for DoomsDay

901 :デフォルトの名無しさん:2011/01/25(火) 08:58:26
最近の美少女中学生はいろんな意味のC++をしたくてたまりませんヒャッホォウ!(*´Д`)

902 :デフォルトの名無しさん:2011/01/25(火) 09:34:20
いやC++の代わりは本気で欲しい。
シンプルで高速な奴。わりとCが違いが機能が足らん。

903 :デフォルトの名無しさん:2011/01/25(火) 10:16:13
下位互換を保ったままコンパイル時シンボル解決をお利口にすることはできなかったのかなぁ
コンパイル遅くなってもいいからinclude順でウダウダするのはもうやめにして欲しかった
あとはGCの標準が欲しかったくらいかな

C++0xと比べた時にJavaやC#がうらやましく感じるのって個人的にはこれくらいしかない

904 :デフォルトの名無しさん:2011/01/25(火) 11:19:22
include 順については同意だが
GC は死んでもいらん typeid と同類

「言語自身で表現できることは言語に組み込まない」という方針をきっちり貫いて欲しい

placement-new だのファクトリパターンを使うと
普通の new すら邪道に見える

905 :デフォルトの名無しさん:2011/01/25(火) 11:25:49
GCはライブラリを作るためのメカニズムが入った。
include順は今のままで問題ない。

906 :デフォルトの名無しさん:2011/01/25(火) 11:25:50
GCはライブラリの方の標準として欲しかったよ
shared_ptrは便利だけどちょっと力不足で結局俺俺intrusive_ptr作ってる人多いよね
循環回収保障付shared_ptr/intrusive_ptrとかあっても良かったと思うんだ

907 :デフォルトの名無しさん:2011/01/25(火) 11:26:38
>>906
C++0x準拠のコンパイラ出たら出てくるんじゃないの?

908 :デフォルトの名無しさん:2011/01/25(火) 11:27:59
>>907
出てくるだろうけどまたboostでwって話にならんか?

909 :デフォルトの名無しさん:2011/01/25(火) 12:33:25
ええやん!

910 :デフォルトの名無しさん:2011/01/25(火) 12:45:56
>>903
C#のpropertyは割と本気で欲しい

911 :デフォルトの名無しさん:2011/01/25(火) 15:08:43
今どきGCのない言語とか血尿が出るレベル。
これだけで使う気にならない

912 :デフォルトの名無しさん:2011/01/25(火) 15:23:34
そういう人が使う言語じゃない。
ある程度レベル以上の人が使う言語。
C++じゃないと無理な領域(e.g.システムソフトウェア)もあるし。

913 :デフォルトの名無しさん:2011/01/25(火) 16:30:10
結局C/C++やそれ以下の低水準言語でしか
まともなOSとか作れてないんだよね。

低能者、例えば>>911とかだと発狂するのかもしれないけど。



914 :デフォルトの名無しさん:2011/01/25(火) 16:32:40
いやー、やっぱりGCは便利だよ
ただ全てにおいてGCを強要されると逆の意味で血尿が出るが

915 :デフォルトの名無しさん:2011/01/25(火) 16:35:02
>>914
> いやー、やっぱりGCは便利だよ

そういう話じゃないだろw
昔、System VのIPCもGC使って実装してあったよ。


916 :デフォルトの名無しさん:2011/01/25(火) 16:42:53
血尿かと思っていたら初潮を知らなかっただけで悩んで誰にも相談できない美少女中学生ヒャッホォウ!(*´Д`)

917 :デフォルトの名無しさん:2011/01/25(火) 18:52:12
まだ0xなの?

918 :デフォルトの名無しさん:2011/01/25(火) 19:11:22
C++書くやつって変態多いよな
プリムラ大好きとか言うから園芸やってんのかと思ったらエロゲのキャラだったし

919 :デフォルトの名無しさん:2011/01/25(火) 19:33:42
ガベコレ導入するなら言語レベルで寿命管理を出来る仕組み入れて欲しいね。
register指定を高度にしたみたいな

920 :デフォルトの名無しさん:2011/01/25(火) 20:21:35
簡単に無効に出来て、無効設定でうっかり使おうとしたらコンパイルエラーになることが保証されてるような
ガベコレならあってもいい

921 :デフォルトの名無しさん:2011/01/25(火) 22:02:46
GCは次のバージョンで入るんじゃないの?

922 :デフォルトの名無しさん:2011/01/25(火) 22:20:21
ないね
校長先生が生きてる間は

923 :デフォルトの名無しさん:2011/01/25(火) 23:23:54
うむ
C++にGCとかマジ勘弁
メモリコストに鈍感なアホが増えるだけだ

GCを使いたい局面ではC++以外を使えば良いよ

924 :デフォルトの名無しさん:2011/01/25(火) 23:29:53
ライブラリならいいだろ?

925 :デフォルトの名無しさん:2011/01/25(火) 23:31:41
C# の unsafe のように、gc 走る部分は safe つけるとか。
あまり実用性が見えないけど。

926 :デフォルトの名無しさん:2011/01/25(火) 23:40:09
GCほしけりゃDやれD

927 :デフォルトの名無しさん:2011/01/26(水) 02:13:23
>>922
うろ覚えだが、D&Eでは割と好意的な評価じゃなかったっけ?

928 :デフォルトの名無しさん:2011/01/26(水) 02:54:07
ロリコンはまたさっさとアク禁にならねーかな。
しばらく平和だったのに。

929 :デフォルトの名無しさん:2011/01/26(水) 08:27:08
>>927
GCは有用であり考慮に値するが、GCを使わないプログラムの表現力が制限されてはいけない。
理想的なGCが存在するならパフォーマンス問題もなく、またそうする事は可能だと思われる。
しかしそれを考えるのも簡単な仕事ではないので、ユーザのGCに対する関心が高まってくれば
試験的な実装も出てくるだろうから、それを見てから考えよう。
要約するとこんな感じ。

930 :デフォルトの名無しさん:2011/01/26(水) 08:33:59
C++にGC実装なんて可能なの?
ポインタ操作を追跡できるとは思えないんだけど

931 :デフォルトの名無しさん:2011/01/26(水) 09:08:03
>>930
ポインタは回収しなければいい
要するにただの「循環参照回収保障付きshared_ptr」みたいなもの

932 :デフォルトの名無しさん:2011/01/26(水) 12:04:01
保守的GCなら既にあるよな、Gaucheやw3mなどが使ってるBoehm GCとか
Cとの組み合わせでは十分実用になってると思うけど
保守的なのでゴミが残る可能性がある
C/C++の言語仕様ではExactなGCはたぶん無理じゃないの、知らんけど

933 :デフォルトの名無しさん:2011/01/26(水) 12:08:00
マシンがタグアーキテクチャなら可能性はある。

つまり現行の普通のマシンでは絶望的だろう、ということだけど。

934 :デフォルトの名無しさん:2011/01/26(水) 13:30:08
C++はなんでもオーバーロードできるが
ポインタ操作だけはオーバーロードできない
絶望的だと言うのは、つまりそういうことだよな

935 :デフォルトの名無しさん:2011/01/26(水) 14:01:18
え、ていうか既存のポインタがそのままGCで回収されるような話だったの?
てっきりstd::managed_ptr<Hoge> pみたいな話かと思ってたんだが

936 :デフォルトの名無しさん:2011/01/26(水) 18:50:34
シングルトン的なGCを設置してそいつにインターフェース食わせるってかんじになるんかな??

937 :デフォルトの名無しさん:2011/01/26(水) 23:05:59
>>931
weak_ptrがあるから循環参照も解決できるね。
weak_ptrは所有者をはっきりできるからわかりやすくなるね。

938 :デフォルトの名無しさん:2011/01/27(木) 10:17:27
現状*_ptrがあれば全く困らないな

939 :デフォルトの名無しさん: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

面白いとは思う。

940 :デフォルトの名無しさん:2011/01/27(木) 21:45:57
次世代のGCは、仮想化支援の命令をハイパーバイザから使ってるから、VMのないC++には向かないかな。
根拠は不明。

941 :デフォルトの名無しさん:2011/01/27(木) 21:52:19
GC専用のコアを積んでいると仮定した方がよくね?
言語仕様の中だけでやろうとするとどうしてもC#とかJavaとかDめいてくる

942 :デフォルトの名無しさん:2011/01/27(木) 21:54:44
コアそのものの記述にも使う言語でか

943 :デフォルトの名無しさん:2011/01/27(木) 22:00:15
PauselessGC
http://www.infoq.com/jp/news/2010/06/azul_ori
ちなみにこれは商用の興味引くためのハリボテプロジェクトの可能性あり。
別のが実装されても、vmが必要ならclang+llvm経由かなーと思う。

944 :デフォルトの名無しさん:2011/02/02(水) 03:32:01
C1xの方もCD投票に向けたドラフトが出てた
ttp://www.open-std.org/jtc1/sc22/wg14/
こっちはスレ立てるほど注目されてないかな

945 :デフォルトの名無しさん:2011/02/02(水) 07:24:51
どうせまたC2xにすればよかったって事になるんだろ

946 :デフォルトの名無しさん:2011/02/02(水) 19:05:38
C99が既に半分死に規格なんだから今さらだな

947 :デフォルトの名無しさん:2011/02/02(水) 19:33:26
とりあえず立ててみた。
http://hibari.2ch.net/test/read.cgi/tech/1296642667/

948 :デフォルトの名無しさん:2011/02/02(水) 19:41:42
そういえば、このスレもそろそろ次スレの時期だな。
まあ、この流れだと、まだしばらく大丈夫そうだけど。

949 :デフォルトの名無しさん: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

あと一年ちょい。

950 :デフォルトの名無しさん:2011/02/03(木) 19:13:20
1年後にも後1年って言ってそうだな

951 :デフォルトの名無しさん:2011/02/03(木) 19:14:44
いやconcept外して軽くなったし、まとまるでしょ。

952 :デフォルトの名無しさん:2011/02/03(木) 19:28:03
本の虫氏が参考書を発売するのもそのころだな。

953 :デフォルトの名無しさん:2011/02/03(木) 19:39:16
そのころにはまた変わってるんだろうな

954 :デフォルトの名無しさん:2011/02/04(金) 07:53:50
永久に本も完成しないのか

955 :デフォルトの名無しさん:2011/02/04(金) 07:58:54
あんまり伸びると本の虫氏が餓死しかねん

956 :デフォルトの名無しさん:2011/02/04(金) 12:48:54
その時には、C++0x本に「本の虫死追討」という帯を着けるよ。

957 :デフォルトの名無しさん:2011/02/04(金) 13:33:06
追い討ちをかけるなよw

958 :デフォルトの名無しさん:2011/02/04(金) 23:57:54
何も完成版じゃなくても、策定途中版でも出せばいいのにな。

何で完成版にこだわるのか意味不明だ。

959 :デフォルトの名無しさん:2011/02/05(土) 00:13:30
途中で仕様が変わってゴミになるかもしれないのに
そんなの買う人いるの?

960 :デフォルトの名無しさん:2011/02/05(土) 00:22:21
ゴミになるかもしれない知識に10960のレスが付いているわけだ。

961 :デフォルトの名無しさん:2011/02/05(土) 00:32:57
最終的な仕様ではなく途中経過にも価値はある罠

962 :デフォルトの名無しさん:2011/02/05(土) 00:56:55
買う気がない人は何とでもいえるだろう

963 :デフォルトの名無しさん:2011/02/05(土) 01:02:09
できれば紙の本として\5,000くらいで出てくれるとありがたいんだが。

964 :デフォルトの名無しさん:2011/02/05(土) 01:12:06
ロングゲートから出るの?

965 :デフォルトの名無しさん:2011/02/05(土) 03:32:02
>>958
VC6の悪夢を繰り返してはならない・・・と言いたいが
既に2010で同じ事が起こりそう

966 :デフォルトの名無しさん:2011/02/05(土) 09:23:55
とっとと実装しろ派 vs 中途半端な物を実装するな派
に挟まれて苦悶するMS

967 :デフォルトの名無しさん:2011/02/05(土) 09:44:15
お前らは参考書の話をしているのか、それともコンパイラの話をしているのかどっちなんだ。

968 :デフォルトの名無しさん:2011/02/05(土) 10:28:18
VCのC++0x機能対応一覧表みたいなのってなかったっけ

969 :デフォルトの名無しさん:2011/02/05(土) 13:49:08
>>968
http://wiki.apache.org/stdcxx/C++0xCompilerSupport

970 :デフォルトの名無しさん:2011/02/06(日) 13:40:23
>>968
http://www.aristeia.com/C++0x/C++0xFeatureAvailability.htm
の一番下の"Language"をクリック。

971 :デフォルトの名無しさん:2011/02/20(日) 21:20:31.02
ここもすっかり静かになってしまったな。ところで校長先生の本はまだかな。去年の年末に校了という話を見たんだが。

972 :デフォルトの名無しさん:2011/02/22(火) 11:47:50.44
ラムダ関数で自己再帰関数が出来ません。
どうやったらできますか?
お願いします。

973 :デフォルトの名無しさん:2011/02/22(火) 12:26:31.20
>>972
ラムダは関数ではなくて式です。諦めな。
どうしてもやりたいなら、
_ = lambda x: x if x == 0 else _(x-1)
_(3)
とか。

974 :デフォルトの名無しさん:2011/02/22(火) 13:40:59.53
>>973
後半のコードの説明お願いします。

975 :デフォルトの名無しさん:2011/02/22(火) 14:32:50.12
なにこれPython?

976 :デフォルトの名無しさん:2011/02/22(火) 14:34:13.35
どうみてもPythonです本当に

977 :デフォルトの名無しさん:2011/02/22(火) 14:47:03.10
>>972
named lambdaがない現状では、キャプチャーするstd::functionのオブジェクトに、クロージャーオブジェクトを入れておくしかない。

std::function<void(void)> f ;
f = [&]() -> void { f() ; } ;
f() ;

978 :デフォルトの名無しさん:2011/02/22(火) 19:29:48.70
引数に自分自身のラムダを渡すとか?

979 :デフォルトの名無しさん:2011/02/22(火) 19:57:46.27
C++0xF

980 :デフォルトの名無しさん: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;
}

981 :デフォルトの名無しさん:2011/02/23(水) 02:13:09.81
>>980
new が入ってる時点でオーバーヘッドもクソもあんのか?
とは思うけど、 std::make_shared() 使うとか、あるいは std::unique_ptr 使うとかして
軽くすることはできそうに見える。

982 :デフォルトの名無しさん:2011/02/23(水) 04:05:37.83
すみません、内部でnewしているのは確かに全く頓珍漢な例でした。
あと先の場合はstd::unique_ptrで良いのですね。ありがとうございます、勉強になりました。

ごめんなさい。書き直します。
以下のような値返しの非インライン関数を、呼び出し元へ最も処理コストを少なく返したい場合、
この関数または呼び出し元などで、C++0xでの特別な書き方が必要になるのでしょうか?

Hoge Moge::getHoge()
{
Hoge hoge;
hoge->hige();
return hoge;
}

983 :デフォルトの名無しさん:2011/02/23(水) 04:25:04.71
Hogeがmove可能ならばNRVOが行われないときmoveされるので
そのままでいい

984 :デフォルトの名無しさん:2011/02/23(水) 12:48:21.58
shared_ptrと違って、weak_ptrは比較演算子が無いの?
現在の規格上そうなっている?うーん、利用側で勝手に定義していいもの?

985 :デフォルトの名無しさん:2011/02/23(水) 13:42:07.05
weak_ptrはそのまま使うものじゃねえよ
shared_ptrに格上げしてから使うもんだ

986 :デフォルトの名無しさん:2011/02/23(水) 13:56:21.31
weak_ptrのままだと比較演算してる最中に消滅してもおかしくないわけだしな

987 :デフォルトの名無しさん:2011/02/23(水) 18:52:19.89
メンバーもしくは、クラスの外に吐き出すならshared
ローカルから全く出る可能性がないならweakでいいんじゃねえの?
ついでに聞くけど、自動変数として確保したオブジェクトを
管理してくれるスマポって無いの?
自動変数が解放されそうになったら、ヒープにコピーしてくれるとか。


988 :デフォルトの名無しさん:2011/02/23(水) 19:05:37.48
最初からヒープに確保するのじゃダメなのか

989 :デフォルトの名無しさん:2011/02/23(水) 19:22:30.68
>>972
thisポインタ経由じゃできないのかな?
this->operator()とか

990 :デフォルトの名無しさん:2011/02/23(水) 19:33:09.67
>>988
argvのような引き渡される形のポインタがあって400万とかデータが
入ってる。こんなもんコピーしたく無いじゃん。
でもこれをスマポを引数に取るクラスに渡したいんだよ。
状況によっては、スマポを引き渡すオブジェクトは、
オブジェクトを生成した関数の中で死ぬ。
最初からヒープにコピーするの無駄じゃん?



991 :デフォルトの名無しさん:2011/02/23(水) 19:40:40.05
>>990
最初にデータを用意するところから全部ヒープでやれって話では?

992 :デフォルトの名無しさん:2011/02/23(水) 20:14:45.84
argcが400万とか胸が熱くなるな

993 :デフォルトの名無しさん:2011/02/23(水) 20:21:06.89
vectorとかで内部的にはヒープに確保されてるとかそんなオチな気がする
make_shared<T>(std::move(...))とかでヒープにmoveさせればいんじゃね?

994 :デフォルトの名無しさん:2011/02/23(水) 21:08:32.91
>>987
こういう用途ならunique_ptrが適当に見えるけどね。
返り値にしなければ自動破棄されるし、返り値にすればmoveされるだろう。
もちろんデータのメモリはヒープにおくことになるが。

995 :デフォルトの名無しさん:2011/02/23(水) 21:14:31.97
argc400万ワロタ

996 :デフォルトの名無しさん:2011/02/23(水) 21:42:43.50
ラッパクラス作ってそれを動的に確保すればいいんじゃないの

997 :デフォルトの名無しさん:2011/02/23(水) 22:05:39.41
そもそも400万とかスタックに入らんだろ

998 :デフォルトの名無しさん:2011/02/23(水) 22:51:08.52
argvだけで16MBか

999 :デフォルトの名無しさん: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 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

205 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)