トップページ⇒tech
1001コメント246KB

C++0x 10

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん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/
0002デフォルトの名無しさん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/
0003デフォルトの名無しさん2010/06/01(火) 18:10:29
○禿
校長先生。
0004デフォルトの名無しさん2010/06/01(火) 19:17:12
0xになって記号の使い方が増えてますます気持ち悪い言語になったな
0005デフォルトの名無しさん2010/06/01(火) 19:49:12
C++学園の人々：0a年春の巻

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

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

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

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

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

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

○static_assertさん
暴走するtype_traitsさんとテンプレ部に振り回されて気苦労が絶えない。
姉貴はリリースコンパイルで逃げ出せるからいいよなーと愚痴りつつ仕事を真面目にこなす苦労人。
0006デフォルトの名無しさん2010/06/01(火) 19:50:04
○initializer_listさん
「ねえねえ配列さん、なんでコンストラクタさんと仲良くしないの？」「新入生が来たら仲良くするよ！」
定番と化しつつあるこのやりとりの繰り返しで過剰な期待が勝手に高まりつつある。
本人はあまり何も考えていない。

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

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

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

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

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

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

○Raw String Literalさん
「お前全然Rawじゃねえじゃん」という状況は、トライグラフさんが譲る形で解決しつつある。
ちなみにトライグラフさんはしぶとく落第を免れ続けてるらしい。
0007デフォルトの名無しさん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さん達と一緒に弁当を食べようとしたら断られた。
0008デフォルトの名無しさん2010/06/01(火) 19:51:52
○attributeさん
他の学校に、かならず一人はいる娘なので、学校側としても、しかたなく、入校させた。
服のセンスが、lambdaさんに負けず劣らず、相当悪い。
lambdaさんと、かぶっている帽子が、見る角度によっては、似ていることがあり、少々問題になっている。
lambdaさんとの区別は、帽子以外で判断すべきだと叫ばれている。

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

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

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


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

○Exception specificationさん
進級できなかったが、彼女の産んだ、まだ一歳にもならない赤ちゃんが、いきなり入校してきた。
0009デフォルトの名無しさん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さんと仲が良いらしい。
0010デフォルトの名無しさん2010/06/01(火) 19:58:54
> ○コンセプトさん（幽霊）
0xスレ1か2くらいで「直ぐに実装できる」って言われてたのになんでこんな酷い事になってんの？
0011デフォルトの名無しさん2010/06/01(火) 20:12:36
○Blocksさん
0012デフォルトの名無しさん2010/06/01(火) 20:22:23
○Blocksさん
遠く青森で林檎に囲まれて育ったラムダさんの親戚。帽子が特徴的。
0013デフォルトの名無しさん2010/06/01(火) 20:37:16
なぜラムダ一族はおかしな帽子を被りたがるのか
0014デフォルトの名無しさん2010/06/01(火) 20:52:57
attributeって、新しい記号を導入しちゃだめなのかな
どうせtrigraphあるから、入力できない環境を作る事もないだろうし
0015デフォルトの名無しさん2010/06/01(火) 20:54:53
○Blocksさん
青森の林檎農家が付属小学校への裏口入学を試みているラムダさんの親戚。
とても気難しく、隣の部屋に行くにも「ぶろっくこぴー」という赤絨毯を要求する箱入り娘。
0016デフォルトの名無しさん2010/06/02(水) 14:21:46
もう2010年なんだから、そろそろC++ 1xでいいと思うんだが。
0017デフォルトの名無しさん2010/06/02(水) 15:32:11
stroustorup先生が00年代に0xと言ってしまったので
0018デフォルトの名無しさん2010/06/02(水) 17:23:49
C++1x 0 でも良かったか
0019デフォルトの名無しさん2010/06/02(水) 18:49:24
スレタイはC++0x0Aになると思ってた
0020デフォルトの名無しさん2010/06/02(水) 19:14:24
校長先生がC++0xのままでいくと言ったから
C++0xのままでおk
C++0x A あたりになるとは俺も思ったのだが
まあどうでもいい
0021デフォルトの名無しさん2010/06/03(木) 01:14:43
そろそろ#include棄てたいんだけどどうにかなるような話はなきや？
0022デフォルトの名無しさん2010/06/03(木) 01:15:58
boost.ppが死ぬのでなきや
0023デフォルトの名無しさん2010/06/03(木) 10:57:52
ラムダって関数ポインタにできないのか？
0024デフォルトの名無しさん2010/06/03(木) 13:48:54
template関数でラップしてそのポインタを取ればできる
0025デフォルトの名無しさん2010/06/03(木) 14:24:12
captureの無いλは関数へのポインタに変換出来るようにするという
提案があったと思うよ。
0026デフォルトの名無しさん2010/06/03(木) 18:49:07
captureがないやつだけか
まあそうだろうな
0027デフォルトの名無しさん2010/06/04(金) 20:24:32
むしろPreprocessorはもっと勢力拡張すべき。
0028デフォルトの名無しさん2010/06/04(金) 20:37:50
> ○__VA_ARGS__さん
> クラス分けで、プリプロセッサ組に通うことになった娘。
> プリプロセッサ組は、落ちこぼれだとも、最強だともいわれている、変わったクラス。
> その外見はあまりにもブサイクだが、密かにファンもいるらしい。

そう、これだ。

0029デフォルトの名無しさん2010/06/04(金) 22:54:31
__VA_ARGS__さんとテンプレート可変長引数さんとinitializer_listさんが組めば
空だって飛べる
0030デフォルトの名無しさん2010/06/04(金) 22:56:13
vc++2010の対応が雑魚過ぎて困る
0031デフォルトの名無しさん2010/06/04(金) 23:53:05
またVC6の頃みたいなバッドノウハウが累積される悪寒
0032デフォルトの名無しさん2010/06/05(土) 00:20:58
まだC++0x自体が出来上がってないんだし仕方ないよ。
ドラフトをフライング実装してforのスコープ問題みたいなことがまた起こっても困るし。

個人で買いにくい価格設定になっているのはMSの良心かもしれない。
0033デフォルトの名無しさん2010/06/05(土) 00:21:41
それならデフォルトではC++0xの機能をオフにして欲しかった
0034デフォルトの名無しさん2010/06/05(土) 00:52:11
そもそも0x機能オフにできるの？
0035デフォルトの名無しさん2010/06/05(土) 01:01:58
>>32
Express版があるぞ
0036デフォルトの名無しさん2010/06/05(土) 02:21:26
VC10はそもそも開発チーム自身が「新しいVC6だ」って言ってたし
0037デフォルトの名無しさん2010/06/05(土) 02:45:57
SPなりhotfixなりで矢継ぎ早に修正してくれれば問題ないんじゃない？
VC6は使われる時間が長すぎたからな

とりあえずさっさと可変長引数テンプレートサポートしてくれ
0038デフォルトの名無しさん2010/06/05(土) 07:15:15
MSは互換性を最優先させるから、
明らかに実装方法の誤りであっても次Ver.まで仕様で放置とか良くあるんだよな。
0039デフォルトの名無しさん2010/06/05(土) 07:24:24
vc++2010って初期化リスト周りおかしくね？
0040デフォルトの名無しさん2010/06/05(土) 08:47:18
初期化リストなんて面倒なこと言わずに{～}をテンポラリな配列として扱えばよかったのに
そうすればtemplate <class T, size_t N> void func(const T (&a)[N]);で受け取れるし
コンパイル時にサイズもわかるし直にランダムアクセスもできる
なにより組み込みなのにstd名前空間とか気持ち悪い現象が発生しない
0041デフォルトの名無しさん2010/06/05(土) 09:13:11
parse上の問題でもあるんじゃない？
0042デフォルトの名無しさん2010/06/05(土) 09:15:39
配列はないな
サイズの取得が面倒くさい
0043デフォルトの名無しさん2010/06/05(土) 09:16:06
組み込みなのにstd名前空間とか別に普通だよ
new が失敗すりゃ std::bad_alloc 例外投げるし
それを抑制する時に使うものも std::nothrow だし
0044デフォルトの名無しさん2010/06/05(土) 10:59:04
std::initializer_list ってどう実装されてんの
引数を隠しローカル配列に入れておいて
そのポインタを保持するとか？
0045デフォルトの名無しさん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) { ... }

と思ったけど仕様とか知らないからこれが可能なのかどうか
分からない
0046デフォルトの名無しさん2010/06/05(土) 12:43:37
>>45
このケースなら薄いテンプレートで分離できなくも無い
0047デフォルトの名無しさん2010/06/05(土) 12:54:49
使えないけど#include<initializer_list>は通るんだよな
中途半端なことやめて
0048デフォルトの名無しさん2010/06/05(土) 13:49:36
std::initializer_list のクラステンプレート自体は実装してある
でもそれだけなんだよな
中途半端やなあ
0049デフォルトの名無しさん2010/06/05(土) 16:26:52
g++4.5.0も a[{1,2}] を解釈してくれない。
FCDには例示されてるけど、後で加筆されたものなのか
0050デフォルトの名無しさん2010/06/05(土) 19:34:34
>>38
スイッチで切り替えられるようにしないのはどういうつもりなのかねえ。
0051デフォルトの名無しさん2010/06/05(土) 21:12:40
03にしたけりゃユーザーが勝手に自分で03の範疇で書いてろよ、って事でね？
0052デフォルトの名無しさん2010/06/05(土) 22:21:04
はあ？
0053デフォルトの名無しさん2010/06/05(土) 22:22:01
>>52
はあ？
0054デフォルトの名無しさん2010/06/05(土) 23:04:15
>>51
VC10のC++0xの対応レベルで互換性が問題になるのはautoぐらいじゃね？
0055デフォルトの名無しさん2010/06/05(土) 23:18:31
C++0xにはスマポ、正規表現、乱数とかいろいろあるから
それ全部使えなくなるってのはちょっと…
まあ、boostの使えば問題ないか
0056デフォルトの名無しさん2010/06/05(土) 23:21:01
右辺値参照はすでに使いまくってるぜ
0057デフォルトの名無しさん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に変換できませんとか出る。何故なんだろう？
0058デフォルトの名無しさん2010/06/05(土) 23:35:40
>>57 そーすうｐ
0059デフォルトの名無しさん2010/06/05(土) 23:46:11
usingしなければよい
0060デフォルトの名無しさん2010/06/06(日) 00:23:14
>>57
気になる。ソースソース。
0061デフォルトの名無しさん2010/06/06(日) 08:48:10
ナントカルックアップだろ
0062デフォルトの名無しさん2010/06/06(日) 09:25:29
>>57
using namespace std;
なんてしてないよな？
0063デフォルトの名無しさん2010/06/06(日) 09:57:46
どっかのヘッダでusingしてる悪寒
0064デフォルトの名無しさん2010/06/06(日) 10:05:57
ヘッダでusingとかえんがちょにもほどがある
0065デフォルトの名無しさん2010/06/06(日) 10:16:49
>>64
ヘッダのnamespace内でusingすることはあるけどなぁ
boost::tr1の真似して
0066デフォルトの名無しさん2010/06/06(日) 10:26:16
ヘッダでusingするのは
名前を取り込みたい時であって
名前空間を省略したい時ではないぞ
0067デフォルトの名無しさん2010/06/06(日) 12:45:21
あーおれ面倒だから using namespace std::string よくやるわすまん・・・
0068デフォルトの名無しさん2010/06/06(日) 12:52:20
死刑
0069デフォルトの名無しさん2010/06/06(日) 13:28:06
ローカルの関数スコープ以外のusingを禁止するコンパイルオプションはなぜ無いのか
0070デフォルトの名無しさん2010/06/06(日) 15:16:35
auto f(int x) -> hoge
{
・・・
}
この書き方ってなんかイイコトあるんですか？
0071デフォルトの名無しさん2010/06/06(日) 15:23:13
-> decltype
が出来る、とか
0072デフォルトの名無しさん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 を２度書かないといけないのが気に食わない
0073デフォルトの名無しさん2010/06/06(日) 15:38:39
template <typename T1, typename T2>
auto add(const T1& a, const T2& b) -> decltype(a + b);
0074デフォルトの名無しさん2010/06/06(日) 15:50:35
auto hoge(fuga x) -> decltype(x + piyo())
{
piyo y;

return x + y;
}

この場合はこう書くの？
けっこうメンドクセーな
0075デフォルトの名無しさん2010/06/06(日) 16:23:37
template <typename T1, typename T2>
auto add(const T1&, const T2&) -> decltype(std::declval<T1>() + std::declval<T2>());
0076デフォルトの名無しさん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 ; }

戻り値にクラス名の修飾がいらない。
0077デフォルトの名無しさん2010/06/06(日) 17:26:41
まあそれなら便利な事もあるかな・・・
Hoge:: くらいなら auto -> 書くのと大差ないけど
もっと長いと使えるかも
0078デフォルトの名無しさん2010/06/06(日) 17:34:21
でもどっちかに統一しないと気持ち悪いよな
0079デフォルトの名無しさん2010/06/06(日) 17:43:35
必要に応じて便利な方を使うしかない。
気持ちを最優先にしてもコンパイルに関係ないし。
0080デフォルトの名無しさん2010/06/06(日) 18:11:30
コンパイルに関係ないなら気持ちは優先してもいいんじゃね？
0081デフォルトの名無しさん2010/06/06(日) 18:12:35
>>70
型が右に来る方が直感的
0082デフォルトの名無しさん2010/06/06(日) 18:31:24
それはない
0083デフォルトの名無しさん2010/06/06(日) 18:37:22
>>70

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

auto LongLongHogeHugaItteyoshiClass::f() -> T
{
...
}
0084デフォルトの名無しさん2010/06/06(日) 18:39:18
// LongLongHogeHugaItteyoshiClass.cpp

#include "LongLongHogeHugaItteyoshiClass.h"
typedef LongLongHogeHugaItteyoshiClass L;

L::T L::f() {
}
0085832010/06/06(日) 18:40:00
ごめんなさい、すでに同じことが76に書かれてました。
0086デフォルトの名無しさん2010/06/06(日) 19:32:46
>>84 と違って、>>76, >>83 のやり方だと
class 中の private な typedef にも使用可能だったはず…
0087デフォルトの名無しさん2010/06/06(日) 19:49:53
privateなら好きに短い名前でtypedefすりゃええんやないの？
0088デフォルトの名無しさん2010/06/06(日) 20:28:57
書くのがだるいというだけでtypedefを使うやつを俺は信用しない
ていうか入力補完でいいじゃないか
0089デフォルトの名無しさん2010/06/06(日) 20:43:05
べ、別にあんたに信用されようなんて思ってないんだからねっ！
0090デフォルトの名無しさん2010/06/06(日) 20:47:06
typedefは必須だろう
0091デフォルトの名無しさん2010/06/06(日) 20:47:48
書くのがだるいだけじゃないぞ
読み辛い
0092デフォルトの名無しさん2010/06/06(日) 20:48:52
typedef使わずに素の宣言かいてたらクラスの変更とか困るだろ
0093デフォルトの名無しさん2010/06/06(日) 20:50:39
>>88
C#のひとか？
0094デフォルトの名無しさん2010/06/06(日) 20:53:31
C#でもmonoで書くと補完効かんぞ
0095デフォルトの名無しさん2010/06/06(日) 21:03:29
std::mapの値とかvalue_typeをtypedefしてるから明確になるのに。
0096デフォルトの名無しさん2010/06/06(日) 21:05:57
EDスクロールが早いから偽EDですね
0097デフォルトの名無しさん2010/06/06(日) 21:07:40
ごめん誤爆・・・
0098デフォルトの名無しさん2010/06/06(日) 21:08:39
知ってます
0099デフォルトの名無しさん2010/06/06(日) 21:35:10
typedefないとtemplate成立しない
0100デフォルトの名無しさん2010/06/06(日) 21:36:57
いやその理論はおかしい
0101デフォルトの名無しさん2010/06/06(日) 21:43:38
テンプレート引数をtypedefしないと
外から使えないし
0102デフォルトの名無しさん2010/06/06(日) 21:55:01
確かにtypedefだけではtemplateは成立しない。
typenameも必要だ。
0103デフォルトの名無しさん2010/06/06(日) 22:37:59
>>82
最近の言語はみんな右に書くようになってるんだぜ？
0104デフォルトの名無しさん2010/06/06(日) 22:39:05
例えば？
0105デフォルトの名無しさん2010/06/06(日) 22:40:47
Fortran
0106デフォルトの名無しさん2010/06/06(日) 23:06:40
>>103
C#はどうだっつんだ
てか、右でも左でもどっちでも変わらん
どちらが直感的とかない
0107デフォルトの名無しさん2010/06/06(日) 23:10:22
右に書く言語は
従来の文法を拡張したら仕方なくそうなったって奴が多いな
0108デフォルトの名無しさん2010/06/06(日) 23:12:13
なんだまたC#の人だったのか
0109デフォルトの名無しさん2010/06/07(月) 06:56:32
日本語的には左
英語的には右
0110デフォルトの名無しさん2010/06/07(月) 07:27:09
構文解析の都合を考えると左の方が便利
0111デフォルトの名無しさん2010/06/07(月) 07:32:54
int a;
int bb;
int ccc;
int dddd;

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

下は揃わないな
0112デフォルトの名無しさん2010/06/07(月) 10:03:52
inline namespaceって何者なんですか？
存在意義がいまいち不明なんですが・・・
0113デフォルトの名無しさん2010/06/07(月) 10:40:53
名前空間バージョニングする場合色々問題があるのでその解決だそうだ
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1344.pdf
0114デフォルトの名無しさん2010/06/08(火) 09:08:12
つまり…どういう事だってばよ？
0115デフォルトの名無しさん2010/06/08(火) 22:34:16
inline namespace だと？初耳だぜ。
0116デフォルトの名無しさん2010/06/08(火) 23:42:00
理解できる部分だけ使えばいいのさ
0117デフォルトの名無しさん2010/06/09(水) 10:14:37
>>109
数学的には右だな
0118デフォルトの名無しさん2010/06/09(水) 12:32:56
数学的にどうのと言うなら = の意味の違いをどうにかせえ
0119デフォルトの名無しさん2010/06/09(水) 13:19:19
数学的に何か問題あるのか？
0120デフォルトの名無しさん2010/06/09(水) 13:33:06
数学的な厳密さを言うんなら副作用がある時点で
0121デフォルトの名無しさん2010/06/09(水) 16:00:15
キャプチャなしのラムダをラップする関数ってどうやって作るの？
0122デフォルトの名無しさん2010/06/09(水) 23:11:25
キャプチャなしラムダなら関数ポインタに暗黙変換できるからラッパなんか必要なし
0123デフォルトの名無しさん2010/06/09(水) 23:19:10
次にお前は「おのれVC++2010」と言う
0124デフォルトの名無しさん2010/06/09(水) 23:19:54
>>122
VC++2010ですができませんよ？
01251242010/06/09(水) 23:20:46
ハッ！？
0126デフォルトの名無しさん2010/06/09(水) 23:35:02
decltype(<<ラムダ式>>)::operator()のポインタ取れば？
0127デフォルトの名無しさん2010/06/09(水) 23:36:22
自演だよなっ？
0128デフォルトの名無しさん2010/06/09(水) 23:44:54
>>126
無理じゃね？
0129デフォルトの名無しさん2010/06/10(木) 16:02:02
自演だとしても笑えたから許す
0130デフォルトの名無しさん2010/06/10(木) 22:43:56
もうmailingは出ないのかしら
0131デフォルトの名無しさん2010/06/11(金) 01:30:34
>>124
VC++ 2010がまだ追い付いていないだけ。
0132デフォルトの名無しさん2010/06/11(金) 02:50:48
f(vector<int> &&);

auto *x = new vector<int>;
f(move(*x));
delete x; // ← このdeleteってなんか変なこと起こさないですか？
0133デフォルトの名無しさん2010/06/11(金) 02:55:30
moveの後で*xに触ってるから未定義動作だな
0134デフォルトの名無しさん2010/06/11(金) 03:26:59
デストラクタも呼べないのか？
そんなまさか
0135デフォルトの名無しさん2010/06/11(金) 04:03:25
やっぱりいるよ。
>>133みたいな勘違いする奴が。
0136デフォルトの名無しさん2010/06/12(土) 07:33:15
破壊的操作と未定義動作の区別がついて無いようだね。
0137デフォルトの名無しさん2010/06/12(土) 07:41:12
X x; std::move(x);
ができる以上、デストラクタは呼べるはず
だからdeleteしても問題ないはず
0138デフォルトの名無しさん2010/06/12(土) 07:58:10
やはり、std::moveなんて関数を標準で用意するから>>133みたいなバカがでるんだよ。
自前でstatic_castさせときゃいいんだよ。
0139デフォルトの名無しさん2010/06/12(土) 08:08:29
>>137
「はず」ﾌﾟｹﾞﾗ
0140デフォルトの名無しさん2010/06/12(土) 08:16:22
たとえばこう書いて、RVO最適化可能ならムーブよりRVOが優先されるなんてあると嬉しいんですが。将来的にはありますか？
Hoge func()
{
Hoge temp;
temp.f1();
temp.f2();
return std::move(temp);
}
0141デフォルトの名無しさん2010/06/12(土) 08:18:59
今でもある。
その場合、
もしHogeがムーブコンストラクターを実装していなければ、
コピーコンストラクターが呼ばれる。

というか、最適化によって、コピーコンストラクターの呼び出しが省略される可能性もあるが。
0142デフォルトの名無しさん2010/06/12(土) 08:24:26
お前実はRVOがなんだかわかってないだろ
0143デフォルトの名無しさん2010/06/12(土) 08:26:54
ということは、
RVO可能->コピコンそのものが不用
RVO不可->コピコンまたはムーブ適用

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

