C++ vs Rust

**デフォルトの名無しさん** · 2021/04/24(土) 08:04:49.48

競え

**デフォルトの名無しさん** · 2021/04/26(月) 22:53:32.32

>>19
話の流れは大体予想できてただろうなという受け答えだろ。
んでもって実際、発案者自らmoonshot言うとるわ。
少しは内容を読んでくれ、なんで一から十まで説明しなきゃならんのか。

**デフォルトの名無しさん** · 2021/04/26(月) 23:32:00.78

>>20
じゃあレスすんなよカス

**デフォルトの名無しさん** · 2021/04/26(月) 23:47:01.17

だから読めって。。文盲なんか？

**デフォルトの名無しさん** · 2021/04/27(火) 00:14:36.96

>>20
moonshotって言ってるの割り込みコンテキストでallocator呼び出すことをコンパイル時にチェックできるようにしたいという話では
現実的には関数ごとにどのコンテキストで呼び出せるものなのかタグ付けしてるとかなんとか
綺麗じゃないけど、まあ動くわなという解決策

つまみ食いしかしてないから読み違えてるかも知れないけど
これをもってlinuxカーネルにrust取り込むのを否定するような話ではないようにみえた

他にもmoonshotって言ってる箇所ある？

**デフォルトの名無しさん** · 2021/04/27(火) 01:12:51.08

一通り読んだけど他にmoonshotって言ってるとこはなかったような。

**デフォルトの名無しさん** · 2021/04/27(火) 08:00:23.09

>>23
あのね。。書けばそうなるってものじゃなくてそれを実装しなきゃならんのよ。。
コンパイラにそういったコンテクストを判断させるのがめちゃくちゃ難しいっていってるでしょ？
なんでそんなに読み取れないの？

**デフォルトの名無しさん** · 2021/04/27(火) 15:37:12.22

>>25
当面はdoc commentにannotation書いて済ませておくって言ってるやん
何はともあれ大局的にはrustをlinux kernelに取り込む方向へ進んでいくことには間違いない

**デフォルトの名無しさん** · 2021/04/27(火) 16:10:45.63

>>26
だからそのコードじゃpanic捉えきれねーからカーネルに入れるわけねーだろって
言ってんじゃん。。何読んでんだよ。

**デフォルトの名無しさん** · 2021/04/27(火) 18:23:48.67

まあ半年後どうなるかで誰が正しかったかは分かるわな

**デフォルトの名無しさん** · 2021/04/27(火) 20:32:29.92

半年も経たなくてももうわかってるっつーの。。だからちゃんと英語の勉強しましょうね。

**デフォルトの名無しさん** · 2021/04/28(水) 03:52:50.81

C++で、n要素のint型の生配列を確保するには、
int *pBuf = new int [n];
だけど、Rustの
let a:Box<i32> = Box::new<x>;
値が x である 32BIT 整数を Heap に 1 つ確保する、という意味だよね？
Heapに n 要素の i32 型の配列を確保したい場合、
let a:Vec<i32> = vec![0; n];
かな？

**デフォルトの名無しさん** · 2021/04/28(水) 03:55:12.80

>>30
あ、
let a:Box<i32> = Box::new<x>;
ではなく、
let a:Box<i32> = Box::new(x);
let a:Box<i32> = Box<i32>::new(x);
let a = Box::new(x);
let a = Box<i32>::new(x);
かな。
か

**デフォルトの名無しさん** · 2021/04/28(水) 04:01:18.27

>>31
確保した領域の中身を書き換えたい場合は「mut」を付ける必要があり、
値が x である 32BIT 整数を Heap に 1 つ確保するのは：
let mut a:Box<i32> = Box::new(x);
let mut a:Box<i32> = Box<i32>::new(x);
let mut a = Box::new(x);
let mut a = Box<i32>::new(x);
のどれかの書き方で、Heapに n 要素の i32 型の配列を確保するのが、
let mut a:Vec<i32> = vec![0; n];
let mut a = vec![0; n];
のどちらかの書き方かな？

**デフォルトの名無しさん** · 2021/04/28(水) 10:37:51.57

let mut a = Box::new([0,n]);

**デフォルトの名無しさん** · 2021/04/28(水) 12:44:00.99

>>33
なるほど、そんな書き方があったとは。でも正しくは、
let mut a = Box::new([0; n]);
かな？

**デフォルトの名無しさん** · 2021/04/28(水) 15:21:28.78

[0; n]
って、n 要素のi32配列を確保して0で初期化するという意味らしいけど、
nは実行時に決まらないような変数も指定できるの？

**デフォルトの名無しさん** · 2021/04/28(水) 16:30:39.18

>>35
できない

https://stackoverflow.com/questions/41710952/allocate-array-onto-heap-with-size-known-at-runtime

Vec<i32>に相当するのはstd::vector<int>だから、
>>33はstd::unique_ptr<int []>相当のBox<[i32]>型の例を出そうとしたのだろう
そういう値は作れるが、Box::newでは無理

**デフォルトの名無しさん** · 2021/08/31(火) 15:22:27.39

246 デフォルトの名無しさん sage 2021/08/31(火) 14:25:42.76 ID:SlncBcTV
>>244
ポインタは適切に使えばデータ構造やアルゴリズム自体が根本的に変えることが
できるので使わない時と比べて計算オーダー自体が劇的に変化することがあり、
プラシーボではない。
Rustはその点でC/C++に勝てない事がある。

247 デフォルトの名無しさん sage 2021/08/31(火) 14:28:10.16 ID:SlncBcTV
例えば、動的配列であるところのVectorはポインタでアクセスしても余り
効率は良くならないが、LinkedListは構造的にポインタで連結されており、
首尾一貫して添え字アクセスを使わずに必ずポインタでノードを識別する
ようにすれば、Vectorに比べて劇的に効率アップできることがある。
それはRustではほぼ不可能。ベンチマークはこの点が反映されてない。

**デフォルトの名無しさん** · 2021/08/31(火) 16:19:11.51

コード例と性能測定結果くれ

**デフォルトの名無しさん** · 2021/08/31(火) 17:18:36.26

>>38
同じ動作をしてもVectorだとO(N)なのに、LinkedListだとO(1)になるものがある。
これだけでも実験してみなくてもNが大きくなった時に明らかに速度が
違うことはコンピュータ科学では常識。
例えば、コロナの感染者数は、O(exp(aN))になるので、どんだけ頑張っても、
Nが十分大きい時にはO(N^b)が上回ることは出来ない。

**デフォルトの名無しさん** · 2021/08/31(火) 18:26:05.32

まだstable入りはしてないけどlinked_list::{Cursor, CursorMut}っていうのがあるね
そのベンチマークでは使ってる？

**デフォルトの名無しさん** · 2021/08/31(火) 19:03:52.76

LinkedListとはなんぞや？std::list?

**デフォルトの名無しさん** · 2021/08/31(火) 19:52:34.92

>>39
Rust は stable で LinkedList も VecDeque (双方向キュー)もありますよ
https://doc.rust-lang.org/std/collections/index.html
ここにそれらのオーダーが O(1) や O(N) になる話もまとまっています

**デフォルトの名無しさん** · 2021/08/31(火) 21:21:08.46

>>39
参照局所性の問題もあるから計算量の理論通りにはいかない場合もあるけど、ちゃんと性能測定してデータ構造選定した？

**デフォルトの名無しさん** · 2021/08/31(火) 21:26:21.55

あとRustではほぼ不可能の意味が分からない
Rust にはポインタがあるから C や C++ のデータ構造はほぼ実現可能なのでは

**ハノン** ◆QZaw55cn4c · 2021/08/31(火) 22:08:35.31

>>44
では赤黒木をひとつやってみて

**デフォルトの名無しさん** · 2021/08/31(火) 22:27:32.77

>>45
Rc<RefCell<Node>>のパターン
Safe Rustでも実現可能

**デフォルトの名無しさん** · 2021/08/31(火) 23:58:27.88

