Rust part17

**デフォルトの名無しさん** · 2022/10/06(木) 22:43:13.96

公式
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を学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

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

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

前スレ
Rust part16

**デフォルトの名無しさん** · 2022/12/07(水) 00:35:34.36

>>855
まじ？
というか20%がrustってえぐいな

**デフォルトの名無しさん** · 2022/12/07(水) 00:41:52.20

C/C++ の書き方の何が危ないのか、Rustはどうやって回避しているのかは何を読めば分かるの？
Out of memory なんか防げるんだっけ？

**デフォルトの名無しさん** · 2022/12/07(水) 00:58:54.43

kLOCあたり1つ以上の脆弱性があったものが1500kLOCでゼロ
unsafeが量も気になるな

**デフォルトの名無しさん** · 2022/12/07(水) 01:00:43.82

Google製のRustライブラリはどんなのがあんの？

**デフォルトの名無しさん** · 2022/12/07(水) 04:00:04.20

>>855
> システムプログラミングからCやC++を排除するつもりはないという。
これの理由を知りたいわ
まだRustでは書きにくい所があるんだろうか？

**デフォルトの名無しさん** · 2022/12/07(水) 04:05:04.23

ってか、Googleはその分野で使うためにCarbon開発したんじゃなかったのか？

**デフォルトの名無しさん** · 2022/12/07(水) 04:17:31.35

CarbonもRust使えるならRust使えと言ってる

**デフォルトの名無しさん** · 2022/12/07(水) 09:06:42.16

google発のOSSって社員の個人プロジェクトをgoogle名義で公開してるだけの場合もあるからな

**はちみつ餃子** ◆8X2XSCHEME · 2022/12/07(水) 09:19:24.95

どれがいい感じに発展するか事前にわかるもんではないからな。狙いとは違う方向で結実することもあるし。
色々やっておく (それが出来る環境を用意する) とどれかは上手くいくし、上手くいかずに消えるものも多いってだけのこと。

**デフォルトの名無しさん** · 2022/12/07(水) 10:24:44.39

そこまで誤訳だと言うならコントリビューションすれば良いのではないの？

**デフォルトの名無しさん** · 2022/12/07(水) 10:39:11.42

>>855
結果だけみると凄まじい
システムプログラミング関係の置き換えは案外急速に進むかもしれんね

**デフォルトの名無しさん** · 2022/12/07(水) 11:16:25.80

>>865
誤訳だらけでキリがない
ゴミから小さなゴミを取り除いてもゴミのまま
だれがそんなことに時間使うのさ

**デフォルトの名無しさん** · 2022/12/07(水) 12:26:52.65

>>867
2chで文句言って他の話題を出にくくする方が有意義だと思うやつもいるんだな。

**デフォルトの名無しさん** · 2022/12/07(水) 12:31:58.03

複おじ以前と以後で明らかに話題の質が落ちてるよね
おのれ複おじ

**デフォルトの名無しさん** · 2022/12/07(水) 12:39:55.04

>>865
難癖つけて嘲笑って愉しんている奴がそんな無駄なことするわけがない。
自分がマウントできればいいだけだから、そもそもRustを良くする気なんて全く無いだろ。

**デフォルトの名無しさん** · 2022/12/07(水) 12:46:13.68

>>860
Cなら分かるがRustが分からない人
のことを老人と思うのは憶測で、むしろ子供である可能性が高い
子供を排除や淘汰しても進歩など起きない
少子化が加速するだけ

**デフォルトの名無しさん** · 2022/12/07(水) 12:53:44.84

>>860
元記事に以下とあるから既存のコードをrustで書き換えることまではしないという意味だと思われる

As we noted in the original announcement, our goal is not to convert existing C/C++ to Rust, but rather to shift development of new code to memory safe languages over time.

**デフォルトの名無しさん** · 2022/12/07(水) 12:54:18.57

>>872
元記事のurl貼り忘れた

https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html

**デフォルトの名無しさん** · 2022/12/07(水) 15:17:49.39

