Rustアンチスレ (202ﾚｽ)
上下前次1-新
67: 2021/09/04(土)03:57 ID:kn1l/Q+t(1) AAS
>>24
いや、自走車椅子だろ
68: 2021/09/04(土)04:05 ID:iqtSb51S(1) AAS
>>24
C++より便利で安全だから
例えると醤油とソースかな
69(1): 2021/09/06(月)13:53 ID:kq9rR1L5(1) AAS
Rustスレでは場違いなので、イテレータというか高階関数の話にもう一度食いつくとする。
Juliaなんかだと並列・分散処理するために@distributed forなんて書くが、Erlangだとループ中に
spawnをして、Goもgoroutineを起動する。map/reduceなんかだと明らかにメニ―コアを使った方が
速いが、標準ではそうなっていなくて、外部ライブラリのrayonなどを使用する。
GoでもRustでもこれをさらに分散処理させるにはgRPCなど規格化されたインターフェースを通すが
やりたい事はJuliaの@distributed forなのに手間を感じさせる。
Rustにライトウェイトスレッドが言語仕様として入るとは思えないが、やはり言語には向き不向きが
省2
70: 2021/09/06(月)14:51 ID:6RpN+EMp(1) AAS
DSLと同等の使い勝手を汎用的な言語に求めるのはつらいのでは
71(1): 2021/09/06(月)16:49 ID:7r7RF488(1) AAS
>>69
たしかにJavaScriptのasync/awaitとRustのは最も対照的ですがどちらも良い特徴があると思います
JavaScriptはブラウザも外部のNode.jsもその言語実行環境として非同期ランタイムが組み込まれasync/await導入以前から非同期関数が標準として装備
そのため非同期関数が呼ばれたら次のスケジュールで即座に実行が始まりますね
一方でRustは標準の非同期ランタイムがなく用途に合わせて自由に非同期ランタイムを用意することが出来ます
さらにRustのasync/await自体はゼロコストで設計されており非同期関数が呼ばれても自動的にスケジューリングされない特徴があります
Rustはこれらに関して「何ができない」のではなく「何でもできる」わけなので
省1
72(1): 2021/09/11(土)00:36 ID:YO3o85Uj(1/2) AAS
>>71
これは良い書き方をしているが非同期ランタイムを自由に選べるのではなく、適切に選ばないと
インターフェースをサポートしない場合があるため、互換性が保てないでしょう。Rusterは
ゼロコストという話を良くしますが、Rustの非同期はタスクごとにステートマシンを作るために
確かにNode.jsなどと比べるjavascriptと比べれば、全体で非同期をスケジューリング管理する
ものと比べアロケーションや実行コストなどは小さいですが、それほど喧伝すべきことでもありません。
いずれにせよ多くの非同期はI/Oバウンドでありepollベースなどで管理されます。当然ながら
省4
73: 2021/09/11(土)01:17 ID:PRM8i6LA(1) AAS
>>72
あなたの主張は意味がわからない
まず「互換性が保てないでしょう」は何との何の互換性が保てないのか？意味不明
次に「それほど喧伝すべきことでもありません。」は結局のところあなたは反論すら出来ずに同意してしまっている
さらに「Rustに限りませんが(略)設計の悪いライブラリが沢山あるという事です。」はRust言語に対する批判にすらなっていない
それぞれ具体的に問題点を述べましょう
74: 2021/09/11(土)01:24 ID:Q/hQI3Xf(1) AAS
唐突にマクロが登場するのも分かりませんね
async-awaitがマクロだった頃の話をしているのですか？
75(4): 2021/09/11(土)01:41 ID:YO3o85Uj(2/2) AAS
あんたの方が意味不明だけど（笑）
まず文書の書き方にケチを付けてロンパーする癖を直しましょう。
最初から非同期ランタイムの互換性と書いているでしょう。例えばasync-stdと
tokioは互換性がありません。今は互換性がほぼあるようになってきていますが
それでも完全ではありません。
ゼロコストFeatureという話は、VS Javascriptという言語のランタイムではその
通り認めていますが、コンパイル型の言語でコストが高い非同期は稀です。
省9
76: 2021/09/11(土)02:11 ID:w5S7rLqj(1) AAS
>>75
具体的な問題点を述べましょう
例えばtokioの上に構築されたhttpモジュールであるhyperも互換レイヤーによりasync-std 上でも動作します
RustアンチスレでなぜJavaScriptを問題にしているのかも謎ですが
JavaScriptのasync/await/Promiseもあの環境で非常に優れて設計されています
この件についても具体的な問題点を述べておられないですね
77: 2021/09/11(土)11:03 ID:LLoV+Okg(1) AAS
>>75の勝ち
以上
78: 2021/09/11(土)13:53 ID:zUj2TAiQ(1) AAS
>>75
＞「近年のjavascriptを発端とするasync/awaitにも疑問が生じる。
＞あまりにも多くの言語が同期実行のライブラリと整合性が無さすぎる」
意味がちょっと不明です。
JavaScriptでそれらが用いられうる通信分野では、基本的に同期実行のライブラリは存在しません。
例えばhttpなどで取得してくるfetch()も非同期ですし、もっと低水準のモジュールも非同期です。
同期実行のライブラリと整合性が無さすぎるとは、何を意味しているのでしょうか？
79: 2021/09/11(土)13:59 ID:QGVH5OH8(1) AAS
発端と言ったらC#の方が古くね
80(3): 2021/09/12(日)14:45 ID:dsndgRWH(1) AAS
Rustって組み込み開発向いて無くね？
どう考えてもLinuxなりBSDなりある程度高度なOSがある事前提だ、OSのメモリーコンパクションが
無いとGCが無い故にメモリーの断片化が起こり、長時間稼働するタイプの小さな組み込みには向かない。
マイクロコントローラのメモリー付きSoCでブーストラップローダーがあるだけの組み込みには使えない
ま、サポートプラットフォームにTier1/Tier2でも、そういうのに使えるとは書いてないけど
81: 2021/09/12(日)15:02 ID:raaoGYn7(1) AAS
>>80
その文章だけならCにいれかえてもあってそうなんだが？
82: 2021/09/12(日)15:22 ID:lBuMyCBZ(1) AAS
>>80
つまりC/C++/Rustは組み込みやOSに向いていないとｗ
83: 2021/09/12(日)15:26 ID:Cf6Jz1Ay(1) AAS
そこで組み込みのために開発されたJavaですよｗ
84: 2021/09/12(日)21:57 ID:UrK9UNLE(1) AAS
それはリソースがたっぷりある組み込みのケースで感覚としてはアプリ開発に近い
組み込みはピンキリだからスクリプト言語が動く環境まである
一方でC/C++/Rustじゃないと厳しい環境もある
85(1): 2021/09/12(日)22:17 ID:Zjk1d74X(1) AAS
>>75
同期実行ライブラリと整合性が無いというのはウソです
Rustでstd利用の同期とasync-std利用の非同期のプログラムはほとんど同じように書けます
例えば複数のファイルのチェックサム計算を同期と非同期の2通りに書いた以下の記事を参考にすると
外部ﾘﾝｸ:qiita.com
メイン部分の両者のdiffを取ると以下のような感じです
for entry in entries {
省22
86: 2021/09/12(日)22:19 ID:s09Gb+ph(1) AAS
設計にバカが関わってなければC++で十分
87(1): 2021/09/12(日)22:44 ID:Q5FBinyU(1) AAS
コードの規模が大きくなると複雑さが増して相対的に知性下がるからバカが開発することを前提にした方が良い
88(1): 2021/09/13(月)20:47 ID:dBMpD8or(1) AAS
>>87
それは自覚症状が無いだけで自分が馬鹿なだけかも知れんが。
89(2): 2021/09/13(月)20:51 ID:9PNw/wOW(1) AAS
>>88
自分は馬鹿と思ってコード書いた方が良いよ本当に
これはバカにしてるとかじゃなくて心構えとして
90: 2021/09/14(火)19:27 ID:kyozNdb6(1) AAS
>>89は賢いお人
本来馬鹿は馬鹿を自覚できないから
平気でウンコを顔面につけたまま歩き回り
いろんなものを糞まみれにしてケロっとしてる
91: 2021/09/14(火)20:13 ID:Wng5bteL(1) AAS
>>89
お前と俺を一緒にスンナよ。
人間の頭脳は画一敵意ではなく差が大きい。
92: 2021/09/14(火)23:33 ID:9cp1Eg6y(1) AAS
微笑ましい
93(2): 2021/09/14(火)23:52 ID:BSh8VTqx(1) AAS
少なくともある程度以上の大きさの開発したことある人や
複数案件を同時進行した人なら
いくら完璧にしていても確率的にミスが入り込むとわかるはず
そしてC++とRustとの比較ならどちらが良いかも冷静に判断できる
94: 2021/09/15(水)02:02 ID:x4RgVtnC(1) AAS
>>85
そんな事を言ってるんじゃないと思いますよ、「複数のファイルのチェックサム計算」なんて単純な事なら
当然ながら同期と非同期でそれほど違いは出ないでしょうし互換性があるように見えるでしょう。なぜなら
チェックサム計算は一瞬で終わり非同期はファイル毎に区切っているから。チェックサム計算は同期コードで
いずれも書かれていて１つも違いがありません。
これをいくつかのファイルは巨大でファイル長が不明（無限では無い）が大きいファイルのチェックサム計算や
より複雑で時間のかかる計算を非同期で行いたいとすればどうしますか？チェックサム計算で、read_to_endは
省5
95(1): 2021/09/15(水)11:47 ID:PYzW5a+n(1/2) AAS
>>93
確率的な話をするならコンパイラの塾制度考えた場合の確率を下回るくらいのメリットしかrustにはないよ。
96: 2021/09/15(水)20:26 ID:77IP/X5S(1) AAS
>>95
rustcで検出できるバグを仕込む確率よりもrustcのバグを踏む確率の方が高いということ？
97: 2021/09/15(水)21:21 ID:PYzW5a+n(2/2) AAS
rustcで検出できるバグよりcとのバインディングでの勘違いで生じるバグのが多いわな
98: 2021/09/16(木)00:37 ID:Efcezeu+(1) AAS
まあ静的チェックに過剰な期待してる奴は大抵クソだよ
99: 2021/09/18(土)06:51 ID:pceSJQ2d(1) AAS
>>93
そのうち上位層はビジュアルプログラミングに取って代わられて行ったりしてね
100: 2021/09/18(土)07:04 ID:WtcFUHdh(1) AAS
Rustのスレで何を頓珍漢な
101: 2021/09/25(土)03:20 ID:r08K7R9X(1) AAS
コンパイルチェックがゼロになるコードを書けるまでウンコ呼ばわりされる
102: 2021/10/20(水)16:37 ID:rOkBuggn(1/3) AAS
>80
>無いとGCが無い故にメモリーの断片化が起こり、長時間稼働するタイプの小さな組み込みには向かない。
ヒープも使わない（ことが多いから）、メモリーの断片化も起きない
当然GCなんかいらない
rustが組み込みに向かないのは同意する
103: 2021/10/20(水)19:56 ID:VGECjsMp(1) AAS
小さなの規模にもよるけど
スタックや初期化時以外で動的なメモリ確保がそもそもできなくない？
Unix風のプロセスモデルでもないとmallocし続けるだけでアウト
104: 2021/10/20(水)20:18 ID:rOkBuggn(2/3) AAS
組み込みの世界ではヒープじゃなくて、
リンクリストのノードを固定長メモリブロックとして使ったりする
例えばuItronのメモリプールの実装とかそんな感じ
ヒープはリアルタイム性がないから
で、rustはstatic mutが使い辛過ぎて、組み込みでは難しそう
105: 2021/10/20(水)20:22 ID:VyYhhIkP(1/2) AAS
D言語も忘れないで下さい。
106(1): 2021/10/20(水)20:37 ID:rOkBuggn(3/3) AAS
アンチスレとはいえ
将来性を考えると、さすがにD言語よりはrustの方が……
107: 2021/10/20(水)22:36 ID:VyYhhIkP(2/2) AAS
D言語：「忘れないで・・・」
108: 2021/10/20(水)22:52 ID:UtWr6ljA(1) AAS
Deprecated
Dormant
Dead
縁起悪いよ…(´・ω・`)
109: 2021/10/21(木)18:37 ID:wlIxx6Dc(1) AAS
言語と関係ないがrusterのこういう陰湿さが嫌、goに頻繁に嫌がらせしてるし、gcが選べるD言語など
まだまだマイナーな言語へ嫌がらせする
110: 2021/10/21(木)20:22 ID:s+sF4o2E(1) AAS
Dのことマイナーって呼ぶなよ
111: 2021/10/22(金)20:07 ID:BGSpAusK(1) AAS
>>106
将来を考えるなら、文字列でだらだら書くというスタイルが古臭いってなるかもね。
今のプログラミングは、分厚い本を読まされてる、書かされてるみたいなもん。
映像なら3秒でですむことを延々と書き連ねているようなもんだし。
112(1): 2021/10/22(金)21:52 ID:v3Yxx0iq(1) AAS
永遠に可能性が無いとは言わないが、テキスト以外の方法は生まれては消えてを繰り返してるのでどうも期待出来無い。
人間がコード書く役割が終わる方が先に来るんじゃないかな。
113: 2021/10/23(土)08:17 ID:126WIPxs(1) AAS
>>112
AIでも同じようなことが言われていて、
囲碁で人間に勝つには100年かかるなんて言われてたからね。
>人間がコード書く役割が終わる
まさにそれ。
人間は「こうしたい」というのを表現できればそれで良いわけで、それをわざわざ文字列で延々と書き連ねるというのが古臭いことになるんじゃない？ってことね。
114(2): 2021/10/23(土)08:56 ID:3BoTC/ER(1) AAS
現状人間同士である程度厳密に情報を伝えようとすると言葉に頼るわけでコンピューター相手でもそこは変わらない気がする
115: 2021/10/25(月)17:46 ID:a6PpXdhO(1/2) AAS
>>114
わざわざ人間が翻訳機になってるっていうのが古臭いって思うんよね。
116(1): 2021/10/25(月)17:54 ID:a6PpXdhO(2/2) AAS
>>114
文字によるプログラムっていうのが結局いつまで経っても1.5次元みたいなもんで、どことどこが関連しているのかということすらパッと見てわからないしね。
まあ、世の中には何百万行もあるプログラムでも簡単に目を通して全体像を把握できるような天才的な人もいるんだろうけど、私には無理だわ。
トシヨリガーとか、老害だとか言ってる割には旧来の手法に固執するんだな。
117: 2021/10/25(月)20:15 ID:cubP7NbG(1) AAS
>>116
グラフィカルなプログラミング環境とか、設計手法だけどUMLとかあるにも関わらず一般的なプログラミング言語を置き換えるには至ってないよね
旧来の手法を置き換えるには何かしらのブレークスルーが必要なんだと思う
現状プログラミングが主に言葉で書かれているのは、人間がプログラムを考えていることと、人間の考えを厳密にコンピューターに伝える必要があることに由来していると思う
人工知能が発達して人間の曖昧な指示に従ってコンピューターがプログラミングするとか、脳波読みとりなど言語化なしで人間の考えを伝える手段が現れれるなどすれば状況は変わるかも知れない
118(1): 2021/10/25(月)20:53 ID:IG0eAPOa(1) AAS
どの程度の複雑さをコンピュータ側に持って行っても、要求なり目的なりを記述する必要は残る。
いわゆる "プログラミング" では無いかもしれないが。
そこの記述はグラフィカルでどうのこうのと言っても汎用性を求めると結局はテキストになるんじゃないかな。
まあ要求記述のテキスト、というとSQLがその一つなんだけどさ。
119(1): 2021/10/28(木)17:10 ID:nJ3D7u2B(1) AAS
>>118
で、現実にやってるのは、やれCだなんだと、それぞれの方言に合わせて人間が一生懸命翻訳作業をして文字列で書き起こしている。
客観的に見れば実に珍妙な記号とあるふぁべっの羅列でね。
そして、流行りの方言が出るたびにその方言を覚えては翻訳作業。
でも、結局のところコードが大幅に減るわけでもなく、肥大化するにつれて誰も正しい全体像を把握できなくなるのは同じこと。そして、いつまで経っても無くならない誤訳…バグの山。
やはりこのスタイル自体に無理がきているんだと思うわ。まあ、究極はコンピュータそのものの考え方から変えないとダメかもしれないけどね。
120: 2021/10/28(木)17:37 ID:oV3TAAYO(1) AAS
>>119
そのレベルの話だとコーディングと言うよりも設計の問題なのでは
121: 2022/02/26(土)07:53 ID:BV4vpVpG(1) AAS
自分がどうしたいってことしか考えないから、言語が要らないなんて言い出す。
受けとる方を考えてみろ。
122(1): [age] 2022/04/27(水)15:55 ID:1aIRuPS7(1) AAS
CとリリースモードのRustは、どちらも実行時間が最小限です。 Cは未定義の動作でそこに到達します。 Rustは、非常に堅牢な言語定義を使用して、コンパイラーが多くの危険なプラクティスを拒否し、多くの望ましい結果を安全で比較的便利にすることを可能にします。
しかし、Rustは、多くの人が望ましくないと考える特定の動作も許可します。許可されるように言語を定義するだけです。たとえば、整数のオーバーフローを考えてみましょう。デバッグモードでは、Rustは整数のオーバーフローでパニックになります。良い。リリースモードでは、2の補数としてラップします。悪い。つまり、それは言語定義に含まれているので、非常に優れていますが、私に関する限り、これは、符号付き整数のオーバーフローを未定義の動作として参照するCおよびC++言語定義とほぼ同じくらい悪いものです。
123(2): 2022/04/27(水)16:14 ID:fXEX2s7j(1) AAS
>>122
Rustはそのために例えば足し算でも
checked_add
overflow_add
wrapping_add
saturating_add
など用途毎に使い分けられるようになっている
124(1): 2022/04/27(水)18:36 ID:HjqqO7sC(1) AAS
BEｱｲｺﾝ:2iyou_2.gif
あかんところ列挙
・コンパイル型言語らしいけど、C++の方が速い(GCC万歳)
・CPLから派生した言語とかなり系統が違う(習得しづらい)
・関数宣言でわざわざfnをつけないといけない(文脈で理解できないのかコンパイラ)
以下、C++のあかんところ
・最近のは遅い->STL使わんかったらいい、もしくは自作
省1
125(1): 2022/04/27(水)18:45 ID:kbMyQ47R(1) AAS
>>124
RustとC++はほぼ同等の速度
その上でRustは様々な安全性とC++より便利な機能によりプログラミング生産性も良い
126(1): 2022/04/27(水)18:53 ID:DngKLmNp(1/2) AAS
>>123
そういうことを言いたいんじゃない。releaseとdebugで動きが異なることを言いたいのだ。例えばGoなどはどちらも動きはわからない。
Rustはどう考えても、プログラムの１つ１つを完全に知りえていなければプログラムを書いてはならず、安全な側へ倒すのではなく、releaseでオーバーフローを省略するのにそれで速いとゴマカしている。計算系のベンチマークテストなどまさにそう
また上のように「用意している」という表現も、限りなく敷居をわざと高くしているだけで、何の利点でもない。
127(1): 2022/04/27(水)18:55 ID:j3SjDNhs(1) AAS
>>123
checked_add (＝足し算でoverflowするとOption::Noneを返す) 便利だな
例としてすぐオーバーフローするi8型(符号付き8bit整数)を使って
フィボナッチ数列イテレータを書いてみた
fn fibonacci_i8() -> impl Iterator<Item=i8> {
itertools::unfold((0_i8, 1), |(m, n)|
m.checked_add(*n).map(|f| {
省14
128: 2022/04/27(水)18:57 ID:DngKLmNp(2/2) AAS
このようにわざと貼り付けなくても良いことを書いて、不都合を指摘すると流すようにするのは本当に良くないコミュニティの態度
129: 2022/04/27(水)19:00 ID:QwtQyiYP(1) AAS
>>127と同じ関数を他のプログラミング言語で書くとどんなコードになるの？
具体的にコードを比較して客観的に判断したい
130: 2022/04/27(水)22:32 ID:Xa5DwGtB(1) AAS
>>126
release buildでもチェック有効にできるよ
外部ﾘﾝｸ[html]:doc.rust-lang.org
プログラムの一つ一つを理解しなくても書ける言語ってどういうものだろう
131(1): 2022/05/19(木)17:01 ID:YoVN/Jlg(1) AAS
>>125
今どきのC++は遅いっていうけど、新しいC++の仕様を使うからである。
つまり、Better Cみたいな使い方をすればRustより速くなる(実際そういう結果もある)。
まあ、体感はどっちもかわんねえべってとこだから、RustよりJava,C#とかスクリプト言語をアンチすればいいと思う。Rustで慣れてる人はRustで書けばいい。
132: 2022/05/21(土)23:22 ID:zNzebGu9(1) AAS
C++が遅いってコンパイル時間の話ちゃうん
133: 2022/05/23(月)00:46 ID:Fl/zPM6P(1/7) AAS
なんでJavaやC#がスクリプト言語に入ってんだ?
C#にはC#スクリプトがあるが実行時に中間言語にコンパイルするだけだろ
134(1): 2022/05/23(月)00:55 ID:Fl/zPM6P(2/7) AAS
一度だけ必要なメモリを確保して使い回せるものを
オブジェクトとして生成、消滅繰り返すようなプログラム組むと(普通にC++でかくとこっちになる)遅くなるよ
挙句の果てにメモリフラグメントが避けられない
普通にCで書くとよほどの馬鹿でも無い限り無駄なメモリ確保開放を繰り返すなんてことはしないから
135(3): 2022/05/23(月)01:27 ID:aUQlcplw(1/3) AAS
>>134
領域使い回せるってことは生成・解放するオブジェクトのサイズはだいたい一定なんだと思うけど
そうだとしたら最近の普通のmalloc実装ならそうそうフラグメント起こすことはない気がするけどどうなんだろ
ベンチマークとかあるの？
136: 2022/05/23(月)01:35 ID:Fl/zPM6P(3/7) AAS
>>135
行列クラス考えてみろ
while(1)
E = A*B+C/D
C++なら一行でかけるが
137(5): 2022/05/23(月)01:45 ID:Fl/zPM6P(4/7) AAS
誤送信
>>135
行列クラス考えてみろ
while(1)
E = A*B+C/D;
C++なら一行でかけるがテンポラリ領域を演算子の多重定義の中で確保開放繰り返さざるをえない
ETでなんとかなる部分もinverseがあるとそれもお手上げ
省1
138: 2022/05/23(月)01:48 ID:Fl/zPM6P(5/7) AAS
>>135
>普通のmalloc実装ならそうそうフラグメント起こすことはない
ヒープの動的確保でフラグメント興さないなら
RTOSでメモリプール確保する必要なんてないよなww
139(1): 2022/05/23(月)02:08 ID:aUQlcplw(2/3) AAS
>>137
速度に関してはC++の方が不利なことに対しては異論ないよ
ただフラグメントについては本当にそうなのか気になってた
今時のmallocなら直近にfreeされた領域再利用するから>>137みたいな例なら毎回同じ領域が割り当てられると思うよ
寿命が異なる複数のオブジェクトの確保・解放を繰り返すようなケースでも、オブジェクトが同サイズであればmalloc自体のフラグメントを防ぐ機構がうまく働いてくれるはず
まあ確かにRTOSのmalloc実装では問題起こるかもしれないけどね
ただ、そういうのは "最近の普通のmalloc" ではないと思う
140(5): 2022/05/23(月)02:25 ID:Fl/zPM6P(6/7) AAS
>>139
なんで同じ領域が確保されると保証されるのさ。今時のOSでww
そのエリアが外のタスクで割り当てられなかったことがなんで保証できるんだ?
とにかく動的確保、削除してフラグメント起こさないと思ってる方がどうかしてる。
そういう思い込みが通用するなら、所有権なんてもんは必要ないだろ。
あれはデフラグの対象にするかどうかが細大の目的
あと、普通のとか今時のとか、お前のあたのなかこっちは見られないんだから使うのやめろ
141: 2022/05/23(月)02:44 ID:Fl/zPM6P(7/7) AAS
>>137
>速度に関してはC++の方が不利
これもちょっと違うだろ
上で>>131が言ってるようにBetter cに留めて。
過度な見やすさや書きやすさを追求しなければ
C++はC機能包含してるんでC++で不利になることなんてない。
機能を使わなければいいんで不利になりようがない。
省1
142(1): 2022/05/23(月)08:16 ID:aUQlcplw(3/3) AAS
>>140
とりあえずglibcのmallocでいいや
>>137のような解放直後に同じサイズで領域を確保する場合は領域再利用されるよね
143(1): 2022/05/23(月)09:11 ID:n2ZPTBPD(1/3) AAS
// ヒープを使う型Testを作って実証実験
#[derive(Debug)]
struct Test(Box<isize>);
// Test型が作成される時に使われるnew()を実装
impl Test {
fn new(n: isize) -> Self {
let new = Test(Box::new(n));
省21
144(3): 2022/05/23(月)09:17 ID:n2ZPTBPD(2/3) AAS
実行結果
0x55790623d9d0 = Test::new(1)
0x55790623d9f0 = Test::new(10)
0x55790623da10 = Test::new(100)
0x55790623da30 = Test::new(1000)
0x55790623da50 = Test::new(10000)
0x55790623da70 = Test::new(11)
省6
145(3): 2022/05/23(月)09:54 ID:n2ZPTBPD(3/3) AAS
一般的に、今回のような多段の計算の場合は、中間領域が少なくとも2つ必要となる
なぜなら、一般的には「中間値2＝中間値1＋次の項目」と順に計算していくためである
つまり一般的な場合は、5つの変数の足し算ならば、中間値2つを加えて、計7つの領域を必要とする
しかし>>144の結果のアドレスを見ると、確かに中間値は交互にアドレスが異なり2種類だが、全体で6つの領域で済んでいるところに注目
5つの変数の領域は避けられないから、余分に確保されたのは1つのみで済んでいる
これがRust
今回用意したTest型はCopyを実装しなかったため、最初の「中間値1＝a＋b」を計算した時点てaとbは消費されてそれらの領域は解放される
省6
146(1): 2022/05/23(月)11:54 ID:n+tkR/ue(1) AAS
glibc mallocの仕様なのでCやC++でも同じです
147: 2022/05/23(月)14:37 ID:GiQn/B1E(1) AAS
Rubyを長期間動かすとGCがメモリを
細分化してしまうという話かなんかと
混同してんのかな
上下前次1-新書関写板覧索設栞歴
あと 55 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.026s