2ちゃんねる ■掲示板に戻る■ 全部 1- 最新50    

■ このスレッドは過去ログ倉庫に格納されています

結局C++とRustってどっちが良いの? 8traits

1 :デフォルトの名無しさん:2023/10/28(土) 13:45:00.38 ID:fh9BWjjr.net
「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」

っていう雑談スレ。

・C/C++ <=> Rust いまさら聞けない移行質問なども適当にどぞ
・レスバはじめんのは勝手だけど、面白いこと・へぇなこと書いたヤツが優勝
・マな話は、マのスレもご活用ください↓

前スレ: 結局C++とRustってどっちが良いの? 7traits
http://mevius.5ch.net/test/read.cgi/tech/1693451813/

関連スレ(マ板): Google&Microsoft「セキュリティバグの70%はC/C++のメモリ管理ミス。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

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

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

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

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

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

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

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

6 :デフォルトの名無しさん:2023/10/29(日) 07:04:58.86 ID:/j90tPs+.net
プログラミング言語「Rust」は世界のセキュリティレベルを底上げする
https://wired.jp/article/rust-secure-programming-language-memory-safe/

Androidでは今、暗号鍵を管理する機能の多くがRustで書かれているとGoogleのクライダーマーカーは話す。
たとえば、暗号化したインターネット通信の機能である「DNS over HTTPS」、新バージョンの超広帯域無線(UWB)チップスタック、
そしてグーグルの独自のチップである「Tensor G2」で使用される新しい「Android 仮想化フレームワーク(AVF)」 などだ。

また、BluetoothやWi-Fiなどの通信接続に使われるスタックも、Androidの開発チームによってRustへの変換が積極的に進められている。
理由は、これらが業界の複雑な標準規格に基づいており、脆弱性を多く含む傾向にあるからだとGoogleのクライダーマーカーは付け加える。
つまり最も狙われやすい、あるいは最も重要なソフトウェアの部分からRustに書き換えて、
そこから徐々に広げることで段階的にセキュリティ上の恩恵を受けようという戦略なのだ。

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

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

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

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

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

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

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

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

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

16 :デフォルトの名無しさん:2023/10/29(日) 16:22:18.96 ID:UpWU1GX+.net
時代は静的検出なので、冒頭に

#pragma safe

とかでも書くとかになるんじゃないかな
そのうしろに、縛りの識別子が入るのでもいい

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

18 :デフォルトの名無しさん:2023/10/29(日) 18:07:40.10 ID:UpWU1GX+.net
} // あとでみなおす

とりあえず生ポはなしかな
ポインタはきちんと定義される

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

20 :デフォルトの名無しさん:2023/10/30(月) 14:08:13.49 ID: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 :デフォルトの名無しさん:2023/10/31(火) 05:55:29.82 ID:DJT4usEp.net
ゲーム業界はC++かC#
Rustが入る余地なし

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

23 :デフォルトの名無しさん:2023/10/31(火) 10:17:54.25 ID:Fz0aDVxr.net
設計が悪いおじさん「設計が悪い」

…とはいうものの、書き味ってもんがあるよね言語って

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

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

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

27 :デフォルトの名無しさん:2023/10/31(火) 22:25:05.59 ID:NeIS8/9C.net
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2687r0.pdf
C++はfeature gate方式でアノテーションした箇所のみ
static analyzerでチェックする方針で一応進み始めてるのね

なんというか過去の資産を生かすというのは大変なんだな
Rustと同レベルのsafetyが提供できるようになるかどうかまだわからないけどまあ頑張ってという感想

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

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

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

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

32 :デフォルトの名無しさん:2023/11/01(水) 08:49:48.50 ID:VeDR0B8A.net
耳が痛いわ〜w (横から

>>27
走り読み…と思ったら、かっちりしたまとめだった
型に含めることばっかり(自分なりに)考えてたが、属性かー。

ああそういや、VCの属性プロバイダ、API公開まだだったよな

33 :デフォルトの名無しさん:2023/11/01(水) 09:15:51.82 ID:QJoNTbA8.net
borrow! またお前かっ!!
ですね
判ります

あとは C# みたいな PartialTrait があれば良いのに

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

56 :デフォルトの名無しさん:2023/11/02(木) 16:27:45.50 ID:26D/b4Fo.net
そこは言語によって異なるんだよ

Pythonは月曜スタート
weekday() 月曜日=0 ~ 日曜日=6
isoweekday() 月曜日=1 ~ 日曜日=7

Javaも月曜スタート
DayOfWeek 月曜日=1 ~ 日曜日=7

だから両対応しているRustが最も良い状況

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

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

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

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

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

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

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

64 :デフォルトの名無しさん:2023/11/03(金) 06:56:19.57 ID:N2L5n51t.net
伝統的には日曜始まり、商用的には月曜始まり、ということだろ。

そもそも現代主流のグレゴリオ暦自体が欠陥だらけ (素数の7を週単位にしている、月の日数がバラバラ) だから、効率を気にしてもしょうがない。
完全数の6と3素数積の30を基準にすれば全然違ったのにな。

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

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

67 :デフォルトの名無しさん:2023/11/03(金) 10:30:38.41 ID:FAT4ZC6j.net
C++もc_encodingとiso_encodingで両方対応はしてる
簡単に変換できるから正直どうでもいいけど

https://en.cppreference.com/w/cpp/chrono/weekday/encoding
このドキュメントはReturn valueの2) の内容が間違ってる
レビュープロセスが心配になるな

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

69 :デフォルトの名無しさん:2023/11/03(金) 12:30:23.11 ID:xNBDqk0z.net
>>56
JavaはWeekFields経由で日曜始まりにもできる
Pythonは日曜始まりのインデックスを直接取得することはできないがcalenderモジュールで日曜始まりのカレンダーを扱える

どちらもRustほど低レイヤーやC++を意識する必要がないからRust比べて少し高いレイヤーで日曜始まりにも対応している
Rustの開発者にとって最もいい状況が他の言語の開発者にとっても最もいい状況とは限らない

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

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

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

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

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

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

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

74 :デフォルトの名無しさん:2023/11/03(金) 16:35:04.29 ID:hQugpIJj.net
プログラミング言語は とにかくユーザ数が増えて裾野が広がらないとだめよ

とはいっても、Rustはその性格上 エンジン系にはとても強いと思う

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

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

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

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

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

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

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

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

83 :デフォルトの名無しさん:2023/11/03(金) 22:56:37.98 ID:oS0jLPzO.net
これすごいわ
https://www.youtube.com/watch?v=62ZcxDGawd4
Rust もびっくり

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

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

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

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

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

89 :デフォルトの名無しさん:2023/11/04(土) 00:23:19.27 ID:EeyeeoXm.net
最近のプログラミング言語は基本的にオブジェクト指向だがクラス継承だけは亡くなったらしい

最近のプログラミング言語
【クラス継承がない】Elixir、Go、Julia、Nim、Rust、Zig
【クラス継承がある】Kotlin(=Javaの後継)、Swift(=Objective-Cの後継)
つまり過去のしがらみでクラス継承を含めざるを得なかったKotlinとSwiftを除いて
全ての言語でクラス継承は亡くなった

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

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

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

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

94 :デフォルトの名無しさん:2023/11/04(土) 03:24:41.20 ID:W1fOq5zR.net
継承無くした結果、馬鹿なことをやらされる
https://qiita.com/muumu/items/a0d111d129d20240d182

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

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

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

98 :デフォルトの名無しさん:2023/11/04(土) 07:37:08.58 ID:tOjhAD6C.net
そうゆうのがない、切り捨ててるから、Linuxカーネルに来てよろしいって言われたのかもね しらんけど

やっぱり必要となりゃ、そのうち解禁(追加)になるでしょ

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

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

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

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

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

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

105 :デフォルトの名無しさん:2023/11/04(土) 09:59:34.34 ID:eaDg3ztu.net
>>93
>GUIはクラス継承要らないだろ
要るか要らないかという話はしてないよ

1) Elixir、Go、Julia、Nim、Rust、Zig
2) Kotlin、Swift

1)の言語でGUI作れなくはないけど実際に作る開発者がかなり少ない
逆に2)の言語は大半の開発者がGUIを作ってる
それには理由があるということ
もっと言えばクラス継承的な機能の有無はトレードオフだからそれを理解しましょうねという話

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

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

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

俺のおかんはC++

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

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

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

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

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

114 :デフォルトの名無しさん:2023/11/04(土) 16:44:29.40 ID:qG8ydW8y.net
いまさら人に聞けない
悪い継承ってのがわからなくなった

継承おぼえたてて(一人プロジェクトが)めちゃくちゃになった経験ならあるけど、そうじゃなくてこう

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

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

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

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

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

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

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

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

123 :デフォルトの名無しさん:2023/11/04(土) 22:19:37.19 ID:+CP/CRpL.net
>>122
所有権はC++にもある
traitはC++の抽象クラスからデータ(メンバー)を分離独立させてより良い設計ができるようになっている
使いづらくなっていない

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

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

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

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

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

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

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

131 :デフォルトの名無しさん:2023/11/06(月) 04:14:47.70 ID:m6bVjB7O.net
>>130
そんなことよりこのクソスレ立てたのもお前?
https://mevius.5ch.net/test/read.cgi/tech/1693054853/

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

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

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

Nimの勝ち

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

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

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

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

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

139 :デフォルトの名無しさん:2023/11/06(月) 18:18:33.08 ID:mZ9CqDyY.net
C++は仕様などがugly
Rustはbeauty

140 :デフォルトの名無しさん:2023/11/06(月) 18:45:27.89 ID:Yw0Fs1sT.net
>>138
お前もかなりのザコだぞ

141 :デフォルトの名無しさん:2023/11/06(月) 19:58:38.94 ID:2NClhQZD.net
>>137
文法はNimの圧勝。

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

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

144 :デフォルトの名無しさん:2023/11/06(月) 22:14:50.32 ID:BFZIHaDs.net
複オジ代表チーっすw

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

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

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

148 :デフォルトの名無しさん:2023/11/07(火) 09:16:54.55 ID:YntbMeAj.net
詭弁 - Wikipedia
https://ja.wikipedia.org/wiki/%E8%A9%AD%E5%BC%81

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

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

151 :デフォルトの名無しさん:2023/11/07(火) 09:32:16.68 ID:IkuZHVo7.net
「Linux」メンテナーの燃え尽き症候群問題--業務内容の変化と支援の必要性
https://japan.zdnet.com/article/35210969/

Corbet氏は「Rust」言語がLinux開発で採用されたことについて歓迎しているものの、これによってメンテナーにさらなる負担がかかるようにもなるとした。同氏は、「カーネルメンテナーを務める以上、Rust言語で記述されたコードのマージ依頼も受け取ることになるため、同言語に対する極めて深い知識が必要となる(中略)既に多忙を極め、自らの仕事量に圧倒されているメンテナーに対して、この新言語の学習を求めるのは酷というものだ。このため、この点は今後、問題となりそうだ」と述べた。

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

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

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

155 :デフォルトの名無しさん:2023/11/07(火) 10:53:19.67 ID:sYaGJjSb.net
リモートワーク制度が削減・廃止されたら「転職や別案件を探す」が4割--
「Offers」登録者調査

ITエンジニア/デザイナーの副業・転職サービス「Offers」を提供するoverflowは、
同社が運営する「Offersデジタル人材総研」にて「リモートワーク実態調査2023」
を公表した。
これによると、リモートワークになり、5人に1人が引っ越したと回答した。そのうち、
現職でリモートワーク制度が削減・廃止された場合、「転職や別案件を探す」という
回答が44.0%にものぼった。一方「会社と交渉する」という回答は40.0%、
「引っ越さず受け入れる」が12.0%となった。
さらにリモートワークを希望している理由として「通勤時間が無駄だと感じている」が
87.7%でトップとなった。このほか「個人の時間ができる」(62.3%)、「副業を続け
やすいから」(39.6%)、「子育てができる」(35.8%)と続いた。

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

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

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

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

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

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

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

163 :デフォルトの名無しさん:2023/11/07(火) 22:35:55.75 ID:irgQLNGX.net
>>162
ダメなのはNim

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

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

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

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

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

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

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

171 :デフォルトの名無しさん:2023/11/08(水) 10:21:07.20 ID:rqy+WU7a.net
cppは汚らしい

172 :デフォルトの名無しさん:2023/11/08(水) 10:34:17.23 ID:K2ksJD7C.net
あれがいいんだぞ

でも、template<>のごちゃっとしてるのは苦手

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

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

175 :デフォルトの名無しさん:2023/11/08(水) 11:26:24.47 ID:088wzVve.net
>>173
macro

176 :デフォルトの名無しさん:2023/11/08(水) 12:07:42.23 ID:fBbSHd4U.net
>>175
関係ないやろ

177 :デフォルトの名無しさん:2023/11/08(水) 13:10:09.47 ID:l0v/WxBk.net
>>169
BSD

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

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

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

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

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

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

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

185 :デフォルトの名無しさん:2023/11/08(水) 17:35:31.79 ID:orrrVPZ2.net
>>180
www

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

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

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

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

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

って感じでいい?

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

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

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

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

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

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

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

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

197 :デフォルトの名無しさん:2023/11/08(水) 21:20:08.15 ID:orrrVPZ2.net
有用なものを何も生み出せない
目的と手段を履き違えた無能たちの知識バトルロワイヤル

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

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

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

201 :デフォルトの名無しさん:2023/11/08(水) 21:56:55.44 ID:cf3mLuef.net
オブジェクト指向 ⊃ クラスの使用 ⊃ クラス継承の使用

オブジェクト指向自体は問題ない
クラスの使用も継承を用いなければ問題ないが
クラスと他との違いはクラス継承にあるように本質がその継承機能にあるため
クラス自体を無くしたプログラミング言語が最近は多数派となった

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

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

204 :デフォルトの名無しさん:2023/11/08(水) 22:52:12.05 ID:W3To02R9.net
>>203
「継承自体いらん」と書いているだろ。

shared_ptr<function<T>>のTがインターフェイスになったのがあれば継承自体いらん。

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

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

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

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

209 :デフォルトの名無しさん:2023/11/09(木) 11:54:56.82 ID:Fo7n9qIp.net
>>196
iostream観たら判るし

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

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

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

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

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

215 :デフォルトの名無しさん:2023/11/09(木) 17:41:32.22 ID:Nh0igmG8.net
>>214

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

216 :デフォルトの名無しさん:2023/11/09(木) 17:53:14.45 ID:apZquDee.net
Lだけだろ

217 :デフォルトの名無しさん:2023/11/09(木) 18:02:47.11 ID:Nh0igmG8.net
S 継承がなければ単一にしかなりようがない
O 継承がなければ勝手に追加も削除も容易
L 継承がなければ置換もクソもない
I 継承がなければインターフェースなんていくらでも分離できる
D 言わずもがな

継承があるからこの原則は生きる
つまり継承の悪い部分を避けるための
オブジェクト指向の原則

その知識は何のためにあるのか?
きちんと自分の頭で考えよう
それが知恵というものだ

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

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

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

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

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

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

224 :デフォルトの名無しさん:2023/11/09(木) 18:41:12.35 ID:hICX9By2.net
「それは、継承から始まった。」っていう世代の資産がまだまだあるからね

自分用には、継承を、きれいに書けるようになりたい
C++から逃げるな

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

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

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

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

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

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

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

232 :デフォルトの名無しさん:2023/11/09(木) 20:29:05.07 ID:8vjWDFJE.net
>>229
Object型じゃ型情報少なすぎるだろ。
全てのクラスにNullObjectを付けてnullptrを禁止すればマシになる。

あとインターフェイスはもっと制約を減らすべき。
c++テンプレートだと、テンプレート引数に指定するクラスはテンプレートについて何も知らなくていいけど、インターフェイスもそのレベルでクラス・インスタンスから切り離されているべきだ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

246 :デフォルトの名無しさん:2023/11/10(金) 12:12:06.75 ID:aa+qv15K.net
s/パソコン/スマホ/g

247 :デフォルトの名無しさん:2023/11/10(金) 13:40:46.42 ID:E5/tDr6w.net
s/ジジイ/池沼/g

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

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

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

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

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

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

254 :デフォルトの名無しさん:2023/11/10(金) 20:21:08.16 ID:VDRR6isO.net
モーター

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

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

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

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

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

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

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

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

263 :デフォルトの名無しさん:2023/11/11(土) 01:19:19.80 ID: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がチート職業!

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

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

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

266 :デフォルトの名無しさん:2023/11/11(土) 09:40:11.96 ID:fuGMacjx.net
Rubyはないわ
ΚΕИТΑもないわ

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

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

269 :デフォルトの名無しさん:2023/11/11(土) 10:48:09.09 ID:hFMfv8+p.net
TikTok LiteでPayPayやAmazonギフトなどに交換可能な4000円分のポイントをプレゼント中!
※既存TikTokユーザーの方はTikTokアプリからログアウトしてアンインストールすれば参加できる可能性があります。

1.SIMの入ったスマホ・タブレットを用意する
2.以下のTikTok Litのサイトからアプリをダウンロード(ダウンロードだけでまだ起動しない)
https://lite.tiktok.com/t/ZSNfJQ9TG/
3.ダウンロード完了後、もう一度上記アドレスのリンクからアプリを起動
4.アプリ内でTikTok未使用の電話番号かメールアドレスを使用して登録
5.10日間連続のチェックインで合計で4000円分のポイントゲット

ポイントはPayPayやAmazonギフト券に交換可能!
家族・友人に紹介したり通常タスクをこなせば更にポイントを追加で獲得できます。

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

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

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

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

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

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

274 :デフォルトの名無しさん:2023/11/11(土) 18:18:11.36 ID:rtkZqGR9.net
>>269
友達にも教えてあげる

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

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

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

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

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

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

281 :デフォルトの名無しさん:2023/11/12(日) 01:09:33.43 ID:l8rhUXJt.net
>>280
>>89の通り大有りだ

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

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

284 :デフォルトの名無しさん:2023/11/12(日) 04:42:06.75 ID:yMP0yjCE.net
>>281
全部ドマイナー

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

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

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

288 :デフォルトの名無しさん:2023/11/12(日) 09:57:24.71 ID:l8rhUXJt.net
そういやRustで書かれたOSが実用化される話を読んだよ
軌道に乗ればRustを使う現場が増えるかもね
https://www.gizmodo.jp/2023/11/vivo-blueos.html

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

290 :デフォルトの名無しさん:2023/11/12(日) 10:24:30.80 ID:l8rhUXJt.net
本家は英語のページがない
https://blueos.vivo.com/

291 :デフォルトの名無しさん:2023/11/12(日) 11:24:34.62 ID:yMP0yjCE.net
古い?
オブジェクト指向経験者のためのRust
https://qiita.com/nacika_ins/items/cf3782bd371da79def74

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

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