>>42
ところが、Rustでは借用規則のせいで上手く行かない。
めんどくさいので自分で気づく人だけが理解してくれればいいので、
俺はこれ以上説明しない。
理解できない人は、親切な人が説明してくれるのを待て。

**デフォルトの名無しさん** · 2021/08/31(火) 23:58:51.57

>>44
無理。

**デフォルトの名無しさん** · 2021/09/01(水) 00:55:38.60

>>47
それはあなたが無知なだけだ
Rustはメモリ安全性を保証する
一方でRustの標準ライブラリではunsafeが多数使われているがこれはメモリ安全性を保証できる操作を効率よく実装するためにある
つまり論理的にメモリ安全性を保証できるならばunsafeを用いてもそれをライブラリやモジュールに閉じ込めることができる
もちろん自作でもこれは同様である
新たな型も当然作ることが可能
標準ライブラリで提供されているリンクドリスト型や双方向リスト型はそのようにして作られている
つまり効率をも落とさない

**デフォルトの名無しさん** · 2021/09/01(水) 01:25:17.04

>>49
お前は何も分かってない。
馬鹿は黙ってろ。

**デフォルトの名無しさん** · 2021/09/01(水) 01:27:41.34

>>40にも答えてくれよ
その「問題」とやらはCursorじゃ解決されてないのかい

**デフォルトの名無しさん** · 2021/09/03(金) 08:12:39.26

>>49
ガイジ

**デフォルトの名無しさん** · 2021/09/07(火) 20:33:21.38

結局unsafe多用するとか意味ないジャンw

**デフォルトの名無しさん** · 2021/09/07(火) 23:30:30.79

>>53 裏方のunsafeなコード(≠危険なコード)を安全に利用してプログラムを書けるのがRustだと思う
また､その裏方のunsafeなコードをRustで書く意味はRustから扱いやすいこと､Rustプログラマーが慣れたRustの文法で書けることがあると思う

**デフォルトの名無しさん** · 2021/09/08(水) 01:30:18.74

>>54
お前の理解は浅くて、間違っている。
お前の様な数学の出来ない人には何を言っても無駄。

**デフォルトの名無しさん** · 2021/09/08(水) 01:30:55.64

unsafeを閉じ込め切れるならRustはパーフェクトだが、そうはなってないのだ。

**デフォルトの名無しさん** · 2021/09/08(水) 09:53:24.22

>>55 そうか､まぁ一個人の感想ぐらいに受け取ってくれ

**デフォルトの名無しさん** · 2021/09/09(木) 16:53:30.53

なんだかんだ言ってまだまだC++だな

**デフォルトの名無しさん** · 2021/09/09(木) 17:22:38.75

unsafe を閉じこめられるかどうかはAPI設計力が問われるよな

**デフォルトの名無しさん** · 2021/09/09(木) 18:17:29.61

>>56
Rustはunsafeを局所的に安全に閉じ込めることができます
例えばVec<T>型はその各メソッド実装においてunsafeを用いています
これも『Rustがunsafeを局所的に安全に閉じ込めることができる』具体的な実例です

>>58
C++よりもRustの方が優れています

**デフォルトの名無しさん** · 2021/09/10(金) 08:39:25.32

>>60
前半、数学的には間違い。
お前には数学の才能が無い。

**デフォルトの名無しさん** · 2021/09/10(金) 09:06:15.40

数学関係ないし
お前には数学の才能が無い

**デフォルトの名無しさん** · 2021/09/10(金) 09:26:50.69

数学的に間違いの意味がようわからんが、
unsafeブロック内あるいは関数内でSAFETYが守られるようにしないと安全に閉じ込めることができないって意味？？

**デフォルトの名無しさん** · 2021/09/10(金) 09:28:15.95

Vec<T> が unsafe を使って安全なインターフェースを提供してることへの反論を示してくれ

**デフォルトの名無しさん** · 2021/09/10(金) 11:00:27.70

>>63
そうでなくて、unsafeブロックで閉じ込めようとしても、閉じ込め切れなくて、
O(x)で表される計算時間が、C言語とは同じでは絶対に不可能な場合があるんだ。
Rustのsafeモードでは、コンテナの中のノードに対して書き込み参照と読み込み参照
を持つことが借用規則によって禁じられていることが原因。
C言語ではそれが当たり前に出来るからとても効率の良いプログラムが可能だが
Rustでは、unsafeの外側ではそれが出来ないから不可能だ。
アプリレベルでそれが出来ないから。
これで納得できない人は数学の才能が無い。
俺は数学の天才。

**デフォルトの名無しさん** · 2021/09/10(金) 11:05:19.78

>>65
数学の才能が無い人のためにもう少し詳しく書いてやろう。
・Rustのsafeモードでは、LinkedListの中の複数のノードに対して、
　読み込み参照と書き込み参照を一度自動時には持てない。
　持つと borrow cheker がコンパイル時にエラーを出してしまう。
・C言語ではそれが当たり前に出来る。
・アプリレベルで1つのLinkedListに対して複数の読み込み参照と
　書き込み参照を同時に記録し続けることで、やっと、挿入や削除が
　O(1)になる。index 値で保持すると O(N)になってしまうから、
　vector と同じ速度オーダーしか出ない(つまり、LinkedList本来の性能
　が全く出せない。)
・結果、Rustは、Cより遅いプログラムしか出来ない。その遅さは、データが
　多いとき、C言語に比べて1万倍でも100万倍でも遅くなる。

**デフォルトの名無しさん** · 2021/09/10(金) 11:27:11.50

>>66
コードで書いて

**デフォルトの名無しさん** · 2021/09/10(金) 11:30:01.67

>>67
RustとCの知識と、東大数学が簡単に解けるような数学の才能をすべてもっている人
に聴いてみろ。

**デフォルトの名無しさん** · 2021/09/10(金) 11:36:42.07

>>68
本当は次のような知識も必要：
・リンクドリストの構造。
・リンクドリストの挿入、削除などの計算オーダーO(x)。
・計算オーダーの記号O(x)の意味。ビッグオー。ランダウの記号。
　東大、京大の学部レベルの解析学(微分積分学)の本を見よ。
・index 値 = 基本は配列の添え字。0から割り振られた連番。
　リンクドリストでは本来使わないが、Rustではノードの場所を覚えておくために
　使わざると得ない。その場合、リンクドリストの先頭のノードを 0 番とし、
　次のノードを 1, その次のノードを 2 のように表す。
　しかしそうすると、リンクドリスとの M 番目の場所の参照を取得するのに
　O(M)の時間が掛かってしまい、リンクドリストの効率の良さが台無しになってしまう。
・このことから、リンクドリストが遅いという誤解を生む状況になってしまっている。

**デフォルトの名無しさん** · 2021/09/10(金) 11:38:10.81

>>68
東大数学って何？

**デフォルトの名無しさん** · 2021/09/10(金) 11:39:59.60

>>70
高校生が灯台に入学するときに受ける東大の数学の試験のことだよ。
それが簡単に解けるくらいのやつに聞いてみろって事だ。
しかし、受験テクニックやパターン学習によって解ける様になったやつはダメだ。

**デフォルトの名無しさん** · 2021/09/10(金) 11:49:52.37

>>69
O(1) で i 番目の要素にアクセスできる safe な LinkedList 実装はある
https://docs.rs/chainlink/0.1.0/chainlink/struct.LinkedList.html

**デフォルトの名無しさん** · 2021/09/10(金) 11:52:48.63

>>72
i 番目の要素というと不正確か
ポインタの代わりに Arena 内での index を使うことで LinkedList のノードを O(1) で参照することができる

**デフォルトの名無しさん** · 2021/09/10(金) 11:53:08.66

https://play.rust-lang.org/?version=nightly&;mode=debug&edition=2018&gist=bc6e823f6a44e442aabd4d4882d3eb5a

