1 名前:デフォルトの名無しさん mailto:sage [2021/08/24(火) 22:55:27.78 ID:972JwtmU.net] 公式 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を学びたい人はまず最初に公式のThe Bookを読むこと https://doc.rust-lang.org/book/ ※Rustのasyncについて知りたければ「async-book」は必読 https://rust-lang.github.io/async-book/ ※C++との比較は専用スレへ C++ vs Rust https://mevius.5ch.net/test/read.cgi/tech/1619219089/ 前スレ Rust part11 https://mevius.5ch.net/test/read.cgi/tech/1623857052/
567 名前:デフォルトの名無しさん mailto:sage [2021/09/24(金) 19:03:51.27 ID:clPGC+m8.net] 機能性で言えば競プロに必要なものは大抵の言語が備えてるだろうし 使いやすさで言えばRustはきっちり書くことを求められてるから素早く書くのには向いてないし それでも敢えてRustを選ぶ理由は趣味や慣れくらいなのでは
568 名前:デフォルトの名無しさん mailto:sage [2021/09/24(金) 21:51:28.01 ID:73j3AhJA.net] releaseビルドするとTrojan:Script/Wacatac.B!mlを検出して Windows Defenderに怒られる --release付けないと大丈夫 誤検知かな?
569 名前:デフォルトの名無しさん mailto:sage [2021/09/24(金) 22:12:48.28 ID:ow12Eod1.net] >>553 ごめん 例えばUnsafeCellの存在はRustの借用ルールに制約されることなく自由に新たな型を設計して作る道を開いているけど あくまでも安全な型を作るための素材であって具体的にはRefCellやOnceCellなどの様々な安全な型を提供する素材となっているように unsafeの存在も上位レベルで安全な関数やモジュールを提供するための素材としてのみ用いるべきではないか ということを伝えたかったのです
570 名前:デフォルトの名無しさん [2021/09/24(金) 23:54:29.51 ID:561kcuCK.net] つまり競プロ君のunsafeの使い方はただ危ない逸脱のみであり、 安全かつ便利な何かを提供する目的のための使い方ではなく、 Rustの精神に反している、と。 したがって競プロの話は、 このRust本スレでやるべきことではなく、 ここでは禁じて別スレでやるべき、と。
571 名前:デフォルトの名無しさん mailto:sage [2021/09/25(土) 00:09:12.18 ID:bZXyxueH.net] >>559 競プロくんを競プロの代表扱いするのはさすがに競プロの人に失礼では
572 名前:デフォルトの名無しさん mailto:sage [2021/09/25(土) 01:22:46.71 ID:HzR9ZlyY.net] Rustの精神とかそんな大層な話でもないでしょ 建設的に話せない奴に付き合う必要はないというだけ
573 名前:デフォルトの名無しさん [2021/09/25(土) 03:09:21.77 ID:r08K7R9X.net] >>558 違う人が書いた事を、さも自分が書いたように返答するのはどうかと思う
574 名前:デフォルトの名無しさん mailto:sage [2021/09/25(土) 08:30:11.81 ID:0L4s8Q79.net] >>562 え?? >>558 は自分の意見を書いただけでこのスレにしか書いていないし参考にしたサイトや書き込みもないよ もし偶然にそっくりな内容なものがどこか他にあるなら見てみたいので教えて
575 名前:デフォルトの名無しさん mailto:sage [2021/09/25(土) 22:50:40.30 ID:jDRrdRW5.net] >>559 こういう自分の意見にあわないと何でも排除したいヤツはどこにでもいるんだよなあ
576 名前:デフォルトの名無しさん mailto:sage [2021/09/26(日) 00:09:45.69 ID:EgHC/Y9j.net] Range関連での質問です (Included(&x), Included(&y)) はx..=yと書けますが、 (Excluded(&x), Included(&y)) を似たように書く方法ってありますか?
577 名前:デフォルトの名無しさん mailto:sage [2021/09/26(日) 01:40:54.44 ID:v4wa9AaY.net] >>565 ないんじゃない? (3..=5).skip(1)で、妥協するかなぁ
578 名前:デフォルトの名無しさん mailto:sage [2021/09/26(日) 01:56:26.69 ID:wsLZ/M6d.net] Range はよく使うから構文糖を入れてちょっと簡単にするという判断がうまれたんだと思うんで、 それほど頻出しないパターンは明示的に書くしかしょうがないと思う。 自分のプログラムでよく使うのであればそういう関数を用意しておけというくらいの妥協になる。
579 名前:デフォルトの名無しさん mailto:sage [2021/09/26(日) 03:07:15.60 ID:RXeC0HEE.net] >>565 range式も魔法があるわけではなく それぞれ対応する構造体があって各traitなどを実装してるだけなのですが stdにあるのは以下の6種類のみですね assert_eq!(.., std::ops::RangeFull); assert_eq!(3.., std::ops::RangeFrom { start: 3 }); assert_eq!(..7, std::ops::RangeTo { end: 7 }); assert_eq!(..=7, std::ops::RangeToInclusive { end: 7 }); assert_eq!(3..7, std::ops::Range { start: 3, end: 7 }); assert_eq!(3..=7, std::ops::RangeInclusive::new(3, 7)); 例えば開始点のあるRangeFrom・Range・RangeInclusiveはIteratorも実装 一方でその(Excluded(&x), Included(&y))形式すなわち (Bound<T>, Bound<T>)および(Bound<&'a T>, Bound<&'a T>)型だと 実装されているのはRangeBoundsトレイトのみでIteratorトレイトなどは無いという違いがあるようです 開始がUnboundedだと意味がないからでしょう つまりイテレータで回したい時にはこの形式では使えないので (Excluded(x), Included(y)) は (x+1)..=y と書くしかないと思います もちろんSkip構造体のコストを払って(x..=y).skip(1)もアリです
580 名前:デフォルトの名無しさん mailto:sage [2021/09/26(日) 03:55:02.75 ID:EgHC/Y9j.net] >>566 >>568 すみません、言葉足らずでした BTreeMap/Setのrangeメソッドに渡す引数を意図していました こちらに渡すのはイテレータではないのでskip(1)はできないようです >>567 >>568 あまり頻出ではないですし仕方ないですかね 実際困るわけではないのですが、 アンバランスなので気になってしまいました
581 名前:デフォルトの名無しさん [2021/09/29(水) 09:06:12.26 ID:W9rNFdvq.net] 無職の人工衛星おじさん来て
582 名前:デフォルトの名無しさん mailto:sage [2021/09/30(木) 11:51:35.89 ID:8/yMCOJS.net] ttps://lkml.org/lkml/2021/7/7/349 完全にストップしたな。最低だよ。
583 名前:デフォルトの名無しさん mailto:sage [2021/09/30(木) 12:33:08.03 ID:Ti8kA/OA.net] >>571 どういう意味や?
584 名前:デフォルトの名無しさん mailto:sage [2021/10/01(金) 12:54:11.60 ID:xF/FYN4O.net] >>573 どういう意味や?
585 名前:デフォルトの名無しさん mailto:sage [2021/10/01(金) 13:00:05.87 ID:EZf94GZ+.net] 自問自答かいな
586 名前:デフォルトの名無しさん mailto:sage [2021/10/01(金) 14:16:55.18 ID:5hzjqknK.net] Rust for Linuxに関しては結局それ以降進展無しということ?
587 名前:デフォルトの名無しさん mailto:sage [2021/10/01(金) 14:33:36.85 ID:2Q9z0ScR.net] そりゃ普段の作業はGitHub上でやって、まとまったところでパッチ投げるんだから LKMLで日々の進捗報告なんかしたら迷惑でしかない
588 名前:デフォルトの名無しさん mailto:sage [2021/10/01(金) 14:40:28.89 ID:5hzjqknK.net] https://github.com/Rust-for-Linux/linux ここかな? 全然活発だったわ
589 名前:デフォルトの名無しさん mailto:sage [2021/10/01(金) 15:23:00.24 ID:25/eRB6c.net] いや実際のドライバーが動かないのにごねてるだけやん。。話になってないんだが。
590 名前:デフォルトの名無しさん mailto:sage [2021/10/01(金) 23:00:07.65 ID:CSO4Qyhi.net] as usize祭りの回避ができてきてる━━━━(゚∀゚)━━━━!! let mut heap: BinaryHeap<Reverse<(usize, usize)>> = BinaryHeap::new(); heap.push(Reverse((0, 0))); while let Some(Reverse((_, now))) = heap.pop() { let mut que: VecDeque<(usize, usize)> = VecDeque::new(); que.push_back((now, 0)); while let Some((next, cnt)) = que.pop_front() { if cnt == price[now].1 { break; }; for &i in &list[next] { if total[i] > total[now] + price[now].0 { total[i] = total[now] + price[now].0; heap.push(Reverse((total[i], i))); } que.push_back((i, cnt + 1)); } } }
591 名前:デフォルトの名無しさん mailto:sage [2021/10/02(土) 02:05:08.49 ID:JhHEfT92.net] >>578 そうなんだ。誰がどこでごねてるの?
592 名前:デフォルトの名無しさん [2021/10/02(土) 07:25:57.30 ID:VZaTbxB/.net] VSCodeか何かで、編集中のファイルを(保存する度ではなく)リアルタイムで構文チェックしてもらうことってできないの? 目が悪いもので、C#みたいに間違えたら即指摘みたいなのがすごく助かるんだけど・・・・
593 名前:デフォルトの名無しさん mailto:sage [2021/10/02(土) 08:17:
] [ここ壊れてます]
594 名前:40.16 ID:KFBxuoB8.net mailto: rust-analyzer入れれば若干のラグはあるけどそんな感じでやってくれると思うが [] [ここ壊れてます]
595 名前:デフォルトの名無しさん mailto:sage [2021/10/02(土) 08:21:40.61 ID:KFBxuoB8.net] すまんオートセーブもつこうてたわw
596 名前:デフォルトの名無しさん mailto:sage [2021/10/02(土) 09:01:16.43 ID:hpIN2xHl.net] >>581 IntelliJRustにon the fly analysisあるぞ
597 名前:デフォルトの名無しさん mailto:sage [2021/10/02(土) 15:27:53.04 ID:4qLxMBdK.net] 普通にVscodeでRustの拡張入れたらやってくれん? 俺が思てる構文チェックとかの支援とは違うんかな
598 名前:デフォルトの名無しさん mailto:sage [2021/10/02(土) 15:48:21.44 ID:BIOPTGX0.net] vscode+rust-analyzerでオートセーブ無効でもリアルタイム構文チェックしてくれるよ
599 名前:デフォルトの名無しさん mailto:sage [2021/10/02(土) 17:14:40.18 ID:0lneUYYy.net] いつrust-analyzerに移行するか悩み中。
600 名前:デフォルトの名無しさん mailto:sage [2021/10/02(土) 17:43:54.53 ID:KFBxuoB8.net] >>586 Auto Saveオフだと、指摘してくれないやつ結構ない? セーブして初めて指摘されるやつが結構あるような
601 名前:デフォルトの名無しさん mailto:sage [2021/10/02(土) 17:45:45.06 ID:cWlg4bES.net] rust-analyzerってvimでも使える? 流石にvim捨てるべきかなあ
602 名前:デフォルトの名無しさん mailto:sage [2021/10/02(土) 18:12:12.35 ID:kCAgHltC.net] vimでもneovimでも使えるよ
603 名前:デフォルトの名無しさん mailto:sage [2021/10/02(土) 21:14:54.36 ID:Yx61ypoH.net] rls から rust-analyzer の移行なんて躊躇するもんじゃないぞ。 試して合わなければすぐに戻せばいいだけだし、戻りたいと思う可能性は俺はゼロだと思う。
604 名前:デフォルトの名無しさん mailto:sage [2021/10/02(土) 21:57:31.81 ID:BIOPTGX0.net] >>588 構文チェックとrust-analyzerの検知できる型エラーは保存しなくても指摘されるはず(前者は即時、後者は少しラグがある) rustcじゃないと検出できないものは確かに保存時しか出ないかもね 特に害あるものじゃないしauto save有効にしても良いのでは?
605 名前:デフォルトの名無しさん mailto:sage [2021/10/02(土) 23:35:42.15 ID:qO3WxvTl.net] >>589 実際にビルドしてみてそのエラーメッセージをエディタに反映するという仕組み (いわゆる flycheck) は昔からあったんだが、 頻繁に実際にビルドするんじゃなくて処理系の構文解析プロセスとエディタを連携させればもっと効率的なんと違うか?という のがマイクロソフトによって LSP (Language Server Protocol) として標準化されたという経緯がある。 エディタにとっては場当たり的なエラーメッセージの解析をせずによくなったので昔より楽になってるんだよ。 昔から flycheck をやってるようなエディタはだいたい LSP にも対応してる。
606 名前:デフォルトの名無しさん mailto:sage [2021/10/04(月) 23:18:59.60 ID:AvMOOeeY.net] https://thenewstack.io/linus-torvalds-on-community-rust-and-linuxs-longevity/ > “Probably next year, we’ll start seeing some first intrepid modules being written in Rust, and maybe being integrated in the mainline kernel.”
607 名前:デフォルトの名無しさん mailto:sage [2021/10/05(火) 01:50:58.24 ID:lj8Vtprb.net] 統合早いな。多言語プロジェクトでcargo面倒くさい問題はなんかやってんだろうか? 統合されたらソース読んでみよ。
608 名前:デフォルトの名無しさん mailto:sage [2021/10/05(火) 03:19:27.62 ID:jICKdFeA.net] 言語を組み合わせる場合を含めてビルドプロセスの記述はなんだかんだで make が万能なんだよな。 クソみたいに場当たり的だけど必要だから機能を追加してきたという現実の前には どんな美しいパラダイムも砂上の楼閣という印象だわ。
609 名前:デフォルトの名無しさん mailto:sage [2021/10/05(火) 11:23:44.05 ID:+tJei17t.net] cargoが勝手にクレートダウンロードしてくれるのは便利だけどね セキュリティ的には……どうなんかなー
610 名前:デフォルトの名無しさん mailto:sage [2021/10/05(火) 11:55:21.23 ID:ds6mcw9v.net] ビルドはmakeからrustc呼ぶ形になってたはず カーネルに関してはクレートのダウンロードなんかもしないならそれで問題ない
611 名前:デフォルトの名無しさん mailto:sage [2021/10/05(火) 12:47:41.98 ID:ZN1Pvbj4.net] 余計なことするツールに限ってモジュラリティ低い
612 名前:デフォルトの名無しさん mailto:sage [2021/10/05(火) 12:55:43.82 ID:I8WE2KTE.net] >>596 既存のものがクソだから俺が全く新しいクールな奴を作ってやるぜ!っていって新しいクソが1つ増えるのはもはや伝統芸やね
613 名前:デフォルトの名無しさん mailto:sage [2021/10/05(火) 15:46:57.33 ID:q+7ifQX8.net] >>597 そのための --offline オプション
614 名前:デフォルトの名無しさん mailto:sage [2021/10/05(火) 18:59:42.65 ID:EBA9Mr3p.net] >>600 makeの機能を持つprologは欲しいなぁ。 論理プログラミング言語を拡張したmakeとか堅牢そうな気がするけど、誰もやらないのかしらん。
615 名前:デフォルトの名無しさん [2021/10/05(火) 20:24:54.05 ID:aXfbUEx/.net] >>602 prolog難しいから流行らない
616 名前:デフォルトの名無しさん mailto:sage [2021/10/05(火) 21:06:12.38 ID:ZN1Pvbj4.net] 宣言的なものの依存がゴタゴタしたもののデバッグのしずらさを知らんのだろう。呑気なもんだ。
617 名前:デフォルトの名無しさん [2021/10/06(水) 17:08:43.54 ID:XAVgSOSv.net] rust-analyserだかに移行しようとうおもったけどemacs とは相性悪過ぎて結局rlsに戻した analの方はcodeいれんとインストール出来んかったりとほぼvs用だなあれ(´・ω・`)
618 名前:デフォルトの名無しさん mailto:sage [2021/10/06(水) 18:10:02.17 ID:msHyc08D.net] >>605 lsp-modeとの組み合わせで普通に使えるが
619 名前:デフォルトの名無しさん [2021/10/06(水) 19:54:44.67 ID:yydNkGdJ.net] マジかeglot使ってたからかも 何かfunction defとかの問い合わせ方法間違ってんのか知らんが常にno docみたいのがmessage表示されて使いもんにならんかった lspってマジで全然分からんちんで小鳥の餌待ち状態で微塵も弄れないのよね俺(´・ω・`)
620 名前:デフォルトの名無しさん mailto:sage [2021/10/06(水) 23:28:27.48 ID:msHyc08D.net] rlsもlspだよ rlsのlsはlanguage serverのls
621 名前:デフォルトの名無しさん mailto:sage [2021/10/06(水) 23:40:35.33 ID:ET8OV0WS.net] >>607 標準ライブラリのソースコードがないとか? rustup component add rust-src で入ると思う
622 名前:デフォルトの名無しさん [2021/10/07(木) 00:12:56.69 ID:3bOhB6en.net] あんま多くは試しでないがrust-analyzerインストールする時に入れさせられたvscodeではanal pluginで動いてたしanal自体はインストール出来てると思うんだがな >>608 そのfuckin msの策定したlspを部分的にとか言語ごとに異なるoverrideてかimplで構成するプロジェクト群がrust-analyzerとかclangdだかとかgoplzとか ただこれらだけじゃ意味不明のjson object返したり読み込んだりするだけのdaemonで役に立たないから 仲介者としてのeglotとかlsp-modeが必要になる ここらまでも簡単に弄れるというか(弄れる必要があると言うのか...)がemacsの良いところ(´・ω・`)
623 名前:デフォルトの名無しさん mailto:sage [2021/10/07(木) 06:40:58.97 ID:F5HUOmxy.net] anal plug?
624 名前:デフォルトの名無しさん mailto:sage [2021/10/07(木) 11:35:48.71 ID:DOEkOZlT.net] インストールもなにも実行ファイルのパス通すだけだからね ~/.vscode/ 配下にあるはずだからそれを使うか GitHub からダウンロードしてくれば良い
625 名前:デフォルトの名無しさん mailto:sage [2021/10/08(金) 22:14:06.47 ID:XK73QT2t.net] べき剰余をオーバーフローさせずに作る関数を作ったヽ(´ー`)ノ fn calc(num: usize, pow: usize, m: usize) -> usize { let mut bit: usize = 1; let mut res: usize = 1; let mut tmp_pow: usize = num; while pow >= bit { if pow & bit > 0 { res = (res * tmp_pow) % m; } bit = bit << 1; tmp_pow = (tmp_pow * tmp_pow) % m; } res }
626 名前:デフォルトの名無しさん mailto:sage [2021/10/09(土) 10:18:30.30 ID:0okuLqNl.net] >>613 普通にオーバーフローするが calc(usize::MAX, usize::MAX, usize::MAX-1);
627 名前:デフォルトの名無しさん mailto:sage [2021/10/09(土) 11:49:04.73 ID:zLg6zd/V.net] 多分競プロのやつだから各数値は32bitなんだろう そらオーバーフローしねえよって話
628 名前:デフォルトの名無しさん mailto:sage [2021/10/10(日) 09:49:29.12 ID:bzbLkL2i.net] 都合のいい仮定置いてそうなのがらしい感じだわな
629 名前:デフォルトの名無しさん mailto:sage [2021/10/10(日) 11:17:36.59 ID:2mgB061S.net] ↓これと同じアルゴリズムなのに>>613 のは読みにくいね https://ja.wikipedia.org/wiki/冪剰余#途中で剰余をとる u64で受け取って内部ではu128で計算して u64で返すようにしとけばオーバーフローしない
630 名前:デフォルトの名無しさん mailto:sage [2021/10/10(日) 11:36:29.13 ID:2mgB061S.net] u16ならu32、u32ならu64、u64ならu128みたいな関係をジェネリクスで表現できたりする?
631 名前:デフォルトの名無しさん mailto:sage [2021/10/10(日) 11:52:04.33 ID:a5kt/zmp.net] trait作ってassociated typeで表現するのはできるかな
632 名前:デフォルトの名無しさん [2021/10/10(日) 12:00:59.32 ID:ZuTCKPOD.net] 関連型使えよ
633 名前:デフォルトの名無しさん mailto:sage [2021/10/10(日) 12:15:12.30 ID:2mgB061S.net] Traitを各データ型に対して全部実装するのが面倒だから 対応する倍のサイズの型を表現する方法はないのかなって話だったんだけど なさそうってことだね
634 名前:デフォルトの名無しさん [2021/10/10(日) 16:41:29.53 ID:X3SL3SyY.net] コンパイラを単純化(高速化)するためにプリミティブ型の型クラスはありません。例えば、Haskellに あるような数値型全般を表す Num という型クラスは、数値型全般を表しますが実体は IntやDoubleなど。 またはtypescriptのtype Tree = Leaf | Nodeはサポートされません
635 名前:デフォルトの名無しさん [2021/10/10(日) 17:11:17.77 ID:X3SL3SyY.net] rustはどちらかと言えばほとんどをトレイトで表現しますが、技術的にはこれらは、Tagged unionと呼ばれ 昔はSum typeともバリアント型とも呼ばれていました。プリミティブ型ではありませんが、似た機能を実現 する技術はenum variantsでも表現できます。C20にあるstd:variantもTagged unionです もちろんassociatedでも似たことは出来るでしょう https://en.wikipedia.org/wiki/Tagged_union
636 名前:デフォルトの名無しさん mailto:sage [2021/10/10(日) 17:13:00.50 ID:2mgB061S.net] >>622 num-traitsとenum
637 名前:デフォルトの名無しさん mailto:sage [2021/10/10(日) 19:43:56.21 ID:a5kt/zmp.net] >>621 マクロの使いどころ
638 名前:デフォルトの名無しさん mailto:sage [2021/10/10(日) 19:46:17.72 ID:a5kt/zmp.net] >>622-623 の言ってることが何一つわからんのだが
639 名前:デフォルトの名無しさん mailto:sage [2021/10/10(日) 19:56:58.54 ID:XwgBItsn.net] >>622 おっしゃる通りですがRustでは別の解決方法を取っていますね まず前者の全般的なNum型がない件ですが Rustでは単純な例だと以下のように1を足す関数add1ををジェネリックに書こうとすると (注釈: 足し算の「+」はstd::ops::Add traitを満たせば使えて任意の型でオーバーロード可) fn add1<T: std::ops::Add<Output=T>>(n: T) -> T { n + 1 } これはコンパイラが通らなくて「1」を型Iにする必要があり「1::<T>」等とでも書ければいいのですが無理です そこでnum craitのOne traitを使って以下のように書きます fn add1<T: std::ops::Add<Output=T> + num::One>(n: T) -> T { n + num::one::<T>() } これで以下のようにジェネリックに1を足すことができました assert_eq!(add1(36), 37); assert_eq!(add1(5.0), 6.0); assert_eq!(add1(1000i128), 1001i128); さらにこの方式ならば自分で定義する構造体など任意の型もAddとOneのtraitを満たせばadd1()を使える利点があります つまり最初の話に戻ると全般的なNum型があるよりももっと高度なことができるわけです 後者の件は一般的に代数データ型の直和をどう扱うかという話になりますが Rustではenumがタグ付き共用体でもあるのでenumでサポートできますね
640 名前:デフォルトの名無しさん mailto:sage [2021/10/10(日) 19:58:36.14 ID:S81FmWQC.net] >>617 rustは可変参照を基本的に好まないスタイルだから、ああなるのは仕方ないな
641 名前:デフォルトの名無しさん mailto:sage [2021/10/10(日) 21:20:06.28 ID:Dxd5NlvW.net] 他人のフリして自分のレスに返信してるやつなんなのwww
642 名前:デフォルトの名無しさん mailto:sage [2021/10/10(日) 21:23:34.82 ID:XwgBItsn.net] >>628 可変参照は関係あるのかな? どちらもbit処理を下から順にするアルゴリズムで変わりなく >>613 はbitマスクを大きく(左シフト)していく方法 >>617 はbitマスクは常に1で本体を小さく(右シフト)していく方法の違いだけだよね だから後者の方式でもRustでコーディングできて動くよね 両者の差分 fn calc(num: usize, pow: usize, m: usize) -> usize { - let mut bit: usize = 1; + let mut bit: usize = pow; let mut res: usize = 1; let mut tmp_pow: usize = num; - while pow >= bit { - if pow & bit > 0 { + while bit > 0 { + if bit & 1 > 0 { res = (res * tmp_pow) % m; } - bit = bit << 1; + bit = bit >> 1; tmp_pow = (tmp_pow * tmp_pow) % m; } res }
643 名前:デフォルトの名無しさん mailto:sage [2021/10/11(月) 00:12:55.43 ID:EeZezr6D.net] >>630 アルゴリズムではなくて、ポインタを渡すのか、実数値を渡すのか そこを明確にしているRustの仕様から引数を可変参照にするのは・・という意味では そして>>617 が何を読みにくいといっているのかも、よくわからんし
644 名前:デフォルトの名無しさん [2021/10/11(月) 00:34:40.68 ID:JbC5nNmw.net] >>624 >>627 がねがねその通りで、言った通りトレイトだが、「Num型があるよりももっと高度なことができる」これは弁明的。 近代的な言語はmixinもしくはアドホック多相で(高度なことが)出来る場合がほとんどであり、無いものを無いと 要求できず弁護をするのはちょっと違う。他にも角度のように、0-360まで制限したいプリミティブ型が欲しいのに PascalのようなSubrange型も足りていない。範囲を表す表現、0..360はあるのに。些細な事だが、コンパイラを 速くする事を現在は主眼なので(仕様に矛盾が無ければ)いずれは拡張されるのかもしれないが
645 名前:デフォルトの名無しさん [2021/10/11(月) 06:54:36.68 ID:95tWd+L1.net] mutをつけたベクター型について教えてください これはまず、入っているのは参照なんですか? また、参照が変わらない(?)のに、参照先を変更するにはmutがなぜ必要になってくるのですか? (所有権概念のせいなのでしょうか?それともスマートポインタの仕組み上、参照するアドレスが変わるのでしょうか?)
646 名前:デフォルトの名無しさん mailto:sage [2021/10/11(月) 08:28:39.20 ID:LNZ+tGdJ.net] >>633 let mut x = vec![1,2,3]; xに入ってるのはVec<i32>、これはスマートポインタ(pointer, capacity, length)。 「参照」というのはRustでは&Vec<i32>のようにアンパサンドがついてる型のこと なのでxに入ってるのは参照ではない 例えばx.push(10)するのにxがmutじゃなきゃいけないのは 直接的にはpushのシグニチャが&mut selfを要求してるからだけど 考え方としては「multiple readers or single writer」ルールをコンパイル時に強制するため 連続したバッファを確保できなければアドレスが変わる可能性も有るし ゼロキャパシティ
647 名前:なら具体的なアドレスを持ってない [] [ここ壊れてます]
648 名前:デフォルトの名無しさん mailto:sage [2021/10/11(月) 13:32:30.30 ID:15cV1HfU.net] Cortex-M対応がClangよりRustの方が進んでいて草
649 名前:デフォルトの名無しさん mailto:sage [2021/10/11(月) 14:07:37.59 ID:lgurMcJY.net] core::ptr::unique::Uniqueもalloc::raw_vecもただのdoc(hidden)なのに Vecがスマートポインタってデタラメ広めてる奴らどこが出処だよ。 以下の関係で、 Vec has-a RawVec RawVec has-a Unique - Vecがrustの作法を強制するためのnewtypeパターン←composition - RawVecが動的配列の低レベルapi←composition - Uniqueがユニークポインタ←smart pointer これだけだろ。 rustのコレクションはデータ構造上直接実装することになる型以外 Box含めて基本newtypeパターン(composition)だぞ。 >>633 GCのある言語しか触ったことない限りその発想にはならんから まずアロケータの仕組みからやりな。
650 名前:デフォルトの名無しさん mailto:sage [2021/10/11(月) 14:34:19.59 ID:Ei1usHzb.net] ホラふきが あらわれた!
651 名前:デフォルトの名無しさん mailto:sage [2021/10/11(月) 14:44:50.63 ID:CP46ljNK.net] また他人のフリして間違いを指摘するレスが来るから乞うご期待www
652 名前:デフォルトの名無しさん mailto:sage [2021/10/11(月) 15:28:05.06 ID:YVW/m0g2.net] compositionだからスマートポインタでないという理屈だと Rc も Arc も非公開な内部型の composition だからスマートポインタでなくなってしまう
653 名前:デフォルトの名無しさん mailto:sage [2021/10/11(月) 15:42:18.11 ID:LNZ+tGdJ.net] >>636 C++のことは一旦忘れて、Rustにおけるスマートポインタの意味を学ぶことをすすめる https://doc.rust-lang.org/book/ch15-00-smart-pointers.html
654 名前:デフォルトの名無しさん mailto:sage [2021/10/11(月) 18:57:50.60 ID:0Mn4AOx6.net] >>640 The concept of smart pointers isn’t unique to Rust: smart pointers originated in C++ and exist in other languages as well. とあるけど?
655 名前:デフォルトの名無しさん mailto:sage [2021/10/11(月) 19:29:34.65 ID:YVW/m0g2.net] We’ve already encountered a few smart pointers in this book, such as String and Vec<T> in Chapter 8, although we didn’t call them smart pointers at the time. Both these types count as smart pointers because they own some memory and allow you to manipulate it. They also have metadata (such as their capacity) and extra capabilities or guarantees (such as with String ensuring its data will always be valid UTF-8). というわけで Rust の定義では Vec<T> はスマートポインタ
656 名前:デフォルトの名無しさん mailto:sage [2021/10/11(月) 20:38:32.88 ID:oB6cAYFd.net] クイズ: この中にウソはいくつウソがある? 「またはtypescriptのtype Tree = Leaf | Nodeはサポートされません」 「rustはどちらかと言えばほとんどをトレイトで表現しますが、技術的にはこれらは、Tagged unionと呼ばれ 昔はSum typeともバリアント型とも呼ばれていました。」 「rustは可変参照を基本的に好まないスタイルだから、ああなるのは仕方ないな」 「Vecがスマートポインタってデタラメ広めてる奴らどこが出処だよ。 」
657 名前:デフォルトの名無しさん [2021/10/11(月) 23:52:58.48 ID:FfJkoMsS.net] >>633 pub struct Vec<略> { buf: RawVec<T, A>, len: usize, } pub struct RawVec<略> { ptr: Unique<T>, cap: usize, alloc: A, } pub struct Unique<T: ?Sized> { pointer: *const T, _marker: PhantomData<T>, } push|insertの際にlen|capとアロケート先が変化するという事、上のは難しい事をわざと言ってる スマートポインタ議論は無視でOK。しかしPhantomDataなんて理解してる人に会ったことない
658 名前:デフォルトの名無しさん mailto:sage [2021/10/11(月) 23:58:39.10 ID:ATb6fs5R.net] >>631 その冪剰余関数の引数は全て数値すなわちCopy traitを持つので 関数呼び出しに参照を渡す必要はありません また、可変参照の数値を渡す必要がある別の関数がもしあったとしても 普通に値を渡して変更値は返り値とする方がわかりやすいでしょう
659 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 02:02:02.32 ID:yPuGDG3+.net] >スマートポインタ議論は無視でOK。 他人のフリして我がフリ直せww
660 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 02:33:26.85 ID:1W2DSIiH.net] >>633 初級者ならばこのスレで言及されている内部実装の話は知らずとも使えるので無視してもよい それよりもmutableとimmutableの意味となぜ区別が必要かを理解したほうがいい あと参照の意味も理解していないようだからそこもまず基本だからおさえるべき それら基本を理解すればVecの中身が書き換わるならばmut指定が必要とわかるはず Rustは簡素に理解しやすく出来ているのに他言語のポインタ周辺の概念を無駄に持ち出してきて難しく考えて失敗する人たちが一部いる
661 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 07:19:09.45 ID:SacTrMIO.net] これが基本を理解してないと指摘されたやつのレスw
662 名前:デフォルトの名無しさん [2021/10/12(火) 08:17:13.13 ID:FR/wdn5M.net] Rusterは他人を同一人物と思い込む素性の悪い病人しか居ないな
663 名前:633 [2021/10/12(火) 08:42:15.75 ID:5WgWwJH0.net] 初心者丸出しの質問で、なんでこうなった・・・・・
664 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 10:28:07.94 ID:XIKPR8ou.net] >>647 >Rustは簡素に理解しやすく出来ているのに それには賛同できない
665 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 10:28:20.90 ID:h0zcLGc7.net] このスレにはアンチRustのC++爺さんと 間違った知識を上から目線でレスするRust初心者が各1名住み着いてるから 質問者は回答内容を自分で精査しないとダメだよ 特に後者はタチが悪いので注意して
666 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 10:37:06.05 ID:BYAG38Ke.net] Rustに近々追加される機能で熱いものなにかありますか?
667 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 10:43:27.65 ID:Br1er+Qs.net] Rustに関する質問はteratailで
668 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 10:55:07.59 ID:aJ9lzwpY.net] 現時点でRustなんかどうでもいい 10年後に普及してたら一般プログラマーも使う程度
669 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 11:09:47.63 ID:Br1er+Qs.net] 653見る前に654書いちゃったのでちょっと訂正 Rustに関するまじめな質問はteratailでするのがよい >>653 もうすぐRust2021がくるぞい 熱いのがあるかっていうと微妙かも
670 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 11:23:31.59 ID:lRrdrCP9.net] >>650 mutの必要有無は他言語では一般的じゃないRustのルールに関連してるんだけど それが少し難しいので回答する側にもそのルールを理解してない人がそれなりにいるということ 基本的にコンパイラが教えてくれるので深く理解してなくても使う分にはそこまで問題にはならない
671 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 12:59:59.43 ID:dsnSo1To.net] Rustを知るということは、弱点も知ることにつながる
672 名前:デフォルトの名無しさん [2021/10/12(火) 13:01:46.79 ID:k+FFNiZ5.net] vlangもmutがあるが散々否定される、曰く「理論に沿ったコンピューター工学を元にしてない」だとか 「トランスコンパイラでしょ」とか、NoGCが過大広告でLobsterというのは分かるがリークするでしょとか
673 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 13:21:05.00 ID:WmCYyvpu.net] async/awaitの追加で一旦大きな機能追加目標は終わって、以降は処理系の効率化にリソースを割いていく、みたいな話を読んだ気がする
674 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 13:54:32.71 ID:fJneTy5r.net] 結局他の言語でのメモリモデルも理解してないとrustはまともに使えんよ。 そこを誤魔化すやつはクソだわ。
675 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 14:51:47.32 ID:2YI6ZITw.net] >>633 Rustは書き換え競合を避けるために、書き換え可能な可変参照(for writer)と、書き換えられない参照(for reader)の区別をして、 書き換えられない参照は同時に複数を持てる(multiple readers)けど、可変参照は同時に一つだけしか許さない(single writer)とすることで、競合を避けている。 Rustではmutかどうかもその観点からなので、変数が別のVecになるだけでなく、同じVecのまま配列内容や長さの変化しても、内容長さ同じだが領域拡大で場所移動でも、書き換わりとしてmutが必要。 だから、Vecのメソッドでmutを要求してるのはそれらの結果論にすぎないし、Vecの内部構造がこうなってるからという説明は不要で筋違い。 >>661 それは違うな。 むしろ頭を一旦ゼロにする柔軟な人ほど理解が早い。 他言語での様々なモデル(メモリモデルやクラスモデルや…)をベースに難しく考える人ほど混乱して理解が遅い。
676 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 14:59:49.12 ID:fJneTy5r.net] >むしろ頭を一旦ゼロにする柔軟な人ほど理解が早い。 >他言語での様々なモデル(メモリモデルやクラスモデルや…)をベースに難しく考える人ほど混乱して理解が遅い。 これを本気で考えてるならバカとしか言いようがない。 C、もしくはアセンブラをバインディングした時に確実にぶっ壊れるコードになるわ。
677 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 15:34:41.08 ID:2YI6ZITw.net] >>663 それはABIやFFIの話であってRustの話ではない。 Rustで完結するシステムでは一切考慮する必要ない。 他言語ライブラリなど利用の際も、適切な仲介モジュールがあれば、利用側で考慮する必要はない。 各言語との連携部分では、それぞれその言語の知識が不可欠なのは当たり前。 だが、それはRustの話ではなく、Rustにおいてはその知識は必要ない。
678 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 16:09:45.89 ID:Br1er+Qs.net] メモリモデルって並行プログラミングやらないならあんまり関係なくない???
679 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 16:12:51.35 ID:BYAG38Ke.net] アトミック操作のOrderingの話なんかはC++の定義に丸投げしてるから他の言語の知識が必要というのは一応正しい
680 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 16:27:05.41 ID:2YI6ZITw.net] >>666 それは理解するのにC++の知識を一切必要としない。 なぜならC++言語仕様とは独立して定められている。 つまり、その件についてもRustを理解習得するために他の言語の知識は必要ない。
681 名前:デフォルトの名無しさん [2021/10/12(火) 18:24:19.63 ID:natODgzZ.net] >>662 「Vecの内部構造がこうなってるからという説明は不要で筋違い」うーん、それこそ趣旨が違うよ。 vec[0] = 2などとして内容長さ同じの場合の理解では、1つの可変参照と、複数の参照を持つ事を 知っているのは必要だが通常では長さや容量が拡張されるpushやinsertは内部構造により説明される。 mutatorであるpushを呼ばない限りはmutは必要なければ、「mutをつけたベクター型」では無くて 配列という質問になるのでは?
682 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 19:12:36.47 ID:2YI6ZITw.net] >>668 公開(pub)されていないstruct Vecの内部構造や非公開のRawVecなどを持ち出してくる人たちがいるから、 「Vecの内部構造がこうなってるからという説明は不要で筋違い」と書いた。 そこは長さや容量を持っている等の概念の理解だけで十分であるし、実際に公表されている情報もそこまで。
683 名前:デフォルトの名無しさん [2021/10/12(火) 19:33:58.77 ID:natODgzZ.net] >>667 C++の知識を「あまり」必要としないのは確かだがC20/C22などの仕様を「参考」にしているのは明らか。 というかLLVMから見てClangっぽく見えるように頑張っていると公式が言っている
684 名前:デフォルトの名無しさん [2021/10/12(火) 19:37:41.99 ID:natODgzZ.net] >>669 なるほど言いたい事は理解してるが、長さや容量を持っている等の概念の理解ならライブラリソースを 示した方が明らかでしょう。親切だと褒められる事はすれど不要と切って捨てるほどではないのでは?
685 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 21:00:30.83 ID:fJneTy5r.net] >>664 rustが単独で使われるなんてことは絶対にない。 低レイヤーのことがまるでわかってないってことがよくわかったよ。
686 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 22:00:42.97 ID:lRrdrCP9.net] >>662 「multiple readers or single writer」のセーフティルールは 参照だけに適用されるものではなくて参照の所有者を含めて適用されるもの
687 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 22:09:23.38 ID:+W0FsG+B.net] >>672 Rustでプログラムを書くに当たってRustを構成する様々な低レベルのレイヤーのうちどこまで書き手は意識すべきと考えますか? さすがにCPUを構成するシリコンひとつひとつの振る舞いを意識することは出来ないので、 これより先は気にしなくて良いという境界は存在すると思うのですが、それはどのあたりにあるとお考えでしょうか
688 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 22:18:28.12 ID:1W2DSIiH.net] >>672 no_stdでさらにシステムコール(あるいは相当)はasmでレジスタ渡しで呼び出しに至るまでRust完全単独で既存OS(など)利用もあるしOS作成ならOS側もRust単独
689 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 23:07:50.81 ID:XIKPR8ou.net] >>664 >Rustで完結するシステムでは一切考慮する必要ない。 それって議論の価値ある? だって現実的じゃないじゃん 研究者のための言語だっていうなら、それもありだけど ここにいる人間は実用を求めてるわけでしょ。多分……
690 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 23:22:14.99 ID:ElEzb70r.net] すまんが何を言っているかさっぱり分からない 自分が書いてるのは9割方Rustで完結したプロジェクトだけど、みんなFFIばっかり書いてるのか?
691 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 23:52:39.59 ID:XIKPR8ou.net] Win32APIとリンクしたり、そういうプログラムは書かないってことね
692 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 23:56:08.22 ID:ElEzb70r.net] Win32API使いたいんなら単にwindows-rsクレート使えば良いだけで その先のC ABIがどうなってるかとか気にする必要はないと思うが
693 名前:デフォルトの名無しさん mailto:sage [2021/10/12(火) 23:57:43.15 ID:ElEzb70r.net] ああでもwindows-rs自体は割とunsafe あるから気にしないとダメかな
694 名前:デフォルトの名無しさん mailto:sage [2021/10/13(水) 00:00:43.80 ID:PhFIUWEp.net] いや、そもそもwindows-rsクレート使おうが C理解してないと使えないよ だってwindows-rsの型定義は「今のところ」まともじゃないもん ポインタは何でもかんでもDWORDだし
695 名前:デフォルトの名無しさん mailto:sage [2021/10/13(水) 00:05:34.07 ID:1HIX7TKw.net] 確かに例が悪かった。windows-rsに関してはunsafe がある以上呼び出し先のCの知識は必須だね 言いたいのは自分でunsafeを書かない限り、Rustだけで完結するってこと そりゃ分野によってはまだライブラリ不足で完結しにくいのもあるだろうけど、多くの分野で完結すると思うがなぁ
696 名前:デフォルトの名無しさん mailto:sage [2021/10/13(水) 00:37:10.90 ID:bi9uBzGZ.net] で、そういうメモリをほとんど気にしないソフトはrustで書く必要がないものなんだよね。 ファッションでやってることがバレちゃったね。
697 名前:デフォルトの名無しさん mailto:sage [2021/10/13(水) 00:38:57.86 ID:fXfbCLiK.net] Rust以外のプログラミング言語を考えれば理解しやすい C言語を全く知らなくても使えるようにその言語だけで書かれたAPIで何でも利用できる Rustも同様でC言語を全く知らなくても使えるようにRustだけで書かれたAPIで何でも利用できるようにすることができるし実際にほとんどの分野ではそうなっている その上でRustの場合は効率面から元のAPI向き出しで例えばCStr使ったりするなどC言語でのAPIのまま提供するモジュールも存在するというだけにすぎなくてそこはあくまでもFFI領域 したがって「他の言語と同様にRustもC言語を全く知らなくても使える」で正解
698 名前:デフォルトの名無しさん mailto:sage [2021/10/13(水) 01:08:46.05 ID:4amWetfo.net] >>683 rustで書く必要性が薄いってのは結構当てはまるとは思うが、 だからといってメモリ回りの知識がrustで何か書くには絶対必須とはならんだろう
699 名前:デフォルトの名無しさん mailto:sage [2021/10/13(水) 01:16:25.82 ID:fXfbCLiK.net] >>683 例えばstd::fsやstd::netなどは本来ならCのABIでやりとりするものだが そんなこといっさい気にする必要なくRustの型で渡してRustの型で返ってくるようにRustの標準ライブラリが作られている そこにCの知識は全く必要としない
700 名前:デフォルトの名無しさん mailto:sage [2021/10/13(水) 07
] [ここ壊れてます]
701 名前::24:31.94 ID:WqU30Pep.net mailto: たくさん書くのは自信がなさの表れ そんな必死になるような話じゃないだろうに [] [ここ壊れてます]
702 名前:デフォルトの名無しさん mailto:sage [2021/10/13(水) 09:00:38.12 ID:W/9iWpHx.net] Cを理解してないとRustは使えない、と ウソをつく人がいるからだろう
703 名前:デフォルトの名無しさん mailto:sage [2021/10/13(水) 09:25:52.29 ID:bi9uBzGZ.net] そう思い込んでりゃいいんでない? 近くにいなけりゃ放置するよ。近くにいればボコボコにするけど。
704 名前:デフォルトの名無しさん [2021/10/13(水) 09:41:01.46 ID:+i9fv0nZ.net] >>674 cpuはシリコンウエハ一枚から切り取ったものからなっている 複数のシリコンの集合体ではない
705 名前:デフォルトの名無しさん mailto:sage [2021/10/13(水) 10:15:02.35 ID:hOkEY9I6.net] >>688 そういうやつの相手をムキになってやってるうちは自分も同じレベルだって気付けよな
706 名前:デフォルトの名無しさん mailto:sage [2021/10/13(水) 10:36:12.77 ID:gkjY8I9d.net] >>690 ちなRyzenとか、組み込みマイコンとかは、マルチチップを繋いで一つにパッケージしてるのもあるけどね。 シリコン一つ一つとかポエムっぽいのは秋になったからか?
707 名前:デフォルトの名無しさん mailto:sage [2021/10/13(水) 14:45:58.97 ID:qAYNHtUZ.net] >>690 シリコン原子一粒一粒の意味
708 名前:デフォルトの名無しさん mailto:sage [2021/10/14(木) 18:50:15.29 ID:1TrBYNn/.net] コンピュータアーキテクチャの基礎知識(メモリモデル、アクセスオーダ、スレッディング等)やOSのシステムコール、APIの知識の事を "C言語の知識" と呼ぶ人が居るのね。 まあどうでもいいけど。
709 名前:デフォルトの名無しさん mailto:sage [2021/10/14(木) 19:43:21.65 ID:JvADELGn.net] システムコールにしても最終的にはレジスタに積んでsyscall命令もしくは割り込みするだけだからCでもRustでもasmと共存するだけか C言語の知識は要らないな
710 名前:デフォルトの名無しさん mailto:sage [2021/10/14(木) 20:55:23.77 ID:1TrBYNn/.net] まあシステムコールやAPIは C や CPP のヘッダ形式で定義/提供されてるという事を言いたいなら判らんでもないが、 そこまでコアな言語仕様知識は要らないねえ。
711 名前:デフォルトの名無しさん mailto:sage [2021/10/14(木) 21:55:10.80 ID:GbD2vike.net] rustは書けるけどCが書けない人いる? そういう人がいないとCがいるかいらないかわからない 自分はCの知識が役に立ったと思う
712 名前:デフォルトの名無しさん mailto:sage [2021/10/14(木) 22:21:20.24 ID:dWpPrl+Q.net] RustでWebバックエンド書いてる人になら普通にいるんじゃない? Web系ならこれまでのキャリアで全くCに触れなくてもおかしくないし
713 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 10:55:12.45 ID:GXWQCf9x.net] 昔からRust for Rubyistsとかあるしスクリプト系言語から流れて来る人もそれなりにいるかと
714 名前:デフォルトの名無しさん [2021/10/15(金) 12:44:17.46 ID:P5mUityt.net] スマートポインタやシェアードポインタ、所有権なんかは、C++0xあたりで導入された考えだから どの程度の範囲をC言語と言っているのかによる。要らない派が多く「見える」が、知識があって 理解をを妨げるという考えは全否定する。「あって困るものではない」
715 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 14:00:41.51 ID:8deGlJY8.net] >>695 OSプログラムしてるとレジスタ内容をメモリに載せるなんて普通にあることなんだが。 まあrustでOSなんて書かないから関係ないですけどね。
716 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 14:27:53.37 ID:lZWoC8Xx.net] >>701 OSなんて書いたこともないくせに語るなド素人
717 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 15:04:44.50 ID:8deGlJY8.net] >>702 ソースコード読むことすらしてないバカは黙ってて。
718 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 15:15:35.47 ID:rb+Oscx7.net] なんか低レベルな話で盛り上がってるな
719 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 15:16:50.75 ID:5/Pqp5xe.net] そんなことよりシステムコールの呼び出しにCの知識は必要ないっていうコメント対して>>701 のレスが噛み合ってないんだが、何を言いたかったのか解説してくれないか
720 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 15:20:05.89 ID:8deGlJY8.net] なるほど、レジスタからメモリ書き込みの同期タイミングなどが必要とかそこまで具体的に言わないと理解できないレベルなのか。 すげー馬鹿しかいないのなら仕方ないな。
721 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 15:33:44.29 ID:5/Pqp5xe.net] システムコールの呼び出しとはまったく関係ないな
722 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 15:40:54.74 ID:lZWoC8Xx.net] OS書いたことも無いのに恥ずかしい奴
723 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 15:45:02.58 ID:lZWoC8Xx.net] >>705 それな > OSプログラムしてるとレジスタ内容をメモリに載せるなんて普通にあることなんだが。 何でいきなり一人だけ見当ハズレなこと言い出したのかだけでも説明してほしいわ
724 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 16:38:42.56 ID:XGfxQXO+.net] >>701 Rustはインラインasmできるので好きなレジスタと好きな変数(メモリ)の行き来演算できるしRustだけでOSも書ける
725 名前:デフォルトの名無しさん [2021/10/15(金) 17:41:49.92 ID:W8XYkXKH.net] >>710 どうせunsafeなんだろ
726 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 18:11:50.56 ID:rb+Oscx7.net] 寒色は人権すらないからな
727 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 18:54:33.37 ID:0qD/Pqit.net] >>711 そりゃアセンブリですから safeにするには不変条件を満たすように自分でやらなきゃいけない
728 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 18:55:28.40 ID:IFdb5cTy.net] Rust? 人気らしいね、でもオイラやらないよ Cは嫌いだし、その後釜狙いの言語はどうせ肌に合わないさ 大半の人には必要ない言語だよね、だからオイラGoをやるよ
729 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 18:58:20.72 ID:WKIFTMdH.net] GoのほうがよっぽどCの後釜感あるがな GCのあるCという感じ
730 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 19:22:21.57 ID:PoOS8yLC.net] >>711 unsafeを誤解しているようだけど CやC++と同じ状況すなわちその部分のメモリ安全性は自己管理となるだけ だから論理的に安全な操作でそれがローカルに閉じ込められて他に影響を及ぼさないならば使われうる 例えば標準ライブラリのVecもその内部実装の一部でunsafeが使われているが我々はVecを安全に使うことができる >>715 つまりGoはCやC++の代替になれない
731 名前:デフォルトの名無しさん [2021/10/15(金) 19:27:43.08 ID:vEXHgFWD.net] rustの強みである静的メモリ安全性っていうのが活かせてないやんって意味で言ったんやけど cやc++と同じ状況ならむしろrustよりcやc++使うよね?
732 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 19:36:00.75 ID:sYZbhEbz.net] 量の概念がないやつが定期的に現れるな コード全域がunaafeなのと局所的なのは全然違うでしょ
733 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 19:46:42.29 ID:PoOS8yLC.net] >>717 例えばVecは実装内部でunsafeを用いているが Vecはメモリ安全性を保証する そしてVecを用いたプログラムもRustコンパイラが通ればメモリ安全性が保証される
734 名前:デフォルトの名無しさん [2021/10/15(金) 19:48:51.64 ID:eqKsqNtm.net] それならC++も同じでは?
735 名前:デフォルトの名無しさん [2021/10/15(金) 19:49:28.65 ID:OmwX7nxr.net] >>719 unsafeなのにメモリ安全性どうやって保証してるの?
736 名前:デフォルトの名無しさん [2021/10/15(金) 19:52:54.07 ID:eqKsqNtm.net] C++の場合は、vector自身がメモリーの所有権を持ってるので安全性が保障されるんだけど。
737 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 20:08:04.69 ID:PoOS8yLC.net] >>721 え?何を言ってるの? Vecに限らずRustの各型を含めた標準ライブラリの内部はもちろんunsafeだらけだけど 論理的に安全な操作のみ、かつ、内部に閉じ込められていて外部に影響を及ぼさないもののみ だからそれら型を含めた標準ライブラリを我々は安全に使うことができる そしてそららを用いた我々のプログラムはコンパイラが通ればメモリ安全性を保証される
738 名前:デフォルトの名無しさん [2021/10/15(金) 20:14:36.90 ID:eqKsqNtm.net] >>723 じゃあC++と変わりませんね。
739 名前:デフォルトの名無しさん [2021/10/15(金) 20:15:19.52 ID:I/84Z1Ml.net] >>723 だからアスペか? 論理的に安全な操作のみ、かつ、内部に閉じ込められていて外部に影響を及ぼさないってことをどうやって保証してるのか聞いてんだけど? 国会の答弁みたいな返答やめろよ というか外部にメモリ及ぼさないはメモリ安全性が保たれるの必要条件じゃないんだけど
740 名前:デフォルトの名無しさん [2021/10/15(金) 20:15:56.65 ID:I/84Z1Ml.net] 外部にメモリ及ぼさないじゃなくて外部に影響及ぼさないだった
741 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 20:21:27.95
] [ここ壊れてます]
742 名前: ID:PoOS8yLC.net mailto: >>724 C++はコンパイルが通ってもメモリ安全性は保証されません Rustはコンパイラが通ればメモリ安全性が保証されます 全く異なります >>725 論理的にそれらを満たす操作かどうかです Rustコンパイラが通ればメモリ安全性を保証するかどうかも論理的に基づいて保証されます [] [ここ壊れてます]
743 名前:デフォルトの名無しさん [2021/10/15(金) 20:33:33.14 ID:WHarWmnu.net] >>727 メモリ安全性を保証することを諦めればコンパイル通るのは当然だよね? こんな基本的なこともわからないんですか?
744 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 20:36:47.57 ID:jQ7TSjOD.net] Cしか知らない人ってプログラミング言語の仕様とコンピュータのアーキテクチャが区別できないってマ? 型理論も知らないってマ?
745 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 20:40:52.58 ID:PoOS8yLC.net] >>728 その通りでC++はコンパイルが通ってもメモリ安全性が保証されない言語 一方でRustはコンパイルが通ればメモリ安全性が保証される言語
746 名前:デフォルトの名無しさん [2021/10/15(金) 20:50:24.31 ID:LC/Ahxji.net] >>730 >unsafeを誤解しているようだけど >CやC++と同じ状況すなわちその部分の>メモリ安全性は自己管理となるだけ って自分で言ってるよね?自分の過去の発言と言ってること矛盾してない? rustのunsafeはメモリ安全性を保証することを諦めてるって言いたかったようだけど今は言ってること無茶苦茶じゃない?
747 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 20:51:16.86 ID:U2SV1SiG.net] >>722 これが一般的なC++erの認識だとしたら恐ろしいな
748 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 20:58:34.88 ID:NxDOUPls.net] unsafeなコードが周りを滅茶滅茶にしない保証は無いよ
749 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 21:01:02.97 ID:NxDOUPls.net] unsafeを使った場合の安全性の保証を機械的にやりたければ↓みたいなので契約プログラミングする手はあるね https://crates.io/crates/contracts
750 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 21:10:23.11 ID:PoOS8yLC.net] >>731 もちろんRustの標準ライブラリの実装内部には多数の細かい小さなunsafeがあってその部分はコンパイラによるメモリ安全性保証の範囲外 それそれの内部ローカルのunsafe使用が論理的にメモリ安全であるか否かの保証はコンパイラではなく人間が行ないunsafeはそのためにある その上でRustコンパイラはプログラム全体のメモリ安全性を保証する
751 名前:デフォルトの名無しさん [2021/10/15(金) 21:17:10.00 ID:Ue2FksZS.net] >>735 人間がどうやって行うの?
752 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 21:31:51.20 ID:XGfxQXO+.net] 話は簡単だ C/C++はプログラム全てがRustのunsafe状態 つまりC/C++はプログラム全てを人間がメモリ安全であると保証しなければならないが人間なので複雑化するとミスも生じる GAFAM各社はメモリ安全に関するバグが全く減らずセキュリティ脆弱性の多くがこの問題に起因することに気付いた そこでコンパイラがメモリ安全であると保証するRustを採用して少しずつC/C++から移行させていってる段階
753 名前:デフォルトの名無しさん [2021/10/15(金) 21:34:04.93 ID:OlLYCHFC.net] unsafe blockはマーが全力で頑張ります!ゾーンだからな アルゴリズムにおいてあるアルゴリズムが正当であると判定するアルゴリズムは存在しないんだからラストコンパライでも完全なセーフティは保証は出来ないけどな ただ完全ではないものの他の注意すべき所をランコンに任せてunsafe部にヒューマンリソース限定出来るのはc++を遥かに優れた点よね(´・ω・`)
754 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 21:39:33.56 ID:NxDOUPls.net] 布教しようとしなくたっていいんだよ めんどくせえから
755 名前:デフォルトの名無しさん [2021/10/15(金) 21:42:55.26 ID:eqKsqNtm.net] >>737 GAFAがその体たらくとは信じがたいけど、resource管理は所有権ベースでほぼ解決するし、逆に所有権以外で解決することは出来ないと思う。
756 名前:デフォルトの名無しさん [2021/10/15(金) 21:45:54.09 ID:kEafjbCd.net] >>738 チューリングマシンの停止性問題のこと言ってるんだろうけど違うよ あるアルゴリズムじゃなくて任意のね 「あるプログラムが正当であると判定するプログラムは存在しない」じゃなくて「任意のプログラムを正当であると判定するプログラムは存在しない」が正しい これが5chクオリティか
757 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 21:58:02.76 ID:rb+Oscx7.net] Rustコンパイラによるメモリ安全性の保証は信頼してても、unsafe使ってる標準ライブラリを信頼しない話おもしろいね。 実際に問題なく動いてるんだから仕様を信頼すればいいのに。
758 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 22:06:00.13 ID:PoOS8yLC.net] >>742 人間が局所的に注力すれば済むのがRust 人間がプログラム全般に注力しなければならず破綻したのがCとC++
759 名前:デフォルトの名無しさん [2021/10/15(金) 22:07:41.72 ID:OlLYCHFC.net] >>741 うーんまぁ日本語で論理学考える事なんてあんましないから間違えてるのかもしれんが あるアルゴリズム、ある整数等々で俺はある集合(=アルゴリズム全体で構成される集合)の元の任意性を表してんたんだけどな(´・ω・`)
760 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 22:11:36.31 ID:wjdlJ99Z.net] >>743 勝手に破綻したことにするのやめな? そういうとこやぞお前マジ
761 名前:デフォルトの名無しさん [2021/10/15(金) 22:18:09.07 ID:JTaIEN+o.net] >>744 その言い訳は厳しいよ まあワイもまともに勉強するまでもそこあたりあやふやだったしそんな気にすんなや
762 名前:デフォルトの名無しさん mailto:sage [2021/10/15(金) 22:39:44.83 ID:XGfxQXO+.net] >>740 C/C++に限界を感じたGAFAMたち大手IT企業がRustに結集 特定の言語がIT業界を挙げて支持されるのは初めて プログラミング言語「Rust」のための「Rust Foundation」設立 -- AWS(Amazon)、Microsoft、Google、Mozilla、Huaweiが創設 https://japan.zdnet.com/article/35166267/ Facebookが「Rust Foundation」に参加 https://japan.zdnet.com/article/35170192/
763 名前:デフォルトの名無しさん [2021/10/16(土) 00:08:25.70 ID:dPfgeqZY.net] >>717 それどこの0か100しか無い世界?
764 名前:デフォルトの名無しさん mailto:sage [2021/10/16(土) 00:34:25.94 ID:bSvFIUA3.net] C++はこれで鼻から悪魔出るから vector<int> hoge {0}; int& fuga = hoge[0]; for (size_t i = 0; i < 5; ++i) { hoge.push_back(i); } cout << fuga; } nsafeがどうたらぬ気にしてRustはこういうのが防げるってだけでもそれなりの価値はある ちなみにunsafeブロックは本当に慎重に作らないと、unsafeの外部をちょっといじっただけで鼻から悪魔が出たりする https://doc.rust-jp.rs/rust-nomicon-ja/working-with-unsafe.html unsafeブロック外のidx < arr.len()をidx <= arr.len()にしただけで死ぬ
765 名前:デフォルトの名無しさん mailto:sage [2021/10/16(土) 03:36:57.11 ID:I/G6evYm.net] unsafeなコードが1行でもあったらRustで書く意味ないと主張する人が定期的に現れるのはなぜなのか
766 名前:デフォルトの名無しさん mailto:sage [2021/10/16(土) 03:54:24.52 ID:0owCAudu.net] >>750 C++が劣ることを認めたくない人が「unsafeがあるならC++と同じだからRustの存在意義はない。」という間違った主張をしてるみたい
767 名前:デフォルトの名無しさん mailto:sage [2021/10/16(土) 04:04:47.91 ID:4kIP2zxZ.net] C++との対決は別の専用スレがあるのでそっち使ってくださいね
768 名前:デフォルトの名無しさん mailto:sage [2021/10/16(土) 04:11:16.75 ID:0owCAudu.net] >>752 同感 C++な人はここでやらずに 向こうの専用スレでやってほしい C++ vs Rust https://mevius.5ch.net/test/read.cgi/tech/1619219089/
769 名前:いつもの光景 [2021/10/16(土) 07:19:55.59 ID:VQLpYdr0.net] Vec型の質問に高卒が答える ↓ 当然の如く高卒がバカにされる ↓ 高卒発狂 ↓ パソコンがどうの、C++がどうの、いつもの大先生問答に発展
770 名前:デフォルトの名無しさん [2021/10/16(土) 09:07:15.06 ID:GnSu5gfs.net] >>749 ちなみになんでこれで悪魔がでるんですか? 無学ですみません
771 名前:デフォルトの名無しさん [2021/10/16(土) 09:21:09.42 ID:wH7tzS3T.net] >>755 fugaがhogeのメモリ参照を取った後にhoge.push_back()でデータを追加している。 データ追加ではhogeの内部で確保していたメモリ領域が足りなくなると 新しいアドレスに確保しなおす(元の領域は開放する)ので、 fugaが指しているアドレスはアクセスしてはいけない領域になってる。(ダングリングポインタ) その状態でcoutでfugaを使ってるから。
772 名前:デフォルトの名無しさん [2021/10/16(土) 09:48:04.61 ID:GnSu5gfs.net] >>756 なるほど ダングリングポインタになっているんですね 教えてくださってありがとうございます
773 名前:デフォルトの名無しさん mailto:sage [2021/10/16(土) 10:29:54.02 ID:N8k1BZc2.net] unsafeなtraitとそうでない通常のtraitってどう違うんでしょうか implにunsafeって書かないといけない点以外で
774 名前:デフォルトの名無しさん mailto:sage [2021/10/16(土) 12:13:05.40 ID:MVC0A82Z.net] バカは実際にバグが起きるかどうかを考えてなくて バグを誰かのせいにできるかどうかしか考えてないんだろ。 だからこんなしょーもないものが持て囃されるってわけだ。
775 名前:デフォルトの名無しさん mailto:sage [2021/10/16(土) 13:08:52.57 ID:xy6guhnI.net] 東アジア圏は原因の究明と再発防止より責任の追及と処罰を優先する文化だからな 気をつければ問題ないみたいな精神論が平気で唱えられるのも同様 システム工学先進国のアメリカあたりと比べたらかなり後れている
776 名前:デフォルトの名無しさん [2021/10/16(土) 20:42:26.55 ID:jYqji68p.net] それは東アジア人の性質ってか東朝鮮の性質だろ(´・ω・`)
777 名前:デフォルトの名無しさん mailto:sage [2021/10/17(日) 12:48:28.83 ID:5UKSiAtl.net] CargoでC/C++のコードをビルドするときにヘッダファイル等の依存関係って何処まで面倒を見てくれるんだろ? 自分で全部記述しないとダメなのか、自動的に追跡してくれるのか・・・ ググってもCのコードも一緒にビルドできます以上の情報が見つからん
778 名前:デフォルトの名無しさん mailto:sage [2021/10/18(月) 10:43:24.73 ID:oPyph5kC.net] 面倒見るわけねーじゃん。 ヘッダーファイル依存をまともに解決しようと思うと、ビルド速度に影響がモロに出る。 解決するには暗黙のキャッシュ使うことになって問題が起きやすくなる。
779 名前:デフォルトの名無しさん mailto:sage [2021/10/18(月) 11:14:38.10 ID:jL9+j5XP.net] >>762 一番基本的なやり方だとcc crate使うことになると思うけど このやり方だとヘッダやライブラリは自分で指定する必要ある 使ったことないけどpkg_config crateとか使えば多少は楽になるのかもしれない C/C++コードが別プロジェクトからの流用ならそのプロジェクトのビルドツールに乗っかるのが楽かも 例えば cmake や autocfg/autotools といった crate はあるみたい
780 名前:デフォルトの名無しさん mailto:sage [2021/10/18(月) 12:25:26.72 ID:cow76Y8p.net] >>749 vectorじゃなくて、listを使うと大丈夫。 C言語は、もともと、linked list が代名詞の様な言語。 それを引き継いだC++もstd::listこそが主役。 ところが、stroustrupがvectorを推奨するから混乱してる。
781 名前:デフォルトの名無しさん mailto:sage [2021/10/18(月) 12:39:56.60 ID:jL9+j5XP.net] >>765 それは初耳。誰が linked list が C の代名詞と言っているの? 経験上は配列使うことの方が多いように思うんだが
782 名前:デフォルトの名無しさん mailto:sage [2021/10/18(月) 15:20:57.34 ID:gU1bKDav.net] >>765 std::listはn番目アクセス遅いよ だからstd::vectorを利用するケースが圧倒的に多い
783 名前:デフォルトの名無しさん mailto:sage [2021/10/18(月) 15:29:58.26 ID:+iNX7XVA.net] listそんな使うことないやろ。挿入と削除が早いだけやんけ。何が言いたかったんだか。
784 名前:デフォルトの名無しさん mailto:sage [2021/10/18(月) 21:23:43.42 ID:292fwFlx.net] 確かにlistはあまり使った記憶がないなー キャッシュのミスヒットを考えると、 vectorでリロケートした方が速い場合もあるし
785 名前:デフォルトの名無しさん mailto:sage [2021/10/18(月) 23:37:04.31 ID:Qq+Ry0m8.net] listは敵キャラの弾幕なんかの座標管理なんかに使える
786 名前:デフォルトの名無しさん mailto:sage [2021/10/19(火) 12:19:23.96 ID:5XPa2/LH.net] ほぼcだよねこれ。 https://github.com/Rust-for-Linux/linux
787 名前:デフォルトの名無しさん mailto:sage [2021/10/19(火) 12:22:25.90 ID:GgDBkr4o.net] (Cで書かれてるLinuxカーネルのフォークなんだから当たり前やろ)
788 名前:デフォルトの名無しさん mailto:sage [2021/10/19(火) 15:27:28.34 ID:0LtRxxZs.net] そもそも全部書き直すならLinuxを冠する意味が・・・
789 名前:デフォルトの名無しさん mailto:sage [2021/10/19(火) 16:06:41.74 ID:9axoCOPN.net] 何で? (全部書き直すなど誰も言ってないけど理由を聞いてみたい)
790 名前:デフォルトの名無しさん mailto:sage [2021/10/19(火) 16:12:52.85 ID:473S9WY0.net] うん、それ、RustでLinuxを作り直してるんじゃなくて、元々のLinuxをベースにして、新しい機能をRustで開発しようとしているプロジェクトでしょ
791 名前:デフォルトの名無しさん [2021/10/19(火) 18:28:24.83 ID:lJqU9SJa.net] 嘘つき
792 名前:デフォルトの名無しさん [2021/10/19(火) 18:57:21.27 ID:C9DkQou5.net] 日本語不自由どころか 頭が不自由だと拝察します
793 名前:デフォルトの名無しさん mailto:sage [2021/10/19(火) 18:58:18.97 ID:bh+xrreW.net] panicは無事無くなったんかな。
794 名前:デフォルトの名無しさん mailto:sage [2021/10/19(火) 19:07:22.39 ID:0VPrblkh.net] 彡 ⌒ ミ (´・ω・`) 頭が不自由という言葉が引っかかったので飛んできました
795 名前:デフォルトの名無しさん [2021/10/19(火) 19:29:57.38 ID:k3wLx80J.net] 彡 ⌒ ミ (´・ω・`) 飛ぶとかカッパの風上にも置けんな、泳げや
796 名前:デフォルトの名無しさん mailto:sage [2021/10/19(火) 20:33:01.03 ID:q+n6NKoj.net] >>778 アロケーターのpanicのことなら7月に出たパッチでなくなったみたい https://lore.kernel.org/lkml/20210704202756.29107-1-ojeda@kernel.org/
797 名前:デフォルトの名無しさん mailto:sage [2021/10/19(火) 20:49:57.64 ID:XSR/7M6W.net] C++erはほんとゴシップ談義が好きやな Rustスレにまでそのカルチャー持ち込まんで欲しいわ
798 名前:デフォルトの名無しさん [2021/10/19(火) 21:31:52.96 ID:3gMaYVXy.net] ペチパーと大差ないからな
799 名前:デフォルトの名無しさん mailto:sage [2021/10/20(水) 10:48:38.28 ID:kKtRU0ug.net] ターゲットも開発者も丸かぶりだからしゃあない
800 名前:デフォルトの名無しさん [2021/10/20(水) 13:23:40.75 ID:nZj/SCQk.net] で、非同期ライブラリはどれが標準になるのよ?
801 名前:デフォルトの名無しさん [2021/10/20(水) 13:24:10.28 ID:nZj/SCQk.net] で、非同期ライブラリはどれが標準になるのよ?
802 名前:デフォルトの名無しさん [2021/10/20(水) 13:29:36.31 ID:4F9a+p6K.net] tokio
803 名前:デフォルトの名無しさん [2021/10/20(水) 16:05:21.56 ID:Ojn1Tksn.net] std
804 名前:デフォルトの名無しさん [2021/10/20(水) 18:46:14.43 ID:2vbfBLJv.net] どっちでもいいけど、インターフェースは統一して欲しいな。 今のところtokioか優勢みたいね。
805 名前:デフォルトの名無しさん mailto:sage [2021/10/20(水) 21:12:16.85 ID:rAmGIrdk.net] std::sync::mpsc ってなんで send がノンブロッキングなんだろうなぁ。
806 名前:デフォルトの名無しさん mailto:sage [2021/10/20(水) 23:01:04.88 ID:Px+syONf.net] ブロッキングなSenderがほしいならchannel_sync使うんだべさ
807 名前:デフォルトの名無しさん [2021/10/20(水) 23:32:51.88 ID:4F9a+p6K.net] ブロッキングとかノンブロッキングとか何度か解説読んだ気がするけど意味がわからないわ
808 名前:デフォルトの名無しさん [2021/10/21(木) 00:05:01.15 ID:5bux1k1I.net] 迷惑な香具師だな
809 名前:デフォルトの名無しさん mailto:sage [2021/10/21(木) 02:48:53.14 ID:rcBT1TlJ.net] おまいら mut のことを何て呼んでる? 俺は心の中でムットと呼んでいる
810 名前:デフォルトの名無しさん mailto:sage [2021/10/21(木) 02:53:24.97 ID:4380fmPV.net] ミュータブルの略なので……
811 名前:デフォルトの名無しさん mailto:sage [2021/10/21(木) 03:47:37.11 ID:mWga6xPa.net] インテジャーはイント キャラクターはチャー なんだから、ムットでも何でも好きに呼べばよろし ちなみに俺は心の中でムトゥと踊る^H^H呼んでる
812 名前:デフォルトの名無しさん mailto:sage [2021/10/21(木) 08:50:47.46 ID:rE4toNa0.net] マッだろjk
813 名前:デフォルトの名無しさん mailto:sage [2021/10/21(木) 08:54:53.70 ID:NOaHdDiV.net] マットな
814 名前:デフォルトの名無しさん mailto:sage [2021/10/21(木) 11:02:50.76 ID:s+STdMnX.net] cv::Mat は?
815 名前:デフォルトの名無しさん [2021/10/21(木) 13:03:22.69 ID:rHBxJh+b.net] >>799 メアット
816 名前:デフォルトの名無しさん mailto:sage [2021/10/21(木) 13:17:43.38 ID:rE4toNa0.net] メッ
817 名前:デフォルトの名無しさん mailto:sage [2021/10/21(木) 15:58:29.41 ID:X5IbXF0A.net] そんなくだらない疑問より誰か>>758 に答えてくれませんでしょうか
818 名前:デフォルトの名無しさん mailto:sage [2021/10/21(木) 16:23:52.35 ID:iSzsEmw9.net] >>802 implにunsafeって書かないといけないのと同じことだけど implを書くやつが要求されてるsafetyルールを担保しないといけない そのためのマーカー
819 名前:デフォルトの名無しさん [2021/10/21(木) 16:35:52.56 ID:wNducfW7.net] うんこすれっど
820 名前:デフォルトの名無しさん mailto:sage [2021/10/21(木) 19:56:22.82 ID:wPmlSLSw.net] >>791 sync_channelってのがあるのか。ありがと。 ちゃんとランデブーもできるって書いてあるな。
821 名前:デフォルトの名無しさん mailto:sage [2021/10/23(土) 00:54:23.67 ID:pgS4Ah89.net] Rust 1.56.0 リリース! https://tech-blog.optim.co.jp/entry/2021/10/22/080000
822 名前:デフォルトの名無しさん mailto:sage [2021/10/23(土) 01:45:44.26 ID:BVy1/we8.net] let x = f64::cos(3.14); みたいなのをf64::を省略して書きたいのですがどうすればよいですか? use f64::cos; みたいなことはダメなようです
823 名前:デフォルトの名無しさん mailto:sage [2021/10/23(土) 12:44:59.32 ID:rv17aNSC.net] 1回はf64と言わないと伝わらないので let p = 3.14_f64; let x = p.cos();
824 名前:デフォルトの名無しさん mailto:sage [2021/10/23(土) 14:40:08.49 ID:BVy1/we8.net] すみません、p.cos()の記法がなんかイヤでcos(p)みたいな記法をしたいってことでした
825 名前:デフォルトの名無しさん [2021/10/23(土) 18:48:04.65 ID:/3ucisXu.net] use f64 でだめなら無理じゃね
826 名前:デフォルトの名無しさん mailto:sage [2021/10/23(土) 18:52:41.89 ID:qtW8jcI5.net] modなら確かにuseで省略できるけど Box::newのBox::を省略したいみたいな話だしなあ
827 名前:デフォルトの名無しさん mailto:sage [2021/10/23(土) 18:55:33.73 ID:qhVW7VS5.net] fn cos(x: f64) -> f64 { f64::cos(x) } cos(3.14) 素直にp.cos()のほうがいいとは思う
828 名前:デフォルトの名無しさん mailto:sage [2021/10/23(土) 18:55:43.78 ID:rVbtEKl1.net] let cos = f64::cos; ならいける https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=3c7b96b61723e46d132c9e0f2d46911b
829 名前:デフォルトの名無しさん [2021/10/23(土) 19:43:20.47 ID:2qA+vCFq.net] fn main() { println!("{}", cos(&32)); println!("{}", cos(&4.5)) } trait GetDouble { fn get_double(&self) -> f64; } fn cos(num: &dyn GetDouble) -> f64 { f64::cos(num.get_double()) } impl GetDouble for f64 { fn get_double(&self) -> f64 { *self } } impl GetDouble for i32 { fn get_double(&self) -> f64 { f64::from(*self) } } https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=cb0e5606622069ca33b0ef0971fa94b4 これでいこう
830 名前:デフォルトの名無しさん mailto:sage [2021/10/23(土) 20:42:27.27 ID:qhVW7VS5.net] ジェネリックにしたいならIntoでいいんじゃないかな fn cos(x: impl Into<f64>) -> f64 { f64::cos(x.into()) }
831 名前:デフォルトの名無しさん mailto:sage [2021/10/23(土) 20:49:05.66 ID:+aPgOjd/.net] ジェネリックにしたいなら戻り値も引数に合わせたいのでは num_traits::Float::cos など使うべき https://docs.rs/num-traits/0.2.14/num_traits/float/trait.Float.html#tymethod.cos
832 名前:デフォルトの名無しさん mailto:sage [2021/10/24(日) 14:23:12.50 ID:eQqSgpa/.net] 文法でrustとc++/cが似ているって言うやつは何をもって似ていると言っているだろう ムーブセマンティクスがデフォだし、classはない、for文はイテレータだし、変数と関数の宣言の
833 名前:痰「がはっきりしているし 何よりも型は前置じゃないし [] [ここ壊れてます]
834 名前:デフォルトの名無しさん mailto:sage [2021/10/24(日) 14:52:08.66 ID:spG6Bthy.net] C++とスクリプト言語ぐらいしか知らないんじゃないの?
835 名前:デフォルトの名無しさん mailto:sage [2021/10/24(日) 14:55:21.00 ID:lUSERxty.net] >>817 誰がもなにもオフィシャルなドキュメントでC++に似せたと言っている 型引数が<>だったりブロックが{}だったりそういうレベルで似てると言っている
836 名前:デフォルトの名無しさん mailto:sage [2021/10/24(日) 14:56:01.04 ID:lUSERxty.net] C/C++というよりC familyに似せたと言っていたからちょっとニュアンスは違ってくるか
837 名前:デフォルトの名無しさん mailto:sage [2021/10/24(日) 15:13:22.96 ID:eQqSgpa/.net] >>819 ソースをくれ 公式で構文を似せたとか言っていないと思うが C++: references, RAII, smart pointers, move semantics, monomorphization, memory model https://doc.rust-lang.org/reference/influences.html
838 名前:デフォルトの名無しさん mailto:sage [2021/10/24(日) 15:37:41.12 ID:IF6Ria+p.net] 型名がintならc++ぽいというのはなんか違うんだよね ->とか<<<とか気持ち悪いことをし始めたらc++感が出てくる
839 名前:デフォルトの名無しさん mailto:sage [2021/10/24(日) 15:38:30.82 ID:lUSERxty.net] >>821 web.archive.org/web/20150401014855/http://doc.rust-lang.org/nightly/intro.html > you may find the syntax easier if you've used a "curly brace" programming language before, like C or JavaScript 確かに似せたとまでは言ってなかった generics の angle bracket についてはコアメンバーが言及してるしC++の影響受けてると言って良いと思う https://old.reddit.com/r/rust/comments/6l9mpe/minor_rant_i_wish_rust_had_gone_with_square/
840 名前:デフォルトの名無しさん mailto:sage [2021/10/24(日) 15:44:23.48 ID:zP2CpnNP.net] C++ iostream の << 演算子をパクらなかったのは、やっぱりあれが失敗作だからだよね
841 名前:デフォルトの名無しさん mailto:sage [2021/10/24(日) 15:46:45.70 ID:IF6Ria+p.net] >>823 thx、ソースまで探してくれてありがとう 個人的にはC++を感じるというエモーション(?)がどこなのかを聞きたかった
842 名前:デフォルトの名無しさん [2021/10/24(日) 16:28:47.34 ID:snvhdKAH.net] よくある質問 RustはLLVMの上に構築されており、LLVMから見てClangっぽく見えるように頑張っているので、LLVMの 性能が向上したらRustの性能向上にもつながります。 https://prev.rust-lang.org/ja-JP/faq.html
843 名前:デフォルトの名無しさん mailto:sage [2021/10/24(日) 16:53:50.00 ID:RHSebvs6.net] 見た目はC++に似ているかも知れないけどML系列の方が近いんじゃない? コンパイラがうるさいところとか「コンパイルが通れば大体動く」という感触はHaskellに近い Vecに限定したくないなあとか関数に分けると型表記が面倒だなあとかはHaskellには無かったけど
844 名前:デフォルトの名無しさん [2021/10/24(日) 17:08:25.09 ID:6Jy8RsQO.net] move semanticsとかcall by ref(not call by val in terms of ptr)とかは他のスクリプトではないの多いしな(rakuぐらいじゃね?) 糞みたいに面倒なbig fiveとか書いて来てるc++ちゃんと理解してる連中はrustの基本部分の理解はかなり早そう 記法は全然似てないてかerror handlerの部分とか全くの別物になってるしな 比較的若いgoとかktとかの方が書いててなんとなく似てる様な気もする(´・ω・`)
845 名前:デフォルトの名無しさん mailto:sage [2021/10/24(日) 17:32:03.31 ID:spG6Bthy.net] もう長いことC++書いてないけど、考えれば考えるほどC++つらいわ。昔の自分はよく書いてたな
846 名前:デフォルトの名無しさん mailto:sage [2021/10/24(日) 17:59:25.66 ID:tj18qr6S.net] 本当はMLが好きな人がMozillaでC++書かされるのに疲れた結果生まれた言語なのでMLやC++の要素を併せ持つのは必然
847 名前:デフォルトの名無しさん mailto:sage [2021/10/24(日) 20:02:44.06 ID:WKsYUqIz.net] >>828 GoやKotlinに似てたらc系列ぐらいの雑さでしょ
848 名前:デフォルトの名無しさん [2021/10/24(日) 21:17:24.37 ID:8hWi5KuQ.net] ChromeよりMozillaの方が性能良いことが、Rustを使うべきである証明になってるのでは?
849 名前:デフォルトの名無しさん mailto:sage [2021/10/24(日) 22:01:13.83 ID:zrg/m0jp.net] 流石に乱暴すぎる
850 名前:デフォルトの名無しさん mailto:sage [2021/10/24(日) 22:21:07.85 ID:HVo+cqVA.net] Chrome も Rust 使おうみたいな話なかったっけ
851 名前:デフォルトの名無しさん mailto:sage [2021/10/24(日) 22:21:39.42 ID:spG6Bthy.net] セルフホストされるまではOCamlで書かれてたので、Chromeより性能の良いMozillaを作ったRustを最初に実装したOCamlを使うべき証明になってるのでは?
852 名前:デフォルトの名無しさん [2021/10/24(日) 22:28:24.77 ID:P21IrDZK.net] chromeユーザーだけどfirefoxの方が性能いいってマジなんか?
853 名前:デフォルトの名無しさん mailto:sage [2021/10/24(日) 22:49:18.90 ID:IF6Ria+p.net] https://amethyst.rs/posts/amethyst--starting-fresh アメジストが死んだ... エンダァァァァァァァァァァァァァイヤァァァァァァ rustのゲームエンジンはbevy一強になるのか
854 名前:デフォルトの名無しさん mailto:sage [2021/10/24(日) 23:27:29.19 ID:q0uVfP5C.net] GUIのツールキットはよ(`・ω・´ )
855 名前:デフォルトの名無しさん mailto:sage [2021/10/24(日) 23:30:13.19 ID:zP2CpnNP.net] ちゃんとリリースまでたどり着いたrustのゲームってあるの?
856 名前:デフォルトの名無しさん mailto:sage [2021/10/24(日) 23:47:38.31 ID:IF6Ria+p.net] >>838 icedじゃだめなん? >>839 今のところない 試作を含むならネット上に転がっているよ bevyね...レンダラーがwgpuだからね 現状はレイトレーシングとか無理 ゲームエンジンに挑戦するいい機会かも
857 名前:デフォルトの名無しさん mailto:sage [2021/10/24(日) 23:55:17.08 ID:J36a/Om9.net] >>824 C++はシフト演算子をなぜ入出力に使いまわそうとしたのか未だに理解できない 見にくく&わかりにくくなってる
858 名前:デフォルトの名無しさん [2021/10/25(月) 00:09:38.02 ID:dMwiicPm.net] >>841 shellのリダイレクトに似てると思ったからだろ
859 名前:デフォルトの名無しさん mailto:sage [2021/10/25(月) 00:21:35.96 ID:dRHq7DJG.net] >>841 当時の C++ には可変長引数を現代的な型システムの枠組みで扱う方法がなかった。 (C++11 からは variadic template がある。 これも今となっては現代的と言えるかどうか……。) 新しいオブジェクトを追加したときにオーバーロードが可能である必要など の諸々の事情が積み重なって演算子オーバーロードの仕組みを使うのが妥当という結論になり、 オーバーロード可能な演算子の中で比較的それらしく見えるのが << だったという経緯。 記法だけなら printf で不満は出なかっただろうけど、 printf (というか C の可変長引数の仕組み) は型システム的な保護が全然できないぶっ壊れなので それを是とすることも出来なかった。 (廃止もしなかったけど。) 良くはないが他にどうにも出来なかったんだよ。
860 名前:デフォルトの名無しさん mailto:sage [2021/10/25(月) 00:30:55.79 ID:dRHq7DJG.net] 歴史が長くなるとしょうもない事情の積み重ねでグダグダになるのもよくあること。 Rust もいずれはそうなる。 そしてそのときは新しい何かで置き換えられるんだよ。 でも Rust の場合は Edition という区切りで新しい Rust 自身で置き換えつつ 過去の Rust とも共存することを最初から意図したデザインにしているので 比較的長く維持されるんじゃないかな。
861 名前:デフォルトの名無しさん mailto:sage [2021/10/25(月) 10:06:46.78 ID:vPVmdF1Z.net] 実際、型安全であるiostreamよりprintfのがよっぽどマシって議論はある。 しょーもない技術要素よりも視認性のがよっぽど大事だったりするわけで。
862 名前:デフォルトの名無しさん mailto:sage [2021/10/25(月) 11:11:20.41 ID:DCgj0YIV.net] >>840 iced日本語入力できなくない?
863 名前:デフォルトの名無しさん [2021/10/25(月) 11:14:28.05 ID:vmRZrQEp.net] >>827 >「コンパイルが通れば大体動く」という感触はHaskellに近い C/C++でも「コンパイルが通れば大体動く」けど Haskellはコンパイル時にアルゴリズムミスまでチェックしてくれるのか?
864 名前:デフォルトの名無しさん [2021/10/25(月) 11:32:11.39 ID:dMwiicPm.net] 単にHaskellはC/C++よりも型安全性の度合いが強いってこと言いたいんだろ
865 名前:デフォルトの名無しさん mailto:sage [2021/10/25(月) 11:51:09.02 ID:fl6GjyRy.net] >>846 Font読み込めば出来るっぽいよ
866 名前:デフォルトの名無しさん [2021/10/25(月) 12:13:25.40 ID:Zg5tRANc.net] >>847 アスペルガーか?
867 名前:デフォルトの名無しさん mailto:sage [2021/10/25(月) 15:20:38.75 ID:YZjFvrvy.net] Rustでゲームエンジン作ったら億万長者になれるのかな
868 名前:デフォルトの名無しさん mailto:sage [2021/10/25(月) 17:18:01.27 ID:uPCS+ug6.net] UnityやUnreal Engine並のを作れるならできるんじゃね さもなきゃプロプライエタリなエンジンなんてきょうび流行らん
869 名前:デフォルトの名無しさん mailto:sage [2021/10/25(月) 17:29:16.50 ID:SuqdiOg2.net] Rustの方が圧倒的に高速なら儲かるんじゃね? 知らんけど
870 名前:デフォルトの名無しさん mailto:sage [2021/10/25(月) 17:42:54.30 ID:dQPM/Zr0.net] C++に勝てると思ってるの?
871 名前:デフォルトの名無しさん mailto:sage [2021/10/25(月) 18:33:26.15 ID:WHGdQ2cY.net] フラッピーバードでも億稼げるんだからいけるいける
872 名前:デフォルトの名無しさん mailto:sage [2021/10/25(月) 18:38:23.54 ID:SAo0WBxS.net] もうインディー2Dゲームぐらいはリリースされてるのかと思ったけど まだなのか
873 名前:デフォルトの名無しさん mailto:sage [2021/10/25(月) 19:12:07.52 ID:rY5vWaGm.net] >>851 億万の金とリソースをかけなきゃ使い物になるエンジンなんて作れないんじゃないの? まあ、そこまでいかなくともユーザーのいる既存のツールで開発止まっているもの(MMDとか)のクローン作ればワンチャンあるかもね。
874 名前:デフォルトの名無しさん mailto:sage [2021/10/25(月) 20:03:31.88 ID:cubP7NbG.net] ゲームエンジンでボトルネックとなるような重い処理ってなんなの 描画関連が重いならGPU側処理がメインでCPUで動くプログラムは何で書いても良いのでは
875 名前:デフォルトの名無しさん [2021/10/25(月) 20:21:36.23 ID:tU+lYK+H.net] 行列計算とメモリー帯域、PS5とPCを比べれば一目瞭然。PC4-25600でさえメモリー帯域が25GB/sで デュアルチャネルで50GB/s、PS5は帯域幅218GB/s、 つまり描画が重いのではなく、CPUやGPUで行列計算した結果をメモリーへ格納したり再び取り出したりが重い。 描画だけなら4K再生できるVRAMの速度だけで終わる話
876 名前:デフォルトの名無しさん mailto:sage [2021/10/25(月) 20:24:03.79 ID:RLuxZR0I.net] >>851 儲かるかは知らんがbevy engineの作者はお賽銭で40万/月貰っているぞ
877 名前:デフォルトの名無しさん mailto:sage [2021/10/25(月) 22:52:02.92 ID:JVD00Zwu.net] ゲーム1本も出てないってそれなんかデカイ問題あるんじゃないの。 使ってみたら、あれこれ全然意味ないわ的な。
878 名前:デフォルトの名無しさん mailto:sage [2021/10/25(月) 23:04:10.31 ID:WHGdQ2cY.net] そらまあUnityとかみたいなガチゲームエンジンとかと比べたら意味ないんじゃね
879 名前:デフォルトの名無しさん mailto:sage [2021/10/26(火) 00:13:42.72 ID:T+NfAItu.net] ゲームとか組み込みと並んで過去の資産が積み上がっているところだろう 現状グラフィックAPIなどのバックエンドは全部C/C++だぞ 一朝一夕の話ではないが、取り組み続ける必要がある とりあえずコールオブデューティのTreyarchは触っているぽい
880 名前:デフォルトの名無しさん mailto:sage [2021/10/26(火) 00:19:35.84 ID:T+NfAItu.net] インディ→ue4かunity 大手→ゲームの開発スパン3-4年+ゲームエンジン開発期間 今から積極的取り組んでも公表できる成果ができるは8-10年じゃない そういえば任天堂もrust人材を募集してたよ
881 名前:デフォルトの名無しさん mailto:sage [2021/10/26(火) 09:14:11.61 ID:1uavI5d4.net] カスタムアロケータ回りがしょぼいからガチのゲームエンジン用としては現状まだきついのでは
882 名前:デフォルトの名無しさん mailto:sage [2021/10/26(火) 09:43:34.49 ID:AMOvMfiW.net] たしかにコンシューマゲーム会社なんかがRust採用を進めていく、ってのはなんかありそうだね プロダクトのプロトタイプ作成とかめっちゃあると思うんだけど、そういうのとかで、どんどん試してみて欲しい 彼らがRustコミュニティに貢献してくれるのか、っていうとなんか怪しい気はするけど
883 名前:デフォルトの名無しさん mailto:sage [2021/10/26(火) 11:03:35.61 ID:ftLfN9xo.net] 最近はマイコンもセキュリティ機能が重要視されているけど 処理系は相変わらずC/C++でRustを推進みたいな流れにはなっていない矛盾
884 名前:デフォルトの名無しさん mailto:sage [2021/10/26(火) 11:18:59.50 ID:BJDScnmh.net] そもそも組み込みで使えるrustコンパイラがないからな
885 名前:デフォルトの名無しさん mailto:sage [2021/10/26(火) 12:47:26.53 ID:hwHjfkE+.net] 限定的ながらCortex-M用のバックエンドがあるじゃん
886 名前:デフォルトの名無しさん mailto:sage [2021/10/26(火) 13:14:38.26 ID:I5hwU/3x.net] 俺のH8はどうなるんや
887 名前:デフォルトの名無しさん mailto:sage [2021/10/26(火) 14:24:23.79 ID:ZxZWHA9I.net] LLVMバックエンドがあるならなんとかできるのでは ないなら知らん
888 名前:デフォルトの名無しさん mailto:sage [2021/10/26(火) 15:31:08.95 ID:bUwN0t0N.net] >>870 RL78に乗り換えてどうぞ。LLVMバックエンドもあるよ
889 名前:デフォルトの名無しさん mailto:sage [2021/10/26(火) 15:43:31.64 ID:BNqSw8pO.net] 僕はRX-78-2からRX-78NT-1に乗り換えたよ みんなもそうしなよ
890 名前:デフォルトの名無しさん mailto:sage [2021/10/26(火) 15:50:06.56 ID:BJDScnmh.net] 嘘だと言ってよバーニィ
891 名前:デフォルトの名無しさん mailto:sage [2021/10/26(火) 15:54:33.07 ID:BJDScnmh.net] 真面目な話Green Hillsが対応したら組み込みでも大分状況変わると思うんだが なんか内部では研究してるみたいだし
892 名前:デフォルトの名無しさん mailto:sage [2021/10/26(火) 16:50:59.50 ID:BwJyZYHo.net] ルネサスは近年arm32bitとしてraファミリ出してる。h8とかsuperhな人は今すぐ乗り換えろ
893 名前:デフォルトの名無しさん mailto:sage [2021/10/26(火) 17:52:31.12 ID:9Njhbr90.net] バックエンドがある組み込み向けISAはCortex-M系、RISC-V系、RL78、AVR8あたり? >>876 RAで済むなら他社のCortex-M系マイコンでも良いんじゃね感が・・・
894 名前:デフォルトの名無しさん mailto:sage [2021/10/26(火) 20:33:41.25 ID:T+NfAItu.net] >>865 基本カスタムアロケータは自作では?
895 名前:デフォルトの名無しさん mailto:sage [2021/10/26(火) 21:43:49.66 ID:BJDScnmh.net] アロケータ自作は大げさじゃないか heaplessクレートでどうにかなるんじゃないかな オレは使ったことないけど
896 名前:デフォルトの名無しさん mailto:sage [2021/10/26(火) 21:51:14.59 ID:PDIGoDZx.net] Unityでいけるくらいならデフォルトのアロケータで十分では? jemallocとかに切り替えてもいいけど、どちらにしても自作するほどかね
897 名前:デフォルトの名無しさん [2021/10/26(火) 21:59:07.68 ID:zVG+0sad.net] うんこ
898 名前:デフォルトの名無しさん [2021/10/26(火) 22:58:46.15 ID:Fg4TonRG.net] Unity使うなら内部のGCはBoehm GCなんだからGC_MALLOC使ったほうが良いのでは? オレはRc<T>使いながらBoehmが使えるのか知らんけど
899 名前:デフォルトの名無しさん mailto:sage [2021/10/27(水) 00:00:42.78 ID:6YxZEOiV.net] 別にゲームにカスタムアロケータが必須なんてことはないと思うが UnityみたいにGCありの言語で書く場合にGCのスパイクが許容できないから 独自のメモリプールとかを書かざるを得ないのでは それともC++でもアロケータ自作してるのか?
900 名前:デフォルトの名無しさん mailto:sage [2021/10/27(水) 00:23:45.53 ID:c5Twcn5s.net] UnityってBoehm GCなんだ? それで十分動くんならRustにもGCあってもよかったんじゃない?
901 名前:デフォルトの名無しさん mailto:sage [2021/10/27(水) 00:29:03.79 ID:QIbcJ+ZF.net] ならGo使えば良くない?
902 名前:デフォルトの名無しさん [2021/10/27(水) 00:46:21.16 ID:l1Jw+QgM.net] goはboehmじゃなく2017年ごろまでtcmallocで今は派生(随分、中身が違う)してるはず
903 名前:デフォルトの名無しさん mailto:sage [2021/10/27(水) 07:18:35.73 ID:4kTRaQF8.net] Boehmてストップザ・ワールドは起こらんの?
904 名前:デフォルトの名無しさん [2021/10/27(水) 08:48:37.83 ID:NxiqMK2Z.net] Boehmってカタカナ的には何て読むの?
905 名前:デフォルトの名無しさん mailto:sage [2021/10/27(水) 09:08:54.86 ID:CWN4UblG.net] ボエヒムじゃないの?
906 名前:デフォルトの名無しさん mailto:sage [2021/10/27(水) 10:46:43.20 ID:OgmKOgHT.net] ベームかボームだろ、ボエヒムとかワロタw
907 名前:デフォルトの名無しさん mailto:sage [2021/10/27(水) 11:14:08.33 ID:7BguKBbd.net] ドラクエの呪文みたいだな
908 名前:デフォルトの名無しさん [2021/10/27(水) 11:35:17.90 ID:Ru0zcXw7.net] ドイツ語のoeは日本語ではエって転写される
909 名前:デフォルトの名無しさん mailto:sage [2021/10/27(水) 12:01:22.63 ID:dNMmh9m9.net] Phoenix
910 名前:デフォルトの名無しさん mailto:sage [2021/10/27(水) 12:11:52.89 ID:AHUxp5wd.net] 412 名前: 以下、名無しにかわりましてVIPがお送りします 投稿日: 2013/01/19(土) 21:03:25.42 ID:a2pD/tlo0 FランのFはフェニックスのFや! 例えこんなところで落ちぶれても不死鳥のごとく上流階級に返り咲くんや!! 414 名前: 以下、名無しにかわりましてVIPがお送りします 投稿日: 2013/01/19(土) 21:04:02.87 ID:dT9mn0sK0 >>412 フェニックスは「phoenix」
911 名前:デフォルトの名無しさん [2021/10/27(水) 14:01:22.92 ID:t2iD5tO8.net] cafe la boheme
912 名前:デフォルトの名無しさん [2021/10/28(木) 12:12:05.45 ID:hM84Yf/1.net] >>887 スレチだが、Boehmなので本来はSTWだけなのでUnityにGCラグが発生していたことは有名ですが、2018/12頃に インクリメンタルGCが出来て改善された。 https://blog.unity.com/technology/feature-preview-incremental-garbage-collection またUnityでゲームなどを作るときに良くやるのがGCを動かさないこと(=オブジェクトを破棄しない)で オブジェクトプールを使用して1度作ったオブジェクトをプールして置き破棄させない方法など、Unityにある 文字列比較などを使用しないなど細かい事をやる。本末転倒といえばその通り
913 名前:デフォルトの名無しさん mailto:sage [2021/10/29(金) 02:30:41.55 ID:dwfT6x3M.net] 典型的なバッドノウハウだな とはいえ日本でUnityが一番つかわれているであろう現場のモバイルゲーム開発は 昔はケータイJavaのゲーム開発やってた場合が多いのでその辺のGCバッドノウハウに慣れちゃってるという Boehmはボエーンて読んでるわ
914 名前:デフォルトの名無しさん mailto:sage [2021/10/29(金) 02:58:27.64 ID:j8WlttkF.net] oe はドイツ語の o の代替綴りとしてあてられることが多い。 つまり boehm の本来の綴りは bohm ってことね。 o はオの口の音でエという感じなので音としては中途半端で、カタカナに当てはめにくい。 ドイツ語の発音通りをあえてカタカナにするならボェーンに聞こえるんだけど、 bohm という人名は通例ではベームと表記してるね。
915 名前:デフォルトの名無しさん mailto:sage [2021/10/29(金) 02:58:48.47 ID:j8WlttkF.net] あれ? 2ch に投稿したらウムラウトが消えてる……。
916 名前:デフォルトの名無しさん mailto:sage [2021/10/29(金) 03:36:42.46 ID:Ws4Kkx5X.net] appleをアップルと記載するような文化やからね。カタカナにしてしまったら本来の発音との差異なんて気にしたらキリがない
917 名前:デフォルトの名無しさん mailto:sage [2021/10/29(金) 04:15:21.99 ID:feAEAXNj.net] 名女優のオードリー・ヘップバーンと ローマ字表記のヘボン式で有名なヘボン氏が実は同じ綴り同じ発音の同じ姓みたいなもんか
918 名前:デフォルトの名無しさん [2021/10/29(金) 05:16:40.74 ID:eAaOJvH1.net] ドイチュ語と描いてない >>898 は失格
919 名前:デフォルトの名無しさん mailto:sage [2021/10/29(金) 21:33:27.38 ID://DLIqvB.net] まじかあ、これが可能だったのかあ let v = vec![1, 2, 3]; println!("{}", v[if true { 1 } else { 2 }]);
920 名前:デフォルトの名無しさん mailto:sage [2021/10/29(金) 23:53:13.86 ID:3N24c0Lq.net] >>901 ヘボンさんは自分でも気に入って「平文」なんてハンコ 持ってたくらいだから定着しちゃったんだよなw
921 名前:デフォルトの名無しさん mailto:sage [2021/10/30(土) 00:22:25.21 ID:9U1YWI6I.net] 音韻と音声は異なる。 ある言語で同じ音だと認められる音が音韻で、 たとえば日本語だとシンブンシという言葉に表れる二個のンは実際には違う音 なのに同じ音として処理している。 (だからヘボン式ローマ字では書き分けるルールになっている。) 音韻として同じでも音声として幅はあり、そして音韻は言語に依存するもんだから、 外国語の音を転写してくるとどう頑張ったって辻褄の合わない部分は出てくる。
922 名前:デフォルトの名無しさん mailto:sage [2021/10/30(土) 01:29:07.34 ID:fDTZDMBU.net] >>901 唐鳳は上手いよな
923 名前:デフォルトの名無しさん mailto:sage [2021/10/30(土) 02:41:12.91 ID:z8LGC696.net] いつの間にか[T; N]にIntoIteratorがimplされてるな しかも興味深いことにVec等と異なり消費されないようだ 借用ルール的にはどういう扱い?
924 名前:デフォルトの名無しさん mailto:sage [2021/10/30(土) 08:30:57.45 ID:zPV0av3I.net] イテレータが理解できないやつ定期的に湧くな
925 名前:デフォルトの名無しさん [2021/10/30(土) 09:56:39.69 ID:gRDEN/XN.net] 常駐
926 名前:デフォルトの名無しさん mailto:sage [2021/10/30(土) 11:34:48.67 ID:cxTfS1zf.net] >>902 ドイちェン
927 名前:デフォルトの名無しさん mailto:sage [2021/10/30(土) 20:52:05.52 ID:/cDwb9ic.net] >>907 Rust 1.53.0で配列にIntoIteratorが実装された あと識別子に日本語も使えるようになった 配列は要素がCopyを実装しているかどうかで所有権の扱いが変わる #[derive(Debug,Clone,Copy)] struct 構造体 { 値: isize, } fn main() { let 配列 = [構造体{値:1}, 構造体{値:2}, 構造体{値:3}]; for 変数 in 配列 { println!("{:?}", 変数); } println!("{:?}", 配列[0]); } 例えばこれはコンパイルが通って動くけど 構造体のderiveのCopyを外すと 配列の所有権はfor in内部のinto_iter()で移動してしまいコンパイルが通らなくなる
928 名前:デフォルトの名無しさん [2021/10/30(土) 21:00:13.45 ID:zJlZfWf6.net] >>911 ぶっちゃけ日本語の識別子わかりやすいって思ってしまった
929 名前:デフォルトの名無しさん mailto:sage [2021/10/30(土) 22:32:29.50 ID:EbhCJ5wH.net] 日本語識別子わかりやすいんだけど入力に手間がかかるのがつらい
930 名前:デフォルトの名無しさん mailto:sage [2021/10/30(土) 23:29:17.10 ID:s2ubgEFJ.net] let v0 = vec![1, 2, 3]; let mut v1 = v0; v1.push(120); let mut v0 = vec![1, 2, 3]; let v1 = &mut v0; v1.push(120); 所有権関連で試してみてるんだけど、この二つの違いってなんなん? いまいちよくわからん 上のはmutでないvecをlet mutの変数に入れるとpushできてまうし 下のはlet mutでない変数なのに&mutでいれるとpushできてまう
931 名前:デフォルトの名無しさん mailto:sage [2021/10/30(土) 23:56:55.99 ID:cJtJXOgj.net] https://doc.rust-lang.org/rust-by-example/scope/move/mut.html
932 名前:デフォルトの名無しさん mailto:sage [2021/10/31(日) 00:40:09.42 ID:ndmOeSWD.net] >>914 それぞれpushした後にv0とv1がどうなってるか確認してみるとわかる
933 名前:デフォルトの名無しさん [2021/10/31(日) 01:41:05.72 ID:e5ZzvOAs.net] うんこ荒らすな!
934 名前:デフォルトの名無しさん [2021/10/31(日) 02:16:55.91 ID:HeT/GYnp.net] すまんがVSCode + Rust-Analyzerで勉強中なんだけどさ 数ヶ月前は変数の型が表示されていたのに、今じゃ全然表示されなくなっちゃったんだけど・・・・どうすればいいんだぜ?
935 名前:デフォルトの名無しさん mailto:sage [2021/10/31(日) 03:00:17.77 ID:9uKpC+QX.net] int * constみたいなもん 参照先のアドレスは変更不可だけどそのアドレスが指してるvectorは&mutだから変更可能
936 名前:デフォルトの名無しさん mailto:sage [2021/10/31(日) 03:02:55.52 ID:nF8ypkXG.net] >>914 他の言語での余計な知識を捨て去ってゼロから考えるとわかりやすかったよ 今回の件で関係するルールは単純でこれだけかな? 【所有権】 ・所有権を持てるのは一人だけ ・使う(=代入や関数引数も含まれる)と所有権は移動する ・ただしCopyトレイト実装型は使う時にCopyされるので所有権は移動しない 【所有権を持つ可変と非可変】 ・その変数の中身を書き換える予定があるなら変数を可変(mut)に宣言しておく ・他の変数に代入しなおせば可変か非可変か変更可能(つまりその変数を使う時の制限ヒント) 【参照(=貸出=借用)】 ・所有権が移動されたくなければ参照で貸し出す ・可変参照(&mut)の貸し出しは1人のみに参照独占で元も可変変数であること ・非可変参照(&)の貸し出しは同時に何人でも可能 ・まとめるとsingle writer or multi readers 所有権を明確にするのはメモリ自動解放のため 可変を明確にするのは並行(concurrent)/並列(parallel)での競合回避のため
937 名前:デフォルトの名無しさん [2021/10/31(日) 07:46:34.10 ID:dD8mFzoB.net] >>918 inlayHints
938 名前:デフォルトの名無しさん mailto:sage [2021/10/31(日) 09:44:05.10 ID:726CqcoT.net] 所有権を伸ばして発音すると昇龍拳みたいに聞こえる 出掛かりが無敵なところも似てる
939 名前:デフォルトの名無しさん mailto:sage [2021/10/31(日) 09:51:39.37 ID:5rE8GYET.net] ヒカヘンサンショウ
940 名前:デフォルトの名無しさん [2021/10/31(日) 13:37:02.02 ID:r7nTmIjE.net] 丁寧で優しい920を弄りたくないけど、これを読める人は914のような質問はしないね
941 名前:デフォルトの名無しさん mailto:sage [2021/10/31(日) 13:58:11.88 ID:yTUS2Zye.net] 以下の関数をジェネリックにする方法ありますか? fn is_one_two_three<A: AsRef<[isize]>>(a: A) { assert_eq!(&[1, 2, 3], a.as_ref()); } fn main() { let a = [1, 2, 3]; is_one_two_three(a); let a = vec![1, 2, 3]; is_one_two_three(a); } 配列もVecも受け取る関数でこれはコンパイルも通り動いているのですが isizeと型が決め打ちのところをジェネリックにTとしたいです どうするとよいでしょうか?
942 名前:デフォルトの名無しさん mailto:sage [2021/10/31(日) 14:34:45.61 ID:ZiqPaZpd.net] >>925 数値型を一般化する trait を使うのが普通かな。 自分で定義しても良いが num_traits::FromPrimitive を使うならこんな感じ https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=1fbd536dd6c9ea76beb20a666b085190
943 名前:デフォルトの名無しさん mailto:sage [2021/10/31(日) 16:04:00.70 ID:2p54m3kz.net] >>914 気持ちの上では他の言語と対応付けるのではなく Rust のルールで理解すべきという点で >>920 に 同意ではあるんだが、そうは言っても知っていると引っ張られるのも仕方のない話で、 入門初期では多少はしょうがないとも思う。 あえて C++ で同等のものに置き換えるとするとこんな感じかな。 #include <vector> int main(void) { { const std::vector<int> v0 = {1, 2, 3}; std::vector<int> v1 = v0; v1.push_back(120); } { std::vector<int> v0 = {1, 2, 3}; std::vector<int>* const v1 = &v0; v1->push_back(120); } } この場合は所有権の概念はあまり関係なくて メソッド呼出しの演算子が参照を自動で調整してしまうのも混乱の原因になってる気がする。 mut が何にかかっているのか見えにくい。
944 名前:デフォルトの名無しさん mailto:sage [2021/10/31(日) 16:25:11.82 ID:KIvWC7vb.net] >>927 少なくとも上は全く同等じゃない C++では表現出来ない
945 名前:デフォルトの名無しさん mailto:sage [2021/10/31(日) 16:52:46.17 ID:2p54m3kz.net] >>928 ムーブの仕組みが違うのはしょうがない。 この場合は const 性の話だと思ったから……
946 名前:デフォルトの名無しさん mailto:sage [2021/10/31(日) 17:14:21.91 ID:WrAvX4Kw.net] C++で考えるのは弊害しかないじゃん 何がしょうがないだよ
947 名前:デフォルトの名無しさん mailto:sage [2021/10/31(日) 17:47:23.34 ID:dE1SXutD.net] 弊害しかないは言いすぎ この場合mutをどこに付けると何が可変になるかの話だから C++でconstをどこに付けると何が不変になるのかを例に出すのは自然なたとえだと思いますよ
948 名前:デフォルトの名無しさん mailto:sage [2021/10/31(日) 21:58:15.04 ID:4rIS02S1.net] let mut vec0 = vec![vec![0, 2, 3]; 3]; for mut i in vec0.iter_mut() { i.push(9); } for mut i in &mut vec0 { i.push(9); } この二つのループの意味は同じ? こういう二つの書き方があるのでちょっとわかりにくい気がする
949 名前:デフォルトの名無しさん mailto:sage [2021/10/31(日) 22:14:30.87 ID:4rIS02S1.net] へー、これが通るんだ ちょっと笑った let vec0 = vec![0, 2, 3]; let mut vec0 = vec0; vec0.push(99);
950 名前:デフォルトの名無しさん [2021/10/31(日) 22:21:16.21 ID:xmsO/hLH.net] >>933 シャドーイングだから当たり前でしょ
951 名前:デフォルトの名無しさん mailto:sage [2021/10/31(日) 22:22:32.67 ID:fTPwCWVK.net] シャドーイングOKな言語でもlintが禁止してきてイラっとする
952 名前:デフォルトの名無しさん mailto:sage [2021/10/31(日) 22:31:01.48 ID:4rIS02S1.net] >>934 状態まで置き換え可能なのはおかしいような気がする せっかく不変変数にしてるのに事実上代入可能にしてることに何の意味があるんだろう
953 名前:デフォルトの名無しさん mailto:sage [2021/10/31(日) 22:44:51.38 ID:2W4wB6er.net] クソみたいな名前が増えないようにだよ
954 名前:デフォルトの名無しさん mailto:sage [2021/10/31(日) 22:57:25.82 ID:Ou5/KoYl.net] >>924 「関係するルールは単純でこれだけ」と言って関係ないものも含めて8個もルールを羅列するやつが丁寧で優しいわけがないよ
955 名前:デフォルトの名無しさん mailto:sage [2021/10/31(日) 23:04:28.74 ID:4rIS02S1.net] >>937 変数名の再利用と状態変更はちがくね? そもそも変更しないと宣言して変数をシャドーイングして変更可能にするのも疑問だけど、 まあそれは仕様だとして、それが変数名の再利用とは無関係じゃんね 再利用しない前提なんだから
956 名前:デフォルトの名無しさん mailto:sage [2021/10/31(日) 23:09:50.30 ID:59hJVDPo.net] もはや何言ってるかわからないレベル
957 名前:デフォルトの名無しさん [2021/11/01(月) 00:28:06.90 ID:lB3Z2euD.net] >>936 状態置き換えてない 新しい方の変数を参照するようにしているだけ
958 名前:デフォルトの名無しさん mailto:sage [2021/11/01(月) 00:30:02.23 ID:cNNz1tH7.net] >>932 mut i ってmut必要だっけ
959 名前:デフォルトの名無しさん mailto:sage [2021/11/01(月) 01:16:30.92 ID:FrHt6Y1+.net] >>932 > for mut i in vec0.iter_mut() { > for mut i in &mut vec0 { どちらもiは&mutになるので同じfor文になる そしてlet mut i = &mut ... と書いている時と同じく左側のmutは不要(warning)
960 名前:デフォルトの名無しさん mailto:sage [2021/11/01(月) 01:31:09.18 ID:FrHt6Y1+.net] >>925 配列もVecも受け取る関数ならば as_ref()でスライスに揃える方法だけでなく
961 名前:r> 配列もVecもそのままの型で使う方法もあり どちらもa[i]の形はIndexトレイトで使えるので例えば fn get_second_item<A: std::ops::Index<usize, Output=T>, T: Copy>(a: A) -> T { a[1] } fn main() { let a = [1.1, 2.2, 3.3]; assert_eq!(2.2, get_second_item(a)); let a = vec!["a", "b", "c"]; assert_eq!("b", get_second_item(a)); } と配列/Vec側も中身のf64/&str側もジェネリックに書ける [] [ここ壊れてます]
962 名前:デフォルトの名無しさん mailto:sage [2021/11/01(月) 08:15:24.70 ID:Qg2QcgLf.net] 背後にある考え方を説明せずにルールだけ教えても理解できないよ。 まあ、ルールに一貫したコンセプトがないんだったら「こういうものだ」と押し付けるしかないけど。
963 名前:デフォルトの名無しさん mailto:sage [2021/11/01(月) 23:13:41.76 ID:PK
] [ここ壊れてます]
964 名前:aNA1In.net mailto: 可変の場合は面倒でもmutが必要ってしたほうがわかりやすいような気がするなあ [] [ここ壊れてます]
965 名前:デフォルトの名無しさん mailto:sage [2021/11/01(月) 23:57:09.03 ID:HKf+kmzN.net] let mut p = &mut q; の左辺mutを書くとwarningが出る理由は、pはmutではなく、あくまでも&mutであるためだろう。 つまり、そこに左辺mutを書いてしまう人はきちんと理解していないという意味ではなかろうか。
966 名前:デフォルトの名無しさん mailto:sage [2021/11/02(火) 07:53:30.47 ID:eth2zNwx.net] let mut ~~はそこで定義される変数が可変(再代入可能)になるもので、 &mut ~~はそこで作成される参照が可変になる、という理解なんだけど、 どうもしっくり来てない。引数の宣言で&mutとつけるとどうなるの、とかすぐ出てこない。
967 名前:デフォルトの名無しさん mailto:sage [2021/11/02(火) 08:18:58.33 ID:gnq/E+lb.net] let mutのmutはコード生成には不要だけど&mutのmutは必要だと言う話を聞いた
968 名前:デフォルトの名無しさん [2021/11/02(火) 09:44:55.98 ID:px0qcy1y.net] 950
969 名前:デフォルトの名無しさん mailto:sage [2021/11/02(火) 11:55:17.95 ID:22+2FiF4.net] let mutのmutはbindingがmutableかどうか &mutは型が&mut Tなのかどうか Cのconst pointerとpointer to constと同じ Rustはデフォルトimmutableなのでmutableにしたい場合にのみmutで修飾 普通使わないけどパターンマッチと組み合わせると let &mut mut x = &mut y; みたいな書き方もありうる
970 名前:デフォルトの名無しさん [2021/11/03(水) 12:07:17.82 ID:gDAMFAnt.net] mutが必要ってより、for mutにfor let mutにならないことが不思議
971 名前:デフォルトの名無しさん mailto:sage [2021/11/03(水) 17:34:54.99 ID:eoGGfQG1.net] それは単にforの文法がlet不要なように設計されたってだけでは
972 名前:デフォルトの名無しさん mailto:sage [2021/11/03(水) 18:34:42.48 ID:+koatzK+.net] let パターン = ... for パターン in iter match パターン ... fn hoge(パターン: TypeName, ...) ってことやぞ
973 名前:デフォルトの名無しさん [2021/11/03(水) 19:26:40.94 ID:6uw3PT+q.net] Rustにはif let Some(3) = v {}とか、 while let Some(i) = a {}とかあり。letは不変のキーワードじゃなく 右辺に対するパターンマッチ展開で、for letがないのは、forはfor..inしかなく、Cのようなfor ;条件;の文が 存在しないためという考えらしいです。。。
974 名前:デフォルトの名無しさん mailto:sage [2021/11/04(木) 06:57:56.88 ID:9Ddr56R/.net] forで変数の初期化が要るみたいな発想になる時点でC由来の処理系に洗脳されているんじゃぁ・・・
975 名前:デフォルトの名無しさん mailto:sage [2021/11/04(木) 13:00:03.95 ID:UnTZr4yd.net] for p in v { … } は v.into_iter().for_each(|p| …) と同じ機能たけど 長いメソッドチェーンな時など敢えてforでなくfor_each使ったりも
976 名前:デフォルトの名無しさん mailto:sage [2021/11/04(木) 20:16:49.18 ID:UnTZr4yd.net] ただしfor文は値を返せないのが弱点かな イテレータならfor_eachの代わりにfoldしたりfindしたりあるいはmapやfilterなど色々処理して最後にcollectしたりと値を返せる
977 名前:デフォルトの名無しさん mailto:sage [2021/11/04(木) 20:24:42.58 ID:faLe9vBn.net] >>958 forやwhileは、そもそもループが実行されないパターンがあるので、それは無理ってなったらしい だからloopでは値を返すことができるので、loopを使うぺし
978 名前:デフォルトの名無しさん mailto:sage [2021/11/04(木) 21:17:21.49 ID:MjRPJM3Z.net] >>959 for式やwhile式がOptionを返してループ0回ならNoneで済む話ではないのでしょうか?
979 名前:デフォルトの名無しさん mailto:sage [2021/11/04(木) 21:26:55.06 ID:sNasn9tC.net] forで値を返したいとか言ってるやつまだいたのかw
980 名前:デフォルトの名無しさん mailto:sage [2021/11/04(木) 23:50:24.53 ID:faLe9vBn.net] >>960 ループ内は実行されないからNoneも返せないってことよ loopは明示的に自分でbreakするから許容 let test: = if true { 1 }; たとえば、これでtestにNoneが入るとかおかしいことになるってわかるっしょ? それと同じこと。
981 名前:デフォルトの名無しさん mailto:sage [2021/11/04(木) 23:51:56.14 ID:Cqbrs2k1.net] 実際問題としてHITUYOU
982 名前:デフォルトの名無しさん mailto:sage [2021/11/04(木) 23:52:15.61 ID:Cqbrs2k1.net] ごめん誤爆した。 実際問題として必要な場面がないだろ。
983 名前:デフォルトの名無しさん [2021/11/05(金) 08:00:41.30 ID:Q0weZe1J.net] forの話なら、これって今はどっちで書くのが一般的?ルールとして基本はHOFで書くのを やっぱり強制したいのだけど https://doc.rust-lang.org/stable/rust-by-example/fn/hof.html
984 名前:デフォルトの名無しさん mailto:sage [2021/11/05(金) 13:18:20.54 ID:/SSooQm2.net] rust現場で使ってる人は何系のシステム作ってるん?
985 名前:デフォルトの名無しさん mailto:sage [2021/11/05(金) 14:22:06.73 ID:pAK9gvBl.net] 現場で使ってる人なんていません
986 名前:デフォルトの名無しさん mailto:sage [2021/11/05(金) 14:42:52.35 ID:Z0sGs5cT.net] 求人検索をしてみても、Rust使ってるとこなんて指で数えられるぐらいしかなさそうかな
987 名前:デフォルトの名無しさん mailto:sage [2021/11/05(金) 15:22:01.85 ID:4VZvWnUi.net] とりあえずいつもの貼っておく https://www.rust-lang.org/production
988 名前:デフォルトの名無しさん mailto:sage [2021/11/05(金) 15:29:07.01 ID:ShfctMVX.net] 試験的にGoからRustに切り替え中だよ。両方ともバックエンドとフロントエンドまでやってるのでそのまま移植出来て簡単…じゃなかった インフラはサクッと終わったけど、フロントは素のWasmで実装するもGoより遥かに複雑で難解なRustでやる意味は?的な事になって vDOM系フレームワークで実装するも、Non-vDOM系のが殆どの場面で速い事が分かったのでやり直し中 で、本番環境で運用できるのか?となると最初の印象に反して「出来る」と思うね。 動かし始めて不具合が出た時に、何処がヤバいのか分からない怖さがない。 過去の資産と経験則は捨ててRustのお作法に従うようにするのが大切、下手にアレを使いたいので使い回すとかやると余計苦労する。
989 名前:デフォルトの名無しさん mailto:sage [2021/11/05(金) 19:10:07.53 ID:0gW7V402.net] >>970 もしよろしければオススメのRustフレームワークを教えてください
990 名前:デフォルトの名無しさん mailto:sage [2021/11/05(金) 20:26:36.98 ID:RvCa6Qvn.net] ちんちんぶらぶらRustすぱーと
991 名前:デフォルトの名無しさん [2021/11/05(金) 20:33:04.86 ID:JniLXeAQ.net] うちではバイトの女子大生も使ってるが Rustを使うような企業はネット求人になんか頼らんだろうね、今のところ
992 名前:デフォルトの名無しさん mailto:sage [2021/11/05(金) 21:52:24.97 ID:ShfctMVX.net] >>971 Dominator
993 名前:デフォルトの名無しさん mailto:sage [2021/11/05(金) 23:26:41.71 ID:DvmJ6O3T.net] Dominatorってこれか https://github.com/Pauan/rust-dominator virtual DOM使わずゼロコストでリアクティブか ベンチマーク見るとVue/React/Angularなどは非常に遅いんだな https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html Vanilla JSで頑張るのでなければRustでDominatorを使った方が良さそうってことか ウェブフロントエンドまでRustの時代が来るとは驚き
994 名前:デフォルトの名無しさん mailto:sage [2021/11/05(金) 23:41:27.00 ID:7Nx3lyuG.net] おもしろそうだけど、メンテが辛くなりそう。仕事でそんなん大丈夫かしら?
995 名前:デフォルトの名無しさん mailto:sage [2021/11/06(土) 01:14:13.09 ID:8rFQ20lW.net] ダメに決まってんじゃん。。無理やり使おうとしてるのが丸わかりだわ。
996 名前:デフォルトの名無しさん mailto:sage [2021/11/06(土) 01:50:27.76 ID:BsA8c5Gl.net] >>975 少くともその表に載ってるsolidってのは非vDOM系のJSフレームワークだけど… その表ではDominatorとどっちが速いですか? そしてそれはなぜですか? それを勘案しても、 Vanilla JSで頑張るのでなければRustでDominatorを使った方が良さそうってなりますか?
997 名前:デフォルトの名無しさん [2021/11/0
] [ここ壊れてます]
998 名前:6(土) 01:55:12.94 ID:eYFGObaB.net mailto: フロントエンドのwasmでrustを使う意味が分からん、assemblyscriptなんかでts変換したほうがよっぽど 人材確保も容易で速度も出そうだけど、まあ全部1つの言語に統一したいという欲望は分かるが [] [ここ壊れてます]
999 名前:デフォルトの名無しさん mailto:sage [2021/11/06(土) 08:58:19.69 ID:8rFQ20lW.net] その種の願望はいつだって失敗してるのに何回でもこだわるバカが出てくる。 ビジュアルプログラミングとかノーコード並みに愚かだわ。
1000 名前:デフォルトの名無しさん mailto:sage [2021/11/06(土) 09:42:55.78 ID:DjcFpt23.net] 夢は終わらねえ!
1001 名前:デフォルトの名無しさん mailto:sage [2021/11/06(土) 10:40:16.97 ID:YOvBnwY8.net] htmlマクロが微妙だよな。yewもしかり マクロの仕様理解して書かないといけないからwebpackみたいなコンパイラー挟んでreact,vueみたいなhtmlベースでかけたら普及進むと思う
1002 名前:デフォルトの名無しさん mailto:sage [2021/11/06(土) 10:43:29.52 ID:gG2xt4rU.net] フロントエンドはElmで書いた方がいいと思う Elmの設計をパクったRust用フレームワークよりElmそのもので書いた方がいい
1003 名前:デフォルトの名無しさん mailto:sage [2021/11/06(土) 11:32:19.13 ID:dvoeGWeX.net] >>979 WasmはもともとC/C++をブラウザのフロントエンドで使いたい願望から 始まったものだ。 意外に思うかもしれないが、C/C++を使いたい人はRustの1000倍くらい多い。
1004 名前:デフォルトの名無しさん mailto:sage [2021/11/06(土) 12:19:33.04 ID:v/Totsm8.net] >>979 AssemblyScriptはメモリ管理GC問題があるし文法が単にTSの限定サブセットに過ぎないため色々と辛すぎる そのためWebAssemblyでの使用言語調査結果もこんな状況でRustが圧勝 https://blog.scottlogic.com/ceberhardt/assets/state-of-wasm/desired-language.png >>978 Wasm⇔JSのオーバーヘッドがあるので処理が少なくほとんどDOM操作になる時だけはJSのみで書いたほうが速い (当たり前) そのためほぼDOM操作のそのベンチマークではRustフレームワークがわずか数%遅くなっているが現実には処理内容次第ですぐに逆転する >>983 Elmは型クラス(Rustではtrait)がなく例えば抽象的なイテレータも持てず色々と辛い このスレはRustにアンチな人がRustを貶めようと常駐して頑張ってるようだけど Rustを用いるのがベストな方法な場合が非常に多いよ
1005 名前:デフォルトの名無しさん [2021/11/06(土) 16:27:09.97 ID:Y613N0Im.net] もはや人類の発展はRustにかかっていると言ってもいい
1006 名前:デフォルトの名無しさん mailto:sage [2021/11/06(土) 16:30:35.71 ID:3ClRyBcI.net] Rustのお陰でハゲが治りました!
1007 名前:デフォルトの名無しさん mailto:sage [2021/11/06(土) 16:45:26.77 ID:EdJhZAmA.net] C++ドロップアウターの掃き溜まり
1008 名前:デフォルトの名無しさん mailto:sage [2021/11/06(土) 16:57:33.02 ID:5yvdtcf3.net] similar word exists: `掃き溜め` similar word exists: `吹き溜まり`
1009 名前:デフォルトの名無しさん mailto:sage [2021/11/06(土) 21:24:09.65 ID:8rFQ20lW.net] rustがベストな時が多いとかよくそういうデマを平気で流せるよね。。
1010 名前:デフォルトの名無しさん mailto:sage [2021/11/06(土) 21:39:59.60 ID:1qW/ULGd.net] シャドーイングがよくわかりません。 変数名によって中身が一意に決まらなくなることによって、安全性も下がるし並列性?も確保できなくなる気がするのですが、変数が全mutableな言語より安全性マシだしRustは関数型言語じゃないから並列性そこまで重要視してないし書き味のが大事だぜってことですか?
1011 名前:デフォルトの名無しさん mailto:sage [2021/11/06(土) 21:47:09.97 ID:PDDtrjdC.net] 安全性も下がるし並列性?も確保できなくなる気がするのは気のせいではないでしょうか
1012 名前:デフォルトの名無しさん mailto:sage [2021/11/06(土) 22:22:33.53 ID:9KDcj+aF.net] >>991 プログラミング初心者には難しいかもしれないけど 一般的にプログラミング言語ではスコープという概念があってスコープが異なれば同じ変数名でも全く別のものとして認識され格納場所は異なるし型が異なってもよい その中でもブロックスコープは多くのプログラミング言語で採用されていてブロックが始まると新たなスコープが出来て同じ変数名でも全く別のものとして扱われる 今回のシャドーイングスコープも同様でシャドーイングの時点から新たなスコープが始まるため同じ変数名でも全く別の変数として扱われる だから安全性は全く下がらないし並行でも並列でもシャドーイングで問題が生じることはない むしろシャドーイングの利用で利便性が高まっていることがプログラミング経験を重ねると理解できる
1013 名前:デフォルトの名無しさん mailto:sage [2021/11/06(土) 22:44:27.14 ID:EdP5MzkQ.net] ダイナミックスコープはいらない子だった・・・?
1014 名前:はちみつ餃子 mailto:sage [2021/11/06(土) 23:40:03.82 ID:tiSLGdpm.net] ダイナミックスコープがデフォルトの言語なんて Emacs Lisp くらいしか見たことないわ。
1015 名前:991 mailto:sage [2021/11/07(日) 06:37:58.76 ID:It35Zcf7.net] 意図したシャドーイングならともかく、間違って同じ変数名つけたコード片突っ込んでしまった系だと他言語にあるらしい2重宣言エラーないの怖くないですか? 新たなスコープが生まれるので並列性に問題ないことはなんとなく理解できました
1016 名前:デフォルトの名無しさん [2021/11/07(日) 07:11:27.61 ID:F+zOFISG.net] D言語の再来。
1017 名前:デフォルトの名無しさん mailto:sage [2021/11/07(日) 07:13:38.67 ID:pJhT3MIE.net] 次スレは? >>980 が1時間待っても立てなかったら俺がやる
1018 名前:デフォルトの名無しさん mailto:sage [2021/11/07(日) 08:48:10.79 ID:N5JIOUKU.net] 質問いいですか
1019 名前:デフォルトの名無しさん mailto:sage [2021/11/07(日) 10:09:41.36 ID:k2ts2WHd.net] くたばれ
1020 名前:1001 [Over 1000 Thread.net] このスレッドは1000を超えました。 新しいスレッドを立ててください。 life time: 74日 11時間 14分 14秒
1021 名前:過去ログ ★ [[過去ログ]] ■ このスレッドは過去ログ倉庫に格納されています