とりあえずstd::moveつけて置けば問題ないということでOK?
0144デフォルトの名無しさん2010/06/12(土) 08:32:04
>>142
ごめん、読み間違えた。「ムーブより・・・優先」とみて条件反射でコピーコンストラクターだと思ってしまった。
0145デフォルトの名無しさん2010/06/12(土) 08:36:07
>>143
よく考えたら、std::move通した時点でRVO可能なオブジェクトとコンパイラが認識できなくなる可能性があるね。

実験しないと分からないや
0146デフォルトの名無しさん2010/06/12(土) 08:39:15
>>145
なぜ？ rvalue referenceにキャストしているだけじゃないか。
ポインターならともかく。
0147デフォルトの名無しさん2010/06/12(土) 08:40:11
というか何だその「実験」って。
未だにまともなC++コンパイラは存在しないんだぞ。
何を実験するというんだ。
0148デフォルトの名無しさん2010/06/12(土) 08:43:44
そうか、まだなのか。
RVO_OR_MOVE()マクロ作って後からまとめて切り替えられるようにしておこうか。

0149デフォルトの名無しさん2010/06/12(土) 08:45:58
>>146
キャストでコンパイラが自動変数って情報を落として最適化できなくなるんじゃないかなっと思った。
0150デフォルトの名無しさん2010/06/12(土) 08:47:35
てかムーブよりRVOが優先されると嬉しいってどういうケースじゃろ
0151デフォルトの名無しさん2010/06/12(土) 09:19:15
moveとかrvalueってさ、コンパイラに最適化のヒントを与える魔法のツールじゃないよね?
0152デフォルトの名無しさん2010/06/12(土) 09:24:16
moveは最適化じゃないから、適用されるかどうかは確実に判断できる。
RVOは最適化だから確実な予測はできない。
0153デフォルトの名無しさん2010/06/12(土) 09:33:36
>>150
RVOはコスト0
0154デフォルトの名無しさん2010/06/12(土) 17:52:49
>140
return std::move(temp);

じゃなくて

return temp;

とだけ書いていれば良いのでは？
0155デフォルトの名無しさん2010/06/12(土) 18:27:16
>>154
たとえばこれならほぼ確実にRVOがかかる。
return hoge(100);

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

RVOかからないなら次善策でムーブを使いたいなと。
0156デフォルトの名無しさん2010/06/12(土) 19:11:55
>>155
return文で（コピーではなく）ムーブすることも決まっていることも決まっているから、
return temp;とだけ書いておけば、NRVOが適用されるならそれで、
適用されないならムーブで処理されることになるはず。
0157デフォルトの名無しさん2010/06/12(土) 19:16:08
>155
いや，なのでそうとだけ書いておきさえすれば

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

というのを上から順に適用していって可能なものを採用すると思います．
(2) は， return temp; という文においては temp が自動変数なので，
まず temp を自動的に右辺値として取り扱おうとするはずだからです．
01581242010/06/12(土) 19:18:10
hoge func() { const hoge h; return h; }

moveにならなくて不愉快
0159デフォルトの名無しさん2010/06/12(土) 19:36:18
>>158
それはconstなオブジェクトからムーブできない話であって、また別の話。

ムーブは元オブジェクトを破壊してよいことを前提としているので、
constなオブジェクトはすなわち破壊できないので、そこからムーブできないということ。
可能な限りconst付ける教とムーブセマンティクスは本質的に相性が良くない。
0160デフォルトの名無しさんNGNG?2BP(0)
それは当然・・・
0161デフォルトの名無しさんNGNG?2BP(0)
>>160は>>158へのレスな
0162デフォルトの名無しさん2010/06/12(土) 19:45:12
関数の戻り値として返すときは特別扱いして欲しいってことか
0163デフォルトの名無しさん2010/06/12(土) 19:46:59
>>157
丁寧な回答ありがとうです。
returnはmoveを使うで理解しました。
c++0xは思ったより気が利いてるなと感心したり
0164デフォルトの名無しさん2010/06/12(土) 20:58:40
VCのSP1はまだか
0165デフォルトの名無しさん2010/06/12(土) 21:41:28
>>164
あほか
まだVC2010そのものが店頭で売ってない
ダウンロード販売のみ
SP1はいくらなんでもその後だろう

あるとしたら店頭に並んでるものに既にSP1が適用してあるとか
そういう場合くらいしか
0166デフォルトの名無しさん2010/06/12(土) 22:58:10
世の中には発売前にパッチが出たりするソフトがあるんだよ
0167デフォルトの名無しさん2010/06/12(土) 23:22:51
というかVS2010は、よくあれでリリースしたなという出来なんだが。
IDEからしてクソすぎるし。
0168デフォルトの名無しさん2010/06/12(土) 23:29:15
>>167
さっさとてめえの化石ＰＣを窓から投げ捨てろ
0169デフォルトの名無しさん2010/06/12(土) 23:40:21
遅いといってるわけではなさそうだが。完成度が低いというなら分かる。
0170デフォルトの名無しさん2010/06/13(日) 00:19:02
遅い上に完成度が低い
0171デフォルトの名無しさん2010/06/13(日) 00:24:47
2005proのIDEから2010eeのC++コンパイラが呼び出せたらベストなんだが
0172デフォルトの名無しさん2010/06/13(日) 00:26:23
そりゃ抱き合わせですよ
独占ですから
0173デフォルトの名無しさん2010/06/13(日) 05:08:33
>>171
devenv /useenv
0174デフォルトの名無しさん2010/06/16(水) 14:31:33
RVOやNRVOが出来たかどうか調べるにはどうしたらいいのだろうか・・・難しい・・・・・・・・
0175デフォルトの名無しさん2010/06/16(水) 14:53:13
コピーコンストラクタでログ録ってそれが無視されてたら最適化されたとみていいんじゃねーか？
0176デフォルトの名無しさん2010/06/16(水) 15:14:40
LLVM の C++ （の開発版）で、オプションつけると RVO/NRVO 対象に
できたかどうかわかるよ
0177デフォルトの名無しさん2010/06/16(水) 17:06:45
inlineみたいにされたか出るコマンドはGCCにはないですか？
0178デフォルトの名無しさん2010/06/16(水) 19:19:30
副作用があるのに勝手に消えられるのも困るよな
0179デフォルトの名無しさん2010/06/16(水) 20:49:23
RVOのような動作が変わる最適化はコンパイルメーカの独断ではできないから、あえて規格上で許してるんでしょう。
規格上許しているんだから、コピコン省かれて困る設計のほうがまずいんではないか？


0180デフォルトの名無しさん2010/06/16(水) 20:53:13
んだ
0181デフォルトの名無しさん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無視かよ
0182デフォルトの名無しさん2010/06/16(水) 21:35:54
>>181
RVOでコピコンがそのもの省略されてるんだから、countのvolatileは無関係だろ。
0183デフォルトの名無しさん2010/06/16(水) 21:39:19
RVOが行われる場合、
コピコンが影響するのはアクセス制限くらいやで
0184デフォルトの名無しさん2010/06/16(水) 21:46:52
じゃあ人類にRVO最適化をコードから阻止する手段は残されていないのですか？
0185デフォルトの名無しさん2010/06/16(水) 21:56:38
>>184
こんなの通してreturnに渡したらかからなくなったことがあったような気がする
template<class T>
inline T& stop(T& a)
{
returan a;
}

ＲＶＯが効いて困るコードを書く方が問題があるぞ。バグの温床じゃないか？直したほうがいいよ。
0186デフォルトの名無しさん2010/06/16(水) 22:00:23
RVOが問題なるケースが思いつかない
0187デフォルトの名無しさん2010/06/16(水) 22:04:18
きっと常人には理解もできない状況なのだろう
理解したくもないが
0188デフォルトの名無しさん2010/06/17(木) 13:02:02
gccが__m128用のコピーコンストラクタ書いているのにスタックに積んで4バイトずつコピーするのはRVOのせいだったのか。
RVOうぜー。
0189デフォルトの名無しさん2010/06/17(木) 15:59:55
RVO,NRVO > move()>無し
だからね。
(RVO OR 無し) あるいは (move())
だから非常に困るね。
0190デフォルトの名無しさん2010/06/17(木) 18:31:44
>>189
もっと整理して書けよw
プログラムもそうなのか?
0191デフォルトの名無しさん2010/06/17(木) 20:03:02
>>188
コピーしているならRVOじゃないよね。コピーそのもの存在を無くすのがRVOなのに。

どんなコピーコンストラクタかいてるの？
0192デフォルトの名無しさん2010/06/17(木) 20:19:52
>>188
お前のコードが糞
0193デフォルトの名無しさん2010/06/17(木) 20:25:34
>>189
どこが困るのかな？
0194デフォルトの名無しさん2010/06/18(金) 09:27:08
可変長テンプレートつかった可変長引数の関数って引数は再帰で取り出すしかないんですか？
再帰はオーバーヘッドがありそうで嫌です
0195デフォルトの名無しさん2010/06/18(金) 12:04:45
じゃあ使うな
0196デフォルトの名無しさん2010/06/18(金) 12:07:27
>>194
ちょっと意味わからないから
コードを２ｃｈのこのスレッドに投稿してくれる？？
0197デフォルトの名無しさんNGNG?2BP(0)
「2chのこのスレッドに」とわざわざ言うのは
「this->」みたいなもんか
0198デフォルトの名無しさん2010/06/18(金) 15:45:10
const Hoge &は左辺・右辺とわず受け取れるけど
非constで左辺・右辺両方を受け取れるにはどうすればいいの？
0199デフォルトの名無しさん2010/06/18(金) 16:15:58
マクロで仮引数の型だけ違う同じ内容の函数を書き出す
0200デフォルトの名無しさん2010/06/18(金) 19:20:02
非constの右辺値受け取ってどうするんだろう
0201デフォルトの名無しさん2010/06/18(金) 19:30:21
move
0202デフォルトの名無しさん2010/06/18(金) 19:57:11
おいこらConceptはいつ入るんだ
0203デフォルトの名無しさん2010/06/18(金) 20:03:29
Conceptはみんなの心の中に生き続けているよ
0204デフォルトの名無しさん2010/06/18(金) 20:51:39
C++1xにご期待ください。
0205デフォルトの名無しさん2010/06/18(金) 20:53:31
>>200だけど、自分の書いたソースコードの中で使用例見つけてしまった。
コンテナから本体を書き換えることのできる部分コンテナを返す関数を
別の関数に参照渡しする場合だな。
具体的にはOpenCVのcv::Matの部分配列(ROI)なんだが。

VC++の非標準の拡張によって右辺値が非constの左辺値参照に置き換えられてたみたいだ。
コンパイルレベルをあげたら警告が出た。
0206デフォルトの名無しさん2010/06/18(金) 20:59:00
>>198
右辺値を非constで左辺値のように受けるのは危険だから受けられないようになっている。そのための&&だ。
まずそれが必要か考え直したほうがいい。
0207デフォルトの名無しさん2010/06/19(土) 02:14:34
すみません質問ですが
#include <iostream>
auto main() -> int
{
　　[]{ std::cout << "hello, world\n"; }();
}

以下の部分は何を意味してるのでしょうか？
main() -> int
0208デフォルトの名無しさん2010/06/19(土) 02:19:48
推論不能時の戻り値
0209デフォルトの名無しさん2010/06/19(土) 02:21:04
「返却値」だろうが
0210デフォルトの名無しさん2010/06/19(土) 02:24:04
それ俺がν速で書いた奴じゃないかｗ
0211デフォルトの名無しさん2010/06/19(土) 02:25:06
そんなクソ短いコードなんてとっくの昔に誰かが書いてるわ
02122072010/06/19(土) 02:26:00
ありがとうございます
0213デフォルトの名無しさん2010/06/19(土) 08:36:41
戻り値を後ろに書く構文ってだけ
0214デフォルトの名無しさん2010/06/19(土) 08:43:30
>>213
auto func(int x)->decltype(hoge(x)){return hoge(x);}
これをこんな風にかけると二回同じ式を書かなくてすむんだけど
auto func(int x)->hoge(x);
0215デフォルトの名無しさん2010/06/19(土) 08:48:47
-> の後ろに直接式書くとかキモいことしなくても
普通にこれでええやん

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

ラムダではできるのに普通の関数ではできない仕様なのは
ヘッダに書く関数や単一ファイル内で使う関数でないと意味がないからか？
と思ったけど、これやりたいのって大体関数テンプレートだから
できてもいいように思える
0216デフォルトの名無しさん2010/06/19(土) 08:51:03
Unified Function Syntaxにも戻り型推測提案してこい
0217デフォルトの名無しさん2010/06/19(土) 08:56:11
>>215
そんな記述もできるの？
{}のなかを評価しないと戻りの型が決まらないんでできないと思ってた。コンパイラは大変だなあ
もしこの関数がメンバー関数の場合{}の中は前方参照不可とか制約無いのかな？
0218デフォルトの名無しさん2010/06/19(土) 08:56:12
もうUnified function syntaxのことは忘れようぜ…
とっくにrejectされてんだから
0219デフォルトの名無しさん2010/06/19(土) 08:56:43
>>217
できない
0220デフォルトの名無しさん2010/06/19(土) 08:58:14
auto func = [](int x){return hoge(x);};
なら行ける

けどテンプレートにできんのよね
0221デフォルトの名無しさん2010/06/19(土) 09:04:05
>>218
VC++2010で使えるけど、これは先走ったわけか
auto hoge() -> int { return 0; } // OK
int main() { return hoge(); }
0222デフォルトの名無しさん2010/06/19(土) 09:16:20
もう仕事に0x使い始めてるところなんてあるの？
0223デフォルトの名無しさん2010/06/19(土) 09:23:29
>>218　え？使えなくなったの？
0224デフォルトの名無しさん2010/06/19(土) 09:24:51
>>221
unified function syntaxってのはこれ
[]main()->int{ return 0; }
0225デフォルトの名無しさん2010/06/19(土) 09:31:49
>>224
なるほど
0226デフォルトの名無しさん2010/06/19(土) 09:35:18
>>217
ラムダでは戻り値型の推測はできるので
普通の関数でもできないわけじゃないはずだ

普通の関数は多値returnができるけど
ラムダではできないという違いも
普通の関数での戻り値推測がない点に関係あるのだろうか？
0227デフォルトの名無しさん2010/06/19(土) 09:37:35
ラムダは実装もすぐに書くから返り値がわかるけど
普通の関数やメンバ関数はヘッダとソースが分かれてるかもしれない
0228デフォルトの名無しさん2010/06/19(土) 09:41:06
分かれてない場合には使えるじゃない、と
0229デフォルトの名無しさん2010/06/19(土) 10:08:13
>>226
> 普通の関数は多値returnができるけど
C++ って多値返せないだろ, どういう意味だ?
0230デフォルトの名無しさん2010/06/19(土) 10:16:22
文脈からみて一個の関数内にreturnが複数個あるって事じゃね？
02311882010/06/19(土) 10:22:53
>>191-192
gcc 4.4.0で起きたからレポートしようと思っていたらgcc 4.5.0で直ってた
0232デフォルトの名無しさん2010/06/19(土) 10:33:26
>>229
std::initializer_list を引数に取るコンストラクタを持つクラスが戻り値の型になってる場合、
return { 0, 1 }; みたいにできる
0233デフォルトの名無しさん2010/06/19(土) 18:22:52
for_each(v, [](auto &x){ return x+=10; });
みたいな引数の型を推論してくれるようなラムダってないの？ないの？の？
0234デフォルトの名無しさん2010/06/19(土) 18:30:45
だからboost::lambdaがなくならないのさ
0235デフォルトの名無しさん2010/06/19(土) 18:36:53
いい加減多次元の動的配列をサポートしろよ
0236デフォルトの名無しさん2010/06/19(土) 19:04:51
>>235
イラネ、ライブラリで対応できる。
そういう言語サポートが必要なのは拡張能力の乏しい言語だけ
0237デフォルトの名無しさん2010/06/19(土) 19:07:57
どうしてBoost.MultiArrayを標準化しなかった。
0238デフォルトの名無しさん2010/06/19(土) 19:11:30
標準にするにはマニアックすぎたんじゃないか？
第二水準標準ライブラリとか作って採用して欲しい。
0239デフォルトの名無しさん2010/06/19(土) 19:14:26
ライブラリでできるからといって組み込みで必要ないというなら
initializer_listもライブラリでいいんだな？
02401882010/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 ...]と式が複雑になっていって、コンパイラを混乱させる。
なので多次元配列が組み込みとして存在すれば、最適化の推論は簡単になる。
0241デフォルトの名無しさん2010/06/19(土) 19:28:25
>>240
多次元配列に夢の持ちすぎだろう。
0242デフォルトの名無しさん2010/06/19(土) 19:36:50
>>240
そういうのって、部分配列で次元数を減少させてループを書いたりするんじゃね？

いくら組み込みでも多次元の添え字をランダムアクセスで渡せば最適化できないだろう。結局同じテクニックが必要だと思うんだ。
0243デフォルトの名無しさん2010/06/19(土) 19:51:32
>>240
処理系の所為なら同じ問題が起きるだけじゃね？
0244デフォルトの名無しさん2010/06/19(土) 20:50:00
多次元配列って実装が一種類じゃないんだよね。
C配列、FORTRAN配列、row-first、collumn-first
使用目的に応じて実装できるライブラリが適してると思うんだよ。
行列にしても、帯行列、三角、スパース行列、など行列の特性に応じた格納方法があるし。

組み込み多次元配列を用意したところで適用できなければメリットは小さいと思うよ。
02451882010/06/19(土) 21:13:45
>>244
その理論だとFORTRANに多次元配列がある説明になっていないぞ。

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

>>235は単に基本となる配列を動的多次元にしてくれって言っているだけでしょ。
そしてその意見には>>240的観点から賛同する。
0246デフォルトの名無しさん2010/06/19(土) 21:32:22
いい加減自己主張やめて名前欄消せ
0247デフォルトの名無しさん2010/06/19(土) 23:56:42
可変長テンプレート引数を利用すれば
std::vectorからの０オーバーヘッドを保ちつつ作れそうか
0248デフォルトの名無しさん2010/06/20(日) 01:39:13
例え次元数固定でもテンプレートで作っちゃうと、毎回愚直にアドレス計算されるよ。
0249デフォルトの名無しさん2010/06/20(日) 01:54:51
特殊化すりゃいいだけじゃん
0250デフォルトの名無しさん2010/06/20(日) 06:25:21
特殊化してもj*mをループの外に移動出来ないでしょ。
0251デフォルトの名無しさん2010/06/20(日) 08:30:17
多次元配列が欲しいんじゃなくて最適化して欲しいだけじゃないか
0252デフォルトの名無しさん2010/06/20(日) 08:39:11
boostの多次元配列はコンパイル時間長いし、そもそもboost禁止の場合もある
組み込みの多次元配列が有ってうれしいことはあっても困ることはない
0253デフォルトの名無しさん2010/06/20(日) 09:05:12
組み込みの多次元配列がなくて困ると言う声がほとんどない以上、入る事はないな。
0254デフォルトの名無しさん2010/06/20(日) 09:14:11
利便性の向上でもあり、最適化のヒントにもなるツール。
言語の歴史から言えば多分RVOよかよっぽど基本的な話。
0255デフォルトの名無しさん2010/06/20(日) 09:14:41
困ることが無いから入れるという理屈では入ることは無い。
実現方法がたくさんあると、ライブラリ間でのデータの受け渡しに支障が出る。
0256デフォルトの名無しさん2010/06/20(日) 09:27:42
NULL終端じゃなくてサイズ+データの基本データ型があるだけでも汎用性高いんだけどね。
FORTRANはデータだけでもコンパイラに多次元配列である事を伝えることが出来る。
Cっぽく書くと
void func(int n, int m, int array[m][n]) {}
ってな感じ。
0257デフォルトの名無しさん2010/06/20(日) 09:32:53
C++ で数値計算しようと思わないからいらね > 多次元配列
0258デフォルトの名無しさん2010/06/20(日) 09:39:45
initializer_listで受け取った引数は連続領域にある前提で書いていいの？
0259デフォルトの名無しさん2010/06/20(日) 09:40:08
多次元配列はライブラリでできるのがC++
組み込みじゃないなと嫌っていう人はFORTRANを遣えば良いってだけの話。
0260デフォルトの名無しさん2010/06/20(日) 09:41:38
はいはい数値計算数値計算。
そういう本質が分からん奴に限ってWin32APIで絵を表示しようとしたときに
SetPixelを使って、「遅い」とか言い出すんだよなあ。
0261デフォルトの名無しさん2010/06/20(日) 09:42:22
必要度　concept>多次元配列

コンセプトは必要。マジ欲しい。
0262デフォルトの名無しさん2010/06/20(日) 09:44:00
>>255
そうそう
規格で統一すれば異なるライブラリ間で多次元配列を簡単にやり取りできるのにね
0263デフォルトの名無しさん2010/06/20(日) 09:50:59
>258
一旦配列に確保されたかのように扱われるから OK のはず。end() も begin() + size() になってる。
0264デフォルトの名無しさん2010/06/21(月) 12:34:28
最適化のためのキーワード(や、それに代わるもの)がほしいって話なら…
registerが肥やしに変わった以上、マジそれがないと実現不可能とかじゃないと追加は難しいんじゃないかな

