Rust part23
■ このスレッドは過去ログ倉庫に格納されています
>>667 >一つの変数の型に関数を紐づけることがプログラミング言語の中核機能だ オブジェクト指向前提思考? >ほとんどの言語がこの方式なのに何を気持ち悪がっているのだろう からの >UFCSはメソッド名空間の汚染であるため、まともな言語では採用されていない。 schizoかな? >>670 虚言癖などと同じパーソナリティ障害の一種だから生温かく見守ってやれ おじいちゃんは昼だけ起きてて 夕方を過ぎると寝てしまう ジェネリックにも同じように安全に適用できるのはRustにトレイト境界があるおかげか トレイト境界はc++ conceptみたいに同じ関数集合ならOKなんだっけ? 柔軟性のために外延性は欲しいところ。 異なる型間の共通項をトレイトとして切り出すだけでよく コードを美しく整理して保守性を高めやすい 143 デフォルトの名無しさん 2024/04/07(日) 19:27 純関数型言語でなくても モダンなプログラミング言語 Go、Rust、Zig、Nim、Julia、Elixirなどは クラスおよびその継承を言語仕様から排除しておりクラスは存在しない それら各々の言語は全く異なる方針を採っている言語だがクラス排除だけは全てが同じ方針である クラスとその継承は悪手であるとプログラミング言語界では結論が出ている 継承がなくても構造体にメソッドついてたら実質クラスだろ 関数に構造体渡してたらそれはクラスじゃないけど >>681 構造体にメソッドが付くことはカプセル化と言う クラス=カプセル化+実装継承 なのでクラスとカプセル化は異なる このクラスを成り立たせている実装継承が悪であるためにモダンな言語群がクラスを採用しなかった 実装継承とは具体型が別の具体型を継承することを指す クラスでは派生クラスが基底クラスを継承するため悪の実装継承となる 正しい方法はインタフェイスやトレイトなどの抽象型からのみ継承する つまりクラスを完全に排除できるためモダンな言語群にクラスはない 用語も色々。 Rust で言うところのトレイトみたいなやつを Haksell とかでは型クラスって呼んでるし、 JavaScript のクラスの実体は (特定のプロトタイプに紐づいたオブジェクトを生成するための) 関数。 極論すればクラスと名付けたものがクラス。 Rust でクラスと呼んでない以上はもう別概念として捉えるしかしょうがないだろ。 C++ のクラス的なことの一部を Rust でも「可能ではある」というという主張なら賛成するけど、 クラスとは何かを定義せずにクラスかどうかを論じても無意味。 型クラスとクラスは全く異なるので混乱しない クラスとはクラス継承すなわち親クラスから子クラスへの実装継承できるものを指す JavaScriptはプロトタイプを親として実装継承するためクラス 一方でRustにクラスはない クラスとは何か?継承とは何か? こういう基本的な概念を特定言語の実装から離れて理解しようとしない限り何を言っても虚しい >>681 が一番まとも 話は非常に単純 具体的な型から具体的な型への継承が実装継承でこれがよくない classは具体的な型superclassから具体的な型subclassへの継承があるから実装継承 interfaceやtraitは具体的な型ではなく抽象的な型なので該当しない 最近の言語がclassのみ採用しなかった理由はその違い RustにはJavaのクラスはありません RustはJavaではないからです あたまいいね Javaの生みの親であるJames Goslingも、 「もう一度最初からJavaを作り直すとしたら、どこを変更したいですか?」に対して、 「クラスを除外するでしょうね」と答えている。 その理由は、クラス継承が実装継承となっているためで、この設計を後悔していて、インターフェースによる継承が望ましいと述べている。 クラス継承のある言語でも今はクラス継承を使わない設計するのが良いとされてるので要らんよな それは単に使い分けが出来ない馬鹿な子向けの説明だぞ >>691 言語仕様としてあった方が良いということ。 馬鹿が使うとクソになる仕様がある言語は馬鹿をチームに入れただけで開発が即破綻するからクソ Javaの生みの親も言ってるようにクラス継承の機能はない方がいい なくても困らない あると問題を引き起こす そういうのは話半分に聞いておけばいいよ nullを使ったのは失敗だったとか 後からそれらしいことを言ってるだけ javaはクラスと継承が無くなったらまともに機能しない interfaceにデフォルト実装がなかったので全部自前かコンポジションで実装することになったはず >>696 interfaceにデフォルト実装を後から入れたので問題なくなった そうなるとclass継承は不要 最初はなかったしずっと取り入れなかったのはそれがJAVA風じゃなかったから 今JAVAが生き残ってるのは最初の設計思想が世間に受け入れられたからであって 後から○○無くせばよかったと言うのは誤りで浅はか NULLを無くせばよかったと言うが当時メジャーな手法でそれの代替手段がなかったのと同じ インターフェイスにも集合で言うところの外延性は欲しいところ。 基底クラスで保証してる内部条件を継承クラスで壊されやすい Javaは基本的に全部オーバーライド可能でprivateとfinalで変な継承を抑えてたけど C#はabstract/virtualかつsealedでない要素だけオーバーライド可能になってたと思う 古い知識だから最近の動向は知らない Unreal EngineがRist対応するんだってね 隙間作って床下チェスト収納ってできなくなった?動画みてるけどうまくできん shift-jisのファイルをBufReaderで1行ずつ読み込もうと思ったら無理でOKが流れてこない 全部読んでデコードして\nで切り分けるしかないの? read_lineはutf-8じゃないと無理だけどread_untilならバイト列で1行ずつ取れそう >>712 encoding_rs_io::DecodeReaderBytesBuilderでsjisをdecodeするreaderを作る あとはreader.lines()で同じ std::io::BufReader::new(encoding_rs_io::DecodeReaderBytesBuilder::new().encoding(Some(encoding_rs::SHIFT_JIS)).build(std::fs::File::open(SJIS_FILE)?)).lines() BufReaderもFile::openもそのまま使える点がいいね >>715 ありがとうございます 動作確認しました ちょっと仕組みがむずかしいですね 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() { バッファリングせず丸ごと贅沢にメモリ使っていいなら単純 let bytes = fs::read(path)?; let (s, _, _) = SHIFT_JIS.decode(&bytes); let reader = BufReader::new(s.as_bytes()); for line in reader.lines() { コマンドラインからファイル名取るようにしたらパニック windowsで文字コードが違うかららしいけどこういうバッドノウハウを開発者に積み重ねていかないと使えないのはめんどい 知らないとそういう反応するんだろうけど std::env::args_osを使ってOsStringを取って対処する必要があるんだよ 勉強になっただろ? 日本人だから日本語名が付いたファイルを扱う機会に恵まれてるからこういうことに出会える アメリカ人だったらこういうのに出会わないでコーディングしてリリースしてるだろう 世界中で使ったらパスの問題で落ちるプログラムがガンガン量産されている >>722 チュートリアルレベルの基礎を バッドノウハウwとか 積み重ねでいかないといけないwとか 言ってるから何言ってんのwになる >>720 Rustのパニックはどの関数で何をした時に発生するかすべてドキュメントに明記されてるのでパニックはプログラミングした側に問題がある さらにパニックがソースコードの何行目のどの場所で起きたのかもわかるのですぐにそのバクを調査できる まずは基礎知識を身につけよう >>722 std::env::argsのドキュメントにどういう時にパニックが起きるか書いてある さらに対処方法はargs_osを使えと明記されている ドキュメントを見よう >>724-725 こういう低能がありがたがるんだろうな 信者としか言いようがないw リリースした後の実行時のpanicを有り難がる信者 Rustのライブラリの思想がいまいち馴染みにくいと言うか素人が作るとこうなりますと言う見本 >>722 Rustではそんな個別の知識を知らなくてもpanicさせた関数が分かるから その関数のドキュメントのpanicの項目を見れば明記されてる 他の言語と比べても良い環境 馬鹿と話しててもらちが開かない 世界中で使ったらパスの問題で落ちるプログラムがガンガン量産されているのは事実 お前らそれを一個一個プルリク送ったりしてるのか? 所有権とか導入してバグを静的に弾こうとしてる割にはこういうところではガバガバ 世界中で英語じゃないwindows環境でpanicが起こるコードが蔓延してる 非合理的 そんなことより The Embedded Rust 読み始めたんです。 冒頭からリンカで割り込みベクタマップの取り方やら panic 無効にしての main 関数導入やら、HAL は自分でこさえるんだよね?と言わんばかりの内容。 おおむかしのMCU開発環境みたいで嫌いじゃないけど、arch 対応してないと敷居高いねこれ。 公式チュートリアルすらまともに読めないお馬鹿さんは自分が使う道具を間違えててもそれを言語のせいにしたがる プラスドライバーを使うべき状況でマイナスドライバーを使って使いにくいじゃねーかこんな道具は非合理的などと言い出す ヤバすぎね? >>725 なんでコンパイル時にエラーにできないんだろう? Rustのポリシーからすれば安全優先でargs_osだけにしてargsは削除すべきでは? c++じゃあるまいに、コマンドラインのデータが常に正しいunicodeだと信用するプログラムを書けるとか、セキュリティーホールになりかねんと思うけど。 >>734 緊急停止して「安全ですよ」はちょっと…… >>733 セキュリティホールにならない 異常データに対して止まり動作を続けない >>733 >なんでコンパイル時にエラーにできないんだろう? 出来るわけないだろw 実行時に与えられる外部入力をコンパイル時にどうやって判定するんだよw バカすぎる しいて言えばargs()を使う方が特殊ケースなのにデフォルトの名前を引き継いだのは設計ミス もう治る見込みはないからargs_os()を使おうねってだけだけど 一応argsをdeprecatedにして徐々に移行させていくのはできるだろうけど 特に提案もなさそうだし誰も困ってないんじゃないかな そもそもほとんどのケースでclapとか使うだろうし >>733 >>>725 >なんでコンパイル時にエラーにできないんだろう? むしろ何でできると思ってるんだろう。謎 環境変数もvarとvar_osがあるから慣れろとしか言えない OS標準が全部utf-8になる未来もありえるし >>741 紛らわしいけどvar/var_osとvars/vars_osは別物だよ varはinvalid UTF-8でもエラーハンドリング可 varsはpanic argsは引数にUTF-8以外はダメだよって前提で使える余地がまだあるけど varsはそんな前提をおける状況はほぼなくてよりたちが悪い >>741 >OS標準が全部utf-8になる未来もありえるし 10年前のその未来予想が大外れしてるから今となっては設計ミスとしか言いようがない もう10年経ったとしても状況は変わらないと思う >>732 公式チュートリアルまともに読めるならC++で良いからな よーわからんけど10年ぐらい前はすべてutf16になると考えられてたのでは? どう考えてもstd::env::argsを非推奨にしろとは思うけどね 欧米人がつくるとこんなことになるんだ 普通は2種類の扱いがある ・実行環境に合わせて自動的に内部での標準形式に変換 か ・何もしない 何もしないならOSから受け取ったままOSに渡して置けば大体問題はない 第三の愚策がRust 受け取ったままそのままOSに渡してもコケる Rustは何もしないように見えるけど何かしてるからコケるのでは? >>745 間違いだらけだな 世界の標準はUTF8 ウェブももちろんUTF8 RustもUTF8 Rustがこの件でコケることはない きちんと各関数の仕様が明記されていて常に正確に動作している >>747 一般的なパニックは色んな意味合いがあるけど Rustでのパニックは関数ドキュメントに明記されている想定のことが起きた ライブラリ関数の作成者はパニックを発生させる時の条件をドキュメントに明記しなければならない だからそれを利用する各プログラマーにとっても想定内のことのみパニックが起きる >>745 勘違いしてることが多すぎてもう笑うしかないwww >>745 >よーわからんけど10年ぐらい前はすべてutf16になると考えられてたのでは? 30年以上前にUCS-2がWindowsやJavaに採用された時代のことを言ってるのかな? (UTF-16と違ってUCS-2は固定幅なので今でもまだ使い所はあるけど) ↓これが15年くらい前のUTF-16に対する一般的な認識 https://softwareengineering.stackexchange.com/questions/102205/ utf-16はUnicode 2.0(1996年7月)のサロゲートペア導入でutf-8に逆転されたな しばらくはBMPしか使われなかったから耐えてたけど 1990代前半に始動したJavaは運が悪かった >>749 そう書きながら何もまともなレスすらできないレス乞食 Rust界隈では狂信者がいてそいつらはまともに反論すら出来ないけど Rustが正しいRustが正しいと繰り返すばかり >>737 >>740 windows環境とかunicode以外が混ざる環境でargをコンパイルエラーにできないのかね。 そもそもargは廃止していい。 >>746 なるほど。 「RustはWindowsをケアする気が無い」 ということですか。 >>754 Windowsでも設定すればUTF-8になるしLinuxだってUTF-8以外に自由に変えられるわけだから、そんな判定は不可能 まぁ廃止していいには同意するけども Windows は Windows の機能として文字コードの管理はしてるが歴史的事情でツギハギのグダグダ。 今の Linux はおおよそ UTF-8 で統一されているけど規約で縛っているだけで、 OS としてはバイナリ単位で素通し。 保証としてはあてにならん。 コンパイルエラーにできないから引数まで廃止するとか原理主義もここまで来てんのか。 >>754 無知にもほどがある! unicodeとUTF-8が区別できない Windowsに限らずLinuxでもmacOSでも非UTF-8の引数や環境変数が使われる可能性があるのは同じなんだがそんな常識を知らない >>760 そんなんだったらなおさらのこと、Rustの安全指向に従ってargs_osだけにすべきで、argsは廃止にすべきだろ。 Rustはメモリ安全しか興味無いんかね。 保証できるものはするに越したことはないけど (充分に実行コストが小さい形では) できんからしゃーない。 どうでもいい話でもめてるな Rustはすべて提供してドキュメントにそるぞれ明記しているのだから使う側の各自の問題 こちらはUTF8環境でしか使われないのでargs()のみ利用している https://github.com/rust-lang/rust/issues/91226#issuecomment-1034188905 関係する議論はこのあたりかな もともとはargs/varsをパニックさせずに無視するか置換してほしいって要望だったが 無視や置換はセキュリティ上問題になる可能性があるので却下 varsは将来的にdeprecatedにするかもと言っている なんでargsもdeprecatedにすべきだろって提案すれば通る可能性はあるかもね 正しく使え論は暴論だな それが許されるならスマートポインタやGCは出ずみんな今でも生ポインタを使ってる >>765 生ポインタは安全ではないから全く違う argsは常に安全 常に自動変換したほうが安全だけどな 開発者が特別コードを書く必要もない Rustはファイル名も自動変換なんかしていないように 変換するかどうかは各自の自由裁量であるところが非常に良い点だよ 自分の好みと合わないからといって批判している人たちは頭がおかしいので相手にしても無駄なのだろうけど ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる