[過去ﾛｸﾞ]
C++相談室 part165 (1002ﾚｽ)
C++相談室 part165 http://mevius.5ch.net/test/read.cgi/tech/1698705458/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
441: デフォルトの名無しさん (ﾜｯﾁｮｲ 277f-jESi) [sage] 2024/09/06(金) 07:27:10.33 ID:Qb4sTpDj0 >>440 それは無理があるんじゃないのかね。 データ共有とかインターフェイス共有とか本質的に所有者が複数存在するオブジェクトはsharedptr使うべきかと。 設計ではモジュール間の疎結合・インターフェイスの汎用化を重視すべきで、そのためにはデータの共有方法が重要になる。 http://mevius.5ch.net/test/read.cgi/tech/1698705458/441
442: デフォルトの名無しさん (ﾌﾞｰｲﾓ MM7f-5+wm) [sage] 2024/09/06(金) 11:54:45.03 ID:onD85wsiM >>440 マルチスレッドセーフ考えたら使わざるを得ない場合は多々ある 言ってる意味がわからないならお前は経験不足 http://mevius.5ch.net/test/read.cgi/tech/1698705458/442
443: デフォルトの名無しさん (ﾜｯﾁｮｲ e7df-UdSI) [] 2024/09/06(金) 22:35:55.77 ID:0hxwMUxG0 recurcive_mutexが欲しくなったら設計を見直したい、なら分かる気もする http://mevius.5ch.net/test/read.cgi/tech/1698705458/443
444: デフォルトの名無しさん (ﾜｯﾁｮｲ 0753-60ma) [sage] 2024/09/07(土) 11:45:08.02 ID:Zy1zUumM0 C++11あたりから「生ポは使うな」みたいな極論で分かった気になってる思い上がった初心者が増えたからなぁ http://mevius.5ch.net/test/read.cgi/tech/1698705458/444
445: デフォルトの名無しさん (ﾜｯﾁｮｲ bfac-jESi) [sage] 2024/09/07(土) 11:58:09.00 ID:UFsx2JaR0 >>444 生ポ使うよりかスマートポインタの参照を使った方がマシだったりするからなぁ。スマートポインタがスタックフレームにあるなら安全だし。 スタック変数専用仮引数とかあればもっと安全になるのになぁ。 仮引数の種類はもっとあっていいと思う。 http://mevius.5ch.net/test/read.cgi/tech/1698705458/445
446: デフォルトの名無しさん (ﾜｯﾁｮｲ 27ea-60ma) [sage] 2024/09/07(土) 16:26:14.57 ID:lSV8lU690 >>445 考え方にもよるだろうけど、確保も解放も所有もしない関数でスマポ受け取る必要あるか？ 特定の用途で管理されている特定のポインタしか許容しない、という意図ならスマポの参照でもいいだろうけど、汎用性は無いよね 生ポ受け取る場合暗黙のキャストも効かないし http://mevius.5ch.net/test/read.cgi/tech/1698705458/446
447: デフォルトの名無しさん (ﾜｯﾁｮｲ 8763-0xUn) [sage] 2024/09/07(土) 20:17:38.39 ID:Ci+xhqlU0 >>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(); ... }; http://mevius.5ch.net/test/read.cgi/tech/1698705458/447
448: デフォルトの名無しさん (ﾜｯﾁｮｲ 8763-0xUn) [sage] 2024/09/07(土) 20:21:44.33 ID:Ci+xhqlU0 んまー前方宣言が必須というのは言い杉やったかもしれんorz TreeNodeみたいなクラスはノード毎にヒープを確保するなんてことはやめて専用のアロケーターを設けて 専用の領域をまとめて確保して、 木全体がいらなくなったら木をトラバースすることなく一気に解放するのが本当やが その場合m_pLeftやm_pRightにあたるのはポインタではなくて専用の領域（配列）のindexとかにすれば 前方宣言は不要、 http://mevius.5ch.net/test/read.cgi/tech/1698705458/448
449: デフォルトの名無しさん (ﾜｯﾁｮｲ 27ea-60ma) [sage] 2024/09/07(土) 21:38:34.24 ID:lSV8lU690 >>442 使わざるを得ないは言い過ぎじゃね 同期取るのにshared_ptrのアトミック保証に依存するしか方法が無いの？ 競技プログラマか何かか？ http://mevius.5ch.net/test/read.cgi/tech/1698705458/449
450: デフォルトの名無しさん (ﾜｯﾁｮｲ 069a-KwgP) [sage] 2024/09/08(日) 00:33:39.65 ID:vgBqrjWA0 shared_ptrの内部的な参照カウンタとかはともかく 保持しているオブジェクト自体はアトミックでもなんでもないでしょ ってなんか勘違いしてる? http://mevius.5ch.net/test/read.cgi/tech/1698705458/450
451: デフォルトの名無しさん (ﾜｯﾁｮｲ 91ea-IbtD) [sage] 2024/09/08(日) 01:27:17.93 ID:6Lpw1aoe0 持ってるポインタの指す先のオブジェクトがアトミックになるとか言ってると思ってんの？アホかw http://mevius.5ch.net/test/read.cgi/tech/1698705458/451
452: デフォルトの名無しさん (ﾜｯﾁｮｲ b501-I4rH) [sage] 2024/09/08(日) 01:32:50.82 ID:TMvzCbR60 そこでRustですよ！ http://mevius.5ch.net/test/read.cgi/tech/1698705458/452
453: デフォルトの名無しさん (ﾜｯﾁｮｲ eaf0-8qrK) [] 2024/09/08(日) 12:52:42.06 ID:Lw7YNDXG0 でたｗ 布教ﾏｿw http://mevius.5ch.net/test/read.cgi/tech/1698705458/453
454: デフォルトの名無しさん (ﾌﾞｰｲﾓ MM0a-bJfQ) [sage] 2024/09/10(火) 11:29:59.05 ID:v6KS9t6sM >>447 お前の理解はshared_ptrの一面だけだな ようするにunique_ptrの延長でしか見てない shared_ptrがどうしても欲しくなるのは オブジェクトのリリースタイミングが非決定的であるとき これは一般的にマルチスレッド環境 お前のTreeNodeの例はそれこそ生ポで実装しても対して苦労しないが 例えば動的可変multi producerなqueueの場合確実に安全なqueueの解放タイミングを知るにはリファレンスカウントのような制御が必要となる 当然この場合コピーすれば安全なんて寝ぼけたことにはならない http://mevius.5ch.net/test/read.cgi/tech/1698705458/454
455: デフォルトの名無しさん (ｱｳｱｳｴｰ Sa52-t/33) [] 2024/09/10(火) 13:20:49.36 ID:KGjTz1X0a x 対して http://mevius.5ch.net/test/read.cgi/tech/1698705458/455
456: デフォルトの名無しさん (ﾜｯﾁｮｲ 8a48-/VPw) [sage] 2024/09/10(火) 15:36:50.97 ID:+l9ylb2n0 それで自己参照ってのは結局何のことを指して言っていたんだい http://mevius.5ch.net/test/read.cgi/tech/1698705458/456
457: デフォルトの名無しさん (ﾜｯﾁｮｲ 8a48-/VPw) [sage] 2024/09/10(火) 15:39:03.70 ID:+l9ylb2n0 あ、相互参照が先か >>435>>436の言うところの http://mevius.5ch.net/test/read.cgi/tech/1698705458/457
458: デフォルトの名無しさん (ﾜｯﾁｮｲ 1ede-2PHd) [] 2024/09/11(水) 12:14:54.12 ID:n6/LwjNL0 (*this) ↑ 自己参照 http://mevius.5ch.net/test/read.cgi/tech/1698705458/458
459: デフォルトの名無しさん (ﾜｯﾁｮｲ 1ede-2PHd) [] 2024/09/11(水) 12:19:01.05 ID:n6/LwjNL0 木のノードはstd::vector<>で確保する と言われて、だよねってなる人はnewもほとんど必要ない http://mevius.5ch.net/test/read.cgi/tech/1698705458/459
460: デフォルトの名無しさん (ﾜｯﾁｮｲ 1ede-2PHd) [] 2024/09/11(水) 12:22:29.60 ID:n6/LwjNL0 木の巡回は、巡回方向別にアダプタとしてイテレータを用意することが出来る 良くある行きがかり順のイテレータはスタックを使って作る http://mevius.5ch.net/test/read.cgi/tech/1698705458/460
461: デフォルトの名無しさん (ﾌﾞｰｲﾓ MM45-bJfQ) [sage] 2024/09/11(水) 15:12:04.16 ID:1n/VD1trM でvectorの拡張で破綻すんだろ？ http://mevius.5ch.net/test/read.cgi/tech/1698705458/461
462: デフォルトの名無しさん (ｱｳｱｳｴｰ Sa52-t/33) [] 2024/09/13(金) 16:29:50.66 ID:bblj+c3pa move禁止 http://mevius.5ch.net/test/read.cgi/tech/1698705458/462
463: デフォルトの名無しさん (ﾜｯﾁｮｲ 5ef4-bJfQ) [sage] 2024/09/13(金) 19:59:43.80 ID:2C9M8qgO0 move禁止したらvector使えないし http://mevius.5ch.net/test/read.cgi/tech/1698705458/463
464: デフォルトの名無しさん (ｱｳｱｳｴｰ Sadf-N1Zj) [sage] 2024/09/17(火) 12:59:42.12 ID:TMGdiCOOa それならオブジェクトを保持するためのオブジェクトと moveためだけのインデックスを分けるかな http://mevius.5ch.net/test/read.cgi/tech/1698705458/464
465: デフォルトの名無しさん (ﾜｯﾁｮｲ bf84-GITO) [sage] 2024/09/17(火) 16:24:30.60 ID:DN+X/Cyr0 何がしたい あほでしょ http://mevius.5ch.net/test/read.cgi/tech/1698705458/465
466: 447 (ﾜｯﾁｮｲ d763-HdVQ) [sage] 2024/09/21(土) 20:05:42.93 ID:FUSKAHoo0 何やら集中砲火を浴びている>>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する（←これは排他が要る http://mevius.5ch.net/test/read.cgi/tech/1698705458/466
467: 447 (ﾜｯﾁｮｲ d763-HdVQ) [sage] 2024/09/21(土) 20:13:25.63 ID:FUSKAHoo0 ていうか2週間ぐらい前から作っていたやつが今さっき完動すた、 http://mevius.5ch.net/test/read.cgi/tech/1698705458/467
468: デフォルトの名無しさん (ﾜｯﾁｮｲ d763-HdVQ) [sage] 2024/09/21(土) 20:35:47.52 ID:FUSKAHoo0 std::vector<TreeNode> nodes; ならnodesを拡張したとき破綻するかもしれんが（nodeをnodesのindexで管理するならその限りではない std::vector<std::shared_ptr<TreeNode> > apNodes; ならapNodesを拡張しても破綻しないYO!（要素の実アドレスは保たれる http://mevius.5ch.net/test/read.cgi/tech/1698705458/468
469: デフォルトの名無しさん (ﾜｯﾁｮｲ e37c-C1Jv) [sage] 2024/09/22(日) 08:21:05.99 ID:e5FZYjui0 それ何のためのshared_ptrなの？unique_ptrでいいというか横からコピーされないようにそうすべきでは http://mevius.5ch.net/test/read.cgi/tech/1698705458/469
470: デフォルトの名無しさん (ﾜｯﾁｮｲ 1e52-VArp) [sage] 2024/09/25(水) 13:57:54.93 ID:N5yN4IuU0 >>466 >>442 を書いたのおれだけど、なんでおれが集中砲火浴びてることになってんだよ 生ポとか意味不明なこといってる>>447は一見してわかるクソレスだろ おまえはそれ以上のクソレスにクソコード でもお前の勝ちだ クソコードに2週間かけた情熱に免じて親切におしえてやるわ shared_ptrはpに誰かがアクセスしている可能性がある間は決してdeleteされないことを保証できるのが肝 (pの先の排他ではこれは実現できない) もちろんこれも正しく使わないと保証できない よくあるミスは知ったかぶって参照カウントを操作しないようにshared_ptrを参照渡しとかにするやつな その間に絶対deleteされない保証がないならやってはいけない http://mevius.5ch.net/test/read.cgi/tech/1698705458/470
471: デフォルトの名無しさん (ﾜｯﾁｮｲ cb41-LUcV) [sage] 2024/09/26(木) 03:21:09.01 ID:5BtHXQaO0 あーなるほど、一貫してshared_ptrの実体を渡してればそういう保証も出来るのか 自分の場合自前で排他処理や生存保証作ってたけど確かに大きなメリットだね (オブジェクト内部の排他は別に必要だとしても) http://mevius.5ch.net/test/read.cgi/tech/1698705458/471
472: デフォルトの名無しさん (ｱｳｱｳｴｰ Saaa-rNKn) [] 2024/09/26(木) 10:52:52.31 ID:R5lWYvWFa そんなあなたにRust http://mevius.5ch.net/test/read.cgi/tech/1698705458/472
473: デフォルトの名無しさん (ﾜｯﾁｮｲ 3224-jZWQ) [sage] 2024/09/26(木) 11:26:35.22 ID:r0pzUHiv0 >>472 c++コードと混在できるようになってからの話だな。 既存c++を捨てなきゃならんのなら要らん。 http://mevius.5ch.net/test/read.cgi/tech/1698705458/473
474: デフォルトの名無しさん (ｱｳｱｳｴｰ Saaa-rNKn) [] 2024/09/26(木) 11:37:49.48 ID:R5lWYvWFa もちろんRustをやるにはC++を捨てる覚悟が必要 C++コード(特にテンプレやclass)とは相性最悪 http://mevius.5ch.net/test/read.cgi/tech/1698705458/474
475: デフォルトの名無しさん (ｱｳｱｳｴｰ Saaa-rNKn) [] 2024/09/26(木) 11:38:22.04 ID:R5lWYvWFa >c++コードと混在できるようになって Rustについて言うなら おそらくそんな未来は永久に来ない http://mevius.5ch.net/test/read.cgi/tech/1698705458/475
476: デフォルトの名無しさん (ｱｳｱｳｴｰ Saaa-rNKn) [] 2024/09/26(木) 11:39:08.38 ID:R5lWYvWFa 誤解の無いように言っておくと (一部機能に限れば今でも混在出来るけど) 基本的にはC++とは相いれない http://mevius.5ch.net/test/read.cgi/tech/1698705458/476
477: デフォルトの名無しさん (ﾜｯﾁｮｲ 77da-jZWQ) [sage] 2024/09/26(木) 18:22:32.63 ID:sl+cfKHN0 ならc++にRustの機能が取り込まれるのを待つ。 Rustが大人気になったら、さすがに標準委員の連中も初心者・コーダー向けの"Safe c++"をやる気になるだろ。 http://mevius.5ch.net/test/read.cgi/tech/1698705458/477
478: はちみつ餃子 ◆8X2XSCHEME (ﾜｯﾁｮｲ e332-Pvcq) [sage] 2024/09/26(木) 18:52:53.17 ID:B+Au+yIB0 >>477 もう Rust を使えばよくない……？ http://mevius.5ch.net/test/read.cgi/tech/1698705458/478
479: デフォルトの名無しさん (ﾜｯﾁｮｲ 77da-jZWQ) [sage] 2024/09/26(木) 19:43:24.82 ID:sl+cfKHN0 >>478 >>473だっつうの。 Kotlinみたいなのが欲しいのであって、Clojureみたいなのは要らん。 http://mevius.5ch.net/test/read.cgi/tech/1698705458/479
480: はちみつ餃子 ◆8X2XSCHEME (ﾜｯﾁｮｲ e332-Pvcq) [sage] 2024/09/26(木) 20:25:47.69 ID:B+Au+yIB0 >>165 C++ のコードを Rust から呼び出したりするくらいのことは簡単に出来るよ。 たぶん (Java に対する) Kotlin みたいなこととして思い浮かべているようなことは出来る。 Rust がやってるような安全性の保障を自動では受けられない。 当然だが安全ではない (安全性が検証されていない) C++ のコードが Rust から呼び出すことで安全になったりはしない。 大抵の場合に Rust の都合に合わせてラッパーを書くことになる。 http://mevius.5ch.net/test/read.cgi/tech/1698705458/480
481: デフォルトの名無しさん (ﾜｯﾁｮｲ e39c-jZWQ) [sage] 2024/09/27(金) 10:23:27.00 ID:n6BA5joS0 >>480 KotlinとJavaみたいにソースコードを混在できるレベルの相互運用性てあったっけ？ Rustとc++では無理だと思うけど。 http://mevius.5ch.net/test/read.cgi/tech/1698705458/481
482: デフォルトの名無しさん (ﾌﾞｰｲﾓ MMe3-VArp) [sage] 2024/09/27(金) 10:44:00.51 ID:02Aq/BhWM cxxとかあるけど個人的には中途半端だから使わない 普通に共有ライブラリにして呼び出す方が素直で汎用的で良い http://mevius.5ch.net/test/read.cgi/tech/1698705458/482
483: デフォルトの名無しさん (ﾜｯﾁｮｲ 5e79-w5sm) [] 2024/09/27(金) 12:33:43.81 ID:6/1p1gGO0 スマートポインターを使うように強制できる機能とかなら必要ないなあ http://mevius.5ch.net/test/read.cgi/tech/1698705458/483
484: デフォルトの名無しさん (ｱｳｱｳｴｰ Saaa-rNKn) [] 2024/09/27(金) 16:51:52.33 ID:pgg/4VuRa >>473 のような未来は永遠に来ない http://mevius.5ch.net/test/read.cgi/tech/1698705458/484
485: デフォルトの名無しさん (ｱｳｱｳｴｰ Saaa-rNKn) [] 2024/09/27(金) 16:54:13.57 ID:pgg/4VuRa >>482 結局Cが正解なんよ C++のスレで言うのもなんだけど http://mevius.5ch.net/test/read.cgi/tech/1698705458/485
486: デフォルトの名無しさん (ｱｳｱｳｴｰ Saaa-rNKn) [] 2024/09/27(金) 16:54:31.95 ID:pgg/4VuRa >>481 同意 http://mevius.5ch.net/test/read.cgi/tech/1698705458/486
487: デフォルトの名無しさん (ｱｳｱｳｴｰ Saaa-rNKn) [] 2024/09/27(金) 16:54:58.40 ID:pgg/4VuRa >>480 嘘つくな 出鱈目言うな http://mevius.5ch.net/test/read.cgi/tech/1698705458/487
488: デフォルトの名無しさん (ﾜｯﾁｮｲ e39c-jZWQ) [sage] 2024/09/27(金) 17:14:28.28 ID:n6BA5joS0 >>483 コーダー向けので考えるなら、スマポ強制は最優先だろ。 生ポインタを(コーダーが)保存できなくするだけでも随分安全になる。あと生ポインタdelete禁止とか。 http://mevius.5ch.net/test/read.cgi/tech/1698705458/488
489: デフォルトの名無しさん (ﾜｯﾁｮｲ 728c-rNKn) [sage] 2024/09/27(金) 18:24:18.27 ID:dg7IL8lg0 極限のパフォーマンスは別に要らないから安全にしたいという要件なら GC が既に解決しているし 今更生ポインタを禁止したところで C# や Java と同じ方向性のナニカにしかならんじゃろ http://mevius.5ch.net/test/read.cgi/tech/1698705458/489
490: デフォルトの名無しさん (ﾜｯﾁｮｲ 1e02-VArp) [sage] 2024/09/27(金) 18:46:28.46 ID:EoeiRCVP0 gcがあったらメモリリークしないなんて幻想未だに信じてるとはね http://mevius.5ch.net/test/read.cgi/tech/1698705458/490
491: デフォルトの名無しさん (ﾜｯﾁｮｲ a778-KU+G) [sage] 2024/09/27(金) 18:59:34.32 ID:RwmUzOsi0 リークの話なの？ http://mevius.5ch.net/test/read.cgi/tech/1698705458/491
492: デフォルトの名無しさん (ﾜｯﾁｮｲ e39c-jZWQ) [sage] 2024/09/27(金) 19:07:06.62 ID:n6BA5joS0 >>489 ライブラリとかフレームワークを使う側のコーダーと作る側のライブラリアンは性能要件が全然別。 コーダーに対してライブラリアンが「コーダーのコードに極限のパフォーマンスは別に要らないから安全に「させたい」」というのはあるだろ。 http://mevius.5ch.net/test/read.cgi/tech/1698705458/492
493: デフォルトの名無しさん (ﾜｯﾁｮｲ cb9e-LUcV) [sage] 2024/09/27(金) 23:12:04.55 ID:cfj6fT7K0 >>492 それならライブラリ側でメモリ周りを隠蔽するような作り方も出来ると思うけど ユーザー(コーダー)にはインスタンス使わせるけど内部では参照カウントなりスマポなり使ってるみたいな それですら問題が起きるようならユーザーがクソ http://mevius.5ch.net/test/read.cgi/tech/1698705458/493
494: デフォルトの名無しさん (ﾜｯﾁｮｲ e37c-C1Jv) [sage] 2024/09/28(土) 10:42:06.28 ID:swed/tX60 C++はどんな安全策敷いてもユーザー側がその気になればいくらでもぶち壊せるからね ライブラリがあんまりそこ頑張っても仕方ない http://mevius.5ch.net/test/read.cgi/tech/1698705458/494
495: デフォルトの名無しさん (ｱｳｱｳｴｰ Saaa-rNKn) [] 2024/09/28(土) 12:39:39.83 ID:gf2/NL3ha Rustなら壊れないみたいな言い草だな http://mevius.5ch.net/test/read.cgi/tech/1698705458/495
496: デフォルトの名無しさん (ﾜｯﾁｮｲ 77ba-vp5J) [] 2024/09/28(土) 13:06:22.71 ID:ZP4SxDa50 C++で書かれたChrome V8エンジンをRustから扱えるRusty V8というライブラリがリリースされたというニュースを見た メモリ安全性を確保して呼び出しオーバーヘッドもゼロなんだって ほんとかな？ ただのラッパーじゃないの？ C++側でメモリアクセス違反があれば落ちそうだけど http://mevius.5ch.net/test/read.cgi/tech/1698705458/496
497: デフォルトの名無しさん (ﾌﾞｰｲﾓ MMde-7TYI) [sage] 2024/09/28(土) 14:26:57.72 ID:yW35cSECM その手の話はMICROSOFTの新機能ぐらいい思っておけば 腹も立たない http://mevius.5ch.net/test/read.cgi/tech/1698705458/497
498: はちみつ餃子 ◆8X2XSCHEME (ﾜｯﾁｮｲ b332-XD+R) [sage] 2024/09/30(月) 22:26:30.09 ID:JxqgGnHQ0 >>496 Rust の標準ライブラリだって内部は unsafe だらけだぞ。 unsafe は Rust のメモリ安全性検査の例外とする指定で、検査はされないが安全であることはプログラマが保証しないといけない。 ただ、 unsafe な部分を慎重に押し込めて (押し込めるのが正しく出来ていれば) あとは Rust のメモリ安全性検査に頼ることが出来る。 ずっと気を付けなきゃならない C++ よりは面倒ごとを基盤に押し込めたら後は機械が検査してくれるほうがマシという程度の話。 押し込めた中に問題があればそりゃ当然駄目だよ。 http://mevius.5ch.net/test/read.cgi/tech/1698705458/498
499: デフォルトの名無しさん (ﾜｯﾁｮｲ 6f79-uMZa) [sage] 2024/10/01(火) 02:05:59.60 ID:J7GPtKrz0 V8エンジンてCVE脆弱性で毎月アップデートの口実にされる迷惑なやつだからさっさとRustで書き直せよ http://mevius.5ch.net/test/read.cgi/tech/1698705458/499
500: デフォルトの名無しさん (ｵｲｺﾗﾐﾈｵ MMa7-Pc8v) [] 2024/10/01(火) 15:19:57.32 ID:KXGxeTHwM >>498 >押し込めた中に問題があればそりゃ当然駄目だよ。 当然分かっているだろうが、unsafeの中だけでなく、 それが外側に及ぼす影響にも問題が生じないように作らなければなら ないが、それにはunsafeとRustの両方に対する深い理解が 必要となるだろうな。 http://mevius.5ch.net/test/read.cgi/tech/1698705458/500
501: デフォルトの名無しさん (ｵｲｺﾗﾐﾈｵ MMa7-Pc8v) [sage] 2024/10/01(火) 18:36:21.46 ID:al1nAqGBM >>500 unsafeの中を通過する時には問題ないが、 戻り値などや、連携する他のメソッドなどが 関係した結果、どこかで分かりにくいメモリーエラー になるようなことも避ける必要が有るが、 それにはかなりRustの内部構造(?)に対する深い知識 と理解が必要となりそうだ。 http://mevius.5ch.net/test/read.cgi/tech/1698705458/501
502: デフォルトの名無しさん (ﾜｯﾁｮｲ 1fb1-/QnX) [sage] 2024/10/17(木) 11:01:19.65 ID:P7X9/HPx0 >>422 これ、static_assertだけ修正してもしょうがない気がするんだけどなぁ 他にも実体化しないはずの分岐でチェックされてエラーにされることあるし まぁ条件式に無理矢理テンプレート入れて回避は出来るけど http://mevius.5ch.net/test/read.cgi/tech/1698705458/502
503: デフォルトの名無しさん (ﾜｯﾁｮｲ 2b63-4umj) [sage] 2024/10/19(土) 17:30:35.94 ID:vb3IsOJN0 >>491 Rustのオブジェクトの所有権管理の強制はコンパイラに従う限りリークしない （病的な反例があるかどうかは知らん からリークの話ではないが、GC付き言語で解決という香具師が現れたから http://mevius.5ch.net/test/read.cgi/tech/1698705458/503
504: デフォルトの名無しさん (ﾜｯﾁｮｲ 2b63-4umj) [sage] 2024/10/19(土) 17:31:10.99 ID:vb3IsOJN0 >>490な発言になったんじゃないの 知らんけど http://mevius.5ch.net/test/read.cgi/tech/1698705458/504
505: デフォルトの名無しさん (ﾜｯﾁｮｲ 8593-t4Y2) [sage] 2024/10/21(月) 07:19:50.64 ID:ThoL8xQh0 >>503 RustはRcの循環参照解決できたの？ 公式ソースある？ http://mevius.5ch.net/test/read.cgi/tech/1698705458/505
506: デフォルトの名無しさん (ﾜｯﾁｮｲ 1907-zDHq) [sage] 2024/10/21(月) 14:54:46.51 ID:WHCxApN50 C++派だが、Rustをもってしても、相互参照みたいなものは、人類には早いらしい (設計段階で)無理しないこったな。。 http://mevius.5ch.net/test/read.cgi/tech/1698705458/506
507: デフォルトの名無しさん (ﾜｯﾁｮｲ c60f-zhf3) [sage] 2024/10/21(月) 15:57:11.21 ID:Hhc6wfX80 そもそも静的解析で解決できる問題か？ http://mevius.5ch.net/test/read.cgi/tech/1698705458/507
508: はちみつ餃子 ◆8X2XSCHEME (ﾜｯﾁｮｲ 0d32-zDHq) [sage] 2024/10/21(月) 16:03:29.88 ID:6JU3cZPt0 循環参照をしたいときに出来ないのも困るしな。 なるべくやらないに越したことはないが、やるなら後始末は人が考えないと仕方ないわ。 http://mevius.5ch.net/test/read.cgi/tech/1698705458/508
509: デフォルトの名無しさん (ﾜｯﾁｮｲ e963-f5bJ) [sage] 2024/10/21(月) 22:48:14.20 ID:XvJERuqr0 食事する哲学者の問題…… Rustだと循環参照するコードを書きにくくなっているから 循環参照によるリークとか病的な反例のうちなんじゃないの 知らんけど ノードNode同士が論理的には循環参照し得るんだけど その所有権をスーパーバイザ的な配列superArray: Node[]が持っていて、 http://mevius.5ch.net/test/read.cgi/tech/1698705458/509
510: デフォルトの名無しさん (ﾜｯﾁｮｲ e963-f5bJ) [sage] 2024/10/21(月) 22:53:33.76 ID:XvJERuqr0 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はどんな魔法を使ってくれる のか http://mevius.5ch.net/test/read.cgi/tech/1698705458/510
511: はちみつ餃子 ◆8X2XSCHEME (ﾜｯﾁｮｲ 0d32-zDHq) [sage] 2024/10/22(火) 11:28:00.82 ID:UXnTPhGj0 >>510 Rust では実行時にチェックされて範囲から外れていたら panic (C/C++ で言うところの abort みたいなもの) する。 https://doc.rust-lang.org/std/ops/trait.Index.html#tymethod.index C/C++ のように配列がポインタになるということはなく、スライス (C++ で言うところの span みたいなもの) が基本型として組み込まれているので範囲チェック出来る。 コンパイル時に範囲内であることがわかる状況なら最適化で消えることもあるみたいだけど 実行時に外部から入ってくる値に依存することもあるので実行時にチェックしないとどうしようもない。 http://mevius.5ch.net/test/read.cgi/tech/1698705458/511
512: デフォルトの名無しさん (ﾜｯﾁｮｲ 8901-1CwD) [sage] 2024/10/28(月) 13:44:32.71 ID:A9ortPvu0 enum、 文字列への変換、 大変すぎて、ビックリした http://mevius.5ch.net/test/read.cgi/tech/1698705458/512
513: デフォルトの名無しさん (ﾜｯﾁｮｲ 1901-2Yr6) [sage] 2024/10/28(月) 14:06:10.17 ID:/lht/Ba/0 俺はenumの機能を拡張するクラスを自分で定義してるな それで文字列変換も文字列からの変換も出来る http://mevius.5ch.net/test/read.cgi/tech/1698705458/513
514: デフォルトの名無しさん (ﾜｯﾁｮｲ 4907-+Yhf) [sage] 2024/10/28(月) 15:41:01.09 ID:xcgYWtNU0 autogenerated.txt.c みたいなの使うのも手だぞ 急がば回れ そしてCよりはうまく書ける http://mevius.5ch.net/test/read.cgi/tech/1698705458/514
515: デフォルトの名無しさん (ﾜｯﾁｮｲ 8901-1CwD) [sage] 2024/10/29(火) 08:22:28.04 ID:XRXAB2XQ0 >>514 うーん、どんなもの？それ http://mevius.5ch.net/test/read.cgi/tech/1698705458/515
516: デフォルトの名無しさん (ﾜｯﾁｮｲ 4907-+Yhf) [sage] 2024/10/29(火) 13:58:12.41 ID:WYOK+g300 好きなように書いて、好きなように変換して、途中でincludeする 簡単に書くもよし、ガッチガチにチェックするもよし http://mevius.5ch.net/test/read.cgi/tech/1698705458/516
517: デフォルトの名無しさん (ﾜｯﾁｮｲ fb79-fQm0) [sage] 2024/10/30(水) 23:11:10.17 ID:x0G86HEF0 HAGE(CAUWA1) HAGE(CAUWA2) HAGE(CAUWA3) ： みたいなテキスト作っといて 手コキストを#includeする手前でHAGEの意味を変えてやるとうまいこと一元化できる http://mevius.5ch.net/test/read.cgi/tech/1698705458/517
518: 警備員[Lv.44] (ﾜｯﾁｮｲ 89c3-YFB5) [sage] 2024/10/31(木) 00:43:29.18 ID:ET2RcGMR0 ｶｳﾜ? http://mevius.5ch.net/test/read.cgi/tech/1698705458/518
519: デフォルトの名無しさん (ﾜｯﾁｮｲ 7b4d-XqAs) [sage] 2024/10/31(木) 01:08:33.55 ID:gisW4Gdb0 magic_enum教えてやれや じじいは感度低いから知らんか http://mevius.5ch.net/test/read.cgi/tech/1698705458/519
520: デフォルトの名無しさん (ﾜｯﾁｮｲ 4907-+Yhf) [sage] 2024/10/31(木) 05:43:35.79 ID:J4xtBqBy0 みてきた それが人気の実装か やりたいこと次第だが、オーバスペック感はある ちょうどほしかったんなら止めないけどね http://mevius.5ch.net/test/read.cgi/tech/1698705458/520
521: デフォルトの名無しさん (ﾜｯﾁｮｲ 1901-2Yr6) [sage] 2024/10/31(木) 10:56:16.92 ID:++2hP8JV0 横からなるほどー！ __PRETTY_FUNCTION__ / __FUNCSIG__ http://mevius.5ch.net/test/read.cgi/tech/1698705458/521
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 481 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.029s