[過去ﾛｸﾞ] C++相談室 part165 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
49: デフォルトの名無しさん (ﾜｯﾁｮｲ e5a7-cSrA) [sage] 2023/11/09(木) 21:28:58.67 ID:Op1F6lz40(3/3) AAS
てかググったら簡単なシミュレーション方法載せてるブログあった
_fastcallで宣言して第二引数のedxを捨て駒にする事で疑似_thiscallになる
つまりint(__fastcall * pFunc)(CDate*, void*, int)とすれば一応アセンブラ的な辻褄は合う事になる
299(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 1b63-9XlH) [sage] 2024/03/02(土) 23:57:46.67 ID:C77pR/Zl0(3/3) AAS
それはそうとして、予防的なtry{ } catch () の何が一番駄目かというと、設計上のトレードオフをわけわかんなくすることが確実な点
例外発生後の状況というのはたいてい>>283283(5): デフォルトの名無しさん (ﾜｯﾁｮｲ 1e85-XyAm) [] 2024/02/17(土) 23:18:00.46 ID:v62CV0mD0(1) AAS
>>278
> そもそも致命的な例外でアプリケーション自身の継続が困難な場合を除いて
> どんな例外でもあっても継続的な処理を可能にするのが例外処理だろうに
それは幻想
c++の例外安全の達成がどれだけ難しいか理解していないね
簡単にリークするし、オブジェクトが想定外の状態を持ったりする
動作保証ができない
だから仕様に明示されていない例外が来たら基本は終了だよ
そのまま継続してそれが原因でその後別の場所で落ちられたら無駄な調査の手間が増えるだけ
の通りのわけなので、何かを捨てて何かを取る
（例えばシステムは最悪落ちても構わないが、例外安全なオブジェクトfooでリソースAの整合性は死守する等）
のトレードオフが発生するがそういうのこそ慎重な設計と考慮が必要な事項であることは確定的にあきらか
プログラムの全階層にtry { } catch ()入れたら完璧などというｱﾌｫはやっぱtry { } catch () しないのが正しい
308: デフォルトの名無しさん (ﾜｯﾁｮｲ 9fad-ZLJX) [sage] 2024/03/04(月) 08:50:22.67 ID:MzjtGtOW0(1) AAS
> なんか予想外に低ﾚなレスポンスを寄越した>>299……
299はお前自身じゃないのか、と俺は思う
328: デフォルトの名無しさん (ﾜｯﾁｮｲ 8f7c-Y/5H) [sage] 2024/05/09(木) 20:23:09.67 ID:MzADiHDk0(1) AAS
外部ﾘﾝｸ[html]:cpprefjp.github.io
#elifって今まで非標準だったのかよ…
334: デフォルトの名無しさん (ﾜｯﾁｮｲ bbda-JG92) [sage] 2024/05/11(土) 22:20:47.67 ID:HBPowvO20(1) AAS
シェルが変だからな
case ～ esac
if ～ fi
602: デフォルトの名無しさん (ﾜｯﾁｮｲ bf6c-6oxW) [sage] 2024/11/29(金) 16:19:14.67 ID:xzsI3pih0(1) AAS
なんでもできるは他を知らないだけだろ
699: デフォルトの名無しさん (ﾜｯﾁｮｲ 6e76-ctcc) [sage] 2025/02/27(木) 11:05:40.67 ID:+3VmvrWI0(1) AAS
>>698ありがとうございます
最近勉強を始めましたので分からないことがありましたらご教示いただければと思います
961(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 5e85-M5IX) [sage] 2025/04/23(水) 23:23:42.67 ID:1cvTRmDz0(1) AAS
いまだにgoto論とかw
いかに効率的にAIに作らせるかの時代だぞ
誤差レベルの最適化なんかやってる場合かよ
999: デフォルトの名無しさん (ｽﾌｯ Sdbf-Nh+M) [] 2025/04/28(月) 10:15:47.67 ID:3WBgyNGdd(1) AAS
連接と分岐があれば反復は要らない説
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.036s