Rust part25

**デフォルトの名無しさん** · 2024/07/31(水) 00:46:26.17

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part24
https://mevius.5ch.net/test/read.cgi/tech/1716759686/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2024/09/05(木) 15:38:39.94

やばい、やばい、別言語に書き換えたらGPLロンダリング出来ると本気で思ってそうだな
会社ぐるみで参考とか調査と称してGPLコード内の処理内容をパクってそう

新興OSがLinuxコードをパクって無いと主張するのはダウト

**デフォルトの名無しさん** · 2024/09/05(木) 16:03:51.09

GPLの力をそこまで拡大するのはカスなんだよな
そこまでやるなら裁判でもなんでもしてGPLごと破壊していくべき

**デフォルトの名無しさん** · 2024/09/05(木) 16:10:43.66

そこまで気にするならGPLに限らず他人の
著作物見ると危険だから

**デフォルトの名無しさん** · 2024/09/05(木) 16:22:33.75

「GPLのソースをコピーして使ったソースは、ソース公開の義務が生じ、それもGPLになる」
というものだから、目で見て脳で記憶してそっくりに真似た場合はコピーしたわけではないから
GPL感染しないかも。
そもそも、目で見たものを再現したら、駄目、なんて理屈、特許も取れてないのに主張できる
ものなのかいな。絵とか文章をそのままコピーするのは著作権違反だけども、目で見て真似た
だけでは著作権違反ではなかろう。ミッキーマウスみたいなのは駄目なんだろうけども。
GPLは、ライセンス自体が法解釈的に「無効」かも知れない。

**デフォルトの名無しさん** · 2024/09/05(木) 16:26:01.06

memcpyのx86用のアセンブリコードがあったとして、それ以上ほぼ高速化できない場合が有るから、
それを真似てはいけないと言うのは、技術の進歩を阻害してしまうだろう。
それとは異なるが速度は同じ、というようなものを考え出す苦労がGPLのせいで生まれる
ことになり、それに時間をとられて人類は損失を被ることになる。

**デフォルトの名無しさん** · 2024/09/05(木) 16:29:22.37

そもそも、人類は技術を少しずつ改良している。memcpyに関しても基本的にそう。
しかも、ハーバード、スタンフォード、MITなどの最高レベルに優秀な人が研究目的
だからライセンスを気にせずにGPLのものを改良を重ね、最良に近いものを作り出して
いることがある。しかし、それを真似てはいけないと言うのは、GPL以外のものは、
人類の英知を利用してはいけない、ということになってしまう。研究費が国から出るような
立場の人はそれでよくても、民間企業はそれではとても困る。

**デフォルトの名無しさん** · 2024/09/05(木) 17:03:49.47

GPLじゃないOSSなんていくらでもあるのに「GPLロンダリング」をどうしても正当化したい勢が結構いる事に驚いた今日この頃

**デフォルトの名無しさん** · 2024/09/05(木) 17:05:55.92

誰が作っても同じ物ができる部分は遵法精神があろうがなかろうが同じ物ができるから
法律は関係ない

関係あるのは、ふつうと違う物を作ったらボーナスがもらえるような奴だけだろう

**デフォルトの名無しさん** · 2024/09/05(木) 17:14:02.07

>>712
例えば、多倍長計算ライブラリは、GPL以外のものに良いものがない。

**デフォルトの名無しさん** · 2024/09/05(木) 17:19:12.62

>>711
> GPL以外のものは、人類の英知を利用してはいけない、ということになってしまう。

そうだよ。真似しなければ滅びるというなら滅びるべきであるのに
どうして生き延びるために真似していいと思うんだ？
GPL の感染を許したくないなら「お前が」適当なライセンスで作ればいい。
お前が作れなければ出来る人に金を払って作らせろよ。
それがオープンソースの理念だろ。

**デフォルトの名無しさん** · 2024/09/05(木) 17:28:10.99

>>715
>GPL の感染を許したくないなら「お前が」適当なライセンスで作ればいい。
memcpy や多倍長計算は、世界最高レベルのものが、GPLで出来てしまえば、
異なるアルゴリズムや書き方で、それと同じか、または、超える効率のものは作りえない。

**デフォルトの名無しさん** · 2024/09/05(木) 17:33:36.15

>>716
なら滅びろと言ってるのがまだわからんのか。
しつこい。

**デフォルトの名無しさん** · 2024/09/05(木) 17:46:49.89

アイデア・ノウハウ・情報などは著作物ではなく保護の対象ではない
だから考え方やアルゴリズムを真似たところで著作権違反にはならない

