C vs C++ vs Rust Part.3

1 名前：デフォルトの名無しさん mailto:sage [2022/01/27(木) 22:19:47.56 ID:avZQ9Wm7.net] 闘え ※前スレ C++ vs Rust https://mevius.5ch.net/test/read.cgi/tech/1619219089/ C vs C++ vs Rust Part.2 https://mevius.5ch.net/test/read.cgi/tech/1639539350/ 830 名前：デフォルトの名無しさん mailto:sage [2022/03/29(火) 14:16:16.84 ID:CtwsyWiP.net] 例えば C$の $"X = {X}" に慣れてしまうと cerr,coutあたりの "x = " << x とか邪魔臭すぎるだろ null合体演算子にしてもそう。これがあるかないかで生産性大違い 恐らくすぐにでも実装出来そうな機能が未だに実装されてない。 async/awaitでもC++20でようやく正式サポートだっけ どこ見て標準規格きめてんの? CユーザがC++知ってしまうとPure Cで書くのがいやになるように C++ユーザがC#知ってしまうともうC++で書くのがめんどくさくてかなわんのよな 831 名前：デフォルトの名無しさん mailto:sage [2022/03/29(火) 15:10:25.26 ID:s791HQmS.net] >>816 ねぼけてるのは君のほうだと思うぞ あ、ねぼけてるわけじゃなくてただ知らないだけか 832 名前：デフォルトの名無しさん mailto:sage [2022/03/29(火) 15:59:34.10 ID:ffas ] [ここ壊れてます] 833 名前：CIjO.net mailto: そもそもusingと > 例外処理のデフォルト処理のことを言ってるんだが になんの関係があるんだ？ [] [ここ壊れてます] 834 名前：デフォルトの名無しさん mailto:sage [2022/03/29(火) 16:42:51.37 ID:sOLohvn0.net] usingでインスタンス生成すると、スコープアウトされたときにDisposeメソッドを呼び出すことが保証される C#にはRAIIがないから try/finally とかで解放処理を書く必要があったりしてそのtry構文はクソ面倒だけど、usingを使うとお手軽に書ける まあRAIIがあればそもそもこんなの不要かな 835 名前：デフォルトの名無しさん mailto:sage [2022/03/29(火) 17:03:56.94 ID:1RqC5Y4R.net] RAIIはGC使わない言語用だからな 836 名前：デフォルトの名無しさん mailto:sage [2022/03/29(火) 17:07:15.66 ID:7ru2bWxl.net] RAIIほどポンコツな名前が長く使われてるケースも珍しいよね 自浄作用とかないのかな 837 名前：デフォルトの名無しさん mailto:sage [2022/03/29(火) 17:16:42.76 ID:QRpFWUID.net] C#にもlock statementみたいにRAII的なものもある 838 名前：デフォルトの名無しさん mailto:sage [2022/03/29(火) 17:59:34.97 ID:bjKur886.net] むしろC++がもたらしたものの中で 一番冴えてるのがRAIIだと思うけど 839 名前：デフォルトの名無しさん mailto:sage [2022/03/29(火) 18:09:07.22 ID:wvo3NcdM.net] そういえばCにdeferが入るかもって話はどうなったんだ？ 840 名前：デフォルトの名無しさん mailto:sage [2022/03/29(火) 19:17:05.07 ID:tpB/JA+o.net] >>816 たぶん using(var sw=new StreamWriter("a.txt")){ sw.WriteLine("test"); } のこと言ってるんだろうけど 例外処理のデフォルトってfinallyのことだよな？ finallyで処理するのは例外の時だけじゃないぞ return/continue/break/throwでusingブロックを抜けるときにIDisposable.Dispose()を実行するための構文だぞ 841 名前：デフォルトの名無しさん mailto:sage [2022/03/29(火) 19:52:33.02 ID:AEoeDiSF.net] >>821 C#: usingでインスタンス生成すると、スコープアウトされたときにDisposeメソッドを呼び出すことが保証される C++: スコープ内で定義すると、スコープアウトされたときにデストラクタを呼び出すことが保証される まさか知らないの？ 842 名前：デフォルトの名無しさん mailto:sage [2022/03/29(火) 20:32:11.38 ID:/9JyHlX1.net] >>822 GCは関係ないな 843 名前：デフォルトの名無しさん mailto:sage [2022/03/29(火) 22:21:27.32 ID:HLabfOkH.net] スコープ抜けた時の動作するって代物ならやっぱdeferのが明示的で使いやすいってのがcにも入った理由だろうな。 844 名前：デフォルトの名無しさん mailto:sage [2022/03/29(火) 22:40:18.50 ID:zunmlMTL.net] deferって実際に入ったの？ 提案されただけでなく？ 書き方が楽なのはC#で間違いない リソースリーク対策でC#のusingみたいな構文を渋々突っ込んだgc言語は多数 RAIIって別にそんな重要なキーワードじゃなく、名前はないけど昔からあった考え方で、Windows3.1時代でも皆普通に使ってた 845 名前：デフォルトの名無しさん mailto:sage [2022/03/29(火) 22:56:21.68 ID:UoyzmKMm.net] >>830 使いやすいかなぁ 自由度は高いけどその分間違えやすい気がする 846 名前：デフォルトの名無しさん mailto:sage [2022/03/29(火) 23:05:49.29 ID:/9JyHlX1.net] >リソースリーク対策でC#のusingみたいな構文を渋々突っ込んだgc言語は多数 C#のusingとpythonのwithと、あと有名どころだと何があったっけか 847 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 06:51:40.79 ID:ES6j8MQa.net] >>827 finallyみたいなもんを用意せずに済むことを言ってるのに じゃ、君のあげたコイツ using(var sw=new StreamWriter("a.txt")){ sw.WriteLine("test"); } 同じようにC++でこれぐらい簡単に書けるというなら書いて見せてくれ 俺は>>616で同様の処理をC++で書けないとは一言もいってない。 生産性たかく、簡単に書ける手法が用意されてないことを言ってる。 usingだけ食いついてるが ・$"X = {X}" ・null合体演算子 は?C++でどー書けるのか是非知りたいから教えてくれよ 848 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 07:54:45.46 ID:ES6j8MQa.net] ? 俺は>>616で同様の処理 〇 俺は>>816で同様の処理 849 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 07:56:10.67 ID:ES6j8MQa.net] バツが機種依存やったな X　俺は>>616で同様の処理 〇 俺は>>816で同様の処理 850 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 08:14:44.56 ID:MqQwCbKz.net] >>834 そのusingブロックを抜けるときに自動でDispose()が呼ばれるという話なら、 C++だとデストラクタでやるってのが>>814が言っていることかと。 usingより簡単だし例外でも問題なし。 851 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 08:18:15.81 ID:qdlu4xZp.net] >>834 横だけど、std::ostreamてRAII使えなかったっけ？ コードは適当。 if (std::ofstream sw(filename)) { sw << "test" << '\n'; } else { std::cerr << "unable to open '" << filename << "'\n"; } 852 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 08:47:18.97 ID:zgtKcvNm.net] >>834 C++向けに設計されたライブラリならデストラクタに終了処理を全部書いてあるのでusing構文自体が不要 スコープアウトでデストラクタが呼ばれる std::ofstream fs("a.txt"); fs<<"test"<<std::endl; 853 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 08:57:42.45 ID:zgtKcvNm.net] >>834 C#2.0以降に実装されてた糖衣構文の多くはC++には実装されていない お前のC++の用語がところどころ違うから無知なようにしか見えない 854 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 10:15:21.19 ID:sgjjbJfo.net] >>834 > ・$"X = {X}" > ・null合体演算子 まあこれは全然違うレベルの話だけどこう言うところはC#はなかなか良く出来てると思う 855 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 13:15:41.55 ID:ES6j8MQa.net] >>839 >fs<<"test"<<std::endl; ファイルオープンできてるかどうかわからないのに書き込むのかよwww C++てファイルオープンできてもないところに書き込んだときに 処理を停止せず、自動でうまく例外処理するおしゃれな機能なんてあったっけ? using(var sw=new StreamWriter("a.txt")){ sw.WriteLine("test"); } とじゃ全然意味が違うだろ なんでエラーチェックしないの? わざわざチェックしなきゃいけないかどうかの話をしてんだよ わざと論点ずらすな >C#2.0以降に実装されてた糖衣構文の多くはC++には実装されていない その通り それを問題にしてんの。 そのおかげでC++では生産性の向上が見られない 認めてるじゃねーかwww 856 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 13:54:11.00 ID:nEZBRLmQ.net] C++ vs C#スレ立てるか？ 857 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 14:02:35.35 ID:uj+JKNAz.net] >>842 > ファイルオープンできてるかどうかわからないのに書き込むのかよwww そういうのが欲しけりゃエラー時に例外を出すようにしとけばいいだけ C# 使ってりゃそれぐらいわかるだろ ... 使えてりゃねw 858 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 15:37:33.26 ID:Blieee3P.net] >>842 >>838は無視かよ。 ずいぶんと都合のいい目をしているんだな。 859 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 18:17:46.54 ID:aaZp/+dN.net] >>838見ればC++がなぜ衰退していくかよくわかるな 860 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 18:28:11.81 ID:4Wrqo5DU.net] >>846 なんで？ そこまでいうからにはきっちり説明してもらおうか。 説明できなきゃ馬鹿にしようかね。 861 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 20:08:24.48 ID:WCI7hBXJ.net] iostreamなんて今使ってないだろ 862 名前：デフォルトの名無しさん [2022/03/30(水) 20:21:40.16 ID:qIK9n1MF.net] > C#のusingみたいな構文 C#の発明と言うより、発祥は、お前らの嫌いな、Visual Basic(VBA)の、With〜 End Withじゃないかな？ 863 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 20:22:04.28 ID:UJJsLtPb.net] C++は例外がcharベースのwhatしかない時点で日本語Win上では実情と合わなくなるんよね。 864 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 20:22:32.28 ID:/krHLZdG.net] >>834 Rustだと以下のようになる > ・using RustもC++と同じくRAIIなのでusingは不要 let mut file = File::create("a.txt")?; file.write("test")?; エラー時は?演算子で即returnとなり例外処理と類似状態になる スコープを抜ける時に自動的にデストラクタdrop()が呼ばれる 何もしなくてもファイルなら自動closeされてロックなら自動解除される > ・$"X = {X}" Rustでは標準マクロ利用でほぼ同様の形式 format!("x={x}") > ・null合体演算子 Rustは安全重視のため各型にnullやnilといった値が無い状態というものがない そこで関数型言語と同様に代数的データであるenumを用いてジェネリックにT型に対してenum Option<T>型を使う Option<T>型はT型の値tが存在する場合Some(t)と存在しない場合Noneの2つのenum値をとる なのでnullに対応するものはNoneとなるが型が異なるので明白に区別できてミスがあればコンパイル時に検出可能 865 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 20:25:10.41 ID:/krHLZdG.net] >>834 > ・null合体演算子 Rustでは>>851という状況なのでnull合体演算子についても少し概念が違ってくるが xがNoneの時にDEFAULT_VALUEとしたい場合 x.or(Some(DEFAULT_VALUE)) でOption<T>型を得る x.or(Some(DEFAULT_VALUE)).unwrap() でT型を得る x.unwrap_or(DEFAULT_VALUE) が上記の簡易版でT型を得る 例えばC#での x ?? y ?? z を全てOption<T>型で表すと Rustでは x.or(y).or(z) となりほぼ同じシンプルな表現 ちなみに?演算子によるNone時の即retun Noneも可能で 例えば各メソッドがOption<T>型を返すとするとこれでT型を得られる let output = input.method1()?.method2()?.method3()?; 866 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 20:27:16.59 ID:WCI7hBXJ.net] >>850 その例外ベースだけだとおもってるの？ クラスや型ならなんでも投げられるんだが 867 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 20:31:07.93 ID:UJJsLtPb.net] それは例外そのものの型のことでしょ。 基本的にはexceptionの派生や孫で作られてるものが大半だからwhatでメッセージ受けるわけだが、 何のエンコードかは定かではない。 868 名前：デフォルトの名無しさん [2022/03/30(水) 20:33:36.81 ID:qIK9n1MF.net] >>842 根本的な理解がない、残念君のご様子。 > std::ofstream fs("a.txt"); コンストラクタでOpenする場合、失敗すると例外がスローされるから、関数内 または上位でtry〜catchかな。 C#やJavaで毎回NULL参照チェック書いてるか？ いずれにしろ、オープンされていないオブジェクトが > fs<<"test"<<std::endl; に渡されることはない。　こうした処理は、オブジェクトのシリアライズ処理を実装 した関数内へ記述して、参照渡しでオープン済のオブジェクトを渡すのが一般的。 869 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 20:43:31.08 ID:/krHLZdG.net] Rustにはnullも例外もなく どちらも代数的データ型であるenumで表現するため シンプルかつ安全性をコンパイル時に保証できる 870 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 21:06:36.60 ID:UJJsLtPb.net] RustでC#のdynamicみたいなことやるにはどうするの？ 871 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 21:23:30.04 ID:yBbOBLyf.net] >>849 全然ちゃうわww 872 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 21:25:28.30 ID:9xKIjqbP.net] >>857 C#はdynamic型という間違った方法を取ったため C#は実行時エラーおよび実行時例外が発生し安全でない Rustは型とは直行するトレイトがあるため 複数の様々な型に対して共通する振る舞いをトレイトとして実装できる これらはコンパイル時にチェックされ実行時の安全性が保証される 更に加えてトレイトの利用方法は用途に向けて2種類用意されている 1つは利用時にimpl Traitで宣言する静的なトレイト利用であり 複数の様々な型に対して各々の静的に異なるコードが適用され高速である もう1つは利用時にdyn Traitで宣言する動的なトレイト利用であり 複数の様々な型に対して実行時にダイナミックにディスパッチし柔軟である 2種類ともにコンパイル時にチェック確定するため Rustではこれら実行時にエラーや例外が起きることはない 873 名前：デフォルトの名無しさん [2022/03/30(水) 21:55:25.20 ID:qIK9n1MF.net] > Rustではこれら実行時にエラーや例外が起きることはない 実行時にメモリが足りなくなったら、Rustで書かれたプログラムは どんな挙動を返すの？ 874 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 21:57:54.53 ID:UJJsLtPb.net] それだと使えないなぁ。 875 名前：デフォルトの名無しさん [2022/03/30(水) 21:58:03.62 ID:qIK9n1MF.net] >>858 おなじだよ。　usingに一時オブジェクトを渡す場合に限って、usingの終わりと オブジェクト寿命が同じなだけだ。 876 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 22:00:39.04 ID:T6u2kz/X.net] 毎度のことながら複オジのアホ解説読むと Rust勧めてるのはこのレベルの人なのかと悲しくなる 無知にも程がある 877 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 22:05:28.12 ID:qUkXH45r.net] >>860 それちゃんとよく読めよ C#のdynamic型に対応するものの話だろ ちなみにRustではメモリアロケータも変更可能＆自作も可能でベアメタル含めて任意の環境に対応できる だからメモリ不足時の対応も自由にできてOS等も書ける もちろん一番単純な対処としてはpanic 878 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 22:07:51.84 ID:jqrh8rWF.net] >>861 C#でのdynamic型で適用してる事項はすべて適用出来るでしょ 反例を持ってこない限りこれはC#側の負けよ 879 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 22:11:11.16 ID:bu0twkVZ.net] >>862 With~End Withだけじゃなくusingも勉強し直した方がいいよ リアルで恥を掻く前に 880 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 22:14:11.74 ID:UJJsLtPb.net] 対象なオブジェクトがrust内にあるわけでも存在してるかさえわからない状態なんだから、 実行時にはエラーや例外が発生すると思うのだが... 881 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 22:25:39.59 ID:ALQUZfnd.net] >>867 どういう想定か曖昧すぎてわからないため一般的な話をすると Rustにはnullもundefinedもないし いわゆるtry-catch例外もないから あるT型が求められる時の関数の返り型は>>851でも触れられているように代数的データ型となって enum Option<T>型かenum Result<T, Err>型になるよ これらはT型を取り出すために広い意味での分岐となるだけで普通に処理が進むね 882 名前：デフォルトの名無しさん [2022/03/30(水) 22:26:22.84 ID:qIK9n1MF.net] >>866 お前がナー 883 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 22:31:08.47 ID:YEeL7eMZ.net] >>867 それはC#でdynamic型を使って問題を解決している例ではないのでは？ 例えばWebのDOM操作など色んな異なる型が返ってくるときのためにC#ではdynamic型を使う Rustではそういう時にトレイトを使うので色んな異なる型が返ってきても対応できる 884 名前：デフォルトの名無しさん [2022/03/30(水) 22:34:21.72 ID:qIK9n1MF.net] >>839 > usingより簡単だし例外でも問題なし。 >>842 は、 > using(var sw=new StreamWriter("a.txt")){ の、newに失敗すると、その時点で例外がスローされることを判ってないん だろうな。 885 名前：デフォルトの名無しさん [2022/03/30(水) 22:37:02.42 ID:qIK9n1MF.net] >>864 > ちなみにRustではメモリアロケータも変更可能＆自作も可能 C++でもできるわけだが？ 886 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 22:42:11.12 ID:OkNrkUse.net] >>872 どこにもC++のことを否定していない書き込みに対して唐突のイチャモンやな それならC++だけでなく Cでもできるわけだが？ 887 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 22:47:22.15 ID:4xlnCCQ3.net] >>860 君は頭が悪いな C#のdynamic型は失敗仕様であるという話だぜ メモリが十分にあっても実行時エラーや例外で死んでしまう コンパイラが検知できない仕様なためミスがあっても通してしまうからだ 888 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 22:50:27.28 ID:NgOFxdTU.net] >>869 いや、マジで勉強したほうがいいぞ using はスコープから拔ける時に Dispose 呼ぶだけ 寿命に感知はしないよ 889 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 23:09:24.22 ID:4bDt5Vb4.net] dynamic自体は名前がわかってるreflectionをいちいち書くのダルいから妥当な導入ではある ジェネリクスにC++20のrequiresみたいな制限があればdynamicなんていらなかったのは確かだが 890 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 23:15:44.80 ID:SheiVyTd.net] 実行時になってようやくエラーを引き起こし得るdynamicはC#の設計ミス C++やRustは異なる解決をしている 891 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 23:59:52.46 ID:Lj4LP6Zg.net] dynamicってそもそもリフレクション＋式木でしょうが こんなもん使うな ジェネリック使え 892 名前：デフォルトの名無しさん mailto:sage [2022/03/31(木) 00:03:05.89 ID:EY1WgKK4.net] tagged-unionだよ 893 名前：デフォルトの名無しさん mailto:sage [2022/03/31(木) 00:24:36.68 ID:LBSBAbTE.net] ミスった時にコンパイルエラーを出せない仕様はよくないな >>859 Rustでの対応は3種類だな (1) ジェネリックにトレイト境界で制約して静的にモノモーフィゼーション (2) ジェネリックにトレイト境界で制約して動的にディスパッチ (3) enumでタグ付け収容して処理時分岐 いずれもプログラミングでミスれば実行時ではなくコンパイル時に早期エラー発覚できる 894 名前：デフォルトの名無しさん mailto:sage [2022/03/31(木) 01:54:42.49 ID:sTE3Pr3t.net] >>855 std::ofstreamのコンストラクタで例外を投げるってマジ？ 普段からC++使ってるの？ 895 名前：デフォルトの名無しさん mailto:sage [2022/03/31(木) 15:47:20.37 ID:TWJkYixT.net] >>832 リソース解放って構造体と紐づけるのは結構無理があると感じることが多い。 もっとコンテクストによるって方が一般的感覚だと思うわ。 そういう意味でdeferのが馴染む。 896 名前：デフォルトの名無しさん mailto:sage [2022/03/31(木) 16:56:25.59 ID:+qzJxbYZ.net] >>882 上にも書いたけど自由度は高いと思うけど忘れたり間違えたりしそうで怖い 897 名前：デフォルトの名無しさん mailto:sage [2022/03/31(木) 17:43:45.66 ID:TWJkYixT.net] デストラクタを正しく書く方が簡単で間違いと考えてる？あんまり理解できんな。 898 名前：デフォルトの名無しさん mailto:sage [2022/03/31(木) 18:24:33.50 ID:wBL3yx/w.net] >>884 デストラクタは一度書けばいいけどdeferは使う度に書かないとだめでしょ？ どっちが間違いやすいかは考えるまでもない 899 名前：デフォルトの名無しさん mailto:sage [2022/03/31(木) 18:47:26.32 ID:d1Z8MU3o.net] >>884 必要なものはだいたい標準ライブラリに入ってるから手書きで頑張る必要はないのでは 例外安全にするのがめんどくさいとかそういう話？ 900 名前：デフォルトの名無しさん mailto:sage [2022/04/02(土) 20:19:43.92 ID:Yphv2UuC.net] https://discourse.llvm.org/t/rfc-lifetime-annotations-for-c/61377 clangの独自拡張としてだけどC++にlifetime入れようという議論があるんだね 901 名前：デフォルトの名無しさん mailto:sage [2022/04/02(土) 20:54:43.62 ID:ezdDFz2p.net] ライフタイム導入すればコンパイル時点でバグを発見できて 実行時の無駄なデバッグを減らせるし メモリ関係の未知のセキュリティバグもコンパイル時点で検出できるもんな 902 名前：デフォルトの名無しさん mailto:sage [2022/04/02(土) 22:41:04.77 ID:5MtdHF70.net] これ以上C++を接ぎ木してこねくり回すの止めにしたら 903 名前：デフォルトの名無しさん mailto:sage [2022/04/03(日) 11:55:08.48 ID:W9pHkRzU.net] >>887 でもrustと同じならdoubly linked listは表現出来ないんでしょ？ 904 名前：デフォルトの名無しさん mailto:sage [2022/04/03(日) 12:04:52.85 ID:llhYZSlD.net] >>889 C++ってかわいそうな運命だよなあ 905 名前：デフォルトの名無しさん mailto:sage [2022/04/03(日) 16:13:05.78 ID:9lFqLTmO.net] >>890 それはlifetime関係なくてxor mutabilityの話だよね 906 名前：デフォルトの名無しさん mailto:sage [2022/04/03(日) 16:37:52.29 ID:W9pHkRzU.net] >>892 なるほど 907 名前：デフォルトの名無しさん mailto:sage [2022/04/03(日) 17:12:35.56 ID:Qom6hzMo.net] >>890 Rustでは出来るよ 908 名前：デフォルトの名無しさん mailto:sage [2022/04/03(日) 17:28:58.27 ID:FsLhH6TX.net] >>885 そんなの一行書くだけろ。。むしろ意図 909 名前：通りのデストラクタが動いてるか怪しい挙動するデストラクタのが問題起こりまくりだわ。 [] [ここ壊れてます] 910 名前：デフォルトの名無しさん mailto:sage [2022/04/03(日) 17:44:36.67 ID:77d+30yb.net] >>895 > そんなの一行書くだけろ。。 できないプログラマーの典型で草 一行書くだけだから確実にできると言うならバグは無くなるわ > むしろ意図通りのデストラクタが動いてるか怪しい挙動するデストラクタのが問題起こりまくりだわ。 それはお前の能力が足らんだけ 911 名前：デフォルトの名無しさん [2022/04/03(日) 17:49:59.46 ID:rc6NcMYZ.net] >>895 defer使えば怪しい挙動は絶対しないとでも？ 912 名前：デフォルトの名無しさん mailto:sage [2022/04/03(日) 17:57:55.57 ID:9lFqLTmO.net] デストラクタでリソースが解放されることを保証するのはデータ構造を定義する人だけど deferの場合はデータ構造を使う人の責任になる データ構造を定義する回数と使う回数では普通は後者の方が多くなるから deferの方が間違いを起こしやすいと 913 名前：デフォルトの名無しさん mailto:sage [2022/04/03(日) 19:34:48.12 ID:W9pHkRzU.net] >>894 実行時にオーバヘッドが出る形でしか実現できないやん 914 名前：デフォルトの名無しさん mailto:sage [2022/04/03(日) 20:40:47.40 ID:9lFqLTmO.net] >>899 オーバーヘッドが出てるのって具体的に何のこと？ stdのLinkedListの実装にもオーバーヘッドあるの？ 915 名前：デフォルトの名無しさん mailto:sage [2022/04/04(月) 09:02:06.19 ID:14cK0a9Z.net] >>900 LinkedListってunsafeで実装されてるんだけど静的にメモリセーフティを実現する言語機能があるRustでそれをするっておかしいよね？ それって行儀よく実装するとオーバーヘッドが出ることの裏返しだよね？ちょっとは頭を使おうか？ 916 名前：デフォルトの名無しさん mailto:sage [2022/04/04(月) 09:14:12.42 ID:y2zkcNcq.net] >>901 えっ、じゃあなんでunsafeという機能がわざわざ用意されてるの？ 頭使って考えてみて 917 名前：デフォルトの名無しさん mailto:sage [2022/04/04(月) 09:31:58.76 ID:WSInp7AV.net] >>901 linked listに限らず何でもunsafeで作られているよ unsafeは悪ではなく、安全なインタフェースを備えた型やモジュールの内部に閉じ込めるもの その結果Rustではプログラム全体の安全性を保証できる 悪なのはプログラム全体がunsafe状態なC/C++ 918 名前：デフォルトの名無しさん mailto:sage [2022/04/04(月) 09:56:40.12 ID:88Lrr0N7.net] >>902 そりゃRustの型システムがオーバーヘッドが起こるやり方でしか安全性を保証できないからでしょ？ 頭使えないんだねかわいそう 919 名前：デフォルトの名無しさん mailto:sage [2022/04/04(月) 10:04:31.11 ID:y2zkcNcq.net] >>904 そうそう、コンパイラとプログラマの責任範囲を明確化するための仕組みだよね 結局 >>899 で言いたかったのは safe rust だけで LinkedList を実装するとオーバーヘッドが生じると言うことだったんだね 920 名前：デフォルトの名無しさん mailto:sage [2022/04/04(月) 10:09:11.84 ID:9r+bgOYm.net] >>903 それってRustの型システムに基づいて行儀よく実装するとオーバーヘッドが出ることへの反論になってないよね？ つまりRustの型システムはdoubly linked listを含めたあらゆるデータ構造をオーバーヘッドなく実装できるほどの表現力がないってことだよね 921 名前：デフォルトの名無しさん mailto:sage [2022/04/04(月) 10:23:50.48 ID:y2zkcNcq.net] >>906 safe rustの範疇ではあらゆるデータ構造を表現できないのはその通り なのでunsafeというescape hatchを用意している rustはpureな言語ではないのでコンパイラですべての安全性を保証することは最初から狙ってないよ 922 名前：デフォルトの名無しさん mailto:sage [2022/04/04(月) 10:34:53.41 ID:M7C/Fpbq.net] >>906 それは違う 例えばVec(ベクタ)はRustが標準ライブラリで提供している型だが LinkedList(二重リンクリスト)もRustが標準ライブラリで提供している型である VecもLinkedListも内部でunsafeを用いているが安全なインタフェースのみを公開している その両者に違いはなくRustによる安全性の保証に何も問題を及ぼしていない 923 名前：デフォルトの名無しさん mailto:sage [2022/04/04(月) 13:39:53.90 ID:RabHiWd3.net] オーバーヘッドwってことでいいじゃん 中途半端な知識でムキになるから無駄なやり取りが続くんだよ 924 名前：デフォルトの名無しさん mailto:sage [2022/04/04(月) 15:17:06.36 ID:ilb8jjlp.net] >>908 > VecもLinkedListも内部でunsafeを用いているが安全なインタフェースのみを公開している ホントかなぁ。　ベクターやリストが管理するオブジェクト参照を、別の参照ポインタ に代入して、ベクターやリストを破棄した後で参照を使うとぬるぽになりそうだけど？ これを防ぐには、ベクターやリスト自体はもちろん、各要素や生ポインタを含めて あらゆる変数に参照カウンタを設けた上で、参照数が0になったタイミングでオブ ジェクト自動破棄する必要があるが、まさにオーバーヘッド。 925 名前：デフォルトの名無しさん mailto:sage [2022/04/04(月) 18:59:43.72 ID:RDBERkGC.net] rustって、unsafe使っていても メモリ安全のチェックはしてくれるって事であってる？ 926 名前：デフォルトの名無しさん mailto:sage [2022/04/04(月) 19:11:22.90 ID:vi3Hd2oR.net] >>911 そんなことはない。 ttps://doc.rust-jp.rs/book-ja/ch19-01-unsafe-rust.html 927 名前：デフォルトの名無しさん mailto:sage [2022/04/04(月) 19:18:31.93 ID:UrWVuubJ.net] rustって、制限きついなら制限緩い他の言語に変換しやすいとかある？ 928 名前：デフォルトの名無しさん mailto:sage [2022/04/04(月) 20:04:42.98 ID:0mSmJ0PC.net] 標準ライブラリに問題がないって言い切れるの? コンパイラとか標準ライブラリを盲信できるほど完成度高いんですかね 盲信してると不具合の発見に支障が出そう 929 名前：デフォルトの名無しさん mailto:sage [2022/04/04(月) 20:07:34.39 ID:Aq9lII9f.net] 嫌なら使わなければいいだけやろ 930 名前：デフォルトの名無しさん mailto:sage [2022/04/04(月) 20:19:31.81 ID:VNZL7sLo.net] >>910 そんなRustの初歩くらいは学んでからレスしようぜw

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef