C++0x 8

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

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

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++学園の人々

○コンセプトさん
ついに一度も登校することなくお星様になってしまった。
この事件によって学園に激震が走り、入学式が一年延期になる事態に。
彼女の再起はあるのだろうか。

○ラムダさん
コンセプトさんに代わって新入生代表に抜擢されることに。
だが服が汚い上デザインが二転三転してるのでよくいじめられる。
コンセプトさんと同じ目に遭わないかと内心ビクビクもの。

○右辺値参照さん
一足先に本格的な通学を始めつつある新入生。
よく出来た子として先生方には評判が高いが、
気難しいので普通の生徒たちからは敬遠されている。

○拡張for文さん
forさんの妹。コンセプトさん問題の一番の被害者。
きったない服で通学することになりテンションガタ落ち中。

○type_traitsさん
ライブラリ科の新入生。
コンセプトさんの代役としてにわかに注目を集め始めた。
思わぬスポットライトに浮かれすぎで最近テンションがやばい。

○static_assertさん
type_traitsさんの相方としてこちらも注目を集める新入生。
面倒な相手との仕事が増えそうで最近憂鬱。
assertさんの妹だが、マクロ科と予約語科の立場の違いで仲が悪い。

○initializer_listさん
vectorさんが泣いて喜ぶコンテナ部悲願の新人。
だが似たような服を着た生徒が元から多いので、一部では
「またややこしい奴が来た」と陰口を言われているらしい。

○テンプレート可変長引数さん
テンプレ部が泣いて喜ぶ期待の新人。部の熱狂的な歓迎ぶりと
「変態が増えた」と嘆く周囲の温度差に困惑中。
stdargさんとは顔がよく似てるが血の繋がりはない。

○autoさん
地味で消えそうだった子が一転、イメチェンで今やモテモテに。
そのあまりの変貌ぶりに周囲は戸惑いを隠せない。
最近まで同じ立場だったregisterさんの胸中はいかに…

○decltypeさん
autoさんの妹の新入生。姉が記憶クラス科にいた過去は知らない。
姉に劣らぬ人気者だが、服装のちょっとした違いで性格が変わる面倒な一面も。

○ユーザー定義リテラルさん
「わかりにくい」「見るからにきもい」「関数さんでいいじゃん」と
すこぶる評判の悪い新入生。強く生きていって欲しい。

○nullptrさん
「今さら来られても……」「なんで今までいなかったの？」という
心ない陰口に傷ついている地味な新入生。

○long longさん
え？新入生だったの？

○禿
校長先生。

・Raw String Literalさん
なんだかよく分からないアクセサリーを頭とお尻に付けている。
しかもアクセサリーは日替わり。

・auto_ptrさん
落第。一応、まだ学校にはいる。

・unique_ptrさん
auto_ptrさんを蹴落として進級してきた。

・Smart pointerさん
とても頭がいいが、循環参照も扱えるかどうかは、学校によって異なる。

・Unordered associative containerさん
いつも、とても大きなカバンを引きずっている。
ただし、カバンから物を取り出すのはとても早い。

・Regular expressionさん
頭は良いらしいのだが、何を言っているのかよく分からない。
周囲からは中二病だと思われている。

・Atomic operationさん
細かいことばかり気にしている神経質な子。
口癖は、「だってその可能性はゼロじゃないし〜」

・threadさん
カバンも持たずに登校してくるミニマリスト。
ペンと紙一枚あればそれで十分でしょと言い張る。
どうしようもないときは、魔法の言葉、「ねぃてぃぶ・はんどる〜」を唱えると、とりあえず何とかなる。

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

・progress_displayたん

>>6
いねぇw

>>6
入試どころか書類選考で落ちたな。

>1乙！！

registerさんはD組行きが決まってしまいました

const_expr ﾀﾝは何処へ

・constexprさん
const さんの従姉妹。const さんと同じく地味ながらきっちり仕事を果たす実力派。
先生達に「りかーしぶ」という魔法の杖を奪われそうになったが無事に維持。
今後の活躍が期待される。

>>11
するってーと、8queenとかのパズルの解法プログラムの答えが実行前に得られそうだな。

constexprはこんな風にオーバーロードはできるの？
double sin(double x); //FPUを呼ぶ。
double sin(double x)constexpr; //近似式で記述されてる。

double sin(double x); //FPUを呼ぶ。
constexpr double sin(const double x); //近似式で記述されてる。

こうなるんじゃないの

lineでチマチマ書いてたリージョンをビットマップで片付けるみたいなもんか

>>12
コンパイラ上で解法プログラムが走ると考えるほうがいいんじゃね？

void f();があったときvoid a = f();って書けるようになった？もしくはautoでいける？

aには何が入るんだ？

ソースコード上はなんか入ってるっぽいけど実際には記憶領域を全く使わないなにか
MLのunit型やHaskellの()みたいな扱いで

>>17
それは余計な機能のような気がするなあ。
voidに対する==や、void*の参照外しの動作を定義する必要があるし。

sizeofが0のオブジェクトは色々と問題があるので作れないようになってる

そんなのできるようになるわけがない

constexpr の再帰回数制限の最低推奨値が 512 とかテンプレートのインスタンス化の再帰制限の
最低推奨値が 17 から一気に 1024 に拡大とか委員会は変態コードを推奨している気がしてならない。

>12
全部 return 一文で書ける形にしなきゃならないからテーブル作るだけでも結構大変だと思ったけど
MPL 使えばいいのかって、いやだったら最初っから全部 MPL で書けばいいような。

>14
constexpr であるかどうかに関わらずパラメータリストの中にある最上位の const は無視される(現行仕様でも)。
なので >13 のようなオーバーロードはできないと思う。

>17
>N3000 3.9.1p9
>(略) The void type is an incomplete type that cannot be completed. (略)
>An expression of type void shall be used only as an expression statement (6.2), as an
>operand of a comma expression (5.18), as a second or third operand of ?: (5.16), as the operand of typeid,
>or as the expression in a return statement (6.6.3) for a function with the return type void.
ってなってるから駄目っぽい。でも対象の式を return に置く形で大体逃げられるんじゃないの？

すごく昔マクロアセンブラで素数を計算するプログラムがあって
アセンブル時に計算し終わっているっていうのがあったけど、
C++は未だに実現できていないという低級言語なんですね。

お前……その……頭、大丈夫か？

>>23
それはね、標準化委員会からの挑戦状だよ。

