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

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

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

っていう雑談スレ。

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

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

**デフォルトの名無しさん** · 2023/07/18(火) 17:12:16.37

>>681
アメリカ人は学者ですらちゃんと理解できて無い。

**デフォルトの名無しさん** · 2023/07/18(火) 18:33:02.09

>>680
多分速くなってると思う。
気になるなら実際計測してみれば分かるのでは？

**デフォルトの名無しさん** · 2023/07/19(水) 00:05:33.03

>>676
StroustrupはC++を作った人で少し前にその人の書いた記事が話題になってた
要約すると↓みたいな流れだったと思う

記事（英語）の内容
ファームウェアみたいにメモリアクセスが高価な環境では多少非効率でも
vectorを使った方がキャッシュ等の関係でパフォーマンスがよくなる
実測データでも数万件程度（うろ覚え）ではvectorが優位だった

記事に対するこのスレでの批判
何にでもvectorを使うように推奨するのはアルゴリズムを理解できてないからだ

**デフォルトの名無しさん** · 2023/07/19(水) 00:22:21.27

算数100点大先生がcache localityを理解できないという話をまたやるのか

**デフォルトの名無しさん** · 2023/07/19(水) 00:38:56.49

>>680
どういうコードでhoge.clone()をお勧めされるんですか？

**デフォルトの名無しさん** · 2023/07/19(水) 01:09:55.37

ハッシュテーブルが遅くなる攻撃を思いつくような奴は確率を信じてない
というかこのラインをこえたら信じないというローカルルールがある

そもそもローカルがグローバルより劣っているみたいな考えは数学で扱わないので
そんなものを信じる義理はない

**デフォルトの名無しさん** · 2023/07/19(水) 01:44:50.95

>>685
理解できて無いのはこのスレの馬鹿どもとStroustrup氏の法だ。

**デフォルトの名無しさん** · 2023/07/19(水) 04:04:32.47

文脈が全くわからないのだがStroustrupの記事ってどれ？

**デフォルトの名無しさん** · 2023/07/19(水) 08:41:42.67

>>684
ほとんどの用途でベクターが有利というその主張で合っている
実際の各ユースケースで計算量の償却解析してみればわかる

**デフォルトの名無しさん** · 2023/07/19(水) 09:52:37.73

ハゲは>>684記事で実測を示したんでしょ?

**デフォルトの名無しさん** · 2023/07/19(水) 11:34:57.60

>>676
C/C++ スレでハゲと描かれていたらそいつのことだ

**デフォルトの名無しさん** · 2023/07/19(水) 11:37:33.24

>>684
>ファームウェアみたいにメモリアクセスが高価な環境では

それこそ「何にでも」なんて言ってない限定してる

**デフォルトの名無しさん** · 2023/07/19(水) 12:59:18.29

>>690
「ほとんどの」というのが嘘だ。

**デフォルトの名無しさん** · 2023/07/19(水) 13:00:42.03

この板は馬鹿ばっかりで、それで納得してしまうのかも
知れんが、海外のサイトだと、ちゃんと、リンクリストが
有利な場合が沢山あげられている。

**デフォルトの名無しさん** · 2023/07/19(水) 13:04:59.13

>>695
ハゲは>>684の記事で実測を示したんでしょ?

**デフォルトの名無しさん** · 2023/07/19(水) 13:07:03.89

>>696
そんなもん、実験条件と解釈がめちゃくちゃなので
証拠にならない。
理論や理屈を理解していなければ実験しても無駄な例。

**デフォルトの名無しさん** · 2023/07/19(水) 13:15:37.13

>>697
実験条件と解釈を読んだのかな?
内容をおせーて

**デフォルトの名無しさん** · 2023/07/19(水) 14:05:33.79

価値観を押し付け合うのは実は平和的だよな
相手の価値観に合わせる柔軟なタイプが最も危険で
相手が戦争嫌いではないと知ったら嫌いになるまで戦争をやめない

**デフォルトの名無しさん** · 2023/07/19(水) 14:24:01.78

Stroustrup師って、一人でさらさらって書いて出しちゃう御仁なのかな
こーゆうツッコミが入るのはわかるだろうにねやっぱ原著見ないとか

