C++0x 9

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

2010/03/27(土) 02:13:56

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

2010/03/27(土) 02:29:18

○禿
校長先生。
不老不死も研究していて、350年後に問題点を全て解決した新パラダイムのC++をリリースする事になる。
ただし頭髪は復活しない。

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

2010/03/27(土) 02:33:23

C++学園の人々：0a年春の巻

○コンセプトさん（幽霊）
かつての痕跡が校内から着々と消されつつあるのを草葉の影で眺めている。
彼女の居た14.10番教室はオバケが出るという噂で閉鎖中。

○ラムダさん
そろそろみんな制服の柄にも慣れたらしく、何も言われなくなってきた。
それどころか、関数さんがラムダさんとお揃いの服を着たいと言いだして物議を醸している。

○右辺値参照さん
ここへ来て急に彼女のせいで校則が変わることになったらしい。
彼女自身はすっかり学園に馴染みつつあるが、聴講生へのイジメが酷くならないか心配している。

○拡張for文さん
服がクリーニングされそうな様子は一向にない。
屋上で「死にたい」と虚ろな目をして呟く様子がよく目撃されている。心配である。

○constexprさん
従姉妹のconstさんと同じく地味な実力派。しかし意外と頭が悪く、単純な話しか理解できない。
「りかーしぶ」の振り回し方次第ではカオスになりかねないので、周りの大人のサポートが大事である。
なぜかstatic_assertさんとは仲が悪い。

○type_traitsさん
最近ますます調子に乗って手が付けられなくなっている。
この間は「私だけで良かったんや！コンセプトなんか最初からいらんかったんや！」と言い放ち
static_assertさんにドロップキックを食らった。

○static_assertさん
暴走するtype_traitsさんとテンプレ部に振り回されて気苦労が絶えない。
姉貴はリリースコンパイルで逃げ出せるからいいよなーと愚痴りつつ仕事を真面目にこなす苦労人。

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

2010/03/27(土) 02:33:55

○initializer_listさん
「ねえねえ配列さん、なんでコンストラクタさんと仲良くしないの？」「新入生が来たら仲良くするよ！」
定番と化しつつあるこのやりとりの繰り返しで過剰な期待が勝手に高まりつつある。
本人はあまり何も考えていない。

○テンプレート可変長引数さん
テンプレ部にはすっかり馴染んだが、相変わらず一般生徒からは「あんた何の役に立つの？」
と受けが悪い。最近はもう面倒臭いのでいちいち説明するのをやめた。

○autoさん
苦楽を共にしたregisterさんはついにD組に落第してしまった。
しかし一報を聞いたautoさんの反応は「ふーん、そう」という素っ気ないものだった。
昔の彼女はもういない。

○decltypeさん
一人前の型としての振る舞いも身につけ、いよいよ活躍が期待される所だが、
服の違いで性格が変わる悪癖はまだ直っていない。
いつか必ず問題を起こすと一部の先生からマークされている。

○ユーザー定義リテラルさん
「まだいたのか」と先生に暴言を吐かれ、体育館の陰で泣いていた。

○nullptrさん
誰もNULLさんと見分けが付かないので、既にこっそり通学していると噂されている。

○long longさん
intさんに「ほら！あんたはこっちでしょ！」と間違えて上級生のクラスに連れて行かれた。

○Raw String Literalさん
「お前全然Rawじゃねえじゃん」という状況は、トライグラフさんが譲る形で解決しつつある。
ちなみにトライグラフさんはしぶとく落第を免れ続けてるらしい。

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

2010/03/27(土) 02:34:55

○unique_ptrさん
コンテナ部とも仲良くできます！あの女とは違うんです！と自分を売り込んでいるが、
みんなのauto_ptrさんのトラウマはなかなか払拭しきれず、苦戦している。

○shared_ptrさん
ライブラリ部が誇るご存じ優等生中の優等生。早く来てくれ。

○unordered_map・unordered_setさん姉妹
名字はhashが良かったが、大人の事情で付けられなかった。
おかげでmap・setさん姉妹との違いをいちいち説明する羽目に。

○Regular expressionさん
Perl学園ではバカにされていたが、ここでは大歓迎。
満更ではないものの、学園の行く末に一抹の不安を抱いている。

○Atomic operationさん
彼女と話していて業を煮やしたとある生徒が「こまけえこたぁいいんだよ！」と叫んで飛び出し
10分後に未定義動作にボコボコにされて帰ってきた。

○threadさん
最大のライバルであるpthreadさんを蹴落とすべく日々努力しているが、
親友のラムダさんがpthreadさんとも親しくなりそうで焦っている。

○System error supportさん
ユーザー定義リテラルさんとよく一緒に弁当を食べている。

○progress_displayたん
System error supportさん達と一緒に弁当を食べようとしたら断られた。

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

2010/03/27(土) 03:43:10

○attributeさん
他の学校に、かならず一人はいる娘なので、学校側としても、しかたなく、入校させた。
服のセンスが、lambdaさんに負けず劣らず、相当悪い。
lambdaさんと、かぶっている帽子が、見る角度によっては、似ていることがあり、少々問題になっている。
lambdaさんとの区別は、帽子以外で判断すべきだと叫ばれている。

○noexceptちゃん
入学試験の選考の最後になって、急に合格した赤ちゃん。
豪華にも、独自の制服を作ってもらった。

○Inheriting Constructorさん
地味にできる娘。何で今までいなかったのか、不思議に思われている。

○__VA_ARGS__さん
クラス分けで、プリプロセッサ組に通うことになった娘。
プリプロセッサ組は、落ちこぼれだとも、最強だともいわれている、変わったクラス。
その外見はあまりにもブサイクだが、密かにファンもいるらしい。

○exportさん
進級できなかった。

○Exception specificationさん
進級できなかったが、彼女の産んだ、まだ一歳にもならない赤ちゃんが、いきなり入校してきた。

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

2010/03/27(土) 11:15:21

C++0F(2015年)までにリリース出来るんでしょうか？

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

2010/03/27(土) 11:15:47

なんか知らんが乙！

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

2010/03/27(土) 12:15:02

