5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

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

C++11/C++0x 15

1 :デフォルトの名無しさん:2011/11/16(水) 23:27:34.48
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 :デフォルトの名無しさん:2011/11/16(水) 23:27:59.61
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 :デフォルトの名無しさん:2011/11/17(木) 00:01:25.19
痛みに耐えてよく頑張った! 1乙!

…奥さんとの会話は殆ど無いらしいよ?
そりゃあ、宮沢りえちゃんとは比較にならないよな、年上女房。

4 :前スレ977:2011/11/17(木) 09:50:50.98
前スレ >>982
おおお、VCでもできました。ありがとうございます。

VCでラムダのメンバが見れなかったから、なんか特殊な物だと思っていたんですが
関数オブジェクトだったんですね。

前スレ >>985
可変長はVCではできないので、また今度お願いします。ありがとうございます。

5 :デフォルトの名無しさん:2011/11/17(木) 10:29:00.11
結局 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 :デフォルトの名無しさん:2011/11/17(木) 11:03:48.34
あと1〜2年はC++11の新機能に関する
質問を受け付けつつ、次のC++の仕様を
夢見るスレってことでいいんじゃないの。

7 :デフォルトの名無しさん:2011/11/17(木) 12:53:28.54
如何にしてC++相談室への平和的な侵略を試みるかについて話し合うスレ

8 :デフォルトの名無しさん:2011/11/17(木) 13:39:15.21
棲み分けね

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

9 :デフォルトの名無しさん:2011/11/17(木) 19:32:02.73
C++11はまだ99%以上準拠した環境がないんだから
メインはこっちで

10 :デフォルトの名無しさん:2011/11/18(金) 22:10:00.14
export非推奨になるかも…って話はいったいどうなったんですか?

11 :デフォルトの名無しさん:2011/11/18(金) 23:23:28.92
exportはdeprecatedですらなく、廃止されました
C++11ではexportはただの予約語

12 :デフォルトの名無しさん:2011/11/18(金) 23:59:29.51
call や overload みたいに予約語ですらなくならなかった理由は何だろう
まだ再燃する余地が残っているのかな

13 :デフォルトの名無しさん:2011/11/19(土) 00:23:11.61
autoみたいに再利用するかもしれないからだろ
今は予約語確保するのも大変なんだよ

14 :デフォルトの名無しさん:2011/11/19(土) 00:26:48.66
予約後も名前空間に入れてしまえばいいのに
std::auto x = hoge();
これで面倒な問題はだいたい解決する


15 :デフォルトの名無しさん:2011/11/19(土) 00:27:09.30
過去に使われたからだろ

16 :デフォルトの名無しさん:2011/11/19(土) 02:03:22.00
>>14
C++世代で識別子と予約語を混同する奴がいるとは思わなんだ。


17 :デフォルトの名無しさん:2011/11/19(土) 02:07:28.31
C++世代ってなんだ?

18 :デフォルトの名無しさん:2011/11/19(土) 02:16:53.08
水色時代

19 :デフォルトの名無しさん:2011/11/19(土) 09:56:27.95
>>12
overloadって規格になる前に消え去ったことないか

20 :デフォルトの名無しさん:2011/11/19(土) 11:44:27.92
>>16
Scheme だと特殊構文も名前空間 (Scheme 用語では library) に属してて、関数やマクロと一貫した扱いになってる綺麗な仕様。

混同する奴は問題じゃない。
区別しなけりゃならないクソ仕様な C++ に疑問を持たないお前が風の前の塵に同じ。

21 :デフォルトの名無しさん:2011/11/19(土) 12:56:04.09
括弧バカ言語の信者こわい

22 :デフォルトの名無しさん:2011/11/19(土) 13:12:23.43
C++はアホの言語ということを受け入れられない可哀想な子が居るね

23 :デフォルトの名無しさん:2011/11/19(土) 13:16:00.31
それでもC++が圧倒的なシェアを誇りSchemeなど足元にも及ばない現実を
認められない可哀想な子がいるね

