Rust part10

1 名前：デフォルトの名無しさん mailto:sage [2021/04/02(金) 21:38:04.11 ID:L7IeSfpL.net] Mozilla発のRust言語のスレ 公式 https://www.rust-lang.org/ https://blog.rust-lang.org/ https://github.com/rust-lang/rust Web上の実行環境 https://play.rust-lang.org 日本語の情報 https://rust-jp.rs/ 前スレ Rust part9 https://mevius.5ch.net/test/read.cgi/tech/1598112455/ 52 名前：デフォルトの名無しさん mailto:sage [2021/04/10(土) 03:35:58.01 ID:mUxV1BIo.net] >>51 begin〜last すわなち [begin, last]　をRustで書いたら begin..last+1 になる、という意味やったｻｰｾﾝ、 しかしコメント内に現れた「a..b」は、Rust式に[a, b)と解釈すべきなのか、 それとも伝統的な[a, b]解釈とすべきなのか というのがそこはかとなく疑問が…… 53 名前：デフォルトの名無しさん mailto:sage [2021/04/10(土) 03:38:59.03 ID:mUxV1BIo.net] 同じことは「=」と「==」（代入と等値）の使い分けを コメント内にまで持ち込むべきかどうかという意味で 昔から迷う感じだったものがRust（やGo）の「..」のせいで悩みの種が増えたは！ 54 名前：デフォルトの名無しさん mailto:sage [2021/04/10(土) 10:43:41.15 ID:+2v3HD7B.net] >>52 Rustコード中ではbegin..=lastって書いたほうがいい（>=rust-1.26.0） 知ってたらすまん >>53 Rubyもそうだぞ 55 名前：デフォルトの名無しさん mailto:sage [2021/04/10(土) 10:51:20.63 ID:gEDOL+ak.net] pythonもじゃないか？ C系のfor(int i=0;i<5;i++)の終了条件に合わせてあるのかと思う 56 名前：はちみつ餃子 mailto:sage [2021/04/10(土) 11:33:17.54 ID:0qKWjqEq.net] 最後の要素を意味するときは last で、 最後の要素のひとつ後を指すときは end を使う習慣があると どこかで見た覚えがあるんだけど、 別の言語だったかもしれないしどこかの数学分野だったかもしれない。 うろおぼえでスマソ 57 名前：デフォルトの名無しさん mailto:sage [2021/04/10(土) 11:52:10.96 ID:K51XBEHT.net] 既存の言語でも a..b が [a,b] になるもの、[a,b) になるものが混在してたこと、 また、見た目で意味が明確にわかることから a..b と a..=b を採用したという経緯だった気がする 58 名前：デフォルトの名無しさん mailto:sage [2021/04/10(土) 16:42:23.36 ID:l4RzKTvO.net] https://doc.rust-lang.org/book/ch02-00-guessing-game-tutorial.html の一番最後のコードをコピペしてもエラーで動かないのですが どこをなおしたらいいのでしょうか？ 59 名前：デフォルトの名無しさん mailto:sage [2021/04/10(土) 17:11:01.23 ID:gEDOL+ak.net] cargo. tomlそのままってオチかな？ 60 名前：デフォルトの名無しさん mailto:sage [2021/04/10(土) 17:13:25.76 ID:l4RzKTvO.net] randの追加はしております 61 名前：デフォルトの名無しさん mailto:sage [2021/04/10(土) 17:23:47.25 ID:+2v3HD7B.net] エラーメッセージを 62 名前：デフォルトの名無しさん mailto:sage [2021/04/10(土) 17:24:38.49 ID:gEDOL+ak.net] エラーそのまま貼らないとわからないわ と言うか頭からやりなよ 63 名前：デフォルトの名無しさん mailto:sage [2021/04/10(土) 17: ] [ここ壊れてます] 64 名前：50:35.32 ID:gEDOL+ak.net mailto: せっかく日本語訳だってあるわけだし https://doc.rust-jp.rs/book-ja/ch02-00-guessing-game-tutorial.html [] [ここ壊れてます] 65 名前：デフォルトの名無しさん mailto:sage [2021/04/10(土) 21:25:06.44 ID:l4RzKTvO.net] あ、すいません randのバージョンを最新版のものにしてました チュートリアルで指定されているバージョンにしたら動きました 失礼しました 66 名前：デフォルトの名無しさん mailto:sage [2021/04/10(土) 21:28:15.45 ID:ugs90wL2.net] 乱数なんて超基本的なライブラリが コンパイル通らないぐらいのAPI変更を簡単にやってしまうなんて大丈夫なのかこの言語 67 名前：デフォルトの名無しさん mailto:sage [2021/04/10(土) 21:58:15.68 ID:gEDOL+ak.net] この場合は言語の責任でもないしそのためのcargoだし 68 名前：デフォルトの名無しさん mailto:sage [2021/04/10(土) 22:07:11.12 ID:gEDOL+ak.net] でもせっかくこういう体験したのであればソースの方を直すのも正しき甲殻類な気がするな 69 名前：デフォルトの名無しさん mailto:sage [2021/04/10(土) 22:55:00.58 ID:DbIYjEaQ.net] 最近使ってないけど randってなんか使いにくいAPIだった気がする 70 名前：デフォルトの名無しさん mailto:sage [2021/04/11(日) 01:46:09.52 ID:+yU+1pdE.net] 最近マシになってきた 71 名前：デフォルトの名無しさん mailto:sage [2021/04/11(日) 03:28:20.09 ID:FNN81f5r.net] マシにする為だろうが一度決めたAPIは変えない それがC/C++界の掟じゃないのか？ 72 名前：デフォルトの名無しさん mailto:sage [2021/04/11(日) 08:22:28.91 ID:/Boh3f8b.net] 絶対に変えないようにした結果かえってひどいことになってるイメージ 73 名前：デフォルトの名無しさん mailto:sage [2021/04/11(日) 08:57:50.42 ID:SN158GXT.net] 普通は破壊的仕様変更のときはメジャーバージョン変えそうなもんだがバージョン0だからな 74 名前：デフォルトの名無しさん mailto:sage [2021/04/11(日) 09:07:58.37 ID:QZzlCmlR.net] バージョン0のうちは破壊的な変更もし放題ということか 75 名前：デフォルトの名無しさん mailto:sage [2021/04/11(日) 09:12:29.26 ID:SN158GXT.net] そいや非推奨や廃止の警告出せたっけ？ 76 名前：デフォルトの名無しさん mailto:sage [2021/04/11(日) 10:02:11.52 ID:8BAcJ5Wr.net] >>74 deprecatedアトリビュートで出せるよ 77 名前：デフォルトの名無しさん mailto:sage [2021/04/11(日) 10:25:10.63 ID:SN158GXT.net] Microsoftがプログラミング言語「Rust」への支援を強化 https://news.yahoo.co.jp/articles/d9e8b5acb96920789bb4364951481f074bfd93d8 visual rustとか出さないでよね… >>75 だよねえ どのバージョンで変えるか警告はするよねえ 78 名前：デフォルトの名無しさん mailto:sage [2021/04/11(日) 10:47:22.32 ID:SN158GXT.net] んでバージョン指定変えてみたら get_rangeの引数が最小、最大+1の２つから最小..最大+1の範囲リテラルに変わったのね カンマを..に一ヵ所変えるだけだったから修正自体は対したことなかったけどオーバロードがあればもっと緩やかな改変が出来るのだろうか？ ゼロコスト抽象化の方針上仕方ないのだろうか？ 79 名前：デフォルトの名無しさん mailto:sage [2021/04/11(日) 11:24:02.64 ID:FNN81f5r.net] >>77 そんなしょうもない変更の為に互換性破壊したのか 80 名前：デフォルトの名無しさん mailto:sage [2021/04/11(日) 11:29:55.74 ID:duIaxYyg.net] >>78 ..= が使えるようになったとあるのでインターフェースの改善ではあるのでは あと破壊的変更はこれだけではない https://rust-random.github.io/book/update-0.8.html 81 名前：デフォルトの名無しさん mailto:sage [2021/04/11(日) 12:27:09.74 ID:SN158GXT.net] マイナーバージョンが上がるのでも結構変わると言うことか 82 名前：デフォルトの名無しさん [2021/04/11(日) 13:05:02.83 ID:/JadX22/.net] バージョン0のうちはね 83 名前：デフォルトの名無しさん mailto:sage [2021/04/11(日) 13:15:29.70 ID:SN158GXT.net] 誰かも言ってたけどこう言うのは標準ライブラリで整備してほしい所だあな 84 名前：デフォルトの名無しさん mailto:sage [2021/04/11(日) 13:43:12.49 ID:4rSwKpry.net] 乱数は用途によってアルゴリズム使い分けにゃならんからなぁ Cのrandはまぁ使えないとしてC++のrandomまで行くと重い 85 名前：デフォルトの名無しさん mailto:sage [2021/04/11(日) 14:40:26.89 ID:duIaxYyg.net] randの設計が安定しない現状でstdに入れるにしても かなり限定されたサブセットしか入れられないのでは 86 名前：デフォルトの名無しさん mailto:sage [2021/04/11(日) 17:41:37.63 ID:aRgjPq06.net] それで十分だろ。 メルセンヌツイスターとか必要な場合は各々入れたら良い。 手軽な乱数を必要とする場面は割とある。 87 名前：デフォルトの名無しさん mailto:sage [2021/04/11(日) 21:41:09.50 ID:LXnW0jT4.net] メルセンヌ・ツイスタ、MT19937 を使っているのは、Ruby ぐらい 他の言語は、低品質 88 名前：デフォルトの名無しさん mailto:sage [2021/04/11(日) 22:30:00.44 ID:2GAqbccY.net] 一瞬信じかけたけど、pythonもboostもmtだったわ 89 名前：デフォルトの名無しさん mailto:sage [2021/04/11(日) 22:41:39.90 ID:FNN81f5r.net] 何でそんなとこで嘘つくん？ 90 名前：デフォルトの名無しさん mailto:sage [2021/04/11(日) 23:24:19.82 ID:REr5r+Uo.net] >>85 直近でThreadRngやRngも破壊的変更されてて 乱数生成器の種類を充実させるとかそういうレベルにすら達してないのよ 91 名前：デフォルトの名無しさん [2021/04/12(月) 16:58:50.31 ID:JNYj24al.net] 一部のプログラミング言語では、デフォルトの疑似乱数生成器としてメルセンヌ・ツイスタが 標準ライブラリに取り入れられている。そのような言語の例として、 Python,[2][3] Ruby,[4] R,[5] PHP,[6] MATLAB, C++[7]（C++11から） がある。 92 名前：デフォルトの名無しさん mailto:sage [2021/04/12(月) 19:41:31.46 ID:bbHno7r0.net] よそはよそ！うちはうち！ 93 名前：デフォルトの名無しさん mailto:sage [2021/04/12(月) 21:18:15.82 ID:z80SpJNy.net] 線形合同が、あまりに低品質 94 名前：デフォルトの名無しさん mailto:sage [2021/04/12(月) 21:49:55.90 ID:b3c5oHjh.net] オライリー調査で明らかに--Go、Rust、Ruby、Dartに関心高まる - ZDNet Japan https://japan.zdnet.com/article/35169143/ 95 名前：デフォルトの名無しさん mailto:sage [2021/04/12(月) 22:02:51.56 ID:mno1Imjq.net] fn main() { let n = 100; println!("{}", type_of(n)); } これを実行すると E0425: cannot find function `type_of` in this scope not found in this scope になるのですがtype_ofは使えないのでしょうか？ rustc -V 1.51.0です 96 名前：デフォルトの名無しさん mailto:sage [2021/04/12(月) 22:08:31.70 ID:mno1Imjq.net] すいません とほほのRust入門見て解決しました type_ofを関数として定義しないとダメなんですね https://docs.rs/typed/1.0.0/typed/fn.type_of.html にページがあったので組み込み関数があるものだと思いこんでたら そういうものは存在しなくて,type_ofの関数を定義しないとダメだったようです kindleで入門書を購入したのですがそこが省略されておりはまりました 失礼しました 97 名前：デフォルトの名無しさん mailto:sage [2021/04/12(月) 22:40:04.94 ID:J2Rjxost.net] 乱数ってxorshiftとかxoroshiroもあるわけで まぁアルゴリズム固定は難しいでしょう 98 名前：デフォルトの名無しさん mailto:sage [2021/04/12(月) 23:08:15.49 ID:/+zeTQQu.net] no_std環境も考えるともし一つ選ぶならMTよりxorshiftかなぁ。Rustの方針に合わないから入ることはないだろうけど。 99 名前：デフォルトの名無しさん mailto:sage [2021/04/13(火) 00:51:04.66 ID:zVaLotRH.net] APIをどうするかどこまでリッチにするかとかも難しいんだろ 100 名前：デフォルトの名無しさん mailto:sage [2021/04/13(火) 01:57:46.80 ID:dtk27dGR.net] xoroshiro1024がないんだよね。 >>95 ```shell rustup doc --std ``` 101 名前：デフォルトの名無しさん mailto:sage [2021/04/15(木) 21:01:10.98 ID:aIjUzI+d.net] パニックお断り―Linus，"Rust for Linux"の盛り上がりに釘を刺す https://gihyo.jp/admin/clip/01/linux_dt/202104/15 102 名前：デフォルトの名無しさん mailto:sage [2021/04/15(木) 21:13:33.74 ID:aIjUzI+d.net] JavaScript／TypeScriptランタイム環境「Deno 1.9」がリリース、パフォーマンス向上に寄与する機能追加など https://codezine.jp/article/detail/13970 103 名前：デフォルトの名無しさん mailto:sage [2021/04/16(金) 04:30:01.56 ID:h4psCBcA.net] >>100 メモリの確保に失敗したくらいでpanicはしないが alloc::alloc::Allocatorの一部メソッドはpanicするから no_core上にpanicしないアロケータ実装すればよさそう。 コンパイル遅いのはキャッシュするしかない。 104 名前：デフォルトの名無しさん mailto:sage [2021/04/16(金) 09:28:25.44 ID:eEnfPPGg.net] 結局kernelやるならunsafeつけまくりにしかならんだろ。 そうするとなぜrustで？という事になる。 105 名前：デフォルトの名無しさん mailto:sage [2021/04/16(金) 09:50:50.04 ID:MkjaOpjL.net] >>102 その「panicしないアロケータ」を使った Vec やらなんやら全部実装しなおさないといけなくならない？ 106 名前：デフォルトの名無しさん mailto:sage [2021/04/16(金) 18:31:00.46 ID:7IMcJQmu.net] >>104 といっても変えるのはnewとかくらいで大半の実装はそのままもってくればいいんじゃない？ まあパッチ投げてる人もそこは作業量多いとは言ってるけど。 107 名前：デフォルトの名無しさん mailto:sage [2021/04/16(金) 18:54:38.72 ID:GwffY4ld.net] >>104 Vec等のコンテナにはtry_reserveとかのメモリ割り当て失敗でエラーにする関数用意されているから メモリ割り当ての失敗だけが問題ならliballocの使い方を変えるだけでよいのでは 他にpanic要因あるならだめだけど ちなみにnewはメモリ割り当てしないから変更不要 108 名前：デフォルトの名無しさん mailto:sage [2021/04/16(金) 21:12:31.63 ID:eEnfPPGg.net] ある種の「コンテキストに対するunsafe」をつけて回らなきゃ無理。 でもってそれはmoonshotだって言ってるわな。 https://lkml.org/lkml/2021/4/14/1140 109 名前：デフォルトの名無しさん mailto:sage [2021/04/16(金) 21:47:54.90 ID:GwffY4ld.net] 特定の関数が割り込みのコンテキストから呼び出されたときにコンパイルエラーにすることは 今の言語機能では不可能という話か 110 名前：デフォルトの名無しさん mailto:sage [2021/04/16(金) 23:21:39.03 ID:Xc/jdFUF.net] >>107 role orientedな言語でコンパイラが特別扱いする コンテキストを指定できれば実現できる、 ここまで考えてだからmoonshotなのかと。 111 名前：デフォルトの名無しさん mailto:sage [2021/04/16(金) 23:46:26.48 ID:Kk/3g/Ul.net] Cでも出来てないことを要求してどうすんの 112 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 00:54:40.80 ID:r+Flv24K.net] 知らんがな。どうしてもrustでkernel作りたいってやつに言えや。 113 名前：はちみつ餃子 mailto:sage [2021/04/17(土) 02:30:05.79 ID:V2rXjiTW.net] Linux のカーネルはカーネルとは言ってもかなり巨大なので 現状の Rust でも採用可能な箇所もあるんでないの。 知らんけど。 114 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 08:49:33.19 ID:r+Flv24K.net] >>112 だからその考えでドライバーならということで始めたら上記の問題が出てきたってところだよ。 何周遅れてんだよ。 115 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 09:05:35.37 ID:dMPv+0ET.net] グーグル、Linuxカーネル開発における「Rust」採用の動きをサポートする考え https://japan.zdnet.com/article/35169455/ 利用が進めば問題点も見えてくるし何らかの対策は追加されるだろうな 116 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 09:33:32.53 ID:tTsG+vVF.net] linusすごいな Rust関わってる人全員子供扱いかよ 117 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 10:42:23.64 ID:r+Flv24K.net] いや、これrustでkernelに関わろうとした人たちが低レイヤーのこと、あまりにわかってなさすぎだろ。。 これ、ほぼ素人の俺でも気づくような内容だぞ 118 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 10:53:16.85 ID:ttx9Ve6D.net] へぇ、すごいんですねぇー^^ 119 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 10:55:23.76 ID:r+Flv24K.net] 冷笑系気取りのバカって本当に救いようがないよな。 120 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 11:09:22.71 ID:h7zOlTtk.net] C++でもコンテナに値を追加しようとすると、メモリー不足で追加に失敗 する可能性があるが、それをいちいちチェックする人はまず居ないだろうな。 デスクトップマシンでそれに失敗する可能性はとても低いけども。 121 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 11:14:10.31 ID:h7zOlTtk.net] 例えば、 std::vector<int> v; // 空の動的配列を生成 for ( unsigned int i = 0; i < 100000000; i++ ) { v.push_back(i + 100); // 末尾に i + 100 という値を追加 } とした場合、環境やマシンの状態によってはメモリー不足で失敗することは あるだろうが、これをいちいちエラーチェックする人は少ないだろう。 122 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 11:22:45.09 ID:3/shspJz.net] >>116 https://rust-lang.github.io/rfcs/2116-alloc-me-maybe.html 歴史的背景はこことか見ると書いてあるけど、処理系の初期開発で想定されていたほとんどの開発者はallocation errorから回復する必要がないから、あえてそういうAPIデザインにしたと カーネルはその「ほとんど」から外れる用途だからlinusは当然今のAPIじゃダメだと釘を刺す だからallocator_apiその他の安定化が急がれる、それだけの話じゃないの？ 123 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 11:25:00.56 ID:/69X/cno.net] linusへのレスポンス読んだ？ allocについては問題なのは認識してるけど 開発スピード上げるために今はliballoc使っていて そのうち独自の物に置き換えると言っている 124 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 11:27:24.53 ID:t/1FzfAW.net] pure rustでカーネル作ってる人いるんだから 原理的に不可能ってわけでもないだろ 125 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 11:29:13.13 ID:LJqBKM+D.net] allocまで全部作り切ってからパッチ投げてLinusに却下って言われたら目も当てられんしな。プロトタイプの段階でこまめに出すのはいいと思う。 126 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 11:37:37.77 ID:h7zOlTtk.net] >>120 伝統的なCでは、 char *ptr; if ( (ptr = malloc(サイズ)) == NULL ) {　// (1) 　printf( "メモリ確保にしっぱいしたで〜\n" ); } それをC++で書くとすれば、 if ( (ptr = new char [サイズ]) == NULL ) {　// (2) 　printf( "メモリ確保にしっぱいしたで〜\n" ); } となるけれども、 v.push_back(i + 100);　// (3) でメモリーエラーのエラーチェックしないのに(2)でしても余り意味はないという 考え方もあるわけでなので(2)と書かずにエラーチェック無しで ptr = new char [サイズ];　// (4) と書く方針もあっていいと思う。 なお、よっぽど大きなデータを扱わない限り、デスクトップマシンでは (3)や(4)で失敗する可能性はとても低い。 127 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 11:41:51.20 ID:h7zOlTtk.net] N88-BASICでは、読み込みモードでファイルを開く時、 open "ファイル名" for input as #1 と書いていたが、ファイルが存在しないとここでエラーになって アプリが終了していたことを思い出した。 Perl、Ruby、Pythonなんかは、全て基本的に同じ方針だと思う。 その流儀とRustでのメモリー不足時のpanicの方針も同じと考えていいだろうな。 128 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 11:48:23.17 ID:r+Flv24K.net] >>121 そう、それだけの話。でもそれだけの話がここでは恐ろしく通じない。 129 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 12:20:31.25 ID:3/shspJz.net] >>122 On allocation: this is just our usage of `alloc` in order to speed development up -- it will be replaced (or customized, we have to decide how we will approach it) with our own allocation and data structures. これのことか？ itってour usage of `alloc`のことじゃねーのと思ったけど、alloc自体のAPIデザインに問題があるみたいな話出てるの？ 130 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 13:30:05.64 ID:5SUmF/jF.net] >>125 > if ( (ptr = new char [サイズ]) == NULL ) {　// (2) C++ は new も vector::push_back も bad_alloc が飛ぶ。ふつうの new は nullptr 返さない。 131 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 13:35:37.75 ID:YGcs/48d.net] てかアロケータの動作がどうのってLinux Kernel関係あるの？ ベアメタル用途全般が該当すると思うけど 132 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 14:08:16.83 ID:h7zOlTtk.net] >>129 そういえば、言葉は忘れたけど、関数宣言の行に、その関数の中でどういう 例外が起きる可能性があるかについてのthrows を書くかどうか、書くべきか、 省略しても良いか、などの違いが色々あって、どういう言語仕様にすべきかが 結構問題になっていると聞いた。 すべてを書くと多くなりすぎるし、全く書かないのも問題だとか、そんな話。 なんという言葉だったかな。 133 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 14:30:50.99 ID:ahfNUrst.net] allocatorがエラーを返さずに例外を上げる挙動にRustの標準ライブラリ的なもの(コレクションとかスマートポインタとか？)が依存していて、 それはLinuxカーネル的には許容できないからそういうコードをそのまま持ち込むなよ？ということでしょ Linuxカーネル上のC言語はそもそも標準ライブラリとか使わないし メモリ確保もmallocじゃなくてkmallocというカーネル内独自関数使うし ここ見ると https://medium.com/nttlabs/linux-kernel-module-with-rust-d5363c2f9085 array: vec![0;32] で kmalloc が呼ばれるみたいだね でもこれLinuxのカーネルモジュールのコードとしてはそこでエラーチェックが必要になるのかね？ もしくはkmallocに失敗したらそのモジュール自体が自動でアンロードされるとか でもアンロードされるときに後処理とかしたいかなとかいろいろ考える必要はありそう 134 名前：はちみつ餃子 mailto:sage [2021/04/17(土) 14:48:08.80 ID:V2rXjiTW.net] >>131 動的例外仕様 (dynamic exception specification) のことか？ https://timsong-cpp.github.io/cppwp/n3337/except.spec 送出される可能性のある例外を記述する仕組みだったが、役に立ってなかったので C++17 で廃止された。 (例外を送出するかしないかだけを指定する方式が残された。) C++ の仕様では例外を送出しないという指定を付けたところを例外が通過しようとしたら std::terminate が呼ばれて異常終了扱いになるという、実質的な assert なんだわ。 静的な検査をカッチリやってくれるわけではないんで、 カーネル記述みたいな文脈では使い物にならんな。 135 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 14:49:51.36 ID:ohP60UMx.net] linuxだろうとwindowsだろうと普通のカーネルはそうだろ。 よっぽど特殊用途のOSならどうかは知らんが。 136 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 15:49:17.42 ID:h7zOlTtk.net] >>133 なんか、Javaにおいて、throwsに創出するすべての例外を書く仕様にしてみたら、 地獄のように沢山書かなくてはならなくなって困り、 関数プロトタイプ宣言の直後の throws()の中に 「書く必要のある例外」と「書かなくても良い例外」 の違いを設けることにした、この板で聞いた。 137 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 15:56:30.53 ID:h7zOlTtk.net] >>135 「OutOfMemoryError」例外は、throws に明示しなくて良いことになった とWikipediaで見た記憶が有る。 138 名前：はちみつ餃子 mailto:sage [2021/04/17(土) 16:29:38.34 ID:V2rXjiTW.net] >>135 検査例外と非検査例外のことだな。 例外の便利なところは大域脱出が出来るところで、例外を捕捉する箇所と発生する箇所の間では例外のことを忘れられる点。 発生しうる例外の伝播を明示しないといけないのだと返却値で返す形にするのと差がない。 例外を使っていると異常系だということが見た目に分かり易いってくらいのもの。 Java が明示しなくてよい例外という分類を設けたのは明示しなくてよいというだけでなく捕捉もしなくてよいということでもあって、 どのように使い分けるのがよいかは諸説あるけども、非検査例外は ・ 捕捉したところで回復できないもの ・ そもそもその例外を発生させないようにすべきもの (実質的には assert) というのがおおよその共通認識になっている。 メモリ不足は回復不可能なので非検査例外に分類されているが、 「Java のレイヤでは」回復不可能という話であって、 Java では低レイヤを書かないという前提があるからこういう決め打ちが出来る。 低レイヤと高レイヤでは前提が違ってくるから同じようにはいかんのだ。 139 名前：デフォルトの名無しさん [2021/04/17(土) 16:34:30.24 ID:h7zOlTtk.net] >>136 https://www.w3resource.com/java-tutorial/types-of-exception.php 1. Checked exceptions 2. Unchecked exceptions が有り、2. には、 2-1. Errors 2-2. Runtime exceptions の2種類がある。 1はmethodシグネチャのthrowsの後に明示しなくてはならないが、 2は不要。1はプログラマが処理することが出来る場合が多いが、 2はとても難しいことが多い。 OutOfMemoryErrorは、2-1 に属し、throwsの後に明示する必要がないが 「2」なのでプログラマが対処することが難しい例外に分類される。 140 名前：はちみつ餃子 mailto:sage [2021/04/17(土) 16:46:23.23 ID:V2rXjiTW.net] 低レイヤでも高レイヤでも使うことを考えたらやっぱ例外という仕組みは使いにくいっつーことだな。 カーネルを書くにあたって Rust が (現状では) ベストというわけでもないだろうけど、 比較的可能性がある選択のひとつではあると思う。 どうせ標準ライブラリのフルセットを使えるわけではないのは C でも同じことだし。 141 名前：デフォルトの名無しさん mailto:sage [2021/04/17(土) 17:10:18.35 ID:h7zOlTtk.net] Rubyなんかでファイルオープンする時にはエラー発生チェックをしなくてもよくて エラーが発生するとpanicする。これは簡単なプログラムでは便利。 そしてbegin,rescue,endではさめば、panicせずにエラー処理することも 出来る様になっている。これはtry,catch構文と発想は同じ。 でも、読み書き用の2つのファイルをオープンして読んで加工して書き込む ような時、catch文でどっちのエラーか区別したりするのは面倒といえば面倒かな。 C風だと、fopen の行で処理できて分かり易かったのに。 142 名前：デフォルトの名無しさん [2021/04/17(土) 17:12:33.63 ID:h7zOlTtk.net] >>139 でも、リストに追加したときにメモリ不足になっても、例外機構でしか エラーを補足出来ないのは面倒だな。 143 名前：デフォルトの名無しさん mailto:sage [2021/04/18(日) 02:29:17.84 ID:xL1TJJG/.net] ttps://github.com/rust-lang/rust-bindgen/commit/0e25962c4e69aef647e7275fa7bc7545dbb8cd0b#diff-b1a35a68f14e696205874893c07fd24fdb88882b47c23cc0e0c80a30c7d53759 コロコロ変わってその度に置換するスクリプト書いてるんだけど、 二ヶ月くらい音沙汰ないからそろそろ名前くらい安定してほしい。 144 名前：デフォルトの名無しさん [2021/04/18(日) 09:49:21.11 ID:vWwiRD ] [ここ壊れてます] 145 名前：OG.net mailto: rustってそんなにいいか？ 任意の場所でfreeできるcとは違って ブロック抜けるタイミングでしかメモリ開放されないんだろ？ rustっていらなくなってもブロック抜けるまではヒープメモリ保持しないといけないってことなの？ [] [ここ壊れてます] 146 名前：デフォルトの名無しさん mailto:sage [2021/04/18(日) 10:08:02.12 ID:UN4umXE6.net] >>143 dropじゃだめなの？ 147 名前：デフォルトの名無しさん mailto:sage [2021/04/18(日) 10:09:10.01 ID:732wPalE.net] そんなに良くないからキミはもっとcを頑張ったほうがいい cを頑張ってc++にも手を出して頑張って 気が狂いそうになるのを覚えてからもう一度来たらいい 148 名前：デフォルトの名無しさん [2021/04/18(日) 10:34:02.72 ID:vWwiRDOG.net] >>144 lifetime内であれば手動で早期開放できるんですね お世話になりました 149 名前：デフォルトの名無しさん mailto:sage [2021/04/18(日) 12:33:31.22 ID:gA/cagL6.net] ワロタw 150 名前：デフォルトの名無しさん mailto:sage [2021/04/18(日) 12:57:11.20 ID:UN4umXE6.net] vectorにpushしながらその要素の可変参照を返すようなメソッドってあったりしますか？ 151 名前：デフォルトの名無しさん mailto:sage [2021/04/18(日) 13:12:40.26 ID:/yrt+WGh.net] お前らの用途だったらgoで十分だろと思うことが多いわ。 ファッションでやるってのも悪くはないが。 152 名前：デフォルトの名無しさん mailto:sage [2021/04/18(日) 13:30:23.57 ID:8MLIImZW.net] rustではunsafeを多用するのは良いことですか？

---

---

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

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