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

C++0x 11

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2010/10/01(金) 07:04:54
The C++ Standards Committee
http://www.open-std.org/jtc1/sc22/wg21/

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

前スレ: C++0x 10
http://hibari.2ch.net/test/read.cgi/tech/1275375522/
0153デフォルトの名無しさん2010/10/12(火) 22:43:03
>>152
ラムダ式は関数じゃなくて関数オブジェクトだから呼び出し規約はないだろう
0154デフォルトの名無しさん2010/10/12(火) 22:46:16
関ポに出来るなら関ポになるんじゃなかったっけ
0155デフォルトの名無しさん2010/10/12(火) 22:46:54
呼び出し規約？
MSVCにおける__stdcallとかか？
そんな規格外のことを言われてもな。
規格的にいえば、attributeで実装して欲しいところだが、
規格を守る気のないMSがやるかなぁ？
0156デフォルトの名無しさん2010/10/12(火) 22:47:46
>>153
一応、何もキャプチャーしてないと、単なる関数ポインターに変換可能。
0157デフォルトの名無しさん2010/10/12(火) 22:51:53
まずは、API関数をラップして、好きなファンクションオブジェクトを引数に取れるラッパを作ればいい。
そしたら、ラムダ式でも何でも渡し放題だ。
ってのをWinSTLとかやっていないかなあ？
0158デフォルトの名無しさん2010/10/12(火) 23:09:11
gccのトランポリンは外のローカル変数に触ってても普通にstdcallでコールバックできるし、clangのblocksとかもあるし
ラムダめいたことに関してはC言語の独自拡張の方がC++よりもずっと進んでる
0159デフォルトの名無しさん2010/10/12(火) 23:11:47
独自拡張は独自拡張でしかないからなぁ…
一生窓やリンゴだけ食って生きてく覚悟があればいいんだろうけど
0160デフォルトの名無しさん2010/10/12(火) 23:14:07
blocksはちょっと色々とアレなとこが・・・
0161デフォルトの名無しさん2010/10/13(水) 01:52:43
>>158
トランポリンはスタック全部に実行可能属性が付く気持ち悪い仕様
0162デフォルトの名無しさん2010/10/13(水) 02:13:09
Windowsでは、呼び出し規約が統一された64bitコードにさっさと移行しろってことだろ。
まあ、それが出来れば苦労しないんだろうがな。
0163デフォルトの名無しさん2010/10/13(水) 05:44:06
呼び出し規約自体独自拡張なんだから、
[](int x) [[ __stdcall ]] -> { return x; } みたいに
attribute さんに仕事をあげればいいのに
0164デフォルトの名無しさん2010/10/14(木) 01:59:52
気持ち悪さに磨きかかっちゃってる・・・
0165デフォルトの名無しさん2010/10/14(木) 03:01:37
どうせならラムダの最初の[]の中にattributeを書くようにすればいいのに……。
0166デフォルトの名無しさん2010/10/14(木) 04:20:16
同名の変数が有ったらどうすんだよ
0167デフォルトの名無しさん2010/10/14(木) 07:45:34
class Hoge
{
public:
　const {
　　void foo();
　　void bar();
　　void baz();
　};
};
0168デフォルトの名無しさん2010/10/14(木) 11:36:19
class Hoge
{
public:
　const {
　　void {
　　　{ foo, bar, baz }();
　　}
}
};
0169デフォルトの名無しさん2010/10/14(木) 18:13:56
>>166

[[[ __stdcall ]]](int x) { return x; }
0170デフォルトの名無しさん2010/10/14(木) 20:14:27
キモさに磨きがかかるな
0171デフォルトの名無しさん2010/10/14(木) 20:49:15
>>168
便利すぎてやばいな
これ考えたやつは天才だと思う
0172デフォルトの名無しさん2010/10/14(木) 20:51:01
>>167
ってOKなの？
0173デフォルトの名無しさん2010/10/15(金) 07:24:12
いや夢語りだろう。
0174デフォルトの名無しさん2010/10/16(土) 19:29:55
VBのWithに通じるクソっぷりを感じる
0175デフォルトの名無しさん2010/10/16(土) 20:52:23
>>174
何行も前を確認しないと関数の定義がわからないとか駄目すぎるね。
0176デフォルトの名無しさん2010/10/16(土) 21:13:15
何行も前を確認しないと関数のアクセスレベルがわからないなんて……
0177デフォルトの名無しさん2010/10/16(土) 21:36:54
class Hoge
{
public virtual Hoge const & { foo, bar, baz } (void) const throw() = 0;
};

う、美しい。。。
0178デフォルトの名無しさん2010/10/16(土) 21:37:50
何行も前を確認しないとクラスの名前がわからないなんて……
0179デフォルトの名無しさん2010/10/16(土) 21:46:34
C#みたいに全メンバにアクセス修飾子がついたクラスなら見たことがある。
0180デフォルトの名無しさん2010/10/16(土) 21:47:42
それはメンバの再配置期待してるんだろ
たまにやるよ
0181デフォルトの名無しさん2010/10/16(土) 21:53:00
メンバのre-orderしてくれんなら俺もやろうかな
0182デフォルトの名無しさん2010/10/16(土) 22:54:22
他はともかく、staticだけはpublic:なんかと同類でグループ指定にしたほうが分かりやすい気はするな
0183デフォルトの名無しさん2010/10/17(日) 09:03:47
メンバの再配置って class A { public: char a; public: int b; public: char c; };
のメンバが b,a,c の順にメモリに並んでくれるのかと思ったけど、そうじゃないね。
0184デフォルトの名無しさん2010/10/17(日) 10:04:52
>>183
PODにすれば記述順配置になるんじゃなかった？
0185デフォルトの名無しさん2010/10/17(日) 12:09:51
別にPODでなくても、publicなメンバ同士、protectedなメンバ同士、private:なメンバ同士は
それぞれ記述順に配置される
0186デフォルトの名無しさん2010/10/17(日) 16:12:35
あれ、記述順になるのは同じラベルじゃなかったっけ
class A { public: char a,b; private: char c,d; protected: char e; public: int f;};
ならaがbの後、cがdの後、それ以外はunspecified（なので親切なコンパイラなら再配置してくれるかもしれない）
例えばf,a,c,b,e,dとかの順でもいい
PODは全メンバのアクセス指定が同じという条件があるので記述順になる

だと思ってたけど規格見るとはっきりしないな
same access controlなら記述順とは書いてるけど（N3126の9.2-13）
"access control"とは何なのかハッキリ定義されてないからどっちにも読める
0187デフォルトの名無しさん2010/10/17(日) 18:08:48
なるほど。the same access control って、
(a,b,f) (c,d) (e) が同じって意味だと思ってたけど
(a,b) と (f) は違うって解釈もできるのね…
0188デフォルトの名無しさん2010/10/18(月) 22:26:36
これ↓を見ると
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2172.html

9.2 ¶12 Class members [class.mem]
Nonstatic data members of a (non-union) class
<del>declared without an intervening access-specifier</del>
<ins>with the same access control (clause 11)</ins>
are allocated so that later members have higher addresses within a class object.

となっているから、
　class A { public: char a; public: int b; public: char c; };
の a, b, c は、このときまでは並べ替えてよかったけど、
今は並べ替えてはいけなくなったようだ。(ついでにPODになった)
0189デフォルトの名無しさん2010/10/18(月) 22:45:34
ですよねー。。。
0190デフォルトの名無しさん2010/10/18(月) 23:48:46
なんだダメになってたのか
それにしても修正入れた割には曖昧な文言だな
0191デフォルトの名無しさん2010/10/18(月) 23:59:22
最適化するしないで互換性が無くなるクラスとか有ったら死ねる
0192デフォルトの名無しさん2010/10/19(火) 11:10:46
というか配置順変えていた実装あるんかいな。
0193デフォルトの名無しさん2010/10/19(火) 15:30:28
sunのコンパイラが宣言と逆順に配置してたよ
0194デフォルトの名無しさん2010/10/20(水) 04:50:52
若干スレ違いな感じもしますが、新しい規格ということで・・・

