X



Rust part23
0001デフォルトの名無しさん
垢版 |
2024/02/23(金) 17:37:52.13ID:CheDQupm
公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

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 part22
https://mevius.5ch.net/test/read.cgi/tech/1705760500/

ワッチョイスレ
プログラミング言語 Rust 4【ワッチョイ】
https://mevius.2ch.net/test/read.cgi/tech/1514107621/
0638デフォルトの名無しさん
垢版 |
2024/04/11(木) 11:57:27.19ID:17a5lmDN
関係ない長文でごまかすフェーズに入ってるってことは内心恥ずかしくて死にそうになってるんやろうな……
0639デフォルトの名無しさん
垢版 |
2024/04/11(木) 11:57:34.08ID:6x2Zth+c
複オジは見えてる範囲が狭過ぎる
だから長文になればなるほど勘違い度や害悪度が高まる
0640デフォルトの名無しさん
垢版 |
2024/04/11(木) 12:47:47.10ID:ZruVErXu
自分が使ってきた特殊な仕様の言語に慣れ親しんでいると
一般的なの仕様のRustに違和感を感じて文句をつけたくなる気持ちはわからんでもない
Rustを叩く前に視野を広く持つべきだな
Rustの仕様はよく考えられ機能的に洗練されている
0645デフォルトの名無しさん
垢版 |
2024/04/11(木) 16:41:03.54ID:KhnNkcJ8
まともな質問にいつものノリで適当に答えて嘘だったら良くないしね
0646デフォルトの名無しさん
垢版 |
2024/04/11(木) 17:01:08.25ID:TWMZ6q+3
そっか
俺の答えも間違ってたしな
正しくはdowncastのために必要らしい
詳しくはfix_errorのRFC見て
0647デフォルトの名無しさん
垢版 |
2024/04/11(木) 17:41:58.72ID:McIjmFt1
Playgroundがwebsocket接続のタイムアウトエラー(504:Gateway Time-out)で全然動かないんだが俺環?
0649デフォルトの名無しさん
垢版 |
2024/04/11(木) 18:55:11.06ID:4f6XcC0j
downcastなんて別にしないからいらねーよって思ったけど

そういえば内部で似たようなことやってるあれがあったな、どっちかっていうとあれのためか
ヒントありがとう
0651デフォルトの名無しさん
垢版 |
2024/04/11(木) 20:25:23.50ID:81s1BzdD
>>641
UFCSはメソッド名空間の汚染であるため、まともな言語では採用されていない。
RustはUFCSを採用しないだけでなく、更に厳しく孤児ルールによってメソッド名空間の汚染を防いでる。
Rustでのメソッド追加拡張は、そのための新たなトレイトを用意することで、その利用空間に限定して安全に行うことができる。
0652デフォルトの名無しさん
垢版 |
2024/04/11(木) 20:52:12.80ID:AZdBjU6j
>>651
UFCSはそもそもメソッドとか無いんだから、ありもしないメソッド空間の汚染とか考えるだけ無駄。

それに、メソッド呼び出しは人間の思考パターン(大域から局所に絞り込む)に従った自然な記述方法なんだから、それを拡張困難なメソッドだけに限定するのは酷い制約かと。カス文法のPythonを思い浮かべますな。
0653デフォルトの名無しさん
垢版 |
2024/04/11(木) 21:02:41.98ID:81s1BzdD
>>652
Rustでメソッド呼び出しは拡張困難ではなく、拡張用トレイトを自由に新たに用意することで、他への汚染を招かずに安全に拡張できる。
そのためUFCSのような愚かな方式を採る必要がない。
0656デフォルトの名無しさん
垢版 |
2024/04/11(木) 21:54:13.50ID:AZdBjU6j
>>653
それって単にメソッドだけ特別に名前空間を管理していという話で、UFCSだから問題になるという話では無いな。
もっとUFCSならではの問題点を指摘してくれ。

せめて関数が左作用ならUFCS捨ててもいいけど、どの言語も馬鹿のひとつ覚えで右作用を採用するからメソッドとかUFCSが重宝される。
0657デフォルトの名無しさん
垢版 |
2024/04/11(木) 23:54:23.85ID:A4VQpdsZ
アラビア語でコーディングすれば、入力左から右へ進むから右作用が思考の順になるぜ
アラビア語おすすめ
0658デフォルトの名無しさん
垢版 |
2024/04/12(金) 00:40:05.77ID:fvGN/jjJ
>>656
それはメソッド呼び出しのメリット
モジュール化や結合の観点からも最初からメソッド定義していくのが正しい