>>872-873
ありがとう、まあ普通はそうするよね
ただそうするとAndroid 13は20%が新規のコードなんだ...
それはそれで凄いな

**デフォルトの名無しさん** · 2022/12/07(水) 15:24:21.27

マジでrust本腰入れよ
ゾワってしたわ
C/C++書いてたけど取り残される

**デフォルトの名無しさん** · 2022/12/07(水) 15:28:39.71

>>856,874
違う
天然か煽りかわからなけどちゃんと読もうな

**デフォルトの名無しさん** · 2022/12/07(水) 15:40:23.08

せっかくモダンC++とoneTBB覚えて万能感感じてたのにさ
リセットかよ

**デフォルトの名無しさん** · 2022/12/07(水) 15:51:23.23

>>874
新規コードの20%ね
In Android 13, about 21% of all new native code (C/C++/Rust) is in Rust.

There are approximately 1.5 million total lines of Rust code in AOSP
ともあるからAOSPの全体のコード量分かればrustの割合も分かるはず

**デフォルトの名無しさん** · 2022/12/07(水) 15:52:33.64

>>878
新規コードの20%というのも不正確で新規のネイティブコードの20%
java等で書かれたものは除外したうちでの割合ね

**デフォルトの名無しさん** · 2022/12/07(水) 15:58:02.82

There are approximately 1.5 million total lines of Rust code in AOSP
*Android Open Source Project (AOSP)

1.5mてどう考えても、例によってRustコンパイラやサードcrateのソースツリーも含まれている悪寒

**デフォルトの名無しさん** · 2022/12/07(水) 16:58:18.23

>>880
AOSPのソースツリーではrustcはpre-built binaryがコミットされてるから行数カウントには含まれてないっぽい
外部crateは含まれてるかも知れないけど、実際にそれだけのコードが使われているという意味では正しいんじゃないの

**デフォルトの名無しさん** · 2022/12/07(水) 17:03:21.31

>>881
その発想がrustクオリティ

Java/C++勢はそんな嵩増ししてない

**デフォルトの名無しさん** · 2022/12/07(水) 17:15:07.05

実際に使われているC/C++
を捨てることの正当性ももう無いんだからいいじゃないか

**デフォルトの名無しさん** · 2022/12/07(水) 17:35:07.63

>>880
>1.5mてどう考えても、
同感。この短期間に150万行ってどの範囲？これが普通の感想

>>881
>AOSPのソースツリーではrustcはpre-built binaryがコミットされてる
何処？
github mirrorの方で教えて https://github.com/aosp-mirror

>>883
新規nativeコードの21%という数字が水増し、かどうかに係るので整理するべきかと

**デフォルトの名無しさん** · 2022/12/07(水) 17:40:15.78

割合とか増えていくんだからどうでもいいだろ
それよりAndroidでrustが使えるところはrustを使うという判断がとっくにされてたのが衝撃

**デフォルトの名無しさん** · 2022/12/07(水) 17:42:58.56

珍しく良い記事紹介だったのに
急に下らない議論になっちゃうのな

**デフォルトの名無しさん** · 2022/12/07(水) 17:44:20.91

>>884
GutHubでどこにあるのかは分からないがAndroid Code Searchでは以下が出てきたのでpre-built binary使ってるのかなと判断した

https://cs.android.com/android/platform/superproject/+/master:prebuilts/rust/linux-musl-x86/1.63.0/bin/rustc;l=1?q=rustc&sq=

C++もrustも外部ライブラリはexternal配下にまとめられているようなので、それぞれで集計の仕方を変えるなんて事をしてない限りは、同一条件での比較になるんじゃないかな

あと150万行ってのはAndroid13の話じゃなくて累積のコード量がって話しだよ

**デフォルトの名無しさん** · 2022/12/07(水) 17:44:50.45

>>884 追記
なんかRust批判みたいな印象になっているけど、881が多少調べたっぽいので詳しく知りたいだけ

**デフォルトの名無しさん** · 2022/12/07(水) 17:47:35.12

>>886
次世代隔離スレがなくなると暇してるオジサン達が溢れてくるのよ

