C++0x 11

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/

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/
C++0x 9
http://pc12.2ch.net/test/read.cgi/tech/1269623636/

C++学園で最近話題の人々

○禿
校長先生。
現在、ヒゲは剃っている模様。
ヒゲのない校長先生のいる学校は流行らないという迷信があるため、
学園の未来のために、ヒゲ剃りを窓から投げ捨てることが期待されている。

○コンセプトさん
もはや噂すらされない伝説の幽霊。
どのような容姿だったすら、もはや誰も覚えていない

○range-based for文さん
最近、C++学園のGCC校舎に通学しているところを見かけるようになった。
しかし、全く話題に登らない影の薄い子。

○アライメントさん。
近い将来、制服が変わる予定である。
何と贅沢にも、新しくデザインされた服を支給されるらしくて大はしゃぎ。
多くの生徒から羨望のまなざしで見つめられている。

○final, override, hiding三姉妹
アライメントさんと同じく、新しくデザインされた制服を支給される予定だが、どうも服のセンスがよろしくない。
退学にこそはならないものの、今後の立ち位置が不明で、しばらく自宅待機中。

○ムーブさん
最近、生徒会の役員に抜擢された期待の新人。
もう単なる一生徒ではないと大いばり。

○lvalue、rvalueさん
これまで二人の姉妹と思われてきたが、
実は、lvalue、xvalue、prvalueという双子が、代わりばんこに登校していたことが、
校長先生の推理により判明。
片想いのconstなlvalueリファレンス君もこれにはびっくり。
今までxvalueさんとprvalueさんのどちらが好きだったのか戸惑っている模様。

○lvalueさん
事実判明の後も、あまり変わらず。

○rvalueさん
実は不純だった！

○xvalueさん
自分の存在を隠しつつ、こっそりと通学していた影の役者。
校長先生によって、なんだかややこしい名前をつけられてしまった。

○prvalueさん
rvalueさんとはうって変わって、ピュアな心の持ち主であると、
校長先生自ら、全校生徒の前で褒めた評判の生徒。

○attributeさん
最近になって任されていた仕事が次々に剥奪された。
今は死んだ魚のような目で「のーりたーん」と呟くばかり。

○deleted定義さん
その秘めた力が最近ようやく認識されるようになってきた。
彼女にはきっとスターになる素質がある。

○default定義さん
deleted定義さんと扱いに差が付き始めた。
今後の運命はムーブさんとの仲をどれほど生かせるかにかかっている。

○constexprさん
彼女の一族「定数式」の正体が掴めないと嘆く校長先生。
生徒からの人気は高いようだが、一体どうなってしまうのか…

○noexceptさん
まるでずっと昔からそこにいたかのような貫禄で、throwさんを着々と追い落としている。
急な台頭は反感を買わないか心配である。

○threadさんファミリー
相変わらず揉めているらしいが、端からは何で揉めているのかさっぱり分からない。

○Raw String Literalさん
また頭とお尻の飾りが変わりました。よかったね。

○ユーザー定義リテラルさん
私、まだいるよ。

○Blocksさん
大量のリンゴと共にときどき学園に侵入するラムダさんの親戚。
最近リンゴが豊作で調子に乗っている。

attributeさんは可哀そうだな

最近追ってなかったけど
attributeの機能が軒並みキーワード化されるのか？

align,final,override,hiding,base_checkがキーワード化される見込みらしい
あとはnoreturnとcarries_dependencyしか残らない

残りも時間の問題か

なんだかしらないけどぼくにはべんりになるならなんでもいいとおもう
むずかしいことはかんがえたくないからぜんぶまかせます

未だにこんなに変更多くて
本当に0x内に仕様固まるんだろうか

その他特に動きのないお馴染みの人たち

○ラムダさん
服装はすっかり見慣れ、能力の良さも知られ、さらにもっとひどい服の従姉妹が暴れているため
もはや誰も何も言わなくなった。本人は少し寂しがっている。

○右辺値参照さん
rvalueさんのゴタゴタにもかかわらず、何変わらず涼しい顔。
xvalue参照に改名することもないようだ。

○initializer_listさん
特に何も変わってないが、入学手続きが難航しているらしい。
不用意な準備で入れると大変なことになるから仕方ないのだが。

○テンプレート可変長引数さん
最近initializer_listさんと手を組んで良からぬイタズラを考えてるらしい。
この2人と__VA_ARGS__さんがつるむと色々危ないので注視したい。

○autoさん
相変わらず生徒達の絶対的な支持を受け続ける新入生のアイドル。
D組で腐ってるregisterさんが妬みを募らせているのも今まで通り。

○decltypeさん
結局、服で性格が変わる悪癖は直す気があるのだろうか。
人気者なのは間違いないが、懸念もそのまま。

○nullptrさん
通学が確認された。ただそれだけ。

○ライブラリ科の皆さん
色々細かい揉め事はあるようだが、面倒なので省略。

>>8
おお！それは願ったりかなったりだな。

アトリビュートってC#の[フラグ]見たいなのだろ。あんな考えなしに属性を増やせそうな仕様は弊害ばかりで障害にしかならないと思う。

>>12
ラムダさんはもう実装されてる処理系があるから変えにくいよね。でもだからといっても必要ならかえる勇気も必要かも。
ラムダとautoはマジ便利なんでもう散々使ってるけど、より良い仕様になるなら非互換も我慢する

decltypeの同じ式を２度書く必要になるのはどうにかならないかな。

先走って実装したり使用している人への配慮はしなくても良いと思うんだぜ。


2009年どころか2010年にすら仕様がまとまらなさそうだなあ。。

2010とかもう�_
2011ですら怪しい

このすれって11スレ目なの？17スレ目なの？紛らわしくない？

>>17
紛らわしいけど
どっちでもいい

投げやりな感じがイイ

カンガルーが袋鼠目に分類されるみたいなもんだな

何を言っているのかと思ったら
0x11
に見えるってことかw

++を演算すれば
D言語の17スレ目に見えるな。

C++0xが2011年になるなら
Conceptさん復活できるんじゃないか。

むしろ、conceptをドラフトからそぎ落とすために、規格制定が当初の予定より一年遅れているんだよ。

それ以外のことも話し合っているように思えるんだが

>>22
Conceptさんは欲しかったな。
Conceptさん無しのテンプレートプログラミングはとても人に勧められたものじゃねえ。エラーメッセージの解読が難しすぎるだろう。

decltypeさんの括弧の有無の件は、妥当な仕様の気もするが、マクロ科との相性が最悪だよねたぶん。

必死になってC++0xを生み出すよりC#を機械語にコンパイルできるようにしてくれたほうが世の為だよねJK

ネイティブコードの需要はなくなることはないからな。
だけど、Cの腐った設計を補う機能を補う機能を補う機能を……というのが続いているような気がするので
C資産を無理なく併合できさえすればD路線の方が未来はある気がする

ただCの.hはまともな言語から見るとカオスに程があるので
やっぱりCの拡張形以外に道はない……残念ながら……

D言語こそ理想だけど
仕様が固まってもっと多くの人が使える様になってくれないとなぁ。
結局 現実的に使えない言語は美しくても存在意義が無い。

> decltypeさんの括弧の有無の件は、妥当な仕様の気もするが、マクロ科との相性が最悪だよねたぶん。
プリプロセッサ組は、落ちこぼれだとも、最強だともいわれている、変わったクラス。
って前スレにあったけど、その通りで、プリプロセッサ組マクロ科をばりばりに使う人なら
なんとか解決できるでしょう。

ていうか別にDじゃなくても、1978年のModula-2とかでも
メタプログラミングができないことを除けば、D言語と比べても遜色ないだけの機能を持ってたんだけどな。

UNIXとWindowsが両方とも開発言語にCを採用してしまったのは、悪貨は良貨を……の見本だよなあ。

>>30
君の表現の場合、

　悪貨は良貨を駆逐する
悪化＝C言語
良貨＝他の言語

ってこと？？

　メタプログラミングこそ正義ィィッ！　メタプログラミングに不可能はないィィッ！

某ブログのこの言葉に現代の流行が集約されている気がする。

>>30
C++は実通貨
他の言語、ゲーム内通貨

>>31
他の言語なら何でもいいってわけじゃないよ。
ただ、C++路線で進化させるにしても、ベースになってるのがCより少しましな言語でさえあれば
?++ももう少しましになってただろう、ってぐらい。
メタプログラミングなんかはその後に生まれた概念なんで、当時の言語に求めるのは筋違いだし
広く使われるようになっていればC++同様に拡張されてただろうし。

>>33みたいなことを言う奴もいるけどさ、今のC++と比べるから現実味が無いように思えるだけで
++も無かった当時のCと他の構造化言語を比べると、差はそんなになかった。

禿は、オブジェクト指向とシステムプログラミングに使える言語が欲しかったわけだ。
「アセンブリを除いて、C++より低級層を挟まない」
他の言語をシステムプログラミングに対応させるより、汚いCにクラスを付け加えるほうが楽だった。

また、プログラマはどんな汚い文法でも覚える、とも言っているな。
綺麗だが目的が実現できない言語と、目的は実現できるが汚い言語なら、
汚い言語の方がマシだ。

いや、C++を勧める人はそう言うけどさ、実際DもModulaもそれより下はアセンブリしか低級層なんてないぞ

DはGCがいるよ
いなくすることも出来るけど大変だよ

記述レイヤを挟まない、ということではなく、ランタイムライブラリによる支援を
必要とする言語機能は却下、ではなかったか？

>>38
dynamic_castとかあるのにそれはない。
そもそもFPUがCPUに内蔵されるのが一般化するまでは、浮動小数点演算すらランタイムの仕事だったぞ

32ビットOSが一般化するまではlongの演算すら

組み込みはまた別の話だが

>>30
頭が幸せな発想だな

>>38
ランタイムライブラリが必要なのはC++も同じ。
C++はCPUの動作に直結しているのがメリットでもありデメリットでもある。

>>37
GCうらやましす。
GCとshared_ptrのデストラクタによる手動管理を両立させることもできるんでしょ、想像だけど。

でもなんでもいいからC++0xをまともな仕様にしてほしい。

>>43
そげぶ

そのためのscopeです

C#のusingとかリソース管理方法を呼ぶ側で決めるとかバグの巣窟だろうに

え？！

Dはscopeクラスにすることでscope変数にすることを強制できるからC#とは違うな

autoさんは中退歴があるが新入生には違いないか

range-based forさんって、autoさんがいればいらない子なのかな。

そんなことはない。しかしコンセプトさんが消えたため邪悪な子になってしまった。

[理想]コンセプトさんとキャッキャウフフのバラ色の学園生活！
ーーーーーーーーーーーーーーーーーーーーーーーーーーーー
[現実]もういないコンセプトさんを求め続けるあまりヤンデレ化

>>49
実はこの子同姓同名の別人じゃね

>>49
修行して最強になって返ってきたって考えればまさに王道パターン

コンセプトさんは結局なんでダメになったの

「コンセプトさんはみんなのものだ！誰でも自由にお近づきになれるんだ！」派と
「コンセプトさんはそんな尻軽じゃない！正式に告白した相手としか付き合わないんだ！」派で
職員室が戦争になったから

仕様が１つにまとまらなかったから外したのか
もったいなさ過ぎる

>>57
しかし変な仕様で固まったらそれこそC++0xの未来が本気で
閉ざされるぞ。

他の仕様は未だに手が入ってるし
もう2000年代に出すの諦めたというか無理だったんだから
粘っても良かった気がする

>>59
>もう2000年代に出すの諦めた
次はC++3000か

C++3000だったらどんだけ進歩しているんだろうなww

目的を自然言語で入力するとアプリがビルドされる

それってどこまで曖昧な内容で指示していいんだろうか

g++ -ask "それってどこまで曖昧な内容で指示していいんですか？"

って聞くとg++(ver 7849.03.827)が懇切丁寧に教えてくれる。

禿の人格を移植するぐらいの勢い

Python3000とか大した事無いよ？

最近VC10導入したんだがautoとunique_ptrとlambdaだけでもう全然違うな
STLのコンテナとか右辺値参照のオーバーロードで
既存のテンプレートライブラリに適合できないとかインパクトあったわ
これ本格的な移行期は大変そうだね

一番夢を感じるのは可変長天ぷら

　　　,.、,､,..,､､,..,､､,..,､､,..,､､,..,､､.,､,､､..,_　　　　　 　／i
　　;'｀;、､:、. .:、. .:、. .:、. .:、. .:、:,　:,.: ::｀ﾞ:.:ﾞ:｀''':,'.´ -‐i
　　'､;: ...: ,:. : ,:. : ,:. : , :. : ,:. :.､.:',.: .:: _;.;;..; :..‐'ﾞ ￣ ￣

　　　,.、,､,..,､､,..,､､,..,､､,..,､､,..,､､,..,､､,..,､､.,､,､､..,_　　　　　 　／i
　　;'｀;、､:、. .:、. .:、. .:、. .:、. .:、:,　.:、. .:、:,:,.: ::｀ﾞ:.:ﾞ:｀''':,'.´ -‐i
　　'､;: ...: ,:. : ,:. : ,:. : , :. : ,:. :.､.:',.: .:: _;.;;..; :.:.､.:',.: .:: _.‐'ﾞ ￣ ￣

夢あふれるな

>>69を書いておいて何だけとエビフライって天ぷらじゃないよね

ワロタw

そこに気づくとは…やはり天才か…

エビ天じゃなかったのか！

そろそろC++0x業務で使っていい？
今後ドカンと仕様変更されるかも…なんてことはないよね？

ガンガン変わってるよ

FCDとは一体何だったのか

>>78
ただのまやかしである。

もう一度0から仕様を考え直した方がいいんでないか。

C++ 改

C++Z

C++乙

最近ダイテルのC++買っちゃったけど今から始めてもまぁ良いよね・・・

>>78
First Committee Draft の略じゃね

>>84
いくつまであるんだーーーwww


>>83
ダイテルってなぁに？

Deitel一族

http://www.amazon.co.jp/C-%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E3%80%88Vol-1%E3%80%89-Computer-Science-Textbook/dp/489471115X/ref=sr_1_3?s=books&ie=UTF8&qid=1286365594&sr=1-3

大照さん

>>87
どうせ暫く仕様固まらないからその間に勉強したら良いだろ。

>>87
良書

usingをスコープ付きのエイリアスみたいな機能にすれば便利なのに

>>91
参照との違いは？

余計なポインタ持たなくていいじゃない

>>93
参照≠ポインタ

そりゃ言語仕様上はそうでも、実装する時は結局何か指し示すもの渡さないといけないだろ
結局ポインタだよ

必ずしもポインタを介する必要が無いし、ポインタ必須の箇所ではusingは使えないし

何の話よ？usingは参照ともポインタとも全く違うだろ
異次元にあるものをごっちゃにするな

だいたい、どのusingだよ？
usingキーワードを使う文法はみっつもあるぞ。

typedefで事足りるんじゃないの

typedefじゃ関数や変数やテンプレートの別名がつけられない
参照やポインタではコストがかかるかもしれない
マクロは安全性に犠牲がでる
一番良いのはマクロと同じ機能をプリプロセスではなく言語でサポートしてスコープの概念を付け加えること

そんなのがあると今度はtypedefがいらなくなるなw

using template とは違うんだよね?
必要になる場面が思いつかないな

いや、D言語ではなんでもかんでもaliasで別名作れるんだけど、確かにすごい便利だぞ。
恐らくC++に導入されても、usingやらtypedefやら参照やらを一掃する勢いになる。
実際Dではtypedefが消滅した。

C++ 0x FAQにunique_ptrははいかなる形の動的チェックも提供しないってあるけど
auto_ptrやscoped_ptrと同じで動的削除子がないって理解でいいのかな？
pimplで試したら、デストラクタを定義しないとコンパイルできなかった

std::smart_ptrのような動的なデリーターはないね。
テンプレート実引数として指定する、静的なデリーターならあるけど。

std::smart_ptrってどこのパチモンだよ

>>105
ありがとうございます
以前どっかのスレで動的削除子があるような書き込みがあったので
一応確認してみました

[.hpp]
class Handle
{
private:
class Body;
unique_ptr<Body, function<void(Body*)>> pimpl;
public:
Handle(void);
};
-------
[.cpp]
Handle::Handle(void) : pimpl(new Body, Deleter<Body>())
{
}

なんということでしょう！

shared_ptrだったｗ

ttp://ja.wikipedia.org/wiki/C%2B%2B0x
> ...演算子を型名の左側におく場合、これは"pack"演算子
> ...演算子が型名の左側にある場合は、"unpack"演算子

これ、両方*左側*になってるんだけど、
まちがいだよね？

wikipediaの情報は大抵間違っているから信用するな。
とくに、日本語版は最悪で、暇人の自治厨が仕切っているからな。

