C++0x 10

1 ：デフォルトの名無しさん：2010/06/01(火) 15:58:42

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

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

前スレ: C++0x 9
http://pc12.2ch.net/test/read.cgi/tech/1269623636/

2 ：デフォルトの名無しさん：2010/06/01(火) 16:00:03

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/

3 ：デフォルトの名無しさん：2010/06/01(火) 18:10:29

○禿
校長先生。

4 ：デフォルトの名無しさん：2010/06/01(火) 19:17:12

0xになって記号の使い方が増えてますます気持ち悪い言語になったな

5 ：デフォルトの名無しさん：2010/06/01(火) 19:49:12

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

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

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

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

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

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

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

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

6 ：デフォルトの名無しさん：2010/06/01(火) 19:50:04

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

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

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

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

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

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

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

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

7 ：デフォルトの名無しさん：2010/06/01(火) 19:51:00

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

8 ：デフォルトの名無しさん：2010/06/01(火) 19:51:52

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

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

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

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

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

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

9 ：デフォルトの名無しさん：2010/06/01(火) 19:52:44

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

10 ：デフォルトの名無しさん：2010/06/01(火) 19:58:54

> ○コンセプトさん（幽霊）
0xスレ1か2くらいで「直ぐに実装できる」って言われてたのになんでこんな酷い事になってんの？

11 ：デフォルトの名無しさん：2010/06/01(火) 20:12:36

○Blocksさん

12 ：デフォルトの名無しさん：2010/06/01(火) 20:22:23

○Blocksさん
遠く青森で林檎に囲まれて育ったラムダさんの親戚。帽子が特徴的。

13 ：デフォルトの名無しさん：2010/06/01(火) 20:37:16

なぜラムダ一族はおかしな帽子を被りたがるのか

14 ：デフォルトの名無しさん：2010/06/01(火) 20:52:57

attributeって、新しい記号を導入しちゃだめなのかな
どうせtrigraphあるから、入力できない環境を作る事もないだろうし

15 ：デフォルトの名無しさん：2010/06/01(火) 20:54:53

○Blocksさん
青森の林檎農家が付属小学校への裏口入学を試みているラムダさんの親戚。
とても気難しく、隣の部屋に行くにも「ぶろっくこぴー」という赤絨毯を要求する箱入り娘。

16 ：デフォルトの名無しさん：2010/06/02(水) 14:21:46

もう2010年なんだから、そろそろC++ 1xでいいと思うんだが。

17 ：デフォルトの名無しさん：2010/06/02(水) 15:32:11

stroustorup先生が00年代に0xと言ってしまったので

18 ：デフォルトの名無しさん：2010/06/02(水) 17:23:49

C++1x 0 でも良かったか

19 ：デフォルトの名無しさん：2010/06/02(水) 18:49:24

スレタイはC++0x0Aになると思ってた

20 ：デフォルトの名無しさん：2010/06/02(水) 19:14:24

校長先生がC++0xのままでいくと言ったから
C++0xのままでおk
C++0x A あたりになるとは俺も思ったのだが
まあどうでもいい

21 ：デフォルトの名無しさん：2010/06/03(木) 01:14:43

そろそろ#include棄てたいんだけどどうにかなるような話はなきや？

22 ：デフォルトの名無しさん：2010/06/03(木) 01:15:58

boost.ppが死ぬのでなきや

23 ：デフォルトの名無しさん：2010/06/03(木) 10:57:52

ラムダって関数ポインタにできないのか？

24 ：デフォルトの名無しさん：2010/06/03(木) 13:48:54

template関数でラップしてそのポインタを取ればできる

25 ：デフォルトの名無しさん：2010/06/03(木) 14:24:12

captureの無いλは関数へのポインタに変換出来るようにするという
提案があったと思うよ。

26 ：デフォルトの名無しさん：2010/06/03(木) 18:49:07

captureがないやつだけか
まあそうだろうな

27 ：デフォルトの名無しさん：2010/06/04(金) 20:24:32

むしろPreprocessorはもっと勢力拡張すべき。

28 ：デフォルトの名無しさん：2010/06/04(金) 20:37:50

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

そう、これだ。

29 ：デフォルトの名無しさん：2010/06/04(金) 22:54:31

__VA_ARGS__さんとテンプレート可変長引数さんとinitializer_listさんが組めば
空だって飛べる

30 ：デフォルトの名無しさん：2010/06/04(金) 22:56:13

vc++2010の対応が雑魚過ぎて困る

31 ：デフォルトの名無しさん：2010/06/04(金) 23:53:05

またVC6の頃みたいなバッドノウハウが累積される悪寒

32 ：デフォルトの名無しさん：2010/06/05(土) 00:20:58

まだC++0x自体が出来上がってないんだし仕方ないよ。
ドラフトをフライング実装してforのスコープ問題みたいなことがまた起こっても困るし。

個人で買いにくい価格設定になっているのはMSの良心かもしれない。

33 ：デフォルトの名無しさん：2010/06/05(土) 00:21:41

それならデフォルトではC++0xの機能をオフにして欲しかった

34 ：デフォルトの名無しさん：2010/06/05(土) 00:52:11

そもそも0x機能オフにできるの？

35 ：デフォルトの名無しさん：2010/06/05(土) 01:01:58

>>32
Express版があるぞ

36 ：デフォルトの名無しさん：2010/06/05(土) 02:21:26

VC10はそもそも開発チーム自身が「新しいVC6だ」って言ってたし

37 ：デフォルトの名無しさん：2010/06/05(土) 02:45:57

SPなりhotfixなりで矢継ぎ早に修正してくれれば問題ないんじゃない？
VC6は使われる時間が長すぎたからな

とりあえずさっさと可変長引数テンプレートサポートしてくれ

38 ：デフォルトの名無しさん：2010/06/05(土) 07:15:15

MSは互換性を最優先させるから、
明らかに実装方法の誤りであっても次Ver.まで仕様で放置とか良くあるんだよな。

39 ：デフォルトの名無しさん：2010/06/05(土) 07:24:24

vc++2010って初期化リスト周りおかしくね？

40 ：デフォルトの名無しさん：2010/06/05(土) 08:47:18

初期化リストなんて面倒なこと言わずに{～}をテンポラリな配列として扱えばよかったのに
そうすればtemplate <class T, size_t N> void func(const T (&a)[N]);で受け取れるし
コンパイル時にサイズもわかるし直にランダムアクセスもできる
なにより組み込みなのにstd名前空間とか気持ち悪い現象が発生しない

41 ：デフォルトの名無しさん：2010/06/05(土) 09:13:11

parse上の問題でもあるんじゃない？

42 ：デフォルトの名無しさん：2010/06/05(土) 09:15:39

配列はないな
サイズの取得が面倒くさい

43 ：デフォルトの名無しさん：2010/06/05(土) 09:16:06

組み込みなのにstd名前空間とか別に普通だよ
new が失敗すりゃ std::bad_alloc 例外投げるし
それを抑制する時に使うものも std::nothrow だし

44 ：デフォルトの名無しさん：2010/06/05(土) 10:59:04

std::initializer_list ってどう実装されてんの
引数を隠しローカル配列に入れておいて
そのポインタを保持するとか？

45 ：デフォルトの名無しさん：2010/06/05(土) 12:38:49

前スレで紹介されてた
http://wiki.apache.org/stdcxx/C++0xCompilerSupport
を見たところ、vc++2010はInitializer Lists対応してないね

確かにテンポラリな配列として扱えれば便利だよね
でも↓のような場合はstd::initializer_listがないと困る
// ヘッダファイル
void func(std::initializer_list<int> list);
// ソースファイル
void func(std::initializer_list<int> list) { ... }

と思ったけど仕様とか知らないからこれが可能なのかどうか
分からない

46 ：デフォルトの名無しさん：2010/06/05(土) 12:43:37

>>45
このケースなら薄いテンプレートで分離できなくも無い

47 ：デフォルトの名無しさん：2010/06/05(土) 12:54:49

使えないけど#include<initializer_list>は通るんだよな
中途半端なことやめて

48 ：デフォルトの名無しさん：2010/06/05(土) 13:49:36

std::initializer_list のクラステンプレート自体は実装してある
でもそれだけなんだよな
中途半端やなあ

49 ：デフォルトの名無しさん：2010/06/05(土) 16:26:52

g++4.5.0も a[{1,2}] を解釈してくれない。
FCDには例示されてるけど、後で加筆されたものなのか

50 ：デフォルトの名無しさん：2010/06/05(土) 19:34:34

>>38
スイッチで切り替えられるようにしないのはどういうつもりなのかねえ。

51 ：デフォルトの名無しさん：2010/06/05(土) 21:12:40

03にしたけりゃユーザーが勝手に自分で03の範疇で書いてろよ、って事でね？

52 ：デフォルトの名無しさん：2010/06/05(土) 22:21:04

はあ？

53 ：デフォルトの名無しさん：2010/06/05(土) 22:22:01

>>52
はあ？

54 ：デフォルトの名無しさん：2010/06/05(土) 23:04:15

>>51
VC10のC++0xの対応レベルで互換性が問題になるのはautoぐらいじゃね？

55 ：デフォルトの名無しさん：2010/06/05(土) 23:18:31

C++0xにはスマポ、正規表現、乱数とかいろいろあるから
それ全部使えなくなるってのはちょっと…
まあ、boostの使えば問題ないか

56 ：デフォルトの名無しさん：2010/06/05(土) 23:21:01

右辺値参照はすでに使いまくってるぜ

57 ：デフォルトの名無しさん：2010/06/05(土) 23:25:20

VC10でstd::tr1::shared_ptrとboost::shared_ptrがごっちゃになって困る。
using boost::shared_ptrして使っててstd::tr1::shared_ptrは使ってないつもりなのにstd::tr1::shared_ptrからboost::shared_ptrに変換できませんとか出る。何故なんだろう？

58 ：デフォルトの名無しさん：2010/06/05(土) 23:35:40

>>57 そーすうｐ

59 ：デフォルトの名無しさん：2010/06/05(土) 23:46:11

usingしなければよい

60 ：デフォルトの名無しさん：2010/06/06(日) 00:23:14

>>57
気になる。ソースソース。

61 ：デフォルトの名無しさん：2010/06/06(日) 08:48:10

ナントカルックアップだろ

62 ：デフォルトの名無しさん：2010/06/06(日) 09:25:29

>>57
using namespace std;
なんてしてないよな？

63 ：デフォルトの名無しさん：2010/06/06(日) 09:57:46

どっかのヘッダでusingしてる悪寒

64 ：デフォルトの名無しさん：2010/06/06(日) 10:05:57

ヘッダでusingとかえんがちょにもほどがある

65 ：デフォルトの名無しさん：2010/06/06(日) 10:16:49

>>64
ヘッダのnamespace内でusingすることはあるけどなぁ
boost::tr1の真似して

66 ：デフォルトの名無しさん：2010/06/06(日) 10:26:16

ヘッダでusingするのは
名前を取り込みたい時であって
名前空間を省略したい時ではないぞ

67 ：デフォルトの名無しさん：2010/06/06(日) 12:45:21

あーおれ面倒だから using namespace std::string よくやるわすまん・・・

68 ：デフォルトの名無しさん：2010/06/06(日) 12:52:20

死刑

69 ：デフォルトの名無しさん：2010/06/06(日) 13:28:06

ローカルの関数スコープ以外のusingを禁止するコンパイルオプションはなぜ無いのか

70 ：デフォルトの名無しさん：2010/06/06(日) 15:16:35

auto f(int x) -> hoge
{
・・・
}
この書き方ってなんかイイコトあるんですか？

71 ：デフォルトの名無しさん：2010/06/06(日) 15:23:13

-> decltype
が出来る、とか

72 ：デフォルトの名無しさん：2010/06/06(日) 15:37:14

template <typename T1, typename T2>
auto add(const T1& a, const T2& b) -> decltype(a + b) { return a + b; }

ができるからと言われるけど

template <typename T1, typename T2>
auto add(const T1& a, const T2& b) { return a + b; }

を許してもらえるなら必要ないよね
そもそも a + b を２度書かないといけないのが気に食わない

73 ：デフォルトの名無しさん：2010/06/06(日) 15:38:39

template <typename T1, typename T2>
auto add(const T1& a, const T2& b) -> decltype(a + b);

74 ：デフォルトの名無しさん：2010/06/06(日) 15:50:35

auto hoge(fuga x) -> decltype(x + piyo())
{
piyo y;

return x + y;
}

この場合はこう書くの？
けっこうメンドクセーな

75 ：デフォルトの名無しさん：2010/06/06(日) 16:23:37

template <typename T1, typename T2>
auto add(const T1&, const T2&) -> decltype(std::declval<T1>() + std::declval<T2>());

76 ：デフォルトの名無しさん：2010/06/06(日) 17:24:05

struct Hoge
{
typedef int type ;
type f() ;
} ;
というクラスがあった場合、このHoge::fの定義を書くのに、
従来の関数宣言の場合、

Hoge::type Hoge::f() { return 0 ; }

新しい関数宣言の場合、

auto Hoge::f() -> type { return 0 ; }

戻り値にクラス名の修飾がいらない。

77 ：デフォルトの名無しさん：2010/06/06(日) 17:26:41

まあそれなら便利な事もあるかな・・・
Hoge:: くらいなら auto -> 書くのと大差ないけど
もっと長いと使えるかも

78 ：デフォルトの名無しさん：2010/06/06(日) 17:34:21

でもどっちかに統一しないと気持ち悪いよな

79 ：デフォルトの名無しさん：2010/06/06(日) 17:43:35

必要に応じて便利な方を使うしかない。
気持ちを最優先にしてもコンパイルに関係ないし。

80 ：デフォルトの名無しさん：2010/06/06(日) 18:11:30

コンパイルに関係ないなら気持ちは優先してもいいんじゃね？

81 ：デフォルトの名無しさん：2010/06/06(日) 18:12:35

>>70
型が右に来る方が直感的

82 ：デフォルトの名無しさん：2010/06/06(日) 18:31:24

それはない

83 ：デフォルトの名無しさん：2010/06/06(日) 18:37:22

>>70

class LongLongHogeHugaItteyoshiClass{
public:
typedef VeryVeryLongLongHawawaTypeName T;
T f();
};

auto LongLongHogeHugaItteyoshiClass::f() -> T
{
...
}

84 ：デフォルトの名無しさん：2010/06/06(日) 18:39:18

// LongLongHogeHugaItteyoshiClass.cpp

#include "LongLongHogeHugaItteyoshiClass.h"
typedef LongLongHogeHugaItteyoshiClass L;

L::T L::f() {
}

85 ：83：2010/06/06(日) 18:40:00

ごめんなさい、すでに同じことが76に書かれてました。

86 ：デフォルトの名無しさん：2010/06/06(日) 19:32:46

>>84 と違って、>>76, >>83 のやり方だと
class 中の private な typedef にも使用可能だったはず…

87 ：デフォルトの名無しさん：2010/06/06(日) 19:49:53

privateなら好きに短い名前でtypedefすりゃええんやないの？

88 ：デフォルトの名無しさん：2010/06/06(日) 20:28:57

書くのがだるいというだけでtypedefを使うやつを俺は信用しない
ていうか入力補完でいいじゃないか

89 ：デフォルトの名無しさん：2010/06/06(日) 20:43:05

べ、別にあんたに信用されようなんて思ってないんだからねっ！

90 ：デフォルトの名無しさん：2010/06/06(日) 20:47:06

typedefは必須だろう

91 ：デフォルトの名無しさん：2010/06/06(日) 20:47:48

書くのがだるいだけじゃないぞ
読み辛い

92 ：デフォルトの名無しさん：2010/06/06(日) 20:48:52

typedef使わずに素の宣言かいてたらクラスの変更とか困るだろ

93 ：デフォルトの名無しさん：2010/06/06(日) 20:50:39

>>88
C#のひとか？

94 ：デフォルトの名無しさん：2010/06/06(日) 20:53:31

C#でもmonoで書くと補完効かんぞ

95 ：デフォルトの名無しさん：2010/06/06(日) 21:03:29

std::mapの値とかvalue_typeをtypedefしてるから明確になるのに。

96 ：デフォルトの名無しさん：2010/06/06(日) 21:05:57

EDスクロールが早いから偽EDですね

97 ：デフォルトの名無しさん：2010/06/06(日) 21:07:40

ごめん誤爆・・・

98 ：デフォルトの名無しさん：2010/06/06(日) 21:08:39

知ってます

99 ：デフォルトの名無しさん：2010/06/06(日) 21:35:10

typedefないとtemplate成立しない

100 ：デフォルトの名無しさん：2010/06/06(日) 21:36:57

いやその理論はおかしい

101 ：デフォルトの名無しさん：2010/06/06(日) 21:43:38

テンプレート引数をtypedefしないと
外から使えないし

102 ：デフォルトの名無しさん：2010/06/06(日) 21:55:01

確かにtypedefだけではtemplateは成立しない。
typenameも必要だ。

103 ：デフォルトの名無しさん：2010/06/06(日) 22:37:59

>>82
最近の言語はみんな右に書くようになってるんだぜ？

104 ：デフォルトの名無しさん：2010/06/06(日) 22:39:05

例えば？

105 ：デフォルトの名無しさん：2010/06/06(日) 22:40:47

Fortran

106 ：デフォルトの名無しさん：2010/06/06(日) 23:06:40

>>103
C#はどうだっつんだ
てか、右でも左でもどっちでも変わらん
どちらが直感的とかない

107 ：デフォルトの名無しさん：2010/06/06(日) 23:10:22

右に書く言語は
従来の文法を拡張したら仕方なくそうなったって奴が多いな

108 ：デフォルトの名無しさん：2010/06/06(日) 23:12:13

なんだまたC#の人だったのか

109 ：デフォルトの名無しさん：2010/06/07(月) 06:56:32

日本語的には左
英語的には右

110 ：デフォルトの名無しさん：2010/06/07(月) 07:27:09

構文解析の都合を考えると左の方が便利

111 ：デフォルトの名無しさん：2010/06/07(月) 07:32:54

int a;
int bb;
int ccc;
int dddd;

a : int
bb : int
ccc : int
dddd : int

下は揃わないな

112 ：デフォルトの名無しさん：2010/06/07(月) 10:03:52

inline namespaceって何者なんですか？
存在意義がいまいち不明なんですが・・・

113 ：デフォルトの名無しさん：2010/06/07(月) 10:40:53

名前空間バージョニングする場合色々問題があるのでその解決だそうだ
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1344.pdf

114 ：デフォルトの名無しさん：2010/06/08(火) 09:08:12

つまり…どういう事だってばよ？

115 ：デフォルトの名無しさん：2010/06/08(火) 22:34:16

inline namespace だと？初耳だぜ。

116 ：デフォルトの名無しさん：2010/06/08(火) 23:42:00

理解できる部分だけ使えばいいのさ

117 ：デフォルトの名無しさん：2010/06/09(水) 10:14:37

>>109
数学的には右だな

118 ：デフォルトの名無しさん：2010/06/09(水) 12:32:56

数学的にどうのと言うなら = の意味の違いをどうにかせえ

119 ：デフォルトの名無しさん：2010/06/09(水) 13:19:19

数学的に何か問題あるのか？

120 ：デフォルトの名無しさん：2010/06/09(水) 13:33:06

数学的な厳密さを言うんなら副作用がある時点で

121 ：デフォルトの名無しさん：2010/06/09(水) 16:00:15

キャプチャなしのラムダをラップする関数ってどうやって作るの？

122 ：デフォルトの名無しさん：2010/06/09(水) 23:11:25

キャプチャなしラムダなら関数ポインタに暗黙変換できるからラッパなんか必要なし

123 ：デフォルトの名無しさん：2010/06/09(水) 23:19:10

次にお前は「おのれVC++2010」と言う

124 ：デフォルトの名無しさん：2010/06/09(水) 23:19:54

>>122
VC++2010ですができませんよ？

125 ：124：2010/06/09(水) 23:20:46

ハッ！？

126 ：デフォルトの名無しさん：2010/06/09(水) 23:35:02

decltype(<<ラムダ式>>)::operator()のポインタ取れば？

127 ：デフォルトの名無しさん：2010/06/09(水) 23:36:22

自演だよなっ？

128 ：デフォルトの名無しさん：2010/06/09(水) 23:44:54

>>126
無理じゃね？

129 ：デフォルトの名無しさん：2010/06/10(木) 16:02:02

自演だとしても笑えたから許す

130 ：デフォルトの名無しさん：2010/06/10(木) 22:43:56

もうmailingは出ないのかしら

131 ：デフォルトの名無しさん：2010/06/11(金) 01:30:34

>>124
VC++ 2010がまだ追い付いていないだけ。

132 ：デフォルトの名無しさん：2010/06/11(金) 02:50:48

f(vector<int> &&);

auto *x = new vector<int>;
f(move(*x));
delete x; // ← このdeleteってなんか変なこと起こさないですか？

133 ：デフォルトの名無しさん：2010/06/11(金) 02:55:30

moveの後で*xに触ってるから未定義動作だな

134 ：デフォルトの名無しさん：2010/06/11(金) 03:26:59

デストラクタも呼べないのか？
そんなまさか

135 ：デフォルトの名無しさん：2010/06/11(金) 04:03:25

やっぱりいるよ。
>>133みたいな勘違いする奴が。

136 ：デフォルトの名無しさん：2010/06/12(土) 07:33:15

破壊的操作と未定義動作の区別がついて無いようだね。

137 ：デフォルトの名無しさん：2010/06/12(土) 07:41:12

X x; std::move(x);
ができる以上、デストラクタは呼べるはず
だからdeleteしても問題ないはず

138 ：デフォルトの名無しさん：2010/06/12(土) 07:58:10

やはり、std::moveなんて関数を標準で用意するから>>133みたいなバカがでるんだよ。
自前でstatic_castさせときゃいいんだよ。

139 ：デフォルトの名無しさん：2010/06/12(土) 08:08:29

>>137
「はず」ﾌﾟｹﾞﾗ

140 ：デフォルトの名無しさん：2010/06/12(土) 08:16:22

たとえばこう書いて、RVO最適化可能ならムーブよりRVOが優先されるなんてあると嬉しいんですが。将来的にはありますか？
Hoge func()
{
Hoge temp;
temp.f1();
temp.f2();
return std::move(temp);
}

141 ：デフォルトの名無しさん：2010/06/12(土) 08:18:59

今でもある。
その場合、
もしHogeがムーブコンストラクターを実装していなければ、
コピーコンストラクターが呼ばれる。

というか、最適化によって、コピーコンストラクターの呼び出しが省略される可能性もあるが。

142 ：デフォルトの名無しさん：2010/06/12(土) 08:24:26

お前実はRVOがなんだかわかってないだろ

143 ：デフォルトの名無しさん：2010/06/12(土) 08:26:54

ということは、
RVO可能->コピコンそのものが不用
RVO不可->コピコンまたはムーブ適用

ムーブコンストラクタがあってもRVO可能であればRVOが適用されるでいいのかな。

とりあえずstd::moveつけて置けば問題ないということでOK?

144 ：デフォルトの名無しさん：2010/06/12(土) 08:32:04

>>142
ごめん、読み間違えた。「ムーブより・・・優先」とみて条件反射でコピーコンストラクターだと思ってしまった。

145 ：デフォルトの名無しさん：2010/06/12(土) 08:36:07

>>143
よく考えたら、std::move通した時点でRVO可能なオブジェクトとコンパイラが認識できなくなる可能性があるね。

実験しないと分からないや

146 ：デフォルトの名無しさん：2010/06/12(土) 08:39:15

>>145
なぜ？ rvalue referenceにキャストしているだけじゃないか。
ポインターならともかく。

147 ：デフォルトの名無しさん：2010/06/12(土) 08:40:11

というか何だその「実験」って。
未だにまともなC++コンパイラは存在しないんだぞ。
何を実験するというんだ。

148 ：デフォルトの名無しさん：2010/06/12(土) 08:43:44

そうか、まだなのか。
RVO_OR_MOVE()マクロ作って後からまとめて切り替えられるようにしておこうか。

149 ：デフォルトの名無しさん：2010/06/12(土) 08:45:58

>>146
キャストでコンパイラが自動変数って情報を落として最適化できなくなるんじゃないかなっと思った。

150 ：デフォルトの名無しさん：2010/06/12(土) 08:47:35

てかムーブよりRVOが優先されると嬉しいってどういうケースじゃろ

151 ：デフォルトの名無しさん：2010/06/12(土) 09:19:15

moveとかrvalueってさ、コンパイラに最適化のヒントを与える魔法のツールじゃないよね?

152 ：デフォルトの名無しさん：2010/06/12(土) 09:24:16