UFCSはそれが出来ないあるいは間違ったプログラミング設計によりフリー関数を多数作ってしまった間違った環境でメソッド呼び出ししたくなった時のみ必要とされる
具体的には歴史的な負の遺産でボロボロなC++が該当する
そのためC++ではUFCSを導入しようと今も悪あがきをしている

ほとんどの言語にUFCSがないのはそんなものを必要としないためだ
0659デフォルトの名無しさん
垢版 |
2024/04/12(金) 00:44:02.94ID:tVNhffJ+
モジュール化や結合の観点から、関数が一つの変数の型に紐づくのがそんなに優れているとはあんま思えんけどなあ
RustのAdd演算子とかrhsとlhsの型が違う時は演算子がlhsのみに紐つくことになってかなりキモい
0660デフォルトの名無しさん
垢版 |
2024/04/12(金) 02:47:17.34ID:DYhqcHWh
それはAddが交換法則の成り立つ二項演算子だからそう見えるにすぎない
AddAssignやSubやShlなど多くの演算は非対称
0661デフォルトの名無しさん
垢版 |
2024/04/12(金) 04:21:38.21ID:tVNhffJ+
いや別にSubでもDivでも左のみに紐づいているのはキモい
0662デフォルトの名無しさん
垢版 |
2024/04/12(金) 04:49:28.47ID:rUQyilnM
>>658
やっぱりUFCSじゃなくて名前空間の設計の問題にしか見えんね。
例としてc++を挙げているが、名前空間を使っているライブラリとかで問題になっている事例てあったっけ?

グローバルのフリー関数は影響範囲が広すぎて問題を引き起こすというなら、Rustのトレイルと同様に適切な名前空間を用意しないと関数を定義できないようにすればいいかと。
0663デフォルトの名無しさん
垢版 |
2024/04/12(金) 05:26:42.25ID:CIaMPOtu
>>662
トレイルではなくトレイト
トレイトは名前空間を用意するものというより、トレイトをuseすることでそのトレイトにより実装されるメソッドが使えるようになるだけ
0664デフォルトの名無しさん
垢版 |
2024/04/12(金) 07:31:40.11ID:rUQyilnM
>>663
だったらなおさら>662だけの話かと。名前空間で「メソッド空間」を管理するのをRustは「トレイト」で管理しているだけにしか見えないね。
0665デフォルトの名無しさん
垢版 |
2024/04/12(金) 12:27:40.08ID:OadUyd3M
>>659
>モジュール化や結合の観点から、関数が一つの変数の型に紐づくのがそんなに優れているとはあんま思えんけどなあ

同意
0667デフォルトの名無しさん
垢版 |
2024/04/12(金) 12:43:39.99ID:6xQx5uEa
>>665
オブジェクト指向を全否定するキチガイか
クラスのある言語もクラスのないGoやRustなどの言語も
一つの変数の型に関数を紐づけることがプログラミング言語の中核機能だ
0668デフォルトの名無しさん
垢版 |
2024/04/12(金) 13:04:32.76ID:qd6Rxygz
とりあえず感覚で一行目から罵倒する人
0669デフォルトの名無しさん
垢版 |
2024/04/12(金) 15:24:23.71ID:XC+pkKeZ
>>667
>一つの変数の型に関数を紐づけることがプログラミング言語の中核機能だ
オブジェクト指向前提思考?
0670デフォルトの名無しさん
垢版 |
2024/04/12(金) 16:22:22.83ID:RDQRwL9V
>ほとんどの言語がこの方式なのに何を気持ち悪がっているのだろう
からの
>UFCSはメソッド名空間の汚染であるため、まともな言語では採用されていない。
schizoかな?
0675デフォルトの名無しさん
垢版 |
2024/04/12(金) 23:58:18.71ID:lpyrPPhz
>>667
つジェネリック
0676デフォルトの名無しさん
垢版 |
2024/04/13(土) 04:39:15.20ID:0YGiYUZr
ジェネリックにも同じように安全に適用できるのはRustにトレイト境界があるおかげか
0677デフォルトの名無しさん
垢版 |
2024/04/13(土) 07:36:48.57ID:beXAxXwF
トレイト境界はc++ conceptみたいに同じ関数集合ならOKなんだっけ?