プログラム関係はそもそも過疎っているので、あんまり自治厨は見かけない気がする。
もちろん、大抵間違っていることは変わりない。過疎、つまり直す人もいないということでもある。

>>111
あそこは事実や真実より声の大きい奴が勝つ場所だからどもならん

>>110 に書いたページを、結構、楽しく読んでから来てみれば
>>111-113 こんな書き込みw

じゃ、ほっとくか。

今、C++ 勉強してるんですが、
wikipedia の C++0xのページで触れられていることが、
100%嘘って事も無いと仮定すると、C++0xがでると、
プログラムの書き方が、かなり変わってくるんでしょうか？

で、Effective C++ 第4版を、読むことになると。

C++0xみたいなやつの場合、書いた時点では正しくても、
その後の変化に記事が追いついていないということもよくある。

それにしても、あの記事よく楽しく読めるね。
直訳調で、自分なんか読むのに疲れてくるんだけど。

まあ個々の内容はともかく、C++0xの記事の目次にある事柄自体は
だいたい本当なので、C++0xの新機能をばんばん使ったらかなり変わってくるだろうことは間違いない。

>>114
＞プログラムの書き方が、かなり変わってくるんでしょうか？
パラダイムシフトするかっていう意味なら変わらないと思う、ただ新しい書き方を適用可能になるのでより意図を伝えやすくなるコードを書けるようになる
なのでプログラマの意識次第だと思うぞ

また新しい定石みたいなもんが増えんのかねめんどくさい

レス、どうも。

>>115
> それにしても、あの記事よく楽しく読めるね。

新しい機能について、「うへぇー、こんな表記認めるんだー」
とか、いう感じで読んでるんで、表現は気にならないです。

ちょっと前に boost regex とか見て、正規表現リテラルが無いことを知ったから、
それが、raw って仕組みで解決されてるとことか…、
その他色々、ちょうど個人的にタイムリーで

>> 116
> パラダイムシフトするかっていう意味なら変わらないと思う

C++(とC)の、面倒くさいと言われている事の一つ、メモリ管理が、
shared_ptr とか、unique_ptr とかで簡単になるとして、
auto とかの表記を使って、型指定する面倒くささを軽減出来たら、
スクリプト言語並とは言わないまでも、ぐっと使いやすくなって、
楽チンになるのかなぁーと。

確かD言語は、スクリプト的にも使えるようになってたし、
C++0xのページに GC の事に触れられていたから、
ガラッと変わってくるのかと、期待と不安で質問してみました。

>>117
> で、Effective C++ 第4版を、読むことになると。

Effective C++0xか
そろそろ常人には手がつけられなくなりそうな

もうすでに…
ここまでついてきてる奴には、さほど問題なかろう。

しかし、自分が今から０から学ぶとか考えたらぞっとするなーw

ウィキペディアは間違ってたら直せよ。

直しても基地外が間違った状態に戻すようだったら文句言えよ。
俺の経験では10%もないぞそういうことは。

憂国の戦場な記事以外はだいたいあってるよな

直そうにも、現状で多くのISPのIPは、自治厨によって永久にBANされている。
ログインしない限り書き込めない。
しかし、アカウントを作るためには、BANされていないIPが必要。

こんな態度のWikipediaに、わざわざ一手間かけてアカウントを作ってまで、直してやる義理もない。

お前どんな悪行を働いたんだ……

>>124
俺じゃねーよ。
同じISPを使っている（使っていた）誰かだよ。

ムーブさんの立場が微妙なことに……
http://cpp-next.com/archive/2010/10/implicit-move-must%c2%a0go/

C++学園の黒歴史の面々

○禿
校長先生。
かつては、校舎の設計と建築に加えて、カリキュラムの構築までもこなし、さらには自身で教鞭をもとった。
しかし、最近、校舎の建築はしていない模様。

○ムーブさん
最近、正式に生徒会の役人に選ばれて有頂天になっていたが、
上級生の反発により、暗黙的な権限が大幅に制限される模様。
「互換性なんてクソだ」とつぶやいているとか。

○asm宣言校舎
C++学園創立の時、asm宣言の実習のために、急遽建てられたプレハブ小屋。
あまりに使い勝手が悪いので、誰からも使われることがなく放置されている開かずの校舎となっている。
かわりに、独自の校舎が乱立している。

○動的例外指定さん
自宅謹慎処分は受けていないものの、だいぶ教室のすみっこに追いやられた。

○exportさん
退学

○文字列リテラルに対するconst性を取り除く標準型変換の校則
生徒会による投票により、削除された。

○リンケージ指定事務員
広く他の学校と姉妹提携を結ぶという業務内容を担っていたが、C言語学園以外との姉妹提携は結ばれなかった。

○range-based forさん
いまだに話題に登らない影の人。
conceptさん亡き今となっては、不遇である。

暗黙のコピー「暗黙のムーブがやられたようだな」
暗黙のデフォコン「ククク…奴は四暗黙の中でも最弱…」
標準型変換「互換性ごときに負けるとは暗黙界の面汚しよ…」

>>128
そりゃあ、創立メンバーの3人と比べりゃなｗ

暗黙のデストラクタ「……」

暗黙なんて何一つ要らない

昔は俺もそう思ってたけど、暗黙のコピーコンストラクタ、代入演算子を積極的に使うように変わってきた。

演算子って暗黙の関数呼び出しですか？

暗黙のコピーコストラクターがないと・・・

struct S
{
int a001, a002, a003, ... a999 ;
S( S const & s ) : a001(s.a001), a002(s.a002), a003(s.a003), ... a999(s.a999) { }
} ;

そんな糞構造体を書くプログラマは暗黙のうちに解雇して良い

>>134
うわぁ…

>>134
ステキな例

>>134
ちなみにboost.preprocessorライブラリでそれを書けば
暗黙のコピーコストラクターがなくても
もっと簡単に記述できるのかな、と。

暗黙コピコンがないとCの構造体コピーがコンパイル通らないだろ
これも互換性のための汚い仕様

暗黙のコピーコンストラクターが無かったら、全てのメンバー変数をコピーするコードを間違えないように書かなくちゃならないじゃないか
メンバー増やしたときに追加忘れすると面倒なバグになるじゃないか

>>140
うわぁ

デフォルトコピーコンストラクタで、メンバ変数のコピーコンストラクターが自動的に呼ばれるけど違った？

>>140
面倒か？
コンパイルエラーになるだけなら大したことないと思うが

初期化子書き漏らししてもエラーになら無い場合があるし

現状の暗黙のコピーコンストラクタと同等の物を明示的に作成する構文があればいいんだろ。
俺はそんな物を作るくらいならコピーコンストラクタの自動生成でいいと思うけど。

default定義さん「……」

=defaultって毎回書くのめんどいから
class Hoge
{
public:
default{
Hoge();
Hoge(const Hoge &);
Hoge(Hoge &&);
}
};
これ通るようにするべき

default定義 でググるとSQLのCREATE TABLE文ばっかりヒットするしなあ……

virtual foo() = 0; って毎回書くのめんどいから(ry

>>146
いやあごめんごめん。コンストラクタさんとも仲良しってことをすっかり忘れてたよ。

>>149
class Hoge
{
public:
virtual {
void foo();
void bar();
void baz();
} = 0;
};
最高にクールだな

そんなことよりなんでラムダ式に呼び出し規約を指定できないんだよ。
C#みたいにラムダをコールバック関数として使いたいのに。
しょうもないコールバックのためにわざわざ非メンバ関数やグローバル変数を
定義するのはいやだお。

>>152
ラムダ式は関数じゃなくて関数オブジェクトだから呼び出し規約はないだろう

関ポに出来るなら関ポになるんじゃなかったっけ

呼び出し規約？
MSVCにおける__stdcallとかか？
そんな規格外のことを言われてもな。
規格的にいえば、attributeで実装して欲しいところだが、
規格を守る気のないMSがやるかなぁ？

>>153
一応、何もキャプチャーしてないと、単なる関数ポインターに変換可能。

まずは、API関数をラップして、好きなファンクションオブジェクトを引数に取れるラッパを作ればいい。
そしたら、ラムダ式でも何でも渡し放題だ。
ってのをWinSTLとかやっていないかなあ？

gccのトランポリンは外のローカル変数に触ってても普通にstdcallでコールバックできるし、clangのblocksとかもあるし
ラムダめいたことに関してはC言語の独自拡張の方がC++よりもずっと進んでる

独自拡張は独自拡張でしかないからなぁ…
一生窓やリンゴだけ食って生きてく覚悟があればいいんだろうけど

blocksはちょっと色々とアレなとこが・・・

>>158
トランポリンはスタック全部に実行可能属性が付く気持ち悪い仕様

Windowsでは、呼び出し規約が統一された64bitコードにさっさと移行しろってことだろ。
まあ、それが出来れば苦労しないんだろうがな。

呼び出し規約自体独自拡張なんだから、
[](int x) [[ __stdcall ]] -> { return x; } みたいに
attribute さんに仕事をあげればいいのに

気持ち悪さに磨きかかっちゃってる・・・

どうせならラムダの最初の[]の中にattributeを書くようにすればいいのに……。

同名の変数が有ったらどうすんだよ

class Hoge
{
public:
　const {
　　void foo();
　　void bar();
　　void baz();
　};
};

class Hoge
{
public:
　const {
　　void {
　　　{ foo, bar, baz }();
　　}
}
};

>>166

[[[ __stdcall ]]](int x) { return x; }

キモさに磨きがかかるな

>>168
便利すぎてやばいな
これ考えたやつは天才だと思う

>>167
ってOKなの？

いや夢語りだろう。

VBのWithに通じるクソっぷりを感じる

>>174
何行も前を確認しないと関数の定義がわからないとか駄目すぎるね。

何行も前を確認しないと関数のアクセスレベルがわからないなんて……

class Hoge
{
public virtual Hoge const & { foo, bar, baz } (void) const throw() = 0;
};

う、美しい。。。

何行も前を確認しないとクラスの名前がわからないなんて……

C#みたいに全メンバにアクセス修飾子がついたクラスなら見たことがある。

それはメンバの再配置期待してるんだろ
たまにやるよ

メンバのre-orderしてくれんなら俺もやろうかな

他はともかく、staticだけはpublic:なんかと同類でグループ指定にしたほうが分かりやすい気はするな

メンバの再配置って class A { public: char a; public: int b; public: char c; };
のメンバが b,a,c の順にメモリに並んでくれるのかと思ったけど、そうじゃないね。

>>183
PODにすれば記述順配置になるんじゃなかった？

別にPODでなくても、publicなメンバ同士、protectedなメンバ同士、private:なメンバ同士は
それぞれ記述順に配置される

あれ、記述順になるのは同じラベルじゃなかったっけ
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"とは何なのかハッキリ定義されてないからどっちにも読める

なるほど。the same access control って、
(a,b,f) (c,d) (e) が同じって意味だと思ってたけど
(a,b) と (f) は違うって解釈もできるのね…

これ↓を見ると
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になった)

ですよねー。。。

なんだダメになってたのか
それにしても修正入れた割には曖昧な文言だな

最適化するしないで互換性が無くなるクラスとか有ったら死ねる

というか配置順変えていた実装あるんかいな。

sunのコンパイラが宣言と逆順に配置してたよ

若干スレ違いな感じもしますが、新しい規格ということで・・・

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
は必要ないのか？とか、環境依存性は？とか、色々気になります。

>>194
なんで _GNU なんてついたマクロが必要かもしれないなんて思うのか、わからない。
「環境依存性は？」と言われても仕様を見たとおり、としか言えない。

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

「自己流で自信が無い」と言うが、ここで名無しさんが何か言ってくれたら自信が付くわけ
でもないだろう。

ttp://linux.die.net/man/3/fenv
とかを見ると、細かい設定をglibc拡張でやれるって話みたいでした。
色々混乱しててすみません。

C99とか0xの範囲なら環境依存するはずないですよね。

ムーブさん先行き不安だな…

moveは仕様をきっちり作り込むのが難しいよね。

ムーブさんはコンセプトさんと似たような泥沼に入りかけてる気がしてならない

コンセプトさんが憑いたのか

右辺値参照さんまさかの入学取り消しあるで

内定取り消しか…胸が熱…(´;ω;)ｳｯ

右辺値さんmixiで調子乗ってなんかやらかしたんだってさ

おまえら全員留年な

>>201
詳細求む

デフォルトムーブコンストラクタの件じゃないのか？うまく折り合いをつけて採用してほしいところ。

いまさら右辺値さん取り消したら、unique_ptrさんも道連れだよ。
unique_ptrさんマジ便利。いまさらなくせないだろう。

range-based for文さんを道連れに消えていったコンセプトって子がおってな

【スキャンダル】入学審査で不正疑惑が【椿事】

>>207
あたらしい転校生のBOOST_FOREACHさん。,さんが苦手。

というか、range-based forいらねーよ。
その次の規格でconceptと一緒に入れてくれよ。

そうか？
使ってみると、意外と便利だぞ。
まあ確かに、今のような糞なイテレート方式じゃなくて、concept使って欲しかったところだが。

range based forぐらい自分でパチもん実装できるからいいじゃん
つーかboostもあるし

そんなこと言ってたらC++0xが要らなくなるだろ

polymorphic lambdaがない以上、以下のコードがうまくいかないんだよな。

std::vector<int>v = { 1, 2, 3 } ;
for ( auto i : v ) { }

どううまくいかないの?
一見して問題なさそうだけど。
実際、gcc4.6 ではエラーにならない。

いや、ちがうちがう。
パチもんが実装できないということ。

range-based forって一つの書き方で多くの範囲オブジェクトをカバーできるところが大きな魅力になってるの？
俺はよく使うコンテナクラスにそれぞれ特化したforを定義して使ってるんだけど

>>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も使えるし

>>218
いいな
俺はvから元クラス参照でそこから::iteratorでもいいんだけどね
要するに元の宣言vector<int> をvからひきだしたいだけなんだけど
コードの中にtypdef宣言いれないでmapとかの長い宣言作ると::iteratorの書式が長くて嫌いなんだよね

>>219
auto使えばいいんじゃね？

理想は>>218がこうなればいいんだけどな
int s = std::accumulate(v, 0);

>>220
foreach(auto x:v){}
だな。
BOOST_FOREACH(auto x,v){}
でもOK
>>221
boost::range や Ovenがそれの役目だな。

標準ライブラリのコンセプト対応で可能になるはずだったのにね・・・

おまいらには、頭が下がります.
物覚えが良くないので, 0x の変態構文にはもうついていけんわ
# つか, テンプラの時から思ってたんだが,
# lisp の ` と , を知ると何とか整理してくれやぁ！！！ になる

>>223
コンセプトがあればエラーメッセージがまだ判りやすくなるのにな。
意味不明のエラーメッセージは新規ユーザにとってかなりハードル高いな。
boost conceptcheckでもかなり改善になるから採用されないかな。

>>224
いえいえ、御代官様の括弧式ほどでは。ふっふっふ

禿げよ。

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

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

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

みなはお前みたいに言語を趣味にしてるんじゃないぞ。

xrvalue → xvalue

>>227
互換性を無視していいなら、同等以上の機能を遥かにシンプルに定義できるっしょ。
xvalueも、規格の文面を全面書き換えするのを避けた結果なんだっけ？

禿曰く、

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

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

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

・ムーブできるかどうか

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

という四種類の値が出来上がる。
このうち、「識別不可能でムーブ不可能」という値は、C++においては、意味が無い。
そういうわけで、C++における根本的な値は、三種類ある。
その値に名前を割り振ったわけだ。

for(vector<int>::iterator i=v.begin();i!=v.end();++i)
は auto さんがいたら
for(auto i=v.begin();i!=v.end();++i)
と書けるわけで、ことさら range-based for さんを導入する動機が
やっぱりわからん

beginとendと*itを書く事すらめんどくさいから

あとはアダプタ噛ませるときに便利だから

>>230
例えばxvalue, lvalue, prvalueには具体的にそれぞれどんなものが該当するの？

>>231
配列だと .begin() とか書けないから

さすがに右辺値と左辺値の区別くらいはついてないと、コンパイルエラーも読めないんじゃないか？

lvalueは今まで通りのlvalue
prvalueは今まで通りのrvalue
xvalueは右辺値参照のこと

使う時はこれくらいの理解でおｋ

lやrまではまだいいとして、pとかxとかわかんねえだろ
分かりやすくするという気はないのかね？

お前がわかりやすい名称を提案すればいいんじゃないかな？

省略するからだめなんだよ

prvalueって見た目通りpointer rvalueなんすか？

pureだろう

「ムーブ可能」ってどういうこと？定義あるの？

処理前のオブジェクトの束縛が、処理後に無くなっても問題ないってことでおｋ？

