Rust part18

**デフォルトの名無しさん** · 2022/12/10(土) 18:17:02.61

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

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

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

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

**デフォルトの名無しさん** · 2022/12/12(月) 01:26:05.71

コード量、もカラクリ
バグが減った、もカラクリ
こういうそしりになるぞ

**デフォルトの名無しさん** · 2022/12/12(月) 01:26:34.63

全員不本意だろ

**デフォルトの名無しさん** · 2022/12/12(月) 01:30:48.03

>>47
言語間の比較はあるけどプロジェクト独自コードとそれ以外を区別してるようなところあった？
セクション名だけでも良いから教えてよ

あとカラクリ推進派とか変な造語で言われてもわからん
何かのレッテル貼り？

**デフォルトの名無しさん** · 2022/12/12(月) 01:31:50.90

>>50 >何かのレッテル貼り？
カラクリ推進派とはあなたのことですよ

**デフォルトの名無しさん** · 2022/12/12(月) 01:34:06.61

誤認誘発、過剰期待のリスクは無視するべきではない

**デフォルトの名無しさん** · 2022/12/12(月) 01:35:03.87

>>51
ごめんね、何を言ってるかわかってあげられなくて
あと文章の後半だけじゃなくて前半にも反応してほしかったな
流し読みで確認したから見落としあるかもしれないので、原文でおかしなこと言ってるなら把握しておきたい

**デフォルトの名無しさん** · 2022/12/12(月) 01:36:12.87

>変に行間を読み取って
>>50は変に行間を読み取らせようとしてるな

**デフォルトの名無しさん** · 2022/12/12(月) 01:37:35.10

>>53
原文にかいてさえあれば、実態はどうでも良い
という事かな？

**デフォルトの名無しさん** · 2022/12/12(月) 01:38:21.40

>>54
あなたの言う良くない文章は>>50で引用してる部分だけということかな？

>>55
それ以外に何を問題にしているの？

**デフォルトの名無しさん** · 2022/12/12(月) 01:39:08.62

引用してるのは>>50じゃなくて>>35だった

**デフォルトの名無しさん** · 2022/12/12(月) 01:39:48.77

>>56
カラクリ推進派=翻訳従事者関係者？

**デフォルトの名無しさん** · 2022/12/12(月) 01:40:20.61

実態を大事にしような

**デフォルトの名無しさん** · 2022/12/12(月) 01:43:08.80

AndroidのうちRustコードは1.5M
そのうちAOSP独自コードは0.1M
この話はおわり

**デフォルトの名無しさん** · 2022/12/12(月) 01:46:10.84

>>60
1.5Mがそんなにうれしかったのか？

>そのうちAOSP独自コードは0.1M
これ原文筆者に明記するように言いに行けよ、関係者なんだろ？

**デフォルトの名無しさん** · 2022/12/12(月) 01:47:21.11

原文にかいてさえあれば、実態はどうでも良い
↓
それ以外に何を問題にしているの？

この返しには驚いた。良心のかけらもない

**デフォルトの名無しさん** · 2022/12/12(月) 01:49:04.49

0.1Mをけなしてるのか？可哀想だろ

**デフォルトの名無しさん** · 2022/12/12(月) 01:50:55.08

>>61
コードの量あたりの脆弱性数の言語間比較の話なのになんで依存関係除外するの？
脆弱性の原因になるのは独自に作った部分だけじゃないよね？
そんなに0.1Mが重要だと思うから原作者に書けと伝えたら？

**デフォルトの名無しさん** · 2022/12/12(月) 01:52:09.95

>>64
君のカラクリストーリーはどうでも良いから

**デフォルトの名無しさん** · 2022/12/12(月) 01:53:07.38

わかったわかった、理屈はどうでも良いね
あんたが道徳的に正しいよ

**デフォルトの名無しさん** · 2022/12/12(月) 01:55:21.13

実態はどうでも良いカラクリ君が理屈を語るとは、笑う

**デフォルトの名無しさん** · 2022/12/12(月) 01:55:55.20

屁理屈、詭弁だろ

**デフォルトの名無しさん** · 2022/12/12(月) 01:57:32.25

しかもね、道徳じゃなくてリスクの話

**デフォルトの名無しさん** · 2022/12/12(月) 01:59:40.01

加えて、プログラマーに対するリスペクト

**デフォルトの名無しさん** · 2022/12/12(月) 02:01:36.06