上の例だと「ネストが深くても最適化してくんない？」ってIntelにリクエストすればいいだけだし
0265デフォルトの名無しさん2010/06/22(火) 02:03:03
これ以上議論する気はないけれど、配列に追加のキーワードはいらないだろ。
そんなこと言うならRVOとかmoveとか口にするなよ。
initializer_listだってなんだって、多くのものは利便性の向上をメインとして
更に最適化の機会向上も兼ね備えているんだよ。
0266デフォルトの名無しさん2010/06/22(火) 07:00:08
これ以上議論する気はないけれどと言っておきながら議論ふっかける男の人って。。。
0267デフォルトの名無しさん2010/06/22(火) 07:13:06
自分の言いたいことは言うけど、反論されるのは怖いからやめてください。
0268デフォルトの名無しさん2010/06/22(火) 07:22:11
initializer_listって配列の代わりに使えるよな
もっと一般化できそうだが
0269デフォルトの名無しさん2010/06/22(火) 08:18:46
反論は怖くない。そこから得られるものがあればいい。
あまり続けると、他の話題を出したい人が話に割り込めなくなるのが怖いだけだ。
0270デフォルトの名無しさん2010/06/22(火) 08:20:20
無様な言い訳をする男の人って軟弱でステキ！
0271デフォルトの名無しさん2010/06/22(火) 11:47:02
ユーザー定義リテラルなんかよりインクルードガードが欲しかったな
0272デフォルトの名無しさん2010/06/22(火) 11:51:11
途中まで #pragma once が規格に残っていたのにいつのまにか消えたのは何でだろう
0273デフォルトの名無しさん2010/06/22(火) 12:40:08
>>272
いい事だ
0274デフォルトの名無しさん2010/06/22(火) 13:21:51
gcc と ｖｃ は #pragma once 使えるから規格になくてもいいや
0275デフォルトの名無しさん2010/06/22(火) 14:59:48
LLVMのCLangも大きな派閥になってくると思う。
ConceptGCCの中の人がC++サポートをやってるし。
0276デフォルトの名無しさん2010/06/22(火) 21:01:57
>>272
インクルードガードだと、インクルードが循環参照するとコンパイルされなくてエラーになるのが便利。
#pragma oneceだとヘッダの参照関係が循環してもコンパイルが通ってしまって不便、危険。
0277デフォルトの名無しさん2010/06/22(火) 21:23:05
？？
0278デフォルトの名無しさん2010/06/22(火) 21:39:28
循環参照を気にしなくてもいいように#pragma once使うんじゃないの？
0279デフォルトの名無しさん2010/06/22(火) 21:39:43
#pragma once の問題はハードリンクをどう扱うか程度じゃなかったっけか？
そしてそれが致命傷
0280デフォルトの名無しさん2010/06/22(火) 21:41:36
インクルードガード内の循環参照は重複してインクルードされないだろ
0281デフォルトの名無しさん2010/06/22(火) 22:18:18
>>280
インクルードされないから循環参照をエラーとして検出できる。
0282デフォルトの名無しさん2010/06/22(火) 22:28:47
例を出せ
もちろんちゃんとコンパイルして期待した動作をすることを確かめてからな
0283デフォルトの名無しさん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;
}

問題なくコンパイルできる
0284デフォルトの名無しさん2010/06/22(火) 22:37:43
循環参照が#pragma onceにしただけで解消されるとか
どんなファンタジーなんだ
0285デフォルトの名無しさん2010/06/23(水) 03:22:22
std::pair を
template<typename U, typename... Args> pair(U&&, Args&&...)
で構築するとして
pair<int, int> p(1);
の second は zero-initialized と決まってるんでしょうか
0286デフォルトの名無しさん2010/06/23(水) 04:22:40
インクルードガードを書けば循環参照が検出できるなんて
どんなファンタジーなんだ
0287デフォルトの名無しさん2010/06/23(水) 10:57:13
#includeは参照じゃないだろ。
ファイルに埋め込まれるから自己埋め込みになる。
0288デフォルトの名無しさん2010/06/23(水) 11:11:05
>インクルードガードだと、インクルードが循環参照するとコンパイルされなくてエラーになるのが便利。
そろそろサンプルぷりーず
0289デフォルトの名無しさん2010/06/23(水) 11:22:58
#errorで自分でやるんじゃないの
0290デフォルトの名無しさん2010/06/23(水) 12:46:24
#includeはただの埋め込みだとなんどいったら(ry
0291デフォルトの名無しさん2010/06/23(水) 14:28:57
>285
そのコンストラクタは N3092 には無いです．
0292デフォルトの名無しさん2010/06/23(水) 16:29:09
クラスの循環参照とごっちゃになってる人がいる？
0293デフォルトの名無しさん2010/06/23(水) 16:32:27
このスレはC++上級者の中でも更に次の規格について議論する人たちの集まりかと思っていたら、
上を目指すどころかコンパイラの仕組みも理解してない人多くね?
0294デフォルトの名無しさん2010/06/23(水) 16:49:05
クラスの循環参照って何？

コンパイラの仕組みとか以前というか
自分で勝手に意味を決めてるやつが多いのかな？
0295デフォルトの名無しさん2010/06/23(水) 16:54:57
VCのpragma onceて、初見のソースにつき一回しか参照っていうか取り込みされないと思ってたのだがちがったのか？
0296デフォルトの名無しさん2010/06/23(水) 18:42:57
違わない
0297デフォルトの名無しさん2010/06/23(水) 19:13:15
だよ～ね。
0298デフォルトの名無しさん2010/06/23(水) 19:21:41
しかし、ハードリンクが絡むと状況は複雑になる
パスが全く違っても同じ実体を指している事があるけど、
それも検出せなあかんのん？ と
0299デフォルトの名無しさん2010/06/23(水) 19:24:20
iノード番号でわかるだろ
0300デフォルトの名無しさん2010/06/23(水) 19:25:10
内容が全く同じソースなら弾けばいいんじゃないのかしら？
たとえ実態が別々でも
0301デフォルトの名無しさん2010/06/23(水) 19:47:34
環境によっては色々面倒な話が出てくるから、規格から外されたわけだ。
0302デフォルトの名無しさん2010/06/23(水) 19:50:27
環境ごとの面倒な話を統一するための規格じゃないのか
根性ねえなぁ
0303デフォルトの名無しさん2010/06/23(水) 19:53:11
めんどくせぇ
0304デフォルトの名無しさん2010/06/23(水) 19:57:11
>>291
ｿﾃﾞｽｶ… orz
では、pair に限らず (U&&, Args&&... args) の args が省略された場合
fundamental type を forward<Args>(args)... で構築した場合
zero-initialized と期待していいのでしょうか
0305デフォルトの名無しさん2010/06/23(水) 20:11:31
>>302
ディレクトリ操作すら規格にない言語だから仕方がない
かろうじてディレクトリに関するerrnoがあるくらいだ
0306デフォルトの名無しさん2010/06/23(水) 21:34:56
禿は # で始まらない include を夢見てたようだが
0307デフォルトの名無しさん2010/06/23(水) 21:40:30
ソースファイルをコンパイルしたら
外部に公開できる宣言をまとめたファイルが自動的に作られて、
それをimportするような感じになってくれればなあと思う
0308デフォルトの名無しさん2010/06/23(水) 21:44:58
むしろ、ソースファイルを指定したら、
そこから必要な宣言集を構築してくれるような仕組みの方がいい。
わざわざ分ける必要はない。
いまどきヘッダーファイルなんて時代じゃねーだろ。
0309デフォルトの名無しさん2010/06/23(水) 21:45:58
それはC++/CLI
0310デフォルトの名無しさん2010/06/23(水) 22:44:31
>>308
C++でそれやると現実的なコンパイル速度にならない気がする
0311デフォルトの名無しさん2010/06/23(水) 23:00:42
>>307-308

まさにGoのやり方．
0312デフォルトの名無しさん2010/06/24(木) 08:09:14
コンパイルとリンクが別になってるのが既に時代遅れ
0313デフォルトの名無しさん2010/06/24(木) 08:39:24
暗号化がデフォじゃないのもね
0314デフォルトの名無しさん2010/06/24(木) 10:05:24
> 暗号化がデフォじゃないのもね
お前のプログラムがリバースエンジニアリングの対象になるわけねーだろ
思い上がるな
0315デフォルトの名無しさん2010/06/24(木) 10:38:37
このスレはC++上級者の中でも更に次の規格について議論する人たちの集まりかと思っていたら、
上を目指すどころかコンピューターの仕組みも理解してない人多くね?
0316デフォルトの名無しさん2010/06/24(木) 13:26:45
流石コンピューターおばあちゃんは言うことが違う
0317デフォルトの名無しさん2010/06/24(木) 14:57:25
bool operator && (function<bool ()> reval);
こんな感じで右辺の評価が自動で関数オブジェクトになりshort circuitが可能になると思っていたのに自分でlambdaにしないと駄目なのか
0318デフォルトの名無しさん2010/06/24(木) 21:38:20
initializer_listってどうなってんだ？
typedefしたらコンパイル通らなくなるし、配列のように振る舞うって聞いたのに代入したらベクターみたいに動作するし、[]の中に{}突っ込んでもエラー出るしでわけわからん
0319デフォルトの名無しさん2010/06/24(木) 21:41:03
VC++2010か
まだ対応してないぞ
定義はあるけど
0320デフォルトの名無しさん2010/06/24(木) 22:05:14
VC++2010は色々と残念
0321デフォルトの名無しさん2010/06/24(木) 22:09:17
>>320
IDEは2008の改良でいいのにあちこち退化して残念
0322デフォルトの名無しさん2010/06/24(木) 22:09:47
いやgcc4.5.0の話です
0323デフォルトの名無しさん2010/06/24(木) 22:18:40
-std=c++0x(gnu++0x)付けた？
0324デフォルトの名無しさん2010/06/24(木) 22:20:11
もちろん
0325デフォルトの名無しさん2010/06/24(木) 22:21:59
gccの実装はまだ完全じゃないからな。
typedefはワケ分からんが、operator []は、まだ実装してない。
だいたい、initializer_listは配列のように振舞わない、どこで聞いたんだそんな話。
0326デフォルトの名無しさん2010/06/24(木) 22:25:55
typedefが動かないバグは上がってないな。
報告しておいたら？
0327デフォルトの名無しさん2010/06/24(木) 22:28:11
いや、配列のようにってのはここできいたんだがw
0328デフォルトの名無しさん2010/06/24(木) 22:30:18
ネット上に出回る情報が全部正しい訳じゃないなんていつものこと
0329デフォルトの名無しさん2010/06/24(木) 22:34:33
まあ、リスト初期化の構文自体は、素の配列や構造体を初期化する文法を、
ユーザー定義のクラスでも使えるようにしようというものだから、
その辺が伝聞が変化したのかも。


初期化リスト（initializer list）は、あたかも配列を初期化するように振舞う
↓
std::initializer_listは、あたかも配列のように振舞う
0330デフォルトの名無しさん2010/06/24(木) 22:43:25
ラムダからinitializer listをreturnできるようにしてくださいよぉ
0331デフォルトの名無しさん2010/06/24(木) 22:56:17
これじゃだめか？

[]() -> std::vector<int>
{
std::vector<int> v = {1,2,3} ;
return v ;
} ;
0332デフォルトの名無しさん2010/06/24(木) 22:59:13
auto foo = []() -> std::vector<int> { return { 1, 2, 3 }; };

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

何で禁止したんだろ
実装が難しいの？
0333デフォルトの名無しさん2010/06/24(木) 23:05:10
ていうかそれでいいのなら、こういうことはできるがな。

[] { return std::vector<int>{1,2,3} ; } ;
0334デフォルトの名無しさん2010/06/25(金) 07:17:43
returnが多いと面倒くさいけど
仕方がないのかねえ
0335デフォルトの名無しさん2010/06/25(金) 08:19:46
おれ的には右辺値参照と可変長テンプレートとラムダだけで十分だった
0336デフォルトの名無しさん2010/06/25(金) 09:09:48
conceptほしかった…
0337デフォルトの名無しさん2010/06/25(金) 09:15:05
conceptは犠牲になったのだ……
0338デフォルトの名無しさん2010/06/25(金) 09:30:03
0xの犠牲にな
0339デフォルトの名無しさん2010/06/25(金) 10:11:30
最適化の為だけのキーワードが云々ほざいてる奴もいたが、俺はconstexprが好きだぜ。
0340デフォルトの名無しさん2010/06/25(金) 11:53:17
それって最適化か？
0341デフォルトの名無しさん2010/06/25(金) 19:24:21
332のコードは通るでしょ
0342デフォルトの名無しさん2010/06/25(金) 22:16:39
constexprはTMPの道具でしょ
0343デフォルトの名無しさん2010/06/26(土) 00:38:01
>>342
それだけじゃないよ
0344デフォルトの名無しさん2010/06/27(日) 11:03:16
<unordered_set>で余分なバケツを削る方法はありませんか？
（<vector>でのいわゆるswap技法に対応するもの）
0345デフォルトの名無しさん2010/06/27(日) 11:06:28
ん？swap技法使えないのか？
0346デフォルトの名無しさん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
0347デフォルトの名無しさん2010/06/27(日) 11:18:30
unordered_set<int>(s).swap(s);
これだとsと同じコンテナとsの中身を交換という形になってしまうぞ。
vectorで同じことをしてもreserveされた領域は小さくなるだろうが、サイズは変わらない。
0348デフォルトの名無しさん2010/06/27(日) 11:21:24
>>346
バケツとアイテム数は同じにはならないだろ。
１０００個挿入して９００個消してからやってみ
0349デフォルトの名無しさん2010/06/27(日) 11:23:29
unordered_set<int>().swap(s);
0350デフォルトの名無しさん2010/06/27(日) 11:24:03
s.empty()
0351デフォルトの名無しさん2010/06/27(日) 11:24:55
>>350これはひどい

まあこのメンバ関数名もどうかと思うけど
0352デフォルトの名無しさん2010/06/27(日) 11:27:01
わたし350だけど349したらs.empty()が真になるって言いたかったんだけど
03533502010/06/27(日) 11:29:12
みんなひどい！もうしらない！
0354デフォルトの名無しさん2010/06/27(日) 11:30:05
やりたいことが伝わってなかったようで、申し訳ないです。
そもそもの目的は、
rehash(n)でバケツの数がn「以上」になってしまうのを
ちょうどnにしたいのです。
0355デフォルトの名無しさん2010/06/27(日) 11:30:07
clearしても真にはなるでしょ、と
03563542010/06/27(日) 11:33:58
unordered_set<myclass>
になっていて、ハッシュ関数もユーザ定義しています。
0357デフォルトの名無しさん2010/06/27(日) 11:34:16
>>354
ならないし、気にするな
03583542010/06/27(日) 11:38:24
>>357
やっぱ無理なんですか・・・。
別の目的に使うhackをしてたんだけど。残念です。
0359デフォルトの名無しさん2010/06/27(日) 11:40:36
我流unodered_setを作ろう
0360デフォルトの名無しさん2010/06/27(日) 11:42:59
>>359
そうだな、自分で作れば理由もわかるしな
03613542010/06/27(日) 11:43:51
ウェブ上で複数の人が「バケツへのアクセスが提供されてる理由が不明」、
と言っておられるようですが、歴史的な経緯って誰か知りませんか？
03623542010/06/27(日) 11:44:51
>> 359,360
CSの人じゃないので、
お手軽hackに走っちゃうんですよね・・・。
精進します。
0363デフォルトの名無しさん2010/06/27(日) 11:48:29
>>361
どういう意図で言ってるのか解らんのでurl貼って。
0364デフォルトの名無しさん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

そんなことを言っている奴はいない。
なんでそういう嘘をつくんだよ？
03653542010/06/27(日) 11:55:12
http://cpplover.blogspot.com/2008/05/c0xunordered.html
あいまいな記憶ですけどここ以外にもあったような。
0366デフォルトの名無しさん2010/06/27(日) 12:02:03
まあアクセスしたいこともあるだろう
ハッシュの性能評価とか
0367デフォルトの名無しさん2010/06/27(日) 12:03:33
>>365
＞bucketの個数や容量、使用量を取得するメンバがあり、さらには、あるキーがどのbucketに属するかを取得するメンバもある
これだけ解ればハッシュをチューニングできるし、バケツにアクセスする必要ないだろう。
バケツへのアクセスを規定したら実装方法に制限を加えることになるから妥当じゃないのか。
0368デフォルトの名無しさん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.

だそうだ
03693542010/06/27(日) 20:34:24
おぉ、ということは変な使い方しても怒られないのね。
わざわざ調べていただいて、ありがとうございました。
0370デフォルトの名無しさん2010/06/27(日) 20:35:39
私も354ではありませんが勉強になりました。ありがとうございました。
0371デフォルトの名無しさん2010/06/27(日) 20:35:50
俺漏れも
0372デフォルトの名無しさん2010/06/29(火) 12:15:04
タプルはinit_listで初期化できないみたいですが、
こんなのを
my_tuple<int,int> tup={1,2};
自分でつくるとしたらどうするのがいいんですかね？
サイズの型チェックできなそうだし・・・。
0373デフォルトの名無しさん2010/06/29(火) 18:31:03
型が全て同じという前提なら作れるだろうけど
そうでなければboost::anyで包むしか
0374デフォルトの名無しさん2010/06/29(火) 20:37:31
てすと
0375デフォルトの名無しさん2010/06/29(火) 20:49:20
>>372
ctor がexplicit でなければ uniform initialization が使えるはず
0376デフォルトの名無しさん2010/06/29(火) 21:57:44
可変長テンプレートでコンストラクタ書いて{}で初期化したいって場合に
違う型が混ざってれば問題ないんだけどすべて同じ型だとイニリスになって定義してないとコンパイルエラー
納得いかないわ
0377デフォルトの名無しさん2010/06/29(火) 22:46:04
>>376
もしあなたの処理系で std::tuple<int,int,int> t = {1, 2, 3}; でコンパイルエラーがでないなら、
あなたが何か勘違いしてるのだろう。
0378デフォルトの名無しさん2010/06/29(火) 23:05:02
どういうこった？　素直に書くとこうなるが。

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

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

当然これは通る。
通らなければお前のコンパイラがマヌケなだけだが。
0379デフォルトの名無しさん2010/06/29(火) 23:10:44
gcc5.0.0だが通らないぞ
まじマヌケだなこの糞コンパイラ
0380デフォルトの名無しさん2010/06/29(火) 23:16:02
Comeau.Computing
の
Comeau C/C++
では通らないの？

0381デフォルトの名無しさん2010/06/30(水) 05:23:06
gcc 5.0。
未来からタイムマシーンでやってきたのか？
0382デフォルトの名無しさん2010/06/30(水) 08:36:29
gcc4.5.0ね間違えた
0383デフォルトの名無しさん2010/06/30(水) 08:43:38
まあ、gccはあてにならんな。
ちなみに、4.6だと>>378は通る。
0384デフォルトの名無しさん2010/06/30(水) 11:03:48
テンプレート関数のテンプレートで型を指定した場合にテンプレートの型が
ムーブコンストラクターを実装している場合に、その型のオブジェクトを返すとき戻り値をmove(　);で返して
その他の場合はNRVOを使うために普通に返す。
なんて事ができる？
0385デフォルトの名無しさん2010/06/30(水) 11:35:10
普通に戻り値の型を非参照にして、return std::move(t)すりゃいいだろ。
それでRVOできなけりゃ、そりゃコンパイラがバカなだけだ。
0386デフォルトの名無しさん2010/06/30(水) 11:59:08
戻り値の型を非参照にするって？？？
0387デフォルトの名無しさん2010/06/30(水) 12:07:31
そのまんまの意味だよ。
参照ではないprvalueで返せばいい。

class C {} ;

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

int main()
{
C c = f() ;// まともなコンパイラならRVOできる
}
0388デフォルトの名無しさん2010/06/30(水) 12:40:21
悪いけど全く意味が分からない。
日本語でおｋ
0389デフォルトの名無しさん2010/06/30(水) 13:18:57
正解かどうかはともかく言ってる意味は分かるだろ…
理解できる言語が日本語だけだと厳しいかもしれないがｗ
0390デフォルトの名無しさん2010/07/01(木) 12:03:39
>>384
そもそも return move(....); がいらないだろ。 return ...; で同じことになるんじゃなかったっけ？
0391デフォルトの名無しさん2010/07/01(木) 13:19:51
それもそうだ。
0392デフォルトの名無しさん2010/07/01(木) 13:47:54
それは最適化じゃなくて必ずそうなるって決まりなの？
0393デフォルトの名無しさん2010/07/01(木) 14:33:45
C++の標準規格には、必ず最適化せよという決まりは、まずないぞ。
Schemeの規格に、必ず末尾再帰の最適化をせよ、とあるのは、Schemeにとっては絶対に外せない根本的な概念だからなんだろうな。

ちなみに、return文の式は、コピーかムーブコンストラクターかのオーバーロード解決のためならば、
rvalueとして扱ってもいいことになっている。
0394デフォルトの名無しさん2010/07/01(木) 21:01:28
「扱ってもいい」って何だよ…
returnの式はソースだけじゃtaxon決まらないのかよ
相変わらず気持ち悪い仕様だな
0395デフォルトの名無しさん2010/07/02(金) 01:54:47
気持ち悪い=個人的に理解不能
ってだけの話
0396デフォルトの名無しさん2010/07/02(金) 02:09:17
そうかなぁ
lvalueかrvalueかがunspecifiedな第4のvalue taxonが隠れてるって事じゃないの？
キモイよ
0397デフォルトの名無しさん2010/07/02(金) 12:30:39
return move(....); がいらないってどういうことだよ？
無かったら一時オブジェクトにコピーするときコピーコンストラクターが
呼ばれてしまうとおもうがｗｗｗｗｗ
0398デフォルトの名無しさん2010/07/02(金) 13:52:39
だから、rvalueとして扱っていいってことだよ。

