21/09/15 11:47:44.97 PYzW5a+n.net
>>94
確率的な話をするならコンパイラの塾制度考えた場合の確率を下回るくらいのメリットしかrustにはないよ。
97:デフォルトの名無しさん
21/09/15 20:26:11.48 77IP/X5S.net
>>96
rustcで検出できるバグを仕込む確率よりもrustcのバグを踏む確率の方が高いということ？
98:デフォルトの名無しさん
21/09/15 21:21:02.30 PYzW5a+n.net
rustcで検出できるバグよりcとのバインディングでの勘違いで生じるバグのが多いわな
99:デフォルトの名無しさん
21/09/16 00:37:37.41 Efcezeu+.net
まあ静的チェックに過剰な期待してる奴は大抵クソだよ
100:デフォルトの名無しさん
21/09/18 06:51:34.59 pceSJQ2d.net
>>94
そのうち上位層はビジュアルプログラミングに取って代わられて行ったりしてね
101:デフォルトの名無しさん
21/09/18 07:04:45.25 WtcFUHdh.net
Rustのスレで何を頓珍漢な
102:デフォルトの名無しさん
21/09/25 03:20:19.87 r08K7R9X.net
コンパイルチェックがゼロになるコードを書けるまでウンコ呼ばわりされる
103:デフォルトの名無しさん
21/10/20 16:37:55.38 rOkBuggn.net
>81
>無いとGCが無い故にメモリーの断片化が起こり、長時間稼働するタイプの小さな組み込みには向かない。
ヒープも使わない（ことが多いから）、メモリーの断片化も起きない
当然GCなんかいらない
rustが組み込みに向かないのは同意する
104:デフォルトの名無しさん
21/10/20 19:56:54.98 VGECjsMp.net
小さなの規模にもよるけど
スタックや初期化時以外で動的なメモリ確保がそもそもできなくない？
Unix風のプロセスモデルでもないとmallocし続けるだけでアウト
105:デフォルトの名無しさん
21/10/20 20:18:24.99 rOkBuggn.net
組み込みの世界ではヒープじゃなくて、
リンクリストのノードを固定長メモリブロックとして使ったりする
例えばuItronのメモリプールの実装とかそんな感じ
ヒープはリアルタイム性がないから
で、rustはstatic mutが使い辛過ぎて、組み込みでは難しそう
106:デフォルトの名無しさん
21/10/20 20:22:41.04 VyYhhIkP.net
D言語も忘れないで下さい。
107:デフォルトの名無しさん
21/10/20 20:37:31.19 rOkBuggn.net
アンチスレとはいえ
将来性を考えると、さすがにD言語よりはrustの方が……
108:デフォルトの名無しさん
21/10/20 22:36:34.87 VyYhhIkP.net
D言語：「忘れないで・・・」
109:デフォルトの名無しさん
21/10/20 22:52:38.54 UtWr6ljA.net
Deprecated
Dormant
Dead
縁起悪いよ…(´・ω・`)
110:デフォルトの名無しさん
21/10/21 18:37:53.89 wlIxx6Dc.net
言語と関係ないがrusterのこういう陰湿さが嫌、goに頻繁に嫌がらせしてるし、gcが選べるD言語など
まだまだマイナーな言語へ嫌がらせする
111:デフォルトの名無しさん
21/10/21 20:22:29.58 s+sF4o2E.net
Dのことマイナーって呼ぶなよ
112:デフォルトの名無しさん
21/10/22 20:07:55.54 BGSpAusK.net
>>107
将来を考えるなら、文字列でだらだら書くというスタイルが古臭いってなるかもね。
今のプログラミングは、分厚い本を読まされてる、書かされてるみたいなもん。
映像なら3秒でですむことを延々と書き連ねているようなもんだし。
113:デフォルトの名無しさん
21/10/22 21:52:45.50 v3Yxx0iq.net
永遠に可能性が無いとは言わないが、テキスト以外の方法は生まれては消えてを繰り返してるのでどうも期待出来無い。
人間がコード書く役割が終わる方が先に来るんじゃないかな。
114:デフォルトの名無しさん
21/10/23 08:17:48.59 126WIPxs.net
>>113
AIでも同じようなことが言われていて、
囲碁で人間に勝つには100年かかるなんて言われてたからね。
>人間がコード書く役割が終わる
まさにそれ。
人間は「こうしたい」というのを表現できればそれで良いわけで、それをわざわざ文字列で延々と書き連ねるというのが古臭いことになるんじゃない？ってことね。
115:デフォルトの名無しさん
21/10/23 08:56:15.06 3BoTC/ER.net
現状人間同士である程度厳密に情報を伝えようとすると言葉に頼るわけでコンピューター相手でもそこは変わらない気がする
116:デフォルトの名無しさん
21/10/25 17:46:30.13 a6PpXdhO.net
>>115
わざわざ人間が翻訳機になってるっていうのが古臭いって思うんよね。
117:デフォルトの名無しさん
21/10/25 17:54:38.98 a6PpXdhO.net
>>115
文字によるプログラムっていうのが結局いつまで経っても1.5次元みたいなもんで、どことどこが関連しているのかということすらパッと見てわからないしね。
まあ、世の中には何百万行もあるプログラムでも簡単に目を通して全体像を把握できるような天才的な人もいるんだろうけど、私には無理だわ。
トシヨリガーとか、老害だとか言ってる割には旧来の手法に固執するんだな。
118:デフォルトの名無しさん
21/10/25 20:15:43.78 cubP7NbG.net
>>117
グラフィカルなプログラミング環境とか、設計手法だけどUMLとかあるにも関わらず一般的なプログラミング言語を置き換えるには至ってないよね
旧来の手法を置き換えるには何かしらのブレークスルーが必要なんだと思う
現状プログラミングが主に言葉で書かれているのは、人間がプログラムを考えていることと、人間の考えを厳密にコンピューターに伝える必要があることに由来していると思う
人工知能が発達して人間の曖昧な指示に従ってコンピューターがプログラミングするとか、脳波読みとりなど言語化なしで人間の考えを伝える手段が現れれるなどすれば状況は変わるかも知れない
119:デフォルトの名無しさん
21/10/25 20:53:20.91 IG0eAPOa.net
どの程度の複雑さをコンピュータ側に持って行っても、要求なり目的なりを記述する必要は残る。
いわゆる "プログラミング" では無いかもしれないが。
そこの記述はグラフィカルでどうのこうのと言っても汎用性を求めると結局はテキストになるんじゃないかな。
まあ要求記述のテキスト、というとSQLがその一つなんだけどさ。
120:デフォルトの名無しさん
21/10/28 17:10:44.11 nJ3D7u2B.net
>>119
で、現実にやってるのは、やれCだなんだと、それぞれの方言に合わせて人間が一生懸命翻訳作業をして文字列で書き起こしている。
客観的に見れば実に珍妙な記号とあるふぁべっの羅列でね。
そして、流行りの方言が出るたびにその方言を覚えては翻訳作業。
でも、結局のところコードが大幅に減るわけでもなく、肥大化するにつれて誰も正しい全体像を把握できなくなるのは同じこと。そして、いつまで経っても無くならない誤訳…バグの山。
やはりこのスタイル自体に無理がきているんだと思うわ。まあ、究極はコンピュータそのものの考え方から変えないとダメかもしれないけどね。
121:デフォルトの名無しさん
21/10/28 17:37:46.17 oV3TAAYO.net
>>120
そのレベルの話だとコーディングと言うよりも設計の問題なのでは
122:デフォルトの名無しさん
22/02/26 07:53:14.27 BV4vpVpG.net
自分がどうしたいってことしか考えないから、言語が要らないなんて言い出す。
受けとる方を考えてみろ。
123:デフォルトの名無しさん
22/04/27 15:55:20 1aIRuPS7.net
CとリリースモードのRustは、どちらも実行時間が最小限です。 Cは未定義の動作でそこに到達します。 Rustは、非常に堅牢な言語定義を使用して、コンパイラーが多くの危険なプラクティスを拒否し、多くの望ましい結果を安全で比較的便利にすることを可能にします。
しかし、Rustは、多くの人が望ましくないと考える特定の動作も許可します。許可されるように言語を定義するだけです。たとえば、整数のオーバーフローを考えてみましょう。デバッグモードでは、Rustは整数のオーバーフローでパニックになります。良い。リリースモードでは、2の補数としてラップします。悪い。つまり、それは言語定義に含まれているので、非常に優れていますが、私に関する限り、これは、符号付き整数のオーバーフローを未定義の動作として参照するCおよびC++言語定義とほぼ同じくらい悪いものです。
124:デフォルトの名無しさん
22/04/27 16:14:27.17 fXEX2s7j.net
>>123
Rustはそのために例えば足し算でも
checked_add
overflow_add
wrapping_add
saturating_add
など用途毎に使い分けられるようになっている
125:デフォルトの名無しさん
22/04/27 18:36:40.62 HjqqO7sC.net BE:557647423-2BP(0)
URLﾘﾝｸ(img.5ch.net)
あかんところ列挙
・コンパイル型言語らしいけど、C++の方が速い(GCC万歳)
・CPLから派生した言語とかなり系統が違う(習得しづらい)
・関数宣言でわざわざfnをつけないといけない(文脈で理解できないのかコンパイラ)
以下、C++のあかんところ
・最近のは遅い->STL使わんかったらいい、もしくは自作
・バッファオーバーランとか、危ないことが起こる->そんな阿保プログラムを書かなかったらいい
126:デフォルトの名無しさん
22/04/27 18:45:52.15 kbMyQ47R.net
>>125
RustとC++はほぼ同等の速度
その上でRustは様々な安全性とC++より便利な機能によりプログラミング生産性も良い
127:デフォルトの名無しさん
22/04/27 18:53:45.96 DngKLmNp.net
>>124
そういうことを言いたいんじゃない。releaseとdebugで動きが異なることを言いたいのだ。例えばGoなどはどちらも動きはわからない。
Rustはどう考えても、プログラムの１つ１つを完全に知りえていなければプログラムを書いてはならず、安全な側へ倒すのではなく、releaseでオーバーフローを省略するのにそれで速いとゴマカしている。計算系のベンチマークテストなどまさにそう
また上のように「用意している」という表現も、限りなく敷居をわざと高くしているだけで、何の利点でもない。
128:デフォルトの名無しさん
22/04/27 18:55:26.96 j3SjDNhs.net
>>124
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| {
*m = *n;
*n = f;
f
})
)
}
fn main() {
for f in fibonacci_i8() {
print!("{f} ");
}
}
出力結果:
1 2 3 5 8 13 21 34 55 89
確かに上限127を超えて溢れる寸前まで求まっている
129:デフォルトの名無しさん
22/04/27 18:57:07.63 DngKLmNp.net
このようにわざと貼り付けなくても良いことを書いて、不都合を指摘すると流すようにするのは本当に良くないコミュニティの態度
130:デフォルトの名無しさん
22/04/27 19:00:24.43 QwtQyiYP.net
>>128と同じ関数を他のプログラミング言語で書くとどんなコードになるの？
具体的にコードを比較して客観的に判断したい
131:デフォルトの名無しさん
22/04/27 22:32:13.33 Xa5DwGtB.net
>>127
release buildでもチェック有効にできるよ
URLﾘﾝｸ(doc.rust-lang.org)
プログラムの一つ一つを理解しなくても書ける言語ってどういうものだろう
132:デフォルトの名無しさん
22/05/19 17:01:33.84 YoVN/Jlg.net
>>126
今どきのC++は遅いっていうけど、新しいC++の仕様を使うからである。
つまり、Better Cみたいな使い方をすればRustより速くなる(実際そういう結果もある)。
まあ、体感はどっちもかわんねえべってとこだから、RustよりJava,C#とかスクリプト言語をアンチすればいいと思う。Rustで慣れてる人はRustで書けばいい。
133:デフォルトの名無しさん
22/05/21 23:22:45.63 zNzebGu9.net
C++が遅いってコンパイル時間の話ちゃうん
134:デフォルトの名無しさん
22/05/23 00:46:57.32 Fl/zPM6P.net
なんでJavaやC#がスクリプト言語に入ってんだ?
C#にはC#スクリプトがあるが実行時に中間言語にコンパイルするだけだろ
135:デフォルトの名無しさん
22/05/23 00:55:18.95 Fl/zPM6P.net
一度だけ必要なメモリを確保して使い回せるものを
オブジェクトとして生成、消滅繰り返すようなプログラム組むと(普通にC++でかくとこっちになる)遅くなるよ
挙句の果てにメモリフラグメントが避けられない
普通にCで書くとよほどの馬鹿でも無い限り無駄なメモリ確保開放を繰り返すなんてことはしないから
136:デフォルトの名無しさん
22/05/23 01:27:08.69 aUQlcplw.net
>>135
領域使い回せるってことは生成・解放するオブジェクトのサイズはだいたい一定なんだと思うけど
そうだとしたら最近の普通のmalloc実装ならそうそうフラグメント起こすことはない気がするけどどうなんだろ
ベンチマークとかあるの？
137:デフォルトの名無しさん
22/05/23 01:35:14.45 Fl/zPM6P.net
>>136
行列クラス考えてみろ
while(1)
E = A*B+C/D
C++なら一行でかけるが
138:デフォルトの名無しさん
22/05/23 01:45:51.46 Fl/zPM6P.net
誤送信
>>136
行列クラス考えてみろ
while(1)
E = A*B+C/D;
C++なら一行でかけるがテンポラリ領域を演算子の多重定義の中で確保開放繰り返さざるをえない
ETでなんとかなる部分もinverseがあるとそれもお手上げ
一時領域をwhileの外で確保してそれを使い回す方法と比べて早くしようがない。
139:デフォルトの名無しさん
22/05/23 01:48:39.79 Fl/zPM6P.net
>>136
>普通のmalloc実装ならそうそうフラグメント起こすことはない
ヒープの動的確保でフラグメント興さないなら
RTOSでメモリプール確保する必要なんてないよなww
140:デフォルトの名無しさん
22/05/23 02:08:18.18 aUQlcplw.net
>>138
速度に関してはC++の方が不利なことに対しては異論ないよ
ただフラグメントについては本当にそうなのか気になってた
今時のmallocなら直近にfreeされた領域再利用するから>>138みたいな例なら毎回同じ領域が割り当てられると思うよ
寿命が異なる複数のオブジェクトの確保・解放を繰り返すようなケースでも、オブジェクトが同サイズであればmalloc自体のフラグメントを防ぐ機構がうまく働いてくれるはず
まあ確かにRTOSのmalloc実装では問題起こるかもしれないけどね
ただ、そういうのは "最近の普通のmalloc" ではないと思う
141:デフォルトの名無しさん
22/05/23 02:25:01.02 Fl/zPM6P.net
>>140
なんで同じ領域が確保されると保証されるのさ。今時のOSでww
そのエリアが外のタスクで割り当てられなかったことがなんで保証できるんだ?
とにかく動的確保、削除してフラグメント起こさないと思ってる方がどうかしてる。
そういう思い込みが通用するなら、所有権なんてもんは必要ないだろ。
あれはデフラグの対象にするかどうかが細大の目的
あと、普通のとか今時のとか、お前のあたのなかこっちは見られないんだから使うのやめろ
142:デフォルトの名無しさん
22/05/23 02:44:22 Fl/zPM6P.net
>>138
>速度に関してはC++の方が不利
これもちょっと違うだろ
上で>>132が言ってるようにBetter cに留めて。
過度な見やすさや書きやすさを追求しなければ
C++はC機能包含してるんでC++で不利になることなんてない。
機能を使わなければいいんで不利になりようがない。
Pure C流ででもかけるわけだし
143:デフォルトの名無しさん
22/05/23 08:16:07.89 aUQlcplw.net
>>141
とりあえずglibcのmallocでいいや
>>138のような解放直後に同じサイズで領域を確保する場合は領域再利用されるよね
144:デフォルトの名無しさん
22/05/23 09:11:41 n2ZPTBPD.net
// ヒープを使う型Testを作って実証実験
#[derive(Debug)]
struct Test(Box<isize>);
// Test型が作成される時に使われるnew()を実装
impl Test {
fn new(n: isize) -> Self {
let new = Test(Box::new(n));
// その時にヒープで確保されたアドレスを表示
println!("{:p} = Test::new({n})", new.0);
new
}
}
// Test型の足し算を実装
impl std::ops::Add for Test {
type Output = Self;
fn add(self, rhs: Self) -> Self::Output {
Test::new(*self.0 + *rhs.0)
}
}
// 足し算の途中で使われる一時領域のアドレスはどうなるか？
fn main() {
let a = Test::new(1);
let b = Test::new(10);
let c = Test::new(100);
let d = Test::new(1000);
let e = Test::new(10000);
println!("{:?}", a + b + c + d + e);
}
145:デフォルトの名無しさん
22/05/23 09:17:13.61 n2ZPTBPD.net
実行結果
0x55790623d9d0 = Test::new(1)
0x55790623d9f0 = Test::new(10)
0x55790623da10 = Test::new(100)
0x55790623da30 = Test::new(1000)
0x55790623da50 = Test::new(10000)
0x55790623da70 = Test::new(11)
0x55790623d9d0 = Test::new(111)
0x55790623da70 = Test::new(1111)
0x55790623d9d0 = Test::new(11111)
Test(11111)
つまり足し算で中間生成される一時的な領域は再利用されて使い回されていることが確認された
したがって>>141の主張がおかしい
146:デフォルトの名無しさん
22/05/23 09:54:21.07 n2ZPTBPD.net
一般的に、今回のような多段の計算の場合は、中間領域が少なくとも2つ必要となる
なぜなら、一般的には「中間値2＝中間値1＋次の項目」と順に計算していくためである
つまり一般的な場合は、5つの変数の足し算ならば、中間値2つを加えて、計7つの領域を必要とする
しかし>>145の結果のアドレスを見ると、確かに中間値は交互にアドレスが異なり2種類だが、全体で6つの領域で済んでいるところに注目
5つの変数の領域は避けられないから、余分に確保されたのは1つのみで済んでいる
これがRust
今回用意したTest型はCopyを実装しなかったため、最初の「中間値1＝a＋b」を計算した時点てaとbは消費されてそれらの領域は解放される
そのため次の「中間値2＝中間値1＋c」の時に、中間値2の領域として既に解放されたaの領域が使われた
実際に中間値2のアドレスがaと同じになっていることで確認できる
同様に中間値3は中間値1と同じアドレスとなっている
結論
Rustでは消費し終えた変数や中間値が使用していたヒープ領域もすぐに再利用されて使い回されるため、
>>138のようなケースでも最小限のメモリしか必要とせずに済む
147:デフォルトの名無しさん
22/05/23 11:54:34.12 n+tkR/ue.net
glibc mallocの仕様なのでCやC++でも同じです
148:デフォルトの名無しさん
22/05/23 14:37:05.11 GiQn/B1E.net
Rubyを長期間動かすとGCがメモリを
細分化してしまうという話かなんかと
混同してんのかな
149:デフォルトの名無しさん
22/05/23 15:10:34.13 K4XvBL00.net
>>146
> しかし>>145の結果のアドレスを見ると、確かに中間値は交互にアドレスが異なり2種類だが、全体で6つの領域で済んでいるところに注目
7つ使ってるように見えるんだけど、何を見て6つで済んでるって言えるの？
150:デフォルトの名無しさん
22/05/23 15:44:46 dNJCbMGg.net
たぶん1行目も0x55790623d9d0なのを見落としてる
151:デフォルトの名無しさん
22/05/23 15:46:07 wWZ2mUik.net
>>149
よく見ると2番目の中間値であるTest::new(111)のアドレスが変数aつまりTest::new(1)のアドレスと同じ
これはRust特有でその時点では変数a(や変数b)を使い終えて解放されているために再利用されたと推測できる
そのため6つメモリ領域で済んでいるのだろう
>>147
CやC++では使い終わった変数の領域が暗黙的には解放されないから7つのメモリ領域を使うと予想
152:デフォルトの名無しさん
22/05/23 15:51:35 K4XvBL00.net
>>150-151 あ、ほんとだありがとう。
153:デフォルトの名無しさん
22/05/23 16:28:21.49 wuIMUAe9.net
試しに>>144で中間値をもう一つ必要とする例でやってみた
println!("{:?}", (a + b) + (c + d) + e);
メモリ1 = Test::new(1)
メモリ2 = Test::new(10)
メモリ3 = Test::new(100)
メモリ4 = Test::new(1000)
メモリ5 = Test::new(10000)
メモリ6 = Test::new(11) // (a + b)
メモリ1 = Test::new(1100) // (c + d)
メモリ3 = Test::new(1111) // (a + b) + (c + d)
メモリ6 = Test::new(11111) // (a + b) + (c + d) + e
即座に解放された変数領域を2つ使う点で異なるが結果的に計6つ使用に収まっているな
154:デフォルトの名無しさん
22/05/24 10:09:58.38 PPYrRT7r.net
URLﾘﾝｸ(wandbox.org)
ところでこの結果とフラグメンテーションって特に関係あるんですかね
155:デフォルトの名無しさん
22/05/30 14:58:44.37 MKPVbFKD.net
>>145
>>146
なーにを馬鹿な考察してんの?
おまえの実行するタスクの途中で他のタスクが実行され、そいつが解放したヒープを確保しないことを
なんで今時のマルチタスク、マルチユーザOSで保証できるのかと言ってる。
156:デフォルトの名無しさん
22/05/30 15:12:27.13 MKPVbFKD.net
>>146
>Rustでは消費し終えた変数や中間値が使用していたヒープ領域もすぐに再利用されて使い回されるため
変数が確保されるのは関数コールの度に毎回上書きされるスタックであてｔヒープではない
そもそもヒープ領域の確保廃棄で何も問題なければメモリフラグメントなど発生するはずがない。
したがって長期間リブートを想定しないRTOSで、
予めメモリプールを確保してその中で固定的にメモリ割り当てなど行うこと自体全くの無意味ってことだが、
現実はそーじゃない。こんなもんエンベ試験あたりのイロハだろw
157:デフォルトの名無しさん
22/05/30 15:42:14 9QWL5Xmb.net
>>155
マルチタスク、マルチユーザーOSというキーワードが出てくるのがよくわからないけど、
物理アドレスの話してるとしたらスタックだろうがヒープだろうがOSの都合で変わりうるんだからヒープのフラグメントの話とはなんら関係ないよね
仮想アドレスの話をしているなら、自プロセスの他スレッドの挙動によってフラグメントしうると言うのは正しいけど
だいたいのmalloc実装ではarenaはスレッドローカルになるからフラグメントは置きにくいと思うよ
というか、どういうシチュエーションで何を実験したときにどのような問題が起きたのか、前提を明確にしてよ
組み込みのRTOSとかいう特殊環境が当たり前のように語られると意見のすりあわせができぬ
158:デフォルトの名無しさん
22/05/30 15:55:38.95 MKPVbFKD.net
>>143
> >>138のような解放直後に同じサイズで領域を確保する場合は領
なんで、マルチタスクのOSが、おまえの都合のいいタイミングで解法直後に確保できるのかと言ってる。
例えば、解法直後に割込タスクがおまえのプログラムを一時実行停止し、
そこで開放したばかりのメモリエリアを確保しないとなんで言い切れるんだと聞いてる。
そして、ページングの発生もなんでおこらないと決めてかかってるんだ? 今時のOSでww
おまえが書き出したメモリエリアはあくまでプログラム側から見た論理アドレスだろ?
そこが実はページング対象になってなかったとなぜ断言できるんだ。
159:デフォルトの名無しさん
22/05/30 15:57:12.40 MKPVbFKD.net
>>157
>物理アドレスの話してるとしたらスタックだろうがヒープだろうがOSの都
プログラムからは論理アドレスしか見えない
同じ領域を確保してるかどうかはプログラムからはわからない
160:デフォルトの名無しさん
22/05/30 16:07:33.52 MKPVbFKD.net
>>157
>マルチタスク、マルチユーザーOSというキーワードが出てくるのがよくわからないけど
汎用OSで自分の起動したタスクしか動いてないと思ってるわけ?
RTOSを持ち出したのは自分のタスクしか実行していなくても、フラグメントを起こす具体例として持ち出した。
そのRTOSでも細心の実装心掛けてるのに汎用OSなんでいわずもがなって話。
今時は、HWのメモリが大きくなってせいぜいページング時のプチフリーズ程度で気付いてない奴もいるだろうが、
やっぱりフラグメントは常時発生してる。
てか、メモリデフラグとか動かしたことないのか?
161:デフォルトの名無しさん
22/05/30 16:23:56.84 S6YD6bxt.net
それなんかRustと関係あるんすか？
162:デフォルトの名無しさん
22/05/30 16:55:49 ccLFuKy8.net
>>155
まずは基礎知識を勉強しよう
Rustにおいてタスクとは非同期にスケジューリングされるスタックレスなコルーチンのこと
そうでない意味のタスクならばプログラミング言語Rustとは関係ない話
>>156
そのRustプログラム例はBoxを使っているのでスタック上てはなくちゃんとヒープを用いた実験となっている
そんな基本的なことも理解できないならば勉強して出直してきなさい
>>160
それはRustとは全く無関係ない話
基礎的なことを会得していないとそういった無関係な話を持ち出してしまう
163:デフォルトの名無しさん
22/05/30 18:21:04.97 9QWL5Xmb.net
>>158
ページサイズより大きい領域の獲得解放を繰り返す想定で良いのかな？
malloc/freeがmmap/munmap呼び出しと一対一対応するような
で、どのOSの実装で問題が起きたの？
164:デフォルトの名無しさん
22/05/30 22:33:20 SMH6yVl4.net
ページ単位で割り当てるのにどうやってフラグメンテーション起こすんだろう
165:デフォルトの名無しさん
22/05/31 14:19:31.88 X/NoC31E.net
じゃあなんでLinuxやBSD、Windowsはメモリコンパクション機能を実装してるの？
166:デフォルトの名無しさん
22/05/31 14:23:20.93 5HfxTPdy.net
>>165 LinuxやBSD、Windowsはメモリコンパクション機能を実装してるの？
167:デフォルトの名無しさん
22/05/31 16:38:22.49 COFqsPBY.net
なんで、mallocの話がOSの話とすり替わってたの？
168:デフォルトの名無しさん
22/05/31 19:29:31.55 6cb4XAup.net
>>141あたりでもう一緒くたにされてるからしょうがない
たぶん誰も問題意識を共有できてない
169:デフォルトの名無しさん
22/05/31 20:07:12.82 qkI00F5r.net
たぶんmallocとOSが密に関連するようなRTOS?が前提なんだと思うよ
>>141は業務で触ってるとかで特性をよく知っているがそのコンテキストが他の人と共有できていないのだろう
170:デフォルトの名無しさん
22/05/31 20:16:37.40 /PJVfDdU.net
ずっと暴れている>>141だけが『所有権』と『OS』を同時に登場させていて二つの別レイヤのメモリ管理の話を区別できていない
ここはRustアンチスレなのにプログラミング言語Rustとは無関係な話で暴れていている
171:デフォルトの名無しさん
22/05/31 21:05:52.27 ycu/V5YM.net
便乗すんな複おじ
172:デフォルトの名無しさん
22/05/31 22:22:41.63 qkI00F5r.net
まあ所有権の話は唐突でよく分かんないけど彼の中では理屈的に繋がりがあるのではないのかな
もうちょっと丁寧に書いてくれれば分かりそうな気もするんだけど
173:デフォルトの名無しさん
22/07/07 09:23:29 kCv7I/gK.net
あーうぜー
1.61.0ビルドしてるけどなんだかいろいろとボコボコDLしてくる()
1.61.0なのに 1.60.0-xxx をDLしてくるし()
あーうぜー
174:デフォルトの名無しさん
22/07/09 14:07:59.53 52J5yu6r.net
いつのまにかpython module のビルドに入り込んでるのな
悪質
175:デフォルトの名無しさん
[ここ壊れてます] .net
腐れ言語
早く外せよ
176:デフォルトの名無しさん
22/09/04 20:06:08.29 9yOWYxc4.net
なんか第二Javaという感じの臭いがする
非人間的な設計で人間を不幸にしていく悪しき文明というか
177:デフォルトの名無しさん
22/09/07 04:11:07.00 h5FYCJvl.net
確かに奴隷言語っぽいね
178:デフォルトの名無しさん
22/10/08 07:50:08.22 fwLI4Y/X.net
linus はこれがいいみたいだけどな()
git も Rust もゴミ
179:デフォルトの名無しさん
22/10/10 15:43:56.96 OkLu+Ovr.net
meson のビルドで、
× Preparing metadata (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> [64 lines of output]
こんなエラーが出た
すげーイラっとくる
> .toml
クズ言語
180:デフォルトの名無しさん
22/10/12 21:08:34.50 BNoDz+WR.net
>>178
重要な部分はRustで作らないと思うよ
181:デフォルトの名無しさん
22/10/20 18:29:22.69 uCae9JR1.net
なんでこれ、こんなにコンパイル遅いの？
182:デフォルトの名無しさん
22/10/20 18:33:14.88 sgmqUmRA.net
>>178
俺もgitもgithubも使いにくいと思っていた。
183:デフォルトの名無しさん
22/10/20 18:58:12.23 1LIQj8JQ.net
git自体は悪いと思わんが、なんかgit奉行が色々言い出すのがうざいわ。
rustもそういう匂いがぷんぷんする。
184:デフォルトの名無しさん
22/10/20 19:21:40.91 LtHEChVu.net
どのバージョン管理ソフトが良いの？
185:デフォルトの名無しさん
22/10/21 01:23:53.55 sdgXBR6P.net
>>184
名前は変わったと思うが、MS製のVisual Source Safeなんかは直感的で便利
だったな。特に何も学ばなくても普通に使えた。
186:デフォルトの名無しさん
23/08/11 13:18:17.34 98F5eoJ/.net
cargo check error: failed to run custom build command for `glib-sys v0.17.10`
いい加減にしろよカス言語
187:デフォルトの名無しさん
23/08/11 13:34:35.94 v1edpQDw.net
cargo publish して初めて出るエラー (cargo のあっち側の環境でコンパイルしてる) ってうざいよね
188:デフォルトの名無しさん
23/08/12 00:05:38.13 qDONLKM9.net
>>186
Cコンパイラかリンカが入ってないんじゃね
そのメッセージの前に何か出ていると思うが
>>187
あっち側ってcrates.ioのこと？
リモート側でビルドなんか走るんだっけ
189:デフォルトの名無しさん
23/08/15 08:53:12.04 ca01mENm.net
firefox のビルドもrust が邪魔しまくりだよね()
190:デフォルトの名無しさん
23/10/02 13:43:22.96 sFvf9xp1.net
RustとC++の相性は最悪だが
RustとCはまあまあイケる
いいじゃんいいじゃん
191:デフォルトの名無しさん
23/10/03 16:57:54.88 rr8MlNTB.net
カス言語ではない
192:デフォルトの名無しさん
23/10/05 17:14:00.69 WXXGTjkD.net
C美しい
C++カス
Rustもうちょっとがんがれ
193:デフォルトの名無しさん
24/04/21 15:50:07.23 aDRU4sod.net
Rust リファクタリングしてるときに
trait 境界が変わって
あれ？ってなることが多いな
194:デフォルトの名無しさん
24/04/21 18:44:44.75 GAd5jyBU.net
>>193
trait境界を満たせなくなるとコンパイラが教えてくれるので安全にリファクタリングできて良いよね
195:デフォルトの名無しさん
24/04/23 10:33:27.89 9zVe0TBb.net
>>0185
お前はディストリ自分で組まないの？
情弱だな(ﾌﾟ
196:デフォルトの名無しさん
24/04/23 10:47:04.81 bJrnaJAq.net
創価
197:デフォルトの名無しさん
24/04/27 21:26:16.94 +PotGQRe.net
crates.io が死ぬと詰むな・・・
198:デフォルトの名無しさん
24/04/28 14:02:08.42 e+80DOh2.net
なんなの vendoring とか stable channel とか
意識高そうですね()
199:デフォルトの名無しさん
24/06/08 09:22:59.84 Kcr3cAzI.net
Ruby批判だけど
URLﾘﾝｸ(qiita.com)
Rustにも同じことが言える
200:デフォルトの名無しさん
24/06/08 10:03:29.15 9nPXIyFb.net
>>199
Rustに該当する話が一つもないのにRustを批判？
201:デフォルトの名無しさん
24/06/09 16:29:53.15 IIKkP3Jm.net
信者は信者スレに帰れ
202:デフォルトの名無しさん
24/09/21 15:07:34.01 v+xBeerr.net
おまいらホントRuby好きだな
203:デフォルトの名無しさん
24/09/21 15:35:51.56 oJtK/qJ9.net
遅いのがなあ