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/03(火) 07:16:54.59

オブジェクトプールって要はキャッシュのことでいいの？

**デフォルトの名無しさん** · 2024/09/03(火) 07:43:29.24

>>645
訂正
アリーナ方式(＝オブジェクトプール方式)はC++とNim2.0だけに導入されてるわけではないと

じゃあNim言語開発者が、RustやC++、そしてSwiftがどのようにメモリ管理を行っているかを調べ、良い部分を再組み合わせたオブジェクトプールは他の言語にあるの？

無いなら、現時点でRustやC++、そしてSwiftがどのようにメモリ管理を行っているかを調べ、良い部分を再組み合わせたオブジェクトプールはを導入してるのはNim2.0だけって事で異論はない？

**デフォルトの名無しさん** · 2024/09/03(火) 07:47:47.67

訂正（オブジェクトプール　→　ムーブセマンティクス）
じゃあNim言語開発者が、RustやC++、そしてSwiftがどのようにメモリ管理を行っているかを調べ、良い部分を再組み合わせたムーブセマンティクスは他の言語にあるの？

無いなら、現時点でRustやC++、そしてSwiftがどのようにメモリ管理を行っているかを調べ、良い部分を再組み合わせたムーブセマンティクスはを導入してるのはNim2.0だけって事で異論はない？

**デフォルトの名無しさん** · 2024/09/03(火) 07:52:41.59

アロケータを細かく制御したいなら断然Zigだろ
Arena Allocatorももちろん用意されてるし、他にも選択肢がある

**デフォルトの名無しさん** · 2024/09/03(火) 07:59:06.62

>>649
普通オブジェクトプールをキャッシュとは言わないと思うけど
まぁ挙動としてはメモリ領域のキャッシュみたいなイメージでいいかもしれない
小領域の確保と解放が繰り返されるときにキャッシュすることで実際のmalloc/free（あるいはGC）呼び出し回数を減らすためのもの

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

来年にはZigがメジャーバージョン1到達見込みみたいだし期待

**デフォルトの名無しさん** · 2024/09/03(火) 08:04:09.12

Zigはこのまま未完成に終わって極少数の趣味人にしか使われないでしょう

**デフォルトの名無しさん** · 2024/09/03(火) 10:06:28.79

なんかZigファン多いみたいだから、単独スレ立てて議論したら？
ここはRustスレだから、ただ単にZigはすごいんだあって宣伝するだけなのはつまらんぞ

**デフォルトの名無しさん** · 2024/09/03(火) 10:17:54.29

C++とかGoとかNimとかの他所様のスレにRustの宣伝を書き散らしてたカスもいたわけだし
今更そんなこと言っても誰も相手にせんだろう

**デフォルトの名無しさん** · 2024/09/03(火) 10:20:47.01

アロケータ周りの不自由さはRustの代表的なウィークポイントだから
Zigと比較するのは有意義だと思うよ

Rust for Linuxで不備を指摘されて、unstable featuresとして整備し始めてるのが現状でしょ？

**デフォルトの名無しさん** · 2024/09/03(火) 10:30:58.77

入院が安定化されればクリアする話だから年内か年明けにでも解決

**デフォルトの名無しさん** · 2024/09/03(火) 13:17:35.66

スレ違いなのに書き込んでるやつは頭悪そう

**デフォルトの名無しさん** · 2024/09/03(火) 16:24:34.66

>>631
>C++を置き換えるものがRust、

doubt

**デフォルトの名無しさん** · 2024/09/03(火) 16:46:40.15

>>657
いたね
ほんとめいわく
世界中のケンタという名のプログラマを敵に回しただろう

**デフォルトの名無しさん** · 2024/09/03(火) 20:18:41.62

>>589
Nim2.0は循環参照が大量に使用されていればいるほどオブジェクトプールとムーブセマンティクスのメモリ最適化アルゴリズムで、人間がCの手動メモリ管理したベンチマークより速くなる

だからNim2.0は循環参照が大量に使用されていない通常の短いコードの言語間ベンチマーク比較だとÇと変わらなくなる

>しかもNimはC言語へトランスパイルされるんだろｗ
人間がCの手動メモリ管理したプログラムだとメモリの最適化に限界がある
Nim2.0はオブジェクトプールとムーブセマンティクスのアルゴリズムでメモリの最適化をしてるから、オブジェクトプール版のNimから生成したCのコードは人間には書けない

Nim2.0のムーブセマンティクスの本当に優れたメモリ最適化アルゴリズムと明示的にオブジェクトプールでプログラミングすることによって、人間がCの手動メモリ管理したベンチマークより2倍以上速くできる

**デフォルトの名無しさん** · 2024/09/03(火) 20:29:12.43

補足
NimはCのソースコード吐けるからから、Nimの手動メモリ管理はCの手動メモリ管理と同じとしてベンチマーク計測してる
https://github.com/Araq/fosdem2020
https://zenn.dev/dum...icles/af2b2b9f8fd890

**デフォルトの名無しさん** · 2024/09/03(火) 20:30:56.39

比較コードとベンチ結果すら示せない嘘つきがまた来てるのか

**デフォルトの名無しさん** · 2024/09/03(火) 20:49:25.51

>>665
https://github.com/Araq/fosdem2020

ベンチマーク：処理能力
Memory management strategy Time Peak Memory
mark&sweep GC 　　　　　　　　17s 　　　588.047MiB
deferred refcounting GC 　　　　　16s 　　　304.074MiB
Boehm GC 　　　　　　　　　　12s 　　　　　N/A
ARC 　　　　　　　　　　　　　　　6.75s 　　472.098MiB(379.074MiB)
manual 　　　　　　　　　　　　5.23s　　　 244.563MiB
manual(with RC) 　　　　　　　6.244s 　　　379.074MiB
object pooling 　　　　　　　　　　2.4s 　　　　　251.504MiB
パフォーマンスはどうでしょうか？結果ははるかに速く、パフォーマンスが2倍以上向上し、メモリ消費もほぼ同じです。

**デフォルトの名無しさん** · 2024/09/03(火) 20:59:57.60

それはNim同士の別方式の比較
他の言語と比較しないと意味がないね
もちろん他の言語で書いてもobject pooling (= arena allocation)方式が一番速くなることが昔から知られている

**デフォルトの名無しさん** · 2024/09/03(火) 21:00:53.22

そもそもGCを使わない方法での比較はしてるの？

**デフォルトの名無しさん** · 2024/09/03(火) 21:03:35.60

V8とRustをベースとしたJavaScript/TypeScriptランタイム環境「Deno」v1.46.2
https://forest.watch.impress.co.jp/docs/digest/1620908.html

**デフォルトの名無しさん** · 2024/09/03(火) 21:22:39.41

Poolの概念
tps://boostjp.github.io/archive/boost_docs/libs/pool/concepts.html

他の実装
Pool 割り当て機構は多くのプログラミング言語に見ることができ、多くのバリエーションが存在する。
多くの実装の端緒は、ごく普通のプログラミングに関する文献に求めることができる。
いくつかを以下に示す。これらの何れも完全な実装ではない。
多くは実装のある局面を読者への練習問題としている。
しかしながら、これらの例はどれも、ある局面が欠落しているとはいえ、
このドキュメントで述べている単純分離記憶域と同じ基底概念を使用している。

"The C++ Programming Language", 3rd ed., by Bjarne Stroustrup, Section 19.4.2.
(略)
"MicroC/OS-II: The Real-Time Kernel", by Jean J. Labrosse, Chapter 7 and Appendix B.04.
(略)
"Efficient C++: Performance Programming Techniques", by Dov Bulka and David Mayhew, Chapters 6 and 7.
(略)
"Advanced C++: Programming Styles and Idioms", by James O. Coplien, Section 3.6.
(略)

**デフォルトの名無しさん** · 2024/09/04(水) 00:24:08.00

なんでstdで公開してるんだか知らんが、rustc開発陣には面白いこと考えて実装してしまう人がいるもんだね
https://doc.rust-lang.org/std/intrinsics/mir/index.html

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

>>669
https://zenn.dev/ekusiadadus/articles/bench-go-node-rust-zig

denoって遅いんだな

**デフォルトの名無しさん** · 2024/09/04(水) 06:51:22.28

>>672
バカなベンチマーク記事の典型例
Goはマルチスレッドをフルに使っていて8倍速い結果

**デフォルトの名無しさん** · 2024/09/04(水) 08:21:33.86

こっちのが各種負荷が分かりやすい
youtu.be/2hWfLiRGaNM

**デフォルトの名無しさん** · 2024/09/04(水) 13:53:11.19

どっちのロゴもださい

**デフォルトの名無しさん** · 2024/09/04(水) 18:38:20.03

いくつか記事出てるけど、Rust for Linuxは失敗に終わったみたいだね

**デフォルトの名無しさん** · 2024/09/04(水) 18:53:43.06

>>676
既に次々とRustコードが入っていってる
一方でRustを理解できない人が抵抗勢力になっていてLinus氏が釘をさした形

**デフォルトの名無しさん** · 2024/09/04(水) 20:38:51.07

具体的にLinuxの何がRustで書かれてるんだっけか

**デフォルトの名無しさん** · 2024/09/04(水) 20:51:35.06

https://github.com/torvalds/linux

