C++11/C++1y 18

>>17
C++にはVLA(可変長配列)が無いのでCの方が同じ事を低オーバーヘッドで書ける、とかw
C++11になるまではC99の機能もなかったから、Cを使うべき理由はたくさんあったw

C++は覚えなきゃいけないことが多い(Effective C++レベルの知識が必要とか)ので、
コーディングに気を遣いたくない人はCにしておけとは思うね。

26 ：デフォルトの名無しさん：2013/04/05(金) 13:25:22.78

>>17
単純に速度的なものかと思ってた、
Cの構造体コピー = memcpy
C++クラスコピー = コピコン(メンバー一個一個コピー)
参照とかポインタにしてコピコン減らせるけど、できない部分も出てくるし
C++っぽいプログラムにすればするほどコピコン増える気がする

27 ：デフォルトの名無しさん：2013/04/05(金) 18:27:35.95

memcpyで済むような構造体はPODにすればC++でも一緒だし
それで済まないクラスならCでだって結局コピーに伴って初期化とか色々しなきゃならないと思うんだけど

28 ：デフォルトの名無しさん：2013/04/05(金) 19:15:39.77

だよね

29 ：デフォルトの名無しさん：2013/04/05(金) 19:30:34.91

せやな

30 ：デフォルトの名無しさん：2013/04/05(金) 19:41:39.77

Deep CopyとShallow Copyがなぜ区別が付いてるのか理解出来ない低脳が
住み着いてるようだよな

31 ：デフォルトの名無しさん：2013/04/05(金) 19:52:32.25

ピュアなcで作ったアプリは、ファイルサイズも小さく、利用メモリも小さくすむからそこが利点だと思う。

32 ：デフォルトの名無しさん：2013/04/05(金) 20:18:59.06

Cは演算子は兎も角普通の関数の
オーバーロード位は欲しい所だよね。
性能には関係ないのだから。

33 ：デフォルトの名無しさん：2013/04/05(金) 20:35:19.93

関数テンプレートあるだけでCも相当便利になるような気がするんだが
って言っても今更C使う必然性なんて全然ないか(笑)

34 ：デフォルトの名無しさん：2013/04/05(金) 20:35:51.37

>>22
うわ、つい昨日全部読んだところだった。
よかったｗ

しかし、この記事読むと、ゾッとするね。
非同期プログラミングとか、ソフトウェアの利点を否定してるようなもんだｗ

35 ：デフォルトの名無しさん：2013/04/05(金) 20:35:54.16

そういや C11 に _Generic とかいう型switchが存在してたな。

36 ：デフォルトの名無しさん：2013/04/05(金) 20:52:31.39

なんでもかんでも _ を付ける今のCって

37 ：デフォルトの名無しさん：2013/04/05(金) 20:59:38.97

>>32
ISO/IEC 9899:2011というものがあってだな。
実装したコンパイラ見たことないけど。

38 ：デフォルトの名無しさん：2013/04/05(金) 22:34:51.83

>>36
誰かが使ってるものと被ったら嫌だから
予約語の _大文字を使うしやないんや・・・

39 ：デフォルトの名無しさん：2013/04/05(金) 23:07:51.22

_Boolとかダサすぎて使う気になれなかった

40 ：デフォルトの名無しさん：2013/04/05(金) 23:15:20.72

#import <stdbool.h>

41 ：デフォルトの名無しさん：2013/04/05(金) 23:18:40.90

stdboot.hもダサい

42 ：デフォルトの名無しさん：2013/04/05(金) 23:19:44.99

#import って何？

43 ：デフォルトの名無しさん：2013/04/05(金) 23:21:09.68

includeの間違いだろう。どう見ても

44 ：デフォルトの名無しさん：2013/04/05(金) 23:30:28.96

>>42
#include の一回しか読み込まない版

45 ：デフォルトの名無しさん：2013/04/05(金) 23:34:53.97

>>44
お前の中ではそうなんだろう

46 ：デフォルトの名無しさん：2013/04/05(金) 23:39:32.46

>>42
Objective-Cの話か？

47 ：デフォルトの名無しさん：2013/04/06(土) 01:07:17.86

ファイルがシンボリックリンクやらハードリンクされてる場合はどうなるの？

48 ：デフォルトの名無しさん：2013/04/06(土) 01:16:04.43

コンパイラ次第です

49 ：デフォルトの名無しさん：2013/04/06(土) 01:43:33.85

下手に規定しない方が実装が自由にやれる

50 ：デフォルトの名無しさん：2013/04/06(土) 01:48:17.10

>>17
C99 の designated initializer はかなり便利
FreeBSD のカーネルコードでガシガシ使ってる

51 ：デフォルトの名無しさん：2013/04/06(土) 02:34:16.78

import == 輸入だす

52 ：デフォルトの名無しさん：2013/04/06(土) 05:30:36.64

>>47
os レベルで処理されるから、多くの場合は普通のファイルと変わらない扱いだろうな

53 ：デフォルトの名無しさん：2013/04/06(土) 08:20:20.35

C++ってCの上にくっ付けた機能がセンス無さ過ぎて...
所詮C人気に便乗したゴミ言語

54 ：デフォルトの名無しさん：2013/04/06(土) 09:03:48.65

>>53
人気に便乗したというよりもともとがcのラッパー(プリプロセッサ)だからね？
すでに存在するものは極力利用するなんていかにもc技術者らしいけどc++のstructとか、言語的欠陥のおかしい部分はそこに引きずられていたという気もしてる。

c/c++の関係は、今でいうjavascriptとtypescriptのような関係だ。

55 ：デフォルトの名無しさん：2013/04/06(土) 12:35:29.62

>>50
初期化といえば、C++にはユーザ定義リテラルがあるぜ。

56 ：デフォルトの名無しさん：2013/04/06(土) 12:38:04.56

>>55
知らないかもしれないけどC++にはコンストラクターがあるんだぜ。
初期化方法をユーザー定義できるんだぜ。

57 ：デフォルトの名無しさん：2013/04/06(土) 12:50:17.73

C++にはデストラクタがある。
これだけでCを捨てるには十分な理由。

58 ：デフォルトの名無しさん：2013/04/06(土) 12:50:21.45

C++は後方互換を切り捨ててコンパクトになれよ

59 ：デフォルトの名無しさん：2013/04/06(土) 13:00:05.91

むしろ今のC++についてこれない奴を切り捨てる方がずっと早いし意義がある

60 ：デフォルトの名無しさん：2013/04/06(土) 13:01:59.87

>>58
Dでいいじゃん

61 ：デフォルトの名無しさん：2013/04/06(土) 13:03:41.01

C++言語はこの世で最も洗練された美しいプログラミング言語だ。

62 ：デフォルトの名無しさん：2013/04/06(土) 13:04:02.95

>>60
今C++以上に混沌としていて仕様の破壊的変更を待っているマゾしかいないのに

63 ：デフォルトの名無しさん：2013/04/06(土) 13:06:01.70

Designated InitializerってC++11に入らなかったんだ。なんで?
VLAが嫌われるのは何となく分かるけど。

64 ：デフォルトの名無しさん：2013/04/06(土) 13:07:32.00

ひとつの言語で低レベルから高レベルまで
全部書けるべきというスタンスが頭悪過ぎて目眩がする

65 ：デフォルトの名無しさん：2013/04/06(土) 13:09:55.52

Cの方がC++との歩み寄りを否定しちゃってるよな

66 ：デフォルトの名無しさん：2013/04/06(土) 13:16:40.74

Cから見ればC++なんて、相互運用可能な
数多ある言語のひとつに過ぎないからね

67 ：デフォルトの名無しさん：2013/04/06(土) 13:19:19.78

>>62
後方互換を捨てるってそういうことだろ？

68 ：デフォルトの名無しさん：2013/04/06(土) 13:34:01.76

>>63
constexprコンストラクタが有れば要らないと判断されたんじゃね

69 ：デフォルトの名無しさん：2013/04/06(土) 13:57:33.50

constexpr は、コンパイル時計算不可の時にエラーを吐くようなオプションが欲しい。

70 ：デフォルトの名無しさん：2013/04/06(土) 14:04:49.90

警告位は出してほしいよな
黙って実行時評価に変更されても

71 ：デフォルトの名無しさん：2013/04/06(土) 14:13:54.65

禿が決めたことには従え

72 ：デフォルトの名無しさん：2013/04/06(土) 15:43:08.46

>>69
gccはその内にできるんじゃない?

73 ：デフォルトの名無しさん：2013/04/06(土) 18:20:44.99

>>61
いや::が醜いわ

74 ：デフォルトの名無しさん：2013/04/07(日) 23:41:12.01

昔はC++には否定的だったけど、JavaやってC++への評価が改まったよ。

75 ：デフォルトの名無しさん：2013/04/08(月) 04:21:12.17

C#やったらC++がクソと思えるようになるだろ

76 ：デフォルトの名無しさん：2013/04/08(月) 04:30:43.01

C#やったけど
こんなに適当に書けていいのかって思ったな

77 ：デフォルトの名無しさん：2013/04/08(月) 07:30:34.13

C#はスレッドが扱いやすい

78 ：デフォルトの名無しさん：2013/04/08(月) 11:23:32.99

BOOST_SCOPE_EXITの代替になるようなものは無いの？

79 ：デフォルトの名無しさん：2013/04/08(月) 13:32:29.51

>>78
言語機能にはないので自動変数のデストラクタを使ってください(BOOST_SCOPE_EXITも基本はそのラッパーマクロです)

80 ：デフォルトの名無しさん：2013/04/08(月) 19:28:53.09

finally実装すれば済むだけな気もするけど
何か難しい問題点があったのだろうか

81 ：デフォルトの名無しさん：2013/04/08(月) 20:45:21.75

デストラクタで賄えって思想なんじゃね

82 ：デフォルトの名無しさん：2013/04/08(月) 20:51:52.49

ゼロオーバーヘッドの原則がイケメンすぐる。

83 ：デフォルトの名無しさん：2013/04/08(月) 21:00:57.66

clangにfinallyが無くてエンバカが慌てたらしいが結局混在出来なくなって
どちらか一方でしかコンパイル出来ないようだ

84 ：デフォルトの名無しさん：2013/04/08(月) 21:22:40.68

>>83
kwsk

85 ：デフォルトの名無しさん：2013/04/08(月) 21:27:24.77

http://docwiki.embarcadero.com/RADStudio/XE3/ja/Finally_%E3%83%96%E3%83%AD%E3%83%83%E3%82%AF%E3%81%AE%E8%A8%98%E8%BF%B0%EF%BC%88Delphi%EF%BC%89

こんな感じでC++Builder 64bitはfinallyが使えなくなったんだろ?
で、こういう方向へ

http://docwiki.embarcadero.com/RADStudio/XE3/ja/%E3%82%88%E3%82%8A%E5%8E%B3%E5%AF%86%E3%81%AA_C%2B%2B_%E3%82%B3%E3%83%B3%E3%83%91%E3%82%A4%E3%83%A9%EF%BC%88BCC64%EF%BC%89

>BCC32 では、__try と catch を混在させることができます。
>BCC64 では、try/catch（標準 C++）か __try/__except/__finally（Microsoft による拡張）のどちらか一方でなければなりません。

86 ：デフォルトの名無しさん：2013/04/08(月) 21:29:09.66

あのさぁ、C++Builderとか使ってるやついるの？？

87 ：デフォルトの名無しさん：2013/04/08(月) 21:29:15.77

そもそも例外と構造化例外は違うだろう

88 ：デフォルトの名無しさん：2013/04/08(月) 21:31:21.62

>>85
＞BCC64 は Clang をベースにしています。
へー知らなかった

89 ：デフォルトの名無しさん：2013/04/08(月) 21:32:40.46

マジか。じゃあWindowsでまともなC+11実装が欲しければBCC64を買えと

90 ：デフォルトの名無しさん：2013/04/08(月) 21:41:10.90

>>86
俺
>>87
へ？
>>88
やっとC++11に純粋に対応したが既に時遅し感
CodeGuardも64bitでは使えないし
>>89
そういう事だろうな

91 ：デフォルトの名無しさん：2013/04/08(月) 21:43:46.19

つまりC++BuilderはDelphiのVCLをそのまま使ってるので、どうしても__finallyがいる
それでも対応しきれないライブラリは使えないように殺してしまってるし
clangを使ったのはもちろん手抜きだろう
もう1から64bitコンパイラを作るだけの企業体力が残ってないんだろ

92 ：デフォルトの名無しさん：2013/04/08(月) 21:53:17.39

一から作るのなんて単なる無駄では...

93 ：デフォルトの名無しさん：2013/04/08(月) 21:54:44.94

ロマンはある。

94 ：デフォルトの名無しさん：2013/04/08(月) 21:54:52.96

ではなぜMSは1から作るんだ？
そこに他にはない商品価値があるからではないか？

95 ：デフォルトの名無しさん：2013/04/08(月) 21:57:01.60

MSでさえなんでも一から作らずにOSS使ってるよ。

96 ：デフォルトの名無しさん：2013/04/08(月) 22:05:47.77

ときどきGPLを混ぜてやらかすからな

97 ：デフォルトの名無しさん：2013/04/08(月) 22:59:36.76

会社ごと買い取って自社製品として売り出すなんてこといつもやってるじゃん

98 ：デフォルトの名無しさん：2013/04/09(火) 00:15:03.38

C++11はそろそろ安定して仕事に使っても大丈夫な感じなんだろうか
まだ不安でC++03のままなんだけど(boost経由で知らない間に使ってるかもしれないけど)

99 ：デフォルトの名無しさん：2013/04/09(火) 00:20:46.74

g++オンリーなら使えなくもないレベル
thread_localがないとか若干微妙だが、概ね実装されてる
VC++はまだまだ糞

100 ：デフォルトの名無しさん：2013/04/09(火) 00:33:54.60

gcc は↓がダメというわけわからんバグがあるから
ラムダはちょっと怖い。今のところ問題ないけど
int main()
{
　　int x = 0;
　　[&]{ try {} catch(...){ x; } }; // NG
　　[&]{{ try {} catch(...){ x; } }}; // (OK)
}

101 ：デフォルトの名無しさん：2013/04/09(火) 00:37:01.89

4.6.0 だと大丈夫だった
4.7.x だとエラーになるのか

102 ：デフォルトの名無しさん：2013/04/09(火) 00:48:32.60

出た。50歩100歩のGCC信者。
gnu自信がexperimentalって言ってるのに
msに無くてgccにある機能を見つけて
msを批判しないと
精神の安定が保てないんだね。

http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011

103 ：デフォルトの名無しさん：2013/04/09(火) 05:25:05.80

VCに限っては批判されてもおかしくはない
それくらい酷い状態

104 ：デフォルトの名無しさん：2013/04/09(火) 05:26:35.66

お前等C++11なんてクソ言語を実装させられる身にもなってみろよ

105 ：デフォルトの名無しさん：2013/04/09(火) 06:15:12.08

もうC++は諦めろよ・・・いい加減
いつまで老害になる気だよ

106 ：デフォルトの名無しさん：2013/04/09(火) 08:36:21.77

このままだとC++03がいつまでも標準なままだな

107 ：デフォルトの名無しさん：2013/04/09(火) 10:35:02.13

c11みたいにGCCにすら相手に
されない言語に比べたらc++11は
はるかにマシ

108 ：デフォルトの名無しさん：2013/04/09(火) 10:47:40.92

ハァ？　GCCは（Clangも）C11ほぼ全部実装してるだろ
Appendixはそりゃ実装してないけど

109 ：デフォルトの名無しさん：2013/04/09(火) 10:54:32.24

あ、ごめん。Appendixじゃない。Optional featureのことね。

110 ：デフォルトの名無しさん：2013/04/10(水) 00:45:11.39

>>108
_Genericとかthread.hあったっけ？

111 ：デフォルトの名無しさん：2013/04/10(水) 02:23:46.16

_Genericはあるだろ、自分で確認しろよそのくらい
thread.hはOptional

112 ：デフォルトの名無しさん：2013/04/11(木) 19:58:37.92

どこかのサイトに、fstreamはfopenよりもパフォーマンス的に良くないと書いてあったんだけど、どうして？？

fstreamはfclose的なものがないから好きなんだけどなぁ。

113 ：デフォルトの名無しさん：2013/04/11(木) 20:02:43.84

メンバ関数にclose()はあるけどな
時々使わなくてはいけない時もある
通常はスコープが外れるとデストラクタでclose()呼び出すけどな

114 ：デフォルトの名無しさん：2013/04/11(木) 20:05:15.30

>>112
http://d.hatena.ne.jp/s-yata/20100726/1280138663

もしかしてこういう奴か

115 ：デフォルトの名無しさん：2013/04/11(木) 20:08:07.88

>>113-114
そんなこた>>112は知ってんだろうから
質問に答えてやったらどうだ？

116 ：デフォルトの名無しさん：2013/04/11(木) 20:09:06.85

何言ってんだこの馬鹿

117 ：デフォルトの名無しさん：2013/04/11(木) 20:12:04.08

お前が答えてやれやカス

118 ：デフォルトの名無しさん：2013/04/11(木) 20:25:15.03

iostreamは「いくらお前等が信者でも
iostreamがクソだと気付よ」
というメッセージが込められている。
だから実装もわざと遅くしてある。
それに気づくかどうかを試す
禿のトラップなんだよ

119 ：112：2013/04/11(木) 20:40:18.57

>>114
そこではなかったんだけど、どっかのブログに書いてた。
しかし、こんなにも差が出るんだなぁ。
stdio.hのファイル入出力使う場合、
fscanfが重宝するんだけど、
ifstream（operator >>）よりは速いかなぁ。

>>118
そうだったのか！！

120 ：デフォルトの名無しさん：2013/04/11(木) 20:42:32.04

そんなことわざわざするか。タコ

121 ：デフォルトの名無しさん：2013/04/11(木) 20:51:18.04

iostreamなんて必要ないよ。

122 ：デフォルトの名無しさん：2013/04/11(木) 21:29:23.06

速度が必要な所ではそもそもAPIを使う

123 ：デフォルトの名無しさん：2013/04/11(木) 22:28:51.00

shared_ptrのカスタムデリータにfclose登録しとけばいいじゃない

124 ：デフォルトの名無しさん：2013/04/11(木) 22:36:28.10

そんなクソなコードはメンテしたくない

125 ：デフォルトの名無しさん：2013/04/11(木) 22:42:52.03

明示的にcloseする必要が無いならcloseなんかしなくてもいいじゃん

だって、closeするのはそこでcloseされてないと困る場合だろ。
どうでもいいならプログラム終了までほっとけばいい。

126 ：デフォルトの名無しさん：2013/04/11(木) 22:53:09.51

ロックしっぱなし、内容フラッシュされないままで放っておくのかよ

127 ：デフォルトの名無しさん：2013/04/11(木) 22:54:13.68

>>125
>明示的にcloseする必要が無いならcloseなんかしなくてもいいじゃん

開く処理と同じスコープを抜けるときに
クローズしたいことは
極めてよくあることですが。
明示的に書くと漏れる恐れがあるから
デストラクタに任せるのも
極めてよくあることです。

128 ：デフォルトの名無しさん：2013/04/11(木) 22:55:42.30

>>125
こいつ最高にアホ

129 ：デフォルトの名無しさん：2013/04/11(木) 23:02:49.16

きっとクローズ処理のエラーハンドリング
の厳密性を重視しているのだろう。
そうに違いない。

130 ：デフォルトの名無しさん：2013/04/11(木) 23:02:50.53

バカチョン発狂

131 ：112：2013/04/11(木) 23:06:25.83

>>122
APIもいいか･･･。

>>123
そうか！
カスタムデリータ、ほんと便利だ。
COMプログラミングでもRelease自動でやってくれる。
神。

132 ：デフォルトの名無しさん：2013/04/11(木) 23:10:11.77

クローズしないと他のソフトに迷惑でしょ

133 ：デフォルトの名無しさん：2013/04/11(木) 23:25:42.15

書き込んだ場合のfclose()は、ちゃんと戻り値チェックしろよー
お約束だろ？

134 ：デフォルトの名無しさん：2013/04/11(木) 23:50:12.99

してませんが

135 ：デフォルトの名無しさん：2013/04/11(木) 23:56:47.74

fcloseがエラー返してもどうしようもないですしおすし
まあログくらいはできるが

136 ：デフォルトの名無しさん：2013/04/12(金) 00:54:19.27

streamは例外飛ばすオプションがあるからそれを利用する手もあるな

137 ：デフォルトの名無しさん：2013/04/12(金) 06:35:22.05

書き込み後のファイルクローズに失敗したという事は、出力ファイルの内容が信頼できないという事だから、そのファイルは破棄するべき。

直接上書きとかしているとできないだろうけれど、テンポラリーファイル作ってrenameするという手順とっておけば問題ない。

138 ：デフォルトの名無しさん：2013/04/12(金) 07:04:01.04

デストラクタ信者はエラーは握りつぶして良いという
強い強い信念をもっている
だってデストラクタから例外投げるとカオスになるから

139 ：デフォルトの名無しさん：2013/04/12(金) 07:09:48.68

デストラクタからでも例外投げればいいじゃない
死ぬだろうけど

140 ：デフォルトの名無しさん：2013/04/12(金) 07:09:54.32

↑&↑↑アホ

141 ：デフォルトの名無しさん：2013/04/12(金) 07:12:16.74

↑マヌケ

142 ：デフォルトの名無しさん：2013/04/12(金) 07:13:09.10

デストラクタで起こるリソース破棄時の
問題は頭が痛い。
だが元の>>125がそれを気にしていたかというと
恐らく違うだろう

143 ：125：2013/04/12(金) 13:26:20.49

俺が言ってるのは明示的にcloseする必要の無いときの話だから。
どうでもいいならcloseなんかしないでほっておけばいいし、
そこでやる理由があるならやればいい(closeを呼ぶとか
そこでデストラクタが呼ばれるようにするとか)。

144 ：デフォルトの名無しさん：2013/04/12(金) 13:35:14.43

何か結構怖い感覚でプログラム書いてくれちゃってるなあ
こいつには仕事任せたくないわ

145 ：デフォルトの名無しさん：2013/04/12(金) 14:01:15.30

>>144
逆に聞きたいんだけど、どこでcloseする必要があるかを検討せずに
プログラムを作ることがあるの?

146 ：デフォルトの名無しさん：2013/04/12(金) 14:07:59.75

あれれ？言ってる事が違って来てますね

147 ：デフォルトの名無しさん：2013/04/12(金) 14:10:41.21

なんで?
明示的にcloseする必要があるか検討せずに分かるの?
どうでもいいならしなくてもいいと言ってるんだけど。

148 ：デフォルトの名無しさん：2013/04/12(金) 14:50:53.20

動作中にハングアップするだの停電になるだので
ファイル吹っ飛ばしたことが無い幸せな人なんだろうなぁ

149 ：デフォルトの名無しさん：2013/04/12(金) 15:57:19.48

UPSも付けないアホが安全性について語ってるぞ

150 ：デフォルトの名無しさん：2013/04/12(金) 15:58:42.78

closeしたからといって停電とかに対して安全な状態になるわけじゃないからね

151 ：デフォルトの名無しさん：2013/04/12(金) 16:19:43.22

>closeしたからといって停電とかに対して安全な状態になるわけじゃないからね

152 ：デフォルトの名無しさん：2013/04/12(金) 16:26:50.93

ハングアップするプログラムをリリースしちゃうような人の頭の中はこんなもん

153 ：デフォルトの名無しさん：2013/04/12(金) 16:32:39.99

ここの人たちはスレ違いな話をしてる間だけは幸せなんだろうな、、、

154 ：デフォルトの名無しさん：2013/04/12(金) 16:32:56.93

11スレでこんなネタ話されてもなー
使い回すならともかく、使用しなくなった時点で閉じるのが普通じゃない？

155 ：デフォルトの名無しさん：2013/04/12(金) 17:13:16.05

やっぱり言語って
みんなが入り込んで規格決めると肥大化してクソになるんだな
C++は完全に終わったわ

156 ：デフォルトの名無しさん：2013/04/12(金) 17:17:53.43

終わってない言語なんてあるの？