**デフォルトの名無しさん** · 2023/07/19(水) 14:45:35.26

>>699
なるほど折伏ですね判ります

**デフォルトの名無しさん** · 2023/07/19(水) 15:39:26.34

https://www.tiobe.com/tiobe-index/
ruby抜けそう
Goくらいは抜いてほしいものだ

**デフォルトの名無しさん** · 2023/07/19(水) 16:11:16.93

>>702
惜しい
swiftが挟まってなければRRRだったのに

**デフォルトの名無しさん** · 2023/07/19(水) 16:21:05.94

やっぱりこうなるね
https://mevius.5ch.net/test/read.cgi/tech/1683600652/509-510

**デフォルトの名無しさん** · 2023/07/19(水) 20:59:38.09

興味ある人のためにStroustrup氏の記事のリンク（Rust本スレのPart18で議論されてた）
https://www.stroustrup.com/Software-for-infrastructure.pdf

URLからも分かるけど記事のタイトルは「Software Development of Infrastracture」で内容は少しハード寄り

**デフォルトの名無しさん** · 2023/07/19(水) 21:18:14.58

>>702
スゲーCOBOLに勝ててるんじゃん

**デフォルトの名無しさん** · 2023/07/19(水) 21:21:56.85

>>705
ハゲの言うinfrastructure softwareはハードよりかどうかは関係ない

**デフォルトの名無しさん** · 2023/07/19(水) 22:58:56.01

俺はハゲに同意かな
LinkedListはもはや古いデータ構造だと思う
現代のアーキテクチャにおいてはキャッシュメモリに乗せることがめちゃくちゃ重要なんだよ
LinkedListは挿入や削除を繰り返すとメモリアドレスがめちゃくちゃになりがちだし
ポインタを辿るという操作もページアウトなどを引き起こす
普通にポインタ配列のvectorが良い
もちろんreallocのコストが無視できない環境だと有効であるのは間違いない

**デフォルトの名無しさん** · 2023/07/19(水) 23:21:25.02

キャッシュメモリがゴミカスレベルのサイズ
もしくは存在しないレベル
メモリアロケーションのコストが高い
追加削除が頻繁に起きまくるようなソフトウェア

これらの場合はLinkedListで良いかも

**デフォルトの名無しさん** · 2023/07/19(水) 23:33:20.68

コンパイラとかもろもろ最適化して計測するとndarrayクレートのArrayのイテレータよりも自分の作った多次元構造体のイテレータの方がまだ10倍くらい遅い。nextメソッドで呼び出される自作の外部関数の呼び出しがコストになってるっぽい。

**デフォルトの名無しさん** · 2023/07/20(木) 02:38:53.91

馬鹿な人ほど、LinkedListを嫌う傾向がある。

**デフォルトの名無しさん** · 2023/07/20(木) 02:50:37.46

ほとんどのケースでLinkedListが使われないのは遅いしメモリも余分に食うためだ
次の位置のアドレスを得るためにメモリアクセスが必要となり遅い
Vectorなら次の位置のアドレスはインクリメントするだけだ
前の位置も辿りたいならLinkedListだと双方向リンクでさらにメモリ使用量も増える

**デフォルトの名無しさん** · 2023/07/20(木) 03:04:02.05

>>712
マシン語レベルで見ると、インクリメントと
次のアドレスを得るのはどちらも mov 命令1つで、
どちらも1クロックで時間に差は無い。

**デフォルトの名無しさん** · 2023/07/20(木) 03:09:08.59

>>713
>次のアドレスを得るのはどちらも mov 命令1つで、
>どちらも1クロックで時間に差は無い。
間違えた。
正しくは、
「インクリメントは、add、次のアドレスを得るのは movだが、
　どちらも1クロックで必要時間に差は無い。」

**デフォルトの名無しさん** · 2023/07/20(木) 03:15:52.51

いやだからメモリアクセスが支配的になるという話なのだが？
キャッシュメモリに乗ってないと致命的な速度低下となる

**デフォルトの名無しさん** · 2023/07/20(木) 03:18:02.86

>>713
メモリアクセスに時間がかかることすら知らないならコンピューターの入門レベルからやり直せ

