公式
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/
Rust part23
■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
2024/02/23(金) 17:37:52.13ID:CheDQupm622デフォルトの名無しさん
2024/04/11(木) 09:02:17.34ID:NXydgA7G >>621
君の感性がおかしいんじゃね?
NimもZigもRustもPythonと同じ標準方式
foo(receiver, arg1, arg2, ..)
または
receiver.foo(arg1, arg2, ..)
君の感性がおかしいんじゃね?
NimもZigもRustもPythonと同じ標準方式
foo(receiver, arg1, arg2, ..)
または
receiver.foo(arg1, arg2, ..)
623デフォルトの名無しさん
2024/04/11(木) 09:02:43.98ID:7FNbL3Xb >>618
なるほどちょっと納得した
なるほどちょっと納得した
624デフォルトの名無しさん
2024/04/11(木) 09:11:33.28ID:azFLg2co >>622
実質Pythonフォロワーを含めて言われても…
実質Pythonフォロワーを含めて言われても…
625デフォルトの名無しさん
2024/04/11(木) 09:14:09.83ID:azFLg2co C言語のときはOOPじゃなくてただの関数の第一引数に構造体を指定してた
それがOOP言語になって指定不要になった
それがまたC言語時代に逆戻り
それがOOP言語になって指定不要になった
それがまたC言語時代に逆戻り
626デフォルトの名無しさん
2024/04/11(木) 09:15:22.73ID:NXydgA7G627デフォルトの名無しさん
2024/04/11(木) 09:17:05.47ID:azFLg2co あらかじめ書いておくけどreceiver.Foo()じゃないメソッドがあるのは
receiverがNullの可能性がある場合でそう設計されてただけ
receiverがNullの可能性がある場合でそう設計されてただけ
628デフォルトの名無しさん
2024/04/11(木) 09:20:43.92ID:NXydgA7G 代案を出せないってことはRustに言いがかりをつけてるだけだな
629デフォルトの名無しさん
2024/04/11(木) 09:24:05.56ID:azFLg2co 別に他のOOP言語のように関数にマークつけてこれはこのインスタンスのメソッドですよと言えばいいだけ
その表記は時間をかけて考えたらいい
その表記は時間をかけて考えたらいい
630デフォルトの名無しさん
2024/04/11(木) 09:30:34.30ID:cvuvfjXO >>625
レシーバは必ず必要
Goでも
func (receiver ReceiverType) Foo(引数…) {
return receiver.xxx + receiver.yyy
}
と書く
レシーバ指定不要という主張は理解できない
レシーバは必ず必要
Goでも
func (receiver ReceiverType) Foo(引数…) {
return receiver.xxx + receiver.yyy
}
と書く
レシーバ指定不要という主張は理解できない
631デフォルトの名無しさん
2024/04/11(木) 09:45:56.75ID:gYo8nOa5 レシーバの名前を自由につけられると人によってバラバラで読みづらいんだよな
selfなら必ず揃うし予約語としてシンタックスハイライトされるのもいい
selfなら必ず揃うし予約語としてシンタックスハイライトされるのもいい
632デフォルトの名無しさん
2024/04/11(木) 09:51:28.66ID:azFLg2co いやいやw
無知って怖いねとしか…
無知って怖いねとしか…
633デフォルトの名無しさん
2024/04/11(木) 09:52:17.20ID:azFLg2co634デフォルトの名無しさん
2024/04/11(木) 10:19:57.47ID:UmgPKlgb635デフォルトの名無しさん
2024/04/11(木) 10:33:59.60ID:Nlu6ipA3636デフォルトの名無しさん
2024/04/11(木) 11:00:57.82ID:azFLg2co IDころころお爺さんは明らかに話を理解できないな
637デフォルトの名無しさん
2024/04/11(木) 11:23:46.71ID:CaCoKmZ3 Rustは小文字selfが値、大文字Selfが型を示していて使いやすいよな
型指定にSelfやSelf::Itemなど使えるだけでなく
Self::CONSTANT_NAMEやSelf::function_without_self()などの呼び出しもできる
Selfによって自分自身であるとわかりコードが読みやすい
型名変更の影響も受けず読みやすいメンテしやすい
ダメな言語だと以下のダメなパターンがある
・Selfの代わりに型名を書かなくてはいけない言語 (自分自身だとわかりにくくメンテ性も悪い)
・Selfの代わりにself(やthis)を用いてしまう言語 (値と型の区別がつかない)
・Selfを使わずに名前空間の区別がない言語 (間違いが起きやすく自分自身だとわかりくくメンテ性が悪い)
型指定にSelfやSelf::Itemなど使えるだけでなく
Self::CONSTANT_NAMEやSelf::function_without_self()などの呼び出しもできる
Selfによって自分自身であるとわかりコードが読みやすい
型名変更の影響も受けず読みやすいメンテしやすい
ダメな言語だと以下のダメなパターンがある
・Selfの代わりに型名を書かなくてはいけない言語 (自分自身だとわかりにくくメンテ性も悪い)
・Selfの代わりにself(やthis)を用いてしまう言語 (値と型の区別がつかない)
・Selfを使わずに名前空間の区別がない言語 (間違いが起きやすく自分自身だとわかりくくメンテ性が悪い)
638デフォルトの名無しさん
2024/04/11(木) 11:57:27.19ID:17a5lmDN 関係ない長文でごまかすフェーズに入ってるってことは内心恥ずかしくて死にそうになってるんやろうな……
639デフォルトの名無しさん
2024/04/11(木) 11:57:34.08ID:6x2Zth+c 複オジは見えてる範囲が狭過ぎる
だから長文になればなるほど勘違い度や害悪度が高まる
だから長文になればなるほど勘違い度や害悪度が高まる
640デフォルトの名無しさん
2024/04/11(木) 12:47:47.10ID:ZruVErXu 自分が使ってきた特殊な仕様の言語に慣れ親しんでいると
一般的なの仕様のRustに違和感を感じて文句をつけたくなる気持ちはわからんでもない
Rustを叩く前に視野を広く持つべきだな
Rustの仕様はよく考えられ機能的に洗練されている
一般的なの仕様のRustに違和感を感じて文句をつけたくなる気持ちはわからんでもない
Rustを叩く前に視野を広く持つべきだな
Rustの仕様はよく考えられ機能的に洗練されている
641デフォルトの名無しさん
2024/04/11(木) 12:59:00.66ID:AZdBjU6j >>640
Rustに無いからといってUFCS叩くのはさすがにアホかと。
Rustに無いからといってUFCS叩くのはさすがにアホかと。
642デフォルトの名無しさん
2024/04/11(木) 13:15:55.80ID:4f6XcC0j そんなことよりError::sourceの戻り値に'static要求されるのってなんでなん
643デフォルトの名無しさん
2024/04/11(木) 15:57:20.01ID:R8LZpbjl >>642
エラー返す時に参照してるリソースをつかんだままにしたくないからじゃない
エラー返す時に参照してるリソースをつかんだままにしたくないからじゃない
644デフォルトの名無しさん
2024/04/11(木) 15:59:23.14ID:v1XXdeLJ くだらないレスは頻繁にするのにまともな質問が来ると急に黙るの面白い
645デフォルトの名無しさん
2024/04/11(木) 16:41:03.54ID:KhnNkcJ8 まともな質問にいつものノリで適当に答えて嘘だったら良くないしね
646デフォルトの名無しさん
2024/04/11(木) 17:01:08.25ID:TWMZ6q+3 そっか
俺の答えも間違ってたしな
正しくはdowncastのために必要らしい
詳しくはfix_errorのRFC見て
俺の答えも間違ってたしな
正しくはdowncastのために必要らしい
詳しくはfix_errorのRFC見て
647デフォルトの名無しさん
2024/04/11(木) 17:41:58.72ID:McIjmFt1 Playgroundがwebsocket接続のタイムアウトエラー(504:Gateway Time-out)で全然動かないんだが俺環?
648デフォルトの名無しさん
2024/04/11(木) 17:48:38.15ID:McIjmFt1649デフォルトの名無しさん
2024/04/11(木) 18:55:11.06ID:4f6XcC0j downcastなんて別にしないからいらねーよって思ったけど
そういえば内部で似たようなことやってるあれがあったな、どっちかっていうとあれのためか
ヒントありがとう
そういえば内部で似たようなことやってるあれがあったな、どっちかっていうとあれのためか
ヒントありがとう
650デフォルトの名無しさん
2024/04/11(木) 19:06:32.42ID:VFM//2+p 複おじはc++も使ってなかったんだな
651デフォルトの名無しさん
2024/04/11(木) 20:25:23.50ID:81s1BzdD >>641
UFCSはメソッド名空間の汚染であるため、まともな言語では採用されていない。
RustはUFCSを採用しないだけでなく、更に厳しく孤児ルールによってメソッド名空間の汚染を防いでる。
Rustでのメソッド追加拡張は、そのための新たなトレイトを用意することで、その利用空間に限定して安全に行うことができる。
UFCSはメソッド名空間の汚染であるため、まともな言語では採用されていない。
RustはUFCSを採用しないだけでなく、更に厳しく孤児ルールによってメソッド名空間の汚染を防いでる。
Rustでのメソッド追加拡張は、そのための新たなトレイトを用意することで、その利用空間に限定して安全に行うことができる。
652デフォルトの名無しさん
2024/04/11(木) 20:52:12.80ID:AZdBjU6j >>651
UFCSはそもそもメソッドとか無いんだから、ありもしないメソッド空間の汚染とか考えるだけ無駄。
それに、メソッド呼び出しは人間の思考パターン(大域から局所に絞り込む)に従った自然な記述方法なんだから、それを拡張困難なメソッドだけに限定するのは酷い制約かと。カス文法のPythonを思い浮かべますな。
UFCSはそもそもメソッドとか無いんだから、ありもしないメソッド空間の汚染とか考えるだけ無駄。
それに、メソッド呼び出しは人間の思考パターン(大域から局所に絞り込む)に従った自然な記述方法なんだから、それを拡張困難なメソッドだけに限定するのは酷い制約かと。カス文法のPythonを思い浮かべますな。
653デフォルトの名無しさん
2024/04/11(木) 21:02:41.98ID:81s1BzdD654デフォルトの名無しさん
2024/04/11(木) 21:15:01.99ID:mF0oHAZm 答えを教えてもらっているのにヒントありがとうというオジさんw
655デフォルトの名無しさん
2024/04/11(木) 21:16:29.71ID:2g+gCFiF メソッド名空間www
656デフォルトの名無しさん
2024/04/11(木) 21:54:13.50ID:AZdBjU6j >>653
それって単にメソッドだけ特別に名前空間を管理していという話で、UFCSだから問題になるという話では無いな。
もっとUFCSならではの問題点を指摘してくれ。
せめて関数が左作用ならUFCS捨ててもいいけど、どの言語も馬鹿のひとつ覚えで右作用を採用するからメソッドとかUFCSが重宝される。
それって単にメソッドだけ特別に名前空間を管理していという話で、UFCSだから問題になるという話では無いな。
もっとUFCSならではの問題点を指摘してくれ。
せめて関数が左作用ならUFCS捨ててもいいけど、どの言語も馬鹿のひとつ覚えで右作用を採用するからメソッドとかUFCSが重宝される。
657デフォルトの名無しさん
2024/04/11(木) 23:54:23.85ID:A4VQpdsZ アラビア語でコーディングすれば、入力左から右へ進むから右作用が思考の順になるぜ
アラビア語おすすめ
アラビア語おすすめ
658デフォルトの名無しさん
2024/04/12(金) 00:40:05.77ID:fvGN/jjJ >>656
それはメソッド呼び出しのメリット
モジュール化や結合の観点からも最初からメソッド定義していくのが正しい
UFCSはそれが出来ないあるいは間違ったプログラミング設計によりフリー関数を多数作ってしまった間違った環境でメソッド呼び出ししたくなった時のみ必要とされる
具体的には歴史的な負の遺産でボロボロなC++が該当する
そのためC++ではUFCSを導入しようと今も悪あがきをしている
ほとんどの言語にUFCSがないのはそんなものを必要としないためだ
それはメソッド呼び出しのメリット
モジュール化や結合の観点からも最初からメソッド定義していくのが正しい
UFCSはそれが出来ないあるいは間違ったプログラミング設計によりフリー関数を多数作ってしまった間違った環境でメソッド呼び出ししたくなった時のみ必要とされる
具体的には歴史的な負の遺産でボロボロなC++が該当する
そのためC++ではUFCSを導入しようと今も悪あがきをしている
ほとんどの言語にUFCSがないのはそんなものを必要としないためだ
659デフォルトの名無しさん
2024/04/12(金) 00:44:02.94ID:tVNhffJ+ モジュール化や結合の観点から、関数が一つの変数の型に紐づくのがそんなに優れているとはあんま思えんけどなあ
RustのAdd演算子とかrhsとlhsの型が違う時は演算子がlhsのみに紐つくことになってかなりキモい
RustのAdd演算子とかrhsとlhsの型が違う時は演算子がlhsのみに紐つくことになってかなりキモい
660デフォルトの名無しさん
2024/04/12(金) 02:47:17.34ID:DYhqcHWh それはAddが交換法則の成り立つ二項演算子だからそう見えるにすぎない
AddAssignやSubやShlなど多くの演算は非対称
AddAssignやSubやShlなど多くの演算は非対称
661デフォルトの名無しさん
2024/04/12(金) 04:21:38.21ID:tVNhffJ+ いや別にSubでもDivでも左のみに紐づいているのはキモい
662デフォルトの名無しさん
2024/04/12(金) 04:49:28.47ID:rUQyilnM >>658
やっぱりUFCSじゃなくて名前空間の設計の問題にしか見えんね。
例としてc++を挙げているが、名前空間を使っているライブラリとかで問題になっている事例てあったっけ?
グローバルのフリー関数は影響範囲が広すぎて問題を引き起こすというなら、Rustのトレイルと同様に適切な名前空間を用意しないと関数を定義できないようにすればいいかと。
やっぱりUFCSじゃなくて名前空間の設計の問題にしか見えんね。
例としてc++を挙げているが、名前空間を使っているライブラリとかで問題になっている事例てあったっけ?
グローバルのフリー関数は影響範囲が広すぎて問題を引き起こすというなら、Rustのトレイルと同様に適切な名前空間を用意しないと関数を定義できないようにすればいいかと。
663デフォルトの名無しさん
2024/04/12(金) 05:26:42.25ID:CIaMPOtu664デフォルトの名無しさん
2024/04/12(金) 07:31:40.11ID:rUQyilnM >>663
だったらなおさら>662だけの話かと。名前空間で「メソッド空間」を管理するのをRustは「トレイト」で管理しているだけにしか見えないね。
だったらなおさら>662だけの話かと。名前空間で「メソッド空間」を管理するのをRustは「トレイト」で管理しているだけにしか見えないね。
665デフォルトの名無しさん
2024/04/12(金) 12:27:40.08ID:OadUyd3M666デフォルトの名無しさん
2024/04/12(金) 12:33:34.40ID:rAepnpk2667デフォルトの名無しさん
2024/04/12(金) 12:43:39.99ID:6xQx5uEa668デフォルトの名無しさん
2024/04/12(金) 13:04:32.76ID:qd6Rxygz とりあえず感覚で一行目から罵倒する人
669デフォルトの名無しさん
2024/04/12(金) 15:24:23.71ID:XC+pkKeZ670デフォルトの名無しさん
2024/04/12(金) 16:22:22.83ID:RDQRwL9V >ほとんどの言語がこの方式なのに何を気持ち悪がっているのだろう
からの
>UFCSはメソッド名空間の汚染であるため、まともな言語では採用されていない。
schizoかな?
からの
>UFCSはメソッド名空間の汚染であるため、まともな言語では採用されていない。
schizoかな?
671デフォルトの名無しさん
2024/04/12(金) 17:02:05.38ID:oSrgtnnN それらの件でもRustの仕様が優秀すぎ
672デフォルトの名無しさん
2024/04/12(金) 20:51:13.79ID:NYkXEvAJ >>670
虚言癖などと同じパーソナリティ障害の一種だから生温かく見守ってやれ
虚言癖などと同じパーソナリティ障害の一種だから生温かく見守ってやれ
673デフォルトの名無しさん
2024/04/12(金) 22:18:23.28ID:HgYc1X5O おじいちゃんは昼だけ起きてて
夕方を過ぎると寝てしまう
夕方を過ぎると寝てしまう
674デフォルトの名無しさん
2024/04/12(金) 22:50:23.70ID:3nYhUDoK RUSTがトレンドに!!
675デフォルトの名無しさん
2024/04/12(金) 23:58:18.71ID:lpyrPPhz >>667
つジェネリック
つジェネリック
676デフォルトの名無しさん
2024/04/13(土) 04:39:15.20ID:0YGiYUZr ジェネリックにも同じように安全に適用できるのはRustにトレイト境界があるおかげか
677デフォルトの名無しさん
2024/04/13(土) 07:36:48.57ID:beXAxXwF トレイト境界はc++ conceptみたいに同じ関数集合ならOKなんだっけ?
柔軟性のために外延性は欲しいところ。
柔軟性のために外延性は欲しいところ。
678デフォルトの名無しさん
2024/04/13(土) 08:07:59.96ID:S51MIqUj 異なる型間の共通項をトレイトとして切り出すだけでよく
コードを美しく整理して保守性を高めやすい
コードを美しく整理して保守性を高めやすい
679デフォルトの名無しさん
2024/04/13(土) 13:32:34.24ID:OrtqC7Lq 敬称ないせいで苦労してるんだってな
680デフォルトの名無しさん
2024/04/13(土) 13:36:34.54ID:F3jinTSj 143 デフォルトの名無しさん 2024/04/07(日) 19:27
純関数型言語でなくても
モダンなプログラミング言語
Go、Rust、Zig、Nim、Julia、Elixirなどは
クラスおよびその継承を言語仕様から排除しておりクラスは存在しない
それら各々の言語は全く異なる方針を採っている言語だがクラス排除だけは全てが同じ方針である
クラスとその継承は悪手であるとプログラミング言語界では結論が出ている
純関数型言語でなくても
モダンなプログラミング言語
Go、Rust、Zig、Nim、Julia、Elixirなどは
クラスおよびその継承を言語仕様から排除しておりクラスは存在しない
それら各々の言語は全く異なる方針を採っている言語だがクラス排除だけは全てが同じ方針である
クラスとその継承は悪手であるとプログラミング言語界では結論が出ている
681デフォルトの名無しさん
2024/04/13(土) 16:56:52.49ID:L60jXWVE 継承がなくても構造体にメソッドついてたら実質クラスだろ
関数に構造体渡してたらそれはクラスじゃないけど
関数に構造体渡してたらそれはクラスじゃないけど
682デフォルトの名無しさん
2024/04/14(日) 23:56:10.96ID:RjsA2T1t >>681
構造体にメソッドが付くことはカプセル化と言う
クラス=カプセル化+実装継承 なのでクラスとカプセル化は異なる
このクラスを成り立たせている実装継承が悪であるためにモダンな言語群がクラスを採用しなかった
実装継承とは具体型が別の具体型を継承することを指す
クラスでは派生クラスが基底クラスを継承するため悪の実装継承となる
正しい方法はインタフェイスやトレイトなどの抽象型からのみ継承する
つまりクラスを完全に排除できるためモダンな言語群にクラスはない
構造体にメソッドが付くことはカプセル化と言う
クラス=カプセル化+実装継承 なのでクラスとカプセル化は異なる
このクラスを成り立たせている実装継承が悪であるためにモダンな言語群がクラスを採用しなかった
実装継承とは具体型が別の具体型を継承することを指す
クラスでは派生クラスが基底クラスを継承するため悪の実装継承となる
正しい方法はインタフェイスやトレイトなどの抽象型からのみ継承する
つまりクラスを完全に排除できるためモダンな言語群にクラスはない
683デフォルトの名無しさん
2024/04/15(月) 00:05:55.58ID:R9iMDmBn 用語も色々。
Rust で言うところのトレイトみたいなやつを Haksell とかでは型クラスって呼んでるし、
JavaScript のクラスの実体は (特定のプロトタイプに紐づいたオブジェクトを生成するための) 関数。
極論すればクラスと名付けたものがクラス。
Rust でクラスと呼んでない以上はもう別概念として捉えるしかしょうがないだろ。
C++ のクラス的なことの一部を Rust でも「可能ではある」というという主張なら賛成するけど、
クラスとは何かを定義せずにクラスかどうかを論じても無意味。
Rust で言うところのトレイトみたいなやつを Haksell とかでは型クラスって呼んでるし、
JavaScript のクラスの実体は (特定のプロトタイプに紐づいたオブジェクトを生成するための) 関数。
極論すればクラスと名付けたものがクラス。
Rust でクラスと呼んでない以上はもう別概念として捉えるしかしょうがないだろ。
C++ のクラス的なことの一部を Rust でも「可能ではある」というという主張なら賛成するけど、
クラスとは何かを定義せずにクラスかどうかを論じても無意味。
684デフォルトの名無しさん
2024/04/15(月) 00:26:07.32ID:rd9697wK 型クラスとクラスは全く異なるので混乱しない
クラスとはクラス継承すなわち親クラスから子クラスへの実装継承できるものを指す
JavaScriptはプロトタイプを親として実装継承するためクラス
一方でRustにクラスはない
クラスとはクラス継承すなわち親クラスから子クラスへの実装継承できるものを指す
JavaScriptはプロトタイプを親として実装継承するためクラス
一方でRustにクラスはない
685デフォルトの名無しさん
2024/04/15(月) 01:47:00.44ID:YLFAz6O4686デフォルトの名無しさん
2024/04/15(月) 01:58:25.85ID:CPtYka/u 話は非常に単純
具体的な型から具体的な型への継承が実装継承でこれがよくない
classは具体的な型superclassから具体的な型subclassへの継承があるから実装継承
interfaceやtraitは具体的な型ではなく抽象的な型なので該当しない
最近の言語がclassのみ採用しなかった理由はその違い
具体的な型から具体的な型への継承が実装継承でこれがよくない
classは具体的な型superclassから具体的な型subclassへの継承があるから実装継承
interfaceやtraitは具体的な型ではなく抽象的な型なので該当しない
最近の言語がclassのみ採用しなかった理由はその違い
687デフォルトの名無しさん
2024/04/15(月) 02:39:20.65ID:zOelqs9y RustにはJavaのクラスはありません
RustはJavaではないからです
あたまいいね
RustはJavaではないからです
あたまいいね
688デフォルトの名無しさん
2024/04/15(月) 03:16:04.95ID:0QcDOjSQ Javaの生みの親であるJames Goslingも、
「もう一度最初からJavaを作り直すとしたら、どこを変更したいですか?」に対して、
「クラスを除外するでしょうね」と答えている。
その理由は、クラス継承が実装継承となっているためで、この設計を後悔していて、インターフェースによる継承が望ましいと述べている。
「もう一度最初からJavaを作り直すとしたら、どこを変更したいですか?」に対して、
「クラスを除外するでしょうね」と答えている。
その理由は、クラス継承が実装継承となっているためで、この設計を後悔していて、インターフェースによる継承が望ましいと述べている。
689デフォルトの名無しさん
2024/04/15(月) 08:31:26.40ID:Mqs/ngjj クラスのようなものでいいよ
690デフォルトの名無しさん
2024/04/15(月) 10:16:50.96ID:dcBtWsLv バカの一つ覚えの相手をしても時間の無駄
691デフォルトの名無しさん
2024/04/15(月) 12:54:52.68ID:f4iHJAq/ クラス継承のある言語でも今はクラス継承を使わない設計するのが良いとされてるので要らんよな
692デフォルトの名無しさん
2024/04/15(月) 21:09:43.00ID:97bFGSba それは単に使い分けが出来ない馬鹿な子向けの説明だぞ
693デフォルトの名無しさん
2024/04/16(火) 07:27:41.72ID:10PaZXAR >>691
言語仕様としてあった方が良いということ。
言語仕様としてあった方が良いということ。
694デフォルトの名無しさん
2024/04/16(火) 07:42:24.51ID:KU96szRc 馬鹿が使うとクソになる仕様がある言語は馬鹿をチームに入れただけで開発が即破綻するからクソ
695デフォルトの名無しさん
2024/04/16(火) 08:43:42.78ID:OvO8gS8m Javaの生みの親も言ってるようにクラス継承の機能はない方がいい
なくても困らない
あると問題を引き起こす
なくても困らない
あると問題を引き起こす
696デフォルトの名無しさん
2024/04/16(火) 09:30:25.53ID:YlYBNC7y そういうのは話半分に聞いておけばいいよ
nullを使ったのは失敗だったとか
後からそれらしいことを言ってるだけ
javaはクラスと継承が無くなったらまともに機能しない
interfaceにデフォルト実装がなかったので全部自前かコンポジションで実装することになったはず
nullを使ったのは失敗だったとか
後からそれらしいことを言ってるだけ
javaはクラスと継承が無くなったらまともに機能しない
interfaceにデフォルト実装がなかったので全部自前かコンポジションで実装することになったはず
697デフォルトの名無しさん
2024/04/16(火) 09:50:49.42ID:pgei3+18698デフォルトの名無しさん
2024/04/16(火) 09:55:41.24ID:YlYBNC7y 最初はなかったしずっと取り入れなかったのはそれがJAVA風じゃなかったから
今JAVAが生き残ってるのは最初の設計思想が世間に受け入れられたからであって
後から○○無くせばよかったと言うのは誤りで浅はか
NULLを無くせばよかったと言うが当時メジャーな手法でそれの代替手段がなかったのと同じ
今JAVAが生き残ってるのは最初の設計思想が世間に受け入れられたからであって
後から○○無くせばよかったと言うのは誤りで浅はか
NULLを無くせばよかったと言うが当時メジャーな手法でそれの代替手段がなかったのと同じ
699デフォルトの名無しさん
2024/04/16(火) 10:21:05.77ID:pgei3+18 今となってはclass継承は廃止でいい
700デフォルトの名無しさん
2024/04/16(火) 11:59:36.87ID:NkOUpCFP インターフェイスにも集合で言うところの外延性は欲しいところ。
701デフォルトの名無しさん
2024/04/16(火) 13:49:22.28ID:DzgCvS5T そういうの使いたいならTSがいいよ
702デフォルトの名無しさん
2024/04/16(火) 14:56:34.55ID:vP0l1V0c 具体的なデメリットって何なの?
703デフォルトの名無しさん
2024/04/16(火) 15:29:25.10ID:ePcpSD5e ダサい
704デフォルトの名無しさん
2024/04/16(火) 20:45:11.55ID:scEyspJl そういう感覚的なもの?
705デフォルトの名無しさん
2024/04/16(火) 22:20:54.32ID:pbIQ4i0L 基底クラスで保証してる内部条件を継承クラスで壊されやすい
Javaは基本的に全部オーバーライド可能でprivateとfinalで変な継承を抑えてたけど
C#はabstract/virtualかつsealedでない要素だけオーバーライド可能になってたと思う
古い知識だから最近の動向は知らない
Javaは基本的に全部オーバーライド可能でprivateとfinalで変な継承を抑えてたけど
C#はabstract/virtualかつsealedでない要素だけオーバーライド可能になってたと思う
古い知識だから最近の動向は知らない
706デフォルトの名無しさん
2024/04/17(水) 08:15:23.25ID:eua5YI/M Unreal EngineがRist対応するんだってね
707デフォルトの名無しさん
2024/04/17(水) 16:42:11.69ID:eua5YI/M Ristってなんだ、Rustだた
708デフォルトの名無しさん
2024/04/17(水) 21:06:33.89ID:ZcFRYo3q Rast
Rist
Rest
Rost
Rist
Rest
Rost
709デフォルトの名無しさん
2024/04/17(水) 21:31:42.40ID:O0zLY4aF Risp
710デフォルトの名無しさん
2024/04/18(木) 23:48:18.11ID:mul2o/Jt >>706
時代の流れだな
時代の流れだな
711デフォルトの名無しさん
2024/04/19(金) 17:19:41.25ID:QdSz4ItG 隙間作って床下チェスト収納ってできなくなった?動画みてるけどうまくできん
712デフォルトの名無しさん
2024/04/20(土) 17:39:26.03ID:pCmD4UWo shift-jisのファイルをBufReaderで1行ずつ読み込もうと思ったら無理でOKが流れてこない
全部読んでデコードして\nで切り分けるしかないの?
全部読んでデコードして\nで切り分けるしかないの?
713デフォルトの名無しさん
2024/04/20(土) 17:53:01.46ID:AAPU1iqE read_lineはutf-8じゃないと無理だけどread_untilならバイト列で1行ずつ取れそう
714デフォルトの名無しさん
2024/04/20(土) 22:11:31.95ID:pZNdwQSZ715デフォルトの名無しさん
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()
716デフォルトの名無しさん
2024/04/21(日) 07:15:48.69ID:QKVewSeW BufReaderもFile::openもそのまま使える点がいいね
717デフォルトの名無しさん
2024/04/21(日) 10:23:00.52ID:Be3/0qjS718デフォルトの名無しさん
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() {
// 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() {
719デフォルトの名無しさん
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() {
let bytes = fs::read(path)?;
let (s, _, _) = SHIFT_JIS.decode(&bytes);
let reader = BufReader::new(s.as_bytes());
for line in reader.lines() {
720デフォルトの名無しさん
2024/04/22(月) 20:07:02.52ID:g+YSHIF5 コマンドラインからファイル名取るようにしたらパニック
windowsで文字コードが違うかららしいけどこういうバッドノウハウを開発者に積み重ねていかないと使えないのはめんどい
windowsで文字コードが違うかららしいけどこういうバッドノウハウを開発者に積み重ねていかないと使えないのはめんどい
721デフォルトの名無しさん
2024/04/22(月) 20:46:10.62ID:ZfX6SpnE 何を言ってんのw
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 小野田紀美・経済安保担当相「何か気に入らないことがあればすぐに経済的威圧をする国への依存はリスク」 ★2 [Hitzeschleier★]
- 日本行き空路49万件キャンセル 中国自粛呼びかけ 日本行きチケット予約の約32%に相当 ★2 [ぐれ★]
- 【中国局長】両国関係に「深刻な影響」 首相発言の撤回要求 [蚤の市★]
- 外務省局長は無言で厳しい表情…日中の高官協議終了か 高市首相“台湾”発言で中国が強硬対応 発言撤回求めたか…★3 [BFU★]
- 【インバウンド】中国人観光客の日本での消費額は年間約2兆円超…中国政府は公務員の出張取り消し [1ゲットロボ★]
- 日経平均の下落率3%超す、財政懸念で長期金利上昇 ★2 [お断り★]
- 【実況】博衣こよりのえちえち歌枠🧪
- 【高市朗報】 日本政府「一昨年は1300億円。去年も防衛費が1100億円余ったw」 日本の防衛費は充分足りてる事が判明。増やす必要無し [485983549]
- 【高市速報】日本人の3割「中国への武力行使に踏み切る必要がある」ANN世論調査 [931948549]
- 高市早苗「支持者の理解を得られないので台湾発言を撤回できない」 [931948549]
- 外務省局長、よくわからないまま帰国へ [834922174]
- 中国外務省「日中関係の悪化は高市早苗首相が原因」と名指しで強く非難。キタ━(゚∀゚)━! [153490809]