C99のfenv.hあるいはC++0xのcfenv
のマニュアルはたくさんあるのですが、具体例がなかなか見つかりません。
英語でも書籍でもいいので、ご存知の方いらっしゃいませんか？

try catchと連携させて
double x = 1.0/10;
try {
fetestexcept(FE_ALL_EXCEPT);
x = sqrt(-x);
if (fetestexcept(FE_ALL_EXCEPT)) throw runtime_error("fpe exception!");
} catch (const runtime_error& e) {
cerr << e.what() << endl;
exit(-1);
}
こんな感じで使いたいのですが、いかんせん自己流で自信ないのです。
#define _GNU_SOURCE
は必要ないのか？とか、環境依存性は？とか、色々気になります。
0195デフォルトの名無しさん2010/10/20(水) 05:04:29
>>194
なんで _GNU なんてついたマクロが必要かもしれないなんて思うのか、わからない。
「環境依存性は？」と言われても仕様を見たとおり、としか言えない。

何か気に入らないところがあるとか、具体的な不満や要件を挙げてもらわないと、
話にならないね。

「自己流で自信が無い」と言うが、ここで名無しさんが何か言ってくれたら自信が付くわけ
でもないだろう。
01961942010/10/20(水) 05:35:57
ttp://linux.die.net/man/3/fenv
とかを見ると、細かい設定をglibc拡張でやれるって話みたいでした。
色々混乱しててすみません。

C99とか0xの範囲なら環境依存するはずないですよね。
0197デフォルトの名無しさん2010/10/20(水) 21:57:29
ムーブさん先行き不安だな…
0198デフォルトの名無しさん2010/10/20(水) 22:59:21
moveは仕様をきっちり作り込むのが難しいよね。
0199デフォルトの名無しさん2010/10/20(水) 23:11:49
ムーブさんはコンセプトさんと似たような泥沼に入りかけてる気がしてならない
0200デフォルトの名無しさん2010/10/20(水) 23:32:13
コンセプトさんが憑いたのか
0201デフォルトの名無しさん2010/10/21(木) 04:22:42
右辺値参照さんまさかの入学取り消しあるで
0202デフォルトの名無しさん2010/10/21(木) 12:08:14
内定取り消しか…胸が熱…(´;ω;)ｳｯ
0203デフォルトの名無しさん2010/10/21(木) 15:12:05
右辺値さんmixiで調子乗ってなんかやらかしたんだってさ
0204デフォルトの名無しさん2010/10/21(木) 19:52:22
おまえら全員留年な
0205デフォルトの名無しさん2010/10/22(金) 08:17:45
>>201
詳細求む
0206デフォルトの名無しさん2010/10/23(土) 14:36:01
デフォルトムーブコンストラクタの件じゃないのか？うまく折り合いをつけて採用してほしいところ。

いまさら右辺値さん取り消したら、unique_ptrさんも道連れだよ。
unique_ptrさんマジ便利。いまさらなくせないだろう。
0207デフォルトの名無しさん2010/10/23(土) 15:57:02
range-based for文さんを道連れに消えていったコンセプトって子がおってな
0208デフォルトの名無しさん2010/10/23(土) 16:32:37
【スキャンダル】入学審査で不正疑惑が【椿事】
0209デフォルトの名無しさん2010/10/23(土) 17:14:43
>>207
あたらしい転校生のBOOST_FOREACHさん。,さんが苦手。
0210デフォルトの名無しさん2010/10/23(土) 19:57:52
というか、range-based forいらねーよ。
その次の規格でconceptと一緒に入れてくれよ。
0211デフォルトの名無しさん2010/10/24(日) 13:50:19
そうか？
使ってみると、意外と便利だぞ。
まあ確かに、今のような糞なイテレート方式じゃなくて、concept使って欲しかったところだが。
0212デフォルトの名無しさん2010/10/24(日) 13:55:55
range based forぐらい自分でパチもん実装できるからいいじゃん
つーかboostもあるし
0213デフォルトの名無しさん2010/10/24(日) 14:07:26
そんなこと言ってたらC++0xが要らなくなるだろ
0214デフォルトの名無しさん2010/10/24(日) 14:11:00
polymorphic lambdaがない以上、以下のコードがうまくいかないんだよな。

std::vector<int>v = { 1, 2, 3 } ;
for ( auto i : v ) { }
0215デフォルトの名無しさん2010/10/24(日) 14:18:01
どううまくいかないの?
一見して問題なさそうだけど。
実際、gcc4.6 ではエラーにならない。
02162142010/10/24(日) 14:26:36
いや、ちがうちがう。
パチもんが実装できないということ。
0217デフォルトの名無しさん2010/10/24(日) 15:37:59
range-based forって一つの書き方で多くの範囲オブジェクトをカバーできるところが大きな魅力になってるの？
俺はよく使うコンテナクラスにそれぞれ特化したforを定義して使ってるんだけど
0218デフォルトの名無しさん2010/10/24(日) 15:55:39
>>217

vector<int> v;
int s=0;
for(vector<int>::iterator i=v.begin();i!=v.end();++i)
s+=*i;

が

vector<int> v;
int s=0;
for(int x:v)
s+=x;

になるんだぜ。これは欲しいな。

あとBOOST_FOREACHで同じよことができるし、autoも使えるし
0219デフォルトの名無しさん2010/10/24(日) 16:31:44
>>218
いいな
俺はvから元クラス参照でそこから::iteratorでもいいんだけどね
要するに元の宣言vector<int> をvからひきだしたいだけなんだけど
コードの中にtypdef宣言いれないでmapとかの長い宣言作ると::iteratorの書式が長くて嫌いなんだよね
0220デフォルトの名無しさん2010/10/24(日) 16:51:47
>>219
auto使えばいいんじゃね？
0221デフォルトの名無しさん2010/10/24(日) 19:04:44
理想は>>218がこうなればいいんだけどな
int s = std::accumulate(v, 0);
0222デフォルトの名無しさん2010/10/24(日) 19:13:44
>>220
foreach(auto x:v){}
だな。
BOOST_FOREACH(auto x,v){}
でもOK
>>221
boost::range や Ovenがそれの役目だな。
0223デフォルトの名無しさん2010/10/24(日) 19:56:57
標準ライブラリのコンセプト対応で可能になるはずだったのにね・・・
0224デフォルトの名無しさん2010/10/24(日) 20:04:43
おまいらには、頭が下がります.
物覚えが良くないので, 0x の変態構文にはもうついていけんわ
# つか, テンプラの時から思ってたんだが,
# lisp の ` と , を知ると何とか整理してくれやぁ！！！ になる
0225デフォルトの名無しさん2010/10/24(日) 20:09:39
>>223
コンセプトがあればエラーメッセージがまだ判りやすくなるのにな。
意味不明のエラーメッセージは新規ユーザにとってかなりハードル高いな。
boost conceptcheckでもかなり改善になるから採用されないかな。
0226デフォルトの名無しさん2010/10/24(日) 20:11:13
>>224
いえいえ、御代官様の括弧式ほどでは。ふっふっふ
0227デフォルトの名無しさん2010/10/24(日) 23:33:55
禿げよ。

xrvalueとかprvalueとかもういいかげんにしてくれる？
みんな、お前ほど賢くないんだから話を複雑にしないでくれ。

ただでさえ、C++は複雑で、経験が少ない社員が含まれる
プロジェクト開発では敬遠されるのに。それでjavaやC#が
流行ったのに。

まったく、学習してないんだな、このタコは。

