Rust part9

**デフォルトの名無しさん** · 2020/08/23(日) 01:07:35.52

Mozilla発のRust言語のスレ

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

前スレ
Rust part8
https://mevius.5ch.net/test/read.cgi/tech/1579834072/

**デフォルトの名無しさん** · 2020/08/30(日) 03:03:14.91

@rustlangって日本語のRTもするのか
機械翻訳で読んだのかな

**デフォルトの名無しさん** · 2020/08/30(日) 11:07:07.53

いつになったらベンチマークStableにすんだよな

**デフォルトの名無しさん** · 2020/08/30(日) 18:03:13.46

ベアメタル用のコードを-C opt-level=0でコンパイルして乗算のオーバーフローチェック等のpanic機構って使用できる？
アセンブラリストを出力すると存在しないラベルの分岐命令が出力されるんだが正常な動作なのか・・・

31 · 2020/08/30(日) 18:53:07.92

例えばこんな感じ
ttps://uploader.purinka.work/src/17641.png
callqの行き先が不明

**デフォルトの名無しさん** · 2020/08/30(日) 19:51:29.80

--emit asmってlibcoreとリンクしたもの吐くの？
リンクされてないだけでここ呼んでるだけな気がする
https://github.com/rust-lang/rust/blob/1.46.0/src/libcore/panicking.rs#L39

**デフォルトの名無しさん** · 2020/08/30(日) 22:35:01.08

>>28
failureは役目を終えた。std::error::Error,thiserror,anyhowでfailure相当になる。
最近はenumxのcexで静的例外風にかけるけど。

>>31-33
panic_handlerを書いた覚えがないなら自分で書く。stdにはデフォルトの実装が用意されてる。
The Embedded Rust Bookに詳しく書いてあるから、rustupでローカルにダウンロードしてrustup docで開ける。

emitだとコンパイルまでしかしない。依存先すらコンパイルしてなかったと思う。

31 · 2020/08/30(日) 23:57:14.44

サンキュ

>>33
ビンゴだった。でも欲しいのはアセンブルリストなのでlibcoreを含むリストをどう入手するかが課題です
objdumpだと元のソースコードの行数等のデバッグ情報が失われるみたいだしグローバルの有無等の取得方法も判らないし
そもそもgasフォーマットじゃないから見方が判らないところがあるし

>>34
panic_handlerを自分で書きたいのはヤマヤマですが記述例が見つからず棚上げ状態です
ttps://rust-embedded.github.io/book/start/panicking.html
は見ていますが記述例は見あたりませんし

**デフォルトの名無しさん** · 2020/08/31(月) 08:19:34.04

ターミナル上で色つけるのとテキストポジションを決めたいだけの簡単なTUIアプリ作りたいんだけど、有名なTUIクレートが多くて迷ってます。
適切なクレートが何か分かる方教えてください。

**デフォルトの名無しさん** · 2020/08/31(月) 10:44:07.07

複雑なことしないなら termion

なんてどう？

**デフォルトの名無しさん** · 2020/08/31(月) 20:17:03.77

>>37
ありがとうございます。一度見てみます。

**デフォルトの名無しさん** · 2020/08/31(月) 22:50:36.76

>>35
英語読めないって話？
>A behavior can be chosen by declaring a #[panic_handler] function. This function must appear exactly once in the dependency graph of a program, and must have the following signature: fn(&PanicInfo) -> !, where PanicInfo is a struct containing information about the location of the panic.
>Given that embedded systems range from user facing to safety critical (cannot crash) there's no one size fits all panicking behavior but there are plenty of commonly used behaviors. These common behaviors have been packaged into crates that define the #[panic_handler] function. Some examples include:

**デフォルトの名無しさん** · 2020/09/01(火) 00:12:49.85

MirakurunクローンのmirakcってRustでかかれてるのか

ソースちょっとのぞいてみたけどサッパリだった

**デフォルトの名無しさん** · 2020/09/01(火) 00:14:06.84

よく作れるよなあ

**デフォルトの名無しさん** · 2020/09/01(火) 00:23:01.46

>>35
記述例が見たいならそこからリンクされてるpanicハンドラクレートのソースを見ればいい。
例えばこれとか。

https://github.com/japaric/panic-abort/blob/master/src/lib.rs

**デフォルトの名無しさん** · 2020/09/02(水) 00:14:27.98

>>42
そうじゃなくて
>Given that embedded systems range from user facing to safety critical (cannot crash) there's no one size fits all panicking behavior
の意味がわからないんだろう。ベアメタルで人の書いたpanic handlerの中身なんて読んでも意味ないし。

31 · 2020/09/02(水) 08:06:57.73

>>42
それだと基本的に>>32と大差なく見えるというかリンク後に逆アセンブラリストを追いかけたら
最終的にfn panicへ制御が渡っている事を確認しています
>>34でpanic_handler書いていないみたいな事が書かれていたので別の書き方があるのかと・・

**デフォルトの名無しさん** · 2020/09/03(木) 00:54:39.65

Supporting Linux kernel development in Rust
https://lwn.net/SubscriberLink/829858/281103f9c6fd0dc2/

**デフォルトの名無しさん** · 2020/09/03(木) 13:59:41.08

お前らの考えとしてぶっちゃけどうよ？
今後10年でc/c++を凌駕する存在になり得るのかRustは

**デフォルトの名無しさん** · 2020/09/03(木) 14:09:27.73

10年もありゃRustベースのもっといいやつが出てきそう

**デフォルトの名無しさん** · 2020/09/03(木) 14:28:37.24

Dはもう20年になるのか胸熱

**デフォルトの名無しさん** · 2020/09/03(木) 14:49:09.48

C++ 30よりは普及するんじゃないか。
（30とかどんな魔境になってるんだろうか…）

**デフォルトの名無しさん** · 2020/09/03(木) 16:20:07.25

Rust++もそこそこの魔境になるから大丈夫

**デフォルトの名無しさん** · 2020/09/03(木) 16:22:17.40

折角Edition分けしてんだし、一部後方互換性をバッサリ捨てて冗長な表現を纏めて++回避したら流行りそう
なおロードマップ見渡してもその予定は一切御座いません(笑)

**デフォルトの名無しさん** · 2020/09/03(木) 21:15:25.18

Rustって未だにセルフホストできていない事に驚いた
標準添付のライブラリのビルドを試みたら
>error[E0554]: `#![feature]` may not be used on the stable release channel
等が大量に吐かれたｗ　要nightlyかよ

**デフォルトの名無しさん** · 2020/09/03(木) 22:16:06.69

>>52
それをセルフホストできてないというかどうかは知らんがビルドしたいならx.py使えよ。
bootstrapにはそれ用のオプションがちゃんとある。

**デフォルトの名無しさん** · 2020/09/04(金) 08:11:24.22

rustc: 1.48.0-nightly (130359cb0 2020-09-01)
src: 1.46.0
でもダメだった

>>53
丸ごとビルドしたい訳じゃなくて一部だけビルドしたい
ttps://qiita.com/kotetuco/items/54af67d5663013ad0db7#rust-core-library%E3%82%92%E7%94%A8%E6%84%8F%E3%81%99%E3%82%8B
こんな感じ。実際にはコンパイルオプションを調整したいけど
コンパイルできる組み合わせを探すしかないのか？stableとnightlyじゃコードツリーのディレクトリ構造からして違う有様だしなぁ

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

>>54
coreだけでもビルドできるが…。さすがに開発中に毎回bootstrapするわけない。
https://rustc-dev-guide.rust-lang.org/building/how-to-build-and-run.html#build-specific-components

自己流で試行錯誤するよりまず公式通りにやってからカスタマイズする方がいいのでは。

**デフォルトの名無しさん** · 2020/09/04(金) 15:34:10.06

>>55
thx。それを実行するにあたって最低限必要な物ってなんだろ。書いていないような・・・
Pythonとbetaなコンパイラが必要そうっぽい事は判るけど
というかコンパイラも含めたビルドは出来るだけ避けたい
環境(Windows)やマシン(2Core/8GB)のリソース的に成功するか判らないし失敗した場合の
トラブルシュートも難しい

あとそのコマンドはnightly？beta？限定のような。1.46.0 stableのコードツリーだとディレクトリ名が違う

**デフォルトの名無しさん** · 2020/09/04(金) 18:04:10.13

>>51
ほんそれ。
ある程度はシュガライズすべき

**デフォルトの名無しさん** · 2020/09/04(金) 18:33:08.78