Repeated 1 time(s), duration = 2.531µs
Repeated 10 time(s), duration = 4.661µs
Repeated 100 time(s), duration = 29.449µs
Repeated 1000 time(s), duration = 256.555µs
Repeated 10000 time(s), duration = 1.800129ms
Repeated 20000 time(s), duration = 3.273489ms
Repeated 50000 time(s), duration = 8.345219ms
Repeated 100000 time(s), duration = 16.454731ms
Repeated 200000 time(s), duration = 32.911471ms
Repeated 500000 time(s), duration = 83.993118ms
Repeated 1000000 time(s), duration = 166.193956ms

結構実行毎にゆれる感じはあるけど、おおむねO(1)じゃないですかね

**デフォルトの名無しさん** · 2021/09/10(金) 12:09:20.46

>>74
アホですか？

>>73
Arenaを使った時点で裸のリンクリストじゃ無いし、時間は、O(x)が同じでも
オーバーヘッドが発生する。また、無駄なメモリー領域も食う。

**デフォルトの名無しさん** · 2021/09/10(金) 12:12:17.45

>>68
呼んだ？

**デフォルトの名無しさん** · 2021/09/10(金) 12:14:53.57

>>71
えっ？
高校数学？
レベル低くないか？

**デフォルトの名無しさん** · 2021/09/10(金) 12:18:15.36

少なくとも>>65が書いてることは数学的でも何でもない

**デフォルトの名無しさん** · 2021/09/10(金) 12:18:20.87

>>75
はい、私はアホで数学の才能が無いので数学の天才様の問題意識が分かりません
VecならO(n)になる先頭への挿入がO(1)でできることを示したつもりでしたが見当違いでしたでしょうか

**デフォルトの名無しさん** · 2021/09/10(金) 12:27:50.85

>>79
push_front()使ってるから先頭へ挿入してるだけじゃないか。
Cのリンクリストは、どんな非負整数 M に対して、M番目に挿入しても
MにもNにも依存しない定数時間で挿入できる。
それがRustに欠けている。

**デフォルトの名無しさん** · 2021/09/10(金) 12:28:54.60

>>75
そのオーバーヘッドは実用上問題になりますか？
例えばmallocの実装もarenaを使っていますが問題はないのですか？
そもそも計算量の議論をしていたのはあなたなのになぜ論点をずらすのですか？

**デフォルトの名無しさん** · 2021/09/10(金) 12:30:48.00

>>80
挿入自体が定数時間でも
M番目を探すのが定数じゃない

**デフォルトの名無しさん** · 2021/09/10(金) 12:41:50.91

>>82
「M番目」のMをそのまま「通し番号」で表しているならその通りだ、たとえC
であっても。
しかし、Cでは、通し番号ではなくポインタで表現することで1クロックで
辿り付けるので O(1)。

**デフォルトの名無しさん** · 2021/09/10(金) 12:42:38.21

>>65が何言ってるのか1行たりとも理解できなくて日本語の見た目した何かにしか見えないんだけど、
なんで話が進んでるの・・・

**デフォルトの名無しさん** · 2021/09/10(金) 13:08:34.28

>>83
自分でM番目に挿入って書いてるわけだが

**デフォルトの名無しさん** · 2021/09/10(金) 13:34:07.88

>>85
「M番目に挿入」するが、それをMという数値で識別するとは書いてない。
数学とはそういうものだ。
ポインタ p で表現する場合でも、p が M 番目のノードを指していることがある。
その場合は、M番目に挿入と表現される。
そう表現しないと、O(x)記号で表現しにくいからだ。

**デフォルトの名無しさん** · 2021/09/10(金) 13:35:00.70

>>83
それと同じことをRustではポインタの代わりにCursorMutを使って実現できる、という認識ですが
CursorMutには何が欠けていますか？

**デフォルトの名無しさん** · 2021/09/10(金) 13:35:29.31

数学での言葉の表現と日常の言葉の表現は異なる。
「M番目に挿入」することと、そのノードを、index = M - 1 で表すこととは
別の話だ。

**デフォルトの名無しさん** · 2021/09/10(金) 13:47:35.86

>>87
同じノードを複数のCursor/CursorMutが参照している場合、1つの参照経由
でノードを削除した場合、別の参照がダングリング参照になるのを0コストで
防ぐ方法は無いはずだ。
静的解析が不可能で、時間や記憶域に何らかのオーバヘッドが必要となるはず。