**デフォルトの名無しさん** · 2023/07/20(木) 03:22:57.78

>>716
キャッシュメモリに乗っている場合の話だ。
乗っていない場合には、もちろんペナルティーが発生する。
ただ、ArrayListは、途中への挿入や削除がO(N)かかるが、
LinkedListは、O(1)だから、Nが10万の時には10万倍
の時間差となる。
一方、キャッシュのペナルティーは15(ns)くらいだから、
現在のCPUでは、45クロック位。
これだと、最悪のケースでも9倍程度だから、圧倒的に
LinkedListの方が時間的に安定。

**デフォルトの名無しさん** · 2023/07/20(木) 03:25:15.25

はっきりいって、ここの数学的才能の無い連中にも
俺は説得できる説明が出来る自信は有るが、敢えて
やってない。なぜなら、それを論文にしてステップアップ
に利用すると言うずるがしこい連中を多く見てきた
からだ。

**デフォルトの名無しさん** · 2023/07/20(木) 03:29:46.06

この板の人は、数学的才能の無い人ばっかなので
異常に馬鹿丁寧に説明しないと理解できない。
今回の説明でも馬鹿丁寧だが、経験上、この程度の
丁寧さでは理解できないだろう。
もっとアセンブリコードまで徹底して書いて、
キャッシュとメインメモリの関係の図を書いて、
大量の比較コードを提示して、やっと僅かに理解できる人が
一人現れる程度だ。
それなのに、自分は賢いと思い込んでいる。
また、文書が読めない人が多い。
音声で言わないと理解できないらしい。
だから、掲示板では無理。

**デフォルトの名無しさん** · 2023/07/20(木) 05:22:45.38

はよ賢い人たちに説明しにいって、出禁にされてこい

**デフォルトの名無しさん** · 2023/07/20(木) 06:31:51.97

>>717
LinkedListがO(1)なのは先頭に挿入する場合だけだぞw
サーチが必要な場合は当然O(n)
数学だけじゃなくCSも正しく理解できていないようだ

**デフォルトの名無しさん** · 2023/07/20(木) 06:47:19.72

LinkedListすらまともに作れない言語ってどうなんだろうなｗ

**デフォルトの名無しさん** · 2023/07/20(木) 07:29:26.02

>>717
キャッシュメモリに載っていてもいなくてもメモリアクセスのペナルティが発生する
キャッシュに載っていないメインメモリならレジスタの数百倍
L3キャッシュに載っていればレジスタの数十倍
L2キャッシュに載っていればレジスタの十数倍
L1キャッシュに載っていてもレジスタの数倍かかる
メモリアクセスはこのようにとても遅い

したがってレジスタのインクリメントだけでアドレスを得られるVectorの方が有利になる
さらにVectorなら次の要素はほぼ必ずL1キャッシュに載っている恩恵も加わる
ほとんどのケースでVectorが速いのはこれらメモリアクセスの観点も効いている

**デフォルトの名無しさん** · 2023/07/20(木) 08:26:57.52

ランダムアクセスになる場合なんかはlinkedlistなんかメチャクチャ遅くなる
例えばバッファサイズが8のフーリエ変換だと
1-5,2-6,3-7,4-8,
1-3,2-4,5-7-6-8,
1-2,3-4,5-6,7-8
とアクセスする
頭から読んでいくとものすごいコストがかかる

**デフォルトの名無しさん** · 2023/07/20(木) 08:40:23.30

そのレベルで速度気にするんならCやC＋＋の方がよくね？

**デフォルトの名無しさん** · 2023/07/20(木) 09:05:41.95

全員がプログラミング言語に全く依存しない話をしてるところで唐突だな

**デフォルトの名無しさん** · 2023/07/20(木) 09:35:16.93

>>719
速度に影響を与え得る全ての要因を把握してれば理論的に予測できる
しかし多くの人は全把握していないことが実測の反例1つで明らかとなる
ハゲは>>684の記事で反例を示したってことなんでしょ? （俺は読んでないよ）
測定条件も恐らく1つではなくグラフの横軸に振って速度に与える影響を
示したんじゃないのかな?

**デフォルトの名無しさん** · 2023/07/20(木) 11:05:22.25