あるアプリケーションを構成するコードの量を示すときは、自分たちが書いた量も示さないとリスクがあるしリスペクトに欠けるということね了解

**デフォルトの名無しさん** · 2022/12/12(月) 02:02:25.03

そうだよ。カラクリ君。15倍は失態だったね

**デフォルトの名無しさん** · 2022/12/12(月) 02:03:00.26

実態を大切にしような

**デフォルトの名無しさん** · 2022/12/12(月) 02:04:04.46

googleの人にもぜひ伝えてあげてよ立派な考えなんだからさ
もうちょっとコンテキスト補ってあげないと伝わらないと思うけど

**デフォルトの名無しさん** · 2022/12/12(月) 02:05:54.83

うっぷん晴らしにキャラ召喚しないでね

**デフォルトの名無しさん** · 2022/12/12(月) 02:07:59.96

あんたじゃないし、そんなことはしないよ

**デフォルトの名無しさん** · 2022/12/12(月) 02:08:45.26

なんか突然ID変わったな
ID:BZoLN2AH=ID:TQPiS+Fx

**デフォルトの名無しさん** · 2022/12/12(月) 02:09:06.83

冗談きついな、別室で頑張ってね

**デフォルトの名無しさん** · 2022/12/12(月) 02:11:40.12

それおちょくってるのか、そういう組織があるとマジで思ってるのか、どつち？

**デフォルトの名無しさん** · 2022/12/12(月) 02:14:41.40

>それおちょくってるのか、そういう組織
リスクの話をしている。おちょくりでもマジでもない

**デフォルトの名無しさん** · 2022/12/12(月) 02:15:18.25

レピュテーションリスク

**デフォルトの名無しさん** · 2022/12/12(月) 02:16:26.89

実態通りのレピュテーションが重要

**デフォルトの名無しさん** · 2022/12/12(月) 02:17:58.12

スレのみなさま、ごめんなさい
>>33は正しい
おやすみなさい

**デフォルトの名無しさん** · 2022/12/12(月) 02:20:53.27

そうか、スレ立て人だったか。バイバイ、面白かったよ、別室で頑張ってね

**デフォルトの名無しさん** · 2022/12/12(月) 02:26:04.34

成果を数値化した側は誤解を招き、リスクを数値化しようともしない側が数学的に優位なのはまあ分かる
3.14よりもπの方が誤解がないのと同じ

**デフォルトの名無しさん** · 2022/12/12(月) 02:28:14.68

あらら、キャラ召喚してるじゃんw

**デフォルトの名無しさん** · 2022/12/12(月) 02:58:18.77

>>33
今回に関しては全く必要なかった
2つNGにしたら33の次は85にw
複オジじゃないからNGしやすくて助かる

**デフォルトの名無しさん** · 2022/12/12(月) 03:05:27.82

そりゃどうも

**デフォルトの名無しさん** · 2022/12/12(月) 03:07:58.75

85もキャラ変しただけだからNGしときな。

**デフォルトの名無しさん** · 2022/12/12(月) 06:07:39.15

>>85
15倍の誤差だからπ=47.12って言う大暴投だからな

**デフォルトの名無しさん** · 2022/12/12(月) 06:51:30.97

深夜のレスバトルが興味深くなる見方、そして消えぬ複オジ軍団説

普段はまともぶってる放り投げキャラ？>>26がつつかれたら、速攻で複オジが出て来た
とにかく複オジは文書(翻訳)と仕様マウントが大事

放り投げキャラは次世代スレのwasmリソースコストおじ→複数人説

>>77が自演の決定的ボロなのか、あるいは監視引き継ぎミスなのか
引き継ぎミスなら→複数人説

しかも>>85がポエオジという可能性→複数人説
更にレスバトルが複オジじゃないと収拾したい>>87の登場

そういう目で見たらそう見える

**デフォルトの名無しさん** · 2022/12/12(月) 07:35:06.40

>>91
いまいち

ミスではなく>>76が引き継ぎの瞬間で
同一人物を装うために>>77を入れてる
という見立ての方が断然面白いでしょ

**デフォルトの名無しさん** · 2022/12/12(月) 07:35:25.61

自称集団ストーカー被害者の供述と同じ

**デフォルトの名無しさん** · 2022/12/12(月) 07:49:30.92

引き継いだら即幕引き、その理由は？
>>79-80
でバトルの必要が無いと判断出来た
という見立てのが面白い

**デフォルトの名無しさん** · 2022/12/12(月) 16:49:32.11