カーネルにはまだ何も入ってなさそう

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

だよね
知ってた

**デフォルトの名無しさん** · 2024/09/04(水) 21:39:00.59

抵抗勢力のクズを一掃できないとLinuxの敗北の始まりになるかもな

**デフォルトの名無しさん** · 2024/09/04(水) 22:30:46.44

何に敗北するんだろうか
Rust製でもっと高信頼性かつ高機能なOSをどこかが作ってたりするの？

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

linux はバイナリ互換性を大事にする。
(Windows ほどではないけど。)
ドキュメントに書いてない仕様外の挙動であってもそれを変更して動かなくなるアプリケーションがあってはならないというのが基本指針。
コンパイラの挙動とも協調して細部をコントロールしてる工芸品だ。
この状態を維持したまま Rust を導入するのは無理だよ。
比較的疎結合な一部のモジュールはなんとかなるかもしれんがあえてやるには時期尚早。

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

それバイナリ互換と関係ない話

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

>>683
それはカーネル外と際の話
さして言語は関係ない
実行バイナリファイル形式は同じだからRustで書かれたものも動いているしCで書かれたものと混在リンクしても動いてる
バイナリインタフェースのうちシステムコールについてはlibcそのまま用いている
そのためためRustでもレジスタの使用方法積み方全て同じ
実行バイナリへの混在リンクの関数呼び出しについてもCと同じくレジスタ割り当てや退避を行うためこれも同じ

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

カーネルとモジュールの間ではバイナリ互換性の問題は発生しないとでも言うつもりなんだろうか

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

>>686
カーネルモジュールはRustで書いても問題なく動いている
興味があるなら誰でも自由に書くことができてローカルにモジュールロードもできるのでどうぞ

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

>>679
unsafeを使うときには必ずそのすぐ上に // SAFETY: コメントで説明を書かないといけない
ってコーディングルールなんだね
Documentation/rust/coding-guidelines.rst

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

>>682
なぜかそれはしない

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

小さいものはある
しかし巨大なものを置き換えるにはコストがかかる
特に安定している部分はメリットがない
一方でデバイスドライバなど次々と新たなコードが実装されていってる部分はメリットがある
そのためカーネル本体ではなく新たなモジュールからRust化されつつある

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

>>677
判らないから反対してるのか
判ってるけど入れたくないから反対してるのか
どっちだろうね(どっちもあると思う)

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

>ドキュメントに書いてない仕様外の挙動であってもそれを変更して動かなくなる
>アプリケーションがあってはならないというのが基本指針。

そういう規定されていない挙動がセキュリティホールになるんじゃないの
アプリじゃなくてウィルスやワームなら動かなくなっても良いという考えは感心しない
(いいけどさ)

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

Windowsアーキテクチャを捨てる時rustでスクラッチから書き直すんじゃね？

もう誰かが実験的に始めてるかも知れないけど

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

Windowsカーネルにはもう既にRustで書かれたモジュールが入ってるぞ

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

>>691
結局、たとえCとRustが相性良いとか言っても現実は
Cプログラマ「Cで十分。はい論破！」
やからな

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

linuxについてもリーナスはrust導入に期待してるからね。
少しずつだけど前進はしてる。けどrust推進者がメンタルやられて後退もしてる。
リーナスも老害には釘さしてる。

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

rust製OSといえばRedox
https://redox-os.org/

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

RedoxはMITライセンスだから、Redox開発者&コントリビュータはLinuxのGNUソースを一切見ることが出来ないね

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

たとえばヌル終端した文字列を Rust に持ってくるのが面倒くさい (かといって素のポインタで扱うのは Rust の良さが活きない) とかそういう些細な不整合の積み重ねがある。
よく分離されたモジュールの間で通信する分にはたいした話じゃないが一体の塊の中で内容が同じ異なるオブジェクトがあって頻繁に変換するなんてのは論外だ。
カーネルが Rust に配慮するよりは libc みたいなポジションの Rust 版みたいなやつがあればいいんでないの。

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

>>698
？何で見ることできない？

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

そう、それもGPLな
Redoxに流用すなると、RedoxもGPL
Redoxソースを見たらそれもGPL

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

>>700
GPL/GPLAライセンスを舐めたら痛い目に遭う

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

ライセンスはApache-2.0 licenseしか信じてないわ

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

>>702
それは見ることできないとは別問題だよ

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

>>699
ヌル終端文字列の一部を切り取ったヌル終端文字列はたいていヒープに割り当てられ
たいていリファレンスカウントまたはマークアンドスイープの対象になる

ヌル終端しない自由があればヒープがいらなくなる

**デフォルトの名無しさん** · 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++のこと全然判ってないね