みなはお前みたいに言語を趣味にしてるんじゃないぞ。
0228デフォルトの名無しさん2010/10/24(日) 23:42:44
xrvalue → xvalue
0229デフォルトの名無しさん2010/10/24(日) 23:55:02
>>227
互換性を無視していいなら、同等以上の機能を遥かにシンプルに定義できるっしょ。
xvalueも、規格の文面を全面書き換えするのを避けた結果なんだっけ？
0230デフォルトの名無しさん2010/10/25(月) 09:59:31
禿曰く、

いまさらlvalue、rvalueといった用語を廃止するわけには行かない。
この用語は、1950年代から使われていたのだから。

そもそも、値というものには、二つの意味がある

・ユーザーが識別可能であるかどうか
識別可能というのは、具体的な変数名が付いていたり、アドレスが与えられていたりすること。
識別不可能というのは、関数の戻り値などの一時オブジェクト。

・ムーブできるかどうか

この二種類を組み合わせると、
・識別可能でムーブ可能：xvalue
・識別可能でムーブ不可能：lvalue
・識別不可能でムーブ可能：prvalue
・識別不可能でムーブ不可能：該当なし

という四種類の値が出来上がる。
このうち、「識別不可能でムーブ不可能」という値は、C++においては、意味が無い。
そういうわけで、C++における根本的な値は、三種類ある。
その値に名前を割り振ったわけだ。
0231デフォルトの名無しさん2010/10/25(月) 13:01:11
for(vector<int>::iterator i=v.begin();i!=v.end();++i)
は auto さんがいたら
for(auto i=v.begin();i!=v.end();++i)
と書けるわけで、ことさら range-based for さんを導入する動機が
やっぱりわからん
0232デフォルトの名無しさん2010/10/25(月) 13:32:01
beginとendと*itを書く事すらめんどくさいから
0233デフォルトの名無しさん2010/10/25(月) 13:32:37
あとはアダプタ噛ませるときに便利だから
0234デフォルトの名無しさん2010/10/25(月) 19:10:38
>>230
例えばxvalue, lvalue, prvalueには具体的にそれぞれどんなものが該当するの？
0235デフォルトの名無しさん2010/10/25(月) 20:11:01
>>231
配列だと .begin() とか書けないから
0236デフォルトの名無しさん2010/10/25(月) 21:10:36
さすがに右辺値と左辺値の区別くらいはついてないと、コンパイルエラーも読めないんじゃないか？
0237デフォルトの名無しさん2010/10/25(月) 21:16:54
lvalueは今まで通りのlvalue
prvalueは今まで通りのrvalue
xvalueは右辺値参照のこと

使う時はこれくらいの理解でおｋ
0238デフォルトの名無しさん2010/10/25(月) 21:36:13
lやrまではまだいいとして、pとかxとかわかんねえだろ
分かりやすくするという気はないのかね？
0239デフォルトの名無しさん2010/10/25(月) 21:43:57
お前がわかりやすい名称を提案すればいいんじゃないかな？
0240デフォルトの名無しさん2010/10/25(月) 21:57:11
省略するからだめなんだよ
0241デフォルトの名無しさん2010/10/25(月) 22:02:00
prvalueって見た目通りpointer rvalueなんすか？
0242デフォルトの名無しさん2010/10/25(月) 22:02:34
pureだろう
0243デフォルトの名無しさん2010/10/25(月) 23:34:26
「ムーブ可能」ってどういうこと？定義あるの？

処理前のオブジェクトの束縛が、処理後に無くなっても問題ないってことでおｋ？
0244デフォルトの名無しさん2010/10/25(月) 23:39:32
>>238
名前がどうのこうの言う前に概念理解してないだろ。
素直になれ。名前なんて単なる名前だ。酷い命名でもないし。
0245デフォルトの名無しさん2010/10/26(火) 00:02:22
>>243
もう必要ないから中身を好きなようにぶち壊してよい物体のこと
0246デフォルトの名無しさん2010/10/26(火) 00:03:24
>>244の書いたコードが見てみたいな
0247デフォルトの名無しさん2010/10/26(火) 05:42:21
>>234
lvalueはC++03から何も変わらない。
名前のついている変数やポインターのdereferenceやリファレンスなど。
rvalueリファレンスの変数も、もちろんlvalueとなる。
lvalueは、安全にムーブできない（ユーザーがどのように使うか分からないため）

