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

C++0x 3 at TECH

1:デフォルトの名無しさん
08/03/06 21:53:47
The C++ Standards Committee
URLﾘﾝｸ(www.open-std.org)

wiki
Wikipedia項目ﾘﾝｸ

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

2:デフォルトの名無しさん
08/03/06 21:56:56
>>1 乙++0x

3:デフォルトの名無しさん
08/03/06 22:26:28
>>1乙
by bjarne stroustrup

4:デフォルトの名無しさん
08/03/07 04:54:57
いちおつ
ばいびょーんすっぽすっぽ

5:デフォルトの名無しさん
08/03/07 06:43:35
>>1乙禿

6:デフォルトの名無しさん
08/03/07 08:18:13
うちの会社には３３歳の美少女がいる
ときどき小学生と間違われている
でも処女じゃない

7:デフォルトの名無しさん
08/03/07 08:19:09
>>1
wikiとwikipediaは違うぞw

MAILING 2008/02
URLﾘﾝｸ(www.open-std.org)

8:デフォルトの名無しさん
08/03/07 10:02:14
int otu(int x) { return x >>1; }

9:デフォルトの名無しさん
08/03/07 11:52:16
C++09/CLI とかヤル気あるんだろうか，マイクロソフト．
個人的には今の C++/CLI は好きだ．

10:デフォルトの名無しさん
08/03/07 11:53:24
spaced keywordとか馬鹿なことやっているところが、
標準準拠を重く見ているわけがないと思う。

11:デフォルトの名無しさん
08/03/07 13:23:22
spaced keyword 自体は標準で作る予定はないから、独自拡張で存在する分には
標準準拠の邪魔にはならないでしょ？

12:デフォルトの名無しさん
08/03/07 13:36:54
で，GCは入るのか入らないのか．
それによって俺の人生が・・・・

もう終わってるけど

13:デフォルトの名無しさん
08/03/07 13:41:43
今回は入らないはず。
けどベームさんが積極的にやってるから、
実装は今使える以上のものが出てくるんじゃないかな。

14:デフォルトの名無しさん
08/03/07 13:42:24
なんだよぉ，言語使用には入らないのか．
残念だな．まぁいいか．

15:デフォルトの名無しさん
08/03/07 13:49:34
>>12
イキロ

16:デフォルトの名無しさん
08/03/07 14:13:18
GC使いたいと思ったことがないのでよくわからん

17:デフォルトの名無しさん
08/03/07 21:54:28
boostのsharedポインターと比べて、GCって重いの？

18:デフォルトの名無しさん
08/03/07 22:00:00
あれって「ベーム」って読むのか……

19:デフォルトの名無しさん
08/03/07 22:10:33
>>17
ケースバイケース

20:デフォルトの名無しさん
08/03/07 22:14:10
ぼえへむヽ(´ー｀)ノぼえへむ

21:デフォルトの名無しさん
08/03/08 00:19:53
GC はあまり言語仕様に入れて欲しくはない。
標準ライブラリにあるのは別に構わんが。

C/C++ は色んな環境に使えることが肝なんだろうし、
そういうのは強制するもんじゃなくて
選択肢としてはありますが強制ではないですよってものであってほしい。

22:デフォルトの名無しさん
08/03/08 00:24:30
強制するしないと、言語側かライブラリ側かは別の問題だよ。
個人的には「強制しない」「言語側」を支持する。

23:デフォルトの名無しさん
08/03/08 00:42:54
gcnew みたいなやつか。
まさに C++/CLI だけど、あの珍妙な文法を見ると・・・。

24:デフォルトの名無しさん
08/03/08 00:59:21
C++/CLIは考え方としては悪くないと思う。でも確かに文法設計のセンスは悪い。

25:デフォルトの名無しさん
08/03/08 01:07:33
Foo<Hoge^>^
　　　　　　↑笑うなよ！

26:デフォルトの名無しさん
08/03/08 01:09:14
今や Unicode が普通なんだから、もうちょっとマシな文字を使えよ、ってかｗ

27:デフォルトの名無しさん
08/03/08 01:10:43
なんなんだろうな、あれは。
C++界隈で相当に有名な人が設計していて、
目指す方向は悪くないのに。
やっぱり言語設計は別物なんだな。

>>22
俺も言語側に何かないと今出てる以上のものは難しいと思う。
けど最低限のもので、汎用に使える聞こうにして欲しい。
まあ禿がいる限りそう言うものしか出てこないだろうけども。

28:デフォルトの名無しさん
08/03/08 01:12:33
Pascalの時代は、^を↑と表示するシステムがあったらしいが…

29:デフォルトの名無しさん
08/03/08 01:13:45
>>26
Foo<Hoge※>※

30:デフォルトの名無しさん
08/03/08 01:16:12
Foo<Hoge/>/

31:デフォルトの名無しさん
08/03/08 01:27:29
Foo<Hoge\>\
Foo<Hoge@>@
Foo<Hoge!>!
Foo<Hoge*>*

32:デフォルトの名無しさん
08/03/08 01:39:01
* に対応する記号としてはやはり / だな・・・。
積つながりの & は既にアドレスや参照で使われてるし。

33:デフォルトの名無しさん
08/03/08 01:42:56
Foo<Hoge/>/
ちょっとXMLっぽいｗ

34:デフォルトの名無しさん
08/03/08 10:28:02
>>26
m17n界隈にはcharacter set independenceとかISO 2022に執着してる
アンチUnicodeの人がまだ生きてるし、変換表地獄でリアルに困ってる人もいるから、
EBCDICを気にしなくていい環境でもASCIIの範囲をはみ出すのはやめた方がいい。
特にメタ文字に使うような記号類は化けやすいし文字幅問題も出てくるから。

35:デフォルトの名無しさん
08/03/08 10:50:56
女子中学生の話題でもちきりですね

36:デフォルトの名無しさん
08/03/08 12:35:01
gcc4.3ｷﾀｰ
URLﾘﾝｸ(gcc.gnu.org)
Status of Experimental C++0x Support in GCC 4.3

Rvalue references N2118 Yes
Rvalue references for *this N2439 No
Variadic templates N2242 Yes
Static assertions N1720 Yes
Declared type of an expression N2343 Yes
Right angle brackets N1757 Yes
Default template arguments for function templates DR226 Yes
Extern templates N1987 Yes

C99 Features in C++0x
__func__ predefined identifier N2340 Yes
C99 preprocessor N1653 Yes
long long N1811 Yes

もちろんg++起動オプションでオンにしたときだけ。
URLﾘﾝｸ(gcc.gnu.org)