>>238
名前がどうのこうの言う前に概念理解してないだろ。
素直になれ。名前なんて単なる名前だ。酷い命名でもないし。

>>243
もう必要ないから中身を好きなようにぶち壊してよい物体のこと

>>244の書いたコードが見てみたいな

>>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になったけど。

>>231
autoって大昔のcのころの機能イメージがあってちょっとコードみててもにょるのが難点

>>247

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

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

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


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

両者の動的メモリのアドレスをswapすれば、メモリのコピーも必要ないし、
右辺値オブジェクトはどうせ破壊されるから問題ないと思ってたけど。

int x = 0 ; int y = 0 ;
int z = x + y ;

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

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

int && rref = x + y ;

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

ムーブの具体的な実装は、好きにすればいい。
体一、コピーの具体的な実装も、好きにしていいのだから。
もちろん、デフォルトのコピー、ムーブコンストラクターや代入演算子の定義はあるけどね。

ストレージってメモリ上ってこと？
それなら、その保証がないのはlvalueだってアドレス参照されない限り
同じなのでは?

「常に可能であること」を「保証されている」と日本語では言う。
e.g. 常にアドレス参照可能

VC++2010なんだけど、ムーブ後なのにf1()もf2()も普通に呼べちゃうのはなんで？

#include <functional>

int main()
{
std::function<void()> f1 = [&]() { std::cout << "1" << std::endl; };
std::function<void()> f2 = std::move(f1);
f1();
f2();

return 0;
}

ムーブコンストラクタが無いから参照になってるんじゃ

ムーブ後の変数は使える保証はなくなるけど、必ずしも使えなくなる
わけじゃないよね。

deleteされた領域を参照すると値が残ってたりするのと一緒

あくまでも高速化のための機能だから、nullで埋めるなんてことはしてくれないんだね。

[&]() { std::cout << "1" << std::endl; };

これやっぱ何回見ても気持ち悪いわ
C++0xで最も汚いのはラムダ式だと思う

代替案を出さなかったのが悪い

ラムダさんは使いつづけてると
やっぱりこの形しかないかなぁと思えてくるよ

int x;
lambda(int a) { vcap.x = a; } //値キャプチャ
lambda(int a) { rcap.x = a; } // 参照キャプチャ

C++0x版のD&Eが今から楽しみだな
ビャーネ・ストロヴストルップ先生のブツクサ文句が山ほど書かれていると思うと・・・

弾道軌道からの眺めも書いてくれるかな

俺はEC++0xが楽しみ

>>253
VC++2010もってないしstd::moveも引数に何とるのか解らんけど、
std::moveがMove Constractorと同じ意味合のものだとしたらマズくね？
なんで名前が使えるものを渡されてコンパイルエラーにならないんだ？

>>265
std::moveでキャストしてるからコンパイルエラーにならない

std::move() ってのが一種のキャストというか、無理を押し通すための道具だから。

>>258
もうすっかり慣れっこになったけど、時々C#のラムダ式を書くとき混乱する。

>>267
んなもん何のために使うのかさっぱりわからんなぁ。
const_castを全く使わんからかもしれんけど。
(旧C互換で定数をchar*で渡す関数にしか使ったこと無い)

左辺値を強制的に右辺値に変更する働きをする
これで意味が分からなかったらぐぐれ

コピーコンストラクタとムーブコンストラクタに限らず、左辺値参照と右辺値参照を取る
オーバーロードがあって、しかも効率の差が大きい場合、

void hoge(int &x);　// 左辺値を渡しても安全だけど遅い
void hoge(int &&x); // 左辺値を渡すと安全は保証されないけど速い

左辺値をどうしても下の関数に渡したい時に使う。

>>255-256
つまり、VC++2010のムーブの実装はswapじゃないってこと？

>>272
つうか、おそらく単なる参照渡し。
ムーブ後の抜け殻に触った結果はどうせ未定義なんだから、仕様は満たしてるよね。

こんなんなってた

