C++0x 13

このエントリーをはてなブックマークに追加
1 ：デフォルトの名無しさん：
The C++ Standards Committee
http://www.open-std.org/jtc1/sc22/wg21/

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

前スレ: C++0x 12
http://hibari.2ch.net/test/read.cgi/tech/1298470844/
2 ：デフォルトの名無しさん：2011/07/21(木) 18:26:42.58
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/
C++0x 5
http://pc12.2ch.net/test/read.cgi/tech/1232460649/
C++0x 6
http://pc12.2ch.net/test/read.cgi/tech/1245092251/
C++0x 7
http://pc12.2ch.net/test/read.cgi/tech/1253280377/
C++0x 8
http://pc12.2ch.net/test/read.cgi/tech/1262874195/
C++0x 9
http://pc12.2ch.net/test/read.cgi/tech/1269623636/
C++0x 10
http://hibari.2ch.net/test/read.cgi/tech/1275375522/
C++0x 11
http://hibari.2ch.net/test/read.cgi/tech/1285884294/
3 ：デフォルトの名無しさん：2011/07/21(木) 18:27:32.83
親戚スレ
C1x
http://hibari.2ch.net/test/read.cgi/tech/1296642667/
4 ：デフォルトの名無しさん：2011/07/21(木) 19:41:04.13
C++0xはこのスレで最後になって次はC++1xかな
201x中に出せるかどうかは怪しいけど
5 ：デフォルトの名無しさん：2011/07/21(木) 19:42:18.66
C++0B
6 ：デフォルトの名無しさん：2011/07/21(木) 23:56:28.58
>>1乙

最後なので事情通の人、C++学園のまとめを書いていただけたら
7 ：デフォルトの名無しさん：2011/07/22(金) 00:18:26.62
・progress_displayたん
8 ：デフォルトの名無しさん：2011/07/22(金) 01:42:57.19
C99未対応 == C++0x未対応？
9 ：デフォルトの名無しさん：2011/07/22(金) 05:06:20.46
c++0xはc99のVLA(可変長配列)サポートしないんじゃなかったっけ
10 ：デフォルトの名無しさん：2011/07/22(金) 05:37:11.99
他にも色々サポートしないよ
コンパウンドリテラルとかコンストラクタあったら要らないし
11 ：デフォルトの名無しさん：2011/07/22(金) 07:58:47.87
>>9
これは何で？
例外のせい？
12 ：デフォルトの名無しさん：2011/07/22(金) 08:24:25.04
禿はvector使えっていってる
13 ：デフォルトの名無しさん：2011/07/22(金) 10:58:58.30
T foo(int size, U array[size])とか狂ってるしな。やりすぎ
14 ：デフォルトの名無しさん：2011/07/22(金) 14:47:46.63
禿は自分の好き嫌いで足引っ張んなよクソが
15 ：デフォルトの名無しさん：2011/07/22(金) 19:06:15.38
vectorでいいじゃん
16 ：デフォルトの名無しさん：2011/07/22(金) 20:47:52.66
0xでもstringのデータは&s[0]で取得するの？
dataだとconst付きのchar*が返っちゃうし
17 ：デフォルトの名無しさん：2011/07/22(金) 22:39:48.15
vectorじゃメモリー確保が遅すぎて代替品にならんだろ。
てか、禿はほぼ100% C99と互換性もたせるんじゃなかったのかよ。
18 ：デフォルトの名無しさん：2011/07/23(土) 00:13:43.64
だからやってるだろ
19 ：デフォルトの名無しさん：2011/07/23(土) 00:15:51.95
Designated Initializerは入れて欲しいんだが。
つかなんでみんなこれ無視すんだ。
20 ：デフォルトの名無しさん：2011/07/23(土) 00:18:06.78
VLAをvectorに替えて遅くなるというシチュエーションが思いつかん。
21 ：デフォルトの名無しさん：2011/07/23(土) 00:23:17.80
VLAの実装がallocaの場合はvectorより速い？
22 ：デフォルトの名無しさん：2011/07/23(土) 00:38:10.76
そりゃVectorといかnewはファーストフィットかベストフィットかしらんけど
メモリ中を捜査して空き容量捜し回ってんだから1回の加算だけでメモリ確保する
alloca方式には敵わんわなぁ。
23 ：デフォルトの名無しさん：2011/07/23(土) 00:48:39.63
template<typename T>struct vArray{size_t const sz;T*const p;T&operator[](size_t const a){return *(p+a);}varray(size_t const a,T*const b):sz(a),p(b){}}
#define MKVARRAY(a,b,c,d) c*const b=alloca(sizeof(c)*d);vArray<c>a(d,b);

MKVARRAY(varray,ptmp,char,size);
varray[0]="";

インラインを展開期待のallocaバージョン書いてみた
24 ：デフォルトの名無しさん：2011/07/23(土) 04:30:44.77
適当にぐぐってみたら Danny さんて人がこんなこと書いますた
> C++ programmers use arrays less than C programmers do.
Instead, vectors, std::tr1:array, std::string and smart pointer classes are used.
Furthermore, supporting VLAs would entail the changing of sizeof’s semantics,
just as in C99. This is against the design philosophy of C++ which forced the
separation between operator dynamic_cast and the remaining compile-time
typecast operators. However, VLAs are still a problem if you try to compile
a C source file using a C++ compiler.

sizeofのセマンティクスに変更を強いる(sizeofがコンパイル時に確定できない)から駄目ってことですかね？
25 ：デフォルトの名無しさん：2011/07/23(土) 08:41:21.52
動的に決まるsizeofとか死ねばいいのにと思う
26 ：デフォルトの名無しさん：2011/07/23(土) 09:51:52.52
つかやったことないけどVLAのsizeofって動的に結果返ってくるの？
だとしてC++で問題あるの？
27 ：デフォルトの名無しさん：2011/07/23(土) 09:59:39.10
sizeof適用不可にすれば？
28 ：デフォルトの名無しさん：2011/07/23(土) 10:03:57.10
> つかやったことないけどVLAのsizeofって動的に結果返ってくるの？
うん
29 ：デフォルトの名無しさん：2011/07/23(土) 10:31:41.81
allocaする配列クラスを作れば良かったのに
実装方法？　コンパイラが頑張れ
30 ：デフォルトの名無しさん：2011/07/23(土) 10:39:26.05
スタック使用を管理するクラスってどんなだよｗ
31 ：デフォルトの名無しさん：2011/07/23(土) 10:45:10.78
どっかにムーブされる可能性がある場合はヒープにとって、
関数内で利用が完結している場合はallocaして
グローバル変数の時は静的に確保する万能クラスを！

……どーかんがえても組み込みの配列拡張したほうが早い→そしてVLAへ……
32 ：デフォルトの名無しさん：2011/07/23(土) 10:51:24.13
ムーブでそこまで特殊な事する必要ないだろー
ローカル変数のアドレスの扱いは自己責任が基本
33 ：デフォルトの名無しさん：2011/07/23(土) 10:53:13.35
あと、静的に確保する際はサイズが決まって無いと無理なので
arrayで十分
34 ：デフォルトの名無しさん：2011/07/23(土) 10:55:02.70
allocaが使用されるのは限定的な場面だしなあ
sizeofは頻繁に出てくる分、動的sizeofになったときの影響のほうがでかいのだろうか…
一応TR2にdynarrayという動的配列のようなテンプレートクラスが提案されていたりする
35 ：デフォルトの名無しさん：2011/07/23(土) 11:06:34.65
お、提案はあるのか
size()でサイズ取得するなら
sizeofはクラス自体のサイズでいいからな
36 ：デフォルトの名無しさん：2011/07/23(土) 11:13:26.01
可変長配列は静的には無理だし、ヒープはnew[]そのものだし。
VLAくらいしかやることないだろ。
37 ：デフォルトの名無しさん：2011/07/23(土) 12:32:16.91
形式的に、sizeofの結果をポインタ＋size_tのサイズとしてしまえばいい
配列の長さはsize()で取得
メモリ確保やメンバ関数の動作は組み込みで
38 ：デフォルトの名無しさん：2011/07/23(土) 12:42:04.12
あほか
39 ：デフォルトの名無しさん：2011/07/23(土) 12:46:07.37
dynamic_sizeof を導入すればいいじゃなーい。
40 ：デフォルトの名無しさん：2011/07/23(土) 12:47:32.36
ふつうにC++と共存してるコンパイラでできてることをなぜ変える必要があるのか
41 ：デフォルトの名無しさん：2011/07/23(土) 13:06:55.53
VLAだけじゃなくコンパウンドリテラルとかも導入しないと
共存なんて夢のまた夢だよ
42 ：デフォルトの名無しさん：2011/07/23(土) 13:11:46.61
void foo(int a[const restrict], int b[const restrict]); とかキモいし
C99との共存とか要らない
43 ：デフォルトの名無しさん：2011/07/23(土) 14:23:35.57
正直C99をフル実装するという需要がどこにあるんだろうな
44 ：デフォルトの名無しさん：2011/07/23(土) 15:09:57.73
それを言い出すとC++0xをフル実装する需要は…という話にも
45 ：デフォルトの名無しさん：2011/07/23(土) 15:13:34.60
C++0xの需要ならここにある
……いやフルにあるかというと微妙かもしれないが
46 ：デフォルトの名無しさん：2011/07/23(土) 15:39:31.68
VLA自体はg++で実証済みだよね。
現実的に今さら問題になるような事は無いと思うけど。
47 ：デフォルトの名無しさん：2011/07/23(土) 15:57:07.38
ガスライティング
48 ：デフォルトの名無しさん：2011/07/23(土) 16:41:37.91
C++ユーザーが文法キモイとか
49 ：デフォルトの名無しさん：2011/07/23(土) 19:10:23.28
元がキモいからこそ
これ以上きもい文法はなるべく要らないと
ラムダくらいメリットが無い限り
50 ：デフォルトの名無しさん：2011/07/23(土) 19:33:18.45
すっかり手遅れな気がするのは俺だけか
51 ：デフォルトの名無しさん：2011/07/23(土) 21:39:41.16
互換性なんてもう諦めて新低級言語作れよ
過去の資産なんてコンバータ通せば十分だろ
52 ：デフォルトの名無しさん：2011/07/23(土) 21:45:31.26
碁
53 ：デフォルトの名無しさん：2011/07/23(土) 21:46:15.15
簡単に言うなよ。
C++からコンバート可能ということは、例え文法が違うとしても
キモい部分含めてC++の全機能を持ってないといけないということだぞ。
54 ：デフォルトの名無しさん：2011/07/23(土) 22:04:58.23
僕の作った最強の言語はろくな結果にならない
ソースはＤ言語
55 ：デフォルトの名無しさん：2011/07/23(土) 22:17:04.81
C++から学んだことは「コードは書いちゃいけない」
56 ：デフォルトの名無しさん：2011/07/23(土) 22:47:16.61
>>51
そんなアナタに D と Go
57 ：デフォルトの名無しさん：2011/07/23(土) 23:03:20.90
C++の文法って別にキモいとは思わないけどなぁ
1パスでコンパイルするためにめんどくさくなってる部分はあるけど

それに、AppleのBlockの酷さを見たら、ラムダさんはもうあれでいいと思うよ
58 ：デフォルトの名無しさん：2011/07/23(土) 23:29:31.94
Blocksさんってそんなに糞なの？
前にラムダなんかやめてBlocksを標準にしろって林檎信者が暴れてたけど
59 ：デフォルトの名無しさん：2011/07/23(土) 23:40:22.96
センスない。
http://en.wikipedia.org/wiki/Blocks_(C_language_extension)
こんなものをClangに実装させられるGregor先生が可哀想。
60 ：デフォルトの名無しさん：2011/07/23(土) 23:40:54.20
文法で言えばRubyやVBの方がキモイと感じるけどな。
Rubyのブロックの改行がイラっとするし、メッセージやブロック関連が一貫されてないのが
意味が解からん。あとVBはなんで戻り値返すか、返さないかだけでサブルーチンの書き方変わるんだよ。
めんどくせぇだけじゃん。
61 ：デフォルトの名無しさん：2011/07/23(土) 23:43:19.98
Wirth先生大激怒w
62 ：デフォルトの名無しさん：2011/07/23(土) 23:48:18.36
__blockとかBlock_copyとか見た目のアレさ加減もさることながら仕様がクソすぎて胃の内容物がcore dumpする
Blocksさん作った奴の言語設計センスはPHPの設計センスに匹敵するわ
63 ：デフォルトの名無しさん：2011/07/23(土) 23:56:12.03
>>61
RubyはEiffel系統だ。VBは色々混じってるがFortran系統だ。
endってキーワードが同じだけでPascal/Modula系統と一緒にするんじゃねえ。ぜんぜん違う。
64 ：デフォルトの名無しさん：2011/07/24(日) 00:58:06.39
つ procedure/function
65 ：デフォルトの名無しさん：2011/07/24(日) 01:18:08.41
Pascalは返値を捨てられないからな。
逆にModula以降は全部procedureだぜ。そんな事も知らないのはWirth先生に失礼だろ。
66 ：デフォルトの名無しさん：2011/07/24(日) 02:55:22.51
Block_release() で使う気なくなるなw
C#でyield return見たときキモかったけど、理屈抜きで使えば便利だw
67 ：デフォルトの名無しさん：2011/07/24(日) 03:15:14.91
C++(のラムダ)にはデストラクタがあるってだけで、なんらかの後始末が必要なこと自体は変わらんと思うが
68 ：デフォルトの名無しさん：2011/07/24(日) 05:29:57.56
ラムダを返値として返す時に、
明示的にBlock_release()する必要があるか、スコープ抜けたら勝手に処理されるかは
かなり決定的な違いだと思うんだが
69 ：デフォルトの名無しさん：2011/07/24(日) 05:40:57.21
つーてもC言語の文化を破壊してまで勝手に後始末される型を導入するなら
クロージャ云々よりもそれこそまず動的配列だしなあw
暗黙に生成されるコードがほとんど無い利点を潰すほどじゃないでしょ
70 ：デフォルトの名無しさん：2011/07/24(日) 05:54:58.30
いや後始末っていうか、C++0xのラムダはコピコン(またはムーブ)で渡されるだけなんで
スコープ抜けたらスタックから消えるってのは普通にC言語の文化を踏襲してるだけだから
そもそもなんでBlock_releaseなんてものが必要な仕様にしたのかが分からん
71 ：デフォルトの名無しさん：2011/07/24(日) 05:57:29.65
？
ブロックだってBlock_copyしなきゃreleaseもいらんのでは？
72 ：デフォルトの名無しさん：2011/07/24(日) 05:59:53.21
>>71
Blocksは変数キャプチャしたラムダを返値にする時はBlock_copyが必要
スタックからスタックにラムダをコピーできない
73 ：デフォルトの名無しさん：2011/07/24(日) 06:23:55.75
キャプチャするローカル変数の個数がわかんないんだから、固定サイズにはできないでしょ。
C++のようにラムダごとに別の型ってわけにもいかないし。
74 ：デフォルトの名無しさん：2011/07/24(日) 06:38:41.34
>>73
デストラクタ機構がないとスコープ脱出で自動処理とか出来ないもんなぁ

そもそもキャプチャ情報なんて動的オブジェクトになるんだから本質的にCと相性悪いので
Cに無理矢理ねじ込んだ時点でどう転んでもセンスの悪い設計にしかならない罠
75 ：デフォルトの名無しさん：2011/07/24(日) 06:43:41.72
道は無いこともないけどな。「可変サイズの返値」をサポートすれば。
要はallocaモドキの動作で無理やり呼び出し元のスタックに領域を作って返す、ってことだけど。
コンパイラに大改造が必要になる上に最近のCPUとも相性悪いけど。
76 ：デフォルトの名無しさん：2011/07/24(日) 06:50:04.16
>>75
そりゃ返値を返すだけなら方法はいくらでもあるが、
それを構造体メンバに代入したいとか言ったら結局詰むから何も解決してないよ。
77 ：デフォルトの名無しさん：2011/07/24(日) 06:54:01.09
いやさ>>72が「スタックからスタックに」って言ったから

親関数がスタック上にある場合のみ有効なdownward限定モードもあるといいなあとは思う。C++も含めて。
これなら関数ポインタとフレームポインタの組だけで済むしコピーとか後始末とか全く要らないんで非常に軽量。
初期のD言語のdelegateってことだけど。
78 ：デフォルトの名無しさん：2011/07/24(日) 06:57:16.44
>>77
C++的にはそれは「ムーブでやれ」じゃないかな
79 ：デフォルトの名無しさん：2011/07/24(日) 10:41:16.65
まあBlocksはCの範疇で使えないといけないから
ああいうダサい感じになるのも仕方が無いよ
デストラクタのあるC++とは違う
80 ：デフォルトの名無しさん：2011/07/24(日) 11:02:29.12
あんなダサい仕様にするくらいなら
Boehm GCみたいなGC前提にしてくれた方が良いわ
81 ：デフォルトの名無しさん：2011/07/24(日) 11:13:23.64
詳しく知らないけどひょっとしてBlocksってObjCの仕様じゃなくてCの独自拡張なの？
82 ：デフォルトの名無しさん：2011/07/24(日) 11:14:33.54
そうか？むしろやってることがC++0xのラムダと変わんない分ありがたい気もするが。
下手にGC前提とかgccのようなスタックに実行属性付けるの前提とかやられたほうが
C/C++両対応コンパイラにとっては痛すぎるぞ。
83 ：デフォルトの名無しさん：2011/07/24(日) 11:17:40.34
ObjCの独自仕様だが、Cに入れようとAppleが頑張ってる、って状況のはず
84 ：デフォルトの名無しさん：2011/07/24(日) 11:18:32.01
つまりC1Xに突っ込もうとしてるのか
なるほど
85 ：デフォルトの名無しさん：2011/07/24(日) 11:23:47.40
正確には、C1Xに突っ込もうとしてた、かな？
もうC1Xに入る可能性は殆ど無いと思う
86 ：デフォルトの名無しさん：2011/07/24(日) 11:29:31.24
ObjCの独自拡張じゃなくて、Cに対するAppleの独自拡張
てかあんなのがC1Xに入ったらC++系にC1Xは入れないでくれと言いたくなるぞ

