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

C++0x 4 at TECH

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

wikipedia
Wikipedia項目ﾘﾝｸ

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

2:デフォルトの名無しさん
08/06/26 00:32:12
おつconcept

3:デフォルトの名無しさん
08/06/26 00:42:23
糞スレたてんな

4:デフォルトの名無しさん
08/06/26 00:42:50
乙
さて0bについて熱く語ろうか

5:デフォルトの名無しさん
08/06/26 01:15:26
[&](){} キモイスレはここですか？

6:これもいれてくれよ！>>1
08/06/26 01:31:04
mailing 2008
URLﾘﾝｸ(www.open-std.org)

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

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

7:デフォルトの名無しさん
08/06/26 06:13:54
>>1 乙

8:デフォルトの名無しさん
08/06/26 10:41:40
おつ

9:デフォルトの名無しさん
08/06/26 14:14:55
#undef __cplusplus0x

10:デフォルトの名無しさん
08/06/26 14:19:20
undefされちゃった(´･ω･｀)

11:デフォルトの名無しさん
08/06/26 15:18:41
前スレの最後でreflectionの話が出ていたが、
俺はHaskellみたいなオペレーター定義(優先順位指定付)が欲しい。
Parser Combinatorの中間記法的記述が羨ましい。

12:デフォルトの名無しさん
08/06/26 20:31:13
>オペレーター定義(優先順位指定付)
どう考えても罠が増えるだけです
本当にありが(ry

俺はパターンマッチングが欲しいな

13:デフォルトの名無しさん
08/06/26 20:42:53
優先順位の指定はD&Eで否定していたな。

14:デフォルトの名無しさん
08/06/26 20:50:23
いつまで0xなんだろうな

15:デフォルトの名無しさん
08/06/26 21:25:28
>>11, 12
なんでC++にしがみついてんのよ?

16:デフォルトの名無しさん
08/06/26 21:33:27
リリースが2010年以降にずれ込んだら　C++1x　XD

17:デフォルトの名無しさん
08/06/26 21:35:51
よく言われるが、2015年までセーフ

18:デフォルトの名無しさん
08/06/26 22:03:24
n2601を使えば2059年までおｋ

19:デフォルトの名無しさん
08/06/26 22:48:16
C+++ でいいじゃん

20:デフォルトの名無しさん
08/06/26 23:07:34
そんな演算子はない

21:11
08/06/27 00:12:36
>>15
面白い機能が次々に入るので。

義理の父に、これ飲め、あれ食えとなかなか帰して貰えないけど、
どれも美味しいから嬉しいやら哀しいやらで、困っている状態。

22:デフォルトの名無しさん
08/06/27 00:19:21
>>20
そこで>>11です。

+++はparser combinatorではCHOICEに使われることが多いです。

How to build a monadic interpreter in one day
URLﾘﾝｸ(www.haskell.org)

23:デフォルトの名無しさん
08/06/27 12:32:26
>>12
結局operator overloadも言われたいたほど
むちゃな使い方はされてないしなあ。
そういうライブラリもあるけど、現実問題として流行ることはない。
むしろ定義できないからBoost Xpressiveなんかわけわからなくなってる。

24:デフォルトの名無しさん
08/06/27 21:02:47
ユーザ定義オペレータなんか認めたら文法をBNFで定義できなくなってウザいからだろ
単に規格書著者とコンパイラ実装者の都合

25:デフォルトの名無しさん
08/06/27 21:40:30
Algol68がやってたんだが、文法が難解な２段階定義になったり大変だったらしい

26:デフォルトの名無しさん
08/06/27 23:47:48
C++のソースを読んでユーザ定義オペレータに対応したコンパイラを生成するコンパイラコンパイラをつくれば…

27:デフォルトの名無しさん
08/06/28 00:03:06
ユーザ定義オペレータを少し変更するたびにコンパイラをリビルドするんですね、わかります

28:デフォルトの名無しさん
08/06/28 00:06:33
そんなものより、生成されるプログラム自体にコンパイラを入れて、
evalが使えるようにするほうが、よっぽどマシで実用的だ。

29:デフォルトの名無しさん
08/06/28 00:15:06
ユーザ定義オペレータを導入するとしたら、
usingとかでスコープにユーザ定義オペレータがロードされた場合、
文法が変わっちゃうのかな。気持ち悪いな。

30:デフォルトの名無しさん
08/06/28 00:15:59
>>28
それなんてスクリプト言語ｗ

31:デフォルトの名無しさん
08/06/28 00:33:46
>>30
今日ではスクリプト言語に限らず、実行時に生成したコードをコンパイルして何かするってことは行われてるよ。

たとえば、.NETではクラスオブジェクトをXMLとして出力する時に、
型ごとにC#のコードを生成してそれをコンパイルして使ってる。

32:デフォルトの名無しさん
08/06/28 00:34:15
つかRuby最強すぎる

33:デフォルトの名無しさん
08/06/28 00:40:30
オブジェクト指向アセンブラC++には関係のない話だな

34:デフォルトの名無しさん
08/06/28 01:08:04
>>31
生成したユーザプログラムに、C++コンパイラ(言語解釈器)が内蔵されるとでもいいたいのか。
なんでC#なんて例を持ち出すんだ。天才なのか馬鹿なのかどっちだろ

35:デフォルトの名無しさん
08/06/28 01:12:03
別に内蔵しなくても共有ライブラリとして配布すればいい

36:デフォルトの名無しさん
08/06/28 01:22:10
ふむ。中間コードと動的実行ランタイム化したC++になるわけだな。
……それ、既にC++である意味ねえだろw

でもC++でevalって凄く変態的発想で素敵だとは思います。
実現したら惚れる

37:デフォルトの名無しさん
08/06/28 01:25:22
>>36
いや、.NETの例が出ただけで中間コードとは何も関係ないだろ。
単純にいうと、プログラムにGCCを同梱すればいいだけの話。

38:デフォルトの名無しさん
08/06/28 01:28:58
醤油噴いた

39:デフォルトの名無しさん
08/06/28 02:13:00
噴いて正解。

40:デフォルトの名無しさん
08/06/28 02:28:24
実行コードにGCC含むってのも、もしかすると天才的発想なのかな。
実行の度に同梱されたGCCがネイティブコード出力とか
どんだけ富豪プログラミングだよ

だが、それさえ工夫すれば実用に耐える時代は目の前に迫ってるのかもしれないな。
着想はLLVM方面かな？

41:デフォルトの名無しさん
08/06/28 02:37:29
実行時にプロファイルを見てネイティブコードを最適化というのは常識になりつつあるしね

42:デフォルトの名無しさん
08/06/28 02:39:26
>>36
おいらはセンス0だと思って、皮肉で書いたのだが。
ただ、evalとラムダ式との相性には多少興味持てたが。

道具は使い分け。問題ごとに道具をうまく使い分けるユーザが最強。
盲目的にRuby最強とか(C++最強とか)言ってるやつは、ゆとり

43:デフォルトの名無しさん
08/06/28 02:40:16
>>42
おいらってお前誰だよ。

44:デフォルトの名無しさん
08/06/28 02:46:38
evalの型はどうなるんだ

45:デフォルトの名無しさん
08/06/28 02:50:27
uniqe_ptr<void>

46:デフォルトの名無しさん
08/06/28 02:54:42
>>44
そこはテンプレートメタプログラミングでなんとかしよう

47:デフォルトの名無しさん
08/06/28 03:22:12
静的なevalとか
何につかえるかはわからん

48:デフォルトの名無しさん
08/06/28 03:25:37
Variantでいいじゃない

49:デフォルトの名無しさん
08/06/28 16:08:43
新スレ早々下らん話題だな
下等なインタプリタ言語の機能なんぞいらん

50:デフォルトの名無しさん
08/06/28 16:22:36
動的コンパイルとインタプリットを同じにされては困る。

51:デフォルトの名無しさん
08/06/28 16:47:44
Post-Sophiaな6月号来ないなー。

52:デフォルトの名無しさん
08/06/28 17:09:12
>>49
上下間違えてます

53:デフォルトの名無しさん
08/06/28 17:35:07
ついにプログラムが自身を書き換える時代が来たんだね

それにしてもRuby最強杉・・・

54:デフォルトの名無しさん
08/06/28 17:50:32
C++ nazo mondaigai(pgr

55:デフォルトの名無しさん
08/07/01 19:01:00
Bjarne Stroustrup
Programming: Principles and Practice Using C++
URLﾘﾝｸ(www.amazon.com)

だって。

56:デフォルトの名無しさん
08/07/01 20:12:58
まぁ順当に分厚いね。

57:デフォルトの名無しさん
08/07/01 20:17:48
1000ページか…
和訳でたら買ってもらおう。

58:デフォルトの名無しさん
08/07/01 21:29:42
俺のママは買ってくれるかなぁ

59:デフォルトの名無しさん
08/07/01 21:33:09
新しいパパを見つけて買ってもらおう

60:デフォルトの名無しさん
08/07/03 07:19:03
URLﾘﾝｸ(www.open-std.org)
News 2008-07-02: The 2008-06 post-Sophia mailing is available (9800 kB tar.gz, .zip 9800 kB)
News 2008-07-02: The C++ Standard Library Issues List (Revision 57) is available
News 2008-07-02: The C++ Standard Core Language Issues List (Revision 56) is available

ドラフトは N2691 。

・・・ copy_if キタ━━━(゜∀゜)━━━!!!
n2666 の説明読んでちょっとﾜﾛﾀ
> the workaround of using double negatives is not unconfusing.

61:デフォルトの名無しさん
08/07/03 08:22:58
説明が二重否定になっとる。

62:デフォルトの名無しさん
08/07/03 09:56:36
単語は分かるのに意味が分からない

63:デフォルトの名無しさん
08/07/03 11:44:22
二重否定を消して、
> the workaround of using double negatives is confusing.
二重否定の利用は紛らわしいのでフィックス。

元に戻って、
> the workaround of using double negatives is not unconfusing.
二重否定の利用は紛らわしくないことはないのでフィックス。

以下、remove_if notの話禁止。

64:デフォルトの名無しさん
08/07/03 16:36:45
そういうことか。ありがとう。

65:デフォルトの名無しさん
08/07/03 22:34:29
copy_ifの話はいいですか？

66:デフォルトの名無しさん
08/07/03 23:59:01
double negativesて何？

67:デフォルトの名無しさん
08/07/04 00:07:41
おすぎとピーコ

68:デフォルトの名無しさん
08/07/04 01:06:07
>>67
正解

69:デフォルトの名無しさん
08/07/05 02:00:37
わろた

70:デフォルトの名無しさん
08/07/05 03:34:28
iotaって何に使うんだろ？

等差数列・・・には使わないよなぁ

71:デフォルトの名無しさん
08/07/05 07:45:31
初心者スレで聞きなよ。

72:デフォルトの名無しさん
08/07/05 09:31:48
APL のιだろうね。
for (i = 0; i < N; ++i) の抽象化でそ？

73:デフォルトの名無しさん
08/07/05 11:48:06
index generator の i からきてるらしいけど、
こういう妙な略字やめて欲しいなぁ。

.NET Framework 3.5 の同様の機能は
Enumerable.Range って名前なんだけど。

74:デフォルトの名無しさん
08/07/05 13:25:22
>>71
itoaじゃないよ？

75:デフォルトの名無しさん
08/07/05 13:51:46
その名前は決定事項なのか…
「イオータ」から連番を代入する機能だって想像できるわけないじゃん。あほらしい

76:デフォルトの名無しさん
08/07/05 13:54:19
>>73
Rangeは名前の通りRangeを生成するだけで、コピーの作業まではやってくれないぞ。

77:デフォルトの名無しさん
08/07/05 15:09:29
>>73
>>75
URLﾘﾝｸ(cpplover.blogspot.com)

int i = 1;
std::generate(first, last, [i] () mutable { return i++; });

ラムダ式は適当だけど、これじゃだめなのかな。
あった方が便利だろうけど。

78:デフォルトの名無しさん
08/07/05 15:20:38
普通にインクリメントしたら挿す値が1増えるようなイテレータがあればいいだけなんじゃないか。

79:デフォルトの名無しさん
08/07/05 15:28:23
>>75
じゃあおまえはλ式ときいて意味が分かるのか？

80:デフォルトの名無しさん
08/07/05 15:48:06
ソース上にlambdaなんてないじゃん。

81:デフォルトの名無しさん
08/07/05 15:53:01
#include <boost/lambda/lambda.hpp>

あるじゃん。

82:デフォルトの名無しさん
08/07/05 15:54:24
誰がboostの話をしてる

83:デフォルトの名無しさん
08/07/05 16:05:58
関数名はもっと説明的にしろって話だろ

84:デフォルトの名無しさん
08/07/05 16:39:54
initializeContainerBySequencialNumber()ですか

iotaでいいや

85:デフォルトの名無しさん
08/07/05 16:45:14
sequenceとかでいいんじゃねえの。

86:デフォルトの名無しさん
08/07/05 16:52:20
atoiの逆関数だろ＞iota

87:デフォルトの名無しさん
08/07/05 16:56:47
>>86
みんな言おうと思っても言わなかったのに…

88:デフォルトの名無しさん
08/07/05 17:02:27
>>86
ﾌｶｸﾆﾓﾜﾛﾀ

89:デフォルトの名無しさん
08/07/05 17:17:42
APL由来らしいけど、Lispで数列的な操作によく使うよ？＞iota

90:デフォルトの名無しさん
08/07/05 17:33:51
iota_iteratorがほしい

91:デフォルトの名無しさん
08/07/05 19:01:16
>>76
C++ は GC 機能持ってないくて
戻り値でオブジェクトを返すコスト高いからそういう仕様になってるだけで、
コピー作業の有無は本質じゃないのでは。

>>89
いや、マイナーな言語はマイナーな命名規則でやってくれてもいいんだけど、
大衆が使う言語で変な名前使われると初心者が寄り付かなくなるぞ。
indexe generator → i → ι
なんて誰が想像するんだよ。

92:デフォルトの名無しさん
08/07/05 19:05:17
Lispがマイナーとな

93:デフォルトの名無しさん
08/07/05 19:08:29
C++もLispも同じくらいマイナーですよｗ

94:デフォルトの名無しさん
08/07/05 19:11:37
>>92
あ、いや、知名度はあるな。
なんだろ、マニア向け言語。

95:デフォルトの名無しさん
08/07/05 19:11:38
>>90
それなんてboost::counting_iterator？

96:デフォルトの名無しさん
08/07/05 19:23:18
counting iterator があるのにわざわざ iota の名前を取ろうとする C++ に絶望した

97:デフォルトの名無しさん
08/07/05 21:14:30
「STLによるコンポーネントデザイン」(2000年)って本にiotaって紹介されてたけど。
copy_ifと同じようにSTLに(当時)存在しないアルゴリズムとして。

98:デフォルトの名無しさん
08/07/05 22:36:12
>>90
つ concept_map InputIterator<int> {
　typedef int value_type;
　typedef int reference;
　typedef int* pointer;
　typedef int difference_type;
　int operator*(int x) { return x; }
};

99:デフォルトの名無しさん
08/07/05 22:37:32
> InputIterator
< ForwardIterator

100:デフォルトの名無しさん
08/07/06 08:27:34
C++0xでダックプログラミングなんて本でないかなぁ。
別にダックプログラミングだけじゃなくてもいいけど

101:デフォルトの名無しさん
08/07/06 12:11:53
APLがマイナーとな？

102:デフォルトの名無しさん
08/07/06 12:17:06
duck typingじゃないのか。

103:デフォルトの名無しさん
08/07/06 12:50:44
>>101
シェア的にはマイナーだろ

104:デフォルトの名無しさん
08/07/06 12:53:16
アヒル思考プログラミング

105:デフォルトの名無しさん
08/07/06 13:12:27
>>101
正直、APLはマイナーだと思う。ｗ

106:デフォルトの名無しさん
08/07/06 14:24:43
STLが影響受けてる言語だけどな。

107:デフォルトの名無しさん
08/07/06 17:11:06
>>106 を読むまで apache portable library の話をしていると思ってたらそれも APR でした＼(＾o＾)／

108:デフォルトの名無しさん
08/07/06 17:12:24
ここまでアイオタの話無し

109:デフォルトの名無しさん
08/07/06 17:13:42
アイダホ？

110:デフォルトの名無しさん
08/07/06 19:51:36
>>106
それはAdaじゃないの？

111:デフォルトの名無しさん
08/07/06 19:52:29
いろんなものの影響を受けてるんですよ

112:デフォルトの名無しさん
08/07/06 20:47:53
言語やライブラリの設計者は言語マニアなことが多いから
メジャーなライブラリが影響を受けているからといって、
その言語がメジャーとは限らない。

113:デフォルトの名無しさん
08/07/06 23:54:24
>>110
Adaは最初の実装言語ですよ。
まともなgenericsのあった数少ない言語だったから。
設計に関してはAPL, FP, Lisp, pure functional, CLU, smalltalkの影響が大きい。

114:デフォルトの名無しさん
08/07/06 23:55:49
SIMULA のことも忘れないでください

115:デフォルトの名無しさん
08/07/07 08:10:28
志村後ろ

116:デフォルトの名無しさん
08/07/07 11:38:33
DVDでるね。

117:デフォルトの名無しさん
08/07/07 14:14:12
>>113
言語拡張を最低限にとどめて何とかなる関数型言語
# 簡単じゃん, 作ってしまえや
言語拡張しようとすると数年がかりになる手続き型言語
# いあ, それは, まだコンセンサスが…
って, 理解でいいのか？

118:デフォルトの名無しさん
08/07/08 02:51:25
何故極端な単純化で物事を理解しようとするのかわからん。

119:デフォルトの名無しさん
08/07/08 03:02:52
再帰使いまくりでスタックぶち壊す関数型言語と
副作用使いまくりでデータぶち壊す手続き型言語ですね、わかります

120:デフォルトの名無しさん
08/07/08 08:02:55
>>118
馬鹿が「俺はもうわかっている」と思うための唯一の方法だからでは。

121:デフォルトの名無しさん
08/07/08 08:13:03
>>119
つ proper tail recursion

122:デフォルトの名無しさん
08/07/08 11:28:47
今度は終わらない末尾最適化関数で時間をぶち壊すんですね

123:デフォルトの名無しさん
08/07/08 11:31:32
>>122
頭悪そう…

124:デフォルトの名無しさん
08/07/08 11:35:55
要するに頭の悪い人は何も書けないという話

125:デフォルトの名無しさん
08/07/08 12:02:56
>>124
それは中途半端に頭がいい人。

頭の悪い奴は気軽に書いて、しっかりぶち壊す。

126:デフォルトの名無しさん
08/07/08 12:42:02
>>125
書けないというのは、書き方に悩んだりして手が出せないという意味ではなく、
まともな物を書けないという意味ね。

127:デフォルトの名無しさん
08/07/11 01:44:59
再帰は悪と教え込まれてきたC系プログラマが
今更まともにラムダ式を使いこなせるわけがないということですね、わかります

128:デフォルトの名無しさん
08/07/11 01:52:07
Fortran じゃあるまいし、そんなこと教える奴いねーだろ

129:デフォルトの名無しさん
08/07/11 02:46:46
えー
「再帰はスタックを壊すので、出来るだけループに書き換えましょー」って習うじゃん
書き換えの練習問題とかお約束じゃん

最近は違うの？

130:デフォルトの名無しさん
08/07/11 02:50:37
いまどき再帰でスタックを「壊す」とは珍しい環境だな。
エラーになるとか、無闇に重くなるとかが普通だろ。

131:デフォルトの名無しさん
08/07/11 02:53:04
>>129
「出来るだけ」ってことは暗に「出来ない」ケースでは使えってことでは？
つか、再帰が悪とかってレベル低すぎでしょ。ｗ

132:デフォルトの名無しさん
08/07/11 03:14:57
珍しくレベルが低い話しですね

133:デフォルトの名無しさん
08/07/11 07:14:34
>>129
何歳なんだおまえは。50歳ぐらいか？

134:デフォルトの名無しさん
08/07/11 07:38:15
>>130
末尾コールしをジャンプにしてるだけじゃん

関数型言語だと結構普通にやってるみたいだけど、CとかC++で
末尾以外の再帰をループに展開する奴ってあるの？
# アッカーマンとか、タライとか………

135:デフォルトの名無しさん
08/07/11 07:41:29
アッカーマン関数をループに展開する関数型言語なんてない。

136:デフォルトの名無しさん
08/07/11 07:56:08
タライってなんだ？調べても盥しかでてこねーぞ

137:デフォルトの名無しさん
08/07/11 07:59:22
>>136
たらいまわし関数で調べなおせ。

138:デフォルトの名無しさん
08/07/11 08:00:05
たらいまわし関数で google よろし

139:デフォルトの名無しさん
08/07/11 08:26:47
出てきましたーぞ。ありがとうございましたーぞ。

140:デフォルトの名無しさん
08/07/11 10:09:15
>>135
手元にある sbcl でオプティマイズかけたら loop に展開したぞ
lisp は関数型じゃないと言われればそれまでだが…

141:デフォルトの名無しさん
08/07/11 10:20:41
>>129
最近のことは知らんが
俺の世代もそうだったから言いたいことはよく分かるｗ

再帰テンプレートで終端条件の特殊化を書き間違って
しばらく帰ってこなくなったりしたときに、ふと当時を思い出して和む

142:デフォルトの名無しさん
08/07/11 10:36:40
Ackのループ化は末尾だけ(>>134)でしょ。
それともスタックや継続使って、
第一引数も第二引数も0じゃない時をループ展開してるの?

143:デフォルトの名無しさん
08/07/11 13:17:34
VC++2008 SP1日本語packはいつでんの？

144:デフォルトの名無しさん
08/07/11 13:21:28
>>143
ここは C++ スレじゃなくて、 C++0x スレですよ。

145:デフォルトの名無しさん
08/07/11 16:39:42
日本語版でも TR1 が欲しいということでしょ。
TR1 は 0x じゃないという主張なら分からんけど。

146:デフォルトの名無しさん
08/07/11 23:51:02
末尾再帰はVCでもGCCでもループに変換するよ

147:デフォルトの名無しさん
08/07/12 00:20:18
>>146
末尾再帰の展開は末尾コールのジャンプ変換と等価

148:デフォルトの名無しさん
08/07/12 00:27:02
>>146
末尾コールのジャンプ変換とループへの変換との違いは？

149:デフォルトの名無しさん
08/07/12 00:28:42
>>147ね

150:デフォルトの名無しさん
08/07/12 00:29:55
>>142
> 第一引数も第二引数も0じゃない時をループ展開してるの?

中間表現に CPS 使うと分岐/呼び出しが末尾コール
に変換可能なので最終的にループになるらしい

詳細は識者に聞いて

151:デフォルトの名無しさん
08/07/12 00:30:27
gcc(たぶん4とかから)には末尾再帰の最適化を明示的にコンパイラに指示するオプションがあるらしいよー

-foptimize-sibling-calls
Optimize sibling and tail recursive calls.

152:デフォルトの名無しさん
08/07/12 00:38:22
>>148
> 末尾コールのジャンプ変換とループへの変換との違いは？
ジャンプ先が別のルーチンか呼自分の内部かの違いに過ぎないだろ？
アセンブラやってる奴ならみんな使ってると思うんだが…

153:デフォルトの名無しさん
08/07/12 00:40:17
>>152
編集ミス
x …が別のルーチンか呼自分の…
o …が別のルーチンか自分の…

154:152
08/07/12 00:46:52
補足
つっても, 戻り番地スタックに積む程度のコストみたいだが

155:デフォルトの名無しさん
08/07/12 00:48:33
GCC 3.4.4で

f(a, n)
{
　if (a==0)
　　return n;
　
　return f(a-1, n*a);
}

が

_f:
　pushl　%ebp
　movl　%esp, %ebp
　movl　8(%ebp), %edx
　movl　12(%ebp), %eax
　jmp　　L3
　.p2align 4,,7
L6:
　imull　%edx, %eax
　decl　%edx
L3:
　testl　%edx, %edx
　jne　L6
　popl　%ebp
　ret

でした

156:デフォルトの名無しさん
08/07/12 00:51:35
>>150
継続スタイルに変換できるのはしってるよ、そんなの常識。
CPSを中間表現に使っているコンパイラも、
オブジェクトコードの生成ではCSP止めてます。
再帰スタックの代わりに、継続の入れ子を持ち運ぶのはとても効率が悪いので。
まともな処理系でAck関数をループや継続に変換して実行するものはないでしょ?
お遊びや学習用ってことなら俺も書いたことがあるけれど。

157:デフォルトの名無しさん
08/07/12 00:52:25
>>155
こんなのコンパイルしてみ
int f(...){return ...;}
int g(...) {return f(...);}
おそらく g() の最後は call f になると思う

158:デフォルトの名無しさん
08/07/12 00:54:04
>>157
gccがやるのは自己再帰の関数内ジャンプだけじゃないの? > おそらく

159:デフォルトの名無しさん
08/07/12 00:57:24
>>157
それはインライン展開すべきなの？

160:デフォルトの名無しさん
08/07/12 00:59:19
>>156
CL-USER> (lisp-implementation-type)
"SBCL"
CL-USER> (lisp-implementation-version)
"1.0.17.42"
CL-USER> (defun a (x y)
(declare (optimize (speed 3) (safety 0))
(type fixnum x y))
(cond ((zerop y) 0)
((zerop x) (the fixnum (* 2 y)))
((= y 1) 2)
(t (the fixnum (a (- x 1) (the fixnum (a x (- y 1))))))))
A
CL-USER> (disassemble 'a)
;;; 続く

161:デフォルトの名無しさん
08/07/12 01:00:53
;;; 続き 1/2
CL-USER> (disassemble 'a)
; 03B5BE33: L0: 4885C9 TEST RCX, RCX ; no-arg-parsing entry point
; 36: 750D JNE L2
; 38: 31C9 XOR ECX, ECX
; 3A: L1: 488D65F0 LEA RSP, [RBP-16]
; 3E: 488B6DF8 MOV RBP, [RBP-8]
; 42: C20800 RET 8
; 45: L2: 488D04D500000000 LEA RAX, [RDX*8]
; 4D: 4885C0 TEST RAX, RAX
; 50: 7505 JNE L3
; 52: 48D1E1 SHL RCX, 1
; 55: EBE3 JMP L1
; 57: L3: 4883F908 CMP RCX, 8
; 5B: 7507 JNE L4
; 5D: B910000000 MOV ECX, 16
; 62: EBD6 JMP L1
; 64: L4: 488BC2 MOV RAX, RDX
; 67: 4883E801 SUB RAX, 1
; 6B: 488945E8 MOV [RBP-24], RAX
; 6F: 4883E908 SUB RCX, 8
; 73: 488BC5 MOV RAX, RBP

162:デフォルトの名無しさん
08/07/12 01:02:22
;;; 続き 2/2 技と1行だぶらせてある
; 73: 488BC5 MOV RAX, RBP
; 76: 488BDC MOV RBX, RSP
; 79: 4883EC40 SUB RSP, 64
; 7D: 488943F8 MOV [RBX-8], RAX
; 81: 488BEB MOV RBP, RBX
; 84: 488D0506000000 LEA RAX, [RIP+6]
; 8B: 488945F0 MOV [RBP-16], RAX
; 8F: EBA2 JMP L0
; 91: 488B55E8 MOV RDX, [RBP-24]
; 95: EB9C JMP L0
; 97: 90 NOP
; 98: 90 NOP
; 99: 90 NOP
; 9A: 90 NOP
; 9B: 90 NOP
; 9C: 90 NOP
; 9D: 90 NOP
; 9E: 90 NOP
; 9F: 90 NOP
;
NIL
CL-USER>

163:デフォルトの名無しさん
08/07/12 01:05:57
Common Lispは使いたくないな

164:デフォルトの名無しさん
08/07/12 01:28:52
>>163
ほっとけ、Lisp は俺の電卓だ

165:デフォルトの名無しさん
08/07/12 01:32:00
>>164
最近電卓はPythonに宗旨替えしました

166:デフォルトの名無しさん
08/07/12 01:40:14
俺の電卓はRuby

167:デフォルトの名無しさん
08/07/12 04:06:59
そこはウソでもよいから「俺の電卓はC++コンパイラ」と書くべきだろ・・・スレ的に考えて

168:デフォルトの名無しさん
08/07/12 04:14:48
テ、テンプレート！

169:デフォルトの名無しさん
08/07/12 07:41:25
じゃあ俺の電卓はghostscript

170:デフォルトの名無しさん
08/07/12 12:09:16
俺の電卓はgoogle　マジで

171:デフォルトの名無しさん
08/07/12 13:48:43
俺の電卓は電卓

172:デフォルトの名無しさん
08/07/12 13:51:02
calc.exeで十分

173:デフォルトの名無しさん
08/07/12 15:00:26
>167
小数計算ができませn！＞＜

174:デフォルトの名無しさん
08/07/12 15:25:10
本物のC++プログラマは、ジョブをこなすのに、実行時プログラミングをまったく必要としない。
彼らはキーパンチャーと規格準拠なC++0x コンパイラ、そしてアニメがあれば完璧に幸福になれるのだ。

本物のプログラマはテンプレートで整数値演算をする。
本物のプログラマはで固定小数点数演算をする。
本物のプログラマはテンプレートでIEEE754の単精度演算を必要ならば'実装する。
本物のプログラマは倍精度演算をテンプレートとコンパイラの64bit整数型でする。

もしテンプレートで出来なければ、プリプロセッサでやる。プリプロセッサで出来なきゃ、それはやる価値がないのだ。

175:デフォルトの名無しさん
08/07/12 17:36:56
たらいまわし関数なんてはじめてきいたんでぐぐるとこんなのでてきた

/*
再帰的に定義された次のような関数。特に用途はない。
*/
int tarai(int x, int y, int z)
{
if (x <= y) return y;
return tarai(tarai(x - 1, y, z), tarai(y - 1, z, x), tarai(z - 1, x, y));
}

たった数行なのに何が起こるか想像できないのは、おれだけ？
大学の時、再帰で書けばエレガントになる、ループで書くのは素人、と刷り込まれたので
再起が出てくるたびに自分はセンスがないと思わされた苦い思い出。

176:デフォルトの名無しさん
08/07/12 18:33:13
おまえだけ。
わからないことを自慢しなくていいよ

177:デフォルトの名無しさん
08/07/12 18:38:27
引数評価の順番がわからんので俺もどう動くか想像できない

178:デフォルトの名無しさん
08/07/12 23:37:27
>>177
別に副作用ないんだから引数評価の順番は結果に関係ないだろう

179:デフォルトの名無しさん
08/07/13 15:25:45
計算量の例題という趣旨から外れるが、
再帰定義がなぜわかりにくいかがよくわかる例だなと思った。
筋のいいやつは数学的定義がそのまま書けるようなメリットがあるが、ほんの一握りだなと
アプリとか分析エンジンとか作ってて感じる。

180:デフォルトの名無しさん
08/07/13 16:00:59
ただ>>175はループに書き直すと更にわけわからなくなる気がする。

181:デフォルトの名無しさん
08/07/13 16:06:24
しかしD言語ではたらい関数もコンパイル時に評価できるのに、
0xのconstexprはほんとがっかりだなあ。

182:デフォルトの名無しさん
08/07/13 17:57:38
>>181
関数が提唱された本来の趣旨を考えると、コンパイル時にたらいをまわしても
意味ないような気がするんだが、気のせいか？

183:デフォルトの名無しさん
08/07/13 18:02:33
コンパイル時に
int tarai(int x, int y, int z){return x<=y ? y<=z ? z : x : y}
に最適化して欲しいって話だろ

184:デフォルトの名無しさん
08/07/13 18:03:40
違った
int tarai(int x, int y, int z){return x<=y ? y : y<=z ? z : x;}

185:デフォルトの名無しさん
08/07/13 18:08:45
>>182
そりゃあ、そもそもたらい関数自体に意味がないから、
コンパイル時にたらいをまわせても意味がないのは自明なんだけど、
言いたいのはそういうことじゃなくて、

再帰ができないとか、return一文で書かないといけないとか制約が多すぎて使い勝手が悪い。

186:デフォルトの名無しさん
08/07/13 18:27:37
そりゃまあコンパイル時評価したけりゃTMPで十分だし
わざわざ新予約語作ってまでconstexprなんて仕組みを作る理由もよくわからない

187:デフォルトの名無しさん
08/07/13 18:34:54
constexprは普通のコードで書けることや実行時にも実行できることに価値があるんじゃないの？

従来だとコンパイルタイムにもランタイムにも欲しい値がある場合、
普通の関数とテンプレートで二つ同じ処理を書かないといけなかった。

それが制限があるとはいえ普通のコード一つで済むようになるのは、
プログラマの負担の観点から言うと大きな進歩だと思う。

とはいえ、再帰ができないんじゃテンプレートの代わりにはならないよなあ…

188:デフォルトの名無しさん
08/07/13 23:05:38
いらない機能は使わなけりゃいい
禿もそう言っている

189:デフォルトの名無しさん
08/07/18 01:04:53
ぶっちゃけauto以外の新機能は全部いらない
最終的にはautoだけ取り入れられてあとはガン無視されるだろう
C99がlong longとか以外ガン無視されているように

190:デフォルトの名無しさん
08/07/18 01:17:36
ぷ

191:デフォルトの名無しさん
08/07/18 01:19:27
ぷ

192:デフォルトの名無しさん
08/07/18 13:30:51
autoに食いついてる時点で素人丸出し
普通autoなんて使わない

193:デフォルトの名無しさん
08/07/18 15:07:21
まじで?
型指定子としてのautoはいるだろ。

194:デフォルトの名無しさん
08/07/18 15:33:34
auto int x;

195:デフォルトの名無しさん
08/07/18 15:46:22
signedかunsignedか自動的に判断するのかな?
そんな風に考えるようになりました。

196:デフォルトの名無しさん
08/07/18 15:46:55
馬鹿じゃねーの？

197:デフォルトの名無しさん
08/07/18 15:48:17
>>195
型名が後に続く場合は自動変数の宣言になります。

198:デフォルトの名無しさん
08/07/18 15:52:21
馬鹿なことやってないで、コンパイラに型推論要求すりゃいい話じゃねぇの？

199:デフォルトの名無しさん
08/07/18 15:54:44
それがautoなんです（＞＜）

200:デフォルトの名無しさん
08/07/18 16:44:24
>>199
C++ の言語仕様でどこまでトレースきるのさ？

201:デフォルトの名無しさん
08/07/18 16:58:46
C++ の言語仕様にも手を入れたのでへっちゃらですよ

202:デフォルトの名無しさん
08/07/18 18:36:15
ムーブセマンティクスとかコンセプトとか、とりあえずライブラリ実装者が使ってくれれば、
利用者は何もしなくても恩恵を被れるって機能も多いぞ。

203:デフォルトの名無しさん
08/07/18 19:02:45
ムーブセマンティクスは微妙だな。
また頭ひねることになりそう。
constくらいは。

204:デフォルトの名無しさん
08/07/18 21:23:06
いやいやあれは超便利だろ。

205:デフォルトの名無しさん
08/07/18 21:34:59
美少女中学生が呼吸をするたびに形のいいおっぱいがオートムーブ

206:デフォルトの名無しさん
08/07/18 21:41:16
ムーブの概念はコピーより自然
今までなかったのが不思議

207:デフォルトの名無しさん
08/07/19 09:57:13
そりゃ一般的な機械語にムーブがなかったからだろうよ。

208:デフォルトの名無しさん
08/07/19 23:39:30
autoなんて、0x新仕様の中でも一番利用者として理解しやすい機能の1つなんだから
少しは勉強してからカキコしろよ。だってここ0xのスレなんだぜ。
という漏れも、Move Semanticsはよく理解してないので、えらそうなこと言えないけどさ。ごめん。

209:デフォルトの名無しさん
08/07/20 00:10:16
mov ebx, eax

210:デフォルトの名無しさん
08/07/20 00:28:24
>>209
俺それ書くの我慢したのに……。

211:デフォルトの名無しさん
08/07/20 01:12:06
copyだし

212:デフォルトの名無しさん
08/07/20 01:15:12
その点、Z80ニーモニックは正しいな

213:デフォルトの名無しさん
08/07/20 02:47:49
conceptのところ読んでみたけど
late_checkとaxiomの意味がわからん・・
何がうれしくなるんだろう

214:デフォルトの名無しさん
08/07/20 04:24:04
>>208
勉強してから書くのは大変だ。
読んで書くくらいなら、かなりの割合で達成してるだろう。

だからみんな単語にだけ詳しいんだよｗｗ
特に俺ｗｗｗ
読んで分かるのは大変だろ。
言い訳にならないのは承知だが。

215:デフォルトの名無しさん
08/07/20 04:38:01
autoの便利さとコンセプトの強力さとラムダ式の醜悪さと0bが却下されたことさえ知ってれば
このスレでは充分

216:デフォルトの名無しさん
08/07/20 05:03:03
個人的には initializer_list に地味に可能性を感じる

217:デフォルトの名無しさん
08/07/20 05:23:33
xchg eax,ebx

218:デフォルトの名無しさん
08/07/20 08:05:19
>>213
late_check:
あるインターフェースに適合するかどうかを
C++ではシグネチャーベースで判定するので、
テンプレート引数が決定して、
テンプレートインスタンスを生成する時にしか、
全体の適合性を判定できない場合が多い。
かといって、テンプレートの定義時に判定できる部分も、
インスタンス生成時まで判定できないのでは、
テンプレートのプログラミングがやりにくい。
だから、late_checkブロックの部分だけ、インスタンス生成時、
後は定義時に整合性のチェックを行う。
axiom:
条件式を最適化で利用して良い。
つまり型に対する論理的な制約になる。
Eiffelの「不変条件」みたいなもの。

219:デフォルトの名無しさん
08/07/20 11:18:40
>>218
concept が与えられてなお

＞テンプレート引数が決定して、
＞テンプレートインスタンスを生成する時にしか、
＞全体の適合性を判定できない場合が多い。

な場合についてｋｗｓｋ

220:デフォルトの名無しさん
08/07/20 11:50:12
>>208
知ってるかもしれないけど、
Move semantics(右辺値参照)に関しては禿がThe C++ Sourceに記事書いてたよ。
結構分かりやすい説明だった

221:デフォルトの名無しさん
08/07/20 13:15:29
Move Semanticsは内部にコンテナとか持っているclassの
operator書いてればありがたみが分かるだろう。

222:デフォルトの名無しさん
08/07/21 01:59:02
Extensible Literals が Proposed wording under review in Core にあるんだけど
まだ欲張るのか？
マジで09年に仕上げるつもりあるのか？

楽しい機能だから入るんなら歓迎だけどさぁ

223:デフォルトの名無しさん
08/07/21 02:24:34
提案者にBjarne Stroustrupの名前があるので無下にできそうにないな

224:デフォルトの名無しさん
08/07/21 02:46:24
>>222
だから2000+0xF年まではセーフだと…

225:デフォルトの名無しさん
08/07/21 06:33:47
0x200F　旧西暦8207年　宇宙暦308年ついにC++0xの完成をみた。銀河の歴史がまた一頁。

226:デフォルトの名無しさん
08/07/21 06:45:23
>>222
だいぶ前からその段階だから、今はもうほとんど、
"Integrated into working paper"に近いんじゃないのかな?

しかしこれliteralじゃねーだろ。
literalと組み合わせられるコンストラクタだ。

"こんにちわ、世界！"ISO2022JP

とかなんでもありだ。二進数リテラル問題も解決。
'_'で4桁ごとに区切るようなoperator"b"を書きたきゃ書けばいい。

227:デフォルトの名無しさん
08/07/21 09:16:16
もう永久に0xでいいよ

228:デフォルトの名無しさん
08/07/21 09:57:19
>>226
Cooked literalですw

229:デフォルトの名無しさん
08/07/21 10:26:02
>>226
>"こんにちわ、世界！"ISO2022JP
>とかなんでもありだ。
それはどうかな？そもそも "..." の ... 内に非アスキー文字を書くと
未定義なんでは？ (実際上はべつとして。)
operator "ISO2022JP" に渡る以前にエンコーディングが
どうなってるかわからないとどうしようもないべ。

230:デフォルトの名無しさん
08/07/21 10:39:17
さすがに未定義ってことは…
処理系に依存するくらいでは

231:デフォルトの名無しさん
08/07/21 10:40:45
char32_tで受け取れるようになればいいんだよ。

232:デフォルトの名無しさん
08/07/21 10:59:13
やるとしても、
L"こんにちわ、世界！"ENCODING
だな。

233:デフォルトの名無しさん
08/07/21 11:01:43
失礼しました、undefined じゃなくて implementation-defined ぽいですね。
char32_t は Unicode だと決まってるから、
U"こんにちわ、世界！"ISO2022JP
と書いておけば問題ないわけですね。なんか先頭のU が気持ち悪いけど。

234:デフォルトの名無しさん
08/07/21 11:18:14
operator "suffix"(char32_t const*, size_t)がinvokeされるわけですね。

>>226
つ constexpr

235:デフォルトの名無しさん
08/07/30 07:55:42
URLﾘﾝｸ(www.open-std.org)
News 2008-07-28: The 2008-07 mailing is available
News 2008-07-28: The C++ Standard Library Issues List (Revision 58) is available
News 2008-07-28: The C++ Standard Core Language Issues List (Revision 57) is available

236:デフォルトの名無しさん
08/08/01 01:37:54
誰も反応しないのは英語読めないからですね

237:デフォルトの名無しさん
08/08/01 01:39:08
自己紹介乙

238:デフォルトの名無しさん
08/08/01 01:43:12
そんなことより0bをだな

239:デフォルトの名無しさん
08/08/01 04:28:43
というか詰めの作業に入っているから、
そんな勢い良くリアクションするようなことはない。
ただ思った以上に書き直しが多かったので驚いた。> Concept Rev.7

240:デフォルトの名無しさん
08/08/02 14:25:37
今さら変えられないんだろうけど、
ストリーム関連の命名規則がぐちゃぐちゃすぎる。
書式を変更すると保存されるのも使いにくい。
cout << hex(123); みたいにしてほしかった。
これじゃあprintfの方が便利とか言われても仕方ない。

あと、再帰のできないconstexprには失望した。
コンパイラの仕事は、実行時向けに最適化してループにするだけじゃね？

241:デフォルトの名無しさん
08/08/02 14:35:10
実行時にループしたらconstexprとは呼べない。

242:デフォルトの名無しさん
08/08/02 14:41:59
実行時はすでに定数じゃないが、
しかし現状で、テンプレートでコンパイル時再帰の定数ができる以上、
constexprも再帰できてほしかったなぁ。

243:240
08/08/02 14:47:06
>>241
N2235には変数を引数に取る例も載ってる。
実行時も使えるよっていうメリットを残しながら、
再帰できるようにするのは可能だと言いたかった。

244:デフォルトの名無しさん
08/08/02 15:31:10
>>243
仮にそうだとしても、再帰するconstexpr関数がどうせ実行時評価しかしないなら、constexpr付ける意味が無いのでは。

245:240
08/08/02 17:06:39
>>244
いやいや、もちろんコンパイル時も使う。
定数のみを引数に取ったらコンパイル時に展開すればいい。

constexpr int pow(int x, unsigned int n) { return n > 0 ? x * pow(x, n - 1) : 1; }
...
char buffer[pow(2, 8)]; // 定数
unsigned int n; std::cin >> n; std::cout << pow(2, n); // 変数

constexprを取ったら、配列のサイズが定数式じゃないから通らない。
テンプレートでメタ関数として書くと、今度は変数が使えない。

246:デフォルトの名無しさん
08/08/02 17:39:31
>>245
可能かどうかで言えばまあ可能なんだろうな。

N2235も「今はまだそのときじゃない」って感じだし。

247:デフォルトの名無しさん
08/08/02 20:36:23
constexprは「実行時にも使いまわせる型厳密なマクロ」だよな。
お世辞にもコンパイルタイム関数実行とは呼べない。

248:デフォルトの名無しさん
08/08/02 21:55:46
再帰がやりたければtemplate使えばいいって考えがあったから
constexprは再帰禁止にしたのではないかと思う。

249:デフォルトの名無しさん
08/08/02 23:39:28
C++の拡張の目的としてあげられている
ユーザー定義型に組み込み型と同等の待遇を与える
っていうのを実現するのには今のconstexprで十分っていう判断だと推測

250:デフォルトの名無しさん
08/08/02 23:56:41
テンプレート引数は小数使えないしな・・・。

251:デフォルトの名無しさん
08/08/03 01:54:32
俺は>>245の愚案には反対。
constexprの狙いから外れすぎ。

252:デフォルトの名無しさん
08/08/03 04:05:47
浮動小数点演算テンプレートを作ればいい

253:デフォルトの名無しさん
08/08/03 11:50:11
コンパイル時のものと実行時のものは明確に区別して欲しいな
両方使えるとか紛らわしい

254:デフォルトの名無しさん
08/08/03 12:06:56
>>253
D言語なんかは現状ではどの関数がコンパイル時実行できるかさっぱりだけれども、今後関数属性のpureで解決するようだねぇ。

255:デフォルトの名無しさん
08/08/03 12:08:49
マクロとテンプレートとinlineとconstexprの関係でパニックになる初心者続出の予感

256:デフォルトの名無しさん
08/08/03 13:59:53
commonlisp よろしく
#eval_when (<評価するタイミング1> <評価するタイミング2> ...) {
<評価する式>
}
みたく、しちまえよw

257:デフォルトの名無しさん
08/08/03 20:48:23
すっきりしないねぇ。標準委員会に入って考え抜くと、これが最もエレガントな解と思えるようになるのかな。
おれがC++が好きだったのは、Modern C++にもあったけど、
各目的で用意された諸機能が、有機的に相互作用(ハーモナイズ)しあって、
1+1=2以上の機能体系を生み出してたところが、実用的でかつアーティスティックで好きだったんだ。
おれが入門したころの、templateがあってRTTIないくらいのころのC++は美しかった。

258:デフォルトの名無しさん
08/08/03 21:10:05
昔はよかった
K&Rの頃のCが一番だと思っている

259:デフォルトの名無しさん
08/08/03 21:19:46
D言語マンセー

260:デフォルトの名無しさん
08/08/03 21:36:26
ここでC++0xの文法があーだこーだ議論するような奴がD言語使うと、
自分で言語仕様を拡張したい病にかかるからやめたほうがいい。

261:デフォルトの名無しさん
08/08/03 21:43:18
>>257
互換性やメリット、デメリットの狭間に立って考えると良い線じゃないの？
既に巨大なC++の仕様を拡張するのは常にデメリットが大きいし
互換性を考えると不要なものも捨てられないし

262:デフォルトの名無しさん
08/08/03 21:47:13
互換性か…嫌な言葉だな

263:デフォルトの名無しさん
08/08/03 22:45:51
>>260
ありすぎて困るww

264:デフォルトの名無しさん
08/08/03 22:59:52
とすると、そろそろ寿命なんだね。
C++がぐんと存在感伸ばしたころ(おれがC++始めたころ)はC++の青年時代。
引きしまってたし、かといって機能が少ないわけでもないくて先駆的機能たくさんあった。
今は余計についた贅肉自体にもフォローしなくちゃいけなくて悪循環。
(後継の人たちが)どうがんばっても老廃物が老廃物を呼ぶ。
初代ガンダムは筋が通ってておもしろかったけど、
それみて育った子供達が作った後継のガンダムはちっともおもしろくないのと同じ。

265:デフォルトの名無しさん
08/08/03 23:15:28
寿命なのはそうなんだろうけど、後継がサッパリ出てこないから老兵が頑張るしかないんだよな

Java？論外ですわ

266:デフォルトの名無しさん
08/08/03 23:22:19
Dの出番ですね

267:デフォルトの名無しさん
08/08/03 23:32:25
言語はともかく、処理系がいまいちな気がするのは偏見だろうか＞Ｄ

268:デフォルトの名無しさん
08/08/03 23:33:04
>>266
個人が趣味で作ってる程度のものをC++やJavaと同列に扱うのはどうかと思う

269:デフォルトの名無しさん
08/08/03 23:33:23
俺的にはC++0xでやっと「使える」様になってきてこれからな感じなんだが・・・
template無い頃のC++はこりゃダメだと思ってたよ

270:デフォルトの名無しさん
08/08/03 23:48:18
>>268
今でこそ標準化されてるけどC++だって昔は似たようなものだったよ。

271:デフォルトの名無しさん
08/08/04 00:01:36
最近はもう、言語も大きな会社がバックについて
結構な規模の開発体制でやってないとまともなものできないんじゃないか。
Java も .NET も企業主体だし。

次ページ