[過去ﾛｸﾞ] C++相談室 part165 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
286: (ﾜｯﾁｮｲ ffe0-UH2C) 2024/02/18(日)09:00 ID:c1Urupub0(1) AAS
>>269
そのあたりの難しさを考えると、例外廃止してoptionalに統一したほうがいいかもな。
少なくとも例外みたいに変なフローで飛んで来ないし。
287(1): (ﾜｯﾁｮｲ e3f9-NGC7) 2024/02/18(日)09:39 ID:9f8IS57r0(1/3) AAS
ぶっちゃけ>>283がなに言ってるのかわからない
継続してそれが原因で？
いやいやw
突如落ちるより、保存できるデータは保存してもらう機会を与えることは出来るだろ
なんでお前は何事もなかったかのように作業を続ける前提でしか話を聞かないんだ？
オブジェクトの状態が変わっているかも？
変更前のデータと比較して変わっていたらユーザに確認すればいいだろ
省2
288: (ﾜｯﾁｮｲ cfcf-sYtR) 2024/02/18(日)09:41 ID:WHoJTRhT0(1/2) AAS
>>285
>例外の種類しか頭にないのか
>>283が仕様に明示されていない例外を話題にしているからだが。
>任意の場所での例外発生に対応するなん現実的にできないということ
これはどういう意味なんだろうな。
着目するのは自分が呼び出している処理から上がってくる例外に対して例外安全かどうかであって
それは基本的に局所的に判断できるもの。
省1
289(1): (ﾜｯﾁｮｲ e3f9-NGC7) 2024/02/18(日)12:27 ID:9f8IS57r0(2/3) AAS
> これはどういう意味なんだろうな。
そうそれ
tryブロックで囲った部分（つまり任意）の例外発生に対応するのが例外処理なのになにが出来ないというのか
想定している例外が発生して継続できると判断したなら続ければいいし
ダメならユーザに通知してもちょも安全な方法を選択させればいい
でもってそれは想定していない例外の発生でも同じ
ただ致命的でどうしようもないなら強制終了させるだけの話で、想定していない例外はなんでもかんでも強制終了じゃ例外処理使う意味が薄まってしまう
290: (ﾜｯﾁｮｲ e3f9-NGC7) 2024/02/18(日)12:28 ID:9f8IS57r0(3/3) AAS
もちょも は もっとも の まちがい
291(2): (ﾜｯﾁｮｲ 6f5b-ERL4) 2024/02/18(日)13:22 ID:JX7gxI3D0(2/2) AAS
>>287
ファイル保存するなとか言ってない
それぐらい終了処理のひとつだろ
ログファイルもシグナルトラップして必ずフラッシュさせるのが常套手段だろ
意味不明な例外が発生しました
データが破損してないかあなたが確認してください
動作無保証ですが処理継続しますか？yes/no
省1
292: (ﾜｯﾁｮｲ e304-hmqi) 2024/02/18(日)14:01 ID:6Yt/CDIt0(1) AAS
私が20代の頃に見かけた論争が今も繰り返されてるのかわいい🩷
293: (ﾜｯﾁｮｲ ffad-mJpf) 2024/02/18(日)15:55 ID:1iQutSwY0(1) AAS
>>291
それを思いついたお前のセンスがないと言うことになるが…
俺は確認しろと言っただけだし確認には様々な方法がある
294: (ﾜｯﾁｮｲ cfcf-sYtR) 2024/02/18(日)16:26 ID:WHoJTRhT0(2/2) AAS
>>291
まさか、何も言わずにいきなり落とす方が良いとか言うわけじゃあるまい。
295: (ｽｯｯﾌﾟ Sd1f-p9fr) 2024/02/18(日)17:54 ID:L2mk1x1ad(1) AAS
>>289
もちょカワイイよね
296: (ﾜｯﾁｮｲ bf9a-/DPD) 2024/02/18(日)18:17 ID:LeQ06zof0(1) AAS
>>280
実生活のあれと似てますよね。「引っ越すことになりました。新住所はXXです」と早めに
連絡したら、気の早い知人がそこに押しかけてきて「なんやまだ引越しとらんやんけ」となる
やはり引越し作業完了を待ってからの方がいいのか。ってちがうか
297: (ﾜｯﾁｮｲ 1b63-9XlH) 2024/03/02(土)23:41 ID:C77pR/Zl0(1/3) AAS
>>282
>相変わらずずれてるな。 catch する == 原因を調査しない じゃないわけ
>249に賛同いただけていないということは、発生してもいない例外について予防的にtry { } catch () を入れようとしていることは
確定的に明らか
で、例外というﾌﾞﾂは「例外なく」悪い知らせなので（∵仮に良い知らせを例外で寄越すライブラリがあったらそれ自体悪い知らせである
普通の人は悪い知らせが来る前に処置しようとする。すわなち例外が来ないように（可能な限り）修正する。
try { } catch ( ) でひっかけて原因調査兼確実な修正でざい、それが一番効率が良い方法論である、などと主張するのはおかしい人だけ……
298(1): (ﾜｯﾁｮｲ 1b63-9XlH) 2024/03/02(土)23:49 ID:C77pR/Zl0(2/3) AAS
>>284
例外安全というもののスコープに対して考察が足りていない
1.
例外安全なオブジェクト foo のデストラクトが他の例外によって引き起こされるケースでは
foo の安全な終了は（メモリかファイルステムか何かが物理的にぶち壊れてOSがパニックになったとかでない限り
ほぼほぼ保たれるから>>284のような言い方はできるっていやーできるが、
システム全体については>>283の通りであって全然安全ではない
省4
299(2): (ﾜｯﾁｮｲ 1b63-9XlH) 2024/03/02(土)23:57 ID:C77pR/Zl0(3/3) AAS
それはそうとして、予防的なtry{ } catch () の何が一番駄目かというと、設計上のトレードオフをわけわかんなくすることが確実な点
例外発生後の状況というのはたいてい>>283の通りのわけなので、何かを捨てて何かを取る
（例えばシステムは最悪落ちても構わないが、例外安全なオブジェクトfooでリソースAの整合性は死守する等）
のトレードオフが発生するがそういうのこそ慎重な設計と考慮が必要な事項であることは確定的にあきらか
プログラムの全階層にtry { } catch ()入れたら完璧などというｱﾌｫはやっぱtry { } catch () しないのが正しい
300(1): (ﾜｯﾁｮｲ 0fcf-0WZ8) 2024/03/03(日)21:57 ID:735dldsp0(1) AAS
>>298
自分が呼び出す関数が例外安全にできているかどうかと自分の処理が例外安全かどうかをごっちゃにしてるだろ。
しかも、呼び出す関数からドキュメント化されていない想定外の例外が発生するなら例外安全に作られていないだろうという
変な決めつけが混じってる。
例外安全なコードは例外の種類に依存しない。知ってる冷害に対しては安全だけど知らない例外が飛んできたら安全じゃない
なんてのはそもそも例外安全とは言わない。
301(1): (ﾜｯﾁｮｲ ef0a-qSkN) 2024/03/03(日)22:08 ID:qMaLplcd0(1) AAS
>>300
お前さ、すべてのnoexcept関数呼び出しの例外テスト書いてんのか？
それが出来もしない理想論だって言ってんの
302(1): (ﾜｯﾁｮｲ 3b7c-85wQ) 2024/03/03(日)22:31 ID:GdJ/jhkt0(1) AAS
>>301
自分でnoexcept指定した関数のことなら投げないことを確認するテストくらい書けよ当たり前だろ
303: (ﾜｯﾁｮｲ 0fcf-0WZ8) 2024/03/04(月)00:08 ID:gWJ01aQ50(1/2) AAS
>お前さ、すべてのnoexcept関数呼び出しの例外テスト書いてんのか？
悪魔の証明をテストすんのか
304: (ﾜｯﾁｮｲ ef0a-qSkN) 2024/03/04(月)07:57 ID:D3yk9beu0(1) AAS
>>302
100%自分で書いてるコードなら未知の例外なんて起こらんだろ
話の筋理解してからレスつけろや三流
305: (ﾜｯﾁｮｲ 8b63-eOBD) 2024/03/04(月)07:58 ID:KYG2Ugpe0(1/3) AAS
なんか予想外に低ﾚなレスポンスを寄越した>>299……
さすがに>>283の後に>>284のような楽天的なことを言えるだけのことはあるということか……
例外安全は確かに目指すべき境地であり、例外安全なオブジェクトだけでコードを書けば
その関数は例外安全となる。try { } catch ()など一切不要、となるわけで一見実現が簡単に思える
が、例外安全なオブジェクトだけかをもれなく機械的に確認する方法は無い上に、
中断したら別物になる（処理の順序が命）というアルゴリズムというものの本質的特性により、
>>183 のような try { } catch () が必要なケースは隙あらば混ざり込んでくるから（※1）
省4
306: (ﾜｯﾁｮｲ 8b63-eOBD) 2024/03/04(月)07:59 ID:KYG2Ugpe0(2/3) AAS
（※1） >>183 の関数そのものは、例外安全なスレッドオブジェクトでも使ったらtry { } catch () 無しの例外安全な関数うに書き直すことはできうる
307: (ﾜｯﾁｮｲ 8b63-eOBD) 2024/03/04(月)08:09 ID:KYG2Ugpe0(3/3) AAS
あと寝てて思ったがプロセスが死んでもサービスが継続したらお客様には迷惑を掛けずに済むので
（直接そういうのをやってちるわけではないので強くは言わんが
ウォッチドッグタイマー的な死活監視で異常あらばプロセス再起動とかマシンを切り替えるとか方法はいくつもあって、
十分テストされたプログラムならクラッシュ頻度をポアソン分布とみなして信頼度も出せる
やっぱ「お客様の前で落ちたら恥ずかしいから」というつまらないプライドを基本的動機とする
try {
....
省6
308: (ﾜｯﾁｮｲ 9fad-ZLJX) 2024/03/04(月)08:50 ID:MzjtGtOW0(1) AAS
> なんか予想外に低ﾚなレスポンスを寄越した>>299……
299はお前自身じゃないのか、と俺は思う
309: (ﾜｯﾁｮｲ 0fcf-0WZ8) 2024/03/04(月)08:53 ID:gWJ01aQ50(2/2) AAS
>例外安全は確かに目指すべき境地であり、例外安全なオブジェクトだけでコードを書けば
>その関数は例外安全となる。try { } catch ()など一切不要、となるわけで一見実現が簡単に思える
例外安全だからといってcatchが不要になるわけないだろ。
根本的なところで勘違いしてるから頓珍漢が主張を続けてるわけだな。
310: (ﾜｯﾁｮｲ abe4-XE6S) 2024/03/04(月)10:20 ID:QvxlWFfk0(1/2) AAS
例外安全には基本保証・強い保証・no-fail保証がある
例外がスローされない関数を作ればno-fail保証がある
基本保証や強い保証は例外発生後も不整合が発生しないもの
たとえば例外が発生した関数をもう一度呼び出すと「すでに実行中です」とエラーを返すようなものは例外安全ではない（おそらく実行中フラグ変数が立ったままになっている）
311: (ﾜｯﾁｮｲ abe4-XE6S) 2024/03/04(月)10:23 ID:QvxlWFfk0(2/2) AAS
10行のデータをファイルに出力するとき、例外が発生して5行だけデータが出力されてしまうのは強い保証があるとはいえない
例外が発生した際にデータを書き込む前のファイル状態に戻れば強い保証がある（例外安全である）といえる
312: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 3b32-hL5K) 2024/03/04(月)12:10 ID:ASLjljy+0(1) AAS
誤解のないように念のため補足。
この場合の「強い」という用語は性質の分類であって強いことがより良いというわけではないという話をしてる。(んだよね？)
例外を出さずに済むならそれに越したことはないよ。
でも、ひとつの部品の中では問題を解決できないことがあるからこそ例外を用いて他の部品と連携しての解決を試みるわけ。
連携するには保証の強力さよりも保証範囲の明瞭さ (明瞭でもカバーしようがない設計はあかんが) が大事で、プログラム全体で整合性が保たれていれば例外安全と言える。
仕様が不明瞭なライブラリもあるのが現実だってのはそりゃそうだけど、出来が悪い部品とつじつま合わせをしきらないってのは例外のせいでも C++ のせいでもない。
313(1): (ﾜｯﾁｮｲ f7f0-B2uz) 2024/04/08(月)15:38 ID:IvxniXPw0(1) AAS
std::initializer_listについて質問です
下の例ですがコンストラクタの引数に配列リテラルを指定した場合、リストがコピーされてしまいますよね？
これは無駄なので回避したいのですが良い方法はありますか？
外部ﾘﾝｸ[html]:cpprefjp.github.io
314: (ﾜｯﾁｮｲ df01-g9Lk) 2024/04/09(火)12:13 ID:gepNgOiE0(1) AAS
どこのコピー?
315: (ﾌﾞｰｲﾓ MM3e-Nnmc) 2024/04/09(火)12:52 ID:80QuF/MqM(1) AAS
リテラルのコピーを気にするならconstexprじゃねーの？
ほんとにコンパイル時に定数になるかは知らんけど
316(2): (ﾜｯﾁｮｲ 7b32-B3tP) 2024/04/09(火)15:22 ID:hsAXyuRl0(1) AAS
>>313
C++ に配列リテラルはない。
その書き方で出てくる波括弧はリスト初期化の構文の一部で、
波括弧の部分単体は配列リテラルではない。
実行時にオブジェクトの構築を避けるならコンパイル時に構築することになるが
それはそれで色々と制約があるんでほんまにそれが必要なんか？
というのはよく考えないといけない。
省2
317(2): (ﾜｯﾁｮｲ c3c9-hAMa) 2024/04/09(火)20:10 ID:T/amOWJO0(1) AAS
とあるtemplateの関数を実装しているのですが、
const指定の振る舞いがよくわからなくなったので
質問させてください。
以下の(だいぶ簡略化した)コードで、
f_without_const<const int*>(const int* a)
はコンパイルが通るのですが
f_with_const<int*>(const int* a)
省2
318: (ﾜｯﾁｮｲ f7f0-B2uz) 2024/04/09(火)20:30 ID:lDhzon+/0(1) AAS
>>316
なるほど
ここまでやるメリットはなさそうなので大人しくデフォルトの書き方にしておきます
319: (ﾜｯﾁｮｲ 2790-Bmwq) 2024/04/09(火)21:45 ID:+RmfoJzl0(1) AAS
>>317
templateは型が違うと全くの別物として処理するからだと思う
320: (ﾜｯﾁｮｲ 7b10-qE2a) 2024/04/09(火)22:00 ID:5hAg3cgl0(1) AAS
>>317
template <class T> void f_with_const (const T t);
これに対応させるなら f_with_const<int*>(int *const a)
321: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7b32-B3tP) 2024/04/10(水)08:39 ID:Fk7YBwaR0(1) AAS
const T t に対して const int* a が来たら
字句の順序としては T に int* が対応してるように見えちゃうもんな……。
322: (ﾜｯﾁｮｲ c37a-hAMa) 2024/04/11(木)21:42 ID:0cjrPM+u0(1) AAS
317です、返信遅くなってすみません
確かに言われてみればconstが修飾してるのはint*なので、意味的にint *constが正しいですね…
ありがとうございました
323(1): (ﾜｯﾁｮｲ b77c-0iQt) 2024/04/14(日)14:49 ID:tTNkn9kB0(1) AAS
先月東京で標準化委員会の会議あったらしいけどなんか情報ないの？
324: (ﾜｯﾁｮｲ ff33-m4LK) 2024/04/14(日)15:03 ID:H7y3imqp0(1) AAS
あるよ。 外部ﾘﾝｸ:github.com
325: (ﾜｯﾁｮｲ 7f52-9wFU) 2024/04/16(火)00:50 ID:38VQ+8UT0(1) AAS
>>323
外部ﾘﾝｸ:www.reddit.com
326(1): (ﾜｯﾁｮｲ 67b1-Jq5A) 2024/05/01(水)21:36 ID:/DCu7vsT0(1) AAS
python みたいに何でも格納できる辞書型ってC++には無いよね？
327: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 8732-nVjz) 2024/05/01(水)22:29 ID:IV4TsWNk0(1) AAS
>>326
要素を std::any にすればだいたいどんな型の値でも入れられる。
いろんな型を入れたところで使うときには元の型として取り出さないといけないから
処理は煩雑になってあまり良いことはないけど。
328: (ﾜｯﾁｮｲ 8f7c-Y/5H) 2024/05/09(木)20:23 ID:MzADiHDk0(1) AAS
外部ﾘﾝｸ[html]:cpprefjp.github.io
#elifって今まで非標準だったのかよ…
329: (ﾜｯﾁｮｲ bed6-w0ma) 2024/05/09(木)21:19 ID:M6C6+6vz0(1) AAS
何いってんだ
330: (ﾜｯﾁｮｲ bbda-JG92) 2024/05/10(金)11:53 ID:P+BretyD0(1) AAS
#elifは大昔からあるぞ
331: (ﾜｯﾁｮｲ 8f7c-Y/5H) 2024/05/11(土)09:12 ID:YR9R4Y390(1) AAS
cpprefjpが間違ってるだけ？
それともずっと規格から欠落してたけど誰も気付いてなかったパターン？
332: (ﾜｯﾁｮｲ bed6-w0ma) 2024/05/11(土)11:19 ID:PrWZroBw0(1) AAS
規格が読めないならC++やめろ
333: (ﾜｯﾁｮｲ 0b63-IWIS) 2024/05/11(土)19:02 ID:RotYKdRC0(1) AAS
elifを逆から読んだらfile
ラリーはこれを嫌ってPerlではelsifにした（適当
334: (ﾜｯﾁｮｲ bbda-JG92) 2024/05/11(土)22:20 ID:HBPowvO20(1) AAS
シェルが変だからな
case ～ esac
if ～ fi
335: 警備員[Lv.23] (ﾜｯﾁｮｲ 1563-WQ8n) 2024/06/06(木)07:08 ID:Glzej5210(1/3) AAS
てｓｔ
336(1): 警備員[Lv.23] (ﾜｯﾁｮｲ 1563-WQ8n) 2024/06/06(木)07:55 ID:Glzej5210(2/3) AAS
質問なのですが
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(1): (ﾌﾞｰｲﾓ MMde-FHn0) 2024/06/06(木)15:53 ID:Vp529NVwM(1) AAS
フル手書き前提がくそださい
338: (ﾜｯﾁｮｲ fe2c-7W3t) 2024/06/06(木)19:13 ID:FMMlTunO0(1) AAS
fstreamなんだったらfstreamのメンバで書くのがいいんじゃない
339: 警備員[Lv.23] (ﾜｯﾁｮｲ 1563-WQ8n) 2024/06/06(木)23:36 ID:Glzej5210(3/3) AAS
(1)は#include <ios>が要るし、
(2)は「basic_」の6文字×フラグの数 だけ長いし、
(3)も同様でありなおかつ>>337に従ったとき
use binary = std::fstream::binary;
use ibinary = std::ifstream::binary;
use obinary = std::ofstream::binary;
となってしまい、
省3
340: (ﾜｯﾁｮｲ d68d-vvKF) 2024/06/06(木)23:54 ID:7ZzCG2hU0(1) AAS
iostreamはまあしゃーない…
341: (ﾜｯﾁｮｲ a97c-3xqL) 2024/06/07(金)02:20 ID:GhXFHGen0(1) AAS
C++の悪評の4割くらいはiostreamのせいだからな
342(2): (ﾜｯﾁｮｲ a944-l7CW) 2024/06/07(金)04:24 ID:qf+nnTv50(1) AAS
ここでCmakeとNinjaについて聞くのダメ?
どーも関係がよくわからなくて?
343: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ a932-zlCG) 2024/06/07(金)05:26 ID:zM43Xr/H0(1/2) AAS
>>342
そういう雑多な話題のちょうどよいスレは見当たらんし、単発で終わる質問程度なら許容されると思うが……。
質問の内容が漠然としているなら丁寧な回答は得られないと思う。
「よくわからない」という状況になるときってのは大抵の場合に関連する前提知識が足りてないので
質問が連鎖的に発生してダラダラ続いたりするから。
344(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ a932-zlCG) 2024/06/07(金)05:36 ID:zM43Xr/H0(2/2) AAS
>>336
第四の選択肢
std::fstream ofs("foo.txt", ofs.out | ofs.binary);
345: (ﾜｯﾁｮｲ fee5-FHn0) 2024/06/07(金)13:37 ID:kav19u0f0(1) AAS
copilotで補完でok
346: (ﾜｯﾁｮｲ 6af0-AYul) 2024/06/07(金)17:07 ID:NFmVQMC40(1) AAS
バカの解決策
347: (ﾌﾞｰｲﾓ MMea-FHn0) 2024/06/07(金)21:12 ID:70o6R+hDM(1) AAS
また時代に取り残されるじじい
348: (ﾜｯﾁｮｲ 1563-WQ8n) 2024/06/07(金)21:48 ID:ORLoeNdF0(1) AAS
>>344
ofsのスコープの隙間を突きなおかつ静的メンバをドット演算子で参照する等
テクニカルですばらっし
349: (ﾜｯﾁｮｲ fee5-FHn0) 2024/06/08(土)01:03 ID:k3Jnk/Aj0(1) AAS
静的解析で文句言われる可能性あるからやめときな
頻発するならスニペット作ればいいだけ
そういう表面的なことにこだわる奴は三流
350: (ﾜｯﾁｮｲ f344-7AaF) 2024/06/09(日)04:26 ID:RJYm8+UN0(1/5) AAS
lldb v14.0.0 で正しくプロセスを実行できません
apt insrall でインストールしたもので, 環境はwsl 1 です
具体的には下のサイトのIssue Encountered:と全く同じ症状です
外部ﾘﾝｸ:stackoverflow.com
改めて書きますと Hello World 表示だけのソースを clang でコンパイルし,
lldb で読み込み run させると
Process 20784 launched: '/home/Hustler/c++/move/move' (x86_64)
省5
351: (ﾜｯﾁｮｲ f344-7AaF) 2024/06/09(日)05:11 ID:RJYm8+UN0(2/5) AAS
今やってみたのですが
lldb-14をuninstall(remove)し lldb-15をインストールしてみましたが
状況は改善しませんでした
352(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ f332-Oh5j) 2024/06/09(日)15:07 ID:bthWHIYm0(1/2) AAS
WSL1 は (ある程度) Linux 互換のシステムコールを windows 内に実装することで実現していて Linux カーネルそのものではないので色々と不足がある。
(そのかわり Windows と親和性がある部分もある。)
WSL1 で用意してない Linux の機能に依存したアプリケーションは動かない。
まともな互換性が必要ならWSL2 を使いなさいという話なので手間をかけて WSL1 を積極的にはサポートしないと思う。
353: (ﾜｯﾁｮｲ f344-7AaF) 2024/06/09(日)20:56 ID:RJYm8+UN0(3/5) AAS
>>352
wsl2 ではlldbは問題なく動いてるんですか?
古いCPUなのでwsl2がインスコできないもんで
上のサイトはwslのバージョンは書いてなかったようですし
354(1): (ﾜｯﾁｮｲ 6363-vt9G) 2024/06/09(日)21:14 ID:VES2dE5O0(1) AAS
WSLはlldbが使うシステムコールが足りてないって昔から言われていたかと
ターゲット機を別にするとかWSL2にするとかじゃね？
355(1): (ﾜｯﾁｮｲ f344-7AaF) 2024/06/09(日)21:36 ID:RJYm8+UN0(4/5) AAS
>>354
>WSLはlldbが使うシステムコールが足りてないって昔から言われていたかと
なるほどTHXです
clang使ってなかったので全然わかりませんでした
動かないlldbもさんざんggったんだけど system call未実装にはたどり着けませんでした
ようやくすっきりしました
356: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ f332-Oh5j) 2024/06/09(日)22:04 ID:bthWHIYm0(2/2) AAS
ざっとググってみた感じたと wsl1 では procfs が提供する情報が少ないのが lldb が動かない直接の原因みたいな数年前の情報は見つかる。
内部構造がまるで違うはずなのに表面的なインターフェースは互換にするなんてのは無理のある話なので互換性が「ある程度」にとどまるのは仕方ない。
357: (ﾜｯﾁｮｲ f344-7AaF) 2024/06/09(日)22:18 ID:RJYm8+UN0(5/5) AAS
んー
clangちょっと調べたかったんで
Visual Studioにclangインスコして調べますわ
できるならwslでやるのが手っ取り早いんですが
Q9550とQ9550sしか持ってないもんで
以来CPUの爆値上がりと最近の円の爆下がりで新しく組めてないんですわ
ダイサイズ変わらないのにCPU 3万ー> 10万とか購買意欲が萎える
358: (ﾌﾞｰｲﾓ MM1f-vt9G) 2024/06/10(月)18:15 ID:bkv2YMA2M(1) AAS
>>355
github のwslのissueを漁れば出て来るかと。
結論がWSL2使えだったかと
359: 350 (ﾜｯﾁｮｲ f344-7AaF) 2024/06/10(月)21:38 ID:gvR5xwnw0(1) AAS
自己レスです
その後 Visual Studioのインストールオプションでclangを選択し
正しく動作することは確認したのですが...
今や誰でもロハで使えるインテルコンパイラがとっくの昔にllvm化されてたんですね
clangに拘りがなければ x86/x64のwin/linux/wsl は素直にopenAPI使っとくのが幸せかも.
ちなみにwsl 1にlinux版をインストールしましたが
コンパイラicxもデバッガgdb-opwnapiも何の問題もなく動いてます(今のところは)
省6
360: 350 (ﾜｯﾁｮｲ f344-7AaF) 2024/06/11(火)06:20 ID:Ip4/j3Hv0(1) AAS
☓ openAPI
◯ oneAPI
361: あぼーん [あぼーん] AAS
あぼーん
362: あぼーん [あぼーん] AAS
あぼーん
363: (ﾜｯﾁｮｲ 43d7-pk1M) 2024/07/13(土)19:06 ID:Dtkl2SPB0(1) AAS
若者のBoost離れ
364: (ﾜｯﾁｮｲ 0501-twcF) 2024/07/13(土)19:56 ID:vwgbCsGD0(1) AAS
と言いますと?
365: (ﾜｯﾁｮｲ f5f9-pk1M) 2024/07/13(土)21:42 ID:Rh1MnFN10(1/2) AAS
VS17.10.xでBoostがビルドできなくなってるのに
誰も触れない
366: (ﾜｯﾁｮｲ f5f9-pk1M) 2024/07/13(土)21:47 ID:Rh1MnFN10(2/2) AAS
MSVC143から144に変わったせいでビルドできないらしいですよ
上下前次1-新書関写板覧索設栞歴
あと 636 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.211s*