5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

C++0x 9

1 :デフォルトの名無しさん:2010/03/27(土) 02:13:56
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/

2 :デフォルトの名無しさん:2010/03/27(土) 02:29:18
○禿
校長先生。
不老不死も研究していて、350年後に問題点を全て解決した新パラダイムのC++をリリースする事になる。
ただし頭髪は復活しない。

3 :デフォルトの名無しさん:2010/03/27(土) 02:33:23
C++学園の人々:0a年春の巻

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

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

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

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

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

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

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

4 :デフォルトの名無しさん:2010/03/27(土) 02:33:55
○initializer_listさん
「ねえねえ配列さん、なんでコンストラクタさんと仲良くしないの?」「新入生が来たら仲良くするよ!」
定番と化しつつあるこのやりとりの繰り返しで過剰な期待が勝手に高まりつつある。
本人はあまり何も考えていない。

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

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

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

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

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

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

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

5 :デフォルトの名無しさん: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さん達と一緒に弁当を食べようとしたら断られた。

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

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

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

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


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

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

7 :デフォルトの名無しさん:2010/03/27(土) 11:15:21
C++0F(2015年)までにリリース出来るんでしょうか?

8 :デフォルトの名無しさん:2010/03/27(土) 11:15:47
なんか知らんが乙!

