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

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

C++0x 5

1 :デフォルトの名無しさん:2009/01/20(火) 23:10:49
The C++ Standards Committee
http://www.open-std.org/jtc1/sc22/wg21/

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

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

2 :デフォルトの名無しさん:2009/01/20(火) 23:12:09
                            rへ __  __
            くヽ  l^ i         /: : : : : : : : Y: :ヽ
  ┏┓  ┏━━┓\\l  l.       /: :./ l: :.lヽ: : :ヽ: : :ヽ.          ┏┓┏┓┏┓
┏┛┗┓┃┏┓┃  \\.l       //: :/ノ  l: :ト、ヽ: : :',: : :. ',          ┃┃┃┃┃┃
┗┓┏┛┃┗┛┃┏━ \\━━━/ l: :/ ○ 丶l ○ l: : :ハ: : : :',━━━━┓┃┃┃┃┃┃
┏┛┗┓┃┏┓┃┃    \\. _/: :l: :l@┌‐┐ @ l: :/: :l: : : :.',.     ┃┃┃┃┃┃┃
┗┓┏┛┗┛┃┃┗━━━ \/:::::::\ヽl.\ |   !   /:// l: : : :..i ━━━┛┗┛┗┛┗┛
  ┃┃      ┃┃          {:::::::::::::::::`T7└‐┴‐<    l: : : :. l      ┏┓┏┓┏┓
  ┗┛      ┗┛           `r──‐┼-/l/l// 01i,  l: : : : : l.      ┗┛┗┛┗┛
                    /: : : : : : | /:/: l: : : :Y:::::::l  l: : : : : :.l
                   ,': : : : : :./ /: /: : : : l:::::::::l.  l: : : : : : l
                     i: : : : : く/レへ: : : : l::::::::::',. !: : : : : : l
                       l: : : : : : :\:::::::::::ヽ イ:::::::::::::〉l: : : : : : : l
                   l: : : : : : : : :ト、:::::::::::::::>tjtjtjノ l: : : : : : : :l
                   ',: : : : : : : :/├‐┤|─ '"|   l: : : : : : : :l
                   ヽ: : : : / .l:::::::| l:::::::::::l   ',: : : : : : :,'
                     \:/    l:::::::l |::::::::::l   ヽ:: : : : /

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

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


4 :デフォルトの名無しさん:2009/01/20(火) 23:14:54
mailing 2008
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/

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

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

Boost
http://www.boost.org

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

6 :デフォルトの名無しさん:2009/01/20(火) 23:17:02
/   //   /   //    ______     /   //   /
 / //   /|   r'7\ ,.ヘ‐'"´iヾ、/\ニ''ー- 、.,   /    /
  /   / |  |::|ァ'⌒',ヽ:::ヽrヘ_,,.!-‐-'、二7-ァ'´|、__
`'ー-‐''"   ヽ、_'´  `| |:::::|'"       二.,_> ,.へ_
         /  //__// / / /      `ヽ7::/
 か っ も  |  / // メ,/_,,. /./ /|   i   Y   //
 ァ  て う.  |'´/ ∠. -‐'ァ'"´'`iヽ.// メ、,_ハ  ,  |〉
  |  約 ク  ヽ! O .|/。〈ハ、 rリ '´   ,ァ=;、`| ,ハ |、  /
  |  束 ソ   >  o  ゜,,´ ̄   .  ト i 〉.レ'i iヽ|ヽ、.,____
  |  し  ス  /   ハ | u   ,.--- 、  `' ゜o O/、.,___,,..-‐'"´
  |  た  レ  |  /  ハ,   /    〉 "从  ヽ!  /
  |  じ  は  |,.イ,.!-‐'-'、,ヘ. !、_   _,/ ,.イヘ. `  ヽ.
 ッ .ゃ .立   |/     ヽ!7>rァ''7´| / ',  〉`ヽ〉
 ! ! な  て   .',      `Y_,/、レ'ヘ/レ'  レ'
   い  .な    ヽ、_     !:::::ハiヽ.   //   /
   で   い   ./‐r'、.,_,.イ\/_」ヽ ',       /  /
   す      /    `/:::::::/ /,」:::iン、 /    /
          〈  ,,..-‐''"´ ̄ ̄77ー--、_\.,__  /
      ,.:'⌒ヽ ´         | |  , i |ノ   `ヾr-、


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

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

9 :デフォルトの名無しさん:2009/01/20(火) 23:22:52
俺は閲覧したね!

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

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

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

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

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

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

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

14 :デフォルトの名無しさん:2009/01/21(水) 11:56:54
       //
     /  /   パカッ
     //⌒)∩__∩
    /.| .| ノ     ヽ
    / | |  ●   ● |     
   /  | 彡  ( _●_) ミ  まピョーん☆
   /  | ヽ  |∪|  /_
  // │   ヽノ  \/
  " ̄ ̄ ̄ ̄ ̄ ̄ ̄(..ノ

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


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

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

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

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

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

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

22 :デフォルトの名無しさん:2009/01/24(土) 12:37:24
wwwwwwwwwwwwwwwwwwwwwwwww

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

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

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

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


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

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

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

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

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

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

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

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

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

36 :デフォルトの名無しさん:2009/01/26(月) 10:33:13
なぜ?

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

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

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

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

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

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

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

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

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

45 :デフォルトの名無しさん:2009/01/26(月) 19:47:57
>>41
ソースは?
ソース出せよ!

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

73 :デフォルトの名無しさん:2009/01/30(金) 11:14:42
誰がハゲだと!?もう一度言ってみろ!!

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

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

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

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

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


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

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

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

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

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


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

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

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


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

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

って可能なの?

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

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

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

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

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

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

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

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

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

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

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

99 :デフォルトの名無しさん:2009/02/01(日) 17:57:10
で、0xの次の標準の主なネタは何?

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

115 :デフォルトの名無しさん:2009/02/02(月) 01:05:44
>>114
before-daemon, after-daemonキター!

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

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

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

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

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

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

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

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

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


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

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

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

126 :デフォルトの名無しさん:2009/02/03(火) 09:20:41
なぜ?

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

185 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/02/10(火) 21:18:27
#define unsinged unsigned がないのはおかしい

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

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

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

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

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

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

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

194 :デフォルトの名無しさん:2009/02/11(水) 03:34:24
コンパイルが遅いならDをt(ry

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

213 :デフォルトの名無しさん:2009/02/15(日) 17:14:36
>>211
> virtual付けなきゃ良いだけじゃない。
( ゚д゚)ポカーン

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

231 :デフォルトの名無しさん:2009/02/17(火) 02:44:02
C++って何がしたいの?

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

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

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

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

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

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

238 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/02/17(火) 21:18:19
Y* として delete pとなるようにすべきである、
というように書いてあるような気がするんだけど。


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

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

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

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

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

auto func(int arg) -> void {}

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

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

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

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

248 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/02/17(火) 22:05:13
pimplで使うことを考えるとY==Tだとしても問題だしな

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

252 :デフォルトの名無しさん:2009/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 :デフォルトの名無しさん:2009/02/17(火) 22:09:31
Yが基底クラス持たなければ常に適格だな
それがどうした

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

255 :デフォルトの名無しさん:2009/02/17(火) 22:14:39
これの話だろ?
http://d.hatena.ne.jp/Cryolite/20060108

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

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

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


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

259 :デフォルトの名無しさん:2009/02/17(火) 22:23:40
>>257
スレ違いどころか板違いです。

260 :デフォルトの名無しさん:2009/02/17(火) 22:27:53
>>256
だからどこに?

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

261 :デフォルトの名無しさん:2009/02/17(火) 22:34:32
>>260
Requires: p shall be convertible to T*. Y shall be a complete type. The expression delete p shall
be well formed, shall have well defined behavior, and shall not throw exceptions.


262 :デフォルトの名無しさん:2009/02/17(火) 22:40:12
>>261
だからそれはコンストラクタでしょ
shared_ptrのコンストラクタではimplクラスの完全な定義が見えてなきゃならないから、
その位置ではdelete p;はwell definedになるけど、
外側のデストラクタが自動生成だった場合にimplクラスの定義が見えてなくて
shared_ptrのデストラクタが呼ぶdelete p;が未定義になりうるんだが、
それを禁じる要件はshared_ptrのデストラクタの説明には書いてない

わかる?

263 :デフォルトの名無しさん:2009/02/17(火) 22:41:22
そういう仕様のアラを突き上げるのが去年の集まりだったんだよなあ。
今年もやるらしいから、そんとき誰かが言えば、委員会の人まで話が届くぞ。

264 :デフォルトの名無しさん:2009/02/17(火) 22:47:21
>>262
デストラクタにdeleterを持つときは、d(p)となると書いてある。

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

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

265 :デフォルトの名無しさん:2009/02/17(火) 22:50:16
>>264
やっぱりわかってなかったのな

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

266 :デフォルトの名無しさん:2009/02/17(火) 22:53:30
>>265
いや、それでも同じ話ですけど。

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

267 :デフォルトの名無しさん:2009/02/17(火) 22:56:43
なくても満たしちゃうだろ、と言ってるんだけど
もう一度言うけどY==Tでの話だぞ

268 :デフォルトの名無しさん:2009/02/17(火) 23:01:07
N2800で言う所のdeleterってのは
template<class Y, class D> shared_ptr(Y* p, D d);の形のコンストラクタで渡されるdのことであって
template<class Y> explicit shared_ptr(Y* p);は「deleterを所有」しない

269 :デフォルトの名無しさん:2009/02/18(水) 00:05:26
結局pimplにshared_ptr使っていいの?

270 :デフォルトの名無しさん:2009/02/18(水) 01:31:05
>>238
> template<class Y> explicit shared_ptr(Y* p);
> Effects: Constructs a shared_ptr object that owns the pointer p.

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

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

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

271 :デフォルトの名無しさん:2009/02/18(水) 02:17:33
そっちの話は終わってるだろ

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

272 :デフォルトの名無しさん:2009/02/18(水) 03:08:39
>>233
できるよ。現にD言語ではそうなってるし。
単に実装面倒だからコンパイラベンダが反対してるだけでしょ。

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

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

273 :デフォルトの名無しさん:2009/02/18(水) 03:12:24
>>271
そういうことか。

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

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

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

274 :デフォルトの名無しさん:2009/02/18(水) 08:02:53
>>272
実装が面倒っての、ここまですでに複雑な言語だと、結構な問題では。

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


275 :デフォルトの名無しさん:2009/02/18(水) 08:27:04
×C#使い
○VisualStudio使い
◎MS迎合派

276 :デフォルトの名無しさん:2009/02/18(水) 09:17:10
こんなデブで非実用的な言語なんか使えねー

277 :デフォルトの名無しさん:2009/02/18(水) 09:30:04
まあC++使ってない携帯電話探す方が難しいけどな。

278 :デフォルトの名無しさん:2009/02/18(水) 16:16:50
Embedded C++(笑)

279 :デフォルトの名無しさん:2009/02/18(水) 17:59:58
Embedded C++0xを予想するスレ

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

280 :デフォルトの名無しさん:2009/02/18(水) 18:24:51
それ以前にEmbedded C++はフリースタンディング環境で
ライブラリがないから特殊用途以外は既に死んでる。
DarwinのI/O Kitですらnamespaceはありになってるし。


281 :デフォルトの名無しさん:2009/02/18(水) 19:18:32
C++にはフリースタンディングの規格は元々あるけど、
Embeddedって日本独自の規格だっけ?
製品化されてる実装なんてあるの?


282 :デフォルトの名無しさん:2009/02/18(水) 19:35:47
>>281
>Embeddedって日本独自の規格だっけ?
事実上日本独自規格
C++のまともな処理系が作れないから、作りやすい縮小規格を作ったってだけ

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

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

284 :デフォルトの名無しさん:2009/02/18(水) 20:08:08
使い物になるやつを頼む。
C#より早いやつを頼むよ。

285 :デフォルトの名無しさん:2009/02/18(水) 21:44:24
コンパイル速度の速さなら一生かなわない自信がある。

286 :デフォルトの名無しさん:2009/02/19(木) 00:55:27
EC++のほうがC++より幾分ましだよ。
言語オタクにはわからんだろうが。

287 :デフォルトの名無しさん:2009/02/19(木) 01:03:03
とにかく必要なモノは実用品だ。


288 :デフォルトの名無しさん:2009/02/19(木) 01:56:22
EC++のページ見に行ったけど、2002年で更新止まってるしURL削ったら会社潰れたとか書いてるし
もう死んでるようにしか見えないんだけどどうなの
どっかで亡霊みたいに生き延びてるの?

289 :デフォルトの名無しさん:2009/02/19(木) 02:01:24
生き延びてたとしたら俺が殺しにいくかもしれない。

290 :デフォルトの名無しさん:2009/02/19(木) 02:15:51
なんで日本のこういうジャンルはクソなもんばかりなんだろうな?
うまいこと行ったのはRubyぐらいか?
てか著名なソフトの作者は大体医者だったりする所が泣ける。

291 :デフォルトの名無しさん:2009/02/19(木) 02:43:25
rubyも最近は面白くなさそうだけどな。

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

293 :デフォルトの名無しさん:2009/02/19(木) 09:21:51
>>269
問題としては >>271,273 が残ってるだけなので、生成時に deleter として
std::default_delete<Y>() を渡しとけば現状のドラフトの記述でも動作保証はできる。
しかし激しくダルイな。

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

294 :デフォルトの名無しさん:2009/02/19(木) 18:47:09
>>292
わざわざそんなドキュメントを出されなくても
フツーに考えたら、C++がパフォーマンスで
劣るハズがないのに。
世間はバカなの?死ぬの?

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

295 :デフォルトの名無しさん:2009/02/19(木) 19:13:46
>>292
てかEC++はパフォーマンスなんて謳ってたの?
速度なら、例外とnew deleteぐらい、容量なら
templateとinline関数とランタイム。実際には、
それぞれ自前で調整できるからまったく問題ないのは
バカでも解ると思うが。

296 :デフォルトの名無しさん:2009/02/19(木) 20:31:53
利点しかない新形式キャストを全部消してるあたり(多分RTTIとdynamic_cast消す時に巻き添え食らったんだろう)
C++を理解してない奴らが作ってたのは明白

297 :デフォルトの名無しさん:2009/02/19(木) 20:37:24
>>294
かわいそうな人。
バカじゃね?

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

298 :デフォルトの名無しさん:2009/02/19(木) 20:37:38
>>293
でもちゃんと規定しておいてくれないとvectorの連続性保証みたいなことになるからな
はっきり書いてない要件はやっぱり信用できない
たとえ事実上全部の実装がそうなってたとしても

299 :デフォルトの名無しさん:2009/02/19(木) 23:16:37
バカ専用にしょぼい言語つくろうって話なんだからw

300 :デフォルトの名無しさん:2009/02/19(木) 23:47:39
同じ事ができるならシンプルな方が正しい。

301 :デフォルトの名無しさん:2009/02/19(木) 23:54:10
百歩譲ってシンプルな事は認めても、同じ事(表現)はできないだろ

302 :デフォルトの名無しさん:2009/02/20(金) 00:13:28
EC++は名前空間さえ残してれば単なるC++サブセットでほぼ済んだのに
なんでわざわざ互換性捨てちゃったんだろうな

303 :デフォルトの名無しさん:2009/02/20(金) 00:44:53
いらないから。
やたら短い関数名つけて検索性下げるバカとか普通に多いから。

304 :デフォルトの名無しさん:2009/02/20(金) 00:45:36
EC++のメリットがパフォーマンスとか言っちゃうやつらに何いってもね。

305 :デフォルトの名無しさん:2009/02/20(金) 00:52:47
日本の企業が中心になって決めたから。

306 :デフォルトの名無しさん:2009/02/20(金) 09:15:46
>>300
それは大きなカンチガイ。
このバカ。

307 :デフォルトの名無しさん:2009/02/20(金) 10:53:55
シンプルだと言うにも視点はそれぞれだからね
短かく書ければシンプルであるというわけでもない

308 :デフォルトの名無しさん:2009/02/20(金) 11:00:10
ああ、三項演算子がバグの元とかいうアレですね

309 :デフォルトの名無しさん:2009/02/20(金) 12:22:46
いいかげんgccのコナピルまんどくせ

310 :デフォルトの名無しさん:2009/02/20(金) 15:31:51
昔gccにあったSignatureいつか次期C++で復活しないかなぁ。
interfaceなんかより遥に便利そうなんだけど何で廃止されかなぁ。

311 :デフォルトの名無しさん:2009/02/20(金) 15:32:54
>>303
逆にループ変数にわざわざcounterとかつけてたり、引数に関数名が入ってたりするアホも見たことがある

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

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

void hoge( int hoges_first_argument, int hoges_second_argument ) ;


313 :デフォルトの名無しさん:2009/02/20(金) 16:14:24
そんなん
ループ変数の方はアホはいい過ぎだったな

314 :デフォルトの名無しさん:2009/02/20(金) 16:31:42
>>306
それはシンプルという言葉から、アインシュタイン言うところの
「単純化せよ。ただし単純化しすぎてもいけない」
の後者のケースばかり思い出すから出てくる反応で、
前者を完全スルーするお前の姿勢がカンチガイってオチじゃないの?

315 :デフォルトの名無しさん:2009/02/20(金) 19:56:49
>>314
アインシュタインはプログラマーか?

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

316 :デフォルトの名無しさん:2009/02/20(金) 20:34:28
simplicityとかいった形で数値化できればいいのにな
でさらにある法則に沿って変形していったらsimplicityがmonotonically decreasingになっていってそれを使って機械的にコードを変形して云々

317 :デフォルトの名無しさん:2009/02/20(金) 20:34:51
アインシュタインのその言葉を引用するには致命的なほど具体性にかけているな。

318 :デフォルトの名無しさん:2009/02/20(金) 21:23:40
w

319 :デフォルトの名無しさん:2009/02/20(金) 21:43:09
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww

320 :デフォルトの名無しさん:2009/02/20(金) 23:17:46
>>310
concept来たやん

321 :デフォルトの名無しさん:2009/02/21(土) 00:14:40
クラス作る時にコンセプト使って
InputIterator my_iterator{/*...*/};
とかやって要件満たしてなかったらエラー出してくれるみたいな使い方ができればよかったのに

322 :デフォルトの名無しさん:2009/02/21(土) 00:16:33
表記が違うだけで出来るやん

323 :デフォルトの名無しさん:2009/02/21(土) 00:27:12
いや、そりゃやろうと思えばできるけどさ
こんな風になるのかな

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

template<InputIterator T> class InputIteratorChecker{};

static_assert(sizeof(InputIteratorChecker<my_iterator>));

めんどくさくね?

324 :デフォルトの名無しさん:2009/02/21(土) 00:29:53
>>315
主旨だけシンプルに書きましょう。
わめいて逃げてるようにしか見えませんw

325 :デフォルトの名無しさん:2009/02/21(土) 00:49:16
>>323
Only required,
> requires InputIterator


326 :デフォルトの名無しさん:2009/02/21(土) 01:02:42
>>325
それでどうやって簡単に書くんだ?
requiresってテンプレートとコンセプトの中でしか使えないだろ

327 :デフォルトの名無しさん:2009/02/21(土) 01:13:26
my_iteratorは、template<〜> iteratorとは無縁のクラス、
まったく別のsignatureってわけですか?
だったらconcept_map書くしかないですね。

328 :デフォルトの名無しさん:2009/02/21(土) 01:18:10
めんどくさい誤解招いてるみたいだからInputIteratorやめる

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

があるときに

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

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

329 :デフォルトの名無しさん:2009/02/21(土) 02:01:42
fooにT型の関与なしかあ。

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

でいいのかなあ。

330 :デフォルトの名無しさん:2009/02/21(土) 02:14:42
めんどくさいなぁ

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

331 :デフォルトの名無しさん:2009/02/21(土) 02:23:59
これでいいじゃん
template<> class Hoge {
void foo();
requires HasFoo<Hoge>;
};

332 :デフォルトの名無しさん:2009/02/21(土) 02:23:59
auto concept HasFoo<typename T>{
void foo(T);
};
だと、
template<typename T> class Hoge {
requires HasFoo<T> void foo(T) {}
}
って書けるけど。
template<> class Hoge {
requires HasFoo<> void foo() {}
}
はいけるかどうかわからん。もう一回ドラフト読まんと。


333 :332:2009/02/21(土) 02:26:50
間違えた。
class Hoge {
requires HasFoo<> void foo() {}
}
これは駄目だった。
>>331
ああそだね。

334 :デフォルトの名無しさん:2009/02/21(土) 02:28:05
>>332
それ以前の問題として

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

>>323の方が楽だわ

335 :デフォルトの名無しさん:2009/02/21(土) 02:31:08
直接こう書ければなんの問題もないのにな
class Hoge {
void foo();
requires HasFoo<Hoge>;
};

336 :デフォルトの名無しさん:2009/02/21(土) 02:44:18
C++ってほんとに糞言語ですね☆

337 :デフォルトの名無しさん:2009/02/21(土) 02:45:25
C++がwadlerとかにボロ糞に貶されるところを見てみたい

338 :デフォルトの名無しさん:2009/02/21(土) 03:30:09
class Hoge : public HasFoo<Hoge> {
void foo();
};

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

339 :デフォルトの名無しさん:2009/02/21(土) 03:53:18
>>320
配列で使えんやん

340 :デフォルトの名無しさん:2009/02/21(土) 08:56:53
>>338
class Hoge requires HasFoo {
void foo();
};
ならあり得るかも。

341 :デフォルトの名無しさん:2009/02/21(土) 12:08:31
>>339
concept_map ?

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

343 :デフォルトの名無しさん:2009/02/21(土) 20:13:06
↓がg++4なら通るけどVC9などintがint&に変えられなくて駄目といって通らない。
これって自分何か勘違いしてますか?VC9のバグってことはありませんか?

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



344 :343:2009/02/21(土) 20:14:24
あ、bindは<functional>のstd::tr1::bind、_1はstd::tr1::placeholders::_1です。

345 :343:2009/02/21(土) 20:21:13
スレ違いな気がしてきた。C++スレへ行きます。すみません。

346 :デフォルトの名無しさん:2009/02/22(日) 15:49:24
さあもう一度アインシュタインでなにか例え話してみれば?

347 :デフォルトの名無しさん:2009/02/22(日) 17:01:38
誰もアインシュタインで例えたことなんて無いと思うが。

348 :デフォルトの名無しさん:2009/02/22(日) 17:47:07
誰かアインシュタインclass作れよ

349 :デフォルトの名無しさん:2009/02/22(日) 18:35:28
__declspec(dllimport) class Einstein * __stdcall BangEinstein(void);
class Einstein *Albert=BangEinstein();

350 :デフォルトの名無しさん:2009/02/22(日) 18:55:22
assert(E==mc2)


351 :デフォルトの名無しさん:2009/02/22(日) 19:19:11
アインシュタインタンジェント

352 :デフォルトの名無しさん:2009/02/23(月) 10:05:15
もう拡張メソッドも組み込んじゃえよ

353 :デフォルトの名無しさん:2009/02/23(月) 19:54:44
C++に拡張メソッドは色々と面倒で厄介な問題があるから無理

354 :デフォルトの名無しさん:2009/02/23(月) 23:39:28
もうちょっと説明クレ
抽象的な言い方では判らないよ

355 :デフォルトの名無しさん:2009/02/24(火) 00:23:27
ヒント:拡張メソッドはメンバ関数もどきを提供するんだから
当然ポインタから->を通して呼ぶこともできるべきだよな、C++的に考えて

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

356 :デフォルトの名無しさん:2009/02/24(火) 05:30:40
>>355
テンプレートメンバ関数の特殊化と同じような方法で実装すればいいんじゃね?
あれも新しいメンバ関数をクラスの定義の外で作ってるわけだし。

357 :デフォルトの名無しさん:2009/02/24(火) 10:13:33
なんか演算子余ってないの?
p->>func() を func(p) の糖衣構文として扱うとかそんなんでいいんだが


358 :デフォルトの名無しさん:2009/02/24(火) 10:17:34
>>356
特殊化はシグネチャを変えているわけじゃない。

359 :デフォルトの名無しさん:2009/02/24(火) 15:44:17
>>357
->* とか?
でも (p->*func)() みたいに括弧が必須なのが面倒。

360 :デフォルトの名無しさん:2009/02/24(火) 18:49:01
>>359
肛門を指してるように見えた俺は逝ったほうがいいんだろうな orz


361 :デフォルトの名無しさん:2009/02/24(火) 19:02:12
 )*(

362 :デフォルトの名無しさん:2009/02/24(火) 22:53:49
>>352
拡張メソッドのメリットって何?


363 :デフォルトの名無しさん:2009/02/25(水) 01:13:23
>>361
むしろ梅干し食べてる感じ

364 :デフォルトの名無しさん:2009/02/25(水) 03:35:03
>>356
難しく考えすぎ

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

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

365 :デフォルトの名無しさん:2009/02/25(水) 09:00:55
>>364
なにその生産性の低い記述は。


366 :デフォルトの名無しさん:2009/02/25(水) 09:13:32
あくまで後から擬似的にメンバメソッドを追加できるようにするシンタックスシュガーでしょ。
あんまりいい例じゃないけど、なんでこの行列クラス、固有値求められないんだよ…ってときに:

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

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

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

367 :デフォルトの名無しさん:2009/02/25(水) 11:11:44
比較的簡単な処理の流れはメソッドチェイン出来ると楽ってだけかと
ただC++だと例外を軽く使えないからエラー処理をどうしようってことでMaybeモナドが欲しくなる

368 :デフォルトの名無しさん:2009/02/25(水) 12:10:37
>>366
例が悪すぎます

369 :デフォルトの名無しさん:2009/02/25(水) 12:45:38
>>366
Matrixをテンプレートの型パラメータで渡したときなんか拡張メソッドの定義includeの読み込み順で拡張メソッドが適用されたりされなかったりするのかな

370 :デフォルトの名無しさん:2009/02/25(水) 15:11:17
oven(egg)のpipableは拡張メソッドっぽい

371 :デフォルトの名無しさん:2009/02/25(水) 19:56:06
ソースが短くなるだけで、生産性の低い、動きがトロい、そんなバイナリーができそうだな。
現状のSTLも遅いし。

372 :デフォルトの名無しさん:2009/02/25(水) 20:06:19
拡張メソッドの解決は動的ポリモルしなければコンパイル時に行うことができるんでそうとも言いきれない

373 :デフォルトの名無しさん:2009/02/25(水) 22:40:52
第一引数を前に出す、単なる糖衣構文だから、バイナリが遅くなるなんてことはないわ

374 :デフォルトの名無しさん:2009/02/25(水) 23:12:40
C++だとただの糖衣じゃ済まないから注意しないとオーバーヘッドはかかるな

375 :デフォルトの名無しさん:2009/02/25(水) 23:15:33
operator.ぐらいの糖衣

376 :デフォルトの名無しさん:2009/02/25(水) 23:47:58
generic functionがあるのに必要ですかね。

377 :デフォルトの名無しさん:2009/02/26(木) 01:09:52
>>372
それが問題なんでねぇかい

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

378 :デフォルトの名無しさん:2009/02/26(木) 05:05:59
普通のオーバーロード解決でなんか問題あるんか。

379 :デフォルトの名無しさん:2009/02/26(木) 11:52:07
>>378
kwsk

380 :デフォルトの名無しさん:2009/02/26(木) 13:18:24
objがfuncメソッドを持ってなくて、スコープにfunc拡張関数がある場合、
obj.func(args) を func(obj, args) と字面上同義みなすってことでは?

381 :デフォルトの名無しさん:2009/02/26(木) 13:20:17
generic functionがあるのに必要ですかね。


382 :デフォルトの名無しさん:2009/02/26(木) 13:35:21
必要です。目的が違います。

383 :デフォルトの名無しさん:2009/02/26(木) 13:39:08
ほとんど変らないんじゃない?
virtualにならないんだし。

384 :デフォルトの名無しさん:2009/02/26(木) 13:44:28
generic functionて何。

385 :デフォルトの名無しさん:2009/02/26(木) 18:48:11
あるオブジェクトに対して行う処理を
まずオブジェクト名から入力できるとインテリセンスとかで楽できるんだよね
候補が狭まるから

386 :デフォルトの名無しさん:2009/02/26(木) 20:08:43
あほくさ

387 :デフォルトの名無しさん:2009/02/26(木) 22:52:27
今時インテリセンスも使いこなせない奴がいるのか・・・

388 :デフォルトの名無しさん:2009/02/26(木) 22:56:03
0xの次で多重ディスパッチが入れば一緒に入るんじゃないかい>拡張メソッド

389 :デフォルトの名無しさん:2009/02/26(木) 23:18:24
汎関数の多重ディスパッチは既にある。

390 :デフォルトの名無しさん:2009/03/15(日) 11:12:39
おっぱいを大きく見せたくて多重ブラジャーする美少女中学生

391 :デフォルトの名無しさん:2009/03/15(日) 12:53:17
久々に上がってるんで見に来てみたら…

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

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


392 :デフォルトの名無しさん:2009/03/15(日) 15:36:14
0xって本当に0xに出せるの?

393 :デフォルトの名無しさん:2009/03/15(日) 15:46:12
残念ながら1xがほぼ決定

394 :デフォルトの名無しさん:2009/03/15(日) 15:47:12
でも未完成のまま強引に0xに出しそうな気もする
やめてほしいけど

395 :デフォルトの名無しさん:2009/03/15(日) 15:50:09
ISOの手続きのスケジュールの都合で無理なのでは?
それがなかったとしても十分09に間に合いそうもないが。

396 :デフォルトの名無しさん:2009/03/15(日) 16:03:26
もう出しても意味ネーよ。

397 :デフォルトの名無しさん:2009/03/15(日) 16:24:56
>>391
auto concept HasAssign<typename T, typename U> {
typename result_type;
result_type T::operator=(U) &; // ←Rvalue reference!
}
ワロス

398 :デフォルトの名無しさん:2009/03/15(日) 18:27:34
>>395 そうきいている

399 :デフォルトの名無しさん:2009/03/15(日) 21:34:43
autoっぽいものを現行のC++で実現するマクロってあったような気がするんですがマクロ名を知りませんか

400 :デフォルトの名無しさん:2009/03/15(日) 21:56:24
BOOST_AUTOのこと?

401 :デフォルトの名無しさん:2009/03/15(日) 22:44:53
gccのtypeofかなぁ?


402 :デフォルトの名無しさん:2009/03/21(土) 14:58:40
僕は言語仕様の問題のほか、現実的な理解者とコンパイラがいつ現れるかも
気になる。現行のSTLやBoostですらコンパイルエラー、ワーニングが長すぎて
解読困難なのに、これ以上になるのかと思うと気が重くなる。

403 :デフォルトの名無しさん:2009/03/21(土) 14:59:11
しまった・・・sage忘れた・・・

404 :デフォルトの名無しさん:2009/03/21(土) 15:03:06
C++0xのconceptにはエラーメッセージを簡易にする目的もあります。

405 :デフォルトの名無しさん:2009/03/21(土) 15:03:38
俺を含む凡人以下からすれば
「まずはまともな処理系を出してくれ、話はそれからだ」
だからな
WGにいる仕様書だけでコードを書いてあーだこーだ議論してる奴等は化け物に思えてくる

406 :デフォルトの名無しさん:2009/03/21(土) 15:06:55
>>404
一般的な開発者がその恩恵を受けられるのは、
どんなに早くても2012年頃かと思われますw

407 :デフォルトの名無しさん:2009/03/21(土) 15:12:33
concept については厳しいだろうけど他の機能についてはちょこちょこ実装されつつあるじゃん。

408 :デフォルトの名無しさん:2009/03/21(土) 17:13:32
可変長テンプレートとか右辺値参照とかばっかり先行してて
可読性を良くする機能はことごとく後回しにされてるけどな

409 :デフォルトの名無しさん:2009/03/21(土) 17:16:56
可変長テンプレートはありがたいだろ。
TEMPL1(X)
TEMPL2(X1, X2)
TEMPL3(X2, X2, X3)

TEMPL20(X1, X2, X3 .. X20)
とかもうイヤだよ。



410 :デフォルトの名無しさん:2009/03/21(土) 17:24:11
そりゃそうだけど、ソースが読みやすくなる訳じゃないじゃん
エラーメッセージは多分もっとわかりにくくなるだろうし

411 :デフォルトの名無しさん:2009/03/21(土) 17:27:25
可変長テンプレートが「可読性を良くする機能」ではないとすると、
後回しにされてる機能って何のこと言ってるの?

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

413 :デフォルトの名無しさん:2009/03/25(水) 03:24:35
http://www.open-std.org/jtc1/sc22/wg21/
News 2009-03-24: The 2009-03 post-Summit mailing is available
News 2009-03-24: The C++ Standard Core Language Issues List (Revision 62) is available
News 2009-03-24: The C++ Standard Library Issues List (Revision 63) is available


414 :デフォルトの名無しさん:2009/03/25(水) 12:21:54
というわけで最新のWorking DraftはN2857ですか。


415 :デフォルトの名無しさん:2009/03/25(水) 18:44:11
あんまり面白くねーな
ラムダ関係がボロボロで全面書き直しって事くらいか
あと日本からのコメントrejectされまくり

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

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)