C++0x 9

The C++ Standards Committee
http://www.open-std.org/jtc1/sc22/wg21/

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

C++0x
http://pc11.2ch.net/test/read.cgi/tech/1149440647/
C++0x 2
http://pc11.2ch.net/test/read.cgi/tech/1191842951/
C++0x 3
http://pc11.2ch.net/test/read.cgi/tech/1204808027/
C++0x 4
http://pc11.2ch.net/test/read.cgi/tech/1214407525/
C++0x 5
http://pc12.2ch.net/test/read.cgi/tech/1232460649/
C++0x 6
http://pc12.2ch.net/test/read.cgi/tech/1245092251/
C++0x 7
http://pc12.2ch.net/test/read.cgi/tech/1253280377/
C++0x 8
http://pc12.2ch.net/test/read.cgi/tech/1262874195/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

○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さん達と一緒に弁当を食べようとしたら断られた。

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

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

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

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


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

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

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

なんか知らんが乙！

>>7
３６(ry

・progress_displayたん

毎度毎度乙wwww

・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さんと仲が良いらしい。

ばびょーん博士

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

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

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

reference_and_const_cast<HOGE>(hoge)();

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

std::functionかautoで受ける

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

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

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

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

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

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

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

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

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

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

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

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

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

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

何とかFCDっすか。

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

> ﾅﾝﾄｶvalue地獄
wwwwww

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

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

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

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

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

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

全く一緒

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

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

多分違いはそれだけ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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(笑)

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

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

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

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

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

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

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

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になった。


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

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

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

お前もか

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

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

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

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

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

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

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

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

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

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

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

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

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

>>73
>>71

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

>>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");

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>94
つ 14.7.2.2

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

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

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

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

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

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

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

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へ移行中

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

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

なんかかっこいいな

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

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

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

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

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

こんなコードがあった場合。投げた例外はキャッチもできず落っこちる。
例外安全性を宣言したつもりが、キャッチもできずにクラッシュしてしまう。安全にするつもりが超危険。なんて罠？
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;
}

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

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

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

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

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

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

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

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

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

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


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

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

こんな感じ？

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

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

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.

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

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

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

え？

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

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

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

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

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

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

やっぱり心配だ。

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

誰かたすけて〜。
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);
    }

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

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

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

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

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

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

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

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

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


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

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

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

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

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

>>127
どういう意味？

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

>>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.

だとさ。

unique_ptrとshared_ptrの違いは何よ？

unique か shard か。

意味わかんね

所有権の話。

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

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

stdにshared_ptrが入れば無敵。

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

unique_ptr がそれじゃないかな

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

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

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

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

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


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

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

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

日本語でおｋ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

initializer_list が渡されるんだろう。

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

これはなんだー

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

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

Scott Meyers先生すげぇ

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

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

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

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

1012年／（ ＾o＾ ）＼

Target publication date: 2012-02-28

>>199
Ed. 紫式部かよ。

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

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

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 = {};
で呼ばれるのはそれぞれどのコンストラクタでしょうか。
あるいはコンパイルエラーになるのでしょうか。
よろしくお願いします。

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

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

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

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

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

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

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

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

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

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

あるよ。

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({})が呼ばれる

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

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

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

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

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

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

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

のがやばいだろ。

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

猫は害獣

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

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

仕事はもう無い

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

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

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

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

じゃないかな・

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

もし興味ある方はぜひ。

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

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

Cat, I'm kitty cat.

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

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

>>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のソースコードを読む事に長けている方は
必ずやいらっしゃると思うので、
有識者の方、ご確認いただけますでしょうか。

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

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

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

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

Japanese版早く出せ

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

俺は待てない

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

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

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

おまえら何歳なんだよ

ょぅι゛ょです

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

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

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

lambdaっちゃ

誰がうｍ

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

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種類も書かないといけないのだろうか? それとも何か勘違いしてる?

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

これはいらないの？

>>252
書き漏らしてたよ。ありがと。

とにかく、こんなにたくさん必要だとすると
なにか省力化できる仕組みでもあればいいのだが…

右辺値参照なんて要らないよ
そんなに破壊可能なテンポラリが欲しければ
自分で一時変数作れ

>>254
演算子関係だと、結構効いてくるよ?
　X = A + B + C + d*D + E;
とか
　Y = A + (B - c*C)*(D + e*E + F)*(G + h*H);
とかね。

>>254
> そんなに破壊可能なテンポラリが欲しければ
右辺値参照をなーんにも理解していないんだな。
少しは勉強しろ。ggr

右辺値参照が必要な場面では内部処理も変わるだろうから
省力化は難しいんじゃないか

>>257
やっぱりそうか…。

でも >>251 のように列挙的に宣言したとき、>>252 のような warning が欲しい :-p

>>255
速度欲しけりゃそんな風に書くなと

でもまあ、そこそこの速度で実行可能なら
ライブラリーではETやrvalue referenceを使ってがんばる意味はあると思うが
その結果、可読性が高くできるし

>>260
>>255みたいな書き方だと、そこそこレベルじゃねーだろ。

>>258
GIMPLE使えば独自warningも追加できるぞ。

Expression Template技法は俺には扱えない。
頭がおかしくなりそう。

Rvalue referenceなら気合いで何とかなりそうに
思える俺が居る。

>>261
その代償が >>251 だと思うと・・・

>>261
ベクトルなら加減・スカラー倍で計16個、
多元環なら加減乗算で計20個、
さらに除算ができる場合は計32個の定義が必要！！

>>265
あっスカラー倍の割り算を計算に入れてなかったので、さらに若干増えるぞ！

X = A;
X.AddAssign(B).AddAssign(C).AddAssign(d*D).AddAssign(E);

でいいだろ

やだよそんなJavaっぽい書き方

>>265
どうせお前はまともなクラスライブラリ書かないから心配することないよ。

演算子のオーバーロードとか
あくまで補助的なもんだと言うのに
速度も一緒に得ようとか烏滸がましいとは思わないか？

現実にいいライブラリ蓄積してきているからなあ。

ET用にはBoost.Protoなんてのもあるから、
Rvalue-ref. にもBoostがなんか作るんじゃね？

いい具合の代数幾何ライブラリを書きたくなって仕方ないのは、
多分 Cg/HLSL とか AltiVec 拡張とか触ってしまったからだろう。
それらをライブラリとして実装するのは無理があるというが俺の結論。

どうせ、ループ中で特定の行列をレジスタに乗ったままにしたいとか
思い始めたらインラインアセンブラとか使うハメになるのだから、
速度よりも使い勝手や安定性や保守性を重視した方が良いと思う。

凡人の結論を軽々突破するのがC++ templateだしな。

>>274
しかし凡人にはC++ Template metaprogrammingが使いこなせないから
やっぱり無理なんだろうw

>>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にこだわる必要はなさそうだよ。


だってさ。

絶対に完成しないだろ0x

完成しなくてもコンパイラが対応しつつあるから
コンパイラ間で齟齬さえなければどうでもいいよ

もうコンパイラベンダ間で勝手に仕様作っちゃおうぜ
C++標準化委員会とか正直どうだっていい集団じゃねぇか。

あうとー。

C++1X/CLI で。

>>281
ああ、なるほど、そうすると
C++/CLIのごとくになっちゃうのか。

それはいやだな。

W3C←→WHATNGみたいな事態には陥ってないかと。
Committeeはいい仕事しているので。
遅いという気持ちは分かるけど。

テンプレ見てたらこんなの出来たとしても使えるようにならんだろ
effective C++を何倍の厚さにすればいいんや

>>283
> Committeeはいい仕事しているので。
遅いんじゃなくて、確実にクソ仕様への道を歩んでいる気がする。
多少 後方互換性を壊す勇気を持ってほしかった。

互換性が無くなったら意味が無いというかC++じゃなくなるというか
ベンダにとって不利益になるのは確実

>>286
> ベンダにとって不利益になるのは確実
どうしてそう言い切れるのさ？
ベンダだってわざと互換性が無いようにすることだってあるだろうよ。
とはいえ
> 互換性が無くなったら意味が無いというかC++じゃなくなるというか
まあそれは分かる。
C/C++との極めて高い互換性を持っていなけC++0xなんて
存在意義が無いとは思う。

もう新しい言語にした方が良い気がするねえ
Cへのトランスレータにすれば互換性も確保出来るじゃん

互換性が無くなるとコンパイルが通らなくなる
コンパイルが通らない新しいコンパイラなんていらない
＝不利益になる

物を作るソフトとかは後方互換性がないと困るよ

互換性捨てた新しいのならJavaとかC#とかDとかいっぱいあるじゃないか。

>>289
なるほどねぇ。そーゆー考えもあるね。

でもわざと他社製品との互換性を無くして自社製品で囲い込むって
ことはやるんでね？
IEとか。

× IEとか。
○ IEとかMS Officeでもそんな感じじゃん。

例外やTMPをCへのトランスレータとして解決できる実装があれば見てみたい。

>>293
> 例外やTMPをCへのトランスレータとして解決できる実装があれば見てみたい。
むしろTMPは割と可能じゃないの？
コンパイル時に定まるんだから。

例外は相当厳しそうに思えるが。

つsetjmp.h

Comeau C++ って
C++ -> C言語
の変換器じゃなかったっけ？？

setjmp使ってCで例外を自作してるのなら見たことあるぞ

コードをいくらでもグロくしていいなら例外も普通にifとreturnで書けるだろ

それかなりオーバーヘッドかからないか？

だってそもそも例外だし。

チューリング完全な言語同士では計算可能性は同じだから
可能かどうかで論じると意味をなさない
どのように実現出来るか、という視点で論じるべき

longjmpでは途中でローカル変数のデストラクタが呼ばれない
Cレベルで実装するなら関数に間接層を設けてif、return、gotoで実装するのが妥当？

そもそもCにデストラクタはないから問題ないんでね。

関数呼び出すたびif例外ならgotoとかするわけ

>>302
いまの話題がC++からCへのトランスレータであるという俺の認識が間違ってないなら、
C++のデストラクタ相当の機能をCでどうやって書き下すかということを言ってるんだと思った

例外が起きた時の処理を関数の中に書いておいて
setjmpでそこに飛ぶ関数を作って
その関数ポインタをグローバルなスタックに関数に入るたび積んで行って
例外が起きたら実行してやればいいんじゃないの

gccは例外サポートがCPUにない場合にそんな感じの実装になってるね。

Cへのトランスレータ作成が例外で頓挫したって話は
ありゃデマだったのか？

おまいら、C++の設計と進化ぐらい読んでないのかよ

私女だけど読んでなかった

CPUによる例外サポートって何？
x86ならINT命令？

C++例外の実装にCPUの機能（CPU例外機能）なんか使わなくていいんだよ。

CPUの例外とC++の例外はそもそも意味が違うだろ

>>308
それ読む価値あった？
俺は別に歴史にはそんな興味ないし。

例外を禁止し、exit()で置き換えれば吉。

>>313
> それ読む価値あった？
物事の欠点を見つけた時に、
「こういう欠点があると自分にわかるのは、自分が利口であり、この物事に関わった奴らが馬鹿だからだ」
と考えて満たされちゃう浅はかな生き方してる人に読ませると、多少はそれを矯正できるかも。

>>315
なんだか深い事いってるのう

C++がこんなになっちゃったことへの禿の言い訳が延々書いてあるのかな

というような人に読ませるのも吉。
読んだら最後、それでも揶揄したかったら具体的な話をしなきゃ通らなくなるし、
そういう人は大抵そういう具体的なやり取りできないので、馬鹿を黙らせるのに使える。