37:デフォルトの名無しさん
08/03/08 12:48:43
こんせぷとまっぷはﾏﾀﾞｰ？

38:デフォルトの名無しさん
08/03/08 16:01:56
Right angle brackets N1757 Yes
うおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおお

39:デフォルトの名無しさん
08/03/08 16:26:47
ケータイからだとさっぱりわからん
詳しく

40:デフォルトの名無しさん
08/03/08 16:29:48
携帯からでも読んでワカラン奴は必要ないということ。

41:デフォルトの名無しさん
08/03/08 16:34:38
右辺値参照 N2118 Yes
*thisの右辺値参照 N2439 No
可変個引数テンプレート N2242 Yes
静的アサーション N1720 Yes
式に対するdecltype N2343 Yes
山括弧閉じの件 N1757 Yes
テンプレート関数のデフォルトテンプレート引数 DR226 Yes
Extern templates N1987 Yes

42:デフォルトの名無しさん
08/03/08 16:35:26
DR226ｷﾀｰ!

43:デフォルトの名無しさん
08/03/08 16:36:26
>>38
ｋｔｋｒ

44:デフォルトの名無しさん
08/03/08 16:38:50
結局、Proposed resolution (revised October 2002)でアクセプトされたのかな。
URLﾘﾝｸ(www.open-std.org)
draft読まないとな。ディフォルト引数便利だし。

45:デフォルトの名無しさん
08/03/08 17:50:46
>>6
相手は誰だ…
うらやましすぐる

46:デフォルトの名無しさん
08/03/08 18:43:27
ローアングルブラジャー！？(;ﾟДﾟ)ポロリもあるよ！！

47:デフォルトの名無しさん
08/03/19 00:34:38
最後の書き込みがブラジャーだと哀れなので保守

48:デフォルトの名無しさん
08/03/19 20:09:10
Javaのクロージャが、
制御文やループ文のブロック仮引数使えて面白いんだが…

