結局C++とRustってどっちが良いの? 8traitsat TECH
結局C++とRustってどっちが良いの? 8traits - 暇つぶし2ch2:デフォルトの名無しさん
23/10/28 13:45:36.64 fh9BWjjr.net
あるあるトピックス
・後発のRustは優れている(この点で特に争いはない
・といっても、C/C++から「推し変」するほどじゃない(使わないとは言ってない
・ていうか、Cとの比較と、C++との比較は違うくね?
・いくら安全っつっても、ヘタクソがunsafeだらけに書いちゃったらおんなし
・てかC++にも unsafe{ } はよ

・web方面、特に基盤部分での人気すごいね
・ChatGPTとかが賢くなる(のに賭けてる)からどうでもいい

3:デフォルトの名無しさん
23/10/28 13:50:00.20 1iiYkiVL.net
スレ立て乙
unsafe {

4:デフォルトの名無しさん
23/10/28 14:37:18.81 o0Izqpe5.net
次スレいらんわボケ

5:デフォルトの名無しさん
23/10/28 16:34:04.19 enMMtIYH.net
ネットインフラが次々とRust製になっていってる

>【CDN世界トップシェアCloudflare】
URLリンク(www.publickey1.jp)
>CDNプロバイダのCloudflareは、同社のグローバルなCDNの基盤として長らく利用してきたNGINXに代えて、
>同社自身がRust製のHTTPプロキシである「Pingora」を開発し利 用していることを明らかにしました。

>【クラウド世界トップシェアAWS】
URLリンク(japan.zdnet.com)
>Rustで構築されたAWSサービスの例としては、
>コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、
>「Amazon Simple Storage Service(S3)」、
>「Amazon Elastic Compute Cloud(EC2)」、
>コンテンツ配信ネットワーク「Amazon CloudFront」、
>LinuxベースのコンテナーOS「Bottlerocket」などがある。

6:デフォルトの名無しさん
23/10/29 07:04:58.86 /j90tPs+.net
プログラミング言語「Rust」は世界のセキュリティレベルを底上げする
URLリンク(wired.jp)
Androidでは今、暗号鍵を管理する機能の多くがRustで書かれているとGoogleのクライダーマーカーは話す。
たとえば、暗号化したインターネット通信の機能である「DNS over HTTPS」、新バージョンの超広帯域無線(UWB)チップスタック、
そしてグーグルの独自のチップである「Tensor G2」で使用される新しい「Android 仮想化フレームワーク(AVF)」 などだ。
また、BluetoothやWi-Fiなどの通信接続に使われるスタックも、Androidの開発チームによってRustへの変換が積極的に進められている。
理由は、これらが業界の複雑な標準規格に基づいており、脆弱性を多く含む傾向にあるからだとGoogleのクライダーマーカーは付け加える。
つまり最も狙われやすい、あるいは最も重要なソフトウェアの部分からRustに書き換えて、
そこから徐々に広げることで段階的にセキュリティ上の恩恵を受けようという戦略なのだ。

7:デフォルトの名無しさん
23/10/29 09:34:40.05 7Lr6oJeR.net
>>1
・・・で、結局どっちが良いの?

8:デフォルトの名無しさん
23/10/29 11:34:03.80 GrwAVmld.net
>>2
C++はデフォルトがunsafeだから、入れるならsafe{}じゃないのけ?

9:デフォルトの名無しさん
23/10/29 11:55:56.89 jrKbdvhX.net
デフォルトをsafeにするって話やろw
そうすると現行のライブラリはビルドできないので取り敢えず全部unsafeで囲う
バージョンを重ねてunsafeの部分を減らすって戦略でしょ?

10:デフォルトの名無しさん
23/10/29 12:10:31.41 rFgSsne0.net
>>8
それ意味ないのわかんない?

11:デフォルトの名無しさん
23/10/29 12:58:33.36 gLyKM6Q0.net
null safetyですら無理なんだからunsafeなんて夢のまた夢

12:デフォルトの名無しさん
23/10/29 13:01:53.93 IsQ6p7Vf.net
positive list と nagative list の違いやろ
どっちも一長一短があるってだけで
どっちが一方的に優れているということではない

13:デフォルトの名無しさん
23/10/29 13:06:42.15 x+5RB5aB.net
前者が明らかに劣ってるのは自衛隊見れば明らかじゃん

14:デフォルトの名無しさん
23/10/29 14:22:40.43 IsQ6p7Vf.net
青山繁晴ファンですね判ります

15:デフォルトの名無しさん
23/10/29 14:24:26.17 IsQ6p7Vf.net
ちなみに Rust の unsafe {} は positive list に相当すると思う

16:デフォルトの名無しさん
23/10/29 16:22:18.96 UpWU1GX+.net
時代は静的検出なので、冒頭に
#pragma safe
とかでも書くとかになるんじゃないかな
そのうしろに、縛りの識別子が入るのでもいい

17:デフォルトの名無しさん
23/10/29 16:22:22.63 B2pW3CpU.net
unsafe {}ってなに?
ポインタ扱えなくするやつ?

18:デフォルトの名無しさん
23/10/29 18:07:40.10 UpWU1GX+.net
} // あとでみなおす
とりあえず生ポはなしかな
ポインタはきちんと定義される

19:デフォルトの名無しさん
23/10/30 01:11:12.37 SHIqNVOV.net
>>9
あー、そういうことね。

20:デフォルトの名無しさん
23/10/30 14:08:13.49 yf48i6Jz.net
前スレ
>>997
HashMapはとVecは異なる型なので直接代入できない
一般的に入力イテレータinput_iterからHashMapを作るには
HashMap::from_iter(input_iter)とすればよい
これは代入先の型がHashMapの時のinput_iter.collect()と同じ
collect()の正体はfrom_iter()を呼ぶだけ

ちなみにfrom_iter()はFromIteratorトレイトのメソッド
引数としてIteratorだけでなくIntoIteratorも取れるため
今回の入力ベクタinput_vecに対してinto_iter()せずとも
そのままHashMap::from_iter(input_vec)と書ける
一方でcollect()を使う場合これはIteratorのメソッドなので
明示的に変換してinput_vec.into_iter().collect()となる

21:デフォルトの名無しさん
23/10/31 05:55:29.82 DJT4usEp.net
ゲーム業界はC++かC#
Rustが入る余地なし

22:デフォルトの名無しさん
23/10/31 08:54:10.63 5Lja4y81.net
Rust がリファクタリングと相性が悪いんじゃないか
と思うことが時々というより割と頻繁にある

23:デフォルトの名無しさん
23/10/31 10:17:54.25 Fz0aDVxr.net
設計が悪いおじさん「設計が悪い」
…とはいうものの、書き味ってもんがあるよね言語って

24:デフォルトの名無しさん
23/10/31 20:53:25.14 1IgY5W3A.net
難しそうという直感でリファクタリングを中止できるのは損なのか得なのか

25:デフォルトの名無しさん
23/10/31 22:01:39.08 PwivvYFW.net
Rustはリファクタリングや更新メンテとの相性いいと思う
C/C++で他人もしくは過去の自分が書いたコードの肝の部分をうっかり踏み抜いてメモリデバッグコースとなるところを
Rustは未然に防いでくれてる

26:デフォルトの名無しさん
23/10/31 22:13:21.13 3AsVVcfX.net
リファクタリングでエンバグしにくいけど、そもそもリファクタリング自体しにくいよね

27:デフォルトの名無しさん
23/10/31 22:25:05.59 NeIS8/9C.net
URLリンク(www.open-std.org)
C++はfeature gate方式でアノテーションした箇所のみ
static analyzerでチェックする方針で一応進み始めてるのね
なんというか過去の資産を生かすというのは大変なんだな
Rustと同レベルのsafetyが提供できるようになるかどうかまだわからないけどまあ頑張ってという感想

28:デフォルトの名無しさん
23/11/01 03:51:28.75 5z6NYMjm.net
悪い(かも知れない)設計を
良い(かも知れない)設計に
するのがリファクタリングのモチベだと思うので
元の設計が悪い(かも知れない)のは仕方ないが
良い(かも知れない)設計に変更するのを阻む力をRustはもってる
もちろんリファクタリングでエンバグしない利点は認めている

29:デフォルトの名無しさん
23/11/01 03:53:16.74 5z6NYMjm.net
更新メンテでエンバグしないと言っても
汚いコードが汚いまま増設されていく不安しかない

30:デフォルトの名無しさん
23/11/01 05:10:40.48 fNUPqUoJ.net
リファクタリングなんてもんは無能な働き者がすることよ

31:デフォルトの名無しさん
23/11/01 08:38:55.26 TrWFH7YA.net
以上、無能な働き者の感想でした

32:デフォルトの名無しさん
23/11/01 08:49:48.50 VeDR0B8A.net
耳が痛いわ~w (横から
>>27
走り読み…と思ったら、かっちりしたまとめだった
型に含めることばっかり(自分なりに)考えてたが、属性かー。
ああそういや、VCの属性プロバイダ、API公開まだだったよな

33:デフォルトの名無しさん
23/11/01 09:15:51.82 QJoNTbA8.net
borrow! またお前かっ!!
ですね
判ります
あとは C# みたいな PartialTrait があれば良いのに

34:デフォルトの名無しさん
23/11/01 09:29:13.02 g0uNXVFl.net
>>28
他の言語との比較も含めて具体的な例を上げてくれないと
何が困ってるのかよくわからん

35:デフォルトの名無しさん
23/11/01 11:28:14.65 r0MV67Oa.net
>ゼークトの組織論において、もっとも害のある存在とされるのが、無能な働き者(愚鈍:勤勉)タイプの人材です。正しい判断力や行動力が備わっていないにもかかわらず、自身の判断で行動してしまう特徴を持っています。いわゆる「余計なことをしてくれる」タイプの人材です。 無能な働き者が動くことで間違った判断により損害が出たり、周囲が後始末に追われたりといった混乱を招きます。しかも、本人は「よかれと思って動いている」点が、大きな問題となるのです。

36:デフォルトの名無しさん
23/11/01 11:36:32.25 r0MV67Oa.net
無能な働き者は放置しておくことで、組織にとって大きな損害をもたらすリスクとなります。
努力や判断のベクトルが間違っているだけで、意欲的な人材であるかもしれません。適切に関わり軌道修正を図れば、組織に貢献してくれる人材になってくれるかもしれません。この困ったちゃんを相手にする余力が会社や関係者にあればよいのですが、そうでない場合は自己都合退職へ誘導し、早めに組織から追い出しましょう。

37:デフォルトの名無しさん
23/11/01 12:40:12.80 8C4ZzEMt.net
軍人を4つのタイプに分類する「ゼークトの組織論」と呼ばれる軍事ジョークがあり[注釈 2]、ゼークトが以下のように語ったとされる。
---------8<----------8=------
これは実際には同時期のドイツ軍人であったクルト・フォン・ハンマーシュタイン=エクヴォルトが副官に述べたとされるもの[31]が元になっている。

38:デフォルトの名無しさん
23/11/01 19:08:00.09 gqkX1mpA.net
いつの間に、こんなに積極的に、異物は排除しましょうなんて世の中に深化したのかねえ
世知辛い

39:デフォルトの名無しさん
23/11/01 19:59:16.09 r0MV67Oa.net
>>38
>いつの間に
いつと問われれば人が集落として生活するようになるぐらい古代から…なんじゃね
村八分とか神隠しとかぐらいは聞いたことあると思うけど
司法がない時代は私刑が日常的に行われていたんだよ
今は法律もあるしネットで大騒ぎすれば助けてくれる奴も出てくるだろうけど
属していた会社なり組織からは切り離される形に落ち着くだろうね

40:デフォルトの名無しさん
23/11/01 20:11:22.67 mATsi7Ug.net
Rustはリファクタリングでのエンバグ防止も強力で開発効率良いな

41:デフォルトの名無しさん
23/11/01 22:31:20.11 H181/maX.net
>>38
嫌なら見るな
嫌なら出ていけ

42:デフォルトの名無しさん
23/11/01 23:11:21.03 FbXsZBSZ.net
競技プログラミングでは何でみんなc++なのですか

43:デフォルトの名無しさん
23/11/02 02:07:29.05 uLntp6kp.net
>>42
Rust使ったことないだろ

44:デフォルトの名無しさん
23/11/02 09:27:36.71 kxWwWLf8.net
>>36
東近江市市長ですね判ります

45:デフォルトの名無しさん
23/11/02 09:30:06.68 kxWwWLf8.net
>>39
私刑の大半は「自分が気に入らない相手を消す」だろ

46:デフォルトの名無しさん
23/11/02 10:28:31.37 e3rN7I7Z.net
ゼロサムゲームなんだよねえ あいつがいると、こっちの幸せの取り分が減る

47:デフォルトの名無しさん
23/11/02 11:00:23.03 NLwKfBpd.net
C++のchrono
Sun=0, Mon=1, ..., Sat=6
Rustのchrono
Mon=0, Tue=1, ..., Sun=0
なんかの嫌がらせか?これ

48:デフォルトの名無しさん
23/11/02 11:01:31.85 NLwKfBpd.net
訂正
C++のchrono
Sun=0, Mon=1, ..., Sat=6
Rustのchrono
Mon=0, Tue=1, ..., Sun=6
なんかの嫌がらせか?これ

49:デフォルトの名無しさん
23/11/02 11:38:23.20 SgY2tw2G.net
>>48
enumで処理するもんじゃないの?

50:デフォルトの名無しさん
23/11/02 12:27:57.80 e3rN7I7Z.net
いっしょは嫌だったんじゃない? (はなほじ

51:デフォルトの名無しさん
23/11/02 13:14:01.78 sR7LRQS1.net
>>49
0と7が日曜だと便利なんだよ
なんで変えちゃったのかね

52:デフォルトの名無しさん
23/11/02 14:01:21.75 26D/b4Fo.net
おまえら全員エアプログラマーだな
Rustのchronoは両対応で困ることはない
num_days_from_sunday()だと日曜日から0発進
num_days_from_monday()だと月曜日から0発進

53:デフォルトの名無しさん
23/11/02 14:21:03.74 R1/lC5p9.net
ISO8601では月曜は1で日曜は7なんだよな。

54:デフォルトの名無しさん
23/11/02 14:43:04.82 26D/b4Fo.net
>>53
Rustのchronoが日曜スタートと月曜スタートの両対応にしている理由がそれ
C++のchronoでISOに変換するには日曜日だけif文するか再び%7する必要がある

55:デフォルトの名無しさん
23/11/02 15:51:19.67 C/SY5g2v.net
たぶん何も考えてない+誰も使わないから放置されているだけだね
Mon=0固定の前提でTryFrom<u8>なんか実装してるし

56:デフォルトの名無しさん
23/11/02 16:27:45.50 26D/b4Fo.net
そこは言語によって異なるんだよ
Pythonは月曜スタート
weekday() 月曜日=0 ~ 日曜日=6
isoweekday() 月曜日=1 ~ 日曜日=7
Javaも月曜スタート
DayOfWeek 月曜日=1 ~ 日曜日=7
だから両対応しているRustが最も良い状況

57:デフォルトの名無しさん
23/11/02 20:37:31.47 YFXMye4z.net
曜日の内部表現とかどうでもいいだろ…

58:デフォルトの名無しさん
23/11/02 21:59:20.29 SgY2tw2G.net
HTTPでJSONやりとりしてるとき思い込みで
バグになるというのはあるかも

59:デフォルトの名無しさん
23/11/02 23:52:30.67 M3hXBmrb.net
今回のchronoでイチャモン始めたやつも
日曜日開始のC++しか知らなくてそれが正しいと思い込みをしてたからな
月曜日開始のISO8601とそれに従うプログラミング言語を一つでも知っていればそんな勘違いは起きなかった

60:デフォルトの名無しさん
23/11/03 00:21:59.00 g+drsbNI.net
と、C言語のtm構造体から続くC/C++/UNIX系全般の伝統を知らなかった人が申しております

61:デフォルトの名無しさん
23/11/03 00:34:37.66 OMWtAqQI.net
恥ずかしいのぉ
ああ恥ずかしい

62:デフォルトの名無しさん
23/11/03 00:58:32.47 /+LsOzGq.net
>>60
それも常識だな
そしてISOおよびそれに準じるJavaやPythonも常識
両派あることを知っていれば両対応のRustを批判しだすような愚かな言動はしない

63:デフォルトの名無しさん
23/11/03 03:57:01.11 QmAmywB5.net
>>62
コウモリ野郎が一番嫌われるんだよ
おまえは獣なのか鳥なのか

64:デフォルトの名無しさん
23/11/03 06:56:19.57 N2L5n51t.net
伝統的には日曜始まり、商用的には月曜始まり、ということだろ。
そもそも現代主流のグレゴリオ暦自体が欠陥だらけ (素数の7を週単位にしている、月の日数がバラバラ) だから、効率を気にしてもしょうがない。
完全数の6と3素数積の30を基準にすれば全然違ったのにな。

65:デフォルトの名無しさん
23/11/03 08:41:35.38 znXtgxSS.net
>>59
おまい望月衣望子そっくりな人間だな

66:デフォルトの名無しさん
23/11/03 08:41:37.96 hQugpIJj.net
>>64
だからその日曜始まり日曜終わり両方に対応できる日曜0,7が有能だった話よ

67:デフォルトの名無しさん
23/11/03 10:30:38.41 FAT4ZC6j.net
C++もc_encodingとiso_encodingで両方対応はしてる
簡単に変換できるから正直どうでもいいけど
URLリンク(en.cppreference.com)
このドキュメントはReturn valueの2) の内容が間違ってる
レビュープロセスが心配になるな

68:デフォルトの名無しさん
23/11/03 11:42:31.25 7w5cnhLp.net
>>58
シリアライズ時と異なるエンコーディングで復元しようとしたらそりゃバグるわな
でもそんなやつらのために内部表現を統一しろと言われても誰も相手にしないでしょ

69:デフォルトの名無しさん
23/11/03 12:30:23.11 xNBDqk0z.net
>>56
JavaはWeekFields経由で日曜始まりにもできる
Pythonは日曜始まりのインデックスを直接取得することはできないがcalenderモジュールで日曜始まりのカレンダーを扱える
どちらもRustほど低レイヤーやC++を意識する必要がないからRust比べて少し高いレイヤーで日曜始まりにも対応している
Rustの開発者にとって最もいい状況が他の言語の開発者にとっても最もいい状況とは限らない

70:デフォルトの名無しさん
23/11/03 13:42:53.76 IVkiUA9g.net
=== 複製おじさん(通称複おじ)について ===
Rustスレを中心に活動し、2023年4月現在で1年以上ム板に住み着くRustacean。無自覚な荒らし。

Rustスレでは、基本的に他住民の意見を聞いて糧とすることなく、自らのコードが最善であると、ID変更自演を交えいつまでも主張し続ける。
同スレで「所有権が複製される」という違和感のある表現を、「違和感がある」とする他住民の意見をすべて否定してしつこく擁護し続けたことから、「複製おじさん」というあだ名が付けられた。
それ以外のム板スレでは、基本的に他住民の意見を聞いて糧とすることなく、Rustこそが最善であると、ID変更自演を交えいつまでも主張し続ける。
その基本戦術は、「GC言語は遅い」の一声でC/C++/Rust以外の言語を否定し、残ったC/C++は安全ではないので、Rustが最善であるとするもの。

しかしながら、Rust以外の言語に関しては、正当な批判を展開するのに十分な知識を持っているとは言いがたい。
本スレPart1では、C++の問題点を指摘しようとして多数の誤り・知識不足を露呈することとなった。特にしつこく食い下がったのが「動的ディスパッチ」に関する誤解である。
スレリンク(tech板:786番)-799(ID:Evbafc70とID:RiLc+pIfが複製おじさんであると考えられている)
要約すると、通常「条件分岐」と呼ばれるものを「動的ディスパッチ」と呼ぶのが正しいと主張し続けたのである。
常識的にはあり得ない誤解だが、提示されたC++のコードが自らの主張(C++にはパターンマッチが無い)に不都合であると感じたためか、C++のコードを正しく読み解くことができないにもかかわらず脊髄反射的に否定してしまい、その根拠として誤った論理をこじつけてしまったものと思われる。

ちなみにこの後、同種の誤解を持って書き込むID:wHEiYRW7(これはID使用歴的に複製おじさんとは考えにくい)に対して、正しい理解に基づく指摘を行う単発IDが複数出現するが、この中にも複製おじさんが多数含まれていると考えられている。
このように自分の誤りを認識した場合、それを認める書き込みは決して行わず、別人の振りをして最初から正しく理解していた体を装うのも複製おじさんの特徴である。

71:デフォルトの名無しさん
23/11/03 13:43:15.14 IVkiUA9g.net
テンプレ忘れてるぞ

72:デフォルトの名無しさん
23/11/03 15:43:05.53 +wuvOqHg.net
ゲームプログラミングに向かない時点でRustに勝ち目は無い

73:デフォルトの名無しさん
23/11/03 16:17:15.97 TISIAi2y.net
ゲームとかどうでもいい

74:デフォルトの名無しさん
23/11/03 16:35:04.29 hQugpIJj.net
プログラミング言語は とにかくユーザ数が増えて裾野が広がらないとだめよ
とはいっても、Rustはその性格上 エンジン系にはとても強いと思う

75:デフォルトの名無しさん
23/11/03 20:01:25.17 oS0jLPzO.net
なんでゲームに向いてないの?

76:デフォルトの名無しさん
23/11/03 20:18:57.74 L6NiYGzz.net
ビルド時間が長いとか主要なゲームエンジンが対応してないとかかな?

77:デフォルトの名無しさん
23/11/03 20:23:49.80 m1BMAQzf.net
>>74
ゲームエンジンこそどうでもいい
どうせ他人の成果物使うだけやし
つまりRustはゲームプログラミングに向いてない

78:デフォルトの名無しさん
23/11/03 20:27:09.44 DDLGlAPd.net
>>75
オブジェクト指向じゃないから大規模開発に向いてない

79:デフォルトの名無しさん
23/11/03 20:27:51.26 DDLGlAPd.net
ゲームはプログラムの積み上げ方式
Rustなんか使い物にならん

80:デフォルトの名無しさん
23/11/03 20:48:01.15 L6NiYGzz.net
え?rustってオブジェクト指向じゃないの?

81:デフォルトの名無しさん
23/11/03 20:54:38.72 hQugpIJj.net
>>77
エンジンを作る側の話やで

82:デフォルトの名無しさん
23/11/03 21:23:41.57 YDoJin8V.net
>>78
むしろRustは大規模開発にも適するように設計された言語
今どきの普通にマルチパラダイムで当然オブジェクト指向もサポート

83:デフォルトの名無しさん
23/11/03 22:56:37.98 oS0jLPzO.net
これすごいわ
URLリンク(www.youtube.com)
Rust もびっくり

84:デフォルトの名無しさん
23/11/03 22:58:02.02 oS0jLPzO.net
>>75
>>79
グローバル変数が超絶面倒臭いからじゃね

85:デフォルトの名無しさん
23/11/03 23:50:14.81 DpBIrO9u.net
オブジェクト指向を理解してない無能が多すぎる

86:デフォルトの名無しさん
23/11/03 23:54:28.74 caMFRrqc.net
オブジェクト指向なんてもはや有害じゃねという
話も出てるようだけど

87:デフォルトの名無しさん
23/11/04 00:10:04.03 vTgEadDD.net
既存のオブジェクト指向言語の置き換えを狙ってるなら
既存のオブジェクト指向言語の機能は備えんとなぁ
設計からやり直す必要が生じてまんどくさってなる
スクラッチから新たに書くのなら支障ないだろうけども
それではいつまで経ってもマイナー言語だよ
この先生きのこれん

88:デフォルトの名無しさん
23/11/04 00:22:53.36 p6vbmy4R.net
みんな反発しても結局オブジェクト指向に帰ってくる
みんなC++に帰ってくる

89:デフォルトの名無しさん
23/11/04 00:23:19.27 EeyeeoXm.net
最近のプログラミング言語は基本的にオブジェクト指向だがクラス継承だけは亡くなったらしい
最近のプログラミング言語
【クラス継承がない】Elixir、Go、Julia、Nim、Rust、Zig
【クラス継承がある】Kotlin(=Javaの後継)、Swift(=Objective-Cの後継)
つまり過去のしがらみでクラス継承を含めざるを得なかったKotlinとSwiftを除いて
全ての言語でクラス継承は亡くなった

90:デフォルトの名無しさん
23/11/04 00:27:29.67 vTgEadDD.net
おかげでみんなマイナー言語のままじゃんw

91:デフォルトの名無しさん
23/11/04 00:28:23.25 vTgEadDD.net
人間は保守的なんだから
互換性を軽視したらユーザは絶対にぶんどれん

92:デフォルトの名無しさん
23/11/04 02:16:54.87 eaDg3ztu.net
>>89
GUI開発用言語とそうでない言語にきれいに分かれてんね

93:デフォルトの名無しさん
23/11/04 03:14:34.51 6Rm06W4Y.net
GUIはクラス継承要らないだろ
有害なクラス継承しかないとクラス継承を使って巨大なピラミッドを作ってしまい
その反省も各新言語が揃って意図的にクラス継承を廃止した要因

94:デフォルトの名無しさん
23/11/04 03:24:41.20 W1fOq5zR.net
継承無くした結果、馬鹿なことをやらされる
URLリンク(qiita.com)

95:デフォルトの名無しさん
23/11/04 05:01:54.27 qNKpZaTJ.net
それはクラスの継承というよくない古い考え方しかできない人向けの方法だな
様々に方向性も異なる方針の新プログラミング諸言語がクラスの継承だけは導入しない同じ結論に至った重みは大きい

96:デフォルトの名無しさん
23/11/04 05:58:52.07 QaQpRr0T.net
IUnk教わい、なくなるといわれるとちょっとさみしい (なくなるとは言われてない

97:デフォルトの名無しさん
23/11/04 06:13:35.65 9ClykILV.net
継承がない言語には大抵はmix-inという優れた代替が用意されてる
継承もmix-inもないRustは無能

98:デフォルトの名無しさん
23/11/04 07:37:08.58 tOjhAD6C.net
そうゆうのがない、切り捨ててるから、Linuxカーネルに来てよろしいって言われたのかもね しらんけど
やっぱり必要となりゃ、そのうち解禁(追加)になるでしょ

99:デフォルトの名無しさん
23/11/04 07:50:02.45 W1fOq5zR.net
>>95
極端だな
そんな考えじゃC++から移行なんて益々困難だし
こんなスレ立てて対立煽りするレベルにも達してないじゃないか
>この記事ではC++やJavaで継承を使っていた人がRustで同様の実装をしたいときにどうすればよいのかを説明します。
この課題については君はどうしたらいいと思ってる?

100:デフォルトの名無しさん
23/11/04 08:26:29.68 tOjhAD6C.net
第1スレはわからんけど、このスレの>>1は俺

101:デフォルトの名無しさん
23/11/04 09:10:11.30 LI9X3aVk.net
>>89
Javaの開発者も継承だけは間違いだったと言ってるみたいだね

102:デフォルトの名無しさん
23/11/04 09:32:38.86 0JVEbPjc.net
64 デフォルトの名無しさん 2023/09/26(火) 09:36
以前Javaのユーザグループミーティングに出席した際、James Gosling(Javaの生みの親)がメインの講演者として招かれていました。
すばらしいQ&Aセッションの途中に、こんな質問が出ました。
「もう一度最初からJavaを作り直すとしたら、どこを変更したいですか?」
答えは「クラスを除外するでしょうね」というものでした。
笑いが静まった後、彼が説明したのは、本当の問題はクラス自体ではなく実装継承(extendsの関係)なのだということでした。
インターフェースによる継承(implementsの関係)のほうが望ましいのです。できる限り実装継承は避けたほうがよいでしょう。

103:デフォルトの名無しさん
23/11/04 09:32:49.65 6irn+b/+.net
やっぱりコミットするならシープラだなとおもいました

104:デフォルトの名無しさん
23/11/04 09:56:14.27 /2/myesZ.net
その論法に乗っかってやると過去の
言語のパラダイム変化はどうやって起きたのか
謎になるな

105:デフォルトの名無しさん
23/11/04 09:59:34.34 eaDg3ztu.net
>>93
>GUIはクラス継承要らないだろ
要るか要らないかという話はしてないよ
1) Elixir、Go、Julia、Nim、Rust、Zig
2) Kotlin、Swift
1)の言語でGUI作れなくはないけど実際に作る開発者がかなり少ない
逆に2)の言語は大半の開発者がGUIを作ってる
それには理由があるということ
もっと言えばクラス継承的な機能の有無はトレードオフだからそれを理解しましょうねという話

