結局C++とRustってどっちが良いの？ 3traits

**デフォルトの名無しさん** · 2023/05/04(木) 07:49:56.33

「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」

っていう雑談スレ。

前スレ: 結局C++とRustってどっちが良いの？ 2traits
https://mevius.5ch.net/test/read.cgi/tech/1680363777/

関連スレ(マ板): Google&MS「バグの70%はC/C++。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

**デフォルトの名無しさん** · 2023/05/04(木) 14:12:15.32

板のルールが理解できない、プログラムがロクに書けない人たちのスレ
>>1死んどけ荒らしのクズ

**デフォルトの名無しさん** · 2023/05/04(木) 14:13:35.45

あらゆるところに関所がある
まるで江戸時代だ
裏山に抜け道を見付けて分け入っても
突然藪から棒に番人が現れる
ところがそんな番人も
unsafe印籠を魅せれば一撃で退散だ
unsafe万歳!!!
こんなことなら最初から
表通りでunsafe印籠を出しておけば良かったんだ
きっと番人たちも思っているはず
さっさと最初からunsafe印籠魅せやがれ
無駄な手間取らせやがって
こんなのがエコシステムとか失笑もの

**デフォルトの名無しさん** · 2023/05/04(木) 14:18:13.51

ここの説明だと
https://keens.github.io/blog/2018/12/08/rustnomoju_runotsukaikata_2018_editionhan/
lib.rs も main.rs も共存出来る様な描きっぷりだなぁ
今の Rust だと許さないゎょ

まあ2018だし

**デフォルトの名無しさん** · 2023/05/04(木) 14:39:58.15

=== 複製おじさん（通称複おじ）について ===
Rustスレを中心に活動し、2023年4月現在で1年以上ム板に住み着くRustacean。無自覚な荒らし。

Rustスレでは、基本的に他住民の意見を聞いて糧とすることなく、自らのコードが最善であると、ID変更自演を交えいつまでも主張し続ける。
同スレで「所有権が複製される」という違和感のある表現を、「違和感がある」とする他住民の意見をすべて否定してしつこく擁護し続けたことから、「複製おじさん」というあだ名が付けられた。
それ以外のム板スレでは、基本的に他住民の意見を聞いて糧とすることなく、Rustこそが最善であると、ID変更自演を交えいつまでも主張し続ける。
その基本戦術は、「GC言語は遅い」の一声でC/C++/Rust以外の言語を否定し、残ったC/C++は安全ではないので、Rustが最善であるとするもの。

しかしながら、Rust以外の言語に関しては、正当な批判を展開するのに十分な知識を持っているとは言いがたい。
本スレPart1では、C++の問題点を指摘しようとして多数の誤り・知識不足を露呈することとなった。特にしつこく食い下がったのが「動的ディスパッチ」に関する誤解である。
https://mevius.5ch.net/test/read.cgi/tech/1677286186/786-799（ID:Evbafc70とID:RiLc+pIfが複製おじさんであると考えられている）
要約すると、通常「条件分岐」と呼ばれるものを「動的ディスパッチ」と呼ぶのが正しいと主張し続けたのである。
常識的にはあり得ない誤解だが、提示されたC++のコードが自らの主張（C++にはパターンマッチが無い）に不都合であると感じたためか、C++のコードを正しく読み解くことができないにもかかわらず脊髄反射的に否定してしまい、その根拠として誤った論理をこじつけてしまったものと思われる。

ちなみにこの後、同種の誤解を持って書き込むID:wHEiYRW7（これはID使用歴的に複製おじさんとは考えにくい）に対して、正しい理解に基づく指摘を行う単発IDが複数出現するが、この中にも複製おじさんが多数含まれていると考えられている。
このように自分の誤りを認識した場合、それを認める書き込みは決して行わず、別人の振りをして最初から正しく理解していた体を装うのも複製おじさんの特徴である。

**デフォルトの名無しさん** · 2023/05/04(木) 14:42:23.03

Fooという型だけを別ファイルfoo.rsへ移してファイルを分けたくなったとする
もちろんそれは可能だが二つの方針に分かれる

その1
pub mod foo;
とする
つまり単にmod foo;とするのではなくpubを付けることで利用者がfooにアクセスできるようになる
さらにfoo.rsでFooにもpubが付いていれば
利用者はfoo::Fooまたはクレート名::foo::Fooという形で利用できる

