[過去ログ] C++相談室 part157 (1002レス)
1-

このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
203
(2): 2021/09/01(水)16:43 ID:Uxp79PtR(1) AAS
Rustみたいにコンパイル時にいちいち参照のチェックするんじゃなくて
C++で最終的に完成したバイナリに対してメモリサニタイザーを一回動かす
ってのではだめな理由ある?
204: 2021/09/01(水)20:16 ID:dG55Jwur(1) AAS
>>203 動かしたフロー以外のフローについて不安が残るし、サニタイザーの精度がどれほどかという問題もありそう。
205: はちみつ餃子 ◆8X2XSCHEME 2021/09/01(水)23:35 ID:3mB0e8fG(1) AAS
>>203
ものによって賢さの程度が違うから一概には言えないけど
基本的にはサニタイザは実際に起こった問題を検出するものなので
入力値次第で問題が有ったりなかったりするようなケースを検出できなかったり、
言語仕様上で未定義なものがたまたま問題ないアクセスになってしまうようなケースも
検出できないかもしれない。

問題が起こっていて再現条件が分かっているときに検証するツール、つまりデバッグ用のツール
としてはサニタイザは有用だし、ごく基本的なテストツールとしても使えるけど、
Rust のライフタイムチェックほど網羅的ではない。
206: 2021/09/02(木)05:18 ID:90/tsZBA(1) AAS
一言でまとめると動的試験てことだな
207
(3): 2021/09/03(金)09:16 ID:6YHhlfzl(1/3) AAS
MozillaのFireFoxの場合、わざとクラッカーがセキュリティーホールを見つけ出して
そこを付いてくるから、普段の実行テストでは一度も発見できなかった
メモリーバグが問題になるが、普通のアプリの場合、ユーザーがわざとバグを
付くことはないから、そのようなホールはあまり関係ないと思う。
テスト駆動開発とかアジャイル開発とかも、普段使いで問題が無いかをテスト
することで大部分のバグが無い状態で開発していこうとする考え方。
それでもほとんどのメモリーバグは無い状態になっている。
メモリーバグがあると、普段使い的なテストをしても発覚することが多いから。
昔から言われているメモリーバグの問題点は、再現性が有る場合でも、バグが
ある行とそれが発覚した時期とがずれていることがあるから。
省7
208
(1): 2021/09/03(金)09:22 ID:6YHhlfzl(2/3) AAS
>>207
例えば、ダングリングポインタ(Use After Free)は、ptrがどこかでまだ使用中なのに、
free(ptr)としてしまうこと。しかし、そのfree()をした時点ではアプリはダウン
しないし、ptrに対して読み書きした段階でもまだ発覚せず、ptrが指すメモリー
アドレスを別の目的で使用してしまって、お互いに読み書きがある種の干渉を
起こしてしまって、データがめちゃくちゃになり、それによってどこかで不具合
が生じた時点で発覚する。
なので、バグの根本原因であるfree(ptr)を実行した行がどこかを探し出しにくいと
される。
しかし、このバグの場所とバグが起きた場所のずれは、デバッグビルド時に速度を
省1
209: 2021/09/03(金)09:24 ID:6YHhlfzl(3/3) AAS
>>208
チェックと言っても人間が手で書く必要は無く、コンパイラがチェックコードを
自動生成できるはず。
210: 2021/09/03(金)10:00 ID:yL2Kwy6+(1) AAS
根拠のない決めつけばかりで気持ち悪い。
211: 2021/09/03(金)10:16 ID:lmzB7IZ6(1/3) AAS
>>207
世の中にはテスターという職種の人がいてだな
212: 2021/09/03(金)10:46 ID:yJUEU9nq(1/2) AAS
>>207
任意のファイルを読むアプリはファイルのパーサーの脆弱性をついてユーザ権限でコードを実行される可能性がある
どちらかと言えばアプリよりサーバとしてアクセスを受け付けているプログラムの脆弱性をつかれて攻撃コードの実行を許してしまうことが多い
さらに上のような場合でも、アプリやサーバのプログラム自体に脆弱性があるのではなく、使用しているOSのAPI側の実装の脆弱性をつかれる可能性がある

