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されまくり

416 :デフォルトの名無しさん:2009/03/26(木) 21:07:56
結局ラムダ式って Monomorphic なやつだけしか入らんの?
型名書くのだりーよ…
結局 Boost.Lambda のほうが便利じゃんってオチ?

417 :デフォルトの名無しさん:2009/03/27(金) 05:20:03
>>416
何言ってるのかわからん。 Boost.Lambda のどんな用法のことを言ってるの?
C++0x のラムダ式で置きかえらない用法があるってことなんだよね?

418 :デフォルトの名無しさん:2009/03/27(金) 08:58:21
>417
単に引数の型書くのが面倒という話では?
_1 + 1
[] (int n) { return n + 1; }

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

419 :デフォルトの名無しさん:2009/03/27(金) 09:13:54
[] (auto x) { (ry }とか[] (x) { (ry }とかでできないのかな?

420 :デフォルトの名無しさん:2009/03/27(金) 11:06:48
>>417
Boost.Lambda は多相じゃん。
(_1 + _2)(1, 1) // -> int 2
(_1 + _2)(1.0, 1.0) // -> double 2.0
単相にして保持したければ
 function<double(double, double)> f = (_1 + _2);
f(1, 1) // double 2.0
とかもできるし。

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

421 :デフォルトの名無しさん:2009/03/27(金) 12:35:25
range based algorithmの採用も却下されたことだし
まだまだboostの役目は終わらないということだな

422 :デフォルトの名無しさん:2009/03/27(金) 17:45:45
boostの肝心な機能を骨抜きにしたのが標準だな
結局みんなboostを使い続け、std名前空間を汚染するゴミが残るだけという

423 :デフォルトの名無しさん:2009/03/28(土) 14:18:37
という意見をぜひ comp.std.c++ あたりに投稿してくれ

日本の総意ってことで

424 :デフォルトの名無しさん:2009/03/29(日) 10:22:55
> range based algorithmの採用も却下されたことだし
( ゚д゚)

425 :デフォルトの名無しさん:2009/03/30(月) 13:50:22
配列初期化の記述だけはサッサと実現してほしい。

426 :デフォルトの名無しさん:2009/03/30(月) 19:48:55
関数型言語とC/C++の関数ってどういう関係?

427 :デフォルトの名無しさん:2009/03/30(月) 19:54:20
特に関係はない

428 :デフォルトの名無しさん:2009/03/30(月) 19:55:43
ちょっと確認。
cout<<boolalpha<<uppercase<<true;
ってした場合でも、TRUE(大文字)とは出力されないんだっけ?
それで規格どおり?

429 :デフォルトの名無しさん:2009/03/30(月) 20:14:51
>>427
そんなこともないだろ。両方関数だし。

430 :デフォルトの名無しさん:2009/03/30(月) 20:16:11
じゃあC/C++の関数が関数型言語とどう関係あるのか教えてよ

431 :デフォルトの名無しさん:2009/03/30(月) 20:22:42
関数型言語の関数は、数学的な関数ほぼそのもののことを指している。

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

432 :デフォルトの名無しさん:2009/03/30(月) 21:42:56
>>431
いや>>426は「関数型言語における関数と、C/C++における関数」の性質の違いを
知りたがっているのではなくて、「関数型言語」と「C/C++の関数」の関係を知りたがってる。
葉巻型UFOと日本たばこ産業の関係を質問するくらい、わけのわからない質問ではあるが。

433 :デフォルトの名無しさん:2009/03/30(月) 22:04:53
>関数型言語の関数は、数学的な関数ほぼそのもののことを指している。
>たまに数学的な関数のような性質を持ってることもある。
ん?どう違うの?

434 :デフォルトの名無しさん:2009/03/30(月) 22:20:25
http://ja.wikipedia.org/wiki/%E3%82%B5%E3%83%96%E3%83%AB%E3%83%BC%E3%83%81%E3%83%B3

435 :デフォルトの名無しさん:2009/03/30(月) 22:25:30
さすがwikipedia

436 :デフォルトの名無しさん:2009/03/30(月) 22:27:55
つまり状態の使用や副作用をおこさなければ関数型言語と等価ということですね。

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

438 :デフォルトの名無しさん:2009/03/30(月) 23:44:29
>>428
真偽値を表す文字列をnumpunctから取得して、
ストリームへ「インサートする」って書いてあるから、
uppercaseは適用されないね。
取得した文字列を再度operator<<するわけじゃないから。


439 :デフォルトの名無しさん:2009/03/30(月) 23:46:01
それで自分流のnumpunctを定義する方法は、
22.2.8.13に例が挙げてある。

440 :デフォルトの名無しさん:2009/03/31(火) 09:00:20
その筋の用語では「参照透明性」な

441 :デフォルトの名無しさん:2009/03/31(火) 10:01:21


442 :デフォルトの名無しさん:2009/03/31(火) 16:41:02
美少女中学生のおなら?

443 :428:2009/03/31(火) 19:51:14
>>438-439
ありがと。
規格の該当パラグラフも確認しました。

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

444 :デフォルトの名無しさん:2009/03/31(火) 20:30:21
そうそう。
結局、os << b ? "TRUE" : "FALSE";を関数にまとめればいいやというとこに落ち着いちゃうんだよね。

445 :438:2009/04/02(木) 17:10:08
本来の主旨とちょっと違ってくるけど、
マイ書式には引数付きマニュピュレーター使って
その中で出力しちゃってる。

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

446 :デフォルトの名無しさん:2009/04/02(木) 18:39:32
美少女中学生の話題をしようぜ!

447 :デフォルトの名無しさん:2009/04/02(木) 23:27:37
女子中学生をいじったら汁が出てきたよ(^−^)

448 :428:2009/04/03(金) 21:06:55
>>445
あー、たしかにマニピュレータはよさそう。
また機会があったらオレもそうしよ。

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


449 :デフォルトの名無しさん:2009/04/04(土) 00:34:14
>>448
C++相談室でいいよ。だいたい規格ガチで文句言われるスレなんてないだろ。

450 :デフォルトの名無しさん:2009/04/04(土) 15:20:15
ここは標準化委員会の迷走を横目で生暖かく見守るスレです

451 :デフォルトの名無しさん:2009/04/05(日) 01:16:11
そんなんだから日本からのコメントがrejectされまくるんだよ。

452 :デフォルトの名無しさん:2009/04/05(日) 01:21:45
あれは結構な割合で、rejectされるだろうけど一応送っておくか、的な雰囲気のものが入っていた気がする。

453 :デフォルトの名無しさん:2009/04/05(日) 02:50:54
どーせ仕事じゃ誰も使わないよ。

454 :デフォルトの名無しさん:2009/04/05(日) 03:45:10
>>452
Unicode関係とか結構気合い入れて議論してたんじゃないの?
サックリrejectされてて笑ったが

455 :デフォルトの名無しさん:2009/04/05(日) 16:09:19
あんなコメント読まされる方もたまったもんじゃない。
かなり基本的な部分でUTF-8前提にしろとかもうアホかと。

456 :デフォルトの名無しさん:2009/04/05(日) 17:24:29
ttp://ja.wikipedia.org/wiki/ビャーネ・ストロヴストルップ

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



457 :デフォルトの名無しさん:2009/04/05(日) 20:12:24
ttp://www.research.att.com/~bs/bs_faq.html#pronounce
ttp://www.research.att.com/~bs/pronounciation.wav

どのへんが近いんだ?

458 :デフォルトの名無しさん:2009/04/05(日) 20:34:26
そうだよな、「すっぽすっぽ」じゃなくて「すぽっすぽっ」だろ?

459 :デフォルトの名無しさん:2009/04/05(日) 20:41:39
JPのコメントにすぽすぽも呆れとったわ

460 :デフォルトの名無しさん:2009/04/05(日) 23:11:55
とりあえず提案だけは出しておこうってのはどう考えても間違いだったな
無理なものは無理と委員会で止めるべきだった

461 :デフォルトの名無しさん:2009/04/06(月) 01:07:29
説明が足りてるか、表現が正確か、おかしな解釈が出来てしまわないか、あたりの確認なのに
JPだけ変な気合い入れて新機能の提案みたいなことしてて明らかに浮いてる
恥ずかしいわ

462 :デフォルトの名無しさん:2009/04/06(月) 01:09:30
そんなことに恥ずかしがるのはJPだけ
みんな言いたいこと言ってる

463 :デフォルトの名無しさん:2009/04/06(月) 04:26:23
「スドゥハウっスドホッブ」を「すっぽすっぽ」のリズムで読めば良い。
strou と strup の間の「っ」(stød) で声門を絞めるのが肝

464 :デフォルトの名無しさん:2009/04/06(月) 09:22:45
肛門が閉まりました。
つーか読みにくい時は、呼び名つけるだろ?
てきとうに、太郎とかつけりゃいいんだよ。

465 :デフォルトの名無しさん:2009/04/06(月) 09:46:58
禿

466 :デフォルトの名無しさん:2009/04/06(月) 10:19:55
そんな議論はどこで読めるんですか?

467 :デフォルトの名無しさん:2009/04/06(月) 10:35:34
>>457
ほんとだ、「びや〜ね=すぽっすぽっ」に聞こえる。

468 :デフォルトの名無しさん:2009/04/06(月) 14:42:26
あまりの卑猥さに美少女中学生も赤面!!!!!!1111

469 :デフォルトの名無しさん:2009/04/06(月) 18:44:45
生粋のデニッシュには言いやすい発音なんだろうな

470 :デフォルトの名無しさん:2009/04/07(火) 15:54:36
C++0x出たらJAVAとかいらなくなるんだよね?
またCさえあればいい時代が来るってことか

471 :デフォルトの名無しさん:2009/04/07(火) 18:39:09
Javaがどうなるかは知らんが、0xはGC付き言語の代わりにはならんよ

472 :デフォルトの名無しさん:2009/04/07(火) 19:16:45
Javaと対抗になるのはC#とC++/CLIだわな

473 :デフォルトの名無しさん:2009/04/08(水) 04:33:23
D…いやなんでもない

474 :デフォルトの名無しさん:2009/04/08(水) 06:13:38
>>473
Delphiですね、わかります

475 :デフォルトの名無しさん:2009/04/08(水) 08:57:43
C# vs Java
F# vs Scala
C++ vs D…いやなんでもない

476 :デフォルトの名無しさん:2009/04/08(水) 10:49:00
>>473-475
おまいらとは別スレであってるような気がしてならない

477 :デフォルトの名無しさん:2009/04/08(水) 12:02:15
>>458
http://twitter.com/finalfusion/status/1469586480

478 :インドリ:2009/04/09(木) 10:06:39
http://blogs.wankuma.com/episteme/archive/2009/04/08/171040.aspx
http://d.hatena.ne.jp/faith_and_brave/20090408

479 :デフォルトの名無しさん:2009/04/09(木) 13:49:35
> 税込2,940円

高い!

480 :デフォルトの名無しさん:2009/04/09(木) 14:23:51
淫鳥

481 :デフォルトの名無しさん:2009/04/09(木) 17:17:02
まあ、どうせ某所にうpされるだろうし
そうなったら眺めてみるか

482 :デフォルトの名無しさん:2009/04/09(木) 17:31:41
C++でこの手の本を書くと、バッドノウハウの詰め合わせみたいになるのは必至だろ…

483 :デフォルトの名無しさん:2009/04/09(木) 17:37:08
だがそれがいい

484 :デフォルトの名無しさん:2009/04/10(金) 00:19:14
びよーんすぽっすぽっ

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

485 :デフォルトの名無しさん:2009/04/10(金) 00:44:38
バッドでもナンでも成程と思わせる何かが含まれてるかどうか
邦人の著者は入門レベルでお茶濁すパターンの繰り返しだからねぇ

486 :デフォルトの名無しさん:2009/04/10(金) 01:18:06
>>484
「びよーん」じゃないよ「びや〜ね」だよ。

487 :デフォルトの名無しさん:2009/04/10(金) 01:49:46
MC++Dの焼き直しみたいな本じゃなけりゃいいけどな

488 :デフォルトの名無しさん:2009/04/10(金) 02:01:02
参考書買ったつもりが
中身は校正不足な教科書崩れですタ
みたいな

489 :デフォルトの名無しさん:2009/04/10(金) 02:16:06
入門書はもういいよ

490 :デフォルトの名無しさん:2009/04/10(金) 02:39:24
ガチガチの数学選書みたいにまともなコンパイラもない今の時点での0xの応用を書いてある本がほしいです。

491 :デフォルトの名無しさん:2009/04/10(金) 12:08:52
どうせ著者のブログ記事の焼き直しでしょ

492 :デフォルトの名無しさん:2009/04/10(金) 14:04:27
誰も仕事じゃ使わんだろ。

493 :デフォルトの名無しさん:2009/04/10(金) 19:13:34
>>490
つ 規格書


494 :デフォルトの名無しさん:2009/04/10(金) 20:34:27
規格書に応用なんて書いてないだろ。

495 :デフォルトの名無しさん:2009/04/12(日) 03:56:21
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww

496 :デフォルトの名無しさん:2009/04/14(火) 20:39:55
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww

497 :デフォルトの名無しさん:2009/04/15(水) 00:29:40
    _, ._
  ( ・ω・)
  ○={=}〇,
   |:::::::::\, ', ´
.wwし w`(.@)wwwwwwwwwwwwwww
   ~~~~~

498 :デフォルトの名無しさん:2009/04/15(水) 00:33:54
テンプレートクラスを入れ子にすると>>演算子が優先されてエラーになることが何度かあったんだが
これって次で直るかなぁ? 演算子の優先度の問題だから無理だよな・・・?

499 :デフォルトの名無しさん:2009/04/15(水) 00:39:49
>>498
C++0xでは vector<vector<int>> も大丈夫

500 :デフォルトの名無しさん:2009/04/15(水) 02:19:16
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html
これな
gcc 4.3では取り込まれてる

501 :デフォルトの名無しさん:2009/04/15(水) 02:20:57
まあ、読みづらいから俺は空白であけるけどな

502 :デフォルトの名無しさん:2009/04/15(水) 23:37:36
ビルド通らないから空白あけてるけどさw
3つ以上入れ子にすると逆に見づらいというか、typedefつかえってことか。

503 :デフォルトの名無しさん:2009/04/16(木) 01:44:57
そんなに入れ子にしたら、遅くてたまらんだろ。

504 :デフォルトの名無しさん:2009/04/16(木) 01:55:51
それほどでもない

505 :デフォルトの名無しさん:2009/04/16(木) 12:48:27
いや遅いって。
javaや.netよりかなり遅くなるぞ。

506 :デフォルトの名無しさん:2009/04/16(木) 12:50:07
遅いってコンパイルの話じゃなかったの?

507 :デフォルトの名無しさん:2009/04/16(木) 17:40:23
何だそりゃ?

508 :デフォルトの名無しさん:2009/04/16(木) 18:14:57
javaや.netよりかなり遅くなるって何のネタだよw

509 :デフォルトの名無しさん:2009/04/16(木) 18:32:55
コンパイルの時間の話なら、そんな入れ子にしなくても元から十分遅いし。

510 :デフォルトの名無しさん:2009/04/16(木) 18:34:26
コンパイルはC++よりC#の方が速いって話でしょ。実行速度の話じゃない
でもMPLでもやらない限りテンプレートはあまり関係ないと思うけどね

511 :デフォルトの名無しさん:2009/04/16(木) 19:47:04
MPL = MetaProgramming Library な。

512 :デフォルトの名無しさん:2009/04/16(木) 21:35:25
TMP!TMP!

513 :デフォルトの名無しさん:2009/04/16(木) 21:36:15
vectorを三つ入れ子にしたら、実行速度は確かにスゲー遅くなるだろうな。

514 :デフォルトの名無しさん:2009/04/16(木) 21:42:46
MPL() { 笑 };


515 :デフォルトの名無しさん:2009/04/17(金) 02:17:16
実行速度の話だろ?
バカなのか?お前らは。

516 :デフォルトの名無しさん:2009/04/17(金) 04:37:53
誰が真の馬鹿なのかは、俺の心の中にしまっておくよ。

517 :デフォルトの名無しさん:2009/04/17(金) 06:16:19
そこでしか生きられない言い分だものな。

518 :デフォルトの名無しさん:2009/04/17(金) 08:47:38
みんなでシャドーボクシング

519 :デフォルトの名無しさん:2009/04/17(金) 10:02:29
じゃあこの山括弧をくっつけて動くようにしろよ!

520 :デフォルトの名無しさん:2009/04/17(金) 10:15:20
     lヽ ノ l        l l l ヽ   ヽ
  )'ーーノ(  | |  | 、      / l| l ハヽ  |ー‐''"l
 / M  | | |/| ハ  / / ,/ /|ノ /l / l l l| l  M ヽ
 l   ・  i´ | ヽ、| |r|| | //--‐'"   `'メ、_lノ| /  ・  /
 |  P  l  トー-トヽ| |ノ ''"´`   rー-/// |  P |
 |  ・   |/     | l ||、 ''"""  j ""''/ | |ヽl  ・ |
 |  L   |       | l | ヽ,   ―   / | | l  L  |
 |   !!  |     / | | |   ` ー-‐ ' ´|| ,ノ| | |  !! |
ノー‐---、,|    / │l、l         |レ' ,ノノ ノハ、_ノヽ
 /        / ノ⌒ヾ、  ヽ    ノハ,      |
,/      ,イーf'´ /´  \ | ,/´ |ヽl      |
     /-ト、| ┼―- 、_ヽメr' , -=l''"ハ    |  l
   ,/   | ヽ  \  _,ノーf' ´  ノノ  ヽ   | |
、_    _ ‐''l  `ー‐―''" ⌒'ー--‐'´`ヽ、_   _,ノ ノ
   ̄ ̄   |           /      

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

521 :デフォルトの名無しさん:2009/04/17(金) 11:00:58
c++で何でわざわざ遅いプログラムつくらなあかんのか。
メタなんて価値なしのオナニーだよな。

522 :デフォルトの名無しさん:2009/04/17(金) 11:06:51
はいはいクマクマ

523 :デフォルトの名無しさん:2009/04/17(金) 17:18:26
JVM向けのコンパイラ書く奴いねぇかなぁ。
そしたら、ワザワザJavaに書き換える事もなくなって便利なんだが。

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

524 :デフォルトの名無しさん:2009/04/17(金) 17:49:55
>>519
なるよ。

525 :デフォルトの名無しさん:2009/04/18(土) 01:38:10
VECTOR3つでも用途によるだろ。
いまどき遅いといっても知れてるわ。

526 :デフォルトの名無しさん:2009/04/18(土) 02:31:07
数えられる程度にしか回らないコード部分なら結果が正しければ少々何しようと勝手だよな

527 :デフォルトの名無しさん:2009/04/18(土) 04:00:06
まったくだ
とはいえ、vectorを三つも入れ子にするようなコードが
数えられる程度にしか回らないケースって少ないような気もするけどな

528 :デフォルトの名無しさん:2009/04/18(土) 08:28:02
>>513は知恵おくれだろ
馬鹿馬鹿しいからスルー推奨

529 :デフォルトの名無しさん:2009/04/18(土) 10:49:30
>>528
知恵遅れはお前だろカスだな。

530 :デフォルトの名無しさん:2009/04/18(土) 12:17:11
本人登場。幼稚なオウム返しによって相手の見方が正しいと証明してしまいました。

531 :デフォルトの名無しさん:2009/04/18(土) 12:35:00
読み書きの速度は配列と変わんないですよね?
サイズ変更は起こらないケースで

532 :デフォルトの名無しさん:2009/04/18(土) 13:05:02
違う。配列とは別物なんだから変わってもおかしくない。コンパイラの頑張り次第。

533 :デフォルトの名無しさん:2009/04/18(土) 13:12:48
コンパイラ?

534 :デフォルトの名無しさん:2009/04/18(土) 13:19:00
コンパイラ∋オプティマイザ

535 :デフォルトの名無しさん:2009/04/18(土) 13:21:05
>>532
別物なんですか?どう違うんですか?

536 :デフォルトの名無しさん:2009/04/18(土) 13:21:59
同じだよ。

537 :デフォルトの名無しさん:2009/04/18(土) 13:41:32
配列とvectorは全く同じというわけではない。
でも要素を指すポインタの配置だとかの制限が多々あって、
vectorの内部構造は配列を使うことが多い。
その場合、最適化次第で配列とほぼ同じ速度で動かせる。

538 :デフォルトの名無しさん:2009/04/18(土) 15:02:39
どちらかというと
たいていの場合はまったく同じ速度で動かせる、のが正しいだろ

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

539 :デフォルトの名無しさん:2009/04/18(土) 15:04:19
operator[]をいちいち呼び出すかもしれないって事でわ?

540 :デフォルトの名無しさん:2009/04/18(土) 15:12:03
実測しろ。

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

541 :デフォルトの名無しさん:2009/04/18(土) 15:19:17
実測、実測って、様々なプラットフォームで実行するプログラムはどうするんだよ。
何でもアホみたく実測する前に、一般論で考察しろ。

542 :デフォルトの名無しさん:2009/04/18(土) 15:27:11
>>541
様々なプラットフォームで実測して、場合によっては最適な実装を
コンパイラスイッチで切り替えるぐらいはしてもいいんじゃない。

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

543 :デフォルトの名無しさん:2009/04/18(土) 15:29:40
実測馬鹿

544 :デフォルトの名無しさん:2009/04/18(土) 15:34:52
なんちゃってー!カクカクカクカクカク!

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

546 :デフォルトの名無しさん:2009/04/18(土) 17:12:51
激烈バカとはなつかしい

547 :デフォルトの名無しさん:2009/04/18(土) 19:31:45
カクカクと聞いていやらしいことを想像してしまった美少女中学生がこのスレにいます!

548 :デフォルトの名無しさん:2009/04/18(土) 23:16:36
>>540
保証されてない

549 :デフォルトの名無しさん:2009/04/18(土) 23:18:40
されてるよ。

550 :デフォルトの名無しさん:2009/04/18(土) 23:26:03
当初03の規格には入ってなかったんだけど
後から委員会のほうで「そういう風に作ってね」って付け加えたんだっけか。
いずれにしても現在では保証されてたはず。

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

552 :デフォルトの名無しさん:2009/04/19(日) 01:42:29
まあ、むやみに大きさかえまくってたら遅いだろうけど、そういう場合はlist使うだろうし
どっちにしろ入れ子にしなきゃならんものは、Cで書いてもそれなりに重い処理になる。

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

553 :デフォルトの名無しさん:2009/04/19(日) 02:34:15
伸びてたから期待して来たのにこんな流れかよ…
ムーブセマンティクスがどう効くかとかarrayと比べてどうとかいう話かと思ったのに
03以前だけの話ならSTLスレでやれよ

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

555 :デフォルトの名無しさん:2009/04/19(日) 09:32:40
>>552
それはないだろ。

556 :デフォルトの名無しさん:2009/04/19(日) 14:49:10
3重vectorの話がでてたけど、
vectorってムーブセマンティクスやCOW
の実装あるんだっけ?

557 :デフォルトの名無しさん:2009/04/19(日) 18:23:47
あるよ。

558 :デフォルトの名無しさん:2009/04/19(日) 21:42:09
素朴な疑問すまん。
C++0xってx=9になるの?
それともなんかしくじって、
C++1xに続くの?

559 :デフォルトの名無しさん:2009/04/19(日) 21:57:41
もう09にはならないはず

560 :デフォルトの名無しさん:2009/04/19(日) 22:02:11
C++0xAでも0xBでもいいから早く出て来い。

561 :デフォルトの名無しさん:2009/04/19(日) 22:10:10
>>558
八進数なのに9はない。

562 :デフォルトの名無しさん:2009/04/19(日) 22:20:41
なんで八進数なんだろね。
K&Rもビット演算で八進数使うんだよね。
二進数と十六進数しかなじみのなかった自分は
ちょっとデカルチャーだった。

563 :デフォルトの名無しさん:2009/04/19(日) 22:32:06
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww

564 :デフォルトの名無しさん:2009/04/19(日) 23:51:30
C言語 → UNIX → PDP-11
後はもう分かるな?

565 :デフォルトの名無しさん:2009/04/20(月) 00:10:43
わからない

566 :デフォルトの名無しさん:2009/04/20(月) 00:48:32
1バイト9ビットのマシンだと八進法も使う機会があると聞いたことがあるけど、PDP-11は違うよね?

567 :デフォルトの名無しさん:2009/04/20(月) 04:06:37
二進数ベースの数値を10キー(の数字)だけで二進数直打ちよりは楽に入力できるからだよ。

568 :デフォルトの名無しさん:2009/04/20(月) 08:23:01
x == 10 (ローマ数字)という
無理矢理解釈で2010年リリースか?

569 :デフォルトの名無しさん:2009/04/20(月) 09:06:44
昔はコンソールにテンキーしかない計算機たくさんあったから。
だから昔の人は基本8進数と10進数。
古いアセンブラの仕様を漁れば分かる。

570 :デフォルトの名無しさん:2009/04/20(月) 09:35:47
それはない

571 :デフォルトの名無しさん:2009/04/20(月) 09:47:51
>>561
標準化まえのCの処理系では'\91'(=73)とかできたらしい。

572 :デフォルトの名無しさん:2009/04/20(月) 23:35:57
例えテンキー入力でも 「8」 「9」キーででもシフト管理すれば簡単に 16進打ち 可能じゃん
char get(char k){
static char f=0;
if(k==9){f=8;return 16}
if(k==8){f=0;return 16}
if(k>=0&&k<=7) return k|f;
つらつら;
}

573 :デフォルトの名無しさん:2009/04/21(火) 03:28:00
>>572
歴史も現場も知らない人間の机上の発想だな。同様のことを考えた人はいたかもしれんが表に出て主流になることはなかった、ってのはそういうことだ。

574 :デフォルトの名無しさん:2009/04/21(火) 03:50:52
歴史を知っていると、10キーのカンマや演算子をa-fに割り当てる入力ツールを思い出せるんだけどね。
まぁ、>569はどうかと思うけれど。

575 :デフォルトの名無しさん:2009/04/21(火) 08:01:02
10キー使わないし

576 :デフォルトの名無しさん:2009/04/21(火) 08:11:18
俺もテンキー嫌いだし一生使うことは無いと思ってたが、
携帯のせいでテンキー的なものを強要されるようになったな。



577 :デフォルトの名無しさん:2009/04/21(火) 08:15:48
>>568
ローマに0はなかった…

578 :デフォルトの名無しさん:2009/04/21(火) 11:22:50
>>576
やっぱりテレビのチャンネルを変えるときは本体のを回したりするんですね

579 :デフォルトの名無しさん:2009/04/21(火) 12:38:39
そういう人は、チャンネルを「変える」じゃなくて、
「回す」って言うらしいぞ。

580 :デフォルトの名無しさん:2009/04/21(火) 18:19:48
>>569
当時は逆にテンキーがなかったんじゃ。
タイプライターにはテンキーなんかないし、
今と違ってスイッチいっこが高かった
だろうし。

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


581 :デフォルトの名無しさん:2009/04/21(火) 18:30:00
テンキーしかないコンピュータってのはマイコンキットとかだな。

582 :デフォルトの名無しさん:2009/04/21(火) 18:42:28
>>569はど素人

583 :576:2009/04/21(火) 21:01:55
>>578
携帯やパソコンのテンキーは少なくとも一秒に3タイプくらいは出来ないと効率悪すぎるし、
テレビのリモコンは30分に1タイプできれば十分事足りるからな。
それとこれとは話が全然違うだろうとマジレスしておく。



584 :デフォルトの名無しさん:2009/04/21(火) 21:05:27
玄人はこんなスレに来ません

585 :デフォルトの名無しさん:2009/04/21(火) 21:33:04
回される想像をしてドキドキしている美少女中学生がこのスレにいる!

586 :デフォルトの名無しさん:2009/04/21(火) 22:58:32
>>581
大丈夫、マイコンキットならきっと16キーだ。

587 :デフォルトの名無しさん:2009/04/22(水) 03:42:50
>>566
マジレスするとインストラクションの基本形式が
16bit を 1+3, 3+3, 3+3 に分解して使ってたから
octal の方が表現しやすかった.


588 :デフォルトの名無しさん:2009/04/22(水) 13:40:15
いつまで続けるんだ

589 :デフォルトの名無しさん:2009/04/22(水) 15:18:38
単にioが四ビットだった名残だろ。

590 :デフォルトの名無しさん:2009/04/22(水) 15:50:01
4ビットなら8進より16進の方が都合いいだろ

591 :デフォルトの名無しさん:2009/04/22(水) 15:50:11
それだったら別に8じゃなくても16でもいいはず。

592 :デフォルトの名無しさん:2009/04/24(金) 12:57:24
8進数なら九九の代わりに七七を覚えれば暗算できるけど、16進でffとなると厳しいと思うぞ。

593 :デフォルトの名無しさん:2009/04/24(金) 14:22:27
>>592
インドに行って来い

594 :デフォルトの名無しさん:2009/04/24(金) 14:27:58
インドでは99*99まで暗記するらしいな

595 :デフォルトの名無しさん:2009/04/24(金) 14:38:46
19*19らしいぞ?
そして、なんと小学校の必須科目に「プログラム」があるそうだ。

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

596 :デフォルトの名無しさん:2009/04/24(金) 15:54:33
偉大な文明は多数の労働力を隷属させることにより築かれるものなのだ

597 :デフォルトの名無しさん:2009/04/24(金) 17:22:19
いつの時代の話?

598 :デフォルトの名無しさん:2009/04/24(金) 18:58:52
そろそろスレ違い過ぎてる

599 :デフォルトの名無しさん:2009/04/24(金) 22:16:57
すれ違いの恋ばかりの美少女中学生・・・

600 :デフォルトの名無しさん:2009/04/24(金) 23:44:59
>>594
サンスクリット語は数体系が複雑すぎて、
99×99まで暗記しないとろくに計算できないというのが実情らしいけど。

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

601 :デフォルトの名無しさん:2009/04/25(土) 00:10:51
>>600
どうやらそのようだな。
100まで暗記が必要らしい。
ttp://www.sf.airnet.ne.jp/~ts/language/number/hindij.html

602 :デフォルトの名無しさん:2009/04/25(土) 01:04:42
外から見ると、インド人すげー、99×99覚えるんだ
実際を見ると、言葉が使いにくいからやむなく覚えてる

それなんてC++?

603 :デフォルトの名無しさん:2009/04/25(土) 11:21:54
っていうか、インドは言語の数があまりに多いのと
学問に向いてないのとで、大学では英語でしょ?
小学校でも英語の授業があるらしいし。

604 :デフォルトの名無しさん:2009/04/25(土) 11:30:31
日本語だって日付の読み方とか不規則で滅茶苦茶だけど日本人はみんな普通に読めてるし
ネイティブにはそれくらいあんまり気にならないと思うけどなぁ

605 :デフォルトの名無しさん:2009/04/25(土) 11:48:50
残念、ヒンズーを筆頭にフランス語も暗算には向かない数の読み上げ方をするんだ。
例えばフランス語の99の読み上げを直訳すると、「4つの20と9足した10」になるらしい。

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

606 :デフォルトの名無しさん:2009/04/25(土) 12:54:48
>>605
99 は 4つの20と10-9 だとおもう (quatre-vingts-dix-neuf.)
93 とかのほうがひどい。(quartre-vingts-treize は 4x20+"3+10".)
フランス語地域でもスイス/ベルギーは nonante-neuf,
nonante-cinq に変えたはず。

607 :デフォルトの名無しさん:2009/04/25(土) 15:18:03
>>604
数システムが複雑な言語では、暗算できない子供が多いみたいな統計もあるらしいけど。
フランス語もその筆頭。

608 :デフォルトの名無しさん:2009/04/25(土) 17:00:19
中国が漢字を一定量覚えないと
手紙もまともにかけないという現状を憂慮して
簡体字を導入したように、
おフランスも暗算が簡単になるように数字の読みを
国策で変更すべき^^

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

609 :デフォルトの名無しさん:2009/04/25(土) 20:02:26
その頃日本では、三桁のかけ算とか普通は電卓使うから別に教えなくていいよね、とかやってたわけだな。

610 :デフォルトの名無しさん:2009/04/25(土) 20:59:30
イギリスにも正字運動があったし、日本にもローマ字化運動があった。

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

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

611 :デフォルトの名無しさん:2009/04/25(土) 21:48:32
「正字運動」でググったら、そうゆう流れもあるのかって思った。
おもしろい。

612 :デフォルトの名無しさん:2009/04/25(土) 23:23:56
なんだこの流れwwwwww
正式版が出たgcc4.4のc++0x対応の話とか出てないのかwwww

613 :デフォルトの名無しさん:2009/04/26(日) 00:21:40
GCCで盛り上がってるかと思ったのに…
なんじゃこりゃ

614 :デフォルトの名無しさん:2009/04/26(日) 00:29:47
このスレに日本語情報の少ない0xについて語れる奴なんていないよ

615 :デフォルトの名無しさん:2009/04/26(日) 00:42:56
まあ、われわれ下々のものは、ちゃんと提供されてそれ以外選択肢がなくなってからが出番だ。

616 :デフォルトの名無しさん:2009/04/26(日) 03:42:10
これくらい張ってもバチは当たんないよな。
http://gcc.gnu.org/gcc-4.4/cxx0x_status.html

617 :デフォルトの名無しさん:2009/04/26(日) 09:35:14
Conceptが入ってないから基本的にどうでもいいな。
Variadic templateは既に使ってるけど。4.4の前からあるからね。

618 :デフォルトの名無しさん:2009/04/26(日) 12:42:34
差分はこっちの方が見やすい
http://gcc.gnu.org/projects/cxx0x.html

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

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

619 :デフォルトの名無しさん:2009/04/26(日) 18:39:03
これなんて虫?
http://2sen.dip.jp/cgi-bin/upgun/up1/source/up26459.jpg


620 :デフォルトの名無しさん:2009/04/26(日) 18:40:50
グロ注意

621 :デフォルトの名無しさん:2009/04/26(日) 18:45:51
おもちゃ。

622 :デフォルトの名無しさん:2009/04/26(日) 19:09:57
ムカデ

623 :デフォルトの名無しさん:2009/04/26(日) 19:16:27
独習デザインパターンC++は参考になるね。

624 :デフォルトの名無しさん:2009/04/26(日) 19:44:38
ムカデじゃなくヤスデの仲間だな

625 :デフォルトの名無しさん:2009/04/26(日) 20:34:17
ムカデは各節に一対 -( )-
ヤスデは各節に二対 =( )=

626 :デフォルトの名無しさん:2009/04/26(日) 20:43:56
オライリー本でこんなのがあったら
さすがに売り上げ減るだろなw

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

627 :デフォルトの名無しさん:2009/04/26(日) 22:39:49
ヤスデのグロ画像からオライリー本の話に行くところが素敵だ。


628 :デフォルトの名無しさん:2009/04/27(月) 01:19:02
最近トビケラとカワゲラとカゲロウを見分ける勉強を始めた俺に隙は無かった

629 :デフォルトの名無しさん:2009/04/27(月) 01:50:01
> 最近トビケラとカワゲラとカゲロウを見分ける勉強を始めた
なんでだよw佃煮でも作るのか?

630 :デフォルトの名無しさん:2009/04/28(火) 01:38:04
言語仕様にPascalで可能な関数内関数を導入するように標準化委員会に言ってくれ。

631 :デフォルトの名無しさん:2009/04/28(火) 01:46:47
ラムダ式と新関数構文を統合してついでにローカル関数も入れようという壮大な提案がある(N2825)

無理だと思うけど

632 :デフォルトの名無しさん:2009/04/28(火) 07:35:09
もう無茶苦茶だな

633 :デフォルトの名無しさん:2009/04/28(火) 13:23:59
C++の関数内関数はもう20年も前から提案されたり採用されなかったり
してるよね。

634 :デフォルトの名無しさん:2009/04/28(火) 13:46:38
なんでローカル関数一つが採用できないのかわからん。

635 :デフォルトの名無しさん:2009/04/28(火) 14:33:34
ただ己の欲求を満たすだけのために仕様作ってんだろ。
こんなの仕事で使えるか!

636 :デフォルトの名無しさん:2009/04/28(火) 14:35:41
関数内クラスで用満たせるから

637 :デフォルトの名無しさん:2009/04/28(火) 14:38:20
関数内関数を実現するためだけに定義された関数内構造体を何度見てきたことか…

638 :デフォルトの名無しさん:2009/04/28(火) 15:38:23
関数内関数の実現は面倒なんだよ。内側の関数から外側の関数のローカル変数を
参照していて、内側の関数へのポインタを他に渡してる場合。
Usenix-88-lexic.pdf でも嫁

639 :デフォルトの名無しさん:2009/04/28(火) 15:51:58
関数内クラスならstaticメンバ関数のポインタを関数外に出してもローカル変数には触れられないしコンパイラ作る方は楽だな

640 :デフォルトの名無しさん:2009/04/28(火) 21:29:09
ラムダ式がちゃんと導入できれば副産物として簡単に実装できるはずなんだがな

641 :デフォルトの名無しさん:2009/04/28(火) 21:44:20
>>631に戻る

642 :デフォルトの名無しさん:2009/04/28(火) 23:47:27
>>638
とりあえずレキシカルクロージャ抜きで関数だけでも定義させてくれれば良いのに…

643 :デフォルトの名無しさん:2009/04/28(火) 23:55:37
ローカル関数何に使うの?

644 :デフォルトの名無しさん:2009/04/28(火) 23:58:59
プログラム書くのに使う

645 :デフォルトの名無しさん:2009/04/29(水) 00:01:35
C++/Cでもみんなプログラム書いてるよ

646 :デフォルトの名無しさん:2009/04/29(水) 00:10:04
ローカル変数にアクセスできるインライン(のみの)関数が一番いいと思う

647 :デフォルトの名無しさん:2009/04/29(水) 00:12:53
グローバル変数にアクセスできない関数とかってないの?

648 :デフォルトの名無しさん:2009/04/29(水) 00:51:07
>>643
sortに渡す比較関数とか即席で作りたいことあるじゃん。

649 :デフォルトの名無しさん:2009/04/29(水) 01:00:01
ローカルクラスはテンプレート引数に渡せないからなぁ

650 :デフォルトの名無しさん:2009/04/29(水) 01:02:31
>>648
正直どうでもいいな

651 :デフォルトの名無しさん:2009/04/29(水) 01:39:10
無名関数でおk

652 :デフォルトの名無しさん:2009/04/29(水) 04:08:45
関数内クラスを活用しだすと
関数の中身が九割九分クラスになって残りはチョロっとしたループや分岐だけに成ったりするが
これが不思議とメンテしやすいんだょな・・

653 :デフォルトの名無しさん:2009/04/29(水) 05:26:32
おぞましいコード書いて悦にはいってんなょ

654 :デフォルトの名無しさん:2009/04/29(水) 08:27:02
高度なコードは理解できないという理由で拒絶する奴が出てくるのが困りもの

655 :デフォルトの名無しさん:2009/04/29(水) 08:55:16
高度なコードと聞いてケラケラと笑う美少女中学生

656 :デフォルトの名無しさん:2009/04/29(水) 09:53:00
お前の勘違いぶりは犯罪者級

657 :デフォルトの名無しさん:2009/04/29(水) 11:50:30
しかし、それが適性あり。

658 :デフォルトの名無しさん:2009/04/29(水) 16:53:21
三項演算子はバグの元。

659 :デフォルトの名無しさん:2009/04/29(水) 17:02:57
条件演算子と呼べって美少女中学生が嘆いてた

660 :デフォルトの名無しさん:2009/04/29(水) 18:02:55
条件演算子以外の三項演算子ってどんなのがあるのさ?:

661 :デフォルトの名無しさん:2009/04/29(水) 18:12:50
参考に聞かせてもらおうか、ですね わかります


662 :デフォルトの名無しさん:2009/04/29(水) 18:29:18
それは演算子なのか?

663 :デフォルトの名無しさん:2009/04/29(水) 18:37:57
>>658
君はプログラミングやめた方がいい

664 :デフォルトの名無しさん:2009/04/29(水) 19:17:26
>>663
俺が言ったことじゃなくて、人から言われたことです

665 :デフォルトの名無しさん:2009/04/29(水) 19:41:00
>>664
なんの免罪符にもなってない

666 :デフォルトの名無しさん:2009/04/29(水) 19:43:55
C言語の話ではないがCを参考にした演算子系を持ってる言語で第2項に順次式おいたときとか()でくくらずに条件式を項にしたときとかの挙動が信用できない。

667 :デフォルトの名無しさん:2009/04/29(水) 19:48:15
>>664
傷口が広がるだけだぜ

668 :デフォルトの名無しさん:2009/04/29(水) 19:55:12
>>667
何で?

669 :デフォルトの名無しさん:2009/04/29(水) 20:11:12
>>664
ありそうでなかったパターンのいいわけだな。

670 :デフォルトの名無しさん:2009/04/29(水) 20:16:14
レベルの低い現場で言われたこと無い?
三項演算子禁止とか。
>653-654の流れで書いたんだが

671 :デフォルトの名無しさん:2009/04/29(水) 20:19:20
レベルの低い現場に加わるのは、
それなりのレベルの低さが要求されるので、
残念ながら未体験です。


672 :デフォルトの名無しさん:2009/04/29(水) 20:21:15
ああ。やっと流れが飲み込めた。
レベル低くてすまんかった

673 :デフォルトの名無しさん:2009/04/29(水) 22:46:55
で、三項演算子が0xで何か変わったのかね?

674 :デフォルトの名無しさん:2009/04/29(水) 22:48:28
発端は何気ない美少女中学生のつぶやき

675 :デフォルトの名無しさん:2009/04/29(水) 22:50:06
gcc4.4のautoの使い心地とか誰か報告してくれよ

676 :デフォルトの名無しさん:2009/04/29(水) 22:51:29
ローカルでstaticでない変数をauto変数って言ってたけど、違う意味になってしまった。

677 :デフォルトの名無しさん:2009/04/29(水) 22:53:13
で、使い心地は?

678 :デフォルトの名無しさん:2009/04/29(水) 23:02:47
つかったことがありません。

679 :デフォルトの名無しさん:2009/04/29(水) 23:05:36
使い心地も何も、新しい機能は何も無くて、自明な宣言の文字数を
省略できるだけだから、何も変らないんじゃね?
後方互換性を気にするなら、愚直に今まで通り宣言するだけだし。

680 :デフォルトの名無しさん:2009/04/29(水) 23:06:08
たとえばイテレータを書くときとか便利そうだね。
つかったことないけどね。Auto。。。

681 :デフォルトの名無しさん:2009/04/29(水) 23:13:38
結局新機能なんか誰も使わないってことか
そうだよな、互換性考えたら使えるわけないよな

682 :デフォルトの名無しさん:2009/04/29(水) 23:33:46
>>681
C++に新たなパラダイムを与えるものならともかく
auto は打つ文字数が減って腱鞘炎が直りました、
ぐらいしか変わらないという意味。

683 :デフォルトの名無しさん:2009/04/30(木) 00:46:40
大事じゃねぇか、「腱鞘炎が直りました」。


684 :デフォルトの名無しさん:2009/04/30(木) 00:54:09
auto が一般的になればテンプレートの中で演算し放題なパラダイスが訪れるよ。

685 :デフォルトの名無しさん:2009/04/30(木) 01:19:11
>>682
でも右辺値参照も誰も使ってないぞ
4.3からだから入ってから大分経つのに

686 :デフォルトの名無しさん:2009/04/30(木) 02:58:28
マクロだとautoは便利。

687 :デフォルトの名無しさん:2009/04/30(木) 08:31:39
>>684
D言語のように静的に文字列弄れる訳でもなし、戻り値推論(以下)できる訳でもなし、C++0x程度じゃまだまだ。
auto Square(T)(T t)
{
    return t * t;
}

688 :デフォルトの名無しさん:2009/04/30(木) 08:57:44
戻り値推論って有れば便利だけどさ、その程度の関数だったら、これでよくね

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

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

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

689 :デフォルトの名無しさん:2009/04/30(木) 09:48:57
>動的に返す型が変わるような関数
?
returnが二つ以上ある関数のこと言っているなら両方の共通の型になる。

690 :デフォルトの名無しさん:2009/04/30(木) 09:55:47
いや、

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

みたいな。

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

691 :デフォルトの名無しさん:2009/04/30(木) 10:10:41
>>690
動的にって言うけど、それってコンパイル時に静的に解決しなきゃいかん問題だよね。

692 :デフォルトの名無しさん:2009/04/30(木) 10:11:38
>>690
C++で>>687は出来ないよ。

693 :デフォルトの名無しさん:2009/04/30(木) 11:14:12
>>690
intとlongならlongだし、A派生のBとA派生のCならAだし。

694 :デフォルトの名無しさん:2009/04/30(木) 11:27:03
auto func = objf_list<>::choice(any);
auto x = func();

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

695 :デフォルトの名無しさん:2009/04/30(木) 19:41:06
>>688
今でも条件演算子でそういう状況になるので、
そのときどうなるかは決まっている。
それは戻り値推論でもそのまま採用すべきかものどうかは分からないけど。

696 :デフォルトの名無しさん:2009/05/02(土) 00:05:47
ラムダ式は簡単な戻り値推論できるから、関数構文と統合されれば
>>688ならこう書けるはず

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

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

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

698 :デフォルトの名無しさん:2009/05/02(土) 06:16:54
&&とか、本気なのか?
ワザと誤解して間違いそうな文法考えて、「分かるヤツだけが分かる!」
って、選民意識を得るために作ってるとしか思えん。
もうちょっと分かりやすいのを考えてほしい・・・

699 :デフォルトの名無しさん:2009/05/02(土) 06:35:56
>>697
そこでキーワードをnothrowにしないのは意地?

700 :デフォルトの名無しさん:2009/05/02(土) 08:08:24
何の意地かは分からんがnothrowの方が分かりやすいのは確かだな

701 :デフォルトの名無しさん:2009/05/02(土) 08:40:31
exceptの方が明示的でいいかな
「投げません」って言われても「何を?」って思うけど
「例外無し」って言われると「ああ、例外無いんだ」って思う

702 :デフォルトの名無しさん:2009/05/02(土) 09:10:40
nothrowはすでに標準ライブラリに存在している名前だから無理っしょ

703 :デフォルトの名無しさん:2009/05/02(土) 09:43:56
>>702
何のための名前空間。

704 :デフォルトの名無しさん:2009/05/02(土) 09:50:52
次期標準にしようとしているのに?

705 :デフォルトの名無しさん:2009/05/02(土) 09:54:43
みんな使わないのに標準?

706 :デフォルトの名無しさん:2009/05/02(土) 10:01:34
>>703
名前空間で対策できるってことは予約語じゃなくて単なる識別子として導入?
そんなきもいのマジ勘弁

707 :デフォルトの名無しさん:2009/05/02(土) 10:06:00
throw 1;って例外を投げてることになる?

708 :デフォルトの名無しさん:2009/05/02(土) 10:55:23
なる。

709 :デフォルトの名無しさん:2009/05/02(土) 12:03:47
>>706
まさにその通り。
operator new 関数に nothrow_t 型を引数として受け取るオーバーロードがある。
で、

struct nothrow_t {};
extern const nothrow_t nothrow;


710 :デフォルトの名無しさん:2009/05/02(土) 12:07:23
>>709
いや、それがあるからキーワードとして nothrow を追加するのは無理ってことだろ。

711 :デフォルトの名無しさん:2009/05/02(土) 13:23:41
attributeでいいじゃん…とおもったらattributeじゃダメな理由も書いてるな

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

712 :デフォルトの名無しさん:2009/05/02(土) 14:58:33
C++0xがマトモに使われるとは思えなくなってきた。
C99と同じ道をたどるんじゃ。

713 :デフォルトの名無しさん:2009/05/02(土) 15:04:38
initializer_listとかが一部で使われるくらいだろうなぁ

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

714 :デフォルトの名無しさん:2009/05/02(土) 15:13:24
boostの中の人のような変態の為の機能だから普通にC++を使う人が使わないぐらいなら想定内


715 :デフォルトの名無しさん:2009/05/02(土) 15:15:15
コンセプトはexport(笑)と同じ道を辿るだろう
誰も実装しない、出来ない

716 :デフォルトの名無しさん:2009/05/02(土) 15:16:31
コンセプトは標準ライブラリやBoostの中で使われれば十分だよ。
テンプレートが関わるエラーメッセージの改善という程度のことに役立つと信じて。

717 :デフォルトの名無しさん:2009/05/02(土) 15:17:41
いや、exportとは違うさ。
conceptを使うことには利点があるのだから。
exportは、コンパイル時間を多少短くできるってことぐらいしか利点がないから。
conceptなしでは、C++0xは語れないぜ。
C++0xの多くの機能が、conceptを前提にしているんだから。exportとはわけがちがう。

718 :デフォルトの名無しさん:2009/05/02(土) 17:02:49
でも実装が出来ないんじゃなぁ
conceptGCCとかいつまでやってんだよ
主な商用コンパイラも軒並みガン無視だし

719 :デフォルトの名無しさん:2009/05/02(土) 17:04:22
conceptの実装は時間がかかるぞ。
だいたい、中途半端な実装をリリースして、互換性の問題を引き起こしてもらっても困る。

720 :デフォルトの名無しさん:2009/05/02(土) 17:10:02
互換性は諸刃の剣だな

721 :デフォルトの名無しさん:2009/05/02(土) 17:11:48
conceptGCCはもう開発してないと思う…
9ヶ月くらい更新止まってるし、その前は1年3ヶ月更新止まってたし
http://www.generic-programming.org/software/ConceptGCC/download.php

722 :デフォルトの名無しさん:2009/05/02(土) 18:19:16
>>719
vcの人は1年くらいかかるとか言ってたな
vc11には入るんだろうか…?

723 :デフォルトの名無しさん:2009/05/02(土) 19:22:41
本家の concept ブランチでやってるんじゃないの?と思ったら
>At present, the concepts branch provides almost no support for concepts.
ttp://gcc.gnu.org/projects/cxx0x.html
とか書いてあるな、おい。
更新も 10 ヶ月止まってるっぽい。
ttp://gcc.gnu.org/viewcvs/branches/cxx0x-concepts-branch/

724 :デフォルトの名無しさん:2009/05/02(土) 20:24:59
GCCが匙を投げたとなると他も追従するかもしれないな
コンセプトオワタ

725 :デフォルトの名無しさん:2009/05/02(土) 20:57:43
まさに絵に描いた餅ですね

726 :デフォルトの名無しさん:2009/05/02(土) 21:08:03
コンパイラ開発者は標準化委員会にいないの?

727 :デフォルトの名無しさん:2009/05/02(土) 21:28:52
少数で開発してるD言語にもコンセプト的な何かはあるのに、
GCCが実装できないってのは、C++の言語仕様の複雑さを物語っているようだ。

728 :デフォルトの名無しさん:2009/05/03(日) 17:42:07
規模と実装難易度を考えりゃ、Concept以外が全部実装されてからやっと本腰入れてConceptに取りかかるくらいのもんだろう。
4.5で何が実装されるかってだけでもwktk出来るさ。

729 :デフォルトの名無しさん:2009/05/03(日) 17:54:55
コンセプトがないと拡張for文もきないしライブラリの作り直しにも本腰入れられないだろ
さっさとしてくれ

730 :デフォルトの名無しさん:2009/05/04(月) 00:35:12
言語オタクな連中に規格を作らせるからこんな事になるんだ

731 :デフォルトの名無しさん:2009/05/04(月) 01:36:56
そうだよな。実務的な言語がものすごくキモい化物になって行く様は、おぞましい。

732 :デフォルトの名無しさん:2009/05/04(月) 01:58:18
現状維持派 → 表に出てこない
変えたい派 → 騒ぐ

止める人がいない

733 :デフォルトの名無しさん:2009/05/04(月) 08:44:52
HTML5ワークショップの実務に即した仕様策定がうらやましい

734 :デフォルトの名無しさん:2009/05/04(月) 13:08:00
それが真実なら、とうの昔に標準GCが規定されてるはずだ

735 :デフォルトの名無しさん:2009/05/04(月) 23:47:01
しかし、本当にjavaより速いプログラムを作るのが難しい言語になって行くなァ。

736 :デフォルトの名無しさん:2009/05/04(月) 23:49:21
それはない。

737 :デフォルトの名無しさん:2009/05/04(月) 23:58:25
VCが新ライブラリへの対応だけでも迅速に進めてくれればいいや
特に cstdint と regex

738 :デフォルトの名無しさん:2009/05/05(火) 00:02:29
>>735
とりあえず
> どんどん〜なっていく
っていうのは無いはず。


739 :デフォルトの名無しさん:2009/05/05(火) 00:24:22
i = i++ の結果は未定義なのでしょうか?

740 :デフォルトの名無しさん:2009/05/05(火) 00:35:11
未定義じゃないと思う。

741 :デフォルトの名無しさん:2009/05/05(火) 00:36:57
a[i++] = i;
の動作は未定義だそうだ

742 :デフォルトの名無しさん:2009/05/05(火) 00:37:51
根拠

743 :デフォルトの名無しさん:2009/05/05(火) 00:43:30
>>739
http://codepad.org/JCtHYXzj

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

744 :デフォルトの名無しさん:2009/05/05(火) 00:49:59
単にその処理系でそうなるだけなのか、C++でそういう定義なのか、分からないだろ。

745 :デフォルトの名無しさん:2009/05/05(火) 00:51:04
(´・ω・`)知らんがな
まぁ誰かが調べるまで気長に待てばいいじゃない

746 :デフォルトの名無しさん:2009/05/05(火) 00:54:58
未定義というよりは不定なのかな?

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

747 :デフォルトの名無しさん:2009/05/05(火) 00:56:34
「未定義」と「不定」を区別するならそれぞれの定義を。

748 :デフォルトの名無しさん:2009/05/05(火) 01:02:01
とりあえず++演算子は右辺に置くなということで。
「未定義or不定だからヤメロ」って言えれば楽なんすけどねー。

>>746
wktk

749 :デフォルトの名無しさん:2009/05/05(火) 01:02:10
区別はここみてそういう区別があるんだと思ったから

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

750 :デフォルトの名無しさん:2009/05/05(火) 01:04:54
補足
http://www.st.rim.or.jp/~phinloda/cqa/cqa7.html#Q8

未定義だそうだ。

751 :デフォルトの名無しさん:2009/05/05(火) 01:06:29
おまえら揃いも揃ってスレタイよめないのか


752 :デフォルトの名無しさん:2009/05/05(火) 01:12:15
739程度が一目で未定義とわからない奴らが新規格のスレに何の用だ

753 :デフォルトの名無しさん:2009/05/05(火) 01:19:27
>>739-750

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

754 :デフォルトの名無しさん:2009/05/05(火) 01:44:52
>>737
Regexは2008 SP1の時点で登載済み。TR1としてだけど。

755 :デフォルトの名無しさん:2009/05/05(火) 02:10:50
TR1との違いってコンセプト対応してるかどうかくらいだっけ?

756 :デフォルトの名無しさん:2009/05/05(火) 06:35:57
テンプレくらい読んでから質問しろ

757 :デフォルトの名無しさん:2009/05/05(火) 06:37:42
>>752
Sequence pointsすら分からない奴が、
まだ確定してない規格知ろうなんて十年早いよな。

758 :デフォルトの名無しさん:2009/05/05(火) 11:16:01
はいはいすごいすごいえらいえらいかしこいかしこい

759 :デフォルトの名無しさん:2009/05/05(火) 12:34:08
フィンローダなつかしいなー
あのころはCマガ面白かった

760 :デフォルトの名無しさん:2009/05/05(火) 20:38:35
>>736
経験不足のおバカさんだな。

761 :デフォルトの名無しさん:2009/05/07(木) 12:23:26
0xとあんま関係ないけど、UNICODEソースは仕様上なんか規程されてるの?
まぁ、サポートされてても日本語でソース書こうなんて思わないけどさぁ。

762 :デフォルトの名無しさん:2009/05/07(木) 15:42:59
日本語で書けるなら書きたい

763 :デフォルトの名無しさん:2009/05/07(木) 15:49:00
ソースコードに実装依存の文字が使えるということになっている。
まあ、今までも、C++のコンパイラは、ほぼ例外なく実装依存の文字が、少なくとも文字列リテラルやコメント内で使えたし、
いまさら規定しても何も変わらないと思うが。

764 :デフォルトの名無しさん:2009/05/07(木) 18:58:57
「実装依存の文字」の話はしていない。
UNICODEの話をしている。

765 :デフォルトの名無しさん:2009/05/07(木) 19:40:52
実装依存か・・・。VCでこんなコードも
通るんだが、現場とかで見るよう担ったらヤダなぁ、
変換するのがダリぃ。
int 二乗(int 引数)
{
 return 引数*引数;
}


766 :デフォルトの名無しさん:2009/05/07(木) 19:54:44
識別子に漢字が使えるのはC++0xの仕様?
コンパイラーの仕様?

767 :デフォルトの名無しさん:2009/05/07(木) 20:18:28
>>764
「ソースコード」の文字列に関しては、何にも規定されてないと思うんだけど。

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


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

768 :デフォルトの名無しさん:2009/05/07(木) 20:30:09
>>767
二点質問があります。
「その他」ではない文字は何ですか?
C++0xに対応したコンパイラーが必ず使えなければいけない(移植性のある)文字セットは何ですか?

769 :デフォルトの名無しさん:2009/05/07(木) 20:58:57
その他ではない文字というのは、

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

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

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

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

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

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

int あいう = 0 ;

770 :デフォルトの名無しさん:2009/05/07(木) 21:12:15
フォワードスラッシュなのか…

771 :デフォルトの名無しさん:2009/05/07(木) 21:14:50
間違えたorz バックスラッシュだ。
int \u3042\u3044\u3046 = 0 ;

772 :デフォルトの名無しさん:2009/05/07(木) 21:16:53
自然数 エー 配列 代入 ここからゼロ、ワン、ツー、ここまで。
加速繰り返し 括弧 自然数参照 エヌ、エー 国家
ここから
 標準の黒板に 書き出せ エヌ 書き出せ 標準の行末。
ここまで

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

774 :デフォルトの名無しさん:2009/05/07(木) 23:00:49
>>772
#define駆使すればもっと自然な日本語にもできるぞ。

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

775 :デフォルトの名無しさん:2009/05/08(金) 13:43:40
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/#mailing2009-05

776 :773:2009/05/08(金) 18:59:34
訂正
> JIS X 3014:2003を読むと処理系依存にその他の文字とか全然ないですね。

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

777 :デフォルトの名無しさん:2009/05/08(金) 19:11:29
>>773
トライグラフの変換は?

778 :デフォルトの名無しさん:2009/05/08(金) 19:45:00
おちんちんがトライグラフ!美少女中学生も赤面!

779 :デフォルトの名無しさん:2009/05/08(金) 20:50:27
なんだ誰も mailing の話してないのか

780 :デフォルトの名無しさん:2009/05/08(金) 21:00:36
何それ

781 :デフォルトの名無しさん:2009/05/08(金) 21:11:47
少ないしあんまり面白いのないんだもん
「for The-C++-After-0x」とかいう気が早すぎる奴くらい

782 :デフォルトの名無しさん:2009/05/08(金) 21:13:52
好きな男子との間に生まれた子の名前を考えるほど気が早い美少女中学生の話で盛り上がっております

783 :773:2009/05/08(金) 21:35:43
>>777
トライグラフも同時だよ!

784 :デフォルトの名無しさん:2009/05/08(金) 22:32:40
>>781
なにげにあったら便利だね

785 :デフォルトの名無しさん:2009/05/09(土) 05:50:40
http://www.open-std.org/jtc1/sc22/wg21/
News 2009-05-08: The C++ Standard Core Language Issues List (Revision 63) is available
News 2009-05-08: The C++ Standard Library Issues List (Revision 64) is available

786 :デフォルトの名無しさん:2009/05/10(日) 19:46:37
g++ (GCC) 4.2.4って、C++0x 5対応済みなの?

787 :デフォルトの名無しさん:2009/05/10(日) 20:00:07
ここに載ってるのは 4.3 以降だな。
ttp://gcc.gnu.org/projects/cxx0x.html

788 :デフォルトの名無しさん:2009/05/10(日) 20:03:45
>>787
Thx

789 :デフォルトの名無しさん:2009/05/13(水) 18:52:20
美少女中学生が次のレスはまだかまだかとwktkしています

790 :デフォルトの名無しさん:2009/05/16(土) 16:21:23
保守

791 :デフォルトの名無しさん:2009/05/16(土) 21:40:17
C++0xって、本当に今年、出るの?
そう言う雰囲気を、ちっとも感じないのだが、
いきなり「出来ました」って出るの?

792 :デフォルトの名無しさん:2009/05/16(土) 21:41:00
予定は未定
この世界の納期は破るためにある

793 :デフォルトの名無しさん:2009/05/16(土) 22:15:03
Committee draft以降は各国の意見調整をしながら
投票の繰り返しになるから、まあ地味っちゃ地味。
サイトにDISって文字が現れだしたらゴールは近い。

794 :デフォルトの名無しさん:2009/05/17(日) 03:12:19
ラムダ周りが各国(日本除く)からフルボッコにされてるから簡単には終わらないと思う

795 :デフォルトの名無しさん:2009/05/17(日) 03:37:38
○○○ 2008が2007年に出たりするんだから
c++ 0xが2010年に出てもいいじゃないか

796 :デフォルトの名無しさん:2009/05/17(日) 03:54:57
○○○6月号は5月にでるんだから、C++0xは08年までに出さないといけなかった。

797 :デフォルトの名無しさん:2009/05/17(日) 04:14:25
0xって16進でしゅ。つまり2015まででしゅよ。by禿げ

798 :デフォルトの名無しさん:2009/05/17(日) 04:59:41
それなら0x0xと書くべき

799 :デフォルトの名無しさん:2009/05/17(日) 09:29:12
>>798
それだとやっぱり09年までだろ。
オプソ厨のアホさ此処に極まれりだな。

800 :デフォルトの名無しさん:2009/05/17(日) 09:34:36
>>799
with whom you are fighting?

801 :デフォルトの名無しさん:2009/05/17(日) 15:03:37
英語がわかんなくてあわあわする美少女中学生

802 :デフォルトの名無しさん:2009/05/17(日) 18:26:05
C++09 Attributes: Specify Your Constructs' Unusual Properties
ttp://www.devx.com/cplus/Article/41694?trk=DXRSS_LATEST

803 :デフォルトの名無しさん:2009/05/18(月) 07:27:37
"[[final]]"ってなんだよ・・・w
かっこはひとつでいいじゃん

804 :デフォルトの名無しさん:2009/05/18(月) 07:36:47
それはどんな識別子でもキーワードにできる魔法の括弧だよ。

805 :デフォルトの名無しさん:2009/05/18(月) 09:12:22
かっこわるい……

806 :デフォルトの名無しさん:2009/05/18(月) 09:22:55
lisp 属の () を笑えない変態構文だらけなんだが
こいつ等にシンタックスシュガーをかませようとか
ってな, 話はでてこない???


807 :デフォルトの名無しさん:2009/05/18(月) 09:36:57
C++の仕様考えてる人にはもはやLISPを笑わない人しか残ってないってことだろ。


808 :デフォルトの名無しさん:2009/05/18(月) 09:39:43
FC++で関数型言語汚染が酷い
mplやpreprocessorで「汚いlisp」汚染が酷い

809 :デフォルトの名無しさん:2009/05/18(月) 10:54:31
逆に考えるんだ
LISPこそ、全てのプログラミング言語の最終形態なのだと
全てのプログラミング言語はその進化の果てにLISPと同一化するのだと


810 :デフォルトの名無しさん:2009/05/18(月) 12:36:06
LISPは化け物だ。って格言無かったっけ。
すべてを飲み込んでしまうってやつ。

811 :デフォルトの名無しさん:2009/05/18(月) 14:08:04
俺は>>807の言う通りの人間だ。
C++0x萌え、CLOS萌え


812 :デフォルトの名無しさん:2009/05/18(月) 20:49:24
美少女中学生は余計なかっこつけが嫌いです。

813 :デフォルトの名無しさん:2009/05/18(月) 20:58:22
とゆうことは
「美少女中学生はC++0xが嫌いです」
でおけ?


814 :デフォルトの名無しさん:2009/05/18(月) 21:33:13
>>810
むしろ寄生虫じぇねーの?
いろんな言語に入り込んでるが、それ自体で使われることが少ないとかさ。


815 :デフォルトの名無しさん:2009/05/18(月) 21:36:27
>>814
ほえ?
他の言語が Lisp のアイデアパクリまくってても、それに対して何も言わないが

> それ自体で使われることが少ないとかさ
ここ数年ずっと Lisp で納品物作ってるwW


816 :デフォルトの名無しさん:2009/05/18(月) 22:24:34
いまPerlを勉強中
LISPよりしごと多そう

817 :デフォルトの名無しさん:2009/05/18(月) 22:33:15
>>815
是非御社で働かせていただきたいでつ ><


818 :デフォルトの名無しさん:2009/05/19(火) 04:11:41
>>815
ほえ、じゃねーよ。なめんなよ。

819 :デフォルトの名無しさん:2009/05/20(水) 23:21:35
美少女中学生なんじゃねーの?

820 :デフォルトの名無しさん:2009/05/21(木) 05:18:19
はにゃ〜ん

821 :デフォルトの名無しさん:2009/05/21(木) 18:47:30
和訳:Rvalue References: C++0x Features in VC10, Part 2
http://d.hatena.ne.jp/ntnek/20090210/p1

822 :デフォルトの名無しさん:2009/05/21(木) 20:07:42
3ヶ月前じゃん


まあ有用だとは思うが

823 :デフォルトの名無しさん:2009/05/27(水) 21:05:44
comp.std.c++ に Scott Mayers がすごい勢いで投稿してるけど
Effective の新版でも書き始めたんかな?

824 :デフォルトの名無しさん:2009/05/28(木) 01:13:13
ものすごい勢いでcobol化していくc++。

825 :デフォルトの名無しさん:2009/05/28(木) 06:42:15
>>823
どっちかというとC++0xに向けての改正版作成のためっぽい

826 :デフォルトの名無しさん:2009/05/28(木) 07:01:05
>>824
COBOLというよりPL/Iの時の悲劇を思い出させる

巨大化しすぎてまともに使いこなせるユーザーがほとんどいなかった

827 :デフォルトの名無しさん:2009/05/28(木) 07:04:25
PL/IとMulticsの失敗による教訓からUNIXとC:言語が生まれたが
時代はまた繰り返そうとしている

複雑化する一方のC++とWindows

828 :デフォルトの名無しさん:2009/05/28(木) 07:49:46
PL/Iは最初から巨大だったんじゃないのか。
だいたい名前からしてでかすぎるだろ。

829 :デフォルトの名無しさん:2009/05/28(木) 07:59:22
現時点でもPL/Iのマクロ>>C++のテンプレートくらいですね。

830 :デフォルトの名無しさん:2009/05/28(木) 08:55:26
C++0x を教訓により良い言語が生まれるならそれでいいじゃないか

831 :デフォルトの名無しさん:2009/05/28(木) 14:49:31
C++を代替可能なC++より良い言語なんてどこにあるんだ
あったら使いたい

832 :デフォルトの名無しさん:2009/05/28(木) 15:06:52
 D・・・いやなんでもない

833 :デフォルトの名無しさん:2009/05/28(木) 15:12:08
Dのテンプレートで浮動小数点とか文字列引数に取れるのはうらやましい。

834 :デフォルトの名無しさん:2009/05/28(木) 16:50:18
もう何年もC++使ってるから新しい仕様にも何とかついていけるが、
今からC++を始める人にとっては相当大変だろうな。
そして、禿はいつ第4版を書くのだろうか。

835 :デフォルトの名無しさん:2009/05/28(木) 18:26:21
別に全機能使うことはないだろう。STL使うだけでもわりと幸せ。

836 :デフォルトの名無しさん:2009/05/28(木) 19:06:53
Boost.ConceptCheckにはよく世話になってる

837 :デフォルトの名無しさん:2009/05/28(木) 19:13:58
STLをまともに使うのも意外と面倒だからな。

838 :デフォルトの名無しさん:2009/05/28(木) 21:44:03
Better Cで十分な漏れはなんでこのスレにいるんだろ?w

839 :デフォルトの名無しさん:2009/05/28(木) 23:29:36
最初のうちは関数オブジェクトを作る時にstd::unary_functionや
std::binary_functionを継承しなければならない理由がわからなかった

840 :デフォルトの名無しさん:2009/05/28(木) 23:30:47
いまでもわからずにやっているので教えてください

841 :デフォルトの名無しさん:2009/05/28(木) 23:38:12
STLスレででも聞け

842 :デフォルトの名無しさん:2009/05/28(木) 23:42:45
別に継承する必要はないんじゃ

843 :デフォルトの名無しさん:2009/05/29(金) 00:42:25
つーか継承前提のくせに仮想デストラクタ持ってない危険なクラスだから使っちゃダメっす

844 :デフォルトの名無しさん:2009/05/29(金) 01:13:15
でりげーと

845 :デフォルトの名無しさん:2009/05/29(金) 01:29:07
継承前提であっても基底クラスのポインタで多態させるような使い方はしないから問題ないだろ。

846 :デフォルトの名無しさん:2009/05/29(金) 01:37:25
という反論が来るのは分かり切ってたが、そんなの言い訳にならないと思うんだよな
unary_function*があらゆる場所で絶対にdeleteされないとどうして言い切れるのか

847 :デフォルトの名無しさん:2009/05/29(金) 01:53:23
本来はprotectedな非仮想デストラクタを提供すべきだった

848 :デフォルトの名無しさん:2009/05/29(金) 01:57:21
そもそも、unary_functionやbinary_functionは、テンプレート引数に関数オブジェクトを渡す時、
引数や戻り値を得るためのものなんだよ。
そもそもの想定されている使用方法が、ベースクラスで渡すものじゃないんだ。

お前の言い方は、

unique_ptrは、auto_ptrと違い、そのスコープ内のみがオブジェクトの生存期間だと明示できる、というけれど、
「何もしないdeleter」をunique_ptrに渡したら、auto_ptrみたいに使用できるじゃないか、
プログラマが絶対に、「何もしないdeleter」を書かないと、どうして言い切れるのか!

と言っているのと何ら変わりないんだよ。


849 :デフォルトの名無しさん:2009/05/29(金) 03:07:11
unary_functionやbinary_functionのやっている事は
実は単なるtypedefなんだけどな

これが無くても平気な関数アダプタはあるが、bind2nd()などは
無いとエラーを吐く

850 :デフォルトの名無しさん:2009/05/29(金) 03:11:23
decltypeがもっと早くからあれば、完全にダックタイピングでいけたんだろうか

851 :デフォルトの名無しさん:2009/05/29(金) 09:03:13
843みたいなアホがなんでこのスレにいんの?

unary_function/binary_functionは必要なtypedefを書くのをちょっと楽するためだけのもの
しかもbind1st/bind2nd使わないなら不要
さらにC++0xのbindには内部resultテンプレートがあれば引数型は固定でなくてよい
result_of<>はresult_typeもしくは内部resultテンプレートがあれば十分

ところでCallableコンセプトあればresult_ofいらなくね?

852 :デフォルトの名無しさん:2009/05/29(金) 09:17:04
>>851
コンセプト使うの前提にすれば、Type Traits系のライブラリなんて全部いらなくね?

853 :デフォルトの名無しさん:2009/05/29(金) 11:06:31
クラス組んじゃえばそうだろうけど、関数内でちまっと条件分岐させたいだけとかなら需要はいくらでもあるような。

854 :デフォルトの名無しさん:2009/05/29(金) 11:17:30
conceptを検討し始めた時の条件として、
既存のtraits系などと共存出来て、段階的に移行できること、
というのがあった。

>>839のようなケースはconcept_mapに集約されていくのだろうか…

855 :デフォルトの名無しさん:2009/05/29(金) 13:18:48
Douglas GregorがApple行ってConceptGCC止めちゃったから、
iteratorを整理したくらいでライブラリのconcept化は止まってるね。

856 :デフォルトの名無しさん:2009/05/29(金) 22:48:31
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww

857 :デフォルトの名無しさん:2009/05/30(土) 02:14:06
>>855
C++0xには入らないのだから、
ライブラリのコンセプト化は後回しだろうね。

858 :デフォルトの名無しさん:2009/06/03(水) 11:15:56
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww

859 :デフォルトの名無しさん:2009/06/03(水) 14:02:42
    _, ._
  ( ・ω・)
  ○={=}〇,
   |:::::::::\, ', ´
、、、、し 、、、(((.@)wwwwwwwww

860 :デフォルトの名無しさん:2009/06/03(水) 21:37:50
一瞬、ここがGrassスレになったのかと思った。


861 :デフォルトの名無しさん:2009/06/05(金) 23:37:58
>>851
not1、not2使うことって多くないのかな?

862 :デフォルトの名無しさん:2009/06/06(土) 12:32:49
>>861
多くはないだろ。jk


863 :デフォルトの名無しさん:2009/06/06(土) 16:48:27
みなさん新機能のチェック等に使うコンパイラは何でしょうか?
やはりGCC-4.4が多いのかな?

864 :デフォルトの名無しさん:2009/06/06(土) 21:11:04
>>863
gcc version 4.5.0 20090605 (experimental) (GCC)

865 :デフォルトの名無しさん:2009/06/06(土) 22:09:01
explicit変換関数が入ってるな

866 :デフォルトの名無しさん:2009/06/07(日) 00:21:16
>>834
頭がついていかなくなって、
もう10年近くほとんど使ってないや…。
テンプレートの暗黙的実体化のときに、
constのあるなしで別の型というので、わけわかめ。

自分でテンプレートをばりばり作って
プログラミングしてる人ってどのぐらいいるんだろうか。
型推論自体は便利なんだけど、テンプレートと組み合わさると、
中で何が起こっているのか、わけがわからん。

867 :デフォルトの名無しさん:2009/06/07(日) 00:23:16
>>866
> constのあるなしで別の型というので、わけわかめ。

特殊化で最適化したいことがあるから別扱いにします。
面倒だなと思うことの方が多いけど、慣れたらルーチンワークだし。


868 :デフォルトの名無しさん:2009/06/07(日) 00:35:05
むしろ、templateって
自分で作ったのしか使えなくね?
boost::ublasとか、デバッグ出来るかよあんなの

869 :デフォルトの名無しさん:2009/06/07(日) 00:50:12
テンプレートは全称修飾子

870 :デフォルトの名無しさん:2009/06/07(日) 15:36:05
http://atnd.org/events/702

http://124.45.27.25:12086/stream.mp3.m3u
IRCNET #CRYBUTSU


871 :デフォルトの名無しさん:2009/06/07(日) 17:34:18
ぶつぶつ会終わったよー

872 :デフォルトの名無しさん:2009/06/08(月) 14:12:38
D言語で言うところのLazyがほしい。

873 :デフォルトの名無しさん:2009/06/08(月) 15:12:12
ぶつぶつ会って東京タワーの近くでやってるあれのこと?

874 :デフォルトの名無しさん:2009/06/08(月) 21:08:43
皮膚病じゃないか?

875 :デフォルトの名無しさん:2009/06/09(火) 01:34:42
どうせなら本当の遅延評価が欲しいw

876 :デフォルトの名無しさん:2009/06/09(火) 09:46:14
徹底的な遅延評価て
ひたすら自己完結で計算するだけの言語ならかまわんけど
処理に紐付けしてのOSと遣り取りが本分のC++には邪魔になるだけだと思うがね

877 :デフォルトの名無しさん:2009/06/09(火) 21:40:10
申し訳ないが意味不明

878 :デフォルトの名無しさん:2009/06/10(水) 00:18:51
過去のコードとの互換性捨てて言語仕様組み直せばいいのに

879 :デフォルトの名無しさん:2009/06/10(水) 00:19:50
世の中にはそういう言語もあるから
そういうのがいい人はそっち使えばいいだけのこと

880 :デフォルトの名無しさん:2009/06/10(水) 00:20:22
>>878
それはそれで、Dっていういまいち普及の兆しすら見えないものがあるわけで。


881 :デフォルトの名無しさん:2009/06/10(水) 02:03:47
DはGCを(簡単には)取り外せないからC/C++の代わりにはならんよ
あれはどちらかというと出来の悪いC#

882 :デフォルトの名無しさん:2009/06/10(水) 11:56:14
DはできそこないのC++/CLIだろう。

883 :デフォルトの名無しさん:2009/06/10(水) 13:56:26
D言語は最近導入されたsharedのお陰でC言語/C++以上の最適化ができそうだね。以前gccの分岐の最適化によってLinux kernelでマルチスレッドのバグが起きたけど、これだとそれも防げそうだし。

他にも関数ハイジャック軽減法とか
http://www.kmonos.net/alang/d/2.0/hijack.html
例外安全なプログラミングとか(Boost.ScopeExitの元ネタ)
http://www.kmonos.net/alang/d/2.0/exception-safe.html
契約プログラミングとか
http://www.kmonos.net/alang/d/2.0/dbc.html
有用な提案がいっぱいあるが、C++との互換性の無さとライブラリの貧弱さと破壊的変更が多すぎることで台無し。
でもそれがいい。

884 :デフォルトの名無しさん:2009/06/10(水) 15:44:22
>>883
なんていうかありがとう

885 :デフォルトの名無しさん:2009/06/10(水) 21:24:46
Dの普及への前望が暗いことはよくわかった
0xと同じくらいには

886 :デフォルトの名無しさん:2009/06/10(水) 21:30:25
C++0xは普通に普及するぞ。

887 :デフォルトの名無しさん:2009/06/10(水) 21:38:24
しないだろ
最大の肝であるコンセプトを誰も実装できそうにない時点でもう無理
せいぜいSTLの実装で見えない所に右辺値参照が使われる程度に終わると思う

888 :デフォルトの名無しさん:2009/06/10(水) 21:48:30
autoとInitializer Listだけでも0x使うわ

889 :デフォルトの名無しさん:2009/06/10(水) 21:56:33
autoはイイな
もう糞長い型名を書くのはイヤだ・・・

890 :デフォルトの名無しさん:2009/06/10(水) 22:04:05
開発現場では禁止されそうだけどな
C#のverへの拒否反応を見るに

891 :デフォルトの名無しさん:2009/06/10(水) 22:07:35
しったか乙

892 :デフォルトの名無しさん:2009/06/10(水) 22:27:32
C++03 の正当なコードで C++0x だと不正になっちゃうものってどんなのがあるの?

893 :デフォルトの名無しさん:2009/06/10(水) 22:30:21
autoを記憶クラス指定子に使ってたり、
新予約語を変数名や関数名に使ってたり
SFINAEの挙動が変わった影響だったり

それくらい?

894 :デフォルトの名無しさん:2009/06/11(木) 07:09:05
>>887
右辺値参照は結構表立って使われると思うけどな
コピー不可のオブジェクトをコンテナに入れられるようにできるし

895 :デフォルトの名無しさん:2009/06/11(木) 20:54:09
しっかし、なんでここまで記号大好きなんだろう。
ワケワカめな構文だらけになっちゃって…。
それこそラムダ式なんて、lambdaとか予約語増やせばいいじゃん。

そもそも、デストラクタが「~クラス名」ってのから、
その傾向があったわけだが、もう一から文法考え直したほうがいいよ。
ツギハギだらけでばっちい。

896 :デフォルトの名無しさん:2009/06/11(木) 20:59:44
予約語増やすと過去のコードとの互換性が問題になるし
互換性を気にしないならD言語というアプローチがあるし
って、こういう話は1スレ内で10回くらい出てくるね

897 :デフォルトの名無しさん:2009/06/11(木) 21:02:09
それが普及しちゃった言語の宿命

後からそれ予約語になりましたとか言われても
困る人がいると

898 :デフォルトの名無しさん:2009/06/11(木) 21:27:28
キーワード接頭記号とかつくったらどうだ。
たとえば、「#」で始まる単語は全部キーワード。
#lambda
#funcdef
#null
プリプロセッサは廃止ってことで。

899 :デフォルトの名無しさん:2009/06/11(木) 21:29:54
そんなゴミイラネ

900 :デフォルトの名無しさん:2009/06/11(木) 21:30:11
C99では_Boolみないな変態キーワードが…。

901 :898:2009/06/11(木) 21:30:31
#はだめか。じゃあ、「$」はどうだ。

902 :デフォルトの名無しさん:2009/06/11(木) 21:34:24
そんなゴミイラネ

903 :デフォルトの名無しさん:2009/06/11(木) 21:35:40
$と@は使えません

というか、トライグラフやダイグラフみたいな有害なだけのクソ仕様を
ただ政治的な理由だけで入れざるを得なかったくらい苦労してる言語だぞ
記号関係はCの頃から予約語以上の鬼門

904 :デフォルトの名無しさん:2009/06/11(木) 21:43:14
大局的に見て、C++にはもう言語的に拡張性はない、と
素直に過去の資産、一度チャラって言えばいいのに

905 :デフォルトの名無しさん:2009/06/11(木) 21:47:11
>トライグラフやダイグラフ
正直アレらは丸ごと削除しても、現実的にあまり影響でないと思う。

906 :デフォルトの名無しさん:2009/06/11(木) 21:54:37
Pascalみたいにこういうのどうだ。

auto main(auto argc: int, auto argv: char **) : int

907 :デフォルトの名無しさん:2009/06/11(木) 22:09:56
Unicodeが仕様に導入される時代にトライグラフとかナンセンスすぎて笑い事じゃないよな
さっさとdeprecatedにして欲しい
どうせ不思議な力が働くから無理なんだろうけど

uR"[こんにちはrawリテラルです( ??'ω??')
でもトライグラフ様の変換が優先なので上の顔文字は( ^ω^)になります( ??'ω??')
ばかなの??(??= ??'ω??')死ぬの??
]"

908 :デフォルトの名無しさん:2009/06/11(木) 23:00:40
何がいけないって、前の標準化もそうだけど、
しめきり間際に、駆け込みで仕様が追加されること。
確かに、その機能自体は有用なんだが、文法のことももっと考えろと。

909 :デフォルトの名無しさん:2009/06/12(金) 00:12:57
けど良く考えてしまうと、
templeteを正定数で特殊化できたり、
その後の大爆発を引き起こしてしまう
ポテンホームランがなくなってしまうと思うの。
conceptやめてtraitsで頑張ろうとか。

910 :デフォルトの名無しさん:2009/06/12(金) 01:49:54
てかなんで、_Finalとかにしなかったの?
[[final]]きもすぎるだろ。

911 :デフォルトの名無しさん:2009/06/12(金) 01:57:11
よし、新しい言語を作ろう。

912 :デフォルトの名無しさん:2009/06/12(金) 02:05:40
C#やJavaやVB.NETはアプリケーションでいうならIEだ。
提供されたコンテンツをただ見るだけ。
C++はExcelだ。色々データを工夫してがんばる。そこにまた楽しみがある。
本来プログラムはC++程度までのものが一番楽しいとおもうんだが・・

これ以上C++を近代化しないでくれ。俺はC++が一番好きだ。

913 :デフォルトの名無しさん:2009/06/12(金) 02:07:40
C++は今のままにして、新しいのは、Reform C++とか別枠にしてください。

914 :デフォルトの名無しさん:2009/06/12(金) 02:50:47
C++じゃないC++作るくらいならDでいいじゃん

915 :デフォルトの名無しさん:2009/06/12(金) 09:12:26
そして >>880 に戻るw


916 :デフォルトの名無しさん:2009/06/12(金) 09:12:43
ゼロオーバーヘッドの原則は維持したまま、C++を改良しなおしてほしいなあ。
Objective-Cみたいに、CからC++のメンバ関数を呼び出したり、
クラスの中身をいじくりまわせたりするようになるとうれしい。

917 :デフォルトの名無しさん:2009/06/12(金) 12:20:48
0x のスレなのだから、提案されておらず、提出するつもりもない機能の話は、
例えば
C++ではこういう新しい機能が必要だと思う
http://pc12.2ch.net/test/read.cgi/tech/1173238573/l50
こういったような、ヨソのスレでやってくれないか。

あと、
C++は難しすぎ 難易度:4
http://pc12.2ch.net/test/read.cgi/tech/1221557484/l50
とか
C++ に未来はあるか??? そんなものはない!!!
http://pc12.2ch.net/test/read.cgi/tech/1178945996/l50
とか向けの話題もそれぞれのスレでよろしく頼む。

C++ に対する願望を書き込むのに、もう少しふさわしいスレがあったように思うが
落ちてるようだ。

0x への不満や愚痴はココでいいと思うのだけれども。

918 :デフォルトの名無しさん:2009/06/12(金) 12:28:26
むしろ class や各種の修飾子を記号にしてほしい。

919 :デフォルトの名無しさん:2009/06/12(金) 12:32:19
>>916
俺はむしろC互換じゃなくていい
DやAda95みたいな呼び出しインターフェースはないと困るけどね

で、俺の意見は「じゃあD使え」と言われるわけだ

920 :デフォルトの名無しさん:2009/06/12(金) 14:07:53
>>919
なんでないと困るんだ?
困る理由は?

921 :デフォルトの名無しさん:2009/06/12(金) 14:39:08
>>920
POSIXやWin32APIにアクセスできなくなるからでしょ
つかこれ系の話題はもういいよ

922 :デフォルトの名無しさん:2009/06/12(金) 17:00:34
結論:C++わ最強。

923 :デフォルトの名無しさん:2009/06/12(金) 18:11:30
コンパイルすると安全なC++ソースを作ってくれる程度のラッパー言語があればいいのに

924 :デフォルトの名無しさん:2009/06/12(金) 18:15:30
必要は発明の母じゃないか
がんばれ!

925 :デフォルトの名無しさん:2009/06/12(金) 19:05:46
じゃあ俺は、実数演算専用の言語が欲しい。
謎の技術で、C#とかのメソッド内に、
インラインで最適化されたネイティブコードを埋め込んでくれるやつ。
これがあれば、C++やめる。


926 :デフォルトの名無しさん:2009/06/12(金) 20:45:05
C++からCの関数を呼び出せるように、
旧C++を呼び出せる、新C++を作ればいいんだよ。
今だって、同じコンパイラにCモードとC++モードがあるんだから、
過去のコードまで同じモードでコンパイルできる必要ないよ。

927 :デフォルトの名無しさん:2009/06/12(金) 20:54:46
>>925
そういう用途には普通はBLASなどのライブラリを使うしそれで十分だろ。

928 :デフォルトの名無しさん:2009/06/12(金) 21:28:02
>>925
数値計算するなら OCaml とか使ってたほうがいいだろ

929 :デフォルトの名無しさん:2009/06/12(金) 21:42:38
>>928
それは極端すぎ

930 :デフォルトの名無しさん:2009/06/12(金) 21:44:41
C++に++を追加したらC#になったから、C#++を作るほうがいいとおもうよ。

931 :デフォルトの名無しさん:2009/06/12(金) 22:27:14
C#には今のところ++しなきゃならないようなパラダイムはないと思うけどな

コンセプト?いらんいらん

932 :デフォルトの名無しさん:2009/06/12(金) 22:50:30
テンプレート

933 :デフォルトの名無しさん:2009/06/12(金) 23:51:41
ジェネリクスはあるから十分だろ
TMPなんか出来ない方がいい

934 :デフォルトの名無しさん:2009/06/13(土) 00:12:41
十分じゃねーよ。バーカ

935 :デフォルトの名無しさん:2009/06/13(土) 00:30:42
テンプレートの代わりとして、C++のコンパイルの前に超高機能なプリプロセッサとか実行すればいいんじゃね?
hogehoge<foo>って書くと、プリプロセッサのhogehoge関数がfoo引数で呼び出されてC++のコードを生成するみたいな。

936 :デフォルトの名無しさん:2009/06/13(土) 00:35:02
0xの次はどうなるんだろうね。

937 :デフォルトの名無しさん:2009/06/13(土) 01:11:41
前例から考えたら、五年後に曖昧な部分を明確にするなどの、マイナーな改訂か。
ライブラリとかもっと増やして欲しいけど。

938 :デフォルトの名無しさん:2009/06/13(土) 01:18:21
>>918
つ Perl


939 :デフォルトの名無しさん:2009/06/13(土) 01:25:33
UNICODEをちゃんとサポートするんだから、
xmlの標準なライブラリが欲しいなぁ。
バリバリにイテレータとか使いまくってるようなの。

940 :デフォルトの名無しさん:2009/06/13(土) 02:42:56
>>935
それはDがCTFEという形で実現してる

941 :デフォルトの名無しさん:2009/06/13(土) 03:21:59
まさにD言語のCTFE+文字列mixinだね。
静的に文字列を弄ってコードを作りmixinできる。
デバッグが大変だけど。

942 :デフォルトの名無しさん:2009/06/13(土) 03:59:14
そんなことよりevalをですね。

943 :デフォルトの名無しさん:2009/06/13(土) 10:52:44
文字列mixinとかIDEやビルドツールを作るのが大変なんだよなぁ。
メンバの有無やimportの依存グラフを作るだけでコンパイラと同等の機能が必要になる。
Dはこの点C++より状況が悪くなっている。

944 :デフォルトの名無しさん:2009/06/13(土) 17:16:18
でもそれを実装しているIDEが既にあるからなぁ。

945 :デフォルトの名無しさん:2009/06/13(土) 17:23:17
Dの場合はコンパイル速いからIDEでもコンパイラ流用すればいいってかそうしてるんじゃないかね
C++だとそうはいかないかと

946 :デフォルトの名無しさん:2009/06/13(土) 20:18:10
いや、そのIDEのコードはJavaで書かれているって話だったような。

947 :デフォルトの名無しさん:2009/06/13(土) 20:29:17
そうかだからあんなに重いのか

948 :デフォルトの名無しさん:2009/06/13(土) 23:18:35
J++はネイティブコードを吐き出してくれて結構早かったし
Direct Xとかも自在に使えて便利だったのに、どうしてやめたのかしら?

949 :デフォルトの名無しさん:2009/06/14(日) 00:03:42
SUNが訴えたから

950 :デフォルトの名無しさん:2009/06/14(日) 02:33:15
ずるいよ、SUN・・・

951 :デフォルトの名無しさん:2009/06/14(日) 02:43:15
実は最初に実装した人が凄すぎて、誰も後メンテナンスできなくなった…とか利いたような気がするけど、本当かどうか走らない

952 :デフォルトの名無しさん:2009/06/14(日) 03:44:55
まあ、結果的にVC#ができて良かった。

953 :デフォルトの名無しさん:2009/06/14(日) 05:04:18
つ スレタイ

954 :デフォルトの名無しさん:2009/06/14(日) 05:28:10
もっと人間の脳味噌のキャパを超えないような言語を頼む。
できるだけ多くの人に使われなきゃ意味内と思うんだが。

955 :デフォルトの名無しさん:2009/06/14(日) 09:25:09
つ C

956 :デフォルトの名無しさん:2009/06/14(日) 11:54:06
>>955
その程度ならまだひとのほうがよゆうある。

957 :デフォルトの名無しさん:2009/06/14(日) 20:55:39
conceptやスレッド周りが実装されないと全体としては何とも言えないけど
いまgccやvcで使える範囲は全然余裕で使えるよ
むしろ、今まで「何故こう書けないようにしたし」って感じてたところが面白いくらいに解消される
lambdaの変態文法も、使いはじめてみれば普通に使えるっつーか短ければ短いほど使いやすいように感じてくる
使ってる記号([])は意味不明だけどね…

958 :デフォルトの名無しさん:2009/06/14(日) 23:03:29
C++は、悪臭を放つような過去の遺産を引き摺り続けてゆく。
悲しむべき事に、これは将来に渡って変わらない、決定事項なのだよ。

959 :デフォルトの名無しさん:2009/06/14(日) 23:07:15
C++の過去の遺産を整理するとC#になる。
悲しまずにC#を使えばいい。

960 :デフォルトの名無しさん:2009/06/14(日) 23:21:45
C#にはtemplateが無い

961 :デフォルトの名無しさん:2009/06/14(日) 23:24:09
なら過去の遺産と一緒にC++を使ってろ

962 :デフォルトの名無しさん:2009/06/15(月) 00:04:45
もちろんそうします

963 :デフォルトの名無しさん:2009/06/15(月) 00:09:30
genericじゃだめなん?

964 :デフォルトの名無しさん:2009/06/15(月) 00:18:12
黒柳徹子もそうしろっていってるしなぁ・・・

965 :デフォルトの名無しさん:2009/06/15(月) 00:29:24
C# もコンパイルする前に CFront 通すようにすればいいんでね?

966 :デフォルトの名無しさん:2009/06/15(月) 00:51:05
C++をいい感じに整理したらD言g・・
いや何でもない

967 :デフォルトの名無しさん:2009/06/15(月) 01:28:03
C#もDもC++とは違うでしょ
GCなしでオブジェクト指向を書ける言語は今もC++くらいしかない

968 :デフォルトの名無しさん:2009/06/15(月) 02:09:27
>>957
勘違いも甚だしい意見だな。
その結果出来上がったソースは、標準的な頭脳のキャパを超えてるだろ?
そして、スパゲッティ。

お前みたいなやつがいるから困る。

969 :デフォルトの名無しさん:2009/06/15(月) 02:30:15

釣りかな……

970 :デフォルトの名無しさん:2009/06/15(月) 02:38:49
むしろマ板でやってほしい話題だなそれ

971 :デフォルトの名無しさん:2009/06/15(月) 02:49:00
[](){} って (){} とも書けるのん?

972 :デフォルトの名無しさん:2009/06/15(月) 02:56:51
[]{} となら書ける

973 :デフォルトの名無しさん:2009/06/15(月) 04:48:39
残念

974 :デフォルトの名無しさん:2009/06/15(月) 05:21:58
>>957
D言語もGC無しで書けるよ。記述が長くなって面倒だけど。

975 :デフォルトの名無しさん:2009/06/15(月) 12:50:39
peRLとc++さえありゃ、大抵のアプリは組めるよ。

976 :デフォルトの名無しさん:2009/06/15(月) 13:20:41
美少女中学生はComeauに期待しています

977 :デフォルトの名無しさん:2009/06/15(月) 13:45:35
結局、負の遺産とやらを使わずにC++使うのが一番ということか

978 :デフォルトの名無しさん:2009/06/15(月) 14:01:44
>>977
言語の境界に触れずに使うのが賢いと思う。

979 :デフォルトの名無しさん:2009/06/15(月) 18:23:40
ヘンに先進的な機能も避けるべき。


980 :デフォルトの名無しさん:2009/06/15(月) 18:24:50
#include <iostream.h>のことですね、わかりますん。

981 :デフォルトの名無しさん:2009/06/15(月) 21:57:15
>>980
先進的ですね。

982 :デフォルトの名無しさん:2009/06/15(月) 22:42:58
そういやtemplateも例外も使ってるけど
iostreamはまともに勉強したこと無いわ

983 :デフォルトの名無しさん:2009/06/15(月) 22:57:07
export

984 :デフォルトの名無しさん:2009/06/15(月) 23:47:37
>>979
お前はマ板にでも行け

985 :デフォルトの名無しさん:2009/06/16(火) 00:19:35
そろそろ次スレですよ

986 :デフォルトの名無しさん:2009/06/16(火) 03:14:47
じゃあ次スレを0xとするか、1xとするか検討しようか。

987 :デフォルトの名無しさん:2009/06/16(火) 03:33:04
だがちょっと待って欲しい。
8進数と2進数の立場がないのは可哀想であろう。


988 :デフォルトの名無しさん:2009/06/16(火) 03:36:32
半年で1スレのペースだし0xでいいよ

989 :デフォルトの名無しさん:2009/06/16(火) 03:46:11
じゃあ次スレが最後の0xだな。
次スレ最後のコメントがC++2009完成ヤホーイになることを期待して・・・

ほい次スレ






・・・スレ立て規制ではじかれた(>_<)
誰かよろ

990 :デフォルトの名無しさん:2009/06/16(火) 03:58:35
ほい
http://pc12.2ch.net/test/read.cgi/tech/1245092251/

991 :デフォルトの名無しさん:2009/06/17(水) 00:08:09


992 :デフォルトの名無しさん:2009/06/17(水) 00:08:53


993 :デフォルトの名無しさん:2009/06/17(水) 00:09:44


994 :デフォルトの名無しさん:2009/06/17(水) 00:10:27


995 :デフォルトの名無しさん:2009/06/17(水) 00:11:08


996 :デフォルトの名無しさん:2009/06/17(水) 00:15:49


997 :デフォルトの名無しさん:2009/06/17(水) 00:17:07


998 :デフォルトの名無しさん:2009/06/17(水) 00:20:41


999 :デフォルトの名無しさん:2009/06/17(水) 00:22:12
正直期待外れだった

1000 :デフォルトの名無しさん:2009/06/17(水) 00:22:50
1000ならコンセプトdeprecated逝き

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

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

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