逆に言語を変えていてもコードを丸コピしてれば違反に問われる可能性はある
コードに「創作性」が認められる場合のみだけど

ただCを例えばHaskellで書き換えたら
基本ルールが違いすぎて異なる表現にしかならないので
複製にあたる可能性は限りなくゼロ

**デフォルトの名無しさん** · 2024/09/05(木) 17:51:37.45

>>718
>アイデア・ノウハウ・情報などは著作物ではなく保護の対象ではない
>だから考え方やアルゴリズムを真似たところで著作権違反にはならない
だとすれば、GPLで書かれた数値計算ライブラリやmemcpyのアイデア・ノウハウ・アルゴリズム
と完全に同じものを使ったプログラムを作っても、著作権の保護にならないと言うことか。

**デフォルトの名無しさん** · 2024/09/05(木) 18:02:59.65

無理筋で弾幕張ってるのは「GPLロンダリング」し過ぎてもう取返しがつかないのか
自動車のECUをリバースエンジニアリングする様子がツベで視聴数を稼ぐ時代にリスク張り過ぎw

>>718
それ論文の話でしょ
>>719
違う

アルゴリズム論文みてHaskell実装するならOK、好きなライセンス形態を選べる
GPL CコードみてHaskell実装するならGPL感染する

**デフォルトの名無しさん** · 2024/09/05(木) 18:13:46.19

著作権は表現を守る権利だよ。
どこまで表現でどこからアイデアなのか知財関連は素人には判断できないが、 memcpy レベルの基礎的なやつは CPU のドキュメントとかに書いてあるのが元だったりするからどうしても GPL なソフトウェアを真似しないといけないってことはあまりない。
GPL に知恵が集約されてるなんてことはない。

**デフォルトの名無しさん** · 2024/09/05(木) 19:53:46.83

企業が収めた税で食ってる立場の人間が企業の邪魔するようになっちゃ終わりよな
そういう資金がなくなるような政党に投票していこうな

**デフォルトの名無しさん** · 2024/09/05(木) 20:22:43.47

>>721
>memcpy レベルの基礎的なやつは CPU のドキュメントとかに書いてあるのが元だったりするから
調べてみたが、Intel PDF Manual からは発見できなかった。

**デフォルトの名無しさん** · 2024/09/05(木) 20:36:21.56

>>720
>アルゴリズム論文みてHaskell実装するならOK、好きなライセンス形態を選べる
>GPL CコードみてHaskell実装するならGPL感染する
「アルゴリズム」というけれど、memcpyみたいなものは高速化のためにCではなく、
アセンブラレベルにする。だから、レジスタや細かい命令の使い方まで含めてアイデア。
レジスタは、完全には自由には選べないので、個人の自由で選べる範囲は狭い。
だから、効率を落とさずに変更できる余地は少ない。

**デフォルトの名無しさん** · 2024/09/05(木) 20:36:22.59

>>720
>アルゴリズム論文みてHaskell実装するならOK、好きなライセンス形態を選べる
>GPL CコードみてHaskell実装するならGPL感染する
「アルゴリズム」というけれど、memcpyみたいなものは高速化のためにCではなく、
アセンブラレベルにする。だから、レジスタや細かい命令の使い方まで含めてアイデア。
レジスタは、完全には自由には選べないので、個人の自由で選べる範囲は狭い。
だから、効率を落とさずに変更できる余地は少ない。

**デフォルトの名無しさん** · 2024/09/05(木) 20:49:43.99

>>720
何も知らんのだなw
Nim推ししてたやつと同じ低知能臭い

**デフォルトの名無しさん** · 2024/09/05(木) 22:10:14.25

多倍長整数は、整数もObjectクラスを継承している系の言語と相性が良かったが
そういう言語とアセンブラの相性は良くないからアセンブラにこだわる意味は昔はなかった
今は知らんけど

**デフォルトの名無しさん** · 2024/09/05(木) 22:17:29.12

民業圧迫ωωω

**デフォルトの名無しさん** · 2024/09/05(木) 22:41:12.21

>>705
C言語の\0終端文字列は部分文字列をそのままでは作れないから不利なのか
長さが最後まで読まないと不明で不利なだけでなく

**デフォルトの名無しさん** · 2024/09/05(木) 22:47:40.53

memcpy(のアセンブリコード)だと、たまたま良く似たコードになる可能性も有る。
絶対に真似したかどうかの判定は難しい。
また、そんなことで裁判起こされても困る。

