C++0x 13

0001デフォルトの名無しさん

2011/07/21(木) 18:26:01.14

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/

0002デフォルトの名無しさん

2011/07/21(木) 18:26:42.58

0003デフォルトの名無しさん

2011/07/21(木) 18:27:32.83

親戚スレ
C1x
http://hibari.2ch.net/test/read.cgi/tech/1296642667/

0004デフォルトの名無しさん

2011/07/21(木) 19:41:04.13

C++0xはこのスレで最後になって次はC++1xかな
201x中に出せるかどうかは怪しいけど

0005デフォルトの名無しさん

2011/07/21(木) 19:42:18.66

C++0B

0006デフォルトの名無しさん

2011/07/21(木) 23:56:28.58

>>1乙

最後なので事情通の人、C++学園のまとめを書いていただけたら

0007デフォルトの名無しさん

2011/07/22(金) 00:18:26.62

・progress_displayたん

0008デフォルトの名無しさん

2011/07/22(金) 01:42:57.19

C99未対応 == C++0x未対応？

0009デフォルトの名無しさん

2011/07/22(金) 05:06:20.46

c++0xはc99のVLA(可変長配列)サポートしないんじゃなかったっけ

0010デフォルトの名無しさん

2011/07/22(金) 05:37:11.99

他にも色々サポートしないよ
コンパウンドリテラルとかコンストラクタあったら要らないし

0011デフォルトの名無しさん

2011/07/22(金) 07:58:47.87

>>9
これは何で？
例外のせい？

0012デフォルトの名無しさん

2011/07/22(金) 08:24:25.04

禿はvector使えっていってる

0013デフォルトの名無しさん

2011/07/22(金) 10:58:58.30

T foo(int size, U array[size])とか狂ってるしな。やりすぎ

0014デフォルトの名無しさん

2011/07/22(金) 14:47:46.63

禿は自分の好き嫌いで足引っ張んなよクソが

0015デフォルトの名無しさん

2011/07/22(金) 19:06:15.38

vectorでいいじゃん

0016デフォルトの名無しさん

2011/07/22(金) 20:47:52.66

0xでもstringのデータは&s[0]で取得するの？
dataだとconst付きのchar*が返っちゃうし

0017デフォルトの名無しさん

2011/07/22(金) 22:39:48.15

vectorじゃメモリー確保が遅すぎて代替品にならんだろ。
てか、禿はほぼ100% C99と互換性もたせるんじゃなかったのかよ。

0018デフォルトの名無しさん

2011/07/23(土) 00:13:43.64

だからやってるだろ

0019デフォルトの名無しさん

2011/07/23(土) 00:15:51.95

Designated Initializerは入れて欲しいんだが。
つかなんでみんなこれ無視すんだ。

0020デフォルトの名無しさん

2011/07/23(土) 00:18:06.78

VLAをvectorに替えて遅くなるというシチュエーションが思いつかん。

0021デフォルトの名無しさん

2011/07/23(土) 00:23:17.80

VLAの実装がallocaの場合はvectorより速い？

0022デフォルトの名無しさん

2011/07/23(土) 00:38:10.76

そりゃVectorといかnewはファーストフィットかベストフィットかしらんけど
メモリ中を捜査して空き容量捜し回ってんだから1回の加算だけでメモリ確保する
alloca方式には敵わんわなぁ。

0023デフォルトの名無しさん

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バージョン書いてみた

0024デフォルトの名無しさん

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がコンパイル時に確定できない)から駄目ってことですかね？

0025デフォルトの名無しさん

2011/07/23(土) 08:41:21.52

動的に決まるsizeofとか死ねばいいのにと思う

0026デフォルトの名無しさん

2011/07/23(土) 09:51:52.52

つかやったことないけどVLAのsizeofって動的に結果返ってくるの？
だとしてC++で問題あるの？

0027デフォルトの名無しさん

2011/07/23(土) 09:59:39.10

sizeof適用不可にすれば？

0028デフォルトの名無しさん

2011/07/23(土) 10:03:57.10

> つかやったことないけどVLAのsizeofって動的に結果返ってくるの？
うん

0029デフォルトの名無しさん

2011/07/23(土) 10:31:41.81

allocaする配列クラスを作れば良かったのに
実装方法？　コンパイラが頑張れ

0030デフォルトの名無しさん

2011/07/23(土) 10:39:26.05

スタック使用を管理するクラスってどんなだよｗ

0031デフォルトの名無しさん

2011/07/23(土) 10:45:10.78

どっかにムーブされる可能性がある場合はヒープにとって、
関数内で利用が完結している場合はallocaして
グローバル変数の時は静的に確保する万能クラスを！

……どーかんがえても組み込みの配列拡張したほうが早い→そしてVLAへ……

0032デフォルトの名無しさん

2011/07/23(土) 10:51:24.13

ムーブでそこまで特殊な事する必要ないだろー
ローカル変数のアドレスの扱いは自己責任が基本

0033デフォルトの名無しさん

2011/07/23(土) 10:53:13.35

あと、静的に確保する際はサイズが決まって無いと無理なので
arrayで十分

0034デフォルトの名無しさん

2011/07/23(土) 10:55:02.70

allocaが使用されるのは限定的な場面だしなあ
sizeofは頻繁に出てくる分、動的sizeofになったときの影響のほうがでかいのだろうか…
一応TR2にdynarrayという動的配列のようなテンプレートクラスが提案されていたりする

0035デフォルトの名無しさん

2011/07/23(土) 11:06:34.65

お、提案はあるのか
size()でサイズ取得するなら
sizeofはクラス自体のサイズでいいからな

0036デフォルトの名無しさん

2011/07/23(土) 11:13:26.01

可変長配列は静的には無理だし、ヒープはnew[]そのものだし。
VLAくらいしかやることないだろ。

0037デフォルトの名無しさん

2011/07/23(土) 12:32:16.91

形式的に、sizeofの結果をポインタ＋size_tのサイズとしてしまえばいい
配列の長さはsize()で取得
メモリ確保やメンバ関数の動作は組み込みで

0038デフォルトの名無しさん

2011/07/23(土) 12:42:04.12

あほか

0039デフォルトの名無しさん

2011/07/23(土) 12:46:07.37

dynamic_sizeof を導入すればいいじゃなーい。

0040デフォルトの名無しさん

2011/07/23(土) 12:47:32.36

ふつうにC++と共存してるコンパイラでできてることをなぜ変える必要があるのか

0041デフォルトの名無しさん

2011/07/23(土) 13:06:55.53

VLAだけじゃなくコンパウンドリテラルとかも導入しないと
共存なんて夢のまた夢だよ

0042デフォルトの名無しさん

2011/07/23(土) 13:11:46.61

void foo(int a[const restrict], int b[const restrict]); とかキモいし
C99との共存とか要らない

0043デフォルトの名無しさん

2011/07/23(土) 14:23:35.57

正直C99をフル実装するという需要がどこにあるんだろうな

0044デフォルトの名無しさん

2011/07/23(土) 15:09:57.73

それを言い出すとC++0xをフル実装する需要は…という話にも

0045デフォルトの名無しさん

2011/07/23(土) 15:13:34.60

C++0xの需要ならここにある
……いやフルにあるかというと微妙かもしれないが

0046デフォルトの名無しさん

2011/07/23(土) 15:39:31.68

VLA自体はg++で実証済みだよね。
現実的に今さら問題になるような事は無いと思うけど。

0047デフォルトの名無しさん

2011/07/23(土) 15:57:07.38

ガスライティング

0048デフォルトの名無しさん

2011/07/23(土) 16:41:37.91

C++ユーザーが文法キモイとか

0049デフォルトの名無しさん

2011/07/23(土) 19:10:23.28

元がキモいからこそ
これ以上きもい文法はなるべく要らないと
ラムダくらいメリットが無い限り

0050デフォルトの名無しさん

2011/07/23(土) 19:33:18.45

すっかり手遅れな気がするのは俺だけか

0051デフォルトの名無しさん

2011/07/23(土) 21:39:41.16

互換性なんてもう諦めて新低級言語作れよ
過去の資産なんてコンバータ通せば十分だろ

0052デフォルトの名無しさん

2011/07/23(土) 21:45:31.26

碁

0053デフォルトの名無しさん

2011/07/23(土) 21:46:15.15

簡単に言うなよ。
C++からコンバート可能ということは、例え文法が違うとしても
キモい部分含めてC++の全機能を持ってないといけないということだぞ。

0054デフォルトの名無しさん

2011/07/23(土) 22:04:58.23

僕の作った最強の言語はろくな結果にならない
ソースはＤ言語

0055デフォルトの名無しさん

2011/07/23(土) 22:17:04.81

C++から学んだことは「コードは書いちゃいけない」

0056デフォルトの名無しさん

2011/07/23(土) 22:47:16.61

>>51
そんなアナタに D と Go

0057デフォルトの名無しさん

2011/07/23(土) 23:03:20.90

C++の文法って別にキモいとは思わないけどなぁ
1パスでコンパイルするためにめんどくさくなってる部分はあるけど

それに、AppleのBlockの酷さを見たら、ラムダさんはもうあれでいいと思うよ

0058デフォルトの名無しさん

2011/07/23(土) 23:29:31.94

Blocksさんってそんなに糞なの？
前にラムダなんかやめてBlocksを標準にしろって林檎信者が暴れてたけど

0059デフォルトの名無しさん

2011/07/23(土) 23:40:22.96

センスない。
http://en.wikipedia.org/wiki/Blocks_(C_language_extension)
こんなものをClangに実装させられるGregor先生が可哀想。

0060デフォルトの名無しさん

2011/07/23(土) 23:40:54.20

文法で言えばRubyやVBの方がキモイと感じるけどな。
Rubyのブロックの改行がイラっとするし、メッセージやブロック関連が一貫されてないのが
意味が解からん。あとVBはなんで戻り値返すか、返さないかだけでサブルーチンの書き方変わるんだよ。
めんどくせぇだけじゃん。

0061デフォルトの名無しさん

2011/07/23(土) 23:43:19.98

Wirth先生大激怒w

0062デフォルトの名無しさん

2011/07/23(土) 23:48:18.36

__blockとかBlock_copyとか見た目のアレさ加減もさることながら仕様がクソすぎて胃の内容物がcore dumpする
Blocksさん作った奴の言語設計センスはPHPの設計センスに匹敵するわ

0063デフォルトの名無しさん

2011/07/23(土) 23:56:12.03

>>61
RubyはEiffel系統だ。VBは色々混じってるがFortran系統だ。
endってキーワードが同じだけでPascal/Modula系統と一緒にするんじゃねえ。ぜんぜん違う。

0064デフォルトの名無しさん

2011/07/24(日) 00:58:06.39

つ procedure/function

0065デフォルトの名無しさん

2011/07/24(日) 01:18:08.41

Pascalは返値を捨てられないからな。
逆にModula以降は全部procedureだぜ。そんな事も知らないのはWirth先生に失礼だろ。

0066デフォルトの名無しさん

2011/07/24(日) 02:55:22.51

Block_release() で使う気なくなるなw
C#でyield return見たときキモかったけど、理屈抜きで使えば便利だw

0067デフォルトの名無しさん

2011/07/24(日) 03:15:14.91

C++(のラムダ)にはデストラクタがあるってだけで、なんらかの後始末が必要なこと自体は変わらんと思うが

0068デフォルトの名無しさん

2011/07/24(日) 05:29:57.56

ラムダを返値として返す時に、
明示的にBlock_release()する必要があるか、スコープ抜けたら勝手に処理されるかは
かなり決定的な違いだと思うんだが

0069デフォルトの名無しさん

2011/07/24(日) 05:40:57.21

つーてもC言語の文化を破壊してまで勝手に後始末される型を導入するなら
クロージャ云々よりもそれこそまず動的配列だしなあw
暗黙に生成されるコードがほとんど無い利点を潰すほどじゃないでしょ

0070デフォルトの名無しさん

2011/07/24(日) 05:54:58.30

いや後始末っていうか、C++0xのラムダはコピコン(またはムーブ)で渡されるだけなんで
スコープ抜けたらスタックから消えるってのは普通にC言語の文化を踏襲してるだけだから
そもそもなんでBlock_releaseなんてものが必要な仕様にしたのかが分からん

0071デフォルトの名無しさん

2011/07/24(日) 05:57:29.65

？
ブロックだってBlock_copyしなきゃreleaseもいらんのでは？

0072デフォルトの名無しさん

2011/07/24(日) 05:59:53.21

>>71
Blocksは変数キャプチャしたラムダを返値にする時はBlock_copyが必要
スタックからスタックにラムダをコピーできない

0073デフォルトの名無しさん

2011/07/24(日) 06:23:55.75

キャプチャするローカル変数の個数がわかんないんだから、固定サイズにはできないでしょ。
C++のようにラムダごとに別の型ってわけにもいかないし。

0074デフォルトの名無しさん

2011/07/24(日) 06:38:41.34

>>73
デストラクタ機構がないとスコープ脱出で自動処理とか出来ないもんなぁ

そもそもキャプチャ情報なんて動的オブジェクトになるんだから本質的にCと相性悪いので
Cに無理矢理ねじ込んだ時点でどう転んでもセンスの悪い設計にしかならない罠

0075デフォルトの名無しさん

2011/07/24(日) 06:43:41.72

道は無いこともないけどな。「可変サイズの返値」をサポートすれば。
要はallocaモドキの動作で無理やり呼び出し元のスタックに領域を作って返す、ってことだけど。
コンパイラに大改造が必要になる上に最近のCPUとも相性悪いけど。

0076デフォルトの名無しさん

2011/07/24(日) 06:50:04.16

>>75
そりゃ返値を返すだけなら方法はいくらでもあるが、
それを構造体メンバに代入したいとか言ったら結局詰むから何も解決してないよ。

0077デフォルトの名無しさん

2011/07/24(日) 06:54:01.09

いやさ>>72が「スタックからスタックに」って言ったから

親関数がスタック上にある場合のみ有効なdownward限定モードもあるといいなあとは思う。C++も含めて。
これなら関数ポインタとフレームポインタの組だけで済むしコピーとか後始末とか全く要らないんで非常に軽量。
初期のD言語のdelegateってことだけど。

0078デフォルトの名無しさん

2011/07/24(日) 06:57:16.44

>>77
C++的にはそれは「ムーブでやれ」じゃないかな

0079デフォルトの名無しさん

2011/07/24(日) 10:41:16.65

まあBlocksはCの範疇で使えないといけないから
ああいうダサい感じになるのも仕方が無いよ
デストラクタのあるC++とは違う

0080デフォルトの名無しさん

2011/07/24(日) 11:02:29.12

あんなダサい仕様にするくらいなら
Boehm GCみたいなGC前提にしてくれた方が良いわ

0081デフォルトの名無しさん

2011/07/24(日) 11:13:23.64

詳しく知らないけどひょっとしてBlocksってObjCの仕様じゃなくてCの独自拡張なの？

0082デフォルトの名無しさん

2011/07/24(日) 11:14:33.54

そうか？むしろやってることがC++0xのラムダと変わんない分ありがたい気もするが。
下手にGC前提とかgccのようなスタックに実行属性付けるの前提とかやられたほうが
C/C++両対応コンパイラにとっては痛すぎるぞ。

0083デフォルトの名無しさん

2011/07/24(日) 11:17:40.34

ObjCの独自仕様だが、Cに入れようとAppleが頑張ってる、って状況のはず

0084デフォルトの名無しさん

2011/07/24(日) 11:18:32.01

つまりC1Xに突っ込もうとしてるのか
なるほど

0085デフォルトの名無しさん

2011/07/24(日) 11:23:47.40

正確には、C1Xに突っ込もうとしてた、かな？
もうC1Xに入る可能性は殆ど無いと思う

0086デフォルトの名無しさん

2011/07/24(日) 11:29:31.24

ObjCの独自拡張じゃなくて、Cに対するAppleの独自拡張
てかあんなのがC1Xに入ったらC++系にC1Xは入れないでくれと言いたくなるぞ

>>82
Appleが出したBlocks提案にはGCの仕様も入ってるんだよ……(ゴクリ
あいつらに言語設計させないで欲しい

0087デフォルトの名無しさん

2011/07/24(日) 11:37:39.89

そこまで言うほどのことかよ。文法の違いだけじゃないか。
ABI的にはキャストすればそのまま渡せるぐらいだろ？
それにGCつったってC++だってGCの想定はしてるじゃないか。

0088デフォルトの名無しさん

2011/07/24(日) 11:57:14.38

Block_copy/Block_releaseの存在が「文法の違い」で済むとは思えないが

0089デフォルトの名無しさん

2011/07/24(日) 12:00:10.07

文法の違いだよ。
Cにデストラクタやコピーコンストラクタなんて入れられるはずもないんだから。

あれか？C99の複素数もゴミと思ってるタイプ？

0090デフォルトの名無しさん

2011/07/24(日) 13:08:26.76

文法の違いって言ったらそりゃあ何だってそうだが、
C層への実装が適切かどうか設計時点で疑問を覚えるべき由々しき違いだと思うぞ。

0091デフォルトの名無しさん

2011/07/24(日) 14:11:56.93

それはC++側でやるからCは余計なことすんなって意味か？
だとしたらすごい傲慢な意見と思うが。

CにはC++の事なんか気にする理由は全くない。
ブロックが没になるとしても純粋にC言語としてどうかって観点でのみ語られるべきで
上位言語でもっと上手い実装方法があるからなんてのは考慮されるべきではないだろ

0092デフォルトの名無しさん

2011/07/24(日) 14:50:41.12

C言語としてどうかって観点で言えばそもそもC言語には不適切な機能ってことになるだろうし
どうせObj-C決め打ち環境での独自拡張なんだからObj-Cのメッセージ機構として実装すればよかったのにとは思うぞ

0093デフォルトの名無しさん

2011/07/24(日) 14:53:22.72

Cは高級アセンブラの立場を忘れるべきじゃないと思う。
64ビット幅の型とか、曖昧な部分の明確化とかのメンテナンス的な地味な改定だけでいいよ…
今更新しい機能を入れるとかやめてー

0094デフォルトの名無しさん

2011/07/24(日) 15:05:11.58

でも規格決めてる人達は未だに今をときめく高級言語だと思ってる節があるからなぁ…
K&R時代の気分で

0095デフォルトの名無しさん

2011/07/24(日) 15:17:44.50

機械語レベルで考えて言語機能じゃないと実現不可能なものは入れるべき。
今のブロックやC++0xのラムダは所詮struct+関数ポインタのシンタックスシュガーだからどうでもいいけど
gccのスタックを実行するタイプのラムダなら規格に欲しい。
あと可変長返値なんて欲しいと思わないか？strdupa(strdup+alloca)なんかをアセンブラじゃなくてCで書けるようになるぜ？

0096デフォルトの名無しさん

2011/07/24(日) 16:00:15.68

トランポリンはスタックまるごと実行可能にしてるんで勘弁

0097デフォルトの名無しさん

2011/07/24(日) 17:59:24.70

＞C++0xのラムダは所詮struct+関数ポインタのシンタックスシュガー
えー

0098デフォルトの名無しさん

2011/07/24(日) 18:04:26.99

ラムダ用のメモリが自動的に動的に管理されれば
単なるシンタックスシュガーではないのだろうけど、
0xのラムダは単にキャプチャ対象変数をメンバに持つ
関数オブジェクトを作ってるに過ぎない

0099デフォルトの名無しさん

2011/07/24(日) 20:09:39.11

ん、それで何か問題あるのかというか、それ以上何を管理して欲しいんだ？

0100デフォルトの名無しさん

2011/07/24(日) 20:23:12.18

>>99
だからメモリをだろ。
Lisp だと lambda 使いまくりだけど、 GC が無かったらかなり使い難い言語だっただろうなーとは思うので >>98 に同意。

0101デフォルトの名無しさん

2011/07/24(日) 20:28:36.78

C++をなんだと思ってるんだ

0102デフォルトの名無しさん

2011/07/24(日) 20:43:49.16

>>99
管理して欲しいっていうか、管理していないからただのシンタックスシュガーだって >>98 は書いてるだけだろ。
シンタックスシュガーが悪いってわけじゃないが、結局は何のシンタックスシュガーなのかをわかってないと
メモリ管理で躓くことになる。 lambda は C++ 的には無理のある構文だと思うんだよなー。

0103デフォルトの名無しさん

2011/07/24(日) 23:24:07.70

ごめん何言ってんのか全然わかんない
なんでラムダがメモリの管理なんかしなきゃならないの？

0104デフォルトの名無しさん

2011/07/24(日) 23:29:40.41

>>103
>>73
std::functionだってメモリ管理はしてるだろ。

>>96
gccそのままじゃなくてもいくらでもやりようはある。
通常スタックから分離された実行可能属性付きのふたつめのスタックを用意するとか、
親関数の呼び出し時点でスタックフレーム自体をヒープに取ってしまうとか。
細部はどうでも良くて、コンパイラが直接サポートするならいくらでも効率の良い方法が
取り放題だし、そうでなくてはコンパイラが直接サポートする意味が無い。

0105デフォルトの名無しさん

2011/07/25(月) 00:13:46.46

>>103
ラムダの基底クラスとかあって、さらに動的に管理されていれば、
ラムダを返す関数を作って、
ラムダの基底クラスのポインタで受けれたりする
GCないから無理だろうけどねー

0106デフォルトの名無しさん

2011/07/25(月) 00:38:48.63

>>105
std::functionで受ければいいじゃん

0107デフォルトの名無しさん

2011/07/25(月) 00:42:57.49

意味わかんないんだけど
シグネチャの異なるラムダを同じ変数に格納出来たら呼び出しが静的に解決できないから論外だし
同じシグネチャで異なるキャプチャのラムダは当然同じstd::functionで受け取れるようになってて
つまるところ一種のスマポとして働いてるわけでメモリは管理されてるしむしろこれ以上何を管理して欲しいのか分からん
おまいさんが言うところの「メモリ管理」ってのは何を指してるんだ

0108デフォルトの名無しさん

2011/07/25(月) 01:23:52.12

本当についてきてるか？
GCなりスタックなりを上手く使えば「std::functionにローカル変数への参照をひとつひとつ持った関数オブジェクトを格納する」よりもっと効率のいいやり方があるって話だろ

0109デフォルトの名無しさん

2011/07/25(月) 01:27:02.19

ＧＣがある時点で効率がどうたらとか…

0110デフォルトの名無しさん

2011/07/25(月) 01:27:57.85

もしかして > std::functionは「メンバ変数として」キャプチャ情報を持っていると思っている

0111デフォルトの名無しさん

2011/07/25(月) 01:34:54.81

効率上げるためにGCを導入とか意味不明なんですが

0112デフォルトの名無しさん

2011/07/25(月) 01:52:31.43

>>110
いやそれは流石に無理やり相手が勘違いしてることにしたいとしか思えん

GCは、もしGC環境下ならの仮定の話だろ

0113デフォルトの名無しさん

2011/07/25(月) 01:52:53.50

GCGC言ってる人は
参照キャプチャする場合の話をしてるのか、コピーキャプチャする場合の話をしてるのか
そこからして最早分からなくなってきた。
俺は後者の話をしているものだとばかり思っていたのだが。

0114デフォルトの名無しさん

2011/07/25(月) 01:56:59.33

>>112
「ローカル変数への参照をひとつひとつ」とか言ってるのでそのレベルから勘違いしている可能性は高いと思うぞ

0115デフォルトの名無しさん

2011/07/25(月) 01:57:31.14

正解は「相手が2人いる」だから……。勝手に意見を含めて代弁したりした部分は混乱させたかな、すまん。
俺はどっちかと言えばスタック操作派のほう。

0116デフォルトの名無しさん

2011/07/25(月) 02:04:34.34

参照キャプチャする場合なら、
C++の関数オブジェクトはネストされたスタックポインタをメンバに記録しておけるからわざわざトランポリンとかする必要もない。
コピーキャプチャの場合なら、
どのみちコピーは必要なんだからメモリ確保してそこにコピーしてstd::function自体がスマポとして振る舞えばいい。

GCの出番は無いと思うんだが。

0117デフォルトの名無しさん

2011/07/25(月) 02:31:26.75

GCがあるならスタックフレーム自体をヒープに確保して放置でコピー一切不要とかもありだけどな一応

0118デフォルトの名無しさん

2011/07/25(月) 02:36:13.55

ラムダのコピーがちょこっとだけ早くなる代わりにそれ以外が悪夢のように遅くなるな

0119デフォルトの名無しさん

2011/07/25(月) 02:42:00.62

そこはそれ、関数内で使われてるラムダをどっかに持ちだそうとしてる状況でのみそうするとか、いくらかやりようが

0120デフォルトの名無しさん

2011/07/25(月) 03:02:45.98

1度でもGCを許すなら全てGCにしてしまった方がまし。
それが許されない状況があるからC++を使ってるわけなんだけど。

0121デフォルトの名無しさん

2011/07/25(月) 06:17:14.12

別の機能でも聞く話だな

0122デフォルトの名無しさん

2011/07/25(月) 11:27:48.23

>>120
そしてそう思わない人たちがObjective-C(++)を改築してる。
方向が違いすぎて相容れない。
Blocksは@Appleだけで幸せにやっていくと思われ

0123デフォルトの名無しさん

2011/07/25(月) 20:50:00.82

C++って何でシンボルを扱う機能が無いんだろうな。
時々無性に欲しくなる。

Holder<InterfaceA,MethodA> objectA;
Holder<InterfaceB,MethodB> objectB;
object.MethodA();
object.MethodB();
//MethodA,MethodBは引数で渡された名前が付いてるだけで同じ物。

0124デフォルトの名無しさん

2011/07/25(月) 20:54:53.71

objectってのは何クラスなの?

0125デフォルトの名無しさん

2011/07/25(月) 21:03:59.39

ごめん。objectAとobjectBね。
AとB書き忘れた。

0126デフォルトの名無しさん

2011/07/25(月) 21:07:19.66

何が呼び出されるの?

0127デフォルトの名無しさん

2011/07/25(月) 21:09:08.95

何を言いたいのかよく分からんな

0128デフォルトの名無しさん

2011/07/25(月) 21:27:07.32

こうしたいんじゃね？
template<typename T, funcname F> struct Holder { void F(){} };

0129デフォルトの名無しさん

2011/07/25(月) 21:36:11.73

>>128
そんな感じ。要するにメンバー変数とかメンバー関数の名前をテンプレート引数で指定するって事。

0130デフォルトの名無しさん

2011/07/25(月) 22:40:38.07

そういうシグネチャの違いは、コンセプトマップで吸収される予定だった。

0131デフォルトの名無しさん

2011/07/25(月) 23:43:11.63

グルーコードとは違うことを言っていると思われる。
なんであるかはよく分からないが。

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

こんな感じなのだろうか…
staticに決まらなくていいならいろいろやり方あるのがC++だが。

0132デフォルトの名無しさん

2011/07/26(火) 00:14:20.62

>>128
それで嬉しくなる使い方ってのがいまいち想像できんなぁ

0133デフォルトの名無しさん

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;
}