moveは最適化じゃないから、適用されるかどうかは確実に判断できる。
RVOは最適化だから確実な予測はできない。

153 ：デフォルトの名無しさん：2010/06/12(土) 09:33:36

>>150
RVOはコスト0

154 ：デフォルトの名無しさん：2010/06/12(土) 17:52:49

>140
return std::move(temp);

じゃなくて

return temp;

とだけ書いていれば良いのでは？

155 ：デフォルトの名無しさん：2010/06/12(土) 18:27:16

>>154
たとえばこれならほぼ確実にRVOがかかる。
return hoge(100);

だけど、こんな複雑な場合だとRVOがかからない場合がある。
hoge temp;
temp.func(100);//なんか操作する。
return temp;

RVOかからないなら次善策でムーブを使いたいなと。

156 ：デフォルトの名無しさん：2010/06/12(土) 19:11:55

>>155
return文で（コピーではなく）ムーブすることも決まっていることも決まっているから、
return temp;とだけ書いておけば、NRVOが適用されるならそれで、
適用されないならムーブで処理されることになるはず。

157 ：デフォルトの名無しさん：2010/06/12(土) 19:16:08

>155
いや，なのでそうとだけ書いておきさえすれば

(1)コンパイラが RVO を適用できるならする
(2)hoge が move constructor を持っているならば return で move を使う
(3)コピー

というのを上から順に適用していって可能なものを採用すると思います．
(2) は， return temp; という文においては temp が自動変数なので，
まず temp を自動的に右辺値として取り扱おうとするはずだからです．

158 ：124：2010/06/12(土) 19:18:10

hoge func() { const hoge h; return h; }

moveにならなくて不愉快

159 ：デフォルトの名無しさん：2010/06/12(土) 19:36:18

>>158
それはconstなオブジェクトからムーブできない話であって、また別の話。

ムーブは元オブジェクトを破壊してよいことを前提としているので、
constなオブジェクトはすなわち破壊できないので、そこからムーブできないということ。
可能な限りconst付ける教とムーブセマンティクスは本質的に相性が良くない。

160 ：デフォルトの名無しさん：2010/06/12(土) 19:38:35 BE:540286092-2BP(0)

それは当然・・・

161 ：デフォルトの名無しさん：2010/06/12(土) 19:39:20 BE:180096023-2BP(0)

>>160は>>158へのレスな

162 ：デフォルトの名無しさん：2010/06/12(土) 19:45:12

関数の戻り値として返すときは特別扱いして欲しいってことか

163 ：デフォルトの名無しさん：2010/06/12(土) 19:46:59

>>157
丁寧な回答ありがとうです。
returnはmoveを使うで理解しました。
c++0xは思ったより気が利いてるなと感心したり

164 ：デフォルトの名無しさん：2010/06/12(土) 20:58:40

VCのSP1はまだか

165 ：デフォルトの名無しさん：2010/06/12(土) 21:41:28

>>164
あほか
まだVC2010そのものが店頭で売ってない
ダウンロード販売のみ
SP1はいくらなんでもその後だろう

あるとしたら店頭に並んでるものに既にSP1が適用してあるとか
そういう場合くらいしか

166 ：デフォルトの名無しさん：2010/06/12(土) 22:58:10

世の中には発売前にパッチが出たりするソフトがあるんだよ

167 ：デフォルトの名無しさん：2010/06/12(土) 23:22:51

というかVS2010は、よくあれでリリースしたなという出来なんだが。
IDEからしてクソすぎるし。

168 ：デフォルトの名無しさん：2010/06/12(土) 23:29:15

>>167
さっさとてめえの化石ＰＣを窓から投げ捨てろ

169 ：デフォルトの名無しさん：2010/06/12(土) 23:40:21

遅いといってるわけではなさそうだが。完成度が低いというなら分かる。

170 ：デフォルトの名無しさん：2010/06/13(日) 00:19:02

遅い上に完成度が低い

171 ：デフォルトの名無しさん：2010/06/13(日) 00:24:47

2005proのIDEから2010eeのC++コンパイラが呼び出せたらベストなんだが

172 ：デフォルトの名無しさん：2010/06/13(日) 00:26:23

そりゃ抱き合わせですよ
独占ですから

173 ：デフォルトの名無しさん：2010/06/13(日) 05:08:33

>>171
devenv /useenv

174 ：デフォルトの名無しさん：2010/06/16(水) 14:31:33

RVOやNRVOが出来たかどうか調べるにはどうしたらいいのだろうか・・・難しい・・・・・・・・

175 ：デフォルトの名無しさん：2010/06/16(水) 14:53:13

コピーコンストラクタでログ録ってそれが無視されてたら最適化されたとみていいんじゃねーか？

176 ：デフォルトの名無しさん：2010/06/16(水) 15:14:40

LLVM の C++ （の開発版）で、オプションつけると RVO/NRVO 対象に
できたかどうかわかるよ

177 ：デフォルトの名無しさん：2010/06/16(水) 17:06:45

inlineみたいにされたか出るコマンドはGCCにはないですか？

178 ：デフォルトの名無しさん：2010/06/16(水) 19:19:30

副作用があるのに勝手に消えられるのも困るよな

179 ：デフォルトの名無しさん：2010/06/16(水) 20:49:23

RVOのような動作が変わる最適化はコンパイルメーカの独断ではできないから、あえて規格上で許してるんでしょう。
規格上許しているんだから、コピコン省かれて困る設計のほうがまずいんではないか？

180 ：デフォルトの名無しさん：2010/06/16(水) 20:53:13

んだ

181 ：デフォルトの名無しさん：2010/06/16(水) 21:29:39

VC++EE2010で

#include <iostream>
struct Hoge
{
static volatile int count_;
Hoge()
{
}
Hoge(const Hoge & hoge)
{
++count_;
}
};
volatile int Hoge::count_ = 0;
Hoge test()
{
return Hoge();
}
int main(void)
{
Hoge h(test()), g(test());
std::cout << Hoge::count_ << std::endl;
return 0;
}

ってやってみたけどcount_はゼロだったぜ
volatile無視かよ

182 ：デフォルトの名無しさん：2010/06/16(水) 21:35:54

>>181
RVOでコピコンがそのもの省略されてるんだから、countのvolatileは無関係だろ。

183 ：デフォルトの名無しさん：2010/06/16(水) 21:39:19

RVOが行われる場合、
コピコンが影響するのはアクセス制限くらいやで

184 ：デフォルトの名無しさん：2010/06/16(水) 21:46:52

じゃあ人類にRVO最適化をコードから阻止する手段は残されていないのですか？

185 ：デフォルトの名無しさん：2010/06/16(水) 21:56:38

>>184
こんなの通してreturnに渡したらかからなくなったことがあったような気がする
template<class T>
inline T& stop(T& a)
{
returan a;
}

ＲＶＯが効いて困るコードを書く方が問題があるぞ。バグの温床じゃないか？直したほうがいいよ。

186 ：デフォルトの名無しさん：2010/06/16(水) 22:00:23

RVOが問題なるケースが思いつかない

187 ：デフォルトの名無しさん：2010/06/16(水) 22:04:18

きっと常人には理解もできない状況なのだろう
理解したくもないが

188 ：デフォルトの名無しさん：2010/06/17(木) 13:02:02

gccが__m128用のコピーコンストラクタ書いているのにスタックに積んで4バイトずつコピーするのはRVOのせいだったのか。
RVOうぜー。

189 ：デフォルトの名無しさん：2010/06/17(木) 15:59:55

RVO,NRVO > move()>無し
だからね。
(RVO OR 無し) あるいは (move())
だから非常に困るね。

190 ：デフォルトの名無しさん：2010/06/17(木) 18:31:44

>>189
もっと整理して書けよw
プログラムもそうなのか?

191 ：デフォルトの名無しさん：2010/06/17(木) 20:03:02

>>188
コピーしているならRVOじゃないよね。コピーそのもの存在を無くすのがRVOなのに。

どんなコピーコンストラクタかいてるの？

192 ：デフォルトの名無しさん：2010/06/17(木) 20:19:52

>>188
お前のコードが糞

193 ：デフォルトの名無しさん：2010/06/17(木) 20:25:34

>>189
どこが困るのかな？

194 ：デフォルトの名無しさん：2010/06/18(金) 09:27:08

可変長テンプレートつかった可変長引数の関数って引数は再帰で取り出すしかないんですか？
再帰はオーバーヘッドがありそうで嫌です

195 ：デフォルトの名無しさん：2010/06/18(金) 12:04:45

じゃあ使うな

196 ：デフォルトの名無しさん：2010/06/18(金) 12:07:27

>>194
ちょっと意味わからないから
コードを２ｃｈのこのスレッドに投稿してくれる？？

197 ：デフォルトの名無しさん：2010/06/18(金) 14:19:01 BE:360191243-2BP(0)

「2chのこのスレッドに」とわざわざ言うのは
「this->」みたいなもんか

198 ：デフォルトの名無しさん：2010/06/18(金) 15:45:10

const Hoge &は左辺・右辺とわず受け取れるけど
非constで左辺・右辺両方を受け取れるにはどうすればいいの？

199 ：デフォルトの名無しさん：2010/06/18(金) 16:15:58

マクロで仮引数の型だけ違う同じ内容の函数を書き出す

200 ：デフォルトの名無しさん：2010/06/18(金) 19:20:02

非constの右辺値受け取ってどうするんだろう

201 ：デフォルトの名無しさん：2010/06/18(金) 19:30:21

move

202 ：デフォルトの名無しさん：2010/06/18(金) 19:57:11

おいこらConceptはいつ入るんだ

203 ：デフォルトの名無しさん：2010/06/18(金) 20:03:29

Conceptはみんなの心の中に生き続けているよ

204 ：デフォルトの名無しさん：2010/06/18(金) 20:51:39

C++1xにご期待ください。

205 ：デフォルトの名無しさん：2010/06/18(金) 20:53:31

>>200だけど、自分の書いたソースコードの中で使用例見つけてしまった。
コンテナから本体を書き換えることのできる部分コンテナを返す関数を
別の関数に参照渡しする場合だな。
具体的にはOpenCVのcv::Matの部分配列(ROI)なんだが。

VC++の非標準の拡張によって右辺値が非constの左辺値参照に置き換えられてたみたいだ。
コンパイルレベルをあげたら警告が出た。

206 ：デフォルトの名無しさん：2010/06/18(金) 20:59:00

>>198
右辺値を非constで左辺値のように受けるのは危険だから受けられないようになっている。そのための&&だ。
まずそれが必要か考え直したほうがいい。

207 ：デフォルトの名無しさん：2010/06/19(土) 02:14:34

すみません質問ですが
#include <iostream>
auto main() -> int
{
　　[]{ std::cout << "hello, world\n"; }();
}

以下の部分は何を意味してるのでしょうか？
main() -> int

208 ：デフォルトの名無しさん：2010/06/19(土) 02:19:48

推論不能時の戻り値

209 ：デフォルトの名無しさん：2010/06/19(土) 02:21:04

「返却値」だろうが

210 ：デフォルトの名無しさん：2010/06/19(土) 02:24:04

それ俺がν速で書いた奴じゃないかｗ

211 ：デフォルトの名無しさん：2010/06/19(土) 02:25:06

そんなクソ短いコードなんてとっくの昔に誰かが書いてるわ

212 ：207：2010/06/19(土) 02:26:00

ありがとうございます

213 ：デフォルトの名無しさん：2010/06/19(土) 08:36:41

戻り値を後ろに書く構文ってだけ

214 ：デフォルトの名無しさん：2010/06/19(土) 08:43:30

>>213
auto func(int x)->decltype(hoge(x)){return hoge(x);}
これをこんな風にかけると二回同じ式を書かなくてすむんだけど
auto func(int x)->hoge(x);

215 ：デフォルトの名無しさん：2010/06/19(土) 08:48:47

-> の後ろに直接式書くとかキモいことしなくても
普通にこれでええやん

auto func(int x) { return hoge(x); }

ラムダではできるのに普通の関数ではできない仕様なのは
ヘッダに書く関数や単一ファイル内で使う関数でないと意味がないからか？
と思ったけど、これやりたいのって大体関数テンプレートだから
できてもいいように思える

216 ：デフォルトの名無しさん：2010/06/19(土) 08:51:03

Unified Function Syntaxにも戻り型推測提案してこい

217 ：デフォルトの名無しさん：2010/06/19(土) 08:56:11

>>215
そんな記述もできるの？
{}のなかを評価しないと戻りの型が決まらないんでできないと思ってた。コンパイラは大変だなあ
もしこの関数がメンバー関数の場合{}の中は前方参照不可とか制約無いのかな？

218 ：デフォルトの名無しさん：2010/06/19(土) 08:56:12

もうUnified function syntaxのことは忘れようぜ…
とっくにrejectされてんだから

219 ：デフォルトの名無しさん：2010/06/19(土) 08:56:43

>>217
できない

220 ：デフォルトの名無しさん：2010/06/19(土) 08:58:14

auto func = [](int x){return hoge(x);};
なら行ける

けどテンプレートにできんのよね

221 ：デフォルトの名無しさん：2010/06/19(土) 09:04:05

>>218
VC++2010で使えるけど、これは先走ったわけか
auto hoge() -> int { return 0; } // OK
int main() { return hoge(); }

222 ：デフォルトの名無しさん：2010/06/19(土) 09:16:20

もう仕事に0x使い始めてるところなんてあるの？

223 ：デフォルトの名無しさん：2010/06/19(土) 09:23:29

>>218　え？使えなくなったの？

224 ：デフォルトの名無しさん：2010/06/19(土) 09:24:51

>>221
unified function syntaxってのはこれ
[]main()->int{ return 0; }

225 ：デフォルトの名無しさん：2010/06/19(土) 09:31:49

>>224
なるほど

226 ：デフォルトの名無しさん：2010/06/19(土) 09:35:18

>>217
ラムダでは戻り値型の推測はできるので
普通の関数でもできないわけじゃないはずだ

普通の関数は多値returnができるけど
ラムダではできないという違いも
普通の関数での戻り値推測がない点に関係あるのだろうか？

227 ：デフォルトの名無しさん：2010/06/19(土) 09:37:35

ラムダは実装もすぐに書くから返り値がわかるけど
普通の関数やメンバ関数はヘッダとソースが分かれてるかもしれない

228 ：デフォルトの名無しさん：2010/06/19(土) 09:41:06

分かれてない場合には使えるじゃない、と

229 ：デフォルトの名無しさん：2010/06/19(土) 10:08:13

>>226
> 普通の関数は多値returnができるけど
C++ って多値返せないだろ, どういう意味だ?

230 ：デフォルトの名無しさん：2010/06/19(土) 10:16:22

文脈からみて一個の関数内にreturnが複数個あるって事じゃね？

231 ：188：2010/06/19(土) 10:22:53

>>191-192
gcc 4.4.0で起きたからレポートしようと思っていたらgcc 4.5.0で直ってた

232 ：デフォルトの名無しさん：2010/06/19(土) 10:33:26

>>229
std::initializer_list を引数に取るコンストラクタを持つクラスが戻り値の型になってる場合、
return { 0, 1 }; みたいにできる

233 ：デフォルトの名無しさん：2010/06/19(土) 18:22:52

for_each(v, [](auto &x){ return x+=10; });
みたいな引数の型を推論してくれるようなラムダってないの？ないの？の？

234 ：デフォルトの名無しさん：2010/06/19(土) 18:30:45

だからboost::lambdaがなくならないのさ

235 ：デフォルトの名無しさん：2010/06/19(土) 18:36:53

いい加減多次元の動的配列をサポートしろよ

236 ：デフォルトの名無しさん：2010/06/19(土) 19:04:51

>>235
イラネ、ライブラリで対応できる。
そういう言語サポートが必要なのは拡張能力の乏しい言語だけ

237 ：デフォルトの名無しさん：2010/06/19(土) 19:07:57

どうしてBoost.MultiArrayを標準化しなかった。

238 ：デフォルトの名無しさん：2010/06/19(土) 19:11:30

標準にするにはマニアックすぎたんじゃないか？
第二水準標準ライブラリとか作って採用して欲しい。

239 ：デフォルトの名無しさん：2010/06/19(土) 19:14:26

ライブラリでできるからといって組み込みで必要ないというなら
initializer_listもライブラリでいいんだな？

240 ：188：2010/06/19(土) 19:25:21

>>236
いや処理系の問題だが、ICCなんかループが深くなると添字の計算をループの外に出さなくなって途端に遅くなる問題とかあるぞ。

m x nの二次元配列aで直線的にアクセスする場合、
for ( int j = 0; j < n; ++j ) {
for ( int i = 0; i < m; ++i ) {
// a[i+j*m] を読み出してなんか処理
}}
で通常j*mはfor(i)の外に移動される。
でもこのループが同じ関数内でも4重5重とネストが深い時に外に出されなくなった。

これが三次元配列、四次元配列となるにつれ、
a[i+j*m+k*m*n+l*m*n*o ...]と式が複雑になっていって、コンパイラを混乱させる。
なので多次元配列が組み込みとして存在すれば、最適化の推論は簡単になる。

241 ：デフォルトの名無しさん：2010/06/19(土) 19:28:25

>>240
多次元配列に夢の持ちすぎだろう。

242 ：デフォルトの名無しさん：2010/06/19(土) 19:36:50

>>240
そういうのって、部分配列で次元数を減少させてループを書いたりするんじゃね？

いくら組み込みでも多次元の添え字をランダムアクセスで渡せば最適化できないだろう。結局同じテクニックが必要だと思うんだ。

243 ：デフォルトの名無しさん：2010/06/19(土) 19:51:32

>>240
処理系の所為なら同じ問題が起きるだけじゃね？

244 ：デフォルトの名無しさん：2010/06/19(土) 20:50:00

多次元配列って実装が一種類じゃないんだよね。
C配列、FORTRAN配列、row-first、collumn-first
使用目的に応じて実装できるライブラリが適してると思うんだよ。
行列にしても、帯行列、三角、スパース行列、など行列の特性に応じた格納方法があるし。

組み込み多次元配列を用意したところで適用できなければメリットは小さいと思うよ。

245 ：188：2010/06/19(土) 21:13:45

>>244
その理論だとFORTRANに多次元配列がある説明になっていないぞ。

確かに疎行列のような特殊なものはライブラリで補うしかない。
row-first、column-firstも行列積の概念から来ているだけ。
C言語的に必要なのはa(i, j)があった時にメモリが隣接しているのはどっちの添字かという事だけ。縦も横も無い。
あとCの静的多次元配列は「ポインタの配列」または「ポインタのポインタ」と矛盾しないようにあんな順序になっているだけ。

>>235は単に基本となる配列を動的多次元にしてくれって言っているだけでしょ。
そしてその意見には>>240的観点から賛同する。

246 ：デフォルトの名無しさん：2010/06/19(土) 21:32:22

いい加減自己主張やめて名前欄消せ

247 ：デフォルトの名無しさん：2010/06/19(土) 23:56:42

可変長テンプレート引数を利用すれば
std::vectorからの０オーバーヘッドを保ちつつ作れそうか

248 ：デフォルトの名無しさん：2010/06/20(日) 01:39:13

例え次元数固定でもテンプレートで作っちゃうと、毎回愚直にアドレス計算されるよ。

249 ：デフォルトの名無しさん：2010/06/20(日) 01:54:51

特殊化すりゃいいだけじゃん

250 ：デフォルトの名無しさん：2010/06/20(日) 06:25:21

特殊化してもj*mをループの外に移動出来ないでしょ。

251 ：デフォルトの名無しさん：2010/06/20(日) 08:30:17

多次元配列が欲しいんじゃなくて最適化して欲しいだけじゃないか

252 ：デフォルトの名無しさん：2010/06/20(日) 08:39:11

boostの多次元配列はコンパイル時間長いし、そもそもboost禁止の場合もある
組み込みの多次元配列が有ってうれしいことはあっても困ることはない

253 ：デフォルトの名無しさん：2010/06/20(日) 09:05:12

組み込みの多次元配列がなくて困ると言う声がほとんどない以上、入る事はないな。

254 ：デフォルトの名無しさん：2010/06/20(日) 09:14:11

利便性の向上でもあり、最適化のヒントにもなるツール。
言語の歴史から言えば多分RVOよかよっぽど基本的な話。

255 ：デフォルトの名無しさん：2010/06/20(日) 09:14:41

困ることが無いから入れるという理屈では入ることは無い。
実現方法がたくさんあると、ライブラリ間でのデータの受け渡しに支障が出る。

256 ：デフォルトの名無しさん：2010/06/20(日) 09:27:42

NULL終端じゃなくてサイズ+データの基本データ型があるだけでも汎用性高いんだけどね。
FORTRANはデータだけでもコンパイラに多次元配列である事を伝えることが出来る。
Cっぽく書くと
void func(int n, int m, int array[m][n]) {}
ってな感じ。

257 ：デフォルトの名無しさん：2010/06/20(日) 09:32:53

C++ で数値計算しようと思わないからいらね > 多次元配列

258 ：デフォルトの名無しさん：2010/06/20(日) 09:39:45

initializer_listで受け取った引数は連続領域にある前提で書いていいの？

259 ：デフォルトの名無しさん：2010/06/20(日) 09:40:08

多次元配列はライブラリでできるのがC++
組み込みじゃないなと嫌っていう人はFORTRANを遣えば良いってだけの話。

260 ：デフォルトの名無しさん：2010/06/20(日) 09:41:38

はいはい数値計算数値計算。
そういう本質が分からん奴に限ってWin32APIで絵を表示しようとしたときに
SetPixelを使って、「遅い」とか言い出すんだよなあ。

261 ：デフォルトの名無しさん：2010/06/20(日) 09:42:22

必要度　concept>多次元配列

コンセプトは必要。マジ欲しい。

262 ：デフォルトの名無しさん：2010/06/20(日) 09:44:00

>>255
そうそう
規格で統一すれば異なるライブラリ間で多次元配列を簡単にやり取りできるのにね

263 ：デフォルトの名無しさん：2010/06/20(日) 09:50:59

>258
一旦配列に確保されたかのように扱われるから OK のはず。end() も begin() + size() になってる。

264 ：デフォルトの名無しさん：2010/06/21(月) 12:34:28

最適化のためのキーワード(や、それに代わるもの)がほしいって話なら…
registerが肥やしに変わった以上、マジそれがないと実現不可能とかじゃないと追加は難しいんじゃないかな

上の例だと「ネストが深くても最適化してくんない？」ってIntelにリクエストすればいいだけだし

265 ：デフォルトの名無しさん：2010/06/22(火) 02:03:03

これ以上議論する気はないけれど、配列に追加のキーワードはいらないだろ。
そんなこと言うならRVOとかmoveとか口にするなよ。
initializer_listだってなんだって、多くのものは利便性の向上をメインとして
更に最適化の機会向上も兼ね備えているんだよ。

266 ：デフォルトの名無しさん：2010/06/22(火) 07:00:08

これ以上議論する気はないけれどと言っておきながら議論ふっかける男の人って。。。

267 ：デフォルトの名無しさん：2010/06/22(火) 07:13:06

自分の言いたいことは言うけど、反論されるのは怖いからやめてください。

268 ：デフォルトの名無しさん：2010/06/22(火) 07:22:11

initializer_listって配列の代わりに使えるよな
もっと一般化できそうだが

269 ：デフォルトの名無しさん：2010/06/22(火) 08:18:46

反論は怖くない。そこから得られるものがあればいい。
あまり続けると、他の話題を出したい人が話に割り込めなくなるのが怖いだけだ。

270 ：デフォルトの名無しさん：2010/06/22(火) 08:20:20

無様な言い訳をする男の人って軟弱でステキ！

271 ：デフォルトの名無しさん：2010/06/22(火) 11:47:02

ユーザー定義リテラルなんかよりインクルードガードが欲しかったな

272 ：デフォルトの名無しさん：2010/06/22(火) 11:51:11

途中まで #pragma once が規格に残っていたのにいつのまにか消えたのは何でだろう

273 ：デフォルトの名無しさん：2010/06/22(火) 12:40:08

>>272
いい事だ

274 ：デフォルトの名無しさん：2010/06/22(火) 13:21:51

gcc とｖｃは #pragma once 使えるから規格になくてもいいや

275 ：デフォルトの名無しさん：2010/06/22(火) 14:59:48

LLVMのCLangも大きな派閥になってくると思う。
ConceptGCCの中の人がC++サポートをやってるし。

276 ：デフォルトの名無しさん：2010/06/22(火) 21:01:57

>>272
インクルードガードだと、インクルードが循環参照するとコンパイルされなくてエラーになるのが便利。
#pragma oneceだとヘッダの参照関係が循環してもコンパイルが通ってしまって不便、危険。