>>56
環境構築はREADMEだな。
https://github.com/rust-lang/rust#building-on-windows

ディレクトリはちょうど運悪く先月くらいに構成変わってて、今betaまで反映されてるから次のリリースでstableも同じになる。
とりあえず今のstableなら以下でcoreだけビルドできるはず。
./x.py build --stage 0 src/libcore
コンパイラはx.pyが適切なバージョンを勝手に取ってくるから任せればよい。

**デフォルトの名無しさん** · 2020/09/05(土) 10:06:13.78

2Core/8GBでLLVMビルドするのかなりつらそう

**デフォルトの名無しさん** · 2020/09/05(土) 13:17:51.96

forとiterの使い分けってどうしたらいいんだろ
用途？

**デフォルトの名無しさん** · 2020/09/05(土) 15:05:36.16

コードが読みやすくなる方を使う

**デフォルトの名無しさん** · 2020/09/05(土) 21:40:57.16

codewarsをRustで解いてるけどなかなか勉強になる

**デフォルトの名無しさん** · 2020/09/06(日) 00:09:09.42

戦争反対

**デフォルトの名無しさん** · 2020/09/06(日) 00:12:10.28

敗戦国に対する差別を助長するとアメリカで主張していこうな！

**デフォルトの名無しさん** · 2020/09/06(日) 13:05:53.33

Cargo.tomlにrustのバージョン指定する方法ってどうやるっけ？
どこかで見た気がするんだけどcargo reference探してもないから知ってる人いる？

**デフォルトの名無しさん** · 2020/09/06(日) 13:33:28.17

>>65
Cargoにその機能はないな。rustupの機能として
rust-toolchainファイルにバージョンとかnightlyとか書けるよ。
当然rustupを使っていないと効果はないけど。

**デフォルトの名無しさん** · 2020/09/06(日) 13:50:50.21

低レイヤーのアルゴリズム実装てrustは実は向いてないんだよ。

**デフォルトの名無しさん** · 2020/09/06(日) 20:53:31.66

>>65
MSRVのことかな
https://rust-lang.github.io/rfcs/2495-min-rust-version.html

**デフォルトの名無しさん** · 2020/09/07(月) 05:35:58.44

>>68
おお、そうそう。ありがとう

**デフォルトの名無しさん** · 2020/09/08(火) 14:08:21.21

なんでIteratorの方にはchunksとかwindowsとかないの？
Vecに変換するのめんどくさい

**デフォルトの名無しさん** · 2020/09/08(火) 14:14:25.89

stdにない理由はしらんけどItertoolsでできるっしょ

**デフォルトの名無しさん** · 2020/09/08(火) 16:58:13.30

rustのormって何でdieselしかないの？dieselが完成されてるから？それともrustがdb使う用途に使われることが少ないとか？

**デフォルトの名無しさん** · 2020/09/08(火) 18:04:31.50

rustに関わらずormって限らられたシーンでしか使えない印象

**デフォルトの名無しさん** · 2020/09/08(火) 20:34:32.20

>>70
任意のimpl Iteratorからスライス作るためにはcollectしてVecを作るなど、比較的重めの処理が必要になる
コストのかかる処理は明示的にやらせるというのがstdのポリシーなので、用意されていないのでは
あと利用者側で .collect::<Vec<_>>() を追加するだけでよくて対処が難しくないのもわざわざstdに追加しようとする人が現れない理由だと思う

**デフォルトの名無しさん** · 2020/09/09(水) 18:10:37.98

>>74
コストのかかる処理はってIteratorにないからコストかかってるのでその理由は成り立たない気がする
個人的にはIteratorとスライスという違う型に同じメソッド名が生えてるのがあれなのかなと思った

**デフォルトの名無しさん** · 2020/09/09(水) 18:23:13.97

>>72
Dieselが早いうちに作られて支配的に使われるようになって他の連携クレートもdiesel用を用意してそして誰もいなくなった的な展開
個人的にはdieselは癖強いから完成度高くないと思う、ただ連携はかなり強い

**デフォルトの名無しさん** · 2020/09/09(水) 18:58:45.43

sqlxが本名だと思う

**デフォルトの名無しさん** · 2020/09/09(水) 21:48:02.38

Sqlx良いね

**デフォルトの名無しさん** · 2020/09/09(水) 22:34:56.87