0134デフォルトの名無しさん

2011/07/26(火) 14:59:14.28

返り値の自動推定は導入されなかったの？

0135デフォルトの名無しさん

2011/07/26(火) 15:07:35.98

decltype??

0136デフォルトの名無しさん

2011/07/26(火) 16:49:00.57

>>134
lambdaだけ。

0137デフォルトの名無しさん

2011/07/26(火) 17:41:31.22

ランバダ！ランバダ！

0138デフォルトの名無しさん

2011/07/26(火) 17:42:31.42

>>133
特殊化の恩恵が受けられないけどね。

0139デフォルトの名無しさん

2011/07/26(火) 20:03:25.00

メンバ関数ポインタでいいんじゃないの？

0140デフォルトの名無しさん

2011/07/26(火) 20:33:06.73

何もかもマクロでOK

0141デフォルトの名無しさん

2011/07/26(火) 20:37:52.30

>>138
templateと組み合わせればいいよね。
俺もdecltypeがない時代にはよく作ってた。

0142デフォルトの名無しさん

2011/07/26(火) 23:37:40.10

本の虫の人のユーザー定義リテラル嫌いは異常

0143デフォルトの名無しさん

2011/07/26(火) 23:58:24.60

今回の策定には予約語の名前空間とかって全く出なかったの？
予約語は広域名前空間の所属って事にしとけば、コンテキスト依存とか
作らずに済んで今後のキーワード追加が楽になっただろうに。

0144デフォルトの名無しさん

2011/07/27(水) 00:04:04.94

それはそれでただでさえ死んでるlexerがハーデスに魂を売って攻めてくる勢いになるぞ……

0145デフォルトの名無しさん

2011/07/27(水) 00:05:56.19

>>143
そのやり方だと、広域でない名前空間に予約語を名前として登録できてしまうが?

0146デフォルトの名無しさん

2011/07/27(水) 00:09:07.26

名前空間ごとに予約語の意味が変わるとか素敵やん

0147デフォルトの名無しさん

2011/07/27(水) 00:16:07.70

Lisp 系言語だとそういうの有るよな。

0148デフォルトの名無しさん

2011/07/27(水) 00:17:48.75

>>145
使いもしないexportとかに延々と予約語として居座られてるよりましだろ。
import(),export()メンバーとか素敵やん。

0149デフォルトの名無しさん

2011/07/27(水) 00:45:56.40

使われてない予約語があるより、
名前の意味が変わってしまうほうがましか…
さすが思い付き君w

0150デフォルトの名無しさん

2011/07/27(水) 02:04:45.59

auto「・・・」

0151デフォルトの名無しさん

2011/07/27(水) 02:37:15.17

予約語namespaceを上書きして詰む言語とか面白いな

0152デフォルトの名無しさん

2011/07/27(水) 06:04:59.54

Forthの仲間入りできるなんて素敵やん

0153デフォルトの名無しさん

2011/07/27(水) 11:25:20.82

なんで本の虫なんていう名前にしたのだろうね。
自分は本を沢山読むことを誇りにしているからなのかもね。

0154デフォルトの名無しさん

2011/07/27(水) 12:06:44.07

>>153
そんな話はマ板でやれば?

0155デフォルトの名無しさん

2011/07/27(水) 12:56:50.21

じゃあ俺はエロ本の虫にするわ

0156デフォルトの名無しさん

2011/07/27(水) 13:26:51.26

g++ にc++0x拡張オプションで使えるのって
autoぐらい？

0157デフォルトの名無しさん

2011/07/27(水) 13:32:26.39

>>156
GCCか？ここ見ろ。
ttp://gcc.gnu.org/gcc-4.6/cxx0x_status.html

0158デフォルトの名無しさん

2011/07/27(水) 13:43:00.87

decltype復活してほしいなあ

0159デフォルトの名無しさん

2011/07/28(木) 11:33:12.80

boost::shared_ptrは出来損ない
stdに入れた意味が分からない

0160デフォルトの名無しさん

2011/07/28(木) 12:01:35.24

どうせならintrusive_ptrが欲しかったなぁと思ったらtr2には入るんだっけ?
shared_ptr使うくらいなら作るよね

0161デフォルトの名無しさん

2011/07/28(木) 13:03:29.86

shared_ptrは機能と性能で丁度いいところ。出来損ないなんかなじゃない。

0162デフォルトの名無しさん

2011/07/28(木) 13:15:12.63

http://flyingfrogblog.blogspot.com/2011/01/boosts-sharedptr-up-to-10-slower-than.html

0163デフォルトの名無しさん

2011/07/28(木) 14:47:15.73

動的削除とスレッド対応は機能を分離するべきだった
要らんときにまで無駄なコストが掛かる

0164デフォルトの名無しさん

2011/07/28(木) 15:56:50.78

それは実装の問題であってshared_ptrの仕様の問題じゃない。

0165デフォルトの名無しさん

2011/07/28(木) 16:42:30.78

仕様の問題だろ

0166デフォルトの名無しさん

2011/07/28(木) 17:58:21.65

boostのはコンパイル時のコンフィグでスレッド対応無効に出来る。

0167デフォルトの名無しさん

2011/07/28(木) 18:54:44.40

標準ライブラリとしての shared_ptr は可用性を優先したということなんじゃないかな
コンパイラがその使用を強制する訳ではないし
必要で可能ならBoehm GCとかを使う自由は常に残されてる訳で

0168デフォルトの名無しさん

2011/07/28(木) 19:40:46.33

intrusive_ptr をキーワード消費してでも言語レベルで実装すれば全て解決
shared_ptr はライブラリでOK

0169デフォルトの名無しさん

2011/07/28(木) 23:27:13.79

intrusive_ptrはintrusiveっていう乱暴な形容詞のせいで損してると思う

0170デフォルトの名無しさん

2011/07/29(金) 03:33:44.56

確かにintrusive_ptrは言語レベルで有って良い機能だよな

0171デフォルトの名無しさん

2011/07/29(金) 04:45:31.46

そうかそうか

0172デフォルトの名無しさん

2011/07/29(金) 07:48:15.82

ねーよ

0173デフォルトの名無しさん

2011/07/29(金) 07:48:40.86

>>170
ライブラリのままでもいいような……
いまのライブラリ形式と比べてなにかいいことあるか？

0174デフォルトの名無しさん

2011/07/29(金) 08:03:14.35

>>173
コンパイラでインライン展開された時に最適化できる余地が増えるかも

0175デフォルトの名無しさん

2011/07/29(金) 11:28:03.55

あほらし

0176デフォルトの名無しさん

2011/07/29(金) 21:57:50.47

vtbl埋め込めるなら参照カウンタだって埋め込めるはず

0177デフォルトの名無しさん

2011/07/29(金) 22:09:14.59

え？参照カウンタ内蔵？？ユーザーオブジェクトがカウンタ持ってるのを融通するポインタじゃないの？

0178デフォルトの名無しさん

2011/07/30(土) 00:06:48.85

どこで死ぬか判らんのにポインタに埋めてどーすんだよ
それならshared_ptrで十分じゃん

0179デフォルトの名無しさん

2011/07/30(土) 07:05:31.15

constみたいな記述でいいよね
実体や生ポでこさえたオブジェクトにはカウンタ付けない、カウンタは見えない触れない、生ポ→intrusiveは不可、循環参照は「知らんshared_ptr使え」で

A*intrusive a;

0180デフォルトの名無しさん

2011/07/30(土) 07:49:46.44

shared_ptrも循環参照は・・・

0181デフォルトの名無しさん

2011/07/30(土) 07:50:29.01

weak_ptr使えだな

0182デフォルトの名無しさん

2011/07/30(土) 15:27:33.64

何がやりたいのかなんとなくわかった
intrusive をつけると自動的に参照カウンタを添加してくれる機能か

それってshared_ptrなんじゃ……

0183デフォルトの名無しさん

2011/07/30(土) 15:45:52.26

shared_ptrは非効率的に自動的にカウンタを付加してくれる機能
組み込みは効率的に以下同文ってことを言いたいんだろう

0184デフォルトの名無しさん

2011/07/30(土) 16:30:24.98

make_shared で解決？

0185デフォルトの名無しさん

2011/07/30(土) 16:33:49.32

機能選べればもっとマシになるんだがなぁ

0186デフォルトの名無しさん

2011/07/30(土) 16:40:48.33

選択的にオンオフが出来て、コンパイラがそれを有効活用出来ればいいけど。

0187デフォルトの名無しさん

2011/07/30(土) 16:49:03.89

>>185 選べたとして、削りたい機能って何？何のため？

0188デフォルトの名無しさん

2011/07/30(土) 16:56:11.70

メジャーな部分だと動的デリータとかマルチタスク対応だな
使ってない時でもコスト払うのはばからしい

0189デフォルトの名無しさん

2011/07/30(土) 17:07:26.24

>>187
>>185じゃないけどマルチスレッドとデリータだろうな
影響の大きさはともかく、
前者はカウンタの増減の実行速度に
後者はshared_ptrのサイズに影響する

これらをポリシー化すればもうちょいマシになると思うんだけどどうだろう
カウンタとデリータの確保は確かプ－ルから取ってるからこれ以上効率化するのは難しいだろうし

0190デフォルトの名無しさん

2011/07/30(土) 19:09:48.45

ばかばっか

0191デフォルトの名無しさん

2011/07/30(土) 19:15:01.31

うむ。>>190とかまじ馬鹿だよな

0192デフォルトの名無しさん

2011/07/30(土) 21:43:06.28

>>188
ソース中で使わなきゃ無駄に動かないだろ。
例外と同じ。

0193デフォルトの名無しさん

2011/07/30(土) 21:47:11.54

デリータはポインタ所有権持った瞬間に生成されるから使わないとか無理
コピーやら代入やらもマルチタスク対応してんのにコレ使わなかったら共有ポインタの意義ゼロじゃねーか
なんか書き込みたい時はちゃんと少しは考えてからにしてくれ

0194デフォルトの名無しさん

2011/07/30(土) 23:10:18.82

どうやったら使わずに済むだろうかと悩んでしまったw

0195デフォルトの名無しさん

2011/07/31(日) 16:28:37.77

intrusive_ptrが言語レベルで実装されればscoped_ptrやauto_ptrもお役御免に出来るな
auto_ptrの破壊コピも解消されて可用範囲広がるし

0196デフォルトの名無しさん

2011/07/31(日) 16:42:27.33

普通のポインタとどう共存するつもりかい

0197デフォルトの名無しさん

2011/07/31(日) 17:22:20.44

ポインタ演算実行時に型情報を確認する行程を挟む負担くらいだと思うよ
条件の無い代入やconstポインタ等コンパイル時で有る程度決定できるだろうし

0198デフォルトの名無しさん

2011/07/31(日) 17:42:59.90

パフォーマンス重視するならちゃんと設計して生ポかユニポで話はおしまいなんですけどね
パフォーマンスを気にしてもしゃーないところを適当に済ませる分にはシェアポは優秀

0199デフォルトの名無しさん

2011/07/31(日) 18:12:37.28

普通のポインタに代入した場合とか

0200デフォルトの名無しさん

2011/07/31(日) 18:24:24.03

マーク＆スイープ方式のGCライブラリないの？

0201デフォルトの名無しさん

2011/07/31(日) 19:32:36.20

boost::noncopyable が継承するとコピーできなくなるように、
継承すると一時オブジェクトのみ作れなくなるようなクラスって作れませんか?

0202デフォルトの名無しさん

2011/07/31(日) 20:07:37.99

コンストラクタをプライベートとかにしてstaticメソッドでnewして
ポインタ返すようにすれば0x関係ないな

0203デフォルトの名無しさん

2011/07/31(日) 23:02:32.74

一時オブジェクトは作れないけどスタックには置きたいとか？
ならどうやっても無理

0204デフォルトの名無しさん

2011/08/01(月) 03:27:13.50

ですよねー。

0205デフォルトの名無しさん

2011/08/01(月) 03:28:16.26

ありがとうございました。(間違って途中で送ってしまいました)

0206デフォルトの名無しさん

2011/08/06(土) 00:05:26.32

久々にmailing来てるな
ちょっとだけだけど

0207デフォルトの名無しさん

2011/08/06(土) 00:11:13.61

>>206
Sun ONE StdioのClamageさん、Oracleに留まっているのか。

0208デフォルトの名無しさん

2011/08/06(土) 16:26:32.47

最適化関連で新規導入されたのはないの？

0209デフォルトの名無しさん

2011/08/06(土) 16:28:50.23

constexprとか？

0210デフォルトの名無しさん

2011/08/06(土) 18:17:18.91

こういう質問ってどこまでを現行と認識してるのかがわからんｗｗ

0211デフォルトの名無しさん

2011/08/06(土) 20:16:21.41

03だろ常識的に

0212デフォルトの名無しさん

2011/08/07(日) 00:42:42.12

>>176
カウンタはvtblじゃなくてヒープのメモリ管理領域を拡張するかなんかして埋め込む形になると思うわ
「生ポの代入を認めず」になれば判別はコンパイルタイムに行えるから

一般的じゃないメモリモデルマシンの場合はどうなるか知らんけど

0213デフォルトの名無しさん

2011/08/07(日) 03:01:47.97

>>212
> 「生ポの代入を認めず」になれば判別はコンパイルタイムに行えるから

研究レベルでも行える時がたまにあるレベルです。

0214デフォルトの名無しさん

2011/08/07(日) 04:06:46.78

Automatic Reference Counting

0215デフォルトの名無しさん

2011/08/08(月) 13:46:33.79

llvm になかなか欲しい機能がとりこまれない
lambdaとか
llvmって素人がコードの投稿できるものなの？

0216デフォルトの名無しさん

2011/08/08(月) 14:09:03.04

俺の欲しい機能がないからという理由で、lambdaをちょちょいと実装してパッチ送る「素人」か。

0217デフォルトの名無しさん

2011/08/08(月) 14:14:21.16

llvm/clangコードリーディングやりたいな

0218デフォルトの名無しさん

2011/08/08(月) 18:00:07.14

llvmにlambdaはいらんだろ。
Clangの間違いか?
とりあえず開発者メーリングリスト読めよ。

0219デフォルトの名無しさん

2011/08/08(月) 18:36:28.73

>>216
おっとApple社の悪口はそこまでだ

0220デフォルトの名無しさん

2011/08/08(月) 18:59:29.06

ClangにはBlocksが入るんだからそれを使えばいい

0221デフォルトの名無しさん

2011/08/08(月) 19:24:18.90

お断りします

0222デフォルトの名無しさん

2011/08/08(月) 20:12:18.78

>>220
いやむしろBlocksがそれじゃねという……

0223デフォルトの名無しさん

2011/08/08(月) 20:35:56.57

bitcodeレベルでラムダを表現するなにかが欲しいということだろう。
最適化が期待できるし、カスタムフェーズ挟んで関数型言語のコンパイラみたく
スタックをヒープに取るような荒業もいれられるかもしれない。

まあスレチ。

0224デフォルトの名無しさん

2011/08/10(水) 17:39:59.36

C++にもproperty ほしいな

0225デフォルトの名無しさん

2011/08/10(水) 17:41:00.73

vcのアレみたいなのか？

0226デフォルトの名無しさん

2011/08/10(水) 17:56:14.39

委員会はpropertyいらないって方向みたいだけどやっぱり欲しいよね。
自分で実装するとどうしたってthisへの（無駄な）ポインタを持たせないといけないし。

0227デフォルトの名無しさん

2011/08/10(水) 19:21:54.85

thisポインタ・・・？

0228デフォルトの名無しさん

2011/08/10(水) 19:36:17.78

こういう事でしょ？
ttp://codepad.org/vYUHccGr

0229デフォルトの名無しさん

2011/08/10(水) 19:41:49.90

そうですね　テンプレートではノーコストでプロパティを実現することは難しいような気がします
できれば規格でサポートしてもらえると嬉しいのですが…

0230デフォルトの名無しさん

2011/08/10(水) 19:46:24.20

プロパティでセッタをパブリック未満にしたいことはよくあるな。
ノーマルな関数形式はそろそろ何とかならんのかね。シンタックスシュガーでいいから。

>>228
バインド系ってこう書くのか。へぇー。

0231デフォルトの名無しさん

2011/08/10(水) 20:24:07.02

Borland C++Builderなんかではpropertyがうまく機能していたように思うんだけど、
どこも真似してないよね。なんでだろう？

0232デフォルトの名無しさん

2011/08/10(水) 20:33:57.47

getとsetだけだと+=とかできないから

0233デフォルトの名無しさん

2011/08/10(水) 20:35:51.32

両方使えば済むんじゃ

0234デフォルトの名無しさん

2011/08/10(水) 20:40:14.77

Obj-C 2.0

0235デフォルトの名無しさん

2011/08/10(水) 21:06:35.97

>>233
intとかならそれでいいけど、ユーザー定義のoperator +=があるクラスはどうする？

0236デフォルトの名無しさん

2011/08/10(水) 22:54:41.35

T tmp = get(); set( tmp += x ); はどうかな

0237デフォルトの名無しさん

2011/08/11(木) 00:16:11.07

どこまで最適化されるかだが・・・

0238デフォルトの名無しさん

2011/08/11(木) 02:19:32.97

>>236
定義がループしてるじゃねーかw

0239デフォルトの名無しさん

2011/08/11(木) 02:46:18.38

>>238
え、どこが？

0240デフォルトの名無しさん

2011/08/11(木) 03:18:43.75

適当に書いてみましたが、勘違いしてたらゴメン。
ttp://ideone.com/boEdA

0241デフォルトの名無しさん

2011/08/11(木) 07:26:50.62

#define PROP_INIT(type, name) name(this, &type::get_##name, &type::set_##name)
みたいなマクロが欲しくなるな

0242デフォルトの名無しさん

2011/08/11(木) 07:32:28.87

C++0xの機能で何かプロパティ作成に役立ちそうなものはないものか

0243デフォルトの名無しさん

2011/08/11(木) 11:42:28.55

