10/03/31 11:19:56
>>57
賢い人には unexpected() が terminate() になったら何がうれしいのかわかるの？
62:デフォルトの名無しさん
10/03/31 11:21:49
>>60
行連結は Raw string literal を解釈するフェーズより前のはずなんだが、
どうなってるんだろう？
63:57
10/03/31 11:25:52
お前もか
>>61
>>50と>>52に共通する事項について俺は言及しただけだ
64:60
10/03/31 11:26:41
>>62
きっとPre-Preprocessorが動作してだな
65:デフォルトの名無しさん
10/03/31 11:28:35
>>63
じゃあ noexcept で何がうれしいのかわかってる人はいないってこと？
66:デフォルトの名無しさん
10/03/31 11:30:59
コンパイラの最適化が期待できるのは十分うれしい 〉noexcept
67:デフォルトの名無しさん
10/03/31 11:32:45
>>66
え？だって例外発生したら terminate() 呼ばなきゃいけないんでしょ？
今まで unexpected() 呼ばなきゃいけなくて余計なコードが出てたのと同じじゃないの？
この違いに基づいてどういう最適化ができるの？
68:デフォルトの名無しさん
10/03/31 11:33:45
Raw string literal は "[ ]" から "( )" になったのか。
<: :> を使用する時どうするのかと思ってたが解決したな。
69:デフォルトの名無しさん
10/03/31 11:37:42
>67
いままで規格上 throw() で最適化することは期待されてなかったんだから
前進したのは事実だろう。terminate() 云々はコストはほぼないって感じらしい。
70:デフォルトの名無しさん
10/03/31 11:40:58
>>67
少しは足りない脳で考えて見ろよ
71:デフォルトの名無しさん
10/03/31 11:46:51
>>67
noexceptの原論文を読みなよ。
リアクションが馬鹿っぽいから説明してやる気にはなれない。
>>54
それが意味がある局面だってある。
72:デフォルトの名無しさん
10/03/31 11:46:55
で、いつごろから
throw[ \t]*([ \t]*)[ \t]*
をgrepしてnoexceptに書き換えていけばいいの？
73:デフォルトの名無しさん
10/03/31 11:47:44
>>69
今までだって throw() が付いてる関数から呼び出してる関数が全部 throw() なら
unexpected() の呼び出しコードは不要、といった類の最適化はできたでしょ？
不測の例外発生に伴って terminate() を呼ぶコストが unexpected() を呼ぶコストと
違うのは何によるのかもわかってないのに「最適化に役立つ」とか言い切っちゃって良いの？
74:デフォルトの名無しさん
10/03/31 11:48:02
noexceptって型なの？？
N2855 noexceptについて - xyuyuxの日記
URLﾘﾝｸ(d.hatena.ne.jp)
75:デフォルトの名無しさん
10/03/31 11:48:46
落ち着いてまとまった解説書を書いてくれないと
俺はたぶん職を失う
76:デフォルトの名無しさん
10/03/31 12:11:09
>>73
>>71
77:デフォルトの名無しさん
10/03/31 12:13:05
本の虫: 例外指定について
URLﾘﾝｸ(cpplover.blogspot.com)
78:デフォルトの名無しさん
10/03/31 12:41:34
>>71
わかったよ。
URLﾘﾝｸ(www.open-std.org)
以下の２点が 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:デフォルトの名無しさん
10/03/31 12:48:36
>>73
unexpected()とterminate()の違いを理解してないね。
80:デフォルトの名無しさん
10/03/31 12:51:27
小さいhelper関数をnoexcept宣言で書ければ凄く便利だよ。
例えばベクトル演算系のクラスライブラリ書いてる時。
81:デフォルトの名無しさん
10/03/31 12:54:17
noexcept 演算子を追加しといて関数の静的解析はしないとか、意味わからんな。
82:78
10/03/31 12:59:47
あれ？
xxx_nothrow_xxx<> は noexcept 演算子で定義されてて、 noexcept 演算子は
例外指定については throw() も noexcept(true) も同じになるんで、 >>78 の２点目は
違わないね。
例外仕様としての noexcept よりも演算子としての noexcept のほうが肝心な気が
してきた。
83:デフォルトの名無しさん
10/03/31 13:25:41
例外は抽象解釈泣かせだからね。
リフトしまくって計算量は増えるわ、情報は劣化するわ。
84:デフォルトの名無しさん
10/03/31 13:39:44
>>83 いきなり何の話だ？誤爆？
85:デフォルトの名無しさん
10/03/31 13:45:54
>>83
× 例外は
○ 例外仕様は
かな？
86:デフォルトの名無しさん
10/03/31 17:57:09
throw()とthrow(...)以外をdeprecatedにするんじゃダメだったのかなぁ
noexcept演算子はthrow?とかじゃダメだったのかなぁ
ラムダ用の予約語はあんなに強硬に反対してたのに、こんな下らない機能に予約語とか意味が分からない
87:デフォルトの名無しさん
10/03/31 18:01:28
n3050読めば分かるが、
nothrow_move_constructorなどなど、非常に重要な概念。
下らないなんてとんでもない。
88:デフォルトの名無しさん
10/03/31 18:03:27
下らないは言い過ぎとしても、予約語が必要なほど重要でもないと思う
89:87
10/03/31 18:05:13
予約語については特に異論ない。
90:デフォルトの名無しさん
10/03/31 18:09:41
時間がないから、構文上のトラブルを避けるためにぶち込んだんだろうな
そんな都合で決めないで欲しいけど
91:デフォルトの名無しさん
10/03/31 18:12:02
void hoge() throw; //なんか投げる
void hoge() ~throw; //投げないらしい
これでいいじゃん
それか!throwとか
92:デフォルトの名無しさん
10/03/31 18:22:21
>>91
デストラクタにならって~throwとか？www
>>90
> 時間がないから、構文上のトラブルを避けるためにぶち込んだんだろうな
> そんな都合で決めないで欲しいけど
激しく同感。
いいよ、もう来年まで持ち越してもいいからちゃんとまともにしてくれ！
93:デフォルトの名無しさん
10/03/31 18:25:03
せめてexceptにしてくれ
noexcept(false)って何だよ二重否定かよ
94:デフォルトの名無しさん
10/03/31 18:26:31
クラスのメンバ関数にthrow()と書くと、それが例外を投げるように変更しようとした時に 制限となってしまう。
あるいは、そのクラスから派生クラスを作ろうとしたときもインターフェイスに強い制限をかけることになる。
とHarb Sutter 氏がおっしゃっていますが、
それはnoexceptでも同じじゃねえか？
何が良いの？？？
95:デフォルトの名無しさん
10/03/31 18:27:27
>>93
宣言の方でexceptだと困る、
operatorの方も同じ予約語にしたい、
こんな感じでは?
96:デフォルトの名無しさん
10/03/31 18:32:25
>>94
つ 14.7.2.2
97:94
10/03/31 18:34:10
>>96
規格書14.7.2.2を読むべし、と？
英語読めない俺にはC++を使うのは難しい
98:デフォルトの名無しさん
10/03/31 18:53:58
まぁ、例外なんか使うなってこった。
メモリ確保などの、失敗がありえない&致命的な処理で失敗したら即ログ吐いてabort。
これでいいでしょ。
99:デフォルトの名無しさん
10/03/31 19:17:28
>>72
そのうちBOOST_NOEXCEPT( )みたいなマクロが流行るんじゃない？
100:デフォルトの名無しさん
10/03/31 19:24:56
さっさと変換して、コンパイラが対応するまで#define noexcept throw()しとけばいい
101:デフォルトの名無しさん
10/03/31 19:45:14
まてnoexcept(false)っていう文法もあるらしい。
そもそもnoexceptを記載する場所と throw()を記載する場所って同じなのか？
102:デフォルトの名無しさん
10/03/31 20:22:03
いきなり>>3以降の、C++学園の人々に修正が迫られるな。
103:デフォルトの名無しさん
10/03/31 20:23:57
今回の変更って、もう決定なの！？
104:デフォルトの名無しさん
10/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
10/03/31 20:56:27
>>104
分かりやすい解説ありがとう。
106:デフォルトの名無しさん
10/03/31 20:58:02
> いずれにせよ、C++0xの規格は、2011年内に、制定されるだろう。
既に来年かwwww
107:デフォルトの名無しさん
10/03/31 20:58:31
なんかかっこいいな
108:デフォルトの名無しさん
10/03/31 20:59:50
どうせnoexceptにNBから総ツッコミ入って遅れるだろ
109:デフォルトの名無しさん
10/03/31 21:56:28
安心して。2011の11は16進数だから。
110:デフォルトの名無しさん
10/03/31 22:21:20
>>46
デストラクタをprivateにして、
明示的にEnd()を呼ばせるようにしたら？
111:デフォルトの名無しさん
10/03/31 22:24:06
>>110
良くある実装だけど何となくウザイ…。
112:デフォルトの名無しさん
10/03/31 22:26:02
>>110
いちいちEnd呼ぶのまんどくせ。
でもいい案思いつかね。
113:デフォルトの名無しさん
10/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:デフォルトの名無しさん
10/03/31 23:00:22
もともと例外仕様はassertと同じく
「俺の書いたコードを信用して！ もし間違ってたら殺していいよ！」
というプログラマの自己責任による表明だから。
コンパイルエラーが出れば便利、てのは同意だけど。
115:デフォルトの名無しさん
10/03/31 23:02:06
throw()とnoexceptの関係を
assertとstatic_assertみたいにすればよかったんじゃね
116:デフォルトの名無しさん
10/03/31 23:08:22
お前ら、何か忘れてるんじゃない？
C++には関数ポインタがある。
だから、コンパイル時には実行時にどのコードが走る可能性があるか決定できない。
つーことは、コンパイル時に例外が投げられる可能性があるか無いかは判断できない。
117:デフォルトの名無しさん
10/03/31 23:10:44
よくよく思い出せ。
適当なポインタを適当な関数型にキャストして適当に()書いたらそこのコードが走るような言語だぞ。
あまり無理を言うな。
118:デフォルトの名無しさん
10/03/31 23:29:28
>>114
> 「俺の書いたコードを信用して！ もし間違ってたら殺していいよ！」
> というプログラマの自己責任による表明だから。
分かりやすいな、例え。
119:デフォルトの名無しさん
10/03/31 23:36:56
誰かADLをどうにかしろ！！
俺にも分かるようにしてくれ！
120:デフォルトの名無しさん
10/03/31 23:37:28
本当にコンパイル時にチェックするなら、
noexceptからはnoexceptしか呼び出せない、とかにする必要があるな。
これはちょうど今のconstと同じ扱いになるな。
てことは、下位互換のためにnoexcept_castが追加されるな。
noexcept関数から、例外を投げないことが分かっているnoexcept指定の無い関数を呼び出す場合は、
noexcept_castをしてください、みたいな。
ウザいな。
121:74
10/03/31 23:40:33
>>120
つまり>>74で言われていたみたいにcv修飾子みたいにするわけですね。
・・・ちょっと待て！
テンプレートの時にどう解決するんだそれは！？
メタプログラミングが「前提」となるなんていやだぞ
C++0xを実装できるコンパイラが少なくなるようでは、
「規格どおりに書いたのに移植性が全然ありません」
とかC++を使う意義が無くなってしまうじゃないか！
122:デフォルトの名無しさん
10/03/31 23:49:53
>>121
そうなると、テンプレートは、noexceptとそうじゃない奴の二種類ずつメソッドを用意する事になるな。
constとの組み合わせもあるから、沢山定義しないといけないね(笑
123:デフォルトの名無しさん
10/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:デフォルトの名無しさん
10/04/01 01:06:09
moveも出来るか考慮した方が
125:デフォルトの名無しさん
10/04/01 04:24:39
URLﾘﾝｸ(cpplover.blogspot.com)
> 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
10/04/01 07:46:20
>>125
> 巻き戻すって、一旦行連結しちゃったらもうどこに改行があったかなんて
> わからないんじゃないの？どういう実装を想定してるんだろう？
そう、俺もそう思って>>60の発言になった。
びっくりだわー
127:デフォルトの名無しさん
10/04/01 09:34:17
行連結する前に丸々コピーするだけだろ
128:デフォルトの名無しさん
10/04/01 11:40:08
え？
129:デフォルトの名無しさん
10/04/01 19:10:02
const char *s = R"EOS(
#include"foo.h"
)EOS";
phase2が終わった直後にfoo.hを書き換えるとどうなるの？
ねえねえ
130:デフォルトの名無しさん
10/04/02 09:38:56
Raw String の実装は、とある強力コンパイラメーカーの実装による要望で、
実のところ "Phases of translation" は as is であって、実際のコンパイル動作とは関係ない。
というか馬鹿正直に守っているコンパイラは事実上無い。
>phase2が終わった直後にfoo.hを書き換えるとどうなるの？
言語仕様の外。そういうときの動作は規定していない。
とくにこまらないだろ。
131:デフォルトの名無しさん
10/04/02 09:58:13
>>130
distcc や ccache などのツールはプリプロセスがコンパイルと分離された
フェーズであることに依存して、一旦プリプロセス結果を生成し、それを
コンパイルは別の独立したプロセスに投げたりする。
プリプロセスまでは gcc などの無償利用できるプリプロセッサを使い、
コード生成は専用のクロスコンパイラを使うようなことも、 Raw String Literal の
仕様さえなければこれまでどおり可能。
やっぱり心配だ。
132:デフォルトの名無しさん
10/04/02 10:12:19
>>129
それ include されるの? 単に「#include"foo.h"\n」って文字列に解釈されるんじゃないの?
133:デフォルトの名無しさん
10/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:デフォルトの名無しさん
10/04/02 16:20:07
>>133です。反応無いので取り下げます～。
お邪魔しました～。
135:デフォルトの名無しさん
10/04/02 16:53:06
スレタイから C++ とったほうがいいかもね。
0x だけで探せるでしょ。
>>133
定義域を明確にして↓のスレに行ったほうがいい。
【FPU】 浮動小数点 【SSE】
ｽﾚﾘﾝｸ(tech板)l50
ム板ではどのスレでも三時間で答えが来る確率は低いが。
136:デフォルトの名無しさん
10/04/02 18:15:26
>>132
一旦includeしてから"revert"するんでしょ
125によると
137:133
10/04/02 20:13:26
>>135
ぁぃゃ～。しまったです。
普通の質問スレと勘違いしてしまいしましたです。
ホントに申し訳ない。Orz
それと、誘導ありがとうです。
138:デフォルトの名無しさん
10/04/02 21:48:36
右辺値参照を用いて（a+b)*(c+d)*e のような行列の積を正しく計算
できますか？
a *= bの行列演算では、裏側で一時オブジェクトを導入しない限り
正しい計算結果は得られないはずですが( a += bとはわけが違う )、
右辺値参照でもこれと同じような事は起きませんか？
｢いや、C=prod(A,B)のような使い方しか想定してない。｣と言うのなら
仕方ないですが。
※｢右辺値参照｣の右辺値という言葉はかえってわかりにくいと思うの
ですが、皆さんはどうですか？
139:デフォルトの名無しさん
10/04/02 22:55:15
誰もがそう思ってるけど、50年来の悪しき伝統なので変えられない
140:デフォルトの名無しさん
10/04/02 23:49:29
>>138 何言ってるのかわからん。 >139 はエスパーか？
141:デフォルトの名無しさん
10/04/02 23:51:29
コンパイラ黎明期から右辺値という名称
142:デフォルトの名無しさん
10/04/03 00:52:24
>>135
> スレタイから C++ とったほうがいいかもね。
> 0x だけで探せるでしょ。
しかし
C++0xからC++をとって、その上2009年中に終わらなかったのだから0xを取ると
何もなくなってしまうじゃないかw
143:126
10/04/03 00:54:03
>>127
どういう意味？
144:デフォルトの名無しさん
10/04/05 01:18:54
unique_ptrってコンテナに使っても大丈夫だったのか
145:デフォルトの名無しさん
10/04/05 07:40:06
>>144
> unique_ptrってコンテナに使っても大丈夫だったのか
C++0x - Wikipedia, the free encyclopedia
URLﾘﾝｸ(en.wikipedia.org)
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:デフォルトの名無しさん
10/04/05 10:27:19
unique_ptrとshared_ptrの違いは何よ？
147:デフォルトの名無しさん
10/04/05 10:51:45
unique か shard か。
148:デフォルトの名無しさん
10/04/05 11:24:12
意味わかんね
149:デフォルトの名無しさん
10/04/05 11:27:17
所有権の話。
150:デフォルトの名無しさん
10/04/05 11:39:36
Pimplとか考えると、一番使用頻度高いのってやっぱ shared_ptr だよな？
151:デフォルトの名無しさん
10/04/05 20:22:09
>>150
stdに入っているauto_ptrと、boostに入っているshared_ptrとで
どっこいどっこいぐらいかな。
stdにshared_ptrが入れば無敵。
ところで何でscoped_ptrがstdに入らなかったの？
最も軽いスマポだったりしない？
152:デフォルトの名無しさん
10/04/05 20:45:59
unique_ptr がそれじゃないかな
153:デフォルトの名無しさん
10/04/06 02:16:36
C++0x前提だとuniqueと比べてscopedのメリットって何も無いよな
154:デフォルトの名無しさん
10/04/06 21:36:55
スマートポインタって生ポインタより遅くなるの？
155:デフォルトの名無しさん
10/04/06 21:40:06
メモリの確保やコピーの際にコストがかかることもあるが
ポインタを使う分にはinline化が効くから生のポインタと同じ
156:デフォルトの名無しさん
10/04/06 21:43:22
必要な機能に必要十分なものを使えば、
オーバーヘッドはない。そう実装されている。
157:154
10/04/06 21:46:07
>>155-156
ありがとう。
なんか変なメンバを持ってたりすると無駄に重くなるかな、と心配だった。
(もちろんboostやstdの有名スマポの話です。)
> 必要な機能に必要十分なものを使えば、オーバーヘッドはない。
なるほど。つまり単にstd::auto_ptrで済む所にstd::tr1::shared_ptrを使用すると
無駄な参照カウント分が無駄なオーバーヘッドとなるが、
それは必要十分じゃないから、ってことね。
158:デフォルトの名無しさん
10/04/07 00:19:47
何億回もループ回すとかミリ秒単位のリアルタイム処理するとか
そんなんでなけりゃスマポのオーバーヘッドなんて何でもないよ
159:デフォルトの名無しさん
10/04/07 01:10:46
auto_ptrの代わりにshared_ptrを使う場合に、auto_ptrは複製が無いので参照カウンタのオーバーヘッドが起きない。
auto_ptrのムーブ（=演算子）はshared_ptrではswapを使うのでやはり参照カウンタのオーバーヘッドが無い。
160:デフォルトの名無しさん
10/04/07 01:12:12
日本語でおｋ
161:デフォルトの名無しさん
10/04/07 01:13:09
>>159 なにいってんのかわかんねぇ。
162:デフォルトの名無しさん
10/04/07 01:18:00
auto_ptrの代わりにshared_ptrを使う場合に（と断っておきながら）、auto_ptrは…（shared_ptrを使う場合じゃなかったのかよｗｗ）
auto_ptrのムーブ（=演算子）は（何、auto_ptrのムーブの話？）shared_ptrでは…（おいおい、auto_prtのムーブってshared_ptrでも使われるのか？ｗ）
163:デフォルトの名無しさん
10/04/07 07:26:02
>>159
日本語読解上級者コース
164:デフォルトの名無しさん
10/04/07 08:31:58
shared_ptr はどちらかと言うと，実行時オーバーヘッドを許してでも
(使わないかも知れない) 多くの機能をデフォルトで提供する，という設計思想ではないですかね？
具体的には， deleter の動的指定， thread-safe as an int のための排他処理， weak_ptr への対応とか．
もちろんこれらのオーバーヘッドが必要になる文脈は限定的ですけれど．
165:デフォルトの名無しさん
10/04/07 08:51:09
ソースみりゃ分かるが shared_ptr はけっこういろいろやってんぞ
カウンタも shared 分と weak 分と 2 つあるし
ふつーに実行時オーバーヘッドあるだろ
166:デフォルトの名無しさん
10/04/07 09:47:46
>>164
> deleter の動的指定， thread-safe as an int のための排他処理
使わない時もオーバーヘッドになる?
167:デフォルトの名無しさん
10/04/07 11:18:37
排他処理と生成破棄以外のコストは気にしなくていいと思う
168:デフォルトの名無しさん
10/04/07 13:42:51
>166
deleter の動的指定にかかるコストは shared_ptr オブジェクトの生成と破棄の際に，
排他処理は shared_ptr オブジェクトのコピーの際に，それぞれ常に付きまとうと思います．
もちろん，これらのオーバーヘッドが shared_ptr を利用する際の全体的なコストから見て
どの程度有意かはまた別の問題だと思いますけれど．
169:デフォルトの名無しさん
10/04/07 18:46:51
まずもって心配いらん
安心して使いたまへ
170:デフォルトの名無しさん
10/04/07 19:34:53
>>157
unique_ptrはすごいぞ
最適化かけたらアセンブリ出力にunique_ptrが居ねえ
171:デフォルトの名無しさん
10/04/07 19:36:01
それは auto_ptr でも scoped_ptr でもいっしょだろ。
172:デフォルトの名無しさん
10/04/07 21:56:44
>>168
そういうのオーバーヘッドって言わないでしょ。
173:デフォルトの名無しさん
10/04/07 22:00:35
オーバヘッ！
オーバヘッ！
174:デフォルトの名無しさん
10/04/07 23:01:02
URLﾘﾝｸ(dictionary.goo.ne.jp)
全然関係ないけど油をそそいでみる
175:デフォルトの名無しさん
10/04/08 08:02:40
冒頭のテンプレ読んだんだけど、今のC++ってこんなことになってるんだな。
カオスすぐる。
176:デフォルトの名無しさん
10/04/08 08:16:47
adhocやるんだって
URLﾘﾝｸ(homepage1.nifty.com)
177:デフォルトの名無しさん
10/04/08 11:09:07
hoge[1, 2, 3] = h; ←これ配列でも使えるように、オーバーロードもできるように仕様に入れるべき
hoge[1][2][3] = h;みたいなのをエミュレートするのに余計なオーバーヘッドのコストを支払うのは嫌だ
178:デフォルトの名無しさん
10/04/08 11:19:15
>>177
operator()のオーバーロードでいいじゃん。
オーバーロード以前にhoge[1, 2, 3]っていう文法ないんだし。
179:デフォルトの名無しさん
10/04/08 11:22:25
>>177
オーバーヘッドは防げないか？コーディングが面倒なだけで。
たとえばどんな hoge[1][2][3] の実装を想定してるの？
180:デフォルトの名無しさん
10/04/08 11:26:21
>>178
hoge(1, 2, 3) = h;
でもこれって見ため最高に気持ち悪くないか？
fortranとかで慣れてる人はいいのかもしれないけど
メンバへの参照アクセスは[]で縛りたいって思うわけよ
181:デフォルトの名無しさん
10/04/08 11:40:59
[1, 2, 3] ってカンマ演算子で最終的に3が返るからどちらにしろだめだろ
(1, 2, 3)も同じ理由からあまり推奨できない
182:デフォルトの名無しさん
10/04/08 11:48:31
>>179
次元Nを引数にしたテンプレートのプロクシクラスで、operator[]で再帰的にうんぬんする感じ
整数の代入*次元数+
整数を引数にプロクシの参照を返すoperator[]呼び出し*(次元数-1)+
整数のポインタを引数にメンバへの参照を返す生のアクセサ（atメンバ）呼び出し*1
頑張ったけどこれだけ実行時コストがかかってしまう
183:デフォルトの名無しさん
10/04/08 11:59:28
>>182
プロクシの参照がコンパイル時に全部解決されれば、実行時のコストは無いよね？
184:デフォルトの名無しさん
10/04/08 12:36:07
hoge[{1,2,3}] で。
185:デフォルトの名無しさん
10/04/08 14:42:16
プロクシクラスを持つのにvoltile修飾してなければ問題ない。
あんまりピリピリするな。
186:デフォルトの名無しさん
10/04/08 19:23:14
0xのメルセンヌ・ツイスタって使ったらいちいち著作権表示しないといかんの？
187:デフォルトの名無しさん
10/04/08 21:05:17
コンパイラのライセンス次第だろ
GCCは非対応にするのかな
GPLにはできんよなぁ
188:デフォルトの名無しさん
10/04/08 21:55:43
わざわざできるようにしたんだから 0x 的には >>184 だろう。
189:デフォルトの名無しさん
10/04/08 21:58:24
x[{1,2,3}];ってやると配列が渡されるの？
190:デフォルトの名無しさん
10/04/08 22:14:33
initializer_list が渡されるんだろう。
191:デフォルトの名無しさん
10/04/09 02:01:50
URLﾘﾝｸ(www.artima.com)
Presentation Materials: Overview of the New C++ (C++0x)
by Scott Meyers
Single-user license (personal use only)
$29.96
これはなんだー
192:デフォルトの名無しさん
10/04/09 02:08:22
さすがメイヤーズ先生や
日本語解説書なんか最初からいらんかったんや
193:デフォルトの名無しさん
10/04/09 02:42:38
メイヤーズ先生ってもっとおじいちゃんだと思ってたわ
194:デフォルトの名無しさん
10/04/09 07:13:03
Scott Meyers先生すげぇ
195:デフォルトの名無しさん
10/04/09 11:31:00
髪の毛こんなにあるとは思わなかったな
196:デフォルトの名無しさん
10/04/09 11:38:58
すぽすぽ先生がいかにもな風貌すぎるんだよ
197:デフォルトの名無しさん
10/04/09 12:43:24
すっぽすっぽ
ふっさふっさ
198:デフォルトの名無しさん
10/04/09 13:13:14
まじか…このTarget publication date
URLﾘﾝｸ(www.iso.org)
199:デフォルトの名無しさん
10/04/09 14:06:30
1012年／（ ＾o＾ ）＼
200:デフォルトの名無しさん
10/04/09 21:12:31
Target publication date: 2012-02-28
>>199
Ed. 紫式部かよ。
201:デフォルトの名無しさん
10/04/09 21:32:53
そのころにはVC11とGCC4.7がそれなりの実装してくれてるといいな
202:デフォルトの名無しさん
10/04/09 21:34:11
文書のタイトルが「Microsoft PowerPoint - C++0x.ppt」になっとる
336ページのパワーポイントw
203:デフォルトの名無しさん
10/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:デフォルトの名無しさん
10/04/09 23:59:34
>>201
> そのころにはVC11とGCC4.7がそれなりの実装してくれてるといいな
VCはともかくg++は5.x系になっても良いくらいの大変革だろ。
むしろg++0xとか名前が変わるくらいの出来事。
205:デフォルトの名無しさん
10/04/10 00:00:56
URLﾘﾝｸ(d.hatena.ne.jp)
206:デフォルトの名無しさん
10/04/10 00:23:29
一つの言語の都合だけではGCCのメジャーバージョンは上がらんよ
207:デフォルトの名無しさん
10/04/10 00:31:51
>>206
そーいや複数の言語を扱う代物だったな。
208:203
10/04/10 00:32:51
>>205
私も自分でググった時にそのページは見つけたのですが、
それだけではClassXしか分かりませんでした。
ClassY, ClassZについて正確な動作をご存じの方がいらっしゃったら
どうかよろしくお願いします。
209:デフォルトの名無しさん
10/04/10 00:34:56
デフォコン優先で無理ならリストだろ
210:デフォルトの名無しさん
10/04/10 00:44:19
>>209
まてそのソースは？
例のブログの人の降臨を待つべきだ。
211:デフォルトの名無しさん
10/04/10 00:57:33
召還しないで205のコメント欄で聞きゃいいよ
そこの人も日本NBのメンバのはずだから
212:デフォルトの名無しさん
10/04/10 00:58:23
自分でドラフトを読むという選択肢は無いのかね？
213:デフォルトの名無しさん
10/04/10 01:00:37
あるよ。
214:デフォルトの名無しさん
10/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:デフォルトの名無しさん
10/04/10 14:31:28
Otherwise多すぎwwww
汚ねぇ仕様書だ・・・。
216:デフォルトの名無しさん
10/04/10 14:51:29
まだこの後に4項目続くんだぜｗ
217:203
10/04/10 15:25:27
皆さんありがとうございます。
特に>>214さんには決定打をいただきまして
ありがとうございます。
218:デフォルトの名無しさん
10/04/10 17:39:14
誰か猫でもわかるオーバーロード入門を書いてください
219:デフォルトの名無しさん
10/04/10 17:47:55
>>218
オーバーロードのどこが難しいの？
猫でも分かるADL入門
猫でも分かるTMP入門
のがやばいだろ。
220:デフォルトの名無しさん
10/04/10 18:41:38
日本の猫はいったいどこまで賢くなろうとしているのか
221:デフォルトの名無しさん
10/04/10 19:16:55
猫は害獣
222:デフォルトの名無しさん
10/04/10 19:34:47
我が輩は猫である
名前は間田内
223:デフォルトの名無しさん
10/04/10 20:52:31
我輩は猫である
I am a cat.
224:デフォルトの名無しさん
10/04/10 21:28:43
仕事はもう無い
225:デフォルトの名無しさん
10/04/10 21:37:30
どこでミスしたかとんと見当がつかぬ。
226:デフォルトの名無しさん
10/04/10 21:42:07
何でも薄暗いじめじめした所で壁に向かって仕事していた事だけは記憶している。
227:デフォルトの名無しさん
10/04/10 21:46:09
吾輩はここで始めてプログラマというものを見た。
228:デフォルトの名無しさん
10/04/10 22:47:54
>>227
吾輩はここで始めて 上司 というものを見た。
じゃないかな・
229:デフォルトの名無しさん
10/04/10 23:10:01
Boost.BigInt
はLGPL汚染されるってことで
ｽﾚﾘﾝｸ(tech板)
で話題になってるよ。
もし興味ある方はぜひ。
ｽﾚﾘﾝｸ(tech板:741-743番)
が発端。
230:デフォルトの名無しさん
10/04/10 23:27:53
TR2でbigint入れて欲しいとかそういうネタ振りですか
231:デフォルトの名無しさん
10/04/10 23:45:18
Cat, I'm kitty cat.
232:デフォルトの名無しさん
10/04/10 23:47:04
>>230
そんなん期待できねぇよ。
できたら願ったり叶ったりだがな。
233:デフォルトの名無しさん
10/04/11 06:26:55
>219
どうやって candidate functions が決まるのかを入れるなら name lookup の話を含むだろうし、
best viable function を定めるルールだけでもきっちり分かりやすく説明できるというのなら
今すぐ執筆してくれ。
234:デフォルトの名無しさん
10/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:デフォルトの名無しさん
10/04/11 14:19:37
油断ならねえなぁ
もしshared_ptrとかが汚染されたら大変なことになるよな
怖すぎる
236:デフォルトの名無しさん
10/04/11 15:31:43
bigint なんてそんな至る所で使われてんのか？
そういう類いのクラスには思えないのだが
237:デフォルトの名無しさん
10/04/11 18:14:59
>>236
いやたぶん使われていない。
だから標準Boost(って変な表現だが)に推されないんじゃね。
238:デフォルトの名無しさん
10/04/13 21:12:34
Visual Studio 2010 is now available!
URLﾘﾝｸ(blogs.msdn.com)
C++0x Core Language Features In VC10: The Table
URLﾘﾝｸ(blogs.msdn.com)
239:デフォルトの名無しさん
10/04/13 22:28:56
Japanese版早く出せ
240:デフォルトの名無しさん
10/04/14 23:34:16
>>239
1週間ぐらい待てないのか？
俺は待てない
241:デフォルトの名無しさん
10/04/15 05:06:09
あんまりソワソワしないで
242:デフォルトの名無しさん
10/04/15 18:46:38
あなたはいつでもキョロキョロ
243:デフォルトの名無しさん
10/04/15 20:40:40
よそ見をするのはやめてよ
244:デフォルトの名無しさん
10/04/15 20:44:14
おまえら何歳なんだよ
245:デフォルトの名無しさん
10/04/15 20:50:16
ょぅι゛ょです
246:デフォルトの名無しさん
10/04/16 01:45:57
いくつも愛を持ってる男の人って…
247:デフォルトの名無しさん
10/04/16 04:45:41
生物の目標が繁栄することだとすると
種をばらまく側としては、あちこちにターゲットを移してしまうのは
それはそれで正しいんだよな
↓では引き続きラムちゃんタイムをお楽しみください
248:デフォルトの名無しさん
10/04/16 13:11:56
lambdaっちゃ
249:デフォルトの名無しさん
10/04/16 14:47:45
誰がうｍ
250:デフォルトの名無しさん
10/04/16 14:59:59
>>238-249
流れでコーヒーﾌｲﾀｗｗ
251:デフォルトの名無しさん
10/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:デフォルトの名無しさん
10/04/16 20:12:17
X<T> operator*(X<T> &&, T &&);
これはいらないの？
253:デフォルトの名無しさん
10/04/16 20:20:59
>>252
書き漏らしてたよ。ありがと。
とにかく、こんなにたくさん必要だとすると
なにか省力化できる仕組みでもあればいいのだが…
254:デフォルトの名無しさん
10/04/16 20:32:59
右辺値参照なんて要らないよ
そんなに破壊可能なテンポラリが欲しければ
自分で一時変数作れ
255:デフォルトの名無しさん
10/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:デフォルトの名無しさん
10/04/16 21:11:50
>>254
> そんなに破壊可能なテンポラリが欲しければ
右辺値参照をなーんにも理解していないんだな。
少しは勉強しろ。ggr
257:デフォルトの名無しさん
10/04/16 21:25:34
右辺値参照が必要な場面では内部処理も変わるだろうから
省力化は難しいんじゃないか
258:デフォルトの名無しさん
10/04/16 21:30:43
>>257
やっぱりそうか…。
でも >>251 のように列挙的に宣言したとき、>>252 のような warning が欲しい :-p
259:デフォルトの名無しさん
10/04/16 21:45:38
>>255
速度欲しけりゃそんな風に書くなと
260:デフォルトの名無しさん
10/04/16 21:58:51
でもまあ、そこそこの速度で実行可能なら
ライブラリーではETやrvalue referenceを使ってがんばる意味はあると思うが
その結果、可読性が高くできるし
261:デフォルトの名無しさん
10/04/17 07:49:52
>>260
>>255みたいな書き方だと、そこそこレベルじゃねーだろ。
262:デフォルトの名無しさん
10/04/17 07:51:06
>>258
GIMPLE使えば独自warningも追加できるぞ。
263:デフォルトの名無しさん
10/04/17 12:56:43
Expression Template技法は俺には扱えない。
頭がおかしくなりそう。
Rvalue referenceなら気合いで何とかなりそうに
思える俺が居る。
264:デフォルトの名無しさん
10/04/17 13:00:31
>>261
その代償が >>251 だと思うと・・・
265:デフォルトの名無しさん
10/04/17 13:27:48
>>261
ベクトルなら加減・スカラー倍で計16個、
多元環なら加減乗算で計20個、
さらに除算ができる場合は計32個の定義が必要！！
266:デフォルトの名無しさん
10/04/17 13:29:58
>>265
あっスカラー倍の割り算を計算に入れてなかったので、さらに若干増えるぞ！
267:デフォルトの名無しさん
10/04/17 13:53:33
X = A;
X.AddAssign(B).AddAssign(C).AddAssign(d*D).AddAssign(E);
でいいだろ
268:デフォルトの名無しさん
10/04/17 14:18:35
やだよそんなJavaっぽい書き方
269:デフォルトの名無しさん
10/04/17 14:19:33
>>265
どうせお前はまともなクラスライブラリ書かないから心配することないよ。
270:デフォルトの名無しさん
10/04/17 14:28:09
演算子のオーバーロードとか
あくまで補助的なもんだと言うのに
速度も一緒に得ようとか烏滸がましいとは思わないか？
271:デフォルトの名無しさん
10/04/17 15:03:21
現実にいいライブラリ蓄積してきているからなあ。
272:デフォルトの名無しさん
10/04/17 15:11:42
ET用にはBoost.Protoなんてのもあるから、
Rvalue-ref. にもBoostがなんか作るんじゃね？
273:デフォルトの名無しさん
10/04/17 16:45:31
いい具合の代数幾何ライブラリを書きたくなって仕方ないのは、
多分 Cg/HLSL とか AltiVec 拡張とか触ってしまったからだろう。
それらをライブラリとして実装するのは無理があるというが俺の結論。
どうせ、ループ中で特定の行列をレジスタに乗ったままにしたいとか
思い始めたらインラインアセンブラとか使うハメになるのだから、
速度よりも使い勝手や安定性や保守性を重視した方が良いと思う。
274:デフォルトの名無しさん
10/04/17 21:34:55
凡人の結論を軽々突破するのがC++ templateだしな。
275:デフォルトの名無しさん
10/04/17 22:26:33
>>274
しかし凡人にはC++ Template metaprogrammingが使いこなせないから
やっぱり無理なんだろうw
276:デフォルトの名無しさん
10/04/21 23:21:47
>>234
上の方でBoost.Bigintがどうのこうのと言っていたが、
URLﾘﾝｸ(ja.wikipedia.org)
ここに
> ライブラリ
> 任意精度演算は多くの場合、専用ライブラリを呼び出すことで実装されている。
> そのライブラリがデータ型を定義し、数値を指定した精度で格納したり、
> 計算を実行するサブルーチン群を提供している。
> ライブラリによって数値の内部表現は異なる。整数のみを扱うライブラリもあるし、
> 各種基数（十進、二進など）で浮動小数点数を格納するもある。
> 分数（有理数）形式で数を格納するものもあれば、実数を全て表現できるとするものもある。
ってあるとおり、改訂BSDライセンスとかでリリースされたライブラリもいっぱいあるから
別にBoost.Bigintにこだわる必要はなさそうだよ。
だってさ。
277:デフォルトの名無しさん
10/04/22 18:54:53
絶対に完成しないだろ0x
278:デフォルトの名無しさん
10/04/22 19:40:49
完成しなくてもコンパイラが対応しつつあるから
コンパイラ間で齟齬さえなければどうでもいいよ
279:デフォルトの名無しさん
10/04/22 19:43:07
もうコンパイラベンダ間で勝手に仕様作っちゃおうぜ
C++標準化委員会とか正直どうだっていい集団じゃねぇか。
280:デフォルトの名無しさん
10/04/22 19:45:11
あうとー。
281:デフォルトの名無しさん
10/04/22 19:52:03
C++1X/CLI で。
282:279
10/04/22 21:23:26
>>281
ああ、なるほど、そうすると
C++/CLIのごとくになっちゃうのか。
それはいやだな。
283:デフォルトの名無しさん
10/04/23 00:22:44
W3C←→WHATNGみたいな事態には陥ってないかと。
Committeeはいい仕事しているので。
遅いという気持ちは分かるけど。
284:デフォルトの名無しさん
10/04/24 09:56:06
テンプレ見てたらこんなの出来たとしても使えるようにならんだろ
effective C++を何倍の厚さにすればいいんや
285:デフォルトの名無しさん
10/04/24 11:46:12
>>283
> Committeeはいい仕事しているので。
遅いんじゃなくて、確実にクソ仕様への道を歩んでいる気がする。
多少 後方互換性を壊す勇気を持ってほしかった。
286:デフォルトの名無しさん
10/04/24 12:32:11
互換性が無くなったら意味が無いというかC++じゃなくなるというか
ベンダにとって不利益になるのは確実
287:デフォルトの名無しさん
10/04/24 12:55:31
>>286
> ベンダにとって不利益になるのは確実
どうしてそう言い切れるのさ？
ベンダだってわざと互換性が無いようにすることだってあるだろうよ。
とはいえ
> 互換性が無くなったら意味が無いというかC++じゃなくなるというか
まあそれは分かる。
C/C++との極めて高い互換性を持っていなけC++0xなんて
存在意義が無いとは思う。
288:デフォルトの名無しさん
10/04/24 12:58:48
もう新しい言語にした方が良い気がするねえ
Cへのトランスレータにすれば互換性も確保出来るじゃん
289:デフォルトの名無しさん
10/04/24 13:07:53
互換性が無くなるとコンパイルが通らなくなる
コンパイルが通らない新しいコンパイラなんていらない
＝不利益になる
物を作るソフトとかは後方互換性がないと困るよ
290:デフォルトの名無しさん
10/04/24 13:15:44
互換性捨てた新しいのならJavaとかC#とかDとかいっぱいあるじゃないか。
291:287
10/04/24 13:27:51
>>289
なるほどねぇ。そーゆー考えもあるね。
でもわざと他社製品との互換性を無くして自社製品で囲い込むって
ことはやるんでね？
IEとか。
292:291
10/04/24 13:29:18
× IEとか。
○ IEとかMS Officeでもそんな感じじゃん。
293:デフォルトの名無しさん
10/04/24 13:53:59
例外やTMPをCへのトランスレータとして解決できる実装があれば見てみたい。
294:デフォルトの名無しさん
10/04/24 14:00:05
>>293
> 例外やTMPをCへのトランスレータとして解決できる実装があれば見てみたい。
むしろTMPは割と可能じゃないの？
コンパイル時に定まるんだから。
例外は相当厳しそうに思えるが。
295:デフォルトの名無しさん
10/04/24 14:01:39
つsetjmp.h
296:デフォルトの名無しさん
10/04/24 14:02:22
Comeau C++ って
C++ -> C言語
の変換器じゃなかったっけ？？
297:デフォルトの名無しさん
10/04/24 14:27:48
setjmp使ってCで例外を自作してるのなら見たことあるぞ
298:デフォルトの名無しさん
10/04/24 14:33:40
コードをいくらでもグロくしていいなら例外も普通にifとreturnで書けるだろ
299:デフォルトの名無しさん
10/04/24 15:03:54
それかなりオーバーヘッドかからないか？
300:デフォルトの名無しさん
10/04/24 15:52:02
だってそもそも例外だし。
301:デフォルトの名無しさん
10/04/24 23:49:04
チューリング完全な言語同士では計算可能性は同じだから
可能かどうかで論じると意味をなさない
どのように実現出来るか、という視点で論じるべき
longjmpでは途中でローカル変数のデストラクタが呼ばれない
Cレベルで実装するなら関数に間接層を設けてif、return、gotoで実装するのが妥当？
302:デフォルトの名無しさん
10/04/25 07:55:52
そもそもCにデストラクタはないから問題ないんでね。
303:デフォルトの名無しさん
10/04/25 12:55:12
関数呼び出すたびif例外ならgotoとかするわけ
304:デフォルトの名無しさん
10/04/25 14:17:22
>>302
いまの話題がC++からCへのトランスレータであるという俺の認識が間違ってないなら、
C++のデストラクタ相当の機能をCでどうやって書き下すかということを言ってるんだと思った
305:デフォルトの名無しさん
10/04/25 14:29:22
例外が起きた時の処理を関数の中に書いておいて
setjmpでそこに飛ぶ関数を作って
その関数ポインタをグローバルなスタックに関数に入るたび積んで行って
例外が起きたら実行してやればいいんじゃないの
306:デフォルトの名無しさん
10/04/25 14:32:12
gccは例外サポートがCPUにない場合にそんな感じの実装になってるね。
307:デフォルトの名無しさん
10/04/25 14:35:07
Cへのトランスレータ作成が例外で頓挫したって話は
ありゃデマだったのか？
308:デフォルトの名無しさん
10/04/25 14:38:19
おまいら、C++の設計と進化ぐらい読んでないのかよ
309:デフォルトの名無しさん
10/04/25 14:41:16
私女だけど読んでなかった
310:デフォルトの名無しさん
10/04/25 14:49:26
CPUによる例外サポートって何？
x86ならINT命令？
311:デフォルトの名無しさん
10/04/25 14:54:07
C++例外の実装にCPUの機能（CPU例外機能）なんか使わなくていいんだよ。
312:デフォルトの名無しさん
10/04/25 15:07:44
CPUの例外とC++の例外はそもそも意味が違うだろ
313:デフォルトの名無しさん
10/04/25 15:11:14
>>308
それ読む価値あった？
俺は別に歴史にはそんな興味ないし。
314:デフォルトの名無しさん
10/04/25 15:12:50
例外を禁止し、exit()で置き換えれば吉。
315:デフォルトの名無しさん
10/04/25 15:18:28
>>313
> それ読む価値あった？
物事の欠点を見つけた時に、
「こういう欠点があると自分にわかるのは、自分が利口であり、この物事に関わった奴らが馬鹿だからだ」
と考えて満たされちゃう浅はかな生き方してる人に読ませると、多少はそれを矯正できるかも。
316:313
10/04/25 15:29:02
>>315
なんだか深い事いってるのう
317:デフォルトの名無しさん
10/04/25 15:33:07
C++がこんなになっちゃったことへの禿の言い訳が延々書いてあるのかな
318:デフォルトの名無しさん
10/04/25 15:36:27
というような人に読ませるのも吉。
読んだら最後、それでも揶揄したかったら具体的な話をしなきゃ通らなくなるし、
そういう人は大抵そういう具体的なやり取りできないので、馬鹿を黙らせるのに使える。
319:デフォルトの名無しさん
10/04/25 16:37:06
難度の高い言語だから「こんなことになっちゃった」とか言っちゃうような子は
そう思っておけばいいんじゃないの
まあC++にも色々「どうしてこうなった」的な部分はあるんだけど
多分俺らがどうしてこうなったと思ってる部分とこの子らが言ってる部分は違うよな
320:デフォルトの名無しさん
10/04/25 17:13:03
D&Eを読むと、大抵の仕様はよく検討したらしいことが伺える
個人的には納得できる議論もあったし、
納得できない記述もあった
まあ少なくとも、単なる思いつきで仕様をいじることはないらしい
もうちょっと深慮がある
321:デフォルトの名無しさん
10/04/25 17:26:32
C++使ってて「なんでだお！？」って思う部分があるならD&Eは読む価値がある。
C++0xに関してはD&Eの記述からすると結構「？」な部分も多いけど。
322:デフォルトの名無しさん
10/04/25 18:57:22
typesafe enum が欲しい
323:デフォルトの名無しさん
10/04/25 19:16:14
0xの Strongly Typed Enums のことか？
324:デフォルトの名無しさん
10/04/25 20:23:12
>>321
禿自身がD&Eに相当するような論文を書いてるよね。C++0xについては。
規格が決まる前に書いているのが違う点だけど。
Concept checking - A mor complement to type checking
URLﾘﾝｸ(www.open-std.org)
Simplifying the use of concepts
URLﾘﾝｸ(www.open-std.org)
325:デフォルトの名無しさん
10/04/25 20:24:36
conceptは犠牲となったのだ・・・
326:デフォルトの名無しさん
10/04/25 21:00:40
>>324
＞A mor complement
愛の補数とはまた粋な
327:デフォルトの名無しさん
10/04/25 21:58:06
いやいや、きっと次のC++の版くらいには
復活するでしょconceptさん。
328:デフォルトの名無しさん
10/04/25 22:31:24
なんか面白い話題無い？
329:デフォルトの名無しさん
10/04/25 22:35:24
>>328
C++0xには今のところない。
330:デフォルトの名無しさん
10/04/25 23:07:36
＿_
, ‐' ´ ｀`‐、 ／￣:三}
. ／,. -─‐- ､. ヽ / ,.＝j
＿,.:_'＿＿＿＿＿_ヽ、 .! .／ _,ﾉ
`‐、{ へ 'ﾞ⌒ `!~ヽ. ! ／{. /
｀! しﾟ （ ﾟj `v‐冫 , '::::::::ヽ､/ 話題がないなら野球しようぜ！
. {.l '⌒ ﾞ 6',! / :::::::::::::::/ __
. 〈 < ´￣,ﾌ .ﾉｰ'_ , ‐'´::::::::::::::;/ （_ノ)‐-､
. ヽ.、 ` ‐", ‐´‐:ラ ':::::::::::::::: ;∠. ヽ_} ﾞヽ
,.r｀ "´ ／:::::::::::::::::::ィ´ ｀ゝ !、 /
/ / :::::::::::::::: ; '´ /´＼ / r'＼
. i ! ::::::::::::::／ 墨 | .!::::::::／ヽ､.._!ヽ. ヽ､
{ {:::::::::::;:ｲ / ∥ｉ:::::::/:::::::::::::/ ＼
. ヽ ヽ,.ｧ‐'´ /ヽ 二 ,/`ヽ、::::::::: ／
331:デフォルトの名無しさん
10/04/25 23:17:18
GCCの完全サポートがまぁ4.5.x～4.6ぐらいだとして
VC++のサポート完了はまたSP1待ちかね。
tr1の時も遅かったし…
332:デフォルトの名無しさん
10/04/25 23:57:52
VCなんかに期待してるのか？
やめとけ。無駄だ。
333:デフォルトの名無しさん
10/04/26 00:00:53
ＶＣ３０００のど飴のことです
334:デフォルトの名無しさん
10/04/26 00:15:21
2020年、cppxlang + LLVM が盤石
335:デフォルトの名無しさん
10/04/26 03:25:13
>>334
いや、2011年にはC++0x完璧で、
下手すりゃconceptも2012年くらいに実装されてると思う。
Clangは凄い勢いで成長してる。
コードも綺麗。
336:デフォルトの名無しさん
10/04/26 03:31:12
Cに変な拡張入れるのやめて欲しい…>Clang
337:デフォルトの名無しさん
10/04/26 03:37:45
しゃーねーだろ。gcc互換目指してるんだから。
338:デフォルトの名無しさん
10/04/26 03:42:48
gcc拡張ならともかくCにGCとかクロージャとか誰か止めなかったのか
せめて一言"ObjCでやれ"と言う奴はいなかったのか・・・
339:デフォルトの名無しさん
10/04/26 04:03:54
いや、ああいうのはLLVM的に必要だから。
LLVMとの絡みで実験的な実装をやるのが、
Clangの目的のひとつ。そしてLLVMの仕様に反映。
340:デフォルトの名無しさん
10/04/26 06:31:05
>>335
C++0xの現行版の仕様が確定するのが
2011年だぞ？
341:デフォルトの名無しさん
10/04/26 07:20:39
アホが来た
342:デフォルトの名無しさん
10/04/26 08:50:02
どうも。いつもお世話になってます。アホです。
343:デフォルトの名無しさん
10/04/26 08:59:27
なんでこれで笑ってしまったんだろう・・ｗｗ
344:デフォルトの名無しさん
10/04/26 09:12:19
>>340
実装状況調べてないだろw
345:デフォルトの名無しさん
10/04/26 10:57:21
>>344
ぜんっぜん調べてねぇけど、ドラフトは読んでるよ。
この状況では確定するのはやっぱり2011年だろ？
346:デフォルトの名無しさん
10/04/26 11:07:29
FCDまで来たから、機能が増えたり改められたりはもう多分ない。
何か問題があったら引かれるだけ。conceptのように。
あとはrvalueみたいに表現の調整ぐらい。
347:デフォルトの名無しさん
10/04/26 11:26:16
>>346
このFCDのまま行くのかね？
あと1回くらいFCDを出し直してそれから進むと踏んでいるんだけど。
その辺を含めて2011年と見ている。
348:デフォルトの名無しさん
10/04/26 12:51:11
今年の夏からFCDという制度そのものがなくなってしまうので、多分このまま
FCD→FDISと行くんじゃないかなあ。FDISは事実上の信任投票で
技術的変更は不可だから、FCD→FDISの間で「FDIS投票がこけないような修正」を
して終わりだと思う。
349:デフォルトの名無しさん
10/04/26 12:54:20
ああでもTarget publication date: 2012-02-28なんて話題もあったっけ。
んー、もうあとは引き算だけだと思うんだけどねえ。
350:デフォルトの名無しさん
10/04/26 19:45:01
noexceptは簡単には済まないと思うけどねえ
ムーブセマンティクスと例外の絡みで出てきた話だから引けばいいってもんでもないし
351:デフォルトの名無しさん
10/04/26 21:12:42
noexceptは引き算されそうなにおいがぷんぷんするな。
352:340
10/04/26 21:13:25
>>341-344
んで、無知なあなた方は、なんか俺に謝る事あるんじゃないの？
353:デフォルトの名無しさん
10/04/26 21:16:43
うわっ ｷﾒｪ＾＾
354:デフォルトの名無しさん
10/04/26 21:19:42
既に実装されているものもあるのにねえ。
355:デフォルトの名無しさん
10/04/26 21:21:18
引き算だけならいいけど、それが形を変えて戻ってきたら
実装済みのコンパイラ涙目
356:デフォルトの名無しさん
10/04/26 21:24:56
掛け算されたりして
アッー！
357:デフォルトの名無しさん
10/04/26 21:28:56
>>353-354
で？
俺は実装の話なんて一言もしていないが。
> C++0xの現行版の仕様が確定するのが
> 2011年だぞ？
としか言ってないけど。
なんか正当な反論ができるならしてみろよ？無知が。
358:デフォルトの名無しさん
10/04/26 21:48:30
どうも。ご迷惑おかけしています。アホです。
359:デフォルトの名無しさん
10/04/26 22:04:10
あんたが正しいか正しくないかじゃなくて、
こんな２ちゃんごときで謝れとか言い出すあんたの器量の狭さがキモいんですよ＾＾
360:デフォルトの名無しさん
10/04/26 22:08:05
>>357
pgr
361:デフォルトの名無しさん
10/04/26 22:33:47
はいはいごめんやさいごめんやさい
362:340
10/04/26 22:47:55
>>358-361
んで結局お前らは全員が知ったかぶりだったってことでいいんだな？
この件を恥じ入り、以後知ったかぶりを改めるように！
363:デフォルトの名無しさん
10/04/26 23:19:11
はーい^^
364:デフォルトの名無しさん
10/04/26 23:24:49
おまえら明日VS2010でたら色々遊んでレポートしなさい
365:デフォルトの名無しさん
10/04/27 15:47:12
本の虫のブログで初めて知った。
deleted定義
URLﾘﾝｸ(cpplover.blogspot.com)
これすげー便利だな。
366:デフォルトの名無しさん
10/04/27 17:14:01
>>365
予約語deleteの再利用か。
exportは仕事 首になったからまさに完全ニートになってるけど、
予約語としては生き残っているらしいから、
なんか有効利用してあげられないかな？
367:デフォルトの名無しさん
10/04/27 17:28:30
concurrency/atomics 周りが GCC 4.6, 4.7 あたりで
完全にサポートされるようになるとはとても思えない……
368:デフォルトの名無しさん
10/04/27 20:14:10
本の虫がそこに気付いてなかったとは…
template<typename T> operator T() = delete;なんて好きそうなのに
369:デフォルトの名無しさん
10/04/27 20:16:31
俺もメンバ関数にしか使えないのかと思ってた
370:デフォルトの名無しさん
10/04/27 20:17:33
ほほうそれは Tの修飾をどの程度含んで殺してしまうのかね？
371:デフォルトの名無しさん
10/04/27 20:22:25
>>367
gccはその辺は一番遅いでしょ。
昔みたいにx86専用フォークあれば別だけど。
372:デフォルトの名無しさん
10/04/27 21:31:40
deleteに続いて併せて使われる予定のdefaultはなんだか微妙な感じだな。
純粋仮想関数よりは見た目はいいが。
373:デフォルトの名無しさん
10/04/27 21:51:32
=defaultも大事だぞ
struct Point{
int x,y;
Point() = default;
Point(int x, int y) : x(x), y(y){}
};
これが出来るだけで凄い価値がある
374:デフォルトの名無しさん
10/04/27 21:55:43
Point() {} と何が違うんだっけ
inline強制じゃないんだっけ？
375:デフォルトの名無しさん
10/04/27 22:20:02
Point(){}はコンパイラ生成のデフォルトコンストラクタじゃない＝PointはPODじゃない
376:デフォルトの名無しさん
10/04/27 22:23:23
コンストラクタつきのPodが可能になるのか
377:デフォルトの名無しさん
10/04/27 22:54:25
Podってキャピタライズされると地味に違和感
378:デフォルトの名無しさん
10/04/27 23:02:40
デフォルトコンストラクタだけデフォルトでも
他が違えば意味ないんじゃないの？ ＞POD
379:デフォルトの名無しさん
10/04/27 23:09:53
コピコン、operator=、デストラクタは書かなけりゃデフォルトだからいいの
デフォルトコンストラクタだけは自分でなんかコンストラクタ書くと潰されるから
明示的に指定が必要
380:デフォルトの名無しさん
10/04/27 23:40:17
だから Point() {} と何が（ry
デフォルトのコピコンやoperator=をprivateにしたい時に使うのは便利そうだけど
381:デフォルトの名無しさん
10/04/27 23:56:42
URLﾘﾝｸ(d.hatena.ne.jp)
URLﾘﾝｸ(ja.wikipedia.org)
C++0xではPODの定義が変わって
>>373の構造体はPODになるとかならないとか
382:デフォルトの名無しさん
10/04/27 23:56:55
新しい関数宣言やラムダって当初のまんまなの？
383:デフォルトの名無しさん
10/04/27 23:59:04
>>381
なーるほど
それだと重要だな
384:デフォルトの名無しさん
10/04/27 23:59:55
そういや、デフォルトのコピコンやoperator=を殺したければdeleteすりゃいいんだった
385:デフォルトの名無しさん
10/04/28 00:07:36
>>382
unified function syntaxはボツになりました…
386:デフォルトの名無しさん
10/04/28 00:11:31
unified function syntaxはクソだったからな。
不細工すぎるだろ
387:デフォルトの名無しさん
10/04/28 00:12:29
やっぱりあれはボツだよなあw
安心した
388:デフォルトの名無しさん
10/04/28 00:13:43
>380
default constructor が trivial か non-trivial かの違いになります．
で，この違いがどうなるかというと結構大量にあるっぽいので
誰か親切な人まとめてください．
389:デフォルトの名無しさん
10/04/28 00:18:50
>>387
うむ。
いくら何でもなぁ。
390:デフォルトの名無しさん
10/04/28 00:23:10
POD って C++0x でそれほど重要な概念になってます？
どちらかというと， POD という用語の従来における定義の個々の構成要件だった
「各 special member function が trivialかどうか」や
"standard-layout type" といった概念が，それぞれ独立して
重要な仕様上の概念として活躍しているような？
391:デフォルトの名無しさん
10/04/28 00:26:34
そういやドラフトでPOD関連全般にもの凄い修正入ってた気がするわ
多すぎて目を通してなかったけど
392:デフォルトの名無しさん
10/04/28 00:28:05
最後にまともにC++に触ったの10年くらい前で、既にJavaに移行してしまった者なんだが、
お前らが何を言ってるのかさっぱり分からん。
393:デフォルトの名無しさん
10/04/28 00:32:11
多分ずっとC++使ってる人でも分からないから問題ない
394:デフォルトの名無しさん
10/04/28 00:33:21
PODの重要性は今までと一切変わらんよ
CのAPIに渡したりバイトの塊としてストリームに流せたりすることを保証する枠組みは絶対に必要
仕様上の概念としてはtrivialとstandard-layoutに整理されて文言の登場頻度は減ったけどね
395:デフォルトの名無しさん
10/04/28 00:35:53
いったいなんなんだC++って。
396:390
10/04/28 00:43:19
>394
＞CのAPIに渡したり～
この部分は完全に同意していて， >390 は単に
＞文言の登場頻度は減った
んじゃないの？ っていうのが言いたかっただけです．すいません．
397:デフォルトの名無しさん
10/04/28 03:23:06
どうでもいいじゃない、そんなこと。
PODの概念が具体的な形で整理されたことが大切。
より重要な概念になったかどうかとか、登場回数が減ったとかどうでもいい。
重要かどうかってのは評価に属することなんで、考え方次第。
C++は、PODにしても>>367にしても、
高級アセンブラとしての役割というか、
低レベルな部分での仕様を追求するのが面白いね。
398:デフォルトの名無しさん
10/04/28 12:12:53
>>397
さすが移植用アセンブラたるC言語の直系の子孫。
いつまでも変態記法と低レベル作業を忘れないでね。
399:デフォルトの名無しさん
10/04/28 13:24:24
変態な君が好き。
400:デフォルトの名無しさん
10/04/28 15:56:12
変態紳士な貴方も、チェリーボーイな君も、ウィザードハッカーな彼も。
みんな大好きC++。
401:デフォルトの名無しさん
10/04/28 16:03:50
むしろそういうヤツしか大好きじゃないんじゃないかなC++
402:デフォルトの名無しさん
10/04/28 18:45:05
俺ってウィザードハッカーだったのか
403:デフォルトの名無しさん
10/04/28 19:11:38
C++はメジャーな言語です。
メジャーな言語を使えるプログラマーは変態ではありません。技術者です。
404:デフォルトの名無しさん
10/04/28 23:33:57
高級アセンブラって褒め言葉にしか聞こえない。
405:デフォルトの名無しさん
10/04/29 02:35:09
C99と違ってMSも実装に前向きみたいだけど
0xってどれだけ普及するだろうか
406:デフォルトの名無しさん
10/04/29 02:44:43
正直「C++で開発してます」と言ってる業界のtemplateの普及度すら怪しい
407:デフォルトの名無しさん
10/04/29 02:46:29
凄い的確な返しだ
408:デフォルトの名無しさん
10/04/29 03:04:45
>>406
templateは保守性が低いから使うな！ってよく言われるよ。
lambdaなんぞ入ったらどうなることやら…。
409:デフォルトの名無しさん
10/04/29 03:15:55
保守性が低い、の意味が、
俺らが読めない、だからなあ
410:デフォルトの名無しさん
10/04/29 08:54:11
ある意味真理
411:デフォルトの名無しさん
10/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型では初期化されていないことを意味すると思うのですが。
これに関係していそうなので↓こんなものを見つけましたが
URLﾘﾝｸ(www.open-std.org)
上の文はまだ修正される可能性があるのでしょうか？
412:デフォルトの名無しさん
10/04/29 09:24:11
分かる人間がいなきゃ企業としては保守性低いわなぁｗ
概念的にはそんなに難しいものじゃないけど
ヘッダに実装書くことによる細かいバッドノウハウはちょっとだるい
413:デフォルトの名無しさん
10/04/29 09:27:05
>>411
POD型のデフォルトコンストラクタは0クリアじゃないの?
414:デフォルトの名無しさん
10/04/29 10:45:16
>413
thanks.
default constructed とは value-initialized(8.5) と同じ意味なんですね。
415:デフォルトの名無しさん
10/04/29 10:48:13
古いVC++だと初期化されなかったような気がする
所詮規格は規格であって実装で無視されたら意味ないしなあ
416:デフォルトの名無しさん
10/04/29 10:48:55
いや、あれはvectorじゃなかったか・・・？
記憶が曖昧だ・・・
違うかもしれない
417:デフォルトの名無しさん
10/04/29 12:13:29
VC10express使った人いる？
どうかな？対応具合は？
418:デフォルトの名無しさん
10/04/29 13:28:25
XP SP2には対応していなかった
419:デフォルトの名無しさん
10/04/29 18:31:41
誰もそんなこと聞いてねぇｗ
420:デフォルトの名無しさん
10/04/29 19:36:54
ワロタｗ
でも地味に良い情報だったｗ
421:デフォルトの名無しさん
10/04/29 21:10:51
対応してないのか、単に保証してないか、どっちなんだろう
単にSP2自体サポート終了してるから対象から外しただけな気もするが
422:デフォルトの名無しさん
10/04/29 22:23:01
A がムーブコンストラクタを持つ状態で
A foo() { return A(); }
を実行した場合、文法上、戻り値返す際に動くのは
コピーコンストラクタとムーブコンストラクタのどっち？
（実際にはどちらにしろ戻り値最適化されるだろうけど、
仮に文法上コピーコンストラクタが実行されるなら、
コピーコンストラクタを private にした時（あるいは delete した時）に
エラーになるという違いがある）
とりあえずVC++2010はコピーコンストラクタが動こうとするみたいだけど。
423:デフォルトの名無しさん
10/04/29 22:25:45
>>415
> 古いVC++だと
古いVC++なんて、それを言って良いならいくらでもそんなことはあるだろうよ。
424:デフォルトの名無しさん
10/04/29 22:34:13
>>422
それだけだと右辺値参照する側がいないんじゃないか。
425:デフォルトの名無しさん
10/04/29 22:40:03
受け取るやつがいるいないは関係なくない？
どこから呼ばれるかコンパイル単位には分からないわけだし
426:デフォルトの名無しさん
10/04/29 22:42:07
>>422
ムーブコンストラクタがあればそっちで、なければコピーコンストラクタ、でしょ。
そうじゃないと困りそう。
427:デフォルトの名無しさん
10/04/29 22:48:57
>>424
戻り値最適化がないなら、
return に書いた式から、関数の戻り値へとコピーかムーブが走ると期待できる
>>426
じゃあVC++2010の挙動がおかしい、と
publicなムーブコンストラクタとprivateなコピーコンストラクタを定義したら、
コピーコンストラクタが使えないよというエラーになるから
428:デフォルトの名無しさん
10/04/29 22:55:37
もう１つ、
A a(A(1));
A a(foo());
でも同じ状況でVC++2010はエラーになる。
ただし、後者ではコピーコンストラクタを有効にして実際に実行してみると
ムーブコンストラクタしか動かない。
（前者は最適化されてコピーやムーブ自体が実行されない）
429:デフォルトの名無しさん
10/04/29 22:58:37
VC++2010、地味にヤバそうな予感
まだゴリゴリ書かない方がいいのか・・・ って、何か問題起きたら 2008に持ってけばいいのかｗ
430:デフォルトの名無しさん
10/04/29 23:00:14
いや、すまん
>>428 は後者も最適化されてコピーもムーブも動かないわ
431:デフォルトの名無しさん
10/04/29 23:02:53
ムーブコンストラクタはそんなに神経質に使うものじゃなくないか？適用されたら儲け程度に考えればいいんじゃね。
432:デフォルトの名無しさん
10/04/29 23:09:23
void hoge(A&& a) {
a.piyo(); // piyoは非constメンバ関数
A b(a); // ムーブ？ コピー？
b.piyo();
}
hoge(A());
これでコピーコンストラクタが動いたんだけど
ひょっとしてムーブコンストラクタの考え方、俺間違ってる？
a.piyo(); が実行できたという点では
右辺値参照万歳ではあるんだけど
433:デフォルトの名無しさん
10/04/29 23:12:59
>>432
ムーブしたかったら A b(std::move(a)) じゃないか？
434:デフォルトの名無しさん
10/04/29 23:14:57
>>432
そこで勝手にmoveしちゃったらその後のaはどうなるんだよ
435:デフォルトの名無しさん
10/04/29 23:14:57
>>433
おお、そうなんだ
そうしたらムーブコンストラクタが呼ばれたわ
ありがとう
436:デフォルトの名無しさん
10/04/29 23:15:59
>>434
あとは野となれ山となれ
437:デフォルトの名無しさん
10/04/29 23:22:26
というか、>>422 のエラー発生状況の説明が
「'A' から 'A &&' への変換時」ってなってるな
どうもムーブコンストラクタを呼ぼうとはしているみたいだ
でも、なぜかコピーコンストラクタがアクセス可能じゃないとダメ、と
'A' から 'A &&' への変換に
なぜコピーコンストラクタへのアクセス可能性が要求されるのだろう？
438:デフォルトの名無しさん
10/04/29 23:24:40
名前付きの値は（左辺値参照でも右辺値参照でも）左辺値として扱われる。
>>432 の例でいうとaをムーブコンストラクタに渡すには
std::moveの返値（無名の右辺値参照）にしなければいけないわけだ。
なるほど。
439:デフォルトの名無しさん
10/04/29 23:27:24
>>438
なるほど
ムーブコンストラクタがあっても、
左辺値でコンストラクとしようとする時には
勝手に右辺値参照になってはくれないのね
確かに安全のためには必要そうな仕様だ
440:デフォルトの名無しさん
10/04/29 23:40:37
ひょっとして、ムーブ可能にしたければ
コピーも可能じゃないとだめというのが仕様だとか？
でも、MoveConstructible requirements にそういう事は書いてないし・・・
441:デフォルトの名無しさん
10/04/30 02:11:51
>427
＞publicなムーブコンストラクタとprivateなコピーコンストラクタを定義したら、
＞コピーコンストラクタが使えないよというエラーになるから
再現しないっぽいのでとりあえずコード全体をさらしてほすぃ……
442:デフォルトの名無しさん
10/04/30 02:18:31
422==432で書いてたコードand/or考えが間違ってたんだろう
443:デフォルトの名無しさん
10/04/30 03:01:44
不思議な事に、こっちでも新しく書いたら再現しない
条件があるのかも
444:デフォルトの名無しさん
10/04/30 03:06:11
めっちゃアンドゥして昔のコードに戻したけどやはり再現しない・・・
一体なんなんだ
445:デフォルトの名無しさん
10/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:デフォルトの名無しさん
10/04/30 04:13:09
new autoとかありだということに驚いた
447:デフォルトの名無しさん
10/04/30 06:30:36
最後はdelete[]だろ
448:デフォルトの名無しさん
10/04/30 07:18:27
>>445
どのコンパイラくらい書いてくれ。
449:デフォルトの名無しさん
10/04/30 08:18:51
死ぬってのは実装の問題ってこと？
450:デフォルトの名無しさん
10/04/30 08:35:12
VC++2010で試したら確かに実行時エラーで死んだ。
誰かGCCで試してみてほしい。
451:デフォルトの名無しさん
10/04/30 08:51:30
なんだこのスレタイと全然関係無い話題なのに
妙に価値のある内容は。
もっとやれ
452:デフォルトの名無しさん
10/04/30 09:50:00
>>445
g++-4.5 (Debian 4.5.0-2) 4.5.1 20100419 (prerelease)
だと死なない（そりゃそうだ）
453:デフォルトの名無しさん
10/04/30 10:47:13
>>447
ポインタをnewしてるだけだからdeleteで問題ない
454:デフォルトの名無しさん
10/04/30 11:39:19
new auto("hoge") は const char**
455:デフォルトの名無しさん
10/04/30 12:45:29
deleteかdelete[]かを判断できないのだからnew auto(ここの部分);で、動的にdeleteかdelete[]かを選べるshared_ptrみたいな動的削除子が組み込みで欲しいな。
456:デフォルトの名無しさん
10/04/30 12:47:09
expression
／ ＼
glvalue rvalue
／ ＼ ／ ＼
lvalue xvalue prvalue
Figure 1 -- Expression category taxonomy
何か笑ってしまった
複雑だなあ
457:デフォルトの名無しさん
10/04/30 12:48:04
>>455
new auto で確保したものは常に delete
配列 new を初期化パラメータ付きで行うのは不可能だから
458:デフォルトの名無しさん
10/04/30 12:51:23
そうだった。つまりこれはnew autoしたのをdeleteする処理系が悪いということか。
459:デフォルトの名無しさん
10/04/30 12:55:10
new autoは実はGCが働くんだよ！
だったらいいんだが
autoってそんな意味じゃねー
460:デフォルトの名無しさん
10/04/30 12:57:51
newしてるのにポインタじゃなくてスマポが返るんですね分かります
461:デフォルトの名無しさん
10/04/30 13:07:33
>>456
仮想継承にしなくちゃならないなｗ
462:デフォルトの名無しさん
10/04/30 13:12:08
>>456
シンプルやん。
対称だと頭に入りやすい。
463:デフォルトの名無しさん
10/04/30 13:30:37
expression
／ ＼
lvalue rvalue
／ ＼ ／ ＼
plvalue xvalue prvalue
これなら対称なんだけど
464:デフォルトの名無しさん
10/04/30 13:32:57
>>463
機能まで対称だったらわざわざ仮想継承構造にする必要ないけどな
465:デフォルトの名無しさん
10/04/30 13:35:43
lvalue &
rvalue &&
prvalue &&&
になりそうな予感
466:デフォルトの名無しさん
10/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:デフォルトの名無しさん
10/04/30 14:28:27
ラムダ式はreturnできないし（template<class L> L hoge(L lambda) { return lambda; } みたいなのは例外で可能だが）、
関数ポインタに渡せないんだな
前者は戻り値の型が書けないからで、
後者は関数呼び出しがクロージャ型の非staticメンバ関数だからだな
どちらも仕方が無いけど、微妙に不便
まあ後者は、クロージャ型の非staticメンバ変数に
operator() を自インスタンスを使って call するコードを
持たせる事で実現できるとは思うのだが、
メモリの実行権限とか考えると微妙だわなあ
468:デフォルトの名無しさん
10/04/30 15:15:49
>>465
> lvalue &
> rvalue &&
> prvalue &&&
何気に分かりやす・・・くねぇな
469:デフォルトの名無しさん
10/04/30 17:34:03
って、規格上はラムダ式は関数ポインタに変換できるのか……
今年３月の話みたいだから対応して無いのは当然だけど
470:デフォルトの名無しさん
10/04/30 17:38:11
関数ポインタよりもresult_typeが欲しいよ。
471:デフォルトの名無しさん
10/04/30 18:09:13
std::functionにキャストすれば使えるんじゃないの＞result_type
472:デフォルトの名無しさん
10/04/30 19:06:02
>>471
なんと、その手があったのか。改めてfunctionはすごいな。
ラムダ式をboost::lambdaでラップしようかとか悩んでた。
473:デフォルトの名無しさん
10/04/30 21:11:54
swap技法が適用されるデフォルトムーブ演算子operator=(&&)とかできないかなあ。
474:デフォルトの名無しさん
10/04/30 21:40:51
デフォルトムーブ代入演算子なら最新のドラフトに入ったよ
475:デフォルトの名無しさん
10/04/30 23:09:11
戻り値の型を auto にして trailing return type を省略し
return する値の型を全て同じにすれば
戻り値の型を自動的に類推してくれる、
という仕様は検討された事ないのかな
それがあれば関数をカリー化して返せるんだが
auto add(int n) {
return [=](int x) { return x + n; };
}
476:デフォルトの名無しさん
10/04/30 23:14:48
>>474
おおっとそれはすごい。VC10にいつかはサポートされるかな。
現状のVC10はどこまでサポートされてるのかさっぱり分らない。SPが出るたびに調整かｗ
477:デフォルトの名無しさん
10/04/30 23:29:33
>>475
auto add = [](int n) {
return [=](int x) { return x + n; };
};
で我慢しろ
478:デフォルトの名無しさん
10/04/30 23:37:39
>>476
URLﾘﾝｸ(blogs.msdn.com)
URLﾘﾝｸ(wiki.apache.org)
479:デフォルトの名無しさん
10/05/01 00:02:33
Unified Function Syntaxも戻り値の型推測入れればいいのに
480:デフォルトの名無しさん
10/05/01 00:15:10
>>475
宣言だけの場合は？
481:デフォルトの名無しさん
10/05/01 01:14:15
>>480
inline や template と同様、ヘッダにしか書けない
ただし、static を明示的につけない限り、リンク時に実体は１つにまとめられる
宣言だけ書くことはできるが、同じ翻訳単位に定義が必要
みたいな感じで
482:デフォルトの名無しさん
10/05/01 01:15:40
×ヘッダにしか書けない
○複数の翻訳単位から利用するにはヘッダにしか書けない
483:デフォルトの名無しさん
10/05/01 01:18:30
まあ、同じ定義を自分で複数の翻訳単位に書いてもいいんだけど
それはそれこれはこれということで
484:デフォルトの名無しさん
10/05/01 01:38:18
>>478
ありがとう。対応状況が一目で分かって助かります。
485:デフォルトの名無しさん
10/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:デフォルトの名無しさん
10/05/01 11:30:56
どういう使い方するかによるんじゃない
普通は一方をもう一方の情報を使って変更して
変更したオブジェクトを返すという形にすると思うけど
487:デフォルトの名無しさん
10/05/01 13:19:54
VC10で is_pod<void>::value がtrueになるのは相変わらずか。
488:デフォルトの名無しさん
10/05/01 16:03:18
>>485
なるほど、通常は片方だけですむってことなのか。
489:デフォルトの名無しさん
10/05/02 04:07:58
ラムダ面白いな。
てきとーにVC10ee触ってるんだが、ラムダって制限つきローカル関数のように使えるな。
さらに便利かも。
490:デフォルトの名無しさん
10/05/02 08:57:41
確かにfor_eachなどに直接渡すだけじゃなく、ローカル関数として使えるね
これでいちいち関数内に構造体作る必要がなくなったわ
しかもメンバにも直接アクセスできるし
491:デフォルトの名無しさん
10/05/02 09:48:03
ラムダ関数はresult_typeを定義してくれてたら完璧なんだけど
492:デフォルトの名無しさん
10/05/02 12:15:28
その辺はconceptで整備するつもりだったんだろうけど…
function_traitsを定義するんで凌ぐのかな。
493:デフォルトの名無しさん
10/05/02 15:36:14
>>490
メンバにもアクセスできるの？！
ローカルクラスとかわんないと思いこんでた
494:デフォルトの名無しさん
10/05/02 15:39:58
環境いじれないのはlambda式じゃないぜ…
495:デフォルトの名無しさん
10/05/02 16:43:10
thisをキャプチャすればメンバに触れる
どうせ[=]か[&]にするだろうから
自動的にキャプチャされるだろうが
496:デフォルトの名無しさん
10/05/02 19:02:42
むしろthisがキャプチャされない場合って．．．？
497:デフォルトの名無しさん
10/05/02 19:36:34
[]にしたい時だってある
498:デフォルトの名無しさん
10/05/02 20:48:36
引数しか使わない
そんな気分の時があります
499:デフォルトの名無しさん
10/05/02 20:59:31
キャプチャってなんだーー！！！
ああ、0xのLambda式か。
500:デフォルトの名無しさん
10/05/03 00:01:17
autoって本当に便利ですね。てかテンプレートには必須だよ。
501:デフォルトの名無しさん
10/05/03 00:08:41
キャプチャしない場合でも、[&][=]って書いてもペナルティはない？
紛らわしいからやめろと言われればその通りなんだが、コンパイラがどういうコードを吐くのか気になる
502:デフォルトの名無しさん
10/05/03 00:15:16
最適化すりゃ消える
503:デフォルトの名無しさん
10/05/03 00:15:56
むしろ追加でコード生成されんの？
504:デフォルトの名無しさん
10/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:デフォルトの名無しさん
10/05/03 00:29:10
すまん，キャプチャの意味がわかってなかった．．．
506:デフォルトの名無しさん
10/05/03 00:43:19
>>504
おばか
507:デフォルトの名無しさん
10/05/03 00:49:10
省略の意味がちげえｗ
508:デフォルトの名無しさん
10/05/03 05:56:52
>>502
コピコンのあるようなものがいらっしゃると消えてくれないかも
509:デフォルトの名無しさん
10/05/03 09:42:06
[](int x){return x;}
510:デフォルトの名無しさん
10/05/03 10:45:04
->int とかの trailing-return-type って普通の関数定義にも使えるんだな
用途がよくわからんが
511:デフォルトの名無しさん
10/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:デフォルトの名無しさん
10/05/03 11:06:26
>>507 kwsk
513:デフォルトの名無しさん
10/05/03 12:50:15
>>510
template <typename T>
auto foo(T a, T b) -> decltype(a + b) { return a + b; }
とかできるよね、という話らしいよ
514:デフォルトの名無しさん
10/05/03 12:54:00
あとは auto foo() -> int(*)(); とか、関数ポインタや配列ポインタを返しやすいとか
515:デフォルトの名無しさん
10/05/03 12:57:20
そういやlambdaはDLLにexportできるようになるんかな？
516:デフォルトの名無しさん
10/05/03 12:58:54
exportするなら普通の関数でええやんという話
517:デフォルトの名無しさん
10/05/03 12:59:27
>>509 あ、そうか。そうだような。俺が馬鹿でした。
でもさすがにC#のように引数の型を省略 auto z3=[](x){return x*2;}; は無理？とおもったけど。
auto z4=boost::lamabda::_1*2; はOKなのね。boost::lambda恐るべし。
518:デフォルトの名無しさん
10/05/03 13:02:53
C#の型推論はデリゲート側と型を一致させるというしくみだから
autoで受けるC++0xではまあ使えないわなあ
519:デフォルトの名無しさん
10/05/03 13:10:52
>>513-514
なるほど、納得。
520:デフォルトの名無しさん
10/05/03 13:13:25
どんどん初心者お断りで複雑怪奇な仕様になっていってる気がする…
521:デフォルトの名無しさん
10/05/03 13:14:46
なにをいまさら
522:デフォルトの名無しさん
10/05/03 13:15:43
カンタンカンタン
523:デフォルトの名無しさん
10/05/03 14:41:40
>511
u'\u0905' wchar16_t だから「実行時キャラクターセット」は使われません。
どんな環境でも UTF-16 エンコードが使われます。
0x0905 と同じ表現を持つ値となります。
524:デフォルトの名無しさん
10/05/03 16:44:54
>>523
実行文字集合に無い文字は、翻訳段階5でいったん文字化けさせろって書いてない？
「文字(列)リテラル中のユニバーサルキャラクター名は、実行文字集合中の対応物に置き換える」
リテラル中の文字が、ユニコードでどの値を持つか評価されるのって、その後だよね？
525:デフォルトの名無しさん
10/05/03 20:40:41
>>520
分かる部分だけ使ってりゃいいって
526:デフォルトの名無しさん
10/05/03 21:01:41
コンセプトが入ってればエラーメッセージが(以下略
527:デフォルトの名無しさん
10/05/04 00:06:10
C++0xはよく考えられた改良だと思うけど
互換性のために殆どが「追加」になっちゃうんだよね
便利でシンプルで完全に動作するC++のサブセットって定義できんもんだろうか
528:デフォルトの名無しさん
10/05/04 00:08:11
互換性を無視したとして、いらない機能は何だろう？
つ可変引数
529:デフォルトの名無しさん
10/05/04 00:11:23
それは要るだろw
筆頭は0＝ヌルポインタだな。
530:デフォルトの名無しさん
10/05/04 00:13:03
古い(というか従来の)関数宣言
struct か class のどちらか
古い(というか従来の) enum
531:デフォルトの名無しさん
10/05/04 00:17:07
typedef
532:デフォルトの名無しさん
10/05/04 00:17:40
型変換演算子の廃止
533:デフォルトの名無しさん
10/05/04 00:18:19
コピコンとデフォコンの特殊ルール
534:デフォルトの名無しさん
10/05/04 00:19:06
unsigned全部
535:527
10/05/04 00:29:42
>>527 は新しい言語を作るんじゃなくてサブセットを定義して学習のコスト削減を意図してました
仕様変更ではなくコーディングルールみたいなもん
536:デフォルトの名無しさん
10/05/04 00:32:07
>>529
printfみたいに引数の検査ができな可変引数よりも、
cout<<a<<b; とか boost::format("%d %d")%a&b;
とかてC++の機能で代用できるもので可変引数は廃止でいいんじゃないか？
hoge a(); が関数のプロトタイプになるのはなくしていいとおもう。
537:デフォルトの名無しさん
10/05/04 00:34:21
boost::format("%d %d")%a%b; だった。
538:デフォルトの名無しさん
10/05/04 00:43:08
これだろ…
std::vector<bool>
539:デフォルトの名無しさん
10/05/04 00:48:27
1パスコンパイル
540:デフォルトの名無しさん
10/05/04 00:49:54
bind1st , bind2nd, fun_ptr
541:デフォルトの名無しさん
10/05/04 00:51:57
>>536
printfを例に出すとは素質悪いな
542:デフォルトの名無しさん
10/05/04 00:56:10
禿の新しいC++本(Programming: Principles and Practice Using C++)で
10行程度しか触れられていない
valarray
543:デフォルトの名無しさん
10/05/04 00:56:45
互換性を無視していいならいらない機能の筆頭は、暗黙の変換
バグの元
544:デフォルトの名無しさん
10/05/04 00:59:15
アップキャストがバグの元っていったい
545:デフォルトの名無しさん
10/05/04 01:00:58
>>544
non-explicitなコンストラクタとかoperator T()のことじゃない？
546:デフォルトの名無しさん
10/05/04 01:02:40
整数の暗黙の拡張とか
547:デフォルトの名無しさん
10/05/04 01:10:06
暗黙の変換というか標準変換の一部と言うべきなのか
要するに数値型間の暗黙の変換
548:デフォルトの名無しさん
10/05/04 01:57:08
charをintegral typeから外して、integral type最小のbyteを設ける。
549:デフォルトの名無しさん
10/05/04 01:59:30
暗黙の型変換なくす人、
xがintの時、式 x * 3.14 の型はintでOK?
550:デフォルトの名無しさん
10/05/04 02:00:56
コンパイルエラー
551:デフォルトの名無しさん
10/05/04 02:02:56
>>549
#pragma yutori
ならばOK
552:デフォルトの名無しさん
10/05/04 02:05:09
整数の拡張って何がまずいん？
553:デフォルトの名無しさん
10/05/04 02:10:00
unsigned int x = -1;
がコンパイルできちゃう
554:デフォルトの名無しさん
10/05/04 02:21:52
static_cast使いまくりで可読性が悪くなりそう
555:デフォルトの名無しさん
10/05/04 02:28:01
>>491
result_ofが使えればいいよ。
556:デフォルトの名無しさん
10/05/04 02:29:28
>>553
警告が出るからいいんじゃね？
557:デフォルトの名無しさん
10/05/04 02:32:38
数値の暗黙の拡張にこれほど疑問や反論がでるのは予想外だった
正直、ほとんどの人に共通の認識だと思ってた
558:デフォルトの名無しさん
10/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:デフォルトの名無しさん
10/05/04 06:01:55
-Wsign-conversion で警告がでるな
560:デフォルトの名無しさん
10/05/04 11:10:01
-Wextra
561:デフォルトの名無しさん
10/05/04 11:48:53
-Warata
562:デフォルトの名無しさん
10/05/04 11:53:26
-Wwwwwwww
563:デフォルトの名無しさん
10/05/04 12:09:41
多少ずれるが
unsigned変数の小なり０比較はエラーにすべき
564:デフォルトの名無しさん
10/05/04 12:52:01
>>563
警告出して最適化してくれれば十分だと思う。
テンプレート使ってるとsignedとunsinged両方使えるようにするとき役に立つ。
警告なら必要に応じて抑制できるけど、エラーだとsignedとunsingedで分岐するテンプレートを書く必要が出てきて面倒。
565:デフォルトの名無しさん
10/05/04 12:54:21
最適化というのは，勝手にsigned変数に変更するということ？
それとも比較元を＋１して小なり1比較ってこと？
566:デフォルトの名無しさん
10/05/04 12:55:00
いや、常にfalse判定じゃないかと
567:デフォルトの名無しさん
10/05/04 13:01:05
うんfalse判定でifのtrue項が削除されてとりあえず警告。その箇所だけpragmaで警告抑制。