C++11/C++0x 15

1 ：11/11/16

The C++ Standards Committee
http://www.open-std.org/jtc1/sc22/wg21/
Wikipedia
http://ja.wikipedia.org/wiki/C%2B%2B11
前スレ: C++11/C++0x 14
http://hibari.2ch.net/test/read.cgi/tech/1316760961/

2 ：11/11/16

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++0x 10
http://hibari.2ch.net/test/read.cgi/tech/1275375522/
C++0x 11
http://hibari.2ch.net/test/read.cgi/tech/1285884294/
C++0x 12
http://hibari.2ch.net/test/read.cgi/tech/1298470844/
C++0x 13
http://hibari.2ch.net/test/read.cgi/tech/1311240361/
親戚スレ
C1x
http://hibari.2ch.net/test/read.cgi/tech/1296642667/

3 ：11/11/17

痛みに耐えてよく頑張った！　1乙！
…奥さんとの会話は殆ど無いらしいよ？
そりゃあ、宮沢りえちゃんとは比較にならないよな、年上女房。

4 ：11/11/17

前スレ >>982
おおお、VCでもできました。ありがとうございます。
VCでラムダのメンバが見れなかったから、なんか特殊な物だと思っていたんですが
関数オブジェクトだったんですね。
前スレ >>985
可変長はVCではできないので、また今度お願いします。ありがとうございます。

5 ：11/11/17

結局 C++ 相談室との棲み分けはどうしたらいいの？
992 ：デフォルトの名無しさん：2011/11/16(水) 23:17:17.49
C++11はもう正式な標準になったんだから、C++11の話はC++相談室でいいだろ。
こっちはC++1xとか「次期C++標準」とか、そういうスレになるんじゃないの？
993 ：デフォルトの名無しさん：2011/11/16(水) 23:21:22.74
次期規格つっても5〜7年後だろ。
98?03?11って流れだからな。
ネタがないって。
994 ：デフォルトの名無しさん：2011/11/16(水) 23:21:59.16
最狂言語スレ？
995 ：デフォルトの名無しさん：2011/11/16(水) 23:22:54.74
>>993 ネタが無いならこのスレ終了ってことでいいんじゃね？
996 ：デフォルトの名無しさん：2011/11/16(水) 23:24:24.02
まともに実装されて普及されるまでは必要だな

6 ：11/11/17

あと1〜2年はC++11の新機能に関する
質問を受け付けつつ、次のC++の仕様を
夢見るスレってことでいいんじゃないの。

7 ：11/11/17

如何にしてC++相談室への平和的な侵略を試みるかについて話し合うスレ

8 ：11/11/17

棲み分けね
C++11 で不採用や延期になった proposal について語るスレでどうよ
まだ「C++0x」あるいは「C++11」で、「C++」ではなかった頃の話ってことで

9 ：11/11/17

C++11はまだ99%以上準拠した環境がないんだから
メインはこっちで

10 ：11/11/18

export非推奨になるかも…って話はいったいどうなったんですか？

11 ：11/11/18

exportはdeprecatedですらなく、廃止されました
C++11ではexportはただの予約語

12 ：11/11/18

call や overload みたいに予約語ですらなくならなかった理由は何だろう
まだ再燃する余地が残っているのかな

13 ：11/11/19

autoみたいに再利用するかもしれないからだろ
今は予約語確保するのも大変なんだよ

14 ：11/11/19

予約後も名前空間に入れてしまえばいいのに
std::auto x = hoge();
これで面倒な問題はだいたい解決する

15 ：11/11/19

過去に使われたからだろ

16 ：11/11/19

>>14
C++世代で識別子と予約語を混同する奴がいるとは思わなんだ。

17 ：11/11/19

C++世代ってなんだ？

18 ：11/11/19

水色時代

19 ：11/11/19

>>12
overloadって規格になる前に消え去ったことないか

20 ：11/11/19

>>16
Scheme だと特殊構文も名前空間 (Scheme 用語では library) に属してて、関数やマクロと一貫した扱いになってる綺麗な仕様。
混同する奴は問題じゃない。
区別しなけりゃならないクソ仕様な C++ に疑問を持たないお前が風の前の塵に同じ。

21 ：11/11/19

括弧バカ言語の信者こわい

22 ：11/11/19

C++はアホの言語ということを受け入れられない可哀想な子が居るね

23 ：11/11/19

それでもC++が圧倒的なシェアを誇りSchemeなど足元にも及ばない現実を
認められない可哀想な子がいるね

24 ：11/11/19

C++ が馬鹿でも使える優秀な言語であることは認めてやるよ。

25 ：11/11/19

C/C++も括弧バカ言語の範疇へ十分に入るよ

26 ：11/11/19

せやな
C++はバカ言語で決まりや

27 ：11/11/19

>>12
export 実装した処理系が少なくとも2つ存在してる。

28 ：11/11/19

>>25
Cを一緒にすんなよ。

29 ：11/11/19

callやoverloadだって実装はされてたろう、多分
その時代知らないけど

30 ：11/11/19

>>28
algol 系の begin/end ではなく {} を使うから「括弧バカ」だと言ってるんじゃないかな。

31 ：11/11/19

begin/end よりも {} の方が見やすいと思うんだが
begin/end 見ると目が痛い…

32 ：11/11/19

つか予約語の多い言語は総じてクソ。
beginやendがシンボル名に使えないとか
どんな罰ゲームだよ。

33 ：11/11/19

begin endって関数名にもよくあったりするから
あまり他のとこで見たくない

34 ：11/11/19

C/C++ は残念ながら比較対象に入ってないけど、
簡単な検証では Java が特に括弧が多いという見解が出てる。
http://e-arrows.sakura.ne.jp/2010/08/is-lisp-really-has-too-many-parenthesis.html
たぶん C++ も Java と似たような結果になるんじゃないかな。
言語はパラダイムの違いがあるから公平に「同じものを書いて比較」ってのが出来ないし、
この程度の単発のお題で結論は出せないけど、
世間で思われるほど他の言語より Lisp に括弧が多いということは無い。
言語の比較対象として Lisp を持ち出したときに括弧のところで思考停止するのマジでやーめーてー。
今回は識別子の扱いが一貫してる話で Scheme を出したのに何で括弧の話になってるんだよ。

35 ：11/11/19

お前がくだらない事書くからじゃねぇか

36 ：11/11/20

http://www.mahdiyusuf.com/post/9947002105/most-pressed-keys-and-programming-syntaxes
やっぱり多いような……w

37 ：11/11/20

式ごとにカッコが必要だから
当然多いわ

38 ：11/11/20

括弧つけるかつけないか迷うくらいなら、全部付けなければコンパイル通らない方が、頭使わなくていいし、間違いも少ない。

39 ：11/11/20

カッコの対応が・・・

40 ：11/11/20

なるほど、カッコの対応が正確にあっていなくてもいい言語が必要なようですね。

41 ：11/11/20

暗黙の結合規則で失敗するくらいなら、全部付けなければコンパイル通らない方が、頭使わなくていいし、間違いも少ない。

42 ：11/11/20

>>40-41
つまり括弧ないとコンパイルは通らないけど、
全部無視される仕組みって事ですね。

43 ：11/11/20

Lispのカッコが非常にうっとおしい。
Lispのカッコをなくすべき。

44 ：11/11/20

というかもうHaskellでいいです

45 ：11/11/20

右辺値参照を勉強し始めましたがさっぱりです。moveとforwardで躓きました。
8.3.2の↓をアホな僕にわかるよう誰か説明してもらえんでしょうか。
If a typedef (7.1.3), a type template-parameter (14.3.1), or a decltype-specifier (7.1.6.2) denotes a type TR
that is a reference to a type T, an attempt to create the type “lvalue reference to cv TR” creates the type
“lvalue reference to T”, while an attempt to create the type “rvalue reference to cv TR” creates the type TR.
void f(int &&a)のaは必ずint &&だけど、
template<typename T> void f(T &&a)に右辺値(0など)を渡すとaはT &&で
template<typename T> void f(T &&a)に左辺値(変数)を渡すとaはT &になる。何ですかコレ？

46 ：11/11/20

>>45
http://slashdot.jp/~taro-nishino/journal/507551
これ読むと解決。
多くの場合コピーコンストラクタと代入演算子と生成に関するパターンが注意のしどころの様子なので
これはイディオムになるような気配がするんだよんよんよん…

47 ：11/11/20

>>36
Lispだけ（）の打鍵数多くて目立つなあｗ
なんで、共通してeの打鍵数が多いんだろ

48 ：11/11/20

英語の中で e の出現頻度は飛び抜けて多い。
ってシャーロックホームズが言ってた。

49 ：11/11/20

符号化の基本だよね

50 ：11/11/20

>>48
モールス符号

51 ：11/11/20

>>40-41
多過ぎて対応取るのが面倒という話なのになぜそうなる

52 ：11/11/20

C++版可変長引数って配列を突っ込んだらそのまま使ってくれたりすんだっけ？
int
       array[] = { 1, 2, 3 };
Example
       a( 1, 2, 3 ),
       b( array );

53 ：11/11/20

配列の先頭要素へのポインタが渡される

54 ：11/11/20

オーバーロードするしか無いのか。
割と気が効かんね。
コンストラクターの委譲のおかげで多少シンプルにできそうだけど。

55 ：11/11/20

配列を引数に個別に展開とか何の嫌がらせだよ

56 ：11/11/20

ああ定数での渡し方を間違えてた。
Example
    a( { 1, 2, 3, 4} );
可変長引数じゃなくて、初期化リストっていうのかこれ。

57 ：11/11/20

std::initializer_list<int> 型で渡されるんじゃないのか？
g++だと内部エラーが出て死んでしまったが

58 ：11/11/20

って、もしかして a(...) じゃなくて a(std::initializer<T>) を想定してるのか？
まずは a のプロトタイプを教えてくれ

59 ：11/11/20

前者のinitializer_list<T>を想定してる。
要するに、↓ができないのは残念ねって事を言ってた。
int array[] = { 1, 2, 3, 4 };
std::initializer_list<int> a = array;

60 ：11/11/20

後者じゃないのか？

61 ：11/11/20

これでいいので実のところ大した手間ではない
template <typename Iterator>
void a(Iterator b, Iterator e) { ... }
template <typename T>
void a(std::initializer_list<T> list) { a(list.begin(), list.end()); }
using std::begin;
using std::end;
a({ 1, 2, 3, 4 });
a(begin(array), end(array));

62 ：11/11/20

見た目的にどうかってより、テンプレートの時どうかってね...。

63 ：11/11/20

template <typename T>
void a(T (&array)[]) { a(std::begin(array), std::end(array)); }
これも追加しておけば？

64 ：11/11/20

constわすれた

65 ：11/11/20

だから>>54にね。

66 ：11/11/20

いまさら組み込み配列なんか使ってんじゃねえ、とかｗ
#include <vector>

void fv(std::vector<int> const & v) {};

int main()
{
std::vector<int> v = {1, 2, 3};
fv(v);
fv({4, 5, 6, 7});
return 0;
}

67 ：11/11/20

そこはstd::arrayだろう。

68 ：11/11/20

>>66
だって動的メモリ確保おせーんだもん。
スタックでの配列確保なら1回の加算命令で済むのに、
ヒープ確保じゃ20命令以上使う上に分岐まですんだぜ。

69 ：11/11/20

1回のというか、関数の最初に全変数分の領域確保するから
他に変数があればコストは０
（キャッシュヒット率に影響は出るかもしれないが）

70 ：11/11/20

なるほど、それで小さいプログラムでは new とか malloc とか使わないのか。
スタック最強伝説。あせんぶりぶり

71 ：11/11/20

脇道
>> だって動的メモリ確保おせーんだもん。
事実であってもその遅さの比較は真実として意味のあるものなのか？
プログラムを普通に一時間使ってる間にある処理が複数回行われてあるやり方だと合計で1msかかるのが
別のやり方だと100倍遅くて合計で100msかかるようになったところでなんだというんだ。
よく言う高速化・最適化は実測が基本というのは本来はそういう視点で高速化すべきポイントを見定めるという意味のほうが大きかったんだぞ。

72 ：11/11/20

いやその例は体感できるだろw
0.1秒って結構分かるぞ
例を出すならマイクロ秒にしとくべきだったな
実際CPUの高速化で意味がなくなってる最適化も多いし

73 ：11/11/20

ベクトル系の処理だと、頻繁にメモリ確保なんかしてられないんだけど。
計算数が増える前に一括で領域をとっておき、
固定で済む範囲は、生配列を使わないと指数的に影響するときもある。

74 ：11/11/21

>>71
スレッド2つ用意して、1つのスレッドからデータ供給、
もう1つのスレッドからデータ読み取り。そのデータ供給の際、
1かつ確保したメモリを参照するパターンと、
毎回newしたメモリを引き渡すパターンを作って試してみ。
Mordern C++ Designにも書いてあった、C++のアロケータは
小規模メモリの確保が苦手というのがよく解ると思う。

75 ：11/11/21

vectorによるメモリ確保はゼロクリアも行われるよね

76 ：11/11/21

>>72
元の話は一時間での合計の差だぞ。つまり60*60*1000=3600000msと3600099msの違い。
一秒当たりにならすと1000msと1000.0275ms、1.0sと1.0000275sの違い。この差がわかるならたいしたものだ。
この考え方が理解できないなら一秒間に一回定期的に行われる処理の場合を考えてみな。
(その場合は理想的な例にすぎるが高速化のための実測データはこういう視点で解析する。)

77 ：11/11/21

>>76
ループで動的に確保してたら普通に遅い。
それだけの話に本筋とかけ離れた当たり前な事を言って何がしたいの？
ゴリ押しは気持ち悪いよ。

78 ：11/11/21

ん？ああ、一時間ってのを普通に読み飛ばしてたわすまんすまん
でも漢数字とmks混ぜんな

79 ：11/11/21

モサーリを改善しようとしたときに関数引数にvectorとかコンテナつこてるとあちこち書き換えしなきゃならなくなる
せっかくクドイC++で書いてんだから速度ヤバメな機能切れ目のやり取りには始めっから生配列を使っておこうや

80 ：11/11/21

>>77
オマエ国語力無いな。
ループとか関係なく、トータルの時間差が
意味があるかを考えるってだけの話が理解できないのか。
200nsかかる処理が1万回ループしたとして、
それがウェブの1回の処理の中だったら2msなんて誤差だろ

81 ：11/11/21

Webアプリだの速度が求めれれない環境の話しなんざしてないし
そんな環境でスタックだヒープだ気にはしない

82 ：11/11/21

速度が求められるプログラムを組んだ事無い人なんだろうね

83 ：11/11/21

そんなレベルの低い人はこのスレを見る資格無いよな

84 ：11/11/21

はいはいワロスワロス

85 ：11/11/21

速度原理主義者はクズ
高速化はハードに任せてソフト面では開発効率を最大重視するのが人類にとって有益

86 ：11/11/21

>>85
そういう用途にはシステム記述言語以外のものを使ってくれ。

87 ：11/11/21

>>85
だったらJavaでも使ってろよ。
お前自体がスレ違いだ。

88 ：11/11/21

Javaはないだろ……

89 ：11/11/21

「この新しくて軽い靴なら100M走のタイムが縮まるぜ！」
「（･･･その前に走行フォーム見直せよ･･･）」
「（･･･楽に走れる履きなれたのを使えよ。怪我するぞ･･･）」
「（･･･お前が走るのはマラソンだぞ。軽さより衝撃吸収性を考慮しろよ･･･）」

90 ：11/11/21

C++でシステム記述ｗ

91 ：11/11/21

>>90
何か問題でも？

92 ：11/11/21

>>85
ハード屋はクズってことか
ハードしかできない人ではなくハード「も」できる人まで
おまえさ、ソフトって何か本質がわかってねえだろ
せいぜい教科書で教わった程度の定義でもの言ってるだろ

93 ：11/11/21

重箱の隅つつくばかりの能無しが湧いてきやがったぜｗｗｗ

94 ：11/11/21

>>89
せいぜいRubyの靴を履いてフォーム改善に勤しんでろ

95 ：11/11/21

ハ
ハ
お
せ

96 ：11/11/23

おまえら全然C++11の話してないな

97 ：11/11/23

既に死んだ言語だし。

98 ：11/11/23

では今来た俺に教えてくれ。最終的に9月の規格にはどこまでの仕様が挿ったんだ？
・右辺値参照 + moveセマンティクス
・unique_ptr
・テンプレ可変湖引数
・ラムダ
ここまで理解した

99 ：11/11/23

そこまでだ問題ない

100 ：11/11/23

wikipediaあたりに載ってるよ

101 ：11/11/23

VC++で使えない仕様なんてゴミだろ

102 ：11/11/23

VCがクソなだけ
いいかげんVCなんて捨てろよ

103 ：11/11/23

商用コンパイラがGCCに比べて対応が遅くなるのは仕方ないだろ。
WindowsでVisual C++捨てろというやつの方が変だと思うぞ。仕事にならん

104 ：11/11/23

Intelコンパイラとか
Borlandコンパイラとか
Comeauコンパイラとか
会社でそれなりの地位に居れば
それなりの選択肢はある。

105 ：11/11/23

会社でそれなりの地位に居て決定権がありますが、
コード書くのは主に自分でなく部下・グループメンバーでなので、
チームで成果を出さないといけないので、自分はVC以外を選択する勇気がありませぬ(´・ω・`)
殆どのメンバーはラムダとか右辺値参照とか全く理解できないのです。下手をするとRAIIも

106 ：11/11/23

そんな会社で大丈夫か？

107 ：11/11/23

RAIIくらいは理解させといた方がいい

108 ：11/11/23

教育しろよカス

109 ：11/11/23

部署にもよるだろうな。
うちの特許レベルの技術開発してる部署だと、
主任レベルの人が社長と掛けあってIntel C++導入してたしな。

110 ：11/11/23

マ板向けの話ではあるが、
C++使う人なら、上級技術者と、それ以外とが
部署として別れてる会社に入ったほうがいい。

111 ：11/11/23

VC6 しか使わせてくれなかったので会社辞めたった
誰でも知ってる某大手子会社だぜw

112 ：11/11/23

boost使うの禁止とか言われたんで嫌々自分でスマポ作った思い出ならある

113 ：11/11/23

ITってかなり重要な部門なのに
なんでコンパイラごときで経費ケチケチすんだろうね

114 ：11/11/23

不法コピーしない限り、コンパイラってかなりばかにならんぞ

115 ：11/11/23

不法コピーしない限り、コンパイラってかなりばかにならんぞ

116 ：11/11/23

重い

117 ：11/11/24

禿20人とお前で開発環境はVC6でboostやstlport無し
と
お前任意数で環境はぼくのかんがえたさいきょうの開発環境
どっち選ぶ

118 ：11/11/24

>>104
ほかはわかるがBorland？
03のテンプレートすら怪しくないかそれ

119 ：11/11/24

Intel C++とハゲと俺まで読んだ

120 ：11/11/24

>>118
最新のコンパイラはほぼ規格準拠してるだろ。
てか、今はEmbarcaderoだっけ。

121 ：11/11/24

>>117
禿は規格無視したVC6使うぐらいならgcc使うんで仕事にならんと思う。

122 ：11/11/24

俺の考えた最強の開発環境がどの程度のものかによるな
あらゆるツールやライブラリにスパコンとかも使えるんだろ

123 ：11/11/24

ぼくのかんがえたさいきょうの開発環境
・ベース：Qt
・コンパイラ：clang++
・補助ライブラリ：boost
・バージョン管理：git
・作業OS：Fedora
他には？

124 ：11/11/24

補助ライブラリにAceとBlits++でも加えとくか

125 ：11/11/24

>>112
そもそも boost がない頃から極めて重要な関心事だったが

126 ：11/11/24

京つかったらコンパイルも一瞬だろうな

127 ：11/11/24

ぜひ、gccのフルビルドのスコアを教えてくれ

128 ：11/11/24

ネタ話はプログラム書けない奴が何とかかんとかスレでやれよ
せめて

129 ：11/11/24

Visual C++のIDEが使うコンパイラのファイルを
こっそりgccに入れ替えて、コマンドラインスイッチとかにも
対応してくれるようなのってない?

130 ：11/11/24

C++11でできた新たな「罠」って見つかってないのかな
>>45
のmoveとオーバーロードとかちゃんと理解してないとハマりそうな

131 ：11/11/24

とりあえずdecltype括弧問題

132 ：11/11/24

>>131
ｋｗｓｋ
もしかして括弧で囲むと参照になるやつのこと

133 ：11/11/24

int n;
decltype(n) i;　　　// int
decltype((n)) r;　　// int&
これね
id-expression ならその変数の型、
そうじゃなくて左辺値なら参照、
(n) は id-expression でなく左辺値なので参照になる、と

134 ：11/11/24

この挙動、左辺値でも参照でなく普通の型（上の例では int）にしたら
何か問題があったのかね

135 ：11/11/25

N1978 -> N2115 の改訂で、
「decltype((e)) は decltype(e) と解釈する」という条文が消えた。
理由は書いてなかった。

136 ：11/11/25

autoとdecltypeとtemplate型推論は同じかとおもってたが
decltypeだけそういう仕様があったのね
ほかにこの3つが違う型になる場合ってあるの?
auto a = ...;
decltype(...) a;
template<typename T> void hoge(T a){}
hoge(...);

137 ：11/11/26

この手の話を全部覚えて使いこなせとか無茶だろ・・・

138 ：11/11/26

気合の入ったライブラリを書く気がないなら必要ないから大丈夫だ
あとはsutter先生あたりの本が出るのを待つんだ

139 ：11/11/29

とりあえず次期仕様には
テンプレートコンストラクタのテンプレート引数を明示的に指定する
operator()のテンプレート引数を明示的に指定する
インスタンス化不要な関数オブジェクト static operator()
配置newのテンプレート引数を明示的に指定する
というか演算子オーバーロード全般のテンプレート引数を明示的に指定する
配置newに対応するdeleteの明示的呼び出し
namespaceのprivateメンバ
テンプレートnamespace
テンプレートでないコンストラクタの引数からテンプレートクラスのテンプレート引数を推定する
　template<typename T> struct A{ A(T){} }; A(1)と書いたらTがintと推定できるような
テンプレート定数 template<int a> static const int b = a * 2;
テンプレートクラスのテンプレート引数によるオーバーロード
テンプレート関数の部分特殊化
SFINAEをキモイ構文じゃなくて言語機能として実装
オーバーロードの優先順位を指定したい
動的declype
　struct A{ virtual vodi f() = 0; };
　struct B : A{ void f(){} };
　A *b1 = new B;
　A *b2 = new dynamic_decltype(*b1);　//Bのインスタンスができる
とか希望。
俺以外の誰もいらないと思うけど。

140 ：11/11/29

ーは１日３回まで

141 ：11/11/30

>>139
テンプレート関数の部分特殊化とdynamic_decltypeはほしい
それ以外はいらん

142 ：11/11/30

関数テンプレートの部分特殊化は入らんよ
オーバーロードがあるからね

143 ：11/11/30

テンプレートの特殊化はもちょっとどうにかならんかねぇ。
特殊化した型で、メンバー関数の実装を省いたら、
汎用型のメンバー関数を使うぐらいして欲しいんだけど。
メンドイ。

144 ：11/11/30

特殊化していない方を継承すればいい。

145 ：11/11/30

それじゃ、いらんもんが付いてくるので勘弁。

146 ：11/11/30

コンストラクタ引数からtemplate型推論は欲しいな
このためだけにテンプレート関数作ることが結構ある

147 ：11/11/30

>>146
単純なものだともう必要なくね？
Example<A, B> object = Type<Example>()(argA, argB);
型推論を使うと更にすっきり
auto object = Type<Example>()(argA, argB);

148 ：11/12/01

>>145
設計が悪い。

149 ：11/12/01

(:foo, bar:) みたいなのでtupleを返してくれるとか

150 ：11/12/01

std::make_tupleで何がご不満か

151 ：11/12/01

ながい

152 ：11/12/01

>>148
設計の問題か？
template<> class Vector<2>;
template<> class Vector<3>;
例えば、ベクトルを次元別に特殊化して作ったとき、
外積は2次元3次元で実装変えるけど、
内積は共通のものを使いたいとか普通にあるだろ。

153 ：11/12/01

あるある
というかまさにその例で

154 ：11/12/01

>>152
メンバ関数単位で特殊化すればそこだけ入れ替わるよ。
template <class T>
struct A {
　　int f(){ return 0; }
　　int g(){ return 100; }
};
template <>
int A<void>::f(){ return 1; }
データメンバは同じやり方では特殊化できないけど
データメンバまで入れ替わるような特殊化をしたなら
汎用のメンバ関数なんぞ役に立つまい

155 ：11/12/01

Vector<T, 2> / Vector<T, 3> だとそれ無理

156 ：11/12/01

>>154
それ処理系依存でしょ。

157 ：11/12/01

うむ。確かにダルイな
二桁近くのバリエーションに成れば対策講じるけど〜５種くらいならダサいなと思いながらもコピペ

158 ：11/12/01

>>156
gcc -pedantic でもいけるから、たぶん規格通りのはず。C++11 も関係ない

159 ：11/12/01

なるほどありがとう。多分当時触ったVCが糞だったんだろう

160 ：11/12/01

現状の汎用的な解決策は、異なる関数だけfriendなんだろうが、
オーバーライドはできないし、コンストラクターや
デストラクターはどうしようも無いんだよなぁ。

161 ：11/12/01

>>155
本当だ。部分特殊化はできないのか。

162 ：11/12/01

Vectorをfloat/double/long double、2/3/4（同次座標）で作りたかった時に
部分特殊化できなくて困った
結局コピペ

163 ：11/12/02

サイズわかってる行列とその演算はスクリプトで出力する派

164 ：11/12/02

template<> class Vector<2> : public Vector_base<2>;
template<> class Vector<3> : public Vector_base<3>;

165 ：11/12/02

結局俺もそれと同じような書き方してるな。
話が変わるが、Dのtypedef structってなんか問題あるの？
C++も組み込めばいいのに。

166 ：11/12/05

プリプロセッサがスクリプト並にリッチになればいいのに

167 ：11/12/05

俺用メモ
Amazon.co.jp： ゲームプログラマのためのC++: マイケル・ディックハイザー, 三宅 陽一郎, 田中 幸, ホジソン ますみ, 松浦 悦子: 本:
ttp://www.amazon.co.jp/dp/4797366761
ttp://togetter.com/li/223398
ttp://www.amazon.co.jp/gp/bestsellers/books/754384/

168 ：11/12/05

そこまで行くとスクリプトとmakeでいいじゃんってなる

169 ：11/12/05

初めてのC++11まだ出てないですか？

170 ：11/12/05

>>169
mayersがPDF売ってるよ

171 ：11/12/05

>>166-168
げてものでならば
C#をプリプロセッサとして使う ― CsPP
ttp://labs.yaneu.com/20111002/

172 ：11/12/05

コードジェネレータ系の欠点はエディタやIDEのサポートがなくなることだよな
そこまで自作してメンテナンスする気も起きないし

173 ：11/12/07

>>170
高橋真奈さんのやつです。

174 ：11/12/09

まなのC++本はNG入りのはずだが。
C++11対応を仮に書いたとしても期待できない。

175 ：11/12/12

dynamic_castを言語機能の中に入れてしまったのは間違いだったよね

176 ：11/12/12

なんでやねん

177 ：11/12/12

それ以外の言語機能でできることを、言語機能とはしないというポリシーはもともとないんだが

178 ：11/12/12

プリプロセッサw
自分で書けよw

179 ：11/12/15

int a = 0;
int &b = a;
int &&c = (int&&)a;
int d[2] = {};
int (&e)[2] = d;
int (&&f)[2] = (int(&&)[2])d; //error C2440: '初期化中' : 'int [2]' から 'int (&&)[2]' に変換できません。左辺値を右辺値の参照にバインドすることはできません
vc10のバグ? c++11の仕様?

180 ：11/12/15

MSVCのバグ。

181 ：11/12/16

thx

182 ：11/12/17

バグっていうより古いだけの気がする。
xvalue が登場する前の rvalue reference なんじゃないの？
配列の prvalue って存在しない気がするし。

183 ：11/12/17

よく考えたら配列の prvalue も存在するな…。
やっぱバグだな。
void f(int (&&a)[1]){ std::printf("%d\n", a[0]); }
int main()
{
　　struct X { int x[1] = { 10 }; };
　　f(X().x);
}

184 ：11/12/18

バグバグ言ってる奴
そのVCが出たのいつだと思ってるんだ？

185 ：11/12/19

β状態だし、期待するだけ無駄だよな。

186 ：11/12/19

いつかは関係ないよ
はなから不完全と言って出してんだから

187 ：11/12/19

vc11も対応項目あんま増えないらしいし
未実装というより、やる気ないってのが正しい気がする

188 ：11/12/19

C99と同じ運命を辿りそうだな

189 ：11/12/19

実装すらされないC99に比べれば
まだM$はやる気があるよ

190 ：11/12/20

やる気がないんじゃなくて
WinRT対応を優先させただけ

191 ：11/12/21

vector< vector< vector<int> > > unko;
C++11ってこれを簡単に書けるようになったんだっけ？
もしくは配列にデフォルトのコンストラクタがあってくれればいいんだけど
やっぱ無理？

192 ：11/12/21

vector<vector<vector<int>>> unko = { { {1,2,3}, {4,5,6}, {7,8,9} }, { {0,0}, {0}, {} } };
こういうの書きたいの？出来るよ

193 ：11/12/21

int unko[5][5][5];
に比べて長いのをC++11で簡単にかけるようになってないかなと
vector<int[5][5]> unko;
これでもいいんだけど
resizeでコンパイルエラーが出てて
多分int[5][5]();を呼びだそうとしてエラー吐かれてしまうま
Marray<vector<int>, 3> unko(5,5,5);
みたいの作らないと無理かな

194 ：11/12/21

>>191
template < std::size_t I, std::size_t J, std::size_t K > using Shit = std::array< std::array< std::array<int, K>, J >, I > ;
Shit<5, 5, 5> unko ;
まあ正直、
template < std::size_t I, std::size_t J, std::size_t K >
struct Shit
{
using type = std::array< std::array< std::array<int, K>, J >, I > ;
} ;
Shit<5, 5, 5>::type unko ;
とあんまり変わんないけどね。

195 ：11/12/21

usingもtemplate使えるんだっけ？

196 ：11/12/21

可変長テンプレート使えばええがな。
Array< int. std::vector >( 10, 20, 30, 4, ・・・);

197 ：11/12/21

なるほどー参考になったありがと
C++03の範囲で作ってみるよ

198 ：11/12/22

何でunkoとかshitとかなの？

199 ：11/12/22

だって美味しいじゃん。

200 ：11/12/22

<thread>ってないの？

201 ：11/12/22

threadsならあるよ

202 ：11/12/22

あるよ

203 ：11/12/23

『ゲームプログラマのためのC++』発刊２日目のつぶやきまとめ
ttp://togetter.com/li/231358
まとめ主は嬉しそうだな

204 ：11/12/23

スレ違いすぎる

205 ：11/12/24

マック関連の環境では全然受け入れられてないよね
linuxとwinでは動くけど

206 ：11/12/24

>>203
こういう奴のせいでゲーム屋はロリコンばかりだと思われるんだ。
アイコンのコピーライトはクリアできてるんだろうな？ 泥棒に宣伝してもらっても嬉しくないだろう。

207 ：11/12/24

>>206
ttp://www.madoka-magica.com/special/present/movies.html

208 ：11/12/24

>>206
実際多いからしょうがない

209 ：11/12/24

アニヲタっぽい話題ふってる人多いと思うよ
そして、そんな人の中にｽｰﾊﾟｰﾊｶｰがいたりする
C++11 Advent Calendar 2011でも見てみなよ
ttp://atnd.org/events/21936

210 ：11/12/24

17.6.4.3.5
_ で始まらないユーザー定義リテラルの接尾辞は、予約されている。
17.6.4.3.2
グローバル名前空間では、一つ以上の _ で始まる名前は予約されている。
→つまりユーザー定義リテラルは非グローバルな名前空間で定義しないといけない。
でもユーザー定義リテラルを呼び出すとき、
その名前空間を引数から判断することはできない。
(引数はプリミティブな型だから)
どうすればいいの…。

211 ：11/12/24

using でいけるんちゃうん？

212 ：11/12/24

operatorも含めて名前でおk

213 ：11/12/24

>>210
ユーザー定義リテラルの接尾辞は「名前(name)」じゃないので
17.6.4.3.2の制約を受けない
ってどっかで結論が出てたような

214 ：11/12/24

http://pc12.2ch.net/test/read.cgi/tech/1253280377/15-
あたりのはなしだな

215 ：11/12/24

0_hoge は operator""_hoge(0) とも呼べるんだよね？

216 ：11/12/24

>>214
トン。読んできた。
"hage"_x; // ここでは "hage"_x でひとつながりで切り出されるトークン
operator"" _x("hage", 4); // ここでは _x は独立したトークン
だから、普通に使うとき "hage"_x; は何の問題もない。
問題は定義するときや operator"" _x("hage", 4); という書き方をするときで
その場合でも _x は suffix なので、他の名前と衝突していても構わない、ということね。
で、あと問題はプリプロセスのマクロだけど
マクロで予約されているのはダブルアンダースコアか、_ + 大文字 だから
_ + 小文字 なら置換される可能性はないというわけだ。
なるほど。

217 ：11/12/24

#define _x a がある時の operator "" _x は
"" と _x が離れてるので１つのトークンとは見なされないから
operator "" a になるってのでいいの？

218 ：11/12/24

>>217
13.5.8-8 の第4例に
float operator ""E(const char*); // error: ""E (with no intervening space)
　　　　　　　　　　　　　　　　// is a single token
とわざわざ書いてあるので、 operator"" _x の場合
_x は独立したトークンだし、独立したトークンとして書かなければいけない。
だから #define _x a があったら operator"" a になるので正しいはず。

219 ：11/12/24

なるほど

220 ：11/12/26

http://www.suri.cs.okayama-u.ac.jp/servlets2/scm2cpp.rkt
Schme to readable C++
に自動型推論を導入してみました。まだ不具合が沢山あるので１ヶ月後ぐらいに見るといいかも

221 ：11/12/27

Sub<T>からTを取り出すようなtype_traitってないですか？
$ cat d.cpp
template <class Derived>
class Base {
typedef typename Derived::type type;
};
template <typename T>
class Sub: Base<Sub<T>> {
typedef T type;
};
int main()
{
Sub<int> s;
return 0;
}
$ g++ -std=c++0x d.cpp
d.cpp: In instantiation of ‘Base<Sub<int> >’:
d.cpp:7:7: instantiated from ‘Sub<int>’
d.cpp:13:12: instantiated from here
d.cpp:3:34: error: no type named ‘type’ in ‘class Sub<int>’

222 ：11/12/27

typeidでいいんじゃね？

223 ：11/12/27

template <template <typename> class Derived, typename T>
class Base {
public:
typedef T type;
};
template <typename T>
class Sub : Base<Sub, T> {
};
とかじゃだめ？

224 ：11/12/27

>>222
実行時は嫌かな。
>>223
Boostは引数たくさん与えるアプローチで、それに近い。
けどライブラリ側で頑張って仕事したい感じなんで。

225 ：11/12/27

ttp://stackoverflow.com/questions/6006614/c-static-polymorphism-crtp-and-using-typedefs-from-derived-classes
によるとこんな感じ。
メタにやるのは難しいのですかね。
template <typename T> struct trait;
template <class Derived>
struct Base {
typedef typename trait<Derived>::type type;
};
template <typename T>
struct Sub: Base<Sub<T>> {
typedef T type;
};
template <typename T>
struct trait<Sub<T>> {
typedef T type;
};
int main()
{
Sub<int> s;
return 0;
}

226 ：11/12/27

http://www.nicovideo.jp/watch/sm16529183

227 ：11/12/27

//テンプレートでない引数を入れた場合
template<typename T>
struct template_trait{
typedef T type;
};
//テンプレートを入れた場合
template<template<typename> class temp, typename T>
struct template_trait<temp<T>>{
typedef T type;
};
template<typename T>
struct hoge{};
typedef hoge<int> ihoge;
template_trait<ihoge>::type i = 0;
こんなかんじ?

228 ：11/12/27

>>227
良い。
こんなのもないのか・・・

229 ：11/12/27

>>225
> メタにやるのは難しいのですかね。
というかそもそも
template <typename T>
class Sub: Base<Sub<T>> { // (1)
typedef T type;
};
Base<Sub<T>>は(1)の時点で定義されるけど
その時点ではSub<T>は不完全型でメンバは未定義なんでBaseの中ではSub<T>のメンバに依存するものは定義できない

230 ：11/12/29

0xだと無名関数を束縛した変数つかって
関数を定義できるようになるよな。
auto Function = []()->int{ return 0; }
Function();
これ応用してクラスの中に書いたとき、
メンバー変数のメンバー関数の委譲に
使えたりはしないんかね。
struct T
{
     D member;
     auto Function = member.Function;
};
T object;
object.Function():

231 ：11/12/29

autoは無理だがstd::functionならいける

232 ：11/12/29

double a = -0;
はIEEE表現で0なのに
-a
とするとIEEE表現で-0になるバグはどうにかならないのかな
http://ideone.com/m27cn

233 ：11/12/29

0 も -0 も int(0)
http://ideone.com/WBvnH

234 ：11/12/29

メンバー関数とオブジェクトにドット演算子とアロー演算子を適用したときの演算結果って
相変わらず関数呼び出し演算子を呼び出せる何かなんだな。
いいかげん、建前だけでもラムダを返すって事にしてくれりゃいいのに。

235 ：11/12/29

>>233
なるほど

236 ：11/12/29

>>234
ラムダが暗黙の関数オブジェクトとして定義されているから循環参照になる。

237 ：11/12/29

>>236
実装上は問題ないじゃん。
object.Function;// この時点ではラムダ無し
auto lambda = object.Function; // 使用されるタイミングで初めてラムダ生成

238 ：11/12/29

C++「javaが二の足踏んでる間にλ入れちゃったぁ えへっ☆」

239 ：12/01/02

Javaには本気でほしい機能。あとイテレータの改善も。

240 ：12/01/04

質問。
ラムダ式って何が便利？
関数ポインタを引数にとる関数のテストには使えるかなと思ったけどそれ以外の使い道があるのか知りたいです。

241 ：12/01/04

>>240
関係のある処理を近くに書けるところ。
キャプチャーができるところ。

242 ：12/01/04

関数作るまでもないような処理を
そのままインラインで書ける

243 ：12/01/04

・関数オブジェクトのクラス定義を式中に書ける
・そのクラス定義を簡略記法で書ける
つまり、ソースの記述の面で書くときに楽になって読むときの可読性があがる。
と、実のところそれだけだけど適切に使えば効果は大きい。

244 ：12/01/04

ラムダがあるのにforにrange-basedの構文を追加したのは冗長だと思う

245 ：12/01/05

for(int i : v){
printf("%d",i);
}
std::for_each(v.begin(),v.end(),[](int i){
printf("%d",i);
})
めんどくせーと書こうと思ったけど
書いてみると大して変わらなかった

246 ：12/01/05

上の方がすっきりに見える

247 ：12/01/05

上で書けた方が格段にいいわ

248 ：12/01/05

lambdaじゃ引数にauto使えないしな

249 ：12/01/05

C++のforeachはめんどくさい
範囲指定するのがめんどくさい
引数の型書くのがめんどくさい
forとeachの間に_書くのがめんどくさい

250 ：12/01/05

boost::for_each(v,[](int){
printf("%d",i);
})
だと記述量はそんなに変わらんだろう
型推論はもうちょっと真面目にやれと思う

251 ：12/01/05

折角std::begin, std::end導入したんだから
conceptさん無くてもそういうアルゴリズムが欲しかったな
関数名変わっても良いから

252 ：12/01/05

concept_mapあればrange-based forがもっと効いてくるのになあ。

253 ：12/01/05

conceptさんなんでってしもうたんや…

254 ：12/01/06

std::vector<int> values;
For( &value ).Each( []( int i ){ std::cerr << "values:"<< i << std::endl; } );
どうせインライン展開してループに変わるんだから
こういう形式を標準で作ってくれればよかったのになぁ。
Sequence sequence( 1, 100 );
For vector_for( &vector );
Iterator *loop;
loop = &sequence;
loop = &vector_for;
loop->Each( []( int i ){ std::cerr << "values:"<< i << std::endl; } );

255 ：12/01/06

関数を
[] func( X x, Y y ) -> decltype( x + y );
みたいにかけるようになるのもラムダのおかげだっちゃ？

256 ：12/01/06

>>254 そういう形式で書きたかったら
自分でそういうライブラリを作ればいいじゃん

257 ：12/01/06

現時点で一番C++11が使えるコンパイラってどれなの？

258 ：12/01/06

GCCじゃないの？

259 ：12/01/06

>>256
書くけどさぁ。標準化されてないのが残念だなって。
標準化されてれば、こういう関数を、他の人のライブラリに対しても
使えるわけじゃん。非標準じゃ自分しか使えない。
template<class Iterator> F( Iterator i )
{
      //事前処理
      loop.each( [](int i){ this->container.push_back( i ) } ):
      //後処理
}

260 ：12/01/06

gccと比べるとmsvcの対応のお粗末さに泣ける

261 ：12/01/06

foreachみたいなものは、ライブラリではなく
言語の構文として実装してほしいなあ
言語自体を大きくするつもりはないらしいが
pararell_forよりもompのほうがしっくりくる

262 ：12/01/07

>>254
> For( &value ).Each( []( int i ){ std::cerr << "values:"<< i << std::endl; } );
このForは不要では?
&も。
Each(value, 〜)でいいのでは?

263 ：12/01/07

gccもまだまだ実装できてないものあるけどね

264 ：12/01/07

>>262
template<class Iterator> F( Iterator loop )
{
      loop.each( [](int i){ this->container.push_back( i ) } ):
}
引数で、ForやSequenceを受け取りたいから、それじゃ困る。

265 ：12/01/07

Boost.RangeとかPStade.Ovenとかじゃだめなの？
何がどう便利なのか分からない。
自分の書きたいように書きたいという気持ちは分かるけど。

266 ：12/01/08

コードのconst祭り状態を何とかしてくれ
規格で

267 ：12/01/08

>>265
所謂コルーチンと言われるものと同じメリットがある
別にテンプレートじゃなくていいのがひとつのメリット
他にも色々あるが書くと長くなって面倒だから、
コルーチンで調べて味噌

268 ：12/01/08

書けるものなら書いてごらん

269 ：12/01/10

>>266
はい sed s/const//g

270 ：12/01/12

245の例なんだけどさ、コンテナの要素の型名が糞長い場合ってあるじゃん？
std::shared_ptr<LongClassName> みたいな感じで。
そのまま書くとラムダが糞長くなっちゃって、for(int i = 0; ... 的な原始的
表記の方が短く書けることがあってさ。
こういうときは型名をtypedefして短縮する、というのが正攻法だと思うんだけど、
boost::for_each(v, [](decltype(v[0])& x){ process(x); });
ってしてもいいの？
gcc, vcともにコンパイルは通るし動きはしたんだけど、
あんまり良いことじゃないような気がして。

271 ：12/01/13

いいんじゃね？
でもその書き方だとrangeに対して一般的に使用することはできないな。

272 ：12/01/13

>>271
いいのか。thx。
ぶっちゃけvectorしか頭に無かったんだが、
コンテナ要素の型名を取り出す一般的表記、というと
decltype(v.back())、あたりが一番短い感じか。
[0]もbackも無意味なのが生理的にいまいちイヤだけども。
conceptさえあればこんなしょーもない記述も必要無くなるんだがなぁ……

273 ：12/01/13

標準コンテナならdecltype(v)::value_typeが本当は正解なんだろうけどな
VCじゃ使えないしオレオレコンテナでは定義されてるとは限らないし

274 ：12/01/13

そこでマクロですよw
昔、g++のtypeof使ったのよく書いてたよ。

275 ：12/01/13

定義されてるとは限らないはSFINAEでなんとかなるっしょ。

276 ：12/01/13

using std::begin;
decltyle(*begin(v))
こうしたほうがいいんだろうなあ

277 ：12/01/13

なんにせよdecltypeはキーワードとして長過ぎる

278 ：12/01/13

確かにdecltypeは長いな。
他に何か良い名称は無かったものか・・・。

279 ：12/01/13

#define d decltype

280 ：12/01/13

decltyan
少し読みやすくなった

281 ：12/01/16

#ifdef HAVE_LAMBDA
とか
#ifdef HAVE_DECLTYPE
みたいなことはできないものでしょうか

282 ：12/01/16

Boost.Config に BOOST_NO_DECLTYPE とか BOOST_NO_LAMBDAS とかある。
ttp://www.boost.org/doc/libs/1_48_0/libs/config/doc/html/boost_config/boost_macro_reference.html

283 ：12/01/18

0xのまとまった情報のあるサイト教えてください。

284 ：12/01/18

wikiじゃダメ？

285 ：12/01/18

とりあえずWikipediaかびゃーんの御大のページ(日本語訳もある)だろうな

286 ：12/01/18

ただ網羅してるだけじゃなく無用な部分を迷い無く読み飛ばせる文書を
纏まってると言うんじゃないかな

287 ：12/01/18

クラス名、メソッド名の命名規則なんだけどさ。
STL, Boost, LinuxAPI：小文字開始のスネークケース
WindowsAPI：大文字開始のキャメルケース＋ハンガリアン
Google：大文字開始のキャメルケース
自分は特に理由もなく大文字開始のキャメルケースを採用してるんだけど、
STLを使わないC++とかまずないわけで、そうなると小文字開始のスネークケース
の方が全体的に見て統制が取れてるような気がしてきたんだよね。
仕事じゃなければ好きにしろ、って話ではあるんだけど、
小文字開始のスネークケースはやめた方が良い理由って何かある？

288 ：12/01/18

すれち

289 ：12/01/18

ごめんC++のスレと間違えた。
287は無視してください。

290 ：12/01/18

(),[],{},<>と全部使う最強カッコ言語だな。
次は、どうすんだろう？

291 ：12/01/18

>>290
Eﾖとかじゃね？

292 ：12/01/18

<>をtemplateに使ったのは失敗だったな
$とか#を使えばよかったのに。
template #T #U class F;
F#int#int f;
…キモッｗ

293 ：12/01/19

>>290
＼(＾o＾)／

294 ：12/01/19

まだ@""とかL""とか""_xxxとか、
qw()とか@()とか%{}とかとかとか

295 ：12/01/19

>>286
「無用な部分」が読み手や時と場合によるんだから、無理だろ。

296 ：12/01/19

>>284
どこの？

297 ：12/01/19

>>287
禿曰く、小文字なのは標準ライブラリだから。
使う側の人はキャメルケース使えとさ。

298 ：12/01/19

>>292
Dの!は悪くないと思う

299 ：12/01/19

FORTHみたいに2-characterで囲い始めを表せばよかったんだよ
template.(typename T)class a{};
a.(int) i;

300 ：12/01/19

/ / が残ってるよ

301 ：12/01/19

>>300
/*コメントに使われてない？*/

302 ：12/01/19

それは /* */ だし

303 ：12/01/19

￥/があるな。日本人には見づらいが。

304 ：12/01/19

>>303
なあに。Linuxならバックスラッシュだし、Windowsでもフォント改造するから問題ないさ。

305 ：12/01/20

<>は比較演算子とシフトに使われているがかっことしては見やすい。
!()はきもいが明確。
「」とか【】とか、新しい括弧がキーボードから直接打てれば、
それが一番いいんだが。

306 ：12/01/20

>>290
括弧いいな
しかし、[[ ]]これはどうよ

307 ：12/01/20

それなら他と完全に区別できるかな。
attributesで使われる予定だったんだっけ?

308 ：12/01/20

attributeはC++11でも生き残ってるよ

309 ：12/01/20

やっぱりヌルポインタを nullptr にしたのは失敗だったな
nullpo にしておけば Java と一歩差をつけられたのに

310 ：12/01/20

なぜ null_ptr にしなかったのか。。unique_ptr や shared_ptr と整合性がとれない…

311 ：12/01/20

キーワードとクラスで整合性取られても

312 ：12/01/20

null_ptrだと
既存のプログラムで動かないのが出てくるから

313 ：12/01/20

< /> があるぜよ

314 ：12/01/20

なんだよそのXHTML

315 ：12/01/20

http://www.open-std.org/jtc1/sc22/wg21/
News 2012-01-18: The deadline for the next mailing is 2012-02-24
News 2012-01-18: The 2012-01 pre-Kona mailing is available
News 2012-01-18: The C++ Standard Core Language Issues List (Revision 78) is available

316 ：12/01/21

ところで tr2ってどうなったの？

317 ：12/01/21

C++1yとか何かと思ったらC++1x(C++0x)の次ってことか
次スレはこれだな

318 ：12/01/21

yだともう16進とは言い訳出来ないな

319 ：12/01/21

まあ、TR2はさすがに7年あれば十分だろ。

320 ：12/01/21

2003 - 1998 = 5
2011 - 2003 = 8
さあどうなるか

321 ：12/01/21

１０年後ぐらいか

322 ：12/01/21

yは17進数と言い張られる可能性が

323 ：12/01/21

つ　フィボナッチ数列

324 ：12/01/21

次はマイナーチェンジじゃないの？
なら大丈夫
static if とか入るなら嬉しいけどさ

325 ：12/01/21

【プログラミング部】 PHPが100倍速で動くようになったぞー
http://awabi.2ch.net/test/read.cgi/poverty/1327050821/

326 ：12/01/21

そりゃコンパイル作りゃ速くなるだろ

327 ：12/01/21

インタープリター型のVMが遅すぎるだけだ

328 ：12/01/22

http://www.open-std.org/jtc1/sc22/wg21/
News 2011-01-18: The C++ Standard Library Issues List (Revision 77) is available

329 ：12/01/23

禿って、C++11対応の「プログラミング言語C++」書いてくれてんの？

330 ：12/01/23

静的型推論でPHPが高速になったのなら
ちょっと使ってみたいけど

331 ：12/01/23

>>329
そりゃ書くだろ。
書かんかったら十字砲火浴びると思われ。

332 ：12/01/23

でも翻訳版が出るまで何年かかるんだろう…

333 ：12/01/24

猫でもわかるように頼む

334 ：12/01/24

猫には分かるが
お前には分からん

335 ：12/01/24

にゃー

336 ：12/01/24

せっかくユーザー定義リテラルさんがいるんだからと
二進数作ってみたけど
if(flag & 0x0101c0111c0000c0000_b) ...
とかするしかなくて、キモイ。普通にマクロで作ったのがマシだな。

337 ：12/01/24

なんでそんなキモイ作り方になるの

338 ：12/01/24

区切りを入れたいんだろう

339 ：12/01/25

ユーザー定義リテラルさん使えるコンパイラって今あるの？

340 ：12/01/25

区切りがないと二進数はかえって見づらいから
最初は "0101_0111"_b みたいにできないかなと思ったんだけど
user-defined string literal は constexpr にできない。
かといって 0101_0111_b にすると、_0111_b がサフィックスになる。
というわけで妥協して c で区切るというキモイものに。
ユーザー定義リテラルはこういう使い方をするためのものではないということがわかった。

341 ：12/01/25

>>339
gcc-4.7 の最新レポジトリのは大体の新機能が使えるよ。
template <char... args> long operator"" _b(){ ... }
template <char... args> long long operator"" _b(){ ... }
のように戻り値だけ違うものが普通にオーバーロードできてしまって
後者が必ず選択されるというバグっぽいものはある。
もしかしたらこれが規格通りの動作かもしれないけど。

342 ：12/01/25

色々バグはあるみたいよ
ttp://cpplover.blogspot.com/2011/09/gcc-47static.html

343 ：12/01/25

実装状況
ttp://gcc.gnu.org/gcc-4.7/cxx0x_status.html
大きな所は
・Alignment support
・Inheriting constructors
・Thread-local storage
あたりかな

344 ：12/01/25

>>340
> user-defined string literal は constexpr にできない。
そうなの？
↓こんなん書いてあったんだけど。
N337 13.5.8 [over.literal] p7
> ... Also, they can be declared inline or constexpr, ...

345 ：12/01/25

>>340
俺もそれほしかったんだが
そうか無理なのか・・・残念だ

346 ：12/01/25

文字列は静的な定数だけど
それでも配列要素にアクセスするのは
constexpr の範疇外な気がする
ポインタ演算だから

347 ：12/01/25

ポインタ演算というか、脱参照ね

348 ：12/01/25

いや、演算後の脱参照だ

349 ：12/01/25

>>340
constexperと可変長引数テンプレートの方がよくね？
b(1111, 0000);
そもそも2進直書きなんて何に使うんだよ。

350 ：12/01/25

>>346-348
別にそんな制限なくね？
http://ideone.com/gk4KE

351 ：12/01/25

ほんとだ。
文字列リテラルの dereference は定数として使えるんだ。
知らなかった…。
int main()
{
　　int a["0"[0]] a;
　　std::printf("%d\n", (int)sizeof(a));
}

352 ：12/01/25

ということは、
　　再帰できない、
　　return 文しか書けない、
　　仮引数は定数として使えない、
という制限のもとで
文字列を解釈して整数に直す constexpr 関数をどうやって書くかという問題になるわけだな。

353 ：12/01/25

宣言時に初期化されているconst配列と、constexpr配列の添字アクセス、ポインター演算は、
規格制定の最後の土壇場に認められた。
>>352
再帰はできるぞ。

354 ：12/01/25

constexpr 整数パーサとか既にあるぞ
http://d.hatena.ne.jp/osyo-manga/20120113/1326395185

355 ：12/01/25

>>353
あれ、ほんとだ。普通に許されてるねえ。
どこかで「再帰は許されない」って文面を見た気がするんだけど…。
ググってもソースがでてこない。

356 ：12/01/25

昔はむしろ再帰くらいしかできないクソ仕様だった

357 ：12/01/25

再帰出来なかったら constexpr の価値が下がりまくり

358 ：12/01/25

ソースは日本語版wikipediaだった。古いのかな >>355
今の規格では再帰は明確に許されている(Annex Bに「最低512回再帰を許せ」とある)
ところで constexpr 関数内でエラー処理が必要なとき
static_assert の中に仮引数を入れられないんだけど、どうしたらいいんだろう。
constexpr int f(int a){ return (a == 0)? a : throw std::logic_error("ふぇぇ"); }
constexpr int x = f(1); // コンパイル時にエラーが出てくれる
if(x == f(1)){ ...; } // 実行時にエラーが出る(コンパイル時に出てほしい)

359 ：12/01/25

リンカエラーにならできる
http://d.hatena.ne.jp/RiSK/20110713/1310540882

360 ：12/01/25

なんでstatic_assertできない仕様になったの？

361 ：12/01/25

constexpr関数は普通の関数としても使えるから。
関数内ではコンパイル時なのか実行時なのか判断できない。

362 ：12/01/25

なんでDの__ctfe変数みたいのを用意しなかったんだ
誰かC++1yで提案してくれ

363 ：12/01/25

>>359
頭いい

364 ：12/01/26

>>362
なんで自分で提案しないのさ？

365 ：12/01/26

>>360
できる。
というか規格嫁アホ。

366 ：12/01/26

main.cpp:3:2: エラー: non-constant condition for static assertion
main.cpp:3:2: エラー: ‘a’ is not a constant expression
って言われるぞ

367 ：12/01/26

>>365
static_assert を入れることはできるけど
static_assert する条件には仮引数を使えない

368 ：12/01/26

ああ、それか。
まあ、constexpr関数はコンパイル時に評価されることもあれば、実行時に評価されることもあるしなぁ。

369 ：12/01/26

こうなってくると、コンパイル時にしか呼び出せない関数がほしくなるな

370 ：12/01/27

実行時に評価される時は無視してくれればいいのに

371 ：12/01/27

ignore namespaceって
こういう使い方ができるのかな。
namespace another_lib{
void func1();
}
namespace my_lib{
//another_lib::を書くのが面倒なので
using namespace another_lib;
inline void func2(){ func1(); }
//my_lib::func1と書けないようにする
ignore namespace another_lib;
}

372 ：12/01/27

>>371
スレ違い。
ここはC++11スレだ。
そういう話はC++1yスレを立ててやれ。
まあそれはともかく、まだ大雑把に提案されただけで、規格の文面の用意されていない段階じゃねーか。

373 ：12/01/27

というかこれでいいじゃん。
#include <string>
void f()
{
　　{
　　　　using namaspace std ;
　　　　string s ;
　　}
　　std::string s ;
}

374 ：12/01/27

templateのADLがらみでしょ。

375 ：12/01/27

randomデバイスの挙動が意味不明なので、おしえてください。
intに入る非負だと思っていたのですが。
$ more rnd.cpp
#include <iostream>
#include <random>
using namespace std;
void echo(int val) {
cout << "why? " << val << endl;
}
int main()
{
static random_device rnd;
for (int i=0; i<10; ++i) {
echo(rnd());
cout << rnd() << endl;
}
}
$ g++-mp-4.6 -std=c++0x rnd.cpp
$ ./a.out
why? -1796924150
3042913710
why? -314325772
2069611482
why? 1357648257
1265153896
...

376 ：12/01/27

非負数ならunsignedで受けないと。

377 ：12/01/27

>>375
random_device関係ないし。
unsigned intからintへの変換でintの表現可能な範囲を超えているので鼻から悪魔を召喚してしまっている。
random_device::result_typeはunsigned intであり、intではない。
その値の範囲はrandom_device::min()とrandom_device::max()の間。

378 ：12/01/27

unsignedって一桁おおいのですね。あぁ恥ずかし。
ありがとうございました。

379 ：12/01/27

調べていたらこれに当たったのですが、
ttp://cpplover.blogspot.com/2009/11/c0xrandom.html
最後のuniform_real_distribution（あるいはuniform_int_distribution）
に到達する道のりが長すぎます。その後、何かショートカットできてたりしませんか？

380 ：12/01/27

しません

381 ：12/01/29

「とりあえずテレビをつける」のをやめようか
http://www.nicovideo.jp/watch/sm16774477
1/28　27日の朝生の感想 ＆ 岐阜にキムチの町があるらしい！
http://www.nicovideo.jp/watch/sm16814879
日本の年寄は情弱。一日中反日TVを見てる。
http://www.nicovideo.jp/watch/sm16812923
マスゴミの麻生さん叩きを検証しよう
http://www.nicovideo.jp/watch/sm16811530
外圧で日本経済の破壊工作をする馬鹿
http://www.nicovideo.jp/watch/sm16811102
【拡散】　民主党の新たな言論弾圧法案、[秘密保全法案]
http://www.nicovideo.jp/watch/sm16809977
法務省の「新たな人権救済機関」Ｑ＆Ａが国民を騙している件
http://www.nicovideo.jp/watch/sm16809271
【西部邁ゼミナール】安倍（元総理）の日本国民に訴える
1　http://www.nicovideo.jp/watch/sm16692013
2　http://www.nicovideo.jp/watch/sm16750147
3　http://www.nicovideo.jp/watch/sm16810518
【討論！】野田民主党内閣の本質と行方[桜H24/1/28]
1/3　http://www.nicovideo.jp/watch/so16804695
2/3　http://www.nicovideo.jp/watch/so16804716
3/3　http://www.nicovideo.jp/watch/so16804726

382 ：12/01/29

>>381
グロ？

383 ：12/01/31

マルチディスパッチはいつになったらはいんのよ。
Perlですら対応したんだから、言語も威厳を見せろよ。

384 ：12/01/31

ADLで我慢しなさい。

385 ：12/01/31

パッと見似てるけど、全然違うじゃんかよ?
オレ、アレがいい?。アレがいぃ?。
アレじゃなきゃヤダヤダ?(´・д・｀)
Perlくんも持ってんだよぉ?
買って買って?

386 ：12/01/31

あなたにはboostがあるでしょ！
うちは低水準なんだから我慢しなさい

387 ：12/01/31

dynamic_castで分岐すりゃいいじゃんいいじゃん

388 ：12/01/31

次の大規模な改訂で入るかもしれんぞ。
なにしろ、禿がいまだに諦めてないから。

389 ：12/01/31

クラス構造はそのままに制約無く実現するには関数の様に振舞う関数じゃないナニカを導入しないといかんから
またラビリンス度が上がるな

390 ：12/01/31

いや、禿の目指してるのはvirtual functionのmultiple dispatchだよ。
効率よいVFTの作り方を模索中(だった、かな?)。
>>n2216

391 ：12/01/31

bridgeパターンのdynamic_castは解決できるのん？

392 ：12/02/01

>>387
どうやってやんの？
関数追加するたびに、分岐書き換えたりしないんだよね。

393 ：12/02/03

>>340
Digit Separators coming back
http://www.open-std.org/JTC1/sc22/wg21/docs/papers/2012/n3342.html
入るといいね

394 ：12/02/03

インデントみたいに何桁区切りにするかで不毛な議論が行われるんだろうなあ

395 ：12/02/03

こういうの各自で解決するためのユーザー定義リテラルさんだったんじゃないのか
一体何だったのか…

396 ：12/02/03

何桁区切りにするかはconstexprで計算する

397 ：12/02/04

朗報
https://twitter.com/#!/visualc/status/165191796383686656

398 ：12/02/04

マジか！
range-based for 使ってみるとすごい便利だから嬉しい。
std::vector<std::shared_ptr<A> > vec;
for(auto it = std::begin(vec); it != std::end(vec); ++it){
　　it->func(); // 間違い
　　(*it)->func();
}
for(auto& x: vec){
　　x->func(); // こう書ける
}

399 ：12/02/04

range-based forどころかあらかた実装しろよ

400 ：12/02/04

C++11 だと
> std::vector<std::shared_ptr<A>>
でもおｋなんじゃ

401 ：12/02/04

挙動に違いがなければコーディングスタイルに突っ込まなくてもいいじゃない

402 ：12/02/04

MS's Visual C++ team invites you to complete this C++11 Conformance Survey
おまいらもやってこい

403 ：12/02/04

Visual C++ 11 Beta って言ってるけど既に2012年なんだよな

404 ：12/02/04

2011年に出す……出すが、今回その底の指定まではしていない
どうかそのことを諸君らも思い出していただきたい
つまり…我々がその気になればVisual Studio 0x2011にすることも可能だろう……ということ……！

405 ：12/02/04

一万年と二千年前から愛してる

406 ：12/02/04

八千年過ぎた頃から毛根がなくなった

407 ：12/02/04

C++11の準拠度を上げたVSという意味で申し上げた

408 ：12/02/04

g++ 4.7 並の準拠率でも微妙に不十分だってのに
それに遥かに及ばないんじゃ

409 ：12/02/04

>>402
どこだか探しちゃったじゃないか
http://blogs.msdn.com/b/vcblog/archive/2012/02/02/10263304.aspx

410 ：12/02/04

どれを優先的に実装して欲しいかの投票？

411 ：12/02/04

>>403
VC++2011じゃなくてVC++11だから
6 = 6
2002 = 7
2003 = 7.1
2005 = 8
2008 = 9
2010 = 10
って続いてきた通し番号だから

412 ：12/02/04

おお、そう言えばそうだな
近い数字だから惑わされてた

413 ：12/02/04

C++0xを踏まえたネタかと

414 ：12/02/05

C++11の仕様を一気に取り入れるのは難しいことなの？
働けやMS

415 ：12/02/05

なんでこんなに時間かかってるんだろうな。
あまり人員割いてないのか難しいのか。
インテルもgccもC++11全体で見るとどんぐりの背比べだよな・・・

416 ：12/02/05

いやー、この規模はそう簡単に実現できるものじゃないと思うけどな。

417 ：12/02/05

下手したら言語処理系史上最悪の複雑さかもしれん
Common LispやAdaがオモチャに見える……というと言い過ぎだがｗ

418 ：12/02/05

複雑だからプログラマーに仕事が生まれるっていう例のネタがさらに強度を増したな

419 ：12/02/05

コンパイラの実装が複雑な分、言語のユーザーはその機能で楽ができるって
ことなのか？

420 ：12/02/05

>>417
下手せんでも最悪。なんでこんな難解な言語にしたんだか。

421 ：12/02/05

>>417
http://www.kmonos.net/wlog/83.html#_1721080322
CLはまだ遠いが、Adaは確実に追い越してるだろうな。

422 ：12/02/05

>>419
楽できる機能は初期段階で挙動を把握しないといけないので、
それのコストがバカにならないとみんな嘆くのだ。

423 ：12/02/05

>>421
その比較だとC#やJavaの方が上じゃん

424 ：12/02/05

>>423
Javaはバイトコードの仕様まで入ってるからしゃーない。

425 ：12/02/05

意外とC言語からものすごい膨れあがってるってわけでもないんだな。

426 ：12/02/05

膨れ上がって入るけどg++が既に９割は実装してんだから
VC++もがんばれ

427 ：12/02/05

VCはC++/CX実装で忙しい

428 ：12/02/05

IDEもな

429 ：12/02/05

C++03
Managed C++
C++/CLI
C++/CX
C++11

430 ：12/02/05

C++11/CLI/CX

431 ：12/02/06

>429
C++AMPも入るらしいよ

432 ：12/02/06

Embedded C++ 「・・・呼んだ？」
Objective-C++ 「きちゃった・・・」

433 ：12/02/06

Embeddedはｶｴﾚ!

434 ：12/02/06

>>422
より少ないタイプ量からc++コードの自動生成が本来の目的だった
http://d.hatena.ne.jp/niitsuma/20120203

435 ：12/02/06

>>431
AMPって何？メタプロをサポートした拡張とか？

436 ：12/02/06

>>434
面白いなー。スキーム書けないけど。
このトランスコーダってどれくらい最適化してくれるんかねぇ。ベタ移植してくれるんかな？？

437 ：12/02/06

>>435
http://pc.watch.impress.co.jp/docs/news/event/20110617_453939.html

438 ：12/02/06

>>434
Ver 0.6 の Not support の項にある define inside define ってのは Scheme 用語で言う internal define のこと？
これは Ver 0.7 では関数内でクラス宣言することでなんとかしたってことでいいのかな。
lambda が使えれば展開後の C++ コードがもうちょっと readable な感じに出来そうだね。

439 ：12/02/06

>>433
Embeddedを甘く見るやつはEmbeddedに泣く

440 ：12/02/06

甘くも何も失敗作には近づかないのが吉

441 ：12/02/06

？？？

442 ：12/02/06

>>436
ベタじゃないと読めない

443 ：12/02/06

このスレでEmbedded C++がひどい失敗作だったことを知らない奴はいない

444 ：12/02/07

標準化委員会に(といっても実質は禿)、名指しで無意味な糞って言われるくらいだからな。

445 ：12/02/07

色々と肝心なものを削った結果、CともC++とも互換性失ったクソ言語だからな

446 ：12/02/07

だって仕様が減るEmbeddedを加えようが無いじゃん！

447 ：12/02/07

embeddedの言い訳がましさはすげぇよな。
どう見ても組み込み関係なく、
コンパイラ作れないんで、
これで許してちょだもんな

448 ：12/02/07

ぶっちゃけ、これが入ってればまだマシだったて言うのはどういう仕様？
調べたらこの仕様決めてる奴らトップが日本人なのか。ソフト弱いってレベルじゃねーな

449 ：12/02/07

例外はともかく、多重継承なしは意味が分からん。
ライブラリ全部自前で設計する必要あるじゃん。
C++のフル仕様のコンパイラ作るのが大変ってレベルで、
独自ライブラリを設計構築できる訳がない。
コンパイラの作成は努力の積み重ねで何とかなるが、
ライブラリの設計はセンスが要求される。

450 ：12/02/07

やめて！Embeddedのライフはもう0よ(ry

451 ：12/02/07

名前空間位言い訳せずにさっさと入れとけやと思った。
細かいとこはともかく、基本的なスコープはすぐ実装できたはずだ。

452 ：12/02/07

仕様のシンプルさと吐出すバイナリのシンプルさに相関成り立たないしね
フルC++にコンパクト化修飾子追加する形にすればよかったのに

453 ：12/02/07

テンプレートはまだしも、名前空間とか新形式キャストとか
実行時コスト0の機能まで考えなしに削ってるのが受ける
策定者は本当に馬鹿だったんだな

454 ：12/02/07

日本発の言語なんだからRuby見たく盛り上げようよ！

455 ：12/02/08

あんなもの、世に発表するのは、社会への害悪。消え失せい

456 ：12/02/08

>>454
ISLISPの方がまし

457 ：12/02/08

屍を動かそうとするのは愚か

458 ：12/02/08

>>453
名前空間は別として、新形式キャストは一貫性を保つためなんじゃね？dynamic castに配慮というか

459 ：12/02/08

何か生まれてきたことを土下座して誤らないといけないレベルの叩かれようだなｗ

460 ：12/02/08

とりあえず門田浩と田丸喜一郎は絶対に許さない

461 ：12/02/08

実際そのとおりだ。こいつのせいでクズコンパイラがバカ高い値段で売られることになり、
手を染めたコンパイラのその後の進歩（ISO仕様での実装しなおしなど）も遅れることになった。

462 ：12/02/08

叩き所がわかりやすい言語は
叩きやすくて良いよね

463 ：12/02/08

引き算するだけの言語設計も簡単だしね。

464 ：12/02/08

日本産のまともな言語ってRubyくらい？
なんか悲しいね。

465 ：12/02/08

プログラミング言語が諸子百家みたいに乱立する戦国時代よりマシだろ。

466 ：12/02/08

>>465
むしろその方がいいかと

467 ：12/02/08

多少書き方が似てるだけで、既に乱立状態だろ。
案外、百種類位余裕で揃えられそうだ。

468 ：12/02/08

C#のプログラムをJava ILにコンパイルするコンパイラとかないの？

469 ：12/02/08

>>468
Antlrの文法一覧にあったかもしれない

470 ：12/02/08

>>464
AnthyといいTuro Linuxといい
日本産のものを過剰に叩き過ぎだよなあ
iphoneがアニメキャラ名を一発変換→すげえ
anthyeがアニメキャラ名を一発変換→きもい

471 ：12/02/08

そのコピペ流行ってんの？

472 ：12/02/09

da yo ne

473 ：12/02/09

Anthyと並べるならTOMOYO Linuxだろjk

474 ：12/02/09

SELinuxでいいよね
あれ何のために存在してるの

475 ：12/02/09

（資金や労働を調達して）自分好みの環境を作れるヤツの贅沢な（企画厨的な）遊び

476 ：12/02/10

C++11のSTL拡張についてまだよく知らないんだけど、もうBoostが必要ないって
くらいにはなったの？

477 ：12/02/10

std::progress_display

478 ：12/02/10

>>477
ぷろぐれすでぃすぷれいたんはもう…ぶーすとにもいないんだ……・

479 ：12/02/10

彼女はね転校しちゃったんだ

480 ：12/02/10

std::egg
std::oven

481 ：12/02/10

std::even
std::odd
はまだですか

482 ：12/02/12

std::nullpo はまだですか

483 ：12/02/12

＼＼
＼＼＼
＼　 ∧＿∧
　 　（ ´・ω・）
　 　G　 　と）　ｶﾞｯ >>482
　 　 ヽ⌒)､ ＼人∧__∧
　 　　 ￣　（＿） >｀д´）')
　　　　　　　　 ∨つ　　 /

484 ：12/02/12

namespace fucking_std {
const struct {
template<typename T>
operator T() const { return nullptr; }
} nullpo;
}

485 ：12/02/12

#define fucking_std std

486 ：12/02/12

find . -print | xargs grep -l nullpo >rm

487 ：12/02/12

ｶﾞｯ

488 ：12/02/13

T&& 型の変数と、T&& 型へのキャストを使わずに
T 型の変数または、T& 型の変数を使って
decltype で T&& を生成する方法はありますか?
T a;
typedef decltype((a)) TT;
とやると T& になるように。

489 ：12/02/13

>>488
意味が分からない

490 ：12/02/13

>>488
C++言語の前に日本語の勉強をしたほうがいいんじゃないか？
エスパーで答えるとこうだな。
using type = std::add_rvalue_reference<decltype(a)>::type ;

491 ：12/02/13

最終的な目標はT&が欲しいのかT&&が欲しいのか

492 ：12/02/13

T&&が作りたいのですが、T&&という記述ができない前提なのです。
なので、add_rvalue_referenceは内部でT&&になっているので、使えません。
decltype内部でT&&を生成する必用があります。
decltypeで出てきたTに&&を付けるのも不可です。

493 ：12/02/13

decltype(std::declval<std::remove_reference<decltype(a)>::type>())

494 ：12/02/13

そうですか。

495 ：12/02/13

何がしたいのかサッパリわからん

496 ：12/02/14

すいません、具体的に申し上げますと
T = char[]なのです。
VC2010にバグがあるらしく、
T& と T&& という記述ができないのです。
ですが、
extern char a[];
decltype((a)) とすると char(&)[]
という型ができたので、
同じような方法で char(&&)[] を作る方法を
模索しているのです。
declval も add_rvalue_reference を内部で使っているので
使えませんでした。

497 ：12/02/14

char (&&)[n] はそう書けば普通に作れると思うが…。
どの変数も受け取れないというバグがあるだけで。

498 ：12/02/14

配列は右辺値にならない。

499 ：12/02/14

ああ、VC10か。
そりゃどうしようもないわ。
窓から投げ捨てろ。

500 ：12/02/14

あれ、配列って右辺値にならないんですか?
それなら作る必用ないかな…
ちなみに作りたかったのはchar(&&)[n]ではなく
char(&&)[]またはchar(&&)[0]です。

501 ：12/02/14

配列のprvalueはあるし（クラスのサブオブジェクトという形でしか存在しないと思うが）、配列のrvalue referenceもある。
MSVCがタコなだけだ。

502 ：12/02/15

なるほど、メンバなら右辺値参照もあり得るのですね。
struct A{
char b[];
} a;
A &&b = (A&&)a;
typedef decltype(b) C;
typedef decltype(b.b) D;
とやると、CはA&&になりましたが、
Dはchar(&&)[]にはならずchar[]でした。
なんとかここからchar(&&)[]を取り出す方法がないでしょうか?
この挙動もVC2010がおかしいだけ?

503 ：12/02/15

おかしいだけ

504 ：12/02/15

もう一つ言うなら、C++ には C と異なり長さ 0 の配列が存在しないので
「長さ不明の配列への参照」ではなく「長さ0の配列への参照」を作ろうとしているなら
それはそもそも規格違反。

505 ：12/02/15

vcでは>>502の a.a と>>496の a は同じ型と見なされているようです。
vcの規格違反である>>502の a.a のような長さ0の配列の入力に対応するのは不毛なのですが
>>496の a のような長さ不明の配列への対応は必用と考えてやっています。

506 ：12/02/15

もう諦めてvector<char>&&を使ったらいかがでしょうか

507 ：12/02/15

タコなのはCの配列だったんだお

508 ：12/02/16

CUDAがEmbedded以上にな件
削りすぎだろ

509 ：12/02/16

C++から削ったわけじゃなくてCからの拡張だからセーフ

510 ：12/02/16

http://forums.appleinsider.com/showthread.php?t=139011
CUDAがllvmになってC++11も動く？
本当？

511 ：12/02/16

clang –x=CUDA
なんてできるのか。驚き
http://stackoverflow.com/questions/9117109/how-to-compile-cuda-to-llvm-ir

512 ：12/02/16

最近のLLVMにはPTXバックエンドがあって、このPTXを
CUDAドライバに渡すとデバイスで動くバイナリに変換される
C++11が動くのかどうかは知らんが、ランタイムや構文
（構文を直接組み込まずとも、対応する機能があれば良い）を解決すれば動くかもしれん
ただ、何も修正しなくてもPTXにコンパイルすればGPUで並列化、ってことは流石にないだろう

513 ：12/02/16

CUDAに限らずGPU computingは、
CPUがメインで動くのが前提の計算モデルです。(ほんのごく一部のは除く)
並列化出来るところだけGPUに計算させる。
CUDAでは並列化を阻害するようなコードは書きにくいようにC/C++を制限している。

514 ：12/02/16

clang++ -emit-llvm でllvmコードはかせて
CUDAに流し込んだらだめなの？

515 ：12/02/16

開発環境に流しこんでどうするんですか?

516 ：12/02/16

何の前触れもなくいきなりCUDAの話をし始めたこの人は一体何者なのだろう

517 ：12/02/16

BOINC狂だろきっと

518 ：12/02/17

CUDAスレに移動します。CUDAでC++11使えるなら使いたかった

519 ：12/02/18

>>516
Embbeded C++へのネガキャンがnvidiaを売るためのステマだったから

520 ：12/02/18

それは斜めすぎるだろ
ステマ言いたいだけちゃうんかと

521 ：12/02/22

というか、ステルスマーケティングと言え

522 ：12/02/22

いちいち横文字にせんでもサクラでいいだろ

523 ：12/02/22

だいたい並行プログラミングを自動でやろうという性根が卑しいんだお

524 ：12/02/22

それでも、C++11のconcurrencyなら、何とかしてくれる！

525 ：12/02/22

C言語初心者ですが質問させてください。
conceptさんはいつ載るんですか？

526 ：12/02/22

コンセプトさんはお星様になったのさ

527 ：12/02/24

外からアルティミシアが入って来れないようにしてんだよ言わせんな

528 ：12/02/26

右辺値参照うけとるコンストラクタと代入って自動生成されますか？

529 ：12/02/26

されない

530 ：12/02/26

アザっす

531 ：12/02/26

コピーコンストラクターとコピー代入演算子も、
ユーザー定義のムーブコンストラクターとムーブ代入演算子、
コピーコンストラクターの場合はユーザー定義のコピー代入演算子、
コピー代入演算子の場合はユーザー定義のコピーコンストラクターが存在する場合、
暗黙に宣言はされるけど、その挙動はobsoleteだからな。
気を付けろよ。
将来廃止されるかもしれないぞ。

532 ：12/02/26

>>531
日本語版で書いてくれ

533 ：12/02/27

C++ で書いてくれ

534 ：12/02/28

むしろperlで書いてくれ

535 ：12/03/01

VC++11がVC++10(2010)とは一体何だったのかってぐらい規格合致度上げてきている件

536 ：12/03/01

beta 出たみたいだけどどうなの？

537 ：12/03/01

可変引数テンプレートいそげよ！

538 ：12/03/01

この惨憺たる状態から向上してんの？
ttp://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx

539 ：12/03/01

GCCやClangも機能一覧のNoが減ってきたね
並行性はどちらもまだNoが多いけど

540 ：12/03/01

iccはlambdaは早かったけどその後が全然だな
gcc/icc/vcで通るコードを書かないといけないからiccに足を引っ張られてる

541 ：12/03/01

コンパイラの開発が落ち着くまで03でいいじゃん

542 ：12/03/01

>>537
http://blogs.msdn.com/b/vcblog/archive/2012/02/29/10272778.aspx

543 ：12/03/01

遂にM$が本気を出してきたのか…

544 ：12/03/01

今までもいろいろな分野で戦いがあったが
最後に立っているのはいつだってM$だった
これからもそうなるだろう
そうWindowsPhoneもね

545 ：12/03/01

>>542
Variadic Templatesないじゃん。
単なるプリプロセッサーメタプログラミングじゃん。

546 ：12/03/01

MINGWがどこまで実装できたかの表はありませんか？

547 ：12/03/01

表はなくても裏がある

548 ：12/03/01

>>546
禿Webに書いてあるGCCの状況と
MinGWの現バージョンから導ける

549 ：12/03/01

ハゲwebってなんですか？

550 ：12/03/01

アデランスだよ

551 ：12/03/01

アートネイチャーでは手に負えなかったか

552 ：12/03/01

面白いと思って言ってるの？

553 ：12/03/01

笑わそうと思って書いてると思ってんの？

554 ：12/03/01

なんで質問を質問で返すの？

555 ：12/03/01

質問で返しちゃいけないなんてルールあるんですか？

556 ：12/03/01

それに答えるには余白が足りない

557 ：12/03/01

ここはお前の日記帳じゃねえんだコミットログにでも書いとけ、な

558 ：12/03/01

そっくりそのまま返したるわぼけ

559 ：12/03/01

　}

560 ：12/03/01

忘れないように橋に書き留めといた。

561 ：12/03/01

；

562 ：12/03/02

最近じゃARMCCが大事なんだぜ
あのコンパイラはロクなもんじゃないが

563 ：12/03/02

ガベージコレクタをC++に実装するか公式で議論が行われてるのはマジか？
mallocかnewが自作できれば、いらないような気もするのだが。

564 ：12/03/02

機構的には単なるスマポのシンタックスシュガーじゃね？
コンパイラによる最適化の余地が増える分だけ得って気はしなくもない

565 ：12/03/02

FAQを見る限りでは、C++11にはポインタが指す領域がGC用語で言う「到達可能（reachable、簡単に言えばオブジェクトが「生きている」という意味）」である事を明示的に宣言したり
ある領域にポインタがない事を宣言したりする機能が入ってるな
到達可能性の宣言はFAQに必要性が書かれてるから読めばわかる
二つ目はガベージコレクタには数値とポインタの区別がつかないから起こる
実際には到達可能でないオブジェクトを到達可能だと誤検出する（つまりリークする）事を防ぐための機能
俺の知る限り、C++のポインタは勝手にアドレスを変えたりできないから
C++のGC ABIではnon-movingなGCだけが実装できるはず

566 ：12/03/02

相互参照に対応出来るのかな？
スタックや非マネージドな構造体のメンバに置いたら原理的に
アドホックな対応しか出来なくなるから
C++/CLIのような感じになるのかな
と思ったけど
http://www32.ocn.ne.jp/~ons/text/CPP0xFAQ.html.ja#gc-abi
アドホックっぽい気がす

567 ：12/03/02

今回の規格ではライブラリ上でGCを実装できるように
最低限のことを決めたんですよ。メモリモデルとか。

568 ：12/03/02

メモリモデルについては決めたは決めたが正直これどーすんだよ的な気が
明示的な修飾したものだけマネージドにする割り切りがないとまたグダグダになりそう

569 ：12/03/02

strict GCのターゲットはC++でランタイムライブラリ書くような場合です。JVMとか。
C++のnative objectを対象にするのは相当先です。そっちは今のところコンサバのみ。

570 ：12/03/02

またゼロオーバーヘッドがないがしろにされる悪寒

571 ：12/03/02

別に将来GC必須になるって話じゃないよ
>>569
(un)declare_no_pointersはexact GCを実現するための機能じゃない？
もちろん、何もせずにexact GCになるわけじゃないから
現実的にはconservative GCにせざるをえないけど

572 ：12/03/02

次はもっとこの関数型のパラダイムをふんだんに盛り込んで欲しいな

573 ：12/03/02

http://www.open-std.org/jtc1/sc22/wg21/
News 2012-03-02: The deadline for the next mailing is 2012-09-21
News 2012-03-02: The 2012-02 post-Kona mailing is available
News 2012-03-02: The C++ Standard Library Issues List (Revision 78) is available
News 2012-03-02: The C++ Standard Core Language Issues List (Revision 79) is available

574 ：12/03/03

メモリーモデル決めたのは、言語仕様内でプログラム作っても、並列処理のメモリー制約が不定になるからじゃないの？

575 ：12/03/03

GCも込みだよ。papersに出てるし、ハゲもコメントしてる。

576 ：12/03/03

未だにテンプレートの定義ってヘッダに書かなきゃいけない処理系が
ほとんどなの？

577 ：12/03/03

むしろexportは廃止された
でも1翻訳単位内でのみ使うなら
別にヘッダで書く必要性はないで

578 ：12/03/03

あ、廃止されたんだ。
じゃあC++11でも依然として、複数の翻訳単位で使用するには
ヘッダに定義書かなきゃいけないのか。
なんでそうなったんだろ。コンパイラに実装するのが難しかったのかな？

579 ：12/03/03

複数の翻訳単位で使う場合もコピペすれば（ry
exportはオブジェクトファイル側に手を入れないと実現不可能だよね

580 ：12/03/03

マクロの高機能版だと思えば自然な制約。

581 ：12/03/03

コンパイル時に展開しないといけないから。
意図してこうなった。実行時オーバーヘッドを許容しない設計だから。

582 ：12/03/03

LTOとかやってるんだから同じ要領でexportもできるはずなんだけどな

583 ：12/03/03

実装者が出来ることだけやればいいのが最適化。

584 ：12/03/04

extern templateもなぁ

585 ：12/03/05

通常関数宣言にも可変引数使えれば良かったのにな。

586 ：12/03/05

ん？

587 ：12/03/05

使えるだろ
printfって関数をご存じない？

588 ：12/03/05

文字列に変数を展開するだけじゃ自由度少ないだろ。

589 ：12/03/05

何いってんのこいつ？

590 ：12/03/05

ご存じないならstdarg.hでぐぐれ

591 ：12/03/05

独立参照利用すれば、可変引数みたいなのは表現できない？

592 ：12/03/05

一瞬、何のスレだったかとスレタイ見直してしまった
たまたまアホばかりいるだけか、あーびっくりした

593 ：12/03/05

きめぇ構文使おうぜ
それっぽく見えるだろ
struct bb{
　　bb & bb::operator , (int i){std::cout<<i; return *this;}
　　bb & bb::operator , (const std::string& s){std::cout<<s; return *this;}
　　bb & bb::operator () (int i){std::cout<<i; return *this;}
　　bb & bb::operator () (const std::string& s){std::cout<<s; return *this;}
};
bb aa(){ return bb(); }
void f(){
　　aa(), "aa", 0;
　　aa()("aa")(0);
}

594 ：12/03/05

おぞましいな

595 ：12/03/05

無駄にカンマ演算子多用する輩はってよし

596 ：12/03/05

タイプセーフな可変長引数が使えたらいいねって話かと思ってたら>>588でビビった

597 ：12/03/06

Cの可変引数でいいなら、ポインタの型は全部void*でいいな。

598 ：12/03/06

可変で静的型安全にやりたければ、引数可変部は同じ型じゃないと仕方ないな。

599 ：12/03/06

現状だとiostreamやboost::formatみたいに
演算子をチェーンさせるのが現実的なのでは

600 ：12/03/06

オペレーターで連結するのは見た目がキモいのに加えてオーバーヘッドもあるしなぁ

601 ：12/03/06

オーバーロードできる演算子の種類が限られてるから、演算子の既存の意味と全く違う意味で使うことになるわけじゃん？
boost::format が % を使うのは iostream と組み合わせるときの演算子の優先順位を考慮したんだろうというのはわかるけど、
泥臭い方法だという感覚は否めないわな。
iostream の << はもうあんまり違和感ないから単なる慣れなんかな？

602 ：12/03/06

>>600
srdargに比べてどこがオーバーヘッド大きいですか?

603 ：12/03/06

>>602
それと比較してるのは今このスレで君だけだから帰っていいよ

604 ：12/03/06

>>585のバカ話はとっくに終わってます。

605 ：12/03/06

ということにしたいのですね。:)

606 ：12/03/06

よく分かってないんだけど
initializer_list使ってそれっぽくできないかな？

607 ：12/03/06

確かにinitializer_listが一番近そう
http://ideone.com/5P9Pa
もうちょっと構文糖衣して欲しい気もするけど
void f(const char* s, std::initializer_list<T> ls){
void f(const char* s, T... ls){
f("aaa", {10, 20, 30});
f("aaa", 10, 20, 30);

608 ：12/03/06

>>600
パフォーマンスに関しては、処理系にもよるけどインライン展開で消滅するから寧ろパフォーマンスは上がるじゃん。
まぁiostreamは遅いけど、あれはバッファの連携のせいだし。
話は変わるけど、Futureの例外送信機能ってどうやって実装されるんだ？
Worker側で一旦例外捕まえて、Worker作成側が、例外受け取るまで
一旦何処かにコピーしなきゃならないだろ。専用の例外しか投げれないとかか？

609 ：12/03/06

>>608 exception_ptr というものがあってな。

610 ：12/03/06

>>593
勉強になります

611 ：12/03/07

>>609
ありがとう。調べた。なんかランタイム情報取り出してる所が
typeinfo見たいで気持ち悪いな。素直にthread_exceptionとかでも定義して
その子クラスだけ返せるようにしたほうが良かったな。
どうせWorker中で他の例外に変換できなかった例外は
Workerの呼び出し元でも無視されるんだし。

612 ：12/03/07

>>611
それ何がうれしいの？
スレッドまたがせるためだけに原因と関係ない型を継承させる（カテゴリを作る）とか、
ありえないと思うんだけど。

613 ：12/03/07

>>612
スレッドの中で原因は完結させればいいじゃん。
最終的な答えを別の例外に委譲するだけ。
あと、スレッドを停止させた以上、スレッドは役割を
達成できなかったって例外カテゴリーに書き換えるから
どのみち同じだと思う。
例えば範囲外エラーを例外で捕まえたくなったら、
結局out_range_errorじゃなくてOnOutRangeThreadStopErrorみたいな
例外に書き換えるわけだし。

614 ：12/03/07

>>613
いや、だからそのカテゴリわけすると何がうれしいの？わけないといけないものなの？
別スレッドで実行するか元スレッドで実行するかなんて実装の詳細の一部になりうるんだから、
そんなのしたくないんだけど。

615 ：12/03/07

ほかのスレッドの例外と自分の例外の区別つかない方がずっとまずい。
そしてC++は言語には最低限の機能だけ付けて、ライブラリで実装する主義。

616 ：12/03/07

>>614
カテゴリっつうかスレッドのコンテキスト情報を添える事になるからねぇ
どういう状況かで例外処理を切り分けなきゃいけないじゃん
特にI/Oとか失敗したら、アドレスとか一部情報を書き換えて
再試行するって事もあって、再試行に必要なコンテキスト情報は送ってもらいたいよね

617 ：12/03/07

アドレスってのは送信先アドレスの事ね
別にI/O全般を例にしたからファイル名でもいいけど

618 ：12/03/07

>>616
その例で必要なのはI/Oエラーかどうかであって
thread_exceptionなんて分類は役に立たんだろ？

619 ：12/03/07

>>618
スレッド間受け渡しの実装のために継承しちゃいかんのか？
分類のため以外で継承しちゃいかんのか？

620 ：12/03/07

thread_exceptionを新設するのが素直な解決法にも思えないし
「Worker中で他の例外に変換できなかった例外はWorkerの呼び出し元でも無視される」というのが常に成り立つ確信もないんだが
こういう設計になってる言語があって、その言語を学べば分かったりするんだろうか？

621 ：12/03/07

Javaのconcurrencyで見たことあるな

622 ：12/03/07

スレッドでWorkerとか言い出す頭固い奴は嫌いだ

623 ：12/03/07

>>619
分類以外にその継承の目的があるならそれを挙げろ。
繰り返し聞かれてるのに何も挙げられてないじゃないか。
無意味な継承を強制することが受け入れられないのは当然。

624 ：12/03/07

>>623
TLSに一旦例外オブジェクトの実体をコピーし、
呼び出しもとスレッドの例外情報取得用領域にコピーするため。
この時、TLSに領域を確保するため例外オブジェクトの実体のサイズが
必要になったるんで、そのサイズ取得を定義する。
あと、例外送信元のスレッドIDやらスレッド関数の情報を積ませる。

625 ：12/03/07

>>624
それって今の仕組みの上にアプリケーションが必要に応じて組めばいいことじゃないの？
それともほんとに標準がそこまでやるべきだと思ってるの？だとしたらなぜ？

626 ：12/03/07

>>625
std::iostreamやらstd::string、std::vector、std::exception。
どれもユーザーが自前で実装しようと思えば出来るじゃん。
そんな事はどうでもいいんだけど、type_infoみたいに
ランタイム情報にべったりってのが嫌なの。
処理系に問題がある場合、自前のライブラリで
一部差し替えて互換性をとるとかしづらくなる。

627 ：12/03/08

実装できるかどうかなんて誰も聞いてないだろ。
「ランタイム情報」も何を指してるのかわかんないし。
コンパイラ実装依存の情報ってことなら継承もダメだよなぁ。

628 ：12/03/08

>>627
ランタイムってのは言葉端折ったけど、
ランタイムライブラリのことね。実行ファイルの中に
埋め込んだメタ情報やアセンブリレベルで
組み込まれた情報に依存してる訳じゃん。
継承とか目で見りゃ解るC++の構文上の互換性とは別の話よ。

629 ：12/03/08

ランタイム関係のトラブルについて具体的な例を書いておこう。
今回の例外とは関係無い話だけど、例外機構ってのはランタイム
ライブラリにべったり依存してる。昔流行ったBCC5.5なんてコンパイラじゃ
例外処理が正しく動作しなかった。言語構文上だけで解決できれば
自前でそれをカバーするコードを書けばよかったがランタイムライブラリの
中に絡み混んでるせいでマトモに手の出しようがなかった。
例外に限らずこういう事がVCやらGCCでもあった時期があったんで、
出来る限り、ランタイムライブラリに依存しない方向で言語機能を
実現してほしいなぁと思うんだよ。あと組み込み屋も大変だろうしね。

630 ：12/03/08

左様であるか

631 ：12/03/08

お粗末さまです。

632 ：12/03/08

正直どうでもいいな。話が噛み合わんわけだ。

633 ：12/03/08

>>629
ほんとにどうでもいい

634 ：12/03/08

vtableのアドレスを自前で列挙して比較すればいいよ

635 ：12/03/08

利便性のため標準的なスレッド補足情報を持つ
thread_exception的なものがあるのは良いけど
それしか返せないようにする必要は無いと思う

636 ：12/03/08

あほらし

637 ：12/03/08

>>630 >>631 >>632 >>633 >>636
具体的なことが書けないゴミはレスしない方がいいよ^^

638 ：12/03/08

糞処理系乙

639 ：12/03/08

そうだそうだ今時VCなんて時代遅れな糞処理系
つかってるヤツは情弱にも程がある。

640 ：12/03/08

A と B の値から C を設定・取得する場合に
std::map<std::pair<A, B>, C>
std::map<std::map<A, B>, C>
どっちでやるのがエレガントですか

641 ：12/03/08

このスレで聞くな

642 ：12/03/08

よく考えたら　std::map<A, std::map<B,C>>　こうだね
boost::assign的なチート級の技も踏まえたらこのスレに辿り着いてしまったのよ
堅いこと言わずに教えてくり

643 ：12/03/08

>>640
下はあり得ない
上か>>642だろうけど
ぶっちゃけどう比較するかじゃね

644 ：12/03/08

pairのほうはメモリ効率悪いからmapのmapかな
検索効率は偏りによるけどあんまかわらんだろう

645 ：12/03/08

>>644
|A|>>|B|だとmapの数が増えることのほうが問題になりそう。
pairよりもmapの方がメモリ効率が悪いから。

646 ：12/03/08

>>639
VCが何に使われているか実例を１つも知らないメタ情弱さん、ご機嫌麗しゅう

647 ：12/03/08

ランダムアクセスが前提ならmapのmapのほうが効率良くないか？

648 ：12/03/08

何の効率か言わないと。

649 ：12/03/08

正直、今時のCPUだったらどっち使っても大差ないでしょ
感覚的にはmap["key"][item]とかでアクセスできるからmapがいいんじゃないかなw

650 ：12/03/08

using std::make_pair;
A a; B b; C c;
_map[make_pair(a, b)] = c;
_map[a][b] = c;
こんな感じかな
後は気分の問題だと思うよw

651 ：12/03/08

mapのmapは列挙は面倒だな

652 ：12/03/08

みんなありがと
使い回す事を考えると後々mapのほうがやりやすそうだと思えたので
map の map を使うことにします

653 ：12/03/09

boostに多次元mapなかったっけ。勘違いか。

654 ：12/03/09

地図？

655 ：12/03/09

google mapを使えば楽だよ

656 ：12/03/09

google earthじゃなきゃ嫌だね

657 ：12/03/09

異次元のマップにアクセスするにはどうすればいいですか
ドラえもんみたいに色々な世界を旅したいです＞＜

658 ：12/03/09

次のC++の企画は開発されていますか？

659 ：12/03/09

C++1y

660 ：12/03/09

>>657
未定義動作のコード書いて運がよければ行けるよ

661 ：12/03/09

>>660
それってコンピューターが悲鳴上げてるだけじゃないですか
私　が　異　次　元　に　行　き　た　い　ん　で　す　！！

662 ：12/03/09

>>661
お前も行けるって
頑張れ

663 ：12/03/09

>>662
だからどうやって行くんですか！
以前だってlsコマンドの代わりにslと打ち間違えた時にせっかくお迎えが来たっていうのに
あろうことか私を置いて行ってしまったんですよ！
もういい加減お手上げしたい気分ですね！！

664 ：12/03/09

教室で涼宮ハルヒの憂鬱（初版、流行る前からもってた）を読んでたら
「なぁ、それハルヒじゃね？」と後ろの席のやつにいわれた。
ちょっと怖い煙草とかすってるやつだったから
「うん、ハルヒ。それの一巻」って説明したら
「○○って長門に似てるよな」とクラスの女子のことを指さした。
大人しくていつも読書している小柄で可愛いこだった。
たしかにそっくりだったし、長門にも彼女にも好意を抱いていたので最高の笑顔で「うん」と賛同したところ
おもむろに携帯で○○さんのを見せてくれました。
誰かハルヒのいる世界に連れて行ってください

665 ：12/03/09

まずはその話、本当かどうか確認する所からだ

666 ：12/03/09

生身の女はかならず男を作るから期待はしないことだ。マンガやアニメじゃないんだよ。

667 ：12/03/09

いきなりスレの流れが物故割れた

668 ：12/03/09

>>666
その認識も行き過ぎだと思うぞ

669 ：12/03/09

いい年して男と付き合ったことも無い可愛い女の子なんて実在しないだろ実際のところ
見た事無いぞ

670 ：12/03/09

実在すればそれはそれで気味が悪い

671 ：12/03/09

そりゃ死ぬまで純潔を守っても仕方ないよw
教室での話だったら学生時代だろ
そのくらいの時期ならチャンスもあろうに

672 ：12/03/09

VIPでやれ

673 ：12/03/09

ここはMIPスレですが何か？

674 ：12/03/09

マングリ返しで何かがでまんぐりんぐwwwwwwwっwwwうぇw

675 ：12/03/09

>>646
それがどうした？

676 ：12/03/09

}

677 ：12/03/09

それは、希望さ。

678 ：12/03/09

const Class< Base(int), Base(std::string) >
         &constructor = ClassType< Delived(int), Delived(std::string) >();
std::shared_ptr<Base>
         base1( constructor.New( 10 ) ),
         base2( constructor.New( "10" ) );
可変長テンプレートがあれば、こんなのがマクロ使わずとも
簡単に作れるんだろ、はよう実装してほしいわ。
なんであんなに対応が遅いんだ？

679 ：12/03/09

同時に絶望でもある

680 ：12/03/09

/*

681 ：12/03/09

*/

682 ：12/03/09

begin

683 ：12/03/09

end

684 ：12/03/09

imort java.io.Fire

685 ：12/03/09

imort hosii...

686 ：12/03/09

using ga::aru::jan;

687 ：12/03/09

int main = 0;

688 ：12/03/09

関数型言語　C++

689 ：12/03/09

インポートなんてインポテンツなもんはいらない
妹が欲しいって言ってるだけだっての！！
と、ミサカはミサカは>>685の気持ちを代弁してみたり

690 ：12/03/09

main :: IO()
main = return()

691 ：12/03/10

>>689
いらんつうかもっと高機能なusingが既にあるだろ。

692 ：12/03/10

むしろ俺の妹をもらってくれ、いらん

693 ：12/03/10

692の妹「な、なりたくてあんたの妹になってやったわけじゃないんだからねっ」

694 ：12/03/10

C++を理解する能力よりも妹がいる能力が欲しい

695 ：12/03/10

C++なんかどうでもいい。
俺は君が欲しいんだ！

696 ：12/03/10

冷静になれよ
オマエと同じ顔の女が増えるんだぜ？
堪えられるのか？

697 ：12/03/10

最近はテンプレートより、ソース吐き出すスクリプトでいいんじゃないかという気になってきた

698 ：12/03/10

配列をゴチャゴチャ記述するのが面倒なんで
スクリプトどころか表計算のTSV出力をincludeしてるわ

699 ：12/03/10

初期化に必要な情報で値も固定されてるならそれでもいいんじゃない

700 ：12/03/10

>>698
細かいけどCSV(Cはカンマ)な。TSVのTはタブだからincludeしてもエラーになるだけだ

701 ：12/03/10

そうやって読み込んだCSVのデータを、テンプレートでソートする…流石に内容が分かっていてもソートは無理か

702 ：12/03/10

>>697
それだとデバッガがな。

703 ：12/03/10

>>697
C++ with ScriptかCへのTranslatorだった時代を思い出すな

704 ：12/03/10

>>703
CFRONTだっけ？SS1+だと重くて悲しかったがかなり世話になった

705 ：12/03/12

cfront には超がつくほど世話になった

706 ：12/03/13

なんかノネナールの臭いがするよここ

707 ：12/03/13

違います！熟成したカレーの臭いです！

708 ：12/03/14

ふむ。
>C++11の次はC++17となりそう
ttp://d.hatena.ne.jp/faith_and_brave/20120307/1331103474

709 ：12/03/14

確か0xは最初C++08になる予定だったから
次はC++20ですね

710 ：12/03/14

C++2038

711 ：12/03/14

>>708
5年間でC++11をマスターしないといけないの(´；ω；｀)

712 ：12/03/14

ある言語でプログラムをするのにその言語の全ての機能を理解しマスターする必要はないだろ

713 ：12/03/14

全単語覚えたら、英語話せます？

714 ：12/03/14

>>708
03みたいなヤツか。C++11の処理系が完全になるのは2021年ぐらいか？

715 ：12/03/15

>>714
そしたら、C++17が遅れて、さらに処理系が完全になるのは何年か考えると、
もうC++はこれ以上覚える必要が無さそうだ(´・ω・｀)

716 ：12/03/15

ライブラリへの変更と言語仕様への変更は、
確かに分けて作業した方がいいと思う。

717 ：12/03/15

C++xxにすればいいのに
学習しないね

718 ：12/03/15

(：xx：)

719 ：12/03/15

マイナーは仕方ないが
メジャーではばっさり切り捨てもやれ
メタボ、しかも発癌してるのは切除しろ
特に例外。禿さまご乱心を黒歴史に早くしろ。
noexcept は廃止。二重否定はダメ。
throw でちゃんと作り直せ。
あくまでメジャーを標榜するのなら。
地味ながら普通の new もな。
特殊化のクソもいつまでgdgdやってやがる、
そういうところこそ禿、がんばれよ。

720 ：12/03/15

こんだけ年寄りなら癌でも進行が遅くて簡単には死なんだろうよ

721 ：12/03/16

http://msdn.microsoft.com/en-us/library/hh567368%28v=vs.110%29.aspx
何がどうpartialなのかちゃんと書けよオウ

722 ：12/03/16

二重否定がダメっていうのは、
英語(他の言語はしらない)の文法学者がただ気に入らなかったから、というだけなんだぜ。
ダメっていう雰囲気が蔓延する前は普通に使われていたんだから
noexcept を嫌う理由にはならない。
まあ throw(false), throw(true) ではなぜダメだったのかわからないけどさ

723 ：12/03/16

throw(Foo)のときにFooが型か値かで意味が変わっちゃうからだろ多分
どうでもいいのに

724 ：12/03/16

って書いてて今わかったこれだ
throw(Foo())
Fooが型の場合、引数なしでFooを返す関数の型を例外指定してるのか
デフォルトコンストラクトしたFooの右辺値をboolとして評価するのか区別が付かないから

725 ：12/03/16

あー constexpr と競合するってことね

726 ：12/03/16

まあtrue/falseでするとなるとthrowとは別のキーワードが欲しいわな
throwは型を取るものだから、使い回したくはない
かといってexpectとか普通に何かで使われる事あるだろうし
nothrowもstd::nothrowと被るしで
まず使われてないだろうというnoexceptになったのかねえ
throw<true/false> というのもキモいよなあ・・・

727 ：12/03/16

#includeはいつ廃止されますか

728 ：12/03/17

>>726
そういう時こそ[[ ]]を

729 ：12/03/17

>>727
廃止は当分無理だろうけど、
次回の規格改定には、かなりの確率でモジュールが入る。

730 ：12/03/17

またexportと同じ道を辿ることは無いのか

731 ：12/03/17

#includeなくなったらコンパイル時間短くなる？

732 ：12/03/17

理論的にはD言語くらいには速くなる

733 ：12/03/17

ないない
そんな簡単ならプリコンパイルドヘッダでもそれなりに速いはず
Dをなめてはいけない

734 ：12/03/17

C++っぽいけどC++じゃない言語を作ったらどうなの
C++からのトランスレータが作りやすい仕様にして

735 ：12/03/17

C++からのトランスレータって、結局フルのC++コンパイラを作るのと労力変わんないんだが
おまけに大抵のヘッダではマクロも込みでAPIだから、完全に活用するにはターゲット言語が細かい文法含めてC++完全上位互換である必要がある＝C++の新バージョンと変わらない
要するにC++は局所解にはまりこんでる

736 ：12/03/17

ついでに完全性を求めないなら、わざわざ新言語を作らなくても既存言語へのトランスレータは結構あるぜ

737 ：12/03/17

>>734
C++の機能を保ったまま文法を変更するって論文がどこかに転がってたと思うが、
まあ、やはりどうもC++の文法に慣れた身には見慣れない文法になってたな。
>>735
今のC++の思想は、既存の汚い方法（プリプロセッサー）は互換性のために残しつつも、
より優れた方法（constexpr）を導入して、
自発的な移行を促すってのだが。
うまくいくかねぇ。
なんだかんだいっても、字句単位での置換は強力だからなぁ。

738 ：12/03/17

>>737
思想とか関係ないよ
C++のヘッダからプリブロセッサがなくなっても、Cのヘッダを全くincludeしないとか無理でしょ

739 ：12/03/17

Ｃ＋＋を見限りたい気持ちでいっぱいだが次の言語が見つからない

740 ：12/03/17

ようこそＤ言語へ

741 ：12/03/17

やはりマクロが癌だよなあ

742 ：12/03/17

D言語は10年くらい仕様を固定できたら選択肢に入ってくる

743 ：12/03/17

マクロが癌は言いすぎ。右辺値参照とか、constexprとかの方が
｢もういいかげんにせえや！この禿のパリサイ人共が｣という気になるｗ

744 ：12/03/17

右辺値参照とかさっぱり理解できんけど
ただでさえ速いSTLが何もしなくてももっと速くなるなら有難い

745 ：12/03/17

インテリセンスの性能が悪いのも
リファクタリングし辛いのも
全部マクロのせいや！

746 ：12/03/17

トランスレータはデバッガ作るのが辛すぎる。

747 ：12/03/17

D言語作ってる人って、失敗作ばっか作ってる人でしょ

748 ：12/03/17

トランスレータはあくまで過去資源を利用するためのもので

749 ：12/03/17

rvalue referenceは当然の機能だろ。
というか今までの、constなlvalue referenceでprvalueを束縛できることのほうが変だっただろ。
まあ、この挙動は今更変えようがないがな。
まあ、別に理解できんユーザーが理解する必要はない。
コピーやムーブの実装はライブラリ作者が考えることだ。
>>744のいうように、STLがなにもしなくても速くなる。
C++11では、STLのクラスを普通に関数の戻り値として返しても、
何のパフォーマンス上の問題もない。
std::vector<int> f() ;
int main()
{
　　std::vector<int> v = f() ; // ムーブされる。ユーザーが詳細を理解する必要はない
}

750 ：12/03/17

何のパフォーマンス上の問題もない、は言いすぎだな。
ムーブ後の一時オブジェクトのデストラクタだって走るし、
ムーブコンストラクタだってただでさえ肥大化傾向の実行ファイルのコードサイズを更に膨らませる。
GCのある言語や v = f() ; を f(&v); として最適化できるタイプの言語ならこういうのは全撤去できるかんね。

751 ：12/03/17

かなり斜めだな。

752 ：12/03/17

>>749
うん、そうだ。
ま、せいぜい頑張ってくれ。
俺はつき合う気になれんがｗ

753 ：12/03/17

入れ物を引数で渡したり戻り値をauto_ptr<std::vector<int>>とかに
する必要がなくなっただけで十分ありがたいです

754 ：12/03/17

NVROも実装してなかったコンパイラがC++11をサポートできるのか

755 ：12/03/17

D言語はGCが余計だったんじゃないかと思ってる

756 ：12/03/17

>>750
つってもムーブ後のオブジェクトなんだから、
一切最適化されなかったとしても、関数呼び出しとか、
すでにムーブされた後であるかどうかを判定する条件分岐の実行とかそれぐらいだろ。
std::vectorだったら、確保した動的ストレージへのアドレスを格納している
ポインター型のメンバーが、nullptrであるかどうかの条件分岐ぐらいだろ。
コードの肥大化っていったって、
ムーブコンストラクターを書くのと、
ムーブ処理をその場にハードコードで実装するのは、
結局同じじゃないか。

757 ：12/03/17

>>756
発想がC++に縛られてるなあ。
例えばf()がv領域をallocaしてそのままvとして使うなら、そもそもムーブという概念自体要らない。
そういう言語もあるんだよ。

758 ：12/03/17

moveとか右辺値最適化とかの新機能についていけてないのだけど、
なんとなく>>750のように変換されるのかと思ってた。違うの？

759 ：12/03/17

違うよ

760 ：12/03/17

「最適化でコピーは消えてくれるよね……？」と心配しながら
ベクトルを返さなくてはいけなかったのが
「どうせムーブだし最適化されなくてもいいや＾＾」と安心して
ベクトルを返せるようになったってのはいいことだよ。

761 ：12/03/17

ムーブも一応ムーブのコストがあるからなあ
戻り値最適化が期待出来る部分ではムーブは劣る

762 ：12/03/17

コピーが最適化されて消えるところではムーブも消えるよ。
コピーなら消せる、ということがわかっている箇所で、
ムーブコンストラクタが定義されているときだけ最適化抑制するって
どんなアホコンパイラたよ

763 ：12/03/17

>>758
ユーザー定義する方針なんで、
変換してくれるってのは根本的に発想が違います。

764 ：12/03/17

>>754
出来れば嬉しい最適化と
必須の仕様の違いがありますから。

765 ：12/03/18

>>762
そういう意味じゃなくてだな・・・
戻り値最適化使った方がいいケースで
ムーブがあるからムーブでいいやとするケースの話で

766 ：12/03/18

どういうケースかよくわかんないからC++でお願いします

767 ：12/03/18

ものすごく適当な例
std::vector<int> a = hoge();
foo(a);
a = foobar();
bar(a);

768 ：12/03/18

vectorって代入される時にもともと持ってるデータを解放してるよな
ムーブでいらなくなったデータが一時変数のデストラクト時に解放されるのと比べて
本当に戻り値最適化のほうが性能的に有利になるのか？
ていうか、そもそも戻り値最適化って初期化する時だけしか有効にならないような

769 ：12/03/18

考えるほどムーブのほうが都合がいいという結論になる

770 ：12/03/18

2つ目のは戻り値最適化じゃなくムーブになる、という例だよ
swapの分だけコストはかかるはず
まあこの例だとこの程度どうでもいいんだけどね

771 ：12/03/18

>>735
現時点でアセンブリに変換できてるんだから、
完全上位である必要ないだろ

772 ：12/03/18

auto_ptrが理解出来てmoveが理解出来ない人は頭おかしい

773 ：12/03/18

auto_ptrはもはや理解する価値がない。

774 ：12/03/18

>>767
a = foobar();はC++03ではコピーになるからmoveより高コストになるな
それにa = hoge();でも
std::vector<int> hoge(){
　　std::vector<int> r;
　　...
　　return r;
}
のように書いた時点で戻り値最適化は効かないから
関数の実装にかなり制限が掛かると思うが

775 ：12/03/18

いや、効くだろ

776 ：12/03/18

>>774
NRVO搭載してるCompiler。具体的には、cl.exeなら最適化されるべ。

777 ：12/03/18

>>773
auto_ptrはunique_ptr+moveに置き換わるんだから当たり前だろｗ
C++11からC++に入る奴の話じゃねぇよ

778 ：12/03/18

流れぶった切るけど、noexcept()って、template<bool mode>てなテンプレート宣言したクラスで
noexcept( mode )って事ができるの？できないなら、throw()で十ぶんじゃね？なんの意味があんの？

779 ：12/03/18

できるだろ。

780 ：12/03/18

>>778
できるんじゃない？ そういう用途だろう、当然

781 ：12/03/18

boost::shared_ptr、std::auto_ptr、std::shared_ptr、
相互変換はどうすんだろうな。過去の資産を再利用するなら
古いポインター使いつづけるしか無いんだろうな。

782 ：12/03/18

まあそうなるな

783 ：12/03/18

はぁ?

784 ：12/03/18

相互変換とか

785 ：12/03/18

参照カウンタどうすんだよ

786 ：12/03/18

boostとstdのshared_ptrに互換性がないのが困る

787 ：12/03/18

別にboost::shared_ptr使い続けりゃいい
あるいはstd::shared_ptrに置換するか

788 ：12/03/18

C++11になって、事実上の廃止ってauto_ptrの他にどんなのがあるの？

789 ：12/03/18

unary_function類とbind1st類

790 ：12/03/18

あんまりお近づきになりたくない機能だと思っていたのでなによりです

791 ：12/03/19

bind廃止なのか…

792 ：12/03/19

bindが追加されたからいらなくなったんでしょ

793 ：12/03/19

boostのやつが導入されたんだっけ
別にラムダでいい気もするけど

794 ：12/03/20

テンプレ引数付きtypedefってクラス内のtypedefでも使えたりするんけ？
いままでクラス内クラスについてはテンプレに出来なかったよな

795 ：12/03/20

あーもうこんな複雑な言語、個人で使うならともかく、それなりのプロジェクトで使うとなると・・・。
これ、もう、オタクの玩具でしょ。

796 ：12/03/20

エイリアステンプレートはクラス内でも使える。
ただ、本当にメンバーテンプレートなエイリアステンプレートを使いたいのか？
苦労するだけだぞ。
struct X
{ template < typename T > using A = T ; } ;
template < typename T >
void f()
{
　　typename T:: template A<int> i ;
}
int main()
{
f<X>() ;
}

797 ：12/03/20

そもそも、システム開発用の言語がこんなに複雑な必要性って、在るのかねぇ。

798 ：12/03/20

システム開発用の言語だからこそ
高速化の為なら何でも取り入れるべき

799 ：12/03/20

システム開発的には安定性の方が重要だよ。
だから、Cでシコシコやってるのが丁度よい。

800 ：12/03/20

>>796
template< typename T > using Vector = Geometory::Vector<T, 2>;
ベクトルの次元は絞るが、型は何でもいい場合。一種のカリー化したいとき。

801 ：12/03/20

C11の_Genericみたいな糞機能はC++に輸入しないで欲しいよな
まあこれに限らずC11普及するのかよって話もあるけど

802 ：12/03/20

ABIを壊さずにオーバーロードを実現するための
_Genericは今更C++には無用だろ

803 ：12/03/20

C99すら・・・

804 ：12/03/20

>>799
安定性と「Cでシコシコ」の関連が不明です。

805 ：12/03/20

Cなら10年前どころか20年前のコード見ても古いと感じないが
C++の10年前のコードは腐臭を放ってる

806 ：12/03/20

それ、個人の慣れの問題じゃないの？

807 ：12/03/20

Cってだけで時代を感じるな

808 ：12/03/20

C++は仕様が固まってから日が浅いからね

809 ：12/03/20

>>808
まだ固まってない

810 ：12/03/20

使い方判らない機能は必要のない機能だから使わない方がいいよ。
いずれ、あー、こんな機能あれば安全なのになぁって必要になるときが来るけどね。
それまでは使わなくてよろしい。

811 ：12/03/21

>>810
基本はひととおり知っとく必要がある。
そうやって必要な知識を遠まわしにして、
ものすごい面倒で複雑なロジックにする
アホがいっぱいいるんだ。

812 ：12/03/22

積極的に使わなくてもいいが、知らなきゃ他人のライブラリは使えなくなるからな

813 ：12/03/22

規格そのものとは関係ないが、翻訳単位が関数単位に出来ないかねぇ。
一つの関数なおす度にファイル一本コンパイルしなおすっつうのもウザい。

814 ：12/03/22

1ファイル1関数にすればいいのでは

815 ：12/03/22

てめえで1つのファイルに書いておきながらうざいとか言っちゃう人って

816 ：12/03/22

そもそも構造違うけどSmalltalkなら関数(Method)単位で処理してくれるんだけどね

817 ：12/03/22

Common Lisp もな

818 ：12/03/22

(object.*function);
関数のポインタを逆参照したときの値って
未だ未定義なんだよな。もうクロージャにでもすりゃいいのに。

819 ：12/03/22

関数とメソッドの違いに注意な

820 ：12/03/22

メッセージを送るセレクタにより起動されるのがメソッド
ディスパッチで呼び出されるのがメンバー関数

821 ：12/03/22

最近はメソッドをまともに実装した言語も少ないな

822 ：12/03/22

int (__closure function)(int) = object.Function;
int (__closure function)(int) = object.*Function;
Borlandのコンパイラじゃこんな感じにクロージャに出来たんだけどな
C++本家にゃ取り込まれず今じゃ.net環境でdelegateとして活躍しとるとは
なんか皮肉だのう

823 ：12/03/22

>>822
だってそれDelphi互換用のためだけの機能だったし。
__closureって名前も紛らわしすぎる。ラムダが入った今となっては特に。

824 ：12/03/22

Delphi互換かどうかはどうでもいいし、別に__closureって予約語もいらん。
ただ、std::function<int(int)> function = object.Function;って書けるなら
ラムダ書かずに済んでありがたい。そもそも、関数がオブジェクトだってのは
Smalltalkの様で自然だ。

825 ：12/03/22

C#なみにラムダの記述量が減ってくれるとありがたいのだが

826 ：12/03/22

>>819
だよな。
メンバ関数のことをメソッドって言うな!! って思うよな。

827 ：12/03/22

それでもまだBlocksさんに比べれば……

828 ：12/03/22

>>824
変に規格に入って、VC++のABIがBorland(ってか現Embarcadero)のそれと違ってしまったら
肝心のC++Builderが困るじゃないか。

829 ：12/03/23

>>824
型が弱すぎ

830 ：12/03/23

>>829
なんだそれ？

831 ：12/03/23

>>828
ABIなんて今までも互換性無かったのに今更

832 ：12/03/23

クロージャっていまだに良くわからん

833 ：12/03/23

>>831
折角64ビットで統一されたんだから

834 ：12/03/23

Delphiってオブジェクト毎に関数ポインタを生成するために
動的コード生成やってなかったっけ

835 ：12/03/23

>>834
やってない。単なる関数ポインタとthisの組。Dのdelegateなんかも同じだね。

836 ：12/03/23

>>824
> std::function<int(int)> function = object.Function;
virtualだと単なるポインタじゃ済まないな。
関数内でthis使ってる場合も同様。
staticなメンバー関数以外、型安全にならないんじゃないの?

837 ：12/03/23

>>836
object.Functionの時点でVMT参照して解決してしまえばいいんでそれは問題ない。
C++のメンバ関数ポインタと違って、後でthisだけ(orメンバだけ)取り替えたりはしないんだから。

838 ：12/03/23

>>836
要するにstd::bindの構文糖にしろって事だけどわかってる？
auto function = object.Function;
auto function = std::bind( &Type::Function, &object. std::_1 );
それとも、もしかしてstd::functionの構造知らないの？

839 ：12/03/25

最近のC++のディスられようがウザい。
DなんたらとかHasなんたらなんてどうでもいい。

840 ：12/03/25

普通にC++について語ったらDisってるようになってしまう
C++がすぎるから

841 ：12/03/25

実用言語と実験言語を比べられてもな

842 ：12/03/25

そうそう、C++は実験言語なんだからdisってもしょうがない。
その成果は確実に実用言語に受け継がれているよ。

843 ：12/03/25

Ｄこそが真の実用言語だよなー

844 ：12/03/25

>>842
その実用言語って何

845 ：12/03/25

融通が利かないことを実用って言うのはちと無理があるわな
ネイティブ吐けてシステム記述できてCの資産が流用できる言語が他にないから
仕方なくC++使ってるってのが実際
いくら流行の機能入れても元が腐ってるからまともな言語設計が出来るはずもない
中の人に呪術染みた技巧コードを量産するテンプレートストが集まりすぎた
Dが実用ってのはもっと無理だ
書きやすくていいんだけど今んとこ遊びにしか使えないよ

846 ：12/03/25

＞Cの資産が流用できる言語が他にない
これは大きいね。Cは仕様がコンパクトでコンパイラを簡単に作れるから
「高級言語としてCだけはある」みたいな環境がぼろぼろ存在するからね。
Cの資産は膨大だ。

847 ：12/03/25

FFI知らんの？

848 ：12/03/25

欧陽菲菲ネ

849 ：12/03/26

もっとマシなものがあるなら流行っているはず

850 ：12/03/26

>Cの資産が流用できる言語が他にない
Objective-Cがあるだろ

851 ：12/03/26

はぁ？

852 ：12/03/26

Objective-Cは11よりだろ…

853 ：12/03/26

ObjCがなのは否定しないけど、なんでなのかというと追加された文法がCから見てキモいからだろう。
(機能的には、OOP部分と組み込み型が別体系ってのは珍しくない。JavaやDもそうだし)
C++もenum classやunified function syntaxでCとは別物を被せる方向に舵を切ったじゃないか。ObjCのことは言えないと思うぜ。
あと曲がりなりにも実際に大規模に使われてる言語に対して「はぁ？」とか反応しちゃう視野の狭さが、
もっとマシなものが出てこない一番の原因と思うね。

854 ：12/03/26

例え嫌々だろうが必要な時に使えて目的に適うならそれでいい。それがC++。

855 ：12/03/26

C++は落ち目

856 ：12/03/26

じゃあ上り調子のＣ＃でも使うか

857 ：12/03/26

ObjCはCの理念と反するからな
実行コストがかかりすぎる

858 ：12/03/26

けっきょくC++しか選択肢がない

859 ：12/03/26

そう思ってるのはC++使いだけ
C使いはC++も実行コストかかり過ぎだって思ってるよ

860 ：12/03/26

けっきょくC/C++しか選択肢がない

861 ：12/03/26

あぁ、「思ってる」な。知ってるぜ。

862 ：12/03/26

そう思ってるのはC使いだけ
アセンブラ使いはCも実行コストかかり過ぎだって思ってるよ

863 ：12/03/26

でもC++は落ち目で、Cはそうじゃないけどね

864 ：12/03/26

CもC++使いもあと数年すればＤに駆逐される運命だと言うのに哀れよのぅ

865 ：12/03/26

>>849
良いものは自然と普及するという考え方はやめた方がいい

866 ：12/03/26

Dってそんなにいいか？

867 ：12/03/26

Dは誰にも見向きされずに消えていく…

868 ：12/03/26

D覚えるくらいならC++と他の高級言語を使い分けるほうがいいからな

869 ：12/03/26

C++覚えるぐらいならCと適当なスクリプト言語でいいって層の方が多いと思うぜ

870 ：12/03/26

Dは配列でLinqできるのが面白かったけど、発展途上の時はメインには押し難い。GCはプラス要素だと思うんだけど。

871 ：12/03/26

Objective-Cの実行コストってCに比べてどんくらい落ちるもんなの？
Effective C++の序文によるとC++は5%以内ってハゲが決めてるそうだけど
Objective-Cにもそういう約束事があるのかしら？

872 ：12/03/26

>>871
Objective-Cのメソッド呼び出しはインタプリタ言語並の遅さ

873 ：12/03/26

Objective-CはC++でラップしてしまえば
後はC++で作れる

874 ：12/03/26

な、俺の予想したとおりになったろ

875 ：12/03/26

ああ、すごいごい。
で、どんな予想したの？

876 ：12/03/26

>>859
そういやCよりC++の方が遅いとはよく聞いたが、
あれの根拠はなんなんだ？実行イメージのロード時間？
C++のライブラリ使わない限りCと速度が変わることはないはずだが。
あと、C++のライブラリ使わず単に言語機能だけでコードを組むと
大概Cより速くなるんだがな。仮想関数とか分岐が固定されてると
インライン展開されて構造体に突っ込んだ関数のコールバックより速い。

877 ：12/03/26

>>872
どんな言語でもメッセージ送信と同等の機能を組めば同じような速度だろうけどな。

878 ：12/03/26

>>876
C++にはrestrictが無い（コンパイラの独自拡張を除く）

879 ：12/03/26

>>878
なにC++11ならあるだろ。じゃないとインターフェース互換なくなる。

880 ：12/03/26

Cとインターフェースレベルでの互換性なくしたら標準ライブラリとか阿鼻叫喚になるわな。
何が楽しくて同じ関数をC用とC++用二つもつくらにゃならんのだ。

881 ：12/03/26

>可変長配列 (VLA) は含まれない (天のお恵みに感謝！)
http://www32.ocn.ne.jp/~ons/text/CPP0xFAQ.html.ja#C99
何がお恵みに感謝だよ。シネバいいのに。

882 ：12/03/26

C++11にrestrictがあるというソースくれ

883 ：12/03/26

ねえよ

884 ：12/03/26

>>882
restrictがあるというと正確ではないかもしれんがC++ 11 FDIS §17.2のあたり

885 ：12/03/26

>>871
んなこたぁない

886 ：12/03/27

>>884
C++にはrestrictが無いって書いてあると読めますね

887 ：12/03/27

より正確には、CのライブラリにrestrictがあってもC++はそれを無視すると書いてある
> The descriptions of many library functions rely on the C standard library 
> for the signatures and semantics of those functions.
> In all such cases, any use of the restrict qualifier shall be omitted.

888 ：12/03/27

無視しろっていう意味ではなくて
restrict を消したヘッダを別に用意するか
マクロで消すかしろってことだと思うな、その箇所。

889 ：12/03/27

そうなんか。処理系が頑張るんじゃなくて（ある意味人力で）
restrictの記述を落とすのか...
確かにそう読めるな

890 ：12/03/27

素直に無視すりゃいいのになんでそんな面倒な事になったんだ？

891 ：12/03/27

17.2 は
「C標準ライブラリは一部変更を加えて、C++でも提供する」
細かい変更箇所はあとで言うけど
restrict についてはいちいち述べているときりがないから
「restrict は一律消去で」ヨロ
という意味
restrict 以外にも変更箇所はあるのに、これだけ特別扱いで
言語レベルで無視というのは非合理かと

892 ：12/03/28

C++からCのライブラリを使うという観点では、
restrictはライブラリ書く人が、
利用者に対して利用上の注意を求めるものだから、
無視しても実装が警告の機会を逃すくらいしかデメリットがない。
大域変数の修飾でも最適化の機会を逃すだけ。

893 ：12/03/28

亀レスだが、
Objective-Cのメソッドディスパッチは
hash table引く。
メソッド名文字列からメソッドIDを生成して、
オブジェクトにsend出来る。
だから低レベルな小さいクラスライブラリ提供が無理。
そういう部分での設計はCでも行う必要があり、
OOな設計スキームを使う場合、
二種類のOO実装射影が必要になる。

894 ：12/03/28

>>891
> restrict 以外にも変更箇所はあるのに、これだけ特別扱いで
C文法でC++11としてill-formedになるのってrestrict絡みだけだと思ってた
_Boolやら_Genericsやらはアンダーバー大文字始まりだから予約シンボルでどうにでもなるとして
他に何かあるの？

895 ：12/03/28

まとめるとObjective-Cはリンゴ臭いからきもい

896 ：12/03/28

>>894
コンパウンドリテラルは C++11 に入らないことになってたような。

897 ：12/03/28

配列の添字指定の初期化とか
構造体のメンバ指定の初期化とか
そういうのも入らない

898 ：12/03/28

＞配列の添字指定の初期化
それはgcc拡張ではないかい？
http://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html

899 ：12/03/28

悪い
俺が間違い

900 ：12/03/28

>>896
乙

901 ：12/03/28

>>895
乙
>>900はミス

902 ：12/03/28

>>899 お前誰だよ。
ID 無しだとわかりにくいから解説しとくと >>898 の方が間違いで >>897 が正しい。

903 ：12/03/28

俺だよ俺

904 ：12/03/28

いや、オレオレ。

905 ：12/03/28

俺だっつてんだろ

906 ：12/03/28

え、俺わかんね???
>>897は文章どおり11の仕様には入っていないと言っている
>>898はGCC拡張だから11の仕様には入っていないと言っている
どっちも11には入らないって言ってるんじゃなく？
おまいらが何言ってるのか教えろください

907 ：12/03/28

>>897はC99には入ってるけどC++11の仕様には入っていないと言っている
>>898はGCC拡張だからC99の仕様には入っていないと言っている（誤り）

908 ：12/03/28

よくわかる解説ありがとう

909 ：12/03/28

>>893
そもそもそういう用途を想定してないからな。
あくまでもモジュール理論の体現を目指したもので、
大規模コーディングを主戦場に想定してるから。

910 ：12/03/29

配列の形で記述された引数の [ ] の中に const とか入れる文法もC++11に入らない

911 ：12/03/29

動的にサイズを指定できる配列も入らない
入らない仕様はかなりあるのできりないな

912 ：12/03/29

そういや複素数型ってどうなってるんだっけ？

913 ：12/03/29

Cとの互換性だけが取り柄の言語なのに...
C++にはCの仕様を取り込むか否か
選択する権利など無いのに勘違いしちゃってるな

914 ：12/03/29

むしろ何でrestrictを仕様に入れないんだろう
ベクトル化とかの最適を考えると困るはずなのに
C89/C++03以前のように、プラグマで対応するっていう事？

915 ：12/03/29

まあ現実には「昔の」Cと実用レベルで互換が取れてれば構わんのだけどね
最新のCなんて最新のC++以上に使われるか怪しいわけだし

916 ：12/03/29

構造体のメンバ指定の初期化は結構見る気がするなあ。
ヘッダファイルに現れないなら関係ないか。

917 ：12/03/29

restrictなんて使った方が性能的に有利な以上
コンパイラが対応してるなら使わない理由がないんだが
もはやgccもclangもC99がデフォルトだし

918 ：12/03/29

restrict の追加でボトルネックが解消されることなんて稀だろ。
コンパイル時にチェックの掛からない制約を追加するわけで、リスクもある。
要らないとは言わないが、「使わない理由がない」はさすがに言いすぎ。

919 ：12/03/29

restrict無いって事は、memcpyなんかは、C言語版C++版2つ実装が必要になるのか。
今までの様にstd::memcpyから::memcpy呼ぶと未定義動作する可能性が有るんだもんな。

920 ：12/03/29

>>919
memcpy （他いくつかのC標準関数）は元から restrict 相当の要求があるから、同じ実装で問題ないよ。

921 ：12/03/30

不自由Windowsでは
いつになったらclang使えるようになりますか？

922 ：12/03/30

リンゴがwindowsでiPhoneアプリを作成できるようになったら

923 ：12/03/30

今更noalias再びのrestrict入れるなんて
Cの標準化委員会は馬鹿だなあと思う。

924 ：12/03/30

restrict（というよりC99に入った仕様の多く）は
FortranをCで置き換えることを意識してる
もとよりC++やC++プログラマなんて眼中に無い

925 ：12/03/30

底辺数値計算屋のために…
現実にはFORTRANでさえOOPになって、
C++の方が数値計算ライブラリに使われているのに。

926 ：12/03/30

＞FortranをCで置き換えることを意識してる
初耳ですー／(^o^)＼

927 ：12/03/31

Fortranでは実現できる自動SIMD化が
別名の問題でCでは困難なケースが見られる
高効率を求めてCを使うユーザー層から不満があるんでしょ

928 ：12/03/31

呼び出し規約合わせれば簡単に呼び出せるんだから速度が必要なところはfortran使えば良いのに

929 ：12/03/31

そうだな、呼び出し規約を合わせれば簡単にCもFortranも呼び出せるから
C++なんて歪なキメラ言語を使う必要は無いな

930 ：12/03/31

Cは相変わらずハッカーに好かれてるのにC++は嫌われてるね
ttp://attractivechaos.github.com/HN-prog-lang-poll.png

931 ：12/03/31

class も namespace も template も例外も欲しいんだよ

932 ：12/03/31

いい加減にスレ違いのCの人はよそでやってくれないかな？
ここらへんとか
cとc++どっちがいいの？
http://toro.2ch.net/test/read.cgi/tech/1245506307/

933 ：12/03/31

ここはどうしてC++11がゴミになっちゃったか
議論するスレですよ

934 ：12/03/31

>>933の頭の中には俺の知ってるのと別の"C++11"があるのか
面白いな

935 ：12/03/31

WindowsでC/C++がオワコンになって
CにはLinuxとOS Xが残ったけど
C++は完全に終わっちゃったね

936 ：12/03/31

LinuxでもC使っているのはカーネルみたいな枯れた分野だけ

937 ：12/03/31

いまどきCだけってのは珍しいな
Cと適当なスクリプト言語を組み合わせて使うのが多い
C++はその「適当なスクリプト言語」枠から脱落しただけ

938 ：12/03/31

Cが使われるのは昔からあるソフトだけ

939 ：12/03/31

じゃあ今は何が主流なんだ？
ネイティブ吐けないJAVAやC#とか言うなよ

940 ：12/03/31

Chrome -> c++
Firefox -> c++
Opera -> c++
KDE -> c++
evernote -> c++
LLVM -> c++
LibreOffice -> c++
Maya -> c++
Photoshop -> c++

941 ：12/03/31

圧倒的じゃないか

942 ：12/03/31

MSとかgoogleとかappleみたいな
世界で滅茶苦茶儲けている企業は
だいたいC++使っている

943 ：12/03/31

C++勉強しよう

944 ：12/03/31

std::thread で作ったスレッドが終了してるかどうかって
どうやって確認したらいいんでしょう？
boost::thread だと timed_join() に 0 msecとか指定して確認してたんですが、
std::thread だと timed_join() がないので。。
自分の環境（Win+VC11）では
join() はスレッドが死んでると system_error 送出するけど
死んでたら例外、の挙動が規格で決まってるわけではなさそう？なので、イマイチ
native_handle() は実装依存かつ、MSDNに記載なしなので、
マジ実装依存でイマイチ
と悩んでいます。get_id() が返す値もシステムの
Thread IDと同一という保証はないと思うのでシステムAPIには渡したくないです。
（今の実相だとシステムのThread IDを返すようですが）

945 ：12/03/31

joinable

946 ：12/03/31

>>937

947 ：12/03/31

>>937
どうでもいいが、C++使っててスクリプトをアプリケーション制御言語以外の意味で使う人って珍しいな。
大体スクリプトとしてPerlを使う、Pythonを使うって言い回しが多いと思うけど。

948 ：12/03/31

1990年代から2000年初頭にかけて、まだC++が素晴らしい言語だと
人々を騙せていた頃に作られたソフトウェアが生き残ってるから
C++はまだまだ使われるよ
COBOLと同じような意味で

949 ：12/03/31

2000年初頭にJavaやC#で作られたソフトが
C++に書き換えられているの知らんのか

950 ：12/03/31

あほか。
パフォーマンスが要求される第一線のアプリではC++以外に選択肢がないから
使われているんだよ。
せめて、お前には無関係な言語だということぐらい理解できるようになろうな。

951 ：12/03/31

C使えよ

952 ：12/03/31

ttp://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png

953 ：12/03/31

>>952
C一強だな。Javaはもうそろそろ終わるかんじか。
あと全般的に下降傾向だな。

954 ：12/03/31

JavaScript, Objective-C, C# は上昇傾向、プラットホームべったり依存が好まれるご時世なのか？

955 ：12/03/31

>>950
速度求めて無いヤツがこのスレに居ると思ってんのか？
速度必要ないならシェルスクリプトやらPythonやらで済ますわ

956 ：12/03/31

>>954
その中にプラットフォーム依存の言語なんて無いだろ
Objective-CはCが動くすべての環境で使えるぞ
なんせgccとclangがサポートしてるからな

957 ：12/03/31

iOS以外でObjective-C使うメリットなんてないし
iOSでもObjective-Cは最小限にしてC/C++で書くだろ

958 ：12/03/31

がはは、うちのC開発はcxxだ。

959 ：12/03/31

他の多くの言語みたいにヘッダとソースコードを分けずに済むような仕組みにしてくれよ

960 ：12/03/31

>>957
NeXT時代からライブラリもってりゃObjective-Cの方がラクだ。
プログラムの中で速度が必要な所なんて1/3も無いからな。
基本的にインタプリターで書いて時折Cを使うってのはなかなか楽。
APIに依存しない部分はどんなOSでも使えるし。

961 ：12/03/31

>>945
それも期待したんだけど、明示的に join() するまで
joinable() == true なんだよね。MSVCがおかしい？
http://ideone.com/a62dR
----VC11b の結果
1
main::<lambda_fd7c0d38621812681769875849cb477a>::operator ()
1
0
----
で、join() するとスレッドがブロックしちゃうから
純粋な検査だけしたいのだけど。。。

962 ：12/03/31

>>961
何がしたいの?結果を受け取りたいだけとか
待ち合わせしたいならfuture使えばいいだろうけど

963 ：12/03/31

>>962
複数の常に生きているべきスレッドがあって、
それらに対してwatchdog的なことをしたい。
boostでやってたことを、C++11ｳｪｰｲってstdに置き換えてたらここで詰まった。
futureは使ったことないけど wait_for() かなんかでできそうな気がしてきた。
ありがとう、すこし調べてみる

964 ：12/03/31

人口が多い順にJava、C、C++、C#。
この中でもっともコンパクトなのがC、最も巨大なのがC++。
Javaも含めていずれもC系列なんだから全部やっとけ＾＾
C++専門であってもJavaのコードを読まなくちゃいけない時とかあるんだし。

965 ：12/03/31

電話機かエンタープライズ向けでしか見ないJavaの人口が一番多いって？
寝言は寝て言え
人口一位は、batスクリプト、VBA、javascriptが競い合ってるのが実状

966 ：12/03/31

>>942
AdobeもC++の偉い人呼んで社内セミナーやってる。
一部セミナー資料は公開されてる。
それからアプリ開発のために作ったライブラリの一部を公開してる。

967 ：12/03/31

Adobeは標準化委員会のメンバーだしな
C++標準化委員の法人メンバーは少なくともこれだけ居る
・Adobe
・Apple
・Boost
・Bloomberg
・EDG
・Google
・HP
・IBM
・Intel
・Microsoft
・Red Hat
・Sun
個人的にはなぜ金融屋(Bloomberg)が居るのか不思議で仕方ない

968 ：12/03/31

Adobeと一緒。トレーディングシステムをC++で開発してる。
http://www.bloomberg.com/careers/opportunities/job/show/31124/trading-systems-c-c++-senior-software-developer.html

969 ：12/03/31

しかしいつ見ても、そうそうたるメンバーだよ。

970 ：12/03/31

Sun ...

971 ：12/03/31

他人にはJava薦めておいて
ちゃっかりC++使っているのがSun