柔軟性のために外延性は欲しいところ。
0678デフォルトの名無しさん
垢版 |
2024/04/13(土) 08:07:59.96ID:S51MIqUj
異なる型間の共通項をトレイトとして切り出すだけでよく
コードを美しく整理して保守性を高めやすい
0680デフォルトの名無しさん
垢版 |
2024/04/13(土) 13:36:34.54ID:F3jinTSj
143 デフォルトの名無しさん 2024/04/07(日) 19:27
純関数型言語でなくても
モダンなプログラミング言語
Go、Rust、Zig、Nim、Julia、Elixirなどは
クラスおよびその継承を言語仕様から排除しておりクラスは存在しない

それら各々の言語は全く異なる方針を採っている言語だがクラス排除だけは全てが同じ方針である
クラスとその継承は悪手であるとプログラミング言語界では結論が出ている
0681デフォルトの名無しさん
垢版 |
2024/04/13(土) 16:56:52.49ID:L60jXWVE
継承がなくても構造体にメソッドついてたら実質クラスだろ
関数に構造体渡してたらそれはクラスじゃないけど
0682デフォルトの名無しさん
垢版 |
2024/04/14(日) 23:56:10.96ID:RjsA2T1t
>>681
構造体にメソッドが付くことはカプセル化と言う
クラス=カプセル化+実装継承 なのでクラスとカプセル化は異なる

このクラスを成り立たせている実装継承が悪であるためにモダンな言語群がクラスを採用しなかった
実装継承とは具体型が別の具体型を継承することを指す
クラスでは派生クラスが基底クラスを継承するため悪の実装継承となる

正しい方法はインタフェイスやトレイトなどの抽象型からのみ継承する
つまりクラスを完全に排除できるためモダンな言語群にクラスはない
0683デフォルトの名無しさん
垢版 |
2024/04/15(月) 00:05:55.58ID:R9iMDmBn
用語も色々。
Rust で言うところのトレイトみたいなやつを Haksell とかでは型クラスって呼んでるし、
JavaScript のクラスの実体は (特定のプロトタイプに紐づいたオブジェクトを生成するための) 関数。
極論すればクラスと名付けたものがクラス。

Rust でクラスと呼んでない以上はもう別概念として捉えるしかしょうがないだろ。
C++ のクラス的なことの一部を Rust でも「可能ではある」というという主張なら賛成するけど、
クラスとは何かを定義せずにクラスかどうかを論じても無意味。
0684デフォルトの名無しさん
垢版 |
2024/04/15(月) 00:26:07.32ID:rd9697wK
型クラスとクラスは全く異なるので混乱しない
クラスとはクラス継承すなわち親クラスから子クラスへの実装継承できるものを指す
JavaScriptはプロトタイプを親として実装継承するためクラス
一方でRustにクラスはない
0685デフォルトの名無しさん
垢版 |
2024/04/15(月) 01:47:00.44ID:YLFAz6O4
クラスとは何か?継承とは何か?
こういう基本的な概念を特定言語の実装から離れて理解しようとしない限り何を言っても虚しい

>>681が一番まとも
0686デフォルトの名無しさん
垢版 |
2024/04/15(月) 01:58:25.85ID:CPtYka/u
話は非常に単純
具体的な型から具体的な型への継承が実装継承でこれがよくない
classは具体的な型superclassから具体的な型subclassへの継承があるから実装継承
interfaceやtraitは具体的な型ではなく抽象的な型なので該当しない
最近の言語がclassのみ採用しなかった理由はその違い
0688デフォルトの名無しさん
垢版 |
2024/04/15(月) 03:16:04.95ID:0QcDOjSQ
Javaの生みの親であるJames Goslingも、
「もう一度最初からJavaを作り直すとしたら、どこを変更したいですか?」に対して、
「クラスを除外するでしょうね」と答えている。
その理由は、クラス継承が実装継承となっているためで、この設計を後悔していて、インターフェースによる継承が望ましいと述べている。
0691デフォルトの名無しさん
垢版 |
2024/04/15(月) 12:54:52.68ID:f4iHJAq/
クラス継承のある言語でも今はクラス継承を使わない設計するのが良いとされてるので要らんよな
0693デフォルトの名無しさん
垢版 |
2024/04/16(火) 07:27:41.72ID:10PaZXAR
>>691
言語仕様としてあった方が良いということ。
0694デフォルトの名無しさん
垢版 |
2024/04/16(火) 07:42:24.51ID:KU96szRc
馬鹿が使うとクソになる仕様がある言語は馬鹿をチームに入れただけで開発が即破綻するからクソ
0695デフォルトの名無しさん
垢版 |
2024/04/16(火) 08:43:42.78ID:OvO8gS8m
Javaの生みの親も言ってるようにクラス継承の機能はない方がいい
なくても困らない
あると問題を引き起こす
0696デフォルトの名無しさん
垢版 |
2024/04/16(火) 09:30:25.53ID:YlYBNC7y
そういうのは話半分に聞いておけばいいよ
nullを使ったのは失敗だったとか
後からそれらしいことを言ってるだけ

