C++0x 5 - 暇つぶし2ch

C++0x 5 at TECH

1:デフォルトの名無しさん
09/01/20 23:10:49
The C++ Standards Committee
URLﾘﾝｸ(www.open-std.org)

wikipedia
Wikipedia項目ﾘﾝｸ

C++0x
ｽﾚﾘﾝｸ(tech板)
C++0x 2
ｽﾚﾘﾝｸ(tech板)
C++0x 3
ｽﾚﾘﾝｸ(tech板)
C++0x 4
ｽﾚﾘﾝｸ(tech板)

2:デフォルトの名無しさん
09/01/20 23:12:09
　　　　　　　　　　　　　　　　　　　　　　　　　　rへ＿＿　 __
　　　　　　　　　　くヽ　　l^ i　　　　　　　　　／: : : : : : : : Y: :ヽ
　 ┏┓　 ┏━┓＼＼l　 l.　　　　　　　／: :.／ l: :.lヽ: : :ヽ: : :ヽ.　　　　　　　 ┏┓┏┓┏┓
┏┛┗┓┃┏┓┃　＼＼.l　　　　　　 //: :/ノ　 l: :ト､ヽ: : :',: : :. ',　　　　　　 ┃┃┃┃┃┃
┗┓┏┛┃┗┛┃┏━ ＼＼━━/ l: :/ ○　丶l ○ l: : :ﾊ: : : :',━━┓┃┃┃┃┃┃
┏┛┗┓┃┏┓┃┃　　　＼＼. ＿/: :l: :l＠┌‐┐ ＠ l: :/: :l: : : :.',.　　　　　┃┃┃┃┃┃┃
┗┓┏┛┗┛┃┃┗━━ ＼/:::::::＼ヽl.＼ | 　 !　　 /:/／ l: : : :..ｉ ━━┛┗┛┗┛┗┛
　 ┃┃ 　　　 ┃┃ 　　　　　 {:::::::::::::::::`Ｔ７└‐┴‐＜　　　ｌ: : : :. ｌ　　　　　　┏┓┏┓┏┓
　 ┗┛ 　　　 ┗┛ 　　　　　 `r─‐┼-/l／l／/ 01i,　　l: : : : : l.　　　　　 ┗┛┗┛┗┛
　　　　　　　　　　　　　　　　　　　 /: : : : : : | /:/: l: : : :Y:::::::l　　l: : : : : :.l
　　　　　　　　　　　　　　　　　　　,': : : : : :.／ /: /: : : : l:::::::::l.　 l: : : : : : l
　　　　　　　　　　　　　　　　　 i: : : : : く／レへ: : : : l::::::::::',.　!: : : : : : l
　　　　　　　　　　　　　　　 l: : : : : : :＼:::::::::::ヽイ:::::::::::::〉l: : : : : : : l
　　　　　　　　　　　　　　　　　　 l: : : : : : : : :ト､:::::::::::::::>ｔｊｔｊｔｊﾉ l: : : : : : : :l
　　　　　　　　　　　　　　　　　　 ',: : : : : : : :/├‐┤|─ '"|　　 l: : : : : : : :l
　　　　　　　　　　　　　　　　　　　ヽ: : : : ／　.l:::::::| l:::::::::::l　　 ',: : : : : : :,'
　　　　　　　　　　　　　　　　　　　　＼:/　　 l:::::::l |::::::::::l　　　ヽ:: : : : /

3:デフォルトの名無しさん
09/01/20 23:13:44
janeの隠し機能

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

4:デフォルトの名無しさん
09/01/20 23:14:54
mailing 2008
URLﾘﾝｸ(www.open-std.org)

最新ドラフト
URLﾘﾝｸ(www.open-std.org)

Status of Experimental C++0x Support in GCC 4.3
URLﾘﾝｸ(gcc.gnu.org)
ConceptGCC
URLﾘﾝｸ(www.generic-programming.org)

Boost
URLﾘﾝｸ(www.boost.org)

5:デフォルトの名無しさん
09/01/20 23:15:41
試してないけど、スレに書き込みされるんかな
いつもAlt+Wで書き込んでるんでたまに普通のブラウザ使うと一瞬戸惑う

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

7:デフォルトの名無しさん
09/01/20 23:19:56
なんと失敬な！
スレがクソな訳じゃない。クソなのは（以下閲覧済み

8:デフォルトの名無しさん
09/01/20 23:21:27
閲覧済みって何だよ
とセルフ突っ込み。

9:デフォルトの名無しさん
09/01/20 23:22:52
俺は閲覧したね！

10:デフォルトの名無しさん
09/01/20 23:31:03
conceptの前に閲覧が来る！
これは乙じゃないんだからね！

11:デフォルトの名無しさん
09/01/20 23:33:15
【あたらしいきのう】

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

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

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

12:デフォルトの名無しさん
09/01/20 23:34:58
エラーメッセージは置いとくとして0xから現行C++への変換は簡単にできそうだな。

13:デフォルトの名無しさん
09/01/21 10:00:52
concept_map使ったコードは無理だろ。

14:デフォルトの名無しさん
09/01/21 11:56:54
　　　　　　　／/
　　　　　／　 /　　　ﾊﾟｶｯ
　　　　 //⌒)∩＿＿∩
　　　　/.|　.| ノ　　　　　ヽ
　　　 /　|　| 　●　　　● | 　　　　
　　　/ 　|　彡　　( _●_)　ミ　まピョーん☆
　　 /　　|　ヽ　　|∪|　　/＿
　　/／　│　　　ヽノ　　＼／
　　"￣￣￣￣￣￣￣（..ノ

15:デフォルトの名無しさん
09/01/21 11:57:18
　 , ._., ...
　‘^^’

16:デフォルトの名無しさん
09/01/23 17:43:19
>>13
ラッパークラスを仕込むようにすれば何とか

17:デフォルトの名無しさん
09/01/23 18:08:04
C++0xってC++のマクロなんでしょ？
C++ってCのマクロなんでしょ？
Cってアセンブリのマクロなんでしょ？
アセンブリって機械語のマクロなんでしょ？
機械語って演算回路のマクロなんでしょ？
演算回路って電子の移動のマクロなんでしょ？
電子の移動ってクォークの作用のマクロなんでしょ？
クォークの作用って量子論のマクロなんでしょ？

18:デフォルトの名無しさん
09/01/23 18:09:15
＞演算回路って電子の移動のマクロなんでしょ？
ここから先が全然違う

19:デフォルトの名無しさん
09/01/23 18:10:53
ごめんね

20:デフォルトの名無しさん
09/01/23 23:13:30
電子はレプトンだろw

21:デフォルトの名無しさん
09/01/24 09:39:51
演算回路ー論理回路ーNANDゲート-電子回路

22:デフォルトの名無しさん
09/01/24 12:37:24
wwwwwwwwwwwwwwwwwwwwwwwww

23:デフォルトの名無しさん
09/01/24 13:45:07
>>19でごめんねって出てるだろ。赦してやれよ。それともこんなジャンキーな書き込みすら無視できないほどお前らは小さい人間なのか？
まぁ俺が>>19だけどね。

24:デフォルトの名無しさん
09/01/24 15:29:46
>>23
許す

25:デフォルトの名無しさん
09/01/24 18:20:22
かどうかは金しだい。

26:デフォルトの名無しさん
09/01/25 14:11:06
>>17
> クォークの作用って量子論のマクロなんでしょ？
これはちゃわんか？

27:デフォルトの名無しさん
09/01/25 14:12:25
それ以前に全部違う

28:デフォルトの名無しさん
09/01/25 14:45:20
＞C++ってCのマクロなんでしょ？
こんな超越的マクロが有るんだったらほしいかもな

29:デフォルトの名無しさん
09/01/25 15:18:05
まっくろクロ助は何のマクロですか？

30:デフォルトの名無しさん
09/01/26 00:28:35
どっちかっていうとミクロ。

31:デフォルトの名無しさん
09/01/26 02:38:20
thisポインタをスマートポインタにする機能が欲しいよな！

32:デフォルトの名無しさん
09/01/26 02:48:33
>>31
enable_shared_from_thisで我慢してください。

33:デフォルトの名無しさん
09/01/26 03:01:19
一番根元にクラスしこむのは自作でもやったことあるんだが
いまいちスマートじゃないんだよなぁ。

34:デフォルトの名無しさん
09/01/26 09:18:54
C++0xってフランケンシュタインみたいだよね

35:デフォルトの名無しさん
09/01/26 09:21:22
もうCOBOLを笑えないよ

36:デフォルトの名無しさん
09/01/26 10:33:13
なぜ？

37:デフォルトの名無しさん
09/01/26 10:45:47
型理論的にも最先端なんだが
COBOLと違って

38:デフォルトの名無しさん
09/01/26 11:03:27
Lisp最強でいいよ^^

39:デフォルトの名無しさん
09/01/26 12:45:21
>>37
そんなの現場は望んでない。
最先端で効率が下がったらいみねーよ

40:デフォルトの名無しさん
09/01/26 12:53:18
>>39
つ COBOL

41:デフォルトの名無しさん
09/01/26 14:39:58
理論のおかげで効率はよくなってる。

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

42:デフォルトの名無しさん
09/01/26 15:34:17
×最先端
○最末端

43:デフォルトの名無しさん
09/01/26 17:49:35
多分、頭数だけたくさん用意しといて
人月で積算するときの「効率」だろ。

44:デフォルトの名無しさん
09/01/26 19:12:51
だからJava or C#最強なんですね

45:デフォルトの名無しさん
09/01/26 19:47:57
>>41
ソースは？
ソース出せよ！

46:デフォルトの名無しさん
09/01/26 22:16:59
だから、Java or C# が普及してるだろ。

47:デフォルトの名無しさん
09/01/27 00:27:11
JavaもC#も実用している現場見たこと無いな。
研究用のおもちゃとしてなら使うこともあるけど。

48:デフォルトの名無しさん
09/01/27 00:28:34
おまえ、ケータイもみたことないのかよ。

49:デフォルトの名無しさん
09/01/27 00:30:48
Javaってあのfinallyとかいう劣化デストラクタを毎回毎回手で書いてる間抜けな言語？

50:デフォルトの名無しさん
09/01/27 00:40:08
いいえ。あれは劣化デストラクタですらない、Cでfreeをきちんと書くのと同じこと。
C#のusingこそ（いい意味で）劣化デストラクタと呼べる存在だ。後発だけあってJavaより賢い。

51:デフォルトの名無しさん
09/01/27 00:47:28
Cで言えばgotoでエラー処理ルーチンに飛ばすようなもの

52:デフォルトの名無しさん
09/01/27 00:48:28
いや例えないでいいから

53:デフォルトの名無しさん
09/01/27 00:52:25
>>47
最近、サーバーサイドの案件はほとんどJavaかC#よ。
Windows Server 使えるならC# 1択。

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

54:デフォルトの名無しさん
09/01/27 21:50:11
>>50
usingがいいのはわかる。
でも、インデントつかブロックが深くなって
しまうーところがかなりイヤ。

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

55:デフォルトの名無しさん
09/01/27 21:56:00
D の scope キーワード最強だろ。

56:デフォルトの名無しさん
09/01/27 22:54:32
>>47
脳内の現場や脳内の研究の話をされても…

57:デフォルトの名無しさん
09/01/28 08:46:59
>>56
一方的に脳内認定されてもな。

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

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

58:デフォルトの名無しさん
09/01/28 08:47:01
>>55
Dってだけでよわい。

59:デフォルトの名無しさん
09/01/28 13:05:25
>>57
＞自分の周りは何処いっても同じようなもの。
もっと見聞を広めたほうがいい。

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

60:デフォルトの名無しさん
09/01/28 13:59:15
>>57
実行速度とメモリ効率だけならFORTRAN以外の選択肢は無いな…
C/C++含めて、FORTRAN以外が選択されることがあるのは、それだけが言語の選択基準じゃないってことだと思うんだが

61:デフォルトの名無しさん
09/01/28 22:48:26
でも最近はC++も見直されつつあると思う

62:デフォルトの名無しさん
09/01/28 23:34:59
>>60
Pascal

63:デフォルトの名無しさん
09/01/28 23:40:09
JAVAが実用じゃないといってる時点でもアウトだろ。

64:デフォルトの名無しさん
09/01/28 23:43:04
でもJavaは嫌い

65:デフォルトの名無しさん
09/01/29 00:08:22
つーかcontrol invocation syntaxがC++にも欲しい。
Javaより先に入れちゃえと言いたいところだけど、
もう閉じちゃったから10年後なんだよな orz

66:デフォルトの名無しさん
09/01/29 03:20:14
>>47だけみて誤解されているようだけど、別にJavaやC#が
実用的でないといっている訳ではないよ。

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

67:デフォルトの名無しさん
09/01/29 08:36:42
>>66
「分野による」って話だと、
.NET やら Java VM 移植されてない環境だってあるわけだし、
組み込みだと未だCだし、
>>47 みたいな書き方するまでもなく、自明な話なんだが。

68:デフォルトの名無しさん
09/01/29 20:27:40
>>65
いらん。
これ以上、デブにしてどうするよ？

69:デフォルトの名無しさん
09/01/29 21:04:52
デブに穴欄よ

70:デフォルトの名無しさん
09/01/29 22:43:27
語れるほど経験を積んでないのに無理するから

71:デフォルトの名無しさん
09/01/30 08:40:04
GCC 4.3.3 の tr1 見たらもうバリバリ Variadic Template 使ってんのな

72:デフォルトの名無しさん
09/01/30 09:17:28
それがどうしたハゲ。

73:デフォルトの名無しさん
09/01/30 11:14:42
誰がハゲだと！？もう一度言ってみろ！！

74:デフォルトの名無しさん
09/01/30 12:32:40
>>73
0x対応の第4版早く書けハゲ

75:デフォルトの名無しさん
09/01/30 13:08:20
そんなに褒めてやるなよ。

76:デフォルトの名無しさん
09/01/30 18:03:36
メタプログラミング厨が喜びそうな機能を真っ先に入れるあたりはやっぱりGCC

77:デフォルトの名無しさん
09/01/30 19:56:09
ハゲがデブい言語を御所望ですね。
臭くね？

78:デフォルトの名無しさん
09/01/31 16:07:56
>>53
> お客様にランタイムインストールしてもらわなきゃとか気にしなくていいし。
なぜかVBのランタイムなら入れてやってもいいという客が多い。

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

80:デフォルトの名無しさん
09/01/31 23:03:55
vbに比べたら.netの方がマシだな。作る側としては。
使う側としては.netの方がランタイムが大きい分、抵抗ありそう。

81:デフォルトの名無しさん
09/01/31 23:10:05
色々思うところはあるがスレ違いはそろそろ・・・

82:デフォルトの名無しさん
09/01/31 23:14:01
あぶねえ。
.netランタイムは複数バージョンを同居させないといけないのが気に食わない
と書いてしまうところだった。
サンクス>>81

83:デフォルトの名無しさん
09/02/01 00:59:08
VBに比べたらC++/CLIのほうがましだといいたいんですね、わかります。

84:デフォルトの名無しさん
09/02/01 01:22:38
C++/CLIは割と良くできてると思うんだ

85:デフォルトの名無しさん
09/02/01 01:25:44
^ とか勘弁して欲しい

86:デフォルトの名無しさん
09/02/01 01:37:15
__gc*よりはましだぜ。

87:デフォルトの名無しさん
09/02/01 01:48:05
C++/CLI 使った事無いんだけど

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

って可能なの？

88:デフォルトの名無しさん
09/02/01 01:52:39
できるけど、そのままだと安全じゃないよ

89:デフォルトの名無しさん
09/02/01 01:58:11
広義の弱い参照になるって話？
まあ、ダングリングポインタ自体は元々危険だから
改めて気にすることは無いと思うけど。

90:デフォルトの名無しさん
09/02/01 02:13:41
C++/CLI使ってるやついないだろ。川俣もC#に戻ったし。

91:デフォルトの名無しさん
09/02/01 04:02:09
MSオンリーでなければ手を出すんだがな。
プロパティーとか、属性とかMS臭いすぎる仕様が気に食わん。

92:デフォルトの名無しさん
09/02/01 08:51:23
プロパティはもともとデルファイのものでは。
属性は Java にも Annotation 付いたし。
MSはほんと後だしじゃんけんでいい物作るよ。

93:デフォルトの名無しさん
09/02/01 09:00:46
C#はもともとMSがDelphiの開発者を引き抜いてきて作ったものだからな

94:デフォルトの名無しさん
09/02/01 10:29:48
MSに引き抜かれた技術は全部「MS臭い」といわれるんですね。
分かります。

95:デフォルトの名無しさん
09/02/01 11:41:06
ウンコなすりつけられた奴が全員ウンコ臭いのは事実

96:デフォルトの名無しさん
09/02/01 15:03:48
MSの属性は元を辿ればMIDLだろう。
その後、いつだか忘れたけど、ATL属性プログラミングといって、MIDLの属性の構文をVC++に持ち込んだ。
その構文がマネージドC++やC++/CLIにも引き継がれて今に至る。

97:デフォルトの名無しさん
09/02/01 15:05:38
F#やIronPythonやIronRubyがあるからOCamlやPythonやRubyもMS臭いのですね

98:デフォルトの名無しさん
09/02/01 15:17:26
>>66
最初から誤解される書き方しかできない知能しか持ち合わせていないカスが、プログラミング言語を語るとは・・・
コンピューターの前に座ってばっかりじゃなくて、たまには人間と会話した方がいいぞ

99:デフォルトの名無しさん
09/02/01 17:57:10
で、0ｘの次の標準の主なネタは何？

100:デフォルトの名無しさん
09/02/01 18:04:59
まず念願のGCだな
あと多重ディスパッチとかyieldとか
メタコンセプトもどうせ作るんだろうな
あとは何だ

101:デフォルトの名無しさん
09/02/01 18:25:55
標準ライブラリの完全なconcept化

102:デフォルトの名無しさん
09/02/01 18:32:10
tr2てのはC++0xの次って事でいいの？

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

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

104:デフォルトの名無しさん
09/02/01 19:59:30
それは他の人／団体／企業がやってるよ。

105:デフォルトの名無しさん
09/02/01 20:26:24
意味はあるだろ
C++を使ってる俺が嬉しい

106:デフォルトの名無しさん
09/02/01 20:27:43
コンパイラ作る側がひぃひぃ言って
サポートが遅れてもあんまり意味が無いからなあ

107:デフォルトの名無しさん
09/02/01 20:45:47
>>103
何そのD言語

108:デフォルトの名無しさん
09/02/01 21:11:31
MS付きのC++/CLIでさえあの体たらくだというのに…

109:デフォルトの名無しさん
09/02/01 21:19:19
D言語もGCあるからなあ・・・
常に scope を使えばいいのかもしれないが、なんだかな・・・

110:デフォルトの名無しさん
09/02/01 21:20:10
>>109
D言語でもGCを止めて、C++のように書くことはできる。

111:デフォルトの名無しさん
09/02/01 21:28:30
スコープにとらわれないタイミングで delete できるの？

112:デフォルトの名無しさん
09/02/01 21:38:00
>>111
普通にC++のようにdeleteすればいい。

113:デフォルトの名無しさん
09/02/01 21:54:39
delete できるのか。
いいね、それ。

114:デフォルトの名無しさん
09/02/02 00:49:28
C++はそろそろコンストラクタとデストラクタの前と後に呼び出される処理をデフォルトで追加するべきだな。
ファクトリー関数とかだるすぎる。

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

115:デフォルトの名無しさん
09/02/02 01:05:44
>>114
before-daemon, after-daemonｷﾀｰ!

116:デフォルトの名無しさん
09/02/02 02:09:14
コントラクトとかアスペクトとか、
そういうのは入らんのか。
テンプレートにちょっといろいろ
たすだけでできそうだが。

117:デフォルトの名無しさん
09/02/02 02:59:18
その辺研究した上でconceptに昇華された。
AspectJ, Eiffel, ML, Haskell辺りの型システムを、
型の専門家が研究した成果を取り入れてる。

118:デフォルトの名無しさん
09/02/02 08:53:22
さあ！みんなDゲンガーになろう！

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

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

120:デフォルトの名無しさん
09/02/02 20:05:08
C++って、もともとCのソースをつくるだけだったんだぜ。

121:デフォルトの名無しさん
09/02/02 22:53:18
例外で破綻したけどな

122:デフォルトの名無しさん
09/02/03 04:26:09
>>103
C++の構文解析って、今はすべて手書きらしいね
こういうことがC++の将来に悪い影響を与えそうな気がする
構文を書き換える時期に来ているのかもしれない

123:デフォルトの名無しさん
09/02/03 04:52:16
たしかに、C++は複雑だからという理由も大いにあるだろうけど、
ほかの綺麗な言語でも高速な解析を目指せば自ずと自前で解析するだろうし、
何より今更そんな気にすることか？と思う。

124:デフォルトの名無しさん
09/02/03 08:36:01
確か、IronPythonとかも手書きって話だったと。

125:デフォルトの名無しさん
09/02/03 09:18:53
使わない仕様とか、勝手にエゴで古いコードの書き方を意味もなく変えたり。
バカだなぁと思う。

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

126:デフォルトの名無しさん
09/02/03 09:20:41
なぜ？

127:デフォルトの名無しさん
09/02/03 09:22:14
>>126
カッコまでが言語仕様だから。
カッコなしで通るなら、スペースを開けるのが正しいと思う。

128:デフォルトの名無しさん
09/02/03 09:24:03
いやお前の文章の意味が分からん。
「騙されてる」の主語は誰だよ？
「ifとカッコの間にスペース開ける奴」が「騙されてるよなぁー」だと思ったぞ。

129:デフォルトの名無しさん
09/02/03 09:25:06
>>128
スペース開けてる奴は、騙されてるよ。

130:デフォルトの名無しさん
09/02/03 09:29:50
恥ずかしい言語仕様を隠すためだけに、権威筋が言い始めたのを真に受けて従ってるわけだろ？
騙されてなけりゃ、単なるバカ。

131:デフォルトの名無しさん
09/02/03 09:33:02
自分の口からだだ漏れ状態の上から目線に興奮冷めやらぬのはわかったけど、
もうちょっと具体的に説明しないとただの電波さんｗ

132:デフォルトの名無しさん
09/02/03 09:46:14
どう見てもただの基地外さんだろ。　文章の意味が全く通っていない。

133:デフォルトの名無しさん
09/02/03 09:46:41
いやぁ、どう説明しても只の電波だろ。片や「騙されてる」と言いながら、片や「正しいと思う」だし。

134:デフォルトの名無しさん
09/02/03 10:00:46
その辺はスルーして、
C++の構文解析は自然言語構文解析並みwと書いた人が以前いたが、
(g++のMLだったか?)
最近手でパーザを書くのが結構流行っているのは、
エラー処理をきちんとやりたいから。

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

135:デフォルトの名無しさん
09/02/03 10:11:05
>>134
理屈はわかるが、いざ自分がそのパーサを書く係になったらと思うとぞっとするな。

136:デフォルトの名無しさん
09/02/03 10:42:34
エラー処理、得にエラー表示は、UIに属することだからね。
GUIで、入力足りないと、ダイアログウィンドウ出して、
入力してないフィールドを赤く表示して入力を促し、
側に警告も表示するっての似て、手間ばかり多いね。

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

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

137:デフォルトの名無しさん
09/02/03 15:50:22
手で書かなくてもエラー処理をまともにする方法はある気はするんだけどなぁ
parser combinatorとか使ってコード量を10分の1ぐらいにできないのかなぁ

138:デフォルトの名無しさん
09/02/03 18:19:38
>>125
あなたはreturnにカッコを付ける人ですね
分かります

139:デフォルトの名無しさん
09/02/03 18:27:17
相談室もだが、今日は変なやつがいるな
もしかして同じ人？

140:デフォルトの名無しさん
09/02/03 18:41:11
>>137
簡単なんでいいから一回パーサーを
書いてみろ。
気のきいたエラー処理がどれだけ
めんどくさいものか体感するべき。

141:デフォルトの名無しさん
09/02/04 00:26:20
>>139
最近あちこちで電波垂れ流してる脳内住人が出没してる。
ここのスレにも、見てわかるとおり。多分同一人物だろうな。

142:デフォルトの名無しさん
09/02/04 00:31:07
パーサのエラー処理は地獄だよ

143:デフォルトの名無しさん
09/02/04 00:38:09
エラー1つ検出して終わりなら大分楽だが
今時そんなコンパイラじゃ誰も使ってくれないだろう。

144:デフォルトの名無しさん
09/02/04 00:39:41
むしろコンパイル速度さえ爆速であればエラーを一つ検出して終わりというコンパイラもアリだと思う。

145:デフォルトの名無しさん
09/02/04 00:48:25
this -> m_Hoge = 10;

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

146:デフォルトの名無しさん
09/02/04 00:57:46
>>144
連鎖的にエラーが出る事が多いから、
結局最初の１つくらいしか見ないとか多いしな。
そこ直したらもっかいコンパイルした方がエラーが見やすいし。

147:デフォルトの名無しさん
09/02/04 01:07:22
権威にはからきし弱い、太鼓持ち。

148:デフォルトの名無しさん
09/02/04 02:10:26
じゃあ柔軟なエラー処理ができ、かつ簡潔で速度もそこそこ出るパーザの実装手法を考案して有名になってやる

149:デフォルトの名無しさん
09/02/04 12:49:40
期待してるよ

150:デフォルトの名無しさん
09/02/04 12:53:03
このスレで宣言するからにはC++0xのパーザも。

151:デフォルトの名無しさん
09/02/04 18:39:36
しかし改めて思うがひっでー文法だな
特にdeclarationまわり

152:デフォルトの名無しさん
09/02/04 23:54:43
varとかtypeとかfunctionとかのキーワードがないのに合わせて、
typedefが止めを刺した感じ。
classやtemplateやcoceptはキーワード付けてくれて本当に良かったよ。

153:デフォルトの名無しさん
09/02/05 11:08:28
>>152
何かで見たけど、キーワードはできるだけ
追加しないってのがポリシーなんだよね。

154:デフォルトの名無しさん
09/02/05 11:14:40
>>138
わかってないな。
省略できるから、つけようがつけまいが自由なんだぞ。
単にあのかっこも、一時期のバグ回避だし。

155:デフォルトの名無しさん
09/02/05 11:45:46
どうでもいいことで盛り上がるなこのスレ

156:デフォルトの名無しさん
09/02/05 11:54:32
馬鹿が必死になるから挑発しないでくれ

157:デフォルトの名無しさん
09/02/05 12:00:29
というか、どうでもいいことだから盛り上がる

158:デフォルトの名無しさん
09/02/05 12:12:45
ごめんなさい…

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

160:デフォルトの名無しさん
09/02/08 20:33:08
return って、20年以上前の大昔には実際に関数だったとかじゃなかったっけ？
ANSI 以前の。

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

161:デフォルトの名無しさん
09/02/08 20:35:06
未だにflex/bisonみたいな古いツールの解説では旧形式の関数定義があったりするな。

162:デフォルトの名無しさん
09/02/08 22:26:28
>>160
＞return って、20年以上前の大昔には実際に関数だったとかじゃなかったっけ？
それはない。exit()の実装と勘違いしていないか?

163:デフォルトの名無しさん
09/02/08 22:51:35
>>160
このレスは全て間違い。以下無視するように。

164:デフォルトの名無しさん
09/02/08 22:56:56
C FAQを当たってみたけど、
URLﾘﾝｸ(www.kouno.jp)
> 20.19:
> returnの後ろに来る式をくくるカッコは本当に省略可能か。
> A:
> 省略可能だ。
> 大昔、Cの初期には、必要であった。そのころにCを学んだ人がたくさんいるし、
> そのころ書かれたコードが今でも世の中に出まわっている。それでカッコが
> 今でも必要であるという考えが広まっている。
ということで、昔は必要だった(が関数ではない)ってのが正しいようだ。

165:デフォルトの名無しさん
09/02/09 00:52:05
ifとかwhileが関数ではないけど括弧が要るってのと同じことだったんだと思う。

166:デフォルトの名無しさん
09/02/09 06:58:32
統一性を考えたらカッコが必要なままでもよかった気がする。
つか、不要にするならするで if や while もカッコ不要にして統一しろよ。

167:デフォルトの名無しさん
09/02/09 07:24:14
>>166
ifやwhileは括弧があっても、タイプミスをするとコンパイル時に検出できるが、
returnに括弧があるとそうはいかない。

168:デフォルトの名無しさん
09/02/09 08:53:03
>>166
retrun() でハマるというネタが

169:デフォルトの名無しさん
09/02/09 10:42:17
>>166
つーか
統一するという言葉自体に惹かれても意味ないし
第一、統一する理由がない

170:デフォルトの名無しさん
09/02/09 11:42:57
括弧無しでも文法としては作れるよね？
そうしろっていってるんじゃなくて、ふとした疑問で

171:デフォルトの名無しさん
09/02/09 12:30:29
return-statement := return EXP
と定義すれば既に統一されてるじゃん
空白や(は識別子に含めないからそこで打ち切られてreturnが認識され、
以降の式が続けて認識される

172:デフォルトの名無しさん
09/02/09 16:13:55
>>166
break continue sizeof系統だからある意味統一されてるだろ。

173:デフォルトの名無しさん
09/02/09 16:26:05
>>172
sizeofちと違う

174:デフォルトの名無しさん
09/02/09 17:58:38
>>170
ついでにifなどにぶら下がる文を複文限定にして、中括弧必須にしてくれればいいのにと思う。

175:デフォルトの名無しさん
09/02/09 18:14:32
P e r l 化決定

176:デフォルトの名無しさん
09/02/09 19:22:59
#define begin {
#define end }

177:デフォルトの名無しさん
09/02/09 20:02:27
>>176
嘘のような、本当の話。

178:デフォルトの名無しさん
09/02/09 21:21:51
昔々のはなしじゃねーか。
つーか、ゴテゴテ強化してJAVAより遅くなってたら笑える。

179:デフォルトの名無しさん
09/02/09 21:23:53
>>176
STL コンテナと一緒に使えますか？

180:デフォルトの名無しさん
09/02/09 21:42:50
#defineはコンパイル以前に発現するのでSTLと一緒には使えません。

181:デフォルトの名無しさん
09/02/10 09:15:30
えー

182:デフォルトの名無しさん
09/02/10 11:57:45
#define private public

183:デフォルトの名無しさん
09/02/10 19:11:50
#define privata public

184:デフォルトの名無しさん
09/02/10 20:59:45
#define mein main
#define retrun return
#define cahr char

185:デフォルトの名無しさん
09/02/10 21:06:58
#define itn int
#define sohrt short
#define unsgied unsigned
#define long lgon
#define vodi void
#define defien define
#define incldue include
#define thrwo throw

186:デフォルトの名無しさん
09/02/10 21:18:27
#define unsinged unsigned がないのはおかしい

187:デフォルトの名無しさん
09/02/10 22:49:20
^t

188:デフォルトの名無しさん
09/02/10 23:04:18
結局、単なるデブ言語か。
テンプレートでarray使うと、C#より遅くなるんだからたまらん。

189:デフォルトの名無しさん
09/02/11 00:08:35
>>188
え～。コンパイル時に最適化掛けてないとかそんな話じゃないよね？

190:デフォルトの名無しさん
09/02/11 00:36:58
「テンプレートで」とか、馬鹿に決まってるから相手にするな。

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

192:デフォルトの名無しさん
09/02/11 01:20:19
188はコンパイルが遅いって話かと思った

193:デフォルトの名無しさん
09/02/11 01:36:50
遅いなら速くすればいいじゃない

194:デフォルトの名無しさん
09/02/11 03:34:24
コンパイルが遅いならDをｔ（ｒｙ

195:デフォルトの名無しさん
09/02/11 23:05:34
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww

196:デフォルトの名無しさん
09/02/12 22:07:49
いやいや、三次元配列だとすで使っても遅いぞ。

197:デフォルトの名無しさん
09/02/13 18:09:29
mailing2009来てるじゃん

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

198:デフォルトの名無しさん
09/02/13 20:58:23
constexpr の再帰が復帰してるっぽ。

199:デフォルトの名無しさん
09/02/13 21:15:07
停止判定できないのはテンプレートも同じだからな

200:デフォルトの名無しさん
09/02/13 22:36:24
結局コンパイラ側で制限かけるんじゃね？

201:デフォルトの名無しさん
09/02/14 00:28:13
そういう問題じゃない。

202:デフォルトの名無しさん
09/02/15 02:07:01
final class に相当するものは導入されてんの？
const class とかでキーワード導入しなくても大丈夫そうな気がするんだけど。

203:デフォルトの名無しさん
09/02/15 02:14:04
されてない

204:デフォルトの名無しさん
09/02/15 02:33:02
意見すら出なかったのだろうか

205:デフォルトの名無しさん
09/02/15 03:36:12
0x はそういう小手先の便利さとかとは掛け離れた大きいものを狙っている気がする。

206:デフォルトの名無しさん
09/02/15 05:12:01
小手先の便利さはライブラリやコーディングテクで補うのが禿と愉快な仲間たちの趣味です。

207:デフォルトの名無しさん
09/02/15 08:03:04
あるあるw

208:デフォルトの名無しさん
09/02/15 13:43:24
>>202
[[final]]っていうオーバーライド禁止属性が入る

209:デフォルトの名無しさん
09/02/15 14:56:54
class hoge [[final]] ってのは入る事になったの？
virtual member function にたいしてだけ？

210:デフォルトの名無しさん
09/02/15 16:24:18
N2800では入ってる
効果はクラスの全仮想関数に[[final]]を付けるのと同じ

211:デフォルトの名無しさん
09/02/15 16:46:12
>>210
継承禁止ならともかく仮想関数オーバーラード禁止してどうするの？
virtual付けなきゃ良いだけじゃない。

212:デフォルトの名無しさん
09/02/15 17:10:07
豚脂の摂り過ぎは禁止じゃないけど控えた方がいいだろうな。

213:デフォルトの名無しさん
09/02/15 17:14:36
>>211
> virtual付けなきゃ良いだけじゃない。
（　ﾟдﾟ）ﾎﾟｶｰﾝ

214:デフォルトの名無しさん
09/02/15 17:45:54
>>211
俺に言われても困るが、virtual付き関数のオーバーライドさえ封じておけば
基底クラスの機能を派生側で変更できなくなるんだから十分だろう

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

215:デフォルトの名無しさん
09/02/15 19:25:02
>>214
やっぱりそういう事なんだ。成るほどね。
>>202に「final classに相当するもの」って書いてあったから、
Javaと同系統の機能なのかと混乱したよ。

216:デフォルトの名無しさん
09/02/16 01:57:18
Java の final メソッドと同じだな

217:デフォルトの名無しさん
09/02/16 21:39:37
どうせクラスと関数でセマンティクスが変わるのが嫌だったんだろうけど
やっぱりキッパリと「派生クラス作ったらアウト」にして欲しかったな

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

218:デフォルトの名無しさん
09/02/16 22:39:33
デフォルトがアーリーバインディングのC++で
final が必要なケースのほとんどは悪い設計の尻拭いでしょ

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

219:デフォルトの名無しさん
09/02/16 22:40:34
安全性より速度側に倒すC++だからこそ
finalが必要なんだろう。

220:デフォルトの名無しさん
09/02/16 22:45:07
統一関数構文周りがここへ来てまた愉快なことになってるからな
今年中には無理だな

221:デフォルトの名無しさん
09/02/16 23:41:14
統一関数構文とかって、英語話者なら前から読んでわかりやすいかもしらんが
日本語だとあんまり C のとかわらなくね？
function of int i and int j which returns array of pointers to function of int i
とかそのままになる？んだろうけど日本語の語順とは全然ちがうよね。

222:デフォルトの名無しさん
09/02/17 00:09:52
まあ戻り値を引数列の後ろに置きたいための変更で
読みやすさのためじゃないからな

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

223:デフォルトの名無しさん
09/02/17 00:22:59
てかC++使いに自然言語的可読性気にする奴いるのかね？
最早ここまで崩れたら英語圏だろうどこの人間でも
気にする気にもならんと思うんだが。

224:デフォルトの名無しさん
09/02/17 00:23:56
統一関数構文は別言語でやってくれって感じだ。
C++にいれるには無理がある。

225:デフォルトの名無しさん
09/02/17 01:06:20
最初に思い切ってfuncdefでも予約語にすると決定すれば良かったんだ

226:デフォルトの名無しさん
09/02/17 01:07:08
いや、あれは必要だ。
とくにdecltypeがあるC++0xにとっては。

227:デフォルトの名無しさん
09/02/17 01:24:49
shared_ptrが付いたのはいいけど、やっぱり演算子にならないといまいち使えないよなー。構文長くなりすぎだし。
[*]とか何か導入できなかったのかな。バカだなー。

228:デフォルトの名無しさん
09/02/17 01:41:12
最大の問題はstd::shared_ptrがboost::shared_ptrと同じように使えるとは限らないこと
dynamic deleterが要件に入ってないとか何なの？死ぬの？

229:デフォルトの名無しさん
09/02/17 02:08:28
そんなあほな

230:デフォルトの名無しさん
09/02/17 02:29:42
>>224
入れないほうが無理があるよw
俺はあのスタイルは好きじゃないけれど、
なんか入れないと>>226の言う通りで破綻する。

231:デフォルトの名無しさん
09/02/17 02:44:02
C++って何がしたいの？

232:デフォルトの名無しさん
09/02/17 03:52:37
>>228
どこ読んでそう思ったの？
n2800 見たけど、 get_deleter() とかあるし、 template 引数には静的な deleter 型は無いよ。
これなら deleter については boost::shared_ptr と同じでしょ。

233:デフォルトの名無しさん
09/02/17 07:22:12
>>226
関数の戻り値の型は前置しても
以降の部分を考慮できるようにはできないんだろうか。

234:デフォルトの名無しさん
09/02/17 14:53:02
デブが集うスレ。

235:デフォルトの名無しさん
09/02/17 16:33:44
時間が経ってみるとこの構文も悪くない気がして来た
[] func(int arg) -> void {}

236:デフォルトの名無しさん
09/02/17 16:35:51
いい具合に洗脳されてきてますね

237:デフォルトの名無しさん
09/02/17 18:30:44
何を今更。C++0x最高！

238:デフォルトの名無しさん
09/02/17 20:53:21
>>232
コンストラクタで明示的に指定するdeleterの話じゃないぞ
boost::shared_ptr<Base> p(new Derived);
が（~Base()が仮想じゃなくても）デストラクタで~Derived()を呼んでくれるのがdynamic deleterだけど

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

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

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

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

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

239:デフォルトの名無しさん
09/02/17 21:18:19
Y* として delete pとなるようにすべきである、
というように書いてあるような気がするんだけど。

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

240:デフォルトの名無しさん
09/02/17 21:23:54
>>231
とにかく最強を目指す
ただし何が最強かは重要ではない

241:デフォルトの名無しさん
09/02/17 21:31:15
>Constructs a shared_ptr object that owns the pointer p.
「このポインタpを所有するshared_ptrオブジェクト」とあるから T*では
条件を満たさないんじゃね？

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

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

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

244:デフォルトの名無しさん
09/02/17 21:41:33
[] func(int arg) -> void {}
と
auto func(int arg) -> void {}

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

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

246:デフォルトの名無しさん
09/02/17 21:45:52
あと一年時間があれば間違いなく[]が正式になっただろうけど、今の状況だと微妙だな
autoが意味持ちすぎだから[]の方がいいと思うけどね

247:デフォルトの名無しさん
09/02/17 21:47:57
いや、こんな調子じゃ、あと一年ぐらいじゃ規格制定までは無理だろ。
まだ数年かかるんじゃない？
x == 9にはならんだろう。

248:デフォルトの名無しさん
09/02/17 21:51:16
>>242
>Y*で持ってY*で解体しろと強制してる箇所

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

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

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

249:デフォルトの名無しさん
09/02/17 21:58:18
>>248
pがT*に変換できて、Yが完全型で、「delete p」の形式が適格で定義済みの振る舞いをして例外を投げない
としか書いてないように見えるんだけど、どこで「Y*で持ってY*で解体しろと強制してる」の？

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

250:デフォルトの名無しさん
09/02/17 22:05:13
pimplで使うことを考えるとY==Tだとしても問題だしな

251:デフォルトの名無しさん
09/02/17 22:06:31
Yのデストラクタがvirtualでなければならないとはどこかに書いてあるのかな？
書いてなければ、delete p がwell formedになるためには、一体どうすればいいんだろうな。

252:デフォルトの名無しさん
09/02/17 22:09:11
>pがT*に変換できて、Yが完全型で、「delete p」の形式が適格で定義済みの振る舞いをして例外を投げない

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

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

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

253:デフォルトの名無しさん
09/02/17 22:09:31
Yが基底クラス持たなければ常に適格だな
それがどうした

254:デフォルトの名無しさん
09/02/17 22:12:32
Tがvoidのとき適格じゃないけど。

255:デフォルトの名無しさん
09/02/17 22:14:39
これの話だろ？
URLﾘﾝｸ(d.hatena.ne.jp)

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

256:デフォルトの名無しさん
09/02/17 22:15:43
書いてるって

257:デフォルトの名無しさん
09/02/17 22:21:05
素朴な疑問
1) どうしてここまでして C++ 使いたいんだ?
2) 型に厳格な関数型言語で十分じゃね?

258:デフォルトの名無しさん
09/02/17 22:22:43
とにかく最強を目指す
ただし何が最強かは重要ではない

次ページ