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で警告抑制。
568:デフォルトの名無しさん
10/05/04 14:48:38
>>563
エラーにするのはループ条件に出てきた時だけでいい
その他の場合はフェイルセーフで書く事もあるので警告すら出て欲しくないな
569:デフォルトの名無しさん
10/05/04 15:37:34
>>568
ループ条件に出てきたときはループ削除でよくない？エラーはやりすぎでしょう。
570:デフォルトの名無しさん
10/05/04 15:39:53
>>569
ごめん
別な条件の方で考えてた
(unsigned)x >= 0 の方
571:デフォルトの名無しさん
10/05/04 19:07:10
-Wallでも警告されずバグを埋め込んだ例
URLﾘﾝｸ(bugzilla.kernel.org)
572:デフォルトの名無しさん
10/05/04 20:28:37
>>571
すげー
Linus Torvalds の生コメントがある！
・・・でもLinusはC++大嫌いだったな確か。
573:デフォルトの名無しさん
10/05/04 21:36:18
enum class って劣化 Java の enum だよね
Java の enum そのものにしてくれないかなぁ・・
574:デフォルトの名無しさん
10/05/04 22:21:57
どちらかといえばC#のenumが近い
575:デフォルトの名無しさん
10/05/04 22:26:04
それは確かに否め（enumえ）ない
576:デフォルトの名無しさん
10/05/04 22:39:39
>>573
Java の enum ってどういう挙動なんだか知らんが
そんなに良いのか？
577:デフォルトの名無しさん
10/05/04 22:56:31
Javaのenumはクラスに近くて、
要素の宣言でコンストラクタに渡すパラメータを指定できる。
578:デフォルトの名無しさん
10/05/04 23:03:51
>>577
ふーん。ありがとう。
いっそenum class とenum structみたいに2種類にして
機能を分ければよかったのにね。
579:デフォルトの名無しさん
10/05/04 23:19:42
enumとして正しい値かどうか検査するメンバ関数とか
enum名を文字列で返すメンバ関数とか欲しいわ
580:デフォルトの名無しさん
10/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:デフォルトの名無しさん
10/05/04 23:59:20
そこまでするならクラスでいいじゃん、と思う
582:デフォルトの名無しさん
10/05/05 00:06:13
先生！！メリットがわかりませんん！！
583:デフォルトの名無しさん
10/05/05 00:10:28
enum class {} というのは指定したクラスのconstインスタンスを名前を
付けて列挙するものという意味付けにすれば後は何でも出来そうな。
584:デフォルトの名無しさん
10/05/05 00:21:49
Scala の case class の超絶しょぼい版という印象だな > Java の enum
585:デフォルトの名無しさん
10/05/05 00:22:54
演算子のオーバーロードは今のenumでもできるが
586:デフォルトの名無しさん
10/05/05 00:28:55
Javaほど機能詰めすぎると逆にイミフなような…
俺がほしかったのは"スコープつきのタイプセーフな列挙子"だし、
機能詰め込んだとしてもC#のenum程度でいいよ
587:デフォルトの名無しさん
10/05/05 00:39:09
ToStringは欲しかった
588:デフォルトの名無しさん
10/05/05 00:58:06
boost::lexical_cast
589:デフォルトの名無しさん
10/05/05 01:10:52
typeidのnameをもっとまともに規定してほしかった。
590:デフォルトの名無しさん
10/05/05 01:16:59
>>588
それもSTLコンテナの場合、operator<<が定義されてないから使えないんだよな……
591:デフォルトの名無しさん
10/05/05 01:23:39
自分で定義すれば良いんじゃね？
592:デフォルトの名無しさん
10/05/05 01:32:26
>>589
ちゃんと読める名前を返すものと、一意性さえあればいいものと、２つ用意して欲しいわ
593:デフォルトの名無しさん
10/05/05 01:36:48
typeidの名前の文字列をバイナリに含めるか含めないかのオプションが欲しい
594:デフォルトの名無しさん
10/05/05 15:03:54
ラムダ式を関数ポインタに渡せるようになれば、
システムコールバックが使いやすくなるな
GCなしでどう実装するのか分からないが
595:デフォルトの名無しさん
10/05/05 15:26:48
また来た
596:デフォルトの名無しさん
10/05/05 23:30:16
>>578
classとstructの違いはデフォルトのアクセス性しかないのに
enum class とenum structで機能が違うのは紛らわしくね?
597:デフォルトの名無しさん
10/05/05 23:52:10
template <struct T> がエラーなのと同様、
enum struct は不許可にすべき
598:デフォルトの名無しさん
10/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:デフォルトの名無しさん
10/05/06 08:37:22
lambdaって関数の引数として渡したい場合はtemplate使うしかないの？
シグネチャが分かっててもダメなんかな。
600:デフォルトの名無しさん
10/05/06 08:49:07
シグネチャが同じってoperator()のシグネチャが同じなだけで
キャプチャした変数によって型は違うんじゃないの？
601:デフォルトの名無しさん
10/05/06 08:52:44
>>600
翻訳単位が違えば型も別になるしなぁ。
静的型付けが大前提だし、template使うしかないのか・・・
602:デフォルトの名無しさん
10/05/06 09:38:55
ていうかlambdaのoperator()ってvirtualになってないのかな?
なってなさそうだなぁ
603:デフォルトの名無しさん
10/05/06 12:03:19
ラムダ式はalgorithmと組み合わせて使う事がほとんどだろうから
virtualはあまり必要ないんじゃ？
あ、コンテナの中にBase, Derivedへのポインタが入っていた場合に欲しいか
604:デフォルトの名無しさん
10/05/06 12:09:12
>>603
うん、C++的発想だとそうなるんだけど、つまりシグネチャ決めようがねーよなって話
605:デフォルトの名無しさん
10/05/06 12:31:36
無理にやったらやったで出来ない事もないだろうが
ただでさえキモいラムダ式がさらにキモくなるな
606:デフォルトの名無しさん
10/05/06 12:39:01
そういう強引な自己満コードを見たら今後は キモダ式 と呼ぶ事にするｗ
607:デフォルトの名無しさん
10/05/06 13:53:03
C++0xが入るとBoostはさらにキモさをPowerUpするぜ間違いない
608:デフォルトの名無しさん
10/05/06 13:57:02
いやな、VS2010で遊んでるんだが、ラムダ式かなり使えるよホント
これでBoost::lambdaはほとんど必要なくなるな
しかし見栄えが汚いな
C#3.0の時に汚いの分かってたろうからもう少し綺麗に見栄えのする
書式にできなかったものかねえ
609:デフォルトの名無しさん
10/05/06 14:37:53
Cの関数ポインタ自体がきったねぇことを考えると
もうラムダさんの服装は無難で妥当に思えてきたよ
610:デフォルトの名無しさん
10/05/06 14:53:15
ラムちゃんの衣装は虎模様のビキニ
611:610
10/05/06 14:54:01
誤爆しました
612:デフォルトの名無しさん
10/05/06 17:46:38
VS2010のメリットはラムダさんとautoさんとdecltypeさんだけだからな
他のすべての点においてVS2008に劣っている
613:デフォルトの名無しさん
10/05/06 18:50:40
VS2010は発売後直ちに数多くのバグ報告がされているからSP1は
早めに出るかも知れない
その時にC++0xの時間が無くて入れられなかった機能を入れて欲しい(´･ω･｀)
614:デフォルトの名無しさん
10/05/06 18:59:36
最初のベータから0xの機能は増えてないんだよな
615:デフォルトの名無しさん
10/05/06 19:52:03
>>612
rvalue reference の準拠文書が更新されてるってのを
Boost ML で見たような気がする。
616:615
10/05/06 19:54:16
>>612 じゃなくて >>614 だった。
617:デフォルトの名無しさん
10/05/06 20:21:29
VC2010は右辺値参照サポートしてライブラリも Move Semantics を実装してるんじゃなかったっけ？
618:デフォルトの名無しさん
10/05/06 20:22:50
別にC++0xの規格がまだ定まっていない以上、
C++0xに関するバグはどれだけあろうがしょうがないんじゃない？
ただ2010から現在のC++0x機能を除いたら何が残るのか知らんけど。
619:デフォルトの名無しさん
10/05/06 20:24:22
最早スレチだと思うけど、インテリセンスがマシになったという噂
620:デフォルトの名無しさん
10/05/06 20:45:35
C++/CLIはインテリセンス自体がなくなった
621:デフォルトの名無しさん
10/05/06 20:56:45
>>620
なるほど。確かにインテリセンスのバグはなくなったな。
622:デフォルトの名無しさん
10/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:デフォルトの名無しさん
10/05/06 23:31:53
>>617
std::mapとstd::tr1::shared_ptrを使ってみたけど両方共右辺値参照サポートしてるね。
624:デフォルトの名無しさん
10/05/06 23:34:07
>>619
インテリセンスはよく効くようになってきてるね。
エラーのハイライトの反映が遅いね。処理中は薄くするかステータスバーに表示して欲しいな。