javaはクラスと継承が無くなったらまともに機能しない
interfaceにデフォルト実装がなかったので全部自前かコンポジションで実装することになったはず
0698デフォルトの名無しさん
垢版 |
2024/04/16(火) 09:55:41.24ID:YlYBNC7y
最初はなかったしずっと取り入れなかったのはそれがJAVA風じゃなかったから

今JAVAが生き残ってるのは最初の設計思想が世間に受け入れられたからであって
後から○○無くせばよかったと言うのは誤りで浅はか

NULLを無くせばよかったと言うが当時メジャーな手法でそれの代替手段がなかったのと同じ
0705デフォルトの名無しさん
垢版 |
2024/04/16(火) 22:20:54.32ID:pbIQ4i0L
基底クラスで保証してる内部条件を継承クラスで壊されやすい

Javaは基本的に全部オーバーライド可能でprivateとfinalで変な継承を抑えてたけど
C#はabstract/virtualかつsealedでない要素だけオーバーライド可能になってたと思う
古い知識だから最近の動向は知らない
0711デフォルトの名無しさん
垢版 |
2024/04/19(金) 17:19:41.25ID:QdSz4ItG
隙間作って床下チェスト収納ってできなくなった?動画みてるけどうまくできん
0712デフォルトの名無しさん
垢版 |
2024/04/20(土) 17:39:26.03ID:pCmD4UWo
shift-jisのファイルをBufReaderで1行ずつ読み込もうと思ったら無理でOKが流れてこない
全部読んでデコードして\nで切り分けるしかないの?
0715デフォルトの名無しさん
垢版 |
2024/04/20(土) 22:28:20.55ID:pZNdwQSZ
std::io::BufReader::new(encoding_rs_io::DecodeReaderBytesBuilder::new().encoding(Some(encoding_rs::SHIFT_JIS)).build(std::fs::File::open(SJIS_FILE)?)).lines()
0718デフォルトの名無しさん
垢版 |
2024/04/21(日) 18:25:05.39ID:GAd5jyBU
decoderが挟まるだけだよ