その2
mod foo;
pub use foo::Foo;
とする
つまりfooは公開しない
しかしFooは公開したいのでfooの下ではなくトップでFooを公開する
この場もfoo.rsでFooにpubは必要
利用者はfoo::を付けずにFooまたはクレート名::Fooという形で利用できる

ようするにファイルを分けたときに
分けた形で公開するならその1
分けたことを隠蔽して公開するならその2

**デフォルトの名無しさん** · 2023/05/04(木) 14:50:46.28

>>5
>自分の誤りを認識した場合、それを認める書き込みは決して行わず、別人の振りをして最初から正しく理解していた体を装う

図らずも昨晩今日のC言語スレでその現象が観測されました

**デフォルトの名無しさん** · 2023/05/04(木) 14:53:45.65

さらに型Fooのイテレータだけ別ファイルiter.rsに分けたくなったとする
その時はfoo/iter.rsというファイルにする
そしてfoo.rsの中でmod iter;とすればよい
分けたことを隠蔽するか公開するか>>6と同じ方針で望む
もし公開するならfoo::iter::Iterのようにパスが長くなる
それをメリットかデメリットかで決めればよい

**デフォルトの名無しさん** · 2023/05/04(木) 15:08:27.50

>>4
今も同じように共存できるよ

**デフォルトの名無しさん** · 2023/05/04(木) 15:23:13.86

次に>>6とは全く逆
ファイルを分けたくないけど
foo::Fooという形で公開したい時
その場合は
pub mod foo {
　ここにFooの定義など
}
とすればよい
ファイルfoo.rsに分けたときと同じにできる

つまり
ファイルを分けるか分けないか
公開パスを分けるか分けないか
任意の組み合わせで自由に可能

**デフォルトの名無しさん** · 2023/05/04(木) 15:23:20.04

>>5
動的ディスパッチは俺だよw
間違うな

**デフォルトの名無しさん** · 2023/05/04(木) 15:35:48.42

かの御仁、ディスパッチのことになるとずいぶん熱くなってたよなあ
継承を廃止するのに必要だったからってわけだったみたいね

**デフォルトの名無しさん** · 2023/05/04(木) 15:59:17.58

さらに5つ目の方法
ファイルは分けなくて
mod foo{...}という形でfooは分けるけど
そのfooは見せない！
と一見すると矛盾した方針がある

その場合は>>6と>>10からのご推測の通り
mod foo {
　ここにFooの定義など
}
pub use foo::Foo;
とすればよい
利用者は直接Fooまたはクレート名::Fooとして使える

しかしそれならば
mod foo{...}を使わずにそのまま直接Fooの定義を書いたのと同じじゃないか！
との疑問が湧く

ほぼその通りだが
この方法によりmod foo{...}の中は名前空間が分離されているため
他とのコードの分離もしっかりできる
もし外部との結合があれば
mod foo{...}の中で改めてその使用宣言が必要になる
逆に外部から使われるものはpub宣言が必要となる
mod foo{...}の中に敢えて入れることでそれら他との関係が明示させられる

つまりまとめると3つの自由度がある
・mod fooとして分けるかどうか
・それをfoo.rsとしてファイルに分けるかどうか
・そのfooを外部に見せるか隠蔽するか
それらを多段foo::bar::bazそれぞれ含めて自由に決めればよい

**デフォルトの名無しさん** · 2023/05/04(木) 16:03:32.18

Rustの用語に「名前空間」なんてあるの？

**デフォルトの名無しさん** · 2023/05/04(木) 16:04:11.41

あるよ

**デフォルトの名無しさん** · 2023/05/04(木) 16:09:29.50

>>12
Rustは継承を使わずに合成だが
動的ディスパッチ自体はほぼ変わらない
vtable部分が合成した各メソッドを含む一覧になる程度

**デフォルトの名無しさん** · 2023/05/04(木) 16:21:16.61

この話興味ない人は今のうちにCpp2見とくと良いよ(思ってたより動きが早い)
https://herbsutter.com/2023/04/30/cppfront-spring-update/

Carbonと違ってこっちは動かせるしC++へのバックポートを視野に入れているから
結果的にRustの立ち位置に影響する

細かいところだと、この辺、Zigに通じるものがある
https://github.com/hsutter/cppfront/wiki/Design-note:-Postfix-operators
https://i.imgur.com/bkjsYG4.png

unsafe印籠(monolithic hammer)は否定してる
https://github.com/hsutter/cppfront/wiki/Design-note:-Unsafe-code

**デフォルトの名無しさん** · 2023/05/04(木) 16:21:47.50

ほとんどのmoduleは
自分の今のprojectから分離して別のcrateに移動しても
module内のpub関数はuse cratename;すればそのまま変更無しで参照出来るが
module内のmacroはuse cratename;するだけでは参照出来ない
#[macro_export] だけでは不十分でmoduleに
pub use macroname;
を書き足す必要がある

**デフォルトの名無しさん** · 2023/05/04(木) 16:22:57.02

>>9
ごめん
proc_macro が共存出来なかったって事だった
ていうか proc_macro が共存出来ないのは昔からだな

**デフォルトの名無しさん** · 2023/05/04(木) 17:29:00.42

ITの世界は短期決戦の世界。知名度がこんなに上がってるのに使用者数が1%未満
のRustには一般言語にまで普及する可能性はほぼ無い。

**デフォルトの名無しさん** · 2023/05/04(木) 17:31:09.86

今までの蓄積ではなく、新しく書かれているコードの量ですら1%未満であることの
意味は、絶対に普及しない路線に入っていると言うことだ。

**デフォルトの名無しさん** · 2023/05/04(木) 17:38:32.86

商品が売れない原因の9割は知名度不足だと言われているが、Rustは既に最高レベル
の知名度になった。なのに「売れてない」。それは商品自体に問題があると考え
なければならない。俺はRustが嫌いなので、それでいいと思っているが。

**デフォルトの名無しさん** · 2023/05/04(木) 17:48:43.01

結論としてはRustはC++に比べるとファイル分轄が非常にめんどくさいと言うことだな
ルールが複雑でめんどくさい

言語仕様なのかcargoの仕様なのかしらないけどフォルダ構造が縛られるし…

**デフォルトの名無しさん** · 2023/05/04(木) 17:52:33.78

よくわからんけど自分でstruct沢山作ってcore/modelフォルダ作ってそこに全部突っ込んでフラットに使おうとすると障害があると
implをcore/implに突っ込もうとしても問題があると
それかそれを参照する何かを別に作らないといけないと
自由度が低い

**デフォルトの名無しさん** · 2023/05/04(木) 17:56:09.35

いやーさすがにC++に比べたらRustのが超シンプルなのでわかりやすい
C++のモジュール知っててRustのモジュールを理解出来ない人はいないと思う

**デフォルトの名無しさん** · 2023/05/04(木) 17:58:28.21

>>24
障害？

**デフォルトの名無しさん** · 2023/05/04(木) 18:03:56.15

/struct、/impl、/traitみたいな分け方をしたかったのかぁ
できなくはないけどやめといたほうがいいんじゃないか

**デフォルトの名無しさん** · 2023/05/04(木) 18:06:55.48

したいんじゃなくてそれは仮に書いただけ
自由度が低いと言うことを示したかっただけ

ファイル名やフォルダ名が縛られたり

なんで自由度が低いのに顔を真っ赤にして自由度が高いと書くのか不明なんだけど

**デフォルトの名無しさん** · 2023/05/04(木) 18:12:40.50

>>25
C++は至ってシンプルやろ?

**ななし** · 2023/05/04(木) 18:16:37.43

Javaしかやったことない
C++っていいの？

**デフォルトの名無しさん** · 2023/05/04(木) 18:16:44.50

既存のC++のプロジェクトに書き足していくかたちでCargoとかが使われてるんだろ？
C/C++の作法に併せたRustのフォルダ構成の裏ルールがあるとしか思えない

**デフォルトの名無しさん** · 2023/05/04(木) 18:21:23.60

モジュール名とファイル名（パス）は↓みたいな書き方で一応切り離せるよ
ややこしくなるから基本使わないけど

#[path="platform/foo_windows.rs"]
mod foo;