**デフォルトの名無しさん** · 2022/12/07(水) 17:55:32.50

>>887 ありがと
ただし、ここ見るだれでもrustコンパイラを構成するソースファイルが山ほどある
https://cs.android.com/android/platform/superproject/+/master:prebuilts/rust/linux-musl-x86/1.63.0/src/

さすがにgccの方はsoになってる
https://cs.android.com/android/platform/superproject/+/master:prebuilts/gcc/linux-x86/

>C++もrustも外部ライブラリはexternal配下にまとめられている
こうした統計ではソースとしておいてあるかどうかで結構差がある

**はちみつ餃子** ◆8X2XSCHEME · 2022/12/07(水) 17:59:46.34

割合で言えば大したことは無くてもある程度は積極的に使おうとする雰囲気は感じなくもないってところかな。

**デフォルトの名無しさん** · 2022/12/07(水) 18:00:13.04

>>887
>あと150万行ってのはAndroid13の話じゃなくて累積のコード量がって話しだよ

累積のコード量で、Android向け書き起こしRustソースが150万行、という主張であれば水増しの疑いを持ってる

**デフォルトの名無しさん** · 2022/12/07(水) 18:01:45.15

>>891
>ある程度は積極的に使おうとする雰囲気
それは同感

**デフォルトの名無しさん** · 2022/12/07(水) 18:01:53.83

>>890
コンパイラじゃなくて標準ライブラリのことね
確かにlibcとは扱いに差があるかもね

詳細な数値が気になるならソースダウンロードして測定してみたら良いのでは
https://source.android.com/docs/setup/download/downloading

**デフォルトの名無しさん** · 2022/12/07(水) 18:04:39.07

>>894
そんな手間かけたくないから聞いたんだけど、皆そうなんだろうな

>累積のコード量で、Android向け書き起こしRustソースが150万行、という主張であれば水増しの疑いを持ってる
これで継続だな

**デフォルトの名無しさん** · 2022/12/07(水) 18:06:43.25

>>895
> Android向け書き起こしRustソースが150万行、という主張
原文ではそんな主張はしていないよ

**デフォルトの名無しさん** · 2022/12/07(水) 18:11:19.10

>>896
そう。原文は意図的かどうかは分からないが、あやふやな表現なので範囲を問うてみた
ここだけ読んでそう捉えて誤解をした人がいたら、まず範囲を疑うのが普通、と思った

**デフォルトの名無しさん** · 2022/12/07(水) 18:13:51.76

ちなみにPhoronixで読んだが、LinuxのRust対応は賞味2万行

**デフォルトの名無しさん** · 2022/12/07(水) 18:20:26.12

>>867
じゃあ一から訳したら？
誰かがそうやったから存在するんだが…

>>870
情けないよね。マージされたらそれなりに嬉しいのに。

**デフォルトの名無しさん** · 2022/12/07(水) 18:24:03.55

例えば、ここだけど、150万行はおろか、2万行すら程遠いかな
https://github.com/aosp-mirror/kernel_common/tree/android-mainline/rust

**デフォルトの名無しさん** · 2022/12/07(水) 18:36:53.47

もっと有意義な話しようぜ
fn<T>foo(x: &T); のTにSized制約付くの邪魔くせーとかさ

**デフォルトの名無しさん** · 2022/12/07(水) 18:39:18.13

>>878
そうするとまたはじめの疑問が...
> まだRustでは書きにくい所があるんだろうか？

**デフォルトの名無しさん** · 2022/12/07(水) 18:41:18.29

>>901
x: TのときはSizedついて欲しいけど、&Tのときはついて欲しくないということ？
Box<T>やRc<T>やユーザー定義のスマートポインタの扱い考えるとめんどくさいから一律Sizedがデフォルトでよくない？

**デフォルトの名無しさん** · 2022/12/07(水) 18:48:05.32

>>902
今出てきている情報だけではなんとも言えないかと
Android開発者の内Rustを使える人の割合が少ないだけの可能性もある

**デフォルトの名無しさん** · 2022/12/07(水) 18:51:46.12

>>902,904
その21%が水増しかどうかは重要なわけではなく

