23/05/04 07:49:56.33 z+qB+AKQ.net
「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」
っていう雑談スレ。
前スレ: 結局C++とRustってどっちが良いの？ 2traits
ｽﾚﾘﾝｸ(tech板)
関連スレ(マ板): Google&MS「バグの70%はC/C++。Rustにする」
ｽﾚﾘﾝｸ(prog板)
2:デフォルトの名無しさん
23/05/04 14:12:15.32 AmdlArlq.net
板のルールが理解できない、プログラムがロクに書けない人たちのスレ
>>1死んどけ荒らしのクズ
3:デフォルトの名無しさん
23/05/04 14:13:35.45 K35qCUKZ.net
あらゆるところに関所がある
まるで江戸時代だ
裏山に抜け道を見付けて分け入っても
突然藪から棒に番人が現れる
ところがそんな番人も
unsafe印籠を魅せれば一撃で退散だ
unsafe万歳!!!
こんなことなら最初から
表通りでunsafe印籠を出しておけば良かったんだ
きっと番人たちも思っているはず
さっさと最初からunsafe印籠魅せやがれ
無駄な手間取らせやがって
こんなのがエコシステムとか失笑もの
4:デフォルトの名無しさん
23/05/04 14:18:13.51 K35qCUKZ.net
ここの説明だと
URLﾘﾝｸ(keens.github.io)
lib.rs も main.rs も共存出来る様な描きっぷりだなぁ
今の Rust だと許さないゎょ
まあ2018だし
5:デフォルトの名無しさん
23/05/04 14:39:58.15 Pbw0n2Gt.net
=== 複製おじさん（通称複おじ）について ===
Rustスレを中心に活動し、2023年4月現在で1年以上ム板に住み着くRustacean。無自覚な荒らし。
Rustスレでは、基本的に他住民の意見を聞いて糧とすることなく、自らのコードが最善であると、ID変更自演を交えいつまでも主張し続ける。
同スレで「所有権が複製される」という違和感のある表現を、「違和感がある」とする他住民の意見をすべて否定してしつこく擁護し続けたことから、「複製おじさん」というあだ名が付けられた。
それ以外のム板スレでは、基本的に他住民の意見を聞いて糧とすることなく、Rustこそが最善であると、ID変更自演を交えいつまでも主張し続ける。
その基本戦術は、「GC言語は遅い」の一声でC/C++/Rust以外の言語を否定し、残ったC/C++は安全ではないので、Rustが最善であるとするもの。
しかしながら、Rust以外の言語に関しては、正当な批判を展開するのに十分な知識を持っているとは言いがたい。
本スレPart1では、C++の問題点を指摘しようとして多数の誤り・知識不足を露呈することとなった。特にしつこく食い下がったのが「動的ディスパッチ」に関する誤解である。
ｽﾚﾘﾝｸ(tech板:786番)-799（ID:Evbafc70とID:RiLc+pIfが複製おじさんであると考えられている）
要約すると、通常「条件分岐」と呼ばれるものを「動的ディスパッチ」と呼ぶのが正しいと主張し続けたのである。
常識的にはあり得ない誤解だが、提示されたC++のコードが自らの主張（C++にはパターンマッチが無い）に不都合であると感じたためか、C++のコードを正しく読み解くことができないにもかかわらず脊髄反射的に否定してしまい、その根拠として誤った論理をこじつけてしまったものと思われる。
ちなみにこの後、同種の誤解を持って書き込むID:wHEiYRW7（これはID使用歴的に複製おじさんとは考えにくい）に対して、正しい理解に基づく指摘を行う単発IDが複数出現するが、この中にも複製おじさんが多数含まれていると考えられている。
このように自分の誤りを認識した場合、それを認める書き込みは決して行わず、別人の振りをして最初から正しく理解していた体を装うのも複製おじさんの特徴である。
6:デフォルトの名無しさん
23/05/04 14:42:23.03 lCXaYfHw.net
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
7:デフォルトの名無しさん
23/05/04 14:50:46.28 MjER2/nN.net
>>5
>自分の誤りを認識した場合、それを認める書き込みは決して行わず、別人の振りをして最初から正しく理解していた体を装う
図らずも昨晩今日のC言語スレでその現象が観測されました
8:デフォルトの名無しさん
23/05/04 14:53:45.65 lCXaYfHw.net
さらに型Fooのイテレータだけ別ファイルiter.rsに分けたくなったとする
その時はfoo/iter.rsというファイルにする
そしてfoo.rsの中でmod iter;とすればよい
分けたことを隠蔽するか公開するか>>6と同じ方針で望む
もし公開するならfoo::iter::Iterのようにパスが長くなる
それをメリットかデメリットかで決めればよい
9:デフォルトの名無しさん
23/05/04 15:08:27.50 BxJFarE7.net
>>4
今も同じように共存できるよ
10:デフォルトの名無しさん
23/05/04 15:23:13.86 lCXaYfHw.net
次に>>6とは全く逆
ファイルを分けたくないけど
foo::Fooという形で公開したい時
その場合は
pub mod foo {
ここにFooの定義など
}
とすればよい
ファイルfoo.rsに分けたときと同じにできる
つまり
ファイルを分けるか分けないか
公開パスを分けるか分けないか
任意の組み合わせで自由に可能
11:デフォルトの名無しさん
23/05/04 15:23:20.04 vi1eEsAo.net
>>5
動的ディスパッチは俺だよw
間違うな
12:デフォルトの名無しさん
23/05/04 15:35:48.42 c9bfGq1+.net
かの御仁、ディスパッチのことになるとずいぶん熱くなってたよなあ
継承を廃止するのに必要だったからってわけだったみたいね
13:デフォルトの名無しさん
23/05/04 15:59:17.58 lCXaYfHw.net
さらに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それぞれ含めて自由に決めればよい
14:デフォルトの名無しさん
23/05/04 16:03:32.18 VOb3FI4m.net
Rustの用語に「名前空間」なんてあるの？
15:デフォルトの名無しさん
23/05/04 16:04:11.41 8veAOVw8.net
あるよ
16:デフォルトの名無しさん
23/05/04 16:09:29.50 lCXaYfHw.net
>>12
Rustは継承を使わずに合成だが
動的ディスパッチ自体はほぼ変わらない
vtable部分が合成した各メソッドを含む一覧になる程度
17:デフォルトの名無しさん
23/05/04 16:21:16.61 gs6nMm59.net
この話興味ない人は今のうちにCpp2見とくと良いよ(思ってたより動きが早い)
URLﾘﾝｸ(herbsutter.com)
Carbonと違ってこっちは動かせるしC++へのバックポートを視野に入れているから
結果的にRustの立ち位置に影響する
細かいところだと、この辺、Zigに通じるものがある
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(i.imgur.com)
unsafe印籠(monolithic hammer)は否定してる
URLﾘﾝｸ(github.com)
18:デフォルトの名無しさん
23/05/04 16:21:47.50 K35qCUKZ.net
ほとんどのmoduleは
自分の今のprojectから分離して別のcrateに移動しても
module内のpub関数はuse cratename;すればそのまま変更無しで参照出来るが
module内のmacroはuse cratename;するだけでは参照出来ない
#[macro_export] だけでは不十分でmoduleに
pub use macroname;
を書き足す必要がある
19:デフォルトの名無しさん
23/05/04 16:22:57.02 K35qCUKZ.net
>>9
ごめん
proc_macro が共存出来なかったって事だった
ていうか proc_macro が共存出来ないのは昔からだな
20:デフォルトの名無しさん
23/05/04 17:29:00.42 5uLSpcuJ.net
ITの世界は短期決戦の世界。知名度がこんなに上がってるのに使用者数が1%未満
のRustには一般言語にまで普及する可能性はほぼ無い。
21:デフォルトの名無しさん
23/05/04 17:31:09.86 5uLSpcuJ.net
今までの蓄積ではなく、新しく書かれているコードの量ですら1%未満であることの
意味は、絶対に普及しない路線に入っていると言うことだ。
22:デフォルトの名無しさん
23/05/04 17:38:32.86 5uLSpcuJ.net
商品が売れない原因の9割は知名度不足だと言われているが、Rustは既に最高レベル
の知名度になった。なのに「売れてない」。それは商品自体に問題があると考え
なければならない。俺はRustが嫌いなので、それでいいと思っているが。
23:デフォルトの名無しさん
23/05/04 17:48:43.01 /QrENRCq.net
結論としてはRustはC++に比べるとファイル分轄が非常にめんどくさいと言うことだな
ルールが複雑でめんどくさい
言語仕様なのかcargoの仕様なのかしらないけどフォルダ構造が縛られるし…
24:デフォルトの名無しさん
23/05/04 17:52:33.78 /QrENRCq.net
よくわからんけど自分でstruct沢山作ってcore/modelフォルダ作ってそこに全部突っ込んでフラットに使おうとすると障害があると
implをcore/implに突っ込もうとしても問題があると
それかそれを参照する何かを別に作らないといけないと
自由度が低い
25:デフォルトの名無しさん
23/05/04 17:56:09.35 jCd1Wte6.net
いやーさすがにC++に比べたらRustのが超シンプルなのでわかりやすい
C++のモジュール知っててRustのモジュールを理解出来ない人はいないと思う
26:デフォルトの名無しさん
23/05/04 17:58:28.21 agWF6Rws.net
>>24
障害？
27:デフォルトの名無しさん
23/05/04 18:03:56.15 gkHxEYi2.net
/struct、/impl、/traitみたいな分け方をしたかったのかぁ
できなくはないけどやめといたほうがいいんじゃないか
28:デフォルトの名無しさん
23/05/04 18:06:55.48 /QrENRCq.net
したいんじゃなくてそれは仮に書いただけ
自由度が低いと言うことを示したかっただけ
ファイル名やフォルダ名が縛られたり
なんで自由度が低いのに顔を真っ赤にして自由度が高いと書くのか不明なんだけど
29:デフォルトの名無しさん
23/05/04 18:12:40.50 JNVfsZ/B.net
>>25
C++は至ってシンプルやろ?
30:ななし
23/05/04 18:16:37.43 hLXsMKYH.net
Javaしかやったことない
C++っていいの？
31:デフォルトの名無しさん
23/05/04 18:16:44.50 VOb3FI4m.net
既存のC++のプロジェクトに書き足していくかたちでCargoとかが使われてるんだろ？
C/C++の作法に併せたRustのフォルダ構成の裏ルールがあるとしか思えない
32:デフォルトの名無しさん
23/05/04 18:21:23.60 BxJFarE7.net
モジュール名とファイル名（パス）は↓みたいな書き方で一応切り離せるよ
ややこしくなるから基本使わないけど
#[path="platform/foo_windows.rs"]
mod foo;
自由度が高いってのはたぶん外面を維持したまま内装を変更しやすいって意味で使ってたと思う
（長文だったからちゃんと読んでない）
モジュールの構成は可視性に関わるからそこまで自由ではないと思う
全部にpubつければ自由になるけどそんな自由はいらない
33:デフォルトの名無しさん
23/05/04 18:34:14.75 /QrENRCq.net
自分が使ってる中ではC#が一番自由度が高い気がする
classの分割自由
名前空間の分割自由
プロジェクト内ではフォルダ空間自由
ファイル名自由
34:デフォルトの名無しさん
23/05/04 18:38:46.37 /QrENRCq.net
global usingと言うものが出来て各ファイルでusingもしなくて良くなった
これはいらない機能だと思うけど
35:デフォルトの名無しさん
23/05/04 18:42:44.88 BxJFarE7.net
C#はまじめに使ったことないけど拡張メソッドとかいうのが自由すぎて若干引いた記憶がある
どこで何を足されるか分からない恐怖を感じた
36:デフォルトの名無しさん
23/05/04 18:48:25.91 /QrENRCq.net
プロジェクト内のファイル位置も当然自由
一ファイルに複数の名前空間含めるのも自由
37:デフォルトの名無しさん
23/05/04 19:14:36.30 /QrENRCq.net
Rustがなぜファイル名やフォルダ名でモジュール固定になってるかと言えば
それしかモジュール位置を決定する仕組みがないから
ルートのコードからたどれる物しか名前を解決できないから
それが良くないんじゃないの？
>>35
既存のクラスすべてで必ず拡張されるわけじゃない
本当は拡張などしてなくてただのstaticメソッドだし
どこかそれを他で使われていてもそれをusingしなければ使えないから関係ない
usingしててもpublicじゃなければ見えないので影響はない
38:デフォルトの名無しさん
23/05/04 19:37:12.64 Zob+4ecH.net
proc_macro で黒魔術やりたい放題出来る様になりますた
おまいらのお蔭です本当にありがとうございますた
っていうか proc_macro::TokenStream と proc_macro2::TokenStream と
同時に使うと違うと判ってても混乱するな
39:デフォルトの名無しさん
23/05/04 19:41:38.84 Zob+4ecH.net
>>35
>どこで何を足されるか分からない恐怖を感じた
これは Rust の trait や後付けの impl にも同じ臭いを感じる
40:デフォルトの名無しさん
23/05/04 20:43:05.13 BxJFarE7.net
一応Rustのimplは型（trait）を定義したクレート内に制限かけてるけどそれでも気になる人はいるか
自由な場所で定義を足せるとどうしても散らかりやすくなる
41:デフォルトの名無しさん
23/05/04 21:36:06.92 Zob+4ecH.net
>>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 がぶつかってるのが気に入らない
42:デフォルトの名無しさん
23/05/04 21:37:41.16 Zob+4ecH.net
main.rs の方は
mk_ts!(); だった
43:デフォルトの名無しさん
23/05/05 01:53:22.17 eU2UcLD5.net
>>30
基本的に、JavaとC++は兄弟言語で、共通点がとても多い。
classの概念もほとんど同じだし、とても良く似ている。
一方、RustとC++は全く違う言語。
44:デフォルトの名無しさん
23/05/05 01:56:43.74 ebreeR6p.net
全く違うんだが 現状は C からの置換を目指さなきゃいけない
その辺りが フォルダ構成にも反映されてしまっている
当然だが マッチの箇所は プロログなどの方が近い
45:デフォルトの名無しさん
23/05/05 02:10:01.68 ebreeR6p.net
現にデコンストラクトによるパターンマッチはlispかhaskelくらいでしか見かけない
46:デフォルトの名無しさん
23/05/05 02:29:13.44 iwKPqxU+.net
似てたら置き換えやすいけど、置き換える意味も薄まりそうだけどな
47:デフォルトの名無しさん
23/05/05 04:24:21.70 eU2UcLD5.net
「みんなが使ってないものが使いたい」という心理を持っている人が一定数いて、
Rustはそういう人に受けてる可能性もある。
48:デフォルトの名無しさん
23/05/05 05:02:21.75 0gcLuV9I.net
Microsoft「Windows 11がまもなくカーネル内でRustを用いて起動」
URLﾘﾝｸ(www.neowin.net)
BlueHat IL 2023 カンファレンスにおいて、マイクロソフトのエンタープライズおよび OS セキュリティ担当バイス プレジデントである David Weston が登壇し、
Windows セキュリティの進化について話し合い、最新の進歩と今後の道のりについての洞察を講演しました。
プレゼンテーションの中でWeston氏は、MicrosoftがWindowsカーネルの一部としてRustを使用して行ってきた進歩について説明しました。
いくつかの理由でこの言語に興味を持っており、そのうちの11つはRustが提供するメモリの安全性とセキュリティを中心にしています。
Weston氏は次のように述べています。
「おそらく今後数週間または数か月以内に、カーネルでRustを使用してWindowsが実際に起動することになりますが、これは本当にクールです。
ここでの基本的な目標は、これらの内部C ++データ型のいくつかをRustの同等のデータ型に変換することでした。」
49:デフォルトの名無しさん
23/05/05 05:36:12.75 qNdmxTVk.net
前スレにも書いたけど、ブートローダってDOSアプリみたいなもんで、劇的に画期的じゃないんだよ
APIが早くRust化してほしい そうすれば、C++も恩恵を受ける
50:デフォルトの名無しさん
23/05/05 06:12:56.25 EdqaEPwW.net
マイクロソフトがわざわざC++を捨ててまでRustを採用するとはよっぽどのことだよな
Linuxの方は元からC++さえ排除してC言語だけの純血主義だったのにRustを採用し始めてる
51:デフォルトの名無しさん
23/05/05 06:30:56.10 EdqaEPwW.net
>>49
記事を読んだがブートローダーなんて書かれてなかった
Rustを使った場合のWindows OSのパフォーマンス比較でOffice apps使用の場合が出てくるからブートローダーの話ではないね
52:デフォルトの名無しさん
23/05/05 06:37:43.26 yAiikMv0.net
昔、マイクロソフトはわざわざJAVAを捨ててJ++を開発したんだよなあ
53:デフォルトの名無しさん
23/05/05 06:58:16.61 4d5P5zld.net
これまで多数の言語が登場したけど求められてる条件はたった二つだけ
「C/C++と同等のパフォーマンスが出ること」
「C/C++の各種安全性の問題が解決されていること」
Rustが最初で唯一の言語
54:デフォルトの名無しさん
23/05/05 08:25:55.79 tbrjl4OG.net
>>53
どこの異世界にすんでるんだ？
55:デフォルトの名無しさん
23/05/05 08:50:30.82 hIDnL8bT.net
>>53
安全にするにはGC言語にするしかないと思われていたからね
Rustだけが勝者となった
56:デフォルトの名無しさん
23/05/05 09:46:15.52 whzNuXwL.net
Rust以外でGC採用せずにメモリやリソースの後始末をちゃんとしてくれるよう設計された言語って何があるの？
57:デフォルトの名無しさん
23/05/05 10:06:18.39 kHrmJumu.net
お! GC君だ（この人が複製おじさん?）
GC君は他人のことを初心者呼ばわりするけど
技術的な話が全くできないんだよなぁ...
58:デフォルトの名無しさん
23/05/05 10:21:16.98 kHrmJumu.net
>>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)
59:デフォルトの名無しさん
23/05/05 10:43:09.36 5yMxjojq.net
>>52
JavaScriptをわざわざパクッてJscriptってのも作ったな
今やIEブラウザごと滅んだが
アップルとかソニーとか独自規格を作りたがる連中はいつの時代も迷惑
60:デフォルトの名無しさん
23/05/05 10:47:34.91 /B4W1iLS.net
Rustはメモリリークには割と寛容なんだよね
野生の参照（ダングリングポインタ）は目の敵にするけど
61:デフォルトの名無しさん
23/05/05 10:52:02.55 rN2P+U1s.net
>>56
Rustしか現存しない
他に出てきそうにないため今後Rustの時代が続くのだろう
62:デフォルトの名無しさん
23/05/05 11:08:39.58 nhdCkkeF.net
>>45
>デコンストラクトによるパターンマッチ
聞かない用語ですねぇ～
デコンストラクト
63:デフォルトの名無しさん
23/05/05 11:27:48.85 i1pozoob.net
>>56
Nim
64:デフォルトの名無しさん
23/05/05 11:29:46.84 i1pozoob.net
>>60
ヒモさえ付いてれば無駄遣いしてもOKみたいな
65:デフォルトの名無しさん
23/05/05 11:58:16.34 kHrmJumu.net
RustってNimに対して何か優位なところはあるの?
66:デフォルトの名無しさん
23/05/05 12:01:00.00 1hHdixRp.net
>>63
NimはGC言語
GCに頼らず済ませられる部分のみ使わないで済むというだけ
67:デフォルトの名無しさん
23/05/05 12:15:37.38 t/UudqdO.net
>>56
間違い：メモリやリソースの後始末をちゃんとしてくれる
正解：メモリやリソースの後始末をちゃんとしてくれる(リーク除く)
68:デフォルトの名無しさん
23/05/05 12:17:42.38 0uwn+ADY.net
Nimはnilが存在していてヌル安全ですらない
69:デフォルトの名無しさん
23/05/05 12:18:25.68 O7pFd4FM.net
基本GCでも充分な性能が出れば別にいいよ
最適化が必要なところだけ手動でやるのはRustも同じだから
手動ライフタイム管理とのトレードオフ
70:デフォルトの名無しさん
23/05/05 12:22:56.73 kk7gdR4M.net
>>69
RustはNimのような逃げをしていない点で全く異なるよね
NimはGC言語という点でも誰も異論はなく
71:デフォルトの名無しさん
23/05/05 12:28:44.39 t/UudqdO.net
>>56
Factorかね。
72:デフォルトの名無しさん
23/05/05 12:37:44.37 A/rFKldr.net
FactorはForthとLispの子みたいな動的型付け言語
ガベージコレクションあり
73:デフォルトの名無しさん
23/05/05 16:12:43.08 UEq66Q3K.net
GCの有無は指標になるけど、現状のC++の、なんでもかんでもヒープに置く習慣は、
GCとそんなかわらないんじゃ…と思わなくもなかったり
74:デフォルトの名無しさん
23/05/05 16:21:47.02 ugKRRbai.net
C++はコンパクションが行えないので、GC付きのJavaのほうが速いのです
って言ってなかった？
75:デフォルトの名無しさん
23/05/05 17:13:23.83 /B4W1iLS.net
感覚的にはプリミティブでない単純なデータ（xyz座標とか）の配列を直接作れるかどうかがボーダーな気がする
ポインタの配列を作ってるようだとGCしなくてもGC言語
C#は微妙なライン
変なタイミングで大掃除始める問題もあるけどこっちを気にする機会は少ないような
76:デフォルトの名無しさん
23/05/05 18:05:31.65 ugKRRbai.net
結局、RustはC++より速くても、Javaよりは遅いってことですね
77:デフォルトの名無しさん
23/05/05 19:01:02.92 yAiikMv0.net
もう少し待てはマイクロソフトがR++を出すと思うから
それまで待って
78:デフォルトの名無しさん
23/05/05 23:04:16.37 Vdiv+WAP.net
JAVAが速い！？
79:デフォルトの名無しさん
23/05/05 23:05:51.16 A/rFKldr.net
>>76
Rustはスタックを多用する言語なのでJavaより速い
80:デフォルトの名無しさん
23/05/05 23:35:38.70 ugKRRbai.net
>>79
証拠は？
81:デフォルトの名無しさん
23/05/05 23:47:38.29 A/rFKldr.net
>>80
スタック上のメモリ領域はCPUレジスタであるスタックポインタを足し算引き算するだけでメモリ確保と解放できるため最も速い
82:デフォルトの名無しさん
23/05/05 23:50:40.76 tbrjl4OG.net
>>81
CPUの仕組みを知っててそういう認識の人はいないと思いますよ
83:デフォルトの名無しさん
23/05/05 23:56:37.63 Ena393we.net
もうみた～
84:デフォルトの名無しさん
23/05/06 00:11:48.42 GtwTEHkL.net
>>81のスタックメモリ利用が一番速いで合ってるけど
スタックメモリは関数から戻ると自動的に開放されその部分は無効になっちゃう
そのため従来の言語ではスタックメモリの利用を抑え気味にすることでその問題を過剰に回避してた
Rustはライフタイムの導入でスタックメモリを安全な範囲内の限界まで使えるようになったことが違いかな
85:デフォルトの名無しさん
23/05/06 00:20:07.63 SIOBPdzx.net
CPUのレジスタ利用が一番速いがレジスタ割り付けの最適化が非常に難しいので
スタックを使ってお茶を濁してる
86:デフォルトの名無しさん
23/05/06 00:36:19.82 cJf94Ar1.net
スタックメモリが主記憶と別の場所にあると思ってない？
87:デフォルトの名無しさん
23/05/06 00:39:27.80 cJf94Ar1.net
もしかしてヒープは主記憶、スタックはプロセッサの中にあるとか思ってない？
いま検索中？
88:デフォルトの名無しさん
23/05/06 00:43:00.80 GtwTEHkL.net
メモリの確保の仕方の違いでの速さの比較の話でレジスタの話を持ち出すのは違うでしょ
そしてレジスタの数は限界がありその退避先もスタックメモリですよ
スタックメモリに割り当てられた変数は最適化によりレジスタ割り当てが可能であればレジスタのみ利用になりますね
>>86
スタックメモリは単なるメインメインの一部にすぎません
しかしメモリ確保と解放が最も速いだけでなくメモリキャッシュに載る点でアクセスも速いです
89:デフォルトの名無しさん
23/05/06 00:43:06.74 ky4tntbz.net
キャッシュメモリは主記憶に含めておいた方がいい？
90:デフォルトの名無しさん
23/05/06 00:43:19.23 SIOBPdzx.net
頭のおかしい人間がずっと一般的な事実に基づかない頓珍漢な独自妄想理論を展開してる
91:デフォルトの名無しさん
23/05/06 00:46:32.42 SIOBPdzx.net
スタックを積極的に利用しているからrustがjavaより速いと言われて
納得する馬鹿はいないだろ
もっと根本的な理由があるだろと
javaはVMでスタックマシンをエミュレートしてるから遅い
92:デフォルトの名無しさん
23/05/06 00:48:39.47 SIOBPdzx.net
通常はレジスタ一発で出来ることもわざわざスタックマシンでエミュレートしてるので遅い
93:デフォルトの名無しさん
23/05/06 00:49:43.41 cJf94Ar1.net
Rustもたいがい遅いだろ
94:デフォルトの名無しさん
23/05/06 00:50:53.23 SIOBPdzx.net
頭のおかしい人間がもう一人増えてた…
95:デフォルトの名無しさん
23/05/06 00:53:21.90 +ei0akhP.net
スタックメモリが確保の点でもキャッシュされてる点でも非常に速いのは常識
そのためGC言語であってもGoのようにまずはスタックメモリ利用を優先する
(他へ渡すときだけGC対象になるヒープを利用)
96:デフォルトの名無しさん
23/05/06 00:58:44.72 cJf94Ar1.net
でもJavaのほうが速いんでしょ？
97:デフォルトの名無しさん
23/05/06 01:02:01.90 GtwTEHkL.net
>>95
Rustはそこからさらに一歩進めて他へ渡すときもスタックメモリを使えるように改善してますね
Rustはライフタイムの導入でスタックメモリを安全な範囲内の限界まで使えるようになりました
98:デフォルトの名無しさん
23/05/06 01:13:46.56 SIOBPdzx.net
変な人大集合だね
それがrustよりjavaが速い理由だと思い込んで疑わない変な人たち
99:デフォルトの名無しさん
23/05/06 01:14:41.38 SIOBPdzx.net
おっと逆だ
それがjavaよりrustが速い理由だと思い込んで疑わない変な人たち
100:デフォルトの名無しさん
23/05/06 01:27:18.47 cJf94Ar1.net
RustはJavaより遅いだろ
101:デフォルトの名無しさん
23/05/06 02:12:11.55 8+gQNNXm.net
そなの?
102:デフォルトの名無しさん
23/05/06 03:12:15.76 eTXbn+fa.net
>>101
それはない。
103:デフォルトの名無しさん
23/05/06 06:31:50.59 BGrqS5mo.net
C++とRustに比べればJavaは当然遅いしどうでもいい
104:デフォルトの名無しさん
23/05/06 06:50:56.78 IDnb553v.net
スタックってそんなでかくない、っていう世界もCの領域なんだよね
そんときの感覚を今でも引きずってる気はする
アプリケーションの起動時に、がつんとデカく確保しちゃえばいいんだろうけどね
なんとなく、ね
105:デフォルトの名無しさん
23/05/06 07:22:20.41 cJf94Ar1.net
>>103
Javaが一番速くて、少し遅れてRust、かなり離されてC++だろ
106:デフォルトの名無しさん
23/05/06 07:46:12.61 a72ZoZZa.net
>>95
いわゆるエスケープ解析と呼ばれているテクニックだな
スタックメモリ利用が断トツに速いのでできる限り使うようにする
GoだけでなくJava含めていくつかの言語で行われてるが適用に限界がある
単純には各ポインタのライフタイムが関数内に閉じてればスタックメモリを利用
他の関数に渡した時は確実に追い切れないので難しい
それを可能とするには言語自体がライフタイムをサポートする必要がある
それを実現したのがRustでありライフタイムを完全に追うことができて現在最強
107:デフォルトの名無しさん
23/05/06 09:19:50.79 xQ/L7Xyj.net
RustよりJavaのほうが速くなることも多々あるけど
unsafeやarena使ったりして最適化すればJavaより遅い状況はなくなる
でもJavaもネイティブコンパイルできるようになってるから起動速度含めてシェルスクリプトの代わりに使えるくらいには十分速いよ
108:デフォルトの名無しさん
23/05/06 09:27:14.82 6sJMiJUH.net
ほとんどのベンチマークでRustが圧倒的に速い
自分でunsafeする必要なんかない
109:デフォルトの名無しさん
23/05/06 09:28:26.41 mjWAg2hj.net
JavaやGoより明らかに高い性能を得ようと思ったら面倒臭いRust特有の最適化が必要になるから
自分用のツールに速度目的でRustを使うのは生産性的におすすめしない
製品開発やそれに準ずるライブラリ開発であればRustも有り
110:デフォルトの名無しさん
23/05/06 09:34:58.48 zYAo+dX9.net
>>109
根拠なくそういうデマはよくないと思うよ
「面倒臭いRust特有の最適化が必要になる」なんて聞いたことも体験したこともない
111:デフォルトの名無しさん
23/05/06 09:46:59.89 IDnb553v.net
Javaはないわー
なんだかんだいって、Oracleのドル箱なんでしょ、あそこの法務はなめちゃだめだ＞＜
112:デフォルトの名無しさん
23/05/06 11:45:09.13 SIOBPdzx.net
chatGTPのいい加減なときの答えみたいなレスが増えたな
しょうもない細部にこだわって全体を一切見ない
事実を使って嘘を作るようなレス
113:デフォルトの名無しさん
23/05/06 14:05:33.18 49fczBUH.net
複オジの一人妄想エコーチェンバースレだからね
114:デフォルトの名無しさん
23/05/06 14:07:36.12 O4KUwdol.net
新しい燃料の投下だよ～
Mojo🔥
URLﾘﾝｸ(zenn.dev)
115:デフォルトの名無しさん
23/05/06 15:11:59.44 Vkc9/sC/.net
>>114
> すべてを1つの言語Mojoで書く。
> Pythonを書くか、metalまでスケールダウンします。
> 多数の低レベルのAIハードウェアをプログラムします。
> C++ や CUDA は必要ありません。
挑発的だな
Pythonがベースの拡張で書きにくいことが確定だからどうでもいい
116:デフォルトの名無しさん
23/05/06 15:24:45.43 IfxSkTCE.net
Pythonが手になじんでる人には吉報かも
こりゃC++に流れ込んでくる日も近いね
117:デフォルトの名無しさん
23/05/06 15:27:19.19 Vkc9/sC/.net
C++を不要にする目標なんだろ
無理だと思うが
118:デフォルトの名無しさん
23/05/06 15:39:53.37 u7GkjfSc.net
逆になるべくC++でやって行きたいと思う人も大勢いるということを
分かってない。
119:デフォルトの名無しさん
23/05/06 15:53:28.09 fVZUtdKL.net
名前からして ジョークじゃねえの
オースティンパワーズ デラックスで見たぞ これ
120:デフォルトの名無しさん
23/05/06 16:59:42.98 QDUY2JyG.net
喪女？
121:デフォルトの名無しさん
23/05/06 17:17:38.48 IfxSkTCE.net
Python使いだけど、全部自力で書きたい…みたいな
GC系言語にどんどん拡がっていくんじゃね
122:デフォルトの名無しさん
23/05/06 18:15:47.48 52PGn/Mb.net
>>106のエスケープ解析やライフタイムを本格的にやるのかな
C++を一気に超えてしまいそう
123:デフォルトの名無しさん
23/05/06 18:26:46.92 SIOBPdzx.net
少しrustの仕組みを勉強してきた
いろいろと勉強になった
面白いからしったかさんを泳がしておこうｗ
124:デフォルトの名無しさん
23/05/06 18:43:25.55 0gq0Gmfh.net
Pythonはインスタンスをヒープに置くことしかしていないが
スタックに置いて高速化するかもしれないのか
125:デフォルトの名無しさん
23/05/06 20:28:37.67 IfxSkTCE.net
LLVMとかあのへんに任せるんだろうから、できるようになりだしたらあっという間
126:デフォルトの名無しさん
23/05/06 23:34:35.68 9Mu3Cg1D.net
GCの分だけRustの方がJavaよりも早いんじゃないの
一般論だけど
127:デフォルトの名無しさん
23/05/06 23:43:00.84 8+gQNNXm.net
GCって予測不能なだけで速いか速くないかとは関係ないのでは?
それよりJavaはプロセッサとの間に入るJavaマシンが律速段階なのでは?
128:デフォルトの名無しさん
23/05/07 00:20:35.09 zx4D7i6q.net
一度実行したら コンパイルすりゃいいんじゃね
129:デフォルトの名無しさん
23/05/07 03:11:23.01 +pQ1lZnP.net
RustよりJavaのほうがだいぶ速い
130:デフォルトの名無しさん
23/05/07 06:16:47.38 7BVdtRv5.net
ネイティブコンパイルができるとからしいから、だいぶ速くなったんかしらんが
Java派のサイトでいいから資料示してくれ
>>111 のとおりで、触る気にはならん それこそJavaやるんならRustやる
131:デフォルトの名無しさん
23/05/07 07:39:12.44 UNWBnCPP.net
多くの人たちが一つの問題を色んな言語を用いて実装することで各言語の実行速度比較例
URLﾘﾝｸ(pbs.twimg.com)
AtCoderのABC182-E問題で提出された各プログラミング言語別の実行時間分布
132:デフォルトの名無しさん
23/05/07 07:45:16.15 ga+9ADYk.net
c++の実装数の多さよ。
Rustの「実装しようとしてできなかった数」がどれくらいになるのか知りたいところ。
133:デフォルトの名無しさん
23/05/07 08:07:01.05 IAlaDasW.net
>>131
Rustは書きやすいから
世間での普及と比較して多数使われてるな
速度もRustとC++は並んで最高速
一般での普及指標も毎年ぐんぐん上昇しているからあとは時間の問題のみか
134:デフォルトの名無しさん
23/05/07 10:50:21.49 xEkqTcpa.net
C、C++、Rust の速度に関しては、fact checkが必要。
少なくとも、C や C++ は、高級アセンブラなのだから、最速のはず。
Rustに負ける可能性はゼロ。
135:デフォルトの名無しさん
23/05/07 10:52:23.10 xEkqTcpa.net
「C++はRustより遅い」などと言っている人は、C++の標準ライブラリ(STL)
だけを使った場合に限定してしまっている。
C++は、アセンブラで書けることはほぼ何でも書けるし、Rustはそれを越える
ことは不可能なわけで、C++がRustより遅くなると言うのは論理的におかしい。
136:デフォルトの名無しさん
23/05/07 10:58:59.25 xEkqTcpa.net
もし、「RustがC++よりどうしても速くなる例」があるとするならば、
Rustのコンパイラは、C言語ではかけない特殊なマシン語を出力できる
ようになっているということである。
しかし、RustのバックエンドはLLVMであり、C/C++ のコンパイラ clang の
バックエンドも LLVM であることから、なぜそのような現象が起きるかは
大いに疑問となる。LLVMはLLVMレベルで最適化を行なうことができるような
コンパイラが存在しているので、C++が吐いたコードを最適化しても、
なぜか、Rustが吐いたコードを最適化したものより遅くなってしまうと言う
ことが起きなければならないことになる。
しかし、C++は、高級アセンブラであり、アセンブラで書けることは特殊命令
以外は基本的に全て書ける。ということは、Rustは、そのような特殊命令を
出力しない限りは、C++に勝つことは不可能と言っても過言ではない。
137:デフォルトの名無しさん
23/05/07 11:00:30.38 +pQ1lZnP.net
いや、>>131 を見る限り、平均するとC++はPythonにすら負けてる
138:デフォルトの名無しさん
23/05/07 11:01:52.13 ms6+oRxa.net
誰かがスタックメモリを使ってるからrustが早いと言ってるけどllvmレベルでは差がない
吐き出した中間コードみてもそんな特徴は特になかった
139:デフォルトの名無しさん
23/05/07 11:04:44.26 +pQ1lZnP.net
いや、>>131 を見る限り、平均するとRustは最速
140:デフォルトの名無しさん
23/05/07 11:06:24.77 xEkqTcpa.net
>>136
アセンブラに詳しくない人のために捕捉しておくと、特殊なマシン語の
例外(仲間はずれ)を除けば
「C言語の演算子は、アセンブラ(マシン語)の 1命令に一対一対応している」
とほぼ言える。なので、基本的に、マシン語を1命令ずつ書いていくのと
同じレベルでC言語はプログラム可能である。それに当てはまらないのは
CPUに依存したような「独特なマシン語」が存在している場合に限られる。
そして、コンピュータは、最終的には全てマシン語に置き換えられて実行され、
マシン語しか理解できない。
そして、C++は、C言語の演算子や機能は全て包含している。
ということは、C++は、特殊命令以外のマシン語を全て1命令ずつ記述できる、
ということである。
マシン語しか理解できないCPUに対して、C++は、あらゆる順序のマシン語を
ほぼ人間が思った通りの順序で書こうと思えば書けるのであるから、どうして、
C++が最速に成らないのだとしたら、非常に特殊な事態が起きていることになる。
その特殊な自体は、人間の手作業による最適化であると考えられている。
141:デフォルトの名無しさん
23/05/07 11:07:48.80 xEkqTcpa.net
>>139
平均と言うが、C++は、Rustのsafeモードを越えられる。
逆に、Rustはsafeモードだけを使っていると、C++に絶対に勝てない状況が
存在すると何度も指摘されている。
142:デフォルトの名無しさん
23/05/07 11:09:29.23 ms6+oRxa.net
>>139
それを見てもptyhon最速の人とC#最速の人が何をしたのかが気になるだけ
143:デフォルトの名無しさん
23/05/07 11:12:16.15 xEkqTcpa.net
>>140
「ほぼ」の意味を書いておく。
int x, y;
x = y;
と書くと、x,y をレジスタにとっていない場合は、
マシン語では、
mov eax,dword ptr [&y]
mov dword ptr [&x],eax
の2命令になり、基本的に1命令では書けない。
x,y がレジスタ、ebx, ecx にとられている場合は、
mov ebx,ecx
という1命令で書ける。
だから、x=y は、2命令になるときと1命令になるときが有る。
これが、「ほぼ」の意味である。
144:デフォルトの名無しさん
23/05/07 11:14:47.99 ms6+oRxa.net
llvmは仮想レジスタマシーンである
145:デフォルトの名無しさん
23/05/07 11:15:59.86 xEkqTcpa.net
>>143
同様に、x += y; は、
x,y をレジスタにとっていない場合は、
マシン語では、
mov eax,dword ptr [&y]
add dword ptr [&x],eax
となり、
x,y がレジスタ、ebx, ecx にとられている場合は、
add ebx,ecx
という1命令で書ける。
だから、x += y は、やはり、2命令になるときと1命令になるときが有る。
「ほぼ 一対一対応」の意味は、このような意味で言っている。
C言語はどうしてもマシン語よりも粒度が大きいので、1命令に置き換える
事が出来ずに、2命令か3命令程度になってしまうことはある。
146:デフォルトの名無しさん
23/05/07 11:17:50.86 xEkqTcpa.net
>>145
なお、Rustは、C言語よりさらに少し粒度が大きいことが多い。
C++は、C言語を包含するので、書こうと思えば、C言語と同じ粒度で書ける。
147:デフォルトの名無しさん
23/05/07 11:19:00.29 ms6+oRxa.net
ながながとつまらないことを書いてるな
最適化でsimdを自動で使ってくれるベースがあればそっちが勝つわ
148:デフォルトの名無しさん
23/05/07 11:20:09.23 xEkqTcpa.net
>>146
[補足]
誤解なきように行っておくと、Rustも、= や、+= のような演算子の粒度は、
C言語と基本的に同じことが多いので、その部分に関しての両者に優劣の
差は無い。だから、RustはC/C++と同じ程度の速度が出ることがある。
149:デフォルトの名無しさん
23/05/07 11:21:33.84 xEkqTcpa.net
>>147
基本を知らない人が誤解する可能性があるので書く必要があった。
C/C++がアセンブラ以外に負ける可能性はほぼ無いと言うことの
根拠を示した。
150:デフォルトの名無しさん
23/05/07 11:23:54.31 ms6+oRxa.net
コンパイラは高速化では中間言語化が有効なケースが多い
llvmの最適化はそれで行われてる
rustは二種類の中間言語に変換されてバイトコードを出す
でも中間言語に寄らないヒューリスティックな最適化も存在してる
そちらは泥臭く研究が進められてそちらは今llvmより速いコードを吐き出している
151:デフォルトの名無しさん
23/05/07 11:25:01.81 xEkqTcpa.net
「ほぼ」の意味が、よく誤解されているから、混乱が起きているようなのだ。
「ほぼ」というのは、>>143 や >>145 の意味においてである。
決して、曖昧な意味で言っているわけではない。
152:デフォルトの名無しさん
23/05/07 11:27:12.27 xEkqTcpa.net
>>150
それでも、C/C++は、そのRust独自の最適化後のコードを手作業で書くことが
できるから、Rustに負ける可能性が「ほぼ」ない。
ここで、「ほぼ」の意味は、>>143 や >>145 の意味である。
153:デフォルトの名無しさん
23/05/07 11:28:14.31 ms6+oRxa.net
エスケープ解析はjava一時期重点的に研究されて実装に取り込まれている
誰か天才的な人間が開発に来たんだろう
golangも後追いでエスケープ解析入れてるけどエスケープ解析をオンにすると速度が落ちるケースが多いらしい
開発者が愚鈍なのか想定ケースを外れてるのか不明
154:デフォルトの名無しさん
23/05/07 11:29:33.02 xEkqTcpa.net
マシン語とは、mov,add,sub,mul,imul,div,idiv,cmp,jnz,jb, jbe, ja, jae,call,ret
の組み合わせでプログラムする方式である。
それは、C/C++ 言語で「ほぼ」一対一対応でかけてしまう。
なので、Rustがそれを越えることは「ほぼ」不可能。
「ほぼ」の意味は、>>143 や >>145 の意味。
155:デフォルトの名無しさん
23/05/07 11:34:06.34 xEkqTcpa.net
>>154
マシン語プログラミングとは、
mov,add,sub,mul,imul,div,idiv,cmp,jnz,jb, jbe, ja, jae,call,ret
のような20個ほどの命令を組み合わせて書く書き方。
ところが、C言語では、少し粒度が大きくなってしまうが、それらの20個の
命令に対応する命令が存在している。つまり、C言語では、マシン語の
1～3命令の単位で命令を書くことが出来る。マシン語の1命令にならない
ケースは、レジスタが足りなくて本質的に1命令で書けない場合。
156:デフォルトの名無しさん
23/05/07 11:35:48.42 ms6+oRxa.net
エスケープ解析が有効なシーンにあっても速度向上はわずか1%～2%ぐらいのレベルなので
誤差と言えば誤差
157:デフォルトの名無しさん
23/05/07 11:37:17.94 zo7jDOyY.net
>>154
時代に取り残されてるな
まず大昔にレジスタ最大限活用最適化により1対1は崩れてる
さらにパイプライン最適化によって手書きアセンブリが敗北するようになってのがだいぶ昔の話
並行してキャッシュ最大限活用最適化によりスタック利用有利がさらに強まったり
158:デフォルトの名無しさん
23/05/07 11:38:19.17 xEkqTcpa.net
>>157
そんなことない。
159:デフォルトの名無しさん
23/05/07 11:40:38.01 ms6+oRxa.net
お互いに自分の強いと思う必殺技を叫んで殴り合ってる状態だな
映画館に行かずにこんなところで聖闘士星矢が見られるとは…
160:デフォルトの名無しさん
23/05/07 11:46:33.50 g30pVgXT.net
今は究極のパイプライン最適化により
生成された機械語と元のプログラミング言語は実行順序すら異なる
だから連投してるアホ>>155の書き込みは読む必要なし
memory orderingとかすら知らない低レベル
161:デフォルトの名無しさん
23/05/07 11:46:55.96 xEkqTcpa.net
いくらRustが独自の最適化しても、その最適化と同じことを
C++では書こうと思えば書けてしまうのだから、C++が負ける可能性
はない可能性がとても高いと言うこと。
162:デフォルトの名無しさん
23/05/07 11:48:22.26 xEkqTcpa.net
>>160
そのレベルの最適化は、コンパイラの最後の段階であるところのLLVMレベル
で行なわれるから、Rustとclangで差が出ることは無い。
出るとしたら、LLVM最適化がたまたまその時には上手く最適化できなかっただけ。
163:デフォルトの名無しさん
23/05/07 11:49:35.05 xEkqTcpa.net
>>162
厳密に言うと、「LLVMレベル」ではなく、それより
さらにマシン語に近いところのレベルの最適化。
164:デフォルトの名無しさん
23/05/07 11:54:20.57 0dpKtdVy.net
まあ一番差が出るのは浮動小数ユニットの扱いだけどね。
165:デフォルトの名無しさん
23/05/07 11:57:59.97 sE0vXw4X.net
>>162
同じLLVMを用いていても
C++よりRustが速くなった例はいくつか知られていて
それはRustの参照排他ルールによりLLVMに渡すことができる制御情報オプションが増えることで
LLVMによる最適化がRustの場合のみ生じることが原因のようです
つまりRustの言語仕様がC++より速くなるケースを生み出しています
166:デフォルトの名無しさん
23/05/07 12:20:49.96 ms6+oRxa.net
どんどん互いにいい技術をパクリあって向上したらいいだけだろ
今後AIによるコード研究が進むだろうし技術的境目はどんどんあいまいになってく
過疎板でお互いにペガサス流星拳を打ち合う必要もなくなる
167:デフォルトの名無しさん
23/05/07 12:44:26.77 IEKfrntf.net
>>131
そもそもこのグラフが、何を測定したかの説明も無い。
事実である根拠も無い。
Rustだけ優秀な人がプログラムし、C++では、スクリプト言語上がりの
CPUやマシン語の基礎が分かってない人がプログラムしたのかもしれない。
それに、Rustは、必ず世界最強クラスの最適化バックエンドLLVMを使っている
のに対し、C++用のコンパイラは最適化がほとんど行なわれないような簡易
コンパイラも含まれる。
168:デフォルトの名無しさん
23/05/07 12:45:57.83 7BVdtRv5.net
ていうか、シンプルにしか書けない(のが利点の)Rustに負けるC++の書きようが悪いって話
きれいに書こうなｗ
169:デフォルトの名無しさん
23/05/07 12:47:17.14 IEKfrntf.net
>>131
「実行時間」というが、PICやAKI-H8、ラズパイPICO、安物Androidデバイス
と、Core i9 とでは全然違ってくる。
Rustは、32BIT 以上専用なのに対し、C++ は、8MHz(?) の 16BIT の
PIC マイコンでも使えるのだから、比較にならない。
C++は、安い低速CPUでも動くが、Rustは高級で豪華な CPU でしか動かない
ということだ。それがグラフに現れているだけだろう。
170:デフォルトの名無しさん
23/05/07 12:49:59.71 IEKfrntf.net
>>165
>それはRustの参照排他ルールによりLLVMに渡すことができる制御情報オプションが増えることで
>LLVMによる最適化がRustの場合のみ生じることが原因のようです
>つまりRustの言語仕様がC++より速くなるケースを生み出しています
その場合、C++でも、同じ「参照排他ルール」に従ってプログラムすれば、
LLVMは同じように最適化できるだろう。
171:デフォルトの名無しさん
23/05/07 12:52:04.21 ms6+oRxa.net
>>167
>>169
atcoderは競技プログラムのプラットフォームで参加者がコード書いて提出
コンパイルも向こうでされてるので統一した環境ではあるかなとｗ
172:デフォルトの名無しさん
23/05/07 12:56:54.33 IEKfrntf.net
>>171
だったら、外国では、C++には、レベルの低い人も参加したのに対して、
Rustはレベルの高い人だけが参加した可能性が高い。
173:デフォルトの名無しさん
23/05/07 13:02:09.04 ms6+oRxa.net
atcoderは日本のサイトだよ
出題は英語で去れ店の？
rustは答えを出せる人間が少なく
低レベルコーダーが足切りされてる可能性が高い
174:デフォルトの名無しさん
23/05/07 13:03:09.17 IEKfrntf.net
>>172
もう一つの可能性は、C++は歴史が長いから、古いCPUで測定された時の
実行時間が記録に残っているのに対し、Rustは、新しいCPUで測定された
記録しか存在して無いという不公平があるのかもしれない。
175:デフォルトの名無しさん
23/05/07 13:04:40.62 IEKfrntf.net
>>173
つまり、
「Rustは初心者向けではない」
「Rustは優秀な人が試している段階」
ということを示しているのかもしれない。
176:デフォルトの名無しさん
23/05/07 13:05:35.59 ms6+oRxa.net
おじいさんは自分の見たいものしか見ず考えもしない
177:デフォルトの名無しさん
23/05/07 13:10:50.09 IEKfrntf.net
Rust信者は木を見て森を見ず。
178:デフォルトの名無しさん
23/05/07 13:11:54.80 tSA2wRyk.net
>>170
参照排他ルールに従うプログラミングをするだけでは最適化されません
言語コンパイラがLLVMへその指示を出さないとLLVMは最適化しないし出来ません
例えばLLVMのnoalias最適化指示の場合
Rustではプログラマーは何も指定しなくても言語仕様によりRustコンパイラが自動的にLLVMへ自動的に指示を出します
C言語の場合はrestrict修飾子が導入されているためプログラマーが自己責任で修飾すればCコンパイラがその指示を出すことが可能です
C++は言語仕様にないためプログラマーは指示できません (言語仕様を独自拡張しているコンパイラのみ可能)
以上のようにプログラマーが何も指示せずともLLVMで最適化が行われるRustが有利な現状です
179:デフォルトの名無しさん
23/05/07 13:13:52.93 IEKfrntf.net
>>178
それは初めて知りました。
このスレで初めてまともな意見です。
180:デフォルトの名無しさん
23/05/07 13:15:46.72 TRA1GHWk.net
C++の方が自由度が高いのだから遅く書くことを妨げない
一方でRustの自由度は低い
書いた人のレベルが如実に現れたってだけでは?
実際に最速は変わらない
Cの最速が遅いのはサンプルが少なかったから?
181:デフォルトの名無しさん
23/05/07 13:16:13.51 ms6+oRxa.net
でたらめを書く前によく見ろよ
グラフにatcode abc 182 e と書かれてるからその問題見て見たらいいだろ
abc = AtCoder Beginner Contest
2020-11-08(日) 21:00 ~ 2020-11-08(日) 22:40 (100分)
問題はAからFまであり後ろに行くほど難易度が高い
E問題を見ると再帰も使わないただのループ問題だからrustの有利なシーンはないと思う
制限時間があるからそこまでの問題で事実上足切りされた人が多いんだろ
182:デフォルトの名無しさん
23/05/07 13:20:05.33 IEKfrntf.net
そもそも、atcoder なんて知りませんから。
183:デフォルトの名無しさん
23/05/07 13:21:58.46 ms6+oRxa.net
通常通り書くとやはりpythonとかは遅くなると思う
速い回答出せた人もいると言うことは技術的に枝狩りできるシーンがあるんだろうな
atcoder知らない＝おじいちゃん
184:デフォルトの名無しさん
23/05/07 13:22:50.40 IEKfrntf.net
C++でやった人は、単に個人の遊びとしてやっていただけなのに対し、
Rustでやった人は、Rustの力をこのスレで自慢するために最高の品質
のコードを書いた「バイアス」があった可能性を除外できない。
185:デフォルトの名無しさん
23/05/07 13:23:13.45 TuWfUTcM.net
atcoderで性能比較www
186:デフォルトの名無しさん
23/05/07 13:23:38.22 IEKfrntf.net
atcoderなんてやってるほど暇人じゃないから。
187:デフォルトの名無しさん
23/05/07 13:24:50.84 vTHLWOBH.net
なんで1問だけで比べるのか
データ公開されてるよね？
188:デフォルトの名無しさん
23/05/07 13:24:56.80 ms6+oRxa.net
それでこのスレでペガサス流星拳を撃ってるとｗ
その前におじいちゃんはe問題解けるのかなあ？
189:デフォルトの名無しさん
23/05/07 13:28:05.72 IEKfrntf.net
なにがペガサス流星拳なんだか、幼稚な。
190:デフォルトの名無しさん
23/05/07 13:30:01.06 ms6+oRxa.net
pythonでギリギリ問題解けるようなレベルの人間がc++やrustに移行できるとは思えない
c++やrustという言語で足切りされてる
でも今後はプログラマー不足が顕著になるのでpythonの利用が促進されると思うわ
191:デフォルトの名無しさん
23/05/07 13:33:41.26 IEKfrntf.net
そもそも、「実験しなければ分からない」というのは物理や数学、コンピュータの
世界ではウソ。理論があるし、人間には想像力があるんだから、思考実験で
済む場合が多い。但し、アホな人は除く必要がある。
192:デフォルトの名無しさん
23/05/07 13:34:36.79 ms6+oRxa.net
プログラムの最適化に詳しくてもプログラム自体出来ないなら本当に存在意義が不明なんだよな
○○が早いと言う人より目的時間内にコードを完成させる人が求められている
アセンブラが捨てられて高級言語が使われてる
生産性の向上が一番の問題
○○速くてスゲーと言うのは意味がない
知識があれば小学生にでも言える
193:デフォルトの名無しさん
23/05/07 13:39:28.20 mYeAuY/K.net
>>190
そこで不足している簡単なレベルかつPythonでできるようなことならば
類似サンプルも多数ネット上に転がっているせいでChatGPTが答えられる
だから従来は人員不足とされたその分野の人材は不要となった
C++/Rustで書かれる分野は少なくとも現状のAIは対応できない
特にインフラをAIが吐くコードに依存するのはリスクが高すぎるため人間の最後の砦として需要が残るだろう
194:デフォルトの名無しさん
23/05/07 13:42:06.90 ms6+oRxa.net
小学生に○○流星拳と言う言葉を教える
何かあればそれを叫ばせるこれがこのスレで起こってる全てです
195:デフォルトの名無しさん
23/05/07 14:20:21.84 7BVdtRv5.net
AtCoderの良問は良問だぞ 俺は全然だけど
あんなもん要らねえｗｗｗとうそぶきつつ、こそっとやっとくと賢くなる
196:デフォルトの名無しさん
23/05/07 14:44:33.78 DlXJa/i8.net
>>172みたいに自分に都合の良い想定を平気で行う人間は
どういう大学出てるんだろうな
「可能性が高い」なんて学部生のレポートレベルでも書かないわ
そのへんのリテラシーなくクソレス書き散らしてるの恥ずかしくないのか
197:デフォルトの名無しさん
23/05/07 15:02:41.71 gnxG91Nb.net
大見得切ってる割に単発で書いてる時点でな
198:デフォルトの名無しさん
23/05/07 15:11:30.83 zx4D7i6q.net
競技プログラミングってC++でやるもんでしょ
集まってくるやつのレベルもピンキリだよ
199:デフォルトの名無しさん
23/05/07 15:16:11.45 nivMpMsP.net
>>131の各プログラミング言語の実行速度比較は実行環境が統一されてる点で信頼度が非常に高いと思う
さらに多数の人たちがコードを書いているためコードのせいで遅くなったりする要因も排除できてる
たまにあるベンチマーク比較でコードが下手なせいで言語によって左右されてるのも見かけるため
200:デフォルトの名無しさん
23/05/07 15:29:50.80 ms6+oRxa.net
自分は触れたくないがpythonって存在は面白い
c++やrustには移れないのにpythonならできるって人が多い
今後c++やrustの研究が進んで実行速度が1%上がるとかそんなレベル
乾いたぞうきんを絞ってる
それだったらpythonをjava並みに引き上げるほうが社会的意義があると思う
pythonの有名ライブラリはc++で書かれてチューンされて実行速度は速い
個人が各部分のコードが遅くてもライブラリが速いならこれで十分
でもそれがc++ユーザーに反映されて利用が進んでいるとは言えない
一般の研究で利用はpythonに軸足が移ってる
今後も進むだろうし
201:デフォルトの名無しさん
23/05/07 15:33:01.77 zx4D7i6q.net
いや、どうみてもPython（PyPy3）書いてるやつらはヘタだな
C++のやつらと同じ程度の頭脳なら言語そのものの早さはともかく分布の形状が同じにならないとおかしい
Pythonだとベストのアルゴリズムを選べないんだろうか？
2500msまで行ってるのはC++しか無いがおそらくはタイムオーバーで失敗したやつもいる
この課題をクリアできたやつの統計だな
クリアできなかった人数もやっぱりC++とPythonが多いと思われる
単に利用者が多いからな
202:デフォルトの名無しさん
23/05/07 15:36:56.31 zx4D7i6q.net
頭脳程度が同じだとすればPythonだと10000ms程度で解けるような尾の方が足きりされてるから分布がそう見えるだけなのか？
すると分布の形状はC++とは相似で、pythonではそれが拡大されただけになる
203:デフォルトの名無しさん
23/05/07 15:39:50.70 ms6+oRxa.net
だから知能レベルが低くてコーディングが下手な人間が書いても成果が残せるんならそっちの言語に注視したほうがいい
ある意味優秀だからさ
たまにライブラリレベルで回答できる問題もあるし正規表現で解決できる問題もある
優劣と言うより実現できるかどうかの世界
204:デフォルトの名無しさん
23/05/07 15:41:53.17 zx4D7i6q.net
とするとC++とPythonの下位は全く同じアルゴリズムを使っているが、
C++の言語性能のおかげで2500msに収まっている
考えてることが同じ人間でそう変わるわけもない
205:デフォルトの名無しさん
23/05/07 15:43:48.79 /r7DBuOd.net
まともにプログラミングができる人ならばC++かRustもやるだろうしな
高速さと省メモリで他の言語とはまるで違う
このスレになぜかJavaのほうが速いと主張してる一匹いるが
206:デフォルトの名無しさん
23/05/07 15:46:07.10 /r7DBuOd.net
効率の良いプログラムを書けない人はAI代替でいいから不要となるんじゃないか
C++とRustだけが残りそうだ
207:デフォルトの名無しさん
23/05/07 15:47:17.20 ms6+oRxa.net
e問題を見れば分かるけどおそらく出題内容をベタにそのままプログラムすると遅くなる
c++の人たちはそんなことはしてないと思う
208:デフォルトの名無しさん
23/05/07 15:48:14.10 ms6+oRxa.net
いいすぎかな
実際自分は解いてないで雰囲気で言ってるだけだから的外れかもしれない
209:デフォルトの名無しさん
23/05/07 15:57:11.39 zx4D7i6q.net
後は手元でのコンパイル時間だろうか
gccとrustcでせいぜい100行200行のコード、コンパイル時間に差が出るとも思えないが
100倍も違ったらさすがに競技プログラミングでは忌避されるがそうじゃあないでしょう
そして書いてすぐ試せるとなるとpythonとかになる
にも関わらずRuby利用者がいないのは悲惨としか言いようがない
210:デフォルトの名無しさん
23/05/07 16:01:14.86 0+o01IGu.net
競プロに限らず無駄な効率悪いプログラムを書くプログラマーが溢れてる
そいつらで十分な分野はAIで置き換わるのたろう
ちゃんと考えて効率良いプログラムを書けるプログラマーならC++でもRustでも会得すぐだしな
211:デフォルトの名無しさん
23/05/07 16:03:17.49 ms6+oRxa.net
pythonは有名ライブラリ内でavx512使ってたりする
コードが寄贈されたりしてる
212:デフォルトの名無しさん
23/05/07 16:20:26.96 zx4D7i6q.net
あとはCargoと競技プログラミングの相性だろうか
213:デフォルトの名無しさん
23/05/07 17:00:28.41 ZuSoPChd.net
連休最終日だというのにお前らは
214:デフォルトの名無しさん
23/05/07 17:27:29.15 IEgposGn.net
>>206
効率の良いプログラムもAIが書いてくれるようになる
215:デフォルトの名無しさん
23/05/07 17:44:09.69 eOzMHQ5G.net
>>214
現在のAIの方式だとそれは無理だな
論理の理解がなく例えば素数すら列挙する以外に理解できない
足し算ですら桁が大きくなると間違える
抜本的な大発明が将来起きない限り見込みがないだろう
216:デフォルトの名無しさん
23/05/07 18:06:36.61 +pQ1lZnP.net
>>131 みれば、平均したらRustのほうがC++より速いだろ
それどころか、平均したらC++はPythonにも負けてそうだぞ
217:デフォルトの名無しさん
23/05/07 18:07:20.74 +pQ1lZnP.net
Pythonクソ速いな
C++より速いな
218:デフォルトの名無しさん
23/05/07 18:10:02.13 TRA1GHWk.net
boxプロットも読めない奴がいるなw
219:デフォルトの名無しさん
23/05/07 18:11:19.92 +pQ1lZnP.net
んなもん読まんでええのや
220:デフォルトの名無しさん
23/05/07 18:31:40.13 N703An5k.net
>>215
AtCoderの問題を解くような処理がプログラミングにおいて最もAIを活用できる分野だよ
広く知られたアルゴリズムの最適化なんてお手のもの
221:デフォルトの名無しさん
23/05/07 18:36:12.26 eOzMHQ5G.net
>>220
競プロに興味はない
そんな話はしていない
222:デフォルトの名無しさん
23/05/07 18:42:35.09 +pQ1lZnP.net
C++がウェブ界に進軍したら、お前らみんな無職だぞ
C++のパワーをまざまざと見せつけられ、しょんベンチビルと思うわ
223:デフォルトの名無しさん
23/05/07 18:43:59.40 +pQ1lZnP.net
それにしてもPython速いな
中にRust入ってるのと違うやろな
224:デフォルトの名無しさん
23/05/07 20:06:09.85 IEgposGn.net
>>215
AIが理解できなくてもパターンみたいに学習するからできちゃうんじゃん
突飛な想像力が必要なのは無理だろうけど
225:デフォルトの名無しさん
23/05/07 20:18:49.70 mxXhCe04.net
工夫すれば１行分（＋電球とブロックの位置）の記憶だけで解けるのか
H,Wが1500以下でメモリ制限1024MBだとH×Wの確保も許容範囲だからそこで差がつきそう
解答者全体のレベルがよく分からないけどPythonにもガチ勢がいただけでしょ
226:デフォルトの名無しさん
23/05/07 20:20:12.61 eOzMHQ5G.net
>>224
パターンはその通りで得意
しかしそこからの帰納法が無理
例えば素数を多数知っているがそこから素数の性質特徴を理解するのは無理
ただし学習として素数の性質特徴はわかるしプログラムも多数転がってるのでわかるだろう
でもそれじゃダメだ
未知のもの(初めてのもの)に対して出来ないといけない
227:デフォルトの名無しさん
23/05/07 20:42:06.12 IEgposGn.net
>>226
そういうことができるプログラマ以外いらなくなりそうだよね
228:◆QZaw55cn4c
23/05/07 21:21:38.60 MxFKzH70.net
>>226
素数に関して突っ込んでいえば、素数の定義と素数の性質＝すべての自然数は素数の積で一意に表現できる、との間には大きなギャップがあるのに、それがあまり意識されていないのが問題
229:デフォルトの名無しさん
23/05/07 21:25:03.91 /qC6ccnK.net
>>227
全く逆だよ
そういうことを差別化要素と捉えてるようなプログラマがいらなくなる
コモディティ化しやすい知識とそうでない知識の違い
230:デフォルトの名無しさん
23/05/07 21:34:18.83 IEgposGn.net
>>229
難しくてわかんない
もう少し優しく
231:デフォルトの名無しさん
23/05/07 22:10:30.80 HMVW7dad.net
バイアスがあった可能性を否定できない っていうんなら逆方向も否定できないだろうに、なんでこのおじいちゃんは片方にだけ肩入れするん？
不自然ですよ
232:デフォルトの名無しさん
23/05/08 00:59:11.95 abS4z/F4.net
最大の問題は rustの利用者が何でこんなに少ないかだな
ただ これには複案があって おそらくは C ++から 移ってきたやつらがrustをやってると思われる
すると rustの標榜する モットーにも合致すると思われる
233:デフォルトの名無しさん
23/05/08 01:13:16.38 abS4z/F4.net
もう出ている通りに この問題を最速で解く 機械語 は存在するので
あと疑うべきは 入出力のオーバーヘッドだけになる
メインのアルゴリズム やら ロジック やらが同じなら
遅くしている要因は 入出力だ
234:デフォルトの名無しさん
23/05/08 01:15:13.32 ddy6A8qL.net
>>232
しかし、SNSを見てると、好きな言語にRustを書いている人は、他の好きな言語と
して、JSやGo、Kotlinなどを挙げる傾向が強く、C++は全く書かれてない
ことが多い。
235:デフォルトの名無しさん
23/05/08 02:06:52.10 A57Tkf07.net
C++のほうが機能が多いので、使える人はC++を使うからだろ
236:デフォルトの名無しさん
23/05/08 02:33:43.51 ocGLFPvg.net
機能の差の比較は難しいが
言語自体で様々な安全保証をするRustの機能が本質的に大きいかな
237:デフォルトの名無しさん
23/05/08 02:37:25.24 A57Tkf07.net
C/C++の90%のコードが危険というような話は
9割が20年以上前に書かれているだけで
最近のマナーで書けば済む話では
238:デフォルトの名無しさん
23/05/08 03:00:18.94 ocGLFPvg.net
IT大手各社が揃って同じ判断をした
C++では無理なので新たなシステムからRustを採用
そしてRust Foundationを共同で立ち上げた
さらに既存のWindows、Linux、AndroidなどもRustの採用を開始
239:デフォルトの名無しさん
23/05/08 03:33:40.76 A57Tkf07.net
そんなこと言ったらJavaの採用も開始してるしC/C++なんか大昔から採用を開始してるだろ
240:デフォルトの名無しさん
23/05/08 03:48:41.01 42N5+bFw.net
非GC言語として絶対的な王道を確立したC++が存在するにも関わらず、
新たな部分からC++ではなくRustを採用し始めたことに重い意味があるのでしょう。
しかも競合ライバル同士が同じ判断をした点も非常に重い意味があるのでしょう。
そのため正しい判断をした可能性が極めて高いでしょう。
241:デフォルトの名無しさん
23/05/08 04:02:39.80 yn6KTAlC.net
C++は死ぬべきだけど、後釜がRustでいいかはわからんわ
コストかけて置き換えるなら最高の言語がいいしな
242:デフォルトの名無しさん
23/05/08 04:21:48.93 c35xMa4f.net
Rustの書きやすさは気に入ったね
次の言語はコンパイラが様々な保証をする点を押さえた上で、Rustが取り込めないような別の新たな画期的な機能を持たないといけない
他に芽が現状ないからこのままRustで進みそう
243:デフォルトの名無しさん
23/05/08 04:29:17.13 PP0yxCHU.net
この流れなら言える
cpp2を知らなかったなんて言えない
244:デフォルトの名無しさん
23/05/08 08:23:06.69 eWwLSdkD.net
実際のところ、将来的に最適化はAIがやるようになって、要件定義と検証だけ人間がやるようになるんだろ。
設計自動化の流れだわな。
そうなってくると実装を人間がやる状況は限定されて、言語もIDLみたいになってくるかと。土方コーダーは全滅だな。
まぁ、c++はCOBOLみたいに過去資産メンテに、Rustはpostscriptみたいにバックエンドで生き残る可能性はあるけど。
245:デフォルトの名無しさん
23/05/08 09:34:04.39 mYRj0CUt.net
>>244
AIにとっても機械語を直接吐くのは保守性が悪すぎる
一方で少なくとも当面は人間が検証できる既存のプログラミング言語になりそう
万が一の時の対応や問題把握のためにも既存の言語が良さそう
インフラは人間がある程度把握し続けないとAIに主導権を奪われかねない点でも同じ
使われる言語は自動的に色々と保証されるRustになるのかな
246:デフォルトの名無しさん
23/05/08 10:33:58.34 faKRd8TS.net
人命や経済損失に大きく関わるシステムは責任や論理的な信頼性の観点からAIに頼るのは無理そうだね。
247:デフォルトの名無しさん
23/05/08 10:45:11.11 iczXOFhv.net
AIはTDD（人間がテストコード書いてAIが実装コード書く）と相性いいかなって思ったけど
絶妙にテストケースだけパスするようなコード吐いてきそうで怖い
人間的な一般化パターンを学習すれば使えそうだけど現状だとコピペミキサーでしょ
248:デフォルトの名無しさん
23/05/08 11:29:16.24 Kh0HUP9F.net
AIがどうとか関係無いはずなんだが
Rustのここがダメ！みたいなことを書くと必死でレスしてくれる人がいるから無限に話を脱線させることができるんだね
249:デフォルトの名無しさん
23/05/08 11:46:17.60 PotcPEgC.net
.gitignore に Cargo.lock を入れてるのに
cargo publish すると Cargo.lock もうｐされる
github の方にはもちろんうｐされていない
cargo publish --allow-dirty は本気で要らないものまでうｐされるからこれはやってないのだが
250:デフォルトの名無しさん
23/05/08 12:11:03.58 Re0hEQKj.net
AIに書いてもらうプログラミング言語はC++かRustになるんだろうが、
C++でプログラムの本質でない部分の隙を残すよりも、
コンパイルが通れば静的にその部分が自動検証されるRustになるんだろうな
251:デフォルトの名無しさん
23/05/08 12:16:11.80 PotcPEgC.net
>>174
すばらC洞察
252:デフォルトの名無しさん
23/05/08 12:31:11.67 B7yn02Wa.net
>>251
バカだな
>>131の実行環境のマシンはプログラミング言語に依らず同一に決まってるだろ
253:デフォルトの名無しさん
23/05/08 12:43:44.96 PotcPEgC.net
>>201
これは良いサンプル
URLﾘﾝｸ(www.youtube.com)
254:デフォルトの名無しさん
23/05/08 12:43:46.40 iczXOFhv.net
>>249
内部で呼ばれるcargo packageの仕様っぽいね
URLﾘﾝｸ(doc.rust-lang.org)
の2.でCargo.lockを含める条件が書かれてる
excludeで強引に外せるのかな
255:デフォルトの名無しさん
23/05/08 12:48:52.30 PotcPEgC.net
>>228
全ての素数の積でπを造る公式あるな
256:デフォルトの名無しさん
23/05/08 12:50:45.02 PotcPEgC.net
>>234
C++使ってるけどC++が一番好きではない
どっちかというとCの方が好き
257:デフォルトの名無しさん
23/05/08 12:56:17.27 yn6KTAlC.net
Rustの検証や推論ってAIの役に立つか？というか役に立つようなAIを作るべきか？
それらもコンパイラではなくAIが判断するようにしたほうがよくないか？
258:デフォルトの名無しさん
23/05/08 12:57:11.50 PotcPEgC.net
thx!
259:デフォルトの名無しさん
23/05/08 13:48:29.03 imilCHLn.net
今話題になってるAIは緻密な整合性検証できるというよりも、人間の雑な問いに「らしい」答えを返してくれる感じだから、コンパイラ側の緻密な推論とかは引き続きやっていく必要あんじゃねえの。
260:デフォルトの名無しさん
23/05/08 14:22:47.81 yn6KTAlC.net
>>259
それならAIが内部でRust的なツールを使ってチェックするだけでよくて、
Rustのコードを出力する必要はないんじゃね
261:デフォルトの名無しさん
23/05/08 15:04:56.15 eTYn8zaL.net
>>245
AIにRustのコード吐かせる理由なんて無いよね
262:デフォルトの名無しさん
23/05/08 15:39:48.45 pZhRtbOb.net
Rust急進派によると、rustcをパスするコードは自動的に与信できるらしいので
263:デフォルトの名無しさん
23/05/08 15:42:47.04 QcAzVd3l.net
速度は、1%位の差になってくると、コンパイラの最適化能力に依存するが、
Rustはrustcの強力なLLVMを使っているのに、C++は、LLVMのclangを
使えばいいのになぜかgccを使っていたりするのもおかしい。
264:デフォルトの名無しさん
23/05/08 16:19:16.98 SySGd/wN.net
>>259 >>262
そうするとコードの安全性は人間かコンパイラが保証するしかないわけか
そうなるとAIに書いてもらうコードはRustしかないな
265:デフォルトの名無しさん
23/05/08 16:35:56.27 x8c+D5IZ.net
>>263
llvmの方がgccより性能良くなった?
266:デフォルトの名無しさん
23/05/08 16:41:27.47 NDGne9Ur.net
>>265
12年前から既にclangの方が速いです:
URLﾘﾝｸ(stackoverflow.com)
267:デフォルトの名無しさん
23/05/08 17:24:13.85 dxF1xGv4.net
>>264
仕様を自分で書く
仕様を満たしてるかどうかを確認するテストを機械に書かせる
テストが正しいがどうか人間がレビューする
テストをパスするコードを機械に書かせる
この繰り返し
機械にやらせてるところは今はベンダーに外注してる作業
抽象度が低くパターン化しやすい仕事ほど高い信頼度で機械化しやすい
268:デフォルトの名無しさん
23/05/08 18:43:10.50 A57Tkf07.net
>>266
その手の話は信用ならねえな
269:デフォルトの名無しさん
23/05/08 20:09:42.31 tptm3XCm.net
>>267
コーディングできない上流と設計できない下流の非効率なウォーターホール方式を続けるの？
テストさせられるほどの細かな設計まで自分でやるならコーディングもしてしまった方が早くない？
270:デフォルトの名無しさん
23/05/08 22:23:28.00 Sk4xBlmq.net
>>269
テストの粒度は上流から下流まで様々あるんだよ
テストさせられる==細かな設計とは限らない
ちなウォーターフォールね
271:デフォルトの名無しさん
23/05/08 22:48:34.95 23L22zMg.net
そんな上位の仕様を渡すだけで内部設計も何でも自動でやってくれるAIは当分来ない
学習して曖昧パターンで答えてくれる方のAIは論理的思考がまるでダメ
論理的な方のAIは厳密に指定し尽くさないと適当に補完してやってくれない
根本的に180度違うから融合の見通しもない
272:デフォルトの名無しさん
23/05/09 02:35:37.18 roDNqhiB.net
公開したcrateの要らなくなった古いバージョンとか消したくても消せないのか
githubよりタチが悪いな
他から参照してると仕方ないのが判るが
管理システムとして破綻してないかこれ
273:デフォルトの名無しさん
23/05/09 02:55:17.89 oJhOeTc4.net
yank
274:デフォルトの名無しさん
23/05/09 03:40:24.06 LWOtm1Dy.net
>>268
gccとclangのどちらの最適化が優れているかは誰にも分からないので、
その影響をなくすためにも、rustc と 比較すべきは gcc ではなく、clang
ということになるわけです。なので、今後ベンチマークを取る際には、
rustc vs clang で行かないと意味が有りません。
275:デフォルトの名無しさん
23/05/09 06:12:08.21 CM93Ewnl.net
そのように同じくLLVMを使ってコンパイルしても
>>178のように言語仕様が原因でC++が遅くなりRustが速くなる事例があるんだよな
276:デフォルトの名無しさん
23/05/09 07:51:20.97 roDNqhiB.net
yankしても消えないやん？
277:デフォルトの名無しさん
23/05/09 08:28:08.83 cNhnBb7C.net
いくらC++が速いといっても、ちゃんと書かないと速度は出ない
当たり前の事実と向き合うべき時期が来ているようだなｗ
278:デフォルトの名無しさん
23/05/09 09:22:12.89 E9TE6Urv.net
プログラミングは能力差が激しいからな
C++を使おうが遅いプログラムが出来上がってしまう人たちも多いが本人自身はなかなか気付けない
Rustだとそれが顕著に出るのでわかりやすい
入門初期は仕方ないがその後もRustを難しいとか面倒とか言ってる人たちは能力の低いプログラマーだけ
279:デフォルトの名無しさん
23/05/09 10:03:50.18 MyUREp4F.net
vec!とか使い捲ってると便利過ぎて
コピーされてるのか所有者移動してるのか意識してない人は遅くなりがち
280:デフォルトの名無しさん
23/05/09 10:17:59.79 DWbeMcsH.net
とフィボナッチイテレータより高度なプログラムが書けない人が申しております
281:デフォルトの名無しさん
23/05/09 10:29:01.80 VcsuRebp.net
>>279
vec!はベクタ初期化時のみに用いられるマクロにすぎずそんな問題はない
値一つ指定でN個を初期化するにはClone以外に方法はない
まあClone回避パターンもありRustは完璧だ
282:デフォルトの名無しさん
23/05/09 11:12:55.99 MyUREp4F.net
>vec!はベクタ初期化時のみに用いられるマクロにすぎずそんな問題はない
doubt
>値一つ指定でN個を初期化するにはClone以外に方法はない
doubt
>まあClone回避パターンもありRustは完璧だ
doubt
よくこんな短文で嘘ばかりかけるな
283:デフォルトの名無しさん
23/05/09 11:27:29.07 5GLz9i7j.net
複オジにいちいち突っ込んでたらキリがないぞ
騙されそうな奴がいなければほっとけばいい
284:デフォルトの名無しさん
23/05/09 11:41:48.76 aPAF6NA5.net
オジ使いの人は否定はしても理由も正解も書かないからどっちが正しいのかいつもわからん
285:デフォルトの名無しさん
23/05/09 12:08:20.62 By46q85D.net
オジオジ言ってる人は間違いも多いけど偶然あってるときもあるぞ
適当に聞き流しとけ
286:デフォルトの名無しさん
23/05/09 12:19:41.76 DWbeMcsH.net
な、単発だろ
287:デフォルトの名無しさん
23/05/09 12:27:45.30 DWbeMcsH.net
プログラミング言語に使われる人になってはいけない
プログラミング言語を使える人になりなさい
288:デフォルトの名無しさん
23/05/09 13:50:33.38 TWnpopnf.net
>>275
ですが、LLVMの最適化層は、メモリー領域が重なっているかどうかを解析する
機能も持っていますから、noaliasを明示的に付けなくても、最適化層が
自動的にnoalias相当の属性を付けてくれる場合も有り、そうなれば、
同じ程度に最適化されます。
C 言語の register 属性を付けなくても今のコンパイラは変数を自動的にレジスタ
に割り当てるのと似たようなことです。
飽くまでも補助情報です。
289:デフォルトの名無しさん
23/05/09 14:18:30.40 qRADqwfY.net
>>288
残念ながら一般的な場合にはその解析が不可能
そのためC言語はrestrictキーワードの指定の有無がそのまま最適化の有無に繋がる
このnoaliasによる最適化はベクトル化にも繋がるため実効果も大きい
Rustの可変参照は常にnoaliasとなりLLVMへその情報が伝わるため有利
290:デフォルトの名無しさん
23/05/09 14:27:49.18 TWnpopnf.net
>>289
>残念ながら一般的な場合にはその解析が不可能
一般的には難しいとされていますが、できる場合も有り、実際 LLVM
の最適化層は、解析を「しています」。
291:デフォルトの名無しさん
23/05/09 14:49:54.81 qRADqwfY.net
>>290
もちろんLLVMが解析で見つけ出すケースもゼロではないだろう
実際にはC言語でrestrict指定のコードを書くか否かで最適化の有無となっている現実が多々ある
つまり各言語はnoalias情報をLLVMへ渡したほうが確実に有利だ
C++は言語仕様にないが各コンパイラの独自拡張を使えば指定可能
もちろん無闇に指定してよいわけではなく確実にnoaliasと判断できる場合でないと動作不良を引き起こす
Rustは言語仕様によりデータ競合を起こさないよう可変参照が排他的になるため確実にnoaliasがLLVMに渡る
292:デフォルトの名無しさん
23/05/09 15:08:56.17 oJhOeTc4.net
URLﾘﾝｸ(stackoverflow.com)
だいたいそんな感じなんだけど実際にはバグったせいで付けたり外したりしてしてます
293:デフォルトの名無しさん
23/05/09 15:10:24.05 TWnpopnf.net
>>291
C++でも、noalias をつけたLLVMを出力するコンパイラも有るかも知れません。
コンパイラの進化の問題です。
294:デフォルトの名無しさん
23/05/09 15:21:42.16 GHMOM/oZ.net
>>292
バグが見つかったのはLLVM側ね
Rustが常にnoaliasをLLVMへ指定してくるようになって
適用事例が増えてLLVMのバグが発覚できた感じ
そしてLLVM側がバグ改修中にRust側は一時的にnoaliasの指定をオフした話だね
295:デフォルトの名無しさん
23/05/09 16:23:47.59 oJhOeTc4.net
重要なのは犯人捜しではなく
「可変参照は常にnoaliasとなり」は嘘だということです
296:デフォルトの名無しさん
23/05/09 16:57:31.86 qRADqwfY.net
>>293
Cではプログラマーがrestrict指定した箇所だけコンパイラがLLVMへnoalias指定する
C++ではプログラマーがコンパイラ独自拡張__restrict指定した箇所だけLLVMへnoalias指定される
言語仕様によりC/C++コンパイラがnoaliasを自動付与することはできない
C/C++プログラマーが安全に適用できると判断した時だけ自己責任でrestrict指定することになる
Rustは言語仕様により常に安全に自動的にコンパイラがLLVMへnoalias指定する
そのためRustプログラマーは何もしなくてもnoaliasによる最適化の恩恵を受けることができる
これが根本的な違い
297:デフォルトの名無しさん
23/05/09 17:04:50.38 9RO9lVT1.net
コンパイラに撃墜されてるRustプログラマもいるから「何もしなくても」は言い過ぎだな
298:デフォルトの名無しさん
23/05/09 17:08:17.41 qRADqwfY.net
>>295
現在はLLVMがバグ対応したため常にnoalias指定となる
もちろん意図的にバグ未対応の古いバージョンのLLVMを指定したときを除く
その場合にRustコンパイラはnoaliasを指定しないという安全な動作をする
299:デフォルトの名無しさん
23/05/09 17:09:31.38 oJhOeTc4.net
そんでいったい何nsec早くなるんですか？ってな
些細すぎる点です
300:デフォルトの名無しさん
23/05/09 17:30:52.58 JrSVS9vw.net
Rustならテキトー書いても速くなる…はさすがに夢見すぎだろう (やってないので)しらんけど
301:デフォルトの名無しさん
23/05/09 17:33:18.67 d0WXtuj5.net
おそらくだけど最適化が利いたとしてもベンチとかでは0.01%も速度は速くならないと思うけどな
302:デフォルトの名無しさん
23/05/09 17:35:11.58 d0WXtuj5.net
普通にコードを書く限り一般的な速度は
c<c++<rust何だろ
でもそんなのにこだわって言語選ぶ意味はないよ
303:デフォルトの名無しさん
23/05/09 17:49:39.63 d0WXtuj5.net
速度じゃないわな
実行時間だ
速度だと
c > c++ > rust
304:デフォルトの名無しさん
23/05/09 21:13:21.70 jpsGavbj.net
>>300
Rustは適当に書いたらコンパイル通らない。
305:デフォルトの名無しさん
23/05/09 21:36:53.43 Pc0KyjBY.net
いうて、C++でinline、constexprやらテンプレートメタとかで実行時の処理効率を上げまくったらRustじゃ敵わないと思うんだけど、、
Rustでも似たようなこと出来るんだっけ？
306:デフォルトの名無しさん
23/05/09 21:55:51.60 m/PdBmgz.net
>>305
できるよw
307:デフォルトの名無しさん
23/05/09 22:07:22.50 GHMOM/oZ.net
>>305
Rustもできるよ
そもそもRustのconstはコンパイル時定数でC++のconstexprのこと
Rustの手続きマクロはRustコードの構文解析を入出力としてコンパイル時に実行生成するためC++より強力だね
308:デフォルトの名無しさん
23/05/09 22:10:15.60 Pc0KyjBY.net
なるほどね
俺の全力のC++コードじゃRustには敵わないようだ
309:デフォルトの名無しさん
23/05/09 23:53:36.96 qRADqwfY.net
>>299
>>301
noalias指定で劇的に速くなる例はC言語でrestrict修飾の有無の解説ページが多数あって詳しい
restrict指定がないとnoalias最適化ができずにベクタ化されずに遅くなる例なども出ている
310:デフォルトの名無しさん
23/05/10 07:24:49.96 gVulLBUf.net
テキトーに書いてもコンパイルが通る言語に憧れるなあ
311:デフォルトの名無しさん
23/05/10 08:38:28.50 uLiToFDO.net
体感ではこうかな
c > rust > c++
312:デフォルトの名無しさん
23/05/10 08:59:49.54 yd4Msfz1.net
複雑なことを好き勝手に書けるのがC++だったけど、簡潔に書くことも求められるようになりそうだねえ
当初は複雑だったけど、やることが大体固まったものをrewriteするなら、
いまなら確かにrustがアツい 成果も目に見えると思う たぶんCでは力不足だしね
313:デフォルトの名無しさん
23/05/10 10:30:02.81 gGgNP0IP.net
>>308
全力のrustコードを書けばいい
314:デフォルトの名無しさん
23/05/10 12:47:47.75 of34847N.net
C++相談室part161、ﾜｯﾁｮｲ導入直前のスレ
ｽﾚﾘﾝｸ(tech板:343番)-381
ｽﾚﾘﾝｸ(tech板:481番)-650
C++相談室part162、ﾜｯﾁｮｲ導入直後
ｽﾚﾘﾝｸ(tech板)
"Rust" の検索結果: 1件
は～
315:デフォルトの名無しさん
23/05/10 12:48:26.46 usV3D88W.net
lintだけでもいいから、smart c++とか名前を付けてRustもどきの強制フォーマットを作って欲しいわ。
Rustそのものは要らん。
316:デフォルトの名無しさん
23/05/10 12:49:05.61 of34847N.net
Rust本スレもﾜｯﾁｮｲ無しのほうやめちまえばいいのにな
C++相談室はすんなり移行できてて羨ましい
317:デフォルトの名無しさん
23/05/10 13:11:50.30 dsu8fQGS.net
>>310
それならば静的型付けではない言語を選ぼう
ここは静的型付けのC++とRustのスレだからコンパイル時に可能な限りエラーを出す言語
>>315
その方向を求めるならばRustの方が優れているからC++にこだわる必要ないんじゃないかな
生産性の高いRustを使った方がメリット享受もたくさん
318:デフォルトの名無しさん
23/05/10 13:15:44.86 uLiToFDO.net
crates.io にうｐして docs.rs の comment cover が
中々 100% に到達しないんだが
どこの comment が足りないって簡単に教えてくれるツールは？
local で docker 使えば判るもんなの？
あと「未 comment」数を減らした(=100%に近付けた)はずなのに
逆に%下がるケースもあるみたいで良く判らん
319:デフォルトの名無しさん
23/05/10 14:03:23.86 jzBK8DOC.net
lintにmissing_docs
URLﾘﾝｸ(doc.rust-lang.org)
があるけどデフォルトでallowになってるらしい
lib.rs（main.rs）に
#![warn(missing_docs)]
を足すかコマンドで↓を実行
cargo rustc -- -W missing-docs
320:デフォルトの名無しさん
23/05/10 14:21:07.26 HatbRJDw.net
>>316
注意喚起テンプレとこの隔離スレが効いてるから本スレも平和
321:デフォルトの名無しさん
23/05/10 16:48:54.33 uLiToFDO.net
>>319
?クス
しかし足りない数(あと5ヶ所のはず)よりはるかに多い warning が出て来たでござる
322:デフォルトの名無しさん
23/05/10 17:11:01.06 uLiToFDO.net
>>319
5ヶ所治して残りの warning 放置で 100% 達成出来ました！
ほんとうにありがとうございました！！！
323:デフォルトの名無しさん
23/05/10 17:13:13.74 dsu8fQGS.net
コメントカバー率の計算対象は限定されてるよ
URLﾘﾝｸ(doc.rust-lang.org)
324:デフォルトの名無しさん
23/05/11 03:47:03.48 1mbxr1bo.net
C++だとdoxygenなど使うところが
Rustだと公式サポートされて色々と進んでいるのね
325:デフォルトの名無しさん
23/05/11 08:01:31.45 UvaUTinw.net
URLﾘﾝｸ(twitter.com)
If you're on the Win11 Insider ring, you're getting the first taste of Rust in the Windows kernel!
URLﾘﾝｸ(pbs.twimg.com)
(deleted an unsolicited ad)
326:デフォルトの名無しさん
23/05/11 11:43:59.84 Ue/TF0sJ.net
win32kbase_rs.sys
win32kfull_rs.sys
って何?
ついでに名前が似た以下のファイルも
win32kbase.sys
win32kfull.sys
327:デフォルトの名無しさん
23/05/11 12:35:35.38 hMF5bhvG.net
URLﾘﾝｸ(japan.zdnet.com)
328:デフォルトの名無しさん
23/05/11 12:57:22.38 h0Ssdxno.net
>>327
C++は何故か年々人気が上がってるね
329:デフォルトの名無しさん
23/05/11 13:16:26.32 a3sWIGIB.net
C++0xの暗黒時代を知らない世代が増えたんだろう
330:デフォルトの名無しさん
23/05/11 14:21:03.16 kyUN9mFL.net
>>317
上澄みだけ使うならライブラリも豊富だし悪くない。
本来なら、c++標準化団体がAccelerated C++みたいなのを用意してメンテナンスすべきだと思うけどなぁ。
331:デフォルトの名無しさん
23/05/11 14:44:20.03 Ue/TF0sJ.net
いらね
332:デフォルトの名無しさん
23/05/11 15:04:29.85 OsVl9AaP.net
デザパタ流行した時ほにゃららパターンのほとんどが理解できなかったけどそのうち理解しなくても何の問題もない事が判った
うんこうんこうんこー
333:デフォルトの名無しさん
23/05/11 15:26:04.23 IKYAIOBH.net
>>332
実務で今使ってるのは、state, proxy, singleton, factoryくらいかな。
あとは使ってないね。
334:デフォルトの名無しさん
23/05/11 16:10:38.63 o+lB6Dgi.net
近年の C + 人気は上の画像でも見ただろ
競技プログラミングだよ
335:デフォルトの名無しさん
23/05/11 16:14:51.13 a3sWIGIB.net
GoFのパターンはiteratorとかadapterも含めてるから多分無意識で使ってるよ
昔のforループはi++で回すのが普通だったし
JavaにIterator（foreach構文）が追加されたのが1.5くらいのはず
336:デフォルトの名無しさん
23/05/11 18:30:22.74 mNkrg+hY.net
懐かしの 何とかの呼吸 ○の型 ほにゃらら！が沢山あるけど
使わないときは使わないと言うだけです
337:デフォルトの名無しさん
23/05/11 18:41:36.44 mNkrg+hY.net
Rustの呼吸 一の型 mut代入！
Rustの呼吸 二の型 シャドーイング！
338:デフォルトの名無しさん
23/05/11 18:56:15.63 gsH464oC.net
それ現行コンテンツちゃうの? (初クール初回から録画だけして観てない
339:デフォルトの名無しさん
23/05/11 19:34:36.36 KOkRWEaK.net
C++コアガイドラインに従い、IDE組み込みのチェッカーを使う
これが一般的なスタイル
これだけであなたの悩みはすべて解決する
340:デフォルトの名無しさん
23/05/11 19:37:24.28 KOkRWEaK.net
CCG！CCG！
341:デフォルトの名無しさん
23/05/12 14:15:57.41 qPE7RwmZ.net
終戦のお知らせ
Rust言語で開発されたカーネルがプレビュー版「Windows 11」に - やじうまの杜 - 窓の杜
URLﾘﾝｸ(forest.watch.impress.co.jp)
342:デフォルトの名無しさん
23/05/12 14:19:03.50 jNwvrlvi.net
解散
343:デフォルトの名無しさん
23/05/12 14:25:26.74 uf2dKGIg.net
カーネルのどのへんで使われてるんだろう
Linuxみたいに周辺部分からかな
344:デフォルトの名無しさん
23/05/12 14:32:56.45 yiIZVwAo.net
>>341
Rustの成果をC/C++に還流させるフェーズ どんどんやってくれ
345:デフォルトの名無しさん
23/05/12 14:44:13.86 GoY4o9UG.net
Microsoft Azure security evolution: Embrace secure multitenancy, Confidential Compute, and Rust
URLﾘﾝｸ(azure.microsoft.com)
Rust as the path forward over C/C++
Decades of vulnerabilities have proven how difficult it is to prevent memory-corrupting bugs when using C/C++. While garbage-collected languages like C# or Java have proven more resilient to these issues, there are scenarios where they cannot be used. For such cases, we’re betting on Rust as the alternative to C/C++. Rust is a modern language designed to compete with the performance C/C++, but with memory safety and thread safety guarantees built into the language. While we are not able to rewrite everything in Rust overnight, we’ve already adopted Rust in some of the most critical components of Azure’s infrastructure. We expect our adoption of Rust to expand substantially over time.
346:デフォルトの名無しさん
23/05/12 14:45:57.07 QUxSeMfx.net
マイクロソフト、Rust言語による開発を含む初めてのWindowsカーネルをInsiderプログラム参加者向けに提供開始
URLﾘﾝｸ(www.publickey1.jp)
デバドラからか
347:デフォルトの名無しさん
23/05/12 15:41:33.52 66ak38wv.net
これを見ると、言語の移り変わり時期が来ると
一気に使われなくなって廃れていくんやな、、
URLﾘﾝｸ(m.youtube.com)
348:デフォルトの名無しさん
23/05/12 16:02:52.10 TaYVXf5t.net
むかしもこんな感じでJ++に騙されたんだよ
349:デフォルトの名無しさん
23/05/12 16:05:02.84 vtQb4m8q.net
コンパイラは何使っているんだろうね?
MSがllvmなんかつかうのかな?
350:デフォルトの名無しさん
23/05/12 16:11:29.41 GsK+e8JY.net
Visual Rust++登場も近いな
351:デフォルトの名無しさん
23/05/12 16:19:18.80 MfrxynDP.net
新しいGC言語がどれだけ出て来ても
C++の天下は揺らがない
もしC++が転落するときが来るとすれば
C++の欠点を解決しつつ同等の性能を出せる新たな非GC言語が登場した時だけだ
352:デフォルトの名無しさん
23/05/12 17:14:53.42 0Z+hsanL.net
trait 内の fn は pub 付けていなくても
trait 自体が pub で定義されていたら
他の trait (というか上の trait を引き継いでいる) からでも参照出来るんだね
353:デフォルトの名無しさん
23/05/12 17:16:09.03 0Z+hsanL.net
Visual R++
Visual R#
しっくりこない
354:デフォルトの名無しさん
23/05/12 17:47:30.22 UYEx77Kz.net
R言語はもう別であるからRustがR++になる心配はない
355:デフォルトの名無しさん
23/05/12 17:50:51.87 BjQIXqEx.net
Visual &mut Rust
356:デフォルトの名無しさん
23/05/12 17:54:33.84 qfqUshnI.net
トリビア: トレイトメソッドに付くVisibilityは構文定義上だけは許されている
357:デフォルトの名無しさん
23/05/12 18:18:31.38 0Z+hsanL.net
トレイト完全に理解した！
ヒャッハーっ！！！
358:デフォルトの名無しさん
23/05/12 18:29:46.57 LzgSZzp6.net
URLﾘﾝｸ(doc.rust-lang.org)
Trait items syntactically allow a Visibility annotation,
but this is rejected when the trait is validated.
359:デフォルトの名無しさん
23/05/12 20:36:17.87 qfqUshnI.net
またひどい知ったかぶりしてる……
ｽﾚﾘﾝｸ(prog板:575番)
575 仕様書無しさん 2023/05/12(金) 15:53:45.02
C++のスマートポインタはRustで吸収され
・RustのCopy実装型 (使われる時は自動コピー)
・RustのCopy非実装型 (使われる時はムーブ) ← C++のunique_ptr
・RustのArc型 (atomic増減でスレッド間も利用可) ← C++のshared_ptr
・RustのRc型 (高速にスレッド内で利用可)
つまりunique_ptrの機能がRustでは標準で備わっている
さらにshared_ptrはArcでその軽量版Rcが追加
C++と異なり使い間違えるとコンパイルエラーで知らせてくれる
さらにRustは参照と可変参照の規則によりデータ競合をコンパイル時に防ぐ