11: std::function<void()> f1 = [&]() { std::cout << "1" << std::endl; };
00411750 xor eax,eax
00411752 mov byte ptr [ebp-121h],al
00411758 movzx ecx,byte ptr [ebp-121h]
0041175F push ecx
00411760 lea ecx,[ebp-2Ch]
00411763 call std::tr1::function<void __cdecl(void)>::function<void __cdecl(void)><`anonymous namespace'::<lambda0> > (41104Bh)
00411768 mov dword ptr [ebp-4],0
12: std::function<void()> f2 = std::move(f1);
0041176F lea eax,[ebp-2Ch]
00411772 push eax
00411773 call std::move<std::tr1::function<void __cdecl(void)> &> (41110Eh)
00411778 add esp,4
0041177B push eax
0041177C lea ecx,[ebp-4Ch]
0041177F call std::tr1::function<void __cdecl(void)>::function<void __cdecl(void)> (411096h)
00411784 mov byte ptr [ebp-4],1
13: f1();
00411788 lea ecx,[ebp-2Ch]
0041178B call std::tr1::_Function_impl0<void>::operator() (41126Ch)
14: f2();
00411790 lea ecx,[ebp-4Ch]
00411793 call std::tr1::_Function_impl0<void>::operator() (41126Ch)

>>272
中身がただの関数ポインタになってて、ポインタのムーブはただのコピーが最善手
ってことじゃないかな？

というか、std::moveは、単にrvalueリファレンスにキャストするだけだ。
std::move(t)と書くのは、static_cast<T &&>(t)と書くのと同じだ。
別にムーブと同等の処理は、非constなlvalueリファレンスを引数に取る関数でもできる。
単に所有権の移動と考えろ。

クラスのオブジェクト自体が魔法のようになくなったりはしない。

右辺値参照を受け取る側は元の値を「気兼ねなく破壊できる」ってだけで
破壊する義務はないってことか。

rvalueリファレンスは、あくまでただの「リファレンス」だからな。
rvalues(xvalueとprvalue)で初期化しなければならないこと以外は、lvalueリファレンスと何ら変わらない。
もちろん、rvalueリファレンスの変数自体を評価するとlvalueだ。

int && ref = 0 ;// OK、0はprvalue
int && aho = rref ; // エラー、rrefはlvalue

>>278
rvalueリファレンスの変数を評価したらxvalueじゃないの？

Non

>>253
そのラムダ式の()は不要だよね。
ネットで見かけるコードだと、相当な上級者の書いたコードでも()が
ついてるけど、なんでみんな書きたがるのか。
でもさすがに某標準化委員は書いてなかった。

規格を読まず他人のコードを読むから

別に書いちゃいかんというルールもないし。

省略するのはなんか気持ち悪いじゃん
慣れの問題だろうけど

引数有る無しで書き方を変えるのが変わるのが嫌、とか

ラムダの時に()を省略できるなら、普通の関数宣言でも()を省略できてもいいじゃない

こうなのか？
std::function<void()> f1 = [&]{ std::cout << "1" << std::endl; };

やっぱり括弧つけようよ

#include <iostream>
いやいやこれで十分でしょう。

int main()
{
[]{ std::cout << "1" << std::endl; }();
return 0;
}

なるほど、ファンクタクラスを作るシンタックスシュガーなんだなあ。

しまった。行が入れ替わったｗ

#include <iostream>
//いやいやこれで十分でしょう。

int main()
{
[]{ std::cout << "1" << std::endl; }();
return 0;
}

#include <iostream>
//つまりこれと等価ということか

struct x {
void operator()() { std::cout << "1" << std::endl; }
};

int main() {
x()();
return 0;
}

Delphi/C#のpropertyみたいなものは導入されないんですか？

知らずに0x使うと爆死するようなトラップ要素って右辺値参照さんのほかになんか有りますか？

>>292
Javaには入る。
C++はもっとprimitiveな機構に分解できれば入ると思う。

>>292
n1615みたいなのは(作れば)あるけど規格には入らないだろうね

>>291
// #1-n と #2-n は等価。
int main()
{
　using namespace std;
　{ // #1
　　int i = 0;
　　auto x1 = [] { cout << "#1-1. " << endl; };
　　auto x2 = [i] { cout << "#1-2. " << i << endl; };
　　auto x3 = [i]() mutable { cout << "#1-3. " << ++i << endl; };
　　auto x4 = [&i] { cout << "#1-4. " << ++i << endl; };
　　x1(); x2(); x3(); x4();
}
　{ // #2
　　int i = 0;
　　struct { void operator()() const { cout << "#2-1. " << endl; } } const x1 = {};
　　struct { int const i; void operator()() const { cout << "#2-2. " << i << endl; } } const x2 = {i};
　　struct { int mutable i; void operator()() const { cout << "#2-3. " << ++i << endl; } } const x3 = {i};
　　struct { int & i; void operator()() { cout << "#2-3. " << ++i << endl; } } x4 = {i};
　　x1(); x2(); x3(); x4();
}
}

そう言えばVCに__declspec(property)ってあったよな。

ラムダ関数を変数に格納する場合、インスタンスと参照、どちらを格納したことになるんでしょう？

1: auto func=[](int x,int y){return x+y;};
2: {
3: 　　func=[](int x,int y){return x-y;};
4: }
5: std::cout<<func(2,1);　　　//出力：1

3行目にfuncにラムダ関数を代入していますが、
これが参照なら5行目はスコープ外ですから動作が不定になりそうです
g++4.5.1では1が出力されたのですが

インスタンスという認識でいいと思うよ

参照でもinfinite extentなら問題ない。
どうせimmutableなんだから。

ありがとうございます
std::function,queueと組み合わせてタスクキュー的なものを作りたくて

関数が変数みたいに使えるって便利ですね

>>298
何もキャプチャーしてないが、typoか？

>>302
何かをキャプチャしなければならないというルールはないよ

typoを修正してくれるライブラリ。Boost.Typoみたいな感じで誰か作ってくれないかな

なにもかもがBoost.Typoの意図通りに捻じ曲げられそう…

main
{

あとはboost::typoにお任せるぜ

>>293
右辺値参照がどうやって「爆死するようなトラップ要素」になるの？

class Hoge
{
int * p;
public:
Hoge(int n) : p(new int(n)) {}
Hoge(Hoge const & o) : mp(new int(*o.p)) {}
~Hoge(void) { delete p; }
};
こういうクラスで暗黙にmoveされたらテンポラリとmove先両方でdeleteされてまずくない？

>>309
そんなわけで暗黙のムーブコンストラクタは無しになったのさ。 >>126 参照。

ちなみにそのクラス定義だと現行の C++ でも代入で死ぬよ。

まだなくなると決まったわけじゃない。
特に、禿がひいきにしているからな。
禿によると、そもそも暗黙のコピーも、ユーザー定義デストラクターがあった場合、
暗黙に生成されないべきなんだとさ。

まあ=defaultで明示的にってのは悪くない考えだけど、いまさらなあ…

しかし今までのコードと互換性が無くなったらストレスで俺たちがハゲになっちまう

もういっそC++++作れよ

本物の C++ 使いはハゲを恐れない。

というかもう殆ど禿げてる
まだ２０なかばなのに

>>316
いつ新しい言語を設計するんですか？
C++と同等に使えて、evalも用意されている言語をお願いします。

>>317
evalはちょっと欠陥品だろう。
頼むからもうちょっとまともな仕様の言語が欲しい。

まあC++1xでconcept入ってしばらくしたら、
その辺の成果を全部生かした言語も作られるんじゃないでしょうか。

いい加減新しい言語作って若いもんに覚えさせたほうが人類のためになるよね
人類はいつまでC系列にしがみつく気なんだろう

プリプロセッサまわりが汚すぎて、既存のライブラリを確実に移植する方法が
手作業以外に無いんだから仕方ない。
OSのAPIから新言語で提供されていれば話は違うんだろうけど、それも既にModulaが通った道だ。

>>320
だからお前がまず代替案を出せよ

C++0xのラムダ式も誰も代替案を出さないからあの汚い形のままなんだぞ

functionとかキーワード化したいよなぁ。
というか、将来のために基本的な英単語を予約しておかなかったのが、そもそもの間違いだった。

functionって毎回書くの長ったらしくないか？

>>320
事情はx86CPUと似ていると思うよ
アーキテクチャがいかに汚くなろうと、過去の財産を大事にすると生き残る

互換性を窓から投げ捨てろ
つうか生き残らなくていいからどんどん新しい物を作って破って捨てろ

お前がこのスレに要らん

>>309
デフォルトコピーコンストラクターが使えないクラスにデフォルトムーブコピーコンストラクタを望むのが間違ってるよ。
デフォルトコピーコンストラクタが可能なクラスなら、おそらくデフォルトムーブコンストラクタが可能じゃないか？こいつらはセットだよ
コピーコンストラクタもムーブコンストラクタも定義されていないクラスのみデフォルトコピーコンストラクタとデフォルトムーブコンストラクタを許可すればすむと思うが、どうか？

>>324
typedef function<int(int,int,int)> func_type;してから使うから気にしない。

>>326
互換性を捨てるならＣ＋＋である必要はなく、ＤでもＥでもＦでも作ればいいんじゃね？

最近の新言語ってJavaもどきとLLと関数型ばっかりでつまらん
結局代わりになる言語を誰も作ろうとしないのよね

>>331
> 結局代わりになる言語を誰も作ろうとしないのよね
頭おかしいのww
作ろうとした人ならめっちゃくちゃ居るよ。

成功した人がいないだけだ。

つくろうとしても既存のコミュニティが受け入れずに潰されるからね

>>329
基本autoでよくね？


enum classってusing enum EnumName;とかって名前空間みたいな書き方できないのかな？
現行でこんな書き方してるから、置き換えられるんなら置き換えたい。

namespace EnumName //列挙型の識別名
{
enum Enum
　{
VALUE1,
VALUE2
};
}

{
using namespace EnumName;
switch(x)
{
case VALUE1:break;
}
}

C++は変態言語だから生き延びたのよ

>>333
それは単なる被害妄想。

>>323
逆じゃないかなぁ。
ユーザーコードで基本的な英単語が変な心配しないで使えるように、
キーワードこそ多少不自然な省略なりしたものを使ったほうがいいんじゃ
ないか？

成功が広く使われることならば、
最近成功したのはLLとObjective-Cだけでしょ。
俺はOmegaや<it>G</it>なんかも面白かったけど。

＞Objective-C
え？

糊インタプリタも軽量言語もC/C++もアセンブラも混ぜこぜで１ソースで書けて且つ一緒クタにコンパイル/リンクが行えて且つ構文エラーやら警告も一緒クタに吐いてくれる環境の標準化シテ欲しいね

>>340
つD

Obj-Cって別に最近出来た訳じゃないだろ

今最もホットな言語なのは間違いないが

禿がポックリ逝ったらC++0xはどうなるんだよ？




いや、それでもいいか

別な誰かが禿げる。

画像をウィンドウの前に表示するためにはどうすればいいですか？

そのウィンドウの前に画像を表示するウィンドウを出してください

禿げが死んでもC++は生き残るさ
２ｃｈはひろゆきが死んだら終わりなんだっけ？

2chはもうどっかの外資が支配してるからひろゆきは関係ないよ

>>347
むしろ禿げが死んだらC++は衰退し、
２ｃｈはひろゆきの手を離れてもこうして続いている。

C++は滅びぬ、何度でも蘇るさ
C++の力こそ人類の夢だからだ

C++は糞言語かもしれないが、あまりに多大な時間と労力を掛け過ぎ、
しかも関わった人が多すぎた
今更白紙に戻す事はできないってのが実情でしょう

>>351 世の中には「語ってはいけない真実」ってのがあるってしってるか?

禿げはA級戦犯ってことか

EXEやDLL、a.out、soのサイズがCに比べて格段に大きくなる傾向があるので
DLLとsoは必須だな

但しx86はコールゲートを通すと滅茶遅くなるんだよなあ
そこは我慢か

>>351
お前がNo.1だ

C++がこのまま肥大化する一方で、PL/Iの悲劇を繰り返さなければいいのだが
まあパソコンのスペックが上がってHDDもテラバイト時代なので、多少大きくても
楽々入ってしまうけどな

こういう問題のある基盤に大量のものが乗っかった状況を改善する一般的手法ってないの
結構そういう状況って他にも溢れてると思うんだけど

>>357
あるとしたらC99とかD言語だけど、知っての通り単なるマニア向け言語に
なってしまっただろ？

Cがあれだけ広く使われてしまったらもう引き返せないんだと思うよ
Cの上に乗っているC++もC++0xも結局同じ道を半ば強制的に辿らされる

他のLL言語は遅くて使い物にならないしな

C#も糞だって分かってしまったし
ただC#やJavaは開発コストと時間を大幅に削減出来るので、一度立ち上げて
しまえば滅多にシャットダウンしない、速度もそんなにカリカリ必要ないデータベース
にはこれからも使われていくだろう

段階的にやるなら、C99で暗黙のintが禁止されたように、じわじわと締め付けていって
・配列からポインタへの暗黙の変換を禁止
・#defineのソース置換を禁止して条件コンパイル用に限定(enumやinlineに移行させる)
・enum/struct/unionのタグとスコープの関係の明確化
あたりを整理。strictモードでコンパイルすれば警告が出るようにして、段々と曖昧な書き方をされた
.hを駆逐していくしかないだろう。
今でも関数ポインタではなくて関数型そのものをtypedefしてる糞.hが山ほどある。

現存する膨大な.h資産から曖昧な部分が無くなれば、C++もこのへんの互換性を残す必要も無くなるし、
他の(LLやVM向けではなくCと同分野の)言語(Modula/Fortran/D……)に向けて.hを自動変換するのも楽になる。

C1xでもそんな話は一切でてないけどな……。

>>359
> 今でも関数ポインタではなくて関数型そのものをtypedefしてる糞.hが山ほどある。

むしろなんで関数型を typedef せずにポインタまでつけた typedef しか提供しないんだ糞が、
それじゃ関数宣言の照合にも使えないし function にも使えないだろうが糞が、とか思うんだけど、
なんでポインタで typedef しないと糞なの？

>>359
C99 を策定したことで古い C のコードの書き換えが進んだりしてないでしょ。
新しい規格の締め付けで古いコードの駆逐なんて期待はできないよ。

コードが準拠してる規格のバージョンを明記することで危険な変換が禁止される
ようになる、とかすればいいのかな？

using "C++2003";
int x = ...;
unsigned int y = x; // ok, but unsafe

using "C++2020";
int x = ...;
unsigned int y = x; // error

>>360
値として使えない型を導入してしまうから。
いやもちろん、今のsyntaxだとパーサレベルでは関数型を扱わないといけないんだけど。

>>361
-Werrorで充分じゃ……。

>>361
実際問題暗黙のintはかなり減った、というよりほぼ全く見なくなったでしょ。
C99というよりC++の功績とは思うけど。

>>362
値として使えない型を導入されると、糞というほど困るの？なんで？

>>362
不完全型の typedef なんぞ腐るほどあるなあ

>>363
long long

>>364
とりあえず現状のCには関数宣言の照合やfunctionの類の機能が全くないので
あってもまるで嬉しくないのに、sizeofその他の例外をvoid以外に増やしてしまう。
(voidの値もダミー値として扱いたいと思ってるクチ、
ついでにvoidをunitに改名して"void"は正しくnoreturnの意味にならないかね)

C++で必要だから導入して、Cがそれを互換性のために追認というならまだしも
現状本当に何の意味もなくただコンパイラが通すからってだけで関数型がtypedefされてるのは
普通に関数ポインタと思って使ったらエラーになったりする……糞が、って思うぐらいで
全く利点がないだろ。

>>366
関数宣言の照合がない C って K&R C か？
a();
void a(void) { } /* error */

>>366
> とりあえず現状のCには関数宣言の照合やfunctionの類の機能が全くないので
×全くない
○全く知らない

typedef int f_type(int);

f_type f;
void f(int); // error

>>368
想像図を書くなら
typedef int f_type(int a);
f_type f { return a; }
だろ

関数定義に「突然」出てくる a は型情報ではないので
確かに気持ち悪い

>>366
> 普通に関数ポインタと思って使ったらエラーになったりする……糞が、って思うぐらいで

ただの思い込みで逆切れとか、ひどいな。

↓どっちが関数ポインタに見えるかって、見りゃわかるだろうに。
Function p;
Function* p;

>>367
>>360が言ってるのは、(仮にこんな文法があるとして)

void a(void);
typedef void f(void);
static_assert(a is f);
template<typename x> class t { operator x ...//変換演算子

みたいな話と解釈したけど。typedefの話なんだから。

>>371
それを実際にやるのが >>368 なわけだが。

って、今試してみたら>>368って通るんだな。これは知らなかった。
これについては俺の間違いだ。ごめん。

>>371
static_assert(typeid(a) == typeid(f));
という話ならわからんでもないが
operator が出てくるのは何？

>>374
関数にキャストできるtemplateで何かできそうだと思って書きかけてやめたんだが消し忘れたようだ。無視してくれ。

>>375
それは構文上はＯＫで、意味でＮＧという（であるべき）話じゃないか？
int a(int);
int b()(int); //OK. b returns int(int)
int b()(int) { return a; } //NG. expression has incomplete type
int a(int c) { return c; } //if a was complete...
int d()(int) { return a; } //NG. d cannot copy from a to rv

そうですね

>>368
それプロトタイプ宣言ではできるけど
関数定義の方では使えないんだよな（できたとしても引数名も分からないし）
プロトタイプ宣言と関数定義の表記が揃ってないと読み辛いし
結局役に立たない

>>361
Cコードの書き換えが進まないのは
単にコンパイラベンダがC99に対応しないからだな

>>310
= default でデフォルトのムーブコンストラクタを作る事もできないのかな？

コンパイルオプションでバージョン指定できるようにすればええやん
互換性なんて気にすることあらへんのや

そこで#pragmaですよ

>>381 それだと古いライブラリコードを新しいコードから使いたいときに困る。

メジャーどころでC99に非対応なのは MSVC だけかと思ってたけど違うのか

C99って可変長配列が使えるらしいけど、開放のタイミングが謎だよな。
むしろ、可変長配列があったらＣとは呼べないんじゃないか？

C99の可変長配列はalloca()のシンタックスシュガーだよ

C++コンパイラはC++0x対応で精一杯だろうからC99の対応には消極的だろう。
Cコンパイラはコストを掛けてまで対応してもメリットはないだろうし

>>384
それが致命的すぎ

>>385
謎とか、規格にちゃんと書いてあるだろ

>>389
C99ってstructに可変長配列宣言してmallocしても機能するの？

そんなもんは宣言できない

寝言は寝て言え

過去の遺産を使えるけど、でもまともな綺麗な言語仕様を持つ言語、
俺には到底つくれないので、誰か天才さん作ってください！！

可変長配列ってlongjmpですっ飛ばしたら解放されない可能性があるとか読んだ覚えがある

可変長って訳語が悪いなあ。
動的に初期サイズ決定するってだけで、
後からサイズを変えられるわけじゃない。

これが可能になるって事？
int n=10;
int array[n];

微妙な拡張よりも拡張子cppに変えてvector使ったほうがメリットあるだろうね。

>>354
stl とか boost 入ると shared library つかっても object サイズはしゃれにならん
strip 後の size みて, "何, これ?" 状態

おまえら使うのやめろや, template !!!

# でも, 俺は使うけどなw

>>394
確か最初はC++はCへのトランスレータの形で実現されていたけど、例外処理を
取り込んだ時点でどうしてもC++のネイティブコンパイラが必要になったそうだな

longjmp()とsetjmp()だけだと例外処理を実現出来ないんだと

かなーり近いもん書けてるけどねー
むしろキツかったのはマングリングとテンプレート方面だろ

テンプレートは例外処理の後で出て来たしな
もうすっかりネイティブ一色になった後だった

ARMには並べて書いてあるけど

>>399
try/chatch のセマンティクスからだと, longjmp は戻り先が固定なので,
使えないんだよ.
いまでも, 例外はオーバーヘッドでかいけど, コンパイラ/実行コードともに,
使い物にならないくらいのオーバーヘッドがあったらしい.

throw; とか実現できないしな

>>402 throw も setjmp したところの dictionary 作って実現してたっぽいけどな

補足:
C++ よりずっと前に kcl(lisp->c のトランスレータ的実装) が lisp の
例外を実装してたんだから， lisp 例外の劣化コピーの C++ の例外が
実装できないはずはないし, ちゃんと考えて実装すれば
拡張 setjmp/longjmp で何とかなったとは思われる.

>>401
戻り先が固定？？　もしかして jmp_buf をグローバルにしてるのか？？？
throw; が実現できないとか噴飯ものだ

>>405
一つの setjmp に一つの longjmp が対応している
単純に考えれば, longjmp から戻ったときに再度 dispatch
素朴な実装だと try/catch のように積極的に使うと, dispatch table (が|で)あふれる

>>401
例外はオーバーヘッドでかいって、何のこと言ってるの？

例外が実際に投げられない限り実行時間のオーバーヘッドは
ほぼゼロになる実装がすでに主流になってると思うんだけど。

投げた時の話だろ

>>406
ド素人ですが
ごく単純に考えれば、単なるjmp_bufのスタックでよくないですか？
tryブロック毎にpush、ブロック出たらpop
throwはスタックトップにlongjmp
スタックはスレッド毎に必要でしょうけど

それSjLj

>>409
Cならそれでスタック巻き戻せるからいいけど、C++はデストラクタ呼ばなくちゃならないのがめんどくさいところ

>>411
そこは承知していますが、出来る出来ないで言えば、この方針で出来るでしょう

上でlongjmpの飛び先が一つなので出来ないという議論をしている意味が
全く理解できなかったものですから

tryブロックのたびにpush、popは結構なオーバーヘッドになるのです。
実際、昔のC++はそのような方法をとっていたようですが、いまは別の方法のようです。

細かい話なのでいちいち書きませんでしたが、
デストラクタ呼び出しが必要な全ての箇所をtry{}finally{}で仮想的に
囲み、デストラクタ呼び出しコードをfinally{}ブロックに埋め込めば
実現可能と考えます（C++にfinallyはありませんが、通じると思います）

さらに自明と思って書きませんでしたが、例外をハンドルしない場合の
リレーは、次のトップにlongjmpするだけです

素人考えなので素朴極まりないのですが、可能不可能で言えば
実現は十分可能に見えます

push みたいな write サイクルを含む命令を jmp_buf の宣言だけで使うかよ
setjmp は必要な範囲だけに限定できるし、そもそも「オーバーヘッド」って何のことだよ

>>412
longjmpのアドレスの保存先ってstrtokのポインタの保存先と同じで、ライブラリ内に
一つしかないんじゃないの？

>>416
そんなことはありません
jmp_bufについて調べてください

>>416
てめーで少しでいいから使ってみろタコ

いまさらlongjmpなんか使わないでしょう

>>419
使ってからいいな

longjmpと例外の実装方法の違いを論ずるならともかく、なんでそんなにlongjmpに御執心なの？

>>421
自分への質問でしたら、>>398あたりの流れ

> longjmp()とsetjmp()だけだと例外処理を実現出来ないんだと

これについて疑問を持ったから意見を述べたまでで、
別にlongjmp()自体はどうでもいいです

>>414
君の考えで間違いない。

大体今でもフロントエンド形式のコンパイラはあるし。
アセンブリも使っているとはいえ。

今だと表引き法なのかな?

gccでもconfigure時に--enable-sjlj-exceptions付けたら今でもlongjmpじゃね？

C++だとlongjmpは使用禁止だけどな

そりゃ、明示的にユーザーコードでlongjmp使ったら、デストラクタ飛ばしちゃうだろ。
コンパイラが裏で例外の実装としてlongjmpを使う分にはなんの問題もない。

区別出来ないアホはほっとけ

http://codepad.org/PtHh60zX
VC++だとデストラクタが実行されるのに、g++だと飛ばされるんだ。知らんかった。

C++でlongjmp使うなyo

何でそんなこともしらないやつがC++0xスレいるの？
>>398とか。背伸びしすぎw

>>429
WindowsのSEHはスタック上でリンクリストを作ってるから、動的に辿るのも簡単だしね。
g++はデフォルトZCXの上にlongjmpにも切り替え可だから両対応は難しい(んだと思う)。不可能ではないだろうけど。

ああそうか、WindowsはOS自体が構造化例外機構を持ってるんだった。

一概に使うなとか言ってる奴は論外
委細をわかっていて使う使わないを選択する人用の言語だかんな

>>425
今でもlongjmp()なんだ
SjLjはthrowされたらpersonalityとlongjmp()する場所を記録したリストを型判定しながらたどって
何とかとかいう構造体でcatchできる型と判定したらsetjmp()した所に帰るとかだったような
随分前に本で読んだ記憶あるがほとんど覚えてないw

>>435
流石にlongjmpそのものではなくて、unwind.hで定義された関数使うけどな。
その中がlongjmpか同等の何かまでは知らん。
personalityは、ハンドラが受け取る例外の種類を判定するための関数だね。

>>435
> 今でもlongjmp()なんだ

今でもも糞も「SjLj」なんだよ！
使わないならLjじゃねえ！

setjmpとlongjmpの関係をnear/farポインタ的なものだと思ってた時期もありました…

ペアで使うような名前には見えないよねこれら

longjmp を使うのに #include <csetjmp> が必要でもか？

何言ってんだこいつ

わからないならレスしないで下さい
ウザいだけです

>>438は単に、なんでgetjmpじゃないんだと言いたいだけだろう。
あと同一ヘッダーに関係ない関数が収録されてる例なんて山ほどあるので>>439も言いたいことはわかるがやや変。

実際名前の対応は取れてないしな。set_longjmpとexecute_longjmpとかならどうだろう。

>>441
わからないならレスしないで下さい
ウザいだけです

>>442
ラベルと goto が１：ｎの関係なのは考えるまでもないことで
ロクに使いもせずに毛嫌いしたばかりに setjmp と longjmp の関係を誤解した間抜けが
藁にもすがる思いで識別名のせいにしただけだろ

なるほどC++0xの話題ですねw

言語の基本
ここがわかんないまま議論しても砂上の楼閣だ

>>437
言われてみればｗ
本当にすみませんでした

>>444
まあいくら御託を並べても名前がクソってことに変わりはないけどなw

それよりも禿げは･･･

さーって、右辺値参照を勉強するか。




ううーーむ、わからん

いつものように0xと関係ない話題になると伸びが早いな

VC10使ってる人とか少ないのかな？lambdaとか右辺値参照とかかなり有益なものが入ってるのに

まだ仕様変わってるし、あまり触りたくない
VC6の悪夢が・・・

右辺値参照の何が難しいのかわからん。

void f(int &x) { puts("L"); }
void f(int &&x) { puts("R"); }

int main()
{
int a = 1;
func(a); // こうやって呼ぶと"L"
func(1); // こうやって呼ぶと"R"
}

これだけのことではないか。

VCというかWindowsがない
俺なんでこのスレ見てるんだろ

こうじゃないの？

void fanku(int &x){ std::cout << "reference" << std::endl; }
void fanku(int &&x){ std::cout << "uhennti sannsyou" << std::endl; }

int main(){
int a = 1;
fanku(a);
fanku(int(a));
}

どっちもあってる

これに
void fanku(int)が加わればどうなるの？

右辺値参照がわかりにくいのは、Standard のどこを読んだらいいのか
いまいちはっきりしないからだと思うけど
rvalue と rvalue reference が違うことを念頭に置いて
以下の原文を読むとわかる…かもしれない。

3.10-1 lvalue,xvalue,prvalue の図

5-6　名前付き右辺値参照は lvalue になる。
　　　名前なしの(関数の戻り値とかの)右辺値参照は xvalue になる。
　　　関数への右辺値参照は、名前のあるなしにかかわらず lvalue になる。

8.3.2-2 左辺値参照と右辺値参照は違う型だが、
　　　　明示的に注記されない限り両者は意味論的に同じ。

13.3.3.2-3
　　　(暗黙の変換S1とS2がありうるとき、S1のほうが適用される条件)
　　　- S1 と S2 が参照束縛で、
　　　　S1 は rvalue (つまり xvalueかprvalue)を右辺値参照に束縛し、
　　　　S2 は左辺値参照を束縛するとき。
　　　- S1 と S2 が参照束縛で、両者が同じ型を参照していて、
　　　　S1 のほうが const/volatile の修飾が少ないとき。
　　　　(片方が参照で、片方が値のときはあいまい)

ついでに
13.3.1-4 と -5 あたりで
　　struct A { void hage(); void hige()&; void hoge()&&; };
の違いがわかるはず。

いや、この程度のことならいいけど。
ところで、int(a)は型キャストだと思うが、これも右辺値？

constが絡んでくるとどうなの？
参照返しがなされたときは？
一時オブジェクトであってもそのオブジェクトを受けた関数側に
参照引数が使ってある場合、その関数内では左辺値になるよね？

こういうことがゴチャゴチャしていてC++は複雑なんだよ。

static_cast（他）もtypenameのキャストも右辺値を返すよ。

＞ところで、int(a)は型キャストだと思うが、これも右辺値？
キャストは一時オブジェクトを作るので右辺値

＞constが絡んでくるとどうなの？
constの右辺値参照引数は意味がない（壊せない右辺値なんて…）ので考えなくていい
const T& と (non-const)T&& でオーバーロードするのが基本

＞参照返しがなされたときは？
戻り値の事なら戻り値の型どおり
左辺値参照なら左辺値、右辺値参照ならxvalue

＞一時オブジェクトであってもそのオブジェクトを受けた関数側に
＞参照引数が使ってある場合、その関数内では左辺値になるよね？
関数内ならそれも引数の型どおり
左辺値参照なら左辺値、右辺値参照ならxvalue

別にゴチャゴチャしてないと思うが
というか右辺値参照の評価が左辺値だったりした昔に比べればずいぶんスッキリした

>>462

あんたはそう言うけどさ、一般の人間にはついていけんよ。
右辺値、左辺値なんて言葉は昔から使ってあったと言うけど
誤解を招くから使わない方が良いと思う。

(1) どういう場合に無名の一時オブジェクトが生成されるのか？
(2) 無名オブジェクトでも名前つきオブジェクトとして扱われる
ケースがあるが、それはどのようなケースか？

で箇条書きしてくれた方がまだまし。

みたいなもので
そのケースを箇条書きで示してくれた方がまだす。

そして一時オブジェクトであっても関数側の参照引数で受け取られた
ときは名前つきオブジェクトになってしまう
されたときには
で参照引数として

↑ああ、ゴミ消すのを忘れた。

実体として存在するのは、
3.10-1
・lvalue (名前付き変数/&戻り値) と
・xvalue (&&戻り値) と
・prvalue (即値/値で戻ってきた戻り値)

だけで、glvalue とか rvalue とかいうのは
上記3つのうち二つをまとめて呼ぶときの略称みたいなもの。

「左辺値には lvalue と xvalue があって、
　右辺値には xvalue と prvalue がある…??」

のように思ってしまうと、訳が分からなくなる。
そうじゃなくて、無機質に、rvalue は xvalue と prvalue の総称なんだな、と考える。

そして左辺値参照と右辺値参照も、上の用語とは切り離して考える。

「rvalue」という用語が出てきたとき、「右辺値参照」を連想してはいけない。
この二つはカテゴリが違う概念だから。
「rvalue」と言われたら、「xvalue か prvalueだな」と思って読む。

ちなみに、参照に関しては↓のようになっている。
8.5.3-5
　・左辺値参照は lvalue を受け取れる
　・特にconst左辺値参照は、なんでも受け取れる
　・右辺値参照は、xvalueとprvalueを受け取れる。

質問する側の分際で横柄だな
別にいいけど

(2)はxvalueのことだから、右辺値参照型の変数が評価される時だけだな

(1)はめんどくさいな
・組み込みリテラル
・組み込み演算子の結果、ただし以下の左辺値を生ずる物は除く
　・前置++、--
　・単項*
　・[]
　・メンバの参照 . .* -> ->*
　・=および+=の類
・関数（オーバーロード演算子とユーザー定義リテラルを含む）の戻り値、ただし左辺値参照型を返す場合を除く
・キャストおよびコンストラクタ呼び出し、ただし左辺値参照型への変換を除く

きっと何か忘れてる

何を言いたかったかというと、

> (2) 無名オブジェクトでも名前つきオブジェクトとして扱われる
> ケースがあるが、それはどのようなケースか？

こういう疑問が生じるのは多分
「右辺値は無名だけど右辺値参照は名前付きで…???」
みたいに用語の混乱を生じているからであって

「prvalue か xvalue は rvalue reference で受け取ることができて、
rvalue reference で宣言された変数は lvalue だ」

と言えば混乱はない。

＞rvalue reference で宣言された変数は lvalue だ
xvalueじゃないの？

xvalueってstd::moveで生成する以外だとどんなのがあるの？

あ、右辺値参照の引数もか

>>468
5章の第6段落に書いてあるけど、
名前付き&&参照は lvalue。
関数の戻り値とか、名前のない&&参照は xvalue。

だからf(int&& a) の引数 a は lvalue。

そうだったのか
じゃあこれって合法なの？

int &&x = 0;
x = 42;

なんだかなあ

>>472
一時変数が作られてるから合法のようだね。
まあ、右辺値参照と明確に指示したんだからしかたなくね

STLに右辺値参照使うのはいいんだけど、関数の種類が増えて実行ファイルが肥大しない？

おお！何だこの難解なレスの伸びは。。。



みんな静かに見てるんだな、怖ひ

そりゃ主要なコンパイラがじわじわと対応してきているからね

>>474
インライン展開されるし、ムーブのコードのほうが小さいだろう。でなければ右辺値参照は使わない。

>>462
> 関数内ならそれも引数の型どおり
> 左辺値参照なら左辺値、右辺値参照ならxvalue

右辺値参照引数には関数内なら名前がついてるんで、
lvalue になるんじゃないの？
move なりなんなりかまさないと xvalue にはならないと
思うんだけど。

>>478
レスが入り乱れててわかりづらいけど
それはもう訂正済み

ごめん分からなくなってきた
名前のない&&参照って例えばどんなの？

>>480
T&& move()
↑こんなのとか。

static_cast<T&&>(t)
↑こんなのとか。

現状、ムーブコンストラクタって明示的に書かないと駄目なんだっけ？

このスレずっと見てきて、右辺値参照がようやくわかってきた。
みなさん、ありがとう。

特に、>>465 >>467 さんの明確な説明が参考になりました。

右辺値参照やmoveを説明した英文の和訳を読んでも(訳がまずいという
のではなく、オリジナルの英文自体の説明がわかりにくい)、
なかったが、このスレを拾い読みしたら

コンセプトさん復活したの？

>>482
現状Yes

>>484
現状No

じゃあコンセプトさん使えるコンパイラは0xではなく独自の仕様ということか・・・

曲がりなりにもコンセプトさん使えるコンパイラって
今のところConceptGCCしかないだろ
開発中止だけど

ConceptGCCが開発中止となり
もうこの世にまともなConceptを実装したコンパイラはありません。

Conceptさんの復活を祈る。
祈るだけで何が出来るわけではないが。

右辺値参照とコンセプトは車の両輪みたいなもの
片方がないと、大変悲しい

// 次の３行分はよく理解できる
int a1 = 0;
int& a2 = a1;
int&& a3 = 0;

// 次の２行はどうなるんだろう？
int& a4 = a3;
int&& a4 = a2;

// もう訳分からん。。
int& a5 = a4;
int&& a6 = a5;
int& a7 = a6;

rvalue referenceとconceptは、あんまり関係がないように思えるがな。

一体何が分からないのか分からん。

int& a4 = a3; // a3はlvalueなのでOK
int&& a4 = a2; // a2はlvalueなのでエラー

int& a5 = a4; // a4はlvalueなのでOK
int&& a6 = a5; // a5はlvalueなのでエラー
int& a7 = a6; // a6はlvalueなのでエラー

>>490
どこにコンセプトが関係するのさ

>>491
a7はa4と同じだからOKじゃね？

>>493
&を読み間違えた。

必要なのはコンセプトよりも、変な記号を置き換えるわかりやすい予約語だよな……。

>>491
>>492
右辺値参照とコンセプトが C++0x の
２本柱のように自分にとって見えたので

車の両輪は良くない比喩でした。すまん

>>491
エラーになる理由について詳しく教えてください。
N3126 から該当部分を指摘して貰えるとありがたいです。

以前GCCで試したら、エラーにならなかったような記憶が
あるのですが、皆さんの処理系ではどうですか？

Conceptさん・・・。。。

記憶違いだと思うぞ
VC++2010は正しくエラー

ずっと、疑問に思っていたので、２つ質問。
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2027.html
にある２つ目のコード例：
A a;
A&& a_ref2 = a; // an rvalue reference
は、エラーになる旨が書いてないけど、不適切な例？

また、
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm#References%20to%20References
では
the reference collapsing rules are:
* A& & -> A&
* A& && -> A&
* A&& & -> A&
* A&& && -> A&&
とあるが、あらゆる参照の参照がエラーにならないことを前提にしている？

いずれも古い文書だから、現在のドラフトの内容と合わないのかもしれません

古いね
右辺値参照をlvalueで初期化するのが禁止されたのは最近だったと思う

参照の参照のルールは今も生きてる
そのproposalにも書いてるけど、テンプレートで発生する事があるので取り決められた

template<class T> class Foo{ T &&x; };

Foo<int&> foo; //foo.xはint& &&だからint&

>>496
＞エラーになる理由

・5章6段落(p85)　　　(何がxvalueか)
・8.5.3節5段落(p206)　(参照は何を初期化子に取れるか)
を読んで。読むのが面倒だったらスレのちょっと上のほうに説明されてる。

>>499

> A a;
> A&& a_ref2 = a; // an rvalue reference
> は、エラーになる旨が書いてないけど、不適切な例？
これは今はもう不適切。いつから変わったかは知らない。

> the reference collapsing rules are:

は n3126 では 8.3.2節6段落に同じことが書かれてるから、
今もルールは変わってない模様。

> あらゆる参照の参照がエラーにならないことを

参照の参照はそもそも、あってはいけない(8.3.2節5段落)と書かれてる。
あくまでただの collapsing rule。

Win32API質問箱からきました。
C++0xでは、basic_string のバッファの連続性が保証されるようになったわけですが、
現実問題として、わざわざ不連続バッファを使うような実装が存在するのでしょうか。

>>502
その質問だと、存在しないことの証明はできない、としか言えないね。
ほんとうに聞きたいことはそんなことじゃないんだろうけど。

vectorよりdequeのが性能良かったりするし

dataとc_strが定数時間で行われる必要があるので
非連続な実装って不可能じゃね

>>505 complexity の要件が追加されるのも C++0x から。

>>502
文字列を+=するときに、バッファーを取り直して伸張するのではなく、新たにバッファを追加して複数のバッファーを使うのは
ありそうだけど、[ ]の効率を考えたら取り直すほうを選択するだろう。

初めて取り出すまでは不連続にしたほうが効率的だよね

確かにそうなんだけど、ここ最近、マルチスレッド化でそうとは限らなくなったね。
constメンバー関数で参照しようとしたときにでも文字列オブジェクトの内部が変化してしてしまう。
内部的にこっそり直してもいいんだけど、マルチスレッド下では再入の保護のためにmutexが必要になる。
過去の文字列クラスは、参照カウンタでバッファーを共有する実装もあったけど、マルチスレッド化で共有での実装も見かけなくなってきたね。

basic_stringでないなら、不連続な実装としてropeがある

>>500
>>501

よくわかりました。ありがとうございます

>>502
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530

pod class Hoge
{
public:
int x;
// NoPod nopod; error
};
void func(pod Hoge & hoge);
そろそろこの指定子が欲しい

lvalue、 prvalue、 xvalue のことや右辺値参照について、このスレの
おかげである程度理解できましたが、まだ完全にわかっていません。

うまく言えないのですが、

(1) std::moveは、右辺値参照で受け取ることができるようにlvalueや
prvalueをxvalueに型変換するだけ。

(2) オブジェクト a と b が持っている(ポインタa.pとb.pで管理して
いる) 動的メモリの交換をポインタのswap(a.p, b.p)の形で行う、
と言うのがmove semantics。

(3) move semanticsは、コピーコンストラクタと代入演算子を右辺値参照
でオーバーロードした、次の関数をユーザ(あるいはライブラリ)が定義する
ことによって実現する。

X(X&& x); // moveコンストラクタ
X& X::operator=(X&& x); // move semanticsによる代入

これらが用意されてなければ、従来のコピーコンストラクタと代入演算子

X(const X& x);
X& X::operator=(const X& x);

が呼ばれてしまう。の理解でいいでしょうか？

>>272
>つうか、おそらく単なる参照渡し。
>ムーブ後の抜け殻に触った結果はどうせ未定義なんだから、仕様は満たしてるよね。

抜け殻のオブジェクトでも消滅するときはデストラクタが呼ばれ、デストラクタ内
では delete p; みたいなものがあると思うのですが。

>>459
>関数への右辺値参照は、名前のあるなしにかかわらず lvalue になる。
｢関数への右辺値参照｣ の意味を解説していただけるとありがたいです。

>struct A { void hage(); void hige()&; void hoge()&&; };
hige()&; hoge()&& ってどういう意味でしょうか？

>>513
static_assert(std::is_pod<Hoge>::value);

>>515
> ｢関数への右辺値参照｣ の意味
#include <cstdio>
int hage(){ return 1; }
void test(int (& )()) { std::puts("lvalue!"); }
void test(int (&&)()) { std::puts("xvalue!"); }
int main(){ test(static_cast<int (&&)()>(hage)); }

↑を実行すると "lvalue!" と表示される。
だから
auto xval() -> int(&&)() { return static_cast<int (&&)()>(hage); }
は戻り値の型に return がバインドできなくてエラー。

何のために存在するのか不明…。誰か教えて。

> struct A { void hage(); void hige()&; void hoge()&&; };
のメンバ関数は、内部的には
　void hage(A& this); void hige(A& this); void hoge(A&& this);
のように扱われるんだけど、このうち禿だけは特別扱いで、
　A().hage(); // 引数 A& this に prvalue をバインドしてる
みたいな呼び出しが可能。ヒゲは禿に似てるけど、そういう特別扱いされない。

>>517
関数型の xvalue を言語要素として排除するためのルールじゃないかな？
これで少しは考えることが減るのかも。

>>515前半
class ptr {
  int *p;
public:
  ptr() : p(new int) {}
  ptr(ptr const& y) : p(new int(*y.p)) {}
  ptr& operator =(ptr const& y) {ptr(y).swap(*this); return *this;}
  ~ptr() {delete p;}
  void swap(ptr& y) {std::swap(p, y.p);}
};
こんなよくありそうなクラスにムーブ構築・代入を定義する場合、
パッと考えつくだけでも2とおりある（ここでは代入で書いたけど、コンストラクタでも同じ）。
ptr& operator =(ptr&& y) {
  swap(y);
  return *this;
}
ptr& operator =(ptr&& y) {
  delete p;
  p = y.p;
  y.p = nullptr;
  return *this;
}
ムーブした後、yがどうなっているか違うけど、どっちでもムーブとしての挙動は行われるはず。
もちろん、yはデストラクタが呼ばれても問題ないのも同じ。

こういう話でいいのかな。

>>519

x=std::move(y); の代入演算子の定義で

(1) x.pとy.p間でswapを行う。
(2) delete x.p; x.p=y.p; y.p=nullptrを行う。

のいずれかの処理が実行されているのなら、デストラクタが呼ばれた
場合も納得できます。


しかし、>>272 に対する

>>273 (272ではなくて273でした)
>つうか、おそらく単なる参照渡し。

>>275
>中身がただの関数ポインタになってて、ポインタのムーブはただのコピーが最善手

のレスを読んで混乱しました。まさか、x.p = y.p 相当の処理だけが実行されている
んでは？と思ってしまいました(そんなわけないか！)。

>>272の質問のきっかけになった >>253 も単なる関数ポインタのコピーであって、
オブジェクトのムーブではないのではないか？ という気がします。

ムーブコンストラクタが呼び出されるって事とムーブコンストラクタの実装が元を破壊しない実装ってのは別々の話でしょ

export キーワードの新しい使い道を考えてみた：
以下のように、スコープを脱出しても有効になるようにできる。
export--extern でやりとりする。

　{
　　export int i = 0;
　　export typedef int INT;
　}

　using extern int i;
　using extern typename INT;

　INT n = 0;
　++i;
　assert(i == 1);

たとえば、
　try {
　　　int i = 0;
　　　export int j = 42;
　　　using export INT = int; // export typedef int INT;
　　　std::cout << i << ' ' << j << '\n'; // 0 42
　　　throw "Foo"
　} catch (...) {
　　　int i = 1;
　　　using extern int j;
　　　using extern typename INT;

　　std::cout << i << ' ' << j << '\n'; // 1 42
　　throw INT();
　}
みたいに使えたら便利だなあ。以上、妄想でした。

デストラクタいつ呼ばれんだよ。

スコープ抜けるところでコピーされて、元のはデストラクトでは。

スコープの外で変数宣言したほうがわかりやすいと思うけどな。

初期化される前に例外投げられた場合の仕様が必要になる事は間違いない
フラグ自分で立てて判断、ってんじゃ面倒くさいからな

まあ try-catch 時に try 内の変数を使いたい場合はよくあるので欲しい所だが、
export やら extern やら無くてもそのままアクセスできたのでも良いと思う

>>522
try export E {
　　　int i = 0;
　　　int j = 42;
　　　using INT = int; // typedef int INT;
　　　std::cout << i << ' ' << j << '\n'; // 0 42
　　　throw "Foo"
　} catch (...) {
　　int i = 1;
　　std::cout << i << ' ' << E::j << '\n'; // 1 42
　　throw E::INT();
　}
とした方が面倒くさくなくていい

簡単な内容のメソッドが多いため、クラス直下のメソッドを減らすために
使用範囲の限られるメソッドをメソッド内に格納したところ、
次のようになってしまいました
class hoge{
/*...*/
　void fuga{
　　auto piyo=[this](...){
　　　auto piyopiyo[this](...){　//VC++ではエラー
　　　　/*...*/
　　　}
　　　/*...*/
　　}
　}
}
g++ 4.5.1ではコンパイルが通るのですが、VC++2010ではエラーが出ます
thisポインタを二重にキャプチャするのは規約違反なんでしょうか

class typedef int Hoge;

でstrong typedefとかどうよ

>>528
5.1.2-12
　変数が「キャプチャされる」とは、明示的もしくは暗黙的にキャプチャされることだ。
　(中略)
　もし this がラムダ式にキャプチャされるなら、
　そのラムダ式を囲んでいる一番内側の関数は、非静的メンバ関数でないとだめ。

って書いてある。

同じ個所に、ラムダの中のラムダを [this] じゃなくて [&] にすることで
this をもう一度キャプチャさせる例が載っていて、
実際 VC でもそれはできるので

『外側のラムダ式を「一番内側の関数」だと思って
　それが非静的メンバ関数じゃないからエラー』
というわけではなさそう。

「キャプチャされる」ことを「キャプチャリストに現れる」ことだと誤読すれば
VC の挙動も説明できるけど、多分 g++ が正しい。

2つ目のthisがpiyoを指してると認識してんだろうなあVC++は

なるほどラムダオブジェクトを指してると思ってる訳か・・・

auto s=[](int x){return x*2.0;};
typedef decltype(s) m;
これを、VC10で１行にまとめて下のようにすると、error C3477: ラムダは評価されていないコンテキストでは使用できませんエラーが出ます
typedef decltype([](int x){return x*2.0;}) mm;
autoの関数定義に使いたいんですけど、１行にまとめる方法はないですか？

現行仕様のでもいいから完全に準拠したC++コードをMVC++に変換するコンパイラがあってもいいはずだ

ラムダのtypedefとか基本的に無茶だろ
そういう風に使うもんじゃない

std::function使え

template <class X> X identify(X);
typedef decltype(identify([](){}) type;

試したことはない

decltype とか sizeof とかにラムダ式入れちゃいけないきまりになってる

>>535-538 ありがとうです。
>>537の方法で通りましたです。この抜け穴で何とかなりそうです

>>539
リビルドしたら通らなくなった？？？なぜに？

もし通ることかあるとすれば、そのほうが間違いっぽいんだけど

内部的にはラムダ式はそれぞれ固有の型として処理されるから、
＞typedef decltype([](int x){return x*2.0;}) mm;
これが仮に通ったとしても、mm型は何にも使えないぞ
だからラムダ式じゃなくstd::functionを使うのが正しい
typedef std::function<int(int)> mm;
ってしろこれなら
＞mm a=[](int x){return x*2.0;};
って宣言・代入できる

functionはboostやtr1でおなじみだと思いきや
C++系のスレ見ててもあまり使われてない感じがする
結構便利なのに

パッと見中で何やってんのか想像できないライブラリってなんか抵抗あるんだよね

ラムダ式を使う場合、大抵はラムダ式を直接渡せば事足りるからな。

functionとlambdaで事実上関数内関数が作れるのはよい

>>544
単に共通の非テンプレートなベースクラスを継承したテンプレートなクラスを作ってるだけ。
まあ、vtable自前とか変態的な実装もあるけど。

ラムダは夢が広がるね。
BOOST_SCOPE_EXITの見た目すっきりの代替品とかいろいろ出てきてる。

関数オブジェクトの戻り型をhoge::result_typeで貰ってるんだけど、lamdaはresult_typeがないから面倒だな。

>>546
見やすくなるよな

>>541
簡易ビルドが効いてて、変更が反映されてなくて通ってたっぽい。リビルドでそれがリセットされた。

ムーブさんの問題がついにコピーさんに飛び火してしまった
一体どうなるのか

いったん0xはなかった事にするのがいいと思う

0x以前を無かったことにしろ

C++を放り投げてネイティブC#であらゆる問題が解決するんだよね

>>552
規格策定がさらに1〜2年伸びるわけですね、わかります

絵に描いたような矛と盾。

ちょっとムーブさんとコピーさんの関係まとめてよ

ムーブさんのせいで家庭崩壊の危機に陥って、ムーブさんの立ち入り禁止を命ずる裁判所命令で
解決したかに見えたが、土壇場で旦那が実はコピーさんが家のことを勝手にあれこれやるのも快く思ってなかったとか
言い出したせいで、示談で落ち着くはずが混迷化(いまここ)

ムーブさんの行動が上級生の邪魔になるというのでムーブさんの権限を一部剥奪することになったが、
校長先生が「上級生のコピー君も今まで同じことをしておった喃」とか言い出して、コピーさんの
権限まで制限されることになってしまった。

よっしゃー。優等生がいなくなって学級世紀末覇者も時間の問題。

暗黙のコピーさんと暗黙の方変換は昔から挙動が怪しかったが、周りがあわせることで事なきを得た。
ムーブさんもそうなってほしい。

暗黙のコピーはCの構造体との互換性のため必須だったんじゃ

互換性は関係ないだろ。
これはユーザー定義のデストラクターが定義されている場合、
暗黙のコピーコンストラクターの生成されないべきという話なんだから。

autoさん「互換性なんて投げ捨てろよｗｗｗ」

auto使っても型違い警告出るとこあるよな

仮にいちゃもん付けられる前までのコピーについて>>1-のテンプレで書くとしたらどんなのになる？

今までの暗黙のコピーは、
今まさにうんこしているやつがいるのに、便器の掃除を始めるようなものかな。

いや
下手に便所を奪ったら先に用たしてた奴がそこらじゅうに糞便まき散らす恐れがあるから
後発で便意をもよおした奴は隣に便所作ってウンコするみたいな様子

この業界ってそのまま説明すればいいのにわざわざ分かりにくい例えしてくるオナニスト大杉やでしかし

もどかしさと被害の表現がえらく的を得てるようだが

的は射るものです

的を射るのはいいけど得たらダメとかおさわり禁止みたいなこというなよ

>>564
なるほどそういう事か
まあ = default あるし、別にいいんじゃない、と思うね
boost::noncopyable とか不要になるし、
そもそもコピー可能かどうかちゃんと考えてないクラスは
コピー禁止すべきだと思うし

不要にはならないだろ
deprecatedなだけで無くなりはしないんだから自衛は必要

古いコードで警告が数百数千と出るようになるだけ。

>>572
的を得るで合ってる

まさに2ch的日常

>>572
的を射るで会ってる

>>577
wwww

的を得るでぐぐれ

賞を射止めるとかあるように
的を得るでもいいのではないだろうか、射的を制する的な意味合いで

プログラマならあいまいな表現は使うな
以上

C++0x風にいうと
「的を得る」は独自拡張であり
正式に導入されるまでは
コンパイルエラー。

的を得るが正しいとか頑張って涙目で主張してもコンパイルエラーは
許してくれないことは思い知っているはず、

例えとか要らないからボケカスアホンダラ

「的を得る」あたりだと規格には入っていないが主要なコンパイラはデフォルトでサポートしている状態
原理主義者が必死にコンパイラオプション指定して「的を得る」はコンパイルエラーにしなければならない
とか喚いている感じ

のように変な例えから変な例えが派生して話がわけわかめになるわけだな。

的を得る/的を失する は別に誤用じゃないんだけどな

自然言語スレになったん？

言語マニアの多いから

日本語0x

自然言語に例えると英語と中国が混ざったようなスレだな

J++とな

>>591
C++/CLIの悪口はやめて！

>>593
だってそれC++じゃないじゃん

BOOST mplやlamadaやspiritはC++に見えないけど確実にC++だしな

あれはC++ではなくてboostという名のなにかだよ

boostの悪口言うなよ
C++0xに標準として取り入れられるライブラリがいくつかあるんだから

ここはObjective-C++の出番か

もしもObjective-C++/CLIが出たら…

Objective-C++0x/CLIを待つしか無いな

vector<int> v;
v::size_type s;

みたいに出来れば素敵なのに
次の規格には入れてくれよな校長

decltype使えばいいんじゃね？

decltypeって長々とうつのめんどくさいじゃん
typedefの手間もいらないしこれ出来ればかなり便利だと思うんだよね

カスだな

>>528
https://connect.microsoft.com/VisualStudioJapan/feedback/details/621572/
＞ 修正しない
＞Unfortunately we will not have time to fix this issue for the next release of Visual Studio.

(ノ∀`)タハー