Fedora37のLinux KernelがVer.6.0になってたから新機能なんだろってググったら6.1から遂にRustサポートされるんだね

**デフォルトの名無しさん** · 2022/12/12(月) 23:25:53.54

このスレ捨て捨てよ

**デフォルトの名無しさん** · 2022/12/13(火) 22:51:58.96

Android12のtokeiしたぞ計算は自分でやれ
===============================================================================
Language Files Lines Code Comments Blanks
===============================================================================
Assembly 10 1835489 1776138 61 59290
GNU Style Assembly 511 698434 666001 20331 12102
C 2269 858479 652278 119729 86472
C Header 20347 4528431 3057716 1023059 447656
C++ 17900 9289538 7491429 858792 939317
C++ Header 305 157423 120050 11387 25986
Go 805 271377 201441 35705 34231
Java 57305 14796003 9709131 3245016 1841856
JavaScript 91 25468 20400 2951 2117
Kotlin 1833 319017 225519 58641 34857
Python 3721 933286 747682 79727 105877
TypeScript 231 680201 536363 142914 924
-------------------------------------------------------------------------------
Rust 203 47094 38569 3786 4739
|- Markdown 148 4044 13 3696 335
(Total) 51138 38582 7482 5074
===============================================================================
Total 105531 34440240 25242717 5602099 3595424
===============================================================================
externalの名前が実態に同意だしそもそもexternal内はダブルカウントが多発している

**デフォルトの名無しさん** · 2022/12/13(火) 23:23:57.37

もっとGoがフィーチャーされてもいい

Rust 0.27%(Android13)
Rust 2.19%(rust増減/全体増減)
Rust 6.25%(rust増減/native増減)

Go 0.94%(Android13)
Go 3.14%(go増減/全体増減)
Go 8.97%(go増減/native増減)

native(C/C++,go,rust,asm)

**デフォルトの名無しさん** · 2022/12/13(火) 23:30:32.49

相関で言うと、致命的バグが減ったのはGoが増えたおかげ

**デフォルトの名無しさん** · 2022/12/13(火) 23:37:00.82

GoはNSA公認の安全志向言語だからね

**デフォルトの名無しさん** · 2022/12/14(水) 01:02:52.63

我が軍のリターンと我が軍のリスクを比較するべきで
味方のリターンと競争相手のリターンの差をカイゼンさせようとするのは合理的ではないと思う

**デフォルトの名無しさん** · 2022/12/14(水) 01:14:31.36

最初から違和感があると思っていたが
元記事ではGoが何故か除外されてる

ストーリー構成に不都合だったのか
相関だと何とでも言えるんだね

**デフォルトの名無しさん** · 2022/12/14(水) 01:27:29.73

>>101
良くないね、堂々と数字のカラクリを肯定するとは

**デフォルトの名無しさん** · 2022/12/14(水) 01:56:11.07

>>101 我が軍
こいつ遂に開き直って複おじ複数人疑惑を隠さなくなった
引き継ぎは2時？

裏舞台でこそこそしてろよ、表舞台に出て来るんじゃないぞ

**デフォルトの名無しさん** · 2022/12/14(水) 06:45:32.23

>>102
元々C/C++のメモリー障害の話なので低レイヤーで使えないGoを対象外にするのは当たり前だと思うぞ
>>98 の native(C/C++,go,rust,asm) もどう言う根拠でGo入れてるのかよくわからん、Go入れるならJavaが入らない理由を示してほしい

**デフォルトの名無しさん** · 2022/12/14(水) 07:01:51.79

ストーリーの無い生データを見た実際のところ、バグデータのある期間(~android12)でのRustは高々0.13%しか無い
C++の検証ツール類の活用だったりGo活用だったりの方が圧倒的に貢献していると考えるのが普通
他言語の成果を横取りしてる印象を持ったし、データを見たマの反発を買うのも当然

**デフォルトの名無しさん** · 2022/12/14(水) 07:15:30.66

>>105 ...の話なので...
>>105 = 放り投げ常習犯のRustカラクリストーリー君

**デフォルトの名無しさん** · 2022/12/14(水) 07:40:22.86

>>106
ほんとこの通りだわ
今回みたいに1.5Mの疑義が出て数字を掘られなければ、メモリバグ削減はRustの成果だと信じ込まされた訳だし、恐ろしいわ

**デフォルトの名無しさん** · 2022/12/14(水) 08:29:54.62

