13/04/04 20:05:20.33
The C++ Standards Committee
URLﾘﾝｸ(www.open-std.org)
Wikipedia
URLﾘﾝｸ(ja.wikipedia.org)
C++11/C++1y 16
ｽﾚﾘﾝｸ(tech板)
2:はちみつ餃子 ◆8X2XSCHEME
13/04/04 20:13:11.37
>>2 get
3:デフォルトの名無しさん
13/04/04 20:28:02.98
後方互換性を適当に切り捨てた素敵C++来い
4:デフォルトの名無しさん
13/04/04 20:32:55.97
禿が牛耳ってる間は無理だろ
5:デフォルトの名無しさん
13/04/04 20:45:26.00
>>3
Dでいいじゃん
6:デフォルトの名無しさん
13/04/04 20:49:09.66
DはベターCとして使えないから
7:はちみつ餃子 ◆8X2XSCHEME
13/04/04 20:55:37.14
>>6
C の制約を捨てられないなら結局 C++ と似たようなものになるんでないの。
8:デフォルトの名無しさん
13/04/04 21:11:57.40
Cレベルの高級アセンブラとして使えればいいと言うこと
9:デフォルトの名無しさん
13/04/04 21:24:35.64
CレベルでいいならCでいいじゃん
10:デフォルトの名無しさん
13/04/04 23:21:53.98
C++コンパイラでコンパイルできるC++の一部ではない本当のCを必要とする人はどれだけいるというのか？
11:デフォルトの名無しさん
13/04/04 23:29:04.04
・変数を使うときに宣言できる
・//でコメントアウトできる
これだけでC++は神言語だ。
12:デフォルトの名無しさん
13/04/04 23:36:44.25
C99でできるじゃん
13:デフォルトの名無しさん
13/04/04 23:42:47.52
>>12
(;ﾟ△ﾟ)マジでっ！？
でもVC++だとC99対応してないしなぁ。
14:デフォルトの名無しさん
13/04/04 23:42:54.03
それじゃあC++が要らない子になっちゃうじゃん！！ダメだよ！
15:デフォルトの名無しさん
13/04/04 23:47:42.50
C#がちょっとしたGUIツール作るのに便利だということで触ってみたら、
ハットとかいうキモい記号がある時点で拒絶反応が起こった。
そう、C++はこの世でだれよりも速く･･････そして美しい！！
16:デフォルトの名無しさん
13/04/04 23:49:47.70
むしろbetterCが欲しければC99以降を使うように誘導して、betterCとしてのC++の使用は排除していくべき
17:デフォルトの名無しさん
13/04/05 00:23:57.28
C++よりC99/C2011を使うべきという人に、
どうしてC++ではダメなのかの根拠を
ちゃんと説明できた人を見たことがない。
18:デフォルトの名無しさん
13/04/05 00:50:54.37
URLﾘﾝｸ(www.infoq.com)
19:デフォルトの名無しさん
13/04/05 01:28:17.17
>>17
BetterCとしてCでのやり方をそのまま全てC++でも使おうとしてC++ならではのやり方を受け入れず、あるいは公然と否定までして
C++として使っている人との間に争いを起こしたりするのは双方にとってただ不幸でしかないだろ
20:デフォルトの名無しさん
13/04/05 07:39:00.84
もともとC++だったLLVMに続いて
GCCもC++に移行か。
21:デフォルトの名無しさん
13/04/05 09:18:34.92
はやくC#に完全移行しないかな
22:デフォルトの名無しさん
13/04/05 10:52:20.02
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
closeされてるwww
23:デフォルトの名無しさん
13/04/05 11:50:21.71
>>19
C++はCと組み合わせて使えるのが基本的な設計方針。
24:デフォルトの名無しさん
13/04/05 11:54:16.28
P/InvokeでC#からCのDLL呼び出したけど地獄だったぞ
STAThreadで呼び出せれば楽だけどパラメータが多いとシャレにならない
25:デフォルトの名無しさん
13/04/05 12:40:43.42
>>17
C++にはVLA(可変長配列)が無いのでCの方が同じ事を低オーバーヘッドで書ける、とかw
C++11になるまではC99の機能もなかったから、Cを使うべき理由はたくさんあったw
C++は覚えなきゃいけないことが多い(Effective C++レベルの知識が必要とか)ので、
コーディングに気を遣いたくない人はCにしておけとは思うね。
26:デフォルトの名無しさん
13/04/05 13:25:22.78
>>17
単純に速度的なものかと思ってた、
Cの構造体コピー = memcpy
C++クラスコピー = コピコン(メンバー一個一個コピー)
参照とかポインタにしてコピコン減らせるけど、できない部分も出てくるし
C++っぽいプログラムにすればするほどコピコン増える気がする
27:デフォルトの名無しさん
13/04/05 18:27:35.95
memcpyで済むような構造体はPODにすればC++でも一緒だし
それで済まないクラスならCでだって結局コピーに伴って初期化とか色々しなきゃならないと思うんだけど
28:デフォルトの名無しさん
13/04/05 19:15:39.77
だよね
29:デフォルトの名無しさん
13/04/05 19:30:34.91
せやな
30:デフォルトの名無しさん
13/04/05 19:41:39.77
Deep CopyとShallow Copyがなぜ区別が付いてるのか理解出来ない低脳が
住み着いてるようだよな
31:デフォルトの名無しさん
13/04/05 19:52:32.25
ピュアなcで作ったアプリは、ファイルサイズも小さく、利用メモリも小さくすむからそこが利点だと思う。
32:デフォルトの名無しさん
13/04/05 20:18:59.06
Cは演算子は兎も角普通の関数の
オーバーロード位は欲しい所だよね。
性能には関係ないのだから。
33:デフォルトの名無しさん
13/04/05 20:35:19.93
関数テンプレートあるだけでCも相当便利になるような気がするんだが
って言っても今更C使う必然性なんて全然ないか(笑)
34:デフォルトの名無しさん
13/04/05 20:35:51.37
>>22
うわ、つい昨日全部読んだところだった。
よかったｗ
しかし、この記事読むと、ゾッとするね。
非同期プログラミングとか、ソフトウェアの利点を否定してるようなもんだｗ
35:デフォルトの名無しさん
13/04/05 20:35:54.16
そういや C11 に _Generic とかいう型switchが存在してたな。
36:デフォルトの名無しさん
13/04/05 20:52:31.39
なんでもかんでも _ を付ける今のCって
37:デフォルトの名無しさん
13/04/05 20:59:38.97
>>32
ISO/IEC 9899:2011というものがあってだな。
実装したコンパイラ見たことないけど。
38:デフォルトの名無しさん
13/04/05 22:34:51.83
>>36
誰かが使ってるものと被ったら嫌だから
予約語の _大文字 を使うしやないんや・・・
39:デフォルトの名無しさん
13/04/05 23:07:51.22
_Boolとかダサすぎて使う気になれなかった
40:デフォルトの名無しさん
13/04/05 23:15:20.72
#import <stdbool.h>
41:デフォルトの名無しさん
13/04/05 23:18:40.90
stdboot.hもダサい
42:デフォルトの名無しさん
13/04/05 23:19:44.99
#import って何？
43:デフォルトの名無しさん
13/04/05 23:21:09.68
includeの間違いだろう。どう見ても
44:デフォルトの名無しさん
13/04/05 23:30:28.96
>>42
#include の一回しか読み込まない版
45:デフォルトの名無しさん
13/04/05 23:34:53.97
>>44
お前の中ではそうなんだろう
46:デフォルトの名無しさん
13/04/05 23:39:32.46
>>42
Objective-Cの話か？
47:デフォルトの名無しさん
13/04/06 01:07:17.86
ファイルがシンボリックリンクやらハードリンクされてる場合はどうなるの？
48:デフォルトの名無しさん
13/04/06 01:16:04.43
コンパイラ次第です
49:デフォルトの名無しさん
13/04/06 01:43:33.85
下手に規定しない方が実装が自由にやれる
50:デフォルトの名無しさん
13/04/06 01:48:17.10
>>17
C99 の designated initializer はかなり便利
FreeBSD のカーネルコードでガシガシ使ってる
51:デフォルトの名無しさん
13/04/06 02:34:16.78
import == 輸入だす
52:デフォルトの名無しさん
13/04/06 05:30:36.64
>>47
os レベルで処理されるから、多くの場合は普通のファイルと変わらない扱いだろうな
53:デフォルトの名無しさん
13/04/06 08:20:20.35
C++ってCの上にくっ付けた機能がセンス無さ過ぎて...
所詮C人気に便乗したゴミ言語
54:デフォルトの名無しさん
13/04/06 09:03:48.65
>>53
人気に便乗したというよりもともとがcのラッパー(プリプロセッサ)だからね？
すでに存在するものは極力利用するなんていかにもc技術者らしいけどc++のstructとか、言語的欠陥のおかしい部分はそこに引きずられていたという気もしてる。
c/c++の関係は、今でいうjavascriptとtypescriptのような関係だ。
55:デフォルトの名無しさん
13/04/06 12:35:29.62
>>50
初期化といえば、C++にはユーザ定義リテラルがあるぜ。
56:デフォルトの名無しさん
13/04/06 12:38:04.56
>>55
知らないかもしれないけどC++にはコンストラクターがあるんだぜ。
初期化方法をユーザー定義できるんだぜ。
57:デフォルトの名無しさん
13/04/06 12:50:17.73
C++にはデストラクタがある。
これだけでCを捨てるには十分な理由。
58:デフォルトの名無しさん
13/04/06 12:50:21.45
C++は後方互換を切り捨ててコンパクトになれよ
59:デフォルトの名無しさん
13/04/06 13:00:05.91
むしろ今のC++についてこれない奴を切り捨てる方がずっと早いし意義がある
60:デフォルトの名無しさん
13/04/06 13:01:59.87
>>58
Dでいいじゃん
61:デフォルトの名無しさん
13/04/06 13:03:41.01
C++言語はこの世で最も洗練された美しいプログラミング言語だ。
62:デフォルトの名無しさん
13/04/06 13:04:02.95
>>60
今C++以上に混沌としていて仕様の破壊的変更を待っているマゾしかいないのに
63:デフォルトの名無しさん
13/04/06 13:06:01.70
Designated InitializerってC++11に入らなかったんだ。なんで?
VLAが嫌われるのは何となく分かるけど。
64:デフォルトの名無しさん
13/04/06 13:07:32.00
ひとつの言語で低レベルから高レベルまで
全部書けるべきというスタンスが頭悪過ぎて目眩がする
65:デフォルトの名無しさん
13/04/06 13:09:55.52
Cの方がC++との歩み寄りを否定しちゃってるよな
66:デフォルトの名無しさん
13/04/06 13:16:40.74
Cから見ればC++なんて、相互運用可能な
数多ある言語のひとつに過ぎないからね
67:デフォルトの名無しさん
13/04/06 13:19:19.78
>>62
後方互換を捨てるってそういうことだろ？
68:デフォルトの名無しさん
13/04/06 13:34:01.76
>>63
constexprコンストラクタが有れば要らないと判断されたんじゃね
69:デフォルトの名無しさん
13/04/06 13:57:33.50
constexpr は、コンパイル時計算不可の時にエラーを吐くようなオプションが欲しい。
70:デフォルトの名無しさん
13/04/06 14:04:49.90
警告位は出してほしいよな
黙って実行時評価に変更されても
71:デフォルトの名無しさん
13/04/06 14:13:54.65
禿が決めたことには従え
72:デフォルトの名無しさん
13/04/06 15:43:08.46
>>69
gccはその内にできるんじゃない?
73:デフォルトの名無しさん
13/04/06 18:20:44.99
>>61
いや::が醜いわ
74:デフォルトの名無しさん
13/04/07 23:41:12.01
昔はC++には否定的だったけど、JavaやってC++への評価が改まったよ。
75:デフォルトの名無しさん
13/04/08 04:21:12.17
C#やったらC++がクソと思えるようになるだろ
76:デフォルトの名無しさん
13/04/08 04:30:43.01
C#やったけど
こんなに適当に書けていいのかって思ったな
77:デフォルトの名無しさん
13/04/08 07:30:34.13
C#はスレッドが扱いやすい
78:デフォルトの名無しさん
13/04/08 11:23:32.99
BOOST_SCOPE_EXITの代替になるようなものは無いの？
79:デフォルトの名無しさん
13/04/08 13:32:29.51
>>78
言語機能にはないので自動変数のデストラクタを使ってください(BOOST_SCOPE_EXITも基本はそのラッパーマクロです)
80:デフォルトの名無しさん
13/04/08 19:28:53.09
finally実装すれば済むだけな気もするけど
何か難しい問題点があったのだろうか
81:デフォルトの名無しさん
13/04/08 20:45:21.75
デストラクタで賄えって思想なんじゃね
82:デフォルトの名無しさん
13/04/08 20:51:52.49
ゼロオーバーヘッドの原則がイケメンすぐる。
83:デフォルトの名無しさん
13/04/08 21:00:57.66
clangにfinallyが無くてエンバカが慌てたらしいが結局混在出来なくなって
どちらか一方でしかコンパイル出来ないようだ
84:デフォルトの名無しさん
13/04/08 21:22:40.68
>>83
kwsk
85:デフォルトの名無しさん
13/04/08 21:27:24.77
URLﾘﾝｸ(docwiki.embarcadero.com)
こんな感じでC++Builder 64bitはfinallyが使えなくなったんだろ?
で、こういう方向へ
URLﾘﾝｸ(docwiki.embarcadero.com)
>BCC32 では、__try と catch を混在させることができます。
>BCC64 では、try/catch（標準 C++）か __try/__except/__finally（Microsoft による拡張）のどちらか一方でなければなりません。
86:デフォルトの名無しさん
13/04/08 21:29:09.66
あのさぁ、C++Builderとか使ってるやついるの？？
87:デフォルトの名無しさん
13/04/08 21:29:15.77
そもそも例外と構造化例外は違うだろう
88:デフォルトの名無しさん
13/04/08 21:31:21.62
>>85
＞BCC64 は Clang をベースにしています。
へー知らなかった
89:デフォルトの名無しさん
13/04/08 21:32:40.46
マジか。じゃあWindowsでまともなC+11実装が欲しければBCC64を買えと
90:デフォルトの名無しさん
13/04/08 21:41:10.90
>>86
俺
>>87
へ？
>>88
やっとC++11に純粋に対応したが既に時遅し感
CodeGuardも64bitでは使えないし
>>89
そういう事だろうな
91:デフォルトの名無しさん
13/04/08 21:43:46.19
つまりC++BuilderはDelphiのVCLをそのまま使ってるので、どうしても__finallyがいる
それでも対応しきれないライブラリは使えないように殺してしまってるし
clangを使ったのはもちろん手抜きだろう
もう1から64bitコンパイラを作るだけの企業体力が残ってないんだろ
92:デフォルトの名無しさん
13/04/08 21:53:17.39
一から作るのなんて単なる無駄では...
93:デフォルトの名無しさん
13/04/08 21:54:44.94
ロマンはある。
94:デフォルトの名無しさん
13/04/08 21:54:52.96
ではなぜMSは1から作るんだ？
そこに他にはない商品価値があるからではないか？
95:デフォルトの名無しさん
13/04/08 21:57:01.60
MSでさえなんでも一から作らずにOSS使ってるよ。
96:デフォルトの名無しさん
13/04/08 22:05:47.77
ときどきGPLを混ぜてやらかすからな
97:デフォルトの名無しさん
13/04/08 22:59:36.76
会社ごと買い取って自社製品として売り出すなんてこといつもやってるじゃん
98:デフォルトの名無しさん
13/04/09 00:15:03.38
C++11はそろそろ安定して仕事に使っても大丈夫な感じなんだろうか
まだ不安でC++03のままなんだけど(boost経由で知らない間に使ってるかもしれないけど)
99:デフォルトの名無しさん
13/04/09 00:20:46.74
g++オンリーなら使えなくもないレベル
thread_localがないとか若干微妙だが、概ね実装されてる
VC++はまだまだ糞
100:デフォルトの名無しさん
13/04/09 00:33:54.60
gcc は↓がダメというわけわからんバグがあるから
ラムダはちょっと怖い。今のところ問題ないけど
int main()
{
int x = 0;
[&]{ try {} catch(...){ x; } }; // NG
[&]{{ try {} catch(...){ x; } }}; // (OK)
}
101:デフォルトの名無しさん
13/04/09 00:37:01.89
4.6.0 だと大丈夫だった
4.7.x だとエラーになるのか
102:デフォルトの名無しさん
13/04/09 00:48:32.60
出た。50歩100歩のGCC信者。
gnu自信がexperimentalって言ってるのに
msに無くてgccにある機能を見つけて
msを批判しないと
精神の安定が保てないんだね。
URLﾘﾝｸ(gcc.gnu.org)
103:デフォルトの名無しさん
13/04/09 05:25:05.80
VCに限っては批判されてもおかしくはない
それくらい酷い状態
104:デフォルトの名無しさん
13/04/09 05:26:35.66
お前等C++11なんてクソ言語を実装させられる身にもなってみろよ
105:デフォルトの名無しさん
13/04/09 06:15:12.08
もうC++は諦めろよ・・・いい加減
いつまで老害になる気だよ
106:デフォルトの名無しさん
13/04/09 08:36:21.77
このままだとC++03がいつまでも標準なままだな
107:デフォルトの名無しさん
13/04/09 10:35:02.13
c11みたいにGCCにすら相手に
されない言語に比べたらc++11は
はるかにマシ
108:デフォルトの名無しさん
13/04/09 10:47:40.92
ハァ？ GCCは（Clangも）C11ほぼ全部実装してるだろ
Appendixはそりゃ実装してないけど
109:デフォルトの名無しさん
13/04/09 10:54:32.24
あ、ごめん。Appendixじゃない。Optional featureのことね。
110:デフォルトの名無しさん
13/04/10 00:45:11.39
>>108
_Genericとかthread.hあったっけ？
111:デフォルトの名無しさん
13/04/10 02:23:46.16
_Genericはあるだろ、自分で確認しろよそのくらい
thread.hはOptional
112:デフォルトの名無しさん
13/04/11 19:58:37.92
どこかのサイトに、fstreamはfopenよりもパフォーマンス的に良くないと書いてあったんだけど、どうして？？
fstreamはfclose的なものがないから好きなんだけどなぁ。
113:デフォルトの名無しさん
13/04/11 20:02:43.84
メンバ関数にclose()はあるけどな
時々使わなくてはいけない時もある
通常はスコープが外れるとデストラクタでclose()呼び出すけどな
114:デフォルトの名無しさん
13/04/11 20:05:15.30
>>112
URLﾘﾝｸ(d.hatena.ne.jp)
もしかしてこういう奴か
115:デフォルトの名無しさん
13/04/11 20:08:07.88
>>113-114
そんなこた>>112は知ってんだろうから
質問に答えてやったらどうだ？
116:デフォルトの名無しさん
13/04/11 20:09:06.85
何言ってんだこの馬鹿
117:デフォルトの名無しさん
13/04/11 20:12:04.08
お前が答えてやれやカス
118:デフォルトの名無しさん
13/04/11 20:25:15.03
iostreamは「いくらお前等が信者でも
iostreamがクソだと気付よ」
というメッセージが込められている。
だから実装もわざと遅くしてある。
それに気づくかどうかを試す
禿のトラップなんだよ
119:112
13/04/11 20:40:18.57
>>114
そこではなかったんだけど、どっかのブログに書いてた。
しかし、こんなにも差が出るんだなぁ。
stdio.hのファイル入出力使う場合、
fscanfが重宝するんだけど、
ifstream（operator >>）よりは速いかなぁ。
>>118
そうだったのか！！
120:デフォルトの名無しさん
13/04/11 20:42:32.04
そんなことわざわざするか。タコ
121:デフォルトの名無しさん
13/04/11 20:51:18.04
iostreamなんて必要ないよ。
122:デフォルトの名無しさん
13/04/11 21:29:23.06
速度が必要な所ではそもそもAPIを使う
123:デフォルトの名無しさん
13/04/11 22:28:51.00
shared_ptrのカスタムデリータにfclose登録しとけばいいじゃない
124:デフォルトの名無しさん
13/04/11 22:36:28.10
そんなクソなコードはメンテしたくない
125:デフォルトの名無しさん
13/04/11 22:42:52.03
明示的にcloseする必要が無いならcloseなんかしなくてもいいじゃん
だって、closeするのはそこでcloseされてないと困る場合だろ。
どうでもいいならプログラム終了までほっとけばいい。
126:デフォルトの名無しさん
13/04/11 22:53:09.51
ロックしっぱなし、内容フラッシュされないままで放っておくのかよ
127:デフォルトの名無しさん
13/04/11 22:54:13.68
>>125
>明示的にcloseする必要が無いならcloseなんかしなくてもいいじゃん
開く処理と同じスコープを抜けるときに
クローズしたいことは
極めてよくあることですが。
明示的に書くと漏れる恐れがあるから
デストラクタに任せるのも
極めてよくあることです。
128:デフォルトの名無しさん
13/04/11 22:55:42.30
>>125
こいつ最高にアホ
129:デフォルトの名無しさん
13/04/11 23:02:49.16
きっとクローズ処理のエラーハンドリング
の厳密性を重視しているのだろう。
そうに違いない。
130:デフォルトの名無しさん
13/04/11 23:02:50.53
バカチョン発狂
131:112
13/04/11 23:06:25.83
>>122
APIもいいか･･･。
>>123
そうか！
カスタムデリータ、ほんと便利だ。
COMプログラミングでもRelease自動でやってくれる。
神。
132:デフォルトの名無しさん
13/04/11 23:10:11.77
クローズしないと他のソフトに迷惑でしょ
133:デフォルトの名無しさん
13/04/11 23:25:42.15
書き込んだ場合のfclose()は、ちゃんと戻り値チェックしろよー
お約束だろ？
134:デフォルトの名無しさん
13/04/11 23:50:12.99
してませんが
135:デフォルトの名無しさん
13/04/11 23:56:47.74
fcloseがエラー返してもどうしようもないですしおすし
まあログくらいはできるが
136:デフォルトの名無しさん
13/04/12 00:54:19.27
streamは例外飛ばすオプションがあるからそれを利用する手もあるな
137:デフォルトの名無しさん
13/04/12 06:35:22.05
書き込み後のファイルクローズに失敗したという事は、出力ファイルの内容が信頼できないという事だから、そのファイルは破棄するべき。
直接上書きとかしているとできないだろうけれど、テンポラリーファイル作ってrenameするという手順とっておけば問題ない。
138:デフォルトの名無しさん
13/04/12 07:04:01.04
デストラクタ信者はエラーは握りつぶして良いという
強い強い信念をもっている
だってデストラクタから例外投げるとカオスになるから
139:デフォルトの名無しさん
13/04/12 07:09:48.68
デストラクタからでも例外投げればいいじゃない
死ぬだろうけど
140:デフォルトの名無しさん
13/04/12 07:09:54.32
↑&↑↑アホ
141:デフォルトの名無しさん
13/04/12 07:12:16.74
↑マヌケ
142:デフォルトの名無しさん
13/04/12 07:13:09.10
デストラクタで起こるリソース破棄時の
問題は頭が痛い。
だが元の>>125がそれを気にしていたかというと
恐らく違うだろう
143:125
13/04/12 13:26:20.49
俺が言ってるのは明示的にcloseする必要の無いときの話だから。
どうでもいいならcloseなんかしないでほっておけばいいし、
そこでやる理由があるならやればいい(closeを呼ぶとか
そこでデストラクタが呼ばれるようにするとか)。
144:デフォルトの名無しさん
13/04/12 13:35:14.43
何か結構怖い感覚でプログラム書いてくれちゃってるなあ
こいつには仕事任せたくないわ
145:デフォルトの名無しさん
13/04/12 14:01:15.30
>>144
逆に聞きたいんだけど、どこでcloseする必要があるかを検討せずに
プログラムを作ることがあるの?
146:デフォルトの名無しさん
13/04/12 14:07:59.75
あれれ？言ってる事が違って来てますね
147:デフォルトの名無しさん
13/04/12 14:10:41.21
なんで?
明示的にcloseする必要があるか検討せずに分かるの?
どうでもいいならしなくてもいいと言ってるんだけど。
148:デフォルトの名無しさん
13/04/12 14:50:53.20
動作中にハングアップするだの停電になるだので
ファイル吹っ飛ばしたことが無い幸せな人なんだろうなぁ
149:デフォルトの名無しさん
13/04/12 15:57:19.48
UPSも付けないアホが安全性について語ってるぞ
150:デフォルトの名無しさん
13/04/12 15:58:42.78
closeしたからといって停電とかに対して安全な状態になるわけじゃないからね
151:デフォルトの名無しさん
13/04/12 16:19:43.22
>closeしたからといって停電とかに対して安全な状態になるわけじゃないからね
152:デフォルトの名無しさん
13/04/12 16:26:50.93
ハングアップするプログラムをリリースしちゃうような人の頭の中はこんなもん
153:デフォルトの名無しさん
13/04/12 16:32:39.99
ここの人たちはスレ違いな話をしてる間だけは幸せなんだろうな、、、
154:デフォルトの名無しさん
13/04/12 16:32:56.93
11スレでこんなネタ話されてもなー
使い回すならともかく、使用しなくなった時点で閉じるのが普通じゃない？
155:デフォルトの名無しさん
13/04/12 17:13:16.05
やっぱり言語って
みんなが入り込んで規格決めると肥大化してクソになるんだな
C++は完全に終わったわ
156:デフォルトの名無しさん
13/04/12 17:17:53.43
終わってない言語なんてあるの？
157:デフォルトの名無しさん
13/04/12 17:21:40.13
実際closeなんてファイルディスクリプタの回収ぐらいの意味しかないぜ
ディスクにきっちり書き込まれることを保障したいならそれ用の関数呼んどけ
158:デフォルトの名無しさん
13/04/12 17:52:49.40
日本語の話者は大概がクソ以下
159:デフォルトの名無しさん
13/04/12 19:55:52.48
>なんで?
>明示的にcloseする必要があるか検討せずに分かるの?
>どうでもいいならしなくてもいいと言ってるんだけど。
↑キチガイage
160:デフォルトの名無しさん
13/04/12 20:24:45.93
この話題何回目だよ
「解法に失敗しうるものでRAIIすんな」でFAだろ
161:デフォルトの名無しさん
13/04/12 20:39:01.60
そう言ってるのはお前だけ
自分が正しいと思うなら少数派の異常者と思われても自分だけでそれを貫けばいい
自分の言うことが正しいとみんなに認められるまでことあるごとに話題にしようとするな
162:デフォルトの名無しさん
13/04/12 20:44:01.32
貫けばいいとかアホかと
納得がいく結論が出ないソフトウェア工学ならいらない
163:デフォルトの名無しさん
13/04/12 21:20:30.94
>>160
それだと大抵のリソースはRAIIで扱えなくなって
やっぱC++ウンコじゃんって話になるので
信者にとって非常に都合が悪い
164:デフォルトの名無しさん
13/04/12 21:35:32.25
ヒープは扱えるんだからそれで十分だろ
165:デフォルトの名無しさん
13/04/12 21:43:56.35
つか、close だって失敗してもどうしようもないよな。
166:デフォルトの名無しさん
13/04/12 21:44:04.17
扱えない大抵のリソースってなんだよ
167:デフォルトの名無しさん
13/04/12 21:52:43.31
解放時エラーは全て握りつぶす
その覚悟無き軟弱者にRAIIは扱えない
168:デフォルトの名無しさん
13/04/12 22:07:41.43
FAはこっち
「明示的解放が必要なリソースはRAIIで扱え
解法の失敗を考慮する必要があるならデストラクタでの解法はミスや異常時の保険としておき
デストラクタによらない解法処理を自前で行え」
169:デフォルトの名無しさん
13/04/12 22:36:28.34
>>166
newとmallocで取ったヒープ以外のほぼ全て
170:デフォルトの名無しさん
13/04/12 22:51:26.45
>>165
それがおかしい。
closeに失敗したのだからエラー処理としてロールバック処理をするべきだろう。
ファイルの中身が壊れていてもかまわないというなら話は別だけどな。
closeをチェックする癖付けとかないと、NFS扱い始めたとき、原意不明の障害調査やる羽目になるぞ。
ローカルディスクならほとんど発生しないと思うけど。。。
171:デフォルトの名無しさん
13/04/12 23:05:55.37
>>170
おかしいかどうかはアプリケーション次第だよ。
君のイメージは書き出しみたいだけど、読み出しなら失敗自体が稀だし、失敗したところで別に困らないし、何もできない。
172:デフォルトの名無しさん
13/04/12 23:40:59.49
どうしてreadだけに絞った？
おかしいのは君の姑息な心理操作の方だよ
173:デフォルトの名無しさん
13/04/12 23:48:03.97
>>169
ファイルの他に何があるの？ほぼ全てって言うぐらいなら２，３個軽く挙げられるよね？
174:デフォルトの名無しさん
13/04/13 03:33:10.75
ストリーム
データベースコネクション
スレッド
プロセス
ハンドル
175:デフォルトの名無しさん
13/04/13 06:52:23.77
>>171
表現の違いか。
それはなにもできないのじゃなく、する必要がないだけ。
176:デフォルトの名無しさん
13/04/13 10:57:55.48
する必要がないはしなくて良いにはならない
表現の違いという落としどころに落としたいんですね可哀想ですね
177:デフォルトの名無しさん
13/04/13 12:30:24.27
まぁ今時のOSならプロセスが正常終了すればたいてい後片付けしてくれる
正常終了すれば
178:デフォルトの名無しさん
13/04/13 13:03:03.02
突然話飛ばした？
179:デフォルトの名無しさん
13/04/13 13:09:09.09
面倒くさいから、ハードウエアリセット
えぇ、うちの会社の数千万円の装置です
180:デフォルトの名無しさん
13/04/13 13:28:52.88
億行ってる装置でも再起動させるんだから全然問題ないな
181:デフォルトの名無しさん
13/04/13 13:37:51.63
無能な開発のケツを運用が拭けばいいだけの話だな
182:デフォルトの名無しさん
13/04/13 15:35:08.93
↑まともな開発を不可能にする無能すぎる営業が背伸びしてPG板に来ちゃいました？
183:デフォルトの名無しさん
13/04/13 16:42:33.94
発狂パーティーを開催いたします
184:デフォルトの名無しさん
13/04/13 20:28:25.02
C++で常時起動型のサーバープログラムを
書いてはいけないんですねわかります。
だからプロセス終了とか言っちゃうんですねﾌﾟ
185:デフォルトの名無しさん
13/04/13 20:31:13.86
大丈夫だよ週次リブート()とかするから
186:デフォルトの名無しさん
13/04/13 20:58:59.50
linux daemon全否定w
187:デフォルトの名無しさん
13/04/13 21:54:55.64
ここの人たち技術ないから
188:デフォルトの名無しさん
13/04/13 22:16:51.32
RAIIに技術?
189:デフォルトの名無しさん
13/04/14 00:04:39.90
なんでRAII限定にしたのか知らないけど常時起動型のサーバープログラムを落とす技術
190:デフォルトの名無しさん
13/04/14 10:36:28.81
C系はメモリ破壊の可能性を否定できないからな。
キチンと試験して稼働実績の有るプログラムでも
新人が加えた一文字のスペルミスで
既存部分のメモリが破壊されて火を噴くから、
プロセス分割したり短時間で終了するような
ウンコ設計にしないと、
精神論だけでは品質を保てないウンコ言語。
191:デフォルトの名無しさん
13/04/14 10:43:56.90
使えん新人１００人より
優秀な奴5人の方が生産性高いと思うぞ
192:デフォルトの名無しさん
13/04/14 11:14:05.85
最初はみんな新人さ。
193:デフォルトの名無しさん
13/04/14 11:31:10.84
"C++0x Concepts Should Stay Dead" -- Bjarne Stroustrup
194:デフォルトの名無しさん
13/04/14 11:53:28.15
conceptがC++がプログラミング言語の世界に出来る最大の貢献だと思うがな。
generic programmingの集大成だろう。
195:デフォルトの名無しさん
13/04/14 12:45:31.75
>conceptがC++がプログラミング言語の世界に出来る最大の貢献
Javaのインターフェースの劣化版コピーだと
思っとりました。
196:デフォルトの名無しさん
13/04/14 12:50:27.31
>>195
もしかしてtraitsも知らないの?
traitsの時点でJavaのinterfaceとはぜんぜん違うだろ。
197:デフォルトの名無しさん
13/04/14 12:51:27.26
えっ？
198:デフォルトの名無しさん
13/04/14 12:52:01.85
>>195の意味がわからん
199:デフォルトの名無しさん
13/04/14 13:03:59.14
寝言だろ
気にするな
200:デフォルトの名無しさん
13/04/14 13:15:39.44
Javaは同じSunにいたSelfグループのtraitとmixinに対する成果をうまく取り入れられてない。
201:デフォルトの名無しさん
13/04/14 13:30:26.27
もしかしてConceptsって単語をconceptのことだと勘違いした？
202:デフォルトの名無しさん
13/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:デフォルトの名無しさん
13/04/14 13:41:47.00
インヘリタンスは分かれよ。
204:デフォルトの名無しさん
13/04/14 14:06:37.40
むしろインヘリタンスと何の区別が付かんのだろw
205:デフォルトの名無しさん
13/04/14 14:14:43.39
バカっぽいんだけど妙に面白い事言うやつっているよね
206:デフォルトの名無しさん
13/04/14 14:41:30.99
C++のtraitsはクラス書かないでも
traitsをユーザ定義して型をどうマッチさせるか記述できる。
207:デフォルトの名無しさん
13/04/14 15:11:36.28
C++0x concept には死んで貰って、concept lite に生まれ変わるという話。
208:デフォルトの名無しさん
13/04/14 15:20:29.09
concept liteはあくまで繋ぎでしょ
209:デフォルトの名無しさん
13/04/14 15:59:41.12
>>208
その辺も含めて >>193 の表題の文章に書いてある
210:デフォルトの名無しさん
13/04/14 16:43:03.96
早く当初の構想どおりの完全版conceptが
現実にならないものかね。
211:デフォルトの名無しさん
13/04/14 16:45:05.56
またtemplateでの黒魔術が増えるの？
212:デフォルトの名無しさん
13/04/14 17:42:13.50
>>211
template 周りのコンパイルエラーで出てくる謎の暗号を解読しなくてよくなる
213:デフォルトの名無しさん
13/04/14 17:59:08.71
ほう
214:デフォルトの名無しさん
13/04/14 23:09:59.88
日本語の解説本って、いつになったら出るの？
215:デフォルトの名無しさん
13/04/15 01:08:22.12
Boost C++ Libraries プログラミング 第3版に期待するべ
216:デフォルトの名無しさん
13/04/15 01:24:13.37
それは11の解説書としては使い物にならないだろ
217:デフォルトの名無しさん
13/04/15 01:33:38.91
解説なんてその辺の解説サイトでいいでしょ。
仕様を正しく理解したいなら原文しかないぜよ。
218:デフォルトの名無しさん
13/04/15 01:38:06.83
疑問点があればここではなく、Stack Overflow で質問するといい。
219:デフォルトの名無しさん
13/04/15 01:53:20.81
Stack Overflow質問文テンプレ
「初心者です(_*_)。右辺値参照って何ですかぁ？
調べたけどさっぱりですぅ☆
エロい人宜しく(^^)/
あ、答えられない人のレスはお断りです(ﾌﾟｹﾞﾗ
220:デフォルトの名無しさん
13/04/15 02:22:19.91
>>219
はっはっは。元気があっていいね。頑張るんだよ。
221:デフォルトの名無しさん
13/04/15 02:27:33.28
日本語じゃないので☆1つ
222:デフォルトの名無しさん
13/04/16 00:18:44.22
>>191
しかしその優秀な人たちは管理業務にまわされます。
223:デフォルトの名無しさん
13/04/16 01:25:53.28
日本のキャリアパスにシニアプログラマってあまりないからな
224:デフォルトの名無しさん
13/04/16 02:52:46.46
未経験の若いプログラマ雇って炎上みたいなのばかり
225:デフォルトの名無しさん
13/04/16 03:24:29.66
>>202
クックック... 我はinheritanceの使い手にして最凶のinterface、
我が道を阻むことなどたとえabstract classでもできはせぬわ
このスレの住人供よ、Light-weight processなど捨てて我が軍門に下るがよいわ
俺もよくわからんけど、多分このへんの単語考えた外人は中二病なんだろうと思うよ。
「俺の考えた呼び方の方がかっけーし」見たいな感じで
クラウドとかも内輪ではめっちゃ受けてるのかもしれん
226:デフォルトの名無しさん
13/04/16 23:52:19.27
>>224
出来るヤツだけ集めても
なぜかうまくいかないのが
プロジェクトと言うもの・・・
227:デフォルトの名無しさん
13/04/17 00:35:42.00
まとめるとプロジェクトは失敗するもの
228:デフォルトの名無しさん
13/04/17 00:59:50.26
JISのC++11って何巻目になるん？
1冊1万前後だから結構な出費だな
229:デフォルトの名無しさん
13/04/17 07:30:48.76
>>227
まとめすぎｗｗｗ
230:デフォルトの名無しさん
13/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
13/04/17 08:39:56.70
ID3D11xxx* p = pD3D11xxx.get();
Func( &p );
ってしたらコンパイルは通ったけど、
もっとエレガントにできないかなぁ。
232:デフォルトの名無しさん
13/04/17 08:41:29.81
CComPtrを使えばよろし
233:230
13/04/17 08:59:24.88
>>232
CComPtrなら大丈夫なんですね。
しかし、できればATLに依存したくないんです。
234:デフォルトの名無しさん
13/04/17 09:04:19.90
ポインタのポインタを受け取るってことはポインタ自体の変更が行われるわけで
ID3D11xxx* p;
Func(&p);
pD3D11xxx.reset(p);
こんな風にするしかないだろう
235:230
13/04/17 09:20:06.70
>>234
ありがとう！
ああ、そうか。
面倒くさい。死にそう･･･。
調べてみると、どうもATLとは違うMicrosoft::WRL::ComPtrというのがあるみたい。
URLﾘﾝｸ(msdn.microsoft.com)
なぜATLがイヤかというと、
まず開発がVC++のExpress（無料）バージョンが使えないこと。
自分はPro持ってるけど、他人にプロジェクトを渡すことがあって、
できれば相手にProを強要したくない。
あと、コンパイルした.exeを配布する際、
ATLを使用していると、ランタイムのインストールをユーザーに強要することになる。
WRLだとどうなんだろうか？
開発的にはExpress（for Windows8だけど）で使えることが調べて分かった。
あとは.exeを配布するときにユーザーがWRLのための追加インストールが必要か。
こういうのってどうやって調べたらいいの？
DependencyWalkerとかでチェックしかないかな。
236:デフォルトの名無しさん
13/04/17 09:27:56.32
>>235
ATLは古いのならWDK7.1辺りに入ってたりする
CComPtrはテンプレートなんだからランタイムも糞もないぞ
237:デフォルトの名無しさん
13/04/17 09:32:01.68
WTL?
238:230
13/04/17 09:59:29.69
早速WRLのComPtr使ってみた。
余計なコードが激減した。
感動した。
さっきまで悩んでたのがあほみたいだ。
もう他人のことなど知るか（おい）
>>236
ありがとう！
安心した。
239:230
13/04/17 10:07:14.80
少し気になったのは、
同じダブルポインタ引数でも、
Create系では&pって渡せるのに、
他の関数ではp.GetAddressOf()で渡さないといけないこと。
後者を&pで渡したらぶっ壊れた。
まぁ、Create系もGetAddressOf()でいけるから、
これで統一しておくほうが無難かな。
240:デフォルトの名無しさん
13/04/17 10:10:33.16
またひとりC++/CXの魔境に旅立ってしまったか
241:デフォルトの名無しさん
13/04/17 10:14:10.97
URLﾘﾝｸ(msdn.microsoft.com)
日本語おかしいがちゃんと違いが書いてあるじゃない
242:230
13/04/17 10:22:51.60
>>241
あ、すんません･･･。
ああ、そういうことか。
参照カウントのこと意識せんといかんのね。
しかし、Create系以外でダブルポインタを引数に取るとか、
ややこしいからやめてくんないかなぁ･･･。