結局C++とRustってどっちが良いの？ 8traits
レス数が1000を超えています。これ以上書き込みはできません。
「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/ あるあるトピックス
・後発のRustは優れている(この点で特に争いはない
・といっても、C/C++から「推し変」するほどじゃない(使わないとは言ってない
・ていうか、Cとの比較と、C++との比較は違うくね?
・いくら安全っつっても、ヘタクソがunsafeだらけに書いちゃったらおんなし
・てかC++にも unsafe{ } はよ
・web方面、特に基盤部分での人気すごいね
・ChatGPTとかが賢くなる(のに賭けてる)からどうでもいい ネットインフラが次々と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」などがある。 プログラミング言語「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に書き換えて、
そこから徐々に広げることで段階的にセキュリティ上の恩恵を受けようという戦略なのだ。 >>2
C++はデフォルトがunsafeだから、入れるならsafe{}じゃないのけ？ デフォルトをsafeにするって話やろw
そうすると現行のライブラリはビルドできないので取り敢えず全部unsafeで囲う
バージョンを重ねてunsafeの部分を減らすって戦略でしょ? null safetyですら無理なんだからunsafeなんて夢のまた夢 positive list と nagative list の違いやろ
どっちも一長一短があるってだけで
どっちが一方的に優れているということではない 前者が明らかに劣ってるのは自衛隊見れば明らかじゃん ちなみに Rust の unsafe {} は positive list に相当すると思う 時代は静的検出なので、冒頭に
#pragma safe
とかでも書くとかになるんじゃないかな
そのうしろに、縛りの識別子が入るのでもいい unsafe {}ってなに？
ポインタ扱えなくするやつ？ ｝ // あとでみなおす
とりあえず生ポはなしかな
ポインタはきちんと定義される 前スレ
>>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()となる Rust がリファクタリングと相性が悪いんじゃないか
と思うことが時々というより割と頻繁にある 設計が悪いおじさん「設計が悪い」
…とはいうものの、書き味ってもんがあるよね言語って 難しそうという直感でリファクタリングを中止できるのは損なのか得なのか Rustはリファクタリングや更新メンテとの相性いいと思う
C/C++で他人もしくは過去の自分が書いたコードの肝の部分をうっかり踏み抜いてメモリデバッグコースとなるところを
Rustは未然に防いでくれてる リファクタリングでエンバグしにくいけど、そもそもリファクタリング自体しにくいよね https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2687r0.pdf
C++はfeature gate方式でアノテーションした箇所のみ
static analyzerでチェックする方針で一応進み始めてるのね
なんというか過去の資産を生かすというのは大変なんだな
Rustと同レベルのsafetyが提供できるようになるかどうかまだわからないけどまあ頑張ってという感想 悪い(かも知れない)設計を
良い(かも知れない)設計に
するのがリファクタリングのモチベだと思うので
元の設計が悪い(かも知れない)のは仕方ないが
良い(かも知れない)設計に変更するのを阻む力をRustはもってる
もちろんリファクタリングでエンバグしない利点は認めている 更新メンテでエンバグしないと言っても
汚いコードが汚いまま増設されていく不安しかない リファクタリングなんてもんは無能な働き者がすることよ 耳が痛いわ〜ｗ (横から
>>27
走り読み…と思ったら、かっちりしたまとめだった
型に含めることばっかり(自分なりに)考えてたが、属性かー。
ああそういや、VCの属性プロバイダ、API公開まだだったよな borrow! またお前かっ!!
ですね
判ります
あとは C# みたいな PartialTrait があれば良いのに >>28
他の言語との比較も含めて具体的な例を上げてくれないと
何が困ってるのかよくわからん >ゼークトの組織論において、もっとも害のある存在とされるのが、無能な働き者（愚鈍：勤勉）タイプの人材です。正しい判断力や行動力が備わっていないにもかかわらず、自身の判断で行動してしまう特徴を持っています。いわゆる「余計なことをしてくれる」タイプの人材です。 無能な働き者が動くことで間違った判断により損害が出たり、周囲が後始末に追われたりといった混乱を招きます。しかも、本人は「よかれと思って動いている」点が、大きな問題となるのです。 無能な働き者は放置しておくことで、組織にとって大きな損害をもたらすリスクとなります。
努力や判断のベクトルが間違っているだけで、意欲的な人材であるかもしれません。適切に関わり軌道修正を図れば、組織に貢献してくれる人材になってくれるかもしれません。この困ったちゃんを相手にする余力が会社や関係者にあればよいのですが、そうでない場合は自己都合退職へ誘導し、早めに組織から追い出しましょう。 軍人を4つのタイプに分類する「ゼークトの組織論」と呼ばれる軍事ジョークがあり[注釈 2]、ゼークトが以下のように語ったとされる。
---------8<----------8=------
これは実際には同時期のドイツ軍人であったクルト・フォン・ハンマーシュタイン＝エクヴォルトが副官に述べたとされるもの[31]が元になっている。 いつの間に、こんなに積極的に、異物は排除しましょうなんて世の中に深化したのかねえ
世知辛い >>38
>いつの間に
いつと問われれば人が集落として生活するようになるぐらい古代から…なんじゃね
村八分とか神隠しとかぐらいは聞いたことあると思うけど
司法がない時代は私刑が日常的に行われていたんだよ
今は法律もあるしネットで大騒ぎすれば助けてくれる奴も出てくるだろうけど
属していた会社なり組織からは切り離される形に落ち着くだろうね Rustはリファクタリングでのエンバグ防止も強力で開発効率良いな >>39
私刑の大半は「自分が気に入らない相手を消す」だろ ゼロサムゲームなんだよねえ あいつがいると、こっちの幸せの取り分が減る C++のchrono
Sun=0, Mon=1, ..., Sat=6
Rustのchrono
Mon=0, Tue=1, ..., Sun=0
なんかの嫌がらせか？これ 訂正
C++のchrono
Sun=0, Mon=1, ..., Sat=6
Rustのchrono
Mon=0, Tue=1, ..., Sun=6
なんかの嫌がらせか？これ >>49
0と7が日曜だと便利なんだよ
なんで変えちゃったのかね おまえら全員エアプログラマーだな
Rustのchronoは両対応で困ることはない
num_days_from_sunday()だと日曜日から0発進
num_days_from_monday()だと月曜日から0発進 >>53
Rustのchronoが日曜スタートと月曜スタートの両対応にしている理由がそれ
C++のchronoでISOに変換するには日曜日だけif文するか再び%7する必要がある たぶん何も考えてない+誰も使わないから放置されているだけだね
Mon=0固定の前提でTryFrom<u8>なんか実装してるし そこは言語によって異なるんだよ
Pythonは月曜スタート
weekday() 月曜日=0 ～ 日曜日=6
isoweekday() 月曜日=1 ～ 日曜日=7
Javaも月曜スタート
DayOfWeek 月曜日=1 ～ 日曜日=7
だから両対応しているRustが最も良い状況 HTTPでJSONやりとりしてるとき思い込みで
バグになるというのはあるかも 今回のchronoでイチャモン始めたやつも
日曜日開始のC++しか知らなくてそれが正しいと思い込みをしてたからな
月曜日開始のISO8601とそれに従うプログラミング言語を一つでも知っていればそんな勘違いは起きなかった と、C言語のtm構造体から続くC/C++/UNIX系全般の伝統を知らなかった人が申しております >>60
それも常識だな
そしてISOおよびそれに準じるJavaやPythonも常識
両派あることを知っていれば両対応のRustを批判しだすような愚かな言動はしない >>62
コウモリ野郎が一番嫌われるんだよ
おまえは獣なのか鳥なのか 伝統的には日曜始まり、商用的には月曜始まり、ということだろ。
そもそも現代主流のグレゴリオ暦自体が欠陥だらけ (素数の7を週単位にしている、月の日数がバラバラ) だから、効率を気にしてもしょうがない。
完全数の6と3素数積の30を基準にすれば全然違ったのにな。 >>64
だからその日曜始まり日曜終わり両方に対応できる日曜0,7が有能だった話よ C++もc_encodingとiso_encodingで両方対応はしてる
簡単に変換できるから正直どうでもいいけど
https://en.cppreference.com/w/cpp/chrono/weekday/encoding
このドキュメントはReturn valueの2) の内容が間違ってる
レビュープロセスが心配になるな >>58
シリアライズ時と異なるエンコーディングで復元しようとしたらそりゃバグるわな
でもそんなやつらのために内部表現を統一しろと言われても誰も相手にしないでしょ >>56
JavaはWeekFields経由で日曜始まりにもできる
Pythonは日曜始まりのインデックスを直接取得することはできないがcalenderモジュールで日曜始まりのカレンダーを扱える
どちらもRustほど低レイヤーやC++を意識する必要がないからRust比べて少し高いレイヤーで日曜始まりにも対応している
Rustの開発者にとって最もいい状況が他の言語の開発者にとっても最もいい状況とは限らない === 複製おじさん（通称複おじ）について ===
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が複数出現するが、この中にも複製おじさんが多数含まれていると考えられている。
このように自分の誤りを認識した場合、それを認める書き込みは決して行わず、別人の振りをして最初から正しく理解していた体を装うのも複製おじさんの特徴である。 ゲームプログラミングに向かない時点でRustに勝ち目は無い プログラミング言語は とにかくユーザ数が増えて裾野が広がらないとだめよ
とはいっても、Rustはその性格上 エンジン系にはとても強いと思う ビルド時間が長いとか主要なゲームエンジンが対応してないとかかな？ >>74
ゲームエンジンこそどうでもいい
どうせ他人の成果物使うだけやし
つまりRustはゲームプログラミングに向いてない >>75
オブジェクト指向じゃないから大規模開発に向いてない ゲームはプログラムの積み上げ方式
Rustなんか使い物にならん >>78
むしろRustは大規模開発にも適するように設計された言語
今どきの普通にマルチパラダイムで当然オブジェクト指向もサポート >>75
>>79
グローバル変数が超絶面倒臭いからじゃね オブジェクト指向なんてもはや有害じゃねという
話も出てるようだけど 既存のオブジェクト指向言語の置き換えを狙ってるなら
既存のオブジェクト指向言語の機能は備えんとなぁ
設計からやり直す必要が生じてまんどくさってなる
スクラッチから新たに書くのなら支障ないだろうけども
それではいつまで経ってもマイナー言語だよ
この先生きのこれん みんな反発しても結局オブジェクト指向に帰ってくる
みんなC++に帰ってくる 最近のプログラミング言語は基本的にオブジェクト指向だがクラス継承だけは亡くなったらしい
最近のプログラミング言語
【クラス継承がない】Elixir、Go、Julia、Nim、Rust、Zig
【クラス継承がある】Kotlin(=Javaの後継)、Swift(=Objective-Cの後継)
つまり過去のしがらみでクラス継承を含めざるを得なかったKotlinとSwiftを除いて
全ての言語でクラス継承は亡くなった 人間は保守的なんだから
互換性を軽視したらユーザは絶対にぶんどれん >>89
GUI開発用言語とそうでない言語にきれいに分かれてんね GUIはクラス継承要らないだろ
有害なクラス継承しかないとクラス継承を使って巨大なピラミッドを作ってしまい
その反省も各新言語が揃って意図的にクラス継承を廃止した要因 それはクラスの継承というよくない古い考え方しかできない人向けの方法だな
様々に方向性も異なる方針の新プログラミング諸言語がクラスの継承だけは導入しない同じ結論に至った重みは大きい IUnk教わい、なくなるといわれるとちょっとさみしい (なくなるとは言われてない 継承がない言語には大抵はmix-inという優れた代替が用意されてる
継承もmix-inもないRustは無能 そうゆうのがない、切り捨ててるから、Linuxカーネルに来てよろしいって言われたのかもね しらんけど
やっぱり必要となりゃ、そのうち解禁(追加)になるでしょ >>95
極端だな
そんな考えじゃC++から移行なんて益々困難だし
こんなスレ立てて対立煽りするレベルにも達してないじゃないか
>この記事ではC++やJavaで継承を使っていた人がRustで同様の実装をしたいときにどうすればよいのかを説明します。
この課題については君はどうしたらいいと思ってる？ >>89
Javaの開発者も継承だけは間違いだったと言ってるみたいだね 64 デフォルトの名無しさん 2023/09/26(火) 09:36
以前Javaのユーザグループミーティングに出席した際、James Gosling（Javaの生みの親）がメインの講演者として招かれていました。
すばらしいQ&Aセッションの途中に、こんな質問が出ました。
「もう一度最初からJavaを作り直すとしたら、どこを変更したいですか？」
答えは「クラスを除外するでしょうね」というものでした。
笑いが静まった後、彼が説明したのは、本当の問題はクラス自体ではなく実装継承(extendsの関係)なのだということでした。
インターフェースによる継承（implementsの関係）のほうが望ましいのです。できる限り実装継承は避けたほうがよいでしょう。 やっぱりコミットするならシープラだなとおもいました その論法に乗っかってやると過去の
言語のパラダイム変化はどうやって起きたのか
謎になるな >>93
>GUIはクラス継承要らないだろ
要るか要らないかという話はしてないよ
1) Elixir、Go、Julia、Nim、Rust、Zig
2) Kotlin、Swift
1)の言語でGUI作れなくはないけど実際に作る開発者がかなり少ない
逆に2)の言語は大半の開発者がGUIを作ってる
それには理由があるということ
もっと言えばクラス継承的な機能の有無はトレードオフだからそれを理解しましょうねという話 多くの高機能webサイトはGUIアプリと言って良いと思うが
ts jsのクラス機能はあるけど使わないな >>89
思惑の違いが見事に結果に表れている分類だね
興味深い >>104
その「言語のパラダイム変化」って具体的にはどれを指している?
Rustがユーザを獲得する際の参考になるかもしれんね オブジェクト(classじゃなくてstructで良い)があって
正しい型指定で正しく関数が呼ばれてれば
クラス継承なんて要らないんだよな
別に禁止というほど厳しくやらなくても自然とそうなる C++ の template なんてあれオブジェクト指向じゃねーし >>105
KotlinとSwiftは最初からGUIアプリをターゲットにしてるしそれ以外の分野では全然使われてないような いまさら人に聞けない
悪い継承ってのがわからなくなった
継承おぼえたてて(一人プロジェクトが)めちゃくちゃになった経験ならあるけど、そうじゃなくてこう クラス継承は必要
オブジェクト指向を理解できないのはただのザコ >>115
最近のプログラミング言語たちが揃いも揃ってクラス継承を不要と判断しちゃいましたぁ
【クラス継承がない言語】Elixir、Go、Julia、Nim、Rust、Zig 言語開発者が設計した基底クラス以外の継承はいらないんじゃないかなぁ Pythonスーパーセットのmojoにこのまま成長してほしいけどシープラRustの競合にはならないか mojoはAI関連の高速化を狙ったものだろうから限定的な利用になりそう 結局ユーザーが欲しかったのは「ポインタのないC++」であって所有権やtraitみたいな使いづらい独自機能じゃなかったんだよなあ >>122
所有権はC++にもある
traitはC++の抽象クラスからデータ(メンバー)を分離独立させてより良い設計ができるようになっている
使いづらくなっていない >>117
doubleがfloatを継承していないのはなぜ？
f64がf32を継承していないのはなぜ？ 精度の違いであって継承関係無いな。
むしろ継承したらダメなやつ。
共通のインターフェースを用意するのが普通。 パフォーマンスを度外視するなら
浮動小数点数型をfloatとdoubleの両方とも継承するのが自然かなぁ >>127
その浮動小数点型ってどんなもの？
インターフェースじゃないんだよね？ >>116
自分に都合の良い言語のみ列挙する
まさにザコ
自分の考えが無い Rustとの相性で言えば
Rust+Pythonはかなり良い
Rust+Cが最強
Rust+C++は最悪
Nimとの相性で言えば
Nim+Pythonはとても良い
Nim+Cが最強
Nim+C++も最強
Nimの勝ち >>129
自分はなにも例を挙げられないの？
それでよく人を批判する気になれたね テンプレートパターンやるにしても今は継承よりもクロージャで渡す方がわかりやすいって話やね。
まあどっちにしろ低レイヤー言語だとオブジェクトの解放タイミングとか気にしてめんどくさくはなるが。 C++/Rustと比べて何もかも劣るNimは選択肢に上がることがない >>134
そもそも流行りの話自体何の根拠にもなってないんでこの話自体無意味
無意味な話は時間の無駄 C++は仕様などがugly
Rustはbeauty Nimの唯一のメリットがPythonに似た文法と言われているが
このスレの住人はそれをメリットと感じない まあ複おじ隔離スレなんだから代表は複おじでいいんじゃない？ >>141
インデントではなく波括弧でブロックを表すのが好まれている多数派 >>146
c世代はそうだけど、pythonユーザーの方が多い現在はインデントブロックの方が主流。じゃなきゃYAMLとか流行らん。
LISPも丸括弧使ってるけどインデントブロック風の整形しているし、波括弧ブロックが多数派とは思えん。 >>147
どさくさに紛れてYAMLを流行り扱いすんなやｗｗ Pythonみたいなインデントずれたら明後日の動きする様な言語は欠損言語だろ 「Linux」メンテナーの燃え尽き症候群問題--業務内容の変化と支援の必要性
https://japan.zdnet.com/article/35210969/
Corbet氏は「Rust」言語がLinux開発で採用されたことについて歓迎しているものの、これによってメンテナーにさらなる負担がかかるようにもなるとした。同氏は、「カーネルメンテナーを務める以上、Rust言語で記述されたコードのマージ依頼も受け取ることになるため、同言語に対する極めて深い知識が必要となる(中略)既に多忙を極め、自らの仕事量に圧倒されているメンテナーに対して、この新言語の学習を求めるのは酷というものだ。このため、この点は今後、問題となりそうだ」と述べた。 >>147
インデントに整形以上の意味を持たせた言語の方が好まれてるかどうかの話をしてるのに
他の言語でもインデントで整形してることを根拠にしても意味ないだろ whitespace significantな言語はプログラミングの素人にとっては多少読みやすいというメリットはある
しかしそれ以外はデメリットだらけなので素人を釣りたい場合を除いて採用するメリットがない リモートワーク制度が削減・廃止されたら「転職や別案件を探す」が4割--
「Offers」登録者調査
ITエンジニア／デザイナーの副業・転職サービス「Offers」を提供するoverflowは、
同社が運営する「Offersデジタル人材総研」にて「リモートワーク実態調査2023」
を公表した。
これによると、リモートワークになり、5人に1人が引っ越したと回答した。そのうち、
現職でリモートワーク制度が削減・廃止された場合、「転職や別案件を探す」という
回答が44.0％にものぼった。一方「会社と交渉する」という回答は40.0％、
「引っ越さず受け入れる」が12.0％となった。
さらにリモートワークを希望している理由として「通勤時間が無駄だと感じている」が
87.7％でトップとなった。このほか「個人の時間ができる」(62.3％)、「副業を続け
やすいから」(39.6％)、「子育てができる」(35.8％)と続いた。 > Pythonみたいなインデントずれたら明後日の動きする様な言語は欠損言語だろ
ほんとこれ
> インデントより会話の論点を揃えないとな
ほんとこれ >>150
ずれたら思ってない動作になる場合があるのは確かだが
ずれることがめったに起こらない 正直食わず嫌いなんだが、あのインデント式、慣れない悪寒しかしない
yaml書かされるけど、おっかなびっくりだわ ifとかforがネストしてるときに論理構成変えたときに
ぐちゃぐちゃになったりしないの？ コピペした時困るのはあるけど
そんなネスト深いところにコピペする時点でコードが終わってるのだろう あっちのファイルはスペースで、こっちのファイルはタブでそれぞれインデントしてるとかw
更に同じファイル内でスペースとタブが混在したインデントしてるとかw シープラの文法が醜いってとこまで合意できてるってことでいいかな >>151
>メンテナーに報酬を支払おうというところはほとんど「ない」のだ
メンテナーほぼ金貰ってないのかｗ
壮絶な時間の無駄だな
linuxなんて潰れちまえ >>162
インデント構文はその醜さを完全に理解した親切な人が書くとわりとマシに読めるって話なら同意できる >>163
Nimの文法が駄目ならRustは産業廃棄物だな。 >>165
Linuxなんて無料だから普及したってだけだし
無名の大学生が作った有料カーネルなんか誰が使うかよ Rustが最も美しいけどC++に比べたらPythonの方がまし あれがいいんだぞ
でも、template<>のごちゃっとしてるのは苦手 NimはPython由来の文法が多い中でprocヘッダーの区切りをわざわざ=記号にしたのは何でなの？ 痘痕もエクボっていうしずっと使ってると美しく見えるのかもしれん
始祖のハゲ散らかしもイケオジに見えるのかもしれん Nimは継承あるじゃん
だれか突っ込めよ
複オジ嘘つき放題じゃねーか このスレの半分は複オジのウソで出来ています。
用法・用量を守って正しくご使用下さい。 複おじってニートでしょ？
なんか我々と対等に喋れること自体がとんでもない体験なんだし
もっと感謝して欲しいね #embed はあると安心 ないとやっぱり一手間かかる
clangではできてたっぽいけど(VC派 >>180
クラス継承だけが継承ではないのだけどね 有害とされているのはクラスの継承
それ以外の継承はあってもいい 綺麗に書けるならという条件がつく
本来、綺麗に階層化するのが目的だったのが、どうしてもごちゃついてしまう
基本にして難 それが継承
って感じでいい? >>189
大抵は駄目。
継承は「インターフェイスの共有」という外部との契約と、「実装の共有」という内部との契約をごっちゃにしているから、すぐに設計がごちゃごちゃになる。
内部と外部は明確に分離したほうが手間がかかるが問題になりにくい。 クラス継承では複数の機能を継承したくなった時に多重継承が起きてしまう
多重継承を避けるには使うすべての機能を巨大なツリー関係に押し込める本末転倒な事態になる >継承は「インターフェイスの共有」という外部との契約と、「実装の共有」という内部との契約をごっちゃにしている
Nimの継承にも同じことが当てはまるけど
Nimにはクラスはないから有害じゃないという主張でいいのかな？ >>189
そのレベル浅い知識ならおそらく「SOLID原則」を知らないでしょ
勉強しな？
メンテや機能追加を繰り返してるとどうしても内部構造が腐敗していくものよ >>193
理想は継承なしの共通インターフェイス。継承自体いらん。
原理的には同じメソッドを持つのならどんなインスタンスでも同じインターフェイスで扱えるから、継承を使って扱えるインターフェイスを制限するのは「早すぎる最適化」としかいえん。 多重継承って本当に悪か?
多重継承を使う前に周りに悪って教え込まれたので
これまで本格的に使ったことはないのだが
みんなは酷い目にあったことあるかい?
敢えて「多重継承=悪」思考停止論を提起したい 有用なものを何も生み出せない
目的と手段を履き違えた無能たちの知識バトルロワイヤル 現在動作してる過去のシステムを捨てるわけにいかない状況で、新しい共通システムを書くには継承がいいと思うけど
どうなんでしょう？素人考えなんですけど。 オブジェクト指向のメリットってホントにメリットなんだろうか？ >>199
モジュール分割の方法を広げるっていうメリットはある。
カーネルドライバー部分はオブジェクト指向した方がいいって、否定派のlinusも認めてる。 オブジェクト指向 ⊃ クラスの使用 ⊃ クラス継承の使用
オブジェクト指向自体は問題ない
クラスの使用も継承を用いなければ問題ないが
クラスと他との違いはクラス継承にあるように本質がその継承機能にあるため
クラス自体を無くしたプログラミング言語が最近は多数派となった >>201
全部マイナー言語じゃん
支持されてないんだよ >>195
全く答えになってない
Nimの継承は君が主張している有害な継承に該当するのか否か？ >>203
「継承自体いらん」と書いているだろ。
shared_ptr<function<T>>のTがインターフェイスになったのがあれば継承自体いらん。 >継承は「インターフェイスの共有」という外部との契約と、「実装の共有」という内部との契約をごっちゃにしている
もう一つ付け加えると↑これはデフォルト実装のあるTraitやインターフェースにも同じことが当てはまる
でもインターフェースのデフォルト実装を有害と言う人は少ない
なぜだろうね？ 特殊事情持ち出して一般論を語るな。
例外的なのが無いとでも思ってるのか >>205
Rustのtraitはデータ(メンバー)とは切り離された設計になっているから
デフォルト実装自身がデータ(メンバー)にアクセスできない点で違うんじゃないか >>194
SOLIDは名前しか知らないがライブラリのクラスを拡張するときは継承あると便利だけどな
コンポジションだとゲッターかプロパティでライブラリクラスのオブジェクト取得しないといけないし面倒じゃない？ >>210
その継承やらインターフェースの設計をうまくやるためのパターンがSOLIDだよ
これを知らずに継承使ってるやつは大抵ゴミコードを量産してる >>211
ゴミコードは沢山書いてきたが継承使う時はほどほどにしてるからな
あまりゴミ化はしたことないな
SOLIDは概念が難しかったがこれって継承の複雑さが出ちゃってるね
継承はもっとシンプルに使わないと >>212
継承がなければSOLIDなんてほぼ考えなくて良いからね
「インターフェース分離の原則」あたりさえ気にしていれば問題ないし
モダンな言語ならインターフェースは言語のコアとして搭載されてる
継承を無くすることでSOLID原則みたいな面倒なことを考えなくても良いし
コードもシンプルになるしメリットしかない
だから最近の言語では継承がない
これがモダンな言語では継承が存在しない理由 >継承がなければSOLIDなんてほぼ考えなくて良いからね
おいおいw
揃いも揃って何なんだここは >>214
？
ほぼ継承に関する問題を解決するための原則だぞこれは S 継承がなければ単一にしかなりようがない
O 継承がなければ勝手に追加も削除も容易
L 継承がなければ置換もクソもない
I 継承がなければインターフェースなんていくらでも分離できる
D 言わずもがな
継承があるからこの原則は生きる
つまり継承の悪い部分を避けるための
オブジェクト指向の原則
その知識は何のためにあるのか？
きちんと自分の頭で考えよう
それが知恵というものだ オブジェクト指向の全ての悪は継承にあり
DIなんかもこの悪を退治するための刃だ
継承こそがソフトウェアをゴミ化し
変更をしにくくする悪魔👿なのだ
この事実を誰も指摘してないことは驚愕に値する
オブジェクト指向はオワコンとかいう人に限って何が悪なのか明示的に指摘できていない 俺ははっきりと言う
継承こそが全ての間違いの始まりだと はるか昔「オブ脳」という概念があった
全てをオブジェクト指向で考えようというものだ
まずベースクラスを考えて〜
いやちょい待ち
その発想がまず間違っている
なんでベースクラスを最初から考えられると思った？
そんなことは神でもできない
そのようなオブ脳🧠こそゴミエンジニアへの入り口
幸いモダンな言語は継承を排除した
英断だと思う モダンな言語に置いては
インターフェース(トレイトとか制約とかプロトコルとか言語によって名前は違うが本質は同じ)
ありきで考える
言語のコアもインターフェース前提で設計されている
誰もベースクラスガーとか考えない
まずインターフェース考えよ、となる
そしてそのインターフェースを満たすための構造を考える
こうすることでデータがシンプルになり
頭を悩ますことが減る
これは業務ロジックでも同じ
インターフェースから考えよ このスレの半分は複オジのウソで出来ています。
用法・用量を守って正しくご使用下さい。 「それは、継承から始まった。」っていう世代の資産がまだまだあるからね
自分用には、継承を、きれいに書けるようになりたい
C++から逃げるな 断末魔で結構
継承カッケーと思ってるエンジニアにどどいてくれ ソフトウェア業界における設計失敗2選
1.ヌルポ
2.継承 ぬるぽは原始より居ただろ
飼い慣らせない人間が悪い(俺を含む ヌルポをなくしてOption型をデフォルトにすべきだった
コンパイラによるチェックを必須にすべきだったのよ
本当にこれだけのことで全てが変わった >>229
10年後に今の言語がどうけなされてるか言ってみ？ result型とoption型
rustだけがこの２つをデフォルトに採用した
生き残るのはrustだけ >>229
Object型じゃ型情報少なすぎるだろ。
全てのクラスにNullObjectを付けてnullptrを禁止すればマシになる。
あとインターフェイスはもっと制約を減らすべき。
c++テンプレートだと、テンプレート引数に指定するクラスはテンプレートについて何も知らなくていいけど、インターフェイスもそのレベルでクラス・インスタンスから切り離されているべきだ。 > Object型じゃ型情報少なすぎるだろ。
> 全てのクラスにNullObjectを付けてnullptrを禁止すればマシになる
Object型ではなくOption型
全ての各型にNullObjectを付ける必要はなく
任意のT型に対してOption<T>型を用いればよい
Option<T>型の値はSome(Tの値)のNone二択
T型自体は決してNull値やNone値をとなってはいけなくここが肝要 ただジェネリクスやテンプレートがないCに追加するのは容易ではない
それほど罪深い仕様 C++はまだ改良頑張ってるよ。
Cなんて、C11ぶり10年以上も改良してないとか酷すぎる。 SOLIDすら理解してないやつがRust推してるのか
呆れを通り越して悲しみを感じる SOLID理解してない人はクラス継承派だからアンチRust側 SOLIDもだが30年前から言われてるfavor composition over inheritanceの理由を理解してないのも呆れる
Rustの推し活する前にまずは基礎を学ぼうぜ
じゃないとどの言語使おうがゴミ量産するだけだぞ 継承より合成とそうすべき理由を理解していないのはRustを叩いてる側だな
理解できないがためにいつまでもクラス継承に固執している 俺はRustも継承も嫌いじゃないんだが
SOLIDは難しいから苦手だけど ついつい、機能を全部くらい使って書こうとしちゃうんだよね
複数世代のパラダイムが入ってるから、まぜるな危険 C++はスマホやPCと同じだよ
昭和ジジイはすぐ「これが持つすべての機能をマスターしてすべて使いこなそう!」とか無意味な事を考え
そして挫折して「パソコンなんて憶えても意味はないっ!人間の尊厳はもっとシンプルなものにあるのだ!
パソコンをつかわずに人間らしい美しい生き方をしよう!」とかいいだす
スマホもPCも自分に必要な機能だけ憶えて使えばいいだけ かわいそうだな
継承が上手く書けないくらい頭おかしいと c++はどっちかというとフロントボンネット開けっ放しでエンジン丸出しにしたテスラって感じだけどな 【基礎解説】 メモリ利用を効率化！ Modern C++のキモ「ムーブセマンティクス」
https://codezine.jp/article/detail/18574 ガソリンエンジンか、エレクトリックエンジンかの違いだね >>248
継承を使わないほうが様々な問題を起こさず上手く書けるというのが本筋
例えばクラスと継承を広めたJavaの生みの親であるJames Goslingも>>102でJavaを作り直せるとしたら継承を除外したいと言っている
これはプログラミング言語界では共通認識であるためモダンな各言語ではクラスとその継承が除外されている 発言のコンテキストを理解しようとしないからアホな結論に達するんだよなあ どうでもいいくだらない話題で延びるのは
上の方に消したいレスがあるとき >>258
伝言ゲームで多くの人を介した後の情報にしか接しようとしない人はコンテキストとかわかんないんだよ 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がチート職業！ >>257
Rustはclassの機能をstruct,impl,traitにばらしているからな。
いっそのことimplも無くしてnimみたいなメソッド構文にしてほしいわ。 >>264
他の型(=他のclass)と継承関係を持つ型がclass
RustやGoなどにclassの機能はない 継承を問題だと考えるならそう考える人が使わなきゃ良いだけで
言語仕様からなくす必要はなかったんだよ
他の機能との間に衝突が生じるというのなら無いのも分かるけど
ユーザの選択肢として継承はあるべきだった（発想が原理主義的なんだよね）
間口を狭めた結果ユーザー数は一向に増えない
ユーザー数が少なければユーザー数を増えないという負のスパイラルを抜け出せない
継承はあるものの手本を示すために標準ライブラリ（ってあるのかな?w）で
継承を使わないという方針を取るべきだったと思う >>263
Ruby使ってるサイトってまだあるの？ >>265
その解釈で言うなら>>180は間違いで、Nimにはクラス継承はあるってことでいいのか？
クラスにしろオブジェクトにしろトレイトにしろ、言語によって定義は微妙に違うのだから
特定の言語にだけ当てはまる特性を一般的なものとして語られると、議論に混乱がもたらされる
意図的にやっているのならば、それは藁人形論法と呼ばれる というか、型ごとにクラスであるか否かが決まるのか？
C++のclass C: public D {};はクラスだが、class C {};はクラスではないということになるのか？
動的型付け言語なら「値がクラスであるための条件」を定義することで何がクラスであるか定義する言語もあるが
（にしたって継承に依存しないだろうが）
静的型付け言語も含めた一般的な定義としては使えなさそうだ カプセル化などはクラス以外にも存在しクラスの固有機能ではない
クラスをクラスたらしめている要素は継承
Javaの生みの親が>>102で「Javaを作り直すとしたらクラスを除外したい」と発言した意図も、
その後に付加説明しているように「クラスを除外」とは「継承を除外」の意味としている
継承を使わないならクラスである必要はない
それがクラスごと除外した各モダン言語の意図だろう 菱形は無理になくてもいい
…といいつつ、あとになって菱形になっちゃいましたもありうるんだろうしな
まあ積極的には使わん 人智を超えるｗ >>272
javascriptのprototypeに近いものをclassと思ってるんじゃないかな JavaScriptもC++と同じく実装継承だからアウトだろ >>268
Githubとかはまだ使ってるみたいだけど明らかに減ってきてる感あるね >>267
ユーザー数と継承機能の有無は関係無いぞ >>281
元になった言語があるかどうかじゃん。継承関係ねーじゃん。 モダン言語＝関数型ベースにボクの考えた似非オブジェクト指向追加するのが流行ってるだけって感じで終わってる とは言っても俺らより遥かに頭いい人が考えた結果だからな >>283
ユーザ数が少ないとユーザは増えないんだよ
おまいらはどマイナー言語が趣味だろうけども世間は違う
ユーザ数を増やすには既存の言語のユーザを分捕るのが手っ取り早い
継承関係がないってことは他言語のユーザが学習したり
他言語のライブラリを移植する際にハードルとなる
期せずして書かれた>>89は上は全部どマイナー言語
下の言語はC++もそうだけどユーザー数が上より遥かに多い
普及戦略には既存言語との互換性が最大の影響を与えるということを示している
俺様の理想のみを追求した原理主義では誰もついてこない そういやRustで書かれたOSが実用化される話を読んだよ
軌道に乗ればRustを使う現場が増えるかもね
https://www.gizmodo.jp/2023/11/vivo-blueos.html >>288-290
Rust 推してんの中國人なんか？
そういえば github の Rust も中國語多い気がするな
Rust に関わるのもう辞めようかな 情熱的な曲ってCmベース多いよ
ドマイナーはドマイナーじゃない(豆
# そのギャグどっかで使おうっと 母数でかいし、まだまだ金回りいいしね cnをなめちゃだめだｗ >>293
コンピュータに関しては中国はもうかなりの分野で日本を凌駕してる
日本人にはRustで書かれたOSを実用化することは
残念ながら金輪際できないだろうね
プライドを捨てる必要がありそうだ >>257
偉い人の名前どうでもいいから具体的な話をしなさいよ
まあ無理だろうけどw Rustが浸透する可能性としてAIライブラリの充実がカギのような気がする。
ライブラリが充実すればマイコンへのAI実装が加速するかもしれないんじゃないかな？ >>287
javaにはinterfaceがあるしkotlinにもある。
objective-cにはprotocolがあるしswiftにもある。
うん、継承関係ねーな。 どうみても結果論で
Java に class も継承も無くて interface だけだったら
普及も糞も無かったはず
今の Rust より地位低かっただろう JavaはC++と文法を似せたことが初期でのユーザ獲得に効いたんだよ
ある程度ユーザ数を獲得したら
ユーザ数の多さがユーザ数の増加につながる
正のスパイラルが始まった
Rustはこの先生きのこれるかな? GoogleのC++スタイルガイドでも継承より合成が適切とあり
特に実装の多重継承は強く非推奨とある
C++には継承があるから積極的に使おうなんて話はない たとえアンチでも、それは過去資産という位置づけでは >>302
なぜ非推奨と言ってるの？
それはどうでもよくてGoogleと言いたい人なの？ 合成とか言うのか昔（2000年代前半頃）C++勉強してた頃には合成とかいう言葉なかった気がする composition over inheritanceの文脈で
compositionを合成と訳すのば明らかに誤訳 チンポジション推奨はわかるがひたすらデリゲード書く羽目になるのはだるい
文法的にサポートすべき >>307
継承が濫用されまくった反省から…っていう認識でいいのかな
継承とくらべてコンポジはフットプリントのコストがかかるけど(個人の感想です)、
そのくらいいいから、もっとわかりやすく書かないとって気運は確かに感じた James Goslingがクラスを無くすという話で警鐘を鳴らしたかったのはimplementation inheritanceのマイナス面
クラスがなくてもGoやRustにもimplementation inheritanceは存在していてそのマイナス面も全部ではないが継承してる
大事なのはプラス面とマイナス面の両面を把握した上で適宜使い分けるということ ちなみにRustは単純なクラス継承相当はないからコードの再利用がやりにくいという弱みがある
言語開発者もそれはかなり昔から認識してて機能追加をあれこれ検討してるが実現には至ってないためマクロを使ってコードを複製することが多い オブシコの綻び
継承無くしてオブシコ厨の大好きだった動物犬猫ニンゲンはどう表現するんですか みんな違ってみんないい
ってか、おまえらが自分らと同じクラスなど、不遜にもほどがあるﾆｬ トレイトって仕組みわりと便利だけどな
PHPでもこの仕組み取り入れられててわりと重宝する 基本はアダプタパターンで、本来はインターフェイスに代入するときに自動で適合してくれるのがいいのよ。
継承はクラスの親子関係でやらなきゃいけないから依存が強すぎるし、合成も実装とインターフェイスが切り離せないから密結合しすぎる。 リファクタリングするときに
Rustの｢親切設計｣が思考の邪魔をしてくる
どうにかならんか？ >>310
>ひたすらデリゲーション
RustのTraitもこれなんだな >>322
継承無しのcomで、インターフェイスはコンパイル時に検証する感じがいい。 なんか良さげじゃないか
これブレークしたらRust大発展場、ワンチャンありそう 6.x以降サポートされてLinuxカーネルコンパイルできるんだね。知らんかった。
Cから置き換わるか？
まだ、メジャーバージョンアップはありそうな気がするが >>325
Unityの1000倍高速な部分を売りにして
Unityと違ってライセンス料金も低く広く無料カバーされ
Unityからの置き換えを狙ってるな >>327
今まで動いてたものを置き換わることは無いんじゃね。
新規ドライバとかは少しずつ対応されるかもね。 >>327
ドライバだけに使われることあっても置き換わることはありえない 置き換えになる前に、Cが強化される方に期待
やっぱり、クリティカル用のCってあったほうがいい Cは進化を前提としたABIではないから
シンタックスシュガー的な強化しかできない
モダンな機能を求めるならCにトランスパイルする言語を使うことになる fn main(){
println!("{}", 111111111*111111111);
println!("{}", 111111111u64*111111111u64);
}
1653732529
12345678987654321
警告もコンパイルエラーも出ないんだが
Rustってあほなんか？ C++の唯一の得意分野だったゲームまでRustに置き換わりそう あほが間違ったのを指摘できるのがRustのメリットじゃなかったんか >>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型とみなされるようだ
エラーも丁寧に出るから初心者にもやさしいな >>330
言い切るのはいいが、その根拠を示さないとな。 現状はそうだけど
それでは、未来永劫置き換わらないと言えないのでは？
sudoとか置き換わってるよ オーバーフローチェックがどういう時に働くか把握してないならThe Bookからやり直しましょう >>331
Cの機能強化はあきらめろ。
委員会の顔はベンダーのほうをみていてCを良くしようなんて思ってないから。 >>341
未来永劫とか言い出すのはガキ
今から置き換えるメリットがない
せいぜいcの黒魔術マクロを排除できるぐらいだろ
カーネルサイズ大きくなりました
ちょっと遅くなりました
気持ちメモリ安全になった気がします
どうせこういう結果になる もちついて。
きき方が悪かったんだけどさ、LinuxカーネルをRust置き換えがありえないってのはなぜ？
これが聞きたかっただけですよ。
現状からの置き換えコストがかかるからという理由は置いといて、すでになにかあるの？
ケンカしたいんじゃないぞ
>>344 sudoは置き換わってないね LinuxのカーネルのソースコードをすべてRustに置き換えたときそれはLinuxと呼べるのだろうか
（テセウスのパラドックス） Rustの道具立てが揃ってきたら
スケジューラとかネットワークスタックなど
コアな部分をRustで書き直そうぜとか
言い出す人は確実にでると思うけど
POSIX互換(Linux互換)カーネルを
Rustでゼロから書いた方が早いとかなるのかどうか >>347
>>>344 sudoは置き換わってないね
どのディストリビューションの何が置き換わった? 口から出任せばっかりのRust宣教師
それに付き合う暇人 カーネルをコンパイルできるか、ってのは、ひとつのベンチマークになるらしい(どっかで見た
C2Rustみたいな翻案ツールができたら、Linuxで試されるようには思う 「その頃」のLinusはカス嫌いだったんだろうから、アウトプットがよければどうでもいい、だろ
C++は百花繚乱感があって、後から考えたらあれは嫌われるわけだ Linuxはもう枯れたと言える技術分野であって
エッジな人々が集まるところではないからな
エンタープライズ分野でたとえれば汎用機システムのメンテナンスしてるようなもの >>351
wiki見るとAndroidは置き換わってるように書いてあるね。
アマゾンのAWSのLinux？とか
カーネルは6.6.1でfind -name '*.rs' で引っかけるとmallocとかCのライブラリ関係かな？ほかいろいろ
LLTM=1スイッチで置き換わるようだが。
すぐに全体が置き換わるわけではないだろうけど、コアで脆弱性なところから始まってる感じに思えるね。 最新の安定版カーネルは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% 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ヶ月間の事実 >>357
>すぐに全体が置き換わるわけではないだろうけど、コアで脆弱性なところから始まってる感じに思えるね。
全くそうは思えないのだが? このスレの半分は複オジのウソで出来ています。
用法・用量を守って正しくご使用下さい。 >>360
そういわれると、たしかにコードの置き換えとしては進んでない感じするな
まだ実験検討段階って感じか >>356
世間知らず
クラウドインフラの技術が集結してる >>347
「コスト」が最大の理由だろ。
コードをRustに置き換えるだけでも膨大な手間と時間がかかる。
そもそもLinusとかのメンテナがRustを使いこなすのに何年費やすかね。そんな時間があったら現環境で機能強化するわな。 clangでのビルドにも慎重なのにrustで置き換えなんか進むわけない
そもそも書き換える行為に生産性がないのだから
せいぜい新しく書くところで部分的に使っていきましょうとなる
だからドライバでとなる 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の言葉を借りて「未来永劫」ないとないと言い切ってやろう >>366
単に物量の問題だろ
何百万行あると思ってるんだよ 30年の積み重ねを置き換えるのに30年…
とまでは行かなくても5年で大部分書き換え
とかはならんだろう 元々Cで造られたプロジェクトを一部だけRustに置き換えなんて面倒なだけでメリット無い
どうせRustでやるんだったら全部描き治しの方が良いに決まってる
Rustで置き換えと言うよりRustで新たにLinux互換プロジェクトが出来上がるだけ Andoroidは置き換え比較的進んでるよ、事実だしこれは否定しようがない。
>>356が言うようにLinuxはメンテナーが少なくなってきてるという記事を読んだことがある。
Cを本当に使える人が減ってきてるんだってさ。AIとかに流出してるのかもね。
Linuxは長い実績で堅牢なんだろうけどまだ脆弱性を含んでいるのは間違いないし。
メンテナーのレベルが落ちると長年で培った堅牢性がゆらいでいくんじゃない？
時間かけてじわじわいくよ。 >>372
カーネルに新機能追加する人は給料貰ってフルタイムで
やってる人がいるけどコードレビューする人は
ボランティアベースで辛いという話だぞ GoogleがAndroid OSのRust化を進めている >>372,375
プログラマなんだから話は定量的にどうぞ Linux Kernelコードの70%はドライバー
こいつらは基本的にデバイス屋さんが書いてる >>372
>Cを本当に使える人が減ってきてるんだってさ。
×Cを本当に使える人が減ってきてる
○Linuxをメンテしたい人が減ってきてる
大事な所を履き違えんなよ Linusは自分がいなくなっても継続できるようにしてると言ってたけどホントかいな ああいうワンマン強引タイプの周辺はだいたい
イエスマン(しかも心中はそのうち取って代ってやると思ってる野心家)ばっかりになってて
本人は継続できるようなつもりになってるけどいざ倒れると急におかしな方向いったり弱体化したりしがち >>383
リーナス氏はカーネルを書いただけの人で、Linuxはgnuの周辺が無ければ成立しないんだよなぁ ニュース記事を斜め読みしただけで
プログラム書いてなさそう人が参入してるな >>384
GoogleがAndroid用にforkしたLinuxカーネルへ加えた変更がアップストリームにも適用されることが多々あるから別におかしい話じゃないぞ
Androidと関係なくてもGoogle自体がLinuxカーネルを進化させてるメジャープレイヤーでもある rustサポートって何してるのか気になってコミットログ読んでみたけどこんなもんか >>385
なおさら駄目じゃね？
GNUツールのRust移行とか不可能だろ。 既存の枯れた部分を移行するメリットは低くそこに興味を持っているのはおまえらだけ
全く新たに作られていってるシステムなどに使われていく言語が世間での焦点 >>392
なるほどはっきりしたな
RustはC/C++の置き換えには適さない
以上！！！！本スレは終了！！！！ 既存の枯れた安定してるものを他言語で置き換えなんてムダなことをするバカはいない
>>5のような新たなシステムがどの言語で書かれているかが全て >>388
AndroidのRust適用はミドルウェアとか
実行ファイルの話 >>394
新規のシステムもRustよりC++/Cの方が多いでしょうよ
Rustはユーザ数が少な過ぎる ＞CDNプロバイダのCloudflareは、同社のグローバルなCDNの基盤として長らく利用してきたNGINXに代えて、
>>394「C言語製の枯れて安定してるnginxをわざわざRustで置き換えるCloudflareはムダなことをするバカ」 >>397
記事読めてる？
nginxでは機能が不十分で様々な検討をして新たに作ることになったとある
そしてRust製のPingoraを開発して以下の性能を出したと記事に書かれている
＞Pingoraはすでに同社のCDNに採用され、毎日1兆回以上のリクエストを処理し、性能向上や数多くの新機能の提供を実現しつつ、従来と比較してCPUとメモリリソースの消費はいずれも3分の1程度に収まっているとのこと。 >>397
nginxでは性能の限界があってRustで新規に
作ったと記事の読み飛ばしたところに
書きてなかった？ APIがRustになってないとRust採用する意味が無い >>401
今回の話の場合APIに相当するものはHTTPだと思いますが
APIがRustになっていないと、とは何？ nginxの代わりに使えるものを「新しく」作ったのだからPingoraはnginxの「置き換え」ではないと言いたいのか？？
じゃあ>>392の言う「移行」>>394の言う「置き換え」って厳密には何のことを指すんだ？？ たとえ後発のより良い新言語(ex. Rust)であっても
システムそのままで新言語への置き換えはコスト的に意味がなく
新たなシステムへ置き換える時に新言語の採用は大いに意味があるという実例だろう 403 は言葉使いからして感情でしか物事をみれない >>383
一応メールの中でコードを書いてるって言ってたけどね >>397
そりゃCloudflareレベルの規模ならメリットはあるだろう
メリットがあるなら書き直すし
メリットがないなら書き直さない
それだけ >>394
置き換えがしたいという意志があるとは誰も言ってない
そもそも修正と新規作成をどうしても区別したいという意志がない
ただ、ミクロな意志と無関係なマクロな現象として
置き換えが自然発生するかも知れないという謎の空気はある early adoptersやearly majorityになるのは
Linuxのperipheralとしてビジネスをしている企業ではなく
Linuxをperipheralとしたビジネスをしている企業
前者の大半はゲームのルールを他者に支配されている立場であり裁量の余地が小さいためマインドセットが保守的
純粋なコストベネフィット以外に低いリスク選好度からくる心理的抵抗が強いためearly adoptersやearly majorityにはなりにくい
複オジがいつも事例であげてるAndroid、Cloudflare、AWSなどが全て後者なのは偶然ではなく構造上の特性から生じる必然
新しい技術というのはゲームのルールを自らコントロールできるこちら側の企業によって牽引される つまり何が言いたかったかというと
Linux KernelにおけるRustの採用率というのは
技術採用ライフサイクルの観点で見た場合
late majorityやluggardsのRust採用率の目安だということ adaptor だと思ってたけど adopter なんか >>410
× luggards
○ laggards >>403
コードの移行、コードの置き換え。
>397は>370の例だろ。 それぞれのケースで大きく異なるから区別が必要
(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)新規作成だからであろう C/C++から書き直すにしても設計をそのまま使えないことが多いから
かなり大変なんだよな
とくに参照やポインタだらけで全部ヒープアロケーションしまくってる場合とか
C++でもその辺りポインタを多用せずスマポやスタック割り当てをうまく使って書いてあるソフトは移植しやすい どの言語からでもいいけどRustに移行するのにプログラム設計もそのまま引き継いだ自動コンバージョン的な移行を想定するほうがおかしいやろ
そんなんありえんよ C/C++にRust世代の知見が流入してくることに賭けて、待ってる勢はあるはず 自分はそう
それもあるけど、いまあるRustから前線で知見を得ようという勢もあるはず >>417
C/C++もclangがいったん咀嚼してLLVMにしてる
Rustにトランスパイルするのは非現実的とまではいえないはず
うまくいけば、Linuxは一夜にしてpure Rustになる
Rust派の誰かがやるんじゃないかと思ってる >>417
な
いつもの藁人形論法
AWSが最初からRustで構築されたとでも思ってんのかね 全てスタック変数で割り当てる
コピー時に適切なムーブをする
ヒープが必要なところはスマポを使う
これをちゃんとやればC++をrustに置き換えることは可能
しかしこれをやってるC++プロジェクトはない ま、雑談だから
ストローマンは愚痴
一頃のC++はなんでもかんでもヒープに置きすぎだったよね
まあ、お膝元のスタックがそんなでかくない石・スレッドも少なくないけど >>419
わざわざLLVM IRまで降りて戻ってこなくてもc2rustとか最低限のトランスパイラはいくつかあるぞ
出力結果は作業の開始地点として使うものでそのままプロダクションに使うものじゃない c2rustの出力をあんまり手直しばっかりしなくていいように、
入力のCにアノテーションを加えていこう、みたいな動きは必ず出ると思うんだよね
良くも悪くもCはマクロ世界だから、当面関わってない人には影響ゼロなようにも書けるはず
そのアノテーションが、そのまま、safe C の礎になればいいんだよ ああ、ストローマンは自動コンバージョンに反応したのか
“的な”の意味が通じなかったんだな >>397
記事を読めてないバカを晒すスレはここですか？ LinuxはスクリプトとCの二刀流だ
PythonとCの関係はRustとCの関係にも使える
その知見が流入してこない原因はスクリプト不要論だろう >>423
だがスマートポインタはスタックに置いて参照渡ししたい。 >>425
Cの安全性を高める目的ならトランスパイラではなく静的コード解析ツール用にアノテーションするほうが遥かに簡単
C++と同じようにCにもそういう動きが出てくる可能性はあると思う
ただ安全性を高めようとすればするほど既存のコードとはかけ離れていくからMISRAのように標準化され半強制的なものにならない限り広く受け入れられる気がしない
イメージ的には↓こういうやつ
浸透するとしても10年以上先だろうね
https://www.youtube.com/watch?v=Pk2RAl8kG1o >>430
Cの標準では今後も無い。
委員会がやる気ない。 Cは他のお笑い言語とは違って俺が最初に手に取ったK&R第二版から変える必要無かったからな >>433
さすがにK&Rからは変わってる
(ギャグだったならスマン) C++もlifetime annotationどうするか決まってないんだな
一番めんどくさくてコードも汚くなる部分だからannotation周りの評価はlifetime+borrow checkerの出来次第だと思ってる
https://discourse.llvm.org/t/rfc-lifetime-annotations-for-c/61377 やる気が暴走したPerlとかC++とかを過大評価するのは暑苦しい
やる気以外のルールはないのか あー、Perlも好きだわーｗ
ドザなので、シェルスクリプト代わりに、中途半端な処理は全部お願いしてる >>421
>コピー時に適切なムーブをする
これが恣意的すぎて自動的に対応できんわな。 立場によってはそう
継承に親でも殺されたんかって人なら、そう言うだろう
でもそれ、自分の推しの言語に継承かなにかが後出し採用されたら、ブーメランだぞｗ クラス継承(実装継承)は悪でプログラミング言語界が一致してるから後から継承の採用はないだろうな
過去のしがらみで継承を採用したSwiftやKotlinですら継承を使わずに済む機構などを採り入れている その結果>>89が示す通りマイナー言語に留まっているじゃん?
ユーザ数を増やすことを優先しないと
数多あるマイナー言語の一つとして忘れ去られる 言語のユーザ数の増加要因として最大なのはユーザー数だよ それがわからんようでは、いっしょに旨い酒は呑めんなあｗ
わかれよーわかりきってんだろ再帰だろ ユーザー数の多いアプリやOSの開発言語が言語利用者数に影響してるんだろうがいw 方法が違うだけでRustやGoにも実装継承が採用されてる
SwiftやKotlinは過去のしがらみで実装継承を採用してるわけではない
目的に対して有益だから採用してるだけ
実装継承の乱用するやつも悪だと決めつけるやつも中身を理解してないという意味では同類だから
どの言語を使っていようがどちらも採用してはいけない >>450
dN/dt = cN
右辺は一次関数とは限らんだろうけども
新たに学ぶ言語を選択するときには
人は多くの人が使っている言語を選択する傾向にある >>452
そんなん仕事で開発する人には通用しないよw
開発対象がどのハードのどのOSで動かすかによって決まるからな しかし、パラメータの意味も説明も無くいきなり数式出す奴ってなんなの？ >>451
それは理解していなさすぎる
実装継承とはある型(クラス)に対して定義したメソッドが別の型(クラス)に対して引き継がれることを指す
Rustに実装継承はない 継承はダメおじさん「継承はダメ」
IUnk教徒俺「うんこ->Release();」 >>453
「仕事で開発する人」ってのは仕事の多さに左右される
新規の言語はまずユーザー数を増やさないと
この先生きのこれない 多段継承は何だかなぁだけど
単純な基礎クラスに応用クラス乗せるくらいは許して欲しいなぁ >>454
Nってのは数
tは時間
cは定数
どれもよく使うから端折ったけども? >>457
だからユーザー数なんて増えないんだよw
その言語でしか開発出来ないスマホとかでも作らないとなw >>463
ならば進次郎にも分かる説明でないとダメだろ 仕事で使う技術選定の最大要因ってなんだかんだで利用者数の多さ（≒資料の多さ）になりがち >>470
そりゃお前が読めてないだけだよ
>>452の最後の1行も平易に同じことを書いているので読んでね C++の資料なんか腐るほどあるが
今やC#かCしか生き残って無いだろw Rustなんて使わなきや開発出来ないアプリなんか無いし
使う事は未来永劫無いだろうね Rust書けないからって嫉妬してるのはわかるけどそこまで逆恨みすることはないじゃん？ それともここで煽られたから「Rustを書いてる人」が嫌いなのかな？ >>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%程度（総本山なのに） もうすでに15%もあるといった考え方は？現状の％を並べても5年どうなるかわからないんだし。
その調べかたからわかるのことは限定的だな。
その割合が年々減っていってるのならRustはだめだろうし。 言語の変更は多くの場合システム改新などコードを書き換えるタイミングで行なわれる
また言語の変更をするか否かに関係なくモノリシックなシステムはシステム改新に不利でその点ではマイクロサービスなど多数で構成されるシステムが有利
OSカーネルやWebブラウザも同様でモノリシックに作られている場合は言語の変更に最も適していない
そのような最も適していない極端な特殊例を持ち出して数え上げることは無意味で無駄な行為 一眼観て微分方程式だと判らないレベルの人は黙っていて欲しい それはわかったけど、英語そんな読めない俺、なんも言えず
教えてもらったRustの再評価? 論文、積ん読になってるんだよねえ
面白そうだったから忘れたことはないけど >>444
一致してない
継承理解できずにアホな使い方する一部の人が勝手に騒いでるだけ
採り入れないとおまえみたいなのが無根拠に騒ぐからとりあえず採り入れてるだけ モダンなプログラミング言語のうち、
過去のしがらみのある2つの言語を除いて、
すべての言語が継承をクラスごと排除して採用していないもんな >>485
おかげで全てマイナー言語のままじゃん? 切捨ては極端すぎる。まるで都合の悪いことは無かったことにする左翼の思想
継承はあった方が便利なんだよ
元々オブシコは継承機能が売りだったのに手のひら返してやっぱ合成でいいって、それC言語でもできることだし…
先祖返り…デグレード…設計ミスってことぉ？ 2010年以降にできた言語で広く使われてるのは
Kotlin, Swift, Dart, TypeScriptらのクラス継承のある言語 型のgeneralization/specializationはどの言語でも必須と言っていい機能でspecializeされた型でgeneralな型の実装を再利用できるというのは物凄く直感的でわかりやすく便利な機能だから完全に無くせば利便性を損なうだけ
Rustでも形を変えて実装継承が存在するのはそのため >>489
実装継承は問題点が多すぎるからRustでは採用されていない
実装継承とはある型で定義されたメソッド実装がその型を継承する別の型にそのまま継承されること
Rustは実装継承をちゃんと排除している >>490
>実装継承とはある型で定義されたメソッド実装がその型を継承する別の型にそのまま継承されること
さすが進次郎
トートロジーが得意だな 継承が必須という人は>191 >195 >204に反論してくれんかね？
shared_ptr<function<T>>で、Tをコンセプトに拡張したものがイメージかね。コンセプトに合致する「インスタンス」なら何でも変数に代入できるようにできれば、わざわざ継承で「インスタンス」の代入可能性を確保する必要は無い。 >>492
継承で定義のコードを書く手間が減るだけでメリットになっている
デメリットうんぬんは使い方知らないだけ
使う場所間違えてる
以上
論破 >>493
ずいぶん貧弱な論破だなぁ。
>継承で定義のコードを書く手間が減る
そのために「事前にクラス継承関係をクラスに追加する」という余計な重たい依存関係を埋め込む必要があり、後々のインターフェイス設計に多大なコストが発生する。
依存関係低減のためにAdaptorを使うことになるなら、最初からインターフェイスにAdaptorみたいな機能があった方が良い。
>デメリットうんぬんは使い方知らないだけ使う場所間違えてる
あなたの感想ですか？ >>492
複オジはデメリットを真に理解してないから
どれレスでも的外れな内容になっている
>shared_ptr<function<T>>で、Tをコンセプトに拡張したものがイメージかね。コンセプトに合致する「インスタンス」なら何でも変数に代入できるようにできれば、わざわざ継承で「インスタンス」の代入可能性を確保する必要は無い。
継承の前にポリモーフィズムから勉強した方がよさそうだね
メリットとデメリットを理解してないというのは同じようだけど >>495
おいおい、まともな反論できなくなったらレッテル張りかよ。
>ポリモーフィズム
だからポリモーフィズムにサブタイピングは依存関係重すぎると言っているんだよ。
std::funcionを理解できていますか？ 記述量が多くなる＝悪は誰にでも判るだろう
RADが流行ったのも理解できるだろう
プログラマはいつも何を重視しているのか、それは時間だ
Rustでコンパイル通す時間よりC++でやった方が早かろう
C++でGUIアプリ作るよりC#でやった方が早かろう
さてRustでGUIアプリ作るには、一体どれだけ時間が掛かるのか
話は終わりだ >>492
必須とは考えてないから反論はしない
ユーザが選択できれば良いんだよ
言語としては装備していて
害悪があると考えるならそう考えるユーザが使わなければ良い
他言語のライブラリを移植する際に
使った方が再設計の手間が掛からないというなら使えば良い
マイナー言語のまま終わるぞ 数年でRustみたいな思想はAIが肩代わりしてくれると思うよ
今からRustで数年苦労するよりは
他の事しつつ待ってた方がもしかして有意義なんじゃないかな笑 >>494
その指摘のような状況で使わなければいいだけ
全てのケースでその指摘が当てはまるわけではない
不適切な使用をしてる例を自分自身で示しているが、それに気づいていない
言うに事欠いて私の感想？
何回論破されるのあなた？ >>497
別にRust推す訳じゃないが
その理屈はRustで簡単にGUIが描けるツールが出たら解消してしまうがな pythonのpysimpleguiでサクッと作って時間の掛かる処理だけpyo3でコールするか >>501
Rustが世に出て13年みたいだが解消する見込みなし
時間の浪費は罪に等しいと考える現実的なプログラマであれば他の手段を見つけてるだろう
何もかも遅すぎるのろまに構う価値はない >>505
electronかtauriをガワにして中身はHTML+TypeScript
今のGUIアプリは大抵これ
ちなみに新しいteamsではガワはネイティブ実装で
中身はWebView2というコンポーネントを使っているらしい
作り方はHTML+TypeScriptなのは変わらない
WebView2はまだ簡単には使えないがおそらくこいつが主流になるはず
MS好きならちゃんとキャッチアップくらいしとこうぜ？ 当たり前だが別にそれにしろとは言わん
シンプルな業務系の画面なら何でも良いし作りやすい方が良い
RustのGUIは今のところ有力なものはないのは事実 「マウス」のイベントハンドラを継承するメリットが誰にでもわかる
という前提が怪しいんだよ
マウスだぞマウス >>509
RustのGUIも色々揃っている
GUIは用途によって多種多様な世界だからeguiのようなリフレッシュフレームベースのGUIクレートもある
そういう用途でなければRust関係なく一般的な話として今は各プログラミング言語でGUI作るのは極少数派になっている
つまりHTML/CSS/JavaScriptベースで作られるようになっていて使用言語を強いて言えばJS/TSの時代 >>500
ならせめて「当てはまるわけではない」ケースを指摘しないと反論にならん。
「不適切な使用をしてる例を自分自身で示しているが、それに気づいていない」というのに指摘しないのは反論者として誠実でない。後出しじゃんけんを狙った詐欺師にしか見えん。 フィクションでもマウス的な小道具を無くそうとしてる
だから剣と魔法しかない >HTML/CSS/JavaScriptベースで作られるようになっていて使用言語を強いて言えばJS/TSの時代
そしてそれらは全て実装継承モリモリの実装に支えられている >>500
「その指摘のような状況で使わなければいいだけ」とか後出しジャンケンにもなっていないな。情報が空っぽすぎる。
無敵ジャンケン出して勝った気になるお子様みたい。 >>514
Reactはクラス止めて関数型のやり方に変えて
かなり経つよ あ、めっちゃ遅れレスだけど>>509に対して書いたつもりだった >>514
Reactは本体含めて継承は使っていない
全て関数 まあ今後のGUIはWebView2になるのは間違いなさそう
特にwindowsはこれが決定版になるはず >>512
ただ親クラスを継承して親クラスのメソッドを使うだけでしょ？
そんなことはどこにでもあるが、そのすべてがインターフェイス的に全てのメンバの実装が必須なケースになるのか？
ならない
なるケースはインターフェイスなど使えばいいだけ メンバ変数に直接アクセスするメリットはgetやsetを実装する時間を浪費しないことだが
継承のメリットはこれに類似している >>516,519
意味のない指摘をありがとう
ReactはHTML/CSS/JavaScriptを支える技術じゃなく
HTML/CSS/JavaScriptを活用した技術
ちなみにReactの本体では今でも実装継承使ってる
つまらない嘘はいい加減止めようね >>523
支える技術とか活用した技術とか意味不明すぎる マイコンレベルに小さなコンパイラを搭載しなければいけないような案件だとRustは重たすぎて無理っぽいが
それ以外のデメリットは無い感じはする。今のところ
FPGAの論理合成のような長いコンパイルプロセスに未来を感じる（感想） >>524
なんか日本語がおかしい
韓国人なんかな？ 英語圏で同じこと言われる不安を煽ってるから英語が苦手になるパターン 昔のReactはコンポーネントクラスというJavaScriptのクラスを用いた方法を用いていたけど
それでも継承は使わないでコンポジションを使うようにと公式に書かれていた
今のReactはクラスではなく関数コンポーネントを用いるようになった 継承はクラスの再利用とクラスの切り替えが同じ継承に集約
されていたのが問題だった >>531
コードの再利用とサブタイピングが一緒になっていたらなぜ問題なの？ クラスの切り替えとはキャストのことか
だがダックタイピング界隈には「キャストする」という振る舞いがない
templateなら引数を変えることが切り替えでありキャストは重要ではない
重要ではないものを重要と思ってたなら問題だ だからさ、独自用語で煙に巻いてないでTaPL読んだうえで共通語彙で話しようぜって >>521
親クラスを継承できないクラスはポリモーフィズムできないねぇ。
後から「読み取り専用のIFが欲しい」「書き込み専用が欲しい」となったらどうすんの？
「なるケースはインターフェイスなど使えばいいだけ」なら、途中で継承からIFに切り替える？
「早すぎる最適化」だなぁ さすがにその例だと、「モード切替するメソッドを足す。所有権管理もさせる。旧クラスは廃止」とかだろ >>537
だから「継承は重い。早すぎる最適化」なんだよ。
いつインターフェイスを確定するのは設計を煮詰めないと無理だから、設計初期に確定なんて不可能。 何で君達は最小のサンプルコードも書かずに俺様用語で議論してるの？
プログラマじゃないのかな？ 今朝のGoogleニュースで米の求人報酬だかでRustが2位とか見たわ
人事的にはRustで沼る人材が欲しいらしいぞ
良かったな >>536
そこら辺は言語によって違うからせめて言語くらい前提として共有しないと議論にならない。
親クラスを継承できないクラス、意味不明。
そもそもサンプルコード見せれば確実なところを自然言語で議論しようとする発想が意味わからない >>542
さすがに出先スマホでコード打ち込みたくないわな。
コードで言うなら>492みたいなのが欲しいというだけだし。
>親クラスを継承できないクラス、意味不明。
例えばライブラリが返すインスタンスのクラス。普通はクラスを直接弄ることはできないし、final宣言されてたら派生も無理。クラスを直接弄くれるとしても、ライブラリをメンテナンスするとか面倒臭いからやりたくない。
普通はAdoptor作るけど、それなら>492みたいなIF側で自動的にやる機能が欲しい。 githubの2023年成長率でもRustが40%増でTOPだったな。
でもまだ人気言語TOP10には食い込んでなかったけど。 >>541
日本だとマジで少ねえんだよな
ガッツリ使ってて将来性があるところならぜひ行きたい >>523
早くだせよコラ
適当いってんのはテメェだろクソが Rustが出せるのは高い信頼性だが、日本で何か作っても、それ信頼できんの?ってなるから
だったりして >>550
求められている信頼性って「Rustが出せる信頼性」とは違うんだと思うよ 日本だけに限らないかも知れないけど
ソフトウェアの利用者ってそもそも
何の言語で造ってるかなんて気にしてないし知ろうともしない Rustが使われる理由は高速省メモリで開発効率や保守性が良いため >>553それはRustプログラマの視点
それまでの話は発注者側からの話 発注者側の視点でも
高速省メモリで安全性も高いのはRustとなる 鶏と卵の関係になるけどプログラマが確保できなく保守性が悪い >>555
という願望
いいものなら売れるというナイーブな考えは捨てろ >>556
プログラムの保守性自体はRustが高くて好ましいため
あとはプログラマーの数は単調増加する一方なので特に問題なし >>558
プログラマが確保できないってことは
発注者側からすると運用後の保守に
支障を来すリクスがあるってことだよ コントリビューター増加「率」はミスリードかも、レポ増加「数」は
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 >>557
株とかはそうだね
いいものは誰にも教えないで買い占めるはず
商品化し売られているのは悪いものしかない説 >>562
お前がレスに使ってる端末は悪いものなんだな～。 >>564
自然言語で雑談ばっかりして
コーディングとコンパイルと実行をしない原因はこの端末かもしれないな >>533 >>548
嘘つきオジは「知ったかぶりして”Reactは本体含めて継承は使っていない全て関数”などという真っ赤なウソをついてすみませんでした」と言うのが先だろ >>563
全くしてないだろ
公開出来るソフトなんて業界の一部でしか無いからなぁ >>566
負けを認めろ
土下座したら許してやるぞ >>530
Reactはクラスコンポーネント時代も
開発元のFacebookが様々なケースで継承を使うとよいケースは存在していないことを確認しているとReact公式に書いていたもんな
もちろん今はクラスコンポーネントすら捨てて関数コンポーネント 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となります。 React本体のJavaScriptコードで継承が使われてるという事実は嘘つきオジがいたので指摘しただけで重要な事ではない
JavaScriptの継承を理解してる人ならリポジトリ見れば誰でもわかる
重要なのはReactやReact Nativeが依存しているHTML/CSS/JavaScriptなどのホスト環境が提供するGUIライブラリやそれに類するものは全て実装継承モリモリで作られているということ
それはなぜなのか？ >>570
Rustはもう何年もずーっと愛され続けてずーっと増加率もすごく高いのに
誰も使ってないのが不思議ｗ >>571
GitHubのコードに対するリンク一行貼るくらいやってよ >>575
エビデンスを出せという言葉を使えば公開されるという認識なんじゃないか
まるで魔法みたいに >>569
とFacebookの犬が申しております >>571
お前毎回遅レスなのは何なの？
回線がない生活保護施設にでも住んでるのか？ 特定のレスに妙に攻撃的な単発ちょくちょく湧いてくるのってやっぱりアイツ？ 質問する側は基本的に無力で、答える側に生殺与奪の権を握られる
一発逆転するには攻撃力か何かで優位に立たなければ 勝ったところで、所詮クソvsクソだぞ
面白いことを書け >>577
GTKは実装継承モリモリ
Cで実装継承を実現するためのオブジェクト管理システムをGTK用に作ってある
Reactの話とは関係ないけどね >>582
誰もが君のように暇なわけではないんだよ
つかそんなにレスが欲しかったのかよw >>590
そういう返答するだろうなあと思ってたよ
言語機能になくても実装で継承使われてるんだ～
というならどんな言語使っても構わないね
はい終了 Cはスマポ<T>を作れない
C++でもtemplateを使わない主義ならばスマポのようなものをTが実装継承するかも >>592
論点は実装継承は不要なのかどうか
常にコンポジションを使うべきかどうか
GTKは言語機能によらない実装継承を使っているというだけ
コンポジションで実装する事も技術的には当然可能だがその選択をしてないことに意味がある
特に言語が提供してないにもかかわらずGTKのためだけに継承機能をわざわざ作り上げるほど実装継承を欲した理由を理解するべき Reactが依存しているHTMLのボタン要素を例に話をするとボタン要素は次のような型階層を取ることがDOM APIの仕様で決められている
EventTarget <- Node <- Element <- HTMLElement <- HTMLButtonElement
上位の型のパブリックなメソッドやプロパティはや下位の型でも使えるようにする必要がある
これは実装継承だけでなくコンポジション+インターフェースでもRustのenumのような代数データ型を使っても実現可能なんだが知る限り全てのブラウザが実装継承を使って実装している >>594
言語機能になくても問題はないんだから
言語の機能比較という論点からは
どうでもいい話だね なぜかというと
例えば仕様変更でNodeに新しいメソッドが追加されたとしても実装継承なら一箇所変更すればいいだけだから
コンポジション+インターフェースの場合はNode以下の数百個のクラスや構造体にメソッドを追加して委譲するコードを書いて回らないといけない
実装継承というのはサブタイピングとコードの再利用を同時に行うことだが、その2つを同時に行えるという点が最大のメリットであり存在理由なわけ >>596
問題がないわけではないんだよ
GTKの実装継承は言語機能のそれと比べてクソ面倒臭い上に言語に組み込まれた型システムではないからこその弱さがある
Rustでも実装継承をマクロで模倣することもできるがだからといってそれに何の問題ないわけではないというのと同じ
他のやり方があったとしてもより楽に安全に開発できるようになるなら言語機能としてあった方がいいってことになるよね？ >>597
それは仕様変更前のクラス数百個を捨てさせ変更後の数百個で置き換えるには都合が良い
一箇所変更するだけで古いクラス数百個が消滅する
だが古いクラスに依存していた資産が消滅するのは本当にお得なのか？ >>590
はよReactの実装継承について参考にすべき
ファイルとかだしてくれ >>598
> 他のやり方があったとしてもより楽に安全に開発できるようになるなら言語機能としてあった方がいいってことになるよね？
c++に色々跳ね返ってきそうなお言葉来たな 「GCは嫌い。だけどC++は苦手。
噂だとRustがそれを解決するらしいから」
ということでRust票が入っているだけ。 GoogleもMicrosoftもAmazonもCloudflareも
そんな理由でRustを採用して使っている？ 結局windows11 10.0.22631.2715 (23H2)にRust製モジュール入らなかったが >>600
>だが古いクラスに依存していた資産が消滅するのは本当にお得なのか？
消滅しないよ >>604
信用できないアホコーダーにはバグを入れる自由なんて与えない。
コーティング規約だと防ぎきれないから抜け道の少ないRustにする。
ということだろ。 関数名の重複を許す仕組みは信用できる
クラスは名前がかぶったらたいてい古い方が無かったことにされるのが信用できない >>603
C++苦手でRustなら大丈夫！って人種は居るのかな
さらに苦労しそうだけど intは信用できないのでi32やi64になったのはまあいい
実装継承の祖先の名前がずらりと並ぶのは嫌だ >>612
それは実装継承による設計をする古い頭のままの駄目プログラマーの典型例 >>611
いるよワイ
とにかくC++はコピーを正しく扱うのがあまりにも難しいのよ
C++の弱点はこの一点に尽きる
もちろんCとの互換性を保つためなのだが本当に難しい
そこにコピーやめたろ！って英断したRustは本当にC++使いの人が設計したんだなと感じる
この部分に手を入れかつ速度を落とさない実装もできる方法を突き詰めるとこうなる >>614
Firefoxはservoで行き詰ったよ Effective C++の初版はほぼこのコピーをいかにうまくやるかを解説した本だった
あらゆる手段でコピーが発生してもオブジェクトの整合性が取れるように注意点を書きまくった
しかしその内容はあまりにも普通の人には難し過ぎた
そして一つのクラスを作るたびにこんなに気をつけて実装しないといけないのか！やってられん！となって
その結果、もう全部ヒープにとって生ポインタでいいじゃんとなってしまった
そのおかげでコピー問題は無くなったが
メモリリークや二重開放、ヌルポの山を産んだ ポインターをメンバーに持つと言うのがコピーの問題になってるだけやん？
アドレスをコピーするのか、実体を複製して新しいポインターとして格納するのか
用途によってはどちらかが不都合だったりするからなぁ >>617
実態を持っても同じだよ
そのオブジェクトが内部にポインタを持ってたら同じ問題が発生
さらにそのオブジェクトが(ry
というわけで地獄のような連鎖になることがわかる
そして厄介なのは自分が作っていないクラスだった場合お手上げということ
いかにやばいか分かっていただけただろうか
だから一時期はあらゆるオブジェクトがヒープ割り当てをしていた スマートポインタによって状況はだいぶ改善されたとは思うが
しかしこのコピー問題というのは常に残っているのだ
そのオブジェクトを安全にコピーできるようにするという本質的な難しさは変わっていない
そしてムーブかコピーかみたいなものをライブラリ提供者が決めなければならず
それを使う側が意識することはかなり難しい
ドキュメントを読み込んで使い方を熟読するしかない
数百個のクラスがあった場合その全てのクラスの性質を暗記しないといけないのである！
しかも一個のミスで全てが崩壊する
こんなことは不可能に近い その結果全てのオブジェクトをヒープにとってそのポインタだけを持ち回る、という実装がほとんどとなったのである
こうすればとりあえずコピーに関する問題はなくなる
俺はその時期にC++を仕事で書いていた
全てのオブジェクトがヒープにあった
コピーに関して悩んだことがなかったので
Effective C++を読んでもこの本は何でこんな「不整合が起きないオブジェクト」の作り方の解説ばっかりやってるんだろうと思っていたぐらいだ ちなみにこの全てのオブジェクトをヒープに取ればいいじゃんの思想をデフォルトにした言語がJavaである
メモリの解放漏れはGCにより問題なくなったがヌルポを量産したのは言うまでもない ChatGPTとまでは言わんが、IDEも仕事しろ、っていう世の中ではある >>615
金がなくなっただけでスポンサーついたら復活した >>623
稼働してるの2~3人だけど当時よりは整ったはずだから今度は完成するよね？
とりあえず年内にtableタグが実装だっけ？ Javaにはポインタしかない
ゆえにコンポジションを繰り返せばリンクリストのようになる
でも実装継承なら
という風に二つの問題は一つにつながる >>616
Effective C++がコピーの話ばっかりという印象はないけどな
あるのはもともとCにあるコピー問題をいかにC++で解決するかというスタンスの解説
あとコピー問題を解決するためヒープを使うってのも謎理論
それは因果関係逆でしょ
ポインタをメンバーに持つデータ構造のコピーをいかに安全に実現するかでしょ
STLコンテナによりそこに厳密な意味定義が必要となった >>621
ヌルポは型無しnullpointerによる型の制約に違反する問題だろ。
スタックだろうがヒープだろうが型無しインスタンスを使う限り発生する。
c++もポインタを排除して参照のみにできれば随分違うだろうけど。 中途半端に浅いコピーは、深い方が正しい可能性を否定できない
これがコピー問題
ヒープを使えば極端に浅いコピーになる
これはバグではなく意図的にしか見えないから問題が解消する 機能追加が常に善なら後発言語は機能お化けに
なる一方のはずだがそうはなってないので
〇〇言語には△△機能が無いからゴミという
論法はあまり意味がない >>627
だからお前は何でそんな遅レスなんだよw
遅レスおじさん登場〜👴 >>631
C++のよろしくない点で一番言われるのは、長い歴史といろんなパラダイムを取り込みまくったことで
まさに機能お化けになっちゃったことだからな >>631
>機能追加が常に善なら
誰もそんなことは言ってないから
それこそ意味のない論法 >>635
誰かがそういう主張しているという文章じゃ
ないんだが
頭悪いな 実装継承不要とか言ってたやつら負けるの早すぎだろ
拍子抜けもいいところ いや。参考になったから、それはそれでいいぞ(IUnk派 Reactの継承を使っているコードを出せない時点で負け犬はどっちか明確
強い言葉使ってやるからかかってこい 「Reactは本体含めて継承は一切使っておらず、全て関数だと言い張る人がいるのですが本当でしょうか？」と
自分の主張ではないフリしてStack Overflowあたりで聞いてみ？
めっちゃ馬鹿にされるだろうけどすぐに欲しがってる答えをもらえるぞw プロトタイプ継承もわかってないのに事あるごとにReact連呼してたのかと思うと滑稽を通り越してちょっと可哀想 はよそのコードを出せよ
それも出せないくせに偉そうに御託をごちゃごちゃ言う
偉そうに自分語りするくせに的外れ
虫唾が走る 継承はプログラミングスタイルとして決定が多いため
モダンな各プログラミング言語で継承が不採用となっただけでなく
Reactでも継承を使わずに済むように進化してきたのよ おーいまた遅レスかー？
快活クラブから出ちゃったのー？ >>644
多分そういう意味すらわかってないと思うよ
プロトタイプ継承がどうとかそんな話とカンケーないのにな
とっととReactのリポジトリクローンしてgrepすりゃわかるのに
何でその程度のことができないのか src/foo/bar.jsの124行目見てどう思うプギャー
とやればいいだけなのになぜかやらない >>629
それは理解がおかしい
浅い深いのコピーの分類ではうまくいかなかったのが歴史
それが所有権の概念とムーブセマンティクスの導入で整理されたのが今の状態
浅いと言っていたのがムーブで深いのがコピー
ヒープがどうのこうのってのは間接的なこと
そもそもヒープが単一って前提もc++にはない >>634
まぁ判断は難しいね
下手に表現力が高かったがために、一見言語組み込みでやるべきものの多くがユーザー側で実現されてきた
様々なテクニックが発見され発展速度向上には寄与しただろうが一方で深い考察のなく導入された結果仕様の複雑さを招いた
個人的にはエラーメッセージ見ても何が悪いのかすぐに理解できない代物になったのは許せないね C++のテンプレートはCのマクロ文化を止めたかったんでしょ
メタプロガチ勢が頑張りすぎてカオスになったけど功績は大きいと思う ディープコピーを知らずに盛大に恥を晒した某オジがコピーについて語るとか世も末だなw テンプレートはコンテナを矛盾なく書くのがめちゃくちゃ難しいのよ
まず要素の型が実体とポインタ両方に対してうまく動くようにするのは至難の業
例のコピー可能オブジェクトの話とも絡んできて「無理」となる
この辺Rustはよくできてる
イテレータが可変参照なのか共有参照なのか、実体なのかによってきちんと分けられている
C++で困った部分を完全に解決してくれてる
Rust素晴らしい >>652
>テンプレートはコンテナを矛盾なく書くのがめちゃくちゃ難しいのよ
>まず要素の型が実体とポインタ両方に対してうまく動くようにするのは至難の業
STLで何か問題でも? そりゃSTLで満足してる間はそれでいいだろ
アロケーターを指定したことないだろ？ むかしはSTLがない環境も多かったからね
windows環境ではクソ遅かったせいか
完全にないものと扱う奴さえいた >>654,655
じゃ今のSTLは問題ないで良いのかな? >>652
そこに加えてRustはスタック領域も扱えるからさらにヒープ使用を減らせるところ 問題ないと問われればあるだろうね
ただよく訓練されたC++使いは気に入らないと文句を垂れても仕方ない事もよく理解してるから
その環境で可能な別の手段を用いるだけだよ >>658
曖昧なことしか書かんのだな
問題あるならどのような問題かを短いサンプルコードで具体化してよ どのような問題かなんて別の手段で解決した後に覚えてるわけないじゃん
何でも欲しがりさんには判らないか >>660
示せないなら問題あるなんて言ってはいかんだろうよ? C++はSTLを一応擁しているけど、各プロジェクトで、もうちょっと軽量で自分とこ向きのコンテナ持ってるとこが多い
異論は認める >>662
でその自作コンテナを矛盾なく書くのがめちゃくちゃ難しいとな?
今のSTLは問題ないで良い? 俺はSTLが重厚すぎて自分の手に負えないと思ってるので、なんとも。
STLにもバリエーションがあるのは承知していて、あんまり幅広く試せてないってのも。
ただし、依存(include)してるプロジェクトは当然あるし、試作には便利なので、ないのは困る。 >>652
要素の型が実体とポインタ両方に対してうまく動くようにする
それはポインタを部分特殊化しろ、ということでは？ >>663
同意を求めるなよw
お前の用途ではSTLで十分ってだけ
そうじゃない場合もある
STLで足りるならboostもEASTLも存在してない >>666
>>652
>テンプレートはコンテナを矛盾なく書くのがめちゃくちゃ難しいのよ
>まず要素の型が実体とポインタ両方に対してうまく動くようにするのは至難の業
これがいったい何のことを言っているのか分からんので
STLで問題を指摘させれば共通の題材として議論できるからSLT取り上げた 全然伸びてなくて草
こんな過疎スレで敗走したからって嫌儲民おらに力を分けてくれーーってやろうとしたけど
そこでも無視されてる
情けない奴だ
だからゴミクズなんだよ >>671
そもそも前半の話いる？w
的外れ過ぎて意味のない指摘だよ いくらめんどくさくても安全のお守りがほしいんすわ
C++製システムがクラッシュしてうなだれたあの日の鬱憤が安全を求めるんすわ >>671
何故この手のやからって、
自分は今まで大丈夫だったから他の人(今度の新卒社員とか)も大丈夫に違いないと思えるんだろうか。
いつも一人で仕事してるのかな。 >>671
その人はRustを知らなすぎるな
C++はインラインアセンブリがある云々もRustにもあるし
算術ラッピング演算の件もRustはラッピングの有無両方が用意されてるのを知らずに書いていたり めっちゃ感想来てるｗ
俺は読まずに貼った、おもしろそうだったから
[Roast Me] って付いてたので、異論は認める系の日記かなって思ってた
仕事終わったら俺も読む 気にしないから感想はご自由に >>674
わかる。他人の書いたC++ライブラリがめっちゃメモリリークする時とかそう思うわ 元記事に英語でコメント付けに行くことはしい内弁慶たちであった 使うなと言ってもバカはクラス継承をどうしても使いたがって質を下げるため
モダンなプログラミング言語は一斉にクラスごと言語から排除した そうそうバカはclassやextendを無くせば実装継承が無くなったと勘違いするからバカに気づかれないようにカモフラージュして実装してバカが無節操に使わないようにしてるんだよなぁ そうしてマイナー言語マニアの思い出の一つとして
長く記憶に留まる言語となるであろう >他人の書いたC++ライブラリがめっちゃメモリリークする
某OSのAPIのことですね判ります >>685
サブタイピング時に
上位の型が持つ実装コードの一部が
下位の型と共有されること OSにバグがあって後処理をしてもOSがリソースを掴みっぱなしになるといった経験はないだろうか。
そういった場合そのリソースを使う箇所だけ子プロセスとして隔離し、使い終わったらそのプロセスを終了する事でリソースを完全に開放させることが可能だ。
このプロセスの隔離はかなり万能な解決方法で、納期が短くて怪しいと思っても修正が困難なケースにも応用可能だ。
まあ要するにリークを疑われる場合一旦別プロセスにすれば必ず開放されるからリークは必ずしも怖くないよって話。 と、御社の現お取引先ホームページにありますね。
弊社はRust採用実績十分、リークは原則としてありません Rustはモダンな言語の一つなので
その定義でもRustは実装継承を持たずきちんと排除している >>689
OSのバグならアプリのプロセスを落としたところでリソースが解放されるとは限らない
プロセス落とすのはどちらかと言うとアプリのバグに対処するため >一旦別プロセスにすれば必ず開放される
doubt すくなくともWindowsは長期間起動し続けると空きメモリが減っていく
OSが意図的に開放せずにキャッシュしてるのかリークなのかは分からないが >>689
子プロレス切り離しが大仕事だろ
そこで別のバグが大量に入り込む
全然簡単な話じゃない
お前言うだけでやったことないだろ 俺が遭遇したのは2件で、どちらもOSの不具合という結論だよ
MSのナレッジに残ってるかもしれないがどっちもプロセスを終了するしか解決策が示されなかった
>>699
こういう理不尽に遭遇して回避策が示されたなら大仕事でもやらざるを得ないと思うけどね
別に難しいって程でもないし そういや別件でOSが設定しているタイムアウト値を待てない場合も別プロセスにして回避した事がある
この板って年寄りばかりだろうしWindowsのプログラミング長年やってれば何度かそういう事に遭遇するんじゃないの あのね、年寄りが真面目に答えてやるとOSの観点から言うと
windowsとLinuxじゃプロセスの考え方が結構違ってて
Linuxの場合、バックグラウンドプロセスっていうのは普通に使われまくってるの
いわゆるプロセスのクローンだから扱いが楽
シェルから作れるし
一方windowsではexeなんでクソ重い上に扱いが面倒
データ共有やプロセス間通信も一苦労だ
だからwindowsではLinuxっぽいバックグラウンド処理はスレッドを使う
windowsにおいてスレッドの方が軽い
一方Linuxではスレッドもプロセスも本質的に同じ
(カーネルの構造体thread_structはプロセス生成の時も使う)
よってプログラミングモデルがだいぶ違うため
どうすべきか？はかなり違う
以上がwindowsでもLinuxでも並行処理を書いてきた俺の感想 Windowsはプロセスもスレッドも、互換性チェックみたいのが重厚らしく超高コスト
さらに、セキュリティソフトが走ってるのが当たり前の世界なので、ファイルハンドルも高コスト
なんでもWSL2でやったほうが軽い? らしい
てことで、コルーチンはいいぞｗ Rustの東京を使えばデフォルトでCPUのコアスレッド数をフル活用してコルーチンを何万も同時に動かせますものね Elixir は、10万もの小プロセスを起動できる
Go の並行処理も、mattn の本に書いてあるけど、
C で、100スレッドを起動したら、
CPU 使用率が高く、12秒も掛かったが、
Goで100 goroutine を起動したら、
6スレッドしか起動せず、9秒で済んだ
Goの方が、CPUコアを効率的に使える とにかく、スレッドを起動したらダメ！
CPU コアや時間の大半が、起動処理に使われるから とはいえコルーチンって使い所が難しいのよ
流行りそうで流行らないのがその理由
結局「本当の並列性が必要ないようなすぐ終わる処理を大量にする」ユースケースにしか使えないから
こういう処理ってあまりないことに気がつく
まず真の並列性が必要となる数値計算では使えない
処理の中でブロックするとダメなのでその判断も難しい
よって普通の言語では使うのが難しい >>706
使いたければc/c++にはむっかしからコルーチンにファイバーがあるから
native言語なんだからosの資源使う上で不利になるはずない >>706
＞Goの方が、CPUコアを効率的に使える
そう主張したかったら根拠を示さないとね
例えば逆の根拠として
Go各のgoroutineは別々の各々のスタック領域を必要とするけど
Rustはスタックレスなコルーチンだから必要とせずその分だけ効率的だね おれの作成したソフトは起動時に64個のスレッドを立ち上げているが常にサクサクだ >>701
それどころかプロセスを完全に終了させても解放されないリソースが残ることがある
OSを再起動してやっと治る
こんなもんOSのバグとしか言いようがない >>702
あるね
>>699 こそやったこと無い香具師だと感じる >>703
Windowsにforkがあれば良かったと思うことは何度かある ああでも
>>703
>一方windowsではexeなんでクソ重い上に扱いが面倒
>データ共有やプロセス間通信も一苦労だ
>だからwindowsではLinuxっぽいバックグラウンド処理はスレッドを使う
ここは完全に間違ってるよ >>706
>C で、100スレッドを起動したら、
>CPU 使用率が高く、12秒も掛かったが、
>
>Goで100 goroutine を起動したら、
>6スレッドしか起動せず、9秒で済んだ
可笑しな理屈だな
スレッド数で比較するならgoでも100スレッド使って比較するか
Cの方でスレッド数増やさないCで描いたコルーチンで比較するべきだろ プロセスを分けて独立したメモリ空間の単位で障害を切り離して耐障害性を高めるのは昔からよく使われる方法だけどこれはスレッドやコルーチンでは代用できない
並行性を高める目的ならコルーチン+スレッドプールが最も効率が良い
C++やRustはまだまだ使いにくいけどGoやC#やSwiftのように使いやすいAPIが用意されれば誰もが当たり前のように使うようになる >>717
ある程度時間がかかる処理を並行で動かすという面でこれほど楽で使いやすいものはないしね
windowsへの移植性を上げるためにはforkを捨てなきゃならんのはかなり厳しい fork移植されてると思うけどそういう話ではなく？ 遅くともcygwinとかで、なんちゃってforkは実装されてるけど、コレジャナイ感は付きまとうんだよな(個人の感想です execなしのforkなんて時代錯誤もいいところ
いまだに使ってるやついんのか？
さっさと引退するのが世のために RubyもNotImplementedError
Perlはエミュレーションしてるがすでに非推奨レベル こんどはforkを取り囲んでフェルマータするターンか forkは同じページを（書き換えるまで）共有できるのが売りだと思うけどwin版は最初からコピーするのか
そんな実装でfork爆弾作れるの？ オジジジジジｗ
https://medaka.5ch.net/test/read.cgi/prog/1619943288/667
667: 仕様書無しさん 2023/11/24(金) 01:57:39.09
>>665
C++のスマポは機能が弱すぎてできないことが多すぎる
例えばヒープ領域しか指せないから
(L1キャッシュ効果と領域確保解放コスト無しで高速な)スタック領域の活用がスマポではできない スタック領域をスマートポインタで指す必要はあるの? 先々で、うっかりfreeするような書き方してしまったときにコンパイルエラーで止まってほしい
実体としては生ポだけど、チェック用の何かにラップされてる…そういうスマポ いつものように誰かが書いてた受け売りで中身は理解してないんだろ
少し突っ込まれたら表面的なことを繰り返す壊れたレコードになる www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf Rustはヒープ領域だけでなくスタック領域にまで所有権やムーブや参照の概念を拡張したことから
C++よりスタック領域の活用で効率的になってる話ではないか >>738
単に「何でもスタックに積む」というだけでは？
ヒープはVec Box使わないと確保できないんじゃなかったっけ。 C++は書くのがしんどい
Rustもしんどいけど、生成AIに書かせたコードもコンパイルとテスト通ればメモリリークの心配なく使えるので気持ちは楽 Boxってヒープのメモリどうやって管理してんの？スコープ？ >>734
ほんそれ
同じ香具師なんだろうバレバレ >>742
unique ptrみたいな感じじゃない？ >>736
自分なりには考えてみてるんだけどね
ベーシックな車輪くらい、削り出せなきゃいけない
ダサいので試してるってのは他言はしないけどね ここくらいだ >>738
また嘘言ってる
Rustはヒープ領域だけでなくスタック領域にまで所有権やムーブや参照の概念を拡張したことから
C++よりスタック領域の活用で非効率的になってる
>>741
お前は死んだ方が良い Rustの所有権チェックって、(コンパイル時にコストを寄せてるから)実行時はゼロコストじゃないん
へたくそに書いたら効率が下がる(たいてい実装効率が上がった犠牲)のは、C/C++も同じ 技術的選択というのは最終的には必ずトレードオフになるので
ある選択のプラス面だけしか見ない/考えない/認識できないやつは何やらせてもダメ 新人やお前らの前任の調子いいだけの奴がコンパイル通したコードで、rustとc++のどっちが安心できるかってことよ。 c++に自動変数専用参照とかあるといいんだけどなぁ。
自動変数にあるスマートポインタは参照渡ししたい。 >>751
イマイチ分からんのだがコードで書ける? >>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); //次のスタックフレームに渡すのも合法
} >>755
あ、最後は
foo(pptr);
だわ。 メモリがスタックにあるかヒープにあるかはリンカのアドレスマップと連携すればわかる
つまり欲しいなら自作すればいいのでは >>757
え？リンクでこねこにすればshared_ptrのカウンタを増減させなくて済むようになるんかね？
そういう最適化しているリンカとかあるの？ さっぱり意味が分からんのだけど
もしかしてshared_ptr&&&なる存在に参照されたshared_ptr<T>だけはスタック上にTを保持する何者かに化けろと要求している？？ クラスは必ずnewしないといけないと思いこんでいた昔のワイみたいな勘違いしてそう >>759
全然違う。
shared_ptr&&&なる存在には自動変数にあるshared_ptrだけしか代入できなくて、左辺値とかヒープにあるインスタンスを代入しようとするとコンパイル時にエラーになるだけだよ。
>>760
呼び出し元の方にあるスタックフレームに保存されている自動変数は、スタックフレームのLIFOを破壊しない限り存在を保証できる。そういう自動変数を呼び出し先から安全に参照したいだけだよ。 >>762
自動変数にあるshared_ptrは左辺値だが そもそも参照に対して行えるのは代入ではなく初期化だし 無知ばっかりでここまで話が通じないと思わなんだ
スタックやヒープの開始アドレスがどこから始まるとか気にしたことないの？
rustの悪いとこ透けて見えたわ Rustならそんな複雑なことする必要もなく
Rustの方が優れている
ライフタイムさえ満たせば参照先がヒープかスタックか関係なく同一コードでその参照を安全に返す関数などを書くことができる >>765
>>751 や
>>755 と話繋がってないけど。
スタックやヒープの始まりは >>755 のコードでも >>751 の要件でもわからんやん。 いまいちメリットがわからない
ヒープのオブジェクトなら渡す前に呼び出し側でチェックすべきなのではないのか >>757
どのOSも汎用的に判別できる方法はない
(組み込みは除く) Rust推してる香具師はスタックとヒープの違いも判ってないのか 関数の定義で、shared ptr の参照を安全に受け付ける仮引数の定義方法とかあるの？
効率化のためにインスタンスのコピーは無しの方向で。 >>773
スタックの頭知りたかったらコマンドライン引数のアドレス取れば？ヒープの頭知りたかったら最初にsbrk(0)すれば？ >>765
それでコンパイル時にエラーにできるのかい？ >>775
「安全に受け付ける」の定義は？
特に何をもって「安全」と言ってるのか >>776
これだと実行時だわ、コンパイル時にはわからんわスマン。
ってか何でコンパイル時にスタックやヒープの先頭アドレス知りたいのかわからん。
リンクしないでなんてわかりようも無いし。 rustはヒープとスタックを言語的に区別してライフタイムをトラックしてるだろ
それが欲しいならrust使えで終わり
c++では汎用的には無理
そういう要望は昔からある >>778
そりゃ、関数を実行している間は参照先が無効にならないことですな。 そもそもスタックに参照カウンタ必要か？
関数に対するスタックはプロセスに対するグローバル領域とライフタイムの考え方は同じ。
関数を抜けるまではスタックは有効だし、その関数以降に呼んだ関数が呼出元の関数を抜けた後も握り続ける状況は発生しえない
(別スレッドに共有したりヒープにCopy/Moveしない限りは)からshared_ptrにする必要がないと思うが。
つまり、
T x; // スタック
shared_ptr<T> x; // ヒープ
で型が異なるから、強引にCopy/Moveしなけりゃコンパイルエラーで検出できるし問題は起きない。 >>755 はいまいちよくわからんが、ポインタを受け取る関数側でスタックかヒープを判別したいんだろ
かつてそれを解決するため手法としてregion based memory managementが開発された
rustのライフタイム管理の源流 >>773
Rustでsafeにヒープが使われるのはBoxとVecおよびそれらが組み込まれた型のみなのでヒープかスタックか明確に区別がつく
>>780
参照になった時点でヒープかスタックかの区別なくライフタイムのみで安全に扱えるところがRustの勝因かな
スタック領域を指す参照についても関数から返してよい参照と返してはいけない参照の区別がライフタイムでなされる 例が微妙だな。直しておくか。
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); //次のスタックフレームに渡すのも合法
} >>785
shared_ptr<T>を使うから意味が不明なんだよ
Tが置かれる場所がスタックかヒープかなんだろ？ void foo(T& p){}
void foo(shared_ptr<T>& p){static_assert} >>773
スタックとヒープの違いが分かってなくても使えるなんて、なんて素晴らしい言語なんだ もういいよ
議論するレベルになってない
引っ掻き回したいだけだろ
この話題終わり
ゴミだから >>786
違う。
「shared ptr」の置かれている場所がスタックかヒープか。この場合だとTはヒープ。
>>785はとりあえず「shared ptrが」自動変数にある場合だけエラーにならないのを想定。 >>791
shared_ptrの参照カウントの操作を省きたいならshared_ptrの参照渡すか生ポインタ渡せばいいだろ
それかrustにしろ 「lvalueよりさらに限定された値カテゴリを作って、それだけを指せる参照を導入したい」という欲求
もしかして: ライフタイム ヒープを排除したいのは参照してる間にfree/deleteされるのを気にしてるからかな
Rustだとライフタイムというよりborrow checkで解決してる問題 >>795
そこでborrow checkerが具体的にしていることがライフタイムの妥当性(やミュータビリティの妥当性など) >>781
ポイントしてる先がどうなってるかは関係なくてshared_ptr自体がスタック上で生きていれば「shared_ptrへの参照」は無効にならないということを「安全」だと言ってるという理解でいい？ >795 >797
そういう話。
RustだとRc<T>の参照をbollow checkerで(たしか)安全に管理できたけど、c++はshared ptr の参照なんて気にもしないで破棄するから、せめて自動変数に置くことを強制しできればちょっとだけ安全に効率化できるのにな、ぐらいの話。 RustのRcもC++のshared_ptrも参照でやり取りするより
Rc本体をclone（C++なら値渡しでコピー）した方が使いやすいと思う
中身じゃなく本体を参照渡しするなら参照カウンタ増えないしRc（shared_ptr）使う意味がなさそう
shared_ptrは元データが破棄されてもコピーが生き残ることに意味があるわけで
この例でshared_ptrを使われると話がややこしくなる >>798
なるほどそういうことならAST的なものに対してカスタムルールを定義できる静的解析ツールみたいなもので頑張ればチェックはできそう
ただポイント先が途中で変化しても安全と言えるかどうか微妙
Arc/Rcはownerが複数いる場合はポイント先が変更されないことも保証されてる ライフタイムチェックが今のRustと同じレベルになるのは早くてもC++32以降なので過度に期待せず気長にお待ち下さい。 >>791
その理屈だと
>>784 も頓珍漢なこと言ってる 的はずれなことを書いてる自覚がないとはな
複オジ(>>784)のほうが多少自覚してるだけマシかもしれんぞ >>800
自作でやるならかなり大変で、自作言語作るのと工数変わらないかも。
それならRust使ったほうが楽かね。 >>801
サポートするとC++ではなくなってしまう
別言語を同居させたようになり混乱が増す C++はもうテンプレートで道を一度踏み外してる外道だから今更だよ Javaからプログラム始めたからC++の静的ポリモーフィズムやるconceptの制約がわかりにくすぎて使いこなせん
C++20のconceptを使いこなせてる猛者さん、果たしてスレにおるのかね C++で継承をやろうとするのが間違いなんだよね😇
テンプレートはゴミ！
ゴミなんです！ C++使ってるけど継承もテンプレートも使ってないな 最近新プロジェクトでC++書かなきゃいけなくてRust使いたがったが
外部システムやライブラリとの絡みで仕方なくC++を使うことになったのだけど
std::shared_ptr
std::weak_ptr
std::move
ムーブ代入演算子
ムーブコンストラクタ
enum class
constexpr(主に設定値のテーブル初期化などに使う)
新しい要素だとマジでこれだけしか使ってなかったよ
継承なしテンプレートなし
外部ライブラリとしてonetbbとminimalloc使ってるだけ
これだけでもそこそこモダンなプログラミングができる
あと足りないのはライフタイムだけかな
C++にそれがきたらRustはいらないけど果たしていつになるのか shared_ptr使ったならテンプレートなしは言いすぎかな
自作テンプレートなしってところか
テンプレートはライブラリとか裏方向けの要素だからアプリ開発ではあまり使わないかも 自作テンプレートって意味だろ
文脈理解できないんだな
全部書かなきゃ理解できないタイプ？ このスレはﾜｯﾁｮｲ必要だねえ
次スレの1の本文先頭に以下を追加しといてね
!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
(新スレ立ての際上記コマンドを2行書き込んでください) わかる 裏方向けっていうか、裏方モードのときだね
アプリ開発してる最中に、ややこしいクラスライブラリを内製してる…ばっかりでもない 人殴ったりはしないけど、アホなこと書いたりはしちゃうんだよねえ(無知を晒す自爆型)
1日経ったらチャラになってくれたほうが気は楽 じゃあベアメタルではヒープとスタックはどうなるの？ マイコンいろいろ買ってみたけど、結局デスクトップばかりいじってる俺、なんとも言えずｗ RVOにより呼び出し元でスタック領域を確保できつつ
Rustのようにスタック領域に対しても自動的にライフタイム管理ができていれば
コストの高いヒープ領域利用を可能な限り減らしつつ
スタック領域を指す参照(ポインタ)を返したり他へ埋め込んだりしていても安全に使える
というシンプルな話 C++もRustもベアメタルという土俵で真価を問われると思うよ
小型軽量ガジェットでAIを高速に処理出る言語に需要があると思ってる。 Rust使ってるとヒープ領域はスタック上のどこかの変数の運命共同体って感覚になるから
ヒープだからコストが高いって言われると何か違和感がある
Box（ヒープ配置）にするかしないかでたまに迷うけど
【スタック領域】
・サイズが固定
・確保、解放のオーバーヘッドがない
・スタック上で頻繁にコピーされるからでかいと不利
【ヒープ領域】
・サイズが自由
・確保、解放のオーバーヘッドがある
・基本的に移動しないからでかいときに有利
みたいなイメージで使い分けてる
スタック／ヒープだから安全／危険とかは特にないな >>835
>>・スタック上で頻繁にコピーされるからでかいと不利
意図的に移動しない限りコピーはされない
ヒープと同じで基本的に移動の必要はない
唯一コピーが起きそうに見える関数返しによる初期化はRVOによりコピーされない
ヒープと同じで確保後はそこへの参照のみ扱うため移動コピーは起きない Result型とかOk(T)とErr(E)のTとEが同じ場所に置かれそうだけどRVO機能するのかな
真面目に調べたことないけどあまり当てにしてない
最適化で適用されたらラッキーくらいの感覚 まあRustはこのまま死ぬんだからどうでもよくね？ >>833-834
ハンドヘルドとはいえ、64bitレジスタ当然、メモリもギガバイト当然、ってそんなの組み込みっていうんかｗ
// てなことだと思う >>835
NGワードかもしれんが
stackのメリットは基本的にGCのこと気にしなくて良くなる感覚 たまにバカでかいオブジェクトをスタックに置くやつが現れるが
スタックは一度伸びたらするスレッド死ぬまで開放されないからメモリ無駄遣いになる
組み込みやコンソールゲーム作ってるとこだとスタックに置けるオブジェクトのサイズの制限決めてるとこあると思うけどチェックがムズいよな
昔仕事でライブラリ開発したときは最大スタック消費量が仕様で決まってた
バグフィクスでもその上限超えてはならない >>813
そりゃ、テンプレートとかは基本ライブラリアン向けの機能で、コーダーから複雑性を隠蔽ながら高度な機能を使わせるためのものだからな。
コーダーが自作テンプレートを使わなくてはならない状況になったら、何か設計が間違っていないか注意する必要がある。
まぁc++だとそういう状況もあるから辛いけど。 >>837
>意図的に移動しない限りコピーはされない
これは微妙すぎる
「意図的」も「移動」も恣意的過ぎるから後出し無敵じゃんけんにしかならない
コピーされないこともあるがコピーされる可能性を前提として最初から考えておくべき Rustのmonomorphization使った静的ポリモーフィズムと同じようなことしたければC++はテンプレート必須だから
ハイレベルのコードしか書かないアプリケーションプログラマーでも普通に使う必要があるでしょ >>845
そういやスタックは一度伸びたら伸びっぱなしだったな
これ傍から見たらメモリリークにも見えるし
何でもスタックはあかんのじゃないか 誰からも指摘されずにどんどん明後日の方向に向かって行っているのは見てる分には面白い
どうか第2の毛の壁と化しませんように
南無阿弥陀仏 >>849
スタックの取扱いを調整すればよろし。
コールスタックとデータスタックを分けてデータスタックをメモリブロックにするとか、大きいのはマネージドヒープに置くようにするとか。
だんだんヒープに近くなるからスタックのメリットは無くなるけど。 コードをよりコンパクトな短文にしようと追求したらテンプレートを使うようになるのはごく当たり前だよ >>835
モダンなC++もそれだぞ
class Hoge {
private:
std::shared_ptr<HogeInternal> hoge;
};
Hogeは常にスタックに割り当てる
実際のオブジェクトはHogeInternalで実装する
こうしておけばめちゃくちゃ安全になる なんで馬鹿はshared_ptr使いたがるんだろう
生ポでいいだろ 3/5/0則を知らないもっと馬鹿なやつがdelete用のデストラクタだけ実装して
事故が多発したからでは >>853
それはHogeInternalがヒープ領域に置かれてしまいスタック領域の利用ではない
さらに参照カウントのオーバーヘッドもある C++、雰囲気で書いたらすぐに壊れるくせに文法がどんどん増えていくのついていけねえわ
どんだけの勉強コストを一つの言語に払わせる気だよ
C++に人生捧げて他のこと何も出来ない無能だけが扱える言語となりつつある 3/5/0則みたいな言語の欠陥に疑問を持たなくなったらもう終わり >>856
いだから置くんだよ
伝わってないみたいだから説明するとHogeに直接実装しないってことを言ってる
間接参照を一段挟むのよ
こうすることでコピーしまくっても問題ないヒープに確保されたオブジェクトができる
多少オーバーヘッドは生まれるがめちゃくちゃ安全性は上がるんよ そそ、難解な概念使いこなせるのはすごいけど、会社でマウントとれるだけ
世の中が求めてるのはそこじゃない。 >>859
Rustを使えばヒープではなくスタック領域に確保してそこへの参照をオーバーヘッドなしで安全に使えるよ
その点がRustとC++の差 >>859
ヒープを使うというオーバーヘッドに加えて
参照カウントを使うというオーバーヘッドまで加わる
もちろん各々が不可欠な場合や両方が不可欠な場合もあるがその前提や吟味をせずに
まともなプログラマーがとる選択肢ではない >>862
嫌だから共有が必要な場合って書いてあるだろ
日本語読める？
共有じゃないならstd::unique_ptrでもいいよ Hogeに実装しないことでコピー時のオーバーヘッドを防ぐ
さらに個別にコピーのことを考える必要性がなくなる
HogeInternalのコピーコストだけで済むため高速
shared_ptrは安全にコピー可能
データは共有できメモリ管理も自動で行われる
ヒープにとらなきゃいけなくて共有する可能性があるオブジェクトはこのパターンで実装してください
マジで何も考えなくていいから >>861
C++で極力Rustっぽく書くにはどうすべきかを突き詰めたらこうなった
褒めてくれ >>863
Rustなら参照の共有はヒープを使わずスタックに置いてあるものに対しても安全に可能です
もちろん参照カウンタは必要ありません
ちなみにRustでC++のshared_ptrに相当するRc/Arcを必要とするのはもっと限定された状況で所有の共有が必要となる時のみです 新たな間接参照でラップすることであたかも普通の変数を作るかのようにヒープに値を置ける
このパターンめちゃくちゃ有用なんだがなぜあらゆる本で紹介されてないんだ？ コロンブスの卵だわ
誰もが思いつきそうで思いつかなかった 本気でRustに寄せるならunique_ptrの方がいいな
コンパイラが助けてくれないから死にそうだけど
とりあえず循環参照だけは気を付けてくれ
>>867
目的はちょっと違うけどPimplってイディオムがある 継承じゃ無くて、包含して各メソッドをバトン渡しすれば良くね？ >>867
他のやつも書いてるけどpimplな
20年前から知られている
ひたすらdelegate関数を書くのがだるい
使う側がshared_ptrで包むというルールのほうが楽 >>872
>ひたすらdelegate関数を書くのがだるい
書かねば良いのでは? >>867
間接参照でいいならわざわざクラスでラップしなくてもshared_ptrそのものでいいように思うんだが
shared_ptr<HogeInternal>で扱うより
ラップしたHogeで扱ったほうがいいメリットって何？ >>872
20年前にこの概念が存在していたのか
当時はauto_ptrとかオレオレメモリ管理モジュールだったとは思うけど >>872
ライブラリとして定期したい場合はshared_ptrで常に包むルールを強制するのも難しいとかかな delegate指定子欲しいよな。
クラスor変数でまとめて指定できればなお良し。 std::byteを使ってみた結果
危険な計算ができるのがC/C++を使う理由という結論になった >>877
Factoryメソッド経由でしかインスタンス化できないようにするとかして常にshared_ptrやunique_ptrで返すようにすればいいのでは？ >>879
delegateに欲しいのはあくまでAdaptorの実装を簡単にする機能。
参照外しとかして型を変えるのはNG。 Rustのdelegate!のようなことがC++ではまだ出来ないということか
汚いマクロ書けばできそうだけど綺麗に書くにはReflection待ちなのかな >>882
こういうキチガイ対策にワッチョイ必要かもな >>884
スマートポインタなのだから
Derefにより自動的に参照できれば十分だろ ﾜｯﾁｮｲ立てたってところで結局また次世代言語スレと同じ流れになってRustスレに帰ってくるんだろ Adaptorにだけ執拗にこだわるオジもアレだか
Adaptorも知らずにDerefを勧めるオジは論外 >>883
ユーザーに返す型では流石に気持ち悪いと思うなあ
C++難し過ぎるだろ
選択肢が多過ぎる
かといって安全でもない
もうRust使わせてくれ >>892
別の理由でfactory使うときはどのみちshard_ptrかunique_ptrにせざるを得ない
(生ポインタはありえない)
だからそこを気持ち悪いと言っても仕方ない >>892
Rustでもそこは同じだと思うよ
ライブラリからBoxやArcが返されるものもあればそれらをラップした型が返されるものもある
シンプルなケースなら前者の方が圧倒的に使いやすい
内包する型のネストが深い場合などで便利メソッドを提供するなら後者ってイメージ
要はラップするだけの付加価値があるかどうか >>854
馬鹿は平気で二重に解放したりする
全然気にしないから馬鹿なんだけどね リファレンスカウンタ方式のGCを基本にするんならGC言語でいいんじゃねってならない？ 循環参照で発生するリークを検出するか放置するか
あるいは循環参照を回避するか
それが問題だ >>899
マークスウィープの話をしてないぞ
リファレンスカウンタ方式のGCすら使えないというならshared_ptrも同様に使えないということになる 手動メモリ管理のできないGC言語は高コストをかけて循環参照を回収せざるをえない
手動メモリ管理のできるC++/Rustは循環参照を避けることができて低コスト
その話とは別にshared_ptrやRc/Arcは参照カウンタによるコストがかかる
そのため複数所有者を使わざるを得ない場合に限定して用いる >>902
Weak Reference等を使って循環参照を手動で避ける方法が用意されてるかどうかは手動メモリ管理かどうかとは全く関係ないよ 積極的にC++を使いたがる人ってC++のどこに魅力を感じているんだ >>897
問題はGC言語は *常に* GC機能ありなところ。 リファレンスカウンター気にするくらい速度を求めるなら、RAIIすら嫌だとはならんのかな
mallocはプログラムの最初に一回呼ぶ以外は許されない >>907
組み込み系でオブジェクトやりたい人
あと意図的に悪意あるコードを仕込む人とか。 やりたいことが出来るのが一番の理由
アンリミテッドが魅力 参照カウントて結構コストあったよな……と探したら解説見つけた。
yamasa.hatenablog.jp/entry/2021/01/29/012525
昔は並列処理と相性悪いと言われていたけど、今はどうかね？ ++C Unsafety Unlimited C++ >>909
GC言語でもunsafeで手動管理とかできるよ
Rustと同じで基本がsafeだからC++をsafeにしていくよりもずっと簡単で問題が起きにくいアプローチ >>902
>そのため複数所有者を使わざるを得ない場合に限定して用いる
複数所有者を使わざるを得ない状況かどうかを確実に見分けるのはそれなりに難しい
Rustの場合はコンパイル通らないから無駄にRc/Arcを違うことはあっても逆はないので安全
C++は逆もある
>>853が「めちゃくちゃ安全になる」と言ってる理由もその辺にあるのでは >>911
RAII自体はコストゼロ
RAIIで解放されるスタック上の値の型にデストラクタがある時にその実行コストがかかる
そしてヒープ領域を所有していればヒープ解放コストがかかる
何度もヒープ確保解放を繰り返すよりはなるべく最初に確保するのはもちろん正しい
スタック領域で済ませられるならさらに望ましい メモリに展開するのにオーバーフローしてもエラーを通知しないの？
https://japan.zdnet.com/article/35212258/
言語はCらしいけどどういうプログラムなんだろう
まじでmallocしてそこにmemcpyしてるだけなんじゃないか
対策はRustで書き直せ たとえクソレガシーだったとしても書き込むアドレスの範囲が想定してるものかのチェックは入れるべきだろう
どうせオフセットも手計算だろうし >>916
＞>>909
＞GC言語でもunsafeで手動管理とかできるよ
どの言語？具体名あげてくれ。 >>867
>あらゆる本で紹介されてない
a)全ての本で紹介されていない
b)紹介された本がひとつもない
どっちの意味？念のため確認 >925 補足
a)全ての本で紹介されていない (紹介されてる本は少なくとも一つ以上ある) >>868
思い付いている人は大勢居る
>>865
>C++で極力Rustっぽく書く
いやいや Rust 以前から Rust 無関係に C++ で普通に C++ っぽく描いた結果でしょ
きみ承認欲求強過ぎるね >>922
メジャーなとこで言えばC#とかSwiftとか >>905
やっぱりNATテーブル不良で再起動したら治るルーターじゃん 型推論の是非を問いたい
書くのは楽かもしれないが読みにくくね？
型の重複記述は省きたいがまったく型がわからなくなると理解が難しくなる
読みやすさを優先すべきだと思うがどうだろう
IDEやエディタのサポートでカバーされるという考え方もあるが、カーソル合わせないとわからないしな >>931
ややこしい型の手書きとか効率悪化の元だから駄目。
せいぜいIDEに型のコメントを自動生成させるくらいまでだな。手動は更新されなくなってバグの温床になる。 >>931
けっこう同意。
変数初期化ではリテラルでの場合だけ型推論利用して、そうでなければ型書いちゃうことも多い。 >>932
＞手動は更新されなくなってバグの温床になる。
型変わったらコンパイル通らないし、型明示がバグの温床になるってのは無い。
修正の手間が増えるってのはわかる。 複雑な型名を知る必要がない場合も多い
例えばRustなら関数の引数型も返り型でも具体的な型名を書かずに
impl Trait名 と使う機能のトレイト名だけを指定したり >>934
c++はスライシングあるからエラーにならない例外もある。
レアケースだけど。 同じ情報を二重に書くのはプログラマなら普通疑問に思う >>924
コピー時はweak_refで渡すので良いかと思うのだが >>925
普通に考えてaじゃないの？
なんで紹介とか出てくるんだ？ >>937
ある程度の重複さによってミスを早期発見できる効果があるから一概にそうはいえないぞ 俺のプログラムにバグがあるのは
俺がまだ本気出してないだけだから どれだけスレが進行しても客観的な基準が示されず
主観バトルを発生させ続け
留まるところを知らない概念
可読性 >>938
いやそれだとshared_ptrの意味ないから
shared_ptr使う限りは本質的には解決は難しい
それは生でshared_ptr使う場合も同じ
get_weakというメソッドでweak_refでラップして返すメソッドを提供するとかだろう 全銀のシステムこの規模で低レイヤーのメモリ操作しまくるのにC使ってるのマジで狂気としか思えないな
コードレベルのユニットテストもないのだろうし
絶対こういうこと起きるやん >>945
プログラミング言語自体、ある程度の冗長性があるようにデザインされている
たからこそコンパイルエラーという現象が起こる
そもそもテストを書くという行為が重複した作業なのだけどやるだろ？
仕様変更したら書き直しなのは仕方ない Cであることは関係なくね？
データ形式の共有に失敗すればどこでも起こりそう
記事だけだとよく分からんけどAAABBBをABABABって誤認した感じでしょ >>946
>プログラミング言語自体、ある程度の冗長性があるようにデザインされている
それは妥協の産物で悪だよ
>たからこそコンパイルエラーという現象が起こる
冗長性がない言語があったとしてコンパイルエラーは起こるし意味がある
>そもそもテストを書くという行為が重複した作業なのだけどやるだろ？
>仕様変更したら書き直しなのは仕方ない
最初に型名が正しいと確認されたら型推論に任せるべきです >>945
>保守できなくなるから必ず避けるべき
保守する気がなくなるから必ず避けるべき
ならわかる >>947
なんも分かってなくて草
あの記事だけで普通は全部理解できるぞ >>949
> 最初に型名が正しいと確認されたら型推論に任せるべきです
その最初の確認ってどうすんのさ？
まったく字面では現れない場合があるよね
もともとはその場合の話 >>952
記事から全部理解できたならたぶん別の記事だと思う >>953
まぁそうだね
>>932で私の言いたいことは書かれてたや 全銀のやつは記事に書いてることはわかるがめちゃくそ疑問だらけ
なんで生成時にサイズチェックしないのか
なんで生成されたテーブルをチェックしてないのか
なんで生成されたテーブル使った試験をしてないのか
一般企業でもなかなかお目にかかれないひどい内容だがそれを金融系のしかも全銀がやっちゃうってのが信じられないわ 型推論よりインテリセンスとか補完がうざい。
こっちの入力リズムに合わないとイラっと来ることある。 >>959
判る
入力enterで違う単語になってたら殺意を覚える Pimplが説明してるある本がないか立ち読みしたのだがあった
最近出たC++ソフトウェア設計という本にモロに書いてあった
こんな本いつの間に出てたんだ？
モロに俺がドヤ顔したパターンじゃねえか...
この本内容もめちゃくちゃ良いぞ ヘッダファイルの変更のせいで再コンパイルされるC++特有の問題に対処するのが主目的のpimplがなんでGoFにあると思ったんですか？ >>962
pimpl、10年前の本「C++のためのAPIデザイン」(2012年)にも載ってるぞ。 まあPimplの主張はコンパイルサイズを固定するとか
内部を隠蔽することが主目的っぽいね
この本ではImplにunique_ptrを使ってコピー時にmoveする実装になってる 知ってると役に立つけどC++使う気が失せる技法のひとつだな >>966
>unique_ptrを使ってコピー時にmoveする
恐怖！auto_ptr再発明男！ >>965
紙本は絶版っぽい
kindleがあるから買うか悩むなあ
クソ高いし 確かに不毛過ぎる気はする
本質的じゃない部分ですげー頭使わなきゃならんし
面白い部分でもない
素直にrust使うべきだわ 銀行はやったこと無いけどSIerの下請けで
お役所のシステム移行の
仕事したときにライブラリ一つに数万個のテストケースが
用意されてあらゆる仕様適合をチェックしていたので
実装でアホなことしててもテストで叩き落とせばよいという
思想なのかも ヘッダーに実装書きまくるのが今のクソc++だからpimplにしたところでというのはある 実装を書かざるを得なくなってヘッダーと呼ぶのが不適切になったから.hの拡張子がなくなった 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/ デザインパターンとは構造について述べたもの
pimplはBridgeパターンの一適用例
別のものではない >>979
>デザインパターンとは構造について述べたもの
全然違うよ
GoFにもそういう考えを明確に否定する内容が書いてある C++オブジェクト設計という本にはbridgeパターンの一種で継承や多態性が必要がない場合の単純な例としてPimplの説明があった >>980
議論をしたければ
GoFに書いてあるそういう考えを明確に否定する内容
を述べ給え C++の不完全型とJavaのインターフェースが同じに見える人には同じに見えるんだろう どうしてもC++を捨てられない人は
RustよりNim使った方が救われる >>994
このスレの腕自慢建ちなら一瞬で移植してくれるだろう このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 40日 20時間 56分 48秒 5ちゃんねるの運営はUPLIFT会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《UPLIFT会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
4 USD/mon. から匿名でご購入いただけます。
▼ UPLIFT会員登録はこちら ▼
https://uplift.5ch.net/
▼ UPLIFTログインはこちら ▼
https://uplift.5ch.net/login レス数が1000を超えています。これ以上書き込みはできません。