**デフォルトの名無しさん** · 2021/09/10(金) 14:16:45.03

さらに、1つの LinkedListに対して、同時に2個以上の CursorMut を作ることは
出来ないはず。

**デフォルトの名無しさん** · 2021/09/10(金) 14:18:55.00

Cでリンクドリストの途中を直接ポインタで持っていると速いが
その途中が削除された場合にそのポインタは危険なポインタとなる
つまりCで記述しても何らかのコストをかけなければ安全に出来ない
つまりこの問題はどの言語であろうがコストゼロにすることは不可能

**デフォルトの名無しさん** · 2021/09/10(金) 15:27:02.65

>>91
いや、数学が得意な人は頭がいいので、それでも至って安全なプログラムが書けるし、
今ままでも書いてきた。
Rustは数学の得意な人間には遥かに及ばない。

**デフォルトの名無しさん** · 2021/09/10(金) 15:44:47.65

すげぇバカ

**デフォルトの名無しさん** · 2021/09/10(金) 15:45:34.73

よくわからないけどこんなスレよりqiitaとかzennとかで記事書いたほうがいいと思う

**デフォルトの名無しさん** · 2021/09/10(金) 17:06:16.82

>>86
屁理屈

**デフォルトの名無しさん** · 2021/09/10(金) 17:11:54.58

どんな非負整数Mに対して
と自分で書いている
当然与える情報はMである

各Mに対応するポインタを保持するなら
挿入時にそのテーブルを更新しなきゃならないから
O(1)では出来ない

**デフォルトの名無しさん** · 2021/09/10(金) 17:38:39.28

>>96
Mを与える情報とは書いてない。
Mというものを使わないと、LinkedListとVectorで共通した議論が出来なく
なるから書いてるだけ。数学では良く使う論法。
つまり、Mは、議論の中で場所を特定するために用いているだけで、
プログラム中で用いているとは言ってない。

**デフォルトの名無しさん** · 2021/09/10(金) 17:41:20.99

例えば、コンテナに100個のノードが入っていたとする。
コンテナは、LinkedListやVectorなどどんなアルゴリズムを使っているかは何でも良い。
で、「5番目の場所にノードを追加する」という言葉は、LinkedListにも使えるが、
その場合、プログラム中では5という数値で識別せず使わず、ポインタで識別する
のが C言語での常識。
でも、「5番目の場所に追加する」という言葉は使ってよい事になっている。

**デフォルトの名無しさん** · 2021/09/10(金) 17:43:19.62

>>96
その人は数学が得意と言いながらそこすら理解できていない人だからね
Cでもプログラミングしたことあるならすぐわかることだからプログラミング経験も乏しいと推測される
つまりRustを叩きたいだけの人が暴れているだけの構図

**デフォルトの名無しさん** · 2021/09/10(金) 17:48:47.41

>>99
理解してる。
お前らが、M番目のノードを数値Mでプログラムでも辿ると勘違いしている
抽象化が理解できない馬鹿だからそう思ってるだけ。
俺は抽象化が得意だから、M番目のノードをポインタで識別すると
考える。お前らは、Mとpを脳内で橋渡しできないだけ。

**デフォルトの名無しさん** · 2021/09/10(金) 17:49:37.61

数学的才能の無い人とは話が合わない。
知能に差が大きすぎる人達とは話が合わない。

**デフォルトの名無しさん** · 2021/09/10(金) 17:58:29.87

もっと知能レベルが合った人が集う場所にいきな

**デフォルトの名無しさん** · 2021/09/10(金) 18:15:44.49

>>100
君は数学が不得意だな
入力Mに対してM番目を得る関数のコスト(リソースコストなど含む)を考えればいいだけなのにそれができない
抽象的に考えるのが苦手なら具体的な関数のプログラムを考えてもよい
Rustを叩きたいだけだとしてもC言語のプログラミングくらいはできるんだろ？
君の主張が間違っていて実現不可能なことがすぐわかる
そして示せなければ君の完全敗北確定だ