まあどうせ未完成なんだし
そこだけ凝っても仕方ないわな

>>601
v.iterator begin(){return v.begin();}
て書くのか？混乱するだろう。同じ目的に複数の記述方法があるとあいまいになるだろ。
>>603
多少のタイプ量を減らすよりtypedefして型を明確にしたほうが読みやすいぜ。

大抵はautoで大丈夫じゃね
メンバ変数とかは無理だが

>>607
v::iterator it = v.begin(), end = v.end();
って書くんだよ

int main(){[](){}();}

Perl以下の糞文法でゲソ

Perlには敵わないんでなイカ？

ラムダ式っておでんっぽい

int main(){<|()[]-;}

int main(){[=]()->O{}();}

int main(){くコ:彡;}

auto main() -> int { auto final = [](){}() ; }

実行したらダメだろ
autoがvoidに推測される

結局OpenCVとかC++で書かれたものは、そのまま使えるの？

ほぼ使えるよ

decltypeすごく便利
ラムダ式もようやく慣れて来た
早く規格が固まらないかねえ

先月分のペーパーが公開されたか。

noexceptたんやっぱうぜーって言われてる?

contextual keywordってマジでやるのか
勘弁して

attribute何とかの嵐よりはマシ

本物の予約語にして「identifierにも使えるけどdeprecatedです」じゃダメなの？