>>24
C++にはpythonというプリプロセッサが(ry

BOOST.PPでできるよ！

>24
いや、MPL で書けるだろ。
後、1994 年の時点でエラーメッセージに素数が出力されるコードが委員会に報告されてる。
ttp://www.informit.com/articles/article.aspx?p=30667&seqNum=8

テンプレートの再帰数が制限されてるのがネックだな
再帰数の制限がなければコンパイラは立派な関数型言語のインタープリタだ

>>24は昔から良く貼られるバカのコピペだから、
みんなレスしちゃだめだよ。

だから再帰回数の制限でできないんだろ。
アッカーマン関数をコンパイル時に計算してみろ、低級言語。

それがなんの役に立つのやら

>>32は低級言語の意味を勘違いしている予感

B級映画やA級戦犯と同じような勘違いかな

いやだから仕事の求人がないやくて
自暴自棄になっているだけのやつを
相手にするなって。

「なくて」と「ない」で迷ったのは分かったが
どうやったらその文脈で「や」をタイプするんだ

日本語不自由な人なんだろうから大目にみてやれよ

>>37
多分そこ迷ったんじゃないと思うよ。
まず最初に「仕事の求人がないやつが」と書いて、自暴自棄のくだりを付け足すために
「なくて」と変更しようとバックスペースしたら、「な」まで戻らず2文字残っちゃったのでは。

低級言語はDSLの出力言語が関の山。

>>4
>・Smart pointerさん
>とても頭がいいが、循環参照も扱えるかどうかは、学校によって異なる。
学校によって異なるってどういう意味？weak_ptrが実装依存なの？

>>3
autoはもはや同姓同名の別人が入学してきたんじゃないか

とても完全に記憶できないような、
低レベルで細かいとても変わった規則の連続。
そんなこんなでちまちま曲芸プログラミングをすることを強いていく低級言語。
そんな言語より、問題に対して真っ正面から素直に
ズドンとぶつかっていく、問題を知り尽くした人により慎重に
そして大胆に設計されたDSLを学ぶ方が良いだろう。

>>43
な.../ :::早:::::l::::":::::::､:::: :ヽ.::::::::::::::::.:::::.こ:.: 駄.
ん/ :::::::く::::::|::::::::::::::ヽ:::::ヽ`:､:::::::::::::::::い::: 目
と.!:::､::::.:::::::::.ｌ:.:::::::::::::::ヽ::＼:::ヽ.::::::::::..つ:. ..だ
か:..: :::|,::: :: :、丶: ヽ: :: :ヽ :::'-::ヽ:::::::::..・ ..
し::::|:::::::y::::::::ヽ:::::ゝ:ヽ,::::::＼.::::ﾞ''.::ヽ::::::・: .
な:,:::.ｌ:::::lヽ::::::::、:":::::､: ､:::::::ﾞ'.ｌ'-、::.:ｌ::::・::.: .
い.!:,::::ﾐ､:ﾞ!,ヽ::::: ｌ::::.＼ヽ,＼::..,.＼＼.ｌ::.::::: ...
と.! ｌ::.:::､::::ｌ从_:::::l::,,'.:/_､ﾆ,,__､i::|:､''"!:::::::, .
.・:::.ゝ. !./ﾞ! :^lゝ＼|::l ゞ='ﾊ":`.,!`)l:'":::::":::/ ..
.・::ﾍ::: `''`:ゝ-:"::::::::ｿ":.､:´ ｀-'‐' ι,.|,i::i'::::/..
.・. ::ﾐ ｀::::::::::::::::::::::::　　　　　　 　　ﾉ.|.l::::i./ ...
.　　ヽ''ｌ､:::::::::::::::::::　　 　　　　　 .i　.,l/::::|:,i"
　　　 .'ﾙ:::::::::::::::::ゝ_-　　　　　　 U,..ｌ,i|::l/:. .
.　 　 　 ヽ::::::::　　 　 　 　 　 　 ﾞ'/ゞ.从､.! ...
　　　　　. ヽ::::::`ヽ..二"''‐　　　 / ,iﾞ.::|"l/‐ .
　　　　　 ／ﾞ:､::: `―　　　　.／,,､/ .ﾞ|　! ......
　　　 ／ 　.ヽ: ＼　　　　_／ ／ l./ 　ﾞ
. , ／　　　　l ヽ .｀'― :(,ﾞ／ﾞ　 //

>>42
auto a=func();
auto int b=func();
なんか共存できそうだけどね。

>43　それはギャグで(ry

低級言語： より機械語に近い（抽象度の低い）言語
　対義語->高級言語：自然言語に近い（抽象度の高い）言語
DSL： 特定の問題領域に特化した言語(Domain Specific Language)
　　　　ＴＭ等価で無いことがある。
　対義語->汎用プログラム元号：様々な処理を行うことを目的とした言語。普通はＴＭ等価。
　　　　　　　general-purpose programming language

Low Level / High Level を低級/高級と訳して平気な男の人って

>>46
だから相手にするなって。
低級言語の意味を間違えていて、
バカにした手前今更引き下がれない低能力者なんだから。

時代に忘れられそうな低級言語に
未だにしがみついていて哀れですね。

DSLw

とりあえずお勧めのDSL教えてくれ。

>>51
boost spirit

boost::xpressive

なんか おつむが弱くて
C++について行けなくなって
落ちこぼれたヤツが必死になってやじっているという絵が
脳裏に浮かぶwww

C++ができるようなこといって
細かい規則をテストしたら40点だろ、おまえ。

大体みんなそんなもんだろ

>>55
低級言語の意味も知らないくせに偉そうだな

>>57
だから>48！
もうほっとこうぜ、騒いだってこいつに職は無いことには変わりないんだから。

>>57
>>40

DSLw

思い出してみると低級言語という表現は
オレがC言語を勉強した15年以上前の頃から知ってるよ。ごめんね。

おっさんはすっこんでろｗ

とりあえずC９９互換だけ先に確定して取り込んで欲しい。
stdint.hと__VA_ARGS__と__func__とlong longとsnprintfあたりだけでいいから

残念なことに、それらはサポートされているのだ。

プリプロセッサとかlong longとか邪悪すぎるだろ。
C畑の奴らどんだけアホなんだよ？

long longのどこが邪悪だよ

long longを邪悪だと認識する人って・・・・・マジでC++使ってねえだろ？

LP64だから要らねえとか思ってるんだろうな

将来さらにでかい整数型ってのを表現したくなったらどうするんだ？
long long longにするのか？

<cstdint>の形で提供されるべきなんだよ。

多倍長ライブラリを使うだろ

せっかく拡張するならlong<128>みたいな構文が欲しかった
128bitや256bitの整数だってどうせそのうち必要になるだろ

long long long
long128_t

…どっちも今ひとつ。

構造体の最後のメンバに、長さを省略した配列が使える機能が欲しかったな。

名前くらい気に入らなかったら変えればいいだろ

warota

char *p = "hello world!";

このクソ変換N3000で無くなったんだな
良いことだ

>>72 VCの言語拡張でできたような気がするけど、
今となってはそういう処理のクラスを作れば済む話になったな。

>>72 はWindowsのAPIで使う構造体の話じゃないの?
struct bmpinfo {
　BITMAPINFOHEADER bmiHeader;
　RGBQUAD bmiColors[1];
}
こんなやつで
bmpinfo *bi = (bmpinfo*)malloc(sizeof(bmpinfo) + sizeof(RGBQUAD) * 16) ;
コード適当であってるか知らないけど

>今となってはそういう処理のクラスを作れば済む話になったな。
最近、WinのAPI使わないから知らないけど、どんな方法使ってるの?

C99
ttp://seclan.dll.jp/c99d/c99d04.htm#dt19990726

>>78 thx
配列を素で使うことはほとんどなくなったから、こういったところは
知らなかった(忘れてた?)なぁ、勉強になったよ。

>>77
APIに渡す構造体が欲しいというなら、こんな感じにしてる。
class Hoge
{
struct bmpinfo
{
BITMAPINFOHEADER bmiHeader;
};
bmpinfo * buf;
public:
Hoge(int size)
:buf((bmpinfo*)new char[sizeof(bmpinfo)+sizeof(RGBQUAD)*size])
{
}
~Hoge()
{
delete[] (char*)buf;
}
RGBQUAD& operator[](int i)
{
return ((RGBQUAD*)&buf[1])[i];
}
BITMAPINFOHEADER& header()
{
return buf->bmiHeader;
}
};

>>80
ダメだぞそれ

>>79
つってもVCはC99非対応だから結局独自拡張だけどな

template <int N,int W,int H> struct bmpfile {
BITMAPFILEHEADER bmfHeader;
BITMAPINFOHEADER bmiHeader;
RGBQUAD bmiColors[N];
BYTE bmBits[H][W];
};
bmpfile<16,480,640/2> vga4bit;

別の方法を考えようとしてもパディングとかアラインメントとか気にしないといけなくて面倒

gcc4.4をインストールしたんだけどコンセプトとかラムダ式はまだ実装されてないのね・・・
まだ劇的に変わったって印象は感じれないな

>85
concept は最早通常リリースでは実装されないんじゃね？
lambda は 4.5 で実装済みらしい。
ttp://gcc.gnu.org/projects/cxx0x.html

>>86
.5にしたらできました
これはすごい便利っぽい

>>75
めでたくVC++2010では入らないことが決定した

　　　　　　　　　　　　　　　　　　　　　　　ｺﾝｸﾞﾗｯﾁｭﾚｰｼｮﾝ
　　　　　　　　　　　　　,―＝=７　　　　　Ｃｏｎｇｒａｔｕｌａｔｉｏｎ！　　　ｺﾝｸﾞﾗｯﾁｭﾚｰｼｮﾝ
　　　　　　　　　　　　　|く ___ _>　　　　　　　　　　　　　　　　　　　　Ｃｏｎｇｒａｔｕｌａｔｉｏｎ！
　　　　　　　　　　　　　ｆll｀ｰU+'
　　　　　　　　　　　　　｀''､ ｰ=|　　　　　　おめでとう・・・・・・・・！
　　　　　　　　　　_,,..-´:|ヽー-;ｰ..,,_
.　　,−＝-,　,,..-‘≡≡:|　><´|≡::|ヽ　　　　おめでとう・・・・・・・・！　　おめでとう・・・・・・・・！
.　　| l____ヽ.|≡ｌ≡≡≡| |::| |≡:::/::|
.　　|(ｌｌｰ´_ヽ|≡|≡≡≡|.|:::|ｌ≡::/::::|　　　　　　おめでとう・・・・・・・・・・・・！
..　４ ｌ__｀=|_|≡:|≡≡≡::||:::|'≡/≡|
／|＼,.･|::≡:|ヽ|≡≡≡≡≡:::/|≡::|　　　　　　　　　　　　　　　　　　　　　　　　　＿,,.........､
≡|/}:ヽ|:≡|::::|{≡≡≡≡≡:::{　.|≡::|　　　　　　　　　　　　　　　　　　　　　　　　ヽ_,,　　　ヽ
≡:| |:::|ｌ≡:|≡|:|≡≡≡≡≡:::|.　.|≡::|　　　　　　　　　　　　　　　　　　　　　　　　/_>　　　|
:::≡ｌ|:::|'≡:|≡:|::|≡≡≡≡≡:::|.　.|≡::|　　　　　　　　　　　　　　　　　　　　　　　|７　llう..　|
≡≡≡≡/|≡ヽ≡≡≡≡≡::::|.　..|≡::|.　　　　ｚ-..,〃、　　　　　　　　　　　　　ﾑ__　ll´..　|
::≡≡≡::/　ヽ≡ヽ≡::|―､≡≡::ｌ　..|≡::|　　　/　　　　ﾐ　　　　　　　　　　　　　　1´/ヽ＝=,...
::≡≡≡|　　　＼≡ヽ::|　　ヽ≡≡ｌ　　.ｌｊヽｌ　　|　　　刀､ﾐ　　　　　　　　　　　_,,,..-｀‐三＝ー-
::≡≡≡|　　　　|ヽ／ｰ.、..　ヽ≡≡ｌ.　　.|/　　|　　ノ= ∠i　　　　　　　　　/ヽ､≡≡≡≡≡
:|¬､≡≡ヽ.　　|≡ゞー=ッ　　|≡≡|　　　__／ (ll ｰ゜＼|ヽ.　　　　　　　/≡::ヽ≡≡≡≡≡
:|　　ヽ≡≡ヽ　|≡≡ヽミ.　　　|≡≡|　　ｌ|. ll７|　ヽu＝/ｌ二ll二ｌ'''ヽ　　/≡:::/≡≡≡≡≡

そりゃそうだ
互換性インパクト強すぎだもん

GCCやBCCだって入れない可能性は高い

規格違反を平気で犯すBCCはほっとくとして、本当に互換性問題でるか？
gccは4年前にC++では-Wwrite-stringsを規定にしたし、文字列リテラルを変更するような未定義コード書いてるやつは頭おかしいだろ

本当に変更してるようなクソコードは救えないしほっといていいけど
単に参照するだけでも素朴にchar*使っちゃってるコードはごまんとあるだろ
それ全部修正だぜ？

参照するだけならなおさらconstちゃんと使えよと言わざるを得ない

＞単に参照するだけでも素朴にchar*使っちゃってるコード

そんなクソコードは救えないしほっといていい

単に参照だけだろうとgccではずっと警告が出ていた事になるわけで
そんなプログラマはやっぱり救えない

うーん。
互換性の意見もわかるけどさ、いつかは修正したいところじゃないか。
この様にC++0xというでっかい変更の際にはちょうど良い機会じゃないか？

VCもせめて警告にはしてほし、かった
警告にはすんのかな

char *foo(char *s){
int a,b;
if(regexp(s,"[HOGE]+",&a,&b)){
*b='\0';
return s+a;
}else{
return "(not found)";
}

こんな関数いっぱいありそうだけどなぁ
と書こうとして誤送信

それをconstに出来ない理由がわからんな

組み込み系だと普通に書き換えできたりするので

で？
規格と実装の違いもわからないバカ？

const_cast使えばいいだけ

コンセプトなしでテンプラ引数が、特定のメンバ関数を持ってるか調べられるの？

boostのlambdaとC++0xのlamdaははっきりいって別物
って言われているんだそうですが、
記法が別なのはともかく、できることも別でしょうか？


>>104
> ttp://cpplover.blogspot.com/2010/01/c0x_23.html
> ちなみに、C++03でも、SFINAEを変態的に使えばできたりする。
> ttp://cpplover.blogspot.com/2008/10/hasxxx.html
だそうです。

C++にlambda追加して何するの？

それは「関数オブジェクトって何に使うの？」という質問と一緒
ぐぐれ

わかんないんだねｗ

>>106
関数オブジェクトを使うなら分るはず。

functionalヘッダの中身とかバッドノウハウすぎるし、
lambdaは絶対必要だよね

VC10とGCC 4.5が出たらTR1のbindもバッドノウハウ行きかもな

バッドノウハウって何ですか？

【bad know-how】ソフトウェアなどを使いこなすために、ストレスを感じながらもしぶしぶ覚えなければならないようなノウハウ。高林哲による造語。氏によると、バッドノウハウは、複雑な設定を「奥が深い」として有難がってしまうマニア独特の感性によってはびこるという。
これか

バッドノウハウと「奥が深い症候群」
ttp://0xcc.net/misc/bad-knowhow.html

C++ユーザーとしては耳が痛いっすorz

templateメタとかそんな感じだよな
もういっそ互換性なんて放り投げてきれいに作り直せばいいのに

>>114
> もういっそ互換性なんて放り投げてきれいに作り直せばいいのに
それをやったらD言語みたいな悲劇になるんじゃないかな。

「奥が深い」 という意味をどう捉えるかだな。
「何でもできるけど簡単」が理想だけど、そんなことはできるわけがない。

「簡単だけどできないことがある」というよりも「使いこなすのは難しいけど何でもできる」
方がマシだな。まあ、複数のツールを使いこなすのとどっちが簡単かのトレードオフだろうけど。

>>116
実行時速度とか、有名さとか、対応環境の広さとかも大事じゃね？

俺はC++を盲信してコーディングしているけど、
そんな俺でさえ日々のちょっとした作業はPythonで
行っている。

・・・だってクソ便利なんだもん。

>>75
今さらだがこれってconst以外に変換できるのがクソってことか？

文字列リテラルの書き換えは未定義→書き換えが可能なポインタを定義できることがクソ→const char []からchar *を作れることがクソ

C++で生ポを使う方が珍しいからその辺は誰も気にしなくてほったらかしにされてるんだよ。

「から」じゃねえよ
状況と結論はあっているが推論は間違っている

boostのlambdaって、
普通に書くと、まずコンパイル通らなくて
試行錯誤してるうちに、つーか関数オブジェクト書いた方が早くね？
ってなるイメージだけど、0x版は良くなってるの？

autoでずいぶんとマシな状況になっていると思う。
関数オブジェクトだとインラインに書けないからねぇ……

C++0xのラムダ式はBoost.Lambdaとは別物。
もし、>>123の言う0x版がC++0xのラムダ式のことを言っているなら、答えはその点では確実に良くなっている。
少なくとも何度ものトライ＆エラーはいらなくなるはず。

良くも悪くも関数オブジェクトをその場で書くという雰囲気。
ラムダ式をまだ見たことないなら、まずは見てみろ。
これラムダ式がメインの話ではないけど、ラムダ式いっぱい出てくる。
http://msdn.microsoft.com/ja-jp/magazine/dd434652.aspx
ほかはこれとか。
http://codezine.jp/article/detail/4035
http://msdn.microsoft.com/ja-jp/library/dd293599(VS.100).aspx

Snow Leopard 以降のブロック構文とラムダ式って違うの？

>>120
未定義なら書き換えできたっていいじゃまいか

>>127 プログラムに未定義動作が入っちゃダメだろ。

>>127
もちろん、これからもできるさ

char * ptr = const_cast<char *>("hello") ;
ptr[0] = 'a' ;

普通にchar []で宣言すりゃいいだろ……

char []で宣言したらただのポインタになるわけだが

>>131は何言ってんだ……

これはもちろんダメ
char str[] = "Hello,world!";
str[0] = 'a';

これが一応の正解（Cでは正解）
char str[13];
strcpy(str,"Hello,world!");
str[0] = 'a';

これがC++での真の正解
std::string str("Hello,world!");
str.at(0) = 'a';

一番上のケースは普通に有効だろ？
constでもなんでもないcharの配列変数に過ぎないんだから。

>>133
一番上はいいに決まってるだろ。
配列を確保してコピーしているんだぞ。
Cからやり直せ。

そう来ると思ったよ

133の一番上が、"Hello world!"のコピーの配列を作るか
strが文字列リテラル"Hello world!"の先頭アドレスになるかは処理系定義
たまたま前者の実装が多いだけ
0xスレなんだから規格くらい当たれ

この本書いてるひとは char hoge[] がただのポインタだとはっきり言ってるよ w
http://www.amazon.co.jp/dp/4839919844

>>133
>これがC++での真の正解
>std::string str("Hello,world!");
>str.at(0) = 'a';

これは？
std::string str = "Hello,world!";
str.c_str()[0] = 'a';

>>133
えっ
だめなのは
char *str = "Hello,world!";
str[0] = 'a';
の方では？

[]だと初期化だろ?

>>136
strにconstがかかってないんだから、
"Hello,world!"という中身で初期化される配列に決まってんだろ。
どこからstrが先頭アドレスになるなんて発想が出てくるんだ。

n3000の8.5.2 Character arrays [dcl.init.string]
では、配列だな。
つまり、strの型は、char [13]　だ。
要素は、初期化式の文字列リテラルの対応するそれぞれの要素で初期化される。

C99の6.7.8 Initialization
を読んでも、同じだ。

C89も、文面はC99と同じだな。

>>136はどの「規格」を参照したのかぜひ教えてほしい。

>>138
それはダメ。
c_str()が返すのは、constへのポインタ。

>>137
機械語レベルで、イメージファイル中の変数領域へのポインタになるのと
C++レベルでポインタになるのは全然違うけどな。

あれ？？？

昔char *p="...";とchar p[]="...";が全く同じになるコンパイラに当たって
その時調べたらそれも一応規格で認められた挙動だと分かった覚えがあるんだけど

もしかしてウソ掴まされてたのか
ずっと誤解してたごめんなさい

まあよくあることだﾄﾞﾝﾏｲ

よく分からんが>>133の一番上でstrに代入されるのは
文字配列なの？
文字配列へのポインタなの？
文字配列を数値化したポインタなの？

>>146
たいていのコンパイラで、"Hello,world!"のビットパターンが表すアドレスのメモリ領域を指すポインタになる筈。
またはコンパイルエラーかも。

ここは規格のスレなんだから「未定義動作です」でおｋ

>>146
文字配列の実体でOK。

>>147は>>136と同じ勘違いをしている。
実装上機械語レベルで"Hello,world!"というデータが格納された領域を差すことになるかもしれないが
書き換えてOKな領域なのでコンパイラがそうしているだけでC言語レベルでは関係無い話だ。

>>147-148
流れくらい読み直せアホ
strはchar [13]型として初期化されて
普通に"Hello,world!"が格納される

>>149
でも面倒くさいのは、その実装のせいで
char str[]で宣言するとextern char *strからリンクできないんだよな
char *strの宣言なら問題ないけど

>>151
かたやポインタ、かたや配列の実体なんだからリンクできなくて当然だろ。
実装関係ねえ。
extern char str[];でいいだろ。

お前ら C ス レ で や れ ！

>>146>>151
ここは初心者スレじゃないぞ。

そうだそうだ。
C++0xだぞ？
遙か深遠なんだよ。

しかし当然C99を含む規格であるので
まあ一連の流れはスレチではない罠w

つまりC++0xスレさえあればCスレは不要ってことか

>>157
それをいったらプログラミングスレがあれば
他言語含めいらなくなるじゃねぇか。

細分化してある場合はそっちに行くのが
2chの常識。

>>158
ときに落ち着けって。お前さんの安価先は俺じゃなく>>156であるべきだろ

C++1x の話はどこですればいい？

GCC 4.4.3 で
　auto v = { 1, 2, 3 };
があっさり通ってなんか感動

>>161
これって勝手にint [3]になるの？
structとかvectorとか同じ形でいけるのがあるときは優先順位どうなるんだろう

long[3]とかshort[3]の方が先だろ

>144
多分 char *p1 = "string"; char *p2 = "string"; で p1 と p2 が同じアドレスになるかどうかが実装依存ってのと混同したんじゃない？

>162
N3000 7.1.6.4p6 によれば std::initializer_list<int> になる。

>>162
うんにゃ
std::initializer_list<int> になる

std::vector とかにも initializer_list を受け取る
コンストラクタが追加されてる模様

うぁかぶった

ちなみにヘッダ忘れると
#include <initializer_list> がねえよ！
とコンパイラ様が大変丁寧におっしゃってくれますた

struct X {
Z operator[](std::initializer_list<int>);
};
X x;
x[{1,2,3}] = 7; // OK: meaning x.operator[]({1,2,3})

こんなのも可能になるんだな。

じゃあ={}はどっちかというとライブラリなのか？
={}を自分で定義することとかできるのかな
オーバーヘッドとかどうなんだろう

>168
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2672.htm
>167 は operator[] だけど、もちろん initializer_list を受けるコンストラクタも定義できるよ。

>>168
> オーバーヘッドとかどうなんだろう

お前は初期化子のオーバーヘッドの心配もしていたのか?

>std::initializer_list
何だろう、もの凄く嫌な感じがする
妥協の産物というか

>>168
処理系依存だと思うけど参考までに。
initializer_list ヘッダの中をみてみると普通にクラスがある。

　// The compiler can call a private constructor.
　initializer_list(const _E* __a, size_t __l)
　: __array(__a), __len(__l) { }

とかあるなｗ
ライブラリでもあり言語機能でもあり、というところ。

処理系があるといろいろ実験できて楽しいね。
auto x = {}; というのは initializer_list<T> の T が決まらなくてエラー。
{}.size() とか {1}.size() とかもエラーになるな…文法の都合？
auto x = {1}; してから x.size() はおｋ

auto({1}).size()で行けない？

>>173
だめっぽい
　error: invalid use of 'auto'

#include <cstdio>

template <class t_any>
void check(const t_any &val)
{
std::puts("this is const left value.");
}

template <class t_any>
void check(t_any &&val)
{
std::puts("this is right value.");
}

int main(void)
{
check(100);

int x = 200;

check(x);

return 0;
}

GCC4.4.1で両方右辺値になるんだけどなんで？

テンプレートの T&& は T& によりマッチするから

>>172
言語機能がライブラリに依存するのは美しくないっ！
bad_allocとか

>>177
おい、C++0xに美しさを要求したいのか！？

>>173
>>175
ttp://cpplover.blogspot.com/2010/01/c0xno0x.html
ここを嫁

Javaに比べりゃC++の言語コアとライブラリの癒着なんて大したことない

ライブラリでできることはライブラリでやろうぜ！
てな意気込みでもあるの？

Javaは「言語のこの機能を使うには、このインターフェースを継承したクラスを使います」
みたいなのだらけ

それはいい面にもなるんだけどね

>>183
どの辺が？

>>インターフェースを継承
このパターンは駄目だって、
何となく世間が気づき始めてる今日この頃

>>183
いい面とかねぇだろ

java.io.Serializableとか気持ち悪くて仕方ない

>>179
本、頑張ってくれ

>>188
いや、俺は あの人じゃないよ。
いつも例のブログを流し読みしてるだけのタダの人。

はいはい

volatileが何の役にも立たないとか言ってる奴は信用できない

まあハードウェア寄りじゃない分野からみればそんなもんだろ

単に使うだけならそれでもいいけど
規格を語りながら「私は使わないので役に立ちません」じゃ話にならない

>>191
俺は使ったことないけどな！

>>190
そういうちょっとした発言が人の神経を逆なでしているんだよ。
失礼な。態度を改めろ

はいはい

あくまで規格上は volatile で規定されていることだけでは
全然ダメ(=使い物にならん)ってだけのことだろ。

実際の処理系では使えるにしたって、規格側から言及できることは何にもない。

そんなのは立場の問題に過ぎない。

1.9　Program execution
8　The least requirements on a conforming implementation are:
. Access to volatile objects are evaluated strictly according to the rules of the abstract machine.

この文言だけでvolatileの有用性は十分だろ
何が不満？

さあ？
ポータブルなコードが書けないことくらいか

>>196
死ねばいいのに

どちらかの寿命が尽きるまでは辛抱だよ

もう [[volatile]] でいくね？

はいはい

じゃあ一緒に死のうか。

Javaくらいシンプルな文法で速度重視の言語が欲しい

Pythonくらい楽で速度重視の言語がほしい

Java/C# は仮想マシンに。Python は実行時インタプリタにめんどくさい部分を押しつけているからねぇ。

Javaはネイティブコードにコンパイルできるがな
実際、それでJNode OSが開発されてるし

operator newさえあればJavaがいいんだが

型がautoばっかりになりつつある

Comeauですでにautoを使い慣れている俺は逆にあまり使わない状況にある
可読性が落ちる気がするんで使ってるのはiteratorくらいだ

なんでauto_typeとかにしなかったんだろう

>>212
新規キーワードの導入を嫌ったんじゃね？

どうせほぼ別言語になっちゃうんだし、
今のうちに多少新規予約語を追加して
欲しい気もするが。

コンセプトには予約語5つも投入してたのに……

autoってB言語でスコープ限定を意味するキーワードだっけ。
C言語でも予約語扱いでリザーブされてたから流用したということかも。

予約語自由に追加していいなら他言語に合わせてvarにするよな
絶対無理だけど

>>216
> 予約語扱いでリザーブ
autoはリザーブでもなんでもなく、
普通に使われる位置にいただろ。

現実に使っている人は見たこと無いけど。

>>217
予約語が選べたとしてもdecltypeみたいにいまいち直感的でない名前になると思う。
少なくとも他の言語に合わせてって理由で決まることはないんじゃないかな。

キーワードの採択の基準について詳細は不明だけど、

例えば
decltypeについては期待されたキーワードはtypeofだったけど、
typeofが既にベンダー独自で実装されてたりして、
しかもちょっとずつ異なってたとかいうことで
混乱をきたさないように新たに命名されたとか聞いた。

もう一つ、nullptrに関してだけど
現実にあるソースファイルをgrepして殆ど使われていないのを確認してから
nullptrという名前で提案したとも聞いた。

std::autoとか
予約語にNSはちょっと無いか

>>220
案外nullptrは居なかったのか。
よかったよかっった。

>>220
しかしそのルールに従うと、予約語は
毎回誰もつけないような微妙な名前を選択することになるわけで

より大勢の人に使ってもらう名前なのに互換性の方を重視するのは
何か違う気がしないでもない

つかベンダ実装なら __typeof__ とかにしとけよ、って話だ

>>223
> ベンダ実装なら __typeof__ とかにしとけよ、って話だ
それは確かに正論。勝手にやりやがって。。。
しかし今更文句言ってもどうしようもあるまい。

> より大勢の人に使ってもらう名前なのに互換性の方を重視するのは
> 何か違う気がしないでもない
その気持ちも分かるが、過去との互換性を切り捨てて
多くの語を予約語にしたら、D言語の悲劇みたいなことに
なりそうな気がしてならない。

>>218
auto int hoge=3;
auto fuga=4;
両立できないことも無いかな。

>>224
D言語の悲劇ってなんぞ？

D言語の悲劇は仕様が全然安定しない事じゃないの

>>227
多くの語を予約語にしたらって言ってるよ

ごめんそんなに深い意味で言ってなかった。
ただ言いたいことは
「C++に似た構文で、C++との互換性が無いように理想を追求したら
現実的に使ってない言語になっちゃってる」
ってことです。
そんなつっこまないでゴメン

×現実的に使ってない言語
○実際に使われない言語

まあこれが言語としての悲劇ではないかと。
C++0xがそうなったらもう目も当てられないでしょ。

Dはむしろ、C++に互換性の縛りがなかったら
どこまで進めるかを試す
実験言語になってる感があるなあｗ

現状のメタボ C++ からの離反〜世代交代は
難しいが誰かがやらねばならぬこと

GC導入とかほざいてるアホじゃなく
ken なみの天才を待つしかなかろう

>>227
Dの悲劇はライブラリが中途半端だったことじゃないか
Cのが使えるからって楽天的になったのが仇になったかと

そこはC++とそっくりだと思う。
Dも悪いとこまで見習う必要はないのに。

どうせ仕様が固まってないんだし今からでも・・

DよりAのほうが好きだな俺は

Dの悲劇もC++の悲劇ももうどうでもいい。
これからはGoの時代が始まる。

おまいらC++1xの話をしるｗ

ラムダ式って関数なの？オブジェクトなの？

>>239

＞ ラムダ式って関数なの？オブジェクトなの？

前スレで関数オブジェクトだとレスがあったな

>>238
2016以降かよ

0x2000+0x10=8208

びっくりしたよオレのPentium100MHz、gccで短いC++ファイルを
コンパイルしたらコマンドラインに戻ってこなくなちゃったよ。
つぎの規格ではコンパイルが速くなるようにしてくれよな。

>>243
どんだけ重いソースをコンパイルしたんだ。
バグじゃね？

それともその低スペックCPUでspiritばりばりの
ソースでもコンパイルしたのか？

Pentium100MHzってヘタしたら
四半世紀前のアーティファクトじゃね？
あんま無茶いうなよ

10数年前にそれより低いスペックのPCで
プレステのゲームをC++で書いて
問題なくgccでビルドできてた。

ゲームでC++って
Unrealあたりで世に知られるようになったんだよねえ
それより前にやってたのか？

やってたやってた。
Formula OneってゲームがC++で書かれていて、
その影響で当時俺が勤めてた会社でもC++が一気に普及した。
C++でどこまで作れるのかといういい判断材料になった。

>>243-244
どうせヘッダファイルが循環参照してるんだろ

246じゃないが、俺もその頃ゲームでテンプレート使ってた。
最適化最大にしたら1ファイルコンパイルに40分以上かかったことがあったｗ

VS2008はマルチコアCPUだとコンパイル早いしな

JISの訳文って何のために存在してるの？
http://www.kijineko.co.jp/node/680

おまえは原文で全部よめるんだね。うらやましいよ。

>JIS X3014には誤訳がところどころあることは知っていましたが、これはあまりにも酷いですね。
そこで思考停止する秀才君しかいないのが日本の不幸。

じゃあなに？　無償で修正してくれるの？
原文読んだ方が速いだろ。

> そこで思考停止する秀才君しかいないのが日本の不幸。

JISC に対してリアクション起こしたり、類例を集めてバグDBを作ったり、
という行動を起こすのが正義、ということ？

>>254
お前もそう変わらねえよ

無駄してる部分もあるかもしれんけど母国語で規格を表現しておくのは良いこと
関数、引数、遅延評価等が音素表記だったらと想像したら悲惨だろ？

輸入語過多な資料で進化阻害してる母国語を使ってる他国の惨状と比べれば日本や中華は頑張ってるよ

さすがに日本語のJPEG規格書がDCT変換の係数を間違えていたのには引いたがな

一方 MSDN は両文併記に踏み切った

>>260
これってよく見かけるけど、
元ネタは何？

一方○○は○○った
（たいてい単純でバカっぽいが確実な解決策を示して）
の元ネタのことを言ってるなら、
「一方ソ連は鉛筆を使った」というネタが元ネタ。

>>262
ありがとうございます。

JISCが酷い訳をしてると思う人が修正を要求することができる
仕組みはあるの？

規格書読むような奴が
英語出来ないとかありえないから

ありうるぞ
だって俺そうだし

俺もプログラム言語関係のものは読めるが、それ以外の読み書きも会話もまるでできん。

JISCって自分のところで訳しているのかなあ。
規格策定作業はたいてい外部の委員会に委任しているから、
そっちに言った方が早いのかもしれない。C++だとitscjか。
もっとも、そっちもそっちで窓口なかったりするが。

error(266): expert programmer who cannot read English exception

C++創ったビョーン(?)博士の英語に比べたら
規格書の英語は解りやすいべし

ビョーン(?)博士の動画の英語は聞きとりやすい

英語の出来ない人って一体どうしているん？
十年前の書いている内容よりも難しい日本語に訳された本とか読んでいるの？

日本でstd::string()がコンストラクタ呼ぶコンパイラ作ったら規格違反なの？

そのコンパイラが何の規格に合致したものかによるだろ

日本でC++コンパイラ作っている奴いるの？

富士通製のがあるな。

>>276
そんなのあるんだ。
初めて知ったっす。

この質問が出ること自体、背景に極めて憂慮すべきものがある

>>277
スパコンやってるとこはみんな作ってるよ

Embedded C++ みたいなぱちもん作って禿直々に pgr されるような日本メーカーなんて。

Embedded C++って結局どうなったの？

公式HPの最終更新が2002年ってあたりで推して知るべし

もうプログラム言語で会話しようよ

Embedded C++の発想は正しい

だとしても、どうもその発想をうまくまとめる能力が全然足りなかった気がする。
もっとも、こんなのが流行らなくて本当によかったと思う。

ttp://books.google.co.jp/books?id=keuzQgAACAAJ
ebC++を批判してたけど、当時の目的や制約について触れない一方的なものだった。
この本自体は、単刀直入で大好きだ。

ttp://books.google.co.jp/books?id=nPZaPJrw_L0C
こっちは、better Cとして、当たり前の工夫のなかに書いてあった。

どうでもいいけどこの本、第1版が、
Programming embedded systems in C and C++
で、第2版が
Programming embedded systems: with C and GNU development tools
なんだよな？

当時のレベルから見ても残念な内容に思えたけどな

お前の思い込みに何の意味が

思い込みじゃないから廃れたんだろ

廃れた理由がレベルが残念だという推論はおかしい

禿のお言葉
http://www2.research.att.com/~bs/bs_faq.html#EC++
>What do you think of EC++?
>(略)
>To the best of my knowledge EC++ is dead (2004), and if it isn't it ought to be.
私の知る限り EC++ は 2004 年現在で死んでいる。さもなくば死ぬべきである。

Embedded C++はコンセプトが色々と残念だったと思うけどな。
例外処理とか実行時型情報を落としたのはまだわかるが、名前空間とか型変換演算子とかを
削ったのはセンス悪すぎだろ。

C++0xスレでコンセプトとか言われるとややこしい

お前ら、C++0xの策定状況をどこで知ってるの？

とりあえず N3000 読めば?

日本製の「コンパイラ」って、フロントエンドは EDG のもので
自社製 CPU のためにバックエンドを移植しているだけだろ？

だから C++0x の規格会議にも出席できない。するきもない。
パーザーをありがたくいただくだけだから。

その代わり、金出して買っているから規格書とのズレには病的に細かい。

ルールが不便ならルールを変えましょう。って世界と
使いづらくてもルールに従いましょう。って日本の文化の戦いなんだな。
世界からは相手にされていないけど。ドラフトの曖昧なところをチェックしてくれる
便利な奴らとしか見なされていないけどな

なんでPHPがはやってるんだろう

馬鹿向けのものほど流行る

独自仕様のC++で不便でも変えられない
コンパイラを大きな顔しててリリースし続けている
世界もありますよね。そんな世界です。

>>298
このメンタリティこそC++ユーザー

おしり

>294
委員会メンバでもなきゃ↓からじゃね？
http://www.open-std.org/jtc1/sc22/wg21/

後は、
http://cpp-next.com/
http://herbsutter.wordpress.com/
comp.std.c++ (newsgroup)
でも情報とれるかもね。

美少女中学生のおしり

しまうまのおしり

C++Oxって言ってるあほがいた

Odakyu++OX

C++0x0

C++20xx

>>260
それは機械翻訳じゃないのか？

xxクラゲ

メメクラゲ？

メノクラゲじゃないかな？

>>309
伝説の宇宙天啓データベースってやつですか

まさかネジ式を知らん奴が居るとわな...。

「ねじ式」

ねじ式 - Wikipedia
ttp://ja.wikipedia.org/wiki/%E3%81%AD%E3%81%98%E5%BC%8F
こんなんしらねがった

まぁ知らんのなら仕方ねーが今回は赦してやっちゃうる
次回から真面目にやりよーにの

美少女中学生なら知らぬのも無理はない

このスレの平均年齢、かなり高いねぇ

そーでもない

井上雄彦なら単行本回収させるレベルだな

○テンプレート可変長引数さん
ってどうやって使えば良いんすか？

自分ではメタプログラミングが使いこなせない俺には
まああまり関係のない話ではあるが。。。

逆に今まで何を調べてきてその結果何が分からなかったのか説明してもらおうか。

>>323
とりあえずWikipediaを読んだ。
もはやtemplate<〜〜>って書いた部分と実装の中のどこの部分が
どう対応しているのかもよく話カラン買った。

一見便利そうで最悪な使い方としては多重継承の中継クラスを可変にするとか

うぃきぺの例は
printf(const char* , int, double, float)
で呼び出されたとき再帰で
printf(const char* , int, Args... args) //Args = {double, float}
printf(const char* , double, Args... args) //Args = {float}
printf(const char* , float, Args... args) //Args = {}
printf(const char*)
になるんだよな？

かかかかか　　カオスじゃー！

まあランダムよりはましかな

正確にはこうかな
まあ一緒だけど

printf<char*,int,double,float>(s,i,d,f) //T:int Args:{double, float} value:s args:{d,f}
printf<char*,double,float>(s,d,f) //T:double Args:{float} value:d args:{f}
printf<char*,float>(s,f) //T:float Args:{} value:f args:{}
printf(s)

char*のconst抜けた

tmp=a;a=b,b=c,c=d,d=tmp;みたいなコードを楽に記述するためのswap書いてみた
交換回数は最小だと思うけど関数呼び出しやらなんやらで遅そう
(Args&...にするのにしばらく気付かずハマった)

template <typename T> T& rolswapimpl(T& a,T& b){a=b;return b;}
template <typename T,typename... Args>
T& rolswapimpl(T& a,T& b,Args&... args){
a=b;
return rolswapimpl(b,args...);
}
template <typename T,typename...Args>
void rolswap(T& a,T& b,Args&...args){
T tmp=a;
a=b;
T& last=rolswapimpl(b,args...);
last=tmp;
}

swapというよりも回転？rotationかな。

全部同じ型なんだったらinitializer_list使った方がいいよ

>>325
ポリシーを提供する基底クラスを可変個設定できるとか
考えただけでも吐き気がしますね

俺、今の仕事が終わったら
自作マシンを組み立ててlinuxを入れてC++0xを楽しむんだ・・・

mingwじゃだめなのだ。configureの野郎が反抗的だ。
winでgcc4.4.3なんて、それこそ無駄な努力ってやつだ。
winはおとなしく古いgccで遊んでいればいい。

windowsは即ち禅なり。
autoconfigは刹土の理なり。
automakeは度脱の一切なり。

如来智慧法界ニ遍ス。

嗚呼俺は融けてゆく。

4.5入れるのか

autoだけ使用ってアリですか？

ant

日本語版 Wikipedia に
>仮称は混乱を避けるため C++0x が維持されるが、その代わり 0x の x は16進数を表すこととなった。
とか、しれっと書いてあるからおいおいと思ったら禿のサイトに本当にそう書いてあってﾜﾛﾀ。

>>339
おいおいおいおいおいおいおいおい
いい加減にせぇwww

びよーんのそこに痺れる憧れるぅ

リンカの改革にも着手してほしいっス
関数にハッシュ仕込んで類似コードの流用圧縮くらいそろそろ実現してもいい頃だと思うんだ

linuxにはgoldがあるからいいよね…

ハッシュ？

関数イメージをハッシュで一致するのかチェックして
共有しようと言うんでしょ。
違う関数は別のアドレスでないといけないんではなかったか？

>>339
0x だから 2000年の最初から確信犯だったとしか

このスレがどれだけ影響力があるかだな。
禿って呼んでる人がいるのも知ってるだろうね。

ないだろ。
わざわざご注進する馬鹿がいるとは思えん。

ありえねーな

You are called by the nickname of baldness.

何日後のHPの反映されるかアクセス増えるなきっと。

このスレのスレ番も
C++0x 09
C++0x 0A
みたいにいくのか？

C++0
ここまでで parse error だろ

次々スレまでに決定するといいな

それなら次スレはC+ +0x9に決めたから。

え？

C++09だろｊｋ

http://www.open-std.org/jtc1/sc22/wg21/
News 2010-02-18: The 2010-02 post-Santa-Cruz mailing is available
News 2010-02-18: The C++ Standard Core Language Issues List (Revision 68) is available
News 2010-02-18: The C++ Standard Library Issues List (Revision 69) is available

ドラフトは N3035

乙。
しかし何でサンタクルーズでやったんだろう

多分pre-Pittsburgの書き間違いだな。

Pittsburgh

#ifdef __cplusplus

みたいな感じで0x対応だよって教えてくれるマクロは無いの？

#if __cplusplus > 199711L

>>357-359 "2010-02 pre Pittsburgh mailing" に修正されたよ。

ここで次のCD出して投票に掛けて、8月のスイスでコメント審議して
FDISへ…という最短コースでも刊行は来年の春頃か。正念場だな。

n日本人にはかんけいないだろ

S式, λ計算, n日本人, ...

さっき喫茶店行ったら
近くに金髪の外人姉ちゃんが座って居て
かわいいと思ってたんだけど
2時間くらい大声でしゃべりっ放しでうざかった
ただのおしゃべりおばさんだったのかも試練

右辺値参照ってサイコーにクールだな

そうでもない

右辺値参照なんて本当ならコンパイラが自分で解釈すべき問題だと思うんだよな

勝手にムーブセマンティクスとかありえんだろ

どういう動作をディープコピーとするかがプログラマの判断に委ねられてるから仕方ない。

>>370
戻り値最適化とか、あきらかな場合は現行のコンパイラだってちゃんと
（コピーコンストラクタの省略とか）やってるじゃん。

俺がまだ「猿状態」の頃で、コピーコンストラクタでいろいろ重要な処理をやらかしていた頃の
古傷をえぐられた！

>>374
ご、ごめんよそんなつもりじゃあ・・・。。。

ところで、右辺値参照デフォルトコピーコンストラクタとか右辺値参照デフォルトコピー演算子とかあるのかな？
便利そうではあるけど

>>376
N2904

新しい提案が通りますよ

ttp://sub.spc.org/san/docs/BS6008.pdf

さすがエゲレス人・・・ネタだよな？

新しいコンテナのようなもの

decltype(*this)って書くと参照型になるみたいなのですが
参照じゃない型がほしい場合はどう書けばいいんでしょうか？

std::remove_reference< decltype(*this) >::type

でもthisの型を欲しいときってどんなときだ？
decltypeはRTTIじゃないぞ。

なんだか良く分かりませんがthisからabstract factoryすればいいんじゃないんでしょうかね

>>383
WTLとかATL使っていると
thisの型がむちゃくちゃ複雑になったりするんです

unique_ptrのdeleter指定のしかたが微妙

shared_ptr互換の方が良かったのか？
unique_ptrの機能が劣化するけど。

>>385
よくわからんな。
いくらテンプレートや多重継承を使おうが、
thisの型は、クラス名だけで参照できるだろ。

それと、コンテキストと用途によっては、std::remove_cvも必要になるかも。

>>385
しかしVC10ではdecltype(*this)はエラーになる罠

本当だ。
しかも普通のエラーじゃない。
これ、検索したけど、バグ報告されてないね。

たとえば、こうするしかないのかね。
std::remove_pointer< decltype(this) >::type

ほんとに検索したのか？
http://connect.microsoft.com/VisualStudioJapan/feedback/details/533849/decltype-this

日本語の方はしてなかった。

>>389
VC blogのコメント欄に書かれていたが
製品版でも直らないらしい

まじかよ。クソだな。

つってもnullptrも実装しないとVC blogでMSFTが言ってた癖に実装したし
公式の発言ではありません、程度には受け取っておけよ

nullptrは昔からあるからなぁ…

ぬるっぽ

インターフェースと実装を分離したいと思ってて、pImplイディオムを利用しようと考えています。
一般的なpImplイディオムは、コンストラクタでimpクラスをnewしていますが、
いま設計しているpImplを利用したクラスは、何度もインスタンス化されるので、newしたくありません。
また、Factory関数を作って、利用者側にわざわざ呼ばせたくありません。

つまり、クラスの利用者から、実装クラスを隠蔽し、かつインスタンス化時に何度もnewしないような方法はありますでしょうか？
（妥協して、メンバ変数だけインターフェース部に持ってきて、実装クラスをSingletonにする、など考えてみましたが、案の定イマイチでした）

何度もっていうけど、１オプジェクトで１回くらいnewしたっていいんじゃないの？

実は、このimplを利用したクラスのオブジェクトを100個程度、リストで保持するクラスがあるので、
この保持するクラスをインスタンス化すると、単純に100回程度newが走ってしまうので、どうしようかなと。
保持するクラスのほうは、わけあって変更できません。

newって重いのか

newしても全部使われないからあまりnewしたく無いって話なら
実際使われる時にnewすれば

100個程度なら問題ないだろ
10000のオーダーなら問題になるかもしれないが

何と比べてnewの何が悪いと言っているんだ？

new以外を使うのは、newで書いてみて、何か問題が発生して、それがnewのせいであることを確認してからでも遅くない。

まあ、newが問題になることなんて絶対に有り得ないから、newで書いてみることは無駄にならないよ。安心していい。

つーかスレチ

つーかマルチ

100個程度じゃー、どうでもいいな。

自前で専用アロケータを作れば高速になるよ。

boostでも使え
自作は遅いし不安定。俺だけかも知れんが

自前で専用アロケータ作って本当に高速になったか確かめてみた？
new/deleteより遅いの作って満足してる奴がたくさんいそうな気がする。

自前で専用アロケータが本当に必要なのかから
立ち返って考えるべし。
あと、後にメンテナンスするメンバーや後輩のことを
考えるべし。

n 個の pimpl クラスを作った時に n 回増えるだけ。オーダーは変わらない。
実装側クラスのコンストラクタが複数回 new するなら、その回数に比例してどうでもよくなる。

それでもデフォルトアロケータの動作回数を抑制したいなら、悪質な手法としては
struct implementationOfAClass;
struct AClass { AClass(); private: char implbuf[ 100/*MAGIC NUMBER!!*/ ]; void doSomething(); };
AClass::AClass() { new (implbuf) implementationOfAClass(); assert(sizeof(implbuf) == sizeof(implementationOfAClass)); }
void AClass::doSomething() { reinterpret_cast<implementationOfAClass*>(implbuf)->doSomething(); }
のように new の配置構文を使うようなのもある。

アセンブラでゲーム作ってた頃は結構あったらしい。pimpl としてではなく、多態の表現として。
C の頃はたまに見かけた。
関数ポインタをいくつかと適当なサイズの char 配列を持った構造体をを作って、それを配列にしてプールアロケータ的に使ってた。
さすがに C++ では見たこと無い。

最大個数が分かってるなら、プールアロケータ使うのもありかな。

>>400
そのnewが総実行時間の何％を占めるか見積もるか計測してごらん。誤差のレベルだよ。

シューティングゲームの弾丸とかでnew/deleteする、とかじゃないとコストは気にならないよな

確かGoogleも独自のアロケータ作っていたはず
tcmallocとかいう名前だったような

>>415
プールを使うと劇速だね。

東方厨乙

コンシューマゲームでnewを自前で書かないなどありえない。

tcmallocって一部アセンブラで書かれてて
64bitで使えなかった記憶が。
今は使えるのかな。

マルチスレッドで高速なアロケータ他にあったら教えてくれい

>>419
> コンシューマゲームでnewを自前で書かないなどありえない。
ありえるだろ別に。

もっとmake_sharedする

>>421

>>419
まあ同意だが、その場合は速さ目的というより
割り当て場所や容量を細かく制御するためのカスタムアロケータ
が多いな

デバッグ時はメモリがたくさん使えるからこっちから割り当てとか、
あんたんとこのモジュールはこのサイズ内でやりくりしてちょとか

リアルタイム性が必要とかでO(1)アロケータにするとかなら理解できる

>>424
それもあるけどデバイスの仕様からやらざるをえない場合もあるね

すれ違いの話題はストップ！

不細工でもいいんだけど、closure ないとやってられない
つか、始めて業務用の開発で使ったが、おまえら closure なしでよくやってるな
感心するわ！！！
で、いつになったら標準になるんだ >> lambda/closure

だっていらないもん。
お前のオナニーに興味ない。

ラムダは次期標準
クロージャはファンクタで代用しろ

>>430
だからいつになったら決まるんだよ > 次期標準
> クロージャはファンクタで代用しろ
結局そうなるんだけどねorz

GCCならラムダはもう使えんだろうがカス

どこに向かってんだこの言語

宇宙

究極

正道から(1+i)/√2方向

>>436
納得した

45度か

>>432 標準にでもなってくれなきゃ 4.1.2 以上を使えない身分なんだが…

ああ、すまん
「4.1.2までしか使えない」
が、正しい

身分を上げる努力ぐらいしろカス

>>441
即座にプログラマを辞めるくらいの
気迫が必要では？

というか身分を上げるというのはコーダを辞めることだよな

ラムダ式気持ち悪りぃ
↓
ラムダ式って便利じゃね？←今ここ

↓
ラムダ式んぎもっぢいいいいいいいいい←そのうちここ

今日はずっとλ式でオナニーしていました。
ただλ式をするだけの主人のいないペットの様でした。

ブースとラムダであと１０ねんたたかえる

boostのlambdaは動的に関数作るから遅すぎ。

なんだろうラムダ式にすごい可能性を感じる
↓
ラムダ式使いまくり
↓
いつも通りリファクタリング
↓
あれ、ラムダ式いらなくね？
↓
コードからラムダ式全部消える←いまここ

ホント？
少なくともGUIライブラリ（Qtとか）はラムダ使いまくりで安定しそうな

使用する場所と宣言する場所が近いってのは見やすい

Pythonistaな俺はラムダというより主にローカル関数として使いたい

やめろ
ちゃんと本物の関数を使いなさい

何も知らない人が疑問に思いました。
ラムダ式って自分自身を呼んだりできんの？
再起ぽく
名前無いからむりなのかな

変数に入れないと無理だな

それも、autoは、初期化に名前が出てはいけないので、使えない。
lambdaは、それぞれユニークな型をもつので、仮にdecltypeに使えたとしても、
変数として束縛するのには使えない。
std::functionしか選択肢がない。

Unified Function Syntaxの行方が気になる。

>>454
できるよ。不動点だとかYコンビネータだとかでググってみ
ちょっとややこしいけど

単純型付きラムダ計算だと不動点作れないよね
System F だとできた気がしたけど、依存型があればいいんだけ？

>>449
正しくない使い方を乱用していただけかと

gnu++0xを使っても構文誤りにならない統合開発環境ってありますか？

GCCオプションの話？

オプションをつけてC++0xの構文を書いたときのはなし。

>450
オブジェクトの生存期間の管理はどうするんですか？

>456
N3043

>>463
よく嫁アホ。
キャプチャリストが空な場合、普通の関数ポインタへの変換を提供しようではないかと提案しているのだ。
お前どうやってキャプチャせずにその変数を使うのだ。
まかさ、グローバル変数を使えというのではあるまいな？

これで晴れて空キャプチャラムダをqsortの引数に渡せるようになるんだな
俺の考えは正しかった

関数ポインタって最適化や分岐予測の障害になるだけじゃないの？
関数ポインタが返るlambdaってやだなあ〜

そもそもポインタは最適化の大敵ｗ

よし、じゃあエイリアスの発生しないポインタを考えるんだ

>>466
あくまで関数へのポインタに変換可能というだけで、
通常は他のラムダ同様に関数オブジェクトとして扱われるのでは？

unique_ptrはCRT境界を超えても大丈夫なスマポとしては使えないんだね

std::sort使えばqsortも関数ポインタも使わなくていいでしょう。
そろそろCライブラリは忘れていいんじゃないか。

Cのインターフェースは今後も永遠に重要な位置を占め続けるし
そこに簡単にアクセスできるのがC++の最大の長所だ
忘れるなんてあり得ない

Cのインターフェースじゃなくてqsortの立場を言っているんだ。ちゃんとレスを読め。

またこの流れかよ

由緒正しいCの標準関数ですよ
std::sortなんかよりきっと長生きする

主張としては悪くないのに、子供じみた一言が「この流れ」を作る

お前ら難しそうなこという割りにたいしたものつくれる感じが全然しないな

確かに大学で単位取るために簡単なコンパイラ作らされたけど大して知識とか技能が得られたわけじゃないなー

>>477
「そう」とか「感じ」とか、ふわっふわした言葉でいわれてもな。

顔真っ赤ｗ

へえキミの顔真っ赤なんだ。

由緒正しいCとは、現行C99である。
全時代的C言語から分離したC++におまけ程度で付いてきた*.h(<c*>)標準ライブラリなど由緒正しいもクソもない。

http://0xcc.net/blog/archives/000052.html

qsortなんて遅い関数使ってんの？

そうだねstd::qsortだね

まーアプリケーション自体がクリティカルでなくて、更にソート関数もとんでもなく重かったりしなければstd::qsort使ってもいいと思うよ。
ただlambda式で気軽にファンクタも作れるしstd::qsortを使う理由もない。

お前らの関数ポインタとqsortへの憎しみは異常
何があかんのですか

知能が低いんだろ

signal はどうよ

いいよ。

右辺値参照でコンストラクタ走らせるときは、&&修飾なんてせずに
コピーコンストラクタがconst referenceなのに対して右辺値参照でただのreferenceという区別を付けるだけじゃ飽き足らなかったの？

すでにあるコードとの互換性をどうするつもりだ？

const referenceじゃなくてreferenceでコピーコンストラクタ書こうとするとエラーでなかったっけ？

ならないけど
コピーしたいのに破壊的コピーされたらかなわん

一時オブジェクトを渡せないだけだろ

X &&func(X &&x) {return x;}
X &&func(X &x) {return x;}
ってやると起こられるんだけどなんで？
std::moveってどうなってんだろ

自己解決した
ソース見たらstatic_cast<X &&>してたでござる

rvalue referenceは、rvalueでしか初期化できない。
rvalue reference自体は、lvalue。
static castでrvalue referenceにキャストすると、rvalueになる。

>>494
>>493が言いたいのはそういうことじゃねぇだろ。

>>495
それって、こうしたらやばくね？
X& a=func(X());
a.f1();

>>499
それ、aの初期化の時点でコンパイルエラー。
rvalue referenceでlvalue referenceであるaの初期化はできない。

もちろん、funcの戻り値の型をlvalue referenceにしてしまえばコンパイル可能だけど、
当然お前の言うようにそれはやばい。

>>500
なるほど。
暗黙キャスト変換を作ろうとして悩んでたんだけど。
template<class T> inline T&& anmoku_cast(T&& a){return a;}
template<class T> inline T& anmoku_cast(T& a){return a;}
と２関数でオーバーロードすれば安全なのが作れるのかな？VC10待ちなのね。

>>591
std::forward

gnu++0xがnullptrがつかえないのはまだ実装されていないからですか？

nullptrと0は違うものなのか？

int x = nullptr; // error

引数を整数とポインタでオーバーロードしてもいいんですね！

>>502 サンクス　おいら宛だと気づくに時間かかった。
std::forwardググって見た。テンプレートだと、&&で&&と&の両方掴めるって事なのね。
forwadの使い方研究してみる。rvalueは深いですな。
とりあえずanmoku_castはstd::forwardで希望通りの動作ができることは理解した。

すみませんthreadについて質問なんですが
__thiscallであったり返値がある関数ポインタでスレッドを起動することはできないのでしょうか

>>508
Windowsの板か、VC++のスレに移動してください。
このスレは新しいC++規格を議論するスレです。

ラムダの変数キャプチャとキャプチャされた変数の寿命に関して
くわしい資料てどこを見ればいいですかね

>>510 >>1

>>508
このスレで聞くって事はstd::threadかな。
なら、std::bindを使えば何とかなるかも。
boostでしか使ったこと無いけど
thread t(bind(&func));
でどうにかならないかな。

>>509
>>512
そうです0xで標準化されたthreadについてです

チュートリアル的なサイトを見て回ったのですが
返値がvoidでメンバ関数でない，であってもstaticなケースばかりなので
出来ないのかと思ったのですが
やはりbindでラッパしないといけないのですね
ありがとうございます

threadに渡すのは関数オブジェクトだから。
関数オブジェクト以外のものを渡すときはbindを使うのが前提だからbindを使うのはなんら問題ない。

ラムダでキャプチャして渡すとか？

お前ら分からないなら答えるなよ。

threadのコンストラクタや、bindのコンストラクタのとる関数オブジェクトは、
20.8.2 Requirements [func.require]に規定されているように呼び出される。
つまり、あるクラスTのメンバ関数へのポインターならば、一つ目の引数が、Tのオブジェクトとして呼び出される。

それ以外の場合、
INVOKE(f, t1, t2, ..., tN)は、f(t1, t2, ..., tN)となるので、
この構文で呼び出せる関数は、すべて呼び出せることになる。

threadの関数オブジェクトの戻り値は無視される。

__thiscallについてはMSDNで「__thiscall 呼び出し規約」検索して。

コンセプトさんなんで死んでしまったんや

違うわ!コンセプトさんはまだ死んでなんかいない、眠っているだけよ!

何年後に起きてくれるんだろうか

現在conceptは深海の都ルルイエで深き者どもにかしずかれ死よりも深い
眠りについているが、星辰が然るべき位置に戻りルルイエが再び浮上する
ときconceptは甦り、地上の全てを支配すると信じられている。

次の標準は
C++2xって名前にするべき

Jeremy Siekがconceptのlectureやるってさ。
http://www.comlab.ox.ac.uk/projects/gip/school.html
Jaakko Jrviも去年、conceptの論文書いてた。
Douglas GregorはAppleで何やってるか分からない。

Conceptさんってそんなに大物なのかw

>>2
○コンセプトさん
ついに一度も登校することなくお星様になってしまった。
この事件によって学園に激震が走り、入学式が一年延期になる事態に。
彼女の再起はあるのだろうか。

2：デフォルトの名無しさん ：sage：2016/07/07(木) 02:11:53
C++学園の人々

○コンセプトさん
ついに一度も登校することなくお星様になってしまった。
この事件によって学園に激震が走り、入学式が十年延期になる事態に。
彼女の再起はあるのだろうか。

微妙に愛○様連想させるからぎょっとした
元ネタあるのかと思って検索したらこのスレと
どっかの糞ブログしかひっかからないので安心した

http://pc12.2ch.net/test/read.cgi/tech/1232460649/11
・こんせぷと！
　テンプレートひきすうをせいげんするぞ！
　constのつけわすれでエラーメッセージが1000ぎょうもでなくなる！
　でもむずかしすぎてだれもじっそうできてないよ！　

http://pc12.2ch.net/test/read.cgi/tech/1245092251/5
○コンセプトさん
学園のアイドルだが、入学してから一度も登校していない。退学の噂も。

全力でコンセプトに体当たりしてみてー。なんかコンセプトっぽい機能のある言語ない？

>全力でコンセプトに体当たりしてみてー。
この一文でまず弱いものいじめに加担するDQN思考があるのではないかと疑ってしまった。
コンセプト自体は静的多相性のインターフェースみたいなものなんでそういうのを探してみてはどうだろうか。

あいつの事はもう忘れろ

>>529
haskell の type class?

new autoきめえ

寄付のお願い
http://cpplover.blogspot.com/2010/03/blog-post_09.html

なんなんだよ、この人は。

働け

俺はある人から聞いた例え
　> 「バットが大好きでバットに詳しいが打たない野球選手」
　> に金を払うヤツはやっぱりそうそう居ないんですよ。
　> バットは使って何かを生み出すことで初めて価値があるのです。
　> （例外的な人は、知識を生かしてバットを開発して「生み出せ」る人も居ますが）
　> このバットをC++に置き換えても、同じ事が言えてしまうのではないかと。
を使って働くように説得を試みたんだけど、
無理なんだろうか。。。

俺だってカネなくても好きなことだけやっていけるなら
カネなんていらないしそうしたいよ。


C++の知識がすさまじいことだけは痛感するが。

誰かが価値を認めさえすれば知識そのものに値段がつくけどね
その書こうとしてる本が誰の仕事を減らしてくれるのかってあたりをもっとアピールした方が
いいんじゃないかな。俺が満足してねーからって理由なら持ち出しでやるしかないっしょ

たんなる規格バカに金を払うやつ/企業はいないでしょ。

なにか新しいアイデアでも持っているならねぇ

あと、規格会議に夢を見すぎ。まさか五日間、C++ の規格の論戦でもすると思っているのだろうか。

数年を要するってあたりは少し悠長に構えすぎてるな。
ドラフトはドラフトでもCommittee Draftっちゅーたらもう終盤だよ。

本が出る頃にはコンセプトさん大復活で盛り上がってるかな

C++ 言語の規格制定に関与することに意味を持つ企業/組織が日本には無いのだから
無いものねだりをしてもしょうがないだろ。

ためしに英語で企画書書いて、どこか良いところに送ってみたら？

あるよー日本にも
悪名高い一部上場企業とか大学とか外資系とか公務員とか色々・・・
まあ当然あの人たちは英語で話すわけだが

http://cacm.acm.org/magazines/2010/1/55760-what-should-we-teach-new-software-developers-why/fulltext
> The professor is wrong in that you can't teach what you don't practice ...

ないよ > 542
悪名高い一部上場企業と外資系で、字句解析を自前でやってるところは無くなった。
大学と公務員のは子供の遊び程度。それも gcc の字句解析をいじくる程度。

さらに STL/boost 程度の規模のライブラリを自前で作れる組織が無い。
コードこねくり回さない人が増えたので（現場が必要とする）仕様の提案ができない。

切り札は、「仕様です」の一言でなぜか納得する日本人。
お上が決めたことには逆らわない。ってのが DNA レベルで組み込まれているんかね？

>>534
働きたくないことの言い訳じゃん

C++0xに関係ない話題になるとよく伸びるスレだなｗ

>>534
誰かうまい棒の山と中古パソコン送ってやれ。

自分が寄付するわけでもないのに騒ぎすぎだろｗｗ

間違って金が集まって、あの手口が儲かると思われると困る
自分だけが寄付しなければいいという問題じゃない

最近の人は、かつてネット乞食が流行したことを知らないのか

べつに流行はしなかった。

そうね。そして影響も悪影響もなにもなかった。

>>549
いや集まらないだろｊｋ

目標寄付額の目安：いくらあれば何ができるか

数十万円
生活費として、急場をしのぐことができる。このままでは生活できないという問題を、しばらく先送りにできる。
百万円
当面の生活費にあてることができ、生活が安定する。
＋数十万円
新しいハードウェアを購入できる。
＋数十万？円
C++標準化委員会の国際会議に、一回出席できる。

だぞ？

「本が出せる」がないのは何なんだろうな
持ち逃げする気まんまんなのかな

自明だから書いていないだけでは？

C++0xの本ならあと2年以内位にでたら俺は買う
寄付はしない

２年経つ前にはもっとまともな洋書が出てると思う

「本気が出せる」がないのは何なんだろうな
持ち逃げする気まんまんなのかな

に見えた・・・

>>553
数百万円＋数十万？円を最も好意的に解釈しても９９９万９９９９円だぞ？
おまえ確定申告してないだろ

>>559
何か勘違いしていないか

>>559がよく読まずにレスするやつだということはわかった

微妙

C++0x仕事に使えるのはいつごろになるかな

>>557
まあそうだろうけど、英語だと敬遠する人間もいるから、
そのまともな洋書がさらに翻訳されるまでのさらに数年間は
日本語で書かれた唯一のC++0x本という価値があると思う。
出来が良くても悪くても。

本ができたら金払うだけの価値は十分あるものができると思う
しかしそれに事前投資する気にはなれない

俺は事前投資する気はあるけど、如何せん俺にも金がない。

クソ本でもいいならそれこそ版変えただけでC++0x対応って帯付けた本とか
VS2010の本とか山ほど出ると思うぞ

どっかで記事でも書いて収入にすればいいのに。
もうCマガジンないから、ITサイトとかに。

俺が本出すから買ってくれ

寄付するための金をつくるためにみんなで0x対応の本を書こうぜ。

>>2-みたいな4コマかいてコミケで売ればいいんじゃね

企画としては悪くなさげだけど、どれだけ儲けが出るかっていうと…

そもそも実績がある人なの?

>実績がある人なの
ないよ。
あの Blog の雑文がすべて

本の虫の人のあまりの人気っぷりに嫉妬。
もう少し何かネタがあれば専用スレでもいけそうだな。

で、その大人気サイトの今日の記述が気になる：

> C++ のドラフトに相当大きな変更があるかもしれない
>
> まだ正式に決まっていないが、post-pittsburgh mailing では、
> 興味深い paper が公にされるだろう。
> 既存の C++ の根本的な定義を、大きく変える proposal だ。

4.5がつかえるTDMインストーラありませんか？

そんなものはない

今さらそんな大きな変更なんて…
まさか右辺値参照さん死亡か？

>>576
>追記：表面的には、なにも変わらない。

なんだ。でも将来的に影響することなんだろうか？

Cとの互換性をあきらめるとかじゃね

そんな馬鹿な
Cとの互換性はC++の存在意義そのものじゃないか

100%の互換性はもう無理だな

互換性なんかいらねーからもっと綺麗に書けるようにしろ

むしろC99/C1xの路線に異議を唱えて
K&R Cの正統な後継者として名乗りを上げる予定とかww

いまさらCとの互換性なんていらないだろ。
拡張子cでコンパイルして、cppからはextern"C"で呼べるんだから何も問題ない。

std::moveやらstd::forwardやらを使わなくても
自動的に適切に変換されるような仕組みになったりしてると・・・いいなあ

自動で適切に変換されるけどどうしても手動で変換する場合にstd::moveやらstd::forwardやらを使うんでないの？

rvalは地味だけど夢が広がる

とうとうC++1xになるとか？

>>582
> Cとの互換性はC++の存在意義そのものじゃないか
良いこと言った！
「Cとの互換性はもうない！」と言うやつも居るが、
それでもまだある方だよな。

Cとの互換性が無くても良いなら
もう別の言語にあっという間に人気とシェアを取られるだろう。

でもC++0xは、もはやCどころかC++03との互換性も、完全にぶち壊したけどね。
規格上、このコードが通らないせいで。

char * ptr = "..." ;

本の虫の人も知識がすごいのは分かるんだけど、
> 読書と、規格を学ぶことだけは、捨てることが出来なかった。
> そして、今、C++0xの本を執筆する機会を得たが、カネという難しい問題がある。
> カネなどいらないのだが、どうやら、日本で生きていく上は、カネが必要らしい。
> ともかく、何もしなければ破綻するのは確実なので、口座でもつくるか。
結局 働かないで好きなことだけして生きたいというのは、
ネトゲの中毒者とかと大同小異だと思うんだよねぇ。

>>592
そーいやそれが通らなくなるんだよな。

でもそれが通ったせいで、俺は最初の頃悩んだぞ？
何でこれがコンパイルエラーにならないんだろう？と。
やっぱりその変換は邪悪だ。

>>579
> まさか右辺値参照さん死亡か？
C++0xの意義がとんでもなく薄っぺらくなるな。

結局、
> 追記２：なんだか誤解を招く書き方だった。実際には、何も変わらない。
> ただ、規格の文面を変更して、規格を読みやすくするだけである。
ということらしい。

一般ユーザーには関係ない模様。
尤も、これからC++0xの本を書こうという人にとっては大問題だろうけど。

C++の一般ユーザーって言語仕様を完璧に把握してる人の事を指して言ってるんだよね。
それくらいこの言語は煩わしい。

uchar.hのように、まだ策定中のC1xから持ってきたようなのは
将来互換性を損ねる要因になる可能性があるな。

…と思いつつ久しぶりに向こうのドラフト見たら、C1xにもthread入るのか。

あとは _Template と _Typename くらいか… >C1x

>>596
じゃあC++の一般ユーザーじゃない人ってのは、
つまりは規格書を書いちゃうレベルの人達ってことか。

変態言語だな相変わらずに。

>>592
それは朗報だね。
そもそもそんなコードを書くほうが悪い。

が、しかし、すでに出回っているコードを、C++0x規格を厳格に実装したコンパイラに移植するのは、面倒だぜ。
まあ、当分の間、コンパイラは、回避方法を提供するだろうけど。

C++0x規格を厳格に実装したコンパイラがそもそも
出るのがいつになるのだろうか？ww

しかし今回、だいぶ、「まともに実装するだけの利点がない」機能が減るぜ。
たとえば、exportとかexception specificationとか。

>>602
2010年中に二つは出るはず。

>>599
一般ユーザではない人たちに、コンパイラを書いちゃう人たちも追加で。

> All expressions are now divided into three "value categories":
>
> * "lvalues" are the same as what's meant traditionally by lvalue.
> * "xvalues" are objects created by rvalue reference operations (sometimes previously called "rvalue reference objects"). The "x" can be for "eXpiring value" or a cross between lvalues and rvalues.
> * "prvalues" are the new name for traditional rvalues (i.e., excluding the xvalue cases). The "p" is for "pure rvalue".
>
> There are two compound categories:
>
> * "glvalues" are lvalues and xvalues. These are things that have dynamic type and object identity.
> * "rvalues" are xvalues and prvalues. These are (as now in the draft) things that are potentially movable.

えーと…何だ？
右辺値を左寄り右辺値と超右辺値に分けるって？

オッスオラ極右

右辺値？ちがうな……オレは……超右辺値だ!!

極右辺値ww

超左辺値がやられたようだな
ククク・・奴はxvaluesの中でも最弱

英語力がないのでネタなのか本気で迷走しているのか区別がつかない

　　　　　 　　 　 　 　 ┌左辺値(lvalue)
大左辺値(glvalue)←{
　　　　　 　　 　 　 　 └中辺値(xvalue) ┐
　　　　　　　　　　　　　　　　　　　 　　　　 }→右辺値(rvalue)
　　　　　　　　　　 　 超右辺値(prvalue)┘

左辺値(lvalue)＝今まで通りの左辺値
右辺値(rvalue)＝今まで通りの右辺値。中辺値と超右辺値に分割される。ムーブできる。

大左辺値(glvalue)＝左辺値と中辺値の総称。名前が付いてる。

中辺値(xvalue)＝右辺値参照で作られるオブジェクト。名前は付いてるけどムーブできる。
超右辺値(prvalue)＝中辺値以外の右辺値。名無しの一時オブジェクト。


あってる？

April Fool's Day にはまだ早いぜ？

ttp://cpplover.blogspot.com/2010/03/funny-lvalue.html
ふーん、さすが。

Google Chromeがネットブックだと糞重たいから
IEのほうがマシだと思ってIEに戻したら

＞ハァ？　お前まさかIEみたいなクソブラウザ使ってるっていうのか？　アホか？　もっとマシなブラウザ使えよ。速いし規格準拠だし、無料だぜ。

だってさ。

というか0x自体がうそだろ

>>616
俺もそれは毎回表示されて正直ウザイと思う。

C++0x--はまだか

>>613
「C++学園の人々」的に頼む。

本の虫って査読をブログで募集するくらい学会で浮いてるの？

学会って？ 話が見えないが

ごめん寄与のとこ見たらニートっぽかった

禿は校長で本の虫の人は用務員

○左辺値
名前を持ってる普通の生徒。

○右辺値
聴講生。特に名前を持たない生徒。それをいいことに周りから弄ばれる不憫な存在。

●右辺値参照さん
聴講生にあだ名を付けて仲良くなれる能力を持つ。

さて、「右辺値参照さんと仲良くなった聴講生」は右辺値参照さんにあだ名をもらったのでもはや名無しではない。
だが聴講生の身分には違いないので周りに弄ばれることにも変わりない。
右辺値とも左辺値とも違うヘンな性質になってしまった。

というわけで、聴講生をさらに分類して区別することにした

○中辺値
右辺値参照さんにあだ名をもらった聴講生。

○超右辺値
右辺値参照さんにあだ名をもらってない聴講生。名前はない。

「右辺値」はこの２つの総称、つまり弄んでもいい生徒ということになった。

それと、「名前を持ってて呼ぶことができる生徒」というのがまどろっこしいのでこれに名前を付けた。
○大左辺値
左辺値と中辺値の総称。本来の名前か、右辺値参照さんにもらったあだ名を持ってるので
先生は授業中に名前を呼んで当てることが出来る。


ごめん余計わかりにくくなった気がする

>>625
乙！

名前分けしただけで機能自体に追加が有ったわけではないと？

>>627
>>615

読みたくも無いな

r,x,l と rx,lx でいいじゃんかよ
gl とか pr とか超とか大とかが分かりやすい？ギャグがそれ

>C++0x規格を厳格に実装したコンパイラがそもそも
>出るのがいつになるのだろうか？ww

EDG のフロントエンドがもうじき実装を提供し始めるから、それから。
独自実装の gcc や msc はもっと後でしょうね

仕事で使っていいよってなるのはいつになるのだろうか

上司に聞け

>>630
それだとrvalueの意味が変わっちゃうからダメ

ところでpを訳すと超になるの？
なんとなくpureの略っぽい気がするから
最初純右辺値さんだと思った

>>635
俺もそう思う。
ってか、>606 に pure って書いてある。

pureの略だから純で合ってるけど超の方が強そうじゃん

prvalueが「純粋な右辺値」ってのもなんか違う気がするし

pure virtual とか純粋仮想って言ってるし純粋でいいよ
純だと順かと勘違いしそうだし

発音的にも
じゅんうへんち
だと発音しにくいから
純粋右辺値
がいいな

こんなんでどう？
lvalue　 = left value　　　　　　: 左辺値
xvalue　= expiring value　　　 : 遷移値
prvalue = pure right value　　: 純粋右辺値
glvalue　= general left value? : 汎左辺値
rvalue　= right value　　　　　 : 右辺値

>>639
同意。

glvalues も「広義左辺値」や「拡張左辺値」、「拡大左辺値」とかの方が分かりやすいと思う

> All expressions are now divided into three "value categories":
>
> * "lvalues" are the same as what's meant traditionally by lvalue.
> * "xvalues" are objects created by rvalue reference operations (sometimes previously called "rvalue reference objects"). The "x" can be for "eXpiring value" or a cross between lvalues and rvalues.
> * "prvalues" are the new name for traditional rvalues (i.e., excluding the xvalue cases). The "p" is for "pure rvalue".
>
> There are two compound categories:
>
> * "glvalues" are lvalues and xvalues. These are things that have dynamic type and object identity.
> * "rvalues" are xvalues and prvalues. These are (as now in the draft) things that are potentially movable.

　　　　　　　　　　　　　　　　 ┌左辺値（lvalues）
　　　　　　　　　　　　　　　　 │　〔従来の左辺値〕
広義左辺値(glvalues)　─＜
〔名前を持つ〕　　　　　　　　│
　　　　　　　　　　　　　　　　 └中辺値（xvalues）　　　　　　　　　　　　　　　　　　　　　┐
　　　　　　　　　　　　　　　　　　　〔右辺値参照でバインドされた名前付き右辺値〕　│
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　＞─　右辺値（rvalues）
　　　　　　　　　　　　　　　　　　純粋右辺値（prvalues）　　　　　　　　　　　　　　　　　 ┘　　　　〔ムーブ可〕
　　　　　　　　　　　　　　　　　　　〔従来の右辺値、無名一時オブジェクトなど〕

ぶっちゃけ左辺値とか右辺値とかわけわからんのだが
これないと記述出きないくらい必要なこととかあるのかね

>>640
かぶった（汗）

個人的には↓の方が良かった
　　　　　　　　　　　　　　　　　　　　　　　　　　 ┌左辺値（lvalue、left value）
　　　　　　　　　　　　　　　　　　　　　　　　　　 │　〔従来の左辺値〕
名前付きの値(nvalues、named value)　─＜
〔名前を持つ〕　　　　　　　　　　　　　　　　　　│
　　　　　　　　　　　　　　　　　　　　　　　　　　 └中辺値（xvalue、expiring value）　　　　　　　　　　　　┐
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　〔右辺値参照でバインドされた名前付き右辺値〕　│
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　＞─　ムーブ可能な値（mvalue、movable value）
　　　　　　　　　　　　　　　　　　　　　　　　　　　　右辺値（rvalue、right value）　　　　　　　　　　　　　　 ┘　　　　〔ムーブ可〕
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　〔従来の右辺値、無名一時オブジェクトなど〕

JISがどんなセンスのない訳語を当てるか楽しみだ

広義左辺値いいね

>>642
下っ端は、const が分かっていれば、とりあえずはそれ以上必要ない。
誰かが適当に対処してくれる。

綺麗左辺値

>>646
誰かって誰だw
コンパイラ屋さんとかか。

左辺値と右辺値までは分かっていた"つもり"だったが、
> 「lvalueとrvalueだけですべてをカバーするのが、大雑把すぎて分かりにくい」
こんな感覚が生じるほどには理解していなかった。

結局 この分類もまた勉強しなければならないのだろうか。

・・・ま、いっか。まだ変遷中だしね。

仕様書やコンパイラを書く立場じゃないかぎり
気にならなそうだけどなぁ

右辺値の「名無し」と「壊してもいい」っていう性質が右辺値参照のせいで分裂したって事でしょ

そういえばこれが通ったら右辺値参照は中辺値参照に名前変わるのかな

右辺値参照を右辺値というのがそもそもおかしい。
どう考えても左辺値。

右辺値だか無名オブジェクトだか一時オブジェクトだかひっくるめて用語の定義が明確になればいいんじゃないか

C++の問題点を拡大する仕様ってどうなんだ？

マニア度が拡大するんじゃないか。
敷居が上がり続けてて、今から始める人にはつらい状況だね。

たしかにC++はメンドくさい
EffectiveC++ぐらいは頭に入ってないとろくなことにならない

入ってるって言ってる奴もろくなことにならない

ピンからキリまでいる場で「みんな同類」的な方向に話を持って行きたがるのは
もちろんピン側の人ではない。

どうでもいいけど敷居が高いはもう間違った意味で一般的になっちゃってるよな。

「煮詰まる」も参戦！

おまえらホントに、C++以外の話が好きだな。

美少女中学生スレだからな

日本語化して JC++ にでもすんのか

厨二病だな

えらくつつましい症状だな

皆さんいかがお過ごしでしょうか。
ストレス解消に煽りに来ている方、十分な睡眠を取って煽ってくださるようお願い申し上げます。
風邪を引く前の予防が肝心です。日々の鍛錬を怠らないようにして下さい。
暇つぶしに来ている方、時間を決めて一時間ごとに十五分から二十分くらいの休息を取られた方が良いと思います。
時間は限られています。あなたの人生はあなたの物ですが、一日中インターネットに没頭している、これはいかがな物でしょうか。
インターネットはあなた様の健康に悪影響を及ぼす可能性があります。
マルチしている方、人を忘れないでください、すべてはたくさんの人の多大な努力と膨大な時間を費やして出来た物でありますが故に、
そのような行為は非人道的行為にあたります。なお九十割はスクリプトで出来ているので、気軽に質問してください。マルチはいけません。
さて、私がこのような事をなぜ申し上げますかというと、この度Goのビルドに成功したが故に存じ上げる次第でございます。
よくよく冷静に考えると、このような開発段階にあり、現段階では実用に適していない「ぼくのかんがえたさいきょうのげんご」は
プログラミング言語の学習に適さないと判断させていただきました。今後ますますのご健康とご活躍をお祈り申し上げます。

中々気が利くスクリプトだな

テンプレート使ってると、これは他人に勧めるのは躊躇するなあと思う。
Conceptさん帰ってきて！！！

本の虫に寄付が集まっているな

>>669
あんがい集まるのか。

>>668
> テンプレート使ってると、これは他人に勧めるのは躊躇するなあと思う。
おおお俺も俺も俺も思うよ！！！
同じ感想の人がいてうれしい

寄付した額３倍にして返してくれるなら寄付してもいいよ

まあ、まともな本が出るなら何も言うまい

いい本だったら３冊買う。

テンプレートよりADLの難解さで他人に勧めるの躊躇
C++のてんぷれーとはよいものだよ

SC 22/WG 21はもう少し人を選べばいいのに。
てか名簿に所属組織が書かれていない人、もしかしてこれ全部…なのか？

テンプレートのエラーメッセージの難解さが勧めにくくする。
10数年前にSTLを挫折したことがある俺。

コンセプトさん・・・

コンセプトって何が駄目だったんだ？素人目には夢のアイテムにしか見えんのだが

>>679
いや、>>>528いわく、 夢は夢のままで、実現するのは困難なんだとさ。

>>675
他人に勧めるのを躊躇するC++の仕様なんて
いくらでも見つかる気がする。。。

各自 困ったことのある経験によるだろうだな。

>>679
実現するためのスタイルが二種類あって、
片方に決まりそうだったけど、
最後に、禿がやはりそれは複雑すぎなんじゃ？
と疑問を呈した大論文を書いたので、
禿のよりシンプルな提案を含めて再検討することに。
ちなみに禿の一方的な考えじゃなくて、
メーリングリストでみんなの議論をまとめた論文。

まあ俺はC++の規格の深遠なんてわからんから
すごい人達だけで便利なのを作ってくれとしか言えんな。

コンセプトが廃止になった理由は、いろいろあるが、直接には、concept mapを、暗黙的に生成するかどうかだった。

あるコンセプトに対して、対応するコンセプトマップを、暗黙的に生成するか、
あるいは、たとえ、コンセプトマップが空でも、明示的に定義させるべきかという問題があった。
つまり、ある型は、そのコンセプトの要求を満たしていると言うことを、明示的に宣言しなければならないわけだ。
こうすることによって、たまたまシグネチャが一致したのではなく、明確に、この型はこのコンセプトを満たしているんだと宣言できる。
ただ、このやり方は、殆どの場合、空のコンセプトマップを、ただ、そのコンセプトを満たしているという宣言のためだけに、書かなければならない。
それはどうなんだと。そんなの面倒で、誰もやらないぜと。

フランクフルト会議での解決策は、デフォルトのコンセプトには、暗黙的に、対応するコンセプトマップが生成され、
explicitをつけた場合、コンセプトマップを（たとえ空でも）、明示的に宣言しなければならないという提案だった。

ただ、やはりコンセプトというのが、非常に微妙で、ある意味では、厳格すぎるし、なかなか難しい機能だった。
コンセプトのコードを正しく書くのは、非常に難しい。
さらに、まともな実装もなかった。
Douglas GregorのConcept GCCは、かなり不完全な実装で使い物にならなかったしね。

まあ、そんなわけで、標準化委員会の中にも、「もういいだろ」って雰囲気が漂っていた。
そこにきて、この根本的な思想の違いをきっかけに、投票が行われた。
すでに入っているConceptを、ドラフトから削除するという投票。
これには、Bjarne Stroustrupも、Douglas Gregorも、削除の票を投じた。

そんなわけで、コンセプトは削除された。

標準C++の範囲で（コンパイラの拡張機能などは禁止として）、
テンプレート引数がある関数を持っているかどうかを
調べてコンパイル時に分岐させる方法はありますか？

　has_funcion_nantoka<T>::flag
みたいなのです。

C++0xまで無理なのでしょうか。

>>684
あー、そうだったのか。
残念すぎる。
どんな実装が良いか一長一短が過ぎて名案が浮かばないってことね。

>>685
なんか出来るらしいという噂も聞いた。
でもテンプレートメタプログラミングを駆使するから
コンパイラを選びまくるという話だったよーな。

あんまり詳しくないんで、ごめんよ。あとは他の人に。

ドラフトやDouglasはコンセプトさんをツンデレにする方向で進めてたが
禿とその仲間達がやっぱり世話焼き妹系がいいと言い出して
結果キャラ設定から考え直すことになったということですね

ツンデレにしちゃうといちいち細かく定義しなきゃいけないから面倒ぽいな

>>685
C++相談室 part78 でこんなのあったよ
ttp://codepad.org/3HNtsPNZ

>>685
0xじゃなくてもできるよ。
C++スレもしくはBoostスレがいいかも。

>>690
これは思いつかなかった
質問者じゃないけどちょうど活用できそうだわサンクス

ほー、特殊化の部分にメンバの名前があるから判別できるのか。

まあ、C++0xなら、これでいいんだけどな。

ttp://codepad.org/Mnw0vil8

SFINAE の挙動で明確になってない部分があるから、現行の標準範囲外だと思ってた。

そのあたり、690は規格的にどうなのさ？

14882:2003 における SFINAE の根拠は 14.8.2 だと思いますけれど，
ここは関数テンプレートにおける deduction についてしか記載していないので，
690 は 14882:2003 的には正当性が不明なのではないですかね？

ところで concept は， archetype test と
(スコープによって切り替えられる) concept map を
分離できなかったんでしょうかね？
個人的には後者が無いことの問題のほうが大きいと感じるので，
後者だけでも 0x までに何とかして欲しかった．

必死に頑張ってSFINAEを勉強します。
ありがとうございます。

SFINAEの正しい発音きぼん
すふぃなぇ？

ググってみた限りではスフィーナイらしい。

エスフィナエ

>>697
そうそう、何をもってSFINAEとするかが、問題でね。
C++0xでは、インスタンス化の結果が、直接書いた場合、ill-formedであれば、type deductionは失敗するとしている。

UKINAE

ちなみに690はgcc4だとokだったが、VC8だと判定できずにfalseになった

VC9/10はhoge

>>>666
noop スレを見てる暇があったらプログラム書けボケ

「ぼくのかんがえたさいきょうのげんご」なんて本当にどうでもいい。
言語で何を作るかによる。言語自体の評価なんて二の次だろ。というかなくてもいいくらい。

誰も言語自体の評価などしてないけど何と闘ってるの

>>707 のコピペどっかで見覚えあるな

乳首オナニー

チューリング完全なら何でもいい

美少女中学生の乳首オナニー！！！！！！！１１１１１１１１１１１１１１１

淫語に過剰反応する中学生キモオタ

×淫語に過剰反応する中学生キモオタ
○中学生キモオタだから淫語に過剰反応する

どうでもいい

どうでもいいけど、上の方で中辺値とかあるのは両辺値にしたほうがよいと思う。
中辺という言葉が意味を為さないので。

どっちにしろ expiring value からは想像し難い訳だけど

かといって失効値だの満期値だのってのもなんかおかしい
JISはこんな訳当てそうだけど

皆分かってる事だけど、このままだとC++0xは失敗するよね。
犯人は誰だ

デフォルトの名無しさん

>>719
> このままだとC++0xは失敗するよね。
そうか？
まあ確かにこのままだと多少微妙かもしれないけどね。

何を持って失敗とするのかはわからんが
少なくともC99みたいにガン無視されることはないと思うけどね
VCに機能が一部入ってるのが大きい

スマポ、右辺値参照、lambdaだけはC++2010として小出しにはできないのか？

「失敗」ってなんだよｗ
言っておくけど制定委員に給与はもともとないから頓挫してもデメリットも糞もないからなｗ
市場価値が発生しない事を「失敗」と言うならば過去に何度も失敗してるｗ

threadと可変長引数マクロ・テンプレート
とにかくこれだけ対応してさっさと普及させてくれないかな

>>725
long long, static_assert, 右辺値参照と可変長引数マクロ・テンプレートが欲しい。
あとライブラリ実装でできるものなら簡単そうだからいろいろ。

threadは、もう別のライブラリが多少普及しているし、
微妙な代物がstdに入っちゃうとそれはそれで困るから
もうちょっとゆっくりやってて良いよ！

ラムダ
右辺値
template可変長引数

3つ選ぶならこれが欲しい
次点でstatic_assert
ということは俺的にgccはもうC++0xとして使える

>>727
lambdaが欲しいのか？この変態め！

ライブラリを使う側の人間にとっては
auto、initializer_list、コンストラクタの委譲と継承、strong Enum、UTF周り
あたりがあるととても楽になる

あーコンストラクタの委譲と継承は欲しいな。

やっぱり constexpr でしょ

lambdaって何が変態なの？
匿名関数なんてあって当然のものだろ。

関数を値渡しでリターンするとき
普通にやってRVOにするかreturn move(戻り値);にするか
迷うけどどっちにしたらいいですか？

最適化されないかもしれない場合に備えてmoveじゃね？

値渡しで返せば右辺値になるから勝手にmoveされるんじゃないの？

一時変数にコピーするとき左辺値じゃね？

>>732
いまだにCと関数ポインタに固執している哀れな人間だ。
そっとしておいてやれ。

たかがインラインで書ける関数オブジェクト如きをラムダと呼ぶのには抵抗が

ざっと追加される項目を見たけどfinalやsealdみたいなのは追加されないのかぁ

Ｃ＋＋で関数型言語が出来るようになる革命だと思うが。

関数型言語とはなんぞや

ループを再帰で書いたり、代入しなかったりで参照透過性を云々する
最近流行ってるパラダイムです

C系列に変わるような高速・低レベルでそこそこ生産性高い言語って無いのか

C++で参照透過性って

ループを再帰で書くってスタック考慮しないつもりかC系なのに

末尾再帰の最適化について書こうと思ったがスレ違いなんでうんこしてくる

>>739
delphiのoverrideとかoverloadが欲しい。

微妙なうち間違いで仮想関数がいつの間にか作られてたりとか非常に辛い

関数型って条件とか書きにくいような気がする。
テンプレートみたいな一部の記述には最適かもしれないけど全てをそれでってのは難しくないかな。

>>793
7.6.4 Final attribute [dcl.attr.final]

>>747
7.6.5 Class member name checking attributes [dcl.attr.override]

>>726
別のライブラリってboost::threadではなく？　他にこれと言って思い当たらないなぁ。

この前組み込みでboost::thread使おうとしたらスタックサイズ指定できなくて残念だった。

スタックサイズってやっぱ必要になる？
自前ライブラリでインターフェースから抹消してしまったんだが

>>750
pthreadじゃね
普及していると言えるか微妙だけど

>>751
メモリが少ない環境ではスタックサイズが必要になると思うけど、グローバルでいいんじゃないか

とりあえずグローバルで入れとくか
コンストラクタで指定できないこともないんだが

最近のglibcだとデフォルトのスタックサイズが8Mとかなので馬鹿にならない。
まぁ組み込みなんだから自分でboostビルドするときに修正すれば済む話なんだけど。

>>752
もうちょっと高レベルなのが欲しいんだよね。JavaのExecutorフレームワークみたいな。
C++0xのfutureは良さそうな感じ。
IntelのTBBとかはまた方向性が違うしなぁ。

futureってなんですか！

この言語が行き着く先さ

>>757
ちゃんと明るいんですか！？

その明るさたるや、Ox と反応する C の輝き程

油断すると不完全燃焼して有毒ガスがですね

酸化数+2の炭素酸化物ですね

ox
n. （pl. oxen） （特に去勢した）雄牛; （普通pl.） 牛（属の動物

つまりはこういうことだ。
0xでいよいよC++に愛想尽かすやつが続出する。

変態が量産される

テールコールの最適化は gcc でもやってるだろ

そろそろテキストソースから脱出した超高級言語が出てこないかなあ

>>763
5年後を考えて見よう。
5年後の段階から初めてC++を学ぶ人達に、
どうお薦めすればいいんだ！？

C++の仕様を変えなくても、boostのshared_ptrとかを早期に標準化するなどライブラリの強化をしてればC++はもっと評価されてたと思う。

>>767
better C++03 としてすすめればいいんじゃないか

Effective C++0xまだか

>>768
そんな気安く変更できない体質が
逆にC++の良い所なんじゃないか。

D言語を見てみろ

きっとそのうち安定するさ・・・そのうち
D言語はそれからが本番

>>772
本番が来るころには別の言語に押されてそうで不憫な子。

ネイティブコンパイル言語に大した競合言語はないから
そこんとこは心配ない気はする

goで知名度のあるサービスやライブラリが出てきたらトドメ刺されると思う

D言語の本番が来る頃にはC++はさらなる変態化…もとい進化を遂げていて
テンプレートメタプログラミング言語になっているのではないだろうか。

>>776
> 進化を遂げて
ねぇ…
どんどん変態構文が増えるだけのよーな気が … … …

C++0xはautoとか一部の便利な仕様は使われるだろうけど、
右辺値参照とか標準ライブラリにあるもの以上のものが
使われる気がしないねえ
Goがどうなるかだね

最大の競合相手である、C言語は、完全にあさっての方向に向かってるしな。
C厨はそもそも強い静的型付けなんか頭にない。
そもそも、競合相手じゃないんだよな、Cは。

まあ、C++は、しばらく競合相手が現れないだろうよ。

そういえば例外仕様が無くなったと聞くが
noexcept を指定する以外は関数の宣言からは
どんな例外が throw されるか判別できなくなるってこと?　

こう、書きたいところにダイレクトに書けるのがいいな。
GCみたいにいつ開放されるのか分からないのはまどろっこしい。

どうせ、関数テンプレートや、関数ポインタやstd::functionを引数に取る関数からは、
現実的に、どんな例外が投げられるかわかったもんじゃないし。

そりゃ、引数を渡すのはユーザーだとしてもだ。
現実的に、まともに把握出来るわけがない。

>>780
例外仕様はいまいちだったと思うけど、thorw()だけは必要だと思ってた。
それがnoexceptになるの？

throw()もdeprecated。
noexcept(true)と同じ意味。

結局色々キーワードが追加されるんだな

0xの新機能にADLの関数→引数バージョンをが欲しかった
hoge::func(Fuga());
とやるとhoge::Fugaがあればそれが選ばれる的な

ADLは明示的に使う機能じゃないとあれほど言っているだろう。

>>785
概念を具現化するにはキーワードが無いと辛いからね。
その昔に追加された explicit や mutable などと同様、導入はやむを得ない。

キーワードは _Noexcept にして
#include <cpp0x> 内で
#define noexcept _Noexcept
とする・・・みたいなことはしないんだなー
C99みたいに

概念概念というが、本当にプログラム書くのにそんなに沢山の概念が必要なのか。

>>790
概念が必要なのは実装よりも頭の中で考えてるときじゃね？
それを実装するときに概念に近い機能があると楽っていう。
ちゃんと概念からコードに変換できる頭があれば疑問かもしれんが。

概念を具体的に、言語機能としてサポートしているかどうかは、重要だぜ。

C言語でも、オブジェクト指向プログラミングは可能なわけだ。
継承も、データメンバーとして持てばいいわけだし、
仮想関数も、自前でvtable構築すればいいわけだ。
俺はやりたくはないけどな。

ジェネリックだって、自分でプリプロセッサを実装すればいいわけだ。
俺はやりたくはないけどな。

しかし、コンピュータは概念を理解できないので、
どこまで行っても永遠に平行線だぞ。
頑張ってる人には申し訳ないが、俺は無駄な努力だと思うね。頑張ってね。

おう
ありがとな

しかし、コンピュータは自然言語を理解できないので（ｒｙ

出来もしない事は、初めからやらないのが俺のやり方だから、許してね。
でも、月に行っちゃう人たちも居るし、頑張れ。

>>795
コンピュータに自然な形で指示を出せばよい。
最後はみんなアセンブリの構文砂糖であるC言語に落ち着き、
そこからもう一歩踏み出して、C++ではないどこかへ旅立っていくのさ。
そういうもんだろ？

> コンピュータは概念を理解できない

だからこそキーワードなしで勝手によろしくはやってくれないって話なんだが

映画の中のコンピューターかよｗ
コンピューターに、「NSA 秘密　情報」　と入力するだけで、NSAのスパイ情報が得られるわけだな。

「name lookup 詳細なルール　俺にでも分かる用語で」

結局、人間の意図をコンピューターに伝える場合、
曖昧さを排する必要がある。

通常は簡単なルールにより強制的に一義性を持たせるようにする。
こういった単純なルールの組み合わせで曖昧さをなくすのである。

だが場合によってはそのルールを組み合わせて使用することで
直観的でない結果を生じることがある。

このようなルールの連鎖によって直観が働かないことが起きないように、
適切な局面にキーワードを導入して、
意味が直観的かつ一義的になるように設定する必要がある。

>>798
検索ぐらいならやってくれるだろう。

googleって漢字で検索しても読みでひっかかったりとか
結構色んな事やってるよね

>>797
上にも出ていたけど、mutableとか要るか？
意味の上ではconstだけど、実装の上ではconstではない。
コンピュータは意味の上でのconstを理解できないので、仕方なくmutable。
でも実装はconstではない。データいじる。でもconst。変なの。

explicitも。
そもそも、暗黙の型変換をコンストラクタで代用したのが失敗だ。
Cで論理値を整数値で代用したために、if( TRUE==func() )がご法度になった失敗を
繰り返してる。

実装上は違う物だけど、意味の上では同じような物だから、同一に扱えるように〜とか、
意味の上では違う物だけど、実装上は同じようなコードになるから、代用〜とか、
ってのは大概失敗する。

まー皆さんは、意味と実装のギャップの分だけ詭弁的キーワードを
コンピュータや周囲に向かって唱え続けてればいいよ。
「この子はやれば出来る子なんです」ってね。

mutableはいるだろう。

いまあるキーワードはそれを導入することで
必要なことが出来ていることだけは間違いない。

変だ、いらないっていうのは簡単だけど。
じゃあどうすればいいかのか別の解決法を示せってことだろうな。
出来もしないことを周囲に向かって唱え続けるのは詭弁だろう。

mutableとconstは全く別物だろｗ

TRUEとの比較なんて内部表現がどうだろうとそもそも馬鹿げてる

そういえばキーワードにしても極力使い回してるよね。
lambda式中のmutableとかexplicit operator bool()とか。

なんだっけ、キーワードが一つもない言語あったよな
それ使えば？

Whitespaceのことか？

>>804
>じゃあどうすればいいかのか別の解決法を示せってことだろうな。

超簡単。
少なくともexplicitに関しては。
暗黙の型変換をコンストラクタで代用しない仕様にしとけばよかった。
だっておかしいだろ、コンストラクタで暗黙の型変換なんて。
後の祭りだがナー。

代用代用、同一視同一視、困ったときは魔法のキーワード。
それがC++。

後からIFと言うのは簡単だよ。
もし当時、そんなに厳格な型システムだったら、誰もC++を使わなかっただろうな。

失敗だとか変だとか後の祭りだとか
C++ユーザーはみんなそう思ってるの？
思ってないでしょ？

それともどこかにいるの？

explicit に関しては後の祭りだな
逆に、暗黙変換をしたい時に implicit を付ける仕様にすべきだった
今言った所でどうにもならんがなー

>>812
少なくともコンストラクタでの暗黙の型変換に関してはそう思うのが普通だろうよ。
むしろ、お前はそうは思わないのか？変な奴。

失敗だろうがなんだろうが、ここまで使い倒せる言語は他に無いな。

constも失敗。
値の書き替えが必要な変数にはmutableをつけるようにすべ(ry

だからconstとmutableは違う物だってば

歴史的経緯は仕方だない。
ちゃぶ台返ししてよいなら
D言語みたいにいろいろチャレンジし続けてる言語を使えば良い。

正直、自分の知識が足りてないせい（？）か
C++のexplicitが何故、後の祭りなのか分からない

C#のようにしたほうが良かったってこと？

>>818
つまり、これからも同じ過ちを繰り返しても良いと

>>819
暗黙の型変換をコンストラクタで代用したために、
コンストラクタが
暗黙の型変換のためにあるのか、
コンストラクトのためにあるのか、
両方のためにあるのか、
つまり、どういう意図のコンストラクタなのか、
文法からは判断がつかなくなっちゃったんだよ。
意味のランク落ち。
暗黙の型変換を提供する演算子なり構文なりを追加すべきだった。

意図よりも問題なのは
デフォルトが暗黙変換を許容するってことだ
暗黙変換を許容するケースの方が特殊だろうに

>>822
とても分かりやすい回答ありがとう

{
implicit none;

// 〜
}

こういうの欲しい

fortran臭いなw

予約語としては残るらしいexportのリサイクル法を考えてくれ

>>822
違うね。
暗黙の型変換をコンストラクタで代用している限りは、
将来の文法の拡張やパラダイムシフトで問題を起こす可能性が残る。
何かの拍子で、暗黙の型変換とコンストラクタを明確に区別する必要が出てきたら、
また謎めいた予約語を追加する羽目になる。
そうでなくても、暗黙の型変換とコンストラクタは全く別の機能なのに、
コンストラクタで代用するのは間違った設計だし、実際に問題がおきて予約語が追加された。

registerもだな。

全く別、というほど別ではないな
演算子オーバーロードを許容するかしないかという
宗教論争と根は同じだと思う
「数値と同じようなものに見せたい」という
実用上の要求から考えれば同一視した方が良い

つーか予約語全部_XXXにするとか名前空間内なら予約語と重複してもいいとかして欲しい
registerとか被りまくりでムカつく

言ってる意味が分からん。
暗黙の型変換とコンストラクタを同一視する事に何の意味がある。

演算子のオーバーロードは分かる。
足し算なら足し算、引き算なら引き算、同じ名前の同じ機能を提供するのだからな。

暗黙の型変換とコンストラクタは名前も機能も違う。

機能が違ったら今実際にコンストラクタで暗黙の型変換なんてできないだろ
そもそもC++はキャストとコンストラクタも同一視されてんだぜ

あー意味が分かった。
intやdoubleには暗黙の型変換があるから、それに似せたいと言う意味か。
でも、それと、コンストラクタを暗黙の型変換に代用する事とは話が別だと思うが。

まあ代用せずに別の構文を用意する事もできるだろう
でも、結局実装はコンストラクタを呼んで
テンポラリオブジェクトを返すだけの実装になるだろう
というか、それ以外の実装になる方が問題だと思う
どんだけ特殊な事やってんだと

>>832
違うって。暗黙の型変換をするときに、コンパイラが勝手にコンストラクタを呼びにいくことが問題なんだ。
なんで「暗黙の型変換==コンストラクタ」みたいに勝手に解釈してんだよ、という。
昔あっただろ、
ポインタが必要なところで0が出てきたらNULLポインタだと勝手に解釈する言語が。
あれも結局オーバーロードと相性悪くてnullptrが追加されただろ？
同じ事だよ。結局問題を起こすんだ。

それに、暗黙の型変換とコンストラクタが別々に定義できた方が柔軟性がある。
コピーコンストラクタと代入演算子が別々に定義できるようにな。

>>834
それでいいんだよ。
その冗長性が暗黙の型変換の特殊性を示している。
というか、暗黙の型変換を定義するわけだから、暗黙ではなくなるんだがな。
知らないところで勝手にコンストラクタが呼ばれるからこそ暗黙なわけで。

デフォルトコンストラクタとかあるんだから、そういう言語なんだろ。
お節介焼きたいお年頃だったんだよ。

コピーコンストラクタと代入演算子は全くの別物だろー
初期化と代入の区別が怪しいぞ
まだ未初期化のオブジェクトを初期化するのと、
初期化済みのオブジェクトに上書き代入するのとはえらい違いだ
実装も変わってくる

オーバーロードと相性が悪いのはまあ確かにそうなんだよな
でも特殊な構文を用意させられるのはちょっと・・・
暗黙じゃないじゃん

結局、デフォルトで明示的な型変換（キャスト）を要求して、
implicit をつけたら暗黙の型変換も許容する、でいいのさ
まあ、今となっちゃどうしようもないがね

一から言語仕様綺麗にしろよ。

具体的にどこをどうするかいってみてください

いくら綺麗な言語仕様があっても使う人間が…

まずD言語を用意します

D厨うぜー

屁が出た
気持ちいい

俺は特殊な構文を用意する事で、
暗黙でなくなるなら、そっちのが良いと思うがなぁ。
今は良くても将来どうなるか分からないのは、
CのNULLポインターを見ても分かるとおり。
あれも、0を暗黙でNULLポインターと解釈する仕様がネックになったわけで。

そんなに暗黙なのが嫌ならキャストしろよぅ

昔は暗黙の何とか系はうざくてしょうがなかったけど、いまはうまく使いこなせば便利だなと思うようになった。
使い方の問題だろ。

D言語を使えばいいじゃん

本来のCはぬるぽでも書き込めたし
書き込めないと困るんだお

>>848はperlにフィット

God bless you.

暗黙のオナニストな美少女中学生

こうしていつものように0xとは何の関係もない話でスレが浪費されていくのでした

C++0xの話をしないのは何でですか？

もう、無かったことになってるから、それ。

冷やかしがほとんどを占めてるんだろう

>>855
C++0xって何のことか分からない人が紛れ込んでくるから。

蒸し返すようだけど、operator T()とかそういうのは
暗黙の型変換用の構文じゃないのか？
なんでコンストラクタでしか定義できないみたいな話になってるんだ。

とりあえずUnionが無駄にパワーアップしているのはわかった

あ、いや operator T とコンストラクタで定義できる奴が別モンだってことはわかってるけどさ。

分かっているなら分かっているように話せ
というか忘れてましたって正直に謝れ

忘れてました。ごめんなさい。

許した

>>862
正直すまんかった

>>863
ちょｗｗｗｗおまｗｗｗ

>>860
どーせならboost::variantぐらいはっちゃけてもいいんじゃないかと思ったが
確実にゼロ・オーバーヘッド原則に反するようなことが起きるから無理か

というか、まだみんなC++0xで実装すると、どういった問題が浮上してくるのか、
把握し切れてないんだと思う。想像しきれんぐらい複雑な化学反応が起こるのだろう。
またどうせ、変な問題が出てきて、変な予約語が追加されるに一票。

意外に思われるかもしれないが、俺がにらんでるのはみんな大好きなauto。
こいつは便利だから、そこらかしこで使われる事になるのだろうが、
それゆえにあちこちで火の手が上がりそうで怖い。

auto value=hoge();　//自分の想像していた型と違ってたりしてな。おーこわ。
value.method();//何が呼ばれるのか、
func( value );//わかったもんじゃないね。

autoは変数宣言のgoto文とか言われるようになったりしてな。

さー何が起こるか楽しみだね。

実のところ、多態とオーバーロードが全ての元凶なんだがな。
あんまりいうと怒られるけど、型によって制御が切り替わるってのは、
データ構造で制御構造を構築しようとしているわけで、
もとより、こんなものがうまく行くわけが無いんだよね。
だって、データ構造と制御構造はあくまで別物だからな。混ぜるのはアホだろ。

オーバーロードは暗黙の型変換や#define NULL 0で問題を引き起こし、
多態は制御構造をスパゲッティーにした。

autoと多態orオーバーロードの相性も良く無いだろうし、
もう止めたら？っておもう。むしろautoはCにこそ相応しい。

おっと、あんま言うと怒られるね。ごめん忘れて。

こわがりすぎ

まぁ高二病感はある

多態とautoが相性悪いなら
C#もJavaもみんな大好きD言語も糞言語だな

D言語が糞言語とかありえないからｗｗ

C#とJavaが糞言語なのは納得いかないがD言語に関しては比較的妥協できる。

ごめん、C#もJavaもD言語も素で糞だと思ってた。
そんな俺の好きな言語はSQLだったり。
まぁSQL自体はあんま好きじゃないんだけど、リレーショナルDBの考え方がすき。
シンプルで良いじゃない。
C++で高速なリレーショナルDBのようなものが言語レベルでサポートされれば、
個人的には満足。
えーって思う人たちも居るだろうけど、生産性は確実にあがると思うよ。
面白みはなくなるけどね。でも、オラクルは成功しているだろ？あやかろうぜ。

まるでコンタクティーの証言のようだ

Dは史上最強の言語だから、やっとかないとこの世界生きていけないよ

Dは現代のバベル

では、史上最強の言語の世界の中だけの話ってことで >D言語

std::vectorとか持ち出して、「コンテナです！！」とか言われても今更というかなんというか。
そんなのいいから、ちゃんとしたDB用意してよって思うんだよ。
トランザクションも付いていたらありがたいなー。それはやりすぎか。
そう言うところをもっと頑張って欲しいんだよなー。
Boostとかマジどうでも良いから。

そんな存在しないものが最高だと言うならば
現実なんてのはさぞ最悪で住みにくいことだろうね

別に。俺はソフトウェアエンジニアじゃねーからな。
気に入るのが出てくるまでボーと待ってるよ。

>>835
何言ってんだ。nullptr_t が必要なところでリテラルの 0 が必要なのは問題ないだろ。
0 のかわりに NULL と書きたい奴が #define NULL ((void*)0) とするから問題なんだ。
コンパイラは int の rvalue が 0 かどうか判断するわけではなくリテラルの "0" だけをヌルポインタだと解釈するのだから、その指摘は的外れだ。

だから、そのリテラルの0がNULLポインタの意味なのか、整数の0の意味なのか、
コンパイラが判断できないっつってんだろー。頭悪いな。
そもそもC++でのNULLのdefineからして間違ってるし。
だれか>>881を教育して。

こう指摘してくれなきゃ。

f( void *p ){}
f( char *p ){}
f( int *p ){}


こんな風になってると、nullptrが有ろうが無かろうが、どっち道キャストは必要だよね、と。
そういう指摘なら俺もわかる。

ただ、nullptrが追加された事で、少なくとも、
f( void *p ){}と
ｆ( int i ){}の
どちらを呼び出すべきかはキャストなしで決定できるようになった。

まーしかしオーバーロードってマジむごいな。
諸悪の根源としか。何かがおかしいんだろうね。

そんなの、null pointerがひどいだけでは?

ふむ、型によって呼び出す関数を変える。
C++の型自体が割りとあいまいなものであるにも関わらず。
NULLポインタの0、暗黙の型変換、auto(←プログラマからは型が見えずらい)。
オーバーロードと柔軟な型、どちらを取りましょうかねぇ。

そのうちオーバーロードを禁止するキーワードが追加されたりしてな。

f(void*)
f(std::nullptr_t)

このときf(NULL)というかf(0)はどっちになるの

>>885
> C++の型自体が割りとあいまいなものである
C++の型付けって強い部類に入ると思うんだけど、あいまいっていうとどのあたり？
C互換の暗黙変換のことかな？それだとautoをこわがってる理由がわからないな。

オーバーロードが問題だと思うなら
オーバーロードしなきゃいいのに
使いたくない物は無理に使わなくても良いんだよ？

自分が使う分には使えるものは便利に使えばいいし
使いたくないものは使わなければいいだけのハナシなんだが、
他人が書いたオーバーロードだらけ、autoだらけのコードの
デバッグをやらされるなんてことを考えると非常に萎える。

やめてしまえ

autoもIDEが整備されてきたらautoが普通に見えるようになりそうだけどね。

C++はDB等の処理系を実装するために生まれてきた言語
C++自体にそれらがくっついていては意味がない

違うC++はＣにオブジェクト指向をつけるために生まれてきた言語

SQLiteにしてもMySQLにしても
C*用のライブラリ完備されてるからな
C*に標準で付ける必要は全く感じない

アナルセックスを想像しておしりの穴が熱くなる美少女中学生

>>895
お前に必要なのはC++0xじゃなくて病院。

autoあるだけでtemplate関係のコンパイルエラーが凄く見易くなる。
今まで特殊化して下請templateに任せていたものが、
auto一発で済むケースが多々ある。

autoも３項演算子みたいなもだ。拒否する人もいれば有効に活用する人もいるし、無駄に読みにくくする人もいる。

匿名の何かを受け取るのに必須じゃね

コンパイル時ネーミング演算子か
ｷﾓｽ

C++のラムダ使ったことないんだが
宣言内の関数のローカル変数にアクセスってのはもちろん無理だよな

C#ではクラスの関数内のローカル変数に、その関数で作ったスレッドがアクセスする形で
非同期処理書いたりいろいろお世話になってるんだがC++だとそこまでは無理だよな

日本語でおｋって感じだｗｗ
具体的にはこういうこと
まぁ普通に考えたら無理だわな

つかスレチ

void func()
{
　　int test = 0;

　　Thread thread = new Thread( 匿名関数
　　{
　　　　非同期処理。ローカル変数testにアクセスできるため、
　　　　わざわざ構造体作って渡したりする必要がない。解放忘れもない
　　} );
}

変数のキャプチャでググれ

__block int test;

>>901
s/無理/可能/
とすれば大体あってる。

> s/無理/可能/
s/無理/可能/g

>>902
void func()
{
　　int test = 0;

　　Thread thread = new Thread( [test]()
　　{
　　　　while(1){test++;}
　　} );
}

ってか？
ダメだよこれ

[test&]だとだめなんじゃないかとか。
C++0x予習中の俺が言ってみる。

[&test]じゃなくて？　あるいは[&]

>>906
現時点で、規格や、コンパイラ付属のドキュメントが読めんなら、
規格が制定されて、入門書が出版されるまで、おとなしく指くわえて待っとけ。

規格まで行かなくてもWikipediaに書いてある内容で十分じゃね？
それ以前に>>901はC#のスタックとヒープの扱いを理解できてないように見えるがスレチ

>>901,906
馬鹿は大人しく黙っとけ

最低限0xのWikipediaぐらいは読んでから書き込もうよ。
良くまとめてあるよ。

ああ、参照キャプチャは&いるのか
逆に覚えてた

まあ
void func()
{
　　int test = 0;

　　Thread thread = new Thread( [&test]()
　　{
　　　　while(1){test++;}
　　} );
}
だとしてもダメだけどな
未定義動作だ

コンパイルできるソースで語ってくれ。

言語仕様が確定している言語で語ってくれ。

mutableも知らんのかよ

c++lamdaを実装しているコンパイラはいくらかあるんだが。

>>901
std::thread* func() {
std::shared_ptr<int> test(new int(0));
return new std::thread([test]() { while (true) { ++(*test); std::cout << *test << std::endl; } });
}

shared_ptr/weak_ptr に対して reference_wrapper と
同様の機能を提供する何かは欲しい感じ．
ライブラリレベルでおそらく間に合う類のものだけれど．

>>918
boostのthreadと仕様が同じなら、funcの戻りはスレッドはshared_ptr<thread>で返していいと思う。
戻りがいらなければそのまま捨てられるし。スレッドが終わる前にthreadがdeleteされてもスレッドは最後まで実行するし、待ちたければjoinすればいいし。

C++0xでは、デストラクタのEffectについては、何も規定されていない。
ただ、このような注意書きがあるだけ。

[ Note: Either implicitly detaching or joining a joinable() thread in its destructor could result in
difficult to debug correctness (for detach) or performance (for join) bugs encountered only when an
exception is raised. Thus the programmer must ensure that the destructor is never executed while the
thread is still joinable. ?end note ]

値返してほしいならfuture使うなりasync使うなりすれば？

あとpackaged_taskか

ラムダを使って↓こんな感じのことをしたいのだが、ムリなんだろうか。

template <typename F, typename... Args>
F test(F f)
{
  return [f](Args... args) { return f(std::forward<Args>(args)...); };
}

>>924
アイディアとしては、なかなか面白いんだが、問題が二つある。

1. そのコードでは、Argsをdeduceできない。

2. lambda式の具体的な型を得る方法がないので、クロージャオブジェクトを、戻り値として返すことはできない。
std::functionなどに入れて返す必要がある。

そして、std::functionを使うなら、そもそもlambdaを使う意義はないわけで。

template <typename F>　F test(F f) { return f; }

で我慢する。

std::array<T>
と
std::valarray<T>
の使い分けが分かりません。
どこかに思想とか書いてありますか？

以前から
valarray<valarray<double>>
とか書く人をみて、どうかと思っていたのですが・・・。

APIはもちろん違うのですが、
コンテナとして読み書きの速度が違ったりするのでしょうか？
という質問です。

内部が連続してるコンテナってくらいしか共通点がないと思うけど

× std::array<T>
○ std::array<T, N>

arrayは固定長（配列のラッパー）
valarrayは可変長
普通は速度云々で使い分けるものじゃない。

valarrayのことは忘れろ。
あれは、中途半端なまま規格入りしたできの悪いライブラリだ。

そんなの多いよなぁ
使ってはいけない糞標準ライブラリのリストが欲しい所だ
つーか糞と分かった時点でさっさとAnnexDにぶち込んでくれよ

vector<bool>も廃止してほしいな。

boolのラッパクラスをかませてなんとかする方法は一応ある

廃止というよりは、実装するなら実装するもしくは他の要素を与えた時と同じ様にするなど、まともに使えるようになんとかして欲しい。

>>936
無茶言うなよw

無茶じゃないだろ。
言語規格からboolの特殊化部分を削除すればいい。

それは廃止って事?

>>935　！☆☆☆
なるほど、こうか。これは使える。
class Bool
{
bool a;
public:
Bool()
:a(false)
{
}
operator bool()const
{
return a;
}
bool operator !()const
{
return !a;
}
Bool& operator=(const bool b)
{
a=b;
return *this;
}
};

vector<Bool> c;

C++って、なんでこの変な仕様はほったらかしなの？とおもったら、代用する方法があるからなのか？。
スマポが長らく無かったのも「shared_ptr？欲しいなら自分で作ればいいんだよ。」がスタンスなんだね。

>>941
> 「shared_ptr？欲しいなら自分で作ればいいんだよ。」がスタンスなんだね。

「boostにあるだろ」が正しい。
一部のウィザード以外には。

shared_ptrとlokiを覚えて、mutexの処理分外したいなとか、intrusive_ptrもいるよなとかは、ふつうじゃないのか？

>>941
> C++って、なんでこの変な仕様はほったらかしなの？
腰が重いから。
その腰の重さがまたC++の良い所。

どっちかというと機能そのものより、「標準である」事がありがたい

本音と建前が交錯してるね。
shared_ptrやオブジェクト指向自体もそうだけど、
他人には使わせたいが、自分では使うべきではない。
何故かってそりゃお前、、、
世の中罠だらけでまいっちまうな。偉い人たちはうまい事考えるもんだ。

>>946
> 他人には使わせたいが、自分では使うべきではない。
> 何故かってそりゃお前、、、
？？？？

しかもバカは伝染するし、プログラマは庶民的な人が多いから、なおさら。
足止めだよ、これ、足止めだよ。正解とは程遠いよ、詭弁だよ、こんなの。
分かりやすい物に飛びついちまった事への罰だよ。

何があったか知らんが、落ち着け。

深呼吸して、はーい　いちにのさん

落ち着いたか？

>>948
> しかもバカは伝染するし、プログラマは庶民的な人が多いから、なおさら。
> 足止めだよ、これ、足止めだよ。正解とは程遠いよ、詭弁だよ、こんなの。

？
すまんが何を言っているのか俺の日本語読解力では分からん。

バカの伝染と庶民的な人と, あるいは正解と遠いことと詭弁と
どの点で対比しているの？

Linusの言葉を読めばいいんすか？

C#でも使ってろ

もちつけw
確かに、C++0xの仕様を見るとwwうぇっうぇっｗってなる気分は分かるが。

優秀な人材はもうオブジェクト指向やC++に興味は無いんだろうね。
きっと逃げ出しちゃったんだよ。だから0xはこんな感じだし、こんなに悲しいことは無いね。
そういえばC++にやたら詳しいニートみたいな奴が居たよな。
本書くから金よこせって奴。詭弁に詭弁を重ねるカス野郎。
あんなのと相性が良いのがC++だというのなら、
オブジェクト指向はバカの思考回路を具現化したものなのかもしれないね。
俺も自分で、「よくこんな無茶苦茶書くな」、とは思うよ。
でも半分ぐらいは当たってるのだろうから困る。

長々書いたが俺の言いたいのは唯一つ。
もはやバカと餓鬼どもの遊び道具になっちゃってるよ、この言語。
悲しくて悲しくて。言葉を遊び道具にするなよなー。

俺は別に飯さえ食えればいいから
C++がどうなろうと悲しくは無いぞ。

オブジェクト指向を新しいパラダイムの様に語る奴がまだいたのか
いい加減引退しろよ

もう枯れた技術なのにね

別にC++はオブジェクト指向言語じゃないんだが
オブジェクト指向も書けるってだけで

他人にはオブジェクト指向という餌を薦めておいて、
自分は腹の中でバカにしながら・・・
もう世の中そんななのか？

>>956
新しいと見せかけて、実は古風なパラダイムだから困る。
でも頭いい人は、古風なパラダイムを使いながらも、
その実全然ちがったパラダイムで組み立ててたりするからこまる。
一見ではそこの微妙な差に気づけない。こりゃバカが騙されるわけだ。
本当、巧妙で、ただただ感心するばかり。
うまいこと檻に閉じ込めておくものだなぁ。

続きはチラシの裏でどうぞ

また規格が制定される前にスレが埋まってしまった

C++0x 9 の次はやはり C++0x a だろうか

>>953
ニートみたいな奴じゃなくてニートだと思うが。
本を出版した瞬間にニートじゃなくなるが、
するまではニートだ。

不老所得があったら無職じゃなくても無職

>>964
> 無職じゃなくても無職
なんじゃそれは

すみません途中でそうしんしちゃいました
「を馬鹿にできない」が後ろに付きます

まあ、内心の自由までレイプしたいんなら
ぐうの音がでないくらいまでたたきつぶせばよかったんだけどね
せっかく3方向で包囲してたんだし

>>970
新スレよろ

止まっちゃったよ

makasero

>>953
有益な情報を何一つよこさない
おまえよりはまし

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

まだ>>972の>>1が
・type_indexさん
・System error supportさん
・Tupleさん
・Binder姉妹(bind1st,bind2nd)
・Function template bindさんと、Polymorphic function wrapperさん
・Time utilitieさん
・Compile-time rational arithmetic君
について書き下ろし中だから書き込んじゃダメだよ。

1が書いたのは5までで6は多分例の人

ああそうなのか。
でもいいじゃん、俺みたいな初心者には
(使い方は分からないけど)現状は分かりやすいから
・type_indexさん
・System error supportさん
・Tupleさん
・Binder姉妹(bind1st,bind2nd)
・Function template bindさんと、Polymorphic function wrapperさん
・Time utilitieさん
・Compile-time rational arithmetic君
についても頼みますどなたか。

えー
乙って書いちゃったよ

>>975
そいつらはネタが思い付かんかったんや

とりあえず今回と同じの書き込んだ。

Hoge *p = new (mem) Hoge;はできるのにdelete (mem) p;が出来ないと対称性が損なわれて気色悪いからできるようにして欲しいわ。へんな新機能たくさん付けるより今変なところを見直すのが先だろJK

static_cast<p_type*>(mem)->~p_type();
があるだろう。そもそもデストラクタを単体で呼べて苦労もないのにわざわざ対称性を維持するのが意味不明。
というかdelete(mem) p;ってなんだよ。memとpでどっちをdestructすればいいだよ。

>>980
わかってないこと自信満々に書き込まない方がいいよ

>>980
delete(mem) p;
free(mem);
って感じになるんかも。

そういう場合は、普通、自己責任で、psude-destructor callでデストラクタを呼び出した後、
p->~Hoge() ;
memの参照先を、自己責任の方法で、開放するのだ。

まあ、自前のallocator書け。

placement deleteなどがなく、また、deleteに追加の引数を渡せない理由に関しては、思想的なものだ。
メモリを確保するときには、あらゆる情報がわかっているが、
開放するときには、たいてい、そういう情報は分からない。
だいたい、ベースクラスへのポインタしかないってこともあるだろ。
そもそも、ユーザーが明示的にdeleteを書くべきではない。

>>979
http://www2.research.att.com/~bs/bs_faq2.html#placement-delete

型消去使え。
placement deleteを実装しようとすると生ポインタにdtorの型情報を入れないといけないからオーバーヘッドが増す。

>>985
え？

delete (args) obj を (obj->~T(), operator delete (obj, args)) に置き換えるだけの
シンタックスシュガーで済むでしょ。

new (arg) Tはoperator new (size_t, arg, ...)とコンストラクタを自動で呼んでくれるのに
デストラクタとoperator delete (p, arg, ...)を自動で呼び出してくれるdelete (arg) pが無いのがいやだって言いたかったんだけど・・・
生メモリの開放とかそういうことは関係ない話だよ

>>979
対象性を持たせるならコンストラクタ側だ。
hoge* a=reinterpret_cast<hoge*>(mem);
a->hoge(); //これをできるようにする。
a->~hoge();

>>988
構築子に開放処理も書かないといけないから、あんまりそうなってほしくないな。

なんでコンストラクタを明示的に呼び出せないんだろうね。
プログラマの責任で出来るようにして欲しいね。
それでなくても罠だらけなんだから、いまさらどうってこと無いだろ。
a->hoge();
a->~hoge();
a->hoge();
a->~hoge();
ってしたいし、

hoge(){...}

hoge( const hoge &r )
{
　　　hoge();
　　　...
}
ってしたい。

struct Hoge { Hoge() { ctor(); } ~Hoge() { dtor(); } void ctor() { ... } void dtor() { ... } };

Hoge *p = (Hoge *)malloc(sizeof(Hoge)); p->ctor(); p->dtor(); free(p);

うーん

普通の記法と区別がつかないとコンストラクタの二重の呼び出しを
チェックしよう、みたいなイディオムが流行りそうなんで勘弁してくれ

コンストラクタを明示的に呼び出せないのは
メンバ変数に参照とか持ってたりすると問題が出てくるからとか？

コンストラクタの明示的呼び出しはnew使って出来るからいいじゃん

下のは
hoge( const hoge &r ) : hoge()
{
　　　...
}
なら0xで出来るよ

>>990
> それでなくても罠だらけなんだから、いまさらどうってこと無いだろ。
俺が死ぬから勘弁してくれ

コンストラクタを明示的に呼び出せないのは、
コンストラクタはオブジェクトを作成する時に呼ぶものだから。
既にオブジェクトがあるのにオブジェクトを作成する時に呼ぶコンストラクタを呼ぶのは
ナンセンスというか、危険。

コンストラクタはメンバを初期化する処理なわけだが、
この時代入とは異なり、「メンバが未初期化である」ことを前提にしている。
例えばメモリを確保するようなクラスでは、
コンストラクタでは新たにメモリを確保すればいいだけだが、
代入では古いメモリを開放してから新しいメモリを確保する
（あるいは古いメモリをそのまま利用する）という処理になる。
途中でいきなりコンストラクタを呼べてしまうと、
古いメモリが開放されないまま新たにメモリを確保することになり、メモリリークする。

このように、コンストラクタは未初期化のオブジェクトに対して実行されることを前提にしており、
途中で呼べると危険なので、明示的に呼び出せないようになっている。

デストラクタが明示的に呼べるのは、
デストラクタはオブジェクトが存在していることを前提とした処理だから
別に呼べても構わないよねということ。
ただ、そのままだとオブジェクトの寿命が尽きた時にもう一度デストラクタが呼ばれちゃうけど。

どうしてもコンストラクタを後から呼び出したい場合は、placement newを使う。（#include <new> が必要）
Hoge hoge;
hoge->~Hoge();
new (&hoge) Hoge(); ←コンストラクタを呼ぶ
このようにデストラクタを呼ぶ事で「未初期化の状態」にしてやれば
コンストラクタを呼んでいい状態になるので、
その状態でplacement newを使えばコンストラクタを呼べる。
あとはstd::vectorみたいに一旦char配列で確保しておいて
placement newでコンストラクトするといった風に使う事もある。（というかこっちが普通の使い方）

char配列じゃなくて::operator new使えよ

実体は同じようなもんだから気にしない
もう行数制限近くて説明難しいし

そしてアライメントに苦しむ or なぜか遅い

1000

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。