>>107
カラクリだと言うならせめて
> >>98 の native(C/C++,go,rust,asm) もどう言う根拠でGo入れてるのかよくわからん、Go入れるならJavaが入らない理由を示してほしい
ぐらいには回答しなよ

**デフォルトの名無しさん** · 2022/12/14(水) 08:46:08.12

あのね、さすがにもう、原文の脚色を軸にした議論に価値は無い
>>109
Goを蹴落としたいだけの言いがかりになるからやめたほうがいい

1.5Mの数字もちだして来たのどうせ>>105,109なんだろうし、この際言っておくけど、

迷惑でしかない

**デフォルトの名無しさん** · 2022/12/14(水) 12:43:46.50

>>110
はい、逃げた～
そもそもここRustスレだから迷惑なのはお前な

**デフォルトの名無しさん** · 2022/12/15(木) 18:34:29.90

Rust自体は好きで趣味で使ってるんだけど、最近の猫も杓子もRustっていう一部の風潮には、在りし日のC++やJavaが持て囃されていた時代を思い出してしまう時がある

**デフォルトの名無しさん** · 2022/12/15(木) 18:53:18.12

奴隷言語ってことなのかもな

**デフォルトの名無しさん** · 2022/12/15(木) 19:32:12.34

同意。
趣味では楽しく使ってるけど仕事では使いたくないわ。

不具合とか新規要件とか起因で所有権周り軒並みいじる必要が出てきたりしたら泣いちゃう。

**デフォルトの名無しさん** · 2022/12/15(木) 20:01:15.60

>>112
> 最近の猫も杓子もRustっていう一部の風潮
そんな風潮ホントにあるの？
C/C++の置き換えがメインだから分野はかなり限られそうだが

**デフォルトの名無しさん** · 2022/12/15(木) 21:34:29.95

正解は一つだけのようなことは昔Pythonが標榜していたけど
違反や無視しても棒で殴られたりしなかったので普通に普及した

**はちみつ餃子** ◆8X2XSCHEME · 2022/12/15(木) 21:48:07.72

C や C++ が駄目な部分を改定でどうにかしようとしてもツギハギだらけでますますグダグダになるばかり。
C や C++ みたい (いわゆるシステム記述言語) なことを安全にやれるように更地から設計しなおそうという試みの中では Rust は比較的よいと思うよ。

**デフォルトの名無しさん** · 2022/12/15(木) 23:23:09.65

>>117
キミは仕事でRust使ってんの？
使ってなさそうな感じを受けたけど

**デフォルトの名無しさん** · 2022/12/15(木) 23:37:14.28

LinkedListってなんで使われないんですか？
VecDequeのほうが性能いいの？

**デフォルトの名無しさん** · 2022/12/16(金) 01:36:50.79

>>119 性能いいことが多いからじゃないかな。
https://www.stroustrup.com/Software-for-infrastructure.pdf
> ... Consider a simple example: generate N random integers and insert
> them into a sequence so that ...
> Now, for which N is it better to use a linked list than a
> vector (or an array) to represent the sequence? ...
> ... When I ran the experiment on my 8-Gbyte laptop, I found N to be much
> larger than 500,000. ...

**デフォルトの名無しさん** · 2022/12/16(金) 01:45:46.48

言語仕様はまあいんだろうけどライブラリがうんこっこ

**デフォルトの名無しさん** · 2022/12/16(金) 02:56:52.27

自演か軍団かどうでも良いが纏めるぞ

>>112
息を吐く様に嘘を混ぜるのはよせ
猫も杓子も...←ウソシンプルに分かりやすいウソ
在りし日の...←ウソ今も昔もJava/C++の時代 + JS/Python/C#
https://i.imgur.com/xwnzvYQ.png

>>117
大人しくしてれば良いものを、そのキャラまたどぶに捨てるのか
もう終わりだよ、そのコテハン

>>117,119-121
話題のすり替え方が雑になってワンパターン

**デフォルトの名無しさん** · 2022/12/16(金) 06:42:28.75

>>85=>>112
よく見たら嘘の混ぜ方が完全一致

**デフォルトの名無しさん** · 2022/12/16(金) 07:28:20.01

>>122のデータ面白い
例えば、0.4%以下集団の慎ましさがまるで違う

Swift/Kotlin/Dart→分野に特化して第一候補、安泰
(モバイルアプリ開発は全体の中では小さいパイだけど)

Rust→システムの低レイヤー分野に特化すれば良いのに、
各方面のスキマ案件や非典型案件で、置き換え風潮だとか
吹聴するから、そこのメインストリームから反感買う
焦り過ぎ

**デフォルトの名無しさん** · 2022/12/16(金) 07:48:14.80

得意分野、スキマ案件や非典型案件、全部集めて0.30%
Rust全然キテないじゃん

**デフォルトの名無しさん** · 2022/12/16(金) 08:03:19.06

無名の謎言語よりも強いぞ

**デフォルトの名無しさん** · 2022/12/16(金) 08:08:17.97

Rustもすぐに一巡して新規消滅まっしぐら
無名の謎言語と競うことに

どうしてこうなった？ry

**デフォルトの名無しさん** · 2022/12/16(金) 11:56:22.77

>>119
LinkedListがフィットするユースケースが少ないから

LRUキャッシュをHashMap+LinkedListで実装する時みたいにランダムインサート/デリートがメインでリストを高速に走査する必要がない場合に使われる

**デフォルトの名無しさん** · 2022/12/16(金) 14:41:11.47

TypeScriptでお馴染みのPrismaってRustでも使えるんか

**デフォルトの名無しさん** · 2022/12/16(金) 15:24:01.50

>>129
元々Rustで作ったバイナリをJSでラップしただけのライブラリだった

**デフォルトの名無しさん** · 2022/12/16(金) 17:29:26.91

>>120
LinkedListよりvectorの方が「ほとんどの場合速いからvectorを使うべき」
と言っているのは、Stroustrup氏だけ。

**デフォルトの名無しさん** · 2022/12/16(金) 18:47:30.36

>>131 嘘つくのやめてもらっていいですか。
https://www.google.com/search?q=vector+list で
いま２位に出たこれ↓見ても引用と併せて「ほとんどvector」って言ってる人が少なくとも二人いる。
https://ja.stackoverflow.com/a/6008
> 大抵のケースでは vector<T> 利用で十分かと思います。（Tは要素の型）
> Scott Meyers, "Effective STL" でも、Item 1で次の言及があります
>> vector is the type of sequence that should be used by default.

俺も言うし>>128も言ってそう。

**デフォルトの名無しさん** · 2022/12/16(金) 19:52:47.31

LinkedListがいいとかVectorがいいとかじゃなく適材適所やろ

**はちみつ餃子** ◆8X2XSCHEME · 2022/12/16(金) 20:14:33.69

>>133
適材適所なのは前提として承知の上で「vector が適材である場所が多い」という話だろ。

**デフォルトの名無しさん** · 2022/12/16(金) 21:44:58.60

vectorはメモリが並んでるからキャッシュヒット率が高くて速いって教わった
C++だと裏で追加したときにreallocされて参照が切れるリスクがあるけど
Rustだと一応安全だし

**デフォルトの名無しさん** · 2022/12/16(金) 21:55:52.92

>>122
まず長文を嫌って端折ったのが悪かった、ごめん
Java/C++の在りし日ってのは、特にJavaなんだけど、JavaでGUIデスクトップアプリ作ったりアプレットでフロントをやってた時代の雰囲気と、Rustでwasmフロントやってたり、tauriがイケてる！GUIの決定版！みたいに言ってる奴が似てるなって思ったのよ
WEB全盛の昨今これらは趣味レベルでしかないので数字には出ないし、当然Rustコミュニティやプロダクト全般の事について言ったわけじゃないので"一部"と書いたんだけど、Rustaceanの一部ではなくプログラマコミュニティないし業界の一部とも読めてしまうね
これもごめんなさい

**デフォルトの名無しさん** · 2022/12/16(金) 23:54:59.70

>>132
ここにいるやつらは　データ構造とアルゴリズム　からやり直したほうがいいんじゃないか？

何を持って早い？っていってるんだ？

queueを実装するのにvector使うやつは愚か者だし
ソートするデータにlinked list使うやつも変なやつ

たいていVectorでOKとかいうのは脳みそ停止してる。ちゃんと考えるべき。

linked listは中間にデータをいれるとか、要素を取り除くのが得意なだけ。
普通に適材適所だろ？

**デフォルトの名無しさん** · 2022/12/17(土) 00:08:08.60

まずお前はアルゴリズムうんぬんの前に日本語からやり直せ
はちみつの割にはまともなこと言ってる

> 適材適所なのは前提として承知の上で「vector が適材である場所が多い」という話だろ。