>>240
演算子オーバーロードは全列挙したらいけそうだね。
一般メンバ関数は方法ないかな？

0244デフォルトの名無しさん

2011/08/11(木) 13:48:14.01

>>243
->をオーバーロードして実体のポインタを返すようにすればなんとか(shared_ptrとかの真似)。
ttp://ideone.com/4vi4m ... 前回のをそのまま改造したもの。一時アドレスの警告が出る。
ttp://ideone.com/24R9e ... getterでポインタを返すようにしたもの。

0245デフォルトの名無しさん

2011/08/11(木) 14:36:50.50

getterでポインタは無いなあ。自分の持ってないor一時的なオブジェクトをさも持っているように見せかけるための
プロパティなんだから、ポインタ返せるならそれこそ参照でもメンバに持ってればいいし。

->は、C++のセマンティクスとして微妙じゃね？
shared_ptrはポインタを踏襲しているから->だけど、プロパティはメンバ変数もどきだから.じゃないと整合性が

0246デフォルトの名無しさん

2011/08/11(木) 14:45:21.32

>>245
プロパティを狭く捉え過ぎでは? > さも持っているかのように

0247デフォルトの名無しさん

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; }
}

0248デフォルトの名無しさん

2011/08/11(木) 15:24:52.58

つ狭く

0249デフォルトの名無しさん

2011/08/11(木) 17:47:18.96

こういうプロパティでも凄く有用なんだけどな
private: int _left;
public:
__property int left {
get(){return _left;}
set(int n){_left=n;}
};

0250デフォルトの名無しさん

2011/08/11(木) 19:53:18.31

>>245
->だったらそのまま関数の呼び出しが自然に書けるかなと思ったんですが。
あとは()とか。http://ideone.com/cSQ3e
かなりC++0xから離れた話題が続いてしまったので、私からは以上です。
勉強になりました。ありがとうございました。

0251デフォルトの名無しさん

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) {}
};

0252デフォルトの名無しさん

2011/08/12(金) 06:08:58.93

既存のコンパイラ拡張の__propertyにラムダ突っ込んで叱られるフラグ

0253デフォルトの名無しさん

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ポインタ持たなくてもいいようになればなぁ

0254デフォルトの名無しさん

2011/08/12(金) 23:57:51.85

property だから括弧要らないとか考えるのめんどくさくないか？

0255デフォルトの名無しさん

2011/08/13(土) 02:41:47.27

データメンバーだから括弧要らないとか考えるのと一緒じゃないですか

0256デフォルトの名無しさん

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 };

0257デフォルトの名無しさん

2011/08/13(土) 04:12:03.33

もうちょっと整理してくれ

0258デフォルトの名無しさん

2011/08/13(土) 04:27:44.30

class nantoka {
struct { int value; operator... } puropati; の形は
struct 内部で変数を宣言しなければならないのと
内部で宣言した変数にしかアクセスできない制限がありまする

0259デフォルトの名無しさん

2011/08/13(土) 12:45:56.59

C++0xが満場一致で国際標準として承認されました。

0260デフォルトの名無しさん

2011/08/13(土) 14:06:36.49

そうかそうか

そうか……

0261デフォルトの名無しさん

2011/08/13(土) 16:31:39.14

bravo!

0262デフォルトの名無しさん

2011/08/13(土) 16:50:28.54

>>255
データーメンバーはprivateだから考えるまでもないし。

0263デフォルトの名無しさん

2011/08/13(土) 18:06:22.93

>>259
C++11となったようだがC++0xの「0」とは何だったのか

0264デフォルトの名無しさん

2011/08/13(土) 18:14:55.40

いまさらC++11って名称が普及するかなぁ。

0265デフォルトの名無しさん

2011/08/13(土) 19:42:36.34

ITTFのことだ。C++12になっても驚かない。

0266デフォルトの名無しさん

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!

0267デフォルトの名無しさん

2011/08/13(土) 21:48:54.59

>>263
0bないし0cの0と、全会で一致しております。

0268デフォルトの名無しさん

2011/08/13(土) 22:06:35.98

ようやく決まったか！
今FDIS読んでるといくつが誤植あるけど、直されてんのかね

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

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

71pの３行目も気になるんだけど、これは何が言いたいのだろうか？
pb の指す先に関わらず、&pb は OK だと思うんだけど

0269デフォルトの名無しさん

2011/08/13(土) 22:13:26.64

ユーザー定義リテラルさん大勝利ｗｗｗｗｗｗ

0270hiding

2011/08/13(土) 23:10:35.76

勝手に改名させられたあげく、退学処分になりました。

0271デフォルトの名無しさん

2011/08/13(土) 23:30:42.69

学園の人々決定ver. を書いてくれ

0272デフォルトの名無しさん

2011/08/13(土) 23:42:32.86

VCにイニシャライザリストさんがくるのかな。かなり楽しみ。

0273デフォルトの名無しさん

2011/08/14(日) 06:02:04.19

template alias があれば typename myalloc_vector<int>::type とタイプせずにすむ…＞＜

0274デフォルトの名無しさん

2011/08/14(日) 07:00:29.76

>>268
原則としてFDISは修正不可、賛否表明のみだから多分残る。
さあ今すぐDefect Reportを！

0275デフォルトの名無しさん

2011/08/14(日) 08:04:28.51

次はC++2xになるのか？

0276デフォルトの名無しさん

2011/08/14(日) 09:55:19.85

禿はC++16くらいにしたいと言っていた
ということは実際はC++20あたりだな

0277デフォルトの名無しさん

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→発行

0278デフォルトの名無しさん

2011/08/14(日) 11:59:55.47

最後は60.60ですな。

0279デフォルトの名無しさん

2011/08/14(日) 12:21:01.30

tr2ってどうなったの？

0280デフォルトの名無しさん

2011/08/14(日) 13:01:05.54

gccの<regex>サポートはまだ時間かかるのかなあ。

0281デフォルトの名無しさん

2011/08/14(日) 17:40:46.51

ﾋﾞｮｰﾝ! ｽﾎﾟｯ! ｽﾎﾟｯ!!

0282デフォルトの名無しさん

2011/08/15(月) 18:22:09.67

>>275
次はC++xxで

0283デフォルトの名無しさん

2011/08/15(月) 18:41:28.66

>>282
それ、C#の名前の由来で見掛けたようなw

0284デフォルトの名無しさん

2011/08/15(月) 18:58:28.96

当面の課題はTR2とコンセプトか

0285hiding

2011/08/15(月) 19:24:36.07

いや、C++98と同じく、一年ぐらいはおとなしくなるだろうと思う。

0286デフォルトの名無しさん

2011/08/15(月) 21:53:09.02

コンセプトを復活させて、range-based for文のADLを、さっさと投げ捨ててほしい

0287デフォルトの名無しさん

2011/08/15(月) 22:01:50.86

そういやコンセプトさんは、何が難しかったんだ？

0288hiding

2011/08/15(月) 23:05:52.37

ググれよ。
ともかく簡単に説明すると、

「空のconcept mapに意味はあるのか。concept mapは常に自動で生成されるべきだ」
という主張と
「いや、conceptは常に明示的であるべきだ。たとえシグネチャが同じでも、意味まで同じとは限らない。明示的に書かせるべきだ」
という主張がぶつかり合って、収集がつかなくなった。

0289デフォルトの名無しさん

2011/08/15(月) 23:27:21.04

>>288
なるほど。ありがと。とりあえず明示的にして、あとで省略できるようにすればよかったのにね。

0290デフォルトの名無しさん

2011/08/16(火) 12:47:41.25

conceptさんは一から設計し直しだな

0291デフォルトの名無しさん

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);} };

0292デフォルトの名無しさん

2011/08/16(火) 14:12:04.29

それだと、sort(Container& c, Comparator cmp) と
sort(Iter b, Iter e) の区別がシグネチャからは付けられなくない？

0293デフォルトの名無しさん

2011/08/16(火) 16:19:56.69

意味わかんない

0294デフォルトの名無しさん

2011/08/16(火) 17:26:54.94

>>293
禿様のありがたいお言葉を聞きなさい
ttp://cpplover.blogspot.com/2009/08/bjarne-stroustrupconcept_14.html

0295デフォルトの名無しさん

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(～}

0296hiding

2011/08/16(火) 23:37:28.13

>>291だと、単に　
T型のオブジェクト通しに適用できるoperator <があり、さらにその戻り値がboolに変換可能か？
ぐらいしか判定できない。
しかしそれは、すでに現行のテンプレートで行っているじゃないか。
そういうことができなければ、正しくコンパイルエラーになる。

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

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

0297デフォルトの名無しさん

2011/08/16(火) 23:47:26.44

禿が言ってるのは、現状のコンパイルエラーに対する不満だよな
エラーメッセージをわかりやすくするシンタックスシュガーが必要であると

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

意味的に operator < と operator >= の対称性が保たれているかどうかなんて
「テスト工程すべて」をコンパイラの機能だなんて幻想は考えてないだろ

0298デフォルトの名無しさん

2011/08/17(水) 00:00:30.83

まあaxiomは要らないと思う
あんなんコメントでいい

0299デフォルトの名無しさん

2011/08/17(水) 00:08:50.99

しかし、axiomの存在は理解できなかったな。
たとえばoperator <が大小比較を意味して、a < b　かつ b < c　ならば a < cであるとか、
その他様々の保証としてのaxiomを書いたとしても、
それを検証してくれるようなツールは、まず近い将来に登場しないと思うんだよ。
禿は、ソースコード中に仕様書を書くための機能だって言ってるけど、
提案されていたaxiomの極端に制限された文法で書くよりは
自然言語による表現力の高い文法で書いたほうがいいにきまってるだろ。

0300デフォルトの名無しさん

2011/08/17(水) 01:24:41.10

どうせ解析に使われないんなら
doxygen使えば良いじゃない、という感じ

0301デフォルトの名無しさん

2011/08/17(水) 12:57:12.10

ついに決まったのか

0302デフォルトの名無しさん

2011/08/17(水) 13:17:03.93

長い時を経て正式に決まった割に盛り上がってないな
C++最大の革新でしょ？　この温度は何？

0303デフォルトの名無しさん

2011/08/17(水) 13:19:24.71

C++はオワコンだから

0304デフォルトの名無しさん

2011/08/17(水) 13:28:37.59

もう随分前から決まったも同然だったし、
99.9%準拠のコンパイラが出るまでは特に今何か語ることもない

0305デフォルトの名無しさん

2011/08/17(水) 13:30:43.22

ここにいる人ならC++ 0x解説サイトとか作れるでしょ
そこでアフィってぼろ儲けしようという人はいないの

0306デフォルトの名無しさん

2011/08/17(水) 13:32:38.64

ぼろ儲けするほど人が来るわけない

0307デフォルトの名無しさん

2011/08/17(水) 13:46:18.05

現在と将来のC++ユーザーのほぼ全員が悶え苦しんでネットの情報にすがるわけだから
すごい数になるでしょ

0308デフォルトの名無しさん

2011/08/17(水) 13:56:49.62

つC99

0309デフォルトの名無しさん

2011/08/17(水) 14:21:44.81

別にフル機能使う人なんてまずいないし、そういう人は勝手に勉強する
企業では技術力低い人に合わせてコーディングルール作るから、知らなくても
問題ない

0310デフォルトの名無しさん

2011/08/17(水) 14:24:42.01

英語で書けば少しは儲かる可能性あるけどね。日本語じゃあ。

0311デフォルトの名無しさん

2011/08/17(水) 14:27:43.49

英語ならそういうサイト腐るほどあるだろ

0312デフォルトの名無しさん

2011/08/17(水) 14:35:02.39

C++使ってる日本人の大半の現状を見るかぎり解説とか、なぁ

0313デフォルトの名無しさん

2011/08/17(水) 14:53:10.60

初心者向けならC99のcompound literalを布教してくれたほうが嬉しいなあ
C++0xはソースは簡潔になるけど、人の書いたコードを読む時0xのほうが嬉しいってのがあまり思いつかない
せいぜい=defaultぐらい？

0314デフォルトの名無しさん

2011/08/17(水) 15:45:04.57

C++11でユーザが悶え苦しむような部分ってラムダちゃんの使い方くらいじゃね
ディープなライブラリ作成者を除けばほとんどが「何も考えなくても恩恵受けられる機能」ばかりだよ

0315デフォルトの名無しさん

2011/08/17(水) 16:00:44.07

lambda式のどこが難しいんだよ。
多分一番難しいのはムーブだろ。

0316デフォルトの名無しさん

2011/08/17(水) 16:00:56.39

いやいや読みやすさだよ。
ラムダはむしろ読みやすい方。

今までは初期化式の{}を見たらコンストラクタは呼ばれないと切って捨てれたのに、そっちも探さないといけなくなったし
range-based forだって深追いしようと思えば実際呼ばれてるbeginとend探しまわるハメになると思う

0317デフォルトの名無しさん

2011/08/17(水) 16:02:14.22

ムーブってそんなに難しいか？

0318デフォルトの名無しさん

2011/08/17(水) 16:08:09.51

難しいんで字句以外にも何度も修正されてます。

0319デフォルトの名無しさん

2011/08/17(水) 16:09:52.97

ムーブどころかコピーすら難しすぎて理解出来ないようなのが大勢プログラマー名乗ってるからなぁ

0320hiding

2011/08/17(水) 16:13:04.47

ムーブは最後の最後の土壇場になって、言語仕様に取り入れられた。
それまでは、単にrvalueリファレンスを用いるライブラリ側の取り決めでしかなかった。
でもそれじゃまずいってことで、コピーと同じく、コア言語側でも規定されるようになったんだよ。

0321デフォルトの名無しさん

2011/08/17(水) 16:13:10.92

そのぐらい知ってるわよ
ばかにしないでくれる

0322デフォルトの名無しさん

2011/08/17(水) 16:19:22.27

hidingさんの文体が本の虫っぽいけど本人ですか？

0323デフォルトの名無しさん

2011/08/17(水) 16:31:18.67

盲蛇に怖じず

0324デフォルトの名無しさん

2011/08/17(水) 17:14:21.39

>>309
> 技術力低い人に合わせて

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

>>319
やめれ、耳が腐る

0325デフォルトの名無しさん

2011/08/17(水) 17:35:53.73

じゃああんたが教育すればいいんじゃね

0326デフォルトの名無しさん

2011/08/17(水) 17:49:39.44

C++は教育コストが高すぎる

0327デフォルトの名無しさん

2011/08/17(水) 17:55:29.55

ムーブは使う側が意識する必要はあまりないような

0328デフォルトの名無しさん

2011/08/17(水) 18:30:10.43

>>326
逆だろ、今までのプログラム言語が歴史の浅い原始的で学問未満なものだった
世のため人のために役立つ知見とは元々そんなに甘くないというだけ

0329デフォルトの名無しさん

2011/08/17(水) 18:34:17.71

C++を教育するコストで
CとCommon LispとSmalltalkとHaskellを教育できる

0330デフォルトの名無しさん

2011/08/17(水) 18:35:26.60

そもそも平均以下のプログラマには何の関係ないスレだし。
通ったばかり規格のスレだから。教育とか他所行け。ドアホ。

0331デフォルトの名無しさん

2011/08/17(水) 18:42:05.88

え？いまどきC++に無様にしがみついてるプログラマが平均以下じゃない……？

0332デフォルトの名無しさん

2011/08/17(水) 18:45:14.03

同感だな
自分は平均以下でないと行間で言ってるのがすげー滑稽

0333デフォルトの名無しさん

2011/08/17(水) 19:22:08.86

お前一人でどれだけのコードがかけるんだって話。
教育コストは生産性の大きなポイント。

0334デフォルトの名無しさん

2011/08/17(水) 20:14:43.61

違うね
大きなポイントはコストではなく効果だ

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

不戦敗する奴に金かけるのは確かに無駄だ

0335デフォルトの名無しさん

2011/08/17(水) 20:16:06.09

templateでlispインタプリタ作れるまでC++を熟知するより、3Dのレンダリングエンジンを
フルスクラッチで開発できるようになる方が時間がかかると思うが。

0336デフォルトの名無しさん

2011/08/17(水) 20:33:06.14

あほか

0337デフォルトの名無しさん

2011/08/17(水) 20:35:48.36

まあ言語の勉強をするぐらいならアルゴリズムの勉強をしたほうがいいってのは正しいからなあ

0338デフォルトの名無しさん

2011/08/17(水) 20:36:51.92

axiomうんぬんは永遠に先延ばしするとして
static_assert系の仕組みの引数にprintfのformatみたいな方式でoperator有無のチェックを記述出来る様にしたらどうかな

static_assert(A,"++\(int)++\*()\*(A)","unimplemented");

0339デフォルトの名無しさん

2011/08/17(水) 20:37:07.83

モノつくれよｗ

0340デフォルトの名無しさん

2011/08/17(水) 21:39:58.60

作ったよ
http://www.mono-project.com/Main_Page

0341デフォルトの名無しさん

2011/08/17(水) 22:24:46.43

>>338
そんなのやだ
演算子の有無はconceptでチェックしたい

0342デフォルトの名無しさん

2011/08/17(水) 22:25:44.19

>>338
これじゃあかんの
sizeof((A()+1,A()-1,A()*1,A()/1))

0343デフォルトの名無しさん

2011/08/17(水) 22:29:13.34

同じフレーズを何度も書き直すのすげーいや

0344デフォルトの名無しさん

2011/08/18(木) 00:18:48.07

>>342
インクリ/デクリメントのチェックに副作用が

0345デフォルトの名無しさん

2011/08/18(木) 00:47:33.74

なんだかんだ言ってもWebKitとかChromeとかv8とか、
低レベルシステムソフトウェアはC++が全盛です。
底辺プログラマには縁のない世界。

0346デフォルトの名無しさん

2011/08/18(木) 00:56:47.19

低レベルと底辺をうまくかけたなｗ

0347デフォルトの名無しさん

2011/08/18(木) 01:02:34.63

そりゃてーへんだ

0348デフォルトの名無しさん

2011/08/18(木) 01:15:58.01

大変と底辺をうまくかけたなｗ

0349デフォルトの名無しさん

2011/08/18(木) 10:38:03.76

>>343
decltype使った末尾戻り値型もそんな感じだな
lambdaみたいに戻り値の型をreturnに書いたやつから類推して欲しかった

0350デフォルトの名無しさん

2011/08/18(木) 16:55:39.20

>>349
returnから型推定すごい欲しいなあ
OCamel使えば自動型推定はやってくれるけど

0351デフォルトの名無しさん

2011/08/18(木) 18:28:03.78

関数の定義見るまで返却値型がわからないんじゃ前方宣言もあいまいになるし
そうなると宣言だけあれば関数を呼び出せるのができなくなるだろ

0352デフォルトの名無しさん

2011/08/18(木) 18:46:06.02

includeに代わる何かをどうにかしようって話とも関係してくるようなそうでもないような

0353デフォルトの名無しさん

2011/08/18(木) 19:32:48.04

結局プロトタイプでは型推論しようがないからなぁ

0354デフォルトの名無しさん

2011/08/18(木) 23:13:16.42

型推論はなんで必要なの？
書くのが面倒ならマクロ使えばいいじゃない。

0355デフォルトの名無しさん

2011/08/18(木) 23:29:48.59

オレオレマクロは再解釈するのが面倒だから廃してほしい。

0356デフォルトの名無しさん

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; }
にできるだけでも価値はあると思うけど

まあ、構文解析難しいとか他に何か問題があれば別だが

0357デフォルトの名無しさん

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; }
とかどうする気なの

0358デフォルトの名無しさん

2011/08/19(金) 07:53:19.72

次のスレタイどうなるの
C++11 14？

0359デフォルトの名無しさん

2011/08/19(金) 08:13:42.72

それは規格書が出版されてからでいいんでない?
出版が来年にずれ込んだら C++12 になるのだし

0360デフォルトの名無しさん

2011/08/19(金) 09:13:11.15

C++0xで定着しちゃったからなぁ・・・

0361デフォルトの名無しさん

2011/08/19(金) 10:02:23.47

>>357
template <typename T> void f(T a, T b);
f(a+b, NULL);
のTと同じ型が類推される、と定義すればいい。
型が合わなければエラー。

0362デフォルトの名無しさん

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に矛盾がなければ戻り値の型が決まり、矛盾があればエラー、とか。

0363デフォルトの名無しさん

2011/08/19(金) 10:14:52.94

>>362
ﾜｹﾜｶﾗﾝ

0364デフォルトの名無しさん

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; }

とか。

0365デフォルトの名無しさん

2011/08/19(金) 18:53:11.11

>>358 c++1x 14 でいいんでね？

0366デフォルトの名無しさん

2011/08/19(金) 18:58:16.53

プロトタイプ宣言の話と似てくるが再帰呼び出しが(も)できない

0367デフォルトの名無しさん

2011/08/19(金) 19:20:37.73

C++1xだと次の仮称になる可能性があって紛らわしい

0368デフォルトの名無しさん

2011/08/19(金) 19:40:07.41

>>367
ないない。

0369デフォルトの名無しさん

2011/08/19(金) 23:15:12.74

次は素直にC++xxにするんじゃない？
その次はしらんけど。

0370デフォルトの名無しさん

2011/08/19(金) 23:36:24.16

シムシティ路線でC++3000

0371デフォルトの名無しさん

2011/08/21(日) 02:00:21.61

次期concept早く来ないかな。
concept = constraint + axiom
って感じらしいが。

0372デフォルトの名無しさん

2011/08/21(日) 09:07:20.29

axiomはｲﾗﾈ

0373デフォルトの名無しさん

2011/08/21(日) 10:46:54.11

個人的に理解不能なものを拒絶してしまうのはよくあること

0374デフォルトの名無しさん

2011/08/21(日) 12:09:26.37

axiomの存在価値を理解できるか？
英語でいいからコメント書いてくれてる方が分かりやすい

0375デフォルトの名無しさん

2011/08/21(日) 12:47:19.85

ペーパーで解説無かった？

0376デフォルトの名無しさん

2011/08/21(日) 13:00:28.25

concept さんが在学していたころのドラフトを持ってないからよくわからないんだけど
axiom って最適化に使ってもいいみたいだし
それなら意味があるのでは？

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

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

という感じでやってくれるなら歓迎。

0377デフォルトの名無しさん

2011/08/21(日) 13:13:55.53

最適化ならpragmaでいいじゃん。

0378376

2011/08/21(日) 13:48:22.98

N2887 を読んだら、いきなり動機で
「axiom は、最適化に役立てることは動機ではない」といきなり否定されてるな…。

