Rust part18
レス数が1000を超えています。これ以上書き込みはできません。
>>2
テンプレにたくさんリンク貼るよりもLearn Rustへのリンク一つ貼るだけの方がいいんじゃないかと思う
https://www.rust-lang.org/learn >>1乙
公式じゃないけどこういうのもある
The Little Book of Rust Books
https://lborb.github.io/book/ tokei -t='Assembly,GNU Style Assembly,Java,Kotlin,JavaScript,TypeScript,Python,Rust,Go,C,C Header,C++,C++ Header' -e external -e prebuilts
===============================================================================
Language Files Lines Code Comments Blanks
===============================================================================
Assembly 11 1835634 1776276 61 59297
GNU Style Assembly 505 702218 669778 20314 12126
C 2260 862132 656263 119096 86773
C Header 20761 4587467 3072817 1053823 460827
C++ 19077 9875194 7969332 904154 1001708
C++ Header 312 227421 184914 13293 29214
Go 960 347839 262712 44117 41010
Java 62585 16324831 10773417 3527799 2023615
JavaScript 132 70006 56347 8309 5350
Kotlin 3162 525334 372328 94668 58338
Python 3924 1024375 820227 86674 117474
TypeScript 58 393127 299455 93064 608
-------------------------------------------------------------------------------
Rust 416 100326 82483 7631 10212
|- Markdown 308 6885 13 6323 549
(Total) 107211 82496 13954 10761
===============================================================================
Total 114163 36875904 26996349 5973003 3906552
=============================================================================== 前スレのAndroid Rustコード量水増しの話だけど、興味が出たので自分で見てみたわ
条件がC++と一緒なら良い、記事書いた本人に言え、はマ的に完全なる詭弁だわ
boostみたら一緒ですらないし、不適切に一票
Rustは10万行という数字が適切
そもそも詭弁擁護する勢力がいることにドン引き、マじゃないの？自分で見て見ろ
これ、Rust関連数字の信用にも響くから、盲目信者はしゃしゃり出るなよ >>7
external含むとどうなるの？
Android13での新規コードの割合はいくつなの？ >>6-7
勝手ながらソートして整えた
https://i.imgur.com/bF7XrxK.png
>>8
横からですが条件が一緒にならないと言っているのでは キモい独り言ツイートばっかりしてる某おじさんに聞いてもらうとかw 論理的に書かないから何が言いたいのか
何を問題視してるのかさっぱりわからない >>14 = 1.5m --> 0.1mでしたが何か？
詭弁w >>9
元記事ではレポジトリには150万行あるとしか言ってないので、
external含めて数えないと事実確認にならないのでは
もう一個の21%というのはAndroid13で追加されたネイティブコードのうちの割合の話なので、>>6の情報からは分からない
比較の条件という意味ではboost云々が何を言いたいのかがよくわからなかったから無視してしまったけど、そこが重要だった？
boost使ってるけどandroidのソースツリーに含まれていなかったということ？ オープンソースの依存ライブラリ含めても0.1Mしかなかったぞという主張なのかな？
だとすれば数え方が違うんだろうね >>16
盲目信者必死アクロバティック擁護
もう終わりだよこのスレ 最初から1.5Mはオープンソースの依存ライブラリ含めた数字だとはっきり書いてる >>18
元記事では21%の方を強調してて150万行はさらっと書いてあっただけだよ
なんか事実に反してること言ってるかな repo拾いに行ったの何人かいたようだが、ほとんどが絶句ダンマリ
これが現実
口数が多いのは盲目信者か、ポジショントークか
明日のLinux6.1の記事に差し障るのかな？ なんだ外部ライブラリはカウントしてないのか
それじゃダメだわな🙅♂ しかしまあ、こんなスレで必死に1.5Mを正当化(適切だという含み)しようとしている連中って、
次世代スレでRustの安全性は証明付き保証だと連呼していた奴らだよね
>口数が多いのは盲目信者か、ポジショントークか
ポジショントーク路線でのプロファイルは面白そう >>26 今晩の監視当番なのかな？
適切かどうか意見を訊かせてよ >>27
適切でしょ？
元記事で含むと明言されているものを除外するようか計測方法をして数字が合わないインチキだと言ってる方が意味不明 適切、元記事で含むと明言されている、って冗談か挑発か？ 自分への反論は当番制で組織的に書かれているという世界観なんだろうか 自分らで書いたコードが0.1Mです、って一行あれば許されたのにな Rust盲目信者による闇組織が5chなどインターネット各所を監視し宣伝工作をしている、と 他人が書いたコードと合わせて1.5Mの方だけしれっと書くのは適切じゃないね >>29
> There are approximately 1.5 million total lines of Rust code in AOSP across new functionality and components such as Keystore2, the new Ultra-wideband (UWB) stack, DNS-over-HTTP3, Android’s Virtualization framework (AVF), and various other components and their open source dependencies.
https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html
変に行間を読み取ってしまって勘違いを誘発すると言ってる？ 言っておくが、0.1Mは立派な成果だぞ
それを書け、と言っている 1.5Mの数字だけ出すから、水増しのそしりを免れない
0.1Mは立派な成果、それを出しとけば良かった >>36
文脈的にRustがどこのコンポーネントで使われているかを示すのが目的で、コード量はご参考程度に書いてあるだけだと思うが
記事全体の内一部にさらっと書かれている場所に突っかかりすきでは... 今までのRustの数字ってみんなこういうからくりだったのか？ってなるだろ 文章としてはAOSPに対するRustの貢献という話だから1.5Mで良いのでは？
AOSP自身がどれだけ書いたかはまた別の話 0.1Mという数値を出すとして、どういう位置づけの数値てして説明するの？ >>42 >どういう位置づけの数値
自分たち書いたコード量に決まってろうが >>43
カラクリ推進派って何？
>>44
それって本論であるRust採用でバグが減ったとどう結びつけるの？ >>46
>結びつけるの？
相関と原因のところを読め。Rustのカラクリ推進派は結論ありきのストーリー作りが好きだな コード量、もカラクリ
バグが減った、もカラクリ
こういうそしりになるぞ >>47
言語間の比較はあるけどプロジェクト独自コードとそれ以外を区別してるようなところあった？
セクション名だけでも良いから教えてよ
あとカラクリ推進派とか変な造語で言われてもわからん
何かのレッテル貼り？ >>50 >何かのレッテル貼り？
カラクリ推進派とはあなたのことですよ >>51
ごめんね、何を言ってるかわかってあげられなくて
あと文章の後半だけじゃなくて前半にも反応してほしかったな
流し読みで確認したから見落としあるかもしれないので、原文でおかしなこと言ってるなら把握しておきたい >変に行間を読み取って
>>50は変に行間を読み取らせようとしてるな >>53
原文にかいてさえあれば、実態はどうでも良い
という事かな？ >>54
あなたの言う良くない文章は>>50で引用してる部分だけということかな？
>>55
それ以外に何を問題にしているの？ AndroidのうちRustコードは1.5M
そのうちAOSP独自コードは0.1M
この話はおわり >>60
1.5Mがそんなにうれしかったのか？
>そのうちAOSP独自コードは0.1M
これ原文筆者に明記するように言いに行けよ、関係者なんだろ？ 原文にかいてさえあれば、実態はどうでも良い
↓
それ以外に何を問題にしているの？
この返しには驚いた。良心のかけらもない >>61
コードの量あたりの脆弱性数の言語間比較の話なのになんで依存関係除外するの？
脆弱性の原因になるのは独自に作った部分だけじゃないよね？
そんなに0.1Mが重要だと思うから原作者に書けと伝えたら？ >>64
君のカラクリストーリーはどうでも良いから わかったわかった、理屈はどうでも良いね
あんたが道徳的に正しいよ 実態はどうでも良いカラクリ君が理屈を語るとは、笑う あるアプリケーションを構成するコードの量を示すときは、自分たちが書いた量も示さないとリスクがあるしリスペクトに欠けるということね了解 googleの人にもぜひ伝えてあげてよ立派な考えなんだからさ
もうちょっとコンテキスト補ってあげないと伝わらないと思うけど なんか突然ID変わったな
ID:BZoLN2AH=ID:TQPiS+Fx それおちょくってるのか、そういう組織があるとマジで思ってるのか、どつち？ >それおちょくってるのか、そういう組織
リスクの話をしている。おちょくりでもマジでもない スレのみなさま、ごめんなさい
>>33は正しい
おやすみなさい そうか、スレ立て人だったか。バイバイ、面白かったよ、別室で頑張ってね 成果を数値化した側は誤解を招き、リスクを数値化しようともしない側が数学的に優位なのはまあ分かる
3.14よりもπの方が誤解がないのと同じ >>33
今回に関しては全く必要なかった
2つNGにしたら33の次は85にw
複オジじゃないからNGしやすくて助かる >>85
15倍の誤差だからπ=47.12って言う大暴投だからな 深夜のレスバトルが興味深くなる見方、そして消えぬ複オジ軍団説
普段はまともぶってる放り投げキャラ？>>26がつつかれたら、速攻で複オジが出て来た
とにかく複オジは文書(翻訳)と仕様マウントが大事
放り投げキャラは次世代スレのwasmリソースコストおじ→複数人説
>>77が自演の決定的ボロなのか、あるいは監視引き継ぎミスなのか
引き継ぎミスなら→複数人説
しかも>>85がポエオジという可能性→複数人説
更にレスバトルが複オジじゃないと収拾したい>>87の登場
そういう目で見たらそう見える >>91
いまいち
ミスではなく>>76が引き継ぎの瞬間で
同一人物を装うために>>77を入れてる
という見立ての方が断然面白いでしょ 引き継いだら即幕引き、その理由は？
>>79-80
でバトルの必要が無いと判断出来た
という見立てのが面白い Fedora37のLinux KernelがVer.6.0になってたから新機能なんだろってググったら6.1から遂にRustサポートされるんだね 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内はダブルカウントが多発している もっと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) 相関で言うと、致命的バグが減ったのはGoが増えたおかげ 我が軍のリターンと我が軍のリスクを比較するべきで
味方のリターンと競争相手のリターンの差をカイゼンさせようとするのは合理的ではないと思う 最初から違和感があると思っていたが
元記事ではGoが何故か除外されてる
ストーリー構成に不都合だったのか
相関だと何とでも言えるんだね >>101
良くないね、堂々と数字のカラクリを肯定するとは >>101 我が軍
こいつ遂に開き直って複おじ複数人疑惑を隠さなくなった
引き継ぎは2時？
裏舞台でこそこそしてろよ、表舞台に出て来るんじゃないぞ >>102
元々C/C++のメモリー障害の話なので低レイヤーで使えないGoを対象外にするのは当たり前だと思うぞ
>>98 の native(C/C++,go,rust,asm) もどう言う根拠でGo入れてるのかよくわからん、Go入れるならJavaが入らない理由を示してほしい ストーリーの無い生データを見た実際のところ、バグデータのある期間(~android12)でのRustは高々0.13%しか無い
C++の検証ツール類の活用だったりGo活用だったりの方が圧倒的に貢献していると考えるのが普通
他言語の成果を横取りしてる印象を持ったし、データを見たマの反発を買うのも当然 >>105 ...の話なので...
>>105 = 放り投げ常習犯のRustカラクリストーリー君 >>106
ほんとこの通りだわ
今回みたいに1.5Mの疑義が出て数字を掘られなければ、メモリバグ削減はRustの成果だと信じ込まされた訳だし、恐ろしいわ >>107
カラクリだと言うならせめて
> >>98 の native(C/C++,go,rust,asm) もどう言う根拠でGo入れてるのかよくわからん、Go入れるならJavaが入らない理由を示してほしい
ぐらいには回答しなよ あのね、さすがにもう、原文の脚色を軸にした議論に価値は無い
>>109
Goを蹴落としたいだけの言いがかりになるからやめたほうがいい
1.5Mの数字もちだして来たのどうせ>>105,109なんだろうし、この際言っておくけど、
迷惑でしかない >>110
はい、逃げた～
そもそもここRustスレだから迷惑なのはお前な Rust自体は好きで趣味で使ってるんだけど、最近の猫も杓子もRustっていう一部の風潮には、在りし日のC++やJavaが持て囃されていた時代を思い出してしまう時がある 同意。
趣味では楽しく使ってるけど仕事では使いたくないわ。
不具合とか新規要件とか起因で所有権周り軒並みいじる必要が出てきたりしたら泣いちゃう。 >>112
> 最近の猫も杓子もRustっていう一部の風潮
そんな風潮ホントにあるの？
C/C++の置き換えがメインだから分野はかなり限られそうだが 正解は一つだけのようなことは昔Pythonが標榜していたけど
違反や無視しても棒で殴られたりしなかったので普通に普及した C や C++ が駄目な部分を改定でどうにかしようとしてもツギハギだらけでますますグダグダになるばかり。
C や C++ みたい (いわゆるシステム記述言語) なことを安全にやれるように更地から設計しなおそうという試みの中では Rust は比較的よいと思うよ。 >>117
キミは仕事でRust使ってんの？
使ってなさそうな感じを受けたけど LinkedListってなんで使われないんですか？
VecDequeのほうが性能いいの？ >>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. ... 言語仕様はまあいんだろうけどライブラリがうんこっこ 自演か軍団かどうでも良いが纏めるぞ
>>112
息を吐く様に嘘を混ぜるのはよせ
猫も杓子も...←ウソ シンプルに分かりやすいウソ
在りし日の...←ウソ 今も昔もJava/C++の時代 + JS/Python/C#
https://i.imgur.com/xwnzvYQ.png
>>117
大人しくしてれば良いものを、そのキャラまたどぶに捨てるのか
もう終わりだよ、そのコテハン
>>117,119-121
話題のすり替え方が雑になってワンパターン >>85=>>112
よく見たら嘘の混ぜ方が完全一致 >>122のデータ面白い
例えば、0.4%以下集団の慎ましさがまるで違う
Swift/Kotlin/Dart→分野に特化して第一候補、安泰
(モバイルアプリ開発は全体の中では小さいパイだけど)
Rust→システムの低レイヤー分野に特化すれば良いのに、
各方面のスキマ案件や非典型案件で、置き換え風潮だとか
吹聴するから、そこのメインストリームから反感買う
焦り過ぎ 得意分野、スキマ案件や非典型案件、全部集めて0.30%
Rust全然キテないじゃん Rustもすぐに一巡して新規消滅まっしぐら
無名の謎言語と競うことに
どうしてこうなった？ry >>119
LinkedListがフィットするユースケースが少ないから
LRUキャッシュをHashMap+LinkedListで実装する時みたいにランダムインサート/デリートがメインでリストを高速に走査する必要がない場合に使われる TypeScriptでお馴染みのPrismaってRustでも使えるんか >>129
元々Rustで作ったバイナリをJSでラップしただけのライブラリだった >>120
LinkedListよりvectorの方が「ほとんどの場合速いからvectorを使うべき」
と言っているのは、Stroustrup氏だけ。 >>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も言ってそう。 LinkedListがいいとかVectorがいいとかじゃなく適材適所やろ >>133
適材適所なのは前提として承知の上で「vector が適材である場所が多い」という話だろ。 vectorはメモリが並んでるからキャッシュヒット率が高くて速いって教わった
C++だと裏で追加したときにreallocされて参照が切れるリスクがあるけど
Rustだと一応安全だし >>122
まず長文を嫌って端折ったのが悪かった、ごめん
Java/C++の在りし日ってのは、特にJavaなんだけど、JavaでGUIデスクトップアプリ作ったりアプレットでフロントをやってた時代の雰囲気と、Rustでwasmフロントやってたり、tauriがイケてる！GUIの決定版！みたいに言ってる奴が似てるなって思ったのよ
WEB全盛の昨今これらは趣味レベルでしかないので数字には出ないし、当然Rustコミュニティやプロダクト全般の事について言ったわけじゃないので"一部"と書いたんだけど、Rustaceanの一部ではなくプログラマコミュニティないし業界の一部とも読めてしまうね
これもごめんなさい >>132
ここにいるやつらは データ構造とアルゴリズム からやり直したほうがいいんじゃないか？
何を持って早い？っていってるんだ？
queueを実装するのにvector使うやつは愚か者だし
ソートするデータにlinked list使うやつも変なやつ
たいていVectorでOKとかいうのは脳みそ停止してる。ちゃんと考えるべき。
linked listは中間にデータをいれるとか、要素を取り除くのが得意なだけ。
普通に適材適所だろ？ まずお前はアルゴリズムうんぬんの前に日本語からやり直せ
はちみつの割にはまともなこと言ってる
> 適材適所なのは前提として承知の上で「vector が適材である場所が多い」という話だろ。
あとqueueの実装にvector使うのは別に変じゃない、リングバッファも知らんのか？ >>137
比較の例は>>120で挙がってるし、「普通に適材適所」を否定してる人も居ないし、
いったい何を見てレスしてるのかわからなくて怖い。 >>120
その記事で、Stroustrup氏は、非常に特殊な例で実験しているように思える。
最初から明らかにvectorに有利、LinkedListに不利な実験。
これは最初からLinkedListに不利なことが脳内でも分かるので、
それが分からないとしたらstroustrup氏は想像力が不足している。
Stroupstrup氏本人は難しくて理由が分からない、みたいに思ってるらしい。 >>134
Stroustrup氏はもっと極端で、LinkedListがvectorより速度面で上回る
ケースはほとんど無い、という程度の事を言っているように思う。 >>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
の不得意分野だから。 >>142
[補足2]
リンクトリストとvectorで、条件を満たす1個の要素を線形探索で探す時に
かかる時間は、共に O(N)で、オーダー的には同じ。
ところが、彼の実験の場合、(均等確率の完全に近い)乱数で要素の追加される
場所と追加される順序が強くランダムになるようにしている。
この条件だと、途中結果の集合を線形探索する時、vectorは、
要素のアドレスが連続しているのでキャッシュの先読み(prefetch)がよく聞くが、
LinkedListは、アドレスが強くランダムになるので、キャッシュの先読みが
上手く働かず、1個の要素当り、現在のCPUで、80クロックほどのレイテンシーが
発生してしまう。
つまり、この実験においては、要素追加の場所をランダムにしているせいで、
要素を巡る際に、
vectorは、メモリーリードの追加レイテンシーが0に近い。
LinkedListは、メモリーリードの追加レイテンシーが80クロック程度かかる。 >>140-141
そういう極端な解釈や誤解を解くためと思われる FAQ が置いてある。
https://www.stroustrup.com/bs_faq.html#list
まずはこれを読んで、それでもなにか異論を唱えたいならこの中のどの部分についての異論なのか、
自身の主張がどう違うのか明らかにするように。 >>144
俺が言いたいのは、Stroustrup氏は、数学的想像力においては、
俺より馬鹿だということだ。 この分野は、専門家かどうかより、生まれつきの頭の良さがものを言う。
彼ははっきり行って、計算速度の見積もりにおいては才能が無い。
彼が評価されるべきは、
誰もオブジェクト指向を知らない時にSimulaのようなオブジェクト指向言語を
知っていて、それをCに応用したというだけ。
vectorやLinkedListの速度に関しては彼は間違っている。 「測定無しで語らないで下さい」
というのも理論を軽視している学者の典型例。
日本でも物凄く多い。
自分が理論を正しく理解できて無いから、テストしないと見積もることが出来ないだけ。 彼は理論を分かって無いことが明白。
この実験において、LinkedListがNが大きくなると有利になると思い込んでNを
大きくしていったらしい。すると、彼の予想に反してそうならなかった。
しかし、俺には理由が分かる。
むしろ、LinkedListで、Nで割った時の単位要素あたりの時間は、あるNが
ある値を超えたときから曲線の傾きが大きくなる。
(i) N < N0 : キャッシュが働く時:
f(N) = a1 * N + b
(ii) N > N0 : キャッシュが働かない時:
f(N) = a2 * N + b
DDR4-SDRAM での推定の係数 :
a1 = 0.5
a2 = 0.5 * 80
俺は、これを数秒間で導いたから、ケアレスミスが含まれるかもしれない。 >>148
[ミス訂正]
a1 = 0.5 * L
a2 = 0.5 * (L + 80)
L = ループ一回当りのマシン語レベルでの見た目のクロック数。
0.5 を掛けているのは、1回の線形探索において、
平均移動回数が (N / 2) 回と推定されるから。
まだ、ケアレスミスがあるかもしれない。 すごいな。０点回答じゃん。
今後のため、ぜひコテハン頼む。 >>142
> = O(N/2) + O(1)
> = O(N)
ナニコレ？ >>150
ID:7EPFyoxp = はちみつがはちみつ搾り取った後の残りカス 100点おじさん頭悪いのは知ってたけどさすがにここまでとは思ってなかった
文章読解力に難があり過ぎ >>150,152-153
ちょっ、はちみつオジ=C++スレの天才オジなのか？
そしてすごい0点オジに、頭悪い100点オジ？
誰か複オジ軍団相関図、書いてよ！ >>136
これよく見たら謝ってるようでそうでもない
当時Javaの時代の雰囲気(全体)と今のRustのイキリ勘違いヤロウ(一部)は全然レイヤーが違う >>122
Rustの0.30%には流石にがっかりきた
比率からして既に一巡したんだと思う
Java vs Scala(JVM, 17.5%/0.47% => 何巡もして37倍)
C/C++ vs Rust(Native, 8.24%/0.30% => 一巡目で27倍) OSに依存しないライブラリの行数は、Android全体の行数で割り算できない
これが割り算のカラクリか フロントエンドのちゃらい流行り廃りを追いかけ続けるのに疲れて
早めにバックエンドに転向したいと目論んでいた筋にとっとは
Rustは無駄だと思い知ったことだろう
GoやっとけよGo 自分はRust使うけど人にはとりあえずGoにしとけば？って言っちゃうな
VSCodeなんかと同じで無難感はある 統一教会は日本で、ゆとりある教育を提唱しているが、韓国では全く逆のことを言ってるからな。
騙されるなよ。 >>157
対象の集団規模やその集団のレイヤーが異なることと、各々の集団に対して類似又は共通の雰囲気・要素が存在することないし感じられることは両立しうると思わない？ 統一教会と自民党は両立じゃないだろ。
日本における統一教会の実行部隊が自民党。 なんでRustのスレで統一教会が出てくるんだ…
統一教会に限らずカルトの関心は政治権力だから判定条件はis_自民党()じゃなくis_政権与党()だろ
必ずしもすべての政党が実行部隊機能を実装してるとは限らないけど
自民党を取り換えればカルト問題が解決するみたいな発想だとデバッグに支障がでるぞ >>167
ナイーブな考え方だなぁ
宗教法人を解散させればカルト問題は半分解決なんだけとなぜ解散させないのか少しでも考えたことある？ Rustが適材適所なのはゼロではないと承知の上で「Goが適材である場所が多い」という話だろ >>168
よっぽどナイーブな考え方で草
中世の人かな？ >>151
要素数Nの時に何らかの処理Aに掛かる時間をf(N)とするとき、
O(g(N))は、ある N0 があって、N0 より大きな どんな実数 N に対しても、
f(N) / g(N) < アルファ
が成り立つことを意味し、「押さえられる無限大」、といい、
ランダウ記号(の一種)、または、ラージO 記法という。
だから、O(N/2)=O(N)であり、O(N)+O(1)=O(N)である。 >>175
[補足]
このことは、
f(N) = O(g(N))
とも書く。以下、厳密性はないが、理解のために書いておけば、
f(N)=O(1)とは、大まかに言って f(N) = b
f(N)=O(N)とは、大まかに言って f(N) = a・N + b
f(N)=O(N^2)とは、大まかに言って f(N) = a2・N^2 + a1・N + b
を意味する。だから、
f'(N)=O(N/2)とは、大まかに言って f'(N) = a・N/2 + b のような意味になるから、
a' = a / 2 と書いてしまえば、
f'(N) = a'・N + b となり、f'(N)=O(N)と言えることが分かる。
f''(N)=O(N)+O(1) は、大まかに言って、
f''(N)= { a・N + b1 } + b2 = a・N + (b1+b2) であるから、
f''(N)=O(N) であることがわかる。従って、
O(N/2)+O(1)=O(N)
であることが分かる。 >>176
[補足2]
また厳密性を無視して大体で書くと、
f(N)=O(g(N))
の場合、f(N)のNに関する最大次数がg(N)と同じ、という意味。
だから、g(N)がNに関して k 次元だと、f(N)もNに関して k 次元、という
ことを概ね意味する。だから、大体、
f(N)=O(1) とは、f(N)=b を意味する。
f(N)=O(N) とは、f(N)=a * N + ・・・ を意味する。
f(N)=O(N^2) とは、f(N)=a * N^2 + ・・・ を意味する。
なので、f(N)=O(N/2)+O(1)だと、
f(N) = a・N/2 + b
みたいになり、これは、N に関して 1 次関数だから、Nに関する最大次数は 1。
だから、O(N)ということになる。 >>177
[補足3]
グラフを描いたときにどこかで無限大になるような特殊な関数以外は、
「テーラー展開」で近似することが出来て、
f(N)=a_k・N^k + a_{k-1}・N^{k-1} + a_{k-2}・N^{k-2}+・・・+
a_1・N + a_0 + (少しの余り)
のように書けることが知られている。
それを知っていれば、理解の助けになる。 O(N) とかを最近知って説明したくてたまらないんだろうなw すまない、彼はド素人だから見逃してやってほしい
山奥で一人でプログラミング勉強中なんだろうね
情報系学生や職業マが一ヶ月目に覚えることを皆に発表したいらしいんだｗ 4ヶ月で教えたいこと
1 実数クラスは複素数クラスを継承しない
2 実装継承だろうがinterface継承だろうがオーバーライドは遅い
3 オーバーロードは速い
4 templateも速い Stroustrup氏の名誉のために補足しておくと、発端？の120の記事は
Software Development for Infractructure（インフラストラクチャ用のソフトウェア開発）
ってタイトルで、vectorとlinked listの比較を出してるセクションの見出しは
Access memory less（メモリアクセスは少なく）
で、書き出しは
When I first wrote microcode to squeeze the last bit of
efficiency out of a processor, a good rule of thumb was that
the system could execute nine instructions while waiting
for a memory read to complete.
（私が初めて効率を追求したマイクロコードを書いたときに目安にしたのは、
システムが１つのメモリの読み取り完了を待つ間に９つの命令を実行できるということだった）
インフラとかファームウェア向けに開発する時はポインタ（間接参照）使うとオーバーヘッドが大きいから
多少非効率に思えてもvector使った方がいいよって内容になってる
端的に言ってしまえば適材適所の話でアルゴリズムとかオーダは関係ないはず（全部読んでない）
余計なこと教える前に読解力を鍛えてやってくれ >>183
おいおいまた誤訳君かよw
お前も読解力鍛えろ
英語が多少不得意だとしてもパラグラフ全体を読めばそんな訳には絶対ならんだろ 昔のCPUでアセンブラの経験あると
間接アドレシングなんか、クロック数かかり過ぎてアホらしいから、
そういうレベルの話だろ
ただ、この記事は２０１２年で、パイプラインやキャッシュの話も出てる 最近の自動翻訳は分かりやすくて優秀過ぎる
マシンのアーキテクチャやプログラミング言語にもよりますが、ベクターはNの値が小から中程度であれば最適という答えになります。
8Gバイトのノートパソコンで実験を行ったところ、Nは50万よりはるかに大きいことが分かりました。
図1の赤線はリスト、青線はベクトルでかかった時間を示しています。
これは微妙な違いではない。X軸は10万要素単位、Y軸は秒単位です。
つまり、「小さなリスト」に対しては、リンク構造よりもベクトルの方がリストの表現として優れているのです。
：
インフラアプリケーションの開発者は、コンパクトでアクセスパターンが
予測可能であることが効率化に不可欠だと言っています。
消費電力はメモリアクセスの回数にほぼ比例するため、
赤（リスト）と青（ベクトル）の線は、スマートフォンのバッテリーの消費量や必要なサーバーファームの数の一次近似値です。 自民党の問題点は、統一教会とつるんでるのがばれても縁を切らず、共存共栄の道を模索するとドヤ顔で記者会見したこと。 >>170
Linuxドライバーはオープンソースが好まれるから、
Rust製ドライバ作成は仕事ではなく趣味プログラマが細々とやるんだろうな
ただ働き奴隷言語でOK LinuxでもRustイキリ飛ばし記事が出て来るだろう
数字のカラクリが無いかどうか皆でTokeiしような 最新のLinux Kernel 6.1はRustyというコード名前だし。
Rustに全振りしてるのでは？ LinuxはC++との相性最悪だし、Rustへ移行するしかない。 LinusのドSでただ働き奴隷がどれだけ頑張るのか
おらワクワクして来たぞ！
早くTokei見たい！ 見せてもらう、イキリRustの全振り移行とやらをw コード名前には突っ込んでこないのか。
せっかくご用意したのに。 GoはNSAのメモリ安全公認言語だしイキリゼロ
堅実だわ 名前でイキレてると考えてるRustが惨めでならない >>195 Goの何が良いのか分からないが、したたかだったのは認める
>>122 なんでこんなに差がついのか？
>>169 これが答え 言語仕様の優劣でイキリマウントしてた俺たちが需要を勘違いしてただけ >>198-199
いろいろ立場によって、Goは食わず嫌いで済まされないか...
そのうちに、やってないとGoを目の敵にしていると疑われて、
こっちがイキリ判定されるから コソコソRust
イヤイヤRust
なのに愛され言語No1←あっ、 >>201
処世術にGoというのは絶妙なポイント突いてる
PythonだとAIで突っ込まれて実力が露呈するから
Rustは今年印象を悪くした ＞PythonだとAIで突っ込まれて実力が露呈するから
知ってたわ
Rust仕様マウントerはそういう実力の無い奴 はちみつオジは仕様マウントerですか？
はちみつオジは仕様マウントerですか？ goのメリット
文法の単純さ
ライブラリ、リントなどのエコ環境の良さ
ビルド速度
バイナリ配布の簡易さ
これだけあれば十分だろ。 各言語の複雑さの総和は大きい
だから、一つしか選べないとかそれ以外と戦争とかしない限り、単純さは現実的でない >>185
そんなことはない。486以降では、昔から間接アドレッシングと
インクリメントのクロック数は同じだった。
1. 間接アドレッシング(p = p->next) :
mov ebx,[ebx+メンバのクラスの先頭からの相対アドレス] ;1クロック
2. ポインタのインクリメント(++p) :
add ebx,クラスのバイトサイズ ;1クロック
#Stroustrup氏はキャッシュの話をしている。 >>178
[補足]
なお、O(・) 記号では、log N はよく出てくるが、log x は x=1の周りでは
次のような無限級数で(近似的に)展開できる。
log(1+x)=x-(1/2)x^2+(1/3)x^3-(1/4)x^4+・・・
無限級数なので、xの最大次数は、無限大。
だから、178 では、k が有限で止まっている形になっているが、本当はそうではない。
また、上記の展開式を見ると、正負の符合が交互に出てくることが分かる。
そんなに単純ではないが、このことも影響して y = log x は、dy/dx → 0 ( x → 無限大 )
であり、傾きが極限的にどんどん 0 (水平) に近付いていく。
つまり、N = 1 + x が変化してもほとんど変化しなくなる。
だから、log N は、「みなし定数」的と言われることがある。
なお、この時、逆関数で考えると、x = exp(y) であり、
y = exp(x) のグラフを描いて、y = x で(対称的に)折り返すと考えやすい事がある。 >>213
なお、この展開式にもウソがある。
それは、log(1+x)で、その展開が正しいのは、|x| < 1 の範囲に限られることを
言及せずに誤魔化していること。
しかし、x → ∞で、dy/dx → 0 の証明は出来る。それは、
y = exp(x) が、dy/dx → ∞ だから、dx/dy → 0 であり、
逆関数 y = log(x) だと、dy/dx → 0 であるから。 // 高校数学を演説したいんよね
それ聞かされる周りの高学歴の気持ちになってみてほしい >>205 それ分かる
SO/HN/rで仕入れた俄か知識をひけらかすために、質問と回答を自演するパターン＞Rust仕様マウントer
厚かましくも、スレ民に教えたい、と思ってるんだろうけど姑息すぎてスルーしてる
時々引っかかるカモがいる様に見えるけど自演なんだろうな
>>206
自分で考えろ >>215-216 俺も分かる
数学科卒でRustのメモリ安全性は(自称色々条件つけて)数学的証明付きだと吹聴してた実力の無い奴がいた
情報系院卒だったかな >>208-209 なるほどね
加えてGCC LLVM以外の独立系native codegenにしては高速なバイナリを吐く様だね
独立系と言ってもGoogleなんだから当然っちゃ当然か 迷惑オジ達に共通してるのは論理的思考レベルの低さ
読解力がない
要点をつかめない
主張を簡潔にまとめられない
全部原因は同じ goユーザとRustユーザは言語に求める性質が違うから住み分けたほうがいいかも
goも少し触ったことがあるけど型の表現とエラー処理のサポートが物足りなくてRustに流れた
例えば標準パッケージioのReadWriteSeekerとかReadSeekCloserは自分の感覚だととても気持ち悪い
（多少文法が複雑でもRead + Write + Seekみたいに足し算で表現したい）
ただgoの文字型のruneは中二っぽくて好き
go2もpython3みたいに大変革になるのかな
※goは長いこと使ってないから情報が古いかもしれない とりあえずここはRustスレなのでGoの話はよそでやってくれ >>219
たしかにRustよりGoのが速いベンチマークがあったな
>>220
この人5chがちら裏なの理解する論理的思考レベルがない
>>221
また中二っぽく可愛がってもらえよ
Go language part 5
https://mevius.5ch.net/test/read.cgi/tech/1645915400/390
390: デフォルトの名無しさん sage 2022/06/15(水) 05:30:30.87 ID:l/JMV/GH
goはそもそもエラーを扱う気概にかける言語だからどうしょうもない
毎回いちいちエラーコード返すのが作法とか何時の時代だよって感じだ >>147
理論は事実に立脚して組み立てられるものであって理論を組み立てればその通りに事実が動くわけじゃない。
理論の正しさは実際にそうなっているということによって証明しなければ想定の中でだけ正しくても意味ない。
実測は要る。 (少なくとも工学的思想では。)
想定のほうで Stroustrup が誤っているという主張は (その主張が妥当かどうかは別として) わかったが、
だからといって実測の重要性を貶めるのはよくないな。 ＞たしかにRustよりGoのが速いベンチマークがあったな
ボロ負けじゃね？しかもマルチスレッドがGoの独壇場じゃねぇか
誰か本気だせよ
次世代言語27 Nim Zig Pony Carbon Gleam
https://mevius.5ch.net/test/read.cgi/tech/1659660050/81
81: デフォルトの名無しさん(ﾜｯﾁｮｲ 1e66-JEMU) sage 2022/09/28(水) 19:48:23.69 ID:Tun9Z/EC0
Nim追加
Language x10 x100 x200 x400 Memory Comment
--------------------------------------------------------------
Zig 0.118 1.073 2.113 4.203 3.2MB (std.HashMap, caller-hash by Context(Fnv1a_64))
Nim(clang) 0.211 1.171 2.245 4.372 4.2MB (CustomCountTable,LTO,ARC,caller-hash) New
C(gcc) 0.136 1.146 2.271 4.531 2.0MB (optimized.c,binary IO,jemalloc,O4,LTO)
C(clang/LLVM) 0.137 1.147 2.280 4.544 2.0MB (optimized.c,binary IO,jemalloc,O3,LTO)
Go 0.152 1.233 2.428 4.832 3.9MB (caller hash,better loop)
Go 0.164 1.346 2.654 5.279 3.8MB (caller hash)
Rust(LLVM) 0.154 1.425 2.838 5.674 2.6MB (optimized-customhashmap,O3,LTO,caller-hash)
以下、caller-hashではない
Go 0.085 0.366 0.693 1.319 61.9MB (parallel.go,reserve 65536/2)<--マルチスレッド
Nim(clang) 0.218 1.255 2.401 4.691 4.2MB (CustomCountTable,LTO,ARC) New
Zig 0.162 1.493 2.970 5.935 4.6MB (std.StringHashMap)
Go 0.182 1.563 3.063 6.097 3.8MB (customhash.go,reserve 65536)
Rust(LLVM) 0.214 1.725 3.396 6.715 3.5MB (optimized,fxhash,O3,LTO)
Nim(clang) 0.316 2.241 4.371 8.633 4.2MB (optimized.nim,std/CountTable,65536,LTO,ARC,FNV) New
Nim(clang) 0.332 2.387 4.652 9.152 4.2MB (optimized.nim,std/CountTable,65536,LTO,ARC) New >>224-225
はちみつオジが、仕様マウントerなのか、それともベンチ実測で天才プログラムを出すか、の流れキター ギャンブルって短期的には実力より運だから
実力主義やめないと短く簡潔にまとめることはできない >>211,227
えっ？
このポエオジ文って、はちみつオジが逃げ出す時の自演だったかよ！ >>223
Goが合わなかったからRust使ってるって言うてますやん
Go2出たらまたちょっと試すかも
このスレでGoの宣伝してる人は他の言語のスレでRustを宣伝してた人と同類なんだろうけど
goのどこを宣伝したいのかいまいち伝わってこない
並行処理が書きやすいって辺り？
「Rust→メモリ安全（ドン！）」みたいにもう少し分かりやすくしてくれないと（どのみち迷惑だけど…） >>231
ライブラリではなく言語ランタイムに統合されてるってのは大きいだろ
並行処理を意識してるだけで勝手に並列になるってのも強みの一つ 俺も知らなかった、裏切られた
androidの数字とか結局は誘導だったんだな >>228-230 なんと
はちみつが否定しているから完全スルーしてたけど内容に一理あるのか？
ID:7EPFyoxp
ID:u3ABxrNN
ID:/g1tYkuT ID:Pt3aaRaQもはちみつだな
>>187 >>207
わけわからん >>235 流れを見直したら、誘導なんて甘くない、印象操作とはつみつ効果でだましに掛かってる
愉快犯にもほどがある、だましの手口↓
Rust part17
https://mevius.5ch.net/test/read.cgi/tech/1665063793/855
855: デフォルトの名無しさん 2022/12/07(水) 00:21:26.68 ID:rpgrLTt2
AndroidもRustで書かれてたのかよ！
しかもRustの部分は脆弱性の報告０件って恐ろしいほどの安全性だな……
これマジでRust一強の時代がくるかも……
Ubuntuにデフォルトで入るまで待とうとのん気に構えてたけど急いで勉強しないと……！〆(.. )ｶﾘｶﾘｯ!!
https://japan.zdnet.com/article/35196972/
https://mevius.5ch.net/test/read.cgi/tech/1665063793/856
856: デフォルトの名無しさん sage 2022/12/07(水) 00:35:34.36 ID:21cwGaas
>>855
まじ？
というか20%がrustってえぐいな
https://mevius.5ch.net/test/read.cgi/tech/1665063793/864
864: はちみつ餃子 ◆8X2XSCHEME sage 2022/12/07(水) 09:19:24.95 ID:vqEtcxl0
どれがいい感じに発展するか事前にわかるもんではないからな。 狙いとは違う方向で結実することもあるし。
色々やっておく (それが出来る環境を用意する) とどれかは上手くいくし、上手くいかずに消えるものも多いってだけのこと。
https://mevius.5ch.net/test/read.cgi/tech/1665063793/866
866: デフォルトの名無しさん 2022/12/07(水) 10:39:11.42 ID:KNXoSnHr
>>855
結果だけみると凄まじい
システムプログラミング関係の置き換えは案外急速に進むかもしれんね 手間さいてTokeiかけてくれた人たちには感謝だわ
>>6-7,10
>>97-98 5chなんてそんなものだが完全にやり過ぎだな
「はちみつ効果」にやられてしまった
C++スレの住人は知ってるんだろうと思うと腹立つ あと複おじ軍団なんて冗談だと思ってたけどちゃんと見ないとだめだな はちみつ効果のネーミングセンスw
複おじ誕生の荒れたスレ進行をすっ飛ばさずに読んでだら防げたのだろうか
5chの洗礼にあった そもそも次世代言語スレがひどいもんだった
Goスレの方は活性ゼロだけどそれが正常なんだろうな 逐一見てたわけじゃないからはちみつだったのには驚いたけど、
中立の立場で一応言っておくと、所有権の複製だったかの言葉尻を
からかってたのは旧Rust民の方なんだよ
何も知らない新Rust民が巻き込まれてやり返されたから5chの洗礼と
言っているけどね、根本は両成敗事案
今年の内にネタ晴らししたのが幸いくらいに考えてもバチは当たらない じゃあ俺も年末大サービスで消化だぞ
あと旧Rust民は関心ないだろw 統一教会は日本で、ゆとりある教育を提唱しているが、韓国では全く逆のことを言ってるからな。
騙されるなよ。 何を解決しようとしているのかさっぱりわからんが「はちみつ効果」だけ覚えておくし個人に遺恨とか無いから
そもそも行き当たりばったりだし舐めプは許さないから何も変わらんよ 誰がどうって属人的な話ばかりでさっぱりわからん
rustについて話すスレじゃないのここ カラクリがどーのこーの言ってる子の自演でしょ
やっぱワッチョイないとダメだなもうこのスレ
・複オジ
・高校数学くん
・カラクリくん
こいつらが張り付いてる限りはもうだめ >>252
人や団体もシステムの部品だと思ってる奴にとってはそういうのもRustの部品じゃないの知らんけど Rustは基本的に奴隷言語って理解できないと難しい 誰でも触れんやろうから奴隷言語として使うのは無理やろ やっとアベノミクスの成果が出てきて物価が上がり始めた。 RUSTとCOBOLだとどっち勉強したほうがいいですか？ 今のCOBOLerが死んでもCOBOLは絶滅せず生き残ってるよ COBOLは確実に先細りだけど需要低下より人材供給量低下の方が激しいことに賭けてそれが当たれば最低限食ってはいけるだろう
ただしどれだけ供給減っても低賃金は確定している >>231「Rust→メモリ安全（ドン！）」
からの
>>263 Rust圏外
イキリ仕様マウントer、ふかし過ぎたな、負け惜しみポエム早う 23日を目の前にしてこんな珍活やるなんて
こいつらほんとに映画完成を祝う気があるのか 正直、今のRustよりZig0.10.0のが圧倒的に使いやすい😭 いえーい
lowerbound
let mut id: usize = vec.binary_search_by(|it| if it > &i { Ordering::Greater } else { Ordering::Less }).unwrap_or_else(|it| it); Rustの企業ニーズがまだまだ圏外なことなんてRust使いなら分かりきってることなのにそんなマウント取った感じで語られても >>267
zigはcomptimeでマクロを撲滅したのが佳き
rustと同じくnull安全だし パーフェクトRust、くるーーーーーーーーー
パーフェクトRust
古川 正寿フルカワ マサトシ(著/文)
発行：技術評論社
B5変型判 608ページ
定価 4,200円+税
ISBN978-4-297-13322-1 >>277
宣伝乙。
5chでイキリRustしてたのはお前だったか。 パーフェクトに知るために608ページも知らなくちゃいけないなんて、、前評判なのか何なのか知らんけど
まだ読んでもない・読まれても無い・好評にもなってない本の宣伝とか、ガッカリだぜ著者 >>282
まずは読まれないと良い評判も悪い評判もつかないんだぞ。
まずは存在を知らないと読まれないんだぞ。 「ちょっと宣伝させて下さい」ﾍﾟｺﾘ
としとけばいいものを 技評でパーフェクトシリーズなら
いろんな雑誌や書籍に宣伝載るだろ
あの日本語訳のような酷い出来じゃなければ
他言語から来たやつが日本語で読める入門書としてそれなりに読まれるんじゃねーの
でも発売2ヶ月以上前からこんなところで宣伝するようじゃ中身には全く期待できない >>282
プログラミング言語C++第4版は1000ページ超えてたぞ。
あれぐらいの名著ならいいんだけど果たして、、、 今どきは、ネットでどんどんぐぐって掘り下げてく方が効率いいだろ モルフィーワン無関係のふり事件とかまだ忘れてへんぞ。 へ、弊社には関係ございません・・・
・・・って、お前、巻末にしっかり申込書載せてただろうが。 技術評論社のネガキャンしてるのはどこの出版社だろうねぇ ちゃんとした本で勉強せずネットだけで勉強したプログラマーの大半が役立たずなのは事実 調べたい事があったら、内容も見ずにそれらしい本を次々買うのか 技術評論社って時点でちゃんとした本とは言えない。
分かった気にさせる系ブック。 >>296
たった4千ちょっとじゃん
論文だとうん十万で企業さん買うことあるし 技術評論所って時点で却下だ。
マイナスにしかならん。
関わったら負け。 会社の質は知らんが技術書の質としたら
日本語書籍のなかじゃ技評はまともな方だよ
Web+DBのシリーズなんかはそこそこ良い本がそこそこある
パーフェクトシリーズは3～4冊読んだことあるがどれも可もなく不可もなくって感じ 予約販売するなら目次くらいは見せてほしいです（アマゾンの紹介文は校正が甘くてちょっと心配になる）
シリーズ物だと本棚に飾るために買う人もいるのかな アマゾンは何年か前から目次データを扱わないことにしたはず 入門ならオライリー本でいいよね。
パーフェクトっつうくらいだからそれ以上の内容だろうな？ しゅうわとぎひょうとしょうえいしゃ！
だめなやつさんじゅうし！！ ギヒョーの本なんて嘘しか書いてないだろ。
読めば遠回りになる。 Rustをやる前にCをやれ、pthreadをやれ
この辺の経験がないとRustの旨味はわからないし、経験があればRustは本じゃなくてbook等で十分習得できる >>303
パーフェクトは言語要素を薄く広く一通り網羅してますよくらいの意味 今のところ入門者向けはオライリー本
脱初級者向けにはRust for Rustaceans
この2冊がド定番
The Bookはオライリー本読んだ後の復習用 amazon見てみたら”あの日本語訳”もあのまま出版されてて笑った
校正とかしなくても出版されるんだな オライリー本って
カニの絵のある、プログラミングRust第2版
ってやつでいいよね？
買ったけどこれで入門者向けなのか。難しい >>313
それだよ
オライリーから出てるRustの日本語書籍は今のところそれの第1版と第2版しかない
入門者向けってのは他言語経験者がRust入門時に1冊目として読むべき本という意味 >>313
入門者向けっていうか言語機能を一通り知りたい人向けかな
簡単なアプリを作りながら徐々に学びたいみたいなタイプの人には向いてないとは思う Comprehensive Rust (by Android team)
https://google.github.io/comprehensive-rust/
どの項目もめちゃ簡潔な説明しかないけど必要な項目をよくおさえてるので短い時間でRustをざっくり把握したい人向き >>317
発売前から星5つけてるのは技術評論社と断定して良いだろ。 オライリーの並列処理の本買ったぞ
頑張って読むか~ オライリーはステマしないから良いですね。
技術評論社は駄目ですね。 >>318
>簡単なアプリを作りながら徐々に学びたいみたいなタイプの人には向いてないとは思う
こういうタイプに向いてるRust入門1冊目向き本ある？
どれも1冊目を標榜してても現実には2冊目向きじゃない？ オライリー本かThe Book以外で1冊目向きでそこそこだと思ったのは「コンセプトから理解するRust」ってやつだな
細かい表現で正確性に欠けてたり不必要に他言語の解説がされてたりダメなところもあるけど
Rustを理解するために必要な概念がわりかし平易に説明されてるのでオライリー本のハードルが高いと思うようなら読んでみてもいいんじゃねって感じた たぶん買わないからつける星がない
プラスに働くかは分からないけど多少はRustの宣伝になるだろうし
よくわかってない意思決定チームが引っ掛かってRust採用するかもしれない zigがバージョン1.0になってrustと比較して、rustが優れてるようであれば、c++からrustに移行するかな パーフェクトRustの著者の古川正寿でググったけどRustの実績皆無で草 「読んでいませんがステマ反対の意味で星1です」って書いておけば良いんじゃないの？ java使いのrust本なんて見る前から星マイナス100だってわかるわ 自分で「パーフェクト」などという王冠を載せてしまう所がなんとも。 在庫がない物を売ったり現金がないのに買ったり
データのない感想を言ったりまだ法的根拠がない悪と戦ったりする現象 それよりなんか、日本でRustの資格を作ろうとしてるやつがいるっぽいな 資格を持っていないRust使いはモグリにされるんだろな。
すぐ獲っとけよお前ら。 本のタイトルってほとんど編集が決めない？
相談があるケースがほとんどだけど全然違うタイトルになるよ。 ステマして申し訳ありませんと言えない病気にかかってるようだな。 >>344
自分も経験あるけど「これはちょっと大げさに言い過ぎで恥ずかしい」
と思っても、こっちの方が売れるからって言われて押し切られることあるよな >>346
まぁ…そうおっしゃって頂けるなら…お任せします、みたいになるよね エンジニアとしては正確に命名したくなっちゃうんだけど
そうすると潜在顧客にリーチしないって言われる
なんでパーフェクトも「もうRust本も結構出てるんで、決定版的な感じで差別化しないと売れませんよ」って編集がゴリ押ししたのかな？とか 普通にパーフェクトシリーズってだけだろ... 頭大丈夫か？ 妙なJava使いがパーフェクトRustかよ。
馬鹿にしすぎ。 オライリーからもC/C++やったことないぜって人のRust本出てるよ
他の本でそこそこ有名な著者ではあるけど 出版社で言えばオームのRust本も残念なやつだったぞ gihyo に恨みを持つ人物... あっ
ttps://blog.goo.ne.jp/ikunya/e/95ff46d785fa70c9a8f69a7aa9eb7508 >>356
うわーこれ知らんかったけど両方ともめちゃくちゃ闇が深いな
あわしろあわしろ言ってたのはコレだったのか
嫌な世界だな これ見たら萎えた
https://togetter.com/li/1084225
Twitterってもう公共の場なんだよね
相手がどうあれそこでこんなやり取りしてたらそりゃ批判されて当然
CoCとか語る資格ないわ 今日は技術評論社の新たな闇が見れて勉強になったわ。
ダメな出版社は何やってもダメだな。 >>364
いやいやどう考えても君が技評に恨みをもつ本人やろ
少なくともこのスレでは このスレ、この板で圧倒的に勢いあるけど
ひとりでスレチな話してるんだな linux-6.2-rc1に新規に追加されたファイル
rust/build_error.rs
rust/kernel/build_assert.rs
rust/kernel/static_assert.rs
rust/kernel/std_vendor.rs
rust/kernel/types.rs
rust/macros/concat_idents.rs
rust/macros/vtable.rs
samples/rust/rust_print.rs 志賀慶一と岡部健戦わせたらどうなるん？
粘着力で毛の壁が上回ってる気がするけど どうでもいいLinux/リーナス関連ゴシップを書き散らかすのもあのキモチ悪いコミュニティの人かと思うと汚コード以上に嫌悪感を感じるな >>370
rustに対してネガティブな内容だったからここで内容は書かないが、ちょうど今日これの開発秘話を聞いてしまった 400スレ近く消費してるのに読む価値のあるレスが1～2個しかない
あとはアンチとステマと誤訳とクローン蜂蜜 >>380
その御方はUbuntu JPの中の人だぞ
頭が高い >>381
その価値というのが量的だから
ソースコード読めない人を参加させるためにわざと定量化してるようなもの asserts、print、types、identという文字面だけで、ム板人は中身が透視できる。
したがって、開発秘話などと言ってるのはム板人ではない。 rustは標準ライブラリが貧弱ってところが唯一引っかかるな
他は今のところ文句ないんだが
goとrustだとどっちのほうが標準ライブラリが充実してるのかな ライブラリの充実感を出すにはLLVMなコンパイラなんかよりも
C/C++へのトランスレータかインタプリタ作った方が直感的だろうね
わかりやすさを無視した実質ではコンパイラが正しいんだろうけど >>390
Goに決まってるだろ
libcにすら依存してないんだから JavaのAWTが標準ライブラリを流行らせた
AWTを潰した奴が標準ライブラリを潰した またスレが一つ死んだ。
行こう、ここもじきクソレスに沈む。 くだらないことを長文で書き続けるやつが湧くとスレが死ぬ 板の他スレのようにワッチョイがついてないせいだろ
このスレはワッチョイついてないんだから荒らしくらいガマンしなさい >>401
きみが考える安心安全を実現する方法を晒してくれ
多分Rustで実現できるなら他の言語でもできると思うけど >>401
掲示板ってどういうものなのか知らなさそうな質問で草 >>390
そもそも低レイヤー言語でプログラムするのに、標準ライブラリに頼りまくるのが間違いだわ。 >>390
充実したリポジトリがあって cargo.toml に一行足すだけでライブラリが使えるんだから
そのライブラリが標準ライブラリかどうかなんてどうでもいいだろ。
標準に入れたくなるほど有用なら標準に入ろうと入るまいとそれなりに保守されることが期待できるし。 標準ライブラリが充実してるということはそれだけ本体の運営者に負荷がかかるということだからね let mut vec: Vec<usize>で
vec.iter_mut().map(|x| *x += 1)
みたいなことはできないの？
こんなふうにしないとだめ？
let mut vec:Vec<usize> = vec.iter_mut().map(|x| x + 1).collect(); 会社でやってるとサードパーティのライブラリはライセンスだったり許可もらったりするのが面倒 >>409
キミのやりたいことは多分こう
let mut v: Vec<usize> = vec!(1,2,3);
v.iter_mut().for_each(|x| *x += 1);
println!("{:?}", v); // [2, 3, 4] >>400
出たよワッチョイ自治厨
こいつが来るとスレが終わる おまえだけワッチョイスレたてて移住すりゃいいだろ
考えを押し付けるなカス 確かにidって中途半端だよなワッチョイと言わずip表示させようぜ C++は経験あるけどRustはまだ触ったことない
RustってC++より簡単？
言語仕様の超複雑なC++よりは使いやすそうに見える >>413
まじか
でｷﾀ━━━━(ﾟ∀ﾟ)━━━━!! >>413
本当にありがとう
for_eachしらんかった
let mut vec: Vec<Vec<usize>> = vec![vec![1, 2, 3]; 3];
vec.iter_mut().for_each(|x| x.iter_mut().for_each(|x| *x += 1));
for i in vec.iter() {
println!("{:?}", i);
}
//[2, 3, 4]
//[2, 3, 4]
//[2, 3, 4]
実現できて助かるヽ(´ー｀)ノ >>424
forループじゃなくイテレータのメソッドつかいたいならinto_iterでmap
for_eachでmutateするのはbad practiceなのでやめようね >>417
c++より簡単と言えば簡単。
言語仕様をちゃんと確かめようとするとc++みたいに生の書き方ができない分、大変かもね。 最近BTreeMap使いすぎて困る
２分探索必要なとき脳死で使っちゃう
なお重複 食いチン棒！万歳
チンコーマンの提供でお送りします なんでお前らRustなんてやってるの？C#の.NETが圧倒的に使いやすいのに
お前ら損してるよ RustやってるヤツなんてC#使った事ないわけないだろ 「なんでRustなんて使うの？」という考えの人がわざわざRustスレに書き込もうと思うのが謎 Rust'erはC++とJava or C# は扱えるイメージ Rusterは大体過去にD言語とか一回はかじってそう >>437
自分がやってきたことに疑念が生じてるんだよ
ひょっとしてC#なんかよりRustやったほうがいいんじゃないか？って
そして言ってもらいたんだよ
C#なんてやめちまえって
どこにでもいるだろ？迷ったとき背中押してもらいにくるやつw キラーアプリの前にセミナーや資格が出てくるのは、売人の世界。
役に立たんよ。 > どこにでもいるだろ？迷ったとき背中押してもらいにくるやつw
みたいなこと言う奴が
> お前ら損してるよ
なんて言うわけないだろ、バカすぎるw 誰も使っていないのに、みんながお勧めする言語。
発売前なのに、みんなが絶賛する書籍。
ダメでしょコレ。 今のご時世、Polyglotなプログラマが求められてるというか、常識みたいな扱いになってるね C#ってC++の代替にはなるけどCの代替にはならない
RustはそのCの代替と成りうる言語でなので
恐らく逆にC++やC#の代替にはあんまり向かないんじゃないかと思う バックエンドデベロッパならlibcは理解してないといけないからcは必修よね C#はRuntime実行前提の言語だから組み込み開発に向いてない とはいえ、WinformやWPF使わないならネイティブコンパイルできるけどね。
.netランタイムない環境でも普通に実行ファイルあるいはネイティブdllにみたてたものして動作する >>457
Rustと同じところに使われてるぞ
そんなことも知らないの？ >>457
それrustがどこに使われてるの？と聞いてるのと同じじゃんかww c#ってフロント組むための言語だよね？rustやc#とは用途が違うのでとっとと出てってください >>458-459
C++はゴミだと確信してたけどRustもゴミってことか
教えてくれてありがとう 大体C言語を碌に触らずにC++をCの上位互換言語を思ってるヤツがホント多い
Cでは**pは必須だけどC++ではそもそもC++で拡張された機能によってそもそも**pを使うべきじゃないし
物理アドレスを触るような場面ではそもそもC++を使うべきじゃない
そしてCの互換言語という点を差っ引いたらC++じゃなきゃいけないって場面は殆どない C言語の開発資産しかない場合、次は上位互換であるC++に行くのが常道になるのが
自然の流れ
しかもRustは新興言語で実績もないから採用は不可 >>465
なんでCもC++もよく知らんのに知ったふうな口きくん？
君はプログラマですらないやろ？ ただのド素人やろ？ そりゃ技術評論社がLinux板から情弱連れてくるからだろう。 Haskell本が売れなくなったからRust売り込むことにしたんだろ。
迷惑な話よ。 C++の話になると途端に饒舌になる老害さん達
スレ間違ってますよww >>471
そう言うのは>>450,465に言った方がいいぞ >>450
>RustはそのCの代替と成りうる言語でなので
個人的にはそうは思えないけどな。
Rustは低レベルが扱いにくいから。 >>473
[補足]
Cは、どういうコードが生成されるかとても分かり易いので安心感が有る。
それに対し、
(Rustは結構頑張って学ぼうとしたが)、Rustは抽象レベルでの意味論は書いて
あっても、最終的にどういうコードが生成されるか分からない(仕様が明確には
書いて無い)事が多い。 >>474
[補足]
Rustの場合、意味論は書いてあるのでどういう結果になるかは一応は分かるが、
結果的に何が行なわれるかは分かっても、どういうコードが生成されるかは
分からない事が多かった。それが分からないと高速化は難しい。
Cだと命令数やクロック数を数えることが出来たがRustでは出来ないと思った。
例えば、引数を渡す時に何回コピー動作が行なわれるかCやC++では分かるのに
対し、Rustでは分からないことが有るように思えた。
論理や意味は分かるが、途中にどういう中間工程が入るか分からないのだ。 >>475;
Cではなくて、C++でも、
TYPE a = 5;
f(a);
と書いたとき、どういう動作がおきるか多くの場合はよく分かって、マシン語で
どういうコードになるかも分かる。コンストラクタがどこで呼び出されるか、
どこでコピー演算やムーブ演算が起きるのか、一応は分かる。
ところが、Rustでは分からない事が有った。
それでは問題を生じることが有る気がした。 JScriptで書いていた支援ツールをRustで書き直そうかなぁ
そうすればwine/proton環境でも個別対応しなくて済むようになるし あ、失礼JScriptってのが別にあるのね
知らなかったわ 組み込みだと、「アドレスへの write アクセスが1回でなくてはならない」
場合がある。アクセスの回数によってハードウェアの動作が変わってくるから。
例えば、あるアドレスに 一回アクセスすると LED が点灯し、もう一回アクセス
すると LED が消灯する、などという動作がある場合がある。
場合によっては、音の PCM の振幅や、モーターの速度調整にそれを利用する可能性があるなど。
この場合、Rustではメモリーアクセスの回数が不明確になって、上手くプログラミングできない
かも。 組み込みでは、
「最適化して後から後れてアクセスする」
「アクセスが時と場合によって省略される」
などが有っては駄目な場合がある。
Cだと結構上手く行く。 2年くらい前はHaskellが世界を席巻してたからな。 >>482
> Cだと結構上手く行く。
アホの子なのかな？w
そもそも処理系の話だからCとかRustの話じゃないだろ >>484
でも、あなたにもC#で組み込みとか、Rubyで組み込みとかやっても難しいのは分かるよね。
それと似たようなことがRustでも起き得そうな気がするんだよ。
C#とかRubyでも、一応、atomicアクセス的な何かは用意されてるかも知れないけど、
そういう問題ではないおきるだろう。 最適化に左右されたくないならちゃんとwrite_volatileとか使えばいいだけの話
memory mapped I/Oの制御なんて当然想定されてるよ MCUがRustを考慮していないから無理。
それだけの話。 >>485
気のせいとかいうレベルで語るなよ... C言語仕様はメモリアクセスの順序を保証しない。動いているのは
ただの偶然だしそのようなコードは仕様外の糞コードでFA Rustは高速化したいときにクロック数を数えにくいのも困る。 しかしCでいいと思ってるならわざわざこんなスレにトンチンカンな書き込みせずに黙って使ってればいいのに
Rustに置き換わって仕事なくなるかも的な心配で攻撃したいとかだろうか
そんな心配しなくても組み込みのCの仕事は当分なくならんよ 既に5chあるいは国民と技術評論社の戦争に発展している。 >>493
変な言語が流行って人類の負の遺産になる前の抑止効果。 >>493
Rustはシステムプログラミングに向いてるってデマのせいじゃね 組み込みでもRustを使えるならRust使うわ。Cは実装依存が多すぎる
正しいコードを書こうとしたらコーディングコストはRustより高くつく 実装に依存しない組み込みとか夢のようなことを言ってるな。 >>498
組み込みは、メモリー関連エラーなんて起きないプログラムも多い。
というか保護モードも使ってないことも多いのでそれ以前の問題。
Lチカなんて、Rust不要。 技術評論社からRustの本が出るだけであって技術評論社自体はRustと関係ない
いい加減に技術評論社発狂ガイジ出てけよ >>501
[補足]
組み込みの世界は「メモリー関連エラー」なんて言葉で語れるほど生易しいものではない。
一つ間違えればハードウェアがICが爆発したりモーターで人が死ぬような世界だったりする。
つまり、慎重に組む。
電線のつなぎ方を間違えれば部品が故障するが、それと同様にプログラムの間違いは
暴走や故障の現象になる。
だから、メモリー関連エラーで苦しむ程度の頭脳しか無いような人は組み込みに向いてない。 >>505
おまえが技術評論社とかいうのをステマしなければいいだけ
RustスレでRustをステマすることのなにがいけないんだ？ ttp://elm-chan.org/fsw/ff/00index_e.html
有名なマイコンや処理系で利用可能な高ポータビリティのCライブラリだが
このレベルのものを実際に書こうとしたらかなり高コスト
Rustのほうが楽かつ確実に動作する MCUを替えたら、回路からすべて変わるのが当たり前なんだよ。
見苦しいな。 組み込みでポータビリティを軽視している奴は昨今のマイコン不足で真っ先に退場するクチだろ
同じチップどころか同メーカーの互換チップすら調達出来ずに、メーカーから変えざるを得ない
こともあるご時世に、特定のハードと特定の処理系と特定のバージョンでなければダメみたいな
前時代的な考えでは話にならない MCUメーカーがRustを考慮していない。
これが全て。 >>512
そうそう。
だから組み込みでRustを使ったらダメ。
C/C++一択。 >>510
現実にC言語版があるんだから、C言語の方が便利だと思うのだが。
現時点でRust版は無いわけで。 >>512
そんな簡単なもんじゃないと思うが。
そもそも論として、ピン番号が変わっただけでも、慎重に設計し直す
必要が出てくる。接続を間違えると大変なことになる。
現実にICが破裂したことがあり、目に入っていたら失明してた。
容易に全く別のICに交換することは出来ない。 そもそも、Rust推してる方がRustを使ったことなくて、否定的な方がRustを使い込んでる。
技術評論社の呼びかけでLinux板から来た連中はプログラミング自体したことが無いので、Rustは組み込みの互換性がCより高いとか言い出す。 >>514
そういえば、「C言語ライクな言語」をサポートしているだけで、gccやclangに
対応して無いマイコンもあるから、Rustなんか到底無理なマイコンも多いな。 組み込みやったことないけどメーカーサポートなんかいるんかね
ABIだけ指定してxargoでクロスコンパイルして終わりじゃないんか？ cargo-c使えば何も問題無く組み込みに使えるのだが、、 素人に毛が生えた程度のコーダーかエアプが知ったか煽りしているだけでしょ そもそも、マイコンで、Rustがなくしたとする「メモリーエラー」で悩むことが無い。 俺はずっとCやC++でプログラムしてきたが、メモリーエラーで悩んだことは
ほとんどない。
うそだと思うかもしれないが本当。
しかも、かなり複雑なシステムプログラムをしてきた。 OSやモバイルアプリの開発も組み込みだよね マイコンだけじゃないよ ARMやRISC-Vはバックエンドあるし処理内容も高度化しがちで
Rustの高速性と安全性のメリットを享受しやすい
>>523-524
おじいちゃん。その辺はとっくに主力じゃないんですよｗ つまり、CやC++でメモリーエラーに悩まされて使いこなせない人は、
そもそも論として俺の脳のレベルにまで全く達して無い。
つまり、生まれつき俺はオマエラより遥かに頭がいいから、Rustを使う必要性が無い。
それだけの話。 >>533
俺がお前より年食っていたとしても、生まれつきお前の脳の1000万倍優秀だから、
関係無い。 >>536
なお、悪いものを批判/非難することは公共の福祉や国益になる。 >>530
ちゃんとしたコーディング規約を遵守してコード書いてればそうそうメモリエラーにはならんはな そもそもRustはメモリ管理を強制するための規約的な言語だし笑
Cに制約をつけただけのドM言語 >>538
世の中にはそれすらできないお馬鹿さんたちがいるのです
諦めるしかないのだ Rust FoundationにARMをはじめ組み込み屋がいる時点でお察しだろ Rustは頭のいい人が頭のわるい人と一緒に仕事するために使うものだと思ってる
頭のわるい人にはC/C++よりRustを使わせたほうがマシなコードを返してくれる
それだけでもRustをプロジェクトに採用する価値が出てくる >>543
いや、頭悪い人を間引いて同じ土俵に上げない為の言語だと思うが
敷居を下げ過ぎてJavaとか悲惨な事になってるじゃん マジでこの世が頭のいい人だけだったらRustなんて要らなかった Rustすら使えないやつなんてどんなコードも書けないよ >>545
JavaはGCあるからメモリ管理気にしなくていいやん PICやH8を引き合いに出している時点でプログラムの想定が違いすぎる
今どきの32bitマイコンのリソースはその辺と比べて1桁以上多い
処理するデータもマルチメディアデータだったりネットワークパケット等の
不安全なデータまで扱わなくちゃならない
もはや初期のWindowsPCに近い内容であり、注意すれば問題ないなど
全く無意味であることはセキュリティ事故が起きまくった歴史が証明している >>545
そもそも頭がよければ滅多にメモリーエラーに遭遇しないからRustを使う必要性
が無いし、Rustは記述量も多いし回りくどいので生産性が低いし、使えない
アルゴリズムも多い。
Rustの存在意義は、使えるアルゴリズムを制限して、記述も回りくどくして
コンパイラを頼りにしてやっと安全なプログラムを書けるような、凡人プログラマ
が生まれつき頭の良いプログラマに少し近付くためにある。 メモリ管理適当野郎共のC/C++出来ます詐欺はほんと酷いよね >>550
変な大企業が馬鹿みたいに人員投入して100人体制とかもっととかで開発やるもんだから出来上がったゴミがカオスコードになってるとかそういう話 >>554
カオスコードでもGCでメモリリーク最小限で動くならいいのでは？
GC稼働を許す製品の話をしてるつもりはなかった >>554
GAFAMみたいな大企業は技術は無くても株価だけ高騰するから、金に任せて
大量の人員だけを頼りに出来るから、数百人がかりでバグだらけの使いにくい
巨大サイズのプログラムを作ってるね。
技術は無いが人だけ入る。凡人プログラマを大量に使って大量のCPUパワーを
使ってPC-9801時代のJG程度のOfficeを作って悦に浸ってる。 >>553
ただ、俺はそれに該当しない。
そういう人も居るというだけの事。 てかこういうのが日本の競争力を落としているんやなって ガベージコレクション使っていいならそら楽ちんですわ
どんな汚コードでも動けばいいんだから
ガベージコレクション無しだと例外処理の例外処理の例外処理を跨いだりして有り得ないところにメモリリーク起きてるなんてことがザラ、どんなに頭よくても絶対に気づけない 気をつけて運転していれば事故は起きないんだから安全運転なんか必要ない
事故るやつは無能だけど俺は違う
こうですかわかりません >>560
車の運転は一発勝負で失敗は一瞬にして起こるしテストすることも出来ない。
それに対して、プログラミングは事前にテストできる。
特にユニットテスト、モジュール別開発という手法を使えばバグはほとんど消せる。
だから十分にバグの無い安全なプログラムが作れる。 >>561
ほとんどで許されるクオリティの製品を作ってるの？ Rustは仕事でしか使わない
趣味ではC++一択ですわ >>562
Rustは、「メモリー関連エラー」を防げるだけで、バグはいくらでも入る。
Rustも、下手な人がプログラムするとバグは100個でも入るし、不安定で
(その人の頭脳では)エラー箇所が見つけられないバグも入り得る。 それとGC有りはGoとKotlin&Swiftや
Goは最強過ぎる >>545
間引きまくってたら募集が集まらないし賃金も上がる
質の悪い土方人間をも上手く使っていかなきゃならない
質の悪い土方の書いたコードでもrustなら厄介なメモリバグ無く論理部分のフィードバック、デバッグに集中できるというメリットがある RustはCの置き換えくらいにしかならん
質の悪いPGが入り込まない分野じゃねえかなあ・・・ だからWebでRustやってる奴は馬鹿
Cとpthreadの経験もないやつはRustやらない方がいいよ >>561
Rustでモジュール別開発、ユニットテストするのが一番いいんじゃね？
てかステマステマ言ってるやつ居るけど出版社がプログラミング言語のプロパガンダしてなんの得になるんだよドメインが違うやろ
出版社なら勝確になった言語の本を出すだけでいいはず
ステマで特定言語を覇権に押し上げても他社が解説本出すのを止められないから独占できる利益とかどこにもない >>571
土方じゃないのってなんだよ
フロント設計用言語か？ >>543これだな
頭の程度の低い人なら安く雇えるから開発費を抑えられる
c/c++をまともに使えるやつの人件費は高すぎて困る まあ1Mにも満たない規模の組み込みでrustはいらんわな。
数GBかつメモリ使用量を気にするって領域以外はほぼ必要ない。 >>574
ArduinoでもRaspiでも、Cだとそのまま単純に理解できて便利だな。 >>568
ところが、Rustの安全性は大規模プログラムで無いと真価が発揮できないから、
帯に短し襷に長し状態。
Cは小規模プログラム向けで、大規模プログラムはC++だから。 >>576
多分C言語 + 一部アセンブラかと
洗濯機・掃除機・調理家電の組み込みソフト開発
組込みソフトウェア開発の経験(C言語他，モデルベースソフト開発)
https://www.hitachi-gls.co.jp/recruit/career/recruit/pe2.html >>568
組み込みって分野は、基本的に微分積分やベクトル、論理回路、複素数などが
普通に出てくる世界だから、頭脳レベルが一般プログラマより元々高い。
だからもともとメモリーエラーで苦しんだりする人が少ない。
なので、Rustの出番が無い。 >>583
その一般レベルプログラマと一緒に仕事しなきゃいけないときには頭脳の高い人も仕方なくRustを使うのでは？
社会活動ってマジで頭脳の高い人が損する世界だわ、一般レベルプログラマは消えてもらって頭脳の高い人集団でCだけ使わせてほしいわ 好きでRustを使ってる人なんてこの世に居ないと思うよ
みんな納品先や上からの命令でイヤイヤRustを使ってる フロントの意味知らないやつとか
バックエンドの意味知らないやつとか
ホントなんなんこのスレw >>583
スマホに使うチップのコードを書いてる知人が何人かいるが頭脳レベルが高いとか全くないわ
Fラン文系新卒で3ヶ月の新卒研修後に客先派遣されるような末端プログラマーに比べたらそりゃ頭脳レベルwは高いがな rustはやってるとイライラするから私用ではぜっっっっったいに使わないw
rust大好きステマするやつは頭おかしい Rustはマイクロソフトが採用したり
Linuxのデバイスドラバで採用されたり
トヨタ自動車の組み込みソフトで採用されたり
特殊用途ではこれから発展していくけど
さらに一般的になるには 最低でも10年くらいかかるといっていだろう c++やjavaとかは人間様のための言語だけど、
rustはコンピュータ様のための言語だからね
人間がコンピュータ様の奴隷になって制約されながら設計する言語だからrust好きの人間はドM確定 >>591
お前みたいなど底辺まで降りてこないから心配すんなw >>589
本当の事は知らんが、PerlやJava、Rubyの本が本屋に沢山並んでいた頃には、
既にそれらの言語はよく使われていたのに対し、Rustは本はその状態になったのに
余り使われて無い現実がある。知名度が高いのに使われて無い。 >>595 は「たくさん」という言葉すら理解できないのか... 今日は初詣に行ってきた
Rustさん普及しないで下さいと神頼みしてきた >>599
お前には無意味な願いだな
お前にRustの仕事が来るわけ無いもんなww >>600
どう考えてもゴミプログラマやゴミ企業が参入してくるなって意味やろ >>600
それな
だけどタワマンをローンで買ったばかりだから簡単に辞められない😭
来週からまたRustやらなあかん😭 >>598
まあ紀伊国屋さんなら...
でも検索すると結構あるんだな、ちょっと驚いたわ 俺は実用にしてるのはC#で、Rustやら情報科学やらは教養のための修行だと思って勉強してる >>605
その目的ならRustではなくCをやるべき Rustでプログラミング始めるヤツなんておらんやろ
最低5言語くらいマスターしてる人が道楽として試すのから入るのが殆どじゃない？ 今北なんだが、メモリー関連バグを潰せるだけでRust採用の価値があると思うけどそうじゃないんか
メモリー管理ミスが6割と聞いた >>610
linuxのドライバー作成ならいいかも >>598
紀伊國屋てw
ジュンク堂と双璧をなすラスボスですやん >>610
何事も良い面と悪い面があるので
自分のユースケースに当てはめてトレードオフを判断すべき >>605
C#やってるならSwift勉強するといいぞ
教養とは違ってC#の力が向上する C#だのSwiftだのJavaだのスレチじゃバカども ファイルシステムのパス回りをいい感じに抽象化してくれる(もしくは整形してくれる)クレートとかない？
env!("APPDATA")→"C:\Users\・・・\AppData\Roaming"
current_exe()→"\\?\C:\foo\・・・"
違うパス形式が入り混じるのはトラブルの元 >>616
fs::canonicalizeかければとりあえず形式は揃うんじゃない？ >>610
頭脳の高い人はそもそもメモリ関バグを引き起こさないからRustである意味がない >>620
頭脳明晰な人は
・論理を間違う頻度が極端に低い。
・テストの仕方が合理的でシステマチック。
・問題が発生しても原因箇所を突き止めるのが上手い。 頭脳明晰な人は人間の限界をよく理解している
注意資源を無駄なことに使わないためにどうすればいいかを考える
頭の悪い人にはこれが理解できない >>622
もっと頭のいい人は、特に注意して無くてもちゃんと出来てる。 架空の「何でも完璧にできるプログラマー」などを頭の中で作り上げたところで何の意味もない
実際にそういう人だけで回せている組織を教えてくれ >>621 そりゃすげえや
天才しか入れない会社であるGoogleで作られたソフトウェアには脆弱性が存在しないことになるんだからな >>616
Ruby では、File.expand_path で、\ を、/ に変換できる >天才しか入れない会社であるGoogle
夢見過ぎw
算数100点オジと同じ発想だぞ >>623
最高に頭悪そうな発言だな
小学生1年生かよ >>618
サンクス。それを通すとUNCライクになるんか
リファレンスを見るとこの仕様が確定しているわけではなく
互換性の面でUNCライクのパスが望ましいのかという問題も
なんとなくだけど互換性はドライブレタースタートのほうが高そう
というかググってもパス情報の推奨される扱いとかよくわからんな
PathBufが返ることが多いためかmutをつけてる例が多く見えるけど
加工が終わった後もmutのままにしておくのが望ましいとも思えないし >>625
そのGoogleがAndroidにRustを使うようになってバグが減ってるからGoogle程度では頭脳明晰な人ばかりではないらしい
https://japan.zdnet.com/article/35196972/ ○○バリア！
○○バリア貫通ビーム！
○○バリア貫通ビーム完封バリア！
まじで小学生と同じやな
グーグルの社員ですらメモリ管理をミスる
それより賢い天才が居ればそいつはCで良いよ、でも俺はそうじゃないのでRustを学んでるよ
ある意味メモリ管理を絶対にミスらない天才がコンパイラ >>629
mut が気になるならシャドーイングで消せばいいよ
let mut a = …
…
let a = a; // これ以降変更不可 >>629
dunce crateのほうがいいかもね
ていうか本音はcurrent_exe()が完全修飾パス返すのをやめてほしいところ ディープステートに関わり持つやつが荒らしに来ている！ >>631
犬と人間くらいの知能差があるとすれば話は違ってくる。
Google社員は犬の中の秀才程度。 >>631
俺からすれば、コンパイラは決まりきったことだけこなす単純馬鹿だけどな。 >>632
となるとパスを整形する関数を用意して切り離すべきか
>>633
なかなかよさそうですね。使ってみます
>There are also Windows NT UNC paths (\\?\C:\foo), which are more robust and with fewer gotchas
>but are rarely supported by Windows programs. Even Microsoft's own!
思うことはみんな同じなんやなって 技評技評言ってるヤツがしつこいが正直Rust流行ったからって技評のあの構成じゃ売れんだろ canonicalizeって存在しないパス情報を扱えない？のか(fsもdeucnも)
let path = dunce::canonicalize(Path::new(".\\foo")).unwrap();
は.\fooが存在しない場合Errが返ってパニックする
こうなるとパス情報は他の処理系と同じく文字列で保持して
使用するところでPathに変換するのがベターなのかな >>643
それ、実はかなり深い問題だぞ。
特に、環境依存のないライブラリではな。
Rustだから安全ですとか言ってないで、経験豊富なC++スレにでも聞きに行け。 >>643
っstd::path::absolute 深い問題だと言ってるだろ。
Rustだから安全ですと言ってないで、わかってる人に聞きに行け。 >>643
dunce::simplifiedでUNC除去するのがいいんじゃない？
別にPath自体は存在しないパスも保持できるしOsStringにするほどのこともないように見えるけど >>645
\\?\にabsoluteは対応してなくない？ >>645,647
そもそも一律で絶対パスに展開するのが最良なのか？ってところから再検討中
リモートになりうるパスを絶対パスに展開するとトラブルの発生率が増す気がしてきた Rustスレでそんなこと質問したって無理だから。
いい加減諦めて実績のある言語スレに行け。 誰も「Rustだから安全です」なんて言ってもいないしそもそも必ずしも安全でないことぐらい少しRustのこと勉強した人なら誰でも知ってる >>649
とりあえずPathBuf（参照ならPath）で保持しておいて必要な時にcomponents()で展開する感じがいいのかな
std::pathのPathBuf、Component、Prefixあたりでそれなりに抽象化はできてると思う
あとは目的次第 しかし何でこんなにアンチ多いんだろうな
ノイジーマイノリティのような気もするけど
海外だと人気あるのにな >>655
多いって言っても結局はいつもの人が連投してるだけだしせいぜい数人では
他のSNSやリアルではこんな人見たことないしなぁ あくまでこのスレの雰囲気からの判断だけど
自分は万能で何でもできると思ってるタイプの人間がどうしてもRustを使いこなせなくて
自分が理解できない言語は欠陥言語に違いないって感じで叩いてる印象
多少扱いにくい言語でもHaskellみたいにマイナーならここまで荒れなかったかもしれない Haskellも叩かれてただろ。
技術評論社のステマが過ぎるんだよ。 少なくともRustを使えっていう現場は今のところ日本では皆無だと思うけどね >>659
C/C++ は文法が無茶苦茶で扱いにくい部類なんだがなんだかんだで資料も多いし
慣れている人も多いから「これが普通」みたいな感覚になっちゃってるんだよな。
そこから遠い言語は「なんか普通じゃないやつ」に見えてしまうんだと思う。
言語としてスマートであろうがなかろうがエコシステムが充実してるほうが強いので
そこで C/C++ が長く支配的な立場だったけど現状の Rust なら十分すぎるほどに
充実してきてるんだから用途的にマッチするなら使えばいいと思うんだがなぁ。 >>659
使いこなせないんじゃなくて、魅力を感じない。 新着レスの表示を押したらgihyoアンチ出てきて笑ってしまった なお、Rustが欠陥言語なのはハッキリ分かってる。 https://mevius.5ch.net/test/read.cgi/tech/1639713446/181
になぞらえよう。
2022年、NSA(アメリカ国家安全保障局)公認メモリ安全言語にGoが入った時点で、
「Rustが自賛する」メモリ安全は「白けた話」になった。
Rustはもうどうでもいい。 >>660
お前にとって技術評論社はギフハブか何かに見えてるのか？ 使いたいけど使えない人 = 能力不足。
使えるけど使いたくない人 = 個人の選択の自由。
俺は後者だから。 文字列のパスの正当性をチェックしてくれるクレートとかないんだろうか
いわゆる汚染チェックだがダメ文字が含まれている、記法が有効ではない等々
WindowsのAPIにそれっぽいのがないかと思ったけど見つけられんかった
GetFullPathNameはファイルのみでディレクトリ名は不可っぽいし
exist類を利用する方法も出てくるけどこれはファイルやディレクトリがある
ケースでしか使えない 2022年 はちみつ味の複製ポエムバレしてRustは白けた話になった
2023年 標準ライブラリ軽視からのクレート探しの自走力無き苦行
合計：白けた話＋苦行＝見放し いままでC/C++の代わりになると云われた言語たちがどれだけ敗走したことか
そのRustの力とやら、見せてもらおうか！ Rust使わないことを選んだのなら、こんなとこで無駄な時間使ってないでC/CPPのスレで活躍したほうが良いのでは？ Rust「うあ～！汚コード増し増し負けたンゴ～！」 >>662
ここのRust'erも大体は海外企業勤めでしょ
国内は仕事無いし >>662
わかんないよ、数年前だけどAdaの仕事があったし
まあ研究所からだけどウチの会社にAdaなんて書けるやつがいることにビビったわ ま、ぶっちゃけ、RustよりSQL覚えた方が仕事はあると思うよ。 カーネルドライバのいくつかがRustで書かれ始めちゃってるので
いやでもぶち当たる日が来るので仕方なく勉強してます。
今のところはクソ言語と言い切れるほどのクソさにはぶつかってないかな >>659
叩かれてない言語は多くの人が使いこなしてるって意味だねｗ オッサンだけど女の子に生まれて百合恋愛がしたいだけの人生だった、女の最大の特権って百合ができる事だよな >>666
なんで魅力を感じない言語のスレなんてわざわざ見てるんだ？
暇すぎるだろw >>689
正しい評価ならな
無能の誹謗中傷は要らん >>691
根拠も示さずに正しいつもりとか言われてもね
> なお、Rustが欠陥言語なのはハッキリ分かってる。 Rustには欠陥が無いようなことを言い出したぞコイツ。 なんかまたErrorトレイトのメソッド変わってる……
見落としてたけど1.64からでしたか まあリーナスみたいに的確な指摘がちゃんと出来れば皆聞く耳を持つだろうにね >>697
Linusみたいな有名人が言ったら信じるだけで、
ちゃんと説明しても自分の頭で理解できない人が多い。 複数の実装を抽象化する想定のtraitにErrorなどというassociated typeを持たせて実装を分けてしまうと死ぬほど面倒だということを学んだ windows::～の使い方の情報が少なすぎ。String→PCWSTRの変換方法もよくわからないし
MessageBoxWに任意の文字列を表示することすら不安定
FFIでuser32のMessageBoxWを直接叩いたほうがマシ。こっちならさすがに安定するようだ >>702
Rustの文字列はUTF-8でナル終端なしだからワイド文字だと
・UTF-8→UTF-16変換
・'\0'追加
の２段階の操作が必要
ナル終端だけならstd::ffi::CStringでいけるけど、ワイド文字（UTF-16）使うなら
内部でVec<u16>を保持する専用の文字列型を用意した方がよさそう
あとはwindows::core::PWCSTR::from_ptr()にVec::as_ptr()を渡してPWCSTRを作る
このPWCSTRが使われてる間はVecを消したり変更したりすると危ないけど
&PCWSTRで返す形にすればライフタイムで束縛できるかな
この辺の操作はwindows-rsでも直のFFIでも変わらないと思う >>705
そんな感じで実験してみたんだけど不定期にMessageBoxWが意図しない文字列を表示する
ボローチェッカーは何も言わないけど結果からすると明らかに信用ならない
FFI利用の直叩きなら問題ないさそうだしPWCSTR::from_ptr()以降が怪しそう 他の言語でも同じ問題抱えているのに
rustではこういう問題があるぞーって批判目的で書いてる人って何なんだろう というか
ttps://learn.microsoft.com/ja-jp/windows/dev-environment/rust/rss-reader-rust-for-windows
この記事って罠じゃね？winapi使うかFFI使うかしたほうが無難な気がする レイヤー低いところをいじる場合はそのまま生で見えた方がデバッグがやりやすいってのはある。
まあ生で見えるから変なことも起こるんだが、この辺りはトレードオフの話だ。 RustがCやC++の文法に似ているというのはウソだと思うね。
本当に似てると思うなら感性を疑う。 似てる
C++から黒魔術をほとんど排除したのがRust 文法つっても BNF 的な意味での文法とセマンティクスまで含めた文法では意味合いが違うし、
「どういう意味で似ている」「どういう意味で似ていない」という基準を提示せずに感性で判断しようとするのなら感性を疑う。 >>712
そうは思えないけどな。
似てると言い切るのは無理やり感がある。 はちみつ餃子vsｵｲｺﾗﾐﾈｵスレ並行するのやめてもらっていいですか お前ら独自エラーはどうやって作ってる？
俺はenum使ってるんだけどこれ普通？ ディレクトリのコピーってないのか・・・再帰処理の実装は特に面倒なのに MSの際と出もRustをC++と似てると豪語しているが、信じられない。 RustとC++がそっくりってそれ中国語と英語がそっくりって言ってるようなもんだよ RustはテンプレートがC++よりスマートだよね
template<typename T>とか書かなくてもいいし >>720
中国語と英語はそっくりかもしれないけど
C++とRustは全く違うものです Rust, Go, Swiftの3言語登場の前後で、時代が変わった級の変化を感じてしまうが・・・・
有名言語で一番どれに近いって言われたら、文法は違うけどSwiftじゃないかな ムーブとRAIIあたりはC++くらいしか似てるものがない気はする
他はそんなに似てないかな C++は似てる似てない以前にちゃんとした知識がないわ。 >>717
普通
thiserrorのドキュメント見るといい >>723
俺もメジャーな言語ならSwiftが一番近いと思う Kotlin/Nativeもポインタ触れたりして結構似てるぞい
根幹をC++で作ってるから当たり前なんだけどもw Swiftと比べたらKotlin/Native とか下の中の下ではあるがw 普通にocamlとかのそこらの関数型言語よりはるかに厳しい たぶん型チェックではない気がするけどコンパイラのチェックが厳しいとゴミ言語になる理由がよく分からない
何となくで書けないのが不満なのかクラッシュバグを量産できないのが不満なのか
C言語でも-Wallとか-Werrorをつければ結構コンパイラうるさいよ
RustとCが近いと感じるのは脳内で同等のコードをイメージしやすいからかな
RustとC++はそんなに近いとは思わない（被ってる部分もあるけど別方向に派生したC言語という感じ） >>733
具体的には？OCamlではどうでRustではどうって例ある？ >>734
>RustとCが近いと感じるのは脳内で同等のコードをイメージしやすいからかな
近いとは思わんけどな。 >>734
Rustほど型チェッカを厳しめにしなくても
安全なプログラムは実現できる
だからこそRustは流行らない >>735
OCamlでは値の寿命を気にしなくていい
GCが管理するから
後はRustとは違って型推論をさせるコツというのが少ない >>715
これ、ねらったトリップを出せるってこと？
どうやるの？ >>738
暗黙的に型変換されることが多いという話なのか？
でなければどっちも型チェックの話じゃないと思うんだが >>738
> 後はRustとは違って型推論をさせるコツというのが少ない
（´･∀･`）ﾍｰ
でも少ないどころかOCamlに
「型推論をさせるコツ」なんてもんがそもそもあっただろうか…
型チェッカがどうこうは実は今もよくわからんけど
型の推論はRustのほうが数段ショボい感じ
「型推論をさせるコツ」とかいう話も大変Rustっぽい 「Rustを勉強したい」「WasmをRustで決まり」みたいな話ばかりで
実際に作ってる人がほぼ居ないのがRust。 rust も ocaml も型推論はHindley Milnerベースだろ。
rustで厳しいのはボローチェックやライフタイムのせいじゃないの？
それらも型に含める？広義では含むか、でも狭義にはちょと違うような。 ボローチェックやライフタイムをそこまで低レイヤー向けじゃない言語に入れてみた方が需要あるんじゃないかね。 低レイヤー向けじゃないならGC使えばいいんだからライフタイムチェックなんてする意味無くね >>745
hindly milnerベースって言っても使い勝手が違う
rustは関連型という機能があるからocamlのように型推論が強力なわけではない
あと推論順序の影響を受ける >>719
アイデアをまるパクりしてるので、同じに見える人も居るだろう。
文法が似てるとかではなく。 しかし、Rustが流行ってよかったよ。
ScalaやHaskellみたいなモナモナした言語が未来って言われても全然ピンとこなかったからな。 プロファイラーの皆さん鑑定お願いします
何やってるのかと思ったら、何やってんだか、オジ
https://i.imgur.com/Ug1VIIs.png くそーCreateProcessWがGetLastError=87で動かねぇ・・・
昔も苦労させられた記憶があるし結構鬼門なんだよなー >>752
OptionとかResult返すときの?オペレータは実質モナドなんだけど
モナドって言葉を使わなければみんな平気なんだろう
>>754
Win32 APIって今も32bit？
ワードサイズで引っ掛かった記憶があるようなないような >>755
PEヘッダ確認してみたけどちゃんとAMD64になっている
ポインタは8バイト、BOOL/DWORDは4バイトでいいはず >>753
RustをWeb系で使ってるとか豪語してたよww
個人の趣味スクレイピングをWeb系と言う虚勢にクスクスさせてもらった Web系はフロントはTypeScript/JavaScript、サーバーサイドはGoしか有り得ない #[link(name = "kernel32")]
extern "stdcall" {
fn CreateProcessW (
lpApplicationName: *mut u16,
lpCommandLine: u64,
lpProcessAttributes: u64,
lpThreadAttributes: u64,
bInheritHandles: u32,
dwCreationFlags: u32,
lpCurrentDirectory: u64,
lpStartupInfo: *const u8,
lpProcessInformation: *mut u8
) -> u32;
}
fn main() {
let mut cl:[u16; 5] = [0x63, 0x61, 0x6c, 0x63, 0x00]; // "calc\0"
let mut si:[u8; 104] = [0; 104];
si[0] = 104;
let mut pi:[u8; 24] = [0; 24];
let mut ret;
unsafe {ret = CreateProcessW (cl.as_mut_ptr(), 0, 0, 0, 0, 0, 0, si.as_ptr(), pi.as_mut_ptr());}
}
>error: process didn't exit successfully: `target\debug\test03.exe` (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)
ここまで単純化しても動かねぇ・・・というかsiとpiの正しいサイズがわからない よーくみたら引数が1個足りなかったｗ コピペ時にガバったか The Book 10.1に掲載されていたlargest関数を、
参照でかけたりしないのかなと思い試しているのですがうまくいきません。。
どうやって書いたらよいのでしょう？
fn largest<T: PartialOrd + Copy>(list: &[T]) -> &T {
let mut res: &T = &list[0];
for &elem in list.iter() {
if elem > *res {
res = &elem;
}
}
res
} 今度はWaitForSingleObjectで止まらない。というか
ttps://learn.microsoft.com/ja-jp/windows/win32/procthread/creating-processes
これをコピペしてコンパイルして電卓を起動させても止まらない。どうなっているのｗ
って思ったらcalc.exeはラッパーで即終了していたというオチ。MSはロクなことしないな >>762
>>759を動かそうとしてるんなら"calc\0"は第1引数じゃなくて第2引数よ
もうちょっと落ち着いて色々見直しなさいな >>761
10.1に書いてるコードがすでに参照使って書いてるじゃん
PartialOrd足せばそのまま動くけど？ >>763
MSDNを見る限り単にアプリを起動するだけなら第一引数でも第二引数(読み込み専用不可)でも大差なくない？
動くようになった状態で入れ替えても問題なく動作するし >>765
こっちじゃ第1引数使うなら"C:\\Windows\\system32\\calc.exe\0"以外は
GetLastError()が2(ERROR_PATH_NOT_FOUND)を返してきて動かんのだけど……
MSDNも第1引数の説明にだけパス検索はしないだの拡張子つけろだの書いてあって、その通りに動作してるだけのように見えるし
https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw
> The function will not use the search path. This parameter must include the file name extension; no default extension is assumed. >>761
とりあえず修正したコード
fn largest<T: PartialOrd>(list: &[T]) -> &T {
let mut res: &T = &list[0];
for elem in list.iter() {
if *elem > *res {
res = elem;
}
}
res
}
forの変数elemの型が諸々の事情でTになってたから&Tに直した
ついでにTのCopyもいらなくなりそうだから外した
letとかも同じだけど
let &x = ...
みたいに受け取る側に&をつけるとxの型は入れる値の&を外した型になる（とても雑な説明） iter().min::<T>()みたいにかけないっけ
うんこまん >>767
ありがとうー
そういう仕組みなのね。勉強します >>769
そのへんはパターンマッチと同じ理屈で解釈されるよ。 ・system()っぽい関数(起動したプロセスが終了するまでブロックする)
・CreateProcessW失敗時は起動失敗を呼び出し元に通知したい
・成功時に戻すべき情報はない
・Rust的にはResultを返すのが定石？
こういう時のコーディング例とかググっても全然出てこなくね・・・
重要なのはOk/Errのみで返り値は不要みたいなケース
とりあえずbool返しにしておくか
>>766
あれ？確かに。すまん気のせいだったっぽい >>767
> if *elem > *res {
if elem > res でいいよね >>747
変数間でのオブジェクトの共有が気になるシチュエーションはjavaなんかは結構あると思う。 rust-analyzerにもVSみたいにドロップダウンでplatform切り替える機能ほしいのう
cfgで複数のplatformに対応しているタイプのライブラリで便利そう 継続不可能な状態→エラーダイアログを表示
ここまではいいけどこの後の後始末ってどう書くのがいいんだろうな
後始末のために共有データ(起動時に設定ファイルから読み込む)にアクセスしたいが
Dropトレイトにしろパニックハンドラにしろmainとは別スコープなのでアクセスできない
後始末のスコープ中で共有データを読み直すという手もあるけど、本当に意図しない状態で
強制終了する場合にファイルのロード＆パースをするのが望ましいとは思えない
Dropトレイトの初期化時に共有データの参照を渡しておくとか？ >>776
mainの中で初期化してResultを返す本処理を呼ぶ形は無理？
fn main() {
// 初期化（設定読み込み）
let info = ...;
// 本処理
let result = main_body(&info);
match result {
OK(_) => {}
Err(e) => {
// エラー処理（info使える）
}
}
} >>777
それコードの位置が逆なだけじゃ。というかResult返しの実装方法を理解できていない
とりあえず共有データを保持している構造体にdropを実装してみた
自身へのアクセスは可能だしmainの終了時に実行される・・・はず >>777
よくこの文章を解釈できたな
素直にすごいわ Rustってゲームに向いてそうなイメージあるけどどうなんだろ
メモリリークは相当起きにくいよな？ ゲーム開発はトリッキーな手品も使うだろうから向いてないんじゃないか 今のご時世に非標準的な実装をするゲームとかOSのバージョンアップで爆死する未来が見える >>782
OSに関係無いところでのトリッキーなテクニックは有りえる。
例えば、複数のポインタ用のバッファをまとめてnewで確保してから、
直後に値を代入するようなことはC/C++では簡単に行なえる。
ところが安全性重視の言語だと、非初期化状態のポインタは許されないから、
少なくともnew演算子が自力でNULL初期化しなくてはならないので、
無駄になる。
他にも、配列の範囲チェックが無駄になる。 >>783
ちなみに、
「非初期化状態の変数」は不安定になり易いので減らした方が良いとされているが、
BYTE *dst = new BYTE[1024]; // dst[k] はこの時点では未初期化状態
memcpy( dst, src, size );
のような時にはC++では効率を考えると仕方が無いものと考えられている。
0初期化すると無駄になるから。 ヒープでいいならVec::with_capacityしてデータ入れた後にBoxed sliceにすればいい話だね
スタックでゼロ初期化した方が性能はいいと思うけど Rustのメモリ安全性にはメモリリークしないことは含まれていないんだよね。
Rc<T>で循環参照するデータを作ってもコンパイルエラーにはならずメモリが解放されないままだったはず。
まぁメモリリークしててもメモリがある限り正しい結果を返すわけだし、メモリがなくなったらクラッシュするので間違いが起きたまま動作しつづけることはないけど。 Rustは例えばGodotではGDScriptが実質Rustだし相当ゲーム制作に向いてる
https://gitlab.com/the-SSD/gdscript-compiler >>786
なんじゃそりゃ
どこでそんなデタラメ仕入れてきたの？ >>781
そういう部分だけunsafe使えばいい。
unsafeダメ原理主義者になるな。 >>791
そこにはライフタイム省略版とは書いてないよ
expressionなどからライフタイムを推論できない場合はstaticになると書いてある
（例えばコード例のようなタイプエイリアスの場合など）
playgroundのコードではu2のライフタイムから推論されるからstaticにはならない >>791
これでしょ？
If the trait object is used as a type argument of a generic type then the containing type is first used to try to infer a bound.
If there is a unique bound from the containing type then that is the default >>793
は〜んなるほどな
関数引数とか構造体メンバとかの'staticに推論される場所で使うことが多かったから勘違いしてたっぽい
ありがとう みんな大好きUnityなどと比べたらRust由来の効率低下なんて微々たるもの unsafeで書いたほうがコンパイル速度速くて好き Rustで多量のファイルを高速に読み込みたい場合ってどうすればいいの？
std::fs::readはVec<u8>を返す＝メモリアロケータが動く＝遅い
十分なサイズのVecを事前に確保してreadなりReadFileなりを叩けば
任意のアドレスに読み込んでくれるけどほかに方法はないのかな Rustに限らずreadで遅いと感じるレベルならOS依存のmmap(memmap)くらいしか思いつかない
速さ目的で使ったことないから本当に速くなるか分からないけど The Book を進めていくと Box<trait> でエラーになって Box<dyn trait> に変えろって言われるんだけど、dyn ってなんですか？ >>807
なるほど
trait は動的なのでより明確になるように dyn キーワードが追加された... という理解でいいでしょうか？ >>805
1MB/1000個くらいのファイルをstd::fs::readで読みながらVec[u8]に
extend_from_sliceで追加していくコードを書いてみたら数秒かかった
さすがに遅すぎ
せめてVec<u8>→Vec<u8>(の任意のインデックス)みたいなmemcpy的な
コピー手段はないのなか。どのくらい早くなるかわからんが >>809
>1MB/1000個くらいのファイル
これはどういう意味？
/ は、割る、または、OR(または) の意味で用いる。
もしかして、
一個当り 1MB のファイルが 1000 個、合計サイズ 1GB の
ファイルのことを言っている？ >>810
ちなみに、そのくらい巨大になると、Rustの「安全機構」は体感速度に
まで影響する。 >>810
わかりにくくてすまん。ファイル総数1000程度、合計サイズ1MB程度 >>808
間違えてるかもしれんが俺の理解だと
>>traitは動的
traitは静的だけど、trait実装してる型が静的/動的に決まるかで
動的→dyn Trait 静的→ジェネリクスやimpl Trait を使い分ける
よくある例では
Vec<T>はT１つ確定して他の型は一切受け付けないけど
Vec<Box<dyn Trait>>はTraitを実装してる型なら何でも入る >>814
分かりやすい説明でなんとなく理解できた気がする
ありがとう >>809
extend_from_sliceだと遅そうだね
io::copyにしてみれば？
ちなみにその1000個をcpしたらどの程度で終わる環境？ >>809
memcpyと同じことしたいならstd::ptrにcopyとかcopy_nonoverlappingが用意されてる
ただ引数はポインタだからunsafe
copy_nonoverlappingのExamplesがやりたいことに近いと思う
この例はコピー元のVecを空にしてるけどu8みたいなCopy型に限定すればコピー元のVecをそのままにしても一応安全 818追記
コピー元が空になっても構わないならVec::appendで同じことができる >>817-819
ありがと。試してみます
エクスプローラーから同ドライブへのコピーで数秒ってところでしょうか >>812
1000個のファイルで1秒だと、もともとOSの速度がその程度の場合も有り得そう。
1ファイル当り1(ms)ということになるから。
もともとファイルはそこまで一度に沢山の個数をopen, closeすることは
想定されて無いので。
それもRustの安全機構が遅さに影響を与えているかも。 >>821
ファイルって、例えばファイラーでコピーする場合でも、合計が同じ容量でも、
細かいファイルが多数有る場合の方がずっと遅くなる。
一個の1MBのファイルをコピーすると一瞬なのに、1KBの1000個のファイルをコピー
すると1秒くらい掛かるかも。 profilingしてsyscallがボトルネックになってれば非同期や並列化で高速化するしかない たとえどんなにメモリ確保が遅くともディスクIOよりも遅いってことはないだろう
体感の遅さが何秒とかじゃなくてドライブのベンチマークと比べて判断しよう >>820
エクスプローラーってことはWindows?
そもそもWindowsはファイルシステムのsyscallが結構重いから
メモリコピーとか関係なくそんなものの可能性はあるかと
思い込みで試行錯誤してないでちゃんとプロファイル取ったほうがいいよ cargo testでドキュメントテストが実行されないんだけどお前らも同じ？
ドキュメントに書いてある通りに実行してるけど実行されない >>826
普通に実行されるから doctest の書き方間違えてるんじゃないのかなぁ
`(バッククォート) じゃなくて '(シングルクォート) になってるとか >>827
ああ、すみません。解決しました。
どうもバイナリだと実行されないみたいです。
cargo new myprog
で作成したバイナリだと駄目で
cargo new doclib --lib
で作成したライブラリではちゃんと実行されました。 >>828
おお、本当ですね... なんでこういう動きなんだろう、分かる人いないかな？ Rust固有の話でもないんだけどUnicode対応のアーカイブフォーマットってどんなのがあるんだろ
比較的新しい7zipはUnicodeファイル名をサポートしているけどライブラリやクレートが豊富とはいいがたい
かといってレガシーなzipやtarだとファイル名のコーディングは実装依存にみえる
実装依存の場合Unicodeファイル名をサポートしているライブラリやクレートがあるのかという問題も出てくるし tarで実験していたら詰んだｗ
let mut v:Vec<u8> = Vec::new();
let mut c = std::io::Cursor::new(v);
let mut t = tar::Builder::new(c);
t.append_path("foo.txt");
std::fs::write("foo.tar", &v); // borrow of moved value: `v`
どうしろと・・・ >>830
zip も特定のビットを立てていればファイル名が UTF-8 ということになる。
https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.10.TXT
項目 4.4.4 で説明されている Bit 11 を見て。 >>833
オンメモリでtarを作って出来上がったものをファイルに保存したい tar使ったことないけどt.get_ref().get_ref()で&Vec<u8>取り出せるのかな
先にt.finish()呼ぶべきかもしれないしget_refよりinto_innerの方がいいかもしれない
get_refは詰み回避の頻出手筋 >>836
let a = t.get_ref().get_ref();
std::fs::write("foo.tar", a);
これは一応それっぽいファイルが作られた
let mut a = t.into_inner().unwrap();
let mut f = std::fs::File::create("foo.tar").unwrap();
std::io::copy(&mut a, &mut f);
こっちは空っぽだった
ttps://crates.io/crates/tar
こんなサンプルしかないしCursorを使用する例なんて見当たらないし
どうやるのが妥当なのか全くわからん ttps://docs.rs/tar/latest/tar/struct.Builder.html#method.append_path
>pub fn append_path<P: AsRef<Path>>(&mut self, path: P) -> Result<()>
>～
>Also note that after all files have been written to an archive the finish function needs to be called to finish writing the archive.
らしいが
>pub fn finish(&mut self) -> Result<()>
>～
>In most situations the into_inner method should be preferred.
どっちなんだよｗ
ここに載っているサンプルだってinto_innerもfinishも呼んでいないのがあるし >>835
もう解決してそうだけど
let mut c = ...からt.append_path(...)までを別スコープにすれば通らない？ >>837
空っぽになるのはtarのinto_innerでfinish経由でwrite_allが呼ばれて
cursorのpositionが末尾になっててio::copy時には書き出すものがないから t.append_pathしたタイミングでcursor.position進んでたわ
そりゃそうか let mut v = Vec::new();
let c = std::io::Cursor::new(&mut v);
let mut t = tar::Builder::new(c);
t.append_path("foo.txt");
t.finish();
drop(t);
std::fs::write("foo.tar", &v); get_mutでCursorにすればReaderとして使える そのコードでCursor使う意味が分からん
let mut tar = tar::Builder::new(Vec::new());
tar.append_path("foo.txt").unwrap();
let body = tar.into_inner().unwrap();
std::fs::write("foo.tar", body).unwrap(); 昨日のファイル1000個の続きなんじゃね
メモリに全部読読み込んでから処理しようとする理由は謎 The Bookをやり終えたあとってどうするのがいい？
次に読むべきおすすめの書籍があるか知りたいです！ >>846
次の書籍を読む前にThe Bookの復習がてら簡単なCLIツールを3～5個くらい書いて自分の理解を確かめたほうがいいよ >>847
アドバイスありがとうございます！
とりあえず何かしら作ってみようと思います コマンドラインに渡した(1000個の)ファイルを
指定した名前のtarファイルに書き出すツールとか >>845
メモリを事前に一括で確保してVecの逐次伸長をなくせば早くなるんじゃね？
と思ったけど実験してみたら全くそんなことはなかった。Rustのメモリアロケータって優秀なんだな・・・ 10回程度の小さい容量のアロケートなんてI/Oに比べれば微々たるものでしょ Vecのcapacityって再確保のたびに倍々に増えていくんじゃなかったっけ
ならpushの回数を増やしても再確保回数は大した数字にならないだろう ドライブレターを割り当ててあるネットワークドライブのパスを
dunce::canonicalizeに食わせるとUNCパスが返ってくる
そりゃねーぜ・・・ こういう瑣末な問題を自分で解決する力のない人はまだRustを使うべき時期じゃないよね というかLinuxのProtonだとネットワークドライブへのアクセスでも
ドライブレタースタートのパスが返ってくるのな
結果、Windowsだと動かないけどLinuxなら動くという珍事になってるｗ ファイル属性の取得はファイル読み込みよりは圧倒的に速いので
・ファイル名とファイルサイズの取得
・合計サイズのチェックと領域の確保
の順でやればマシかもね
ファイル読み込みに比べたら微々たる違いだとは思うが ファイルの数だけ二重にsyscallを呼び出すことになるからサイズのデカい数ファイルを処理するときならともかく1000ファイルで合計1MBという今回のケースだと悪化するんじゃね？ >>858
そもそもトータル１MB程度って分かってるなら余裕みて２MB程度確保しとけば良いような気がするが... >>859
ripgrepは今回のようにすべてのコンテンツを全て一括でメモリに保持するわけじゃないから
streamingで処理するのでいいなら固定長のバッファ確保してそこを使いながらパイプライン通して結果をI/O出力すればいい
>>860
アロケーションがボトルネックならそういう対処もあるだろうけど十中八九違うんじゃね？ >>861
> アロケーションがボトルネックならそういう対処もあるだろうけど十中八九違うんじゃね？
そんなのはみんなわかっててあーだこーだ言ってるわけだがw >>863
的外れないことを言ってる自覚があるなら>>860みたいなレスはしないだろ dunce::canonicalizeはダメっぽいのでGetFullPathNameWを使うことにした
ちょうどいいシステムコールが用意されているなら安易に野良クレートを使うより確実な気がしてきた >>844
のコード見るだけでも、Rustは書き味の悪い言語だと思う。 >>872
Rust関連の本を何冊か読んだが良いコードは余り無い。 悪い見本だと判別できない時点でろくな本を読んでないことが分かる みんなの参考になるように読んだ本を列挙してみてはどうだ？ はっきり言ってやろう。Rustは根本的に書き味が悪いんだよ。 Rustは苦痛を感じるためのドM言語ってこと、忘れてないか？ >>876
じゃ君が思う根本的に書き味が良い言語は何なの？ ラクダケース派か
PythonとかRustみたいに型と変数でラクダとヘビ使い分けるパターンって名前あるのかな Rustってそもそもコンパイル速度が遅くてダメだわ Goはコンパイル最速だからデオキシスのスピードフォルムだな
Rustはディフィンス、Java/C#はノーマルフォルムだな
アタックフォルムは知らん >>878
C, C++, C#, JS, Ruby, Java は、Rustよりは書き味がいい。 自分はスネーク派だからJavaとC#は苦手（根本的に書き味が悪い）
Python使用歴が長かったからだと思う
CとC++は何でもありだからどうでもいいけど
TypeScript（JS）も油断するとスネークで書いてたりする スネークとは関係なく、Rustは書き味が悪い。
他のどんな言語にも無い書きにくさ。
Kotlinも書き味が悪いから没落中。 書き味で言うならNimが一番良い。
特にメソッド呼出し構文はNimが一番洗練されていると思う。UFCSとかもっと色々な言語で採用されてほしい。 nimの構文とか好きな人は好きだろうと思うけど自分は嫌いだし
嫌いな構文をわざわざ使うほどの他の魅力がないんだよなぁ 書き味悪いとか言ってRust使う気全くないのにわざわざRustスレに書き込もうとするのが一番意味不明 >>893
オレもそう思った
意味不明というかアンチスレあるからそっちでやれよ
って感じ わざわざ文句いいに来るおじさんって大抵構ってちゃん 「書き味」の良さ悪さの原因を自分なりに考察して言語化してれば多少は議論になるんだけどな
慣れと好みの次元でしか語れないならお爺ちゃんの自分語りでしかないから相手しても無駄 そもそもRustはいろいろ我慢して使う言語だし
みんな上に言われて仕方なく使ってる >>896
そんなことしたら、ずるがしこい人達にアイデア盗まれるだけじゃ。 何が良くて何が悪いかを発見すること能力こそ重要なのだから。 コンパイラ安全最強はrust
コンパイラ速度最強はgolang
オブジェクト指向設計最強はjava/c#
汎用最強はc/c++ 殆どの言語は高速化に向けて頑張ってるからGo言語の地位は危ういけど、既存の言語をメモリ安全にするのは大変だからRustは安泰
強みがあるって大事 また次世代言語スレ(旧世代おじいちゃん隔離スレ)が消えたから溜まり場になってるのか
迷惑な話だな >>898
アホだろw
「トマトは不味い、俺はりんごが好き」と同程度の話なのにお前がりんごが美味いと感じる理由を説明したらそのアイデアwとやらがが盗まれると思ってんのかww >>907
まともにrust使ったことないのがまたバレるから誤魔化してるだけでしょ アイデアってことは書き味のいい最強のプログラミング言語の開発でもしてるんだろうな 仮に、あくまでも仮にプログラミング言語を確実に素晴らしくする案があったとして
その案が盗まれて (他の言語に取り入れられて) なんか損なことがあるのか？
世の中に良いものがひとつ増えればありがたい話。 車関連のソフトウェア携わってるやつおる？
今年から急にrustの案件増えてきてね？
しかもすごい金かけてる案件が目白押し
うちは4次請け5次受けくらいの立場だからわからないけどこれってＴＯＹＯＴＡとかホンダとかが大元なのか？ 車載での普及はかなり先では
少なくとも今のE/EではCのままでしょ >>912
この流れだとedgeやsafariが追随するのは必至か >>915
EdgeはChromiumベースじゃん >>915
edgeはchromiumだから追随も何も自動的にRust採用
chromeの脆弱性の大半はメモリ関連バグが原因なので自然な流れ >>911
俺もそんぐらいの商流だけど、話は増えてる。
>>914,916
今の車はエンジンやナビ以外も色々電子制御してるんだわ。
んでもって今まさに売るもんじゃなくて、ン年先に出るかもしれないモデルの話。
C/C++のテスト工数がばかんなんないんだわ。 Rustは自動車などの人命に関わる部分では人気が高まっていると。
人命に関わるからめんどくさくても仕方が無いと。 その話が事実ならルネサスからRustの開発環境が提供されるのも
時間の問題ってこと？(もしくは一部にはすでに提供されている？)
現状組み込み用だとCortex-MやRISC-V用の野良コンパイラと
vscodeあたりを組み合わせるしかないわけだし ソニー・ホンダのAFEELAとかどうなんだろ？
Rustとか使ってるのかね。
ソニー･ホンダも志向､自動車の｢走るスマホ化｣
https://toyokeizai.net/articles/-/644484?page=2
ソニー・ホンダモビリティの河野拓・デザイン＆ブランド戦略部ゼネラルマネジャーは、AFEELAを「iPhoneにタイヤがついたようなもの」と例える。 >>921
>>922
914です。ADやゾーンE/Eに向けて採用されていくのは同意。演算能力はマイコンというよりPC
エンジン、ブレーキ、ステアECU等々のマイコン使った従来E/EのECUは人命に関わっていたとしてもCのままだと思うよ
モデルベースでRustのコード生成なんて聞いたことないし 書き味ってのはオブジェクト指向し易いかどうかってこと？ >>924
> ソニー・ホンダモビリティの河野拓・デザイン＆ブランド戦略部ゼネラルマネジャーは、AFEELAを「iPhoneにタイヤがついたようなもの」と例える。
そう言うのはECUとか知らない一般向けの宣伝文句だよ 命に関わるようなところを4次請け5次請けに出してんの！？
日本マジ終わってんなww 仕様書通りにできててテストに合格すればどこに出してもいいでしょ
孫請け以降禁止する契約もあるけど >>930
言い訳ないだろw
戦略的にも品質的にも生産性的にもあり得ない
仕様書通りにできててテストに合格してればいいという理由でGoogleが自動運転技術の命に関わるような開発を4次請け5次請けに出すと思うか？
シートベルトやエアバッグ作るのとはわけが違うんだよ >>931
GoogleはGoogleの付加価値を提供するために自分たちでやっているだけでしょ
車とそのシステムを作るカーメーカーやTier1が自分でソフト書かなくても品質保証できていれば問題ない。付加価値はそこじゃないから
時代は変わってきてるけどね Rustは メモリ関連のバグが減るからどんだけ下請けに出しても
大丈夫な言語でしょw >>933
そんな考えだから
トヨタですらコードがスパゲッティすぎるという理由で安全性を疑問視され訴訟で負けたりするんだぞ
ソフトウェアというものへの理解が足りない fn foo(・・・) -> Path {
>error[E0277]: the size for values of type `[u8]` cannot be known at compilation time
Pathを返したい場合ってどうすればいいの？
Path::newとかはPathを返してくるしPathを返り値とできないってことはないと思うんだけど テスラ車を突然襲う｢ファントムブレーキ｣、米NHTSAが調査に本腰
https://www.gizmodo.jp/2022/02/what-causes-phantom-braking-in-tesla-cars.html
https://www.youtube.com/watch?v=gG2joDBwvUk
調査の対象となる去年と今年の北米市場版Model 3とModel Yは8つのカメラオンリーです。前方の障害物を認識するレーダー（競合EVの間では自動運転に不可欠というのが常識）は装備されていません >>937
Path::new()の戻り値の型は&Path >>935
コードがスパゲッティだと安全性に問題あり→分かる
コードがスパゲッティだと裁判で負ける→そんなわけない >>937
Pathはsliceだから生のままでは返せないよ
Stringとstr
OsStringとOsStr
PathBufとPath
の関係 >>939
今度は
>error[E0515]: cannot return value referencing temporary value
そりゃそうだが動的に生成したPathは返せないのか？ >>935
rustはスパゲッティーでもメモリは安全安心なんだぞ >>944
動的に生成したパス文字列なら生成した文字列を保持するメモリが必要だからPathBufで返す
関数の中で作成したString（OsString）は関数を抜けるといなくなるからそれを参照する&Pathは返せない
どーーーしても&Pathで返したいなら生成した文字列を保持するための&mut OsStringを渡すみたいな技巧が必要
単純に使いたい関数の引数が&Pathなのであれば&PathBufを&Pathとして使える（&Stringが&strになるのと同じ） コンパイラを黙らせることが開発だとでも思ってんのかね 日本の仕事の進め方的には遠からず当たっているのでは？
うるさい奴を黙らせればおｋみたいな会社は多いだろ そういうアリバイ主義者と静的解析バカの悪魔合体は勘弁願いたいな。 >>947
マジか。結局Pathを全部PathBufに書き換えた 最初の[u8]渡してエラーになってるやつは
&[u8]を渡して&Pathを返す関数にするのが一般的 let mut v:Vec::<u8> = Vec::new();
let mut t = tar::Builder::new(v);
と書くと1行目がwarning: variable does not need to be mutableになるんだけど
こういうときってどう書くのがいいのだろうか
コンパイラのチェックや動作に問題がなくても変化する変数をイミュータブルで
宣言するのは可読性が落ちるし >>956
少なくともvは一度も変更せずにtar::Builderにムーブされてしまうのだから
素直にmut取ればいいと思うけど
ムーブ先で将来的に変更される可能性のあるものすべてにmutを付けるというのは
特に可読性良くもないと思う というかその理屈だと
let b = a;
let c = b;
let d = c;
とムーブしたときにdをmutにしたくなったら依存関係を遡って全部にmutつけてまわるのか？ Chromium、プログラミング言語「Rust」をサポートへ
https://news.mynavi.jp/article/20230116-2564518/
米Googleは1月12日(現地時間)、これまで展開してきたChromiumプロジェクトにおいて、新しくプログラミング言語「Rust」をサポートしていくと明らかにした。来年にはRustで書かれたコードをChromeのバイナリに含めることができるようになるという。
Rustは、もともとFirefoxなどを提供しているMozillaがブラウザ開発のために作ったプログラミング言語。GoogleはRsutをChromiumに導入する目標として、開発のスピードアップやセキュリティの向上を挙げており、この達成にはRust採用が適切だと言及。
Mozillaのソフトウェア業界への貢献に対して感謝すると述べている。なお、ChromiumにおけるRustのサポートは、しばらくC++からRustへの単一方向に限定するという。 >>959
おまえさぁ、もうで>>912ですでにでてることをなんでわざわざ書くの？
仕事できないだろお前 そのための言語だろRustって
ド素人無能の働き者養成ギブスよ >>962
古のイキリCOBOLコーダーと同じメンタリティだな ところが、COBOLよりC/C++は圧倒的に多くの人に使われて来たはず。 Rustももう少しC/C++に寄せてくれたらよかったのにな。
C++をうまく拡張してメモリまわりとかどうにかならんにかな。
maneged C++、、C++/CLI、、、うっ、頭が。 なんでわざわざ避けるべきものに寄せる必要があるんだよ Rust好きは、関東の人が世界で一番関東料理が優れていると思い込んでいるみたいな話だな。 C++ の改定の歴史を見ればわかるだろう。
互換性を維持して便利に改良！ なんてやってたらわけのわからん歴史的事情の積み重ねでグダグダになるんだってば。
互換性は絶対要件にしないが似て非なるものという程度の改良だとそれはそれで新しいキメラになるだけだし。
知見を踏まえつつも新しく設計するというくらいでようやくスッキリと整理されたものが出来る。
でも現実はね、現実がそんなに綺麗なもんじゃないからそれに使うプログラミング言語もいくらか汚い部分があるのは仕方がないのや。
Rust の汚い部分は unsafe に集約されてるから簡単に未定義を踏めてしまう C++ より比較的マシって話。 Rust用語派は同じような話ばかりで、C++の問題点を解決したからRustは良くなっ
たと。しかし、それはfactではない。 Rustという英単語から「枯れた」という印象を受けてしまう人も多いんだろうが、
実際のRustの言語定義は、枯れているとは言い難い出来で独自な奇妙で新しいもの。
枯れている=古いが便利 というニュアンスとは全く当てはまってない。 > Rustという英単語から「枯れた」という印象を受けてしまう人も多い
まずこれがおかしい >>957-958
イミュータブルで宣言した中身が書き変わってしまうようなコードはムーブ後であったとしても
ttps://doc.rust-lang.org/book/ch03-01-variables-and-mutability.html
このあたりの説明と矛盾しない？
tar::Builder::new()の引数の中身が書き変わらないことを期待されるということはないだろうし
ミュータブルのものだけ通るようになっていた方が宣言と動作が一致すると思うけど
何か不都合があるのだろうか >>977
変数とその変数が指している先がごっちゃになってる予感。 >>977
あと旧来の変数への代入とletバインディングもごっちゃにしてる予感。 >>977
たぶんmutが値の不変を示しているという理解なんだと思うんだけど
mutはあくまでバインドしてる変数を通して変更操作ができるかどうかしか言ってない
値の不変は型で示されるもので、例えば&[u8]ならそこからどうムーブしようがmutつけ外ししようが値は不変
逆に言うとVec<u8>と宣言した時点で値は可変だと言ってることになる
なのでtar::Builder::newの引数がVec<u8>を取るのは可変を要求していて、宣言と動作が一致している んー。
取っ掛かりがいまいち掴めないね。
やる気なんだけど。 >>979
そこは従来の宣言+初期化と本質的な違いはないからごっちゃにしてても構わない >>978-980
それってC/C++のポインタとポインタが指し示す先にある実体の関係に似ていると思うけど
The Bookのどこに書いてあるんだ？
新しめの言語はC/C++の反省？からかポインタを意識させないようなのが多いと思うし
スカラー型と非スカラー型を明確に区別して扱う必要があるのであればなおさら重要じゃないかな
>>980
動作はわかるけどソースを見たときの直感と動作が一致してるかは疑問
C/C++のconstとかも何が修飾されるのか判りにくいけど同じ問題があると思う >>986
個人的には一貫して直観的だと思うけど、
完全に理解した上で分かりにくいというならしょうがないんじゃない
感じ方は人それぞれだし into_inner() はムーブする、get_ref() はムーブしないという理解で合ってますか？ >>989
命名的にはだいたいそうだろうという予測はつくが正確にはメソッドシグニチャを確認して >>992
おけ、このスレ完走したらそっちに移ろうか ワッチョイいれると原理主義者しか残らなくなるからいらない
特に技術系スレで論理性がなくなるのは致命的 言うほど論理性があったか？
ﾜありで別に困らないし、ありとなしで並走して人が多いほうに行くわ このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 39日 10時間 23分 50秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