return文の式は、関数の戻り値の型に変換される。
これが大前提の挙動。

このとき、コピー、ムーブコンストラクターの呼び出しを省略してもよい
これが、RVO(Return Value Optimization)と呼ばれるもの。

このとき、コピーかムーブかのコンストラクターのオーバーロード解決のために、
式をrvalueとみなしてもよい。（つまり、ムーブコンストラクターを呼べる）

どんな式でもというわけにはいかんが、どうせreturn文が評価されるということは、
その関数のブロックスコープを抜けるということであって、ローカル変数の寿命は終わる。
もし、式がローカル変数のlvalueだとしたら、ムーブしたっていいだろ、どうせすぐ死ぬんだから。
0399デフォルトの名無しさん2010/07/02(金) 13:58:24
誰か規格をもってきてくれ……
0400デフォルトの名無しさん2010/07/02(金) 14:00:29
>>398
机上の空論乙
0401デフォルトの名無しさん2010/07/02(金) 14:22:26
まあ移植した時にどうなるかわからんのだし明示的に書けばいいじゃん
0402デフォルトの名無しさん2010/07/02(金) 21:34:32
>398
「rvalue とみなしてもよい」ではなくて「まず rvalue とみなす」では？
0403デフォルトの名無しさん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 に書いてある挙動が発動することが許される，ではない)
0404デフォルトの名無しさん2010/07/02(金) 22:12:04
え～っと，つまりまとめると，

12.8/34 には「ある条件下でコピーの省略 (いわゆる RVO) を行うことが*許される*．この条件の1つに
return 文に指定された式が戻り値と同じ型の左辺値自動オブジェクトの場合がある．」と書いてあって，
12.8/35 には「12.8/34 に示された条件下では，コピー元をまず右辺値とみなせ． (みなしても良い，ではない)」
と書いてあるように読めますがどうでしょうか？
0405デフォルトの名無しさん2010/07/03(土) 01:38:18
おお本当だ。
コピーが省略出来る場合で、しかも省略しない場合は、まずムーブコンストラクターを優先的に使うんだな。
0406デフォルトの名無しさん2010/07/03(土) 12:54:20
RVOもしらん馬鹿が一人紛れ込んだか
0407デフォルトの名無しさん2010/07/04(日) 01:07:10
そんなことで勝ち誇れるなんて幸せですね
もしかしてオランダ在住ですか？
0408デフォルトの名無しさん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;
}
0409デフォルトの名無しさん2010/07/04(日) 15:24:19
まずコピーが可能でなけりゃRVOは採用されない
ムーブが出来ない式ならコンパイルエラー
つーかunique_ptrに触れてみそ
0410デフォルトの名無しさん2010/07/05(月) 13:48:20
規格なんてどうでも良い、
GCCで出来るか出来ないか
それだけが問題だろ。
0411デフォルトの名無しさん2010/07/05(月) 15:52:25
規格も GCC もどうでも良い、
VCで出来るか出来ないか
それだけが問題さ。
0412デフォルトの名無しさん2010/07/05(月) 16:38:48
実装なんていらない。
規格がどうなっているか。
それだけが問題なり。
0413デフォルトの名無しさん2010/07/05(月) 17:31:20
実装がすべて。
委員会のメンバーは実装者/組織を代表している。
いかに自分たちの実装（に基づく規格）を通すか。
いかに自分たち（の実装に）不利な規格を落とすか。

だから日本からの提案は無いし（たまに）あっても通らない。
わかったかな？
0414デフォルトの名無しさん2010/07/05(月) 17:54:48
つまらんレスだな
わかるか？
0415デフォルトの名無しさん2010/07/05(月) 20:12:50
確かにお前のレスはつまらん
0416デフォルトの名無しさん2010/07/05(月) 21:22:06
うわホントにつまらんこの人
0417デフォルトの名無しさん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が無い所為で残念なソースコード
0418デフォルトの名無しさん2010/07/06(火) 14:29:11
initializer listはともかく、コンセプトなしのrange based forなんてまったく骨抜きで使い物になんねーよ。
0419デフォルトの名無しさん2010/07/06(火) 14:31:34
c++2xにご期待ください
0420デフォルトの名無しさん2010/07/06(火) 14:56:09
>>418
そこでrange仮想クラスを継承ですよ、継承。
0421デフォルトの名無しさん2010/07/07(水) 10:36:09
今のところwindows環境でつかえる一番できのいい0xコンパイラーってどれですか？
0422デフォルトの名無しさん2010/07/07(水) 12:22:42
知るかボケ
0423デフォルトの名無しさん2010/07/07(水) 19:00:35
知っとけよアホ
0424デフォルトの名無しさん2010/07/07(水) 21:10:31
自分で作れ。
もちろんconceptsも実装してだ。
0425デフォルトの名無しさん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>>を２度書くことになってしまいます。
うまい解決策はないでしょうか？
0426デフォルトの名無しさん2010/07/08(木) 01:03:59
つ　ｄｅｆｉｎｅ
0427デフォルトの名無しさん2010/07/08(木) 01:07:42
マクロはなしで・・・。
0428デフォルトの名無しさん2010/07/08(木) 01:15:33
手元のModern C++を眺めるかぎり、
#define TLIST_2(T1,T2) Typelist<T1, TLIST_1(T2)>
とかしてますね・・・。

やっぱ無理か。
0429デフォルトの名無しさん2010/07/08(木) 01:50:53
0xなら、usingで別名つければ少しは短くなりそうな。
0430デフォルトの名無しさん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;
};
とか
0431デフォルトの名無しさん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;
};
0432デフォルトの名無しさん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だろ。
0433デフォルトの名無しさん2010/07/08(木) 06:36:52
あーすまん、この場合、BaseはDependant Nameじゃないな。そりゃ無理だ。
04344252010/07/08(木) 13:58:25
各種ありがとうございました。
0435デフォルトの名無しさん2010/07/08(木) 20:25:39
C++0xの0xってどういう意味？
0436デフォルトの名無しさん2010/07/08(木) 20:28:31
xには0からF
0437デフォルトの名無しさん2010/07/08(木) 20:29:45
>>435
西暦200x年、人類に(ry
0438デフォルトの名無しさん2010/07/08(木) 20:58:21
一桁目だと誰が決めたのだろう
そう20x0だったんだよ！
0439デフォルトの名無しさん2010/07/08(木) 21:20:27
時が未来へ進むと誰が決めたんだ
0440デフォルトの名無しさん2010/07/08(木) 21:54:10
時代が
0441デフォルトの名無しさん2010/07/08(木) 23:08:14
多分次ぎはc++0y
0442デフォルトの名無しさん2010/07/08(木) 23:19:49
>>436 F でけりがつくんかい?
ハゲの論調だと 9 で終わりそうもないので 0...F みたいな感じだったが ...
0443デフォルトの名無しさん2010/07/09(金) 02:30:57
バージョンの数字か何かが続くってことなのかな？
数字の範囲を超えそうなら36進数にでもして
桁を増やしていけばいいのに、なんで0xなんてわざわざつけたんだろう
0444デフォルトの名無しさん2010/07/09(金) 18:19:31
今となっては信じ難いことだが
本当は2007年に完成する予定だったんだ
0445デフォルトの名無しさん2010/07/09(金) 19:46:32
C++98だって、延びに延びていたがな。
0446デフォルトの名無しさん2010/07/09(金) 21:22:26
xが何になろうと、右辺値参照とLambdaとautoが既に実装されてるから気にしない。一休み一休み
0447デフォルトの名無しさん2010/07/09(金) 21:24:15
うんこドドンパ
0448デフォルトの名無しさん2010/07/09(金) 21:44:33
>>447ですが、誤爆しました。すみません。
0449名無しさん＠そうだ選挙に行こう2010/07/10(土) 06:26:44
わざとですね分かります
0450名無しさん＠そうだ選挙に行こう2010/07/10(土) 16:56:52
イニリスの長さをコンパイル時に知りたいんだけどconstexprが実装されるのを待つしかないのか
0451名無しさん＠そうだ選挙に行こう2010/07/10(土) 17:00:45
コンパイル時に分かるわけねーだろ。
0452名無しさん＠そうだ選挙に行こう2010/07/11(日) 08:38:27
アトリビュートの構文に違和感を覚えたのは俺だけでいい
0453名無しさん＠そうだ選挙に行こう2010/07/11(日) 09:47:28
どんな構文でもマクロよりはましだと悟った

キレイなC++なんてC++じゃないんだ！
0454デフォルトの名無しさん2010/07/13(火) 17:13:47
パーサーが解析でないような構文を違和感のある構文っていうんだよ。
0455デフォルトの名無しさん2010/07/13(火) 21:29:44
元々汚かったC++の文法規則がattribute-specifierだらけになってますます小汚くなった
0456デフォルトの名無しさん2010/07/14(水) 12:34:04
C++0xの解説の本ありませんか？
0457デフォルトの名無しさん2010/07/14(水) 12:40:12
http://www.artima.com/shop/overview_of_the_new_cpp
0458デフォルトの名無しさん2010/07/14(水) 17:01:40
本屋からC++関連の本が綺麗に消えたな
C++0xに向けて調整中か？
0459デフォルトの名無しさん2010/07/14(水) 20:14:47
>>458
本屋がそんなこと把握してるのか・・・
0460デフォルトの名無しさん2010/07/14(水) 20:38:03
本屋にはウェブ書籍のコーナーにAjax本、Java本コーナーにJavaScript本があるって印象しかないなあ
0461デフォルトの名無しさん2010/07/15(木) 07:29:30
C++自体が消えたって可能性は考えないのか
0462デフォルトの名無しさん2010/07/15(木) 09:47:51
もういいかげん拡張はあきらめて新しい言語作ればいいのに
0463デフォルトの名無しさん2010/07/15(木) 21:05:28
そして生まれた言語の数々。
0464デフォルトの名無しさん2010/07/15(木) 23:26:27
いっぱいあんだろ。
そのうちＪＡＶＡでＯＳ作るのが当たり前の時代とかもきちゃったりするぞ。
0465デフォルトの名無しさん2010/07/15(木) 23:30:37
D最終形態にはあらゆる言語がひれ伏すぞ。
0466デフォルトの名無しさん2010/07/15(木) 23:40:29
アルティメットD・・・
仮面ライダーにいたよ、そんな敵
0467デフォルトの名無しさん2010/07/15(木) 23:52:10
>>464
と、言われて１０年たちましたね。
0468デフォルトの名無しさん2010/07/16(金) 00:42:26
eclipseでOS作ればJAVA使ったことになるのさ
0469デフォルトの名無しさん2010/07/16(金) 18:06:32
JavaでOSってどうやって書くの？
ブートローダで真っ先にJVM呼ぶの？
ハードウェアアクセスを全部JVM様にお願いして仲介してもらうの？
カーネルのメモリまで全部GCに支配されてんの？

ｵｴｯ
0470デフォルトの名無しさん2010/07/16(金) 18:16:20
Javaのバイトコードをネイティブにデコードするプロセッサなんだろう。きっと。
0471デフォルトの名無しさん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)
0472デフォルトの名無しさん2010/07/16(金) 19:14:20
ちょっと待ってほしい
もし仮にPCに電源投入すると
Javaインタープリターが起ち上るとするならば、
これもまたJavaOSと名乗ることを許されるのではないだろうか
0473デフォルトの名無しさん2010/07/16(金) 19:28:29
そのインタプリタはCで書かれてるんですね
わかります
0474デフォルトの名無しさん2010/07/16(金) 20:06:12
JavaをJavaで書けるようになってからだね。
0475デフォルトの名無しさん2010/07/16(金) 22:41:08
Visual C++はVisual C++で作成されています。

ってVC++6.0のスプラッシュに書いてあった
0476デフォルトの名無しさん2010/07/16(金) 23:08:41
>>469
SingularityっていうC#(の拡張言語)で書かれた似たようなOSの場合は
WindowsでいうHALはC++で書かれていてそれ以外の部分がC#になってた

>>470
なんか10年前に話だけは聞いたことあるけどどうなったんだろうなアレ
0477デフォルトの名無しさん2010/07/16(金) 23:35:40
富士通とか携帯用プロセッサに乗っけてたな？
0478デフォルトの名無しさん2010/07/17(土) 01:41:41
>>476
今のTexas InstrumentのARMプロセッサは多くが"Java Acceleration"
という機能を謳っているけど何なんだろう？
0479デフォルトの名無しさん2010/07/17(土) 19:24:26
？
04804782010/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ってすごいなあ。
0481デフォルトの名無しさん2010/07/17(土) 20:22:57
D&E読んでるけどなんで既にconceptあるの
0482デフォルトの名無しさん2010/07/17(土) 20:45:05
何も最近新しく出来た概念ってわけじゃない。
当時からアイディアはあったんだよ。

ちなみに、今とまったく同じautoは、すでに1982年に、C with Classesの一部として、禿によって実装されていた。
残念ながら、Cとの互換性の問題で、消さなければならなかったっけれど。
0483デフォルトの名無しさん2010/07/17(土) 20:50:30
昔はCで組んでたけど、autoなんて使った記憶ないなあ。
消さなきゃ良かったのに。
0484デフォルトの名無しさん2010/07/17(土) 21:06:15
元のautoを有効利用したことがある奴いるの？
0485デフォルトの名無しさん2010/07/17(土) 21:14:35
>>484
auto
って何に使うの？
0486デフォルトの名無しさん2010/07/17(土) 21:38:31
registerでないことを明示したい時に使う

void foo(){
int x;
&x;
}

こんなxを勝手にレジスタに置いてポインタが取れないと癇癪を起こしてたのさ
昔々のコンパイラは
04874852010/07/17(土) 21:41:08
元のauto、ね。
タイプ量を増やす以外の役割は？？
0488デフォルトの名無しさん2010/07/17(土) 21:42:05
>>486
あ、ごめん、
> 昔々のコンパイラは
ね。
ってことは、途中で規格が改訂されて省略可能になったわけか。

ありがとうございます。
0489デフォルトの名無しさん2010/07/18(日) 11:33:32
昔のコンパイラはレジスタ配置すら人力だったのか……
0490デフォルトの名無しさん2010/07/18(日) 11:36:55
絶望した。

std::vector<int>& Get(){
    return vec;//クラス内で宣言済み
}
上のようなメソッドが有って、

auto vec = hoge.Get();

ってやったら、ムーブかコピーだった。参照で受け取れるとおもったんだが。
で、結局

auto& vec = hoge.Get()

ってやったら意図通りになった。＠VC10
0491デフォルトの名無しさん2010/07/18(日) 12:02:20
>>490 の通りが普通だと思ってたんだけど、
規格上の動作はVC10と違うの?
0492デフォルトの名無しさん2010/07/18(日) 12:09:28
auto var = exp;はexpの評価されたTypeがvarの宣言/定義に使用される。
たとえhoge.Get()が参照を返したとしても、式中では参照のついたstd::vector<int>&ではなくstd::vector<int>として評価される。
これは0xに関係なく今の時点でもそう。
どうしてもと言いたければboost::refを使って式中の評価を参照修飾にする必要がある。
0493デフォルトの名無しさん2010/07/18(日) 12:14:12
decltype
0494デフォルトの名無しさん2010/07/18(日) 12:24:12
>>490
どこを困ってるかわからん
0495デフォルトの名無しさん2010/07/18(日) 12:25:56
decltype((hoge.Get())) vec = hoge.Get()
0496デフォルトの名無しさん2010/07/18(日) 12:27:31
#define BOOST_AUTO(E, F) decltype(E) F = E;
04974902010/07/18(日) 12:31:26
返信ありがと～。

>>491
いやー、俺の勘違いのようですよ。
戻り値の型を評価されるんだと思ってたので、＆取られるのは気づきにくいなーと。

>>492
詳細ありがとう。理解が深まって助かるよ。
厳密にboostのようなものが必要だったわけじゃないからいいんだけど、
知らなかったら、コストかかるわ、バグの元になってるわで、自分的には不味かったんだ。

>>493
decltype先生はタイプ量増えるから難しいね。
0498デフォルトの名無しさん2010/07/18(日) 12:36:30
おっとっと。

>>494
最近はムーブされるから多少マシになったけど、その前はRVOか全コピーだからマズーって感じ？？

>>495-496
decltype先生は用途がむずかしいね。
0499デフォルトの名無しさん2010/07/18(日) 12:56:32
decltype で書かなきゃいけないの? と思ってfcd読み返したら
auto& みたいな書き方でOKだったじゃないか。

>>495 みたいなのは、&で返ってくるときは&で、
値で返ってくるときは値で受け取りたいときに使うってことだね。
05004902010/07/18(日) 14:00:35
>>499
なるほど。


皆さんありがとう。ノシ
0501デフォルトの名無しさん2010/07/18(日) 15:45:49
autoって互換性無くさなくてよくね？
今までだと
auto hoge h;
これからは
auto h = hoge();
だから別に構文は被ってないじゃん
0502デフォルトの名無しさん2010/07/18(日) 16:08:05
型を省略したらintとかそんなのなかったっけ？
0503デフォルトの名無しさん2010/07/18(日) 16:14:29
それはあまりにもフリーダム
0504デフォルトの名無しさん2010/07/18(日) 16:15:25
>>502
Cの戻り値がそんなんだったような気が
0505デフォルトの名無しさん2010/07/18(日) 16:17:11
まあ、いまだに残ってるんだよな。

unsigned x = 0 ;// unsigned int
0506デフォルトの名無しさん2010/07/18(日) 20:08:10
いや、unsigned x; は型名省略じゃない
0507デフォルトの名無しさん2010/07/18(日) 20:10:59
処理系の一番手ごろな型えらぶんだっけ？？
0508デフォルトの名無しさん2010/07/18(日) 20:55:31
いや、unsigned/signed は unsigned int/signed int の別名だから。
0509デフォルトの名無しさん2010/07/18(日) 20:59:05
signedなんて予約語あったっけ？
0510デフォルトの名無しさん2010/07/18(日) 21:00:04
あるよ
0511デフォルトの名無しさん2010/07/18(日) 21:04:04
static x; みたいな例の方がわかりやすい。
0512デフォルトの名無しさん2010/07/18(日) 23:10:06
関数定義の戻り値省略とかも
05132072010/07/19(月) 21:30:00
すみません
gccで現在コンパイルがC++0xとして行われているか判別する方法はないでしょうか
事前定義マクロのようなものはないでしょうか？
0514デフォルトの名無しさん2010/07/19(月) 21:31:19
auto a = test();とかやってみる
0515デフォルトの名無しさん2010/07/19(月) 21:43:07
>>514
すみません．言葉が足りませんでした．
コード中で0xに対応していればstd::threadを
対応してなければboost::threadを使う
といった使い方をしたいのです．
0516デフォルトの名無しさん2010/07/19(月) 21:47:26
#if __cplusplus > 199711L
でいいと思う
0517デフォルトの名無しさん2010/07/19(月) 21:52:10
ありがとうございます．
試してみます．
0518デフォルトの名無しさん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
少し不安ですがでいけました．ありがとうございました．
0519デフォルトの名無しさん2010/07/19(月) 22:02:50
>>518
！＝は不適切じゃないか？
0520デフォルトの名無しさん2010/07/19(月) 22:24:08
#if __cplusplus < 199711L
// 0x
#else
// boost
#endif

まだ少し不安ですがこうしてみました．
バージョンが新しいほど値が小さくなるのでしょうか
gcc version 4.4.3 で試しています．
0521デフォルトの名無しさん2010/07/19(月) 22:26:01
>>520
制定日を示してる
0522デフォルトの名無しさん2010/07/19(月) 22:28:55
greater than
0523デフォルトの名無しさん2010/07/19(月) 22:32:22
>>521
なるほど

__cplusplusの値を見てみたのですが
　msvcでは199711Lでした
　gcc version 4.4.3では1でした

まだ制定されていないからでしょうか．
FAQにあるように，199711L以外としか決まってないのでしょうか
しょうが無いので1の場合は0xと見なして処理してみます．
0524デフォルトの名無しさん2010/07/19(月) 22:33:23
いやgccは昔からずっと1にしてるぞ
0525デフォルトの名無しさん2010/07/19(月) 22:36:39
なるほどそうだったのですか
とりあえずgccはコンパイラのバージョンを見て決めることにしてみます
0526デフォルトの名無しさん2010/07/19(月) 22:42:52
gcc の場合 __GXX_EXPERIMENTAL_CXX0X__
0527デフォルトの名無しさん2010/07/19(月) 22:46:42
_HAS_CPP0X とか、もうね（ry
0528デフォルトの名無しさん2010/07/21(水) 19:28:23
>>527じゃダメなの？
0529デフォルトの名無しさん2010/07/21(水) 22:41:59
_から始まるからだめ
0530デフォルトの名無しさん2010/07/22(木) 19:12:44
コンパイラが定義する分にはいいんじゃね？
0531デフォルトの名無しさん2010/07/22(木) 19:14:12
書いてて気持ち悪いからやだ
0532デフォルトの名無しさん2010/07/23(金) 06:58:11
VS2010にThreadがないんだけど、まだ入ってないん？
0533デフォルトの名無しさん2010/08/02(月) 15:24:30
あん…
0534デフォルトの名無しさん2010/08/02(月) 21:37:46
ぱん…
0535デフォルトの名無しさん2010/08/03(火) 00:21:21
まん・・・
0536デフォルトの名無しさん2010/08/03(火) 00:30:21
あたらしい質問です

