■ このスレッドは過去ログ倉庫に格納されています
結局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 ★