106:デフォルトの名無しさん
23/11/04 10:34:34.64 2TRtrAOp.net
多くの高機能webサイトはGUIアプリと言って良いと思うが
ts jsのクラス機能はあるけど使わないな

107:デフォルトの名無しさん
23/11/04 10:49:05.41 XpaBBm0T.net
やっぱりRustが最強だなっておもいました

108:デフォルトの名無しさん
23/11/04 11:16:32.88 qG8ydW8y.net
最強はRust世代

俺のおかんはC++

109:デフォルトの名無しさん
23/11/04 12:01:10.23 vTgEadDD.net
>>89
思惑の違いが見事に結果に表れている分類だね
興味深い

110:デフォルトの名無しさん
23/11/04 12:09:00.72 vTgEadDD.net
>>104
その「言語のパラダイム変化」って具体的にはどれを指している?
Rustがユーザを獲得する際の参考になるかもしれんね

111:デフォルトの名無しさん
23/11/04 12:27:39.60 KPpuxUox.net
オブジェクト(classじゃなくてstructで良い)があって
正しい型指定で正しく関数が呼ばれてれば
クラス継承なんて要らないんだよな
別に禁止というほど厳しくやらなくても自然とそうなる

112:デフォルトの名無しさん
23/11/04 12:29:16.51 KPpuxUox.net
C++ の template なんてあれオブジェクト指向じゃねーし