>>7
３６(ry

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

2010/03/27(土) 12:51:43

・progress_displayたん

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

2010/03/27(土) 12:57:11

毎度毎度乙wwww

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

2010/03/27(土) 13:22:54

・type_indexさん
type_info君と仲が良いらしい。
噂では、いくとこまでいったとかいってないとか。
ただし、開校前のクラス分けで離ればなれになってしまった。

・System error supportさん
いじめられて転校してきたらしい。
たぶん、どの学校でも相手にされない子。
ほとんどの学校には、学校独自の、もっとマシな子がいるし。

・Tupleさん
博愛平等主義者。ほとんどのクラスメートと仲が良い。

・Binder姉妹(bind1st,bind2nd)
落第。一応、まだ学校にはいる。

・Function template bindさんと、Polymorphic function wrapperさん
二人とも、とても頭が良い。
なんでも、「ぶーすと」という一流の進学校から転校してきたらしい。
あまりに成績が良かったために偏差値を押し上げて、Binder姉妹を落第させる原因をつくった。

・Time utilitieさん
2038年問題も3000年問題も大丈夫と豪語。

・Compile-time rational arithmetic君
Time utilitieさんと仲が良いらしい。

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

2010/03/27(土) 14:25:02

ばびょーん博士

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

2010/03/27(土) 21:17:02

>>6
>lambdaさんとの区別は、帽子以外で判断すべきだと叫ばれている。
まあ、校舎が違うからいいんでないの？

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

2010/03/28(日) 17:28:01

前スレ>>996
あーだこーだ言ってるけど、結局ひよって、あとからコンストラクトする方法を用意してるんじゃん
だったら普通にp->Hoge();を使わせてくれよって思う
placementのわかりにくい仕様よりも、メモリ領域をキャストして普通にコンストラクタ呼ぶほうが直感的で理解しやすいし

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

2010/03/28(日) 17:33:14

C++キャストと同じだよ
意図的に面倒くさくしてんだよ

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

2010/03/28(日) 17:39:16

reference_and_const_cast<HOGE>(hoge)();

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

2010/03/28(日) 21:50:05

先生質問!!!
lamda を返したときの lambda の型はどう書くんですか?
つか, 返る型で dispatch してくれるようになるんだっけ???

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

2010/03/28(日) 21:57:12

std::functionかautoで受ける

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

2010/03/28(日) 21:57:48

高階関数でも他のlambda式と同じ様に型推論してくれるよ。

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

2010/03/28(日) 22:17:09

>>19
その auto が信用できてないんだが
関数の戻り型ってめんどう見てくれるようになたんだっけか?

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

2010/03/28(日) 22:20:17

>>21 信用とかめんどう見るとか、わけのわからん言葉を使わないようにしてもらえませんか？

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

2010/03/28(日) 22:20:27

>>21
信用できないって、コンパイラは右辺値の型を正確に求められるんだからautoがミスることはなくね？

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

2010/03/28(日) 22:22:03

autoとVBのバリアントの区別がついてないんじゃないか

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

2010/03/28(日) 22:23:18

65536くらいネストしたらコンパイラ落ちるかもしれないというのが気に食わないの？

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

2010/03/29(月) 00:56:28

struct や class の {} の後の ; はいつになったら省略可能になりますかね。
文法的に無理ですか、そうですか。でもウザイよね。

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

2010/03/29(月) 00:57:32

>>25
クラス書いてコンパイルすると5割くらいはそのエラーだな。。。

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

2010/03/29(月) 01:20:33

定義に続けてインスタンスを宣言できる以上、無理っぽいよ。

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

2010/03/29(月) 01:41:10

省略しても曖昧さが生じない ; っていうと
配列とか構造体の初期化データの末尾とか?

int a[] = { ... }; ←ｺﾚ

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

2010/03/29(月) 01:55:49

initializer_listが導入されてややこしくなったから曖昧さが生じるケースとかありそう

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

2010/03/30(火) 16:13:43

post-Pittburgh mailing (N3047-N3093)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/#mailing2010-03

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

2010/03/30(火) 20:49:22

exportあぼーんｷﾀ━━━━━━━(ﾟ∀ﾟ)━━━━━━━!!!
例外指定あぼーんｷﾀ━━━━━━━(ﾟ∀ﾟ)━━━━━━━!!!
noexceptｷﾀ━━━━━━━(ﾟ∀ﾟ)━━━━━━━!!!
ﾅﾝﾄｶvalue地獄ｷﾀ━━━━━━━(ﾟ∀ﾟ)━━━━━━━!!!
decltype超強化ｷﾀ━━━━━━━(ﾟ∀ﾟ)━━━━━━━!!!
デフォルトムーブコンストラクタ＆代入演算子ｷﾀ━━━━━━━(ﾟ∀ﾟ)━━━━━━━!!!
Unified function syntaxｺﾈ━━━━━━━('A`)━━━━━━━!!!

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

2010/03/30(火) 21:10:51

何とかFCDっすか。

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

2010/03/30(火) 21:32:48

exportとかthrow()が廃止になったって事？

> ﾅﾝﾄｶvalue地獄
wwwwww

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

2010/03/30(火) 21:33:42

フォルキャン・・・ダッシュ・・・？

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

2010/03/30(火) 21:48:52

N3092がFCDなんだろうけど、以前14.1にあったExported templatesが確かになくなってる。

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

2010/03/30(火) 22:08:01

throw()あぼんってまじ？
exportはともかく無例外指定は使ってるコード多いと思うのだが。

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

2010/03/30(火) 22:31:27

deprecatedだからまだ一応あるよ
これからはnoexceptを使いましょう

でもexportはD行きをすっ飛ばしていきなり抹殺された
Comeau涙目

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

2010/03/30(火) 22:33:54

throw()とnoexceptってどない違うねん

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

2010/03/30(火) 22:36:19

全く一緒

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

2010/03/30(火) 22:37:17

じゃあ最初からnoexceptにしてくれれう゛ぁーーーー

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

2010/03/30(火) 22:40:06

あ、全く一緒ではなかった
throw()は違反するとstd::unexpected()を呼ぶ
noexceptはstd::terminate()を呼ぶ

多分違いはそれだけ

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

2010/03/30(火) 22:43:36

ttp://cpplover.blogspot.com/2010/03/n3055-taxonomy-of-expression-value.html
> xvalue(eXpiring value)
> rvalue referenceに束縛した結果を、xvalueという。これは、eXpiring valueである。rvalue referenceというのは、valueのリソースをmoveするのに使われることから、このように名付けられた。
> lvalue
> 以前と変わらず。
> prvalues(pure rvalues)
> 既存のrvalue、つまり、C++03の意味のrvalueを、prvaluesという。
> rvalues
> xvalueとprvaluesをあわせて、rvaluesという。
> glvalues(generalized lvalue)
> xvalueとlvalueをあわせて、glvaluesと言う。
> lvalue, rvalueを、左辺値、右辺値などというのは間違っているように、これらは、あえて訳さない方が良い。

2周読んでも今ひとつしっくりこねぇwwwwwww

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

2010/03/30(火) 22:45:58

そんな解説よりN3092の3.10の図見るのが一番わかりやすいと思う

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

2010/03/30(火) 22:56:37

> Expressions are categorized according to the taxonomy in Figure 1.
から始まるくだりか。

確かに分かりやすいっちゃ分かりやすい

…ような気がするだけヽ(`Д')ノｳﾜｱｱﾝ

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

2010/03/31(水) 00:29:22

デストラクタで仮想関数を呼びたいんだけど、何かいい方法ない？
class Base{
public:
Base(){}
~Base() { End(); }
private:
virtual void End() = 0;
};
ってことがやりたいんだけど・・・。
End()では、newした領域deleteしたり、なんやかんやと、
派生クラスごとに異なった処理します。

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

2010/03/31(水) 00:32:38

普通はvirtual ~Base(void);を使う

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

2010/03/31(水) 00:46:06

>>46
~Baseが呼ばれるころには派生クラスのデストラクタが呼ばれている。その状態で仮想関数を呼ぶと未定義状態になる。

おとなしく、各派生クラスのデストラクタでdeleteするように設計を見直す。殆どの場合はそれで解決する。

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

2010/03/31(水) 00:49:54

未定義にならないだろ、と書こうと思ったが純粋仮想関数だったか。

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

2010/03/31(水) 01:10:39

>>42
え？コンパイルエラーにならないの？
わざわざキーワード追加してそのザマなの？
っていうか unexpected() が terminate() になったからって誰が喜ぶの？

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

2010/03/31(水) 01:14:13

>>50
知るか
俺だって何かの間違いだと思って何度も読み直して失望したんだ

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

2010/03/31(水) 01:24:50

>>50
コンパイルエラーにならないってマジ？？使えねー　絶望した。

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

2010/03/31(水) 01:38:28

コンパイルエラーにするのは無理じゃね？

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

2010/03/31(水) 01:47:53

void foo() { new char[10000]; } //投げるかもしれない関数
void bar() noexcept(false) { throw 42; } //投げると表明してる関数

void f() noexcept { foo(); } //well-formed(!?)
void g() noexcept { bar(); } //well-formed(!!!???)
void h() noexcept { throw 1; } //well-formed(笑)

なんだこの哀れな機能は……

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

2010/03/31(水) 03:03:57

今までどおり、とくに不自由はないってことだ

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

2010/03/31(水) 06:40:04

自由が素敵なものだとは限らない

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

2010/03/31(水) 11:10:17

>>50
>>52
クソバカ共みっけw

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

2010/03/31(水) 11:14:51

> exportの廃止。deprecateではなく、完全な削除。
> ただし、exportというキーワードは、予約語として残す。

だれか、exportキーワードを便利に活用する案を出そうぜ

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

2010/03/31(水) 11:16:24

他の言語にエクスポートしてくれるとか

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

2010/03/31(水) 11:18:30

http://cpplover.blogspot.com/2010/03/post-pittsburgh-mailing.html

> Raw string literalは、本当に、Rawになる。
> つまり、UCNのエスケープシーケンスや、トライグラフ、プリプロセッサの、行末に\を指定することによる、
> 改行の削除の影響すら、受けなくなる。
> char const * ptr = R"delimiter(\u1234
> \
> )delimiter" ;
> これは、従来の文字列リテラルでは、
> "\\u1234\n\\\n"
> と同じである。つまり、UCNも気にしなくていいし、
> プリプロセッサによる改行の削除の影響も、気にしなくてよくなる。
> ついに、本当の意味でRawになった。

プリプロセッサによる改行の削除の影響を受けないって、すごすぎねぇか？

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

2010/03/31(水) 11:19:56

>>57
賢い人には unexpected() が terminate() になったら何がうれしいのかわかるの？

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

2010/03/31(水) 11:21:49

>>60
行連結は Raw string literal を解釈するフェーズより前のはずなんだが、
どうなってるんだろう？

006357

2010/03/31(水) 11:25:52

お前もか

>>61
>>50と>>52に共通する事項について俺は言及しただけだ

006460

2010/03/31(水) 11:26:41

>>62
きっとPre-Preprocessorが動作してだな

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

2010/03/31(水) 11:28:35

>>63
じゃあ noexcept で何がうれしいのかわかってる人はいないってこと？

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

2010/03/31(水) 11:30:59

コンパイラの最適化が期待できるのは十分うれしい〉noexcept

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

2010/03/31(水) 11:32:45

>>66
え？だって例外発生したら terminate() 呼ばなきゃいけないんでしょ？
今まで unexpected() 呼ばなきゃいけなくて余計なコードが出てたのと同じじゃないの？
この違いに基づいてどういう最適化ができるの？

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

2010/03/31(水) 11:33:45

Raw string literal は "[ ]" から "( )" になったのか。
<: :> を使用する時どうするのかと思ってたが解決したな。

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

2010/03/31(水) 11:37:42

>67
いままで規格上 throw() で最適化することは期待されてなかったんだから
前進したのは事実だろう。terminate() 云々はコストはほぼないって感じらしい。

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

2010/03/31(水) 11:40:58

>>67
少しは足りない脳で考えて見ろよ

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

2010/03/31(水) 11:46:51

>>67
noexceptの原論文を読みなよ。
リアクションが馬鹿っぽいから説明してやる気にはなれない。
>>54
それが意味がある局面だってある。

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

2010/03/31(水) 11:46:55

で、いつごろから
throw[ \t]*([ \t]*)[ \t]*
をgrepしてnoexceptに書き換えていけばいいの？

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

2010/03/31(水) 11:47:44

>>69
今までだって throw() が付いてる関数から呼び出してる関数が全部 throw() なら
unexpected() の呼び出しコードは不要、といった類の最適化はできたでしょ？
不測の例外発生に伴って terminate() を呼ぶコストが unexpected() を呼ぶコストと
違うのは何によるのかもわかってないのに「最適化に役立つ」とか言い切っちゃって良いの？

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

2010/03/31(水) 11:48:02

noexceptって型なの？？
N2855 noexceptについて - xyuyuxの日記
ttp://d.hatena.ne.jp/xyuyux/20090630/1246360766

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

2010/03/31(水) 11:48:46

落ち着いてまとまった解説書を書いてくれないと
俺はたぶん職を失う

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

2010/03/31(水) 12:11:09

>>73
>>71

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

2010/03/31(水) 12:13:05

本の虫: 例外指定について
http://cpplover.blogspot.com/2010/03/blog-post_31.html

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

2010/03/31(水) 12:41:34

>>71
わかったよ。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3050.html#an-optimization-hint

以下の２点が throw() とは違う。
　- noexcept 違反の場合、 terminate() が呼ばれるまでにスタックの巻き戻しが
　　済んでいるかどうかをを実装依存とすること。
　- xxx_nothrow_xxx<> メタ関数によって情報にアクセスできること。
つまり >>42 を素直に信じて考えてしまったのが間違いだったわけだ。ごめんよ。

前者については、ほんとうにこのスタックの巻き戻しが最適化の妨げだったのか
（暗黙のハンドラの存在が問題だったのではないのか？）という点で疑問が残るが、
後者については大幅な状況の改善が期待できる。

任意の式について例外を投げうるかどうか判定する noexcept 演算子なんてあるんだな。
・・・あれ？
これと同じことを関数の中身についてコンパイラが勝手にやってくれればいいだけなのになぁ。
↓こんなのがイディオムになっちゃったりするのかなぁ・・・
#define FUNCTION_BODY_EXPR \
　expr1,\
　expr2,\
　expr3,\
　...
void f() noexcept { FUNCTION_BODY_EXPR; }
static_assert(noexcept(FUNCTION_BODY_EXPR), "noexcept violation");

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

2010/03/31(水) 12:48:36

>>73
unexpected()とterminate()の違いを理解してないね。

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

2010/03/31(水) 12:51:27

小さいhelper関数をnoexcept宣言で書ければ凄く便利だよ。
例えばベクトル演算系のクラスライブラリ書いてる時。

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

2010/03/31(水) 12:54:17

noexcept 演算子を追加しといて関数の静的解析はしないとか、意味わからんな。

008278

2010/03/31(水) 12:59:47

あれ？
xxx_nothrow_xxx<> は noexcept 演算子で定義されてて、 noexcept 演算子は
例外指定については throw() も noexcept(true) も同じになるんで、 >>78 の２点目は
違わないね。

例外仕様としての noexcept よりも演算子としての noexcept のほうが肝心な気が
してきた。

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

2010/03/31(水) 13:25:41

例外は抽象解釈泣かせだからね。
リフトしまくって計算量は増えるわ、情報は劣化するわ。

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

2010/03/31(水) 13:39:44

>>83 いきなり何の話だ？誤爆？

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

2010/03/31(水) 13:45:54

>>83
× 例外は
○ 例外仕様は
かな？

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

2010/03/31(水) 17:57:09

throw()とthrow(...)以外をdeprecatedにするんじゃダメだったのかなぁ
noexcept演算子はthrow?とかじゃダメだったのかなぁ
ラムダ用の予約語はあんなに強硬に反対してたのに、こんな下らない機能に予約語とか意味が分からない

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

2010/03/31(水) 18:01:28

n3050読めば分かるが、
nothrow_move_constructorなどなど、非常に重要な概念。
下らないなんてとんでもない。

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

2010/03/31(水) 18:03:27

下らないは言い過ぎとしても、予約語が必要なほど重要でもないと思う

008987

2010/03/31(水) 18:05:13

予約語については特に異論ない。

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

2010/03/31(水) 18:09:41

時間がないから、構文上のトラブルを避けるためにぶち込んだんだろうな
そんな都合で決めないで欲しいけど

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

2010/03/31(水) 18:12:02

void hoge() throw; //なんか投げる
void hoge() ~throw; //投げないらしい

これでいいじゃん
それか!throwとか

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

2010/03/31(水) 18:22:21

>>91
デストラクタにならって~throwとか？www

>>90
> 時間がないから、構文上のトラブルを避けるためにぶち込んだんだろうな
> そんな都合で決めないで欲しいけど
激しく同感。
いいよ、もう来年まで持ち越してもいいからちゃんとまともにしてくれ！

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

2010/03/31(水) 18:25:03

せめてexceptにしてくれ
noexcept(false)って何だよ二重否定かよ

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

2010/03/31(水) 18:26:31

クラスのメンバ関数にthrow()と書くと、それが例外を投げるように変更しようとした時に制限となってしまう。
あるいは、そのクラスから派生クラスを作ろうとしたときもインターフェイスに強い制限をかけることになる。

とHarb Sutter 氏がおっしゃっていますが、
それはnoexceptでも同じじゃねえか？
何が良いの？？？

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

2010/03/31(水) 18:27:27

>>93
宣言の方でexceptだと困る、
operatorの方も同じ予約語にしたい、
こんな感じでは?

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

2010/03/31(水) 18:32:25

>>94
つ 14.7.2.2

009794

2010/03/31(水) 18:34:10

>>96
規格書14.7.2.2を読むべし、と？
英語読めない俺にはC++を使うのは難しい

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

2010/03/31(水) 18:53:58

まぁ、例外なんか使うなってこった。
メモリ確保などの、失敗がありえない&致命的な処理で失敗したら即ログ吐いてabort。
これでいいでしょ。

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

2010/03/31(水) 19:17:28

>>72
そのうちBOOST_NOEXCEPT( )みたいなマクロが流行るんじゃない？

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

2010/03/31(水) 19:24:56

さっさと変換して、コンパイラが対応するまで#define noexcept throw()しとけばいい

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

2010/03/31(水) 19:45:14

まてnoexcept(false)っていう文法もあるらしい。
そもそもnoexceptを記載する場所と throw()を記載する場所って同じなのか？

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

2010/03/31(水) 20:22:03

いきなり>>3以降の、C++学園の人々に修正が迫られるな。

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

2010/03/31(水) 20:23:57

今回の変更って、もう決定なの！？

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

2010/03/31(水) 20:51:24

1.WD (Working Draft): 作業部会であれやこれやする段階
2.CD (Committee Draft): ISOとしての承認過程スタート
3.CDに対し各国規格団体による投票
4.投票時のコメントを考慮して作業部会で修正
5.FCD (Final CD)
6.FCDに対し各国規格団体による投票
7.投票時のコメントを考慮して作業部会で修正
8.FDIS (Final Draft International Standard)
9.FDISに対し各国規格団体による投票
10.成立

今5から6へ移行中

0105103

2010/03/31(水) 20:56:27

>>104
分かりやすい解説ありがとう。

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

2010/03/31(水) 20:58:02

> いずれにせよ、C++0xの規格は、2011年内に、制定されるだろう。
既に来年かwwww

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

2010/03/31(水) 20:58:31

なんかかっこいいな

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

2010/03/31(水) 20:59:50

どうせnoexceptにNBから総ツッコミ入って遅れるだろ

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

2010/03/31(水) 21:56:28

安心して。2011の11は16進数だから。

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

2010/03/31(水) 22:21:20

>>46
デストラクタをprivateにして、
明示的にEnd()を呼ばせるようにしたら？

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

2010/03/31(水) 22:24:06

>>110
良くある実装だけど何となくウザイ…。

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

2010/03/31(水) 22:26:02

>>110
いちいちEnd呼ぶのまんどくせ。
でもいい案思いつかね。

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

2010/03/31(水) 22:43:57

こんなコードがあった場合。投げた例外はキャッチもできず落っこちる。
例外安全性を宣言したつもりが、キャッチもできずにクラッシュしてしまう。安全にするつもりが超危険。なんて罠？
throw()の関数は例外を投げる可能性があればコンパイルエラーになるほうが便利じゃね？そうであればthrow()はすごく強力だ。VC8は例外仕様を無視するからキャッチするけど、この反規格の判断は正解かもね。
#include <exception>
#include <iostream>

void func1()
{
throw std::exception();
}
void func2()throw()
{
func1(); //ここでコンパイルエラーが出れば丸く収まる。
}

int _tmain(int argc, _TCHAR* argv[])
{
try
{
func2();
}
catch(...)
{
std::cout<<"きゃっち"<<std::endl;
}
return 0;
}

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

2010/03/31(水) 23:00:22

もともと例外仕様はassertと同じく
「俺の書いたコードを信用して！　もし間違ってたら殺していいよ！」
というプログラマの自己責任による表明だから。

コンパイルエラーが出れば便利、てのは同意だけど。

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

2010/03/31(水) 23:02:06

throw()とnoexceptの関係を
assertとstatic_assertみたいにすればよかったんじゃね

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

2010/03/31(水) 23:08:22

お前ら、何か忘れてるんじゃない？
C++には関数ポインタがある。
だから、コンパイル時には実行時にどのコードが走る可能性があるか決定できない。
つーことは、コンパイル時に例外が投げられる可能性があるか無いかは判断できない。

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

2010/03/31(水) 23:10:44

よくよく思い出せ。
適当なポインタを適当な関数型にキャストして適当に()書いたらそこのコードが走るような言語だぞ。
あまり無理を言うな。

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

2010/03/31(水) 23:29:28

>>114
> 「俺の書いたコードを信用して！　もし間違ってたら殺していいよ！」
> というプログラマの自己責任による表明だから。
分かりやすいな、例え。

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

2010/03/31(水) 23:36:56

誰かADLをどうにかしろ！！
俺にも分かるようにしてくれ！

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

2010/03/31(水) 23:37:28

本当にコンパイル時にチェックするなら、
noexceptからはnoexceptしか呼び出せない、とかにする必要があるな。
これはちょうど今のconstと同じ扱いになるな。
てことは、下位互換のためにnoexcept_castが追加されるな。
noexcept関数から、例外を投げないことが分かっているnoexcept指定の無い関数を呼び出す場合は、
noexcept_castをしてください、みたいな。
ウザいな。

012174

2010/03/31(水) 23:40:33

>>120
つまり>>74で言われていたみたいにcv修飾子みたいにするわけですね。

・・・ちょっと待て！
テンプレートの時にどう解決するんだそれは！？
メタプログラミングが「前提」となるなんていやだぞ

C++0xを実装できるコンパイラが少なくなるようでは、
「規格どおりに書いたのに移植性が全然ありません」
とかC++を使う意義が無くなってしまうじゃないか！

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

2010/03/31(水) 23:49:53

>>121
そうなると、テンプレートは、noexceptとそうじゃない奴の二種類ずつメソッドを用意する事になるな。
constとの組み合わせもあるから、沢山定義しないといけないね(笑

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

2010/04/01(木) 01:01:33

こんな感じ？

templete<typename T>
void swap(T& a, T& b) noexcept(has_nothrow_copy_construcor<T>::value && has_nothrow_copy_assign<T>::value)
{ T x(a); a = b; b = x; }

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

2010/04/01(木) 01:06:09

moveも出来るか考慮した方が

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

2010/04/01(木) 04:24:39

http://cpplover.blogspot.com/2010/03/raw-string-literal.html
> 2.2 Phases of translation [lex.phases] p3
> Within the r-char-sequence of a raw string literal, any transformations
> performed in phases 1 and 2 (trigraphs, universal-character-names, and
> line splicing) are reverted.

巻き戻すって、一旦行連結しちゃったらもうどこに改行があったかなんて
わからないんじゃないの？どういう実装を想定してるんだろう？

012660

2010/04/01(木) 07:46:20

>>125
> 巻き戻すって、一旦行連結しちゃったらもうどこに改行があったかなんて
> わからないんじゃないの？どういう実装を想定してるんだろう？
そう、俺もそう思って>>60の発言になった。
びっくりだわー

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

2010/04/01(木) 09:34:17

行連結する前に丸々コピーするだけだろ

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

2010/04/01(木) 11:40:08

え？

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

2010/04/01(木) 19:10:02

const char *s = R"EOS(
#include"foo.h"
)EOS";

phase2が終わった直後にfoo.hを書き換えるとどうなるの？
ねえねえ

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

2010/04/02(金) 09:38:56

Raw String の実装は、とある強力コンパイラメーカーの実装による要望で、
実のところ "Phases of translation" は as is であって、実際のコンパイル動作とは関係ない。
というか馬鹿正直に守っているコンパイラは事実上無い。

>phase2が終わった直後にfoo.hを書き換えるとどうなるの？
言語仕様の外。そういうときの動作は規定していない。
とくにこまらないだろ。

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

2010/04/02(金) 09:58:13

>>130
distcc や ccache などのツールはプリプロセスがコンパイルと分離された
フェーズであることに依存して、一旦プリプロセス結果を生成し、それを
コンパイルは別の独立したプロセスに投げたりする。

プリプロセスまでは gcc などの無償利用できるプリプロセッサを使い、
コード生成は専用のクロスコンパイラを使うようなことも、 Raw String Literal の
仕様さえなければこれまでどおり可能。

やっぱり心配だ。

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

2010/04/02(金) 10:12:19

>>129
それ include されるの? 単に「#include"foo.h"\n」って文字列に解釈されるんじゃないの?

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

2010/04/02(金) 13:25:02

誰かたすけて～。
doubleで10のN乗をmath.hのPowで実装したんだが、N=100位で何でか細かい誤差が出る。
doubleから、指数部を切った値（=残った仮数部）をとる方法無いだろうか。なるべく誤差の出ない方法で・・・。

    Decimal& operator =(double Val){
        Sign_ = (Val<0)? false:true;
        if(Sign_ == false) Val*=-1;
        Digit_=static_cast<long long int>(log(Val)/log(10.0));//これで、Log10(Val)になるらしい。
        int VD= static_cast<int>((log(static_cast<long double>(Val))/log(10.0)));
        int ID= static_cast<int>((log(static_cast<double>(static_cast<unsigned int>(-1)))/log(10.0)));
        double Pow = (VD>=ID) ? pow(10.0,(VD-ID)):1;
        Value_ = Val / Pow;
        return (*this);
    }

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

2010/04/02(金) 16:20:07

>>133です。反応無いので取り下げます～。
お邪魔しました～。

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

2010/04/02(金) 16:53:06

スレタイから C++ とったほうがいいかもね。
0x だけで探せるでしょ。

>>133
定義域を明確にして↓のスレに行ったほうがいい。
【FPU】　浮動小数点　【SSE】
http://pc12.2ch.net/test/read.cgi/tech/1199424344/l50
ム板ではどのスレでも三時間で答えが来る確率は低いが。

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

2010/04/02(金) 18:15:26

>>132
一旦includeしてから"revert"するんでしょ
125によると

0137133

2010/04/02(金) 20:13:26

>>135
ぁぃゃ～。しまったです。
普通の質問スレと勘違いしてしまいしましたです。
ホントに申し訳ない。Orz

それと、誘導ありがとうです。

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

2010/04/02(金) 21:48:36

右辺値参照を用いて（a+b)*(c+d)*e のような行列の積を正しく計算
できますか？

a *= bの行列演算では、裏側で一時オブジェクトを導入しない限り
正しい計算結果は得られないはずですが( a += bとはわけが違う )、
右辺値参照でもこれと同じような事は起きませんか？

｢いや、C=prod(A,B)のような使い方しか想定してない。｣と言うのなら
仕方ないですが。

※｢右辺値参照｣の右辺値という言葉はかえってわかりにくいと思うの
ですが、皆さんはどうですか？

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

2010/04/02(金) 22:55:15

誰もがそう思ってるけど、50年来の悪しき伝統なので変えられない

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

2010/04/02(金) 23:49:29

>>138 何言ってるのかわからん。 >139 はエスパーか？

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

2010/04/02(金) 23:51:29

コンパイラ黎明期から右辺値という名称

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

2010/04/03(土) 00:52:24

>>135
> スレタイから C++ とったほうがいいかもね。
> 0x だけで探せるでしょ。
しかし
C++0xからC++をとって、その上2009年中に終わらなかったのだから0xを取ると
何もなくなってしまうじゃないかw

0143126

2010/04/03(土) 00:54:03

>>127
どういう意味？

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

2010/04/05(月) 01:18:54

unique_ptrってコンテナに使っても大丈夫だったのか

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

2010/04/05(月) 07:40:06

>>144
> unique_ptrってコンテナに使っても大丈夫だったのか
C++0x - Wikipedia, the free encyclopedia
ttp://en.wikipedia.org/wiki/C%2B%2B0x
unique_ptr will be provided as a replacement for auto_ptr which will be deprecated.
It provides all the features of auto_ptr with the exception of unsafe implicit moving from lvalues.
Unlike auto_ptr, unique_ptr can be used with the C++0x move-aware containers.

だとさ。

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

2010/04/05(月) 10:27:19

unique_ptrとshared_ptrの違いは何よ？

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

2010/04/05(月) 10:51:45

unique か shard か。

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

2010/04/05(月) 11:24:12

意味わかんね

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

2010/04/05(月) 11:27:17

所有権の話。

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

2010/04/05(月) 11:39:36

Pimplとか考えると、一番使用頻度高いのってやっぱ shared_ptr だよな？

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

2010/04/05(月) 20:22:09

>>150
stdに入っているauto_ptrと、boostに入っているshared_ptrとで
どっこいどっこいぐらいかな。

stdにshared_ptrが入れば無敵。

ところで何でscoped_ptrがstdに入らなかったの？
最も軽いスマポだったりしない？

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

2010/04/05(月) 20:45:59

unique_ptr がそれじゃないかな

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

2010/04/06(火) 02:16:36

C++0x前提だとuniqueと比べてscopedのメリットって何も無いよな

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

2010/04/06(火) 21:36:55

スマートポインタって生ポインタより遅くなるの？

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

2010/04/06(火) 21:40:06

メモリの確保やコピーの際にコストがかかることもあるが
ポインタを使う分にはinline化が効くから生のポインタと同じ

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

2010/04/06(火) 21:43:22

必要な機能に必要十分なものを使えば、
オーバーヘッドはない。そう実装されている。

0157154

2010/04/06(火) 21:46:07

>>155-156
ありがとう。
なんか変なメンバを持ってたりすると無駄に重くなるかな、と心配だった。
(もちろんboostやstdの有名スマポの話です。)

> 必要な機能に必要十分なものを使えば、オーバーヘッドはない。
なるほど。つまり単にstd::auto_ptrで済む所にstd::tr1::shared_ptrを使用すると
無駄な参照カウント分が無駄なオーバーヘッドとなるが、
それは必要十分じゃないから、ってことね。

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

2010/04/07(水) 00:19:47

何億回もループ回すとかミリ秒単位のリアルタイム処理するとか
そんなんでなけりゃスマポのオーバーヘッドなんて何でもないよ

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

2010/04/07(水) 01:10:46

auto_ptrの代わりにshared_ptrを使う場合に、auto_ptrは複製が無いので参照カウンタのオーバーヘッドが起きない。
auto_ptrのムーブ（=演算子）はshared_ptrではswapを使うのでやはり参照カウンタのオーバーヘッドが無い。

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

2010/04/07(水) 01:12:12

日本語でおｋ

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

2010/04/07(水) 01:13:09

>>159 なにいってんのかわかんねぇ。

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

2010/04/07(水) 01:18:00

auto_ptrの代わりにshared_ptrを使う場合に（と断っておきながら）、auto_ptrは…（shared_ptrを使う場合じゃなかったのかよｗｗ）
auto_ptrのムーブ（=演算子）は（何、auto_ptrのムーブの話？）shared_ptrでは…（おいおい、auto_prtのムーブってshared_ptrでも使われるのか？ｗ）

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

2010/04/07(水) 07:26:02

>>159
日本語読解上級者コース

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

2010/04/07(水) 08:31:58

shared_ptr はどちらかと言うと，実行時オーバーヘッドを許してでも
(使わないかも知れない) 多くの機能をデフォルトで提供する，という設計思想ではないですかね？
具体的には， deleter の動的指定， thread-safe as an int のための排他処理， weak_ptr への対応とか．
もちろんこれらのオーバーヘッドが必要になる文脈は限定的ですけれど．

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

2010/04/07(水) 08:51:09

ソースみりゃ分かるが shared_ptr はけっこういろいろやってんぞ
カウンタも shared 分と weak 分と 2 つあるし
ふつーに実行時オーバーヘッドあるだろ

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

2010/04/07(水) 09:47:46

>>164
> deleter の動的指定， thread-safe as an int のための排他処理

使わない時もオーバーヘッドになる?

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

2010/04/07(水) 11:18:37

排他処理と生成破棄以外のコストは気にしなくていいと思う

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

2010/04/07(水) 13:42:51

>166
deleter の動的指定にかかるコストは shared_ptr オブジェクトの生成と破棄の際に，
排他処理は shared_ptr オブジェクトのコピーの際に，それぞれ常に付きまとうと思います．
もちろん，これらのオーバーヘッドが shared_ptr を利用する際の全体的なコストから見て
どの程度有意かはまた別の問題だと思いますけれど．

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

2010/04/07(水) 18:46:51

まずもって心配いらん
安心して使いたまへ

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

2010/04/07(水) 19:34:53

>>157
unique_ptrはすごいぞ
最適化かけたらアセンブリ出力にunique_ptrが居ねえ

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

2010/04/07(水) 19:36:01

それは auto_ptr でも scoped_ptr でもいっしょだろ。

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

2010/04/07(水) 21:56:44

>>168
そういうのオーバーヘッドって言わないでしょ。

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

2010/04/07(水) 22:00:35

オーバヘッ！
オーバヘッ！

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

2010/04/07(水) 23:01:02

http://dictionary.goo.ne.jp/leaf/jn/23536/m0u/%E3%82%AA%E3%83%BC%E3%83%90%E3%83%BC%E3%83%98%E3%83%83%E3%83%89/

全然関係ないけど油をそそいでみる

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

2010/04/08(木) 08:02:40

冒頭のテンプレ読んだんだけど、今のC++ってこんなことになってるんだな。
カオスすぐる。

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

2010/04/08(木) 08:16:47

adhocやるんだって
ttp://homepage1.nifty.com/herumi/prog/cppwg.html

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

2010/04/08(木) 11:09:07

hoge[1, 2, 3] = h; ←これ配列でも使えるように、オーバーロードもできるように仕様に入れるべき
hoge[1][2][3] = h;みたいなのをエミュレートするのに余計なオーバーヘッドのコストを支払うのは嫌だ

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

2010/04/08(木) 11:19:15

>>177
operator()のオーバーロードでいいじゃん。
オーバーロード以前にhoge[1, 2, 3]っていう文法ないんだし。

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

2010/04/08(木) 11:22:25

>>177
オーバーヘッドは防げないか？コーディングが面倒なだけで。
たとえばどんな hoge[1][2][3] の実装を想定してるの？

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

2010/04/08(木) 11:26:21

>>178
hoge(1, 2, 3) = h;
でもこれって見ため最高に気持ち悪くないか？
fortranとかで慣れてる人はいいのかもしれないけど
メンバへの参照アクセスは[]で縛りたいって思うわけよ

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

2010/04/08(木) 11:40:59

[1, 2, 3] ってカンマ演算子で最終的に3が返るからどちらにしろだめだろ
(1, 2, 3)も同じ理由からあまり推奨できない

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

2010/04/08(木) 11:48:31

>>179
次元Nを引数にしたテンプレートのプロクシクラスで、operator[]で再帰的にうんぬんする感じ
整数の代入*次元数+
整数を引数にプロクシの参照を返すoperator[]呼び出し*(次元数-1)+
整数のポインタを引数にメンバへの参照を返す生のアクセサ（atメンバ）呼び出し*1
頑張ったけどこれだけ実行時コストがかかってしまう

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

2010/04/08(木) 11:59:28

>>182
プロクシの参照がコンパイル時に全部解決されれば、実行時のコストは無いよね？

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

2010/04/08(木) 12:36:07

hoge[{1,2,3}] で。

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

2010/04/08(木) 14:42:16

プロクシクラスを持つのにvoltile修飾してなければ問題ない。
あんまりピリピリするな。

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

2010/04/08(木) 19:23:14

0xのメルセンヌ・ツイスタって使ったらいちいち著作権表示しないといかんの？

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

2010/04/08(木) 21:05:17

コンパイラのライセンス次第だろ

GCCは非対応にするのかな
GPLにはできんよなぁ

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

2010/04/08(木) 21:55:43

わざわざできるようにしたんだから 0x 的には >>184 だろう。

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

2010/04/08(木) 21:58:24

x[{1,2,3}];ってやると配列が渡されるの？

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

2010/04/08(木) 22:14:33

initializer_list が渡されるんだろう。

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

2010/04/09(金) 02:01:50

http://www.artima.com/shop/overview_of_the_new_cpp

Presentation Materials: Overview of the New C++ (C++0x)
by Scott Meyers
Single-user license (personal use only)
$29.96

これはなんだー

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

2010/04/09(金) 02:08:22

さすがメイヤーズ先生や
日本語解説書なんか最初からいらんかったんや

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

2010/04/09(金) 02:42:38

メイヤーズ先生ってもっとおじいちゃんだと思ってたわ

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

2010/04/09(金) 07:13:03

Scott Meyers先生すげぇ

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

2010/04/09(金) 11:31:00

髪の毛こんなにあるとは思わなかったな

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

2010/04/09(金) 11:38:58

すぽすぽ先生がいかにもな風貌すぎるんだよ

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

2010/04/09(金) 12:43:24

すっぽすっぽ
ふっさふっさ

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

2010/04/09(金) 13:13:14

まじか…このTarget publication date
ttp://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50372

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

2010/04/09(金) 14:06:30

1012年／（＾o＾）＼

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

2010/04/09(金) 21:12:31

Target publication date: 2012-02-28

>>199
Ed. 紫式部かよ。

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

2010/04/09(金) 21:32:53

そのころにはVC11とGCC4.7がそれなりの実装してくれてるといいな

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

2010/04/09(金) 21:34:11

文書のタイトルが「Microsoft PowerPoint - C++0x.ppt」になっとる
336ページのパワーポイントw

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

2010/04/09(金) 23:53:07

class ClassX{
public :
ClassX(std::initializer_list<int>); // Xのstd::initializer_list版コンストラクタ
ClassX(); // Xのデフォルトコンストラクタ
};

class ClassY{
public :
ClassY(std::initializer_list<int>); // Yのstd::initializer_list版コンストラクタ
};

class ClassZ{
public :
ClassZ(); // Zのデフォルトコンストラクタ
};

このような3つのクラスがあるとき、
X x = {};
Y y = {};
Z z = {};
で呼ばれるのはそれぞれどのコンストラクタでしょうか。
あるいはコンパイルエラーになるのでしょうか。
よろしくお願いします。

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

2010/04/09(金) 23:59:34

>>201
> そのころにはVC11とGCC4.7がそれなりの実装してくれてるといいな
VCはともかくg++は5.x系になっても良いくらいの大変革だろ。
むしろg++0xとか名前が変わるくらいの出来事。

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

2010/04/10(土) 00:00:56

ttp://d.hatena.ne.jp/faith_and_brave/20100406/1270537463

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

2010/04/10(土) 00:23:29

一つの言語の都合だけではGCCのメジャーバージョンは上がらんよ

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

2010/04/10(土) 00:31:51

>>206
そーいや複数の言語を扱う代物だったな。

0208203

2010/04/10(土) 00:32:51

>>205
私も自分でググった時にそのページは見つけたのですが、
それだけではClassXしか分かりませんでした。

ClassY, ClassZについて正確な動作をご存じの方がいらっしゃったら
どうかよろしくお願いします。

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

2010/04/10(土) 00:34:56

デフォコン優先で無理ならリストだろ

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

2010/04/10(土) 00:44:19

>>209
まてそのソースは？
例のブログの人の降臨を待つべきだ。

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

2010/04/10(土) 00:57:33

召還しないで205のコメント欄で聞きゃいいよ
そこの人も日本NBのメンバのはずだから

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

2010/04/10(土) 00:58:23

自分でドラフトを読むという選択肢は無いのかね？

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

2010/04/10(土) 01:00:37

あるよ。

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

2010/04/10(土) 01:24:19

8.5.4の3に書いてあるんだから読もうぜ

(1) If the initializer list has no elements and T is a class type with a default constructor, the object is
value-initialized.
(2) Otherwise, if the initializer list has no elements and T is an aggregate, each of the members of T is
initialized from an empty initializer list.
(3) Otherwise, if T is an aggregate, aggregate initialization is performed (8.5.1).
(4) Otherwise, if T is a specialization of std::initializer_list<E>, an initializer_list object is
constructed as described below and used to initialize the object according to the rules for initialization
of an object from a class of the same type (8.5).
(5)Otherwise, if T is a class type, constructors are considered. If T has an initializer-list constructor, the
argument list consists of the initializer list as a single argument; otherwise, （後略）
（番号は便宜上振った、Exampleは省略）

ClassXはデフォコン持ってるから(1)でvalue-initialized＝クラスの場合はデフォコン呼ぶ
ClassZもデフォコンがあるから(1)で同じ
ClassYはユーザー定義コンストラクタがあるからデフォコンがないし集成体でもないし
当然std::initializer_listでもないから(5)に当てはまり、かつinitializer-list constructorがあるので
ClassY({})が呼ばれる

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

2010/04/10(土) 14:31:28

Otherwise多すぎwwww
汚ねぇ仕様書だ・・・。

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

2010/04/10(土) 14:51:29

まだこの後に4項目続くんだぜｗ

0217203

2010/04/10(土) 15:25:27

皆さんありがとうございます。

特に>>214さんには決定打をいただきまして
ありがとうございます。

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

2010/04/10(土) 17:39:14

誰か猫でもわかるオーバーロード入門を書いてください

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

2010/04/10(土) 17:47:55

>>218
オーバーロードのどこが難しいの？

猫でも分かるADL入門
猫でも分かるTMP入門

のがやばいだろ。

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

2010/04/10(土) 18:41:38

日本の猫はいったいどこまで賢くなろうとしているのか

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

2010/04/10(土) 19:16:55

猫は害獣

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

2010/04/10(土) 19:34:47

我が輩は猫である
名前は間田内

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

2010/04/10(土) 20:52:31

我輩は猫である
I am a cat.

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

2010/04/10(土) 21:28:43

仕事はもう無い

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

2010/04/10(土) 21:37:30

どこでミスしたかとんと見当がつかぬ。

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

2010/04/10(土) 21:42:07

何でも薄暗いじめじめした所で壁に向かって仕事していた事だけは記憶している。

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

2010/04/10(土) 21:46:09

吾輩はここで始めてプログラマというものを見た。

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

2010/04/10(土) 22:47:54

>>227
吾輩はここで始めて上司というものを見た。

じゃないかな・

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

2010/04/10(土) 23:10:01

Boost.BigInt
はLGPL汚染されるってことで
ttp://pc12.2ch.net/test/read.cgi/tech/1251446016/
で話題になってるよ。

もし興味ある方はぜひ。

ttp://pc12.2ch.net/test/read.cgi/tech/1251446016/741-743
が発端。

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

2010/04/10(土) 23:27:53

TR2でbigint入れて欲しいとかそういうネタ振りですか

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

2010/04/10(土) 23:45:18

Cat, I'm kitty cat.

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

2010/04/10(土) 23:47:04

>>230
そんなん期待できねぇよ。
できたら願ったり叶ったりだがな。

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

2010/04/11(日) 06:26:55

>219
どうやって candidate functions が決まるのかを入れるなら name lookup の話を含むだろうし、
best viable function を定めるルールだけでもきっちり分かりやすく説明できるというのなら
今すぐ執筆してくれ。

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

2010/04/11(日) 13:46:55

>>229
結局LGPL汚染は普通に使っていれば関係ないって事になってるよ

754 名前：741[] 投稿日：2010/04/11(日) 00:24:24
Boost.BigInt のソースコードを読んできました。

・・・デフォルトでGMP非依存になってますね。

#define BOOST_BIGINT_HAS_GMP_SUPPORT
を定義した上で
#include <boost/bigint/bigint.hpp>
とした場合に限り、GMPが使われるようです。

ということで、特に
Boost.BigInt を Boost Software License でリリースする事には
問題は無いようです。

755 名前：741[] 投稿日：2010/04/11(日) 00:26:31
私は念のために
大文字小文字を区別せずgmpの文字を含む部分を全て削除した
bigintを使って見ましたが正常にどうさするようです。

・・・だと思うのですが、
私以上にBoostのソースコードを読む事に長けている方は
必ずやいらっしゃると思うので、
有識者の方、ご確認いただけますでしょうか。

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

2010/04/11(日) 14:19:37

油断ならねえなぁ
もしshared_ptrとかが汚染されたら大変なことになるよな
怖すぎる

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

2010/04/11(日) 15:31:43

bigint なんてそんな至る所で使われてんのか？
そういう類いのクラスには思えないのだが

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

2010/04/11(日) 18:14:59

>>236
いやたぶん使われていない。
だから標準Boost(って変な表現だが)に推されないんじゃね。

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

2010/04/13(火) 21:12:34

Visual Studio 2010 is now available!
http://blogs.msdn.com/visualstudio/archive/2010/04/12/visual-studio-2010-is-now-available.aspx

C++0x Core Language Features In VC10: The Table
http://blogs.msdn.com/vcblog/archive/2010/04/06/c-0x-core-language-features-in-vc10-the-table.aspx

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

2010/04/13(火) 22:28:56

Japanese版早く出せ

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

2010/04/14(水) 23:34:16

>>239
1週間ぐらい待てないのか？

俺は待てない

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

2010/04/15(木) 05:06:09

あんまりソワソワしないで

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

2010/04/15(木) 18:46:38

あなたはいつでもキョロキョロ

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

2010/04/15(木) 20:40:40

よそ見をするのはやめてよ

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

2010/04/15(木) 20:44:14

おまえら何歳なんだよ

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

2010/04/15(木) 20:50:16

ょぅι゛ょです

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

2010/04/16(金) 01:45:57

いくつも愛を持ってる男の人って…

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

2010/04/16(金) 04:45:41

生物の目標が繁栄することだとすると
種をばらまく側としては、あちこちにターゲットを移してしまうのは
それはそれで正しいんだよな

↓では引き続きラムちゃんタイムをお楽しみください

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

2010/04/16(金) 13:11:56

lambdaっちゃ

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

2010/04/16(金) 14:47:45

誰がうｍ

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

2010/04/16(金) 14:59:59

>>238-249
流れでコーヒーﾌｲﾀｗｗ

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

2010/04/16(金) 19:49:42

template <typename T> class X;
というのがあって、
いま T と X<T>, X<T> と X<T> の (非可換な) 積が定義できるときに
最適化を考えたら、

X<T> operator*(T const &, X<T> const &);
X<T> operator*(T &&, X<T> const &);
X<T> operator*(T const &, X<T> &&);
X<T> operator*(T &&, X<T> &&);
X<T> operator*(X<T> const &, T const &);
X<T> operator*(X<T> const &, T &&);
X<T> operator*(X<T> &&, T const &);
X<T> operator*(X<T> const &, X<T> const &);
X<T> operator*(X<T> &&, X<T> const &);
X<T> operator*(X<T> const &, X<T> &&);
X<T> operator*(X<T> &&, X<T> &&);

と11種類も書かないといけないのだろうか? それとも何か勘違いしてる?

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

2010/04/16(金) 20:12:17

X<T> operator*(X<T> &&, T &&);

これはいらないの？

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

2010/04/16(金) 20:20:59

>>252
書き漏らしてたよ。ありがと。

とにかく、こんなにたくさん必要だとすると
なにか省力化できる仕組みでもあればいいのだが…

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

2010/04/16(金) 20:32:59

右辺値参照なんて要らないよ
そんなに破壊可能なテンポラリが欲しければ
自分で一時変数作れ

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

2010/04/16(金) 20:42:29

>>254
演算子関係だと、結構効いてくるよ?
　X = A + B + C + d*D + E;
とか
　Y = A + (B - c*C)*(D + e*E + F)*(G + h*H);
とかね。

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

2010/04/16(金) 21:11:50

>>254
> そんなに破壊可能なテンポラリが欲しければ
右辺値参照をなーんにも理解していないんだな。
少しは勉強しろ。ggr

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

2010/04/16(金) 21:25:34

右辺値参照が必要な場面では内部処理も変わるだろうから
省力化は難しいんじゃないか

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

2010/04/16(金) 21:30:43

>>257
やっぱりそうか…。

でも >>251 のように列挙的に宣言したとき、>>252 のような warning が欲しい :-p

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

2010/04/16(金) 21:45:38

>>255
速度欲しけりゃそんな風に書くなと

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

2010/04/16(金) 21:58:51

でもまあ、そこそこの速度で実行可能なら
ライブラリーではETやrvalue referenceを使ってがんばる意味はあると思うが
その結果、可読性が高くできるし

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

2010/04/17(土) 07:49:52

>>260
>>255みたいな書き方だと、そこそこレベルじゃねーだろ。

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

2010/04/17(土) 07:51:06

>>258
GIMPLE使えば独自warningも追加できるぞ。

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

2010/04/17(土) 12:56:43

Expression Template技法は俺には扱えない。
頭がおかしくなりそう。

Rvalue referenceなら気合いで何とかなりそうに
思える俺が居る。

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

2010/04/17(土) 13:00:31

>>261
その代償が >>251 だと思うと・・・

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

2010/04/17(土) 13:27:48

>>261
ベクトルなら加減・スカラー倍で計16個、
多元環なら加減乗算で計20個、
さらに除算ができる場合は計32個の定義が必要！！

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

2010/04/17(土) 13:29:58

>>265
あっスカラー倍の割り算を計算に入れてなかったので、さらに若干増えるぞ！

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

2010/04/17(土) 13:53:33

X = A;
X.AddAssign(B).AddAssign(C).AddAssign(d*D).AddAssign(E);

でいいだろ

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

2010/04/17(土) 14:18:35

やだよそんなJavaっぽい書き方

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

2010/04/17(土) 14:19:33

>>265
どうせお前はまともなクラスライブラリ書かないから心配することないよ。

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

2010/04/17(土) 14:28:09

演算子のオーバーロードとか
あくまで補助的なもんだと言うのに
速度も一緒に得ようとか烏滸がましいとは思わないか？

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

2010/04/17(土) 15:03:21

現実にいいライブラリ蓄積してきているからなあ。

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

2010/04/17(土) 15:11:42

ET用にはBoost.Protoなんてのもあるから、
Rvalue-ref. にもBoostがなんか作るんじゃね？

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

2010/04/17(土) 16:45:31

いい具合の代数幾何ライブラリを書きたくなって仕方ないのは、
多分 Cg/HLSL とか AltiVec 拡張とか触ってしまったからだろう。
それらをライブラリとして実装するのは無理があるというが俺の結論。

どうせ、ループ中で特定の行列をレジスタに乗ったままにしたいとか
思い始めたらインラインアセンブラとか使うハメになるのだから、
速度よりも使い勝手や安定性や保守性を重視した方が良いと思う。

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

2010/04/17(土) 21:34:55

凡人の結論を軽々突破するのがC++ templateだしな。

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

2010/04/17(土) 22:26:33

>>274
しかし凡人にはC++ Template metaprogrammingが使いこなせないから
やっぱり無理なんだろうw

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

2010/04/21(水) 23:21:47

>>234
上の方でBoost.Bigintがどうのこうのと言っていたが、
ttp://ja.wikipedia.org/wiki/%E4%BB%BB%E6%84%8F%E7%B2%BE%E5%BA%A6%E6%BC%94%E7%AE%97
ここに
> ライブラリ
> 任意精度演算は多くの場合、専用ライブラリを呼び出すことで実装されている。
> そのライブラリがデータ型を定義し、数値を指定した精度で格納したり、
> 計算を実行するサブルーチン群を提供している。
> ライブラリによって数値の内部表現は異なる。整数のみを扱うライブラリもあるし、
> 各種基数（十進、二進など）で浮動小数点数を格納するもある。
> 分数（有理数）形式で数を格納するものもあれば、実数を全て表現できるとするものもある。
ってあるとおり、改訂BSDライセンスとかでリリースされたライブラリもいっぱいあるから
別にBoost.Bigintにこだわる必要はなさそうだよ。

だってさ。

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

2010/04/22(木) 18:54:53

絶対に完成しないだろ0x

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

2010/04/22(木) 19:40:49

完成しなくてもコンパイラが対応しつつあるから
コンパイラ間で齟齬さえなければどうでもいいよ

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

2010/04/22(木) 19:43:07

もうコンパイラベンダ間で勝手に仕様作っちゃおうぜ
C++標準化委員会とか正直どうだっていい集団じゃねぇか。

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

2010/04/22(木) 19:45:11

あうとー。

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

2010/04/22(木) 19:52:03

C++1X/CLI で。

0282279

2010/04/22(木) 21:23:26

>>281
ああ、なるほど、そうすると
C++/CLIのごとくになっちゃうのか。

それはいやだな。

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

2010/04/23(金) 00:22:44

W3C←→WHATNGみたいな事態には陥ってないかと。
Committeeはいい仕事しているので。
遅いという気持ちは分かるけど。

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

2010/04/24(土) 09:56:06

テンプレ見てたらこんなの出来たとしても使えるようにならんだろ
effective C++を何倍の厚さにすればいいんや

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

2010/04/24(土) 11:46:12

>>283
> Committeeはいい仕事しているので。
遅いんじゃなくて、確実にクソ仕様への道を歩んでいる気がする。
多少後方互換性を壊す勇気を持ってほしかった。

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

2010/04/24(土) 12:32:11

互換性が無くなったら意味が無いというかC++じゃなくなるというか
ベンダにとって不利益になるのは確実

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

2010/04/24(土) 12:55:31

>>286
> ベンダにとって不利益になるのは確実
どうしてそう言い切れるのさ？
ベンダだってわざと互換性が無いようにすることだってあるだろうよ。
とはいえ
> 互換性が無くなったら意味が無いというかC++じゃなくなるというか
まあそれは分かる。
C/C++との極めて高い互換性を持っていなけC++0xなんて
存在意義が無いとは思う。

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

2010/04/24(土) 12:58:48

もう新しい言語にした方が良い気がするねえ
Cへのトランスレータにすれば互換性も確保出来るじゃん

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

2010/04/24(土) 13:07:53

互換性が無くなるとコンパイルが通らなくなる
コンパイルが通らない新しいコンパイラなんていらない
＝不利益になる

物を作るソフトとかは後方互換性がないと困るよ

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

2010/04/24(土) 13:15:44

互換性捨てた新しいのならJavaとかC#とかDとかいっぱいあるじゃないか。

0291287

2010/04/24(土) 13:27:51

>>289
なるほどねぇ。そーゆー考えもあるね。

でもわざと他社製品との互換性を無くして自社製品で囲い込むって
ことはやるんでね？
IEとか。

0292291

2010/04/24(土) 13:29:18

× IEとか。
○ IEとかMS Officeでもそんな感じじゃん。

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

2010/04/24(土) 13:53:59

例外やTMPをCへのトランスレータとして解決できる実装があれば見てみたい。

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

2010/04/24(土) 14:00:05

>>293
> 例外やTMPをCへのトランスレータとして解決できる実装があれば見てみたい。
むしろTMPは割と可能じゃないの？
コンパイル時に定まるんだから。

例外は相当厳しそうに思えるが。

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

2010/04/24(土) 14:01:39

つsetjmp.h

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

2010/04/24(土) 14:02:22

Comeau C++ って
C++ -> C言語
の変換器じゃなかったっけ？？

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

2010/04/24(土) 14:27:48

setjmp使ってCで例外を自作してるのなら見たことあるぞ

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

2010/04/24(土) 14:33:40

コードをいくらでもグロくしていいなら例外も普通にifとreturnで書けるだろ

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

2010/04/24(土) 15:03:54

それかなりオーバーヘッドかからないか？

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

2010/04/24(土) 15:52:02

だってそもそも例外だし。

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

2010/04/24(土) 23:49:04

チューリング完全な言語同士では計算可能性は同じだから
可能かどうかで論じると意味をなさない
どのように実現出来るか、という視点で論じるべき

longjmpでは途中でローカル変数のデストラクタが呼ばれない
Cレベルで実装するなら関数に間接層を設けてif、return、gotoで実装するのが妥当？

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

2010/04/25(日) 07:55:52

そもそもCにデストラクタはないから問題ないんでね。

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

2010/04/25(日) 12:55:12

関数呼び出すたびif例外ならgotoとかするわけ

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

2010/04/25(日) 14:17:22

>>302
いまの話題がC++からCへのトランスレータであるという俺の認識が間違ってないなら、
C++のデストラクタ相当の機能をCでどうやって書き下すかということを言ってるんだと思った

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

2010/04/25(日) 14:29:22

例外が起きた時の処理を関数の中に書いておいて
setjmpでそこに飛ぶ関数を作って
その関数ポインタをグローバルなスタックに関数に入るたび積んで行って
例外が起きたら実行してやればいいんじゃないの

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

2010/04/25(日) 14:32:12

gccは例外サポートがCPUにない場合にそんな感じの実装になってるね。

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

2010/04/25(日) 14:35:07

Cへのトランスレータ作成が例外で頓挫したって話は
ありゃデマだったのか？

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

2010/04/25(日) 14:38:19

おまいら、C++の設計と進化ぐらい読んでないのかよ

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

2010/04/25(日) 14:41:16

私女だけど読んでなかった

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

2010/04/25(日) 14:49:26

CPUによる例外サポートって何？
x86ならINT命令？

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

2010/04/25(日) 14:54:07

C++例外の実装にCPUの機能（CPU例外機能）なんか使わなくていいんだよ。

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

2010/04/25(日) 15:07:44

CPUの例外とC++の例外はそもそも意味が違うだろ

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

2010/04/25(日) 15:11:14

>>308
それ読む価値あった？
俺は別に歴史にはそんな興味ないし。

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

2010/04/25(日) 15:12:50

例外を禁止し、exit()で置き換えれば吉。

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

2010/04/25(日) 15:18:28

>>313
> それ読む価値あった？
物事の欠点を見つけた時に、
「こういう欠点があると自分にわかるのは、自分が利口であり、この物事に関わった奴らが馬鹿だからだ」
と考えて満たされちゃう浅はかな生き方してる人に読ませると、多少はそれを矯正できるかも。

0316313

2010/04/25(日) 15:29:02

>>315
なんだか深い事いってるのう

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

2010/04/25(日) 15:33:07

C++がこんなになっちゃったことへの禿の言い訳が延々書いてあるのかな

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

2010/04/25(日) 15:36:27

というような人に読ませるのも吉。
読んだら最後、それでも揶揄したかったら具体的な話をしなきゃ通らなくなるし、
そういう人は大抵そういう具体的なやり取りできないので、馬鹿を黙らせるのに使える。

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

2010/04/25(日) 16:37:06

難度の高い言語だから「こんなことになっちゃった」とか言っちゃうような子は
そう思っておけばいいんじゃないの
まあC++にも色々「どうしてこうなった」的な部分はあるんだけど
多分俺らがどうしてこうなったと思ってる部分とこの子らが言ってる部分は違うよな

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

2010/04/25(日) 17:13:03

D&Eを読むと、大抵の仕様はよく検討したらしいことが伺える
個人的には納得できる議論もあったし、
納得できない記述もあった

まあ少なくとも、単なる思いつきで仕様をいじることはないらしい
もうちょっと深慮がある

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

2010/04/25(日) 17:26:32

C++使ってて「なんでだお！？」って思う部分があるならD&Eは読む価値がある。
C++0xに関してはD&Eの記述からすると結構「？」な部分も多いけど。

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

2010/04/25(日) 18:57:22

typesafe enum が欲しい

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

2010/04/25(日) 19:16:14

0xの Strongly Typed Enums のことか？

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

2010/04/25(日) 20:23:12

>>321
禿自身がD&Eに相当するような論文を書いてるよね。C++0xについては。
規格が決まる前に書いているのが違う点だけど。

Concept checking - A mor complement to type checking
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1510.pdf
Simplifying the use of concepts
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2906.pdf

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

2010/04/25(日) 20:24:36

conceptは犠牲となったのだ・・・

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

2010/04/25(日) 21:00:40

>>324
＞A mor complement

愛の補数とはまた粋な

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

2010/04/25(日) 21:58:06

いやいや、きっと次のC++の版くらいには
復活するでしょconceptさん。

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

2010/04/25(日) 22:31:24

なんか面白い話題無い？

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

2010/04/25(日) 22:35:24

>>328
C++0xには今のところない。

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

2010/04/25(日) 23:07:36

　　　　　　　　＿_
　　　　 , ‐' ´　　　｀`‐、　　　　　　／￣:三}
.　　　／,. -─‐- ､.　　ヽ　　　　　　　　/　　 ,.＝j
　＿,.:_'＿＿＿＿＿_ヽ、　.!　　　　　 .／　 _,ﾉ
　 `‐、{　へ　　'ﾞ⌒　`!~ヽ. !　　　　／{.　　/
　　　｀!　しﾟ　（　ﾟj　`v‐冫　　　, '::::::::ヽ､/ 　　　　話題がないなら野球しようぜ！
.　　　 {.l 　 '⌒　　　ﾞ 6',!　　 / :::::::::::::::/ __
. 　　〈　　< ´￣,ﾌ　 .ﾉｰ'_ , ‐'´::::::::::::::;/ （_ノ)‐-､
.　　　ヽ.、 ` ‐", ‐´‐:ラ ':::::::::::::::: ;∠.　　ヽ_}　ﾞヽ
　　　　 ,.r｀ "´　　／:::::::::::::::::::ィ´　　｀ゝ　 !、　　/
　　　　　/ 　　　 / :::::::::::::::: ; '´　　　/´＼　/ 　 r'＼
.　　　　 i　　　　　 ! ::::::::::::::／墨　|　.!::::::::／ヽ､.._!ヽ.　ヽ､
　　　　 {　　　　　 {:::::::::::;:ｲ　/　　 ∥ｉ:::::::/:::::::::::::/　＼
.　　　ヽ　　　ヽ,.ｧ‐'´ /ヽ二 ,/`ヽ、::::::::: ／

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

2010/04/25(日) 23:17:18

GCCの完全サポートがまぁ4.5.x～4.6ぐらいだとして
VC++のサポート完了はまたSP1待ちかね。
tr1の時も遅かったし…

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

2010/04/25(日) 23:57:52

VCなんかに期待してるのか？
やめとけ。無駄だ。

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

2010/04/26(月) 00:00:53

ＶＣ３０００のど飴のことです

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

2010/04/26(月) 00:15:21

2020年、cppxlang + LLVM が盤石

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

2010/04/26(月) 03:25:13

>>334
いや、2011年にはC++0x完璧で、
下手すりゃconceptも2012年くらいに実装されてると思う。
Clangは凄い勢いで成長してる。
コードも綺麗。

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

2010/04/26(月) 03:31:12

Cに変な拡張入れるのやめて欲しい…>Clang

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

2010/04/26(月) 03:37:45

しゃーねーだろ。gcc互換目指してるんだから。

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

2010/04/26(月) 03:42:48

gcc拡張ならともかくCにGCとかクロージャとか誰か止めなかったのか
せめて一言"ObjCでやれ"と言う奴はいなかったのか・・・

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

2010/04/26(月) 04:03:54

いや、ああいうのはLLVM的に必要だから。
LLVMとの絡みで実験的な実装をやるのが、
Clangの目的のひとつ。そしてLLVMの仕様に反映。

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

2010/04/26(月) 06:31:05

>>335
C++0xの現行版の仕様が確定するのが
2011年だぞ？

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

2010/04/26(月) 07:20:39

アホが来た

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

2010/04/26(月) 08:50:02

どうも。いつもお世話になってます。アホです。

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

2010/04/26(月) 08:59:27

なんでこれで笑ってしまったんだろう・・ｗｗ

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

2010/04/26(月) 09:12:19

>>340
実装状況調べてないだろw

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

2010/04/26(月) 10:57:21

>>344
ぜんっぜん調べてねぇけど、ドラフトは読んでるよ。
この状況では確定するのはやっぱり2011年だろ？

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

2010/04/26(月) 11:07:29

FCDまで来たから、機能が増えたり改められたりはもう多分ない。
何か問題があったら引かれるだけ。conceptのように。
あとはrvalueみたいに表現の調整ぐらい。

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

2010/04/26(月) 11:26:16

>>346
このFCDのまま行くのかね？
あと1回くらいFCDを出し直してそれから進むと踏んでいるんだけど。
その辺を含めて2011年と見ている。

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

2010/04/26(月) 12:51:11

今年の夏からFCDという制度そのものがなくなってしまうので、多分このまま
FCD→FDISと行くんじゃないかなあ。FDISは事実上の信任投票で
技術的変更は不可だから、FCD→FDISの間で「FDIS投票がこけないような修正」を
して終わりだと思う。

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

2010/04/26(月) 12:54:20

ああでもTarget publication date: 2012-02-28なんて話題もあったっけ。
んー、もうあとは引き算だけだと思うんだけどねえ。

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

2010/04/26(月) 19:45:01

noexceptは簡単には済まないと思うけどねえ
ムーブセマンティクスと例外の絡みで出てきた話だから引けばいいってもんでもないし

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

2010/04/26(月) 21:12:42

noexceptは引き算されそうなにおいがぷんぷんするな。

0352340

2010/04/26(月) 21:13:25

>>341-344
んで、無知なあなた方は、なんか俺に謝る事あるんじゃないの？

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

2010/04/26(月) 21:16:43

うわっ　ｷﾒｪ＾＾

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

2010/04/26(月) 21:19:42

既に実装されているものもあるのにねえ。

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

2010/04/26(月) 21:21:18

引き算だけならいいけど、それが形を変えて戻ってきたら
実装済みのコンパイラ涙目

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

2010/04/26(月) 21:24:56

掛け算されたりして
アッー！

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

2010/04/26(月) 21:28:56

>>353-354
で？
俺は実装の話なんて一言もしていないが。

> C++0xの現行版の仕様が確定するのが
> 2011年だぞ？
としか言ってないけど。
なんか正当な反論ができるならしてみろよ？無知が。

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

2010/04/26(月) 21:48:30

どうも。ご迷惑おかけしています。アホです。

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

2010/04/26(月) 22:04:10

あんたが正しいか正しくないかじゃなくて、
こんな２ちゃんごときで謝れとか言い出すあんたの器量の狭さがキモいんですよ＾＾

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

2010/04/26(月) 22:08:05

>>357
pgr

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

2010/04/26(月) 22:33:47

はいはいごめんやさいごめんやさい

0362340

2010/04/26(月) 22:47:55

>>358-361
んで結局お前らは全員が知ったかぶりだったってことでいいんだな？

この件を恥じ入り、以後知ったかぶりを改めるように！

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

2010/04/26(月) 23:19:11

はーい^^

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

2010/04/26(月) 23:24:49

おまえら明日VS2010でたら色々遊んでレポートしなさい

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

2010/04/27(火) 15:47:12

本の虫のブログで初めて知った。
deleted定義
ttp://cpplover.blogspot.com/2010/04/deleted.html

これすげー便利だな。

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

2010/04/27(火) 17:14:01

>>365
予約語deleteの再利用か。
exportは仕事首になったからまさに完全ニートになってるけど、
予約語としては生き残っているらしいから、
なんか有効利用してあげられないかな？

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

2010/04/27(火) 17:28:30

concurrency/atomics 周りが GCC 4.6, 4.7 あたりで
完全にサポートされるようになるとはとても思えない……

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

2010/04/27(火) 20:14:10

本の虫がそこに気付いてなかったとは…

template<typename T> operator T() = delete;なんて好きそうなのに

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

2010/04/27(火) 20:16:31

俺もメンバ関数にしか使えないのかと思ってた

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

2010/04/27(火) 20:17:33

ほほうそれは Tの修飾をどの程度含んで殺してしまうのかね？

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

2010/04/27(火) 20:22:25

>>367
gccはその辺は一番遅いでしょ。
昔みたいにx86専用フォークあれば別だけど。

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

2010/04/27(火) 21:31:40

deleteに続いて併せて使われる予定のdefaultはなんだか微妙な感じだな。
純粋仮想関数よりは見た目はいいが。

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

2010/04/27(火) 21:51:32

=defaultも大事だぞ

struct Point{
int x,y;
Point() = default;
Point(int x, int y) : x(x), y(y){}
};

これが出来るだけで凄い価値がある

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

2010/04/27(火) 21:55:43

Point() {} と何が違うんだっけ
inline強制じゃないんだっけ？

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

2010/04/27(火) 22:20:02

Point(){}はコンパイラ生成のデフォルトコンストラクタじゃない＝PointはPODじゃない

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

2010/04/27(火) 22:23:23

コンストラクタつきのPodが可能になるのか

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

2010/04/27(火) 22:54:25

Podってキャピタライズされると地味に違和感

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

2010/04/27(火) 23:02:40

デフォルトコンストラクタだけデフォルトでも
他が違えば意味ないんじゃないの？　＞POD

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

2010/04/27(火) 23:09:53

コピコン、operator=、デストラクタは書かなけりゃデフォルトだからいいの

デフォルトコンストラクタだけは自分でなんかコンストラクタ書くと潰されるから
明示的に指定が必要

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

2010/04/27(火) 23:40:17

だから Point() {} と何が（ry
デフォルトのコピコンやoperator=をprivateにしたい時に使うのは便利そうだけど

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

2010/04/27(火) 23:56:42

http://d.hatena.ne.jp/faith_and_brave/20081127
http://ja.wikipedia.org/wiki/C++0x#Plain_Old_Data_.E5.9E.8B.E3.81.AE.E5.AE.9A.E7.BE.A9.E3.81.AE.E4.BF.AE.E6.AD.A3

C++0xではPODの定義が変わって
>>373の構造体はPODになるとかならないとか

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

2010/04/27(火) 23:56:55

新しい関数宣言やラムダって当初のまんまなの？

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

2010/04/27(火) 23:59:04

>>381
なーるほど
それだと重要だな

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

2010/04/27(火) 23:59:55

そういや、デフォルトのコピコンやoperator=を殺したければdeleteすりゃいいんだった

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

2010/04/28(水) 00:07:36

>>382
unified function syntaxはボツになりました…

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

2010/04/28(水) 00:11:31

unified function syntaxはクソだったからな。
不細工すぎるだろ

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

2010/04/28(水) 00:12:29

やっぱりあれはボツだよなあw
安心した

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

2010/04/28(水) 00:13:43

>380
default constructor が trivial か non-trivial かの違いになります．
で，この違いがどうなるかというと結構大量にあるっぽいので
誰か親切な人まとめてください．

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

2010/04/28(水) 00:18:50

>>387
うむ。
いくら何でもなぁ。

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

2010/04/28(水) 00:23:10

POD って C++0x でそれほど重要な概念になってます？

どちらかというと， POD という用語の従来における定義の個々の構成要件だった
「各 special member function が trivialかどうか」や
"standard-layout type" といった概念が，それぞれ独立して
重要な仕様上の概念として活躍しているような？

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

2010/04/28(水) 00:26:34

そういやドラフトでPOD関連全般にもの凄い修正入ってた気がするわ
多すぎて目を通してなかったけど

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

2010/04/28(水) 00:28:05

最後にまともにC++に触ったの10年くらい前で、既にJavaに移行してしまった者なんだが、
お前らが何を言ってるのかさっぱり分からん。

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

2010/04/28(水) 00:32:11

多分ずっとC++使ってる人でも分からないから問題ない

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

2010/04/28(水) 00:33:21

PODの重要性は今までと一切変わらんよ
CのAPIに渡したりバイトの塊としてストリームに流せたりすることを保証する枠組みは絶対に必要

仕様上の概念としてはtrivialとstandard-layoutに整理されて文言の登場頻度は減ったけどね

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

2010/04/28(水) 00:35:53

いったいなんなんだC++って。

0396390

2010/04/28(水) 00:43:19

>394
＞CのAPIに渡したり～
この部分は完全に同意していて， >390 は単に
＞文言の登場頻度は減った
んじゃないの？っていうのが言いたかっただけです．すいません．

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

2010/04/28(水) 03:23:06

どうでもいいじゃない、そんなこと。
PODの概念が具体的な形で整理されたことが大切。

より重要な概念になったかどうかとか、登場回数が減ったとかどうでもいい。
重要かどうかってのは評価に属することなんで、考え方次第。

C++は、PODにしても>>367にしても、
高級アセンブラとしての役割というか、
低レベルな部分での仕様を追求するのが面白いね。

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

2010/04/28(水) 12:12:53

>>397
さすが移植用アセンブラたるC言語の直系の子孫。
いつまでも変態記法と低レベル作業を忘れないでね。

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

2010/04/28(水) 13:24:24

変態な君が好き。

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

2010/04/28(水) 15:56:12

変態紳士な貴方も、チェリーボーイな君も、ウィザードハッカーな彼も。
みんな大好きC++。

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

2010/04/28(水) 16:03:50

むしろそういうヤツしか大好きじゃないんじゃないかなC++

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

2010/04/28(水) 18:45:05

俺ってウィザードハッカーだったのか

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

2010/04/28(水) 19:11:38

C++はメジャーな言語です。
メジャーな言語を使えるプログラマーは変態ではありません。技術者です。

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

2010/04/28(水) 23:33:57

高級アセンブラって褒め言葉にしか聞こえない。

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

2010/04/29(木) 02:35:09

C99と違ってMSも実装に前向きみたいだけど
0xってどれだけ普及するだろうか

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

2010/04/29(木) 02:44:43

正直「C++で開発してます」と言ってる業界のtemplateの普及度すら怪しい

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

2010/04/29(木) 02:46:29

凄い的確な返しだ

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

2010/04/29(木) 03:04:45

>>406
templateは保守性が低いから使うな！ってよく言われるよ。
lambdaなんぞ入ったらどうなることやら…。

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

2010/04/29(木) 03:15:55

保守性が低い、の意味が、
俺らが読めない、だからなあ

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

2010/04/29(木) 08:54:11

ある意味真理

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

2010/04/29(木) 09:23:34

過去スレ読めないので既出かもしれませんが質問させてください。

vector<int> v(10000);
のように書いたときの v の要素は C++0x では初期化されなくなるのでしょうか？

23.3.6.1
explicit vector(size_type n);
3 Effects: Constructs a vector with n default constructed elements.
と書かれていて、default constructed というのは、POD型では初期化されていないことを意味すると思うのですが。

これに関係していそうなので↓こんなものを見つけましたが
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868
上の文はまだ修正される可能性があるのでしょうか？

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

2010/04/29(木) 09:24:11

分かる人間がいなきゃ企業としては保守性低いわなぁｗ
概念的にはそんなに難しいものじゃないけど
ヘッダに実装書くことによる細かいバッドノウハウはちょっとだるい

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

2010/04/29(木) 09:27:05

>>411
POD型のデフォルトコンストラクタは0クリアじゃないの?

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

2010/04/29(木) 10:45:16

>413
thanks.
default constructed とは value-initialized(8.5) と同じ意味なんですね。

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

2010/04/29(木) 10:48:13

古いVC++だと初期化されなかったような気がする
所詮規格は規格であって実装で無視されたら意味ないしなあ

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

2010/04/29(木) 10:48:55

いや、あれはvectorじゃなかったか・・・？
記憶が曖昧だ・・・
違うかもしれない

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

2010/04/29(木) 12:13:29

VC10express使った人いる？
どうかな？対応具合は？

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

2010/04/29(木) 13:28:25

XP SP2には対応していなかった

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

2010/04/29(木) 18:31:41

誰もそんなこと聞いてねぇｗ

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

2010/04/29(木) 19:36:54

ワロタｗ
でも地味に良い情報だったｗ

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

2010/04/29(木) 21:10:51

対応してないのか、単に保証してないか、どっちなんだろう
単にSP2自体サポート終了してるから対象から外しただけな気もするが

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

2010/04/29(木) 22:23:01

A がムーブコンストラクタを持つ状態で

A foo() { return A(); }

を実行した場合、文法上、戻り値返す際に動くのは
コピーコンストラクタとムーブコンストラクタのどっち？
（実際にはどちらにしろ戻り値最適化されるだろうけど、
　仮に文法上コピーコンストラクタが実行されるなら、
　コピーコンストラクタを private にした時（あるいは delete した時）に
　エラーになるという違いがある）

とりあえずVC++2010はコピーコンストラクタが動こうとするみたいだけど。

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

2010/04/29(木) 22:25:45

>>415
> 古いVC++だと
古いVC++なんて、それを言って良いならいくらでもそんなことはあるだろうよ。

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

2010/04/29(木) 22:34:13

>>422
それだけだと右辺値参照する側がいないんじゃないか。

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

2010/04/29(木) 22:40:03

受け取るやつがいるいないは関係なくない？
どこから呼ばれるかコンパイル単位には分からないわけだし

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

2010/04/29(木) 22:42:07

>>422
ムーブコンストラクタがあればそっちで、なければコピーコンストラクタ、でしょ。
そうじゃないと困りそう。

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

2010/04/29(木) 22:48:57

>>424
戻り値最適化がないなら、
return に書いた式から、関数の戻り値へとコピーかムーブが走ると期待できる

>>426
じゃあVC++2010の挙動がおかしい、と
publicなムーブコンストラクタとprivateなコピーコンストラクタを定義したら、
コピーコンストラクタが使えないよというエラーになるから

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

2010/04/29(木) 22:55:37

もう１つ、

A a(A(1));
A a(foo());

でも同じ状況でVC++2010はエラーになる。
ただし、後者ではコピーコンストラクタを有効にして実際に実行してみると
ムーブコンストラクタしか動かない。
（前者は最適化されてコピーやムーブ自体が実行されない）

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

2010/04/29(木) 22:58:37

VC++2010、地味にヤバそうな予感
まだゴリゴリ書かない方がいいのか・・・　って、何か問題起きたら 2008に持ってけばいいのかｗ

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

2010/04/29(木) 23:00:14

いや、すまん
>>428 は後者も最適化されてコピーもムーブも動かないわ

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

2010/04/29(木) 23:02:53

ムーブコンストラクタはそんなに神経質に使うものじゃなくないか？適用されたら儲け程度に考えればいいんじゃね。

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

2010/04/29(木) 23:09:23

void hoge(A&& a) {
　a.piyo(); // piyoは非constメンバ関数

　A b(a); // ムーブ？　コピー？
　b.piyo();
}

hoge(A());

これでコピーコンストラクタが動いたんだけど
ひょっとしてムーブコンストラクタの考え方、俺間違ってる？

a.piyo(); が実行できたという点では
右辺値参照万歳ではあるんだけど

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

2010/04/29(木) 23:12:59

>>432
ムーブしたかったら A b(std::move(a)) じゃないか？

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

2010/04/29(木) 23:14:57

>>432
そこで勝手にmoveしちゃったらその後のaはどうなるんだよ

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

2010/04/29(木) 23:14:57

>>433
おお、そうなんだ
そうしたらムーブコンストラクタが呼ばれたわ
ありがとう

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

2010/04/29(木) 23:15:59

>>434
あとは野となれ山となれ

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

2010/04/29(木) 23:22:26

というか、>>422 のエラー発生状況の説明が
「'A' から 'A &&' への変換時」ってなってるな
どうもムーブコンストラクタを呼ぼうとはしているみたいだ
でも、なぜかコピーコンストラクタがアクセス可能じゃないとダメ、と

'A' から 'A &&' への変換に
なぜコピーコンストラクタへのアクセス可能性が要求されるのだろう？

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

2010/04/29(木) 23:24:40

名前付きの値は（左辺値参照でも右辺値参照でも）左辺値として扱われる。
>>432 の例でいうとaをムーブコンストラクタに渡すには
std::moveの返値（無名の右辺値参照）にしなければいけないわけだ。
なるほど。

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

2010/04/29(木) 23:27:24

>>438
なるほど
ムーブコンストラクタがあっても、
左辺値でコンストラクとしようとする時には
勝手に右辺値参照になってはくれないのね
確かに安全のためには必要そうな仕様だ

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

2010/04/29(木) 23:40:37

ひょっとして、ムーブ可能にしたければ
コピーも可能じゃないとだめというのが仕様だとか？
でも、MoveConstructible requirements にそういう事は書いてないし・・・

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

2010/04/30(金) 02:11:51

>427
＞publicなムーブコンストラクタとprivateなコピーコンストラクタを定義したら、
＞コピーコンストラクタが使えないよというエラーになるから

再現しないっぽいのでとりあえずコード全体をさらしてほすぃ……

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

2010/04/30(金) 02:18:31

422==432で書いてたコードand/or考えが間違ってたんだろう

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

2010/04/30(金) 03:01:44

不思議な事に、こっちでも新しく書いたら再現しない
条件があるのかも

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

2010/04/30(金) 03:06:11

めっちゃアンドゥして昔のコードに戻したけどやはり再現しない・・・
一体なんなんだ

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

2010/04/30(金) 03:47:00

auto p = new auto(1);
delete p; // 死ぬ
auto p = new auto(2.0 * 3.4);
delete p; // 死ぬ
auto p = new auto("hoge");
delete p; // 死ぬ

基本型を引数に取ってnew autoすると
delete時に死ぬ

クラスとかなら問題ない

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

2010/04/30(金) 04:13:09

new autoとかありだということに驚いた

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

2010/04/30(金) 06:30:36

最後はdelete[]だろ

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

2010/04/30(金) 07:18:27

>>445
どのコンパイラくらい書いてくれ。

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

2010/04/30(金) 08:18:51

死ぬってのは実装の問題ってこと？

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

2010/04/30(金) 08:35:12

VC++2010で試したら確かに実行時エラーで死んだ。
誰かGCCで試してみてほしい。

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

2010/04/30(金) 08:51:30

なんだこのスレタイと全然関係無い話題なのに
妙に価値のある内容は。

もっとやれ

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

2010/04/30(金) 09:50:00

>>445
g++-4.5 (Debian 4.5.0-2) 4.5.1 20100419 (prerelease)
だと死なない（そりゃそうだ）

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

2010/04/30(金) 10:47:13

>>447
ポインタをnewしてるだけだからdeleteで問題ない

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

2010/04/30(金) 11:39:19

new auto("hoge") は const char**

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

2010/04/30(金) 12:45:29

deleteかdelete[]かを判断できないのだからnew auto(ここの部分);で、動的にdeleteかdelete[]かを選べるshared_ptrみたいな動的削除子が組み込みで欲しいな。

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

2010/04/30(金) 12:47:09

　　　　　　　　　　expression
　　　　　　　　　／　　　　　＼
　　　　　　 glvalue　　　　　rvalue
　　　　　／　　　　＼　　／　　　　＼
　　　lvalue　　　　 xvalue　　　　prvalue

Figure 1 -- Expression category taxonomy

何か笑ってしまった
複雑だなあ

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

2010/04/30(金) 12:48:04

>>455
new auto で確保したものは常に delete
配列 new を初期化パラメータ付きで行うのは不可能だから

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

2010/04/30(金) 12:51:23

そうだった。つまりこれはnew autoしたのをdeleteする処理系が悪いということか。

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

2010/04/30(金) 12:55:10

new autoは実はGCが働くんだよ！

だったらいいんだが
autoってそんな意味じゃねー

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

2010/04/30(金) 12:57:51

newしてるのにポインタじゃなくてスマポが返るんですね分かります

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

2010/04/30(金) 13:07:33

>>456
仮想継承にしなくちゃならないなｗ

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

2010/04/30(金) 13:12:08

>>456
シンプルやん。
対称だと頭に入りやすい。

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

2010/04/30(金) 13:30:37

　　　　　　　　　　expression
　　　　　　　　　／　　　　　＼
　　　　　　　lvalue　　　　　rvalue
　　　　　／　　　　＼　　／　　　　＼
　　 plvalue　　　　 xvalue　　　　prvalue

これなら対称なんだけど

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

2010/04/30(金) 13:32:57

>>463
機能まで対称だったらわざわざ仮想継承構造にする必要ないけどな

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

2010/04/30(金) 13:35:43

lvalue &
rvalue &&
prvalue &&&
になりそうな予感

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

2010/04/30(金) 13:41:13

int n = 0;
auto l = [=]() mutable { ++n; std::cout << n << std::endl; };
l(); //1と表示
l(); //2と表示

ラムダ式を作成した時に
クロージャ型の非staticメンバ変数のnに外のnがコピーされるから、
それを変更すると次の呼び出しでもその影響が残るのは
仕様でいいのよね？

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

2010/04/30(金) 14:28:27

ラムダ式はreturnできないし（template<class L> L hoge(L lambda) { return lambda; } みたいなのは例外で可能だが）、
関数ポインタに渡せないんだな
前者は戻り値の型が書けないからで、
後者は関数呼び出しがクロージャ型の非staticメンバ関数だからだな
どちらも仕方が無いけど、微妙に不便

まあ後者は、クロージャ型の非staticメンバ変数に
operator() を自インスタンスを使って call するコードを
持たせる事で実現できるとは思うのだが、
メモリの実行権限とか考えると微妙だわなあ

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

2010/04/30(金) 15:15:49

>>465
> lvalue &
> rvalue &&
> prvalue &&&
何気に分かりやす・・・くねぇな

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

2010/04/30(金) 17:34:03

って、規格上はラムダ式は関数ポインタに変換できるのか……
今年３月の話みたいだから対応して無いのは当然だけど

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

2010/04/30(金) 17:38:11

関数ポインタよりもresult_typeが欲しいよ。

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

2010/04/30(金) 18:09:13

std::functionにキャストすれば使えるんじゃないの＞result_type

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

2010/04/30(金) 19:06:02

>>471
なんと、その手があったのか。改めてfunctionはすごいな。
ラムダ式をboost::lambdaでラップしようかとか悩んでた。

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

2010/04/30(金) 21:11:54

swap技法が適用されるデフォルトムーブ演算子operator=(&&)とかできないかなあ。

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

2010/04/30(金) 21:40:51

デフォルトムーブ代入演算子なら最新のドラフトに入ったよ

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

2010/04/30(金) 23:09:11

戻り値の型を auto にして trailing return type を省略し
return する値の型を全て同じにすれば
戻り値の型を自動的に類推してくれる、
という仕様は検討された事ないのかな
それがあれば関数をカリー化して返せるんだが

auto add(int n) {
　return [=](int x) { return x + n; };
}

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

2010/04/30(金) 23:14:48

>>474
おおっとそれはすごい。VC10にいつかはサポートされるかな。
現状のVC10はどこまでサポートされてるのかさっぱり分らない。SPが出るたびに調整かｗ

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

2010/04/30(金) 23:29:33

>>475

　auto add = [](int n) {
　　return [=](int x) { return x + n; };
　};

で我慢しろ

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

2010/04/30(金) 23:37:39

>>476
http://blogs.msdn.com/vcblog/archive/2010/04/06/c-0x-core-language-features-in-vc10-the-table.aspx
http://wiki.apache.org/stdcxx/C++0xCompilerSupport

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

2010/05/01(土) 00:02:33

Unified Function Syntaxも戻り値の型推測入れればいいのに

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

2010/05/01(土) 00:15:10

>>475
宣言だけの場合は？

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

2010/05/01(土) 01:14:15

>>480
inline や template と同様、ヘッダにしか書けない
ただし、static を明示的につけない限り、リンク時に実体は１つにまとめられる
宣言だけ書くことはできるが、同じ翻訳単位に定義が必要

みたいな感じで

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

2010/05/01(土) 01:15:40

×ヘッダにしか書けない
○複数の翻訳単位から利用するにはヘッダにしか書けない

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

2010/05/01(土) 01:18:30

まあ、同じ定義を自分で複数の翻訳単位に書いてもいいんだけど
それはそれこれはこれということで

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

2010/05/01(土) 01:38:18

>>478
ありがとう。対応状況が一目で分かって助かります。

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

2010/05/01(土) 11:05:51

引数が二個ある関数で右辺値参照するときは、
こんな風に全ての組み合わせがいるの？

hoge func(const fuga& a,const piyo& b);
hoge func( fuga&& a,const piyo& b);
hoge func(const fuga& a, piyo&& b);
hoge func( fuga&& a, piyo&& b);

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

2010/05/01(土) 11:30:56

どういう使い方するかによるんじゃない
普通は一方をもう一方の情報を使って変更して
変更したオブジェクトを返すという形にすると思うけど

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

2010/05/01(土) 13:19:54

VC10で is_pod<void>::value がtrueになるのは相変わらずか。

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

2010/05/01(土) 16:03:18

>>485
なるほど、通常は片方だけですむってことなのか。

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

2010/05/02(日) 04:07:58

ラムダ面白いな。
てきとーにVC10ee触ってるんだが、ラムダって制限つきローカル関数のように使えるな。
さらに便利かも。

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

2010/05/02(日) 08:57:41

確かにfor_eachなどに直接渡すだけじゃなく、ローカル関数として使えるね
これでいちいち関数内に構造体作る必要がなくなったわ
しかもメンバにも直接アクセスできるし

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

2010/05/02(日) 09:48:03

ラムダ関数はresult_typeを定義してくれてたら完璧なんだけど

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

2010/05/02(日) 12:15:28

その辺はconceptで整備するつもりだったんだろうけど…
function_traitsを定義するんで凌ぐのかな。

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

2010/05/02(日) 15:36:14

>>490
メンバにもアクセスできるの？！

ローカルクラスとかわんないと思いこんでた

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

2010/05/02(日) 15:39:58

環境いじれないのはlambda式じゃないぜ…

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

2010/05/02(日) 16:43:10

thisをキャプチャすればメンバに触れる
どうせ[=]か[&]にするだろうから
自動的にキャプチャされるだろうが

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

2010/05/02(日) 19:02:42

むしろthisがキャプチャされない場合って．．．？

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

2010/05/02(日) 19:36:34

[]にしたい時だってある

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

2010/05/02(日) 20:48:36

引数しか使わない
そんな気分の時があります

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

2010/05/02(日) 20:59:31

キャプチャってなんだーー！！！

ああ、0xのLambda式か。

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

2010/05/03(月) 00:01:17

autoって本当に便利ですね。てかテンプレートには必須だよ。

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

2010/05/03(月) 00:08:41

キャプチャしない場合でも、[&][=]って書いてもペナルティはない？
紛らわしいからやめろと言われればその通りなんだが、コンパイラがどういうコードを吐くのか気になる

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

2010/05/03(月) 00:15:16

最適化すりゃ消える

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

2010/05/03(月) 00:15:56

むしろ追加でコード生成されんの？

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

2010/05/03(月) 00:28:00

lambdaって戻りを省略できるると思ってたのですが。
VC10です。C++0xWikipediaにも省略できるって書いてあるのに？
auto z0=[](int x)->{return x;}; //エラー
auto z1=[](int x)->int{return x;}; //OK
auto z2=[](int x)->decltype(x){return x;};//OK

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

2010/05/03(月) 00:29:10

すまん，キャプチャの意味がわかってなかった．．．

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

2010/05/03(月) 00:43:19

>>504
おばか

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

2010/05/03(月) 00:49:10

省略の意味がちげえｗ

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

2010/05/03(月) 05:56:52

>>502
コピコンのあるようなものがいらっしゃると消えてくれないかも

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

2010/05/03(月) 09:42:06

[](int x){return x;}

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

2010/05/03(月) 10:45:04

->int とかの trailing-return-type って普通の関数定義にも使えるんだな
用途がよくわからんが

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

2010/05/03(月) 10:52:02

Phase of translation の 5 なんだけどさ

std::printf("%.4x\n", (int) u'\u0905'); //デーバナーガリー文字 \u0905

↓ phase 5

実行時キャラクターセットに対応する文字が無ければ
'\0'以外の適当な文字に置き換えられる
(eucとかだったら \u0905 は無い)

std::printf("%.4x\n", (int) u'?');

↓
実行結果: 003f (プレフィクス u をつけてもやっぱり 0905 にならない)

――ってこと？　最近のOSなら大丈夫なんだろうけど。

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

2010/05/03(月) 11:06:26

>>507 kwsk

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

2010/05/03(月) 12:50:15

>>510
template <typename T>
auto foo(T a, T b) -> decltype(a + b) { return a + b; }

とかできるよね、という話らしいよ

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

2010/05/03(月) 12:54:00

あとは auto foo() -> int(*)(); とか、関数ポインタや配列ポインタを返しやすいとか

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

2010/05/03(月) 12:57:20

そういやlambdaはDLLにexportできるようになるんかな？

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

2010/05/03(月) 12:58:54

exportするなら普通の関数でええやんという話

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

2010/05/03(月) 12:59:27

>>509　あ、そうか。そうだような。俺が馬鹿でした。
でもさすがにC#のように引数の型を省略 auto z3=[](x){return x*2;}; は無理？とおもったけど。
auto z4=boost::lamabda::_1*2;　はOKなのね。boost::lambda恐るべし。

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

2010/05/03(月) 13:02:53

C#の型推論はデリゲート側と型を一致させるというしくみだから
autoで受けるC++0xではまあ使えないわなあ

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

2010/05/03(月) 13:10:52

>>513-514
なるほど、納得。

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

2010/05/03(月) 13:13:25

どんどん初心者お断りで複雑怪奇な仕様になっていってる気がする…

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

2010/05/03(月) 13:14:46

なにをいまさら

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

2010/05/03(月) 13:15:43

カンタンカンタン

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

2010/05/03(月) 14:41:40

>511

u'\u0905' wchar16_t だから「実行時キャラクターセット」は使われません。
どんな環境でも UTF-16 エンコードが使われます。
0x0905 と同じ表現を持つ値となります。

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

2010/05/03(月) 16:44:54

>>523
実行文字集合に無い文字は、翻訳段階5でいったん文字化けさせろって書いてない？
「文字(列)リテラル中のユニバーサルキャラクター名は、実行文字集合中の対応物に置き換える」

リテラル中の文字が、ユニコードでどの値を持つか評価されるのって、その後だよね？

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

2010/05/03(月) 20:40:41

>>520
分かる部分だけ使ってりゃいいって

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

2010/05/03(月) 21:01:41

コンセプトが入ってればエラーメッセージが(以下略

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

2010/05/04(火) 00:06:10

C++0xはよく考えられた改良だと思うけど
互換性のために殆どが「追加」になっちゃうんだよね
便利でシンプルで完全に動作するC++のサブセットって定義できんもんだろうか

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

2010/05/04(火) 00:08:11

互換性を無視したとして、いらない機能は何だろう？
つ可変引数

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

2010/05/04(火) 00:11:23

それは要るだろw
筆頭は0＝ヌルポインタだな。

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

2010/05/04(火) 00:13:03

古い(というか従来の)関数宣言
struct か class のどちらか
古い(というか従来の) enum

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

2010/05/04(火) 00:17:07

typedef

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

2010/05/04(火) 00:17:40

型変換演算子の廃止

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

2010/05/04(火) 00:18:19

コピコンとデフォコンの特殊ルール

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

2010/05/04(火) 00:19:06

unsigned全部

0535527

2010/05/04(火) 00:29:42

>>527 は新しい言語を作るんじゃなくてサブセットを定義して学習のコスト削減を意図してました
仕様変更ではなくコーディングルールみたいなもん

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

2010/05/04(火) 00:32:07

>>529
printfみたいに引数の検査ができな可変引数よりも、
cout<<a<<b; とか boost::format("%d %d")%a&b;
とかてC++の機能で代用できるもので可変引数は廃止でいいんじゃないか？

hoge a(); が関数のプロトタイプになるのはなくしていいとおもう。

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

2010/05/04(火) 00:34:21

boost::format("%d %d")%a%b; だった。

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

2010/05/04(火) 00:43:08

これだろ…
std::vector<bool>

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

2010/05/04(火) 00:48:27

1パスコンパイル

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

2010/05/04(火) 00:49:54

bind1st , bind2nd, fun_ptr

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

2010/05/04(火) 00:51:57

>>536
printfを例に出すとは素質悪いな

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

2010/05/04(火) 00:56:10

禿の新しいC++本(Programming: Principles and Practice Using C++)で
10行程度しか触れられていない
valarray

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

2010/05/04(火) 00:56:45

互換性を無視していいならいらない機能の筆頭は、暗黙の変換
バグの元

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

2010/05/04(火) 00:59:15

アップキャストがバグの元っていったい

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

2010/05/04(火) 01:00:58

>>544
non-explicitなコンストラクタとかoperator T()のことじゃない？

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

2010/05/04(火) 01:02:40

整数の暗黙の拡張とか

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

2010/05/04(火) 01:10:06

暗黙の変換というか標準変換の一部と言うべきなのか
要するに数値型間の暗黙の変換

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

2010/05/04(火) 01:57:08

charをintegral typeから外して、integral type最小のbyteを設ける。

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

2010/05/04(火) 01:59:30

暗黙の型変換なくす人、
xがintの時、式 x * 3.14 の型はintでOK?

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

2010/05/04(火) 02:00:56

コンパイルエラー

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

2010/05/04(火) 02:02:56

>>549
#pragma yutori
ならばOK

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

2010/05/04(火) 02:05:09

整数の拡張って何がまずいん？

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

2010/05/04(火) 02:10:00

unsigned int x = -1;
がコンパイルできちゃう

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

2010/05/04(火) 02:21:52

static_cast使いまくりで可読性が悪くなりそう

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

2010/05/04(火) 02:28:01

>>491
result_ofが使えればいいよ。

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

2010/05/04(火) 02:29:28

>>553
警告が出るからいいんじゃね？

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

2010/05/04(火) 02:32:38

数値の暗黙の拡張にこれほど疑問や反論がでるのは予想外だった
正直、ほとんどの人に共通の認識だと思ってた

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

2010/05/04(火) 02:35:27

>>556
これには警告でないでしょ
gcc -Wall でも警告でないはず

unsigned f(int y)
{
unsigned int x = y;
return x;
}

unsigned int g()
{
return f(-1);
}

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

2010/05/04(火) 06:01:55

-Wsign-conversion で警告がでるな

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

2010/05/04(火) 11:10:01

-Wextra

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

2010/05/04(火) 11:48:53

-Warata

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

2010/05/04(火) 11:53:26

-Wwwwwwww

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

2010/05/04(火) 12:09:41

多少ずれるが
unsigned変数の小なり０比較はエラーにすべき

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

2010/05/04(火) 12:52:01

>>563
警告出して最適化してくれれば十分だと思う。
テンプレート使ってるとsignedとunsinged両方使えるようにするとき役に立つ。
警告なら必要に応じて抑制できるけど、エラーだとsignedとunsingedで分岐するテンプレートを書く必要が出てきて面倒。

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

2010/05/04(火) 12:54:21

最適化というのは，勝手にsigned変数に変更するということ？
それとも比較元を＋１して小なり1比較ってこと？

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

2010/05/04(火) 12:55:00

いや、常にfalse判定じゃないかと

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

2010/05/04(火) 13:01:05

うんfalse判定でifのtrue項が削除されてとりあえず警告。その箇所だけpragmaで警告抑制。

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

2010/05/04(火) 14:48:38

>>563
エラーにするのはループ条件に出てきた時だけでいい
その他の場合はフェイルセーフで書く事もあるので警告すら出て欲しくないな

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

2010/05/04(火) 15:37:34

>>568
ループ条件に出てきたときはループ削除でよくない？エラーはやりすぎでしょう。

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

2010/05/04(火) 15:39:53

>>569
ごめん
別な条件の方で考えてた
(unsigned)x >= 0 の方

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

2010/05/04(火) 19:07:10

-Wallでも警告されずバグを埋め込んだ例
https://bugzilla.kernel.org/show_bug.cgi?id=12597

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

2010/05/04(火) 20:28:37

>>571
すげー
Linus Torvalds の生コメントがある！

・・・でもLinusはC++大嫌いだったな確か。

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

2010/05/04(火) 21:36:18

enum class って劣化 Java の enum だよね
Java の enum そのものにしてくれないかなぁ・・

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

2010/05/04(火) 22:21:57

どちらかといえばC#のenumが近い

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

2010/05/04(火) 22:26:04

それは確かに否め（enumえ）ない

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

2010/05/04(火) 22:39:39

>>573
Java の enum ってどういう挙動なんだか知らんが
そんなに良いのか？

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

2010/05/04(火) 22:56:31

Javaのenumはクラスに近くて、
要素の宣言でコンストラクタに渡すパラメータを指定できる。

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

2010/05/04(火) 23:03:51

>>577
ふーん。ありがとう。

いっそenum class とenum structみたいに2種類にして
機能を分ければよかったのにね。

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

2010/05/04(火) 23:19:42

enumとして正しい値かどうか検査するメンバ関数とか
enum名を文字列で返すメンバ関数とか欲しいわ

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

2010/05/04(火) 23:42:32

>>576
enum class は単に enum をタイプセーフにしただけだけど、Java のはメソッドをもてたり、
各要素毎にオーバーライドして振る舞いも変更できる。

public enum Operation {
    PLUS("+") { double eval(double x, double y) { return x + y; } },
    MINUS("-") { double eval(double x, double y) { return x - y; } },
    TIMES("*") { double eval(double x, double y) { return x * y; } },
    DIVIDE("/") { double eval(double x, double y) { return x / y; } };

    abstract double eval(double x, double y);

    private Operation(String op) {
        op_ = op;
    }

    private String op_;
}

Operation.PLUS.eval(10, 3); // -> 13

これ結構便利だと思う。C++にも同等の機能入れてくれないかな

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

2010/05/04(火) 23:59:20

そこまでするならクラスでいいじゃん、と思う

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

2010/05/05(水) 00:06:13

先生！！メリットがわかりませんん！！

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

2010/05/05(水) 00:10:28

enum class {} というのは指定したクラスのconstインスタンスを名前を
付けて列挙するものという意味付けにすれば後は何でも出来そうな。

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

2010/05/05(水) 00:21:49

Scala の case class の超絶しょぼい版という印象だな > Java の enum

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

2010/05/05(水) 00:22:54

演算子のオーバーロードは今のenumでもできるが

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

2010/05/05(水) 00:28:55

Javaほど機能詰めすぎると逆にイミフなような…

俺がほしかったのは"スコープつきのタイプセーフな列挙子"だし、
機能詰め込んだとしてもC#のenum程度でいいよ

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

2010/05/05(水) 00:39:09

ToStringは欲しかった

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

2010/05/05(水) 00:58:06

boost::lexical_cast

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

2010/05/05(水) 01:10:52

typeidのnameをもっとまともに規定してほしかった。

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

2010/05/05(水) 01:16:59

>>588
それもSTLコンテナの場合、operator<<が定義されてないから使えないんだよな……

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

2010/05/05(水) 01:23:39

自分で定義すれば良いんじゃね？

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

2010/05/05(水) 01:32:26

>>589
ちゃんと読める名前を返すものと、一意性さえあればいいものと、２つ用意して欲しいわ

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

2010/05/05(水) 01:36:48

typeidの名前の文字列をバイナリに含めるか含めないかのオプションが欲しい

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

2010/05/05(水) 15:03:54

ラムダ式を関数ポインタに渡せるようになれば、
システムコールバックが使いやすくなるな
GCなしでどう実装するのか分からないが

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

2010/05/05(水) 15:26:48

また来た

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

2010/05/05(水) 23:30:16

>>578
classとstructの違いはデフォルトのアクセス性しかないのに
enum class とenum structで機能が違うのは紛らわしくね?

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

2010/05/05(水) 23:52:10

template <struct T> がエラーなのと同様、
enum struct は不許可にすべき

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

2010/05/06(木) 00:30:59

>>590
そもそもコンテナの文字列表現なんて一意に決められるものでないから、

template<class Policy, class Container> class container_io_wrapper;
template<class Policy, class Container> container_io_wrapper container_io(Container& c);

std::vector<int> v = { 1, 2, 3, 4 };
std::cout << container_io<EnumPolicy>(v) << std::endl;
// 例えば [1, 2, 3, 4] のように表示される。

みたいなラッパーを自作するだろ普通。

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

2010/05/06(木) 08:37:22

lambdaって関数の引数として渡したい場合はtemplate使うしかないの？
シグネチャが分かっててもダメなんかな。

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

2010/05/06(木) 08:49:07

シグネチャが同じってoperator()のシグネチャが同じなだけで
キャプチャした変数によって型は違うんじゃないの？

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

2010/05/06(木) 08:52:44

>>600
翻訳単位が違えば型も別になるしなぁ。
静的型付けが大前提だし、template使うしかないのか・・・

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

2010/05/06(木) 09:38:55

ていうかlambdaのoperator()ってvirtualになってないのかな?
なってなさそうだなぁ

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

2010/05/06(木) 12:03:19

ラムダ式はalgorithmと組み合わせて使う事がほとんどだろうから
virtualはあまり必要ないんじゃ？

あ、コンテナの中にBase, Derivedへのポインタが入っていた場合に欲しいか

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

2010/05/06(木) 12:09:12

>>603
うん、C++的発想だとそうなるんだけど、つまりシグネチャ決めようがねーよなって話

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

2010/05/06(木) 12:31:36

無理にやったらやったで出来ない事もないだろうが
ただでさえキモいラムダ式がさらにキモくなるな

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

2010/05/06(木) 12:39:01

そういう強引な自己満コードを見たら今後はキモダ式　と呼ぶ事にするｗ

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

2010/05/06(木) 13:53:03

C++0xが入るとBoostはさらにキモさをPowerUpするぜ間違いない

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

2010/05/06(木) 13:57:02

いやな、VS2010で遊んでるんだが、ラムダ式かなり使えるよホント
これでBoost::lambdaはほとんど必要なくなるな

しかし見栄えが汚いな
C#3.0の時に汚いの分かってたろうからもう少し綺麗に見栄えのする
書式にできなかったものかねえ

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

2010/05/06(木) 14:37:53

Cの関数ポインタ自体がきったねぇことを考えると
もうラムダさんの服装は無難で妥当に思えてきたよ

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

2010/05/06(木) 14:53:15

ラムちゃんの衣装は虎模様のビキニ

0611610

2010/05/06(木) 14:54:01

誤爆しました

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

2010/05/06(木) 17:46:38

VS2010のメリットはラムダさんとautoさんとdecltypeさんだけだからな
他のすべての点においてVS2008に劣っている

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

2010/05/06(木) 18:50:40

VS2010は発売後直ちに数多くのバグ報告がされているからSP1は
早めに出るかも知れない

その時にC++0xの時間が無くて入れられなかった機能を入れて欲しい(´･ω･｀)

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

2010/05/06(木) 18:59:36

最初のベータから0xの機能は増えてないんだよな

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

2010/05/06(木) 19:52:03

>>612
rvalue reference の準拠文書が更新されてるってのを
Boost ML で見たような気がする。

0616615

2010/05/06(木) 19:54:16

>>612 じゃなくて >>614 だった。

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

2010/05/06(木) 20:21:29

VC2010は右辺値参照サポートしてライブラリも Move Semantics を実装してるんじゃなかったっけ？

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

2010/05/06(木) 20:22:50

別にC++0xの規格がまだ定まっていない以上、
C++0xに関するバグはどれだけあろうがしょうがないんじゃない？

ただ2010から現在のC++0x機能を除いたら何が残るのか知らんけど。

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

2010/05/06(木) 20:24:22

最早スレチだと思うけど、インテリセンスがマシになったという噂

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

2010/05/06(木) 20:45:35

C++/CLIはインテリセンス自体がなくなった

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

2010/05/06(木) 20:56:45

>>620
なるほど。確かにインテリセンスのバグはなくなったな。

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

2010/05/06(木) 23:08:42

>>608
boost::lambdaはこんなこともできる。
auto m=boost::lambda::_1*2;
auto a=m(3); //戻りはint
auto b=m(1.3); //戻りはdouble

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

2010/05/06(木) 23:31:53

>>617
std::mapとstd::tr1::shared_ptrを使ってみたけど両方共右辺値参照サポートしてるね。

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

2010/05/06(木) 23:34:07

>>619
インテリセンスはよく効くようになってきてるね。
エラーのハイライトの反映が遅いね。処理中は薄くするかステータスバーに表示して欲しいな。

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

2010/05/07(金) 09:02:09

>>622
すげー

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

2010/05/07(金) 13:36:52

>>622
この機能はすごいと思うがさすがに必要ない
関数テンプレートで簡単に実現できちゃうもんな

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

2010/05/07(金) 20:40:14

>>626
ラムダは無名関数を作れるのがメリット

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

2010/05/07(金) 20:55:55

>>627
メリットどころか存在意義じゃね。

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

2010/05/07(金) 21:21:47

それなかったら何のためのラムダっちゃっていう

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

2010/05/07(金) 21:31:17

アウトーーーーーーーーーーーーーーーー！！

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

2010/05/07(金) 21:35:02

>>622
これってテンプレート型変換演算子でもつかってんのかな、と思って
実装を見てみたが正直意味がわからない

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

2010/05/07(金) 21:36:31

>>622
これってテンプレート型変換演算子でもつかってんのかな、と思って
実装を見てみたが正直意味がわからない

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

2010/05/07(金) 21:37:12

まさかの二重投稿……orz

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

2010/05/08(土) 00:13:56

まさかの二重投稿……orz

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

2010/05/08(土) 00:31:26

どうせなら、

まさかの二重投稿……0x

と、こうコンパクトなorzでｗ

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

2010/05/08(土) 00:31:58

0x0 0w0

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

2010/05/08(土) 02:57:47

>>599
シグネチャが分かっているならstd::function<>を使えばいいのではないでしょうか。

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

2010/05/08(土) 11:13:09

lambdaと互換性あるのけ？

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

2010/05/08(土) 11:14:37

なけりゃこれができん。

template < typename T >
void f( T t )
{
t() ;
}

int main()
{
f([]{}) ;
}

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

2010/05/08(土) 11:19:25

>>639
シグネチャが指定したい場合はどう書けばいいの？

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

2010/05/08(土) 11:51:16

>>640
std::functionのコンストラクターは、クラステンプレートの引数を取るんじゃないんだよね。
クラステンプレートのシグネチャで、関数オブジェクトが補足されるんじゃないんだよ。
だから、シグネチャは、知らなくてもいいんだよ。

>>639の例で、
f< void () >( []{} ) ;
とするのは、もちろんエラーだけど、functionの場合、

// primary template、宣言だけで定義されない
template< typename >
class function ;

// すべてのfunctionは、シグネチャに対する部分的特殊化のインスタンスである。
template< typename R, typename... ArgTypes>
class function< R( ArgTypes... ) >
{
public :
// コンストラクター
// type erasureのテクニックを使って、fを保持する。
// シグネチャについては知らなくてよい。
template < typename F >
function( F f ) ;

// operator ()()
// クラステンプレートに指定されたシグネチャで、fを呼び出す。
R operator()(ArgTypes...) const ;
} ;

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

2010/05/08(土) 15:46:56

ん？横やりだからよくわからないけど
>>599 は引数で lambda 関数を渡すときに template 使いたくないって話だよね？

// f は非template関数
void f(std::function</.*なんか*/> &a) {
a();
}

f([]{});

と書けるってこと？

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

2010/05/08(土) 17:29:05

関数ポインタに代入できるようにする提案が出てんじゃなかったっけ？
少しコストはかかるし、ラムダの寿命を越えるとダングリングポインタになるけど、
実装可能ではあるよ

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

2010/05/08(土) 19:15:31

>>642
それはできない。prvalueは非constな参照では受けられない。
まあ、単なる間違いだろうけど。

void f( std::function<void ()> const & a ) ;

あるいは、f()を以下のように呼び出すか。

std::function<void ()> a = []{} ;
f(a) ;

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

2010/05/08(土) 19:17:40

結局>>641が何を言いたかったのかよくわからないです

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

2010/05/08(土) 22:26:34

>>644
ほー、そんな書き方ができるのか
便利だな

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

2010/05/09(日) 08:33:58

属性って採用されるんだろうか
あまりにも文法キモいんだけど

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

2010/05/09(日) 08:43:41

typedef int aligned_int __attribute__((aligned(128)));
こういう文法を使いつづけるほうが良いと？

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

2010/05/09(日) 08:48:49

#pragma みたいに、どんなのを用意するか処理系次第ってんならいいんだけど、
規格で属性を提供されてもね
そういうのはキーワードにして欲しい

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

2010/05/09(日) 09:14:02

その気持ちはわからなくもない

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

2010/05/09(日) 10:40:44

overrideのような文法上意味があるものはキーワードのして欲しいな。

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

2010/05/09(日) 10:44:05

overrideとかfinalとかalignとか
キーワードでいいじゃんと思う
キーワード増やしたくないのは分からなくはないが

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

2010/05/09(日) 11:16:14

>>648
属性でそれがすっきりになるのか？

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

2010/05/09(日) 11:29:39

記述が変わるだけだな

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

2010/05/09(日) 11:54:10

迷い猫Ｏｖｅｒｒｉｄｅ

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

2010/05/09(日) 11:58:17

auto はっぴぃ = new にゃあ();

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

2010/05/09(日) 11:59:45

オーバーロード
オーバーライド
オーバードライブ
オーバーフロー
アンダースコート
の違いがわかりません

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

2010/05/09(日) 12:00:55

[[align]]はC1Xとの互換のためにalignas復活させろって提案が出てるね

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

2010/05/09(日) 12:05:36

>>656
識別子に日本語使いたいなあ、C#が羨ましい

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

2010/05/09(日) 12:12:02

vc++で使えるじゃん

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

2010/05/09(日) 12:16:08

識別子に日本語使ってる人とは仕事したくねえな…

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

2010/05/09(日) 12:16:43

C1XはC++0x以上に普及しないと思うがなあ
alignas復活するのならどうでもいいけど

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

2010/05/09(日) 12:17:09

>>660
class にゃあ
{

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

2010/05/09(日) 12:18:20

日本語識別子はタイピングコストは高いわ
誤字見つけにくい場合があるわで最悪だ

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

2010/05/09(日) 12:18:51

なんだって！

class にゃあ
{};

VS10マジで使えるよ。これは活用せねば。
c++0x構文がでふぉでイネーブルとかvs10気が利いてるなあ。

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

2010/05/09(日) 12:20:23

>>661
C#で漢字使えるから活用しようと提案したら、0.1秒で却下された。

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

2010/05/09(日) 12:22:57

0.1秒も検討してくれたのか、凄いな

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

2010/05/09(日) 12:24:01

コンパイル通らないと思ったら字体が違ってた

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

2010/05/09(日) 12:24:39

神経の伝達速度を考慮に入れよ

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

2010/05/09(日) 12:26:13

提案を最後まで述べる前に却下すればいい

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

2010/05/09(日) 12:26:56

ようギルバート

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

2010/05/09(日) 12:27:32

class 二ダ一 { ... };

ニダーウり;

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

2010/05/09(日) 12:28:58

日本語みたいな入力が面倒くさい言語で
プログラムなんか書いてらんない

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

2010/05/09(日) 12:29:56

現時点でC++0x使ってるプロジェクトって何かある？

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

2010/05/09(日) 12:35:57

流石に気が早すぎるだろ

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

2010/05/09(日) 13:06:12

帳票の名前とかGUIのボタンの名前とか法律用語とか、日本語の方が分かりやすいものは使ったらいい。
送り仮名などの表記揺れは困るので、無理に ASCII 外の文字を使う必要はない。

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

2010/05/09(日) 13:10:49

ボタンの名前とかころころ変わるし
無理に同じにしなくても

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

2010/05/09(日) 13:25:14

>>661
＞識別子に日本語使ってる人とは仕事したくねえな…

class おまんこ {
public:
　void insert(Foo f);
};

ｺﾞｸﾘ・・・

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

2010/05/09(日) 13:29:48

void おまんこ::insert(Foo f)
{
if (f.resNo() == 678) { cout << "うんこを突っ込まれた方がまし"; abort(); }
}

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

2010/05/09(日) 13:32:10

flushすらしないでabortとか

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

2010/05/09(日) 13:33:03

心の声ってやつだな

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

2010/05/09(日) 13:46:51

>>676
COBOLの二の舞になるぜ。
あれはローマ字だけど。

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

2010/05/09(日) 13:48:32

そうか。ログに残さずソフトに本音を出させたい時にはこうするのか。

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

2010/05/09(日) 14:00:46

バッファリング無効になってたらどうすんだ

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

2010/05/09(日) 14:01:24

心の声だだ漏れってやつだな

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

2010/05/09(日) 14:18:55

VC10はデフォルトムーブコンストラクタには未対応なのかな？

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

2010/05/09(日) 15:44:39

先月のドラフトで導入されたばっかだしさすがに無理だろ

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

2010/05/09(日) 15:45:56

assert(false);
と
abort();
って、効力的には同じでしょうか。
両方ともデバッグビルドで有効で、リリースビルドで消えますか？

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

2010/05/09(日) 15:48:11

abort()がリリースで勝手に消えたら怖いよ

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

2010/05/09(日) 15:54:07

あ、ではabort()は消えないんですか。
知りませんでした。
ありがとうございます。

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

2010/05/09(日) 15:58:40

assertの引数の式はreleaseでは評価されないので正解だった？

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

2010/05/09(日) 16:00:16

なぜ消えると思ったのかそっちの方が知りたい

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

2010/05/09(日) 16:00:26

正確にはNDEBUGマクロが定義されている状態でcassertをインクルードしたら
assertの引数の式が評価されなくなる、が正解

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

2010/05/09(日) 16:01:08

assertとabortが似てるからじゃね
字面が

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

2010/05/09(日) 16:07:03

いろいろごっちゃになってました。
失礼しました。
しかもNDEBUGマクロとか初めて知りました。
確かにISOの規格書をNDEBUGで検索するとはっきり書いてありました。

済みません。

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

2010/05/09(日) 16:22:20

assertの引数に副作用のある式を書いてハマるとか

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

2010/05/09(日) 17:59:41

可変個テンプレート引数で侵入式のスマポが作りやすくなったとか
そういう話は無いの

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

2010/05/09(日) 18:14:01

>>697
可変個テンプレート引数は変態御用達なだけでしょうな。

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

2010/05/09(日) 18:16:04

>>697
可変個テンプレート引数は変態御用達なだけでしょうな。

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

2010/05/09(日) 18:18:09

そんなに重要な事なのか

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

2010/05/09(日) 18:20:53

引数の数が違うだけのテンプレートを何個も定義する方がよっぽど…

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

2010/05/09(日) 18:34:33

未だに可変個テンプレート引数をどう活用するのか分からない俺が居る。

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

2010/05/09(日) 18:36:04

未だに可変個テンプレート引数をどう活用するのか分からない俺が居る。

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

2010/05/09(日) 18:41:52

template <typename T> class intrusive_ptr {
public:
　template <typename P...> void alloc(const P&... values) { m_pair = new Pair(values...); }
　T* operator->() { return m_pair == nullptr ? nullptr : &m_pair->obj; }
　T& operator*() { assert(m_pair != nullptr); return m_pair->obj; }

private:
　struct Pair {
　　T obj;
　　int cnt;
　　template <typename P...>
　　Pair(const P&... values) : obj(values...), cnt(1) { }
　};
　std::unique_ptr<Pair> m_pair;
};

カウントする部分は今はどうでもいいから書かないけど
こういう事はできるのかい？

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

2010/05/09(日) 18:55:44

できるよ
コンストラクタへの引数丸投げなら標準がやってる
std::make_sharedとか

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

2010/05/09(日) 18:58:26

それでもboost::intrusive_ptrが規格に入らなかったのには何かあるのかな

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

2010/05/09(日) 19:01:11

>>706
その前にregexが採用されてxpressiveが採用されないとか,
boost::scoped_ptrが何故採用されないのかとか
結構言いたい事はあるよな。

やっぱ歴史が足りないんじゃないの？

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

2010/05/09(日) 19:03:28

>>704 だと weak_ptr が実装できない（たぶん）ので、ちょっとした相互参照でどうしようもない
メモリリークになってしまう。

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

2010/05/09(日) 19:07:39

scoped_ptrがないのはunique_ptrがあるからじゃない
つか名前変えただけというか
xpressiveは技巧的すぎたのかねえ

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

2010/05/09(日) 19:10:00

intrusive_ptrからweak_ptrは元々作れなかったかと

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

2010/05/09(日) 19:10:19

C++0x は、というか C++ 標準化委員会の連中は
C++ に Template metaprogramming を補強する
新しい機構をどんどん導入しているわりには、
Template metaprogramming で書かれた boost ライブラリを
採用しようとしない様な気がする。

特に xpressive, それ以外にも・・・ねぇ。

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

2010/05/09(日) 19:14:34

>>706
intrusive_ptrはshared_ptrに対してメリットが少ないし、共有系が複数あると面倒だからじゃないか。

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

2010/05/09(日) 19:15:07

>>711 妄想は頭の中だけで済ませとけよ。

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

2010/05/09(日) 19:16:44

他の言語もしくはC++自身の別実行レベルでメタプログラミングしたい

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

2010/05/09(日) 19:16:53

valarrayみたいなものもあるんだし
少々あってもいいじゃん

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

2010/05/09(日) 19:54:24

>>711
テンプレートメタプログラミングは標準にするには敷居が高いでしょう。
enable_ifぐらいなら単純デメリットも多いとは思うよ。

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

2010/05/09(日) 19:55:37

>>716
×単純デメリットも
○単純でメリットも

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

2010/05/09(日) 19:57:40

いや、メタプログラミング関連は山ほど追加されてるんだが。何言ってるんだお前ら。
20.7 Metaprogramming and type traits

0719711

2010/05/09(日) 20:17:05

俺も一応そう申し上げているんだけどね。

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

2010/05/09(日) 21:05:32

テンプレートプログラミングと、テンプレートメタプログラミングの境目ってどこ？

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

2010/05/09(日) 21:07:19

主な処理を実行ファイルがするかコンパイラがするか

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

2010/05/09(日) 21:11:45

>>720
> テンプレートプログラミングと、テンプレートメタプログラミングの境目ってどこ？
前者が本来想定されていた使い方で、
後者は仕様の隙間を付いた本来は想定されていない使用法。

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

2010/05/09(日) 21:20:52

>>720
プログラムの動作に対するプログラミングか、プログラムコードに対するプログラミングかの違い。

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

2010/05/09(日) 21:22:31

テンプレートメタプログラミングは
コンパイル時に動作するプログラムのようなものと考えれば良い

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

2010/05/09(日) 21:24:13

テンプレートメタプログラミングはチューリング完全ですか?

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

2010/05/09(日) 21:25:32

>>725
一定の制限があるがそれを忘れていいなら
チューリング完全であることは証明されている。

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

2010/05/09(日) 22:22:20

というか、再帰回数に問題がある点を除けば、関数型言語だよな

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

2010/05/09(日) 22:23:27

ある程度はconstexprで置き換わるのかな

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

2010/05/09(日) 23:24:44

>>727
上限がないと本当にコンパイラが停止問題を解かなければならなくなるから
制限が付いてる

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

2010/05/09(日) 23:52:27

>>729
そういう理由なの？
最低限アテにしていい回数を保証するためじゃなくて？

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

2010/05/09(日) 23:52:57

案外その条件が厳しいんだよね。
確かそういう制限一覧ってのがあったな。

Recursively nested template instantiations [17].
うわぁ、もうちょっと頑張ろうよ。
せめて255とか、現実的に問題になりにくそうな数字にすれば
良いのになぁ。

ISO/IEC 14882:1998(E) -- C++ -- Implementation quantities
ttp://www.kuzbass.ru/docs/isocpp/limits.html

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

2010/05/09(日) 23:54:52

>>730
> 最低限アテにしていい回数を保証するためじゃなくて？
それもある。
というか2つの側面がある。

17と定める事により、コンパイラ実装者は17までで作ればよくなるし、
ユーザーも17まではネストできると信じて作れる。

規格とはユーザーとコンパイラ実装者の間の決まり事だから。

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

2010/05/09(日) 23:58:49

>>731
最新のドラフトでは超パワーアップされてるよ。
> Recursively nested template instantiations [1024].

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

2010/05/10(月) 00:06:19

コンパイラ作者泣かせだなw

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

2010/05/10(月) 00:08:21

C++コンパイラ実装者は実質４つのコンパイラを作成する必要がある。
C++、プリプロセッサ、テンプレート、アセンブラ。

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

2010/05/10(月) 00:16:39

s/コンパイラ/トランスレータ/

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

2010/05/10(月) 00:34:46

プリミティブ値の国境付近に近づくのは愚行と喚き散らす奴が
テンプレートの事に成ると平気で越境してあーだこーだと不満言い出すのはナゼ？

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

2010/05/10(月) 00:38:39

17回の再帰でも、コンパイルがまともな時間では終わらなくなるサンプルがあったな

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

2010/05/10(月) 00:39:03

>>737 もう少しわかりやすくたのむ。

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

2010/05/10(月) 08:35:15

>>737 多分両者は別人だと思う

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

2010/05/10(月) 10:23:55

ところで C++0x の規格で、日本発の提案ってあるの？

重箱の隅をつつくような議論しか目に付かないのだけど

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

2010/05/10(月) 11:23:23

日本人はケチを付けるしか能がないから

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

2010/05/10(月) 11:53:59

C++0xに準拠したコンパイラが楽しみですね..＾－＾..

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

2010/05/10(月) 11:55:31

>>741
俺ってこんなに頭がいいんだぜ、ということをアピールしたいだけなので、
「言う側」にだけなれて、決して「言われる側」になることのない場所からしかモノ言いません。

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

2010/05/10(月) 12:00:35

動く人は誰にも何も言わず黙々と自分の道歩いちゃうので目立たないとも言う
そしてそういう人は逆に協調性が無いので他人との共有に無関心だったりする

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

2010/05/10(月) 12:33:52

Defect reportならたまに日本人ぽい名前も見るな。

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

2010/05/10(月) 13:44:10

>>742, >>744
そんなに日本人の足を引っ張るようなこと言わんでも…
まさに日本人の敵は日本人だなw

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

2010/05/10(月) 15:11:32

自虐民族乙

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

2010/05/10(月) 20:55:25

だって日本NBのコメント見てみろよ
イギリスやドイツと比べてみろよ本当にひどいから
クレクレと重箱の隅つつきばかりで建設的なコメントが一つもない

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

2010/05/10(月) 21:04:23

で、そいつが錦の御旗なの？
背中から撃ち続ける気満々だねえw

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

2010/05/10(月) 22:53:02

と、こういう場所では上から目線全開で食い下がる。
でも肝心な場所では子リスのように震えているだけ。

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

2010/05/10(月) 22:57:03

どうでもいいけど0xは余計コンパイラ開発者側に優しくなくなったのはどうにかならんのか。

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

2010/05/10(月) 23:30:26

どうでもいい

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

2010/05/10(月) 23:30:57

どうでもいいことでしたねすみません。

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

2010/05/10(月) 23:42:12

>>749
じゃあ、自分でNBコメント出したり、アドホック会議行ってこいよ。

NBコメント：ttp://cpplover.blogspot.com/2010/04/cfcdnb.html
アドホック会議：ttp://homepage1.nifty.com/herumi/prog/cppwg.html

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

2010/05/10(月) 23:43:15

>>755
面白そうだな。これ傍聴とかできるの？

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

2010/05/10(月) 23:52:03

>>657
> オーバーロード
過剰に流しこむ→元の加えて、他のが増える

> オーバーライド
上にかぶせる→元のが見えなくなる

> オーバードライブ
過剰に駆動する→元以上に頑張らせる

> オーバーフロー
超えて流れる→溢れる

> アンダースコート
エロス

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

2010/05/11(火) 00:10:14

>>756
去年、CDがでたときにも、まったく同じことをやっていた。
ただ、もうFCDなんで、クレクレはできないよ。
typoとか矛盾点の指摘とか、重箱の隅をほじくるようなことしかできない。

アドホック会議は、こうして一般から集まったコメントに対して、議論して、
日本を代表して出すコメントを決定する。

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

2010/05/11(火) 03:52:56

基本となる仕様の、重箱の隅をつつくことは悪いことではないが。

それとは別に、何か新しい言語仕様/仕様拡張に貢献した例とかはないのかね？
という疑問でした。

秀才さんたちには、新しい物を作るのは不得手なんだなぁということでしょうね

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

2010/05/11(火) 04:06:19

ものを作る秀才はどうなのよ。
秀才を「調べるのに手一杯でどうにもならない駄目人間」だと勘違いしてないか？

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

2010/05/11(火) 04:18:09

新しい言語仕様を提案するのはほとんど政治力の問題であって
問題点の洗い直しこそ開発者・言語研究者としての能力を要する点なのだが

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

2010/05/11(火) 04:25:46

あら、触れちゃいけない点に触ったかな？

>問題点の洗い直しこそ
じゃそういった研究はやっているんですね？
けど、問題点を解決する提案は出せない。ということですかね？

政治的というより、コンパイラ作成に携わっている人が（ほとんど）いないことが原因でしょうね

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

2010/05/11(火) 04:29:45

>>762
>けど、問題点を解決する提案は出せない。ということですかね？
出てるが、出てることが理解できないというですかね？

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

2010/05/11(火) 05:06:17

秀才がどうとか言ってる奴はただのルサンチマンだろ

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

2010/05/11(火) 05:32:18

でてるんだぁ。
けどドラフトペーパーに日本人の名前あったけ？

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

2010/05/11(火) 08:41:09

美少女中学生がドラフト出すようにならないかなあ
そしたらがんばって実装するのに

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

2010/05/11(火) 08:53:12

中学生「かわいくないし意味わからないから、ラムダ廃止にして！」
グラマー「え！？」

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

2010/05/11(火) 11:09:25

>>759
秀才ごときがどれだけ束になっても759の足元にも及ばないと豪語しているわけですね。

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

2010/05/11(火) 11:25:37

結局、日本からの貢献は無い。ということですか。
中国はあるのにねぇ
国力の差か。

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

2010/05/11(火) 11:31:42

各個人にオープンな貢献の場が与えられているのに国のくくりでものを考える意味がわからない。

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

2010/05/11(火) 11:37:17

C++0x自体多くの人には不要だから仕方が無い

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

2010/05/11(火) 11:54:47

C++0xのキラーアプリケーションって何かな

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

2010/05/11(火) 12:06:07

>新しい言語仕様を提案するのはほとんど政治力の問題であって
なんだから、仕様提案ができないのは、政治的発言力が無い証拠だよなぁ。

大学で gcc の派生コンパイラとかまではザラにあるけど、
まともな提案を作って、働きかけて、物にすることができる人はいない。
レポート出したらそれっきりだしね。

某 ML のオフ会でも、たまにこの話題が出てくるけど、何もできないね。でオチついて終わり。

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

2010/05/11(火) 12:31:05

C++0x で次世代のコンパイラを開発しよう。

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

2010/05/11(火) 15:47:48

>>773
仕様提案といえばEmbedded C++があるじゃないか。
これがトラウマになって今の状況を招いたのだったりして。

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

2010/05/11(火) 19:28:07

Embedded C++0xでリベンジを

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

2010/05/11(火) 19:39:11

Embedded C++0x.

decltypeは、難しすぎて俺らには実装できないし、そもそも新しすぎて俺らには使いこなせないので却下。
autoは、難しすぎて俺らには実装できないし、そもそも新しすぎて俺らには使いこなせないので却下。
Variadic Templateは（ｒｙ
lambdaは（ｒｙ
scoped enumは（ｒｙ

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

2010/05/11(火) 21:16:44

こうしてalignofと[[align]]だけが残った

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

2010/05/11(火) 21:39:10

>>777
ようやく普通のテンプレートが入るならそれでもいいけどなｗ

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

2010/05/11(火) 22:03:49

テンプレートはコードが膨張するので
Javaのgenericsみたいなのが入ります

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

2010/05/11(火) 23:24:40

そこで明示的なインスタンス化ですよ

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

2010/05/11(火) 23:39:32

>>778
alignas でいいじゃないですかぁ

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

2010/05/11(火) 23:56:15

>>780
JAVAのげねりっくの正体はキャストって聞いたけど本当？

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

2010/05/12(水) 00:01:31

むしろJAVAのCASTがGENERIC

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

2010/05/12(水) 00:06:42

>>782
そこは戻ることに気付かずにC++0xともC1Xとも互換性失った方がEC++らしい

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

2010/05/12(水) 00:13:54

互換性といえば、>>1の一番上のサイトのSC22→WG14でCの委員会サイトに
行けるんだけど、あっちもあっちでC++0xとの同期を意識しているんだよな。

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

2010/05/12(水) 00:16:20

そりゃC++98とC99の時みたいな間抜けなこと繰り返したくないでしょ
お互いに

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

2010/05/12(水) 02:10:05

「Cに」GCとクロージャを提案してるアホもいるけどな

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

2010/05/12(水) 02:53:57

>>788
GCはともかくクロージャは並列プログラム等いろんな所で有用だし、
既にAppleは実現させてるでしょ。
http://blog.8-p.info/2009/09/gcd-1

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

2010/05/12(水) 03:10:05

>>789
Apple拡張のクロージャは「GCはともかく」というよりGCありきでしょ
というかクロージャなんてオブジェクト機構を伴うことが前提なんだから
明らかに「Cのカバー範囲」を逸脱しまくってるだろ
ObjCがアレだからCのレイヤに二重実装してケツ拭かせますと言っているに等しい

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

2010/05/12(水) 07:09:59

MacOSXは10.5からObjective-CにGC入ったけど
もしかしてOS自体がGCサポートしてんの？

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

2010/05/12(水) 07:31:47

Apple 用の CPU は、アセンブラレベルで GC をサポートしているんですよ > 791

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

2010/05/12(水) 07:33:53

Apple用てWindows用と変わらんで

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

2010/05/12(水) 07:42:32

>>792
ちょｗ何を言い出すんだｗ

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

2010/05/12(水) 13:39:41

Appleのブロック構文はGC使わず、参照カウンタでも動くけどな。
ブロック自体にretain,releseかますし。

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

2010/05/12(水) 13:49:21

つーかなぜにAppleはクロージャをCに入れようとしたんだろう
構造体とフル機能のクロージャがあればそれだけでオブジェクト指向言語になってしまうので
「Cの」拡張としては恐ろしく筋が悪いものに感じる
インラインで「関数が」書ける機能ならCらしくて分かるんだが……

そもそもObjective-Cの拡張としなかった理由がよく分からんなぁ
どっかで「Cの拡張ならBSDカーネルに取り込める」とか強弁してた奴がいるけど
Cの「独自」拡張を使ってカーネル書くくらいならまだObjective-Cでカーネル書いた方がマシだろうと

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

2010/05/12(水) 13:59:24

Obj-C (.m) だけで使えるより C でも使えた方が単純に考えてお得じゃない？

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

2010/05/12(水) 14:10:14

ECMAScriptにclassを独自拡張した某言語に胸熱になったのを思い出す

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

2010/05/12(水) 14:13:42

あ、いいこと思いついた。
C++0xの機能を全部C1xにバックポートすれば、超便利な機能がCでも使えて単純に考えてお得じゃない？

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

2010/05/12(水) 18:29:28

おまえてんさいだな

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

2010/05/12(水) 19:14:16

Obj-C用に実装したけど
Cでも使える構文になったから
Cでも使えるようにしちゃえ

でしょ。どうせ

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

2010/05/12(水) 19:31:30

>>801
AppleクロージャはObj-CのオブジェクトじゃないからObj-C用に設計したものではないよ
Obj-C用に設計しようとしたがあまりにパフォーマンスが悪くてObj-Cと切り離さざるを得なくなった
という方が実態に近いと思う
でもオブジェクト機構と乖離したクロージャって物凄くいびつだと思うんだが
ああいうのって世間の言語設計者的にはOKなんだろうかね

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

2010/05/12(水) 21:21:06

>>801
Obj-C で完結する部分には元々のブロックで充分じゃない？

>>802
逆じゃない？
オブジェクトは貧者のクロージャで、環境を文脈として保持するのが本来のクロージャでしょ。
だから Obj-C の blocks も微妙じゃないかな。

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

2010/05/12(水) 21:44:54

>>803
環境だってデータなんだから、クロージャはデータを持った手続きであって
つまり表面上、データが主で手続きが従か、手続きが主でデータが従か、の違いだけで
クロージャはオブジェクトの一種というか表と裏のような概念。
実際オブジェクト指向言語におけるクロージャはそういう概念で設計・実装されてる。
Javaの無名Runnableなんかは明らかにオブジェクト寄りのクロージャで中間概念として分かりやすいんじゃないかな。

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

2010/05/12(水) 22:31:20

頭に isa 付けてりゃObj-Cのオブジェクトになる訳で。

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

2010/05/12(水) 22:43:13

>>805
そういう問題じゃないだろｗ

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

2010/05/12(水) 23:10:30

GCDに必要で、Block導入したんだっけ？
BSDがLLVM-Clang移行したらGCDも導入されるのかな。
ttp://developer.apple.com/mac/articles/cocoa/introblocksgcd.html
ttp://developer.apple.com/snowleopard/library/documentation/Cocoa/Conceptual/Blocks/Articles/00_Introduction.html
ttp://clang.llvm.org/docs/LanguageExtensions.html#blocks

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

2010/05/13(木) 11:07:36

必要っちゃ必要なのかなぁ
ぶっちゃけGCDはjava.util.concurrentの簡易版みたいなものだから
クロージャ無いと無理というわけではないと思われ

BSDがカーネル内でBlocks使うって噂もあるけど
独自拡張使ってカーネル書くのは正直それってどうなのって気はするな。

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

2010/05/13(木) 20:46:43

カーネルこそコンパイラの独自仕様に頼らざるを得ないだろ
LinuxカーネルなんてGCCに依存どころかほとんど癒着してるぞ

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

2010/05/13(木) 20:56:51

そりゃLinuxのお行儀悪さの発露であって。
処理系依存なコードは必要最小限に抑えるのがまともな実装。

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

2010/05/13(木) 21:27:06

>>810
頭の中に花畑があるようですね

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

2010/05/13(木) 22:10:34

あれ、LinuxってGCC独自拡張の文法とか使ってるんだっけ?

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

2010/05/13(木) 22:36:16

丁度良さげなのがあったので貼っておく
http://www.ibm.com/developerworks/jp/linux/library/l-gcc-hacks/

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

2010/05/13(木) 22:48:08

>>813
全体的に代替マクロで潰せるものが多いね
範囲caseとゼロ長配列は冗長だけど標準で書けるんだから標準で書けとは思った

ロジック的に完全にGCCに依存してそうなのは定数判定かな

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

2010/05/13(木) 23:19:26

>>814
> 全体的に代替マクロで潰せるものが多いね

どうやって？　どれ一つとしてマクロで出来る様には思えなかったけど。

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

2010/05/13(木) 23:29:38

>>814
御託はいいから置き換えて晒してみろよ

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

2010/05/13(木) 23:51:16

まさか・・・　ExcelにおけるVBAのような脳内マクロをイメージした発言では・・・・ｗｗ

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

2010/05/14(金) 00:02:23

マクロで「潰す」と言ってるんだが
最適化ヒントは全部空文字列と置換可能だろ

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

2010/05/14(金) 00:21:01

・型検出
　この機能自体は大抵のコンパイラでマクロ使ってエミュレート可能かな
・範囲拡張・ゼロ長の配列
　gcc拡張使えば楽になるのは分かるけど、こらえてベタ書き汁
・呼び出しアドレスの判断
　スタック辿れば可能だが、こんな情報は引数で渡すべきじゃないのか
・定数検出
　これは専用の文法ないと厳しいかな
　全部定数でないと見なして最適化を諦めることは可能だけどパフォーマンスすごく悪そう
・関数属性
　各コンパイラごとに存在するならそれに置換、無ければ空にすればいいだけ
　よくある話
・最適化に関する拡張機能
　上に同じ

下2つはVC/GCC両対応コード書く時とかマクロで切り替えるの常套手段だと思うんだけど
>>815がなぜ「マクロで出来るように思えなかった」のかがむしろわからんなぁ

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

2010/05/14(金) 03:03:13

無理矢理スレの趣旨に戻すと
Blocksさんに比べれば我らがラムダさんの制服の柄は許容範囲
という認識でよろしいか

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

2010/05/14(金) 07:38:12

Blocks サイコー

__block int (^F)(int);
F = ^(int n) {
if (n == 0) return 1;
else return n * F(n-1);
};

NSLog(@"%d", F(5));

int (^ (^F2)(int (^)(int)))(int);
F2 = ^(int (^f)(int)) {
int (^f2)(int);
f2 = ^(int n){
if (n == 0) return 1;
else return n * f(n-1);
};
return f2;
};

NSLog(@"%d", F2(F)(5));

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

2010/05/14(金) 13:26:43

>>804
Scheme や Smalltalk や ECMAScript などのクロージャが物凄くいびつだと。

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

2010/05/14(金) 13:34:09

>>819
お前が夢ばかり見てるオバカさんだってのはよくわかった

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

2010/05/14(金) 13:49:32

>>822
その辺はむしろクロージャこそがオブジェクト機構の主体なんだから一貫してるよ
ECMAScriptにclassを更に足してしまったActionScriptはいびつと言っていいと思う
Blocksは「Cを単体でECMAScriptのような言語にする」機構なので
Objective-Cとして使われることを前提とした拡張だとむしろActionScript状態に近い

0825デフォルトの名無しさん

2010/05/14(金) 14:04:14

具体的に全く反論できないのでレッテル貼りしかできないのですねわかります

0826デフォルトの名無しさん

2010/05/14(金) 14:12:04

>>825
え、どの辺が具体的じゃない？
ScmemeやECMAScriptはクロージャ機構からオブジェクト機構が導出されている
C++とかJavaとかRubyとかはオブジェクト機構があってそこからクロージャが導出されている
Objective-C with Blocksは、Blocksというクロージャ機構があり、かつそれと直交したオブジェクト機構を持つ
そんなに難しいことではないと思うけど、分かりにくいとこある？

0827デフォルトの名無しさん

2010/05/14(金) 14:14:28

>>826 >>825 は >>823 に対してだと思われ

0828デフォルトの名無しさん

2010/05/14(金) 14:20:24

>>826 が何気に他人の反応気にしてるのがわかったｗ

0829デフォルトの名無しさん

2010/05/14(金) 14:24:47

>>828
いやめっちゃ分かりやすく書いたつもりだったので衝撃を受けただけ
>>827ってことなら気にせんでくれ

0830デフォルトの名無しさん

2010/05/14(金) 15:06:20

>>819
スタック辿ればとか言ってる時点で処理系依存しまくり
引数とかいうがプログラムカウンタをアーキテクチャ依存無しで取ってみろ

0831デフォルトの名無しさん

2010/05/14(金) 15:18:56

似たものが直行する概念として実装されているのがどうしていびつなのか
具体性に欠ける

0832デフォルトの名無しさん

2010/05/14(金) 15:28:52

直交の意味から説明しないといけないほどのバカが一人で暴れてる模様

0833デフォルトの名無しさん

2010/05/14(金) 15:53:59

>>824
Smalltalk は違うよ。
というか、クロージャでできることは全てオブジェクトでできるけど、クロージャを欲しがる理由はオブジェクトとは関係ない。
そして ECMAScript 的なクロージャは元々あるブロックを使えばいい。

0834デフォルトの名無しさん

2010/05/14(金) 16:24:34

>>833
smalltalkはRubyと同じで、というか由来的には逆だけど
ブロックはオブジェクト機構の枠内にいるよ
ブロックとオブジェクト機構が直交した独立の存在にはなってない

0835デフォルトの名無しさん

2010/05/14(金) 17:26:43

Rubyの場合は、ブロックを表現するProcというクラスもあるけど、
それがブロックそのものではなく、オブジェクトにはなってない。

0836デフォルトの名無しさん

2010/05/14(金) 18:02:23

>>835
Procはオブジェクトだぞ
ちょうどC++0xのlambdaで返るfunctionと同じ立ち位置

0837デフォルトの名無しさん

2010/05/14(金) 18:09:11

誰かC++学園的に各言語のクロージャ、ブロックを例えてくれよ。
話しについて行けない。

0838デフォルトの名無しさん

2010/05/14(金) 18:20:25

>>836
Procはオブジェクトなんだけど、ブロックがすなわちProcではない。

def foo &c で、ブロックを変数に入れるか、引数なしで Proc.new を呼ぶと、
ブロックからProcのインスタンスが作られる。

0839デフォルトの名無しさん

2010/05/14(金) 18:27:17

>>838
今君の言ってるところの「ブロック」って「構文木」のこと?
普通ブロックとかクロージャとか言う時は、
キャプチャされたローカル変数とコードの組み合わせのことであって、
構文木のことは指さないんじゃない?

0840デフォルトの名無しさん

2010/05/14(金) 18:32:53

>>839

def foo
　yield
end

def bar &c
　c.call
end

foo{p "foo"}
bar{p "bar"}

これを実行した時、p "foo"に相当する「キャプチャされたローカル変数とコードの組み合わせ」は、
Ruby処理系内部のデータ構造としてしか存在していない。
p "bar"のほうはProcのインスタンスが作られる。

0841デフォルトの名無しさん

2010/05/14(金) 18:39:11

>>840
それは論理的にはProcインスタンスが匿名かどうかの問題でしかないぞ

0842デフォルトの名無しさん

2010/05/14(金) 19:10:34

これまで出てきている「ブロック」というのは、もともとはSmalltalkローカルの用語で無名関数のこと。
Smalltalkのブロックは、クロージャーで実装されていることが多い（が、そうでない場合～エンクローズされていない～もある）。
Rubyのブロックや Objective-C の Blocks はこのSmalltalkのブロックから名前を借りたもの。
Rubyのブロックは、ファーストクラスオブジェクトでも Ruby のオブジェクトでもない。(840の言いたいこと）
Rubyのブロックをオブジェクトとして扱えるように用意されたのが Proc クラス。

0843デフォルトの名無しさん

2010/05/14(金) 19:23:12

>>842
んっとね、Rubyのブロック構文は基本的にProc(など)の定義であり
そのProcインスタンスが外部から可視であるかは問題ではない
というのが>>841で言いたかったことね。
この点は言語設計として一貫してるよ。smalltalkも基本的にそうでしょ。
#もちろん最適化の結果、内部でいつの間にかショートカットされてることはあり得る

クロージャというオブジェクトとは直交した全く別の構造があって
Procというインターフェースから間接的にアクセスできる
という論理構造"ではない"

でもApple CのBlocksは当然根本的にObjective-Cのインスタンスではない。
何故ならObjectiveじゃないCの中に存在している概念だから。
逆にBlocksが常にObjective-Cのインスタンスであるなら>>799を地で行くことになる。

0844デフォルトの名無しさん

2010/05/14(金) 19:46:44

実質的にはObjCの拡張であって本気でBlocksをC1Xに提案していく気はないでしょ
あんな__付きまくりなものに仕様的整合で目くじら立ててもしょうがないしスレ違い

0845デフォルトの名無しさん

2010/05/14(金) 20:06:01

実際に存在してないものを「可視か否かの問題」にされたらかなわんわ

0846デフォルトの名無しさん

2010/05/14(金) 20:13:10

>>845
内部的に存在するが外部からアクセス手段がないことを「実際に存在しない」と言うのか

0847デフォルトの名無しさん

2010/05/14(金) 20:17:33

内部的に存在してるものはProcのインスタンスじゃないから。

0848デフォルトの名無しさん

2010/05/14(金) 20:25:09

iostreamとかpimplとか見たら発狂するタイプだな

0849デフォルトの名無しさん

2010/05/14(金) 20:31:03

Apple の Blocks は toll-free だけど、処理の実体は C に投げられてるから、Obj-Cの拡張言うかな？
NSBlock のサブクラス検索したけど、どれも変数持たないし。

0850デフォルトの名無しさん

2010/05/14(金) 20:36:39

>>849
ObjCとは切り離されてると思う。
ObjCのオブジェクトはパフォーマンスが悪すぎて
クロージャを表現するには正直きついので、
同種の機構を二重に実装するダサさは目をつぶってCに入れた、
という認識の方が実態に近いかと。

0851デフォルトの名無しさん

2010/05/14(金) 20:40:36

まあ[hoge retain],copyとかの為だけにObj-C クラスの皮被せただけだろうな。

0852デフォルトの名無しさん

2010/05/14(金) 21:16:03

Obj-Cのオブジェクトってそんなにパフォーマンス悪いの？
クロージャをオブジェクトのシンタックスシュガーとして扱えないほど重いってそれ自体がかなりむごい話に聞こえるんだが・・・

0853デフォルトの名無しさん

2010/05/14(金) 21:30:14

メソッドは関数呼び出しの3倍くらいの速度。

0854デフォルトの名無しさん

2010/05/14(金) 21:30:29

1/3くらい。

0855デフォルトの名無しさん

2010/05/14(金) 22:17:32

IMP呼び出し使ってC++のvirtualくらいの速度じゃなかったっけ?
staticな関数コールと素のmessage sendを比べると10倍どころでは済まないと思う

0856デフォルトの名無しさん

2010/05/16(日) 13:18:17

>>834
ブロックを辞書に格納することはできるけど、ブロックは辞書で表現されてないよ。
[|a|a:=10.[^a] value] の内側のブロックから a を参照することをオブジェクト機構の枠内というのは強弁だと思うよ。

というか直行してるといびつだという理由を教えて欲しい。
コストの安いほうでいいじゃん。

0857デフォルトの名無しさん

2010/05/16(日) 18:09:57

>>856
何故に唐突に辞書が……

0858デフォルトの名無しさん

2010/05/16(日) 18:50:14

素朴な疑問だけどWebKitがC++である以上
Objective-CはObjective-C++として使われるのは不可避なわけで
lambdaをObjective-Cの中に置くことを最初から諦めるなら
最初からC++のlambdaを使えば良かったんじゃないのと思うのは俺だけ？

0859デフォルトの名無しさん

2010/05/16(日) 19:27:11

馬鹿？　ラッパしてある中身が云々とか、使う分には関係ないし。

0860デフォルトの名無しさん

2010/05/17(月) 13:40:22

>>856
論理的に包摂関係にあるものを全く別々の独立した2つの仕様として策定するのは、設計としてはダサいだろ。
一貫した仕様を定義し、最適化の過程で内部実装は切り分けられる、というのが基本。

あくまで原則論なので過去の負の遺産との整合上仕方ないこともあるし、いわんや独自拡張で何やろうと知ったことではないがな。

0861デフォルトの名無しさん

2010/05/17(月) 13:49:48

>>860
論理的に包摂関係にある、というのがさっぱり理解できないんだけど。
バナナで釘が打てるからバナナも金槌に包摂されると主張しているように聞こえる。
俺は、クロージャとオブジェクトは、たまたま一部について同じことができるだけの別物だと思う。

0862デフォルトの名無しさん

2010/05/17(月) 13:55:18

>>861
オブジェクトとクロージャは「たまたま一部について同じことができる」なんてレベルじゃないだろ。
バナナが存在するところにリンゴを追加する際に、果物クラスを作らずリンゴクラスが独立して作られて、バナナとリンゴは違うだろ、と主張しているように聞こえる。
それどころか青リンゴと赤リンゴくらいの関係じゃないか。

0863デフォルトの名無しさん

2010/05/17(月) 17:43:39

>>862
理解できないと言っているのだから説明してよ。
包摂関係とはどういうことかの説明じゃなくて、オブジェクトがクロージャを包摂するということについてね。

860 の「論理的に包摂関係にある」ということは、論理的に説明できるんだよね？
包摂関係にあることの確認を、論理的に行えると考えていいんだよね？

あと、バナナの話は凍らせた時の話で、殺伐としすぎないようにジョークで出したのだけれども、場違いだったようで失礼。
http://www.youtube.com/watch?v=Po_B6SHWUdI

0864デフォルトの名無しさん

2010/05/17(月) 18:06:42

オブジェクトとクロージャは片方がもう一方の全てを満たすことが可能である以上
包摂関係と言うと語弊があると思う
むしろ同じものの表と裏と言った方が概念的には正しい

0865デフォルトの名無しさん

2010/05/17(月) 18:17:58

何だ？　一行目と二行目が……

0866デフォルトの名無しさん

2010/05/17(月) 18:26:59

流れを読まずに書き込むが
オブジェクト⊃クロージャじゃないの？

「オブジェクト」の定義がよくわからんが、どうせ
「データと手続きを一緒にしたもの」ぐらいだろ？
なら、そういう包含関係にならざるを得ないと思う

クロージャはレキシカルスコープと密接に絡んだ概念だから、（より一般的な）
オブジェクトより狭い概念だと思うけど？

0867デフォルトの名無しさん

2010/05/17(月) 18:36:51

>>864
了解した。
その上で、
1) 表と裏であることを示してくれ
2) 表と裏である機能（性質？事象？）を、独立した別々の機構として策定するのがダサい理由を説明してくれ
　　虚数表現とか表色系とか、いろいろあると思うがどうだろう
をお願い。

>>866
クロージャでできることをオブジェクトで行うことはできる。
が、ローカル変数を含めたレキシカルスコープへの参照を束縛するという機能なり概念なりはオブジェクトにはない。
クロージャの概念のほとんどをオブジェクトが持つといっても反対はしないが、全てではない。
クロージャが持ち、オブジェクトが持たない概念が存在する。

ちなみに俺は、同じことができるだけで別モンだと思うけどね。
金属バットとバールのようなものくらい違うと思うよ。

0868デフォルトの名無しさん

2010/05/17(月) 18:39:47

>>867
よくわからんけど、あんたの言う「オブジェクト」の定義って何？
「クラス」の話？

0869デフォルトの名無しさん

2010/05/17(月) 18:42:53

>>866
実際にJavaScriptとかLisp系とかはクロージャでオブジェクトを実現しているよ
理論上は得意不得意の違いだけで扱えるスコープは同じになる

0870869

2010/05/17(月) 18:44:55

補足
　扱えるスコープ→扱える「問題の」スコープ
です
このため、片方が存在すれば、もう片方は単なるシンタックス上のトリックとして扱えます

0871デフォルトの名無しさん

2010/05/17(月) 18:45:45

>>869
あのね、
俺はオブジェクトのほうが広い（曖昧な）概念で
クロージャは、より狭い概念だと言ってるんだよ

出来ることの差なんてそりゃ無いが、概念の広い狭いとは全然関係ない話だろ

0872デフォルトの名無しさん

2010/05/17(月) 18:54:51

>>871
うーん、それはどうだろう
C++的な立場から見るならそれで合ってる
コンピュータ上での実際の動作という意味でもその方が実態に近い
でも関数型的な観点で言えばクロージャの方がよりプリミティブな概念になっちゃうんだよね
だからどっちが広いとか狭いとかいうよりも「表と裏」なのだと思う
多分オブジェクトの方が表なのだろうけど

0873デフォルトの名無しさん

2010/05/17(月) 19:18:21

>>872
んーそれじゃ、あんたの「オブジェクト」の定義は何なの？
俺の定義は>>866でしかないから、紛れも無くクロージャは「オブジェクトの
一種」でしかないんだけど

「オブジェクト」は別にレキシカルスコープと関係なくてもいいし
データは環境でなくてもいい
だからクロージャはより「狭い」

0874872

2010/05/17(月) 19:22:44

>>873
ん、俺の定義も>>866と変わらんよ
…ところで俺は「オブジェクトとクロージャは直交してる」と言い張ってる人とは別人ですよ……？

0875デフォルトの名無しさん

2010/05/17(月) 19:28:19

>>874
あ、そうなの？その定義なら
オブジェクト⊃クロージャ
は自明というか、論理的にそうにしかならんでしょうに

0876デフォルトの名無しさん

2010/05/17(月) 19:34:23

>>875
いや、関数型の世界では手続きは情報を持っていることが当たり前で
オブジェクト的なものはその一種でしかないんだわ
だから君のような考え方はC++の観点では自明なんだけど
一方で関数型の世界では「クロージャの概念がオブジェクトの概念を内包している」ことになる

手続き型と関数型があってどっちが内包するわけじゃなくてどっちもチューリング完全だよねみたいな感じ
実装は通常最終的に手続き型で行われるからマシンレベルで最もプリミティブなのは前者ではあろうけど、と

0877デフォルトの名無しさん

2010/05/17(月) 19:40:02

>>876
いいたいことは分かるが、論理的に全然包含関係の否定になってない気がするが

否定したければ、非オブジェクト的なクロージャが存在することを示すしかないぞ
無いでしょ？
一方、全てのクロージャは>>866の定義なら自動的にオブジェクトだし
それは関数型だろうが変わらんでしょ

0878デフォルトの名無しさん

2010/05/17(月) 19:50:12

ごめん変な書き方になった

全てのクロージャはオブジェクトである
クロージャでないオブジェクトは存在する
ゆえにオブジェクト⊃クロージャである

というのが俺の論理なので、否定したいのなら最初の奴の反例出すしかないんじゃ
ないのって話ね

0879デフォルトの名無しさん

2010/05/17(月) 19:51:43

お前誰よ？

0880デフォルトの名無しさん

2010/05/17(月) 19:52:09

俺は>>866

0881デフォルトの名無しさん

2010/05/17(月) 19:55:45

俺は>>881

0882デフォルトの名無しさん

2010/05/17(月) 20:08:31

>>878
オブジェクト＝クロージャ
なんじゃね？
>どっちが広いとか狭いとかいうよりも「表と裏」
とか書いてるし

>クロージャでないオブジェクトは存在する
を否定する根拠があるかどうかは俺は知らん

0883デフォルトの名無しさん

2010/05/17(月) 20:13:46

>>877
うーん、非オブジェクトなクロージャってのは難しいな
一応逆の観点で見ると
オブジェクトのconstructは引数による明示的な束縛に他ならないし
メソッドの実行もプロパティの読み書きも関数型的には関数(手続き)実行に他ならないから
概念的には逆に全てのオブジェクトもクロージャであることを満たすんだよね

実際クロージャ指向な世界ではそういう扱いをしている
うん、変態的だとは思う

0884デフォルトの名無しさん

2010/05/17(月) 20:29:18

ぶっちゃけお前らが何をいってるのかよくわからん。
クロージャといえば、その場の自由変数をbindできて、Callable(operator()が使える)である必要があると思うが、
Haskellみたいな言語でもすべてのオブジェクトがCallableであるとは限らないだろ。
data Point = Point x y と定義して、Point 1 2とかするとオブジェクトが生成されるが、これはCallableか？

0885デフォルトの名無しさん

2010/05/17(月) 20:30:24

>>883
うーんSchemeあたりでオブジェクトっぽいのを書くときにそうする、というのは
分かるけどねぇ
関数型でない言語にまでその議論を広げるのは無理がない？

レキシカルスコープとクロージャを提供してるけど
クラスも提供してる言語はいくらでもあるし
それらの言語では、クラスオブジェクトとクロージャは別物だから

0886デフォルトの名無しさん

2010/05/17(月) 20:38:16

>>885
クロージャとクラスを提供していて、論理的に全く分断された扱いがされてる言語ってどんなのがある?
ActionScriptがそんな感じになってるんだっけ?

0887デフォルトの名無しさん

2010/05/17(月) 20:50:51

PHP(ゴクリ

0888デフォルトの名無しさん

2010/05/17(月) 21:03:43

>>886
論理的に全く分断って意味がわからんけど
C#とかPythonとかScalaとか、いくらでもないか？

それらの言語のクラスを、普通の意味でのクロージャとは見做せないと思うけど

0889デフォルトの名無しさん

2010/05/17(月) 21:06:04

ああクロージャ＝オブジェクト論では
クラススコープの変数を、レキシカルスコープの自由変数と見做すのか

なんとなく意味は分かったｗ
なるほどね

0890デフォルトの名無しさん

2010/05/17(月) 21:12:48

>>888
その辺の言語はクラス指向で、クロージャは単純にクラス機構の下位に属してるんじゃ？

0891デフォルトの名無しさん

2010/05/17(月) 21:20:13

>>889
ちょうどオブジェクト指向言語でクロージャを表現するのと逆方向だな
レキシカルスコープの束縛はコンストラクタでのインスタンス変数へのコピー・参照
C++0xのlambdaをC++で書こうとするとまさにそうなるｗ

0892デフォルトの名無しさん

2010/05/17(月) 21:21:14

>>890
よくわからない
「クロージャではないオブジェクト」が存在する例がクラス指向の言語だと、
何か問題に影響するの？

0893デフォルトの名無しさん

2010/05/17(月) 21:25:26

>>892
なんの問題の話をしてるのかよく分からんが
ほとんどの言語は
・クラス指向の言語でありクロージャはクラスである(オブジェクト指向言語、多数派)
か
・クロージャ指向の言語でありクラスはクロージャである(一部の関数型言語、少数派)
のどちらかで、クラスとクロージャが「別物」の言語はそうそうないのでは

PHPとかはそうなのかな?

0894デフォルトの名無しさん

2010/05/17(月) 21:33:27

クロージャがクラスとか、クラスがクロージャなんじゃなくて、
クラス機構もクロージャ機構もオブジェクト機構の一部であって、共通する部分もあるってだけなんじゃないかな

0895デフォルトの名無しさん

2010/05/17(月) 21:35:54

>>893
Pythonはオブジェクト指向言語だけど、全ての型がclassかというとそうではない
クロージャの型はfunctionで、functionはファーストクラスオブジェクトだが
classではない

0896デフォルトの名無しさん

2010/05/17(月) 21:40:53

>>889の見立てを行ったときに、クロージャと同じものと見做せるのは
class objectではなく、bound methodだと思う

0897デフォルトの名無しさん

2010/05/17(月) 21:52:44

Perlはクラス指向でもクロージャ指向でもなくて
どっちも持ってる

0898デフォルトの名無しさん

2010/05/17(月) 21:54:03

そろそろスレ違い

0899デフォルトの名無しさん

2010/05/17(月) 21:55:06

つまりラムダさんかわいいよラムダさん、ということでまとめとこうぜ

0900デフォルトの名無しさん

2010/05/17(月) 21:59:12

あんまりそわそわしないで。　あなたはいつでも話脱線しちゃうけど
スレタイ見てよそ見はやめてよ。　ラムダっちゃ。　　ってことでここは一つ

0901デフォルトの名無しさん

2010/05/17(月) 23:03:19

次スレは10だよ派といやAだろう派による
ねっとりした論戦が始まります。

0902デフォルトの名無しさん

2010/05/18(火) 00:57:26

ラムダ、auto、右辺値参照、progress_display
個人的に大いに期待する４大新機能

おまいらどう？

0903デフォルトの名無しさん

2010/05/18(火) 01:05:50

progress_displayたんともあろうお方が…(´;ω;`)ｳｯ

0904デフォルトの名無しさん

2010/05/18(火) 05:33:49

誰もがぱっと恩恵受けられるのはautoだろうね
autoのためにC++0xを使わせて貰える現場があるのかは知らん・・・

0905デフォルトの名無しさん

2010/05/18(火) 06:04:00

>>904
auto は待ち遠しいねえ。　GCC 4.4では使えるが、まだ許されるのはGCC 4.3まで。

0906デフォルトの名無しさん

2010/05/18(火) 20:09:02

昔のautoちゃんはもういないのかな...

0907デフォルトの名無しさん

2010/05/18(火) 20:15:30

○Blocksさん
遠く青森で林檎に囲まれて育ったラムダさんの親戚。帽子が特徴的。

0908デフォルトの名無しさん

2010/05/18(火) 20:26:19

>>904
右辺値参照は標準ライブラリが対応するだけで、ソース書き換えなくても自動的に恩恵が得られる。

0909デフォルトの名無しさん

2010/05/18(火) 21:15:24

vectorにunique_ptrが入るようになるだけでもマジうれしい

0910デフォルトの名無しさん

2010/05/18(火) 21:17:13

>>906
VC10だとオプションで復学可能

0911デフォルトの名無しさん

2010/05/18(火) 21:18:26

>>904
autoとバリアントの区別がつかない人が拒否反応起こして困る。

0912デフォルトの名無しさん

2010/05/18(火) 21:25:45

>>911
昔は「そんなんいねーだろ！」とか思ってたけど、いるみたいだねぇ。
C#の記事で、varとバリアントを混同する人が結構いる、という前提の説明を見たことがある。
当然C++のautoでも出て来るんだろうね・・・。

0913デフォルトの名無しさん

2010/05/18(火) 21:30:32

やべえ、最近書いたコードはautoがずらずら並んでいるが問題ないよね？

0914デフォルトの名無しさん

2010/05/18(火) 21:50:32

auto a = 1;
a = "Hello"; //エラー

「なにこれマジ使えねー」

0915デフォルトの名無しさん

2010/05/18(火) 22:02:40

#define auto_type_affirmation auto

0916デフォルトの名無しさん

2010/05/18(火) 22:55:03

0xオプションつけると
auto int x = 4;
がもう通らない。

完全に別人やな。

0917デフォルトの名無しさん

2010/05/18(火) 23:14:54

auto<int>とかfoo<auto>みたいな文法が
採用される夢を見た

0918デフォルトの名無しさん

2010/05/18(火) 23:22:57

auto<auto>

胸が熱くなるな

0919デフォルトの名無しさん

2010/05/18(火) 23:31:54

>>918
テンプレート引数を取る識別子は型そのものではないのだからautoでそれを示すのは不可能なんじゃないか

0920デフォルトの名無しさん

2010/05/18(火) 23:37:41

誰も可能だなんて言ってない

0921デフォルトの名無しさん

2010/05/18(火) 23:39:16

return auto;

0922デフォルトの名無しさん

2010/05/18(火) 23:43:15

むしろfoo<auto>だろ。

vector<nagai_namae_no_type> hogehoge;
///...
hogehoge.swap(vector<auto>());

0923デフォルトの名無しさん

2010/05/19(水) 00:17:59

T<auto>は出来るように提案されてたよね?
std::pair<auto, auto> = make_pair( T(), U() ) みたいの。
g++, vc2010 で出来るか知らないけど

0924デフォルトの名無しさん

2010/05/19(水) 00:35:17

D の !( みたいに専用の括弧が無いから、auto<T> みたいのをやるなら
template であることを明示するとか?
vector<short> a;
template auto<int> b = a;

0925デフォルトの名無しさん

2010/05/19(水) 07:13:44

>>923
関数テンプレートでもそれ欲しいな
foo<auto, int>(...); みたいな感じで、１つ目は推論とか

それでこんな文法も欲しいと思ってしまった
void foo(int a, int b = 1, int c = 1);
foo(2, default, 3);

0926デフォルトの名無しさん

2010/05/19(水) 07:33:05

defaultって書く方がめんどくさくね？
単純に省略じゃダメなのか
foo(2, , 3);

0927デフォルトの名無しさん

2010/05/19(水) 07:35:37

defaultはやめてくれ。そこ変数名書けるとこだろ
省略はtypoで追跡しにくいバグを生みそうだなぁ

0928デフォルトの名無しさん

2010/05/19(水) 07:41:05

デフォルト引数をそのまま使いたいのよ
よくあるっしょ？

0929デフォルトの名無しさん

2010/05/19(水) 07:43:41

>>928
defaultって名前の変数あったらどうするんだよ・・・

0930デフォルトの名無しさん

2010/05/19(水) 07:44:45

ごめん、ないな。忘れてくれ

0931デフォルトの名無しさん

2010/05/19(水) 07:51:44

foo(2, __, 3);

0932デフォルトの名無しさん

2010/05/19(水) 07:53:32

むしろ名前付き引数が欲しいな
foo(a: 2, c: 3);

0933デフォルトの名無しさん

2010/05/19(水) 07:54:53

[foo a: 2, c: 3];

0934デフォルトの名無しさん

2010/05/19(水) 09:56:56

v(9, __,9);

0935デフォルトの名無しさん

2010/05/19(水) 10:21:04

v(^・^)v

0936デフォルトの名無しさん

2010/05/19(水) 12:37:19

defoult:

0937デフォルトの名無しさん

2010/05/19(水) 20:13:25

>>925
using boost::optional;
using boost::none;
void foo(int a, optional<int> b, optional<int> c)
{
foo(2, none, 3);

0938デフォルトの名無しさん

2010/05/19(水) 20:14:07

>>937
{　はなしで

0939デフォルトの名無しさん

2010/05/20(木) 07:09:39

離すってことは・・・こうか！ありがとう！

void foo(int a, optional<int> b, optional<int> c)

　{

　　foo(2, none, 3);

0940デフォルトの名無しさん

2010/05/20(木) 07:19:21

再帰ということでいいんじゃないか

0941デフォルトの名無しさん

2010/05/20(木) 22:35:59

lambdaとbindの使い分けを教えてください

0942デフォルトの名無しさん

2010/05/20(木) 23:59:32

使い分けもクソも全然別物じゃないですか

0943デフォルトの名無しさん

2010/05/22(土) 17:26:12

lambda: 常に使え
bind: 忘れろ。ネイティブなlambdaがあれば必要ない。

0944デフォルトの名無しさん

2010/05/23(日) 21:00:42

struct { int a, b, c; } foo() { return { 1, 2, 3 }; }

みたいに戻り値の型のところで直接型宣言できたら
tupleより結果にアクセスしやすいと思うのだが
C++0xでできたっけ？　これ

0945デフォルトの名無しさん

2010/05/23(日) 21:05:04

イニシャライザーリストでできるのかなぁ？？

0946デフォルトの名無しさん

2010/05/23(日) 21:05:34

>>944
戻り値のところで型の宣言するだけなら現行のC++でも可能だと思うが。

0947デフォルトの名無しさん

2010/05/23(日) 21:10:14

g++ 4.2.1でエラーになったけど

main.cpp:7: error: new types may not be defined in a return type

0948デフォルトの名無しさん

2010/05/23(日) 21:11:07

struct A { int a, b, c; };
A foo() { return { 1, 2, 3 }; }

はC++0xで可能なんだよね？

0949デフォルトの名無しさん

2010/05/23(日) 21:26:41

auto x2 = []{ return { 1, 2 }; }; // error: the return type is void (a braced-init-list is not an expression)

これも微妙なんだが
戻り値の型をstd::initializer_list<int>にしない理由は何なんだろ

0950デフォルトの名無しさん

2010/05/24(月) 01:38:15

書いてある通りだろ。
braced-init-listはexpressionじゃなくて、initializer。
戻り値を省略した場合、returnから推測してくれるためには、lambdaは、

{ return attribute-specifieropt expression ; }

の形でなければならない。
expressionであるべき場所に、expressionじゃないものを書いて、なんでダメなんだって言われても困る。

0951デフォルトの名無しさん

2010/05/24(月) 08:13:01

アスペルガー

0952デフォルトの名無しさん

2010/05/24(月) 18:41:43

>>950
別に、braced-init-listの時はstd::initializer_list<T>に推測する、
というルールを入れればいいだけじゃない？

0953デフォルトの名無しさん

2010/05/25(火) 23:26:39

アクセッサ自動生成する指定子とか提案されてないんですか？

0954デフォルトの名無しさん

2010/05/26(水) 01:23:04

>>953
ないだろうね。
実装（メンバ変数）に基づいてインターフェース（アクセッサ）が決まるような、
設計の基礎に反するプログラミングをサポートするとは考えにくい。

0955デフォルトの名無しさん

2010/05/26(水) 06:54:24

traitsやconceptでメンバー変数も対象にするようにしないとなあ

0956デフォルトの名無しさん

2010/05/27(木) 23:50:48

その前にまずconcept自体を入れないと

0957デフォルトの名無しさん

2010/05/29(土) 09:43:36

引数なしの非explicitメソッドx(void)は()を省略してobj.x;に置き換えられる
引数ひとつのexplicit非指定のメソッドx(arg)はobj.x = arg;で置き換えられる
これを導入するだけでプロパティがらくらく定義できて気持ちイイのになんでやらないのか

0958デフォルトの名無しさん

2010/05/29(土) 09:50:19

>>957
C#使ってると、obj.Size()でエラーが出てたりして非常にウザイ。関数とプロパティの区別は面倒。プロパティはいらない。

0959デフォルトの名無しさん

2010/05/29(土) 16:40:41

デフォで省略可能なのはキモい
何かつけたら省略可能、ならいいけど

0960デフォルトの名無しさん

2010/05/29(土) 16:59:02

プロパティと勘違いしてげった関数の括弧を省略しても文法的には通るのが大きな罠だよ

0961デフォルトの名無しさん

2010/05/29(土) 17:24:42

通っても別にいいんじゃない

0962デフォルトの名無しさん

2010/05/29(土) 17:41:45

explicit指定では省略できなくすればその問題も解決

0963デフォルトの名無しさん

2010/05/29(土) 17:43:49

問題はゲッタ関数じゃないのにプロパティっぽく呼べる方じゃないか
全部explicitつけろとか勘弁

0964デフォルトの名無しさん

2010/05/29(土) 17:45:03

>>959
コンストラクタさんディスってんのか
implicit指定がなぜ無いのか理解に苦しむ…

0965デフォルトの名無しさん

2010/05/29(土) 17:49:25

ディスってるよ！

0966デフォルトの名無しさん

2010/05/29(土) 17:50:24

this

0967デフォルトの名無しさん

2010/05/29(土) 17:54:10

Intel Distel?

0968デフォルトの名無しさん

2010/05/30(日) 03:00:38

アクセッサとまでは言わんけど、メンバ変数をクラスの外からは読み出し専用に
出来る方法があればなあとは思う。

0969デフォルトの名無しさん

2010/05/30(日) 11:59:05

昔は欲しいと思ったけど、今は必要とは思わないし、無くてよかったと思う。

0970デフォルトの名無しさん

2010/05/30(日) 12:02:55

アクセッサがあったら実際の型とは別の型として評価したり、評価だけに副作用を入れる事もできたりと夢が広がるが
結局それはメンバとしてではなくて別の一般的な機能
（例えばfactory patternをそのまま組み込んだような、派生クラスの型を追跡できないのにインスタンスをポインタを介さずに操作できる何か）
として規定してしまったほうがスマートなんだよなぁ・・・。

0971デフォルトの名無しさん

2010/05/30(日) 13:14:09

あのねオブジェクト指向というのは、人間が自然に持っている、
物などを認識する時にあれは魚だとか、これは食べられるだとか
分類しているそれの事なんです、ので、ものすごく古い行為です。
俺はC++よりいい方法でオブジェクト指向を有効に使って
プログラミングできる言語を思案中ですよ、みなさん。

0972デフォルトの名無しさん

2010/05/30(日) 13:15:34

そうですか

0973デフォルトの名無しさん

2010/05/30(日) 13:18:32

C++「＾＾；」

0974デフォルトの名無しさん

2010/05/30(日) 13:26:04

>>968
まんまRubyのattr_readerじゃん

0975デフォルトの名無しさん

2010/05/30(日) 13:40:58

>>968
メンバをconstにしてprivateな雪駄内でconst_castして代入すればいい

0976デフォルトの名無しさん

2010/05/30(日) 14:26:25

>>975 未定義動作

0977デフォルトの名無しさん

2010/05/30(日) 14:28:28

メンバでもだめなんだっけ？

0978デフォルトの名無しさん

2010/05/30(日) 14:29:13

>>975
const_cast覚えたての頃にやったわｗ

0979デフォルトの名無しさん

2010/05/31(月) 07:49:35

>>975
そんなことするより、これでいいんじゃ
class foo {
public:
　foo() : impl(1), val(impl) {}
　void increment() { impl++; }
　const int& val;
private:
　int impl;
};

0980デフォルトの名無しさん

2010/05/31(月) 08:04:51

メンバに参照を持つのはだるい

0981デフォルトの名無しさん

2010/05/31(月) 08:07:59

参照は小粒でピリリと辛い

0982デフォルトの名無しさん

2010/05/31(月) 08:16:09

コンパイラに代入演算子が自動生成できんぞオラァって言われるしな

0983デフォルトの名無しさん

2010/05/31(月) 12:26:35

const_castって未定義じゃない使いかたってあるの？

0984デフォルトの名無しさん

2010/05/31(月) 12:51:23

>>983
未定義動作になるのは、生成時点で const な型を持っていたオブジェクトに対して
書き込みをしてしまった場合。

最終的に書き込みが発生しなかったり、生成時点で const じゃなかったオブジェクトに
対して書き込みが発生するぶんには未定義動作とはならない。

0985デフォルトの名無しさん

2010/05/31(月) 14:09:12

>>979
メンバの宣言は
private:
int impl;
public:
const int& val;
の順でやらないとまずくない?

0986デフォルトの名無しさん

2010/05/31(月) 14:13:13

はっきり言ってconst_castには0xで消えてもらいたかった。
規格から消すだけじゃユーザーが独自にtemplate関数とc style castで作ってしまいそうだから
javaのgotoみたいに明示的に締め出すくらいしてほしかった。

0987デフォルトの名無しさん

2010/05/31(月) 14:32:35

C形式のキャストを消すほうが先だ。

0988デフォルトの名無しさん

2010/05/31(月) 14:45:13

あんなのD組

0989デフォルトの名無しさん

2010/05/31(月) 15:19:24

D言語は関係ないだろ！

0990デフォルトの名無しさん

2010/05/31(月) 17:06:27

Cを超える者…それがDだ

0991デフォルトの名無しさん

2010/05/31(月) 17:09:58

DはD組送りで

0992デフォルトの名無しさん

2010/05/31(月) 17:24:22

DとC++では用途が違うだろ。
変数CをC++するのとchar moji = 'C';をmoji++するくらい別モノ

0993デフォルトの名無しさん

2010/05/31(月) 18:05:58

moji is 0x0.

0994デフォルトの名無しさん

2010/05/31(月) 20:02:38

>>986
const使わないで作るバカは多いから
const_castがないとそういうバカの作った関数などが使えなくなる
あとCOMはconstないから（ry

0995デフォルトの名無しさん

2010/06/01(火) 15:20:35

下のを実行すると
2
1
4
となるのですが、mに2をキャプチャするにはどうすればよいのですか？

##############################
#include <iostream>
#include <functional>
using namespace std;

template <typename T>
std::function<T(T)> func(T m) {
cout << m << endl;
return [&](T x){ cout << m << endl; return x/m; };
}

int main()
{
cout << func<int>(2)(4) << endl;
return 0;
}

0996デフォルトの名無しさん

2010/06/01(火) 15:28:08

[&]を[=]にするとできましたが、
コピーコストがかかる場合もあるだろうから嫌だ・・・。
1ってどっからきたんだ・・・？

0997デフォルトの名無しさん

2010/06/01(火) 15:30:52

>>996
[=]にしないと、もともとのmはスコープアウトして不定になるんじゃないかい？

0998デフォルトの名無しさん

2010/06/01(火) 15:32:44

次ぎスレまだー？　次はAなのか10なのか。

0999デフォルトの名無しさん

2010/06/01(火) 16:01:09

C++0x 10
http://pc12.2ch.net/test/read.cgi/tech/1275375522/

C++0x学園の人々は任せた。

1000デフォルトの名無しさん

2010/06/01(火) 16:07:47

スレ番まで10になってしまったか…

1001１００１

Over 1000Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。