**デフォルトの名無しさん** · 2021/09/10(金) 18:22:19.32

>>98
完全に屁理屈
それならわざわざ「どんな非負整数Mに対しても」なんて言う必要は全く無い
任意のノード、任意の箇所
ならまだそういう可能性もある

たまたまMに対応するポインタがキャッシュされてた場合の計算量を言っても何の意味も無い

ちなみに数学的能力はお前よりあると思うよ
実績で勝負するなら付き合う

**デフォルトの名無しさん** · 2021/09/10(金) 18:33:25.73

>>65
> 俺は数学の天才。

これみて釣りと判断してるけどマジに受け取ってる人もいるのかな？
議論を続けるなら数学うんぬんの要素を抜きつつアクセス効率だけ語ってほすい

**デフォルトの名無しさん** · 2021/09/10(金) 20:54:06.22

まあここ隔離スレなんで

**デフォルトの名無しさん** · 2021/09/10(金) 22:29:30.98

自分は数学できないからできる人の相場感覚は分からないが、数学の天才って◯◯予想を証明したとか、定理に自分の名前が付いているとか、そういうレベルの人のことじゃない？　東大数学程度で数学の天才を名乗られても……。

**デフォルトの名無しさん** · 2021/09/10(金) 23:03:29.47

> 高校生が灯台に入学するときに受ける東大の数学の試験のことだよ。

高校数学でここまでイキれるのはもはや才能だと思うわ
数学の天才っていうのは数学の研究してて教科書書いてるような
著名な人をまわりの人が「他称」するときの話で
高校数学の成績で「自称」しちゃうってのは別の才能ｗ

**デフォルトの名無しさん** · 2021/09/10(金) 23:04:20.56

東大でやる数学じゃなくて入試でしょ？
つまり高校レベル
こんなのを東大の数学と言うな

**デフォルトの名無しさん** · 2021/09/11(土) 01:22:42.58

知ってる一番難しい数学がそれだったんでしょ
つっこんであげないのが優しさでは

**デフォルトの名無しさん** · 2021/09/11(土) 01:40:01.24

>>80
C言語でも他の言語でもそのようなことは実現不可能です
いくらRustを叩きたいとはいえ主張が滅茶苦茶になっていますよ

**デフォルトの名無しさん** · 2021/09/11(土) 10:36:57.99

馬鹿ばっか。

**デフォルトの名無しさん** · 2021/09/11(土) 11:20:17.45

実際連結リストのノードに対する参照を保持しておくってどういうユースケースで現れるんだろうか

**デフォルトの名無しさん** · 2021/09/11(土) 11:40:09.41

掲示板で算数自慢するときに使う

**デフォルトの名無しさん** · 2021/09/11(土) 11:42:49.15

>>113
例:

1. テキストエディタで、10万行のファイルを読み込み、その先頭に
1000行のテキストを挿入するときの速度向上。

2. 言語を自作する時、マクロ展開の時のトークン列へのトークンの挿入

**デフォルトの名無しさん** · 2021/09/11(土) 16:43:18.56

>>115
それはどちらの使用例なのかハッキリしてほしいです。
配列にN番目への参照を格納する例として挙げているのか、
そうではなくリンクリストを用いる例として挙げているのか、
どちらですか？

**デフォルトの名無しさん** · 2021/09/11(土) 23:33:36.29

>>112

**デフォルトの名無しさん** · 2021/09/12(日) 00:21:25.00

相手をバカと貶めることで何もしなくても自分わ相対的に高めることができるという高等な議論テクだ
さすが高学歴

**デフォルトの名無しさん** · 2021/09/12(日) 02:54:54.78

>>115
1.ってバッファを1個のLinkedListとして持っておいて、カーソルの位置をノードへの&mutで持っておきたいって発想だよね
それよか2個のLinkedListに「カーソル以前の内容」「カーソル以降の内容」を最初から分けて持っておいて、
必要に応じて前者の末尾または後者の先頭を操作するという風にすれば、常に&mut LinkedListつかまれることもなくて都合良いのでは？

workaroundでしかないという批判は認めよう