**デフォルトの名無しさん** · 2024/09/05(木) 22:47:40.53

memcpy(のアセンブリコード)だと、たまたま良く似たコードになる可能性も有る。
絶対に真似したかどうかの判定は難しい。
また、そんなことで裁判起こされても困る。

**デフォルトの名無しさん** · 2024/09/05(木) 22:51:02.28

ヌル終端の文字列が不利かどうかは知らんが C で書かれたプログラムは原則としてそうなっていて、
OS レベルに互換性が重要なものはいまさら変更することもできない (から Rust と相性が悪い要素のひとつ) って文脈の話ね。

どちらが良いとかじゃなくて混ぜるのはしんどいという話。

**デフォルトの名無しさん** · 2024/09/05(木) 23:25:02.06

let hoge: &str = "hoge\0";
で解決

**デフォルトの名無しさん** · 2024/09/05(木) 23:28:42.24

Rustに std::ffi::CStr が出来たから大丈夫

**デフォルトの名無しさん** · 2024/09/06(金) 07:46:48.97

>>731
ちゃんと上流に問い合わせた方が良い

何かあったら切捨てられるように何も知らない下流を使っている可能性大
確認して一蓮托生だと認識させないとだめ

**デフォルトの名無しさん** · 2024/09/06(金) 08:16:00.50

>>677 >>691
そりゃそうだろ。マネージャーとコーダーで立場が違うんだから。
Rustはコーダーに余計なことをやらせない管理者向けの言語だからLinusが受け入れるのは分かるし、コーダーにとっては無駄に複雑で自由の無い言語だからクソ判定するのもわかる。

実際、Rustは設計固めないとコーティングできないクソ言語だし。

**デフォルトの名無しさん** · 2024/09/06(金) 08:41:14.19

>>718
日本の場合、翻訳は二次著作物で原著作者の支配下だよ。
外国も同様のところが多くなかったっけ？

**デフォルトの名無しさん** · 2024/09/06(金) 09:22:28.52

>>737
GPLのプログラムソース中のアルゴリズムを別の言語で書いてGPL違反になった判例ある？

**デフォルトの名無しさん** · 2024/09/06(金) 09:23:43.25