294 :デフォルトの名無しさん:2023/11/12(日) 11:32:56.85 ID:CMeM7fMz.net
情熱的な曲ってCmベース多いよ
ドマイナーはドマイナーじゃない(豆

# そのギャグどっかで使おうっと

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

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

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

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

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

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

301 :デフォルトの名無しさん:2023/11/12(日) 13:42:28.02 ID:l8rhUXJt.net
JavaはC++と文法を似せたことが初期でのユーザ獲得に効いたんだよ
ある程度ユーザ数を獲得したら
ユーザ数の多さがユーザ数の増加につながる
正のスパイラルが始まった
Rustはこの先生きのこれるかな?

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

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

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

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

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

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

308 :デフォルトの名無しさん:2023/11/12(日) 20:32:20.30 ID:EyVQy8uj.net
compositionでしょ?

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

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

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

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

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

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

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

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

316 :デフォルトの名無しさん:2023/11/13(月) 01:10:29.96 ID:uWfytJAu.net
みんな違ってみんないい

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

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

318 :デフォルトの名無しさん:2023/11/13(月) 07:32:53.84 ID:tgErF0Wq.net
基本はアダプタパターンで、本来はインターフェイスに代入するときに自動で適合してくれるのがいいのよ。

継承はクラスの親子関係でやらなきゃいけないから依存が強すぎるし、合成も実装とインターフェイスが切り離せないから密結合しすぎる。

319 :デフォルトの名無しさん:2023/11/13(月) 08:45:58.99 ID:nbPiM1Pw.net
リファクタリングするときに
Rustの「親切設計」が思考の邪魔をしてくる

どうにかならんか?

320 :デフォルトの名無しさん:2023/11/13(月) 08:47:34.93 ID:nbPiM1Pw.net
>>298
小池AIなら要らないぞ

321 :デフォルトの名無しさん:2023/11/13(月) 08:49:35.17 ID:nbPiM1Pw.net
>>310
>ひたすらデリゲーション

RustのTraitもこれなんだな

322 :デフォルトの名無しさん:2023/11/13(月) 09:10:04.39 ID:y0V48+mZ.net
>>318
それがcomだな

323 :デフォルトの名無しさん:2023/11/13(月) 11:10:08.61 ID:mdWiRvuj.net
>>319
どんなコード?

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

325 :デフォルトの名無しさん:2023/11/13(月) 18:01:25.01 ID:QMjdC+SV.net
新たなゲームエンジン「Arete Engine」発表
https://automaton-media.com/articles/newsjp/20231113-271841/

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

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

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

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

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

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

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

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

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

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

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

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

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

337 :デフォルトの名無しさん:2023/11/14(火) 16:25:51.54 ID:B1tltd4R.net
程度による

338 :デフォルトの名無しさん:2023/11/14(火) 16:28:06.37 ID: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型とみなされるようだ
エラーも丁寧に出るから初心者にもやさしいな

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

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

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

342 :デフォルトの名無しさん:2023/11/14(火) 20:26:23.93 ID:QUrDO32K.net
>>338
paiza.io があほだな
https://paiza.io/projects/EOdRe5MWBWrUr4Wtxd_Hiw

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

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

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

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

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

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

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

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

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

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

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

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

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

354 :デフォルトの名無しさん:2023/11/15(水) 08:24:44.15 ID:yd8/VhXj.net
Linusの気持ちは?

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

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

357 :デフォルトの名無しさん:2023/11/15(水) 10:46:32.75 ID:PvDO1mrU.net
>>351
wiki見るとAndroidは置き換わってるように書いてあるね。
アマゾンのAWSのLinux?とか

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

358 :デフォルトの名無しさん:2023/11/15(水) 11:16:22.78 ID:ywV5GNL0.net
最新の安定版カーネルは11月8日にリリースされたV. 6.6.1
$ curl 'https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.6.1.tar.xz' -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%

359 :デフォルトの名無しさん:2023/11/15(水) 11:18:06.72 ID:ywV5GNL0.net
Rustがlinuxに取り込まれたのが昨年12月でV. 6.1
$ curl 'https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.1.tar.xz' -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ヶ月間の事実

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

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

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

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

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

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

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

366 :デフォルトの名無しさん:2023/11/15(水) 13:19:00.88 ID: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の言葉を借りて「未来永劫」ないとないと言い切ってやろう

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

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

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

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

371 :デフォルトの名無しさん:2023/11/15(水) 14:56:46.34 ID:/tSVEj7/.net
>>368
ひぇっ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

387 :デフォルトの名無しさん:2023/11/16(木) 10:58:48.69 ID:oAo4ftxR.net
複おじのことやん

388 :デフォルトの名無しさん:2023/11/16(木) 11:04:24.85 ID:JqwSNCs1.net
>>384
GoogleがAndroid用にforkしたLinuxカーネルへ加えた変更がアップストリームにも適用されることが多々あるから別におかしい話じゃないぞ

Androidと関係なくてもGoogle自体がLinuxカーネルを進化させてるメジャープレイヤーでもある

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

390 :デフォルトの名無しさん:2023/11/16(木) 11:15:44.45 ID:cWrKpE+4.net
>>385
なおさら駄目じゃね?
GNUツールのRust移行とか不可能だろ。

391 :デフォルトの名無しさん:2023/11/16(木) 11:20:28.08 ID:QXdh7keC.net
>>376
ほんそれ

>>382
すばらしい洞察

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

393 :デフォルトの名無しさん:2023/11/16(木) 11:36:03.27 ID:oAo4ftxR.net
>>392
なるほどはっきりしたな
RustはC/C++の置き換えには適さない

以上!!!!本スレは終了!!!!

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

395 :デフォルトの名無しさん:2023/11/16(木) 11:44:41.17 ID:c22vQqL3.net
>>388
AndroidのRust適用はミドルウェアとか
実行ファイルの話

396 :デフォルトの名無しさん:2023/11/16(木) 11:52:51.95 ID:nxuWB9A/.net
>>394
新規のシステムもRustよりC++/Cの方が多いでしょうよ
Rustはユーザ数が少な過ぎる

397 :デフォルトの名無しさん:2023/11/16(木) 11:59:45.29 ID:oAo4ftxR.net
>CDNプロバイダのCloudflareは、同社のグローバルなCDNの基盤として長らく利用してきたNGINXに代えて、

>>394「C言語製の枯れて安定してるnginxをわざわざRustで置き換えるCloudflareはムダなことをするバカ」

398 :デフォルトの名無しさん:2023/11/16(木) 12:24:14.05 ID:AwpJQf7l.net
>>397
Pingoraの話じゃないの?

399 :デフォルトの名無しさん:2023/11/16(木) 12:31:03.07 ID:1vSd70Wx.net
>>397
記事読めてる?
nginxでは機能が不十分で様々な検討をして新たに作ることになったとある
そしてRust製のPingoraを開発して以下の性能を出したと記事に書かれている

>Pingoraはすでに同社のCDNに採用され、毎日1兆回以上のリクエストを処理し、性能向上や数多くの新機能の提供を実現しつつ、従来と比較してCPUとメモリリソースの消費はいずれも3分の1程度に収まっているとのこと。

400 :デフォルトの名無しさん:2023/11/16(木) 12:42:36.36 ID:c22vQqL3.net
>>397
nginxでは性能の限界があってRustで新規に
作ったと記事の読み飛ばしたところに
書きてなかった?

401 :デフォルトの名無しさん:2023/11/16(木) 12:47:30.32 ID:QXdh7keC.net
APIがRustになってないとRust採用する意味が無い

402 :デフォルトの名無しさん:2023/11/16(木) 12:53:18.79 ID:1vSd70Wx.net
>>401
今回の話の場合APIに相当するものはHTTPだと思いますが
APIがRustになっていないと、とは何?

403 :デフォルトの名無しさん:2023/11/16(木) 12:53:44.43 ID:oAo4ftxR.net
nginxの代わりに使えるものを「新しく」作ったのだからPingoraはnginxの「置き換え」ではないと言いたいのか??
じゃあ>>392の言う「移行」>>394の言う「置き換え」って厳密には何のことを指すんだ??

404 :デフォルトの名無しさん:2023/11/16(木) 13:04:58.32 ID:1vSd70Wx.net
たとえ後発のより良い新言語(ex. Rust)であっても
システムそのままで新言語への置き換えはコスト的に意味がなく
新たなシステムへ置き換える時に新言語の採用は大いに意味があるという実例だろう

405 :デフォルトの名無しさん:2023/11/16(木) 13:27:53.62 ID:6XhGio1W.net
403 は言葉使いからして感情でしか物事をみれない

406 :デフォルトの名無しさん:2023/11/16(木) 13:37:39.61 ID:GrubNHks.net
>>383
一応メールの中でコードを書いてるって言ってたけどね

407 :デフォルトの名無しさん:2023/11/16(木) 13:40:47.78 ID:GrubNHks.net
>>397
そりゃCloudflareレベルの規模ならメリットはあるだろう
メリットがあるなら書き直すし
メリットがないなら書き直さない
それだけ

408 :デフォルトの名無しさん:2023/11/16(木) 14:28:52.70 ID:U5aa+aRa.net
>>394
置き換えがしたいという意志があるとは誰も言ってない
そもそも修正と新規作成をどうしても区別したいという意志がない

ただ、ミクロな意志と無関係なマクロな現象として
置き換えが自然発生するかも知れないという謎の空気はある

409 :デフォルトの名無しさん:2023/11/16(木) 15:09:24.13 ID:IFD1cI+g.net
early adoptersやearly majorityになるのは
Linuxのperipheralとしてビジネスをしている企業ではなく
Linuxをperipheralとしたビジネスをしている企業

前者の大半はゲームのルールを他者に支配されている立場であり裁量の余地が小さいためマインドセットが保守的
純粋なコストベネフィット以外に低いリスク選好度からくる心理的抵抗が強いためearly adoptersやearly majorityにはなりにくい
複オジがいつも事例であげてるAndroid、Cloudflare、AWSなどが全て後者なのは偶然ではなく構造上の特性から生じる必然
新しい技術というのはゲームのルールを自らコントロールできるこちら側の企業によって牽引される

410 :デフォルトの名無しさん:2023/11/16(木) 15:14:00.47 ID:IFD1cI+g.net
つまり何が言いたかったかというと
Linux KernelにおけるRustの採用率というのは
技術採用ライフサイクルの観点で見た場合
late majorityやluggardsのRust採用率の目安だということ

411 :デフォルトの名無しさん:2023/11/16(木) 15:14:30.69 ID:QXdh7keC.net
adaptor だと思ってたけど adopter なんか

412 :デフォルトの名無しさん:2023/11/16(木) 15:24:27.23 ID:JRjQuxlT.net
>>410
× luggards
○ laggards

413 :デフォルトの名無しさん:2023/11/16(木) 15:29:19.80 ID:FRf+5dUd.net
early adopter とは
https://dictionary.goo.ne.jp/word/en/early+adopter/
アーリーアダプター,(新製品の)初期受容者

adopter とは
https://dictionary.goo.ne.jp/word/en/adopter/
1 採用[採択]者
2 養い親,里親

414 :デフォルトの名無しさん:2023/11/16(木) 16:41:51.84 ID:cWrKpE+4.net
>>403
コードの移行、コードの置き換え。

>397は>370の例だろ。

415 :デフォルトの名無しさん:2023/11/16(木) 17:06:23.69 ID:DQsCMcKm.net
それぞれのケースで大きく異なるから区別が必要

(1) 新規に作るもの
CloudflareやAWSの例やゲームの新フレームワークやLinuxの新たなデバドラ等すべてこれ
これらは100% Rustが有利

(2) 既存のソフトの言語のみの置き換え
(2)-a. スクリプト言語などからの言語の置き換え
CPUやメモリの使用リソース削減が目的ならばRust化は有利

(2)-b. C/C++からの言語の置き換え
セキュリティやメモリ管理の不安定で困ってる時にRust化が有利

一般的に可能なら(2)の単なる言語間の移植よりも
設計を見直して(1)の新規作成とした方が好ましい

>>399でCloudflareがCPUメモリリソース消費1/3にできた例も
単なるC→Rustへの(2)移植ではなく
新たな設計での(1)新規作成だからであろう

416 :デフォルトの名無しさん:2023/11/16(木) 17:13:48.99 ID:GrubNHks.net
C/C++から書き直すにしても設計をそのまま使えないことが多いから
かなり大変なんだよな
とくに参照やポインタだらけで全部ヒープアロケーションしまくってる場合とか
C++でもその辺りポインタを多用せずスマポやスタック割り当てをうまく使って書いてあるソフトは移植しやすい

417 :デフォルトの名無しさん:2023/11/16(木) 17:41:46.11 ID:cVeFFprT.net
どの言語からでもいいけどRustに移行するのにプログラム設計もそのまま引き継いだ自動コンバージョン的な移行を想定するほうがおかしいやろ
そんなんありえんよ

418 :デフォルトの名無しさん:2023/11/16(木) 17:41:52.36 ID:nV/QBQ73.net
C/C++にRust世代の知見が流入してくることに賭けて、待ってる勢はあるはず 自分はそう
それもあるけど、いまあるRustから前線で知見を得ようという勢もあるはず

419 :デフォルトの名無しさん:2023/11/16(木) 17:47:05.98 ID:nV/QBQ73.net
>>417
C/C++もclangがいったん咀嚼してLLVMにしてる
Rustにトランスパイルするのは非現実的とまではいえないはず
うまくいけば、Linuxは一夜にしてpure Rustになる
Rust派の誰かがやるんじゃないかと思ってる

420 :デフォルトの名無しさん:2023/11/16(木) 17:51:33.13 ID:xS+g93Tz.net
>>417

いつもの藁人形論法

AWSが最初からRustで構築されたとでも思ってんのかね

421 :デフォルトの名無しさん:2023/11/16(木) 17:55:14.82 ID:GrubNHks.net
全てスタック変数で割り当てる
コピー時に適切なムーブをする
ヒープが必要なところはスマポを使う

これをちゃんとやればC++をrustに置き換えることは可能
しかしこれをやってるC++プロジェクトはない

422 :デフォルトの名無しさん:2023/11/16(木) 17:56:48.64 ID:GrubNHks.net
>>420
そいつの意見を真面目に考えてて草

423 :デフォルトの名無しさん:2023/11/16(木) 18:05:24.97 ID:nV/QBQ73.net
ま、雑談だから
ストローマンは愚痴

一頃のC++はなんでもかんでもヒープに置きすぎだったよね
まあ、お膝元のスタックがそんなでかくない石・スレッドも少なくないけど

424 :デフォルトの名無しさん:2023/11/16(木) 18:12:37.43 ID:C/58Cd2m.net
>>419
わざわざLLVM IRまで降りて戻ってこなくてもc2rustとか最低限のトランスパイラはいくつかあるぞ
出力結果は作業の開始地点として使うものでそのままプロダクションに使うものじゃない

425 :デフォルトの名無しさん:2023/11/16(木) 18:27:30.00 ID:nV/QBQ73.net
c2rustの出力をあんまり手直しばっかりしなくていいように、
入力のCにアノテーションを加えていこう、みたいな動きは必ず出ると思うんだよね
良くも悪くもCはマクロ世界だから、当面関わってない人には影響ゼロなようにも書けるはず

そのアノテーションが、そのまま、safe C の礎になればいいんだよ

426 :デフォルトの名無しさん:2023/11/16(木) 18:28:02.28 ID:jjq/yUIi.net
ああ、ストローマンは自動コンバージョンに反応したのか
“的な”の意味が通じなかったんだな

427 :デフォルトの名無しさん:2023/11/16(木) 18:39:53.99 ID:RH2XyDS1.net
>>397
記事を読めてないバカを晒すスレはここですか?

428 :デフォルトの名無しさん:2023/11/16(木) 18:40:10.28 ID:U5aa+aRa.net
LinuxはスクリプトとCの二刀流だ
PythonとCの関係はRustとCの関係にも使える

その知見が流入してこない原因はスクリプト不要論だろう

429 :デフォルトの名無しさん:2023/11/16(木) 20:51:00.53 ID:AwpJQf7l.net
>>423
だがスマートポインタはスタックに置いて参照渡ししたい。

430 :デフォルトの名無しさん:2023/11/16(木) 23:13:12.09 ID:BwM227bO.net
>>425
Cの安全性を高める目的ならトランスパイラではなく静的コード解析ツール用にアノテーションするほうが遥かに簡単
C++と同じようにCにもそういう動きが出てくる可能性はあると思う

ただ安全性を高めようとすればするほど既存のコードとはかけ離れていくからMISRAのように標準化され半強制的なものにならない限り広く受け入れられる気がしない

イメージ的には↓こういうやつ
浸透するとしても10年以上先だろうね
https://www.youtube.com/watch?v=Pk2RAl8kG1o

431 :デフォルトの名無しさん:2023/11/16(木) 23:35:15.35 ID:nxuWB9A/.net
そこで奥さんChat-GPTですよ!

432 :デフォルトの名無しさん:2023/11/16(木) 23:43:26.30 ID:4If2hIRf.net
>>430
Cの標準では今後も無い。
委員会がやる気ない。

433 :デフォルトの名無しさん:2023/11/17(金) 00:28:52.66 ID:XzLpc9VL.net
Cは他のお笑い言語とは違って俺が最初に手に取ったK&R第二版から変える必要無かったからな

434 :デフォルトの名無しさん:2023/11/17(金) 00:34:46.03 ID:UIKq6eA7.net
>>433
さすがにK&Rからは変わってる
(ギャグだったならスマン)

435 :デフォルトの名無しさん:2023/11/17(金) 00:41:31.13 ID:ofj+MCpV.net
C++もlifetime annotationどうするか決まってないんだな
一番めんどくさくてコードも汚くなる部分だからannotation周りの評価はlifetime+borrow checkerの出来次第だと思ってる
https://discourse.llvm.org/t/rfc-lifetime-annotations-for-c/61377

436 :デフォルトの名無しさん:2023/11/17(金) 01:27:31.74 ID:lIdOKj8F.net
やる気が暴走したPerlとかC++とかを過大評価するのは暑苦しい
やる気以外のルールはないのか

437 :デフォルトの名無しさん:2023/11/17(金) 05:30:59.53 ID:30xMjeDv.net
あー、Perlも好きだわーw
ドザなので、シェルスクリプト代わりに、中途半端な処理は全部お願いしてる

438 :デフォルトの名無しさん:2023/11/17(金) 10:14:27.25 ID:vs9w0Abf.net
>>436
無能な働き者がやる気を出すとね……

439 :デフォルトの名無しさん:2023/11/17(金) 21:12:15.87 ID:+5SAg77h.net
NGINXモジュールがRustで書けるようになった
https://www.infoq.com/jp/news/2023/11/nginx-modules-rust/

440 :デフォルトの名無しさん:2023/11/17(金) 22:09:06.15 ID:HoPy7y+y.net
>>421
>コピー時に適切なムーブをする
これが恣意的すぎて自動的に対応できんわな。

441 :デフォルトの名無しさん:2023/11/17(金) 23:36:50.31 ID:FMmcnveO.net
>>436
その2言語は増築工事でダメになった

442 :デフォルトの名無しさん:2023/11/17(金) 23:58:55.97 ID:8WHR7HZ4.net
継承でダメになった、と言った?
ほぼそれに近い?

443 :デフォルトの名無しさん:2023/11/18(土) 11:21:22.60 ID:ZyDTP43o.net
立場によってはそう
継承に親でも殺されたんかって人なら、そう言うだろう

でもそれ、自分の推しの言語に継承かなにかが後出し採用されたら、ブーメランだぞw

444 :デフォルトの名無しさん:2023/11/18(土) 11:36:22.09 ID:XY0Izw3X.net
クラス継承(実装継承)は悪でプログラミング言語界が一致してるから後から継承の採用はないだろうな
過去のしがらみで継承を採用したSwiftやKotlinですら継承を使わずに済む機構などを採り入れている

445 :デフォルトの名無しさん:2023/11/18(土) 11:44:56.68 ID:GRi2RJZB.net
その結果>>89が示す通りマイナー言語に留まっているじゃん?
ユーザ数を増やすことを優先しないと
数多あるマイナー言語の一つとして忘れ去られる

446 :デフォルトの名無しさん:2023/11/18(土) 11:52:32.21 ID:GRi2RJZB.net
言語のユーザ数の増加要因として最大なのはユーザー数だよ

447 :デフォルトの名無しさん:2023/11/18(土) 11:58:51.53 ID:63IqxYSZ.net
>>446
頭沸いてんのかおまえ、進次郎かよw

448 :デフォルトの名無しさん:2023/11/18(土) 12:08:09.00 ID:Q9aHTM00.net
それがわからんようでは、いっしょに旨い酒は呑めんなあw

わかれよーわかりきってんだろ再帰だろ

449 :デフォルトの名無しさん:2023/11/18(土) 12:11:13.74 ID:GRi2RJZB.net
>>447
微分積分はまだなのかな?

450 :デフォルトの名無しさん:2023/11/18(土) 12:11:30.53 ID:63IqxYSZ.net
ユーザー数の多いアプリやOSの開発言語が言語利用者数に影響してるんだろうがいw

451 :デフォルトの名無しさん:2023/11/18(土) 12:22:30.52 ID:moXb3tPD.net
方法が違うだけでRustやGoにも実装継承が採用されてる
SwiftやKotlinは過去のしがらみで実装継承を採用してるわけではない
目的に対して有益だから採用してるだけ

実装継承の乱用するやつも悪だと決めつけるやつも中身を理解してないという意味では同類だから
どの言語を使っていようがどちらも採用してはいけない

452 :デフォルトの名無しさん:2023/11/18(土) 12:22:47.39 ID:GRi2RJZB.net
>>450
dN/dt = cN
右辺は一次関数とは限らんだろうけども
新たに学ぶ言語を選択するときには
人は多くの人が使っている言語を選択する傾向にある

453 :デフォルトの名無しさん:2023/11/18(土) 12:27:30.14 ID:63IqxYSZ.net
>>452
そんなん仕事で開発する人には通用しないよw
開発対象がどのハードのどのOSで動かすかによって決まるからな

454 :デフォルトの名無しさん:2023/11/18(土) 12:29:23.25 ID:63IqxYSZ.net
しかし、パラメータの意味も説明も無くいきなり数式出す奴ってなんなの?

455 :デフォルトの名無しさん:2023/11/18(土) 12:31:03.67 ID:jiGs7deg.net
>>451
それは理解していなさすぎる
実装継承とはある型(クラス)に対して定義したメソッドが別の型(クラス)に対して引き継がれることを指す
Rustに実装継承はない

456 :デフォルトの名無しさん:2023/11/18(土) 12:35:26.40 ID:Q9aHTM00.net
継承はダメおじさん「継承はダメ」
IUnk教徒俺「うんこ->Release();」

457 :デフォルトの名無しさん:2023/11/18(土) 12:38:02.55 ID:GRi2RJZB.net
>>453
「仕事で開発する人」ってのは仕事の多さに左右される
新規の言語はまずユーザー数を増やさないと
この先生きのこれない

458 :デフォルトの名無しさん:2023/11/18(土) 12:38:26.91 ID:63IqxYSZ.net
多段継承は何だかなぁだけど
単純な基礎クラスに応用クラス乗せるくらいは許して欲しいなぁ

459 :デフォルトの名無しさん:2023/11/18(土) 12:39:14.68 ID:GRi2RJZB.net
>>454
Nってのは数
tは時間
cは定数
どれもよく使うから端折ったけども?

460 :デフォルトの名無しさん:2023/11/18(土) 12:40:04.55 ID:63IqxYSZ.net
>>457
だからユーザー数なんて増えないんだよw
その言語でしか開発出来ないスマホとかでも作らないとなw

461 :デフォルトの名無しさん:2023/11/18(土) 12:41:04.57 ID:63IqxYSZ.net
>>459
dは何よ?

462 :デフォルトの名無しさん:2023/11/18(土) 12:42:08.12 ID:Q9aHTM00.net
ダァン! ってやつだ

俺が考えた

463 :デフォルトの名無しさん:2023/11/18(土) 12:45:04.02 ID:GRi2RJZB.net
>>461
>>449

464 :デフォルトの名無しさん:2023/11/18(土) 12:49:36.30 ID:zRkY2vB2.net
ネットワーク外部性 - Wikipedia
https://ja.wikipedia.org/wiki/%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E5%A4%96%E9%83%A8%E6%80%A7

465 :デフォルトの名無しさん:2023/11/18(土) 12:49:49.32 ID:63IqxYSZ.net
>>463
ならば進次郎にも分かる説明でないとダメだろ

466 :デフォルトの名無しさん:2023/11/18(土) 12:54:44.31 ID:GRi2RJZB.net
>>465
>>446に分かりやすく書いておる

467 :デフォルトの名無しさん:2023/11/18(土) 12:55:17.22 ID:63IqxYSZ.net
>>466
だからそれは否定されたろ

468 :デフォルトの名無しさん:2023/11/18(土) 12:56:30.92 ID:GRi2RJZB.net
>>467
誰に?

469 :デフォルトの名無しさん:2023/11/18(土) 12:56:35.04 ID:zRkY2vB2.net
仕事で使う技術選定の最大要因ってなんだかんだで利用者数の多さ(≒資料の多さ)になりがち

470 :デフォルトの名無しさん:2023/11/18(土) 12:57:39.99 ID:63IqxYSZ.net
>>468
俺にw

471 :デフォルトの名無しさん:2023/11/18(土) 12:59:42.63 ID:GRi2RJZB.net
>>470
そりゃお前が読めてないだけだよ
>>452の最後の1行も平易に同じことを書いているので読んでね

472 :デフォルトの名無しさん:2023/11/18(土) 13:00:29.94 ID:9pS/cQYo.net
>>461
ワロタ

473 :デフォルトの名無しさん:2023/11/18(土) 13:03:35.26 ID:63IqxYSZ.net
C++の資料なんか腐るほどあるが
今やC#かCしか生き残って無いだろw

474 :デフォルトの名無しさん:2023/11/18(土) 13:05:11.55 ID:63IqxYSZ.net
Rustなんて使わなきや開発出来ないアプリなんか無いし
使う事は未来永劫無いだろうね

475 :デフォルトの名無しさん:2023/11/18(土) 13:06:24.64 ID:9pS/cQYo.net
書けない人がいくら叫んでも無駄

476 :デフォルトの名無しさん:2023/11/18(土) 13:09:08.70 ID:9pS/cQYo.net
Rust書けないからって嫉妬してるのはわかるけどそこまで逆恨みすることはないじゃん?

477 :デフォルトの名無しさん:2023/11/18(土) 13:09:45.32 ID:9pS/cQYo.net
それともここで煽られたから「Rustを書いてる人」が嫌いなのかな?

478 :デフォルトの名無しさん:2023/11/18(土) 13:42:18.00 ID:GRi2RJZB.net
>>473
Debian bookwormのfirefox-esrのソースのうちcとc++を比較すると
ヘッダは区別がつかないので除外して
$ apt source firefox-esr
$ find firefox-esr-115.4.0esr -name *.cpp -o -name *.cxx | xargs cat | wc -l
4766467
$ find firefox-esr-115.4.0esr -name *.c | xargs cat | wc -l
3598263
4766467 / 3598263 = 1.3... C++がCの1.3倍程度
C++はヘッダのみで実装してしまうことも多々あるから1.3倍では済まないだろう
C++の方が多いのだよ
Rustは>>366に書いた通り全体の15%程度(総本山なのに)

479 :デフォルトの名無しさん:2023/11/18(土) 14:46:30.05 ID:BPYzRrhj.net
それ過去に開発された言語が混ざってるよね?

480 :デフォルトの名無しさん:2023/11/18(土) 15:41:41.81 ID:aHGnQ9F/.net
もうすでに15%もあるといった考え方は?現状の%を並べても5年どうなるかわからないんだし。
その調べかたからわかるのことは限定的だな。
その割合が年々減っていってるのならRustはだめだろうし。

481 :デフォルトの名無しさん:2023/11/18(土) 16:00:47.99 ID:Q+v8Z7oO.net
言語の変更は多くの場合システム改新などコードを書き換えるタイミングで行なわれる
また言語の変更をするか否かに関係なくモノリシックなシステムはシステム改新に不利でその点ではマイクロサービスなど多数で構成されるシステムが有利
OSカーネルやWebブラウザも同様でモノリシックに作られている場合は言語の変更に最も適していない
そのような最も適していない極端な特殊例を持ち出して数え上げることは無意味で無駄な行為

482 :デフォルトの名無しさん:2023/11/18(土) 17:15:55.14 ID:rXJKESWN.net
一眼観て微分方程式だと判らないレベルの人は黙っていて欲しい

483 :デフォルトの名無しさん:2023/11/18(土) 19:58:38.30 ID:HxfHsjDi.net
それはわかったけど、英語そんな読めない俺、なんも言えず

教えてもらったRustの再評価? 論文、積ん読になってるんだよねえ
面白そうだったから忘れたことはないけど

484 :デフォルトの名無しさん:2023/11/18(土) 21:45:39.76 ID:0cWoHYmK.net
>>444
一致してない
継承理解できずにアホな使い方する一部の人が勝手に騒いでるだけ
採り入れないとおまえみたいなのが無根拠に騒ぐからとりあえず採り入れてるだけ

485 :デフォルトの名無しさん:2023/11/18(土) 22:49:22.88 ID:zlAHanIg.net
モダンなプログラミング言語のうち、
過去のしがらみのある2つの言語を除いて、
すべての言語が継承をクラスごと排除して採用していないもんな

486 :デフォルトの名無しさん:2023/11/18(土) 22:53:24.96 ID:GRi2RJZB.net
>>485
おかげで全てマイナー言語のままじゃん?

487 :デフォルトの名無しさん:2023/11/18(土) 23:39:14.05 ID:Wj/Y5gpw.net
切捨ては極端すぎる。まるで都合の悪いことは無かったことにする左翼の思想
継承はあった方が便利なんだよ
元々オブシコは継承機能が売りだったのに手のひら返してやっぱ合成でいいって、それC言語でもできることだし…
先祖返り…デグレード…設計ミスってことぉ?

488 :デフォルトの名無しさん:2023/11/18(土) 23:51:56.62 ID:WzRKAbU/.net
2010年以降にできた言語で広く使われてるのは
Kotlin, Swift, Dart, TypeScriptらのクラス継承のある言語

489 :デフォルトの名無しさん:2023/11/19(日) 00:04:07.84 ID:QnG3yXze.net
型のgeneralization/specializationはどの言語でも必須と言っていい機能でspecializeされた型でgeneralな型の実装を再利用できるというのは物凄く直感的でわかりやすく便利な機能だから完全に無くせば利便性を損なうだけ

Rustでも形を変えて実装継承が存在するのはそのため

490 :デフォルトの名無しさん:2023/11/19(日) 04:16:47.88 ID:RVJYDbf6.net
>>489
実装継承は問題点が多すぎるからRustでは採用されていない
実装継承とはある型で定義されたメソッド実装がその型を継承する別の型にそのまま継承されること
Rustは実装継承をちゃんと排除している

491 :デフォルトの名無しさん:2023/11/19(日) 10:00:16.37 ID:tWthAkiw.net
>>490
>実装継承とはある型で定義されたメソッド実装がその型を継承する別の型にそのまま継承されること
さすが進次郎
トートロジーが得意だな

492 :デフォルトの名無しさん:2023/11/19(日) 10:14:54.62 ID:xroD2KWj.net
継承が必須という人は>191 >195 >204に反論してくれんかね?

shared_ptr<function<T>>で、Tをコンセプトに拡張したものがイメージかね。コンセプトに合致する「インスタンス」なら何でも変数に代入できるようにできれば、わざわざ継承で「インスタンス」の代入可能性を確保する必要は無い。

493 :デフォルトの名無しさん:2023/11/19(日) 10:29:52.82 ID:nljhlBVQ.net
>>492
継承で定義のコードを書く手間が減るだけでメリットになっている
デメリットうんぬんは使い方知らないだけ
使う場所間違えてる
以上
論破

494 :デフォルトの名無しさん:2023/11/19(日) 11:09:12.91 ID:xroD2KWj.net
>>493
ずいぶん貧弱な論破だなぁ。

>継承で定義のコードを書く手間が減る
そのために「事前にクラス継承関係をクラスに追加する」という余計な重たい依存関係を埋め込む必要があり、後々のインターフェイス設計に多大なコストが発生する。
依存関係低減のためにAdaptorを使うことになるなら、最初からインターフェイスにAdaptorみたいな機能があった方が良い。

>デメリットうんぬんは使い方知らないだけ使う場所間違えてる

あなたの感想ですか?

495 :デフォルトの名無しさん:2023/11/19(日) 11:18:00.14 ID:a8wUH91D.net
>>492
複オジはデメリットを真に理解してないから
どれレスでも的外れな内容になっている

>shared_ptr<function<T>>で、Tをコンセプトに拡張したものがイメージかね。コンセプトに合致する「インスタンス」なら何でも変数に代入できるようにできれば、わざわざ継承で「インスタンス」の代入可能性を確保する必要は無い。
継承の前にポリモーフィズムから勉強した方がよさそうだね
メリットとデメリットを理解してないというのは同じようだけど

496 :デフォルトの名無しさん:2023/11/19(日) 11:25:06.19 ID:xroD2KWj.net
>>495
おいおい、まともな反論できなくなったらレッテル張りかよ。

>ポリモーフィズム
だからポリモーフィズムにサブタイピングは依存関係重すぎると言っているんだよ。
std::funcionを理解できていますか?

497 :デフォルトの名無しさん:2023/11/19(日) 11:34:23.07 ID:h6lf9AUt.net
記述量が多くなる=悪は誰にでも判るだろう
RADが流行ったのも理解できるだろう
プログラマはいつも何を重視しているのか、それは時間だ
Rustでコンパイル通す時間よりC++でやった方が早かろう
C++でGUIアプリ作るよりC#でやった方が早かろう
さてRustでGUIアプリ作るには、一体どれだけ時間が掛かるのか
話は終わりだ

498 :デフォルトの名無しさん:2023/11/19(日) 11:39:08.94 ID:JXkS/kRe.net
>>492
必須とは考えてないから反論はしない

ユーザが選択できれば良いんだよ
言語としては装備していて
害悪があると考えるならそう考えるユーザが使わなければ良い
他言語のライブラリを移植する際に
使った方が再設計の手間が掛からないというなら使えば良い
マイナー言語のまま終わるぞ

499 :デフォルトの名無しさん:2023/11/19(日) 11:58:31.45 ID:o0KxE9xi.net
数年でRustみたいな思想はAIが肩代わりしてくれると思うよ
今からRustで数年苦労するよりは
他の事しつつ待ってた方がもしかして有意義なんじゃないかな笑

500 :デフォルトの名無しさん:2023/11/19(日) 12:13:25.84 ID:nljhlBVQ.net
>>494
その指摘のような状況で使わなければいいだけ
全てのケースでその指摘が当てはまるわけではない
不適切な使用をしてる例を自分自身で示しているが、それに気づいていない
言うに事欠いて私の感想?
何回論破されるのあなた?

501 :デフォルトの名無しさん:2023/11/19(日) 12:32:27.75 ID:/G2k3fWt.net
>>497
別にRust推す訳じゃないが
その理屈はRustで簡単にGUIが描けるツールが出たら解消してしまうがな

502 :デフォルトの名無しさん:2023/11/19(日) 12:35:10.88 ID:Tj6ZCNuo.net
pythonのpysimpleguiでサクッと作って時間の掛かる処理だけpyo3でコールするか

503 :デフォルトの名無しさん:2023/11/19(日) 13:27:48.93 ID:h6lf9AUt.net
>>501
Rustが世に出て13年みたいだが解消する見込みなし
時間の浪費は罪に等しいと考える現実的なプログラマであれば他の手段を見つけてるだろう
何もかも遅すぎるのろまに構う価値はない

504 :デフォルトの名無しさん:2023/11/19(日) 13:57:40.85 ID:Oy1huhHi.net
>>497
C#でGUIとか今時書かんて

505 :デフォルトの名無しさん:2023/11/19(日) 14:01:24.71 ID:nljhlBVQ.net
>>504
今時はguiには何使うもの?

506 :デフォルトの名無しさん:2023/11/19(日) 14:07:51.59 ID:Oy1huhHi.net
>>505
electronかtauriをガワにして中身はHTML+TypeScript
今のGUIアプリは大抵これ

ちなみに新しいteamsではガワはネイティブ実装で
中身はWebView2というコンポーネントを使っているらしい
作り方はHTML+TypeScriptなのは変わらない
WebView2はまだ簡単には使えないがおそらくこいつが主流になるはず

MS好きならちゃんとキャッチアップくらいしとこうぜ?

507 :デフォルトの名無しさん:2023/11/19(日) 14:10:24.62 ID:Oy1huhHi.net
当たり前だが別にそれにしろとは言わん
シンプルな業務系の画面なら何でも良いし作りやすい方が良い
RustのGUIは今のところ有力なものはないのは事実

508 :デフォルトの名無しさん:2023/11/19(日) 14:21:03.03 ID:BvvFFAMC.net
「マウス」のイベントハンドラを継承するメリットが誰にでもわかる
という前提が怪しいんだよ
マウスだぞマウス

509 :デフォルトの名無しさん:2023/11/19(日) 14:38:54.75 ID:iOyghJL5.net
え?! RustってGUIライブラリがないの??

510 :デフォルトの名無しさん:2023/11/19(日) 14:57:36.66 ID:/G2k3fWt.net
Tauriは糞

511 :デフォルトの名無しさん:2023/11/19(日) 14:57:55.82 ID:y0Jh7vt2.net
>>509
RustのGUIも色々揃っている
GUIは用途によって多種多様な世界だからeguiのようなリフレッシュフレームベースのGUIクレートもある

そういう用途でなければRust関係なく一般的な話として今は各プログラミング言語でGUI作るのは極少数派になっている
つまりHTML/CSS/JavaScriptベースで作られるようになっていて使用言語を強いて言えばJS/TSの時代

512 :デフォルトの名無しさん:2023/11/19(日) 15:15:35.10 ID:xroD2KWj.net
>>500
ならせめて「当てはまるわけではない」ケースを指摘しないと反論にならん。
「不適切な使用をしてる例を自分自身で示しているが、それに気づいていない」というのに指摘しないのは反論者として誠実でない。後出しじゃんけんを狙った詐欺師にしか見えん。

513 :デフォルトの名無しさん:2023/11/19(日) 15:17:38.47 ID:BvvFFAMC.net
フィクションでもマウス的な小道具を無くそうとしてる
だから剣と魔法しかない

514 :デフォルトの名無しさん:2023/11/19(日) 15:21:36.07 ID:5CKxkiE7.net
>HTML/CSS/JavaScriptベースで作られるようになっていて使用言語を強いて言えばJS/TSの時代
そしてそれらは全て実装継承モリモリの実装に支えられている

515 :デフォルトの名無しさん:2023/11/19(日) 15:24:12.29 ID:xroD2KWj.net
>>500
「その指摘のような状況で使わなければいいだけ」とか後出しジャンケンにもなっていないな。情報が空っぽすぎる。
無敵ジャンケン出して勝った気になるお子様みたい。

516 :デフォルトの名無しさん:2023/11/19(日) 16:13:36.90 ID:NqOCouPw.net
>>514
Reactはクラス止めて関数型のやり方に変えて
かなり経つよ

517 :デフォルトの名無しさん:2023/11/19(日) 16:43:45.43 ID:HSZIalWb.net
あったはずだけど

518 :デフォルトの名無しさん:2023/11/19(日) 16:45:02.12 ID:HSZIalWb.net
あ、めっちゃ遅れレスだけど>>509に対して書いたつもりだった

519 :デフォルトの名無しさん:2023/11/19(日) 17:14:49.95 ID:H8V03qQo.net
>>514
Reactは本体含めて継承は使っていない
全て関数

520 :デフォルトの名無しさん:2023/11/19(日) 17:17:51.68 ID:H8V03qQo.net
まあ今後のGUIはWebView2になるのは間違いなさそう
特にwindowsはこれが決定版になるはず

521 :デフォルトの名無しさん:2023/11/19(日) 17:39:17.01 ID:nljhlBVQ.net
>>512
ただ親クラスを継承して親クラスのメソッドを使うだけでしょ?
そんなことはどこにでもあるが、そのすべてがインターフェイス的に全てのメンバの実装が必須なケースになるのか?
ならない
なるケースはインターフェイスなど使えばいいだけ

522 :デフォルトの名無しさん:2023/11/19(日) 17:55:10.88 ID:o+X6buyf.net
メンバ変数に直接アクセスするメリットはgetやsetを実装する時間を浪費しないことだが
継承のメリットはこれに類似している

523 :デフォルトの名無しさん:2023/11/19(日) 18:40:03.88 ID:RRmaBkyu.net
>>516,519
意味のない指摘をありがとう
ReactはHTML/CSS/JavaScriptを支える技術じゃなく
HTML/CSS/JavaScriptを活用した技術

ちなみにReactの本体では今でも実装継承使ってる
つまらない嘘はいい加減止めようね

524 :デフォルトの名無しさん:2023/11/19(日) 18:50:12.97 ID:WxxDsdGH.net
>>523
支える技術とか活用した技術とか意味不明すぎる

525 :デフォルトの名無しさん:2023/11/19(日) 19:34:44.92 ID:nljhlBVQ.net
>>524
何で知ったかしてバレないと思うん?

526 :デフォルトの名無しさん:2023/11/19(日) 20:05:00.46 ID:aXcE9XXk.net
マイコンレベルに小さなコンパイラを搭載しなければいけないような案件だとRustは重たすぎて無理っぽいが
それ以外のデメリットは無い感じはする。今のところ
FPGAの論理合成のような長いコンパイルプロセスに未来を感じる(感想)

527 :デフォルトの名無しさん:2023/11/19(日) 20:46:51.67 ID:H8V03qQo.net
>>523
頭が悪すぎて嫌になるな

528 :デフォルトの名無しさん:2023/11/19(日) 20:52:10.42 ID:H8V03qQo.net
>>524
なんか日本語がおかしい
韓国人なんかな?

529 :デフォルトの名無しさん:2023/11/19(日) 21:13:25.27 ID:o+X6buyf.net
英語圏で同じこと言われる不安を煽ってるから英語が苦手になるパターン

530 :デフォルトの名無しさん:2023/11/19(日) 22:14:28.15 ID:fSaG2PoW.net
昔のReactはコンポーネントクラスというJavaScriptのクラスを用いた方法を用いていたけど
それでも継承は使わないでコンポジションを使うようにと公式に書かれていた
今のReactはクラスではなく関数コンポーネントを用いるようになった

531 :デフォルトの名無しさん:2023/11/19(日) 22:31:23.82 ID:2h4NT+3n.net
継承はクラスの再利用とクラスの切り替えが同じ継承に集約
されていたのが問題だった

532 :デフォルトの名無しさん:2023/11/19(日) 23:15:24.31 ID:WkLuwjlK.net
>>531
コードの再利用とサブタイピングが一緒になっていたらなぜ問題なの?

533 :デフォルトの名無しさん:2023/11/20(月) 00:02:51.71 ID:miVVMWsb.net
>>523
継承使ってるというのはどこのコード?

534 :デフォルトの名無しさん:2023/11/20(月) 03:25:10.93 ID:m3TC6/PX.net
クラスの切り替えとはキャストのことか
だがダックタイピング界隈には「キャストする」という振る舞いがない
templateなら引数を変えることが切り替えでありキャストは重要ではない
重要ではないものを重要と思ってたなら問題だ

535 :デフォルトの名無しさん:2023/11/20(月) 03:52:37.02 ID:Uh0cT6mQ.net
だからさ、独自用語で煙に巻いてないでTaPL読んだうえで共通語彙で話しようぜって

536 :デフォルトの名無しさん:2023/11/20(月) 07:37:53.49 ID:kv+dmWMk.net
>>521
親クラスを継承できないクラスはポリモーフィズムできないねぇ。

後から「読み取り専用のIFが欲しい」「書き込み専用が欲しい」となったらどうすんの?

「なるケースはインターフェイスなど使えばいいだけ」なら、途中で継承からIFに切り替える?
「早すぎる最適化」だなぁ

537 :デフォルトの名無しさん:2023/11/20(月) 08:24:47.95 ID:dEVryb2p.net
さすがにその例だと、「モード切替するメソッドを足す。所有権管理もさせる。旧クラスは廃止」とかだろ

538 :デフォルトの名無しさん:2023/11/20(月) 08:49:37.76 ID:Gc8IZzjG.net
>>537
だから「継承は重い。早すぎる最適化」なんだよ。
いつインターフェイスを確定するのは設計を煮詰めないと無理だから、設計初期に確定なんて不可能。

539 :デフォルトの名無しさん:2023/11/20(月) 09:03:13.39 ID:07sj62mg.net
>>499
俺もそう思う

540 :デフォルトの名無しさん:2023/11/20(月) 10:54:06.11 ID:NElbrJwW.net
何で君達は最小のサンプルコードも書かずに俺様用語で議論してるの?
プログラマじゃないのかな?

541 :デフォルトの名無しさん:2023/11/20(月) 11:26:53.92 ID:6jnK0Jj8.net
今朝のGoogleニュースで米の求人報酬だかでRustが2位とか見たわ
人事的にはRustで沼る人材が欲しいらしいぞ
良かったな

542 :デフォルトの名無しさん:2023/11/20(月) 12:00:36.92 ID:ZwEoOGmm.net
>>536
そこら辺は言語によって違うからせめて言語くらい前提として共有しないと議論にならない。

親クラスを継承できないクラス、意味不明。
そもそもサンプルコード見せれば確実なところを自然言語で議論しようとする発想が意味わからない

543 :デフォルトの名無しさん:2023/11/20(月) 12:49:28.44 ID:aVFf8Qq7.net
>>542
さすがに出先スマホでコード打ち込みたくないわな。
コードで言うなら>492みたいなのが欲しいというだけだし。

>親クラスを継承できないクラス、意味不明。

例えばライブラリが返すインスタンスのクラス。普通はクラスを直接弄ることはできないし、final宣言されてたら派生も無理。クラスを直接弄くれるとしても、ライブラリをメンテナンスするとか面倒臭いからやりたくない。
普通はAdoptor作るけど、それなら>492みたいなIF側で自動的にやる機能が欲しい。

544 :デフォルトの名無しさん:2023/11/20(月) 12:49:42.01 ID:JpnTJcOA.net
githubの2023年成長率でもRustが40%増でTOPだったな。
でもまだ人気言語TOP10には食い込んでなかったけど。

545 :デフォルトの名無しさん:2023/11/20(月) 12:53:05.42 ID:PG0EBfXZ.net
>>541
日本だとマジで少ねえんだよな
ガッツリ使ってて将来性があるところならぜひ行きたい

546 :デフォルトの名無しさん:2023/11/20(月) 13:32:31.99 ID:NElbrJwW.net
>>541
1位はpython?

547 :デフォルトの名無しさん:2023/11/20(月) 13:42:54.45 ID:IjnmMF1h.net
そりゃ1位はPHPだよ

548 :デフォルトの名無しさん:2023/11/20(月) 13:54:03.53 ID:SNQO1x/A.net
>>523
早くだせよコラ
適当いってんのはテメェだろクソが

549 :デフォルトの名無しさん:2023/11/20(月) 14:04:35.58 ID:NElbrJwW.net
>>547
PHPを書けるより市場価値がないの?

550 :デフォルトの名無しさん:2023/11/20(月) 14:38:31.00 ID:dEVryb2p.net
Rustが出せるのは高い信頼性だが、日本で何か作っても、それ信頼できんの?ってなるから
だったりして

551 :デフォルトの名無しさん:2023/11/20(月) 14:44:00.93 ID:NElbrJwW.net
>>550
求められている信頼性って「Rustが出せる信頼性」とは違うんだと思うよ

552 :デフォルトの名無しさん:2023/11/20(月) 15:09:31.41 ID:MS7hPbOQ.net
日本だけに限らないかも知れないけど
ソフトウェアの利用者ってそもそも
何の言語で造ってるかなんて気にしてないし知ろうともしない

553 :デフォルトの名無しさん:2023/11/20(月) 15:36:03.59 ID:JXHwx0JF.net
Rustが使われる理由は高速省メモリで開発効率や保守性が良いため

554 :デフォルトの名無しさん:2023/11/20(月) 15:41:32.66 ID:NElbrJwW.net
>>553それはRustプログラマの視点
それまでの話は発注者側からの話

555 :デフォルトの名無しさん:2023/11/20(月) 15:49:44.16 ID:JXHwx0JF.net
発注者側の視点でも
高速省メモリで安全性も高いのはRustとなる

556 :デフォルトの名無しさん:2023/11/20(月) 15:55:24.47 ID:NElbrJwW.net
鶏と卵の関係になるけどプログラマが確保できなく保守性が悪い

557 :デフォルトの名無しさん:2023/11/20(月) 16:02:14.85 ID:N43MAaAU.net
>>555
という願望

いいものなら売れるというナイーブな考えは捨てろ

558 :デフォルトの名無しさん:2023/11/20(月) 16:18:06.96 ID:JXHwx0JF.net
>>556
プログラムの保守性自体はRustが高くて好ましいため
あとはプログラマーの数は単調増加する一方なので特に問題なし

559 :デフォルトの名無しさん:2023/11/20(月) 16:27:04.23 ID:NElbrJwW.net
>>558
プログラマが確保できないってことは
発注者側からすると運用後の保守に
支障を来すリクスがあるってことだよ

560 :デフォルトの名無しさん:2023/11/20(月) 17:04:51.35 ID:aPv5cKlG.net
コントリビューター増加「率」はミスリードかも、レポ増加「数」は
github 2023年新規レポジトリ10KB以上

JavaScript 2.1M results
Java 767k results
Python 749k results
TypeScript 627k results
C# 338k results
C++ 244k results
C 174k results
PHP 152k results
Kotlin 147k results
Dart 109k results
Go 84.4k results
Ruby 64.3k results
Swift 59.3k results
Rust 39.4k results
Lua 22.1k results
HCL 16.4k results

561 :デフォルトの名無しさん:2023/11/20(月) 18:15:53.85 ID:1QHH6HXV.net
クローズ開発案件が含められないから意味が無い件

562 :デフォルトの名無しさん:2023/11/20(月) 18:32:56.66 ID:Tq0YX8uR.net
>>557
株とかはそうだね
いいものは誰にも教えないで買い占めるはず
商品化し売られているのは悪いものしかない説

563 :デフォルトの名無しさん:2023/11/20(月) 20:50:45.51 ID:NElbrJwW.net
>>561
ある程度は相関してるでしょ

564 :デフォルトの名無しさん:2023/11/20(月) 21:15:52.04 ID:ojqzhkRS.net
>>562
お前がレスに使ってる端末は悪いものなんだな~。

565 :デフォルトの名無しさん:2023/11/20(月) 21:47:51.39 ID:Tq0YX8uR.net
>>564
自然言語で雑談ばっかりして
コーディングとコンパイルと実行をしない原因はこの端末かもしれないな

566 :デフォルトの名無しさん:2023/11/20(月) 21:56:32.85 ID:Ygoo/zhh.net
>>533 >>548
嘘つきオジは「知ったかぶりして”Reactは本体含めて継承は使っていない全て関数”などという真っ赤なウソをついてすみませんでした」と言うのが先だろ

567 :デフォルトの名無しさん:2023/11/20(月) 21:59:46.43 ID:1QHH6HXV.net
>>563
全くしてないだろ
公開出来るソフトなんて業界の一部でしか無いからなぁ

568 :デフォルトの名無しさん:2023/11/20(月) 22:02:12.48 ID:SNQO1x/A.net
>>566
負けを認めろ
土下座したら許してやるぞ

569 :デフォルトの名無しさん:2023/11/20(月) 23:27:57.05 ID:/Ubqd6b6.net
>>530
Reactはクラスコンポーネント時代も
開発元のFacebookが様々なケースで継承を使うとよいケースは存在していないことを確認しているとReact公式に書いていたもんな
もちろん今はクラスコンポーネントすら捨てて関数コンポーネント

570 :デフォルトの名無しさん:2023/11/21(火) 08:57:03.65 ID:CeBFd4j1.net
GitHubで最も使われている言語はJavaScript、最も利用者が増加したのはRust。AIプロジェクト数はこの1年で3倍増GitHubが年次調査「Octoverse 2023」発表
https://www.publickey1.jp/blog/23/githubjavascriptrustai13githuboctoverse_2023.html

AI関連のプロジェクトを国別に見ると米国が突出していますが、日本はインドに次いで3位となっており、日本のオープンソース開発者は世界的に見て積極的にAI関連のプロジェクトに関わっていることが分かります。

プログラミング言語別にコントリビュータの増加率を見ると、1位がRust、2位がRua、3位がTypeScript、4位がHCL(HashiCorp Configration Language)、4位がTSQL、5位がPythonとなります。

571 :デフォルトの名無しさん:2023/11/21(火) 09:29:05.70 ID:WJ7yrtvk.net
React本体のJavaScriptコードで継承が使われてるという事実は嘘つきオジがいたので指摘しただけで重要な事ではない
JavaScriptの継承を理解してる人ならリポジトリ見れば誰でもわかる

重要なのはReactやReact Nativeが依存しているHTML/CSS/JavaScriptなどのホスト環境が提供するGUIライブラリやそれに類するものは全て実装継承モリモリで作られているということ

それはなぜなのか?

572 :デフォルトの名無しさん:2023/11/21(火) 09:48:09.93 ID:meOGGGPH.net
>>570
Rustはもう何年もずーっと愛され続けてずーっと増加率もすごく高いのに
誰も使ってないのが不思議w

573 :デフォルトの名無しさん:2023/11/21(火) 10:52:34.98 ID:TIZNoRj+.net
増加<率>だからねw

574 :デフォルトの名無しさん:2023/11/21(火) 10:53:27.83 ID:TIZNoRj+.net
つまり分子が大きいというより分母が少ない

575 :デフォルトの名無しさん:2023/11/21(火) 10:56:46.75 ID:fyFN08Ef.net
ヒント非公開

576 :デフォルトの名無しさん:2023/11/21(火) 11:02:46.10 ID:ZX3v40di.net
>>571
GitHubのコードに対するリンク一行貼るくらいやってよ

577 :デフォルトの名無しさん:2023/11/21(火) 11:06:40.20 ID:ZX3v40di.net
>>571
gtkはCだね

578 :デフォルトの名無しさん:2023/11/21(火) 11:07:36.25 ID:HSO31doi.net
>>557
ほんそれ

579 :デフォルトの名無しさん:2023/11/21(火) 11:18:07.78 ID:Lmp19CDx.net
>>575
エビデンスを出せという言葉を使えば公開されるという認識なんじゃないか
まるで魔法みたいに

580 :デフォルトの名無しさん:2023/11/21(火) 11:27:49.20 ID:j31CN6Yb.net
>>569
とFacebookの犬が申しております

581 :デフォルトの名無しさん:2023/11/21(火) 12:12:04.36 ID:Vub9wpCB.net
>>571
嘘つきはお前だよ

582 :デフォルトの名無しさん:2023/11/21(火) 12:25:12.17 ID:MyNMYruR.net
>>571
お前毎回遅レスなのは何なの?
回線がない生活保護施設にでも住んでるのか?

583 :デフォルトの名無しさん:2023/11/21(火) 12:27:03.76 ID:vP2RupFQ.net
特定のレスに妙に攻撃的な単発ちょくちょく湧いてくるのってやっぱりアイツ?

584 :デフォルトの名無しさん:2023/11/21(火) 12:50:14.72 ID:j31CN6Yb.net
>>583
いや、あいつとは別

585 :デフォルトの名無しさん:2023/11/21(火) 12:50:16.11 ID:j31CN6Yb.net
>>583
いや、あいつとは別

586 :デフォルトの名無しさん:2023/11/21(火) 13:37:07.13 ID:f4244eke.net
アイツじゃねーかw

587 :デフォルトの名無しさん:2023/11/21(火) 13:52:02.24 ID:Lmp19CDx.net
質問する側は基本的に無力で、答える側に生殺与奪の権を握られる
一発逆転するには攻撃力か何かで優位に立たなければ

588 :デフォルトの名無しさん:2023/11/21(火) 18:59:23.42 ID:E3kr56i/.net
勝ったところで、所詮クソvsクソだぞ

面白いことを書け

589 :デフォルトの名無しさん:2023/11/21(火) 19:14:06.76 ID:MyNMYruR.net
攻撃的なこと言われて大人しくなってるの草

590 :デフォルトの名無しさん:2023/11/21(火) 22:22:25.20 ID:3Y9OZVuh.net
>>577
GTKは実装継承モリモリ
Cで実装継承を実現するためのオブジェクト管理システムをGTK用に作ってある
Reactの話とは関係ないけどね

591 :デフォルトの名無しさん:2023/11/21(火) 22:23:49.29 ID:3Y9OZVuh.net
>>582
誰もが君のように暇なわけではないんだよ
つかそんなにレスが欲しかったのかよw

592 :デフォルトの名無しさん:2023/11/21(火) 22:43:10.96 ID:Q9pynku3.net
>>590
そういう返答するだろうなあと思ってたよ
言語機能になくても実装で継承使われてるんだ~
というならどんな言語使っても構わないね
はい終了

593 :デフォルトの名無しさん:2023/11/21(火) 23:11:04.07 ID:Lmp19CDx.net
Cはスマポ<T>を作れない
C++でもtemplateを使わない主義ならばスマポのようなものをTが実装継承するかも

594 :デフォルトの名無しさん:2023/11/21(火) 23:15:06.85 ID:x0TxAGsF.net
>>592
論点は実装継承は不要なのかどうか
常にコンポジションを使うべきかどうか

GTKは言語機能によらない実装継承を使っているというだけ
コンポジションで実装する事も技術的には当然可能だがその選択をしてないことに意味がある

特に言語が提供してないにもかかわらずGTKのためだけに継承機能をわざわざ作り上げるほど実装継承を欲した理由を理解するべき

595 :デフォルトの名無しさん:2023/11/21(火) 23:35:36.54 ID:LOJe+P0r.net
Reactが依存しているHTMLのボタン要素を例に話をするとボタン要素は次のような型階層を取ることがDOM APIの仕様で決められている

EventTarget <- Node <- Element <- HTMLElement <- HTMLButtonElement

上位の型のパブリックなメソッドやプロパティはや下位の型でも使えるようにする必要がある
これは実装継承だけでなくコンポジション+インターフェースでもRustのenumのような代数データ型を使っても実現可能なんだが知る限り全てのブラウザが実装継承を使って実装している

596 :デフォルトの名無しさん:2023/11/21(火) 23:45:35.68 ID:Q9pynku3.net
>>594
言語機能になくても問題はないんだから
言語の機能比較という論点からは
どうでもいい話だね

597 :デフォルトの名無しさん:2023/11/21(火) 23:49:00.55 ID:5SU8rUzf.net
なぜかというと
例えば仕様変更でNodeに新しいメソッドが追加されたとしても実装継承なら一箇所変更すればいいだけだから

コンポジション+インターフェースの場合はNode以下の数百個のクラスや構造体にメソッドを追加して委譲するコードを書いて回らないといけない

実装継承というのはサブタイピングとコードの再利用を同時に行うことだが、その2つを同時に行えるという点が最大のメリットであり存在理由なわけ

598 :デフォルトの名無しさん:2023/11/22(水) 00:08:02.11 ID:h68LLJ0S.net
>>596
問題がないわけではないんだよ
GTKの実装継承は言語機能のそれと比べてクソ面倒臭い上に言語に組み込まれた型システムではないからこその弱さがある

Rustでも実装継承をマクロで模倣することもできるがだからといってそれに何の問題ないわけではないというのと同じ

他のやり方があったとしてもより楽に安全に開発できるようになるなら言語機能としてあった方がいいってことになるよね?

599 :デフォルトの名無しさん:2023/11/22(水) 00:19:05.87 ID:i7dbnQQ2.net
>>1-10

乗り遅れるな!

いつまでも待ってはくれませんよ

https://note.com/nukatiktok/n/nfbb66b3b3d3e ←4000円貰えます

この機会にぜひ

https://i.imgur.com/eWEQ3eT.jpg
(毎日動画見てるだけでお金貰えるんだぞ💰)

600 :デフォルトの名無しさん:2023/11/22(水) 00:33:52.03 ID:SCjy6MJ9.net
>>597
それは仕様変更前のクラス数百個を捨てさせ変更後の数百個で置き換えるには都合が良い
一箇所変更するだけで古いクラス数百個が消滅する
だが古いクラスに依存していた資産が消滅するのは本当にお得なのか?

601 :デフォルトの名無しさん:2023/11/22(水) 01:12:20.99 ID:uxQX1dJD.net
>>590
はよReactの実装継承について参考にすべき
ファイルとかだしてくれ

602 :デフォルトの名無しさん:2023/11/22(水) 01:26:34.89 ID:uxQX1dJD.net
>>598
> 他のやり方があったとしてもより楽に安全に開発できるようになるなら言語機能としてあった方がいいってことになるよね?

c++に色々跳ね返ってきそうなお言葉来たな

603 :デフォルトの名無しさん:2023/11/22(水) 16:32:36.94 ID:Ky8NVDmM.net
「GCは嫌い。だけどC++は苦手。
 噂だとRustがそれを解決するらしいから」
ということでRust票が入っているだけ。

604 :デフォルトの名無しさん:2023/11/22(水) 18:06:32.01 ID:VuMm7++t.net
GoogleもMicrosoftもAmazonもCloudflareも
そんな理由でRustを採用して使っている?

605 :デフォルトの名無しさん:2023/11/22(水) 18:40:30.34 ID:I05HGQ1N.net
結局windows11 10.0.22631.2715 (23H2)にRust製モジュール入らなかったが

606 :デフォルトの名無しさん:2023/11/22(水) 19:20:29.71 ID:zUxnYc1v.net
MSの使ってるコンパイラは何だろう?

607 :デフォルトの名無しさん:2023/11/22(水) 20:23:02.05 ID:BBiTeKwa.net
>>600
>だが古いクラスに依存していた資産が消滅するのは本当にお得なのか?
消滅しないよ

608 :デフォルトの名無しさん:2023/11/22(水) 20:29:20.42 ID:ltxaInSK.net
>>604
信用できないアホコーダーにはバグを入れる自由なんて与えない。
コーティング規約だと防ぎきれないから抜け道の少ないRustにする。

ということだろ。

609 :デフォルトの名無しさん:2023/11/22(水) 21:18:08.59 ID:+UnlqW3r.net
関数名の重複を許す仕組みは信用できる
クラスは名前がかぶったらたいてい古い方が無かったことにされるのが信用できない

610 :デフォルトの名無しさん:2023/11/22(水) 21:25:34.99 ID:zUxnYc1v.net
なにそれ?

611 :デフォルトの名無しさん:2023/11/22(水) 21:26:35.97 ID:5rDf7evN.net
>>603
C++苦手でRustなら大丈夫!って人種は居るのかな
さらに苦労しそうだけど

612 :デフォルトの名無しさん:2023/11/22(水) 21:47:18.27 ID:+UnlqW3r.net
intは信用できないのでi32やi64になったのはまあいい
実装継承の祖先の名前がずらりと並ぶのは嫌だ

613 :デフォルトの名無しさん:2023/11/22(水) 22:42:24.09 ID:+dkhSESN.net
>>612
それは実装継承による設計をする古い頭のままの駄目プログラマーの典型例

614 :デフォルトの名無しさん:2023/11/22(水) 22:48:19.59 ID:F4GGzYS9.net
>>611
いるよワイ
とにかくC++はコピーを正しく扱うのがあまりにも難しいのよ
C++の弱点はこの一点に尽きる
もちろんCとの互換性を保つためなのだが本当に難しい
そこにコピーやめたろ!って英断したRustは本当にC++使いの人が設計したんだなと感じる
この部分に手を入れかつ速度を落とさない実装もできる方法を突き詰めるとこうなる

615 :デフォルトの名無しさん:2023/11/22(水) 22:59:48.09 ID:Lo22StDU.net
>>614
Firefoxはservoで行き詰ったよ

616 :デフォルトの名無しさん:2023/11/22(水) 23:05:36.01 ID:F4GGzYS9.net
Effective C++の初版はほぼこのコピーをいかにうまくやるかを解説した本だった
あらゆる手段でコピーが発生してもオブジェクトの整合性が取れるように注意点を書きまくった
しかしその内容はあまりにも普通の人には難し過ぎた
そして一つのクラスを作るたびにこんなに気をつけて実装しないといけないのか!やってられん!となって
その結果、もう全部ヒープにとって生ポインタでいいじゃんとなってしまった
そのおかげでコピー問題は無くなったが
メモリリークや二重開放、ヌルポの山を産んだ

617 :デフォルトの名無しさん:2023/11/22(水) 23:09:46.91 ID:EF2LJjbV.net
ポインターをメンバーに持つと言うのがコピーの問題になってるだけやん?
アドレスをコピーするのか、実体を複製して新しいポインターとして格納するのか
用途によってはどちらかが不都合だったりするからなぁ

618 :デフォルトの名無しさん:2023/11/22(水) 23:14:04.80 ID:F4GGzYS9.net
>>617
実態を持っても同じだよ
そのオブジェクトが内部にポインタを持ってたら同じ問題が発生
さらにそのオブジェクトが(ry

というわけで地獄のような連鎖になることがわかる
そして厄介なのは自分が作っていないクラスだった場合お手上げということ
いかにやばいか分かっていただけただろうか

だから一時期はあらゆるオブジェクトがヒープ割り当てをしていた

619 :デフォルトの名無しさん:2023/11/22(水) 23:21:57.25 ID:F4GGzYS9.net
スマートポインタによって状況はだいぶ改善されたとは思うが
しかしこのコピー問題というのは常に残っているのだ
そのオブジェクトを安全にコピーできるようにするという本質的な難しさは変わっていない
そしてムーブかコピーかみたいなものをライブラリ提供者が決めなければならず
それを使う側が意識することはかなり難しい
ドキュメントを読み込んで使い方を熟読するしかない
数百個のクラスがあった場合その全てのクラスの性質を暗記しないといけないのである!
しかも一個のミスで全てが崩壊する
こんなことは不可能に近い

620 :デフォルトの名無しさん:2023/11/22(水) 23:27:21.33 ID:F4GGzYS9.net
その結果全てのオブジェクトをヒープにとってそのポインタだけを持ち回る、という実装がほとんどとなったのである
こうすればとりあえずコピーに関する問題はなくなる
俺はその時期にC++を仕事で書いていた
全てのオブジェクトがヒープにあった
コピーに関して悩んだことがなかったので
Effective C++を読んでもこの本は何でこんな「不整合が起きないオブジェクト」の作り方の解説ばっかりやってるんだろうと思っていたぐらいだ

621 :デフォルトの名無しさん:2023/11/22(水) 23:30:42.74 ID:F4GGzYS9.net
ちなみにこの全てのオブジェクトをヒープに取ればいいじゃんの思想をデフォルトにした言語がJavaである
メモリの解放漏れはGCにより問題なくなったがヌルポを量産したのは言うまでもない

622 :デフォルトの名無しさん:2023/11/22(水) 23:32:00.30 ID:UBOPkQxC.net
ChatGPTとまでは言わんが、IDEも仕事しろ、っていう世の中ではある

623 :デフォルトの名無しさん:2023/11/22(水) 23:37:47.47 ID:Rf3A/fx6.net
>>615
金がなくなっただけでスポンサーついたら復活した

624 :デフォルトの名無しさん:2023/11/23(木) 00:06:01.85 ID:KrVwEhLS.net
>>623
稼働してるの2~3人だけど当時よりは整ったはずだから今度は完成するよね?
とりあえず年内にtableタグが実装だっけ?

625 :デフォルトの名無しさん:2023/11/23(木) 00:11:54.90 ID:mLPybMZb.net
Javaにはポインタしかない
ゆえにコンポジションを繰り返せばリンクリストのようになる
でも実装継承なら
という風に二つの問題は一つにつながる

626 :デフォルトの名無しさん:2023/11/23(木) 01:52:03.12 ID:FMewW6Qw.net
>>616
Effective C++がコピーの話ばっかりという印象はないけどな
あるのはもともとCにあるコピー問題をいかにC++で解決するかというスタンスの解説
あとコピー問題を解決するためヒープを使うってのも謎理論
それは因果関係逆でしょ
ポインタをメンバーに持つデータ構造のコピーをいかに安全に実現するかでしょ
STLコンテナによりそこに厳密な意味定義が必要となった

627 :デフォルトの名無しさん:2023/11/23(木) 07:44:46.73 ID:N5SmR8A3.net
>>568
と負け犬が申しております

628 :デフォルトの名無しさん:2023/11/23(木) 09:38:23.37 ID:jt92Atwz.net
>>621
ヌルポは型無しnullpointerによる型の制約に違反する問題だろ。
スタックだろうがヒープだろうが型無しインスタンスを使う限り発生する。

c++もポインタを排除して参照のみにできれば随分違うだろうけど。

629 :デフォルトの名無しさん:2023/11/23(木) 10:31:50.34 ID:mLPybMZb.net
中途半端に浅いコピーは、深い方が正しい可能性を否定できない
これがコピー問題
ヒープを使えば極端に浅いコピーになる
これはバグではなく意図的にしか見えないから問題が解消する

630 :デフォルトの名無しさん:2023/11/23(木) 10:37:31.57 ID:mHKDjsht.net
>>597
そこはRust最低だよな

631 :デフォルトの名無しさん:2023/11/23(木) 10:57:07.78 ID:KmXfNFgK.net
機能追加が常に善なら後発言語は機能お化けに
なる一方のはずだがそうはなってないので
〇〇言語には△△機能が無いからゴミという
論法はあまり意味がない

632 :デフォルトの名無しさん:2023/11/23(木) 12:06:15.18 ID:gaANDpVB.net
>>627
だからお前は何でそんな遅レスなんだよw
遅レスおじさん登場〜👴

633 :デフォルトの名無しさん:2023/11/23(木) 12:33:56.71 ID:cJqQ5Mzl.net
>>631
C++のよろしくない点で一番言われるのは、長い歴史といろんなパラダイムを取り込みまくったことで
まさに機能お化けになっちゃったことだからな

634 :デフォルトの名無しさん:2023/11/23(木) 13:07:39.51 ID:mHKDjsht.net
C++のtemplateは失敗

635 :デフォルトの名無しさん:2023/11/23(木) 13:35:39.34 ID:tND7y2dZ.net
>>631
>機能追加が常に善なら
誰もそんなことは言ってないから
それこそ意味のない論法

636 :デフォルトの名無しさん:2023/11/23(木) 13:53:47.80 ID:KmXfNFgK.net
>>635
誰かがそういう主張しているという文章じゃ
ないんだが
頭悪いな

637 :デフォルトの名無しさん:2023/11/23(木) 14:01:33.34 ID:P5PvPGf5.net
実装継承不要とか言ってたやつら負けるの早すぎだろ
拍子抜けもいいところ

638 :デフォルトの名無しさん:2023/11/23(木) 15:08:18.27 ID:m+MQWJu5.net
いや。参考になったから、それはそれでいいぞ(IUnk派

639 :デフォルトの名無しさん:2023/11/23(木) 16:01:38.36 ID:M3SMKrV5.net
Reactの継承を使っているコードを出せない時点で負け犬はどっちか明確
強い言葉使ってやるからかかってこい

640 :デフォルトの名無しさん:2023/11/23(木) 16:37:00.29 ID:/KrkujPK.net
「Reactは本体含めて継承は一切使っておらず、全て関数だと言い張る人がいるのですが本当でしょうか?」と
自分の主張ではないフリしてStack Overflowあたりで聞いてみ?
めっちゃ馬鹿にされるだろうけどすぐに欲しがってる答えをもらえるぞw

641 :デフォルトの名無しさん:2023/11/23(木) 16:38:05.49 ID:t7xzkVTj.net
ビビってレスもできんかw
情けないクズ

642 :デフォルトの名無しさん:2023/11/23(木) 16:43:11.88 ID:9Fa6B1S9.net
プロトタイプ継承もわかってないのに事あるごとにReact連呼してたのかと思うと滑稽を通り越してちょっと可哀想

643 :デフォルトの名無しさん:2023/11/23(木) 16:52:07.60 ID:t7xzkVTj.net
はよそのコードを出せよ
それも出せないくせに偉そうに御託をごちゃごちゃ言う
偉そうに自分語りするくせに的外れ
虫唾が走る

644 :デフォルトの名無しさん:2023/11/23(木) 17:57:28.21 ID:qpiJFg02.net
継承はプログラミングスタイルとして決定が多いため
モダンな各プログラミング言語で継承が不採用となっただけでなく
Reactでも継承を使わずに済むように進化してきたのよ

645 :デフォルトの名無しさん:2023/11/23(木) 18:04:46.83 ID:t7xzkVTj.net
おーいまた遅レスかー?
快活クラブから出ちゃったのー?

646 :デフォルトの名無しさん:2023/11/23(木) 18:52:56.05 ID:t7xzkVTj.net
>>644
多分そういう意味すらわかってないと思うよ
プロトタイプ継承がどうとかそんな話とカンケーないのにな
とっととReactのリポジトリクローンしてgrepすりゃわかるのに
何でその程度のことができないのか

647 :デフォルトの名無しさん:2023/11/23(木) 19:34:58.02 ID:5s3/w8/I.net
src/foo/bar.jsの124行目見てどう思うプギャー
とやればいいだけなのになぜかやらない

648 :デフォルトの名無しさん:2023/11/23(木) 21:12:25.76 ID:FMewW6Qw.net
>>629
それは理解がおかしい
浅い深いのコピーの分類ではうまくいかなかったのが歴史
それが所有権の概念とムーブセマンティクスの導入で整理されたのが今の状態
浅いと言っていたのがムーブで深いのがコピー
ヒープがどうのこうのってのは間接的なこと
そもそもヒープが単一って前提もc++にはない

649 :デフォルトの名無しさん:2023/11/23(木) 21:20:40.39 ID:FMewW6Qw.net
>>634
まぁ判断は難しいね
下手に表現力が高かったがために、一見言語組み込みでやるべきものの多くがユーザー側で実現されてきた
様々なテクニックが発見され発展速度向上には寄与しただろうが一方で深い考察のなく導入された結果仕様の複雑さを招いた
個人的にはエラーメッセージ見ても何が悪いのかすぐに理解できない代物になったのは許せないね

650 :デフォルトの名無しさん:2023/11/23(木) 21:32:54.70 ID:12+j04nO.net
C++のテンプレートはCのマクロ文化を止めたかったんでしょ
メタプロガチ勢が頑張りすぎてカオスになったけど功績は大きいと思う

651 :デフォルトの名無しさん:2023/11/23(木) 21:58:33.69 ID:hsLNP7GU.net
ディープコピーを知らずに盛大に恥を晒した某オジがコピーについて語るとか世も末だなw

652 :デフォルトの名無しさん:2023/11/23(木) 22:09:33.63 ID:t7xzkVTj.net
テンプレートはコンテナを矛盾なく書くのがめちゃくちゃ難しいのよ
まず要素の型が実体とポインタ両方に対してうまく動くようにするのは至難の業
例のコピー可能オブジェクトの話とも絡んできて「無理」となる
この辺Rustはよくできてる
イテレータが可変参照なのか共有参照なのか、実体なのかによってきちんと分けられている
C++で困った部分を完全に解決してくれてる
Rust素晴らしい

653 :デフォルトの名無しさん:2023/11/23(木) 22:28:06.68 ID:0De2U7us.net
>>652
>テンプレートはコンテナを矛盾なく書くのがめちゃくちゃ難しいのよ
>まず要素の型が実体とポインタ両方に対してうまく動くようにするのは至難の業
STLで何か問題でも?

654 :デフォルトの名無しさん:2023/11/23(木) 23:13:27.00 ID:FMewW6Qw.net
そりゃSTLで満足してる間はそれでいいだろ
アロケーターを指定したことないだろ?

655 :デフォルトの名無しさん:2023/11/23(木) 23:28:00.45 ID:M3SMKrV5.net
むかしはSTLがない環境も多かったからね
windows環境ではクソ遅かったせいか
完全にないものと扱う奴さえいた

656 :デフォルトの名無しさん:2023/11/23(木) 23:30:28.39 ID:0De2U7us.net
>>654,655
じゃ今のSTLは問題ないで良いのかな?

657 :デフォルトの名無しさん:2023/11/23(木) 23:37:07.63 ID:u/H26W0M.net
>>652
そこに加えてRustはスタック領域も扱えるからさらにヒープ使用を減らせるところ

658 :デフォルトの名無しさん:2023/11/23(木) 23:37:56.70 ID:09UkZirn.net
問題ないと問われればあるだろうね
ただよく訓練されたC++使いは気に入らないと文句を垂れても仕方ない事もよく理解してるから
その環境で可能な別の手段を用いるだけだよ

659 :デフォルトの名無しさん:2023/11/23(木) 23:39:53.17 ID:0De2U7us.net
>>658
曖昧なことしか書かんのだな
問題あるならどのような問題かを短いサンプルコードで具体化してよ

660 :デフォルトの名無しさん:2023/11/23(木) 23:48:05.78 ID:09UkZirn.net
どのような問題かなんて別の手段で解決した後に覚えてるわけないじゃん
何でも欲しがりさんには判らないか

661 :デフォルトの名無しさん:2023/11/23(木) 23:58:49.29 ID:0De2U7us.net
>>660
示せないなら問題あるなんて言ってはいかんだろうよ?

662 :デフォルトの名無しさん:2023/11/24(金) 00:21:55.00 ID:oZLKiYTi.net
C++はSTLを一応擁しているけど、各プロジェクトで、もうちょっと軽量で自分とこ向きのコンテナ持ってるとこが多い
異論は認める

663 :デフォルトの名無しさん:2023/11/24(金) 00:29:35.14 ID:qKRvRsRu.net
>>662
でその自作コンテナを矛盾なく書くのがめちゃくちゃ難しいとな?
今のSTLは問題ないで良い?

664 :デフォルトの名無しさん:2023/11/24(金) 00:31:58.77 ID:oZLKiYTi.net
俺はSTLが重厚すぎて自分の手に負えないと思ってるので、なんとも。
STLにもバリエーションがあるのは承知していて、あんまり幅広く試せてないってのも。
ただし、依存(include)してるプロジェクトは当然あるし、試作には便利なので、ないのは困る。

665 :デフォルトの名無しさん:2023/11/24(金) 07:39:29.33 ID:eRQLkcC1.net
>>652
要素の型が実体とポインタ両方に対してうまく動くようにする

それはポインタを部分特殊化しろ、ということでは?

666 :デフォルトの名無しさん:2023/11/24(金) 08:38:00.98 ID:4SGglGUV.net
>>663
同意を求めるなよw
お前の用途ではSTLで十分ってだけ
そうじゃない場合もある
STLで足りるならboostもEASTLも存在してない

667 :デフォルトの名無しさん:2023/11/24(金) 11:26:41.73 ID:qKRvRsRu.net
>>666
>>652
>テンプレートはコンテナを矛盾なく書くのがめちゃくちゃ難しいのよ
>まず要素の型が実体とポインタ両方に対してうまく動くようにするのは至難の業
これがいったい何のことを言っているのか分からんので
STLで問題を指摘させれば共通の題材として議論できるからSLT取り上げた

668 :デフォルトの名無しさん:2023/11/24(金) 11:31:35.71 ID:UKwUTpr8.net
継承を使いこなせない者同士仲良くしろよなw

669 :デフォルトの名無しさん:2023/11/24(金) 14:20:00.82 ID:v63PRHPl.net
嫌儲にまでスレ立てることないだろw

670 :デフォルトの名無しさん:2023/11/24(金) 14:23:40.25 ID:9RAaBgN9.net
全然伸びてなくて草
こんな過疎スレで敗走したからって嫌儲民おらに力を分けてくれーーってやろうとしたけど
そこでも無視されてる
情けない奴だ
だからゴミクズなんだよ

671 :デフォルトの名無しさん:2023/11/24(金) 14:29:03.78 ID:rK2EDUzF.net
Why I think C++ is still a desirable coding platform compared to Rust
https://lucisqr.substack.com/p/why-i-think-c-is-still-a-very-attractive

672 :デフォルトの名無しさん:2023/11/24(金) 14:36:54.58 ID:eHJQmp62.net
>>671
そもそも前半の話いる?w
的外れ過ぎて意味のない指摘だよ

673 :デフォルトの名無しさん:2023/11/24(金) 16:11:19.50 ID:UVQLfV0S.net
>>671
これは酷いw

674 :デフォルトの名無しさん:2023/11/24(金) 16:25:00.95 ID:tvJVQF3W.net
いくらめんどくさくても安全のお守りがほしいんすわ
C++製システムがクラッシュしてうなだれたあの日の鬱憤が安全を求めるんすわ

675 :デフォルトの名無しさん:2023/11/24(金) 16:34:40.23 ID:6OrpRj0R.net
>>671
何故この手のやからって、
自分は今まで大丈夫だったから他の人(今度の新卒社員とか)も大丈夫に違いないと思えるんだろうか。
いつも一人で仕事してるのかな。

676 :デフォルトの名無しさん:2023/11/24(金) 16:45:30.90 ID:Oe/LAESW.net
>>671
その人はRustを知らなすぎるな
C++はインラインアセンブリがある云々もRustにもあるし
算術ラッピング演算の件もRustはラッピングの有無両方が用意されてるのを知らずに書いていたり

677 :デフォルトの名無しさん:2023/11/24(金) 16:52:45.75 ID:KbRqc6TK.net
フルボッコで草

678 :デフォルトの名無しさん:2023/11/24(金) 16:55:26.04 ID:rK2EDUzF.net
めっちゃ感想来てるw

俺は読まずに貼った、おもしろそうだったから
[Roast Me] って付いてたので、異論は認める系の日記かなって思ってた
仕事終わったら俺も読む 気にしないから感想はご自由に

679 :デフォルトの名無しさん:2023/11/24(金) 19:51:30.59 ID:FR/8T+5m.net
>>674
わかる。他人の書いたC++ライブラリがめっちゃメモリリークする時とかそう思うわ

680 :デフォルトの名無しさん:2023/11/24(金) 19:53:16.58 ID:Pf2BWo+V.net
元記事に英語でコメント付けに行くことはしい内弁慶たちであった

681 :デフォルトの名無しさん:2023/11/24(金) 20:53:52.01 ID:HwIqF0Eo.net
>>652
要約: バカには無理

682 :デフォルトの名無しさん:2023/11/24(金) 22:58:47.93 ID:cJ52o0CU.net
使うなと言ってもバカはクラス継承をどうしても使いたがって質を下げるため
モダンなプログラミング言語は一斉にクラスごと言語から排除した

683 :デフォルトの名無しさん:2023/11/24(金) 23:09:27.03 ID:UpLQZeUm.net
そうそうバカはclassやextendを無くせば実装継承が無くなったと勘違いするからバカに気づかれないようにカモフラージュして実装してバカが無節操に使わないようにしてるんだよなぁ

684 :デフォルトの名無しさん:2023/11/24(金) 23:40:23.66 ID:qKRvRsRu.net
そうしてマイナー言語マニアの思い出の一つとして
長く記憶に留まる言語となるであろう

685 :デフォルトの名無しさん:2023/11/25(土) 00:57:31.51 ID:xDUppX6s.net
>>683
実装継承の定義教えてくれ

686 :デフォルトの名無しさん:2023/11/25(土) 09:02:19.65 ID:rKTwm3uz.net
>他人の書いたC++ライブラリがめっちゃメモリリークする

某OSのAPIのことですね判ります

687 :デフォルトの名無しさん:2023/11/25(土) 09:47:04.81 ID:9BsUE7B+.net
>>685
サブタイピング時に
上位の型が持つ実装コードの一部が
下位の型と共有されること

688 :デフォルトの名無しさん:2023/11/25(土) 21:29:31.59 ID:1Ohowu9E.net
嘘オジと複オジは撃沈されたようだな

689 :デフォルトの名無しさん:2023/11/26(日) 15:19:59.23 ID:06WEnIxy.net
OSにバグがあって後処理をしてもOSがリソースを掴みっぱなしになるといった経験はないだろうか。
そういった場合そのリソースを使う箇所だけ子プロセスとして隔離し、使い終わったらそのプロセスを終了する事でリソースを完全に開放させることが可能だ。
このプロセスの隔離はかなり万能な解決方法で、納期が短くて怪しいと思っても修正が困難なケースにも応用可能だ。
まあ要するにリークを疑われる場合一旦別プロセスにすれば必ず開放されるからリークは必ずしも怖くないよって話。

690 :デフォルトの名無しさん:2023/11/26(日) 15:30:13.25 ID:qv9H5y0z.net
と、御社の現お取引先ホームページにありますね。
弊社はRust採用実績十分、リークは原則としてありません

691 :デフォルトの名無しさん:2023/11/26(日) 16:02:44.80 ID:GTIMQwMH.net
>>687
いい定義だな

692 :デフォルトの名無しさん:2023/11/26(日) 16:21:23.35 ID:8OjiBh4l.net
Rustはモダンな言語の一つなので
その定義でもRustは実装継承を持たずきちんと排除している

693 :デフォルトの名無しさん:2023/11/26(日) 18:06:50.18 ID:6qvbnksS.net
結局、c++が最狂ってことでいいな?

694 :デフォルトの名無しさん:2023/11/26(日) 18:08:00.70 ID:Dq1p+inG.net
>>618
c++が最凶最悪

695 :デフォルトの名無しさん:2023/11/26(日) 18:37:35.88 ID:4YJKEDWv.net
>>689
OSのバグならアプリのプロセスを落としたところでリソースが解放されるとは限らない
プロセス落とすのはどちらかと言うとアプリのバグに対処するため

696 :デフォルトの名無しさん:2023/11/26(日) 18:49:55.09 ID:o8qwwCxG.net
>一旦別プロセスにすれば必ず開放される

doubt

697 :デフォルトの名無しさん:2023/11/26(日) 19:14:33.38 ID:6NRjjzPt.net
すくなくともWindowsは長期間起動し続けると空きメモリが減っていく
OSが意図的に開放せずにキャッシュしてるのかリークなのかは分からないが

698 :デフォルトの名無しさん:2023/11/26(日) 19:39:37.59 ID:AfiVlC9p.net
>>689
それ本当にOSのバグ?w

699 :デフォルトの名無しさん:2023/11/26(日) 19:41:06.05 ID:Lbe7PiAw.net
>>689
子プロレス切り離しが大仕事だろ
そこで別のバグが大量に入り込む
全然簡単な話じゃない
お前言うだけでやったことないだろ

700 :デフォルトの名無しさん:2023/11/26(日) 19:44:09.20 ID:EBR4w0d/.net
>>689
きっしょ

701 :デフォルトの名無しさん:2023/11/26(日) 22:37:51.44 ID:06WEnIxy.net
俺が遭遇したのは2件で、どちらもOSの不具合という結論だよ
MSのナレッジに残ってるかもしれないがどっちもプロセスを終了するしか解決策が示されなかった
>>699
こういう理不尽に遭遇して回避策が示されたなら大仕事でもやらざるを得ないと思うけどね
別に難しいって程でもないし

702 :デフォルトの名無しさん:2023/11/26(日) 22:48:32.77 ID:06WEnIxy.net
そういや別件でOSが設定しているタイムアウト値を待てない場合も別プロセスにして回避した事がある
この板って年寄りばかりだろうしWindowsのプログラミング長年やってれば何度かそういう事に遭遇するんじゃないの

703 :デフォルトの名無しさん:2023/11/26(日) 23:01:37.86 ID:iMOX0Yuj.net
あのね、年寄りが真面目に答えてやるとOSの観点から言うと
windowsとLinuxじゃプロセスの考え方が結構違ってて
Linuxの場合、バックグラウンドプロセスっていうのは普通に使われまくってるの
いわゆるプロセスのクローンだから扱いが楽
シェルから作れるし

一方windowsではexeなんでクソ重い上に扱いが面倒
データ共有やプロセス間通信も一苦労だ
だからwindowsではLinuxっぽいバックグラウンド処理はスレッドを使う
windowsにおいてスレッドの方が軽い

一方Linuxではスレッドもプロセスも本質的に同じ
(カーネルの構造体thread_structはプロセス生成の時も使う)

よってプログラミングモデルがだいぶ違うため
どうすべきか?はかなり違う

以上がwindowsでもLinuxでも並行処理を書いてきた俺の感想

704 :デフォルトの名無しさん:2023/11/26(日) 23:12:09.99 ID:dlQxZ4PC.net
Windowsはプロセスもスレッドも、互換性チェックみたいのが重厚らしく超高コスト
さらに、セキュリティソフトが走ってるのが当たり前の世界なので、ファイルハンドルも高コスト
なんでもWSL2でやったほうが軽い? らしい

てことで、コルーチンはいいぞw

705 :デフォルトの名無しさん:2023/11/26(日) 23:30:18.11 ID:EFSUb3PR.net
Rustの東京を使えばデフォルトでCPUのコアスレッド数をフル活用してコルーチンを何万も同時に動かせますものね

706 :デフォルトの名無しさん:2023/11/27(月) 00:37:45.36 ID:ggQuSpTQ.net
Elixir は、10万もの小プロセスを起動できる

Go の並行処理も、mattn の本に書いてあるけど、
C で、100スレッドを起動したら、
CPU 使用率が高く、12秒も掛かったが、

Goで100 goroutine を起動したら、
6スレッドしか起動せず、9秒で済んだ

Goの方が、CPUコアを効率的に使える

707 :706:2023/11/27(月) 00:48:36.74 ID:ggQuSpTQ.net
とにかく、スレッドを起動したらダメ!

CPU コアや時間の大半が、起動処理に使われるから

708 :デフォルトの名無しさん:2023/11/27(月) 00:59:58.17 ID:zZXu+dmb.net
とはいえコルーチンって使い所が難しいのよ
流行りそうで流行らないのがその理由
結局「本当の並列性が必要ないようなすぐ終わる処理を大量にする」ユースケースにしか使えないから

こういう処理ってあまりないことに気がつく
まず真の並列性が必要となる数値計算では使えない
処理の中でブロックするとダメなのでその判断も難しい

よって普通の言語では使うのが難しい

709 :デフォルトの名無しさん:2023/11/27(月) 01:36:12.87 ID:O2rw1r7K.net
>>706
使いたければc/c++にはむっかしからコルーチンにファイバーがあるから
native言語なんだからosの資源使う上で不利になるはずない

710 :デフォルトの名無しさん:2023/11/27(月) 01:38:37.07 ID:AHLzaHDv.net
>>706
>Goの方が、CPUコアを効率的に使える

そう主張したかったら根拠を示さないとね
例えば逆の根拠として
Go各のgoroutineは別々の各々のスタック領域を必要とするけど
Rustはスタックレスなコルーチンだから必要とせずその分だけ効率的だね

711 :デフォルトの名無しさん:2023/11/27(月) 01:45:48.38 ID:zZXu+dmb.net
>>707
普通はスレッドプール使うやろ

712 :デフォルトの名無しさん:2023/11/27(月) 06:31:05.54 ID:klBkI3Ol.net
おれの作成したソフトは起動時に64個のスレッドを立ち上げているが常にサクサクだ

713 :デフォルトの名無しさん:2023/11/27(月) 07:50:36.80 ID:h6EdzCL7.net
>>712
言語は何?

714 :デフォルトの名無しさん:2023/11/27(月) 07:54:36.67 ID:klBkI3Ol.net
cppは光速

715 :デフォルトの名無しさん:2023/11/27(月) 09:19:45.20 ID:7/k6/GSg.net
>>701
それどころかプロセスを完全に終了させても解放されないリソースが残ることがある
OSを再起動してやっと治る
こんなもんOSのバグとしか言いようがない

716 :デフォルトの名無しさん:2023/11/27(月) 09:21:22.84 ID:7/k6/GSg.net
>>702
あるね
>>699 こそやったこと無い香具師だと感じる

717 :デフォルトの名無しさん:2023/11/27(月) 09:24:14.02 ID:7/k6/GSg.net
>>703
Windowsにforkがあれば良かったと思うことは何度かある

718 :デフォルトの名無しさん:2023/11/27(月) 09:26:12.71 ID:7/k6/GSg.net
ああでも
>>703
>一方windowsではexeなんでクソ重い上に扱いが面倒
>データ共有やプロセス間通信も一苦労だ
>だからwindowsではLinuxっぽいバックグラウンド処理はスレッドを使う

ここは完全に間違ってるよ

719 :デフォルトの名無しさん:2023/11/27(月) 09:30:39.99 ID:7/k6/GSg.net
>>706
>C で、100スレッドを起動したら、
>CPU 使用率が高く、12秒も掛かったが、
>
>Goで100 goroutine を起動したら、
>6スレッドしか起動せず、9秒で済んだ

可笑しな理屈だな
スレッド数で比較するならgoでも100スレッド使って比較するか
Cの方でスレッド数増やさないCで描いたコルーチンで比較するべきだろ

720 :デフォルトの名無しさん:2023/11/27(月) 10:19:10.91 ID:bfNyVWtl.net
プロセスを分けて独立したメモリ空間の単位で障害を切り離して耐障害性を高めるのは昔からよく使われる方法だけどこれはスレッドやコルーチンでは代用できない

並行性を高める目的ならコルーチン+スレッドプールが最も効率が良い
C++やRustはまだまだ使いにくいけどGoやC#やSwiftのように使いやすいAPIが用意されれば誰もが当たり前のように使うようになる

721 :デフォルトの名無しさん:2023/11/27(月) 13:17:02.15 ID:y1vsdTcE.net
>>717
ある程度時間がかかる処理を並行で動かすという面でこれほど楽で使いやすいものはないしね
windowsへの移植性を上げるためにはforkを捨てなきゃならんのはかなり厳しい

722 :デフォルトの名無しさん:2023/11/27(月) 13:22:19.90 ID:y1vsdTcE.net
windowsくんェ
https://draftcode.github.io/2011/12/29/145918.html

723 :デフォルトの名無しさん:2023/11/27(月) 13:27:11.60 ID:UqO8a829.net
fork移植されてると思うけどそういう話ではなく?

724 :デフォルトの名無しさん:2023/11/27(月) 13:40:29.77 ID:y1vsdTcE.net
>>723
pythonじゃ使えないぞ

725 :デフォルトの名無しさん:2023/11/27(月) 14:04:14.09 ID:l+s92lQ4.net
遅くともcygwinとかで、なんちゃってforkは実装されてるけど、コレジャナイ感は付きまとうんだよな(個人の感想です

726 :デフォルトの名無しさん:2023/11/27(月) 14:10:54.29 ID:O2rw1r7K.net
execなしのforkなんて時代錯誤もいいところ
いまだに使ってるやついんのか?
さっさと引退するのが世のために

727 :デフォルトの名無しさん:2023/11/27(月) 14:17:35.21 ID:zZXu+dmb.net
RubyもNotImplementedError
Perlはエミュレーションしてるがすでに非推奨レベル

728 :デフォルトの名無しさん:2023/11/27(月) 14:21:41.56 ID:+D1aTXqp.net
こんどはforkを取り囲んでフェルマータするターンか

729 :デフォルトの名無しさん:2023/11/27(月) 15:12:24.83 ID:qB4qrVrI.net
forkは同じページを(書き換えるまで)共有できるのが売りだと思うけどwin版は最初からコピーするのか
そんな実装でfork爆弾作れるの?

730 :デフォルトの名無しさん:2023/11/27(月) 15:12:35.28 ID:l+s92lQ4.net
ま、雑談だからな おもしろければどうでもおっけー

731 :デフォルトの名無しさん:2023/11/27(月) 15:37:56.10 ID:+D1aTXqp.net
オジジジジジw

https://medaka.5ch.net/test/read.cgi/prog/1619943288/667
667: 仕様書無しさん 2023/11/24(金) 01:57:39.09
>>665
C++のスマポは機能が弱すぎてできないことが多すぎる
例えばヒープ領域しか指せないから
(L1キャッシュ効果と領域確保解放コスト無しで高速な)スタック領域の活用がスマポではできない

732 :デフォルトの名無しさん:2023/11/27(月) 15:50:29.33 ID:UqO8a829.net
スタック領域をスマートポインタで指す必要はあるの?

733 :デフォルトの名無しさん:2023/11/27(月) 15:57:04.75 ID:l+s92lQ4.net
先々で、うっかりfreeするような書き方してしまったときにコンパイルエラーで止まってほしい
実体としては生ポだけど、チェック用の何かにラップされてる…そういうスマポ

734 :デフォルトの名無しさん:2023/11/27(月) 17:16:07.46 ID:FscsMJtl.net
いつものように誰かが書いてた受け売りで中身は理解してないんだろ
少し突っ込まれたら表面的なことを繰り返す壊れたレコードになる

735 :デフォルトの名無しさん:2023/11/27(月) 17:19:29.35 ID:ZLucLoet.net
www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf

736 :デフォルトの名無しさん:2023/11/27(月) 19:00:17.85 ID:UqO8a829.net
>>733
実装すれば良いのでは?

737 :デフォルトの名無しさん:2023/11/27(月) 19:12:23.49 ID:MloD+hDC.net
>>731
スタック領域は勝手に解放されますが

738 :デフォルトの名無しさん:2023/11/27(月) 19:23:48.42 ID:VTBvXWTh.net
Rustはヒープ領域だけでなくスタック領域にまで所有権やムーブや参照の概念を拡張したことから
C++よりスタック領域の活用で効率的になってる話ではないか

739 :デフォルトの名無しさん:2023/11/27(月) 19:41:50.12 ID:4LX/kS4x.net
>>738
コードで示してよ
C++の

740 :デフォルトの名無しさん:2023/11/27(月) 19:55:41.13 ID:XLFtaca7.net
>>738
単に「何でもスタックに積む」というだけでは?
ヒープはVec Box使わないと確保できないんじゃなかったっけ。

741 :デフォルトの名無しさん:2023/11/27(月) 19:57:13.46 ID:ceTrdy2T.net
C++は書くのがしんどい
Rustもしんどいけど、生成AIに書かせたコードもコンパイルとテスト通ればメモリリークの心配なく使えるので気持ちは楽

742 :デフォルトの名無しさん:2023/11/28(火) 03:07:58.34 ID:iuwbNdCf.net
Boxってヒープのメモリどうやって管理してんの?スコープ?

743 :デフォルトの名無しさん:2023/11/28(火) 06:19:45.83 ID:fb4KLmhh.net
>>734
ほんそれ
同じ香具師なんだろうバレバレ

744 :デフォルトの名無しさん:2023/11/28(火) 07:21:41.08 ID:p7m/jx+j.net
>>742
unique ptrみたいな感じじゃない?

745 :デフォルトの名無しさん:2023/11/28(火) 07:38:03.63 ID:OE19BKGq.net
>>736
自分なりには考えてみてるんだけどね

ベーシックな車輪くらい、削り出せなきゃいけない
ダサいので試してるってのは他言はしないけどね ここくらいだ

746 :デフォルトの名無しさん:2023/11/28(火) 08:32:49.65 ID:t7+ip2Xg.net
>>738
また嘘言ってる
Rustはヒープ領域だけでなくスタック領域にまで所有権やムーブや参照の概念を拡張したことから
C++よりスタック領域の活用で非効率的になってる

>>741
お前は死んだ方が良い

747 :デフォルトの名無しさん:2023/11/28(火) 08:34:53.09 ID:4GFkN+H+.net
スタック使うってカーネルで使えるん?

748 :デフォルトの名無しさん:2023/11/28(火) 09:04:02.54 ID:uB2ZO1/C.net
Rustの所有権チェックって、(コンパイル時にコストを寄せてるから)実行時はゼロコストじゃないん

へたくそに書いたら効率が下がる(たいてい実装効率が上がった犠牲)のは、C/C++も同じ

749 :デフォルトの名無しさん:2023/11/28(火) 10:10:56.04 ID:pC50QOa+.net
技術的選択というのは最終的には必ずトレードオフになるので
ある選択のプラス面だけしか見ない/考えない/認識できないやつは何やらせてもダメ

750 :デフォルトの名無しさん:2023/11/28(火) 12:14:38.37 ID:0HFLSmnD.net
新人やお前らの前任の調子いいだけの奴がコンパイル通したコードで、rustとc++のどっちが安心できるかってことよ。

751 :デフォルトの名無しさん:2023/11/28(火) 12:37:00.84 ID:zgX3htu8.net
c++に自動変数専用参照とかあるといいんだけどなぁ。
自動変数にあるスマートポインタは参照渡ししたい。

752 :デフォルトの名無しさん:2023/11/28(火) 14:34:16.09 ID:5v5wYsOr.net
今更だけどNonNullクソ便利だな

753 :デフォルトの名無しさん:2023/11/28(火) 14:49:32.02 ID:tbacT9e+.net
>>751
イマイチ分からんのだがコードで書ける?

754 :デフォルトの名無しさん:2023/11/28(火) 15:14:43.92 ID:zjrE05Ar.net
>>632
と暇人が申しております

755 :デフォルトの名無しさん:2023/11/28(火) 15:30:47.32 ID:PhTWlmVC.net
>>753
void foo(shared_ptr<T>&&& p)
でshared_ptr&&&が自動変数専用参照だとすると、

void main() {
shared_ptr<T> ptr;
foo(ptr); //スタックにあると合法
shared_ptr<shared_ptr<T>> pptr;
foo(*pptr); //ヒープにあるとエラー
shared_ptr<T>&&& pp = ptr;
foo(*pptr); //次のスタックフレームに渡すのも合法
}

756 :デフォルトの名無しさん:2023/11/28(火) 15:32:05.10 ID:PhTWlmVC.net
>>755
あ、最後は
foo(pptr);
だわ。

757 :デフォルトの名無しさん:2023/11/28(火) 20:15:20.15 ID:QlCOA+Xa.net
メモリがスタックにあるかヒープにあるかはリンカのアドレスマップと連携すればわかる
つまり欲しいなら自作すればいいのでは

758 :デフォルトの名無しさん:2023/11/28(火) 21:08:43.42 ID:zgX3htu8.net
>>757
え?リンクでこねこにすればshared_ptrのカウンタを増減させなくて済むようになるんかね?

そういう最適化しているリンカとかあるの?

759 :デフォルトの名無しさん:2023/11/28(火) 21:40:34.18 ID:2tolr/zk.net
さっぱり意味が分からんのだけど
もしかしてshared_ptr&&&なる存在に参照されたshared_ptr<T>だけはスタック上にTを保持する何者かに化けろと要求している??

760 :デフォルトの名無しさん:2023/11/28(火) 21:52:40.46 ID:5v5wYsOr.net
何がやりたいのかさっぱりわからん

761 :デフォルトの名無しさん:2023/11/28(火) 23:17:43.17 ID:Y2Vu8rdK.net
クラスは必ずnewしないといけないと思いこんでいた昔のワイみたいな勘違いしてそう

762 :デフォルトの名無しさん:2023/11/28(火) 23:30:04.45 ID:p7m/jx+j.net
>>759
全然違う。
shared_ptr&&&なる存在には自動変数にあるshared_ptrだけしか代入できなくて、左辺値とかヒープにあるインスタンスを代入しようとするとコンパイル時にエラーになるだけだよ。

>>760
呼び出し元の方にあるスタックフレームに保存されている自動変数は、スタックフレームのLIFOを破壊しない限り存在を保証できる。そういう自動変数を呼び出し先から安全に参照したいだけだよ。

763 :デフォルトの名無しさん:2023/11/28(火) 23:38:15.09 ID:2tolr/zk.net
>>762
自動変数にあるshared_ptrは左辺値だが

764 :デフォルトの名無しさん:2023/11/28(火) 23:41:06.97 ID:2tolr/zk.net
そもそも参照に対して行えるのは代入ではなく初期化だし

765 :デフォルトの名無しさん:2023/11/28(火) 23:43:48.38 ID:QlCOA+Xa.net
無知ばっかりでここまで話が通じないと思わなんだ
スタックやヒープの開始アドレスがどこから始まるとか気にしたことないの?
rustの悪いとこ透けて見えたわ

766 :デフォルトの名無しさん:2023/11/28(火) 23:55:41.04 ID:xnaKz8pj.net
Rustならそんな複雑なことする必要もなく
Rustの方が優れている
ライフタイムさえ満たせば参照先がヒープかスタックか関係なく同一コードでその参照を安全に返す関数などを書くことができる

767 :デフォルトの名無しさん:2023/11/29(水) 00:18:45.75 ID:UMPQWy8o.net
言い訳ばかり達者で見苦しいスレだこと

768 :デフォルトの名無しさん:2023/11/29(水) 01:18:06.77 ID:w45cg+MW.net
>>765
>>751
>>755 と話繋がってないけど。
スタックやヒープの始まりは >>755 のコードでも >>751 の要件でもわからんやん。

769 :デフォルトの名無しさん:2023/11/29(水) 02:07:48.15 ID:0GsI2ATG.net
どっかで身に覚えがある流れだなと思った
たぶん要件定義の時点でなんかおかしいよ
https://mevius.5ch.net/test/read.cgi/tech/1542002113/504-523

770 :デフォルトの名無しさん:2023/11/29(水) 03:16:09.69 ID:0jw/VZcC.net
いまいちメリットがわからない
ヒープのオブジェクトなら渡す前に呼び出し側でチェックすべきなのではないのか

771 :デフォルトの名無しさん:2023/11/29(水) 03:26:29.12 ID:nEUPDdEn.net
バカ強制矯正共生強請言語Rust

772 :デフォルトの名無しさん:2023/11/29(水) 03:32:20.62 ID:I6OxsG4L.net
>>757
どのOSも汎用的に判別できる方法はない
(組み込みは除く)

773 :デフォルトの名無しさん:2023/11/29(水) 06:13:09.34 ID:n75oaT1g.net
Rust推してる香具師はスタックとヒープの違いも判ってないのか

774 :デフォルトの名無しさん:2023/11/29(水) 06:15:55.34 ID:n75oaT1g.net
>>768 ←これはひどい

775 :デフォルトの名無しさん:2023/11/29(水) 07:33:14.16 ID:Oshr4ESo.net
関数の定義で、shared ptr の参照を安全に受け付ける仮引数の定義方法とかあるの?
効率化のためにインスタンスのコピーは無しの方向で。

776 :デフォルトの名無しさん:2023/11/29(水) 08:59:38.65 ID:w45cg+MW.net
>>773
スタックの頭知りたかったらコマンドライン引数のアドレス取れば?ヒープの頭知りたかったら最初にsbrk(0)すれば?

777 :デフォルトの名無しさん:2023/11/29(水) 09:22:10.12 ID:cEfAMy5j.net
>>765
それでコンパイル時にエラーにできるのかい?

778 :デフォルトの名無しさん:2023/11/29(水) 09:24:24.67 ID:cEfAMy5j.net
>>775
「安全に受け付ける」の定義は?
特に何をもって「安全」と言ってるのか

779 :デフォルトの名無しさん:2023/11/29(水) 09:29:15.22 ID:w45cg+MW.net
>>776
これだと実行時だわ、コンパイル時にはわからんわスマン。
ってか何でコンパイル時にスタックやヒープの先頭アドレス知りたいのかわからん。
リンクしないでなんてわかりようも無いし。

780 :デフォルトの名無しさん:2023/11/29(水) 10:51:01.40 ID:I6OxsG4L.net
rustはヒープとスタックを言語的に区別してライフタイムをトラックしてるだろ
それが欲しいならrust使えで終わり
c++では汎用的には無理
そういう要望は昔からある

781 :デフォルトの名無しさん:2023/11/29(水) 11:14:58.09 ID:wOoUvEHR.net
>>778
そりゃ、関数を実行している間は参照先が無効にならないことですな。

782 :デフォルトの名無しさん:2023/11/29(水) 11:26:21.99 ID:JCtBk62y.net
そもそもスタックに参照カウンタ必要か?
関数に対するスタックはプロセスに対するグローバル領域とライフタイムの考え方は同じ。
関数を抜けるまではスタックは有効だし、その関数以降に呼んだ関数が呼出元の関数を抜けた後も握り続ける状況は発生しえない
(別スレッドに共有したりヒープにCopy/Moveしない限りは)からshared_ptrにする必要がないと思うが。
つまり、

T x; // スタック
shared_ptr<T> x; // ヒープ

で型が異なるから、強引にCopy/Moveしなけりゃコンパイルエラーで検出できるし問題は起きない。

783 :デフォルトの名無しさん:2023/11/29(水) 11:39:18.60 ID:I6OxsG4L.net
>>755 はいまいちよくわからんが、ポインタを受け取る関数側でスタックかヒープを判別したいんだろ
かつてそれを解決するため手法としてregion based memory managementが開発された
rustのライフタイム管理の源流

784 :デフォルトの名無しさん:2023/11/29(水) 11:46:11.39 ID:wioHB1Dg.net
>>773
Rustでsafeにヒープが使われるのはBoxとVecおよびそれらが組み込まれた型のみなのでヒープかスタックか明確に区別がつく

>>780
参照になった時点でヒープかスタックかの区別なくライフタイムのみで安全に扱えるところがRustの勝因かな
スタック領域を指す参照についても関数から返してよい参照と返してはいけない参照の区別がライフタイムでなされる

785 :デフォルトの名無しさん:2023/11/29(水) 12:57:35.03 ID:/iUfnYRG.net
例が微妙だな。直しておくか。

void foo(shared_ptr<T>&&& p)
でshared_ptr&&&が自動変数専用参照だとすると、

shared_ptr<T> bar()

void main() {
shared_ptr<T> ptr;
foo(ptr); //自動変数だと合法
foo(bar()); //自動変数でないとエラー
}

void foo(shared_ptr<T>&&& p) {
baz(p); //次のスタックフレームに渡すのも合法
}

786 :デフォルトの名無しさん:2023/11/29(水) 13:05:45.44 ID:I6OxsG4L.net
>>785
shared_ptr<T>を使うから意味が不明なんだよ
Tが置かれる場所がスタックかヒープかなんだろ?

787 :デフォルトの名無しさん:2023/11/29(水) 13:32:40.14 ID:SVBOdyHv.net
void foo(T& p){}
void foo(shared_ptr<T>& p){static_assert}

788 :デフォルトの名無しさん:2023/11/29(水) 13:33:08.54 ID:pBsavzeJ.net
>>768
なんやこれ
頭がおかしくなりそう

789 :デフォルトの名無しさん:2023/11/29(水) 13:37:19.41 ID:qKmTtpoR.net
>>773
スタックとヒープの違いが分かってなくても使えるなんて、なんて素晴らしい言語なんだ

790 :デフォルトの名無しさん:2023/11/29(水) 13:52:43.41 ID:pBsavzeJ.net
もういいよ
議論するレベルになってない
引っ掻き回したいだけだろ
この話題終わり
ゴミだから

791 :デフォルトの名無しさん:2023/11/29(水) 14:48:01.22 ID:wOoUvEHR.net
>>786
違う。
「shared ptr」の置かれている場所がスタックかヒープか。この場合だとTはヒープ。
>>785はとりあえず「shared ptrが」自動変数にある場合だけエラーにならないのを想定。

792 :デフォルトの名無しさん:2023/11/29(水) 15:04:52.17 ID:0jw/VZcC.net
はい終わり終わり

793 :デフォルトの名無しさん:2023/11/29(水) 15:22:50.48 ID:I6OxsG4L.net
>>791
shared_ptrの参照カウントの操作を省きたいならshared_ptrの参照渡すか生ポインタ渡せばいいだろ
それかrustにしろ

794 :デフォルトの名無しさん:2023/11/29(水) 15:29:56.33 ID:0GsI2ATG.net
「lvalueよりさらに限定された値カテゴリを作って、それだけを指せる参照を導入したい」という欲求

もしかして: ライフタイム

795 :デフォルトの名無しさん:2023/11/29(水) 15:56:42.98 ID:8C/SUjDF.net
ヒープを排除したいのは参照してる間にfree/deleteされるのを気にしてるからかな
Rustだとライフタイムというよりborrow checkで解決してる問題

796 :デフォルトの名無しさん:2023/11/29(水) 16:40:54.30 ID:wioHB1Dg.net
>>795
そこでborrow checkerが具体的にしていることがライフタイムの妥当性(やミュータビリティの妥当性など)

797 :デフォルトの名無しさん:2023/11/29(水) 18:22:15.98 ID:g4z1paMZ.net
>>781
ポイントしてる先がどうなってるかは関係なくてshared_ptr自体がスタック上で生きていれば「shared_ptrへの参照」は無効にならないということを「安全」だと言ってるという理解でいい?

798 :デフォルトの名無しさん:2023/11/29(水) 20:22:08.97 ID:/iUfnYRG.net
>795 >797
そういう話。
RustだとRc<T>の参照をbollow checkerで(たしか)安全に管理できたけど、c++はshared ptr の参照なんて気にもしないで破棄するから、せめて自動変数に置くことを強制しできればちょっとだけ安全に効率化できるのにな、ぐらいの話。

799 :デフォルトの名無しさん:2023/11/29(水) 20:54:47.61 ID:8C/SUjDF.net
RustのRcもC++のshared_ptrも参照でやり取りするより
Rc本体をclone(C++なら値渡しでコピー)した方が使いやすいと思う

中身じゃなく本体を参照渡しするなら参照カウンタ増えないしRc(shared_ptr)使う意味がなさそう
shared_ptrは元データが破棄されてもコピーが生き残ることに意味があるわけで
この例でshared_ptrを使われると話がややこしくなる

800 :デフォルトの名無しさん:2023/11/29(水) 22:26:34.34 ID:gjeaJk+d.net
>>798
なるほどそういうことならAST的なものに対してカスタムルールを定義できる静的解析ツールみたいなもので頑張ればチェックはできそう

ただポイント先が途中で変化しても安全と言えるかどうか微妙
Arc/Rcはownerが複数いる場合はポイント先が変更されないことも保証されてる

801 :デフォルトの名無しさん:2023/11/30(木) 12:27:38.75 ID:MXha9GzH.net
ライフタイムチェックが今のRustと同じレベルになるのは早くてもC++32以降なので過度に期待せず気長にお待ち下さい。

802 :デフォルトの名無しさん:2023/11/30(木) 13:55:26.66 ID:7CM8sx7O.net
>>791
その理屈だと
>>784 も頓珍漢なこと言ってる

803 :デフォルトの名無しさん:2023/11/30(木) 13:57:58.44 ID:7CM8sx7O.net
要するに
>>782
で話は終わってる

804 :デフォルトの名無しさん:2023/11/30(木) 14:51:08.28 ID:JOtYuMwa.net
的はずれなことを書いてる自覚がないとはな
複オジ(>>784)のほうが多少自覚してるだけマシかもしれんぞ

805 :デフォルトの名無しさん:2023/11/30(木) 15:21:08.01 ID:D7FKv4Y4.net
>>800
自作でやるならかなり大変で、自作言語作るのと工数変わらないかも。
それならRust使ったほうが楽かね。

806 :デフォルトの名無しさん:2023/11/30(木) 16:35:34.05 ID:5k4SwxyG.net
いや服おじは論外

807 :デフォルトの名無しさん:2023/12/01(金) 20:56:33.56 ID:2VykkaiV.net
>>801
サポートするとC++ではなくなってしまう
別言語を同居させたようになり混乱が増す

808 :デフォルトの名無しさん:2023/12/02(土) 00:20:14.03 ID:qhhzthLD.net
C++はもうテンプレートで道を一度踏み外してる外道だから今更だよ

809 :デフォルトの名無しさん:2023/12/02(土) 21:13:09.29 ID:Lt6EdYBh.net
Javaからプログラム始めたからC++の静的ポリモーフィズムやるconceptの制約がわかりにくすぎて使いこなせん
C++20のconceptを使いこなせてる猛者さん、果たしてスレにおるのかね

810 :デフォルトの名無しさん:2023/12/02(土) 21:29:52.21 ID:ojltmATj.net
C++で継承をやろうとするのが間違いなんだよね😇
テンプレートはゴミ!
ゴミなんです!

811 :デフォルトの名無しさん:2023/12/02(土) 22:01:16.75 ID:PDmr7t8h.net
C++使ってるけど継承もテンプレートも使ってないな

812 :デフォルトの名無しさん:2023/12/03(日) 11:30:00.35 ID:QTewqrs7.net





813 :デフォルトの名無しさん:2023/12/03(日) 13:55:04.97 ID:vkjAQods.net
最近新プロジェクトでC++書かなきゃいけなくてRust使いたがったが
外部システムやライブラリとの絡みで仕方なくC++を使うことになったのだけど

std::shared_ptr
std::weak_ptr
std::move
ムーブ代入演算子
ムーブコンストラクタ
enum class
constexpr(主に設定値のテーブル初期化などに使う)

新しい要素だとマジでこれだけしか使ってなかったよ
継承なしテンプレートなし
外部ライブラリとしてonetbbとminimalloc使ってるだけ
これだけでもそこそこモダンなプログラミングができる
あと足りないのはライフタイムだけかな
C++にそれがきたらRustはいらないけど果たしていつになるのか

814 :デフォルトの名無しさん:2023/12/03(日) 14:26:32.44 ID:KItL/kTG.net
shared_ptr使ったならテンプレートなしは言いすぎかな
自作テンプレートなしってところか
テンプレートはライブラリとか裏方向けの要素だからアプリ開発ではあまり使わないかも

815 :デフォルトの名無しさん:2023/12/03(日) 14:31:19.88 ID:Xy0LqFPl.net
は?

816 :デフォルトの名無しさん:2023/12/03(日) 16:51:09.16 ID:455UU+Ox.net
>>813
STLって何の略だか知ってる?

817 :デフォルトの名無しさん:2023/12/03(日) 17:00:48.99 ID:qGjodFlK.net
>>815
は?

818 :デフォルトの名無しさん:2023/12/03(日) 17:02:40.23 ID:POEAPkcj.net
自作テンプレートって意味だろ
文脈理解できないんだな
全部書かなきゃ理解できないタイプ?

819 :デフォルトの名無しさん:2023/12/03(日) 17:43:27.43 ID:wvh0Q/xj.net
>>818
はww

820 :デフォルトの名無しさん:2023/12/03(日) 17:57:09.24 ID:st4Oydl2.net
このスレはワッチョイ必要だねえ
次スレの1の本文先頭に以下を追加しといてね
!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
(新スレ立ての際上記コマンドを2行書き込んでください)

821 :デフォルトの名無しさん:2023/12/03(日) 18:05:13.75 ID:7+5J7jul.net
>>818
はww

822 :デフォルトの名無しさん:2023/12/03(日) 19:07:22.56 ID:hEqJHVGR.net
わかる 裏方向けっていうか、裏方モードのときだね
アプリ開発してる最中に、ややこしいクラスライブラリを内製してる…ばっかりでもない

823 :デフォルトの名無しさん:2023/12/03(日) 19:10:50.45 ID:hEqJHVGR.net
人殴ったりはしないけど、アホなこと書いたりはしちゃうんだよねえ(無知を晒す自爆型)
1日経ったらチャラになってくれたほうが気は楽

824 :デフォルトの名無しさん:2023/12/03(日) 19:13:42.60 ID:Y6w6S9dN.net
次スレ自体いらんが

825 :デフォルトの名無しさん:2023/12/03(日) 19:55:23.02 ID:hEqJHVGR.net
絶対必要なモノなんてない 俺すら不要物

826 :デフォルトの名無しさん:2023/12/03(日) 20:29:50.68 ID:2KUtTHRr.net
俺スラ?
は?
www

827 :デフォルトの名無しさん:2023/12/03(日) 20:33:01.48 ID:PuZI2f4X.net
>>819
効いてる効いてるw

828 :デフォルトの名無しさん:2023/12/03(日) 21:02:12.27 ID:o7sDI4zZ.net
じゃあベアメタルではヒープとスタックはどうなるの?

829 :デフォルトの名無しさん:2023/12/03(日) 22:33:53.82 ID:K2dbitVB.net
まだいたのかベアメタル

830 :デフォルトの名無しさん:2023/12/03(日) 22:41:05.20 ID:hEqJHVGR.net
マイコンいろいろ買ってみたけど、結局デスクトップばかりいじってる俺、なんとも言えずw

831 :デフォルトの名無しさん:2023/12/03(日) 22:55:35.48 ID:idvLkFW9.net
RVOにより呼び出し元でスタック領域を確保できつつ
Rustのようにスタック領域に対しても自動的にライフタイム管理ができていれば
コストの高いヒープ領域利用を可能な限り減らしつつ
スタック領域を指す参照(ポインタ)を返したり他へ埋め込んだりしていても安全に使える
というシンプルな話

832 :デフォルトの名無しさん:2023/12/03(日) 23:01:41.36 ID:hT/LokGW.net
C++もRustもベアメタルという土俵で真価を問われると思うよ
小型軽量ガジェットでAIを高速に処理出る言語に需要があると思ってる。

833 :デフォルトの名無しさん:2023/12/03(日) 23:04:45.84 ID:8f6BMxsw.net
ねーわw
ガジェットww

834 :デフォルトの名無しさん:2023/12/03(日) 23:06:04.65 ID:JMjzgwiz.net
ガジェットじゃなくて組み込みデバイスと言え

835 :デフォルトの名無しさん:2023/12/03(日) 23:16:00.90 ID:KItL/kTG.net
Rust使ってるとヒープ領域はスタック上のどこかの変数の運命共同体って感覚になるから
ヒープだからコストが高いって言われると何か違和感がある
Box(ヒープ配置)にするかしないかでたまに迷うけど

【スタック領域】
・サイズが固定
・確保、解放のオーバーヘッドがない
・スタック上で頻繁にコピーされるからでかいと不利

【ヒープ領域】
・サイズが自由
・確保、解放のオーバーヘッドがある
・基本的に移動しないからでかいときに有利

みたいなイメージで使い分けてる
スタック/ヒープだから安全/危険とかは特にないな

836 :デフォルトの名無しさん:2023/12/03(日) 23:16:28.96 ID:hT/LokGW.net
明日仕事がいやでストレスためてそうやなw

837 :デフォルトの名無しさん:2023/12/03(日) 23:38:17.10 ID:4Lj+S9P7.net
>>835
>>・スタック上で頻繁にコピーされるからでかいと不利

意図的に移動しない限りコピーはされない
ヒープと同じで基本的に移動の必要はない
唯一コピーが起きそうに見える関数返しによる初期化はRVOによりコピーされない
ヒープと同じで確保後はそこへの参照のみ扱うため移動コピーは起きない

838 :デフォルトの名無しさん:2023/12/04(月) 00:12:41.83 ID:ista3uD6.net
Result型とかOk(T)とErr(E)のTとEが同じ場所に置かれそうだけどRVO機能するのかな
真面目に調べたことないけどあまり当てにしてない
最適化で適用されたらラッキーくらいの感覚

839 :デフォルトの名無しさん:2023/12/04(月) 01:36:48.81 ID:DD5cHxD/.net
>>835
スタックは常にキャッシュにのってる

840 :デフォルトの名無しさん:2023/12/04(月) 02:21:32.80 ID:7y9dHiQE.net
まあRustはこのまま死ぬんだからどうでもよくね?

841 :デフォルトの名無しさん:2023/12/04(月) 03:52:22.51 ID:ukOfFF9P.net
>>840
おまえのレスよりは重要だろ?

842 :デフォルトの名無しさん:2023/12/04(月) 04:29:02.89 ID:IuiYb6LZ.net
>>840
お前自身がどうでもいい

843 :デフォルトの名無しさん:2023/12/04(月) 05:55:52.64 ID:9MFLJqwq.net
>>833-834
ハンドヘルドとはいえ、64bitレジスタ当然、メモリもギガバイト当然、ってそんなの組み込みっていうんかw

// てなことだと思う

844 :デフォルトの名無しさん:2023/12/04(月) 10:07:12.79 ID:vGycO/bS.net
>>835
NGワードかもしれんが
stackのメリットは基本的にGCのこと気にしなくて良くなる感覚

845 :デフォルトの名無しさん:2023/12/04(月) 11:26:40.76 ID:t4TeK/vS.net
たまにバカでかいオブジェクトをスタックに置くやつが現れるが
スタックは一度伸びたらするスレッド死ぬまで開放されないからメモリ無駄遣いになる
組み込みやコンソールゲーム作ってるとこだとスタックに置けるオブジェクトのサイズの制限決めてるとこあると思うけどチェックがムズいよな
昔仕事でライブラリ開発したときは最大スタック消費量が仕様で決まってた
バグフィクスでもその上限超えてはならない

846 :デフォルトの名無しさん:2023/12/04(月) 12:05:08.64 ID:EKSqu5ND.net
>>813
そりゃ、テンプレートとかは基本ライブラリアン向けの機能で、コーダーから複雑性を隠蔽ながら高度な機能を使わせるためのものだからな。

コーダーが自作テンプレートを使わなくてはならない状況になったら、何か設計が間違っていないか注意する必要がある。
まぁc++だとそういう状況もあるから辛いけど。

847 :デフォルトの名無しさん:2023/12/04(月) 12:20:54.27 ID:EwsyjZMT.net
>>837
>意図的に移動しない限りコピーはされない
これは微妙すぎる
「意図的」も「移動」も恣意的過ぎるから後出し無敵じゃんけんにしかならない
コピーされないこともあるがコピーされる可能性を前提として最初から考えておくべき

848 :デフォルトの名無しさん:2023/12/04(月) 12:32:02.91 ID:5v4NXSIj.net
Rustのmonomorphization使った静的ポリモーフィズムと同じようなことしたければC++はテンプレート必須だから
ハイレベルのコードしか書かないアプリケーションプログラマーでも普通に使う必要があるでしょ

849 :デフォルトの名無しさん:2023/12/04(月) 13:13:30.82 ID:TyudsW/I.net
>>845
そういやスタックは一度伸びたら伸びっぱなしだったな
これ傍から見たらメモリリークにも見えるし
何でもスタックはあかんのじゃないか

850 :デフォルトの名無しさん:2023/12/04(月) 13:29:26.93 ID:+6ZMbPCa.net
誰からも指摘されずにどんどん明後日の方向に向かって行っているのは見てる分には面白い

どうか第2の毛の壁と化しませんように
南無阿弥陀仏

851 :デフォルトの名無しさん:2023/12/04(月) 13:38:09.73 ID:EKSqu5ND.net
>>849
スタックの取扱いを調整すればよろし。

コールスタックとデータスタックを分けてデータスタックをメモリブロックにするとか、大きいのはマネージドヒープに置くようにするとか。
だんだんヒープに近くなるからスタックのメリットは無くなるけど。

852 :デフォルトの名無しさん:2023/12/04(月) 19:31:46.91 ID:Vux7QnQs.net
コードをよりコンパクトな短文にしようと追求したらテンプレートを使うようになるのはごく当たり前だよ

853 :デフォルトの名無しさん:2023/12/04(月) 19:42:38.90 ID:BRBvRtzF.net
>>835
モダンなC++もそれだぞ

class Hoge {
private:
std::shared_ptr<HogeInternal> hoge;
};

Hogeは常にスタックに割り当てる
実際のオブジェクトはHogeInternalで実装する
こうしておけばめちゃくちゃ安全になる

854 :デフォルトの名無しさん:2023/12/04(月) 19:56:42.31 ID:S3L8tG/0.net
なんで馬鹿はshared_ptr使いたがるんだろう
生ポでいいだろ

855 :デフォルトの名無しさん:2023/12/04(月) 20:13:20.11 ID:ista3uD6.net
3/5/0則を知らないもっと馬鹿なやつがdelete用のデストラクタだけ実装して
事故が多発したからでは

856 :デフォルトの名無しさん:2023/12/04(月) 20:18:13.44 ID:61k0lpUm.net
>>853
それはHogeInternalがヒープ領域に置かれてしまいスタック領域の利用ではない
さらに参照カウントのオーバーヘッドもある

857 :デフォルトの名無しさん:2023/12/04(月) 20:23:01.45 ID:lyR6TlPF.net
C++、雰囲気で書いたらすぐに壊れるくせに文法がどんどん増えていくのついていけねえわ
どんだけの勉強コストを一つの言語に払わせる気だよ
C++に人生捧げて他のこと何も出来ない無能だけが扱える言語となりつつある

858 :デフォルトの名無しさん:2023/12/04(月) 20:27:01.58 ID:648vwdUw.net
3/5/0則みたいな言語の欠陥に疑問を持たなくなったらもう終わり

859 :デフォルトの名無しさん:2023/12/04(月) 20:31:26.59 ID:KZyfgQnR.net
>>856
いだから置くんだよ
伝わってないみたいだから説明するとHogeに直接実装しないってことを言ってる
間接参照を一段挟むのよ
こうすることでコピーしまくっても問題ないヒープに確保されたオブジェクトができる
多少オーバーヘッドは生まれるがめちゃくちゃ安全性は上がるんよ

860 :デフォルトの名無しさん:2023/12/04(月) 20:32:20.03 ID:oiJ5wZfJ.net
そそ、難解な概念使いこなせるのはすごいけど、会社でマウントとれるだけ
世の中が求めてるのはそこじゃない。

861 :デフォルトの名無しさん:2023/12/04(月) 20:59:36.17 ID:H6ggqIOp.net
>>859
Rustを使えばヒープではなくスタック領域に確保してそこへの参照をオーバーヘッドなしで安全に使えるよ
その点がRustとC++の差

862 :デフォルトの名無しさん:2023/12/04(月) 21:10:50.41 ID:61k0lpUm.net
>>859
ヒープを使うというオーバーヘッドに加えて
参照カウントを使うというオーバーヘッドまで加わる
もちろん各々が不可欠な場合や両方が不可欠な場合もあるがその前提や吟味をせずに
まともなプログラマーがとる選択肢ではない

863 :デフォルトの名無しさん:2023/12/04(月) 21:14:53.25 ID:KZyfgQnR.net
>>862
嫌だから共有が必要な場合って書いてあるだろ
日本語読める?
共有じゃないならstd::unique_ptrでもいいよ

864 :デフォルトの名無しさん:2023/12/04(月) 21:15:11.88 ID:KZyfgQnR.net
Hogeに実装しないことでコピー時のオーバーヘッドを防ぐ
さらに個別にコピーのことを考える必要性がなくなる
HogeInternalのコピーコストだけで済むため高速
shared_ptrは安全にコピー可能
データは共有できメモリ管理も自動で行われる
ヒープにとらなきゃいけなくて共有する可能性があるオブジェクトはこのパターンで実装してください
マジで何も考えなくていいから

865 :デフォルトの名無しさん:2023/12/04(月) 21:18:26.98 ID:KZyfgQnR.net
>>861
C++で極力Rustっぽく書くにはどうすべきかを突き詰めたらこうなった
褒めてくれ

866 :デフォルトの名無しさん:2023/12/04(月) 21:25:29.71 ID:H6ggqIOp.net
>>863
Rustなら参照の共有はヒープを使わずスタックに置いてあるものに対しても安全に可能です
もちろん参照カウンタは必要ありません
ちなみにRustでC++のshared_ptrに相当するRc/Arcを必要とするのはもっと限定された状況で所有の共有が必要となる時のみです

867 :デフォルトの名無しさん:2023/12/04(月) 21:32:42.16 ID:KZyfgQnR.net
新たな間接参照でラップすることであたかも普通の変数を作るかのようにヒープに値を置ける
このパターンめちゃくちゃ有用なんだがなぜあらゆる本で紹介されてないんだ?

868 :デフォルトの名無しさん:2023/12/04(月) 21:35:03.72 ID:KZyfgQnR.net
コロンブスの卵だわ
誰もが思いつきそうで思いつかなかった

869 :デフォルトの名無しさん:2023/12/04(月) 21:39:30.12 ID:KZyfgQnR.net
>>866
まあその辺はさすがRust

870 :デフォルトの名無しさん:2023/12/04(月) 21:41:03.87 ID:ista3uD6.net
本気でRustに寄せるならunique_ptrの方がいいな
コンパイラが助けてくれないから死にそうだけど
とりあえず循環参照だけは気を付けてくれ

>>867
目的はちょっと違うけどPimplってイディオムがある

871 :デフォルトの名無しさん:2023/12/04(月) 21:54:58.33 ID:85Eugi9n.net
継承じゃ無くて、包含して各メソッドをバトン渡しすれば良くね?

872 :デフォルトの名無しさん:2023/12/04(月) 22:45:48.75 ID:t1H4jiv7.net
>>867
他のやつも書いてるけどpimplな
20年前から知られている
ひたすらdelegate関数を書くのがだるい
使う側がshared_ptrで包むというルールのほうが楽

873 :デフォルトの名無しさん:2023/12/04(月) 23:15:56.57 ID:o6jCQk0t.net
>>872
>ひたすらdelegate関数を書くのがだるい
書かねば良いのでは?

874 :デフォルトの名無しさん:2023/12/04(月) 23:53:40.38 ID:xybHpH7g.net
>>867
間接参照でいいならわざわざクラスでラップしなくてもshared_ptrそのものでいいように思うんだが
shared_ptr<HogeInternal>で扱うより
ラップしたHogeで扱ったほうがいいメリットって何?

875 :デフォルトの名無しさん:2023/12/05(火) 00:09:25.25 ID:NEqb8LdH.net
mallocでメモリ確保するの気持ちイィ🥴

876 :デフォルトの名無しさん:2023/12/05(火) 00:55:04.31 ID:gtr9NjJz.net
>>872
20年前にこの概念が存在していたのか
当時はauto_ptrとかオレオレメモリ管理モジュールだったとは思うけど

877 :デフォルトの名無しさん:2023/12/05(火) 00:58:42.15 ID:gtr9NjJz.net
>>872
ライブラリとして定期したい場合はshared_ptrで常に包むルールを強制するのも難しいとかかな

878 :デフォルトの名無しさん:2023/12/05(火) 04:45:21.81 ID:55rynLOP.net
delegate指定子欲しいよな。
クラスor変数でまとめて指定できればなお良し。

879 :デフォルトの名無しさん:2023/12/05(火) 05:43:53.62 ID:DR8rm2oC.net
それってRustのDeref?

880 :デフォルトの名無しさん:2023/12/05(火) 08:01:23.94 ID:HiCWBikd.net
std::byteを使ってみた結果
危険な計算ができるのがC/C++を使う理由という結論になった

881 :デフォルトの名無しさん:2023/12/05(火) 08:50:09.72 ID:iiJ5Z2H1.net
一人で何役やってるの?

882 :デフォルトの名無しさん:2023/12/05(火) 09:49:41.30 ID:Akhn3hwz.net
>>881
数えてみろよ

883 :デフォルトの名無しさん:2023/12/05(火) 10:22:23.63 ID:0dgzhl7w.net
>>877
Factoryメソッド経由でしかインスタンス化できないようにするとかして常にshared_ptrやunique_ptrで返すようにすればいいのでは?

884 :デフォルトの名無しさん:2023/12/05(火) 10:50:40.33 ID:cS2yZHjP.net
>>879
delegateに欲しいのはあくまでAdaptorの実装を簡単にする機能。

参照外しとかして型を変えるのはNG。

885 :デフォルトの名無しさん:2023/12/05(火) 11:56:35.63 ID:pNurA5HJ.net
Rustのdelegate!のようなことがC++ではまだ出来ないということか
汚いマクロ書けばできそうだけど綺麗に書くにはReflection待ちなのかな

886 :デフォルトの名無しさん:2023/12/05(火) 13:26:22.00 ID:iiJ5Z2H1.net
>>882
こういうキチガイ対策にワッチョイ必要かもな

887 :デフォルトの名無しさん:2023/12/05(火) 13:34:36.87 ID:gtr9NjJz.net
>>882
きっしょw

888 :デフォルトの名無しさん:2023/12/05(火) 14:18:15.60 ID:DR8rm2oC.net
>>884
スマートポインタなのだから
Derefにより自動的に参照できれば十分だろ

889 :デフォルトの名無しさん:2023/12/05(火) 14:23:46.88 ID:4UYj/sQ8.net
ワッチョイ立てたってところで結局また次世代言語スレと同じ流れになってRustスレに帰ってくるんだろ

890 :デフォルトの名無しさん:2023/12/05(火) 14:24:46.44 ID:4UYj/sQ8.net
×立てたってところで
○立てたところで

891 :デフォルトの名無しさん:2023/12/05(火) 14:31:18.82 ID:1iJo44eg.net
Adaptorにだけ執拗にこだわるオジもアレだか
Adaptorも知らずにDerefを勧めるオジは論外

892 :デフォルトの名無しさん:2023/12/05(火) 14:58:30.60 ID:gtr9NjJz.net
>>883
ユーザーに返す型では流石に気持ち悪いと思うなあ
C++難し過ぎるだろ
選択肢が多過ぎる
かといって安全でもない
もうRust使わせてくれ

893 :デフォルトの名無しさん:2023/12/05(火) 15:21:39.57 ID:MywljXTh.net
>>892
別の理由でfactory使うときはどのみちshard_ptrかunique_ptrにせざるを得ない
(生ポインタはありえない)
だからそこを気持ち悪いと言っても仕方ない

894 :デフォルトの名無しさん:2023/12/05(火) 15:51:48.29 ID:Nvodex4n.net
>>892
Rustでもそこは同じだと思うよ
ライブラリからBoxやArcが返されるものもあればそれらをラップした型が返されるものもある
シンプルなケースなら前者の方が圧倒的に使いやすい
内包する型のネストが深い場合などで便利メソッドを提供するなら後者ってイメージ
要はラップするだけの付加価値があるかどうか

895 :デフォルトの名無しさん:2023/12/05(火) 15:52:25.13 ID:QJai9ytv.net
>>854
馬鹿は平気で二重に解放したりする
全然気にしないから馬鹿なんだけどね

896 :デフォルトの名無しさん:2023/12/05(火) 16:00:15.02 ID:8v2tQb+c.net
>>854
いやいやいやいやw

897 :デフォルトの名無しさん:2023/12/05(火) 16:26:52.90 ID:sq6EbAl6.net
リファレンスカウンタ方式のGCを基本にするんならGC言語でいいんじゃねってならない?

898 :デフォルトの名無しさん:2023/12/05(火) 16:45:36.42 ID:iiJ5Z2H1.net
>>889
えー

899 :デフォルトの名無しさん:2023/12/05(火) 16:47:29.78 ID:MywljXTh.net
ならない
リアルタイム系アプリでGCは困る

900 :デフォルトの名無しさん:2023/12/05(火) 17:17:38.64 ID:CoP1YuvK.net
循環参照で発生するリークを検出するか放置するか
あるいは循環参照を回避するか
それが問題だ

901 :デフォルトの名無しさん:2023/12/05(火) 17:29:27.24 ID:W0r7TCUZ.net
>>899
マークスウィープの話をしてないぞ
リファレンスカウンタ方式のGCすら使えないというならshared_ptrも同様に使えないということになる

902 :デフォルトの名無しさん:2023/12/05(火) 17:59:20.81 ID:ugZXhcp8.net
手動メモリ管理のできないGC言語は高コストをかけて循環参照を回収せざるをえない
手動メモリ管理のできるC++/Rustは循環参照を避けることができて低コスト

その話とは別にshared_ptrやRc/Arcは参照カウンタによるコストがかかる
そのため複数所有者を使わざるを得ない場合に限定して用いる

903 :デフォルトの名無しさん:2023/12/05(火) 18:13:07.15 ID:Ppu4uIXE.net
>>902
Weak Reference等を使って循環参照を手動で避ける方法が用意されてるかどうかは手動メモリ管理かどうかとは全く関係ないよ

904 :デフォルトの名無しさん:2023/12/05(火) 18:43:14.63 ID:gtr9NjJz.net
>>894
気持ち的にはラップしたいかなあ

905 :デフォルトの名無しさん:2023/12/05(火) 19:04:48.69 ID:gtr9NjJz.net
全銀システム障害「詳細設計書見落とし」でオーバーフローの痛恨、再発防止なるか
https://xtech.nikkei.com/atcl/nxt/column/18/00001/08680/

Rustを使えばいいじゃない

906 :デフォルトの名無しさん:2023/12/05(火) 19:13:25.15 ID:gquaqYbt.net
IBMだったらJavaだったのに

907 :デフォルトの名無しさん:2023/12/05(火) 19:18:25.05 ID:800y2Su3.net
積極的にC++を使いたがる人ってC++のどこに魅力を感じているんだ

908 :デフォルトの名無しさん:2023/12/05(火) 19:24:31.25 ID:GrTJwyK/.net
Cとの互換性

909 :デフォルトの名無しさん:2023/12/05(火) 19:32:43.32 ID:4rw/VL0P.net
>>897
問題はGC言語は *常に* GC機能ありなところ。

910 :デフォルトの名無しさん:2023/12/05(火) 19:40:36.09 ID:iiJ5Z2H1.net
>>907
オブジェクト指向w

911 :デフォルトの名無しさん:2023/12/05(火) 20:04:51.38 ID:3vhS3QGH.net
リファレンスカウンター気にするくらい速度を求めるなら、RAIIすら嫌だとはならんのかな
mallocはプログラムの最初に一回呼ぶ以外は許されない

912 :デフォルトの名無しさん:2023/12/05(火) 20:31:30.51 ID:GM9Glwep.net
>>907
組み込み系でオブジェクトやりたい人
あと意図的に悪意あるコードを仕込む人とか。

913 :デフォルトの名無しさん:2023/12/05(火) 21:15:38.20 ID:HiCWBikd.net
やりたいことが出来るのが一番の理由
アンリミテッドが魅力

914 :デフォルトの名無しさん:2023/12/05(火) 21:36:14.43 ID:9fH1d+k3.net
参照カウントて結構コストあったよな……と探したら解説見つけた。
yamasa.hatenablog.jp/entry/2021/01/29/012525

昔は並列処理と相性悪いと言われていたけど、今はどうかね?

915 :デフォルトの名無しさん:2023/12/05(火) 21:36:19.50 ID:ckmQfDX3.net
++C Unsafety Unlimited C++

916 :デフォルトの名無しさん:2023/12/05(火) 21:43:08.45 ID:tZxAn7Rl.net
>>909
GC言語でもunsafeで手動管理とかできるよ
Rustと同じで基本がsafeだからC++をsafeにしていくよりもずっと簡単で問題が起きにくいアプローチ

917 :デフォルトの名無しさん:2023/12/05(火) 21:59:57.96 ID:puqODfvy.net
>>902
>そのため複数所有者を使わざるを得ない場合に限定して用いる
複数所有者を使わざるを得ない状況かどうかを確実に見分けるのはそれなりに難しい
Rustの場合はコンパイル通らないから無駄にRc/Arcを違うことはあっても逆はないので安全
C++は逆もある
>>853が「めちゃくちゃ安全になる」と言ってる理由もその辺にあるのでは

918 :デフォルトの名無しさん:2023/12/05(火) 22:10:46.45 ID:vNAfxFS3.net
>>911
RAII自体はコストゼロ
RAIIで解放されるスタック上の値の型にデストラクタがある時にその実行コストがかかる
そしてヒープ領域を所有していればヒープ解放コストがかかる
何度もヒープ確保解放を繰り返すよりはなるべく最初に確保するのはもちろん正しい
スタック領域で済ませられるならさらに望ましい

919 :デフォルトの名無しさん:2023/12/05(火) 22:57:00.41 ID:iiJ5Z2H1.net
全部独り言だったりしてw

920 :デフォルトの名無しさん:2023/12/06(水) 01:20:30.01 ID:N0N71GtG.net
メモリに展開するのにオーバーフローしてもエラーを通知しないの?
https://japan.zdnet.com/article/35212258/

言語はCらしいけどどういうプログラムなんだろう
まじでmallocしてそこにmemcpyしてるだけなんじゃないか
対策はRustで書き直せ

921 :デフォルトの名無しさん:2023/12/06(水) 01:23:15.09 ID:N0N71GtG.net
たとえクソレガシーだったとしても書き込むアドレスの範囲が想定してるものかのチェックは入れるべきだろう
どうせオフセットも手計算だろうし

922 :デフォルトの名無しさん:2023/12/06(水) 01:40:45.31 ID:MT5mgeUa.net
>>916
>>909
>GC言語でもunsafeで手動管理とかできるよ

どの言語?具体名あげてくれ。

923 :デフォルトの名無しさん:2023/12/06(水) 01:58:21.86 ID:+XLnMsko.net
[gc unsafe] [🔍]

924 :デフォルトの名無しさん:2023/12/06(水) 09:15:07.04 ID:oM0gjrfW.net
>>867-868
循環参照は?

925 :デフォルトの名無しさん:2023/12/06(水) 09:17:14.31 ID:oM0gjrfW.net
>>867
>あらゆる本で紹介されてない

a)全ての本で紹介されていない
b)紹介された本がひとつもない

どっちの意味?念のため確認

926 :デフォルトの名無しさん:2023/12/06(水) 09:18:07.12 ID:oM0gjrfW.net
>925 補足
a)全ての本で紹介されていない (紹介されてる本は少なくとも一つ以上ある)

927 :デフォルトの名無しさん:2023/12/06(水) 09:20:39.56 ID:oM0gjrfW.net
>>868
思い付いている人は大勢居る

>>865
>C++で極力Rustっぽく書く

いやいや Rust 以前から Rust 無関係に C++ で普通に C++ っぽく描いた結果でしょ
きみ承認欲求強過ぎるね

928 :デフォルトの名無しさん:2023/12/06(水) 10:53:51.94 ID:CNnXy5JV.net
>>922
メジャーなとこで言えばC#とかSwiftとか

929 :デフォルトの名無しさん:2023/12/06(水) 11:45:54.12 ID:oM0gjrfW.net
>>905
やっぱりNATテーブル不良で再起動したら治るルーターじゃん

930 :デフォルトの名無しさん:2023/12/06(水) 12:09:32.50 ID:4VSkBLs6.net
>>929
頭大丈夫か?

931 :デフォルトの名無しさん:2023/12/06(水) 12:31:44.18 ID:3kI3ay52.net
型推論の是非を問いたい
書くのは楽かもしれないが読みにくくね?
型の重複記述は省きたいがまったく型がわからなくなると理解が難しくなる
読みやすさを優先すべきだと思うがどうだろう
IDEやエディタのサポートでカバーされるという考え方もあるが、カーソル合わせないとわからないしな

932 :デフォルトの名無しさん:2023/12/06(水) 12:44:38.03 ID:lEEu+DT0.net
>>931
ややこしい型の手書きとか効率悪化の元だから駄目。

せいぜいIDEに型のコメントを自動生成させるくらいまでだな。手動は更新されなくなってバグの温床になる。

933 :デフォルトの名無しさん:2023/12/06(水) 12:46:06.06 ID:MT5mgeUa.net
>>931
けっこう同意。
変数初期化ではリテラルでの場合だけ型推論利用して、そうでなければ型書いちゃうことも多い。

934 :デフォルトの名無しさん:2023/12/06(水) 12:51:11.58 ID:MT5mgeUa.net
>>932
>手動は更新されなくなってバグの温床になる。

型変わったらコンパイル通らないし、型明示がバグの温床になるってのは無い。
修正の手間が増えるってのはわかる。

935 :デフォルトの名無しさん:2023/12/06(水) 12:54:09.75 ID:B4jpx9xe.net
複雑な型名を知る必要がない場合も多い
例えばRustなら関数の引数型も返り型でも具体的な型名を書かずに
impl Trait名 と使う機能のトレイト名だけを指定したり

936 :デフォルトの名無しさん:2023/12/06(水) 12:56:26.38 ID:lEEu+DT0.net
>>934
c++はスライシングあるからエラーにならない例外もある。
レアケースだけど。

937 :デフォルトの名無しさん:2023/12/06(水) 13:09:40.96 ID:6EzLMFr7.net
同じ情報を二重に書くのはプログラマなら普通疑問に思う

938 :デフォルトの名無しさん:2023/12/06(水) 13:12:47.35 ID:N0N71GtG.net
>>924
コピー時はweak_refで渡すので良いかと思うのだが

939 :デフォルトの名無しさん:2023/12/06(水) 13:14:02.81 ID:N0N71GtG.net
>>925
普通に考えてaじゃないの?
なんで紹介とか出てくるんだ?

940 :デフォルトの名無しさん:2023/12/06(水) 13:17:03.16 ID:3kI3ay52.net
>>937
ある程度の重複さによってミスを早期発見できる効果があるから一概にそうはいえないぞ

941 :デフォルトの名無しさん:2023/12/06(水) 13:31:08.88 ID:UHi6Tpqq.net
俺のプログラムにバグがあるのは
俺がまだ本気出してないだけだから

942 :デフォルトの名無しさん:2023/12/06(水) 13:38:13.20 ID:+XLnMsko.net
どれだけスレが進行しても客観的な基準が示されず
主観バトルを発生させ続け
留まるところを知らない概念

可読性

943 :デフォルトの名無しさん:2023/12/06(水) 13:40:26.85 ID:uGBP6FLN.net
>>938
いやそれだとshared_ptrの意味ないから
shared_ptr使う限りは本質的には解決は難しい
それは生でshared_ptr使う場合も同じ
get_weakというメソッドでweak_refでラップして返すメソッドを提供するとかだろう

944 :デフォルトの名無しさん:2023/12/06(水) 13:44:37.37 ID:uGBP6FLN.net
全銀のシステムこの規模で低レイヤーのメモリ操作しまくるのにC使ってるのマジで狂気としか思えないな
コードレベルのユニットテストもないのだろうし
絶対こういうこと起きるやん

945 :デフォルトの名無しさん:2023/12/06(水) 13:55:39.00 ID:6EzLMFr7.net
>>940
保守できなくなるから必ず避けるべき

946 :デフォルトの名無しさん:2023/12/06(水) 14:04:56.53 ID:3kI3ay52.net
>>945
プログラミング言語自体、ある程度の冗長性があるようにデザインされている
たからこそコンパイルエラーという現象が起こる
そもそもテストを書くという行為が重複した作業なのだけどやるだろ?
仕様変更したら書き直しなのは仕方ない

947 :デフォルトの名無しさん:2023/12/06(水) 14:06:40.52 ID:ts/cnrJA.net
Cであることは関係なくね?
データ形式の共有に失敗すればどこでも起こりそう
記事だけだとよく分からんけどAAABBBをABABABって誤認した感じでしょ

948 :デフォルトの名無しさん:2023/12/06(水) 14:10:35.44 ID:4S+GIU/C.net
ABAP

949 :デフォルトの名無しさん:2023/12/06(水) 14:11:26.67 ID:6EzLMFr7.net
>>946
>プログラミング言語自体、ある程度の冗長性があるようにデザインされている
それは妥協の産物で悪だよ

>たからこそコンパイルエラーという現象が起こる
冗長性がない言語があったとしてコンパイルエラーは起こるし意味がある

>そもそもテストを書くという行為が重複した作業なのだけどやるだろ?
>仕様変更したら書き直しなのは仕方ない

最初に型名が正しいと確認されたら型推論に任せるべきです

950 :デフォルトの名無しさん:2023/12/06(水) 14:17:11.63 ID:N0N71GtG.net
>>947
どこを読んだらそうなるんだ?

951 :デフォルトの名無しさん:2023/12/06(水) 14:41:23.05 ID:oM0gjrfW.net
>>945
>保守できなくなるから必ず避けるべき

保守する気がなくなるから必ず避けるべき
ならわかる

952 :デフォルトの名無しさん:2023/12/06(水) 14:44:32.97 ID:uGBP6FLN.net
>>947
なんも分かってなくて草
あの記事だけで普通は全部理解できるぞ

953 :デフォルトの名無しさん:2023/12/06(水) 14:52:19.97 ID:3kI3ay52.net
>>949
> 最初に型名が正しいと確認されたら型推論に任せるべきです

その最初の確認ってどうすんのさ?
まったく字面では現れない場合があるよね
もともとはその場合の話

954 :デフォルトの名無しさん:2023/12/06(水) 15:01:15.76 ID:ts/cnrJA.net
>>952
記事から全部理解できたならたぶん別の記事だと思う

955 :デフォルトの名無しさん:2023/12/06(水) 15:07:10.91 ID:N0N71GtG.net
>>954
正確にはスライド
普通にわかる

956 :デフォルトの名無しさん:2023/12/06(水) 15:12:14.26 ID:6EzLMFr7.net
>>953
まぁそうだね
>>932で私の言いたいことは書かれてたや

957 :デフォルトの名無しさん:2023/12/06(水) 15:22:00.69 ID:aoO2XCof.net
全銀のやつは記事に書いてることはわかるがめちゃくそ疑問だらけ

なんで生成時にサイズチェックしないのか
なんで生成されたテーブルをチェックしてないのか
なんで生成されたテーブル使った試験をしてないのか

一般企業でもなかなかお目にかかれないひどい内容だがそれを金融系のしかも全銀がやっちゃうってのが信じられないわ

958 :デフォルトの名無しさん:2023/12/06(水) 15:26:41.21 ID:MT5mgeUa.net
>>944
同感

959 :デフォルトの名無しさん:2023/12/06(水) 15:33:52.57 ID:MT5mgeUa.net
型推論よりインテリセンスとか補完がうざい。
こっちの入力リズムに合わないとイラっと来ることある。

960 :デフォルトの名無しさん:2023/12/06(水) 16:16:19.10 ID:oM0gjrfW.net
>>957
同感

961 :デフォルトの名無しさん:2023/12/06(水) 16:17:28.30 ID:oM0gjrfW.net
>>959
判る
入力enterで違う単語になってたら殺意を覚える

962 :デフォルトの名無しさん:2023/12/06(水) 18:22:40.40 ID:SQhb0To1.net
Pimplが説明してるある本がないか立ち読みしたのだがあった
最近出たC++ソフトウェア設計という本にモロに書いてあった
こんな本いつの間に出てたんだ?
モロに俺がドヤ顔したパターンじゃねえか...
この本内容もめちゃくちゃ良いぞ

963 :デフォルトの名無しさん:2023/12/06(水) 18:31:32.46 ID:6EzLMFr7.net
pimplってGoFになかったっけ?

964 :デフォルトの名無しさん:2023/12/06(水) 18:37:31.41 ID:+XLnMsko.net
ヘッダファイルの変更のせいで再コンパイルされるC++特有の問題に対処するのが主目的のpimplがなんでGoFにあると思ったんですか?

965 :デフォルトの名無しさん:2023/12/06(水) 18:54:10.35 ID:MT5mgeUa.net
>>962
pimpl、10年前の本「C++のためのAPIデザイン」(2012年)にも載ってるぞ。

966 :デフォルトの名無しさん:2023/12/06(水) 18:55:40.21 ID:SQhb0To1.net
まあPimplの主張はコンパイルサイズを固定するとか
内部を隠蔽することが主目的っぽいね
この本ではImplにunique_ptrを使ってコピー時にmoveする実装になってる

967 :デフォルトの名無しさん:2023/12/06(水) 19:05:32.22 ID:ts/cnrJA.net
知ってると役に立つけどC++使う気が失せる技法のひとつだな

968 :デフォルトの名無しさん:2023/12/06(水) 19:09:45.42 ID:+XLnMsko.net
>>966
>unique_ptrを使ってコピー時にmoveする

恐怖!auto_ptr再発明男!

969 :デフォルトの名無しさん:2023/12/06(水) 19:24:48.89 ID:lBgUAnRO.net
>>965
紙本は絶版っぽい
kindleがあるから買うか悩むなあ
クソ高いし

970 :デフォルトの名無しさん:2023/12/06(水) 19:26:54.33 ID:lBgUAnRO.net
確かに不毛過ぎる気はする
本質的じゃない部分ですげー頭使わなきゃならんし
面白い部分でもない
素直にrust使うべきだわ

971 :デフォルトの名無しさん:2023/12/06(水) 19:48:07.27 ID:Pw3WwC1e.net
銀行はやったこと無いけどSIerの下請けで
お役所のシステム移行の
仕事したときにライブラリ一つに数万個のテストケースが
用意されてあらゆる仕様適合をチェックしていたので
実装でアホなことしててもテストで叩き落とせばよいという
思想なのかも

972 :デフォルトの名無しさん:2023/12/06(水) 20:02:44.32 ID:Knh+cYx8.net
>>964
GoFのBridgeパターン

973 :デフォルトの名無しさん:2023/12/06(水) 20:16:14.69 ID:3kI3ay52.net
ヘッダーに実装書きまくるのが今のクソc++だからpimplにしたところでというのはある

974 :デフォルトの名無しさん:2023/12/06(水) 20:37:00.46 ID:MnzvwPfi.net
実装を書かざるを得なくなってヘッダーと呼ぶのが不適切になったから.hの拡張子がなくなった

975 :デフォルトの名無しさん:2023/12/06(水) 20:57:06.52 ID:N0N71GtG.net
Pimplの良い説明を見つけた
この中のstd::shared_ptrの場合が今議論されている項目のようだ
http://www17.plala.or.jp/KodamaDeveloped/LetsProgramming/details_pimpl_idiom.html

976 :デフォルトの名無しさん:2023/12/06(水) 22:01:15.11 ID:rDPAp/5U.net
IT大手がRustへ舵を切るわけだな

977 :デフォルトの名無しさん:2023/12/06(水) 22:38:24.64 ID:UoD976YL.net
pimplはScott MeyersのEffective Modern C++が詳しい(Effective C++にもある程度書いてある)
shared_ptrじゃなくunique_ptrを使えと書いてる
https://en.cppreference.com/w/cpp/language/pimpl
https://herbsutter.com/gotw/_100/

978 :デフォルトの名無しさん:2023/12/06(水) 22:38:53.88 ID:UoD976YL.net
>>972
構造が似てるだけで全然別のもの

979 :デフォルトの名無しさん:2023/12/07(木) 00:06:56.11 ID:3PWWuEZS.net
デザインパターンとは構造について述べたもの
pimplはBridgeパターンの一適用例
別のものではない

980 :デフォルトの名無しさん:2023/12/07(木) 00:37:25.72 ID:mM7hpDu4.net
>>979
>デザインパターンとは構造について述べたもの
全然違うよ
GoFにもそういう考えを明確に否定する内容が書いてある

981 :デフォルトの名無しさん:2023/12/07(木) 00:41:10.07 ID:katRzGi9.net
C++オブジェクト設計という本にはbridgeパターンの一種で継承や多態性が必要がない場合の単純な例としてPimplの説明があった

982 :デフォルトの名無しさん:2023/12/07(木) 00:52:49.01 ID:3PWWuEZS.net
>>980
議論をしたければ
GoFに書いてあるそういう考えを明確に否定する内容
を述べ給え

983 :デフォルトの名無しさん:2023/12/07(木) 00:55:08.82 ID:3PWWuEZS.net
>>981
一見して分かりそうなもんだけどね

984 :デフォルトの名無しさん:2023/12/07(木) 01:04:03.35 ID:Avn/NPEq.net
C++の不完全型とJavaのインターフェースが同じに見える人には同じに見えるんだろう

985 :デフォルトの名無しさん:2023/12/07(木) 02:06:38.63 ID:Sudvf4UZ.net
>>980
そんなこと書いてねーぞ

986 :デフォルトの名無しさん:2023/12/07(木) 09:57:06.17 ID:XOE4A360.net
RustでGUIのアプリがつくりたいです

987 :デフォルトの名無しさん:2023/12/07(木) 11:16:21.90 ID:Gb/m/afO.net
egui

988 :デフォルトの名無しさん:2023/12/07(木) 13:36:44.52 ID:XOE4A360.net
>>987
ありがとう
これはおもしろそうでごす

989 :デフォルトの名無しさん:2023/12/07(木) 23:09:48.18 ID:wfAAUjY+.net
えぐい

990 :デフォルトの名無しさん:2023/12/08(金) 09:55:56.32 ID:k3Bpg+TD.net
踏んどくか

991 :デフォルトの名無しさん:2023/12/08(金) 09:58:29.65 ID:k3Bpg+TD.net
結局C++とRustってどっちが良いの? 9traits
https://mevius.5ch.net/test/read.cgi/tech/1701997063/

992 :デフォルトの名無しさん:2023/12/08(金) 10:01:41.64 ID:dTkbwwL5.net
unsafe {
次スレいらんわボケ
}

993 :デフォルトの名無しさん:2023/12/08(金) 10:15:03.32 ID:k3Bpg+TD.net
・めとくか

994 :デフォルトの名無しさん:2023/12/08(金) 10:27:55.85 ID:gyEpWkla.net
Cで書かれたプログラムがある
Rustに移植せよ
https://uguisu.skr.jp/othello/7gyou.html
https://ideone.com/0xz2SJ

995 :デフォルトの名無しさん:2023/12/08(金) 10:38:32.80 ID:DJ4GSkDO.net
こんな短く書けるんだ!

996 :デフォルトの名無しさん:2023/12/08(金) 10:39:02.81 ID:k3Bpg+TD.net
RustはCとの相性は良いがC++との相性は最悪

997 :デフォルトの名無しさん:2023/12/08(金) 10:39:54.69 ID:k3Bpg+TD.net
どうしてもC++を捨てられない人は
RustよりNim使った方が救われる

998 :デフォルトの名無しさん:2023/12/08(金) 10:40:47.47 ID:k3Bpg+TD.net
>>994
このスレの腕自慢建ちなら一瞬で移植してくれるだろう

999 :デフォルトの名無しさん:2023/12/08(金) 10:41:18.48 ID:k3Bpg+TD.net
間違えた
x 建ち
o 達

1000 :デフォルトの名無しさん:2023/12/08(金) 10:41:47.84 ID:k3Bpg+TD.net

https://mevius.5ch.net/test/read.cgi/tech/1701997063/

1001 :2ch.net投稿限界:Over 1000 Thread
2ch.netからのレス数が1000に到達しました。

総レス数 1001
253 KB
掲示板に戻る 全部 前100 次100 最新50
read.cgi ver 2014.07.20.01.SC 2014/07/20 D ★