自由度が高いってのはたぶん外面を維持したまま内装を変更しやすいって意味で使ってたと思う
（長文だったからちゃんと読んでない）

モジュールの構成は可視性に関わるからそこまで自由ではないと思う
全部にpubつければ自由になるけどそんな自由はいらない

**デフォルトの名無しさん** · 2023/05/04(木) 18:34:14.75

自分が使ってる中ではC#が一番自由度が高い気がする
classの分割自由
名前空間の分割自由
プロジェクト内ではフォルダ空間自由
ファイル名自由

**デフォルトの名無しさん** · 2023/05/04(木) 18:38:46.37

global usingと言うものが出来て各ファイルでusingもしなくて良くなった
これはいらない機能だと思うけど

**デフォルトの名無しさん** · 2023/05/04(木) 18:42:44.88

C#はまじめに使ったことないけど拡張メソッドとかいうのが自由すぎて若干引いた記憶がある
どこで何を足されるか分からない恐怖を感じた

**デフォルトの名無しさん** · 2023/05/04(木) 18:48:25.91

プロジェクト内のファイル位置も当然自由
一ファイルに複数の名前空間含めるのも自由

**デフォルトの名無しさん** · 2023/05/04(木) 19:14:36.30

Rustがなぜファイル名やフォルダ名でモジュール固定になってるかと言えば
それしかモジュール位置を決定する仕組みがないから
ルートのコードからたどれる物しか名前を解決できないから
それが良くないんじゃないの？

>>35
既存のクラスすべてで必ず拡張されるわけじゃない
本当は拡張などしてなくてただのstaticメソッドだし
どこかそれを他で使われていてもそれをusingしなければ使えないから関係ない
usingしててもpublicじゃなければ見えないので影響はない

**デフォルトの名無しさん** · 2023/05/04(木) 19:37:12.64

proc_macro で黒魔術やりたい放題出来る様になりますた
おまいらのお蔭です本当にありがとうございますた

っていうか proc_macro::TokenStream と proc_macro2::TokenStream と
同時に使うと違うと判ってても混乱するな

**デフォルトの名無しさん** · 2023/05/04(木) 19:41:38.84

>>35
>どこで何を足されるか分からない恐怖を感じた

これは Rust の trait や後付けの impl にも同じ臭いを感じる

**デフォルトの名無しさん** · 2023/05/04(木) 20:43:05.13

一応Rustのimplは型（trait）を定義したクレート内に制限かけてるけどそれでも気になる人はいるか
自由な場所で定義を足せるとどうしても散らかりやすくなる

**デフォルトの名無しさん** · 2023/05/04(木) 21:36:06.92

>>38
---- lib.rs 側 ----
use proc_macro::TokenStream;
use proc_macro2::TokenStream as PM2TS;
(略)
#[proc_macro]
pub fn mk_ts(_item: TokenStream) -> TokenStream {
let mut ts: PM2TS = PM2TS::new();
Ident::new("let", Span::call_site()).to_tokens(&mut ts);
Ident::new("x", Span::call_site()).to_tokens(&mut ts);
Punct::new('=', Spacing::Alone).to_tokens(&mut ts);
Literal::u8_suffixed(255u8).to_tokens(&mut ts);
Punct::new(';', Spacing::Alone).to_tokens(&mut ts);
ts.into()
}

---- main.rs 側 ----
fn main() {
mk_ts();
println!("{}", x);
}

これで実行は出来たけど TokenStream がぶつかってるのが気に入らない

**デフォルトの名無しさん** · 2023/05/04(木) 21:37:41.16

main.rs の方は
mk_ts!(); だった

**デフォルトの名無しさん** · 2023/05/05(金) 01:53:22.17

>>30
基本的に、JavaとC++は兄弟言語で、共通点がとても多い。
classの概念もほとんど同じだし、とても良く似ている。
一方、RustとC++は全く違う言語。

**デフォルトの名無しさん** · 2023/05/05(金) 01:56:43.74

全く違うんだが現状は C からの置換を目指さなきゃいけない
その辺りがフォルダ構成にも反映されてしまっている

当然だがマッチの箇所はプロログなどの方が近い

**デフォルトの名無しさん** · 2023/05/05(金) 02:10:01.68

現にデコンストラクトによるパターンマッチはlispかhaskelくらいでしか見かけない

**デフォルトの名無しさん** · 2023/05/05(金) 02:29:13.44

似てたら置き換えやすいけど、置き換える意味も薄まりそうだけどな

**デフォルトの名無しさん** · 2023/05/05(金) 04:24:21.70

「みんなが使ってないものが使いたい」という心理を持っている人が一定数いて、
Rustはそういう人に受けてる可能性もある。

**デフォルトの名無しさん** · 2023/05/05(金) 05:02:21.75

Microsoft「Windows 11がまもなくカーネル内でRustを用いて起動」
https://www.neowin.net/news/senior-microsoft-exec-says-windows-11-kernel-will-soon-be-booting-with-rust-inside/

BlueHat IL 2023 カンファレンスにおいて、マイクロソフトのエンタープライズおよび OS セキュリティ担当バイスプレジデントである David Weston が登壇し、
Windows セキュリティの進化について話し合い、最新の進歩と今後の道のりについての洞察を講演しました。

プレゼンテーションの中でWeston氏は、MicrosoftがWindowsカーネルの一部としてRustを使用して行ってきた進歩について説明しました。
いくつかの理由でこの言語に興味を持っており、そのうちの11つはRustが提供するメモリの安全性とセキュリティを中心にしています。

Weston氏は次のように述べています。
「おそらく今後数週間または数か月以内に、カーネルでRustを使用してWindowsが実際に起動することになりますが、これは本当にクールです。
ここでの基本的な目標は、これらの内部C ++データ型のいくつかをRustの同等のデータ型に変換することでした。」

**デフォルトの名無しさん** · 2023/05/05(金) 05:36:12.75

前スレにも書いたけど、ブートローダってDOSアプリみたいなもんで、劇的に画期的じゃないんだよ

APIが早くRust化してほしいそうすれば、C++も恩恵を受ける

**デフォルトの名無しさん** · 2023/05/05(金) 06:12:56.25

マイクロソフトがわざわざC++を捨ててまでRustを採用するとはよっぽどのことだよな
Linuxの方は元からC++さえ排除してC言語だけの純血主義だったのにRustを採用し始めてる

**デフォルトの名無しさん** · 2023/05/05(金) 06:30:56.10

>>49
記事を読んだがブートローダーなんて書かれてなかった
Rustを使った場合のWindows OSのパフォーマンス比較でOffice apps使用の場合が出てくるからブートローダーの話ではないね

**デフォルトの名無しさん** · 2023/05/05(金) 06:37:43.26

昔、マイクロソフトはわざわざJAVAを捨ててJ++を開発したんだよなあ

**デフォルトの名無しさん** · 2023/05/05(金) 06:58:16.61

これまで多数の言語が登場したけど求められてる条件はたった二つだけ
「C/C++と同等のパフォーマンスが出ること」
「C/C++の各種安全性の問題が解決されていること」
Rustが最初で唯一の言語

**デフォルトの名無しさん** · 2023/05/05(金) 08:25:55.79

>>53
どこの異世界にすんでるんだ？

**デフォルトの名無しさん** · 2023/05/05(金) 08:50:30.82

>>53
安全にするにはGC言語にするしかないと思われていたからね
Rustだけが勝者となった

**デフォルトの名無しさん** · 2023/05/05(金) 09:46:15.52

Rust以外でGC採用せずにメモリやリソースの後始末をちゃんとしてくれるよう設計された言語って何があるの？

**デフォルトの名無しさん** · 2023/05/05(金) 10:06:18.39

お! GC君だ（この人が複製おじさん?）
GC君は他人のことを初心者呼ばわりするけど
技術的な話が全くできないんだよなぁ...

**デフォルトの名無しさん** · 2023/05/05(金) 10:21:16.98

>>50
$ tar xJf linux-6.3.1.tar.xz
$ find linux-6.3.1 -name *.c -o -name *.h | wc -l
55806
$ find linux-6.3.1 -name *.rs | wc -l
38
0.07%未満! 前回v6.2.1のとき37だったから1ファイルは増えてるね
何が増えたかは
$ diff -uNr <(cd linux-6.2.1; find . -name *.rs) <(cd linux-6.3.1; find . -name *.rs)

**デフォルトの名無しさん** · 2023/05/05(金) 10:43:09.36