113:デフォルトの名無しさん
23/11/04 12:35:18.44 eFHrirh7.net
>>105
KotlinとSwiftは最初からGUIアプリをターゲットにしてるしそれ以外の分野では全然使われてないような

114:デフォルトの名無しさん
23/11/04 16:44:29.40 qG8ydW8y.net
いまさら人に聞けない
悪い継承ってのがわからなくなった
継承おぼえたてて(一人プロジェクトが)めちゃくちゃになった経験ならあるけど、そうじゃなくてこう

115:デフォルトの名無しさん
23/11/04 17:10:03.05 S8hti0fw.net
クラス継承は必要
オブジェクト指向を理解できないのはただのザコ

116:デフォルトの名無しさん
23/11/04 18:03:19.84 rn/KP434.net
>>115
最近のプログラミング言語たちが揃いも揃ってクラス継承を不要と判断しちゃいましたぁ
【クラス継承がない言語】Elixir、Go、Julia、Nim、Rust、Zig

117:デフォルトの名無しさん
23/11/04 18:26:15.51 EmvA1J0P.net
言語開発者が設計した基底クラス以外の継承はいらないんじゃないかなぁ

118:デフォルトの名無しさん
23/11/04 18:26:28.96 p6vbmy4R.net
rust以外上がり目なさそうな言語たちで草

119:デフォルトの名無しさん
23/11/04 18:42:09.44 vTgEadDD.net
Rustも同じく普及戦略を誤った言語だよ

120:デフォルトの名無しさん
23/11/04 19:41:01.77 hPdVOFaj.net
Pythonスーパーセットのmojoにこのまま成長してほしいけどシープラRustの競合にはならないか

121:デフォルトの名無しさん
23/11/04 19:51:27.75 Is+FXxYG.net
mojoはAI関連の高速化を狙ったものだろうから限定的な利用になりそう

122:デフォルトの名無しさん
23/11/04 21:29:47.46 9ClykILV.net
結局ユーザーが欲しかったのは「ポインタのないC++」であって所有権やtraitみたいな使いづらい独自機能じゃなかったんだよなあ

123:デフォルトの名無しさん
23/11/04 22:19:37.19 +CP/CRpL.net
>>122
所有権はC++にもある
traitはC++の抽象クラスからデータ(メンバー)を分離独立させ�


124:トより良い設計ができるようになっている 使いづらくなっていない



125:デフォルトの名無しさん
23/11/05 10:25:09.84 ol9bMVcc.net
>>117
doubleがfloatを継承していないのはなぜ?
f64がf32を継承していないのはなぜ?

126:デフォルトの名無しさん
23/11/05 11:09:33.12 JT3Ktc4T.net
それって継承するようなもんかね

127:デフォルトの名無しさん
23/11/05 11:48:56.89 8w5QKIdz.net
精度の違いであって継承関係無いな。
むしろ継承したらダメなやつ。
共通のインターフェースを用意するのが普通。

128:デフォルトの名無しさん
23/11/05 12:19:51.94 pw4Q0c9f.net
パフォーマンスを度外視するなら
浮動小数点数型をfloatとdoubleの両方とも継承するのが自然かなぁ

129:デフォルトの名無しさん
23/11/05 17:32:34.60 vp0BWznn.net
>>127
その浮動小数点型ってどんなもの?
インターフェースじゃないんだよね?

130:デフォルトの名無しさん
23/11/05 19:27:50.24 aeGT2yJ/.net
>>116
自分に都合の良い言語のみ列挙する
まさにザコ
自分の考えが無い

131:デフォルトの名無しさん
23/11/05 19:50:12.60 o9vKIGF+.net
>>129
同じくらいたくさん反例を挙げようよ

132:デフォルトの名無しさん
23/11/06 04:14:47.70 m6bVjB7O.net
>>130
そんなことよりこのクソスレ立てたのもお前?
スレリンク(tech板)

133:デフォルトの名無しさん
23/11/06 08:09:26.10 Cot/SbpY.net
募集してんのか、大胆だな!

134:デフォルトの名無しさん
23/11/06 10:12:15.79 48qtdwXc.net
Rustとの相性で言えば
Rust+Pythonはかなり良い
Rust+Cが最強
Rust+C++は最悪

Nimとの相性で言えば
Nim+Pythonはとても良い
Nim+Cが最強
Nim+C++も最強

Nimの勝ち

135:デフォルトの名無しさん
23/11/06 10:16:59.00 UjpY0LiG.net
>>129
自分はなにも例を挙げられないの?
それでよく人を批判する気になれたね

136:デフォルトの名無しさん
23/11/06 14:46:38.23 DT4BUOTR.net
テンプレートパターンやるにしても今は継承よりもクロージャで渡す方がわかりやすいって話やね。
まあどっちにしろ低レイヤー言語だとオブジェクトの解放タイミングとか気にしてめんどくさくはなるが。

137:デフォルトの名無しさん
23/11/06 14:50:37.11 mJLQiI1M.net
Nimちゃんに行くわ
RUSTとかクソゲーみたい

138:デフォルトの名無しさん
23/11/06 15:23:25.15 X0T3Y72w.net
C++/Rustと比べて何もかも劣るNimは選択肢に上がることがない

139:デフォルトの名無しさん
23/11/06 18:05:43.27 BlmWAswu.net
>>134
そもそも流行りの話自体何の根拠にもなってないんでこの話自体無意味
無意味な話は時間の無駄

140:デフォルトの名無しさん
23/11/06 18:18:33.08 mZ9CqDyY.net
C++は仕様などがugly
Rustはbeauty

141:デフォルトの名無しさん
23/11/06 18:45:27.89 Yw0


142:Fs1sT.net



143:デフォルトの名無しさん
23/11/06 19:58:38.94 2NClhQZD.net
>>137
文法はNimの圧勝。

144:デフォルトの名無しさん
23/11/06 21:52:22.89 xwaCKIbt.net
Nimの唯一のメリットがPythonに似た文法と言われているが
このスレの住人はそれをメリットと感じない

145:デフォルトの名無しさん
23/11/06 22:00:03.84 juqSJt+O.net
何でお前が住人を代表してるの?w

146:デフォルトの名無しさん
23/11/06 22:14:50.32 BFZIHaDs.net
複オジ代表チーっすw

147:デフォルトの名無しさん
23/11/06 23:09:22.63 m6bVjB7O.net
まあ複おじ隔離スレなんだから代表は複おじでいいんじゃない?

148:デフォルトの名無しさん
23/11/06 23:55:02.14 X0T3Y72w.net
>>141
インデントではなく波括弧でブロックを表すのが好まれている多数派

149:デフォルトの名無しさん
23/11/07 07:52:40.08 Z7KocuHY.net
>>146
c世代はそうだけど、pythonユーザーの方が多い現在はインデントブロックの方が主流。じゃなきゃYAMLとか流行らん。
LISPも丸括弧使ってるけどインデントブロック風の整形しているし、波括弧ブロックが多数派とは思えん。

150:デフォルトの名無しさん
23/11/07 09:16:54.55 YntbMeAj.net
詭弁 - Wikipedia
URLリンク(ja.wikipedia.org)

151:デフォルトの名無しさん
23/11/07 09:19:09.61 YNljO5VY.net
>>147
どさくさに紛れてYAMLを流行り扱いすんなやww

152:デフォルトの名無しさん
23/11/07 09:23:10.10 pJrSerDn.net
Pythonみたいなインデントずれたら明後日の動きする様な言語は欠損言語だろ

153:デフォルトの名無しさん
23/11/07 09:32:16.68 IkuZHVo7.net
「Linux」メンテナーの燃え尽き症候群問題--業務内容の変化と支援の必要性
URLリンク(japan.zdnet.com)
Corbet氏は「Rust」言語がLinux開発で採用されたことについて歓迎しているものの、これによってメンテナーにさらなる負担がかかるようにもなるとした。同氏は、「カーネルメンテナーを務める以上、Rust言語で記述されたコードのマージ依頼も受け取ることになるため、同言語に対する極めて深い知識が必要となる(中略)既に多忙を極め、自らの仕事量に圧倒されているメンテナーに対して、この新言語の学習を求めるのは酷というものだ。このため、この点は今後、問題となりそうだ」と述べた。

154:デフォルトの名無しさん
23/11/07 09:58:24.32 KQXk8Lyc.net
>>147
インデントに整形以上の意味を持たせた言語の方が好まれてるかどうかの話をしてるのに
他の言語でもインデントで整形してることを根拠にしても意味ないだろ

155:デフォルトの名無しさん
23/11/07 10:27:17.78 sAtxR3nB.net
インデントより会話の論点を揃えないとな

156:デフォルトの名無しさん
23/11/07 10:45:48.18 S2z7fl4T.net
whitespace significantな言語はプログラミングの素人にとっては多少読みやすいというメリットはある
しかしそれ以外はデメリットだらけなので素人を釣りたい場合を除いて採用するメリットがない

157:デフォルトの名無しさん
23/11/07 10:53:19.67 sYaGJjSb.net
リモートワーク制度が削減・廃止されたら「転職や別案件を探す」が4割--
「Offers」登録者調査
ITエンジニア/デザイナーの副業・転職サービス「Offers」を提供するoverflowは、
同社が運営する「Offersデジタル人材総研」にて「リモートワーク実態調査2023」
を公表した。
これによると、リモートワークになり、5人に1人が引っ越したと回答した。そのうち、
現職でリモートワーク制度が削減・廃止された場合、「転職や別案件を探す」�


158:ニいう 回答が44.0%にものぼった。一方「会社と交渉する」という回答は40.0%、 「引っ越さず受け入れる」が12.0%となった。 さらにリモートワークを希望している理由として「通勤時間が無駄だと感じている」が 87.7%でトップとなった。このほか「個人の時間ができる」(62.3%)、「副業を続け やすいから」(39.6%)、「子育てができる」(35.8%)と続いた。



159:デフォルトの名無しさん
23/11/07 16:44:22.56 K3Q4DPSx.net
> Pythonみたいなインデントずれたら明後日の動きする様な言語は欠損言語だろ
ほんとこれ
> インデントより会話の論点を揃えないとな
ほんとこれ

160:デフォルトの名無しさん
23/11/07 16:48:16.87 r4VgdGvO.net
>>150
ずれたら思ってない動作になる場合があるのは確かだが
ずれることがめったに起こらない

161:デフォルトの名無しさん
23/11/07 17:52:17.78 yNm6SVJF.net
正直食わず嫌いなんだが、あのインデント式、慣れない悪寒しかしない
yaml書かされるけど、おっかなびっくりだわ

162:デフォルトの名無しさん
23/11/07 18:32:13.35 WwhMyV/o.net
ifとかforがネストしてるときに論理構成変えたときに
ぐちゃぐちゃになったりしないの?

163:デフォルトの名無しさん
23/11/07 19:03:13.54 nOWHHYht.net
コピペした時困るのはあるけど
そんなネスト深いところにコピペする時点でコードが終わってるのだろう

164:デフォルトの名無しさん
23/11/07 19:24:21.76 RqjiUzBc.net
あっちのファイルはスペースで、こっちのファイルはタブでそれぞれインデントしてるとかw
更に同じファイル内でスペースとタブが混在したインデントしてるとかw

165:デフォルトの名無しさん
23/11/07 21:26:08.28 cNgR9CBR.net
シープラの文法が醜いってとこまで合意できてるってことでいいかな

166:デフォルトの名無しさん
23/11/07 22:35:55.75 irgQLNGX.net
>>162
ダメなのはNim

167:デフォルトの名無しさん
23/11/07 23:28:55.99 hgNhDI9g.net
長いだけあって、いくらでも悪く書ける

168:デフォルトの名無しさん
23/11/07 23:29:26.17 zgo9bT4J.net
>>151
>メンテナーに報酬を支払おうというところはほとんど「ない」のだ
メンテナーほぼ金貰ってないのかw
壮絶な時間の無駄だな
linuxなんて潰れちまえ

169:デフォルトの名無しさん
23/11/07 23:40:27.67 laLhHNQt.net
>>162
インデント構文はその醜さを完全に理解した親切な人が書くとわりとマシに読めるって話なら同意できる

170:デフォルトの名無しさん
23/11/08 07:17:12.54 W3To02R9.net
>>163
Nimの文法が駄目ならRustは産業廃棄物だな。

171:デフォルトの名無しさん
23/11/08 09:28:37.50 G1poaB6X.net
>>167
最初からそう言ってますよね

172:デフォルトの名無しさん
23/11/08 10:02:49.03 RamzJ36x.net
>>165
Linuxなんて無料だから普及したってだけだし
無名の大学生が作った有料カーネルなんか誰が使うかよ

173:デフォルトの名無しさん
23/11/08 10:07:20.75 QixgdFmt.net
Rustが最も美しいけどC++に比べたらPythonの方がまし

174:デフォルトの名無しさん
23/11/08 10:21:07.20 rqy+WU7a.net
cppは汚らしい

175:デフォルトの名無しさん
23/11/08 10:34:17.23 K2ksJD7C.net
あれがいいんだぞ
でも、template<>のごちゃっとしてるのは苦手

176:デフォルトの名無しさん
23/11/08 10:49:02.95 MFNjLgBF.net
NimはPython由来の文法が多い中でprocヘッダーの区切りをわざわざ=記号にしたのは何でなの?

177:デフォルトの名無しさん
23/11/08 11:13:52.74 U7ghqgyy.net
痘痕もエクボっていうしずっと使ってると美しく見えるのかもしれん
始祖のハゲ散らかしもイケオジに見えるのかもしれん

178:デフォルトの名無しさん
23/11/08 11:26:24.47 088wzVve.net
>>173
macro

179:デフォルトの名無しさん
23/11/08 12:07:42.23 fBbSHd4U.net
>>175
関係ないやろ

180:デフォルトの名無しさん
23/11/08 13:10:09.47 l0v/WxBk.net
>>169
BSD

181:デフォルトの名無しさん
23/11/08 14:09:53.13 qh/Yreq5.net
Nimは継承あるじゃん
だれか突っ込めよ
複オジ嘘つき放題じゃねーか

182:デフォルトの名無しさん
23/11/08 14:45:54.44 7EPaeHp0.net
Nim使ってる時点でセンスがないからな

183:デフォルトの名無しさん
23/11/08 15:29:55.01 9/Sq9IWJ.net
Nimはクラスがないため当然クラス継承もない

184:デフォルトの名無しさん
23/11/08 15:41:40.86 hsKTrqcL.net
このスレの半分は複オジのウソで出来ています。
用法・用量を守って正しくご使用下さい。

185:デフォルトの名無しさん
23/11/08 15:50:23.42 J3/ZiO6G.net
複おじってニートでしょ?
なんか我々と対等に喋れること自体がとんでもない体験なんだし
もっと感謝して欲しいね

186:デフォルトの名無しさん
23/11/08 17:01:15.09 wMkAKLer.net
C++er的にC23ってどうなの?

187:デフォルトの名無しさん
23/11/08 17:32:19.27 K2ksJD7C.net
#embed はあると安心 ないとやっぱり一手間かかる
clangではできてたっぽいけど(VC派

188:デフォルトの名無しさん
23/11/08 17:35:31.79 orrrVPZ2.net
>>180
www

189:デフォルトの名無しさん
23/11/08 18:12:04.23 J3/ZiO6G.net
>>180
クラス継承だけが継承ではないのだけどね

190:デフォルトの名無しさん
23/11/08 19:11:51.53 BxyJgb4P.net
有害とされているのはクラスの継承
それ以外の継承はあってもいい

191:デフォルトの名無しさん
23/11/08 19:13:26.39 mR96+8QE.net
>>182
とニートが申しております

192:デフォルトの名無しさん
23/11/08 20:13:44.98 ow8V8oTj.net
有害なのは多重継承では?
単一継承はいいでしょ

193:デフォルトの名無しさん
23/11/08 20:15:54.45 dNhK+uJb.net
綺麗に書けるならという条件がつく
本来、綺麗に階層化するのが目的だったのが、どうしてもごちゃついてしまう
基本にして難 それが継承

って感じでいい?

194:デフォルトの名無しさん
23/11/08 20:28:47.14 dEbgw7JQ.net
>>189
大抵は駄目。
継承は「インターフェイスの共有」という外部との契約と、「実装の共有」という内部との契約をごっちゃにしているから、すぐに設計がごちゃごちゃになる。

内部と外部は明確に分離したほうが手間がかかるが問題になりにくい。

195:デフォルトの名無しさん
23/11/08 20:35:51.69 57OVemIO.net
クラス継承では複数の機能を継承したくなった時に多重継承が起きてしまう
多重継承を避けるには使うすべての機能を巨大なツリー関係に押し込める本末転倒な事態になる

196:デフォルトの名無しさん
23/11/08 20:37:37.21 5gc/7Ny5.net
>継承は「インターフェイスの共有」という外部との契約と、「実装の共有」という内部との契約をごっちゃにしている
Nimの継承にも同じことが当てはまるけど
Nimにはクラスはないから有害じゃないという主張でいいのかな?

197:デフォルトの名無しさん
23/11/08 20:53:57.66 7EPaeHp0.net
>>189
そのレベル浅い知識ならおそらく「SOLID原則」を知らないでしょ
勉強しな?
メンテや機能追加を繰り返してるとどうしても内部構造が腐敗していくものよ

198:デフォルトの名無しさん
23/11/08 21:01:44.80 dEbgw7JQ.net
>>193
理想は継承なしの共通インターフェイス。継承自体いらん。

原理的には同じメソッドを持つのならどんなインスタンスでも同じインターフェイスで扱えるから、継承を使って扱えるインターフェイスを制限するのは「早すぎる最適化」としかいえん。

199:デフォルトの名無しさん
23/11/08 21:07:15.90 5ONqWRVX.net
多重継承って本当に悪か?
多重継承を使う前に周りに悪って教え込まれたので
これまで本格的に使ったことはないのだが
みんなは酷い目にあったことあるかい?
敢えて「多重継承=悪」思考停止論を提起したい

200:デフォルトの名無しさん
23/11/08 21:20:08.15 orrrVPZ2.net
有用なものを何も生み出せない
目的と手段を履き違えた無能たちの知識�


201:oトルロワイヤル



202:デフォルトの名無しさん
23/11/08 21:23:09.85 wwLvTPFi.net
現在動作してる過去のシステムを捨てるわけにいかない状況で、新しい共通システムを書くには継承がいいと思うけど
どうなんでしょう?素人考えなんですけど。

203:デフォルトの名無しさん
23/11/08 21:23:13.22 WEquhdeD.net
オブジェクト指向のメリットってホントにメリットなんだろうか?

204:デフォルトの名無しさん
23/11/08 21:35:45.96 JLAEJM24.net
>>199
モジュール分割の方法を広げるっていうメリットはある。
カーネルドライバー部分はオブジェクト指向した方がいいって、否定派のlinusも認めてる。

205:デフォルトの名無しさん
23/11/08 21:56:55.44 cf3mLuef.net
オブジェクト指向 ⊃ クラスの使用 ⊃ クラス継承の使用
オブジェクト指向自体は問題ない
クラスの使用も継承を用いなければ問題ないが
クラスと他との違いはクラス継承にあるように本質がその継承機能にあるため
クラス自体を無くしたプログラミング言語が最近は多数派となった

206:デフォルトの名無しさん
23/11/08 22:24:24.52 5ONqWRVX.net
>>201
全部マイナー言語じゃん
支持されてないんだよ

207:デフォルトの名無しさん
23/11/08 22:32:30.66 5gc/7Ny5.net
>>195
全く答えになってない
Nimの継承は君が主張している有害な継承に該当するのか否か?

208:デフォルトの名無しさん
23/11/08 22:52:12.05 W3To02R9.net
>>203
「継承自体いらん」と書いているだろ。
shared_ptr<function<T>>のTがインターフェイスになったのがあれば継承自体いらん。

209:デフォルトの名無しさん
23/11/08 23:04:09.93 08jT+y3p.net
>継承は「インターフェイスの共有」という外部との契約と、「実装の共有」という内部との契約をごっちゃにしている
もう一つ付け加えると↑これはデフォルト実装のあるTraitやインターフェースにも同じことが当てはまる
でもインターフェースのデフォルト実装を有害と言う人は少ない
なぜだろうね?

210:デフォルトの名無しさん
23/11/08 23:45:38.02 wMkAKLer.net
特殊事情持ち出して一般論を語るな。
例外的なのが無いとでも思ってるのか

211:デフォルトの名無しさん
23/11/08 23:46:51.04 dNhK+uJb.net
最初はきれいなんだよ、最初は

212:デフォルトの名無しさん
23/11/08 23:59:18.59 57OVemIO.net
>>205
Rustのtraitはデータ(メンバー)とは切り離された設計になっているから
デフォルト実装自身がデータ(メンバー)にアクセスできない点で違うんじゃないか

213:デフォルトの名無しさん
23/11/09 11:54:56.82 Fo7n9qIp.net
>>196
iostream観たら判るし

214:デフォルトの名無しさん
23/11/09 12:57:22.06 vs5NVBb2.net
>>194
SOLIDは名前しか知らないがライブラリのクラスを拡張するときは継承あると便利だけどな
コンポジションだとゲッターかプロパティでライブラリクラスのオブジェクト取得しないといけないし面倒じゃない?

215:デフォルトの名無しさん
23/11/09 15:49:49.48 Nh0igmG8.net
>>210
その継承やらインターフェースの設計をうまくやるためのパターンがSOLIDだよ
これを知らずに継承使ってるやつは大抵ゴミコードを量産してる

216:デフォルトの名無しさん
23/11/09 16:57:59.50 vs5NVBb2.net
>>211
ゴミコードは沢山書いてきたが継承使う時はほどほどにしてるからな
あまりゴミ化はしたことないな
SOLIDは概念が難しかったがこれって継承の複雑さが出ちゃってるね
継承はもっとシンプルに使わないと

217:デフォルトの名無しさん
23/11/09 17:02:28.18 Nh0igmG8.net
>>212
継承がなければSOLIDなんてほぼ考えなくて良いからね
「インターフェース分離の原則」あたりさえ気にしていれば問題ないし
モダンな言語ならインターフェースは言語のコアとして搭載されてる
継承を無くすることでSOLID原則みたいな面倒なことを考えなくても良いし
コードもシンプルになるしメリットしかない
だから最近の言語では継承がない
これがモダンな言語では継承が存在しない理由

218:デフォルトの名無しさん
23/11/09 17:17:08.18 wF5VsxRz.net
>継承がなければSOLIDなんてほぼ考えなくて良いからね
おいおいw
揃いも揃って何なんだここは

219:デフォルトの名無しさん
23/11/09 17:41:32.22 Nh0igmG8.net
>>214

ほぼ継承に関する問題を解決するための原則だぞこれは

220:デフォルトの名無しさん
23/11/09 17:


221:53:14.45 ID:apZquDee.net



222:デフォルトの名無しさん
23/11/09 18:02:47.11 Nh0igmG8.net
S 継承がなければ単一にしかなりようがない
O 継承がなければ勝手に追加も削除も容易
L 継承がなければ置換もクソもない
I 継承がなければインターフェースなんていくらでも分離できる
D 言わずもがな
継承があるからこの原則は生きる
つまり継承の悪い部分を避けるための
オブジェクト指向の原則
その知識は何のためにあるのか?
きちんと自分の頭で考えよう
それが知恵というものだ

223:デフォルトの名無しさん
23/11/09 18:06:49.12 Nh0igmG8.net
オブジェクト指向の全ての悪は継承にあり
DIなんかもこの悪を退治するための刃だ
継承こそがソフトウェアをゴミ化し
変更をしにくくする悪魔👿なのだ
この事実を誰も指摘してないことは驚愕に値する
オブジェクト指向はオワコンとかいう人に限って何が悪なのか明示的に指摘できていない

224:デフォルトの名無しさん
23/11/09 18:07:38.95 Nh0igmG8.net
俺ははっきりと言う
継承こそが全ての間違いの始まりだと

225:デフォルトの名無しさん
23/11/09 18:09:54.14 Nh0igmG8.net
はるか昔「オブ脳」という概念があった
全てをオブジェクト指向で考えようというものだ
まずベースクラスを考えて~
いやちょい待ち
その発想がまず間違っている
なんでベースクラスを最初から考えられると思った?
そんなことは神でもできない
そのようなオブ脳🧠こそゴミエンジニアへの入り口
幸いモダンな言語は継承を排除した
英断だと思う

226:デフォルトの名無しさん
23/11/09 18:13:43.54 Nh0igmG8.net
モダンな言語に置いては
インターフェース(トレイトとか制約とかプロトコルとか言語によって名前は違うが本質は同じ)
ありきで考える
言語のコアもインターフェース前提で設計されている
誰もベースクラスガーとか考えない
まずインターフェース考えよ、となる
そしてそのインターフェースを満たすための構造を考える
こうすることでデータがシンプルになり
頭を悩ますことが減る
これは業務ロジックでも同じ
インターフェースから考えよ

227:デフォルトの名無しさん
23/11/09 18:24:54.65 46vHv3J3.net
solidが面倒ってのもよくわからんな

228:デフォルトの名無しさん
23/11/09 18:28:01.90 GxZAPNre.net
このスレの半分は複オジのウソで出来ています。
用法・用量を守って正しくご使用下さい。

229:デフォルトの名無しさん
23/11/09 18:41:12.35 hICX9By2.net
「それは、継承から始まった。」っていう世代の資産がまだまだあるからね
自分用には、継承を、きれいに書けるようになりたい
C++から逃げるな

230:デフォルトの名無しさん
23/11/09 19:19:30.86 Jqv+rt1P.net
継承を綺麗に書けないバカの断末魔ww

231:デフォルトの名無しさん
23/11/09 19:22:43.00 Nh0igmG8.net
断末魔で結構
継承カッケーと思ってるエンジニアにどどいてくれ

232:デフォルトの名無しさん
23/11/09 19:23:51.89 Nh0igmG8.net
ソフトウェア業界における設計失敗2選
1.ヌルポ
2.継承

233:デフォルトの名無しさん
23/11/09 19:28:25.39 hICX9By2.net
ぬるぽは原始より居ただろ
飼い慣らせない人間が悪い(俺を含む

234:デフォルトの名無しさん
23/11/09 19:45:53.51 Nh0igmG8.net
ヌルポをなくしてOption型をデフォルトにすべきだった
コンパイラによるチェックを必須にすべきだったのよ
本当にこれだけのことで全てが変わった

235:デフォルトの名無しさん
23/11/09 20:06:24.95 T10okj+l.net
>>229
10年後に今の言語がどうけなされてるか言ってみ?

236:デフォルトの名無しさん
23/11/09 20:26:38.28 GhU74Yg7.net
result型とoption型
rustだけがこの2つをデフォルトに採用した
生き残るのはrustだけ

237:デフォルトの名無しさん
23/11/09 20:29:05.07 8vjWDFJE.net
>>229
Object型じゃ型情報少なすぎるだろ。
全てのクラスにNullObjectを付けてnullptrを禁止すればマシになる。
あとインターフェイスはもっと制約を減らすべき。
c++テンプレートだと、テンプレート引数に指定するクラスはテンプレートについて何も知らなくていいけど、インターフェイスもそのレベルでクラス�


238:Eインスタンスから切り離されているべきだ。



239:デフォルトの名無しさん
23/11/09 20:57:20.45 PEX7rJUj.net
> Object型じゃ型情報少なすぎるだろ。
> 全てのクラスにNullObjectを付けてnullptrを禁止すればマシになる

Object型ではなくOption型
全ての各型にNullObjectを付ける必要はなく
任意のT型に対してOption<T>型を用いればよい
Option<T>型の値はSome(Tの値)のNone二択
T型自体は決してNull値やNone値をとなってはいけなくここが肝要

240:デフォルトの名無しさん
23/11/09 21:05:40.49 GhU74Yg7.net
ただジェネリクスやテンプレートがないCに追加するのは容易ではない
それほど罪深い仕様

241:デフォルトの名無しさん
23/11/09 22:19:33.09 /jR/7UWQ.net
C++はまだ改良頑張ってるよ。
Cなんて、C11ぶり10年以上も改良してないとか酷すぎる。

242:デフォルトの名無しさん
23/11/09 22:33:55.61 U2tOOexp.net
C23ってどうなったんだっけか
もう少し先?

243:デフォルトの名無しさん
23/11/09 23:32:03.13 alU/Ei+B.net
SOLIDすら理解してないやつがRust推してるのか
呆れを通り越して悲しみを感じる

244:デフォルトの名無しさん
23/11/09 23:45:28.17 FlvKmVTx.net
SOLID理解してない人はクラス継承派だからアンチRust側

245:デフォルトの名無しさん
23/11/09 23:51:27.12 /jR/7UWQ.net
>>236
新機能は決まって来年ISOから発行

246:デフォルトの名無しさん
23/11/10 00:37:21.40 YpxZ8uto.net
SOLIDもだが30年前から言われてるfavor composition over inheritanceの理由を理解してないのも呆れる
Rustの推し活する前にまずは基礎を学ぼうぜ
じゃないとどの言語使おうがゴミ量産するだけだぞ

247:デフォルトの名無しさん
23/11/10 02:22:01.34 bGIK0BM5.net
継承より合成とそうすべき理由を理解していないのはRustを叩いてる側だな
理解できないがためにいつまでもクラス継承に固執している

248:デフォルトの名無しさん
23/11/10 05:15:36.99 bzX4P4Us.net
俺はRustも継承も嫌いじゃないんだが
SOLIDは難しいから苦手だけど

249:デフォルトの名無しさん
23/11/10 09:27:08.62 YqCm/hRG.net
>>235
だからゴチャゴチャしてるんだ

250:デフォルトの名無しさん
23/11/10 09:40:56.20 aa+qv15K.net
ついつい、機能を全部くらい使って書こうとしちゃうんだよね
複数世代のパラダイムが入ってるから、まぜるな危険

251:デフォルトの名無しさん
23/11/10 10:45:22.93 TCW8Ak5o.net
C++はスマホやPCと同じだよ
昭和ジジイはすぐ「これが持つすべての機能をマスターしてすべて使いこなそう!」とか無意味な事を考え
そして挫折して「パソコンなんて憶えても意味はないっ!人間の尊厳はもっとシンプルなものにあるのだ!
パソコンをつかわずに人間らしい美しい生き方をしよう!」とかいいだす
スマホもPCも自分に必要な機能だけ憶えて使えばいいだけ

252:デフォルトの名無しさん
23/11/10 12:12:06.75 aa+qv15K.net
s/パソコン/スマホ/g

253:デフォルトの名無しさん
23/11/10 13:40:46.42 E5/tDr6w.net
s/ジジイ/池沼/g

254:デフォルトの名無しさん
23/11/10 15:25:54.34 nVu+/fuO.net
かわいそうだな
継承が上手く書けないくらい頭おかしいと

255:デフォルトの名無しさん
23/11/10 16:20:15.04 FL9N1XVu.net
c++はどっちかというとフロントボンネット開けっ放しでエンジン丸出しにしたテスラって感じだけどな

256:デフォルトの名無しさん
23/11/10 16:50:58.76 3Hc35zyY.net
【基礎解説】 メモリ利用を効率化! Modern C++のキモ「ムーブセマンティクス」
URLリンク(codezine.jp)

257:デフォルトの名無しさん
23/11/10 16:51:19.99 tLf5vZ8S.net
>>249
うまい例えのつもりなのか?

258:デフォルトの名無しさん
23/11/10 16:55:26.35 SY+Dup8/.net
テスラ車にエンジンは付いてないけどな

259:デフォルトの名無しさん
23/11/10 20:11:27.55 NL+wF9v3.net
エンジン無しでどうやって走るのかと

260:デフォルトの名無しさん
23/11/10 20:21:08.16


261:VDRR6isO.net



262:デフォルトの名無しさん
23/11/10 20:21:28.96 eRO+Ebqf.net
ガソリンエンジンか、エレクトリックエンジンかの違いだね

263:デフォルトの名無しさん
23/11/10 20:33:46.45 POaaExM9.net
NTにもJetエンジン付いてるね 2色ある

264:デフォルトの名無しさん
23/11/10 23:56:02.81 XAiSTtL/.net
>>248
継承を使わないほうが様々な問題を起こさず上手く書けるというのが本筋
例えばクラスと継承を広めたJavaの生みの親であるJames Goslingも>>102でJavaを作り直せるとしたら継承を除外したいと言っている
これはプログラミング言語界では共通認識であるためモダンな各言語ではクラスとその継承が除外されている

265:デフォルトの名無しさん
23/11/11 00:01:12.93 woXaVSWq.net
発言のコンテキストを理解しようとしないからアホな結論に達するんだよなあ

266:デフォルトの名無しさん
23/11/11 00:03:12.63 uDCEJA+a.net
どうでもいいくだらない話題で延びるのは
上の方に消したいレスがあるとき

267:デフォルトの名無しさん
23/11/11 00:09:22.37 DbOeM/y4.net
消したいのはNimとSOLIDだろうな

268:デフォルトの名無しさん
23/11/11 00:53:13.03 Qqt+MGf6.net
>>258
伝言ゲームで多くの人を介した後の情報にしか接しようとしない人はコンテキストとかわかんないんだよ

269:デフォルトの名無しさん
23/11/11 00:54:21.99 CRU56Rbd.net
アスペルガーはそういうのわからないよ

270:デフォルトの名無しさん
23/11/11 01:19:19.80 PsmtBz7W.net
Go/Rust/Elixir の3大言語は継承ない。
でも継承のある、Ruby の米国年収は、3大言語を超えた!
Ruby, Elixir : 9.3 万ドル
Go : 8.9
Rust : 8.7
多くの言語 : 6.5~7
PHP : 5
Dart : 4.4
Ruby on Rails, AWS Solution Architect は13万ドルとか!
YouTube で有名な雑食系エンジニア・KENTA は、
初心者のキャリアパスは、Rails → Go だけと言ってる
文系のアホには全職種の中で唯一、Railsがチート職業!

271:デフォルトの名無しさん
23/11/11 07:03:04.53 6YPjiDGp.net
>>257
Rustはclassの機能をstruct,impl,traitにばらしているからな。

いっそのことimplも無くしてnimみたいなメソッド構文にしてほしいわ。

272:デフォルトの名無しさん
23/11/11 09:24:43.23 sUAuCE0K.net
>>264
他の型(=他のclass)と継承関係を持つ型がclass
RustやGoなどにclassの機能はない

273:デフォルトの名無しさん
23/11/11 09:40:11.96 fuGMacjx.net
Rubyはないわ
ΚΕИТΑもないわ

274:デフォルトの名無しさん
23/11/11 09:53:08.61 qMAq6GeL.net
継承を問題だと考えるならそう考える人が使わなきゃ良いだけで
言語仕様からなくす必要はなかったんだよ
他の機能との間に衝突が生じるというのなら無いのも分かるけど
ユーザの選択肢として継承はあるべきだった(発想が原理主義的なんだよね)
間口を狭めた結果ユーザー数は一向に増えない
ユーザー数が少なければユーザー数を増えないという負のスパイラルを抜け出せない
継承はあるものの手本を示すために標準ライブラリ(ってあるのかな?w)で
継承を使わないという方針を取るべきだったと思う

275:デフォルトの名無しさん
23/11/11 09:59:27.11 hCMtMwE+.net
>>263
Ruby使ってるサイトってまだあるの?

276:デフォルトの名無しさん
23/11/11 10:48:09.09 hFMfv8+p.net
TikTok LiteでPayPayやAmazonギフトなどに交換可能な4000円分のポイントをプレゼント中!
※既存TikTokユーザーの方はTikTokアプリ


277:からログアウトしてアンインストールすれば参加できる可能性があります。 1.SIMの入ったスマホ・タブレットを用意する 2.以下のTikTok Litのサイトからアプリをダウンロード(ダウンロードだけでまだ起動しない) https://lite.tiktok.com/t/ZSNfJQ9TG/ 3.ダウンロード完了後、もう一度上記アドレスのリンクからアプリを起動 4.アプリ内でTikTok未使用の電話番号かメールアドレスを使用して登録 5.10日間連続のチェックインで合計で4000円分のポイントゲット ポイントはPayPayやAmazonギフト券に交換可能! 家族・友人に紹介したり通常タスクをこなせば更にポイントを追加で獲得できます。



278:デフォルトの名無しさん
23/11/11 12:33:28.67 8FSI241M.net
>>269
サンキュー試してみる

279:デフォルトの名無しさん
23/11/11 17:06:47.94 rVvrsmp3.net
>>265
その解釈で言うなら>>180は間違いで、Nimにはクラス継承はあるってことでいいのか?

クラスにしろオブジェクトにしろトレイトにしろ、言語によって定義は微妙に違うのだから
特定の言語にだけ当てはまる特性を一般的なものとして語られると、議論に混乱がもたらされる
意図的にやっているのならば、それは藁人形論法と呼ばれる

280:デフォルトの名無しさん
23/11/11 17:17:53.08 rVvrsmp3.net
というか、型ごとにクラスであるか否かが決まるのか?
C++のclass C: public D {};はクラスだが、class C {};はクラスではないということになるのか?

動的型付け言語なら「値がクラスであるための条件」を定義することで何がクラスであるか定義する言語もあるが
(にしたって継承に依存しないだろうが)
静的型付け言語も含めた一般的な定義としては使えなさそうだ

281:デフォルトの名無しさん
23/11/11 17:56:27.75 8uzQmIun.net
カプセル化などはクラス以外にも存在しクラスの固有機能ではない
クラスをクラスたらしめている要素は継承
Javaの生みの親が>>102で「Javaを作り直すとしたらクラスを除外したい」と発言した意図も、
その後に付加説明しているように「クラスを除外」とは「継承を除外」の意味としている
継承を使わないならクラスである必要はない
それがクラスごと除外した各モダン言語の意図だろう

282:デフォルトの名無しさん
23/11/11 18:18:11.36 rtkZqGR9.net
>>269
友達にも教えてあげる

283:デフォルトの名無しさん
23/11/11 18:19:47.08 Mzt4UIrv.net
実装継承は菱形継承の問題もある

284:デフォルトの名無しさん
23/11/11 18:28:45.74 mn5CSVOj.net
菱形は無理になくてもいい
…といいつつ、あとになって菱形になっちゃいましたもありうるんだろうしな
まあ積極的には使わん 人智を超えるw

285:デフォルトの名無しさん
23/11/11 19:45:32.60 2HJkyP1v.net
>>272
javascriptのprototypeに近いものをclassと思ってるんじゃないかな

286:デフォルトの名無しさん
23/11/11 20:07:27.33 Ig0qHM6i.net
JavaScriptもC++と同じく実装継承だからアウトだろ

287:デフォルトの名無しさん
23/11/12 00:15:34.52 EWqnRvOH.net
>>268
Githubとかはまだ使ってるみたいだけど明らかに減ってきてる感あるね

288:デフォルトの名無しさん
23/11/12 00:36:55.65 E93HrjVI.net
>>267
ユーザー数と継承機能の有無は関係無いぞ

289:デフォルトの名無しさん
23/11/12 01:09:33.43 l8rhUXJt.net
>>280
>>89の通り大有りだ

290:デフォルトの名無しさん
23/11/12 01:59:57.74 daW7Mc+n.net
エンジニアなら作ったもので勝負しろ

291:デフォルトの名無しさん
23/11/12 02:41:28.74 E93HrjVI.net
>>281
元になった言語があるかどうかじゃん。継承関係ねーじゃん。

292:デフォルトの名無しさん
23/11/12 04:42:06.75 yMP0yjCE.net
>>281
全部ドマイナー

293:デフォルトの名無しさん
23/11/12 08:54:04.31 TrDrLjQN.net
モダン言語=関数型ベースにボクの考えた似非オブジェクト指向追加するのが流行ってるだけって感じで終わってる

294:デフォルトの名無しさん
23/11/12 09:00:27.54 EWqnRvOH.net
とは言っても俺らより遥かに頭いい人が考えた結果だからな

295:デフォルトの名無しさん
23/11/12 09:53:11.34 l8rhUXJt.net
>>283
ユーザ数が少ないとユーザは増えないんだよ
おまいらはどマイナー言語が趣味だろうけども世間は違う
ユーザ数を増やすには既存の言語のユーザを分捕るのが手っ取り早い
継承関係がないってことは他言語のユーザが学習したり
他言語のライブラリを移植する際にハードルとなる
期せずして書かれた>>89は上は全部どマイナー言語
下の言語はC++もそうだけどユーザー数が上より遥かに多い
普及戦略には既存言語との互換性が最大の影響を与えるということを示している
俺様の理想のみを追求した原理主義では誰もついてこない

296:デフォルトの名無しさん
23/11/12 09:57:24.71 l8rhUXJt.net
そういやRustで書かれたOSが実用化される話を読んだよ
軌道に乗ればRustを使う現場が増えるかもね
URLリンク(www.gizmodo.jp)

297:デフォルトの名無しさん
23/11/12 10:10:01.41 nDYms+cf.net
ロゴがVAIOっぽくて草ァ

298:デフォルトの名無しさん
23/11/12 10:24:30.80 l8rhUXJt.net
本家は英語のページがない
URLリンク(blueos.vivo.com)

299:デフォルトの名無しさん
23/11/12 11:24:34.62 yMP0yjCE.net
古い?
オブジェクト指向経験者のためのRust
URLリンク(qiita.com)

300:デフォルトの名無しさん
23/11/12 11:25:51.39 yMP0yjCE.net
どうでもいいけど
ドマイナーってCmのことだね

301:デフォルトの名無しさん
23/11/12 11:31:15.41 yMP0yjCE.net
>>288-290
Rust 推してんの中國人なんか?
そういえば github の Rust も中國語多い気がするな
Rust に関わるのもう辞めようかな

302:デフォルトの名無しさん
23/11/12 11:32:56.85 CMeM7fMz.net
情熱的な曲ってCmベース多いよ
ドマイナーはドマイナーじゃない(豆
# そのギャグどっかで使おうっと

303:デフォルトの名無しさん
23/11/12 11:34:44.94 CMeM7fMz.net
母数でかいし、まだまだ金回りいいしね cnをなめちゃだめだw

304:デフォルトの名無しさん
23/11/12 11:39:24.18 l8rhUXJt.net
>>293
コンピュータに関しては中国はもうかなりの分野で日本を凌駕してる
日本人にはRustで書かれたOSを実用化することは
残念ながら金輪際できないだろうね
プライドを捨てる必要がありそうだ

305:デフォルトの名無しさん
23/11/12 11:56:22.44 TjUPxwN+.net
>>257
偉い人の名前どうでもいいから具体的な話をしなさいよ
まあ無理だろうけどw

306:デフォルトの名無しさん
23/11/12 12:50:23.87 gR0aPFqO.net
Rustが浸透する可能性としてAIライブラリの充実がカギのような気がする。
ライブラリが充実すればマイコンへのAI実装が加速するかもしれないんじゃないかな?

307:デフォルトの名無しさん
23/11/12 13:00:10.14 E93HrjVI.net
>>287
javaにはinterfaceがあるしkotlinにもある。
objective-cにはprotocolがあるしswiftにもある。
うん、継承関係ねーな。

308:デフォルトの名無しさん
23/11/12 13:24:47.44 yMP0yjCE.net
どうみても結果論で
Java に class も継承も無くて interface だけだったら
普及も糞も無かったはず
今の Rust より地位低かっただろう

309:デフォルトの名無しさん
23/11/12 13:42:28.02 l8rhUXJt.net
JavaはC++と


310:文法を似せたことが初期でのユーザ獲得に効いたんだよ ある程度ユーザ数を獲得したら ユーザ数の多さがユーザ数の増加につながる 正のスパイラルが始まった Rustはこの先生きのこれるかな?



311:デフォルトの名無しさん
23/11/12 15:04:17.66 2kP6dQwH.net
GoogleのC++スタイルガイドでも継承より合成が適切とあり
特に実装の多重継承は強く非推奨とある
C++には継承があるから積極的に使おうなんて話はない

312:デフォルトの名無しさん
23/11/12 15:10:39.48 BtB8NmKb.net
インターフェースの多重実装は?
俺的にはアリだが

313:デフォルトの名無しさん
23/11/12 15:12:06.22 FXO/G2ox.net
アリというかそれは普通だろ

314:デフォルトの名無しさん
23/11/12 17:22:10.37 fcqBe9ye.net
たとえアンチでも、それは過去資産という位置づけでは

315:デフォルトの名無しさん
23/11/12 19:58:58.70 UMFi1GHl.net
>>302
なぜ非推奨と言ってるの?
それはどうでもよくてGoogleと言いたい人なの?

316:デフォルトの名無しさん
23/11/12 20:22:32.82 EWqnRvOH.net
合成とか言うのか昔(2000年代前半頃)C++勉強してた頃には合成とかいう言葉なかった気がする

317:デフォルトの名無しさん
23/11/12 20:32:20.30 EyVQy8uj.net
compositionでしょ?

318:デフォルトの名無しさん
23/11/12 20:54:38.02 oa0+ZaPS.net
composition over inheritanceの文脈で
compositionを合成と訳すのば明らかに誤訳

319:デフォルトの名無しさん
23/11/12 21:10:07.68 uw3vvLb2.net
チンポジション推奨はわかるがひたすらデリゲード書く羽目になるのはだるい
文法的にサポートすべき

320:デフォルトの名無しさん
23/11/12 22:58:36.87 OO+koJ2d.net
>>307
継承が濫用されまくった反省から…っていう認識でいいのかな

継承とくらべてコンポジはフットプリントのコストがかかるけど(個人の感想です)、
そのくらいいいから、もっとわかりやすく書かないとって気運は確かに感じた

321:デフォルトの名無しさん
23/11/12 23:24:53.52 R2fa8NnH.net
James Goslingがクラスを無くすという話で警鐘を鳴らしたかったのはimplementation inheritanceのマイナス面
クラスがなくてもGoやRustにもimplementation inheritanceは存在していてそのマイナス面も全部ではないが継承してる
大事なのはプラス面とマイナス面の両面を把握した上で適宜使い分けるということ

322:デフォルトの名無しさん
23/11/12 23:29:45.60 p1tJuVOt.net
ちなみにRustは単純なクラス継承相当はないからコードの再利用がやりにくいという弱みがある
言語開発者もそれはかなり昔から認識してて機能追加をあれこれ検討してるが実現には至ってないためマクロを使ってコードを複製することが多い

323:デフォルトの名無しさん
23/11/12 23:33:34.84 kGZwhVgb.net
そのためのクレートでは(エアプ

324:デフォルトの名無しさん
23/11/13 00:43:02.47 AJp6/mRY.net
オブシコの綻び
継承無くしてオブシコ厨の大好きだった動物犬猫ニンゲンはどう表現するんですか

325:デフォルトの名無しさん
23/11/13 01:10:29.96 uWfytJAu.net
みんな違ってみんないい

ってか、おまえらが自分らと同じクラスなど、不遜にもほどがあるニャ

326:デフォルトの名無しさん
23/11/13 02:50:04.87 SmGbt3Rc.net
トレイトって仕組みわりと便利だけどな
PHPでもこの仕組み取り入れられててわりと重宝する

327:デフォルトの名無しさん
23/11/13 07:32:53.84 tgErF0Wq.net
基本はアダプタパターンで、本来はインターフェイスに代入するときに自動で適合してくれるのがいいのよ。
継承はクラスの親子関係でやらなきゃいけないから依存が強すぎるし、合成も実装とインターフェイスが切り離せないから密結合しすぎる。

328:デフォルトの名無しさん
23/11/13 08:45:58.99 nbPiM1Pw.net
リファクタリングするときに
Rustの「親切設計」が思考の邪魔をしてくる
どうにかならんか?

329:デフォルトの名無しさん
23/11/13 08:47


330::34.93 ID:nbPiM1Pw.net



331:デフォルトの名無しさん
23/11/13 08:49:35.17 nbPiM1Pw.net
>>310
>ひたすらデリゲーション
RustのTraitもこれなんだな

332:デフォルトの名無しさん
23/11/13 09:10:04.39 y0V48+mZ.net
>>318
それがcomだな

333:デフォルトの名無しさん
23/11/13 11:10:08.61 mdWiRvuj.net
>>319
どんなコード?

334:デフォルトの名無しさん
23/11/13 11:24:38.37 Ex26ICxs.net
>>322
継承無しのcomで、インターフェイスはコンパイル時に検証する感じがいい。

335:デフォルトの名無しさん
23/11/13 18:01:25.01 QMjdC+SV.net
新たなゲームエンジン「Arete Engine」発表
URLリンク(automaton-media.com)

Rustベースとのこと
対応言語として、C++, C#ほか

336:デフォルトの名無しさん
23/11/13 19:27:32.88 eizg6Llc.net
なんか良さげじゃないか
これブレークしたらRust大発展場、ワンチャンありそう

337:デフォルトの名無しさん
23/11/13 22:14:58.07 vy9Jjh7g.net
6.x以降サポートされてLinuxカーネルコンパイルできるんだね。知らんかった。
Cから置き換わるか?
まだ、メジャーバージョンアップはありそうな気がするが

338:デフォルトの名無しさん
23/11/13 22:30:02.31 VKpgHGcI.net
>>325
Unityの1000倍高速な部分を売りにして
Unityと違ってライセンス料金も低く広く無料カバーされ
Unityからの置き換えを狙ってるな

339:デフォルトの名無しさん
23/11/14 00:08:42.55 elb2YwUG.net
>>327
今まで動いてたものを置き換わることは無いんじゃね。
新規ドライバとかは少しずつ対応されるかもね。

340:デフォルトの名無しさん
23/11/14 07:56:37.32 NHwXNMzQ.net
>>327
ドライバだけに使われることあっても置き換わることはありえない

341:デフォルトの名無しさん
23/11/14 08:35:51.95 DoXgoJ+r.net
置き換えになる前に、Cが強化される方に期待

やっぱり、クリティカル用のCってあったほうがいい

342:デフォルトの名無しさん
23/11/14 10:15:35.52 XadOWBX2.net
Cは進化を前提としたABIではないから
シンタックスシュガー的な強化しかできない
モダンな機能を求めるならCにトランスパイルする言語を使うことになる

343:デフォルトの名無しさん
23/11/14 12:09:27.81 SRCspH78.net
fn main(){
println!("{}", 111111111*111111111);
println!("{}", 111111111u64*111111111u64);
}
1653732529
12345678987654321
警告もコンパイルエラーも出ないんだが
Rustってあほなんか?

344:デフォルトの名無しさん
23/11/14 13:48:38.27 CBni7tLT.net
C++の唯一の得意分野だったゲームまでRustに置き換わりそう

345:デフォルトの名無しさん
23/11/14 15:16:56.57 XhCdgplR.net
>>333
書いてるやつがアホなだけだろw

346:デフォルトの名無しさん
23/11/14 16:14:21.75 SRCspH78.net
あほが間違ったのを指摘できるのがRustのメリットじゃなかったんか

347:デフォルトの名無しさん
23/11/14 16:25:51.54 B1tltd4R.net
程度による

348:デフォルトの名無しさん
23/11/14 16:28:06.37 Z/oEWqNB.net
>>333
そのままやってみたらエラー出た

 error: this arithmetic operation will overflow
  --> src/main.rs:2:18
  |
 2 | println!("{}", 111111111*111111111);
  | ^^^^^^^^^^^^^^^^^^^ attempt to compute `111111111_i32 * 111111111_i32`, which would overflow
  |
  = note: `#[deny(arithmetic_overflow)]` on by default

型を全く指定しないとi32型とみなされるようだ
エラーも丁寧に出るから初心者にもやさしいな

349:デフォルトの名無しさん
23/11/14 18:34:48.03 hryaTN3D.net
>>330
言い切るのはいいが、その根拠を示さないとな。

350:デフォルトの名無しさん
23/11/14 18:48:47.69 do91JJab.net
ドライバ開発用の環境しかないから
知らんのか

351:デフォルトの名無しさん
23/11/14 19:23:59.78 hryaTN3D.net
現状はそうだけど
それでは、未来永劫置き換わらないと言えないのでは?
sudoとか置き換わってるよ

352:デフォルトの名無しさん
23/11/14 20:26:23.93 QUrDO32K.net
>>338
paiza.io があほだな
URLリンク(paiza.io)

353:デフォルトの名無しさん
23/11/14 21:16:27.35 K+bD5cJ/.net
オーバーフローチェックがどういう時に働くか把握してないならThe Bookからやり直しましょう

354:デフォルトの名無しさん
23/11/14 21:54:16.75 sG8x0H9f.net
>>341
置き換わってねーよw

355:デフォルトの名無しさん
23/11/14 22:10:44.82 elb2YwUG.net
>>331
Cの機能強化はあきらめろ。
委員会の顔はベンダーのほうをみていてCを良くしようなんて思ってないから。

356:デフォルトの名無しさん
23/11/14 22:30:39.73 e1z7sXs7.net
>>341
未来永劫とか言い出すのはガキ
今から置き換えるメリットがない
せいぜいcの黒魔術マクロを排除できるぐらいだろ

カーネルサイズ大きくなりました
ちょっと遅くなりました
気持ちメモリ安全になった気がします
どうせこういう結果になる

357:デフォルトの名無しさん
23/11/14 23:19:38.77 hryaTN3D.net
もちついて。
きき方が悪かったんだけどさ、LinuxカーネルをRust置き換えがありえないってのはなぜ?
これが聞きたかっただけですよ。
現状からの置き換えコストがかかるからという理由は置いといて、すでになにかあるの?
ケンカしたいんじゃないぞ

>>344 sudoは置き換わってないね

358:デフォルトの名無しさん
23/11/14 23:52:26.09 5RSSAN+/.net
LinuxのカーネルのソースコードをすべてRustに置き換えたときそれはLinuxと呼べるのだろうか
(テセウスのパラドックス)

359:デフォルトの名無しさん
23/11/15 00:44:03.25 aoVQj80M.net
Rustの道具立てが揃ってきたら
スケジューラとかネットワークスタックなど
コアな部分をRustで書き直そうぜとか
言い出す人は確実にでると思うけど
POSIX互換(Linux互換)カーネルを
Rustでゼロから書いた方が早いとかなるのかどうか

360:デフォルトの名無しさん
23/11/15 00:55:26.57 ywV5GNL0.net
残念ながらレビューできる人がいない

361:デフォルトの名無しさん
23/11/15 01:32:50.34 ywV5GNL0.net
>>347
>>>344 sudoは置き換わってないね
どのディストリビューションの何が置き換わった?

362:デフォルトの名無しさん
23/11/15 02:15:41.37 1U/J6vOE.net
口から出任せばっかりのRust宣教師
それに付き合う暇人

363:デフォルトの名無しさん
23/11/15 05:50:02.33 y8SxX7I2.net
カーネルをコンパイルできるか、ってのは、ひとつのベンチマークになるらしい(どっかで見た
C2Rustみたいな翻案ツールができたら、Linuxで試されるようには思う

364:デフォルトの名無しさん
23/11/15 08:24:44.15 yd8/VhXj.net
Linusの気持ちは?

365:デフォルトの名無しさん
23/11/15 08:28:35.87 L9zXFwKt.net
「その頃」のLinusはカス嫌いだったんだろうから、アウトプットがよければどうでもいい、だろ
C++は百花繚乱感があって、後から考えたらあれは嫌われるわけだ

366:デフォルトの名無しさん
23/11/15 09:41:39.61 pZco8j8P.net
Linuxはもう枯れたと言える技術分野であって
エッジな人々が集まるところではないからな
エンタープライズ分野でたとえれば汎用機システムのメンテナンスしてるようなもの

367:デフォルトの名無しさん
23/11/15 10:46:32.75 PvDO1mrU.net
>>351
wiki見るとAndr


368:oidは置き換わってるように書いてあるね。 アマゾンのAWSのLinux?とか カーネルは6.6.1でfind -name '*.rs' で引っかけるとmallocとかCのライブラリ関係かな?ほかいろいろ LLTM=1スイッチで置き換わるようだが。 すぐに全体が置き換わるわけではないだろうけど、コアで脆弱性なところから始まってる感じに思えるね。



369:デフォルトの名無しさん
23/11/15 11:16:22.78 ywV5GNL0.net
最新の安定版カーネルは11月8日にリリースされたV. 6.6.1
$ curl 'URLリンク(cdn.kernel.org)' -o - | tar xJf -
$ find linux-6.6.1 -name *.rs | xargs cat | wc -l
19033
$ find linux-6.6.1 -name *.c -o -name *.h | xargs cat | wc -l
32601643

19033 / (19033 + 32601643) = 0.05834643034374886
Rustのソースは僅か0.058%

370:デフォルトの名無しさん
23/11/15 11:18:06.72 ywV5GNL0.net
Rustがlinuxに取り込まれたのが昨年12月でV. 6.1
$ curl 'URLリンク(cdn.kernel.org)' -o - | tar xJf -
$ find linux-6.1 -name *.rs | xargs cat | wc -l
10359
$ find linux-6.1 -name *.c -o -name *.h | xargs cat | wc -l
31476383
この11ヶ月にCで書かれたのは32601643 - 31476383 = 1125260ステップ
その間にRustで書かれたソースは19033 - 10359 = 8674ステップ

増分を比較すると
8674 / 1125260 = 0.007708440715923431
Rustで書こうって人はCの0.8%未満ってことだ
C開発者が100人いたらRust開発者は1人もいないくらい

Linuxカーネルのプロジェクトで
Rustに存在感は全くない
少なくとも最初の11ヶ月間の事実

371:デフォルトの名無しさん
23/11/15 11:20:10.48 ywV5GNL0.net
>>357
>すぐに全体が置き換わるわけではないだろうけど、コアで脆弱性なところから始まってる感じに思えるね。
全くそうは思えないのだが?

372:デフォルトの名無しさん
23/11/15 11:25:52.06 7t1hSBTd.net
このスレの半分は複オジのウソで出来ています。
用法・用量を守って正しくご使用下さい。

373:デフォルトの名無しさん
23/11/15 11:35:20.23 PvDO1mrU.net
>>360
そういわれると、たしかにコードの置き換えとしては進んでない感じするな
まだ実験検討段階って感じか

374:デフォルトの名無しさん
23/11/15 12:21:37.48 no7PoE7H.net
>>356
世間知らず
クラウドインフラの技術が集結してる

375:デフォルトの名無しさん
23/11/15 12:27:36.50 teqcURmf.net
>>347
「コスト」が最大の理由だろ。
コードをRustに置き換えるだけでも膨大な手間と時間がかかる。

そもそもLinusとかのメンテナがRustを使いこなすのに何年費やすかね。そんな時間があったら現環境で機能強化するわな。

376:デフォルトの名無しさん
23/11/15 13:00:57.66 no7PoE7H.net
clangでのビルドにも慎重なのにrustで置き換えなんか進むわけない
そもそも書き換える行為に生産性がないのだから
せいぜい新しく書くところで部分的に使っていきましょうとなる
だからドライバでとなる

377:デフォルトの名無しさん
23/11/15 13:19:00.88 ywV5GNL0.net
Rustの本家本元のfirefoxのソースコードでも
Debianの115.4.0esr-1~deb12u1を調べると以下の通りだよ
Rust(*.rs) 15%
JS(*.js) 35%
C++/C(*.cpp *.cxx *.c *.h) 50%
LinuxでRustがCを置き換えるなんてことは
>>341の言葉を借りて「未来永劫」ないとないと言い切ってやろう

378:デフォルトの名無しさん
23/11/15 14:07:32.56 g71OGRWz.net
>>366
単に物量の問題だろ
何百万行あると思ってるんだよ

379:デフォルトの名無しさん
23/11/15 14:11:39.36 ywV5GNL0.net
>>367
ざっと2千500万行だね

380:デフォルトの名無しさん
23/11/15 14:24:01.47 kSRDfKJq.net
30年の積み重ねを置き換えるのに30年…
とまでは行かなくても5年で大部分書き換え
とかはなら


381:んだろう



382:デフォルトの名無しさん
23/11/15 14:51:21.03 6FugGo49.net
元々Cで造られたプロジェクトを一部だけRustに置き換えなんて面倒なだけでメリット無い
どうせRustでやるんだったら全部描き治しの方が良いに決まってる
Rustで置き換えと言うよりRustで新たにLinux互換プロジェクトが出来上がるだけ

383:デフォルトの名無しさん
23/11/15 14:56:46.34 /tSVEj7/.net
>>368
ひぇっ

384:デフォルトの名無しさん
23/11/15 15:12:05.87 PvDO1mrU.net
Andoroidは置き換え比較的進んでるよ、事実だしこれは否定しようがない。

>>356が言うようにLinuxはメンテナーが少なくなってきてるという記事を読んだことがある。
Cを本当に使える人が減ってきてるんだってさ。AIとかに流出してるのかもね。
Linuxは長い実績で堅牢なんだろうけどまだ脆弱性を含んでいるのは間違いないし。
メンテナーのレベルが落ちると長年で培った堅牢性がゆらいでいくんじゃない?
時間かけてじわじわいくよ。

385:デフォルトの名無しさん
23/11/15 16:57:42.00 HubpN1/i.net
>>372
カーネルに新機能追加する人は給料貰ってフルタイムで
やってる人がいるけどコードレビューする人は
ボランティアベースで辛いという話だぞ

386:デフォルトの名無しさん
23/11/15 18:15:25.04 /tSVEj7/.net
>>372
富士通の社員がやってるんじゃないの?

387:デフォルトの名無しさん
23/11/15 18:31:31.15 c9l3XMad.net
GoogleがAndroid OSのRust化を進めている

388:デフォルトの名無しさん
23/11/15 19:02:01.02 V2KbO/sW.net
都合の悪い話されるとすぐそうやって話題変える

389:デフォルトの名無しさん
23/11/15 21:13:40.04 ywV5GNL0.net
>>372,375
プログラマなんだから話は定量的にどうぞ

390:デフォルトの名無しさん
23/11/15 21:36:10.57 2QF9cM/v.net
トランスレータ作ればいいのにね

391:デフォルトの名無しさん
23/11/15 21:48:13.78 FmmLZXFq.net
Linux Kernelコードの70%はドライバー
こいつらは基本的にデバイス屋さんが書いてる

392:デフォルトの名無しさん
23/11/15 23:20:59.98 9Wll1i1V.net
>>372
>Cを本当に使える人が減ってきてるんだってさ。

×Cを本当に使える人が減ってきてる
○Linuxをメンテしたい人が減ってきてる
大事な所を履き違えんなよ

393:デフォルトの名無しさん
23/11/15 23:25:45.67 /tSVEj7/.net
Linusは自分がいなくなっても継続できるようにしてると言ってたけどホントかいな

394:デフォルトの名無しさん
23/11/16 02:20:43.10 YE0GrThs.net
ああいうワンマン強引タイプの周辺はだいたい
イエスマン(しかも心中はそのうち取って代ってやると思ってる野心家)ばっかりになってて
本人は継続できるようなつもりになってるけどいざ倒れると急におかしな方向いったり弱体化したりしがち

395:デフォルトの名無しさん
23/11/16 07:32:35.40 nbKqUUuT.net
>>381
もう本人コード書いてないし

396:デフォルトの名無しさん
23/11/16 09:47:18.38 wNLmB51s.net
カーネルの話にAndroidを出してくる奴

397:デフォルトの名無しさん
23/11/16 10:24:39.57 csSKyxVc.net
>>383
リーナス氏はカーネルを書いただけの人で、Linuxはgnuの周辺が無ければ成立しないんだよなぁ

398:デフォルトの名無しさん
23/11/16 10:36:18.81 c22vQqL3.net
ニュース記事を斜め読みしただけで
プログラム書いてなさそう人が参入してるな

399:デフォルトの名無しさん
23/11/16 10:58:48.69 oAo4ftxR.net
複おじのことやん

400:デフォルトの名無しさん
23/11/16 11:04:24.85 JqwSNCs1.net
>>384
GoogleがAndroid用にforkしたLinuxカーネルへ加えた変更がアップストリームにも適用されることが多々あるから別におかしい話じゃないぞ
Androidと関係なくてもGoogle自体がLinuxカーネルを進化させてるメジャープレイヤーでもある

401:デフォルトの名無しさん
23/11/16 11:05:25.04 wNLmB51s.net
rustサポートって何してるのか気になってコミットログ読んでみたけどこんなもんか

402:デフォルトの名無しさん
2023/11/1


403:6(木) 11:15:44.45 ID:cWrKpE+4.net



404:デフォルトの名無しさん
23/11/16 11:20:28.08 QXdh7keC.net
>>376
ほんそれ
>>382
すばらしい洞察

405:デフォルトの名無しさん
23/11/16 11:23:05.99 5W7eUxhr.net
既存の枯れた部分を移行するメリットは低くそこに興味を持っているのはおまえらだけ
全く新たに作られていってるシステムなどに使われていく言語が世間での焦点

406:デフォルトの名無しさん
23/11/16 11:36:03.27 oAo4ftxR.net
>>392
なるほどはっきりしたな
RustはC/C++の置き換えには適さない
以上!!!!本スレは終了!!!!

407:デフォルトの名無しさん
23/11/16 11:40:52.68 5W7eUxhr.net
既存の枯れた安定してるものを他言語で置き換えなんてムダなことをするバカはいない
>>5のような新たなシステムがどの言語で書かれているかが全て


次ページ
最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch