18/12/28 06:06:22.84 ufThBpcD.net
c++builder10.3 community
IID_PPV_ARGSを使わない場合どうしたら良いか教えてください
何を入れたら良いのかわからないです
#include <windows.h>
#include <tchar.h>
#include <shlobj.h>
#include <shellapi.h>
#include <commoncontrols.h>
void __fastcall TForm1::Button1Click(TObject *Sender) {
IImageList *piml;
SHGetImageList(SHIL_JUMBO, IID_IImageList, (void**)&piml);// pimlがNULLになる
SHGetImageList(SHIL_JUMBO, IID_PPV_ARGS(&piml));// 成功
}
3:デフォルトの名無しさん
18/12/28 07:22:25.34 br5v3uv4.net
わけのわからん言語をこねくり回して、つまらんことしてちゃ、つまらん。
4:デフォルトの名無しさん
18/12/28 11:40:52.89 sicn3fFV.net
O2
5:デフォルトの名無しさん
18/12/28 11:42:24.93 VQYieTPu.net
つまんね
6:デフォルトの名無しさん
18/12/28 11:48:00.87 e5XGwJ2H.net
>>997
UTF-8 は char * に入れるもの
char32_t * ならぎりぎりセーフ
wchar_t * は wcs 用
UTF-32 を wchar_t * に入れる
7:デフォルトの名無しさん
18/12/28 12:09:16.93 qtS4fp6w.net
utf8は漢字仮名に3バイト使ってることわかってんのか
処理を簡単にするためいったんwchar_t使うのは普通のこと
でなければ文字数のカウントすら文字コードを調べる羽目になる
8:デフォルトの名無しさん
18/12/28 12:17:53.33 sicn3fFV.net
その用途ならchar32_t*ってことじゃね
9:デフォルトの名無しさん
18/12/28 12:21:31.54 I8tv0Dcv.net
調べる羽目になるっていうけど、たったそれだけのことでしかない
当然、パフォーマンス的に最適な方法は場合による
10:デフォルトの名無しさん
18/12/28 13:36:08.91 qtS4fp6w.net
>>8
c++17は調べてないが、
char32_tだと文字列処理のライブラリも正規表現も使えないだろ。
既存のライブラリ使うためにまた変換するのか？
>>9
たったそれだけて、文字列処理なんか主たる作業じゃないC/C++プログラマにとっては、
utf8の文字コード常に思い浮かべながらコーディングするなんてのは不快極まるだろ。
*x == 'あ'
これが書けないことがたったそれだけかよ
11:デフォルトの名無しさん
18/12/28 13:40:58.79 VQYieTPu.net
endian でドツボですねわかります
12:デフォルトの名無しさん
18/12/28 13:46:43.01 qtS4fp6w.net
そもそもchar32_tてutf32用だろwwww
13:デフォルトの名無しさん
18/12/28 14:07:56.51 e5XGwJ2H.net
判ってないなお前
14:デフォルトの名無しさん
18/12/28 22:03:45.49 n6DxUiN/.net
このなかで一番美人なのって真ん中だよね？深キョンレベルだと思うのだが
ちなみに向かって右は目も鼻も整形してるって本人が公言してるけどそれ抜きにして誰が一番美人だと思う？
URLﾘﾝｸ(bigsta.net)
15:デフォルトの名無しさん
18/12/29 09:44:06.88 ixKuXlJx.net
VSだとwchar_tは16ビットだろ。
だから3バイト以上/文字あるutf8だとおいしくもなんともないが、
unixは32ビットなんで、シェル出力をfgetwsでwchar_tで受け手、時にwstringで処理すると、
fgets->charより格段に楽に処理できる場合がある。
環境依存であんまり人に推奨できないだろうけど、unix, gcc限定なら正しく処理できる
もちろんwslでも使える
16:デフォルトの名無しさん
18/12/29 12:44:13.02 EK4sWEwk.net
次から次へと嘘を並べるのがウリナラ
密漁船を捜索中だった→密漁船は既に発見し救出中(実際は瀬取り中？)だった
レーダーは水平以下へ照射していた→上空へレーダー飛んだのはなぜ
機体は真上を飛んでいた→実際は1km以上遠方だった
カメラを向けただけで照射はしていない→レーダーも回転して対面していた
17:デフォルトの名無しさん
18/12/29 13:22:25.41 Ol/xTs6w.net
環境：Win10/VC++2015
WinSockでマルチキャスト受信のプログラムを作っているんですが、
マルチキャスト送信している別PCとの接続において、
以下のケース2の挙動に困っています。
■ケース1（期待する挙動）
LANケーブルが接続されている状態で受信ソフト起動
⇒ recvfrom()で受信する
⇒ LANケーブルを抜く
⇒ recvfrom()がブロックする
⇒ LANケーブルを挿す
⇒ recvfrom()がデータを受信し、ブロックが解除される
■ケース2
LANケーブルが接続されていない状態で受信ソフト起動
⇒ recvfrom()がブロックする
⇒ LANケーブルを挿す
⇒ recvfrom()はブロックしたまま、いつまで経っても解除されない
（受信＆ブロック解除してほしい）
なぜrecvfrom()はブロックされたままなのでしょうか？
18:デフォルトの名無しさん
18/12/29 13:25:48.49 EK4sWEwk.net
selectしてないから
19:17
18/12/29 13:51:03.81 Ol/xTs6w.net
>>18
selectは「複数ソケットのとき」という先入観があったのですが、
1ソケットのときでも使うんですね。
ありがとうございました！
20:デフォルトの名無しさん
18/12/30 13:06:57.06 bhbCdqKe.net
gccでしか確認してないが、warningは出るんだが
前にu8をつけない'あ' は int (4バイト)展開されるんだな
u8つけてしまうと下位1バイトしか処理されないんで正しく処理されない。
wchar_t buf[0x100];
としとくと
buf[i] == L'あ'
ではwarningすらでない.
21:デフォルトの名無しさん
18/12/30 16:05:04.48 FqO1nm3e.net
文字リテラルにu8プレフィックスは使用できない。
22:デフォルトの名無しさん
18/12/30 16:10:42.14 kRHvhG4M.net
【ＴＯＫＩＯがまた被曝を応援】 「不勉強」「操られている」のはローラではなく、安倍と食事した奴
ｽﾚﾘﾝｸ(liveplus板)
23:デフォルトの名無しさん
18/12/30 16:13:30.28 Y/PcKL5Q.net
URLﾘﾝｸ(cpplover.blogspot.com)
24:デフォルトの名無しさん
18/12/30 16:43:37.53 bhbCdqKe.net
>>21
いったいいつの時代の話してるんだ古すぎるんだよ情弱
C++17から問題なく使用できる
25:デフォルトの名無しさん
18/12/30 16:50:02.84 bhbCdqKe.net
情弱がねごとほざくからそのたんびにイラン労力強いられることとなる
ちったぁ情報収集してこいよダニ
26:デフォルトの名無しさん
18/12/30 16:50:18.97 bm6ZOgnS.net
どうせだったら、utf8専用のchar8_t型も用意しといてくれたら良かったのに。
ascii文字圏の連中にはどうでもいいことなんだろうけどw
27:デフォルトの名無しさん
18/12/30 23:19:20.59 +xBVE+bB.net
教えてください。
C++のvectorについてです。
あるvectorの要素を自分自身に追加したいとき、どうすればよいのでしょうか。
例えば、v.push_back(v[2]);のようなことをしたいのです。
28:デフォルトの名無しさん
18/12/30 23:25:38.38 fEPs2N4H.net
それでいいんじゃね？
29:デフォルトの名無しさん
18/12/31 07:35:40.55 fsnZuStD.net
>>27
それ以外の何を望むの?
特定場所への挿入v.insertぐらいしかないじゃん
30:デフォルトの名無しさん
18/12/31 07:57:31.16 kcuDnRZu.net
27です。レスありがとうございます。v.insertでうまく行きました。
v.push_back(v[i])だとなぜか空の要素が追加されてしまい、困っていました。
31:デフォルトの名無しさん
18/12/31 08:53:01.66 Ls1ZsSUM.net
>>27
URLﾘﾝｸ(stackoverflow.com)
32:デフォルトの名無しさん
18/12/31 09:18:55.86 Ls1ZsSUM.net
>>30
まともなpush_backの実装なら対策されているので問題ないはず。
無対策でも明示的にコピーコンストラクタを呼べばうまくいかくも。(要素の型をTとする)
v.push_back(T(v[2]));
33:デフォルトの名無しさん
18/12/31 09:25:50.67 rwDIj1dr.net
あ～そういうことか
俺もハマりそうだなそれ
でもそれはvectorの実装側の責任になるか
34:デフォルトの名無しさん
18/12/31 10:05:21.41 fsnZuStD.net
>>27
意図しないエレメントが追加されてしまうC++は何？バージョンも併せて教えてよ
35:27
18/12/31 10:10:54.60 kcuDnRZu.net
環境書くのを忘れてました。すみません。
Win7、Visual Studio 2008です。
36:デフォルトの名無しさん
18/12/31 10:19:59.32 fsnZuStD.net
>>32
まともでない実装ってのはどのテンプレート？つかコンパイラ？
37:デフォルトの名無しさん
18/12/31 10:27:09.66 fsnZuStD.net
>>35
thx
なるほど10年前のコンパイラならstlにバグ残ってる可能性あるわな
2011、2014、2017でずいぶん新しくなってるよ
仕事で2008指定されてるとかじゃなければ2017入れて損することあんまないと思うけど
38:デフォルトの名無しさん
18/12/31 10:27:22.88 Ls1ZsSUM.net
さすがにvectorではまともでない実装にお目にかかったことはない。
VisualStudio2010のMFC独自コンテナCArrayで同じ問題ではまったことがあっただけ。
39:デフォルトの名無しさん
18/12/31 11:04:33.38 .net
マジかよ MFC 最低だな！
失望しました。WPF 使うの止めます
40:デフォルトの名無しさん
18/12/31 11:44:30.10 zd5ZDQG6.net
vsに2011ってのもあったのか、いやあ勉強になるなぁ
41:デフォルトの名無しさん
18/12/31 11:46:37.75 sEEumFv8.net
C++の規格と混同しているっぽい。
42:デフォルトの名無しさん
18/12/31 11:58:04.83 fsnZuStD.net
C++の規格の話
43:デフォルトの名無しさん
18/12/31 12:28:15.56 .net
つまり江添亮の話
44:デフォルトの名無しさん
18/12/31 20:39:25.62 kcuDnRZu.net
>>31
参考になりました。ありがとうございます。
45:デフォルトの名無しさん
19/01/01 03:54:37.57 vBi+DP3M.net
元日記念カキコ
46:デフォルトの名無しさん
19/01/01 15:38:58.76 tgQbht6s.net
gnuのobstackってざっくり理解するなら普通にデータ構造としてのstackのいち実装って認識であってますか？
47:デフォルトの名無しさん
19/01/01 17:39:02.76 i/vicifv.net
うん
48:
19/01/01 18:06:26.08 kK3EzG3m.net
はっキネン
49:デフォルトの名無しさん
19/01/03 02:16:07.41 oIrbeINi.net
Privateにメンバ関数を置くのって別にいいですか？
50:デフォルトの名無しさん
19/01/03 02:25:02.88 rCo9hP60.net
いいんじゃね？
そのクラスの中のみでよく使われる関数とかprivateにする
51:
19/01/03 03:52:58.78 moS/XERj.net
zen2 5GHz が来た！
URLﾘﾝｸ(wccftech.com)
52:デフォルトの名無しさん
19/01/03 15:12:15.57 .net
誤爆しました
53:デフォルトの名無しさん
19/01/04 00:19:38.87 C/NwCX/x.net
デバッガってどう動いたら正常なんでしょうか
vscodeでハロワしてみてブレークポイントで止まる→これでいいんだよな？となりまして
54:デフォルトの名無しさん
19/01/04 00:50:16.36 ihBPygyi.net
リクツを語ると
デバッガにデバッガを適用するとバグかどうかを検出できない
55:デフォルトの名無しさん
19/01/04 20:57:44.72 leXZv0J4.net
Win32APIなんですが、
ウィンドウクラスにアイコンハンドルを設定してWS_OVERLAPPEDWINDOWスタイルで
CreateWindow()すると問題なくタイトルバーにアイコンが表示されるのですが、
WS_POPUPスタイルでCreateWindow()した後にSetWindowLong()でWS_OVERLAPPEDWINDOWスタイルに変更すると、
タイトルバーにアイコンが表示されません。
WM_SETICONをSendMessage()しても変わりませんでした。
どうすれば表示されるようになるでしょうか？
56:デフォルトの名無しさん
19/01/04 23:35:35.15 GKwYgY3X.net
>>55
つ Win32API質問箱
57:55
19/01/05 00:28:56.43 1yzAmca9.net
>>56
そちらはスレが盛んでないので、こちらでお聞きしました･･･
58:デフォルトの名無しさん
19/01/05 08:53:49.71 b8ezfK6l.net
じゃあ自力で頑張って下さい
59:デフォルトの名無しさん
19/01/05 12:19:51.40 wMTnOPNR.net
>>55
URLﾘﾝｸ(eternalwindows.jp)
URLﾘﾝｸ(chokuto.ifdef.jp)
SetWindowLong 関数で変更されたそのデータは SetWindowPos 関数が呼び出されるまで反映されません 👀
Rock54: Caution(BBR-MD5:79b7e0206b0fd5ffcfddd514fa488d36)
60:55
19/01/05 22:25:41.89 1yzAmca9.net
>>59
SetWindowLong()後にSetWindowPos()はコールしていたのですが、
WM_SETICONをSendMessage()するときのアイコンハンドル取得方法がまずかっただけでした（汗）
（LoadIcon()のHINSTANCE引数が正しくなかった）
今は問題なくアイコンが表示できています。
お騒がせしました！
61:デフォルトの名無しさん
19/01/06 01:50:50.63 crl+XFhH.net
>>60
URLﾘﾝｸ(g.co) 👀
Rock54: Caution(BBR-MD5:36abcc1a7fb24404caf692865ab3af18)
62:デフォルトの名無しさん
19/01/06 13:24:20.28 .net
>>57
盛んでないなら先ず盛んにしろよ
欲しい者は先ず自ら与えると言うぞ
63:デフォルトの名無しさん
19/01/06 16:05:17.54 s8+QTrGL.net
難癖つけ太郎
64:デフォルトの名無しさん
19/01/07 19:00:48.26 29GPlbw0.net
ﾂｹﾀﾛｻｧﾝ
65:デフォルトの名無しさん
19/01/09 15:58:07.62 LoPBTm2D.net
C++て3年周期で新規格リリースされるんだなC++20が来年発表て、
えーかげんもうついていけんわ
家電のモデルチェンジじゃあるまいし。言語の追っかけなんかやってられん。
66:デフォルトの名無しさん
19/01/09 18:23:48.31 h/UgfZoi.net
C言語の需要はそういうところじゃねえの
もうこれ以上進歩しないが大抵のことはできる
適度に難しいところもある
67:はちみつ餃子
19/01/09 18:30:18.01 wEN9wc2j.net
>>65
もしそうしたければ古い版の規格で書いてもええんやで。
C++20 が出ても C++11 が消滅するというわけでなし。
まあ主要なコンパイラがサポートしなくなったらしょうがないけど……
68:デフォルトの名無しさん
19/01/09 22:38:39.03 teyoDIou.net
C++11が神過ぎる。
それまでとは雲泥の差。
これだけでずっと戦える。
69:デフォルトの名無しさん
19/01/10 07:42:30.84 JUlDRUM2.net
>>67
言語って自分だけで済まんだろ
キャッチアップしていかんと人の書いたコードが読めなくなる
こんな短期間でアップデート繰り返すんじゃなくもっと精査した上で規格変更しろといいたい
アップデート繰り返す度にユーザ減少してるだろ
70:デフォルトの名無しさん
19/01/10 07:53:15.61 JUlDRUM2.net
>>66
new/delete無造作に使ったコードを組込なんかで書くと、
メモリフラグメント作りまくるだけだからな。
ハードウェアの一部としてRTOS上で安定動作させるためには、
ポインタ使いまくりのbetter Cとして書くしかない。
4kB メモリのRL78でコード書いてみろと
71:デフォルトの名無しさん
19/01/10 11:58:03.74 +qf2Eno1.net
>>69
C++の良かったのは仕様が枯れてることだったのにな
今は逆を逝っててどんどん人が離れて逝ってる
72:デフォルトの名無しさん
19/01/10 13:39:40.00 AlpMGZ50.net
utf-8の文字コードが格納されてるchar配列から、デコードされた文字をstd::string型に入れる方法を教えてください
以下のような変換を実装したいです
char ai[] = {0xe3, 0x81, 0x82, 0xe3, 0x81, 0x84}; // "あい"のutf-8コード
std::string str = ??
std::cout << str << "\n"; // prints "あい"
73:デフォルトの名無しさん
19/01/10 14:15:08.46 XfqugDbL.net
>>72
aiの最後にnull文字は入れないの？
入れないなら
srd::string str { ai, sizeof(ai)/sizeof(ai[0]) };
74:デフォルトの名無しさん
19/01/10 14:38:26.46 f6PjJx/6.net
>>72
wstringに入れろ
75:はちみつ餃子
19/01/10 17:13:07.72 2cm4ZQb/.net
>>69
時間を掛けたら扱う項目 (提案) も増えるからどっちでも同じだよ。
一度の変更が大量になるよりは小さな変更を頻繁にした方が良いというポリシー。
その方が実際の運用で出た問題をフィードバックしやすいという利点もあるしな。
>>73
配列の大きさを知るには std::size か std::extent を使えよ。
76:デフォルトの名無しさん
19/01/10 17:38:07.90 d84NrtHP.net
C++ には C 以来伝統の sizeof / sizeof 以外に
配列の要素数を知る方法があったはず…と思ったが std::size だったか。
でも標準で使えるのは C++17 以降だよね。
「C++ならテンプレート使えばできますよ」的な情報は色々あるけど、
結局、移植性を考えると古典的な sizeof 割り算が便利だったり。
77:デフォルトの名無しさん
19/01/10 19:00:06.40 K/rzzMpV.net
ちょっと知ったかは、よくよく初心者を馬鹿にする。
自分も、初めは、初心者だったくせに。
78:デフォルトの名無しさん
19/01/10 19:11:35.64 .net
スタティックおじさんにならないように戒めなければ
79:デフォルトの名無しさん
19/01/10 20:37:36.88 WIE9C9TP.net
ヒカキンの年収が10億超え!?明石家さんま・坂上忍も驚愕の総資産とは??
URLﾘﾝｸ(logtube.jp)
【衝撃】ヒカキンの年収・月収を暴露！広告収入が15億円超え！？
URLﾘﾝｸ(nicotubers.com)
HIKAKIN(ヒカキン)の年収が14億円！？トップYouTuberになるまでの道のりは？
URLﾘﾝｸ(youtuberhyouron.com)
ヒカキンの月収は１億円！読唇術でダウンタウンなうの坂上忍を検証！
URLﾘﾝｸ(mitarashi-highland.com)
なぜか観てしまう！！サバイバル系youtuberまとめ
URLﾘﾝｸ(tokyohitori.hatenablog.com)
あのPewDiePieがついに、初心YouTuber向けに「視聴回数」「チャンネル登録者数」を増やすコツを公開！
URLﾘﾝｸ(naototube.com)
27歳で年収8億円 女性ユーチューバー「リリー・シン」の生き方
URLﾘﾝｸ(headlines.yahoo.co.jp)
1年で何十億円も稼ぐ高収入ユーチューバー世界ランキングトップ10
URLﾘﾝｸ(gigazine.net)
おもちゃのレビューで年間12億円！ 今、話題のYouTuberは6歳の男の子
URLﾘﾝｸ(www.businessinsider.jp)
彼女はいかにして750万人のファンがいるYouTubeスターとなったのか？
URLﾘﾝｸ(www.businessinsider.jp)
1億円稼ぐ9歳のYouTuberがすごすぎる……アメリカで話題のEvanTubeHD
URLﾘﾝｸ(weekly.ascii.jp)
世界で最も稼ぐユーチューバー、2連覇の首位は年収17億円
URLﾘﾝｸ(forbesjapan.com)
80:デフォルトの名無しさん
19/01/10 22:25:25.90 jgU/jZru.net
std::sizeが使えなかったとしても(主要なゲーム機の環境の1つはC++14止まりだし)、テンプレートで取得するのはC++の移植性には影響しなくないか？
81:デフォルトの名無しさん
19/01/10 22:41:00.66 poVh1zdG.net
ていうかGUIとかマングリングの統一とかvtblが最初に来ることとか
テンプレート周りばっかりじゃなくて解決して欲しい問題いっぱいあるんだけどなぁ
あと個人的にはプロパティとかも欲しい
82:はちみつ餃子
19/01/11 00:50:02.24 le18Krsa.net
配列の要素数を取得するだけのものを自分で書くならこんな感じかな。
template<class T, size_t N>
std::size_t size(T (&)[N]) {
return N;
}
実装自体には sizeof を使ったって害はあまりない (あえてする意味もないけど)。
template<class T, size_t N>
std::size_t size(T (&a)[N]) {
return sizeof a/sizeof a[0];
}
sizeof でのやり方を「そのまま」書く、またはマクロで覆うのは、
型チェックの支援を受けられないから変なミスをしやすい。
変数 a が (配列ではなく) ポインタのときに
sizeof(a)/sizeof(a[0]) という式がコンパイルは通っちゃったりするし。
変数名を二回書かなきゃならないのも、
何かの修正のときにうっかり片方だけ書き換えたりとか有りがち。
プログラミングをそれなりに長くやってると、
馬鹿みたいなつまらないミスをした経験のひとつやふたつやみっつや二百くらいはあるでしょ。
型システムはそういうのを多少なりとも事前に検出してくれるありがたい仕組みなんだから、
積極的に活用したいところ。
83:デフォルトの名無しさん
19/01/11 01:26:18.63 bUNhmYA9.net
C++標準じゃないけどVC++の_countofが重宝してる
84:デフォルトの名無しさん
19/01/11 07:47:16.24 PueFbUtC.net
>>75
>時間を掛けたら扱う項目 (提案) も増えるからどっちでも同じだよ。
同じ訳ないだろが、
仕様変更、追加したものの、さんざん使ったあげくそんなもん使うなってのはいくらでもあるだろ。
auto_ptrはどーした。
だから3年なんて製品のモデルチェンジ並の仕様変更じゃなく、言語オタク共がもっと時間をかけて精査して、
10年に一度ぐらいの変更にしとけってこった。
そもそもCのプリプロセスだったわけで、
Cとの整合性は確保した上で双方同時に仕様変更しろといいたい。
だいたいどっち見て仕様変更してんの？言語オタクのセンズリか？wwww
85:デフォルトの名無しさん
19/01/11 11:25:51.10 saOHWwmK.net
3年ごとなのはいいと思うけど、クラステンプレートの引数推定なんか
関数テンプレートみたいに推論できないテンプレート引数が残る形に出来ない上に
エイリアステンプレートには使えないしクラステンプレートの参照にも使えないし
デフォルトテンプレート引数では省略できないしで・・
便利だけど、あまりにも片手落ちじゃね？と思うことはある
86:はちみつ餃子
19/01/11 13:40:13.69 le18Krsa.net
>>84
> 同じ訳ないだろが、
> 仕様変更、追加したものの、さんざん使ったあげくそんなもん使うなってのはいくらでもあるだろ。
同じだよ。
散々使ったからようやくわかったことで、ただの言語オタクどもがどんだけ理屈をこねた
ところで現実的なプロダクトの実際なんかわかりゃしない。
精査をしっかりすれば事前にどうにか出来てたと本当に思うのか？
> auto_ptrはどーした。
これはまあ……アレだ……
これ自体は擁護しようがないほどアレだけど、
一番アレなのを抜き出して言うのもちょっとどうかなって。
強いて言えば、当時としてはスマートポインタという概念を提示出来たという
成果といえなくもないんじゃないかな……。
> 10年に一度ぐらいの変更にしとけってこった。
URLﾘﾝｸ(i2.wp.com)
> だいたいどっち見て仕様変更してんの？言語オタクのセンズリか？
そうならないために言語オタクにゆだねない (実際の運用で見極める) という選択なのに、
お前はもっと言語オタクに活躍しろって言ってんだぞ。
おかしいだろ。
87:デフォルトの名無しさん
19/01/11 14:33:07.36 iMdUEP7b.net
仕様変更が止まってる言語はともかくとして仕様策定のない言語に比べればC++の更新スパンは割と長い方という認識がある
これより長いのメジャーどころだとC11(1,20年)/Fortran2008(5年)/Ada2005(10年)/Haskell(5年前後)くらい？
Haskellなんかは処理系拡張ゴリゴリだしアテにならないし他はもう古めかしさを感じるなぁ
88:デフォルトの名無しさん
19/01/11 14:56:08.31 9UT8ehvY.net
これ以上Dをdisるのはやめて
89:デフォルトの名無しさん
19/01/11 16:08:50.25 c9plSaZI.net
まぁ、TypeScriptは年6回updateしてるけど次が待ち遠しいな。
90:デフォルトの名無しさん
19/01/11 20:26:13.94 KLK+GnJ4.net
426名無しでいいとも！＠放送中は実況板で2019/01/10(木) 18:17:49.03ID:b7PfIJnh0
新しい物好きな人は、よく、古いもの馬鹿にする。
古いものに、大切なものがあることが、
よくあることを、知らない人が多い。
91:デフォルトの名無しさん
19/01/12 08:06:07.36 TXMmMfvK.net
古いという感覚を持つと話をしただけで古いものが悪いとは一言も言っていないが……？
一方でもしその良さが「新しい仕様を頻繁に覚えなくて良い」なら、言語に対して掛けるコストが減る事と、自身が怠惰である事の2面性を常に持つかもね
プログラマなんて怠惰でナンボだけど覚える事に怠惰か書く事に怠惰か人それぞれよね
個人的には草案で嬉しそうな機能を追加します！って言いながら実際の仕様では無限に延期される方が嫌
92:デフォルトの名無しさん
19/01/12 13:08:56.44 k/r1EiKa.net
これな
youtube
qqwgldvnNlk
#t=41m41s
93:388
19/01/12 23:22:31.27 0iVYXuy3.net
>>82
配列の参照のsizeofは配列のサイズじゃないから害はあるな()
94:388
19/01/12 23:28:35.62 0iVYXuy3.net
>>84 は面白いよな、散々使うことで問題が見付かるって自分で初っ端から言ってるのに「だからスパンを長くしろ」つまり散々使うことが出来ないようにしろって言ってる
そして最後には言語オタクのセンズリかって、言ってる事が弾けまくってるな。
言語オタクのセンズリになってるのが不味いから、積極的に一定毎に更新するようにしていってるんだがな
95:デフォルトの名無しさん
19/01/13 09:10:56.47 47MX21Fj.net
何が言いたいのか分らん
96:デフォルトの名無しさん
19/01/13 09:35:19.34 e8OabTpu.net
箇条書きでよろ
97:デフォルトの名無しさん
19/01/13 14:11:24.44 goGtxYMD.net
おれは >>84 に同意だな
数年で更新ってそれがどれだけワークしてるのさ
だいたいどれだけ認知されてるのかようわからん小さい機能追加が山盛りな一方で
大規模なconstexprとかひかえめにいって大クソじゃん？
理論もなければ、現実のワークフローなにも考慮にはいってない
結局オナニーでしょ、何オタクかはしらんが
98:デフォルトの名無しさん
19/01/13 15:03:59.93 lykUAvmZ.net
1.仕様が確定してからでなければ実務には使われない
2.実務で使われないと良し悪しは分からない
3-1.仕様確定のスパンが短いと、仕様に提案されてから試されるまでが短い（もし悪ければ次で撤回も可能）
3-2.仕様確定のスパンが長いと、提案されてから実務で試されるまでが長い（撤回されないと言えば聞こえは良いが、当然悪いものが残り続ける）
んで仕様策定を言語オタクのオナニーって言ってるのに、実務で試されない、策定の期間だけ伸ばして言語オタクなんとかしろって言ってるように聞こえるからよく分からんわけだ
だって君たち仕様確定してからじゃないとそうそう草案の機能なんて使わないでしょ？追わないでしょ？私だってそうだ
期間が長ければその間に普及する概念も多くなるし（少なくともc++はそれを取り込む方針の言語なので）あんまり長くすると大変だと思うよ
99:デフォルトの名無しさん
19/01/13 16:52:54.35 bhcZ5Z4Z.net
>>97
c++14のconstexprは条件分岐とかループにも対応してるから、そこそこ使えるよ。
文字列リテラルの長さを取得する関数とかも定数化できるし。
テンプレートの非型引数をあれこれする関数を定数化したりとか。
100:デフォルトの名無しさん
19/01/13 16:58:40.56 goGtxYMD.net
機能追加したい人が、ブランチして機能追加して実務で実証して、
それから正式に仕様を提案すりゃいいじゃん
なんで仕方なく業務でC++使ってるだけなのにベータテストみたいな
仕様更新に巻きこまれなきゃならないのさ
101:デフォルトの名無しさん
19/01/13 17:05:15.75 zLcYabhS.net
そんなことよりrvoを強制してほしい…
102:デフォルトの名無しさん
19/01/13 17:05:25.96 bhcZ5Z4Z.net
仕様を確定させないと各コンパイラでの実装と互換性チェックとか出来ないし、
既存のコードが動かなくなるわけでもなし、
10年くらい経って十分枯れた機能を使ってれば良いだけでは？
103:デフォルトの名無しさん
19/01/13 17:06:11.78 goGtxYMD.net
>>99
その程度の最適化はコンパイラが勝手にやればよくね？
もっと大規模なことしたいからわざわざconstexprなんてキーワード追加して
かつ人間様がわざわざそれを指定するんだろ？
で大規模なことをできる仕様か？あれが？
どうせみんなデバッグするときにconstexprをはずしてんだろ？
アホと思わないか？
104:デフォルトの名無しさん
19/01/13 17:10:55.99 bhcZ5Z4Z.net
>>103
Visual Studioでしか試してないけど、わざわざ外さなくてもデバッグビルドでは定数化されないのが普通じゃないの？
105:デフォルトの名無しさん
19/01/13 17:11:37.75 zLcYabhS.net
constexpr相当を勝手にやられたら、参照してるほうがリコンパイルが必要か判断できなくなるんじゃないの？
106:デフォルトの名無しさん
19/01/13 17:27:56.15 bhcZ5Z4Z.net
constexpr指定を使わずに同じような定数化を自動でやるとなると、
一度全ての関数を定数化可能か調べるためのプレビルドみたいなことをしないと無理だよね。
107:デフォルトの名無しさん
19/01/13 17:43:24.56 goGtxYMD.net
定数畳み込みなんて古典的な最適化手法だし、
gccはstrlenの最適化やるだろ
だからもっと大規模なことをやるためのconstexprだろと言ってる
108:デフォルトの名無しさん
19/01/13 17:50:38.42 bhcZ5Z4Z.net
その最適化をコンパイラ依存でなく標準規格化したことに意味があると思うんだけど。
gccで出来ればあとは何でも良いの？
109:デフォルトの名無しさん
19/01/13 18:13:13.67 goGtxYMD.net
珍説どうも
その程度の最適化技術を持たないコンパイラベンダなんてどうでもいいな
clangのバックエンド自分で作った方が早い
110:はちみつ餃子
19/01/14 02:10:17.55 ybeYuaGe.net
constexpr 相当のことはコンパイラが最適化で頑張るのが筋だというのは
まったく正当な意見だと思うんだが、本当に速度が必要な個所のチューニング
をしたいとき、つまりコンパイラの最適化以上のことがしたいときに
打てる手段が無かったりだとか処理系の拡張構文を使わなければならないというよりは、
不格好でも constexpr の方がマシ。
C++ は現実的に使えることを指向した言語で、現実はクソなんで、
クソを少しマシに書けるようにするってのは妥当な選択肢。
コンパイラが十分に賢いだとかいうような
理想的な世界で生きてる人は別に constexpr を使わなくてもいいよ。
111:デフォルトの名無しさん
19/01/14 06:19:38.07 S0iGLcvV.net
pythonやmatlabみたいに配列やvectorを:とかでスライス抽出できないんですか？
112:デフォルトの名無しさん
19/01/14 07:17:53.28 4qrkuOlT.net
技術スキンだけ高い奴が、できる奴と思い込んでるチキン。
113:デフォルトの名無しさん
19/01/14 09:22:28.84 UgNfZwvf.net
>>111
それをアセンブラで書いてみてくれ
114:デフォルトの名無しさん
19/01/14 10:26:42.41 3TGcl/LH.net
++20のfilterでスライスみたいな事ができるようになる
しばし待たれよ
115:デフォルトの名無しさん
19/01/14 13:02:31.28 BcFaCsuL.net
>>110
constexpr指定はコンパイラにはわからない関数呼び出し先で
定数化できる計算であるとコンパイラに教えられるので
指定できるならした方がいいだろうけど
＞本当に速度が必要な個所のチューニング
そういう個所がコンパイル時にわかってる定数だけで構成されてる例なんて
まず滅多にないんだけどね
116:はちみつ餃子
19/01/14 13:29:30.02 ybeYuaGe.net
>>115
>> 本当に速度が必要な個所のチューニング
> そういう個所がコンパイル時にわかってる定数だけで構成されてる例なんて
> まず滅多にないんだけどね
constexpr はコンパイラに対するヒントであるだけでなく、プログラマにとっての制約でもある。
「そういう (速度が必要な) 箇所」であるにもかかわらず実行時の値に依存しているということを
プログラマが気づくことが出来る (ので分離するなどの工夫をする機会があるかもしれない)
というのは十分に便利だよ。
117:デフォルトの名無しさん
19/01/14 13:39:03.52 BcFaCsuL.net
わかってないな
本当に解決しなきゃいけないボトルネックが、たかだか定数の畳み込みだけで
解決出来ることなどまず無いと言ってんの
ただの数回、数十回の普通の演算はそのままやっても十分速いんだよ
むしろ定数化できるとこを全部定数化したせいで、(即値にならないような構造体の場合)定数を読みに行くコストの方が大幅に高くなる可能性もある
constexprというか言語の機能を盲信しすぎ
118:デフォルトの名無しさん
19/01/14 13:47:53.15 BcFaCsuL.net
あと、
＞「そういう (速度が必要な) 箇所」であるにもかかわらず実行時の値に依存しているということを
ファイルから読んだ内容、mainに渡された引数、ネットワークから受け取ったデータ
そういうの(および一度でもそれらと関わった変数)全て実行時の値だってわかってる？
119:デフォルトの名無しさん
19/01/14 22:35:17.67 SOyXSPCI.net
オフラインで複雑な計算して、結果をバイナリで埋め込んでおくことはよくやる
ゲームなら当たり前にやるワークフローだよな
しかしそういう典型的な用途にconstexprは向いてないという間抜け具合
C++でなんでもやるというのが目的になってんだよね
こういうのをオナニーって言う
120:はちみつ餃子
19/01/15 09:17:36.65 f9+1p0X/.net
>>117-118
やりたいときに出来る方法があるというのは無いより「マシ」と私は >>110 で述べたが、
それが君にとっての妄信なのかい？
要するに、 constexpr の成果は限定的すぎると言いたいんだろ？
ほとんどの機能は個別に見ればどうでもいいような些細なものなのは普通のことだ。
121:デフォルトの名無しさん
19/01/15 09:57:48.09 fPstZ0f7.net
何度も言ってきたが、負けを認めたら死ぬ病気なのか？君は
122:デフォルトの名無しさん
19/01/15 10:02:02.52 fPstZ0f7.net
ついでに言えば、俺は「指定できるならした方がいい」と書いた
俺が成果を限定的だと貶してるんじゃなくて、
君が過信してるの
123:はちみつ餃子
19/01/15 10:05:46.91 f9+1p0X/.net
>>122
じゃあ何が問題なんだい？
指定できるならした方がよくて、指定できるようになってるのは指定できないより良いというのなら意見は一致してるじゃないか。
124:デフォルトの名無しさん
19/01/15 10:23:37.90 p3r+u4ET.net
＞本当に速度が必要な個所のチューニング
＞をしたいとき、つまりコンパイラの最適化以上のことがしたいときに
＞打てる手段が無かったりだとか処理系の拡張構文を使わなければならないというよりは、
＞不格好でも constexpr の方がマシ。
125:デフォルトの名無しさん
19/01/15 10:26:22.74 fPstZ0f7.net
(途中送信してしまった)
本当に"速度"が必要なときに速度より移植性やC++標準への準拠を優先してconstexprマンセーする
これを過信と言わずして何と言う
126:はちみつ餃子
19/01/15 10:40:35.59 f9+1p0X/.net
>>125
速度が必要な個所が「なるべく」移植性が高い形で表現できればそれに越したことは無いし、
更にそれ以上が欲しいなら移植性を犠牲にすることも出来るんだから、
constexpr の導入に何の問題もないだろ？
127:デフォルトの名無しさん
19/01/15 19:01:25.37 CKmovdLr.net
何でC++スレはプログラム板で勢いあるんですか？
128:デフォルトの名無しさん
19/01/15 19:02:26.94 CKmovdLr.net
C++で有名人になりたいです
どうすればいいでしょうか？
129:
19/01/15 21:38:31.55 niK8DUcQ.net
>>128
c++ のコンパイラを c で記述すれば、それだけで有名になれると思います
gcc が c から c++ になったときは心底残念に思っていました
130:デフォルトの名無しさん
19/01/15 22:36:39.63 CKmovdLr.net
>>129
それって無理では‥
131:デフォルトの名無しさん
19/01/16 01:23:29.16 CLrL7dI7.net
>>130
つ URLﾘﾝｸ(www.amazon.co.jp)
132:デフォルトの名無しさん
19/01/16 04:10:04.96 GtMBox+p.net
>>94
はちみつなんとかもそーだけど、
おまえもほんま馬鹿やね。表面しか読めないんだな。
10年間、言語オタを隔離してしまえといってるのだよ間抜けちゃん。
世の中から隔離された世界でせんずりこいてろといってる。ザーメン臭でくさいやつは地上に出るな。
大体、大規模プログラミングはすでにC++には向かないことが露呈して久しく、
せいぜいbetter Cとして生き残るぐらいしか道はないのにどういう意図を持っての3年ごとの改訂なんだ。
ポリシーなき改訂ははた迷惑なだけ
これだけ頻繁に改訂されると、スペック以外の解説本では、すでにストラウストラップ本自体改訂をキャッチアップできてない。
その邦訳ともなればますます現行仕様から浦島太郎になるのは必至。せっかく覚えた頃に新スペックの登場か？
C++初心者はいったいどの本買ってるのさ？キチガイ言語オタ江添本でも買うのか？
結局、ユーザー減少させてるだけだろうが
133:デフォルトの名無しさん
19/01/16 04:55:20.85 M8dG57eU.net
他人をけなす人には、なりたくないな
ｽﾚﾘﾝｸ(pav板)
134:デフォルトの名無しさん
19/01/16 05:13:03.61 CLrL7dI7.net
なるな人間になるな
135:デフォルトの名無しさん
19/01/16 09:06:01.53 Cj0f6L/5.net
もしかして、最初の「なる」はNULLと掛かってる？
中身のない人間、アクセスしちゃダメな奴、みたいな意味で。
ちなみに自分は「ヌル」派。
だってNULLを「ナル」と読んだら「ぬるぽ」と言えなくなるもの。
136:デフォルトの名無しさん
19/01/16 09:58:04.96 qfBMRYbT.net
>>131
一応買ってみました
でもどうせコンパイラ作るならC++でClangとかの実装を勉強したい
137:デフォルトの名無しさん
19/01/16 12:17:10.07 qfBMRYbT.net
C++好きな人って、C‡‡、Java嫌いな人が多いのって偏見ですか？
関数型言語かRustの話しかしてない気がします
138:デフォルトの名無しさん
19/01/16 13:56:12.46 CLrL7dI7.net
>>135
回文
139:はちみつ餃子
19/01/16 15:05:52.98 kJO3cJ8H.net
>>132
C++ の言語としてのポリシーはこのように提示されている。
Stroustrup 自身がその著書に書いたもの。
委員会の公式な文書にするとかどうとかいう議論はあったけど、
結局どうなったのかは知らない。
・C++ の進化は現実の問題をその動因とする
・完全主義にはこだわらない
・C++ は今現在役に立つ言語でなければならない
・人に何かを強制しない
・静的タイプシステムに対する暗黙の違反が無い
・同じ機能なら人に教えやすい方を選ぶ
・C のプリプロセッサは使わないように
・C との正当でない非互換性が無い
・C++ 以外に他の低レベル言語を必要としない (アセンブラは除く)
・使わない機能はコストを発生させない
これらの考え方に基づいて今要求されているものが (不完全でも) より素早く反映しやすくする
リリース体制として ship train model が導入された。
多くの人が関わるので妥協はあるだろうが、一環したポリシーの下で改定されている。
そのポリシーを気に入らないでいる自由はあるし、それはどんどん主張して良いが、
ポリシーが無いというのは事実誤認だし、自分にとって妥当ではないからといって
必要としている人を侮辱するべきではないよ。
140:デフォルトの名無しさん
19/01/16 15:25:10.37 mUX6kDFm.net
俺が以前「D&E読んでないのか」、って言ったせいではちみつはD&Eの受け売りするようになったな・・・
URLﾘﾝｸ(i-saint.hatenablog.com)
「あるプログラム言語を使うためにその言語の弁護人になるべきではない。」
そういうただの弁護人になってるバカは大抵C++を実用レベルで使ってない人間ばっかりだ
141:デフォルトの名無しさん
19/01/16 15:27:49.73 vTKVQdGX.net
そやな
142:はちみつ餃子
19/01/16 15:39:55.50 kJO3cJ8H.net
>>140
？
このスレで言われたから読んだということは無いはずだが、どの発言のこと？
正確に覚えてないけど
私が持ってるやつは (日本語版の) 初版だからたぶん 2006～2007 年頃には読んでるはず。
143:はちみつ餃子
19/01/16 15:56:46.23 kJO3cJ8H.net
現実的な問題があるならそれは解決されなければならない問題であって、
改定を先延ばしにすることを要求するのはおかしな話じゃない？
ドキュメントが追い付いていないのは、これは確かにあるけど、
翻訳とかに時間がかかるのが分かっているから
早め早めに改定がリリースされるのはむしろありがたいことでしょ。
デカい改定が一気にくるよりは。
constexpr が限定的に過ぎるとかいうのはわかってる話で、
だから制限を緩くしたり consteval を検証したりしてるんだろ。
それでも必要だと判断したから入れたんだから、
そこに文句付けたって今更な話で擁護もクソもない。
駄目な部分があるのは知ってるっつーの。 それでも要るんだよ！
144:135
19/01/16 17:16:27.25 Cj0f6L/5.net
>>138 回文には気づかなかった。
「なるな」「人間に」がそれぞれ反転同一で、
それらフレーズを反転同一になるように並べて作成した回文か。
「人間になるな人間に」でも構造的には同じね。
いくらかPPAPな感じがしないでもない。
あと、正規表現のパズルっぽくもある。
145:はちみつ餃子
19/01/16 17:26:40.42 kJO3cJ8H.net
酢にピリッとした風味を足すのに使えます
＿人人人人人人＿
＞ スピリタス ＜
￣Y^Y^Y^Y^Y^Y￣
146:はちみつ餃子
19/01/16 17:28:13.10 kJO3cJ8H.net
>>145
すまん。 誤爆した。
147:デフォルトの名無しさん
19/01/16 17:58:49.69 Cj0f6L/5.net
はちみつと関係ないと思ったけど、餃子の方には関係ありそう。
しかし、C++スレッドでの真摯な態度と裏腹に、
他所ではどういうキャラクタなんだろ、と思わせる投稿ね。
148:デフォルトの名無しさん
19/01/16 18:12:30.55 mUX6kDFm.net
真摯かねぇ・・・・希望的観測で詳しくないことに首突っ込んだり
自分の間違いや認識の誤りは絶対に認めないクソコテなのに
まぁそれも俺の主観だから他の人がどう思うかは知らんけど。
149:デフォルトの名無しさん
19/01/16 18:41:54.90 YdXHJCw6.net
>>145
風味って鼻から空気が出る時に感じる食べ物の香りかと思ってたわ
150:デフォルトの名無しさん
19/01/16 20:40:09.12 iaQOejPk.net
c++が対象にしてる現実問題って何だ？
c++使う大規模プロジェクトってゲームがまずあると思うけど
例外禁止未だに普通だし標準ライブラリも限定的にしか使わないよ
151:デフォルトの名無しさん
19/01/16 20:47:01.61 Tucl/crz.net
c++で書かれたc++のコンパイラのことだろ
ここが0.001%早くなるだけで世界から年間１０００００時間くらいが節約できるんじゃねえの
152:デフォルトの名無しさん
19/01/16 21:54:11.46 gQtWsPR9.net
じゃあLLVMのコーディングスタンダードこれな
URLﾘﾝｸ(llvm.org)
例外、RTTI、iostream使わない
現実に使えるソフトってのはこういう制約で作るわけだ
C++の標準化やってる連中はメタプログラミングで遊んでるだけ
現実問題なんて何もわかってない
153:デフォルトの名無しさん
19/01/16 23:10:45.86 4t4UncJr.net
例外使わないとかないわー
初心者かよ
154:デフォルトの名無しさん
19/01/16 23:12:36.63 Xh3PQjx5.net
だから、ブラウザ、ロケット射的距離のシミュレーション、機械学習
155:デフォルトの名無しさん
19/01/16 23:36:41.52 gQtWsPR9.net
>>153
初心者ってのはC++の例外のバイナリモデル説明できねーやつのことな
156:デフォルトの名無しさん
19/01/16 23:44:05.56 gQtWsPR9.net
>>154
でC++がそれらに対してどんな問題解決してくれたんだ？
157:はちみつ餃子
19/01/17 01:07:41.88 /VOhvfFp.net
>>152
そこらへんはしゃーない。 便利な機能も害悪な場面は有るし、
ある時点では有用だったものが後には足を引っ張ることもある。
あるプロジェクトで縛りを設けるからといって
それが現実の全てというわけではない。
ただ、例外を使わない方向というのは大きなプロジェクトでは
そこそこあるかも？
>>153
例外が忌避されるのは他の言語と接続したときに、
呼出した側が例外を捕捉できないというのが致命的で、
つまりはそういった場面が想定されるようなライブラリでの一般的な規則。
外へ出る前に例外を全部キャッチしてしまうってのでも、
まあなんとかならんことはないが、
近頃では std::optional を活用した方がいいという雰囲気はある気がするね。
Go や Rust は最初からそういう方向だし。
158:デフォルトの名無しさん
19/01/17 02:01:31.97 l+wuAult.net
このスレ、初心者を見下す者ばかりだし、
何が 【初心者歓迎】だよ。
【初心者歓迎】はずせ。
そう言うと、「何にもそんなことしてないよ」
とか、レスが来る。
子供スレ。
159:デフォルトの名無しさん
19/01/17 08:10:37.95 qOfK2eXQ.net
optionalはヒープ使わないだけでnullと大差ない
せっかく静的にnot nulが保証されてるとこを壊してしまう
ほとんどアンチパターン
160:デフォルトの名無しさん
19/01/17 08:21:29.72 4hvMH0x4.net
業務でC++使ってない雑魚の意見なんて無視しろ
161:デフォルトの名無しさん
19/01/17 08:22:23.19 4hvMH0x4.net
趣味でC++齧ってるやつと本気で仕事としてやってるやつじゃ格が違うんだよ
162:デフォルトの名無しさん
19/01/17 08:22:55.36 .net
C++では好きなだけ効率を犠牲にして安全を手にすることができる
効率を犠牲にして安全を手にすることを余儀なくされている言語とは区別すべきだ
163:デフォルトの名無しさん
19/01/17 08:47:23.41 qOfK2eXQ.net
業務で使ってない素人は平気で例外禁則とか言って返り値チェックで死ぬほど汚いコード書くんだよな
164:デフォルトの名無しさん
19/01/17 09:07:15.76 CHgbqTPA.net
まぁ業務と違って趣味は時間を無駄につぎ込めるから
人によっては素人の方がレベル高かったりするけどな
そういうのと比較するのはホントやめて欲しい
165:デフォルトの名無しさん
19/01/17 09:09:21.72 4hvMH0x4.net
>>164
は？業務と趣味でやってる奴が一番最強
166:デフォルトの名無しさん
19/01/17 10:35:25.89 iQ0t94Qh.net
>>159
optionalの理解間違ってるよ
167:デフォルトの名無しさん
19/01/17 10:39:29.94 iQ0t94Qh.net
>>163
例外禁止されるのは業務の方だろ
一見汚くなるがそちらの方がバグが少なくメンテしやすいという判断で
トップダウンで強制される
趣味なら最新の機能ばんばん使って自由にやりゃいい
168:デフォルトの名無しさん
19/01/17 12:13:15.88 oU9OMPiG.net
実際には例外を禁止するとバグが増えてメンテしにくくなるんだけどな
169:デフォルトの名無しさん
19/01/17 13:51:39.37 l+wuAult.net
そのソフトが気に入らないなら、
そのソフトを使わなきゃ良いだけだし。
そんなことも、いい年になって、わからないのか。
170:デフォルトの名無しさん
19/01/17 14:34:02.57 DbtLCT5r.net
このスレ卒業死体
171:デフォルトの名無しさん
19/01/17 14:43:25.66 n6FY+cyG.net
スレばいいじゃない
172:デフォルトの名無しさん
19/01/17 15:55:58.66 K5aWd8xj.net
setjmp 使えばよろし
173:デフォルトの名無しさん
19/01/17 17:20:21.35 .net
遂に中級者になるのか……
174:さまよえる蟻人間
19/01/17 20:25:15.31 e9w/TFC0.net
>>173
なんでID消えてるの？
175:デフォルトの名無しさん
19/01/17 20:47:04.58 iJuNblTy.net
浪人で消してるんでっしゃろ
176:デフォルトの名無しさん
19/01/17 21:54:16.18 yb/OKoP7.net
単なるエラーを返すのに例外機構みたいな大域脱出って牛刀感あるよな。
177:デフォルトの名無しさん
19/01/17 22:25:28.97 zQ8cL02f.net
エラーコードの取り間違いやチェック漏れがないように書くにはすごい集中力が必要で神経をすり減らす作業
スローすれば僅かな労力で安全に済むところをわざわざ戻り値にするのは事を大げさにするだけ
178:デフォルトの名無しさん
19/01/17 23:05:50.61 K5aWd8xj.net
つ errno
179:デフォルトの名無しさん
19/01/17 23:24:18.46 yb/OKoP7.net
なあに、例外のcatch漏れや例外安全を欠いていないか注意するのと比べたら
たいてい局所的に判断できるから大したことない。
>エラーコードの取り間違いやチェック漏れがないように書くにはすごい集中力が必要で神経をすり減らす作業
検査例外じゃない例外機構でそれを保証するのも簡単じゃないと思うがな。
まぁ、一人開発で投げるのもcatchするのも全部把握しているという前提ならわからんでもないが。
180:はちみつ餃子
19/01/18 00:32:34.20 ZqjXe4yq.net
>>179
そのへんはチェックするツールとかあったりしない？
知らんけど。
181:デフォルトの名無しさん
19/01/18 00:49:25.33 HmTdANXo.net
実はキャッチ漏れは戻り値処理漏れよりはるかに少ない
戻り値処理はその場でエラー処理したくない場合にも一度変数に受け取って分岐を入れて呼び元に返すということを繰り返さなければならない
なので処理漏れを起こしうる確率が呼び出し箇所の数に比例して増えていくことになる
そして本当のエラー処理をしたい場所が隠れてしまいコードの可読性が低下する
可読性が低下すればミスがさらに増える
例外なら処理したくない場合は何も書かなくていいので間違えようがないので安心
またエラー処理をしたいまさにその箇所だけに処理を書けばいいのでコードの見通しが非常に良くなりミスも激減する
エラーコード戻し安全なコードを書くことは実は非常に難しい
エラーコードチェックのせいで無駄な変数と分岐が大増殖するので正確にシステムの状態を追うことが困難になりミスが増える
例外を使えばフローが非常に単調で綺麗になるので安全なコードを書くのも簡単になる
182:デフォルトの名無しさん
19/01/18 01:03:26.14 0w3MYNkW.net
同じ理由で、忌み嫌われてるgoto文も、実はけっこう便利だと思う
183:はちみつ餃子
19/01/18 01:11:53.91 ZqjXe4yq.net
正しく使えば何だって便利だし、
駄目な使い方をすれば何だって駄目だっていう
すごく当たり前すぎる話
184:デフォルトの名無しさん
19/01/18 08:10:56.74 VfzPRVfV.net
>>183
>>180
プログラミング辞めてツールでチェックしてもらえば？
185:デフォルトの名無しさん
19/01/18 08:14:02.62 BmxrQ6cX.net
>>180
それが検査例外じゃないかな。
いろいろ批判もあるけど、例外の内容に応じてそれぞれ異なるリカバリを確実に行うことを
保証する手段としては今のところそれ以外無いかなと思う。
まぁ、erlang/swiftあるいはgoのpanicのように、エラーの種類なんて気にせず「この下の
処理が失敗した」とだけ捉えるのが例外の扱いとして妥当なところかも。
186:デフォルトの名無しさん
19/01/18 09:51:47.22 LyFbxqMk.net
>>181
使い捨てでないまともなプログラムはいたるところにエラーリカバリー処理が入る
つまり例外だといたるところにtry catchかつ外に投げる例外は誰がcatchするのか仕様が複雑
仕事で大規模なプロジェクトに関わったことない人はこういうのが理解できていない
187:デフォルトの名無しさん
19/01/18 10:01:53.52 LyFbxqMk.net
例外押しのやつはどうせほとんどcatchせずにそのままexitさせてるだろ
exitするぐらいなら異常が発生した場所でabortする方がはるかにいい
確実にスタックダンプが残せる
188:デフォルトの名無しさん
19/01/18 10:41:00.50 cHsPUmRi.net
例外が有用なのってネットワークとストレージのioぐらいという認識
それ以外で必要性を感じない
配列外アクセスとかで例外とばすなと思う
189:デフォルトの名無しさん
19/01/18 11:40:22.57 6lA8mErY.net
>>188
そういうバグが原因の例外はcatchしなければいいんでは？
190:デフォルトの名無しさん
19/01/18 13:31:14.01 cHsPUmRi.net
>>189
だから現実的にそういうのに例外をなげる仕様にありがたみがないでしょ
191:デフォルトの名無しさん
19/01/18 13:49:33.80 6lA8mErY.net
>>190
なんで？SEGVも起こさずに潜在的なバグとして残り続けるよりよくない？
192:デフォルトの名無しさん
19/01/18 13:57:52.52 cHsPUmRi.net
>>191
自分でcatchするならtry catchがうざい
バグ扱いでcatchしないならそもそも例外投げずにpanicされた方が調査が楽
また下手にどこかでcatchされたらバグに気づかない危険性がある
以上の理由により
193:デフォルトの名無しさん
19/01/18 16:42:12.57 MrHOaa15.net
gotoなんか品質チェックに問答無用で引っ掛かる
194:デフォルトの名無しさん
19/01/18 16:50:08.01 e8mi14LA.net
お間抜けな品質チェックだこと
195:デフォルトの名無しさん
19/01/18 17:34:28.42 dGgLcYHd.net
ID:cHsPUmRi ってcatchで全ての例外がキャッチされると思ってるのか？
196:デフォルトの名無しさん
19/01/18 17:42:49.84 e8mi14LA.net
例外が発生しました
「このPCの電源が入っていません」
197:デフォルトの名無しさん
19/01/18 17:59:44.06 .net
例外機構は誰がキャッチするのか別の問題を作った
問題先送りで日本人らしい
結局本質的には何の解決ももたらさなかった
例外機構はオカルトだったんだ。占いの類
198:さまよえる蟻人間
19/01/18 18:01:08.56 eisM0hGT.net
例外なくしてOS作れるか？
199:はちみつ餃子
19/01/18 18:48:44.03 ZqjXe4yq.net
>>197
エラーを返却値で返すことにしたところでそれは同じでしょ。
どこまで上に (返却値によって) 伝播すべきかってのは
どこでキャッチすべきかと問題は同じだよ。
200:デフォルトの名無しさん
19/01/18 18:57:17.35 X3ceYQ3H.net
ダウソファイルのファイル名置換する簡単なプログラムをC++とC#で書いてみた(C++で作って、それ見ながらC#に変換した)
もともとシェルスクリプトでもいいようなプログラムなんで実行速度とかどーでもいい
コンパイル時間長が
C# <<< 超えられない壁 <<< C++
C++のコンパイル時間と比べるとC#は一瞬で完了する。これは、快適性がだんちだな。
201:デフォルトの名無しさん
19/01/18 19:12:22.57 seZYByET.net
if文使うな。
ということか？
202:デフォルトの名無しさん
19/01/18 20:07:49.64 BPWAMvDw.net
リターンコードスタイルにすると
無駄な変数が増える
無駄な分岐が増える
エラーコード追加時に全ての呼び出し元を精査しなければならない
エラーに付随する情報を伝達する標準的な規則が存在しない
全ての正常系の処理にコードチェックのオーバーヘッドが追加される
ライブラリ内部で発生する例外への対処が困難(例外を基本としていれば容易に対処可能)
参照透過性が壊滅する
デメリットだらけ
203:デフォルトの名無しさん
19/01/18 20:59:01.43 BmxrQ6cX.net
>エラーコード追加時に全ての呼び出し元を精査しなければならない
>参照透過性が壊滅する
例外ならそれが解決すると考えているならちょっとやばい。
204:デフォルトの名無しさん
19/01/18 23:06:15.78 BPWAMvDw.net
>>203
返り値でエラー通知するようなセピア色の世界にいるとわからんかもしれんが普通に解決するぞ
205:デフォルトの名無しさん
19/01/19 01:49:00.66 gJ7zJmkH.net
参照透過性ってそういう意味だっけ？w
最近例外ない言語増えてる事実はどう考える？
206:デフォルトの名無しさん
19/01/19 07:07:12.07 +IqL7b8U.net
>>203
リターンコード方式や例外と参照透過性になんの関係があるんだろう…
>>205
> 最近例外ない言語増えてる事実はどう考える？
Go以外にあったっけ？
207:デフォルトの名無しさん
19/01/19 07:37:40.03 FscMnE/k.net
まぁ、実際関係ないね。
同じ入力に対して常に同じエラーコードを返すなら参照透過性があると言えるし、
入力によらず場合によって例外を返すことがあるなら参照透過じゃない。
208:デフォルトの名無しさん
19/01/19 07:43:37.22 WVD5Mi4y.net
「呼び出し元を精査」とかプログラム内のデバッグに例外使ってるような書き方やね
例外処理は外部的要因（ハード、通信等）のエラーのように自分の責任外のエラーを積極的に通知するために使うべきだと思うけどな
209:デフォルトの名無しさん
19/01/19 08:51:08.36 fPDnzLoP.net
戻り値形式ではそもそも式として書けないから参照透過性もクソもないということをまずは理解しろ
int h(P const & p, Q const & q, Z & out_z) {
X x;
Int ret_f = f(p, x); // out ref x
if (is_error(ret_f)) return ret_f;
Y y;
int ret_g = g(q, y); // out ref y
if (is_error(ret_g)) return ret_g;
z = x * y;
return RET_OK;
}
↑例外を使わない下品すぎるコード
↓例外を使ったスーパーエレガントなコード
Z h(P const & p, Q const & q) { return f(p) * g(q); }
210:デフォルトの名無しさん
19/01/19 09:21:20.09 XwZdf3Vk.net
Real Programmers Don't Use Exception.
211:デフォルトの名無しさん
19/01/19 12:10:48.67 gJ7zJmkH.net
>>206
rust
swiftは最初なくて後で追加
積極的に使うスタンスでない
212:デフォルトの名無しさん
19/01/19 12:13:26.40 gJ7zJmkH.net
>>209
そこに丹念なエラー処理を追加していくと、あら不思議どっちもあまりかわらない
213:デフォルトの名無しさん
19/01/19 13:16:34.67 +IqL7b8U.net
>>211
それってやっぱりいるじゃん
ってことだよね w
>>212
え？
何言ってるの？
エラー処理ってなんのこと？
具体的に書いてみて
214:デフォルトの名無しさん
19/01/19 14:04:33.44 gJ7zJmkH.net
>>213
エラー処理って言ったらまぎらわしかった
異常系の対応ってこと
215:デフォルトの名無しさん
19/01/19 14:08:49.01 fPDnzLoP.net
何にでも丹念なエラー処理が必要になることはないし
丹念なエラー処理も例外の方がやりやすい
216:デフォルトの名無しさん
19/01/19 14:30:15.46 +IqL7b8U.net
>>214
エラー処理でも異常系の対応でもいいから具体的に書いてくれよ
>>209程度ならたいしたことないだろ
217:デフォルトの名無しさん
19/01/19 14:50:30.01 FscMnE/k.net
案の定、参照透過性は関係ない話だった。
218:デフォルトの名無しさん
19/01/19 16:58:07.69 gJ7zJmkH.net
>>216
具体的にするには前提がいるでしょ
f、gは外部から与えられてる関数で中身を書き換えることはできない
かつ至る所で使われている
p、qは誤りを含んでいる可能性があって、異常(エラー/例外)が起こりうる
異常の場合は何かおかしかったの後で調査できるようにログに残す、
または人間にフィードバックしてリトライさせる必要がある
製品レベルのソフトウェアならいたって普通の前提と要件
これを実現するとどうなるかは想像つくでしょ？
おれは例外否定派ではないよ
役に立つところは限定的と言う主張
>>188 がおれだから
まぁ確かにどちらかで言えばなくてもいいとは思ってる
ただ現状C++の標準ライブラリは例外ありきの設計に突き進んでいるから
エラーコードで突き進むのは筋が悪いのは確か
219:デフォルトの名無しさん
19/01/19 17:14:14.89 +IqL7b8U.net
>>218
> p、qは誤りを含んでいる可能性があって、異常(エラー/例外)が起こりうる
意味わからん
220:デフォルトの名無しさん
19/01/19 17:16:52.76 fPDnzLoP.net
コード書けないならそう言えば？
長文で言い訳してないでさ
221:デフォルトの名無しさん
19/01/19 17:33:46.39 XYN5JTgF.net
普通は馬鹿に割く時間がもったいないからコード書けません
222:デフォルトの名無しさん
19/01/19 17:53:36.92 +IqL7b8U.net
そう言ういいわけ要らんし
223:デフォルトの名無しさん
19/01/19 18:31:39.45 fPDnzLoP.net
信者ですらわずかなサンプルコードを書くのをためらうほどには戻り値スタイルは厄介な代物ということがわかったね
くだらない言い訳で長文を書く労力よりも高くつくということがはっきりした
224:デフォルトの名無しさん
19/01/19 20:10:32.29 XwZdf3Vk.net
普通signalで実装するよね～
225:デフォルトの名無しさん
19/01/19 20:17:23.95 gJ7zJmkH.net
勝利宣言の後で申し訳ないけど
h()でハンドルするとしたら単に
Z h(P const & p, Q const & q) {
try {
return f(p) * g(q)
} catch (exception_invalid_arg_f e) {
throw exception_invalid_arg("arg p is invalid");
} catch (exception_invalid_arg_g e) {
throw exception_invalid_arg("arg q is invalid");
}
}
みたいにリアス海岸になるわけでしょ
でもこれはpとqの異常の区別が下からあがってくる例外で区別できてしまう特殊例
Z h2(P const & p, Q const & q0, Q const & q1) {
return f(p) * g(q0) * g(q1);
}
だとより複雑になる
じゃあこれ次の人やってみて
226:デフォルトの名無しさん
19/01/19 20:34:58.74 DlKBTFO2.net
天狗だ天狗が出たぞぉ
227:デフォルトの名無しさん
19/01/19 21:39:06.68 .net
やっぱり例外機構はオカルトだった。皆が長い間この迷信に惑わされ疲弊した
228:デフォルトの名無しさん
19/01/19 22:11:28.98 +IqL7b8U.net
疲弊してるのは君みたいだけど w
229:デフォルトの名無しさん
19/01/19 22:15:24.45 wCv/sLww.net
>>227
少し休め
人生は長いぞ
230:デフォルトの名無しさん
19/01/20 09:40:39.15 GKseTsKF.net
>>225
例外の使い方知らないのか
231:デフォルトの名無しさん
19/01/20 10:17:17.63 0AQxsU+K.net
具体的に書いてくれよ
232:デフォルトの名無しさん
19/01/20 10:50:52.46 mVpLWWyp.net
>>231
まさかと思うけど>>225でcatch書かなきゃf()やg()で発生した例外はそのままh()の呼び出し側に伝搬すること知らんのか？
あと、例えば引数がおかしいと言う例外なら例外情報に引数の値などを含めて一番外側でログを採るとかするから
> Z h2(P const & p, Q const & q0, Q const & q1) {
> return f(p) * g(q0) * g(q1);
> }
> だとより複雑になる
なんてことはない
233:デフォルトの名無しさん
19/01/20 11:19:55.89 GKseTsKF.net
ほらな言った通りになった
戻り値スタイルはただ異常処理を上位に委ねるだけでも多量のコードを書かなければならない
だから本当に処理すべき異常や正常系の処理が異常伝達に埋もれてしまいコードの可読性が著しく低下してしまう
>>225が>>209のサンプルコードの意図を誤解した理由がこれだ
>>225が間違えたのは予想された事だったんだ
>>225が例外スタイルでは必要ない障害伝達を書いてしまった理由も根は同じ
戻り値スタイルを書き続ける事によって関数コールの周りに障害伝達を書くのは当たり前の事なんだと頭の中に刷り込まれて思考停止してしまった
結果として例外スタイルを書く際にもいつもの癖で不要な障害伝達を書いてしまった
そして戻り値スタイル派の人々は自分達が戻り値スタイルの常識にしたがって書いた例外スタイルの酷いコードを見てこう言うのだ
「ほらやっぱり例外はダメじゃないか」
とね
234:デフォルトの名無しさん
19/01/20 11:22:27.27 GKseTsKF.net
ちなみに言った通りのレスは>>181のことな
235:デフォルトの名無しさん
19/01/20 13:52:10.31 Y8m3wOFq.net
>>232
> > だとより複雑になる
> なんてことはない
具体的にコードで書けよw
要件は >>218 な
h()が異常処理の責任を持つ前提でな
上に例外伝搬させてるだけでは問題は何も解決しねーから
236:デフォルトの名無しさん
19/01/20 14:06:11.05 Y8m3wOFq.net
あと
>>225
で例外投げなおしてるのは本質じゃない
単にそこでなにかしら異常系の対応をするという意味合い
人間にリトライさせることを考えると h()を呼び出したのがUIのフレームワークで
呼び出し側が "arg p is invalid" というメッセージでどっちの間違いが判定するなど
(現実には文字列で判定させる実装にしないだろうが、例な)
そこをそのまま exception_invalid_arg_f を上に伝搬させればいいだろと思うのはど素人
h() から外部ライブラリの exception_invalid_arg_f、exception_invalid_arg_g がそのまま
あがってくるというのは一般的にソフトウェアのレイヤー構造を崩してる
もちろん自分が担当している範囲ならありだが、
h() を外部に公開するような場合は仕様の責任をもつために自分で定義した例外で
投げなおすのは当たり前
237:デフォルトの名無しさん
19/01/20 14:24:17.92 mVpLWWyp.net
とりあえず戻り値スタイルでコード書いてくれよ
例外版に直してあげるからさ
238:デフォルトの名無しさん
19/01/20 14:29:19.26 GKseTsKF.net
>>235
ほら何もわかってない
エラー発生箇所でなんでも解決しなきゃならないと洗脳されてんだね
何もなくてもエラー処理コードを書かなければならない戻り値スタイルの書きすぎで感覚がおかしくなってる
239:デフォルトの名無しさん
19/01/20 14:32:48.63 Q8jHF7yk.net
printfの戻り値もチェックしろよ
240:デフォルトの名無しさん
19/01/20 14:40:21.16 GKseTsKF.net
>>236
戻り値スタイルに慣れるとレイヤー境界がどこかも定義せずに例外変換をしてしまうようになっちゃうのかな
そして本当に変換が必要な例外は何かということも考えなくなってしまう
必要かどうかわからないけど何かしなきゃって強迫観念に苛まれてるのだろうね
戻り値スタイルだと伝達処理が必須だから例外スタイルになると不安になるのだろうな
241:デフォルトの名無しさん
19/01/20 17:06:39.20 z2xvgkTe.net
戻り値って何？
242:デフォルトの名無しさん
19/01/20 17:27:50.05 wW/QZhoY.net
戻り値を使う例
printf("%d\n",printf("1+2+3="));
243:デフォルトの名無しさん
19/01/20 17:45:51.48 Q2ecPa0m.net
配列・ポインタ・構造体・クラス→「プログラミング楽勝ンゴｗｗｗｗｗｗ」
スレッド・コルーチン・テンプレート→「あばばばば・・・」
244:デフォルトの名無しさん
19/01/20 21:20:28.02 Y8m3wOFq.net
はい誰もコード書かないw
お前らちっさいコードとか異常系の甘いコードしか書いたことないから例外マンセーなんだよ
245:デフォルトの名無しさん
19/01/20 21:31:17.80 .net
やっぱり例外機構はオカルトだった。皆が長い間この銀の弾丸を装った迷信に惑わされ疲弊した
246:デフォルトの名無しさん
19/01/20 21:52:33.91 mVpLWWyp.net
>>244
だから後出し条件出されると困るから戻り値スタイルでコード書いてくれ
って書いてあるだろ
例外とあまり変わらないんだから書けるよね？
247:デフォルトの名無しさん
19/01/20 22:13:54.05 GKseTsKF.net
>>244
>>209
248:はちみつ餃子
19/01/20 22:17:29.98 /TyOXJfP.net
あのなぁ、俺は他の機能についての話で何度か書いてるけど、
適切な場面で適切に使えってだけの話で、
どんな機能だってそんなに万能だと思ってるやつなんていねぇよ。
どうせ回復できない異常ならちまちまと返却値をとりまわして
上まで運ぶのはクソ面倒くせぇし、
その場で対処する必要があるようなものは
try/catch よりも if で書いた方が短くて簡単だし取りこぼしにくいってのはわかる。
どちらにするべきか判断を付けるコストの方がデカいわっていう場面なら
各プロジェクトのポリシーで一方に決めつけたって別にかまわん。
当たり前すぎて主張するのがアホくさいんだけど、
そんなことは場合によるとしか言いようが無いだろ。
249:デフォルトの名無しさん
19/01/20 22:18:21.76 GKseTsKF.net
異常系の処理がシビアになればなるほど例外が有利になる
リターンコードスタイルは複雑化した分岐と大量の変数のせいでミスを誘発しまくる
例外ならば必要な時に必要なだけ異常系の処理を書けばいいので混乱することはない
例外スタイルにはまったく過不足がない
やりたいことをジャストそのまま書けばよろしい
250:デフォルトの名無しさん
19/01/20 22:25:39.40 GTDVzsz1.net
>>248
中身のない長文は要らんよ
251:デフォルトの名無しさん
19/01/20 22:33:30.46 ps+hJNCY.net
例外はその機構が重いから極端な異常系にしか使わないようにしてるのも今は昔の考え方なのかな
252:デフォルトの名無しさん
19/01/20 22:36:51.24 XHg9p3tl.net
>>250
ここ数10レスほど続いていた中身のない不毛なやり取りより>>248の1レスの方が有意義だと思うぞ
253:デフォルトの名無しさん
19/01/20 22:39:23.56 GTDVzsz1.net
>>252
お前もな～
254:デフォルトの名無しさん
19/01/20 22:55:26.02 GKseTsKF.net
>>251
そもそも正常系では例外の方が速い
255:デフォルトの名無しさん
19/01/20 23:31:58.94 PO2ZqArQ.net
>戻り値スタイルに慣れるとレイヤー境界がどこかも定義せずに例外変換をしてしまうようになっちゃうのかな
レイヤーの境界やエラーの粒度の違いに頓着しないのは、どっちかというと安直に例外投げれば良いと
考えている方のような気がするがな。
この一連の発言見ても、投げた例外が誤ってレイヤー境界を越えてしまわないようどう保証するかなんて
言及してた人いないでしょ。
256:はちみつ餃子
19/01/21 00:00:25.72 seIeK7lJ.net
>>251
例外にもいくつかの方式があって、SJLJ ってやつは例外を投げないときもやたら遅いが、
他のほとんどの方式は例外を投げないときはゼロに近いコストのはず。
ただ、 SJLJ 以外の方法というのはデバッグ情報を使うためにツールチェインとの連携が必須だとか、
ハードウェアの機能を使うとかいった制約があって移植性に難があったりもするので、 SJLJ も滅びずに残ってる。
要するに例外の処理速度は場合によるが、
普通のデスクトップコンピュータで SJLJ を使わざるを得ないようなみみっちいツールチェイン、ハードウェアって
ことはあんまりなかろうと思う。 (ある？)
257:デフォルトの名無しさん
19/01/21 00:16:50.05 xYP7RvSv.net
>>255
リターンコードスタイルはレイヤ境界どころか体系的にエラー処理を考えるということをしないからなぁ
例外スタイルの人はじゃあどこで処理すんのということもちゃんと考えてる
258:デフォルトの名無しさん
19/01/21 02:42:47.97 sP4gcHu6.net
例外でイベント発生させて、イベントハンドラで受けるのはど？
259:デフォルトの名無しさん
19/01/21 06:13:04.33 NbFzEAOW.net
>>255
> この一連の発言見ても、投げた例外が誤ってレイヤー境界を越えてしまわないようどう保証するかなんて
> 言及してた人いないでしょ。
保証は言語側でやってくれるから言及する必要がないだけのこと
そもそも例外は>>249の言う通りその場所で必要なものをキャッチして処理をすればいいだけ
260:デフォルトの名無しさん
19/01/21 07:28:30.34 sP4gcHu6.net
swith caseで分岐する場合もあれば、
関数へのポインタテーブル作って、ジャンプさせる場合もあるわけで、
例外も戻り値分岐も両方普通に使わないか？
C++てイベントとかイベントハンドラは環境とかboost任せで、言語仕様としては未だに確定してないのか？
C++11でようやくマルチスレッドや排他制御が仕様に盛り込まれたり、
テンプレートの仕様いじくるよりこっちの方がよっぽど大事なんじゃないのか？
261:デフォルトの名無しさん
19/01/21 08:25:41.60 vJCo0PxF.net
>保証は言語側でやってくれるから言及する必要がないだけのこと
保証なんてしないよね？catch忘れたらそのまま上まですっ飛んでいくだけ。
Javaのような検査例外ならそこに差異があることを意識されられるかもしれないけど。
>そもそも例外は>>249の言う通りその場所で必要なものをキャッチして処理をすればいいだけ
そこでプログラマが考える「必要なもの」から漏れた例外は上位へ渡されてしまう。
それを防ぐためには呼び出し先から送られる可能性のあるすべての例外を把握する必要があるが、
検査例外がないなら動的型付言語のように投げる側と受け取る側とで平仄を合わせてやるしかない。
262:デフォルトの名無しさん
19/01/21 08:37:50.82 Kndge7xV.net
大前提が間違ってる
例外なんか最終的にはフレームワークが最上位で纏めてキャッチすりゃいいんだよ
途中でキャッチして処理するのはあくまでベターなオプションであり、それを必須とするような作りにしてはいけない
263:デフォルトの名無しさん
19/01/21 08:55:24.27 NbFzEAOW.net
>>261
> catch忘れたらそのまま上まですっ飛んでいくだけ。
闇雲にキャッチしたいならcatch(...)ってやればいいだけ w
> そこでプログラマが考える「必要なもの」から漏れた例外は上位へ渡されてしまう。
本来キャッチが必要な例外を漏らしているならそれはバグ
それは戻り値スタイルでも同じ話
違うのは例外はキャッチする必要の無い例外についてはそこで考慮する必要はない、自動的に上位に渡されるから上位の然るべき場所で考慮すればいいから
それが>>249の言う
> 例外ならば必要な時に必要なだけ異常系の処理を書けばいいので混乱することはない
ってこと
264:デフォルトの名無しさん
19/01/21 08:56:49.38 vJCo0PxF.net
>>262
半分同意。
結局のところエラーの種類に応じてきっちり対処するなら検査例外的な仕組みが必要になるが
そうでなければエラーの内容など見ずにlet it crash的に対処するしかない。
どっちつかずが一番ダメなやつ。
265:デフォルトの名無しさん
19/01/21 08:58:29.41 Kndge7xV.net
(検査例外とかいうJava自身も認める失敗作は論外として、)例外機構は正しく使えばエラー処理に対する関心の分離に有効なんだよ。
ところがC++では例外を煩わしいノイズと見做す人が多い。これは即ち関心の分離ができてないわけだ。
その一番の原因は、例外型がロクに標準化されてないことだろうね。
最上位での集約処理を実現するには、下位の全てのコードが制御下になければならない。
これは膨大な既存資産と貧弱な標準ライブラリを持つC++においては非現実的な前提である。
266:デフォルトの名無しさん
19/01/21 08:58:39.64 unEY8tjt.net
すべての例外を把握する必要はない
回復可能かつ回復が要件に含まれるなら個別に処理すべき
それ以外はアスペクトで処理すればいい
267:デフォルトの名無しさん
19/01/21 09:04:47.90 nVlZ7k5e.net
>>247
だからさ、比較できるように例外スタイルで一度きちっと異常系対応して
かつスーパーエレガントなのを書いてくれよって言ってんの
お前のは体よく異常系の処理全無視してるだけじゃん
catchしたい人が必要なところでcatchすればとか言うんだろうけど
例外発生場所から遠くなればなるだけ何が原因で例外が発生して、
その回避はどうすればいいかが不明瞭になっていくってのは
散々語られてる例外の欠点
リターンコードは泥臭いが下層からくるエラーをどう処理してるかはコード見れば一目瞭然
エラーを上位に伝搬させるか、リカバリーするか、その場でクラッシュさせるか
ローカルに記述が完結できてる
APIとして外部に公開するときもインタフェースの仕様にきっちり責任持たせることができる
ちなみにプルリクでレビューする文化があればエラー無視してるような雑はコードは突き返されるだろう
見ればすぐわかるんだから
大規模な開発を経験したことない人はこういう観点でソフトウェア開発を
考えられないんだよ
最後にもう一度言っておくけどおれは例外を完全否定してるわけじゃねーから
使える場所は限られるって意見ね
268:デフォルトの名無しさん
19/01/21 09:07:50.76 nVlZ7k5e.net
>>262
> 大前提が間違ってる
> 例外なんか最終的にはフレームワークが最上位で纏めてキャッチすりゃいいんだよ
これがど素人の意見
ソフトウェアの品質について考えたことがない
269:デフォルトの名無しさん
19/01/21 09:11:48.87 nVlZ7k5e.net
「不正な入力です」
「ネットワークでエラーが発生しました」
「書き込みに失敗しました」
こういう情けないダイアログが表示させて終わりのアプリを作るやつね
270:デフォルトの名無しさん
19/01/21 09:19:18.64 9okmCQOj.net
>>269
それでも正常に回復できてるならそれでいいケースは多い
例外の最大の利点は例外安全さえ死守できていればアドホックな例外処理が必須でなくなることで、
より丁寧な処理が必要になれば後から追加すればよい
まあ組み込みとかやってる人には馴染まない考え方だろうね
271:デフォルトの名無しさん
19/01/21 09:35:09.59 9okmCQOj.net
まあC++開発者が未処理例外=クラッシュと短絡的に考えてしまう気持ちはよく分かるよ
呼び出し階層の途中に一つでも if (hoge() != SUCCESS) errorhandle(); があれば例外安全は破綻するわけで、あまりにも非現実的
272:デフォルトの名無しさん
19/01/21 09:54:05.98 NbFzEAOW.net
>>267
仕様は>>218が決めるんだから>>218がコードを提示すべき
>>236みたいに後出しの条件出されても困るからな
273:デフォルトの名無しさん
19/01/21 10:02:59.35 +Z2Zhk1G.net
>>267
> 例外発生場所から遠くなればなるだけ何が原因で例外が発生して、
> その回避はどうすればいいかが不明瞭になっていくってのは
> 散々語られてる例外の欠点
それ戻り値スタイルでも同じだろ
> リターンコードは泥臭いが下層からくるエラーをどう処理してるかはコード見れば一目瞭然
だからそれはすぐ上位で処理することが前提になってるだろ
上位に何度も伝搬したら例外と同じになる上に伝搬するコードをそこら中に書く羽目になる
> ちなみにプルリクでレビューする文化があればエラー無視してるような雑はコードは突き返されるだろう
例外処理を書かないことはエラーを無視するんじゃなくてそのまま上位に伝搬してるだけ
書かないと無視してると取るのは例外をきちんと理解してないってこと
> 見ればすぐわかるんだから
お前の能力がな w
274:デフォルトの名無しさん
19/01/21 12:21:37.48 Di3L4KSP.net
>>267
例外を使いこなせていないね
例外の型とパラメータをみれば何が起こったかはっきりわかる
おそらく君は例外の種類を使い分ける習慣がないだろ？
あったとしてもせいぜい標準ライブラリの例外をなんとなくふり分ける程度だろうね
でないとこんな発言はしないから
まずは例外を定義するところから初めてごらん
それと大規模開発をしたことがないのはそちらだろう
関数コールするたびにずらずらと変数や分岐を書かれたらあっという間に管理不能になる
大規模だからこそ標準的なコード、必要十分なコードというのが大切になる
275:デフォルトの名無しさん
19/01/21 12:52:23.62 Di3L4KSP.net
リターンコードスタイルをレビューに出すと袋叩きにされるぞ
・ノイズが多すぎて正常系のレビューが不可能
・同じくどのエラーが上位伝達、エラー変換、共通対応、個別対応なのか見てすぐにわからない
・同じく要件漏れを見落としやすい
・正常系、異常系、判断、伝達などあらゆる要素が密集して強く結合しているため仕様変更があった場合の影響が大きすぎてレビューしきれない
276:デフォルトの名無しさん
19/01/21 13:00:29.05 9okmCQOj.net
>>275
考え方自体には同意するけど、>>271で示したように例外安全が破綻しているケースについてどう考える?
エラーコードを前提にクリーンアップ処理が記述されているコードが混入しているような場合ね
あくまでC++に限った話だけど、大規模開発で完全な例外安全を維持するのは極めて困難だか実際には絵に書いた餅と思ってる
277:デフォルトの名無しさん
19/01/21 13:01:15.22 9okmCQOj.net
>>276
訂正
極めて困難で、実際には絵に描いた餅
278:デフォルトの名無しさん
19/01/21 13:05:57.47 eQbQQa6X.net
レビュアーの経験値不足って感が否めない
279:デフォルトの名無しさん
19/01/21 13:14:15.22 NbFzEAOW.net
>>276-277
必要なら直せばいいだけ
非常に稀な事象についてまで例外安全を遵守する必要はないでしょ
そもそもそういう変なコードが混入してる体質の組織で何を言ってるんだよ？ って話だと思うけど
280:デフォルトの名無しさん
19/01/21 13:20:41.40 9okmCQOj.net
>>279
文化と素養の問題だよ
例外の是非でこれだけ荒れる現状を見てれば、例外のスルーなんて怖くてできねえよ
そりゃあんたが全てのコードをレビューしてマサカリ投げまくってくれるなら別だけどねえ
281:デフォルトの名無しさん
19/01/21 13:46:08.82 NbFzEAOW.net
>>280
ごめん、言ってることがよくわからん
そもそも
if (hoge() != SUCCESS) errorhandle();
なんてコードがあったら戻り値スタイルでもどうしようもない
例外は魔法の杖じゃないんだから何でもかんでも例外使えば解決するわけじゃなくて戻り値スタイルより楽にできるというだけの事だよ
プログラムがデカくなるほどその差は開くけど
282:デフォルトの名無しさん
19/01/21 15:00:28.97 9okmCQOj.net
>>281
result = hogehoge();
if (failure(result)) エラー処理();
リソース解放();
これhogehogeが例外起こしたらリークするだろ
283:デフォルトの名無しさん
19/01/21 15:09:35.03 NbFzEAOW.net
>>282
スマートポインタ使うなりcatchしてリソース解放して例外再送出するなりいくらでもやりようはあるだろ…
ちょっとレベル低くね？
284:デフォルトの名無しさん
19/01/21 15:25:30.15 9okmCQOj.net
>>283
だからそれが例外安全だよ
勉強になったね
285:デフォルトの名無しさん
19/01/21 15:27:04.68 NbFzEAOW.net
流石に恥ずかしくね？ w
286:デフォルトの名無しさん
19/01/21 15:51:37.78 GjW/cezm.net
>>283
基本的にデストラクタやリソース開放系は例外投げられると大変なことになる
catchしてなんて簡単にいってるけどもcatch(...)をそこに入れることになるのはわかるかね
287:デフォルトの名無しさん
19/01/21 16:15:33.27 NbFzEAOW.net
で、そんな当たり前のことを言って何が言いたいの？
聞きかじりの知識を披露してるとしか思えないんだが… w
288:デフォルトの名無しさん
19/01/21 18:01:37.80 .net
例外機構は宗教
多くの人が正しいと盲信しているに過ぎない
289:デフォルトの名無しさん
19/01/21 21:32:31.75 sP4gcHu6.net
戻り値でイベント投げるという選択肢がない言語使用自体くそじゃね？
290:デフォルトの名無しさん
19/01/21 22:06:05.18 5kYBxhZB.net
Cにそんな機能あったっけ？
それとも別の言語の信者が折伏に来ているの？
291:デフォルトの名無しさん
19/01/21 23:00:01.73 vJCo0PxF.net
>>265
そう、検査例外を正しく使うのはしばしば困難で批判も多いな。ただ、呼び出す処理がどのような
例外を返すか、静的な型検査による保証を与えてくれる仕組みとしては他に無いのも事実。
検査例外を否定するのであれば例外型に頼らない(>>264の後者)か、プログラマの努力で
整合をとってやる(>>261の最後)カウボーイ的プログラミングになる。
>>265はあくまでも例外に型を期待しているようだからカウボーイの方なんだろう。
292:
19/01/21 23:52:35.55 N0KGcgmj.net
>>291
＞プログラマの努力で整合をとってやる(>>261の最後)カウボーイ的プログラミングになる。
…
…
これって「カウボーイ的」と形容されるべきものだったんですか？
catch の引数は値ではなくて、「型」だから、
テキトーな super class ERROR の下に個別エラー用派生クラスを列挙しておき、
臨機応変に catch (ERROR &e) を噛ましています…
>>256
一応例外を投げておくけれども、まじめにサポートする気はさらさらなく、
そもそもやる気は皆無・全くゼロであることを、ただ、それだけを全心全霊で表現するためだけに
throw 13;
293:はちみつ餃子
19/01/22 02:54:09.24 FdSNzm47.net
例外の処理速度については、こういう提案もある。
URLﾘﾝｸ(ezoeryou.github.io)
要するに、投げるオブジェクトが条件を満たすときは、
暗黙の返却値のような形で例外を伝播する仕組み。
バイナリレベルの取り扱いも ABI を決めさえすれば済むだろうし、
互換性も確保しやすそうに思う。