>>52
JavaScriptをわざわざパクッてJscriptってのも作ったな
今やIEブラウザごと滅んだが
アップルとかソニーとか独自規格を作りたがる連中はいつの時代も迷惑

**デフォルトの名無しさん** · 2023/05/05(金) 10:47:34.91

Rustはメモリリークには割と寛容なんだよね
野生の参照（ダングリングポインタ）は目の敵にするけど

**デフォルトの名無しさん** · 2023/05/05(金) 10:52:02.55

>>56
Rustしか現存しない
他に出てきそうにないため今後Rustの時代が続くのだろう

**デフォルトの名無しさん** · 2023/05/05(金) 11:08:39.58

>>45
>デコンストラクトによるパターンマッチ
聞かない用語ですねぇ～
デコンストラクト

**デフォルトの名無しさん** · 2023/05/05(金) 11:27:48.85

>>56
Nim

**デフォルトの名無しさん** · 2023/05/05(金) 11:29:46.84

>>60
ヒモさえ付いてれば無駄遣いしてもOKみたいな

**デフォルトの名無しさん** · 2023/05/05(金) 11:58:16.34

RustってNimに対して何か優位なところはあるの?

**デフォルトの名無しさん** · 2023/05/05(金) 12:01:00.00

>>63
NimはGC言語
GCに頼らず済ませられる部分のみ使わないで済むというだけ

**デフォルトの名無しさん** · 2023/05/05(金) 12:15:37.38

>>56

間違い：メモリやリソースの後始末をちゃんとしてくれる
正解：メモリやリソースの後始末をちゃんとしてくれる(リーク除く)

**デフォルトの名無しさん** · 2023/05/05(金) 12:17:42.38

Nimはnilが存在していてヌル安全ですらない

**デフォルトの名無しさん** · 2023/05/05(金) 12:18:25.68

基本GCでも充分な性能が出れば別にいいよ
最適化が必要なところだけ手動でやるのはRustも同じだから

手動ライフタイム管理とのトレードオフ

**デフォルトの名無しさん** · 2023/05/05(金) 12:22:56.73

>>69
RustはNimのような逃げをしていない点で全く異なるよね
NimはGC言語という点でも誰も異論はなく

**デフォルトの名無しさん** · 2023/05/05(金) 12:28:44.39

>>56
Factorかね。

**デフォルトの名無しさん** · 2023/05/05(金) 12:37:44.37

FactorはForthとLispの子みたいな動的型付け言語
ガベージコレクションあり

**デフォルトの名無しさん** · 2023/05/05(金) 16:12:43.08

GCの有無は指標になるけど、現状のC++の、なんでもかんでもヒープに置く習慣は、
GCとそんなかわらないんじゃ…と思わなくもなかったり

**デフォルトの名無しさん** · 2023/05/05(金) 16:21:47.02

C++はコンパクションが行えないので、GC付きのJavaのほうが速いのです

って言ってなかった？

**デフォルトの名無しさん** · 2023/05/05(金) 17:13:23.83

感覚的にはプリミティブでない単純なデータ（xyz座標とか）の配列を直接作れるかどうかがボーダーな気がする
ポインタの配列を作ってるようだとGCしなくてもGC言語
C#は微妙なライン

変なタイミングで大掃除始める問題もあるけどこっちを気にする機会は少ないような

**デフォルトの名無しさん** · 2023/05/05(金) 18:05:31.65

結局、RustはC++より速くても、Javaよりは遅いってことですね

**デフォルトの名無しさん** · 2023/05/05(金) 19:01:02.92

もう少し待てはマイクロソフトがR++を出すと思うから
それまで待って

**デフォルトの名無しさん** · 2023/05/05(金) 23:04:16.37

JAVAが速い！？

**デフォルトの名無しさん** · 2023/05/05(金) 23:05:51.16

>>76
Rustはスタックを多用する言語なのでJavaより速い

**デフォルトの名無しさん** · 2023/05/05(金) 23:35:38.70

>>79
証拠は？

**デフォルトの名無しさん** · 2023/05/05(金) 23:47:38.29

>>80
スタック上のメモリ領域はCPUレジスタであるスタックポインタを足し算引き算するだけでメモリ確保と解放できるため最も速い