C++0xでは例外指定が消えただの何だのと聞いたんですが、
try-catchが消えるってことですか？
0537デフォルトの名無しさん2010/08/03(火) 00:33:40
>>536
違う。

throw()のこと
0538デフォルトの名無しさん2010/08/03(火) 01:54:09
finallyは欲しいところ
0539デフォルトの名無しさん2010/08/03(火) 03:24:46
>>537
throwができなくなるor非推奨になるって認識で良いんでしょうか
0540デフォルトの名無しさん2010/08/03(火) 03:34:37
>>539
関数の定義の際に、
int hoge() throw(なんとか) { ... }
という書式があったんだよ。
0541デフォルトの名無しさん2010/08/03(火) 08:57:07
>>538
欲しいよね
0542デフォルトの名無しさん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
0543デフォルトの名無しさん2010/08/03(火) 12:07:47
0xだとライブラリレベルのスコープガード実装で満足できる気がする
0544デフォルトの名無しさん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 > >(); // <-現実　少なくともこれ以上、呼び出し文を複雑にしたくない

関数テンプレートの特殊化は少なく、呼び出しは簡素な良い方法はないでしょうか？
0545デフォルトの名無しさん2010/08/03(火) 18:01:00
>544

struct {
template <typename T>
T operator()() const { return 0; }
} const zero = {};
0546デフォルトの名無しさん2010/08/03(火) 18:46:30
>>545
どうもコンパイルエラーがでる…

struct {
　template <typename T> operator T () const { return 0; }
} const zero = {};

として、

　special_value<int> i = zero;

だと、OK だった。
0547デフォルトの名無しさん2010/08/03(火) 18:52:24
>>545
>>546

結局、

　struct zero {
　　template <typename T> operator T () const { return 0; }
　};

とすれば、

　special_value< int > i = zero();

で、いける。
0548デフォルトの名無しさん2010/08/03(火) 20:27:04
>>545-547
検証した結果、その方法で全てOKでした。
使わせてもらいます。ありがとうございました。
0549デフォルトの名無しさん2010/08/04(水) 12:43:14
>>542
これは素晴らしい。惚れた
C++にこの構文を入れるプリプロセッサとかないものか
0550デフォルトの名無しさん2010/08/04(水) 13:12:10
Boost.ScopeExit
0551デフォルトの名無しさん2010/08/04(水) 18:58:10
>実際ソースコード上で視覚的に大きく離れてしまします。

素晴らしい日本語だな
0552デフォルトの名無しさん2010/08/04(水) 19:02:28
boostだと表記が長ったらしくて嫌
0553デフォルトの名無しさん2010/08/04(水) 19:54:13
最近のboostはPP厨すぎて付いていけない
0554デフォルトの名無しさん2010/08/05(木) 12:47:03
test
0555デフォルトの名無しさん2010/08/09(月) 19:03:39
本の話が出てこないな
0556デフォルトの名無しさん2010/08/09(月) 20:34:50
魔導書？ 面白かったけど、なんか話題のネタになるようなのあったっけ？
0557デフォルトの名無しさん2010/08/09(月) 21:01:08
このスレに出入りするような生粋にとっては特に目新しい情報なかったでしょ
0558デフォルトの名無しさん2010/08/10(火) 07:04:31
ゲームスレでも開いたのかと思った
0559デフォルトの名無しさん2010/08/10(火) 10:42:38
Variadic Templatesはケーススタディが微妙だった
0560デフォルトの名無しさん2010/08/19(木) 16:52:53
0xおわったな・・・
0561デフォルトの名無しさん2010/08/19(木) 17:18:57
始まってすらいねーよ
0562デフォルトの名無しさん2010/08/19(木) 20:00:26
まずCスタイルキャストの廃止をだなry
0563デフォルトの名無しさん2010/08/19(木) 22:50:13
>>562
そんな事したら、だれも使わなくなると思うんだな
0564デフォルトの名無しさん2010/08/20(金) 08:36:22
じゃあ、Cスタイルのキャストをstatic_castと同じ意味にすれば
0565デフォルトの名無しさん2010/08/20(金) 11:45:51
互換性パラノイアのC++に何を求めてるんだ
0566デフォルトの名無しさん2010/08/20(金) 17:58:05
キャストは長たらしくて面倒なんだよなあ
0567デフォルトの名無しさん2010/08/20(金) 20:03:46
Cスタイルキャスト便利だけど周知のとおりなんでも変形できちゃうからねぇ・・・。
最近はC++スタイルを使うように心がけてる。
0568デフォルトの名無しさん2010/08/20(金) 20:36:12
signed ⇔ unsigned
signed ⇔ 浮動小数点数
共にリテラルなのに処理が違うのは変だと思う。
0569デフォルトの名無しさん2010/08/21(土) 01:27:27
この言語は次世代を担う最強言語たりえるの？
0570デフォルトの名無しさん2010/08/21(土) 01:47:09
最強かは知らないが、もともと使ってた人にはステップアップできるいい改良。
根っこは腐ってしまったが、周辺は良好。
0571デフォルトの名無しさん2010/08/21(土) 02:24:40
>>566
むしろ面倒にしてあるからな
0572デフォルトの名無しさん2010/08/21(土) 10:22:55
>>569
最強に難解になることは間違いないかな
0573デフォルトの名無しさん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(); }

こんな感じで
仕様変えたい時にメンバ増やしてもコンパイル依存性は変わらないから便利だろ
ヘッダもすっきりするしな
0574デフォルトの名無しさん2010/08/21(土) 12:14:03
>>569
最強というか、そもそもC++が必要な領域では対抗できる言語が無いからね
Dはまだまだだし
0575デフォルトの名無しさん2010/08/21(土) 16:41:50
>>573
それ何年も前の本(ピアソンとか)で
そんなもん非メンバ関数で実装すればいいだろ
って書かれてた気がする
コンパイル依存性を変えないなら仮想関数に適用できなくなるし
しかもその例だと非拡張メンバ関数から拡張メンバ関数を呼び出してて
なお一層気持ち悪い
0576デフォルトの名無しさん2010/08/21(土) 16:54:34
非メンバ関数じゃprivateメンバーが見えないじゃん
なにかコードを追加しようとしたときに
そのコードがprivateメンバーを使ってて
さらに同じコードをなんども書く必要がある場合は
外部関数じゃできないんだからメンバー関数追加するじゃない普通
でもそのクラスをインクルードしてるファイルが死ぬほどたくさんあったらどうすんのよ
0577デフォルトの名無しさん2010/08/21(土) 17:03:52
>>576
設計がおかしいからリファクタリングしろ。

それと、ここは 0x のスレだから、提案されてもない機能の話題はスレ違い。
俺の考えた最強言語の話は自分のブログでやってくれ。
0578デフォルトの名無しさん2010/08/21(土) 20:01:14
>>576
そんな簡単にprivateに侵入されたらプライバシーもクソもないじゃない
0579デフォルトの名無しさん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は使えないんです
0580デフォルトの名無しさん2010/08/21(土) 20:46:13
>>579
const X　&で困るのってどんなとき？
05815792010/08/21(土) 21:16:43
あ、すいません自己解決しました
可変長引数にも普通にメタ関数使ってtypename foo<X>::type...って感じでコンパイル通るんですね

>>580
Hoge<int &>とかHoge<int &&>だとconst参照ではエラーがでますね
0582デフォルトの名無しさん2010/08/22(日) 10:56:02
constexperでCRCやMD5とか計算できるようにならないかな？
30バイトぐらいでもかまいません
0583デフォルトの名無しさん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);
}
0584デフォルトの名無しさん2010/08/22(日) 21:32:09
今更だけど64ビット定数は嫌がらせのように長いな・・・
0585デフォルトの名無しさん2010/08/22(日) 21:42:25
4096bit とかどうしようか
0586デフォルトの名無しさん2010/08/22(日) 21:52:38
桁数間違えそうだわ
0587デフォルトの名無しさん2010/08/22(日) 21:55:16
それもあってのconstexprなのかも
0588デフォルトの名無しさん2010/08/22(日) 22:02:51
0x8000 0000 0000 0000
こう書けばよい
0589デフォルトの名無しさん2010/08/22(日) 22:08:33
デバッガで追ってる時にポインタが
0x000000000485c77a
とか表示されるの拷問
0590デフォルトの名無しさん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\
やだよこんなの
0591デフォルトの名無しさん2010/08/22(日) 22:58:37
CRCってこうやって計算してるのかぁ
0592デフォルトの名無しさん2010/08/23(月) 03:06:11
ipv6みたいな短縮記法を使いたくなってくるよね。
0x80::01で0x8000000000000001になる的な。
0593デフォルトの名無しさん2010/08/23(月) 03:12:10
ユーザ定義リテラルの出番か
0594デフォルトの名無しさん2010/08/25(水) 01:51:35
void関数でreturnでvoidを返せるようにしましょうよ。
0595デフォルトの名無しさん2010/08/25(水) 02:12:42
return ; de ok
0596デフォルトの名無しさん2010/08/25(水) 02:14:44
>>594
現行の規格でも関数テンプレートならいけたはず。
何か具体的に通らなくて困ってるコードでもあるの？
0597デフォルトの名無しさん2010/08/25(水) 02:29:37
>>594
何バイト長の値が返されるの？
0598デフォルトの名無しさん2010/08/25(水) 15:15:08
>>490
この問題ですんごいはまってた。
そうか、仕様だったのか・・・
0599デフォルトの名無しさん2010/08/25(水) 15:58:50
>>597
コンパイラ上にだけ存在する常にvoidしか入らない0バイト長の型とか?
理論上の存在意義は分からんでもないが現実に嬉しいかというと微妙だなぁ
0600デフォルトの名無しさん2010/08/25(水) 16:19:18
void 型の値があることになったら、末尾呼出を常に return func(); と書けるな。
0601デフォルトの名無しさん2010/08/25(水) 18:31:03
void型値が存在すれば加減算とかが発生しない限り代入や比較は可能で構わないわけだから
void型の返値を受け取ってvoid型の変数に格納してvoid型の引数を取る関数に渡すとか有りか

最終的に評価が発生するところだけvoid型で特殊化できるという意味で理論上の適応はあるな
誰が得するのか知らんが
0602デフォルトの名無しさん2010/08/25(水) 22:07:59
sizeofが0の型はカオスを引き起こすからダメです
0603デフォルトの名無しさん2010/08/25(水) 22:44:13
あー、0除算で死んだりするのか・・・。
0604デフォルトの名無しさん2010/08/25(水) 22:50:38
コンパイル時定数なんだからソレは問題に成らんでしょ
0605デフォルトの名無しさん2010/08/26(木) 01:34:13
コンパイル時定数を普通の変数に代入して使うこともあるわけで、問題なくなるわけがない。
0606デフォルトの名無しさん2010/08/26(木) 01:40:03
関数は必ず、void func(int)だろうと何だろうと
何かしらの値を返す、
ただ、void型の場合はその値に意味なんてないですよ

ってんだと俺は勝手に思っていた。
そして、コンパイラがその値を参照しようとすると
コンパイルエラーになるようにしているんだと思っていた。
0607デフォルトの名無しさん2010/08/26(木) 04:42:09
perl病
0608デフォルトの名無しさん2010/08/27(金) 01:39:06
void func2();

void func()
{
return func2();
}

これができるとテンプレートとかでvoidだけ例外処理する必要なくなるので嬉しい。
0609デフォルトの名無しさん2010/08/27(金) 08:33:23
それはもう出来るんじゃなかった？
0610デフォルトの名無しさん2010/08/28(土) 02:32:30
早く言えよ！
すこしコードがすっきりしたぜ。
0611デフォルトの名無しさん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
0612デフォルトの名無しさん2010/08/28(土) 22:11:46
最新ドラフトは N3126 ね。

> Added new issues 1091, 1092, ... and 1173.
３週間ほどで追加されすぎｗ
0613デフォルトの名無しさん2010/08/29(日) 10:24:32
相変わらずJPのNBコメントは質が低いのう……
0614デフォルトの名無しさん2010/08/29(日) 17:52:51
813さんが質の高いコメントを出していただけないため。
0615デフォルトの名無しさん2010/08/29(日) 19:49:22
えらいロングパス出したな
0616デフォルトの名無しさん2010/08/29(日) 22:26:08
ゴールラインを割りましたので
スローインから再開です
0617デフォルトの名無しさん2010/08/30(月) 19:43:12
わしがC++0x校長【自粛】である
http://www.asahi.com/science/update/0830/TKY201008300162.html
0618デフォルトの名無しさん2010/08/30(月) 19:59:37
結局継承関係もalignasも予約語になるんだな
attributeとは一体何だったのか
0619デフォルトの名無しさん2010/08/30(月) 20:13:11
>>617
なんか見出しがgigazineだなw
0620デフォルトの名無しさん2010/08/30(月) 21:54:19
禿って蔑称？愛称？敬称？
0621デフォルトの名無しさん2010/08/30(月) 22:22:09
その全て
0622デフォルトの名無しさん2010/08/30(月) 22:27:48
日本の在日禿＝蔑称
Bなんとかの禿＝尊称
0623デフォルトの名無しさん2010/09/02(木) 03:06:04
std::unique_ptr<Type []>の知名度が低すぎる
　　 　　　　　　　　　　 ~~
0624デフォルトの名無しさん2010/09/02(木) 05:40:37
配列生成しても適当に開放してくれるの？？
0625デフォルトの名無しさん2010/09/02(木) 08:14:47
そうだよ。 boost::scoped_array 相当だね。
0626デフォルトの名無しさん2010/09/02(木) 08:23:39
おぉー。オペレータがどういう感じになってるか興味あるかも。
delete[] で両方開放できるんだっけ？？
0627デフォルトの名無しさん2010/09/02(木) 08:35:39
delete[] しないためのものだろうに。何言ってるの？
0628デフォルトの名無しさん2010/09/02(木) 09:14:36
あるぅぇ？？
0629デフォルトの名無しさん2010/09/02(木) 10:47:24
default_deleteがT[]で特殊化されてるからか
なるほど
0630デフォルトの名無しさん2010/09/02(木) 18:39:10
>>627
どう見てもお前が流れを理解してない
0631デフォルトの名無しさん2010/09/02(木) 20:20:29
struct Hoge {
void swap(Hoge& rhs) {}
Hoge& operator=(Hoge&& rhs) {
swap(rhs);
}
上記のコードのように、右辺値参照である rhs を 非const参照を受け取る swap に渡すことは仕様的に合法なのでしょうか？
0632デフォルトの名無しさん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++標準化委員会のひとはいうことが違うな
0633デフォルトの名無しさん2010/09/02(木) 21:58:29
>>632
何か変なこと言っている？？
> やっぱC++標準化委員会のひとはいうことが違うな
0634デフォルトの名無しさん2010/09/02(木) 22:07:02
>>632
こんなんよく見つけるな。面白いねー。
0635デフォルトの名無しさん2010/09/02(木) 22:12:45
つまんね
くだらない記事はるなよ
0636デフォルトの名無しさん2010/09/04(土) 20:15:28
規格で許されていることをバグとして報告する輩にはもっと▽してやれ
0637デフォルトの名無しさん2010/09/09(木) 16:43:35
C++相談室に0xに関する質問したので来て答えてくれませんか？
どうせ暇でしょ。
0638デフォルトの名無しさん2010/09/09(木) 19:13:05
>>637
どれ？
0639デフォルトの名無しさん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
0640デフォルトの名無しさん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 の対応が入ってなくて試せない。
0641デフォルトの名無しさん2010/09/11(土) 01:34:07
>>640
それは通らない。
なぜならば、Fooの最初のデータメンバーであるBooは、0では初期化できない。

Boo boo = 0 ; // エラー

よって、次の文もエラーとなる

Foo foo[100] = {0}; // エラー

これなら通る
Foo foo[100] = { } ;
0642デフォルトの名無しさん2010/09/11(土) 01:37:20
そもそも、C++0x以前の話。
ttp://cpplover.blogspot.com/2010/09/aggregate.html
0643デフォルトの名無しさん2010/09/11(土) 02:44:21
>>641
だよな。

↓こいつ何言ってるんだろう？
http://hibari.2ch.net/test/read.cgi/tech/1280914463/572
0644デフォルトの名無しさん2010/09/11(土) 02:47:58
>>642
> MSVCは、「'A::b' : non-aggregates cannot be initialized with initializer list」などというエラーを吐く。
> これは、規格上間違っている。

これ、 C++2003 では正しいエラーだよね。

> この分では、C++0xの初期化リストの対応も、あまり期待できそうにはない。

まだ対応してないんなら、上記のエラーで当然だと思う。
0645デフォルトの名無しさん2010/09/11(土) 10:31:43
Foo foo[100] = { Boo(), 0 };
0646デフォルトの名無しさん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)
{
0647デフォルトの名無しさん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);
}

見たいな感じで列挙するしかないの？
0648デフォルトの名無しさん2010/09/11(土) 12:48:14
完全転送は右辺値参照でしか再現できないぞ
0649デフォルトの名無しさん2010/09/11(土) 13:30:14
そんなことはない
boostにc++03でムーブするライブラリあるし
右辺値参照は単に書きやすさの問題
0650デフォルトの名無しさん2010/09/11(土) 13:31:39
>>649 ムーブじゃなくて完全転送（ perfect forwarding ）の話だろう。
0651デフォルトの名無しさん2010/09/11(土) 13:36:16
そもそも右辺値のないC++03なら>>647で最大効率じゃない？
0652デフォルトの名無しさん2010/09/11(土) 13:55:51
なぜ03で再現したいのか
0653デフォルトの名無しさん2010/09/11(土) 14:09:14
03で再現したくもない機能なんて0xにもいらないだろ？
0654デフォルトの名無しさん2010/09/11(土) 21:04:06
>>647
const、volatile修飾で動作を変えないなら後ろの２つは要らないんじゃない?
06556542010/09/11(土) 21:06:38
2つじゃなくて3つ
0656デフォルトの名無しさん2010/09/11(土) 21:24:12
３つ消したらテンポラリを受け取れないね
06576542010/09/12(日) 00:32:47
>>656
最初のテンプレートしかなければ
X const &
X volatile &
X const volatile &
全部最初のにマッチするでしょ？
0658デフォルトの名無しさん2010/09/12(日) 01:04:05
forward_test(Hoge());
がとれないよ
どうもforward_test<Hoge>って認識されるっぽい
06596542010/09/12(日) 12:17:57
>>658
仰るとおりです。
0660デフォルトの名無しさん2010/09/15(水) 09:20:51
Hoge()はprvalueだから、rvalueへのリファレンスでなければ取れない。
constなlvalueリファレンスでrvalueを束縛できるのが、そもそもおかしいんだよ。
0661デフォルトの名無しさん2010/09/15(水) 13:27:26
rvalue/lvalueを理解してないやつがunique_ptr使ってコンパイル通らないとか言ってるの見ると笑える
0662デフォルトの名無しさん2010/09/15(水) 14:54:51
>>661
君がそれで苦労したと言いたいのか？

レベル低すぎ
0663デフォルトの名無しさん2010/09/15(水) 14:58:50
struct Foo
{
Bar bar;
Baz baz;
};

Foo foo;

Foo fooo(move(foo));

ってやった場合fooo.barとfooo.bazのコンストラクタは右辺値参照のやつが呼ばれるって決まってるの？
0664デフォルトの名無しさん2010/09/15(水) 15:07:48
>>663
絶対呼ばれない
0665デフォルトの名無しさん2010/09/15(水) 17:33:37
ということは、ちゃんとムーブコンストラクタのなかで各要素をmoveしてやるひつようがあるのね。
0666デフォルトの名無しさん2010/09/15(水) 18:12:08
当然です
0667デフォルトの名無しさん2010/09/15(水) 20:22:51
Bar, Bazがmove可能として
　Foo& operator=(Foo&&) = default;
とクラス定義中に書いとけばいいんじゃね?
0668デフォルトの名無しさん2010/09/15(水) 20:47:56
デフォルトムーブが入ったから>>663でいいんじゃないの？
0669デフォルトの名無しさん2010/09/15(水) 21:03:07
そのdefaultだとメンバ全部moveしてくれるの？
0670デフォルトの名無しさん2010/09/16(木) 11:12:39
勝手にコード生成しない
explicit class Hoge;
構文があればいいのに
0671デフォルトの名無しさん2010/09/16(木) 13:26:59
>>667-669
根本的なところから理解出来てない

あのね、無理して使わなくていいんだよ、お前らには無理
0672デフォルトの名無しさん2010/09/16(木) 13:32:19
>>671
くだらないこといってる暇があったら質問に答えるなり解説するなりしたらどうなの？奴隷階級が生意気だよ
0673デフォルトの名無しさん2010/09/16(木) 14:20:35
>>672
他人に言う前に、自問自答すればいいのに。
酔っぱらいが「酔っぱらいは嫌いだ」って言ってるのと同じだろｗ
0674デフォルトの名無しさん2010/09/17(金) 09:53:29
12.8.10 節:
　ユーザー定義のコピーコンストラクタがなくて、
　かつムーブコンストラクタが暗黙にデリートされなければ、
　ムーブコンストラクタが暗黙に定義される。

12.8.17 節:
　暗黙のムーブコンストラクタは、メンバーごとにムーブを行う。

これだけ読むと >>669 は正しい気がする。
0675デフォルトの名無しさん2010/09/17(金) 09:56:05
すまん。×定義 ○宣言
0676デフォルトの名無しさん2010/09/17(金) 10:01:49
>暗黙にデリートされなければ暗黙に宣言される

明示的にデリートじゃないの？
0677デフォルトの名無しさん2010/09/17(金) 11:08:35
>>676
多分↓のことだと思う＞暗黙にデリート
12.8.12 節: コピー/ムーブコンストラクタは(中略)の場合、デリートされる。