24 :デフォルトの名無しさん:2011/11/19(土) 13:57:29.73
C++ が馬鹿でも使える優秀な言語であることは認めてやるよ。

25 :デフォルトの名無しさん:2011/11/19(土) 13:59:44.65
C/C++も括弧バカ言語の範疇へ十分に入るよ

26 :デフォルトの名無しさん:2011/11/19(土) 14:20:36.86
せやな
C++はバカ言語で決まりや


27 :デフォルトの名無しさん:2011/11/19(土) 14:53:16.74
>>12
export 実装した処理系が少なくとも2つ存在してる。

28 :デフォルトの名無しさん:2011/11/19(土) 14:55:09.33
>>25
Cを一緒にすんなよ。

29 :デフォルトの名無しさん:2011/11/19(土) 17:11:31.14
callやoverloadだって実装はされてたろう、多分
その時代知らないけど

30 :デフォルトの名無しさん:2011/11/19(土) 21:57:04.40
>>28
algol 系の begin/end ではなく {} を使うから「括弧バカ」だと言ってるんじゃないかな。

31 :デフォルトの名無しさん:2011/11/19(土) 23:08:58.23
begin/end よりも {} の方が見やすいと思うんだが
begin/end 見ると目が痛い…

32 :デフォルトの名無しさん:2011/11/19(土) 23:11:50.18
つか予約語の多い言語は総じてクソ。
beginやendがシンボル名に使えないとか
どんな罰ゲームだよ。

33 :デフォルトの名無しさん:2011/11/19(土) 23:24:12.96
begin endって関数名にもよくあったりするから
あまり他のとこで見たくない

34 :20:2011/11/19(土) 23:26:29.08
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 :デフォルトの名無しさん:2011/11/19(土) 23:35:33.62
お前がくだらない事書くからじゃねぇか

36 :デフォルトの名無しさん:2011/11/20(日) 00:16:47.17
http://www.mahdiyusuf.com/post/9947002105/most-pressed-keys-and-programming-syntaxes
やっぱり多いような……w

37 :デフォルトの名無しさん:2011/11/20(日) 01:11:55.58
式ごとにカッコが必要だから
当然多いわ

38 :デフォルトの名無しさん:2011/11/20(日) 01:15:21.51
括弧つけるかつけないか迷うくらいなら、全部付けなければコンパイル通らない方が、頭使わなくていいし、間違いも少ない。

39 :デフォルトの名無しさん:2011/11/20(日) 01:32:02.59
カッコの対応が・・・

40 :デフォルトの名無しさん:2011/11/20(日) 01:36:39.74
なるほど、カッコの対応が正確にあっていなくてもいい言語が必要なようですね。

41 :デフォルトの名無しさん:2011/11/20(日) 01:56:38.59
暗黙の結合規則で失敗するくらいなら、全部付けなければコンパイル通らない方が、頭使わなくていいし、間違いも少ない。

42 :デフォルトの名無しさん:2011/11/20(日) 03:25:29.50
>>40-41
つまり括弧ないとコンパイルは通らないけど、
全部無視される仕組みって事ですね。

43 :デフォルトの名無しさん:2011/11/20(日) 03:42:43.29
Lispのカッコが非常にうっとおしい。
Lispのカッコをなくすべき。

44 :デフォルトの名無しさん:2011/11/20(日) 04:03:24.35
というかもうHaskellでいいです

45 :デフォルトの名無しさん:2011/11/20(日) 07:16:47.63
右辺値参照を勉強し始めましたがさっぱりです。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 :デフォルトの名無しさん:2011/11/20(日) 08:24:49.84
>>45
http://slashdot.jp/~taro-nishino/journal/507551

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

47 :デフォルトの名無しさん:2011/11/20(日) 09:09:18.85
>>36
Lispだけ()の打鍵数多くて目立つなあw
なんで、共通してeの打鍵数が多いんだろ

48 :デフォルトの名無しさん:2011/11/20(日) 09:21:56.86
英語の中で e の出現頻度は飛び抜けて多い。
ってシャーロックホームズが言ってた。