なら確かにゴミだな。

0379デフォルトの名無しさん

2011/08/21(日) 14:54:42.82

親クラスから、孫クラスへ子クラスでコンストラクターを作らず、
コンストラクターを呼び出させる事ってC++0xじゃないと無理なんかね？

0380デフォルトの名無しさん

2011/08/21(日) 15:42:18.63

struct Base{
Base(){}
};
struct Derived{
Derived()=delete;
};
struct Grandderived{
Grandderived(): Base::Base(){}
};
こういうこと？
0xでも無理だろ

0381デフォルトの名無しさん

2011/08/21(日) 16:30:34.91

0xなら子のコンストラクターを一切書かないことを条件に、
親クラスのコンストラクターを子に引き継がせることができる。

0382hiding

2011/08/21(日) 16:44:22.09

>>381
継承コンストラクターは、コンストラクターが無いわけじゃない。
継承コンストラクターは、基本クラスのコンストラクターと同じシグネチャで、
実引数をそのまま渡すコンストラクターを、自動的に宣言するだけだぞ。

「コンストラクターを作らず」といったら、>>380だ。

0383デフォルトの名無しさん

2011/08/21(日) 16:54:40.00

c++0xは完全にマスターした
早くc++1x来い

0384デフォルトの名無しさん

2011/08/21(日) 17:28:26.01

>>382
理屈がどうであれ実質変わらんがな。
暗黙で作られるつったってコンパイラはどうせvtableだけ置き換えて
親クラスのコンストラクターそのまま使うんだから。

>>382がもし理屈上だけでなく明確な実装まで影響する話だとしたら、
0xの継承コンストラクターって、オブジェクトの値渡しをしたら
子のコンストラクターで1回、親のコンストラクターで2回目の
コピーないしムーブコンストラクターが呼ばれるのか？

0385デフォルトの名無しさん

2011/08/21(日) 17:34:48.29

axiomはスキーマです。

0386デフォルトの名無しさん

2011/08/21(日) 17:40:50.32

スキマです。。。
隙間です。。。
ヒロシです。。。

0387デフォルトの名無しさん

2011/08/21(日) 18:29:33.47

>>384
12.9 の第8段落

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

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

で、わざわざそんな配慮をもって記述されているということは
T が値渡しならもちろん二回コピーされるってこと。

0388デフォルトの名無しさん

2011/08/21(日) 18:35:52.55

>>387
例と書いてあるけどそれは一例じゃなく実装義務なのか？
RVOのように省いちゃいかんのか？

0389デフォルトの名無しさん

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 のようなユーザー定義の
　コンストラクタと同様の動作をする。

0390hiding

2011/08/22(月) 04:17:37.21

>>384
実装の話がしたいならスレ違いだ。