こういうアプリやサーバやOSのコードの脆弱性にMSやGoogleは悩まされている
213: 2021/09/03(金)11:00 ID:yJUEU9nq(2/2) AAS
Valgrind と言う動的解析ツールを調べて見るといい
うちはC++のプログラムは基本これを通すことになってる
商用ならもっといいツールもあるかも知れない
そういうのを利用しても充分でないから静的解析するRustが注目されている
214: 2021/09/03(金)11:27 ID:6Xh4x7Us(1/3) AAS
商用の静的解析ツール使ってると、正直メモリ関係のバグなんてありえないと思えるくらいいろいろ見つけてくれるよ
215: 2021/09/03(金)11:44 ID:9y+1HwQb(1) AAS
コンパイル時間に糸目を付けなければ、静的解析はもっと出来る。
216: 2021/09/03(金)11:47 ID:lmzB7IZ6(2/3) AAS
> メモリ関係のバグなんてありえないと思える

lintの副作用がモロに出てるなw
217: 2021/09/03(金)15:20 ID:MvVz2a9W(1) AAS
言うまでもない事だが完璧なメモリチェッカーは存在し得ない
停止問題と同値だからな
218: 2021/09/03(金)15:50 ID:6Xh4x7Us(2/3) AAS
完璧無理っておまえの毛髪の量がプログラム停止に与える影響が読めないとかそういう話だろ?
限定的な範囲で正しけりゃ十分だよ
219: 2021/09/03(金)16:54 ID:lmzB7IZ6(3/3) AAS
ゴールポストは動かしちゃダメだよ
220: 2021/09/03(金)17:38 ID:6Xh4x7Us(3/3) AAS
無限遠のゴールを設定するのはアホだべ
221: 2021/09/03(金)17:51 ID:xmwLNRYX(1/2) AAS
スクリプト言語も普通にクラッシュすることあるから
222: 2021/09/03(金)17:52 ID:xmwLNRYX(2/2) AAS
OSのコアダンプ出力とリブートに救われる手のひらの孫悟空
223
(2): 2021/09/03(金)18:28 ID:iCLUv6gH(1) AAS
rustでもメモリアロケーション失敗するとパニックになる、てリーナスが突っ込んでいたろ。
c++の場合はどうなんのかな。
224: 2021/09/03(金)20:13 ID:USKNPKWa(1) AAS
CoverityとVectorCASTは使ったことあるけど検知レベル最高にしても見逃すリークや二重フリー, ダングリングはそれなりにある (そもそもコードの構造が悪い場合も多いが)
検知レベル上げ過ぎると逆にFalse Positiveも増えるし
225: 2021/09/04(土)07:59 ID:kFVsNuY8(1) AAS
無限遠のゴールポストを動かすって
こいつ文系か?
226: 2021/09/04(土)08:08 ID:N/QuNfWR(1) AAS
まあ見つからないのは間違いなく書き方が悪いよな
227: 2021/09/04(土)19:04 ID:7+pvijvQ(1) AAS
∞の概念が理解できるならそいつはもう文系ではあるまい
228: 2021/09/04(土)19:11 ID:ICKB9ww0(1) AAS
ε-N論法
229: 2021/09/04(土)22:28 ID:mLTAxmCN(1) AAS
超久しぶりにC++の参考書 買った。
いまってC++20までいってるんでしょ?

時代遅れもいいところだから勉強しようと思ってw

ただ読む気がおきない。
「pythonでいいか」って思いが・・・ww
230
(4): ハノン ◆QZaw55cn4c 2021/09/04(土)23:52 AAS
>>223
外部リンク[html]:tabesugi.net
C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために
さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが
簡単に生産されるようになってる。正直いって、C を選ぶ理由が C++ プログラマーを
追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。

C++ はトンでもなく悪い設計の元になりうる。どうせこの言語ではいつも STL やら
Boost やら、その他ゲロゲロベロベロの「素敵な」ライブラリの機能を使って、
それがあんたのプログラムに「役立つ」んだろうが、以下のことが起きる:

- うまく動かないときにもたらされる際限のない苦痛 (あと STL とか、特に Boost が
省11
231: 2021/09/05(日)00:05 ID:yIsM5ONG(1/3) AAS
バカが使いこなせる言語ではないからな
232: 2021/09/05(日)00:27 ID:eMsTCIh+(1/3) AAS
linusに言われると返す言葉もないが、その後の文脈にある

『もし C++ で書かれた VCS が欲しいのなら、Monotone を見てみるといい。
ほんとに。連中は「本物のデータベース」を使っているよ。
「素敵なオブジェクト指向ライブラリ」も使ってる。「ナイスな C++ の抽象化」も
使ってる。そして率直なことろ、一部の情報系の人間が喜びそうな
これらすべての設計上の決定のために、できてきた結果はゲロゲロで
保守不可能なカオスだ。

でもあんたはきっと git よりも気に入るだろう。保証するよ。』

な感じでC++を気に入って、夢を見ていたいんだろうね。
233: 2021/09/05(日)00:53 ID:66hkUr5p(1/2) AAS
「オレはC++を使いこなせている」と思い込む素人を生温かく見守るスレはここですね
234
(1): 2021/09/05(日)01:42 ID:eMsTCIh+(2/3) AAS
>>223
外部リンク:lkml.org
コレのことだと思うけど、どういうケースを想定しているの?
235: 2021/09/05(日)06:00 ID:fsFc+8nQ(1) AAS
昔、バカでも使える言語でプログラマ人口増やしましょうてなことやってたな
BASICじゃないぞ、あれは初心者用で、バカ用じゃない

計算を数式で書くのは理系だけだから
英文で書けるようにして文系でも使えるようにしようという試みがあった

で、狙いどおり本当にバカプログラマを量産できた
それでいいことあったか?

C++はアレの逆をいっているわけだ
236: 2021/09/05(日)06:45 ID:ClPlKiJv(1) AAS
Qtを使ってるから、C++一択だな。
237: 2021/09/05(日)12:24 ID:cBh+EO/A(1/7) AAS
namespaceと多態性はCだけではやりにくい
238: 2021/09/05(日)12:47 ID:0Cj96kG7(1/2) AAS
静的なディスパッチの充実がCに必要なのではないか
239
(1): 2021/09/05(日)14:17 ID:cBh+EO/A(2/7) AAS
>>234
Linuxはモノリシックカーネルなので動的メモリ確保を伴うような軟弱な
モジュールもカーネルのうちに入ってしまっているからメモリ不足ぐらいで
パニくられると手の打ちようがないから困るという話なんじゃないの(適当

OSはリソース管理を放り投げて停止することは許されないから
伝統的なやり方では起動時に非常用のメモリブロックをアロケートしておいて
メモリが枯渇したら非常用のメモリブロックを使うみたいな手段がとられる(と思う
がパニックされたらそこまで行きつかない

※ 個人の感想です
240: 2021/09/05(日)14:38 ID:eMsTCIh+(3/3) AAS
>>239
具体的に何かのケースを想定して言ってるわけじゃないのか。
ぶっちゃけOSをC++で書くならカーネルでnew/malloc/mmapとか使う実装はしないだろうし、処理系が使うランタイムにも依存するけど基本その辺はカスタマイズできるようになってると思う。
rustでもそんな感じで処理系次第って話だと思う。
241
(1): 2021/09/05(日)14:44 ID:LgQhIBwq(1) AAS
>>230
馬鹿除けのために C++ じゃなくてあえて C を使うのは良いね
動画リンク[YouTube]
242
(6): ハノン ◆QZaw55cn4c 2021/09/05(日)17:28 AAS
>>241
>>230 の類の話は昔からいわれていたもので、これも有名ですね
外部リンク[html]:www.kh.rim.or.jp

インタビューア(以下「I」): あなたがソフトウェアデザインの世界を一変させてから何年にもなる。振り返ってみて、感想は。
Stroustrup(以下「S」): 実はあなたがここへ来る直前、当時のことを思い出していたんだ。おぼえているかな。誰もが C 言語を使っていたけど、問題はみんな結構うまくコーディングしていたことだった。
大学も C 言語を教えるのがうまくなっていたしね。驚異的な割合で有能な――「有能」という言葉は強調しておきたい――卒業生を量産していた。それが問題の原因だったんだ

S: ある日、オフィスにいたときに、ある策略を思いついたんだ。バランスを少し回復させる策略をね。「プログラマが余るなんてことが絶対にありえないくらい、複雑でおぼえにくい言語があったらどうなるかな」ってね。
実は、この考えの一部は X10――例の X Window の――から頂いたんだ。あれはひどいグラフィックシステムでね、Sun 3/60とかでないと動かなかった。
ばかばかしいくらい複雑な構文規則とか、わかりにくい関数とか、疑似オブジェクト指向的な構造とか、僕がほしいと思う要素は全部揃っていたんだよね。
省12
243
(1): 2021/09/05(日)17:47 ID:eWmYSwWp(1) AAS
>>242
とっくに否定済みのデマを貼るな
外部リンク[html]:www.stroustrup.com
244
(3): 2021/09/05(日)18:05 ID:Lkm6/1Sl(1) AAS
外部リンク:ideone.com
これが、シングルトンとして抜けている理由を教えて下し亜。
コードのストックにするために書いたのですが、そもそもシングルトンってなんでしたっけ?
245
(1): ハノン ◆QZaw55cn4c 2021/09/05(日)18:06 AAS
>>243
誰が書いたかなどどうでもよく、その内容についてはどう思いますか?
246
(2): はちみつ餃子 ◆8X2XSCHEME 2021/09/05(日)18:10 ID:vh6AiUnJ(1) AAS
>>244
関数テンプレートが結果的に引数の数が違う関数として展開される。
引数の数の違いが結果の違い。
247
(2): 2021/09/05(日)18:23 ID:cBh+EO/A(3/7) AAS
>static std::shared_ptr<T> O = std::make_shared<T>(A...);
の部分って、Singleton()の初回呼び出しが複数のスレッドから同時に起こってもき
ちんと排他してくれるんでした
っけ

また排他してくれるとしても最速(そのアーキテクチャ(マルチコアかもしれない)で最も適切)
であることを気体していいんでしたっけ……
つまり生成に成功した後は排他不要なわけで、無駄にロックを取りに行きたくない……
248
(1): 2021/09/05(日)18:24 ID:yIsM5ONG(2/3) AAS
>>242
おまえホント頭悪いな
249: 2021/09/05(日)18:27 ID:cBh+EO/A(4/7) AAS
みたいな配慮がシングルトンにしたとたんに必要になる
メインの処理が始まる前に普通の初期化関数呼び出しでOを生成したらそれで済むのに、、、
250
(1): 2021/09/05(日)18:28 ID:0Cj96kG7(2/2) AAS
>>247
呼ばれたところで最後の奴が勝てば問題ないのでは
251
(1): 2021/09/05(日)18:47 ID:cBh+EO/A(5/7) AAS
>>250
ある
>static std::shared_ptr<T> O = std::make_shared<T>(A...);
全体が排他されないとしたら、Oの生成関数(初期化式「O=」の右辺)が複数回、
それも同期的に繰り返し呼ばれるのではなく、非同期的に再入される形で呼ばれかねない
生成関数の中でリソース確保するとしたら先の呼び出しで確保したリソースの
ハンドルがdunglingにならないように配慮が必要になる
非同期的再入ということは、Oが生成→破棄→生成→破棄、にならず、
生成→生成→破棄→破棄になりかねないから、デストラクタをちゃんと書いたらリークしないとか
そういう認識で当たったらバグる
省2
252: 2021/09/05(日)18:50 ID:nyuo1Vq1(1) AAS
>>245
お前の質問なんかどうでもいいからデマを貼るな
253: 2021/09/05(日)19:08 ID:UYU4AxET(1) AAS
>>247 外部リンク[dcl]:timsong-cpp.github.io
254
(1): 2021/09/05(日)19:10 ID:2jP3+tuQ(1) AAS
>>246を踏まえるとこんな感じか
関数テンプレートだけで済ます方法はあるのかな?

外部リンク:ideone.com
255
(2): ハノン ◆QZaw55cn4c 2021/09/05(日)21:38 AAS
>>248
はい、頭も性格も悪いと思います、しかし >>242 の中のどういうところが悪いとお考えになったのか教えていただくと嬉しいです!!
256: 2021/09/05(日)22:21 ID:TAzC3d8r(1) AAS
>>255
そもそも、C++の生みの親で、それに関する書籍を出してその中でC++を
良い言語と自負して(それ以上の言語が出来ないというような主張も幾度もして)
解説し、まだ推進しようとしている人が、C++を徹底的に卑下するかどうかを
疑問に思ってないことも頭が悪いと思われる原因の一つ。
257: 2021/09/05(日)22:29 ID:15q7gB85(1) AAS
実際、C++は、特に初期の頃はCより全面的に優れていると誰でも思えるような
物であって、ちゃんと世界的に認められて広まっていたのに、その部分まで
全否定するようなことをインタビューで答えるわけがない。
その後に追加されて機能は人により評価が分かれて全面的に優れているとは
思えるようなものではなくなっていた。
だから、C++11は、好きな人も居れば嫌いな人も居る。C++98より全面的に
優れていると言えるかどうかは人により評価が分かれるので、好みにより
文壇の様なものが生じている。
258
(2): 2021/09/05(日)22:30 ID:cBh+EO/A(6/7) AAS
>>254
ひ、日本語でおk、、、

>If control enters the declaration concurrently while the variable is being initialized, the concurrent execution shall wait for completion of the initialization.85
>If control re-enters the declaration recursively while the variable is being initialized, the behavior is undefined.
はどう読めばいいの?
結局concurrentlyにre-enterされるときはbehavior is undefinedとしか読めなさげ

>>254
以上の状況なので>>244の糞コードは直しても仕方が無い
259
(1): 2021/09/05(日)22:36 ID:66hkUr5p(2/2) AAS
メモリを自動解放するfinally機能さえあればCでも大丈夫とは思う
260: 2021/09/05(日)22:50 ID:yIsM5ONG(3/3) AAS
画像リンク[jpg]:imgur.com
261: 2021/09/05(日)22:52 ID:cBh+EO/A(7/7) AAS
とオモタがcontrol enters the declaration concurrently のときは初期化のcompletionまでshall waitで、
ただしrecursivelyだとイカン(未定義動作)と書いてあるのか……
つまりSingleton()関数内の初期化式「O=」の右辺がSingleton()を呼び出す場合か

まあ確かにWindousみたいに特殊な仕様のクリティカルセクションでもない限りデッドロックしそう
262: 2021/09/05(日)23:09 ID:eTOvJaZ9(1) AAS
>>251
そうか
まあ仕様的にはスレッドセーフだわ
関係ないけど参照したグローバル変数に値が入っとらんで困ったことがあった
263
(2): 2021/09/06(月)00:30 ID:62gS+LUW(1/2) AAS
>>258
なんかスレッド安全性の問題にしたいようだけど、
そもそも>>244の第一の問題点は2番目のSingletonの呼び出しだけ別のオブジェクトを指してしまっている点だよ
stdoutの2行目だけ0になってるだろ?
その原因の説明が>>246というわけだ

すべての関数・クラスを最初からスレッドセーフな設計にしないといけないわけじゃない
264
(2): 2021/09/06(月)04:31 ID:HRRCwLhx(1/2) AAS
>>263
>>258じゃないし、よく分からないけど
外部リンク:ideone.com
ではダメなの?
265
(3): 2021/09/06(月)04:31 ID:G2BRvA3h(1) AAS
ビャーネ・ストロヴストルップその人のインタビューだとは私も考えてませんよ、これはブラックジョークというべきでしょう、まあC++er が気を悪くする理由は理解できますが
それに私も GNU Multi-Precision Library を使うときはC++のラッパの方を使います。C インターフェースの方は使い難くって使い難くって、これはもう罰ゲームですね‥‥
だから演算子のオーバーロードも控えめに使えば有用という立場です、紹介することと賛成することとは別だと思います
2chスレ:tech
266: ハノン ◆QZaw55cn4c 2021/09/06(月)04:40 AAS
テステス
267
(1): 2021/09/06(月)07:17 ID:7SReNX2q(1) AAS
>>263
スレッドセーフでなくともよいシングルトンとか
>メインの処理が始まる前に普通の初期化関数呼び出しでOを生成したらそれで済むのに、、、
で良くね?

>>264
>>263じゃないが非アトミックな操作(初回か否かチェックして初回なら初期化する)
であることが明示される分その書き方の方がマシ
必要なら排他する、不要ならしないという判断ができるから
>すべての関数・クラスを最初からスレッドセーフな設計にしないといけないわけじゃない (>>263
という願いも叶うYO!
268
(1): 2021/09/06(月)08:08 ID:62gS+LUW(2/2) AAS
>>264
確かに普通こんな感じだな
テンプレート別々にすることだけで頭止まってた

>>267
そうだな
書いてはみたがC++でシングルトン使う意味は無いと思う
あれはグローバル変数の無いJavaでグローバル変数を使うためのハックだとか聞いたし
じゃあもう普通にグローバル変数使えばよくね、と
269: 2021/09/06(月)08:45 ID:3/UK3SOv(1) AAS
グローバル変数と同じなのでだめだよな
普通に動的に用意して渡せばよろしい
270: 2021/09/06(月)08:48 ID:HRRCwLhx(2/2) AAS
ログとかアプリの現行設定ファイルとかはSingletonっぽく実装するけどなぁ・・・
インスタンス生成が遅いものはただのグローバルにしたら起動が遅くなるし
271: 2021/09/06(月)09:20 ID:FistWoaj(1) AAS
>>268
最初のデザパタ本であるGOF本はc++とsmalltalkで書かれてるんで、javaは関係ないよ
272: 2021/09/06(月)10:32 ID:d5h9Y6Qi(1/2) AAS
シングルトンはスレッドセーフが実現できれば問題ないでしょ
273
(1): 2021/09/06(月)12:01 ID:KKMECnvR(1) AAS
>>255 >>265
これは「権威に訴える論証」を悪用した主張であり、議論の対象としてはいけない類のもの。
もし真面目に議論したいのなら、少なくともStroustrupの名前は消して内容だけに修正しなくてはならない。

本人も否定しているのに訂正もしないようなフェイク記事は邪悪。それに対してコメントを求めるのは正気を疑う。
274
(2): 2021/09/06(月)12:06 ID:86SPG0/G(1/2) AAS
その昔、こんなクラス作ってたな
class WinMainArguments
{
public:
static HINSTANCE hInstance;
static HINSTANCE hPrevious;
static LPSTR lpszCmdLine;
static int nCmdShow;
};
275
(1): 2021/09/06(月)15:04 ID:DsY+3+kX(1) AAS
>>265
ブラックジョークは大半の人が聴いた瞬間にジョークだと判るから成立する
麦藁禿のあの名文はまさにそれ

だまされてるのは事情を知らない若い人かも知れんな
276
(1): 2021/09/06(月)15:52 ID:86SPG0/G(2/2) AAS
>>265
GMPについて同意見
277
(1): 2021/09/06(月)16:43 ID:akmYwjNo(1) AAS
>>274
ネームスペースつかえよバカww
278
(1): 2021/09/06(月)16:51 ID:5nha9zO6(1) AAS
>>277
初期のc++には名前空間が無くてなぁ。
標準化する前だから良く知らんが。
279
(1): 2021/09/06(月)17:50 ID:xrgLRigr(1) AAS
その初期のC++ってもしかしてEC++とかいうパチモンじゃないですかね
280: 2021/09/06(月)17:51 ID:ugWeBDlD(1) AAS
今更バイエルの運指について議論してるような雑魚に構うなよ
C++もピアノも、憧れだけあって実力がまるでないバカ
281: 2021/09/06(月)20:33 ID:d5h9Y6Qi(2/2) AAS
日本語版(0xCC=フ)によりフフフフフ…で埋められたWin32アプリデバッグメモリを思い出した人、どのくらいいるかな

「フフフ…」4歳娘が撮影した花火に家族で爆笑! 見ると笑顔になる“奇跡の1枚”の状況を父親に聞いた | FNNプライムオンライン
外部リンク:www.fnn.jp
282: はちみつ餃子 ◆8X2XSCHEME 2021/09/06(月)23:42 ID:buVCF6sT(1) AAS
>>278-279
D&E によればネームスペースは 1991 年に ANSI/ISO の委員会において浮上したトピックであるとのことだ。
逆に言えばそれ以前には無かった。
Windows 3.1 の頃に C++ でプログラミングしていたなら >>274 のようなコードが有ったとしても不自然とは言い切れない。
283: 2021/09/07(火)02:14 ID:b2odouMM(1) AAS
今でもchar_traitsみたいのあるね
284: 2021/09/07(火)02:29 ID:fAleIY7G(1) AAS
なあに名前空間的な修飾を省略させたくない時に役立つ
285: 2021/09/07(火)03:15 ID:5ki66s4L(1) AAS
>>259
cに付け加えるならgoのdefer文かなと思う。
286
(3): 2021/09/07(火)11:04 ID:1Eqd+3ka(1) AAS
C...Cにだってtry~catch~finallyあるんだからね!(ネタ=setjmp/longjmpを使ったマクロ)
外部リンク:gist.github.com
287
(1): 2021/09/07(火)23:50 ID:jZhA4bAr(1) AAS
>>286
ちなみにtry~catch~finallyっぽいのはVC++が持つと光と闇が両方そなわり最強に見える
Cが持つと逆に最適化が合わさり頭がおかしくなって死ぬ
288: 2021/09/08(水)05:21 ID:KzXEzs8I(1) AAS
>>287
別に頭がおかしくなって死なないでしょ
finally機構で資源解放する機会が増えるのはユーザーの利益になるだけで、複雑さを増す不利益にはならないよ
289
(1): 2021/09/08(水)05:59 ID:4NmVrZFW(1/3) AAS
確かにgccだと-O1でも2でも3でも暴走しちゃうけど、vc++だと最適化してもちゃんと動くね
290: 2021/09/08(水)09:59 ID:1wbeyQs7(1) AAS
VC++はマイクロソフト拡張によってCでも構造化例外処理が使えたんだよね

__try __except __finally
291: 2021/09/08(水)10:59 ID:6jFCz4HP(1) AAS
intalコンパイラはほんとにヤバいが、gccの最適化で変なことになったことは自分は一回もない
292: 2021/09/08(水)17:34 ID:nCYYHiA4(1) AAS
finallyは20年前からBorlandC++に既に実装済だったしその頃のVC++なんか>>146の状態やし
293: ハノン ◆QZaw55cn4c 2021/09/08(水)19:46 AAS
>>276
ですよね!
294
(1): ハノン ◆QZaw55cn4c 2021/09/08(水)19:47 AAS
>>286
最近まで try.. catch の実装の大半は sjlj だと思っていましたが最近は違うのですか?
295
(3): ハノン ◆QZaw55cn4c 2021/09/08(水)19:51 AAS
>>273
あなたはジョークの分からない人か、それとも >>275 のいう若い人か
>>242>>230 と同様でしょ
296
(1): 2021/09/08(水)19:52 ID:zE01k1pD(1) AAS
>>294
IDが出る板でID消してると浪人焼かれるぞ
297
(1): ハノン ◆QZaw55cn4c 2021/09/08(水)20:33 AAS
>>296
それは単なる都市伝説
お布施を毎年律儀に払っている人にそんなことをするわけがないでしょう‥‥
298
(2): 2021/09/08(水)20:48 ID:4NmVrZFW(2/3) AAS
>>289の件、再現コード抽出しました。最適時i=1がlongjmp後に0に戻ります。
// gccだと最適化なしなら正常終了。最適化すると終わらない。
#include <stdio.h>
#include <setjmp.h>
int main(int argc, char *argv[])
{
int i = 0;
jmp_buf jmpbuf;
_setjmp(jmpbuf);
printf("hoge\n");
省7
299: 2021/09/08(水)21:06 ID:QZMwNs5W(1) AAS
gccで例外ぽい事したいならC++にして使えで完結しちゃうからな……
300: 2021/09/08(水)21:09 ID:4NmVrZFW(3/3) AAS
インラインアセンブラとかでもない限り、処理系依存の文法を使いたくはないし、>>286はあくまでネタですよ。
ただ最適化時の挙動が違う原因を知りたかったので、個人的に調べた結果を載せといただけです。
お気になさらず。
301: 2021/09/08(水)22:55 ID:7k6oklod(1) AAS
setjmpの結果を変数に入れちゃダメだって教わらなかった?
302: 2021/09/08(水)23:11 ID:cWvdMGeM(1) AAS
入ってなくない?
1-
あと 700 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.083s