暗黙デフォルトムーブさんはマジで退学。
defaulted定義のときだけ召喚されるんだね。

>>625
もう予約語追加しないって言っちゃったんじゃなかったっけ?FCDで。

わざわざstd::moveで食わせないといけなくなったのか？

退学は妥当な処置だな

C++0x好きだわー
こうやって何回も議論を重ねると論理の穴を塞いだ規格が出来上がる
一人で作った言語とは大違い

LLバトロイスレ逝け

>>629
その代わり覚えなければならない事が山ほど増えるぞ
初心者向け言語ではますますなくなる

範囲ベースの for ループはどうやって
範囲の長さがわかるんですか？

stdを特別にassociated namespaceに付け加えたADLで、range式を引数に取るbeginとendを探して呼び出す。
配列の場合は、特別に何も#includeしなくても使える。
配列以外の場合は、<iterator>もしくは関連するヘッダーを#includeしなければならない。
std名前空間には、あらかじめbeginとendが定義されていて、これはクラスのメンバー関数、beginとendを呼び出す。

つまり、自作クラスをrange-base forに対応させるためには、
STLのコンテナのようにイテレーターを返すbegin、endという名前のメンバー関数を実装するか。
そのクラスを引数として、イテレーターを返す、begin、endという名前の関数を、
ADLで呼び出せるように実装しておけばいい。

>>633
フリー関数とメンバ関数と、両方固められたらもう予約語級の名前空間汚染度だなぁ。
ってそんな議論もきっと通った上での話しなんだろうなぁ。でもでも、もしかしたら
Concept が抜けたことで、ふさいでたつもりの穴がうっかり空いてたりしそうで怖いなぁ。

暗黙デフォルトコピーも退学にしてくれ

>>635
それはこまるなー。
プロトタイプ作ってるときは効率なんて考えないから、そういう便利機能はありがたい。
関数型ライクというかなんというか。

退学じゃないけどD組行きだろ

n3225だと、暗黙デフォルトムーブさんは退学してなくね？
一部D組に堕ちた暗黙デフォルトコピーと、同じくらいの穏便な処置で済んでるよ。

デフォルトコピーとかユーザーによって反応がまちまちの機能は
コンパイルオプションで決めれるように仕様に明記すれば良いのに

わたし、n3225で退学だって・・・ショック。
何よ、そりゃusing宣言ちゃんの方がすこし可愛いかもしれないけどさ。
八方美人っていうの？　わたしからすれば尻軽だけどぉ。

>>639
人の書いたコードと混ぜられなくなるだろ。
言語によってはソースファイル毎に指定できたりもするが、C++は#includeというものがあるし。

コンパイルオプションでそんな動作変わるとかPHPじゃないんだから・・・

キモイ
private "C++0x" extern "C" {
}
private "C99" {
}

>>642
#includeの無い言語ではそんな珍しいものでもないぜ。
FreePascalの、GNU Pascal互換モードとDelphi互換モードなんか、見た目にも別の言語だw

C99の#pragma STDCでも使って切り替えられればいいのに

もう2010年も終わろうとしてるのにまだ0xと言い張るか

2015年が終わるまでは

C++0xの0xは20xy年のまんなか2桁をとったんだよ!
よしこれでこれで2100年まで延々と規格策定を続けられる

ならコンセプトさん復活させようぜ！

もう秒単位で変わる規格にしようぜ！

もう新規さんは出てこないだろうから別に規格とかどーでもいいんじゃないかな
MSとGNU間で摺合の機会を持てば十分でしょ

林檎の人たちを忘れてますよ

彼らは摺り合わせとか応じないだろうなぁ

Symantec C++やWatcom C++がやる気なくしてBorland C++が変な方向へ疾走しだした頃から規格なんてベンダへ押し付ける努力目標になってるからなー

HTML5のように規格厨が蔓延るよりなんぼかマシだわ。

でも規格がないとD言語になっちゃうからな

有能なコンパイラ屋が相次いで離反する「信者を持てない言語」だな

規格はMSとGNUで決めればOK
規格制定委員会なんてイラン

C++0xがこのざまなのは、全て禿げが悪いんだよね

>>652
林檎はgcc使ってるだけじゃん。

>>654
あれほど実装にすりよってもまだそんなこと言われるの
XHTML2厨が聞いたら卒倒しそうだな

C++規格がHTML5規格にように書かれるならば、
すべての実装はMSVC拡張とgcc拡張に加えて、POSIXとWin32 APIとx86インラインアセンブラをサポートしなければならなくなるな。

autoとかめんどくさいこと言わずに最初に代入か初期化された型になるで良いじゃん
そんで初期化されるまでは不定でアクセスするとコンパイルエラーになる

変数は使うときに宣言すればいいだろ。
まさかC言語厨か？
あれだろ、お前は関数の冒頭に変数を全部宣言しておく口だろ。

ちげーよ。なんでそうなるんだよ。ふんころがしは黙ってろ

>>662
うーん良く分からん
最初の代入で型を決めるという実装だと
unsigned x = 0;
void hoge(){
x = 0;
}
このときにローカル変数のxを宣言して初期化なのか、
グローバル変数のxに代入なのか区別つかん気がする。

これを解決するためには結局autoに近いものが必要だよね(javascriptのvarとか)

x( 100 ) ; // グローバルのint xを100で初期化
void hoge()
{
x = 200; // グローバルのxに200を代入
x(300); // ローカルのint xを300で初期化
x = 400; // ローカルのxに400を代入
y = 500; // 型不明でエラー
for( i(v.begin()) , e(v.end()); i!=e; ++i){} // ok
}

こんな感じならautoはいらないかもね

extern x = 0;
x = 1;
void hoge(){
　x = 2;
　assert(extern x == 0 && ::x == 1 && x == 2);
}

なんか B への原点回帰みたいだな

後のStroustrupの語るところによれば、「BCPLに比べれば、C言語は超高級な言語に見えた」ということである。

>>666
なにこれきめぇ

>>666
struct foo{
foo(int);
void operator()(int);
}

とかあるとややこしいことになるな

初期化の代入は := にするとか

それなんてIo

:=とか[a,b)とか使えたらさぞや気持ち良いだろうな

:=はともかく[a,b)はパーサが死にそうw

>>662
ローカル変数の事だと思うけど、
適当な文をコメントアウトしただけで挙動が変わりそうで怖いし、
結局キャストが必要で宣言したんでいいじゃんなケースも多いと思うし、
配列どうすんのって感じだし、
アドレスとる分にはコンパイルエラーになるケースが皆無だし、
C++として全然駄目だと思うぞ

forの後限定、整数限定とかなら実装も簡単だし、実用性も高い

既存の変数を使った場合、同名の新しい変数が使われるのか、
それとも新規の変数が使われるのか分からない

同じ事言ってしまったw

既存の変数を使った場合、同名の新しい変数が使われるのか、
それとも既存の変数が使われるのか分からない

だ

Rubyスレかと思った

a = [1,2,3]
a.each{|a| p a}

1
2
3

こういうことか

>>681
古いバージョンではその後の a の値が 3 になるが、
新しいバージョンでは [1,2,3] のままになる。