>>82
Appleが出したBlocks提案にはGCの仕様も入ってるんだよ……(ゴクリ
あいつらに言語設計させないで欲しい
87 ：デフォルトの名無しさん：2011/07/24(日) 11:37:39.89
そこまで言うほどのことかよ。文法の違いだけじゃないか。
ABI的にはキャストすればそのまま渡せるぐらいだろ？
それにGCつったってC++だってGCの想定はしてるじゃないか。
88 ：デフォルトの名無しさん：2011/07/24(日) 11:57:14.38
Block_copy/Block_releaseの存在が「文法の違い」で済むとは思えないが
89 ：デフォルトの名無しさん：2011/07/24(日) 12:00:10.07
文法の違いだよ。
Cにデストラクタやコピーコンストラクタなんて入れられるはずもないんだから。

あれか？C99の複素数もゴミと思ってるタイプ？
90 ：デフォルトの名無しさん：2011/07/24(日) 13:08:26.76
文法の違いって言ったらそりゃあ何だってそうだが、
C層への実装が適切かどうか設計時点で疑問を覚えるべき由々しき違いだと思うぞ。
91 ：デフォルトの名無しさん：2011/07/24(日) 14:11:56.93
それはC++側でやるからCは余計なことすんなって意味か？
だとしたらすごい傲慢な意見と思うが。

CにはC++の事なんか気にする理由は全くない。
ブロックが没になるとしても純粋にC言語としてどうかって観点でのみ語られるべきで
上位言語でもっと上手い実装方法があるからなんてのは考慮されるべきではないだろ
92 ：デフォルトの名無しさん：2011/07/24(日) 14:50:41.12
C言語としてどうかって観点で言えばそもそもC言語には不適切な機能ってことになるだろうし
どうせObj-C決め打ち環境での独自拡張なんだからObj-Cのメッセージ機構として実装すればよかったのにとは思うぞ
93 ：デフォルトの名無しさん：2011/07/24(日) 14:53:22.72
Cは高級アセンブラの立場を忘れるべきじゃないと思う。
64ビット幅の型とか、曖昧な部分の明確化とかのメンテナンス的な地味な改定だけでいいよ…
今更新しい機能を入れるとかやめてー
94 ：デフォルトの名無しさん：2011/07/24(日) 15:05:11.58
でも規格決めてる人達は未だに今をときめく高級言語だと思ってる節があるからなぁ…
K&R時代の気分で
95 ：デフォルトの名無しさん：2011/07/24(日) 15:17:44.50
機械語レベルで考えて言語機能じゃないと実現不可能なものは入れるべき。
今のブロックやC++0xのラムダは所詮struct+関数ポインタのシンタックスシュガーだからどうでもいいけど
gccのスタックを実行するタイプのラムダなら規格に欲しい。
あと可変長返値なんて欲しいと思わないか？strdupa(strdup+alloca)なんかをアセンブラじゃなくてCで書けるようになるぜ？
96 ：デフォルトの名無しさん：2011/07/24(日) 16:00:15.68
トランポリンはスタックまるごと実行可能にしてるんで勘弁
97 ：デフォルトの名無しさん：2011/07/24(日) 17:59:24.70
＞C++0xのラムダは所詮struct+関数ポインタのシンタックスシュガー
えー
98 ：デフォルトの名無しさん：2011/07/24(日) 18:04:26.99
ラムダ用のメモリが自動的に動的に管理されれば
単なるシンタックスシュガーではないのだろうけど、
0xのラムダは単にキャプチャ対象変数をメンバに持つ
関数オブジェクトを作ってるに過ぎない
99 ：デフォルトの名無しさん：2011/07/24(日) 20:09:39.11
ん、それで何か問題あるのかというか、それ以上何を管理して欲しいんだ？
100 ：デフォルトの名無しさん：2011/07/24(日) 20:23:12.18
>>99
だからメモリをだろ。
Lisp だと lambda 使いまくりだけど、 GC が無かったらかなり使い難い言語だっただろうなーとは思うので >>98 に同意。
101 ：デフォルトの名無しさん：2011/07/24(日) 20:28:36.78
C++をなんだと思ってるんだ
102 ：デフォルトの名無しさん：2011/07/24(日) 20:43:49.16
>>99
管理して欲しいっていうか、管理していないからただのシンタックスシュガーだって >>98 は書いてるだけだろ。
シンタックスシュガーが悪いってわけじゃないが、結局は何のシンタックスシュガーなのかをわかってないと
メモリ管理で躓くことになる。 lambda は C++ 的には無理のある構文だと思うんだよなー。
103 ：デフォルトの名無しさん：2011/07/24(日) 23:24:07.70
ごめん何言ってんのか全然わかんない
なんでラムダがメモリの管理なんかしなきゃならないの？
104 ：デフォルトの名無しさん：2011/07/24(日) 23:29:40.41
>>103
>>73
std::functionだってメモリ管理はしてるだろ。

>>96
gccそのままじゃなくてもいくらでもやりようはある。
通常スタックから分離された実行可能属性付きのふたつめのスタックを用意するとか、
親関数の呼び出し時点でスタックフレーム自体をヒープに取ってしまうとか。
細部はどうでも良くて、コンパイラが直接サポートするならいくらでも効率の良い方法が
取り放題だし、そうでなくてはコンパイラが直接サポートする意味が無い。
105 ：デフォルトの名無しさん：2011/07/25(月) 00:13:46.46
>>103
ラムダの基底クラスとかあって、さらに動的に管理されていれば、
ラムダを返す関数を作って、
ラムダの基底クラスのポインタで受けれたりする
GCないから無理だろうけどねー
106 ：デフォルトの名無しさん：2011/07/25(月) 00:38:48.63
>>105
std::functionで受ければいいじゃん
107 ：デフォルトの名無しさん：2011/07/25(月) 00:42:57.49
意味わかんないんだけど
シグネチャの異なるラムダを同じ変数に格納出来たら呼び出しが静的に解決できないから論外だし
同じシグネチャで異なるキャプチャのラムダは当然同じstd::functionで受け取れるようになってて
つまるところ一種のスマポとして働いてるわけでメモリは管理されてるしむしろこれ以上何を管理して欲しいのか分からん
おまいさんが言うところの「メモリ管理」ってのは何を指してるんだ
108 ：デフォルトの名無しさん：2011/07/25(月) 01:23:52.12
本当についてきてるか？
GCなりスタックなりを上手く使えば「std::functionにローカル変数への参照をひとつひとつ持った関数オブジェクトを格納する」よりもっと効率のいいやり方があるって話だろ
109 ：デフォルトの名無しさん：2011/07/25(月) 01:27:02.19
ＧＣがある時点で効率がどうたらとか…
110 ：デフォルトの名無しさん：2011/07/25(月) 01:27:57.85
もしかして > std::functionは「メンバ変数として」キャプチャ情報を持っていると思っている
111 ：デフォルトの名無しさん：2011/07/25(月) 01:34:54.81
効率上げるためにGCを導入とか意味不明なんですが
112 ：デフォルトの名無しさん：2011/07/25(月) 01:52:31.43
>>110
いやそれは流石に無理やり相手が勘違いしてることにしたいとしか思えん

GCは、もしGC環境下ならの仮定の話だろ
113 ：デフォルトの名無しさん：2011/07/25(月) 01:52:53.50
GCGC言ってる人は
参照キャプチャする場合の話をしてるのか、コピーキャプチャする場合の話をしてるのか
そこからして最早分からなくなってきた。
俺は後者の話をしているものだとばかり思っていたのだが。
114 ：デフォルトの名無しさん：2011/07/25(月) 01:56:59.33
>>112
「ローカル変数への参照をひとつひとつ」とか言ってるのでそのレベルから勘違いしている可能性は高いと思うぞ
115 ：デフォルトの名無しさん：2011/07/25(月) 01:57:31.14
正解は「相手が2人いる」だから……。勝手に意見を含めて代弁したりした部分は混乱させたかな、すまん。
俺はどっちかと言えばスタック操作派のほう。
116 ：デフォルトの名無しさん：2011/07/25(月) 02:04:34.34
参照キャプチャする場合なら、
C++の関数オブジェクトはネストされたスタックポインタをメンバに記録しておけるからわざわざトランポリンとかする必要もない。
コピーキャプチャの場合なら、
どのみちコピーは必要なんだからメモリ確保してそこにコピーしてstd::function自体がスマポとして振る舞えばいい。

GCの出番は無いと思うんだが。
117 ：デフォルトの名無しさん：2011/07/25(月) 02:31:26.75
GCがあるならスタックフレーム自体をヒープに確保して放置でコピー一切不要とかもありだけどな一応
118 ：デフォルトの名無しさん：2011/07/25(月) 02:36:13.55
ラムダのコピーがちょこっとだけ早くなる代わりにそれ以外が悪夢のように遅くなるな
119 ：デフォルトの名無しさん：2011/07/25(月) 02:42:00.62
そこはそれ、関数内で使われてるラムダをどっかに持ちだそうとしてる状況でのみそうするとか、いくらかやりようが
120 ：デフォルトの名無しさん：2011/07/25(月) 03:02:45.98
1度でもGCを許すなら全てGCにしてしまった方がまし。
それが許されない状況があるからC++を使ってるわけなんだけど。
121 ：デフォルトの名無しさん：2011/07/25(月) 06:17:14.12
別の機能でも聞く話だな
122 ：デフォルトの名無しさん：2011/07/25(月) 11:27:48.23
>>120
そしてそう思わない人たちがObjective-C(++)を改築してる。
方向が違いすぎて相容れない。
Blocksは@Appleだけで幸せにやっていくと思われ
123 ：デフォルトの名無しさん：2011/07/25(月) 20:50:00.82
C++って何でシンボルを扱う機能が無いんだろうな。
時々無性に欲しくなる。

Holder<InterfaceA,MethodA> objectA;
Holder<InterfaceB,MethodB> objectB;
object.MethodA();
object.MethodB();
//MethodA,MethodBは引数で渡された名前が付いてるだけで同じ物。
124 ：デフォルトの名無しさん：2011/07/25(月) 20:54:53.71
objectってのは何クラスなの?
125 ：デフォルトの名無しさん：2011/07/25(月) 21:03:59.39
ごめん。objectAとobjectBね。
AとB書き忘れた。
126 ：デフォルトの名無しさん：2011/07/25(月) 21:07:19.66
何が呼び出されるの?
127 ：デフォルトの名無しさん：2011/07/25(月) 21:09:08.95
何を言いたいのかよく分からんな
128 ：デフォルトの名無しさん：2011/07/25(月) 21:27:07.32
こうしたいんじゃね？
template<typename T, funcname F> struct Holder { void F(){} };
129 ：デフォルトの名無しさん：2011/07/25(月) 21:36:11.73
>>128
そんな感じ。要するにメンバー変数とかメンバー関数の名前をテンプレート引数で指定するって事。
130 ：デフォルトの名無しさん：2011/07/25(月) 22:40:38.07
そういうシグネチャの違いは、コンセプトマップで吸収される予定だった。
131 ：デフォルトの名無しさん：2011/07/25(月) 23:43:11.63
グルーコードとは違うことを言っていると思われる。
なんであるかはよく分からないが。

template<typename T, typename U, funcname F> U func { return T.F(); }

こんな感じなのだろうか…
staticに決まらなくていいならいろいろやり方あるのがC++だが。
132 ：デフォルトの名無しさん：2011/07/26(火) 00:14:20.62
>>128
それで嬉しくなる使い方ってのがいまいち想像できんなぁ
133 ：デフォルトの名無しさん：2011/07/26(火) 01:47:23.60
>>123
C++でも必要ならマクロを使ってもいいんだぞ。

#include <iostream>
#define CreateHolder(name, interface, method)\
class Holder##name {\
int method_impl() { return 1; }\
public:\
int method() { return method_impl(); }\
}
int main() {
CreateHolder( A, InterfaceA, MethodA );
HolderA objectA;
CreateHolder( B, InterfaceB, MethodB );
HolderB objectB;
std::cout << objectA.MethodA() << " " << objectB.MethodB() << std::endl;
return 0;
}
134 ：デフォルトの名無しさん：2011/07/26(火) 14:59:14.28
返り値の自動推定は導入されなかったの？
135 ：デフォルトの名無しさん：2011/07/26(火) 15:07:35.98
decltype??
136 ：デフォルトの名無しさん：2011/07/26(火) 16:49:00.57
>>134
lambdaだけ。
137 ：デフォルトの名無しさん：2011/07/26(火) 17:41:31.22
ランバダ！ ランバダ！
138 ：デフォルトの名無しさん：2011/07/26(火) 17:42:31.42
>>133
特殊化の恩恵が受けられないけどね。
139 ：デフォルトの名無しさん：2011/07/26(火) 20:03:25.00
メンバ関数ポインタでいいんじゃないの？
140 ：デフォルトの名無しさん：2011/07/26(火) 20:33:06.73
何もかもマクロでOK
141 ：デフォルトの名無しさん：2011/07/26(火) 20:37:52.30
>>138
templateと組み合わせればいいよね。
俺もdecltypeがない時代にはよく作ってた。
142 ：デフォルトの名無しさん：2011/07/26(火) 23:37:40.10
本の虫の人のユーザー定義リテラル嫌いは異常
143 ：デフォルトの名無しさん：2011/07/26(火) 23:58:24.60
今回の策定には予約語の名前空間とかって全く出なかったの？
予約語は広域名前空間の所属って事にしとけば、コンテキスト依存とか
作らずに済んで今後のキーワード追加が楽になっただろうに。
144 ：デフォルトの名無しさん：2011/07/27(水) 00:04:04.94
それはそれでただでさえ死んでるlexerがハーデスに魂を売って攻めてくる勢いになるぞ……
145 ：デフォルトの名無しさん：2011/07/27(水) 00:05:56.19
>>143
そのやり方だと、広域でない名前空間に予約語を名前として登録できてしまうが?
146 ：デフォルトの名無しさん：2011/07/27(水) 00:09:07.26
名前空間ごとに予約語の意味が変わるとか素敵やん
147 ：デフォルトの名無しさん：2011/07/27(水) 00:16:07.70
Lisp 系言語だとそういうの有るよな。
148 ：デフォルトの名無しさん：2011/07/27(水) 00:17:48.75
>>145
使いもしないexportとかに延々と予約語として居座られてるよりましだろ。
import(),export()メンバーとか素敵やん。
149 ：デフォルトの名無しさん：2011/07/27(水) 00:45:56.40
使われてない予約語があるより、
名前の意味が変わってしまうほうがましか…
さすが思い付き君w
150 ：デフォルトの名無しさん：2011/07/27(水) 02:04:45.59
auto「・・・」
151 ：デフォルトの名無しさん：2011/07/27(水) 02:37:15.17
予約語namespaceを上書きして詰む言語とか面白いな
152 ：デフォルトの名無しさん：2011/07/27(水) 06:04:59.54
Forthの仲間入りできるなんて素敵やん
153 ：デフォルトの名無しさん：2011/07/27(水) 11:25:20.82
なんで本の虫なんていう名前にしたのだろうね。
自分は本を沢山読むことを誇りにしているからなのかもね。
154 ：デフォルトの名無しさん：2011/07/27(水) 12:06:44.07
>>153
そんな話はマ板でやれば?
155 ：デフォルトの名無しさん：2011/07/27(水) 12:56:50.21
じゃあ俺はエロ本の虫にするわ
156 ：デフォルトの名無しさん：2011/07/27(水) 13:26:51.26
g++ にc++0x拡張オプションで使えるのって
autoぐらい？
157 ：デフォルトの名無しさん：2011/07/27(水) 13:32:26.39
>>156
GCCか？ここ見ろ。
ttp://gcc.gnu.org/gcc-4.6/cxx0x_status.html
158 ：デフォルトの名無しさん：2011/07/27(水) 13:43:00.87
decltype復活してほしいなあ
159 ：デフォルトの名無しさん：2011/07/28(木) 11:33:12.80
boost::shared_ptrは出来損ない
stdに入れた意味が分からない
160 ：デフォルトの名無しさん：2011/07/28(木) 12:01:35.24
どうせならintrusive_ptrが欲しかったなぁと思ったらtr2には入るんだっけ?
shared_ptr使うくらいなら作るよね
161 ：デフォルトの名無しさん：2011/07/28(木) 13:03:29.86
shared_ptrは機能と性能で丁度いいところ。出来損ないなんかなじゃない。
162 ：デフォルトの名無しさん：2011/07/28(木) 13:15:12.63
http://flyingfrogblog.blogspot.com/2011/01/boosts-sharedptr-up-to-10-slower-than.html
163 ：デフォルトの名無しさん：2011/07/28(木) 14:47:15.73
動的削除とスレッド対応は機能を分離するべきだった
要らんときにまで無駄なコストが掛かる
164 ：デフォルトの名無しさん：2011/07/28(木) 15:56:50.78
それは実装の問題であってshared_ptrの仕様の問題じゃない。
165 ：デフォルトの名無しさん：2011/07/28(木) 16:42:30.78
仕様の問題だろ
166 ：デフォルトの名無しさん：2011/07/28(木) 17:58:21.65
boostのはコンパイル時のコンフィグでスレッド対応無効に出来る。
167 ：デフォルトの名無しさん：2011/07/28(木) 18:54:44.40
標準ライブラリとしての shared_ptr は可用性を優先したということなんじゃないかな
コンパイラがその使用を強制する訳ではないし
必要で可能ならBoehm GCとかを使う自由は常に残されてる訳で
168 ：デフォルトの名無しさん：2011/07/28(木) 19:40:46.33
intrusive_ptr をキーワード消費してでも言語レベルで実装すれば全て解決
shared_ptr はライブラリでOK
169 ：デフォルトの名無しさん：2011/07/28(木) 23:27:13.79
intrusive_ptrはintrusiveっていう乱暴な形容詞のせいで損してると思う
170 ：デフォルトの名無しさん：2011/07/29(金) 03:33:44.56
確かにintrusive_ptrは言語レベルで有って良い機能だよな
171 ：デフォルトの名無しさん：2011/07/29(金) 04:45:31.46
そうかそうか
172 ：デフォルトの名無しさん：2011/07/29(金) 07:48:15.82
ねーよ
173 ：デフォルトの名無しさん：2011/07/29(金) 07:48:40.86
>>170
ライブラリのままでもいいような……
いまのライブラリ形式と比べてなにかいいことあるか？
174 ：デフォルトの名無しさん：2011/07/29(金) 08:03:14.35
>>173
コンパイラでインライン展開された時に最適化できる余地が増えるかも
175 ：デフォルトの名無しさん：2011/07/29(金) 11:28:03.55
あほらし
176 ：デフォルトの名無しさん：2011/07/29(金) 21:57:50.47
vtbl埋め込めるなら参照カウンタだって埋め込めるはず
177 ：デフォルトの名無しさん：2011/07/29(金) 22:09:14.59
え？参照カウンタ内蔵？？ユーザーオブジェクトがカウンタ持ってるのを融通するポインタじゃないの？
178 ：デフォルトの名無しさん：2011/07/30(土) 00:06:48.85
どこで死ぬか判らんのにポインタに埋めてどーすんだよ
それならshared_ptrで十分じゃん
179 ：デフォルトの名無しさん：2011/07/30(土) 07:05:31.15
constみたいな記述でいいよね
実体や生ポでこさえたオブジェクトにはカウンタ付けない、カウンタは見えない触れない、生ポ→intrusiveは不可、循環参照は「知らんshared_ptr使え」で

A*intrusive a;
180 ：デフォルトの名無しさん：2011/07/30(土) 07:49:46.44
shared_ptrも循環参照は・・・
181 ：デフォルトの名無しさん：2011/07/30(土) 07:50:29.01
weak_ptr使えだな
182 ：デフォルトの名無しさん：2011/07/30(土) 15:27:33.64
何がやりたいのかなんとなくわかった
intrusive をつけると自動的に参照カウンタを添加してくれる機能か


それってshared_ptrなんじゃ……
183 ：デフォルトの名無しさん：2011/07/30(土) 15:45:52.26
shared_ptrは非効率的に自動的にカウンタを付加してくれる機能
組み込みは効率的に以下同文ってことを言いたいんだろう
184 ：デフォルトの名無しさん：2011/07/30(土) 16:30:24.98
make_shared で解決？
185 ：デフォルトの名無しさん：2011/07/30(土) 16:33:49.32
機能選べればもっとマシになるんだがなぁ
186 ：デフォルトの名無しさん：2011/07/30(土) 16:40:48.33
選択的にオンオフが出来て、コンパイラがそれを有効活用出来ればいいけど。
187 ：デフォルトの名無しさん：2011/07/30(土) 16:49:03.89
>>185 選べたとして、削りたい機能って何？何のため？
188 ：デフォルトの名無しさん：2011/07/30(土) 16:56:11.70
メジャーな部分だと動的デリータとかマルチタスク対応だな
使ってない時でもコスト払うのはばからしい
189 ：デフォルトの名無しさん：2011/07/30(土) 17:07:26.24
>>187
>>185じゃないけどマルチスレッドとデリータだろうな
影響の大きさはともかく、
前者はカウンタの増減の実行速度に
後者はshared_ptrのサイズに影響する


これらをポリシー化すればもうちょいマシになると思うんだけどどうだろう
カウンタとデリータの確保は確かプ−ルから取ってるからこれ以上効率化するのは難しいだろうし
190 ：デフォルトの名無しさん：2011/07/30(土) 19:09:48.45
ばかばっか
191 ：デフォルトの名無しさん：2011/07/30(土) 19:15:01.31
うむ。>>190とかまじ馬鹿だよな
192 ：デフォルトの名無しさん：2011/07/30(土) 21:43:06.28
>>188
ソース中で使わなきゃ無駄に動かないだろ。
例外と同じ。
193 ：デフォルトの名無しさん：2011/07/30(土) 21:47:11.54
デリータはポインタ所有権持った瞬間に生成されるから使わないとか無理
コピーやら代入やらもマルチタスク対応してんのにコレ使わなかったら共有ポインタの意義ゼロじゃねーか
なんか書き込みたい時はちゃんと少しは考えてからにしてくれ
194 ：デフォルトの名無しさん：2011/07/30(土) 23:10:18.82
どうやったら使わずに済むだろうかと悩んでしまったw
195 ：デフォルトの名無しさん：2011/07/31(日) 16:28:37.77
intrusive_ptrが言語レベルで実装されればscoped_ptrやauto_ptrもお役御免に出来るな
auto_ptrの破壊コピも解消されて可用範囲広がるし
196 ：デフォルトの名無しさん：2011/07/31(日) 16:42:27.33
普通のポインタとどう共存するつもりかい
197 ：デフォルトの名無しさん：2011/07/31(日) 17:22:20.44
ポインタ演算実行時に型情報を確認する行程を挟む負担くらいだと思うよ
条件の無い代入やconstポインタ等コンパイル時で有る程度決定できるだろうし
198 ：デフォルトの名無しさん：2011/07/31(日) 17:42:59.90
パフォーマンス重視するならちゃんと設計して生ポかユニポで話はおしまいなんですけどね
パフォーマンスを気にしてもしゃーないところを適当に済ませる分にはシェアポは優秀
199 ：デフォルトの名無しさん：2011/07/31(日) 18:12:37.28
普通のポインタに代入した場合とか
200 ：デフォルトの名無しさん：2011/07/31(日) 18:24:24.03
マーク＆スイープ方式のGCライブラリないの？
201 ：デフォルトの名無しさん：2011/07/31(日) 19:32:36.20
boost::noncopyable が継承するとコピーできなくなるように、
継承すると一時オブジェクトのみ作れなくなるようなクラスって作れませんか?
202 ：デフォルトの名無しさん：2011/07/31(日) 20:07:37.99
コンストラクタをプライベートとかにしてstaticメソッドでnewして
ポインタ返すようにすれば0x関係ないな
203 ：デフォルトの名無しさん：2011/07/31(日) 23:02:32.74
一時オブジェクトは作れないけどスタックには置きたいとか？
ならどうやっても無理
204 ：デフォルトの名無しさん：2011/08/01(月) 03:27:13.50
ですよねー。
205 ：デフォルトの名無しさん：2011/08/01(月) 03:28:16.26
ありがとうございました。(間違って途中で送ってしまいました)
206 ：デフォルトの名無しさん：2011/08/06(土) 00:05:26.32
久々にmailing来てるな
ちょっとだけだけど
207 ：デフォルトの名無しさん：2011/08/06(土) 00:11:13.61
>>206
Sun ONE StdioのClamageさん、Oracleに留まっているのか。
208 ：デフォルトの名無しさん：2011/08/06(土) 16:26:32.47
最適化関連で新規導入されたのはないの？
209 ：デフォルトの名無しさん：2011/08/06(土) 16:28:50.23
constexprとか？
210 ：デフォルトの名無しさん：2011/08/06(土) 18:17:18.91
こういう質問ってどこまでを現行と認識してるのかがわからんｗｗ
211 ：デフォルトの名無しさん：2011/08/06(土) 20:16:21.41
03だろ常識的に
212 ：デフォルトの名無しさん：2011/08/07(日) 00:42:42.12
>>176
カウンタはvtblじゃなくてヒープのメモリ管理領域を拡張するかなんかして埋め込む形になると思うわ
「生ポの代入を認めず」になれば判別はコンパイルタイムに行えるから

一般的じゃないメモリモデルマシンの場合はどうなるか知らんけど
213 ：デフォルトの名無しさん：2011/08/07(日) 03:01:47.97
>>212
> 「生ポの代入を認めず」になれば判別はコンパイルタイムに行えるから

研究レベルでも行える時がたまにあるレベルです。
214 ：デフォルトの名無しさん：2011/08/07(日) 04:06:46.78
Automatic Reference Counting
215 ：デフォルトの名無しさん：2011/08/08(月) 13:46:33.79
llvm になかなか欲しい機能がとりこまれない
lambdaとか
llvmって素人がコードの投稿できるものなの？
216 ：デフォルトの名無しさん：2011/08/08(月) 14:09:03.04
俺の欲しい機能がないからという理由で、lambdaをちょちょいと実装してパッチ送る「素人」か。
217 ：デフォルトの名無しさん：2011/08/08(月) 14:14:21.16
llvm/clangコードリーディングやりたいな
218 ：デフォルトの名無しさん：2011/08/08(月) 18:00:07.14
llvmにlambdaはいらんだろ。
Clangの間違いか?
とりあえず開発者メーリングリスト読めよ。
219 ：デフォルトの名無しさん：2011/08/08(月) 18:36:28.73
>>216
おっとApple社の悪口はそこまでだ
220 ：デフォルトの名無しさん：2011/08/08(月) 18:59:29.06
ClangにはBlocksが入るんだからそれを使えばいい
221 ：デフォルトの名無しさん：2011/08/08(月) 19:24:18.90
お断りします
222 ：デフォルトの名無しさん：2011/08/08(月) 20:12:18.78
>>220
いやむしろBlocksがそれじゃねという……
223 ：デフォルトの名無しさん：2011/08/08(月) 20:35:56.57
bitcodeレベルでラムダを表現するなにかが欲しいということだろう。
最適化が期待できるし、カスタムフェーズ挟んで関数型言語のコンパイラみたく
スタックをヒープに取るような荒業もいれられるかもしれない。

まあスレチ。
224 ：デフォルトの名無しさん：2011/08/10(水) 17:39:59.36
C++にもproperty ほしいな
225 ：デフォルトの名無しさん：2011/08/10(水) 17:41:00.73
vcのアレみたいなのか？
226 ：デフォルトの名無しさん：2011/08/10(水) 17:56:14.39
委員会はpropertyいらないって方向みたいだけどやっぱり欲しいよね。
自分で実装するとどうしたってthisへの（無駄な）ポインタを持たせないといけないし。
227 ：デフォルトの名無しさん：2011/08/10(水) 19:21:54.85
thisポインタ・・・？
228 ：デフォルトの名無しさん：2011/08/10(水) 19:36:17.78
こういう事でしょ？
ttp://codepad.org/vYUHccGr
229 ：デフォルトの名無しさん：2011/08/10(水) 19:41:49.90
そうですね　テンプレートではノーコストでプロパティを実現することは難しいような気がします
できれば規格でサポートしてもらえると嬉しいのですが…
230 ：デフォルトの名無しさん：2011/08/10(水) 19:46:24.20
プロパティでセッタをパブリック未満にしたいことはよくあるな。
ノーマルな関数形式はそろそろ何とかならんのかね。シンタックスシュガーでいいから。

>>228
バインド系ってこう書くのか。へぇー。
231 ：デフォルトの名無しさん：2011/08/10(水) 20:24:07.02
Borland C++Builderなんかではpropertyがうまく機能していたように思うんだけど、
どこも真似してないよね。なんでだろう？
232 ：デフォルトの名無しさん：2011/08/10(水) 20:33:57.47
getとsetだけだと+=とかできないから
233 ：デフォルトの名無しさん：2011/08/10(水) 20:35:51.32
両方使えば済むんじゃ
234 ：デフォルトの名無しさん：2011/08/10(水) 20:40:14.77
Obj-C 2.0
235 ：デフォルトの名無しさん：2011/08/10(水) 21:06:35.97
>>233
intとかならそれでいいけど、ユーザー定義のoperator +=があるクラスはどうする？
236 ：デフォルトの名無しさん：2011/08/10(水) 22:54:41.35
T tmp = get(); set( tmp += x ); はどうかな
237 ：デフォルトの名無しさん：2011/08/11(木) 00:16:11.07
どこまで最適化されるかだが・・・
238 ：デフォルトの名無しさん：2011/08/11(木) 02:19:32.97
>>236
定義がループしてるじゃねーかw
239 ：デフォルトの名無しさん：2011/08/11(木) 02:46:18.38
>>238
え、どこが？
240 ：デフォルトの名無しさん：2011/08/11(木) 03:18:43.75
適当に書いてみましたが、勘違いしてたらゴメン。
ttp://ideone.com/boEdA
241 ：デフォルトの名無しさん：2011/08/11(木) 07:26:50.62
#define PROP_INIT(type, name) name(this, &type::get_##name, &type::set_##name)
みたいなマクロが欲しくなるな
242 ：デフォルトの名無しさん：2011/08/11(木) 07:32:28.87
C++0xの機能で何かプロパティ作成に役立ちそうなものはないものか
243 ：デフォルトの名無しさん：2011/08/11(木) 11:42:28.55
>>240
演算子オーバーロードは全列挙したらいけそうだね。
一般メンバ関数は方法ないかな？
244 ：デフォルトの名無しさん：2011/08/11(木) 13:48:14.01
>>243
->をオーバーロードして実体のポインタを返すようにすればなんとか(shared_ptrとかの真似)。
ttp://ideone.com/4vi4m ... 前回のをそのまま改造したもの。一時アドレスの警告が出る。
ttp://ideone.com/24R9e ... getterでポインタを返すようにしたもの。
245 ：デフォルトの名無しさん：2011/08/11(木) 14:36:50.50
getterでポインタは無いなあ。自分の持ってないor一時的なオブジェクトをさも持っているように見せかけるための
プロパティなんだから、ポインタ返せるならそれこそ参照でもメンバに持ってればいいし。

->は、C++のセマンティクスとして微妙じゃね？
shared_ptrはポインタを踏襲しているから->だけど、プロパティはメンバ変数もどきだから.じゃないと整合性が
246 ：デフォルトの名無しさん：2011/08/11(木) 14:45:21.32
>>245
プロパティを狭く捉え過ぎでは? > さも持っているかのように
247 ：デフォルトの名無しさん：2011/08/11(木) 15:08:48.29
>>246
↓とかやりたいじゃん。

struct rect {
int left, top, right, bottom;
__property int width { read = get_width };
private:
int get_width(){ return right - left; }
}
248 ：デフォルトの名無しさん：2011/08/11(木) 15:24:52.58
つ 狭く
249 ：デフォルトの名無しさん：2011/08/11(木) 17:47:18.96
こういうプロパティでも凄く有用なんだけどな
private: int _left;
public:
__property int left {
get(){return _left;}
set(int n){_left=n;}
};
250 ：デフォルトの名無しさん：2011/08/11(木) 19:53:18.31
>>245
->だったらそのまま関数の呼び出しが自然に書けるかなと思ったんですが。
あとは()とか。http://ideone.com/cSQ3e
かなりC++0xから離れた話題が続いてしまったので、私からは以上です。
勉強になりました。ありがとうございました。
251 ：デフォルトの名無しさん：2011/08/12(金) 01:00:00.45
この方がC++0xっぽくていいかな。
struct A {
int get() const;
void set(int);

property int read_write(&A::get, &A::set);
property int readonly = &A::get;
property int writeonly(0, &A::set);
property int dynamic;

A(): dynamic(&A::get) {}
};
252 ：デフォルトの名無しさん：2011/08/12(金) 06:08:58.93
既存のコンパイラ拡張の__propertyにラムダ突っ込んで叱られるフラグ
253 ：デフォルトの名無しさん：2011/08/12(金) 22:50:26.19
private:
int _value;
public:
PropertyMacro(int, Value)
{
int get() const { return self->_value; }
void set(int value) { self->_value = value; }
};
C++03でこんな感じに書けるようにしたことあったけど、作るだけ作って結局使ってないな
thisポインタ持たなくてもいいようになればなぁ
254 ：デフォルトの名無しさん：2011/08/12(金) 23:57:51.85
property だから括弧要らないとか考えるのめんどくさくないか？
255 ：デフォルトの名無しさん：2011/08/13(土) 02:41:47.27
データメンバーだから括弧要らないとか考えるのと一緒じゃないですか
256 ：デフォルトの名無しさん：2011/08/13(土) 03:02:50.01
プロパティ欲しいとか言ってるヤツの要求はこんなもんで満たせるんじゃね？
単純にするために漏れ漏れpublic制約があるけど

#define CLOSE_GSTTER };
#define GSETTER(a,b)struct a{b a##_value;operator const b&()const{return a##_value;}const b&operator=(const b&x){return a##_value=x;} };
#define GSETTERFACTS(a,b)struct a{b a##_value;operator const b&()const{return a##_value;}
#define GSETTERFACTGS(a,b)struct a{b a##_value;