// UTF8の場合
let file = File::open(path)?;
let reader = BufReader::new(file);
for line in reader.lines() {

// SJISの場合
let file = File::open(path)?;
let decoder = DecodeReaderBytesBuilder::new()
 .encoding(Some(SHIFT_JIS))
 .build(file);
let reader = BufReader::new(decoder);
for line in reader.lines() {
0719デフォルトの名無しさん
垢版 |
2024/04/22(月) 06:09:19.12ID:kZ9sSSe5
バッファリングせず丸ごと贅沢にメモリ使っていいなら単純
let bytes = fs::read(path)?;
let (s, _, _) = SHIFT_JIS.decode(&bytes);
let reader = BufReader::new(s.as_bytes());
for line in reader.lines() {
0720デフォルトの名無しさん
垢版 |
2024/04/22(月) 20:07:02.52ID:g+YSHIF5
コマンドラインからファイル名取るようにしたらパニック
windowsで文字コードが違うかららしいけどこういうバッドノウハウを開発者に積み重ねていかないと使えないのはめんどい
0722デフォルトの名無しさん
垢版 |
2024/04/22(月) 21:19:42.71ID:g+YSHIF5
知らないとそういう反応するんだろうけど
std::env::args_osを使ってOsStringを取って対処する必要があるんだよ
勉強になっただろ?
0723デフォルトの名無しさん
垢版 |
2024/04/22(月) 21:24:48.26ID:g+YSHIF5
日本人だから日本語名が付いたファイルを扱う機会に恵まれてるからこういうことに出会える
アメリカ人だったらこういうのに出会わないでコーディングしてリリースしてるだろう

世界中で使ったらパスの問題で落ちるプログラムがガンガン量産されている
0724デフォルトの名無しさん
垢版 |
2024/04/22(月) 23:12:07.98ID:ljq3CdpU
>>722
チュートリアルレベルの基礎を
バッドノウハウwとか
積み重ねでいかないといけないwとか
言ってるから何言ってんのwになる
0725デフォルトの名無しさん
垢版 |
2024/04/22(月) 23:32:38.83ID:cr/ZTax6
>>720
Rustのパニックはどの関数で何をした時に発生するかすべてドキュメントに明記されてるのでパニックはプログラミングした側に問題がある
さらにパニックがソースコードの何行目のどの場所で起きたのかもわかるのですぐにそのバクを調査できる
まずは基礎知識を身につけよう

>>722
std::env::argsのドキュメントにどういう時にパニックが起きるか書いてある
さらに対処方法はargs_osを使えと明記されている
ドキュメントを見よう
0727デフォルトの名無しさん
垢版 |
2024/04/22(月) 23:42:55.88ID:g+YSHIF5
リリースした後の実行時のpanicを有り難がる信者

Rustのライブラリの思想がいまいち馴染みにくいと言うか素人が作るとこうなりますと言う見本
0728デフォルトの名無しさん
垢版 |
2024/04/22(月) 23:57:01.81ID:kZ9sSSe5
>>722
Rustではそんな個別の知識を知らなくてもpanicさせた関数が分かるから
その関数のドキュメントのpanicの項目を見れば明記されてる
他の言語と比べても良い環境
0729デフォルトの名無しさん
垢版 |
2024/04/23(火) 00:03:29.34ID:aheV4X/O
馬鹿と話しててもらちが開かない

世界中で使ったらパスの問題で落ちるプログラムがガンガン量産されているのは事実
お前らそれを一個一個プルリク送ったりしてるのか?
0730デフォルトの名無しさん
垢版 |
2024/04/23(火) 00:13:45.98ID:aheV4X/O
所有権とか導入してバグを静的に弾こうとしてる割にはこういうところではガバガバ
世界中で英語じゃないwindows環境でpanicが起こるコードが蔓延してる

非合理的
0731デフォルトの名無しさん
垢版 |
2024/04/23(火) 00:34:48.42ID:tNw43TTr
そんなことより The Embedded Rust 読み始めたんです。
冒頭からリンカで割り込みベクタマップの取り方やら panic 無効にしての main 関数導入やら、HAL は自分でこさえるんだよね?と言わんばかりの内容。
おおむかしのMCU開発環境みたいで嫌いじゃないけど、arch 対応してないと敷居高いねこれ。
0732デフォルトの名無しさん
垢版 |
2024/04/23(火) 09:44:34.04ID:SlAsUTut
公式チュートリアルすらまともに読めないお馬鹿さんは自分が使う道具を間違えててもそれを言語のせいにしたがる
プラスドライバーを使うべき状況でマイナスドライバーを使って使いにくいじゃねーかこんな道具は非合理的などと言い出す
ヤバすぎね?
0733デフォルトの名無しさん
垢版 |
2024/04/23(火) 11:06:58.83ID:PMnHeW+x
>>725
なんでコンパイル時にエラーにできないんだろう?

Rustのポリシーからすれば安全優先でargs_osだけにしてargsは削除すべきでは?
c++じゃあるまいに、コマンドラインのデータが常に正しいunicodeだと信用するプログラムを書けるとか、セキュリティーホールになりかねんと思うけど。
0737デフォルトの名無しさん
垢版 |
2024/04/23(火) 15:43:54.29ID:3Xc7JqWG
>>733
>なんでコンパイル時にエラーにできないんだろう?
出来るわけないだろw
実行時に与えられる外部入力をコンパイル時にどうやって判定するんだよw
バカすぎる
0738デフォルトの名無しさん
垢版 |
2024/04/23(火) 16:19:44.91ID:1rwyWp7B
しいて言えばargs()を使う方が特殊ケースなのにデフォルトの名前を引き継いだのは設計ミス
もう治る見込みはないからargs_os()を使おうねってだけだけど
レスを投稿する


ニューススポーツなんでも実況