ハゲの書いてることは00年代中盤にはCSでは一般常識化してた内容
実測すれば答えすぐ出るから

**デフォルトの名無しさん** · 2023/07/20(木) 12:39:51.73

>>720
出禁にされた結果がこのスレや

**デフォルトの名無しさん** · 2023/07/20(木) 12:47:25.92

cargo は便利だけど crates.io の複数のモジュール同時使用で衝突するケースがあるよな
それぞれ単独で使うと問題起きないのに組み合わせて使うと死ねる
それぞれの開発者はたぶんお互いを認知してないかあるいは
どうなろうと知ったこっちゃないんだろ

**デフォルトの名無しさん** · 2023/07/20(木) 12:56:38.69

>>713-714
そういう問題じゃなくて
リンク先がキャッシュに乗ってなかったら大変コストが増える
って話だろ

**デフォルトの名無しさん** · 2023/07/20(木) 13:00:04.58

>>717
だからそれぞれの利点欠点を把握した上で使い分けようという話をしてるんだよな
ハゲは(ほぼ)全部Vectorとか極端だから馬鹿だと言われてるって話だよな

**デフォルトの名無しさん** · 2023/07/20(木) 13:03:06.20

>>721
明らかに君が可笑しい

**デフォルトの名無しさん** · 2023/07/20(木) 14:30:33.52

バランスを考えるのをやめろ
両極端の宗派はそのままにしておけ
統一するな

**デフォルトの名無しさん** · 2023/07/20(木) 15:21:54.49

>>733
サーチが必要な場合、LinkedListはO(1)ではなくO(n)
どういう勘違いをしたのかも含めて教えてもらえるとありがたい

**デフォルトの名無しさん** · 2023/07/20(木) 15:33:00.56

横からだけど
>>735

＞　>>717
＞　LinkedListがO(1)なのは先頭に挿入する場合だけだぞw

これじゃね？明らかに間違ってる

**デフォルトの名無しさん** · 2023/07/20(木) 15:43:18.38

LinkedListが一直線のリンクで実現してるのか、二分木とか赤黒木とかまで含んでるのかで話が変わる

**デフォルトの名無しさん** · 2023/07/20(木) 15:51:48.08

>>736
うーん、じゃあもういいやw

**デフォルトの名無しさん** · 2023/07/20(木) 16:09:51.27

同じO(N)でも性能は全く違うって話なのは理解してる？

**デフォルトの名無しさん** · 2023/07/20(木) 16:12:38.55

このスレではLinkedListは常にO(1)ってことにしようw
よし使いまくるぞ！w

**デフォルトの名無しさん** · 2023/07/20(木) 17:35:21.34

>>740
本当はしまったと思ってるけど開き直って違うことをかいてるんでしょう
みじめですね

**デフォルトの名無しさん** · 2023/07/20(木) 18:03:33.53

なおRust標準ライブラリのLinkedListの扱い
（https://doc.rust-lang.org/std/collections/index.html）

Use a `LinkedList` when:
* You want a `Vec` or `VecDeque` of unknown size, and can't tolerate amortization.
* You want to efficiently split and append lists.
* You are *absolutely* certain you *really*, *truly*, want a doubly linked list.

**デフォルトの名無しさん** · 2023/07/20(木) 18:32:16.87

>>741
ほんと惨めやね
>>719のような人間は自分だと自ら証明してしまった訳だ
せめてid変えとけよって思うわw

**デフォルトの名無しさん** · 2023/07/20(木) 18:57:14.98

1. ソートされた状態でデータを管理したい
2. 走査は激遅でいいけどキーに対応する値1件の取得/挿入/削除は高速に行いたい
3. 取得/挿入/削除時に先頭末尾以外位置はリストにアクセスしなくても分かる
これらを満たしてる場合にのみLinkedListが候補の1つに上がる

**デフォルトの名無しさん** · 2023/07/20(木) 20:29:35.29

数学の人とオープンソースの人はひょっとして同じ人？

**デフォルトの名無しさん** · 2023/07/20(木) 21:52:17.16

ひょっとしなくても同じやつだろ

**デフォルトの名無しさん** · 2023/07/20(木) 21:57:32.90

>>744
>> 3. 取得/挿入/削除時に先頭末尾以外位置はリストにアクセスしなくても分かる

それはLinkedList全ての要素へのポインタ一覧を持っていないと無理だな
それをベクタで持つならその削除問題が発生してLinkedList利用の唯一の利点が消える
別のLinkedListで持つなら再び激遅な走査問題が起きる

**デフォルトの名無しさん** · 2023/07/20(木) 23:49:45.08

>>747
一般的にはLinkedListとHashMapを組み合わせる
一部の言語に実装されてるLinkedHashMap/OrderedDictionaryや
基本的なLRUキャッシュの実装でその組み合わせが使われてる

**デフォルトの名無しさん** · 2023/07/21(金) 00:53:33.35

一般的なLinkedListはともかくとしてRustに標準に実装されてる
use std::collections::LinkedList;
は前後のノードへのポインタで実現してるらしい
赤黒木がどうこうとかいうものではとてもなさそう
ランダムアクセスなんか劇遅やろ
そもそもLinkedListのくせに
「リストの中間地点に要素を追加したり、削除する操作が効率的にできるのも連結リストの特徴ですが、Rust1.26の時点では、そのような操作のためのメソッドが用意されていません」
とはどういうつもりなんやと
https://qiita.com/garkimasera/items/a6df4d1cd99bc5010a5e

**デフォルトの名無しさん** · 2023/07/21(金) 02:25:21.34

LinkedList単体で使おうとするとベクタ系での実装に対するアドバンテージがほとんどのケースで存在しない
またソートを維持したいならLinkedListよりもBTreeMapが有利
他にもそれぞれ目的別に有利なデータ構造がある

>>748
Rustにも毎日10万ダウンロードされているLinkedHashMapがある
https://crates.io/crates/linked-hash-map

**デフォルトの名無しさん** · 2023/07/21(金) 02:46:28.99

アルゴリズムやデータ構造の性能を評価する上で、
よく使われてきた計算量という指標の実用性も微妙になっちゃったな

**デフォルトの名無しさん** · 2023/07/21(金) 03:01:04.83

>>724
そのように番号で場所にアクセスするような
事に使用するにはArrayが有利。
単純なLinkedListは、番号でアクセスする用途には向いていない。
LinkedListを効率よく利用するには番号ではなくアドレスでアクセスする。
アドレスとは、ノードに付けられた唯一無二の名前。
この板の人達はその概念が全く理解できず、
いつまでも番号によるアクセスから頭が切り替えられないでいる。

**デフォルトの名無しさん** · 2023/07/21(金) 03:38:53.42

ndarrayクレートはイテレータの高速化のためにZip構造体を使ってるって聞いたんだけど、Zip構造体ってどんなことやってんの？誰か教えて。

**デフォルトの名無しさん** · 2023/07/21(金) 03:40:00.01

>>752
それをしようとするとLinkedListの各要素のアドレスを持つもう一つのデータ構造が必要となる
さらにそのもう一つのデータ構造に対しても挿入や削除の処理が必要となる

**デフォルトの名無しさん** · 2023/07/21(金) 03:49:23.59

>>753
今一瞬しか見ていないがndarray::Zipは単なるタプル化

**デフォルトの名無しさん** · 2023/07/21(金) 08:45:47.57

これがRustの実力だ

FirefoxがついにChromeよりも高速なブラウザに
https://gigazine.net/news/20230720-firefox-surpassed-chrome-speedometer/

**デフォルトの名無しさん** · 2023/07/21(金) 09:30:46.83

そろそろ、(Rust世代の知見を組み入れた新世代の)C++でフルスクラッチが試みられてもいい頃合だな

**デフォルトの名無しさん** · 2023/07/21(金) 09:59:32.61

>>756
記事にはRustのRの字もないのだが本当に早くなった要因なの?

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

まぁそんな結論出せるわけない
その結論出すにはFireFoxと同じアルゴリズムで別の言語で組み直して実測するしかない
そんな事誰もしない
しかしRustは他の言語に比べて抽象度はやや高め(C++等とでは)だから速度面とかでは不利になるはず
しかしそのディスアドバンテージが跳ね返されるくらいの性能がある事は実証されたとしていいやろ

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