難度の高い言語だから「こんなことになっちゃった」とか言っちゃうような子は
そう思っておけばいいんじゃないの
まあC++にも色々「どうしてこうなった」的な部分はあるんだけど
多分俺らがどうしてこうなったと思ってる部分とこの子らが言ってる部分は違うよな

D&Eを読むと、大抵の仕様はよく検討したらしいことが伺える
個人的には納得できる議論もあったし、
納得できない記述もあった

まあ少なくとも、単なる思いつきで仕様をいじることはないらしい
もうちょっと深慮がある

C++使ってて「なんでだお！？」って思う部分があるならD&Eは読む価値がある。
C++0xに関してはD&Eの記述からすると結構「？」な部分も多いけど。

typesafe enum が欲しい

0xの Strongly Typed Enums のことか？

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

conceptは犠牲となったのだ・・・

>>324
＞A mor complement

愛の補数とはまた粋な

いやいや、きっと次のC++の版くらいには
復活するでしょconceptさん。

なんか面白い話題無い？

>>328
C++0xには今のところない。

　　　　　　 　 　 ＿_
　 　 　 　 , ‐' ´　　　｀`‐、 　 　 　 　 　 　 ／￣:三}
.　　 　 ／,. -─‐- ､.　　 ヽ　　　　　　　　/　　 ,.＝j
　＿,.:_'＿＿＿＿＿_ヽ、　.!　　　　 　 .／ 　 _,ﾉ
　 `‐、{　へ　　'ﾞ⌒　`!~ヽ. !　　　　 ／{.　　/
　　　 ｀!　しﾟ　 （　ﾟj　`v‐冫　　　, '::::::::ヽ､/ 　　　　話題がないなら野球しようぜ！
.　　　 {.l 　 '⌒　 　 　 ﾞ 6',!　　 / :::::::::::::::/ __
. 　 　 〈　　< ´￣,ﾌ　 .ﾉｰ'_ , ‐'´::::::::::::::;/ （_ノ)‐-､
.　 　 　 ヽ.、 ` ‐", ‐´‐:ラ ':::::::::::::::: ;∠.　　 ヽ_}　 ﾞヽ
　 　 　 　 ,.r｀ "´　　／:::::::::::::::::::ィ´　　｀ゝ　 !、　　/
　　　　　/ 　 　 　 / :::::::::::::::: ; '´　　　/´＼　/ 　 r'＼
.　　　　 i　　　　　 ! ::::::::::::::／ 墨　|　.!::::::::／ヽ､.._!ヽ.　ヽ､
　　　　 {　　　　　 {:::::::::::;:ｲ　/　　 ‖ｉ:::::::/:::::::::::::/　 ＼
.　 　 　 ヽ 　 　 　 ヽ,.ｧ‐'´ /ヽ 二 ,/`ヽ、::::::::: ／

GCCの完全サポートがまぁ4.5.x〜4.6ぐらいだとして
VC++のサポート完了はまたSP1待ちかね。
tr1の時も遅かったし…

VCなんかに期待してるのか？
やめとけ。無駄だ。

ＶＣ３０００のど飴のことです

2020年、cppxlang + LLVM が盤石

>>334
いや、2011年にはC++0x完璧で、
下手すりゃconceptも2012年くらいに実装されてると思う。
Clangは凄い勢いで成長してる。
コードも綺麗。

Cに変な拡張入れるのやめて欲しい…>Clang

しゃーねーだろ。gcc互換目指してるんだから。

gcc拡張ならともかくCにGCとかクロージャとか誰か止めなかったのか
せめて一言"ObjCでやれ"と言う奴はいなかったのか・・・

いや、ああいうのはLLVM的に必要だから。
LLVMとの絡みで実験的な実装をやるのが、
Clangの目的のひとつ。そしてLLVMの仕様に反映。

>>335
C++0xの現行版の仕様が確定するのが
2011年だぞ？

アホが来た

どうも。いつもお世話になってます。アホです。

なんでこれで笑ってしまったんだろう・・ｗｗ

>>340
実装状況調べてないだろw

>>344
ぜんっぜん調べてねぇけど、ドラフトは読んでるよ。
この状況では確定するのはやっぱり2011年だろ？

FCDまで来たから、機能が増えたり改められたりはもう多分ない。
何か問題があったら引かれるだけ。conceptのように。
あとはrvalueみたいに表現の調整ぐらい。

>>346
このFCDのまま行くのかね？
あと1回くらいFCDを出し直してそれから進むと踏んでいるんだけど。
その辺を含めて2011年と見ている。

今年の夏からFCDという制度そのものがなくなってしまうので、多分このまま
FCD→FDISと行くんじゃないかなあ。FDISは事実上の信任投票で
技術的変更は不可だから、FCD→FDISの間で「FDIS投票がこけないような修正」を
して終わりだと思う。

ああでもTarget publication date: 2012-02-28なんて話題もあったっけ。
んー、もうあとは引き算だけだと思うんだけどねえ。

noexceptは簡単には済まないと思うけどねえ
ムーブセマンティクスと例外の絡みで出てきた話だから引けばいいってもんでもないし

noexceptは引き算されそうなにおいがぷんぷんするな。

>>341-344
んで、無知なあなた方は、なんか俺に謝る事あるんじゃないの？

うわっ　ｷﾒｪ＾＾

既に実装されているものもあるのにねえ。

引き算だけならいいけど、それが形を変えて戻ってきたら
実装済みのコンパイラ涙目

掛け算されたりして
アッー！

>>353-354
で？
俺は実装の話なんて一言もしていないが。

> C++0xの現行版の仕様が確定するのが
> 2011年だぞ？
としか言ってないけど。
なんか正当な反論ができるならしてみろよ？無知が。

どうも。ご迷惑おかけしています。アホです。

あんたが正しいか正しくないかじゃなくて、
こんな２ちゃんごときで謝れとか言い出すあんたの器量の狭さがキモいんですよ＾＾

>>357
pgr

はいはいごめんやさいごめんやさい

>>358-361
んで結局お前らは全員が知ったかぶりだったってことでいいんだな？

この件を恥じ入り、以後知ったかぶりを改めるように！

はーい^^

おまえら明日VS2010でたら色々遊んでレポートしなさい

本の虫のブログで初めて知った。
deleted定義
ttp://cpplover.blogspot.com/2010/04/deleted.html

これすげー便利だな。

>>365
予約語deleteの再利用か。
exportは仕事 首になったからまさに完全ニートになってるけど、
予約語としては生き残っているらしいから、
なんか有効利用してあげられないかな？

concurrency/atomics 周りが GCC 4.6, 4.7 あたりで
完全にサポートされるようになるとはとても思えない……

本の虫がそこに気付いてなかったとは…

template<typename T> operator T() = delete;なんて好きそうなのに

俺もメンバ関数にしか使えないのかと思ってた

ほほうそれは Tの修飾をどの程度含んで殺してしまうのかね？

>>367
gccはその辺は一番遅いでしょ。
昔みたいにx86専用フォークあれば別だけど。

deleteに続いて併せて使われる予定のdefaultはなんだか微妙な感じだな。
純粋仮想関数よりは見た目はいいが。

=defaultも大事だぞ

struct Point{
int x,y;
Point() = default;
Point(int x, int y) : x(x), y(y){}
};

これが出来るだけで凄い価値がある

Point() {} と何が違うんだっけ
inline強制じゃないんだっけ？

Point(){}はコンパイラ生成のデフォルトコンストラクタじゃない＝PointはPODじゃない

コンストラクタつきのPodが可能になるのか

Podってキャピタライズされると地味に違和感

デフォルトコンストラクタだけデフォルトでも
他が違えば意味ないんじゃないの？　＞POD

コピコン、operator=、デストラクタは書かなけりゃデフォルトだからいいの

デフォルトコンストラクタだけは自分でなんかコンストラクタ書くと潰されるから
明示的に指定が必要

だから Point() {} と何が（ry
デフォルトのコピコンやoperator=をprivateにしたい時に使うのは便利そうだけど

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になるとかならないとか

新しい関数宣言やラムダって当初のまんまなの？

>>381
なーるほど
それだと重要だな

そういや、デフォルトのコピコンやoperator=を殺したければdeleteすりゃいいんだった

>>382
unified function syntaxはボツになりました…

unified function syntaxはクソだったからな。
不細工すぎるだろ

やっぱりあれはボツだよなあw
安心した

>380
default constructor が trivial か non-trivial かの違いになります．
で，この違いがどうなるかというと結構大量にあるっぽいので
誰か親切な人まとめてください．

>>387
うむ。
いくら何でもなぁ。

POD って C++0x でそれほど重要な概念になってます？

どちらかというと， POD という用語の従来における定義の個々の構成要件だった
「各 special member function が trivialかどうか」や
"standard-layout type" といった概念が，それぞれ独立して
重要な仕様上の概念として活躍しているような？

そういやドラフトでPOD関連全般にもの凄い修正入ってた気がするわ
多すぎて目を通してなかったけど

最後にまともにC++に触ったの10年くらい前で、既にJavaに移行してしまった者なんだが、
お前らが何を言ってるのかさっぱり分からん。

多分ずっとC++使ってる人でも分からないから問題ない

PODの重要性は今までと一切変わらんよ
CのAPIに渡したりバイトの塊としてストリームに流せたりすることを保証する枠組みは絶対に必要

仕様上の概念としてはtrivialとstandard-layoutに整理されて文言の登場頻度は減ったけどね

いったいなんなんだC++って。

>394
＞CのAPIに渡したり〜
この部分は完全に同意していて， >390 は単に
＞文言の登場頻度は減った
んじゃないの？ っていうのが言いたかっただけです．すいません．

どうでもいいじゃない、そんなこと。
PODの概念が具体的な形で整理されたことが大切。

より重要な概念になったかどうかとか、登場回数が減ったとかどうでもいい。
重要かどうかってのは評価に属することなんで、考え方次第。

C++は、PODにしても>>367にしても、
高級アセンブラとしての役割というか、
低レベルな部分での仕様を追求するのが面白いね。

>>397
さすが移植用アセンブラたるC言語の直系の子孫。
いつまでも変態記法と低レベル作業を忘れないでね。

変態な君が好き。

変態紳士な貴方も、チェリーボーイな君も、ウィザードハッカーな彼も。
みんな大好きC++。

むしろそういうヤツしか大好きじゃないんじゃないかなC++

俺ってウィザードハッカーだったのか

C++はメジャーな言語です。
メジャーな言語を使えるプログラマーは変態ではありません。技術者です。

高級アセンブラって褒め言葉にしか聞こえない。

C99と違ってMSも実装に前向きみたいだけど
0xってどれだけ普及するだろうか

正直「C++で開発してます」と言ってる業界のtemplateの普及度すら怪しい

凄い的確な返しだ

>>406
templateは保守性が低いから使うな！ってよく言われるよ。
lambdaなんぞ入ったらどうなることやら…。

保守性が低い、の意味が、
俺らが読めない、だからなあ

ある意味真理

過去スレ読めないので既出かもしれませんが質問させてください。

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
上の文はまだ修正される可能性があるのでしょうか？

分かる人間がいなきゃ企業としては保守性低いわなぁｗ
概念的にはそんなに難しいものじゃないけど
ヘッダに実装書くことによる細かいバッドノウハウはちょっとだるい

>>411
POD型のデフォルトコンストラクタは0クリアじゃないの?

>413
thanks.
default constructed とは value-initialized(8.5) と同じ意味なんですね。

古いVC++だと初期化されなかったような気がする
所詮規格は規格であって実装で無視されたら意味ないしなあ

いや、あれはvectorじゃなかったか・・・？
記憶が曖昧だ・・・
違うかもしれない

VC10express使った人いる？
どうかな？対応具合は？

XP SP2には対応していなかった

誰もそんなこと聞いてねぇｗ

ワロタｗ
でも地味に良い情報だったｗ

対応してないのか、単に保証してないか、どっちなんだろう
単にSP2自体サポート終了してるから対象から外しただけな気もするが

A がムーブコンストラクタを持つ状態で

A foo() { return A(); }

を実行した場合、文法上、戻り値返す際に動くのは
コピーコンストラクタとムーブコンストラクタのどっち？
（実際にはどちらにしろ戻り値最適化されるだろうけど、
　仮に文法上コピーコンストラクタが実行されるなら、
　コピーコンストラクタを private にした時（あるいは delete した時）に
　エラーになるという違いがある）

とりあえずVC++2010はコピーコンストラクタが動こうとするみたいだけど。

>>415
> 古いVC++だと
古いVC++なんて、それを言って良いならいくらでもそんなことはあるだろうよ。

>>422
それだけだと右辺値参照する側がいないんじゃないか。

受け取るやつがいるいないは関係なくない？
どこから呼ばれるかコンパイル単位には分からないわけだし

>>422
ムーブコンストラクタがあればそっちで、なければコピーコンストラクタ、でしょ。
そうじゃないと困りそう。

>>424
戻り値最適化がないなら、
return に書いた式から、関数の戻り値へとコピーかムーブが走ると期待できる

>>426
じゃあVC++2010の挙動がおかしい、と
publicなムーブコンストラクタとprivateなコピーコンストラクタを定義したら、
コピーコンストラクタが使えないよというエラーになるから

もう１つ、

A a(A(1));
A a(foo());

でも同じ状況でVC++2010はエラーになる。
ただし、後者ではコピーコンストラクタを有効にして実際に実行してみると
ムーブコンストラクタしか動かない。
（前者は最適化されてコピーやムーブ自体が実行されない）

VC++2010、地味にヤバそうな予感
まだゴリゴリ書かない方がいいのか・・・　って、何か問題起きたら 2008に持ってけばいいのかｗ

いや、すまん
>>428 は後者も最適化されてコピーもムーブも動かないわ

ムーブコンストラクタはそんなに神経質に使うものじゃなくないか？適用されたら儲け程度に考えればいいんじゃね。

void hoge(A&& a) {
　a.piyo(); // piyoは非constメンバ関数

　A b(a); // ムーブ？　コピー？
　b.piyo();
}

hoge(A());

これでコピーコンストラクタが動いたんだけど
ひょっとしてムーブコンストラクタの考え方、俺間違ってる？

a.piyo(); が実行できたという点では
右辺値参照万歳ではあるんだけど

>>432
ムーブしたかったら A b(std::move(a)) じゃないか？

>>432
そこで勝手にmoveしちゃったらその後のaはどうなるんだよ

>>433
おお、そうなんだ
そうしたらムーブコンストラクタが呼ばれたわ
ありがとう

>>434
あとは野となれ山となれ

というか、>>422 のエラー発生状況の説明が
「'A' から 'A &&' への変換時」ってなってるな
どうもムーブコンストラクタを呼ぼうとはしているみたいだ
でも、なぜかコピーコンストラクタがアクセス可能じゃないとダメ、と

'A' から 'A &&' への変換に
なぜコピーコンストラクタへのアクセス可能性が要求されるのだろう？

名前付きの値は（左辺値参照でも右辺値参照でも）左辺値として扱われる。
>>432 の例でいうとaをムーブコンストラクタに渡すには
std::moveの返値（無名の右辺値参照）にしなければいけないわけだ。
なるほど。

>>438
なるほど
ムーブコンストラクタがあっても、
左辺値でコンストラクとしようとする時には
勝手に右辺値参照になってはくれないのね
確かに安全のためには必要そうな仕様だ

ひょっとして、ムーブ可能にしたければ
コピーも可能じゃないとだめというのが仕様だとか？
でも、MoveConstructible requirements にそういう事は書いてないし・・・

>427
＞publicなムーブコンストラクタとprivateなコピーコンストラクタを定義したら、
＞コピーコンストラクタが使えないよというエラーになるから

再現しないっぽいのでとりあえずコード全体をさらしてほすぃ……

422==432で書いてたコードand/or考えが間違ってたんだろう

不思議な事に、こっちでも新しく書いたら再現しない
条件があるのかも

めっちゃアンドゥして昔のコードに戻したけどやはり再現しない・・・
一体なんなんだ

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時に死ぬ

クラスとかなら問題ない

new autoとかありだということに驚いた

最後はdelete[]だろ

>>445
どのコンパイラくらい書いてくれ。

死ぬってのは実装の問題ってこと？

VC++2010で試したら確かに実行時エラーで死んだ。
誰かGCCで試してみてほしい。

なんだこのスレタイと全然関係無い話題なのに
妙に価値のある内容は。





もっとやれ

>>445
g++-4.5 (Debian 4.5.0-2) 4.5.1 20100419 (prerelease)
だと死なない（そりゃそうだ）

>>447
ポインタをnewしてるだけだからdeleteで問題ない

new auto("hoge") は const char**

deleteかdelete[]かを判断できないのだからnew auto(ここの部分);で、動的にdeleteかdelete[]かを選べるshared_ptrみたいな動的削除子が組み込みで欲しいな。

　　　　　　　　　　expression
　　　　　　　　　／　　　　　＼
　　　　　　 glvalue　　　　　rvalue
　　　　　／　　　　＼　　／　　　　＼
　　　lvalue　　　　 xvalue　　　　prvalue

Figure 1 -- Expression category taxonomy

何か笑ってしまった
複雑だなあ

>>455
new auto で確保したものは常に delete
配列 new を初期化パラメータ付きで行うのは不可能だから

そうだった。つまりこれはnew autoしたのをdeleteする処理系が悪いということか。

new autoは実はGCが働くんだよ！

だったらいいんだが
autoってそんな意味じゃねー

newしてるのにポインタじゃなくてスマポが返るんですね分かります

>>456
仮想継承にしなくちゃならないなｗ

>>456
シンプルやん。
対称だと頭に入りやすい。

　　　　　　　　　　expression
　　　　　　　　　／　　　　　＼
　　　　　　　lvalue　　　　　rvalue
　　　　　／　　　　＼　　／　　　　＼
　　 plvalue　　　　 xvalue　　　　prvalue

これなら対称なんだけど

>>463
機能まで対称だったらわざわざ仮想継承構造にする必要ないけどな

lvalue &
rvalue &&
prvalue &&&
になりそうな予感

int n = 0;
auto l = [=]() mutable { ++n; std::cout << n << std::endl; };
l(); //1と表示
l(); //2と表示

ラムダ式を作成した時に
クロージャ型の非staticメンバ変数のnに外のnがコピーされるから、
それを変更すると次の呼び出しでもその影響が残るのは
仕様でいいのよね？

ラムダ式はreturnできないし（template<class L> L hoge(L lambda) { return lambda; } みたいなのは例外で可能だが）、
関数ポインタに渡せないんだな
前者は戻り値の型が書けないからで、
後者は関数呼び出しがクロージャ型の非staticメンバ関数だからだな
どちらも仕方が無いけど、微妙に不便

まあ後者は、クロージャ型の非staticメンバ変数に
operator() を自インスタンスを使って call するコードを
持たせる事で実現できるとは思うのだが、
メモリの実行権限とか考えると微妙だわなあ

>>465
> lvalue &
> rvalue &&
> prvalue &&&
何気に分かりやす・・・くねぇな

って、規格上はラムダ式は関数ポインタに変換できるのか……
今年３月の話みたいだから対応して無いのは当然だけど

関数ポインタよりもresult_typeが欲しいよ。

std::functionにキャストすれば使えるんじゃないの＞result_type

>>471
なんと、その手があったのか。改めてfunctionはすごいな。
ラムダ式をboost::lambdaでラップしようかとか悩んでた。

swap技法が適用されるデフォルトムーブ演算子operator=(&&)とかできないかなあ。

デフォルトムーブ代入演算子なら最新のドラフトに入ったよ

戻り値の型を auto にして trailing return type を省略し
return する値の型を全て同じにすれば
戻り値の型を自動的に類推してくれる、
という仕様は検討された事ないのかな
それがあれば関数をカリー化して返せるんだが

auto add(int n) {
　return [=](int x) { return x + n; };
}

>>474
おおっとそれはすごい。VC10にいつかはサポートされるかな。
現状のVC10はどこまでサポートされてるのかさっぱり分らない。SPが出るたびに調整かｗ

>>475

　auto add = [](int n) {
　　return [=](int x) { return x + n; };
　};

で我慢しろ

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

Unified Function Syntaxも戻り値の型推測入れればいいのに

>>475
宣言だけの場合は？

>>480
inline や template と同様、ヘッダにしか書けない
ただし、static を明示的につけない限り、リンク時に実体は１つにまとめられる
宣言だけ書くことはできるが、同じ翻訳単位に定義が必要

みたいな感じで

×ヘッダにしか書けない
○複数の翻訳単位から利用するにはヘッダにしか書けない

まあ、同じ定義を自分で複数の翻訳単位に書いてもいいんだけど
それはそれこれはこれということで

>>478
ありがとう。対応状況が一目で分かって助かります。

引数が二個ある関数で右辺値参照するときは、
こんな風に全ての組み合わせがいるの？

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

どういう使い方するかによるんじゃない
普通は一方をもう一方の情報を使って変更して
変更したオブジェクトを返すという形にすると思うけど

VC10で is_pod<void>::value がtrueになるのは相変わらずか。

>>485
なるほど、通常は片方だけですむってことなのか。

ラムダ面白いな。
てきとーにVC10ee触ってるんだが、ラムダって制限つきローカル関数のように使えるな。
さらに便利かも。

確かにfor_eachなどに直接渡すだけじゃなく、ローカル関数として使えるね
これでいちいち関数内に構造体作る必要がなくなったわ
しかもメンバにも直接アクセスできるし

ラムダ関数はresult_typeを定義してくれてたら完璧なんだけど

その辺はconceptで整備するつもりだったんだろうけど…
function_traitsを定義するんで凌ぐのかな。

>>490
メンバにもアクセスできるの？！

ローカルクラスとかわんないと思いこんでた

環境いじれないのはlambda式じゃないぜ…

thisをキャプチャすればメンバに触れる
どうせ[=]か[&]にするだろうから
自動的にキャプチャされるだろうが

むしろthisがキャプチャされない場合って．．．？

[]にしたい時だってある

引数しか使わない
そんな気分の時があります

キャプチャってなんだーー！！！

ああ、0xのLambda式か。

autoって本当に便利ですね。てかテンプレートには必須だよ。

キャプチャしない場合でも、[&][=]って書いてもペナルティはない？
紛らわしいからやめろと言われればその通りなんだが、コンパイラがどういうコードを吐くのか気になる

最適化すりゃ消える

むしろ追加でコード生成されんの？

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

すまん，キャプチャの意味がわかってなかった．．．

>>504
おばか

省略の意味がちげえｗ

>>502
コピコンのあるようなものがいらっしゃると消えてくれないかも

[](int x){return x;}

->int とかの trailing-return-type って普通の関数定義にも使えるんだな
用途がよくわからんが

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なら大丈夫なんだろうけど。

>>507 kwsk

>>510
template <typename T>
auto foo(T a, T b) -> decltype(a + b) { return a + b; }

とかできるよね、という話らしいよ

あとは auto foo() -> int(*)(); とか、関数ポインタや配列ポインタを返しやすいとか

そういやlambdaはDLLにexportできるようになるんかな？

exportするなら普通の関数でええやんという話

>>509　あ、そうか。そうだような。俺が馬鹿でした。
でもさすがにC#のように引数の型を省略 auto z3=[](x){return x*2;}; は無理？とおもったけど。
auto z4=boost::lamabda::_1*2;　はOKなのね。boost::lambda恐るべし。

C#の型推論はデリゲート側と型を一致させるというしくみだから
autoで受けるC++0xではまあ使えないわなあ

>>513-514
なるほど、納得。

どんどん初心者お断りで複雑怪奇な仕様になっていってる気がする…

なにをいまさら

カンタンカンタン

>511

u'\u0905' wchar16_t だから「実行時キャラクターセット」は使われません。
どんな環境でも UTF-16 エンコードが使われます。
0x0905 と同じ表現を持つ値となります。

>>523
実行文字集合に無い文字は、翻訳段階5でいったん文字化けさせろって書いてない？
「文字(列)リテラル中のユニバーサルキャラクター名は、実行文字集合中の対応物に置き換える」

リテラル中の文字が、ユニコードでどの値を持つか評価されるのって、その後だよね？

>>520
分かる部分だけ使ってりゃいいって

コンセプトが入ってればエラーメッセージが(以下略

C++0xはよく考えられた改良だと思うけど
互換性のために殆どが「追加」になっちゃうんだよね
便利でシンプルで完全に動作するC++のサブセットって定義できんもんだろうか

互換性を無視したとして、いらない機能は何だろう？
つ可変引数

それは要るだろw
筆頭は0＝ヌルポインタだな。

古い(というか従来の)関数宣言
struct か class のどちらか
古い(というか従来の) enum

typedef

型変換演算子の廃止

コピコンとデフォコンの特殊ルール

unsigned全部

>>527 は新しい言語を作るんじゃなくてサブセットを定義して学習のコスト削減を意図してました
仕様変更ではなくコーディングルールみたいなもん

>>529
printfみたいに引数の検査ができな可変引数よりも、
cout<<a<<b; とか boost::format("%d %d")%a&b;
とかてC++の機能で代用できるもので可変引数は廃止でいいんじゃないか？

hoge a(); が関数のプロトタイプになるのはなくしていいとおもう。

boost::format("%d %d")%a%b; だった。

これだろ…
std::vector<bool>

1パスコンパイル

bind1st , bind2nd, fun_ptr

>>536
printfを例に出すとは素質悪いな

禿の新しいC++本(Programming: Principles and Practice Using C++)で
10行程度しか触れられていない
valarray

互換性を無視していいならいらない機能の筆頭は、暗黙の変換
バグの元

アップキャストがバグの元っていったい

>>544
non-explicitなコンストラクタとかoperator T()のことじゃない？

整数の暗黙の拡張とか

暗黙の変換というか標準変換の一部と言うべきなのか
要するに数値型間の暗黙の変換

charをintegral typeから外して、integral type最小のbyteを設ける。

暗黙の型変換なくす人、
xがintの時、式 x * 3.14 の型はintでOK?

コンパイルエラー

>>549
#pragma yutori
ならばOK

整数の拡張って何がまずいん？

unsigned int x = -1;
がコンパイルできちゃう

static_cast使いまくりで可読性が悪くなりそう

>>491
result_ofが使えればいいよ。

>>553
警告が出るからいいんじゃね？

数値の暗黙の拡張にこれほど疑問や反論がでるのは予想外だった
正直、ほとんどの人に共通の認識だと思ってた

>>556
これには警告でないでしょ
gcc -Wall でも警告でないはず

unsigned f(int y)
{
unsigned int x = y;
return x;
}

unsigned int g()
{
return f(-1);
}

-Wsign-conversion で警告がでるな

-Wextra

-Warata

-Wwwwwwww

多少ずれるが
unsigned変数の小なり０比較はエラーにすべき

>>563
警告出して最適化してくれれば十分だと思う。
テンプレート使ってるとsignedとunsinged両方使えるようにするとき役に立つ。
警告なら必要に応じて抑制できるけど、エラーだとsignedとunsingedで分岐するテンプレートを書く必要が出てきて面倒。

最適化というのは，勝手にsigned変数に変更するということ？
それとも比較元を＋１して小なり1比較ってこと？

いや、常にfalse判定じゃないかと

うんfalse判定でifのtrue項が削除されてとりあえず警告。その箇所だけpragmaで警告抑制。

>>563
エラーにするのはループ条件に出てきた時だけでいい
その他の場合はフェイルセーフで書く事もあるので警告すら出て欲しくないな

>>568
ループ条件に出てきたときはループ削除でよくない？エラーはやりすぎでしょう。

>>569
ごめん
別な条件の方で考えてた
(unsigned)x >= 0 の方

-Wallでも警告されずバグを埋め込んだ例
https://bugzilla.kernel.org/show_bug.cgi?id=12597

>>571
すげー
Linus Torvalds の生コメントがある！

・・・でもLinusはC++大嫌いだったな確か。

enum class って劣化 Java の enum だよね
Java の enum そのものにしてくれないかなぁ・・

どちらかといえばC#のenumが近い

それは確かに否め（enumえ）ない

>>573
Java の enum ってどういう挙動なんだか知らんが
そんなに良いのか？

Javaのenumはクラスに近くて、
要素の宣言でコンストラクタに渡すパラメータを指定できる。

>>577
ふーん。ありがとう。

いっそenum class とenum structみたいに2種類にして
機能を分ければよかったのにね。

enumとして正しい値かどうか検査するメンバ関数とか
enum名を文字列で返すメンバ関数とか欲しいわ

>>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++にも同等の機能入れてくれないかな

そこまでするならクラスでいいじゃん、と思う

先生！！メリットがわかりませんん！！

enum class {} というのは指定したクラスのconstインスタンスを名前を
付けて列挙するものという意味付けにすれば後は何でも出来そうな。

Scala の case class の超絶しょぼい版という印象だな > Java の enum

演算子のオーバーロードは今のenumでもできるが

Javaほど機能詰めすぎると逆にイミフなような…

俺がほしかったのは"スコープつきのタイプセーフな列挙子"だし、
機能詰め込んだとしてもC#のenum程度でいいよ

ToStringは欲しかった

boost::lexical_cast

typeidのnameをもっとまともに規定してほしかった。

>>588
それもSTLコンテナの場合、operator<<が定義されてないから使えないんだよな……

自分で定義すれば良いんじゃね？

>>589
ちゃんと読める名前を返すものと、一意性さえあればいいものと、２つ用意して欲しいわ

typeidの名前の文字列をバイナリに含めるか含めないかのオプションが欲しい

ラムダ式を関数ポインタに渡せるようになれば、
システムコールバックが使いやすくなるな
GCなしでどう実装するのか分からないが

また来た

>>578
classとstructの違いはデフォルトのアクセス性しかないのに
enum class とenum structで機能が違うのは紛らわしくね?

template <struct T> がエラーなのと同様、
enum struct は不許可にすべき

>>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] のように表示される。

みたいなラッパーを自作するだろ普通。

lambdaって関数の引数として渡したい場合はtemplate使うしかないの？
シグネチャが分かっててもダメなんかな。

シグネチャが同じってoperator()のシグネチャが同じなだけで
キャプチャした変数によって型は違うんじゃないの？

>>600
翻訳単位が違えば型も別になるしなぁ。
静的型付けが大前提だし、template使うしかないのか・・・

ていうかlambdaのoperator()ってvirtualになってないのかな?
なってなさそうだなぁ

ラムダ式はalgorithmと組み合わせて使う事がほとんどだろうから
virtualはあまり必要ないんじゃ？

あ、コンテナの中にBase, Derivedへのポインタが入っていた場合に欲しいか

>>603
うん、C++的発想だとそうなるんだけど、つまりシグネチャ決めようがねーよなって話

無理にやったらやったで出来ない事もないだろうが
ただでさえキモいラムダ式がさらにキモくなるな

そういう強引な自己満コードを見たら今後は キモダ式　と呼ぶ事にするｗ

C++0xが入るとBoostはさらにキモさをPowerUpするぜ間違いない

いやな、VS2010で遊んでるんだが、ラムダ式かなり使えるよホント
これでBoost::lambdaはほとんど必要なくなるな

しかし見栄えが汚いな
C#3.0の時に汚いの分かってたろうからもう少し綺麗に見栄えのする
書式にできなかったものかねえ

Cの関数ポインタ自体がきったねぇことを考えると
もうラムダさんの服装は無難で妥当に思えてきたよ

ラムちゃんの衣装は虎模様のビキニ

誤爆しました

VS2010のメリットはラムダさんとautoさんとdecltypeさんだけだからな
他のすべての点においてVS2008に劣っている

VS2010は発売後直ちに数多くのバグ報告がされているからSP1は
早めに出るかも知れない

その時にC++0xの時間が無くて入れられなかった機能を入れて欲しい(´･ω･｀)

最初のベータから0xの機能は増えてないんだよな

>>612
rvalue reference の準拠文書が更新されてるってのを
Boost ML で見たような気がする。

>>612 じゃなくて >>614 だった。

VC2010は右辺値参照サポートしてライブラリも Move Semantics を実装してるんじゃなかったっけ？

別にC++0xの規格がまだ定まっていない以上、
C++0xに関するバグはどれだけあろうがしょうがないんじゃない？

ただ2010から現在のC++0x機能を除いたら何が残るのか知らんけど。

最早スレチだと思うけど、インテリセンスがマシになったという噂

C++/CLIはインテリセンス自体がなくなった

>>620
なるほど。確かにインテリセンスのバグはなくなったな。

>>608
boost::lambdaはこんなこともできる。
auto m=boost::lambda::_1*2;
auto a=m(3); //戻りはint
auto b=m(1.3); //戻りはdouble

>>617
std::mapとstd::tr1::shared_ptrを使ってみたけど両方共右辺値参照サポートしてるね。

>>619
インテリセンスはよく効くようになってきてるね。
エラーのハイライトの反映が遅いね。処理中は薄くするかステータスバーに表示して欲しいな。

>>622
すげー

>>622
この機能はすごいと思うがさすがに必要ない
関数テンプレートで簡単に実現できちゃうもんな

>>626
ラムダは無名関数を作れるのがメリット

>>627
メリットどころか存在意義じゃね。

それなかったら何のためのラムダっちゃっていう

アウトーーーーーーーーーーーーーーーー！！

>>622
これってテンプレート型変換演算子でもつかってんのかな、と思って
実装を見てみたが正直意味がわからない

>>622
これってテンプレート型変換演算子でもつかってんのかな、と思って
実装を見てみたが正直意味がわからない

まさかの二重投稿……orz

まさかの二重投稿……orz

どうせなら、

まさかの二重投稿……0x

と、こうコンパクトなorzでｗ

0x0 0w0

>>599
シグネチャが分かっているならstd::function<>を使えばいいのではないでしょうか。

lambdaと互換性あるのけ？

なけりゃこれができん。

template < typename T >
void f( T t )
{
t() ;
}

int main()
{
f([]{}) ;
}

>>639
シグネチャが指定したい場合はどう書けばいいの？

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

ん？横やりだからよくわからないけど
>>599 は引数で lambda 関数を渡すときに template 使いたくないって話だよね？

// f は非template関数
void f(std::function</.*なんか*/> &a) {
a();
}

f([]{});

と書けるってこと？

関数ポインタに代入できるようにする提案が出てんじゃなかったっけ？
少しコストはかかるし、ラムダの寿命を越えるとダングリングポインタになるけど、
実装可能ではあるよ

>>642
それはできない。prvalueは非constな参照では受けられない。
まあ、単なる間違いだろうけど。

void f( std::function<void ()> const & a ) ;

あるいは、f()を以下のように呼び出すか。

std::function<void ()> a = []{} ;
f(a) ;

結局>>641が何を言いたかったのかよくわからないです

>>644
ほー、そんな書き方ができるのか
便利だな

属性って採用されるんだろうか
あまりにも文法キモいんだけど

typedef int aligned_int __attribute__((aligned(128)));
こういう文法を使いつづけるほうが良いと？

#pragma みたいに、どんなのを用意するか処理系次第ってんならいいんだけど、
規格で属性を提供されてもね
そういうのはキーワードにして欲しい

その気持ちはわからなくもない

overrideのような文法上意味があるものはキーワードのして欲しいな。

overrideとかfinalとかalignとか
キーワードでいいじゃんと思う
キーワード増やしたくないのは分からなくはないが

>>648
属性でそれがすっきりになるのか？

記述が変わるだけだな

迷い猫Ｏｖｅｒｒｉｄｅ

auto はっぴぃ = new にゃあ();

オーバーロード
オーバーライド
オーバードライブ
オーバーフロー
アンダースコート
の違いがわかりません

[[align]]はC1Xとの互換のためにalignas復活させろって提案が出てるね

>>656
識別子に日本語使いたいなあ、C#が羨ましい

vc++で使えるじゃん

識別子に日本語使ってる人とは仕事したくねえな…

C1XはC++0x以上に普及しないと思うがなあ
alignas復活するのならどうでもいいけど

>>660
class にゃあ
{

日本語識別子はタイピングコストは高いわ
誤字見つけにくい場合があるわで最悪だ

なんだって！


class にゃあ
{};

VS10マジで使えるよ。これは活用せねば。
c++0x構文がでふぉでイネーブルとかvs10気が利いてるなあ。

>>661
C#で漢字使えるから活用しようと提案したら、0.1秒で却下された。

0.1秒も検討してくれたのか、凄いな

コンパイル通らないと思ったら字体が違ってた

神経の伝達速度を考慮に入れよ

提案を最後まで述べる前に却下すればいい

ようギルバート

class 二ダ一 { ... };

ニダー ウり;

日本語みたいな入力が面倒くさい言語で
プログラムなんか書いてらんない

現時点でC++0x使ってるプロジェクトって何かある？

流石に気が早すぎるだろ

帳票の名前とかGUIのボタンの名前とか法律用語とか、日本語の方が分かりやすいものは使ったらいい。
送り仮名などの表記揺れは困るので、無理に ASCII 外の文字を使う必要はない。

ボタンの名前とかころころ変わるし
無理に同じにしなくても

>>661
＞識別子に日本語使ってる人とは仕事したくねえな…

class おまんこ {
public:
　void insert(Foo f);
};

ｺﾞｸﾘ・・・

void おまんこ::insert(Foo f)
{
if (f.resNo() == 678) { cout << "うんこを突っ込まれた方がまし"; abort(); }
}

flushすらしないでabortとか

心の声ってやつだな

>>676
COBOLの二の舞になるぜ。
あれはローマ字だけど。

そうか。ログに残さずソフトに本音を出させたい時にはこうするのか。

バッファリング無効になってたらどうすんだ

心の声だだ漏れってやつだな

VC10はデフォルトムーブコンストラクタには未対応なのかな？

先月のドラフトで導入されたばっかだしさすがに無理だろ

assert(false);
と
abort();
って、効力的には同じでしょうか。
両方ともデバッグビルドで有効で、リリースビルドで消えますか？

abort()がリリースで勝手に消えたら怖いよ

あ、ではabort()は消えないんですか。
知りませんでした。
ありがとうございます。

assertの引数の式はreleaseでは評価されないので正解だった？

なぜ消えると思ったのかそっちの方が知りたい

正確にはNDEBUGマクロが定義されている状態でcassertをインクルードしたら
assertの引数の式が評価されなくなる、が正解

assertとabortが似てるからじゃね
字面が

いろいろごっちゃになってました。
失礼しました。
しかもNDEBUGマクロとか初めて知りました。
確かにISOの規格書をNDEBUGで検索するとはっきり書いてありました。

済みません。

assertの引数に副作用のある式を書いてハマるとか

可変個テンプレート引数で侵入式のスマポが作りやすくなったとか
そういう話は無いの

>>697
可変個テンプレート引数は変態御用達なだけでしょうな。

>>697
可変個テンプレート引数は変態御用達なだけでしょうな。

そんなに重要な事なのか

引数の数が違うだけのテンプレートを何個も定義する方がよっぽど…

未だに可変個テンプレート引数をどう活用するのか分からない俺が居る。

未だに可変個テンプレート引数をどう活用するのか分からない俺が居る。

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

カウントする部分は今はどうでもいいから書かないけど
こういう事はできるのかい？

できるよ
コンストラクタへの引数丸投げなら標準がやってる
std::make_sharedとか

それでもboost::intrusive_ptrが規格に入らなかったのには何かあるのかな

>>706
その前にregexが採用されてxpressiveが採用されないとか,
boost::scoped_ptrが何故採用されないのかとか
結構 言いたい事はあるよな。

やっぱ歴史が足りないんじゃないの？

>>704 だと weak_ptr が実装できない（たぶん）ので、ちょっとした相互参照でどうしようもない
メモリリークになってしまう。

scoped_ptrがないのはunique_ptrがあるからじゃない
つか名前変えただけというか
xpressiveは技巧的すぎたのかねえ

intrusive_ptrからweak_ptrは元々作れなかったかと

C++0x は、というか C++ 標準化委員会の連中は
C++ に Template metaprogramming を補強する
新しい機構をどんどん導入しているわりには、
Template metaprogramming で書かれた boost ライブラリを
採用しようとしない様な気がする。

特に xpressive, それ以外にも・・・ねぇ。

>>706
intrusive_ptrはshared_ptrに対してメリットが少ないし、共有系が複数あると面倒だからじゃないか。

>>711 妄想は頭の中だけで済ませとけよ。

他の言語もしくはC++自身の別実行レベルでメタプログラミングしたい

valarrayみたいなものもあるんだし
少々あってもいいじゃん

>>711
テンプレートメタプログラミングは標準にするには敷居が高いでしょう。
enable_ifぐらいなら単純デメリットも多いとは思うよ。

>>716
×単純デメリットも
○単純でメリットも

いや、メタプログラミング関連は山ほど追加されてるんだが。何言ってるんだお前ら。
20.7 Metaprogramming and type traits

俺も一応そう申し上げているんだけどね。

テンプレートプログラミングと、テンプレートメタプログラミングの境目ってどこ？

主な処理を実行ファイルがするかコンパイラがするか

>>720
> テンプレートプログラミングと、テンプレートメタプログラミングの境目ってどこ？
前者が本来想定されていた使い方で、
後者は仕様の隙間を付いた本来は想定されていない使用法。

>>720
プログラムの動作に対するプログラミングか、プログラムコードに対するプログラミングかの違い。

テンプレートメタプログラミングは
コンパイル時に動作するプログラムのようなものと考えれば良い

テンプレートメタプログラミングはチューリング完全ですか?

>>725
一定の制限があるがそれを忘れていいなら
チューリング完全であることは証明されている。

というか、再帰回数に問題がある点を除けば、関数型言語だよな

ある程度はconstexprで置き換わるのかな

>>727
上限がないと本当にコンパイラが停止問題を解かなければならなくなるから
制限が付いてる

>>729
そういう理由なの？
最低限アテにしていい回数を保証するためじゃなくて？

案外その条件が厳しいんだよね。
確かそういう制限一覧ってのがあったな。

Recursively nested template instantiations [17].
うわぁ、もうちょっと頑張ろうよ。
せめて255とか、現実的に問題になりにくそうな数字にすれば
良いのになぁ。




ISO/IEC 14882:1998(E) -- C++ -- Implementation quantities
ttp://www.kuzbass.ru/docs/isocpp/limits.html

>>730
> 最低限アテにしていい回数を保証するためじゃなくて？
それもある。
というか2つの側面がある。


17と定める事により、コンパイラ実装者は17までで作ればよくなるし、
ユーザーも17まではネストできると信じて作れる。


規格とはユーザーとコンパイラ実装者の間の決まり事だから。

>>731
最新のドラフトでは超パワーアップされてるよ。
> Recursively nested template instantiations [1024].

コンパイラ作者泣かせだなw

C++コンパイラ実装者は実質４つのコンパイラを作成する必要がある。
C++、プリプロセッサ、テンプレート、アセンブラ。

s/コンパイラ/トランスレータ/

プリミティブ値の国境付近に近づくのは愚行と喚き散らす奴が
テンプレートの事に成ると平気で越境してあーだこーだと不満言い出すのはナゼ？

17回の再帰でも、コンパイルがまともな時間では終わらなくなるサンプルがあったな

>>737 もう少しわかりやすくたのむ。

>>737 多分両者は別人だと思う

ところで C++0x の規格で、日本発の提案ってあるの？

重箱の隅をつつくような議論しか目に付かないのだけど

日本人はケチを付けるしか能がないから

C++0xに準拠したコンパイラが楽しみですね..＾−＾..

>>741
俺ってこんなに頭がいいんだぜ、ということをアピールしたいだけなので、
「言う側」にだけなれて、決して「言われる側」になることのない場所からしかモノ言いません。

動く人は誰にも何も言わず黙々と自分の道歩いちゃうので目立たないとも言う
そしてそういう人は逆に協調性が無いので他人との共有に無関心だったりする

Defect reportならたまに日本人ぽい名前も見るな。

>>742, >>744
そんなに日本人の足を引っ張るようなこと言わんでも…
まさに日本人の敵は日本人だなw

自虐民族乙

だって日本NBのコメント見てみろよ
イギリスやドイツと比べてみろよ本当にひどいから
クレクレと重箱の隅つつきばかりで建設的なコメントが一つもない

で、そいつが錦の御旗なの？
背中から撃ち続ける気満々だねえw

と、こういう場所では上から目線全開で食い下がる。
でも肝心な場所では子リスのように震えているだけ。

どうでもいいけど0xは余計コンパイラ開発者側に優しくなくなったのはどうにかならんのか。

どうでもいい

どうでもいいことでしたねすみません。

>>749
じゃあ、自分でNBコメント出したり、アドホック会議行ってこいよ。

NBコメント：ttp://cpplover.blogspot.com/2010/04/cfcdnb.html
アドホック会議：ttp://homepage1.nifty.com/herumi/prog/cppwg.html

>>755
面白そうだな。これ傍聴とかできるの？

>>657
> オーバーロード
過剰に流しこむ→元の加えて、他のが増える

> オーバーライド
上にかぶせる→元のが見えなくなる

> オーバードライブ
過剰に駆動する→元以上に頑張らせる

> オーバーフロー
超えて流れる→溢れる

> アンダースコート
エロス

>>756
去年、CDがでたときにも、まったく同じことをやっていた。
ただ、もうFCDなんで、クレクレはできないよ。
typoとか矛盾点の指摘とか、重箱の隅をほじくるようなことしかできない。

アドホック会議は、こうして一般から集まったコメントに対して、議論して、
日本を代表して出すコメントを決定する。

基本となる仕様の、重箱の隅をつつくことは悪いことではないが。

それとは別に、何か新しい言語仕様/仕様拡張に貢献した例とかはないのかね？
という疑問でした。

秀才さんたちには、新しい物を作るのは不得手なんだなぁということでしょうね

ものを作る秀才はどうなのよ。
秀才を「調べるのに手一杯でどうにもならない駄目人間」だと勘違いしてないか？

新しい言語仕様を提案するのはほとんど政治力の問題であって
問題点の洗い直しこそ開発者・言語研究者としての能力を要する点なのだが

あら、触れちゃいけない点に触ったかな？

>問題点の洗い直しこそ
じゃそういった研究はやっているんですね？
けど、問題点を解決する提案は出せない。ということですかね？

政治的というより、コンパイラ作成に携わっている人が（ほとんど）いないことが原因でしょうね

>>762
>けど、問題点を解決する提案は出せない。ということですかね？
出てるが、出てることが理解できないというですかね？

秀才がどうとか言ってる奴はただのルサンチマンだろ

でてるんだぁ。
けどドラフトペーパーに日本人の名前あったけ？

美少女中学生がドラフト出すようにならないかなあ
そしたらがんばって実装するのに

中学生「かわいくないし意味わからないから、ラムダ廃止にして！」
グラマー「え！？」

>>759
秀才ごときがどれだけ束になっても759の足元にも及ばないと豪語しているわけですね。

結局、日本からの貢献は無い。ということですか。
中国はあるのにねぇ
国力の差か。

各個人にオープンな貢献の場が与えられているのに国のくくりでものを考える意味がわからない。

C++0x自体多くの人には不要だから仕方が無い

C++0xのキラーアプリケーションって何かな

>新しい言語仕様を提案するのはほとんど政治力の問題であって
なんだから、仕様提案ができないのは、政治的発言力が無い証拠だよなぁ。

大学で gcc の派生コンパイラとかまではザラにあるけど、
まともな提案を作って、働きかけて、物にすることができる人はいない。
レポート出したらそれっきりだしね。

某 ML のオフ会でも、たまにこの話題が出てくるけど、何もできないね。でオチついて終わり。

C++0x で次世代のコンパイラを開発しよう。

>>773
仕様提案といえばEmbedded C++があるじゃないか。
これがトラウマになって今の状況を招いたのだったりして。

Embedded C++0xでリベンジを

Embedded C++0x.

decltypeは、難しすぎて俺らには実装できないし、そもそも新しすぎて俺らには使いこなせないので却下。
autoは、難しすぎて俺らには実装できないし、そもそも新しすぎて俺らには使いこなせないので却下。
Variadic Templateは（ｒｙ
lambdaは（ｒｙ
scoped enumは（ｒｙ

こうしてalignofと[[align]]だけが残った

>>777
ようやく普通のテンプレートが入るならそれでもいいけどなｗ

テンプレートはコードが膨張するので
Javaのgenericsみたいなのが入ります

そこで明示的なインスタンス化ですよ

>>778
alignas でいいじゃないですかぁ

>>780
JAVAのげねりっくの正体はキャストって聞いたけど本当？

むしろJAVAのCASTがGENERIC

>>782
そこは戻ることに気付かずにC++0xともC1Xとも互換性失った方がEC++らしい

互換性といえば、>>1の一番上のサイトのSC22→WG14でCの委員会サイトに
行けるんだけど、あっちもあっちでC++0xとの同期を意識しているんだよな。

そりゃC++98とC99の時みたいな間抜けなこと繰り返したくないでしょ
お互いに

「Cに」GCとクロージャを提案してるアホもいるけどな

>>788
GCはともかくクロージャは並列プログラム等いろんな所で有用だし、
既にAppleは実現させてるでしょ。
http://blog.8-p.info/2009/09/gcd-1

>>789
Apple拡張のクロージャは「GCはともかく」というよりGCありきでしょ
というかクロージャなんてオブジェクト機構を伴うことが前提なんだから
明らかに「Cのカバー範囲」を逸脱しまくってるだろ
ObjCがアレだからCのレイヤに二重実装してケツ拭かせますと言っているに等しい

MacOSXは10.5からObjective-CにGC入ったけど
もしかしてOS自体がGCサポートしてんの？

Apple 用の CPU は、アセンブラレベルで GC をサポートしているんですよ > 791

Apple用てWindows用と変わらんで

>>792
ちょｗ何を言い出すんだｗ

Appleのブロック構文はGC使わず、参照カウンタでも動くけどな。
ブロック自体にretain,releseかますし。

つーかなぜにAppleはクロージャをCに入れようとしたんだろう
構造体とフル機能のクロージャがあればそれだけでオブジェクト指向言語になってしまうので
「Cの」拡張としては恐ろしく筋が悪いものに感じる
インラインで「関数が」書ける機能ならCらしくて分かるんだが……

そもそもObjective-Cの拡張としなかった理由がよく分からんなぁ
どっかで「Cの拡張ならBSDカーネルに取り込める」とか強弁してた奴がいるけど
Cの「独自」拡張を使ってカーネル書くくらいならまだObjective-Cでカーネル書いた方がマシだろうと

Obj-C (.m) だけで使えるより C でも使えた方が単純に考えてお得じゃない？

ECMAScriptにclassを独自拡張した某言語に胸熱になったのを思い出す

あ、いいこと思いついた。
C++0xの機能を全部C1xにバックポートすれば、超便利な機能がCでも使えて単純に考えてお得じゃない？

おまえてんさいだな

Obj-C用に実装したけど
Cでも使える構文になったから
Cでも使えるようにしちゃえ

でしょ。どうせ

>>801
AppleクロージャはObj-CのオブジェクトじゃないからObj-C用に設計したものではないよ
Obj-C用に設計しようとしたがあまりにパフォーマンスが悪くてObj-Cと切り離さざるを得なくなった
という方が実態に近いと思う
でもオブジェクト機構と乖離したクロージャって物凄くいびつだと思うんだが
ああいうのって世間の言語設計者的にはOKなんだろうかね

>>801
Obj-C で完結する部分には元々のブロックで充分じゃない？

>>802
逆じゃない？
オブジェクトは貧者のクロージャで、環境を文脈として保持するのが本来のクロージャでしょ。
だから Obj-C の blocks も微妙じゃないかな。

>>803
環境だってデータなんだから、クロージャはデータを持った手続きであって
つまり表面上、データが主で手続きが従か、手続きが主でデータが従か、の違いだけで
クロージャはオブジェクトの一種というか表と裏のような概念。
実際オブジェクト指向言語におけるクロージャはそういう概念で設計・実装されてる。
Javaの無名Runnableなんかは明らかにオブジェクト寄りのクロージャで中間概念として分かりやすいんじゃないかな。

頭に isa 付けてりゃObj-Cのオブジェクトになる訳で。

>>805
そういう問題じゃないだろｗ

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

必要っちゃ必要なのかなぁ
ぶっちゃけGCDはjava.util.concurrentの簡易版みたいなものだから
クロージャ無いと無理というわけではないと思われ

BSDがカーネル内でBlocks使うって噂もあるけど
独自拡張使ってカーネル書くのは正直それってどうなのって気はするな。

カーネルこそコンパイラの独自仕様に頼らざるを得ないだろ
LinuxカーネルなんてGCCに依存どころかほとんど癒着してるぞ

そりゃLinuxのお行儀悪さの発露であって。
処理系依存なコードは必要最小限に抑えるのがまともな実装。

>>810
頭の中に花畑があるようですね

あれ、LinuxってGCC独自拡張の文法とか使ってるんだっけ?

丁度良さげなのがあったので貼っておく
http://www.ibm.com/developerworks/jp/linux/library/l-gcc-hacks/

>>813
全体的に代替マクロで潰せるものが多いね
範囲caseとゼロ長配列は冗長だけど標準で書けるんだから標準で書けとは思った

ロジック的に完全にGCCに依存してそうなのは定数判定かな

>>814
> 全体的に代替マクロで潰せるものが多いね

どうやって？　どれ一つとしてマクロで出来る様には思えなかったけど。

>>814
御託はいいから置き換えて晒してみろよ

まさか・・・　ExcelにおけるVBAのような脳内マクロをイメージした発言では・・・・ｗｗ

マクロで「潰す」と言ってるんだが
最適化ヒントは全部空文字列と置換可能だろ

・型検出
　この機能自体は大抵のコンパイラでマクロ使ってエミュレート可能かな
・範囲拡張・ゼロ長の配列
　gcc拡張使えば楽になるのは分かるけど、こらえてベタ書き汁
・呼び出しアドレスの判断
　スタック辿れば可能だが、こんな情報は引数で渡すべきじゃないのか
・定数検出
　これは専用の文法ないと厳しいかな
　全部定数でないと見なして最適化を諦めることは可能だけどパフォーマンスすごく悪そう
・関数属性
　各コンパイラごとに存在するならそれに置換、無ければ空にすればいいだけ
　よくある話
・最適化に関する拡張機能
　上に同じ

下2つはVC/GCC両対応コード書く時とかマクロで切り替えるの常套手段だと思うんだけど
>>815がなぜ「マクロで出来るように思えなかった」のかがむしろわからんなぁ

無理矢理スレの趣旨に戻すと
Blocksさんに比べれば我らがラムダさんの制服の柄は許容範囲
という認識でよろしいか

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

>>804
Scheme や Smalltalk や ECMAScript などのクロージャが物凄くいびつだと。

>>819
お前が夢ばかり見てるオバカさんだってのはよくわかった

>>822
その辺はむしろクロージャこそがオブジェクト機構の主体なんだから一貫してるよ
ECMAScriptにclassを更に足してしまったActionScriptはいびつと言っていいと思う
Blocksは「Cを単体でECMAScriptのような言語にする」機構なので
Objective-Cとして使われることを前提とした拡張だとむしろActionScript状態に近い

具体的に全く反論できないのでレッテル貼りしかできないのですねわかります

>>825
え、どの辺が具体的じゃない？
ScmemeやECMAScriptはクロージャ機構からオブジェクト機構が導出されている
C++とかJavaとかRubyとかはオブジェクト機構があってそこからクロージャが導出されている
Objective-C with Blocksは、Blocksというクロージャ機構があり、かつそれと直交したオブジェクト機構を持つ
そんなに難しいことではないと思うけど、分かりにくいとこある？

>>826 >>825 は >>823 に対してだと思われ

>>826 が何気に他人の反応気にしてるのがわかったｗ

>>828
いやめっちゃ分かりやすく書いたつもりだったので衝撃を受けただけ
>>827ってことなら気にせんでくれ

>>819
スタック辿ればとか言ってる時点で処理系依存しまくり
引数とかいうがプログラムカウンタをアーキテクチャ依存無しで取ってみろ

似たものが直行する概念として実装されているのがどうしていびつなのか
具体性に欠ける

直交の意味から説明しないといけないほどのバカが一人で暴れてる模様

>>824
Smalltalk は違うよ。
というか、クロージャでできることは全てオブジェクトでできるけど、クロージャを欲しがる理由はオブジェクトとは関係ない。
そして ECMAScript 的なクロージャは元々あるブロックを使えばいい。

>>833
smalltalkはRubyと同じで、というか由来的には逆だけど
ブロックはオブジェクト機構の枠内にいるよ
ブロックとオブジェクト機構が直交した独立の存在にはなってない

Rubyの場合は、ブロックを表現するProcというクラスもあるけど、
それがブロックそのものではなく、オブジェクトにはなってない。

>>835
Procはオブジェクトだぞ
ちょうどC++0xのlambdaで返るfunctionと同じ立ち位置

誰かC++学園的に各言語のクロージャ、ブロックを例えてくれよ。
話しについて行けない。

>>836
Procはオブジェクトなんだけど、ブロックがすなわちProcではない。

def foo &c で、ブロックを変数に入れるか、引数なしで Proc.new を呼ぶと、
ブロックからProcのインスタンスが作られる。

>>838
今君の言ってるところの「ブロック」って「構文木」のこと?
普通ブロックとかクロージャとか言う時は、
キャプチャされたローカル変数とコードの組み合わせのことであって、
構文木のことは指さないんじゃない?

>>839

def foo
　yield
end

def bar &c
　c.call
end

foo{p "foo"}
bar{p "bar"}

これを実行した時、p "foo"に相当する「キャプチャされたローカル変数とコードの組み合わせ」は、
Ruby処理系内部のデータ構造としてしか存在していない。
p "bar"のほうはProcのインスタンスが作られる。

>>840
それは論理的にはProcインスタンスが匿名かどうかの問題でしかないぞ

これまで出てきている「ブロック」というのは、もともとはSmalltalkローカルの用語で無名関数のこと。
Smalltalkのブロックは、クロージャーで実装されていることが多い（が、そうでない場合〜エンクローズされていない〜もある）。
Rubyのブロックや Objective-C の Blocks はこのSmalltalkのブロックから名前を借りたもの。
Rubyのブロックは、ファーストクラスオブジェクトでも Ruby のオブジェクトでもない。(840の言いたいこと）
Rubyのブロックをオブジェクトとして扱えるように用意されたのが Proc クラス。

>>842
んっとね、Rubyのブロック構文は基本的にProc(など)の定義であり
そのProcインスタンスが外部から可視であるかは問題ではない
というのが>>841で言いたかったことね。
この点は言語設計として一貫してるよ。smalltalkも基本的にそうでしょ。
#もちろん最適化の結果、内部でいつの間にかショートカットされてることはあり得る

クロージャというオブジェクトとは直交した全く別の構造があって
Procというインターフェースから間接的にアクセスできる
という論理構造"ではない"

でもApple CのBlocksは当然根本的にObjective-Cのインスタンスではない。
何故ならObjectiveじゃないCの中に存在している概念だから。
逆にBlocksが常にObjective-Cのインスタンスであるなら>>799を地で行くことになる。

実質的にはObjCの拡張であって本気でBlocksをC1Xに提案していく気はないでしょ
あんな__付きまくりなものに仕様的整合で目くじら立ててもしょうがないしスレ違い

実際に存在してないものを「可視か否かの問題」にされたらかなわんわ

>>845
内部的に存在するが外部からアクセス手段がないことを「実際に存在しない」と言うのか

内部的に存在してるものはProcのインスタンスじゃないから。

iostreamとかpimplとか見たら発狂するタイプだな

Apple の Blocks は toll-free だけど、処理の実体は C に投げられてるから、Obj-Cの拡張言うかな？
NSBlock のサブクラス検索したけど、どれも変数持たないし。

>>849
ObjCとは切り離されてると思う。
ObjCのオブジェクトはパフォーマンスが悪すぎて
クロージャを表現するには正直きついので、
同種の機構を二重に実装するダサさは目をつぶってCに入れた、
という認識の方が実態に近いかと。

まあ[hoge retain],copyとかの為だけにObj-C クラスの皮被せただけだろうな。

Obj-Cのオブジェクトってそんなにパフォーマンス悪いの？
クロージャをオブジェクトのシンタックスシュガーとして扱えないほど重いってそれ自体がかなりむごい話に聞こえるんだが・・・

メソッドは関数呼び出しの3倍くらいの速度。

1/3くらい。

IMP呼び出し使ってC++のvirtualくらいの速度じゃなかったっけ?
staticな関数コールと素のmessage sendを比べると10倍どころでは済まないと思う

>>834
ブロックを辞書に格納することはできるけど、ブロックは辞書で表現されてないよ。
[|a|a:=10.[^a] value] の 内側のブロックから a を参照することをオブジェクト機構の枠内というのは強弁だと思うよ。

というか直行してるといびつだという理由を教えて欲しい。
コストの安いほうでいいじゃん。

>>856
何故に唐突に辞書が……

素朴な疑問だけどWebKitがC++である以上
Objective-CはObjective-C++として使われるのは不可避なわけで
lambdaをObjective-Cの中に置くことを最初から諦めるなら
最初からC++のlambdaを使えば良かったんじゃないのと思うのは俺だけ？

馬鹿？　ラッパしてある中身が云々とか、使う分には関係ないし。

>>856
論理的に包摂関係にあるものを全く別々の独立した2つの仕様として策定するのは、設計としてはダサいだろ。
一貫した仕様を定義し、最適化の過程で内部実装は切り分けられる、というのが基本。

あくまで原則論なので過去の負の遺産との整合上仕方ないこともあるし、いわんや独自拡張で何やろうと知ったことではないがな。

>>860
論理的に包摂関係にある、というのがさっぱり理解できないんだけど。
バナナで釘が打てるからバナナも金槌に包摂されると主張しているように聞こえる。
俺は、クロージャとオブジェクトは、たまたま一部について同じことができるだけの別物だと思う。

>>861
オブジェクトとクロージャは「たまたま一部について同じことができる」なんてレベルじゃないだろ。
バナナが存在するところにリンゴを追加する際に、果物クラスを作らずリンゴクラスが独立して作られて、バナナとリンゴは違うだろ、と主張しているように聞こえる。
それどころか青リンゴと赤リンゴくらいの関係じゃないか。

>>862
理解できないと言っているのだから説明してよ。
包摂関係とはどういうことかの説明じゃなくて、オブジェクトがクロージャを包摂するということについてね。

860 の「論理的に包摂関係にある」ということは、論理的に説明できるんだよね？
包摂関係にあることの確認を、論理的に行えると考えていいんだよね？


あと、バナナの話は凍らせた時の話で、殺伐としすぎないようにジョークで出したのだけれども、場違いだったようで失礼。
http://www.youtube.com/watch?v=Po_B6SHWUdI

オブジェクトとクロージャは片方がもう一方の全てを満たすことが可能である以上
包摂関係と言うと語弊があると思う
むしろ同じものの表と裏と言った方が概念的には正しい

何だ？　一行目と二行目が……

流れを読まずに書き込むが
オブジェクト⊃クロージャじゃないの？

「オブジェクト」の定義がよくわからんが、どうせ
「データと手続きを一緒にしたもの」ぐらいだろ？
なら、そういう包含関係にならざるを得ないと思う

クロージャはレキシカルスコープと密接に絡んだ概念だから、（より一般的な）
オブジェクトより狭い概念だと思うけど？

>>864
了解した。
その上で、
1) 表と裏であることを示してくれ
2) 表と裏である機能（性質？ 事象？）を、独立した別々の機構として策定するのがダサい理由を説明してくれ
　　虚数表現とか表色系とか、いろいろあると思うがどうだろう
をお願い。

>>866
クロージャでできることをオブジェクトで行うことはできる。
が、ローカル変数を含めたレキシカルスコープへの参照を束縛するという機能なり概念なりはオブジェクトにはない。
クロージャの概念のほとんどをオブジェクトが持つといっても反対はしないが、全てではない。
クロージャが持ち、オブジェクトが持たない概念が存在する。

ちなみに俺は、同じことができるだけで別モンだと思うけどね。
金属バットとバールのようなものくらい違うと思うよ。

>>867
よくわからんけど、あんたの言う「オブジェクト」の定義って何？
「クラス」の話？

>>866
実際にJavaScriptとかLisp系とかはクロージャでオブジェクトを実現しているよ
理論上は得意不得意の違いだけで扱えるスコープは同じになる

補足
　扱えるスコープ→扱える「問題の」スコープ
です
このため、片方が存在すれば、もう片方は単なるシンタックス上のトリックとして扱えます

>>869
あのね、
俺はオブジェクトのほうが広い（曖昧な）概念で
クロージャは、より狭い概念だと言ってるんだよ

出来ることの差なんてそりゃ無いが、概念の広い狭いとは全然関係ない話だろ

>>871
うーん、それはどうだろう
C++的な立場から見るならそれで合ってる
コンピュータ上での実際の動作という意味でもその方が実態に近い
でも関数型的な観点で言えばクロージャの方がよりプリミティブな概念になっちゃうんだよね
だからどっちが広いとか狭いとかいうよりも「表と裏」なのだと思う
多分オブジェクトの方が表なのだろうけど

>>872
んーそれじゃ、あんたの「オブジェクト」の定義は何なの？
俺の定義は>>866でしかないから、紛れも無くクロージャは「オブジェクトの
一種」でしかないんだけど

「オブジェクト」は別にレキシカルスコープと関係なくてもいいし
データは環境でなくてもいい
だからクロージャはより「狭い」

>>873
ん、俺の定義も>>866と変わらんよ
…ところで俺は「オブジェクトとクロージャは直交してる」と言い張ってる人とは別人ですよ……？

>>874
あ、そうなの？その定義なら
オブジェクト⊃クロージャ
は自明というか、論理的にそうにしかならんでしょうに

>>875
いや、関数型の世界では手続きは情報を持っていることが当たり前で
オブジェクト的なものはその一種でしかないんだわ
だから君のような考え方はC++の観点では自明なんだけど
一方で関数型の世界では「クロージャの概念がオブジェクトの概念を内包している」ことになる

手続き型と関数型があってどっちが内包するわけじゃなくてどっちもチューリング完全だよねみたいな感じ
実装は通常最終的に手続き型で行われるからマシンレベルで最もプリミティブなのは前者ではあろうけど、と

>>876
いいたいことは分かるが、論理的に全然包含関係の否定になってない気がするが

否定したければ、非オブジェクト的なクロージャが存在することを示すしかないぞ
無いでしょ？
一方、全てのクロージャは>>866の定義なら自動的にオブジェクトだし
それは関数型だろうが変わらんでしょ

ごめん変な書き方になった

全てのクロージャはオブジェクトである
クロージャでないオブジェクトは存在する
ゆえにオブジェクト⊃クロージャである

というのが俺の論理なので、否定したいのなら最初の奴の反例出すしかないんじゃ
ないのって話ね

お前誰よ？

俺は>>866

俺は>>881

>>878
オブジェクト＝クロージャ
なんじゃね？
>どっちが広いとか狭いとかいうよりも「表と裏」
とか書いてるし

>クロージャでないオブジェクトは存在する
を否定する根拠があるかどうかは俺は知らん

>>877
うーん、非オブジェクトなクロージャってのは難しいな
一応逆の観点で見ると
オブジェクトのconstructは引数による明示的な束縛に他ならないし
メソッドの実行もプロパティの読み書きも関数型的には関数(手続き)実行に他ならないから
概念的には逆に全てのオブジェクトもクロージャであることを満たすんだよね

実際クロージャ指向な世界ではそういう扱いをしている
うん、変態的だとは思う

ぶっちゃけお前らが何をいってるのかよくわからん。
クロージャといえば、その場の自由変数をbindできて、Callable(operator()が使える)である必要があると思うが、
Haskellみたいな言語でもすべてのオブジェクトがCallableであるとは限らないだろ。
data Point = Point x y と定義して、Point 1 2とかするとオブジェクトが生成されるが、これはCallableか？

>>883
うーんSchemeあたりでオブジェクトっぽいのを書くときにそうする、というのは
分かるけどねぇ
関数型でない言語にまでその議論を広げるのは無理がない？

レキシカルスコープとクロージャを提供してるけど
クラスも提供してる言語はいくらでもあるし
それらの言語では、クラスオブジェクトとクロージャは別物だから

>>885
クロージャとクラスを提供していて、論理的に全く分断された扱いがされてる言語ってどんなのがある?
ActionScriptがそんな感じになってるんだっけ?

PHP(ゴクリ

>>886
論理的に全く分断って意味がわからんけど
C#とかPythonとかScalaとか、いくらでもないか？

それらの言語のクラスを、普通の意味でのクロージャとは見做せないと思うけど

ああクロージャ＝オブジェクト論では
クラススコープの変数を、レキシカルスコープの自由変数と見做すのか

なんとなく意味は分かったｗ
なるほどね

>>888
その辺の言語はクラス指向で、クロージャは単純にクラス機構の下位に属してるんじゃ？

>>889
ちょうどオブジェクト指向言語でクロージャを表現するのと逆方向だな
レキシカルスコープの束縛はコンストラクタでのインスタンス変数へのコピー・参照
C++0xのlambdaをC++で書こうとするとまさにそうなるｗ

>>890
よくわからない
「クロージャではないオブジェクト」が存在する例がクラス指向の言語だと、
何か問題に影響するの？

>>892
なんの問題の話をしてるのかよく分からんが
ほとんどの言語は
・クラス指向の言語でありクロージャはクラスである(オブジェクト指向言語、多数派)
か
・クロージャ指向の言語でありクラスはクロージャである(一部の関数型言語、少数派)
のどちらかで、クラスとクロージャが「別物」の言語はそうそうないのでは

PHPとかはそうなのかな?

クロージャがクラスとか、クラスがクロージャなんじゃなくて、
クラス機構もクロージャ機構もオブジェクト機構の一部であって、共通する部分もあるってだけなんじゃないかな

>>893
Pythonはオブジェクト指向言語だけど、全ての型がclassかというとそうではない
クロージャの型はfunctionで、functionはファーストクラスオブジェクトだが
classではない

>>889の見立てを行ったときに、クロージャと同じものと見做せるのは
class objectではなく、bound methodだと思う

Perlはクラス指向でもクロージャ指向でもなくて
どっちも持ってる

そろそろスレ違い

つまりラムダさんかわいいよラムダさん、ということでまとめとこうぜ

あんまりそわそわしないで。　あなたはいつでも話脱線しちゃうけど
スレタイ見てよそ見はやめてよ。　ラムダっちゃ。　　ってことでここは一つ

次スレは10だよ派といやAだろう派による
ねっとりした論戦が始まります。

ラムダ、auto、右辺値参照、progress_display
個人的に大いに期待する４大新機能


おまいらどう？

progress_displayたんともあろうお方が…(´;ω;`)ｳｯ

誰もがぱっと恩恵受けられるのはautoだろうね
autoのためにC++0xを使わせて貰える現場があるのかは知らん・・・

>>904
auto は待ち遠しいねえ。　GCC 4.4では使えるが、まだ許されるのはGCC 4.3まで。

昔のautoちゃんはもういないのかな...

○Blocksさん
遠く青森で林檎に囲まれて育ったラムダさんの親戚。帽子が特徴的。

>>904
右辺値参照は標準ライブラリが対応するだけで、ソース書き換えなくても自動的に恩恵が得られる。

vectorにunique_ptrが入るようになるだけでもマジうれしい

>>906
VC10だとオプションで復学可能

>>904
autoとバリアントの区別がつかない人が拒否反応起こして困る。

>>911
昔は「そんなんいねーだろ！」とか思ってたけど、いるみたいだねぇ。
C#の記事で、varとバリアントを混同する人が結構いる、という前提の説明を見たことがある。
当然C++のautoでも出て来るんだろうね・・・。

やべえ、最近書いたコードはautoがずらずら並んでいるが問題ないよね？

auto a = 1;
a = "Hello"; //エラー

「なにこれマジ使えねー」

#define auto_type_affirmation auto

0xオプションつけると
auto int x = 4;
がもう通らない。

完全に別人やな。

auto<int>とかfoo<auto>みたいな文法が
採用される夢を見た

auto<auto>

胸が熱くなるな

>>918
テンプレート引数を取る識別子は型そのものではないのだからautoでそれを示すのは不可能なんじゃないか

誰も可能だなんて言ってない

return auto;

むしろfoo<auto>だろ。

vector<nagai_namae_no_type> hogehoge;
///...
hogehoge.swap(vector<auto>());

T<auto>は出来るように提案されてたよね?
std::pair<auto, auto> = make_pair( T(), U() ) みたいの。
g++, vc2010 で出来るか知らないけど

D の !( みたいに専用の括弧が無いから、auto<T> みたいのをやるなら
template であることを明示するとか?
vector<short> a;
template auto<int> b = a;

>>923
関数テンプレートでもそれ欲しいな
foo<auto, int>(...); みたいな感じで、１つ目は推論とか

それでこんな文法も欲しいと思ってしまった
void foo(int a, int b = 1, int c = 1);
foo(2, default, 3);

defaultって書く方がめんどくさくね？
単純に省略じゃダメなのか
foo(2, , 3);

defaultはやめてくれ。そこ変数名書けるとこだろ
省略はtypoで追跡しにくいバグを生みそうだなぁ

デフォルト引数をそのまま使いたいのよ
よくあるっしょ？

>>928
defaultって名前の変数あったらどうするんだよ・・・

ごめん、ないな。忘れてくれ

foo(2, __, 3);

むしろ名前付き引数が欲しいな
foo(a: 2, c: 3);

[foo a: 2, c: 3];

v(9, __,9);

v(^・^)v

defoult:

>>925
using boost::optional;
using boost::none;
void foo(int a, optional<int> b, optional<int> c)
{
foo(2, none, 3);

>>937
{　はなしで

離すってことは・・・こうか！ありがとう！

void foo(int a, optional<int> b, optional<int> c)

　{

　　foo(2, none, 3);

再帰ということでいいんじゃないか

lambdaとbindの使い分けを教えてください

使い分けもクソも全然別物じゃないですか

lambda: 常に使え
bind: 忘れろ。ネイティブなlambdaがあれば必要ない。

struct { int a, b, c; } foo() { return { 1, 2, 3 }; }

みたいに戻り値の型のところで直接型宣言できたら
tupleより結果にアクセスしやすいと思うのだが
C++0xでできたっけ？　これ

イニシャライザーリストでできるのかなぁ？？

>>944
戻り値のところで型の宣言するだけなら現行のC++でも可能だと思うが。

g++ 4.2.1でエラーになったけど

main.cpp:7: error: new types may not be defined in a return type

struct A { int a, b, c; };
A foo() { return { 1, 2, 3 }; }

はC++0xで可能なんだよね？

auto x2 = []{ return { 1, 2 }; }; // error: the return type is void (a braced-init-list is not an expression)

これも微妙なんだが
戻り値の型をstd::initializer_list<int>にしない理由は何なんだろ

書いてある通りだろ。
braced-init-listはexpressionじゃなくて、initializer。
戻り値を省略した場合、returnから推測してくれるためには、lambdaは、

{ return attribute-specifieropt expression ; }

の形でなければならない。
expressionであるべき場所に、expressionじゃないものを書いて、なんでダメなんだって言われても困る。

アスペルガー

>>950
別に、braced-init-listの時はstd::initializer_list<T>に推測する、
というルールを入れればいいだけじゃない？

アクセッサ自動生成する指定子とか提案されてないんですか？

>>953
ないだろうね。
実装（メンバ変数）に基づいてインターフェース（アクセッサ）が決まるような、
設計の基礎に反するプログラミングをサポートするとは考えにくい。

traitsやconceptでメンバー変数も対象にするようにしないとなあ

その前にまずconcept自体を入れないと

引数なしの非explicitメソッドx(void)は()を省略してobj.x;に置き換えられる
引数ひとつのexplicit非指定のメソッドx(arg)はobj.x = arg;で置き換えられる
これを導入するだけでプロパティがらくらく定義できて気持ちイイのになんでやらないのか

>>957
C#使ってると、obj.Size()でエラーが出てたりして非常にウザイ。関数とプロパティの区別は面倒。プロパティはいらない。

デフォで省略可能なのはキモい
何かつけたら省略可能、ならいいけど

プロパティと勘違いしてげった関数の括弧を省略しても文法的には通るのが大きな罠だよ

通っても別にいいんじゃない

explicit指定では省略できなくすればその問題も解決

問題はゲッタ関数じゃないのにプロパティっぽく呼べる方じゃないか
全部explicitつけろとか勘弁

>>959
コンストラクタさんディスってんのか
implicit指定がなぜ無いのか理解に苦しむ…

ディスってるよ！

this

Intel Distel?

アクセッサとまでは言わんけど、メンバ変数をクラスの外からは読み出し専用に
出来る方法があればなあとは思う。

昔は欲しいと思ったけど、今は必要とは思わないし、無くてよかったと思う。

アクセッサがあったら実際の型とは別の型として評価したり、評価だけに副作用を入れる事もできたりと夢が広がるが
結局それはメンバとしてではなくて別の一般的な機能
（例えばfactory patternをそのまま組み込んだような、派生クラスの型を追跡できないのにインスタンスをポインタを介さずに操作できる何か）
として規定してしまったほうがスマートなんだよなぁ・・・。

あのねオブジェクト指向というのは、人間が自然に持っている、
物などを認識する時にあれは魚だとか、これは食べられるだとか
分類しているそれの事なんです、ので、ものすごく古い行為です。
俺はC++よりいい方法でオブジェクト指向を有効に使って
プログラミングできる言語を思案中ですよ、みなさん。

そうですか

C++「＾＾；」

>>968
まんまRubyのattr_readerじゃん

>>968
メンバをconstにしてprivateな雪駄内でconst_castして代入すればいい

>>975 未定義動作

メンバでもだめなんだっけ？

>>975
const_cast覚えたての頃にやったわｗ

>>975
そんなことするより、これでいいんじゃ
class foo {
public:
　foo() : impl(1), val(impl) {}
　void increment() { impl++; }
　const int& val;
private:
　int impl;
};

メンバに参照を持つのはだるい

参照は小粒でピリリと辛い

コンパイラに代入演算子が自動生成できんぞオラァって言われるしな

const_castって未定義じゃない使いかたってあるの？

>>983
未定義動作になるのは、生成時点で const な型を持っていたオブジェクトに対して
書き込みをしてしまった場合。

最終的に書き込みが発生しなかったり、生成時点で const じゃなかったオブジェクトに
対して書き込みが発生するぶんには未定義動作とはならない。

>>979
メンバの宣言は
private:
int impl;
public:
const int& val;
の順でやらないとまずくない?

はっきり言ってconst_castには0xで消えてもらいたかった。
規格から消すだけじゃユーザーが独自にtemplate関数とc style castで作ってしまいそうだから
javaのgotoみたいに明示的に締め出すくらいしてほしかった。

C形式のキャストを消すほうが先だ。

あんなのD組

D言語は関係ないだろ！

Cを超える者…それがDだ

DはD組送りで

DとC++では用途が違うだろ。
変数CをC++するのとchar moji = 'C';をmoji++するくらい別モノ

moji is 0x0.

>>986
const使わないで作るバカは多いから
const_castがないとそういうバカの作った関数などが使えなくなる
あとCOMはconstないから（ry

下のを実行すると
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;
}

[&]を[=]にするとできましたが、
コピーコストがかかる場合もあるだろうから嫌だ・・・。
1ってどっからきたんだ・・・？

>>996
[=]にしないと、もともとのmはスコープアウトして不定になるんじゃないかい？

次ぎスレまだー？　次はAなのか10なのか。

C++0x 10
http://pc12.2ch.net/test/read.cgi/tech/1275375522/

C++0x学園の人々は任せた。

スレ番まで10になってしまったか…

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。