あと、デフォルトのムーブコンストラクタのみだと、
最終的には
　「スカラー型は組み込みの代入演算子で初期化される」 (12.8.17)
に行きつくので、コピーするのと結局変わらない。
0678デフォルトの名無しさん2010/09/18(土) 22:27:30
extern templateってなんですかー！
exportとは違うんですか？
explicit instantationとも違うんですか？

全部ex.*で始まってて同じに見えます！！
0679デフォルトの名無しさん2010/09/19(日) 00:51:13
extern template + explicit instantation = export
0680デフォルトの名無しさん2010/09/19(日) 01:04:09
exportさんは死んだよ
0681デフォルトの名無しさん2010/09/19(日) 01:14:44
exportのキーワードは開放されたのかな？？
0682デフォルトの名無しさん2010/09/19(日) 01:16:30
The export keyword is unused but is reserved for future use.
0683デフォルトの名無しさん2010/09/19(日) 01:43:00
残ってるのね。教えてくれてありがとう。
0684デフォルトの名無しさん2010/09/19(日) 21:50:59
そういえば range-based for って enum では使いようがないね。

コンパイル時に enum の全要素はわかってるんだから
begin/end を適当に決定して内部的によろしくやってくれて
range-based for 文を使えるようにしてくれてもいいだろうと思わないでもない。
unroll も簡単にできるだろうし。ただ、型を直接置けないから
enum X {...}; とある場合、for (X x: X{}) とでもすればいいのかな。
0685デフォルトの名無しさん2010/09/19(日) 22:12:51
禿含めC/C++の委員はenum大嫌いだからあまりenumの扱いに期待しない方がいい
0686デフォルトの名無しさん2010/09/19(日) 23:27:24
enum classは？
0687デフォルトの名無しさん2010/09/19(日) 23:29:07
enumなかったらフラグが使いにくくて大変じゃない
0688デフォルトの名無しさん2010/09/19(日) 23:34:53
enumなかったら整数リテラルに名前を付けられないじゃない
0689デフォルトの名無しさん2010/09/19(日) 23:39:55
K&Rに「あんまり要望がうるっせーから仕方なく適当に入れてやった。クソが」
みたいなことが書いてあったと思う

それを受けてD&Eにも「Cのenumがテキトーすぎてクソまみれなので、仕方なくC++で少しクソを拭うことになった。ちくしょう」みたいなことが書いてある
あと「どうせお前らが欲しいのはこれだろ→enum BOOL{FALSE,TRUE}。bool使え」とか
0690デフォルトの名無しさん2010/09/19(日) 23:47:56
望まれてるのはenum classなんかじゃなくて、Pascal系の部分型も作れて集合も扱える列挙型か、
あるいは関数型言語のバリアントかと思うんだけど、どうしてこうなった
0691デフォルトの名無しさん2010/09/20(月) 02:24:35
enumは不要
static な定数用に class を自分で定義すればいいだけ
0692デフォルトの名無しさん2010/09/20(月) 02:30:24
それって、case部分に書けないだろ……
0693デフォルトの名無しさん2010/09/20(月) 08:39:15
range-base for ってそういやVC10に入ってないよな
あるとかなり便利になると思うんだが
実装難しいのかな？
0694デフォルトの名無しさん2010/09/20(月) 10:37:44
コンセプトの仕様が七転八倒してたから入れようが無かったんじゃないのかな？
おいらはBOOST_FOREACHをforeachに#defineして使ってる。カウンタ変数にautoも使えて便利でござる。
0695デフォルトの名無しさん2010/09/20(月) 12:46:48
VC10を開発していた時には、まだコンセプトはドラフトに入ってたんだろう。
というかMSVCはC++コンパイラとして未来がないと思う。
どんなバグ報告をしようと、
「それは些細な問題だから、次のリリースでも直す予定はない」
ときたもんだ。

MSVCはもはや、C++コンパイラ界のIEみたいなもんだぜ。
0696デフォルトの名無しさん2010/09/20(月) 12:55:41
ひとつのコンパイラ以外ついていけない言語になってしまうと、もはや規格の意味もなくなるけどね……
0697デフォルトの名無しさん2010/09/20(月) 17:25:46
うっかり実装した結果、0xの仕様変更に合わせて次期バージョンで非互換が出るなんてことは、
商用コンパイラではなかなか難しいからなぁ。
0698デフォルトの名無しさん2010/09/20(月) 17:38:12
誰がC++0xだといった。C++03すら壊滅的に酷いじゃないか。
0699デフォルトの名無しさん2010/09/20(月) 18:21:58
c++03との仕様の乖離だったらスレチ
0700デフォルトの名無しさん2010/09/20(月) 18:24:05
コンセプトが削除された理由がイマイチ分からない

どこかで、「コンセプトマップを書くのが面倒くさい」というような記事を読んだことがあるが、
そのあたりの詳細に詳しい人いる？

一般のプログラマも、コンセプトマップを書くことになるのは分かるのだが、
そのことが、コンセプトを規格から外す理由になった経緯が分からん。

