24/02/10 20:56:08.28 0f3gz8pL0.net
>>228
>>>188のように自分が何をやっているのか認識しないまませき止めるのは論外すぐる……
どこが論外？>>169でぜんぜん問題ないが。
233:デフォルトの名無しさん (ﾌﾞｰｲﾓ MM8f-tai3)
24/02/10 21:22:31.20 dL54PN9cM.net
>>232
それは未知の例外投げてきたライブラリを信用し過ぎ
製品ならそういう「たぶん大丈夫っしょw」的なのは許されないね
234:デフォルトの名無しさん
24/02/10 22:40:34.32 0f3gz8pL0.net
>>233
逆だろ。catchしないのはライブらにが未知の例外を投げてこないだろうと信用してるってことだろ。
235:デフォルトの名無しさん (ﾜｯﾁｮｲ bf27-tai3)
24/02/10 23:44:13.35 iRyhZExm0.net
>>234
catchしないということは終了させるということ
見かけ上動き続けたらいいってもんじゃない
236:デフォルトの名無しさん
24/02/11 03:08:09.08 4PD3HqyC0.net
>>232
それは未知の例外投げてきた原因を調査しなさすぎ
製品ならそういう「たぶん大丈夫っしょw」的なのは許されないね
>>233
ドキュメント通りに例外発生条件にならないように呼んでやったのに
例外を飛ばしてくるライブラリって一体……
製品やぞ……
237:デフォルトの名無しさん
24/02/11 03:16:41.24 4PD3HqyC0.net
質問なのですが
Q1. std::ldexp(0.0, 0.0) が0.0なのですがこれは 0^0 = 0という大胆な主張なのですが何で決まっているの？
STLがIEEE735に従っているだけ？
Q2. 最小の（絶対値が最小の正の）非正規化数は
const auto min_expn = std::numeric_limits<double>::min_exponent;
const auto digits = std::numeric_limits<double>::digits;
として、std::ldexp(0.5, min_expn - digits + 1) で正しい？
（実際 std::ldexp(0.5, min_expn - digits + 1) > 0.0 やが std::ldexp(0.5, min_expn - digits + 1) / 2.0 == 0.0 であっる
Q3.にもかかわらず、
std::ldexp(0.5, min_expn - digits) > 0.0 になるのはなんで……orz
238:デフォルトの名無しさん
24/02/11 03:25:12.56 4PD3HqyC0.net
訂正 |||。n_
誤1： IEEE735
正1： IEEE754
誤2： 非正規化数
正2： 非正規数
239:デフォルトの名無しさん
24/02/11 06:22:40.58 2tL2xZqD0.net
>>237
wandboxに書いてみ
240:はちみつ餃子
24/02/11 07:55:26.62 nHqSm2on0.net
>>237
決まっていない。言語仕様としては未規定。
std::numeric_limits::is_iec559 が真であるならその挙動をあてにしていいがそうでないときは各環境の事情による。
241:デフォルトの名無しさん (ﾜｯﾁｮｲ 16cf-BOeC)
24/02/11 09:19:29.20 XOPhWcHA0.net
>>236
あんたの認識じゃ catchする=見かけ上動き続ける なんだ？
なんか根本的に勘違いしてる気がする。
242:デフォルトの名無しさん (ﾜｯﾁｮｲ 637c-IqbK)
24/02/11 09:29:04.38 9XvrSVak0.net
例外は「関数外にエラー発生を伝える」ための「方法の一つ」でしかない
関数の処理がどんなエラーを発生させうるか、受け取った外側の処理がその情報をどう取り扱うべきかという問題とは完全に直交してる
（言語ごとにある程度の慣例はあるけどあくまで慣例）
例外に変なこだわりや的外れな批判をしてる奴は大体そこを勘違いしてる
243:デフォルトの名無しさん (ﾜｯﾁｮｲ 16cf-BOeC)
24/02/11 09:47:48.61 XOPhWcHA0.net
アンカ間違えた、すまん
>>241は>>235宛な。
244:デフォルトの名無しさん (ﾜｯﾁｮｲ 1e27-2ki6)
24/02/11 09:47:48.79 2tL2xZqD0.net
>>242
お前はバグのないお花畑を考えてるからそういう理想的な抽象論を持ち出すんだよ
c++の現実は道を踏み外したら即カオス
stlのコンテナのpopに返り値がない理由は知ってるか？
あのレベルの考察でソフトウェア設計している人間が世の中にどれだけいると思う？
245:デフォルトの名無しさん (ﾜｯﾁｮｲ 1e27-2ki6)
24/02/11 09:55:44.37 2tL2xZqD0.net
>>241
>>169を否定している
知らない例外が飛んできた場合にcatchして握りつぶしてそのまま動作を継続するかどうかって話な
246:デフォルトの名無しさん (ﾜｯﾁｮｲ 637c-IqbK)
24/02/11 10:07:06.72 9XvrSVak0.net
>>244
バグのあるなしなんか関係ない設計の話だし、「例外はエラー伝達の具体的方法の一つ」って話のどこが抽象的なのかも分からないし、
「C++の現実」とか「カオス」が具体的に何のことで何の関係があるかも分からないし
STLにpopがないのはnoexcept moveがない時代に例外安全に出来なかったからだけど今の話に何の関係があるかわからないし
そんなのまともなC++erなら誰だって考えて設計してると思うけど、そうでないタコの話が何の関係あるかわからないし何もかも分からなすぎてすごい
仕事でそんなドキュメントやレビューコメント出すなよ
>>245
知らない例外を握り潰すのも、知らない戻り値をガン無視するのも一緒
errnoが変わってるのを無視するのもint*err引数に渡した変数の値を無視するのもexpected<T,E>で帰ってきたEを無視するのも「知らんエラーを無視した」という結果は一緒
知らんエラーを無視していいかどうかの意味論と、そのエラーがどう伝播して来るかかは関係ない
関係ない話を混ぜるからお前のC++はカオスなんだよ
247:デフォルトの名無しさん (ﾜｯﾁｮｲ 16cf-BOeC)
24/02/11 10:14:56.00 XOPhWcHA0.net
>>245
？
そのtryブロックの処理が失敗したものとするって書いてあるじゃん。
248:デフォルトの名無しさん
24/02/11 11:18:37.96 4PD3HqyC0.net
>>231
>前半のよくわからない計算はcatch句を書いたらそのC0網羅のためのテストケースが必要になるとかいうことなんだろうか
例外が関数の階層をぶち抜いてfall-throughしてくることを忘れている発言
1. catchが書かれた関数が正しくcatchし、適切に処理するか（処理してせき止め or/and 必要な場合再スロー)（←要テスト！
2. fall-throughする関数が例外による処理の中断でおかしいことにならないか（←要テスト！
2をテストもせずに放置するとおかしくなる例は>>183のとうーり
これにより、例外を生じる関数foo()の呼び出しﾊﾟﾃｨｰﾝn個それぞれに対し、a個のテストが必要になっる
例外を発生させない使い方をするなら、n*a*mではなくmの定数倍（例外を飛ばさない使い方に依存擦る定数）。
例外が飛んで来たらバグ。わかりやすい
例外を多用しつつn*a*mをよくわからない計算とか言っている時点で以下略
249:デフォルトの名無しさん
24/02/11 11:18:50.45 4PD3HqyC0.net
>>244
以下の主張のどこが抽象論なのかkwsk、
1. ライブラリのドキュメントに従い、可能な限り例外を生じない使い方で設計する（>>236
2. 例外が生じない前提としたところは例外が生じないことをテストする（m個のオーダー）（>>229
3. 1と2の過程で意図に反して飛んでくる例外がある場合は原因を調査し、修正を試みる（>>228 例外が飛んで来たらバグ
4. 3を意図通りの形で解決できないことが判明した場合は
（ライブラリの使用方法の当方の誤解、ライブラリのドキュメントの不備、ライブラリの作りの粗さによりこれはあり得る、
結果的にtry { } catch (/*省略*/) { ... }を付ける可能性もある（>>228
5. 例外を複数段fall-throughか再スローを許し、かつそれが起きた後もプログラムの
正常な動作の継続を意図する場合はテストケースが爆発する(>>
設計し、検証し、必要とあらばtry { } catch ( ) の追加も含めた修正を行うと言っているのやぞ；；；
いっぽう藻前らの主張は
1. 例外をせき止めれば良い（←処理不能な未知の例外が飛んでくることが無いというライブラリに対する全幅の信頼
2. 例外を処理したりfall-throughしたり再スローしたりする関数はn*a*m個のテストしなくても動くっしょ
（←自己のコードに対する無制限の気体
3. ドキュメントは100%信頼せず、読まない
の3成分からなるわけやが……
250:デフォルトの名無しさん
24/02/11 12:01:58.52 XOPhWcHA0.net
>>248
>例外が関数の階層をぶち抜いてfall-throughしてくることを忘れている発言
やっぱり意味不明だな。catchすれば「階層をぶち抜いて」ってことはないわけだが。
>2. fall-throughする関数が例外による処理の中断でおかしいことにならないか（←要テスト！
もしそのテストが必要なんだとすれば、catchしない場合はその例外が通過する
呼び出し階層全部でテストをしなきゃならないってことになるが。
251:デフォルトの名無しさん
24/02/11 12:31:22.40 XOPhWcHA0.net
>>249
>1. 例外をせき止めれば良い（←処理不能な未知の例外が飛んでくることが無いというライブラリに対する全幅の信頼
なるほどな。
catchする⇒無視する、握りつぶす って脳内変換されてんだな。
catch書いたからといって上に挙げられたようなテストができなくなるわけじゃないっしょ。必要と思うならやればいい。
3.の意図しない例外の原因調査なんて main() に例外が上がってきてプログラムが落ちてからより
発生個所に近い下層で catch できた方がはるかに調査しやすいと思うんだがな。感覚が違うなあ。
252:デフォルトの名無しさん (ｽﾌﾟｯｯ Sd52-oDfP)
24/02/11 12:37:47.91 AyRTgUB7d.net
仕様書や規格書はその意図を正確に読み取ろうとするのに
掲示板の他人の書き込みは積極的に曲解しようとするのは何故か？
253:デフォルトの名無しさん (ﾜｯﾁｮｲ ef8b-u/MX)
24/02/11 12:44:06.42 E8bU9+6D0.net
見下しているからよ
こいつらは俺より下なはずと
254:デフォルトの名無しさん (ﾜｯﾁｮｲ 5eda-5kwM)
24/02/12 07:49:39.70 4SfsXRB60.net
本気で面白いと思ってやってんだろう
255:デフォルトの名無しさん (ﾜｯﾁｮｲ 637c-IqbK)
24/02/12 08:44:56.68 WngRm50l0.net
例外は糞！危険！意味不明！テスト漏れる！って言ってる奴ほど
if (err != 0) { return -1; }が大好きなんだよな
本質的にやってること変わらないのに
256:デフォルトの名無しさん
24/02/12 15:42:15.86 NdUIQhSh0.net
ファイル名に年月が使えないの困ります。
2024/02/11_データ.txt
とか
257:デフォルトの名無しさん
24/02/12 15:46:00.47 QicyHe7E0.net
>>256
それ検索性最悪だから良くないんだよなぁ。
データ/2024/02/11/データ.txt
データ.txt/2024/02/11/データ.txt
あたりならまだ許せる。
258:デフォルトの名無しさん
24/02/12 16:40:43.94 MdmHk5EH0.net
ふつう年月日はハイフンで区切るよね
259:はちみつ餃子
24/02/12 17:02:03.84 4VueJhli0.net
スラッシュを使う習慣が悪いわけではないが
プログラマの感覚だと ISO 8601 の方式に馴染みが有ることが多いってのはある。
260:デフォルトの名無しさん (ﾜｯﾁｮｲ 5edc-s3Gl)
24/02/12 17:31:20.60 rGOG+Ewu0.net
年月日は「ふつう」がないのでみんなが苦労している
日本とアメリカとイギリスで順番が違うし
日本には「令和」とかあるし
261:デフォルトの名無しさん
24/02/12 18:43:50.33 zGvIVge80.net
Windowsでも / をディレクトリ区切り文字として使えるけど(場面は限定的かもしれないけど)、その認識で使ってるのかな…
262:はちみつ餃子
24/02/12 20:07:00.91 4VueJhli0.net
Linux で * という名前のファイルを消そうとして
うわあぁぁぁとなった話はたまに聞く。
使えたとしても使うべきでない文字もある。
263:デフォルトの名無しさん (ﾜｯﾁｮｲ f7cb-nOVH)
24/02/12 21:44:07.99 zGvIVge80.net
262>>
それ以外のファイルをすべて退避した上でディレクトリごと削除したことがあったな
264:デフォルトの名無しさん (ﾜｯﾁｮｲ f7cb-nOVH)
24/02/12 21:46:10.68 zGvIVge80.net
すみません、261ですが、Windows限定の話ではなかったですね
失礼しました…
265:デフォルトの名無しさん (ﾜｯﾁｮｲ 5edc-s3Gl)
24/02/13 05:53:49.07 QIUviIGO0.net
Linuxならi-nodeをしていすれば
findと組み合わせてどんな名前のファイルも消去できるんだけどなあ
windowsはなんか複雑だったような気がした
266:デフォルトの名無しさん
24/02/13 09:36:03.89 7CLA20rP0.net
iso8901にしない人はたぶんこの規格を知らないわけで意識低すぎだろと思ってしまう
267:はちみつ餃子
24/02/13 11:18:57.32 T85IlqBy0.net
>>266
ISO 8901 は情報交換用 (要するに機械同士のやり取り) の時刻フォーマットを定める規格であって
言葉や文章で使うもの (人間が読み書きする目的) ではないと適用範囲の言及がある。
ファイル名はどちらの用途もありうるので >>256 がどのような状況を想定しているかによって
ISO 8901 が適切かどうかは違う。
もし非技術者向けのシステムなら
文化固有の日付表現に対応できてないほうが意識低いという見方もある。
268:デフォルトの名無しさん
24/02/13 12:55:27.90 c63MYIIQ0.net
>>267
エンドユーザーの文化的背景に配慮したデータフォーマットの利点は、エンドユーザーの知識やメタファーを利用した学習曲線の低勾配化であって、技術的には負の遺産になりやすいことには注意が必要。
典型的には小組織から始まるURLの並びですな。木構造との相性がひどく悪い。
あるいは大きな桁から始まるバイト列とか。あんなの１桁目から始めればエンディアン問題とか無かった。
269:デフォルトの名無しさん
24/02/13 13:07:38.28 mTl8FNrx0.net
> 典型的には小組織から始まるURLの並びですな。木構造との相性がひどく悪い。
それは人間から見たときと機械から見たときの見やすさの違いでしかないような気がする
でも日本の住所は大きい方から始まるんだよな
アメリカは個人から始まる
文化の違いやけども、日本人は機械生命体だったのかもしれぬ
270:デフォルトの名無しさん (ﾜｯﾁｮｲ 6b74-e92p)
24/02/15 04:22:25.92 MOgQCM5N0.net
>>58
亀だがクロスで使ってるよ
271:デフォルトの名無しさん
24/02/16 22:41:08.10 /bcZ41DF0.net
enable_shared_from_thisなクラスで、shared_from_this()はコンストラクタの中では
呼べないようですね
コンストラクタの中の処理でthisを渡したい処理があるのですが、どうしたら...
そもそもそれ自体が間違っているのでしょうか
コンストラクタが呼ばれる行の次でその処理を呼べばいいという説もありますが、
現在のコードがそれをやりにくい形になっていて
272:デフォルトの名無しさん
24/02/17 11:55:24.05 hsYxYbKj0.net
>>250
>>2. fall-throughする関数が例外による処理の中断でおかしいことにならないか（←要テスト！
>もしそのテストが必要なんだとすれば、catchしない場合はその例外が通過する
>呼び出し階層全部でテストをしなきゃならないってことになるが。
その通り。テスト不要としたいなら、例外が出た原因を調べて出ないようにするのが筋
原因を調査して対策せずに予防的にテスト不十分のtry { } catch () をてんこ盛りにする方がソフトウェアー品質が上がるという考えのはおかしい
>>251
>catchする⇒無視する、握りつぶす って脳内変換
脳内変換ではなくて、予防的に入れたtry { } catch ()部分のテストが不十分な限り事実じゃーん？
>>252
>本質的にやってること変わらないのに
別に。
return -1; は呼び出し側のバグで見落とすかもしれないが
throw std::logic_error("*** ERR ***"); なら悪評千里を走ってバグの兆候が嫌でもﾜｶﾙ
むしろ予防的なtry { } catch () が例外のメリットをreturn -1; に縮小してゐる
273:デフォルトの名無しさん
24/02/17 12:01:54.73 hsYxYbKj0.net
>>253
藻前が二の句をつげないのは藻前の見識と資質の問題であって
漏れの責任ではないのでお間違えなきよう、
なのですよ……
274:デフォルトの名無しさん
24/02/17 12:35:51.03 mUyTgSzm0.net
テストって想定した動作環境、データ入力に対して想定した動作をするか確認をするわけで
想定しえないエラーや割り込みに対してはテストのしようがないんだけどな
そのための例外処理だろ
275:デフォルトの名無しさん
24/02/17 13:04:42.05 4+T7+QKn0.net
例外が上がってくるってことはどこかで例外を投げてるってことだぞ。
問題が起きたところでその問題に対して例外を投げるという対処をしてる箇所がある。
想定してないなら例外送出すらできないよ。
その上で人間は大きいプログラムの全体を把握することは困難だし
機械的なチェックがしづらいという現実はあるって話だ。
276:デフォルトの名無しさん
24/02/17 13:33:26.89 mUyTgSzm0.net
アプリケーションを作っているのとOSを作っている人は別
それと同様に利用するライブラリがどのような例外を投げてくるか、もしくはそのライブラリがさらに下位のライブラリから投げられた例外をどう処理しているか
アプリケーション開発者はそれらすべて想定できているとでも？
ハードウェアやシステム含めて全部ひとりで作り上げる（もしくは密に情報共有できている）ならお前の言う通りだけどな
277:デフォルトの名無しさん
24/02/17 13:41:06.46 4+T7+QKn0.net
>>276
「把握することは困難」という現実の話もしてる。
想定してはいて、しかしそれが伝わってない。
コミュニケーションの問題、自動化の問題として捉えるべき。
278:デフォルトの名無しさん
24/02/17 13:56:12.85 mUyTgSzm0.net
俺も、（もしくは密に情報共有できている）なら、と言う話をしているがな
ただ「現実の話」と言うならば、伝わっていないことをコミュニケーションの問題、自動化の問題と言うのはナンセンスだわな
お前自身がこう言っている
> その上で人間は大きいプログラムの全体を把握することは困難だし
> 機械的なチェックがしづらいという現実はあるって話だ。
ではWindowsと言う巨大プログラムにおいてMSの中の人はどの程度全体を把握していて、発生しうる例外を公開しているのか
アプリケーション開発者はその公開情報をもとに ＊想定し＊ プログラムを組まなくてはならない
さてアプリケーション開発者はOSなど下位のモジュールから飛んでくる例外をすべて想定できるのか？
そもそも致命的な例外でアプリケーション自身の継続が困難な場合を除いて
どんな例外でもあっても継続的な処理を可能にするのが例外処理だろうに
（ここで言う継続的な処理とは問題なしとして先に進むだけでなく、異常があったとして正常な（処理の）出発点に戻るという意味でもある）
起こりえる例外をすべて想定せずともプログラムを安全に継続するための仕組みが例外処理だろ
279:デフォルトの名無しさん (ﾜｯﾁｮｲ 6332-A7R9)
24/02/17 15:09:15.47 4+T7+QKn0.net
C++ の設計理念としては「そうは言っても現実はこうなっとるやろが！」という
状況に対処する方法があることも大事にしてはいる。 たとえ綺麗な方法ではなくても。
どのような問題が起こりうるのか (それなりには) きちんと想定するのは当然の大前提で、
それでもこれからリリースするソフトウェアに何が起こるかわからんのは仕方がないという話であって、
想定が不十分でも構わないという話でもない。
よくは無いが悪いときでもなんとかなるという程度の仕組みだよ。
280:デフォルトの名無しさん
24/02/17 15:39:40.77 snTd9S980.net
>>271
一番いいのはコンストラクタの中でthisを渡す部分を何とかすることだけど、それが必ずしも間違ってるかは分からないので
コンストラクタの中だけでその処理が呼ばれるなら生のthisを渡すことを許容しつつ、その処理の呼び出し可能範囲を限定するか
そのクラスの構築をファクトリ関数経由に限定して、ファクトリ関数の中に構築とその処理呼び出しをまとめてしまうとか
281:デフォルトの名無しさん
24/02/17 15:49:12.98 mUyTgSzm0.net
> 想定が不十分でも構わないという話でもない。
誰もそれで構わないとは言っていないので
それでも起きてしまうエラーや割り込みに対応するための仕組みが例外処理だろ
身も蓋もない言い方をするなら
そもそも想定できているなら事前に排除するだけで済むわけで例外処理の必要もない
（もちろん分かっていても事前に排除せず意図的に例外処理に丸投げすることもあるのは知っている）
アプリケーション開発者にとってもっとも想定できない問題ってのは実行環境に起因するもの
282:デフォルトの名無しさん (ﾜｯﾁｮｲ 16cf-BOeC)
24/02/17 20:37:07.00 QSMcEn770.net
>>272
>原因を調査して対策せずに予防的にテスト不十分のtry { } catch () をてんこ盛りにする方がソフトウェアー品質が上がるという考えのはおかしい
相変わらずずれてるな。 catch する == 原因を調査しない じゃないわけ。
>return -1; は呼び出し側のバグで見落とすかもしれないが
>throw std::logic_error("*** ERR ***"); なら悪評千里を走ってバグの兆候が嫌でもﾜｶﾙ
戻り値のチェック漏れは静的局所的にチェックできるが例外は出てみなけりゃ結局澪とされるわけだが。
リリース後にユーザーサイドでその見落とされていた例外が発生してプログラムが落ちたりしたらそれはただのバグ。
283:デフォルトの名無しさん
24/02/17 23:18:00.46 v62CV0mD0.net
>>278
> そもそも致命的な例外でアプリケーション自身の継続が困難な場合を除いて
> どんな例外でもあっても継続的な処理を可能にするのが例外処理だろうに
それは幻想
c++の例外安全の達成がどれだけ難しいか理解していないね
簡単にリークするし、オブジェクトが想定外の状態を持ったりする
動作保証ができない
だから仕様に明示されていない例外が来たら基本は終了だよ
そのまま継続してそれが原因でその後別の場所で落ちられたら無駄な調査の手間が増えるだけ
284:デフォルトの名無しさん
24/02/17 23:48:07.59 QSMcEn770.net
例外安全と例外の種類には特に関係はないわけで、知らない例外だと例外安全の保証が困難になるなんてこともない。
285:デフォルトの名無しさん
24/02/18 00:24:49.13 JX7gxI3D0.net
>>284
例外の種類しか頭にないのか
任意の場所での例外発生に対応するなん現実的にできないということ
286:デフォルトの名無しさん
24/02/18 09:00:09.02 c1Urupub0.net
>>269
そのあたりの難しさを考えると、例外廃止してoptionalに統一したほうがいいかもな。
少なくとも例外みたいに変なフローで飛んで来ないし。
287:デフォルトの名無しさん
24/02/18 09:39:44.00 9f8IS57r0.net
ぶっちゃけ>>283がなに言ってるのかわからない
継続してそれが原因で？
いやいやw
突如落ちるより、保存できるデータは保存してもらう機会を与えることは出来るだろ
なんでお前は何事もなかったかのように作業を続ける前提でしか話を聞かないんだ？
オブジェクトの状態が変わっているかも？
変更前のデータと比較して変わっていたらユーザに確認すればいいだろ
例えば図形情報のうちTopの読み込みで例外が発生した場合に想定してないからとアプリ落として全情報ロストさせる気か？
Topは０で初期化させ読み込めなかったことをユーザに伝えて修正、もしくは再読み込みの機会を与えるだけの話だろ
288:デフォルトの名無しさん
24/02/18 09:41:50.12 WHoJTRhT0.net
>>285
>例外の種類しか頭にないのか
>>283が仕様に明示されていない例外を話題にしているからだが。
>任意の場所での例外発生に対応するなん現実的にできないということ
これはどういう意味なんだろうな。
着目するのは自分が呼び出している処理から上がってくる例外に対して例外安全かどうかであって
それは基本的に局所的に判断できるもの。
下層の、例外が通過してきた処理が例外安全な実装になっているかどうかってのはそっちの責務。
289:デフォルトの名無しさん (ﾜｯﾁｮｲ e3f9-NGC7)
24/02/18 12:27:32.99 9f8IS57r0.net
> これはどういう意味なんだろうな。
そうそれ
tryブロックで囲った部分（つまり任意）の例外発生に対応するのが例外処理なのになにが出来ないというのか
想定している例外が発生して継続できると判断したなら続ければいいし
ダメならユーザに通知してもちょも安全な方法を選択させればいい
でもってそれは想定していない例外の発生でも同じ
ただ致命的でどうしようもないなら強制終了させるだけの話で、想定していない例外はなんでもかんでも強制終了じゃ例外処理使う意味が薄まってしまう
290:デフォルトの名無しさん (ﾜｯﾁｮｲ e3f9-NGC7)
24/02/18 12:28:39.34 9f8IS57r0.net
もちょも は もっとも の まちがい
291:デフォルトの名無しさん (ﾜｯﾁｮｲ 6f5b-ERL4)
24/02/18 13:22:22.19 JX7gxI3D0.net
>>287
ファイル保存するなとか言ってない
それぐらい終了処理のひとつだろ
ログファイルもシグナルトラップして必ずフラッシュさせるのが常套手段だろ
意味不明な例外が発生しました
データが破損してないかあなたが確認してください
動作無保証ですが処理継続しますか？yes/no
こんなUIだすやつセンスの欠片もない
292:デフォルトの名無しさん (ﾜｯﾁｮｲ e304-hmqi)
24/02/18 14:01:41.78 6Yt/CDIt0.net
私が20代の頃に見かけた論争が今も繰り返されてるのかわいい🩷
293:デフォルトの名無しさん
24/02/18 15:55:07.22 1iQutSwY0.net
>>291
それを思いついたお前のセンスがないと言うことになるが…
俺は確認しろと言っただけだし確認には様々な方法がある
294:デフォルトの名無しさん
24/02/18 16:26:47.97 WHoJTRhT0.net
>>291
まさか、何も言わずにいきなり落とす方が良いとか言うわけじゃあるまい。
295:デフォルトの名無しさん
24/02/18 17:54:38.27 L2mk1x1ad.net
>>289
もちょカワイイよね
296:デフォルトの名無しさん
24/02/18 18:17:37.55 LeQ06zof0.net
>>280
実生活のあれと似てますよね。「引っ越すことになりました。新住所はXXです」と早めに
連絡したら、気の早い知人がそこに押しかけてきて「なんやまだ引越しとらんやんけ」となる
やはり引越し作業完了を待ってからの方がいいのか。ってちがうか
297:デフォルトの名無しさん
24/03/02 23:41:07.84 C77pR/Zl0.net
>>282
>相変わらずずれてるな。 catch する == 原因を調査しない じゃないわけ
>249に賛同いただけていないということは、発生してもいない例外について予防的にtry { } catch () を入れようとしていることは
確定的に明らか
で、例外というﾌﾞﾂは「例外なく」悪い知らせなので（∵仮に良い知らせを例外で寄越すライブラリがあったらそれ自体悪い知らせである
普通の人は悪い知らせが来る前に処置しようとする。すわなち例外が来ないように（可能な限り）修正する。
try { } catch ( ) でひっかけて原因調査兼確実な修正でざい、それが一番効率が良い方法論である、などと主張するのはおかしい人だけ……
298:デフォルトの名無しさん
24/03/02 23:49:37.41 C77pR/Zl0.net
>>284
例外安全というもののスコープに対して考察が足りていない
1.
例外安全なオブジェクト foo のデストラクトが他の例外によって引き起こされるケースでは
foo の安全な終了は（メモリかファイルステムか何かが物理的にぶち壊れてOSがパニックになったとかでない限り
ほぼほぼ保たれるから>>284のような言い方はできるっていやーできるが、
システム全体については>>283の通りであって全然安全ではない
2.
fooの中の例外処理が本当に完璧かはfooのコードに書かれている全てのtry { } catch () について
全ての例外発生条件についてテストか厳格めのコードレビューでも行わないことには安全性が担保されない。
（つまり例外安全にした実装したと主張するだけでは話がただちには簡単にはならない
299:デフォルトの名無しさん
24/03/02 23:57:46.67 C77pR/Zl0.net
それはそうとして、予防的なtry{ } catch () の何が一番駄目かというと、設計上のトレードオフをわけわかんなくすることが確実な点
例外発生後の状況というのはたいてい>>283の通りのわけなので、何かを捨てて何かを取る
（例えばシステムは最悪落ちても構わないが、例外安全なオブジェクトfooでリソースAの整合性は死守する等）
のトレードオフが発生するがそういうのこそ慎重な設計と考慮が必要な事項であることは確定的にあきらか
プログラムの全階層にtry { } catch ()入れたら完璧などというｱﾌｫはやっぱtry { } catch () しないのが正しい
300:デフォルトの名無しさん (ﾜｯﾁｮｲ 0fcf-0WZ8)
24/03/03 21:57:15.41 735dldsp0.net
>>298
自分が呼び出す関数が例外安全にできているかどうかと自分の処理が例外安全かどうかをごっちゃにしてるだろ。
しかも、呼び出す関数からドキュメント化されていない想定外の例外が発生するなら例外安全に作られていないだろうという
変な決めつけが混じってる。
例外安全なコードは例外の種類に依存しない。知ってる冷害に対しては安全だけど知らない例外が飛んできたら安全じゃない
なんてのはそもそも例外安全とは言わない。
301:デフォルトの名無しさん (ﾜｯﾁｮｲ ef0a-qSkN)
24/03/03 22:08:48.84 qMaLplcd0.net
>>300
お前さ、すべてのnoexcept関数呼び出しの例外テスト書いてんのか？
それが出来もしない理想論だって言ってんの
302:デフォルトの名無しさん (ﾜｯﾁｮｲ 3b7c-85wQ)
24/03/03 22:31:19.01 GdJ/jhkt0.net
>>301
自分でnoexcept指定した関数のことなら投げないことを確認するテストくらい書けよ当たり前だろ
303:デフォルトの名無しさん
24/03/04 00:08:35.31 gWJ01aQ50.net
>お前さ、すべてのnoexcept関数呼び出しの例外テスト書いてんのか？
悪魔の証明をテストすんのか
304:デフォルトの名無しさん (ﾜｯﾁｮｲ ef0a-qSkN)
24/03/04 07:57:02.63 D3yk9beu0.net
>>302
100%自分で書いてるコードなら未知の例外なんて起こらんだろ
話の筋理解してからレスつけろや三流
305:デフォルトの名無しさん (ﾜｯﾁｮｲ 8b63-eOBD)
24/03/04 07:58:21.27 KYG2Ugpe0.net
なんか予想外に低ﾚなレスポンスを寄越した>>299……
さすがに>>283の後に>>284のような楽天的なことを言えるだけのことはあるということか……
例外安全は確かに目指すべき境地であり、例外安全なオブジェクトだけでコードを書けば
その関数は例外安全となる。try { } catch ()など一切不要、となるわけで一見実現が簡単に思える
が、例外安全なオブジェクトだけかをもれなく機械的に確認する方法は無い上に、
中断したら別物になる（処理の順序が命）というアルゴリズムというものの本質的特性により、
>>183 のような try { } catch () が必要なケースは隙あらば混ざり込んでくるから（※1）
>>284が空想するようなシステム全体の例外安全化などは現実には不可能。
せいぜいある程度の規模のオブジェクトであれば、十分テストすれば
（自分が呼び出す関数が例外安全にできているかどうかと自分の処理が例外安全かどうかを慎重に確認せねばならない）
ほぼほぼの信頼度で実現できるというぐらい。
306:デフォルトの名無しさん (ﾜｯﾁｮｲ 8b63-eOBD)
24/03/04 07:59:55.02 KYG2Ugpe0.net
（※1） >>183 の関数そのものは、例外安全なスレッドオブジェクトでも使ったらtry { } catch () 無しの例外安全な関数うに書き直すことはできうる
307:デフォルトの名無しさん (ﾜｯﾁｮｲ 8b63-eOBD)
24/03/04 08:09:49.95 KYG2Ugpe0.net
あと寝てて思ったがプロセスが死んでもサービスが継続したらお客様には迷惑を掛けずに済むので
（直接そういうのをやってちるわけではないので強くは言わんが
ウォッチドッグタイマー的な死活監視で異常あらばプロセス再起動とかマシンを切り替えるとか方法はいくつもあって、
十分テストされたプログラムならクラッシュ頻度をポアソン分布とみなして信頼度も出せる
やっぱ「お客様の前で落ちたら恥ずかしいから」というつまらないプライドを基本的動機とする
try {
....
} catch (std::exception& e) {
log_e("std::exceptionがスローされました");
};
みたいなコードをリリースコードに含めましょうという>>282の調査のスタンスは全く正当化されない
100日に一回しか再現しないバグの修正を3日でやれと言われて手元にあるのがメモリダンプの代わりに上の23文字のログメッセージだけだったりしたら
>>282は自○が真剣に考慮すべき選択肢に……
308:デフォルトの名無しさん (ﾜｯﾁｮｲ 9fad-ZLJX)
24/03/04 08:50:22.67 MzjtGtOW0.net
> なんか予想外に低ﾚなレスポンスを寄越した>>299……
299はお前自身じゃないのか、と俺は思う
309:デフォルトの名無しさん (ﾜｯﾁｮｲ 0fcf-0WZ8)
24/03/04 08:53:34.53 gWJ01aQ50.net
>例外安全は確かに目指すべき境地であり、例外安全なオブジェクトだけでコードを書けば
>その関数は例外安全となる。try { } catch ()など一切不要、となるわけで一見実現が簡単に思える
例外安全だからといってcatchが不要になるわけないだろ。
根本的なところで勘違いしてるから頓珍漢が主張を続けてるわけだな。
310:デフォルトの名無しさん (ﾜｯﾁｮｲ abe4-XE6S)
24/03/04 10:20:12.57 QvxlWFfk0.net
例外安全には基本保証・強い保証・no-fail保証がある
例外がスローされない関数を作ればno-fail保証がある
基本保証や強い保証は例外発生後も不整合が発生しないもの
たとえば例外が発生した関数をもう一度呼び出すと「すでに実行中です」とエラーを返すようなものは例外安全ではない（おそらく実行中フラグ変数が立ったままになっている）
311:デフォルトの名無しさん (ﾜｯﾁｮｲ abe4-XE6S)
24/03/04 10:23:14.03 QvxlWFfk0.net
10行のデータをファイルに出力するとき、例外が発生して5行だけデータが出力されてしまうのは強い保証があるとはいえない
例外が発生した際にデータを書き込む前のファイル状態に戻れば強い保証がある（例外安全である）といえる
312:はちみつ餃子
24/03/04 12:10:26.04 ASLjljy+0.net
誤解のないように念のため補足。
この場合の「強い」という用語は性質の分類であって強いことがより良いというわけではないという話をしてる。(んだよね？)
例外を出さずに済むならそれに越したことはないよ。
でも、ひとつの部品の中では問題を解決できないことがあるからこそ例外を用いて他の部品と連携しての解決を試みるわけ。
連携するには保証の強力さよりも保証範囲の明瞭さ (明瞭でもカバーしようがない設計はあかんが) が大事で、プログラム全体で整合性が保たれていれば例外安全と言える。
仕様が不明瞭なライブラリもあるのが現実だってのはそりゃそうだけど、出来が悪い部品とつじつま合わせをしきらないってのは例外のせいでも C++ のせいでもない。
313:デフォルトの名無しさん
24/04/08 15:38:53.52 IvxniXPw0.net
std::initializer_listについて質問です
下の例ですがコンストラクタの引数に配列リテラルを指定した場合、リストがコピーされてしまいますよね？
これは無駄なので回避したいのですが良い方法はありますか？
URLﾘﾝｸ(cpprefjp.github.io)
314:デフォルトの名無しさん (ﾜｯﾁｮｲ df01-g9Lk)
24/04/09 12:13:11.96 gepNgOiE0.net
どこのコピー?
315:デフォルトの名無しさん (ﾌﾞｰｲﾓ MM3e-Nnmc)
24/04/09 12:52:21.68 80QuF/MqM.net
リテラルのコピーを気にするならconstexprじゃねーの？
ほんとにコンパイル時に定数になるかは知らんけど
316:デフォルトの名無しさん
24/04/09 15:22:07.81 hsAXyuRl0.net
>>313
C++ に配列リテラルはない。
その書き方で出てくる波括弧はリスト初期化の構文の一部で、
波括弧の部分単体は配列リテラルではない。
実行時にオブジェクトの構築を避けるならコンパイル時に構築することになるが
それはそれで色々と制約があるんでほんまにそれが必要なんか？
というのはよく考えないといけない。
あえてやるならこんな感じかな……。
URLﾘﾝｸ(wandbox.org)
317:デフォルトの名無しさん
24/04/09 20:10:25.18 T/amOWJO0.net
とあるtemplateの関数を実装しているのですが、
const指定の振る舞いがよくわからなくなったので
質問させてください。
以下の(だいぶ簡略化した)コードで、
f_without_const<const int*>(const int* a)
はコンパイルが通るのですが
f_with_const<int*>(const int* a)
がコンパイルが通らないのは何故でしょうか。
URLﾘﾝｸ(wandbox.org)
318:デフォルトの名無しさん
24/04/09 20:30:45.76 lDhzon+/0.net
>>316
なるほど
ここまでやるメリットはなさそうなので大人しくデフォルトの書き方にしておきます
319:デフォルトの名無しさん
24/04/09 21:45:08.71 +RmfoJzl0.net
>>317
templateは型が違うと全くの別物として処理するからだと思う
320:デフォルトの名無しさん
24/04/09 22:00:45.26 5hAg3cgl0.net
>>317
template <class T> void f_with_const (const T t);
これに対応させるなら f_with_const<int*>(int *const a)
321:はちみつ餃子
24/04/10 08:39:45.44 Fk7YBwaR0.net
const T t に対して const int* a が来たら
字句の順序としては T に int* が対応してるように見えちゃうもんな……。
322:デフォルトの名無しさん
24/04/11 21:42:31.84 0cjrPM+u0.net
317です、返信遅くなってすみません
確かに言われてみればconstが修飾してるのはint*なので、意味的にint *constが正しいですね…
ありがとうございました
323:デフォルトの名無しさん
24/04/14 14:49:11.63 tTNkn9kB0.net
先月東京で標準化委員会の会議あったらしいけどなんか情報ないの？
324:デフォルトの名無しさん
24/04/14 15:03:51.38 H7y3imqp0.net
あるよ。 URLﾘﾝｸ(github.com)
325:デフォルトの名無しさん (ﾜｯﾁｮｲ 7f52-9wFU)
24/04/16 00:50:18.09 38VQ+8UT0.net
>>323
URLﾘﾝｸ(www.reddit.com)
326:デフォルトの名無しさん (ﾜｯﾁｮｲ 67b1-Jq5A)
24/05/01 21:36:46.68 /DCu7vsT0.net
python みたいに何でも格納できる辞書型ってC++には無いよね？
327:はちみつ餃子 ◆8X2XSCHEME (ﾜｯﾁｮｲ 8732-nVjz)
24/05/01 22:29:05.62 IV4TsWNk0.net
>>326
要素を std::any にすればだいたいどんな型の値でも入れられる。
いろんな型を入れたところで使うときには元の型として取り出さないといけないから
処理は煩雑になってあまり良いことはないけど。
328:デフォルトの名無しさん (ﾜｯﾁｮｲ 8f7c-Y/5H)
24/05/09 20:23:09.67 MzADiHDk0.net
URLﾘﾝｸ(cpprefjp.github.io)
#elifって今まで非標準だったのかよ…
329:デフォルトの名無しさん (ﾜｯﾁｮｲ bed6-w0ma)
24/05/09 21:19:14.71 M6C6+6vz0.net
何いってんだ
330:デフォルトの名無しさん
24/05/10 11:53:06.45 P+BretyD0.net
#elifは大昔からあるぞ
331:デフォルトの名無しさん
24/05/11 09:12:25.64 YR9R4Y390.net
cpprefjpが間違ってるだけ？
それともずっと規格から欠落してたけど誰も気付いてなかったパターン？
332:デフォルトの名無しさん
24/05/11 11:19:25.57 PrWZroBw0.net
規格が読めないならC++やめろ
333:デフォルトの名無しさん (ﾜｯﾁｮｲ 0b63-IWIS)
24/05/11 19:02:18.20 RotYKdRC0.net
elifを逆から読んだらfile
ラリーはこれを嫌ってPerlではelsifにした（適当
334:デフォルトの名無しさん
24/05/11 22:20:47.67 HBPowvO20.net
シェルが変だからな
case ～ esac
if ～ fi
335:
24/06/06 07:08:30.09 Glzej5210.net
てｓｔ
336:
24/06/06 07:55:41.85 Glzej5210.net
質問なのですが
Q1. std::fstreamでファイルを開くときのフラグの指定の仕方は次のどれが正義？
std::fstream ofs("foo.txt", std::ios::out | std::ios::binary); // (1)
std::fstream ofs("foo.txt", std::basic_ios::out | std::basic_ios::binary); // (2)
std::fstream ofs("foo.txt", std::fstream::out | std::fstream::binary); // (3)
337:デフォルトの名無しさん (ﾌﾞｰｲﾓ MMde-FHn0)
24/06/06 15:53:22.90 Vp529NVwM.net
フル手書き前提がくそださい
338:デフォルトの名無しさん
24/06/06 19:13:19.37 FMMlTunO0.net
fstreamなんだったらfstreamのメンバで書くのがいいんじゃない
339:
24/06/06 23:36:07.51 Glzej5210.net
(1)は#include <ios>が要るし、
(2)は「basic_」の6文字×フラグの数 だけ長いし、
(3)も同様でありなおかつ>>337に従ったとき
use binary = std::fstream::binary;
use ibinary = std::ifstream::binary;
use obinary = std::ofstream::binary;
となってしまい、
どれもこれもコード量最小化原則的にﾋﾞﾐｮｰなことに……
ていうかなんで同じことをするのに複数の書き方があるのかっていうか、
Perlじゃあるまいし……
340:デフォルトの名無しさん
24/06/06 23:54:13.70 7ZzCG2hU0.net
iostreamはまあしゃーない…
341:デフォルトの名無しさん
24/06/07 02:20:24.96 GhXFHGen0.net
C++の悪評の4割くらいはiostreamのせいだからな
342:デフォルトの名無しさん (ﾜｯﾁｮｲ a944-l7CW)
24/06/07 04:24:11.05 qf+nnTv50.net
ここでCmakeとNinjaについて聞くのダメ?
どーも関係がよくわからなくて?
343:はちみつ餃子 ◆8X2XSCHEME (ﾜｯﾁｮｲ a932-zlCG)
24/06/07 05:26:04.94 zM43Xr/H0.net
>>342
そういう雑多な話題のちょうどよいスレは見当たらんし、単発で終わる質問程度なら許容されると思うが……。
質問の内容が漠然としているなら丁寧な回答は得られないと思う。
「よくわからない」という状況になるときってのは大抵の場合に関連する前提知識が足りてないので
質問が連鎖的に発生してダラダラ続いたりするから。
344:はちみつ餃子 ◆8X2XSCHEME (ﾜｯﾁｮｲ a932-zlCG)
24/06/07 05:36:24.41 zM43Xr/H0.net
>>336
第四の選択肢
std::fstream ofs("foo.txt", ofs.out | ofs.binary);
345:デフォルトの名無しさん (ﾜｯﾁｮｲ fee5-FHn0)
24/06/07 13:37:29.47 kav19u0f0.net
copilotで補完でok
346:デフォルトの名無しさん (ﾜｯﾁｮｲ 6af0-AYul)
24/06/07 17:07:58.06 NFmVQMC40.net
バカの解決策
347:デフォルトの名無しさん
24/06/07 21:12:45.28 70o6R+hDM.net
また時代に取り残されるじじい
348:デフォルトの名無しさん (ﾜｯﾁｮｲ 1563-WQ8n)
24/06/07 21:48:19.45 ORLoeNdF0.net
>>344
ofsのスコープの隙間を突きなおかつ静的メンバをドット演算子で参照する等
テクニカルですばらっし
349:デフォルトの名無しさん
24/06/08 01:03:51.86 k3Jnk/Aj0.net
静的解析で文句言われる可能性あるからやめときな
頻発するならスニペット作ればいいだけ
そういう表面的なことにこだわる奴は三流
350:デフォルトの名無しさん (ﾜｯﾁｮｲ f344-7AaF)
24/06/09 04:26:59.39 RJYm8+UN0.net
lldb v14.0.0 で正しくプロセスを実行できません
apt insrall でインストールしたもので, 環境はwsl 1 です
具体的には下のサイトのIssue Encountered:と全く同じ症状です
URLﾘﾝｸ(stackoverflow.com)
改めて書きますと Hello World 表示だけのソースを clang でコンパイルし,
lldb で読み込み run させると
Process 20784 launched: '/home/Hustler/c++/move/move' (x86_64)
と表示されたまま応答がなくなり 放置すると(サイトでは強制終了させてるようですが)
Process 20784 exited with status = -1 (0xffffffff) lost connection
となってコマンド入力待ち状態となります
ちなみにプログラムはそのまま実行して正しく動作しますし gdb でも何の問題もありません
これに関して何か情報をお持ちの方いますか?
351:デフォルトの名無しさん (ﾜｯﾁｮｲ f344-7AaF)
24/06/09 05:11:57.08 RJYm8+UN0.net
今やってみたのですが
lldb-14をuninstall(remove)し lldb-15をインストールしてみましたが
状況は改善しませんでした
352:はちみつ餃子
24/06/09 15:07:14.43 bthWHIYm0.net
WSL1 は (ある程度) Linux 互換のシステムコールを windows 内に実装することで実現していて Linux カーネルそのものではないので色々と不足がある。
(そのかわり Windows と親和性がある部分もある。)
WSL1 で用意してない Linux の機能に依存したアプリケーションは動かない。
まともな互換性が必要ならWSL2 を使いなさいという話なので手間をかけて WSL1 を積極的にはサポートしないと思う。
353:デフォルトの名無しさん (ﾜｯﾁｮｲ f344-7AaF)
24/06/09 20:56:05.63 RJYm8+UN0.net
>>352
wsl2 ではlldbは問題なく動いてるんですか?
古いCPUなのでwsl2がインスコできないもんで
上のサイトはwslのバージョンは書いてなかったようですし
354:デフォルトの名無しさん (ﾜｯﾁｮｲ 6363-vt9G)
24/06/09 21:14:14.41 VES2dE5O0.net
WSLはlldbが使うシステムコールが足りてないって昔から言われていたかと
ターゲット機を別にするとかWSL2にするとかじゃね？
355:デフォルトの名無しさん (ﾜｯﾁｮｲ f344-7AaF)
24/06/09 21:36:35.88 RJYm8+UN0.net
>>354
>WSLはlldbが使うシステムコールが足りてないって昔から言われていたかと
なるほどTHXです
clang使ってなかったので全然わかりませんでした
動かないlldbもさんざんggったんだけど system call未実装にはたどり着けませんでした
ようやくすっきりしました
356:はちみつ餃子
24/06/09 22:04:05.34 bthWHIYm0.net
ざっとググってみた感じたと wsl1 では procfs が提供する情報が少ないのが lldb が動かない直接の原因みたいな数年前の情報は見つかる。
内部構造がまるで違うはずなのに表面的なインターフェースは互換にするなんてのは無理のある話なので互換性が「ある程度」にとどまるのは仕方ない。
357:デフォルトの名無しさん (ﾜｯﾁｮｲ f344-7AaF)
24/06/09 22:18:48.29 RJYm8+UN0.net
んー
clangちょっと調べたかったんで
Visual Studioにclangインスコして調べますわ
できるならwslでやるのが手っ取り早いんですが
Q9550とQ9550sしか持ってないもんで
以来CPUの爆値上がりと最近の円の爆下がりで新しく組めてないんですわ
ダイサイズ変わらないのにCPU 3万ー> 10万とか購買意欲が萎える
358:デフォルトの名無しさん
24/06/10 18:15:47.68 bkv2YMA2M.net
>>355
github のwslのissueを漁れば出て来るかと。
結論がWSL2使えだったかと
359:350
24/06/10 21:38:00.71 gvR5xwnw0.net
自己レスです
その後 Visual Studioのインストールオプションでclangを選択し
正しく動作することは確認したのですが...
今や誰でもロハで使えるインテルコンパイラがとっくの昔にllvm化されてたんですね
clangに拘りがなければ x86/x64のwin/linux/wsl は素直にopenAPI使っとくのが幸せかも.
ちなみにwsl 1にlinux版をインストールしましたが
コンパイラicxもデバッガgdb-opwnapiも何の問題もなく動いてます(今のところは)
なので
Visual Studio はインストールオプションのclang は外してもとに戻し
wsl は
>apt remove clang clang-15
>apt remove lldb lldb-15
しときました
360:350
24/06/11 06:20:17.73 Ip4/j3Hv0.net
☓ openAPI
◯ oneAPI
361:デフォルトの名無しさん (ﾜｯﾁｮｲ 3bb1-hWAc)
24/06/21 22:07:24.38 sN/1ehEs0.net
今だけです
URLﾘﾝｸ(i.imgur.com)
362:デフォルトの名無しさん
24/06/22 13:52:54.53 5xyD4PGd0.net
今だけです
URLﾘﾝｸ(i.imgur.com)
363:デフォルトの名無しさん (ﾜｯﾁｮｲ 43d7-pk1M)
24/07/13 19:06:26.39 Dtkl2SPB0.net
若者のBoost離れ
364:デフォルトの名無しさん (ﾜｯﾁｮｲ 0501-twcF)
24/07/13 19:56:34.01 vwgbCsGD0.net
と言いますと?
365:デフォルトの名無しさん (ﾜｯﾁｮｲ f5f9-pk1M)
24/07/13 21:42:42.00 Rh1MnFN10.net
VS17.10.xでBoostがビルドできなくなってるのに
誰も触れない
366:デフォルトの名無しさん (ﾜｯﾁｮｲ f5f9-pk1M)
24/07/13 21:47:29.39 Rh1MnFN10.net
MSVC143から144に変わったせいでビルドできないらしいですよ
367:デフォルトの名無しさん (ﾜｯﾁｮｲ e91c-hIhh)
24/07/16 12:22:56.57 gS8T2k/f0.net
>>342
CMakeとNinjaはC++の話題なのでOKです
368:デフォルトの名無しさん (ﾜｯﾁｮｲ 4901-V77j)
24/07/27 17:57:44.53 KDd62vAV0.net
C++、
型の指定が、めんどい
速いぐらいしか、利点ないよな
369:デフォルトの名無しさん (ﾜｯﾁｮｲ 7b95-4q6c)
24/07/27 20:53:02.50 eNksZtKQ0.net
顧客目線に立てない三流の感想
370:デフォルトの名無しさん (ﾜｯﾁｮｲ 4901-7phL)
24/07/27 21:03:15.66 zOSUCWw50.net
>>368
auto使えば?
371:デフォルトの名無しさん (ﾜｯﾁｮｲ 1379-xel+)
24/07/27 23:40:34.69 iHlVB6Tw0.net
ランタイムに依存しない(し難い)のが最大の利点だろうに
さらに大抵のアーキテクチャには用意されてるからクロスプラットフォームの観点でもなんだかんだ最強なんだよ
むしろ最近はChatGPTが他の言語で書いたやつまで適当に書き直してくれるのもあって最強度がより高まってきてると感じるね
372:デフォルトの名無しさん (ﾜｯﾁｮｲ 8e95-N8l3)
24/07/28 00:00:39.51 ePI6t8jD0.net
全く同意できんな
むしろ環境依存上等で使うのがC/C++だろ
パッケージシステムも標準がないしビルド環境もばらばら
どこが最強やねん
標準ライブラリで完結するようなしょぼいプログラムなら他の言語使ったほうが楽
373:デフォルトの名無しさん (ﾜｯﾁｮｲ bdf0-+IYp)
24/07/28 00:11:55.23 4HqkcgMt0.net
型の指定のサンプル
GetProcAddressに変換をかけるマクロ
#define ENTRY_INTERFACE(api) api = (decltype(api)) GetProcAddress(hInst,"_INTERFACE_"#api)
ね？簡単でしょ？
374:デフォルトの名無しさん (ﾜｯﾁｮｲ 5d01-viEi)
24/07/28 12:00:20.72 x9q80Pnt0.net
>>370
auto
オートね
(いいこと聞いた
375:デフォルトの名無しさん (ﾜｯﾁｮｲ aa3e-cE1m)
24/07/28 17:36:32.24 9wLF96CX0.net
>>374
あとテンプレートを使ったダックタイプとかも便利。
376:デフォルトの名無しさん (ｵｯﾍﾟｹ Sr05-viEi)
24/07/28 21:14:24.07 roXukc4Cr.net
>>375
ふむ
実践的な(アプリを作るとか)、c++、書籍かなんか、おすすめ、ありますか？
cmake、とかの、関門もあるのだが
(githubにあがってるやつを、きっちり理解したい)
377:デフォルトの名無しさん (ﾜｯﾁｮｲ 4132-nuT0)
24/07/29 08:53:31.23 cQQT2a1I0.net
実践に入る前に言語の入門は読んだほうが良いと思う。
基礎を積まずに実践しようとするのは無謀。
378:デフォルトの名無しさん (ﾜｯﾁｮｲ 9a05-pVLH)
24/07/29 15:25:34.30 heyNGOtI0.net
なんでも、まずは改造から入るんだぜ
こうですか、うんたぶんこう
379:デフォルトの名無しさん (ﾜｯﾁｮｲ 4132-nuT0)
24/07/29 19:25:02.89 cQQT2a1I0.net
C++ には未規定がやたらたくさんあるんだ。
実際の挙動から仕様を想像しようとすると意味不明でグダグダやねん。
380:デフォルトの名無しさん (ﾌﾞｰｲﾓ MM9a-N8l3)
24/07/29 20:07:37.15 Nl7D5VelM.net
ネットでいくらでも勉強できるだろ
書籍なんかいらん
381:デフォルトの名無しさん (ﾜｯﾁｮｲ aa3e-cE1m)
24/07/29 20:36:26.35 9/o4+28+0.net
結局ライブラリが重要だから、作りたいアプリで流行っているライブラリの入門をやるのがいい。
作りたいアプリそのものじゃなくても、類似アプリを作るのはやる気に繋がる。
382:デフォルトの名無しさん (ｵｯﾍﾟｹ Sr05-viEi)
24/07/29 22:02:41.02 8hMQwTW/r.net
>>377
github にあがってるやつを、理解しようとして、助けになる本は、結局ない希ガス
実際、実践的なものがないので、文法理解で終わってしまうという
URLﾘﾝｸ(github.com)
これ、再利用して、アプリを作りたいのだが
383:デフォルトの名無しさん (ﾜｯﾁｮｲ 4132-nuT0)
24/07/29 22:18:19.65 cQQT2a1I0.net
>>382
言いたいことがわからん。
auto すら知らんかったということは文法もまだ十分に理解してないってことだろ？
文法が分かったら読めばいいだけなんだから何の本が必要なんだ？
384:デフォルトの名無しさん (ﾜｯﾁｮｲ 0168-qw7+)
24/07/29 23:36:56.61 7XbSB18u0.net
>>382
立直麻雀のシミュレーターなら mjx の方がいいんじゃないかな?
マイクロソフトで麻雀 AI Suphx の開発に携わってた人が作ったシミュレーターで
動作検証も天鳳の牌譜で実施したらしい
URLﾘﾝｸ(github.com)
他のシミュレーターだと
- libriichi (Rust製 麻雀 AI Mortal に付属 天鳳ルール準拠 AGPL)
URLﾘﾝｸ(github.com)
- kanachan.simulation (C++製 麻雀AI kanachan に付属 雀魂ルール準拠 MITL)
URLﾘﾝｸ(github.com)
とかも参考になると思う
作りたいアプリの内容がわからないけど
ネット麻雀を作りたいなら cmajiang の元ネタの電脳麻将
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(kobalab.net)
AI 用の対戦シミュレーターなら mjai.app
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(mjai.app)
が参考になりそう
385:デフォルトの名無しさん (ﾜｯﾁｮｲ 0168-qw7+)
24/07/29 23:43:38.11 7XbSB18u0.net
>>382
書くのを忘れてた
cmajiang の元ネタ majiang-core は作者が解説本を出してる
実際買ってみたけど、やっぱりソースコードだけ読むより分かりやすい
URLﾘﾝｸ(www.shuwasystem.co.jp)
ブログでも解説されてるけど、お目当ての記事を探すのが大変だし本の方が見やすいと思った
URLﾘﾝｸ(blog.kobalab.net)
386:デフォルトの名無しさん (ﾜｯﾁｮｲ bdf0-+IYp)
24/07/30 12:23:26.36 8UDCP+we0.net
>>379
未規定というか、C++11よりも古い規格のは、古参でないと扱いが難しいからね
そういう古い規格のものが仕事で入ってい来たりすると新人は頭悩ますかもしれんね
03~11まで結構間に空いてるしね
387:デフォルトの名無しさん (ﾜｯﾁｮｲ 5d01-viEi)
24/07/30 23:52:38.43 KT8SFJ0h0.net
>>385
はい、
すべて、既読です
make,
pybind11
とか入ってて、
デバッグビルド、わかりませんorz
388:デフォルトの名無しさん (ﾜｯﾁｮｲ 1bef-BWtz)
24/08/04 06:24:46.59 WlfSsbJh0.net
ラムダ式が渡された側って、キャプチャの内容をチェックしたりできないのでしょうか。
例えば以下の例で、funcA()の中でfの中のthisをチェックして挙動を変えたりとか?
そういうことをしたいなら、ラムダの引数で渡したりすべきでしょうか?
#include <iostream>
class A {
public:
void funcA(const std::function<void(int)>& f, int a) {
f(a); // can I check 'this' (B class) in f?
};
};
class B {
public:
void print(int b) {
A objA;
objA.funcA([this](int i) { std::cout << "val = " << i << "\n"; }, b);
}
};
int main(void) {
B objB;
objB.print(2);
}
389:はちみつ餃子 ◆8X2XSCHEME (ﾜｯﾁｮｲ a932-NesV)
24/08/04 10:12:57.69 w7HjtqNP0.net
>>388
キャプチャした変数はラムダ式の中で使う以外の方法ではアクセスできない。
どのような方法で解決すべきかはそれをしようとする意図によるのでなんとも言えない。
390:デフォルトの名無しさん (ﾜｯﾁｮｲ a94a-ImVy)
24/08/04 14:50:32.12 ao1w9dwD0.net
それはラムダ式を使う理由とズレてるな
A側で判定が必要なものならラムダ式の引数もしくはfuncAの引数で渡すべき
A側は受け取るものを「intをひとつ受け取ってvoidを出力する関数」として抽象化してるんだから、それ以外のことは知れないし、知るべきではない
Aは渡された関数が何であろうとintを一つ渡すだけで、その詳細 (関数がどのような値や参照をキャプチャしてるのか、渡した引数がどのように使われるのか) には触れられない
ラムダ式を使うのはこのような抽象化が目的のはずだから、キャプチャした値を知りたいというのは用途から外れるかと思う
391:デフォルトの名無しさん (ﾜｯﾁｮｲ 9b72-3sGu)
24/08/04 18:55:04.35 knGBcNlu0.net
なんか最近自分でで適切なインターフェースを定義して使うって発想がなくなってる気がする
ひたすらありものを繋ぐだけで作り切るみたいな
392:デフォルトの名無しさん (ﾜｯﾁｮｲ c1f0-3TXu)
24/08/04 19:21:38.37 oxQURbTu0.net
仕組みを追求することをせずにどっかから完成した㌬をﾄﾞｯｷﾝｸﾞするだけの作業は情報収集力さえあれば組み込み系の作業員でもできるし己のﾁｶﾗにはならんのよな
で、いろんなもの付け合わせていった結果、とんでもない容量のものが出来上がる上におまえそれﾒﾝﾃとかどうするんだよって方向に走ってって…あとは想像のとおりに
393:デフォルトの名無しさん (ﾌﾞｰｲﾓ MM8b-3sGu)
24/08/04 19:54:18.08 wSg2UiB1M.net
オブジェクト指向オワコン論からの風潮
394:デフォルトの名無しさん (ﾜｯﾁｮｲ 1320-cRFB)
24/08/04 21:00:47.00 YVKn/U480.net
なんでオワコンなの？
395:デフォルトの名無しさん
24/08/06 01:29:43.68 DDRjgUjC0.net
全然関係ないよな
取って貼っ付ける行為とオブジェクト指向は
全体の概要設計を把握してﾒﾝﾃ出来ていれば何の問題もない
396:青木康善
24/08/07 04:36:25.01 S6qXQ6lv0.net
素晴らしいなあみなさん。早すぎる！C plus plusは！
397:デフォルトの名無しさん
24/08/07 09:54:05.95 +pgWMXtY0.net
JavaはCの20倍速いを知らん人か
398:デフォルトの名無しさん
24/08/07 17:07:58.21 RPpAsXPKa.net
>>391-392
チェンジニアをチェンジ
>>395
オブジェクト指向でもクラスライブラリを造る側とただ使う側では理解度に雲泥の差がある
399:青木康善
24/08/08 00:15:58.93 Qfze0mfg0.net
マジっすか？Cの20倍？しかし、専門学校の先生に、青木！バカもん！プログラミング言語Cが一冊で事足りる、と言われても、高校数学でつまづいて大鬱病になったんで、問題が解けない。。。有隣堂本店さんで、リッチーの本置いているから、いつか買います！
400:デフォルトの名無しさん
24/08/08 04:05:43.03 G3QDAupS0.net
今のANSI対応版は易しくなってると思うけどな。
不安ならアンサーブックとセットで買えば良いベ
401:デフォルトの名無しさん
24/08/08 16:07:46.41 fgfi2g+JM.net
VMのオーバーヘッドがあるのに20倍って?
あるいは20倍時間が掛かる?
402:青木康善
24/08/09 13:02:28.92 FZEpuz0a0.net
いや、プログミング言語は、駿台電子は、国語の倒置法なんです。夜間の一年で、javaからで、二年でCなんです。いや、アンサーブックは、池袋ジュンク堂本店さんには、置いてなかったような。。。。。ありがたいというか、ビックリ。。。。マジか。。。機械語を仕事でプログラミングしていた先生が、喫煙所で、青木、お前、一つのことを本当に深く考えたことがあるか？と質問してくれた恩師なんです。
403:デフォルトの名無しさん
24/08/10 12:16:45.89 xFKQiXk00.net
スカイネットの誕生日
404:デフォルトの名無しさん
24/08/10 23:52:09.93 oQf4NdPPd.net
御巣鷹山ノボレ
405:デフォルトの名無しさん
24/08/24 08:35:54.88 yYuYqoCz0.net
すみません。教えて下さい。
template<class T, class U>void (T& x, const U& y)
{
x=y;
...
}
double ←complex<double> の代入がコンパイルエラーとなるconceptの書き方あるんでしょうか？
complex<double> ← doubleの代入ではエラーが出てほしくないです。
406:デフォルトの名無しさん
24/08/24 09:05:25.59 yYuYqoCz0.net
あ、上では関数名fが抜けてましたね．concept使わずとも
template<class T> void f(complex<T>& x, const T& y)とすればいいでしょうけど、
y=xのときはどうかとか、あるいは complex<double>←float の代入はokにしたいとか、
いろいろ考えているとテンプレート関数なのに関数のオーバーロードが増えてしまって面倒だなと思ったものですから。
407:デフォルトの名無しさん (ﾜｯﾁｮｲ 7f78-/FHh)
24/08/24 09:23:02.26 yYuYqoCz0.net
y=xのときは忘れてください。(ｆ(complex<T>& y, const T& ｘ)とすればいいだけ)。どういう状況のためにconceptが必要なのか要点がまとまっていませんね。失礼しました。
408:デフォルトの名無しさん
24/08/24 09:53:34.49 PPcTgFGr0.net
conceptで無理やりくくるよりか、static_assertのほうが楽そう
template<class T, class U>void f(T& x, const U& y)
{
static_assert(std::is_same<double,T>::value&&std::is_same<complex<T>,U>::value,"絶対にゆるさない！絶対ﾆﾀﾞ!!");
x=y;
...
}
409:デフォルトの名無しさん
24/08/24 11:11:32.60 yYuYqoCz0.net
&& は右辺値参照ではなくてandの意味なんですね。std::is_same<double,T>はdouble型とT型が一致するかどうかを調べるヘルパー変数テンプレート、::value は trueかfalseのいずれかの値をとる定数ですか。static_assertは自分でエラーメッセージを作れるのがいいですね。完全にわかっていないですが、勉強します。ヒントありがとうございました。
410:デフォルトの名無しさん
24/08/24 11:44:22.45 6PXbzil00.net
最近、初心者にいきなり右辺値参照とかテンプレート教える風潮は良くないと思うんだよなぁ・・・論理andとごっちゃになってるやんけ
ともあれis_same自体は構造体で、中にあるvalueは定数値やで
変数テンプレートはis_same_vの方。利便性(::value書くのがめんどい)のために用意されてるだけ
static_assertの第一引数(bool)に条件式を与えてるんだが、間違ってる
static_assert(!(std::is_same<double,T>::value&&std::is_same<complex<T>,U>::value),"絶対にゆるさない！絶対ﾆﾀﾞ!!");
411:デフォルトの名無しさん
24/08/24 12:20:38.61 PPcTgFGr0.net
！抜けてたわ
ｽﾏｿ
412:デフォルトの名無しさん
24/08/24 12:40:45.95 PPcTgFGr0.net
// こういう書き方もある
if const_expr ( std::is_same<double,T>::value && std::is_same<complex<T>,U>::value ) {
//許されない処理
static_assert(false,"許さんぞ!!");
}else {
//正常処理
}
413:デフォルトの名無しさん
24/08/24 12:43:11.34 PPcTgFGr0.net
また間違えたw
× const_expr
● constexpr
414:デフォルトの名無しさん
24/08/24 14:40:14.03 yYuYqoCz0.net
いろいろとありがとうございます。参考になりました。
template<class T, class U> void f(T& x, U& y)
{
if constexpr ( !(std::is_same<T,double>::value &&
std::is_same<U, std::complex<T>>::value) ) static_assert(false,"ワシャ許さんぞ!!");
y=x;
}
template <class T, class U> void g(T& x, U& y)
{
static_assert( (std::is_same<T,double>::value && std::is_same<U, std::complex<T>>::v
alue),"ワシャ許さんぞ!!" );
y=x;
}
int main()
{
using namespace std;
double x=3.14159265358979;
complex<double> z;
f(x,z);
g(z,x); // 順番変えたり、ｘをfloatにするとエラー
cout<<z<<endl;
しかし、コンパイル時にifがつかえるんですねえ。凄いな、constexpr
415:デフォルトの名無しさん
24/08/24 15:09:12.28 yYuYqoCz0.net
std::is_same<T,double>::valueの代わりにstd::same_as<T,double>でも良いみたいですね．
416:デフォルトの名無しさん
24/08/24 16:42:04.52 6x2BzwZB0.net
#ifdef NDEBUG
/*pass*/
#else
class dbg_complex {
std::complex<double> m_complex;
public:
// std::complex<double> のメソッドのうち使うやつ同じシグネチャのメソッドを書き並べ、m_complexに移譲
...
private:
dbg_complex(doble); // 禁止
};
#define complex dbg_compled
#endif
※ 個人の感想です。
417:デフォルトの名無しさん
24/08/24 16:48:40.66 6x2BzwZB0.net
いちいち移譲せねばならないのはstd::complex<T>の継承が禁止されているためorz
実際デストラクタが十中八九virtualではないし、
>>416の最後の
#define complex dbg_complex
みたいな穴だらけの置換手段が嫌ならもうstd::complex<double> を普段からcomplexdbl という別名にすると決めてまう
すると
#ifdef NDEBUG
using complexdbl = std::complex<double>;
#else
using complexdbl = dbg_complex;
#endif
で済む
418:デフォルトの名無しさん
24/08/24 18:35:31.16 BJpt+Mj00.net
>>412
これかなり新しめのコンパイラじゃないと動かないので注意
419:デフォルトの名無しさん
24/08/24 19:16:42.78 6PXbzil00.net
行うべき解放処理が無い上ポリモーフィズムも不要なら、別にデストラクタがvirtualである必要は無いぞ
このケースで継承すべきかどうかはまた別として
420:デフォルトの名無しさん
24/08/24 23:53:59.32 4DIR6G6I0.net
>>412
constexpr if が使える (= C++17以上) なら std::is_same<T, U>::value よりも std::is_same_v<T, U> を使う方がシンプルだと思う
421:デフォルトの名無しさん
24/08/25 00:16:13.89 LfSHCV3h0.net
ま、お好きなの使えいいんじゃないんすか～
こちとら例文示しているだけで極めているﾜｹじゃないからぬ
422:はちみつ餃子
24/08/25 01:15:32.96 zZ+WMAII0.net
>>414
テンプレート型引数に require 節などで制約を付けた場合に制約に合致しなければオーバーロード解決候補から除外されるが、 static_assert や if constexpr での判定は解決が終わってテンプレートが実体化されるときに判定される。
つまり、より優先順位の低い候補に当てはめたいかもしれない場合は static_assert や if constexpr での判定をすべきではない。
状況によって使い分けがある。
それと >>418 が注意しているのは、テンプレートはテンプレート引数に依存しない部分は実体化されなくても検証されるルールだから。
(Two phase name lookup について調べてみて。)
つまり static_assert(false, ほにゃらら) と書いてあったらそのテンプレートが使われるかどうかに関係なく問答無用でエラーとして報告されていた。
新しい仕様では static_assert は実体化のときまで検証しないように挙動が改められたのだが、これは欠陥報告の形で問題提起されて過去の仕様に遡って修正されるので C++11 からこの仕様だったことになった。
新しいコンパイラでは C++11 を指定したときでも新しい挙動になる。
423:デフォルトの名無しさん
24/08/25 01:34:45.73 GxcwnqZY0.net
まあ、そんな小難しいこと言われても。C++が嫌われる理由だわ
424:デフォルトの名無しさん
24/08/25 02:05:31.18 LfSHCV3h0.net
実体化ってどっちみちコンパイルするときにエラー発生するんだから結果かわらねぇだろﾊﾞｶがよう
425:デフォルトの名無しさん
24/08/25 06:41:14.01 n8ainESh0.net
static_assert(false, "")は何かしらダミーの値入れて回避してたけど修正されてたんだ、知らんかった
426:デフォルトの名無しさん
24/08/26 00:27:52.82 JWWBXqLI0.net
false効かないﾊﾞｶｺﾝﾊﾟｲﾗはどうしようもないからどうにもならんか
//requires を使った方法
template<class T, class U>
requires(!(std::is_same_v<double,T>&&std::is_same_v<complex<T>,U>))
void f(T& x, const U& y)
{
x=y;
...
}
427:デフォルトの名無しさん (ﾜｯﾁｮｲ 2963-G6Q9)
24/08/27 07:16:06.25 NdPbjHCm0.net
特定の引数型についてテンプレート展開を阻止したいんなら
特殊化してその中にstatic_assert(false, "*** ERR ***")書いても昔は駄目だったんか恐ろしい……
428:デフォルトの名無しさん
24/08/27 07:35:09.57 NdPbjHCm0.net
しかしまあ特殊化してテンプレート引数の型Tについて
態と存在しないメソッドを呼ぶように書いたらその特殊化ケースについて展開を阻止できうる（適当
クラス内でint型定数が欲しかったら古き良き enum { ONE, TWO, THREE } で十分やし
同じことをやる手段を増やせば良いってもんじゃないぞPerlじゃあるまいし……
429:デフォルトの名無しさん
24/08/27 14:55:30.59 oHcafaf7a.net
perlの面白仕様
430:デフォルトの名無しさん
24/08/27 17:14:33.06 K2iTXH930.net
まぁ普通にSFINAEなり=delete指定なりコンセプトなりでオーバーロード候補から外す方が利用者視点でいえば自然だな
431:デフォルトの名無しさん
24/08/27 17:33:30.75 K7dNHCWQ0.net
#include <iostream>
#include <complex>
template <class T> decltype(auto) f(T x)
{
decltype(abs(std::declval<T>())) w;
w=abs(x);
return w;
}
int main()
{
using namespace std;
cout<<f(-1) << endl;
cout<<f(2.f)<< endl;
complex<double> z=complex<double>(1.0,1.0);
cout<<f(z)<<endl;
cin.get();
return 0;
}
いちかばちかでやったら、通りました。abs！ Who are you？ sizeof演算子と同じくコンパイル時に評価されるんですか？ というか、地味だけど declval が凄い。
432:はちみつ餃子
24/08/27 18:27:19.33 WfqXHPCU0.net
>>431
sizeof や decltype のオペランドは評価されないということになってる。
だからその文脈で関数を使う場合でもその関数が定義されている必要はない。 (宣言だけあればよい。)
評価されないけど実体化は起こるのでそのへんの理屈は複雑でよくわからん。
433:
24/08/30 02:40:03.60 qLymVnYK0.net
decval使ったコード始めてみたかも
434:デフォルトの名無しさん
24/08/30 05:15:18.21 ZIPlhev80.net
相互参照わっかんねぇ
435:デフォルトの名無しさん
24/09/02 12:36:59.33 bqeYsc0k0.net
相互参照は必要ない
最近はウェブプログラマのほうが賢くなった
すそ野が広がると質が良くなるらしい
436:デフォルトの名無しさん
24/09/02 13:00:06.45 Rco2Fp/20.net
必要ない理由ぐらい言ったら？
437:はちみつ餃子
24/09/02 14:42:22.37 o+5p2SR60.net
プログラムの文法要素が相互参照になっている状況という意味？
たとえば前方宣言が必要な場合とか。
それとも (実行時の) データ構造が相互参照ということ？
たとえば循環構造の後始末のやり方がわからんとか。
438:デフォルトの名無しさん (ﾜｯﾁｮｲ 0701-+rOo)
24/09/02 19:52:42.06 cn5uZ01w0.net
>>435
その「相互参照」って何?
439:デフォルトの名無しさん
24/09/05 00:06:16.92 /oUqYYg3a.net
相互参照も自己参照も一緒
自己参照なんて参照してるのは自己ではない
ホントの意味での自己参照は循環参照
440:デフォルトの名無しさん
24/09/05 18:17:57.29 xTcyjaky0.net
shared_ptrを使いたくなったら設計を見直すべき
441:デフォルトの名無しさん
24/09/06 07:27:10.33 Qb4sTpDj0.net
>>440
それは無理があるんじゃないのかね。
データ共有とかインターフェイス共有とか本質的に所有者が複数存在するオブジェクトはsharedptr使うべきかと。
設計ではモジュール間の疎結合・インターフェイスの汎用化を重視すべきで、そのためにはデータの共有方法が重要になる。
442:デフォルトの名無しさん
24/09/06 11:54:45.03 onD85wsiM.net
>>440
マルチスレッドセーフ考えたら使わざるを得ない場合は多々ある
言ってる意味がわからないならお前は経験不足
443:デフォルトの名無しさん
24/09/06 22:35:55.77 0hxwMUxG0.net
recurcive_mutexが欲しくなったら設計を見直したい、なら分かる気もする
444:デフォルトの名無しさん
24/09/07 11:45:08.02 Zy1zUumM0.net
C++11あたりから「生ポは使うな」みたいな極論で分かった気になってる思い上がった初心者が増えたからなぁ
445:デフォルトの名無しさん
24/09/07 11:58:09.00 UFsx2JaR0.net
>>444
生ポ使うよりかスマートポインタの参照を使った方がマシだったりするからなぁ。スマートポインタがスタックフレームにあるなら安全だし。
スタック変数専用仮引数とかあればもっと安全になるのになぁ。
仮引数の種類はもっとあっていいと思う。
446:デフォルトの名無しさん
24/09/07 16:26:14.57 lSV8lU690.net
>>445
考え方にもよるだろうけど、確保も解放も所有もしない関数でスマポ受け取る必要あるか？
特定の用途で管理されている特定のポインタしか許容しない、という意図ならスマポの参照でもいいだろうけど、汎用性は無いよね
生ポ受け取る場合暗黙のキャストも効かないし
447:デフォルトの名無しさん
24/09/07 20:17:38.39 Ci+xhqlU0.net
>>442
むしろshared_ptr<T>でスレッド間共有オブジェクトを保持するのは
生ポに対するshared_ptr<T>のメリットが無い……
可能な限りスレッド間共有なんてことはやめてconstオブジェクトのコピーにするのが正義……
>>439
自己参照ではないが前方宣言が必須の例、
class TreeNode;
class TreeNode {
std::shared_ptr<TreeNode> m_pLeft;
std::shared_ptr<TreeNode> m_pRight;
public:
TreeNode();
...
};
448:デフォルトの名無しさん
24/09/07 20:21:44.33 Ci+xhqlU0.net
んまー前方宣言が必須というのは言い杉やったかもしれんorz
TreeNodeみたいなクラスはノード毎にヒープを確保するなんてことはやめて専用のアロケーターを設けて
専用の領域をまとめて確保して、
木全体がいらなくなったら木をトラバースすることなく一気に解放するのが本当やが
その場合m_pLeftやm_pRightにあたるのはポインタではなくて専用の領域（配列）のindexとかにすれば
前方宣言は不要、
449:デフォルトの名無しさん
24/09/07 21:38:34.24 lSV8lU690.net
>>442
使わざるを得ないは言い過ぎじゃね
同期取るのにshared_ptrのアトミック保証に依存するしか方法が無いの？
競技プログラマか何かか？
450:デフォルトの名無しさん
24/09/08 00:33:39.65 vgBqrjWA0.net
shared_ptrの内部的な参照カウンタとかはともかく
保持しているオブジェクト自体はアトミックでもなんでもないでしょ
ってなんか勘違いしてる?
451:デフォルトの名無しさん
24/09/08 01:27:17.93 6Lpw1aoe0.net
持ってるポインタの指す先のオブジェクトがアトミックになるとか言ってると思ってんの？アホかw
452:デフォルトの名無しさん
24/09/08 01:32:50.82 TMvzCbR60.net
そこでRustですよ！
453:デフォルトの名無しさん
24/09/08 12:52:42.06 Lw7YNDXG0.net
でたｗ
布教ﾏｿw
454:デフォルトの名無しさん
24/09/10 11:29:59.05 v6KS9t6sM.net
>>447
お前の理解はshared_ptrの一面だけだな
ようするにunique_ptrの延長でしか見てない
shared_ptrがどうしても欲しくなるのは
オブジェクトのリリースタイミングが非決定的であるとき
これは一般的にマルチスレッド環境
お前のTreeNodeの例はそれこそ生ポで実装しても対して苦労しないが
例えば動的可変multi producerなqueueの場合確実に安全なqueueの解放タイミングを知るにはリファレンスカウントのような制御が必要となる
当然この場合コピーすれば安全なんて寝ぼけたことにはならない
455:デフォルトの名無しさん
24/09/10 13:20:49.36 KGjTz1X0a.net
x 対して
456:デフォルトの名無しさん
24/09/10 15:36:50.97 +l9ylb2n0.net
それで自己参照ってのは結局何のことを指して言っていたんだい
457:デフォルトの名無しさん
24/09/10 15:39:03.70 +l9ylb2n0.net
あ、相互参照が先か
>>436の言うところの
458:デフォルトの名無しさん
24/09/11 12:14:54.12 n6/LwjNL0.net
(*this)
↑
自己参照
459:デフォルトの名無しさん
24/09/11 12:19:01.05 n6/LwjNL0.net
木のノードはstd::vector<>で確保する
と言われて、だよねってなる人はnewもほとんど必要ない
460:デフォルトの名無しさん
24/09/11 12:22:29.60 n6/LwjNL0.net
木の巡回は、巡回方向別にアダプタとしてイテレータを用意することが出来る
良くある行きがかり順のイテレータはスタックを使って作る
461:デフォルトの名無しさん
24/09/11 15:12:04.16 1n/VD1trM.net
でvectorの拡張で破綻すんだろ？
462:デフォルトの名無しさん
24/09/13 16:29:50.66 bblj+c3pa.net
move禁止
463:デフォルトの名無しさん
24/09/13 19:59:43.80 2C9M8qgO0.net
move禁止したらvector使えないし
464:デフォルトの名無しさん
24/09/17 12:59:42.12 TMGdiCOOa.net
それならオブジェクトを保持するためのオブジェクトと
moveためだけのインデックスを分けるかな
465:デフォルトの名無しさん
24/09/17 16:24:30.60 DN+X/Cyr0.net
何がしたい
あほでしょ
466:447
24/09/21 20:05:42.93 FUSKAHoo0.net
何やら集中砲火を浴びている>>442 やが
マルチスレッド状況でshared_ptr<T>を超有効活用できる手が一つあったわ；；；
スレッド間の共有オブジェクトをポインタpで保持する際の問題点は、
そのポインタを知っている複数スレッドの間でpが指すオブジェクト*pへのアクセスを悉く排他制御せなばならない点やが
逆にpを知っているスレッドが任意の時刻につき1つだけなら、オブジェクトのアクセスに対して排他の必要が無い
それでいてスレッドへのデータの受け渡しに関してコピーの手間は減らせる
例:
なんちゃらWorkerスレッドオブジェクトをshared_ptr<Worker>のキューで保持しておく
スレッドfooが使うときWorker1をshared_ptr<Worker>としてpopする（←これは排他が要る
スレッドbarが使うときWorker2をshared_ptr<Worker>としてpopする（←これは排他が要る
...
（スレッドfooやbarはWorker1、2をそれぞれ独占的に使用できる） ←重要
...
スレッドfooが使い終わったWorker1をキューにpushする（←これは排他が要る
スレッドbarが使い終わったWorker2をキューにpushする（←これは排他が要る
467:447
24/09/21 20:13:25.63 FUSKAHoo0.net
ていうか2週間ぐらい前から作っていたやつが今さっき完動すた、
468:デフォルトの名無しさん
24/09/21 20:35:47.52 FUSKAHoo0.net
std::vector<TreeNode> nodes;
ならnodesを拡張したとき破綻するかもしれんが（nodeをnodesのindexで管理するならその限りではない
std::vector<std::shared_ptr<TreeNode> > apNodes;
ならapNodesを拡張しても破綻しないYO!（要素の実アドレスは保たれる
469:デフォルトの名無しさん
24/09/22 08:21:05.99 e5FZYjui0.net
それ何のためのshared_ptrなの？unique_ptrでいいというか横からコピーされないようにそうすべきでは
470:デフォルトの名無しさん
24/09/25 13:57:54.93 N5yN4IuU0.net
>>466
>>442 を書いたのおれだけど、なんでおれが集中砲火浴びてることになってんだよ
生ポとか意味不明なこといってる>>447は一見してわかるクソレスだろ
おまえはそれ以上のクソレスにクソコード
でもお前の勝ちだ
クソコードに2週間かけた情熱に免じて親切におしえてやるわ
shared_ptrはpに誰かがアクセスしている可能性がある間は決してdeleteされないことを保証できるのが肝
(pの先の排他ではこれは実現できない)
もちろんこれも正しく使わないと保証できない
よくあるミスは知ったかぶって参照カウントを操作しないようにshared_ptrを参照渡しとかにするやつな
その間に絶対deleteされない保証がないならやってはいけない
471:デフォルトの名無しさん
24/09/26 03:21:09.01 5BtHXQaO0.net
あーなるほど、一貫してshared_ptrの実体を渡してればそういう保証も出来るのか
自分の場合自前で排他処理や生存保証作ってたけど確かに大きなメリットだね
(オブジェクト内部の排他は別に必要だとしても)
472:デフォルトの名無しさん
24/09/26 10:52:52.31 R5lWYvWFa.net
そんなあなたにRust
473:デフォルトの名無しさん
24/09/26 11:26:35.22 r0pzUHiv0.net
>>472
c++コードと混在できるようになってからの話だな。
既存c++を捨てなきゃならんのなら要らん。
474:デフォルトの名無しさん
24/09/26 11:37:49.48 R5lWYvWFa.net
もちろんRustをやるにはC++を捨てる覚悟が必要
C++コード(特にテンプレやclass)とは相性最悪
475:デフォルトの名無しさん
24/09/26 11:38:22.04 R5lWYvWFa.net
>c++コードと混在できるようになって
Rustについて言うなら
おそらくそんな未来は永久に来ない
476:デフォルトの名無しさん
24/09/26 11:39:08.38 R5lWYvWFa.net
誤解の無いように言っておくと
(一部機能に限れば今でも混在出来るけど)
基本的にはC++とは相いれない
477:デフォルトの名無しさん
24/09/26 18:22:32.63 sl+cfKHN0.net
ならc++にRustの機能が取り込まれるのを待つ。
Rustが大人気になったら、さすがに標準委員の連中も初心者・コーダー向けの"Safe c++"をやる気になるだろ。
478:はちみつ餃子
24/09/26 18:52:53.17 B+Au+yIB0.net
>>477
もう Rust を使えばよくない……？
479:デフォルトの名無しさん
24/09/26 19:43:24.82 sl+cfKHN0.net
>>478
>>473だっつうの。
Kotlinみたいなのが欲しいのであって、Clojureみたいなのは要らん。
480:はちみつ餃子
24/09/26 20:25:47.69 B+Au+yIB0.net
>>165
C++ のコードを Rust から呼び出したりするくらいのことは簡単に出来るよ。
たぶん (Java に対する) Kotlin みたいなこととして思い浮かべているようなことは出来る。
Rust がやってるような安全性の保障を自動では受けられない。
当然だが安全ではない (安全性が検証されていない) C++ のコードが Rust から呼び出すことで安全になったりはしない。
大抵の場合に Rust の都合に合わせてラッパーを書くことになる。
481:デフォルトの名無しさん
24/09/27 10:23:27.00 n6BA5joS0.net
>>480
KotlinとJavaみたいにソースコードを混在できるレベルの相互運用性てあったっけ？
Rustとc++では無理だと思うけど。
482:デフォルトの名無しさん
24/09/27 10:44:00.51 02Aq/BhWM.net
cxxとかあるけど個人的には中途半端だから使わない
普通に共有ライブラリにして呼び出す方が素直で汎用的で良い
483:デフォルトの名無しさん
24/09/27 12:33:43.81 6/1p1gGO0.net
スマートポインターを使うように強制できる機能とかなら必要ないなあ
484:デフォルトの名無しさん
24/09/27 16:51:52.33 pgg/4VuRa.net
>>473 のような未来は永遠に来ない
485:デフォルトの名無しさん
24/09/27 16:54:13.57 pgg/4VuRa.net
>>482
結局Cが正解なんよ
C++のスレで言うのもなんだけど
486:デフォルトの名無しさん
24/09/27 16:54:31.95 pgg/4VuRa.net
>>481
同意
487:デフォルトの名無しさん
24/09/27 16:54:58.40 pgg/4VuRa.net
>>480
嘘つくな
出鱈目言うな
488:デフォルトの名無しさん
24/09/27 17:14:28.28 n6BA5joS0.net
>>483
コーダー向けので考えるなら、スマポ強制は最優先だろ。
生ポインタを(コーダーが)保存できなくするだけでも随分安全になる。あと生ポインタdelete禁止とか。
489:デフォルトの名無しさん (ﾜｯﾁｮｲ 728c-rNKn)
24/09/27 18:24:18.27 dg7IL8lg0.net
極限のパフォーマンスは別に要らないから安全にしたいという要件なら GC が既に解決しているし
今更生ポインタを禁止したところで C# や Java と同じ方向性のナニカにしかならんじゃろ
490:デフォルトの名無しさん
24/09/27 18:46:28.46 EoeiRCVP0.net
gcがあったらメモリリークしないなんて幻想未だに信じてるとはね
491:デフォルトの名無しさん
24/09/27 18:59:34.32 RwmUzOsi0.net
リークの話なの？
492:デフォルトの名無しさん
24/09/27 19:07:06.62 n6BA5joS0.net
>>489
ライブラリとかフレームワークを使う側のコーダーと作る側のライブラリアンは性能要件が全然別。
コーダーに対してライブラリアンが「コーダーのコードに極限のパフォーマンスは別に要らないから安全に「させたい」」というのはあるだろ。
493:デフォルトの名無しさん
24/09/27 23:12:04.55 cfj6fT7K0.net
>>492
それならライブラリ側でメモリ周りを隠蔽するような作り方も出来ると思うけど
ユーザー(コーダー)にはインスタンス使わせるけど内部では参照カウントなりスマポなり使ってるみたいな
それですら問題が起きるようならユーザーがクソ
494:デフォルトの名無しさん
24/09/28 10:42:06.28 swed/tX60.net
C++はどんな安全策敷いてもユーザー側がその気になればいくらでもぶち壊せるからね
ライブラリがあんまりそこ頑張っても仕方ない
495:デフォルトの名無しさん (ｱｳｱｳｴｰ Saaa-rNKn)
24/09/28 12:39:39.83 gf2/NL3ha.net
Rustなら壊れないみたいな言い草だな
496:デフォルトの名無しさん (ﾜｯﾁｮｲ 77ba-vp5J)
24/09/28 13:06:22.71 ZP4SxDa50.net
C++で書かれたChrome V8エンジンをRustから扱えるRusty V8というライブラリがリリースされたというニュースを見た
メモリ安全性を確保して呼び出しオーバーヘッドもゼロなんだって
ほんとかな？
ただのラッパーじゃないの？
C++側でメモリアクセス違反があれば落ちそうだけど
497:デフォルトの名無しさん
24/09/28 14:26:57.72 yW35cSECM.net
その手の話はMICROSOFTの新機能ぐらいい思っておけば
腹も立たない
498:はちみつ餃子
24/09/30 22:26:30.09 JxqgGnHQ0.net
>>496
Rust の標準ライブラリだって内部は unsafe だらけだぞ。
unsafe は Rust のメモリ安全性検査の例外とする指定で、検査はされないが安全であることはプログラマが保証しないといけない。
ただ、 unsafe な部分を慎重に押し込めて (押し込めるのが正しく出来ていれば) あとは Rust のメモリ安全性検査に頼ることが出来る。
ずっと気を付けなきゃならない C++ よりは面倒ごとを基盤に押し込めたら後は機械が検査してくれるほうがマシという程度の話。
押し込めた中に問題があればそりゃ当然駄目だよ。
499:デフォルトの名無しさん
24/10/01 02:05:59.60 J7GPtKrz0.net
V8エンジンてCVE脆弱性で毎月アップデートの口実にされる迷惑なやつだからさっさとRustで書き直せよ
500:デフォルトの名無しさん
24/10/01 15:19:57.32 KXGxeTHwM.net
>>498
>押し込めた中に問題があればそりゃ当然駄目だよ。
当然分かっているだろうが、unsafeの中だけでなく、
それが外側に及ぼす影響にも問題が生じないように作らなければなら
ないが、それにはunsafeとRustの両方に対する深い理解が
必要となるだろうな。
501:デフォルトの名無しさん
24/10/01 18:36:21.46 al1nAqGBM.net
>>500
unsafeの中を通過する時には問題ないが、
戻り値などや、連携する他のメソッドなどが
関係した結果、どこかで分かりにくいメモリーエラー
になるようなことも避ける必要が有るが、
それにはかなりRustの内部構造(?)に対する深い知識
と理解が必要となりそうだ。
502:デフォルトの名無しさん (ﾜｯﾁｮｲ 1fb1-/QnX)
24/10/17 11:01:19.65 P7X9/HPx0.net
>>422
これ、static_assertだけ修正してもしょうがない気がするんだけどなぁ
他にも実体化しないはずの分岐でチェックされてエラーにされることあるし
まぁ条件式に無理矢理テンプレート入れて回避は出来るけど
503:デフォルトの名無しさん
24/10/19 17:30:35.94 vb3IsOJN0.net
>>491
Rustのオブジェクトの所有権管理の強制はコンパイラに従う限りリークしない
（病的な反例があるかどうかは知らん
からリークの話ではないが、GC付き言語で解決という香具師が現れたから
504:デフォルトの名無しさん
24/10/19 17:31:10.99 vb3IsOJN0.net
>>490な発言になったんじゃないの
知らんけど
505:デフォルトの名無しさん
24/10/21 07:19:50.64 ThoL8xQh0.net
>>503
RustはRcの循環参照解決できたの？
公式ソースある？
506:デフォルトの名無しさん
24/10/21 14:54:46.51 WHCxApN50.net
C++派だが、Rustをもってしても、相互参照みたいなものは、人類には早いらしい
(設計段階で)無理しないこったな。。
507:デフォルトの名無しさん
24/10/21 15:57:11.21 Hhc6wfX80.net
そもそも静的解析で解決できる問題か？
508:はちみつ餃子
24/10/21 16:03:29.88 6JU3cZPt0.net
循環参照をしたいときに出来ないのも困るしな。
なるべくやらないに越したことはないが、やるなら後始末は人が考えないと仕方ないわ。
509:デフォルトの名無しさん
24/10/21 22:48:14.20 XvJERuqr0.net
食事する哲学者の問題……
Rustだと循環参照するコードを書きにくくなっているから
循環参照によるリークとか病的な反例のうちなんじゃないの
知らんけど
ノードNode同士が論理的には循環参照し得るんだけど
その所有権をスーパーバイザ的な配列superArray: Node[]が持っていて、
510:デフォルトの名無しさん
24/10/21 22:53:33.76 XvJERuqr0.net
Node間の参照はsuperArrayのindexで済ませるというのもRustではすんなり通してくれな
いんだっけどうだっけ……
Node& node1 = superArray[0];
Node& node2 = superArray[1];
node1.next = 1;
superArray[node1.next].value = 123; // node2.valueに書く
node1.nextがsuperArray[]の添え字範囲内であることを機械的に保証するためにRustはどんな魔法を使ってくれる
のか
511:はちみつ餃子
24/10/22 11:28:00.82 UXnTPhGj0.net
>>510
Rust では実行時にチェックされて範囲から外れていたら panic (C/C++ で言うところの abort みたいなもの) する。
URLﾘﾝｸ(doc.rust-lang.org)
C/C++ のように配列がポインタになるということはなく、スライス (C++ で言うところの span みたいなもの) が基本型として組み込まれているので範囲チェック出来る。
コンパイル時に範囲内であることがわかる状況なら最適化で消えることもあるみたいだけど
実行時に外部から入ってくる値に依存することもあるので実行時にチェックしないとどうしようもない。
512:デフォルトの名無しさん
24/10/28 13:44:32.71 A9ortPvu0.net
enum、
文字列への変換、
大変すぎて、ビックリした
513:デフォルトの名無しさん
24/10/28 14:06:10.17 /lht/Ba/0.net
俺はenumの機能を拡張するクラスを自分で定義してるな
それで文字列変換も文字列からの変換も出来る
514:デフォルトの名無しさん
24/10/28 15:41:01.09 xcgYWtNU0.net
autogenerated.txt.c みたいなの使うのも手だぞ 急がば回れ
そしてCよりはうまく書ける
515:デフォルトの名無しさん
24/10/29 08:22:28.04 XRXAB2XQ0.net
>>514
うーん、どんなもの？それ