49 :デフォルトの名無しさん:2011/11/20(日) 09:59:59.82
符号化の基本だよね

50 :デフォルトの名無しさん:2011/11/20(日) 10:50:27.42
>>48
モールス符号

51 :デフォルトの名無しさん:2011/11/20(日) 12:06:57.69
>>40-41
多過ぎて対応取るのが面倒という話なのになぜそうなる

52 :デフォルトの名無しさん:2011/11/20(日) 19:03:33.88
C++版可変長引数って配列を突っ込んだらそのまま使ってくれたりすんだっけ?

int
       array[] = { 1, 2, 3 };
Example
       a( 1, 2, 3 ),
       b( array );

53 :デフォルトの名無しさん:2011/11/20(日) 19:24:55.46
配列の先頭要素へのポインタが渡される

54 :デフォルトの名無しさん:2011/11/20(日) 19:33:03.54
オーバーロードするしか無いのか。
割と気が効かんね。
コンストラクターの委譲のおかげで多少シンプルにできそうだけど。

55 :デフォルトの名無しさん:2011/11/20(日) 19:58:32.39
配列を引数に個別に展開とか何の嫌がらせだよ

56 :デフォルトの名無しさん:2011/11/20(日) 20:17:59.26
ああ定数での渡し方を間違えてた。
Example
    a( { 1, 2, 3, 4} );

可変長引数じゃなくて、初期化リストっていうのかこれ。

57 :デフォルトの名無しさん:2011/11/20(日) 20:27:46.25
std::initializer_list<int> 型で渡されるんじゃないのか?
g++だと内部エラーが出て死んでしまったが

58 :デフォルトの名無しさん:2011/11/20(日) 20:30:50.24
って、もしかして a(...) じゃなくて a(std::initializer<T>) を想定してるのか?
まずは a のプロトタイプを教えてくれ

59 :デフォルトの名無しさん:2011/11/20(日) 20:40:27.73
前者のinitializer_list<T>を想定してる。
要するに、↓ができないのは残念ねって事を言ってた。

int array[] = { 1, 2, 3, 4 };
std::initializer_list<int> a = array;


60 :デフォルトの名無しさん:2011/11/20(日) 20:44:13.47
後者じゃないのか?

61 :デフォルトの名無しさん:2011/11/20(日) 20:52:10.06
これでいいので実のところ大した手間ではない

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 :デフォルトの名無しさん:2011/11/20(日) 20:54:37.07
見た目的にどうかってより、テンプレートの時どうかってね...。

63 :デフォルトの名無しさん:2011/11/20(日) 21:03:38.99
template <typename T>
void a(T (&array)[]) { a(std::begin(array), std::end(array)); }

これも追加しておけば?

64 :デフォルトの名無しさん:2011/11/20(日) 21:04:01.17
constわすれた

65 :デフォルトの名無しさん:2011/11/20(日) 21:14:09.51
だから>>54にね。

66 :デフォルトの名無しさん:2011/11/20(日) 21:53:30.68
いまさら組み込み配列なんか使ってんじゃねえ、とかw

#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 :デフォルトの名無しさん:2011/11/20(日) 22:05:45.85
そこはstd::arrayだろう。

68 :デフォルトの名無しさん:2011/11/20(日) 22:16:27.68
>>66
だって動的メモリ確保おせーんだもん。
スタックでの配列確保なら1回の加算命令で済むのに、
ヒープ確保じゃ20命令以上使う上に分岐まですんだぜ。

69 :デフォルトの名無しさん:2011/11/20(日) 22:43:02.53
1回のというか、関数の最初に全変数分の領域確保するから
他に変数があればコストは0
(キャッシュヒット率に影響は出るかもしれないが)

70 :デフォルトの名無しさん:2011/11/20(日) 23:05:48.86
なるほど、それで小さいプログラムでは new とか malloc とか使わないのか。
スタック最強伝説。あせんぶりぶり

71 :デフォルトの名無しさん:2011/11/20(日) 23:36:14.45
脇道

>> だって動的メモリ確保おせーんだもん。
事実であってもその遅さの比較は真実として意味のあるものなのか?
プログラムを普通に一時間使ってる間にある処理が複数回行われてあるやり方だと合計で1msかかるのが
別のやり方だと100倍遅くて合計で100msかかるようになったところでなんだというんだ。

よく言う高速化・最適化は実測が基本というのは本来はそういう視点で高速化すべきポイントを見定めるという意味のほうが大きかったんだぞ。

72 :デフォルトの名無しさん:2011/11/20(日) 23:42:54.79
いやその例は体感できるだろw
0.1秒って結構分かるぞ

例を出すならマイクロ秒にしとくべきだったな
実際CPUの高速化で意味がなくなってる最適化も多いし

73 :デフォルトの名無しさん:2011/11/20(日) 23:51:17.59
ベクトル系の処理だと、頻繁にメモリ確保なんかしてられないんだけど。
計算数が増える前に一括で領域をとっておき、
固定で済む範囲は、生配列を使わないと指数的に影響するときもある。

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

75 :デフォルトの名無しさん:2011/11/21(月) 00:25:48.82
vectorによるメモリ確保はゼロクリアも行われるよね

76 :デフォルトの名無しさん:2011/11/21(月) 00:31:49.71
>>72
元の話は一時間での合計の差だぞ。つまり60*60*1000=3600000msと3600099msの違い。
一秒当たりにならすと1000msと1000.0275ms、1.0sと1.0000275sの違い。この差がわかるならたいしたものだ。

この考え方が理解できないなら一秒間に一回定期的に行われる処理の場合を考えてみな。
(その場合は理想的な例にすぎるが高速化のための実測データはこういう視点で解析する。)

77 :デフォルトの名無しさん:2011/11/21(月) 01:02:21.71
>>76
ループで動的に確保してたら普通に遅い。
それだけの話に本筋とかけ離れた当たり前な事を言って何がしたいの?
ゴリ押しは気持ち悪いよ。

78 :デフォルトの名無しさん:2011/11/21(月) 01:15:19.18
ん?ああ、一時間ってのを普通に読み飛ばしてたわすまんすまん
でも漢数字とmks混ぜんな

79 :デフォルトの名無しさん:2011/11/21(月) 01:16:26.64
モサーリを改善しようとしたときに関数引数にvectorとかコンテナつこてるとあちこち書き換えしなきゃならなくなる
せっかくクドイC++で書いてんだから速度ヤバメな機能切れ目のやり取りには始めっから生配列を使っておこうや

80 :デフォルトの名無しさん:2011/11/21(月) 02:00:43.17
>>77
オマエ国語力無いな。
ループとか関係なく、トータルの時間差が
意味があるかを考えるってだけの話が理解できないのか。

200nsかかる処理が1万回ループしたとして、
それがウェブの1回の処理の中だったら2msなんて誤差だろ

81 :デフォルトの名無しさん:2011/11/21(月) 02:16:59.06
Webアプリだの速度が求めれれない環境の話しなんざしてないし
そんな環境でスタックだヒープだ気にはしない

82 :デフォルトの名無しさん:2011/11/21(月) 07:25:46.82
速度が求められるプログラムを組んだ事無い人なんだろうね

83 :デフォルトの名無しさん:2011/11/21(月) 07:53:17.33
そんなレベルの低い人はこのスレを見る資格無いよな

84 :デフォルトの名無しさん:2011/11/21(月) 12:11:18.55
はいはいワロスワロス

85 :デフォルトの名無しさん:2011/11/21(月) 12:17:09.64
速度原理主義者はクズ
高速化はハードに任せてソフト面では開発効率を最大重視するのが人類にとって有益

86 :デフォルトの名無しさん:2011/11/21(月) 12:35:14.53
>>85
そういう用途にはシステム記述言語以外のものを使ってくれ。

87 :デフォルトの名無しさん:2011/11/21(月) 12:55:03.85
>>85
だったらJavaでも使ってろよ。
お前自体がスレ違いだ。

