Rust part17

1 名前：デフォルトの名無しさん mailto:sage [2022/10/06(木) 22:43:13.96 ID:Re0G7B20.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を学ぶ際に犯しがちな12の過ち https://dystroy.org/blog/how-not-to-learn-rust ※Rustのasyncについて知りたければ「async-book」は必読 https://rust-lang.github.io/async-book/ ※次スレは原則>>980が立てること 前スレ Rust part16 855 名前：デフォルトの名無しさん [2022/12/07(水) 00:09:51.51 ID:IJoOi7Sy.net] 文献や資料の質を見極める力もプログラマーにとってはかなり重要な能力 質の低い文献にひっかかったなら失敗から学べ 856 名前：デフォルトの名無しさん [2022/12/07(水) 00:21:26.68 ID:rpgrLTt2.net] AndroidもRustで書かれてたのかよ！ しかもRustの部分は脆弱性の報告０件って恐ろしいほどの安全性だな…… これマジでRust一強の時代がくるかも…… Ubuntuにデフォルトで入るまで待とうとのん気に構えてたけど急いで勉強しないと……！〆(.. )ｶﾘｶﾘｯ!! https://japan.zdnet.com/article/35196972/ 857 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 00:35:34.36 ID:21cwGaas.net] >>845 まじ？ というか20%がrustってえぐいな 858 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 00:41:52.20 ID:xT6Hu5AC.net] C/C++ の書き方の何が危ないのか、Rustはどうやって回避しているのかは何を読めば分かるの？ Out of memory なんか防げるんだっけ？ 859 名前：デフォルトの名無しさん [2022/12/07(水) 00:58:54.43 ID:fQ3/NsZR.net] kLOCあたり1つ以上の脆弱性があったものが1500kLOCでゼロ unsafeが量も気になるな 860 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 01:00:43.82 ID:+scmKVbE.net] Google製のRustライブラリはどんなのがあんの？ 861 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 04:00:04.20 ID:0xPH+d9p.net] >>845 > システムプログラミングからCやC++を排除するつもりはないという。 これの理由を知りたいわ まだRustでは書きにくい所があるんだろうか？ 862 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 04:05:04.23 ID:+scmKVbE.net] ってか、Googleはその分野で使うためにCarbon開発したんじゃなかったのか？ 863 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 04:17:31.35 ID:21cwGaas.net] CarbonもRust使えるならRust使えと言ってる 864 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 09:06:42.16 ID:Mw8qZqut.net] google発のOSSって社員の個人プロジェクトをgoogle名義で公開してるだけの場合もあるからな 865 名前：はちみつ餃子 mailto:sage [2022/12/07(水) 09:19:24.95 ID:vqEtcxl0.net] どれがいい感じに発展するか事前にわかるもんではないからな。 狙いとは違う方向で結実することもあるし。 色々やっておく (それが出来る環境を用意する) とどれかは上手くいくし、上手くいかずに消えるものも多いってだけのこと。 866 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 10:24:44.39 ID:G2nMx9FR.net] そこまで誤訳だと言うならコントリビューションすれば良いのではないの？ 867 名前：デフォルトの名無しさん [2022/12/07(水) 10:39:11.42 ID:KNXoSnHr.net] >>845 結果だけみると凄まじい システムプログラミング関係の置き換えは案外急速に進むかもしれんね 868 名前：デフォルトの名無しさん [2022/12/07(水) 11:16:25.80 ID:6Eaq6nhz.net] >>855 誤訳だらけでキリがない ゴミから小さなゴミを取り除いてもゴミのまま だれがそんなことに時間使うのさ 869 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 12:26:52.65 ID:El0pJGUF.net] >>857 2chで文句言って他の話題を出にくくする方が有意義だと思うやつもいるんだな。 870 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 12:31:58.03 ID:74PfFudB.net] 複おじ以前と以後で明らかに話題の質が落ちてるよね おのれ複おじ 871 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 12:39:55.04 ID:m46mCwKQ.net] >>855 難癖つけて嘲笑って愉しんている奴がそんな無駄なことするわけがない。 自分がマウントできればいいだけだから、そもそもRustを良くする気なんて全く無いだろ。 872 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 12:46:13.68 ID:g3+WCnxI.net] >>850 Cなら分かるがRustが分からない人 のことを老人と思うのは憶測で、むしろ子供である可能性が高い 子供を排除や淘汰しても進歩など起きない 少子化が加速するだけ 873 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 12:53:44.84 ID:Mw8qZqut.net] >>850 元記事に以下とあるから既存のコードを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. 874 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 12:54:18.57 ID:Mw8qZqut.net] >>862 元記事のurl貼り忘れた https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html 875 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 15:17:49.39 ID:Xzjw4n/l.net] >>862-863 ありがとう、まあ普通はそうするよね ただそうするとAndroid 13は20%が新規のコードなんだ... それはそれで凄いな 876 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 15:24:21.27 ID:3HHCfxiv.net] マジでrust本腰入れよ ゾワってしたわ C/C++書いてたけど取り残される 877 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 15:28:39.71 ID:h/t9+qo5.net] >>846,864 違う 天然か煽りかわからなけどちゃんと読もうな 878 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 15:40:23.08 ID:3HHCfxiv.net] せっかくモダンC++とoneTBB覚えて万能感感じてたのにさ リセットかよ 879 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 15:51:23.23 ID:Mw8qZqut.net] >>864 新規コードの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の割合も分かるはず 880 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 15:52:33.64 ID:Mw8qZqut.net] >>868 新規コードの20%というのも不正確で新規のネイティブコードの20% java等で書かれたものは除外したうちでの割合ね 881 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 15:58:02.82 ID:JdTFl5al.net] There are approximately 1.5 million total lines of Rust code in AOSP *Android Open Source Project (AOSP) 1.5mてどう考えても、例によってRustコンパイラやサードcrateのソースツリーも含まれている悪寒 882 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 16:58:18.23 ID:Mw8qZqut.net] >>870 AOSPのソース 883 名前：ツリーではrustcはpre-built binaryがコミットされてるから行数カウントには含まれてないっぽい 外部crateは含まれてるかも知れないけど、実際にそれだけのコードが使われているという意味では正しいんじゃないの [] [ここ壊れてます] 884 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 17:03:21.31 ID:n0jQbyrj.net] >>871 その発想がrustクオリティ Java/C++勢はそんな嵩増ししてない 885 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 17:15:07.05 ID:g3+WCnxI.net] 実際に使われているC/C++ を捨てることの正当性ももう無いんだからいいじゃないか 886 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 17:35:07.63 ID:8PgDeggG.net] >>870 >1.5mてどう考えても、 同感。この短期間に150万行ってどの範囲？これが普通の感想 >>871 >AOSPのソースツリーではrustcはpre-built binaryがコミットされてる 何処？ github mirrorの方で教えて https://github.com/aosp-mirror >>873 新規nativeコードの21%という数字が水増し、かどうかに係るので整理するべきかと 887 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 17:40:15.78 ID:21cwGaas.net] 割合とか増えていくんだからどうでもいいだろ それよりAndroidでrustが使えるところはrustを使うという判断がとっくにされてたのが衝撃 888 名前：デフォルトの名無しさん [2022/12/07(水) 17:42:58.56 ID:NHS9DFe3.net] 珍しく良い記事紹介だったのに 急に下らない議論になっちゃうのな 889 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 17:44:20.91 ID:Mw8qZqut.net] >>874 GutHubでどこにあるのかは分からないがAndroid Code Searchでは以下が出てきたのでpre-built binary使ってるのかなと判断した https://cs.android.com/android/platform/superproject/+/maste 890 名前：r:prebuilts/rust/linux-musl-x86/1.63.0/bin/rustc;l=1?q=rustc&sq= C++もrustも外部ライブラリはexternal配下にまとめられているようなので、それぞれで集計の仕方を変えるなんて事をしてない限りは、同一条件での比較になるんじゃないかな あと150万行ってのはAndroid13の話じゃなくて累積のコード量がって話しだよ [] [ここ壊れてます] 891 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 17:44:50.45 ID:8PgDeggG.net] >>874 追記 なんかRust批判みたいな印象になっているけど、881が多少調べたっぽいので詳しく知りたいだけ 892 名前：デフォルトの名無しさん [2022/12/07(水) 17:47:35.12 ID:JLiaiVk0.net] >>876 次世代隔離スレがなくなると暇してるオジサン達が溢れてくるのよ 893 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 17:55:32.50 ID:8PgDeggG.net] >>877 ありがと ただし、ここ見るだれでも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配下にまとめられている こうした統計ではソースとしておいてあるかどうかで結構差がある 894 名前：はちみつ餃子 mailto:sage [2022/12/07(水) 17:59:46.34 ID:vqEtcxl0.net] 割合で言えば大したことは無くてもある程度は積極的に使おうとする雰囲気は感じなくもないってところかな。 895 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 18:00:13.04 ID:8PgDeggG.net] >>877 >あと150万行ってのはAndroid13の話じゃなくて累積のコード量がって話しだよ 累積のコード量で、Android向け書き起こしRustソースが150万行、という主張であれば水増しの疑いを持ってる 896 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 18:01:45.15 ID:8PgDeggG.net] >>881 >ある程度は積極的に使おうとする雰囲気 それは同感 897 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 18:01:53.83 ID:Mw8qZqut.net] >>880 コンパイラじゃなくて標準ライブラリのことね 確かにlibcとは扱いに差があるかもね 詳細な数値が気になるならソースダウンロードして測定してみたら良いのでは https://source.android.com/docs/setup/download/downloading 898 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 18:04:39.07 ID:8PgDeggG.net] >>884 そんな手間かけたくないから聞いたんだけど、皆そうなんだろうな >累積のコード量で、Android向け書き起こしRustソースが150万行、という主張であれば水増しの疑いを持ってる これで継続だな 899 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 18:06:43.25 ID:Mw8qZqut.net] >>885 > Android向け書き起こしRustソースが150万行、という主張 原文ではそんな主張はしていないよ 900 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 18:11:19.10 ID:8PgDeggG.net] >>886 そう。原文は意図的かどうかは分からないが、あやふやな表現なので範囲を問うてみた ここだけ読んでそう捉えて誤解をした人がいたら、まず範囲を疑うのが普通、と思った 901 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 18:13:51.76 ID:8PgDeggG.net] ちなみにPhoronixで読んだが、LinuxのRust対応は賞味2万行 902 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 18:20:26.12 ID:wjXnim/d.net] >>857 じゃあ一から訳したら？ 誰かがそうやったから存在するんだが… >>860 情けないよね。マージされたらそれなりに嬉しいのに。 903 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 18:24:03.55 ID:8PgDeggG.net] 例えば、ここだけど、150万行はおろか、2万行すら程遠いかな https://github.com/aosp-mirror/kernel_common/tree/android-mainline/rust 904 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 18:36:53.47 ID:M+Adnv0G.net] もっと有意義な話しようぜ fn<T>foo(x: &T); のTにSized制約付くの邪魔くせーとかさ 905 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 18:39:18.13 ID:CifLjB7G.net] >>868 そうするとまたはじめの疑問が... > まだRustでは書きにくい所があるんだろうか？ 906 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 18:41:18.29 ID:Mw8qZqut.net] >>891 x: TのときはSizedついて欲しいけど、&Tのときはついて欲しくないということ？ Box<T>やRc<T>やユーザー定義のスマートポインタの扱い考えるとめんどくさいから一律Sizedがデフォルトでよくない？ 907 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 18:48:05.32 ID:Mw8qZqut.net] >>892 今出てきている情報だけではなんとも言えないかと Android開発者の内Rustを使える人の割合が少ないだけの可能性もある 908 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 18:51:46.12 ID:8PgDeggG.net] >>892,894 その21%が水増しかどうかは重要なわけではなく >ある程度は積極的に使おうとする雰囲気 これに意義がある 909 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 18:53:03.86 ID:21cwGaas.net] そりゃC++とのInteropが絶対に必要だしRustはそこが弱い そういう用途としてはCarbonがあるけどセキュアではない (C++よりはマシだろうが) 910 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 18:58:45.38 ID:8PgDeggG.net] >>896 は20%(水増し？)で浮き足立ったり、Carbonの話に拘ってるけど 当分の間はCarbonの話をすると鬼が笑うと思う 911 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 19:02:37.66 ID:glN0FB8M.net] Androidの中のRustはGabeldorsche, keystore2, DoH, UWBくらいだっけ もう3年くらいかかってるからそれなりの行数になってる気もするけどどうなんだろ aospのrepo sync全部やるの時間かかるんだよな… 912 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 19:05:40.97 ID:8PgDeggG.net] >>898 >aospのrepo sync全部やるの時間かかるんだよな… そこを何とかお願いします どの範囲を集計したら150万行に到達するのか皆気になってます 913 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 19:09:14.99 ID:/TInWduh.net] repo sync 終わらんよな 今3時間経過 914 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 19:14:14.71 ID:8PgDeggG.net] 期待大 原文では >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コンパイラのソースツリーが入っているとは言えませんよね 915 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 19:30:47.68 ID:/TInWduh.net] 期待すんな gitとpython入ってるwsl環境とかあれば簡単にとってこれるぞ https://source.android.com/docs/setup/download/downloading ただ時間がかかるだけ この程度出来ない奴がrustについて云々言うとか片腹痛い 916 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 19:35:42.75 ID:8PgDeggG.net] >この程度出来ない奴がrustについて云々言うとか片腹痛い そうだね（笑） こっちでもやってみるかな 917 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 19:35:54.12 ID:glN0FB8M.net] 半年ほど前のやつがあったのでそれでtokeiかけてみた とりあえずexternal内が180万行でprebuiltsが500万行くらい なので1.5mの根拠はexternalの方かな prebuiltsの方に上で挙がってたmuslとか入っている external内はrustディレクトリ内の依存クレートが150万くらい 依存クレートでないので最大はcrosvmが30万行くらい というわけでAndroidのために150万行書き下ろしたというのは言い過ぎ ただ150万行のソースコード使ってるという原文の主張は正しそう（コンパイラのコードとかは入ってない） まぁ依存クレートにも明らかにAndroid用っぽいのもあるし これ以上の切り分けは難しいな 918 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 19:50:48.43 ID:CifLjB7G.net] >>894 それなりに優秀な人たちだと思うんたけどそれでもハードル高いのかな... >>895 水増しとかどうでもいいのでいちいち絡んで来ないでね 919 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 20:03:05.60 ID:glN0FB8M.net] 一応依存クレートも一通り見てみたけど大きいのはメジャーなやつだね というわけでAndroidのために書かれたコードは全体で40万行以内ってとこかな まぁtokioやらcrossbeamがちゃんと使われているのは水増しと批判するようなことではなく むしろいいことなんじゃないか？ 920 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 22:19:15.93 ID:Lb4jZ7zf.net] それにしても無駄の多いコーディングだな。 そもそもAndroidで使われたというだけであって、Rustが広まったという訳ではない。 921 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 22:24:52.03 ID:Lb4jZ7zf.net] かつてCが流行したのは、LatticeC、SmallC、TurboC、MS-C、WatcomC など 色んな企業がコンパイラ作りを競い合った結果だったかも知れん。 TurboCが流行ったが、それ以前からCは雑誌I/Oなどでも取り上げられて、 さまざまな人が話をし、良い言語であるという噂が立っていた。 当時を知っている俺が言わせて貰えば、なぜか、Rustはビビっとこない。 Cはビビっと来た。 C++は、初期の頃にびびっときたが、C++11では、こりゃもう駄目だ、 と思った。 922 名前：デフォルトの名無しさん [2022/12/07(水) 22:39:14.39 ID:UARY1o0b.net] >>908 蓋を開けてみれば様々なバグ(特にメモリ関連)の元凶だったから､その感覚の逆が正解かな 923 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 22:42:23.65 ID:cTs8jKu4.net] アセンブラとBASICしか無かった所に Cが登場したから、そりゃ喜んで使うわ 924 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 22:59:32.88 ID:Odhm3loP.net] >>908 今は何にビビっと来るの？ 925 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 23:01:58.13 ID:Xa+0WmXy.net] >>908 LSI C-86も入れといてね 926 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 23:23:48.68 ID:g3+WCnxI.net] スタックかグローバル変数しか無い文化でCを流行らせてもヒープのバグは少ない ヒープを使わないなら変数の寿命は固定長、という伏線が回収されたことに まだ気付いてない人もいる 927 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 23:25:35.88 ID:21cwGaas.net] >>908 ロートルは去れ 928 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 23:26:15.82 ID:Lb4jZ7zf.net] >>911 そうだな、まだ決め手となるものは無いが、(個人的には好きではないが)JSに 人気が有るのはブラウザがそれしか使えなかったから「では無い」と思ってる。 Rubyと比較すればJSの方が優れているように感じる。 また、C#はJavaよりは改良されていると感じる。但し、これも好きではない。 Pythonも好きではない。人気が有る理由は恐らくAIのライブラリと使用例が 多いからではないかと思ってる。 ということで、今はびびっとくるものが無い。 929 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 23:31:51.79 ID:Xa+0WmXy.net] 結局RUSTに限った話じゃなかったかw 930 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 23:34:48.20 ID:Lb4jZ7zf.net] Rustは大々的には流行らないんじゃないと思うぞ。 理由は色々有るが、 ・流行ってる言語は、JS、Python、Java、PHP、C#、Ruby、VB など、初心者向けの 　簡易言語が多い。 ・Rustは中途半端。伝統を無視。習慣を無視。直感的でない。 ・そもそもRustは低レベル向け言語、上記に書いた簡易言語のターゲット層には 　被らない。 なお、Googleは色んな言語に手を出す企業。 使ってる言語も幅広く、(同列に入れるべきでないものも混ざるが) C++、NaCL(*)、Java、Kotlin(*)、Go(*)、Dart(*)、Carbon(*)、Rust、Wasm、 などなど。[(*)は自社製言語や自社製仮想言語(?)] 自社製言語だけでも4つ、仮想言語が1つ。 931 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 23:36:08.15 ID:cTs8jKu4.net] MS-DOS 向けで最初に入ってきたのは optimizing C86 だったと思う 932 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 23:40:24.00 ID:Lb4jZ7zf.net] そもそも低レベル言語でもココまでメモリ管理に気をとられる言語はなく、 直感的に書けた。 Rustはメモリ管理ばかりに気をとられる言語。論理に集中しにくい。 また、JavaやC#、C、C++では直感的に書けることがRustでは書けない。 なお、「それはおまえがバグのコードを書いているから」と反論されるが、 はっきり言って、そのコードでも全くバグは無いから。 933 名前：デフォルトの名無しさん [2022/12/07(水) 23:49:55.59 ID:51+7TkbX.net] 隔離スレがないからとにかく昔話をしたいお爺ちゃん達のたまり場になっちゃったね 934 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 23:56:19.06 ID:Lb4jZ7zf.net] Cが流行ったのはリンクリストが作れたからだ。 Strousutup氏はリンクリストを全否定に近い形で否定しまくっているが、 彼は机上の空論であり、彼が自分で実験してvectorの方が速いとしたものも 実際に合わない机上の空論的なベンチマークテストだったろう。 そしてそれを信じてしまったRustの作者はRustではリンクリストを まともには使えない状態にしてしまった。 935 名前：デフォルトの名無しさん mailto:sage [2022/12/07(水) 23:59:45.09 ID:sHYfIE3H.net] なんだお前だったのか 936 名前：デフォルトの名無しさん mailto:sage [2022/12/08(木) 00:03:22.42 ID:kNVI3qAc.net] スレ立てろよ 手持ちの回線だと全部無理なんだ 937 名前：デフォルトの名無しさん mailto:sage [2022/12/08(木) 00:08:02.18 ID:QroOE5Fs.net] ID:Lb4jZ7zfのプライドだけ高い老害感すごいな 狙ってできるもんじゃない 938 名前：デフォルトの名無しさん mailto:sage [2022/12/08(木) 00:20:06.52 ID:pMPEGjtK.net] 一般人は馬鹿だから偉い学者さんが言った間違った言説を信じるしかない。 実験したことが現実的な状況と合ってなければ実験結果は無意味。 だから、他の経験者はリンクリストが速くてメモリー効率もいいことを知っている のに机上の空論者であるところのStroustrup氏は、自分がやった机上の空論的な 実験結果を縦に徹底抗戦を仕掛けている。 しかし、実際と有って無いから反感を買っている。 それも、C++から人が離れていっている原因の一つ。 C++もRustもどちらも机上の空論になってる。 939 名前：デフォルトの名無しさん mailto:sage [2022/12/08(木) 00:22:10.33 ID:pMPEGjtK.net] >>924 老害はStroustrup氏とRustの信者の方。 Rust信者には本の謳い文句に騙された哀れな宗教信者も多いが。 940 名前：デフォルトの名無しさん [2022/12/08(木) 00:29:07.90 ID:WCqcOtXz.net] 即NG㌧ 941 名前：デフォルトの名無しさん mailto:sage [2022/12/08(木) 00:32:17.18 ID:pMPEGjtK.net] LinkedListがキャッシュ効率が悪いというのも机上の空論。 なぜなら、机上の空論者は、LinkedListのノードのアドレスが「ランダム」で あると間違った仮定するから。 実際には基本的に連続しており、多くの場合は連続して無いとしても 軽微な数バイトの隙間がところどころ空いているだけ。 大きく変化することもあるが、それは全体の数箇所だけ。 なぜなら、挿入箇所は、一箇所から始まってその周辺を押し広げてノードを挿入している だけで、それが少数あるだけだから、アドレスが大きく変わる箇所はわずかで、 「バースト的」になっているから。 机上の空論者は、ノードアドレスをランダムだと考えるから、キャッシュ・ミスが常に 起きると考えてしまう。ところが、そんな状況はまず有りえない。 942 名前：デフォルトの名無しさん mailto:sage [2022/12/08(木) 00:35:48.02 ID:pMPEGjtK.net] >>928 さらに、LinkedListのメモリー効率が悪いというのもウソで、むしろ、 std::vectorの方が悪いことが多い。 なぜなら、後者は、濃度ーを末尾追加していくと、スプリアス的に 今までの配列の入ったテーブルの1.5倍のサイズのテーブルをヒープ領域から 確保してしまう。 これが物凄く致命的で、std::vectorは、要素 T のサイズが大きい場合、 物凄くメモリー効率が悪くなる。 一方、std::list は、要素 T のサイズが大きい場合、std::vectorより遥かにメモリー効率が良い。 943 名前：デフォルトの名無しさん mailto:sage [2022/12/08(木) 00:39:53.26 ID:pMPEGjtK.net] >>929 [補足] std::vectorは、sizeがcapacityを越えそうになると、今までのcapacityの 1.5倍のテーブルを新たに確保するので、今までのテーブルと合わせると、 一時的に 1 + 1.5 = 2.5 倍のメモリー領域を確保してしまう。 std::list ならこんなことは起きない。 なおさらに悪いことに、std::vectorはことの時、全要素を move するので キャッシュが大規模に汚染されてしまう。 キャッシュ汚染という点では、std::vectorは、先頭や途中への要素追加 の際もキャッシュが大規模に汚染されてしまう。 944 名前：デフォルトの名無しさん mailto:sage [2022/12/08(木) 00:45:56.87 ID:pMPEGjtK.net] stroustrup氏の言説はデタラメが多くてストレスがたまる。 そして、自分が間違った説を後ろ盾するために、間違った仮定の元に 実験を行なっている。 コンピュータの実験の場合、正しい仮定のもとで行なうことが重要で、 実験して時節を裏付ける結果が出たとしても、仮定がまるっきり 間違っているのだからどうしようもない。 ベンチマークテストでも、もし、実際と合わないような内容をテストしても 意味が無い。そんな状況は滅多に起きないから。 コンピュータの測度は「加重平均値」で決まる。どういう「加重」かが、机上の空論者 には分からないからデタラメになる。 言語仕様の策定においても、実際にはそんなことをやってもほとんど意味が無いことを 優先的に簡単化しようとする一方で、もっとも重要なことがめんどくさくなるような 仕様を追加してしまったりする。 だから、C++は机上の空論といわれる。 ところが、同じことがRustにも言える。 945 名前：デフォルトの名無しさん mailto:sage [2022/12/08(木) 00:46:30.49 ID:rnWAZYk7.net] gccのrustフロントエンドがマージされるそうだけど、これってどういう時に便利なの？ gccでビルドしたCとのcross-language LTOとかできるの？ 946 名前：デフォルトの名無しさん mailto:sage [2022/12/08(木) 01:02:47.82 ID:D2mGrKMe.net] >>904,906 ありがとうございます とても参考になります こちらはパーティションを小分けにしていたせいで要領不足にあっていました これ全体だと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向け)の移行を含んでるのかどうか見たかったのですが 話のネタが変わってしまったので週末かどこかでやり直すことにしました 947 名前：デフォルトの名無しさん mailto:sage [2022/12/09(金) 01:41:09.99 ID:Sh2LVmg/.net] LinkedList信者まだいるんだ.... リンクリストなんて既にETHやMITでも、コンピューターサイエンスで多くの人が間違いなく否定するものなのに。別にStrousutupだけじゃないぞ？ほぼ全否定で言ってるのは キャパを越えそうな事を無理やりするのはほぼ設計の問題だし、途中への要素追加が起きるようなコードを書いてて問題ないと思ってるのはプログラマの能力の問題。 バースト的なんて言ってるけど、連続するメモリー領域へのアクセスと比べて明らかにリンクリストが不利になるのは自明だ、さらに逆に途中追加した場合のキャッシュミスを汚染なんて言ってるけど それこそ現代の多段キャッシュアーキテクチャを甘く見すぎてる。そりゃ容量を超えるような操作を行えばメインメモリに取りに行くけど、言うまでもないがリンクリストの要素の先はメインメモリー散らばってる。 それがキャッシュされるとしてもCPUのキャッシュは1Byteとか8Byteをキャッシュするものじゃなく1キャッシュブロックで連続するメモリーをk単位でキャッシュする。 StrousutupのC++は明らかに欠陥言語だが、それとデーター構造の理解は別の問題。 コンピュータの速度は加重平均なんていう単純なもんではない すべてがキャッシュに乗るなら一番早く動くが、メインメモリを頻繁にアクセスするなら100倍遅くなる。メインメモリにさえ載りきらないデータを扱いHDDならそこからさらに1000倍遅い。 だがキャッシュの容量しかデータを扱えないプログラムは役に立たたないし、Swapしまくりのプログラムは実用に耐えない。 まだLinkedListを擁護する人が多いのは、欧米のように日本のプログラマーは文系や高卒がやり、明らかにまともに計算機科学というものを受けていないからだ Rustこそ欧州主体で行われている計算機科学にあまり即してない、FORTRANみたいな米国主導のLinkedListのような産物 948 名前：デフォルトの名無しさん [2022/12/09(金) 02:35:24.01 ID:wDDTmzGU.net] なんだかRubyガイジみたいな論法だよな Rubyでできることはすばらしいこと Rubyでできないことは必要ないこと いや必要あるか、使うかどうかは検討の上こっちが決めるんで😅 949 名前：デフォルトの名無しさん mailto:sage [2022/12/09(金) 08:53:27.93 ID:eLXAv6sJ.net] 関数型のElixir は、先頭だけに追加できる片方向リストで、 データが変更されない・immutable だから、バグらない x = a-b の時に、 先頭に、c を追加して、y = c-a-b となった時に、 a-bの部分が変更されないので、x, y 両方で再利用できる 950 名前：デフォルトの名無しさん mailto:sage [2022/12/09(金) 09:23:54.41 ID:Bd/06DhF.net] >>934 絶対ネタで書いてるだろｗ 951 名前：デフォルトの名無しさん mailto:sage [2022/12/09(金) 13:50:41.90 ID:3DNXTGzR.net] >>934 CPUにおいて、基本的に cache block と cache line は同じ意味だが、 https://stackoverflow.com/questions/14707803/line-size-of-l1-and-l2-caches のように、Intel CPUにおけるcache lineの大きさは 64バイト。 先読み機能が有るので、少し先まで読むことがあるが、 1KBみたいに大きくは無い。 952 名前：デフォルトの名無しさん mailto:sage [2022/12/09(金) 13:58:22.82 ID:3DNXTGzR.net] >>934 コンピュータ科学ではむしろ、LinkedListがArrayListより速いことがあることを学ぶ。 953 名前：デフォルトの名無しさん mailto:sage [2022/12/09(金) 14:00:08.53 ID:3DNXTGzR.net] >>934 >言うまでもないがリンクリストの要素の先はメインメモリー散らばってる。 現実的な使用法では、バースト的になっていて、散らばってない。 散らばっていると思っている人が現実を知らない机上の空論家だと言っている。 954 名前：デフォルトの名無しさん mailto:sage [2022/12/09(金) 14:03:46.44 ID:3DNXTGzR.net] >>940 [補足] バース的で無い場合においても、非常に近いアドレスになっていることが多い。 例えば、ノードを削除してから追加すると、最後に削除されたアドレスが再利用されるから、 データ列を加工する場合にはキャッシュがとても強く働く。 また、ソートにおいてもノードの繋ぎ方を変えるだけだから、コピーはおろか、 ムーブすら発生せず、要素Tのバイト数sizeof(T)が十分大きい場合は、 std::vectorより速い。 955 名前：デフォルトの名無しさん mailto:sage [2022/12/09(金) 14:08:27.79 ID:3DNXTGzR.net] >>934 >コンピュータの速度は加重平均なんていう単純なもんではない 加重平均である事と、単純である事は同じことでは無い。 単純ではないが、加重平均である。 実行時間 T = Σ_i w_i T_i w_i = 処理 i に対する重みパラメータ T_i = 処理 i に掛かる時間 w_i は、経験を積まないとわからなくて、机上の空論家はこれを誤って見積もる。 偉いとされる先生を筆頭とした「象牙の塔」の集団幻覚の様な現象が起きる。 956 名前：デフォルトの名無しさん mailto:sage [2022/12/09(金) 14:13:39.03 ID:3DNXTGzR.net] >>941 [さらに補足] ・ノードを削除してから追加する--->malloc や new が、直近に 　削除したノードのアドレスを再利用されるのでキャッシュが良く効く。 ・削除したノードのメモリ・ブロックが全部使われた場合、 　malloc や new がHeapやOSから新しくアドレスを確保してくる --> 　OSは後続の連続アドレスを返してくるので、アドレスはほぼ連続 　するので、キャッシュが良く効く。 故に、実際的な使用においては、LinkedListはキャッシュがよく効く。 　 　 957 名前：デフォルトの名無しさん mailto:sage [2022/12/09(金) 14:18:24.24 ID:3DNXTGzR.net] たとえば、馬鹿な人は、通信経路においてのエラーは「ランダムに起きる」から、 「本当にランダム」のケースを脳内で勝手に想像して、 「CRC符合は一般には役に立たない」 と結論付けてしまうかも知れないが、それは机上の空論で、 実際のエラーはバースト的に起きるから、CRC符合は非常に強力に働く。 それと同様にLinkedListもキャッシュが良く効く。 なぜならノードのアドレスが「ランダム」ではないから。 958 名前：デフォルトの名無しさん [2022/12/09(金) 15:08:04.74 ID:gsPXBpPV.net] どっちもヤバくて草w 959 名前：デフォルトの名無しさん mailto:sage [2022/12/09(金) 16:41:02.60 ID:WiULU0Bz.net] 自己完結すれば最速で完結するが 机上で完結しないことを望むなら呪術的な対価を要求されるんだよ 960 名前：デフォルトの名無しさん [2022/12/09(金) 17:13:50.21 ID:TeKO8AU2.net] >自己完結すれば最速で完結する アタオカの巣窟になりつつあるな 961 名前：デフォルトの名無しさん mailto:sage [2022/12/09(金) 18:30:00.75 ID:rq1aZYl+.net] 絶対にベンチマークの数値は出せないリンクリストおじさん いつまでrustに粘着してんの 962 名前：デフォルトの名無しさん mailto:sage [2022/12/09(金) 21:16:01.37 ID:o+3mnUPM.net] 馬鹿は想像力が無いから、理論から計算できない上に、仮定も間違っているから 間違った条件で実験して間違った実験結果を出して、それを信じてしまう。 Stroustrup氏もその一部。 963 名前：デフォルトの名無しさん mailto:sage [2022/12/09(金) 21:33:34.50 ID:o+3mnUPM.net] >>949 そんな馬鹿でも実際にプログラムしてる人は自分の間違いに気付くが、 彼と彼の取り巻き達はベンチマーク以外のプログラムはしないので 一生気付かない。そして自分達は実験したから正しいんだと主張し まくって、それを信じた人類は謝った認識を持って文明の発達が遅れる。 964 名前：デフォルトの名無しさん mailto:sage [2022/12/09(金) 22:18:43.15 ID:STy7gq1K.net] 真面目に言うならStroustrupの指摘したリンクリストは、愚直で安直な1要素で次を示すようなデータ構造はバカのすることで間違いない。 というかStroustrupはプログラマのために教え諭してるのに対して、自分が攻撃されたと思い込み、稀なケースで「LinkedListがArrayListより速いことがある」なんていい年してイキっててもしょうもないだろう？ 「非常に近いアドレス」とか自分で参照効率が悪いことを理解してるのに、何がしたいのかサッパリわからん。ぴろゆきみたいに見えない仮想的にロンパーしたいの？ https://www.youtube.com/watch?v=YQs6IC-vgmo ま、今ではUnrolled Linked listとか普通の配列やB-Treeなどと区別がつかない参照の局所性が大幅に向上しているものもあるから そんなことで騒ぐのはもはやジジイの域だなあ、10年前の出来事じゃん・・・・ 965 名前：デフォルトの名無しさん mailto:sage [2022/12/09(金) 22:39:25.91 ID:rOm/uTcN.net] ジジイと言うかその人は 1) 頭が悪くて 2) 経験もなくて 3) その自覚が無い というかわいそうな存在だからあんま刺激しちゃダメ こうなってくるとこの手のひとは あとは粘着するだけのマシンと化すから要注意だぞみんな 966 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 00:05:08.23 ID:s9w4cjy9.net] 自己完結は悪と思ってるから他者に粘着するんでしょ 967 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 01:32:53.73 ID:ExYz252Q.net] コンピュータサイエンスやプログラミング関連の学者は、アホばっかだからな。 968 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 01:33:28.16 ID:CrLmIOQg.net] Rustではポインタの代わりに要素のインデックスで管理するのが基本であり安全 リストもツリーもグラフもこれで実装可能 これはポインタがない言語では当たり前のように使われていた方式 これまでが間違ってた ポインタなどというものは数百万行とかあるプログラムで正しく使うのは無理 世界中のエンジニアがそのために苦労している ポインタとNULLは完全に失敗 969 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 01:36:13.33 ID:CrLmIOQg.net] ちなみにインデックス管理がゴミだったのはCみたいに配列の要素チェックがなく 生アドレスを直接触れる仕様だったせい 本来この仕様があり得ない これならポインタの方がマシだし楽だからという理由でポインタが乱用されてきた 970 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 01:42:29.86 ID:ExYz252Q.net] >>951 その動画のジジイはまさに馬鹿。 老害。 971 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 01:44:30.98 ID:ExYz252Q.net] アメリカのコンピュータ学者は馬鹿。 自ら馬鹿な方法ばかり想定しているから遅いと思い込んでいる。 それを鵜呑みにしてる学生は大ばか者。 972 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 01:46:18.37 ID:ExYz252Q.net] だからアメリカ人の作るソフトは遅い上にサイズも大きいんだな。 日本人の作るソフトはコードも小さいし、データも小さいし、速度も速い。 全然違う。 なぜなら、アメリカ人がイマジネーションが足りなくて馬鹿なのに自覚が無いから。 なのに、詐欺的手法によってアメリカ製ソフトを蔓延させた。 973 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 01:47:54.33 ID:48CeiLls.net] ポインタてのは、CPUの汎用レジスタの アドレッシングモードを考慮して OSをコーディングしやすくする仕組みだから 974 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 01:51:53.77 ID:ExYz252Q.net] >>957 おっと、こいつが、Stroustrup氏だったのか。 どうりでデタラメな事言ってると思った。まさに、彼が自書で言ってる通りの内容。 この人は計算量などを考えるイマジネーションが不足している。 975 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 02:00:02.88 ID:ExYz252Q.net] 仮に、彼の間違った仮定であるところの、リンクリストのノードのアドレスが ランダムに近い状態だったとして(それ自体がウソの仮定なのだが)も、 キャッシュペナルティーは、一回当り20クロックほどだ。 だから、この場合、次のノードに移るのに20クロック掛かることになる。 しかし、それでも、ノード数がNの場合に、20*N クロックほどで済むから そんなに致命的ではない。Nを100倍しても、100倍の時間がかかるだけで、 大した増加ではない。 一方、std::vectorの場合、挿入や削除一回当り、O(N)の時間が掛かるから、 N回それを繰り返すと、O(N^2)の時間が掛かる。 これは致命的で、Nを100倍すると、1万倍の時間になってしまう。 Stroustrup氏は、オーダーの考え方が経験的に身についてない。 976 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 02:06:32.68 ID:ExYz252Q.net] >>962 [補足] CPUの速度はこの30年間で、1コアあたりに限定しても300倍以上になっている。 良いアルゴリズムを使えば、扱うデータも300倍に増やすことが出来る。 ところが、std::vetcorを使った挿入や削除を行なっていた場合、300*300=9万倍 にクロック数が増� 977 名前：ｦるから、CPUの速度がせっかく300倍になっても、300倍の 時間が掛かることになる。 一方、std::listを使った挿入や削除を行なっていた場合には、クロック数が 300倍で済むから、CPUが300倍になったことにより、時間は昔のままで済む。 つまり、std::listの場合、CPUの速度が300倍になった現在、 データを300倍に増やしても、挿入や削除が昔と同じ時間で済むのに対し、 std::vectorは、同じことをするとなんと昔の300倍の時間が掛かるということだ。 こういう基本をstroustrup氏は理解出来て無い。 探索の時間は関係無い。探索しなければいいのだから。 [] [ここ壊れてます] 978 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 02:29:35.43 ID:ExYz252Q.net] >>951 >稀なケースで「LinkedListがArrayListより速いことがある」なんていい年してイキっててもしょうもないだろう？ 稀ではない。 今はCPUが速くなりすぎて実感がわかないだけ。 だから、遅いCPUでトレーニングした方が良いと言われている。 979 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 03:06:45.22 ID:EiHCMpy7.net] プロファイルでは粘着というより、論破された時の憂さ晴らし自演が延々と続くパターン ID:Lb4jZ7zf = ID:pMPEGjtK = ID:3DNXTGzR = ID:ExYz252Q +α 今回は ID:Mw8qZqut だな 980 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 08:26:05.03 ID:wI0qdr5j.net] CPUが早くなったんだからRustで多少遅くなっても大丈夫 981 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 08:49:37.65 ID:pTzP7Jq7.net] Goも大丈夫 982 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 08:52:02.51 ID:QB2FhiiS.net] >>965 ID:Mw8qZqut だけどこの人と同一人物判定されるのは不名誉すぎるからやめてくれ 983 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 08:54:11.81 ID:5JJKT/6S.net] >>968 そうかな？流れ的には水増し論に決着して放り投げてるよ 984 名前：962 mailto:sage [2022/12/10(土) 09:12:41.82 ID:pmPytGrf.net] 誤解は避けたいからいちおう書いとく > ジジイと言うかその人は これはもちろん連投してる哀れなID:ExYz252Qのことね C++やハゲに文句言うとか身の程知らずもいいとこやわ 985 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 09:19:33.69 ID:5JJKT/6S.net] >>970 その人C++スレの自称天才でRustに傾倒していてChatGPT並みに尤もらしい適当をこいている人 986 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 09:22:07.09 ID:5JJKT/6S.net] その人自演が大好きなので ID:Mw8qZqut だとしてもおかしくない 987 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 09:25:57.47 ID:5JJKT/6S.net] 流れ的には水増しの話が再開するはずなので、ID:Mw8qZqut = >>968がどう反応するか楽しみ 988 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 09:30:48.75 ID:pmPytGrf.net] >>971 C++スレも荒らされてるのか 自称天才の粘着力すげえな 989 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 11:09:35.00 ID:/zXB1Eur.net] C++ vs Rust Part4建てとく？ 990 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 12:35:14.53 ID:QB2FhiiS.net] >>973 Androidのソースコード量については、 * コンパイラはカウントされていない * 外部の依存関係はカウントされているぽい ということで、事実関係についてはだいたい確定したのでは 991 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 13:03:40.38 ID:f/x7hc9i.net] >>976 横からですが、その回答だと、適切かどうかに関して、はぐらかそうとしているだけでは？ 論理的に考えてC++でboostを使ってhello_asioとか書いたら、 そのレポジトリの行数にboostのソースもカウントするのが適切かどうかと照らし合わせて考えて見ては？ 992 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 13:23:37.96 ID:s9w4cjy9.net] 行数の正確さを保証しているのは行数をカウントするアルゴリズムの質だよ だから、質を保証するために量を根拠にするのはもう違和感しかない 993 名前：デフォルトの名無しさん [2022/12/10(土) 14:01:34.35 ID:aynhf3Gg.net] >>977 目的次第やろ 使ってるライブラリも含めてそのプログラムに含まれる脆弱性をカウントする際の分母として使いたいならboostのコードをカウントするのも一つの考え方 Googleが実際にどうカウントしたかは知らんけどRustとC++を異なる条件でカウントしてるんじゃなければここで何言っても無駄だよ 994 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 14:17:34.56 ID:CrLmIOQg.net] 糖質にかまうな 995 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 14:23:19.49 ID:++bfMBzJ.net] 盲目的に現状肯定する集団には見られたくないから言うけど 個人的には誤認する人が多発するから不適切だと思うよ >目的次第 何の目的があって依存関係のソースもカンウトするのか、AndroidのRustチームの考えを知りたい >>979 Androidがboost依存があって、boostソースがカウントされていない場合はどうなるの？ RustとC++を異なる条件でカウントしてる、に該当するよね >>979がいう事が正しければ、新規ネイティブコード21%の下りでも依存関係ソースの増減も含めるのが同条件なんだよね？ 996 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 14:29:10.10 ID:++bfMBzJ.net] >>980 その発言で ID:CrLmIOQg の内容全部が地に落ちたよ 997 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 15:17:06.99 ID:hJa6mCIB.net] >>981 仮に○○なら対等な条件の比較ではないという主張は真だと思うけど、 そもそもRustとC++が異なる条件で比較されてると考える根拠はなんかあるの？ 998 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 16:30:04.48 ID:/zXB1Eur.net] 行数をカウントする目的: 利用状況の度合いをバカにも分かる数字で説明するため 依存関係を含めるのが適切か？: 数字を出すのが目的なのでどちらでもよい 999 名前：デフォルトの名無しさん [2022/12/10(土) 17:08:17.02 ID:+r0o6+3M.net] >>981 >何の目的があって依存関係のソースもカンウトするのか、AndroidのRustチームの考えを知りたい Rustチームとかじゃなくセキュリティ監査をするチームが計測してるんだぞ 本当に計測方法の詳細や理由が知りたいなら記事書いた本人にTwitterとかで聞けばいいよ この辺のエンジニアは普通に答えてくれるぞ 1000 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 17:13:44.96 ID:bYLLjzjY.net] >>970 >C++やハゲに文句言うとか身の程知らずもいいとこやわ 分かってはいたが、この板はレベル低いな。 1001 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 17:50:19.42 ID:8gOJz6B3.net] 次スレは平和になりますように 1002 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 17:51:40.13 ID:s9w4cjy9.net] 死者の数をカウントしてみろ、平和だぞ 1003 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 21:25:51.87 ID:AuQEELto.net] Androidドメインに限定したコードの量を測るよりも、Androidに搭載されうるコードの量を測る方が適切だと思うから外部ライブラリ含んでいいんじゃね。 1004 名前：デフォルトの名無しさん mailto:sage [2022/12/10(土) 22:05:26.23 ID:s9w4cjy9.net] C,C++,Rustの三者は対等として、 C/C++とかいう概念はRustと対等か？ 1005 名前：1001 [Over 1000 Thread.net] このスレッドは１０００を超えました。 新しいスレッドを立ててください。 life time: 64日 23時間 22分 13秒 1006 名前：過去ログ ★ [[過去ログ]] ■ このスレッドは過去ログ倉庫に格納されています

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

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