だって、一般のプログラマは、そんなに頻繁にコンセプトマップ書くとは思えないから
0701デフォルトの名無しさん2010/09/20(月) 18:32:25
そもそもコンセプトとはどうあるべきかって所で意見がまとまらなかったから見送られたから
書くのが面倒くさいからどうこうという浅い理由じゃないよ
0702デフォルトの名無しさん2010/09/20(月) 18:42:04
0xの機能をふんだんに使ったconcept_checkingライブラリで妥協するしかないか
とはいうもののconcept_checkingだけでも十分便利だから期待はできそうか
0703デフォルトの名無しさん2010/09/20(月) 19:04:49
boost concept checkは便利だわ。これを規格化できないかな。
0704デフォルトの名無しさん2010/09/20(月) 19:26:52
>>693
一応VCは拡張 for each in があるよね?
0x に提案されてるのとちょっと文法違うけど
0705デフォルトの名無しさん2010/09/20(月) 19:32:31
なにそのC#
0706デフォルトの名無しさん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
0707デフォルトの名無しさん2010/09/20(月) 23:42:33
gotchaという自覚はあるんだな
0708デフォルトの名無しさん2010/09/23(木) 16:43:42
>>695
そんなの昔からだ
VC6 ≒ IE6
0709デフォルトの名無しさん2010/09/23(木) 20:52:46
03のコードってムーブコンストラクタを書き足さないと場合によってはバグる？
書いてない場合はムーブ禁止みたいなオプションないのかな
0710デフォルトの名無しさん2010/09/23(木) 22:17:22
全メンバがムーブ可能なら勝手にムーブコンストラクタが作られる、ただしVC2010は(ry
禁止させるならX(X&&) = delete; ただしVC2010は（ry
0711デフォルトの名無しさん2010/09/24(金) 00:02:18
こっちが何もしなければ、STLがバグってない限り大丈夫だろ。

デフォルトのムーブ動作はコピーすることだし、
コンストラクタ呼び出しが省略される条件もコピーコンストラクタと同じ。
0712デフォルトの名無しさん2010/09/24(金) 00:58:34
ポインタメンバ変数はデフォルトムーブされるの？
デフォルトコピーされるのも考え物だけど
0713デフォルトの名無しさん2010/09/24(金) 01:06:59
もちろん、ポインター、というかすべてのスカラー型もムーブされる。
ただし、その「ムーブ」とやらは、単に組み込みの代入演算子を呼び出すだけだが。
まあ、メンバーは、普通はポインターじゃなくて、unique_ptrで持つわな。
0714デフォルトの名無しさん2010/09/24(金) 12:01:12
そんなこといちいち気にしてると禿るぞ



Bjarneの頭は必然だったわけか…
0715デフォルトの名無しさん2010/09/24(金) 20:44:12
ムーブ可能なクラスは、必ずしもコピー可能とは限らない。
（例えばストリームクラスなど）

そこで質問ですが、

［コピー可能クラスの集合］ ⊂ ［ムーブ可能クラスの集合］
（つまり、コピー可能ならば、常にムーブ可能か）

ですか？それとも

［コピー可能クラスの集合］ と ［ムーブ可能クラスの集合］ は無関係
（つまり、コピー可能性とムーブ可能性は無関係か）

ですか？
0716デフォルトの名無しさん2010/09/24(金) 21:01:36
class X{
X(X&&) = delete;
X& operator=(const X&) = default
X(const X&) = default
};
07177152010/09/24(金) 22:24:18
>>716
そうですよね。ありがとうございました。
0718デフォルトの名無しさん2010/09/24(金) 23:44:03
ムーブって理解できない俺がいるんだけど、
自分の設計する全クラスに用意しなくてもいいんだよね？

用意してやることで効率が改善されると考えられる自作クラスにのみ
用意してあげればいいんだよね？？

0719デフォルトの名無しさん2010/09/24(金) 23:59:32
あと値渡しは出来るけどコピーは出来ないクラスもな（mutexとか）
0720デフォルトの名無しさん2010/09/25(土) 12:58:46
効率なんてRVO/NRVOに任せてムーブOKコピーNGのクラスにだけ用意しとけばいいよ
0721デフォルトの名無しさん2010/09/25(土) 13:06:39
既存クラスのほとんどはムーブNGコピーNGだろうけどな
0722デフォルトの名無しさん2010/09/25(土) 13:07:08
んなわけねーだろカス
0723デフォルトの名無しさん2010/09/25(土) 13:27:35
だってintやポインタのメンバを鬼のように持ってるクラスにとってはムーブもコピーと一緒だろ
ムーブも出来るのかもしれないけど禁止だね
0724デフォルトの名無しさん2010/09/25(土) 13:30:26
pimpl使えカス
0725デフォルトの名無しさん2010/09/25(土) 13:31:55
ぴんぷる！
0726デフォルトの名無しさん2010/09/25(土) 13:56:36
ムーブのためにレガシーコードは全部pimplに書き直せって？青いなあ
理想も結構だけど、勝手に古いコード壊すなよ
0727デフォルトの名無しさん2010/09/25(土) 15:36:43
>>726
テンプレートでラッパー作ればpimpl化なんて即終了ですよね
ひとつひとつ修正するとか笑わせないでくださいよｗｗｗ
0728デフォルトの名無しさん2010/09/25(土) 15:47:50
>>721,723
バ　カ
0729デフォルトの名無しさん2010/09/25(土) 15:53:02
std::type_infoのように、コピーもムーブもする必要のないクラスなら、
別にそれでいいんじゃね？
「既存クラスのほとんど」ってのは疑問だがな。
0730デフォルトの名無しさん2010/09/25(土) 16:19:24
まあ３割くらいはコピー不要かも
0731デフォルトの名無しさん2010/09/25(土) 18:23:16
>>723
ポインタを素で置いてるのはバグの元。unique_ptrやshared_ptrやboost::scoped_ptrを使おうぜ。
コピーやムーブの可否が自動的に適用されるよ
0732デフォルトの名無しさん2010/09/25(土) 18:26:21
コードの芸術性からしたらポインターは生だろー
実用品を作ってる職業プログラマーはスマートポインターを使うべきだと思うけどね。
0733デフォルトの名無しさん2010/09/25(土) 18:38:58
正直、ポインタ周りで厄介なバグだしたためしがないので
いまいちリッチなポインタ使う動機がない
0734デフォルトの名無しさん2010/09/25(土) 18:39:07
でもshared_ptrではオーバースペックだしunique_ptrじゃ使いにくいってケースのが多いよね実際
0735デフォルトの名無しさん2010/09/25(土) 18:40:14
C++から外に出ようとするとな
0736デフォルトの名無しさん2010/09/25(土) 18:50:53
>>732
逆だろ。RAII こそ芸術。
0737デフォルトの名無しさん2010/09/25(土) 19:08:31
確かに芸術だな
実用コードでは全く使い物にならないという意味で
0738デフォルトの名無しさん2010/09/25(土) 19:11:01
RAII普通に良く使うけど
0739デフォルトの名無しさん2010/09/25(土) 19:15:41
ちゃんとRAII適用していいか熟考した上で使うのはいいよ
何も考えずに解放が必要な物にホイホイ使ってるなら危なすぎるから今すぐ止めろ
0740デフォルトの名無しさん2010/09/25(土) 19:19:36
解放っていうか、開始処理と終了処理がセットになってる物で
スコープ内の一時利用で済むような機能はリソース獲得関係なくRAIIにするでしょ。
0741デフォルトの名無しさん2010/09/25(土) 19:20:25
開放が必要なものに使わない方が怖いだろアホか？
0742デフォルトの名無しさん2010/09/25(土) 19:23:09
解放処理に失敗する可能性のあるものにはさすがに使わんでしょ
0743デフォルトの名無しさん2010/09/25(土) 19:26:27
んなこと言ったらなんにも使えねーだろ
0744デフォルトの名無しさん2010/09/25(土) 19:28:07
だから実用的には何にも使えないんだよ
RAIIは「リソース解放は絶対に失敗しない」という仮定に全面的に依存している
そして大抵のリアルなリソースはそうではない

けど「RAIIは素晴らしいからみんな使おう^^」とか言ってる無責任な本やwebの多くはそんなこと触れてない
そのせいで間違った利用が横行している
恐ろしい
0745デフォルトの名無しさん2010/09/25(土) 19:30:24
開放に失敗したらキューに入れといてプログラム終了時に例外的に処理するんだよカス
0746デフォルトの名無しさん2010/09/25(土) 19:32:05
リソースに使わんかったらええねん
お前ら、beginXXX() ～ endXXX() とかやるときあるだろ
そういうのに使えないか確認してみよう
0747デフォルトの名無しさん2010/09/25(土) 19:33:20
そのendXXX()は戻り値持たないの？絶対に失敗しないの？
安易にRAIIを使う前に確認してみよう
0748デフォルトの名無しさん2010/09/25(土) 19:34:16
外部要因に依存してなかったら失敗も糞もあらへん
0749デフォルトの名無しさん2010/09/25(土) 19:34:47
>>745
ほう、そのプログラムは解放に失敗したファイルやロックを自分が終わるまで握り込むのか
はた迷惑なプログラムだな
0750デフォルトの名無しさん2010/09/25(土) 19:37:31
間違ったRAIIをあろうことか標準ライブラリがやってるの有様だからなぁ
fstreamは万死に値する
0751デフォルトの名無しさん2010/09/25(土) 19:41:56
>>749
お前の実行環境が分からんが
解放が失敗したリソースはどうすればいいんだ？
もう一度解放を試みるのか？
0752デフォルトの名無しさん2010/09/25(土) 19:45:03
>>751
失敗の仕方次第だろ
戻り値やerrnoを見てしかるべき処置を執る
もう一度解放が必要かもしれないし、解放不要でそのまま正常系に戻れるかもしれないし、致命傷でプログラムを落とす必要があるかもしれない
実用的プログラムを謳うならそこまでちゃんとしないとね
0753デフォルトの名無しさん2010/09/25(土) 19:46:46
終了処理が成功したかどうか確認しなくても良い機能ってわりとあるような。
それに失敗したときはassertする時って事わりと多くね。
0754デフォルトの名無しさん2010/09/25(土) 19:56:34
0x関係無い
釣り乙
0xだとλがあるからscope exit風な処理もマクロで実装出来るね
と無理矢理0xに繋げるﾃｽﾄ
0755デフォルトの名無しさん2010/09/25(土) 20:03:11
匿名テンプレート
0756デフォルトの名無しさん2010/09/25(土) 22:15:35
RAIIを理解できないやつがRAIIを否定するんだよ
0757デフォルトの名無しさん2010/09/26(日) 00:12:55
std::set_new_handlerみたいに
失敗時のハンドラを登録できるRAIIを用意すればいんじゃね？
失敗が怖いからRAIIを使わないってのは怖がりすぎな気が

hoge_ptr<T> hoge = ...;

hoge.set_handler([](){
// リソースの解放失敗時に呼び出される
});
0758デフォルトの名無しさん2010/09/26(日) 00:42:08
アホだから相手にするな
0759デフォルトの名無しさん2010/09/26(日) 00:42:29
>>753
そのための例外だね
>>757
例外のほうがすっきりすると思うよ。
0760デフォルトの名無しさん2010/09/26(日) 00:53:09
>>757
RAII解放時のエラー処理の話なんだから例外使うとまずい。
デストラクタで例外はC++的にヤバすぎて使えない。
だからハンドラ作って処理させるという逃げの一手にしてるわけで
0761デフォルトの名無しさん2010/09/26(日) 00:53:50
うおっとレス先間違えた
× >>757
○ >>759
0762デフォルトの名無しさん2010/09/26(日) 00:57:03
エラーハンドラとかわざわざ構造を複雑にするだけじゃん
デリーターをラップしてその中で処理しろよ
0763デフォルトの名無しさん2010/09/26(日) 01:05:32
RAIIはりソースの管理が本命だから、デストラクタ内例外はterminateかログして握りつぶす出よいんじゃないか？
リソース開放でエラーってヒープ破壊のようなクラッシュ直前のよっぽど異常な状態だろう。
0764デフォルトの名無しさん2010/09/26(日) 01:07:14
>>762
あー確かにそのとおりだわ。
ハンドラ作るより素直だし良いコードになるね。
うーん何で思いつかなかったんだろ。自分の頭の硬さが嫌になるわ。
0765デフォルトの名無しさん2010/09/26(日) 01:12:09
デストラクタで例外とか
0766デフォルトの名無しさん2010/09/26(日) 01:14:59
>>763
ネットワーク越しのファイルとかみたいに
割と日常的にclose(というより正確にはclose時のflush)に失敗しそうなものがあるから困る。
しかも時間をおけば成功しそうだから下手に握りつぶすのも悪手な感じだし。

まぁそんなわけでリソース解放の失敗は別にレアケースではないよと。
0767デフォルトの名無しさん2010/09/26(日) 01:21:25
みんななんでそんなクリティカルな所にRAII使うんだ
0768デフォルトの名無しさん2010/09/26(日) 01:26:39
C++でRAII以外にどうやる？
で、そのRAII以外の方法はデストラクタに入れられない？
0769デフォルトの名無しさん2010/09/26(日) 01:38:48
別に普通にデストラクタに書いていいよ
デストラクタでやるメリットはスコープ抜けるタイミングを気にしなくていいとこだかんね
デストラクタ内でリトライしてもいいし、ログってもいいし、無視してもいいし、アプリをアボンしてもいい
デストラクタの中で普段やってるリソース開放処理をやるだけ
ただし成功するまでリトライみたいな無限ループと例外だけは使ってはいけない
0770デフォルトの名無しさん2010/09/26(日) 01:58:40
よくできたRAII用クラスは明示的解放用のメンバがあるだろ。
解放失敗がクリティカルだったり失敗することが多い状況では
そのメンバ使った明示的解放と失敗時の処理をすればいい。

そんなことシラネってやつが何も考えずにRAII使っても
リソース解放処理が自動で行われる(成否はともかく)という点で
生ポインタや生ハンドル使って解放忘れてリークおこすよりマシって話じゃないの。
0771デフォルトの名無しさん2010/09/26(日) 02:12:03
それはよくできた設計ではないんだよ、本当は
明示的開放が用意されてるってことはdtorでの自動処理では問題が起こる可能性があるってこと
dtorでの開放は危険性がまだ残ったままなのに安全に処理しているような錯覚を生み出す
危険性を認知していないまま安全だと思い込むことはただのうっかりよりも恐ろしい（様々な分野で致命的な事故が起こる原因の多くは間違った安心感からだ）
本来ならばdtorでリソースの生死を判断して生きているならassertするべきなんだよね
0772デフォルトの名無しさん2010/09/26(日) 02:14:48
assertの意味わかってる？
「表明」だよ
0773デフォルトの名無しさん2010/09/26(日) 02:18:49
そうだよ
「適切な開放処理を経由している」って条件を表明してるんじゃん
0774デフォルトの名無しさんNGNG?2BP(0)
相変わらずここはレベルの低い話してるな
0775デフォルトの名無しさん2010/09/26(日) 11:38:42
例外って本当に必要なんだろうか
0776デフォルトの名無しさん2010/09/26(日) 11:43:33
newに失敗したらnullを返す方がいいのか
0777デフォルトの名無しさん2010/09/26(日) 12:04:33
例外もパワフルすぎて使い方を誤ると酷いことになる機能だな。
入門書とかひたすら「便利でしょ！」みたいな感じだから、みんな勘違いしたままになる。
0778デフォルトの名無しさん2010/09/26(日) 12:35:01
便利な機能を駆使して
落とし穴を巧妙に一生懸命
作ってるようなもんだよなあ
0779デフォルトの名無しさん2010/09/26(日) 12:50:20
デストラクタで例外投げれない仕様が全部悪いんだ
何とかならないのか
0780デフォルトの名無しさん2010/09/26(日) 12:53:11
被せるより生だろ
被せた方が安全かもしれないけど
後処理が出来てれば生の方が
気持ちいいし絶対生。
0781デフォルトの名無しさん2010/09/26(日) 12:55:07
そして妊娠（リーク）へ……
0782デフォルトの名無しさん2010/09/26(日) 12:58:50
>>779
例外巻き戻し中に例外を投げたときのエレガントな動作を定義してくれればデストラクタでの例外が可能になるよ。
デストラクタはリソース開放しかしないようにすれば例外投げる必要はなくなるんだよね。
0783デフォルトの名無しさん2010/09/26(日) 13:11:19
またリソース解放は絶対失敗しないという思い込みか
失敗しないリソース解放なんてfreeとdeleteくらいだというのに
0784デフォルトの名無しさん2010/09/26(日) 13:15:50
稀に失敗するからこその例外だろ
つまりRAIIと例外処理は相補的でC++の設計が理にかなってることを示している
0785デフォルトの名無しさん2010/09/26(日) 13:17:21
deleteが失敗するのはヒープが破壊されてる常態だから考えなくても良いな
0786デフォルトの名無しさん2010/09/26(日) 13:20:56
RAIIってなんて発生してるの？

ん、俺か？

俺は　雷ッ　だな
0787デフォルトの名無しさん2010/09/26(日) 13:23:11
ラツー
0788デフォルトの名無しさん2010/09/26(日) 17:22:22
リソース解放は絶対失敗しないという前提でRAII使いまくればいいよ。
現在大きな問題になってる解放忘れによるリークをなくすことが第一。
その後で解放失敗によるリークが無視できない問題になれば
ハードウェアやOSの設計レベルでのリソース管理法の見直しも含めて新たな手法が考案されるよ。
0789デフォルトの名無しさん2010/09/26(日) 17:40:35
わざとポインターのデータを開放しない場合に間違って
ＲＡＩＩを使って開放されてしまう間違いも同等に起きるから
どっちもどっちとしか言わざるをえない。
0790デフォルトの名無しさん2010/09/26(日) 17:43:15
>>789
解放しないクラスを作ればいいだけだろ
0791デフォルトの名無しさん2010/09/26(日) 17:46:49
>>789
いやそれは設計がおかしいだろｗ
0792デフォルトの名無しさん2010/09/26(日) 20:26:16
リソース解放に失敗するって、思いつかないのだが、例えば？
>>766が言ってるclose時のflushはリソース解放じゃないし。
0793デフォルトの名無しさん2010/09/26(日) 20:42:51
close時の失敗として出てくるんだからそれはclose（リソース解放）の失敗だろ
792はファイル扱う時に常にflushしてからflushしないcloseをしてるの？
0794デフォルトの名無しさん2010/09/26(日) 21:03:11
close()明示したらflushされるけどRAIIに任せたらflushされずに尻切れトンボになる、
ってのもどうなんだろうな？
0795デフォルトの名無しさん2010/09/26(日) 21:09:05
そんなの解放のし忘れに比べれば些細なこと
RAIIを使わない理由にはならない
0796デフォルトの名無しさん2010/09/26(日) 21:22:18
>>792
closeの失敗としてバッファの値を何らかの原因で書き出せなかった場合か?
こんなのOSが悪いんでC++の知ったことじゃない。例としてWinが時々出す遅延書き込みの失敗でシステムのイベントとして記録される。

それでもRAIIとしてはファイルハンドルを閉じてしまえば責任を果たしたことになるだろう。
0797デフォルトの名無しさん2010/09/26(日) 21:22:54
>>793
I/Oエラーでflashに失敗しcloseがエラーを返した場合でもリソースは解放される。
少なくともリークは起こらない。
RAIIを使わないで信頼性／保守性の悪いコード書くよりは最後のデータをwrite
した後に明示的にflushするようにする方がマシだと思う。
0798デフォルトの名無しさん2010/09/26(日) 21:30:37
>>794
おいらはclose明示すればファイルを残し、closeされずにデストラクトされたらファイルを消すようにしてる。
これなら例外で抜けてもごみは残らない。
0799デフォルトの名無しさん2010/09/26(日) 21:30:53
RAII + 明示的に処理 はダメなのか？
管理しなきゃいけないものが複数出てきたとき
RAIIなしじゃ面倒そう
それこそ保守性の悪いコードが出てきそう
0800デフォルトの名無しさん2010/09/26(日) 21:32:50
>>799
>>798はそのRAII+明示処理の考え方。すっきりする。
0801デフォルトの名無しさん2010/09/26(日) 21:55:49
>>796
大事なデータの書き損じを、RAIIだと検知できないからって正常系に戻しちゃっといて
「OSが悪い。C++の知ったことじゃない。ファイルハンドル閉じたから責任を果たした」ってか。

おー怖い。絶対に他人様が使うプログラム書くなよ。
0802デフォルトの名無しさん2010/09/26(日) 22:14:01
>>801
遅延書き込みの失敗を受け取る方法を教えてくれ。
0803デフォルトの名無しさん2010/09/26(日) 23:13:57
>>802
だから例外や返却値に頼るのでなくハンドラを渡してコールバックしてもらえとあれほど…？…誰も言ってないな
0804デフォルトの名無しさん2010/09/26(日) 23:24:37
コールバックは処理が癒着するからイヤ
0805デフォルトの名無しさん2010/09/26(日) 23:58:31
>>802
現在の処理進行度と結果を示してる何かをポーリングで監視。
0806デフォルトの名無しさん2010/09/27(月) 00:04:32
>>801は遅延書き込みなんてウルトラ異常系までアプリ側で拾ってるのか・・・
0807デフォルトの名無しさんNGNG?2BP(0)
>>801
知ったか乙
0808デフォルトの名無しさん2010/09/27(月) 05:29:27
まあ普段はどうでもいいけど、いざ拾わないといけないとなったときに拡張できる余地は欲しいよな。
Windowsとか遅延書き込みに反応するためのAPIまであるし。
0809デフォルトの名無しさん2010/09/27(月) 10:03:43
>>796
趣味のプロブラムならそれでいい
商用ならクビ
0810デフォルトの名無しさん2010/09/27(月) 11:49:32
コンパイラに備わってない機能を
無理やり実装しようとするのがそもそもの間違い
RAIIを使いたければJavaでもC#つかえばいい。
0811デフォルトの名無しさん2010/09/27(月) 11:50:17
>>809
あなたならどのように実装する？
0812デフォルトの名無しさん2010/09/27(月) 11:53:13
プログラムを書かないのがプロなんだよ
0813デフォルトの名無しさん2010/09/27(月) 11:59:48
大体、日本人の癖にアメリカの合理主義に洗脳されて
なんでも実利主義でも儲け主義な企業がわるい。
日本人はもともと巧みで繊細な技術だから
無意味なところにもこだわるべき。
0814デフォルトの名無しさん2010/09/27(月) 12:48:05
プログラミングなんぞに頼らずに
すべてを手作業にすべき。
0815デフォルトの名無しさん2010/09/27(月) 13:47:05
これからの時代はプログラム言語作成言語という言語が出来て、
RAIIをオンにしたり構文の規則をカタマライズしたり
自分好みのプログラミング言語を作る時代に発展していくんだろうな。
0816デフォルトの名無しさん2010/09/27(月) 13:49:58
>>810
こいつ最高にアホ
0817デフォルトの名無しさん2010/09/27(月) 14:16:40
>>811
エラーが起きる可能性があることを前提すればよいだけの話
・正常に書き込めたかチェックする（使用した関数の戻り値とかのふざけた方法でなく）
・復旧できる仕組みを用意する
・バックアップを作成する
・データの保存は複数の系統で、重複して行う

趣味のプログラムなら「あららデータなくなっちゃた」で済むけど、
商用では絶対に許されないことだよ
0818デフォルトの名無しさん2010/09/27(月) 14:21:38
>>817
つまり fstream の仕様はどうするべきだ（だった）と言うの？

現状の仕様でも、趣味のプログラムならデストラクタ任せで、商用で
データロスが許されないなら明示的に close() して戻り値チェックすれば
いいってことで、問題ないんじゃないの？
0819デフォルトの名無しさん2010/09/27(月) 14:27:36
商用でもデータロストなんてよくあることだろWindows製品とか
0820デフォルトの名無しさん2010/09/27(月) 14:28:13
Linuxで動くソフトもわりとロストするよね。
0821デフォルトの名無しさん2010/09/27(月) 14:30:08
Linuxは自己責任だから
08228182010/09/27(月) 14:30:59
おっと fstream::close() は void だったか。 exceptions() を設定しとくか、
あとで fail() なり !good() なりでチェックするってことで。
0823デフォルトの名無しさん2010/09/27(月) 14:34:42
ファイルを書き込んでから
読み込んで書き込んだデータと一致するか調べないと本当に
正常に書き込めたかは分からないよ？
それでもやるの？
0824デフォルトの名無しさん2010/09/27(月) 14:36:28
チェックのための読み込みで失敗するかもしれない
0825デフォルトの名無しさん2010/09/27(月) 14:43:56
>>821
windowsも自己責任だよ
契約書(だれも読まないけど)にちゃんと書いてある
0826デフォルトの名無しさん2010/09/27(月) 14:48:53
>>823
printf だってちゃんと出力できたかどうかわからないのに
毎回戻り値ちゃんと見てるのか？
0827デフォルトの名無しさん2010/09/27(月) 14:49:34
自己責任が嫌なら自分でＯＳをつくりＣＰＵをつくるしかないだろう。
0828デフォルトの名無しさん2010/09/27(月) 14:52:22
>>825
どうみてもPL法違反だよな
0829デフォルトの名無しさん2010/09/27(月) 14:53:56
自分以外誰も信じないで全て疑って掛かるというのが商用だからね
0830デフォルトの名無しさん2010/09/27(月) 14:55:37
石橋を叩き壊して新しい橋を自分で作るというのが商用なんだろうね。
0831デフォルトの名無しさん2010/09/27(月) 14:57:16
一番信じられないのは自分だよ
0832デフォルトの名無しさん2010/09/27(月) 15:00:49
>>831気が合いますね！
0833デフォルトの名無しさん2010/09/27(月) 15:57:26
>>823
そういうのが手間だからやらないとでも？

書き込んだはずのデーターが消失するんですよ？
事の重大性がわかってないんじゃない？

うちの会社なら君はクビだ
0834デフォルトの名無しさん2010/09/27(月) 15:58:36
一生チェック作業やってろ
0835デフォルトの名無しさん2010/09/27(月) 16:02:20
>>834
馬鹿？
人がやらなくていいようにプログラムがやるんだよ。
0836デフォルトの名無しさん2010/09/27(月) 16:07:33
メモリに収まりきらないような大量のデータを書き込んだときはどうやって丸ごとチェックするの？
0837デフォルトの名無しさん2010/09/27(月) 16:15:32
段階的にやればよくね？
0838デフォルトの名無しさん2010/09/27(月) 16:18:18
>>837
ストリームとじた後に再読込して全体チェックしなきゃいけないんだから段階的にはできないでしょ
0839デフォルトの名無しさん2010/09/27(月) 16:20:19
複数の系統で保存するって言ってるんだから
ハードディスクとハードディスクでチェックすればいいだろ。
0840デフォルトの名無しさん2010/09/27(月) 16:29:09


0x の話じゃないよね。
0841デフォルトの名無しさん2010/09/27(月) 16:47:26
板違い
0842デフォルトの名無しさん2010/09/27(月) 17:08:43
C++で特に0xとか必要としてる分野って
商用アプリ、組み込み系特殊ハード、ゲーム屋くらいかと思ってたけど
そうでもないんか

趣味でWindowsでC++ってなんでそんな茨の道？とか思った
0843デフォルトの名無しさん2010/09/27(月) 17:13:36
>>842
ちょっと前までC++でWINとかふつうだったけど、なにかんがえてるの？
0844デフォルトの名無しさん2010/09/27(月) 18:16:32
うーんと、金と女かな・・・
0845デフォルトの名無しさん2010/09/27(月) 18:17:30
残念でした、両方とも得られないでしょう。
0846デフォルトの名無しさん2010/09/27(月) 18:26:53
>>840
shared_ptrの利用ポリシーにも関わってくるから全く無関係ではない
0847デフォルトの名無しさん2010/09/27(月) 18:35:03
>>842
> 趣味でWindowsでC++ってなんでそんな茨の道？とか思った
俺は趣味だけど、
コンパイルできてネイティブコードが出力できたり
ライブラリが(外部のね)充実していたりと
最初に取り組んだ言語がCだったりと
いった理由でC++やってる。

でも0xで辟易している。
仕事じゃないからあんまり余暇をC++0xの勉強だけにつぶしたくないし。

0848デフォルトの名無しさん2010/09/27(月) 18:36:49
>>847
0xはやれやれだぜってこと？
0849デフォルトの名無しさん2010/09/27(月) 18:41:58
辟易したなら別に勉強しなくていいじゃない
0xコンパイラで03コードは（ほぼ）通るんだし
perlやpythonみたいに古いコードが壊されないのがC++のいい所
0850デフォルトの名無しさん2010/09/27(月) 18:44:49
（ほぼ）というにはそれなりの根拠があってのことだろうなぁｗｗｗｗｗｗｗ
0851デフォルトの名無しさん2010/09/27(月) 18:51:00
↑アホ
0852デフォルトの名無しさん2010/09/27(月) 19:56:34
そりゃまあ、通らないの確定なところで、新しい予約語がそれまで使ってた識別子に被ったらとかあるしなあ。
0853デフォルトの名無しさん2010/09/27(月) 19:58:43
あとわかりやすい所だと記憶クラス指定子のautoとexportだな
0854デフォルトの名無しさん2010/09/27(月) 20:52:53
俺も趣味でC++やってるが、0xはかなり楽しいぞ。
特にラムダとSTLの相性の良さが癖になる。
0855デフォルトの名無しさんNGNG?2BP(0)
>>833
どうやってチェックするのかまだわからないんだが。
ファイル読み込みAPIが正常に動作しているという保証がどこにある？
0856デフォルトの名無しさん2010/09/27(月) 21:52:04
>>853
ほとんどの03コンパイラでexportは通らなかっただろう
0857デフォルトの名無しさん2010/09/27(月) 23:11:18
>>855
書きこんで読み込めたからといってディスクに書かれているとは限らないしなぁ
833の回答が気になるｗ
0858デフォルトの名無しさん2010/09/27(月) 23:28:31
ばーか釣りだよｗｗｗなにマジレスしてんのｗｗｗｗｗ
0859デフォルトの名無しさん2010/09/27(月) 23:34:13
>>817とか見てると笑える
0860デフォルトの名無しさん2010/09/27(月) 23:38:40
あほにそれ以上構うな
0861デフォルトの名無しさん2010/09/28(火) 00:55:40
障害耐性スレチもいいとこだろ。本気で知りたいのか？
0862デフォルトの名無しさん2010/09/28(火) 00:58:19
で、結論は？
0863デフォルトの名無しさん2010/09/28(火) 01:02:47
素晴らしいものでも馬鹿が使うとだめになる
0864デフォルトの名無しさん2010/09/28(火) 01:19:17
RAIIが使えるのはメモリかロックくらい
ファイルやデータベース接続をRAIIで管理したつもりになってる奴は今すぐやめなさい
0865デフォルトの名無しさん2010/09/28(火) 01:22:20
煽ってる奴もわけわからんなあ。
APIがぶっ壊れてる(暴走してる？)ケースと、レアでも何でもちゃんとエラーが返ってきて
アプリ側で対応できるケースは全然別だろ？
0866デフォルトの名無しさん2010/09/28(火) 01:25:42
そんなレアなエラーを返すOSが悪い(ｷﾘｯ
0867デフォルトの名無しさん2010/09/28(火) 01:30:39
>>864
はいはい
0868デフォルトの名無しさん2010/09/28(火) 01:33:08
例外安全とエラー処理の話を混ぜてどうしたいんだか
0869デフォルトの名無しさん2010/09/28(火) 01:35:56
エラーを握り潰して「はいno-fail保証です例外安全です」とか勘弁してくれ
0870デフォルトの名無しさん2010/09/28(火) 01:39:48
それならエラー処理をちゃんとやれ
で済むじゃん
0871デフォルトの名無しさん2010/09/28(火) 01:41:21
エラーを握り潰すのが悪いって分かってるのにRAIIが悪いとか
0872デフォルトの名無しさん2010/09/28(火) 01:46:35
解放エラーはRAIIじゃちゃんと出来ないと言うとるのに
0873デフォルトの名無しさん2010/09/28(火) 01:59:39
出来るだろカスが
0874デフォルトの名無しさん2010/09/28(火) 02:15:37
どうやって？
デストラクタ起動した時点でオブジェクトは壊れてるし、例外は当然投げれないんだぞ？
staticメンバとかerrnoとかバカなこと言うなよ
0875デフォルトの名無しさん2010/09/28(火) 04:29:52
具体的なことを何も書かない馬鹿は放ってよし。

でもやり方としては>>757で既出な気がする。
そこでリトライ/中途半端な結果で諦める/ファイルを削除する/独自処理(バックアップから書き戻すetc)を
選べればよいのではなかろうか。
コールバックの中から例外投げられないのは辛そうだけど。
0876デフォルトの名無しさん2010/09/28(火) 05:42:04
そもそも、ユーザーがリソースを解放するという処理は失敗すべきじゃないだろ。哲学的に。
失敗が許されるのは、無効なリソースを開放しようとしたときぐらいなものだ。

解放に失敗しても、やれることは皆無だし。
C++が、あらゆる場所で、デストラクターは失敗しないべきだという前提のもとに設計されているのも、当然だ。

それでも失敗するとしたら、それはリソースの解放以外の何かをやろうとしているせいだ。
同期処理では、すぐに処理が終わらないこと、
例えば、他のスレッドやプロセスとの同期やネットワーク越しなど何らかの環境依存の処理をもって、
失敗としているならば、非同期処理でやるべきだ。
例えば、ユーザーが解放処理をした時点で、スレッドやスレッドプールなどで、そのリソースを、いずれ解放するようにする。
少なくとも、解放処理をした時点で、リソースの解放は、ライブラリ（OSなどのシステムも含む）側が責任を持つべきで、
ユーザー側が責任をもつべきではない。
0877デフォルトの名無しさん2010/09/28(火) 05:45:21
ユーザー側とライブラリ側の解放処理がごっちゃになっているから混乱するんだよ。
解放処理とは失敗すべきではない。
ユーザー側にとっての解放処理を、
ライブラリ側にとっても「解放」と呼ぶ必要はない。
0878デフォルトの名無しさん2010/09/28(火) 05:50:33
いや、ディスクの容量が足りなくてetcで書き込めませんでしたー→バックアップから書き戻し、ぐらいは
アプリ側でできないと困るだろ……
ライブラリはバックアップのファイル名なんて知る訳ないし
0879デフォルトの名無しさん2010/09/28(火) 05:59:33
その処理はデストラクターの中ではやれないのかな。
0880デフォルトの名無しさん2010/09/28(火) 06:02:38
>>879
それがコールバック関数案だと思うんだが、バックアップからの書き戻し(大抵リネームだけだろうけど)すら
失敗する可能性があるんだよなあ。
そうするとどうしても外に例外を投げるなりしてユーザーにダイアログボックスを見せたい。

まあそこまで作り込むなら、デストラクタじゃなくてflushなりcloseを別関数にしろよ、ってのが正しいと思うw
0881デフォルトの名無しさん2010/09/28(火) 06:14:26
ディスク Full をそこまで気にするなら RAII の哲学的に、先にファイルを確保してから書き込みするべきですね。
先にリソース確保、その後に使う。でしょ？

同様に、必要とされるメモリは事前に確保。少なくともデストラクタ実行時に発生する動的なメモリ確保は、コンストラクタ内で確保しておく。と。

0882デフォルトの名無しさん2010/09/28(火) 06:16:28
本当にdisk fullを救わないといけないなら
closeを保証するブロックの内側にflushを保証する別のブロックをRAIIで作ればいいんじゃないの？
0883デフォルトの名無しさん2010/09/28(火) 06:21:22
>>881は正論かもしれんが、
エラーハンドリングしたいときはデストラクタに任せず別関数を呼んでください、のほうが遥かに現実的だな……
大体スタックオーバーフローの可能性もある以上別の関数すら呼べないじゃん……
0884デフォルトの名無しさん2010/09/28(火) 06:25:36
>>882
flushを保証するブロックで失敗したら、closeを保証するブロックを抜けた上で
(closeしないとファイルを消すこともできないので)
外側でなんかする、ということになると思うんだが、
closeを保証するブロックを抜ける手段として一番便利なのはどう考えても例外なので
flushがRAIIである必要は全くないと思う。普通のメンバ関数で充分。
0885デフォルトの名無しさん2010/09/28(火) 06:27:40
失敗時にバックアップからの書き戻しとかするような仕様なら
テンポラリな名前でファイル書き込んで成功時にリネームするもんじゃね？
0886デフォルトの名無しさん2010/09/28(火) 06:28:00
>>882
flush を保証するのに RAII 使ったら例外投げれないでしょ。

まとめると、
「 ofstream で書き込み終了したら close() 呼ばないと危ないよ」
で済む話を RAII のせいにしてわめいてるおかしな人が一人、
ってことでおｋ？
0887デフォルトの名無しさん2010/09/28(火) 06:30:33
>>885
ああ、普通はその方が正しいな。
どっちにしろ失敗したファイルは消さないといけないけど
0888デフォルトの名無しさん2010/09/28(火) 06:31:23
ああ、close後にサルベージしたいのか。じゃあflush保証は意味ないな
0889デフォルトの名無しさん2010/09/28(火) 06:42:26
>>887
>>885のやり方でいいなら、closeはcloseでリソースリークが起こらないことだけ面倒見て
続行不能なIO例外が飛んできたら一律そこで一時ファイル削除すればいいんじゃないの？
0890デフォルトの名無しさん2010/09/28(火) 06:49:00
>>889
いいよ。
でもデストラクタは例外飛ばせないので、やっぱりcloseは明示的に呼ぶことになるね。

あとまあ、ファイルのIDを維持したいとかハードリンクを維持したいとかリソースフォークを維持したいとかで
リネームによる解決ができない場合は時々あると思う
0891デフォルトの名無しさん2010/09/28(火) 06:57:26
>>890
書き込み操作が全部終わった時点で手動でflushして失敗したら例外投げたらいいんじゃないの？
0892デフォルトの名無しさん2010/09/28(火) 06:59:17
明示的に呼ぶのがcloseかflushのどっちかはこの際問題にされてないと思ったけど？
0893デフォルトの名無しさん2010/09/28(火) 06:59:35
単にデストラクターの中で例外を使いたいだけなら、
つまり、デストラクターの外に例外を飛ばす必要がないのなら、
デストラクターの中でthreadをつくって、join()すればいいじゃん。
0894デフォルトの名無しさん2010/09/28(火) 07:00:39
>>892
全然違う
closeは書き込み操作が成功しようが失敗しようが呼ばないといけない
flushはwriteしたいものが全部片付いた時だけ呼べばいい
0895デフォルトの名無しさん2010/09/28(火) 07:11:49
>>893
えっ
単に外に飛ばさなければいいだけで、デストラクタの中で握りつぶす分には大丈夫と思ってたけど
もしかして違うのか……怖くなってきた
0896デフォルトの名無しさん2010/09/28(火) 07:15:05
デストラクタ内で例外握りつぶすのがダメだったらほとんど何も出来ないな
0897デフォルトの名無しさん2010/09/28(火) 07:27:57
>>894
ある程度書き込んだあとflush到達前に例外が飛んだ場合でなおかつdisk fullなら、
デストラクタ経由close経由flushがやっぱり失敗するんでどっちにしろ明示的に……と
書こうとしたが、この場合はもみ消していいのか。すまん。
0898デフォルトの名無しさん2010/09/28(火) 07:32:52
例外の発生中に、新たな例外を投げることはできない。
デストラクターの中で例外を使うというのは、問題になる。
例外を投げた結果、デストラクターが実行されているとしたらどうなる？

struct S
{
~S()
{
try {
throw 0 ;
} catch(...) { }
}
} ;

void f()
{
S s ;
throw 0 ;
// sのデストラクターを呼び出す
}

この例では、S::~S()の外には例外を投げないものの、
すでに例外が発生しているので、デストラクター内のthrow文を実行した時点で、
例外が重複することになり、エラーとなる。

したがって、例外を投げたことによるデストラクターの実行ではない保証できる場合でしか、
デストラクターの中で、安全に例外を使うことはできない。
08998982010/09/28(火) 07:38:51
あ、間違ってた。中で握りつぶす文にはいいのか。
0900デフォルトの名無しさん2010/09/28(火) 07:42:44
デストラクタの中で発生した例外は握りつぶさないと危険
あとの処理は誰かに任せる
0901デフォルトの名無しさん2010/09/28(火) 07:58:37
>あとの処理は誰かに任せる
どうやって？
何を使えば伝えられるのか？
0902デフォルトの名無しさん2010/09/28(火) 08:04:14
つか、おまえらの「議論」は極論の塊なのよ。
クリティカルなメモリマネージメントをしたければ、その例外ハンドラ用に「小さな」メモリマネージャを持つ。
とか、もっと簡単にコンストラクタで非常用メモリを確保しておいて、new / alloc でエラーが起きたら、
その非常用メモリを解放して最後の後始末をする。とかね。
ディスクも、システム用に「ちょっと」確保しておいて、最後のログはき出しようにそこを使うとか。

実装レベルではそれで十分だし、それ以上の対策なんて、どちらにしろできないだろ？
メモリゼロ、空き容量もゼロであと何ができる？

0903デフォルトの名無しさん2010/09/28(火) 08:24:07
>>897
flush到達前に例外でたらスコープ抜ける際にcloseされてそのあとキャッチされて後始末
書き込み一通りエラー無しで通ったのにflush失敗した場合でも例外投げたらスコープ以下同文
0904デフォルトの名無しさん2010/09/28(火) 08:26:26
>>898
デストラクタで例外を投げる可能性がある部分を実行するときは
std::uncaught_exception で例外中かどうか確認してからすべきでは
if( !std::uncaught_exception() ) throw 0; ﾄｶ
0905デフォルトの名無しさん2010/09/28(火) 08:27:31
>>901
デストラクタにしろクローズ処理にしろ、そこまでに処理し忘れていたエラーは全て握り潰すのが基本
エラー拾いたいならそれより前でチェックして例外投げるなり回復処理するなりしなはれ
0906デフォルトの名無しさん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, ...
0907デフォルトの名無しさん2010/09/28(火) 09:10:36
まーだやってんのかお前らも暇だねぇ
0908デフォルトの名無しさん2010/09/28(火) 09:18:50
{

if(!r.close())
{
// エラー処理
}

}

なんて書くのはアホのする仕事

void Deleter(resource * pr)
{
if(!r->close())
{
// エラー処理(さっきと同じ)
}
}

{

resource r(..., Deleter());

}

って感じでRAII使って処理するのが仕事で使って良いコード
0xならラムダもあるからコーディングの手間も少ないし、
従来のスタイルと同等の柔軟性もあって、スコープガードとしても機能する
リソースの処理をリソース管理クラスの外に丸出しするなんて愚の骨頂でしょ
0909デフォルトの名無しさん2010/09/28(火) 10:17:43
さっきからエラーを外側で処理しないといけないケースの話をしてるんだが
0910デフォルトの名無しさん2010/09/28(火) 12:07:14
だからそれが間違ってるんだよ
0911デフォルトの名無しさん2010/09/28(火) 13:37:33
まだ粘着の相手してんの？お前ら
0912デフォルトの名無しさん2010/09/28(火) 13:49:44
>>911
分からないのなら口を挟まずスルーしろ
0913デフォルトの名無しさん2010/09/28(火) 14:35:44
fj の malloc/free 論争なみにもっとやろうぜ
0914デフォルトの名無しさん2010/09/28(火) 14:49:06
ここまでのまとめ

発端は>>737,739,742,744。要するに
『解放が必要なリソースを扱うときでも場合によってはRAIIを使わないと言う選択をするべきだ。
なぜならRAIIを使ってリソース解放をデストラクタに一任では解放失敗という事態に対処できないからだ。』
という意見が出る。

で反論。>>770,799とか
『RAII+明示的解放(と解放失敗した場合の処理)、で対処すればいい。RAIIを使うことを否定する意味はない。』

わかってる人にはこの時点で終了。

で、その流れから派生したが本質的でない
・解放処理に失敗したことをどう検知するかという話
・いまだに解放をデストラクタに一任する前提でされている話
・あくまでRAIIを使うべきではないときがあると主張する話
とかをいまだに続けている人がいる。
0915デフォルトの名無しさん2010/09/28(火) 14:54:26
「みながわけんじ」みたいな老害が居るわけね
0916デフォルトの名無しさん2010/09/28(火) 15:30:00
じゃなくて
RAII+明示的解放
は RAII ではない。
ってことでしょ？
0917デフォルトの名無しさん2010/09/28(火) 15:41:45
RAIIってのは自分の欠は自分で拭くってことなんだよ
0918デフォルトの名無しさん2010/09/28(火) 15:47:01
言い換えるとウォッシュレットを使わない人ってことですね。
0919デフォルトの名無しさん2010/09/28(火) 15:48:27
0x関係なくないか?
0920デフォルトの名無しさん2010/09/28(火) 15:50:28
C++0xにC++は含まれてるから
C++のことはC++0xのことでもあるとおもうが。
0921デフォルトの名無しさん2010/09/28(火) 16:43:47
なんだその理屈
0922デフォルトの名無しさん2010/09/28(火) 16:46:11
>>920ベン図に描いて説明してみろよｗ
09238472010/09/28(火) 17:27:54
>>848
> 0xはやれやれだぜってこと？
そう。
学生時代は落とし穴回避する俺sugeeeeモードでそれなりに
楽しくやれたんだが、そろそろ就職と資格勉強にあたり
あんまり時間も取れなくて、それなのに新しい仕様が
登場してきて勉強しなおしかぁ…って気が沈むんだ。

>>849
> 辟易したなら別に勉強しなくていいじゃない
ところがC++が楽しかった思い出が後ろ髪を引くんだよ。

> perlやpythonみたいに古いコードが壊されないのがC++のいい所
Python 2.x では最近習得し始めて、文字列処理するだけなら
圧倒的にこっちがメイン。
最近 3.x で非互換になっているらしいが先進的な機能は使ってない
(というか使えていない)のでまあ問題無い。

>>854
楽しいのか－。
もう学生気分は終わりだからなー。
0924デフォルトの名無しさん2010/09/28(火) 17:30:31
長文乙ｗｗｗｗｗｗｗｗｗ
0925デフォルトの名無しさん2010/09/28(火) 17:49:21
0x の新機能は大体糖衣構文なのだから、別に勉強しなおすって表現する程のものは無いぞ。
分からないものは使う必要は無い。
0926デフォルトの名無しさん2010/09/28(火) 18:34:57
アセンブリを除けば、すべての言語はシンタックスシュガーであると言える。
0927デフォルトの名無しさん2010/09/28(火) 18:35:35
高級言語なんてアセンブラのマクロから派生したもんだからな。
0928デフォルトの名無しさん2010/09/28(火) 18:39:14
assembla でさえ machine language の syntax sugar なんだよな
0929デフォルトの名無しさん2010/09/28(火) 18:46:58
もとはHEXだしね。
最近のIntelCPUなんかアセンブリ命令がさらにこまかい単位になるんだっけか？ｗ
0930デフォルトの名無しさん2010/09/28(火) 18:56:48
マイクロopは別に新しい技術じゃないよ。てかスレチ
0931デフォルトの名無しさん2010/09/28(火) 19:25:25
おまえら極論がすきだな～。
0932デフォルトの名無しさん2010/09/28(火) 19:39:44
お前らシンタックスシュガーって言葉が大好きだな
0933デフォルトの名無しさん2010/09/28(火) 20:48:35
μopとかPenIIの頃からじゃなかったっけか
0934デフォルトの名無しさん2010/09/28(火) 20:55:18
構文糖衣A錠、医薬品です。
0935デフォルトの名無しさん2010/09/28(火) 21:07:48
央退散良い薬です
0936デフォルトの名無しさん2010/09/28(火) 21:24:02
正露丸糖衣Aを「正露丸トウ、イェー」だと思っていた僕の母
0937デフォルトの名無しさん2010/09/28(火) 23:33:57
お前らもっと建設的な議論をしようぜ。
例えば、
Alternative representations（C++03でいうAlternative token）とか、
asm宣言とか、
vector<bool>とか。
0938デフォルトの名無しさん2010/09/29(水) 00:04:17
結局そのままなんだよなvector<bool>
0939デフォルトの名無しさん2010/09/29(水) 01:00:56
そのまま、というのが何を指すのかにも依るけど
vector<bool> は deprecated だし、その役目は dynamic_bitset に移譲
されていくことは確かな訳で
0940デフォルトの名無しさん2010/09/29(水) 01:04:26
なんでvectorあんな仕様にしたんだろうな
標準化委員ってマヌケばっかなのか？
0941デフォルトの名無しさん2010/09/29(水) 01:08:49
コンテナの要件を満たさないというのがどれだけヒドいことか当時は良く理解してなかった
まあ間抜けっちゃ間抜け
0942デフォルトの名無しさん2010/09/29(水) 01:43:51
std::vector<bool>だけ
過去の物をどうにかして直せないのかな？


①過去との互換性を破棄する
②std::vector_container<T>というテンプレートを用意して、
　Tがboolで無い限りはstd::vector<T>と同じで
　Tがboolである場合はコンテナの要件を満たすようにするとか。
　(要するにboolでの特殊化をしない)


特に後者②の方法で解決できないのかな？？
そして今後は②を使う様推奨していくってのが良さそうなんだけど。
②の方式ってデメリットあるのかな？



教えて標準化委員会の人！！


0943デフォルトの名無しさん2010/09/29(水) 02:48:58
boolの特殊化でvector<bool>のまともな実装と同等のコードを書かないといけない→新しいコンテナ丸ごと作るのと手間がほとんど変わらないのでめんどい
0944デフォルトの名無しさん2010/09/29(水) 03:05:31
機種依存文字を平気で使える時代になったのはいつから？
0945デフォルトの名無しさん2010/09/29(水) 03:07:18
vector<char>あたりのラッパー作るだけでいいんじゃないの？
0946デフォルトの名無しさん2010/09/29(水) 03:14:42
個人的には使う人が便利なら右辺値云々含めて気合いで書き直すべきだと思うけど
vectorに関しては既にリリースしちゃったから互換性気にする人がいるんだろうな
0947デフォルトの名無しさん2010/09/29(水) 04:30:42
当時の委員会を間抜けと言うならそのとき間抜けでない人間はいなかった。

まあこの期に及んでvector<bool>なんて最早全く使わないけどな。
サイズが問題ならbitsetがあるしそうでなければvector<int>で代用すればいい。
0948デフォルトの名無しさん2010/09/29(水) 07:28:46
vector<bool>がdeprecatedってのは、0xの話じゃなくてユーザーの雰囲気的にってこと?
どっちにせよ面倒そうだから使わないようにしてるけど。
0949デフォルトの名無しさん2010/09/29(水) 13:12:31
結局なんとなくもやもやしながらvector<int>やdeque<bool>を使うしかない
09509422010/09/29(水) 14:57:45
>>943
何を言っているのかわからんが、
別にboolを特殊化しないだけであとは既存のvectorのコピペでいいんだから
手間は全くかからないとおもうんだけど。
0951デフォルトの名無しさん2010/09/29(水) 16:01:19
>>944
丸数字がUnicodeに入った時点で、時代遅れは我々になったのかもしれん
0952デフォルトの名無しさん2010/09/30(木) 00:53:04
Macで普通に文字化けするっつーの＞丸文字
まあソフトとフォント？によるけど
0953デフォルトの名無しさん2010/09/30(木) 01:13:58
そのソフトがアホなだけだろ。
0954デフォルトの名無しさん2010/09/30(木) 03:13:57
windows以外はゼンブゴミでOK？
0955デフォルトの名無しさん2010/09/30(木) 09:41:42
macワロタ
なに？人とは違う、おしゃれな私かっこいい、とか思ってんの？
中身のないマイナーOSは引っ込んでろよ
0956デフォルトの名無しさん2010/09/30(木) 09:54:12
脳味噌の中身がないドザ黙れよ
0957デフォルトの名無しさん2010/09/30(木) 11:24:06
単にNFCとNFDの差
WindowsもMacも両方対応が不完全
0958デフォルトの名無しさん2010/09/30(木) 13:53:35
>>956
反論不能ｗ
0959デフォルトの名無しさん2010/09/30(木) 14:23:51
つうか機種依存とか気にしてたらAA書けないし
実際機種の問題じゃなくて掲示板見るときの設定がオカシイってだけでしょ
0960デフォルトの名無しさん2010/09/30(木) 14:24:59
>>957
丸付き数字なら、cp932とsjis-macで割り当ててるコードポイントが違うのが原因じゃねーかと思う。
0961デフォルトの名無しさん2010/09/30(木) 14:33:25
①
0962デフォルトの名無しさん2010/09/30(木) 19:07:36
勝手に引数を暗黙変換しない
void f(explicit bool);
という構文があればいいのに
0963デフォルトの名無しさん2010/09/30(木) 19:10:30
お前センスあるな
0964デフォルトの名無しさん2010/09/30(木) 19:35:59
>>962
なんかそれっぽいの無かったっけ？

自分でMyBoolってクラスを作って、
explicitコンストラクタで bool型だけを受け付けて、
void f(MyBool myb);内に入るとすぐMyBoolが格納しているbool値を放出して
受け取ってもらうってのはらめなの？
0965デフォルトの名無しさん2010/09/30(木) 19:47:25
汚すぎる
0966デフォルトの名無しさん2010/09/30(木) 19:56:17
>>965
ってことは一応可能って事？
自分で描いててこれじゃあんまり有用性無い気がしてきた。
大体
void f(true);
が通らないよねこれだと
0967デフォルトの名無しさん2010/09/30(木) 21:08:00
void f(bool){ ... }
void f(...){ static_assert(false, "ダメよ♪"); }
0968デフォルトの名無しさん2010/09/30(木) 21:11:34
>>967
それって通るコード？
0xって良くわかんない。
0969デフォルトの名無しさん2010/09/30(木) 21:14:04
テンプレートじゃないとダメか。
void f(bool){ ... }
template <class T> void f(T const&){ static_assert(false, "らめぇー"); }
0970デフォルトの名無しさん2010/09/30(木) 21:22:59
>>969
その場合、コンパイル時にトラップするだけのための関数を
エラーになるように定義するのも面倒なので

template <class T>
void f(T) = static_assert;

とでも書くと、コンパイラがエラーメッセージを出すようになっていればいいのに
0971デフォルトの名無しさん2010/09/30(木) 21:25:55
メタプロ用の仕様もっとモリモリ拡張すればよかったのにね

これが実体化したらこれこれこうする～とか
0972デフォルトの名無しさん2010/09/30(木) 21:29:07
Defaulted and Deleted Functionsがテンプレートでも使えるような気がしないか？
0973デフォルトの名無しさん2010/09/30(木) 21:31:25
Defaultedはクラス以外で使い道ない。
Deletedにすると、boolの例だと逆にトラップ先が無くなって
何でもかんでもboolに集まってくることになる
0974デフォルトの名無しさん2010/09/30(木) 21:38:03
暗黙の型変換はint←→longみたいなのも含めて全部なしにして、
C言語と互換性のある型変換は#include<implicit>みたいなのにすればいいのかな。
0975デフォルトの名無しさん2010/09/30(木) 21:44:11
>>974
> C言語と互換性のある型変換は#include<implicit>みたいなのにすればいいのかな。
何を言っているんだ
#includeって何をしていると思っているんだ
#includeじゃなかったとしてもプリプロセッサレベルでどうやって解決しろと。
0976デフォルトの名無しさん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;
}
0977デフォルトの名無しさん2010/09/30(木) 21:51:25
>>975
中にはoperator int(long);みたいなのがたくさん入ってるのを考えてた。
09789722010/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.
って書いてあるな
0979デフォルトの名無しさん2010/09/30(木) 22:08:33
= default; はスペシャルファンクションだけって書いてあるけど、
= delete; はそういう制限ないんだね。

それに、
8.4.3.2 のノートを見る限り >>976 が正しいみたい。
0980デフォルトの名無しさん2010/09/30(木) 22:15:59
とりあえず暗黙の型変換対策は
deleted関数でOKってことのようで
0981デフォルトの名無しさん2010/09/30(木) 22:33:44
>>980
そうっぽいけど
誰か仕様書に基づき解説してくれ

教えて頭いい人！
0982デフォルトの名無しさん2010/09/30(木) 22:36:42
そろそろ次スレだけど
この4ヶ月でなんか大きな動きあったっけ？
0983デフォルトの名無しさん2010/09/30(木) 22:38:20
俺がVC++を見限ったことぐらいかな
0984デフォルトの名無しさん2010/09/30(木) 22:41:49
VC++2010のパッケージ版が出たことぐらいかな
0985デフォルトの名無しさん2010/09/30(木) 23:20:57
gccが、nullptr、range-based for、noexceptの一部、をサポートしたことぐらいか。
0986デフォルトの名無しさん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; 可能。
09879862010/09/30(木) 23:49:54
あれ? 俺間違ってる?
explicit specializationは「宣言」だから、関数定義はできないのか。

じゃあ
× =delete; した関数テンプレートも、明示的特殊化で使えるようにできる。
× 明示的特殊化で =delete; 可能。
はウソだ。
0988デフォルトの名無しさん2010/09/30(木) 23:56:14
というか何でお前ら、「関数のdeleted定義はメンバー関数に限る」みたいな誤解をしているんだ？
そんなこと、規格のどこにも書いていないじゃないか。
まあ、サンプルコードはメンバー関数の場合しか載っていないというのはあるがな。
0989デフォルトの名無しさん2010/10/01(金) 00:03:05
>>988
「deletedな関数は呼び出すべき関数の探索対象にならない」という誤解をしている人はいたが、
「メンバ関数に限る」という誤解をしている人はいないように見える。
0990デフォルトの名無しさん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;
}
0991デフォルトの名無しさん2010/10/01(金) 01:23:30
>>987 定義は宣言でもあるので、問題でしょ。
0992デフォルトの名無しさん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定義であった場合、その名前を使うとエラーとなる。