>>75
allocation不要なchunks/windowsの実装ってどうやるの？
Iterator ではなくて std::vec::IntoIter などに実装するということ？

**デフォルトの名無しさん** · 2020/09/10(木) 07:20:42.22

itertoolsの実装どんなんかしらんけど、
itertoolsのchunksは各チャンクがイテレータになってるし、
windowsのほうはtupleで帰ってくるからアロケーションしないんじゃね？

**デフォルトの名無しさん** · 2020/09/10(木) 07:23:35.08

すまん、チャンク・ウィンドウの個数分のアロケーションはさすがに発生してると思うわ多分

**デフォルトの名無しさん** · 2020/09/13(日) 20:54:26.61

VS2019の拡張機能にRustがあるんだけど、これは本物ですか？
VSCodeのとは違うみたいで情報がない

**デフォルトの名無しさん** · 2020/09/14(月) 01:42:47.60

&'static strってデータかテキスト領域どっちに入るの？デバッグ方法分からん

**デフォルトの名無しさん** · 2020/09/16(水) 01:12:00.89

Rustってむずくないですか
これ最初にプログラムやる言語じゃないよね…昔にC触ったとかそんなレベルだと全然わからん

**デフォルトの名無しさん** · 2020/09/16(水) 10:24:27.14

むずくない
めんどくい

**デフォルトの名無しさん** · 2020/09/16(水) 11:57:04.37

std::collections とかが複数形でstd::markerが単数形な理由ってなに？

**デフォルトの名無しさん** · 2020/09/16(水) 12:36:20.15

>>85
この言語は、深いことをやろうとするとメンドクサイだけではなく、
ちゃんと仕様が公開されて無い事が多いから難しくなる。

**デフォルトの名無しさん** · 2020/09/16(水) 13:09:08.47

え？仕様公開されてるだろ英語で

**デフォルトの名無しさん** · 2020/09/16(水) 13:54:55.78

自分の足も撃ち抜けない不自由な言語

**デフォルトの名無しさん** · 2020/09/16(水) 14:23:57.05

>>87
公開されていないというより確定していないことは結構ある。
細かいところでは処理系の実装の現実に頼らないとしゃーないってのは
C/C++ でもなんでも同じだし、
まあそんなもんです。

**デフォルトの名無しさん** · 2020/09/16(水) 20:12:39.40

具体的な話をしてくれ

**デフォルトの名無しさん** · 2020/09/17(木) 04:57:16.23

>>88
公開されてない。

**デフォルトの名無しさん** · 2020/09/17(木) 06:48:06.13

何の仕様が知りたくて見つけられなかったのか言ってくれよ

**デフォルトの名無しさん** · 2020/09/17(木) 09:31:52.63

チュートリアル追ってみたらLinkedListの実装に結局
unsafeなことやらなきゃいけないみたいに書いてあって
やる気なくしたアホくさ

**デフォルトの名無しさん** · 2020/09/17(木) 09:38:19.49

LinkedListはもうオワコン
あれはCPUが遅くてキャッシュミスとかあまり考えなくても良かった時代のもの

**デフォルトの名無しさん** · 2020/09/17(木) 09:49:42.39

初心者が「まずは独自コンテナクラスでも実装してみるか」っていって討ち死にしていくのはしばしば見られるよな。
Rustのコンテナ実装は高難度なので素直に標準ライブラリを使いましょう、ってどこかに書いてあるべきかも。

**デフォルトの名無しさん** · 2020/09/17(木) 09:53:23.90

高難度？ただ面倒なだけじゃなくて？

**デフォルトの名無しさん** · 2020/09/17(木) 10:01:04.46

>>97
大抵の人にとってhello worldの次にやる課題としては高難度過ぎると思うけど。
もちろんおまえにとっては簡単で面倒なだけってのは別に否定しないが。

**デフォルトの名無しさん** · 2020/09/17(木) 10:11:43.63

別にRustのチュートリアルはプログラミング初心者のためにあるわけじゃないし

**デフォルトの名無しさん** · 2020/09/17(木) 10:53:28.83

>>93
一番問題なのは、ヒープに対する参照の詳細が英語でもどこを探してもないこと。
Box<T>, Rc<T>, RefCell<T>
などの詳細と、生存期間、所有、借用、コンストラクト時のMoveの処理の話。
Option<T>はまだ分かるが。