あとqueueの実装にvector使うのは別に変じゃない、リングバッファも知らんのか？

**デフォルトの名無しさん** · 2022/12/17(土) 00:12:22.66

>>137
比較の例は>>120で挙がってるし、「普通に適材適所」を否定してる人も居ないし、
いったい何を見てレスしてるのかわからなくて怖い。

**デフォルトの名無しさん** · 2022/12/17(土) 01:03:01.35

>>120
その記事で、Stroustrup氏は、非常に特殊な例で実験しているように思える。
最初から明らかにvectorに有利、LinkedListに不利な実験。
これは最初からLinkedListに不利なことが脳内でも分かるので、
それが分からないとしたらstroustrup氏は想像力が不足している。
Stroupstrup氏本人は難しくて理由が分からない、みたいに思ってるらしい。

**デフォルトの名無しさん** · 2022/12/17(土) 01:08:13.28

>>134
Stroustrup氏はもっと極端で、LinkedListがvectorより速度面で上回る
ケースはほとんど無い、という程度の事を言っているように思う。

**デフォルトの名無しさん** · 2022/12/17(土) 01:15:11.07

>>140
[補足]
コンテナ内にN個の要素がある場合、
リンクリストは、1個の要素の追加はO(1)。しかし、全走査や探索は、O(N)。
彼の実験だと、1個追加する際に、追加する場所を探すために平均で N/2 個の
ノードを巡ることになっているから、
1要素あたりに必要な時間 = 場所を探す時間 + 追加の時間
= O(N/2) + O(1)
= O(N)
となる。一方、vector の場合、
1要素あたりに必要な時間 = 場所を探す時間 + 追加の時間
= O(N/2) + O(N/2)
= O(N)
となる。
オーダー的には、O(N)で同じだが、前者は、キャッシュミスが酷くなるので、
「係数」がとても大きくなっている。
だから、前者の方が後者よりも遅くなっていっる理由は明確。

結論は、要素を追加する際に「場所を探す」ことを行なっていて、それがLinkedList
の不得意分野だから。

**デフォルトの名無しさん** · 2022/12/17(土) 01:26:25.05

>>142
[補足2]
リンクトリストとvectorで、条件を満たす1個の要素を線形探索で探す時に
かかる時間は、共に O(N)で、オーダー的には同じ。
ところが、彼の実験の場合、(均等確率の完全に近い)乱数で要素の追加される
場所と追加される順序が強くランダムになるようにしている。
この条件だと、途中結果の集合を線形探索する時、vectorは、
要素のアドレスが連続しているのでキャッシュの先読み(prefetch)がよく聞くが、
LinkedListは、アドレスが強くランダムになるので、キャッシュの先読みが
上手く働かず、1個の要素当り、現在のCPUで、80クロックほどのレイテンシーが
発生してしまう。
つまり、この実験においては、要素追加の場所をランダムにしているせいで、
要素を巡る際に、
vectorは、メモリーリードの追加レイテンシーが0に近い。
LinkedListは、メモリーリードの追加レイテンシーが80クロック程度かかる。

**デフォルトの名無しさん** · 2022/12/17(土) 01:27:47.24

>>140-141
そういう極端な解釈や誤解を解くためと思われる FAQ が置いてある。
https://www.stroustrup.com/bs_faq.html#list
まずはこれを読んで、それでもなにか異論を唱えたいならこの中のどの部分についての異論なのか、
自身の主張がどう違うのか明らかにするように。

**デフォルトの名無しさん** · 2022/12/17(土) 01:33:08.88

>>144
俺が言いたいのは、Stroustrup氏は、数学的想像力においては、
俺より馬鹿だということだ。

**デフォルトの名無しさん** · 2022/12/17(土) 01:36:35.34

この分野は、専門家かどうかより、生まれつきの頭の良さがものを言う。
彼ははっきり行って、計算速度の見積もりにおいては才能が無い。
彼が評価されるべきは、
誰もオブジェクト指向を知らない時にSimulaのようなオブジェクト指向言語を
知っていて、それをCに応用したというだけ。
vectorやLinkedListの速度に関しては彼は間違っている。

**デフォルトの名無しさん** · 2022/12/17(土) 01:38:43.69

「測定無しで語らないで下さい」
というのも理論を軽視している学者の典型例。
日本でも物凄く多い。
自分が理論を正しく理解できて無いから、テストしないと見積もることが出来ないだけ。