0993デフォルトの名無しさん2010/10/01(金) 01:42:38
>>992
> なんか皆がどのへんの理解に苦しんでいるのかがわからない。
というかC++0xのカオス状態の規格を読んでも
いまいちぴんと来ないのだ。
単に俺がバカなだけかもしれんけど。
0994デフォルトの名無しさん2010/10/01(金) 01:46:19
>>992
decltypeやsizeof中での使用を禁止してるのは何か深い理由があってのことですか？
0995デフォルトの名無しさん2010/10/01(金) 05:03:46
>>994
さあ？
しかし、

void f() = delete ;

に対して、

f() ;

がエラーとなるのに、

typedef decltype( f() ) type ;

がエラーとならない、というのは、違和感がある。
0996デフォルトの名無しさん2010/10/01(金) 07:15:01
次スレ
C++0x 11
ttp://hibari.2ch.net/test/read.cgi/tech/1285884294/
0997デフォルトの名無しさん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 だとか、そんなことだったっけ。
0998デフォルトの名無しさん2010/10/01(金) 12:32:55
.
0999デフォルトの名無しさん2010/10/01(金) 12:33:54
.
1000小倉優子 ◆YUKOH0W58Q 2010/10/01(金) 12:33:56
　　∧,,,∧　
　( 　・∀・)　1000ならジュースでも飲むか
　 (　　 　)　
　　し─J　
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。