**デフォルトの名無しさん** · 2020/09/17(木) 10:55:15.75

>>95
それは信頼できる情報か。
キャッシュミスし易いから、LinkedListは、もう動的配列より絶対的に劣る、
などというようなことを書いたまともな論文でもどこかにあるのか。

**デフォルトの名無しさん** · 2020/09/17(木) 11:01:24.99

Cアルゴリズム入門的な本があるように
Rustアルゴリズム入門的な記事があっていい気がする

**デフォルトの名無しさん** · 2020/09/17(木) 11:06:01.57

任意の場所への挿入・削除とかは動的配列よりLinkedListでやったほうが効率いいし

**デフォルトの名無しさん** · 2020/09/17(木) 11:19:25.01

>>94
unsafe使わなくてもできるよ
stdのLinkedListがunsafe使ってるのはパフォーマンスのため

独自実装のLinkedListなんでプロダクションでは使わないだろう
unsafe使わないやり方で作ってみればいいと思うよ

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

>>101
まともな論文ではないけどC++のハゲがそんなこと言ってなかったっけ

**デフォルトの名無しさん** · 2020/09/17(木) 11:27:31.41

キャッシュミスしやすいのはそうだろう
メモリが連続してないんだから当然だね
ただ時代遅れってのは勝手に付け足したろ

**デフォルトの名無しさん** · 2020/09/17(木) 11:33:13.70

>>100
「ヒープに対する参照の詳細」って何じゃい？

Box<T>, Rc<T>, RefCell<T>は標準ライブラリだからライブラリのリファレンスを見る

>生存期間、所有、借用、コンストラクト時のMoveの処理の話。
こっちは一般原則だから普通に明記されてると思うけど
Language Reference本も完成はしてないから書いてない詳細もあるだろうけど
それで困るのは一般原則的なことじゃないでしょ

**デフォルトの名無しさん** · 2020/09/17(木) 12:26:42.19

C++ のコンテナは、デフォルトでベクター

ゲームプログラミングでは、プログラマー自身がまとめてメモリを確保する、
メモリ管理システムの例が、よく載っているけど、

一般用途では、ベクターの速度には勝てないのじゃないか？
2分木とか、特殊用途なら別だが

Elixir でも、リストは先頭・末尾だけが速いだけで、
中間の要素を取得するには、N / 2 要素をたどる必要がある

ただ、Elixirは関数型で、元の要素が変化しないから、
更新時だけ、要素をコピーすればよい

**デフォルトの名無しさん** · 2020/09/17(木) 13:19:52.64

C++のvectorでも深い考え無しに闇雲に使うと
要素コピー発生しまくりなアホなコードになる

**デフォルトの名無しさん** · 2020/09/17(木) 13:41:43.66

LinkedListと動的配列の違いは速度だけの問題じゃないんだな、これが。
前者はプログラミング上、後者より圧倒的に有利な場面がある。
それは、要素の識別性だ。

**デフォルトの名無しさん** · 2020/09/17(木) 14:10:37.15

C++のRAIIイディオム、SharedPointer、Moveセマンティクス
でRustにメモリ安全でどこまで対抗可能かな

**デフォルトの名無しさん** · 2020/09/17(木) 15:25:52.19

とりあえず二重開放でコケますね

**デフォルトの名無しさん** · 2020/09/17(木) 15:58:39.73

C++は確かに道具は十分揃ってるんだけど、
適切に使えるかどうかはプログラマーの注意力次第なので厳しい…。

**デフォルトの名無しさん** · 2020/09/17(木) 20:47:10.45

LinkedListが役に立たないと知ったのは結構前だな
Javaのスレで色々議論があったんだけど
LinkedListが優位になるであろう場面でもArrayListのほうが早いと断言するやつが居て
バカじゃねーの？と思いつつも実装してみたら完全にArrayListのほうが早かった
古い知識でイキってた当時の自分が恥ずかしい

**デフォルトの名無しさん** · 2020/09/17(木) 21:46:41.57

> C++は確かに道具は十分揃ってるんだけど、
> 適切に使えるかどうかはプログラマーの注意力次第なので厳しい…。
そもそもC++は注意力の前に必要知識が多すぎる

>>114
ベンチのソースとか記事ないの？