277 ：デフォルトの名無しさん：2010/06/22(火) 21:23:05

？？

278 ：デフォルトの名無しさん：2010/06/22(火) 21:39:28

循環参照を気にしなくてもいいように#pragma once使うんじゃないの？

279 ：デフォルトの名無しさん：2010/06/22(火) 21:39:43

#pragma once の問題はハードリンクをどう扱うか程度じゃなかったっけか？
そしてそれが致命傷

280 ：デフォルトの名無しさん：2010/06/22(火) 21:41:36

インクルードガード内の循環参照は重複してインクルードされないだろ

281 ：デフォルトの名無しさん：2010/06/22(火) 22:18:18

>>280
インクルードされないから循環参照をエラーとして検出できる。

282 ：デフォルトの名無しさん：2010/06/22(火) 22:28:47

例を出せ
もちろんちゃんとコンパイルして期待した動作をすることを確かめてからな

283 ：デフォルトの名無しさん：2010/06/22(火) 22:36:01

// a.h
#ifndef a_h
#define a_h
#include "b.h"
struct A {};
#endif a_h

// b.h
#ifndef b_h
#define b_h
#include "a.h" // 循環参照
struct B {};
#endif b_h

// a.cpp
#include <ostream>
#include "a.h"
int main() {
std::cout << sizeof(A) << ' ' << sizeof(B) << std::endl;
}

問題なくコンパイルできる

284 ：デフォルトの名無しさん：2010/06/22(火) 22:37:43

循環参照が#pragma onceにしただけで解消されるとか
どんなファンタジーなんだ

285 ：デフォルトの名無しさん：2010/06/23(水) 03:22:22

std::pair を
template<typename U, typename... Args> pair(U&&, Args&&...)
で構築するとして
pair<int, int> p(1);
の second は zero-initialized と決まってるんでしょうか

286 ：デフォルトの名無しさん：2010/06/23(水) 04:22:40

インクルードガードを書けば循環参照が検出できるなんて
どんなファンタジーなんだ

287 ：デフォルトの名無しさん：2010/06/23(水) 10:57:13

#includeは参照じゃないだろ。
ファイルに埋め込まれるから自己埋め込みになる。

288 ：デフォルトの名無しさん：2010/06/23(水) 11:11:05

>インクルードガードだと、インクルードが循環参照するとコンパイルされなくてエラーになるのが便利。
そろそろサンプルぷりーず

289 ：デフォルトの名無しさん：2010/06/23(水) 11:22:58

#errorで自分でやるんじゃないの

290 ：デフォルトの名無しさん：2010/06/23(水) 12:46:24

#includeはただの埋め込みだとなんどいったら(ry

291 ：デフォルトの名無しさん：2010/06/23(水) 14:28:57

>285
そのコンストラクタは N3092 には無いです．

292 ：デフォルトの名無しさん：2010/06/23(水) 16:29:09

クラスの循環参照とごっちゃになってる人がいる？

293 ：デフォルトの名無しさん：2010/06/23(水) 16:32:27

このスレはC++上級者の中でも更に次の規格について議論する人たちの集まりかと思っていたら、
上を目指すどころかコンパイラの仕組みも理解してない人多くね?

294 ：デフォルトの名無しさん：2010/06/23(水) 16:49:05

クラスの循環参照って何？

コンパイラの仕組みとか以前というか
自分で勝手に意味を決めてるやつが多いのかな？

295 ：デフォルトの名無しさん：2010/06/23(水) 16:54:57

VCのpragma onceて、初見のソースにつき一回しか参照っていうか取り込みされないと思ってたのだがちがったのか？

296 ：デフォルトの名無しさん：2010/06/23(水) 18:42:57

違わない

297 ：デフォルトの名無しさん：2010/06/23(水) 19:13:15

だよ～ね。

298 ：デフォルトの名無しさん：2010/06/23(水) 19:21:41

しかし、ハードリンクが絡むと状況は複雑になる
パスが全く違っても同じ実体を指している事があるけど、
それも検出せなあかんのん？と

299 ：デフォルトの名無しさん：2010/06/23(水) 19:24:20

iノード番号でわかるだろ

300 ：デフォルトの名無しさん：2010/06/23(水) 19:25:10

内容が全く同じソースなら弾けばいいんじゃないのかしら？
たとえ実態が別々でも

301 ：デフォルトの名無しさん：2010/06/23(水) 19:47:34

環境によっては色々面倒な話が出てくるから、規格から外されたわけだ。

302 ：デフォルトの名無しさん：2010/06/23(水) 19:50:27

環境ごとの面倒な話を統一するための規格じゃないのか
根性ねえなぁ

303 ：デフォルトの名無しさん：2010/06/23(水) 19:53:11

めんどくせぇ

304 ：デフォルトの名無しさん：2010/06/23(水) 19:57:11

>>291
ｿﾃﾞｽｶ… orz
では、pair に限らず (U&&, Args&&... args) の args が省略された場合
fundamental type を forward<Args>(args)... で構築した場合
zero-initialized と期待していいのでしょうか

305 ：デフォルトの名無しさん：2010/06/23(水) 20:11:31

>>302
ディレクトリ操作すら規格にない言語だから仕方がない
かろうじてディレクトリに関するerrnoがあるくらいだ

306 ：デフォルトの名無しさん：2010/06/23(水) 21:34:56

禿は # で始まらない include を夢見てたようだが

307 ：デフォルトの名無しさん：2010/06/23(水) 21:40:30

ソースファイルをコンパイルしたら
外部に公開できる宣言をまとめたファイルが自動的に作られて、
それをimportするような感じになってくれればなあと思う

308 ：デフォルトの名無しさん：2010/06/23(水) 21:44:58

むしろ、ソースファイルを指定したら、
そこから必要な宣言集を構築してくれるような仕組みの方がいい。
わざわざ分ける必要はない。
いまどきヘッダーファイルなんて時代じゃねーだろ。

309 ：デフォルトの名無しさん：2010/06/23(水) 21:45:58

それはC++/CLI

310 ：デフォルトの名無しさん：2010/06/23(水) 22:44:31

>>308
C++でそれやると現実的なコンパイル速度にならない気がする

311 ：デフォルトの名無しさん：2010/06/23(水) 23:00:42

>>307-308

まさにGoのやり方．

312 ：デフォルトの名無しさん：2010/06/24(木) 08:09:14

コンパイルとリンクが別になってるのが既に時代遅れ

313 ：デフォルトの名無しさん：2010/06/24(木) 08:39:24

暗号化がデフォじゃないのもね

314 ：デフォルトの名無しさん：2010/06/24(木) 10:05:24

> 暗号化がデフォじゃないのもね
お前のプログラムがリバースエンジニアリングの対象になるわけねーだろ
思い上がるな

315 ：デフォルトの名無しさん：2010/06/24(木) 10:38:37

このスレはC++上級者の中でも更に次の規格について議論する人たちの集まりかと思っていたら、
上を目指すどころかコンピューターの仕組みも理解してない人多くね?

316 ：デフォルトの名無しさん：2010/06/24(木) 13:26:45

流石コンピューターおばあちゃんは言うことが違う

317 ：デフォルトの名無しさん：2010/06/24(木) 14:57:25

bool operator && (function<bool ()> reval);
こんな感じで右辺の評価が自動で関数オブジェクトになりshort circuitが可能になると思っていたのに自分でlambdaにしないと駄目なのか

318 ：デフォルトの名無しさん：2010/06/24(木) 21:38:20

initializer_listってどうなってんだ？
typedefしたらコンパイル通らなくなるし、配列のように振る舞うって聞いたのに代入したらベクターみたいに動作するし、[]の中に{}突っ込んでもエラー出るしでわけわからん

319 ：デフォルトの名無しさん：2010/06/24(木) 21:41:03

VC++2010か
まだ対応してないぞ
定義はあるけど

320 ：デフォルトの名無しさん：2010/06/24(木) 22:05:14

VC++2010は色々と残念

321 ：デフォルトの名無しさん：2010/06/24(木) 22:09:17

>>320
IDEは2008の改良でいいのにあちこち退化して残念

322 ：デフォルトの名無しさん：2010/06/24(木) 22:09:47

いやgcc4.5.0の話です

323 ：デフォルトの名無しさん：2010/06/24(木) 22:18:40

-std=c++0x(gnu++0x)付けた？

324 ：デフォルトの名無しさん：2010/06/24(木) 22:20:11

もちろん

325 ：デフォルトの名無しさん：2010/06/24(木) 22:21:59

gccの実装はまだ完全じゃないからな。
typedefはワケ分からんが、operator []は、まだ実装してない。
だいたい、initializer_listは配列のように振舞わない、どこで聞いたんだそんな話。

326 ：デフォルトの名無しさん：2010/06/24(木) 22:25:55

typedefが動かないバグは上がってないな。
報告しておいたら？

327 ：デフォルトの名無しさん：2010/06/24(木) 22:28:11

いや、配列のようにってのはここできいたんだがw

328 ：デフォルトの名無しさん：2010/06/24(木) 22:30:18

ネット上に出回る情報が全部正しい訳じゃないなんていつものこと

329 ：デフォルトの名無しさん：2010/06/24(木) 22:34:33

まあ、リスト初期化の構文自体は、素の配列や構造体を初期化する文法を、
ユーザー定義のクラスでも使えるようにしようというものだから、
その辺が伝聞が変化したのかも。

初期化リスト（initializer list）は、あたかも配列を初期化するように振舞う
↓
std::initializer_listは、あたかも配列のように振舞う

330 ：デフォルトの名無しさん：2010/06/24(木) 22:43:25

ラムダからinitializer listをreturnできるようにしてくださいよぉ

331 ：デフォルトの名無しさん：2010/06/24(木) 22:56:17

これじゃだめか？

[]() -> std::vector<int>
{
std::vector<int> v = {1,2,3} ;
return v ;
} ;

332 ：デフォルトの名無しさん：2010/06/24(木) 22:59:13

auto foo = []() -> std::vector<int> { return { 1, 2, 3 }; };

みたいにしたいんだけどねえ
普通の関数ではできるのに

何で禁止したんだろ
実装が難しいの？

333 ：デフォルトの名無しさん：2010/06/24(木) 23:05:10

ていうかそれでいいのなら、こういうことはできるがな。

[] { return std::vector<int>{1,2,3} ; } ;

334 ：デフォルトの名無しさん：2010/06/25(金) 07:17:43

returnが多いと面倒くさいけど
仕方がないのかねえ

335 ：デフォルトの名無しさん：2010/06/25(金) 08:19:46

おれ的には右辺値参照と可変長テンプレートとラムダだけで十分だった

336 ：デフォルトの名無しさん：2010/06/25(金) 09:09:48

conceptほしかった…

337 ：デフォルトの名無しさん：2010/06/25(金) 09:15:05

conceptは犠牲になったのだ……

338 ：デフォルトの名無しさん：2010/06/25(金) 09:30:03

0xの犠牲にな

339 ：デフォルトの名無しさん：2010/06/25(金) 10:11:30

最適化の為だけのキーワードが云々ほざいてる奴もいたが、俺はconstexprが好きだぜ。

340 ：デフォルトの名無しさん：2010/06/25(金) 11:53:17

それって最適化か？

341 ：デフォルトの名無しさん：2010/06/25(金) 19:24:21

332のコードは通るでしょ

342 ：デフォルトの名無しさん：2010/06/25(金) 22:16:39

constexprはTMPの道具でしょ

343 ：デフォルトの名無しさん：2010/06/26(土) 00:38:01

>>342
それだけじゃないよ

344 ：デフォルトの名無しさん：2010/06/27(日) 11:03:16

<unordered_set>で余分なバケツを削る方法はありませんか？
（<vector>でのいわゆるswap技法に対応するもの）

345 ：デフォルトの名無しさん：2010/06/27(日) 11:06:28

ん？swap技法使えないのか？

346 ：デフォルトの名無しさん：2010/06/27(日) 11:15:36

こんな感じです。（コピペできなくてすみません）

unordered_set<int> s;
for (i in 0...100) s.insert(i);
cout << s.bucket_count() << endl;
unordered_set<int>(s).swap(s);
cout << s.bucket_count() << endl;

> 199
> 199

347 ：デフォルトの名無しさん：2010/06/27(日) 11:18:30

unordered_set<int>(s).swap(s);
これだとsと同じコンテナとsの中身を交換という形になってしまうぞ。
vectorで同じことをしてもreserveされた領域は小さくなるだろうが、サイズは変わらない。

348 ：デフォルトの名無しさん：2010/06/27(日) 11:21:24

>>346
バケツとアイテム数は同じにはならないだろ。
１０００個挿入して９００個消してからやってみ

349 ：デフォルトの名無しさん：2010/06/27(日) 11:23:29

unordered_set<int>().swap(s);

350 ：デフォルトの名無しさん：2010/06/27(日) 11:24:03

s.empty()

351 ：デフォルトの名無しさん：2010/06/27(日) 11:24:55

>>350これはひどい

まあこのメンバ関数名もどうかと思うけど

352 ：デフォルトの名無しさん：2010/06/27(日) 11:27:01

わたし350だけど349したらs.empty()が真になるって言いたかったんだけど

353 ：350：2010/06/27(日) 11:29:12

みんなひどい！もうしらない！

354 ：デフォルトの名無しさん：2010/06/27(日) 11:30:05

やりたいことが伝わってなかったようで、申し訳ないです。
そもそもの目的は、
rehash(n)でバケツの数がn「以上」になってしまうのを
ちょうどnにしたいのです。

355 ：デフォルトの名無しさん：2010/06/27(日) 11:30:07

clearしても真にはなるでしょ、と

356 ：354：2010/06/27(日) 11:33:58

unordered_set<myclass>
になっていて、ハッシュ関数もユーザ定義しています。

357 ：デフォルトの名無しさん：2010/06/27(日) 11:34:16

>>354
ならないし、気にするな

358 ：354：2010/06/27(日) 11:38:24

>>357
やっぱ無理なんですか・・・。
別の目的に使うhackをしてたんだけど。残念です。

359 ：デフォルトの名無しさん：2010/06/27(日) 11:40:36

我流unodered_setを作ろう

360 ：デフォルトの名無しさん：2010/06/27(日) 11:42:59

>>359
そうだな、自分で作れば理由もわかるしな

361 ：354：2010/06/27(日) 11:43:51

ウェブ上で複数の人が「バケツへのアクセスが提供されてる理由が不明」、
と言っておられるようですが、歴史的な経緯って誰か知りませんか？

362 ：354：2010/06/27(日) 11:44:51

>> 359,360
CSの人じゃないので、
お手軽hackに走っちゃうんですよね・・・。
精進します。

363 ：デフォルトの名無しさん：2010/06/27(日) 11:48:29

>>361
どういう意図で言ってるのか解らんのでurl貼って。

364 ：デフォルトの名無しさん：2010/06/27(日) 11:51:41

>>361

http://www.google.co.jp/search?q=%22%83o%83P%83c%82%D6%82%CC%83A%83N%83Z%83X%82%AA%92%F1%8B%9F%82%B3%82%EA%82%C4%82%E9%97%9D%97R%82%AA%95s%96%BE%22

そんなことを言っている奴はいない。
なんでそういう嘘をつくんだよ？

365 ：354：2010/06/27(日) 11:55:12

http://cpplover.blogspot.com/2008/05/c0xunordered.html
あいまいな記憶ですけどここ以外にもあったような。

366 ：デフォルトの名無しさん：2010/06/27(日) 12:02:03

まあアクセスしたいこともあるだろう
ハッシュの性能評価とか

367 ：デフォルトの名無しさん：2010/06/27(日) 12:03:33

>>365
＞bucketの個数や容量、使用量を取得するメンバがあり、さらには、あるキーがどのbucketに属するかを取得するメンバもある
これだけ解ればハッシュをチューニングできるし、バケツにアクセスする必要ないだろう。
バケツへのアクセスを規定したら実装方法に制限を加えることになるから妥当じゃないのか。

368 ：デフォルトの名無しさん：2010/06/27(日) 19:14:31

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1456.html の G. Bucket Interface より
It's also useful to expose the bucket structure, for two reasons.
First, it lets users investigate how well their hash function performs: it lets them test how evenly elements are distributed within buckets,
and to look at the elements within a bucket to see if they have any common properties.
Second, if the iterators have an underlying segmented structure (as they do in existing singly linked list implementations),
algorithms that exploit that structure, with an explicit nested loop, can be more efficient than algorithms that view the elements as a flat range.

だそうだ

369 ：354：2010/06/27(日) 20:34:24

おぉ、ということは変な使い方しても怒られないのね。
わざわざ調べていただいて、ありがとうございました。

370 ：デフォルトの名無しさん：2010/06/27(日) 20:35:39

私も354ではありませんが勉強になりました。ありがとうございました。

371 ：デフォルトの名無しさん：2010/06/27(日) 20:35:50

俺漏れも

372 ：デフォルトの名無しさん：2010/06/29(火) 12:15:04

タプルはinit_listで初期化できないみたいですが、
こんなのを
my_tuple<int,int> tup={1,2};
自分でつくるとしたらどうするのがいいんですかね？
サイズの型チェックできなそうだし・・・。

373 ：デフォルトの名無しさん：2010/06/29(火) 18:31:03

型が全て同じという前提なら作れるだろうけど
そうでなければboost::anyで包むしか

374 ：デフォルトの名無しさん：2010/06/29(火) 20:37:31

てすと

375 ：デフォルトの名無しさん：2010/06/29(火) 20:49:20

>>372
ctor がexplicit でなければ uniform initialization が使えるはず

376 ：デフォルトの名無しさん：2010/06/29(火) 21:57:44

可変長テンプレートでコンストラクタ書いて{}で初期化したいって場合に
違う型が混ざってれば問題ないんだけどすべて同じ型だとイニリスになって定義してないとコンパイルエラー
納得いかないわ

377 ：デフォルトの名無しさん：2010/06/29(火) 22:46:04

>>376
もしあなたの処理系で std::tuple<int,int,int> t = {1, 2, 3}; でコンパイルエラーがでないなら、
あなたが何か勘違いしてるのだろう。

378 ：デフォルトの名無しさん：2010/06/29(火) 23:05:02

どういうこった？　素直に書くとこうなるが。

struct C
{
template < typename... Types >
C(Types... args) { }
} ;

int main()
{
C c = {1,2,3} ;
}

当然これは通る。
通らなければお前のコンパイラがマヌケなだけだが。

379 ：デフォルトの名無しさん：2010/06/29(火) 23:10:44

gcc5.0.0だが通らないぞ
まじマヌケだなこの糞コンパイラ

380 ：デフォルトの名無しさん：2010/06/29(火) 23:16:02

Comeau.Computing
の
Comeau C/C++
では通らないの？

381 ：デフォルトの名無しさん：2010/06/30(水) 05:23:06

gcc 5.0。
未来からタイムマシーンでやってきたのか？

382 ：デフォルトの名無しさん：2010/06/30(水) 08:36:29

gcc4.5.0ね間違えた

383 ：デフォルトの名無しさん：2010/06/30(水) 08:43:38

まあ、gccはあてにならんな。
ちなみに、4.6だと>>378は通る。

384 ：デフォルトの名無しさん：2010/06/30(水) 11:03:48

テンプレート関数のテンプレートで型を指定した場合にテンプレートの型が
ムーブコンストラクターを実装している場合に、その型のオブジェクトを返すとき戻り値をmove(　);で返して
その他の場合はNRVOを使うために普通に返す。
なんて事ができる？

385 ：デフォルトの名無しさん：2010/06/30(水) 11:35:10

普通に戻り値の型を非参照にして、return std::move(t)すりゃいいだろ。
それでRVOできなけりゃ、そりゃコンパイラがバカなだけだ。

386 ：デフォルトの名無しさん：2010/06/30(水) 11:59:08

戻り値の型を非参照にするって？？？

387 ：デフォルトの名無しさん：2010/06/30(水) 12:07:31

そのまんまの意味だよ。
参照ではないprvalueで返せばいい。

class C {} ;

C f() { C c ; return std::move(c) ; }

int main()
{
C c = f() ;// まともなコンパイラならRVOできる
}

388 ：デフォルトの名無しさん：2010/06/30(水) 12:40:21

悪いけど全く意味が分からない。
日本語でおｋ

389 ：デフォルトの名無しさん：2010/06/30(水) 13:18:57

正解かどうかはともかく言ってる意味は分かるだろ…
理解できる言語が日本語だけだと厳しいかもしれないがｗ

390 ：デフォルトの名無しさん：2010/07/01(木) 12:03:39

>>384
そもそも return move(....); がいらないだろ。 return ...; で同じことになるんじゃなかったっけ？

391 ：デフォルトの名無しさん：2010/07/01(木) 13:19:51

それもそうだ。

392 ：デフォルトの名無しさん：2010/07/01(木) 13:47:54

それは最適化じゃなくて必ずそうなるって決まりなの？

393 ：デフォルトの名無しさん：2010/07/01(木) 14:33:45

C++の標準規格には、必ず最適化せよという決まりは、まずないぞ。
Schemeの規格に、必ず末尾再帰の最適化をせよ、とあるのは、Schemeにとっては絶対に外せない根本的な概念だからなんだろうな。

ちなみに、return文の式は、コピーかムーブコンストラクターかのオーバーロード解決のためならば、
rvalueとして扱ってもいいことになっている。

394 ：デフォルトの名無しさん：2010/07/01(木) 21:01:28

「扱ってもいい」って何だよ…
returnの式はソースだけじゃtaxon決まらないのかよ
相変わらず気持ち悪い仕様だな

395 ：デフォルトの名無しさん：2010/07/02(金) 01:54:47

気持ち悪い=個人的に理解不能
ってだけの話

396 ：デフォルトの名無しさん：2010/07/02(金) 02:09:17

そうかなぁ
lvalueかrvalueかがunspecifiedな第4のvalue taxonが隠れてるって事じゃないの？
キモイよ

397 ：デフォルトの名無しさん：2010/07/02(金) 12:30:39

return move(....); がいらないってどういうことだよ？
無かったら一時オブジェクトにコピーするときコピーコンストラクターが
呼ばれてしまうとおもうがｗｗｗｗｗ

398 ：デフォルトの名無しさん：2010/07/02(金) 13:52:39

だから、rvalueとして扱っていいってことだよ。

return文の式は、関数の戻り値の型に変換される。
これが大前提の挙動。

このとき、コピー、ムーブコンストラクターの呼び出しを省略してもよい
これが、RVO(Return Value Optimization)と呼ばれるもの。

このとき、コピーかムーブかのコンストラクターのオーバーロード解決のために、
式をrvalueとみなしてもよい。（つまり、ムーブコンストラクターを呼べる）

どんな式でもというわけにはいかんが、どうせreturn文が評価されるということは、
その関数のブロックスコープを抜けるということであって、ローカル変数の寿命は終わる。
もし、式がローカル変数のlvalueだとしたら、ムーブしたっていいだろ、どうせすぐ死ぬんだから。

399 ：デフォルトの名無しさん：2010/07/02(金) 13:58:24

誰か規格をもってきてくれ……

400 ：デフォルトの名無しさん：2010/07/02(金) 14:00:29

>>398
机上の空論乙

401 ：デフォルトの名無しさん：2010/07/02(金) 14:22:26

まあ移植した時にどうなるかわからんのだし明示的に書けばいいじゃん

402 ：デフォルトの名無しさん：2010/07/02(金) 21:34:32

>398
「rvalue とみなしてもよい」ではなくて「まず rvalue とみなす」では？

403 ：デフォルトの名無しさん：2010/07/02(金) 22:02:21

N3092 の 12.8/34 には
「ある基準が満たされたときに "when certain criteria are met"，
RVO に相当する最適化をやっても良い "an implementation is allowed to...".
ごにょごにょ．
で， copy/move の省略は以下の状況で許される (...is permitted in the following circumstances)．
(以下，その条件が列挙されている)」
と書いてあって， N3092 の 12.8/35 には
「copy の省略のための基準(★)が満たされていて "when the criteria for elision of a copy operation are met"
コピーされようとしているオブジェクトが lvalue なら，
コピーのためのコンストラクタを選択するオーバーロード解決は "overload resolution to select the constructor for the copy"
まずコピーされようとしているそのオブジェクトが rvalue であるかのように実行される
"is first performed as if the object were designated by an rvalue"．」

★の基準は 12.8/34 に記述されている条件を指していると思われます．
で， 12.8/34 に列挙されている条件のうちの第1の bullet に書いてある内容から，
「return 文の式が，関数の戻り値型と (cv-qualification の違いを無視して) 同じ型の
non-volatile の自動オブジェクトの名前である場合」という条件の場合，
12.8/35 に書いてある挙動 (まず右辺値として扱ってみる) が発動すると思います．
(12.8/35 に書いてある挙動が発動することが許される，ではない)