157 ：デフォルトの名無しさん：2013/04/12(金) 17:21:40.13

実際closeなんてファイルディスクリプタの回収ぐらいの意味しかないぜ
ディスクにきっちり書き込まれることを保障したいならそれ用の関数呼んどけ

158 ：デフォルトの名無しさん：2013/04/12(金) 17:52:49.40

日本語の話者は大概がクソ以下

159 ：デフォルトの名無しさん：2013/04/12(金) 19:55:52.48

>なんで?
>明示的にcloseする必要があるか検討せずに分かるの?
>どうでもいいならしなくてもいいと言ってるんだけど。

↑キチガイage

160 ：デフォルトの名無しさん：2013/04/12(金) 20:24:45.93

この話題何回目だよ
「解法に失敗しうるものでRAIIすんな」でFAだろ

161 ：デフォルトの名無しさん：2013/04/12(金) 20:39:01.60

そう言ってるのはお前だけ
自分が正しいと思うなら少数派の異常者と思われても自分だけでそれを貫けばいい
自分の言うことが正しいとみんなに認められるまでことあるごとに話題にしようとするな

162 ：デフォルトの名無しさん：2013/04/12(金) 20:44:01.32

貫けばいいとかアホかと
納得がいく結論が出ないソフトウェア工学ならいらない

163 ：デフォルトの名無しさん：2013/04/12(金) 21:20:30.94

>>160
それだと大抵のリソースはRAIIで扱えなくなって
やっぱC++ウンコじゃんって話になるので
信者にとって非常に都合が悪い

164 ：デフォルトの名無しさん：2013/04/12(金) 21:35:32.25

ヒープは扱えるんだからそれで十分だろ

165 ：デフォルトの名無しさん：2013/04/12(金) 21:43:56.35

つか、close だって失敗してもどうしようもないよな。

166 ：デフォルトの名無しさん：2013/04/12(金) 21:44:04.17

扱えない大抵のリソースってなんだよ

167 ：デフォルトの名無しさん：2013/04/12(金) 21:52:43.31

解放時エラーは全て握りつぶす
その覚悟無き軟弱者にRAIIは扱えない

168 ：デフォルトの名無しさん：2013/04/12(金) 22:07:41.43

FAはこっち
「明示的解放が必要なリソースはRAIIで扱え
解法の失敗を考慮する必要があるならデストラクタでの解法はミスや異常時の保険としておき
デストラクタによらない解法処理を自前で行え」

169 ：デフォルトの名無しさん：2013/04/12(金) 22:36:28.34

>>166
newとmallocで取ったヒープ以外のほぼ全て

170 ：デフォルトの名無しさん：2013/04/12(金) 22:51:26.45

>>165
それがおかしい。
closeに失敗したのだからエラー処理としてロールバック処理をするべきだろう。
ファイルの中身が壊れていてもかまわないというなら話は別だけどな。

closeをチェックする癖付けとかないと、NFS扱い始めたとき、原意不明の障害調査やる羽目になるぞ。
ローカルディスクならほとんど発生しないと思うけど。。。

171 ：デフォルトの名無しさん：2013/04/12(金) 23:05:55.37

>>170
おかしいかどうかはアプリケーション次第だよ。
君のイメージは書き出しみたいだけど、読み出しなら失敗自体が稀だし、失敗したところで別に困らないし、何もできない。

172 ：デフォルトの名無しさん：2013/04/12(金) 23:40:59.49

どうしてreadだけに絞った？
おかしいのは君の姑息な心理操作の方だよ

173 ：デフォルトの名無しさん：2013/04/12(金) 23:48:03.97

>>169
ファイルの他に何があるの？ほぼ全てって言うぐらいなら２，３個軽く挙げられるよね？

174 ：デフォルトの名無しさん：2013/04/13(土) 03:33:10.75

ストリーム
データベースコネクション
スレッド
プロセス
ハンドル

175 ：デフォルトの名無しさん：2013/04/13(土) 06:52:23.77

>>171
表現の違いか。
それはなにもできないのじゃなく、する必要がないだけ。

176 ：デフォルトの名無しさん：2013/04/13(土) 10:57:55.48

する必要がないはしなくて良いにはならない
表現の違いという落としどころに落としたいんですね可哀想ですね

177 ：デフォルトの名無しさん：2013/04/13(土) 12:30:24.27

まぁ今時のOSならプロセスが正常終了すればたいてい後片付けしてくれる
正常終了すれば

178 ：デフォルトの名無しさん：2013/04/13(土) 13:03:03.02

突然話飛ばした？

179 ：デフォルトの名無しさん：2013/04/13(土) 13:09:09.09

面倒くさいから、ハードウエアリセット
えぇ、うちの会社の数千万円の装置です

180 ：デフォルトの名無しさん：2013/04/13(土) 13:28:52.88

億行ってる装置でも再起動させるんだから全然問題ないな

181 ：デフォルトの名無しさん：2013/04/13(土) 13:37:51.63

無能な開発のケツを運用が拭けばいいだけの話だな

182 ：デフォルトの名無しさん：2013/04/13(土) 15:35:08.93

↑まともな開発を不可能にする無能すぎる営業が背伸びしてPG板に来ちゃいました？

183 ：デフォルトの名無しさん：2013/04/13(土) 16:42:33.94

発狂パーティーを開催いたします

184 ：デフォルトの名無しさん：2013/04/13(土) 20:28:25.02

C++で常時起動型のサーバープログラムを
書いてはいけないんですねわかります。
だからプロセス終了とか言っちゃうんですねﾌﾟ

185 ：デフォルトの名無しさん：2013/04/13(土) 20:31:13.86

大丈夫だよ週次リブート()とかするから

186 ：デフォルトの名無しさん：2013/04/13(土) 20:58:59.50

linux daemon全否定w

187 ：デフォルトの名無しさん：2013/04/13(土) 21:54:55.64

ここの人たち技術ないから

188 ：デフォルトの名無しさん：2013/04/13(土) 22:16:51.32

RAIIに技術?

189 ：デフォルトの名無しさん：2013/04/14(日) 00:04:39.90

なんでRAII限定にしたのか知らないけど常時起動型のサーバープログラムを落とす技術

190 ：デフォルトの名無しさん：2013/04/14(日) 10:36:28.81

C系はメモリ破壊の可能性を否定できないからな。
キチンと試験して稼働実績の有るプログラムでも
新人が加えた一文字のスペルミスで
既存部分のメモリが破壊されて火を噴くから、
プロセス分割したり短時間で終了するような
ウンコ設計にしないと、
精神論だけでは品質を保てないウンコ言語。

191 ：デフォルトの名無しさん：2013/04/14(日) 10:43:56.90

使えん新人１００人より
優秀な奴5人の方が生産性高いと思うぞ

192 ：デフォルトの名無しさん：2013/04/14(日) 11:14:05.85

最初はみんな新人さ。

193 ：デフォルトの名無しさん：2013/04/14(日) 11:31:10.84

"C++0x Concepts Should Stay Dead" -- Bjarne Stroustrup

194 ：デフォルトの名無しさん：2013/04/14(日) 11:53:28.15

conceptがC++がプログラミング言語の世界に出来る最大の貢献だと思うがな。
generic programmingの集大成だろう。

195 ：デフォルトの名無しさん：2013/04/14(日) 12:45:31.75

>conceptがC++がプログラミング言語の世界に出来る最大の貢献

Javaのインターフェースの劣化版コピーだと
思っとりました。

196 ：デフォルトの名無しさん：2013/04/14(日) 12:50:27.31

>>195
もしかしてtraitsも知らないの?
traitsの時点でJavaのinterfaceとはぜんぜん違うだろ。

197 ：デフォルトの名無しさん：2013/04/14(日) 12:51:27.26

えっ？

198 ：デフォルトの名無しさん：2013/04/14(日) 12:52:01.85

>>195の意味がわからん

199 ：デフォルトの名無しさん：2013/04/14(日) 13:03:59.14

寝言だろ
気にするな

200 ：デフォルトの名無しさん：2013/04/14(日) 13:15:39.44

Javaは同じSunにいたSelfグループのtraitとmixinに対する成果をうまく取り入れられてない。

201 ：デフォルトの名無しさん：2013/04/14(日) 13:30:26.27

もしかしてConceptsって単語をconceptのことだと勘違いした？

202 ：デフォルトの名無しさん：2013/04/14(日) 13:37:34.91

inheritanceとかinterfaceとかtraitとかmixinとかDIとかbindingsとか
区別がつかない
wikipediaからもってきたflavors、roles、abstract classも追加

スレッドやら関数回りも同じような
thread、fiber、coroutine、Light-weight process、microthread、protothread

区別する程有用な作用があるのか
俺が何か間違ってる事は正しいんだけど

203 ：デフォルトの名無しさん：2013/04/14(日) 13:41:47.00

インヘリタンスは分かれよ。

204 ：デフォルトの名無しさん：2013/04/14(日) 14:06:37.40

むしろインヘリタンスと何の区別が付かんのだろw

205 ：デフォルトの名無しさん：2013/04/14(日) 14:14:43.39

バカっぽいんだけど妙に面白い事言うやつっているよね

206 ：デフォルトの名無しさん：2013/04/14(日) 14:41:30.99

C++のtraitsはクラス書かないでも
traitsをユーザ定義して型をどうマッチさせるか記述できる。

207 ：デフォルトの名無しさん：2013/04/14(日) 15:11:36.28

C++0x concept には死んで貰って、concept lite に生まれ変わるという話。

208 ：デフォルトの名無しさん：2013/04/14(日) 15:20:29.09

concept liteはあくまで繋ぎでしょ

209 ：デフォルトの名無しさん：2013/04/14(日) 15:59:41.12

>>208
その辺も含めて >>193 の表題の文章に書いてある

210 ：デフォルトの名無しさん：2013/04/14(日) 16:43:03.96

早く当初の構想どおりの完全版conceptが
現実にならないものかね。

211 ：デフォルトの名無しさん：2013/04/14(日) 16:45:05.56

またtemplateでの黒魔術が増えるの？

212 ：デフォルトの名無しさん：2013/04/14(日) 17:42:13.50

>>211
template 周りのコンパイルエラーで出てくる謎の暗号を解読しなくてよくなる

213 ：デフォルトの名無しさん：2013/04/14(日) 17:59:08.71

ほう

214 ：デフォルトの名無しさん：2013/04/14(日) 23:09:59.88

日本語の解説本って、いつになったら出るの？

215 ：デフォルトの名無しさん：2013/04/15(月) 01:08:22.12

Boost C++ Libraries プログラミング第3版に期待するべ

216 ：デフォルトの名無しさん：2013/04/15(月) 01:24:13.37

それは11の解説書としては使い物にならないだろ

217 ：デフォルトの名無しさん：2013/04/15(月) 01:33:38.91

解説なんてその辺の解説サイトでいいでしょ。
仕様を正しく理解したいなら原文しかないぜよ。

218 ：デフォルトの名無しさん：2013/04/15(月) 01:38:06.83

疑問点があればここではなく、Stack Overflow で質問するといい。

219 ：デフォルトの名無しさん：2013/04/15(月) 01:53:20.81

Stack Overflow質問文テンプレ
「初心者です(_*_)。右辺値参照って何ですかぁ？
　調べたけどさっぱりですぅ☆
　エロい人宜しく(^^)/
　あ、答えられない人のレスはお断りです(ﾌﾟｹﾞﾗ

220 ：デフォルトの名無しさん：2013/04/15(月) 02:22:19.91

>>219
はっはっは。元気があっていいね。頑張るんだよ。

221 ：デフォルトの名無しさん：2013/04/15(月) 02:27:33.28

日本語じゃないので☆1つ

222 ：デフォルトの名無しさん：2013/04/16(火) 00:18:44.22

>>191
しかしその優秀な人たちは管理業務にまわされます。

223 ：デフォルトの名無しさん：2013/04/16(火) 01:25:53.28

日本のキャリアパスにシニアプログラマってあまりないからな

224 ：デフォルトの名無しさん：2013/04/16(火) 02:52:46.46

未経験の若いプログラマ雇って炎上みたいなのばかり

225 ：デフォルトの名無しさん：2013/04/16(火) 03:24:29.66

>>202
クックック... 我はinheritanceの使い手にして最凶のinterface、
我が道を阻むことなどたとえabstract classでもできはせぬわ
このスレの住人供よ、Light-weight processなど捨てて我が軍門に下るがよいわ

俺もよくわからんけど、多分このへんの単語考えた外人は中二病なんだろうと思うよ。
「俺の考えた呼び方の方がかっけーし」見たいな感じで
クラウドとかも内輪ではめっちゃ受けてるのかもしれん

226 ：デフォルトの名無しさん：2013/04/16(火) 23:52:19.27

>>224
出来るヤツだけ集めても
なぜかうまくいかないのが
プロジェクトと言うもの・・・

227 ：デフォルトの名無しさん：2013/04/17(水) 00:35:42.00

まとめるとプロジェクトは失敗するもの

228 ：デフォルトの名無しさん：2013/04/17(水) 00:59:50.26

JISのC++11って何巻目になるん？
1冊1万前後だから結構な出費だな

229 ：デフォルトの名無しさん：2013/04/17(水) 07:30:48.76

>>227
まとめすぎｗｗｗ

230 ：デフォルトの名無しさん：2013/04/17(水) 08:35:27.55

COM（Direct3D11）を使ってプログラミングしてて、
インターフェースの解放（Release）を忘れないように、
shared_ptrを使おうとしてるんだけど、壁にぶつかった。

ある関数はインターフェースのポインタを引数に取る。
この場合は以下で大丈夫。

shared_ptr<ID3D11xxx> pD3D11xxx;

･･･

Func( pD3D11xxx.get() );

しかし、関数の中にはインターフェースのダブルポインタ（ID3D11xxx* const* pp）を引数に取るものがあって、
以下のように書いても「'&'に左辺値がない」と言ってコンパイラに怒られる。

Func( &pD3D11xxx.get() );

どうしたものかと、検索をかけると、
shared_ptrではなくて自作っぽいスマートポインタを作って、
pD3D11xxx.GetAddressOf()みたいなメソッドを利用して引数に与えていた。

std::shared_ptrでは上記みたいな関数に渡せないの？？

231 ：230：2013/04/17(水) 08:39:56.70

ID3D11xxx* p = pD3D11xxx.get();
Func( &p );

ってしたらコンパイルは通ったけど、
もっとエレガントにできないかなぁ。

232 ：デフォルトの名無しさん：2013/04/17(水) 08:41:29.81

CComPtrを使えばよろし

233 ：230：2013/04/17(水) 08:59:24.88

>>232
CComPtrなら大丈夫なんですね。
しかし、できればATLに依存したくないんです。

234 ：デフォルトの名無しさん：2013/04/17(水) 09:04:19.90

ポインタのポインタを受け取るってことはポインタ自体の変更が行われるわけで
ID3D11xxx* p;
Func(&p);
pD3D11xxx.reset(p);
こんな風にするしかないだろう

235 ：230：2013/04/17(水) 09:20:06.70

>>234
ありがとう！
ああ、そうか。
面倒くさい。死にそう･･･。

調べてみると、どうもATLとは違うMicrosoft::WRL::ComPtrというのがあるみたい。
http://msdn.microsoft.com/ja-jp/library/vstudio/br230382.aspx

なぜATLがイヤかというと、
まず開発がVC++のExpress（無料）バージョンが使えないこと。
自分はPro持ってるけど、他人にプロジェクトを渡すことがあって、
できれば相手にProを強要したくない。

あと、コンパイルした.exeを配布する際、
ATLを使用していると、ランタイムのインストールをユーザーに強要することになる。

WRLだとどうなんだろうか？
開発的にはExpress（for Windows8だけど）で使えることが調べて分かった。
あとは.exeを配布するときにユーザーがWRLのための追加インストールが必要か。
こういうのってどうやって調べたらいいの？
DependencyWalkerとかでチェックしかないかな。

236 ：デフォルトの名無しさん：2013/04/17(水) 09:27:56.32

>>235
ATLは古いのならWDK7.1辺りに入ってたりする
CComPtrはテンプレートなんだからランタイムも糞もないぞ

237 ：デフォルトの名無しさん：2013/04/17(水) 09:32:01.68

WTL?

238 ：230：2013/04/17(水) 09:59:29.69

早速WRLのComPtr使ってみた。
余計なコードが激減した。
感動した。
さっきまで悩んでたのがあほみたいだ。
もう他人のことなど知るか（おい）

>>236
ありがとう！
安心した。

239 ：230：2013/04/17(水) 10:07:14.80

少し気になったのは、
同じダブルポインタ引数でも、
Create系では&pって渡せるのに、
他の関数ではp.GetAddressOf()で渡さないといけないこと。
後者を&pで渡したらぶっ壊れた。

まぁ、Create系もGetAddressOf()でいけるから、
これで統一しておくほうが無難かな。

240 ：デフォルトの名無しさん：2013/04/17(水) 10:10:33.16

またひとりC++/CXの魔境に旅立ってしまったか

241 ：デフォルトの名無しさん：2013/04/17(水) 10:14:10.97

ttp://msdn.microsoft.com/ja-jp/library/vstudio/br230430.aspx
日本語おかしいがちゃんと違いが書いてあるじゃない

242 ：230：2013/04/17(水) 10:22:51.60

>>241
あ、すんません･･･。
ああ、そういうことか。
参照カウントのこと意識せんといかんのね。

しかし、Create系以外でダブルポインタを引数に取るとか、
ややこしいからやめてくんないかなぁ･･･。

243 ：デフォルトの名無しさん：2013/04/20(土) 13:36:39.41

普通は戻り値使うよね

244 ：デフォルトの名無しさん：2013/04/21(日) 13:15:09.07

C++11のテンプレートの実体化のことで疑問なんですが

extern templateと、それをtypedefしたものを同時に使った場合
extern template Temp<T>; の直後に typedef Temp<T> Type; とすると実体化されてしまいますか？

もう一つ、以下のようにusingにtemplateを付けない場合、実体化されますか？
using Type = Temp<T>;

245 ：デフォルトの名無しさん：2013/04/21(日) 16:04:03.90

extern template とか考えなくても、
typedef しただけじゃメンバ関数は実体化しないだろ？
ならそういうことだ。

// a.h
template <class T> struct Temp { void f(); };

// a.cpp
#include "a.h"
template <class T> Temp<T>::f(){}
typedef Temp<T> Type; // これじゃ実体化しない

// main.cpp
#include "a.h"
int main(){ Temp<T>f(); } // 実体化してないので使えない

246 ：デフォルトの名無しさん：2013/04/21(日) 16:34:23.46

さわるなよ

247 ：デフォルトの名無しさん：2013/04/21(日) 18:59:40.33

？

248 ：デフォルトの名無しさん：2013/04/23(火) 22:43:29.02

触らないで触らないで垢が付くから

249 ：デフォルトの名無しさん：2013/04/24(水) 00:18:50.88

やめてよして触らないで垢が付くから
だったな俺の地域では

250 ：デフォルトの名無しさん：2013/04/24(水) 08:00:21.15

ここは加齢臭漂うスレですね

251 ：デフォルトの名無しさん：2013/04/24(水) 19:22:29.66

>>249
うちもそう。

あんたなんてキライよ♪顔も見たくない、ふん！

252 ：デフォルトの名無しさん：2013/04/25(木) 13:38:24.46

MicrosoftがClangに興味を示しているらしいですね
VCもClang/LLVMに切り替えるつもりなんだろか

253 ：デフォルトの名無しさん：2013/04/25(木) 13:58:55.30

半年間（場合により延長有）なんて雇用で切り替えられるか？

254 ：デフォルトの名無しさん：2013/04/25(木) 21:49:05.68

もしそうだとしてもVC++の独自仕様・拡張を維持したいだろうから
フロントエンドはClangでなく全く独自のものかClangの改造版になるだろう
そのうえでバックエンドをLLVMに切り替えるというのならありえなくはないかな

255 ：デフォルトの名無しさん：2013/04/25(木) 22:06:24.13

Linuxカーネルもgccを独自に拡張して使ってるせいで
未だclangでコンパイルできないときいた

256 ：デフォルトの名無しさん：2013/04/25(木) 23:18:30.60

extension will never be supported

257 ：デフォルトの名無しさん：2013/04/25(木) 23:25:21.40

何で今更C言語に戻るの？

258 ：デフォルトの名無しさん：2013/04/25(木) 23:32:14.55

LinuxのデバイスドライバってC固定？

259 ：デフォルトの名無しさん：2013/04/26(金) 00:16:46.60

C#に対するMonoみたいないやつを、
Clangで作るって公開するってことならありうるかも。
C#懼Mono
C++/CLI懼Clang/CLI

260 ：デフォルトの名無しさん：2013/04/26(金) 00:57:57.63

mono-projectでも、Clang C++/CLIをposix環境にポートするためのコミッター募集してる

http://www.mono-project.com/StudentProjects#Tools_and_Compilers

261 ：デフォルトの名無しさん：2013/04/28(日) 12:05:43.36

まだ一人で書いてるんだな。
どこにそんな時間があるのか...

The C++ Programming Language, 4th Edition [Paperback]
http://www.amazon.com/The-Programming-Language-4th-Edition/dp/0321563840/
Publication Date: May 20, 2013

262 ：デフォルトの名無しさん：2013/04/28(日) 13:37:28.20

http://www.amazon.com/dp/0321563840/
http://www.amazon.co.jp/dp/0321563840/

時価で$51.95が5099円
$25以上で送料無料でこの差額の2500円はどっからくるのだ

c++11のリファレンス期待でUSの方でポチッてるがな

263 ：デフォルトの名無しさん：2013/04/28(日) 13:55:49.58

俺のポッケに入る

264 ：デフォルトの名無しさん：2013/04/28(日) 14:17:07.04

個人で輸入すると関税も個人で払うことになるから
かえって高くなるかも試練

265 ：デフォルトの名無しさん：2013/04/28(日) 20:24:40.11

１３００ページか
日本語版は１万円くらいになりそうだな

266 ：デフォルトの名無しさん：2013/04/28(日) 20:29:58.63

英語版がPDFで多量に流出しちゃってるんだが・・・

でも日本語版でないと読めないしなあ早く出版してくれ

267 ：デフォルトの名無しさん：2013/04/28(日) 20:36:58.05

おまえら禿の妄想本なんかでなく
ちゃんとisoの規格嫁よ

268 ：デフォルトの名無しさん：2013/04/28(日) 20:37:50.11

めんどい

269 ：デフォルトの名無しさん：2013/04/28(日) 21:51:19.53

JISは無料なのでJIS待ち

270 ：デフォルトの名無しさん：2013/04/28(日) 21:55:11.09

えっ、JISってただなの？

271 ：デフォルトの名無しさん：2013/04/28(日) 22:11:30.19

見るだけならね

272 ：デフォルトの名無しさん：2013/04/28(日) 22:23:54.54

見る以外の使い道ないだろ

273 ：はちみつ餃子 ◆8X2XSCHEME ：2013/04/28(日) 22:35:08.67

>>
JISC のサイトで見れるよ。
http://www.jisc.go.jp/

但し、ウェブで閲覧することが出来るだけで、保存や印刷は出来ない。
それが必要なら買ってくれってことになってる。
実際はちょっと小細工すれば保存も印刷も出来るけど。

日本の法律だと公文書には著作権が発生しないことになってて、
法的に見れば JIS 規格は公文書であると考えられている (異論はある) んだけど、
ISO の規約では規格に著作権があることになってるのでそれに批准していることになってる日本としては著作権を認めなければならず、
間を取って閲覧だけ無料でという微妙な状況。
(ISO は民間団体なので国際条約のような強制力はなく、厳密に言えば日本の法律をそのまま適用してかまわない。)

実際のところ、規格書って高すぎだよなー。
10ページもないようなペラッペラの冊子でも何千円も取るんだぜ。

274 ：デフォルトの名無しさん：2013/04/28(日) 22:40:21.02

JISは誤訳あるから注意。

275 ：デフォルトの名無しさん：2013/04/28(日) 22:50:19.30

規格書はISOの運営資金源だし払うのは普通企業だから仕方ないといえば仕方ない

276 ：デフォルトの名無しさん：2013/04/28(日) 22:56:21.66

>>273
> 但し、ウェブで閲覧することが出来るだけで、保存や印刷は出来ない。

この部分が不思議だよな。
閲覧できるということはどこかには保存されている。
どこにどう保存するかはUAの設計次第だし、
プログラマ視点で考えると「どうするかは、要は自分の考え次第」

277 ：デフォルトの名無しさん：2013/04/28(日) 22:59:58.44

>>276
今時の電子出版も分からないのですね?
凄いプログラマがいるもんだな。

278 ：デフォルトの名無しさん：2013/04/28(日) 23:01:41.90

>>277
webでPDF公開している形の電子出版なんかあるの？

279 ：デフォルトの名無しさん：2013/04/28(日) 23:16:48.26

Adobe JavaScriptを使用している唯一の糞PDF

280 ：デフォルトの名無しさん：2013/04/28(日) 23:48:16.24

規格の後ろ盾が必要ない人はISOのdraftを見ればよい。
無料でダウンロードできる。

281 ：デフォルトの名無しさん：2013/04/29(月) 05:19:43.22

後ろ盾の必要ない人はググってりゃいい。
難解な規格を読み解くのは人生の時間の無駄。
自己満オナニーしたい人だけご購入ください。

282 ：デフォルトの名無しさん：2013/04/29(月) 05:37:09.54

このご時世にc++11使ってる人はみんなオナニスト

283 ：デフォルトの名無しさん：2013/04/29(月) 07:53:40.60

そんなに褒めるなよ照れるだろ

284 ：デフォルトの名無しさん：2013/04/29(月) 08:01:05.25

右辺値山椒で1ヶ月ぐらいは抜ける

285 ：デフォルトの名無しさん：2013/04/29(月) 08:10:54.65

おまいら変態すぎてﾜﾛﾀｗ

286 ：デフォルトの名無しさん：2013/04/29(月) 09:58:06.98

スレ違いだが。

>273
>日本の法律だと公文書には著作権が発生しないことになってて
そうだっけ？
13条は法令とかでこれを公文書全体ととるのは拡大解釈じゃないの？
米国著作権法だと連邦政府職員の職務による著作物には
著作権が発生しないことになってるけど。

287 ：デフォルトの名無しさん：2013/04/29(月) 10:33:03.77

http://cpplover.blogspot.jp/2010/09/aggregate.html

別件で検索してて見付けたんだけど、
この人、C++11の標準化委員会のメンバーになるような人なのに仕事がないんだって･･･。
どういうことなの？？

288 ：デフォルトの名無しさん：2013/04/29(月) 11:05:58.76

委員会は飯の種にはならんだろうし
オナニー言語の仕様を議論できるのは
相当なアスぺ脳基地外である確率が高い

289 ：デフォルトの名無しさん：2013/04/29(月) 11:23:39.04

天才とキチガイは紙一重ってか･･･。
何か報われないね･･･。

290 ：デフォルトの名無しさん：2013/04/29(月) 11:39:39.23

自己紹介の書き出しが
「自由ソフトウェア主義者」
ってなってる痛い状況だしね

291 ：デフォルトの名無しさん：2013/04/29(月) 11:50:02.79

あの人は自由自由言ってて気持ち悪い

292 ：デフォルトの名無しさん：2013/04/29(月) 11:51:43.94

とか言いつつこのスレ常駐してるやつはみんな見てるんだろそこ

293 ：デフォルトの名無しさん：2013/04/29(月) 11:52:36.50

そりゃ見ないと気持ち悪いかどうかわからんからな

294 ：デフォルトの名無しさん：2013/04/29(月) 12:10:23.91

こんな小者知らんがな。きんもー☆

295 ：デフォルトの名無しさん：2013/04/29(月) 12:37:55.64

こういう変な思想ってヒッピー辺りから受け継いだものなのか？
ストールマンとか、正直見ていて怖いぞ。

296 ：デフォルトの名無しさん：2013/04/29(月) 12:54:23.73

江添さんは思想関係ないときの記事はわかりやすい
思想が絡むと色々めんどい　宗教家の典型

297 ：デフォルトの名無しさん：2013/04/29(月) 12:54:30.32

空飛ぶスパゲッティー教信者だしな

298 ：デフォルトの名無しさん：2013/04/29(月) 13:02:23.07

空飛ぶスパゲッティ・モンスター教な
昔これの本買ったわ
ラーメン

299 ：デフォルトの名無しさん：2013/04/29(月) 14:05:54.42

まあ面倒な人じゃなければ普通にバリバリ仕事してるだろうな
しかし面倒な人じゃなければC++にあそこまで入れ込んでないとも言える

300 ：デフォルトの名無しさん：2013/04/29(月) 15:23:24.72

日本の標準化委員会の人もあれだよな掲示板の発言みてると性格きつい

301 ：デフォルトの名無しさん：2013/04/29(月) 15:26:01.62

委員にとってアスぺは褒め言葉なのであります

302 ：デフォルトの名無しさん：2013/04/29(月) 15:28:19.70

誰？

303 ：デフォルトの名無しさん：2013/04/29(月) 15:32:47.94

http://cpplover.blogspot.jp/

ここだろ？お前らにここに書いてある内容を超える記事が毎日書けるのか？

304 ：デフォルトの名無しさん：2013/04/29(月) 15:35:06.46

わんくまもそうだな
まあ俺は好きだけど

305 ：デフォルトの名無しさん：2013/04/29(月) 15:41:27.33

もうライターになればいいんじゃね？

306 ：デフォルトの名無しさん：2013/04/29(月) 15:47:40.25

化委員ライターアスぺス

307 ：デフォルトの名無しさん：2013/04/29(月) 15:52:52.88

大学教授のほうがよっぽどアスペなのに、社会的地位が高いのがムカつくぜ。

308 ：デフォルトの名無しさん：2013/04/29(月) 16:01:44.33

アスぺのくせに自分の価値を主張するとは生意気だな
アスぺは所詮、特定領域で役に立つこともたまにある使い捨てのコマ

309 ：デフォルトの名無しさん：2013/04/29(月) 16:03:19.02

それを言ったら会長以外全員使い捨てのコマ

310 ：デフォルトの名無しさん：2013/04/29(月) 16:08:59.88

人間は所詮、猫の下僕

311 ：デフォルトの名無しさん：2013/04/29(月) 17:22:37.79

猫でも分かるC++14

312 ：デフォルトの名無しさん：2013/04/29(月) 17:29:32.79

C++14にもなるとPL/Iを遥かに超えるかつてない言語規模になるなあ
まあ現状でももう超えてるだろうけどさ
STLが大き過ぎ

313 ：デフォルトの名無しさん：2013/04/29(月) 17:39:08.03

さすがに2013年なんだし 外部ライブラリの利用はrubygemsやcpanみたいな、LL系のやつ見習ってほしい
Goにはそういう機構ある

314 ：デフォルトの名無しさん：2013/04/29(月) 18:51:41.38

江添はさっさと本出して寄付金の用途公開しろよ

315 ：デフォルトの名無しさん：2013/04/29(月) 18:53:26.64

そろそろモジュールシステムをどうにかしてほしい

316 ：デフォルトの名無しさん：2013/04/29(月) 19:01:45.11

c++14ってそんなにすごいんですか？

317 ：デフォルトの名無しさん：2013/04/29(月) 19:11:57.35

optionalさんが入るらしいので楽しみ

318 ：デフォルトの名無しさん：2013/04/29(月) 19:20:02.04

おまいら11の前でもそれいえんの

319 ：デフォルトの名無しさん：2013/04/29(月) 19:25:42.92

そろそろスレタイからC++11外していいと思う

320 ：デフォルトの名無しさん：2013/04/29(月) 22:11:24.91

c++スレも11が当たり前になりつつあるしね
本スレはアスぺの集う自慰スレでおk

321 ：デフォルトの名無しさん：2013/04/29(月) 22:45:10.02

モジュールとABIと静的リフレクションを入れてくれ

322 ：デフォルトの名無しさん：2013/04/29(月) 23:46:11.47

何を入れろじゃなくて、どの問題を解決すべきなのかで言ってほしいな。

323 ：デフォルトの名無しさん：2013/04/29(月) 23:53:45.13

オナニーするのに理由が必要なのかよ
実用を考えたらこれ以上肥大化させないで欲しいものだ

324 ：デフォルトの名無しさん：2013/04/29(月) 23:58:40.67

でも最終的にboostまで入れるんじゃないの？

325 ：デフォルトの名無しさん：2013/04/30(火) 00:54:08.38

零オーバーヘッドの法則があるから使わない機能が増えても問題ないな

326 ：デフォルトの名無しさん：2013/05/06(月) 21:08:02.41

おいテンプレートが追加されたぞ！
　→ゼロオーバーヘッドだから関係ないね
おい右辺値参照で効率化だって！
　→ゼロオーバーヘッドだから関係ないね
おいautoでイテレーターがすっきりだって！
　→ゼロオーバーヘッドだから関係ないね
おいマルチスレッドが標準化されたぞ！
　→ゼロオーバーヘッドだから関係ないね
おいラムダでコードの局所性があがりそうだ！
　→ゼロオーバーヘッドだから関係ないね
おいvectorの要素が連続だって！
　→ゼロオーバーヘッドだから関係ないね
おいconstexprで定数表現の範囲が広がぞ！
　→ゼロオーバーヘッドだから関係ないね

327 ：デフォルトの名無しさん：2013/05/06(月) 21:48:42.98

ゼロオーバヘッドってなんかかっこいいなｗ

328 ：デフォルトの名無しさん：2013/05/06(月) 22:15:02.27

ゼロオーバーヘッドさんの
確執っぷりが漢らしい

329 ：デフォルトの名無しさん：2013/05/06(月) 22:21:22.16

言い換えると「嫌なら使うな」

330 ：デフォルトの名無しさん：2013/05/07(火) 07:39:03.20

まぁそんなことばっか言ってっからこんな事になった訳ですが

331 ：デフォルトの名無しさん：2013/05/07(火) 12:39:52.50

こんなことってどんなこと？

332 ：デフォルトの名無しさん：2013/05/07(火) 13:00:46.42

ミドルウェアでの圧倒的なシェアじゃない?

333 ：デフォルトの名無しさん：2013/05/08(水) 00:48:45.38

ゼロオーバーヘッド気に入った
これからリアルでどんどん使ってく

334 ：デフォルトの名無しさん：2013/05/08(水) 02:13:13.53

でもリアルにはよくいるよね。
Javaが5にメジャーバージョンアップだって！
　→既存コードはそのまま動くから関係ないね
俺らの年金が確定拠出になったぞ！
　→ゼロオーバーヘッドだから関係ないね
お前そろそろ結婚しないと
　→ゼロオーバーヘッドだから関係ないね
おい松葉杖の人が乗ってきたぞ
　→ゼロオーバーヘッドだから関係ないね

335 ：デフォルトの名無しさん：2013/05/08(水) 10:19:43.53

センス無いな

336 ：デフォルトの名無しさん：2013/05/08(水) 21:19:10.91

何書いてようがスルーすればゼロオーバーヘッドだから問題ない

337 ：デフォルトの名無しさん：2013/05/10(金) 00:12:04.84

http://www.open-std.org/jtc1/sc22/wg21/
News 2013-05-09: The deadline for the next mailing is 2013-06-28
News 2013-05-09: The 2013-05 mailing is available
News 2013-05-09: The C++ Standard Core Language Issues List (Revision 83) is available

338 ：デフォルトの名無しさん：2013/05/11(土) 07:40:29.30

日本語でおｋ

339 ：デフォルトの名無しさん：2013/05/14(火) 09:36:12.41

粒度の小さいループとかTPLのように並列化する手段ってないの？

340 ：デフォルトの名無しさん：2013/05/15(水) 18:18:42.54

無い

341 ：デフォルトの名無しさん：2013/05/26(日) 09:38:44.71

http://www.open-std.org/jtc1/sc22/wg21/
News 2013-05-24: The CD for the new C++ standard is released
News 2013-05-24: New ub reflector and archive. for undefined behaviour study group.

342 ：デフォルトの名無しさん：2013/05/26(日) 09:41:44.54

日本語でおk

343 ：デフォルトの名無しさん：2013/05/26(日) 09:47:43.87

そんな糞文章の作るより
PDFみたいな糞に代わるまっとうな
ファイルフォーマットでも作れよ

344 ：デフォルトの名無しさん：2013/05/26(日) 10:16:14.21

本の虫の人おつ

345 ：デフォルトの名無しさん：2013/05/26(日) 10:44:06.81

pdfってほんと糞だよな

346 ：デフォルトの名無しさん：2013/05/26(日) 10:58:41.52

PDFはクソだけど本の虫のPDF叩きネタは寒い
後で本人が見返すときに恥ずかしくなるだろう

347 ：デフォルトの名無しさん：2013/05/26(日) 11:06:49.23

PlainTextFormatは糞
いつまでPlainTextFormatでプログラミングするんだよ

348 ：デフォルトの名無しさん：2013/05/26(日) 11:11:11.62

>>344
ISでなくドラフトだろ？
成果でなく努力を労う内輪ネタを
2ちゃんでやるなハゲ

349 ：デフォルトの名無しさん：2013/05/26(日) 11:17:03.97

>>347
http://www.stroustrup.com/Software-for-infrastructure.pdf
> WHY WORRY ABOUT CODE?
> Do we need traditional programmers and traditional programs?
> Can’t we just express what we want in some high-level manner,
> such as pictures, diagrams, high-level specification languages,
> formalized English text, or mathematical equations, and
> use code-generation tools to provide compact data structures
> and fast code? ...

350 ：デフォルトの名無しさん：2013/05/26(日) 11:18:06.55

> ... I suspect that we can make progress on many fronts, but for
> the next 10 years or so, relying on well-structured, type-rich
> source code is our best bet by far.

351 ：デフォルトの名無しさん：2013/05/26(日) 11:20:07.97

ドラフトがないと、過去のドラフトとの diff を取って頭をアップデートすることができない

352 ：デフォルトの名無しさん：2013/05/26(日) 11:26:05.18

今度から全てのレスには「江添さんﾁｰｯｽ!」を付けよう

>>341,349
江添さんﾁｰｯｽ!

353 ：デフォルトの名無しさん：2013/05/26(日) 14:14:16.42

つまり
>>342-348 = >>352
ということか

354 ：デフォルトの名無しさん：2013/05/26(日) 14:20:57.92

>>353
江添さんﾁｰｯｽ!

355 ：デフォルトの名無しさん：2013/05/26(日) 14:33:01.73

PDFは閲覧ソフトの操作が糞。
作るソフトが有償なのが糞。
時々動き出すAdobeARM.exeとかいう
アップデートウイルスが糞。
フォーマットはどうでもいいや。

356 ：デフォルトの名無しさん：2013/05/26(日) 15:31:38.38

盲目的にAdobeのソフトしか使わない人か

357 ：デフォルトの名無しさん：2013/05/26(日) 15:38:48.86

>>356
江添さんﾁｰｯｽ

358 ：デフォルトの名無しさん：2013/05/26(日) 15:57:49.74

Office で文書を作って
受け渡し・公開するときは PDFでっていう規則があるんだろ

359 ：デフォルトの名無しさん：2013/05/26(日) 15:57:51.42

Adobeなんて月5000円で使い放題じゃん

360 ：デフォルトの名無しさん：2013/05/26(日) 16:16:06.02

日本規格協会の販売するISO規格PDFは
見出しが付いていないので糞
日本規格協会の販売するJIS規格PDFはよく
テキスト検索できないので糞

361 ：デフォルトの名無しさん：2013/05/26(日) 16:23:28.16

６万円で買い切りにしてくれれば１年で元取れるのにケチくさい話。

362 ：デフォルトの名無しさん：2013/05/26(日) 16:31:07.55

昔は、postscriptみたいなページ記述言語で手書きしたりスクリプト書いて印刷したり、NEXT/AppleもDisplay PostScriptを用意したり結構重宝されてたんだけどな。
GNUも重要性分かっててghostscriptやgnustepあるわけだし。
PDFはそのPostScriptの交換向けのもの。

Officeほどバイナリなデータフォーマットではなかったので、
illustratorやPageMakerのフリーソフトウエアのクローンが出ていれば、
一般的な認識も編集不可な印刷物的なファイルフォーマットとは、ならなかったかも。

実際には、GUIのツールは開発コストがかかるので、(企業のお金がガンガン投入されてるが)オープンな実装で花開いたのはブラウザだけなので、
フリーなGUIにこだわるなら、WEB関連技術の資産を増やすしかない訳だが。

363 ：デフォルトの名無しさん：2013/05/26(日) 16:34:00.83

PDFの見出し自体が糞であり、あれはシカトするのが正論
JSAの糞なところは公文書に高額な金を取るところ

# 年額6万とか本当に貢いでる情弱いないよな？　ネタだよな
# ケチるつもりがなくても馬鹿すぎる

364 ：デフォルトの名無しさん：2013/05/26(日) 16:37:37.80

PCやワークステーションのOS作るのにC++は必須？というか向いている？

365 ：デフォルトの名無しさん：2013/05/26(日) 16:45:13.37

C++がOS作りに向いてるとか言うとLinusさんが激怒するんじゃまいか

366 ：デフォルトの名無しさん：2013/05/26(日) 16:46:28.86

MonaOSはC++だったろ

367 ：デフォルトの名無しさん：2013/05/26(日) 16:59:53.85

Cなんて使っているから脆弱なんだよLinuxは

368 ：デフォルトの名無しさん：2013/05/26(日) 17:24:30.10

じゃあ主にC++使ってて堅牢なOS教えてくれ
言っておくが堅牢と言われてるSolarisとかOpenBSDだって

369 ：デフォルトの名無しさん：2013/05/26(日) 17:37:30.51

Darwinはドライバがembedded C++相当くらいしか思い浮かばないな。

370 ：デフォルトの名無しさん：2013/05/26(日) 19:43:40.63

Darwin の IOKit の C++ は、かなり面白、不思議なことになってたな

371 ：デフォルトの名無しさん：2013/05/26(日) 19:50:41.77

SystemCという腐ったC++のライブラリがあって、それでHW作ってるよ。
堅牢かどうかは知らんけど。
HW系の人は本当にダメ…

372 ：デフォルトの名無しさん：2013/05/26(日) 20:26:50.34

BeOSはほぼ全部C++で書かれていたな。
Be->Palm->ACCESSと買収で所有権が変わってる。
クローンのHaikuってOSがあるらしい。

373 ：デフォルトの名無しさん：2013/05/26(日) 20:35:15.34

>>371
同意

374 ：364：2013/05/26(日) 22:00:54.06

様々な意見、参考になりました。

375 ：デフォルトの名無しさん：2013/05/26(日) 22:10:38.87

つ SunのSpring

376 ：デフォルトの名無しさん：2013/05/26(日) 22:38:10.57

LinuxとかBSDを作ってた頃はGCCのC++の実装は糞だったから
C++は選択肢に入ってなかった

377 ：デフォルトの名無しさん：2013/05/26(日) 22:47:58.59

ここまでwindowsなs(ry

378 ：デフォルトの名無しさん：2013/05/27(月) 12:12:16.56

>>371
SytemCはC++のライブラリじゃなくC++の言語フォーマットをパクッたHDLだろ
VHDLがAdaパクッたようにさ

379 ：デフォルトの名無しさん：2013/05/27(月) 19:29:23.16

C++使いって、いまじゃC++使い用HDLのSystemCを使いICの論理設計もできないなと馬鹿にされるからな
もう、C/C++な奴はハードからソフトまでこなせないようじゃ価値なしって感じなっているし
ソフトならC/C++でなくてJavaやC#などで十分ってのが非常に増えたからしょうがないか

380 ：デフォルトの名無しさん：2013/05/27(月) 20:13:44.83

>>378
ライブラリだよ。C++コンパイラでコンパイルして実行できる。
マクロも使ってるけどw

381 ：デフォルトの名無しさん：2013/05/27(月) 20:45:46.55

>>379
おせーよ！重くてイライラする言語でアプリつくんじゃねえ

382 ：デフォルトの名無しさん：2013/05/27(月) 20:47:47.29

CPUが２００倍速くなってメモリが１万倍になってもダメダメなソフトが全て台無しにする

383 ：デフォルトの名無しさん：2013/05/27(月) 21:07:54.33

いままでC++のSystemCでどんなのを設計した？

384 ：デフォルトの名無しさん：2013/05/27(月) 21:14:46.78

メモリクリーナーとか田中式とか

385 ：デフォルトの名無しさん：2013/05/27(月) 23:35:01.10

>>362
ロジック部分などは好きな言語でHTTPしゃべるように作って、GUI部分をHTML5, Javascriptってのが今は無難かなぁ。

386 ：デフォルトの名無しさん：2013/05/28(火) 08:53:32.98

>>379
SystemCでLSI作ってる手抜き会社ってどこだ？
あれてまどもなLSIなんて出来ると思ってる方がどうかしてる
電電板でもHDL関連スレはあるけどSystemCなんか話題にも上ってないだろうが

>もう、C/C++な奴はハードからソフトまでこなせないようじゃ価値なしって感じなっているし
そんなのは昔から、

387 ：デフォルトの名無しさん：2013/05/28(火) 08:56:21.08

>>379
間違われやすいのでもひとつ言っとくと
Verilog上位互換のSystemVerilogは普通に使われてるから。
SystemCは既に終了

388 ：デフォルトの名無しさん：2013/05/28(火) 09:24:13.38

求人でVerilog やVHDLはいくらでもヒットするけどSystemCはほとんどないな

389 ：デフォルトの名無しさん：2013/05/28(火) 11:16:19.84

Intel Cofluent StudioでもSystemCが検証ベンチで使われてるよ。
SystemCで書くとC++によるシミュレータを記述してることになるんで。
OSSなんでいろいろな製品や研究でも使われてる。
まあマイナーだけど。

390 ：デフォルトの名無しさん：2013/05/28(火) 12:00:13.13

検証ベンチとHW設計なんて全くの別物だぜ

391 ：デフォルトの名無しさん：2013/05/28(火) 13:15:15.64

http://japan.xilinx.com/products/design-tools/vivado/integration/esl-design/index.htm
FPGAではSystemCは普通に使われている
VerilogやVHDLはハードドカタが使うものだし。当然求人多いよな
ソフトドカタでも学校で習っただろうから当然Verilog・VHDLは使えるだろ
俺でもVerilog/SystemVerilogはある程度使えるからな
SystemVerilogはDPI-CのおかげでC/C++との協調検証えらくしやすくなったからな

392 ：デフォルトの名無しさん：2013/05/28(火) 14:37:15.01

>>391
合成品質のレベルをわかって言ってるのか？
それで動くならなんでRTLレベルのHDLで書く必要があるんだい？
みーんなSystemCの合成ツールに任せれば済む話しだよなぁゲラゲラ
それとSystemCはFPGAよりむしろASICの機能検証で使われることぐらいしっとこうか

>俺でもVerilog/SystemVerilogはある程度使えるからな

これが全て。
お前みたいなカスが書いても金もらえるレベルになることが重要

393 ：デフォルトの名無しさん：2013/05/28(火) 14:55:14.93

局所的アルゴリズムはC/C++で開発する
その後
SystemCはシステムにおける挙動検証をするために用いられるが
結局、これだとハードウェア実体からは遠いので主流にはなり得ていない
というか今後もならない
間違いなくSystemCはSystemVerilogに取って代わられる

394 ：デフォルトの名無しさん：2013/05/28(火) 15:38:43.80

けどこのスレ的にはSystemC万歳。

395 ：デフォルトの名無しさん：2013/05/28(火) 15:59:22.07

電電板のVerilogスレの
http://uni.2ch.net/test/read.cgi/denki/1351913871/404
の回路記述、検証コードをSystemVerilog、SystemCならどう書くんだ？

396 ：デフォルトの名無しさん：2013/05/28(火) 19:37:55.73

俺もSystemCの絶滅した世界に行きたい。
ちなみにRTL用のテストベンチはC++で書けばいいのでSystemCみたいな
アホなものは要らん。

SystemVerilogは、C++がどんなに素晴らしいものだったか認識できるという
点でのみ意味がある。C++の後にどうやったらこんなものを作れたのか気が
しれない。

SystemVerilogはDPIがあるがVerilogにはPLI/VPI、VHDLにはVHPIがある。
超機能限定版がDPIで、その代わり簡単に書ける。

397 ：デフォルトの名無しさん：2013/05/28(火) 20:00:46.81

古い言語が割と生き残るのがプログラムの世界。既に入手困難な環境を使うのが普通「

398 ：デフォルトの名無しさん：2013/05/28(火) 21:53:16.33

>>396
>SystemVerilogは、C++がどんなに素晴らしいものだったか認識できるという
>点でのみ意味がある。C++の後にどうやったらこんなものを作れたのか気が
>しれない。

ハァ？
SystemCでRTLレベルで回路書いてミロ
書こうと思えばRTLで回路を記述できることにこそ意味がある

399 ：デフォルトの名無しさん：2013/05/28(火) 21:58:50.20

>>395
そのスレで聞いたら？なんでこっちにふってんの？

400 ：デフォルトの名無しさん：2013/05/28(火) 22:28:39.13

>>399
SystemVerilogはスレチガイだがSystemCはC++ってことで
このスレにはSystemC、SystemVerilogの猛者がいるし
SystemVerilogとSystemCの比較をしてみたい

401 ：デフォルトの名無しさん：2013/05/28(火) 22:45:30.57

C言語で文字列が面倒だが、分かりやすいと思ったな。
他の言語で文字列型変数ってどう扱っていいのか躊躇するようになった。

402 ：デフォルトの名無しさん：2013/05/28(火) 22:57:55.17

Cの文字列が分かりやすい？　正気か

403 ：デフォルトの名無しさん：2013/05/28(火) 23:24:06.34

文字操作関数覚えなくてもどーとでもできるのがシンプルだし
ハード的にわかりやすいとは思うな
BASICからC触ったときすごくシンプルで"コレ"だと思った
インタプリタでもないC#のstringとかもなにがしかの操作しようとすると新たにコピーされる仕様とか
今のメモリ事情だから許されるんだろと思うな

404 ：はちみつ餃子 ◆8X2XSCHEME ：2013/05/28(火) 23:52:11.45

ハードウェアの性能向上は理由のひとつにはあるだろうけど、最適化技術の向上もあなどれないと思うな。
「コピーされる仕様」とは言うが、事実はコピーされるかのように見えるってことだろ。
破壊的操作がされないことをフロー解析で看破できれば実際にはコピーしなくても見掛け上の動作は同じになる。

むしろ高級アセンブラでしかない C/C++ はコンパイラができることが少なくて本来なら最適化はしづらいタイプの言語だし。
異様にリソースが投入されてるから未だ動作速度では優勢だけど、原理的にはそれほど有利でもない。

405 ：デフォルトの名無しさん：2013/05/29(水) 01:00:22.77

コピーされるよ
そんな変な解釈変更するぐらいなら初めからstring不変をわざわざ言語仕様に盛り込まない
CやC++と同じ仕様にしとけばよかった。なんでわざわざ今のような仕様にしたんだwwww
それと
破壊操作されるんじゃなくガベコレ対象になる

最適化技術の向上てんなもんは信じてる方が馬鹿
コーディングの際人間が最大限配慮しなければならないのは20年前からなんらかわってない。
そんな魔法がまかり通るなら今頃言語翻訳もOCRも読み上げソフトもあのレベルのはずもなし

>原理的にはそれほど有利でもない。

いや原理的には速度上は圧倒的に有利だろ。
人間様が使いやすくするために配列の添え字チェックやってりゃ速くなるはずがない。

406 ：デフォルトの名無しさん：2013/05/29(水) 02:25:48.04

添字チェックしないコンパイルオプションのある高級言語もあるけど

行列演算をCでベタ書きした場合より速く計算してくれる高級言語なら割とあるよ
メモリの配置とかSIMDとかマルチスレッドとか勝手にやってくれるし
有能な人間がゴリゴリ最適化すりゃそりゃCの方が速いが、その労力のかけかたは明らかに無駄

407 ：デフォルトの名無しさん：2013/05/29(水) 02:40:26.50

別にC言語の規格でも配列の添え字チェックやって悪いってことはないはずなんだがね
それを売りにしたコンパイラもあったはず

C文字列はC文字列で各関数ではほぼ毎回strlen的な処理が走ってるので、不利な部類
効率だけならPascal文字列のほうがずっと速いし、
あらゆる文字列がstring_viewなD言語の文字列は至高

408 ：デフォルトの名無しさん：2013/05/29(水) 02:44:09.35

最近はようやくSSA最適化も普及してきた
コンパイラの最適化は相変わらず課題山積みって感じだが、
着実に進歩はしている

409 ：デフォルトの名無しさん：2013/05/29(水) 06:15:49.86

> C文字列はC文字列で各関数ではほぼ毎回strlen的な処理が走ってる

寝言は寝て言え

410 ：デフォルトの名無しさん：2013/05/29(水) 18:45:18.40

>>406
>メモリの配置とかSIMDとかマルチスレッドとか勝手にやってくれるし

その比較はアンフェアだろ
Cはシングル前提で
比較対象の言語はSIMDにマルチスレッドなんて比較は。言語比較じゃねーだろが

>有能な人間がゴリゴリ最適化すりゃそりゃCの方が速いが、その労力のかけかたは明らかに無駄

無駄じゃない。組み込みとか実際そーやってるんだから。

411 ：デフォルトの名無しさん：2013/05/29(水) 18:47:48.92

>>407
>別にC言語の規格でも配列の添え字チェックやって悪いってことはないはずなんだがね

計算負荷をかけず添え字チェックをどーやってやるのかアセンブラコードで説明してくれ
どんなコードを書けば添え字チェックが計算コストにならないか
そんな命令コード持ってるCPUを知りたい実に興味がある
馬鹿か？

412 ：デフォルトの名無しさん：2013/05/29(水) 19:10:22.03

>>410
費用対効果って知ってる？

413 ：デフォルトの名無しさん：2013/05/29(水) 19:30:11.81

>>412
他社との差別化て知ってる？

414 ：デフォルトの名無しさん：2013/05/29(水) 19:37:01.76

SIMD最適化くらいCコンパイラでもするだろう

415 ：デフォルトの名無しさん：2013/05/29(水) 19:44:28.76

>>414
お兄さん、ARMでSIMD/DSP命令最適化するコンパイラ教えてくれない？

416 ：デフォルトの名無しさん：2013/05/29(水) 20:20:46.25

最適化とは名ばかりで最適からは程遠いけどな

417 ：デフォルトの名無しさん：2013/05/29(水) 20:27:23.55

そんな汎用的な最適化アルゴリズム見つかったらノーベル賞やで

418 ：デフォルトの名無しさん：2013/05/29(水) 21:57:45.32

VLIWアーキテクチャだとある程度対応できるんだろうけど、
いかんせんマイナーアーキテクチャなんでC++とかないかな？

419 ：デフォルトの名無しさん：2013/05/29(水) 22:07:32.04

時々いるけど最適化を魔法の杖みたいに勘違いしてる人は
意味不明なこと言うよね。

420 ：デフォルトの名無しさん：2013/05/29(水) 22:07:38.73

C++は互換性気にしてるけど、
もう新規案件でしか使えなくてもいいから
機能を整理した規格を作って欲しい

421 ：デフォルトの名無しさん：2013/05/29(水) 22:09:22.49

Ｄでいいじゃん

422 ：デフォルトの名無しさん：2013/05/29(水) 22:12:26.06

DはGCが

423 ：デフォルトの名無しさん：2013/05/30(木) 00:42:54.47

かなり前からC++の最適化は優れたものになってるそうだな。

GUIになってからスケルトンそのものが環境によって違うから最初から互換性を考えて設計してない
限りC++でも移植は難しいな。

424 ：デフォルトの名無しさん：2013/05/30(木) 00:44:52.46

DCも便利かもしれんが、メモリリークを起こすなどPGの恥だぞ

425 ：デフォルトの名無しさん：2013/05/30(木) 00:45:50.52

×DC
○GC

426 ：デフォルトの名無しさん：2013/05/30(木) 00:52:10.70

>>411
たぶん「計算負荷をかけず」って話じゃないと思うんだ。

427 ：デフォルトの名無しさん：2013/05/30(木) 00:56:09.93

ABIをどうにかしてくれ

428 ：デフォルトの名無しさん：2013/05/30(木) 01:03:50.28

よし、もっと複雑にしてやる

429 ：デフォルトの名無しさん：2013/05/30(木) 01:19:04.73

>GCも便利かもしれんが、メモリリークを起こすなどPGの恥だぞ

組織での開発に於いてこういう
考えをしている奴が一番危険。

430 ：デフォルトの名無しさん：2013/05/30(木) 02:58:53.77

しょぼい組織にお勤めなようで

431 ：はちみつ餃子 ◆8X2XSCHEME ：2013/05/30(木) 03:52:23.25

GC は GC でちゃんとクセを把握して使わないと性能が出ないのは確かだけど、
そもそもほとんどのケースでそこまで性能が必要ないのも確かなわけで。

性能を出したい部分は C/C++ で書いて、全体をまとめるにはもうちょっと気楽な
グルー言語を使うってのが合理的選択じゃねーの。

最近の C++ はグルー言語やコードジェネレータでやればいい部分まで自前でやろうとしてるみたいで
ちょっとイケてない気がする。
今後は役割の分割していかないといいかげん巨大すぎる。
現在のプリプロセッサのイケてなさへの反省があるのかもしれんが、
あれはあのプリプロセッサが駄目なだけでしょ。

432 ：デフォルトの名無しさん：2013/05/30(木) 09:45:29.44

>GC は GC でちゃんとクセを把握して使わないと性能が出ないのは確か

このあいだ姉妹スレでc++のnewがGCに完敗して
「意味のない比較だ」とか言い訳してる奴いたよな

433 ：デフォルトの名無しさん：2013/05/30(木) 12:00:03.60

だからなんで malloc とガベコレを比較してるんだ
意味の無い比較と言ってるのはその通りだろ
馬鹿なのお前？

434 ：デフォルトの名無しさん：2013/05/30(木) 12:08:42.48

"Garbage Collection Can Be Faster Than Stack Allocation"
という古い論文があるな。

435 ：デフォルトの名無しさん：2013/05/30(木) 12:52:01.97

C/C++に都合の悪い比較は
意味のない比較とします

436 ：デフォルトの名無しさん：2013/05/30(木) 12:55:17.65

でもGCってどういうタイミングで実行されるか事前に把握出来ない事が多いんだよな

JavaとかC#で書かれたプログラムを走らせてみれば分かるけど、メモリギリギリ一杯まで
使いきってからようやくGCが実行される

タスクマネージャを見てると心臓に悪いぞ

437 ：デフォルトの名無しさん：2013/05/30(木) 13:18:46.35

そりゃなるべく回数を減らして一回のGCでたくさんのゴミを一掃する方が効率いいんだから仕方がない
でもOSや他のアプリにしてみれば無駄にメモリ圧迫されて迷惑だよな・・

438 ：デフォルトの名無しさん：2013/05/30(木) 13:25:27.56

むしろメモリがクソ安い時代にただのアプリごときに
Cの方がメモリ少ないからとメリットを作り上げ
ようとしているのが無様

439 ：デフォルトの名無しさん：2013/05/30(木) 13:30:59.70

都合のいい条件設定でマヌケ過ぎる比較して
中間言語が速度上も優位なんて結論を出そうと画策
してる方が異常

440 ：はちみつ餃子 ◆8X2XSCHEME ：2013/05/30(木) 13:36:03.50

>>436
メモリ使用量を節約する (使われてないメモリが余っている) という方針にした場合、
それはメモリが無駄になっているとも言える。
ギリギリまで使うのは意図的な方針だと思う。

GC にも特性の違うものが無数にあって、時には組合わせたりもするわけだけど、
いわゆるインクリメンタル化は体感的な速度上昇が見込める場合が多い。
それと言うのも一般的なプログラムは常に CPU を目一杯使うことはなくて大半は待機時間なので、
その待機時間の間に GC を発動すればメモリ回収のために使う時間は事実上のゼロになる。

C++ でもデストラクタで領域を登録だけして実際の開放は後回しっていうやり方である程度の緩和は
見込めるけど、普通の使い方ではデストラクタ発動のときに関連するオブジェクトのデストラクタが
連鎖的に動いてその間は本来的な動作が停止してしまうという問題が指摘されてる。

441 ：デフォルトの名無しさん：2013/05/30(木) 13:51:30.21

>>439
まだ言ってるのか。
単に「C/C++は動的メモリ確保が他言語より遅い」
が本当か比べただけだろ。
「そのうちアセンブラを追い越す」みたいな煽りは別として、
誰も全般で優位なんて言ってないし、落ち着けよカス。

442 ：デフォルトの名無しさん：2013/05/30(木) 13:57:13.45

C++の仕様にGCが入れば最強

443 ：はちみつ餃子 ◆8X2XSCHEME ：2013/05/30(木) 14:01:16.62

Boehm さんがかかわったりしてるし、いずれ入るんじゃね。

444 ：デフォルトの名無しさん：2013/05/30(木) 14:02:26.74

>>434
スタック割り当て？mallocと何も関係無いだろ

445 ：デフォルトの名無しさん：2013/05/30(木) 14:03:29.27

マイクロソフトのアレでいいや
ゼロオーバーヘッドさんも納得の仕様

446 ：デフォルトの名無しさん：2013/05/30(木) 14:08:14.17

>>436
今やそんなGCばかりではないよ。

447 ：デフォルトの名無しさん：2013/05/30(木) 14:09:03.25

>>443
GCのライブラリ実装がポータブルになるための最小限の仕様変更は既に入った。

448 ：はちみつ餃子 ◆8X2XSCHEME ：2013/05/30(木) 14:09:15.69

>>444
俺が英語わからんつっても、いくらなんでもこのくらいの英語は読めるぞ。
「ガベージコレクションはスタック割り当てより速くできる」で、
比較対象としてスタックを持ち出してるんだろ。関係あるよ。

449 ：デフォルトの名無しさん：2013/05/30(木) 14:11:20.15

ﾏﾛｰｸ/ニュー>>スターク>gcnew　ってことで

450 ：はちみつ餃子 ◆8X2XSCHEME ：2013/05/30(木) 16:17:26.29

比較に意味がないなんてことはねーよ。
絶対値でどちらかが速いということを示そうとするのは意味がないとは言えるけど。
要するに状況によって有利不利がある。

俺が >>440 で言ったような待機時間を活用する話は、
待機時間が無いような処理 (画像のエンコードとか、めいっぱい処理を詰め込む系) では意味がなくなるしな。
そういう場合はインクリメンタル化は無駄だからやめようってだけのこった。

速いか遅いかじゃなくて比較検討しようぜって話だ。

451 ：デフォルトの名無しさん：2013/05/30(木) 16:21:24.04

マインクラフトはJavaで書かれたゲームだけど全くGCが気になった事はないな
むしろ今のJavaはこれだけ高速で動くようになったのかとむしろ驚き

452 ：デフォルトの名無しさん：2013/05/30(木) 19:33:48.01

間違いない。C++を貶めるステマがいる

453 ：デフォルトの名無しさん：2013/05/30(木) 19:47:39.12

>>448
ヒープ割り当てるmallocとスタック割り当てに何の関係があるんだつってんだろが

454 ：デフォルトの名無しさん：2013/05/30(木) 19:50:40.81

>>443
>Boehm さんがかかわったりしてるし、いずれ入るんじゃね。
C#が勝手なGC抑制するためにどーしてるかわかってんのか？
そもそもGCは言語レベルの仕事じゃない

455 ：デフォルトの名無しさん：2013/05/30(木) 19:53:54.64

>>454
>GCは言語レベルの仕事じゃない
言語仕様に基づいて確保した領域の開放が
言語の仕事でないと？

456 ：はちみつ餃子 ◆8X2XSCHEME ：2013/05/30(木) 20:01:33.37

>>453
だから比較対象だっつってんだろうが。

457 ：デフォルトの名無しさん：2013/05/30(木) 23:25:37.09

Boehmは糞。
リフレクション機能が全く無い言語で
ガベージコレクションなんて無理に決まってるのに
なんちゃってガベコレを繕うという発想がバカ。

458 ：デフォルトの名無しさん：2013/05/31(金) 00:00:59.19

asyncを試してるのですが、ランタイムエラーになってしまいます。
何か間違っているのでしょうか？
ideone 側の問題かなー？

http://ideone.com/gYydfz

459 ：ＫＵＳＯＫＯＴＥ：2013/05/31(金) 00:21:09.86

>>458
GCCはおUNKOなので-lpthreadが必要です(たぶん)

460 ：デフォルトの名無しさん：2013/05/31(金) 00:31:25.73

>>458
質問の本質には関係ないと思うけど、ちょっとバグってたので修正。

http://ideone.com/TkZejo

>>459
そうなのですか…

コンパイルオプション設定できるのだろうか…

461 ：ＫＵＳＯＫＯＴＥ：2013/05/31(金) 00:48:46.73

>>460
ideoneのAPIリファレンスを見ても、
コンパイラーオプションを渡す
パラメーターは見あたらず。

http://ideone.com/brcYwy
join(waitやget)で落ちる模様…。

462 ：デフォルトの名無しさん：2013/05/31(金) 00:55:23.22

http://www.hpl.hp.com/personal/Hans_Boehm/
規格として関わってるのはメモリーモデルのような気がする。
でも、c++11で云々って書いてあるね。やっぱり標準ライブラリ外の話なんだろうが。

463 ：デフォルトの名無しさん：2013/05/31(金) 00:57:34.36

よしお前、
(650) 857-3406
に電話して訊け

464 ：デフォルトの名無しさん：2013/05/31(金) 01:00:37.64

>>457
応用対象に寄ります。

465 ：デフォルトの名無しさん：2013/05/31(金) 01:19:48.52

本来できるはずがないことを
動いたように見せかけるあたりが
中学生の工作レベル
使い捨てツールぐらいなら使えるかもな

466 ：デフォルトの名無しさん：2013/05/31(金) 01:38:12.41

単純化しないと物事を考えられない性能の低い脳みそなんですね

467 ：デフォルトの名無しさん：2013/05/31(金) 01:44:37.94

>>461
おお、追試ありがとうございます。

結局 ideone の thread 周りの不具合って事で FA かな。
しょうがないので、会社のVS2012で試すとするか…
自宅だとc++11環境が無いんだよね…

468 ：デフォルトの名無しさん：2013/05/31(金) 01:54:10.91

>>467
>ideone の thread 周りの不具合って事でFA
必要なリンクオプションが足りないのにノーエラーでリンクできてしまう糞ツール群を内部で使用したサービス、
という意味ではそうなんだろうけど
しっくりこない解釈だなおい。

469 ：デフォルトの名無しさん：2013/05/31(金) 02:02:06.68

>自宅だとc++11環境が無いんだよね
自宅のパソコンにVMwarePlayer入れて
ウブンコ入れてClangとG++入れなさい
家で毎日どうやってオナニーしてんのよ

470 ：デフォルトの名無しさん：2013/05/31(金) 02:11:56.21

>ウブンコ
何かとクソ談義のさかんなC++スレだが
そう来たか…

471 ：はちみつ餃子 ◆8X2XSCHEME ：2013/05/31(金) 02:38:02.49

X-Window を X-Windows とか言うようなもんじゃね。

472 ：デフォルトの名無しさん：2013/05/31(金) 08:04:05.33

全然ちがうんこ

473 ：デフォルトの名無しさん：2013/05/31(金) 10:39:08.09

debianで最小限インストールすればディスクイメージ小さくて済むよー。
たしかshとfileutilsくらいしかない。

474 ：デフォルトの名無しさん：2013/05/31(金) 18:40:23.34

475 ：デフォルトの名無しさん：2013/05/31(金) 18:40:44.34

1FDDブートできますかっ

476 ：デフォルトの名無しさん：2013/06/01(土) 22:31:54.50

1-475
ここまで糞コテの自作自演

477 ：デフォルトの名無しさん：2013/06/01(土) 22:38:44.89

1 floppy disk drive

478 ：デフォルトの名無しさん：2013/06/01(土) 22:41:08.44

floppyってなんですか？

479 ：デフォルトの名無しさん：2013/06/02(日) 01:49:30.18

パズルゲームの主人公

480 ：デフォルトの名無しさん：2013/06/02(日) 10:20:12.02

それはフラッピーだろ
不自由ソフトだ

481 ：デフォルトの名無しさん：2013/06/02(日) 10:21:33.08

フロッピーが現役なシステムも普通に存在する

482 ：はちみつ餃子 ◆8X2XSCHEME ：2013/06/02(日) 10:24:26.27

僻地の役所とかはそんなもんだとか聞いたことある。

483 ：デフォルトの名無しさん：2013/06/02(日) 10:28:09.29

金が無けりゃ昔のシステムをずっと使うしかないからな
MS-DOSも現役

484 ：デフォルトの名無しさん：2013/06/02(日) 11:00:45.80

江添さんﾁｰｯｽ

485 ：デフォルトの名無しさん：2013/06/02(日) 11:57:05.82

さすがにconfig.sysの書き方とかもう忘れた
戻れないわ

486 ：デフォルトの名無しさん：2013/06/02(日) 12:20:14.02

c++1yの話題が乏しいな
適当に出したc++11の見直しみたいな
ものになるん？
ヘッダー名が<cstding>みたいな誤記とか
レビューしてんのかよってかんじ
だったからな

487 ：デフォルトの名無しさん：2013/06/02(日) 12:45:42.07

仕様追加があるらしい
今以上にC++11本が出なくなるじゃねえか

488 ：デフォルトの名無しさん：2013/06/02(日) 12:52:31.94

誤記があっても正誤表は出さない
それがWG21クォリティー

489 ：デフォルトの名無しさん：2013/06/02(日) 13:01:15.48

コンセプトさんは期待してよかですか？

490 ：デフォルトの名無しさん：2013/06/02(日) 16:47:28.46

コンセプト？何ソレ？

491 ：デフォルトの名無しさん：2013/06/02(日) 22:54:04.55

これから日本で実現する政策

TPP参加
解雇規制緩和
限定正社員の導入
派遣労働の拡大、派遣対象の業種を全面解禁
ホワイトカラーエグゼンプション(残業代０)
セーフティネット削減(失業保険の受給期間を短期間、生活保護受給厳格化、親族の扶養強化)
混合診療解禁(国保適用外の拡大)
留学生30万人受け入れ
グローバル企業の英語公用語化
貸金業法の改正(総量規制廃止、グレーゾーン合法化、金利引き上げ)

492 ：デフォルトの名無しさん：2013/06/03(月) 09:36:55.78

>>487
言語って旬の時期があってc++はもうその時期を過ぎた
今後仕様追加されてもそれをキャッチアップするやつどの程度いるのかな？
FortranやCが新スペック追いかけてる奴なんてもうほとんど居ないのと同じでさ

493 ：デフォルトの名無しさん：2013/06/03(月) 11:22:18.09

FORTRANやCの新スペックは当時でも斬新なものは全くない。
FORTRAN実装の独自仕様なら90年代でも斬新なものが幾つもあったが。
C++の新規格は先鋭的すぎるところが面白い。
新機能の多くを使わない人が多いのはどの言語でも一緒だし。
templateなんか誰も使わないとか、害しかないとか当時は言われた。

494 ：デフォルトの名無しさん：2013/06/03(月) 13:00:28.00

そのC++の新スペックより既にもっと上を行くのがC#なわけ
WinアプリではC++の必要とされるほとんどの部分はC#で既に十分

495 ：はちみつ餃子 ◆8X2XSCHEME ：2013/06/03(月) 13:10:34.22

いつの間にWinアプリの話になってんの?

496 ：デフォルトの名無しさん：2013/06/03(月) 14:52:28.68

C++ の新機能は「待望」のものが多いのが、C のそれとの大きな違い・・・というか真逆といってもよい

満点はやれないけどね
ゼロオーバーヘッド厳守の仕様を渇望していただけに

497 ：デフォルトの名無しさん：2013/06/03(月) 14:59:05.83

なんか違反してるのあったか？

498 ：デフォルトの名無しさん：2013/06/03(月) 14:59:42.53

Winアプリ作ってるけどC#じゃ無理

499 ：デフォルトの名無しさん：2013/06/03(月) 18:23:52.40

>>497
例えば noexcept をデフォにするとかね
既存コード保護の観点から難しいのはわかるんだけど

500 ：デフォルトの名無しさん：2013/06/03(月) 18:30:22.02

それはC++11で起きた問題じゃないと思うが。

501 ：デフォルトの名無しさん：2013/06/03(月) 18:40:02.10

new が NULL を返さなくなった日の狼狽は何だったんだろう...
メジャーチェンジってそういうもんだと期待してたんだけど

502 ：デフォルトの名無しさん：2013/06/03(月) 19:04:12.78

noexceptデフォとか死ねる
そんな言語他にあるか？

503 ：デフォルトの名無しさん：2013/06/03(月) 19:27:55.66

他になくていい　・・・って女かC++はｗ

504 ：デフォルトの名無しさん：2013/06/03(月) 19:37:16.67

デフォルトにするといえばポインタ引数に noknot みたいなもん宣言出来ればいいな
メンバや他の引数に実体を結びつけず気兼ね無くスコープ消滅と同時にdelete出来たりコンパイル時警告を出してくれる様な

505 ：デフォルトの名無しさん：2013/06/03(月) 19:42:42.51

>>502
Java？
超不評だけど

506 ：デフォルトの名無しさん：2013/06/03(月) 20:29:37.53

>>501
new するまえに変数が NULL で初期化されてれば良いんじゃね？

507 ：デフォルトの名無しさん：2013/06/03(月) 20:48:20.08

>>501
exportが無くなってComeauがビックリしました

508 ：デフォルトの名無しさん：2013/06/03(月) 20:54:50.70

C++と違ってCは2011年に改訂されたことすら
世間では知られていない
C++はまだマシな状況

509 ：デフォルトの名無しさん：2013/06/03(月) 21:06:18.60

Cを改訂する意味ってあるの？

510 ：デフォルトの名無しさん：2013/06/03(月) 21:06:23.19

>>501
別にそれはオーバーロードで置き換えられるし
そもそも規格化される前の話だしな

511 ：デフォルトの名無しさん：2013/06/04(火) 00:52:46.30

>>499
「noexcept がデフォ」が何のこと言ってるのかよくわからない。
それがゼロオーバーヘッドの原則とどう関係するのかもよくわからない。
もうちょっと詳しく。

512 ：デフォルトの名無しさん：2013/06/04(火) 02:24:49.60

atomicの辺りのデフォルトがゼロオーバーヘッドではないとか
聞いたことがある気がする

513 ：デフォルトの名無しさん：2013/06/04(火) 02:25:19.88

void foo() except(true) {...}
みたいな感じで例外を投げる可能性のある方を指定できるようにして、
投げないのをデフォに、って主張じゃない？

例外は組み込み系なんかだとサイズ(や速度)の点で好まれないこともあるんだが、
try, catch, throw使わないでも例外のために挿入されるコードというのもあるので。

514 ：デフォルトの名無しさん：2013/06/04(火) 02:52:08.33

http://mimizun.com/log/2ch/tech/1349356417/277-

515 ：デフォルトの名無しさん：2013/06/04(火) 03:04:54.60

>>513
そんな要求はコンパイルオプションで例外無効にしろってことでずっと昔から
答えが決まってるんだから、規格の改定で考慮する必要ないだろ。

516 ：デフォルトの名無しさん：2013/06/04(火) 06:41:04.32

例外指定付けるか付けないかでコードが変わるなんて事情、規格が知るかよ

517 ：デフォルトの名無しさん：2013/06/04(火) 08:20:11.21

実装を全く考慮しないということは無いだろうけど、今はメジャーになった
テーブルアプローチによる例外実装であれば多くのプログラムでたいした
違いにならないとは言えそうな気がする。

あ、例外を使うこと自体は前提での「違い」のことね。それ自体（例外実装
コードのリンクだけ）で領域があふれるようなら>>515

518 ：デフォルトの名無しさん：2013/06/04(火) 20:29:31.18

ゼロオーバーヘッドキーック！！

519 ：デフォルトの名無しさん：2013/06/05(水) 14:58:19.59

株全部売っといてよかったわ

520 ：デフォルトの名無しさん：2013/06/05(水) 21:18:01.05

[[noreturn]]付けるか付けないかでコードが変わるなんて事情、規格が知るかよ

521 ：デフォルトの名無しさん：2013/06/05(水) 21:31:48.26

↑馬鹿

522 ：デフォルトの名無しさん：2013/06/05(水) 21:34:10.40

>>496
>ゼロオーバーヘッド厳守の仕様を渇望
これは>>325-326みたいな人が安心できる機能
ということですね

523 ：デフォルトの名無しさん：2013/06/07(金) 02:04:52.67

アベノミクスはまやかし

524 ：デフォルトの名無しさん：2013/06/19(水) 16:23:40.36

gist.github.com/anonymous/5812246
これclangとg++で結果違うんだけどclangのバグかな

525 ：デフォルトの名無しさん：2013/06/19(水) 21:28:57.67

ちょうどllvm3.3がリリースされたからそれでも確認してみれば
bug database見るとエイリアステンプレートでのパラメータパックに対する
sizeof...に不具合があるような報告もあるけどよくわからん

526 ：デフォルトの名無しさん：2013/06/20(木) 00:02:26.78

>>524
template <class... Types> struct test<Derived<Types...>> : public std::true_type {};

何かへんじゃね
Derivedはテンプレートだからtestは
template<template<…>…>
で始まらないといけないんじゃね？

527 ：デフォルトの名無しさん：2013/06/22(土) 21:01:51.67

clangの実装ペース半端ないな。もうC++11終わったのか

528 ：デフォルトの名無しさん：2013/06/22(土) 21:32:00.51

目指すはC++14

529 ：デフォルトの名無しさん：2013/06/23(日) 00:59:22.69

>>527
最強C++コンパイラのVCなんてVC2012でC++11はサポート済みだろ？

530 ：デフォルトの名無しさん：2013/06/23(日) 01:16:23.74

サポート済み（全ての機能を実装したとは言ってない）

531 ：デフォルトの名無しさん：2013/06/23(日) 12:43:05.88

>>529
いいえ、Visual C++はC++規格第3版の仕様を
サポートしていません

532 ：デフォルトの名無しさん：2013/06/23(日) 12:59:23.69

今月26日に公開予定のVS2013プレビュー版なら、きっとC++11をフルサポートしてるはず！
フルサポートしてなかったら俺はMSを見捨てるぞジョジョ！

533 ：デフォルトの名無しさん：2013/06/23(日) 16:30:13.26

コンパイラ製作者が手に負えない仕様って…

534 ：デフォルトの名無しさん：2013/06/23(日) 16:33:52.42

その名もexpoort!さん

535 ：デフォルトの名無しさん：2013/06/23(日) 17:19:52.43

>>532
http://blogs.msdn.com/b/somasegar/archive/2013/06/03/teched-2013.aspx
12 Jun 2013 10:19
>Most folks on the VS team use Visual Studio including those who use C++11. When we released the C++11 CTP, there was no IDE support (e.g. intelisense) for some of the C++11 features but we have added such support in this release

C++11CTPがVisual Studioに統合された以上のことは期待するなってことだと理解した

536 ：デフォルトの名無しさん：2013/06/23(日) 21:02:33.67

>>533
Variadicテンプレートは結構死ねると思う。
・C(forward<Args>(args)...)
　→C(forward<A>(a), forward<B>(b))
・template<typename...T>void f(T(*...t)());
　→void f(A (*)(), B(*)())
・struct X:Mixins...{X(Mixins&... mixins):Mixins(mixins)...{}
　→struct X:A,B{X(A&a, B&b):A(a),B(b){}

コンパイラはよく頑張るよまったく。

537 ：デフォルトの名無しさん：2013/06/23(日) 21:52:40.03

>>534
Comeauというコンパイラーがあってだな。

538 ：デフォルトの名無しさん：2013/06/23(日) 22:03:05.15

ゼロオーバーヘッドだから関係ないね
既存のコードがそのまま動くのこと重要

539 ：デフォルトの名無しさん：2013/06/23(日) 22:23:39.34

日本語でお書きくだしあ

540 ：デフォルトの名無しさん：2013/06/24(月) 20:02:00.11

ここC++11以後スレだけど、そこにたむろしているお前らって
コンパイラー何を使ってるんだよ？　C++11をたいしてサポートしていないVC2012?
俺はそうなんだけど

541 ：はちみつ餃子 ◆8X2XSCHEME ：2013/06/24(月) 20:09:49.16

clang だろ。常識的に考えて。

542 ：デフォルトの名無しさん：2013/06/24(月) 20:11:39.36

clangはインスコの仕方がわからんかった

543 ：デフォルトの名無しさん：2013/06/24(月) 20:22:42.22

>>541
Clangが良いと分かっていても、さくっとWinにインスコできないからVC2012なんだよ

544 ：デフォルトの名無しさん：2013/06/24(月) 20:23:50.26

sudo apt-get install clang

545 ：デフォルトの名無しさん：2013/06/24(月) 20:31:01.85

VC++2012で十分じゃん！
autoやrange based forなんかもう神だね！

546 ：542：2013/06/24(月) 20:31:16.96

＞544
そこまではやったけど
コンパイルしたら壮大なリンクエラーが出て
めんどくさくなった

547 ：デフォルトの名無しさん：2013/06/24(月) 20:42:55.97

windowsで不完全なコンパイラを買う金でmacが買える

548 ：デフォルトの名無しさん：2013/06/24(月) 20:55:13.37

>>547
買う？

いや、買ってもいいけどさ。

549 ：デフォルトの名無しさん：2013/06/24(月) 21:11:17.38

MS的にVSはIDEでC#、VBがメイン用途でVCはおまけって感じだからね
おまけには力なんてたいして入れないだろうし

550 ：デフォルトの名無しさん：2013/06/24(月) 21:39:42.22

>>541
QZのくせに生意気な

551 ：デフォルトの名無しさん：2013/06/24(月) 23:03:53.28

ギガクラスのCPUでもJavaや.Netは一拍置いてから動作する。まあVC++のデバッガも
ステップ実行がやけに遅くなったが…
瞬間的に動作しないアプリで満足できる奴が分からん

552 ：デフォルトの名無しさん：2013/06/24(月) 23:31:56.10

>>540
そもそもWindows使ってない。

553 ：デフォルトの名無しさん：2013/06/24(月) 23:40:40.56

そんなことは誰も聞いていない

554 ：はちみつ餃子 ◆8X2XSCHEME ：2013/06/24(月) 23:44:48.41

>>550
QZ と混同するのはやめてくれ。
俺は Scheme スレ出身だぞ。

555 ：デフォルトの名無しさん：2013/06/25(火) 04:41:21.88

なんであなたここ来てるの？

556 ：はちみつ餃子 ◆8X2XSCHEME ：2013/06/25(火) 08:03:41.81

Scheme スレが過疎ってて暇だから。

557 ：デフォルトの名無しさん：2013/06/25(火) 08:17:42.10

ふむふむ
Qzはschemeかぶれと

558 ：デフォルトの名無しさん：2013/06/25(火) 21:26:48.03

じゃあモリタポスレに来なよ糞ース豊漁突っ込みどころ満載だ

559 ：デフォルトの名無しさん：2013/06/26(水) 00:19:57.53

VS2013でVCが最強のC++11/C++14サポートコンパイラになるらしいな
さすがMS

560 ：デフォルトの名無しさん：2013/06/26(水) 00:33:15.10

すげー！！

561 ：デフォルトの名無しさん：2013/06/26(水) 07:13:28.79

>>559
ソースは？

562 ：デフォルトの名無しさん：2013/06/27(木) 21:05:55.58

>>559
Visual C++2013で対応されなかったもの
　=default,=delete
　noexcept
　constexpr
　inline namespace
　メムバー関数に &
　[[属性]]
その他多数。
つまりマイクロソフトはUNKO

563 ：デフォルトの名無しさん：2013/06/27(木) 21:10:15.99

メムバー関数ってなんですか？

564 ：デフォルトの名無しさん：2013/06/27(木) 21:12:22.59

>>563
struct kuso_vs {
　void fuck() & {}　←これ
};

565 ：デフォルトの名無しさん：2013/06/27(木) 21:19:11.89

そこにアンドってどういう意味？

566 ：デフォルトの名無しさん：2013/06/27(木) 21:24:04.75

>>565 右辺値と左辺値がオーバーロードできる
struct kuso_vs {
　void fuck() & {}
　void fuck() && {}
};

void f() {
　func_returns_kuso().fuck();

　kuso_vs unko;
　unko.fuck();
}

567 ：デフォルトの名無しさん：2013/06/27(木) 21:25:56.35

きたねえ幼稚なコード書いてんじゃねえよ

568 ：デフォルトの名無しさん：2013/06/27(木) 22:27:36.56

>>566
C++は好きだけどこの先どこに行くんだろうって思う
そりゃjavaはconstをなくすわけだ

569 ：デフォルトの名無しさん：2013/06/27(木) 23:05:53.70

こんなスレ覗いてる奴が言っても説得力ないw
自分がどこに行ってもいいのに、ここにいるくせに

570 ：デフォルトの名無しさん：2013/06/28(金) 08:45:53.63

老害ジジイは新しいことを覚えられないので
何十年も同じものにしがみつくしかないのです

571 ：デフォルトの名無しさん：2013/06/28(金) 11:55:40.49

AdobeのCrossBridgeがClangベースになるって。
http://blogs.adobe.com/digitalmedia/2013/06/open-source-flash-c-compiler-crossbridge/
FlashがターゲットのC/C++コンパイラ。

572 ：デフォルトの名無しさん：2013/06/28(金) 13:40:19.59

>>568
constこそJavaやC#に比べたC++の良いところだと思うが？
特に引数にconst指定できないのは危険極まりないと思う。

573 ：デフォルトの名無しさん：2013/06/28(金) 16:05:39.92

Javaはintとかの組み込み型でも関数の引数に参照渡しできないのがね・・・
C#はref明示で使えるが、これが紛らわしさも解消して一番いいと思う

574 ：デフォルトの名無しさん：2013/06/28(金) 18:09:36.50

Integerにboxingすればできるだろ

575 ：デフォルトの名無しさん：2013/06/28(金) 19:25:49.46

えっ？

576 ：デフォルトの名無しさん：2013/06/28(金) 21:34:27.79

「え」とか「は」とだけのレスは無意味だからやめとけ

java.lang.Integerはimmutable

577 ：デフォルトの名無しさん：2013/06/29(土) 04:38:45.82

Bulid2013見てたら
RTMとその後のCTPでいろいろ実装する予定らしいね

578 ：デフォルトの名無しさん：2013/06/29(土) 05:51:46.36

そこでリリースバージョンという概念にとらわれない
アプリケーションライフサイクルマネージメント
というわけですね

579 ：ＫＵＳＯＫＯＴＥ：2013/06/29(土) 07:36:57.93

>>577
ソース貼った方がいいぞよ。
http://blogs.msdn.com/b/somasegar/archive/2013/06/28/cpp-conformance-roadmap.aspx

それでもconstexprは2013に入らず。。

580 ：ＫＵＳＯＫＯＴＥ：2013/06/29(土) 07:39:01.43

ああ、現地で聞いたのか。すまぬ。

581 ：デフォルトの名無しさん：2013/06/29(土) 09:45:22.93

ハーブサッターってMSの人だったのか
今さらながら知った

582 ：デフォルトの名無しさん：2013/06/29(土) 12:48:36.78

LINQをC++11に提案してたじゃない。

583 ：デフォルトの名無しさん：2013/06/29(土) 12:50:11.62

LINQはC++11に入ってもいいと思う
C#で使いまくってるけど本当便利
STLでも同じ事ができるけど、それをさらに分解した感じがするのと、
遅延評価という点と、INTO句で更に絞り込みを掛けれるしな

584 ：デフォルトの名無しさん：2013/06/29(土) 13:16:43.35

GCの無い言語との親和性はどんなものだろう

あとLINQは横糸の技術で理解されにくい

585 ：デフォルトの名無しさん：2013/06/29(土) 13:29:09.74

いい香りがしそうなお名前ですね

586 ：デフォルトの名無しさん：2013/06/29(土) 14:27:01.71

LINQ をゼロオーバヘッドで実装できたらすごいな

587 ：デフォルトの名無しさん：2013/06/29(土) 14:30:38.20

お前、ゼロオーバーヘッドの意味わかってないだろ

588 ：デフォルトの名無しさん：2013/06/29(土) 14:48:53.56

絶対そういわれると思った
真意は、LINQ を使う箇所はそれ相応のコストを覚悟する
しかし、それ以外の部分の実行に余分なコストがかかっては嫌だと言うこと
例えば、LINQ を使うためには、全てにおいて GC 必須とかね

589 ：デフォルトの名無しさん：2013/06/29(土) 15:01:17.34

>>588
LINQを使ったC#をVC++から呼び出せば
ゼロオーバーヘッドだぜ

590 ：デフォルトの名無しさん：2013/06/29(土) 15:05:21.47

>>589
そ、それで C++ LINQ サポートて言えるのか？

591 ：デフォルトの名無しさん：2013/06/29(土) 15:20:43.43

P/Invokeの逆版か

592 ：デフォルトの名無しさん：2013/06/29(土) 17:11:21.58

でもC++11はC#に比べてラムダがめんどくさい作りなのでLINQに対応しても
C#ほどには楽にはならなそう。

C#の場合
var ret = list.Where(x => x.a == 1).Select(x => new { x.a, x.b });
C++11の場合
auto ret = list.Where([](data& x){ return x.a == 1; }).Select([](data& x){ return tuple<int, string>(x.a , x.b); });

593 ：デフォルトの名無しさん：2013/06/29(土) 17:56:18.13

C#ってコンパイラが賢いのになんであんなにコンパイル速いん？

594 ：デフォルトの名無しさん：2013/06/29(土) 18:41:31.89

実行速度が遅きゃ何にもならん

595 ：デフォルトの名無しさん：2013/06/29(土) 18:48:17.37

ヒント：VM
賢い機能はVMに丸投げ、実はVMが頑張ってる

596 ：デフォルトの名無しさん：2013/06/29(土) 19:12:15.97

禿「LINQはテンプレートライブラリで実装して提案してね」
と終了

597 ：デフォルトの名無しさん：2013/06/29(土) 19:39:16.76

>>592
それってLINQじゃなくね？

598 ：デフォルトの名無しさん：2013/06/29(土) 19:55:39.93

ヘジたんはコンパイルが高速な事にMSに移ってもこだわってるわけか

おっとスレ違いになるな

>>597
クエリメソッドとラムダ式を使っているだけでLINQの一種

599 ：デフォルトの名無しさん：2013/06/30(日) 00:58:13.99

>>592
なにそのC++11のコード。　つまり使うなってことか

600 ：デフォルトの名無しさん：2013/06/30(日) 01:17:37.62

>>599
>>522はLINQでも何でもねーよ
>>522をシンタックスシュガーで読みやすくしたのがLINQ

601 ：デフォルトの名無しさん：2013/06/30(日) 01:30:01.52

シンタックスシュガーという言葉が万能薬だと思うなよ
コンパイラが内部で変換してくれているんだ
ありがたく思え

602 ：デフォルトの名無しさん：2013/06/30(日) 01:32:26.75

クエリ式だけをLINQだと勘違いしてる奴は結構いるんだな
スレチだからこのくらいにしとくけど

603 ：デフォルトの名無しさん：2013/06/30(日) 01:39:04.87

クエリ式をLINQじゃないと勘違いしている奴は結構いるんだな

604 ：デフォルトの名無しさん：2013/06/30(日) 01:44:25.56

そんなことより、>>600のアンカー間違うなよ

605 ：デフォルトの名無しさん：2013/06/30(日) 10:56:25.30

クエリ式のLINQしか知らない奴が >>592 にそれはLINQじゃなくね？といったら、
メソッド形式のLINQがあることを指摘されて、激おこぷんぷん丸になっちゃたのか。

コンパイラ作るのが一番難しいと言われているC++にクエリ式を導入するのは
難しいんじゃないかな。
メソッド形式ならyieldを言語機能に追加する以外はライブラリでなんとかなりそう。
ラムダはC++14で若干楽になるようだけど、C#並に簡単にならないとLINQで
使いこなせる人はかなり限られてしまうのでは。

606 ：デフォルトの名無しさん：2013/06/30(日) 11:10:55.53

yield return がないとシステムコールなしではコルーチンが作れないし不便だよなあ

607 ：デフォルトの名無しさん：2013/06/30(日) 11:11:47.58

>メソッド形式のLINQ
それはLanguage Integrated Queryを実現
するために必用なメソッド群であって
Language Integrated Queryではない

608 ：デフォルトの名無しさん：2013/06/30(日) 11:36:40.38

>>607
もう見苦しいからやめなよ(´・ω・｀)

609 ：デフォルトの名無しさん：2013/06/30(日) 12:07:54.07

C#スレで仕様書つき合わせてやれ

610 ：デフォルトの名無しさん：2013/06/30(日) 12:27:26.93

ところで、C++14の目玉機能を
俺に10行以内で教えてくれ。

611 ：デフォルトの名無しさん：2013/06/30(日) 12:35:22.46

ラムダが完成した

612 ：デフォルトの名無しさん：2013/06/30(日) 14:51:32.54

軽量版concept

613 ：デフォルトの名無しさん：2013/06/30(日) 16:57:59.67

>>612
そんなのあったっけ？

614 ：はちみつ餃子 ◆8X2XSCHEME ：2013/06/30(日) 18:11:18.92

>>613
constexpr との融合でなんちゃらっていう話じゃなかったっけ？
http://cpplover.blogspot.jp/2013/02/concept.html

615 ：デフォルトの名無しさん：2013/06/30(日) 19:07:25.06

>>614
先日の委員会ドラフトに見あたらないのだが…

616 ：デフォルトの名無しさん：2013/06/30(日) 20:14:21.25

小粒だが言語仕様自体への変更はどれも目玉だろ
・lambda式の初期化キャプチャ
・ジェネリックlambda式
・constexpr関数の制限緩和
・実行時要素数指定配列
・関数の返却値型推論

617 ：デフォルトの名無しさん：2013/06/30(日) 21:50:19.99

軽量版って使い物にならいおまけってことか

618 ：デフォルトの名無しさん：2013/06/30(日) 21:58:59.65

>>616
最後の2つはすごい変更だな。

619 ：デフォルトの名無しさん：2013/06/30(日) 22:00:27.46

実行時要素数指定配列ってdynarrayクラスじゃなくて
C99みたいな奴？

620 ：デフォルトの名無しさん：2013/06/30(日) 22:36:17.68

構造化アセンブラなだけだと言われたC言語が複雑怪奇もいいところになってきたな
これでネイテブなんだから凄い

621 ：デフォルトの名無しさん：2013/06/30(日) 22:37:24.72

iostreamとかSTLの部分のコードを見ると失神しそうになる

622 ：デフォルトの名無しさん：2013/06/30(日) 22:37:51.20

もちろん、ゼロオーバーヘッドキィーック！！

623 ：デフォルトの名無しさん：2013/06/30(日) 22:46:11.74

boostのVC++対策のifdef部分読むと頭が禿げる

624 ：デフォルトの名無しさん：2013/06/30(日) 23:42:29.25

int (*a)[x]=new int(*)[y][x]; みたいな？

625 ：デフォルトの名無しさん：2013/07/01(月) 01:08:21.50

スレタイ見てC++18まで来たのかと思ってしまった。

626 ：デフォルトの名無しさん：2013/07/01(月) 07:16:36.37

それはそれで、おもろいな

627 ：デフォルトの名無しさん：2013/07/01(月) 12:05:20.09

C++17の作業中だしC++18になる可能性は十分ある

628 ：デフォルトの名無しさん：2013/07/01(月) 21:17:33.69

そろそろ新しいiostreamを考えてもいいんじゃないかと

629 ：デフォルトの名無しさん：2013/07/01(月) 21:18:16.19

iostreamみたいな糞はもう要らん

630 ：デフォルトの名無しさん：2013/07/01(月) 21:18:57.03

うむ、そろそろメジャーチェンジきぼんぬだね

631 ：デフォルトの名無しさん：2013/07/01(月) 21:19:57.64

iostreamを使ってる奴は情弱確定

632 ：デフォルトの名無しさん：2013/07/01(月) 23:43:53.87

auto z = composable_functor(a) >> b >> c >> d;
std::cout << a << std::endl;
みたいなライブラリ書いて使ってる俺冷や汗の流れ。
演算子をオーバーロードして別の用途で使うのはやっぱ醜いッスか？

633 ：デフォルトの名無しさん：2013/07/01(月) 23:48:58.08

CUI？

634 ：デフォルトの名無しさん：2013/07/02(火) 00:16:45.25

GUIのことグイって人いるけど、
CUIはキュイ？
ギニュー特戦隊みたいだｗ

635 ：デフォルトの名無しさん：2013/07/02(火) 00:30:15.64

iomanip さんが使えない子なので iostream さんも要らない子

636 ：デフォルトの名無しさん：2013/07/02(火) 01:42:59.14

>>634
CUIというのは、ないらしい（日本人には、通じるが、アメリカ人には、通じないかもしれない）

637 ：デフォルトの名無しさん：2013/07/02(火) 01:46:53.16

ＣＬＩ（Command Line Interface）とかＴｅｘｔＵＩ

638 ：デフォルトの名無しさん：2013/07/02(火) 01:58:21.19

TUIは罫線使ったり色変えたりしてGUIの一種じゃね？ってイメージ

639 ：デフォルトの名無しさん：2013/07/02(火) 02:04:48.49

コマンドラインがゆるされるのはテレタイプまでよね

640 ：デフォルトの名無しさん：2013/07/02(火) 19:20:05.14

>>636
ホントか？
C:\>dumpbin.exe /headers test.exe
Microsoft (R) COFF/PE Dumper Version 11.00.60315.1
OPTIONAL HEADER VALUES
3 subsystem (Windows CUI)

この「CUI」の表示は少なくとも
Windows 3.1の時から見かけるのだが

641 ：はちみつ餃子 ◆8X2XSCHEME ：2013/07/02(火) 19:28:17.14

Subsystem を表す定数として WINDOWS_CUI というのが公式に定義されてるな。

http://msdn.microsoft.com/en-us/library/ms809762.aspx

642 ：デフォルトの名無しさん：2013/07/02(火) 21:54:30.55

くいっくいっ

643 ：デフォルトの名無しさん：2013/07/02(火) 21:55:37.94

はい。次の方。

644 ：デフォルトの名無しさん：2013/07/02(火) 21:57:45.45

悔いの無い人生を送りたいのですが

645 ：デフォルトの名無しさん：2013/07/02(火) 22:03:47.26

んー、次っ！

646 ：デフォルトの名無しさん：2013/07/02(火) 22:14:03.65

>>644
だったらC++の最新規格をリアルタイムに追いかけるようなことはしない方がいい。
どうせ実務では使わせてもらえないんだから、無駄にストレスが溜まるだけｗ

647 ：デフォルトの名無しさん：2013/07/02(火) 22:17:38.74

でも、CUIの無い人生をなんて考えられません

648 ：デフォルトの名無しさん：2013/07/02(火) 22:17:47.34

総理、ここは突っ込んだら負けですぞ…

649 ：デフォルトの名無しさん：2013/07/02(火) 22:18:24.72

>>647 へんたいよくできました

650 ：デフォルトの名無しさん：2013/07/02(火) 22:30:44.46

たいへんよできました

651 ：デフォルトの名無しさん：2013/07/02(火) 22:34:39.34

うまかっ　です。

652 ：デフォルトの名無しさん：2013/07/02(火) 23:42:36.76

ﾜﾛﾀｗ

653 ：デフォルトの名無しさん：2013/07/02(火) 23:46:13.86

今日も平和だ風邪ひいた

654 ：デフォルトの名無しさん：2013/07/02(火) 23:47:46.30

CUNッ、があったらナッパできるのになぁｗ

655 ：はちみつ餃子 ◆8X2XSCHEME ：2013/07/02(火) 23:55:04.86

ここまでイルククゥの話題なし

656 ：デフォルトの名無しさん：2013/07/03(水) 18:49:39.95

C/C++が進歩して色々便利にはなったが、これ以上複雑化しても意味あるんだろうか？
ネイテブで専門アプリが要求されない限り選択肢はC++しか無くなってきたがC++自体が
まるでスクリプト言語の仕様を全部飲み込んだような物になっても保守が大変になる。
仕事で新規のが少ないんだし

657 ：デフォルトの名無しさん：2013/07/03(水) 19:47:20.40

そもそも複雑化してるかな？
autoとか戻り値の型推論で煩わしい部分を簡略化してて寧ろ楽になっていってる。
constexprもC++14が実装されれば普通に書けるようになるし？

俺としてはテンプレート＋プリプロセッサなコンパイル時スクリプトが欲しい。
テンプレートの展開を転用してロジック書こうとするから黒魔術になる。
いっそ定数と型を扱うコンパイル時スクリプトを実装した方が絶対便利だと思う。

658 ：デフォルトの名無しさん：2013/07/03(水) 20:07:06.33

あれだな
コーディングは楽になったな
保守はやりにくくなったかもしれん

659 ：デフォルトの名無しさん：2013/07/03(水) 20:50:18.33

shared_ptrやautoは革命。
その他STLも素晴らしいよ。

660 ：デフォルトの名無しさん：2013/07/03(水) 21:07:35.22

STLとは何ぞや？
1.iostreamはSTLですか？
2.stringはSTLですか？
3.auto_ptrはSTLですか？
4.regexはSTLですか？

661 ：デフォルトの名無しさん：2013/07/03(水) 21:08:31.80

言語仕様の全容を把握できるか自信がなくなってきた
C++11の巨大さは、AdaとかCommon Lispもびっくりな気がする

662 ：デフォルトの名無しさん：2013/07/03(水) 21:37:24.21

>>656,658
「保守」ってのがどういう仕事を想定しているのかわからない。
C++11 以降の改定によって大変になることの具体的な例があったりする？

663 ：デフォルトの名無しさん：2013/07/03(水) 21:57:00.33

>>662
保守ってのは拡張・デバッグ・他製品との統一ってのも知らんのか？
新規ソフトは会社が嫌う。技術者が見たら明らかに新規のが早いってのも保守をやらせる
C++はオモチャじゃないんだ。気付かないうちにライブラリが増えるだけでも保守の為の
システム把握に手間が増える。つまり開発費用が嵩む

664 ：デフォルトの名無しさん：2013/07/03(水) 22:08:43.06

>>663 C++11 以降の改定による具体例たのむ

665 ：デフォルトの名無しさん：2013/07/03(水) 22:33:13.34

>>664
例えばだけど、
auto a = b.getX();
a.write(obj);
とかされてたとして、write 付近に何かの不具合があったとする。
すると、先ずは write の仕様を確認したいが、型がわからないので、b から調べる羽目になる。
まあ、MS で言うところのインテリセンス系の技術が発達すれば問題なさそうだけど、明らかにコードの視認性が悪くなってるよね。

666 ：デフォルトの名無しさん：2013/07/03(水) 22:36:12.25

コードがすっきりして
必用なときはマウスを持ってくと表示されるから
視認性はばつ牛ンだわ
IDEが無かったら厳しいな

667 ：655：2013/07/03(水) 22:36:54.07

>>665 の追記だけど、一人で開発してる分には多分問題ないと思うんだ。
ある程度把握できるような思想で統一的に作ったりするだろうし。
他人のコードとかが問題だよね。

668 ：655：2013/07/03(水) 22:40:34.81

>>666
まんまの見た目はスッキリするけど、、、
何て言うのかな、透過性って言ったらいいのかな。
見ただけではクラスの関連がわからなくなるじゃん？

669 ：デフォルトの名無しさん：2013/07/03(水) 22:43:06.68

>>668
関数名がクソだとそうだけど
auto a = b.getX();
この場合は明確だろ？

670 ：655：2013/07/03(水) 23:04:24.99

>>669
ま、まあ、それは一例だからね。
チーム開発をしてると、クソ名も多くなってくるけど、そんなのいちいちチェックできないし。
大抵、不具合発生してからなんじゃこれーってね。

671 ：デフォルトの名無しさん：2013/07/03(水) 23:07:17.49

関数名もそうだけど変数名も重要
この二つが不適切な名前だとｶｵｽ

672 ：デフォルトの名無しさん：2013/07/03(水) 23:12:14.96

現状のインテリセンスってテンプレートクラスや関数内ではテンプレートに纏わるアシストの
効きが落ちるのが不満。
template <class X>のXが不明なうちはアシストしようがないって理屈は分かるんだけど
[intellisense: X = optional<o>, bool, tumuyatumazaruya] template <class X>
とか書いて仮の型を(インテリセンスに対して)提示することでアシストが効くようになってほ
しい。

673 ：デフォルトの名無しさん：2013/07/03(水) 23:31:07.48

最近のC++は脳内コンパイラがないとコーディング困難とかいう記事をどこかのブログで見た。
なるほどって思った面もあるんだけど、scalaみたいにインタプリタを提供すれば脳内コンパイルの
助けになると思うんだよな。そういう点も含めてclangに期待してる。
IDEの補助とC++インタプリタを使えれば、コーディング凄い楽になると思う。

674 ：デフォルトの名無しさん：2013/07/04(木) 01:20:47.76

そもそも全部を把握してる必要あるの？
誰も使わなくなったら終わりなんだからC++は簡単になっていかなければ未来はないよ
今は簡単になっていってると思うよ

675 ：デフォルトの名無しさん：2013/07/04(木) 02:57:12.24

>>674
全部は無い。だがプロには未知の機能を使う事を強いられる時が多い

676 ：デフォルトの名無しさん：2013/07/04(木) 09:56:42.53

ジェネリックラムダとか
「こういう機能です」じゃなくて
「こういう関数オブジェクトクラスが
生成される」と理解しないと
厳しいものがある
あとfor (:)も

677 ：デフォルトの名無しさん：2013/07/04(木) 11:40:36.99

ラムダは「なんでそう記述できるのか」理解しないと使いこなしにくいわな

678 ：デフォルトの名無しさん：2013/07/04(木) 11:51:46.67

自分が使える機能だけ使えばいいじゃん。
コードが読みにくくなるのは、ほとんどプログラマーのせい。
理解できないものには手を出さなければいい。

679 ：デフォルトの名無しさん：2013/07/04(木) 11:55:50.67

プログラマは書けるだけでは半人前
誰が書いたコードでも読めるようになって一人前
誰が書いたコードでも読めると胸張って言うには全てを把握する必要がある

680 ：デフォルトの名無しさん：2013/07/04(木) 12:08:21.20

IOCCCみたいなプログラムは読む必要がない
いや読めない

681 ：デフォルトの名無しさん：2013/07/04(木) 12:15:52.67

Boost.MPLバリバリのも勘弁

682 ：デフォルトの名無しさん：2013/07/04(木) 12:21:04.22

>>681
慣れると読めるというか、苦労するけどなんとか追える。
Lokiも登場当時はイミフすぎバロスだったけど、今では意外と普通？って気すらする。

683 ：デフォルトの名無しさん：2013/07/04(木) 16:00:56.38

>>679
一人前である必要のある人間だけが読めればいい。
一山いくらの連中のために仕様を削る必要はない。

684 ：デフォルトの名無しさん：2013/07/04(木) 17:35:11.58

仕様自体は増えてるけど、汚いパッチワーク仕様や今となっては意味のないクソ機能・クソライブラリが
どんどんdeprecated逝きしてるから、1から学習する分にはずいぶん学びやすくなってると思うんだけどなあ

685 ：デフォルトの名無しさん：2013/07/04(木) 19:46:36.78

C++はゆとり機能を色入れてグダグダになったって感じだからな

686 ：デフォルトの名無しさん：2013/07/04(木) 22:22:02.25

>>665
キミはそのコードが a.write(b.getX()); となっていたら「コードの視認性が悪い」と言うのかね？

687 ：デフォルトの名無しさん：2013/07/04(木) 22:39:13.68

>>686
>>665 はa.write(b.getX());とかが視認性悪いって言っているんじゃないと思う
auto使っていることが>>665の視認性悪いにつながっている
頭悪いと、そんなレスするのかなって気がする

688 ：デフォルトの名無しさん：2013/07/04(木) 22:52:32.61

>>687
auto使ってなくたって「write の仕様を確認したいが、型がわからないので、b から調べる羽目になる」という結果は同じだろ。

689 ：655：2013/07/04(木) 23:05:01.12

>>688
autoでなければaの型がわかるのだから、直接aを調べれば良いのでは…

690 ：デフォルトの名無しさん：2013/07/04(木) 23:09:18.61

C言語を（古っ）覚えた後は他の言語（慣れ親しんだBASICでさえ）文字列型変数って何？！ってなった

691 ：デフォルトの名無しさん：2013/07/04(木) 23:23:52.03

>>689
auto使ってなくたってa.write(b.getX());でも同様に型がわからないという状況は発生する、と言っている。

あと、番号コテ間違ってるよね、たぶん。

692 ：665：2013/07/04(木) 23:44:50.30

>>691
えっ？
元の例え話が、
> auto a = b.getX();
> a.write(obj);
なのだが、
auto を使わないと言う事は、
A a = b.getX();
と言う事なので、型は明確だよね…

で、定義が遠い場所にある場合は、確かに君の言う通りかもしれない。
でもね、元々は auto を使う事で発生しうる不利益の一例をあげたのだから、この例にそぐわないケースで反論されても、その通りだね、で？としか言いようがないのだが。

あ、番号スレの指摘ありがとう。
マジで気付いてなかった。

693 ：665：2013/07/04(木) 23:45:57.61

×番号スレ
○番号コテ

694 ：デフォルトの名無しさん：2013/07/04(木) 23:57:29.44

C++11って可読性が著しく低下してない？

695 ：デフォルトの名無しさん：2013/07/05(金) 00:00:09.41

>>692
C++11以降の規格改訂で増える保守の手間とは？
↓
例えばautoによってこんな問題が。
↓
それautoじゃなくても前から同じ問題起こり得る（んだから
規格改訂で発生した問題ってわけじゃない）よね？
↓←イマココ

696 ：デフォルトの名無しさん：2013/07/05(金) 00:02:01.61

>>694
たとえば？

697 ：デフォルトの名無しさん：2013/07/05(金) 00:04:56.48

>>694
規格の全項目読破が可能かどうかという意味の「可読性」なら同意する。

698 ：665：2013/07/05(金) 00:06:06.94

>>695
いや、だから、auto が故に起きた問題を例示したじゃん。
それを、違う例にすり替えて反論されても、話の筋が通ってないでしょ？

699 ：デフォルトの名無しさん：2013/07/05(金) 00:12:25.77

>>695
autoの使い方によって読みづらくなるケースがあることには反対していない。
それが規格改訂によって発生する問題であるという主張に疑義を示している。

700 ：デフォルトの名無しさん：2013/07/05(金) 00:12:54.38

autoはむやみに使わない／使わせないようにしないとダメだね

701 ：デフォルトの名無しさん：2013/07/05(金) 00:14:46.67

>>696
宣言部分で曖昧なソースでは整数・実数・文字列とかの時代と違って複雑な階層を持つ
クラスを定義されたら何が起こってるのか把握しにくい。

>>697
それほど？C++使いがいなくなりそうだ。むしろトドメを刺す気だろうか

702 ：665：2013/07/05(金) 00:22:54.33

>>699
規格改訂によりauto が取り入れられて、そのauto の使い方で発生しうる一例を挙げた。
規格改訂がなければあの例のケースは発生し得ないよね？
そこは納得してもらえる？

703 ：デフォルトの名無しさん：2013/07/05(金) 00:25:49.96

>>699
規格改訂によって発生する問題と
a.write(b.getX()); がどう関係するんだ?
a.write(b.getX());は規格改定でできるようになったのか

>>700
アホなことにauto使わないってことだな

704 ：デフォルトの名無しさん：2013/07/05(金) 00:27:17.41

>>702
699に書いたとおり、そこは承知。

705 ：デフォルトの名無しさん：2013/07/05(金) 00:28:14.10

autoが「型が明確で無くなる」として害悪であり避けられねばならないと言うのなら、
同じ理由で「関数の引数に他の関数呼び出しその他クラス型に依存する式の結果を
直接渡すことは、型が明確で無くなるので避けるべきである」などと主張することに
なるのではないか、後者のような主張をしないとすればautoと何が違うことによるのか。

706 ：665：2013/07/05(金) 00:39:17.46

>>705
違う違う。
型が明確でなくなるのではなくて、人間が確認するときの手間が増える事を問題視してるのよ。
静的型付け言語なんだから、型は常に明確だよ。

ただ、templateを駆使すると、型が複雑になるからコーディングが大変。
そこでautoの登場でコーティングが楽になる。
反面、読むのは辛くなるから保守に影響しそうと言うのが、僕の主張ね。

707 ：デフォルトの名無しさん：2013/07/05(金) 00:41:31.81

>>665 の例とその後の話を繋げるには a.write(b.getX()) じゃなくて b.getX().write(obj) を考えないとダメだね。

708 ：665：2013/07/05(金) 00:42:58.83

>>707
そうだね。
それなら確かにauto関係なしだね。

709 ：デフォルトの名無しさん：2013/07/05(金) 00:48:27.41

auto x = b.getX();
a.write(x);
とした時にxの型が一目で確認できないというなら
a.write(b.getX());
だって一目で確認できないから同じでしょ？
って話じゃないの？

後者はa.write()の引数の型から分かるってこともあるけど
a.writeがオーバーロード持ってたら？とか
a.writeがtemplate<F>を引数に取るとしたら？とか
考えると、前者と後者には確かに大した差はない。

710 ：デフォルトの名無しさん：2013/07/05(金) 00:54:49.63

>>707
あ・・・大変申し訳ない。見間違えてた。

ただ、示している疑義については変わらない。

C++コードを保守するプログラマはC++98時代からb.getX().write(obj)のような式が
存在する世界に居るわけで、autoによって>>665のような例が発生するとしても
それによって保守の手間が増えるなどということはない、あるいはたいした違いでは
ないだろう、と。

711 ：665：2013/07/05(金) 01:01:11.32

>>709
それは全然話が違うです…

712 ：665：2013/07/05(金) 01:03:16.22

>>710
んー、確かにね。
その例ならこちらも納得せざろう得ないなあ。
ま、可能性があるかもねくらいに受け取ってもらえればよしとしようかな。

713 ：デフォルトの名無しさん：2013/07/05(金) 01:13:06.85

>a.write(b.getX());
>だって一目で確認できないから同じでしょ？

その通りだと思うし、2行に分けて書いた方がいいと思う

714 ：デフォルトの名無しさん：2013/07/05(金) 01:13:14.06

>>710
auto aだと、クラス名が分からない
でも、XXXX a だと、クラス名が分かるからコードの理解に少し役立つから少し安心。
保守の手間って言うより、その場での可読性だと思う
>>665例だと　俺はautoじゃなくクラス名にしろってなる

715 ：デフォルトの名無しさん：2013/07/05(金) 01:14:48.56

「C++はオーバーロードで可読性がー」とか「仮想関数で可読性がー」とか喚いてたCジジィと同じ感覚かな。

716 ：デフォルトの名無しさん：2013/07/05(金) 01:17:01.99

しかし、アレだな
例が hoge じゃないだけで、かなり良スレ化したな
俺はむしろその点を評価するぜ

717 ：デフォルトの名無しさん：2013/07/05(金) 01:17:19.04

そもそも現在においてIDEの補助がない世界を考える必要ってある？
scalaは猛烈に複雑な型を扱うことがあるけど、IDEの補助を前提とする限りは問題にならない。
極論でauto使用禁止とかいう話になったらbindとかクソ面倒臭くてやってられなくなる。
必要な時にはIDEがいつでも即座に型を提示してくれる世界では、人は型を明示的に書く必然性はない。
今後現れるであろうより複雑な型を扱うには、そういう前提が必要になってるんだと俺は思うんだけどな。

718 ：デフォルトの名無しさん：2013/07/05(金) 01:20:49.08

IDE の補助がない環境の方がまだ多いと思うぞ

719 ：デフォルトの名無しさん：2013/07/05(金) 01:22:12.38

え～、うそ～ん、ヤダそんな世界。俺泣いちゃうｗ

720 ：デフォルトの名無しさん：2013/07/05(金) 01:22:36.49

チーム開発で bind は悪

721 ：デフォルトの名無しさん：2013/07/05(金) 01:27:53.01

WindowsならVSがあるが、Linux系でC++開発やってる人って、
IDEは何使ってるんだろ

722 ：デフォルトの名無しさん：2013/07/05(金) 01:32:30.19

>>717
俺はVSだけで組み込みやったことないけど
組み込み系のIDEではろくな補助がないのが多いんじゃないのかって気がする。
あとLinux系で使うIDEは即座にautoの型を提示してくれるのが普通なのかな

723 ：デフォルトの名無しさん：2013/07/05(金) 01:39:54.55

eclipse CDT とかかね？

724 ：デフォルトの名無しさん：2013/07/05(金) 01:41:46.60

>>721
emacsかviにきまってるだろがjk

725 ：デフォルトの名無しさん：2013/07/05(金) 01:48:06.03

>>722
NetBeansはVSに劣らない機能があるよ。
EclipseはCDTの評判がここ最近頗る悪いらしいがどうなんだろう？
あとvimはclang(のフロントエンド？)と組み合わせるとエディタの範疇を遥かに超えるほど
強力って話は聞いたことあるけど、エディタ派生のIDEもどきって全然いい印象がないｗ

726 ：デフォルトの名無しさん：2013/07/05(金) 02:00:52.40

viにきまってるだろがjust kidding

727 ：デフォルトの名無しさん：2013/07/05(金) 02:01:36.07

>NetBeansはVSに劣らない
笑わせてもらった

728 ：はちみつ餃子 ◆8X2XSCHEME ：2013/07/05(金) 02:09:15.14

Emacs なら CEDET を入れるのが鉄板かなぁ。
補完候補を表示してる様子とかのスクリーンショットがこのページにあるよ。
http://alexott.net/en/writings/emacs-devenv/EmacsCedet.html
設定が何かと面倒くさくはあるので、細かいカスタマイズの手間をかけたくないなら NetBeans の方がいいかも。
カスタマイズの余地は Emacs の方がかなり大きいと思うので好みによるだろうな。
普段から Emacs を使っている人は C++ のために NetBeans を入れたりはしないんじゃないかな。

729 ：デフォルトの名無しさん：2013/07/05(金) 02:11:30.37

eclipse過小評価されすぎワロエナイ
eclipseも型表示くらいできるし、vsなんかリファクタリング機能すらないヘッポコだろ？

730 ：デフォルトの名無しさん：2013/07/05(金) 02:16:50.82

linuxな方々って設定ファイルを手書きすることに対してなんかこう思うとこはないんかな？ｗ

731 ：デフォルトの名無しさん：2013/07/05(金) 02:18:07.85

思わないからリナックスなんです

732 ：デフォルトの名無しさん：2013/07/05(金) 02:48:38.69

>>687
痛い所疲れたら逆切れ
恥ずかしw

733 ：デフォルトの名無しさん：2013/07/05(金) 11:40:04.01

>>716
例に「hoge」を用いる文化ってどこが発祥なの

734 ：デフォルトの名無しさん：2013/07/05(金) 12:26:52.84

fjあたりじゃね？
キモヲタウニクサー

735 ：はちみつ餃子 ◆8X2XSCHEME ：2013/07/05(金) 13:35:28.09

http://kmaebashi.com/programmer/hoge.html

736 ：デフォルトの名無しさん：2013/07/05(金) 16:48:41.19

いつまでもしつこいんだよhogeハゲ

737 ：デフォルトの名無しさん：2013/07/05(金) 16:53:34.69

どうしてhogeで発狂するキチが生成されるようになったんだ?

738 ：デフォルトの名無しさん：2013/07/05(金) 20:54:33.46

ファクトリにもクラスとインスタンスがあってだな

739 ：デフォルトの名無しさん：2013/07/05(金) 21:26:00.08

C++使いを多態したらHogeで基地になるバグが....

740 ：デフォルトの名無しさん：2013/07/05(金) 22:07:40.42

半端に知識があるだけで自分のレベルが高いと勘違いしていたところをhogeを多用する人にか場所でフルボッコされたんだろ

741 ：デフォルトの名無しさん：2013/07/05(金) 23:07:41.96

プログラムはテクニックが要るからな。

742 ：デフォルトの名無しさん：2013/07/06(土) 15:16:48.71

>>740
どうしてそういう卑屈な発想になるんだ
普通に人に説明する際、特に意味の無い名前
にhogeは不適切だろ？

743 ：デフォルトの名無しさん：2013/07/06(土) 18:27:12.37

pee poo

744 ：デフォルトの名無しさん：2013/07/06(土) 19:17:09.15

pee pooを流行らせよう

745 ：デフォルトの名無しさん：2013/07/06(土) 19:36:17.32

class poop

746 ：デフォルトの名無しさん：2013/07/06(土) 19:51:32.76

このスレのおかげで、適当な変数名なんかにUnkoとかKusoとか付ける癖がついてしまったｗ
うっかり会社でやりかねんｗ

747 ：ＫＵＳＯＫＯＴＥ：2013/07/06(土) 20:04:55.64

それはなによりです
struct unko_del final {
};

748 ：デフォルトの名無しさん：2013/07/06(土) 20:11:46.02

unkoなら直ぐに意味の無い名前とわかるけど
hogeは一般人には通じないから問題だと思う

749 ：ＫＵＳＯＫＯＴＥ：2013/07/06(土) 20:19:33.31

ご参考：規格3.9p6(Types)
typedef int UNKA[];
UNKA* arrp;

750 ：デフォルトの名無しさん：2013/07/06(土) 20:20:02.72

流石に自演だと思いたい。
クソスレ化する原因は大概たった一人のクソスレメーカーが自演で暴れた結果なんだよなｗ

751 ：デフォルトの名無しさん：2013/07/06(土) 20:22:28.92

人間は誰しもクソメーカー。

752 ：デフォルトの名無しさん：2013/07/06(土) 20:33:13.98

いやUNKOはじわじわ来るぞw
てかこのクソスレに書き込んでるの
5、6人くらいだろ

753 ：ウェルノウン ◆9Ce54OonTI ：2013/07/06(土) 20:41:21.90

よーし、じゃあトリ付けて数えてみようか。
まずはオレから。

754 ： ◆9Ce54OonTI ：2013/07/06(土) 20:45:14.21

どれどれ

755 ： ◆9Ce54OonTI ：2013/07/06(土) 20:49:52.29

このスレには8X2XSCHEMEと9Ce54OonTIの
二人しか居ないようだなw

756 ：デフォルトの名無しさん：2013/07/06(土) 20:53:17.73

hogeよりUNKO・KUSOのほうがはるかに良い!
UNKO・KUSOなら初心者でもどんなものか分かるし

757 ：デフォルトの名無しさん：2013/07/06(土) 20:57:57.78

unko: バカかこいつ
hoge: 氏ね

758 ：デフォルトの名無しさん：2013/07/06(土) 21:25:03.10

おい、江○添の7/3のブログに
コメントしたのおまえらだろ絶対

759 ：デフォルトの名無しさん：2013/07/06(土) 22:51:36.69

(≧∀≦)ゞ

760 ：デフォルトの名無しさん：2013/07/07(日) 00:45:13.91

>>742
別に何でもいいんじゃね？
まあ、俺は使わないけどな
ホゲとか言うのがはずかしいわ

761 ：デフォルトの名無しさん：2013/07/07(日) 01:55:22.20

>>742
hogeを使うことの是非に関する意見はともかく
C++関連スレでhogeを使うなと騒いでる人の行為を抽象化して客観視すれば
どういう人であるか、そういう人の行動原理はなにに基づくことが多いかは自然に感じるところがある

・目標に知らせずに長期にわたって目標の行動を継続的に監視、動きがあれば速やかに反応
・目標のなにげない行動一つをきっかけにして、目標やその周囲の反応を無視して自身が満足するまで執拗に行動を続ける
・目標の言動を自分に都合よく解釈して目標の人格・思想・感情を決めつけて、目標自身やその周囲から否定されても認識を変えない
・行動を糾弾されると理由にならない理由を持ち出して自分の行為の原因は全て目標にあると責任回避・自己正当化

実体が一人の人間ではなくても総体としてよくまとまった行動が可能な集団の構成員なら各自の根本に共通するものがある

762 ：デフォルトの名無しさん：2013/07/07(日) 07:27:50.11

むしろC++関連すれでは
hoge使いの方が基地外

763 ：デフォルトの名無しさん：2013/07/07(日) 10:54:16.68

・気にしない人(普通)
・hoge で釣り針垂らす人(2ch)
・hoge に激しく反応する人()
と言う構図だろ

764 ：デフォルトの名無しさん：2013/07/07(日) 12:56:17.48

釣り糸たらす奴は激しく反応する基地で遊ぶためだし
簡単に釣れ、キチ反応じゃ遊ばれるよね

765 ：デフォルトの名無しさん：2013/07/10(水) 21:02:34.20

なんかC#のようにあらゆる物を取り込んで積荷と偽装で沈む船みたいになりそうな

766 ：デフォルトの名無しさん：2013/07/13(土) 15:51:45.14

hoge志向だからそうなる

767 ：デフォルトの名無しさん：2013/07/13(土) 19:05:45.71

hoge思考言語C++
hogeeeeeeeeeeeeeeeeeee!

768 ：デフォルトの名無しさん：2013/08/08(木) 23:03:13.98

おまえら少しはC++11の規格に関して話せよ
hogehogehogehogeうっせーよ

769 ：デフォルトの名無しさん：2013/08/09(金) 08:51:11.57

hagehageいうなhage

770 ：デフォルトの名無しさん：2013/08/10(土) 01:11:44.47

VisualC++2010のC++11対応状況はどんな感じですか？

771 ：デフォルトの名無しさん：2013/08/10(土) 03:19:31.18

うんこ

772 ：デフォルトの名無しさん：2013/08/10(土) 06:29:36.64

autoとnullptrぐらいじゃね

773 ：デフォルトの名無しさん：2013/08/10(土) 07:15:51.80

ムーブやラムダもかろうじて

774 ：デフォルトの名無しさん：2013/08/10(土) 08:36:47.99

でもラムダ式くらいは使えるのでしょう？

775 ：デフォルトの名無しさん：2013/08/10(土) 08:47:21.03

右辺値参照も一応ある

776 ：デフォルトの名無しさん：2013/08/10(土) 09:55:49.24

11から13のdiffを簡単に教えてくれ

777 ：デフォルトの名無しさん：2013/08/10(土) 10:07:09.96

>>776
右辺値参照の暗黙の変換っていうんだっけ？

void func(string&& str); が、
VC++11 では、func("xxx") では呼ばれないが、
VC++13 では呼ばれるようになった。

778 ：デフォルトの名無しさん：2013/08/11(日) 17:13:56.29

早くideoneでthread使えるようにならないかなかなかなー

779 ：デフォルトの名無しさん：2013/08/11(日) 17:27:10.10

fork爆弾でつぶされる、に１０００ペリカ

780 ：デフォルトの名無しさん：2013/08/25(日) 23:55:14.03

C/C++はコンピュータで何が起こってるのが分かるから好きだし裏ワザも使えるが
C++11は危なそう

781 ：デフォルトの名無しさん：2013/08/26(月) 00:30:07.09

型推論を理解していなければそうみえるだろう
TAPLよめTAPL

782 ：デフォルトの名無しさん：2013/08/26(月) 00:32:32.69

C++11便利すぎてたまらん。
もう離れられん。

783 ：デフォルトの名無しさん：2013/08/26(月) 01:07:54.93

C++11程度と一緒にされたら、真面目に型推論を実装してる言語の人達は怒っていいと思う

784 ：デフォルトの名無しさん：2013/08/29(木) 19:20:22.65

>>783
十分使い勝手いいよ
そら静的型付の関数型言語には負けるが

785 ：デフォルトの名無しさん：2013/09/02(月) 05:21:55.95

自演？

786 ：デフォルトの名無しさん：2013/09/05(木) 01:44:03.58

http://www.open-std.org/jtc1/sc22/wg21/
News 2013-09-04: The deadline for the next mailing is 2013-10-11
News 2013-09-04: The 2013-09-pre-Chicago mailing is available
News 2013-09-04: The C++ Standard Core Language Issues List (Revision 85) is available
News 2013-09-04: The C++ Standard Library Issues List (Revision 84) is available

787 ：デフォルトの名無しさん：2013/09/08(日) 13:19:17.26

>>786はコミュ障

788 ：デフォルトの名無しさん：2013/09/08(日) 16:15:38.17

実装というか今後、企画を満たすコンパイラがどの程度普及するのかも問題

789 ：はちみつ餃子 ◆8X2XSCHEME ：2013/09/08(日) 20:05:24.47

>>788
× 企画
○ 規格

790 ：デフォルトの名無しさん：2013/09/08(日) 21:25:28.51

GCC/Clang は C++14 対応に関してそう長くはかからないだろうし、
VC++ もそろそろ本気出すらしいって話だけどね。

791 ：デフォルトの名無しさん：2013/09/08(日) 21:28:39.82

Windows 8.1出てから本気出す(たぶん)

792 ：デフォルトの名無しさん：2013/09/08(日) 22:55:51.61

>>783
そんなことないよ
C++はかなり厳密な型システムを持ってる

793 ：デフォルトの名無しさん：2013/09/08(日) 23:15:05.31

>>792
strong typingでなくtype deductionの話なのだが

794 ：デフォルトの名無しさん：2013/09/08(日) 23:21:17.76

>>783
明確な一線が存在するが、
それで「怒る」ってのは不自然だな
残念ながら「笑う」が現実だと思う

795 ：デフォルトの名無しさん：2013/09/09(月) 00:18:51.85

>>792
キャストでconstはずせるしdynamic_cast使わずにvoid*から適当な型にキャストできるけどな

796 ：デフォルトの名無しさん：2013/09/09(月) 00:26:51.99

>>795は「厳密な型を持つ」と
「型を無視する抜け道が存在しない」
の区別が付かない人

797 ：デフォルトの名無しさん：2013/09/09(月) 00:27:26.06

>>795
絶対的で硬直化した「型システム」と
必要悪を必要悪と認識したうえで危機管理できる「型システム」ってやつだな

どちらが良いか、この場では言及を避けるが
未知（でなければ金とれない）案件でどちらを選ぶか

後者あっての前者がそのあるべき立ち位置だが
それすらも傲慢な態度で撥ねつける、原理と違う原理主義者が蔓延るのも現実で

798 ：デフォルトの名無しさん：2013/09/09(月) 00:29:48.93

研究する上では抜け道は無いものとして扱うけど
現実の処理系には抜け道がある、ってのが典型的

799 ：はちみつ餃子 ◆8X2XSCHEME ：2013/09/09(月) 02:13:40.44

元の話は抜け道がどうとかじゃなくて >>781 の型推論の話だろ。
型推論の強力さは Haskell 等に比べれば確かに C++ は複雑なばかりで強力とは言えない。

だけどあまり強力な推論はプログラマの意図の外のまるっきり考えてなかったところで型が嵌ってしまうことがあり、
やっぱそこそこでいいやっていう説もあって、その意味でも C++ は現実的な折り合いが付くポイントを探しながら、
発展を続けていると言える。

800 ：デフォルトの名無しさん：2013/09/09(月) 10:55:05.38

>>799
何も言ってないのと同じだな

801 ：デフォルトの名無しさん：2013/09/09(月) 11:13:25.52

>プログラマの意図の外のまるっきり考えてなかったところで型が嵌ってしまう
のはC++のほうが多そうな罠
なんだよ括弧の有無で動作が違うって…

802 ：デフォルトの名無しさん：2013/09/09(月) 13:00:18.61

リリリリら

803 ：デフォルトの名無しさん：2013/09/09(月) 15:13:38.75

>>799
>だけどあまり強力な推論はプログラマの意図の外の
>まるっきり考えてなかったところで型が嵌ってしまうことがあり
ねえよｗありえねえよｗ
想像だけで語るなよｗ

804 ：デフォルトの名無しさん：2013/09/10(火) 00:00:40.32

型推論の宗教論争はともかく
decltypeちゃんがどんどん黒魔術に成り果てていくのが見てて辛い

805 ：デフォルトの名無しさん：2013/09/10(火) 00:35:09.33

>>796
それをわかった上で抜け道があることが厳密性を破壊してるって指摘してるんだけど

806 ：デフォルトの名無しさん：2013/09/13(金) 14:04:32.77

scalaとかIDEなしだとどんな型になってるのか訳が分からん。

>>804
decltypeちゃんとautoさんはバギーな脳内コンパイラをよしなに補ってくれる天使

807 ：デフォルトの名無しさん：2013/10/02(水) 18:13:41.49

std::optional さんの命運や如何に

808 ：片山博文MZコスモ ◆T6xkBnTXz7B0 ：2013/10/07(月) 13:14:59.86

C++ reference (CHMファイル)ができたよ。
https://dl.dropboxusercontent.com/u/72753355/cppreference-20130510-0.zip

809 ：デフォルトの名無しさん：2013/10/07(月) 16:25:48.96

日本語訳しといて。

810 ：デフォルトの名無しさん：2013/10/08(火) 01:48:57.64

おう

811 ：デフォルトの名無しさん：2013/10/11(金) 07:29:32.38

shared_ptr遅くね？

812 ：デフォルトの名無しさん：2013/10/11(金) 07:41:10.88

shared_ptrより万倍遅いやつがいるから大丈夫

813 ：デフォルトの名無しさん：2013/10/12(土) 12:47:44.64

http://d.hatena.ne.jp/gintenlabo/20110725/1311606012
http://itr0510.blogspot.jp/2011/02/sharedptrintrusiveptr_27.html
shared_ptrを管理して高速化することは出来るみたいだけど、ちゃんとしたライブラリあるんかな？

814 ：デフォルトの名無しさん：2013/10/12(土) 12:51:52.08

>shared_ptrを管理して高速化
バカの発想はどうしようもないな

815 ：デフォルトの名無しさん：2013/10/12(土) 14:15:42.13

だいたいshared_ptrのオーバーヘッドが問題になるくらいの使い方ってどんなのよ？
ベンチマークか？

816 ：デフォルトの名無しさん：2013/10/12(土) 14:29:14.37

shared pointer等からアドレスをとって、それに対して何らかの処理をしていると、
何らかの処理にかかる時間の方が随分と大きくなるのが当たり前。
shared pointerと生pointerの違いがベンチマークで表面化することは、普通はあり得ないくらい
shared pointerによるオーバーヘッドは極めて微量。

817 ：デフォルトの名無しさん：2013/10/13(日) 05:45:20.73

ナパームドライバー！

818 ：デフォルトの名無しさん：2013/10/13(日) 06:32:53.66

make_shared使ってるか？

819 ：デフォルトの名無しさん：2013/10/13(日) 14:58:51.88

make_sharedの方がコンストラクタ呼んでくれるから便利

820 ：デフォルトの名無しさん：2013/10/13(日) 15:19:26.21

make_uniqueが11で入らなかったのが不思議

821 ：デフォルトの名無しさん：2013/10/13(日) 15:41:00.82

元となったBoost.SmartPointersに無かったからじゃない？14では提案されているし

822 ：デフォルトの名無しさん：2013/10/13(日) 16:04:54.50

宣言にauto 使えるだけでshare_ptr ほどにはご利益が無いじゃん

823 ：デフォルトの名無しさん：2013/10/13(日) 16:06:42.84

newを隠せるとか

824 ：デフォルトの名無しさん：2013/10/13(日) 20:34:08.69

多次元配列を実装してくれ

825 ：デフォルトの名無しさん：2013/10/13(日) 21:21:26.38

多次元配列なんていらんだろ。

826 ：デフォルトの名無しさん：2013/10/13(日) 21:25:17.27

自分でできるだろ。

827 ：デフォルトの名無しさん：2013/10/14(月) 04:19:15.42

>>824
多次元配列や行列はハードウェア固有機能を使った最適化の影響が大きい
汎用品では性能差がありすぎて実用的ではない

828 ：デフォルトの名無しさん：2013/10/15(火) 11:12:30.00

shared_ptrで気になるオーバーヘッドって、マルチスレッド対応で同期処理してる部分のことじゃないの

829 ：デフォルトの名無しさん：2013/10/15(火) 11:13:52.29

>>828
shared_ptrに同期保証なんてあったの？

830 ：デフォルトの名無しさん：2013/10/15(火) 11:43:33.74

std::shared_ptrはアトミック保証

831 ：デフォルトの名無しさん：2013/10/15(火) 11:59:02.91

atomic = 同期とは限らんからなあ。

N2351 Improving shared_ptr for C++0x, Revision 2
＞A variant of shared_ptr that is atomic, that is, safe to be manipulated from multiple threads without synchronization

wait-freeかlock-freeな実装してるんじゃないの

832 ：デフォルトの名無しさん：2013/10/15(火) 12:46:50.31

引用したところは「使う側は同期する必要ないよ」って言ってるだけだろ
アトミック命令だって一種の同期メカニズム

833 ：デフォルトの名無しさん：2013/10/15(火) 14:32:29.52

競合する箇所では使わないからもっと速度優先でやってくれ
の場合
自分で作るしかないか

834 ：デフォルトの名無しさん：2013/10/15(火) 14:35:55.86

Boostのshared_ptrだとdefineで同期機能の無効化（高速化）ができる

835 ：デフォルトの名無しさん：2013/10/15(火) 14:44:04.79

参照カウンタの増減に使ってる程度なら、
CASだけで実装できるだろうから、
オーバーヘッドは軽微でないかいな

836 ：デフォルトの名無しさん：2013/10/15(火) 14:51:13.63

>>834
同期機能あり版と無し版を同時に使えない？

837 ：デフォルトの名無しさん：2013/10/15(火) 14:53:05.00

>>835
CAS重いぞ。ベンチマークが極端に変わる

838 ：デフォルトの名無しさん：2013/10/15(火) 16:14:08.86

>>836
ソースごとにdefine＋includeすればモジュール単位での併用はいけるかもしれないが完全共用は無理臭い

839 ：デフォルトの名無しさん：2013/10/15(火) 16:32:33.74

マルチスレッド無視でいいから速度重視のsharedptr欲しいなら
まじで作ってしまうのが手っ取り早いぞ
試しに作ってみろ
ベンチ圧倒的だ

昔のCPUだとフロントクラスのメンバーに実ポインタを持たせると速かったが（boostとかそうしてる）
今はむしろ逆だからな
オブジェクトのサイズをコンパクトに抑えてキャッシュ効果を上げろ

840 ：デフォルトの名無しさん：2013/10/15(火) 21:19:34.05

フロントクラスてなに？

841 ：デフォルトの名無しさん：2013/10/16(水) 01:18:40.37

>>840
スマートポインター系は、どれも前と後ろに分かれてんじゃね？

842 ：デフォルトの名無しさん：2013/10/16(水) 18:56:34.40

んなこたーない

843 ：デフォルトの名無しさん：2013/10/16(水) 19:16:17.25

>>842
分かれてないやつは具体的にどういうのがある？

844 ：デフォルトの名無しさん：2013/10/16(水) 19:33:54.53

>>843
auto_ptr

845 ：デフォルトの名無しさん：2013/10/16(水) 20:08:30.14

>>844
もはや別物

846 ：デフォルトの名無しさん：2013/10/17(木) 06:29:16.59

auto_ptrはオワコン

847 ：デフォルトの名無しさん：2013/10/17(木) 07:26:06.00

じゃあunique_ptr

848 ：デフォルトの名無しさん：2013/10/17(木) 13:21:27.42

typedef (void *) smart_ptr;

849 ：デフォルトの名無しさん：2013/10/17(木) 14:27:12.45

claver_ptr

850 ：デフォルトの名無しさん：2013/10/17(木) 14:27:54.63

clever_ptrだった

851 ：デフォルトの名無しさん：2013/10/17(木) 17:59:51.27

You is big fool man.

852 ：デフォルトの名無しさん：2013/10/21(月) 18:46:31.57

そういえば生ポをラップしただけのアホの子ポインタを入れる話は結局どうなったの

853 ：デフォルトの名無しさん：2013/10/22(火) 16:45:08.81

低レベル言語のくせに
化け物みたいに膨らんだグロテスクな文法

仕様の切捨てしろよ

854 ：デフォルトの名無しさん：2013/10/22(火) 17:11:47.09

例外を刷新してほしい

855 ：デフォルトの名無しさん：2013/10/22(火) 17:17:26.01

>>854
具体的に

856 ：デフォルトの名無しさん：2013/10/22(火) 17:30:00.07

catch のオーバーロードなんかいらねえ
exception_ptr と dynamic_cast さえあればどうにでもできる

それと RESUME がないのも
諸説あろうが俺は好かん

857 ：デフォルトの名無しさん：2013/10/22(火) 22:18:53.58

お前らが過去を切り捨てた綺麗なc++作るとしたらどこを切り捨てるの？

858 ：デフォルトの名無しさん：2013/10/22(火) 22:23:30.84

なにはともあれ、まずユーザー定義リテラルだな

859 ：デフォルトの名無しさん：2013/10/22(火) 23:32:30.32

++の部分を全て

860 ：デフォルトの名無しさん：2013/10/23(水) 00:02:42.37

>>857

変数定義や宣言を意味する予約語を新設。関数宣言を意味する別の予約語も新設。

今のC++の場合
a b(c);
と書かれている箇所を解釈しようとしても、
型aの変数bを定義して引数cをコンストラクタの引数に渡しているのか、
引数の型がcとなる型aの関数bを宣言しているのか、
この表現を見ただけでは分からない。
つまり構文解析の結果を知っていないと解析できない。

861 ：デフォルトの名無しさん：2013/10/23(水) 00:08:06.22

>>860
そこは、削除するべきはコンストラクタの ( ) 呼びじゃね？
{ } で統一されたんだから

862 ：デフォルトの名無しさん：2013/10/23(水) 00:17:55.36

>>861

int i = getpid();
double d = double(i) / 2;

は

int i = getpid();
double d = double{i} / 2;

になるべきだと？

863 ：デフォルトの名無しさん：2013/10/23(水) 00:41:51.43

>>862
double tod(int i) { return double(i); } を
double tod(int i) { return {i}; } って書けるんだから、それでいいだろ

864 ：デフォルトの名無しさん：2013/10/23(水) 01:31:24.15

過去を切り捨てた美しいC++が欲しいなら
Java、C#、Dがもう既にあるのだからこてを今すぐ使えばいい。
C++は良くも悪くもCと互換性があるというところに存在意義がある。

865 ：デフォルトの名無しさん：2013/10/23(水) 01:48:40.89

Cとの互換性なんて
どうでもいいんだが

866 ：デフォルトの名無しさん：2013/10/23(水) 01:59:36.20

>>864
> 過去を切り捨てた美しいC++が欲しいなら
> Java、C#、Dがもう既にあるのだから

違う。
それらが切り捨てたのはC互換だけじゃない。

867 ：デフォルトの名無しさん：2013/10/23(水) 02:31:24.20

>>864
よしてくれ
そんな軟派と一緒になんか

Jだけは論点によっては傾聴すべきところはあるが
おまえはそこに噛みついてこれるか？

868 ：デフォルトの名無しさん：2013/10/23(水) 02:53:24.69

>>867
お前が聴くから、その聴いてる行為に対して他人が噛みつけと？

869 ：デフォルトの名無しさん：2013/10/23(水) 03:00:34.05

>>868
何の話か通じない人たちには聞いてないから無理にレス返さなくていいよ

870 ：デフォルトの名無しさん：2013/10/23(水) 03:10:02.54

>>867
お前が傾聴するの？

871 ：デフォルトの名無しさん：2013/10/23(水) 03:17:39.65

stlのライブラリをboostベースにして
ついでに.bad()とか使ってる人にしか理解できないメソッドを
一度整備してほしい
std::streamとか初めて見た時具合悪くなったｗ

872 ：デフォルトの名無しさん：2013/10/23(水) 03:30:38.31

>>870
論点によってはと言っているだろ
おまえくどい

873 ：デフォルトの名無しさん：2013/10/23(水) 07:34:50.73

>>867
Jって書かれるとJ言語に見えるからやめたまえ

874 ：デフォルトの名無しさん：2013/10/23(水) 08:34:00.07

>>860
賛成だけど、切り捨ててないし、それ。

875 ：デフォルトの名無しさん：2013/10/23(水) 09:04:21.15

>>872
お前が傾聴するなら、お前は聴いてる立場だろ。
お前が論じるならお前に噛みつく奴は現れるかもしれないけど、
お前が聴いてるだけの立場なら、お前に噛みつく奴はいないだろ。

876 ：デフォルトの名無しさん：2013/10/23(水) 09:38:05.07

>>875
それは屁理屈
聞いているか論じるかなんてこっちの勝手だ
お前が決める事ではない

877 ：デフォルトの名無しさん：2013/10/23(水) 12:30:06.81

C++2ch つくろーぜ

878 ：デフォルトの名無しさん：2013/10/23(水) 14:30:09.26

>>876
そうだね。
君の自由意思で、君は論じずに傾聴すると決めたんだよね。
で、他人は論じない君に対してどうやって噛みつくの？

879 ：デフォルトの名無しさん：2013/10/23(水) 16:33:22.20

>>878
傾聴するなんて一言も言ってないわけだが

880 ：デフォルトの名無しさん：2013/10/23(水) 17:18:45.06

>>879
いやいや、>>872で
論点によっては傾聴すると言っている

881 ：デフォルトの名無しさん：2013/10/23(水) 17:30:18.31

アルツハイマーかよ

882 ：デフォルトの名無しさん：2013/10/23(水) 17:41:01.47

本物の病気の相手はほどほどにな
ドグラマグラみたいなの読まされるの勘弁

883 ：デフォルトの名無しさん：2013/10/23(水) 20:56:49.29

キチガイ地獄祭文

884 ：デフォルトの名無しさん：2013/10/23(水) 21:05:45.01

>>867
つまりお前が言いたいのは
「論点によっては傾聴すべきこともあるから、
すわなち、論点によっては、俺はお前の意見を傾聴してやるから、
その件についてお前は俺に噛みついてこれるか（俺に反論できるか）？」
ってことだろ？

885 ：デフォルトの名無しさん：2013/10/23(水) 21:39:43.45

いいからC++14の話しろよ

886 ：デフォルトの名無しさん：2013/10/23(水) 21:46:11.15

>>857
Cにclassとtemplateを追加した感じかなぁ。
Cのラッパーだったときのしがらみはちゃんと切り捨てたい。切り分けたい
構造体はデータの塊というだけで十分なんだよ。

あと、仮想デストラクタのないクラスは、デフォルトでは継承不可とか？

887 ：デフォルトの名無しさん：2013/10/23(水) 21:49:29.26

仮想デストラクターになるのが "class"
そうでないものが "struct"
structは基底クラスへのポインターで取り扱うことができない

ってしてほしかったぞ

888 ：デフォルトの名無しさん：2013/10/23(水) 21:57:27.52

>>877
Cww だなｗ

889 ：デフォルトの名無しさん：2013/10/23(水) 21:57:48.92

仮想デスクトラクタとかめったに使わんわ

890 ：デフォルトの名無しさん：2013/10/23(水) 21:59:31.29

>>889
ポリモちっくなこと全然やらんとか？

891 ：デフォルトの名無しさん：2013/10/23(水) 22:15:08.00

仮装デストラクターが無いとポリモーフィズムができないとでも
言いたいんだろうか

892 ：デフォルトの名無しさん：2013/10/23(水) 22:18:47.23

>>890
ほとんどやらんな
静的に解決できてるわ

893 ：デフォルトの名無しさん：2013/10/23(水) 22:34:23.96

プログラムの意味的に継承構造があまり必要でない
オブジェクトがあまりスコープをこえて旅しない

のどっちだろ

894 ：デフォルトの名無しさん：2013/10/23(水) 22:49:48.97

> オブジェクトがあまりスコープをこえて旅しない
こっちじゃね？
オブジェクトを手元だけで使う分には静的にできるからね。
離れた場所に旅させるとオブジェクト自身の動的な機能が必要になる。

895 ：デフォルトの名無しさん：2013/10/23(水) 23:15:15.70

>>865
Cのライブラリそのまま使えるのはでかかったよ

896 ：デフォルトの名無しさん：2013/10/24(木) 00:19:02.16

shared_ptrにつっこんどけば仮想デストラクタにしなくても適切なデストラクタが呼ばれるって選択肢も

使い方変えたときに間違いの元になるが。

897 ：デフォルトの名無しさん：2013/10/24(木) 13:58:27.02

>>896
これ便利だよね
virtual付け忘れてやっべリークしたかと思って調べたらセーフだったことがある

898 ：デフォルトの名無しさん：2013/10/24(木) 19:25:21.41

その仕組み規格では明記されてないから
やってくれるかどうかはimplementation-definedじゃなかったっけ

899 ：デフォルトの名無しさん：2013/10/24(木) 19:27:00.26

あ、C++11/14のstd::shared_ptrの話な
boost::shared_ptrはドキュメントに書いてあるから大丈夫

900 ：デフォルトの名無しさん：2013/10/24(木) 23:46:58.92

こうしてC++の深い部分を理解しない土方PGが量産されるのであった。

901 ：デフォルトの名無しさん：2013/10/24(木) 23:55:31.36

量産されるほど人数いたのか

902 ：デフォルトの名無しさん：2013/10/25(金) 00:47:07.09

動的削除子サポートされてないshared_ptrなんて現存するの？

903 ：デフォルトの名無しさん：2013/10/25(金) 00:51:17.23

>>898
規格読んでないけどその仕組みのためにコンストラクタのポインタの型がテンプレートになってるんじゃないの？

どちらとも言わずにつまらん煽りしか言わない人は何者になれるのかな

904 ：デフォルトの名無しさん：2013/10/25(金) 01:42:03.03

デストラクタにはvirtual付け必須でイイんでね？

905 ：デフォルトの名無しさん：2013/10/25(金) 01:47:11.03

もはやC++ではなくなる

906 ：デフォルトの名無しさん：2013/10/25(金) 01:48:46.56

非virtualの明示化なら、まだ意味わかるんだけど
それがfinalと連動とかだとキモすぎて耐えらんない

907 ：デフォルトの名無しさん：2013/10/25(金) 03:17:18.94

>>904
非ポリモーフィックなクラスはファイナルかつ非仮想デストラクタにする

908 ：904：2013/10/25(金) 03:46:26.66

>>907
C++11からfinal入ったんか。

909 ：デフォルトの名無しさん：2013/10/25(金) 06:49:14.99

>>864
> 過去を切り捨てた美しいC++が欲しいなら
> Java、C#、Dがもう既にあるのだからこてを今すぐ使えばいい。

全部GCがついてくるというのが心底頭抱えたくなるんだが……
JavaScriptを覇権言語にしたがってる連中もだがどいつもこいつも何なの

Java-House MLあたりで「ふんづまり現象」だのとクソのような名前で呼ばれていた頃から
GC pause、結局全然解決しとらんではないか。

「Javaでハイパフォーマンスアプリが作れないというのは誤解だ。作り方が悪い」ｷﾘｯ
→newしない＆オブジェクトプール（笑）

「JavaScriptでハイパフォーマンスアプリが作れないというのは誤解だ。作り方が悪い」ｷﾘｯ
→newしない＆オブジェクトプール（笑）

いくらCPUが速くなってもカクカク動作のAndroid
一方、AppleはiPhoneの成功を受けてMacでもGCを非推奨にした。

GCのある言語はクソであること、GCのない言語を置き換えることはできないことをそろそろ学習するべきだ。
その根底が分からない限り、better C++など100年経っても出てこない。

910 ：デフォルトの名無しさん：2013/10/25(金) 06:57:39.62

世の中にはほんの数ミリ秒でも動作が止まっちゃまずいソフトウェアというものが数多くあって
（例えば機械制御、ゲームプログラム、株取引、シンセサイザー等）
そういう世界が見えていない、時間解像度が低いプログラマが多すぎる

特にウェブの連中は数百ミリ秒のめちゃめちゃ荒いオーダーの世界で生きてるくせに
その認識がまったくないからマジで頭に来る

911 ：デフォルトの名無しさん：2013/10/25(金) 07:20:17.26

マルチコア当たり前の現在でもやっぱりガベコレで糞詰まるもんなの？
D言語＋マルチコアで革命的な何かが起こると期待してたんだけど
まったく何も起こらないんでガッカリしてるとこなんだけど・・・・・・

912 ：デフォルトの名無しさん：2013/10/25(金) 07:57:19.07

マルチコアでガベコレが速くなると思えるのが不思議。

913 ：デフォルトの名無しさん：2013/10/25(金) 08:01:19.68

「GCで詰らなくなる」と「GCが速くなる」が同じと思えるのが不思議

914 ：デフォルトの名無しさん：2013/10/25(金) 08:04:32.33

原理的な問題と実装上の問題が混同されている

Erlangとそれを使ったシステム開発は、ソフトリアルタイムシステムまでは
GCが特に問題なく適用できることを示した事例にあたると思う
ハードリアルタイムな例えば車のブレーキ制御とかだとさすがに不味い気はする

915 ：デフォルトの名無しさん：2013/10/25(金) 08:15:28.88

>>909,910
頑張らなければならないところでJavaを使うのもどうかとおもうけれども、頑張らなくてもいいところでC++というのも
正直メモリまわりが手抜きに書けるのはありがたい

916 ：デフォルトの名無しさん：2013/10/25(金) 08:42:38.64

>>913
結局、詰まらなくなるのと速くなるのは同じじゃねーか？

917 ：デフォルトの名無しさん：2013/10/25(金) 08:49:07.97

ソフトウェアは待機時間の方が長いことも多い。 (特にデスクトップ用途なら。)
何もしてないはずの待機時間をメモリの回収のために使えば体感的な動作速度が速くなるのは道理。
GC を使うことによって単位時間あたりの処理量が少なくなってもレスポンスタイムは速くなる可能性がある。

デストラクタの発動時に関連オブジェクトのデストラクタが連鎖的に発動するのは GC で詰まるのと似たようなもの。
C++ でもデストラクタで不要なオブジェクトの登録だけして後で回収するとかいった工夫も出来ることは出来るけど、
それなら GC のある言語を使った方がマシ。

いずれにしてもそれは作ろうとしているソフトウェアの性質によるのであって、
GC が不利になる状況だけをことさらに抜き出して比較するのはアンフェアというものだよ。

918 ：デフォルトの名無しさん：2013/10/25(金) 09:01:10.07

そんな道理通りにいかないのはJavaアプリちょっと使ってたら体感できるじゃねーか

919 ：デフォルトの名無しさん：2013/10/25(金) 09:25:06.73

http://toro.2ch.net/test/read.cgi/tech/1374022208/9
こういうの見るとなんだかなあって思っちゃうわ

920 ：デフォルトの名無しさん：2013/10/25(金) 10:08:52.44

>>917
Chromiumの中身で使われてるメモリ領域なんて99% スマポ(sp)だし
Eclipseは重すぎて高スペック要求
現実は全く逆なんだけど、どうしてそんな主張というか見解が生まれるの？

921 ：デフォルトの名無しさん：2013/10/25(金) 10:22:21.23

GC嫌ならRustにしたら

922 ：デフォルトの名無しさん：2013/10/25(金) 10:23:50.30

GCは便利なツールってだけだよ
事実をねじ曲げてまで肯定するアホは死んでください

923 ：デフォルトの名無しさん：2013/10/25(金) 10:26:01.44

もしかしてEclipseがクソ重いのはGCのせいだと思っているのか

924 ：デフォルトの名無しさん：2013/10/25(金) 10:30:32.18

>>923
動作自体が重い処理もあるので、GCだけで重くなってるとは言わない
が、現実としてGC回数減らすとぐっと速くなる

925 ：デフォルトの名無しさん：2013/10/25(金) 10:47:30.50

コンカレントGCとかG1GCを動かすと速度が露骨に落ちるな
マルチコアだと落ちないと思ってたけど甘かった

926 ：デフォルトの名無しさん：2013/10/25(金) 11:01:11.82

>>916
GCの停止時間とGCのスループットはトレードオフの部分もあるので、
そこまで単純でない。あの辺りの話は一概には言えないことばっかり

ちなみに参照カウントは遅いという議論もあって……

927 ：デフォルトの名無しさん：2013/10/25(金) 11:07:36.24

参照カウントが遅い？

928 ：デフォルトの名無しさん：2013/10/25(金) 11:12:21.90

もちろんatomicなshared_ptrに限定した参照カウントです

929 ：デフォルトの名無しさん：2013/10/25(金) 11:15:03.42

その辺の比較してる文献ソースとかプログラムソースとかないの？
体感で遅い速い言っててもしょうがないよ。

930 ：デフォルトの名無しさん：2013/10/25(金) 11:58:22.31

"Why mobile web apps are slow | Sealed Abstract"
http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
> All about garbage collectors
とりあえずやたら長い記事なうえ 2005 年の論文を論拠にしててコメント欄で
突っ込まれてたりするので結論はいまいち。まぁここに載ってるような話を
繰り返す必要はないということで。

931 ：デフォルトの名無しさん：2013/10/25(金) 12:03:47.05

で参照カウントがGCより遅いって根拠はどこ？

932 ：デフォルトの名無しさん：2013/10/25(金) 12:17:15.77

>>931
参照カウントもGCの一種だから
参照カウントとGCのなにを比較してんのかと

933 ：デフォルトの名無しさん：2013/10/25(金) 12:17:59.63

ひたすらコピーするのがポインタと比べて遅いとか言ってるんじゃねえの？

934 ：デフォルトの名無しさん：2013/10/25(金) 12:25:14.81

>>932
また無茶なことを言い出したな…

935 ：デフォルトの名無しさん：2013/10/25(金) 13:58:42.61

定数文字列をコンパイル時に操作できるライブラリってありませんか？
できれば某氏の以外で・・・

936 ：デフォルトの名無しさん：2013/10/25(金) 14:15:13.06

定数文字列をコンパイル時に操作って何よ？意味不明なんだけど

937 ：デフォルトの名無しさん：2013/10/25(金) 17:02:55.66

え、そのまんまだろｗ

938 ：デフォルトの名無しさん：2013/10/25(金) 20:15:03.78

>>936
コンパイル時、定数文字列から、別の新しい定数文字列を作成するようなものです。
C++11対応で、より一般的なライブラリがないかなと思いまして。

939 ：デフォルトの名無しさん：2013/10/25(金) 21:12:46.98

>>938
具体例でも挙げて

940 ：デフォルトの名無しさん：2013/10/25(金) 21:13:49.22

>>939
は何が分からないの？「コンパイル時」？「定数文字列」？「文字列操作」？

941 ：デフォルトの名無しさん：2013/10/25(金) 21:18:51.96

>>917
GC って途中でやめることができるのか？一度走り出したら最後まで止まらないとおもっていたんだが
マーク&スウィープとかさ

942 ：デフォルトの名無しさん：2013/10/25(金) 21:23:46.25

>>938
コンパイル時に編集したファイルをコンパイルするようにすればいいじゃん。
別名で保存してさ

943 ：デフォルトの名無しさん：2013/10/25(金) 21:35:10.40

>>938
> 別の新しい定数文字列を作成

って具体的に何すんの？

944 ：デフォルトの名無しさん：2013/10/25(金) 21:42:05.27

こういう奴?
http://www.boost.org/doc/libs/1_54_0/libs/mpl/doc/refmanual/string.html

945 ：デフォルトの名無しさん：2013/10/25(金) 22:08:02.18

>>944
えーと・・そういうやつですが、mplみたいな黒魔術的なのでなく、
C++11で、かつ某氏のSproutよりも一般的なものがないかなと。
ないならSproutを拝借するつもりです。

946 ：デフォルトの名無しさん：2013/10/25(金) 22:48:23.75

めんどくせえ
実行時にやれ

947 ：デフォルトの名無しさん：2013/10/25(金) 23:00:50.72

そういえば目的を聞いてなかったな

948 ：デフォルトの名無しさん：2013/10/25(金) 23:03:50.19

いえ、もう結構です。
ありがとうございました。

949 ：デフォルトの名無しさん：2013/10/25(金) 23:51:29.17

ちょｗｗｗ

950 ：デフォルトの名無しさん：2013/10/26(土) 00:39:34.43

もう埋め埋め
店じまい

951 ：デフォルトの名無しさん：2013/10/26(土) 00:48:07.15

constexprってC++1yで早々に手直しが入ってなかったっけ

952 ：デフォルトの名無しさん：2013/10/26(土) 01:00:47.10

三項演算限定の制約無くなったんだっけ

953 ：デフォルトの名無しさん：2013/10/26(土) 01:01:18.65

関数の

954 ：デフォルトの名無しさん：2013/10/26(土) 01:11:58.49

constexpr時代のクラス
・ポリモーフィックなクラス
・非ポリモーフィックなクラス
・インターフェイスなクラス
・リテラルなクラス＜new

955 ：デフォルトの名無しさん：2013/10/26(土) 01:32:57.33

>>941
ものによる。
細かな空き時間を使えるようにちょこちょこ GC する方式もあって、
そういった種類の GC は「インクリメンタル GC」と呼ばれている。

956 ：デフォルトの名無しさん：2013/10/26(土) 02:56:07.02

int hoge()
{

comeback (0)//return の返り値が0だったら実行
{

}

return 0;
}

957 ：デフォルトの名無しさん：2013/10/26(土) 15:41:48.16

次スレのタイトルはどうなるんだ？
いくらなんでも11を付けたままなのは
そろそろまずいだろう

958 ：デフォルトの名無しさん：2013/10/26(土) 19:04:33.90

いつになったら.ccと.hh分割の呪いから解消されるの？
そろそろ他の言語みたいに拡張子ひとつで書きたいよ

959 ：デフォルトの名無しさん：2013/10/26(土) 19:12:21.77

昔、区分編成データセットというのがあってだな・・・

960 ：デフォルトの名無しさん：2013/10/26(土) 20:05:25.73

C++14/C++1yでいいだろ

961 ：デフォルトの名無しさん：2013/10/26(土) 20:14:17.69

>>957
ウゼェ他所池

962 ：デフォルトの名無しさん：2013/10/26(土) 20:20:28.44

>>958
ファイルが分かれていないと、非公開部分だけを修正しても依存ファイルがリビルドされてしまいそうだけど。
(公開部分だけを抜き出してハッシュで管理するような超賢いビルドツールがある場合を除く)

963 ：デフォルトの名無しさん：2013/10/26(土) 21:22:56.10

結局C使い以外は「コンピュータとは何か？」が見えてないんだな

964 ：デフォルトの名無しさん：2013/10/26(土) 21:28:00.02

哲学的だな

965 ：デフォルトの名無しさん：2013/10/26(土) 21:44:59.55

いや、まんまだろ

966 ：デフォルトの名無しさん：2013/10/26(土) 23:43:02.90

>>962
後続の言語がそういうのをぞくぞくと解決しているのにC++ときたら

967 ：デフォルトの名無しさん：2013/10/27(日) 00:51:16.46

例えばJavaの大量のimport文の羅列が美しいかどうかってこと？ないな
rubyとかだとそれさえ不要になってるとか言う？Railsボケあたりが寝ぼけた反論してくるのが関の山だろ
ヘッダファイルは泥臭くとも最小の解の一つ
対案たる実装はない

968 ：デフォルトの名無しさん：2013/10/27(日) 01:16:31.10

ヘッダファイルはとても便利だと思うがなあ
コンパイラに何が見えてて何が見えないか把握できるのが非常に便利
そういう把握が出来ないならプログラマ向いてない

969 ：デフォルトの名無しさん：2013/10/27(日) 01:18:41.07

privateメンバも別ファイルにできたら良かったんだけどなぁ。
まぁ、pImpleイディオムがあるけど。

970 ：デフォルトの名無しさん：2013/10/27(日) 01:31:08.51

この辺の議論かな

There are many reasons why C++ compiles so slowly
http://www.drdobbs.com/cpp/c-compilation-speed/228701711

971 ：デフォルトの名無しさん：2013/10/27(日) 01:54:34.27

import文の有無とヘッダファイルの有無って関係なくね

972 ：デフォルトの名無しさん：2013/10/27(日) 02:23:01.18

ファイルの参照も理解できないのか

973 ：デフォルトの名無しさん：2013/10/27(日) 08:55:04.12

>>969
同意

974 ：デフォルトの名無しさん：2013/10/27(日) 08:56:47.54

クラスのサイズが変わっちゃうから無理なんじゃないかな

975 ：デフォルトの名無しさん：2013/10/27(日) 09:35:55.56

精神分裂とか2重人格をオブジェクト指向に取り入れられないか

class A
{
unknown://自分の知らない自分

private:

protected:

public:

};

976 ：デフォルトの名無しさん：2013/10/27(日) 11:57:49.87

じつに興味深いテーマだｗ

977 ：デフォルトの名無しさん：2013/10/27(日) 12:41:30.76

this が左辺値になってくれるとうれしいんだけど
root=>bintree_add(obj);

978 ：デフォルトの名無しさん：2013/10/27(日) 12:42:11.87

オペレーターの外部定義や、C#の拡張メソッドなどが、
publicを利用しているだけなんだけど
class自身が知らない世界に近いかな

979 ：デフォルトの名無しさん：2013/10/27(日) 15:14:57.25

>>975
お前はバカだけどすごく気に入った

980 ： ◆QZschizo.ptH ：2013/10/27(日) 16:34:04.11

>>975
精神分裂って別に unknown な自分があるとかじゃないよ、ただただだんだん馬鹿になっていくだけで、自覚はないらしいよ
本人がいうから間違いないよ

981 ：デフォルトの名無しさん：2013/10/27(日) 16:39:50.35

>>975
Obj-C はそういうのも簡単にできる。カテゴリプロパティとか。

982 ：デフォルトの名無しさん：2013/10/27(日) 16:45:02.42

今更新しくもないな
javascriptでインスタンスに後付で関数追加すればこんな感じじゃん

983 ：デフォルトの名無しさん：2013/10/27(日) 19:35:27.56

std::async が c++14 で deprecated になるかもという話を
ちらほら見かけるのだけど、

非同期な処理ガーとかいう話なのか、
スレッドを安全に終了する方法ガーとかいう話なのか、
sort の並列化なんかに使うには adaptive なスレッド生成して work stealing ガーとかいう話なのか、

だれか説明求む。

984 ：デフォルトの名無しさん：2013/10/27(日) 19:56:02.77

http://cpplover.blogspot.jp/2013/10/c11.html
C++とかJavaScriptのような無駄に複雑な言語と付き合ってると人生台なしになりかねなんな
適当でいいよ

といっても全員がそれではいかんというジレンマがあるんだが

985 ：デフォルトの名無しさん：2013/10/27(日) 20:17:25.00

使えない奴は何をやってもダメ
ただそれだけ
例えばC++のせいにするバカとか

986 ：デフォルトの名無しさん：2013/10/27(日) 21:19:32.45

次スレは？

987 ：デフォルトの名無しさん：2013/10/27(日) 21:35:25.18

付き合ってくれる人がいるから一般人は適当できるんじゃね

988 ：デフォルトの名無しさん：2013/10/28(月) 00:51:37.33

30代に入ってから言語仕様の仔細追いかけるのやめたわ
Good Parts適当に抜き出したらもうその範囲しか使わん。

プログラミング言語は道具にすぎないし
プロダクトを作るとか、脳内嫁を大切にするとか
人生にはもっと重要なことがある。

989 ：デフォルトの名無しさん：2013/10/28(月) 01:01:14.10

C++14/C++1y
http://toro.2ch.net/test/read.cgi/tech/1382889622/