88 :デフォルトの名無しさん:2011/11/21(月) 13:06:23.53
Javaはないだろ……

89 :デフォルトの名無しさん:2011/11/21(月) 13:21:54.53
「この新しくて軽い靴なら100M走のタイムが縮まるぜ!」

「(・・・その前に走行フォーム見直せよ・・・)」
「(・・・楽に走れる履きなれたのを使えよ。怪我するぞ・・・)」
「(・・・お前が走るのはマラソンだぞ。軽さより衝撃吸収性を考慮しろよ・・・)」

90 :デフォルトの名無しさん:2011/11/21(月) 13:59:21.77
C++でシステム記述w

91 :デフォルトの名無しさん:2011/11/21(月) 17:56:43.99
>>90
何か問題でも?

92 :デフォルトの名無しさん:2011/11/21(月) 20:37:19.85
>>85
ハード屋はクズってことか
ハードしかできない人ではなくハード「も」できる人まで

おまえさ、ソフトって何か本質がわかってねえだろ
せいぜい教科書で教わった程度の定義でもの言ってるだろ

93 :デフォルトの名無しさん:2011/11/21(月) 20:40:02.07
重箱の隅つつくばかりの能無しが湧いてきやがったぜwww

94 :デフォルトの名無しさん:2011/11/21(月) 21:09:34.68
>>89
せいぜいRubyの靴を履いてフォーム改善に勤しんでろ

95 :デフォルトの名無しさん:2011/11/21(月) 23:11:51.43






96 :デフォルトの名無しさん:2011/11/23(水) 15:46:46.08
おまえら全然C++11の話してないな

97 :デフォルトの名無しさん:2011/11/23(水) 16:34:50.03
既に死んだ言語だし。

98 :デフォルトの名無しさん:2011/11/23(水) 18:56:10.81
では今来た俺に教えてくれ。最終的に9月の規格にはどこまでの仕様が挿ったんだ?
・右辺値参照 + moveセマンティクス
・unique_ptr
・テンプレ可変湖引数
・ラムダ
ここまで理解した

99 :デフォルトの名無しさん:2011/11/23(水) 18:57:29.38
そこまでだ問題ない

100 :デフォルトの名無しさん:2011/11/23(水) 18:57:46.85
wikipediaあたりに載ってるよ

101 :デフォルトの名無しさん:2011/11/23(水) 19:37:59.51
VC++で使えない仕様なんてゴミだろ

102 :デフォルトの名無しさん:2011/11/23(水) 19:44:40.76
VCがクソなだけ
いいかげんVCなんて捨てろよ

103 :デフォルトの名無しさん:2011/11/23(水) 19:51:18.99
商用コンパイラがGCCに比べて対応が遅くなるのは仕方ないだろ。
WindowsでVisual C++捨てろというやつの方が変だと思うぞ。仕事にならん

104 :デフォルトの名無しさん:2011/11/23(水) 20:13:41.57
Intelコンパイラとか
Borlandコンパイラとか
Comeauコンパイラとか

会社でそれなりの地位に居れば
それなりの選択肢はある。

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

106 :デフォルトの名無しさん:2011/11/23(水) 20:43:58.69
そんな会社で大丈夫か?

107 :デフォルトの名無しさん:2011/11/23(水) 20:46:49.63
RAIIくらいは理解させといた方がいい

108 :デフォルトの名無しさん:2011/11/23(水) 20:47:41.83
教育しろよカス

109 :デフォルトの名無しさん:2011/11/23(水) 21:11:49.94
部署にもよるだろうな。
うちの特許レベルの技術開発してる部署だと、
主任レベルの人が社長と掛けあってIntel C++導入してたしな。

110 :デフォルトの名無しさん:2011/11/23(水) 21:15:47.95
マ板向けの話ではあるが、
C++使う人なら、上級技術者と、それ以外とが
部署として別れてる会社に入ったほうがいい。

111 :デフォルトの名無しさん:2011/11/23(水) 21:45:42.82
VC6 しか使わせてくれなかったので会社辞めたった
誰でも知ってる某大手子会社だぜw