404 ：デフォルトの名無しさん：2010/07/02(金) 22:12:04

え～っと，つまりまとめると，

12.8/34 には「ある条件下でコピーの省略 (いわゆる RVO) を行うことが*許される*．この条件の1つに
return 文に指定された式が戻り値と同じ型の左辺値自動オブジェクトの場合がある．」と書いてあって，
12.8/35 には「12.8/34 に示された条件下では，コピー元をまず右辺値とみなせ． (みなしても良い，ではない)」
と書いてあるように読めますがどうでしょうか？

405 ：デフォルトの名無しさん：2010/07/03(土) 01:38:18

おお本当だ。
コピーが省略出来る場合で、しかも省略しない場合は、まずムーブコンストラクターを優先的に使うんだな。

406 ：デフォルトの名無しさん：2010/07/03(土) 12:54:20

RVOもしらん馬鹿が一人紛れ込んだか

407 ：デフォルトの名無しさん：2010/07/04(日) 01:07:10

そんなことで勝ち誇れるなんて幸せですね
もしかしてオランダ在住ですか？

408 ：デフォルトの名無しさん：2010/07/04(日) 13:33:18

難しいな。例えば可視性が絡んだらどうなるんだろ？
例えば下のauto_ptr-ライクなコードはムーブコンストラクタ可能ならコンパイルできて、
コピーコンストラクタが呼ばれたり、RVOが採用される場合はコンパイルエラーになるの？
ちなみにVS2010だとムーブコンストラクタが呼ばれる。

class Foo {
public:
Foo() : ptr_(new int(3))　{
std::clog << "construct Foo()\n";
}
~Foo()　{
std::clog << "destruct Foo()\n";
delete ptr_;
}
Foo(Foo&& rhs) : ptr_(rhs.ptr_)　{
std::clog << "construct Foo() by move\n";
rhs.ptr_ = 0;
}
private:
Foo(const Foo& rhs);
Foo& operator=(const Foo&);
private:
int* ptr_;
};
Foo createFoo()　{
Foo f;
return f;
}

409 ：デフォルトの名無しさん：2010/07/04(日) 15:24:19

まずコピーが可能でなけりゃRVOは採用されない
ムーブが出来ない式ならコンパイルエラー
つーかunique_ptrに触れてみそ

410 ：デフォルトの名無しさん：2010/07/05(月) 13:48:20

規格なんてどうでも良い、
GCCで出来るか出来ないか
それだけが問題だろ。

411 ：デフォルトの名無しさん：2010/07/05(月) 15:52:25

規格も GCC もどうでも良い、
VCで出来るか出来ないか
それだけが問題さ。

412 ：デフォルトの名無しさん：2010/07/05(月) 16:38:48

実装なんていらない。
規格がどうなっているか。
それだけが問題なり。

413 ：デフォルトの名無しさん：2010/07/05(月) 17:31:20

実装がすべて。
委員会のメンバーは実装者/組織を代表している。
いかに自分たちの実装（に基づく規格）を通すか。
いかに自分たち（の実装に）不利な規格を落とすか。

だから日本からの提案は無いし（たまに）あっても通らない。
わかったかな？

414 ：デフォルトの名無しさん：2010/07/05(月) 17:54:48

つまらんレスだな
わかるか？

415 ：デフォルトの名無しさん：2010/07/05(月) 20:12:50

確かにお前のレスはつまらん

416 ：デフォルトの名無しさん：2010/07/05(月) 21:22:06

うわホントにつまらんこの人

417 ：デフォルトの名無しさん：2010/07/06(火) 12:57:30

http://channel9.msdn.com/shows/Going+Deep/C9-Lectures-Introduction-to-STL-with-Stephan-T-Lavavej/

Initializer ListとRange-base forが無い所為で残念なソースコード

418 ：デフォルトの名無しさん：2010/07/06(火) 14:29:11

initializer listはともかく、コンセプトなしのrange based forなんてまったく骨抜きで使い物になんねーよ。

419 ：デフォルトの名無しさん：2010/07/06(火) 14:31:34

c++2xにご期待ください

420 ：デフォルトの名無しさん：2010/07/06(火) 14:56:09

>>418
そこでrange仮想クラスを継承ですよ、継承。

421 ：デフォルトの名無しさん：2010/07/07(水) 10:36:09

今のところwindows環境でつかえる一番できのいい0xコンパイラーってどれですか？

422 ：デフォルトの名無しさん：2010/07/07(水) 12:22:42

知るかボケ

423 ：デフォルトの名無しさん：2010/07/07(水) 19:00:35

知っとけよアホ

424 ：デフォルトの名無しさん：2010/07/07(水) 21:10:31

自分で作れ。
もちろんconceptsも実装してだ。

425 ：デフォルトの名無しさん：2010/07/08(木) 00:51:06

C++0x以前に解決法があるのかもしれませんが、

template <class T, class P> class Base;
を次のように継承したい場合に
template <class T, template <class> class Q>
class Derived: Base<T,Q<T>> {
typedef Base<T,Q<T>> base;
}
長ったるいBase<T,Q<T>>を２度書くことになってしまいます。
うまい解決策はないでしょうか？

426 ：デフォルトの名無しさん：2010/07/08(木) 01:03:59

つ　ｄｅｆｉｎｅ

427 ：デフォルトの名無しさん：2010/07/08(木) 01:07:42

マクロはなしで・・・。

428 ：デフォルトの名無しさん：2010/07/08(木) 01:15:33

手元のModern C++を眺めるかぎり、
#define TLIST_2(T1,T2) Typelist<T1, TLIST_1(T2)>
とかしてますね・・・。

やっぱ無理か。

429 ：デフォルトの名無しさん：2010/07/08(木) 01:50:53

0xなら、usingで別名つければ少しは短くなりそうな。

430 ：デフォルトの名無しさん：2010/07/08(木) 01:55:25

template <class T, template <class> class Q, typename U = Q<T>>
class Derived2: Base<T, U> {
　　typedef Base<T, U> base;
};
とか

431 ：デフォルトの名無しさん：2010/07/08(木) 02:15:04

>>430
その手を使うなら↓ここまでやったほうがよくね？
template <class T, template <class> class Q, class BaseT = Base<T,Q<T> > >
class Derived: BaseT {
typedef BaseT base;
};

432 ：デフォルトの名無しさん：2010/07/08(木) 06:35:33

>>425

template <class T, template <class> class Q>
class Derived: Base<T,Q<T>> {
typedef Derived::Base base;
}

というかこれ、gccがおかしいんじゃねーかな。
Derivedにとって、Baseはinjected-class-nameだろ。

433 ：デフォルトの名無しさん：2010/07/08(木) 06:36:52

あーすまん、この場合、BaseはDependant Nameじゃないな。そりゃ無理だ。

434 ：425：2010/07/08(木) 13:58:25

各種ありがとうございました。

435 ：デフォルトの名無しさん：2010/07/08(木) 20:25:39

C++0xの0xってどういう意味？

436 ：デフォルトの名無しさん：2010/07/08(木) 20:28:31

xには0からF

437 ：デフォルトの名無しさん：2010/07/08(木) 20:29:45