クロージャのある言語で変数宣言的な構文がないと
こういう問題がある。

C++ は宣言もあるし、lambda にキャプチャリストもあるんで
関係ないけど。

ああ、さらにそのあとp aしないと意味なかったか

やはり宣言ないとスコープ分かりにくいな

制御ブロック専用のauto予約語を作ればいいんだな
afor,awhile,doa

do (int n) {
　n = ...;
} while (n == m);

みたいなことはやりたいと思う

do {
　int n;
　n = ...;
} while (n == m);

と何が違うんだ？

whileはブロックの外だからnにアクセスできない

http://codepad.org/EpMG6m1l

きもいコードだが

{
　　int n;
　　do {
　　　n = ...;
　　} while (n == m);
}
で良いじゃないか

>>687
アクセスできる仕様になれば良いんだな

>>688
ifを使うとはwww

>>689
ブロックがウザい

do { int n; do{
〜
} while(0); }while(n==m);

いや、逆だろ

#define DO(decl) for(bool DO_ = true; DO_; ) for(decl; DO_; DO_ = false) do

DO(int n) {
　n = ...;
} while (n == m);

さすがプリプロセッサさんや

while条件がスコープの中なら万事解決なのに
なんでdoの時は外されるの？

0xではスコープ変わったりしてないの？

N3225では変わってない

よく読むと条件部って「宣言された名前が内側のスコープに入る」(3.3.3-4)だけで
条件部自体がスコープに入ってるわけではないのね
do-whileの条件で宣言なんかしても意味ないから（そもそも出来ないけど）、スコープに入らないわけか
納得した

while( int i = 1 )
{
i = 0 ;
}

宣言は出来る
でも永久ループする

いや、それは当然できるよ
do{
...
}while(int i=0);

が出来ないって事
普通のwhileの条件はconditionで、do-whileの条件はexpressionだからね

まあそれ以降使える所がないしな

do statement while(expression); だっけ？
{ } は必須じゃなくて do-while とは無関係だから
スコープを広げるという仕様を加えにくいんだろうね

その辺はifやforも一緒だから問題ない

do-whileの場合はstatementの中の名前を条件部に導入するっていう
他と逆の話になるのが問題なんだろう

全然違う
if, for, while の場合はスコープを狭めるだけなのに対して、
do-while の場合はブロックの外にスコープを広げる仕様になるわけで

だったらこれでいいんでない？

do
　declaration-list;
　statement;
while (expression);

do int i; { i = ... } while (i == 0);

これで良いだろ
do:
......
if( xxx ) goto do;

予約語ってラベルに出来たっけ？

できるわけないだろ。
プリプロセッサーのマクロの識別子にも使えないから注意しろよ。
今回、newキーワードの再利用で、
#define new(x) ....
とかやってるマクロがぶっ壊れるからな。
自業自得だ。

new(...) という形式の構文が追加されたの?

追加も何もC++03でもplacement newがありますが

そうかnewマクロが軒並み壊れるのか
MSVCには絶対採用されない機能になったな

そもそも、C++98の時点で、使えないとされているからな。
newキーワードの再利用の時の議論に、この問題があがったらしいけれど、
そもそもplacement newすらぶっ壊れるじゃん。自業自得だと論破された。

そんな事言われてもMFC使っちゃってるプログラムは現にごまんとあるんだよ
どうせcontextual keyword作るならhidingでいいじゃんかよ
勘弁してくれ

>>709
あいや、それは知ってるんだわ。
707で「今回newの再利用で」とあるので、新規に()が続く形式も追加されたのか
と思っただけ。
メンバー関数の上書き指定の文脈依存語では new() の形は挙がってなかった
と思ったんで。

プリプロセッサーの識別子に、
キーワードと新しく追加される文脈依存キーワードを使ってはならないというのは、
ライブラリ実装者からしても当然のルールだよ。
そんなことを許してしまうと、コンパイラ側で、すべてのキーワードに対して、
アンダースコアで始まる同等な意味を持つ独自キーワードでも提供しない限り、
安全にライブラリを実装することができなくなってしまう。

ライブラリ自ら、そんなアホなことやってるのは、自分で首を絞めているようなもんだ。

俺はMFC使わないしどうでもいいんだが
予約語を前処理で置換する事の道義的な是非は別として
new() 形式の構文が追加されても、それらについて明示的に「手で」マクロ
展開を抑制することは出来るし、特別 new() マクロだけ使えなくなるという
ことは無さそうに見える。

>>714
あなたの言ってる事は全く正論だし完全に正しいと思うが
そんなアホな事をやってるライブラリが実際に存在して、
しかもそれは世界一普及したOSの重要なライブラリであって、極めて広く使われているという現実を
無視してはいけないと思うんだ

VC6時代は
#define for if(0); else for
とか普通にやってたよね
forが腐ってる時点で規格云々話す意味ないけど

それもATLのヘッダが腐ってたせいでなかなか修正できなかったんだよな

結局、諸悪の根源はMSだな。

必要悪だからどうにも出来ないけどな。

for i in x, y, z do …
的なこと0xだと出来るんだっけか？

range-based forですね

>>665
そういえばboost.fusionが後から型を変更できるのだろうか

MFCは糞

マクドナルドフライドチキン？

麻雀格闘倶楽部。

マイケルファックチャイルド

で、右辺値参照はその後どうなった？

どうにもならなかった

暗黙のムーブコンストラクタが
暗黙のコピーコンストラクタを巻き込んで
弄ばれてるんじゃなかったっけ

何で今頃になってそんな話してるんだよ

コピコンを使用禁止にしておいて
ムブコンだけでいいような設計がベストだよ。

言語仕様をこんなに複雑にしちゃって大規模アプリで運用できるのかなぁ

>>733
ライブラリを使う側の人には、大して複雑になってないと思うけど。
キモい見た目のアレはコーディング規約とかでゴニョゴニョすればいいし。

> キモい見た目のアレはコーディング規約とかでゴニョゴニョすればいいし。
lambda なんてものは、あれば使いたくなるのが人情ってもんだろ？
コーディング規約でゴニョゴニョしてもキモイ見た目は変わらない

見慣れないものはキモイ、
そうやって差別や偏見がはじまっていくのだろうな・・・

見た目なんて気にしてたら何時まで経ってもコーディングできないだろ

lambdaはキモいって事になってんの？
結構使い勝手良いし、見た目もわかりやすいと思うけど

ランバダ

キモくないと思えるのは幸せだね・・・

http://www.news.janjan.jp/government/0702/0702090742/1.php

λはいつの間にか使ってるものだな
自然に使ってしまう

>>738
他の言語のlambdaを使い熟れてるとキモサ爆発だわな
まぁ、あれば使うけど

このまえpythonのスレをちらっとみたら、他の言語は
サブルーチンのネストができないから、しかたなくあんなもん(ラムダ)を
導入してるんだ。
やっぱpythonはスジがいいね!

ってことで意見がまとまってた。

（ ﾟдﾟ）

pythonはラムダっぽいことはできないのか

ラムダをつかっていると無性にランバダを踊りたくなるな。

>>746
lambdaそのものは存在するがローカル関数の方が好まれるのであまり使われない。

boost.lambdaとC++0xのlambdaって同じ？

continuationとdelay forceは導入されないの？

>>749
かなり違う
C++0xの方が後発だけあって変数のキャプチャが出来たり変数を定義する事が出来たり
参照で渡せたりまあいろいろと便利かな

yieldなんて予約語は死んでも使えないC++が
どんな奇妙な構文を導入してくるか興味ある

>>749
boost.lambdaはpolymorphicだけどC++0xのlambdaは違う

互換性を維持しながら後発言語の機能を全部追加するなんて無茶だと思うの

>>754
C++ がアイデア借りまくってる LISP も SmallTalk も ML も C++ より先発なんだが

>>752
yieldはしんでも採用して欲しくないな。

>>738
引数がlamdaを返すlambdaな関数のprototypeを定義してみそ

C++0xになってもboost.lambdaは使えるってことでＯＫ？

おｋ
別に競合するもんじゃねーしな

boostは標準ライブラリーではないよ。

なにを突然言い出してんだ

我々はアマチュアではないよ。

どこの誤爆だ？

>>758
boost.lambdaが使えなくなっていいぐらい互換性を壊して良いなら
C++0xはもっと早く決まっているだろう。

さて、仕様が決まらないまままた年が明けた訳だが

今年も仕様が決まらないまま年末を迎えるんだろうな

仕様なんてそこらへんのルンペンに押し付ければいいんだ

shared_ptrとかコンパイラ変えなくても実装できるものは先に規格化するとか段階的にできないの？

shared_ptrマジ必要。

>>768 そこで Boost ですよ。

C++が悠長に仕様策定している間に他の言語のコード資産はどんどん増えていく
プログラミング言語は道具に過ぎないのに手段と目的が逆になってきてるよな

相互に互換性のない俺スマポが世界中で生まれては消えるんだよね。

だがスマポの設計は一度はやっておくといい経験にはなるのではあるが・・・・

大量のオブジェクトを一斉削除したときスマートポインタの限界を思い知った

ガベコレでもきっと限界を思い知るよ

ガーベジコレクションで困るのって組込くらいじゃね？

ガベージコレクションなんかが使い物になるのってPCくらいじゃね？

ガベコレはゲームで困る

普通のアプリでもたまに困る

>768
TR1 があるじゃん。

大量のオブジェクトを一斉削除したらスマートポインタじゃなくても結局同じ事になるような･･･？

ガベコレは他のスレッドの邪魔をしないように動くのが普通

そうあってほしいがそれほど普通でもない
理想と現実は区別しなければならん

みんなそんなにクリティカルな仕事してるの？

エロいこと言うな

クリティカルだからC/C++なんだよ
効率どうでもいいならもっと便利な言語がいっぱいあるし

クリティカルな仕事って、原子炉の掃除とか、骨折バイトとかのことだろ？

>>780 処理系依存だ
>>784 ほかの言語がマシン語はいてくれたらC++は要らない子の筆頭だ
>>785 ハードリアルタイムが必要な処理系あるんだな
臨界値越えなきゃいいって極めておおらかな世界 < 原子炉の掃除
# で、人間系がこけると最悪なことになる

「ハードリアルタイムが必要な処理系」での仕事を「クリティカルな仕事」とは言わないと暗に言ってるのでは。

骨折バイトって骨のくっつき方を調べるためにわざと骨折するみたいなバイト?
痛そう

そんな都市伝説信じてるやついんの？

ミッションクリティカルと混同してたわすまん

そういう仕事だと例外処理も嫌がられるってほんと？

まあ、原子炉の掃除はルーチンワークで済ませたいだろ

ミッションクリティカルな基幹系では例外処理使いまくり。

いいかげんに、C++の機能はそのままに、フロントエンドの文法だけ変更した言語が欲しい。
宣言文とかテンプレートとかの曖昧になる可能性のある文法をどうにかして欲しい。

>>794
【超高速】C/C++に代わる低級言語を開発したい 7
http://hibari.2ch.net/test/read.cgi/tech/1275235018/

>>791
ハードリアルタイムに関してはそう
つか、例外処理悪阻杉だろ > C++

そんなジャパニーズのためにEmbedded C++があります。

>>796
そもそも例外処理って使ってる？

>>798 C++の例外を、ハードリアルタイムな組み込みで、使うわけないじゃん

嫌がれる以前に使わないだろ？という話じゃないの

ハードとかリアルとかってレーザーラモンのことだろ

ソフトだけで保証できるタイミングの範囲は笑っちゃうくらいどんくさい
たとえ全部アセンブラでも

その心は

>>802 「それをいっちゃあ、おしめぇよ」な、発言だろwWW

>>779
ガベコレの実装次第。
たとえばコピーGCなら、一回のGCにかかる時間は生きているオブジェクト数に比例するから
一度に大量のオブジェクトが死のうが関係ない。

>>805 destructorの処理コストを言ってるんじゃないか？
GC まかせでボチボチやったとしても、
でかいallocation要求来ればGCがアップアップするわな

実装次第だな。

>>807

file close とかも GC 側でめんどうみるだろ？
OS の特性として close より open が重ければアウトじゃん
GC だけで解決できる問題とはおもえへん

明確な例を提示してほしいいな

スマートポインタで、デストラクタの走るタイミングを
上手いことズラしてくれるような物は無いの？

>>889:2 error: '上手いこと' undeclared

>>809
プログラムのセマンティックスかわっちゃうからムリだろ

即解放して欲しいものと、そのうち適当に解放してくれればいい物を区別しておくんだな

あれ？

>>809
デアロケータに適当なの渡して別スレッドに後始末押し付ければ

デストラクタのタイミング変わったらだめだよな
C#だってディスポーザはちゃんとタイミング決めて走るわけで
じゃあデストラクタの後にもう一度廃棄処理が走れば・・・ってそれはC++/CLIじゃなイカ？

デストラクタとファイナライザの役割分担か
ありがちすぎて胸が熱くなるな

大量のオブジェクトを一斉に削除すると
スマートポインタのデストラクタが一遍に呼ばれて(deleteが呼ばれて)処理が滞るということから
GCの優位性を主張する奴がいただけなのにどうしてこうなった

>>816
実装依存なものを優位性とか言い出すから荒れるのでは？
リソース開放処理の負荷分散したいんなら>>813のような
設計にすればよいだけ。

C++の速度優位性（JavaC#にくらべ）もコンパイラ(最適化・癖）や
ＣＰＵ（キャッシュヒット等）の実装依存だけど、負荷分散の為の
ＧＣ実装への依存よりはよっぽどましな気がする。
程度問題だけど。

C#でタイマーやソケットのオブジェクトへの参照を切っても、いつまでもオブジェクトがデストラクトされずにイベントが垂れ流しだったりソケットが閉じなかったり。GCっていい加減なものでGC任せにはできないな。

>>780
その普通ができている実装ってあるのか？

ttp://www32.ocn.ne.jp/~ons/text/CPP0xFAQ.html.ja
年末に、更新してくれたみたい。

>>818
知らないことはあんまり叩かないほうがよくね？

.NETのファイナライザの実行タイミングはGCまかせだから
メモリ以外のリソース解放をファイナライザで行うのは稀
ていうか、ファイナライザ自体GCに負荷をかけるから推奨されてない

リソースは使用した箇所のfinally句で解放するのが.NETのルールで
C#には糖衣構文も用意されている

てかC++書けるくせに.NET書けないとか不勉強すぎだろ

disposeあるし、、、usingもあるからましなほうだろ。
818はjavaでも同じようなことやるだろw
いっしょに仕事したくないですw

Javaでも「原則使うな」なのがファイナライザ
というより、ファイナライザを積極的に使う言語なんてあるのか？

Stringを継承してデフォルトデストラクターが呼ばれないことが防げるよ。

C#のDisposeはもっと書きやすくして下さい

enum classについて言及が無いけどswitchでcaseに列挙子書くとき
型名省略できたりとかできないの？

>>821
じゃあC#も結局リソースの破棄は手動か？何のためのGCだか。
finallyとかusingとか呼ぶ側で対処するとかダサくない？

C++なら例えばunique_ptrつかえば、finallyやusingなくても確実にデストラクトできる。
finallyやusingは書き損じのリスクを人がチェックしなきゃならないのがデメリット

書き損じのリスク程度なら静的解析ツールに診断させりゃいいだけじゃね？

viだけで書けるようにしてくれ

>>827
>>818もそうだけど、GCはあくまでメモリ管理の機能だってことわかってないだろ

言語にかかわらずOSリソースは自前で開放しなきゃいけない事を認識するべき
ダサすぎるわ

C++はデストラクタで解放されるわけだが

C#もネイティブリソースの扱いには色々頑張っていて
CriticalFinalizerObject
とかあるわけですよ

C++だとメモリはリソースの一種という扱いだからねぇ

C++0xこそガラパゴスだよな。
進化の袋小路にはまって未来がない。

>>835が未来のある言語を教えてくれるらしいぞ

Java以上のガラパゴスなんかねーよ

C++に未来がないとしたら、理由はどちらかというと互換性のしがらみだと思うが
move騒動然り

>>838
だから、互換性捨てろよ
lambda ちゃんだってキーワードひとつでもっとこぎれいな制服になってたはずだ

キャプチャ考えると結局こんなもんって気もするけどね

その辺はD&Eを100回読めということで

むしろラムダは他にやりようあんまりない気がする
参照キャプチャを全く無しにするなら全部コピーキャプチャのみにすることで簡略化できるが

>>838
互換性のしがらみからの脱却果てしないDを見習おう。

ユーザーが全くいなければ互換性のしがらみもないな

つまりＤ言語最強

Dはいつ本気出すんだよ

明日

Dはいつも全開だよ
目指す方向が間違ってるだけで

間違ってないよメジャーになる気がないだけだよ

Dは完成したらメジャーになれると信じている