112 :デフォルトの名無しさん:2011/11/23(水) 22:16:17.13
boost使うの禁止とか言われたんで嫌々自分でスマポ作った思い出ならある

113 :デフォルトの名無しさん:2011/11/23(水) 22:35:22.21
ITってかなり重要な部門なのに
なんでコンパイラごときで経費ケチケチすんだろうね

114 :デフォルトの名無しさん:2011/11/23(水) 22:41:10.53
不法コピーしない限り、コンパイラってかなりばかにならんぞ

115 :デフォルトの名無しさん:2011/11/23(水) 22:41:27.12
不法コピーしない限り、コンパイラってかなりばかにならんぞ

116 :デフォルトの名無しさん:2011/11/23(水) 22:42:48.57
重い

117 :デフォルトの名無しさん:2011/11/24(木) 00:08:42.24
禿20人とお前で開発環境はVC6でboostやstlport無し

お前任意数で環境はぼくのかんがえたさいきょうの開発環境
どっち選ぶ

118 :デフォルトの名無しさん:2011/11/24(木) 00:13:29.81
>>104
ほかはわかるがBorland?
03のテンプレートすら怪しくないかそれ

119 :デフォルトの名無しさん:2011/11/24(木) 00:15:28.91
Intel C++とハゲと俺まで読んだ

120 :デフォルトの名無しさん:2011/11/24(木) 00:17:33.34
>>118
最新のコンパイラはほぼ規格準拠してるだろ。
てか、今はEmbarcaderoだっけ。

121 :デフォルトの名無しさん:2011/11/24(木) 00:18:24.84
>>117
禿は規格無視したVC6使うぐらいならgcc使うんで仕事にならんと思う。

122 :デフォルトの名無しさん:2011/11/24(木) 00:19:57.50
俺の考えた最強の開発環境がどの程度のものかによるな
あらゆるツールやライブラリにスパコンとかも使えるんだろ

123 :デフォルトの名無しさん:2011/11/24(木) 00:28:23.59
ぼくのかんがえたさいきょうの開発環境

・ベース:Qt
・コンパイラ:clang++
・補助ライブラリ:boost
・バージョン管理:git
・作業OS:Fedora

他には?

124 :デフォルトの名無しさん:2011/11/24(木) 00:29:14.49
補助ライブラリにAceとBlits++でも加えとくか

125 :デフォルトの名無しさん:2011/11/24(木) 00:30:43.25
>>112
そもそも boost がない頃から極めて重要な関心事だったが

126 :デフォルトの名無しさん:2011/11/24(木) 00:32:26.89
京つかったらコンパイルも一瞬だろうな

127 :デフォルトの名無しさん:2011/11/24(木) 00:42:57.00
ぜひ、gccのフルビルドのスコアを教えてくれ

128 :デフォルトの名無しさん:2011/11/24(木) 02:26:59.30
ネタ話はプログラム書けない奴が何とかかんとかスレでやれよ
せめて

129 :デフォルトの名無しさん:2011/11/24(木) 11:56:17.69
Visual C++のIDEが使うコンパイラのファイルを
こっそりgccに入れ替えて、コマンドラインスイッチとかにも
対応してくれるようなのってない?

130 :デフォルトの名無しさん:2011/11/24(木) 11:59:34.27
C++11でできた新たな「罠」って見つかってないのかな
>>45
のmoveとオーバーロードとかちゃんと理解してないとハマりそうな

131 :デフォルトの名無しさん:2011/11/24(木) 12:30:09.52
とりあえずdecltype括弧問題

132 :デフォルトの名無しさん:2011/11/24(木) 18:34:31.40
>>131
kwsk

もしかして括弧で囲むと参照になるやつのこと

133 :デフォルトの名無しさん:2011/11/24(木) 18:58:37.41
int n;
decltype(n) i;   // int
decltype((n)) r;  // int&

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

134 :デフォルトの名無しさん:2011/11/24(木) 23:29:21.87
この挙動、左辺値でも参照でなく普通の型(上の例では int)にしたら
何か問題があったのかね