withLock(lockVar) {
// do something
}
void withLock(Lock l, {Lock => void} b) { ...

for foo(T i : aCollection) {
// do something
}
void foo(C<T> c, {T => void} b) { ...

49:デフォルトの名無しさん
08/03/26 00:05:23
ラムダ式はN2550でだいたい決まりかな
<> が [] になって、中にキャプチャ変数並べられるようにしたと
return は省略できないぽい？

50:デフォルトの名無しさん
08/03/26 00:09:48
おまえら最新ドラフト来てるなら知らせてくださいよ

URLﾘﾝｸ(www.open-std.org)

51:デフォルトの名無しさん
08/03/26 00:12:15
しかしラムダを導入するために新しいキーワードを入れる気はサラサラないんだな

52:デフォルトの名無しさん
08/03/26 02:27:35
識別子に利用できるトークン列を割り当てると、
下方互換性がなくなるからね。
あまり奇怪な記号列も困るけどラムダ式は俺的にギリギリセーフ。

あとconceptのexportは取り下げられたねw

53:デフォルトの名無しさん
08/03/26 02:56:22
コンセプトのexport？
まさかテンプレートのexportと同じように、
別の翻訳単位のコンセプトを参照する機能？
そんなのあったんだ。そりゃはいらないだろうなぁ

N2550を、今読んでいるんだけど、文法がものすごくキモいな。
本当に新しいキーワードがほしい。
新しいキーワードさえあれば、
どこでlambdaを使っているか、メモ帳ですら検索できるのに。

54:デフォルトの名無しさん
08/03/26 03:27:16
俺も素直にキーワード導入した方がいいと思う。
検索のやりやすさが全然違う。

55:デフォルトの名無しさん
08/03/26 04:26:40
N2550を読んだのだけれど、lambda-parameter-declarationって、
もしかして省略できる？
つまり、

[](){}() ;

と同じ意味で

[]{}() ;

は可能？

しかし、邪悪なコードだ。

56:デフォルトの名無しさん
08/03/26 07:11:36
ラムダ用に新しい記号を導入してくれれば・・・

57:デフォルトの名無しさん
08/03/26 11:20:09
そんなに互換性を気にするならひらがなでも使えばいい。
std::for_each(v.begin(), v.end(), ら(int x) {std::cout << x;});

58:デフォルトの名無しさん
08/03/26 12:15:33
λでいいじゃん。

λ.....ﾄﾎﾞﾄﾎﾞ

59:デフォルトの名無しさん
08/03/26 12:30:25
#define lambda []
#define closure(captures) [captures]
こんなんほしいかもな。

60:デフォルトの名無しさん
08/03/26 12:31:44
>>55
文法のところにはっきり opt と書いてあるだろ。

61:デフォルトの名無しさん
08/03/26 19:02:17
$ 使おうぜ

62:デフォルトの名無しさん
08/03/26 19:21:48
盲点なような気がするが、\ を使えばいい気がする。

63:デフォルトの名無しさん
08/03/26 19:36:11
よくない

64:デフォルトの名無しさん
08/03/26 20:23:14
inlineとか使えそうだけどな

int n = 10;
auto x10 = inline [n] (int a) { return a * n; }

65:デフォルトの名無しさん
08/03/26 21:04:17
inline ｷﾀ━━━(ﾟ∀ﾟ)━━━ !!!!

66:デフォルトの名無しさん
08/03/26 21:47:25
そこでvolatileですよ

67:デフォルトの名無しさん
08/03/26 21:55:47
export でどうだ

68:デフォルトの名無しさん
08/03/26 21:57:59
extern だな。

69:デフォルトの名無しさん
08/03/26 21:58:59
inline は正直結構イケるんじゃないかと思った。

70:デフォルトの名無しさん
08/03/26 22:01:07
#define Lambda

71:デフォルトの名無しさん
08/03/26 22:02:11
書いても書かなくてもいいタイプのマクロは害悪にしかならない。
構文に影響を与えるタイプのマクロも混乱を招くしかない。
しかし元の文法からして微妙。
どうすればいいんだ。

72:デフォルトの名無しさん
08/03/26 23:43:51
おまえらもうあきらめろｗ
100回くらい使ってれば慣れるよきっと

73:デフォルトの名無しさん
08/03/26 23:44:27
自分はいいんだ。問題は一見さんとかに説明するとき。

74:デフォルトの名無しさん
08/03/27 00:42:10
「100回くらい使ってれば慣れる」って説明すれば良いのでは？ｗ

75:デフォルトの名無しさん
08/03/27 05:49:53
decltype(x) lambda(x) { return x; }

76:デフォルトの名無しさん
08/03/27 07:40:59
美少女中学生にバイブをプレゼントした時みたいな反応だな

最初の抵抗感から最終的な快感への淫靡なプロセスをたどるわけだ

77:デフォルトの名無しさん
08/03/27 10:58:46
いや、その形状がドン引きするような感じだって話なのではw

78:デフォルトの名無しさん
08/03/27 11:49:13
というか美少女中学生にバイブにしろ何にしろ何かをプレゼントする機会なんてあるのかよ。

79:デフォルトの名無しさん
08/03/27 13:39:31
あるか、ないか、ではなく、つくるんだよ。迷惑だろうけど。ｗ

80:デフォルトの名無しさん
08/03/27 19:36:34
プレゼントではなくセクハラです。

81:デフォルトの名無しさん
08/04/06 20:01:37
何イッとるんだこのスレは

82:デフォルトの名無しさん
08/04/06 20:11:06
女子中学生にラムダを教えるにはどうすればいいのか検討するスレです

83:デフォルトの名無しさん
08/04/06 21:25:26
女子中学生にランダバを教えたい

84:デフォルトの名無しさん
08/04/06 23:25:53
ランバダのことか。

85:デフォルトの名無しさん
08/04/06 23:27:34
>>83-84ﾌｲﾀ

86:デフォルトの名無しさん
08/04/07 00:16:53
しかしあのラムダの構文は邪悪すぎると思うのだが ...
旧キャスト並に邪悪だ。

87:デフォルトの名無しさん
08/04/07 00:21:24
何が邪悪ですか?
旧キャストとはCスタイルのキャストのこと?
だとして、構文が邪悪?

88:デフォルトの名無しさん
08/04/07 00:23:29
おい誰か lambda introducer に inline 強制しろって提案出してくれよ。
こういうときに、えぴなんとか通せばいいの？

89:デフォルトの名無しさん
08/04/07 00:35:49
本来その手の提案とか defect report とかは comp.std.c++ が窓口なんだけど、
今年に入ってからトラブってるらしいんだよなあ。他の人はどうしてんだろ。

90:デフォルトの名無しさん
08/04/07 00:41:35
とりあえず proposal のところに書いてあるメルアドに投げとけばよいような？

91:デフォルトの名無しさん
08/04/07 07:53:48
いや、やっぱ [&] (const employee& e) {e.salary()=...}
とかいう構文は邪悪でしょう...

92:デフォルトの名無しさん
08/04/07 09:39:32
だから、どう邪悪なのか説明してくれんと頭の悪い漏れには判らん

93:デフォルトの名無しさん
08/04/07 11:27:58
個人的には一つのまとまりとして見づらい構文はやめて欲しいなぁ。

94:デフォルトの名無しさん
08/04/07 13:27:49
キーワードがあるほうが単純に検索できて良いと思うな。
そういう意味ではCスタイルキャストのいやらしさと似てる。

95:デフォルトの名無しさん
08/04/07 14:24:31
そんなに検索したいなら/*lambda*/[～とでも書けばいいだろ

96:デフォルトの名無しさん
08/04/07 15:22:33
美少女中学生のグンゼのおばんつにおかんがマジックで名前を書いている状態か！

97:デフォルトの名無しさん
08/04/07 21:31:48
for も if も検索しにくいけどね

98:デフォルトの名無しさん
08/04/07 21:46:43
lambdaが検索し易くなければならない理由も判らなければ、
検索しにくい事がどう邪悪なのかも判らん
もっと判り易く説明してくれ

99:デフォルトの名無しさん
08/04/07 21:48:48
関数適用だって検索しにくいしなあ
関数適用が検索し易くなければならない理由もないけど

100:デフォルトの名無しさん
08/04/07 22:29:38
>>97-99
なんか必死だなあｗ
どちらかといえば探せたほうがいいかな、という程度の話なんだけどね。
関数の先頭とかも検索しにくいわけだから、構わんといえば構わんか。
あとは美観の問題だね。

101:デフォルトの名無しさん
08/04/07 22:39:50
>100
その程度の話なら別にいいんだけど,
邪悪だなんて穏やかでない言い方してるから
なんか構文的に問題があるなら教えてくれ、ってだけなんだけど

102:デフォルトの名無しさん
08/04/07 22:41:37
ここで言ってる邪悪というのは美観の問題じゃないかな。
構文の問題とかはさすがにないんだろ、偉い人が考えたんだから。ｗ

103:デフォルトの名無しさん
08/04/07 23:13:22
いや、どう考えても邪悪な類のコードだろ

104:デフォルトの名無しさん
08/04/07 23:17:11
goto は何にでも使えるから邪悪なように、
使い回すにしてもどれを使い回すか結構考えないと、
goto と同じくらい邪悪になってしまう。

105:デフォルトの名無しさん
08/04/07 23:19:39
ラムダ式の何がどう邪悪なのかもうちょっとｋｗｓｋ

106:デフォルトの名無しさん
08/04/07 23:21:28
レベルの低い奴は無視しろ

107:デフォルトの名無しさん
08/04/07 23:50:42
おっぱいの標高が低い美少女中学生ならみっちりねっとりお相手をお願いしたい

108:デフォルトの名無しさん
08/04/07 23:51:44
括弧が続いて読みづらい

109:デフォルトの名無しさん
08/04/07 23:57:24
コンビネーションですむのにそうしないところがラムダ式の存在の邪悪さ

110:デフォルトの名無しさん
08/04/07 23:59:44
それを言うならコンビネータじゃなかろか？

111:デフォルトの名無しさん
08/04/08 00:05:07
何か勘違いしてるんじゃないか？
コンビネータもλ式の一種だぞ。

112:デフォルトの名無しさん
08/04/08 00:08:03
単に [&] という三文字の並びがキモイ

113:デフォルトの名無しさん
08/04/08 00:10:44
俺は >>112 だな。難しいことはよくわからん。ｗ

114:デフォルトの名無しさん
08/04/08 00:12:54
キモいよな。

115:デフォルトの名無しさん
08/04/08 00:18:39
エディタのマクロで保存時にλを[&]に変換すれば桶

116:デフォルトの名無しさん
08/04/08 00:24:35
白スクを着てひざを抱えつつこっちを見てにっこりしている美少女中学生にしか見えない

117:デフォルトの名無しさん
08/04/08 00:27:35
ついにC++も AA 言語になってしまうのだなあ

118:デフォルトの名無しさん
08/04/08 00:40:30
新しい刺激に慣れるのに時間が掛かるタイプの人がいるのですね

119:デフォルトの名無しさん
08/04/08 00:52:29
いじりまわせばくせになる！！！！！！！！！！！！！！！！！！！！！！！！！

120:デフォルトの名無しさん
08/04/08 01:01:22
Perl とかいつまで経ってもキモいし。

121:デフォルトの名無しさん
08/04/08 01:09:38
美少女中学生のアレはキモくないぞ

122:デフォルトの名無しさん
08/04/08 01:10:04
同じシンボルでも$とか@とか[]とかの付けかたで参照する変数が違うからなー

123:デフォルトの名無しさん
08/04/08 01:16:09
つける下着で印象が変わるわけだな

124:デフォルトの名無しさん
08/04/08 02:02:33
今<>のパース失敗してるみたいに
[&]とoperator[]が絡んでおかしなことにならねえかな

125:デフォルトの名無しさん
08/04/08 02:03:22
"λ" が使えない処理系ではtrigraphとして "[&]" で代用しても良いというのなら許す

126:デフォルトの名無しさん
08/04/08 02:45:24
autoでもわかるように、どうあっても予約語増やす気は無いんだろう

127:デフォルトの名無しさん
08/04/08 02:49:24
おまえらはもうboostのラムダつかってなさい

128:デフォルトの名無しさん
08/04/08 03:03:30
__TheLambdaExpressionKeywordOfC++0xとか絶対かぶらないようなキーワードにすればいいのに

129:デフォルトの名無しさん
08/04/08 07:31:32
_Lambda をキーワードとして採用し、
#define lambda _Lambda を行うヘッダファイル lambda を用意すればいい。

130:デフォルトの名無しさん
08/04/08 08:31:41
美少女中学生の全裸ランバダ

131:デフォルトの名無しさん
08/04/08 08:36:47
>>129
それなんて _Bool ?

132:デフォルトの名無しさん
08/04/08 13:16:48
美少女中学生と lambda がいい具合に入り乱れててワロタw

133:デフォルトの名無しさん
08/04/08 14:23:30
ここまで来ると lisp 系言語の () の方が可愛く見えるな > lambda

134:デフォルトの名無しさん
08/04/08 19:27:05
この先も予約語増やさずに変な記号の組み合わせや予約語の転用でどんどん機能増やしていくんだろうか
C++2xくらいでは酷いことになってそうだ

135:デフォルトの名無しさん
08/04/08 19:43:39
オペレーター定義可能なHaskellに比べたら

136:デフォルトの名無しさん
08/04/08 20:06:52
C++の将来は墓穴掘ってユーザーからサヨナラされそうだな

137:デフォルトの名無しさん
08/04/08 20:10:45
既にもうマイナな言語だから大丈夫。今でも使ってる好き者たちなら付いてくるさ。ｗ

138:デフォルトの名無しさん
08/04/08 20:19:48
2029年か。想像できんな。
妄想してみるか。

・十分にハードウェアが高速になったとして、とうとうC++にもevalを導入
・メタプログラミングや賢いマクロを積極的に仕様に盛り込むことで、新たな文法を定義可能
　例えば、LispやPerl、Pythonはおろか、Brainf*ckやWhitespaceまでもがC++としてコンパイル可能
・現実世界で、本当にほしいライブラリが標準規格に盛り込まれる（XMLとかUnicodeとか）
・Bjarne Stroustrupがフサフサになる

C++以外の妄想
・宗教戦争は終わらない：言語、OS、コンパイラ、エディタ
・既に64bitが主流になり、32bitコードは16bitコードなみの扱いを受けている
・メモリを数十GB確保することは当然である
・そのようなハードウェアでも、最新の3Dゲームはまだ遅い
・96DPIより高いDPIのディスプレイが使われている。

139:デフォルトの名無しさん
08/04/08 20:31:44
関数型言語が主流になっているだろうな

140:デフォルトの名無しさん
08/04/08 20:57:47
>>138
2029年までC++は現役でいられるんだろうか？…
寧ろ、現役であることのほうが問題だとも感じてしまうのだが、C++0x仕様策定の経緯を考えると
僅か数年のライフサイクルの為にそんなことしないとも思えるわけで…
まだCPUが8ビットでOSなんか載ってなくて、アセンブリでがんがってた時代を顧みると、
既に量子コンピュータは無理としても量子マイコンみたいな4キュービットマシンがあったりしてｗ

そういやtime_tが32ビット符号付なLinuxディストリビューションが2038年にオーバーフローする件、
Y2Kのような事は起きないんだろうな
それまでにtime_tは64ビットは当たり前だったりするだろうし、CPUのレジスタやアドレス空間が
512ビット幅だったりしてねｗ
メモリはTBは余裕なんじゃないの？
15年くらい前は4MBとかだったのに15年程度で1～2GBが標準だし
HDDなんかがTB越えてEBとか新たな単位がデファクトスタンダード化してたりして
妄想楽しかったわ

141:デフォルトの名無しさん
08/04/08 21:09:01
>>138
・GCは本当にC++標準になるか?
・CRTPの果たす機能を、より一般的でかつ抽象的な機構で実現できないか?
・daemon method, accessor hook

142:デフォルトの名無しさん
08/04/08 21:12:28
>>140
2038年問題は考えてたけれど、2029年には早すぎると思って入れるのをやめた。
人間が騒ぎ出すのは、大抵、問題がひっ迫してからだから、数年後に迫らないと、
本格的に議論されないと思う。

Y2Kのようなことはおきるね。32bitコードはそこらかしこで動いているだろうから。
一体誰がコンパイルしなおすの？

というか標準規格厨としては、POSIXのCライブラリは嫌い。
ANSI CやC99とは微妙に違うし。
というかそもそもCライブラリ自体が古いから、使われなくなってくれれば、うれしいんだけどなぁ。

>CPUのレジスタやアドレス空間が512ビット幅
というか本音を言うと、本当に64bitに移行できているかどうかも怪しい。
最悪、いまだにWindowsは32bit版が発売されているということも。

>HDDなんかがTB越えて
HDDに置き換わるものは、やはり20～30年ぐらいじゃ無理かな。

143:デフォルトの名無しさん
08/04/08 21:27:47
>>141
mixin だな。今の C++ に足りないのは。

144:デフォルトの名無しさん
08/04/08 21:29:44
conceptはmixin風に使えるけど、
access controlがないのが痛いね。

145:デフォルトの名無しさん
08/04/08 21:31:58
>>142
まあY2Kと同じで大した問題は起きないだろうな。
と油断しておけば、いろいろ問題が起きて楽しめるかも。ｗ

146:デフォルトの名無しさん
08/04/08 21:36:25
>>142
冷静に考えると、CPUのアドレスバス幅を512bitなんかにする恩恵は殆ど無いね
64bitでも十分なアドレス空間があるし
確かに、32bitCPUのライフサイクルは長かった、というか今も64bitコアを64bitとして使ってる
OSは全体からすれば少数だろうし

CはもうC++のサブセットでいいんじゃないの？
今もC++コンパイラがオプションでCコンパイル出来るけど…
よりOOP色、AOP色強くなればなるほど、C標準ライブラリを使用することへの危機感はでかくなる
だろうし…
POSIX俺も好きじゃないし、なんやかんやいいつつも、ISOベースでいいとおもってるし
直近じゃC++0x、boostの幾つかを標準ライブラリとしてstdネームスペースに取り入れるようだし
それはコンパイラとしては歓迎されるのかも？
新コンパイラ出たところで、2038年問題とも絡んで古いコードは存在し続けるわけで、古い
コンパイラを使うだろうから新しいライブラリを使用するのは暫く様子を見ることになるんだろうし

32bitのソースなど、下手すりゃポインタ変数のサイズ=4バイトと決めうちのコードもあるから
リコンパイルだけじゃ済まなそう…
アライメント違反も出そうだなあ

とはいえ、プリプロセッサが2029年まで残ってるんだろうか？
今の俺の脳味噌ではプリプロセッサが無いと大変に困るわけだけど…
EffectiveC++なんかに指南される
　#define FOO "foobarfoo"
よりも
　const char* const FOO = "foobarfoo";
を使え、これは分かるが、
#if/#ifdefが無いのは困るし、マクロ定義が使えずにインラインというのもそれはそれでデバッグログ
出すときに困る…

147:デフォルトの名無しさん
08/04/08 21:39:05
2038年問題はスレ違い

148:デフォルトの名無しさん
08/04/08 21:40:01
namespace階層入れて欲しいなあ。
stdがどんどん増えるのは好ましくないと思う。

149:デフォルトの名無しさん
08/04/08 21:49:59
>>144
もうちょっとｋｗｓｋ

150:デフォルトの名無しさん
08/04/08 21:56:36
>>148
> stdがどんどん増えるのは好ましくないと思う。

わからなくはないが、STLの大半がコンテナであるうえに、stdというネームスペース名を考えると、
確かに新しい標準ライブラリは異なるネームスペースに入れて貰いたいという気もしなくもない
ついでに、マクロに C++0x 対応コンパイラなのかどうかを判別するマクロ用意して欲しいんだけど、
既にそれは予定済みだったりしてｗ

151:デフォルトの名無しさん
08/04/08 21:59:10
C++ にはヘッダファイルってものがあるから
気軽に using できない。
そう考えると、あんまり標準ライブラリの階層深いと
ダルくなると思う。

152:デフォルトの名無しさん
08/04/08 22:08:51
>>150
__cplusplusの値が増えているんじゃないの？

153:デフォルトの名無しさん
08/04/08 22:16:47
>>151
それそれ、頼むからヘッダファイルで using namespace std; とかしないで欲しい！
だが、今のPRJではそこら中にあるんだよね…
そんなに std::string とか std::vector って書くのがめんどくさいのかね

>>152
それもそうだｗ
__cplusplusなんて値を意識しないもんなぁ extern"C" くらいにしか使わないからｗ

154:デフォルトの名無しさん
08/04/08 22:42:46
美少女中学生を namespace 俺の姓; で囲んでバラ色の生活をだな

155:デフォルトの名無しさん
08/04/08 22:49:26
ADL対策でstlの中にも名前空間を作っていけないとやっていけないんじゃないのか？

156:デフォルトの名無しさん
08/04/08 23:23:08
>>151
単純にスタティックなオブジェクト言語の限界だと思うんだが

157:デフォルトの名無しさん
08/04/08 23:47:46
>>151
ヘッダも今や階層化されてるし。
>>156
そんなの関係ないねえ

158:デフォルトの名無しさん
08/04/09 00:30:10
>>157
> そんなの関係ないねえ
どんな意味で関係ないんだろ? >>151, >>156 は
> ヘッダも今や階層化されてるし。
このことを問題にしてるんじゃないのか?

159:デフォルトの名無しさん
08/04/09 00:45:23
皆の見解をまとめると、これからはD言語の時代ってことか。

160:デフォルトの名無しさん
08/04/09 01:54:30
それはない

何だかんだ言ってもここ20年間はおおむねCとC++の天下だったし、
それはこの先も変わらないだろうな

161:デフォルトの名無しさん
08/04/09 03:09:07
関数型言語に取って代わられるだろうと予想する。
オブジェクト指向やC++にはスマートさで限界を感じる。

162:デフォルトの名無しさん
08/04/09 04:26:18
まさか
LISPが誕生して50年になるけどその間に関数型言語が主流になったことなんて一度もないだろ

163:デフォルトの名無しさん
08/04/09 04:44:38
>>162
ほんとにそうよね。

まあ、最近よく言われてるのは、
宣言型とか手続き型、静的とか動的の垣根がなくなっていくってのかな。

あとは、1つの言語で全部書くんじゃなくて、
多言語混在開発な方向に進んで行ってる。

というのを考えると、やっぱり C++ には限界を感じるんだけど。

164:デフォルトの名無しさん
08/04/09 07:18:34
For me, easily the biggest news of the meeting was that we voted lambda functions and closures into C++0x.
･・・・・・・・・・・・・・・・・・
by Sutter
なぜlambdaやclosureに拘っているのかもわからん。
MSはF#に本腰を入れてるようだけど。
いずれにせよC++色々取り込みすぎて記述レベルに難があるとは思う。

165:デフォルトの名無しさん
08/04/09 07:48:48
>>161
D言語はpure関数とかを導入して、関数プログラミングを取り込む方向で動いてるみたいだね。

URLﾘﾝｸ(www.digitalmars.com)
どうなるかわかんないけど。

166:デフォルトの名無しさん
08/04/09 07:55:09
ついおこづかいでアクセサリーを買い込みすぎてしまう美少女中学生

167:デフォルトの名無しさん
08/04/09 08:29:09
>>166 美少女中学生以外は眼中にないのか?

168:デフォルトの名無しさん
08/04/09 08:57:25
>>164
わからん方が鈍いと思うけどね。

169:デフォルトの名無しさん
08/04/09 09:15:35
>>168
schemeをやってきた俺は勝ち組だがな。C++はのλはモドキだ。

170:デフォルトの名無しさん
08/04/09 09:25:40
馬鹿丸出しだな。

171:デフォルトの名無しさん
08/04/09 09:30:06
記述レベルに難がある
モドキ
だけじゃなくて、具体的に言わないと。
愚痴書くスレじゃないから。

172:デフォルトの名無しさん
08/04/09 09:32:05
やっべー、薄っぺらいことがばれてもうたｗｗｗ
でもテンプレートの可読性の低さは難だろ。キモ構文のオンパレード
それでもあなたはC++に期待しますか？

173:デフォルトの名無しさん
08/04/09 09:39:49
メタをテンプレートで実現するのは難アリ。

174:デフォルトの名無しさん
08/04/09 09:45:09
>>171
例えばscheme処理系は言語の機能として構文拡張が可能。
C++は言うに及ばず。

175:デフォルトの名無しさん
08/04/09 09:53:56
Schemeと比べてああだこうだ言われても。
Schemeのプリミティブは強力だけど、
Schemeだって得意じゃないことは一杯あるし。

C++のclosureは、Javaの奴みたいに、
コントロール拡張について考慮されてないのが寂しいですねえ。

176:デフォルトの名無しさん
08/04/09 10:53:42
>>175
＞C++のclosureは、Javaの奴みたいに、
＞コントロール拡張について考慮されてないのが寂しいですねえ。
もうちょっとｋｗｓｋ

177:デフォルトの名無しさん
08/04/09 11:23:44
つ URLﾘﾝｸ(jazoon.com)

178:デフォルトの名無しさん
08/04/09 11:25:27
range-based for-loopと絡めたいね。

179:デフォルトの名無しさん
08/04/09 12:31:24
>>162
まるでLISPが関数型言語みたいな言い方だな。ｗ

180:デフォルトの名無しさん
08/04/09 13:17:07
自分の知識がきっちりしていることをひけらかすだめだけの
細かい突っ込みは痛々しいよ。
その「句点のあとのダブリュー」に突っ込むくらい虚しいことだ。

181:デフォルトの名無しさん
08/04/09 13:17:51
美少女中学生が丸出し！

182:デフォルトの名無しさん
08/04/09 13:35:51
いい加減中学生から離れろ。

183:デフォルトの名無しさん
08/04/09 13:38:14
そうだそうだ。中学生なんてババアだろ。

184:デフォルトの名無しさん
08/04/09 14:50:27
>>180
あやふやな知識じゃ自慢できませんものね。ｗ

185:デフォルトの名無しさん
08/04/09 15:14:33
自慢というか、自爆。

186:デフォルトの名無しさん
08/04/09 16:44:56
美少女中学生の初めての自慰はダイソーバイブと相場が決まっていてな

187:デフォルトの名無しさん
08/04/09 17:39:48
つまりUnlambdaサイコー！ということですね
わかります

188:デフォルトの名無しさん
08/04/09 21:42:03
>>177
遅くなりましたけれどありがとうございます．
finally 周りを省略するための使い方は， scope guard 系の技法に
lambda expression を組み合わせれば C++0x でもおよそそのまま転用できそうですね．
Listener に Event 設定したり， thread function の設定に使うのは
C++ だと lifetime の問題が出てくるのでそのまま転用するのが
難しい局面が出てくると思いますけれど，
これはコントロール云々とは直接は関係ないですかね．

189:デフォルトの名無しさん
08/04/10 15:51:50
>>138
Dスレから来ました
＞ Brainf*ckやWhitespaceまでもがC++としてコンパイル可能
DでBrainfuckをDの関数としてコンパイルするサンプルはもう作ってみたよ。
C++でもテンプレートプログラミングが変態的になればできると思う。
メモリ管理がうまくいけばJavaあたりはC++で直接いけるような気がします

190:デフォルトの名無しさん
08/04/10 16:11:46
Dか。
Dはやねうらおが一時期信者だったので敬遠してたんだが、
今は離れたみたいだし、ちょっと遊んでみようかな。
流行るとは思わないけれど。

191:デフォルトの名無しさん
08/04/11 11:57:20
>>190
「誰々が信者だったから～」
なんともくだらない理由だなww

192:デフォルトの名無しさん
08/04/11 12:15:17
Rubyはまつもとが××信者だったから～

193:デフォルトの名無しさん
08/04/11 12:50:57
生理的に駄目なやつっているだろ

美少女中学生の生理なら駄目じゃないぞむしろ大歓迎

194:デフォルトの名無しさん
08/04/11 18:00:43
製作者がGPL信者だったから敬遠しますた

195:デフォルトの名無しさん
08/04/11 18:02:33
それは実害があるからしゃーないが・・・
坊主憎けりゃ袈裟まで憎いとか俺には一生分からない感情だろうな。

196:デフォルトの名無しさん
08/04/11 18:30:23
「誰誰が信者だったから～～」
「坊主憎けりゃなんとやらか」
「でも今日は気にしないよ」
「あー、"今朝まで憎い"ってか」

197:デフォルトの名無しさん
08/04/11 18:43:42
まつもとはいいかげん他言語を煽って目立とうとするのはやめてほしいんだが
煽りの内容もお前が言うなレベルの低次元なものだし・・・

198:デフォルトの名無しさん
08/04/11 19:10:56
子供っぽい美少女中学生はどこが坊主？

199:デフォルトの名無しさん
08/04/11 19:27:21
結局 Python に落ち着いた漏れ．
でも最近は仕事じゃPHPばっかりで萎える．

200:デフォルトの名無しさん
08/04/11 20:40:51
まぁ標準みたいなもんだし

201:デフォルトの名無しさん
08/04/11 23:00:49
C++0xはC++1xになるのだろうか…

202:デフォルトの名無しさん
08/04/12 09:07:38
0f までいけるからまあ大丈夫だろ。

203:デフォルトの名無しさん
08/04/12 09:27:12
07までだろ…

204:デフォルトの名無しさん
08/04/12 11:47:56
それは盲点だった

205:デフォルトの名無しさん
08/04/12 11:50:32
いいかげん0のプリフィクスで8進数リテラルっての止めて欲しい
誰も使わない上に紛らわしい

pythonを見習って止めるべし

206:デフォルトの名無しさん
08/04/12 11:51:15
つ互換性

207:デフォルトの名無しさん
08/04/12 14:32:37
パーミション設定するときに使うべ。

208:デフォルトの名無しさん
08/04/12 14:51:09
そうだな
パーミションは3ビットだから8進使うと便利だな

209:デフォルトの名無しさん
08/04/12 14:55:54
そのために8進表記があるんじゃないのか

210:デフォルトの名無しさん
08/04/12 14:59:15
別にパーミションのためにあるわけじゃないぞ。

211:デフォルトの名無しさん
08/04/12 15:00:11
for all 3bit user

212:デフォルトの名無しさん
08/04/12 16:04:49
それより２進表記を作ってくれ 0b0100110101010 みたいな

213:デフォルトの名無しさん
08/04/12 16:08:27
読みづらいから D みたいに区切りを入れられるようにしてくれ。

214:デフォルトの名無しさん
08/04/12 17:27:33
>>212
これ良く書かれてるんだけど
0xdcとかが11011100とかに見えないの？
実に不思議だ

215:デフォルトの名無しさん
08/04/12 17:28:57
TMPで2進表記をする有名なサンプルがあってだな・・・

216:デフォルトの名無しさん
08/04/12 17:34:12
>>214
「実質ゼロ時間・ゼロ労力」でできるのはせいぜいその辺の変換+αくらいで、
その程度ではまるで不便だから「よく書かれる」んだろう。

もし「0xdcが11011100に見えないレベルの人が」よくこの要望を出しているのだと考えているなら、
勘違いで自分を相対的に持ち上げすぎ。不思議っていうか、君が不思議ちゃんだよｗ

217:デフォルトの名無しさん
08/04/12 17:36:42
頭の中で変換可能ならリテラルの表記は10進のみでおｋ
という話しになってしまうな

ただ二進数だと桁が多くなるから区切りがないと返って可読性落ちるな

218:デフォルトの名無しさん
08/04/12 17:40:15
>>216
どういうこと？
16進と2進は直接4桁ごとに変換できるから2進表記はないんだろ？
そしてそれをほとんどができるから
よく書かれるってのは皮肉で書いたんだけど

219:デフォルトの名無しさん
08/04/12 17:40:54
皮肉っていうのはおまえいつもそれ書いてるなって意味

220:デフォルトの名無しさん
08/04/12 18:02:42
俺は脳内で変換できるから、5進数でも大丈夫

221:デフォルトの名無しさん
08/04/12 18:04:05
16進でいいだろってのは釣りなんだから相手にしないでおけ。

222:デフォルトの名無しさん
08/04/12 18:28:35
C系言語使うつもりなら
・2進 <-> 8進 <-> 16進の変換
・0xF*0xFまでの16進九九
・文字定数 <-> ASCII値
・主要な2^n値の10進表記(n=1～16,20,24,30,31,32,40,63,64あたり)
くらいは身につけてるのが常識だし、マナーだと思ってたが
最近はそうでもないのか

223:デフォルトの名無しさん
08/04/12 18:30:39
身につけるのが常識である事と、
そのままでいいこととは別の話だろ？

224:デフォルトの名無しさん
08/04/12 18:34:33
そんなのまで言語側で面倒見るべきではないと思うぞ
九九を知らない奴が家を設計できるようになることが良いこととは思えない

225:デフォルトの名無しさん
08/04/12 18:34:38
0b0100110101010
こんなのぱっと見て長すぎて分かりにくいし
たかだか16個のビットパターン覚えられないって方がネタだろ

226:デフォルトの名無しさん
08/04/12 18:38:18
>>222
この辺、本当にそう思うならちょっと披露して欲しいと思った。
・8進16進変換
普通の人は、2進を介在させないと難しいと思う。
・16進9x9
必要になるケースがレアすぎる。
・2^nのnが40とか64とか。
nが16以下なら普通に言えるけど。nが32でさえ桁数が多すぎて普通は無理。

227:デフォルトの名無しさん
08/04/12 18:38:20
D みたいに自由にアンダースコア入れれるようにすればいい。

228:デフォルトの名無しさん
08/04/12 18:38:45
>>222
そんな化石言語使いません。

229:デフォルトの名無しさん
08/04/12 18:39:30
マクロとか書けるけどな。
でも、できるなら言語的にサポートされてほしい。

230:デフォルトの名無しさん
08/04/12 18:40:18
0b001101000101ならすぐ0x345とわかるけど
これを0b1101000101とか書かれると困る
0bの後に続く数は4の倍数個に制限するべきだが、導入されたとして多分そうはならないだろ
だったら有害なだけ

231:デフォルトの名無しさん
08/04/12 18:40:59
いや32なら簡単だろさすがに

232:デフォルトの名無しさん
08/04/12 18:41:41
>>231は思いっきり勘違い

233:デフォルトの名無しさん
08/04/12 18:42:55
>>230
D ではこう書く。

0b11_0100_0101

234:デフォルトの名無しさん
08/04/12 18:43:18
特にメモリが4Gに迫って色々あったり2038年問題の影がちらつきだしたこのご時世に
2^31と2^32の10進値も知らないコンピュータ技術者がいるなんて信じたくない

235:デフォルトの名無しさん
08/04/12 18:44:27
だから、概数を覚えていることと全桁そらで言えることは違うって。

236:デフォルトの名無しさん
08/04/12 18:45:06
およそ40億としか覚えてなかった
1048576までなら覚えてるけど

237:デフォルトの名無しさん
08/04/12 18:45:36
20億代と40億代だと覚えておけば、
細かい値が必要なときだけ電卓でポンでいいだろ。
無駄な事覚えるのはタダのバカ。

238:デフォルトの名無しさん
08/04/12 18:48:05
約21億と約43億としか覚えてないなぁ
けど2^24は16777216って覚えてるな

239:デフォルトの名無しさん
08/04/12 18:48:14
>>234
2^10 = K
2^20 = M
2^30 = G

で十分だ。

240:デフォルトの名無しさん
08/04/12 18:49:04
>>238
俺も 16777216 は覚えてるな。
何か覚えやすい並びだしな。

241:デフォルトの名無しさん
08/04/12 18:50:18
>>239
Gってのは文脈によって1073741824・1047586000・1024000000・1000000000を意味する可能性がある
全然十分ではない

242:デフォルトの名無しさん
08/04/12 18:51:08
>>239
2^10=1024も知らないとか冗談だろ？

243:デフォルトの名無しさん
08/04/12 18:51:51
1024 は流石に知らないと恥ずかしいな。

244:デフォルトの名無しさん
08/04/12 18:53:29
>>241
例えば伝送速度は1k=1000、メモリ容量などは1k=1024換算だ。

>>242
んなもん覚えてるわ

245:デフォルトの名無しさん
08/04/12 18:53:37
2^31=2147483648は結構覚えやすいと思うんだけどな
万の区切りで48が2回出てくるし偶数桁目に4,4,3,4って調子よく並んでるし

246:デフォルトの名無しさん
08/04/12 18:54:10
>>241
文脈だって、馬鹿じゃね

247:デフォルトの名無しさん
08/04/12 18:54:58
2^8 = 256
2^10 = 1024
2^15 = 32768
2^16 = 65536

これはおさえとかないと確かにマズいな

248:デフォルトの名無しさん
08/04/12 18:56:38
データ容量でキロを1000メガを1000000と解釈するのは記録メディア業界だけ？

249:デフォルトの名無しさん
08/04/12 18:56:51
0xFFFF = 65535
これで覚えてる

250:デフォルトの名無しさん
08/04/12 18:58:21
>>248
メディア業界でも会社によってメガが1000000だったり1024000だったりするから困る
（1048576であることはまずないけど）

251:デフォルトの名無しさん
08/04/12 18:58:28
てかC++0xのスレだよな？

252:デフォルトの名無しさん
08/04/12 18:59:21
いつまでも0bなんて粘着に持ち出すゆとりのせいで荒れたじゃないか

253:デフォルトの名無しさん
08/04/12 19:04:49
0bを導入するメリットがあるとすればフラグを表す定数なんかで
#define FLAG_A 0b00000001
#define FLAG_B 0b00000010
#define FLAG_C 0b00000100
#define FLAG_D 0b00001000
#define FLAG_E 0b00010000
#define FLAG_F 0b00100000

なんて表現ができて初心者がフラグの定義の仕方を直感的に理解できるくらいか？
それ以外のメリットが思いつかん・・・

254:デフォルトの名無しさん
08/04/12 19:06:21
#define BIT(n) (1u << (n))

#define FLAG_A BIT(0)
#define FLAG_B BIT(1)
#define FLAG_C BIT(2)
#define FLAG_D BIT(3)
#define FLAG_E BIT(4)
#define FLAG_F BIT(5)

とかの方が分かりやすい

255:デフォルトの名無しさん
08/04/12 19:07:07
0b literals considered harmful

256:デフォルトの名無しさん
08/04/12 19:10:50
Gauche使え

257:デフォルトの名無しさん
08/04/12 19:12:27
そういう思い込み書き込むスレじゃないからw
マ板行けよ

新しい関数型の記法です。->を使う。
URLﾘﾝｸ(www.open-std.org)

typedef int IFUNC(int);
IFUNC* fpif(int);
　↓
auto fpif(int)->int(*)(int)

template <class T, class U> decltype((*(T*)0)+(*(U*)0)) add(T t, U u);
　↓
template <class T, class U> auto add(T t, U u) -> decltype(t+u);

258:デフォルトの名無しさん
08/04/12 19:17:28
コンパイラの都合臭がする記法だよな

259:デフォルトの名無しさん
08/04/12 19:19:27
constexpr long operator prefix"0b"(const char *literal_string){
　　long n=0;
　　for(; *literal_string; literal_string++){
　　　　n = (n << 1) + *literal_string - '0';
　　}
　　return n
}
こういうのが出来れば0b厨もおとなしくなるのに

260:デフォルトの名無しさん
08/04/12 19:21:37
なんか盛り上がってると思ったら、記憶力自慢の子が来てたのか。ｗ

261:デフォルトの名無しさん
08/04/12 19:21:55
typedefの何が気に食わなくてこんなキモい構文を

262:デフォルトの名無しさん
08/04/12 19:36:31
こういうのを見るとC/C++って下品なプログラミング言語だと思うよな。

263:デフォルトの名無しさん
08/04/12 19:37:58
>>262
そこがいい。下品な俺たちにぴったりなのだ。

264:デフォルトの名無しさん
08/04/12 19:50:37
>>261
templateの例はtypedefじゃきついだろ。

関数型表記の無理やり感がついに破綻しましたね。

265:デフォルトの名無しさん
08/04/12 19:51:05
>>260
というかその人達、これだけ会話が続いてもまだ
「16種類のビットパターンを覚えられないから0b表記を欲しがっている」
と思い込んでるのが痛い。

266:デフォルトの名無しさん
08/04/12 19:58:44
>>265
ごめん、違うの？

267:デフォルトの名無しさん
08/04/12 19:59:45
>>266
違うに決まってるだろ。
その記憶力でちゃんと日本語を覚えような。

268:デフォルトの名無しさん
08/04/12 20:04:25
ごめんなさいバカなのでわかりません
0bには16進のビットパターンを覚えられないゆとりのため以外にどのような利点があるのでしょうか

269:デフォルトの名無しさん
08/04/12 20:06:34
最近のGCCは独自拡張で0bを持っている。

270:デフォルトの名無しさん
08/04/12 20:07:39
>>268
バーカバーカ

271:デフォルトの名無しさん
08/04/12 20:09:47
>>268
保守性の向上

272:デフォルトの名無しさん
08/04/12 20:10:36
0bでは保守性向上しないだろ・・・

273:デフォルトの名無しさん
08/04/12 20:12:12
他の言語に採用されてる事に関しては疑問を持たないのかね

274:デフォルトの名無しさん
08/04/12 20:18:02
何を言おうと標準化委員会に却下された時点で0b厨の敗北は決定している

275:デフォルトの名無しさん
08/04/12 20:20:56
>>271
0bの方が読みやすい、だから保守性が向上するんだ！という主張ですね？

つまり0xを読めない奴でも保守できるようにするための機能ということですから
16進のビットパターンを覚えられないゆとりのための機能という意味ですね
解答になってないですね

「16進のビットパターンを覚えられないゆとりのため」以外の理由を教えて下さい
この馬鹿な私に教えて下さい

276:デフォルトの名無しさん
08/04/12 20:21:57
>>274
こういう下品な理由こそが C++ に相応しい

277:デフォルトの名無しさん
08/04/12 20:22:32
>>275
君は馬鹿というより単純だと思う

278:デフォルトの名無しさん
08/04/12 20:24:26
面倒くさいから
「ゆとりと仕事する（或いは保守をやらせる）かも知れないから」
でいいんじゃね

279:デフォルトの名無しさん
08/04/12 20:24:42
>>275
一行目と二行目の間に凄い飛躍があるなw

280:デフォルトの名無しさん
08/04/12 20:26:55
>>279
0xが読めるなら0xだろうと0bだろうと保守性は変わらないんですから
0xが読めない人にのみ意味のある保守性の向上ということですよね？

普通に読めばそういう意味になると思いますが
どのような飛躍があるのか教えて下さい
単純な私に教えて下さい

次ページ