struct A{
GSTTER(MYINT,int)
GETTERFACTS(MYINT2,int)
  int operator=(const int x){return MYINT2_value=x/2;}
CLOSE_GSTTER };
257 ：デフォルトの名無しさん：2011/08/13(土) 04:12:03.33
もうちょっと整理してくれ
258 ：デフォルトの名無しさん：2011/08/13(土) 04:27:44.30
class nantoka {
struct { int value; operator... } puropati; の形は
struct 内部で変数を宣言しなければならないのと
内部で宣言した変数にしかアクセスできない制限がありまする
259 ：デフォルトの名無しさん：2011/08/13(土) 12:45:56.59
C++0xが満場一致で国際標準として承認されました。
260 ：デフォルトの名無しさん：2011/08/13(土) 14:06:36.49
そうかそうか

そうか……
261 ：デフォルトの名無しさん：2011/08/13(土) 16:31:39.14
bravo!
262 ：デフォルトの名無しさん：2011/08/13(土) 16:50:28.54
>>255
データーメンバーはprivateだから考えるまでもないし。
263 ：デフォルトの名無しさん：2011/08/13(土) 18:06:22.93
>>259
C++11となったようだがC++0xの「0」とは何だったのか
264 ：デフォルトの名無しさん：2011/08/13(土) 18:14:55.40
いまさらC++11って名称が普及するかなぁ。
265 ：デフォルトの名無しさん：2011/08/13(土) 19:42:36.34
ITTFのことだ。C++12になっても驚かない。
266 ：デフォルトの名無しさん：2011/08/13(土) 20:27:37.37
>>259
ttp://herbsutter.com/2011/08/12/we-have-an-international-standard-c0x-is-unanimously-approved/
The final ISO ballot on C++0x closed on Wednesday, and we just received the results: Unanimous approval.

The next revision of C++ that we’ve been calling “C++0x” is now an International Standard!
Geneva will take several months to publish it, but we hope it will be published well within the year,
and then we’ll be able to call it “C++11.”

I want to extend my thanks again to Bjarne Stroustrup for sharing his work with the world
and continuing to help move it forward,
and to all of the participants whose hard work went into achieving this important milestone in the history of a great language.
Thanks!
267 ：デフォルトの名無しさん：2011/08/13(土) 21:48:54.59
>>263
0bないし0cの0と、全会で一致しております。
268 ：デフォルトの名無しさん：2011/08/13(土) 22:06:35.98
ようやく決まったか！
今FDIS読んでるといくつが誤植あるけど、直されてんのかね

113p2行目　) が足りない
201p sometype と some_type が混在

あとどうでもいいけど、180pの [[ no return ]] はスペース空けてんのに
[[carries_dependency]] は空けてないのが気になる

71pの３行目も気になるんだけど、これは何が言いたいのだろうか？
pb の指す先に関わらず、&pb は OK だと思うんだけど
269 ：デフォルトの名無しさん：2011/08/13(土) 22:13:26.64
ユーザー定義リテラルさん大勝利ｗｗｗｗｗｗ
270 ：hiding：2011/08/13(土) 23:10:35.76
勝手に改名させられたあげく、退学処分になりました。
271 ：デフォルトの名無しさん：2011/08/13(土) 23:30:42.69
学園の人々 決定ver. を書いてくれ
272 ：デフォルトの名無しさん：2011/08/13(土) 23:42:32.86
VCにイニシャライザリストさんがくるのかな。かなり楽しみ。
273 ：デフォルトの名無しさん：2011/08/14(日) 06:02:04.19
template alias があれば typename myalloc_vector<int>::type とタイプせずにすむ…＞＜
274 ：デフォルトの名無しさん：2011/08/14(日) 07:00:29.76
>>268
原則としてFDISは修正不可、賛否表明のみだから多分残る。
さあ今すぐDefect Reportを！
275 ：デフォルトの名無しさん：2011/08/14(日) 08:04:28.51
次はC++2xになるのか？
276 ：デフォルトの名無しさん：2011/08/14(日) 09:55:19.85
禿はC++16くらいにしたいと言っていた
ということは実際はC++20あたりだな
277 ：デフォルトの名無しさん：2011/08/14(日) 10:57:15.33
ttp://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50372

Stage: 50.60→投票終了
60.00→刊行作業中
60.20→発行
278 ：デフォルトの名無しさん：2011/08/14(日) 11:59:55.47
最後は60.60ですな。
279 ：デフォルトの名無しさん：2011/08/14(日) 12:21:01.30
tr2ってどうなったの？
280 ：デフォルトの名無しさん：2011/08/14(日) 13:01:05.54
gccの<regex>サポートはまだ時間かかるのかなあ。
281 ：デフォルトの名無しさん：2011/08/14(日) 17:40:46.51
ﾋﾞｮｰﾝ! ｽﾎﾟｯ! ｽﾎﾟｯ!!
282 ：デフォルトの名無しさん：2011/08/15(月) 18:22:09.67
>>275
次はC++xxで
283 ：デフォルトの名無しさん：2011/08/15(月) 18:41:28.66
>>282
それ、C#の名前の由来で見掛けたようなw
284 ：デフォルトの名無しさん：2011/08/15(月) 18:58:28.96
当面の課題はTR2とコンセプトか
285 ：hiding：2011/08/15(月) 19:24:36.07
いや、C++98と同じく、一年ぐらいはおとなしくなるだろうと思う。
286 ：デフォルトの名無しさん：2011/08/15(月) 21:53:09.02
コンセプトを復活させて、range-based for文のADLを、さっさと投げ捨ててほしい
287 ：デフォルトの名無しさん：2011/08/15(月) 22:01:50.86
そういやコンセプトさんは、何が難しかったんだ？
288 ：hiding：2011/08/15(月) 23:05:52.37
ググれよ。
ともかく簡単に説明すると、

「空のconcept mapに意味はあるのか。concept mapは常に自動で生成されるべきだ」
という主張と
「いや、conceptは常に明示的であるべきだ。たとえシグネチャが同じでも、意味まで同じとは限らない。明示的に書かせるべきだ」
という主張がぶつかり合って、収集がつかなくなった。
289 ：デフォルトの名無しさん：2011/08/15(月) 23:27:21.04
>>288
なるほど。ありがと。とりあえず明示的にして、あとで省略できるようにすればよかったのにね。
290 ：デフォルトの名無しさん：2011/08/16(火) 12:47:41.25
conceptさんは一から設計し直しだな
291 ：デフォルトの名無しさん：2011/08/16(火) 13:01:45.72
うむ。
事前の外部conceptsでなくテンプレート内で定義の必要を明示する方が良いわ