>>736
Rustは清書用(キリっ

**デフォルトの名無しさん** · 2024/09/06(金) 09:25:11.78

>>738
コードそのものは違反にならないね
アルゴリズムに著作権は無いとして
外部とのインターフェースに著作権があるかどうか

**デフォルトの名無しさん** · 2024/09/06(金) 10:11:20.75

>>740
インターフェースに著作権は無いよ

**デフォルトの名無しさん** · 2024/09/06(金) 10:16:26.58

マネージャとコーダーとか多重請負SIer文化で
linuxカーネル開発を語るなよ…

**デフォルトの名無しさん** · 2024/09/06(金) 11:01:47.89

じゃあメンテナーとコミッターで

**デフォルトの名無しさん** · 2024/09/06(金) 11:05:42.46

linuxで余計なことをやろうとしたのはコーダーではなく
継承とか仮想関数とか設計を語る人達だよね
継承とか仮想関数とかを使わない方針が固まるまでC++コードを書かなかった情強がRustを書き始めた

**デフォルトの名無しさん** · 2024/09/06(金) 12:04:11.30

C++でOS造ろうとした●●ぽんとかいう人は情弱か

**デフォルトの名無しさん** · 2024/09/06(金) 12:19:00.64

linuxカーネルのソース読んだことないのか
c言語とは言え実質的に継承、仮想関数で実装されているところ数多あるから
このあたりはもしオブジェクト指向言語であれば非常にすっきり書けたはずだ
c++の問題はそれ以外の落とし穴が多すぎる

**デフォルトの名無しさん** · 2024/09/06(金) 12:20:47.23

>>738
GPLに限定した話は知らんけど、ソースコード->機械語のコンパイルは翻訳として扱われるんだから同じじゃね？

**デフォルトの名無しさん** · 2024/09/06(金) 12:30:31.40

カーネルが清書だ
何言語だろうがカーネルを書いた者は清書おじさんだ

**デフォルトの名無しさん** · 2024/09/06(金) 13:03:06.23

ここでRust持ち上げてC++叩いてる人は
C++のこと全然判ってないね

**デフォルトの名無しさん** · 2024/09/06(金) 14:21:47.18

>>746
openもcloseもただのメンバ関数とする設計が固まればいいのだが
いやopenはコンストラクタに変えるべきだろ
closeはデストラクタだ
っていう所がすっきりしない

**デフォルトの名無しさん** · 2024/09/06(金) 16:17:28.15

>>747
判例出してよ

**デフォルトの名無しさん** · 2024/09/06(金) 16:37:13.89

>>749
分かります。

**デフォルトの名無しさん** · 2024/09/06(金) 16:38:41.24

>>752
誤解を招きそうな書き方になってしまいましたが、
「判ってないね」
を否定しているのではなく、あなたのご意見に賛同すると言う意味です。

**デフォルトの名無しさん** · 2024/09/06(金) 18:30:21.35

C++のこと、全然わかんないや
わかってる人に会ったこともない

**デフォルトの名無しさん** · 2024/09/06(金) 19:25:43.95

C++のメタプログラミングがすべてを理解しようとしたら頭おかしくなる

**デフォルトの名無しさん** · 2024/09/06(金) 20:38:27.30

>>751
ちょっと検索してみたけどこんなのがトップに出てきた。

jpaa-patent.info/patent/viewPdf/4110

逆コンパイルがメインだけど差は無いかね。

**デフォルトの名無しさん** · 2024/09/07(土) 07:53:51.62

>>756
その判例にGPLのGの字も無いよ
「GPLのプログラムソース中のアルゴリズムを別の言語で書いてGPL違反になった判例」出して

**デフォルトの名無しさん** · 2024/09/07(土) 08:03:00.66

そろそろGPLスレでやった方がいい

**デフォルトの名無しさん** · 2024/09/07(土) 08:24:32.13

このスレにRustでGPLロンダリングしている輩が一定数居そうだからおk

**デフォルトの名無しさん** · 2024/09/07(土) 09:16:43.75

unsafeを使えばCを呼べるのに一体なぜCをRustに書き直すんだ

**デフォルトの名無しさん** · 2024/09/07(土) 10:03:49.93

チューニングするなら結局境界検査とかオフにすることになるしなぁ

**デフォルトの名無しさん** · 2024/09/07(土) 10:22:43.32

低レイヤ、ベアメタルってのも何故か一連のRust関連スレで見かける印象

**デフォルトの名無しさん** · 2024/09/07(土) 10:37:53.70

>>757
レスバトラーなら絶対言うだろうなと思ったら案の定で笑っちゃった

**デフォルトの名無しさん** · 2024/09/07(土) 11:14:10.87

>>761
境界検査は不要なところではそもそも行われないのでそんなことする必要がない
例えば回数的にほとんどのケースはループ内だがそれはループの終端検査に集約されるため消える

**デフォルトの名無しさん** · 2024/09/07(土) 11:33:41.32

ランダムアクセスは思ったより少ないけど必要なところでは性能的に割とシビアなことも多いぞ。

**デフォルトの名無しさん** · 2024/09/07(土) 11:44:43.13

>>757
その反論するならまず
「著作物のGPL配布には『著作権上コンパイルは翻訳として扱われる』ことを否定する要因がある」
ことを明らかにしなきゃ話にならんわな。

そもそも>747で「GPLに限定した話は知らんけど」と言っているのにその反論は無能すぎるかと。

**デフォルトの名無しさん** · 2024/09/07(土) 11:58:50.25

>>760
unsafeだからですよ

**デフォルトの名無しさん** · 2024/09/07(土) 12:14:44.55

>>759,760,767

Rust書き換えに裏の目的があったとはね

低レイヤRustプロジェクトの数は少なくて
更にわざわざRust使ってますアピールするから
絞り込んだら見つかるかもしれない

**デフォルトの名無しさん** · 2024/09/07(土) 13:21:00.20

C++とCがまるで嫁と姑のように同居する設計はLinuxに採用されなかった
Rustなら同居にはならない
本来の目的はそんな感じだろう

**デフォルトの名無しさん** · 2024/09/07(土) 13:41:30.42

LinusがC++を嫌ってるのはCとの関係性でなくC++独自の部分だと思うぞ
「レベルの低い開発者がクラスとかオブジェクトを使ってどうしようもない壊れたコードを容易に作れる」といった感じだったと思う
これはC++ 11すら登場してない時代の批判だから、今も同じように思うかどうかは分からないけど
あと「C++の例外機構はカーネル開発に向かない」というのもあって、これは今も同じだと思う

**デフォルトの名無しさん** · 2024/09/07(土) 13:45:37.17

RustやGoなどの例外ではなくエラー値を返していくやり方いいね

**デフォルトの名無しさん** · 2024/09/07(土) 14:09:35.09

返されたエラー値をスルーする事例が多発したから例外が作られたと思う
Rustはmust_useがあるけどGoはよく分からん（特に戻り値がエラーだけの関数）

**デフォルトの名無しさん** · 2024/09/07(土) 14:10:48.96

ハイプ期に流行った言説をいつまでも言い続けていくこの感じ

**デフォルトの名無しさん** · 2024/09/07(土) 14:34:40.97

東京オリンピック、大阪万博、不動産バブル

**デフォルトの名無しさん** · 2024/09/07(土) 15:19:49.13

>>763>>766
スレ違うだし判例無いならもういいよ

**デフォルトの名無しさん** · 2024/09/07(土) 16:51:05.14

ゲームサーバーもRustで書く時代か

> 業務内容
> 経験・志向に応じて、以下のような分野でお仕事をしていただきます。
> ・ゲームサーバー構築およびバックエンド開発(Rust、C++、etc)
> ・運用補助のためのフロントエンドおよびバックエンド開発(Rust、React、TypeScript、etc)

> 今までゲームサーバーの開発ではC++がメインでしたが、近年少しずつRustに移行しつつあります。
> 実績としてARMORED COREⅥのゲームサーバーはRustで作られ、稼働しています。
> Rust、C++のいずれかの経験者を歓迎していますが、他の言語経験者でRust、C++に興味ある方も歓迎しております。

**デフォルトの名無しさん** · 2024/09/07(土) 17:01:27.84

ゲームサーバーは低レイヤRustプロジェクトじゃないから
Linux等からのGPLロンダリングは関係なさそうだね

低レイヤ、ベアメタル、Rustがポイントなのかな？

**デフォルトの名無しさん** · 2024/09/07(土) 18:01:33.85

>>775
判例という難しそうな言葉を使いたいお年頃なのね

**デフォルトの名無しさん** · 2024/09/07(土) 18:16:42.45

>>778
お前のお気持ち表明に何の意味も無いのよ

**デフォルトの名無しさん** · 2024/09/07(土) 18:41:33.85

表明されたエラーを無視されない確実な方法はプロセス全体を終了すること
終了を回避する方法があれば無視される可能性がある

**デフォルトの名無しさん** · 2024/09/07(土) 18:57:47.65

>>775
判例は>>756。
GPLの著作物と違いから無いからそのまま適用可能。

**デフォルトの名無しさん** · 2024/09/07(土) 21:31:00.16

逆コンパイルとGPLプログラム見たことがある人がプログラム書く行為が同じってマジ？

**デフォルトの名無しさん** · 2024/09/07(土) 22:24:15.60

**デフォルトの名無しさん** · 2024/09/07(土) 22:53:24.95

なぜ実験すればいいと思った
自分は科学的だと思ってるのかな
科学って暴走するんだな

**デフォルトの名無しさん** · 2024/09/07(土) 23:03:30.32

>>782
んなわけない
逆コンパイルはコンパイルに近い扱い

**デフォルトの名無しさん** · 2024/09/07(土) 23:14:34.54

当たり前だが「見た == パクった」とはならない

ただ万が一の訴訟リスクも避けたいなら
GPLのソースを見て仕様を起こす組織/人間と
GPLのソースを見ず起こされた仕様をもとに
コードを書く組織/人間を完全に分けておけばよい
これで完全にパクリを否定できる

**デフォルトの名無しさん** · 2024/09/08(日) 00:01:36.02

そもそも、特許取れてないものをパクることは、歴史的には許されてきた。
また、著作権法も契約も、作家や著作権者が作品を売って暮らしていけることを目的と
していたものであり、GPLのように社会全体を構造的に変化させることを目的としたものでは
なく、法令の目的外使用と言える。

**デフォルトの名無しさん** · 2024/09/08(日) 02:29:49.31

パソコンのキーボードでフリック入力できるものはありますか？

**デフォルトの名無しさん** · 2024/09/08(日) 07:57:18.94

相場が乱高下することは許される
ということは昨日は無罪だったものが今日は有罪になっても
相場が間違っていることにならない

**デフォルトの名無しさん** · 2024/09/08(日) 21:59:24.16

shared_ptrはRustではArcだと思うけどこれ本当？

447 デフォルトの名無しさん 2024/09/07(土) 20:17
むしろshared_ptr<T>でスレッド間共有オブジェクトを保持するのは
生ポに対するshared_ptr<T>のメリットが無い……
可能な限りスレッド間共有なんてことはやめてconstオブジェクトのコピーにするのが正義……

**デフォルトの名無しさん** · 2024/09/08(日) 22:20:14.30

C++スレでやれって感じだけど、自分ははその説明は適切でないと思う
shared_ptrを使う理由はちゃんとある
寿命を適切に管理してるなら片方がunique_ptr等で所有して他方に生ポインタ渡すのも駄目ではない

可能ならデータ共有よりもスレッドごとに所有させる方が安全というのは分かるけど、共有が必要な場面って普通にあるはず

**デフォルトの名無しさん** · 2024/09/08(日) 23:25:28.71

>>791
スレッドの寿命に依存するからunique_ptr使用でポインタ渡しはリスキーだね
Rustならthread::scopeで安全に参照を渡せる
もちろんArcを使うのもよくて
追加コストはclone時と終える時の加減算
スレッド内での参照にコストはかからないからArcを避ける必要はない

**デフォルトの名無しさん** · 2024/09/08(日) 23:59:54.41

自分も推奨とまでは思ってなくて、「寿命の問題がないことが明らかであれば許容する」くらいの感じで書いた
クラスのコンストラクタでスレッド立ち上げて、デストラクタの中でjoinするような作り (よくあると思う) ならスレッドの寿命 < 参照先のデータの寿命は明らかだし
shared_ptrの方が意図は分かりやすいとは思うけど、必須までとは思わない

**デフォルトの名無しさん** · 2024/09/09(月) 00:11:01.40

std::thread::scope()は必然的にそういう挙動になるな
終了時のjoinが保証されるからスレッドの寿命 < 参照先のデータの寿命になる

実際の例は
https://doc.rust-lang.org/stable/std/thread/fn.scope.html
のExample参照

**デフォルトの名無しさん** · 2024/09/09(月) 05:07:18.49

>>792
>寿命を適切に管理してるなら
って描いてあるだろ

**デフォルトの名無しさん** · 2024/09/09(月) 07:01:55.53

>>795
その考え方が既に詰んでいる
もし寿命を適切に管理できるならunique_ptrもRustも不要
しかし人間が100%適切に管理することは不可能だからC++でunique_ptr等が導入された
そしてさらにRust言語が導入された

**デフォルトの名無しさん** · 2024/09/09(月) 08:08:18.92

寿命を適切に管理できる時はあるんだけど、そうであるかそうでないかの境界くらいなコードをうっかり受け入れてしまうとその後ずっと負債になるんだよな

**デフォルトの名無しさん** · 2024/09/09(月) 08:13:24.94

でもここでRustを持ち上げている一定数は
RustでGPLロンダリングしていると吹聴しているレベル

低レイヤ、ベアメタル、Rustってのがポイントみたい

**デフォルトの名無しさん** · 2024/09/09(月) 08:59:39.68

どうあっても完璧にはならないという前提で、ちょいちょいリファクタリングするくらいの運用ができればいいんだけどな。
ワヤになることがあっても戻せば少なくとも動きはするし。

**デフォルトの名無しさん** · 2024/09/09(月) 11:37:01.61

またC++知らん人が出て来たでおじゃる

**デフォルトの名無しさん** · 2024/09/09(月) 13:49:10.25

C++のスマートポインタは分かってる分かってないもあるがTの型や使われ方によって考えること多すぎて元々キツイやろ
Rustは継承無くしたり所有権複雑にしたことでスマートポインタの様々な機能が可能な限り単一責任に分散されててスッキリしてる
考えた奴の努力凄えと思う

**デフォルトの名無しさん** · 2024/09/09(月) 13:56:14.25

あっちのスレﾜｯﾁｮｲ付いてるからわざわざこっちに持ってきたの？

**デフォルトの名無しさん** · 2024/09/09(月) 20:31:43.26

Rust プログラミング 1 (全 5 回)
watch?v=6AiU6ncdUdk
出演
低レイヤーガール 1: 自作 OS を Rust で書いている
低レイヤーガール 2: 自作 browser を Rust で書いている

**デフォルトの名無しさん** · 2024/09/09(月) 21:35:49.10

>>801
継承の有無は関係なくて
C++ではヒープの解放責任が対象で
Rustはそれに加えてヒープかスタック上かに関わらず参照の有効性が対象

**デフォルトの名無しさん** · 2024/09/09(月) 23:09:27.92

>>804
ArcやRcってスタックのデータを指せるっけ？
基本的にヒープに確保されると思ってた