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

そこまでだ問題ない

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

いろんな言語で宿題 第五編 (582)
Perl忍者最終決戦〜ゲスッ復活プロジェクト (430)
【論理】Prolog【初心者】 (475)
【初心者お断り】ガチ規格準拠C専用スレ Part134 (201)
クラス名・変数名に迷ったら書き込むスレ。Part21 (416)
【自動】株式トレーディングシステム Part6【売買】 (141)
--log9.info------------------
【恥を】バス業界の悪を糾弾するスレ【知れ】 (568)
【屁】HeddonスレッドPart10【丼】 (469)
帰ってきた★ 相羽純一 ★総合Part3 (560)
勝ち組村田と負け組今江なぜ差がついたか (400)
●●●ダイワのリールはすぐにガタがくる２●●● (340)
【日】清水盛三 3投目【米】 (145)
【陸っぱりも】芦ノ湖の現状は？part5【ボートも】 (595)
ダイレクトリールスレッド (124)
最近メーカーがバスを見限りつつある件 (209)
【KEITECH】ケイテック Part２【林と柳】 (473)
三重県総合スレッドVer.22 (511)
MAJORCRAFT ７ (710)
★★★バス業界人の元ヤン暴露大会★★★ (811)
ハートランドを語ろう MemorialNumber 28 (272)
【鬼嫁】お父さんのおこずかい２【35年ローン】 (760)
※※※※※大阪総合スレッド　(ぱーと３)※※※※※ (728)
--log55.com------------------
トキメキファンタジーラテール part1524
【AA】ArcheAge Part240【アーキエイジ】
幻想神域 -Cross to Fate- Part286
【UO】UOスレッド第1801章【本スレ】
【BlackDesert】 黒い砂漠 占領戦スレ Part37
【ToS】Tree of Savior part1303
【BlackDesert】黒い砂漠PC版 質問スレPart57
【FEZ】ファンタジーアースゼロ雑談スレ1489