135 :デフォルトの名無しさん:2011/11/25(金) 07:40:10.49
N1978 -> N2115 の改訂で、
「decltype((e)) は decltype(e) と解釈する」という条文が消えた。
理由は書いてなかった。

136 :デフォルトの名無しさん:2011/11/25(金) 13:07:14.96
autoとdecltypeとtemplate型推論は同じかとおもってたが
decltypeだけそういう仕様があったのね

ほかにこの3つが違う型になる場合ってあるの?
auto a = ...;
decltype(...) a;
template<typename T> void hoge(T a){}
hoge(...);


137 :デフォルトの名無しさん:2011/11/26(土) 16:43:03.71
この手の話を全部覚えて使いこなせとか無茶だろ・・・

138 :デフォルトの名無しさん:2011/11/26(土) 16:55:23.68
気合の入ったライブラリを書く気がないなら必要ないから大丈夫だ
あとはsutter先生あたりの本が出るのを待つんだ

139 :デフォルトの名無しさん:2011/11/29(火) 09:03:23.09
とりあえず次期仕様には


テンプレートコンストラクタのテンプレート引数を明示的に指定する
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 :デフォルトの名無しさん:2011/11/29(火) 09:25:08.77
オナニーは1日3回まで

141 :デフォルトの名無しさん:2011/11/30(水) 08:17:39.35
>>139
テンプレート関数の部分特殊化とdynamic_decltypeはほしい

それ以外はいらん

142 :デフォルトの名無しさん:2011/11/30(水) 10:55:33.30
関数テンプレートの部分特殊化は入らんよ
オーバーロードがあるからね

143 :デフォルトの名無しさん:2011/11/30(水) 19:51:49.76
テンプレートの特殊化はもちょっとどうにかならんかねぇ。
特殊化した型で、メンバー関数の実装を省いたら、
汎用型のメンバー関数を使うぐらいして欲しいんだけど。
メンドイ。

144 :デフォルトの名無しさん:2011/11/30(水) 20:01:16.07
特殊化していない方を継承すればいい。

145 :デフォルトの名無しさん:2011/11/30(水) 20:24:31.65
それじゃ、いらんもんが付いてくるので勘弁。

146 :デフォルトの名無しさん:2011/11/30(水) 21:21:56.53
コンストラクタ引数からtemplate型推論は欲しいな
このためだけにテンプレート関数作ることが結構ある

147 :デフォルトの名無しさん:2011/11/30(水) 21:41:10.58
>>146
単純なものだともう必要なくね?

Example<A, B> object = Type<Example>()(argA, argB);
型推論を使うと更にすっきり
auto object = Type<Example>()(argA, argB);

148 :デフォルトの名無しさん:2011/12/01(木) 10:07:07.70
>>145
設計が悪い。

149 :デフォルトの名無しさん:2011/12/01(木) 11:27:27.61
(:foo, bar:) みたいなのでtupleを返してくれるとか

150 :デフォルトの名無しさん:2011/12/01(木) 18:21:28.90
std::make_tupleで何がご不満か

151 :デフォルトの名無しさん:2011/12/01(木) 20:04:33.09
ながい

152 :デフォルトの名無しさん:2011/12/01(木) 21:22:35.54
>>148
設計の問題か?
template<> class Vector<2>;
template<> class Vector<3>;
例えば、ベクトルを次元別に特殊化して作ったとき、
外積は2次元3次元で実装変えるけど、
内積は共通のものを使いたいとか普通にあるだろ。

153 :デフォルトの名無しさん:2011/12/01(木) 21:32:25.13
あるある
というかまさにその例で

154 :デフォルトの名無しさん:2011/12/01(木) 21:45:05.95
>>152
メンバ関数単位で特殊化すればそこだけ入れ替わるよ。

template <class T>
struct A {
  int f(){ return 0; }
  int g(){ return 100; }
};

template <>
int A<void>::f(){ return 1; }

データメンバは同じやり方では特殊化できないけど
データメンバまで入れ替わるような特殊化をしたなら
汎用のメンバ関数なんぞ役に立つまい