**デフォルトの名無しさん** · 2020/09/17(木) 21:47:07.97

その早いって何が？
要素の検索が？挿入・削除が？

**デフォルトの名無しさん** · 2020/09/17(木) 21:56:39.63

適当に検索した記事みてみたら普通に予想通りの内容だったけど

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

リンクリストのキャッシュミスが問題になるのであれば
探索時にプリフェッチしておけばよくね？
今時の高性能なプロセッサなら大抵そういう命令を装備しているだろ
遅いのは実装がウンコなだけなんじゃ

**デフォルトの名無しさん** · 2020/09/18(金) 00:33:25.64

リストの要素がそれぞれ離れたアドレスにあるような実装だったら、クソデカキャッシュ必要になったりしない？

**デフォルトの名無しさん** · 2020/09/18(金) 02:24:56.35

最近のDDR4(?)メモリの速度の進化も凄いから、キャッシュミスがあっても、
キャッシュがヒットした場合の3倍位の速度低下で済むんじゃないかと思うし、
少なくとも、キャッシュミスによる速度低下には上限がある。
一方、LinkedList、動的配列の途中への挿入や、途中要素の削除にかかる時間は、
全体の要素数を N とした時、それぞれ、O(1)、O(N)となる。
キャッシュミスによる速度低下が高々3倍程度なのに対し、
動的配列の遅さは、要素数 N に比例してしまうから上限がない。
だから、本質的に要素数が多くなった場合には、
キャッシュミスによる速度低下とは比べ物にならないくらい
速度差は歴然たるものとなる。

**デフォルトの名無しさん** · 2020/09/18(金) 02:26:46.51

>>120
[補足]
動的配列で途中への挿入や途中要素の削除では、平均で、 N/2 要素程度のコピー動作が
入る。これを

**デフォルトの名無しさん** · 2020/09/18(金) 02:33:02.97

>>121
これをMoveに置き換えて高速になるのは、要素の中身が、Heap領域など、要素自体
とは別の場所に有る場合である。たとえば、
struct Element {
　const char *m_pszText;　// new char[]で確保したHeap領域を指す0終端文字列
};
簡単のためこれの固定長配列を書いてみれば：
Element g_arr[1024];
となる。この要素のデータを読み取る場合は次のようになる、
for ( int i=0; i<1024; i++) {
　printf( "i=%d, text=%s\n", i, g_arr[i].m_pszText );
}
この場合、m_pszTextは、ヒープ領域にとってあるから、結局、配列でも
キャッシュミスは生じ得る。
ということで、動的配列でMove動作が有効である例では、たとえ動的配列で
あっても、結局、キャッシュミスは生じる。

**デフォルトの名無しさん** · 2020/09/18(金) 03:33:15.49

ここまでベンチなんもないのでとりあえず適当に拾ったやつ
https://dzone.com/articles/performance-of-array-vs-linked-list-on-modern-comp

総データ量がキャッシュをはるかに超えるとかだと多分変わってくるんだとは思う
その場合でもUnrolled linked listとかを使うのがいいってことにはなるのかな？

**デフォルトの名無しさん** · 2020/09/18(金) 03:52:17.29

>>123
大体そういう人は、リンクリストの本質を理解できてないので、
「先頭から10番目の場所に挿入する」
などという馬鹿な書き方をしている。
例え博士課程とかの人でもそういう馬鹿な人がいる。

**デフォルトの名無しさん** · 2020/09/18(金) 03:53:47.62

推測するな、計測せよ

**デフォルトの名無しさん** · 2020/09/18(金) 03:54:10.38

>>124
C++のSTLは設計は馬鹿なので、先頭から k 番目に挿入するなど言う
馬鹿な統一関数がある。
それは、リンクリストにとって最悪の挿入法で、O(N)の時間が掛かる。
だから遅い。
数学的なイマジネーションが無いので、その間違いに気づかない。

**デフォルトの名無しさん** · 2020/09/18(金) 03:54:37.58

>>125
いくら測定しても、理屈が間違っていれば、間違った実験結果となる。

**デフォルトの名無しさん** · 2020/09/18(金) 03:56:20.84

>>125
グラフだけ書いて、ソースがない。
どうせ、k 番目に挿入すると言う馬鹿コードになっている。
いくら言っても、同じ間違いをする人が続出する。