9 :デフォルトの名無しさん:2010/03/27(土) 12:15:02
>>7
36(ry

10 :デフォルトの名無しさん:2010/03/27(土) 12:51:43
・progress_displayたん

11 :デフォルトの名無しさん:2010/03/27(土) 12:57:11
毎度毎度乙wwww

12 :デフォルトの名無しさん: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さんと仲が良いらしい。

13 :デフォルトの名無しさん:2010/03/27(土) 14:25:02
ばびょーん博士

14 :デフォルトの名無しさん:2010/03/27(土) 21:17:02
>>6
>lambdaさんとの区別は、帽子以外で判断すべきだと叫ばれている。
まあ、校舎が違うからいいんでないの?

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

16 :デフォルトの名無しさん:2010/03/28(日) 17:33:14
C++キャストと同じだよ
意図的に面倒くさくしてんだよ

17 :デフォルトの名無しさん:2010/03/28(日) 17:39:16
reference_and_const_cast<HOGE>(hoge)();

18 :デフォルトの名無しさん:2010/03/28(日) 21:50:05
先生質問!!!
lamda を返したときの lambda の型はどう書くんですか?
つか, 返る型で dispatch してくれるようになるんだっけ???


19 :デフォルトの名無しさん:2010/03/28(日) 21:57:12
std::functionかautoで受ける

20 :デフォルトの名無しさん:2010/03/28(日) 21:57:48
高階関数でも他のlambda式と同じ様に型推論してくれるよ。

21 :デフォルトの名無しさん:2010/03/28(日) 22:17:09
>>19
その auto が信用できてないんだが
関数の戻り型ってめんどう見てくれるようになたんだっけか?


22 :デフォルトの名無しさん:2010/03/28(日) 22:20:17
>>21 信用とかめんどう見るとか、わけのわからん言葉を使わないようにしてもらえませんか?

23 :デフォルトの名無しさん:2010/03/28(日) 22:20:27
>>21
信用できないって、コンパイラは右辺値の型を正確に求められるんだからautoがミスることはなくね?

24 :デフォルトの名無しさん:2010/03/28(日) 22:22:03
autoとVBのバリアントの区別がついてないんじゃないか

25 :デフォルトの名無しさん:2010/03/28(日) 22:23:18
65536くらいネストしたらコンパイラ落ちるかもしれないというのが気に食わないの?

26 :デフォルトの名無しさん:2010/03/29(月) 00:56:28
struct や class の {} の後の ; はいつになったら省略可能になりますかね。
文法的に無理ですか、そうですか。でもウザイよね。

27 :デフォルトの名無しさん:2010/03/29(月) 00:57:32
>>25
クラス書いてコンパイルすると5割くらいはそのエラーだな。。。

28 :デフォルトの名無しさん:2010/03/29(月) 01:20:33
定義に続けてインスタンスを宣言できる以上、無理っぽいよ。

29 :デフォルトの名無しさん:2010/03/29(月) 01:41:10
省略しても曖昧さが生じない ; っていうと
配列とか構造体の初期化データの末尾とか?

int a[] = { ... }; ←コレ

30 :デフォルトの名無しさん:2010/03/29(月) 01:55:49
initializer_listが導入されてややこしくなったから曖昧さが生じるケースとかありそう

31 :デフォルトの名無しさん:2010/03/30(火) 16:13:43
post-Pittburgh mailing (N3047-N3093)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/#mailing2010-03

32 :デフォルトの名無しさん:2010/03/30(火) 20:49:22
exportあぼーんキタ━━━━━━━(゚∀゚)━━━━━━━!!!
例外指定あぼーんキタ━━━━━━━(゚∀゚)━━━━━━━!!!
noexceptキタ━━━━━━━(゚∀゚)━━━━━━━!!!
ナントカvalue地獄キタ━━━━━━━(゚∀゚)━━━━━━━!!!
decltype超強化キタ━━━━━━━(゚∀゚)━━━━━━━!!!
デフォルトムーブコンストラクタ&代入演算子キタ━━━━━━━(゚∀゚)━━━━━━━!!!
Unified function syntaxコネ━━━━━━━('A`)━━━━━━━!!!

33 :デフォルトの名無しさん:2010/03/30(火) 21:10:51
何とかFCDっすか。

34 :デフォルトの名無しさん:2010/03/30(火) 21:32:48
exportとかthrow()が廃止になったって事?

> ナントカvalue地獄
wwwwww


35 :デフォルトの名無しさん:2010/03/30(火) 21:33:42
フォルキャン・・・ダッシュ・・・?

36 :デフォルトの名無しさん:2010/03/30(火) 21:48:52
N3092がFCDなんだろうけど、以前14.1にあったExported templatesが確かになくなってる。

37 :デフォルトの名無しさん:2010/03/30(火) 22:08:01
throw()あぼんってまじ?
exportはともかく無例外指定は使ってるコード多いと思うのだが。

38 :デフォルトの名無しさん:2010/03/30(火) 22:31:27
deprecatedだからまだ一応あるよ
これからはnoexceptを使いましょう

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

39 :デフォルトの名無しさん:2010/03/30(火) 22:33:54
throw()とnoexceptってどない違うねん

40 :デフォルトの名無しさん:2010/03/30(火) 22:36:19
全く一緒

41 :デフォルトの名無しさん:2010/03/30(火) 22:37:17
じゃあ最初からnoexceptにしてくれれう゛ぁーーーー

42 :デフォルトの名無しさん:2010/03/30(火) 22:40:06
あ、全く一緒ではなかった
throw()は違反するとstd::unexpected()を呼ぶ
noexceptはstd::terminate()を呼ぶ

多分違いはそれだけ

43 :デフォルトの名無しさん: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

44 :デフォルトの名無しさん:2010/03/30(火) 22:45:58
そんな解説よりN3092の3.10の図見るのが一番わかりやすいと思う

45 :デフォルトの名無しさん:2010/03/30(火) 22:56:37
> Expressions are categorized according to the taxonomy in Figure 1.
から始まるくだりか。

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

…ような気がするだけヽ(`Д')ノウワアアン

46 :デフォルトの名無しさん:2010/03/31(水) 00:29:22
デストラクタで仮想関数を呼びたいんだけど、何かいい方法ない?
class Base{
public:
Base(){}
~Base() { End(); }
private:
virtual void End() = 0;
};
ってことがやりたいんだけど・・・。
End()では、newした領域deleteしたり、なんやかんやと、
派生クラスごとに異なった処理します。

47 :デフォルトの名無しさん:2010/03/31(水) 00:32:38
普通はvirtual ~Base(void);を使う

48 :デフォルトの名無しさん:2010/03/31(水) 00:46:06
>>46
~Baseが呼ばれるころには派生クラスのデストラクタが呼ばれている。その状態で仮想関数を呼ぶと未定義状態になる。

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

49 :デフォルトの名無しさん:2010/03/31(水) 00:49:54
未定義にならないだろ、と書こうと思ったが純粋仮想関数だったか。

50 :デフォルトの名無しさん:2010/03/31(水) 01:10:39
>>42
え?コンパイルエラーにならないの?
わざわざキーワード追加してそのザマなの?
っていうか unexpected() が terminate() になったからって誰が喜ぶの?

51 :デフォルトの名無しさん:2010/03/31(水) 01:14:13
>>50
知るか
俺だって何かの間違いだと思って何度も読み直して失望したんだ

52 :デフォルトの名無しさん:2010/03/31(水) 01:24:50
>>50
コンパイルエラーにならないってマジ??使えねー 絶望した。

53 :デフォルトの名無しさん:2010/03/31(水) 01:38:28
コンパイルエラーにするのは無理じゃね?

54 :デフォルトの名無しさん: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(笑)

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

55 :デフォルトの名無しさん:2010/03/31(水) 03:03:57
今までどおり、とくに不自由はないってことだ

56 :デフォルトの名無しさん:2010/03/31(水) 06:40:04
自由が素敵なものだとは限らない

57 :デフォルトの名無しさん:2010/03/31(水) 11:10:17
>>50
>>52
クソバカ共みっけw


58 :デフォルトの名無しさん:2010/03/31(水) 11:14:51
> exportの廃止。deprecateではなく、完全な削除。
> ただし、exportというキーワードは、予約語として残す。

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



59 :デフォルトの名無しさん:2010/03/31(水) 11:16:24
他の言語にエクスポートしてくれるとか


60 :デフォルトの名無しさん: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になった。


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

61 :デフォルトの名無しさん:2010/03/31(水) 11:19:56
>>57
賢い人には unexpected() が terminate() になったら何がうれしいのかわかるの?

62 :デフォルトの名無しさん:2010/03/31(水) 11:21:49
>>60
行連結は Raw string literal を解釈するフェーズより前のはずなんだが、
どうなってるんだろう?

63 :57:2010/03/31(水) 11:25:52
お前もか

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


64 :60:2010/03/31(水) 11:26:41
>>62
きっとPre-Preprocessorが動作してだな

65 :デフォルトの名無しさん:2010/03/31(水) 11:28:35
>>63
じゃあ noexcept で何がうれしいのかわかってる人はいないってこと?

66 :デフォルトの名無しさん:2010/03/31(水) 11:30:59
コンパイラの最適化が期待できるのは十分うれしい 〉noexcept

67 :デフォルトの名無しさん:2010/03/31(水) 11:32:45
>>66
え?だって例外発生したら terminate() 呼ばなきゃいけないんでしょ?
今まで unexpected() 呼ばなきゃいけなくて余計なコードが出てたのと同じじゃないの?
この違いに基づいてどういう最適化ができるの?

68 :デフォルトの名無しさん:2010/03/31(水) 11:33:45
Raw string literal は "[ ]" から "( )" になったのか。
<: :> を使用する時どうするのかと思ってたが解決したな。

69 :デフォルトの名無しさん:2010/03/31(水) 11:37:42
>67
いままで規格上 throw() で最適化することは期待されてなかったんだから
前進したのは事実だろう。terminate() 云々はコストはほぼないって感じらしい。

70 :デフォルトの名無しさん:2010/03/31(水) 11:40:58
>>67
少しは足りない脳で考えて見ろよ

71 :デフォルトの名無しさん:2010/03/31(水) 11:46:51
>>67
noexceptの原論文を読みなよ。
リアクションが馬鹿っぽいから説明してやる気にはなれない。
>>54
それが意味がある局面だってある。

72 :デフォルトの名無しさん:2010/03/31(水) 11:46:55
で、いつごろから
throw[ \t]*([ \t]*)[ \t]*
をgrepしてnoexceptに書き換えていけばいいの?

73 :デフォルトの名無しさん:2010/03/31(水) 11:47:44
>>69
今までだって throw() が付いてる関数から呼び出してる関数が全部 throw() なら
unexpected() の呼び出しコードは不要、といった類の最適化はできたでしょ?
不測の例外発生に伴って terminate() を呼ぶコストが unexpected() を呼ぶコストと
違うのは何によるのかもわかってないのに「最適化に役立つ」とか言い切っちゃって良いの?

74 :デフォルトの名無しさん:2010/03/31(水) 11:48:02
noexceptって型なの??
N2855 noexceptについて - xyuyuxの日記
ttp://d.hatena.ne.jp/xyuyux/20090630/1246360766


75 :デフォルトの名無しさん:2010/03/31(水) 11:48:46
落ち着いてまとまった解説書を書いてくれないと
俺はたぶん職を失う

76 :デフォルトの名無しさん:2010/03/31(水) 12:11:09
>>73
>>71

77 :デフォルトの名無しさん:2010/03/31(水) 12:13:05
本の虫: 例外指定について
http://cpplover.blogspot.com/2010/03/blog-post_31.html

78 :デフォルトの名無しさん:2010/03/31(水) 12:41:34
>>71
わかったよ。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3050.html#an-optimization-hint

以下の2点が 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");

79 :デフォルトの名無しさん:2010/03/31(水) 12:48:36
>>73
unexpected()とterminate()の違いを理解してないね。


80 :デフォルトの名無しさん:2010/03/31(水) 12:51:27
小さいhelper関数をnoexcept宣言で書ければ凄く便利だよ。
例えばベクトル演算系のクラスライブラリ書いてる時。

81 :デフォルトの名無しさん:2010/03/31(水) 12:54:17
noexcept 演算子を追加しといて関数の静的解析はしないとか、意味わからんな。

82 :78:2010/03/31(水) 12:59:47
あれ?
xxx_nothrow_xxx<> は noexcept 演算子で定義されてて、 noexcept 演算子は
例外指定については throw() も noexcept(true) も同じになるんで、 >>78 の2点目は
違わないね。

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

83 :デフォルトの名無しさん:2010/03/31(水) 13:25:41
例外は抽象解釈泣かせだからね。
リフトしまくって計算量は増えるわ、情報は劣化するわ。

84 :デフォルトの名無しさん:2010/03/31(水) 13:39:44
>>83 いきなり何の話だ?誤爆?

85 :デフォルトの名無しさん:2010/03/31(水) 13:45:54
>>83
× 例外は
○ 例外仕様は
かな?

86 :デフォルトの名無しさん:2010/03/31(水) 17:57:09
throw()とthrow(...)以外をdeprecatedにするんじゃダメだったのかなぁ
noexcept演算子はthrow?とかじゃダメだったのかなぁ
ラムダ用の予約語はあんなに強硬に反対してたのに、こんな下らない機能に予約語とか意味が分からない

87 :デフォルトの名無しさん:2010/03/31(水) 18:01:28
n3050読めば分かるが、
nothrow_move_constructorなどなど、非常に重要な概念。
下らないなんてとんでもない。

88 :デフォルトの名無しさん:2010/03/31(水) 18:03:27
下らないは言い過ぎとしても、予約語が必要なほど重要でもないと思う

89 :87:2010/03/31(水) 18:05:13
予約語については特に異論ない。

90 :デフォルトの名無しさん:2010/03/31(水) 18:09:41
時間がないから、構文上のトラブルを避けるためにぶち込んだんだろうな
そんな都合で決めないで欲しいけど

91 :デフォルトの名無しさん:2010/03/31(水) 18:12:02
void hoge() throw; //なんか投げる
void hoge() ~throw; //投げないらしい

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

92 :デフォルトの名無しさん:2010/03/31(水) 18:22:21
>>91
デストラクタにならって~throwとか?www

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

93 :デフォルトの名無しさん:2010/03/31(水) 18:25:03
せめてexceptにしてくれ
noexcept(false)って何だよ二重否定かよ

94 :デフォルトの名無しさん:2010/03/31(水) 18:26:31
クラスのメンバ関数にthrow()と書くと、それが例外を投げるように変更しようとした時に 制限となってしまう。
あるいは、そのクラスから派生クラスを作ろうとしたときもインターフェイスに強い制限をかけることになる。

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


95 :デフォルトの名無しさん:2010/03/31(水) 18:27:27
>>93
宣言の方でexceptだと困る、
operatorの方も同じ予約語にしたい、
こんな感じでは?


96 :デフォルトの名無しさん:2010/03/31(水) 18:32:25
>>94
つ 14.7.2.2

97 :94:2010/03/31(水) 18:34:10
>>96
規格書14.7.2.2を読むべし、と?
英語読めない俺にはC++を使うのは難しい

98 :デフォルトの名無しさん:2010/03/31(水) 18:53:58
まぁ、例外なんか使うなってこった。
メモリ確保などの、失敗がありえない&致命的な処理で失敗したら即ログ吐いてabort。
これでいいでしょ。

99 :デフォルトの名無しさん:2010/03/31(水) 19:17:28
>>72
そのうちBOOST_NOEXCEPT( )みたいなマクロが流行るんじゃない?

100 :デフォルトの名無しさん:2010/03/31(水) 19:24:56
さっさと変換して、コンパイラが対応するまで#define noexcept throw()しとけばいい

101 :デフォルトの名無しさん:2010/03/31(水) 19:45:14
まてnoexcept(false)っていう文法もあるらしい。
そもそもnoexceptを記載する場所と throw()を記載する場所って同じなのか?

102 :デフォルトの名無しさん:2010/03/31(水) 20:22:03
いきなり>>3以降の、C++学園の人々に修正が迫られるな。

103 :デフォルトの名無しさん:2010/03/31(水) 20:23:57
今回の変更って、もう決定なの!?

104 :デフォルトの名無しさん: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へ移行中

105 :103 :2010/03/31(水) 20:56:27
>>104
分かりやすい解説ありがとう。


106 :デフォルトの名無しさん:2010/03/31(水) 20:58:02
> いずれにせよ、C++0xの規格は、2011年内に、制定されるだろう。
既に来年かwwww

107 :デフォルトの名無しさん:2010/03/31(水) 20:58:31
なんかかっこいいな

108 :デフォルトの名無しさん:2010/03/31(水) 20:59:50
どうせnoexceptにNBから総ツッコミ入って遅れるだろ

109 :デフォルトの名無しさん:2010/03/31(水) 21:56:28
安心して。2011の11は16進数だから。

110 :デフォルトの名無しさん:2010/03/31(水) 22:21:20
>>46
デストラクタをprivateにして、
明示的にEnd()を呼ばせるようにしたら?

111 :デフォルトの名無しさん:2010/03/31(水) 22:24:06
>>110
良くある実装だけど何となくウザイ…。

112 :デフォルトの名無しさん:2010/03/31(水) 22:26:02
>>110
いちいちEnd呼ぶのまんどくせ。
でもいい案思いつかね。

113 :デフォルトの名無しさん: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;
}



114 :デフォルトの名無しさん:2010/03/31(水) 23:00:22
もともと例外仕様はassertと同じく
「俺の書いたコードを信用して! もし間違ってたら殺していいよ!」
というプログラマの自己責任による表明だから。

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

115 :デフォルトの名無しさん:2010/03/31(水) 23:02:06
throw()とnoexceptの関係を
assertとstatic_assertみたいにすればよかったんじゃね

116 :デフォルトの名無しさん:2010/03/31(水) 23:08:22
お前ら、何か忘れてるんじゃない?
C++には関数ポインタがある。
だから、コンパイル時には実行時にどのコードが走る可能性があるか決定できない。
つーことは、コンパイル時に例外が投げられる可能性があるか無いかは判断できない。

117 :デフォルトの名無しさん:2010/03/31(水) 23:10:44
よくよく思い出せ。
適当なポインタを適当な関数型にキャストして適当に()書いたらそこのコードが走るような言語だぞ。
あまり無理を言うな。

118 :デフォルトの名無しさん:2010/03/31(水) 23:29:28
>>114
> 「俺の書いたコードを信用して! もし間違ってたら殺していいよ!」
> というプログラマの自己責任による表明だから。
分かりやすいな、例え。


119 :デフォルトの名無しさん:2010/03/31(水) 23:36:56
誰かADLをどうにかしろ!!
俺にも分かるようにしてくれ!

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

121 :74:2010/03/31(水) 23:40:33
>>120
つまり>>74で言われていたみたいにcv修飾子みたいにするわけですね。

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


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



122 :デフォルトの名無しさん:2010/03/31(水) 23:49:53
>>121
そうなると、テンプレートは、noexceptとそうじゃない奴の二種類ずつメソッドを用意する事になるな。
constとの組み合わせもあるから、沢山定義しないといけないね(笑

123 :デフォルトの名無しさん: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; }

124 :デフォルトの名無しさん:2010/04/01(木) 01:06:09
moveも出来るか考慮した方が

125 :デフォルトの名無しさん: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.

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

126 :60:2010/04/01(木) 07:46:20
>>125
> 巻き戻すって、一旦行連結しちゃったらもうどこに改行があったかなんて
> わからないんじゃないの?どういう実装を想定してるんだろう?
そう、俺もそう思って>>60の発言になった。
びっくりだわー

127 :デフォルトの名無しさん:2010/04/01(木) 09:34:17
行連結する前に丸々コピーするだけだろ

128 :デフォルトの名無しさん:2010/04/01(木) 11:40:08
え?

129 :デフォルトの名無しさん:2010/04/01(木) 19:10:02
const char *s = R"EOS(
#include"foo.h"
)EOS";

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

130 :デフォルトの名無しさん:2010/04/02(金) 09:38:56
Raw String の実装は、とある強力コンパイラメーカーの実装による要望で、
実のところ "Phases of translation" は as is であって、実際のコンパイル動作とは関係ない。
というか馬鹿正直に守っているコンパイラは事実上無い。

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

131 :デフォルトの名無しさん:2010/04/02(金) 09:58:13
>>130
distcc や ccache などのツールはプリプロセスがコンパイルと分離された
フェーズであることに依存して、一旦プリプロセス結果を生成し、それを
コンパイルは別の独立したプロセスに投げたりする。

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

やっぱり心配だ。

132 :デフォルトの名無しさん:2010/04/02(金) 10:12:19
>>129
それ include されるの? 単に「#include"foo.h"\n」って文字列に解釈されるんじゃないの?

133 :デフォルトの名無しさん: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);
    }

134 :デフォルトの名無しさん:2010/04/02(金) 16:20:07
>>133です。反応無いので取り下げます〜。
お邪魔しました〜。

135 :デフォルトの名無しさん:2010/04/02(金) 16:53:06
スレタイから C++ とったほうがいいかもね。
0x だけで探せるでしょ。

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

136 :デフォルトの名無しさん:2010/04/02(金) 18:15:26
>>132
一旦includeしてから"revert"するんでしょ
125によると

137 :133:2010/04/02(金) 20:13:26
>>135
ぁぃゃ〜。しまったです。
普通の質問スレと勘違いしてしまいしましたです。
ホントに申し訳ない。Orz

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

138 :デフォルトの名無しさん:2010/04/02(金) 21:48:36
右辺値参照を用いて(a+b)*(c+d)*e のような行列の積を正しく計算
できますか?

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

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


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

139 :デフォルトの名無しさん:2010/04/02(金) 22:55:15
誰もがそう思ってるけど、50年来の悪しき伝統なので変えられない

140 :デフォルトの名無しさん:2010/04/02(金) 23:49:29
>>138 何言ってるのかわからん。 >139 はエスパーか?

141 :デフォルトの名無しさん:2010/04/02(金) 23:51:29
コンパイラ黎明期から右辺値という名称

142 :デフォルトの名無しさん:2010/04/03(土) 00:52:24
>>135
> スレタイから C++ とったほうがいいかもね。
> 0x だけで探せるでしょ。
しかし
C++0xからC++をとって、その上2009年中に終わらなかったのだから0xを取ると
何もなくなってしまうじゃないかw


143 :126:2010/04/03(土) 00:54:03
>>127
どういう意味?


144 :デフォルトの名無しさん:2010/04/05(月) 01:18:54
unique_ptrってコンテナに使っても大丈夫だったのか

145 :デフォルトの名無しさん: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.

だとさ。


146 :デフォルトの名無しさん:2010/04/05(月) 10:27:19
unique_ptrとshared_ptrの違いは何よ?

147 :デフォルトの名無しさん:2010/04/05(月) 10:51:45
unique か shard か。

148 :デフォルトの名無しさん:2010/04/05(月) 11:24:12
意味わかんね

149 :デフォルトの名無しさん:2010/04/05(月) 11:27:17
所有権の話。

150 :デフォルトの名無しさん:2010/04/05(月) 11:39:36
Pimplとか考えると、一番使用頻度高いのってやっぱ shared_ptr だよな?

151 :デフォルトの名無しさん:2010/04/05(月) 20:22:09
>>150
stdに入っているauto_ptrと、boostに入っているshared_ptrとで
どっこいどっこいぐらいかな。

stdにshared_ptrが入れば無敵。

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


152 :デフォルトの名無しさん:2010/04/05(月) 20:45:59
unique_ptr がそれじゃないかな

153 :デフォルトの名無しさん:2010/04/06(火) 02:16:36
C++0x前提だとuniqueと比べてscopedのメリットって何も無いよな

154 :デフォルトの名無しさん:2010/04/06(火) 21:36:55
スマートポインタって生ポインタより遅くなるの?


155 :デフォルトの名無しさん:2010/04/06(火) 21:40:06
メモリの確保やコピーの際にコストがかかることもあるが
ポインタを使う分にはinline化が効くから生のポインタと同じ

156 :デフォルトの名無しさん:2010/04/06(火) 21:43:22
必要な機能に必要十分なものを使えば、
オーバーヘッドはない。そう実装されている。

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


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


158 :デフォルトの名無しさん:2010/04/07(水) 00:19:47
何億回もループ回すとかミリ秒単位のリアルタイム処理するとか
そんなんでなけりゃスマポのオーバーヘッドなんて何でもないよ

159 :デフォルトの名無しさん:2010/04/07(水) 01:10:46
auto_ptrの代わりにshared_ptrを使う場合に、auto_ptrは複製が無いので参照カウンタのオーバーヘッドが起きない。
auto_ptrのムーブ(=演算子)はshared_ptrではswapを使うのでやはり参照カウンタのオーバーヘッドが無い。

160 :デフォルトの名無しさん:2010/04/07(水) 01:12:12
日本語でおk

161 :デフォルトの名無しさん:2010/04/07(水) 01:13:09
>>159 なにいってんのかわかんねぇ。

162 :デフォルトの名無しさん:2010/04/07(水) 01:18:00
auto_ptrの代わりにshared_ptrを使う場合に(と断っておきながら)、auto_ptrは…(shared_ptrを使う場合じゃなかったのかよww)
auto_ptrのムーブ(=演算子)は(何、auto_ptrのムーブの話?)shared_ptrでは…(おいおい、auto_prtのムーブってshared_ptrでも使われるのか?w)

163 :デフォルトの名無しさん:2010/04/07(水) 07:26:02
>>159
日本語読解上級者コース

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

165 :デフォルトの名無しさん:2010/04/07(水) 08:51:09
ソースみりゃ分かるが shared_ptr はけっこういろいろやってんぞ
カウンタも shared 分と weak 分と 2 つあるし
ふつーに実行時オーバーヘッドあるだろ

166 :デフォルトの名無しさん:2010/04/07(水) 09:47:46
>>164
> deleter の動的指定, thread-safe as an int のための排他処理

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


167 :デフォルトの名無しさん:2010/04/07(水) 11:18:37
排他処理と生成破棄以外のコストは気にしなくていいと思う

168 :デフォルトの名無しさん:2010/04/07(水) 13:42:51
>166
deleter の動的指定にかかるコストは shared_ptr オブジェクトの生成と破棄の際に,
排他処理は shared_ptr オブジェクトのコピーの際に,それぞれ常に付きまとうと思います.
もちろん,これらのオーバーヘッドが shared_ptr を利用する際の全体的なコストから見て
どの程度有意かはまた別の問題だと思いますけれど.

169 :デフォルトの名無しさん:2010/04/07(水) 18:46:51
まずもって心配いらん
安心して使いたまへ

170 :デフォルトの名無しさん:2010/04/07(水) 19:34:53
>>157
unique_ptrはすごいぞ
最適化かけたらアセンブリ出力にunique_ptrが居ねえ

171 :デフォルトの名無しさん:2010/04/07(水) 19:36:01
それは auto_ptr でも scoped_ptr でもいっしょだろ。

172 :デフォルトの名無しさん:2010/04/07(水) 21:56:44
>>168
そういうのオーバーヘッドって言わないでしょ。

173 :デフォルトの名無しさん:2010/04/07(水) 22:00:35
オーバヘッ!
オーバヘッ!

174 :デフォルトの名無しさん: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/

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

175 :デフォルトの名無しさん:2010/04/08(木) 08:02:40
冒頭のテンプレ読んだんだけど、今のC++ってこんなことになってるんだな。
カオスすぐる。

176 :デフォルトの名無しさん:2010/04/08(木) 08:16:47
adhocやるんだって
ttp://homepage1.nifty.com/herumi/prog/cppwg.html

177 :デフォルトの名無しさん:2010/04/08(木) 11:09:07
hoge[1, 2, 3] = h; ←これ配列でも使えるように、オーバーロードもできるように仕様に入れるべき
hoge[1][2][3] = h;みたいなのをエミュレートするのに余計なオーバーヘッドのコストを支払うのは嫌だ

178 :デフォルトの名無しさん:2010/04/08(木) 11:19:15
>>177
operator()のオーバーロードでいいじゃん。
オーバーロード以前にhoge[1, 2, 3]っていう文法ないんだし。

179 :デフォルトの名無しさん:2010/04/08(木) 11:22:25
>>177
オーバーヘッドは防げないか?コーディングが面倒なだけで。
たとえばどんな hoge[1][2][3] の実装を想定してるの?

180 :デフォルトの名無しさん:2010/04/08(木) 11:26:21
>>178
hoge(1, 2, 3) = h;
でもこれって見ため最高に気持ち悪くないか?
fortranとかで慣れてる人はいいのかもしれないけど
メンバへの参照アクセスは[]で縛りたいって思うわけよ

181 :デフォルトの名無しさん:2010/04/08(木) 11:40:59
[1, 2, 3] ってカンマ演算子で最終的に3が返るからどちらにしろだめだろ
(1, 2, 3)も同じ理由からあまり推奨できない

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

183 :デフォルトの名無しさん:2010/04/08(木) 11:59:28
>>182
プロクシの参照がコンパイル時に全部解決されれば、実行時のコストは無いよね?

184 :デフォルトの名無しさん:2010/04/08(木) 12:36:07
hoge[{1,2,3}] で。

185 :デフォルトの名無しさん:2010/04/08(木) 14:42:16
プロクシクラスを持つのにvoltile修飾してなければ問題ない。
あんまりピリピリするな。

186 :デフォルトの名無しさん:2010/04/08(木) 19:23:14
0xのメルセンヌ・ツイスタって使ったらいちいち著作権表示しないといかんの?

187 :デフォルトの名無しさん:2010/04/08(木) 21:05:17
コンパイラのライセンス次第だろ

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

188 :デフォルトの名無しさん:2010/04/08(木) 21:55:43
わざわざできるようにしたんだから 0x 的には >>184 だろう。

189 :デフォルトの名無しさん:2010/04/08(木) 21:58:24
x[{1,2,3}];ってやると配列が渡されるの?

190 :デフォルトの名無しさん:2010/04/08(木) 22:14:33
initializer_list が渡されるんだろう。

191 :デフォルトの名無しさん: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

これはなんだー

192 :デフォルトの名無しさん:2010/04/09(金) 02:08:22
さすがメイヤーズ先生や
日本語解説書なんか最初からいらんかったんや

193 :デフォルトの名無しさん:2010/04/09(金) 02:42:38
メイヤーズ先生ってもっとおじいちゃんだと思ってたわ

194 :デフォルトの名無しさん:2010/04/09(金) 07:13:03
Scott Meyers先生すげぇ

195 :デフォルトの名無しさん:2010/04/09(金) 11:31:00
髪の毛こんなにあるとは思わなかったな

196 :デフォルトの名無しさん:2010/04/09(金) 11:38:58
すぽすぽ先生がいかにもな風貌すぎるんだよ

197 :デフォルトの名無しさん:2010/04/09(金) 12:43:24
すっぽすっぽ
ふっさふっさ

198 :デフォルトの名無しさん:2010/04/09(金) 13:13:14
まじか…このTarget publication date
ttp://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50372

199 :デフォルトの名無しさん:2010/04/09(金) 14:06:30
1012年/( ^o^ )\

200 :デフォルトの名無しさん:2010/04/09(金) 21:12:31
Target publication date: 2012-02-28

>>199
Ed. 紫式部かよ。

201 :デフォルトの名無しさん:2010/04/09(金) 21:32:53
そのころにはVC11とGCC4.7がそれなりの実装してくれてるといいな

202 :デフォルトの名無しさん:2010/04/09(金) 21:34:11
文書のタイトルが「Microsoft PowerPoint - C++0x.ppt」になっとる
336ページのパワーポイントw

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



204 :デフォルトの名無しさん:2010/04/09(金) 23:59:34
>>201
> そのころにはVC11とGCC4.7がそれなりの実装してくれてるといいな
VCはともかくg++は5.x系になっても良いくらいの大変革だろ。
むしろg++0xとか名前が変わるくらいの出来事。


205 :デフォルトの名無しさん:2010/04/10(土) 00:00:56
ttp://d.hatena.ne.jp/faith_and_brave/20100406/1270537463

206 :デフォルトの名無しさん:2010/04/10(土) 00:23:29
一つの言語の都合だけではGCCのメジャーバージョンは上がらんよ

207 :デフォルトの名無しさん:2010/04/10(土) 00:31:51
>>206
そーいや複数の言語を扱う代物だったな。


208 :203:2010/04/10(土) 00:32:51
>>205
私も自分でググった時にそのページは見つけたのですが、
それだけではClassXしか分かりませんでした。

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


209 :デフォルトの名無しさん:2010/04/10(土) 00:34:56
デフォコン優先で無理ならリストだろ

210 :デフォルトの名無しさん:2010/04/10(土) 00:44:19
>>209
まてそのソースは?
例のブログの人の降臨を待つべきだ。


211 :デフォルトの名無しさん:2010/04/10(土) 00:57:33
召還しないで205のコメント欄で聞きゃいいよ
そこの人も日本NBのメンバのはずだから

212 :デフォルトの名無しさん:2010/04/10(土) 00:58:23
自分でドラフトを読むという選択肢は無いのかね?

213 :デフォルトの名無しさん:2010/04/10(土) 01:00:37
あるよ。

214 :デフォルトの名無しさん: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({})が呼ばれる

215 :デフォルトの名無しさん:2010/04/10(土) 14:31:28
Otherwise多すぎwwww
汚ねぇ仕様書だ・・・。


216 :デフォルトの名無しさん:2010/04/10(土) 14:51:29
まだこの後に4項目続くんだぜw

217 :203:2010/04/10(土) 15:25:27
皆さんありがとうございます。

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


218 :デフォルトの名無しさん:2010/04/10(土) 17:39:14
誰か猫でもわかるオーバーロード入門を書いてください

219 :デフォルトの名無しさん:2010/04/10(土) 17:47:55
>>218
オーバーロードのどこが難しいの?

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

のがやばいだろ。


220 :デフォルトの名無しさん:2010/04/10(土) 18:41:38
日本の猫はいったいどこまで賢くなろうとしているのか

221 :デフォルトの名無しさん:2010/04/10(土) 19:16:55
猫は害獣

222 :デフォルトの名無しさん:2010/04/10(土) 19:34:47
我が輩は猫である
名前は間田内

223 :デフォルトの名無しさん:2010/04/10(土) 20:52:31
我輩は猫である
I am a cat.

224 :デフォルトの名無しさん:2010/04/10(土) 21:28:43
仕事はもう無い

225 :デフォルトの名無しさん:2010/04/10(土) 21:37:30
どこでミスしたかとんと見当がつかぬ。

226 :デフォルトの名無しさん:2010/04/10(土) 21:42:07
何でも薄暗いじめじめした所で壁に向かって仕事していた事だけは記憶している。

227 :デフォルトの名無しさん:2010/04/10(土) 21:46:09
吾輩はここで始めてプログラマというものを見た。

228 :デフォルトの名無しさん:2010/04/10(土) 22:47:54
>>227
吾輩はここで始めて 上司 というものを見た。

じゃないかな・


229 :デフォルトの名無しさん: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
が発端。


230 :デフォルトの名無しさん:2010/04/10(土) 23:27:53
TR2でbigint入れて欲しいとかそういうネタ振りですか

231 :デフォルトの名無しさん:2010/04/10(土) 23:45:18
Cat, I'm kitty cat.

232 :デフォルトの名無しさん:2010/04/10(土) 23:47:04
>>230
そんなん期待できねぇよ。
できたら願ったり叶ったりだがな。

233 :デフォルトの名無しさん:2010/04/11(日) 06:26:55
>219
どうやって candidate functions が決まるのかを入れるなら name lookup の話を含むだろうし、
best viable function を定めるルールだけでもきっちり分かりやすく説明できるというのなら
今すぐ執筆してくれ。

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


235 :デフォルトの名無しさん:2010/04/11(日) 14:19:37
油断ならねえなぁ
もしshared_ptrとかが汚染されたら大変なことになるよな
怖すぎる

236 :デフォルトの名無しさん:2010/04/11(日) 15:31:43
bigint なんてそんな至る所で使われてんのか?
そういう類いのクラスには思えないのだが

237 :デフォルトの名無しさん:2010/04/11(日) 18:14:59
>>236
いやたぶん使われていない。
だから標準Boost(って変な表現だが)に推されないんじゃね。



238 :デフォルトの名無しさん: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

239 :デフォルトの名無しさん:2010/04/13(火) 22:28:56
Japanese版早く出せ

240 :デフォルトの名無しさん:2010/04/14(水) 23:34:16
>>239
1週間ぐらい待てないのか?

俺は待てない

241 :デフォルトの名無しさん:2010/04/15(木) 05:06:09
あんまりソワソワしないで

242 :デフォルトの名無しさん:2010/04/15(木) 18:46:38
あなたはいつでもキョロキョロ

243 :デフォルトの名無しさん:2010/04/15(木) 20:40:40
よそ見をするのはやめてよ

244 :デフォルトの名無しさん:2010/04/15(木) 20:44:14
おまえら何歳なんだよ

245 :デフォルトの名無しさん:2010/04/15(木) 20:50:16
ょぅι゛ょです

246 :デフォルトの名無しさん:2010/04/16(金) 01:45:57
いくつも愛を持ってる男の人って…

247 :デフォルトの名無しさん:2010/04/16(金) 04:45:41
生物の目標が繁栄することだとすると
種をばらまく側としては、あちこちにターゲットを移してしまうのは
それはそれで正しいんだよな

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

248 :デフォルトの名無しさん:2010/04/16(金) 13:11:56
lambdaっちゃ

249 :デフォルトの名無しさん:2010/04/16(金) 14:47:45
誰がうm

250 :デフォルトの名無しさん:2010/04/16(金) 14:59:59
>>238-249
流れでコーヒーフイタww


251 :デフォルトの名無しさん: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種類も書かないといけないのだろうか? それとも何か勘違いしてる?

252 :デフォルトの名無しさん:2010/04/16(金) 20:12:17
X<T> operator*(X<T> &&, T &&);

これはいらないの?

253 :デフォルトの名無しさん:2010/04/16(金) 20:20:59
>>252
書き漏らしてたよ。ありがと。

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

254 :デフォルトの名無しさん:2010/04/16(金) 20:32:59
右辺値参照なんて要らないよ
そんなに破壊可能なテンポラリが欲しければ
自分で一時変数作れ

255 :デフォルトの名無しさん: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);
とかね。

256 :デフォルトの名無しさん:2010/04/16(金) 21:11:50
>>254
> そんなに破壊可能なテンポラリが欲しければ
右辺値参照をなーんにも理解していないんだな。
少しは勉強しろ。ggr


257 :デフォルトの名無しさん:2010/04/16(金) 21:25:34
右辺値参照が必要な場面では内部処理も変わるだろうから
省力化は難しいんじゃないか

258 :デフォルトの名無しさん:2010/04/16(金) 21:30:43
>>257
やっぱりそうか…。

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

259 :デフォルトの名無しさん:2010/04/16(金) 21:45:38
>>255
速度欲しけりゃそんな風に書くなと

260 :デフォルトの名無しさん:2010/04/16(金) 21:58:51
でもまあ、そこそこの速度で実行可能なら
ライブラリーではETやrvalue referenceを使ってがんばる意味はあると思うが
その結果、可読性が高くできるし

261 :デフォルトの名無しさん:2010/04/17(土) 07:49:52
>>260
>>255みたいな書き方だと、そこそこレベルじゃねーだろ。

262 :デフォルトの名無しさん:2010/04/17(土) 07:51:06
>>258
GIMPLE使えば独自warningも追加できるぞ。

263 :デフォルトの名無しさん:2010/04/17(土) 12:56:43
Expression Template技法は俺には扱えない。
頭がおかしくなりそう。

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


264 :デフォルトの名無しさん:2010/04/17(土) 13:00:31
>>261
その代償が >>251 だと思うと・・・

265 :デフォルトの名無しさん:2010/04/17(土) 13:27:48
>>261
ベクトルなら加減・スカラー倍で計16個、
多元環なら加減乗算で計20個、
さらに除算ができる場合は計32個の定義が必要!!

266 :デフォルトの名無しさん:2010/04/17(土) 13:29:58
>>265
あっスカラー倍の割り算を計算に入れてなかったので、さらに若干増えるぞ!

267 :デフォルトの名無しさん:2010/04/17(土) 13:53:33
X = A;
X.AddAssign(B).AddAssign(C).AddAssign(d*D).AddAssign(E);

でいいだろ

268 :デフォルトの名無しさん:2010/04/17(土) 14:18:35
やだよそんなJavaっぽい書き方

269 :デフォルトの名無しさん:2010/04/17(土) 14:19:33
>>265
どうせお前はまともなクラスライブラリ書かないから心配することないよ。


270 :デフォルトの名無しさん:2010/04/17(土) 14:28:09
演算子のオーバーロードとか
あくまで補助的なもんだと言うのに
速度も一緒に得ようとか烏滸がましいとは思わないか?

271 :デフォルトの名無しさん:2010/04/17(土) 15:03:21
現実にいいライブラリ蓄積してきているからなあ。


272 :デフォルトの名無しさん:2010/04/17(土) 15:11:42
ET用にはBoost.Protoなんてのもあるから、
Rvalue-ref. にもBoostがなんか作るんじゃね?

273 :デフォルトの名無しさん:2010/04/17(土) 16:45:31
いい具合の代数幾何ライブラリを書きたくなって仕方ないのは、
多分 Cg/HLSL とか AltiVec 拡張とか触ってしまったからだろう。
それらをライブラリとして実装するのは無理があるというが俺の結論。

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

274 :デフォルトの名無しさん:2010/04/17(土) 21:34:55
凡人の結論を軽々突破するのがC++ templateだしな。


275 :デフォルトの名無しさん:2010/04/17(土) 22:26:33
>>274
しかし凡人にはC++ Template metaprogrammingが使いこなせないから
やっぱり無理なんだろうw


276 :デフォルトの名無しさん: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にこだわる必要はなさそうだよ。


だってさ。

277 :デフォルトの名無しさん:2010/04/22(木) 18:54:53
絶対に完成しないだろ0x

278 :デフォルトの名無しさん:2010/04/22(木) 19:40:49
完成しなくてもコンパイラが対応しつつあるから
コンパイラ間で齟齬さえなければどうでもいいよ

279 :デフォルトの名無しさん:2010/04/22(木) 19:43:07
もうコンパイラベンダ間で勝手に仕様作っちゃおうぜ
C++標準化委員会とか正直どうだっていい集団じゃねぇか。


280 :デフォルトの名無しさん:2010/04/22(木) 19:45:11
あうとー。

281 :デフォルトの名無しさん:2010/04/22(木) 19:52:03
C++1X/CLI で。

282 :279:2010/04/22(木) 21:23:26
>>281
ああ、なるほど、そうすると
C++/CLIのごとくになっちゃうのか。

それはいやだな。


283 :デフォルトの名無しさん:2010/04/23(金) 00:22:44
W3C←→WHATNGみたいな事態には陥ってないかと。
Committeeはいい仕事しているので。
遅いという気持ちは分かるけど。

284 :デフォルトの名無しさん:2010/04/24(土) 09:56:06
テンプレ見てたらこんなの出来たとしても使えるようにならんだろ
effective C++を何倍の厚さにすればいいんや

285 :デフォルトの名無しさん:2010/04/24(土) 11:46:12
>>283
> Committeeはいい仕事しているので。
遅いんじゃなくて、確実にクソ仕様への道を歩んでいる気がする。
多少 後方互換性を壊す勇気を持ってほしかった。


286 :デフォルトの名無しさん:2010/04/24(土) 12:32:11
互換性が無くなったら意味が無いというかC++じゃなくなるというか
ベンダにとって不利益になるのは確実

287 :デフォルトの名無しさん:2010/04/24(土) 12:55:31
>>286
> ベンダにとって不利益になるのは確実
どうしてそう言い切れるのさ?
ベンダだってわざと互換性が無いようにすることだってあるだろうよ。
とはいえ
> 互換性が無くなったら意味が無いというかC++じゃなくなるというか
まあそれは分かる。
C/C++との極めて高い互換性を持っていなけC++0xなんて
存在意義が無いとは思う。



288 :デフォルトの名無しさん:2010/04/24(土) 12:58:48
もう新しい言語にした方が良い気がするねえ
Cへのトランスレータにすれば互換性も確保出来るじゃん

289 :デフォルトの名無しさん:2010/04/24(土) 13:07:53
互換性が無くなるとコンパイルが通らなくなる
コンパイルが通らない新しいコンパイラなんていらない
=不利益になる

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

290 :デフォルトの名無しさん:2010/04/24(土) 13:15:44
互換性捨てた新しいのならJavaとかC#とかDとかいっぱいあるじゃないか。

291 :287:2010/04/24(土) 13:27:51
>>289
なるほどねぇ。そーゆー考えもあるね。

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


292 :291:2010/04/24(土) 13:29:18
× IEとか。
○ IEとかMS Officeでもそんな感じじゃん。

293 :デフォルトの名無しさん:2010/04/24(土) 13:53:59
例外やTMPをCへのトランスレータとして解決できる実装があれば見てみたい。

294 :デフォルトの名無しさん:2010/04/24(土) 14:00:05
>>293
> 例外やTMPをCへのトランスレータとして解決できる実装があれば見てみたい。
むしろTMPは割と可能じゃないの?
コンパイル時に定まるんだから。

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


295 :デフォルトの名無しさん:2010/04/24(土) 14:01:39
つsetjmp.h

296 :デフォルトの名無しさん:2010/04/24(土) 14:02:22
Comeau C++ って
C++ -> C言語
の変換器じゃなかったっけ??


297 :デフォルトの名無しさん:2010/04/24(土) 14:27:48
setjmp使ってCで例外を自作してるのなら見たことあるぞ

298 :デフォルトの名無しさん:2010/04/24(土) 14:33:40
コードをいくらでもグロくしていいなら例外も普通にifとreturnで書けるだろ

299 :デフォルトの名無しさん:2010/04/24(土) 15:03:54
それかなりオーバーヘッドかからないか?

300 :デフォルトの名無しさん:2010/04/24(土) 15:52:02
だってそもそも例外だし。

301 :デフォルトの名無しさん:2010/04/24(土) 23:49:04
チューリング完全な言語同士では計算可能性は同じだから
可能かどうかで論じると意味をなさない
どのように実現出来るか、という視点で論じるべき

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

302 :デフォルトの名無しさん:2010/04/25(日) 07:55:52
そもそもCにデストラクタはないから問題ないんでね。

303 :デフォルトの名無しさん:2010/04/25(日) 12:55:12
関数呼び出すたびif例外ならgotoとかするわけ

304 :デフォルトの名無しさん:2010/04/25(日) 14:17:22
>>302
いまの話題がC++からCへのトランスレータであるという俺の認識が間違ってないなら、
C++のデストラクタ相当の機能をCでどうやって書き下すかということを言ってるんだと思った

305 :デフォルトの名無しさん:2010/04/25(日) 14:29:22
例外が起きた時の処理を関数の中に書いておいて
setjmpでそこに飛ぶ関数を作って
その関数ポインタをグローバルなスタックに関数に入るたび積んで行って
例外が起きたら実行してやればいいんじゃないの

306 :デフォルトの名無しさん:2010/04/25(日) 14:32:12
gccは例外サポートがCPUにない場合にそんな感じの実装になってるね。

307 :デフォルトの名無しさん:2010/04/25(日) 14:35:07
Cへのトランスレータ作成が例外で頓挫したって話は
ありゃデマだったのか?

308 :デフォルトの名無しさん:2010/04/25(日) 14:38:19
おまいら、C++の設計と進化ぐらい読んでないのかよ

309 :デフォルトの名無しさん:2010/04/25(日) 14:41:16
私女だけど読んでなかった

310 :デフォルトの名無しさん:2010/04/25(日) 14:49:26
CPUによる例外サポートって何?
x86ならINT命令?

311 :デフォルトの名無しさん:2010/04/25(日) 14:54:07
C++例外の実装にCPUの機能(CPU例外機能)なんか使わなくていいんだよ。

312 :デフォルトの名無しさん:2010/04/25(日) 15:07:44
CPUの例外とC++の例外はそもそも意味が違うだろ

313 :デフォルトの名無しさん:2010/04/25(日) 15:11:14
>>308
それ読む価値あった?
俺は別に歴史にはそんな興味ないし。

314 :デフォルトの名無しさん:2010/04/25(日) 15:12:50
例外を禁止し、exit()で置き換えれば吉。


315 :デフォルトの名無しさん:2010/04/25(日) 15:18:28
>>313
> それ読む価値あった?
物事の欠点を見つけた時に、
「こういう欠点があると自分にわかるのは、自分が利口であり、この物事に関わった奴らが馬鹿だからだ」
と考えて満たされちゃう浅はかな生き方してる人に読ませると、多少はそれを矯正できるかも。

316 :313:2010/04/25(日) 15:29:02
>>315
なんだか深い事いってるのう

317 :デフォルトの名無しさん:2010/04/25(日) 15:33:07
C++がこんなになっちゃったことへの禿の言い訳が延々書いてあるのかな

318 :デフォルトの名無しさん:2010/04/25(日) 15:36:27
というような人に読ませるのも吉。
読んだら最後、それでも揶揄したかったら具体的な話をしなきゃ通らなくなるし、
そういう人は大抵そういう具体的なやり取りできないので、馬鹿を黙らせるのに使える。

319 :デフォルトの名無しさん:2010/04/25(日) 16:37:06
難度の高い言語だから「こんなことになっちゃった」とか言っちゃうような子は
そう思っておけばいいんじゃないの
まあC++にも色々「どうしてこうなった」的な部分はあるんだけど
多分俺らがどうしてこうなったと思ってる部分とこの子らが言ってる部分は違うよな

320 :デフォルトの名無しさん:2010/04/25(日) 17:13:03
D&Eを読むと、大抵の仕様はよく検討したらしいことが伺える
個人的には納得できる議論もあったし、
納得できない記述もあった

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

321 :デフォルトの名無しさん:2010/04/25(日) 17:26:32
C++使ってて「なんでだお!?」って思う部分があるならD&Eは読む価値がある。
C++0xに関してはD&Eの記述からすると結構「?」な部分も多いけど。

322 :デフォルトの名無しさん:2010/04/25(日) 18:57:22
typesafe enum が欲しい

323 :デフォルトの名無しさん:2010/04/25(日) 19:16:14
0xの Strongly Typed Enums のことか?

324 :デフォルトの名無しさん: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


325 :デフォルトの名無しさん:2010/04/25(日) 20:24:36
conceptは犠牲となったのだ・・・

326 :デフォルトの名無しさん:2010/04/25(日) 21:00:40
>>324
>A mor complement

愛の補数とはまた粋な

327 :デフォルトの名無しさん:2010/04/25(日) 21:58:06
いやいや、きっと次のC++の版くらいには
復活するでしょconceptさん。


328 :デフォルトの名無しさん:2010/04/25(日) 22:31:24
なんか面白い話題無い?

329 :デフォルトの名無しさん:2010/04/25(日) 22:35:24
>>328
C++0xには今のところない。

330 :デフォルトの名無しさん:2010/04/25(日) 23:07:36
           __
        , ‐' ´   ``‐、             / ̄:三}
.     /,. -─‐- 、.   ヽ        /   ,.=j
 _,.:_'______ヽ、 .!       ./   _,ノ
  `‐、{ へ  '゙⌒ `!~ヽ. !     /{.  /
    `! し゚  ( ゚j `v‐冫   , '::::::::ヽ、/     話題がないなら野球しようぜ!
.    {.l   '⌒      ゙ 6',!   / :::::::::::::::/ __
.     〈  < ´ ̄,フ  .ノー'_ , ‐'´::::::::::::::;/ (_ノ)‐-、
.      ヽ.、 ` ‐", ‐´‐:ラ ':::::::::::::::: ;∠.   ヽ_}  ゙ヽ
        ,.r` "´  /:::::::::::::::::::ィ´  `ゝ  !、  /
     /       / :::::::::::::::: ; '´   /´\ /   r'\
.     i      ! ::::::::::::::/ 墨 | .!::::::::/ヽ、.._!ヽ. ヽ、
     {      {:::::::::::;:イ /   ‖i:::::::/:::::::::::::/  \
.      ヽ       ヽ,.ァ‐'´ /ヽ 二 ,/`ヽ、::::::::: /

331 :デフォルトの名無しさん:2010/04/25(日) 23:17:18
GCCの完全サポートがまぁ4.5.x〜4.6ぐらいだとして
VC++のサポート完了はまたSP1待ちかね。
tr1の時も遅かったし…

332 :デフォルトの名無しさん:2010/04/25(日) 23:57:52
VCなんかに期待してるのか?
やめとけ。無駄だ。

333 :デフォルトの名無しさん:2010/04/26(月) 00:00:53
VC3000のど飴のことです

334 :デフォルトの名無しさん:2010/04/26(月) 00:15:21
2020年、cppxlang + LLVM が盤石

335 :デフォルトの名無しさん:2010/04/26(月) 03:25:13
>>334
いや、2011年にはC++0x完璧で、
下手すりゃconceptも2012年くらいに実装されてると思う。
Clangは凄い勢いで成長してる。
コードも綺麗。

336 :デフォルトの名無しさん:2010/04/26(月) 03:31:12
Cに変な拡張入れるのやめて欲しい…>Clang

337 :デフォルトの名無しさん:2010/04/26(月) 03:37:45
しゃーねーだろ。gcc互換目指してるんだから。

338 :デフォルトの名無しさん:2010/04/26(月) 03:42:48
gcc拡張ならともかくCにGCとかクロージャとか誰か止めなかったのか
せめて一言"ObjCでやれ"と言う奴はいなかったのか・・・

339 :デフォルトの名無しさん:2010/04/26(月) 04:03:54
いや、ああいうのはLLVM的に必要だから。
LLVMとの絡みで実験的な実装をやるのが、
Clangの目的のひとつ。そしてLLVMの仕様に反映。

340 :デフォルトの名無しさん:2010/04/26(月) 06:31:05
>>335
C++0xの現行版の仕様が確定するのが
2011年だぞ?


341 :デフォルトの名無しさん:2010/04/26(月) 07:20:39
アホが来た

342 :デフォルトの名無しさん:2010/04/26(月) 08:50:02
どうも。いつもお世話になってます。アホです。

343 :デフォルトの名無しさん:2010/04/26(月) 08:59:27
なんでこれで笑ってしまったんだろう・・ww

344 :デフォルトの名無しさん:2010/04/26(月) 09:12:19
>>340
実装状況調べてないだろw

345 :デフォルトの名無しさん:2010/04/26(月) 10:57:21
>>344
ぜんっぜん調べてねぇけど、ドラフトは読んでるよ。
この状況では確定するのはやっぱり2011年だろ?


346 :デフォルトの名無しさん:2010/04/26(月) 11:07:29
FCDまで来たから、機能が増えたり改められたりはもう多分ない。
何か問題があったら引かれるだけ。conceptのように。
あとはrvalueみたいに表現の調整ぐらい。

347 :デフォルトの名無しさん:2010/04/26(月) 11:26:16
>>346
このFCDのまま行くのかね?
あと1回くらいFCDを出し直してそれから進むと踏んでいるんだけど。
その辺を含めて2011年と見ている。


348 :デフォルトの名無しさん:2010/04/26(月) 12:51:11
今年の夏からFCDという制度そのものがなくなってしまうので、多分このまま
FCD→FDISと行くんじゃないかなあ。FDISは事実上の信任投票で
技術的変更は不可だから、FCD→FDISの間で「FDIS投票がこけないような修正」を
して終わりだと思う。

349 :デフォルトの名無しさん:2010/04/26(月) 12:54:20
ああでもTarget publication date: 2012-02-28なんて話題もあったっけ。
んー、もうあとは引き算だけだと思うんだけどねえ。

350 :デフォルトの名無しさん:2010/04/26(月) 19:45:01
noexceptは簡単には済まないと思うけどねえ
ムーブセマンティクスと例外の絡みで出てきた話だから引けばいいってもんでもないし

351 :デフォルトの名無しさん:2010/04/26(月) 21:12:42
noexceptは引き算されそうなにおいがぷんぷんするな。

352 :340:2010/04/26(月) 21:13:25
>>341-344
んで、無知なあなた方は、なんか俺に謝る事あるんじゃないの?

353 :デフォルトの名無しさん:2010/04/26(月) 21:16:43
うわっ キメェ^^

354 :デフォルトの名無しさん:2010/04/26(月) 21:19:42
既に実装されているものもあるのにねえ。


355 :デフォルトの名無しさん:2010/04/26(月) 21:21:18
引き算だけならいいけど、それが形を変えて戻ってきたら
実装済みのコンパイラ涙目

356 :デフォルトの名無しさん:2010/04/26(月) 21:24:56
掛け算されたりして
アッー!

357 :デフォルトの名無しさん:2010/04/26(月) 21:28:56
>>353-354
で?
俺は実装の話なんて一言もしていないが。

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


358 :デフォルトの名無しさん:2010/04/26(月) 21:48:30
どうも。ご迷惑おかけしています。アホです。

359 :デフォルトの名無しさん:2010/04/26(月) 22:04:10
あんたが正しいか正しくないかじゃなくて、
こんな2ちゃんごときで謝れとか言い出すあんたの器量の狭さがキモいんですよ^^

360 :デフォルトの名無しさん:2010/04/26(月) 22:08:05
>>357
pgr

361 :デフォルトの名無しさん:2010/04/26(月) 22:33:47
はいはいごめんやさいごめんやさい

362 :340:2010/04/26(月) 22:47:55
>>358-361
んで結局お前らは全員が知ったかぶりだったってことでいいんだな?

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

363 :デフォルトの名無しさん:2010/04/26(月) 23:19:11
はーい^^

364 :デフォルトの名無しさん:2010/04/26(月) 23:24:49
おまえら明日VS2010でたら色々遊んでレポートしなさい

365 :デフォルトの名無しさん:2010/04/27(火) 15:47:12
本の虫のブログで初めて知った。
deleted定義
ttp://cpplover.blogspot.com/2010/04/deleted.html

これすげー便利だな。


366 :デフォルトの名無しさん:2010/04/27(火) 17:14:01
>>365
予約語deleteの再利用か。
exportは仕事 首になったからまさに完全ニートになってるけど、
予約語としては生き残っているらしいから、
なんか有効利用してあげられないかな?

367 :デフォルトの名無しさん:2010/04/27(火) 17:28:30
concurrency/atomics 周りが GCC 4.6, 4.7 あたりで
完全にサポートされるようになるとはとても思えない……

368 :デフォルトの名無しさん:2010/04/27(火) 20:14:10
本の虫がそこに気付いてなかったとは…

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

369 :デフォルトの名無しさん:2010/04/27(火) 20:16:31
俺もメンバ関数にしか使えないのかと思ってた

370 :デフォルトの名無しさん:2010/04/27(火) 20:17:33
ほほうそれは Tの修飾をどの程度含んで殺してしまうのかね?

371 :デフォルトの名無しさん:2010/04/27(火) 20:22:25
>>367
gccはその辺は一番遅いでしょ。
昔みたいにx86専用フォークあれば別だけど。

372 :デフォルトの名無しさん:2010/04/27(火) 21:31:40
deleteに続いて併せて使われる予定のdefaultはなんだか微妙な感じだな。
純粋仮想関数よりは見た目はいいが。

373 :デフォルトの名無しさん:2010/04/27(火) 21:51:32
=defaultも大事だぞ

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

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

374 :デフォルトの名無しさん:2010/04/27(火) 21:55:43
Point() {} と何が違うんだっけ
inline強制じゃないんだっけ?

375 :デフォルトの名無しさん:2010/04/27(火) 22:20:02
Point(){}はコンパイラ生成のデフォルトコンストラクタじゃない=PointはPODじゃない

376 :デフォルトの名無しさん:2010/04/27(火) 22:23:23
コンストラクタつきのPodが可能になるのか

377 :デフォルトの名無しさん:2010/04/27(火) 22:54:25
Podってキャピタライズされると地味に違和感

378 :デフォルトの名無しさん:2010/04/27(火) 23:02:40
デフォルトコンストラクタだけデフォルトでも
他が違えば意味ないんじゃないの? >POD

379 :デフォルトの名無しさん:2010/04/27(火) 23:09:53
コピコン、operator=、デストラクタは書かなけりゃデフォルトだからいいの

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

380 :デフォルトの名無しさん:2010/04/27(火) 23:40:17
だから Point() {} と何が(ry
デフォルトのコピコンやoperator=をprivateにしたい時に使うのは便利そうだけど

381 :デフォルトの名無しさん: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になるとかならないとか

382 :デフォルトの名無しさん:2010/04/27(火) 23:56:55
新しい関数宣言やラムダって当初のまんまなの?

383 :デフォルトの名無しさん:2010/04/27(火) 23:59:04
>>381
なーるほど
それだと重要だな

384 :デフォルトの名無しさん:2010/04/27(火) 23:59:55
そういや、デフォルトのコピコンやoperator=を殺したければdeleteすりゃいいんだった

385 :デフォルトの名無しさん:2010/04/28(水) 00:07:36
>>382
unified function syntaxはボツになりました…

386 :デフォルトの名無しさん:2010/04/28(水) 00:11:31
unified function syntaxはクソだったからな。
不細工すぎるだろ

387 :デフォルトの名無しさん:2010/04/28(水) 00:12:29
やっぱりあれはボツだよなあw
安心した

388 :デフォルトの名無しさん:2010/04/28(水) 00:13:43
>380
default constructor が trivial か non-trivial かの違いになります.
で,この違いがどうなるかというと結構大量にあるっぽいので
誰か親切な人まとめてください.

389 :デフォルトの名無しさん:2010/04/28(水) 00:18:50
>>387
うむ。
いくら何でもなぁ。

390 :デフォルトの名無しさん:2010/04/28(水) 00:23:10
POD って C++0x でそれほど重要な概念になってます?

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

391 :デフォルトの名無しさん:2010/04/28(水) 00:26:34
そういやドラフトでPOD関連全般にもの凄い修正入ってた気がするわ
多すぎて目を通してなかったけど

392 :デフォルトの名無しさん:2010/04/28(水) 00:28:05
最後にまともにC++に触ったの10年くらい前で、既にJavaに移行してしまった者なんだが、
お前らが何を言ってるのかさっぱり分からん。

393 :デフォルトの名無しさん:2010/04/28(水) 00:32:11
多分ずっとC++使ってる人でも分からないから問題ない

394 :デフォルトの名無しさん:2010/04/28(水) 00:33:21
PODの重要性は今までと一切変わらんよ
CのAPIに渡したりバイトの塊としてストリームに流せたりすることを保証する枠組みは絶対に必要

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

395 :デフォルトの名無しさん:2010/04/28(水) 00:35:53
いったいなんなんだC++って。


396 :390:2010/04/28(水) 00:43:19
>394
>CのAPIに渡したり〜
この部分は完全に同意していて, >390 は単に
>文言の登場頻度は減った
んじゃないの? っていうのが言いたかっただけです.すいません.

397 :デフォルトの名無しさん:2010/04/28(水) 03:23:06
どうでもいいじゃない、そんなこと。
PODの概念が具体的な形で整理されたことが大切。

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

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


398 :デフォルトの名無しさん:2010/04/28(水) 12:12:53
>>397
さすが移植用アセンブラたるC言語の直系の子孫。
いつまでも変態記法と低レベル作業を忘れないでね。


399 :デフォルトの名無しさん:2010/04/28(水) 13:24:24
変態な君が好き。

400 :デフォルトの名無しさん:2010/04/28(水) 15:56:12
変態紳士な貴方も、チェリーボーイな君も、ウィザードハッカーな彼も。
みんな大好きC++。

401 :デフォルトの名無しさん:2010/04/28(水) 16:03:50
むしろそういうヤツしか大好きじゃないんじゃないかなC++


402 :デフォルトの名無しさん:2010/04/28(水) 18:45:05
俺ってウィザードハッカーだったのか

403 :デフォルトの名無しさん:2010/04/28(水) 19:11:38
C++はメジャーな言語です。
メジャーな言語を使えるプログラマーは変態ではありません。技術者です。

404 :デフォルトの名無しさん:2010/04/28(水) 23:33:57
高級アセンブラって褒め言葉にしか聞こえない。

405 :デフォルトの名無しさん:2010/04/29(木) 02:35:09
C99と違ってMSも実装に前向きみたいだけど
0xってどれだけ普及するだろうか

406 :デフォルトの名無しさん:2010/04/29(木) 02:44:43
正直「C++で開発してます」と言ってる業界のtemplateの普及度すら怪しい

407 :デフォルトの名無しさん:2010/04/29(木) 02:46:29
凄い的確な返しだ

408 :デフォルトの名無しさん:2010/04/29(木) 03:04:45
>>406
templateは保守性が低いから使うな!ってよく言われるよ。
lambdaなんぞ入ったらどうなることやら…。

409 :デフォルトの名無しさん:2010/04/29(木) 03:15:55
保守性が低い、の意味が、
俺らが読めない、だからなあ

410 :デフォルトの名無しさん:2010/04/29(木) 08:54:11
ある意味真理

411 :デフォルトの名無しさん: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
上の文はまだ修正される可能性があるのでしょうか?

412 :デフォルトの名無しさん:2010/04/29(木) 09:24:11
分かる人間がいなきゃ企業としては保守性低いわなぁw
概念的にはそんなに難しいものじゃないけど
ヘッダに実装書くことによる細かいバッドノウハウはちょっとだるい

413 :デフォルトの名無しさん:2010/04/29(木) 09:27:05
>>411
POD型のデフォルトコンストラクタは0クリアじゃないの?

414 :デフォルトの名無しさん:2010/04/29(木) 10:45:16
>413
thanks.
default constructed とは value-initialized(8.5) と同じ意味なんですね。

415 :デフォルトの名無しさん:2010/04/29(木) 10:48:13
古いVC++だと初期化されなかったような気がする
所詮規格は規格であって実装で無視されたら意味ないしなあ

416 :デフォルトの名無しさん:2010/04/29(木) 10:48:55
いや、あれはvectorじゃなかったか・・・?
記憶が曖昧だ・・・
違うかもしれない

417 :デフォルトの名無しさん:2010/04/29(木) 12:13:29
VC10express使った人いる?
どうかな?対応具合は?

418 :デフォルトの名無しさん:2010/04/29(木) 13:28:25
XP SP2には対応していなかった

419 :デフォルトの名無しさん:2010/04/29(木) 18:31:41
誰もそんなこと聞いてねぇw

420 :デフォルトの名無しさん:2010/04/29(木) 19:36:54
ワロタw
でも地味に良い情報だったw


421 :デフォルトの名無しさん:2010/04/29(木) 21:10:51
対応してないのか、単に保証してないか、どっちなんだろう
単にSP2自体サポート終了してるから対象から外しただけな気もするが

422 :デフォルトの名無しさん:2010/04/29(木) 22:23:01
A がムーブコンストラクタを持つ状態で

A foo() { return A(); }

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

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

423 :デフォルトの名無しさん:2010/04/29(木) 22:25:45
>>415
> 古いVC++だと
古いVC++なんて、それを言って良いならいくらでもそんなことはあるだろうよ。

424 :デフォルトの名無しさん:2010/04/29(木) 22:34:13
>>422
それだけだと右辺値参照する側がいないんじゃないか。

425 :デフォルトの名無しさん:2010/04/29(木) 22:40:03
受け取るやつがいるいないは関係なくない?
どこから呼ばれるかコンパイル単位には分からないわけだし

426 :デフォルトの名無しさん:2010/04/29(木) 22:42:07
>>422
ムーブコンストラクタがあればそっちで、なければコピーコンストラクタ、でしょ。
そうじゃないと困りそう。

427 :デフォルトの名無しさん:2010/04/29(木) 22:48:57
>>424
戻り値最適化がないなら、
return に書いた式から、関数の戻り値へとコピーかムーブが走ると期待できる

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

428 :デフォルトの名無しさん:2010/04/29(木) 22:55:37
もう1つ、

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

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

429 :デフォルトの名無しさん:2010/04/29(木) 22:58:37
VC++2010、地味にヤバそうな予感
まだゴリゴリ書かない方がいいのか・・・ って、何か問題起きたら 2008に持ってけばいいのかw


430 :デフォルトの名無しさん:2010/04/29(木) 23:00:14
いや、すまん
>>428 は後者も最適化されてコピーもムーブも動かないわ

431 :デフォルトの名無しさん:2010/04/29(木) 23:02:53
ムーブコンストラクタはそんなに神経質に使うものじゃなくないか?適用されたら儲け程度に考えればいいんじゃね。

432 :デフォルトの名無しさん:2010/04/29(木) 23:09:23
void hoge(A&& a) {
 a.piyo(); // piyoは非constメンバ関数

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

hoge(A());

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

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

433 :デフォルトの名無しさん:2010/04/29(木) 23:12:59
>>432
ムーブしたかったら A b(std::move(a)) じゃないか?

434 :デフォルトの名無しさん:2010/04/29(木) 23:14:57
>>432
そこで勝手にmoveしちゃったらその後のaはどうなるんだよ

435 :デフォルトの名無しさん:2010/04/29(木) 23:14:57
>>433
おお、そうなんだ
そうしたらムーブコンストラクタが呼ばれたわ
ありがとう

436 :デフォルトの名無しさん:2010/04/29(木) 23:15:59
>>434
あとは野となれ山となれ

437 :デフォルトの名無しさん:2010/04/29(木) 23:22:26
というか、>>422 のエラー発生状況の説明が
「'A' から 'A &&' への変換時」ってなってるな
どうもムーブコンストラクタを呼ぼうとはしているみたいだ
でも、なぜかコピーコンストラクタがアクセス可能じゃないとダメ、と

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

438 :デフォルトの名無しさん:2010/04/29(木) 23:24:40
名前付きの値は(左辺値参照でも右辺値参照でも)左辺値として扱われる。
>>432 の例でいうとaをムーブコンストラクタに渡すには
std::moveの返値(無名の右辺値参照)にしなければいけないわけだ。
なるほど。

439 :デフォルトの名無しさん:2010/04/29(木) 23:27:24
>>438
なるほど
ムーブコンストラクタがあっても、
左辺値でコンストラクとしようとする時には
勝手に右辺値参照になってはくれないのね
確かに安全のためには必要そうな仕様だ

440 :デフォルトの名無しさん:2010/04/29(木) 23:40:37
ひょっとして、ムーブ可能にしたければ
コピーも可能じゃないとだめというのが仕様だとか?
でも、MoveConstructible requirements にそういう事は書いてないし・・・

441 :デフォルトの名無しさん:2010/04/30(金) 02:11:51
>427
>publicなムーブコンストラクタとprivateなコピーコンストラクタを定義したら、
>コピーコンストラクタが使えないよというエラーになるから

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

442 :デフォルトの名無しさん:2010/04/30(金) 02:18:31
422==432で書いてたコードand/or考えが間違ってたんだろう

443 :デフォルトの名無しさん:2010/04/30(金) 03:01:44
不思議な事に、こっちでも新しく書いたら再現しない
条件があるのかも

444 :デフォルトの名無しさん:2010/04/30(金) 03:06:11
めっちゃアンドゥして昔のコードに戻したけどやはり再現しない・・・
一体なんなんだ

445 :デフォルトの名無しさん: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時に死ぬ

クラスとかなら問題ない

446 :デフォルトの名無しさん:2010/04/30(金) 04:13:09
new autoとかありだということに驚いた

447 :デフォルトの名無しさん:2010/04/30(金) 06:30:36
最後はdelete[]だろ

448 :デフォルトの名無しさん:2010/04/30(金) 07:18:27
>>445
どのコンパイラくらい書いてくれ。

449 :デフォルトの名無しさん:2010/04/30(金) 08:18:51
死ぬってのは実装の問題ってこと?

450 :デフォルトの名無しさん:2010/04/30(金) 08:35:12
VC++2010で試したら確かに実行時エラーで死んだ。
誰かGCCで試してみてほしい。

451 :デフォルトの名無しさん:2010/04/30(金) 08:51:30
なんだこのスレタイと全然関係無い話題なのに
妙に価値のある内容は。





もっとやれ

452 :デフォルトの名無しさん:2010/04/30(金) 09:50:00
>>445
g++-4.5 (Debian 4.5.0-2) 4.5.1 20100419 (prerelease)
だと死なない(そりゃそうだ)

453 :デフォルトの名無しさん:2010/04/30(金) 10:47:13
>>447
ポインタをnewしてるだけだからdeleteで問題ない

454 :デフォルトの名無しさん:2010/04/30(金) 11:39:19
new auto("hoge") は const char**

455 :デフォルトの名無しさん:2010/04/30(金) 12:45:29
deleteかdelete[]かを判断できないのだからnew auto(ここの部分);で、動的にdeleteかdelete[]かを選べるshared_ptrみたいな動的削除子が組み込みで欲しいな。

456 :デフォルトの名無しさん:2010/04/30(金) 12:47:09
          expression
         /     \
       glvalue     rvalue
     /    \  /    \
   lvalue     xvalue    prvalue

Figure 1 -- Expression category taxonomy

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

457 :デフォルトの名無しさん:2010/04/30(金) 12:48:04
>>455
new auto で確保したものは常に delete
配列 new を初期化パラメータ付きで行うのは不可能だから

458 :デフォルトの名無しさん:2010/04/30(金) 12:51:23
そうだった。つまりこれはnew autoしたのをdeleteする処理系が悪いということか。

459 :デフォルトの名無しさん:2010/04/30(金) 12:55:10
new autoは実はGCが働くんだよ!

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

460 :デフォルトの名無しさん:2010/04/30(金) 12:57:51
newしてるのにポインタじゃなくてスマポが返るんですね分かります

461 :デフォルトの名無しさん:2010/04/30(金) 13:07:33
>>456
仮想継承にしなくちゃならないなw

462 :デフォルトの名無しさん:2010/04/30(金) 13:12:08
>>456
シンプルやん。
対称だと頭に入りやすい。

463 :デフォルトの名無しさん:2010/04/30(金) 13:30:37
          expression
         /     \
       lvalue     rvalue
     /    \  /    \
   plvalue     xvalue    prvalue

これなら対称なんだけど

464 :デフォルトの名無しさん:2010/04/30(金) 13:32:57
>>463
機能まで対称だったらわざわざ仮想継承構造にする必要ないけどな

465 :デフォルトの名無しさん:2010/04/30(金) 13:35:43
lvalue &
rvalue &&
prvalue &&&
になりそうな予感

466 :デフォルトの名無しさん: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がコピーされるから、
それを変更すると次の呼び出しでもその影響が残るのは
仕様でいいのよね?

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

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

468 :デフォルトの名無しさん:2010/04/30(金) 15:15:49
>>465
> lvalue &
> rvalue &&
> prvalue &&&
何気に分かりやす・・・くねぇな


469 :デフォルトの名無しさん:2010/04/30(金) 17:34:03
って、規格上はラムダ式は関数ポインタに変換できるのか……
今年3月の話みたいだから対応して無いのは当然だけど

470 :デフォルトの名無しさん:2010/04/30(金) 17:38:11
関数ポインタよりもresult_typeが欲しいよ。

471 :デフォルトの名無しさん:2010/04/30(金) 18:09:13
std::functionにキャストすれば使えるんじゃないの>result_type

472 :デフォルトの名無しさん:2010/04/30(金) 19:06:02
>>471
なんと、その手があったのか。改めてfunctionはすごいな。
ラムダ式をboost::lambdaでラップしようかとか悩んでた。

473 :デフォルトの名無しさん:2010/04/30(金) 21:11:54
swap技法が適用されるデフォルトムーブ演算子operator=(&&)とかできないかなあ。

474 :デフォルトの名無しさん:2010/04/30(金) 21:40:51
デフォルトムーブ代入演算子なら最新のドラフトに入ったよ

475 :デフォルトの名無しさん:2010/04/30(金) 23:09:11
戻り値の型を auto にして trailing return type を省略し
return する値の型を全て同じにすれば
戻り値の型を自動的に類推してくれる、
という仕様は検討された事ないのかな
それがあれば関数をカリー化して返せるんだが

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

476 :デフォルトの名無しさん:2010/04/30(金) 23:14:48
>>474
おおっとそれはすごい。VC10にいつかはサポートされるかな。
現状のVC10はどこまでサポートされてるのかさっぱり分らない。SPが出るたびに調整かw

477 :デフォルトの名無しさん:2010/04/30(金) 23:29:33
>>475

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

で我慢しろ

478 :デフォルトの名無しさん: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

479 :デフォルトの名無しさん:2010/05/01(土) 00:02:33
Unified Function Syntaxも戻り値の型推測入れればいいのに

480 :デフォルトの名無しさん:2010/05/01(土) 00:15:10
>>475
宣言だけの場合は?

481 :デフォルトの名無しさん:2010/05/01(土) 01:14:15
>>480
inline や template と同様、ヘッダにしか書けない
ただし、static を明示的につけない限り、リンク時に実体は1つにまとめられる
宣言だけ書くことはできるが、同じ翻訳単位に定義が必要

みたいな感じで

482 :デフォルトの名無しさん:2010/05/01(土) 01:15:40
×ヘッダにしか書けない
○複数の翻訳単位から利用するにはヘッダにしか書けない

483 :デフォルトの名無しさん:2010/05/01(土) 01:18:30
まあ、同じ定義を自分で複数の翻訳単位に書いてもいいんだけど
それはそれこれはこれということで

484 :デフォルトの名無しさん:2010/05/01(土) 01:38:18
>>478
ありがとう。対応状況が一目で分かって助かります。

485 :デフォルトの名無しさん: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);


486 :デフォルトの名無しさん:2010/05/01(土) 11:30:56
どういう使い方するかによるんじゃない
普通は一方をもう一方の情報を使って変更して
変更したオブジェクトを返すという形にすると思うけど

487 :デフォルトの名無しさん:2010/05/01(土) 13:19:54
VC10で is_pod<void>::value がtrueになるのは相変わらずか。

488 :デフォルトの名無しさん:2010/05/01(土) 16:03:18
>>485
なるほど、通常は片方だけですむってことなのか。

489 :デフォルトの名無しさん:2010/05/02(日) 04:07:58
ラムダ面白いな。
てきとーにVC10ee触ってるんだが、ラムダって制限つきローカル関数のように使えるな。
さらに便利かも。

490 :デフォルトの名無しさん:2010/05/02(日) 08:57:41
確かにfor_eachなどに直接渡すだけじゃなく、ローカル関数として使えるね
これでいちいち関数内に構造体作る必要がなくなったわ
しかもメンバにも直接アクセスできるし

491 :デフォルトの名無しさん:2010/05/02(日) 09:48:03
ラムダ関数はresult_typeを定義してくれてたら完璧なんだけど

492 :デフォルトの名無しさん:2010/05/02(日) 12:15:28
その辺はconceptで整備するつもりだったんだろうけど…
function_traitsを定義するんで凌ぐのかな。

493 :デフォルトの名無しさん:2010/05/02(日) 15:36:14
>>490
メンバにもアクセスできるの?!

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

494 :デフォルトの名無しさん:2010/05/02(日) 15:39:58
環境いじれないのはlambda式じゃないぜ…

495 :デフォルトの名無しさん:2010/05/02(日) 16:43:10
thisをキャプチャすればメンバに触れる
どうせ[=]か[&]にするだろうから
自動的にキャプチャされるだろうが

496 :デフォルトの名無しさん:2010/05/02(日) 19:02:42
むしろthisがキャプチャされない場合って...?

497 :デフォルトの名無しさん:2010/05/02(日) 19:36:34
[]にしたい時だってある

498 :デフォルトの名無しさん:2010/05/02(日) 20:48:36
引数しか使わない
そんな気分の時があります

499 :デフォルトの名無しさん:2010/05/02(日) 20:59:31
キャプチャってなんだーー!!!

ああ、0xのLambda式か。

500 :デフォルトの名無しさん:2010/05/03(月) 00:01:17
autoって本当に便利ですね。てかテンプレートには必須だよ。


501 :デフォルトの名無しさん:2010/05/03(月) 00:08:41
キャプチャしない場合でも、[&][=]って書いてもペナルティはない?
紛らわしいからやめろと言われればその通りなんだが、コンパイラがどういうコードを吐くのか気になる

502 :デフォルトの名無しさん:2010/05/03(月) 00:15:16
最適化すりゃ消える

503 :デフォルトの名無しさん:2010/05/03(月) 00:15:56
むしろ追加でコード生成されんの?

504 :デフォルトの名無しさん: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


505 :デフォルトの名無しさん:2010/05/03(月) 00:29:10
すまん,キャプチャの意味がわかってなかった...

506 :デフォルトの名無しさん:2010/05/03(月) 00:43:19
>>504
おばか

507 :デフォルトの名無しさん:2010/05/03(月) 00:49:10
省略の意味がちげえw

508 :デフォルトの名無しさん:2010/05/03(月) 05:56:52
>>502
コピコンのあるようなものがいらっしゃると消えてくれないかも

509 :デフォルトの名無しさん:2010/05/03(月) 09:42:06
[](int x){return x;}

510 :デフォルトの名無しさん:2010/05/03(月) 10:45:04
->int とかの trailing-return-type って普通の関数定義にも使えるんだな
用途がよくわからんが

511 :デフォルトの名無しさん: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なら大丈夫なんだろうけど。


512 :デフォルトの名無しさん:2010/05/03(月) 11:06:26
>>507 kwsk

513 :デフォルトの名無しさん:2010/05/03(月) 12:50:15
>>510
template <typename T>
auto foo(T a, T b) -> decltype(a + b) { return a + b; }

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

514 :デフォルトの名無しさん:2010/05/03(月) 12:54:00
あとは auto foo() -> int(*)(); とか、関数ポインタや配列ポインタを返しやすいとか

515 :デフォルトの名無しさん:2010/05/03(月) 12:57:20
そういやlambdaはDLLにexportできるようになるんかな?

516 :デフォルトの名無しさん:2010/05/03(月) 12:58:54
exportするなら普通の関数でええやんという話

517 :デフォルトの名無しさん:2010/05/03(月) 12:59:27
>>509 あ、そうか。そうだような。俺が馬鹿でした。
でもさすがにC#のように引数の型を省略 auto z3=[](x){return x*2;}; は無理?とおもったけど。
auto z4=boost::lamabda::_1*2; はOKなのね。boost::lambda恐るべし。

518 :デフォルトの名無しさん:2010/05/03(月) 13:02:53
C#の型推論はデリゲート側と型を一致させるというしくみだから
autoで受けるC++0xではまあ使えないわなあ

519 :デフォルトの名無しさん:2010/05/03(月) 13:10:52
>>513-514
なるほど、納得。

520 :デフォルトの名無しさん:2010/05/03(月) 13:13:25
どんどん初心者お断りで複雑怪奇な仕様になっていってる気がする…

521 :デフォルトの名無しさん:2010/05/03(月) 13:14:46
なにをいまさら

522 :デフォルトの名無しさん:2010/05/03(月) 13:15:43
カンタンカンタン

523 :デフォルトの名無しさん:2010/05/03(月) 14:41:40
>511

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



524 :デフォルトの名無しさん:2010/05/03(月) 16:44:54
>>523
実行文字集合に無い文字は、翻訳段階5でいったん文字化けさせろって書いてない?
「文字(列)リテラル中のユニバーサルキャラクター名は、実行文字集合中の対応物に置き換える」

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


525 :デフォルトの名無しさん:2010/05/03(月) 20:40:41
>>520
分かる部分だけ使ってりゃいいって

526 :デフォルトの名無しさん:2010/05/03(月) 21:01:41
コンセプトが入ってればエラーメッセージが(以下略

527 :デフォルトの名無しさん:2010/05/04(火) 00:06:10
C++0xはよく考えられた改良だと思うけど
互換性のために殆どが「追加」になっちゃうんだよね
便利でシンプルで完全に動作するC++のサブセットって定義できんもんだろうか

528 :デフォルトの名無しさん:2010/05/04(火) 00:08:11
互換性を無視したとして、いらない機能は何だろう?
つ可変引数


529 :デフォルトの名無しさん:2010/05/04(火) 00:11:23
それは要るだろw
筆頭は0=ヌルポインタだな。

530 :デフォルトの名無しさん:2010/05/04(火) 00:13:03
古い(というか従来の)関数宣言
struct か class のどちらか
古い(というか従来の) enum

531 :デフォルトの名無しさん:2010/05/04(火) 00:17:07
typedef

532 :デフォルトの名無しさん:2010/05/04(火) 00:17:40
型変換演算子の廃止

533 :デフォルトの名無しさん:2010/05/04(火) 00:18:19
コピコンとデフォコンの特殊ルール

534 :デフォルトの名無しさん:2010/05/04(火) 00:19:06
unsigned全部

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

536 :デフォルトの名無しさん:2010/05/04(火) 00:32:07
>>529
printfみたいに引数の検査ができな可変引数よりも、
cout<<a<<b; とか boost::format("%d %d")%a&b;
とかてC++の機能で代用できるもので可変引数は廃止でいいんじゃないか?

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

537 :デフォルトの名無しさん:2010/05/04(火) 00:34:21
boost::format("%d %d")%a%b; だった。

538 :デフォルトの名無しさん:2010/05/04(火) 00:43:08
これだろ…
std::vector<bool>

539 :デフォルトの名無しさん:2010/05/04(火) 00:48:27
1パスコンパイル

540 :デフォルトの名無しさん:2010/05/04(火) 00:49:54
bind1st , bind2nd, fun_ptr

541 :デフォルトの名無しさん:2010/05/04(火) 00:51:57
>>536
printfを例に出すとは素質悪いな

542 :デフォルトの名無しさん:2010/05/04(火) 00:56:10
禿の新しいC++本(Programming: Principles and Practice Using C++)で
10行程度しか触れられていない
valarray

543 :デフォルトの名無しさん:2010/05/04(火) 00:56:45
互換性を無視していいならいらない機能の筆頭は、暗黙の変換
バグの元

544 :デフォルトの名無しさん:2010/05/04(火) 00:59:15
アップキャストがバグの元っていったい

545 :デフォルトの名無しさん:2010/05/04(火) 01:00:58
>>544
non-explicitなコンストラクタとかoperator T()のことじゃない?

546 :デフォルトの名無しさん:2010/05/04(火) 01:02:40
整数の暗黙の拡張とか

547 :デフォルトの名無しさん:2010/05/04(火) 01:10:06
暗黙の変換というか標準変換の一部と言うべきなのか
要するに数値型間の暗黙の変換

548 :デフォルトの名無しさん:2010/05/04(火) 01:57:08
charをintegral typeから外して、integral type最小のbyteを設ける。

549 :デフォルトの名無しさん:2010/05/04(火) 01:59:30
暗黙の型変換なくす人、
xがintの時、式 x * 3.14 の型はintでOK?

550 :デフォルトの名無しさん:2010/05/04(火) 02:00:56
コンパイルエラー

551 :デフォルトの名無しさん:2010/05/04(火) 02:02:56
>>549
#pragma yutori
ならばOK


552 :デフォルトの名無しさん:2010/05/04(火) 02:05:09
整数の拡張って何がまずいん?

553 :デフォルトの名無しさん:2010/05/04(火) 02:10:00
unsigned int x = -1;
がコンパイルできちゃう

554 :デフォルトの名無しさん:2010/05/04(火) 02:21:52
static_cast使いまくりで可読性が悪くなりそう

555 :デフォルトの名無しさん:2010/05/04(火) 02:28:01
>>491
result_ofが使えればいいよ。

556 :デフォルトの名無しさん:2010/05/04(火) 02:29:28
>>553
警告が出るからいいんじゃね?

557 :デフォルトの名無しさん:2010/05/04(火) 02:32:38
数値の暗黙の拡張にこれほど疑問や反論がでるのは予想外だった
正直、ほとんどの人に共通の認識だと思ってた

558 :デフォルトの名無しさん: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);
}


559 :デフォルトの名無しさん:2010/05/04(火) 06:01:55
-Wsign-conversion で警告がでるな

560 :デフォルトの名無しさん:2010/05/04(火) 11:10:01
-Wextra

561 :デフォルトの名無しさん:2010/05/04(火) 11:48:53
-Warata

562 :デフォルトの名無しさん:2010/05/04(火) 11:53:26
-Wwwwwwww

563 :デフォルトの名無しさん:2010/05/04(火) 12:09:41
多少ずれるが
unsigned変数の小なり0比較はエラーにすべき

564 :デフォルトの名無しさん:2010/05/04(火) 12:52:01
>>563
警告出して最適化してくれれば十分だと思う。
テンプレート使ってるとsignedとunsinged両方使えるようにするとき役に立つ。
警告なら必要に応じて抑制できるけど、エラーだとsignedとunsingedで分岐するテンプレートを書く必要が出てきて面倒。


565 :デフォルトの名無しさん:2010/05/04(火) 12:54:21
最適化というのは,勝手にsigned変数に変更するということ?
それとも比較元を+1して小なり1比較ってこと?

566 :デフォルトの名無しさん:2010/05/04(火) 12:55:00
いや、常にfalse判定じゃないかと

567 :デフォルトの名無しさん:2010/05/04(火) 13:01:05
うんfalse判定でifのtrue項が削除されてとりあえず警告。その箇所だけpragmaで警告抑制。


568 :デフォルトの名無しさん:2010/05/04(火) 14:48:38
>>563
エラーにするのはループ条件に出てきた時だけでいい
その他の場合はフェイルセーフで書く事もあるので警告すら出て欲しくないな

569 :デフォルトの名無しさん:2010/05/04(火) 15:37:34
>>568
ループ条件に出てきたときはループ削除でよくない?エラーはやりすぎでしょう。

570 :デフォルトの名無しさん:2010/05/04(火) 15:39:53
>>569
ごめん
別な条件の方で考えてた
(unsigned)x >= 0 の方

571 :デフォルトの名無しさん:2010/05/04(火) 19:07:10
-Wallでも警告されずバグを埋め込んだ例
https://bugzilla.kernel.org/show_bug.cgi?id=12597

572 :デフォルトの名無しさん:2010/05/04(火) 20:28:37
>>571
すげー
Linus Torvalds の生コメントがある!

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

573 :デフォルトの名無しさん:2010/05/04(火) 21:36:18
enum class って劣化 Java の enum だよね
Java の enum そのものにしてくれないかなぁ・・

574 :デフォルトの名無しさん:2010/05/04(火) 22:21:57
どちらかといえばC#のenumが近い

575 :デフォルトの名無しさん:2010/05/04(火) 22:26:04
それは確かに否め(enumえ)ない

576 :デフォルトの名無しさん:2010/05/04(火) 22:39:39
>>573
Java の enum ってどういう挙動なんだか知らんが
そんなに良いのか?

577 :デフォルトの名無しさん:2010/05/04(火) 22:56:31
Javaのenumはクラスに近くて、
要素の宣言でコンストラクタに渡すパラメータを指定できる。

578 :デフォルトの名無しさん:2010/05/04(火) 23:03:51
>>577
ふーん。ありがとう。

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


579 :デフォルトの名無しさん:2010/05/04(火) 23:19:42
enumとして正しい値かどうか検査するメンバ関数とか
enum名を文字列で返すメンバ関数とか欲しいわ

580 :デフォルトの名無しさん: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++にも同等の機能入れてくれないかな

581 :デフォルトの名無しさん:2010/05/04(火) 23:59:20
そこまでするならクラスでいいじゃん、と思う

582 :デフォルトの名無しさん:2010/05/05(水) 00:06:13
先生!!メリットがわかりませんん!!

583 :デフォルトの名無しさん:2010/05/05(水) 00:10:28
enum class {} というのは指定したクラスのconstインスタンスを名前を
付けて列挙するものという意味付けにすれば後は何でも出来そうな。

584 :デフォルトの名無しさん:2010/05/05(水) 00:21:49
Scala の case class の超絶しょぼい版という印象だな > Java の enum

585 :デフォルトの名無しさん:2010/05/05(水) 00:22:54
演算子のオーバーロードは今のenumでもできるが

586 :デフォルトの名無しさん:2010/05/05(水) 00:28:55
Javaほど機能詰めすぎると逆にイミフなような…

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

587 :デフォルトの名無しさん:2010/05/05(水) 00:39:09
ToStringは欲しかった

588 :デフォルトの名無しさん:2010/05/05(水) 00:58:06
boost::lexical_cast

589 :デフォルトの名無しさん:2010/05/05(水) 01:10:52
typeidのnameをもっとまともに規定してほしかった。

590 :デフォルトの名無しさん:2010/05/05(水) 01:16:59
>>588
それもSTLコンテナの場合、operator<<が定義されてないから使えないんだよな……

591 :デフォルトの名無しさん:2010/05/05(水) 01:23:39
自分で定義すれば良いんじゃね?

592 :デフォルトの名無しさん:2010/05/05(水) 01:32:26
>>589
ちゃんと読める名前を返すものと、一意性さえあればいいものと、2つ用意して欲しいわ

593 :デフォルトの名無しさん:2010/05/05(水) 01:36:48
typeidの名前の文字列をバイナリに含めるか含めないかのオプションが欲しい

594 :デフォルトの名無しさん:2010/05/05(水) 15:03:54
ラムダ式を関数ポインタに渡せるようになれば、
システムコールバックが使いやすくなるな
GCなしでどう実装するのか分からないが

595 :デフォルトの名無しさん:2010/05/05(水) 15:26:48
また来た

596 :デフォルトの名無しさん:2010/05/05(水) 23:30:16
>>578
classとstructの違いはデフォルトのアクセス性しかないのに
enum class とenum structで機能が違うのは紛らわしくね?

597 :デフォルトの名無しさん:2010/05/05(水) 23:52:10
template <struct T> がエラーなのと同様、
enum struct は不許可にすべき

598 :デフォルトの名無しさん: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] のように表示される。

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

599 :デフォルトの名無しさん:2010/05/06(木) 08:37:22
lambdaって関数の引数として渡したい場合はtemplate使うしかないの?
シグネチャが分かっててもダメなんかな。

600 :デフォルトの名無しさん:2010/05/06(木) 08:49:07
シグネチャが同じってoperator()のシグネチャが同じなだけで
キャプチャした変数によって型は違うんじゃないの?

601 :デフォルトの名無しさん:2010/05/06(木) 08:52:44
>>600
翻訳単位が違えば型も別になるしなぁ。
静的型付けが大前提だし、template使うしかないのか・・・

602 :デフォルトの名無しさん:2010/05/06(木) 09:38:55
ていうかlambdaのoperator()ってvirtualになってないのかな?
なってなさそうだなぁ

603 :デフォルトの名無しさん:2010/05/06(木) 12:03:19
ラムダ式はalgorithmと組み合わせて使う事がほとんどだろうから
virtualはあまり必要ないんじゃ?

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

604 :デフォルトの名無しさん:2010/05/06(木) 12:09:12
>>603
うん、C++的発想だとそうなるんだけど、つまりシグネチャ決めようがねーよなって話

605 :デフォルトの名無しさん:2010/05/06(木) 12:31:36
無理にやったらやったで出来ない事もないだろうが
ただでさえキモいラムダ式がさらにキモくなるな

606 :デフォルトの名無しさん:2010/05/06(木) 12:39:01
そういう強引な自己満コードを見たら今後は キモダ式 と呼ぶ事にするw


607 :デフォルトの名無しさん:2010/05/06(木) 13:53:03
C++0xが入るとBoostはさらにキモさをPowerUpするぜ間違いない

608 :デフォルトの名無しさん:2010/05/06(木) 13:57:02
いやな、VS2010で遊んでるんだが、ラムダ式かなり使えるよホント
これでBoost::lambdaはほとんど必要なくなるな

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

609 :デフォルトの名無しさん:2010/05/06(木) 14:37:53
Cの関数ポインタ自体がきったねぇことを考えると
もうラムダさんの服装は無難で妥当に思えてきたよ

610 :デフォルトの名無しさん:2010/05/06(木) 14:53:15
ラムちゃんの衣装は虎模様のビキニ

611 :610:2010/05/06(木) 14:54:01
誤爆しました


612 :デフォルトの名無しさん:2010/05/06(木) 17:46:38
VS2010のメリットはラムダさんとautoさんとdecltypeさんだけだからな
他のすべての点においてVS2008に劣っている

613 :デフォルトの名無しさん:2010/05/06(木) 18:50:40
VS2010は発売後直ちに数多くのバグ報告がされているからSP1は
早めに出るかも知れない

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

614 :デフォルトの名無しさん:2010/05/06(木) 18:59:36
最初のベータから0xの機能は増えてないんだよな

615 :デフォルトの名無しさん:2010/05/06(木) 19:52:03
>>612
rvalue reference の準拠文書が更新されてるってのを
Boost ML で見たような気がする。

616 :615:2010/05/06(木) 19:54:16
>>612 じゃなくて >>614 だった。

617 :デフォルトの名無しさん:2010/05/06(木) 20:21:29
VC2010は右辺値参照サポートしてライブラリも Move Semantics を実装してるんじゃなかったっけ?

618 :デフォルトの名無しさん:2010/05/06(木) 20:22:50
別にC++0xの規格がまだ定まっていない以上、
C++0xに関するバグはどれだけあろうがしょうがないんじゃない?

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

619 :デフォルトの名無しさん:2010/05/06(木) 20:24:22
最早スレチだと思うけど、インテリセンスがマシになったという噂

620 :デフォルトの名無しさん:2010/05/06(木) 20:45:35
C++/CLIはインテリセンス自体がなくなった

621 :デフォルトの名無しさん:2010/05/06(木) 20:56:45
>>620
なるほど。確かにインテリセンスのバグはなくなったな。

622 :デフォルトの名無しさん: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


623 :デフォルトの名無しさん:2010/05/06(木) 23:31:53
>>617
std::mapとstd::tr1::shared_ptrを使ってみたけど両方共右辺値参照サポートしてるね。


624 :デフォルトの名無しさん:2010/05/06(木) 23:34:07
>>619
インテリセンスはよく効くようになってきてるね。
エラーのハイライトの反映が遅いね。処理中は薄くするかステータスバーに表示して欲しいな。


625 :デフォルトの名無しさん:2010/05/07(金) 09:02:09
>>622
すげー

626 :デフォルトの名無しさん:2010/05/07(金) 13:36:52
>>622
この機能はすごいと思うがさすがに必要ない
関数テンプレートで簡単に実現できちゃうもんな

627 :デフォルトの名無しさん:2010/05/07(金) 20:40:14
>>626
ラムダは無名関数を作れるのがメリット

628 :デフォルトの名無しさん:2010/05/07(金) 20:55:55
>>627
メリットどころか存在意義じゃね。


629 :デフォルトの名無しさん:2010/05/07(金) 21:21:47
それなかったら何のためのラムダっちゃっていう

630 :デフォルトの名無しさん:2010/05/07(金) 21:31:17
アウトーーーーーーーーーーーーーーーー!!

631 :デフォルトの名無しさん:2010/05/07(金) 21:35:02
>>622
これってテンプレート型変換演算子でもつかってんのかな、と思って
実装を見てみたが正直意味がわからない

632 :デフォルトの名無しさん:2010/05/07(金) 21:36:31
>>622
これってテンプレート型変換演算子でもつかってんのかな、と思って
実装を見てみたが正直意味がわからない

633 :デフォルトの名無しさん:2010/05/07(金) 21:37:12
まさかの二重投稿……orz

634 :デフォルトの名無しさん:2010/05/08(土) 00:13:56
まさかの二重投稿……orz

635 :デフォルトの名無しさん:2010/05/08(土) 00:31:26
どうせなら、

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

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

636 :デフォルトの名無しさん:2010/05/08(土) 00:31:58
0x0 0w0

637 :デフォルトの名無しさん:2010/05/08(土) 02:57:47
>>599
シグネチャが分かっているならstd::function<>を使えばいいのではないでしょうか。

638 :デフォルトの名無しさん:2010/05/08(土) 11:13:09
lambdaと互換性あるのけ?

639 :デフォルトの名無しさん:2010/05/08(土) 11:14:37
なけりゃこれができん。

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

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

640 :デフォルトの名無しさん:2010/05/08(土) 11:19:25
>>639
シグネチャが指定したい場合はどう書けばいいの?

641 :デフォルトの名無しさん: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 ;
} ;


642 :デフォルトの名無しさん:2010/05/08(土) 15:46:56
ん?横やりだからよくわからないけど
>>599 は引数で lambda 関数を渡すときに template 使いたくないって話だよね?

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

f([]{});

と書けるってこと?

643 :デフォルトの名無しさん:2010/05/08(土) 17:29:05
関数ポインタに代入できるようにする提案が出てんじゃなかったっけ?
少しコストはかかるし、ラムダの寿命を越えるとダングリングポインタになるけど、
実装可能ではあるよ

644 :デフォルトの名無しさん:2010/05/08(土) 19:15:31
>>642
それはできない。prvalueは非constな参照では受けられない。
まあ、単なる間違いだろうけど。

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

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

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

645 :デフォルトの名無しさん:2010/05/08(土) 19:17:40
結局>>641が何を言いたかったのかよくわからないです

646 :デフォルトの名無しさん:2010/05/08(土) 22:26:34
>>644
ほー、そんな書き方ができるのか
便利だな

647 :デフォルトの名無しさん:2010/05/09(日) 08:33:58
属性って採用されるんだろうか
あまりにも文法キモいんだけど

648 :デフォルトの名無しさん:2010/05/09(日) 08:43:41
typedef int aligned_int __attribute__((aligned(128)));
こういう文法を使いつづけるほうが良いと?

649 :デフォルトの名無しさん:2010/05/09(日) 08:48:49
#pragma みたいに、どんなのを用意するか処理系次第ってんならいいんだけど、
規格で属性を提供されてもね
そういうのはキーワードにして欲しい

650 :デフォルトの名無しさん:2010/05/09(日) 09:14:02
その気持ちはわからなくもない

651 :デフォルトの名無しさん:2010/05/09(日) 10:40:44
overrideのような文法上意味があるものはキーワードのして欲しいな。

652 :デフォルトの名無しさん:2010/05/09(日) 10:44:05
overrideとかfinalとかalignとか
キーワードでいいじゃんと思う
キーワード増やしたくないのは分からなくはないが

653 :デフォルトの名無しさん:2010/05/09(日) 11:16:14
>>648
属性でそれがすっきりになるのか?

654 :デフォルトの名無しさん:2010/05/09(日) 11:29:39
記述が変わるだけだな

655 :デフォルトの名無しさん:2010/05/09(日) 11:54:10
迷い猫Override

656 :デフォルトの名無しさん:2010/05/09(日) 11:58:17
auto はっぴぃ = new にゃあ();

657 :デフォルトの名無しさん:2010/05/09(日) 11:59:45
オーバーロード
オーバーライド
オーバードライブ
オーバーフロー
アンダースコート
の違いがわかりません

658 :デフォルトの名無しさん:2010/05/09(日) 12:00:55
[[align]]はC1Xとの互換のためにalignas復活させろって提案が出てるね

659 :デフォルトの名無しさん:2010/05/09(日) 12:05:36
>>656
識別子に日本語使いたいなあ、C#が羨ましい

660 :デフォルトの名無しさん:2010/05/09(日) 12:12:02
vc++で使えるじゃん

661 :デフォルトの名無しさん:2010/05/09(日) 12:16:08
識別子に日本語使ってる人とは仕事したくねえな…

662 :デフォルトの名無しさん:2010/05/09(日) 12:16:43
C1XはC++0x以上に普及しないと思うがなあ
alignas復活するのならどうでもいいけど

663 :デフォルトの名無しさん:2010/05/09(日) 12:17:09
>>660
class にゃあ
{

664 :デフォルトの名無しさん:2010/05/09(日) 12:18:20
日本語識別子はタイピングコストは高いわ
誤字見つけにくい場合があるわで最悪だ

665 :デフォルトの名無しさん:2010/05/09(日) 12:18:51
なんだって!


class にゃあ
{};

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

666 :デフォルトの名無しさん:2010/05/09(日) 12:20:23
>>661
C#で漢字使えるから活用しようと提案したら、0.1秒で却下された。

667 :デフォルトの名無しさん:2010/05/09(日) 12:22:57
0.1秒も検討してくれたのか、凄いな

668 :デフォルトの名無しさん:2010/05/09(日) 12:24:01
コンパイル通らないと思ったら字体が違ってた

669 :デフォルトの名無しさん:2010/05/09(日) 12:24:39
神経の伝達速度を考慮に入れよ

670 :デフォルトの名無しさん:2010/05/09(日) 12:26:13
提案を最後まで述べる前に却下すればいい

671 :デフォルトの名無しさん:2010/05/09(日) 12:26:56
ようギルバート

672 :デフォルトの名無しさん:2010/05/09(日) 12:27:32
class 二ダ一 { ... };

ニダー ウり;

673 :デフォルトの名無しさん:2010/05/09(日) 12:28:58
日本語みたいな入力が面倒くさい言語で
プログラムなんか書いてらんない

674 :デフォルトの名無しさん:2010/05/09(日) 12:29:56
現時点でC++0x使ってるプロジェクトって何かある?

675 :デフォルトの名無しさん:2010/05/09(日) 12:35:57
流石に気が早すぎるだろ

676 :デフォルトの名無しさん:2010/05/09(日) 13:06:12
帳票の名前とかGUIのボタンの名前とか法律用語とか、日本語の方が分かりやすいものは使ったらいい。
送り仮名などの表記揺れは困るので、無理に ASCII 外の文字を使う必要はない。

677 :デフォルトの名無しさん:2010/05/09(日) 13:10:49
ボタンの名前とかころころ変わるし
無理に同じにしなくても

678 :デフォルトの名無しさん:2010/05/09(日) 13:25:14
>>661
>識別子に日本語使ってる人とは仕事したくねえな…

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

ゴクリ・・・

679 :デフォルトの名無しさん:2010/05/09(日) 13:29:48
void おまんこ::insert(Foo f)
{
if (f.resNo() == 678) { cout << "うんこを突っ込まれた方がまし"; abort(); }
}

680 :デフォルトの名無しさん:2010/05/09(日) 13:32:10
flushすらしないでabortとか

681 :デフォルトの名無しさん:2010/05/09(日) 13:33:03
心の声ってやつだな

682 :デフォルトの名無しさん:2010/05/09(日) 13:46:51
>>676
COBOLの二の舞になるぜ。
あれはローマ字だけど。

683 :デフォルトの名無しさん:2010/05/09(日) 13:48:32
そうか。ログに残さずソフトに本音を出させたい時にはこうするのか。

684 :デフォルトの名無しさん:2010/05/09(日) 14:00:46
バッファリング無効になってたらどうすんだ

685 :デフォルトの名無しさん:2010/05/09(日) 14:01:24
心の声だだ漏れってやつだな

686 :デフォルトの名無しさん:2010/05/09(日) 14:18:55
VC10はデフォルトムーブコンストラクタには未対応なのかな?

687 :デフォルトの名無しさん:2010/05/09(日) 15:44:39
先月のドラフトで導入されたばっかだしさすがに無理だろ

688 :デフォルトの名無しさん:2010/05/09(日) 15:45:56
assert(false);

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

689 :デフォルトの名無しさん:2010/05/09(日) 15:48:11
abort()がリリースで勝手に消えたら怖いよ

690 :デフォルトの名無しさん:2010/05/09(日) 15:54:07
あ、ではabort()は消えないんですか。
知りませんでした。
ありがとうございます。


691 :デフォルトの名無しさん:2010/05/09(日) 15:58:40
assertの引数の式はreleaseでは評価されないので正解だった?


692 :デフォルトの名無しさん:2010/05/09(日) 16:00:16
なぜ消えると思ったのかそっちの方が知りたい

693 :デフォルトの名無しさん:2010/05/09(日) 16:00:26
正確にはNDEBUGマクロが定義されている状態でcassertをインクルードしたら
assertの引数の式が評価されなくなる、が正解

694 :デフォルトの名無しさん:2010/05/09(日) 16:01:08
assertとabortが似てるからじゃね
字面が

695 :デフォルトの名無しさん:2010/05/09(日) 16:07:03
いろいろごっちゃになってました。
失礼しました。
しかもNDEBUGマクロとか初めて知りました。
確かにISOの規格書をNDEBUGで検索するとはっきり書いてありました。

済みません。


696 :デフォルトの名無しさん:2010/05/09(日) 16:22:20
assertの引数に副作用のある式を書いてハマるとか

697 :デフォルトの名無しさん:2010/05/09(日) 17:59:41
可変個テンプレート引数で侵入式のスマポが作りやすくなったとか
そういう話は無いの

698 :デフォルトの名無しさん:2010/05/09(日) 18:14:01
>>697
可変個テンプレート引数は変態御用達なだけでしょうな。


699 :デフォルトの名無しさん:2010/05/09(日) 18:16:04
>>697
可変個テンプレート引数は変態御用達なだけでしょうな。

700 :デフォルトの名無しさん:2010/05/09(日) 18:18:09
そんなに重要な事なのか

701 :デフォルトの名無しさん:2010/05/09(日) 18:20:53
引数の数が違うだけのテンプレートを何個も定義する方がよっぽど…

702 :デフォルトの名無しさん:2010/05/09(日) 18:34:33
未だに可変個テンプレート引数をどう活用するのか分からない俺が居る。

703 :デフォルトの名無しさん:2010/05/09(日) 18:36:04
未だに可変個テンプレート引数をどう活用するのか分からない俺が居る。


704 :デフォルトの名無しさん: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;
};

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

705 :デフォルトの名無しさん:2010/05/09(日) 18:55:44
できるよ
コンストラクタへの引数丸投げなら標準がやってる
std::make_sharedとか

706 :デフォルトの名無しさん:2010/05/09(日) 18:58:26
それでもboost::intrusive_ptrが規格に入らなかったのには何かあるのかな

707 :デフォルトの名無しさん:2010/05/09(日) 19:01:11
>>706
その前にregexが採用されてxpressiveが採用されないとか,
boost::scoped_ptrが何故採用されないのかとか
結構 言いたい事はあるよな。

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

708 :デフォルトの名無しさん:2010/05/09(日) 19:03:28
>>704 だと weak_ptr が実装できない(たぶん)ので、ちょっとした相互参照でどうしようもない
メモリリークになってしまう。

709 :デフォルトの名無しさん:2010/05/09(日) 19:07:39
scoped_ptrがないのはunique_ptrがあるからじゃない
つか名前変えただけというか
xpressiveは技巧的すぎたのかねえ

710 :デフォルトの名無しさん:2010/05/09(日) 19:10:00
intrusive_ptrからweak_ptrは元々作れなかったかと

711 :デフォルトの名無しさん:2010/05/09(日) 19:10:19
C++0x は、というか C++ 標準化委員会の連中は
C++ に Template metaprogramming を補強する
新しい機構をどんどん導入しているわりには、
Template metaprogramming で書かれた boost ライブラリを
採用しようとしない様な気がする。

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


712 :デフォルトの名無しさん:2010/05/09(日) 19:14:34
>>706
intrusive_ptrはshared_ptrに対してメリットが少ないし、共有系が複数あると面倒だからじゃないか。

713 :デフォルトの名無しさん:2010/05/09(日) 19:15:07
>>711 妄想は頭の中だけで済ませとけよ。

714 :デフォルトの名無しさん:2010/05/09(日) 19:16:44
他の言語もしくはC++自身の別実行レベルでメタプログラミングしたい

715 :デフォルトの名無しさん:2010/05/09(日) 19:16:53
valarrayみたいなものもあるんだし
少々あってもいいじゃん

716 :デフォルトの名無しさん:2010/05/09(日) 19:54:24
>>711
テンプレートメタプログラミングは標準にするには敷居が高いでしょう。
enable_ifぐらいなら単純デメリットも多いとは思うよ。


717 :デフォルトの名無しさん:2010/05/09(日) 19:55:37
>>716
×単純デメリットも
○単純でメリットも


718 :デフォルトの名無しさん:2010/05/09(日) 19:57:40
いや、メタプログラミング関連は山ほど追加されてるんだが。何言ってるんだお前ら。
20.7 Metaprogramming and type traits

719 :711:2010/05/09(日) 20:17:05
俺も一応そう申し上げているんだけどね。


720 :デフォルトの名無しさん:2010/05/09(日) 21:05:32
テンプレートプログラミングと、テンプレートメタプログラミングの境目ってどこ?


721 :デフォルトの名無しさん:2010/05/09(日) 21:07:19
主な処理を実行ファイルがするかコンパイラがするか

722 :デフォルトの名無しさん:2010/05/09(日) 21:11:45
>>720
> テンプレートプログラミングと、テンプレートメタプログラミングの境目ってどこ?
前者が本来想定されていた使い方で、
後者は仕様の隙間を付いた本来は想定されていない使用法。


723 :デフォルトの名無しさん:2010/05/09(日) 21:20:52
>>720
プログラムの動作に対するプログラミングか、プログラムコードに対するプログラミングかの違い。

724 :デフォルトの名無しさん:2010/05/09(日) 21:22:31
テンプレートメタプログラミングは
コンパイル時に動作するプログラムのようなものと考えれば良い

725 :デフォルトの名無しさん:2010/05/09(日) 21:24:13
テンプレートメタプログラミングはチューリング完全ですか?

726 :デフォルトの名無しさん:2010/05/09(日) 21:25:32
>>725
一定の制限があるがそれを忘れていいなら
チューリング完全であることは証明されている。



727 :デフォルトの名無しさん:2010/05/09(日) 22:22:20
というか、再帰回数に問題がある点を除けば、関数型言語だよな

728 :デフォルトの名無しさん:2010/05/09(日) 22:23:27
ある程度はconstexprで置き換わるのかな

729 :デフォルトの名無しさん:2010/05/09(日) 23:24:44
>>727
上限がないと本当にコンパイラが停止問題を解かなければならなくなるから
制限が付いてる

730 :デフォルトの名無しさん:2010/05/09(日) 23:52:27
>>729
そういう理由なの?
最低限アテにしていい回数を保証するためじゃなくて?

731 :デフォルトの名無しさん: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



732 :デフォルトの名無しさん:2010/05/09(日) 23:54:52
>>730
> 最低限アテにしていい回数を保証するためじゃなくて?
それもある。
というか2つの側面がある。


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


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


733 :デフォルトの名無しさん:2010/05/09(日) 23:58:49
>>731
最新のドラフトでは超パワーアップされてるよ。
> Recursively nested template instantiations [1024].

734 :デフォルトの名無しさん:2010/05/10(月) 00:06:19
コンパイラ作者泣かせだなw

735 :デフォルトの名無しさん:2010/05/10(月) 00:08:21
C++コンパイラ実装者は実質4つのコンパイラを作成する必要がある。
C++、プリプロセッサ、テンプレート、アセンブラ。

736 :デフォルトの名無しさん:2010/05/10(月) 00:16:39
s/コンパイラ/トランスレータ/

737 :デフォルトの名無しさん:2010/05/10(月) 00:34:46
プリミティブ値の国境付近に近づくのは愚行と喚き散らす奴が
テンプレートの事に成ると平気で越境してあーだこーだと不満言い出すのはナゼ?

738 :デフォルトの名無しさん:2010/05/10(月) 00:38:39
17回の再帰でも、コンパイルがまともな時間では終わらなくなるサンプルがあったな

739 :デフォルトの名無しさん:2010/05/10(月) 00:39:03
>>737 もう少しわかりやすくたのむ。

740 :デフォルトの名無しさん:2010/05/10(月) 08:35:15
>>737 多分両者は別人だと思う

741 :デフォルトの名無しさん:2010/05/10(月) 10:23:55
ところで C++0x の規格で、日本発の提案ってあるの?

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


742 :デフォルトの名無しさん:2010/05/10(月) 11:23:23
日本人はケチを付けるしか能がないから

743 :デフォルトの名無しさん:2010/05/10(月) 11:53:59
C++0xに準拠したコンパイラが楽しみですね..^−^..

744 :デフォルトの名無しさん:2010/05/10(月) 11:55:31
>>741
俺ってこんなに頭がいいんだぜ、ということをアピールしたいだけなので、
「言う側」にだけなれて、決して「言われる側」になることのない場所からしかモノ言いません。

745 :デフォルトの名無しさん:2010/05/10(月) 12:00:35
動く人は誰にも何も言わず黙々と自分の道歩いちゃうので目立たないとも言う
そしてそういう人は逆に協調性が無いので他人との共有に無関心だったりする


746 :デフォルトの名無しさん:2010/05/10(月) 12:33:52
Defect reportならたまに日本人ぽい名前も見るな。

747 :デフォルトの名無しさん:2010/05/10(月) 13:44:10
>>742, >>744
そんなに日本人の足を引っ張るようなこと言わんでも…
まさに日本人の敵は日本人だなw

748 :デフォルトの名無しさん:2010/05/10(月) 15:11:32
自虐民族乙

749 :デフォルトの名無しさん:2010/05/10(月) 20:55:25
だって日本NBのコメント見てみろよ
イギリスやドイツと比べてみろよ本当にひどいから
クレクレと重箱の隅つつきばかりで建設的なコメントが一つもない

750 :デフォルトの名無しさん:2010/05/10(月) 21:04:23
で、そいつが錦の御旗なの?
背中から撃ち続ける気満々だねえw

751 :デフォルトの名無しさん:2010/05/10(月) 22:53:02
と、こういう場所では上から目線全開で食い下がる。
でも肝心な場所では子リスのように震えているだけ。

752 :デフォルトの名無しさん:2010/05/10(月) 22:57:03
どうでもいいけど0xは余計コンパイラ開発者側に優しくなくなったのはどうにかならんのか。

753 :デフォルトの名無しさん:2010/05/10(月) 23:30:26
どうでもいい

754 :デフォルトの名無しさん:2010/05/10(月) 23:30:57
どうでもいいことでしたねすみません。

755 :デフォルトの名無しさん: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

756 :デフォルトの名無しさん:2010/05/10(月) 23:43:15
>>755
面白そうだな。これ傍聴とかできるの?

757 :デフォルトの名無しさん:2010/05/10(月) 23:52:03
>>657
> オーバーロード
過剰に流しこむ→元の加えて、他のが増える

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

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

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

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

758 :デフォルトの名無しさん:2010/05/11(火) 00:10:14
>>756
去年、CDがでたときにも、まったく同じことをやっていた。
ただ、もうFCDなんで、クレクレはできないよ。
typoとか矛盾点の指摘とか、重箱の隅をほじくるようなことしかできない。

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

759 :デフォルトの名無しさん:2010/05/11(火) 03:52:56
基本となる仕様の、重箱の隅をつつくことは悪いことではないが。

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

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


760 :デフォルトの名無しさん:2010/05/11(火) 04:06:19
ものを作る秀才はどうなのよ。
秀才を「調べるのに手一杯でどうにもならない駄目人間」だと勘違いしてないか?

761 :デフォルトの名無しさん:2010/05/11(火) 04:18:09
新しい言語仕様を提案するのはほとんど政治力の問題であって
問題点の洗い直しこそ開発者・言語研究者としての能力を要する点なのだが

762 :デフォルトの名無しさん:2010/05/11(火) 04:25:46
あら、触れちゃいけない点に触ったかな?

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

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

763 :デフォルトの名無しさん:2010/05/11(火) 04:29:45
>>762
>けど、問題点を解決する提案は出せない。ということですかね?
出てるが、出てることが理解できないというですかね?

764 :デフォルトの名無しさん:2010/05/11(火) 05:06:17
秀才がどうとか言ってる奴はただのルサンチマンだろ

765 :デフォルトの名無しさん:2010/05/11(火) 05:32:18
でてるんだぁ。
けどドラフトペーパーに日本人の名前あったけ?

766 :デフォルトの名無しさん:2010/05/11(火) 08:41:09
美少女中学生がドラフト出すようにならないかなあ
そしたらがんばって実装するのに

767 :デフォルトの名無しさん:2010/05/11(火) 08:53:12
中学生「かわいくないし意味わからないから、ラムダ廃止にして!」
グラマー「え!?」

768 :デフォルトの名無しさん:2010/05/11(火) 11:09:25
>>759
秀才ごときがどれだけ束になっても759の足元にも及ばないと豪語しているわけですね。

769 :デフォルトの名無しさん:2010/05/11(火) 11:25:37
結局、日本からの貢献は無い。ということですか。
中国はあるのにねぇ
国力の差か。

770 :デフォルトの名無しさん:2010/05/11(火) 11:31:42
各個人にオープンな貢献の場が与えられているのに国のくくりでものを考える意味がわからない。

771 :デフォルトの名無しさん:2010/05/11(火) 11:37:17
C++0x自体多くの人には不要だから仕方が無い

772 :デフォルトの名無しさん:2010/05/11(火) 11:54:47
C++0xのキラーアプリケーションって何かな

773 :デフォルトの名無しさん:2010/05/11(火) 12:06:07
>新しい言語仕様を提案するのはほとんど政治力の問題であって
なんだから、仕様提案ができないのは、政治的発言力が無い証拠だよなぁ。

大学で gcc の派生コンパイラとかまではザラにあるけど、
まともな提案を作って、働きかけて、物にすることができる人はいない。
レポート出したらそれっきりだしね。

某 ML のオフ会でも、たまにこの話題が出てくるけど、何もできないね。でオチついて終わり。

774 :デフォルトの名無しさん:2010/05/11(火) 12:31:05
C++0x で次世代のコンパイラを開発しよう。

775 :デフォルトの名無しさん:2010/05/11(火) 15:47:48
>>773
仕様提案といえばEmbedded C++があるじゃないか。
これがトラウマになって今の状況を招いたのだったりして。

776 :デフォルトの名無しさん:2010/05/11(火) 19:28:07
Embedded C++0xでリベンジを

777 :デフォルトの名無しさん:2010/05/11(火) 19:39:11
Embedded C++0x.

decltypeは、難しすぎて俺らには実装できないし、そもそも新しすぎて俺らには使いこなせないので却下。
autoは、難しすぎて俺らには実装できないし、そもそも新しすぎて俺らには使いこなせないので却下。
Variadic Templateは(ry
lambdaは(ry
scoped enumは(ry

778 :デフォルトの名無しさん:2010/05/11(火) 21:16:44
こうしてalignofと[[align]]だけが残った

779 :デフォルトの名無しさん:2010/05/11(火) 21:39:10
>>777
ようやく普通のテンプレートが入るならそれでもいいけどなw


780 :デフォルトの名無しさん:2010/05/11(火) 22:03:49
テンプレートはコードが膨張するので
Javaのgenericsみたいなのが入ります

781 :デフォルトの名無しさん:2010/05/11(火) 23:24:40
そこで明示的なインスタンス化ですよ

782 :デフォルトの名無しさん:2010/05/11(火) 23:39:32
>>778
alignas でいいじゃないですかぁ

783 :デフォルトの名無しさん:2010/05/11(火) 23:56:15
>>780
JAVAのげねりっくの正体はキャストって聞いたけど本当?

784 :デフォルトの名無しさん:2010/05/12(水) 00:01:31
むしろJAVAのCASTがGENERIC

785 :デフォルトの名無しさん:2010/05/12(水) 00:06:42
>>782
そこは戻ることに気付かずにC++0xともC1Xとも互換性失った方がEC++らしい

786 :デフォルトの名無しさん:2010/05/12(水) 00:13:54
互換性といえば、>>1の一番上のサイトのSC22→WG14でCの委員会サイトに
行けるんだけど、あっちもあっちでC++0xとの同期を意識しているんだよな。

787 :デフォルトの名無しさん:2010/05/12(水) 00:16:20
そりゃC++98とC99の時みたいな間抜けなこと繰り返したくないでしょ
お互いに

788 :デフォルトの名無しさん:2010/05/12(水) 02:10:05
「Cに」GCとクロージャを提案してるアホもいるけどな

789 :デフォルトの名無しさん:2010/05/12(水) 02:53:57
>>788
GCはともかくクロージャは並列プログラム等いろんな所で有用だし、
既にAppleは実現させてるでしょ。
http://blog.8-p.info/2009/09/gcd-1

790 :デフォルトの名無しさん:2010/05/12(水) 03:10:05
>>789
Apple拡張のクロージャは「GCはともかく」というよりGCありきでしょ
というかクロージャなんてオブジェクト機構を伴うことが前提なんだから
明らかに「Cのカバー範囲」を逸脱しまくってるだろ
ObjCがアレだからCのレイヤに二重実装してケツ拭かせますと言っているに等しい

791 :デフォルトの名無しさん:2010/05/12(水) 07:09:59
MacOSXは10.5からObjective-CにGC入ったけど
もしかしてOS自体がGCサポートしてんの?

792 :デフォルトの名無しさん:2010/05/12(水) 07:31:47
Apple 用の CPU は、アセンブラレベルで GC をサポートしているんですよ > 791

793 :デフォルトの名無しさん:2010/05/12(水) 07:33:53
Apple用てWindows用と変わらんで

794 :デフォルトの名無しさん:2010/05/12(水) 07:42:32
>>792
ちょw何を言い出すんだw

795 :デフォルトの名無しさん:2010/05/12(水) 13:39:41
Appleのブロック構文はGC使わず、参照カウンタでも動くけどな。
ブロック自体にretain,releseかますし。

796 :デフォルトの名無しさん:2010/05/12(水) 13:49:21
つーかなぜにAppleはクロージャをCに入れようとしたんだろう
構造体とフル機能のクロージャがあればそれだけでオブジェクト指向言語になってしまうので
「Cの」拡張としては恐ろしく筋が悪いものに感じる
インラインで「関数が」書ける機能ならCらしくて分かるんだが……

そもそもObjective-Cの拡張としなかった理由がよく分からんなぁ
どっかで「Cの拡張ならBSDカーネルに取り込める」とか強弁してた奴がいるけど
Cの「独自」拡張を使ってカーネル書くくらいならまだObjective-Cでカーネル書いた方がマシだろうと

797 :デフォルトの名無しさん:2010/05/12(水) 13:59:24
Obj-C (.m) だけで使えるより C でも使えた方が単純に考えてお得じゃない?

798 :デフォルトの名無しさん:2010/05/12(水) 14:10:14
ECMAScriptにclassを独自拡張した某言語に胸熱になったのを思い出す

799 :デフォルトの名無しさん:2010/05/12(水) 14:13:42
あ、いいこと思いついた。
C++0xの機能を全部C1xにバックポートすれば、超便利な機能がCでも使えて単純に考えてお得じゃない?

800 :デフォルトの名無しさん:2010/05/12(水) 18:29:28
おまえてんさいだな

801 :デフォルトの名無しさん:2010/05/12(水) 19:14:16
Obj-C用に実装したけど
Cでも使える構文になったから
Cでも使えるようにしちゃえ

でしょ。どうせ

802 :デフォルトの名無しさん:2010/05/12(水) 19:31:30
>>801
AppleクロージャはObj-CのオブジェクトじゃないからObj-C用に設計したものではないよ
Obj-C用に設計しようとしたがあまりにパフォーマンスが悪くてObj-Cと切り離さざるを得なくなった
という方が実態に近いと思う
でもオブジェクト機構と乖離したクロージャって物凄くいびつだと思うんだが
ああいうのって世間の言語設計者的にはOKなんだろうかね

803 :デフォルトの名無しさん:2010/05/12(水) 21:21:06
>>801
Obj-C で完結する部分には元々のブロックで充分じゃない?

>>802
逆じゃない?
オブジェクトは貧者のクロージャで、環境を文脈として保持するのが本来のクロージャでしょ。
だから Obj-C の blocks も微妙じゃないかな。

804 :デフォルトの名無しさん:2010/05/12(水) 21:44:54
>>803
環境だってデータなんだから、クロージャはデータを持った手続きであって
つまり表面上、データが主で手続きが従か、手続きが主でデータが従か、の違いだけで
クロージャはオブジェクトの一種というか表と裏のような概念。
実際オブジェクト指向言語におけるクロージャはそういう概念で設計・実装されてる。
Javaの無名Runnableなんかは明らかにオブジェクト寄りのクロージャで中間概念として分かりやすいんじゃないかな。

805 :デフォルトの名無しさん:2010/05/12(水) 22:31:20
頭に isa 付けてりゃObj-Cのオブジェクトになる訳で。

806 :デフォルトの名無しさん:2010/05/12(水) 22:43:13
>>805
そういう問題じゃないだろw

807 :デフォルトの名無しさん: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

808 :デフォルトの名無しさん:2010/05/13(木) 11:07:36
必要っちゃ必要なのかなぁ
ぶっちゃけGCDはjava.util.concurrentの簡易版みたいなものだから
クロージャ無いと無理というわけではないと思われ

BSDがカーネル内でBlocks使うって噂もあるけど
独自拡張使ってカーネル書くのは正直それってどうなのって気はするな。

809 :デフォルトの名無しさん:2010/05/13(木) 20:46:43
カーネルこそコンパイラの独自仕様に頼らざるを得ないだろ
LinuxカーネルなんてGCCに依存どころかほとんど癒着してるぞ

810 :デフォルトの名無しさん:2010/05/13(木) 20:56:51
そりゃLinuxのお行儀悪さの発露であって。
処理系依存なコードは必要最小限に抑えるのがまともな実装。

811 :デフォルトの名無しさん:2010/05/13(木) 21:27:06
>>810
頭の中に花畑があるようですね

812 :デフォルトの名無しさん:2010/05/13(木) 22:10:34
あれ、LinuxってGCC独自拡張の文法とか使ってるんだっけ?

813 :デフォルトの名無しさん:2010/05/13(木) 22:36:16
丁度良さげなのがあったので貼っておく
http://www.ibm.com/developerworks/jp/linux/library/l-gcc-hacks/

814 :デフォルトの名無しさん:2010/05/13(木) 22:48:08
>>813
全体的に代替マクロで潰せるものが多いね
範囲caseとゼロ長配列は冗長だけど標準で書けるんだから標準で書けとは思った

ロジック的に完全にGCCに依存してそうなのは定数判定かな

815 :デフォルトの名無しさん:2010/05/13(木) 23:19:26
>>814
> 全体的に代替マクロで潰せるものが多いね

どうやって? どれ一つとしてマクロで出来る様には思えなかったけど。

816 :デフォルトの名無しさん:2010/05/13(木) 23:29:38
>>814
御託はいいから置き換えて晒してみろよ

817 :デフォルトの名無しさん:2010/05/13(木) 23:51:16
まさか・・・ ExcelにおけるVBAのような脳内マクロをイメージした発言では・・・・ww


818 :デフォルトの名無しさん:2010/05/14(金) 00:02:23
マクロで「潰す」と言ってるんだが
最適化ヒントは全部空文字列と置換可能だろ

819 :デフォルトの名無しさん:2010/05/14(金) 00:21:01
・型検出
 この機能自体は大抵のコンパイラでマクロ使ってエミュレート可能かな
・範囲拡張・ゼロ長の配列
 gcc拡張使えば楽になるのは分かるけど、こらえてベタ書き汁
・呼び出しアドレスの判断
 スタック辿れば可能だが、こんな情報は引数で渡すべきじゃないのか
・定数検出
 これは専用の文法ないと厳しいかな
 全部定数でないと見なして最適化を諦めることは可能だけどパフォーマンスすごく悪そう
・関数属性
 各コンパイラごとに存在するならそれに置換、無ければ空にすればいいだけ
 よくある話
・最適化に関する拡張機能
 上に同じ

下2つはVC/GCC両対応コード書く時とかマクロで切り替えるの常套手段だと思うんだけど
>>815がなぜ「マクロで出来るように思えなかった」のかがむしろわからんなぁ

820 :デフォルトの名無しさん:2010/05/14(金) 03:03:13
無理矢理スレの趣旨に戻すと
Blocksさんに比べれば我らがラムダさんの制服の柄は許容範囲
という認識でよろしいか

821 :デフォルトの名無しさん: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));

822 :デフォルトの名無しさん:2010/05/14(金) 13:26:43
>>804
Scheme や Smalltalk や ECMAScript などのクロージャが物凄くいびつだと。

823 :デフォルトの名無しさん:2010/05/14(金) 13:34:09
>>819
お前が夢ばかり見てるオバカさんだってのはよくわかった

824 :デフォルトの名無しさん:2010/05/14(金) 13:49:32
>>822
その辺はむしろクロージャこそがオブジェクト機構の主体なんだから一貫してるよ
ECMAScriptにclassを更に足してしまったActionScriptはいびつと言っていいと思う
Blocksは「Cを単体でECMAScriptのような言語にする」機構なので
Objective-Cとして使われることを前提とした拡張だとむしろActionScript状態に近い

825 :デフォルトの名無しさん:2010/05/14(金) 14:04:14
具体的に全く反論できないのでレッテル貼りしかできないのですねわかります

826 :デフォルトの名無しさん:2010/05/14(金) 14:12:04
>>825
え、どの辺が具体的じゃない?
ScmemeやECMAScriptはクロージャ機構からオブジェクト機構が導出されている
C++とかJavaとかRubyとかはオブジェクト機構があってそこからクロージャが導出されている
Objective-C with Blocksは、Blocksというクロージャ機構があり、かつそれと直交したオブジェクト機構を持つ
そんなに難しいことではないと思うけど、分かりにくいとこある?

827 :デフォルトの名無しさん:2010/05/14(金) 14:14:28
>>826 >>825>>823 に対してだと思われ

828 :デフォルトの名無しさん:2010/05/14(金) 14:20:24
>>826 が何気に他人の反応気にしてるのがわかったw


829 :デフォルトの名無しさん:2010/05/14(金) 14:24:47
>>828
いやめっちゃ分かりやすく書いたつもりだったので衝撃を受けただけ
>>827ってことなら気にせんでくれ

830 :デフォルトの名無しさん:2010/05/14(金) 15:06:20
>>819
スタック辿ればとか言ってる時点で処理系依存しまくり
引数とかいうがプログラムカウンタをアーキテクチャ依存無しで取ってみろ

831 :デフォルトの名無しさん:2010/05/14(金) 15:18:56
似たものが直行する概念として実装されているのがどうしていびつなのか
具体性に欠ける


832 :デフォルトの名無しさん:2010/05/14(金) 15:28:52
直交の意味から説明しないといけないほどのバカが一人で暴れてる模様

833 :デフォルトの名無しさん:2010/05/14(金) 15:53:59
>>824
Smalltalk は違うよ。
というか、クロージャでできることは全てオブジェクトでできるけど、クロージャを欲しがる理由はオブジェクトとは関係ない。
そして ECMAScript 的なクロージャは元々あるブロックを使えばいい。

834 :デフォルトの名無しさん:2010/05/14(金) 16:24:34
>>833
smalltalkはRubyと同じで、というか由来的には逆だけど
ブロックはオブジェクト機構の枠内にいるよ
ブロックとオブジェクト機構が直交した独立の存在にはなってない

835 :デフォルトの名無しさん:2010/05/14(金) 17:26:43
Rubyの場合は、ブロックを表現するProcというクラスもあるけど、
それがブロックそのものではなく、オブジェクトにはなってない。

836 :デフォルトの名無しさん:2010/05/14(金) 18:02:23
>>835
Procはオブジェクトだぞ
ちょうどC++0xのlambdaで返るfunctionと同じ立ち位置

837 :デフォルトの名無しさん:2010/05/14(金) 18:09:11
誰かC++学園的に各言語のクロージャ、ブロックを例えてくれよ。
話しについて行けない。

838 :デフォルトの名無しさん:2010/05/14(金) 18:20:25
>>836
Procはオブジェクトなんだけど、ブロックがすなわちProcではない。

def foo &c で、ブロックを変数に入れるか、引数なしで Proc.new を呼ぶと、
ブロックからProcのインスタンスが作られる。

839 :デフォルトの名無しさん:2010/05/14(金) 18:27:17
>>838
今君の言ってるところの「ブロック」って「構文木」のこと?
普通ブロックとかクロージャとか言う時は、
キャプチャされたローカル変数とコードの組み合わせのことであって、
構文木のことは指さないんじゃない?

840 :デフォルトの名無しさん: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のインスタンスが作られる。

841 :デフォルトの名無しさん:2010/05/14(金) 18:39:11
>>840
それは論理的にはProcインスタンスが匿名かどうかの問題でしかないぞ

842 :デフォルトの名無しさん:2010/05/14(金) 19:10:34
これまで出てきている「ブロック」というのは、もともとはSmalltalkローカルの用語で無名関数のこと。
Smalltalkのブロックは、クロージャーで実装されていることが多い(が、そうでない場合〜エンクローズされていない〜もある)。
Rubyのブロックや Objective-C の Blocks はこのSmalltalkのブロックから名前を借りたもの。
Rubyのブロックは、ファーストクラスオブジェクトでも Ruby のオブジェクトでもない。(840の言いたいこと)
Rubyのブロックをオブジェクトとして扱えるように用意されたのが Proc クラス。

843 :デフォルトの名無しさん:2010/05/14(金) 19:23:12
>>842
んっとね、Rubyのブロック構文は基本的にProc(など)の定義であり
そのProcインスタンスが外部から可視であるかは問題ではない
というのが>>841で言いたかったことね。
この点は言語設計として一貫してるよ。smalltalkも基本的にそうでしょ。
#もちろん最適化の結果、内部でいつの間にかショートカットされてることはあり得る

クロージャというオブジェクトとは直交した全く別の構造があって
Procというインターフェースから間接的にアクセスできる
という論理構造"ではない"

でもApple CのBlocksは当然根本的にObjective-Cのインスタンスではない。
何故ならObjectiveじゃないCの中に存在している概念だから。
逆にBlocksが常にObjective-Cのインスタンスであるなら>>799を地で行くことになる。

844 :デフォルトの名無しさん:2010/05/14(金) 19:46:44
実質的にはObjCの拡張であって本気でBlocksをC1Xに提案していく気はないでしょ
あんな__付きまくりなものに仕様的整合で目くじら立ててもしょうがないしスレ違い

845 :デフォルトの名無しさん:2010/05/14(金) 20:06:01
実際に存在してないものを「可視か否かの問題」にされたらかなわんわ

846 :デフォルトの名無しさん:2010/05/14(金) 20:13:10
>>845
内部的に存在するが外部からアクセス手段がないことを「実際に存在しない」と言うのか

847 :デフォルトの名無しさん:2010/05/14(金) 20:17:33
内部的に存在してるものはProcのインスタンスじゃないから。

848 :デフォルトの名無しさん:2010/05/14(金) 20:25:09
iostreamとかpimplとか見たら発狂するタイプだな

849 :デフォルトの名無しさん:2010/05/14(金) 20:31:03
Apple の Blocks は toll-free だけど、処理の実体は C に投げられてるから、Obj-Cの拡張言うかな?
NSBlock のサブクラス検索したけど、どれも変数持たないし。

850 :デフォルトの名無しさん:2010/05/14(金) 20:36:39
>>849
ObjCとは切り離されてると思う。
ObjCのオブジェクトはパフォーマンスが悪すぎて
クロージャを表現するには正直きついので、
同種の機構を二重に実装するダサさは目をつぶってCに入れた、
という認識の方が実態に近いかと。

851 :デフォルトの名無しさん:2010/05/14(金) 20:40:36
まあ[hoge retain],copyとかの為だけにObj-C クラスの皮被せただけだろうな。

852 :デフォルトの名無しさん:2010/05/14(金) 21:16:03
Obj-Cのオブジェクトってそんなにパフォーマンス悪いの?
クロージャをオブジェクトのシンタックスシュガーとして扱えないほど重いってそれ自体がかなりむごい話に聞こえるんだが・・・

853 :デフォルトの名無しさん:2010/05/14(金) 21:30:14
メソッドは関数呼び出しの3倍くらいの速度。

854 :デフォルトの名無しさん:2010/05/14(金) 21:30:29
1/3くらい。

855 :デフォルトの名無しさん:2010/05/14(金) 22:17:32
IMP呼び出し使ってC++のvirtualくらいの速度じゃなかったっけ?
staticな関数コールと素のmessage sendを比べると10倍どころでは済まないと思う

856 :デフォルトの名無しさん:2010/05/16(日) 13:18:17
>>834
ブロックを辞書に格納することはできるけど、ブロックは辞書で表現されてないよ。
[|a|a:=10.[^a] value] の 内側のブロックから a を参照することをオブジェクト機構の枠内というのは強弁だと思うよ。

というか直行してるといびつだという理由を教えて欲しい。
コストの安いほうでいいじゃん。

857 :デフォルトの名無しさん:2010/05/16(日) 18:09:57
>>856
何故に唐突に辞書が……

858 :デフォルトの名無しさん:2010/05/16(日) 18:50:14
素朴な疑問だけどWebKitがC++である以上
Objective-CはObjective-C++として使われるのは不可避なわけで
lambdaをObjective-Cの中に置くことを最初から諦めるなら
最初からC++のlambdaを使えば良かったんじゃないのと思うのは俺だけ?

859 :デフォルトの名無しさん:2010/05/16(日) 19:27:11
馬鹿? ラッパしてある中身が云々とか、使う分には関係ないし。

860 :デフォルトの名無しさん:2010/05/17(月) 13:40:22
>>856
論理的に包摂関係にあるものを全く別々の独立した2つの仕様として策定するのは、設計としてはダサいだろ。
一貫した仕様を定義し、最適化の過程で内部実装は切り分けられる、というのが基本。

あくまで原則論なので過去の負の遺産との整合上仕方ないこともあるし、いわんや独自拡張で何やろうと知ったことではないがな。

861 :デフォルトの名無しさん:2010/05/17(月) 13:49:48
>>860
論理的に包摂関係にある、というのがさっぱり理解できないんだけど。
バナナで釘が打てるからバナナも金槌に包摂されると主張しているように聞こえる。
俺は、クロージャとオブジェクトは、たまたま一部について同じことができるだけの別物だと思う。

862 :デフォルトの名無しさん:2010/05/17(月) 13:55:18
>>861
オブジェクトとクロージャは「たまたま一部について同じことができる」なんてレベルじゃないだろ。
バナナが存在するところにリンゴを追加する際に、果物クラスを作らずリンゴクラスが独立して作られて、バナナとリンゴは違うだろ、と主張しているように聞こえる。
それどころか青リンゴと赤リンゴくらいの関係じゃないか。

863 :デフォルトの名無しさん:2010/05/17(月) 17:43:39
>>862
理解できないと言っているのだから説明してよ。
包摂関係とはどういうことかの説明じゃなくて、オブジェクトがクロージャを包摂するということについてね。

860 の「論理的に包摂関係にある」ということは、論理的に説明できるんだよね?
包摂関係にあることの確認を、論理的に行えると考えていいんだよね?


あと、バナナの話は凍らせた時の話で、殺伐としすぎないようにジョークで出したのだけれども、場違いだったようで失礼。
http://www.youtube.com/watch?v=Po_B6SHWUdI

864 :デフォルトの名無しさん:2010/05/17(月) 18:06:42
オブジェクトとクロージャは片方がもう一方の全てを満たすことが可能である以上
包摂関係と言うと語弊があると思う
むしろ同じものの表と裏と言った方が概念的には正しい

865 :デフォルトの名無しさん:2010/05/17(月) 18:17:58
何だ? 一行目と二行目が……

866 :デフォルトの名無しさん:2010/05/17(月) 18:26:59
流れを読まずに書き込むが
オブジェクト⊃クロージャじゃないの?

「オブジェクト」の定義がよくわからんが、どうせ
「データと手続きを一緒にしたもの」ぐらいだろ?
なら、そういう包含関係にならざるを得ないと思う

クロージャはレキシカルスコープと密接に絡んだ概念だから、(より一般的な)
オブジェクトより狭い概念だと思うけど?

867 :デフォルトの名無しさん:2010/05/17(月) 18:36:51
>>864
了解した。
その上で、
1) 表と裏であることを示してくれ
2) 表と裏である機能(性質? 事象?)を、独立した別々の機構として策定するのがダサい理由を説明してくれ
  虚数表現とか表色系とか、いろいろあると思うがどうだろう
をお願い。

>>866
クロージャでできることをオブジェクトで行うことはできる。
が、ローカル変数を含めたレキシカルスコープへの参照を束縛するという機能なり概念なりはオブジェクトにはない。
クロージャの概念のほとんどをオブジェクトが持つといっても反対はしないが、全てではない。
クロージャが持ち、オブジェクトが持たない概念が存在する。

ちなみに俺は、同じことができるだけで別モンだと思うけどね。
金属バットとバールのようなものくらい違うと思うよ。

868 :デフォルトの名無しさん:2010/05/17(月) 18:39:47
>>867
よくわからんけど、あんたの言う「オブジェクト」の定義って何?
「クラス」の話?

869 :デフォルトの名無しさん:2010/05/17(月) 18:42:53
>>866
実際にJavaScriptとかLisp系とかはクロージャでオブジェクトを実現しているよ
理論上は得意不得意の違いだけで扱えるスコープは同じになる

870 :869:2010/05/17(月) 18:44:55
補足
 扱えるスコープ→扱える「問題の」スコープ
です
このため、片方が存在すれば、もう片方は単なるシンタックス上のトリックとして扱えます

871 :デフォルトの名無しさん:2010/05/17(月) 18:45:45
>>869
あのね、
俺はオブジェクトのほうが広い(曖昧な)概念で
クロージャは、より狭い概念だと言ってるんだよ

出来ることの差なんてそりゃ無いが、概念の広い狭いとは全然関係ない話だろ

872 :デフォルトの名無しさん:2010/05/17(月) 18:54:51
>>871
うーん、それはどうだろう
C++的な立場から見るならそれで合ってる
コンピュータ上での実際の動作という意味でもその方が実態に近い
でも関数型的な観点で言えばクロージャの方がよりプリミティブな概念になっちゃうんだよね
だからどっちが広いとか狭いとかいうよりも「表と裏」なのだと思う
多分オブジェクトの方が表なのだろうけど

873 :デフォルトの名無しさん:2010/05/17(月) 19:18:21
>>872
んーそれじゃ、あんたの「オブジェクト」の定義は何なの?
俺の定義は>>866でしかないから、紛れも無くクロージャは「オブジェクトの
一種」でしかないんだけど

「オブジェクト」は別にレキシカルスコープと関係なくてもいいし
データは環境でなくてもいい
だからクロージャはより「狭い」

874 :872:2010/05/17(月) 19:22:44
>>873
ん、俺の定義も>>866と変わらんよ
…ところで俺は「オブジェクトとクロージャは直交してる」と言い張ってる人とは別人ですよ……?

875 :デフォルトの名無しさん:2010/05/17(月) 19:28:19
>>874
あ、そうなの?その定義なら
オブジェクト⊃クロージャ
は自明というか、論理的にそうにしかならんでしょうに

876 :デフォルトの名無しさん:2010/05/17(月) 19:34:23
>>875
いや、関数型の世界では手続きは情報を持っていることが当たり前で
オブジェクト的なものはその一種でしかないんだわ
だから君のような考え方はC++の観点では自明なんだけど
一方で関数型の世界では「クロージャの概念がオブジェクトの概念を内包している」ことになる

手続き型と関数型があってどっちが内包するわけじゃなくてどっちもチューリング完全だよねみたいな感じ
実装は通常最終的に手続き型で行われるからマシンレベルで最もプリミティブなのは前者ではあろうけど、と

877 :デフォルトの名無しさん:2010/05/17(月) 19:40:02
>>876
いいたいことは分かるが、論理的に全然包含関係の否定になってない気がするが

否定したければ、非オブジェクト的なクロージャが存在することを示すしかないぞ
無いでしょ?
一方、全てのクロージャは>>866の定義なら自動的にオブジェクトだし
それは関数型だろうが変わらんでしょ

878 :デフォルトの名無しさん:2010/05/17(月) 19:50:12
ごめん変な書き方になった

全てのクロージャはオブジェクトである
クロージャでないオブジェクトは存在する
ゆえにオブジェクト⊃クロージャである

というのが俺の論理なので、否定したいのなら最初の奴の反例出すしかないんじゃ
ないのって話ね

879 :デフォルトの名無しさん:2010/05/17(月) 19:51:43
お前誰よ?

880 :デフォルトの名無しさん:2010/05/17(月) 19:52:09
俺は>>866

881 :デフォルトの名無しさん:2010/05/17(月) 19:55:45
俺は>>881

882 :デフォルトの名無しさん:2010/05/17(月) 20:08:31
>>878
オブジェクト=クロージャ
なんじゃね?
>どっちが広いとか狭いとかいうよりも「表と裏」
とか書いてるし

>クロージャでないオブジェクトは存在する
を否定する根拠があるかどうかは俺は知らん

883 :デフォルトの名無しさん:2010/05/17(月) 20:13:46
>>877
うーん、非オブジェクトなクロージャってのは難しいな
一応逆の観点で見ると
オブジェクトのconstructは引数による明示的な束縛に他ならないし
メソッドの実行もプロパティの読み書きも関数型的には関数(手続き)実行に他ならないから
概念的には逆に全てのオブジェクトもクロージャであることを満たすんだよね

実際クロージャ指向な世界ではそういう扱いをしている
うん、変態的だとは思う

884 :デフォルトの名無しさん:2010/05/17(月) 20:29:18
ぶっちゃけお前らが何をいってるのかよくわからん。
クロージャといえば、その場の自由変数をbindできて、Callable(operator()が使える)である必要があると思うが、
Haskellみたいな言語でもすべてのオブジェクトがCallableであるとは限らないだろ。
data Point = Point x y と定義して、Point 1 2とかするとオブジェクトが生成されるが、これはCallableか?

885 :デフォルトの名無しさん:2010/05/17(月) 20:30:24
>>883
うーんSchemeあたりでオブジェクトっぽいのを書くときにそうする、というのは
分かるけどねぇ
関数型でない言語にまでその議論を広げるのは無理がない?

レキシカルスコープとクロージャを提供してるけど
クラスも提供してる言語はいくらでもあるし
それらの言語では、クラスオブジェクトとクロージャは別物だから

886 :デフォルトの名無しさん:2010/05/17(月) 20:38:16
>>885
クロージャとクラスを提供していて、論理的に全く分断された扱いがされてる言語ってどんなのがある?
ActionScriptがそんな感じになってるんだっけ?

887 :デフォルトの名無しさん:2010/05/17(月) 20:50:51
PHP(ゴクリ

888 :デフォルトの名無しさん:2010/05/17(月) 21:03:43
>>886
論理的に全く分断って意味がわからんけど
C#とかPythonとかScalaとか、いくらでもないか?

それらの言語のクラスを、普通の意味でのクロージャとは見做せないと思うけど

889 :デフォルトの名無しさん:2010/05/17(月) 21:06:04
ああクロージャ=オブジェクト論では
クラススコープの変数を、レキシカルスコープの自由変数と見做すのか

なんとなく意味は分かったw
なるほどね

890 :デフォルトの名無しさん:2010/05/17(月) 21:12:48
>>888
その辺の言語はクラス指向で、クロージャは単純にクラス機構の下位に属してるんじゃ?

891 :デフォルトの名無しさん:2010/05/17(月) 21:20:13
>>889
ちょうどオブジェクト指向言語でクロージャを表現するのと逆方向だな
レキシカルスコープの束縛はコンストラクタでのインスタンス変数へのコピー・参照
C++0xのlambdaをC++で書こうとするとまさにそうなるw

892 :デフォルトの名無しさん:2010/05/17(月) 21:21:14
>>890
よくわからない
「クロージャではないオブジェクト」が存在する例がクラス指向の言語だと、
何か問題に影響するの?


893 :デフォルトの名無しさん:2010/05/17(月) 21:25:26
>>892
なんの問題の話をしてるのかよく分からんが
ほとんどの言語は
・クラス指向の言語でありクロージャはクラスである(オブジェクト指向言語、多数派)

・クロージャ指向の言語でありクラスはクロージャである(一部の関数型言語、少数派)
のどちらかで、クラスとクロージャが「別物」の言語はそうそうないのでは

PHPとかはそうなのかな?

894 :デフォルトの名無しさん:2010/05/17(月) 21:33:27
クロージャがクラスとか、クラスがクロージャなんじゃなくて、
クラス機構もクロージャ機構もオブジェクト機構の一部であって、共通する部分もあるってだけなんじゃないかな

895 :デフォルトの名無しさん:2010/05/17(月) 21:35:54
>>893
Pythonはオブジェクト指向言語だけど、全ての型がclassかというとそうではない
クロージャの型はfunctionで、functionはファーストクラスオブジェクトだが
classではない


896 :デフォルトの名無しさん:2010/05/17(月) 21:40:53
>>889の見立てを行ったときに、クロージャと同じものと見做せるのは
class objectではなく、bound methodだと思う

897 :デフォルトの名無しさん:2010/05/17(月) 21:52:44
Perlはクラス指向でもクロージャ指向でもなくて
どっちも持ってる

898 :デフォルトの名無しさん:2010/05/17(月) 21:54:03
そろそろスレ違い

899 :デフォルトの名無しさん:2010/05/17(月) 21:55:06
つまりラムダさんかわいいよラムダさん、ということでまとめとこうぜ

900 :デフォルトの名無しさん:2010/05/17(月) 21:59:12
あんまりそわそわしないで。 あなたはいつでも話脱線しちゃうけど
スレタイ見てよそ見はやめてよ。 ラムダっちゃ。  ってことでここは一つ


901 :デフォルトの名無しさん:2010/05/17(月) 23:03:19
次スレは10だよ派といやAだろう派による
ねっとりした論戦が始まります。

902 :デフォルトの名無しさん:2010/05/18(火) 00:57:26

ラムダ、auto、右辺値参照、progress_display
個人的に大いに期待する4大新機能


おまいらどう?

903 :デフォルトの名無しさん:2010/05/18(火) 01:05:50
progress_displayたんともあろうお方が…(´;ω;`)ウッ

904 :デフォルトの名無しさん:2010/05/18(火) 05:33:49
誰もがぱっと恩恵受けられるのはautoだろうね
autoのためにC++0xを使わせて貰える現場があるのかは知らん・・・

905 :デフォルトの名無しさん:2010/05/18(火) 06:04:00
>>904
auto は待ち遠しいねえ。 GCC 4.4では使えるが、まだ許されるのはGCC 4.3まで。

906 :デフォルトの名無しさん:2010/05/18(火) 20:09:02
昔のautoちゃんはもういないのかな...

907 :デフォルトの名無しさん:2010/05/18(火) 20:15:30
○Blocksさん
遠く青森で林檎に囲まれて育ったラムダさんの親戚。帽子が特徴的。

908 :デフォルトの名無しさん:2010/05/18(火) 20:26:19
>>904
右辺値参照は標準ライブラリが対応するだけで、ソース書き換えなくても自動的に恩恵が得られる。

909 :デフォルトの名無しさん:2010/05/18(火) 21:15:24
vectorにunique_ptrが入るようになるだけでもマジうれしい

910 :デフォルトの名無しさん:2010/05/18(火) 21:17:13
>>906
VC10だとオプションで復学可能

911 :デフォルトの名無しさん:2010/05/18(火) 21:18:26
>>904
autoとバリアントの区別がつかない人が拒否反応起こして困る。

912 :デフォルトの名無しさん:2010/05/18(火) 21:25:45
>>911
昔は「そんなんいねーだろ!」とか思ってたけど、いるみたいだねぇ。
C#の記事で、varとバリアントを混同する人が結構いる、という前提の説明を見たことがある。
当然C++のautoでも出て来るんだろうね・・・。

913 :デフォルトの名無しさん:2010/05/18(火) 21:30:32
やべえ、最近書いたコードはautoがずらずら並んでいるが問題ないよね?

914 :デフォルトの名無しさん:2010/05/18(火) 21:50:32
auto a = 1;
a = "Hello"; //エラー

「なにこれマジ使えねー」

915 :デフォルトの名無しさん:2010/05/18(火) 22:02:40
#define auto_type_affirmation auto

916 :デフォルトの名無しさん:2010/05/18(火) 22:55:03
0xオプションつけると
auto int x = 4;
がもう通らない。

完全に別人やな。


917 :デフォルトの名無しさん:2010/05/18(火) 23:14:54
auto<int>とかfoo<auto>みたいな文法が
採用される夢を見た

918 :デフォルトの名無しさん:2010/05/18(火) 23:22:57
auto<auto>

胸が熱くなるな

919 :デフォルトの名無しさん:2010/05/18(火) 23:31:54
>>918
テンプレート引数を取る識別子は型そのものではないのだからautoでそれを示すのは不可能なんじゃないか

920 :デフォルトの名無しさん:2010/05/18(火) 23:37:41
誰も可能だなんて言ってない

921 :デフォルトの名無しさん:2010/05/18(火) 23:39:16
return auto;

922 :デフォルトの名無しさん:2010/05/18(火) 23:43:15
むしろfoo<auto>だろ。

vector<nagai_namae_no_type> hogehoge;
///...
hogehoge.swap(vector<auto>());

923 :デフォルトの名無しさん:2010/05/19(水) 00:17:59
T<auto>は出来るように提案されてたよね?
std::pair<auto, auto> = make_pair( T(), U() ) みたいの。
g++, vc2010 で出来るか知らないけど

924 :デフォルトの名無しさん:2010/05/19(水) 00:35:17
D の !( みたいに専用の括弧が無いから、auto<T> みたいのをやるなら
template であることを明示するとか?
vector<short> a;
template auto<int> b = a;

925 :デフォルトの名無しさん:2010/05/19(水) 07:13:44
>>923
関数テンプレートでもそれ欲しいな
foo<auto, int>(...); みたいな感じで、1つ目は推論とか

それでこんな文法も欲しいと思ってしまった
void foo(int a, int b = 1, int c = 1);
foo(2, default, 3);

926 :デフォルトの名無しさん:2010/05/19(水) 07:33:05
defaultって書く方がめんどくさくね?
単純に省略じゃダメなのか
foo(2, , 3);

927 :デフォルトの名無しさん:2010/05/19(水) 07:35:37
defaultはやめてくれ。そこ変数名書けるとこだろ
省略はtypoで追跡しにくいバグを生みそうだなぁ

928 :デフォルトの名無しさん:2010/05/19(水) 07:41:05
デフォルト引数をそのまま使いたいのよ
よくあるっしょ?

929 :デフォルトの名無しさん:2010/05/19(水) 07:43:41
>>928
defaultって名前の変数あったらどうするんだよ・・・

930 :デフォルトの名無しさん:2010/05/19(水) 07:44:45
ごめん、ないな。忘れてくれ

931 :デフォルトの名無しさん:2010/05/19(水) 07:51:44
foo(2, __, 3);

932 :デフォルトの名無しさん:2010/05/19(水) 07:53:32
むしろ名前付き引数が欲しいな
foo(a: 2, c: 3);

933 :デフォルトの名無しさん:2010/05/19(水) 07:54:53
[foo a: 2, c: 3];

934 :デフォルトの名無しさん:2010/05/19(水) 09:56:56
v(9, __,9);

935 :デフォルトの名無しさん:2010/05/19(水) 10:21:04
v(^・^)v

936 :デフォルトの名無しさん:2010/05/19(水) 12:37:19
defoult:

937 :デフォルトの名無しさん: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);

938 :デフォルトの名無しさん:2010/05/19(水) 20:14:07
>>937
{ はなしで

939 :デフォルトの名無しさん:2010/05/20(木) 07:09:39
離すってことは・・・こうか!ありがとう!

void foo(int a, optional<int> b, optional<int> c)

 {

  foo(2, none, 3);

940 :デフォルトの名無しさん:2010/05/20(木) 07:19:21
再帰ということでいいんじゃないか

941 :デフォルトの名無しさん:2010/05/20(木) 22:35:59
lambdaとbindの使い分けを教えてください

942 :デフォルトの名無しさん:2010/05/20(木) 23:59:32
使い分けもクソも全然別物じゃないですか

943 :デフォルトの名無しさん:2010/05/22(土) 17:26:12
lambda: 常に使え
bind: 忘れろ。ネイティブなlambdaがあれば必要ない。

944 :デフォルトの名無しさん:2010/05/23(日) 21:00:42
struct { int a, b, c; } foo() { return { 1, 2, 3 }; }

みたいに戻り値の型のところで直接型宣言できたら
tupleより結果にアクセスしやすいと思うのだが
C++0xでできたっけ? これ

945 :デフォルトの名無しさん:2010/05/23(日) 21:05:04
イニシャライザーリストでできるのかなぁ??

946 :デフォルトの名無しさん:2010/05/23(日) 21:05:34
>>944
戻り値のところで型の宣言するだけなら現行のC++でも可能だと思うが。

947 :デフォルトの名無しさん:2010/05/23(日) 21:10:14
g++ 4.2.1でエラーになったけど

main.cpp:7: error: new types may not be defined in a return type

948 :デフォルトの名無しさん:2010/05/23(日) 21:11:07
struct A { int a, b, c; };
A foo() { return { 1, 2, 3 }; }

はC++0xで可能なんだよね?

949 :デフォルトの名無しさん: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>にしない理由は何なんだろ

950 :デフォルトの名無しさん:2010/05/24(月) 01:38:15
書いてある通りだろ。
braced-init-listはexpressionじゃなくて、initializer。
戻り値を省略した場合、returnから推測してくれるためには、lambdaは、

{ return attribute-specifieropt expression ; }

の形でなければならない。
expressionであるべき場所に、expressionじゃないものを書いて、なんでダメなんだって言われても困る。

951 :デフォルトの名無しさん:2010/05/24(月) 08:13:01
アスペルガー

952 :デフォルトの名無しさん:2010/05/24(月) 18:41:43
>>950
別に、braced-init-listの時はstd::initializer_list<T>に推測する、
というルールを入れればいいだけじゃない?

953 :デフォルトの名無しさん:2010/05/25(火) 23:26:39
アクセッサ自動生成する指定子とか提案されてないんですか?

954 :デフォルトの名無しさん:2010/05/26(水) 01:23:04
>>953
ないだろうね。
実装(メンバ変数)に基づいてインターフェース(アクセッサ)が決まるような、
設計の基礎に反するプログラミングをサポートするとは考えにくい。

955 :デフォルトの名無しさん:2010/05/26(水) 06:54:24
traitsやconceptでメンバー変数も対象にするようにしないとなあ

956 :デフォルトの名無しさん:2010/05/27(木) 23:50:48
その前にまずconcept自体を入れないと

957 :デフォルトの名無しさん:2010/05/29(土) 09:43:36
引数なしの非explicitメソッドx(void)は()を省略してobj.x;に置き換えられる
引数ひとつのexplicit非指定のメソッドx(arg)はobj.x = arg;で置き換えられる
これを導入するだけでプロパティがらくらく定義できて気持ちイイのになんでやらないのか

958 :デフォルトの名無しさん:2010/05/29(土) 09:50:19
>>957
C#使ってると、obj.Size()でエラーが出てたりして非常にウザイ。関数とプロパティの区別は面倒。プロパティはいらない。

959 :デフォルトの名無しさん:2010/05/29(土) 16:40:41
デフォで省略可能なのはキモい
何かつけたら省略可能、ならいいけど

960 :デフォルトの名無しさん:2010/05/29(土) 16:59:02
プロパティと勘違いしてげった関数の括弧を省略しても文法的には通るのが大きな罠だよ

961 :デフォルトの名無しさん:2010/05/29(土) 17:24:42
通っても別にいいんじゃない

962 :デフォルトの名無しさん:2010/05/29(土) 17:41:45
explicit指定では省略できなくすればその問題も解決


963 :デフォルトの名無しさん:2010/05/29(土) 17:43:49
問題はゲッタ関数じゃないのにプロパティっぽく呼べる方じゃないか
全部explicitつけろとか勘弁

964 :デフォルトの名無しさん:2010/05/29(土) 17:45:03
>>959
コンストラクタさんディスってんのか
implicit指定がなぜ無いのか理解に苦しむ…

965 :デフォルトの名無しさん:2010/05/29(土) 17:49:25
ディスってるよ!

966 :デフォルトの名無しさん:2010/05/29(土) 17:50:24
this

967 :デフォルトの名無しさん:2010/05/29(土) 17:54:10
Intel Distel?

968 :デフォルトの名無しさん:2010/05/30(日) 03:00:38
アクセッサとまでは言わんけど、メンバ変数をクラスの外からは読み出し専用に
出来る方法があればなあとは思う。

969 :デフォルトの名無しさん:2010/05/30(日) 11:59:05
昔は欲しいと思ったけど、今は必要とは思わないし、無くてよかったと思う。

970 :デフォルトの名無しさん:2010/05/30(日) 12:02:55
アクセッサがあったら実際の型とは別の型として評価したり、評価だけに副作用を入れる事もできたりと夢が広がるが
結局それはメンバとしてではなくて別の一般的な機能
(例えばfactory patternをそのまま組み込んだような、派生クラスの型を追跡できないのにインスタンスをポインタを介さずに操作できる何か)
として規定してしまったほうがスマートなんだよなぁ・・・。

971 :デフォルトの名無しさん:2010/05/30(日) 13:14:09
あのねオブジェクト指向というのは、人間が自然に持っている、
物などを認識する時にあれは魚だとか、これは食べられるだとか
分類しているそれの事なんです、ので、ものすごく古い行為です。
俺はC++よりいい方法でオブジェクト指向を有効に使って
プログラミングできる言語を思案中ですよ、みなさん。

972 :デフォルトの名無しさん:2010/05/30(日) 13:15:34
そうですか

973 :デフォルトの名無しさん:2010/05/30(日) 13:18:32
C++「^^;」

974 :デフォルトの名無しさん:2010/05/30(日) 13:26:04
>>968
まんまRubyのattr_readerじゃん

975 :デフォルトの名無しさん:2010/05/30(日) 13:40:58
>>968
メンバをconstにしてprivateな雪駄内でconst_castして代入すればいい


976 :デフォルトの名無しさん:2010/05/30(日) 14:26:25
>>975 未定義動作

977 :デフォルトの名無しさん:2010/05/30(日) 14:28:28
メンバでもだめなんだっけ?

978 :デフォルトの名無しさん:2010/05/30(日) 14:29:13
>>975
const_cast覚えたての頃にやったわw

979 :デフォルトの名無しさん:2010/05/31(月) 07:49:35
>>975
そんなことするより、これでいいんじゃ
class foo {
public:
 foo() : impl(1), val(impl) {}
 void increment() { impl++; }
 const int& val;
private:
 int impl;
};


980 :デフォルトの名無しさん:2010/05/31(月) 08:04:51
メンバに参照を持つのはだるい

981 :デフォルトの名無しさん:2010/05/31(月) 08:07:59
参照は小粒でピリリと辛い

982 :デフォルトの名無しさん:2010/05/31(月) 08:16:09
コンパイラに代入演算子が自動生成できんぞオラァって言われるしな

983 :デフォルトの名無しさん:2010/05/31(月) 12:26:35
const_castって未定義じゃない使いかたってあるの?

984 :デフォルトの名無しさん:2010/05/31(月) 12:51:23
>>983
未定義動作になるのは、生成時点で const な型を持っていたオブジェクトに対して
書き込みをしてしまった場合。

最終的に書き込みが発生しなかったり、生成時点で const じゃなかったオブジェクトに
対して書き込みが発生するぶんには未定義動作とはならない。

985 :デフォルトの名無しさん:2010/05/31(月) 14:09:12
>>979
メンバの宣言は
private:
int impl;
public:
const int& val;
の順でやらないとまずくない?

986 :デフォルトの名無しさん:2010/05/31(月) 14:13:13
はっきり言ってconst_castには0xで消えてもらいたかった。
規格から消すだけじゃユーザーが独自にtemplate関数とc style castで作ってしまいそうだから
javaのgotoみたいに明示的に締め出すくらいしてほしかった。

987 :デフォルトの名無しさん:2010/05/31(月) 14:32:35
C形式のキャストを消すほうが先だ。

988 :デフォルトの名無しさん:2010/05/31(月) 14:45:13
あんなのD組

989 :デフォルトの名無しさん:2010/05/31(月) 15:19:24
D言語は関係ないだろ!

990 :デフォルトの名無しさん:2010/05/31(月) 17:06:27
Cを超える者…それがDだ

991 :デフォルトの名無しさん:2010/05/31(月) 17:09:58
DはD組送りで

992 :デフォルトの名無しさん:2010/05/31(月) 17:24:22
DとC++では用途が違うだろ。
変数CをC++するのとchar moji = 'C';をmoji++するくらい別モノ

993 :デフォルトの名無しさん:2010/05/31(月) 18:05:58
moji is 0x0.

994 :デフォルトの名無しさん:2010/05/31(月) 20:02:38
>>986
const使わないで作るバカは多いから
const_castがないとそういうバカの作った関数などが使えなくなる
あとCOMはconstないから(ry

995 :デフォルトの名無しさん: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;
}

996 :デフォルトの名無しさん:2010/06/01(火) 15:28:08
[&]を[=]にするとできましたが、
コピーコストがかかる場合もあるだろうから嫌だ・・・。
1ってどっからきたんだ・・・?

997 :デフォルトの名無しさん:2010/06/01(火) 15:30:52
>>996
[=]にしないと、もともとのmはスコープアウトして不定になるんじゃないかい?

998 :デフォルトの名無しさん:2010/06/01(火) 15:32:44
次ぎスレまだー? 次はAなのか10なのか。

999 :デフォルトの名無しさん: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 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

207 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)