>>435
西暦200x年、人類に(ry

438 ：デフォルトの名無しさん：2010/07/08(木) 20:58:21

一桁目だと誰が決めたのだろう
そう20x0だったんだよ！

439 ：デフォルトの名無しさん：2010/07/08(木) 21:20:27

時が未来へ進むと誰が決めたんだ

440 ：デフォルトの名無しさん：2010/07/08(木) 21:54:10

時代が

441 ：デフォルトの名無しさん：2010/07/08(木) 23:08:14

多分次ぎはc++0y

442 ：デフォルトの名無しさん：2010/07/08(木) 23:19:49

>>436 F でけりがつくんかい?
ハゲの論調だと 9 で終わりそうもないので 0...F みたいな感じだったが ...

443 ：デフォルトの名無しさん：2010/07/09(金) 02:30:57

バージョンの数字か何かが続くってことなのかな？
数字の範囲を超えそうなら36進数にでもして
桁を増やしていけばいいのに、なんで0xなんてわざわざつけたんだろう

444 ：デフォルトの名無しさん：2010/07/09(金) 18:19:31

今となっては信じ難いことだが
本当は2007年に完成する予定だったんだ

445 ：デフォルトの名無しさん：2010/07/09(金) 19:46:32

C++98だって、延びに延びていたがな。

446 ：デフォルトの名無しさん：2010/07/09(金) 21:22:26

xが何になろうと、右辺値参照とLambdaとautoが既に実装されてるから気にしない。一休み一休み

447 ：デフォルトの名無しさん：2010/07/09(金) 21:24:15

うんこドドンパ

448 ：デフォルトの名無しさん：2010/07/09(金) 21:44:33

>>447ですが、誤爆しました。すみません。

449 ：名無しさん＠そうだ選挙に行こう：2010/07/10(土) 06:26:44

わざとですね分かります

450 ：名無しさん＠そうだ選挙に行こう：2010/07/10(土) 16:56:52

イニリスの長さをコンパイル時に知りたいんだけどconstexprが実装されるのを待つしかないのか

451 ：名無しさん＠そうだ選挙に行こう：2010/07/10(土) 17:00:45

コンパイル時に分かるわけねーだろ。

452 ：名無しさん＠そうだ選挙に行こう：2010/07/11(日) 08:38:27

アトリビュートの構文に違和感を覚えたのは俺だけでいい

453 ：名無しさん＠そうだ選挙に行こう：2010/07/11(日) 09:47:28

どんな構文でもマクロよりはましだと悟った

キレイなC++なんてC++じゃないんだ！

454 ：デフォルトの名無しさん：2010/07/13(火) 17:13:47

パーサーが解析でないような構文を違和感のある構文っていうんだよ。

455 ：デフォルトの名無しさん：2010/07/13(火) 21:29:44

元々汚かったC++の文法規則がattribute-specifierだらけになってますます小汚くなった

456 ：デフォルトの名無しさん：2010/07/14(水) 12:34:04

C++0xの解説の本ありませんか？

457 ：デフォルトの名無しさん：2010/07/14(水) 12:40:12

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

458 ：デフォルトの名無しさん：2010/07/14(水) 17:01:40

本屋からC++関連の本が綺麗に消えたな
C++0xに向けて調整中か？

459 ：デフォルトの名無しさん：2010/07/14(水) 20:14:47

>>458
本屋がそんなこと把握してるのか・・・

460 ：デフォルトの名無しさん：2010/07/14(水) 20:38:03

本屋にはウェブ書籍のコーナーにAjax本、Java本コーナーにJavaScript本があるって印象しかないなあ

461 ：デフォルトの名無しさん：2010/07/15(木) 07:29:30

C++自体が消えたって可能性は考えないのか

462 ：デフォルトの名無しさん：2010/07/15(木) 09:47:51

もういいかげん拡張はあきらめて新しい言語作ればいいのに

463 ：デフォルトの名無しさん：2010/07/15(木) 21:05:28

そして生まれた言語の数々。

464 ：デフォルトの名無しさん：2010/07/15(木) 23:26:27

いっぱいあんだろ。
そのうちＪＡＶＡでＯＳ作るのが当たり前の時代とかもきちゃったりするぞ。

465 ：デフォルトの名無しさん：2010/07/15(木) 23:30:37

D最終形態にはあらゆる言語がひれ伏すぞ。

466 ：デフォルトの名無しさん：2010/07/15(木) 23:40:29

アルティメットD・・・
仮面ライダーにいたよ、そんな敵

467 ：デフォルトの名無しさん：2010/07/15(木) 23:52:10

>>464
と、言われて１０年たちましたね。

468 ：デフォルトの名無しさん：2010/07/16(金) 00:42:26

eclipseでOS作ればJAVA使ったことになるのさ

469 ：デフォルトの名無しさん：2010/07/16(金) 18:06:32

JavaでOSってどうやって書くの？
ブートローダで真っ先にJVM呼ぶの？
ハードウェアアクセスを全部JVM様にお願いして仲介してもらうの？
カーネルのメモリまで全部GCに支配されてんの？

ｵｴｯ

470 ：デフォルトの名無しさん：2010/07/16(金) 18:16:20

Javaのバイトコードをネイティブにデコードするプロセッサなんだろう。きっと。

471 ：デフォルトの名無しさん：2010/07/16(金) 18:59:50

>>469
こういう商業版はしってたが
http://en.wikipedia.org/wiki/JavaOS
http://en.wikipedia.org/wiki/SavaJe

オープンソースもいくつかあるね
http://en.wikipedia.org/wiki/JNode
http://en.wikipedia.org/wiki/JX_(operating_system)

472 ：デフォルトの名無しさん：2010/07/16(金) 19:14:20

ちょっと待ってほしい
もし仮にPCに電源投入すると
Javaインタープリターが起ち上るとするならば、
これもまたJavaOSと名乗ることを許されるのではないだろうか

473 ：デフォルトの名無しさん：2010/07/16(金) 19:28:29

そのインタプリタはCで書かれてるんですね
わかります

474 ：デフォルトの名無しさん：2010/07/16(金) 20:06:12

JavaをJavaで書けるようになってからだね。

475 ：デフォルトの名無しさん：2010/07/16(金) 22:41:08

Visual C++はVisual C++で作成されています。

ってVC++6.0のスプラッシュに書いてあった

476 ：デフォルトの名無しさん：2010/07/16(金) 23:08:41

>>469
SingularityっていうC#(の拡張言語)で書かれた似たようなOSの場合は
WindowsでいうHALはC++で書かれていてそれ以外の部分がC#になってた

>>470
なんか10年前に話だけは聞いたことあるけどどうなったんだろうなアレ

477 ：デフォルトの名無しさん：2010/07/16(金) 23:35:40

富士通とか携帯用プロセッサに乗っけてたな？

478 ：デフォルトの名無しさん：2010/07/17(土) 01:41:41

>>476
今のTexas InstrumentのARMプロセッサは多くが"Java Acceleration"
という機能を謳っているけど何なんだろう？

479 ：デフォルトの名無しさん：2010/07/17(土) 19:24:26

？

480 ：478：2010/07/17(土) 20:14:33

気になってたのでちょっと調べた。　ちゃんとコアのARMアーキテクチャ
で定義されてるんだ。

Java Technology Knowledge Article
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/kiRFU6S7H96L83.html

機能としてはほとんどのバイトコードを直接実行するDBX (Direct Bytecode eXecution) と
AOTやJITのコンパイル機能を補佐するRCT(Run-time Compilation Target)の２つになる。

ARMってすごいなあ。

481 ：デフォルトの名無しさん：2010/07/17(土) 20:22:57

D&E読んでるけどなんで既にconceptあるの

482 ：デフォルトの名無しさん：2010/07/17(土) 20:45:05

何も最近新しく出来た概念ってわけじゃない。
当時からアイディアはあったんだよ。

ちなみに、今とまったく同じautoは、すでに1982年に、C with Classesの一部として、禿によって実装されていた。
残念ながら、Cとの互換性の問題で、消さなければならなかったっけれど。

483 ：デフォルトの名無しさん：2010/07/17(土) 20:50:30

昔はCで組んでたけど、autoなんて使った記憶ないなあ。
消さなきゃ良かったのに。

484 ：デフォルトの名無しさん：2010/07/17(土) 21:06:15

元のautoを有効利用したことがある奴いるの？

485 ：デフォルトの名無しさん：2010/07/17(土) 21:14:35

>>484
auto
って何に使うの？

486 ：デフォルトの名無しさん：2010/07/17(土) 21:38:31

registerでないことを明示したい時に使う

void foo(){
int x;
&x;
}

こんなxを勝手にレジスタに置いてポインタが取れないと癇癪を起こしてたのさ
昔々のコンパイラは

487 ：485：2010/07/17(土) 21:41:08

元のauto、ね。
タイプ量を増やす以外の役割は？？

488 ：デフォルトの名無しさん：2010/07/17(土) 21:42:05

>>486
あ、ごめん、
> 昔々のコンパイラは
ね。
ってことは、途中で規格が改訂されて省略可能になったわけか。

ありがとうございます。

489 ：デフォルトの名無しさん：2010/07/18(日) 11:33:32

昔のコンパイラはレジスタ配置すら人力だったのか……

490 ：デフォルトの名無しさん：2010/07/18(日) 11:36:55

絶望した。

std::vector<int>& Get(){
return vec;//クラス内で宣言済み
}
上のようなメソッドが有って、

auto vec = hoge.Get();

ってやったら、ムーブかコピーだった。参照で受け取れるとおもったんだが。
で、結局

auto& vec = hoge.Get()

ってやったら意図通りになった。＠VC10

491 ：デフォルトの名無しさん：2010/07/18(日) 12:02:20

>>490 の通りが普通だと思ってたんだけど、
規格上の動作はVC10と違うの?

492 ：デフォルトの名無しさん：2010/07/18(日) 12:09:28

auto var = exp;はexpの評価されたTypeがvarの宣言/定義に使用される。
たとえhoge.Get()が参照を返したとしても、式中では参照のついたstd::vector<int>&ではなくstd::vector<int>として評価される。
これは0xに関係なく今の時点でもそう。
どうしてもと言いたければboost::refを使って式中の評価を参照修飾にする必要がある。

493 ：デフォルトの名無しさん：2010/07/18(日) 12:14:12

decltype

494 ：デフォルトの名無しさん：2010/07/18(日) 12:24:12

>>490
どこを困ってるかわからん

495 ：デフォルトの名無しさん：2010/07/18(日) 12:25:56

decltype((hoge.Get())) vec = hoge.Get()

496 ：デフォルトの名無しさん：2010/07/18(日) 12:27:31

#define BOOST_AUTO(E, F) decltype(E) F = E;

497 ：490：2010/07/18(日) 12:31:26

返信ありがと～。

>>491
いやー、俺の勘違いのようですよ。
戻り値の型を評価されるんだと思ってたので、＆取られるのは気づきにくいなーと。

>>492
詳細ありがとう。理解が深まって助かるよ。
厳密にboostのようなものが必要だったわけじゃないからいいんだけど、
知らなかったら、コストかかるわ、バグの元になってるわで、自分的には不味かったんだ。

>>493
decltype先生はタイプ量増えるから難しいね。

498 ：デフォルトの名無しさん：2010/07/18(日) 12:36:30

おっとっと。

>>494
最近はムーブされるから多少マシになったけど、その前はRVOか全コピーだからマズーって感じ？？

>>495-496
decltype先生は用途がむずかしいね。

499 ：デフォルトの名無しさん：2010/07/18(日) 12:56:32

decltype で書かなきゃいけないの? と思ってfcd読み返したら
auto& みたいな書き方でOKだったじゃないか。

>>495 みたいなのは、&で返ってくるときは&で、
値で返ってくるときは値で受け取りたいときに使うってことだね。

500 ：490：2010/07/18(日) 14:00:35

>>499
なるほど。

皆さんありがとう。ノシ

501 ：デフォルトの名無しさん：2010/07/18(日) 15:45:49

autoって互換性無くさなくてよくね？
今までだと
auto hoge h;
これからは
auto h = hoge();
だから別に構文は被ってないじゃん

502 ：デフォルトの名無しさん：2010/07/18(日) 16:08:05

型を省略したらintとかそんなのなかったっけ？

503 ：デフォルトの名無しさん：2010/07/18(日) 16:14:29

それはあまりにもフリーダム

504 ：デフォルトの名無しさん：2010/07/18(日) 16:15:25

>>502
Cの戻り値がそんなんだったような気が

505 ：デフォルトの名無しさん：2010/07/18(日) 16:17:11

まあ、いまだに残ってるんだよな。

unsigned x = 0 ;// unsigned int

506 ：デフォルトの名無しさん：2010/07/18(日) 20:08:10

いや、unsigned x; は型名省略じゃない

507 ：デフォルトの名無しさん：2010/07/18(日) 20:10:59

処理系の一番手ごろな型えらぶんだっけ？？

508 ：デフォルトの名無しさん：2010/07/18(日) 20:55:31

いや、unsigned/signed は unsigned int/signed int の別名だから。

509 ：デフォルトの名無しさん：2010/07/18(日) 20:59:05

signedなんて予約語あったっけ？

510 ：デフォルトの名無しさん：2010/07/18(日) 21:00:04

あるよ

511 ：デフォルトの名無しさん：2010/07/18(日) 21:04:04

static x; みたいな例の方がわかりやすい。

512 ：デフォルトの名無しさん：2010/07/18(日) 23:10:06

関数定義の戻り値省略とかも

513 ：207：2010/07/19(月) 21:30:00

すみません
gccで現在コンパイルがC++0xとして行われているか判別する方法はないでしょうか
事前定義マクロのようなものはないでしょうか？

514 ：デフォルトの名無しさん：2010/07/19(月) 21:31:19

auto a = test();とかやってみる

515 ：デフォルトの名無しさん：2010/07/19(月) 21:43:07

>>514
すみません．言葉が足りませんでした．
コード中で0xに対応していればstd::threadを
対応してなければboost::threadを使う
といった使い方をしたいのです．

516 ：デフォルトの名無しさん：2010/07/19(月) 21:47:26

#if __cplusplus > 199711L
でいいと思う

517 ：デフォルトの名無しさん：2010/07/19(月) 21:52:10

ありがとうございます．
試してみます．

518 ：デフォルトの名無しさん：2010/07/19(月) 21:58:47

__cplusplus
　　In C++0x the macro __cplusplus will be set to a value that differs from (is greater than) the current 199711L.
とのことで
#if __cplusplus != 199711L
少し不安ですがでいけました．ありがとうございました．

519 ：デフォルトの名無しさん：2010/07/19(月) 22:02:50

>>518
！＝は不適切じゃないか？

520 ：デフォルトの名無しさん：2010/07/19(月) 22:24:08

#if __cplusplus < 199711L
// 0x
#else
// boost
#endif

まだ少し不安ですがこうしてみました．
バージョンが新しいほど値が小さくなるのでしょうか
gcc version 4.4.3 で試しています．

521 ：デフォルトの名無しさん：2010/07/19(月) 22:26:01

>>520
制定日を示してる

522 ：デフォルトの名無しさん：2010/07/19(月) 22:28:55

greater than

523 ：デフォルトの名無しさん：2010/07/19(月) 22:32:22

>>521
なるほど

__cplusplusの値を見てみたのですが
　msvcでは199711Lでした
　gcc version 4.4.3では1でした

まだ制定されていないからでしょうか．
FAQにあるように，199711L以外としか決まってないのでしょうか
しょうが無いので1の場合は0xと見なして処理してみます．

524 ：デフォルトの名無しさん：2010/07/19(月) 22:33:23

いやgccは昔からずっと1にしてるぞ

525 ：デフォルトの名無しさん：2010/07/19(月) 22:36:39

なるほどそうだったのですか
とりあえずgccはコンパイラのバージョンを見て決めることにしてみます

526 ：デフォルトの名無しさん：2010/07/19(月) 22:42:52

gcc の場合 __GXX_EXPERIMENTAL_CXX0X__

527 ：デフォルトの名無しさん：2010/07/19(月) 22:46:42

_HAS_CPP0X とか、もうね（ry

528 ：デフォルトの名無しさん：2010/07/21(水) 19:28:23

>>527じゃダメなの？

529 ：デフォルトの名無しさん：2010/07/21(水) 22:41:59

_から始まるからだめ

530 ：デフォルトの名無しさん：2010/07/22(木) 19:12:44

コンパイラが定義する分にはいいんじゃね？

531 ：デフォルトの名無しさん：2010/07/22(木) 19:14:12

書いてて気持ち悪いからやだ

532 ：デフォルトの名無しさん：2010/07/23(金) 06:58:11

VS2010にThreadがないんだけど、まだ入ってないん？

533 ：デフォルトの名無しさん：2010/08/02(月) 15:24:30

あん…

534 ：デフォルトの名無しさん：2010/08/02(月) 21:37:46

ぱん…

535 ：デフォルトの名無しさん：2010/08/03(火) 00:21:21

まん・・・

536 ：デフォルトの名無しさん：2010/08/03(火) 00:30:21

あたらしい質問です

C++0xでは例外指定が消えただの何だのと聞いたんですが、
try-catchが消えるってことですか？

537 ：デフォルトの名無しさん：2010/08/03(火) 00:33:40

>>536
違う。

throw()のこと

538 ：デフォルトの名無しさん：2010/08/03(火) 01:54:09

finallyは欲しいところ

539 ：デフォルトの名無しさん：2010/08/03(火) 03:24:46

>>537
throwができなくなるor非推奨になるって認識で良いんでしょうか

540 ：デフォルトの名無しさん：2010/08/03(火) 03:34:37

>>539
関数の定義の際に、
int hoge() throw(なんとか) { ... }
という書式があったんだよ。

541 ：デフォルトの名無しさん：2010/08/03(火) 08:57:07

>>538
欲しいよね

542 ：デフォルトの名無しさん：2010/08/03(火) 10:11:19

>>538
今から追加するならいっそのこと D のスコープガードにしてほしい。
http://www.kmonos.net/alang/d/2.0/exception-safe.html
http://www.kmonos.net/alang/d/2.0/statement.html#ScopeGuardStatement

543 ：デフォルトの名無しさん：2010/08/03(火) 12:07:47

0xだとライブラリレベルのスコープガード実装で満足できる気がする

544 ：デフォルトの名無しさん：2010/08/03(火) 13:57:44

0を返すテンプレート関数 zero() を作るとします。
template< typename result_type > result_type zero() { return result_type(0); }

そして、関数テンプレートの特殊化で、それぞれの型にあわせたzero()をt作るとします。
template< > int zero< int >() { return 0; } // 例1
template< > float zero< float >() { return 0.0f; } // 例2
template< > double zero< double >() { return 0.0; } // 例3

ある特殊な数を表す special_value< value_type > クラスがあり、
special_value< int > や special_value< char > など無数に定義されているとします。

この special_value< value_type > に対し、zero() を定義したいのですが、
現状だと special_value の具体的なクラスひとつひとつに特殊化を定義しなければならず、大変手間です。
template< > special_value< int > zero< special_value< int > >() { return 0; } // <-これが無数に必要

出来れば、特殊化は special_value< value_type > ひとつだけにして、
尚且つ、zero()の呼び出しも簡素な形にしたいのです。
special_value< int > i = zero(); // <-理想
special_value< int > i = zero< special_value< int > >(); // <-現実　少なくともこれ以上、呼び出し文を複雑にしたくない

関数テンプレートの特殊化は少なく、呼び出しは簡素な良い方法はないでしょうか？

545 ：デフォルトの名無しさん：2010/08/03(火) 18:01:00

>544

struct {
template <typename T>
T operator()() const { return 0; }
} const zero = {};

546 ：デフォルトの名無しさん：2010/08/03(火) 18:46:30

>>545
どうもコンパイルエラーがでる…

struct {
　template <typename T> operator T () const { return 0; }
} const zero = {};

として、

　special_value<int> i = zero;

だと、OK だった。

547 ：デフォルトの名無しさん：2010/08/03(火) 18:52:24

>>545
>>546

結局、

　struct zero {
　　template <typename T> operator T () const { return 0; }
　};

とすれば、

　special_value< int > i = zero();

で、いける。

548 ：デフォルトの名無しさん：2010/08/03(火) 20:27:04

>>545-547
検証した結果、その方法で全てOKでした。
使わせてもらいます。ありがとうございました。

549 ：デフォルトの名無しさん：2010/08/04(水) 12:43:14

>>542
これは素晴らしい。惚れた
C++にこの構文を入れるプリプロセッサとかないものか

550 ：デフォルトの名無しさん：2010/08/04(水) 13:12:10

Boost.ScopeExit

551 ：デフォルトの名無しさん：2010/08/04(水) 18:58:10

>実際ソースコード上で視覚的に大きく離れてしまします。

素晴らしい日本語だな

552 ：デフォルトの名無しさん：2010/08/04(水) 19:02:28

boostだと表記が長ったらしくて嫌

553 ：デフォルトの名無しさん：2010/08/04(水) 19:54:13

最近のboostはPP厨すぎて付いていけない

554 ：デフォルトの名無しさん：2010/08/05(木) 12:47:03

test

555 ：デフォルトの名無しさん：2010/08/09(月) 19:03:39

本の話が出てこないな

556 ：デフォルトの名無しさん：2010/08/09(月) 20:34:50

魔導書？面白かったけど、なんか話題のネタになるようなのあったっけ？

557 ：デフォルトの名無しさん：2010/08/09(月) 21:01:08

このスレに出入りするような生粋にとっては特に目新しい情報なかったでしょ

558 ：デフォルトの名無しさん：2010/08/10(火) 07:04:31

ゲームスレでも開いたのかと思った

559 ：デフォルトの名無しさん：2010/08/10(火) 10:42:38

Variadic Templatesはケーススタディが微妙だった

560 ：デフォルトの名無しさん：2010/08/19(木) 16:52:53

0xおわったな・・・

561 ：デフォルトの名無しさん：2010/08/19(木) 17:18:57

始まってすらいねーよ

562 ：デフォルトの名無しさん：2010/08/19(木) 20:00:26

まずCスタイルキャストの廃止をだなry

563 ：デフォルトの名無しさん：2010/08/19(木) 22:50:13

>>562
そんな事したら、だれも使わなくなると思うんだな

564 ：デフォルトの名無しさん：2010/08/20(金) 08:36:22

じゃあ、Cスタイルのキャストをstatic_castと同じ意味にすれば

565 ：デフォルトの名無しさん：2010/08/20(金) 11:45:51

互換性パラノイアのC++に何を求めてるんだ

566 ：デフォルトの名無しさん：2010/08/20(金) 17:58:05

キャストは長たらしくて面倒なんだよなあ

567 ：デフォルトの名無しさん：2010/08/20(金) 20:03:46

Cスタイルキャスト便利だけど周知のとおりなんでも変形できちゃうからねぇ・・・。
最近はC++スタイルを使うように心がけてる。

568 ：デフォルトの名無しさん：2010/08/20(金) 20:36:12

signed ⇔ unsigned
signed ⇔ 浮動小数点数
共にリテラルなのに処理が違うのは変だと思う。

569 ：デフォルトの名無しさん：2010/08/21(土) 01:27:27

この言語は次世代を担う最強言語たりえるの？

570 ：デフォルトの名無しさん：2010/08/21(土) 01:47:09

最強かは知らないが、もともと使ってた人にはステップアップできるいい改良。
根っこは腐ってしまったが、周辺は良好。

571 ：デフォルトの名無しさん：2010/08/21(土) 02:24:40

>>566
むしろ面倒にしてあるからな

572 ：デフォルトの名無しさん：2010/08/21(土) 10:22:55

>>569
最強に難解になることは間違いないかな

573 ：デフォルトの名無しさん：2010/08/21(土) 10:26:33

拡張メンバ関数を導入するべきだ

.h
class hoge { int x; public: int y; void print_xy(); };

.cpp
namespace {
inline private void hoge::print_x() { cout << x << endl; } // privateならprivateに触れる。ただしprivateの拡張メンバか非拡張のメンバからしか呼べない
inline public void hoge::print_y() { cout << y << endl; } // publicならpublicにしか触れない、どこからでも呼べる
}
void hoge::print_xy() { print_x(); print_y(); }

こんな感じで
仕様変えたい時にメンバ増やしてもコンパイル依存性は変わらないから便利だろ
ヘッダもすっきりするしな

574 ：デフォルトの名無しさん：2010/08/21(土) 12:14:03

>>569
最強というか、そもそもC++が必要な領域では対抗できる言語が無いからね
Dはまだまだだし

575 ：デフォルトの名無しさん：2010/08/21(土) 16:41:50

>>573
それ何年も前の本(ピアソンとか)で
そんなもん非メンバ関数で実装すればいいだろ
って書かれてた気がする
コンパイル依存性を変えないなら仮想関数に適用できなくなるし
しかもその例だと非拡張メンバ関数から拡張メンバ関数を呼び出してて
なお一層気持ち悪い

576 ：デフォルトの名無しさん：2010/08/21(土) 16:54:34

非メンバ関数じゃprivateメンバーが見えないじゃん
なにかコードを追加しようとしたときに
そのコードがprivateメンバーを使ってて
さらに同じコードをなんども書く必要がある場合は
外部関数じゃできないんだからメンバー関数追加するじゃない普通
でもそのクラスをインクルードしてるファイルが死ぬほどたくさんあったらどうすんのよ

577 ：デフォルトの名無しさん：2010/08/21(土) 17:03:52

>>576
設計がおかしいからリファクタリングしろ。

それと、ここは 0x のスレだから、提案されてもない機能の話題はスレ違い。
俺の考えた最強言語の話は自分のブログでやってくれ。

578 ：デフォルトの名無しさん：2010/08/21(土) 20:01:14

>>576
そんな簡単にprivateに侵入されたらプライバシーもクソもないじゃない

579 ：デフォルトの名無しさん：2010/08/21(土) 20:40:42

#include <utility>

template <class... X> class Hoge
{
public:

void invoke(X... x)
{
func(x...);
}

template <class... Y> void t_invoke(Y &&... y)
{
func(std::forward<Y>(y)...);
}

private:

void func(X... x)
{
}
};

t_invokeのほうは無駄なく転送してくれそうなのですがinvokeのほうだとコピーコストが発生して困ります
かといって引数の型をX　&&...やconst X　&..に変更すると引数によってコンパイルエラーが出ます
そして引数の参照性やconst性の組み合わせを網羅してオーバーロードするのも可変長では無理ですしできても現実的じゃありません
何とかしてinvokeのほうでも無駄なコピーのない転送を実現したいんですがどうすればいいんでしょうか？
最終的にinvokeを関数ポインタにしたいのでどうしてもtemplateは使えないんです

580 ：デフォルトの名無しさん：2010/08/21(土) 20:46:13

>>579
const X　&で困るのってどんなとき？

581 ：579：2010/08/21(土) 21:16:43

あ、すいません自己解決しました
可変長引数にも普通にメタ関数使ってtypename foo<X>::type...って感じでコンパイル通るんですね

>>580
Hoge<int &>とかHoge<int &&>だとconst参照ではエラーがでますね

582 ：デフォルトの名無しさん：2010/08/22(日) 10:56:02

constexperでCRCやMD5とか計算できるようにならないかな？
30バイトぐらいでもかまいません

583 ：デフォルトの名無しさん：2010/08/22(日) 19:26:48

CRCならこんな感じで書けそう
確認はしていない

const uint64_t key = 0x104C11DB7;

constexpr uint32_t CRC32_subsub(uint64_t n, int b)
{
　return b==0 ?
　　n :
　　CRC32_sub( ( (n & 0x8000000000000000) ? n ^ (key<<31) : n) << 1, b-1);
}

constexpr uint32_t CRC32_sub(uint32_t head, uint32_t tail[], int tlen)
{
　return tlen==0 ?
　　head :
　　CRC32_sub( CRC32_subsub( ((uint64_t)*head<<32) | tail[0], 32), &tail[1], tlen-1);
}

constexpr uint32_t CRC32(uint32_t input[], int len)
{
　return CRC32_sub(input[0], &input[1], len-1);
}

584 ：デフォルトの名無しさん：2010/08/22(日) 21:32:09

今更だけど64ビット定数は嫌がらせのように長いな・・・

585 ：デフォルトの名無しさん：2010/08/22(日) 21:42:25

4096bit とかどうしようか

586 ：デフォルトの名無しさん：2010/08/22(日) 21:52:38

桁数間違えそうだわ

587 ：デフォルトの名無しさん：2010/08/22(日) 21:55:16

それもあってのconstexprなのかも

588 ：デフォルトの名無しさん：2010/08/22(日) 22:02:51

0x8000 0000 0000 0000
こう書けばよい

589 ：デフォルトの名無しさん：2010/08/22(日) 22:08:33

デバッガで追ってる時にポインタが
0x000000000485c77a
とか表示されるの拷問

590 ：デフォルトの名無しさん：2010/08/22(日) 22:29:19

>>588
0x\
8000\
0000\
0000\
0000\
0000\
0000\
0000\
0000\
0000\
0000\
0000\
0000\
0000\
0000\
0000\
0000\
8000\
0000\
0000\
0000\
0000\
0000\
0000\
0000\
0000\
0000\
0000\
0000\
やだよこんなの

591 ：デフォルトの名無しさん：2010/08/22(日) 22:58:37

CRCってこうやって計算してるのかぁ

592 ：デフォルトの名無しさん：2010/08/23(月) 03:06:11

ipv6みたいな短縮記法を使いたくなってくるよね。
0x80::01で0x8000000000000001になる的な。

593 ：デフォルトの名無しさん：2010/08/23(月) 03:12:10

ユーザ定義リテラルの出番か

594 ：デフォルトの名無しさん：2010/08/25(水) 01:51:35

void関数でreturnでvoidを返せるようにしましょうよ。

595 ：デフォルトの名無しさん：2010/08/25(水) 02:12:42

return ; de ok

596 ：デフォルトの名無しさん：2010/08/25(水) 02:14:44

>>594
現行の規格でも関数テンプレートならいけたはず。
何か具体的に通らなくて困ってるコードでもあるの？

597 ：デフォルトの名無しさん：2010/08/25(水) 02:29:37

>>594
何バイト長の値が返されるの？

598 ：デフォルトの名無しさん：2010/08/25(水) 15:15:08

>>490
この問題ですんごいはまってた。
そうか、仕様だったのか・・・

599 ：デフォルトの名無しさん：2010/08/25(水) 15:58:50

>>597
コンパイラ上にだけ存在する常にvoidしか入らない0バイト長の型とか?
理論上の存在意義は分からんでもないが現実に嬉しいかというと微妙だなぁ

600 ：デフォルトの名無しさん：2010/08/25(水) 16:19:18

void 型の値があることになったら、末尾呼出を常に return func(); と書けるな。

601 ：デフォルトの名無しさん：2010/08/25(水) 18:31:03

void型値が存在すれば加減算とかが発生しない限り代入や比較は可能で構わないわけだから
void型の返値を受け取ってvoid型の変数に格納してvoid型の引数を取る関数に渡すとか有りか

最終的に評価が発生するところだけvoid型で特殊化できるという意味で理論上の適応はあるな
誰が得するのか知らんが

602 ：デフォルトの名無しさん：2010/08/25(水) 22:07:59

sizeofが0の型はカオスを引き起こすからダメです

603 ：デフォルトの名無しさん：2010/08/25(水) 22:44:13

あー、0除算で死んだりするのか・・・。

604 ：デフォルトの名無しさん：2010/08/25(水) 22:50:38

コンパイル時定数なんだからソレは問題に成らんでしょ

605 ：デフォルトの名無しさん：2010/08/26(木) 01:34:13

コンパイル時定数を普通の変数に代入して使うこともあるわけで、問題なくなるわけがない。

606 ：デフォルトの名無しさん：2010/08/26(木) 01:40:03

関数は必ず、void func(int)だろうと何だろうと
何かしらの値を返す、
ただ、void型の場合はその値に意味なんてないですよ

ってんだと俺は勝手に思っていた。
そして、コンパイラがその値を参照しようとすると
コンパイルエラーになるようにしているんだと思っていた。

607 ：デフォルトの名無しさん：2010/08/26(木) 04:42:09

perl病

608 ：デフォルトの名無しさん：2010/08/27(金) 01:39:06

void func2();

void func()
{
return func2();
}

これができるとテンプレートとかでvoidだけ例外処理する必要なくなるので嬉しい。

609 ：デフォルトの名無しさん：2010/08/27(金) 08:33:23

それはもう出来るんじゃなかった？

610 ：デフォルトの名無しさん：2010/08/28(土) 02:32:30

早く言えよ！
すこしコードがすっきりしたぜ。

611 ：デフォルトの名無しさん：2010/08/28(土) 22:08:27

http://www.open-std.org/jtc1/sc22/wg21/
> News 2010-08-28: The 2010-07 post Rapperswil mailing is available
> News 2010-08-28: The C++ Standard Core Language Issues List (Revision 72) is available

612 ：デフォルトの名無しさん：2010/08/28(土) 22:11:46

最新ドラフトは N3126 ね。

> Added new issues 1091, 1092, ... and 1173.
３週間ほどで追加されすぎｗ

613 ：デフォルトの名無しさん：2010/08/29(日) 10:24:32

相変わらずJPのNBコメントは質が低いのう……

614 ：デフォルトの名無しさん：2010/08/29(日) 17:52:51

813さんが質の高いコメントを出していただけないため。

615 ：デフォルトの名無しさん：2010/08/29(日) 19:49:22

えらいロングパス出したな

616 ：デフォルトの名無しさん：2010/08/29(日) 22:26:08

ゴールラインを割りましたので
スローインから再開です

617 ：デフォルトの名無しさん：2010/08/30(月) 19:43:12

わしがC++0x校長【自粛】である
http://www.asahi.com/science/update/0830/TKY201008300162.html

618 ：デフォルトの名無しさん：2010/08/30(月) 19:59:37

結局継承関係もalignasも予約語になるんだな
attributeとは一体何だったのか

619 ：デフォルトの名無しさん：2010/08/30(月) 20:13:11

>>617
なんか見出しがgigazineだなw

620 ：デフォルトの名無しさん：2010/08/30(月) 21:54:19

禿って蔑称？愛称？敬称？

621 ：デフォルトの名無しさん：2010/08/30(月) 22:22:09

その全て

622 ：デフォルトの名無しさん：2010/08/30(月) 22:27:48

日本の在日禿＝蔑称
Bなんとかの禿＝尊称

623 ：デフォルトの名無しさん：2010/09/02(木) 03:06:04

std::unique_ptr<Type []>の知名度が低すぎる
　　　　　　　　　　　　 ~~

624 ：デフォルトの名無しさん：2010/09/02(木) 05:40:37

配列生成しても適当に開放してくれるの？？

625 ：デフォルトの名無しさん：2010/09/02(木) 08:14:47

そうだよ。 boost::scoped_array 相当だね。

626 ：デフォルトの名無しさん：2010/09/02(木) 08:23:39

おぉー。オペレータがどういう感じになってるか興味あるかも。
delete[] で両方開放できるんだっけ？？

627 ：デフォルトの名無しさん：2010/09/02(木) 08:35:39

delete[] しないためのものだろうに。何言ってるの？

628 ：デフォルトの名無しさん：2010/09/02(木) 09:14:36

あるぅぇ？？

629 ：デフォルトの名無しさん：2010/09/02(木) 10:47:24

default_deleteがT[]で特殊化されてるからか
なるほど

630 ：デフォルトの名無しさん：2010/09/02(木) 18:39:10

>>627
どう見てもお前が流れを理解してない

631 ：デフォルトの名無しさん：2010/09/02(木) 20:20:29

struct Hoge {
void swap(Hoge& rhs) {}
Hoge& operator=(Hoge&& rhs) {
swap(rhs);
}
上記のコードのように、右辺値参照である rhs を非const参照を受け取る swap に渡すことは仕様的に合法なのでしょうか？

632 ：デフォルトの名無しさん：2010/09/02(木) 21:22:39

https://connect.microsoft.com/VisualStudioJapan/feedback/details/584141/c-r-value-reference-move-semantics-ignored-from-optimized-code
やっぱC++標準化委員会のひとはいうことが違うな

633 ：デフォルトの名無しさん：2010/09/02(木) 21:58:29

>>632
何か変なこと言っている？？
> やっぱC++標準化委員会のひとはいうことが違うな

634 ：デフォルトの名無しさん：2010/09/02(木) 22:07:02

>>632
こんなんよく見つけるな。面白いねー。

635 ：デフォルトの名無しさん：2010/09/02(木) 22:12:45

つまんね
くだらない記事はるなよ

636 ：デフォルトの名無しさん：2010/09/04(土) 20:15:28

規格で許されていることをバグとして報告する輩にはもっと▽してやれ

637 ：デフォルトの名無しさん：2010/09/09(木) 16:43:35

C++相談室に0xに関する質問したので来て答えてくれませんか？
どうせ暇でしょ。

638 ：デフォルトの名無しさん：2010/09/09(木) 19:13:05

>>637
どれ？

639 ：デフォルトの名無しさん：2010/09/10(金) 08:07:07

>>637-638
http://hibari.2ch.net/test/read.cgi/tech/1280914463/473-478
http://hibari.2ch.net/test/read.cgi/tech/1280914463/500-501
http://hibari.2ch.net/test/read.cgi/tech/1280914463/568-582
http://hibari.2ch.net/test/read.cgi/tech/1280914463/590

640 ：デフォルトの名無しさん：2010/09/11(土) 01:21:27

>>637-639
つまり、これが C++0x なら通るのか？って話だね。

#include <cassert>
struct Boo
{
Boo() : b(111) {}
int b;
};
struct Foo
{
Boo boo;
int f;
};
Foo foo[100] = {0};
int main()
{
for (int i = 0; i < 100; ++i)
{
assert(foo[i].f == 0);
assert(foo[i].boo.b == 111);
}
return 0;
}

cygwin の g++ 4.3 だと、まだ initializer list の対応が入ってなくて試せない。

641 ：デフォルトの名無しさん：2010/09/11(土) 01:34:07

>>640
それは通らない。
なぜならば、Fooの最初のデータメンバーであるBooは、0では初期化できない。

Boo boo = 0 ; // エラー

よって、次の文もエラーとなる

Foo foo[100] = {0}; // エラー

これなら通る
Foo foo[100] = { } ;

642 ：デフォルトの名無しさん：2010/09/11(土) 01:37:20

そもそも、C++0x以前の話。
ttp://cpplover.blogspot.com/2010/09/aggregate.html

643 ：デフォルトの名無しさん：2010/09/11(土) 02:44:21

>>641
だよな。

↓こいつ何言ってるんだろう？
http://hibari.2ch.net/test/read.cgi/tech/1280914463/572

644 ：デフォルトの名無しさん：2010/09/11(土) 02:47:58

>>642
> MSVCは、「'A::b' : non-aggregates cannot be initialized with initializer list」などというエラーを吐く。
> これは、規格上間違っている。

これ、 C++2003 では正しいエラーだよね。

> この分では、C++0xの初期化リストの対応も、あまり期待できそうにはない。

まだ対応してないんなら、上記のエラーで当然だと思う。

645 ：デフォルトの名無しさん：2010/09/11(土) 10:31:43

Foo foo[100] = { Boo(), 0 };

646 ：デフォルトの名無しさん：2010/09/11(土) 11:10:42

template <class X> void forward_test(X && x)
{
func(forward<X>(x));
}

これをC++03でやろうとしたら
template <class X> void forward_test(X & x)
{

647 ：デフォルトの名無しさん：2010/09/11(土) 11:12:20

途中で送っちゃった

template <class X> void forward_test(X && x)
{
func(forward<X>(x));
}

これをC++03でやろうとしたら
template <class X> void forward_test(X & x)
{
func(x);
}

template <class X> void forward_test(X const & x)
{
func(x);
}

template <class X> void forward_test(X volatile & x)
{
func(x);
}

template <class X> void forward_test(X const volatile & x)
{
func(x);
}

見たいな感じで列挙するしかないの？

648 ：デフォルトの名無しさん：2010/09/11(土) 12:48:14

完全転送は右辺値参照でしか再現できないぞ

649 ：デフォルトの名無しさん：2010/09/11(土) 13:30:14

そんなことはない
boostにc++03でムーブするライブラリあるし
右辺値参照は単に書きやすさの問題

650 ：デフォルトの名無しさん：2010/09/11(土) 13:31:39

>>649 ムーブじゃなくて完全転送（ perfect forwarding ）の話だろう。

651 ：デフォルトの名無しさん：2010/09/11(土) 13:36:16

そもそも右辺値のないC++03なら>>647で最大効率じゃない？

652 ：デフォルトの名無しさん：2010/09/11(土) 13:55:51

なぜ03で再現したいのか

653 ：デフォルトの名無しさん：2010/09/11(土) 14:09:14

03で再現したくもない機能なんて0xにもいらないだろ？

654 ：デフォルトの名無しさん：2010/09/11(土) 21:04:06

>>647
const、volatile修飾で動作を変えないなら後ろの２つは要らないんじゃない?

655 ：654：2010/09/11(土) 21:06:38

2つじゃなくて3つ

656 ：デフォルトの名無しさん：2010/09/11(土) 21:24:12

３つ消したらテンポラリを受け取れないね

657 ：654：2010/09/12(日) 00:32:47

>>656
最初のテンプレートしかなければ
X const &
X volatile &
X const volatile &
全部最初のにマッチするでしょ？

658 ：デフォルトの名無しさん：2010/09/12(日) 01:04:05

forward_test(Hoge());
がとれないよ
どうもforward_test<Hoge>って認識されるっぽい

659 ：654：2010/09/12(日) 12:17:57

>>658
仰るとおりです。

660 ：デフォルトの名無しさん：2010/09/15(水) 09:20:51

Hoge()はprvalueだから、rvalueへのリファレンスでなければ取れない。
constなlvalueリファレンスでrvalueを束縛できるのが、そもそもおかしいんだよ。

661 ：デフォルトの名無しさん：2010/09/15(水) 13:27:26

rvalue/lvalueを理解してないやつがunique_ptr使ってコンパイル通らないとか言ってるの見ると笑える

662 ：デフォルトの名無しさん：2010/09/15(水) 14:54:51

>>661
君がそれで苦労したと言いたいのか？

レベル低すぎ

663 ：デフォルトの名無しさん：2010/09/15(水) 14:58:50

struct Foo
{
Bar bar;
Baz baz;
};

Foo foo;

Foo fooo(move(foo));

ってやった場合fooo.barとfooo.bazのコンストラクタは右辺値参照のやつが呼ばれるって決まってるの？

664 ：デフォルトの名無しさん：2010/09/15(水) 15:07:48

>>663
絶対呼ばれない

665 ：デフォルトの名無しさん：2010/09/15(水) 17:33:37

ということは、ちゃんとムーブコンストラクタのなかで各要素をmoveしてやるひつようがあるのね。

666 ：デフォルトの名無しさん：2010/09/15(水) 18:12:08

当然です

667 ：デフォルトの名無しさん：2010/09/15(水) 20:22:51

Bar, Bazがmove可能として
　Foo& operator=(Foo&&) = default;
とクラス定義中に書いとけばいいんじゃね?

668 ：デフォルトの名無しさん：2010/09/15(水) 20:47:56

デフォルトムーブが入ったから>>663でいいんじゃないの？

669 ：デフォルトの名無しさん：2010/09/15(水) 21:03:07

そのdefaultだとメンバ全部moveしてくれるの？

670 ：デフォルトの名無しさん：2010/09/16(木) 11:12:39

勝手にコード生成しない
explicit class Hoge;
構文があればいいのに

671 ：デフォルトの名無しさん：2010/09/16(木) 13:26:59

>>667-669
根本的なところから理解出来てない

あのね、無理して使わなくていいんだよ、お前らには無理

672 ：デフォルトの名無しさん：2010/09/16(木) 13:32:19

>>671
くだらないこといってる暇があったら質問に答えるなり解説するなりしたらどうなの？奴隷階級が生意気だよ

673 ：デフォルトの名無しさん：2010/09/16(木) 14:20:35

>>672
他人に言う前に、自問自答すればいいのに。
酔っぱらいが「酔っぱらいは嫌いだ」って言ってるのと同じだろｗ

674 ：デフォルトの名無しさん：2010/09/17(金) 09:53:29

12.8.10 節:
　ユーザー定義のコピーコンストラクタがなくて、
　かつムーブコンストラクタが暗黙にデリートされなければ、
　ムーブコンストラクタが暗黙に定義される。

12.8.17 節:
　暗黙のムーブコンストラクタは、メンバーごとにムーブを行う。

これだけ読むと >>669 は正しい気がする。

675 ：デフォルトの名無しさん：2010/09/17(金) 09:56:05

すまん。×定義 ○宣言

676 ：デフォルトの名無しさん：2010/09/17(金) 10:01:49

>暗黙にデリートされなければ暗黙に宣言される

明示的にデリートじゃないの？

677 ：デフォルトの名無しさん：2010/09/17(金) 11:08:35

>>676
多分↓のことだと思う＞暗黙にデリート
12.8.12 節: コピー/ムーブコンストラクタは(中略)の場合、デリートされる。

あと、デフォルトのムーブコンストラクタのみだと、
最終的には
　「スカラー型は組み込みの代入演算子で初期化される」 (12.8.17)
に行きつくので、コピーするのと結局変わらない。

678 ：デフォルトの名無しさん：2010/09/18(土) 22:27:30

extern templateってなんですかー！
exportとは違うんですか？
explicit instantationとも違うんですか？

全部ex.*で始まってて同じに見えます！！

679 ：デフォルトの名無しさん：2010/09/19(日) 00:51:13

extern template + explicit instantation = export

680 ：デフォルトの名無しさん：2010/09/19(日) 01:04:09

exportさんは死んだよ

681 ：デフォルトの名無しさん：2010/09/19(日) 01:14:44

exportのキーワードは開放されたのかな？？

682 ：デフォルトの名無しさん：2010/09/19(日) 01:16:30

The export keyword is unused but is reserved for future use.

683 ：デフォルトの名無しさん：2010/09/19(日) 01:43:00

残ってるのね。教えてくれてありがとう。

684 ：デフォルトの名無しさん：2010/09/19(日) 21:50:59

そういえば range-based for って enum では使いようがないね。

コンパイル時に enum の全要素はわかってるんだから
begin/end を適当に決定して内部的によろしくやってくれて
range-based for 文を使えるようにしてくれてもいいだろうと思わないでもない。
unroll も簡単にできるだろうし。ただ、型を直接置けないから
enum X {...}; とある場合、for (X x: X{}) とでもすればいいのかな。

685 ：デフォルトの名無しさん：2010/09/19(日) 22:12:51

禿含めC/C++の委員はenum大嫌いだからあまりenumの扱いに期待しない方がいい

686 ：デフォルトの名無しさん：2010/09/19(日) 23:27:24

enum classは？

687 ：デフォルトの名無しさん：2010/09/19(日) 23:29:07

enumなかったらフラグが使いにくくて大変じゃない

688 ：デフォルトの名無しさん：2010/09/19(日) 23:34:53

enumなかったら整数リテラルに名前を付けられないじゃない

689 ：デフォルトの名無しさん：2010/09/19(日) 23:39:55

K&Rに「あんまり要望がうるっせーから仕方なく適当に入れてやった。クソが」
みたいなことが書いてあったと思う

それを受けてD&Eにも「Cのenumがテキトーすぎてクソまみれなので、仕方なくC++で少しクソを拭うことになった。ちくしょう」みたいなことが書いてある
あと「どうせお前らが欲しいのはこれだろ→enum BOOL{FALSE,TRUE}。bool使え」とか

690 ：デフォルトの名無しさん：2010/09/19(日) 23:47:56

望まれてるのはenum classなんかじゃなくて、Pascal系の部分型も作れて集合も扱える列挙型か、
あるいは関数型言語のバリアントかと思うんだけど、どうしてこうなった

691 ：デフォルトの名無しさん：2010/09/20(月) 02:24:35

enumは不要
static な定数用に class を自分で定義すればいいだけ

692 ：デフォルトの名無しさん：2010/09/20(月) 02:30:24

それって、case部分に書けないだろ……

693 ：デフォルトの名無しさん：2010/09/20(月) 08:39:15

range-base for ってそういやVC10に入ってないよな
あるとかなり便利になると思うんだが
実装難しいのかな？

694 ：デフォルトの名無しさん：2010/09/20(月) 10:37:44

コンセプトの仕様が七転八倒してたから入れようが無かったんじゃないのかな？
おいらはBOOST_FOREACHをforeachに#defineして使ってる。カウンタ変数にautoも使えて便利でござる。

695 ：デフォルトの名無しさん：2010/09/20(月) 12:46:48

VC10を開発していた時には、まだコンセプトはドラフトに入ってたんだろう。
というかMSVCはC++コンパイラとして未来がないと思う。
どんなバグ報告をしようと、
「それは些細な問題だから、次のリリースでも直す予定はない」
ときたもんだ。

MSVCはもはや、C++コンパイラ界のIEみたいなもんだぜ。

696 ：デフォルトの名無しさん：2010/09/20(月) 12:55:41

ひとつのコンパイラ以外ついていけない言語になってしまうと、もはや規格の意味もなくなるけどね……

697 ：デフォルトの名無しさん：2010/09/20(月) 17:25:46

うっかり実装した結果、0xの仕様変更に合わせて次期バージョンで非互換が出るなんてことは、
商用コンパイラではなかなか難しいからなぁ。

698 ：デフォルトの名無しさん：2010/09/20(月) 17:38:12

誰がC++0xだといった。C++03すら壊滅的に酷いじゃないか。

699 ：デフォルトの名無しさん：2010/09/20(月) 18:21:58

c++03との仕様の乖離だったらスレチ

700 ：デフォルトの名無しさん：2010/09/20(月) 18:24:05

コンセプトが削除された理由がイマイチ分からない

どこかで、「コンセプトマップを書くのが面倒くさい」というような記事を読んだことがあるが、
そのあたりの詳細に詳しい人いる？

一般のプログラマも、コンセプトマップを書くことになるのは分かるのだが、
そのことが、コンセプトを規格から外す理由になった経緯が分からん。

だって、一般のプログラマは、そんなに頻繁にコンセプトマップ書くとは思えないから

701 ：デフォルトの名無しさん：2010/09/20(月) 18:32:25

そもそもコンセプトとはどうあるべきかって所で意見がまとまらなかったから見送られたから
書くのが面倒くさいからどうこうという浅い理由じゃないよ

702 ：デフォルトの名無しさん：2010/09/20(月) 18:42:04

0xの機能をふんだんに使ったconcept_checkingライブラリで妥協するしかないか
とはいうもののconcept_checkingだけでも十分便利だから期待はできそうか

703 ：デフォルトの名無しさん：2010/09/20(月) 19:04:49

boost concept checkは便利だわ。これを規格化できないかな。

704 ：デフォルトの名無しさん：2010/09/20(月) 19:26:52

>>693
一応VCは拡張 for each in があるよね?
0x に提案されてるのとちょっと文法違うけど

705 ：デフォルトの名無しさん：2010/09/20(月) 19:32:31

なにそのC#

706 ：デフォルトの名無しさん：2010/09/20(月) 19:38:25

>>704
Please don't use the non-Standard "for each" extension. It has nasty gotchas.

http://blogs.msdn.com/b/vcblog/archive/2010/07/02/video-introduction-to-the-stl-part-1.aspx

707 ：デフォルトの名無しさん：2010/09/20(月) 23:42:33

gotchaという自覚はあるんだな

708 ：デフォルトの名無しさん：2010/09/23(木) 16:43:42

>>695
そんなの昔からだ
VC6 ≒ IE6

709 ：デフォルトの名無しさん：2010/09/23(木) 20:52:46

03のコードってムーブコンストラクタを書き足さないと場合によってはバグる？
書いてない場合はムーブ禁止みたいなオプションないのかな

710 ：デフォルトの名無しさん：2010/09/23(木) 22:17:22

全メンバがムーブ可能なら勝手にムーブコンストラクタが作られる、ただしVC2010は(ry
禁止させるならX(X&&) = delete; ただしVC2010は（ry

711 ：デフォルトの名無しさん：2010/09/24(金) 00:02:18

こっちが何もしなければ、STLがバグってない限り大丈夫だろ。

デフォルトのムーブ動作はコピーすることだし、
コンストラクタ呼び出しが省略される条件もコピーコンストラクタと同じ。

712 ：デフォルトの名無しさん：2010/09/24(金) 00:58:34

ポインタメンバ変数はデフォルトムーブされるの？
デフォルトコピーされるのも考え物だけど

713 ：デフォルトの名無しさん：2010/09/24(金) 01:06:59

もちろん、ポインター、というかすべてのスカラー型もムーブされる。
ただし、その「ムーブ」とやらは、単に組み込みの代入演算子を呼び出すだけだが。
まあ、メンバーは、普通はポインターじゃなくて、unique_ptrで持つわな。

714 ：デフォルトの名無しさん：2010/09/24(金) 12:01:12

そんなこといちいち気にしてると禿るぞ

Bjarneの頭は必然だったわけか…

715 ：デフォルトの名無しさん：2010/09/24(金) 20:44:12

ムーブ可能なクラスは、必ずしもコピー可能とは限らない。
（例えばストリームクラスなど）

そこで質問ですが、

［コピー可能クラスの集合］ ⊂ ［ムーブ可能クラスの集合］
（つまり、コピー可能ならば、常にムーブ可能か）

ですか？それとも

［コピー可能クラスの集合］と［ムーブ可能クラスの集合］は無関係
（つまり、コピー可能性とムーブ可能性は無関係か）

ですか？

716 ：デフォルトの名無しさん：2010/09/24(金) 21:01:36

class X{
X(X&&) = delete;
X& operator=(const X&) = default
X(const X&) = default
};

717 ：715：2010/09/24(金) 22:24:18

>>716
そうですよね。ありがとうございました。

718 ：デフォルトの名無しさん：2010/09/24(金) 23:44:03

ムーブって理解できない俺がいるんだけど、
自分の設計する全クラスに用意しなくてもいいんだよね？

用意してやることで効率が改善されると考えられる自作クラスにのみ
用意してあげればいいんだよね？？

719 ：デフォルトの名無しさん：2010/09/24(金) 23:59:32

あと値渡しは出来るけどコピーは出来ないクラスもな（mutexとか）

720 ：デフォルトの名無しさん：2010/09/25(土) 12:58:46

効率なんてRVO/NRVOに任せてムーブOKコピーNGのクラスにだけ用意しとけばいいよ

721 ：デフォルトの名無しさん：2010/09/25(土) 13:06:39

既存クラスのほとんどはムーブNGコピーNGだろうけどな

722 ：デフォルトの名無しさん：2010/09/25(土) 13:07:08

んなわけねーだろカス

723 ：デフォルトの名無しさん：2010/09/25(土) 13:27:35

だってintやポインタのメンバを鬼のように持ってるクラスにとってはムーブもコピーと一緒だろ
ムーブも出来るのかもしれないけど禁止だね

724 ：デフォルトの名無しさん：2010/09/25(土) 13:30:26

pimpl使えカス

725 ：デフォルトの名無しさん：2010/09/25(土) 13:31:55

ぴんぷる！

726 ：デフォルトの名無しさん：2010/09/25(土) 13:56:36

ムーブのためにレガシーコードは全部pimplに書き直せって？青いなあ
理想も結構だけど、勝手に古いコード壊すなよ

727 ：デフォルトの名無しさん：2010/09/25(土) 15:36:43

>>726
テンプレートでラッパー作ればpimpl化なんて即終了ですよね
ひとつひとつ修正するとか笑わせないでくださいよｗｗｗ

728 ：デフォルトの名無しさん：2010/09/25(土) 15:47:50

>>721,723
バ　カ

729 ：デフォルトの名無しさん：2010/09/25(土) 15:53:02

std::type_infoのように、コピーもムーブもする必要のないクラスなら、
別にそれでいいんじゃね？
「既存クラスのほとんど」ってのは疑問だがな。

730 ：デフォルトの名無しさん：2010/09/25(土) 16:19:24

まあ３割くらいはコピー不要かも

731 ：デフォルトの名無しさん：2010/09/25(土) 18:23:16

>>723
ポインタを素で置いてるのはバグの元。unique_ptrやshared_ptrやboost::scoped_ptrを使おうぜ。
コピーやムーブの可否が自動的に適用されるよ

732 ：デフォルトの名無しさん：2010/09/25(土) 18:26:21

コードの芸術性からしたらポインターは生だろー
実用品を作ってる職業プログラマーはスマートポインターを使うべきだと思うけどね。

733 ：デフォルトの名無しさん：2010/09/25(土) 18:38:58

正直、ポインタ周りで厄介なバグだしたためしがないので
いまいちリッチなポインタ使う動機がない

734 ：デフォルトの名無しさん：2010/09/25(土) 18:39:07

でもshared_ptrではオーバースペックだしunique_ptrじゃ使いにくいってケースのが多いよね実際

735 ：デフォルトの名無しさん：2010/09/25(土) 18:40:14

C++から外に出ようとするとな

736 ：デフォルトの名無しさん：2010/09/25(土) 18:50:53

>>732
逆だろ。RAII こそ芸術。

737 ：デフォルトの名無しさん：2010/09/25(土) 19:08:31

確かに芸術だな
実用コードでは全く使い物にならないという意味で

738 ：デフォルトの名無しさん：2010/09/25(土) 19:11:01

RAII普通に良く使うけど

739 ：デフォルトの名無しさん：2010/09/25(土) 19:15:41

ちゃんとRAII適用していいか熟考した上で使うのはいいよ
何も考えずに解放が必要な物にホイホイ使ってるなら危なすぎるから今すぐ止めろ

740 ：デフォルトの名無しさん：2010/09/25(土) 19:19:36

解放っていうか、開始処理と終了処理がセットになってる物で
スコープ内の一時利用で済むような機能はリソース獲得関係なくRAIIにするでしょ。

741 ：デフォルトの名無しさん：2010/09/25(土) 19:20:25

開放が必要なものに使わない方が怖いだろアホか？

742 ：デフォルトの名無しさん：2010/09/25(土) 19:23:09

解放処理に失敗する可能性のあるものにはさすがに使わんでしょ

743 ：デフォルトの名無しさん：2010/09/25(土) 19:26:27

んなこと言ったらなんにも使えねーだろ

744 ：デフォルトの名無しさん：2010/09/25(土) 19:28:07

だから実用的には何にも使えないんだよ
RAIIは「リソース解放は絶対に失敗しない」という仮定に全面的に依存している
そして大抵のリアルなリソースはそうではない

けど「RAIIは素晴らしいからみんな使おう^^」とか言ってる無責任な本やwebの多くはそんなこと触れてない
そのせいで間違った利用が横行している
恐ろしい

745 ：デフォルトの名無しさん：2010/09/25(土) 19:30:24

開放に失敗したらキューに入れといてプログラム終了時に例外的に処理するんだよカス

746 ：デフォルトの名無しさん：2010/09/25(土) 19:32:05

リソースに使わんかったらええねん
お前ら、beginXXX() ～ endXXX() とかやるときあるだろ
そういうのに使えないか確認してみよう

747 ：デフォルトの名無しさん：2010/09/25(土) 19:33:20

そのendXXX()は戻り値持たないの？絶対に失敗しないの？
安易にRAIIを使う前に確認してみよう

748 ：デフォルトの名無しさん：2010/09/25(土) 19:34:16

外部要因に依存してなかったら失敗も糞もあらへん

749 ：デフォルトの名無しさん：2010/09/25(土) 19:34:47

>>745
ほう、そのプログラムは解放に失敗したファイルやロックを自分が終わるまで握り込むのか
はた迷惑なプログラムだな

750 ：デフォルトの名無しさん：2010/09/25(土) 19:37:31

間違ったRAIIをあろうことか標準ライブラリがやってるの有様だからなぁ
fstreamは万死に値する

751 ：デフォルトの名無しさん：2010/09/25(土) 19:41:56

>>749
お前の実行環境が分からんが
解放が失敗したリソースはどうすればいいんだ？
もう一度解放を試みるのか？

752 ：デフォルトの名無しさん：2010/09/25(土) 19:45:03

>>751
失敗の仕方次第だろ
戻り値やerrnoを見てしかるべき処置を執る
もう一度解放が必要かもしれないし、解放不要でそのまま正常系に戻れるかもしれないし、致命傷でプログラムを落とす必要があるかもしれない
実用的プログラムを謳うならそこまでちゃんとしないとね

753 ：デフォルトの名無しさん：2010/09/25(土) 19:46:46

終了処理が成功したかどうか確認しなくても良い機能ってわりとあるような。
それに失敗したときはassertする時って事わりと多くね。

754 ：デフォルトの名無しさん：2010/09/25(土) 19:56:34

0x関係無い
釣り乙
0xだとλがあるからscope exit風な処理もマクロで実装出来るね
と無理矢理0xに繋げるﾃｽﾄ

755 ：デフォルトの名無しさん：2010/09/25(土) 20:03:11

匿名テンプレート

756 ：デフォルトの名無しさん：2010/09/25(土) 22:15:35

RAIIを理解できないやつがRAIIを否定するんだよ

757 ：デフォルトの名無しさん：2010/09/26(日) 00:12:55

std::set_new_handlerみたいに
失敗時のハンドラを登録できるRAIIを用意すればいんじゃね？
失敗が怖いからRAIIを使わないってのは怖がりすぎな気が

hoge_ptr<T> hoge = ...;

hoge.set_handler([](){
// リソースの解放失敗時に呼び出される
});

758 ：デフォルトの名無しさん：2010/09/26(日) 00:42:08

アホだから相手にするな

759 ：デフォルトの名無しさん：2010/09/26(日) 00:42:29

>>753
そのための例外だね
>>757
例外のほうがすっきりすると思うよ。

760 ：デフォルトの名無しさん：2010/09/26(日) 00:53:09

>>757
RAII解放時のエラー処理の話なんだから例外使うとまずい。
デストラクタで例外はC++的にヤバすぎて使えない。
だからハンドラ作って処理させるという逃げの一手にしてるわけで

761 ：デフォルトの名無しさん：2010/09/26(日) 00:53:50

うおっとレス先間違えた
× >>757
○ >>759

762 ：デフォルトの名無しさん：2010/09/26(日) 00:57:03

エラーハンドラとかわざわざ構造を複雑にするだけじゃん
デリーターをラップしてその中で処理しろよ

763 ：デフォルトの名無しさん：2010/09/26(日) 01:05:32

RAIIはりソースの管理が本命だから、デストラクタ内例外はterminateかログして握りつぶす出よいんじゃないか？
リソース開放でエラーってヒープ破壊のようなクラッシュ直前のよっぽど異常な状態だろう。

764 ：デフォルトの名無しさん：2010/09/26(日) 01:07:14

>>762
あー確かにそのとおりだわ。
ハンドラ作るより素直だし良いコードになるね。
うーん何で思いつかなかったんだろ。自分の頭の硬さが嫌になるわ。

765 ：デフォルトの名無しさん：2010/09/26(日) 01:12:09

デストラクタで例外とか

766 ：デフォルトの名無しさん：2010/09/26(日) 01:14:59

>>763
ネットワーク越しのファイルとかみたいに
割と日常的にclose(というより正確にはclose時のflush)に失敗しそうなものがあるから困る。
しかも時間をおけば成功しそうだから下手に握りつぶすのも悪手な感じだし。

まぁそんなわけでリソース解放の失敗は別にレアケースではないよと。

767 ：デフォルトの名無しさん：2010/09/26(日) 01:21:25

みんななんでそんなクリティカルな所にRAII使うんだ

768 ：デフォルトの名無しさん：2010/09/26(日) 01:26:39

C++でRAII以外にどうやる？
で、そのRAII以外の方法はデストラクタに入れられない？

769 ：デフォルトの名無しさん：2010/09/26(日) 01:38:48

別に普通にデストラクタに書いていいよ
デストラクタでやるメリットはスコープ抜けるタイミングを気にしなくていいとこだかんね
デストラクタ内でリトライしてもいいし、ログってもいいし、無視してもいいし、アプリをアボンしてもいい
デストラクタの中で普段やってるリソース開放処理をやるだけ
ただし成功するまでリトライみたいな無限ループと例外だけは使ってはいけない

770 ：デフォルトの名無しさん：2010/09/26(日) 01:58:40

よくできたRAII用クラスは明示的解放用のメンバがあるだろ。
解放失敗がクリティカルだったり失敗することが多い状況では
そのメンバ使った明示的解放と失敗時の処理をすればいい。

そんなことシラネってやつが何も考えずにRAII使っても
リソース解放処理が自動で行われる(成否はともかく)という点で
生ポインタや生ハンドル使って解放忘れてリークおこすよりマシって話じゃないの。

771 ：デフォルトの名無しさん：2010/09/26(日) 02:12:03

それはよくできた設計ではないんだよ、本当は
明示的開放が用意されてるってことはdtorでの自動処理では問題が起こる可能性があるってこと
dtorでの開放は危険性がまだ残ったままなのに安全に処理しているような錯覚を生み出す
危険性を認知していないまま安全だと思い込むことはただのうっかりよりも恐ろしい（様々な分野で致命的な事故が起こる原因の多くは間違った安心感からだ）
本来ならばdtorでリソースの生死を判断して生きているならassertするべきなんだよね

772 ：デフォルトの名無しさん：2010/09/26(日) 02:14:48

assertの意味わかってる？
「表明」だよ

773 ：デフォルトの名無しさん：2010/09/26(日) 02:18:49

そうだよ
「適切な開放処理を経由している」って条件を表明してるんじゃん

774 ：デフォルトの名無しさん：2010/09/26(日) 05:43:18 BE:1260668467-2BP(0)

相変わらずここはレベルの低い話してるな

775 ：デフォルトの名無しさん：2010/09/26(日) 11:38:42

例外って本当に必要なんだろうか

776 ：デフォルトの名無しさん：2010/09/26(日) 11:43:33

newに失敗したらnullを返す方がいいのか

777 ：デフォルトの名無しさん：2010/09/26(日) 12:04:33

例外もパワフルすぎて使い方を誤ると酷いことになる機能だな。
入門書とかひたすら「便利でしょ！」みたいな感じだから、みんな勘違いしたままになる。

778 ：デフォルトの名無しさん：2010/09/26(日) 12:35:01

便利な機能を駆使して
落とし穴を巧妙に一生懸命
作ってるようなもんだよなあ

779 ：デフォルトの名無しさん：2010/09/26(日) 12:50:20

デストラクタで例外投げれない仕様が全部悪いんだ
何とかならないのか

780 ：デフォルトの名無しさん：2010/09/26(日) 12:53:11

被せるより生だろ
被せた方が安全かもしれないけど
後処理が出来てれば生の方が
気持ちいいし絶対生。

781 ：デフォルトの名無しさん：2010/09/26(日) 12:55:07

そして妊娠（リーク）へ……

782 ：デフォルトの名無しさん：2010/09/26(日) 12:58:50

>>779
例外巻き戻し中に例外を投げたときのエレガントな動作を定義してくれればデストラクタでの例外が可能になるよ。
デストラクタはリソース開放しかしないようにすれば例外投げる必要はなくなるんだよね。

783 ：デフォルトの名無しさん：2010/09/26(日) 13:11:19

またリソース解放は絶対失敗しないという思い込みか
失敗しないリソース解放なんてfreeとdeleteくらいだというのに

784 ：デフォルトの名無しさん：2010/09/26(日) 13:15:50

稀に失敗するからこその例外だろ
つまりRAIIと例外処理は相補的でC++の設計が理にかなってることを示している

785 ：デフォルトの名無しさん：2010/09/26(日) 13:17:21

deleteが失敗するのはヒープが破壊されてる常態だから考えなくても良いな

786 ：デフォルトの名無しさん：2010/09/26(日) 13:20:56

RAIIってなんて発生してるの？

ん、俺か？

俺は　雷ッ　だな

787 ：デフォルトの名無しさん：2010/09/26(日) 13:23:11

ラツー

788 ：デフォルトの名無しさん：2010/09/26(日) 17:22:22

リソース解放は絶対失敗しないという前提でRAII使いまくればいいよ。
現在大きな問題になってる解放忘れによるリークをなくすことが第一。
その後で解放失敗によるリークが無視できない問題になれば
ハードウェアやOSの設計レベルでのリソース管理法の見直しも含めて新たな手法が考案されるよ。

789 ：デフォルトの名無しさん：2010/09/26(日) 17:40:35

わざとポインターのデータを開放しない場合に間違って
ＲＡＩＩを使って開放されてしまう間違いも同等に起きるから
どっちもどっちとしか言わざるをえない。

790 ：デフォルトの名無しさん：2010/09/26(日) 17:43:15

>>789
解放しないクラスを作ればいいだけだろ

791 ：デフォルトの名無しさん：2010/09/26(日) 17:46:49

>>789
いやそれは設計がおかしいだろｗ

792 ：デフォルトの名無しさん：2010/09/26(日) 20:26:16

リソース解放に失敗するって、思いつかないのだが、例えば？
>>766が言ってるclose時のflushはリソース解放じゃないし。

793 ：デフォルトの名無しさん：2010/09/26(日) 20:42:51

close時の失敗として出てくるんだからそれはclose（リソース解放）の失敗だろ
792はファイル扱う時に常にflushしてからflushしないcloseをしてるの？

794 ：デフォルトの名無しさん：2010/09/26(日) 21:03:11

close()明示したらflushされるけどRAIIに任せたらflushされずに尻切れトンボになる、
ってのもどうなんだろうな？

795 ：デフォルトの名無しさん：2010/09/26(日) 21:09:05

そんなの解放のし忘れに比べれば些細なこと
RAIIを使わない理由にはならない

796 ：デフォルトの名無しさん：2010/09/26(日) 21:22:18

>>792
closeの失敗としてバッファの値を何らかの原因で書き出せなかった場合か?
こんなのOSが悪いんでC++の知ったことじゃない。例としてWinが時々出す遅延書き込みの失敗でシステムのイベントとして記録される。

それでもRAIIとしてはファイルハンドルを閉じてしまえば責任を果たしたことになるだろう。

797 ：デフォルトの名無しさん：2010/09/26(日) 21:22:54

>>793
I/Oエラーでflashに失敗しcloseがエラーを返した場合でもリソースは解放される。
少なくともリークは起こらない。
RAIIを使わないで信頼性／保守性の悪いコード書くよりは最後のデータをwrite
した後に明示的にflushするようにする方がマシだと思う。

798 ：デフォルトの名無しさん：2010/09/26(日) 21:30:37

>>794
おいらはclose明示すればファイルを残し、closeされずにデストラクトされたらファイルを消すようにしてる。
これなら例外で抜けてもごみは残らない。

799 ：デフォルトの名無しさん：2010/09/26(日) 21:30:53

RAII + 明示的に処理はダメなのか？
管理しなきゃいけないものが複数出てきたとき
RAIIなしじゃ面倒そう
それこそ保守性の悪いコードが出てきそう

800 ：デフォルトの名無しさん：2010/09/26(日) 21:32:50

>>799
>>798はそのRAII+明示処理の考え方。すっきりする。

801 ：デフォルトの名無しさん：2010/09/26(日) 21:55:49

>>796
大事なデータの書き損じを、RAIIだと検知できないからって正常系に戻しちゃっといて
「OSが悪い。C++の知ったことじゃない。ファイルハンドル閉じたから責任を果たした」ってか。

おー怖い。絶対に他人様が使うプログラム書くなよ。

802 ：デフォルトの名無しさん：2010/09/26(日) 22:14:01

>>801
遅延書き込みの失敗を受け取る方法を教えてくれ。

803 ：デフォルトの名無しさん：2010/09/26(日) 23:13:57

>>802
だから例外や返却値に頼るのでなくハンドラを渡してコールバックしてもらえとあれほど…？…誰も言ってないな

804 ：デフォルトの名無しさん：2010/09/26(日) 23:24:37

コールバックは処理が癒着するからイヤ

805 ：デフォルトの名無しさん：2010/09/26(日) 23:58:31

>>802
現在の処理進行度と結果を示してる何かをポーリングで監視。

806 ：デフォルトの名無しさん：2010/09/27(月) 00:04:32

>>801は遅延書き込みなんてウルトラ異常系までアプリ側で拾ってるのか・・・

807 ：デフォルトの名無しさん：2010/09/27(月) 04:39:42 BE:1080572494-2BP(0)

>>801
知ったか乙

808 ：デフォルトの名無しさん：2010/09/27(月) 05:29:27

まあ普段はどうでもいいけど、いざ拾わないといけないとなったときに拡張できる余地は欲しいよな。
Windowsとか遅延書き込みに反応するためのAPIまであるし。

809 ：デフォルトの名無しさん：2010/09/27(月) 10:03:43

>>796
趣味のプロブラムならそれでいい
商用ならクビ

810 ：デフォルトの名無しさん：2010/09/27(月) 11:49:32

コンパイラに備わってない機能を
無理やり実装しようとするのがそもそもの間違い
RAIIを使いたければJavaでもC#つかえばいい。

811 ：デフォルトの名無しさん：2010/09/27(月) 11:50:17

>>809
あなたならどのように実装する？

812 ：デフォルトの名無しさん：2010/09/27(月) 11:53:13

プログラムを書かないのがプロなんだよ

813 ：デフォルトの名無しさん：2010/09/27(月) 11:59:48

大体、日本人の癖にアメリカの合理主義に洗脳されて
なんでも実利主義でも儲け主義な企業がわるい。
日本人はもともと巧みで繊細な技術だから
無意味なところにもこだわるべき。

814 ：デフォルトの名無しさん：2010/09/27(月) 12:48:05

プログラミングなんぞに頼らずに
すべてを手作業にすべき。

815 ：デフォルトの名無しさん：2010/09/27(月) 13:47:05

これからの時代はプログラム言語作成言語という言語が出来て、
RAIIをオンにしたり構文の規則をカタマライズしたり
自分好みのプログラミング言語を作る時代に発展していくんだろうな。

816 ：デフォルトの名無しさん：2010/09/27(月) 13:49:58

>>810
こいつ最高にアホ

817 ：デフォルトの名無しさん：2010/09/27(月) 14:16:40

>>811
エラーが起きる可能性があることを前提すればよいだけの話
・正常に書き込めたかチェックする（使用した関数の戻り値とかのふざけた方法でなく）
・復旧できる仕組みを用意する
・バックアップを作成する
・データの保存は複数の系統で、重複して行う

趣味のプログラムなら「あららデータなくなっちゃた」で済むけど、
商用では絶対に許されないことだよ

818 ：デフォルトの名無しさん：2010/09/27(月) 14:21:38

>>817
つまり fstream の仕様はどうするべきだ（だった）と言うの？

現状の仕様でも、趣味のプログラムならデストラクタ任せで、商用で
データロスが許されないなら明示的に close() して戻り値チェックすれば
いいってことで、問題ないんじゃないの？

819 ：デフォルトの名無しさん：2010/09/27(月) 14:27:36

商用でもデータロストなんてよくあることだろWindows製品とか

820 ：デフォルトの名無しさん：2010/09/27(月) 14:28:13

Linuxで動くソフトもわりとロストするよね。

821 ：デフォルトの名無しさん：2010/09/27(月) 14:30:08

Linuxは自己責任だから

822 ：818：2010/09/27(月) 14:30:59

おっと fstream::close() は void だったか。 exceptions() を設定しとくか、
あとで fail() なり !good() なりでチェックするってことで。

823 ：デフォルトの名無しさん：2010/09/27(月) 14:34:42

ファイルを書き込んでから
読み込んで書き込んだデータと一致するか調べないと本当に
正常に書き込めたかは分からないよ？
それでもやるの？

824 ：デフォルトの名無しさん：2010/09/27(月) 14:36:28

チェックのための読み込みで失敗するかもしれない

825 ：デフォルトの名無しさん：2010/09/27(月) 14:43:56

>>821
windowsも自己責任だよ
契約書(だれも読まないけど)にちゃんと書いてある

826 ：デフォルトの名無しさん：2010/09/27(月) 14:48:53

>>823
printf だってちゃんと出力できたかどうかわからないのに
毎回戻り値ちゃんと見てるのか？

827 ：デフォルトの名無しさん：2010/09/27(月) 14:49:34

自己責任が嫌なら自分でＯＳをつくりＣＰＵをつくるしかないだろう。

828 ：デフォルトの名無しさん：2010/09/27(月) 14:52:22

>>825
どうみてもPL法違反だよな

829 ：デフォルトの名無しさん：2010/09/27(月) 14:53:56

自分以外誰も信じないで全て疑って掛かるというのが商用だからね

830 ：デフォルトの名無しさん：2010/09/27(月) 14:55:37

石橋を叩き壊して新しい橋を自分で作るというのが商用なんだろうね。

831 ：デフォルトの名無しさん：2010/09/27(月) 14:57:16

一番信じられないのは自分だよ

832 ：デフォルトの名無しさん：2010/09/27(月) 15:00:49

>>831気が合いますね！

833 ：デフォルトの名無しさん：2010/09/27(月) 15:57:26

>>823
そういうのが手間だからやらないとでも？

書き込んだはずのデーターが消失するんですよ？
事の重大性がわかってないんじゃない？

うちの会社なら君はクビだ

834 ：デフォルトの名無しさん：2010/09/27(月) 15:58:36

一生チェック作業やってろ

835 ：デフォルトの名無しさん：2010/09/27(月) 16:02:20

>>834
馬鹿？
人がやらなくていいようにプログラムがやるんだよ。

836 ：デフォルトの名無しさん：2010/09/27(月) 16:07:33

メモリに収まりきらないような大量のデータを書き込んだときはどうやって丸ごとチェックするの？

837 ：デフォルトの名無しさん：2010/09/27(月) 16:15:32

段階的にやればよくね？

838 ：デフォルトの名無しさん：2010/09/27(月) 16:18:18

>>837
ストリームとじた後に再読込して全体チェックしなきゃいけないんだから段階的にはできないでしょ

839 ：デフォルトの名無しさん：2010/09/27(月) 16:20:19

複数の系統で保存するって言ってるんだから
ハードディスクとハードディスクでチェックすればいいだろ。

840 ：デフォルトの名無しさん：2010/09/27(月) 16:29:09

0x の話じゃないよね。

841 ：デフォルトの名無しさん：2010/09/27(月) 16:47:26

板違い

842 ：デフォルトの名無しさん：2010/09/27(月) 17:08:43

C++で特に0xとか必要としてる分野って
商用アプリ、組み込み系特殊ハード、ゲーム屋くらいかと思ってたけど
そうでもないんか

趣味でWindowsでC++ってなんでそんな茨の道？とか思った

843 ：デフォルトの名無しさん：2010/09/27(月) 17:13:36

>>842
ちょっと前までC++でWINとかふつうだったけど、なにかんがえてるの？

844 ：デフォルトの名無しさん：2010/09/27(月) 18:16:32

うーんと、金と女かな・・・

845 ：デフォルトの名無しさん：2010/09/27(月) 18:17:30

残念でした、両方とも得られないでしょう。

846 ：デフォルトの名無しさん：2010/09/27(月) 18:26:53

>>840
shared_ptrの利用ポリシーにも関わってくるから全く無関係ではない

847 ：デフォルトの名無しさん：2010/09/27(月) 18:35:03

>>842
> 趣味でWindowsでC++ってなんでそんな茨の道？とか思った
俺は趣味だけど、
コンパイルできてネイティブコードが出力できたり
ライブラリが(外部のね)充実していたりと
最初に取り組んだ言語がCだったりと
いった理由でC++やってる。

でも0xで辟易している。
仕事じゃないからあんまり余暇をC++0xの勉強だけにつぶしたくないし。

848 ：デフォルトの名無しさん：2010/09/27(月) 18:36:49

>>847
0xはやれやれだぜってこと？

849 ：デフォルトの名無しさん：2010/09/27(月) 18:41:58

辟易したなら別に勉強しなくていいじゃない
0xコンパイラで03コードは（ほぼ）通るんだし
perlやpythonみたいに古いコードが壊されないのがC++のいい所

850 ：デフォルトの名無しさん：2010/09/27(月) 18:44:49

（ほぼ）というにはそれなりの根拠があってのことだろうなぁｗｗｗｗｗｗｗ

851 ：デフォルトの名無しさん：2010/09/27(月) 18:51:00

↑アホ

852 ：デフォルトの名無しさん：2010/09/27(月) 19:56:34

そりゃまあ、通らないの確定なところで、新しい予約語がそれまで使ってた識別子に被ったらとかあるしなあ。

853 ：デフォルトの名無しさん：2010/09/27(月) 19:58:43

あとわかりやすい所だと記憶クラス指定子のautoとexportだな

854 ：デフォルトの名無しさん：2010/09/27(月) 20:52:53

俺も趣味でC++やってるが、0xはかなり楽しいぞ。
特にラムダとSTLの相性の良さが癖になる。

855 ：デフォルトの名無しさん：2010/09/27(月) 21:38:47 BE:630334837-2BP(0)

>>833
どうやってチェックするのかまだわからないんだが。
ファイル読み込みAPIが正常に動作しているという保証がどこにある？

856 ：デフォルトの名無しさん：2010/09/27(月) 21:52:04

>>853
ほとんどの03コンパイラでexportは通らなかっただろう

857 ：デフォルトの名無しさん：2010/09/27(月) 23:11:18

>>855
書きこんで読み込めたからといってディスクに書かれているとは限らないしなぁ
833の回答が気になるｗ

858 ：デフォルトの名無しさん：2010/09/27(月) 23:28:31

ばーか釣りだよｗｗｗなにマジレスしてんのｗｗｗｗｗ

859 ：デフォルトの名無しさん：2010/09/27(月) 23:34:13

>>817とか見てると笑える

860 ：デフォルトの名無しさん：2010/09/27(月) 23:38:40

あほにそれ以上構うな

861 ：デフォルトの名無しさん：2010/09/28(火) 00:55:40

障害耐性スレチもいいとこだろ。本気で知りたいのか？

862 ：デフォルトの名無しさん：2010/09/28(火) 00:58:19

で、結論は？

863 ：デフォルトの名無しさん：2010/09/28(火) 01:02:47

素晴らしいものでも馬鹿が使うとだめになる

864 ：デフォルトの名無しさん：2010/09/28(火) 01:19:17

RAIIが使えるのはメモリかロックくらい
ファイルやデータベース接続をRAIIで管理したつもりになってる奴は今すぐやめなさい

865 ：デフォルトの名無しさん：2010/09/28(火) 01:22:20

煽ってる奴もわけわからんなあ。
APIがぶっ壊れてる(暴走してる？)ケースと、レアでも何でもちゃんとエラーが返ってきて
アプリ側で対応できるケースは全然別だろ？

866 ：デフォルトの名無しさん：2010/09/28(火) 01:25:42

そんなレアなエラーを返すOSが悪い(ｷﾘｯ

867 ：デフォルトの名無しさん：2010/09/28(火) 01:30:39

>>864
はいはい

868 ：デフォルトの名無しさん：2010/09/28(火) 01:33:08

例外安全とエラー処理の話を混ぜてどうしたいんだか

869 ：デフォルトの名無しさん：2010/09/28(火) 01:35:56

エラーを握り潰して「はいno-fail保証です例外安全です」とか勘弁してくれ

870 ：デフォルトの名無しさん：2010/09/28(火) 01:39:48

それならエラー処理をちゃんとやれ
で済むじゃん

871 ：デフォルトの名無しさん：2010/09/28(火) 01:41:21

エラーを握り潰すのが悪いって分かってるのにRAIIが悪いとか

872 ：デフォルトの名無しさん：2010/09/28(火) 01:46:35

解放エラーはRAIIじゃちゃんと出来ないと言うとるのに

873 ：デフォルトの名無しさん：2010/09/28(火) 01:59:39

出来るだろカスが

874 ：デフォルトの名無しさん：2010/09/28(火) 02:15:37

どうやって？
デストラクタ起動した時点でオブジェクトは壊れてるし、例外は当然投げれないんだぞ？
staticメンバとかerrnoとかバカなこと言うなよ

875 ：デフォルトの名無しさん：2010/09/28(火) 04:29:52

具体的なことを何も書かない馬鹿は放ってよし。

でもやり方としては>>757で既出な気がする。
そこでリトライ/中途半端な結果で諦める/ファイルを削除する/独自処理(バックアップから書き戻すetc)を
選べればよいのではなかろうか。
コールバックの中から例外投げられないのは辛そうだけど。

876 ：デフォルトの名無しさん：2010/09/28(火) 05:42:04

そもそも、ユーザーがリソースを解放するという処理は失敗すべきじゃないだろ。哲学的に。
失敗が許されるのは、無効なリソースを開放しようとしたときぐらいなものだ。

解放に失敗しても、やれることは皆無だし。
C++が、あらゆる場所で、デストラクターは失敗しないべきだという前提のもとに設計されているのも、当然だ。

それでも失敗するとしたら、それはリソースの解放以外の何かをやろうとしているせいだ。
同期処理では、すぐに処理が終わらないこと、
例えば、他のスレッドやプロセスとの同期やネットワーク越しなど何らかの環境依存の処理をもって、
失敗としているならば、非同期処理でやるべきだ。
例えば、ユーザーが解放処理をした時点で、スレッドやスレッドプールなどで、そのリソースを、いずれ解放するようにする。
少なくとも、解放処理をした時点で、リソースの解放は、ライブラリ（OSなどのシステムも含む）側が責任を持つべきで、
ユーザー側が責任をもつべきではない。

877 ：デフォルトの名無しさん：2010/09/28(火) 05:45:21

ユーザー側とライブラリ側の解放処理がごっちゃになっているから混乱するんだよ。
解放処理とは失敗すべきではない。
ユーザー側にとっての解放処理を、
ライブラリ側にとっても「解放」と呼ぶ必要はない。

878 ：デフォルトの名無しさん：2010/09/28(火) 05:50:33

いや、ディスクの容量が足りなくてetcで書き込めませんでしたー→バックアップから書き戻し、ぐらいは
アプリ側でできないと困るだろ……
ライブラリはバックアップのファイル名なんて知る訳ないし

879 ：デフォルトの名無しさん：2010/09/28(火) 05:59:33

その処理はデストラクターの中ではやれないのかな。

880 ：デフォルトの名無しさん：2010/09/28(火) 06:02:38

>>879
それがコールバック関数案だと思うんだが、バックアップからの書き戻し(大抵リネームだけだろうけど)すら
失敗する可能性があるんだよなあ。
そうするとどうしても外に例外を投げるなりしてユーザーにダイアログボックスを見せたい。

まあそこまで作り込むなら、デストラクタじゃなくてflushなりcloseを別関数にしろよ、ってのが正しいと思うw

881 ：デフォルトの名無しさん：2010/09/28(火) 06:14:26

ディスク Full をそこまで気にするなら RAII の哲学的に、先にファイルを確保してから書き込みするべきですね。
先にリソース確保、その後に使う。でしょ？

同様に、必要とされるメモリは事前に確保。少なくともデストラクタ実行時に発生する動的なメモリ確保は、コンストラクタ内で確保しておく。と。

882 ：デフォルトの名無しさん：2010/09/28(火) 06:16:28

本当にdisk fullを救わないといけないなら
closeを保証するブロックの内側にflushを保証する別のブロックをRAIIで作ればいいんじゃないの？

883 ：デフォルトの名無しさん：2010/09/28(火) 06:21:22

>>881は正論かもしれんが、
エラーハンドリングしたいときはデストラクタに任せず別関数を呼んでください、のほうが遥かに現実的だな……
大体スタックオーバーフローの可能性もある以上別の関数すら呼べないじゃん……

884 ：デフォルトの名無しさん：2010/09/28(火) 06:25:36

>>882
flushを保証するブロックで失敗したら、closeを保証するブロックを抜けた上で
(closeしないとファイルを消すこともできないので)
外側でなんかする、ということになると思うんだが、
closeを保証するブロックを抜ける手段として一番便利なのはどう考えても例外なので
flushがRAIIである必要は全くないと思う。普通のメンバ関数で充分。

885 ：デフォルトの名無しさん：2010/09/28(火) 06:27:40

失敗時にバックアップからの書き戻しとかするような仕様なら
テンポラリな名前でファイル書き込んで成功時にリネームするもんじゃね？

886 ：デフォルトの名無しさん：2010/09/28(火) 06:28:00

>>882
flush を保証するのに RAII 使ったら例外投げれないでしょ。

まとめると、
「 ofstream で書き込み終了したら close() 呼ばないと危ないよ」
で済む話を RAII のせいにしてわめいてるおかしな人が一人、
ってことでおｋ？

887 ：デフォルトの名無しさん：2010/09/28(火) 06:30:33

>>885
ああ、普通はその方が正しいな。
どっちにしろ失敗したファイルは消さないといけないけど

888 ：デフォルトの名無しさん：2010/09/28(火) 06:31:23

ああ、close後にサルベージしたいのか。じゃあflush保証は意味ないな

889 ：デフォルトの名無しさん：2010/09/28(火) 06:42:26

>>887
>>885のやり方でいいなら、closeはcloseでリソースリークが起こらないことだけ面倒見て
続行不能なIO例外が飛んできたら一律そこで一時ファイル削除すればいいんじゃないの？

890 ：デフォルトの名無しさん：2010/09/28(火) 06:49:00

>>889
いいよ。
でもデストラクタは例外飛ばせないので、やっぱりcloseは明示的に呼ぶことになるね。

あとまあ、ファイルのIDを維持したいとかハードリンクを維持したいとかリソースフォークを維持したいとかで
リネームによる解決ができない場合は時々あると思う

891 ：デフォルトの名無しさん：2010/09/28(火) 06:57:26

>>890
書き込み操作が全部終わった時点で手動でflushして失敗したら例外投げたらいいんじゃないの？

892 ：デフォルトの名無しさん：2010/09/28(火) 06:59:17

明示的に呼ぶのがcloseかflushのどっちかはこの際問題にされてないと思ったけど？

893 ：デフォルトの名無しさん：2010/09/28(火) 06:59:35

単にデストラクターの中で例外を使いたいだけなら、
つまり、デストラクターの外に例外を飛ばす必要がないのなら、
デストラクターの中でthreadをつくって、join()すればいいじゃん。

894 ：デフォルトの名無しさん：2010/09/28(火) 07:00:39

>>892
全然違う
closeは書き込み操作が成功しようが失敗しようが呼ばないといけない
flushはwriteしたいものが全部片付いた時だけ呼べばいい

895 ：デフォルトの名無しさん：2010/09/28(火) 07:11:49

>>893
えっ
単に外に飛ばさなければいいだけで、デストラクタの中で握りつぶす分には大丈夫と思ってたけど
もしかして違うのか……怖くなってきた

896 ：デフォルトの名無しさん：2010/09/28(火) 07:15:05

デストラクタ内で例外握りつぶすのがダメだったらほとんど何も出来ないな

897 ：デフォルトの名無しさん：2010/09/28(火) 07:27:57

>>894
ある程度書き込んだあとflush到達前に例外が飛んだ場合でなおかつdisk fullなら、
デストラクタ経由close経由flushがやっぱり失敗するんでどっちにしろ明示的に……と
書こうとしたが、この場合はもみ消していいのか。すまん。

898 ：デフォルトの名無しさん：2010/09/28(火) 07:32:52

例外の発生中に、新たな例外を投げることはできない。
デストラクターの中で例外を使うというのは、問題になる。
例外を投げた結果、デストラクターが実行されているとしたらどうなる？

struct S
{
~S()
{
try {
throw 0 ;
} catch(...) { }
}
} ;

void f()
{
S s ;
throw 0 ;
// sのデストラクターを呼び出す
}

この例では、S::~S()の外には例外を投げないものの、
すでに例外が発生しているので、デストラクター内のthrow文を実行した時点で、
例外が重複することになり、エラーとなる。

したがって、例外を投げたことによるデストラクターの実行ではない保証できる場合でしか、
デストラクターの中で、安全に例外を使うことはできない。

899 ：898：2010/09/28(火) 07:38:51

あ、間違ってた。中で握りつぶす文にはいいのか。

900 ：デフォルトの名無しさん：2010/09/28(火) 07:42:44

デストラクタの中で発生した例外は握りつぶさないと危険
あとの処理は誰かに任せる

901 ：デフォルトの名無しさん：2010/09/28(火) 07:58:37

>あとの処理は誰かに任せる
どうやって？
何を使えば伝えられるのか？

902 ：デフォルトの名無しさん：2010/09/28(火) 08:04:14

つか、おまえらの「議論」は極論の塊なのよ。
クリティカルなメモリマネージメントをしたければ、その例外ハンドラ用に「小さな」メモリマネージャを持つ。
とか、もっと簡単にコンストラクタで非常用メモリを確保しておいて、new / alloc でエラーが起きたら、
その非常用メモリを解放して最後の後始末をする。とかね。
ディスクも、システム用に「ちょっと」確保しておいて、最後のログはき出しようにそこを使うとか。

実装レベルではそれで十分だし、それ以上の対策なんて、どちらにしろできないだろ？
メモリゼロ、空き容量もゼロであと何ができる？

903 ：デフォルトの名無しさん：2010/09/28(火) 08:24:07

>>897
flush到達前に例外でたらスコープ抜ける際にcloseされてそのあとキャッチされて後始末
書き込み一通りエラー無しで通ったのにflush失敗した場合でも例外投げたらスコープ以下同文

904 ：デフォルトの名無しさん：2010/09/28(火) 08:26:26

>>898
デストラクタで例外を投げる可能性がある部分を実行するときは
std::uncaught_exception で例外中かどうか確認してからすべきでは
if( !std::uncaught_exception() ) throw 0; ﾄｶ

905 ：デフォルトの名無しさん：2010/09/28(火) 08:27:31

>>901
デストラクタにしろクローズ処理にしろ、そこまでに処理し忘れていたエラーは全て握り潰すのが基本
エラー拾いたいならそれより前でチェックして例外投げるなり回復処理するなりしなはれ

906 ：デフォルトの名無しさん：2010/09/28(火) 08:57:29

>>904
http://www.gotw.ca/gotw/047.htm
> 2. Consider the following code:
>
> T::~T() {
> if( !std::uncaught_exception() ) {
...
> Is this a good technique? Present arguments for and against.
>
> In short: No, ...

907 ：デフォルトの名無しさん：2010/09/28(火) 09:10:36

まーだやってんのかお前らも暇だねぇ

908 ：デフォルトの名無しさん：2010/09/28(火) 09:18:50

{

if(!r.close())
{
// エラー処理
}

}

なんて書くのはアホのする仕事

void Deleter(resource * pr)
{
if(!r->close())
{
// エラー処理(さっきと同じ)
}
}

{

resource r(..., Deleter());

}

って感じでRAII使って処理するのが仕事で使って良いコード
0xならラムダもあるからコーディングの手間も少ないし、
従来のスタイルと同等の柔軟性もあって、スコープガードとしても機能する
リソースの処理をリソース管理クラスの外に丸出しするなんて愚の骨頂でしょ

909 ：デフォルトの名無しさん：2010/09/28(火) 10:17:43

さっきからエラーを外側で処理しないといけないケースの話をしてるんだが

910 ：デフォルトの名無しさん：2010/09/28(火) 12:07:14

だからそれが間違ってるんだよ

911 ：デフォルトの名無しさん：2010/09/28(火) 13:37:33

まだ粘着の相手してんの？お前ら

912 ：デフォルトの名無しさん：2010/09/28(火) 13:49:44

>>911
分からないのなら口を挟まずスルーしろ

913 ：デフォルトの名無しさん：2010/09/28(火) 14:35:44

fj の malloc/free 論争なみにもっとやろうぜ

914 ：デフォルトの名無しさん：2010/09/28(火) 14:49:06

ここまでのまとめ

発端は>>737,739,742,744。要するに
『解放が必要なリソースを扱うときでも場合によってはRAIIを使わないと言う選択をするべきだ。
なぜならRAIIを使ってリソース解放をデストラクタに一任では解放失敗という事態に対処できないからだ。』
という意見が出る。

で反論。>>770,799とか
『RAII+明示的解放(と解放失敗した場合の処理)、で対処すればいい。RAIIを使うことを否定する意味はない。』

わかってる人にはこの時点で終了。

で、その流れから派生したが本質的でない
・解放処理に失敗したことをどう検知するかという話
・いまだに解放をデストラクタに一任する前提でされている話
・あくまでRAIIを使うべきではないときがあると主張する話
とかをいまだに続けている人がいる。

915 ：デフォルトの名無しさん：2010/09/28(火) 14:54:26

「みながわけんじ」みたいな老害が居るわけね

916 ：デフォルトの名無しさん：2010/09/28(火) 15:30:00

じゃなくて
RAII+明示的解放
は RAII ではない。
ってことでしょ？

917 ：デフォルトの名無しさん：2010/09/28(火) 15:41:45

RAIIってのは自分の欠は自分で拭くってことなんだよ

918 ：デフォルトの名無しさん：2010/09/28(火) 15:47:01

言い換えるとウォッシュレットを使わない人ってことですね。

919 ：デフォルトの名無しさん：2010/09/28(火) 15:48:27

0x関係なくないか?

920 ：デフォルトの名無しさん：2010/09/28(火) 15:50:28

C++0xにC++は含まれてるから
C++のことはC++0xのことでもあるとおもうが。

921 ：デフォルトの名無しさん：2010/09/28(火) 16:43:47

なんだその理屈

922 ：デフォルトの名無しさん：2010/09/28(火) 16:46:11

>>920ベン図に描いて説明してみろよｗ

923 ：847：2010/09/28(火) 17:27:54

>>848
> 0xはやれやれだぜってこと？
そう。
学生時代は落とし穴回避する俺sugeeeeモードでそれなりに
楽しくやれたんだが、そろそろ就職と資格勉強にあたり
あんまり時間も取れなくて、それなのに新しい仕様が
登場してきて勉強しなおしかぁ…って気が沈むんだ。

>>849
> 辟易したなら別に勉強しなくていいじゃない
ところがC++が楽しかった思い出が後ろ髪を引くんだよ。

> perlやpythonみたいに古いコードが壊されないのがC++のいい所
Python 2.x では最近習得し始めて、文字列処理するだけなら
圧倒的にこっちがメイン。
最近 3.x で非互換になっているらしいが先進的な機能は使ってない
(というか使えていない)のでまあ問題無い。

>>854
楽しいのか－。
もう学生気分は終わりだからなー。

924 ：デフォルトの名無しさん：2010/09/28(火) 17:30:31

長文乙ｗｗｗｗｗｗｗｗｗ

925 ：デフォルトの名無しさん：2010/09/28(火) 17:49:21

0x の新機能は大体糖衣構文なのだから、別に勉強しなおすって表現する程のものは無いぞ。
分からないものは使う必要は無い。

926 ：デフォルトの名無しさん：2010/09/28(火) 18:34:57

アセンブリを除けば、すべての言語はシンタックスシュガーであると言える。

927 ：デフォルトの名無しさん：2010/09/28(火) 18:35:35

高級言語なんてアセンブラのマクロから派生したもんだからな。

928 ：デフォルトの名無しさん：2010/09/28(火) 18:39:14

assembla でさえ machine language の syntax sugar なんだよな

929 ：デフォルトの名無しさん：2010/09/28(火) 18:46:58

もとはHEXだしね。
最近のIntelCPUなんかアセンブリ命令がさらにこまかい単位になるんだっけか？ｗ

930 ：デフォルトの名無しさん：2010/09/28(火) 18:56:48

マイクロopは別に新しい技術じゃないよ。てかスレチ

931 ：デフォルトの名無しさん：2010/09/28(火) 19:25:25

おまえら極論がすきだな～。

932 ：デフォルトの名無しさん：2010/09/28(火) 19:39:44

お前らシンタックスシュガーって言葉が大好きだな

933 ：デフォルトの名無しさん：2010/09/28(火) 20:48:35

μopとかPenIIの頃からじゃなかったっけか

934 ：デフォルトの名無しさん：2010/09/28(火) 20:55:18

構文糖衣A錠、医薬品です。

935 ：デフォルトの名無しさん：2010/09/28(火) 21:07:48

央退散良い薬です

936 ：デフォルトの名無しさん：2010/09/28(火) 21:24:02

正露丸糖衣Aを「正露丸トウ、イェー」だと思っていた僕の母

937 ：デフォルトの名無しさん：2010/09/28(火) 23:33:57

お前らもっと建設的な議論をしようぜ。
例えば、
Alternative representations（C++03でいうAlternative token）とか、
asm宣言とか、
vector<bool>とか。

938 ：デフォルトの名無しさん：2010/09/29(水) 00:04:17

結局そのままなんだよなvector<bool>

939 ：デフォルトの名無しさん：2010/09/29(水) 01:00:56

そのまま、というのが何を指すのかにも依るけど
vector<bool> は deprecated だし、その役目は dynamic_bitset に移譲
されていくことは確かな訳で

940 ：デフォルトの名無しさん：2010/09/29(水) 01:04:26

なんでvectorあんな仕様にしたんだろうな
標準化委員ってマヌケばっかなのか？

941 ：デフォルトの名無しさん：2010/09/29(水) 01:08:49

コンテナの要件を満たさないというのがどれだけヒドいことか当時は良く理解してなかった
まあ間抜けっちゃ間抜け

942 ：デフォルトの名無しさん：2010/09/29(水) 01:43:51

std::vector<bool>だけ
過去の物をどうにかして直せないのかな？

①過去との互換性を破棄する
②std::vector_container<T>というテンプレートを用意して、
　Tがboolで無い限りはstd::vector<T>と同じで
　Tがboolである場合はコンテナの要件を満たすようにするとか。
　(要するにboolでの特殊化をしない)

特に後者②の方法で解決できないのかな？？
そして今後は②を使う様推奨していくってのが良さそうなんだけど。
②の方式ってデメリットあるのかな？

教えて標準化委員会の人！！

943 ：デフォルトの名無しさん：2010/09/29(水) 02:48:58

boolの特殊化でvector<bool>のまともな実装と同等のコードを書かないといけない→新しいコンテナ丸ごと作るのと手間がほとんど変わらないのでめんどい

944 ：デフォルトの名無しさん：2010/09/29(水) 03:05:31

機種依存文字を平気で使える時代になったのはいつから？

945 ：デフォルトの名無しさん：2010/09/29(水) 03:07:18

vector<char>あたりのラッパー作るだけでいいんじゃないの？

946 ：デフォルトの名無しさん：2010/09/29(水) 03:14:42

個人的には使う人が便利なら右辺値云々含めて気合いで書き直すべきだと思うけど
vectorに関しては既にリリースしちゃったから互換性気にする人がいるんだろうな

947 ：デフォルトの名無しさん：2010/09/29(水) 04:30:42

当時の委員会を間抜けと言うならそのとき間抜けでない人間はいなかった。

まあこの期に及んでvector<bool>なんて最早全く使わないけどな。
サイズが問題ならbitsetがあるしそうでなければvector<int>で代用すればいい。

948 ：デフォルトの名無しさん：2010/09/29(水) 07:28:46

vector<bool>がdeprecatedってのは、0xの話じゃなくてユーザーの雰囲気的にってこと?
どっちにせよ面倒そうだから使わないようにしてるけど。

949 ：デフォルトの名無しさん：2010/09/29(水) 13:12:31

結局なんとなくもやもやしながらvector<int>やdeque<bool>を使うしかない

950 ：942：2010/09/29(水) 14:57:45

>>943
何を言っているのかわからんが、
別にboolを特殊化しないだけであとは既存のvectorのコピペでいいんだから
手間は全くかからないとおもうんだけど。

951 ：デフォルトの名無しさん：2010/09/29(水) 16:01:19

>>944
丸数字がUnicodeに入った時点で、時代遅れは我々になったのかもしれん

952 ：デフォルトの名無しさん：2010/09/30(木) 00:53:04

Macで普通に文字化けするっつーの＞丸文字
まあソフトとフォント？によるけど

953 ：デフォルトの名無しさん：2010/09/30(木) 01:13:58

そのソフトがアホなだけだろ。

954 ：デフォルトの名無しさん：2010/09/30(木) 03:13:57

windows以外はゼンブゴミでOK？

955 ：デフォルトの名無しさん：2010/09/30(木) 09:41:42

macワロタ
なに？人とは違う、おしゃれな私かっこいい、とか思ってんの？
中身のないマイナーOSは引っ込んでろよ

956 ：デフォルトの名無しさん：2010/09/30(木) 09:54:12

脳味噌の中身がないドザ黙れよ

957 ：デフォルトの名無しさん：2010/09/30(木) 11:24:06

単にNFCとNFDの差
WindowsもMacも両方対応が不完全

958 ：デフォルトの名無しさん：2010/09/30(木) 13:53:35

>>956
反論不能ｗ

959 ：デフォルトの名無しさん：2010/09/30(木) 14:23:51

つうか機種依存とか気にしてたらAA書けないし
実際機種の問題じゃなくて掲示板見るときの設定がオカシイってだけでしょ

960 ：デフォルトの名無しさん：2010/09/30(木) 14:24:59

>>957
丸付き数字なら、cp932とsjis-macで割り当ててるコードポイントが違うのが原因じゃねーかと思う。

961 ：デフォルトの名無しさん：2010/09/30(木) 14:33:25

①

962 ：デフォルトの名無しさん：2010/09/30(木) 19:07:36

勝手に引数を暗黙変換しない
void f(explicit bool);
という構文があればいいのに

963 ：デフォルトの名無しさん：2010/09/30(木) 19:10:30

お前センスあるな

964 ：デフォルトの名無しさん：2010/09/30(木) 19:35:59

>>962
なんかそれっぽいの無かったっけ？

自分でMyBoolってクラスを作って、
explicitコンストラクタで bool型だけを受け付けて、
void f(MyBool myb);内に入るとすぐMyBoolが格納しているbool値を放出して
受け取ってもらうってのはらめなの？

965 ：デフォルトの名無しさん：2010/09/30(木) 19:47:25

汚すぎる

966 ：デフォルトの名無しさん：2010/09/30(木) 19:56:17

>>965
ってことは一応可能って事？
自分で描いててこれじゃあんまり有用性無い気がしてきた。
大体
void f(true);
が通らないよねこれだと

967 ：デフォルトの名無しさん：2010/09/30(木) 21:08:00

void f(bool){ ... }
void f(...){ static_assert(false, "ダメよ♪"); }

968 ：デフォルトの名無しさん：2010/09/30(木) 21:11:34

>>967
それって通るコード？
0xって良くわかんない。

969 ：デフォルトの名無しさん：2010/09/30(木) 21:14:04

テンプレートじゃないとダメか。
void f(bool){ ... }
template <class T> void f(T const&){ static_assert(false, "らめぇー"); }

970 ：デフォルトの名無しさん：2010/09/30(木) 21:22:59

>>969
その場合、コンパイル時にトラップするだけのための関数を
エラーになるように定義するのも面倒なので

template <class T>
void f(T) = static_assert;

とでも書くと、コンパイラがエラーメッセージを出すようになっていればいいのに

971 ：デフォルトの名無しさん：2010/09/30(木) 21:25:55

メタプロ用の仕様もっとモリモリ拡張すればよかったのにね

これが実体化したらこれこれこうする～とか

972 ：デフォルトの名無しさん：2010/09/30(木) 21:29:07

Defaulted and Deleted Functionsがテンプレートでも使えるような気がしないか？

973 ：デフォルトの名無しさん：2010/09/30(木) 21:31:25

Defaultedはクラス以外で使い道ない。
Deletedにすると、boolの例だと逆にトラップ先が無くなって
何でもかんでもboolに集まってくることになる

974 ：デフォルトの名無しさん：2010/09/30(木) 21:38:03

暗黙の型変換はint←→longみたいなのも含めて全部なしにして、
C言語と互換性のある型変換は#include<implicit>みたいなのにすればいいのかな。

975 ：デフォルトの名無しさん：2010/09/30(木) 21:44:11

>>974
> C言語と互換性のある型変換は#include<implicit>みたいなのにすればいいのかな。
何を言っているんだ
#includeって何をしていると思っているんだ
#includeじゃなかったとしてもプリプロセッサレベルでどうやって解決しろと。

976 ：デフォルトの名無しさん：2010/09/30(木) 21:49:40

>>973
>Deletedにすると、boolの例だと逆にトラップ先が無くなって
>何でもかんでもboolに集まってくることになる

試してみたら、bool以外を弾いてくれてたよ。

hoge.cc: In function ‘int main(int, char**)’:
hoge.cc:3:26: error: deleted function ‘void f(T) [with T = int]’
hoge.cc:6:6: error: used here

hoge.cc
--
void f(bool){}
template<typename T>void f(T) = delete;

int main(int,char**){
f(1);
return 0;
}

977 ：デフォルトの名無しさん：2010/09/30(木) 21:51:25

>>975
中にはoperator int(long);みたいなのがたくさん入ってるのを考えてた。

978 ：972：2010/09/30(木) 21:56:47

てか
One can define a template with a deleted definition. Specialization and argument deduction occur as they would with a regular template function.
って書いてあるな

979 ：デフォルトの名無しさん：2010/09/30(木) 22:08:33

= default; はスペシャルファンクションだけって書いてあるけど、
= delete; はそういう制限ないんだね。

それに、
8.4.3.2 のノートを見る限り >>976 が正しいみたい。

980 ：デフォルトの名無しさん：2010/09/30(木) 22:15:59

とりあえず暗黙の型変換対策は
deleted関数でOKってことのようで

981 ：デフォルトの名無しさん：2010/09/30(木) 22:33:44

>>980
そうっぽいけど
誰か仕様書に基づき解説してくれ

教えて頭いい人！

982 ：デフォルトの名無しさん：2010/09/30(木) 22:36:42

そろそろ次スレだけど
この4ヶ月でなんか大きな動きあったっけ？

983 ：デフォルトの名無しさん：2010/09/30(木) 22:38:20

俺がVC++を見限ったことぐらいかな

984 ：デフォルトの名無しさん：2010/09/30(木) 22:41:49

VC++2010のパッケージ版が出たことぐらいかな

985 ：デフォルトの名無しさん：2010/09/30(木) 23:20:57

gccが、nullptr、range-based for、noexceptの一部、をサポートしたことぐらいか。

986 ：デフォルトの名無しさん：2010/09/30(木) 23:30:23

>>981
n3126 の中を delete で検索すると、「～できる」みたいな積極的な記述はないけど
言葉のはしばしから窺えることがある(★)。

8.4.3.2
デリートした関数を(暗黙にも明示的にも)参照するプログラムはエラー。
(中略)
関数がオーバーロードされてるときは、オーバーロード解決で選択されたときのみ参照される
　　★= delete; でオーバーロードできる。
　　★オーバーロード解決でデリートした関数が選ばれたときにエラー。

14.7.3
以下のものは、頭に template<> を付けて明示的に特殊化できる:
　・(削除→デリートされてない←削除)メンバ・非メンバ関数テンプレート
　・(後略)
　　★関数テンプレートも =delete; できる。
　　★=delete; した関数テンプレートも、明示的特殊化で使えるようにできる。

14.7.12
関数テンプレートを明示的に特殊化するときは、
そのときに inline を付けるか、もしくはデリートしたときのみインラインになる。
元のジェネリックなやつがインラインかどうかは関係ない。
　　★明示的特殊化で =delete; 可能。

987 ：986：2010/09/30(木) 23:49:54

あれ? 俺間違ってる?
explicit specializationは「宣言」だから、関数定義はできないのか。

じゃあ
× =delete; した関数テンプレートも、明示的特殊化で使えるようにできる。
× 明示的特殊化で =delete; 可能。
はウソだ。

988 ：デフォルトの名無しさん：2010/09/30(木) 23:56:14

というか何でお前ら、「関数のdeleted定義はメンバー関数に限る」みたいな誤解をしているんだ？
そんなこと、規格のどこにも書いていないじゃないか。
まあ、サンプルコードはメンバー関数の場合しか載っていないというのはあるがな。

989 ：デフォルトの名無しさん：2010/10/01(金) 00:03:05

>>988
「deletedな関数は呼び出すべき関数の探索対象にならない」という誤解をしている人はいたが、
「メンバ関数に限る」という誤解をしている人はいないように見える。

990 ：デフォルトの名無しさん：2010/10/01(金) 00:20:48

>>987
>じゃあ
>× =delete; した関数テンプレートも、明示的特殊化で使えるようにできる。
>× 明示的特殊化で =delete; 可能。
>はウソだ。

こういう話？
仕様は読んでないが、とりあえずgcc-4.5.1ではコンパイルを通った。

--
// deleteした関数テンプレートを明示的特殊化で使えるように
template<int>void f()=delete;
template<>void f<1>(){}

// 明示的特殊化でdelete
template<int>void g(){}
template<>void g<1>()=delete;

int main(int,char**){
f<1>();
g<0>();
return 0;
}

991 ：デフォルトの名無しさん：2010/10/01(金) 01:23:30

>>987 定義は宣言でもあるので、問題でしょ。

992 ：デフォルトの名無しさん：2010/10/01(金) 01:40:38

なんか皆がどのへんの理解に苦しんでいるのかがわからない。

関数のdeleted定義は、その名前のとおり、関数の定義である。
deleted定義によって定義された名前は、宣言以外の目的で使うことはできない。
使った場合はエラーとなる。
もちろん、関数呼び出しはできないし、未評価式の中でも使えない。

void f() = delete ;
void f() ; // OK、再宣言

int main()
{
　　f() ; // エラー、関数呼び出し
　　typedef decltype(f) * type = &f ; // エラー、decltypeの未評価式と、&演算子のオペランド
}

それ以外は、通常の関数の定義とまったく同じように振舞う。
もちろん、name lookupで見つかるし、テンプレートならばインスタンス化されるし、オーバーロード解決の際にも考慮される。
ただし、そうした結果として選ばれた名前が、deleted定義であった場合、その名前を使うとエラーとなる。

993 ：デフォルトの名無しさん：2010/10/01(金) 01:42:38

>>992
> なんか皆がどのへんの理解に苦しんでいるのかがわからない。
というかC++0xのカオス状態の規格を読んでも
いまいちぴんと来ないのだ。
単に俺がバカなだけかもしれんけど。

994 ：デフォルトの名無しさん：2010/10/01(金) 01:46:19

>>992
decltypeやsizeof中での使用を禁止してるのは何か深い理由があってのことですか？

995 ：デフォルトの名無しさん：2010/10/01(金) 05:03:46

>>994
さあ？
しかし、

void f() = delete ;

に対して、

f() ;

がエラーとなるのに、

typedef decltype( f() ) type ;

がエラーとならない、というのは、違和感がある。

996 ：デフォルトの名無しさん：2010/10/01(金) 07:15:01

次スレ
C++0x 11
ttp://hibari.2ch.net/test/read.cgi/tech/1285884294/

997 ：デフォルトの名無しさん：2010/10/01(金) 08:14:56

>>990,991
template <class T> void f(T){}
template <> void f<>(int){} //A
void f(int){} //B

A,Bの違いが判らなくなって血迷った。
f(1) は B、f<int>(1) は A だとか、そんなことだったっけ。

998 ：デフォルトの名無しさん：2010/10/01(金) 12:32:55

999 ：デフォルトの名無しさん：2010/10/01(金) 12:33:54

1000 ：小倉優子 ◆YUKOH0W58Q ：2010/10/01(金) 12:33:56

　　∧,,,∧　
　( 　・∀・)　1000ならジュースでも飲むか
　 (　　　)　
　　し─J　

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。