>ある程度は積極的に使おうとする雰囲気
これに意義がある

**デフォルトの名無しさん** · 2022/12/07(水) 18:53:03.86

そりゃC++とのInteropが絶対に必要だしRustはそこが弱い
そういう用途としてはCarbonがあるけどセキュアではない
(C++よりはマシだろうが)

**デフォルトの名無しさん** · 2022/12/07(水) 18:58:45.38

>>906
は20%(水増し？)で浮き足立ったり、Carbonの話に拘ってるけど
当分の間はCarbonの話をすると鬼が笑うと思う

**デフォルトの名無しさん** · 2022/12/07(水) 19:02:37.66

Androidの中のRustはGabeldorsche, keystore2, DoH, UWBくらいだっけ
もう3年くらいかかってるからそれなりの行数になってる気もするけどどうなんだろ
aospのrepo sync全部やるの時間かかるんだよな…

**デフォルトの名無しさん** · 2022/12/07(水) 19:05:40.97

>>908
>aospのrepo sync全部やるの時間かかるんだよな…
そこを何とかお願いします
どの範囲を集計したら150万行に到達するのか皆気になってます

**デフォルトの名無しさん** · 2022/12/07(水) 19:09:14.99

repo sync 終わらんよな
今3時間経過

**デフォルトの名無しさん** · 2022/12/07(水) 19:14:14.71

期待大

原文では
>There are approximately 1.5 million total lines of Rust code in AOSP across new functionality and components such as Keystore2, the new Ultra-wideband (UWB) stack, DNS-over-HTTP3, Android’s Virtualization framework (AVF), and various other components and their open source dependencies.
となってますので、

Keystore2
Ultra-wideband (UWB) stack
DNS-over-HTTP3
Android’s Virtualization framework (AVF)
and various other components and their open source dependencies.
これで150万行の大半を占めているかのような書き方です

まさかこれが大半を占めていたり
>open source dependencies
rustコンパイラのソースツリーが入っているとは言えませんよね

**デフォルトの名無しさん** · 2022/12/07(水) 19:30:47.68

期待すんな
gitとpython入ってるwsl環境とかあれば簡単にとってこれるぞ
https://source.android.com/docs/setup/download/downloading
ただ時間がかかるだけ
この程度出来ない奴がrustについて云々言うとか片腹痛い

**デフォルトの名無しさん** · 2022/12/07(水) 19:35:42.75

>この程度出来ない奴がrustについて云々言うとか片腹痛い
そうだね（笑）

こっちでもやってみるかな

**デフォルトの名無しさん** · 2022/12/07(水) 19:35:54.12

半年ほど前のやつがあったのでそれでtokeiかけてみた
とりあえずexternal内が180万行でprebuiltsが500万行くらい
なので1.5mの根拠はexternalの方かな
prebuiltsの方に上で挙がってたmuslとか入っている
external内はrustディレクトリ内の依存クレートが150万くらい
依存クレートでないので最大はcrosvmが30万行くらい

というわけでAndroidのために150万行書き下ろしたというのは言い過ぎ
ただ150万行のソースコード使ってるという原文の主張は正しそう（コンパイラのコードとかは入ってない）
まぁ依存クレートにも明らかにAndroid用っぽいのもあるし
これ以上の切り分けは難しいな

**デフォルトの名無しさん** · 2022/12/07(水) 19:50:48.43

>>904
それなりに優秀な人たちだと思うんたけどそれでもハードル高いのかな...

>>905
水増しとかどうでもいいのでいちいち絡んで来ないでね

**デフォルトの名無しさん** · 2022/12/07(水) 20:03:05.60

一応依存クレートも一通り見てみたけど大きいのはメジャーなやつだね
というわけでAndroidのために書かれたコードは全体で40万行以内ってとこかな

まぁtokioやらcrossbeamがちゃんと使われているのは水増しと批判するようなことではなく
むしろいいことなんじゃないか？

**デフォルトの名無しさん** · 2022/12/07(水) 22:19:15.93