「この関数呼び出しは実装ではインライン展開されるから、規格上でも関数呼び出しなんて発生しない( ｰ`дｰ´)ｷﾘｯ」

0391デフォルトの名無しさん

2011/08/22(月) 12:45:22.76

もうOCamelのsubsetまるまる持ってきちゃえばいいのに
進化の方向同じなんだから
そうすればOCamelのライブラリも使いまわせて最高

0392デフォルトの名無しさん

2011/08/22(月) 15:38:14.94

肝心の言語の名前を間違えるくらいの認識で
進化の方向が同じなんて判断がよくできるね。

0393デフォルトの名無しさん

2011/08/22(月) 20:30:54.88

>>390
規格が許すか許さないかの話なんだからべつにいいんじゃね。

0394デフォルトの名無しさん

2011/08/22(月) 21:32:42.21

実装を見据えなかったexportがどうなったかを考えると
実装に言及するのも必要だと思う

0395デフォルトの名無しさん

2011/08/23(火) 00:33:53.30

OCamlのことなんかなあ。
同じ方向に見えるなら全然勉強足りないから初心者スレで修行を。

0396デフォルトの名無しさん

2011/08/23(火) 11:38:51.33

ガーベジコレクタのないOCaml = C++

0397デフォルトの名無しさん

2011/08/23(火) 12:15:17.83

名前解決に対する考え方すら全く違う。

0398デフォルトの名無しさん

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 だけは持ってるけど、これは互換性のためだろうか。

0399デフォルトの名無しさん

2011/08/25(木) 19:01:59.72

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2946.pdf
たぶんこのへんに書いてある

0400デフォルトの名無しさん

2011/08/25(木) 22:54:36.16

>>399 ﾄﾝ

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

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

というわけね。

0401デフォルトの名無しさん

2011/08/26(金) 13:42:06.91

いきてる?

0402デフォルトの名無しさん

2011/08/26(金) 20:00:40.51

スマートポインタでも何でも良くなったのであれば
ますますreference必要じゃね？

0403デフォルトの名無しさん

2011/08/26(金) 20:30:35.23

C++ではスマートポインタは作れるけどスマートリファレンスは作れないんだよ

0404デフォルトの名無しさん

2011/08/26(金) 20:45:20.70

weak_refer<T>が必要になる様なうっかり遣ってしまいそうな事てどんなコード？
子スレッドから孫スレッド作って子スレッド消滅くらいしか思いつかんわ

0405デフォルトの名無しさん

2011/08/26(金) 21:49:54.23

>>402
pointer側は関係ないんだよ
referenceがvalue_type&しかないのが問題

0406デフォルトの名無しさん

2011/08/27(土) 03:13:03.15

そっか
そりゃそうだな
まあreferenceなんざ、value_type&のみでいいんじゃね？

0407デフォルトの名無しさん

2011/08/27(土) 09:06:13.47

C++03 と C++11 の互換性
ttp://d.hatena.ne.jp/melpon/20110826/1314343549

0408デフォルトの名無しさん

2011/08/28(日) 23:46:50.31

>>406
昔のx86みたいに、farポインタnearポインタの区別のある世界なら、
referenceにもfarとnearの区別が欲しくなるのではないかと思う。
そんなところにC++11がやってくるかどうかは別として。

0409デフォルトの名無しさん

2011/08/29(月) 08:16:57.84

far/near の違いは pointer のほうに持たせるのが自然じゃないの？ allocator の話だろ?

allocator はたとえば vector<T, allocator<T>>::push_back(val) の val　を
far の参照で受けるべきか near かなんて責任を負わないと思うよ。

0410デフォルトの名無しさん

2011/08/29(月) 22:14:36.37

C++相談室を見てて思ったんだけど、イテレータコンセプトってどうして流れたの？
そのまま Boost のイテレータコンセプトを採用するって聞いたけど。。

経緯を知っている方、もしいれば教えて下さい

0411デフォルトの名無しさん

2011/08/30(火) 12:47:12.82

llvm　clangは早く全部の機能を実装してくれ
iphone開発で使いたいんじゃ

0412デフォルトの名無しさん

2011/08/30(火) 17:37:03.79

<iterator_concepts>はあったけどコンセプト削除とともに消えた

0413デフォルトの名無しさん

2011/08/30(火) 18:22:12.50

iphoneならBlocksさんが全部何とかしてくれるよ

0414デフォルトの名無しさん

2011/08/30(火) 21:53:23.55

>>411さんの要望はIndiana版conceptの彼が叶えてくれるだろう。

0415デフォルトの名無しさん

2011/08/31(水) 20:58:42.90

>>411
03の機能は完全なんだからいいだろ。
11での開発を今から始めるのはバカすぎる。
あと4年は待て。

0416デフォルトの名無しさん

2011/09/01(木) 18:57:37.59

せめてlambdaだけでも実装されないものかのお

0417デフォルトの名無しさん

2011/09/01(木) 20:28:20.92

されてもどうせ規格非準拠だぞ。
3,4年たったら規格準拠になって今書いたコードが
腐るかもしれん。

0418デフォルトの名無しさん

2011/09/01(木) 22:30:59.73

Blocksが普及するまで政治的都合でlambdaは実装されないテロ

0419デフォルトの名無しさん

2011/09/01(木) 23:24:29.56

３・４年も価値のあるコードなんてかけないだろｗ

0420デフォルトの名無しさん

2011/09/01(木) 23:31:49.76

他の言語ならともかくC++だったらあるだろ。
うちの会社のライブラリなんて未だVC6.0で書かれたものが生き残ってんだぞ。

0421デフォルトの名無しさん

2011/09/01(木) 23:53:09.13

簡単に書き直せるだろ

0422デフォルトの名無しさん

2011/09/02(金) 00:01:43.90

どうやって？

0423デフォルトの名無しさん

2011/09/02(金) 00:08:24.49

どうせ書き直すならboost.lambdaでも使ってたほうがマシ

0424デフォルトの名無しさん

2011/09/02(金) 00:17:32.56

>>421
そもそも、VCの処理系依存は、スコープすら違うんだぞ。
しかもそれが、50万行以上。

0425デフォルトの名無しさん

2011/09/02(金) 00:50:48.81

つかC++でラムダとか頭悪いだろ

0426デフォルトの名無しさん

2011/09/02(金) 00:59:23.07

ラムダさん超便利なのに。。。

0427デフォルトの名無しさん

2011/09/02(金) 11:13:20.08

てかCでラムダよりはまだよほどまし

0428デフォルトの名無しさん

2011/09/02(金) 12:25:40.96

>>418
あの人たちはCLang行ってしまったから、
g++は影響受けないと思われます。

0429デフォルトの名無しさん

2011/09/02(金) 18:24:42.24

>>425
ラムダまでいかないにしても、関数内関数が使えるとすごい嬉しいな

0430デフォルトの名無しさん

2011/09/02(金) 19:48:07.36

というか関数内ではret foo(args){body}を
auto foo=[&](args)->ret{body};と見做すようにすればいいだけなのになんで0xでも関数内関数出来ないの？

0431デフォルトの名無しさん

2011/09/02(金) 19:52:31.77

>>430
関数内でラムダ宣言してautoでキャプチャすればことたりるからじゃね？

0432デフォルトの名無しさん

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;
}

0433デフォルトの名無しさん

2011/09/02(金) 21:37:28.44

ラムダの括弧がださいって話だろ

0434デフォルトの名無しさん

2011/09/02(金) 21:39:28.83

リンゴよりマシだろ

0435デフォルトの名無しさん

2011/09/02(金) 22:26:22.32

見た目が問題なのはautoでない時の返値だろ。decltypeの問題とはいえあれはきもい。
括弧は別に何とも思わんしどちらかというと綺麗な部類だと思うが。

0436デフォルトの名無しさん

2011/09/02(金) 22:51:21.90

>>430
関数内関数を導入するよりも、関数の書き方自体を　[] f() -> ret { ,,, } にシフトしていく
方針のつもりでいたんだと予想。
そうすればラムダの記法がそのまま関数内関数になる。

0437デフォルトの名無しさん

2011/09/02(金) 23:10:11.89

>>436 だけど lambda を引数にとる lambda を返す lambda を...
って，シグネチャ書く気力おきねぇw

0438デフォルトの名無しさん

2011/09/02(金) 23:32:14.75

>>437
関数ポインタは今のままの書き方でいいってことで…。

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

そういうのを受け取ったり返したりするのは、
template <class Lambda> と書く以上に複雑にはならない。

0439デフォルトの名無しさん

2011/09/03(土) 16:39:11.97

>>430
そんな差もないし別にlambdaでいいじゃない
それじゃキャプチャも自由にできないし

0440デフォルトの名無しさん

2011/09/03(土) 16:44:34.74

>>437
そんな複雑なことかいな？

auto bar = [](std::function<int()> f) {
　　return [=]{ return f(); };
};

0441デフォルトの名無しさん

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);

0442デフォルトの名無しさん

2011/09/03(土) 17:28:43.53

文法はキモいけど
キャプチャは重要だと思うよ

0443デフォルトの名無しさん

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 で確定でいいんだよね？

0444デフォルトの名無しさん

2011/09/03(土) 21:26:22.42

C++って俺の考えた最強言語ごっこできもい

0445デフォルトの名無しさん

2011/09/03(土) 21:27:09.83

キモいけど感じちゃう

0446デフォルトの名無しさん

2011/09/03(土) 21:32:00.54

他人のオナニーじゃ感じないだろｗ

0447デフォルトの名無しさん

2011/09/03(土) 22:05:46.87

カワイイおにゃのこのオナニーなら感じちゃうかもしれないけどヒゲオッサンのオナニーじゃなぁ。

0448デフォルトの名無しさん

2011/09/03(土) 23:09:54.90

>>443
半年もまだ何やる事が残ってんの？

0449デフォルトの名無しさん

2011/09/03(土) 23:22:59.89

>>430
GCCみたいな関数内関数を勝手に実装しやがった処理系と干渉するから。

0450デフォルトの名無しさん

2011/09/03(土) 23:27:00.94

別に干渉はしないだろっつーか、gccの関数内関数は実はC++では使えない。Cモードのみ。

0451デフォルトの名無しさん

2011/09/03(土) 23:28:59.45

>>450
※みたいな

0452デフォルトの名無しさん

2011/09/03(土) 23:41:51.39

gccは過去にも独自拡張してるけど、
新しい規格により不必要になったり、
バッティングしたら削除してるよ。

0453デフォルトの名無しさん

2011/09/04(日) 08:29:07.54

func(){

}

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

func()
{

}

こう書くように。

0454デフォルトの名無しさん

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

0455デフォルトの名無しさん

2011/09/04(日) 08:59:26.11

>>453
てめえのブログにでも書いてろ

0456デフォルトの名無しさん

2011/09/04(日) 10:17:14.87

pyhonでも書いてろ

0457デフォルトの名無しさん

2011/09/04(日) 10:53:37.01

ただこれはやめて欲しい
func()
　　{
　　hoge...
　　}

0458デフォルトの名無しさん

2011/09/04(日) 12:09:58.81

なにこのヘミ猫臭い流れ

0459デフォルトの名無しさん

2011/09/04(日) 12:23:50.66

11 (C++11 の略は 11 なのか？) と何の関係もない。どうでもいい

0460デフォルトの名無しさん

2011/09/04(日) 13:20:53.44

C++03を03とか略してたなら11でいいんじゃないの

0461デフォルトの名無しさん

2011/09/04(日) 13:28:57.41

0xと言う呼び方があまりに有名になりすぎた

0462デフォルトの名無しさん

2011/09/04(日) 14:47:01.21

0xに従えば0bと言った方がしっくりくる気もするが
２進数の接頭辞っぽく見えるという罠も

0463デフォルトの名無しさん

2011/09/04(日) 15:00:16.46

C++は2進のリテラルもサポートするようになるの？

0464デフォルトの名無しさん

2011/09/04(日) 15:07:14.98

>>463
つ operator""

0465デフォルトの名無しさん

2011/09/04(日) 15:40:01.77

C++0xはISO/IEC 14882:2011のことで2012年に発行される

ややこしい

0466デフォルトの名無しさん

2011/09/04(日) 16:43:18.66

D言語にはあるよ

0467デフォルトの名無しさん

2011/09/04(日) 16:43:40.67

ISO/IEC 14882:2011だから結局C++11でいいの？

0468デフォルトの名無しさん

2011/09/04(日) 16:45:47.54

9899:1990 を C89 と言うやつ多いし

0469デフォルトの名無しさん

2011/09/04(日) 17:09:08.10

>>458
ということにしたいのですね:-)

0470デフォルトの名無しさん

2011/09/04(日) 22:23:12.17

一体どう呼べば良いんだ・・・

0471デフォルトの名無しさん

2011/09/04(日) 23:08:29.84

じゃあ 0x0b で

0472デフォルトの名無しさん

2011/09/05(月) 08:27:58.77

>>463
良くこういう意見聞くけど何が嬉しいのか解らん。
むしろ256進数使えるほうが便利だろうに。

0473デフォルトの名無しさん

2011/09/05(月) 08:45:13.32

ビットマスクの可読性が16進数と比べて格段に上がる。
16進⇔2進の変換がイメージで浮かぶような変態には意味がない

0474デフォルトの名無しさん

2011/09/05(月) 11:01:46.45

>>472
256進数とか何が嬉しいのか解らん。

0475デフォルトの名無しさん

2011/09/05(月) 11:37:25.10

C++11的には60進リテラルだろ

0476デフォルトの名無しさん

2011/09/05(月) 13:01:33.79

そんなもんＩＤＥ側で表示変えれるようにしたらいいだけと思うが
なぜそんな機能を実装したＩＤＥがないかがアメリカ人の大雑把さだよな。

0477デフォルトの名無しさん

2011/09/05(月) 13:37:57.63

規格にIDE云々を持ち込む方がバカだろ

0478デフォルトの名無しさん

2011/09/05(月) 14:43:45.70

>>472
２５６進数って・・・ 0x00-0x1f ぬきでさえ mﾗd*%u6EBｮﾌ)61A みたいになるぞ？
確かに昨今はアドレスの類が１６進数じゃ辛くなってきているが、
それはただ IPv6 みたいに区切り表記があれば済むことで基数を変える必要はあんまりないだろ

２進数にも１６進数にもえこひいきする合理性があるが、これらに対して２５６進数を持ち出す合理性はあるのか？

0479デフォルトの名無しさん

2011/09/05(月) 14:49:20.77

''で囲むのが256進数じゃね？

0480デフォルトの名無しさん

2011/09/05(月) 15:47:22.78

>>478
「うるせえ、屑」って意味かと

0481デフォルトの名無しさん

2011/09/05(月) 19:55:59.48

発行、発効、どっちが正しいの？

0482デフォルトの名無しさん

2011/09/05(月) 20:06:16.74

verilog みたいに　_ を使って任意の場所で数字を区切れるといいのになあ。
0xffff_ffff_ffff_ffff みたいに。

>>481
発行 publication
発効 effectuation

0483デフォルトの名無しさん

2011/09/05(月) 23:48:54.25

>>482
adaとかそんなのができたよね。
何気にn進数も標準じゃかなったかな

0484デフォルトの名無しさん

2011/09/06(火) 00:18:09.09

>>481
文書類は発行で、仕様の強制力は発効じゃね？

0485デフォルトの名無しさん

2011/09/06(火) 00:41:07.35

>>483
区切りはD言語にもあるね

区切りがなくても、WindowsのMAKELONGみたいなのを作れば
一応区切りの代わりにはなる

0486デフォルトの名無しさん

2011/09/06(火) 01:58:51.20

0xNxAA で AA が N進数だと解釈するコンパイラが昔あった。
0x2x11x200 だと 18。

0487デフォルトの名無しさん

2011/09/06(火) 07:24:45.45

0x2x11x200
　↑ ↑ ↑
　16　2　3
　進進進
　数数数

ということか
ややっこいなw

0488デフォルトの名無しさん

2011/09/06(火) 09:50:18.90

それ32進数とかはどうするの?
大文字限定?
48進数は?

0489デフォルトの名無しさん

2011/09/06(火) 10:01:29.66

よく覚えてないけど、0-9,a-z(A-Z)の36文字しか使えないから36進数までだった気がするよ。

0490デフォルトの名無しさん

2011/09/06(火) 17:17:47.01

'x'は使っちゃいかんだろw

0491デフォルトの名無しさん

2011/09/06(火) 17:52:47.87

0 で始まるトークンの 2 文字目でなければいいんじゃね
8 進数には使えない文字だし

0492デフォルトの名無しさん

2011/09/06(火) 18:25:32.69

0x36xxx10は34(十進)か1630404(十進)か?

0493デフォルトの名無しさん

2011/09/06(火) 18:56:19.75

小文字xはタブーにすればいい

0494デフォルトの名無しさん

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

0495486,489

2011/09/06(火) 21:42:02.22

今、CD-ROM発掘して調べたら 2進から16進までだった。すまぬ…すまぬ…

0496デフォルトの名無しさん

2011/09/06(火) 22:05:30.51

絶対に許さない

0497デフォルトの名無しさん

2011/09/07(水) 15:04:46.62

>>473
16進数で2進を想像できないヤツがビット操作なんてするもんじゃない。
64bitフルに使うと64桁の値がソースコードに散りばめられるわけだぞ
汚すぎるし、43bit目が立ってかとか見分けるのもメンドクサイ。

0498デフォルトの名無しさん

2011/09/07(水) 15:44:48.06

じゃなんでアセンブラなんかは 0b とか書けるんだ

0499デフォルトの名無しさん

2011/09/07(水) 15:50:06.19

マクロ使えよ・・・

0500デフォルトの名無しさん

2011/09/07(水) 15:54:37.22

そんなゴミみたいな欲求を満たすために追加されたのがconstexprなんだろ

0501デフォルトの名無しさん

2011/09/07(水) 15:55:44.95

10進数見て2進数がうかぶやつは変態の名にふさわしいと思うが
16進数は0-Fのたかが16種類のビットパターン覚えてれば機械的に読めるので
変態というのはどうなんだろう

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

0502デフォルトの名無しさん

2011/09/07(水) 16:08:06.78

>>500
は？

0503デフォルトの名無しさん

2011/09/07(水) 18:00:52.10

どうしても二進書きたければ自分でoperator""_bでも書けばいい

0504デフォルトの名無しさん

2011/09/07(水) 18:10:51.85

>>498
アセンブリ言語によるだろ。
というかCPUか。8bit,16bit CPUの時代ならまだbit単位で
書いても煩わしくはなかった。今はもう組み込み環境でもなければ
煩わしいだけ。

0505デフォルトの名無しさん

2011/09/07(水) 18:26:24.57

unsigned long long x = 0b000100100011010001010110011110001001101010111100110111101111;

うん、ありえん

0506デフォルトの名無しさん

2011/09/07(水) 18:28:00.77

アスキーアート的プログラミング。

0507デフォルトの名無しさん

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);

0508デフォルトの名無しさん

2011/09/07(水) 19:12:45.84

あ、しくったｗ
まあいい、意味に関係ない

0509デフォルトの名無しさん

2011/09/07(水) 19:44:56.58

>>504
全部が全部 2 進で書くわけじゃなかろ

0510デフォルトの名無しさん

2011/09/07(水) 19:51:11.58

(＾ｐ＾) ニシンソバおいしいです

0511デフォルトの名無しさん

2011/09/07(水) 20:05:43.12

>>507
当然。ビットフラグなんかの操作に慣れてる者から
すればすぐ解る。16進なんて所詮1+2+4+8の
組み合わせしか無いし。
0xFFFFffffFFFFffff
16桁しかないから、8桁目を中心に左右に見ていけば、
そうそう今何桁目を見てるか考える必要もない。

0512デフォルトの名無しさん

2011/09/07(水) 20:41:14.64

0x0000010000000000 = 43bit目がONの状態
2進よりはまだ読みやすいわ。

0513デフォルトの名無しさん

2011/09/07(水) 21:43:12.85

そこまで来るとNbit目がONの時に真になるようなマクロなり用意すると思う

0514デフォルトの名無しさん

2011/09/07(水) 21:57:54.30

未だにリトルエンディアンが苦手。
全部ビッグエンディアン、ネットワークバイトオーダーになればいいのに

0515デフォルトの名無しさん

2011/09/07(水) 22:52:38.28

ビッグエンディアンは人間の都合だから嫌い

0516デフォルトの名無しさん

2011/09/07(水) 22:53:16.14

43ビット目かどうかとか16進数でも難しいわ

unsigned long long x = 0b0001001000_1101000101_0110011110_0010011010_1011110011_0111101111;

こう書ければすぐだが

0517デフォルトの名無しさん

2011/09/07(水) 23:07:41.97

それで_を挿入する桁間違えてハマるんですね？

0518デフォルトの名無しさん

2011/09/07(水) 23:24:35.59

素直に1u<<42って書こうぜ

0519デフォルトの名無しさん

2011/09/07(水) 23:26:10.77

>>516
桁の区切り方が素人みたいだ。経験の長いプログラマーらしくない。

0520デフォルトの名無しさん

2011/09/07(水) 23:26:31.69

>>511
8+4+2+1 な
ハッタリはばれると赤っ恥だぜｗ

0521デフォルトの名無しさん

2011/09/07(水) 23:31:34.54

>>518
多分そういうフラグ作成みたいな用途以外に使うんじゃね。
例えば、フラグでのポートからの信号出力なら
Output8( io_address, SIG1 | SIG3 | SIG4 );;
ってな書き方するだろうし。

0522デフォルトの名無しさん

2011/09/07(水) 23:32:47.83

>>520
ん？2+4+8+1でも8+4+2+1でも同じじゃね？

0523デフォルトの名無しさん

2011/09/07(水) 23:36:02.39

>>520
?

0524デフォルトの名無しさん

2011/09/07(水) 23:37:27.84

>>519
8桁で区切るのが普通だとは思うが
43をぱっと分かるようにするには
10桁ずつ区切らないとな・・・

0525デフォルトの名無しさん

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

0526デフォルトの名無しさん

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桁潰してる。

0527デフォルトの名無しさん

2011/09/08(木) 00:12:48.28

16進数の1桁を1bitに見立てようぜ
B(01010101,10101010,10110101,11110010)
で 0x##a とかやればいい

0528デフォルトの名無しさん

2011/09/08(木) 00:15:42.64

>>524
> 43をぱっと分かるようにするには
> 10桁ずつ区切らないとな・・・

ﾜﾛﾀ

0529デフォルトの名無しさん

2011/09/08(木) 00:38:37.19

>>522
１６進から２進を連想するときは同じではない
0x20 は 32 であり断じて 128 ではない

0530デフォルトの名無しさん

2011/09/08(木) 00:46:21.23

マクロとしてコンパイル通るかどうか
やってないから知らんけど、アセンブリで
2進数使えるんなら、マクロ内でアセンブリに2進数渡してやれば？
B(11111111111111111111111111111111b);

0531デフォルトの名無しさん

2011/09/08(木) 00:49:00.82

>>529
意味が解らない・・・。
0x20は32以外あり得ないのは解るけど、128は何で出てきた？
128は十進数じゃない別の表記とか？

0532デフォルトの名無しさん

2011/09/08(木) 00:53:34.54

8+4+2+1 = F
1+2+4+8 = F
だと思うけど違いが解からん。
なおかつ>>529で余計に分からなくなった。

0533デフォルトの名無しさん

2011/09/08(木) 00:57:01.68

>>531 は合格（ただし可）
>>532 は落第

0534デフォルトの名無しさん

2011/09/08(木) 01:02:21.21

バカにも解るように教えてつかーさい。

0535デフォルトの名無しさん

2011/09/08(木) 01:04:15.77

>>522の 2+4+8+1 から
1000=2 0100=4 0010=8 0001=1 で
0x20=10000000b=128
という話なんだろうとエスパーした

0536デフォルトの名無しさん

2011/09/08(木) 01:10:03.22

>>535
なるほど、>>535の内容は解った。
しかし不思議な発想だね。

0537デフォルトの名無しさん

2011/09/08(木) 10:10:32.07

ワード長が伸びてきて、16進にせよ2進にせよ桁区切りができないと見づらい。
マクロ(というか constexpr 関数)でやれよっていうのは、確かにその通り

0538デフォルトの名無しさん

2011/09/08(木) 11:58:53.06

>>520の意味もさっぱりわからんが、
どうもバカそうな話なんでスルーするか。

0539デフォルトの名無しさん

2011/09/08(木) 12:11:38.52

>>520は上位ビットは左側に書くものだって言いたいんじゃないの？よくわからんけど。

そもそも、ビット演算を繰り上がりのある加算で記述ところからセンスを疑うが。

0540デフォルトの名無しさん

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進数とか最初に習う段階で勉強することじゃね？

0541デフォルトの名無しさん

2011/09/08(木) 12:39:31.74

で？

0542デフォルトの名無しさん

2011/09/08(木) 12:40:36.30

レベル低いよなお前らﾌﾟｷﾞｬｰ

0543デフォルトの名無しさん

2011/09/08(木) 12:43:10.57

>>540
よくわかりました！
ありがとうございました！！

0544デフォルトの名無しさん

2011/09/08(木) 12:54:11.88

加算の交換法則すら知らないアホがいる

0545デフォルトの名無しさん

2011/09/08(木) 12:55:14.31

どこに？

0546デフォルトの名無しさん

2011/09/08(木) 12:57:04.07

加法は可換だけど、数の表記の順序は左からで固定だから

ま、1234をひとりだけ4321と書く世界に生きたいんならご自由に
そういう人はア・プリオリな言語みたいなものを使うのは不便でしょうがないだろうけど

0547デフォルトの名無しさん

2011/09/08(木) 12:59:09.81

>>546
1+2+4+8と8+4+2+1の話じゃなかったんか？
もしかして+記号見えない病気とか？

0548デフォルトの名無しさん

2011/09/08(木) 12:59:32.57

つまり、>>544はLSBやMSBのようなエンディアン概念も知らないようなアホ以下ね

0549デフォルトの名無しさん

2011/09/08(木) 13:00:48.40

ああ、やっぱり+記号見えてないんだね
可哀想に

0550デフォルトの名無しさん

2011/09/08(木) 13:01:05.38

>>547
ああ、そっちの話か
俺はそっちの話は知らん
たぶん誤解されやすい加法表記を持ち出した>>520がアホなのだろう

0551デフォルトの名無しさん

2011/09/08(木) 13:19:28.75

1,2,4,8の組み合わせと16進でビット計算出来ないヤツに
このスレは早すぎないか？
0xより基礎のお勉強をした方がいいと思う。

0552デフォルトの名無しさん

2011/09/08(木) 13:22:39.06

>>548
型変換する訳じゃないからエンディアン関係ねえ。

0553デフォルトの名無しさん

2011/09/08(木) 13:26:40.43

>>552
エンディアンは関係は無いが、2進表記はMSB側から・左から書くわけだから
4桁の2進表記があれば、左から8, 4, 2, 1の係数になっているのであって
逆ではないだろ
加法は可換だが、順序がどうでもいいわけではないということ

つーかお前ら本当に糞どうでもいい自転車置き場の議論が好きだな
くだらねぇ

0554デフォルトの名無しさん

2011/09/08(木) 14:11:04.11

1+2+4+8から順序を連想するなんて頭オカシイだろ

0555デフォルトの名無しさん

2011/09/08(木) 14:27:41.62

慣習とか慣用とか

0556デフォルトの名無しさん

2011/09/08(木) 15:48:43.36

>>554
なんかの病気だろうね。

0557デフォルトの名無しさん

2011/09/08(木) 18:59:53.09

1+2+4+8の順々に対して慣習なんて聞いたことねぇ。
プログラム以前に中学数学レベルの話だろ。
0x81 + 0x18 = 0x99 なんてどうすんだよ。

0558デフォルトの名無しさん

2011/09/08(木) 19:03:31.19

いち、じゅう、ひゃく、せん、まん
まん、せん、ひゃく、じゅう、いち

0559デフォルトの名無しさん

2011/09/08(木) 19:24:28.54

そろそろ C++0x の話をしようよ。

0560デフォルトの名無しさん

2011/09/08(木) 19:29:10.80

11

0561デフォルトの名無しさん

2011/09/08(木) 20:28:10.81

桁数数えるときは下から考えるだろ常考

0562デフォルトの名無しさん

2011/09/08(木) 20:38:50.57

次スレどうする？C++11 0x14にでもする？
そろそろどっかに11いれにゃならんだろ。

0563デフォルトの名無しさん

2011/09/08(木) 20:40:33.16

0b却下の時もこんな流れで1スレ潰したなぁ
進歩ないなお前ら

0564デフォルトの名無しさん

2011/09/08(木) 21:03:55.80

>>539
飽和論理和じゃ桁上がりしないから、
純粋に数学特性の説明だとマズイだろ。
7 | 9 = 0xF だと、正しいけど意味が解からんだろ。

0565デフォルトの名無しさん

2011/09/08(木) 22:02:28.71

C++0x 11 14

0566デフォルトの名無しさん

2011/09/08(木) 22:05:57.54

>>562
それに検索用に【C++0x】って感じで付け加えるのでどうだろう。

0567デフォルトの名無しさん

2011/09/08(木) 22:06:37.85

>>564
お前、頭おかしいのか？

0568デフォルトの名無しさん

2011/09/08(木) 22:15:55.17

ハイ

0569デフォルトの名無しさん

2011/09/08(木) 22:18:40.58

C++11 (C++0x) 14

0570デフォルトの名無しさん

2011/09/08(木) 22:19:30.58

>>568
ハイじゃないがな

0571デフォルトの名無しさん

2011/09/08(木) 22:33:52.47

正確に行こう
ISO/IEC 14882:2011 (C++11/C++0x) 14

0572デフォルトの名無しさん

2011/09/08(木) 22:35:45.42

JISはいつくるんだ。
まぁ、JIS規格になったところで、タダで仕様を見られるようになるだけだけど。

0573デフォルトの名無しさん

2011/09/08(木) 22:44:29.35

おまえがつくれ！

0574デフォルトの名無しさん

2011/09/08(木) 23:08:00.13

FDIS落としてないのー

0575デフォルトの名無しさん

2011/09/09(金) 03:07:31.43

C++0b 0d
でいいだろ

0576デフォルトの名無しさん

2011/09/09(金) 17:01:54.97

というか正式なC++の規格になったんだからC++本スレに合流でいいんじゃね

0577デフォルトの名無しさん

2011/09/09(金) 17:34:25.03

ここが本スレと思ってた

0578デフォルトの名無しさん

2011/09/09(金) 18:23:09.74

>>576
君、行っていいよ。許可する。

0579デフォルトの名無しさん

2011/09/09(金) 20:31:48.55

むしろ旧C++スレをC++03スレにするべきなのか

0580デフォルトの名無しさん

2011/09/11(日) 13:53:36.06

本スレで0xの話題しても迷惑になるだけだから
VCやGCCが正式に0xに対応するまではこのスレは維持する。
でなければ混乱を起こすだけ。

0581デフォルトの名無しさん

2011/09/11(日) 14:22:41.21

このスレはここと同じようなスタンスでいいんじゃないの？

【初心者お断り】ガチ規格準拠C専用スレ Part134
http://hibari.2ch.net/test/read.cgi/tech/1246115922/

0582デフォルトの名無しさん

2011/09/11(日) 14:34:02.77

いやもうすぐに次の規格の話始まるから。

0583デフォルトの名無しさん

2011/09/11(日) 15:30:08.14

それは別スレでやった方がよくね？

0584デフォルトの名無しさん

2011/09/11(日) 17:09:13.63

shared_ptrは使わない機能にコストを払わないというC++の基本理念におもいっきり反してると思うんですが
なんでこんな出来損ないが次期標準に選ばれたのでしょうか？

0585デフォルトの名無しさん

2011/09/11(日) 17:27:14.15

shared_ptrを使わなければコストなんてかからないから
別に反してない

0586デフォルトの名無しさん

2011/09/11(日) 17:35:20.43

だが考えてみてほしい、委員会の人的コストがかかるのではないか
ひいては限られた人類の時間資源というコストがかかるのではないか
人類が滅亡するまでに使うことができる人月は決して無限ではないのだ・・・
まあ俺はshared_ptr使うんだけど

0587デフォルトの名無しさん

2011/09/11(日) 17:43:02.10

vectorだって、長さ固定ならただの配列よりコストがかかるし、
stringだってただの配列に比べれば高コスト。
機能にコストが掛からないというのは言語に限った話で、
ライブラリに対しては至上命題じゃない。

0588デフォルトの名無しさん

2011/09/11(日) 18:22:01.59

至上命題って言葉を使うのは止めようよ。至上命令ならいいけど。

0589デフォルトの名無しさん

2011/09/11(日) 18:29:36.50

このスレの残りと次スレからは「次期C++標準スレTRもあるよ」ってことでいいんじゃないかな？

0590デフォルトの名無しさん

2011/09/11(日) 18:41:51.94

まあライブラリも可能な限りコストがかからないように気は配ってるけどね
今回は仕様まで変えて（右辺値参照を追加して）効率化計ったし

0591デフォルトの名無しさん

2011/09/11(日) 20:15:33.30

>>587
それは現状な
ライブラリがバイナリ提供という前提のうえでの

ライブラリのユーザにとって決して満足な解ではなく改善の余地が残っている問題だ

0592デフォルトの名無しさん

2011/09/11(日) 20:29:17.35

どうやって改善するの？
ファイルリンケージな、ポインター管理テーブルでも作って、
擬似スレッド(コールスタックでのガベコレイベント)によるリソース解放でもすんの？
C++の活躍の場は、組み込み環境もあるから安易にスレッドによる同時管理なんて手も使えないけど。

0593デフォルトの名無しさん

2011/09/11(日) 20:35:24.68

使わない機能にコストを払わないって言葉を正しく理解していない人がいるな。

shared_ptr を標準に追加したからといって、shared_ptr を使用しないプログラムが
実行時のコストを払わされることはないってことだから問題ないだろ。

0594デフォルトの名無しさん

2011/09/11(日) 20:54:53.56

なんでガベコレが出てくるんだよ
コンパイラが最終的にうまいアセンブラ使いと同じコードを吐くまで改善の余地はずっとあるだろ

ライブラリが気に入らなければ使わないんじゃなく
ライブラリに何を要求したかによる最小のコストであるべきものだ
それを妨げているネックがバイナリ提供だと主張した

0595デフォルトの名無しさん

2011/09/11(日) 20:59:20.36

>>594
だから具体的にどうできるの？
トランポリンみたいに直接機械語を変更するでもいいから、
具体的に同改善できるのか教えておくれ。

0596デフォルトの名無しさん

2011/09/11(日) 21:00:02.88

銀の弾丸が欲しいだけだろ

0597デフォルトの名無しさん

2011/09/11(日) 21:01:53.67

>>594
具体例が出せなきゃ、「妄想か。策定グループの判断が正しいな。」としか言えないよ。

0598デフォルトの名無しさん

2011/09/11(日) 21:05:12.01

shared_ptrを使わなければ実効バイナリにshared_ptrのコードは含まれないじゃん
要求しない分には最小コストになってるじゃん

0599デフォルトの名無しさん

2011/09/11(日) 21:06:02.35

それがわかってない馬鹿がいただけですよ

0600デフォルトの名無しさん

2011/09/11(日) 21:14:24.22

それを言うなら
shared_ptr に対する要求がサブセットであることと
shared_ptr を全く使わないことを、同じであることにしたいだけの馬鹿がいるだけだよ

これで具体的にどういうことか通じない御仁に付き合ってやりたいやつはそうしたらどうだ？　（俺はパス

0601デフォルトの名無しさん

2011/09/11(日) 21:14:45.83

>>598
流れと関係ないけど、リンケージって何処まで仕様が決まってんだっけ？
インタープリタやLLVMで動くから、コンパイル & リンクは仕様の範囲じゃないよね。
リンク段階なしでもあり？

0602デフォルトの名無しさん

2011/09/11(日) 21:16:14.04

>>600
じゃそのサブセットってのは何を要求していて、
具体的にどう機能を変えることで対応できるの？

0603デフォルトの名無しさん

2011/09/11(日) 21:28:51.27

>>601
shared_ptrはテンプレートだから
使わない限り実体化されないだろ

0604デフォルトの名無しさん

2011/09/11(日) 21:37:14.34

インタープリタでの使用は仕様じゃ考慮してないんじゃなかったっけ？

0605デフォルトの名無しさん

2011/09/11(日) 21:38:40.79

>>603
いや、shared_ptr関係なく純粋にリンケージの事。
使ってもない関数が結構リンクされてるのがウザイ。
仕様上あれを全部除去する余地はないのか？
一応仮想関数が無理なのは解る。
C++なんて最低限、new deleteと例外用のランタイムだけ
リンクすればいいでしょ。

0606デフォルトの名無しさん

2011/09/11(日) 21:42:36.60

LTCGを仕様に含めろとか馬鹿な事を

0607デフォルトの名無しさん

2011/09/11(日) 21:46:07.03

>593が回答だろ。
>584 >587は単なる勘違い。

0608デフォルトの名無しさん

2011/09/11(日) 21:53:01.92

>>606
LTCGじゃなくclangみたいな方法でもいいじゃん。
とにかく、外部に公開しないような関数は根こそぎ
消すことを義務化してほしいね。

0609デフォルトの名無しさん

2011/09/11(日) 21:54:52.01

>>607 誰に対する？

0610デフォルトの名無しさん

2011/09/11(日) 22:40:04.14

>>608
つまり関数はデフォルトで内部結合にして、
外部に出すには extern つけなさいってことか？

0611デフォルトの名無しさん

2011/09/11(日) 22:45:58.85

>>610
リンク時のシンボルテーブルから、参照されてない関数見つけて
その関数を領域ごとごっそり消せばいいって事でしょ。
関数の長さが解らないから、関数のマングリングに関数のバイト数を追加したりする
必要はあるだろうけど。

0612デフォルトの名無しさん

2011/09/11(日) 23:04:03.43

>>611
そんな具体的なところにまで規格は踏み込めないよ多分。

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

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

それに、些細で不要な関数を消してもどうせアライニングの関係で
パディングしなければいけないとき、
その関数を消すのをさぼったからといって規格不適合っていうのも無理がある。

0613デフォルトの名無しさん

2011/09/11(日) 23:09:45.55

>>612
やっぱ規格上でその規定はむりか。

今時、crang,gcc,armcc,optimize compilerと実装は違えど
大抵のコンパイラで、できる機能なんだけどな。
それを言ったら最適化もって事ではあるけど。

0614デフォルトの名無しさん

2011/09/11(日) 23:36:54.72

確かに規格の死角ではあるね

考え落としではなく、触れるわけにいかない事項だが
コードサイズの増加が無害と思い込むのは狭い視野での早まった結論だ

0615デフォルトの名無しさん

2011/09/12(月) 01:59:20.53

vtableの仕様すら規格で決まって無いのに、お前らお花畑だな。

0616デフォルトの名無しさん

2011/09/12(月) 07:44:12.85

実行バイナリには不要な関数コードが10%以上混在してはならないとか
実行コードは物理的なCPUネイティブ？で実行されなくてはならないとか
１組み込み演算コードは１KB以内に収めるとか1000サイクル以内に実行できるとか
そんなん言い出すと法律家みたいな判例と解釈の専門家が必要になる気がする

0617デフォルトの名無しさん

2011/09/12(月) 10:01:23.91

言語規格だけが規格でもなし、ある程度の標準化求めるにも
もっと別のベンダ寄りなとこに出す話なんじゃね。言語の理念は理念としても。

0618デフォルトの名無しさん

2011/09/12(月) 12:39:25.86

意味を左右しない実装の自由が残ってるのは良い規格である証拠。

0619デフォルトの名無しさん

2011/09/12(月) 13:01:37.85

行列計算なんかオペレータ使うとアレじゃん?
このあたりはなんとかなならないの

0620デフォルトの名無しさん

2011/09/12(月) 13:21:21.50

アレとは

0621デフォルトの名無しさん

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

0622デフォルトの名無しさん

2011/09/12(月) 17:06:16.48

はええな
可決されてからほぼ一ヶ月か

0623デフォルトの名無しさん

2011/09/12(月) 18:34:00.45

>>619
一時オブジェクトがどうこうという話なら右辺値参照で解決された

0624デフォルトの名無しさん

2011/09/12(月) 19:43:40.52

>>623
あれま、そうなんだ。
ポインタ含まないような構造体でも解決されてるのか。

0625デフォルトの名無しさん

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 で消せる)

0626デフォルトの名無しさん

2011/09/12(月) 21:09:05.39

>>625
そういう問題じゃないんじゃね？
Expression Templateを使うような問題だろ。

最終的にこういう感じで展開されなきゃならんと言う話。
n[i] = a[i] + b[i] + c[i] + d[i];

0627デフォルトの名無しさん

2011/09/12(月) 22:25:29.82

>>626
そういうのは右辺値参照関係ない…

0628627

2011/09/12(月) 22:28:48.84

ああそうか、>>623 ≠ >>625 = >>627 って言っとかないと流れがよくわからないな

0629デフォルトの名無しさん

2011/09/14(水) 16:35:22.29

Visual Studio vNextのC++11対応に失望した

0630デフォルトの名無しさん

2011/09/14(水) 16:52:18.48

nested lambdaがバグるコンパイラってなんなの

0631デフォルトの名無しさん

2011/09/14(水) 17:05:51.91

>>629
これ？
http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx

0632デフォルトの名無しさん

2011/09/14(水) 17:56:12.19

C++11対応にまともに取り組んでると言えるのはGCCとIntelくらいか

0633デフォルトの名無しさん

2011/09/14(水) 18:34:19.54

早漏気味に対応してたBCCはどうなの
あとexportに定評のあったComeauとか

0634デフォルトの名無しさん

2011/09/15(木) 08:37:45.51

>>631
欲しかったものがatd::atomicぐらいしか入ってねー

0635デフォルトの名無しさん

2011/09/15(木) 10:50:55.83

今まで何やってたんだって感じだな

0636デフォルトの名無しさん

2011/09/15(木) 13:24:02.02

vc10から変わってないじゃないか

0637デフォルトの名無しさん

2011/09/15(木) 14:36:35.94

Visual Studioにそういうの期待する方がおかしい。
あれはMSの現フレームワークの開発環境提供が第一義。

ISO C++の部分だけベータリリースしてもいいんじゃないかとは思うが。

0638デフォルトの名無しさん

2011/09/15(木) 14:40:30.40

>>633
Comeauは開発停まってるでしょ。
http://www.comeaucomputing.com/43101features.html#newstuff

0639デフォルトの名無しさん

2011/09/15(木) 14:46:46.51

wikipediaのc++0xをc++11に転送するようにできないものか

0640デフォルトの名無しさん

2011/09/15(木) 15:14:15.56

してくりゃいいじゃない

0641デフォルトの名無しさん

2011/09/15(木) 15:23:35.10

英語版は二週間くらい前に転送されているからあれ？と思ったら、
日本語版はまだC++0xしかエントリないんだね。

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

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

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

まあ日本語版見てる人が少ないんだろうけど。

0642デフォルトの名無しさん

2011/09/15(木) 15:31:42.48

>>641
そこまで言うなら直してくれよ

0643デフォルトの名無しさん

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

0644デフォルトの名無しさん

2011/09/15(木) 16:13:04.87

>>641
自分でやれよ

0645デフォルトの名無しさん

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; }

0646デフォルトの名無しさん

2011/09/15(木) 16:32:18.74

c++11のlambdaはmonomorphic

0647デフォルトの名無しさん

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ってどうとればいいんだ

0648デフォルトの名無しさん

2011/09/15(木) 17:44:31.04

decltype(NamedLambda2(0)) c=5;

0649デフォルトの名無しさん

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;
}

0650デフォルトの名無しさん

2011/09/15(木) 18:59:44.49

decltypeの中が複雑だったり、関数のスコープ内で定義された変数を含む場合ってどうするの？

0651デフォルトの名無しさん

2011/09/15(木) 20:25:04.36

型だけ見る

0652デフォルトの名無しさん

2011/09/15(木) 22:16:45.06

>>625

演算子を用いた(a+b)*(c+d)*eとかの行列計算もokでしょうか？

0653デフォルトの名無しさん

2011/09/15(木) 23:09:06.38

>>652
右辺値参照ををオーバーロードするライブラリを誰かが作ればOK

「テンポラリを無駄に生成したくない」という問題だけなら解決する。
( (a+b)*(c+d)*e なら c+d のテンポラリは消せないけど)

0654デフォルトの名無しさん

2011/09/15(木) 23:54:57.27

>>650
decltypeの中は自分で頑張って書くしかないな。
ttp://ideone.com/dgXqf

0655デフォルトの名無しさん

2011/09/15(木) 23:59:29.18

lambdaみたいにreturnから推論できればいいのにね
定義必須になるけど、どうせほとんどの場合テンプレートで使うんでしょ

0656デフォルトの名無しさん

2011/09/16(金) 00:01:23.32

そもかわりlambdaはresult_typeがないので
boostと組み合わせると大変なことに

0657デフォルトの名無しさん

2011/09/16(金) 00:02:18.79

なんでそんな事に・・・

0658デフォルトの名無しさん

2011/09/16(金) 00:05:01.11

もう拡張だけで頑張るのは無理な次期にきてるんじゃないかな

0659デフォルトの名無しさん

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のバグというか、まだ実装途中ってことなんだよね？

0660デフォルトの名無しさん

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; }
}

0661hiding

2011/09/16(金) 02:41:50.22

>>659
decltypeをnested name spacifierとして使えるようになったのはごく最近のこと。
土壇場のギリギリになってから規格に入った。
だからgccはまだ対応してない。

0662デフォルトの名無しさん

2011/09/16(金) 12:19:02.49

http://www.suri.cs.okayama-u.ac.jp/servlets/APPLICATION.rkt

schemeからc++0xの自動生成

0663デフォルトの名無しさん

2011/09/16(金) 12:41:10.61

こんな短いコードで変換できちゃうの？

0664デフォルトの名無しさん

2011/09/16(金) 13:00:36.22

declarationを人間が入力することで型推定を人間がやってるから短くなる

0665デフォルトの名無しさん

2011/09/16(金) 15:51:58.41

>>664
gambit-c
http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Main_Page
も凄いとおもったが、>>662はそれ以上だな。

0666デフォルトの名無しさん

2011/09/16(金) 16:16:28.24

なんだかなぁ。右辺値参照とか、decltypeとかconstexprとか
複雑さをもたらすだけだな。autoは便利だが。

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

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

使いたいのはスレッドとスマートポインタ、unourdered set、map
ぐらいでいい。

0667デフォルトの名無しさん

2011/09/16(金) 16:48:37.04

つチラ裏

0668デフォルトの名無しさん

2011/09/16(金) 17:06:20.97

はいはい

0669デフォルトの名無しさん

2011/09/16(金) 21:10:58.59

>>666
overrideつけたのはベースのクラスで引数変えて、派生クラスで
引数変え忘れとかのケアレスミス防止だろ、
今のコンパイラでも警告出たかどうか知らないけど。
他人のコード引き継いだりしたときはミスしそうなとこだろ。

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

以上、チラ裏

0670デフォルトの名無しさん

2011/09/16(金) 21:47:17.03

overrideないとエラーになるならいいんだけどねえ

0671デフォルトの名無しさん

2011/09/16(金) 21:56:11.59

>>444

0672デフォルトの名無しさん

2011/09/16(金) 22:07:01.41

C++0xをシェイプアップして
キモいメタプログラミングを構造化言語で記述する仕様を付けて出せば最強言語

0673デフォルトの名無しさん

2011/09/16(金) 23:31:47.94

>>672

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

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

科学、工学、他分野の技術系の人にとっては、計算やアルゴリズム
が大事だから、文法が簡単な言語を使う(最近は工学関係もMATLABや
Octaveが浸透してきた)。どうしてもスピードが要求されるところ
にはFORTRANを使う。C++はあまりにも言語が自己主張しすぎる。
複雑なC++の習得に時間をかけるのは本末転倒。

0674デフォルトの名無しさん

2011/09/16(金) 23:41:48.01

>>672の発想で作られたD言語という失敗作があってな

0675デフォルトの名無しさん

2011/09/16(金) 23:46:03.91

>>673
> どうしてもスピードが要求されるところ
> にはFORTRANを使う。
C++には満足な並列構文がないじゃん

0676デフォルトの名無しさん

2011/09/16(金) 23:51:14.57

やっとスレッドの概念が規格化された言語に並列構文とか無茶言うな

0677デフォルトの名無しさん

2011/09/17(土) 01:53:27.72

D言語は仕様が固まれば・・・

0678デフォルトの名無しさん

2011/09/17(土) 11:33:40.70

Dは失敗したけどそのうち取って代わる言語が現れて
C++の仕事は過去の遺物の保守と移植だけみたいな状況が来るよ
ジョンタイターと飲みに行ったときに彼ももそう言ってた

0679デフォルトの名無しさん

2011/09/17(土) 11:58:06.53

Vita にもいよいよ C# 来たしなあ。
どの程度なのか知らんが。

0680デフォルトの名無しさん

2011/09/17(土) 12:15:22.92

10年以上前から言われてる気がする

0681デフォルトの名無しさん

2011/09/17(土) 13:28:52.06

>>679
XBLIGでC#使えるのと同じぐらいのインパクトしか無いんじゃないかな。

0682デフォルトの名無しさん

2011/09/17(土) 15:14:57.91

360でC#使えるけど、C#っぽい楽な書き方してるとGC走りまくって使い物にならなかった。
GCが問題無いくらいVITAが速いならいいけど。

0683デフォルトの名無しさん

2011/09/17(土) 16:00:17.69

ドイツ語ってすごい文法も奇麗だし
読みがそのままスペルでいいよね

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

仮にドイツ語が広く使われたとしても
結局ぐちゃぐちゃな拡張される事になると思う

0684デフォルトの名無しさん

2011/09/17(土) 16:04:05.68

ドイツ語の読み書きが出来る人？　それとも聞きかじっただけ？

0685デフォルトの名無しさん

2011/09/17(土) 16:06:45.65

>>683
Wikipedia一回見れ　恥ずかしすぎるお前

0686デフォルトの名無しさん

2011/09/17(土) 16:16:54.15

リンカエラーやデバッガの出力で壮絶なmangled nameを見ると
ドイツ語の複合語が連想される、まで読んだ

0687デフォルトの名無しさん

2011/09/17(土) 16:34:35.95

demangle して読まないの?

0688デフォルトの名無しさん

2011/09/17(土) 19:28:58.02

あれ？C#ってGCコントロールできるんじゃなかったっけ？

0689デフォルトの名無しさん

2011/09/17(土) 19:39:29.77

日本語読めないヒト科？

0690デフォルトの名無しさん

2011/09/17(土) 20:12:10.18

>>688
処理系による。Windowsの.netなら発生頻度はある程度コントロール出来る。
360とかWPは無理。Monoは知らない。

0691デフォルトの名無しさん

2011/09/17(土) 22:06:10.73

.net by auェ・・・

0692デフォルトの名無しさん

2011/09/17(土) 22:26:27.73

そういえば、ラベル付きbreak/continueは常々ほしいと思ってたんだけど、
C++11から敢えて外した理由ってあるの？
それともほとんどの人は多重ループからの脱出とかしないの？

0693デフォルトの名無しさん

2011/09/17(土) 22:28:49.06

>>692
そんなの作ったら巨大な関数が今よりもっと増えそうな気がしていいやだな。
関数作って return を使うプレッシャーがあるぐらいでちょうどいいんじゃないかと思う。

0694デフォルトの名無しさん

2011/09/17(土) 22:28:49.60

switch (a) {
case 0:
...
break;
case 1:
...
goto 0;//とか出来たらいいなあ
}

0695デフォルトの名無しさん

2011/09/17(土) 22:47:27.00

C#やDではgoto caseがあるっけ

0696デフォルトの名無しさん

2011/09/17(土) 22:59:05.59

……C#使い始めて結構経つけど今初めて知ったよ。

0697デフォルトの名無しさん

2011/09/17(土) 23:03:30.99

auto DoubleLoop = [&]
{
　for(...){
　　for(...){
　　　if(...) return;
　　}
　}
};

DoubleLoop();

0698デフォルトの名無しさん

2011/09/17(土) 23:23:10.00

>>693
結局goto使うか、エラーでもないのに例外使うか、
それとも>>697みたいな黒魔法に走るか（俺なら変数宣言もしないけど）するだろうから、
それならラベル付きループの方がいくらかマシじゃないかなあ

それに、どうせループの中でスコープ切れてるから、
ループによる関数の巨大化の弊害はそんなにない気はする

0699デフォルトの名無しさん

2011/09/17(土) 23:44:40.97

>>683-685
ヒント：銀英伝

0700デフォルトの名無しさん

2011/09/18(日) 00:54:15.19

>>692
必要ないです。
上手く構造化出来なければ、普通にgotoです。

0701デフォルトの名無しさん

2011/09/18(日) 01:19:46.51

whileとか必要ないです
普通にgotoです

と同レベルだぞそれ

0702デフォルトの名無しさん

2011/09/18(日) 01:32:30.69

いいえ全然違います。

0703デフォルトの名無しさん

2011/09/18(日) 01:52:16.23

同レベルだよ
gotoじゃ意味を言語的に記述出来ない

0704デフォルトの名無しさん

2011/09/18(日) 01:54:23.96

[&]{
　for(...){
　　for(...){
　　　if(...) return;
　　}
　}
}();

そんなに黒っぽくないような気がする

0705デフォルトの名無しさん

2011/09/18(日) 02:49:50.93

本当にreturnしたい時どうするんですｶｰ

0706デフォルトの名無しさん

2011/09/18(日) 04:43:56.57

>>704
はやくllvm clangでも動いて欲しい

0707デフォルトの名無しさん

2011/09/18(日) 04:47:03.93

生成される機械語を考えたらgoto一択と思いたいんだが、LLVMなら>>704も最適化されるんだろうか？

0708デフォルトの名無しさん

2011/09/18(日) 04:58:12.52

clangはクソblocksさんが普及するまでラムダさん実装ボイコットじゃねーの

0709デフォルトの名無しさん

2011/09/18(日) 06:40:34.78

即使用のラムダさんは
最適化でinline化するのがベストではあるが

0710デフォルトの名無しさん

2011/09/18(日) 10:13:31.20

最適化するために(mutableをつけない限り)全メンバが const なんだと思う

0711デフォルトの名無しさん

2011/09/18(日) 10:16:08.32

最適化にconstって関係あるの？

0712デフォルトの名無しさん

2011/09/18(日) 10:21:09.32

ないな。
変更されてるかどうかなんてコンパイラが勝手に解析すればいいし、constなんてキャストで外せるんだから信用しちゃだめだ。

0713デフォルトの名無しさん

2011/09/18(日) 11:35:31.71

const値は定数に置換される事が仕様で決まってる。

0714デフォルトの名無しさん

2011/09/18(日) 11:46:52.30

アホー知恵遅れに>>713みたいに定数値で初期化されることが抜けている奴がなにか喚いてたな

0715デフォルトの名無しさん

2011/09/18(日) 12:15:43.12

>>713
規格中のどこの規定のことを言っているのかね？

0716デフォルトの名無しさん

2011/09/18(日) 12:30:36.76

goto hell; //hell へ行く。で、何がしたいのか？
while(hell) //hell の間繰り返す。で、何がしたいのか？

どちらも「意味を言語的に記述」はしていて、意図を記述していない
これで while をえこひいきする客観的な理由は何だ？ Dijkstra の教えがどうたらじゃなく

0717デフォルトの名無しさん

2011/09/18(日) 12:33:45.89

どうでもいいことに必死だな。
マルチスレッド対応のほうが大事だろ。

0718デフォルトの名無しさん

2011/09/18(日) 12:34:54.13

>>716
すれ違い

0719デフォルトの名無しさん

2011/09/18(日) 12:41:24.47

聞かれたら困る、まで読んだｗ

0720デフォルトの名無しさん

2011/09/18(日) 12:46:08.16

煽るのは適切なスレでやってね

0721デフォルトの名無しさん

2011/09/18(日) 17:53:23.59

>>716
C++的にはgotoだと上方向に飛べるからコンストラクタやtryをまたがれると云々とか。

0722デフォルトの名無しさん

2011/09/18(日) 17:57:42.38

>>716
アホはお帰り下さい

0723デフォルトの名無しさん

2011/09/18(日) 18:14:41.35

>>716
gotoは制御のネストを破壊する。
break,retrun,continueに於いてはネストを
下げるだけの操作だからgotoとは別。

このスレで、スレ違い、さらには初心者レベルなネタをだすな。

0724デフォルトの名無しさん

2011/09/18(日) 19:24:31.94

今時、gotoアレルギーの人が多いんでびっくりした。

0725デフォルトの名無しさん

2011/09/18(日) 19:26:55.56

ステートマシンとかに使えて便利なのにな

0726デフォルトの名無しさん

2011/09/18(日) 19:27:55.45

ステートマシンぐらいオブジェクトで組めよ。
そっちの方が楽だろ。

0727デフォルトの名無しさん

2011/09/18(日) 19:47:31.29

>>721
コンストラクタや try をまたぐ問題は上方向か下方向かには関係ないと思うぞ

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

# goto や多重継承についてドライに何か尋ねると高圧的になる人を魚っ血中
# これから出かけるところで帰りは明朝　（疲れる用事なので寝てるかも）

0728デフォルトの名無しさん

2011/09/18(日) 19:51:04.36

continueは、ネストの範囲を狭める。
どっちかといえば新しいネストを作り出してる方だな。

0729デフォルトの名無しさん

2011/09/18(日) 19:52:31.86

匿名掲示板でそーゆーこと書いちゃうのは後釣り宣言と変わらんぞ

0730デフォルトの名無しさん

2011/09/18(日) 19:54:27.44

横レスだけども、
gotoはコードの原則を変えてしまうので問題なんだろう。
つまり、下に流れるということ。

俺は、下に流れるgotoは許容してるな。
あんまり使う機会もないけども。

0731デフォルトの名無しさん

2011/09/18(日) 19:54:35.35

>>727
くだらねぇ事相手にしたくないけど。
再利用が効くからってこんなコード書かれたらどう思うんだよ。
label2:
if(・・・)
{
    ・・・・
label1:
    ・・・・
     goto label2;
}
else
{
    ・・・・
    goto label1;
}

0732デフォルトの名無しさん

2011/09/18(日) 19:58:37.69

>>730
俺も迂闊に上とか言っちゃったんで>>727で実につまらん反論されたけどさ(元々の意図と異なるので相手にしないけど)
迂闊に下とか言っちゃうと↓みたいな揚げ足取りがきっと来るぞ

goto L;
t obj; //コンストラクタが動く
L:

0733デフォルトの名無しさん

2011/09/18(日) 20:03:08.74

>>732
そういうのは趣味でやってるうちに、頭の中で最適化されて消えてくモノだと思うんだけどねぇ。
来たら来たで、なんでそうなった？？って聞くだろうし。

0734デフォルトの名無しさん

2011/09/18(日) 20:08:47.30

>>731
書いたその日はいいかもしれんが、手直しが必要になったら関数の中まるごと消すわ

0735デフォルトの名無しさん

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を使ってるだけで、
構文があった方がいいのは間違いない

0736デフォルトの名無しさん

2011/09/18(日) 20:33:17.24

バカがバカなことできるってのが問題なんだろな

0737デフォルトの名無しさん

2011/09/18(日) 20:42:26.12

研究畑の人間がいじる可能性のあるコードは特に危険
プログラムとか適当でも理論を実証できればそれで良いと思ってるから
可読性とか安全性とかほとんど気にしない（というか興味も知識もない）ので
ラベル名変えないとか普通にあり得る

ラベル付きbreak/continueはC++1xではどうなるんだろう

0738デフォルトの名無しさん

2011/09/18(日) 20:48:51.45

gotoはbreakと同じだと思ってるヤツは、
gotoは2重forから2重forのど真ん中に
飛び込んだり出来ることをよく覚えとけよ。

0739デフォルトの名無しさん

2011/09/18(日) 20:50:20.40

ラベル付きより番号指定のほうがよくね。
名前考えるのメンドイわ。

break 1;//一段抜ける
break 2;//二段抜ける
break 3;//三弾抜ける

0740デフォルトの名無しさん

2011/09/18(日) 20:52:05.14

>>739
それ良いね。

0741デフォルトの名無しさん

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)

0742デフォルトの名無しさん

2011/09/18(日) 21:19:51.42

>>739
ネスト増やした途端バグになる

0743デフォルトの名無しさん

2011/09/18(日) 21:21:05.26

>>741
醜悪すぎる・・・

0744デフォルトの名無しさん

2011/09/18(日) 21:22:00.50

多重ループ脱出以外でのgotoの使いどころを教えてくれ

0745デフォルトの名無しさん

2011/09/18(日) 21:22:19.30

>>742
そんな迂闊に for や while 書く奴なら、何やってもバグるだろう。

0746デフォルトの名無しさん

2011/09/18(日) 21:22:58.72

>>731
土人と一緒に仕事するのをやめろ。

0747デフォルトの名無しさん

2011/09/18(日) 21:24:27.96

>>742
ラベルでも方向は違えど同じだろ。

0748デフォルトの名無しさん

2011/09/18(日) 21:26:51.88

>>739
これカウントが逆のほうが良くないか？

break 0;//一番外を抜ける
break 1;//二段目を抜ける

0749デフォルトの名無しさん

2011/09/18(日) 21:27:42.02

>>744
よく見るのは関数終了前のエラー処理に飛ぶタイプ。
finally節的な使い方。カーネルのソースでもしょっちゅう見る。

0750デフォルトの名無しさん

2011/09/18(日) 21:28:09.18

>>745
マジックナンバー書く時点でｵﾜｯﾄﾙ

0751デフォルトの名無しさん

2011/09/18(日) 21:28:11.31

PL/1がカウンタ方式じゃなかったかな。

0752デフォルトの名無しさん

2011/09/18(日) 21:28:52.22

なんかいっしょのプロジェクトやりたくない奴ばっかだな

0753デフォルトの名無しさん

2011/09/18(日) 21:28:55.11

デストラクタちゃんとしてれば要らんよな。

0754デフォルトの名無しさん

2011/09/18(日) 21:30:20.98

>>750
> マジックナンバー

え？

0755デフォルトの名無しさん

2011/09/18(日) 21:30:44.07

>>750
数値をマジックで書いたら全部アウトかよ。
break 0;を見てなんと間違えたり、
どの値と同期とったりするんだ？

0756デフォルトの名無しさん

2011/09/18(日) 21:35:28.30

>>739
むかしのBASIC的な牧歌的感性

0757デフォルトの名無しさん

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;

0758デフォルトの名無しさん

2011/09/18(日) 21:37:32.71

>>755
だから実際のネスト数と同期とるんだろ

0759デフォルトの名無しさん

2011/09/18(日) 21:40:09.55

>>748の方式だったら大して困らんだろ？
なんかあるの？

0760デフォルトの名無しさん

2011/09/18(日) 21:42:28.97

>>759
ネスト増やしたらコードの意味が変わっちゃうし
そもそもコードが見ただけで何を意図してるのか分からん
それを定数変数やマクロで置き換えた所で修正も面倒
gotoの方がよほど保守しやすい

0761デフォルトの名無しさん

2011/09/18(日) 21:42:47.90

>>749
あれ何らかの理由で例外飛ばせないケースでは自然だよなあ

0762デフォルトの名無しさん

2011/09/18(日) 21:42:52.26

>>757
きちがい

0763デフォルトの名無しさん

2011/09/18(日) 21:46:32.79

>>760
ネスト増やしたらコード変わるの当たり前じゃん。
break n;と定義されてて、ループ抜ける以外の意図って何感じるの？
gotoの方がループ変わるたびにラベル管理しなきゃならなくてよっぽど保守しづらいけど。

0764デフォルトの名無しさん

2011/09/18(日) 21:47:46.24

>>762
だろ。ループ抜ける以外の意味しか無いのにgotoでラベルつけんのも頭おかしい。

0765デフォルトの名無しさん

2011/09/18(日) 21:49:10.55

>>764
おまえがだよ

0766デフォルトの名無しさん

2011/09/18(日) 21:49:31.78

>>739
それはやめてほしい。
今でも if 文の閉じ括弧とループ文の閉じ括弧が混じってると
break でどこに飛ぶのかわかりにくい。

それが何段も抜けるとかもう意味不明

0767デフォルトの名無しさん

2011/09/18(日) 21:56:36.43

今時クソカスコボラーが新規にC業界に殴りこんでくるわけでもなし
事実上goto=脱出と思っておいていいと思うんだが

0768デフォルトの名無しさん

2011/09/18(日) 21:57:52.47

一応聞いておくけど構造化定理くらいは知ってるよね？

0769デフォルトの名無しさん

2011/09/18(日) 21:58:25.62

>>716
まず質問の意図を確認しておきたいんだが、
1. お前らなんでwhile使うの？ifとgotoで同じことできるじゃん
2. お前らgoto不要論についてどう思ってんの？

>>716は1のように見える(明らかにwhileとgoto比較してるし)が、普通知りたいのは2だよな。どっちなんだ？

0770デフォルトの名無しさん

2011/09/18(日) 22:00:51.55

>>768
forの中からforのど真ん中に飛び込んだり
ifの中からforに飛び込んだり
forからifに飛び込まんでもプログラムは書けるから
すんなよって話だろ。

0771デフォルトの名無しさん

2011/09/18(日) 22:02:14.61

>>766
お前に break を扱うことは無理ってことだな。

0772デフォルトの名無しさん

2011/09/18(日) 22:02:59.17

>>766
構文としては既にgotoあるんだから
増えても変わらんだろ。使わなきゃいいし
権力あるならコーディングルールでしばりゃいい。

0773デフォルトの名無しさん

2011/09/18(日) 22:06:18.33

そんなもんより本物のfinallyをだな。デストラクタよりこっちがプリミティブなんだから……

0774デフォルトの名無しさん

2011/09/18(日) 22:08:13.81

どうでもいい

0775デフォルトの名無しさん

2011/09/18(日) 22:08:46.16

>>772
if の括弧なのかループの括弧なのか考慮しながら、
「1, 2, 3,.. 4 ここに飛ぶのかー」
みたいなのは疲れるよ。break ラベル; のがずっといい

0776デフォルトの名無しさん

2011/09/18(日) 22:09:16.08

>>768
goto使わない限りコードのコピーをしなければならない
プログラムフロー構造があるのはご存知ですか?

0777デフォルトの名無しさん

2011/09/18(日) 22:09:19.37

finallyなんか何に使うんだ？
具体的な用途がさっぱり解からん。

0778デフォルトの名無しさん

2011/09/18(日) 22:11:01.61

なにやら break N を使わないといけないという強迫観念患者が混ざってるぞ。

0779デフォルトの名無しさん

2011/09/18(日) 22:11:33.70

>>775
whileとforの数を数えればいいだけだと思うが？
まさか4重ネストとか常用してんの？ループなんてせいぜい3が限度だろ。

0780デフォルトの名無しさん

2011/09/18(日) 22:14:07.30

>>777
>>749

catch(...){ ... throw; }なんてのは割りとよく見かけるんだからfinallyが使えたほうがずっと素直。
unique_ptrのカスタムデリータにラムダ渡してそこで……なんてやるより直接書けたほうがいいだろ？

0781デフォルトの名無しさん

2011/09/18(日) 22:14:43.94

>>779
775 にかかれば五重六重ネストなんて日常茶飯事だよ。

……こいつに C は無理だ。

0782SCHEME餃子 ◆8X2XSCHEME

2011/09/18(日) 22:16:12.97

おまいらマクロの存在を忘れてないか？
見掛け上のネストの数と合わないかもしれないぞ。

0783デフォルトの名無しさん

2011/09/18(日) 22:18:07.35

マクロで暗黙のループが発生するってどんなクソコードだよ。

0784デフォルトの名無しさん

2011/09/18(日) 22:18:11.92

マクロの中で特別注意することも出来ない奴は死んで良いよ

0785デフォルトの名無しさん

2011/09/18(日) 22:19:15.84

>>779
ゴミプログラマの書いたコードを誰も読まなくていいなら goto は問題にならない

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

多重に抜けるってことは、単純な break よりもずっとかけ離れた場所に飛ぶってことだろ。
それを数かぞえながら追うとか悪夢でしかない。
素直に検索で飛べるラベルがいい。

0786デフォルトの名無しさん

2011/09/18(日) 22:20:34.26

>>780
>catch(...){ ... throw; }なんてのは割りとよく見かけるんだからfinallyが使えたほうがずっと素直。
意味が解からん。catch(...){ ... throw; }なんてfinallyと用途が全然違うでしょ。
正常系じゃfinallyと違って動かない。

0787SCHEME餃子 ◆8X2XSCHEME

2011/09/18(日) 22:20:43.80

>>784
書いた奴が死んでもコードは残るんだよ。

0788デフォルトの名無しさん

2011/09/18(日) 22:24:19.47

>>785
だからラベルが欲しいなら定数使えばいいでしょ。
caseだって同じじゃん。あと、バカが居るなら仕事でしょ
レビューで止めればいい。過去に使われて直せないならgotoだって同じ話。
てか、長いループだろうがbreak n;で検索なんていらんだろ。
labelなら要るだろうけど。

0789デフォルトの名無しさん

2011/09/18(日) 22:37:14.24

>>788
定数にしてもどの行に飛ぶかわからんだろうよ。

それにプログラムを読まなくちゃいけないのは、専業プログラマだけじゃない。
科学系研究者の書いたコードなんて現状クソ以外の何物でもない。
しかも有名な奴ほど腐ってるんだ。あれをさらに腐敗させるようなのは導入してほしくない。

0790デフォルトの名無しさん

2011/09/18(日) 22:39:50.43

>>786
catch(...){ throw; } がある場合、gotoによるfinally処理は記述が難しいんじゃないの？　ってことだと思うよ
もし、「超簡単だよ！」って思ったらcodepadで書いて見せてほしい

たぶん、
>unique_ptrのカスタムデリータにラムダ渡してそこで
これより簡単になることはないと思う

0791デフォルトの名無しさん

2011/09/18(日) 22:40:37.70

>>786
その前後で例外が発生してない時も同じ後始末をしてるコードを見たことがないのか？

それに例外が発生してるときに限定したって、catchするとランタイムが例外オブジェクトを捕まえないといけないので
結構裏で処理が走ってるし、C++の例外の形になってないunwind操作がもしあったらすり抜けてしまう。
bool flag = true;
try{
　例外が起きるかも
　flag = false;
}finally{
　if(flag) 後始末
}
のほうが、実は軽いし補足できる範囲も広いんだよ。

0792デフォルトの名無しさん

2011/09/18(日) 22:43:58.07

C使ってた頃ならまだしも、C++使い始めてから、クラススコープ以外でリソース生成した事ないわ。

0793デフォルトの名無しさん

2011/09/18(日) 22:45:36.19

>>789
だからgotoと同じだって
理論的じゃないなぁ。

0794デフォルトの名無しさん

2011/09/18(日) 22:47:31.93

>>789
例外構文も使えそうに無いな。てか絶対使うな。取りこぼしそうだから。

0795デフォルトの名無しさん

2011/09/18(日) 22:50:41.93

インデントはループに限らないんだから、ループかどうか見るために上を見て、
次に飛び先を確かめるために下を見ないといけないってのはあるなあ。
break nだとそれがn回か。

よしループの最後にEND WHILEって明記しようぜ。それならbreak nも有りな気がしてきた。

0796デフォルトの名無しさん

2011/09/18(日) 22:50:47.67

>>791
その処理具体的に何するの？
ディスクリプタのクローズ？
メモリーの解放？
ロックの解除？

0797デフォルトの名無しさん

2011/09/18(日) 22:54:06.64

>>793
同じじゃない。goto は飛ぶ先が必ずラベルだから、検索すれば思考せずに見つけることができる。
多重 break で飛ぶ先に数字を使うなら、
今の上のループの、上のループがどれで、どこで終わっているのか探す手間がかかる。

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

>>794
実際使えてないアホばかり

0798デフォルトの名無しさん

2011/09/18(日) 22:54:49.05

>>795
ifブロック1つが100行、forブロック1つが200行。
そりゃ大変だね。もうループの条件判定だけで
抜けるようにしたほうがいいんじゃない？

0799デフォルトの名無しさん

2011/09/18(日) 22:55:36.53

>>797
だから番号逆に書いたらって。

0800デフォルトの名無しさん

2011/09/18(日) 22:57:50.85

>>>792
finallyだって頻繁に使いたくなるというわけでもない。そうやって組んでる中でごくたまに使いたくなるだけなんだよ
そのごくたまに使いたくなる時のみでさえ、
>unique_ptrのカスタムデリータにラムダ渡してそこで
みたいなfinally節の代替物が関数の先頭に来るやり方になにかもやもやしたものを感じるのでfinallyがほしいなぁと思うことがあるだけ

>>796
>>791じゃないけど俺は忘れた。少なくともここ5年はほしいと思ったことすらない

0801デフォルトの名無しさん

2011/09/18(日) 22:58:17.99

どうせbreak番号導入されたら統合開発環境に、ネスト数補正とか追加されるから気にすんなって

0802デフォルトの名無しさん

2011/09/18(日) 23:00:38.53

いやね、ロケットの軌道計算とか、制御とかには例外処理は必要だろうよ。
ヘタすると宇宙のかなたにとんでいくし。

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

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

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

だから、分野によってはそれがないと致命的かもしれんが、普通の数値計算
では例外処理なんてどうでもいい。C++の掲示板とかBlogには大事だと書かれ
ているが、それは分野による。騙されるなｗ

0803デフォルトの名無しさん

2011/09/18(日) 23:04:56.65

>>802
横レスするが、ロケットとか人工衛星って、電磁波の磁界通過の関係で
高性能CPUはつまんから例外処理とかもタブーよ。
とりあえず待機系を20個とかバカみたいに動かして、
異常が起きたら片っ端からリセット。

0804デフォルトの名無しさん

2011/09/18(日) 23:07:16.76

>>796
そりゃほとんどは確保と解放が対応付いてるよ。そういうのはクラスにすればいい。
>>800も言ってるけど、超稀に対応が取れないレアケースがある。
そういうときにunique_ptrとか持ち出すのもなんだかなーってだけ。

あとまあどうせ1箇所でしか使わないのにいちいちクラス化するのもめんどくせーとか。

0805デフォルトの名無しさん

2011/09/18(日) 23:08:00.96

>>803
こないだ小惑星から帰ってきた人工衛星もそんな感じだったよね。
回路つぎ変えて対応とかさ。

0806デフォルトの名無しさん

2011/09/18(日) 23:11:26.24

>>804
やったねたえちゃん。ラムダで済むね。

0807デフォルトの名無しさん

2011/09/18(日) 23:12:38.96

>>802
コンストラクターと演算子でどうやってエラー返す気だろ。

0808デフォルトの名無しさん

2011/09/18(日) 23:18:45.51

>>806
まあunique_ptr+ラムダで済むから、ローカルクラス作って云々やるよりは遥かにマシになったのは事実なんだよなあ。
既にcatch(...)を書いてる人たちもこれに置き換え……てくれる見込みは全くないけどさ。

0809デフォルトの名無しさん

2011/09/18(日) 23:32:47.82

shared_ptrって実際どういう用途に使われるんだろ。
Factoryクラスとかに使われるんだろうか憂鬱だ。
newしたクラス以外は所有するオブジェクトを
deleteしない。原則自動変数を使うを守ってりゃ済む話だったのに。

0810デフォルトの名無しさん

2011/09/18(日) 23:47:31.77

>>799
一番外まで脱出するケースでしか意味ないじゃん

0811デフォルトの名無しさん

2011/09/18(日) 23:50:57.00

>>783
#define X(略) do { 略; } while(0)
は、全く見ないってもんでもないだろ。

0812デフォルトの名無しさん

2011/09/18(日) 23:51:34.64

>>809
何らかの管理クラスに一括して管理させたいときだな
他で作って、管理クラスに突っ込んでおく

0813デフォルトの名無しさん

2011/09/18(日) 23:53:47.39

break 番号、って、なんかこう……goto 行番号を思い出す……

0814デフォルトの名無しさん

2011/09/18(日) 23:56:49.07

>>811
それクソコードだろ。

0815デフォルトの名無しさん

2011/09/18(日) 23:58:50.78

>>810
いや、ループのネストが増えようが減ろうが脱出ループは変わらなくなる。

0816デフォルトの名無しさん

2011/09/18(日) 23:59:52.79

>>812
そのまとめるオブジェクトを関数スコープかクラススコープに置いといても変わんないんでしょ？

0817デフォルトの名無しさん

2011/09/19(月) 00:01:10.72

labelはアセンブリを思い出すな、というか現役で使ってるから混じるな。

0818デフォルトの名無しさん

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を抜けるようになる
　　　}
　　}
　}
}

0819デフォルトの名無しさん

2011/09/19(月) 00:03:47.13

あってるよ。必ず外から2個目を抜ける。ラベルみたいに書き換える必要はない。

0820デフォルトの名無しさん

2011/09/19(月) 00:04:31.33

4重ループとか頭おかしいだろ・・・
goto以上に読みづらいわ

0821デフォルトの名無しさん

2011/09/19(月) 00:06:39.37

>>818
gotoでもラベルの位置変える必要があるよな
Bの前か後かは絶対決めなきゃならない

0822デフォルトの名無しさん

2011/09/19(月) 00:16:12.60

break n;の件だけどあれじゃん
要するにnに関数ブロック以上の制御ブロック全てを含めりゃ
ネストの深さだけで判断できて解決するんだろ
オフサイドっぽいかんじで

0823デフォルトの名無しさん

2011/09/19(月) 00:19:19.91

>>811
Cでは便利でもC++で使う意味はあまり……

実用上gotoで十分と思うけどねえ。nがそこまで大事な子に見えないし。

0824デフォルトの名無しさん

2011/09/19(月) 00:21:54.31

>>811
そんなモンの中に break 突っ込む奴はイカレてるだろ。

0825デフォルトの名無しさん

2011/09/19(月) 00:22:21.07

まぁ今更締め切られたもんに機能追加する妄想しても仕方あるめェよ。

0826デフォルトの名無しさん

2011/09/19(月) 00:23:42.35

>>821
while(C)についてるってのは変わらんだろ
ループ追加しても普通は位置なんて変える必要はないのだから
大して問題にならない
ネスト深くなるからって関数化する時もラベルならそのままコピーできる

なにより定数で置くにしても
最終的には自分で数を数えて書かないといけないとか
バグの温床じゃないですかー

0827デフォルトの名無しさん

2011/09/19(月) 00:24:21.87

>>825
まだC++1xがあるさ

0828デフォルトの名無しさん

2011/09/19(月) 00:24:45.94

switch(x)do
{
      default;
      break;
      case 0:
      retrun 0;
      case 1:
}while(0);;

ある意味最凶やね

0829デフォルトの名無しさん

2011/09/19(月) 00:26:50.05

>>826
Bについて値を変えなくていいのは変わらんし
五十歩百歩目糞鼻糞。

0830デフォルトの名無しさん

2011/09/19(月) 00:28:09.98

>>827
何十年後になるんだろ。
そういや詳細知らないけど前回は03だっけ。

0831デフォルトの名無しさん

2011/09/19(月) 00:31:59.20

>>809
だよねー

0832デフォルトの名無しさん

2011/09/19(月) 00:38:31.63

03はマイナーチェンジだから実質98と考えた方がいい

0833デフォルトの名無しさん

2011/09/19(月) 00:46:56.38

プログラムの最初から最後まで使う→main関数で値を持つ
2つのウィンドウ等で共有する→ウィンドウを所有するオブジェクトか関数が共有するオブジェクトを持っておく
条件によって返すオブジェクトが変わる関数がある→関数でなくオブジェクトにして保有するオブジェクトをきりかえてやればいい。

share_ptrの必然性はないわな。

0834デフォルトの名無しさん

2011/09/19(月) 01:12:30.15

誰も言及していないけど break n は php には既にある。
内側から n 個目のループを抜ける仕様。

0835デフォルトの名無しさん

2011/09/19(月) 01:13:15.94

最後日本語でおk
てか右辺値参照のおかげでただ返すだけならunique_ptrで良いし

0836デフォルトの名無しさん

2011/09/19(月) 01:18:26.97

昔は配列にnewしたの突っ込む時はptr_vectorかshared_ptrのvectorを使ってたけど
右辺値参照のおかげでunique_ptrのvectorで十分になったので
shared_ptr使うケースは減りそうだな

0837デフォルトの名無しさん

2011/09/19(月) 01:39:33.61

>>738
出来るからするなんて誰も言ってないと思うが。

0838デフォルトの名無しさん

2011/09/19(月) 02:04:41.11

>>809,831,833
こういう考えの人って多いの？

複雑なアプリケーションでは所有権が頻繁に移動するケースがあるから
shared_ptrが標準に取り込まれたと思うんだけど
所有権の移動を自力管理しないのは怠慢／所有権を移動するような設計がアホ、とか言われちゃうんだろうか
うーむ・・・周りに嫌がられたくないし、しばらく使わないでおこうかな・・・

0839デフォルトの名無しさん

2011/09/19(月) 02:40:53.00

>>838
移動ならunique_ptrでいいんじゃない？

基本的に自動変数を使えばいいってのはその通りだが
Factoryに削除のためのインターフェースをつけるのは俺はやらないな
所有権をunique_ptrに移譲してしまえば使い終わった/例外発生時に自動削除してくれるのにそれをわざわざ手動で削除することもないだろう

0840デフォルトの名無しさん

2011/09/19(月) 02:41:44.23

>>838
所有権を共有するわけでもないのに shared_ptr 使うのはアホだろ。
名前見ろっていう。

0841デフォルトの名無しさん

2011/09/19(月) 02:47:30.90

>>840
まぁそれはある意味仕方がない
0x以前は"移動"がなかったんだから

0842デフォルトの名無しさん

2011/09/19(月) 02:47:57.71

>838
所有権が移動する場面の安全対策は重要。むしろRAIIを使わずに管理するのがアホだろ。
極端な話、shared_ptr吐き出すnewがあっても良いと思うが。

あとはリソースを複数オブジェクトで共有する場合はshared_ptr必須だね。

0843デフォルトの名無しさん

2011/09/19(月) 02:49:30.51

>>842
make_sharedってのがある

0844デフォルトの名無しさん

2011/09/19(月) 02:49:43.02

>>841 auto_ptr ...

0845デフォルトの名無しさん

2011/09/19(月) 02:53:08.63

>>844
それはやめとけ

0846デフォルトの名無しさん

2011/09/19(月) 03:08:21.28

なんでだよー。わかってて使う分には（特に移植性とか）最強なのに。
あ、コンテナは boost ptr_container ね。

0847デフォルトの名無しさん

2011/09/19(月) 03:34:14.31

他の言語にあるのに何でC++11に入らなかったんだリスト
・ラベル付き（or ネスト数付き）break/continue
・finally
・プロパティ
・restrict修飾子

まだまだある？

0848デフォルトの名無しさん

2011/09/19(月) 03:45:53.14

C99のdesignator

0849デフォルトの名無しさん

2011/09/19(月) 03:49:18.53

C++ってrestrict入ってないのか・・・

0850デフォルトの名無しさん

2011/09/19(月) 05:29:17.30

finallyはRAIIで代用出来るから要らない
というよりは、finallyがあったとしてもなるべくRAIIを使うべきというくらいだ

0851デフォルトの名無しさん

2011/09/19(月) 06:46:31.90

>>847
restrictはC99だから上位互換として実装されるんじゃないの?

0852デフォルトの名無しさん

2011/09/19(月) 06:50:52.71

されないよ
別にC++はC99との完全互換は目指してないから

0853デフォルトの名無しさん

2011/09/19(月) 06:51:18.91

>>850
上にもあるけどラムダで済むようになったしね。
汚いネストが減る分こっちの方がいい。

0854デフォルトの名無しさん

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言語のスコープガード文に似てるね

0855デフォルトの名無しさん

2011/09/19(月) 09:13:49.66

>>847
前々スレ位に出てたけどシンボル。

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

function<Function>(this);
と関数からシンボルを独立させて渡したい。

0856デフォルトの名無しさん

2011/09/19(月) 09:22:58.96

メンバ関数ポインタの取得でクラス名は必須だけど、
そうなった経緯ってどんなの？

0857デフォルトの名無しさん

2011/09/19(月) 10:02:42.95

>>856
式で使う値だからでしょ。

0858デフォルトの名無しさん

2011/09/19(月) 10:23:06.53

VC6はメンバ関数名だけで取れてたし、実装できないわけじゃないでしょ？

0859デフォルトの名無しさん

2011/09/19(月) 12:14:33.27

ばかか

0860デフォルトの名無しさん

2011/09/19(月) 12:58:31.08

そんなバカみたいにバカいわんでもバカじゃあるまいし
そんなにひとをバカにしちゃいかんで、
バカだ星のバカ大学のバカ学長のバカ息子のバカ友達に掘られるよ。

0861デフォルトの名無しさん

2011/09/19(月) 13:04:29.47

VisualStudioに可変テンプレートないとかなんなの？
舐めてんの？

0862デフォルトの名無しさん

2011/09/19(月) 13:29:23.39

>>861
gcc-4.6.1 でもまだ実装が不完全でイライラしてるくらいで
全く対応する気なしとか何を考えてるんだと

0863デフォルトの名無しさん

2011/09/19(月) 14:17:27.94

イラネー機能のせいにしてコーディングしないタイプ

0864デフォルトの名無しさん

2011/09/19(月) 17:36:27.42

>>847
上にもあるけど、goto case

0865デフォルトの名無しさん

2011/09/19(月) 17:36:30.90

>>857
もっと詳しく

0866デフォルトの名無しさん

2011/09/19(月) 17:42:18.65

C++ならラベル追加すれば素直にgotoできるし、
goto caseより読みやすくできると思うぞ

0867デフォルトの名無しさん

2011/09/19(月) 17:59:14.08

そうか？　感性の違いだな

0868デフォルトの名無しさん

2011/09/19(月) 18:00:54.88

例えばcaseが複数並んでる所に飛ぶ場合、
どれか１個だけ抽出してgoto caseするより
ラベルにした方が意味が分かりやすいっしょ？

0869デフォルトの名無しさん

2011/09/19(月) 18:09:04.03

複数並んでたら、そうだな。
でも1個の場合は goto case の方が良い。

0870デフォルトの名無しさん

2011/09/19(月) 18:10:33.73

あと、なぜ別のcaseに飛ぶのか、という理由は、
単に処理が同じだからであって、そのcaseの値に特別な意味があるわけでもない
gotoならcase以外に飛んで２つ以上のcase共通の後処理を素直に行う事もできるし、
caseに飛ぶよりは意味合いが分かりやすくなると思われ

0871デフォルトの名無しさん

2011/09/19(月) 18:14:05.94

確かにその通りだけどｸﾞﾇﾇ

そこまでキッチリしにゃきゃならんの？　日曜マには分からん。

0872デフォルトの名無しさん

2011/09/19(月) 19:01:27.61

>>870
それダイクストラがやめろっていってたことじゃないのか?
スイッチのネストで解決出来ない?

0873デフォルトの名無しさん

2011/09/19(月) 19:31:44.99

switchのネストとかさらっと恐ろしいこと言うのやめて

0874デフォルトの名無しさん

2011/09/19(月) 19:40:26.12

二回も条件判定が出ると、修正ミスが起こりそうなのがね
まあ俺もこんなgoto使った事ないけど
goto caseよりはマシだな

0875デフォルトの名無しさん

2011/09/19(月) 19:45:50.08

ダイクストラの言う事が全てではないな
基本は複数のcaseで使われる処理を別関数化すると思うけど
あまりに冗長になるならgotoの方が綺麗に書けると思われ

0876デフォルトの名無しさん

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);
と呼ぶとどうなる？
答えはメール欄

0877デフォルトの名無しさん

2011/09/19(月) 19:51:38.40

あいうえおって表示されるけど・・・

0878デフォルトの名無しさん

2011/09/19(月) 19:59:25.56

>>876は何がしたかったんだ？

0879デフォルトの名無しさん

2011/09/19(月) 20:00:06.06

あいうえおだな

0880デフォルトの名無しさん

2011/09/19(月) 20:02:49.93

うん、あいうえおだ

0881デフォルトの名無しさん

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.

0882デフォルトの名無しさん

2011/09/19(月) 20:03:00.42

>>876
お前に switch 文は無理だ。

0883デフォルトの名無しさん

2011/09/19(月) 20:18:33.42

4スイッチの文は入れ子にすることができます。caseまたはdefaultラベルは、それを囲む最小のスイッチに関連付けられています。

0884デフォルトの名無しさん

2011/09/19(月) 20:19:32.52

>>876「コンパイラのバグだ！」
他「いや、お前のバグだろ」

よくあるこれ。

0885デフォルトの名無しさん

2011/09/19(月) 20:24:16.87

まあ大昔そういう時期があって
そのまま覚えてるだけかもしれないから
そろそろ許してやろうぜ

0886デフォルトの名無しさん

2011/09/19(月) 20:28:42.82

あいうえおﾜﾗﾀ

0887デフォルトの名無しさん

2011/09/19(月) 20:30:26.66

>>885
組み込み系か昔のコンパイラあたりでハマるケースがあったのかも知れないね
case -1:ってのが何かのポイントのような気がするが、解説もないし真相は闇の中か・・・

0888デフォルトの名無しさん

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:
//共通処理
}

0889デフォルトの名無しさん

2011/09/19(月) 21:11:07.48

>>888
>>874

0890デフォルトの名無しさん

2011/09/19(月) 21:45:40.84

いやこれで、直し忘れって
gotoの方が忘れるだろ

0891デフォルトの名無しさん

2011/09/19(月) 22:09:27.57

case追加するだけでいい場合、
片方にだけcase追加して満足する場合があるんだよな、これが

0892デフォルトの名無しさん

2011/09/19(月) 22:10:56.71

そもそも最近switchとかあんま使わないけどな

0893デフォルトの名無しさん

2011/09/19(月) 22:11:51.73

caseはただのラベルだから、switchの入れ子はスコープ無視して
外のswitchからボコボコ飛んで来て滅茶苦茶になるからダメって教わってきたんだけど

最近は大丈夫なんだな
VC2010だと確かにあいうえおだわ
VC6やGCC3の頃はスコープ無視して最初のラベルに飛ぶようになってたはず

0894デフォルトの名無しさん

2011/09/19(月) 22:12:56.88

switch以外の場合はスコープ無視するけど
switchだけは無視しないぞ

0895デフォルトの名無しさん

2011/09/19(月) 22:20:16.99

昔のコンパイラはswitchのスコープも無視してたんだよ
現にそれで痛い目にあった事があったからこんな事書いてるわけで

今は規格も実装もちゃんとネスト出来るようになってるらしいからいいです
昔話で混乱させてすみませんでした

0896デフォルトの名無しさん

2011/09/19(月) 22:34:45.65

VC6の頃もそうだっけかな・・・
あの頃はまだ規格ができたばかりの時期だったし
準拠率ひどいもんだったのであり得るとは思うけど、
C89だとそこんとこどうなんだろう？

0897デフォルトの名無しさん

2011/09/19(月) 22:35:12.62

>>891
意図して共通処理実行させるのに忘れる理由が解らん。
むしろ共通処理へのcaceを書いてないときは、
共通処理が実行されないことを望むだろ。

0898デフォルトの名無しさん

2011/09/19(月) 22:36:55.79

>>897
コピペや置換にミスはつきものなんだよ
理屈じゃない
人間は優秀だとしても100%正確に何かをできるとは限らないのだ

0899デフォルトの名無しさん

2011/09/19(月) 22:38:03.09

そのとおり計算上ほぼ百％安全だったはずの原発もポポポポーンしてしまうものなのだ

0900デフォルトの名無しさん

2011/09/19(月) 22:51:59.11

あれは計算の方を弄って100%を装ってただけだろーがｗ一緒にスンナ？

0901デフォルトの名無しさん

2011/09/19(月) 23:04:18.36

> 外のswitchからボコボコ飛んで来て滅茶苦茶になるからダメって教わってきたんだけど

上司に恵まれなかったんだな
バグが原因なのに、言語のせいにする上司
可哀想に
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　（笑）

0902デフォルトの名無しさん

2011/09/19(月) 23:09:22.97

C89でもswitchは普通にネストできるね
VC6でネストできないってのは流石にないんじゃないの？　時代的に

0903デフォルトの名無しさん

2011/09/19(月) 23:10:30.06

>>898
goto はその辺酷いだろ。

0904デフォルトの名無しさん

2011/09/19(月) 23:11:23.74

あいうういになるコンパイラが特定されるまでは
>>876の間違い。そんなふうになるコンパイラはないってことで、
スレは進みます。

0905デフォルトの名無しさん

2011/09/19(月) 23:19:11.01

>>903
印象だけで語られても

0906デフォルトの名無しさん

2011/09/19(月) 23:26:46.56

印象もくそも入り組むし事実だと思うけど。

0907デフォルトの名無しさん

2011/09/19(月) 23:29:00.50

>>905
試しにgoto cace とやらを書いてみて。

0908デフォルトの名無しさん

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;
}

0909デフォルトの名無しさん

2011/09/19(月) 23:35:27.65

１つ目YじゃなくてXだよ
ミスったよ
まさにコピペの罠

0910デフォルトの名無しさん

2011/09/19(月) 23:36:31.59

Cっていうか、かなり足りないC言語ではswitchネストしてbreakすると
一番外まで抜けてしまうコードを吐くこともあるコンパイラには出会ったことあるな
MPLABのPIC用のコンパイラだけどさ

0911デフォルトの名無しさん

2011/09/19(月) 23:37:45.54

酷いとしか言いようがない

0912デフォルトの名無しさん

2011/09/19(月) 23:45:23.15

そこまで酷いコンパイラになると
もう規格だの実装だの言うレベルにすら達してないな

0913デフォルトの名無しさん

2011/09/20(火) 00:15:56.98

template <typename T, typename U, template <class...> class C>
C map(function<U(T)> f, const C<T>& xs) {
C ret;
transform(xs.cbegin(),xs.cend(),back_inserter(ret),f);
return move(ret);
}

これ、
map<int,int>([](int x){return x+1;},xs)
って呼んであげないとコンパイル通らないのですが、何とかなりませんか？
マクロ使えば一瞬なのに・・・

0914デフォルトの名無しさん

2011/09/20(火) 00:25:52.22

lambdaはfunctionじゃないからUは推測できない
function<U(T)>じゃなくて直接Lとかにして
その戻り値の型を取得するといいよ

0915デフォルトの名無しさん

2011/09/20(火) 00:26:50.27

どう書きたいんだ。
<int, int>を無くしたいの？

0916913

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
そうです。

0917913

2011/09/20(火) 01:03:26.85

返信遅れましたが、いけました。
イテレータ渡すときもそうですけど、型の情報がコードの見た目に反映されなくて嫌いです。
functionは記法としていいなぁ、と思ってたんですけどね・・・。

ところでmoveの使い方ってあってます？書かなくてもよかったりして。

0918913

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>&)'
のエラーになります。

0919デフォルトの名無しさん

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);
}

0920デフォルトの名無しさん

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;
}

0921デフォルトの名無しさん

2011/09/20(火) 02:08:50.80

そのための名前空間じゃないの

0922デフォルトの名無しさん

2011/09/20(火) 10:24:17.60

名前空間をなんでテンプレの引数にとれないのかな
クラスで代用しろってことなんかな。
広域関数入れ換えられないからたまに欲しくなる。

0923デフォルトの名無しさん

2011/09/20(火) 12:48:57.47

可変テンプレート使えないコンパイラでもBoost.Egg(ただしReject)が代用できる

0924デフォルトの名無しさん

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)

0925デフォルトの名無しさん

2011/09/20(火) 19:23:32.01

ｷﾓｲﾖｰ

0926デフォルトの名無しさん

2011/09/20(火) 20:03:25.53

>>908
ないわ

0927デフォルトの名無しさん

2011/09/20(火) 21:56:55.07

もう、基地外コードやめてくれる？
そんなの、お前ら密教仲間で使っとけ

0928デフォルトの名無しさん

2011/09/21(水) 08:11:35.95

>>919,920
ありがとうございます。これで解決してますが、やっぱ
decltypeは嫌いですねぇ。typeofに逆戻りしてる感じが。

そもそもこのmapって効率悪いけどその場で書くことを目的としていたので、
どうせゴタゴタするならproxyつくるほうに注力するかな・・・。

0929デフォルトの名無しさん

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
{
std::vector ret;
std::transform(xs.cbegin(),xs.cend(),std::back_inserter(ret),f);
return std::move(ret);
}

こういう事できたらいいんだが
（まあそれでもキモさにそこまで変わりはない気もするが）

0930デフォルトの名無しさん

2011/09/21(水) 21:37:51.19

なんでC++な人はLispじゃなくてHaskellに流れてくんだろ
OCamlならまだわかるんだけど

0931デフォルトの名無しさん

2011/09/21(水) 21:44:04.30

Lispなんてゴミ今さらやるかよw

0932デフォルトの名無しさん

2011/09/21(水) 21:44:43.27

それなりに経験のある人なら、Lisp はもうやったからじゃないの。

0933デフォルトの名無しさん

2011/09/21(水) 21:46:04.63

C++な人でLispやっている人見かけないけどな
話題にすらならない

0934デフォルトの名無しさん

2011/09/21(水) 21:58:41.47

やはり型がないとやる気が起きない

0935デフォルトの名無しさん

2011/09/21(水) 21:58:49.41

Lispの話なんかして
Lisperに絡まれたら嫌だし

0936デフォルトの名無しさん

2011/09/21(水) 22:04:45.14

Lisperって面白いことやっている人いないよね
態度はでかいんだけど

0937デフォルトの名無しさん

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 map(BFunc f, const pair<C<T1>,C<T2>>& zs);

0938デフォルトの名無しさん

2011/09/21(水) 22:22:00.86

naiveにzip書いてみたのですが、
returnするとき、コピーコンストラクタが呼び出されてる気がします。
なんかうまい手はあります？
（ref(...)とか、使い方しらないので0xのrval_refでそういうのあったりするのかなーとか）

ちなみにpair<const C<T1>&, const C<T2>&>を返すとセグフォだったので諦めました。

0939デフォルトの名無しさん

2011/09/21(水) 23:00:34.88

戻り値にmoveはいらないだろ
あと、それzipじゃなくてただのmake_pairじゃん

0940デフォルトの名無しさん

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;
}

0941デフォルトの名無しさん

2011/09/22(木) 00:33:41.25

>>940
完璧です。ありがとうございます。
map(f,zip(xs,ys))も、多重定義でmap(f,xs,ys)にしとくことにしました。
どうせこのパターンでしか使わないだろうし。

あとはreduceか・・・クロージャは素直に渡せるだろうか。
第一引数はconst F&にすればいいのか？

0942デフォルトの名無しさん

2011/09/22(木) 04:46:12.58

http://cpplover.blogspot.com/2011/09/blog-post_21.html

0943デフォルトの名無しさん

2011/09/22(木) 07:22:06.76

そのうちロベールさんがいい本を出してくれるさ

0944デフォルトの名無しさん

2011/09/22(木) 07:37:10.83

言い訳を重ねて逃げるってのはニートの特徴だわな

0945デフォルトの名無しさん

2011/09/22(木) 09:40:24.24

ただの愚痴だろ。たまに俺も自分のやってることに自信が無くなる。
無心にやり遂げちゃって決着ついた後なら案外成功でも失敗でも気にならんもんだけど。

0946デフォルトの名無しさん

2011/09/22(木) 09:51:37.93

>>930
そりゃ特殊化と同じ事できるからじやね。
あと俺はたまにlisp使う。

0947デフォルトの名無しさん

2011/09/22(木) 11:06:53.88

>>946
なんとなくわかった
ちなみに自分は数式処理がどうしても必要なんでlispからは離れられない

0948デフォルトの名無しさん

2011/09/22(木) 11:19:39.96

>>933
OpenC++でMOPとか
template駆使してLisp処理系モドキとか、
結構いるんじゃないの。
Boost-dev MLでもSchemeの例あげる人いるし。

0949デフォルトの名無しさん

2011/09/22(木) 11:23:00.60

>>946
特殊化はCLOSでもできるし、
むしろあっちが最近の特殊化の流れの大元だけど、
まあもはや流行りじゃないんでしょうねえ。

0950デフォルトの名無しさん

2011/09/22(木) 11:47:41.95

autoキーワード使いまくるのは良くないのかな？
たとえばintのところも全部autoにしてるんだけど

0951デフォルトの名無しさん

2011/09/22(木) 11:55:09.29

intなのかstd::size_tなのかstd::ptrdiff_tなのか
ぱっと見はっきりしてるんならいいんじゃない？

0952デフォルトの名無しさん

2011/09/22(木) 12:38:03.44

>>950
それがだめじゃスクリプト言語もダメって事になるだろ。

0953デフォルトの名無しさん

2011/09/22(木) 12:38:53.72

スクリプト言語はダメだろw

0954デフォルトの名無しさん

2011/09/22(木) 12:58:42.36

OO的側面からみたら宣言型を明示しなくてよいならそれに越したことはない。
smalltalkだってsimulaの派生なのに宣言型はもってないしね。
OOらしく依存性を下げたければ出来る限り宣言型でなく
オブジェクト自身の型に委ねるべきだ。

まあそれ以前に11規格は今すぐ使っていいものではないけど。

0955デフォルトの名無しさん

2011/09/22(木) 14:22:31.22

functionとかautoを使わないで「引数がAで返り値がRになるラムダ式」っていう型は作れないの？

0956デフォルトの名無しさん

2011/09/22(木) 14:26:41.05

作れない

0957デフォルトの名無しさん

2011/09/22(木) 14:49:40.47

テンプレ使えば作れますん

0958デフォルトの名無しさん

2011/09/22(木) 22:34:06.11

GCC4.6で

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

ってやると「まだ実装されてない」っておこられるけど、
これって仕様としてはアリなのですか？

0959デフォルトの名無しさん

2011/09/22(木) 22:36:31.38

明らかに
n+sum<ns>::value
だった。すみません。

0960デフォルトの名無しさん

2011/09/22(木) 22:42:37.90

n+sum<ns...>::value じゃないの
まあ未実装みたいだけど

0961デフォルトの名無しさん

2011/09/22(木) 22:46:56.95

main.cpp:9:40: 残念ですが未実装です: cannot expand ‘ns ...’ into a fixed-length argument list

切ない

0962デフォルトの名無しさん

2011/09/22(木) 23:58:24.70

「残念ですが」の余計な一言がイラッとさせる

0963デフォルトの名無しさん

2011/09/23(金) 00:00:48.36

ぷぷっ、未実装ですよJKｗｗｗｗ

0964デフォルトの名無しさん

2011/09/23(金) 01:21:12.88

>>950
リテラルで初期化するところは全部autoにしちゃってるな

0965デフォルトの名無しさん

2011/09/23(金) 01:46:51.61

それてfloat/double、short/int/longの適用次第計算中の精度が落ちたりする弊害出たりするんじゃね？

0966デフォルトの名無しさん

2011/09/23(金) 01:59:47.23

main.cpp:9:40: どうして実装してると思ってしまったのかな？ちょっとびっくりしました(笑): cannot expand ‘ns ...’ into a fixed-length argument list

0967デフォルトの名無しさん

2011/09/23(金) 07:52:04.50

>>965
auto関係ない

0968デフォルトの名無しさん

2011/09/23(金) 08:07:45.94

リテラルが何の型になるかって環境依存だから
autoにしない方がいいと思うけど

0969デフォルトの名無しさん

2011/09/23(金) 08:08:50.63

整数リテラルは、ね

0970デフォルトの名無しさん

2011/09/23(金) 08:56:14.38

>>964
本末転倒も甚だしいな。

0971デフォルトの名無しさん

2011/09/23(金) 10:54:41.28

autoはコードの可読性が下がるので明示しろ派との宗教戦争が勃発すると予言しておこう

0972デフォルトの名無しさん

2011/09/23(金) 11:00:02.92

そのうちautoはラムダとイテレータだけに使っとけよみたいな案がでます

0973デフォルトの名無しさん

2011/09/23(金) 12:47:55.90

auto a = -2147483648 * 1;
auto main() { }

0974デフォルトの名無しさん

2011/09/23(金) 13:18:32.27

C++0xの追加要素のせいで過去のコードがバグるっていう可能性はありますか？

0975デフォルトの名無しさん

2011/09/23(金) 13:53:10.06

理屈の上では可能性はあるけど現実的には実際に使われてるC++98/03準拠のコードがC++11で動作が変わるということはほぼありえない。
もっともコンパイラのC++11対応(=バージョンアップ)の結果、古いバージョンでの独自拡張や規格違反だった仕様が変更されて
それに依存していたコードの動作が変わる可能性ならばそれなりにある。

0976hiding

2011/09/23(金) 14:05:01.75

一番でかいのは文字列リテラルからconst除去したポインターに変換できなくなったことだろ。
Cに毛の生えた程度の糞コードは軒並みエラーになるだろ。

0977hiding

2011/09/23(金) 14:05:43.16

専ブラ使ってると、ついついコテハン記録機能がorz

0978デフォルトの名無しさん

2011/09/23(金) 14:13:42.98

>>976
実際には、あんまり派生言語対応とか考えられてないCライブラリのヘッダーが使えなくなって、
やむをえずコンパイラの互換性オプションを変更するはめに……ってなりそうだけどな

0979デフォルトの名無しさん

2011/09/23(金) 14:45:49.79

コンパイルできなくなるのはたいした問題ではなくあるいは逆に喜ぶべきことであったりする。
もし修正なしにコンパイルはできるが動作が変わることがあったりしたら地獄を見る。

0980デフォルトの名無しさん

2011/09/23(金) 14:55:31.72

03のstringでコンパイルしたobjファイルを0xでつかおうとすると死ぬ？

0981デフォルトの名無しさん

2011/09/23(金) 15:17:10.98

次スレC++11でよろしくな

0982デフォルトの名無しさん

2011/09/23(金) 15:56:29.44

C++11/C++0x 14
http://hibari.2ch.net/test/read.cgi/tech/1316760961/

0983デフォルトの名無しさん

2011/09/23(金) 18:26:33.36

ところで、あんた達、このC++11の仕様を仕事に使う気(というか、もう勇気)
あるん？

まったく、くだらん。せいぜいマスターベーションでもしてろ、馬鹿がｗ

0984デフォルトの名無しさん

2011/09/23(金) 18:55:30.04

>>980
03でコンパイルしたobjと0xでコンパイルしたobjで使用してるstringの実装が異なっているときに
03objで生成したstringを0xobjで受け取って使ったりその逆をやったりすればしねるかもしれない。

0985デフォルトの名無しさん

2011/09/23(金) 19:34:04.50

>>983
下っ端の教育とかまで考えるとちょっと踏み込む勇気いるよね

0986デフォルトの名無しさん

2011/09/23(金) 19:44:57.40

右辺値参照はSTLに組み込まれて速くなるだけでいいや

ラムダ式は多用すると思う、ってかgccでは既に多用してる

0987デフォルトの名無しさん

2011/09/23(金) 21:44:00.69

使い勝手悪かったalgorithmさんが
これで活躍してくれるかも

0988デフォルトの名無しさん

2011/09/23(金) 21:50:08.38

range版algorithmとrange adaptorが来るまでは標準のalgorithmは使う気にはなれない

0989デフォルトの名無しさん

2011/09/23(金) 22:07:06.11

まだないんだっけ？
コンセプトさんがいないせいなのか

0990デフォルトの名無しさん

2011/09/23(金) 22:17:56.81

下っ端はライブラリ作らないんだからむしろautoとラムダだけ教えればいいわけで楽勝なんでは

0991デフォルトの名無しさん

2011/09/23(金) 22:21:57.13

下っ端がどうとか底辺の話はマ板でやってくれ

0992デフォルトの名無しさん

2011/09/24(土) 02:16:46.11

うめるか

0993デフォルトの名無しさん

2011/09/24(土) 02:18:09.07

>>990
ライブラリ的にはスレッドサポートが大きいと思うけど
atomicは楽勝なのだろうか

0994デフォルトの名無しさん

2011/09/24(土) 03:28:37.10

ウリもラムダ式は使いたいニダ

0995デフォルトの名無しさん

2011/09/24(土) 04:36:46.23

うめとくか

0996デフォルトの名無しさん

2011/09/24(土) 13:54:52.17

うめる

0997デフォルトの名無しさん

2011/09/24(土) 13:57:20.95

うめてんてー

0998デフォルトの名無しさん

2011/09/24(土) 14:45:12.63

C++998

0999デフォルトの名無しさん

2011/09/24(土) 14:45:30.22

C++999

1000デフォルトの名無しさん

2011/09/24(土) 14:45:51.02

C++1000

1001１００１

Over 1000Thread

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