template<typename T>struct A{
bool operator(T a,T b){return CONCEPT<a,b>(a>b);} };
292 ：デフォルトの名無しさん：2011/08/16(火) 14:12:04.29
それだと、sort(Container& c, Comparator cmp) と
sort(Iter b, Iter e) の区別がシグネチャからは付けられなくない？
293 ：デフォルトの名無しさん：2011/08/16(火) 16:19:56.69
意味わかんない
294 ：デフォルトの名無しさん：2011/08/16(火) 17:26:54.94
>>293
禿様のありがたいお言葉を聞きなさい
ttp://cpplover.blogspot.com/2009/08/bjarne-stroustrupconcept_14.html
295 ：デフォルトの名無しさん：2011/08/16(火) 22:43:12.87
yappaわからんわ 特殊化するだけじゃないの？
template<typename T,typename U>void sort(T a,U b){〜x=CONCEPT<a>(a.ite++);if(CONCEPT<a,b>(b.cmp(x,a.ite)))swap(〜}
template<typename T>void sort(T a,T b){〜x=CONCEPT<a>(a++);if(CONCEPT<a>(x<a))swap(〜}
296 ：hiding：2011/08/16(火) 23:37:28.13
>>291だと、単に　
T型のオブジェクト通しに適用できるoperator <があり、さらにその戻り値がboolに変換可能か？
ぐらいしか判定できない。
しかしそれは、すでに現行のテンプレートで行っているじゃないか。
そういうことができなければ、正しくコンパイルエラーになる。

それは単なるシグネチの一致であって、そのoperator <が、実際には何を意味するのか保証できない。

コンセプトというのは、単なるシグネチャの一致ではなく、
たとえば、LessThanComparableとかの具体的な「意味」を表す名前をつけて、
たとえ同じoperator <であっても、単なるシグネチャの一致とは区別化できるところにあるんだよ。

297 ：デフォルトの名無しさん：2011/08/16(火) 23:47:26.44
禿が言ってるのは、現状のコンパイルエラーに対する不満だよな
エラーメッセージをわかりやすくするシンタックスシュガーが必要であると

俺的に通訳すると継承を使わないインターフェイスが必要だったな、てなとこ

意味的に operator < と operator >= の対称性が保たれているかどうかなんて
「テスト工程すべて」をコンパイラの機能だなんて幻想は考えてないだろ
298 ：デフォルトの名無しさん：2011/08/17(水) 00:00:30.83
まあaxiomは要らないと思う
あんなんコメントでいい
299 ：デフォルトの名無しさん：2011/08/17(水) 00:08:50.99
しかし、axiomの存在は理解できなかったな。
たとえばoperator <が大小比較を意味して、a < b　かつ b < c　ならば a < cであるとか、
その他様々の保証としてのaxiomを書いたとしても、
それを検証してくれるようなツールは、まず近い将来に登場しないと思うんだよ。
禿は、ソースコード中に仕様書を書くための機能だって言ってるけど、
提案されていたaxiomの極端に制限された文法で書くよりは
自然言語による表現力の高い文法で書いたほうがいいにきまってるだろ。
300 ：デフォルトの名無しさん：2011/08/17(水) 01:24:41.10
どうせ解析に使われないんなら
doxygen使えば良いじゃない、という感じ
301 ：デフォルトの名無しさん：2011/08/17(水) 12:57:12.10
ついに決まったのか
302 ：デフォルトの名無しさん：2011/08/17(水) 13:17:03.93
長い時を経て正式に決まった割に盛り上がってないな
C++最大の革新でしょ？　この温度は何？
303 ：デフォルトの名無しさん：2011/08/17(水) 13:19:24.71
C++はオワコンだから
304 ：デフォルトの名無しさん：2011/08/17(水) 13:28:37.59
もう随分前から決まったも同然だったし、
99.9%準拠のコンパイラが出るまでは特に今何か語ることもない
305 ：デフォルトの名無しさん：2011/08/17(水) 13:30:43.22
ここにいる人ならC++ 0x解説サイトとか作れるでしょ
そこでアフィってぼろ儲けしようという人はいないの
306 ：デフォルトの名無しさん：2011/08/17(水) 13:32:38.64
ぼろ儲けするほど人が来るわけない
307 ：デフォルトの名無しさん：2011/08/17(水) 13:46:18.05
現在と将来のC++ユーザーのほぼ全員が悶え苦しんでネットの情報にすがるわけだから
すごい数になるでしょ
308 ：デフォルトの名無しさん：2011/08/17(水) 13:56:49.62
つC99
309 ：デフォルトの名無しさん：2011/08/17(水) 14:21:44.81
別にフル機能使う人なんてまずいないし、そういう人は勝手に勉強する
企業では技術力低い人に合わせてコーディングルール作るから、知らなくても
問題ない
310 ：デフォルトの名無しさん：2011/08/17(水) 14:24:42.01
英語で書けば少しは儲かる可能性あるけどね。日本語じゃあ。
311 ：デフォルトの名無しさん：2011/08/17(水) 14:27:43.49
英語ならそういうサイト腐るほどあるだろ
312 ：デフォルトの名無しさん：2011/08/17(水) 14:35:02.39
C++使ってる日本人の大半の現状を見るかぎり解説とか、なぁ
313 ：デフォルトの名無しさん：2011/08/17(水) 14:53:10.60
初心者向けならC99のcompound literalを布教してくれたほうが嬉しいなあ
C++0xはソースは簡潔になるけど、人の書いたコードを読む時0xのほうが嬉しいってのがあまり思いつかない
せいぜい=defaultぐらい？
314 ：デフォルトの名無しさん：2011/08/17(水) 15:45:04.57
C++11でユーザが悶え苦しむような部分ってラムダちゃんの使い方くらいじゃね
ディープなライブラリ作成者を除けばほとんどが「何も考えなくても恩恵受けられる機能」ばかりだよ
315 ：デフォルトの名無しさん：2011/08/17(水) 16:00:44.07
lambda式のどこが難しいんだよ。
多分一番難しいのはムーブだろ。
316 ：デフォルトの名無しさん：2011/08/17(水) 16:00:56.39
いやいや読みやすさだよ。
ラムダはむしろ読みやすい方。

今までは初期化式の{}を見たらコンストラクタは呼ばれないと切って捨てれたのに、そっちも探さないといけなくなったし
range-based forだって深追いしようと思えば実際呼ばれてるbeginとend探しまわるハメになると思う
317 ：デフォルトの名無しさん：2011/08/17(水) 16:02:14.22
ムーブってそんなに難しいか？
318 ：デフォルトの名無しさん：2011/08/17(水) 16:08:09.51
難しいんで字句以外にも何度も修正されてます。
319 ：デフォルトの名無しさん：2011/08/17(水) 16:09:52.97
ムーブどころかコピーすら難しすぎて理解出来ないようなのが大勢プログラマー名乗ってるからなぁ
320 ：hiding：2011/08/17(水) 16:13:04.47
ムーブは最後の最後の土壇場になって、言語仕様に取り入れられた。
それまでは、単にrvalueリファレンスを用いるライブラリ側の取り決めでしかなかった。
でもそれじゃまずいってことで、コピーと同じく、コア言語側でも規定されるようになったんだよ。
321 ：デフォルトの名無しさん：2011/08/17(水) 16:13:10.92
そのぐらい知ってるわよ
ばかにしないでくれる
322 ：デフォルトの名無しさん：2011/08/17(水) 16:19:22.27
hidingさんの文体が本の虫っぽいけど本人ですか？
323 ：デフォルトの名無しさん：2011/08/17(水) 16:31:18.67
盲蛇に怖じず
324 ：デフォルトの名無しさん：2011/08/17(水) 17:14:21.39
>>309
> 技術力低い人に合わせて

これだけは避けたかった受け入れがたい事態だな
丁稚や女中が組織全体の律速段階でいいんだと開き直ったら何ができるんだ

>>319
やめれ、耳が腐る
325 ：デフォルトの名無しさん：2011/08/17(水) 17:35:53.73
じゃああんたが教育すればいいんじゃね
326 ：デフォルトの名無しさん：2011/08/17(水) 17:49:39.44
C++は教育コストが高すぎる
327 ：デフォルトの名無しさん：2011/08/17(水) 17:55:29.55
ムーブは使う側が意識する必要はあまりないような
328 ：デフォルトの名無しさん：2011/08/17(水) 18:30:10.43
>>326
逆だろ、今までのプログラム言語が歴史の浅い原始的で学問未満なものだった
世のため人のために役立つ知見とは元々そんなに甘くないというだけ
329 ：デフォルトの名無しさん：2011/08/17(水) 18:34:17.71
C++を教育するコストで
CとCommon LispとSmalltalkとHaskellを教育できる
330 ：デフォルトの名無しさん：2011/08/17(水) 18:35:26.60
そもそも平均以下のプログラマには何の関係ないスレだし。
通ったばかり規格のスレだから。教育とか他所行け。ドアホ。
331 ：デフォルトの名無しさん：2011/08/17(水) 18:42:05.88
え？いまどきC++に無様にしがみついてるプログラマが平均以下じゃない……？
332 ：デフォルトの名無しさん：2011/08/17(水) 18:45:14.03
同感だな
自分は平均以下でないと行間で言ってるのがすげー滑稽
333 ：デフォルトの名無しさん：2011/08/17(水) 19:22:08.86
お前一人でどれだけのコードがかけるんだって話。
教育コストは生産性の大きなポイント。
334 ：デフォルトの名無しさん：2011/08/17(水) 20:14:43.61
違うね
大きなポイントはコストではなく効果だ

最大のポイントはそいつの生涯の稼ぎで
次いで教育コストとの比
それから負担割合

不戦敗する奴に金かけるのは確かに無駄だ
335 ：デフォルトの名無しさん：2011/08/17(水) 20:16:06.09
templateでlispインタプリタ作れるまでC++を熟知するより、3Dのレンダリングエンジンを
フルスクラッチで開発できるようになる方が時間がかかると思うが。
336 ：デフォルトの名無しさん：2011/08/17(水) 20:33:06.14
あほか
337 ：デフォルトの名無しさん：2011/08/17(水) 20:35:48.36
まあ言語の勉強をするぐらいならアルゴリズムの勉強をしたほうがいいってのは正しいからなあ
338 ：デフォルトの名無しさん：2011/08/17(水) 20:36:51.92
axiomうんぬんは永遠に先延ばしするとして
static_assert系の仕組みの引数にprintfのformatみたいな方式でoperator有無のチェックを記述出来る様にしたらどうかな

static_assert(A,"++\(int)++\*()\*(A)","unimplemented");
339 ：デフォルトの名無しさん：2011/08/17(水) 20:37:07.83
モノつくれよｗ
340 ：デフォルトの名無しさん：2011/08/17(水) 21:39:58.60
作ったよ
http://www.mono-project.com/Main_Page
341 ：デフォルトの名無しさん：2011/08/17(水) 22:24:46.43
>>338
そんなのやだ
演算子の有無はconceptでチェックしたい
342 ：デフォルトの名無しさん：2011/08/17(水) 22:25:44.19
>>338
これじゃあかんの
sizeof((A()+1,A()-1,A()*1,A()/1))
343 ：デフォルトの名無しさん：2011/08/17(水) 22:29:13.34
同じフレーズを何度も書き直すのすげーいや
344 ：デフォルトの名無しさん：2011/08/18(木) 00:18:48.07
>>342
インクリ/デクリメントのチェックに副作用が
345 ：デフォルトの名無しさん：2011/08/18(木) 00:47:33.74
なんだかんだ言ってもWebKitとかChromeとかv8とか、
低レベルシステムソフトウェアはC++が全盛です。
底辺プログラマには縁のない世界。
346 ：デフォルトの名無しさん：2011/08/18(木) 00:56:47.19
低レベルと底辺をうまくかけたなｗ
347 ：デフォルトの名無しさん：2011/08/18(木) 01:02:34.63
そりゃてーへんだ
348 ：デフォルトの名無しさん：2011/08/18(木) 01:15:58.01
大変と底辺をうまくかけたなｗ
349 ：デフォルトの名無しさん：2011/08/18(木) 10:38:03.76
>>343
decltype使った末尾戻り値型もそんな感じだな
lambdaみたいに戻り値の型をreturnに書いたやつから類推して欲しかった
350 ：デフォルトの名無しさん：2011/08/18(木) 16:55:39.20
>>349
returnから型推定すごい欲しいなあ
OCamel使えば自動型推定はやってくれるけど
351 ：デフォルトの名無しさん：2011/08/18(木) 18:28:03.78
関数の定義見るまで返却値型がわからないんじゃ前方宣言もあいまいになるし
そうなると宣言だけあれば関数を呼び出せるのができなくなるだろ
352 ：デフォルトの名無しさん：2011/08/18(木) 18:46:06.02
includeに代わる何かをどうにかしようって話とも関係してくるようなそうでもないような
353 ：デフォルトの名無しさん：2011/08/18(木) 19:32:48.04
結局プロトタイプでは型推論しようがないからなぁ
354 ：デフォルトの名無しさん：2011/08/18(木) 23:13:16.42
型推論はなんで必要なの？
書くのが面倒ならマクロ使えばいいじゃない。
355 ：デフォルトの名無しさん：2011/08/18(木) 23:29:48.59
オレオレマクロは再解釈するのが面倒だから廃してほしい。
356 ：デフォルトの名無しさん：2011/08/19(金) 02:18:34.50
定義の場合のみ類推可能にすればいいんじゃないの？
template <typename A, typename B> auto add(A a, B b) -> decltype(a+b) { return a+b; }
を
template <typename A, typename B> auto add(A a, B b) { return a+b; }
にできるだけでも価値はあると思うけど

まあ、構文解析難しいとか他に何か問題があれば別だが
357 ：デフォルトの名無しさん：2011/08/19(金) 04:31:46.87
template <typename A, typename B> auto add(A a, B b) { if(pred)return a+b;else return NULL; }
とかどうする気なの
358 ：デフォルトの名無しさん：2011/08/19(金) 07:53:19.72
次のスレタイどうなるの
C++11 14？
359 ：デフォルトの名無しさん：2011/08/19(金) 08:13:42.72
それは規格書が出版されてからでいいんでない?
出版が来年にずれ込んだら C++12 になるのだし
360 ：デフォルトの名無しさん：2011/08/19(金) 09:13:11.15
C++0xで定着しちゃったからなぁ・・・
361 ：デフォルトの名無しさん：2011/08/19(金) 10:02:23.47
>>357
template <typename T> void f(T a, T b);
f(a+b, NULL);
のTと同じ型が類推される、と定義すればいい。
型が合わなければエラー。
362 ：デフォルトの名無しさん：2011/08/19(金) 10:10:27.54
>>356
template <typename A, typename B> auto add(A a, B b) { return decltype(a+b); }
って書ければいいんじゃない？
returnが複数あればそれぞれdecltypeって書く。
template <typename A, typename B> auto add(A a, B b) { if(pred)return decltype(a+b);else return decltype(NULL); }
複数にdecltypeに矛盾がなければ戻り値の型が決まり、矛盾があればエラー、とか。
363 ：デフォルトの名無しさん：2011/08/19(金) 10:14:52.94
>>362
ﾜｹﾜｶﾗﾝ
364 ：デフォルトの名無しさん：2011/08/19(金) 10:24:01.49
戻り値型の類推自体は既にlambdaがやってんだし、何も特殊な事ではない
定義がないと使えないというのはあるけど、別にそこは重要ではないと思う。
なぜなら、ほとんどの場合テンプレートでしか必要ないから。
（テンプレートじゃなくても、一応inlineや内部リンケージでも可能だが）

プロトタイプも、定義が出てこないと使えないものの、書く事自体は出来てもいい。
例えば

template <typename A, typename B>
struct BinaryOperation
{
　auto add(A a, B b);
};

template <typename A, typename B>
auto BinaryOperation<A, B>::add(A a, B b) { return a+b; }

とか。
365 ：デフォルトの名無しさん：2011/08/19(金) 18:53:11.11
>>358 c++1x 14 でいいんでね？
366 ：デフォルトの名無しさん：2011/08/19(金) 18:58:16.53
プロトタイプ宣言の話と似てくるが再帰呼び出しが(も)できない
367 ：デフォルトの名無しさん：2011/08/19(金) 19:20:37.73
C++1xだと次の仮称になる可能性があって紛らわしい
368 ：デフォルトの名無しさん：2011/08/19(金) 19:40:07.41
>>367
ないない。
369 ：デフォルトの名無しさん：2011/08/19(金) 23:15:12.74
次は素直にC++xxにするんじゃない？
その次はしらんけど。
370 ：デフォルトの名無しさん：2011/08/19(金) 23:36:24.16
シムシティ路線でC++3000
371 ：デフォルトの名無しさん：2011/08/21(日) 02:00:21.61
次期concept早く来ないかな。
concept = constraint + axiom
って感じらしいが。
372 ：デフォルトの名無しさん：2011/08/21(日) 09:07:20.29
axiomはｲﾗﾈ
373 ：デフォルトの名無しさん：2011/08/21(日) 10:46:54.11
個人的に理解不能なものを拒絶してしまうのはよくあること
374 ：デフォルトの名無しさん：2011/08/21(日) 12:09:26.37
axiomの存在価値を理解できるか？
英語でいいからコメント書いてくれてる方が分かりやすい
375 ：デフォルトの名無しさん：2011/08/21(日) 12:47:19.85
ペーパーで解説無かった？
376 ：デフォルトの名無しさん：2011/08/21(日) 13:00:28.25
concept さんが在学していたころのドラフトを持ってないからよくわからないんだけど
axiom って最適化に使ってもいいみたいだし
それなら意味があるのでは？

「axiom に違反するときはコンパイルエラー」とか「例外をなげる」とか
変なことを言い出したら、
exception specification の二の舞になる気もするけど

「axiom に従って勝手に最適化しますよ。
あなたのクラスが axiom に違反してても気にしませんよ」

という感じでやってくれるなら歓迎。
377 ：デフォルトの名無しさん：2011/08/21(日) 13:13:55.53
最適化ならpragmaでいいじゃん。
378 ：376：2011/08/21(日) 13:48:22.98
N2887 を読んだら、いきなり動機で
「axiom は、最適化に役立てることは動機ではない」といきなり否定されてるな…。

なら確かにゴミだな。
379 ：デフォルトの名無しさん：2011/08/21(日) 14:54:42.82
親クラスから、孫クラスへ子クラスでコンストラクターを作らず、
コンストラクターを呼び出させる事ってC++0xじゃないと無理なんかね？
380 ：デフォルトの名無しさん：2011/08/21(日) 15:42:18.63
struct Base{
Base(){}
};
struct Derived{
Derived()=delete;
};
struct Grandderived{
Grandderived(): Base::Base(){}
};
こういうこと？
0xでも無理だろ
381 ：デフォルトの名無しさん：2011/08/21(日) 16:30:34.91
0xなら子のコンストラクターを一切書かないことを条件に、
親クラスのコンストラクターを子に引き継がせることができる。
382 ：hiding：2011/08/21(日) 16:44:22.09
>>381
継承コンストラクターは、コンストラクターが無いわけじゃない。
継承コンストラクターは、基本クラスのコンストラクターと同じシグネチャで、
実引数をそのまま渡すコンストラクターを、自動的に宣言するだけだぞ。

「コンストラクターを作らず」といったら、>>380だ。
383 ：デフォルトの名無しさん：2011/08/21(日) 16:54:40.00
c++0xは完全にマスターした
早くc++1x来い
384 ：デフォルトの名無しさん：2011/08/21(日) 17:28:26.01
>>382
理屈がどうであれ実質変わらんがな。
暗黙で作られるつったってコンパイラはどうせvtableだけ置き換えて
親クラスのコンストラクターそのまま使うんだから。

>>382がもし理屈上だけでなく明確な実装まで影響する話だとしたら、
0xの継承コンストラクターって、オブジェクトの値渡しをしたら
子のコンストラクターで1回、親のコンストラクターで2回目の
コピーないしムーブコンストラクターが呼ばれるのか？
385 ：デフォルトの名無しさん：2011/08/21(日) 17:34:48.29
axiomはスキーマです。
386 ：デフォルトの名無しさん：2011/08/21(日) 17:40:50.32
スキマです。。。
隙間です。。。
ヒロシです。。。

387 ：デフォルトの名無しさん：2011/08/21(日) 18:29:33.47
>>384
12.9 の第8段落

暗黙に定義される inheriting constructor の例:
ThisClass(T t): BaseClass(static_cast<T&&>(t)) {}

ここでわざわざT&& にキャストしているのは、
親クラスのコンストラクタで T が && のときに対処するため。

で、わざわざそんな配慮をもって記述されているということは
T が値渡しならもちろん二回コピーされるってこと。
388 ：デフォルトの名無しさん：2011/08/21(日) 18:35:52.55
>>387
例と書いてあるけどそれは一例じゃなく実装義務なのか？
RVOのように省いちゃいかんのか？
389 ：デフォルトの名無しさん：2011/08/21(日) 20:28:50.49
>>388
自分で FIDS 読みなよ……と思ったけどもう非公開になってるんだったね。

省略していいなんて書いてないよ。
Inheriting constructor の概略はこう。

12.9-1. using-declaration でコンストラクタを指名すると、
　inheriting constructor を暗黙に宣言したことになる。

3. 暗黙に宣言された inheriting constructor は、
　ベースクラスと同じ引数リスト(など)をもつ。

8. inheriting constructor は、odr-used されたときに暗黙に定義される。
　暗黙に定義されたコンストラクタは、>>387 のようなユーザー定義の
　コンストラクタと同様の動作をする。
390 ：hiding：2011/08/22(月) 04:17:37.21
>>384
実装の話がしたいならスレ違いだ。

「この関数呼び出しは実装ではインライン展開されるから、規格上でも関数呼び出しなんて発生しない( ｰ`дｰ´)ｷﾘｯ」
391 ：デフォルトの名無しさん：2011/08/22(月) 12:45:22.76
もうOCamelのsubsetまるまる持ってきちゃえばいいのに
進化の方向同じなんだから
そうすればOCamelのライブラリも使いまわせて最高
392 ：デフォルトの名無しさん：2011/08/22(月) 15:38:14.94
肝心の言語の名前を間違えるくらいの認識で
進化の方向が同じなんて判断がよくできるね。
393 ：デフォルトの名無しさん：2011/08/22(月) 20:30:54.88
>>390
規格が許すか許さないかの話なんだからべつにいいんじゃね。
394 ：デフォルトの名無しさん：2011/08/22(月) 21:32:42.21
実装を見据えなかったexportがどうなったかを考えると
実装に言及するのも必要だと思う
395 ：デフォルトの名無しさん：2011/08/23(火) 00:33:53.30
OCamlのことなんかなあ。
同じ方向に見えるなら全然勉強足りないから初心者スレで修行を。
396 ：デフォルトの名無しさん：2011/08/23(火) 11:38:51.33
ガーベジコレクタのないOCaml = C++
397 ：デフォルトの名無しさん：2011/08/23(火) 12:15:17.83
名前解決に対する考え方すら全く違う。
398 ：デフォルトの名無しさん：2011/08/25(木) 17:01:28.83
17.6.3.5 Allocator requirements と
20.6.8 Allocator traits に、typedef ●●& (const_)reference; が欠けてるのはどうして?

20.12.1 scoped_allocator にもない。
20.6.9 default allocator だけは持ってるけど、これは互換性のためだろうか。
399 ：デフォルトの名無しさん：2011/08/25(木) 19:01:59.72
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2946.pdf
たぶんこのへんに書いてある
400 ：デフォルトの名無しさん：2011/08/25(木) 22:54:36.16
>>399 ﾄﾝ

「pointer とか reference とかの typedef を要求してたけど
それが必ず value_type*, value_type& でなければならないなら
意味ないじゃん、カスタマイズする人に面倒かけるだけで」

という状態だったところ、改変によって
- pointer はスマートポインタでもなんでもいいように生まれ変わった。
- reference は更生できず退学になった

というわけね。
401 ：デフォルトの名無しさん：2011/08/26(金) 13:42:06.91
いきてる?
402 ：デフォルトの名無しさん：2011/08/26(金) 20:00:40.51
スマートポインタでも何でも良くなったのであれば
ますますreference必要じゃね？
403 ：デフォルトの名無しさん：2011/08/26(金) 20:30:35.23
C++ではスマートポインタは作れるけどスマートリファレンスは作れないんだよ
404 ：デフォルトの名無しさん：2011/08/26(金) 20:45:20.70
weak_refer<T>が必要になる様なうっかり遣ってしまいそうな事てどんなコード？
子スレッドから孫スレッド作って子スレッド消滅くらいしか思いつかんわ
405 ：デフォルトの名無しさん：2011/08/26(金) 21:49:54.23
>>402
pointer側は関係ないんだよ
referenceがvalue_type&しかないのが問題
406 ：デフォルトの名無しさん：2011/08/27(土) 03:13:03.15
そっか
そりゃそうだな
まあreferenceなんざ、value_type&のみでいいんじゃね？
407 ：デフォルトの名無しさん：2011/08/27(土) 09:06:13.47
C++03 と C++11 の互換性
ttp://d.hatena.ne.jp/melpon/20110826/1314343549
408 ：デフォルトの名無しさん：2011/08/28(日) 23:46:50.31
>>406
昔のx86みたいに、farポインタnearポインタの区別のある世界なら、
referenceにもfarとnearの区別が欲しくなるのではないかと思う。
そんなところにC++11がやってくるかどうかは別として。
409 ：デフォルトの名無しさん：2011/08/29(月) 08:16:57.84
far/near の違いは pointer のほうに持たせるのが自然じゃないの？ allocator の話だろ?

allocator はたとえば vector<T, allocator<T>>::push_back(val) の val　を
far の参照で受けるべきか near かなんて責任を負わないと思うよ。
410 ：デフォルトの名無しさん：2011/08/29(月) 22:14:36.37
C++相談室を見てて思ったんだけど、イテレータコンセプトってどうして流れたの？
そのまま Boost のイテレータコンセプトを採用するって聞いたけど。。

経緯を知っている方、もしいれば教えて下さい
411 ：デフォルトの名無しさん：2011/08/30(火) 12:47:12.82
llvm　clangは早く全部の機能を実装してくれ
iphone開発で使いたいんじゃ
412 ：デフォルトの名無しさん：2011/08/30(火) 17:37:03.79
<iterator_concepts>はあったけどコンセプト削除とともに消えた
413 ：デフォルトの名無しさん：2011/08/30(火) 18:22:12.50
iphoneならBlocksさんが全部何とかしてくれるよ
414 ：デフォルトの名無しさん：2011/08/30(火) 21:53:23.55
>>411さんの要望はIndiana版conceptの彼が叶えてくれるだろう。
415 ：デフォルトの名無しさん：2011/08/31(水) 20:58:42.90
>>411
03の機能は完全なんだからいいだろ。
11での開発を今から始めるのはバカすぎる。
あと4年は待て。
416 ：デフォルトの名無しさん：2011/09/01(木) 18:57:37.59
せめてlambdaだけでも実装されないものかのお
417 ：デフォルトの名無しさん：2011/09/01(木) 20:28:20.92
されてもどうせ規格非準拠だぞ。
3,4年たったら規格準拠になって今書いたコードが
腐るかもしれん。
418 ：デフォルトの名無しさん：2011/09/01(木) 22:30:59.73
Blocksが普及するまで政治的都合でlambdaは実装されないテロ
419 ：デフォルトの名無しさん：2011/09/01(木) 23:24:29.56
３・４年も価値のあるコードなんてかけないだろｗ
420 ：デフォルトの名無しさん：2011/09/01(木) 23:31:49.76
他の言語ならともかくC++だったらあるだろ。
うちの会社のライブラリなんて未だVC6.0で書かれたものが生き残ってんだぞ。
421 ：デフォルトの名無しさん：2011/09/01(木) 23:53:09.13
簡単に書き直せるだろ
422 ：デフォルトの名無しさん：2011/09/02(金) 00:01:43.90
どうやって？
423 ：デフォルトの名無しさん：2011/09/02(金) 00:08:24.49
どうせ書き直すならboost.lambdaでも使ってたほうがマシ
424 ：デフォルトの名無しさん：2011/09/02(金) 00:17:32.56
>>421
そもそも、VCの処理系依存は、スコープすら違うんだぞ。
しかもそれが、50万行以上。
425 ：デフォルトの名無しさん：2011/09/02(金) 00:50:48.81
つかC++でラムダとか頭悪いだろ
426 ：デフォルトの名無しさん：2011/09/02(金) 00:59:23.07
ラムダさん超便利なのに。。。
427 ：デフォルトの名無しさん：2011/09/02(金) 11:13:20.08
てかCでラムダよりはまだよほどまし
428 ：デフォルトの名無しさん：2011/09/02(金) 12:25:40.96
>>418
あの人たちはCLang行ってしまったから、
g++は影響受けないと思われます。
429 ：デフォルトの名無しさん：2011/09/02(金) 18:24:42.24
>>425
ラムダまでいかないにしても、関数内関数が使えるとすごい嬉しいな
430 ：デフォルトの名無しさん：2011/09/02(金) 19:48:07.36
というか関数内ではret foo(args){body}を
auto foo=[&](args)->ret{body};と見做すようにすればいいだけなのになんで0xでも関数内関数出来ないの？
431 ：デフォルトの名無しさん：2011/09/02(金) 19:52:31.77
>>430
関数内でラムダ宣言してautoでキャプチャすればことたりるからじゃね？
432 ：デフォルトの名無しさん：2011/09/02(金) 19:57:45.41
これでなんか不満あるの？環境はVC10EESP1

#include <iostream>

int F(int v){
    auto F2 = [](int va){ return  va+1;};

    return F2(v);
}

int main(){
    int N = F(100);

    std::cout<<N<<std::endl;
    return 0;
}
433 ：デフォルトの名無しさん：2011/09/02(金) 21:37:28.44
ラムダの括弧がださいって話だろ
434 ：デフォルトの名無しさん：2011/09/02(金) 21:39:28.83
リンゴよりマシだろ
435 ：デフォルトの名無しさん：2011/09/02(金) 22:26:22.32
見た目が問題なのはautoでない時の返値だろ。decltypeの問題とはいえあれはきもい。
括弧は別に何とも思わんしどちらかというと綺麗な部類だと思うが。
436 ：デフォルトの名無しさん：2011/09/02(金) 22:51:21.90
>>430
関数内関数を導入するよりも、関数の書き方自体を　[] f() -> ret { ,,, } にシフトしていく
方針のつもりでいたんだと予想。
そうすればラムダの記法がそのまま関数内関数になる。
437 ：デフォルトの名無しさん：2011/09/02(金) 23:10:11.89
>>436 だけど lambda を引数にとる lambda を返す lambda を...
って， シグネチャ書く気力おきねぇw
438 ：デフォルトの名無しさん：2011/09/02(金) 23:32:14.75
>>437
関数ポインタは今のままの書き方でいいってことで…。

もし関数内関数を >>430 のようにキャプチャあり auto foo = [&]... にするなら
どうせ関数ポインタに入らない。

そういうのを受け取ったり返したりするのは、
template <class Lambda> と書く以上に複雑にはならない。
439 ：デフォルトの名無しさん：2011/09/03(土) 16:39:11.97
>>430
そんな差もないし別にlambdaでいいじゃない
それじゃキャプチャも自由にできないし
440 ：デフォルトの名無しさん：2011/09/03(土) 16:44:34.74
>>437
そんな複雑なことかいな？

auto bar = [](std::function<int()> f) {
　　return [=]{ return f(); };
};
441 ：デフォルトの名無しさん：2011/09/03(土) 17:26:33.65
lambdaをキーワードにすべき。
基本autoで返してポインタ、参照の修飾だけを指示出来る形で
lambda a=(int x=1){x-1};;
lambda f=(lambda(int)x){x(3);};
return f(a);
442 ：デフォルトの名無しさん：2011/09/03(土) 17:28:43.53
文法はキモいけど
キャプチャは重要だと思うよ
443 ：デフォルトの名無しさん：2011/09/03(土) 20:46:05.52
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50372
ISO/IEC 14882:2011 として発行されたようだけど、
"Target publication date: 2012-02-28" ってのはどういうことなの？
C++11 で確定でいいんだよね？
444 ：デフォルトの名無しさん：2011/09/03(土) 21:26:22.42
C++って俺の考えた最強言語ごっこできもい
445 ：デフォルトの名無しさん：2011/09/03(土) 21:27:09.83
キモいけど感じちゃう
446 ：デフォルトの名無しさん：2011/09/03(土) 21:32:00.54
他人のオナニーじゃ感じないだろｗ
447 ：デフォルトの名無しさん：2011/09/03(土) 22:05:46.87
カワイイおにゃのこのオナニーなら感じちゃうかもしれないけどヒゲオッサンのオナニーじゃなぁ。
448 ：デフォルトの名無しさん：2011/09/03(土) 23:09:54.90
>>443
半年もまだ何やる事が残ってんの？
449 ：デフォルトの名無しさん：2011/09/03(土) 23:22:59.89
>>430
GCCみたいな関数内関数を勝手に実装しやがった処理系と干渉するから。
450 ：デフォルトの名無しさん：2011/09/03(土) 23:27:00.94
別に干渉はしないだろっつーか、gccの関数内関数は実はC++では使えない。Cモードのみ。
451 ：デフォルトの名無しさん：2011/09/03(土) 23:28:59.45
>>450
※みたいな
452 ：デフォルトの名無しさん：2011/09/03(土) 23:41:51.39
gccは過去にも独自拡張してるけど、
新しい規格により不必要になったり、
バッティングしたら削除してるよ。
453 ：デフォルトの名無しさん：2011/09/04(日) 08:29:07.54
func(){

}

こういう書き方やめろ。見づらい。

func()
{

}

こう書くように。
454 ：デフォルトの名無しさん：2011/09/04(日) 08:32:52.38
>>453
http://ja.wikipedia.org/wiki/%E5%AD%97%E4%B8%8B%E3%81%92%E3%82%B9%E3%82%BF%E3%82%A4%E3%83%AB#K.26R.E3.81.AE.E3.82.B9.E3.82.BF.E3.82.A4.E3.83.AB
455 ：デフォルトの名無しさん：2011/09/04(日) 08:59:26.11
>>453
てめえのブログにでも書いてろ
456 ：デフォルトの名無しさん：2011/09/04(日) 10:17:14.87
pyhonでも書いてろ
457 ：デフォルトの名無しさん：2011/09/04(日) 10:53:37.01
ただこれはやめて欲しい
func()
　　{
　　hoge...
　　}
458 ：デフォルトの名無しさん：2011/09/04(日) 12:09:58.81
なにこのヘミ猫臭い流れ
459 ：デフォルトの名無しさん：2011/09/04(日) 12:23:50.66
11 (C++11 の略は 11 なのか？) と何の関係もない。どうでもいい
460 ：デフォルトの名無しさん：2011/09/04(日) 13:20:53.44
C++03を03とか略してたなら11でいいんじゃないの
461 ：デフォルトの名無しさん：2011/09/04(日) 13:28:57.41
0xと言う呼び方があまりに有名になりすぎた
462 ：デフォルトの名無しさん：2011/09/04(日) 14:47:01.21
0xに従えば0bと言った方がしっくりくる気もするが
２進数の接頭辞っぽく見えるという罠も
463 ：デフォルトの名無しさん：2011/09/04(日) 15:00:16.46
C++は2進のリテラルもサポートするようになるの？
464 ：デフォルトの名無しさん：2011/09/04(日) 15:07:14.98
>>463
つ operator""
465 ：デフォルトの名無しさん：2011/09/04(日) 15:40:01.77
C++0xはISO/IEC 14882:2011のことで2012年に発行される

ややこしい
466 ：デフォルトの名無しさん：2011/09/04(日) 16:43:18.66
D言語にはあるよ
467 ：デフォルトの名無しさん：2011/09/04(日) 16:43:40.67
ISO/IEC 14882:2011だから結局C++11でいいの？
468 ：デフォルトの名無しさん：2011/09/04(日) 16:45:47.54
9899:1990 を C89 と言うやつ多いし
469 ：デフォルトの名無しさん：2011/09/04(日) 17:09:08.10
>>458
ということにしたいのですね:-)
470 ：デフォルトの名無しさん：2011/09/04(日) 22:23:12.17
一体どう呼べば良いんだ・・・
471 ：デフォルトの名無しさん：2011/09/04(日) 23:08:29.84
じゃあ 0x0b で
472 ：デフォルトの名無しさん：2011/09/05(月) 08:27:58.77
>>463
良くこういう意見聞くけど何が嬉しいのか解らん。
むしろ256進数使えるほうが便利だろうに。
473 ：デフォルトの名無しさん：2011/09/05(月) 08:45:13.32
ビットマスクの可読性が16進数と比べて格段に上がる。
16進⇔2進の変換がイメージで浮かぶような変態には意味がない
474 ：デフォルトの名無しさん：2011/09/05(月) 11:01:46.45
>>472
256進数とか何が嬉しいのか解らん。
475 ：デフォルトの名無しさん：2011/09/05(月) 11:37:25.10
C++11的には60進リテラルだろ
476 ：デフォルトの名無しさん：2011/09/05(月) 13:01:33.79
そんなもんＩＤＥ側で表示変えれるようにしたらいいだけと思うが
なぜそんな機能を実装したＩＤＥがないかがアメリカ人の大雑把さだよな。
477 ：デフォルトの名無しさん：2011/09/05(月) 13:37:57.63
規格にIDE云々を持ち込む方がバカだろ
478 ：デフォルトの名無しさん：2011/09/05(月) 14:43:45.70
>>472
２５６進数って・・・ 0x00-0x1f ぬきでさえ mﾗd*%u6EBｮﾌ)61A みたいになるぞ？
確かに昨今はアドレスの類が１６進数じゃ辛くなってきているが、
それはただ IPv6 みたいに区切り表記があれば済むことで基数を変える必要はあんまりないだろ

２進数にも１６進数にもえこひいきする合理性があるが、これらに対して２５６進数を持ち出す合理性はあるのか？
479 ：デフォルトの名無しさん：2011/09/05(月) 14:49:20.77
''で囲むのが256進数じゃね？
480 ：デフォルトの名無しさん：2011/09/05(月) 15:47:22.78
>>478
「うるせえ、屑」って意味かと
481 ：デフォルトの名無しさん：2011/09/05(月) 19:55:59.48
発行、発効、どっちが正しいの？
482 ：デフォルトの名無しさん：2011/09/05(月) 20:06:16.74
verilog みたいに　_ を使って任意の場所で数字を区切れるといいのになあ。
0xffff_ffff_ffff_ffff みたいに。

>>481
発行 publication
発効 effectuation
483 ：デフォルトの名無しさん：2011/09/05(月) 23:48:54.25
>>482
adaとかそんなのができたよね。
何気にn進数も標準じゃかなったかな
484 ：デフォルトの名無しさん：2011/09/06(火) 00:18:09.09
>>481
文書類は発行で、仕様の強制力は発効じゃね？
485 ：デフォルトの名無しさん：2011/09/06(火) 00:41:07.35
>>483
区切りはD言語にもあるね

区切りがなくても、WindowsのMAKELONGみたいなのを作れば
一応区切りの代わりにはなる
486 ：デフォルトの名無しさん：2011/09/06(火) 01:58:51.20
0xNxAA で AA が N進数だと解釈するコンパイラが昔あった。
0x2x11x200 だと 18。
487 ：デフォルトの名無しさん：2011/09/06(火) 07:24:45.45
0x2x11x200
　↑ ↑ ↑
　16　2　3
　進 進 進
　数 数 数

ということか
ややっこいなw
488 ：デフォルトの名無しさん：2011/09/06(火) 09:50:18.90
それ32進数とかはどうするの?
大文字限定?
48進数は?
489 ：デフォルトの名無しさん：2011/09/06(火) 10:01:29.66
よく覚えてないけど、0-9,a-z(A-Z)の36文字しか使えないから36進数までだった気がするよ。
490 ：デフォルトの名無しさん：2011/09/06(火) 17:17:47.01
'x'は使っちゃいかんだろw
491 ：デフォルトの名無しさん：2011/09/06(火) 17:52:47.87
0 で始まるトークンの 2 文字目でなければいいんじゃね
8 進数には使えない文字だし
492 ：デフォルトの名無しさん：2011/09/06(火) 18:25:32.69
0x36xxx10は34(十進)か1630404(十進)か?
493 ：デフォルトの名無しさん：2011/09/06(火) 18:56:19.75
小文字xはタブーにすればいい
494 ：デフォルトの名無しさん：2011/09/06(火) 20:11:48.06
＜調査＞中国の胡錦濤国家主席、7割の日本人が「嫌い」

　2011年9月4日、AP通信と米GfKが共同で行った調査によると、日本人の7割が中国の胡錦濤（フー・ジンタオ）国家主席に対し、
　好感を持っていないことが分かった。米華字サイト・多維新聞が伝えた。

　調査結果によると、日本人が好きな国は「米国」（49％）が首位で、「ドイツ」（48％）が2位。
　一方、中国を「好き」だと答えた人はわずか7％、「嫌い」は76％だった。嫌いな国の首位は北朝鮮で、中国は2位だった。
　韓国に対しては41％が「好きでも嫌いでもない」、27％が「嫌い」と答えた。

　また、日本人が最も好きな国家の元首や首脳では、「天皇陛下」（70％）が首位。

　「オバマ米大統領」（41％）、「メルケル独首相」（28％）、「李明博（イ・ミョンバク）韓国大統領」（20％）がこれに続いた。
　中国の胡主席について、「好き」と答えた人はわずか6％、「嫌い」は68％だった。
　「好き」と答えた割合が最も低かったのは、北朝鮮の金正日（キム・ジョンイル）総書記の1％だった。

　調査は7月29日〜8月10日、日本各地の1000人を対象に実施された。

http://www.recordchina.co.jp/group.php?groupid=54100&type=1
495 ：486,489：2011/09/06(火) 21:42:02.22
今、CD-ROM発掘して調べたら 2進から16進までだった。すまぬ…すまぬ…
496 ：デフォルトの名無しさん：2011/09/06(火) 22:05:30.51
絶対に許さない
497 ：デフォルトの名無しさん：2011/09/07(水) 15:04:46.62
>>473
16進数で2進を想像できないヤツがビット操作なんてするもんじゃない。
64bitフルに使うと64桁の値がソースコードに散りばめられるわけだぞ
汚すぎるし、43bit目が立ってかとか見分けるのもメンドクサイ。
498 ：デフォルトの名無しさん：2011/09/07(水) 15:44:48.06
じゃなんでアセンブラなんかは 0b とか書けるんだ
499 ：デフォルトの名無しさん：2011/09/07(水) 15:50:06.19
マクロ使えよ・・・
500 ：デフォルトの名無しさん：2011/09/07(水) 15:54:37.22
そんなゴミみたいな欲求を満たすために追加されたのがconstexprなんだろ
501 ：デフォルトの名無しさん：2011/09/07(水) 15:55:44.95
10進数見て2進数がうかぶやつは変態の名にふさわしいと思うが
16進数は0-Fのたかが16種類のビットパターン覚えてれば機械的に読めるので
変態というのはどうなんだろう

まあ俺は0,1,2,3,4,7,8,Fぐらいしかすぐ出てこないけどな！


502 ：デフォルトの名無しさん：2011/09/07(水) 16:08:06.78
>>500
は？
503 ：デフォルトの名無しさん：2011/09/07(水) 18:00:52.10
どうしても二進書きたければ自分でoperator""_bでも書けばいい
504 ：デフォルトの名無しさん：2011/09/07(水) 18:10:51.85
>>498
アセンブリ言語によるだろ。
というかCPUか。8bit,16bit CPUの時代ならまだbit単位で
書いても煩わしくはなかった。今はもう組み込み環境でもなければ
煩わしいだけ。
505 ：デフォルトの名無しさん：2011/09/07(水) 18:26:24.57
unsigned long long x = 0b000100100011010001010110011110001001101010111100110111101111;

うん、ありえん
506 ：デフォルトの名無しさん：2011/09/07(水) 18:28:00.77
アスキーアート的プログラミング。
507 ：デフォルトの名無しさん：2011/09/07(水) 19:11:45.48
>>497
では１６進数ならビット 43 が立っているかどうか、２進数より見やすくなるのか？

　　　　　　　　　　　　　　 // see manual p999 pio pin assign
　　　　　　　　　　　　　　 // .6 .5 .4 .3 .2 .1 .0
　　　　　　　　　　　　　　 //3210987654321098765432109876543210987654321098765432109876543210
unsigned long long x = 0b000100100011010001010110011110001001101010111100110111101111;
test(x);
assert(x & 1LL << 43);
508 ：デフォルトの名無しさん：2011/09/07(水) 19:12:45.84
あ、しくったｗ
まあいい、意味に関係ない
509 ：デフォルトの名無しさん：2011/09/07(水) 19:44:56.58
>>504
全部が全部 2 進で書くわけじゃなかろ
510 ：デフォルトの名無しさん：2011/09/07(水) 19:51:11.58
(＾ｐ＾) ニシンソバおいしいです
511 ：デフォルトの名無しさん：2011/09/07(水) 20:05:43.12
>>507
当然。ビットフラグなんかの操作に慣れてる者から
すればすぐ解る。16進なんて所詮1+2+4+8の
組み合わせしか無いし。
0xFFFFffffFFFFffff
16桁しかないから、8桁目を中心に左右に見ていけば、
そうそう今何桁目を見てるか考える必要もない。
512 ：デフォルトの名無しさん：2011/09/07(水) 20:41:14.64
0x0000010000000000 = 43bit目がONの状態
2進よりはまだ読みやすいわ。
513 ：デフォルトの名無しさん：2011/09/07(水) 21:43:12.85
そこまで来るとNbit目がONの時に真になるようなマクロなり用意すると思う
514 ：デフォルトの名無しさん：2011/09/07(水) 21:57:54.30
未だにリトルエンディアンが苦手。
全部ビッグエンディアン、ネットワークバイトオーダーになればいいのに
515 ：デフォルトの名無しさん：2011/09/07(水) 22:52:38.28
ビッグエンディアンは人間の都合だから嫌い
516 ：デフォルトの名無しさん：2011/09/07(水) 22:53:16.14
43ビット目かどうかとか16進数でも難しいわ

unsigned long long x = 0b0001001000_1101000101_0110011110_0010011010_1011110011_0111101111;

こう書ければすぐだが
517 ：デフォルトの名無しさん：2011/09/07(水) 23:07:41.97
それで_を挿入する桁間違えてハマるんですね？
518 ：デフォルトの名無しさん：2011/09/07(水) 23:24:35.59
素直に1u<<42って書こうぜ
519 ：デフォルトの名無しさん：2011/09/07(水) 23:26:10.77
>>516
桁の区切り方が素人みたいだ。経験の長いプログラマーらしくない。
520 ：デフォルトの名無しさん：2011/09/07(水) 23:26:31.69
>>511
8+4+2+1 な
ハッタリはばれると赤っ恥だぜｗ
521 ：デフォルトの名無しさん：2011/09/07(水) 23:31:34.54
>>518
多分そういうフラグ作成みたいな用途以外に使うんじゃね。
例えば、フラグでのポートからの信号出力なら
Output8( io_address, SIG1 | SIG3 | SIG4 );;
ってな書き方するだろうし。
522 ：デフォルトの名無しさん：2011/09/07(水) 23:32:47.83
>>520
ん？2+4+8+1でも8+4+2+1でも同じじゃね？
523 ：デフォルトの名無しさん：2011/09/07(水) 23:36:02.39
>>520
?
524 ：デフォルトの名無しさん：2011/09/07(水) 23:37:27.84
>>519
8桁で区切るのが普通だとは思うが
43をぱっと分かるようにするには
10桁ずつ区切らないとな・・・
525 ：デフォルトの名無しさん：2011/09/07(水) 23:44:56.11
バイナリエディタは2の累乗で区切られてるから、(↓)
経験が長くて10桁区切りが見やすいという人は特殊な気がする。

00000008 00 00 00 00　00 00 00 00
00000010 00 00 00 00　00 00 00 00
526 ：デフォルトの名無しさん：2011/09/08(木) 00:07:55.68
>>507
どうしても2進数使いたいならマクロでも使ったら？
次期C++と言わず明日からでも使えるよ。

32bitの例
B(001111111111,011111111111,011111111111);
8進数の1桁を1bitに見立てる。
8進数は3bit食うので、1塊で掛けない。なので3つに分割。
先頭が00になってるが、8進数で埋めると最大33bitになるため1桁潰してる。
527 ：デフォルトの名無しさん：2011/09/08(木) 00:12:48.28
16進数の1桁を1bitに見立てようぜ
B(01010101,10101010,10110101,11110010)
で 0x##a とかやればいい
528 ：デフォルトの名無しさん：2011/09/08(木) 00:15:42.64
>>524
> 43をぱっと分かるようにするには
> 10桁ずつ区切らないとな・・・

ﾜﾛﾀ
529 ：デフォルトの名無しさん：2011/09/08(木) 00:38:37.19
>>522
１６進から２進を連想するときは同じではない
0x20 は 32 であり断じて 128 ではない
530 ：デフォルトの名無しさん：2011/09/08(木) 00:46:21.23
マクロとしてコンパイル通るかどうか
やってないから知らんけど、アセンブリで
2進数使えるんなら、マクロ内でアセンブリに2進数渡してやれば？
B(11111111111111111111111111111111b);
531 ：デフォルトの名無しさん：2011/09/08(木) 00:49:00.82
>>529
意味が解らない・・・。
0x20は32以外あり得ないのは解るけど、128は何で出てきた？
128は十進数じゃない別の表記とか？
532 ：デフォルトの名無しさん：2011/09/08(木) 00:53:34.54
8+4+2+1 = F
1+2+4+8 = F
だと思うけど違いが解からん。
なおかつ>>529で余計に分からなくなった。
533 ：デフォルトの名無しさん：2011/09/08(木) 00:57:01.68
>>531 は合格（ただし可）
>>532 は落第
534 ：デフォルトの名無しさん：2011/09/08(木) 01:02:21.21
バカにも解るように教えてつかーさい。
535 ：デフォルトの名無しさん：2011/09/08(木) 01:04:15.77
>>522の 2+4+8+1 から
1000=2 0100=4 0010=8 0001=1 で
0x20=10000000b=128
という話なんだろうとエスパーした
536 ：デフォルトの名無しさん：2011/09/08(木) 01:10:03.22
>>535
なるほど、>>535の内容は解った。
しかし不思議な発想だね。
537 ：デフォルトの名無しさん：2011/09/08(木) 10:10:32.07
ワード長が伸びてきて、16進にせよ2進にせよ桁区切りができないと見づらい。
マクロ(というか constexpr 関数)でやれよっていうのは、確かにその通り
538 ：デフォルトの名無しさん：2011/09/08(木) 11:58:53.06
>>520の意味もさっぱりわからんが、
どうもバカそうな話なんでスルーするか。
539 ：デフォルトの名無しさん：2011/09/08(木) 12:11:38.52
>>520は上位ビットは左側に書くものだって言いたいんじゃないの？よくわからんけど。

そもそも、ビット演算を繰り上がりのある加算で記述ところからセンスを疑うが。
540 ：デフォルトの名無しさん：2011/09/08(木) 12:35:30.15
10進表記でABCDになる数は
A * 10^3 + B * 10^2 + C * 10^1 + D * 10^0
2進表記でABCDになる数は
A * 2^3 + B * 2^2 + C * 2^1 + D * 2^0 = A * 8 + B * 4 + C * 2 + D * 1

8, 4, 2, 1はこっから出てくるってだけの話だろ
こんなん2進数とか最初に習う段階で勉強することじゃね？
541 ：デフォルトの名無しさん：2011/09/08(木) 12:39:31.74
で？
542 ：デフォルトの名無しさん：2011/09/08(木) 12:40:36.30
レベル低いよなお前らﾌﾟｷﾞｬｰ
543 ：デフォルトの名無しさん：2011/09/08(木) 12:43:10.57
>>540
よくわかりました！
ありがとうございました！！
544 ：デフォルトの名無しさん：2011/09/08(木) 12:54:11.88
加算の交換法則すら知らないアホがいる
545 ：デフォルトの名無しさん：2011/09/08(木) 12:55:14.31
どこに？
546 ：デフォルトの名無しさん：2011/09/08(木) 12:57:04.07
加法は可換だけど、数の表記の順序は左からで固定だから

ま、1234をひとりだけ4321と書く世界に生きたいんならご自由に
そういう人はア・プリオリな言語みたいなものを使うのは不便でしょうがないだろうけど
547 ：デフォルトの名無しさん：2011/09/08(木) 12:59:09.81
>>546
1+2+4+8と8+4+2+1の話じゃなかったんか？
もしかして+記号見えない病気とか？
548 ：デフォルトの名無しさん：2011/09/08(木) 12:59:32.57
つまり、>>544はLSBやMSBのようなエンディアン概念も知らないようなアホ以下ね
549 ：デフォルトの名無しさん：2011/09/08(木) 13:00:48.40
ああ、やっぱり+記号見えてないんだね
可哀想に
550 ：デフォルトの名無しさん：2011/09/08(木) 13:01:05.38
>>547
ああ、そっちの話か
俺はそっちの話は知らん
たぶん誤解されやすい加法表記を持ち出した>>520がアホなのだろう
551 ：デフォルトの名無しさん：2011/09/08(木) 13:19:28.75
1,2,4,8の組み合わせと16進でビット計算出来ないヤツに
このスレは早すぎないか？
0xより基礎のお勉強をした方がいいと思う。
552 ：デフォルトの名無しさん：2011/09/08(木) 13:22:39.06
>>548
型変換する訳じゃないからエンディアン関係ねえ。
553 ：デフォルトの名無しさん：2011/09/08(木) 13:26:40.43
>>552
エンディアンは関係は無いが、2進表記はMSB側から・左から書くわけだから
4桁の2進表記があれば、左から8, 4, 2, 1の係数になっているのであって
逆ではないだろ
加法は可換だが、順序がどうでもいいわけではないということ

つーかお前ら本当に糞どうでもいい自転車置き場の議論が好きだな
くだらねぇ
554 ：デフォルトの名無しさん：2011/09/08(木) 14:11:04.11
1+2+4+8から順序を連想するなんて頭オカシイだろ
555 ：デフォルトの名無しさん：2011/09/08(木) 14:27:41.62
慣習とか慣用とか
556 ：デフォルトの名無しさん：2011/09/08(木) 15:48:43.36
>>554
なんかの病気だろうね。
557 ：デフォルトの名無しさん：2011/09/08(木) 18:59:53.09
1+2+4+8の順々に対して慣習なんて聞いたことねぇ。
プログラム以前に中学数学レベルの話だろ。
0x81 + 0x18 = 0x99 なんてどうすんだよ。
558 ：デフォルトの名無しさん：2011/09/08(木) 19:03:31.19
いち、じゅう、ひゃく、せん、まん
まん、せん、ひゃく、じゅう、いち
559 ：デフォルトの名無しさん：2011/09/08(木) 19:24:28.54
そろそろ C++0x の話をしようよ。
560 ：デフォルトの名無しさん：2011/09/08(木) 19:29:10.80
11
561 ：デフォルトの名無しさん：2011/09/08(木) 20:28:10.81
桁数数えるときは下から考えるだろ常考
562 ：デフォルトの名無しさん：2011/09/08(木) 20:38:50.57
次スレどうする？C++11 0x14にでもする？
そろそろどっかに11いれにゃならんだろ。
563 ：デフォルトの名無しさん：2011/09/08(木) 20:40:33.16
0b却下の時もこんな流れで1スレ潰したなぁ
進歩ないなお前ら
564 ：デフォルトの名無しさん：2011/09/08(木) 21:03:55.80
>>539
飽和論理和じゃ桁上がりしないから、
純粋に数学特性の説明だとマズイだろ。
7 | 9 = 0xF だと、正しいけど意味が解からんだろ。
565 ：デフォルトの名無しさん：2011/09/08(木) 22:02:28.71
C++0x 11 14
566 ：デフォルトの名無しさん：2011/09/08(木) 22:05:57.54
>>562
それに検索用に【C++0x】って感じで付け加えるのでどうだろう。
567 ：デフォルトの名無しさん：2011/09/08(木) 22:06:37.85
>>564
お前、頭おかしいのか？
568 ：デフォルトの名無しさん：2011/09/08(木) 22:15:55.17
ハイ
569 ：デフォルトの名無しさん：2011/09/08(木) 22:18:40.58
C++11 (C++0x) 14
570 ：デフォルトの名無しさん：2011/09/08(木) 22:19:30.58
>>568
ハイじゃないがな
571 ：デフォルトの名無しさん：2011/09/08(木) 22:33:52.47
正確に行こう
ISO/IEC 14882:2011 (C++11/C++0x) 14
572 ：デフォルトの名無しさん：2011/09/08(木) 22:35:45.42
JISはいつくるんだ。
まぁ、JIS規格になったところで、タダで仕様を見られるようになるだけだけど。
573 ：デフォルトの名無しさん：2011/09/08(木) 22:44:29.35
おまえがつくれ！
574 ：デフォルトの名無しさん：2011/09/08(木) 23:08:00.13
FDIS落としてないのー
575 ：デフォルトの名無しさん：2011/09/09(金) 03:07:31.43
C++0b 0d
でいいだろ
576 ：デフォルトの名無しさん：2011/09/09(金) 17:01:54.97
というか正式なC++の規格になったんだからC++本スレに合流でいいんじゃね
577 ：デフォルトの名無しさん：2011/09/09(金) 17:34:25.03
ここが本スレと思ってた
578 ：デフォルトの名無しさん：2011/09/09(金) 18:23:09.74
>>576
君、行っていいよ。許可する。
579 ：デフォルトの名無しさん：2011/09/09(金) 20:31:48.55
むしろ旧C++スレをC++03スレにするべきなのか
580 ：デフォルトの名無しさん：2011/09/11(日) 13:53:36.06
本スレで0xの話題しても迷惑になるだけだから
VCやGCCが正式に0xに対応するまではこのスレは維持する。
でなければ混乱を起こすだけ。
581 ：デフォルトの名無しさん：2011/09/11(日) 14:22:41.21
このスレはここと同じようなスタンスでいいんじゃないの？

【初心者お断り】ガチ規格準拠C専用スレ Part134
http://hibari.2ch.net/test/read.cgi/tech/1246115922/
582 ：デフォルトの名無しさん：2011/09/11(日) 14:34:02.77
いやもうすぐに次の規格の話始まるから。
583 ：デフォルトの名無しさん：2011/09/11(日) 15:30:08.14
それは別スレでやった方がよくね？
584 ：デフォルトの名無しさん：2011/09/11(日) 17:09:13.63
shared_ptrは使わない機能にコストを払わないというC++の基本理念におもいっきり反してると思うんですが
なんでこんな出来損ないが次期標準に選ばれたのでしょうか？
585 ：デフォルトの名無しさん：2011/09/11(日) 17:27:14.15
shared_ptrを使わなければコストなんてかからないから
別に反してない
586 ：デフォルトの名無しさん：2011/09/11(日) 17:35:20.43
だが考えてみてほしい、委員会の人的コストがかかるのではないか
ひいては限られた人類の時間資源というコストがかかるのではないか
人類が滅亡するまでに使うことができる人月は決して無限ではないのだ・・・
まあ俺はshared_ptr使うんだけど
587 ：デフォルトの名無しさん：2011/09/11(日) 17:43:02.10
vectorだって、長さ固定ならただの配列よりコストがかかるし、
stringだってただの配列に比べれば高コスト。
機能にコストが掛からないというのは言語に限った話で、
ライブラリに対しては至上命題じゃない。
588 ：デフォルトの名無しさん：2011/09/11(日) 18:22:01.59
至上命題って言葉を使うのは止めようよ。至上命令ならいいけど。
589 ：デフォルトの名無しさん：2011/09/11(日) 18:29:36.50
このスレの残りと次スレからは「次期C++標準スレTRもあるよ」ってことでいいんじゃないかな？
590 ：デフォルトの名無しさん：2011/09/11(日) 18:41:51.94
まあライブラリも可能な限りコストがかからないように気は配ってるけどね
今回は仕様まで変えて（右辺値参照を追加して）効率化計ったし
591 ：デフォルトの名無しさん：2011/09/11(日) 20:15:33.30
>>587
それは現状な
ライブラリがバイナリ提供という前提のうえでの

ライブラリのユーザにとって決して満足な解ではなく改善の余地が残っている問題だ
592 ：デフォルトの名無しさん：2011/09/11(日) 20:29:17.35
どうやって改善するの？
ファイルリンケージな、ポインター管理テーブルでも作って、
擬似スレッド(コールスタックでのガベコレイベント)によるリソース解放でもすんの？
C++の活躍の場は、組み込み環境もあるから安易にスレッドによる同時管理なんて手も使えないけど。
593 ：デフォルトの名無しさん：2011/09/11(日) 20:35:24.68
使わない機能にコストを払わないって言葉を正しく理解していない人がいるな。

shared_ptr を標準に追加したからといって、shared_ptr を使用しないプログラムが
実行時のコストを払わされることはないってことだから問題ないだろ。
594 ：デフォルトの名無しさん：2011/09/11(日) 20:54:53.56
なんでガベコレが出てくるんだよ
コンパイラが最終的にうまいアセンブラ使いと同じコードを吐くまで改善の余地はずっとあるだろ

ライブラリが気に入らなければ使わないんじゃなく
ライブラリに何を要求したかによる最小のコストであるべきものだ
それを妨げているネックがバイナリ提供だと主張した
595 ：デフォルトの名無しさん：2011/09/11(日) 20:59:20.36
>>594
だから具体的にどうできるの？
トランポリンみたいに直接機械語を変更するでもいいから、
具体的に同改善できるのか教えておくれ。
596 ：デフォルトの名無しさん：2011/09/11(日) 21:00:02.88
銀の弾丸が欲しいだけだろ
597 ：デフォルトの名無しさん：2011/09/11(日) 21:01:53.67
>>594
具体例が出せなきゃ、「妄想か。策定グループの判断が正しいな。」としか言えないよ。
598 ：デフォルトの名無しさん：2011/09/11(日) 21:05:12.01
shared_ptrを使わなければ実効バイナリにshared_ptrのコードは含まれないじゃん
要求しない分には最小コストになってるじゃん
599 ：デフォルトの名無しさん：2011/09/11(日) 21:06:02.35
それがわかってない馬鹿がいただけですよ
600 ：デフォルトの名無しさん：2011/09/11(日) 21:14:24.22
それを言うなら
shared_ptr に対する要求がサブセットであることと
shared_ptr を全く使わないことを、同じであることにしたいだけの馬鹿がいるだけだよ

これで具体的にどういうことか通じない御仁に付き合ってやりたいやつはそうしたらどうだ？　（俺はパス
601 ：デフォルトの名無しさん：2011/09/11(日) 21:14:45.83
>>598
流れと関係ないけど、リンケージって何処まで仕様が決まってんだっけ？
インタープリタやLLVMで動くから、コンパイル & リンクは仕様の範囲じゃないよね。
リンク段階なしでもあり？
602 ：デフォルトの名無しさん：2011/09/11(日) 21:16:14.04
>>600
じゃそのサブセットってのは何を要求していて、
具体的にどう機能を変えることで対応できるの？
603 ：デフォルトの名無しさん：2011/09/11(日) 21:28:51.27
>>601
shared_ptrはテンプレートだから
使わない限り実体化されないだろ
604 ：デフォルトの名無しさん：2011/09/11(日) 21:37:14.34
インタープリタでの使用は仕様じゃ考慮してないんじゃなかったっけ？
605 ：デフォルトの名無しさん：2011/09/11(日) 21:38:40.79
>>603
いや、shared_ptr関係なく純粋にリンケージの事。
使ってもない関数が結構リンクされてるのがウザイ。
仕様上あれを全部除去する余地はないのか？
一応仮想関数が無理なのは解る。
C++なんて最低限、new deleteと例外用のランタイムだけ
リンクすればいいでしょ。
606 ：デフォルトの名無しさん：2011/09/11(日) 21:42:36.60
LTCGを仕様に含めろとか馬鹿な事を
607 ：デフォルトの名無しさん：2011/09/11(日) 21:46:07.03
>593が回答だろ。
>584 >587は単なる勘違い。
608 ：デフォルトの名無しさん：2011/09/11(日) 21:53:01.92
>>606
LTCGじゃなくclangみたいな方法でもいいじゃん。
とにかく、外部に公開しないような関数は根こそぎ
消すことを義務化してほしいね。
609 ：デフォルトの名無しさん：2011/09/11(日) 21:54:52.01
>>607 誰に対する？
610 ：デフォルトの名無しさん：2011/09/11(日) 22:40:04.14
>>608
つまり関数はデフォルトで内部結合にして、
外部に出すには extern つけなさいってことか？
611 ：デフォルトの名無しさん：2011/09/11(日) 22:45:58.85
>>610
リンク時のシンボルテーブルから、参照されてない関数見つけて
その関数を領域ごとごっそり消せばいいって事でしょ。
関数の長さが解らないから、関数のマングリングに関数のバイト数を追加したりする
必要はあるだろうけど。
612 ：デフォルトの名無しさん：2011/09/11(日) 23:04:03.43
>>611
そんな具体的なところにまで規格は踏み込めないよ多分。

規格は、ここに述べることと外から見てそっくり同じ動きをするバイナリなら
どんな風に翻訳しようが構わないってものだろう。

不要な関数があろうがなかろうが外側からみた動きは変わらない。

それに、些細で不要な関数を消してもどうせアライニングの関係で
パディングしなければいけないとき、
その関数を消すのをさぼったからといって規格不適合っていうのも無理がある。
613 ：デフォルトの名無しさん：2011/09/11(日) 23:09:45.55
>>612
やっぱ規格上でその規定はむりか。

今時、crang,gcc,armcc,optimize compilerと実装は違えど
大抵のコンパイラで、できる機能なんだけどな。
それを言ったら最適化もって事ではあるけど。
614 ：デフォルトの名無しさん：2011/09/11(日) 23:36:54.72
確かに規格の死角ではあるね

考え落としではなく、触れるわけにいかない事項だが
コードサイズの増加が無害と思い込むのは狭い視野での早まった結論だ
615 ：デフォルトの名無しさん：2011/09/12(月) 01:59:20.53
vtableの仕様すら規格で決まって無いのに、お前らお花畑だな。
616 ：デフォルトの名無しさん：2011/09/12(月) 07:44:12.85
実行バイナリには不要な関数コードが10%以上混在してはならないとか
実行コードは物理的なCPUネイティブ？で実行されなくてはならないとか
１組み込み演算コードは１KB以内に収めるとか1000サイクル以内に実行できるとか
そんなん言い出すと法律家みたいな判例と解釈の専門家が必要になる気がする
617 ：デフォルトの名無しさん：2011/09/12(月) 10:01:23.91
言語規格だけが規格でもなし、ある程度の標準化求めるにも
もっと別のベンダ寄りなとこに出す話なんじゃね。言語の理念は理念としても。
618 ：デフォルトの名無しさん：2011/09/12(月) 12:39:25.86
意味を左右しない実装の自由が残ってるのは良い規格である証拠。
619 ：デフォルトの名無しさん：2011/09/12(月) 13:01:37.85
行列計算なんかオペレータ使うとアレじゃん?
このあたりはなんとかなならないの
620 ：デフォルトの名無しさん：2011/09/12(月) 13:21:21.50
アレとは
621 ：デフォルトの名無しさん：2011/09/12(月) 14:34:21.12
http://www.open-std.org/jtc1/sc22/wg21/
News 2011-09-11: The new C++ standard - C++11 - is published!
News 2011-09-11: The deadline for the next mailing is 2012-01-13
News 2011-09-11: The 2011-07 post-Bloomington mailing is available
News 2011-09-11: The C++ Standard Core Language Issues List (Revision 77) is available
622 ：デフォルトの名無しさん：2011/09/12(月) 17:06:16.48
はええな
可決されてからほぼ一ヶ月か
623 ：デフォルトの名無しさん：2011/09/12(月) 18:34:00.45
>>619
一時オブジェクトがどうこうという話なら右辺値参照で解決された
624 ：デフォルトの名無しさん：2011/09/12(月) 19:43:40.52
>>623
あれま、そうなんだ。
ポインタ含まないような構造体でも解決されてるのか。
625 ：デフォルトの名無しさん：2011/09/12(月) 20:43:17.94
>>624
行列計算程度ならね。

たとえば a+b+c+d = ((a+b)+c)+d は、
二回目以降の足し算は T operator+(T&& x, const T& y){ return x += y; }　を使えばコピーは起こらない。
(戻り値のコピーは RVO で消せる)
626 ：デフォルトの名無しさん：2011/09/12(月) 21:09:05.39
>>625
そういう問題じゃないんじゃね？
Expression Templateを使うような問題だろ。

最終的にこういう感じで展開されなきゃならんと言う話。
n[i] = a[i] + b[i] + c[i] + d[i];
627 ：デフォルトの名無しさん：2011/09/12(月) 22:25:29.82
>>626
そういうのは右辺値参照関係ない…
628 ：627：2011/09/12(月) 22:28:48.84
ああそうか、>>623 ≠ >>625 = >>627 って言っとかないと流れがよくわからないな
629 ：デフォルトの名無しさん：2011/09/14(水) 16:35:22.29
Visual Studio vNextのC++11対応に失望した
630 ：デフォルトの名無しさん：2011/09/14(水) 16:52:18.48
nested lambdaがバグるコンパイラってなんなの
631 ：デフォルトの名無しさん：2011/09/14(水) 17:05:51.91
>>629
これ？
http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx
632 ：デフォルトの名無しさん：2011/09/14(水) 17:56:12.19
C++11対応にまともに取り組んでると言えるのはGCCとIntelくらいか
633 ：デフォルトの名無しさん：2011/09/14(水) 18:34:19.54
早漏気味に対応してたBCCはどうなの
あとexportに定評のあったComeauとか
634 ：デフォルトの名無しさん：2011/09/15(木) 08:37:45.51
>>631
欲しかったものがatd::atomicぐらいしか入ってねー
635 ：デフォルトの名無しさん：2011/09/15(木) 10:50:55.83
今まで何やってたんだって感じだな
636 ：デフォルトの名無しさん：2011/09/15(木) 13:24:02.02
vc10から変わってないじゃないか
637 ：デフォルトの名無しさん：2011/09/15(木) 14:36:35.94
Visual Studioにそういうの期待する方がおかしい。
あれはMSの現フレームワークの開発環境提供が第一義。

ISO C++の部分だけベータリリースしてもいいんじゃないかとは思うが。
638 ：デフォルトの名無しさん：2011/09/15(木) 14:40:30.40
>>633
Comeauは開発停まってるでしょ。
http://www.comeaucomputing.com/43101features.html#newstuff
639 ：デフォルトの名無しさん：2011/09/15(木) 14:46:46.51
wikipediaのc++0xをc++11に転送するようにできないものか
640 ：デフォルトの名無しさん：2011/09/15(木) 15:14:15.56
してくりゃいいじゃない
641 ：デフォルトの名無しさん：2011/09/15(木) 15:23:35.10
英語版は二週間くらい前に転送されているからあれ？と思ったら、
日本語版はまだC++0xしかエントリないんだね。

ただ日本語版は、そういうことより、

> 標準化の作業はようやく完了しC++11という名称も定まったが、
> 本項は必ずしも最近の C++0x の状況を反映してはいない。

こういう奇っ怪な文章を直したらどうかねえ。
「が、」で継続するなら二行目も「C++11」の方がだろう。
C++0x命名の長い解説が最初のサマリーのところに入っていたり。

まあ日本語版見てる人が少ないんだろうけど。
642 ：デフォルトの名無しさん：2011/09/15(木) 15:31:42.48
>>641
そこまで言うなら直してくれよ
643 ：デフォルトの名無しさん：2011/09/15(木) 15:47:19.51
相変わらず高いなあ。

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50372
http://webstore.ansi.org/RecordDetail.aspx?sku=ISO%2FIEC+14882%3A2011
644 ：デフォルトの名無しさん：2011/09/15(木) 16:13:04.87
>>641
自分でやれよ
645 ：デフォルトの名無しさん：2011/09/15(木) 16:15:36.86
VisualStudi2010で動かなかった
lambda動くんじゃなかったの？

template<typename LHS, typename RHS>
[]AddingFunc(const LHS &lhs, const RHS &rhs) -> decltype(lhs+rhs) { return lhs + rhs; }
646 ：デフォルトの名無しさん：2011/09/15(木) 16:32:18.74
c++11のlambdaはmonomorphic
647 ：デフォルトの名無しさん：2011/09/15(木) 17:32:19.30
auto NamedLambda2 = [&](int a) { return a + b; };

boost::function_traits<BOOST_TYPEOF(NamedLambda2)>::result_type c=5; //bug??
boost::function_types::result_type<BOOST_TYPEOF(NamedLambda2)>::type c=5; //bug?

NamedLambda2のresult_typeってどうとればいいんだ
648 ：デフォルトの名無しさん：2011/09/15(木) 17:44:31.04
decltype(NamedLambda2(0)) c=5;
649 ：デフォルトの名無しさん：2011/09/15(木) 18:50:49.79
>>645
c++11ではそもそもlambda式のテンプレートはできないし。

// これは関数テンプレート
template<class LHS, class RHS>
auto AddingFunc(const LHS & lhs, const RHS & rhs) -> decltype(lhs + rhs) { return lhs + rhs; }

int main()
{
cout << AddingFunc(1, 2) << endl;
cout << AddingFunc(3.3, 4.4) << endl;
}
650 ：デフォルトの名無しさん：2011/09/15(木) 18:59:44.49
decltypeの中が複雑だったり、関数のスコープ内で定義された変数を含む場合ってどうするの？
651 ：デフォルトの名無しさん：2011/09/15(木) 20:25:04.36
型だけ見る
652 ：デフォルトの名無しさん：2011/09/15(木) 22:16:45.06
>>625

演算子を用いた(a+b)*(c+d)*eとかの行列計算もokでしょうか？
653 ：デフォルトの名無しさん：2011/09/15(木) 23:09:06.38
>>652
右辺値参照ををオーバーロードするライブラリを誰かが作ればOK

「テンポラリを無駄に生成したくない」という問題だけなら解決する。
( (a+b)*(c+d)*e なら c+d のテンポラリは消せないけど)
654 ：デフォルトの名無しさん：2011/09/15(木) 23:54:57.27
>>650
decltypeの中は自分で頑張って書くしかないな。
ttp://ideone.com/dgXqf
655 ：デフォルトの名無しさん：2011/09/15(木) 23:59:29.18
lambdaみたいにreturnから推論できればいいのにね
定義必須になるけど、どうせほとんどの場合テンプレートで使うんでしょ
656 ：デフォルトの名無しさん：2011/09/16(金) 00:01:23.32
そもかわりlambdaはresult_typeがないので
boostと組み合わせると大変なことに
657 ：デフォルトの名無しさん：2011/09/16(金) 00:02:18.79
なんでそんな事に・・・
658 ：デフォルトの名無しさん：2011/09/16(金) 00:05:01.11
もう拡張だけで頑張るのは無理な次期にきてるんじゃないかな
659 ：デフォルトの名無しさん：2011/09/16(金) 00:27:44.72
std::function<int()> a;
std::function<int()>::result_type b;　　← OK
decltype(a)::result_type c;　　　　　　 ← Error!　　expected initializer before ‘c’

これはGCCのバグというか、まだ実装途中ってことなんだよね？
660 ：デフォルトの名無しさん：2011/09/16(金) 01:04:02.42
ファンクタの状態や()のオーバーロードいらないなら素直にlambda使えって話
int main()
{
int x = 11;
double y = 22.22;
vector<int> v1 = { 0, 1, 5, 10, 100 };

vector<decltype(x + y + v1[0])> v2;
transform(v1.begin(), v1.end(), back_inserter(v2),
[x, y](decltype(v1[0]) i) -> decltype(x + y + i) { return x + y + i; } );
for(auto i = v2.begin(), e = v2.end(); i != e; ++i) { cout << *i << endl; }
}
661 ：hiding：2011/09/16(金) 02:41:50.22
>>659
decltypeをnested name spacifierとして使えるようになったのはごく最近のこと。
土壇場のギリギリになってから規格に入った。
だからgccはまだ対応してない。
662 ：デフォルトの名無しさん：2011/09/16(金) 12:19:02.49
http://www.suri.cs.okayama-u.ac.jp/servlets/APPLICATION.rkt

schemeからc++0xの自動生成
663 ：デフォルトの名無しさん：2011/09/16(金) 12:41:10.61
こんな短いコードで変換できちゃうの？
664 ：デフォルトの名無しさん：2011/09/16(金) 13:00:36.22
declarationを人間が入力することで型推定を人間がやってるから短くなる
665 ：デフォルトの名無しさん：2011/09/16(金) 15:51:58.41
>>664
gambit-c
http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Main_Page
も凄いとおもったが、>>662はそれ以上だな。
666 ：デフォルトの名無しさん：2011/09/16(金) 16:16:28.24
なんだかなぁ。右辺値参照とか、decltypeとかconstexprとか
複雑さをもたらすだけだな。autoは便利だが。

overrideには笑った。virtual関数使う奴が引数を間違えるかねぇ。
finalはあっていいけど。

いろいろ機能拡張してるけど、それはSTLなどのライブラリ作る職人さん
達が使うものとして、新しい機能にあれこれ手を出すのはやめた。

使いたいのはスレッドとスマートポインタ、unourdered set、map
ぐらいでいい。
667 ：デフォルトの名無しさん：2011/09/16(金) 16:48:37.04
つ チラ裏
668 ：デフォルトの名無しさん：2011/09/16(金) 17:06:20.97
はいはい
669 ：デフォルトの名無しさん：2011/09/16(金) 21:10:58.59
>>666
overrideつけたのはベースのクラスで引数変えて、派生クラスで
引数変え忘れとかのケアレスミス防止だろ、
今のコンパイラでも警告出たかどうか知らないけど。
他人のコード引き継いだりしたときはミスしそうなとこだろ。

こういった機能やスレッドにしても0xはいまさら感なところも多いね
個人的にはC++はめんどいイメージが最近は大きくなってるから
ある程度、楽に使えるようになってきているのはいいんじゃないかな
non copyable は delete 指定でできるみたいだけど
コーディング量的に微妙か?w

以上、チラ裏
670 ：デフォルトの名無しさん：2011/09/16(金) 21:47:17.03
overrideないとエラーになるならいいんだけどねえ
671 ：デフォルトの名無しさん：2011/09/16(金) 21:56:11.59
>>444
672 ：デフォルトの名無しさん：2011/09/16(金) 22:07:01.41
C++0xをシェイプアップして
キモいメタプログラミングを構造化言語で記述する仕様を付けて出せば最強言語
673 ：デフォルトの名無しさん：2011/09/16(金) 23:31:47.94
>>672

賛成。テンプレートやメタプログラミングも過渡期の段階だろう。
もっと簡潔にしなければならないよね。ま、大変な作業だろうけど。

しかし、最近のビヤーネさん、禿に磨きがかかっているねえ。
C++11の複雑さも磨きがかかってるけど。

科学、工学、他分野の技術系の人にとっては、計算やアルゴリズム
が大事だから、文法が簡単な言語を使う(最近は工学関係もMATLABや
Octaveが浸透してきた)。どうしてもスピードが要求されるところ
にはFORTRANを使う。C++はあまりにも言語が自己主張しすぎる。
複雑なC++の習得に時間をかけるのは本末転倒。
674 ：デフォルトの名無しさん：2011/09/16(金) 23:41:48.01
>>672の発想で作られたD言語という失敗作があってな
675 ：デフォルトの名無しさん：2011/09/16(金) 23:46:03.91
>>673
> どうしてもスピードが要求されるところ
> にはFORTRANを使う。
C++には満足な並列構文がないじゃん
676 ：デフォルトの名無しさん：2011/09/16(金) 23:51:14.57
やっとスレッドの概念が規格化された言語に並列構文とか無茶言うな
677 ：デフォルトの名無しさん：2011/09/17(土) 01:53:27.72
D言語は仕様が固まれば・・・
678 ：デフォルトの名無しさん：2011/09/17(土) 11:33:40.70
Dは失敗したけどそのうち取って代わる言語が現れて
C++の仕事は過去の遺物の保守と移植だけみたいな状況が来るよ
ジョンタイターと飲みに行ったときに彼ももそう言ってた
679 ：デフォルトの名無しさん：2011/09/17(土) 11:58:06.53
Vita にもいよいよ C# 来たしなあ。
どの程度なのか知らんが。
680 ：デフォルトの名無しさん：2011/09/17(土) 12:15:22.92
10年以上前から言われてる気がする
681 ：デフォルトの名無しさん：2011/09/17(土) 13:28:52.06
>>679
XBLIGでC#使えるのと同じぐらいのインパクトしか無いんじゃないかな。
682 ：デフォルトの名無しさん：2011/09/17(土) 15:14:57.91
360でC#使えるけど、C#っぽい楽な書き方してるとGC走りまくって使い物にならなかった。
GCが問題無いくらいVITAが速いならいいけど。
683 ：デフォルトの名無しさん：2011/09/17(土) 16:00:17.69
ドイツ語ってすごい文法も奇麗だし
読みがそのままスペルでいいよね

でも現実にはいろんな言語のいいとこパクったり
ぐちゃぐちゃな拡張してきた英語が広く使われている

仮にドイツ語が広く使われたとしても
結局ぐちゃぐちゃな拡張される事になると思う
684 ：デフォルトの名無しさん：2011/09/17(土) 16:04:05.68
ドイツ語の読み書きが出来る人？　それとも聞きかじっただけ？
685 ：デフォルトの名無しさん：2011/09/17(土) 16:06:45.65
>>683
Wikipedia一回見れ　恥ずかしすぎるお前
686 ：デフォルトの名無しさん：2011/09/17(土) 16:16:54.15
リンカエラーやデバッガの出力で壮絶なmangled nameを見ると
ドイツ語の複合語が連想される、まで読んだ
687 ：デフォルトの名無しさん：2011/09/17(土) 16:34:35.95
demangle して読まないの?
688 ：デフォルトの名無しさん：2011/09/17(土) 19:28:58.02
あれ？C#ってGCコントロールできるんじゃなかったっけ？
689 ：デフォルトの名無しさん：2011/09/17(土) 19:39:29.77
日本語読めないヒト科？
690 ：デフォルトの名無しさん：2011/09/17(土) 20:12:10.18
>>688
処理系による。Windowsの.netなら発生頻度はある程度コントロール出来る。
360とかWPは無理。Monoは知らない。
691 ：デフォルトの名無しさん：2011/09/17(土) 22:06:10.73
.net by auェ・・・
692 ：デフォルトの名無しさん：2011/09/17(土) 22:26:27.73
そういえば、ラベル付きbreak/continueは常々ほしいと思ってたんだけど、
C++11から敢えて外した理由ってあるの？
それともほとんどの人は多重ループからの脱出とかしないの？
693 ：デフォルトの名無しさん：2011/09/17(土) 22:28:49.06
>>692
そんなの作ったら巨大な関数が今よりもっと増えそうな気がしていいやだな。
関数作って return を使うプレッシャーがあるぐらいでちょうどいいんじゃないかと思う。
694 ：デフォルトの名無しさん：2011/09/17(土) 22:28:49.60
switch (a) {
case 0:
...
break;
case 1:
...
goto 0;//とか出来たらいいなあ
}
695 ：デフォルトの名無しさん：2011/09/17(土) 22:47:27.00
C#やDではgoto caseがあるっけ
696 ：デフォルトの名無しさん：2011/09/17(土) 22:59:05.59
……C#使い始めて結構経つけど今初めて知ったよ。
697 ：デフォルトの名無しさん：2011/09/17(土) 23:03:30.99
auto DoubleLoop = [&]
{
　for(...){
　　for(...){
　　　if(...) return;
　　}
　}
};

DoubleLoop();
698 ：デフォルトの名無しさん：2011/09/17(土) 23:23:10.00
>>693
結局goto使うか、エラーでもないのに例外使うか、
それとも>>697みたいな黒魔法に走るか（俺なら変数宣言もしないけど）するだろうから、
それならラベル付きループの方がいくらかマシじゃないかなあ

それに、どうせループの中でスコープ切れてるから、
ループによる関数の巨大化の弊害はそんなにない気はする
699 ：デフォルトの名無しさん：2011/09/17(土) 23:44:40.97
>>683-685
ヒント：銀英伝
700 ：デフォルトの名無しさん：2011/09/18(日) 00:54:15.19
>>692
必要ないです。
上手く構造化出来なければ、普通にgotoです。
701 ：デフォルトの名無しさん：2011/09/18(日) 01:19:46.51
whileとか必要ないです
普通にgotoです

と同レベルだぞそれ
702 ：デフォルトの名無しさん：2011/09/18(日) 01:32:30.69
いいえ全然違います。
703 ：デフォルトの名無しさん：2011/09/18(日) 01:52:16.23
同レベルだよ
gotoじゃ意味を言語的に記述出来ない
704 ：デフォルトの名無しさん：2011/09/18(日) 01:54:23.96
[&]{
　for(...){
　　for(...){
　　　if(...) return;
　　}
　}
}();

そんなに黒っぽくないような気がする
705 ：デフォルトの名無しさん：2011/09/18(日) 02:49:50.93
本当にreturnしたい時どうするんですｶｰ
706 ：デフォルトの名無しさん：2011/09/18(日) 04:43:56.57
>>704
はやくllvm clangでも動いて欲しい
707 ：デフォルトの名無しさん：2011/09/18(日) 04:47:03.93
生成される機械語を考えたらgoto一択と思いたいんだが、LLVMなら>>704も最適化されるんだろうか？
708 ：デフォルトの名無しさん：2011/09/18(日) 04:58:12.52
clangはクソblocksさんが普及するまでラムダさん実装ボイコットじゃねーの
709 ：デフォルトの名無しさん：2011/09/18(日) 06:40:34.78
即使用のラムダさんは
最適化でinline化するのがベストではあるが
710 ：デフォルトの名無しさん：2011/09/18(日) 10:13:31.20
最適化するために(mutableをつけない限り)全メンバが const なんだと思う
711 ：デフォルトの名無しさん：2011/09/18(日) 10:16:08.32
最適化にconstって関係あるの？
712 ：デフォルトの名無しさん：2011/09/18(日) 10:21:09.32
ないな。
変更されてるかどうかなんてコンパイラが勝手に解析すればいいし、constなんてキャストで外せるんだから信用しちゃだめだ。
713 ：デフォルトの名無しさん：2011/09/18(日) 11:35:31.71
const値は定数に置換される事が仕様で決まってる。
714 ：デフォルトの名無しさん：2011/09/18(日) 11:46:52.30
アホー知恵遅れに>>713みたいに定数値で初期化されることが抜けている奴がなにか喚いてたな
715 ：デフォルトの名無しさん：2011/09/18(日) 12:15:43.12
>>713
規格中のどこの規定のことを言っているのかね？
716 ：デフォルトの名無しさん：2011/09/18(日) 12:30:36.76
goto hell; //hell へ行く。で、何がしたいのか？
while(hell) //hell の間繰り返す。で、何がしたいのか？

どちらも「意味を言語的に記述」はしていて、意図を記述していない
これで while をえこひいきする客観的な理由は何だ？ Dijkstra の教えがどうたらじゃなく
717 ：デフォルトの名無しさん：2011/09/18(日) 12:33:45.89
どうでもいいことに必死だな。
マルチスレッド対応のほうが大事だろ。
718 ：デフォルトの名無しさん：2011/09/18(日) 12:34:54.13
>>716
すれ違い
719 ：デフォルトの名無しさん：2011/09/18(日) 12:41:24.47
聞かれたら困る、まで読んだｗ
720 ：デフォルトの名無しさん：2011/09/18(日) 12:46:08.16
煽るのは適切なスレでやってね
721 ：デフォルトの名無しさん：2011/09/18(日) 17:53:23.59
>>716
C++的にはgotoだと上方向に飛べるからコンストラクタやtryをまたがれると云々とか。
722 ：デフォルトの名無しさん：2011/09/18(日) 17:57:42.38
>>716
アホはお帰り下さい
723 ：デフォルトの名無しさん：2011/09/18(日) 18:14:41.35
>>716
gotoは制御のネストを破壊する。
break,retrun,continueに於いてはネストを
下げるだけの操作だからgotoとは別。

このスレで、スレ違い、さらには初心者レベルなネタをだすな。
724 ：デフォルトの名無しさん：2011/09/18(日) 19:24:31.94
今時、gotoアレルギーの人が多いんでびっくりした。
725 ：デフォルトの名無しさん：2011/09/18(日) 19:26:55.56
ステートマシンとかに使えて便利なのにな
726 ：デフォルトの名無しさん：2011/09/18(日) 19:27:55.45
ステートマシンぐらいオブジェクトで組めよ。
そっちの方が楽だろ。
727 ：デフォルトの名無しさん：2011/09/18(日) 19:47:31.29
>>721
コンストラクタや try をまたぐ問題は上方向か下方向かには関係ないと思うぞ

>>723
破壊というと何か不都合なことが起きるとでも言いたげだが具体的にどういうことだ？
なあ熟練者さん、continue は「下げる」のか？

# goto や多重継承についてドライに何か尋ねると高圧的になる人を魚っ血中
# これから出かけるところで帰りは明朝　（疲れる用事なので寝てるかも）
728 ：デフォルトの名無しさん：2011/09/18(日) 19:51:04.36
continueは、ネストの範囲を狭める。
どっちかといえば新しいネストを作り出してる方だな。
729 ：デフォルトの名無しさん：2011/09/18(日) 19:52:31.86
匿名掲示板でそーゆーこと書いちゃうのは後釣り宣言と変わらんぞ
730 ：デフォルトの名無しさん：2011/09/18(日) 19:54:27.44
横レスだけども、
gotoはコードの原則を変えてしまうので問題なんだろう。
つまり、下に流れるということ。

俺は、下に流れるgotoは許容してるな。
あんまり使う機会もないけども。
731 ：デフォルトの名無しさん：2011/09/18(日) 19:54:35.35
>>727
くだらねぇ事相手にしたくないけど。
再利用が効くからってこんなコード書かれたらどう思うんだよ。
label2:
if(・・・)
{
    ・・・・
label1:
    ・・・・
     goto label2;
}
else
{
    ・・・・
    goto label1;
}
732 ：デフォルトの名無しさん：2011/09/18(日) 19:58:37.69
>>730
俺も迂闊に上とか言っちゃったんで>>727で実につまらん反論されたけどさ(元々の意図と異なるので相手にしないけど)
迂闊に下とか言っちゃうと↓みたいな揚げ足取りがきっと来るぞ

goto L;
t obj; //コンストラクタが動く
L:
733 ：デフォルトの名無しさん：2011/09/18(日) 20:03:08.74
>>732
そういうのは趣味でやってるうちに、頭の中で最適化されて消えてくモノだと思うんだけどねぇ。
来たら来たで、なんでそうなった？？って聞くだろうし。
734 ：デフォルトの名無しさん：2011/09/18(日) 20:08:47.30
>>731
書いたその日はいいかもしれんが、手直しが必要になったら関数の中まるごと消すわ
735 ：デフォルトの名無しさん：2011/09/18(日) 20:33:07.86
議論が変な方向に行ってるな
gotoによる多段break/continueと
ラベル付きbreak/continueの違いは
gotoという構文を見ただけでは
それがbreakなのかcontinueなのか
それとも他の処理なのか分からないということだけが問題
他の問題は些末な事だよ

ラベルを工夫すれば人間に分かるようになるが、あくまで苦肉の策
最初はbreakのつもりだったけどやっぱcontinueに変えたわ、とかで
ラベル変更しないアホも出る可能性のある不確実なもので、
どう見てもcontinueなのにラベル名がBREAKになってるとかもあり得る諸刃の剣

あくまで多段break/continueの構文がないし
goto以外のworkaroundはどれもgotoより醜悪だから
仕方がなくgotoを使ってるだけで、
構文があった方がいいのは間違いない
736 ：デフォルトの名無しさん：2011/09/18(日) 20:33:17.24
バカがバカなことできるってのが問題なんだろな
737 ：デフォルトの名無しさん：2011/09/18(日) 20:42:26.12
研究畑の人間がいじる可能性のあるコードは特に危険
プログラムとか適当でも理論を実証できればそれで良いと思ってるから
可読性とか安全性とかほとんど気にしない（というか興味も知識もない）ので
ラベル名変えないとか普通にあり得る

ラベル付きbreak/continueはC++1xではどうなるんだろう
738 ：デフォルトの名無しさん：2011/09/18(日) 20:48:51.45
gotoはbreakと同じだと思ってるヤツは、
gotoは2重forから2重forのど真ん中に
飛び込んだり出来ることをよく覚えとけよ。
739 ：デフォルトの名無しさん：2011/09/18(日) 20:50:20.40
ラベル付きより番号指定のほうがよくね。
名前考えるのメンドイわ。

break 1;//一段抜ける
break 2;//二段抜ける
break 3;//三弾抜ける
740 ：デフォルトの名無しさん：2011/09/18(日) 20:52:05.14
>>739
それ良いね。
741 ：デフォルトの名無しさん：2011/09/18(日) 21:18:21.12
こんな感じの解決案
#define do_bbreak(a) {typedef int illb#a;
#define bbreak(a) {typedef illb##a dmy;goto l##a;}
#define close_bbreak(a) {typedef illb##a dmy}l##a:;}
#define do_bcontinue(a) c##a:{typedef int illc##a;
#define bcontinue(a) {typedef illc##a dmy;goto c##a;}
#define close_bcontinue(a) {typedef illc##a dmy;}}

do_bbreak(a){
　do_bcontinue(a){
　　if () bbreak(a);
　　if () bcontinue(a)
　}close_bcontinue(a)
}close_bbreak(a)
742 ：デフォルトの名無しさん：2011/09/18(日) 21:19:51.42
>>739
ネスト増やした途端バグになる
743 ：デフォルトの名無しさん：2011/09/18(日) 21:21:05.26
>>741
醜悪すぎる・・・
744 ：デフォルトの名無しさん：2011/09/18(日) 21:22:00.50
多重ループ脱出以外でのgotoの使いどころを教えてくれ
745 ：デフォルトの名無しさん：2011/09/18(日) 21:22:19.30
>>742
そんな迂闊に for や while 書く奴なら、何やってもバグるだろう。
746 ：デフォルトの名無しさん：2011/09/18(日) 21:22:58.72
>>731
土人と一緒に仕事するのをやめろ。
747 ：デフォルトの名無しさん：2011/09/18(日) 21:24:27.96
>>742
ラベルでも方向は違えど同じだろ。
748 ：デフォルトの名無しさん：2011/09/18(日) 21:26:51.88
>>739
これカウントが逆のほうが良くないか？

break 0;//一番外を抜ける
break 1;//二段目を抜ける
749 ：デフォルトの名無しさん：2011/09/18(日) 21:27:42.02
>>744
よく見るのは関数終了前のエラー処理に飛ぶタイプ。
finally節的な使い方。カーネルのソースでもしょっちゅう見る。
750 ：デフォルトの名無しさん：2011/09/18(日) 21:28:09.18
>>745
マジックナンバー書く時点でｵﾜｯﾄﾙ
751 ：デフォルトの名無しさん：2011/09/18(日) 21:28:11.31
PL/1がカウンタ方式じゃなかったかな。
752 ：デフォルトの名無しさん：2011/09/18(日) 21:28:52.22
なんかいっしょのプロジェクトやりたくない奴ばっかだな
753 ：デフォルトの名無しさん：2011/09/18(日) 21:28:55.11
デストラクタちゃんとしてれば要らんよな。
754 ：デフォルトの名無しさん：2011/09/18(日) 21:30:20.98
>>750
> マジックナンバー

え？
755 ：デフォルトの名無しさん：2011/09/18(日) 21:30:44.07
>>750
数値をマジックで書いたら全部アウトかよ。
break 0;を見てなんと間違えたり、
どの値と同期とったりするんだ？
756 ：デフォルトの名無しさん：2011/09/18(日) 21:35:28.30
>>739
むかしのBASIC的な牧歌的感性
757 ：デフォルトの名無しさん：2011/09/18(日) 21:37:15.44
まぁ配列の添字も即値だし、switch caseも即値だし、
名前付けたら他の構文と同じく定数定義したらええんちゃうん。

const int FUNCTION_SCOPE = 0;
const int LOOP_SCOPE = 1;
const int LOOP_THE_LOOP_SCOPE = 2;
758 ：デフォルトの名無しさん：2011/09/18(日) 21:37:32.71
>>755
だから実際のネスト数と同期とるんだろ
759 ：デフォルトの名無しさん：2011/09/18(日) 21:40:09.55
>>748の方式だったら大して困らんだろ？
なんかあるの？
760 ：デフォルトの名無しさん：2011/09/18(日) 21:42:28.97
>>759
ネスト増やしたらコードの意味が変わっちゃうし
そもそもコードが見ただけで何を意図してるのか分からん
それを定数変数やマクロで置き換えた所で修正も面倒
gotoの方がよほど保守しやすい
761 ：デフォルトの名無しさん：2011/09/18(日) 21:42:47.90
>>749
あれ何らかの理由で例外飛ばせないケースでは自然だよなあ
762 ：デフォルトの名無しさん：2011/09/18(日) 21:42:52.26
>>757
きちがい
763 ：デフォルトの名無しさん：2011/09/18(日) 21:46:32.79
>>760
ネスト増やしたらコード変わるの当たり前じゃん。
break n;と定義されてて、ループ抜ける以外の意図って何感じるの？
gotoの方がループ変わるたびにラベル管理しなきゃならなくてよっぽど保守しづらいけど。
764 ：デフォルトの名無しさん：2011/09/18(日) 21:47:46.24
>>762
だろ。ループ抜ける以外の意味しか無いのにgotoでラベルつけんのも頭おかしい。
765 ：デフォルトの名無しさん：2011/09/18(日) 21:49:10.55
>>764
おまえがだよ
766 ：デフォルトの名無しさん：2011/09/18(日) 21:49:31.78
>>739
それはやめてほしい。
今でも if 文の閉じ括弧とループ文の閉じ括弧が混じってると
break でどこに飛ぶのかわかりにくい。

それが何段も抜けるとかもう意味不明
767 ：デフォルトの名無しさん：2011/09/18(日) 21:56:36.43
今時クソカスコボラーが新規にC業界に殴りこんでくるわけでもなし
事実上goto=脱出と思っておいていいと思うんだが
768 ：デフォルトの名無しさん：2011/09/18(日) 21:57:52.47
一応聞いておくけど構造化定理くらいは知ってるよね？
769 ：デフォルトの名無しさん：2011/09/18(日) 21:58:25.62
>>716
まず質問の意図を確認しておきたいんだが、
1. お前らなんでwhile使うの？ifとgotoで同じことできるじゃん
2. お前らgoto不要論についてどう思ってんの？

>>716は1のように見える(明らかにwhileとgoto比較してるし)が、普通知りたいのは2だよな。どっちなんだ？
770 ：デフォルトの名無しさん：2011/09/18(日) 22:00:51.55
>>768
forの中からforのど真ん中に飛び込んだり
ifの中からforに飛び込んだり
forからifに飛び込まんでもプログラムは書けるから
すんなよって話だろ。
771 ：デフォルトの名無しさん：2011/09/18(日) 22:02:14.61
>>766
お前に break を扱うことは無理ってことだな。
772 ：デフォルトの名無しさん：2011/09/18(日) 22:02:59.17
>>766
構文としては既にgotoあるんだから
増えても変わらんだろ。使わなきゃいいし
権力あるならコーディングルールでしばりゃいい。
773 ：デフォルトの名無しさん：2011/09/18(日) 22:06:18.33
そんなもんより本物のfinallyをだな。デストラクタよりこっちがプリミティブなんだから……
774 ：デフォルトの名無しさん：2011/09/18(日) 22:08:13.81
どうでもいい
775 ：デフォルトの名無しさん：2011/09/18(日) 22:08:46.16
>>772
if の括弧なのか ループの括弧なのか考慮しながら、
「1, 2, 3,.. 4 ここに飛ぶのかー」
みたいなのは疲れるよ。break ラベル; のがずっといい
776 ：デフォルトの名無しさん：2011/09/18(日) 22:09:16.08
>>768
goto使わない限りコードのコピーをしなければならない
プログラムフロー構造があるのはご存知ですか?
777 ：デフォルトの名無しさん：2011/09/18(日) 22:09:19.37
finallyなんか何に使うんだ？
具体的な用途がさっぱり解からん。
778 ：デフォルトの名無しさん：2011/09/18(日) 22:11:01.61
なにやら break N を使わないといけないという強迫観念患者が混ざってるぞ。
779 ：デフォルトの名無しさん：2011/09/18(日) 22:11:33.70
>>775
whileとforの数を数えればいいだけだと思うが？
まさか4重ネストとか常用してんの？ループなんてせいぜい3が限度だろ。
780 ：デフォルトの名無しさん：2011/09/18(日) 22:14:07.30
>>777
>>749

catch(...){ ... throw; }なんてのは割りとよく見かけるんだからfinallyが使えたほうがずっと素直。
unique_ptrのカスタムデリータにラムダ渡してそこで……なんてやるより直接書けたほうがいいだろ？
781 ：デフォルトの名無しさん：2011/09/18(日) 22:14:43.94
>>779
775 にかかれば五重六重ネストなんて日常茶飯事だよ。

……こいつに C は無理だ。
782 ：SCHEME餃子 ◆8X2XSCHEME ：2011/09/18(日) 22:16:12.97
おまいらマクロの存在を忘れてないか？
見掛け上のネストの数と合わないかもしれないぞ。
783 ：デフォルトの名無しさん：2011/09/18(日) 22:18:07.35
マクロで暗黙のループが発生するってどんなクソコードだよ。
784 ：デフォルトの名無しさん：2011/09/18(日) 22:18:11.92
マクロの中で特別注意することも出来ない奴は死んで良いよ
785 ：デフォルトの名無しさん：2011/09/18(日) 22:19:15.84
>>779
ゴミプログラマの書いたコードを誰も読まなくていいなら goto は問題にならない

多重ループ使いまくって break continue 多用するバカは
そのループ自身も長いし入り組んでるんだよ。break で飛ぶ先がずーっと下にある。

多重に抜けるってことは、単純な break よりもずっとかけ離れた場所に飛ぶってことだろ。
それを数かぞえながら追うとか悪夢でしかない。
素直に検索で飛べるラベルがいい。
786 ：デフォルトの名無しさん：2011/09/18(日) 22:20:34.26
>>780
>catch(...){ ... throw; }なんてのは割りとよく見かけるんだからfinallyが使えたほうがずっと素直。
意味が解からん。catch(...){ ... throw; }なんてfinallyと用途が全然違うでしょ。
正常系じゃfinallyと違って動かない。
787 ：SCHEME餃子 ◆8X2XSCHEME ：2011/09/18(日) 22:20:43.80
>>784
書いた奴が死んでもコードは残るんだよ。
788 ：デフォルトの名無しさん：2011/09/18(日) 22:24:19.47
>>785
だからラベルが欲しいなら定数使えばいいでしょ。
caseだって同じじゃん。あと、バカが居るなら仕事でしょ
レビューで止めればいい。過去に使われて直せないならgotoだって同じ話。
てか、長いループだろうがbreak n;で検索なんていらんだろ。
labelなら要るだろうけど。
789 ：デフォルトの名無しさん：2011/09/18(日) 22:37:14.24
>>788
定数にしてもどの行に飛ぶかわからんだろうよ。

それにプログラムを読まなくちゃいけないのは、専業プログラマだけじゃない。
科学系研究者の書いたコードなんて現状クソ以外の何物でもない。
しかも有名な奴ほど腐ってるんだ。あれをさらに腐敗させるようなのは導入してほしくない。
790 ：デフォルトの名無しさん：2011/09/18(日) 22:39:50.43
>>786
catch(...){ throw; } がある場合、gotoによるfinally処理は記述が難しいんじゃないの？　ってことだと思うよ
もし、「超簡単だよ！」って思ったらcodepadで書いて見せてほしい

たぶん、
>unique_ptrのカスタムデリータにラムダ渡してそこで
これより簡単になることはないと思う
791 ：デフォルトの名無しさん：2011/09/18(日) 22:40:37.70
>>786
その前後で例外が発生してない時も同じ後始末をしてるコードを見たことがないのか？

それに例外が発生してるときに限定したって、catchするとランタイムが例外オブジェクトを捕まえないといけないので
結構裏で処理が走ってるし、C++の例外の形になってないunwind操作がもしあったらすり抜けてしまう。
bool flag = true;
try{
　例外が起きるかも
　flag = false;
}finally{
　if(flag) 後始末
}
のほうが、実は軽いし補足できる範囲も広いんだよ。
792 ：デフォルトの名無しさん：2011/09/18(日) 22:43:58.07
C使ってた頃ならまだしも、C++使い始めてから、クラススコープ以外でリソース生成した事ないわ。
793 ：デフォルトの名無しさん：2011/09/18(日) 22:45:36.19
>>789
だからgotoと同じだって
理論的じゃないなぁ。
794 ：デフォルトの名無しさん：2011/09/18(日) 22:47:31.93
>>789
例外構文も使えそうに無いな。てか絶対使うな。取りこぼしそうだから。
795 ：デフォルトの名無しさん：2011/09/18(日) 22:50:41.93
インデントはループに限らないんだから、ループかどうか見るために上を見て、
次に飛び先を確かめるために下を見ないといけないってのはあるなあ。
break nだとそれがn回か。

よしループの最後にEND WHILEって明記しようぜ。それならbreak nも有りな気がしてきた。
796 ：デフォルトの名無しさん：2011/09/18(日) 22:50:47.67
>>791
その処理具体的に何するの？
ディスクリプタのクローズ？
メモリーの解放？
ロックの解除？
797 ：デフォルトの名無しさん：2011/09/18(日) 22:54:06.64
>>793
同じじゃない。goto は飛ぶ先が必ずラベルだから、検索すれば思考せずに見つけることができる。
多重 break で飛ぶ先に数字を使うなら、
今の上のループの、上のループがどれで、どこで終わっているのか探す手間がかかる。

for(){ for(){ if(){ break 2; } } } みたいな一目瞭然の場合だけを考えているなら別だが。

>>794
実際使えてないアホばかり
798 ：デフォルトの名無しさん：2011/09/18(日) 22:54:49.05
>>795
ifブロック1つが100行、forブロック1つが200行。
そりゃ大変だね。もうループの条件判定だけで
抜けるようにしたほうがいいんじゃない？
799 ：デフォルトの名無しさん：2011/09/18(日) 22:55:36.53
>>797
だから番号逆に書いたらって。
800 ：デフォルトの名無しさん：2011/09/18(日) 22:57:50.85
>>>792
finallyだって頻繁に使いたくなるというわけでもない。そうやって組んでる中でごくたまに使いたくなるだけなんだよ
そのごくたまに使いたくなる時のみでさえ、
>unique_ptrのカスタムデリータにラムダ渡してそこで
みたいなfinally節の代替物が関数の先頭に来るやり方になにかもやもやしたものを感じるのでfinallyがほしいなぁと思うことがあるだけ

>>796
>>791じゃないけど俺は忘れた。少なくともここ5年はほしいと思ったことすらない
801 ：デフォルトの名無しさん：2011/09/18(日) 22:58:17.99
どうせbreak番号導入されたら統合開発環境に、ネスト数補正とか追加されるから気にすんなって
802 ：デフォルトの名無しさん：2011/09/18(日) 23:00:38.53
いやね、ロケットの軌道計算とか、制御とかには例外処理は必要だろうよ。
ヘタすると宇宙のかなたにとんでいくし。

ロボットの制御には逆運動学計算が必要だし、それに基づいて制御する
ときにも例外処理は必要。突然暴走して人間を殴る殺人ロボットになる
かもしれないし。

当然、ATMシステムに例外処理がないと(COBOLシステムにそれに類した
対策はあるよね？)とんでもないことになるし。

しかし、ただの数値計算に例外処理を導入しても、根本的にアルゴリズム
というか、プログラムにエラーがあるわけで、例外処理で正常な計算に戻
せるわけがない。プログラムを見直して、初期値やデータを与えて計算を
やり直すしかない。

だから、分野によってはそれがないと致命的かもしれんが、普通の数値計算
では例外処理なんてどうでもいい。C++の掲示板とかBlogには大事だと書かれ
ているが、それは分野による。騙されるなｗ
803 ：デフォルトの名無しさん：2011/09/18(日) 23:04:56.65
>>802
横レスするが、ロケットとか人工衛星って、電磁波の磁界通過の関係で
高性能CPUはつまんから例外処理とかもタブーよ。
とりあえず待機系を20個とかバカみたいに動かして、
異常が起きたら片っ端からリセット。
804 ：デフォルトの名無しさん：2011/09/18(日) 23:07:16.76
>>796
そりゃほとんどは確保と解放が対応付いてるよ。そういうのはクラスにすればいい。
>>800も言ってるけど、超稀に対応が取れないレアケースがある。
そういうときにunique_ptrとか持ち出すのもなんだかなーってだけ。

あとまあどうせ1箇所でしか使わないのにいちいちクラス化するのもめんどくせーとか。
805 ：デフォルトの名無しさん：2011/09/18(日) 23:08:00.96
>>803
こないだ小惑星から帰ってきた人工衛星もそんな感じだったよね。
回路つぎ変えて対応とかさ。
806 ：デフォルトの名無しさん：2011/09/18(日) 23:11:26.24
>>804
やったねたえちゃん。ラムダで済むね。
807 ：デフォルトの名無しさん：2011/09/18(日) 23:12:38.96
>>802
コンストラクターと演算子でどうやってエラー返す気だろ。
808 ：デフォルトの名無しさん：2011/09/18(日) 23:18:45.51
>>806
まあunique_ptr+ラムダで済むから、ローカルクラス作って云々やるよりは遥かにマシになったのは事実なんだよなあ。
既にcatch(...)を書いてる人たちもこれに置き換え……てくれる見込みは全くないけどさ。
809 ：デフォルトの名無しさん：2011/09/18(日) 23:32:47.82
shared_ptrって実際どういう用途に使われるんだろ。
Factoryクラスとかに使われるんだろうか憂鬱だ。
newしたクラス以外は所有するオブジェクトを
deleteしない。原則自動変数を使うを守ってりゃ済む話だったのに。
810 ：デフォルトの名無しさん：2011/09/18(日) 23:47:31.77
>>799
一番外まで脱出するケースでしか意味ないじゃん
811 ：デフォルトの名無しさん：2011/09/18(日) 23:50:57.00
>>783
#define X(略) do { 略; } while(0)
は、全く見ないってもんでもないだろ。
812 ：デフォルトの名無しさん：2011/09/18(日) 23:51:34.64
>>809
何らかの管理クラスに一括して管理させたいときだな
他で作って、管理クラスに突っ込んでおく
813 ：デフォルトの名無しさん：2011/09/18(日) 23:53:47.39
break 番号、って、なんかこう……goto 行番号を思い出す……
814 ：デフォルトの名無しさん：2011/09/18(日) 23:56:49.07
>>811
それクソコードだろ。
815 ：デフォルトの名無しさん：2011/09/18(日) 23:58:50.78
>>810
いや、ループのネストが増えようが減ろうが脱出ループは変わらなくなる。
816 ：デフォルトの名無しさん：2011/09/18(日) 23:59:52.79
>>812
そのまとめるオブジェクトを関数スコープかクラススコープに置いといても変わんないんでしょ？
817 ：デフォルトの名無しさん：2011/09/19(月) 00:01:10.72
labelはアセンブリを思い出すな、というか現役で使ってるから混じるな。
818 ：デフォルトの名無しさん：2011/09/19(月) 00:01:27.27
>>815
俺の認識間違ってるか？

while (A) {
　while (C) {
　　while (D) {
　　　break 1; // Cを抜ける
　　}
　}
}

while (A) {
　while (B) {　// 追加
　　while (C) {
　　　while (D) {
　　　　break 1; // Bを抜けるようになる
　　　}
　　}
　}
}
819 ：デフォルトの名無しさん：2011/09/19(月) 00:03:47.13
あってるよ。必ず外から2個目を抜ける。ラベルみたいに書き換える必要はない。
820 ：デフォルトの名無しさん：2011/09/19(月) 00:04:31.33
4重ループとか頭おかしいだろ・・・
goto以上に読みづらいわ
821 ：デフォルトの名無しさん：2011/09/19(月) 00:06:39.37
>>818
gotoでもラベルの位置変える必要があるよな
Bの前か後かは絶対決めなきゃならない
822 ：デフォルトの名無しさん：2011/09/19(月) 00:16:12.60
break n;の件だけどあれじゃん
要するにnに関数ブロック以上の制御ブロック全てを含めりゃ
ネストの深さだけで判断できて解決するんだろ
オフサイドっぽいかんじで
823 ：デフォルトの名無しさん：2011/09/19(月) 00:19:19.91
>>811
Cでは便利でもC++で使う意味はあまり……

実用上gotoで十分と思うけどねえ。nがそこまで大事な子に見えないし。
824 ：デフォルトの名無しさん：2011/09/19(月) 00:21:54.31
>>811
そんなモンの中に break 突っ込む奴はイカレてるだろ。
825 ：デフォルトの名無しさん：2011/09/19(月) 00:22:21.07
まぁ今更締め切られたもんに機能追加する妄想しても仕方あるめェよ。
826 ：デフォルトの名無しさん：2011/09/19(月) 00:23:42.35
>>821
while(C)についてるってのは変わらんだろ
ループ追加しても普通は位置なんて変える必要はないのだから
大して問題にならない
ネスト深くなるからって関数化する時もラベルならそのままコピーできる

なにより定数で置くにしても
最終的には自分で数を数えて書かないといけないとか
バグの温床じゃないですかー
827 ：デフォルトの名無しさん：2011/09/19(月) 00:24:21.87
>>825
まだC++1xがあるさ
828 ：デフォルトの名無しさん：2011/09/19(月) 00:24:45.94
switch(x)do
{
      default;
      break;
      case 0:
      retrun 0;
      case 1:
}while(0);;

ある意味最凶やね
829 ：デフォルトの名無しさん：2011/09/19(月) 00:26:50.05
>>826
Bについて値を変えなくていいのは変わらんし
五十歩百歩目糞鼻糞。
830 ：デフォルトの名無しさん：2011/09/19(月) 00:28:09.98
>>827
何十年後になるんだろ。
そういや詳細知らないけど前回は03だっけ。
831 ：デフォルトの名無しさん：2011/09/19(月) 00:31:59.20
>>809
だよねー
832 ：デフォルトの名無しさん：2011/09/19(月) 00:38:31.63
03はマイナーチェンジだから実質98と考えた方がいい
833 ：デフォルトの名無しさん：2011/09/19(月) 00:46:56.38
プログラムの最初から最後まで使う→main関数で値を持つ
2つのウィンドウ等で共有する→ウィンドウを所有するオブジェクトか関数が共有するオブジェクトを持っておく
条件によって返すオブジェクトが変わる関数がある→関数でなくオブジェクトにして保有するオブジェクトをきりかえてやればいい。

share_ptrの必然性はないわな。
834 ：デフォルトの名無しさん：2011/09/19(月) 01:12:30.15
誰も言及していないけど break n は php には既にある。
内側から n 個目のループを抜ける仕様。
835 ：デフォルトの名無しさん：2011/09/19(月) 01:13:15.94
最後日本語でおk
てか右辺値参照のおかげでただ返すだけならunique_ptrで良いし
836 ：デフォルトの名無しさん：2011/09/19(月) 01:18:26.97
昔は配列にnewしたの突っ込む時はptr_vectorかshared_ptrのvectorを使ってたけど
右辺値参照のおかげでunique_ptrのvectorで十分になったので
shared_ptr使うケースは減りそうだな
837 ：デフォルトの名無しさん：2011/09/19(月) 01:39:33.61
>>738
出来るからするなんて誰も言ってないと思うが。
838 ：デフォルトの名無しさん：2011/09/19(月) 02:04:41.11
>>809,831,833
こういう考えの人って多いの？

複雑なアプリケーションでは所有権が頻繁に移動するケースがあるから
shared_ptrが標準に取り込まれたと思うんだけど
所有権の移動を自力管理しないのは怠慢／所有権を移動するような設計がアホ、とか言われちゃうんだろうか
うーむ・・・周りに嫌がられたくないし、しばらく使わないでおこうかな・・・
839 ：デフォルトの名無しさん：2011/09/19(月) 02:40:53.00
>>838
移動ならunique_ptrでいいんじゃない？

基本的に自動変数を使えばいいってのはその通りだが
Factoryに削除のためのインターフェースをつけるのは俺はやらないな
所有権をunique_ptrに移譲してしまえば使い終わった/例外発生時に自動削除してくれるのにそれをわざわざ手動で削除することもないだろう
840 ：デフォルトの名無しさん：2011/09/19(月) 02:41:44.23
>>838
所有権を共有するわけでもないのに shared_ptr 使うのはアホだろ。
名前見ろっていう。
841 ：デフォルトの名無しさん：2011/09/19(月) 02:47:30.90
>>840
まぁそれはある意味仕方がない
0x以前は"移動"がなかったんだから
842 ：デフォルトの名無しさん：2011/09/19(月) 02:47:57.71
>838
所有権が移動する場面の安全対策は重要。むしろRAIIを使わずに管理するのがアホだろ。
極端な話、shared_ptr吐き出すnewがあっても良いと思うが。

あとはリソースを複数オブジェクトで共有する場合はshared_ptr必須だね。
843 ：デフォルトの名無しさん：2011/09/19(月) 02:49:30.51
>>842
make_sharedってのがある
844 ：デフォルトの名無しさん：2011/09/19(月) 02:49:43.02
>>841 auto_ptr ...
845 ：デフォルトの名無しさん：2011/09/19(月) 02:53:08.63
>>844
それはやめとけ
846 ：デフォルトの名無しさん：2011/09/19(月) 03:08:21.28
なんでだよー。わかってて使う分には（特に移植性とか）最強なのに。
あ、コンテナは boost ptr_container ね。
847 ：デフォルトの名無しさん：2011/09/19(月) 03:34:14.31
他の言語にあるのに何でC++11に入らなかったんだリスト
・ラベル付き（or ネスト数付き）break/continue
・finally
・プロパティ
・restrict修飾子

まだまだある？
848 ：デフォルトの名無しさん：2011/09/19(月) 03:45:53.14
C99のdesignator
849 ：デフォルトの名無しさん：2011/09/19(月) 03:49:18.53
C++ってrestrict入ってないのか・・・
850 ：デフォルトの名無しさん：2011/09/19(月) 05:29:17.30
finallyはRAIIで代用出来るから要らない
というよりは、finallyがあったとしてもなるべくRAIIを使うべきというくらいだ
851 ：デフォルトの名無しさん：2011/09/19(月) 06:46:31.90
>>847
restrictはC99だから上位互換として実装されるんじゃないの?
852 ：デフォルトの名無しさん：2011/09/19(月) 06:50:52.71
されないよ
別にC++はC99との完全互換は目指してないから
853 ：デフォルトの名無しさん：2011/09/19(月) 06:51:18.91
>>850
上にもあるけどラムダで済むようになったしね。
汚いネストが減る分こっちの方がいい。
854 ：デフォルトの名無しさん：2011/09/19(月) 07:18:30.76
まあunique_ptr使うよりは、それなりのクラス作った方が分かりやすくはあるかな

#include <iostream>
#include <functional>

class Finally {
public:
　　Finally(std::function<void()> f) : f(f) { }
　　~Finally() { f(); }
　　Finally(const Finally&) = delete;
　　Finally& operator=(const Finally&) = delete;
private:
　　std::function<void()> f;
};

int main()
{
　　FILE* fp = NULL;
　　Finally f1([&]{
　　　　fclose(fp);
　　});

　　// fpを使う
}

先に後始末を書くあたり、D言語のスコープガード文に似てるね
855 ：デフォルトの名無しさん：2011/09/19(月) 09:13:49.66
>>847
前々スレ位に出てたけどシンボル。

function(this, &Type::Function);
とか書くのがだるい。

function<Function>(this);
と関数からシンボルを独立させて渡したい。
856 ：デフォルトの名無しさん：2011/09/19(月) 09:22:58.96
メンバ関数ポインタの取得でクラス名は必須だけど、
そうなった経緯ってどんなの？
857 ：デフォルトの名無しさん：2011/09/19(月) 10:02:42.95
>>856
式で使う値だからでしょ。
858 ：デフォルトの名無しさん：2011/09/19(月) 10:23:06.53
VC6はメンバ関数名だけで取れてたし、実装できないわけじゃないでしょ？
859 ：デフォルトの名無しさん：2011/09/19(月) 12:14:33.27
ばかか
860 ：デフォルトの名無しさん：2011/09/19(月) 12:58:31.08
そんなバカみたいにバカいわんでもバカじゃあるまいし
そんなにひとをバカにしちゃいかんで、
バカだ星のバカ大学のバカ学長のバカ息子のバカ友達に掘られるよ。
861 ：デフォルトの名無しさん：2011/09/19(月) 13:04:29.47
VisualStudioに可変テンプレートないとかなんなの？
舐めてんの？
862 ：デフォルトの名無しさん：2011/09/19(月) 13:29:23.39
>>861
gcc-4.6.1 でもまだ実装が不完全でイライラしてるくらいで
全く対応する気なしとか何を考えてるんだと
863 ：デフォルトの名無しさん：2011/09/19(月) 14:17:27.94
イラネー機能のせいにしてコーディングしないタイプ
864 ：デフォルトの名無しさん：2011/09/19(月) 17:36:27.42
>>847
上にもあるけど、goto case
865 ：デフォルトの名無しさん：2011/09/19(月) 17:36:30.90
>>857
もっと詳しく
866 ：デフォルトの名無しさん：2011/09/19(月) 17:42:18.65
C++ならラベル追加すれば素直にgotoできるし、
goto caseより読みやすくできると思うぞ
867 ：デフォルトの名無しさん：2011/09/19(月) 17:59:14.08
そうか？　感性の違いだな
868 ：デフォルトの名無しさん：2011/09/19(月) 18:00:54.88
例えばcaseが複数並んでる所に飛ぶ場合、
どれか１個だけ抽出してgoto caseするより
ラベルにした方が意味が分かりやすいっしょ？
869 ：デフォルトの名無しさん：2011/09/19(月) 18:09:04.03
複数並んでたら、そうだな。
でも1個の場合は goto case の方が良い。
870 ：デフォルトの名無しさん：2011/09/19(月) 18:10:33.73
あと、なぜ別のcaseに飛ぶのか、という理由は、
単に処理が同じだからであって、そのcaseの値に特別な意味があるわけでもない
gotoならcase以外に飛んで２つ以上のcase共通の後処理を素直に行う事もできるし、
caseに飛ぶよりは意味合いが分かりやすくなると思われ
871 ：デフォルトの名無しさん：2011/09/19(月) 18:14:05.94
確かにその通りだけどｸﾞﾇﾇ

そこまでキッチリしにゃきゃならんの？　日曜マには分からん。
872 ：デフォルトの名無しさん：2011/09/19(月) 19:01:27.61
>>870
それダイクストラがやめろっていってたことじゃないのか?
スイッチのネストで解決出来ない?
873 ：デフォルトの名無しさん：2011/09/19(月) 19:31:44.99
switchのネストとかさらっと恐ろしいこと言うのやめて
874 ：デフォルトの名無しさん：2011/09/19(月) 19:40:26.12
二回も条件判定が出ると、修正ミスが起こりそうなのがね
まあ俺もこんなgoto使った事ないけど
goto caseよりはマシだな
875 ：デフォルトの名無しさん：2011/09/19(月) 19:45:50.08
ダイクストラの言う事が全てではないな
基本は複数のcaseで使われる処理を別関数化すると思うけど
あまりに冗長になるならgotoの方が綺麗に書けると思われ
876 ：デフォルトの名無しさん：2011/09/19(月) 19:48:32.35
そういう問題じゃないよ
switchは絶対にネストしてはいけない

void hoge(int x, int y){
switch(x){
case 0:
　switch(y){
　case 0:
　　puts("あ");break;
　case 1:
　　puts("い");break;
　default:
　　puts("う");break;
　}
　break;
case -1:
　puts("え");break;
default:
　puts("お");break;
}
}

hoge(0,0);hoge(0,1);hoge(0,2);hoge(-1,0);hoge(1,1);
と呼ぶとどうなる？
答えはメール欄
877 ：デフォルトの名無しさん：2011/09/19(月) 19:51:38.40
あいうえおって表示されるけど・・・
878 ：デフォルトの名無しさん：2011/09/19(月) 19:59:25.56
>>876は何がしたかったんだ？
879 ：デフォルトの名無しさん：2011/09/19(月) 20:00:06.06
あいうえおだな
880 ：デフォルトの名無しさん：2011/09/19(月) 20:02:49.93
うん、あいうえおだ
881 ：デフォルトの名無しさん：2011/09/19(月) 20:02:59.31
C++規格化前の大昔か、あるいは規格化前のCだと
そういう時期もあったのかもしれないけど、
少なくともC++98にはこう書かれてる

6.4.2 The switch statement
4 Switch statements can be nested; a case or default label is associated with the smallest switch enclosing it.
882 ：デフォルトの名無しさん：2011/09/19(月) 20:03:00.42
>>876
お前に switch 文は無理だ。
883 ：デフォルトの名無しさん：2011/09/19(月) 20:18:33.42
4スイッチの文は入れ子にすることができます。caseまたはdefaultラベルは、それを囲む最小のスイッチに関連付けられています。
884 ：デフォルトの名無しさん：2011/09/19(月) 20:19:32.52
>>876「コンパイラのバグだ！」
他「いや、お前のバグだろ」

よくあるこれ。
885 ：デフォルトの名無しさん：2011/09/19(月) 20:24:16.87
まあ大昔そういう時期があって
そのまま覚えてるだけかもしれないから
そろそろ許してやろうぜ
886 ：デフォルトの名無しさん：2011/09/19(月) 20:28:42.82
あいうえおﾜﾗﾀ
887 ：デフォルトの名無しさん：2011/09/19(月) 20:30:26.66
>>885
組み込み系か昔のコンパイラあたりでハマるケースがあったのかも知れないね
case -1:ってのが何かのポイントのような気がするが、解説もないし真相は闇の中か・・・
888 ：デフォルトの名無しさん：2011/09/19(月) 21:07:55.57
>>870
これでええんとちゃう。
switch(x)
{
cace 1:break;
cace 2:break;
cace 3:break;
}
switch(x)
{
cace 1:
cace 2:
//共通処理
}
889 ：デフォルトの名無しさん：2011/09/19(月) 21:11:07.48
>>888
>>874
890 ：デフォルトの名無しさん：2011/09/19(月) 21:45:40.84
いやこれで、直し忘れって
gotoの方が忘れるだろ
891 ：デフォルトの名無しさん：2011/09/19(月) 22:09:27.57
case追加するだけでいい場合、
片方にだけcase追加して満足する場合があるんだよな、これが
892 ：デフォルトの名無しさん：2011/09/19(月) 22:10:56.71
そもそも最近switchとかあんま使わないけどな
893 ：デフォルトの名無しさん：2011/09/19(月) 22:11:51.73
caseはただのラベルだから、switchの入れ子はスコープ無視して
外のswitchからボコボコ飛んで来て滅茶苦茶になるからダメって教わってきたんだけど

最近は大丈夫なんだな
VC2010だと確かにあいうえおだわ
VC6やGCC3の頃はスコープ無視して最初のラベルに飛ぶようになってたはず
894 ：デフォルトの名無しさん：2011/09/19(月) 22:12:56.88
switch以外の場合はスコープ無視するけど
switchだけは無視しないぞ
895 ：デフォルトの名無しさん：2011/09/19(月) 22:20:16.99
昔のコンパイラはswitchのスコープも無視してたんだよ
現にそれで痛い目にあった事があったからこんな事書いてるわけで

今は規格も実装もちゃんとネスト出来るようになってるらしいからいいです
昔話で混乱させてすみませんでした
896 ：デフォルトの名無しさん：2011/09/19(月) 22:34:45.65
VC6の頃もそうだっけかな・・・
あの頃はまだ規格ができたばかりの時期だったし
準拠率ひどいもんだったのであり得るとは思うけど、
C89だとそこんとこどうなんだろう？
897 ：デフォルトの名無しさん：2011/09/19(月) 22:35:12.62
>>891
意図して共通処理実行させるのに忘れる理由が解らん。
むしろ共通処理へのcaceを書いてないときは、
共通処理が実行されないことを望むだろ。
898 ：デフォルトの名無しさん：2011/09/19(月) 22:36:55.79
>>897
コピペや置換にミスはつきものなんだよ
理屈じゃない
人間は優秀だとしても100%正確に何かをできるとは限らないのだ
899 ：デフォルトの名無しさん：2011/09/19(月) 22:38:03.09
そのとおり計算上ほぼ百％安全だったはずの原発もポポポポーンしてしまうものなのだ
900 ：デフォルトの名無しさん：2011/09/19(月) 22:51:59.11
あれは計算の方を弄って100%を装ってただけだろーがｗ一緒にスンナ？
901 ：デフォルトの名無しさん：2011/09/19(月) 23:04:18.36
> 外のswitchからボコボコ飛んで来て滅茶苦茶になるからダメって教わってきたんだけど

上司に恵まれなかったんだな
バグが原因なのに、言語のせいにする上司
可哀想に
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　（笑）
902 ：デフォルトの名無しさん：2011/09/19(月) 23:09:22.97
C89でもswitchは普通にネストできるね
VC6でネストできないってのは流石にないんじゃないの？　時代的に
903 ：デフォルトの名無しさん：2011/09/19(月) 23:10:30.06
>>898
goto はその辺酷いだろ。
904 ：デフォルトの名無しさん：2011/09/19(月) 23:11:23.74
あいううい になるコンパイラが特定されるまでは
>>876の間違い。そんなふうになるコンパイラはないってことで、
スレは進みます。
905 ：デフォルトの名無しさん：2011/09/19(月) 23:19:11.01
>>903
印象だけで語られても
906 ：デフォルトの名無しさん：2011/09/19(月) 23:26:46.56
印象もくそも入り組むし事実だと思うけど。
907 ：デフォルトの名無しさん：2011/09/19(月) 23:29:00.50
>>905
試しにgoto cace とやらを書いてみて。
908 ：デフォルトの名無しさん：2011/09/19(月) 23:34:41.31
gotoの例ってこんな感じでいいか？

switch (key) {
case VK_LEFT: x--; goto RING_Y;
case VK_RIGHT: x++; goto RING_Y;
RING_Y:
　x = (x + width) % width;
　break;

case VK_UP: y--; goto RING_Y;
case VK_DOWN: y++; goto RING_Y;
RING_Y:
　y = (y + height) % height;
　break;
}
909 ：デフォルトの名無しさん：2011/09/19(月) 23:35:27.65
１つ目YじゃなくてXだよ
ミスったよ
まさにコピペの罠
910 ：デフォルトの名無しさん：2011/09/19(月) 23:36:31.59
Cっていうか、かなり足りないC言語ではswitchネストしてbreakすると
一番外まで抜けてしまうコードを吐くこともあるコンパイラには出会ったことあるな
MPLABのPIC用のコンパイラだけどさ
911 ：デフォルトの名無しさん：2011/09/19(月) 23:37:45.54
酷いとしか言いようがない
912 ：デフォルトの名無しさん：2011/09/19(月) 23:45:23.15
そこまで酷いコンパイラになると
もう規格だの実装だの言うレベルにすら達してないな
913 ：デフォルトの名無しさん：2011/09/20(火) 00:15:56.98
template <typename T, typename U, template <class...> class C>
C<U> map(function<U(T)> f, const C<T>& xs) {
C<U> ret;
transform(xs.cbegin(),xs.cend(),back_inserter(ret),f);
return move(ret);
}

これ、
map<int,int>([](int x){return x+1;},xs)
って呼んであげないとコンパイル通らないのですが、何とかなりませんか？
マクロ使えば一瞬なのに・・・
914 ：デフォルトの名無しさん：2011/09/20(火) 00:25:52.22
lambdaはfunctionじゃないからUは推測できない
function<U(T)>じゃなくて直接Lとかにして
その戻り値の型を取得するといいよ
915 ：デフォルトの名無しさん：2011/09/20(火) 00:26:50.27
どう書きたいんだ。
<int, int>を無くしたいの？
916 ：913：2011/09/20(火) 00:37:33.05
>>914
template <class f_type, ...>
typename function<f_type>::result_type map(...
だと、
map<int(int)>(...)
ってかんじに呼び出せることは確認しました。
lambda全体をLにしたとき、L::argument_typeとかって定義されてます？

>>915
そうです。
917 ：913：2011/09/20(火) 01:03:26.85
返信遅れましたが、いけました。
イテレータ渡すときもそうですけど、型の情報がコードの見た目に反映されなくて嫌いです。
functionは記法としていいなぁ、と思ってたんですけどね・・・。

ところでmoveの使い方ってあってます？書かなくてもよかったりして。
918 ：913：2011/09/20(火) 01:06:58.96
いけてなかった・・・orz
map(negate<int>(),xs)
はいいけど、
map([](int x){return -x;},xs)
は
no matching function for call to 'map(main()::<lambda(int)>,std::vector<int>&)'
のエラーになります。
919 ：デフォルトの名無しさん：2011/09/20(火) 01:42:39.38
これでどうよ

template <typename L, typename T>
auto map(L f, const std::vector<T>& xs) -> std::vector<decltype(f(std::declval<T>()))>
{
std::vector<decltype(f(std::declval<T>()))> ret;
std::transform(xs.cbegin(),xs.cend(),std::back_inserter(ret),f);
return std::move(ret);
}
920 ：デフォルトの名無しさん：2011/09/20(火) 02:03:37.20
機能的に妥当な名前だけどmapはやめとこうよ。STLのコンテナとまぎらわしいぞ

template<class F, class T, template<class ...> class C>
auto func(F f, const C<T> & c) -> C<decltype(f(*c.cbegin()))>
{
C<decltype(f(*c.cbegin()))> ret;
transform(c.cbegin(), c.cend(), back_inserter(ret), f);
return ret;
}
921 ：デフォルトの名無しさん：2011/09/20(火) 02:08:50.80
そのための名前空間じゃないの
922 ：デフォルトの名無しさん：2011/09/20(火) 10:24:17.60
名前空間をなんでテンプレの引数にとれないのかな
クラスで代用しろってことなんかな。
広域関数入れ換えられないからたまに欲しくなる。
923 ：デフォルトの名無しさん：2011/09/20(火) 12:48:57.47
可変テンプレート使えないコンパイラでもBoost.Egg(ただしReject)が代用できる
924 ：デフォルトの名無しさん：2011/09/20(火) 18:12:54.38
気になって仕方が無いのでscope(exit)ぽいのも書いてみた
#define do_scpexit(a) {typedef int dmy_t_##a;int sx_cntr_##a=0;
#define sbreak(a) {++sx_cntr_##a;goto label_sx_##a;}
#define scpexit_pp(a) label_sx_##a:;for(int sx_i=++sx_cntr_##a;sx_i>=0;--sx_i){{;
#define exit_case(a) }if(sx_i>=a){
#define close_scpexit(a) }}typedef dmy_t_##a dmy;}

do_scpexit(x){
　sbreak(x);
　sbreak(x);
scpexit_pp(x){
　exit_case(2){}
　exit_case(1){}
　exit_case(0){}
}
}close_scpexit(x)
925 ：デフォルトの名無しさん：2011/09/20(火) 19:23:32.01
ｷﾓｲﾖｰ
926 ：デフォルトの名無しさん：2011/09/20(火) 20:03:25.53
>>908
ないわ
927 ：デフォルトの名無しさん：2011/09/20(火) 21:56:55.07
もう、基地外コードやめてくれる？
そんなの、お前ら密教仲間で使っとけ
928 ：デフォルトの名無しさん：2011/09/21(水) 08:11:35.95
>>919,920
ありがとうございます。これで解決してますが、やっぱ
decltypeは嫌いですねぇ。typeofに逆戻りしてる感じが。

そもそもこのmapって効率悪いけどその場で書くことを目的としていたので、
どうせゴタゴタするならproxyつくるほうに注力するかな・・・。
929 ：デフォルトの名無しさん：2011/09/21(水) 20:01:43.23
->の前にusingでも書きたくなる

template <typename L, typename T>
auto map(L f, const std::vector<T>& xs)
　using U = decltype(f(std::declval<T>()))
-> std::vector<U>
{
std::vector<U> ret;
std::transform(xs.cbegin(),xs.cend(),std::back_inserter(ret),f);
return std::move(ret);
}

こういう事できたらいいんだが
（まあそれでもキモさにそこまで変わりはない気もするが）
930 ：デフォルトの名無しさん：2011/09/21(水) 21:37:51.19
なんでC++な人はLispじゃなくてHaskellに流れてくんだろ
OCamlならまだわかるんだけど
931 ：デフォルトの名無しさん：2011/09/21(水) 21:44:04.30
Lispなんてゴミ今さらやるかよw
932 ：デフォルトの名無しさん：2011/09/21(水) 21:44:43.27
それなりに経験のある人なら、Lisp はもうやったからじゃないの。
933 ：デフォルトの名無しさん：2011/09/21(水) 21:46:04.63
C++な人でLispやっている人見かけないけどな
話題にすらならない
934 ：デフォルトの名無しさん：2011/09/21(水) 21:58:41.47
やはり型がないとやる気が起きない
935 ：デフォルトの名無しさん：2011/09/21(水) 21:58:49.41
Lispの話なんかして
Lisperに絡まれたら嫌だし
936 ：デフォルトの名無しさん：2011/09/21(水) 22:04:45.14
Lisperって面白いことやっている人いないよね
態度はでかいんだけど
937 ：デフォルトの名無しさん：2011/09/21(水) 22:15:35.67
template <typename T1, typename T2, template <class...> class C>
const pair<C<T1>,C<T2>> zip(const C<T1>& xs, const C<T2>& ys) {
return move(make_pair(xs,ys)); //just want to pass
}

C<U> map(BFunc f, const pair<C<T1>,C<T2>>& zs);
938 ：デフォルトの名無しさん：2011/09/21(水) 22:22:00.86
naiveにzip書いてみたのですが、
returnするとき、コピーコンストラクタが呼び出されてる気がします。
なんかうまい手はあります？
（ref(...)とか、使い方しらないので0xのrval_refでそういうのあったりするのかなーとか）

ちなみにpair<const C<T1>&, const C<T2>&>を返すとセグフォだったので諦めました。
939 ：デフォルトの名無しさん：2011/09/21(水) 23:00:34.88
戻り値にmoveはいらないだろ
あと、それzipじゃなくてただのmake_pairじゃん
940 ：デフォルトの名無しさん：2011/09/21(水) 23:25:12.66
>>929
template<class F, class T, class A, template<class, class> class C,
class U = decltype(declval<F>()(declval<T>()))>
C<U, A> func(F f, const C<T, A> & c)
{
C<U, A> ret;
transform(c.cbegin(), c.cend(), back_inserter(ret), f);
return ret;
}
941 ：デフォルトの名無しさん：2011/09/22(木) 00:33:41.25
>>940
完璧です。ありがとうございます。
map(f,zip(xs,ys))も、多重定義でmap(f,xs,ys)にしとくことにしました。
どうせこのパターンでしか使わないだろうし。

あとはreduceか・・・クロージャは素直に渡せるだろうか。
第一引数はconst F&にすればいいのか？
942 ：デフォルトの名無しさん：2011/09/22(木) 04:46:12.58
http://cpplover.blogspot.com/2011/09/blog-post_21.html
943 ：デフォルトの名無しさん：2011/09/22(木) 07:22:06.76
そのうちロベールさんがいい本を出してくれるさ
944 ：デフォルトの名無しさん：2011/09/22(木) 07:37:10.83
言い訳を重ねて逃げるってのはニートの特徴だわな
945 ：デフォルトの名無しさん：2011/09/22(木) 09:40:24.24
ただの愚痴だろ。たまに俺も自分のやってることに自信が無くなる。
無心にやり遂げちゃって決着ついた後なら案外成功でも失敗でも気にならんもんだけど。
946 ：デフォルトの名無しさん：2011/09/22(木) 09:51:37.93
>>930
そりゃ特殊化と同じ事できるからじやね。
あと俺はたまにlisp使う。
947 ：デフォルトの名無しさん：2011/09/22(木) 11:06:53.88
>>946
なんとなくわかった
ちなみに自分は数式処理がどうしても必要なんでlispからは離れられない
948 ：デフォルトの名無しさん：2011/09/22(木) 11:19:39.96
>>933
OpenC++でMOPとか
template駆使してLisp処理系モドキとか、
結構いるんじゃないの。
Boost-dev MLでもSchemeの例あげる人いるし。
949 ：デフォルトの名無しさん：2011/09/22(木) 11:23:00.60
>>946
特殊化はCLOSでもできるし、
むしろあっちが最近の特殊化の流れの大元だけど、
まあもはや流行りじゃないんでしょうねえ。
950 ：デフォルトの名無しさん：2011/09/22(木) 11:47:41.95
autoキーワード使いまくるのは良くないのかな？
たとえばintのところも全部autoにしてるんだけど
951 ：デフォルトの名無しさん：2011/09/22(木) 11:55:09.29
intなのかstd::size_tなのかstd::ptrdiff_tなのか
ぱっと見はっきりしてるんならいいんじゃない？
952 ：デフォルトの名無しさん：2011/09/22(木) 12:38:03.44
>>950
それがだめじゃスクリプト言語もダメって事になるだろ。
953 ：デフォルトの名無しさん：2011/09/22(木) 12:38:53.72
スクリプト言語はダメだろw
954 ：デフォルトの名無しさん：2011/09/22(木) 12:58:42.36
OO的側面からみたら宣言型を明示しなくてよいならそれに越したことはない。
smalltalkだってsimulaの派生なのに宣言型はもってないしね 。
OOらしく依存性を下げたければ出来る限り宣言型でなく
オブジェクト自身の型に委ねるべきだ。

まあそれ以前に11規格は今すぐ使っていいものではないけど。
955 ：デフォルトの名無しさん：2011/09/22(木) 14:22:31.22
functionとかautoを使わないで「引数がAで返り値がRになるラムダ式」っていう型は作れないの？
956 ：デフォルトの名無しさん：2011/09/22(木) 14:26:41.05
作れない
957 ：デフォルトの名無しさん：2011/09/22(木) 14:49:40.47
テンプレ使えば作れますん
958 ：デフォルトの名無しさん：2011/09/22(木) 22:34:06.11
GCC4.6で

template <int n, int...ns>
struct sum {
static const int value = sum<ns>::value;
}

ってやると「まだ実装されてない」っておこられるけど、
これって仕様としてはアリなのですか？
959 ：デフォルトの名無しさん：2011/09/22(木) 22:36:31.38
明らかに
n+sum<ns>::value
だった。すみません。
960 ：デフォルトの名無しさん：2011/09/22(木) 22:42:37.90
n+sum<ns...>::value じゃないの
まあ未実装みたいだけど
961 ：デフォルトの名無しさん：2011/09/22(木) 22:46:56.95
main.cpp:9:40: 残念ですが未実装です: cannot expand ‘ns ...’ into a fixed-length argument list

切ない
962 ：デフォルトの名無しさん：2011/09/22(木) 23:58:24.70
「残念ですが」の余計な一言がイラッとさせる
963 ：デフォルトの名無しさん：2011/09/23(金) 00:00:48.36
ぷぷっ、未実装ですよJKｗｗｗｗ
964 ：デフォルトの名無しさん：2011/09/23(金) 01:21:12.88
>>950
リテラルで初期化するところは全部autoにしちゃってるな
965 ：デフォルトの名無しさん：2011/09/23(金) 01:46:51.61
それてfloat/double、short/int/longの適用次第計算中の精度が落ちたりする弊害出たりするんじゃね？
966 ：デフォルトの名無しさん：2011/09/23(金) 01:59:47.23
main.cpp:9:40: どうして実装してると思ってしまったのかな？ちょっとびっくりしました(笑): cannot expand ‘ns ...’ into a fixed-length argument list
967 ：デフォルトの名無しさん：2011/09/23(金) 07:52:04.50
>>965
auto関係ない
968 ：デフォルトの名無しさん：2011/09/23(金) 08:07:45.94
リテラルが何の型になるかって環境依存だから
autoにしない方がいいと思うけど
969 ：デフォルトの名無しさん：2011/09/23(金) 08:08:50.63
整数リテラルは、ね
970 ：デフォルトの名無しさん：2011/09/23(金) 08:56:14.38
>>964
本末転倒も甚だしいな。
971 ：デフォルトの名無しさん：2011/09/23(金) 10:54:41.28
autoはコードの可読性が下がるので明示しろ派との宗教戦争が勃発すると予言しておこう
972 ：デフォルトの名無しさん：2011/09/23(金) 11:00:02.92
そのうちautoはラムダとイテレータだけに使っとけよみたいな案がでます
973 ：デフォルトの名無しさん：2011/09/23(金) 12:47:55.90
auto a = -2147483648 * 1;
auto main() { }
974 ：デフォルトの名無しさん：2011/09/23(金) 13:18:32.27
C++0xの追加要素のせいで過去のコードがバグるっていう可能性はありますか？
975 ：デフォルトの名無しさん：2011/09/23(金) 13:53:10.06
理屈の上では可能性はあるけど現実的には実際に使われてるC++98/03準拠のコードがC++11で動作が変わるということはほぼありえない。
もっともコンパイラのC++11対応(=バージョンアップ)の結果、古いバージョンでの独自拡張や規格違反だった仕様が変更されて
それに依存していたコードの動作が変わる可能性ならばそれなりにある。
976 ：hiding：2011/09/23(金) 14:05:01.75
一番でかいのは文字列リテラルからconst除去したポインターに変換できなくなったことだろ。
Cに毛の生えた程度の糞コードは軒並みエラーになるだろ。
977 ：hiding：2011/09/23(金) 14:05:43.16
専ブラ使ってると、ついついコテハン記録機能がorz
978 ：デフォルトの名無しさん：2011/09/23(金) 14:13:42.98
>>976
実際には、あんまり派生言語対応とか考えられてないCライブラリのヘッダーが使えなくなって、
やむをえずコンパイラの互換性オプションを変更するはめに……ってなりそうだけどな
979 ：デフォルトの名無しさん：2011/09/23(金) 14:45:49.79
コンパイルできなくなるのはたいした問題ではなくあるいは逆に喜ぶべきことであったりする。
もし修正なしにコンパイルはできるが動作が変わることがあったりしたら地獄を見る。
980 ：デフォルトの名無しさん：2011/09/23(金) 14:55:31.72
03のstringでコンパイルしたobjファイルを0xでつかおうとすると死ぬ？
981 ：デフォルトの名無しさん：2011/09/23(金) 15:17:10.98
次スレC++11でよろしくな
982 ：デフォルトの名無しさん：2011/09/23(金) 15:56:29.44
C++11/C++0x 14
http://hibari.2ch.net/test/read.cgi/tech/1316760961/
983 ：デフォルトの名無しさん：2011/09/23(金) 18:26:33.36
ところで、あんた達、このC++11の仕様を仕事に使う気(というか、もう勇気)
あるん？

まったく、くだらん。せいぜいマスターベーションでもしてろ、馬鹿がｗ
984 ：デフォルトの名無しさん：2011/09/23(金) 18:55:30.04
>>980
03でコンパイルしたobjと0xでコンパイルしたobjで使用してるstringの実装が異なっているときに
03objで生成したstringを0xobjで受け取って使ったりその逆をやったりすればしねるかもしれない。
985 ：デフォルトの名無しさん：2011/09/23(金) 19:34:04.50
>>983
下っ端の教育とかまで考えるとちょっと踏み込む勇気いるよね
986 ：デフォルトの名無しさん：2011/09/23(金) 19:44:57.40
右辺値参照はSTLに組み込まれて速くなるだけでいいや

ラムダ式は多用すると思う、ってかgccでは既に多用してる
987 ：デフォルトの名無しさん：2011/09/23(金) 21:44:00.69
使い勝手悪かったalgorithmさんが
これで活躍してくれるかも
988 ：デフォルトの名無しさん：2011/09/23(金) 21:50:08.38
range版algorithmとrange adaptorが来るまでは標準のalgorithmは使う気にはなれない
989 ：デフォルトの名無しさん：2011/09/23(金) 22:07:06.11
まだないんだっけ？
コンセプトさんがいないせいなのか
990 ：デフォルトの名無しさん：2011/09/23(金) 22:17:56.81
下っ端はライブラリ作らないんだからむしろautoとラムダだけ教えればいいわけで楽勝なんでは
991 ：デフォルトの名無しさん：2011/09/23(金) 22:21:57.13
下っ端がどうとか底辺の話はマ板でやってくれ
992 ：デフォルトの名無しさん：2011/09/24(土) 02:16:46.11
うめるか
993 ：デフォルトの名無しさん：2011/09/24(土) 02:18:09.07
>>990
ライブラリ的にはスレッドサポートが大きいと思うけど
atomicは楽勝なのだろうか
994 ：デフォルトの名無しさん：2011/09/24(土) 03:28:37.10
ウリもラムダ式は使いたいニダ
995 ：デフォルトの名無しさん：2011/09/24(土) 04:36:46.23
うめとくか
996 ：デフォルトの名無しさん：2011/09/24(土) 13:54:52.17
うめる
997 ：デフォルトの名無しさん：2011/09/24(土) 13:57:20.95
うめてんてー
998 ：デフォルトの名無しさん：2011/09/24(土) 14:45:12.63
C++998
999 ：デフォルトの名無しさん：2011/09/24(土) 14:45:30.22
C++999
1000 ：デフォルトの名無しさん：2011/09/24(土) 14:45:51.02
C++1000
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。