prvalue(pure rvalue)は、主に一時オブジェクト。
名前がなく、ストレージが確保されている保証もない値。
リファレンス型以外の関数の戻り値とかがこれに該当する。
prvalueは、安全にムーブできる（ユーザーは自由に利用できないため）

xvalue(eXpiring value)は、ユーザーが意図的に作り出すもの。
つまり、lvalueやprvalueを、ユーザーが意図的にxvalueにキャストして、ムーブ可能であることを示す。
static_cast<T &&>(t)や、関数の戻り値の型がrvalueリファレンスの場合、xvalueとなる。

ほかにも、return文でローカル変数をオペランドに渡したときとか、暗黙にムーブが発生することとかがある。

>>244
内部で動的に確保した、何らかのリソースをぶんどってもよいかどうか。
コピー先のオブジェクトが、コピー元を使えない状態にしてもいいかどうか。
std::auto_ptrのようなもの。auto_ptrの場合、コピー後、コピー元は妥当なポインターを持たなくなる。
rvalueリファレンスができたおかげで、auto_ptrはめでたくdeprecatedになったけど。
0248デフォルトの名無しさん2010/10/26(火) 06:41:16
>>231
autoって大昔のcのころの機能イメージがあってちょっとコードみててもにょるのが難点
0249デフォルトの名無しさん2010/10/26(火) 11:14:46
>>247

>prvalue(pure rvalue)は、主に一時オブジェクト。
>名前がなく、ストレージが確保されている保証もない値。
>リファレンス型以外の関数の戻り値とかがこれに該当する。
>prvalueは、安全にムーブできる（ユーザーは自由に利用できないため）

こめん、上の2行目と4行目の記述が矛盾しているように見える。
｢ストレージが確保されている保証もない値｣ なら ｢安全にムーブ｣ でき
ないと思うけど。

｢ストレージが確保されている保証もない｣ が ｢メモリが、名前のある
ポインタ変数によって管理されていない｣ という意味ならわからんでも
ないが。


｢Move(移動)｣とは、右辺値オブジェクト(一時オブジェクト)が(そのデータ
メンバであるポインタを通して)管理している動的メモリを、左辺値オブジ
ェクトが管理している動的メモリとswapすることだと勝手に解釈してたけど、
これって間違い？

両者の動的メモリのアドレスをswapすれば、メモリのコピーも必要ないし、
右辺値オブジェクトはどうせ破壊されるから問題ないと思ってたけど。
0250デフォルトの名無しさん2010/10/26(火) 11:26:20
int x = 0 ; int y = 0 ;
int z = x + y ;

ここで、x + yという式を評価した場合、その結果を表す一時オブジェクトが生成されるが、
この一時オブジェクトは、具体的なストレージを持たなくてもよい。

ただし、xvalueにされたときは、具体的なストレージが必要となる。

int && rref = x + y ;

ムーブは、言語的にいえば、ムーブコンストラクターかムーブ代入演算子を呼び出すこと。
ライブラリ的にいえば、仮引数の型がrvalueリファレンスな関数も、ムーブしていると言える。

ムーブの具体的な実装は、好きにすればいい。
体一、コピーの具体的な実装も、好きにしていいのだから。
もちろん、デフォルトのコピー、ムーブコンストラクターや代入演算子の定義はあるけどね。
0251デフォルトの名無しさん2010/10/26(火) 16:40:54
ストレージってメモリ上ってこと？
それなら、その保証がないのはlvalueだってアドレス参照されない限り
同じなのでは?
0252デフォルトの名無しさん2010/10/26(火) 18:20:59
「常に可能であること」を「保証されている」と日本語では言う。
e.g. 常にアドレス参照可能

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