それにしても無駄の多いコーディングだな。
そもそもAndroidで使われたというだけであって、Rustが広まったという訳ではない。

**デフォルトの名無しさん** · 2022/12/07(水) 22:24:52.03

かつてCが流行したのは、LatticeC、SmallC、TurboC、MS-C、WatcomC など
色んな企業がコンパイラ作りを競い合った結果だったかも知れん。
TurboCが流行ったが、それ以前からCは雑誌I/Oなどでも取り上げられて、
さまざまな人が話をし、良い言語であるという噂が立っていた。
当時を知っている俺が言わせて貰えば、なぜか、Rustはビビっとこない。
Cはビビっと来た。
C++は、初期の頃にびびっときたが、C++11では、こりゃもう駄目だ、
と思った。

**デフォルトの名無しさん** · 2022/12/07(水) 22:39:14.39

>>918 蓋を開けてみれば様々なバグ(特にメモリ関連)の元凶だったから､その感覚の逆が正解かな

**デフォルトの名無しさん** · 2022/12/07(水) 22:42:23.65

アセンブラとBASICしか無かった所に
Cが登場したから、そりゃ喜んで使うわ

**デフォルトの名無しさん** · 2022/12/07(水) 22:59:32.88

>>918
今は何にビビっと来るの？

**デフォルトの名無しさん** · 2022/12/07(水) 23:01:58.13

>>918
LSI C-86も入れといてね

**デフォルトの名無しさん** · 2022/12/07(水) 23:23:48.68

スタックかグローバル変数しか無い文化でCを流行らせてもヒープのバグは少ない

ヒープを使わないなら変数の寿命は固定長、という伏線が回収されたことに
まだ気付いてない人もいる

**デフォルトの名無しさん** · 2022/12/07(水) 23:25:35.88

>>918
ロートルは去れ

**デフォルトの名無しさん** · 2022/12/07(水) 23:26:15.82

>>921
そうだな、まだ決め手となるものは無いが、(個人的には好きではないが)JSに
人気が有るのはブラウザがそれしか使えなかったから「では無い」と思ってる。
Rubyと比較すればJSの方が優れているように感じる。
また、C#はJavaよりは改良されていると感じる。但し、これも好きではない。
Pythonも好きではない。人気が有る理由は恐らくAIのライブラリと使用例が
多いからではないかと思ってる。
ということで、今はびびっとくるものが無い。

**デフォルトの名無しさん** · 2022/12/07(水) 23:31:51.79

結局RUSTに限った話じゃなかったかw

**デフォルトの名無しさん** · 2022/12/07(水) 23:34:48.20

Rustは大々的には流行らないんじゃないと思うぞ。
理由は色々有るが、
・流行ってる言語は、JS、Python、Java、PHP、C#、Ruby、VB など、初心者向けの
　簡易言語が多い。
・Rustは中途半端。伝統を無視。習慣を無視。直感的でない。
・そもそもRustは低レベル向け言語、上記に書いた簡易言語のターゲット層には
　被らない。
なお、Googleは色んな言語に手を出す企業。
使ってる言語も幅広く、(同列に入れるべきでないものも混ざるが)
C++、NaCL(*)、Java、Kotlin(*)、Go(*)、Dart(*)、Carbon(*)、Rust、Wasm、
などなど。[(*)は自社製言語や自社製仮想言語(?)]
自社製言語だけでも4つ、仮想言語が1つ。

**デフォルトの名無しさん** · 2022/12/07(水) 23:36:08.15

MS-DOS 向けで最初に入ってきたのは
optimizing C86 だったと思う

**デフォルトの名無しさん** · 2022/12/07(水) 23:40:24.00

そもそも低レベル言語でもココまでメモリ管理に気をとられる言語はなく、
直感的に書けた。
Rustはメモリ管理ばかりに気をとられる言語。論理に集中しにくい。
また、JavaやC#、C、C++では直感的に書けることがRustでは書けない。
なお、「それはおまえがバグのコードを書いているから」と反論されるが、
はっきり言って、そのコードでも全くバグは無いから。

**デフォルトの名無しさん** · 2022/12/07(水) 23:49:55.59

隔離スレがないからとにかく昔話をしたいお爺ちゃん達のたまり場になっちゃったね

**デフォルトの名無しさん** · 2022/12/07(水) 23:56:19.06

Cが流行ったのはリンクリストが作れたからだ。
Strousutup氏はリンクリストを全否定に近い形で否定しまくっているが、
彼は机上の空論であり、彼が自分で実験してvectorの方が速いとしたものも
実際に合わない机上の空論的なベンチマークテストだったろう。
そしてそれを信じてしまったRustの作者はRustではリンクリストを
まともには使えない状態にしてしまった。

**デフォルトの名無しさん** · 2022/12/07(水) 23:59:45.09

なんだお前だったのか

**デフォルトの名無しさん** · 2022/12/08(木) 00:03:22.42

スレ立てろよ
手持ちの回線だと全部無理なんだ

**デフォルトの名無しさん** · 2022/12/08(木) 00:08:02.18

ID:Lb4jZ7zfのプライドだけ高い老害感すごいな狙ってできるもんじゃない

**デフォルトの名無しさん** · 2022/12/08(木) 00:20:06.52

一般人は馬鹿だから偉い学者さんが言った間違った言説を信じるしかない。
実験したことが現実的な状況と合ってなければ実験結果は無意味。
だから、他の経験者はリンクリストが速くてメモリー効率もいいことを知っている
のに机上の空論者であるところのStroustrup氏は、自分がやった机上の空論的な
実験結果を縦に徹底抗戦を仕掛けている。
しかし、実際と有って無いから反感を買っている。
それも、C++から人が離れていっている原因の一つ。
C++もRustもどちらも机上の空論になってる。

**デフォルトの名無しさん** · 2022/12/08(木) 00:22:10.33

>>934
老害はStroustrup氏とRustの信者の方。
Rust信者には本の謳い文句に騙された哀れな宗教信者も多いが。

**デフォルトの名無しさん** · 2022/12/08(木) 00:29:07.90

即NG㌧

**デフォルトの名無しさん** · 2022/12/08(木) 00:32:17.18

LinkedListがキャッシュ効率が悪いというのも机上の空論。
なぜなら、机上の空論者は、LinkedListのノードのアドレスが「ランダム」で
あると間違った仮定するから。
実際には基本的に連続しており、多くの場合は連続して無いとしても
軽微な数バイトの隙間がところどころ空いているだけ。
大きく変化することもあるが、それは全体の数箇所だけ。
なぜなら、挿入箇所は、一箇所から始まってその周辺を押し広げてノードを挿入している
だけで、それが少数あるだけだから、アドレスが大きく変わる箇所はわずかで、
「バースト的」になっているから。
机上の空論者は、ノードアドレスをランダムだと考えるから、キャッシュ・ミスが常に
起きると考えてしまう。ところが、そんな状況はまず有りえない。

**デフォルトの名無しさん** · 2022/12/08(木) 00:35:48.02

>>938
さらに、LinkedListのメモリー効率が悪いというのもウソで、むしろ、
std::vectorの方が悪いことが多い。
なぜなら、後者は、濃度ーを末尾追加していくと、スプリアス的に
今までの配列の入ったテーブルの1.5倍のサイズのテーブルをヒープ領域から
確保してしまう。
これが物凄く致命的で、std::vectorは、要素 T のサイズが大きい場合、
物凄くメモリー効率が悪くなる。
一方、std::list は、要素 T のサイズが大きい場合、std::vectorより遥かにメモリー効率が良い。

**デフォルトの名無しさん** · 2022/12/08(木) 00:39:53.26

>>939
[補足]
std::vectorは、sizeがcapacityを越えそうになると、今までのcapacityの
1.5倍のテーブルを新たに確保するので、今までのテーブルと合わせると、
一時的に 1 + 1.5 = 2.5 倍のメモリー領域を確保してしまう。
std::list ならこんなことは起きない。
なおさらに悪いことに、std::vectorはことの時、全要素を move するので
キャッシュが大規模に汚染されてしまう。
キャッシュ汚染という点では、std::vectorは、先頭や途中への要素追加
の際もキャッシュが大規模に汚染されてしまう。

**デフォルトの名無しさん** · 2022/12/08(木) 00:45:56.87

stroustrup氏の言説はデタラメが多くてストレスがたまる。
そして、自分が間違った説を後ろ盾するために、間違った仮定の元に
実験を行なっている。
コンピュータの実験の場合、正しい仮定のもとで行なうことが重要で、
実験して時節を裏付ける結果が出たとしても、仮定がまるっきり
間違っているのだからどうしようもない。
ベンチマークテストでも、もし、実際と合わないような内容をテストしても
意味が無い。そんな状況は滅多に起きないから。
コンピュータの測度は「加重平均値」で決まる。どういう「加重」かが、机上の空論者
には分からないからデタラメになる。
言語仕様の策定においても、実際にはそんなことをやってもほとんど意味が無いことを
優先的に簡単化しようとする一方で、もっとも重要なことがめんどくさくなるような
仕様を追加してしまったりする。
だから、C++は机上の空論といわれる。
ところが、同じことがRustにも言える。

**デフォルトの名無しさん** · 2022/12/08(木) 00:46:30.49

gccのrustフロントエンドがマージされるそうだけど、これってどういう時に便利なの？
gccでビルドしたCとのcross-language LTOとかできるの？

**デフォルトの名無しさん** · 2022/12/08(木) 01:02:47.82

>>914,916
ありがとうございますとても参考になります

こちらはパーティションを小分けにしていたせいで要領不足にあっていました
これ全体だと300GB以上あるのでしょうか？

仕方ないので
repo init -u https://android.googlesource.com/platform/manifest --depth=1 --partial-clone --clone-filter=blob:limit=10M -b android-13.0.0_r18
としたら100GB位に収まって何とか完走したところです

android-12.1.0_r26も取ってきて21%がcrosvm(当初はChromeOS向け)の移行を含んでるのかどうか見たかったのですが
話のネタが変わってしまったので週末かどこかでやり直すことにしました

**デフォルトの名無しさん** · 2022/12/09(金) 01:41:09.99

LinkedList信者まだいるんだ....
リンクリストなんて既にETHやMITでも、コンピューターサイエンスで多くの人が間違いなく否定するものなのに。別にStrousutupだけじゃないぞ？ほぼ全否定で言ってるのは
キャパを越えそうな事を無理やりするのはほぼ設計の問題だし、途中への要素追加が起きるようなコードを書いてて問題ないと思ってるのはプログラマの能力の問題。
バースト的なんて言ってるけど、連続するメモリー領域へのアクセスと比べて明らかにリンクリストが不利になるのは自明だ、さらに逆に途中追加した場合のキャッシュミスを汚染なんて言ってるけど
それこそ現代の多段キャッシュアーキテクチャを甘く見すぎてる。そりゃ容量を超えるような操作を行えばメインメモリに取りに行くけど、言うまでもないがリンクリストの要素の先はメインメモリー散らばってる。
それがキャッシュされるとしてもCPUのキャッシュは1Byteとか8Byteをキャッシュするものじゃなく1キャッシュブロックで連続するメモリーをk単位でキャッシュする。
StrousutupのC++は明らかに欠陥言語だが、それとデーター構造の理解は別の問題。コンピュータの速度は加重平均なんていう単純なもんではない
すべてがキャッシュに乗るなら一番早く動くが、メインメモリを頻繁にアクセスするなら100倍遅くなる。メインメモリにさえ載りきらないデータを扱いHDDならそこからさらに1000倍遅い。
だがキャッシュの容量しかデータを扱えないプログラムは役に立たたないし、Swapしまくりのプログラムは実用に耐えない。
まだLinkedListを擁護する人が多いのは、欧米のように日本のプログラマーは文系や高卒がやり、明らかにまともに計算機科学というものを受けていないからだ
Rustこそ欧州主体で行われている計算機科学にあまり即してない、FORTRANみたいな米国主導のLinkedListのような産物

**デフォルトの名無しさん** · 2022/12/09(金) 02:35:24.01

なんだかRubyガイジみたいな論法だよな
Rubyでできることはすばらしいこと
Rubyでできないことは必要ないこと

いや必要あるか、使うかどうかは検討の上こっちが決めるんで😅

**デフォルトの名無しさん** · 2022/12/09(金) 08:53:27.93

関数型のElixir は、先頭だけに追加できる片方向リストで、
データが変更されない・immutable だから、バグらない

x = a-b の時に、
先頭に、c を追加して、y = c-a-b となった時に、
a-bの部分が変更されないので、x, y 両方で再利用できる

**デフォルトの名無しさん** · 2022/12/09(金) 09:23:54.41

>>944
絶対ネタで書いてるだろｗ

**デフォルトの名無しさん** · 2022/12/09(金) 13:50:41.90

>>944
CPUにおいて、基本的に cache block と cache line は同じ意味だが、
https://stackoverflow.com/questions/14707803/line-size-of-l1-and-l2-caches
のように、Intel CPUにおけるcache lineの大きさは 64バイト。
先読み機能が有るので、少し先まで読むことがあるが、
1KBみたいに大きくは無い。

**デフォルトの名無しさん** · 2022/12/09(金) 13:58:22.82

>>944
コンピュータ科学ではむしろ、LinkedListがArrayListより速いことがあることを学ぶ。

**デフォルトの名無しさん** · 2022/12/09(金) 14:00:08.53

>>944
>言うまでもないがリンクリストの要素の先はメインメモリー散らばってる。
現実的な使用法では、バースト的になっていて、散らばってない。
散らばっていると思っている人が現実を知らない机上の空論家だと言っている。

**デフォルトの名無しさん** · 2022/12/09(金) 14:03:46.44

>>950
[補足]
バース的で無い場合においても、非常に近いアドレスになっていることが多い。
例えば、ノードを削除してから追加すると、最後に削除されたアドレスが再利用されるから、
データ列を加工する場合にはキャッシュがとても強く働く。
また、ソートにおいてもノードの繋ぎ方を変えるだけだから、コピーはおろか、
ムーブすら発生せず、要素Tのバイト数sizeof(T)が十分大きい場合は、
std::vectorより速い。

**デフォルトの名無しさん** · 2022/12/09(金) 14:08:27.79

>>944
>コンピュータの速度は加重平均なんていう単純なもんではない
加重平均である事と、単純である事は同じことでは無い。
単純ではないが、加重平均である。
実行時間 T = Σ_i w_i T_i
w_i = 処理 i に対する重みパラメータ
T_i = 処理 i に掛かる時間

w_i は、経験を積まないとわからなくて、机上の空論家はこれを誤って見積もる。
偉いとされる先生を筆頭とした「象牙の塔」の集団幻覚の様な現象が起きる。

**デフォルトの名無しさん** · 2022/12/09(金) 14:13:39.03

>>951
[さらに補足]
・ノードを削除してから追加する--->malloc や new が、直近に
　削除したノードのアドレスを再利用されるのでキャッシュが良く効く。
・削除したノードのメモリ・ブロックが全部使われた場合、
　malloc や new がHeapやOSから新しくアドレスを確保してくる -->
　OSは後続の連続アドレスを返してくるので、アドレスはほぼ連続
　するので、キャッシュが良く効く。

故に、実際的な使用においては、LinkedListはキャッシュがよく効く。
　
　

**デフォルトの名無しさん** · 2022/12/09(金) 14:18:24.24

たとえば、馬鹿な人は、通信経路においてのエラーは「ランダムに起きる」から、
「本当にランダム」のケースを脳内で勝手に想像して、
「CRC符合は一般には役に立たない」
と結論付けてしまうかも知れないが、それは机上の空論で、
実際のエラーはバースト的に起きるから、CRC符合は非常に強力に働く。
それと同様にLinkedListもキャッシュが良く効く。
なぜならノードのアドレスが「ランダム」ではないから。

**デフォルトの名無しさん** · 2022/12/09(金) 15:08:04.74

どっちもヤバくて草w