いつ完成するんだよ。

明日

完成したらDじゃないだろう

明日っていつだよ

あしたっていまさッ！

まあキャプチャリストの必要性も分かるんだが…なんというか、
boost lambda の (*_1 < *_2) みたいなインパクトが無いんだよなあ

禿げの理屈っぽさにはウンザリ

いいかげんに仕様をきめやがれ

DやるくらいならC#やってるよ

>>857
理屈っぽさ自体はいいと思う（禿本おもろいし）
結論がきれいにまとまらないことがもどかしいだけ

Conceptのちゃぶ台ひっくり返した時も
理屈理屈で笑ってしまったがw

禿を論破して黙らせるくらいの人材が足りない

人材を待つより、自動命題論破システムを構築

俺がやってもいいけど

期間と予算は？

>>864
そんなもん、 (期間無 == 限大 && 予算 == ゼロ) にきまっtるじゃん

理屈はC++が、というか
あるプログラミング言語がまともな言語として
存在するためには必須だろう。

禿がそれを考えていてくれるんだからいいじゃないか。




俺としては
C++0xを2段階に分けてリリースしてほしいけど。
難しそうな所は第2段階目に置いておいて、
ひとまず有用そうで簡単そうなところだけを第1段階目としてリリースしてほしい。

リリースっていう単語の使い方がおかしいか。策定とでもいうべきか。

C++1x否定ですか

難しそうなconceptは先送りになったでしょ

現実はどうあれ98を置き換える規格を作ってるんだから小出しリリースとかアホすぐる発言はよし玉枝

先などあるのだろうか

>>866
それやるとコンパイラベンダが文句を付けて来ないか
今も規格が固まってないのに当たり障りない部分から対応してきてるけど

今でも使わない機能が山盛りなのにこれ以上増やしてどうするのかと思う。
俺達に必要なのは間違えなくC++ーーだ。
C++0xなんか要らない。

>>872
つ EC++

あれ気持ちはわかるんだけど極端すぎたのが敗因だな
template や多重継承は残して、virtual や new のほうを何とかして欲しかった
関数ポインタで片付くところはそれでいいしゼロオーバーヘッド原則を有名無実化されるのがいや

言語そのものが巨大オブジェクトのアンチパターンまっしぐらなのがどうもね
これ C++ に限ったことじゃないけど

>>874
( ﾟдﾟ)ﾎﾟｶｰﾝ

>>872
全員が全部を使う必要なんて無い。
ライブラリを作る人、使う人、カーネル寄りのコードを書く人、それぞれ使う部分使わない部分が違う。
ただ 0x の追加のそれなりの部分は誰にとっても便利だけど。

てゆーか0xの追加機能っておおむね簡単便利な機能ばっかだと思うんだけど
単純に機能山盛りという意味ではC#の方が遥かに仕様でかいじゃん

>>872
たとえば使わない機能ってなにさ？

右辺値参照はライブラリ屋さんは必須項目だけとアプリ技術者は特に気にする必要はないし。

>>877
Move semanticsは今もいろいろバタバタしてるよ、簡単とは言えない。

使わない筆頭のautoは出世したな

>>879
決めるのにゴタついてるだけで、決まった後にそれを使うのが難しいようなものじゃないだろ

>>878
＞右辺値参照はライブラリ屋さんは必須項目だけとアプリ技術者は特に気にする必要はないし。

アプリ技術者でも、既存のソース読んだり、自分でクラス作ろうと思ったら知る必要あるのでは？
C++0x はまだ使ってないけど、最近 C++ のプロジェクトに新人が入ってきて、引数の値（コピー）渡しと参照渡しの使い分けとか、いろいろ教えるのが大変すぎる。

>>872
C++ の機能はほとんどが密接に関連してるから、部分的に削るとかは無理。

>>881
ええっ！？

C++0x後を見越したTR2ってその後どうなったんだろう。
並行してC++1xに取りかかってほしい。

0xがFixしたあとだろ

もう最初からC++2xと言うべき

VC10のbasic_stringってメモリの連続性保証されてるのでしょうか？

0xでbasic_string何か変更あったっけ

21.4.1 basic_string general requirements の 5:
The char-like objects in a basic_string object shall be stored contiguously. That is, for any basic_string
object s, the identity &*(s.begin() + n) == &*s.begin() + n shall hold for all values of n such that 0
<= n < s.size().

あとC++0xでは、arrayとvectorも "The elements ... are stored contiguously," となる。

vectorはC++03から
arrayはTR1から
"The elements ... are stored contiguously,"だと思うけど

TRはその名の通りreportでまだ規格の一部じゃない

>>882
アプリ屋さんでも右辺値参照を知っていれば効率的なコードが書けるね。
まあ、知らなくても十分だけどな。

constのうんかす

右辺値参照＋コンテナ＋unique_ptr＝最強

>>894
constは必須だろうJK

constは必須というか、Javaはなんでfinalをあんな設計にしちまったんだと思う

C土土

やろうと思えばC#のように新しい言語を作って定着させる事は出来る
結局だれも本気でC++の代わりを欲しがってるわけではないんだ

D is for DoomsDay

最近の美少女中学生はいろんな意味のC++をしたくてたまりませんヒャッホォウ！(*´Д`)

いやC++の代わりは本気で欲しい。
シンプルで高速な奴。わりとCが違いが機能が足らん。

下位互換を保ったままコンパイル時シンボル解決をお利口にすることはできなかったのかなぁ
コンパイル遅くなってもいいからinclude順でウダウダするのはもうやめにして欲しかった
あとはGCの標準が欲しかったくらいかな

C++0xと比べた時にJavaやC#がうらやましく感じるのって個人的にはこれくらいしかない

include 順については同意だが
GC は死んでもいらん typeid と同類

「言語自身で表現できることは言語に組み込まない」という方針をきっちり貫いて欲しい

placement-new だのファクトリパターンを使うと
普通の new すら邪道に見える

GCはライブラリを作るためのメカニズムが入った。
include順は今のままで問題ない。

GCはライブラリの方の標準として欲しかったよ
shared_ptrは便利だけどちょっと力不足で結局俺俺intrusive_ptr作ってる人多いよね
循環回収保障付shared_ptr/intrusive_ptrとかあっても良かったと思うんだ

>>906
C++0x準拠のコンパイラ出たら出てくるんじゃないの？

>>907
出てくるだろうけどまたboostでwって話にならんか？

ええやん！

>>903
C#のpropertyは割と本気で欲しい

今どきGCのない言語とか血尿が出るレベル。
これだけで使う気にならない

そういう人が使う言語じゃない。
ある程度レベル以上の人が使う言語。
C++じゃないと無理な領域(e.g.システムソフトウェア)もあるし。

結局C/C++やそれ以下の低水準言語でしか
まともなOSとか作れてないんだよね。

低能者、例えば>>911とかだと発狂するのかもしれないけど。

いやー、やっぱりGCは便利だよ
ただ全てにおいてGCを強要されると逆の意味で血尿が出るが

>>914
> いやー、やっぱりGCは便利だよ

そういう話じゃないだろw
昔、System VのIPCもGC使って実装してあったよ。

血尿かと思っていたら初潮を知らなかっただけで悩んで誰にも相談できない美少女中学生ヒャッホォウ！(*´Д`)

まだ0xなの？

C++書くやつって変態多いよな
プリムラ大好きとか言うから園芸やってんのかと思ったらエロゲのキャラだったし

ガベコレ導入するなら言語レベルで寿命管理を出来る仕組み入れて欲しいね。
register指定を高度にしたみたいな

簡単に無効に出来て、無効設定でうっかり使おうとしたらコンパイルエラーになることが保証されてるような
ガベコレならあってもいい

GCは次のバージョンで入るんじゃないの？

ないね
校長先生が生きてる間は

うむ
C++にGCとかマジ勘弁
メモリコストに鈍感なアホが増えるだけだ

GCを使いたい局面ではC++以外を使えば良いよ

ライブラリならいいだろ？

C# の unsafe のように、gc 走る部分は safe つけるとか。
あまり実用性が見えないけど。

GCほしけりゃDやれD

>>922
うろ覚えだが、D&Eでは割と好意的な評価じゃなかったっけ？

ロリコンはまたさっさとアク禁にならねーかな。
しばらく平和だったのに。

>>927
GCは有用であり考慮に値するが、GCを使わないプログラムの表現力が制限されてはいけない。
理想的なGCが存在するならパフォーマンス問題もなく、またそうする事は可能だと思われる。
しかしそれを考えるのも簡単な仕事ではないので、ユーザのGCに対する関心が高まってくれば
試験的な実装も出てくるだろうから、それを見てから考えよう。
要約するとこんな感じ。

C++にGC実装なんて可能なの？
ポインタ操作を追跡できるとは思えないんだけど

>>930
ポインタは回収しなければいい
要するにただの「循環参照回収保障付きshared_ptr」みたいなもの

保守的GCなら既にあるよな、Gaucheやw3mなどが使ってるBoehm GCとか
Cとの組み合わせでは十分実用になってると思うけど
保守的なのでゴミが残る可能性がある
C/C++の言語仕様ではExactなGCはたぶん無理じゃないの、知らんけど

マシンがタグアーキテクチャなら可能性はある。

つまり現行の普通のマシンでは絶望的だろう、ということだけど。

C++はなんでもオーバーロードできるが
ポインタ操作だけはオーバーロードできない
絶望的だと言うのは、つまりそういうことだよな

え、ていうか既存のポインタがそのままGCで回収されるような話だったの？
てっきりstd::managed_ptr<Hoge> pみたいな話かと思ってたんだが

シングルトン的なGCを設置してそいつにインターフェース食わせるってかんじになるんかな？？

>>931
weak_ptrがあるから循環参照も解決できるね。
weak_ptrは所有者をはっきりできるからわかりやすくなるね。

現状*_ptrがあれば全く困らないな

GCはこの後全く進んでない。二年たってる。

N2586 Minimal Support for Garbage Collection and Reachability-Based Leak Detection (revised) H.-J. Boehm, M. Spertus, C. Nelson
N2587 Minimal Garbage Collection Status API M. Spertus, H.-J. Boehm

面白いとは思う。

次世代のGCは、仮想化支援の命令をハイパーバイザから使ってるから、VMのないC++には向かないかな。
根拠は不明。

GC専用のコアを積んでいると仮定した方がよくね？
言語仕様の中だけでやろうとするとどうしてもC#とかJavaとかDめいてくる

コアそのものの記述にも使う言語でか

PauselessGC
http://www.infoq.com/jp/news/2010/06/azul_ori
ちなみにこれは商用の興味引くためのハリボテプロジェクトの可能性あり。
別のが実装されても、vmが必要ならclang+llvm経由かなーと思う。

C1xの方もCD投票に向けたドラフトが出てた
ttp://www.open-std.org/jtc1/sc22/wg14/
こっちはスレ立てるほど注目されてないかな

どうせまたC2xにすればよかったって事になるんだろ

C99が既に半分死に規格なんだから今さらだな

とりあえず立ててみた。
http://hibari.2ch.net/test/read.cgi/tech/1296642667/

そういえば、このスレもそろそろ次スレの時期だな。
まあ、この流れだと、まだしばらく大丈夫そうだけど。

ttp://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50372
>Target publication date: 2012-02-28

あと一年ちょい。

1年後にも後1年って言ってそうだな

いやconcept外して軽くなったし、まとまるでしょ。

本の虫氏が参考書を発売するのもそのころだな。

そのころにはまた変わってるんだろうな

永久に本も完成しないのか

あんまり伸びると本の虫氏が餓死しかねん

その時には、C++0x本に「本の虫死追討」という帯を着けるよ。

追い討ちをかけるなよw

何も完成版じゃなくても、策定途中版でも出せばいいのにな。

何で完成版にこだわるのか意味不明だ。

途中で仕様が変わってゴミになるかもしれないのに
そんなの買う人いるの？

ゴミになるかもしれない知識に10960のレスが付いているわけだ。

最終的な仕様ではなく途中経過にも価値はある罠

買う気がない人は何とでもいえるだろう

できれば紙の本として\5,000くらいで出てくれるとありがたいんだが。

ロングゲートから出るの?

>>958
VC6の悪夢を繰り返してはならない・・・と言いたいが
既に2010で同じ事が起こりそう

とっとと実装しろ派 vs 中途半端な物を実装するな派
に挟まれて苦悶するMS

お前らは参考書の話をしているのか、それともコンパイラの話をしているのかどっちなんだ。

VCのC++0x機能対応一覧表みたいなのってなかったっけ

>>968
http://wiki.apache.org/stdcxx/C++0xCompilerSupport

>>968
http://www.aristeia.com/C++0x/C++0xFeatureAvailability.htm
の一番下の"Language"をクリック。

ここもすっかり静かになってしまったな。ところで校長先生の本はまだかな。去年の年末に校了という話を見たんだが。

ラムダ関数で自己再帰関数が出来ません。
どうやったらできますか？
お願いします。

>>972
ラムダは関数ではなくて式です。諦めな。
どうしてもやりたいなら、
_ = lambda x: x if x == 0 else _(x-1)
_(3)
とか。

>>973
後半のコードの説明お願いします。

なにこれPython？

どうみてもPythonです本当に

>>972
named lambdaがない現状では、キャプチャーするstd::functionのオブジェクトに、クロージャーオブジェクトを入れておくしかない。

std::function<void(void)> f ;
f = [&]() -> void { f() ; } ;
f() ;

引数に自分自身のラムダを渡すとか？

C++0xF

質問です。
右辺値とかmoveとかをあまりよく分かっていないのですが、
ヘッダとソースで宣言と定義を分けられている関数で
クラスのインスタンスを戻り値で返したい場合に、
大抵の場合でパフォーマンス的に妥当な
C++0x時代の書き方というのはあるのでしょうか？
実体返しで良くなったとかいう話を目にしたりするのですが、
でもそれってインライン展開される場合だけの話？ですよね？

今は全て↓のように書いています。
std::shared_ptr<Hoge> Moge::getHoge()
{
auto hoge = std::shared_ptr<Hoge> (new Hoge());
hoge->hige();
return hoge;
}

>>980
new が入ってる時点でオーバーヘッドもクソもあんのか？
とは思うけど、 std::make_shared() 使うとか、あるいは std::unique_ptr 使うとかして
軽くすることはできそうに見える。

すみません、内部でnewしているのは確かに全く頓珍漢な例でした。
あと先の場合はstd::unique_ptrで良いのですね。ありがとうございます、勉強になりました。

ごめんなさい。書き直します。
以下のような値返しの非インライン関数を、呼び出し元へ最も処理コストを少なく返したい場合、
この関数または呼び出し元などで、C++0xでの特別な書き方が必要になるのでしょうか？

Hoge Moge::getHoge()
{
Hoge hoge;
hoge->hige();
return hoge;
}

Hogeがmove可能ならばNRVOが行われないときmoveされるので
そのままでいい

shared_ptrと違って、weak_ptrは比較演算子が無いの？
現在の規格上そうなっている？うーん、利用側で勝手に定義していいもの？

weak_ptrはそのまま使うものじゃねえよ
shared_ptrに格上げしてから使うもんだ

weak_ptrのままだと比較演算してる最中に消滅してもおかしくないわけだしな

メンバーもしくは、クラスの外に吐き出すならshared
ローカルから全く出る可能性がないならweakでいいんじゃねえの？
ついでに聞くけど、自動変数として確保したオブジェクトを
管理してくれるスマポって無いの？
自動変数が解放されそうになったら、ヒープにコピーしてくれるとか。

最初からヒープに確保するのじゃダメなのか

>>972
thisポインタ経由じゃできないのかな？
this->operator()とか

>>988
argvのような引き渡される形のポインタがあって400万とかデータが
入ってる。こんなもんコピーしたく無いじゃん。
でもこれをスマポを引数に取るクラスに渡したいんだよ。
状況によっては、スマポを引き渡すオブジェクトは、
オブジェクトを生成した関数の中で死ぬ。
最初からヒープにコピーするの無駄じゃん?

>>990
最初にデータを用意するところから全部ヒープでやれって話では？

argcが400万とか胸が熱くなるな

vectorとかで内部的にはヒープに確保されてるとかそんなオチな気がする
make_shared<T>(std::move(...))とかでヒープにmoveさせればいんじゃね？

>>987
こういう用途ならunique_ptrが適当に見えるけどね。
返り値にしなければ自動破棄されるし、返り値にすればmoveされるだろう。
もちろんデータのメモリはヒープにおくことになるが。

argc400万ワロタ

ラッパクラス作ってそれを動的に確保すればいいんじゃないの

そもそも400万とかスタックに入らんだろ

argvだけで16MBか

つか次スレは？

C++0x 12
http://hibari.2ch.net/test/read.cgi/tech/1298470844/

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。