155 :デフォルトの名無しさん:2011/12/01(木) 21:48:11.20
Vector<T, 2> / Vector<T, 3> だとそれ無理

156 :デフォルトの名無しさん:2011/12/01(木) 21:49:56.86
>>154
それ処理系依存でしょ。

157 :デフォルトの名無しさん:2011/12/01(木) 21:54:02.38
うむ。確かにダルイな
二桁近くのバリエーションに成れば対策講じるけど〜5種くらいならダサいなと思いながらもコピペ

158 :デフォルトの名無しさん:2011/12/01(木) 22:00:55.06
>>156
gcc -pedantic でもいけるから、たぶん規格通りのはず。C++11 も関係ない

159 :デフォルトの名無しさん:2011/12/01(木) 22:02:49.02
なるほどありがとう。多分当時触ったVCが糞だったんだろう

160 :デフォルトの名無しさん:2011/12/01(木) 22:11:21.56
現状の汎用的な解決策は、異なる関数だけfriendなんだろうが、
オーバーライドはできないし、コンストラクターや
デストラクターはどうしようも無いんだよなぁ。

161 :デフォルトの名無しさん:2011/12/01(木) 23:02:31.44
>>155
本当だ。部分特殊化はできないのか。

162 :デフォルトの名無しさん:2011/12/01(木) 23:11:37.21
Vectorをfloat/double/long double、2/3/4(同次座標)で作りたかった時に
部分特殊化できなくて困った
結局コピペ

163 :デフォルトの名無しさん:2011/12/02(金) 00:50:59.75
サイズわかってる行列とその演算はスクリプトで出力する派

164 :デフォルトの名無しさん:2011/12/02(金) 17:36:26.95
template<> class Vector<2> : public Vector_base<2>;
template<> class Vector<3> : public Vector_base<3>;

165 :デフォルトの名無しさん:2011/12/02(金) 20:20:16.66
結局俺もそれと同じような書き方してるな。

話が変わるが、Dのtypedef structってなんか問題あるの?
C++も組み込めばいいのに。

166 :デフォルトの名無しさん:2011/12/05(月) 11:26:56.34
プリプロセッサがスクリプト並にリッチになればいいのに

167 :デフォルトの名無しさん:2011/12/05(月) 11:32:21.31
俺用メモ

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 :デフォルトの名無しさん:2011/12/05(月) 11:42:24.43
そこまで行くとスクリプトとmakeでいいじゃんってなる

169 :デフォルトの名無しさん:2011/12/05(月) 14:08:10.40
初めてのC++11まだ出てないですか?

170 :デフォルトの名無しさん:2011/12/05(月) 14:32:18.49
>>169
mayersがPDF売ってるよ

171 :デフォルトの名無しさん:2011/12/05(月) 19:22:23.18
>>166-168
げてものでならば

C#をプリプロセッサとして使う ― CsPP
ttp://labs.yaneu.com/20111002/

172 :デフォルトの名無しさん:2011/12/05(月) 19:33:36.18
コードジェネレータ系の欠点はエディタやIDEのサポートがなくなることだよな
そこまで自作してメンテナンスする気も起きないし

173 :デフォルトの名無しさん:2011/12/07(水) 02:34:31.08
>>170
高橋真奈さんのやつです。

174 :デフォルトの名無しさん:2011/12/09(金) 01:58:58.79
まなのC++本はNG入りのはずだが。
C++11対応を仮に書いたとしても期待できない。

175 :デフォルトの名無しさん:2011/12/12(月) 17:54:00.65
dynamic_castを言語機能の中に入れてしまったのは間違いだったよね

176 :デフォルトの名無しさん:2011/12/12(月) 20:43:01.12
なんでやねん

177 :デフォルトの名無しさん:2011/12/12(月) 23:26:37.32
それ以外の言語機能でできることを、言語機能とはしないというポリシーはもともとないんだが

178 :デフォルトの名無しさん:2011/12/12(月) 23:58:52.20
プリプロセッサw
自分で書けよw

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

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)