**デフォルトの名無しさん** · 2023/05/05(金) 23:50:40.76

>>81
CPUの仕組みを知っててそういう認識の人はいないと思いますよ

**デフォルトの名無しさん** · 2023/05/05(金) 23:56:37.63

もうみた～

**デフォルトの名無しさん** · 2023/05/06(土) 00:11:48.42

>>81のスタックメモリ利用が一番速いで合ってるけど
スタックメモリは関数から戻ると自動的に開放されその部分は無効になっちゃう
そのため従来の言語ではスタックメモリの利用を抑え気味にすることでその問題を過剰に回避してた
Rustはライフタイムの導入でスタックメモリを安全な範囲内の限界まで使えるようになったことが違いかな

**デフォルトの名無しさん** · 2023/05/06(土) 00:20:07.63

CPUのレジスタ利用が一番速いがレジスタ割り付けの最適化が非常に難しいので
スタックを使ってお茶を濁してる

**デフォルトの名無しさん** · 2023/05/06(土) 00:36:19.82

スタックメモリが主記憶と別の場所にあると思ってない？

**デフォルトの名無しさん** · 2023/05/06(土) 00:39:27.80

もしかしてヒープは主記憶、スタックはプロセッサの中にあるとか思ってない？
いま検索中？

**デフォルトの名無しさん** · 2023/05/06(土) 00:43:00.80

メモリの確保の仕方の違いでの速さの比較の話でレジスタの話を持ち出すのは違うでしょ
そしてレジスタの数は限界がありその退避先もスタックメモリですよ
スタックメモリに割り当てられた変数は最適化によりレジスタ割り当てが可能であればレジスタのみ利用になりますね

>>86
スタックメモリは単なるメインメインの一部にすぎません
しかしメモリ確保と解放が最も速いだけでなくメモリキャッシュに載る点でアクセスも速いです

**デフォルトの名無しさん** · 2023/05/06(土) 00:43:06.74

キャッシュメモリは主記憶に含めておいた方がいい？

**デフォルトの名無しさん** · 2023/05/06(土) 00:43:19.23

頭のおかしい人間がずっと一般的な事実に基づかない頓珍漢な独自妄想理論を展開してる

**デフォルトの名無しさん** · 2023/05/06(土) 00:46:32.42

スタックを積極的に利用しているからrustがjavaより速いと言われて
納得する馬鹿はいないだろ

もっと根本的な理由があるだろと
javaはVMでスタックマシンをエミュレートしてるから遅い

**デフォルトの名無しさん** · 2023/05/06(土) 00:48:39.47

通常はレジスタ一発で出来ることもわざわざスタックマシンでエミュレートしてるので遅い

**デフォルトの名無しさん** · 2023/05/06(土) 00:49:43.41

Rustもたいがい遅いだろ

**デフォルトの名無しさん** · 2023/05/06(土) 00:50:53.23

頭のおかしい人間がもう一人増えてた…

**デフォルトの名無しさん** · 2023/05/06(土) 00:53:21.90

スタックメモリが確保の点でもキャッシュされてる点でも非常に速いのは常識
そのためGC言語であってもGoのようにまずはスタックメモリ利用を優先する
(他へ渡すときだけGC対象になるヒープを利用)

**デフォルトの名無しさん** · 2023/05/06(土) 00:58:44.72

でもJavaのほうが速いんでしょ？

**デフォルトの名無しさん** · 2023/05/06(土) 01:02:01.90

>>95
Rustはそこからさらに一歩進めて他へ渡すときもスタックメモリを使えるように改善してますね
Rustはライフタイムの導入でスタックメモリを安全な範囲内の限界まで使えるようになりました

**デフォルトの名無しさん** · 2023/05/06(土) 01:13:46.56

変な人大集合だね
それがrustよりjavaが速い理由だと思い込んで疑わない変な人たち

**デフォルトの名無しさん** · 2023/05/06(土) 01:14:41.38

おっと逆だ
それがjavaよりrustが速い理由だと思い込んで疑わない変な人たち

**デフォルトの名無しさん** · 2023/05/06(土) 01:27:18.47

RustはJavaより遅いだろ

**デフォルトの名無しさん** · 2023/05/06(土) 02:12:11.55

そなの?