>>751
指標やハッシュ値や非可逆圧縮や浮動小数点数はある意味現実の劣化コピーだから
現実とお花畑の対立を煽れば煽るほど劣化コピーという身分が固定されてしまう

**デフォルトの名無しさん** · 2023/07/21(金) 11:44:03.63

>>751
絶対的性能を評価するためのものではなくて
要素数の変化に対する性能変化の次数(order of growth)を分かりやすく把握するためのもの
“計算量”という誤った訳語から受ける印象に引きずられてはいけない

**デフォルトの名無しさん** · 2023/07/21(金) 11:51:22.56

トータルの消費時間を決定する要因は複数なんだから
律速段階も見極めずに最適化しても意味はない

**デフォルトの名無しさん** · 2023/07/21(金) 14:00:29.86

>>759
抽象度が高いことによる速度面の不利はコンパイル時間の方で吸収してると思う

**デフォルトの名無しさん** · 2023/07/21(金) 14:39:47.78

FireFoxは糞ブラ
↓
Rustは糞言語
↓
C/C++勝利

**デフォルトの名無しさん** · 2023/07/21(金) 15:20:14.46

>>763
ｗ

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

>>754
それが必要ない場合もある。
頭の良し悪しが問われる。

**デフォルトの名無しさん** · 2023/07/21(金) 19:13:00.15

フィールズ賞を受賞してる日本人で広中さんって人がいるよな
広中さんは「自分は鈍才だが、森君は天才」と言ってるそうな（wikipedia調べ）
このスレで数学の才能がどうのと言ってる人はこれもう
ひょっとしたら森さんなのかもしれんな
森さんって人も、フィールズ賞受賞してる数学の天才

このスレすげーな

**デフォルトの名無しさん** · 2023/07/21(金) 19:42:37.78

日本は30年以上フィールズ賞出てない
韓国は数年前出てる
しかもヲタ属性の好青年

**デフォルトの名無しさん** · 2023/07/21(金) 19:48:10.45

広中さんほどの人でも鈍才ってことなんだから
自分で数学の才能をアピってくるやつって
なんか凄い賞とか受賞してたりするんやろな
そうやって世界に認められてるんやろな

**デフォルトの名無しさん** · 2023/07/21(金) 20:26:35.88

そんなことよりLinkedListとO記法の勉強しろよw

**デフォルトの名無しさん** · 2023/07/21(金) 20:45:01.52

フィールズ賞で思い出したけどモッチーはどうなった?
宇宙際タヒミューラー理論（調べずに記憶をもとに書いてるw）
はどうなった?

**デフォルトの名無しさん** · 2023/07/21(金) 20:50:46.81

作品に罪はないと三回唱えれば
受賞が目標だった人もいつの間にか無罪が目標になってる

**デフォルトの名無しさん** · 2023/07/21(金) 21:00:24.54

>>771
タイヒミュラーな
フィールズ賞受賞で世界で3本の指に入る天才のショルツからの反論がなくなったのでもっちーの勝ち

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

世の中には凄い天才がいるもんですねえ

**デフォルトの名無しさん** · 2023/07/21(金) 21:08:55.93

>>773
そうそうタイヒミュラー
そうなんだモッチー勝ったんだ
若かったらこの人も取ってたと聞いたことある

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

もうつべですら名前出なくなった
ここくらいやろ

**デフォルトの名無しさん** · 2023/07/21(金) 22:04:13.55

>>775
勝ったは勝ったが人格否定レベルの反論論文を出してしまったので
世界的に認められることはなさそう

**デフォルトの名無しさん** · 2023/07/21(金) 22:30:59.27

もしかしたら今数学板で暴れ回ってるアホここまで進出してるんかな

**デフォルトの名無しさん** · 2023/07/21(金) 22:49:21.36

そいつが同一人物なのか知らないがそれだったら皮肉だな
LinkedListの間違いを指摘し俺は数学科出身だ

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

モッチーが勝ちと言ってる時点で数学科卒の面汚しとわかる

**デフォルトの名無しさん** · 2023/07/21(金) 23:12:54.88

たまたま間違い指摘されたやつが数学科とかw
こうなるともう数学にマウントを取られ続ける人生だな
宿命というべきか