探検
結局C++とRustってどっちが良いの？
レス数が1000を超えています。これ以上書き込みはできません。
0002デフォルトの名無しさん
2023/02/25(土) 11:00:27.52ID:9NhnUjd20003デフォルトの名無しさん
2023/02/25(土) 13:27:35.74ID:P9AUzv0x趣味なら好きなのやればいい
0004デフォルトの名無しさん
2023/02/25(土) 13:38:44.05ID:QyjTyTMeそうなんだけど、今後の流れが気になったので
0005デフォルトの名無しさん
2023/02/25(土) 17:13:51.27ID:lt8vujMQ何か急にある言語をプッシュして他を異様にディスるムーブメントある場合
それは情報商材売りたい勢のゴリ押しってのが判明してる
そんなものに右往左往してたら話にならんよ
0006547
2023/02/25(土) 18:15:55.88ID:VqXFnbZEどの言語がプッシュされたんですか？
0007デフォルトの名無しさん
2023/02/25(土) 20:03:19.10ID:bUASXHz9rustからいきなり入る奴が本当に理解できるのか正直わからん。
0008デフォルトの名無しさん
2023/02/26(日) 08:44:07.54ID:NKFFZ0EI0009デフォルトの名無しさん
2023/02/26(日) 10:30:55.37ID:W2bio7pu少しずつRust縛り(必須)となっていく
C/C++だと気付かないうっかりミスが紛れ込んでセキュリティにも影響してきた確固たる暗い実績が様々なソフトウェアにある
Rustはコンパイル時点でエラーや警告として示し防止する
この差を非常に大きくそしてそれを満たすのは現状Rustしか現実的な選択肢がなく代替候補もない
Rustを書ける人員を揃えることができたところから既に移行は少しずつ始まっており着実に進んでいる
市場的にも公的にもRust製とC/C++製どちらがセキュリティ含めて信頼できるか明確なためいずれは必須指定要件となるだろう
0010デフォルトの名無しさん
2023/02/26(日) 11:58:18.24ID:R0VbvaR9詳しい説明ありがとうございます。
少しずつRustも勉強していこうと思いました。
0011デフォルトの名無しさん
2023/02/26(日) 13:02:29.94ID:E7NCL2qFRust,Python,UnrealEngine
0012デフォルトの名無しさん
2023/02/26(日) 14:38:46.87ID:0HNO0Bah0013デフォルトの名無しさん
2023/02/26(日) 16:48:37.69ID:M2zxuPcRオブジェクト指向が求められてCからC++が出てきたように、C/C++の構文スタイルをとりながらメモリ安全を実装したものが出てくるかもね。
学習コストとしても文法的に新規性が少ない方が好まれるだろうし。
0014デフォルトの名無しさん
2023/02/26(日) 17:26:20.61ID:32xuZUXuC/C++系言語の可能性を試みる時間は既に終わった
ここ10年間でC/C++拡張やその系統では無理だと結論が出たためGAFAMなどIT大手がこぞってRustへ舵をきった
0015デフォルトの名無しさん
2023/02/26(日) 20:14:35.53ID:DFLJCTJ6時期尚早
0016デフォルトの名無しさん
2023/02/26(日) 21:44:33.99ID:GQhuf+Lw見てしまう癖が有るらしい。それでしばらくして別のものが出てくると絶賛し、
前のものを批判に変える。
0017デフォルトの名無しさん
2023/02/26(日) 22:00:08.16ID:32xuZUXu世界中のインフラが次々とRust製へ変わりつつある
例えばAWSなどのクラウドもそう
0018デフォルトの名無しさん
2023/02/26(日) 22:11:58.45ID:GQhuf+Lwそこまですばらしい言語ではないと思えるぞ。
0019デフォルトの名無しさん
2023/02/27(月) 01:07:20.97ID:uT3J6RSV嘘つけ
0020デフォルトの名無しさん
2023/02/27(月) 01:48:26.87ID:O9/5cYsghttps://japan.zdnet.com/article/35183866/
Amazon Web Services（AWS）は、同社のエンジニアたちがプログラミング言語「Rust」を
使っている大きな理由として、エネルギー効率の高さを挙げる。
AWSは早くからRustを採用し、Rust Foundationの創設にも携わった。
現在もRustの普及に熱心に取り組んでいる。
AWSのソフトウェアエンジニアで、Rustの普及に取り組む
Shane Miller氏と主任エンジニアのCarl Lerche氏の投稿によれば、
Rustはメモリー安全性を高め、セキュリティ関連の不具合を減らす役に立つだけでなく、
PythonやJavaよりもはるかに「エネルギー効率に優れている」という。
Amazonは、2025年までにデータセンターの100％を再生エネルギーでまかなうという目標を掲げ、
データセンターの環境負荷の軽減に取り組んでいる。
Rustの採用はその一翼を担うという。
Rustで構築されたAWSサービスの例としては、
コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、
「Amazon Simple Storage Service（S3）」「Amazon Elastic Compute Cloud（EC2）」、
コンテンツ配信ネットワーク「Amazon CloudFront」、
LinuxベースのコンテナーOS「Bottlerocket」がある。
「CやRustが他の言語よりもエネルギー効率に優れていることに驚きはない。
衝撃的なのは、その違いの大きさだ。CとRustを広範に採用すれば、
控えめに見積もってもコンピュートに使用されるエネルギーの量を50％削減できる可能性がある」と
Miller氏は述べ、その根拠として、C、GoogleのGo、Lua、Python、Ruby、Fortranなどをはじめとする
複数の言語のエネルギー効率を相対的に示した研究結果を紹介している。
0021デフォルトの名無しさん
2023/02/27(月) 13:40:42.65ID:csXgFZ4x0022デフォルトの名無しさん
2023/02/27(月) 16:14:37.34ID:dFRgN5USそれでどれくらいがRustで書かれているのかな？
0023デフォルトの名無しさん
2023/02/27(月) 16:27:08.91ID:NzhKA4cT>CやRustが他の言語よりもエネルギー効率に優れていることに驚きはない。
実に疑わしい。
Cは高級アセンブラ。
基本的に効率がよいプログラムがエネルギー効率も良いはずで、だとしたら、
高級アセンブラより効率がよい言語が存在しないといけないことになるが、
あらゆる言語が高級アセンブラを越えることは不可能であるはずなので、
矛盾しているように思える。
0024デフォルトの名無しさん
2023/02/27(月) 16:30:03.92ID:NzhKA4cT[補足]
手書きアセンブラだと超えることが出来る場合が有る。
C言語レベルで最も良いアルゴリズムで書いた場合、最終的にはコンパイラの
バックエンドの最適化次第ということになる。
そしてバックエンドは Rustもclang(C)も同じLLVMのものを使っているので、
Rustがclang(C)が到達できないように効率がよくなる可能性は数学的に
有りえないはず。
Rustでできるなら、Cでも出来るはずだからだ。
0025デフォルトの名無しさん
2023/02/27(月) 17:32:52.43ID:NzhKA4cT[補足2]
C言語は、ノイマン型コンピュータでできる限りどんなアルゴリズムでも
使えて、使えるアルゴリズムに制限が無い。
だから、発見されている中での世界最良のアルゴリズムを使うことができる。
そしてその場合に、世界最速になれない可能性があるとしたら、
バックエンドの最適化層の最適化の能力が人間の手作業の最適化に劣る
ような場合だけである。
それに対してRustがCを速度で上回るというのは数学的に矛盾している。
むしろ、Rustのsafeモードでは、使えるアルゴリズムに強い制限が掛かっている。
0026デフォルトの名無しさん
2023/02/27(月) 17:55:34.32ID:jgoAw3GaもちろんRustとCと全く同様の低レベル記述もできるしCと同様にインラインアセンブラが書けてRust変数との連携もできるしそれらを安全に閉じ込めることができる
一方でRustはプログラム全体の安全性を大域的にコンパイラが保証することが出来るため仮に局所的にunsafeな部分かあっても人間はそこだけに注力できる点でCとは異なり決定的で革新的な変化をもたらした
そしてRustとCが他のプログラミング言語と決定的に異なるのはガベージコレクション(GC)無しで動きプログラミング言語の中で最も高速であり電力消費面でもCPUメモリリソース面でも最も有利な言語である
0027デフォルトの名無しさん
2023/02/27(月) 18:16:27.45ID:NzhKA4cT>安全に閉じ込めることができる
Rustでは、これは不可能なケースが有ることが分かってる。
0028デフォルトの名無しさん
2023/02/27(月) 18:17:38.69ID:NzhKA4cTアルゴリズムが存在することがいくつも知られている。
0029デフォルトの名無しさん
2023/02/27(月) 18:31:59.25ID:BUZw0Bcxプログラム全体に非安全が散らばっているアルゴリズムを考えることは可能だがバカな行為
非安全な部分を局所的に閉じ込めて安全なインターフェイスを公開するライブラリを作るのが正しい道
そうすればRustはプログラム全体の安全性を規模に関わりなく保証することができるためGAFAMなど大手ITを筆頭にその方法へと次々に切り替え始めた
0030デフォルトの名無しさん
2023/02/27(月) 18:36:09.13ID:NzhKA4cTですから、そのように閉じ込めることが絶対に出来ないアルゴリズムが存在しているのです。
0031デフォルトの名無しさん
2023/02/27(月) 18:36:32.74ID:NzhKA4cT0032デフォルトの名無しさん
2023/02/27(月) 22:09:41.53ID:LP8T7WNZ大きなメリットはないのでね
Rustは使う人も少ないし仕事も全くない
CのUNIXやC++のMFCのようなものがないと
Rustをやろうという人は増えないだろう
0033デフォルトの名無しさん
2023/02/27(月) 22:13:22.96ID:3K/qRK7oどっちかだけと言ってるやつは仕事になってないやつだろ。
0034デフォルトの名無しさん
2023/02/27(月) 22:37:20.68ID:KG8RKFb2Rustは洗練されていてモダンな便利な機能も含めて開発効率も良い
もちろん安全性の保証なども付いてくるため比較するとRustが大差で有利
唯一の問題はまだRustを使える人が少ないこと
しかし着実にRustも使える人が増えていってるため
人数を揃えられたところからRustを使うところがどんどん増えている
この流れは逆になりようがない
0035デフォルトの名無しさん
2023/02/27(月) 23:35:53.90ID:LP8T7WNZ0036デフォルトの名無しさん
2023/02/27(月) 23:38:16.05ID:LP8T7WNZRustも牽引する何かがないと増えることはないよ
0037デフォルトの名無しさん
2023/02/28(火) 00:08:33.64ID:pH6hfy6BGoogle ChromeやMicrosoft Edgeで使っているChromiumもC++での多発するセキュリティ問題に耐えかねてRust採用を発表した
クラウドTOPのAmazonも>>20の記事にあるようにインフラをRust製にしている
Meta(旧Facebook)もRust製の基幹システムに変えたとの記事が出ている
この世界的な動きは日本でも少しずつ進み始めている
0038デフォルトの名無しさん
2023/02/28(火) 11:57:56.87ID:xNmaYcy8>>33
ほんそれ
C/C++ 使えるがどうしても Rust 嫌いって人は
Nim を使うと幸せになれる
0039デフォルトの名無しさん
2023/02/28(火) 14:09:00.41ID:e51yPnPZ>Cじゃないとダメだと長年C++を拒絶していたLinuxもRustの導入を始めた
$ wget 'https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.2.1.tar.xz'
$ tar xJf linux-6.2.1.tar.xz
$ find linux-6.2.1 -name *.c | wc -l
32329
$ find linux-6.2.1 -name *.rs | wc -l
37
37ファイルもある!
最後の | wc -l を取るとRustが何に用いられているか分かるよ!
いずれにしても>>37が列挙しているように
現状ではRustにキラープロダクトは無いので
増えることはないと断言できる
0040デフォルトの名無しさん
2023/02/28(火) 15:53:29.33ID:5HrxdEqKRust嫌いは無知が多いな
NimもPythonもGCのあるプログラミング言語であり代替になれない
超遅いPythonは論外としても
NimはNull安全すらなくC/C++と同様に安全性を保証できない言語
0041デフォルトの名無しさん
2023/02/28(火) 16:39:39.54ID:eD9OZA2Z0042デフォルトの名無しさん
2023/02/28(火) 17:12:23.08ID:e51yPnPZ無知はお前さんじゃないかな?
都合の良い記事ばっかり検索して貼っとらんで
>>39のようにソースを見なさい
0043デフォルトの名無しさん
2023/02/28(火) 18:20:57.50ID:Owe2yvkDhttps://codezine.jp/article/detail/17038
> Linus Torvalds氏は、Linux OSのカーネルの最新バージョンである「バージョン6.1」を公開したと2022年12月11日に明らかにした。
> バージョン6.1は、カーネルの記述にRust言語を一部使用した最初のバージョンとなる。
> 従来、LinuxカーネルはC言語とアセンブリ言語で記述していたことから、Rustの採用は大きな変化と言える。
0044デフォルトの名無しさん
2023/02/28(火) 18:25:06.29ID:ilYsCf2nプログラマならソースコードをみなよw
0045デフォルトの名無しさん
2023/02/28(火) 21:39:14.49ID:y7e/yQA5C++は中途半端でクソなことがLinux界でも結論出たのは大きいな
人間チェックで安全を保証するCか
コンパイラによるチェックで安全を保証するRustか、どちらかしかないな
0046デフォルトの名無しさん
2023/02/28(火) 21:43:01.23ID:e51yPnPZ0047デフォルトの名無しさん
2023/02/28(火) 21:46:42.30ID:e51yPnPZカーネルはclangでビルドするのかな?
gccとバイナリ互換じゃなかったような気がするんだけども?
というかカーネルってclangでビルドできるようになったのかな?
0048デフォルトの名無しさん
2023/02/28(火) 21:47:06.07ID:y7e/yQA5そのことだよ
C++は中途半端でクソだから使う意義がないので採用しないとLinux界からも却下されていた
ところがRustは意義があるとして採用された
0049デフォルトの名無しさん
2023/02/28(火) 21:48:12.02ID:e51yPnPZ全く違う
0050デフォルトの名無しさん
2023/02/28(火) 21:54:59.06ID:e51yPnPZ00.11% だからな...
プログラムの隆盛を見るとCにおけるUNIX
C++におけるMFC
PythonにおけるAIのようなキラープロダクトが出て
コードを書ける人が増えないと
メモリ安全ごときでRustが流行ることはあり得ない
0051デフォルトの名無しさん
2023/03/01(水) 02:20:06.43ID:Mc7FdiYoRustを本格的に始めたら言語仕様が秀逸だと分かった
これまでの言語の既成の固定観念に引きずられてるうちは分からなかったことが見えてきた
0052デフォルトの名無しさん
2023/03/01(水) 03:16:12.01ID:1Oup3Ez2Pythonは苦労せず使えるようになった
でもrustは無理くさい
書き方が違いすぎるのと脳が老化して覚えられないw
0053デフォルトの名無しさん
2023/03/01(水) 04:54:30.39ID:HcVT2treモダンな言語なんでもいいけど
何らか抽象的なプログラミングをサポートしている言語でそういう保守性の高い書き方したことがない場合
どの言語でもまずは抽象的なプログラミングに慣れて習得しないままだと
仮に長年プログラミングやってきたとしても初心者止まりのままになっちゃうのでどこかへ進むとよいかも
CやってきたのならばRustはあとその部分を習得するだけだね
0054デフォルトの名無しさん
2023/03/01(水) 08:01:08.42ID:82Husj9hC/C++のリプレースで使われることで騒ぐしかないんじゃ、できること自体はCと変わらないってことだしね。
小規模なプログラムだと一番のウリのメモリ安全も利益感じられないし。
制御関係とかでC++のClassや継承とかは部品の組み合わせと対応させられて便利だったけど、Rustでは継承はバッサリ切り捨てちゃったみたいだしなあ。
そういえば、脳科学者が言うには脳は老化しない、何歳になっても海馬は大きくなるらしいよ。
自分はChatGPTで掛け合い漫才しながらチュートリアル眺めてるけど、以前三日坊主だった時の壁は越えられた気がする。
0055デフォルトの名無しさん
2023/03/01(水) 10:16:16.06ID:BrtIIoCoC#のほうが言語仕様秀逸だよ
0056デフォルトの名無しさん
2023/03/01(水) 10:16:52.64ID:BrtIIoCo0057デフォルトの名無しさん
2023/03/01(水) 10:20:08.76ID:68s28u+fなんで二択なんだよ
Nimがあるじゃないか
0058デフォルトの名無しさん
2023/03/01(水) 10:23:04.35ID:BrtIIoCo組み込みで使われてる？
0059デフォルトの名無しさん
2023/03/01(水) 10:24:39.92ID:68s28u+f脳の老化じゃなくて過学習が始まった年頃なんじゃね
0060デフォルトの名無しさん
2023/03/01(水) 10:35:28.60ID:jxeZ0t7/あとはZigとかはどうなんだ
0061デフォルトの名無しさん
2023/03/01(水) 10:39:50.76ID:NalgN/NX0062デフォルトの名無しさん
2023/03/01(水) 10:41:08.58ID:jxeZ0t7/上でも言われてたけどNimでGC無効メモリ手動管理でやったらどれくらい使い物になるんだってのは気になる
まあふつうNimならもうメモリ管理せずにORCでやるだろうけど
0063デフォルトの名無しさん
2023/03/01(水) 17:09:50.12ID:FMM19mI8C#もNimもGCが基本の言語
このスレに持ち出すのは場違い
>>60
Carbonは公式ページに「Rustを使える状況ならばRustを使った方が良い」と明記されてる位置付けの言語
CarbonはC++記述遺産のメンテ用が目的
Zigは手動でメモリ解放する言語
Rustは自動でメモリ解放する言語
そしてRustではメモリ安全性がコンパイル通れば保証される信頼性が大きな差
0064デフォルトの名無しさん
2023/03/01(水) 17:19:17.03ID:FMM19mI8もちろんRustはC言語と同じく低レベル記述も可能
必要ならばインラインアセンブリもサポートしておりRustの変数を使ってその場でasm挿入記述もできる
組み込みもRustのメインターゲットの一つ
https://www.rust-lang.org/ja/what/embedded
0065デフォルトの名無しさん
2023/03/01(水) 23:46:27.72ID:YuYxAjXZ>C#もNimもGCが基本の言語
>このスレに持ち出すのは場違い
ここはどういう場なんでしょうか?www
0066デフォルトの名無しさん
2023/03/01(水) 23:58:04.67ID:Faf+SNloスレタイ見ればわかるようにガベージコレクション使う遅い言語は対象外だと思うよ
0067デフォルトの名無しさん
2023/03/02(木) 00:15:37.04ID:4/ee2SHc>スレタイ見ればわかるように
飛躍し過ぎていて「結局C++とRustってどっちが良いの？」で
GC使う言語がスレの対象外になるのがサッパリわからん
0068デフォルトの名無しさん
2023/03/02(木) 02:30:04.05ID:bqXvu2FA伝統ばかりに固執する人らに
過去の栄華はあっても
未来など無い
0069デフォルトの名無しさん
2023/03/02(木) 05:01:47.34ID:s9foVenTプログラミング言語は大きく2つに分かれていて
GCのある遅くてメモリ消費も多い言語と
GCのない速くてメモリ消費も少ない言語に分かれる
そこには決定的な違いがある
次にスレタイというのはいちいち説明しなくても
例えば「Vue vs React vs Angular vs Svelte Part.11」というスレはそれら比較対象からJavaScriptフロントフレームワークのスレだと分かる
そしてここはスレタイが非GC言語の既存代表例C++と非GC言語の新興代表例Rustの比較的となっているから
基本的にその両者が対象でおまけとしても同じ非GC言語のCやZigなどが対象ギリギリかなと思う
0070デフォルトの名無しさん
2023/03/02(木) 05:13:35.95ID:MiifFeAk0071デフォルトの名無しさん
2023/03/02(木) 05:44:38.60ID:6fagNnHa最低限ガベージコレクション無しと低レベル記述可を備えた最高速クラス言語じゃないと比較の土俵にも上がらんわ
0072デフォルトの名無しさん
2023/03/02(木) 06:35:13.17ID:M8IdVdds0073デフォルトの名無しさん
2023/03/02(木) 07:12:21.96ID:ZOdXc5Gl猫と犬とどっち飼ったらいいかな？
の質問に「金魚が良いよ」と回答しても意味ないだろ
0074デフォルトの名無しさん
2023/03/02(木) 07:14:53.01ID:D5BhE+0S例えばC#やPythonではまともなOSを作ることができない
GoogleがRustで書かれたセキュアなOS「KataOS」を発表
https://japan.zdnet.com/article/35194751/
0075デフォルトの名無しさん
2023/03/02(木) 11:41:51.38ID:v0ZnzcWP高い性能や高い応答性くらいの意味でリアルタイム性という用語を使ってるのかもしれないけど意味違うからね
0076デフォルトの名無しさん
2023/03/02(木) 12:13:29.31ID:4/ee2SHcそういうのは飛躍と言う
お前が>>1でそのつもりでこのスレを立てたのならスレタイは不適切
0077デフォルトの名無しさん
2023/03/02(木) 12:17:03.65ID:4/ee2SHc「リアルタイム性」も知らんようだし
お前はRustについてGCのあるなしくらいしか語れないのかな?
ちなみにこの板読んでる人でGCを分からん人はほぼいないと思う
0078デフォルトの名無しさん
2023/03/02(木) 12:57:49.07ID:D5BhE+0S最近は新たなものが出てくるとRust製
Webpackの後継となる新バンドルツール「Turbopack」が登場。Rust製のネイティブアプリケーションでWebpackの700倍高速に！
https://www.publickey1.jp/blog/22/webpackturbopackrustwebpack700nextjs_conf_2022.html
0079デフォルトの名無しさん
2023/03/02(木) 13:19:48.65ID:2W3DfR3dC++で今まで作られてきたものがどれだけRustに変わっていくのか気になってスレ立てしました。
メモリ安全性という観点だとRustになりますが、C++にはRustより優れている点があって、今後もまだ残り続けるのかどうかです。
0080デフォルトの名無しさん
2023/03/02(木) 13:47:49.79ID:9x7ptNRV今のところC++がそういったゴミになる兆候は無いと思います
Rustが優れているかどうかは一切関係がありませんね
0081デフォルトの名無しさん
2023/03/02(木) 13:48:50.41ID:BxgVYWtl既存のコードベースが大きいから急激には変化しない
残る理由はCOBOLが残っているのと同じで優れてるという理由からではない
0082デフォルトの名無しさん
2023/03/02(木) 14:11:06.82ID:4/ee2SHc>SolanaやRayonがUNIXやMFCのようにプログラミング言語を新たに習得しようと
>する人を爆発的に増やすことは、現時点では考えにくいと言えます。
>UNIXやMFCが広く普及した理由の一つは、それらが当時の主流であったプラッ
>トフォームやアプリケーションの開発に必要不可欠であったためです。一方、
>SolanaやRayonは、それぞれ特定の分野において高いパフォーマンスを発揮す
>るためのライブラリやプラットフォームであり、必ずしも全ての開発プロジェ
>クトに必要不可欠なものではありません。
>また、Rust自体がまだ比較的新しい言語であるため、多くのプログラマがRust
>を習得する必要性を感じているわけではありません。ただし、Rustの安全性や
>パフォーマンスが注目されるにつれ、より多くのプログラマがRustに興味を持
>ち、学習する可能性はあります。
>つまり、SolanaやRayonがプログラミング言語を新たに習得しようとする人を
>爆発的に増やすことに貢献するかどうかは、それらが必要不可欠なライブラリ
>やプラットフォームとして広く普及するかどうかにかかっていると言えます。
0083デフォルトの名無しさん
2023/03/02(木) 14:16:45.49ID:4/ee2SHc携帯に匹敵する新たな情報端末が出現して
それがRustで制御されているとか
0084デフォルトの名無しさん
2023/03/02(木) 14:23:37.36ID:N97puPhxググり力と同じくジピり力が求められる
0085デフォルトの名無しさん
2023/03/02(木) 14:36:25.48ID:4/ee2SHcSolanaやRayonが返ってきた質問は以下
>あるプログラミング言語が流行るにはC言語におけるUNIXやC++のMFC、最近だ
>とpythonがAIによって流行ったようにキラープロダクトが重要だと思います。
>キラープロダクトがあれば、その言語を習得したプログラマが一気に増えます。
>Rustにそのようなキラープロダクトはありますか？
Rustの爆発的普及にはキラープロダクトが不可欠
0086デフォルトの名無しさん
2023/03/02(木) 14:38:15.81ID:D5BhE+0SC++は今も違法増改築を続けて無数に部屋(仕様)が作られていくような言語
そして新たな増改築が決まっても、完成(実装)されなかったり、新たな部屋の存在が知られていなかったり、ほとんどの部屋は極一部の人しか使われていない
結果的に良い機能があっても使われないのは無駄に大きく重複もある複雑な言語仕様のせい
例えばC++20で導入されたstd::rangesはRustでいうとIteratorなどの基本的なデータ取り扱い機能で超重要だが今後も広まらないのだろう
歴史的な事情でC++の全容は複雑怪奇となっていて理念の一貫性もなくどうしようもない状態
Rustは洗練された言語仕様となっていてC++と比べれべるとシンプルで分かりやすい
全体の理念も統一されており特に安全性に関する保証が与える信頼性はこのセキュリティ重視の時代に完全にマッチしている
今後Rust人口が増えてくると企業案件でC/C++が使われてきたものはRust指定(必須)となっていくだろう
0087デフォルトの名無しさん
2023/03/02(木) 14:45:55.72ID:4/ee2SHc普及して長いことたてばRustもご多分に漏れずいずれ複雑怪奇になるってw
若いと分からんかもしれんが
C++は複雑怪奇に見えるかもしれんが規格変更には慎重の方だと思うよ
ところでRustって規格あるの? 仕様しかない?
0088デフォルトの名無しさん
2023/03/02(木) 15:24:09.80ID:4/ee2SHc0089デフォルトの名無しさん
2023/03/02(木) 15:30:29.97ID:o+lCraYI0090デフォルトの名無しさん
2023/03/02(木) 15:41:34.24ID:4/ee2SHc90年代中盤から後半にかけて使われ始めたと思うけど
（boost::shared_ptrはいつからだっけ？）
std::shared_ptrが規格に入ったのはC++11
規格の拡張は無節操というより慎重というかクソ遅いよ
0091デフォルトの名無しさん
2023/03/02(木) 15:59:19.04ID:dC3Ayx4mJavaが出た時に聴いたことあるような文句だな
割とマジでフラッシュバック
0092デフォルトの名無しさん
2023/03/02(木) 16:08:40.39ID:eS6QMQkYそれは分類が非常に簡単
既に作られており穴も発見されないものをわざわざRustに移植する意味はない
穴が多く悩まされてるものはChromiumのようにRust併用やRustへ切り替えが進んでいる
新たに作ったり大きく作り直す場合はRust一択
0093デフォルトの名無しさん
2023/03/02(木) 16:24:01.58ID:eS6QMQkYC++はスマートポインタがあっても言語システムとして安全を保証する枠組みがない
まともなIT企業からRustへ移動し始めている根本的な理由がそこ
0094デフォルトの名無しさん
2023/03/02(木) 16:40:50.78ID:4/ee2SHcRustプログラマを支障なく確保できなければ企業は
試験的採用こそすれど本格採用はしない
Rustプログラマが多い -> Rust生態圏が良くなる ->
Rustプログラマが増える -> （最初に戻る）
※Rust生態圏が良くなるとはライブラリやtipsが増えRustの仕事が増えること
この好循環を作らないことにはRustが流行りだすことはないだろう
そのためのキラーコンテンツ
>>37で上げてるようなソフトはしょぼすぎて該当しない
>>83くらいの状況になれば変わる
0095デフォルトの名無しさん
2023/03/02(木) 16:53:27.06ID:eS6QMQkYまともなIT企業からRustを導入していっている理由がそこにある
非GC言語でメモリ安全性を言語システムが保証する初で唯一のプログラミング言語がRust
0096デフォルトの名無しさん
2023/03/02(木) 17:10:59.88ID:oc1UgWLG0097デフォルトの名無しさん
2023/03/02(木) 18:47:07.82ID:9x7ptNRV0098デフォルトの名無しさん
2023/03/02(木) 19:04:35.27ID:o+lCraYIメーカーさんのサンプルにしても、過去の資産も（FreeRTOSだのもArduinoなんかも）膨大。
それらが全て使われなくなったり、他の言語でで書き換えられるということが仮に
にあるとしても相当先の話になるだろう。
と考えると、C/C++はほぼ基礎教養かな？
あとは実務で要求されたものを身につけるっていう感じなんだろうな。
パラパラ眺めた範囲ではRustもC++知っていればさほど難しくなさそうだけど
個人で趣味レベルでやってますといっても、実務経験ないとキャリアとしてのアピール度は低いしな
0099デフォルトの名無しさん
2023/03/02(木) 19:14:16.94ID:OHJUJNoLCの基礎は必要だがC++は要らん
特殊な組み込み環境などでない通常利用ならば対応していてRustが使える
0100デフォルトの名無しさん
2023/03/02(木) 19:20:18.08ID:OAWE1K4h0101デフォルトの名無しさん
2023/03/02(木) 19:22:55.17ID:OAWE1K4hこれもいずれはあのような壊れたレコードに成り果てるのだろう
0102デフォルトの名無しさん
2023/03/02(木) 19:42:00.55ID:+4hIkzucGoogle Chrome、プログラミング言語「Rust」の採用を発表
https://news.mynavi.jp/techplus/article/20230113-2561774/
0103デフォルトの名無しさん
2023/03/02(木) 23:06:33.64ID:4/ee2SHcそれでRustプログラマが増えることはないな
>>83くらいの状況にならんと
0104デフォルトの名無しさん
2023/03/03(金) 06:56:09.99ID:3EPD3050その「特殊な組み込み環境」とやらでもC/C++は使えるからね。
C++はフルには要らんかもだけど、
クラスと継承は組み込みとかでも便利に使われてたりするね。
できることが大差ないとすると、仕事でRustを使えと言われない限り、個人レベルで積極的に使う理由に乏しいかなぁ。
個人でメンテできる程度だとメモリ安全ってそれほど重要ポイントではないし。
PythonにとってのAIみたいに、こういうアプリケーションなら、C/C++より遥かに楽で簡単に実現できるというものが必要なのではないかな。
今の段階じゃ、メモリ安全にするために制約やチェックを厳しくしたC/C++ってだけって感じだもの。
0105デフォルトの名無しさん
2023/03/03(金) 07:13:09.62ID:5+VE8dsn洗練されたモダンな言語仕様のため非常に書きやすい
これが一番大きなメリット
おまけとしてメモリ安全性の自動保証とデータ競合なしの保証
これらにおかげでC/C++で書いてた時に無駄に必要だった実行時デバッグが激減して消えた
Rustは開発効率が大きく向上する
0106デフォルトの名無しさん
2023/03/03(金) 09:31:41.76ID:oC7cFOXyDが出た時に聴いたことあるような文句だな
割とマジでフラッシュバック
0107デフォルトの名無しさん
2023/03/03(金) 13:09:51.97ID:t7eEMnCDどこが似てんだよ何も区別付かないアフォ
0108デフォルトの名無しさん
2023/03/03(金) 13:21:04.67ID:mNTxopBi0109デフォルトの名無しさん
2023/03/03(金) 13:21:58.74ID:PdMH/ctMやっぱりHaxeは復活すべきだよな
0110デフォルトの名無しさん
2023/03/03(金) 13:26:08.63ID:HbtHbRsb凄い似てるよ
Javaが出たときにも聞いたぞ
「C/C++を置換する！」は人間の性なんだろうw
長くやってると何度も見るし結果もだいたい分かる
0111デフォルトの名無しさん
2023/03/03(金) 16:49:35.55ID:lJwnZSPrしかも、Javaの普及速度は物凄く速かったが、Rustは伸びてない。
0112デフォルトの名無しさん
2023/03/03(金) 19:36:46.54ID:NsCHD7Iuプログラミング言語の一般的な基礎知識を持たない人がRustのアンチをやっているのかしら
JavaがCやC++に置き換わらなかった理由の一つはJavaがガベージコレクション必須の言語だからですよ
CやC++の置き換えとなるためにはGCを必要としないプログラミング言語でないとダメなんですよ
GCを必要としない言語も数少ないながら今までいくつか出て来たのになぜCやC++を置き換えられなかったか分かりますか？
CやC++で問題となってきたのはメモリ操作の安全性とデータ競合の安全性です
それらを完璧に対応して言語自体が安全性を保証する言語が今までなかったからですよ
Rustが初めて対応して初めて真にCやC++を置き換えられるようになりました
だからIT大手各社がライバル関係を超えて共同してRustを支援そして採用しているのですよ
0113デフォルトの名無しさん
2023/03/03(金) 20:45:25.65ID:56kfvkVg>>77
お前はそればっかりだなw
そんなものはこの板の住人が知らん訳ないやろw
GCくらいしか語る知識がないんだろうな
0114デフォルトの名無しさん
2023/03/03(金) 21:06:34.40ID:NsCHD7Iuその>>77を見てみましたがリアルタイム性の話ですか
それは直接はプログラミング言語とは関係ない話ですが少し関係がありますね
言語に関わらず作成したシステム側の話でOSからゲームのようなアプリまで必要とされる時間的制約があることをリアルタイム性と言います
もちろんガベージコレクションはリアルタイム性の障害となりますのでそれを軽減する手法を取ったりリアルタイム性を必要としないタイミングでGCを実行します
しかしそれでも現実的なOSや基幹システムでGC言語の利用は厳しいでしょう
そのためOSなどの記述にはCやC++やRustが使われます
メモリ安全性などの保証をプログラマーではなく言語システムに任せることができるRustがベストとなります
0115デフォルトの名無しさん
2023/03/03(金) 21:20:32.28ID:qLiBhaKu0116デフォルトの名無しさん
2023/03/03(金) 21:26:29.88ID:HbtHbRsbリアルタイム性の話ではなく
GCの話しかしないことを言っている
GCくらいしか語る知識がないと俺は推測している
0117デフォルトの名無しさん
2023/03/03(金) 21:48:53.60ID:IWtB3OsLJavaとか持ち出す>>110や>>111はアホすぎ
0118デフォルトの名無しさん
2023/03/03(金) 21:51:10.69ID:HbtHbRsb>>76
0119デフォルトの名無しさん
2023/03/03(金) 21:51:28.18ID:HbtHbRsb>>76
0120デフォルトの名無しさん
2023/03/03(金) 22:54:44.50ID:3xVHehJY0121デフォルトの名無しさん
2023/03/03(金) 23:40:18.48ID:DSH9vzOSしかし無関係なGC言語を持ち出してくるバカがいてそれを邪魔をしているようだ
0122デフォルトの名無しさん
2023/03/03(金) 23:41:20.65ID:kiJ4JQPsまぁ隔離ファイト続けてくれ
0123デフォルトの名無しさん
2023/03/03(金) 23:57:24.37ID:gZNQib4P0124デフォルトの名無しさん
2023/03/04(土) 02:04:08.56ID:OUzFL/z00125デフォルトの名無しさん
2023/03/04(土) 05:09:33.55ID:zMMeSguG0126デフォルトの名無しさん
2023/03/04(土) 10:37:16.20ID:4/pts6A0VB6はGC無かったのになぜこうなった
0127デフォルトの名無しさん
2023/03/04(土) 10:41:49.65ID:CDmz22lO君はてをにはがおかしい
寝ぼけた頭で脊髄反射で書き込むのはやめたほうがいいな
0128デフォルトの名無しさん
2023/03/04(土) 10:54:13.03ID:RFNVa0QichatGPTの回答に似てるなωωω
0129デフォルトの名無しさん
2023/03/04(土) 10:59:11.20ID:RFNVa0Qi何処が可笑しいか指摘してくれ
おれには判らん
0130デフォルトの名無しさん
2023/03/04(土) 11:05:58.63ID:54Un32Sk「CやC++に置き換わる言語の話」なんて誰もしていない
「CやC++に取って代わる」あるいは「CやC++を置き換える」と言いたいのだろう
あるいは本気で「CやC++に置き換わる言語の話」をしているのなら今度こそ本当に頭がおかしいな
0131デフォルトの名無しさん
2023/03/04(土) 11:14:10.28ID:RFNVa0Qi0132デフォルトの名無しさん
2023/03/04(土) 11:23:10.42ID:33wAkDSdVB6はトレースGCではないけど参照カウンタGC方式のGC言語
VB6オブジェクトは裏で参照カウンタが自動的に使われていてそれにより使われなくなったメモリを回収している
ちなみにC++のshared_ptrなども参照カウンタ方式だが裏で勝手に使われることはなく必須でもなくプログラマー裁量なのでC++はGC言語ではない
0133デフォルトの名無しさん
2023/03/04(土) 11:59:27.29ID:Ss9j+0CwフルスクラッチでOSを書くくらいしか方法はないだろうね
OSの普及は更に至難の技だけども
0134デフォルトの名無しさん
2023/03/04(土) 12:08:40.51ID:2fdiw2OM0135デフォルトの名無しさん
2023/03/04(土) 12:51:29.76ID:SdQ3Tgr2| 彡⌒ミ
＼ (´･ω･`)またGCの話してる
(| |)::::
(γ /:::::::
し ＼:::
＼
0136デフォルトの名無しさん
2023/03/05(日) 00:54:23.16ID:OH6jTTZv0137デフォルトの名無しさん
2023/03/05(日) 00:59:18.56ID:eidG4gk+フルスクラッチの新たなOSを普及させるのは難しいだろうが
>>74に記事があるようにGoogleがRustのみで新OSを作ってるな
あとAndroidもLinuxもWindowsもRustの一部採用を始めて
この流れはOSに限らず全てのシステムでRust化が進んでいくのだろう
GoogleとMicrosoftがRust言語でOS開発
https://xtech.nikkei.com/atcl/nxt/column/18/00692/042700054/
0138デフォルトの名無しさん
2023/03/05(日) 09:30:23.81ID:B0+xSixt次第に現行プロジェクトを置換して増えていくなんて展開はありえないっての
AndroidやWindowsをRust製のOSで置換するくらいしかストーリとしてはない
Linuxに入っているRustコードは>>39で書いた通り
0139デフォルトの名無しさん
2023/03/05(日) 10:00:51.19ID:N4QaJnepマイナープロジェクトでちょっと使われたら勝利なのかよ
0140デフォルトの名無しさん
2023/03/05(日) 11:14:29.69ID:/Qd0pRlS0141デフォルトの名無しさん
2023/03/05(日) 11:34:54.12ID:ukOUhlGm0142デフォルトの名無しさん
2023/03/05(日) 11:49:22.14ID:nmaj3subとかね。
0143デフォルトの名無しさん
2023/03/05(日) 14:28:35.02ID:FAqgXVt30144デフォルトの名無しさん
2023/03/05(日) 14:30:11.56ID:FAqgXVt3それよりもグラフィックソフト作ったほうが広まると思うけどね
Blender参考に3Dモデリングソフトつくってよ
0145デフォルトの名無しさん
2023/03/05(日) 14:54:49.80ID:B0+xSixtそれでは心が満たされないんだよ
GCの話しかしない人とか
0146デフォルトの名無しさん
2023/03/05(日) 15:15:15.70ID:WdTi9AcGGCの有無はその言語がカバーできる範囲の差となり優劣関係が明白
GCのない言語は全てをカバーできる
0147デフォルトの名無しさん
2023/03/05(日) 15:45:42.10ID:09jM8CxoUEとかのゲームエンジンは当たり前だがついてる
うまく付き合ってくほうが大事
0148デフォルトの名無しさん
2023/03/05(日) 15:50:56.78ID:7nv7saAEGC以外のことを語る知識がない
GCはこの板見てる人はほぼ誰でも知っているだろう
0149デフォルトの名無しさん
2023/03/05(日) 15:58:09.36ID:Y+o3TKYeC++とRustが王者決定戦になるのは当たり前じゃね？
0150デフォルトの名無しさん
2023/03/05(日) 16:07:43.53ID:RiJu3w7U0151デフォルトの名無しさん
2023/03/05(日) 18:26:02.22ID:xsWqtK1g0152デフォルトの名無しさん
2023/03/06(月) 00:49:06.50ID:pFRSokg0アホか
0153デフォルトの名無しさん
2023/03/06(月) 09:19:45.87ID:93HR+LQR0154デフォルトの名無しさん
2023/03/06(月) 09:45:52.37ID:4Z2NP+rF0155デフォルトの名無しさん
2023/03/06(月) 13:40:13.02ID:diWxUEyJ| 彡⌒ミ
＼ (´･ω･`)またGCの話してる
(| |)::::
(γ /:::::::
し ＼:::
＼
0156デフォルトの名無しさん
2023/03/06(月) 15:05:53.11ID:diWxUEyJhttps://zenn.dev/dumblepy/articles/3db2134ff88763
0157デフォルトの名無しさん
2023/03/06(月) 17:14:45.53ID:93HR+LQR0158デフォルトの名無しさん
2023/03/06(月) 20:00:50.97ID:BPh5rEIJそういえば、C++のcv属性は、論理和方式で、constは足し算の様に0から1に
変わるが、mut 属性はそうはならないだろうから、どうなるんだろうな。
constは意味的に考えてもcastしない限りは、、constなものはいくらやっても
書き込めるようにはならない、というのは安全性から当然なんだけど、
mutだとそうはいかない。
0159デフォルトの名無しさん
2023/03/06(月) 20:09:02.49ID:BPh5rEIJmutとconstは逆さまの働きみたいだから、どっちで行くかは言語設計者の自由と
思われがちだけど、constな構造体のメンバは勝手に全てconst扱いになるという
単純な論理に出来るけど、mut方式の場合は、constキーワードも別に必要になりそう。
0160デフォルトの名無しさん
2023/03/06(月) 21:18:31.55ID:HKTArltY他の言語と同じでsetter相当をなくしてgetterだけにすればいい
専用のラッパーを作る方法もあるができて当然の機能なので誰もやらないだろうね
0161デフォルトの名無しさん
2023/03/06(月) 21:44:09.47ID:l1NoBYC6C++でconstを誤用しているのとは異なり
Rustではconstを正しく定数の意味で使っているので注意
つまりconstは定数でありコンパイル時に静的に定まる
もちろんconstとは別の概念としてmutableとimmutableがあり、これらは可変性の有無を表す
さらにそれらと別の概念として所有権があり、所有権を持っていればimmutableであろうと関係なくmutableな変数へ移すことで可変性を得られる
一方で所有権を持たないimmutableな参照からは可変性を得られない
0162デフォルトの名無しさん
2023/03/06(月) 21:51:25.41ID:1935XsNt>C++でconstを誤用しているのとは異なり
誤用なの?
0163デフォルトの名無しさん
2023/03/06(月) 22:01:32.22ID:l1NoBYC6そうだよ
実行するたびにあるいは関数を呼ぶたびに値が変わりうる変数(＝静的に値が定まらず変わりうること)に対して、
変数がimmutableであることを間違えてconstと付けてしまった
そのためC++では定数(＝静的に値が定まること)の場合は苦肉の策でconstexprと変な名前を付けることになった
0164デフォルトの名無しさん
2023/03/06(月) 22:21:12.53ID:1935XsNtC++では単に値が`constant'って意味で使っただけではないのかな?
それを誤用とは言わんと思う
ところで何でconstexprではないconst変数は
静的に定まらないことになってるの?
0165デフォルトの名無しさん
2023/03/06(月) 22:37:19.16ID:l1NoBYC6もちろんC++は整数などに限ればconstで静的な定数となるが
それ以外C++のconstは定数ではなく静的にコンパイル時に定まらない
そのため真のconstを表すためにconstexprというキーワードを新たに用意する本末転倒な状況となった
0166デフォルトの名無しさん
2023/03/06(月) 22:52:19.69ID:1935XsNt>>163
>実行するたびにあるいは関数を呼ぶたびに値が変わりうる変数(＝静的に値が定まらず変わりうること)に対して、
>変数がimmutableであることを間違えてconstと付けてしまった
>>164
>もちろんC++は整数などに限ればconstで静的な定数となるが
2つ目はなるんだっけ?
0167デフォルトの名無しさん
2023/03/06(月) 22:53:11.95ID:1935XsNt>そのため真のconstを表すためにconstexprというキーワードを新たに用意する本末転倒な状況となった
「本末転倒」とは違うと思うよ
0168デフォルトの名無しさん
2023/03/06(月) 23:09:16.19ID:h8dbx3naC++で何らかのクラスのインスタンスを作ってconstに入れることを考えてみるとわかりやすいよ
もちろんこのconstのインスタンスはコンストラクタの引き数の値によって変わるから静的な定数じゃないよね
つまり単なるimmutableな変数に過ぎないわけだけどC++はそれに対してconstと間違えて名付けちゃった
だから本当の定数に対してconstexprと名付けることになった有名な話だよ
0169デフォルトの名無しさん
2023/03/06(月) 23:20:34.22ID:1935XsNt>つまり単なるimmutableな変数に過ぎないわけだけどC++はそれに対してconstと間違えて名付けちゃった
C++のconstは単なる`constant'の意味で
静的な定数という意味でないというだけなのでは?
本当に「間違えて」名付けたのかな?
俺にはC++のconstにあなたが「間違えて」静的な定数という意味を
期待しているだけに見えるのだが?
0170デフォルトの名無しさん
2023/03/06(月) 23:31:32.57ID:l1NoBYC6環境によって実行毎に、または、関数の引き数によって関数が呼ばれるごとに、>>168の示してる例だと値が変わりうる
その変わりうるものに対して、C++がconstと付けたのは失敗としか言いようがないのではないか
そしてC++は本当にconstantなものに対して、後からconstexprと付けざるをえなかったことが、C++の失敗を誰の目にも明らかにしている
0171デフォルトの名無しさん
2023/03/06(月) 23:33:40.69ID:1935XsNt>環境によって実行毎に、または、関数の引き数によって関数が呼ばれるごとに、>>168の示してる例だと値が変わりうる
これはどいう状況か分かりにくい? ソースで書いてみて
0172デフォルトの名無しさん
2023/03/06(月) 23:42:46.60ID:l1NoBYC6関数に渡ってきた毎回変わりうる引き数を使ってそれを渡してインスタンス作成してconstに突っ込む場合でもよい
あるいは環境変数やargv使ってインスタンス作成でもよい
いずれも毎回インスタンスの値が変わりうるため定数ではないがC++ではconstと付けてしまった
そして本当の定数にconstexprと付けた
0173デフォルトの名無しさん
2023/03/06(月) 23:47:46.47ID:1935XsNt曖昧さを避けたいのでソースで書いて
反論する
0174デフォルトの名無しさん
2023/03/06(月) 23:52:15.11ID:p7JhiTtQ一貫性がありませんね
0175デフォルトの名無しさん
2023/03/06(月) 23:56:33.22ID:h8dbx3na数字でも物理でも定数は静的に定まるものだよ
でもC++はconstをimmutableの意味で間違えて名付けてしまいました
そして定数を表すためにconstを使えなくなりconstexprと名付けたという誰でも知ってる有名な話だよ
0176デフォルトの名無しさん
2023/03/07(火) 00:01:46.05ID:gZ1LpnCS>でもC++はconstをimmutableの意味で間違えて名付けてしまいました
とあなたが思っているだけではないかな?
C++のconstにあなたなが「間違えて」静的に定まるものを期待しているだけでは?
0177デフォルトの名無しさん
2023/03/07(火) 00:09:47.95ID:6eBCzRN0どうせC++で静的に定まる値を示すキーワードも必要となるんだから素直にそれをconstにしておくべきだったか
設計ミスだな
0178デフォルトの名無しさん
2023/03/07(火) 00:57:00.01ID:UNnBBHt00179デフォルトの名無しさん
2023/03/07(火) 01:08:45.38ID:gZ1LpnCS>言われてみれば
www
0180デフォルトの名無しさん
2023/03/07(火) 01:27:52.75ID:phr7A4jUそのためconstantに対してconstと命名できなくなってconstexprと命名したと
0181デフォルトの名無しさん
2023/03/07(火) 01:31:47.04ID:CjRtBzJ1相対主義的に考えなさい
相手の価値観を理解しなければ説得力は生まれません
0182デフォルトの名無しさん
2023/03/07(火) 02:21:18.68ID:oSHTm7slaをimmutableと呼ぶかconstantと呼ぶか
・y=f(a) (a=10である)
f(a)をconstantと呼ぶかconstant expressionと呼ぶか
まあ考え方次第だよな
0183デフォルトの名無しさん
2023/03/07(火) 02:29:20.82ID:phr7A4jU上はxが実行時に値がわかる変数なんでしょ？
それならconstantには成りえないんじゃない？
0184デフォルトの名無しさん
2023/03/07(火) 08:05:58.19ID:oSHTm7slかかるaについてなんと呼ぶかって話だから別にxについて気にする必要は無いよ
0185デフォルトの名無しさん
2023/03/07(火) 08:10:06.41ID:X5urLXgj理解できていなさ過ぎだろｗ
0186デフォルトの名無しさん
2023/03/07(火) 08:16:15.53ID:X5urLXgjあと例を出すにしても
整数は特殊でconstexprでなくconstでも静的定数になる例外だから例として最も不適切
0187デフォルトの名無しさん
2023/03/07(火) 09:21:06.13ID:hj+ftEk+複製おじさんと呼ばれてるRustスレでは有名な荒らし
しかもそいつが「RustJP公式 」の中の人で間違いなさそうって話だから手に負えない
0188デフォルトの名無しさん
2023/03/07(火) 10:27:35.30ID:QCj9HjAv「RustJP自称公式 」なのでなんの問題もない
0189デフォルトの名無しさん
2023/03/07(火) 11:40:31.33ID:gZ1LpnCSそれはお前用語なんじゃね?
0190デフォルトの名無しさん
2023/03/07(火) 11:55:27.75ID:CdvGJ9oAy も a も x も変数としか言いようがない
0191デフォルトの名無しさん
2023/03/07(火) 12:47:12.28ID:CHI/c7S+最適化してしまうかaという入れ物残しとくか更にはf(a)も計算して結果だけ使うか
0192デフォルトの名無しさん
2023/03/07(火) 21:59:54.08ID:6AJw5hNkC++ならクラスのインスタンスを生成する場合などを考えるとわかりやすい
コンパイル時点でそのインスタンスを定数化できる時にconstexprを使い静的に定数となる
そうでなく実行時にならないと値が定まらない変数となる時はconstexprを使えない
その変数がimmutableつまり生成以降は値を変更できない時はconstを使う
0193182
2023/03/07(火) 22:28:59.56ID:oSHTm7sl少数でも文字列でも適当に読み替えてね
0194デフォルトの名無しさん
2023/03/08(水) 00:26:55.95ID:Ax/TB2dRC++の命名ミスだな
定数にconstと命名すべきであり
immutableな変数にconstと命名すべきでなかった
0195デフォルトの名無しさん
2023/03/08(水) 00:36:06.87ID:o1WhyvRq0196デフォルトの名無しさん
2023/03/08(水) 00:46:11.75ID:+ZMcnEdg0197デフォルトの名無しさん
2023/03/08(水) 01:01:29.10ID:qkb67oYH0198デフォルトの名無しさん
2023/03/08(水) 01:22:37.49ID:9h+oJZcX昔はimmutableとconstantの概念の区別が曖昧だった
0199デフォルトの名無しさん
2023/03/08(水) 01:53:12.26ID:CbNEQcSB#define immutable const
0200デフォルトの名無しさん
2023/03/08(水) 02:01:56.79ID:3vDDzLqz>>174
0201デフォルトの名無しさん
2023/03/08(水) 07:29:50.16ID:OMAPV4fURustでconstは常に静的な定数を表す
*constはconstとは全く別のものであり予約語を最小限にするための使い回し組み合わせ
両者は種別も異なるため混乱することもない
constは定数の定義なのでこの位置に来る
let foo: i32 = 12345;
const FOO: i32 = 12345;
*constは生ポインタの型を示すのでこの位置に来る
const BAR: &i32 = &FOO;
const BAZ: *const i32 = &FOO;
このように両者は全く別物で出現位置も異なり共存もでき混乱することもない
この生ポインタはunsafe Rustでしか使わないため通常は出て来ない
そのために新たな予約語を消費するのは馬鹿げているため既存の組み合わせという合理的な選択をした
0202デフォルトの名無しさん
2023/03/08(水) 07:30:57.28ID:/qygPgTx元々Cがシステムプログラミング向けだったことを思えば、「リードオンリーセクションに置け」っていうくらいのつもりだったんだろ。
定数は#defineで指定しろって感じかな。
0203デフォルトの名無しさん
2023/03/08(水) 08:49:19.07ID:w2ee/I/N> この生ポインタはunsafe Rustでしか使わないため通常は出て来ない
safeの範囲で普通に使うけど
参照の同一性比較とか書いたことないの？
0204デフォルトの名無しさん
2023/03/08(水) 09:00:01.62ID:OMAPV4fU参照の比較は生ポインタ直接比較ではなくstd::ptr::eqを使うのが行儀良いマナー
参照を渡せば*constに自動でcoerceされるためコードに*constを記述する必要はない
0205デフォルトの名無しさん
2023/03/09(木) 14:43:18.74ID:lc0skjdv0206デフォルトの名無しさん
2023/03/09(木) 19:02:01.89ID:33ubz+zP0207デフォルトの名無しさん
2023/03/11(土) 11:27:51.97ID:E47xdjIQVBも同じ理由で使ってるだけで駄目プログラマとみなされていったから、
同じようにRustを使ってるだけで駄目プログラマ決定されてしまう気がする。
0208デフォルトの名無しさん
2023/03/11(土) 11:29:57.74ID:E47xdjIQVBもそうなったから、中味はそう変わってないのに名前を変えてC#にされた。
しかし、だんだんと、C#もVBと同じように馬鹿プログラマ専用言語とみなされる
ようになってきてる。
Rustもきっとそうなるだろう。
0209デフォルトの名無しさん
2023/03/11(土) 14:27:01.34ID:lvldJuuVたとえば第七章のパッケージとグレートの話とかでも
-------
最初に学ぶモジュールシステムの要素は、パッケージとクレートです。 クレートはバイナリかライブラリのどちらかです。 クレートルート (crate root) とは、Rustコンパイラの開始点となり、クレートのルートモジュールを作るソースファイルのことです
--------
英文の方は版が新しいこともあってか
The first parts of the module system we’ll cover are packages and crates.
A crate is the smallest amount of code that the Rust compiler considers at a time. Even if you run rustc rather than cargo and pass a single source code file (as we did all the way back in the “Writing and Running a Rust Program” section of Chapter 1), the compiler considers that file to be a crate.
と、いう具合で以下だいぶ丁寧に解説してる。
パッケージにはa library crateとあるから一つだけなの？とChatGPTに尋ねたら複数入ることもあると断言されたけど。
0210デフォルトの名無しさん
2023/03/11(土) 14:31:08.67ID:+PZMhSrI> モジュールシステムで最初に取り上げるのは、パッケージとクレートです。
>
> クレートは、Rustコンパイラが一度に考慮する最小のコード量です。cargoで
> はなくrustcを実行し、1つのソースコードファイルを渡したとしても（第1章
> の「Rustプログラムの作成と実行」でやったように）、コンパイラはそのファ
> イルをクレートと見なします。
0211デフォルトの名無しさん
2023/03/11(土) 16:27:23.47ID:BtFFfdHVひどすぎるのには同意するが
それはボランティアによる非公式な翻訳で
識者による監修や査読がされてないから
質が低いのは当然といえば当然
一部専門用語を除くと機械翻訳のほうが
それよりはマシな訳になることが多いので
多少英語が苦手でも公式を見たほうが断然効率がいいよ
0212デフォルトの名無しさん
2023/03/11(土) 16:39:48.49ID:47WJOH0Y7章の最初のページ見ればそれぞれどういう関係なのか一目瞭然
単数形複数形の違いを丁寧に訳してなければ重要な意味が日本語訳では消えてるかもね
・Packages: A Cargo feature that lets you build, test, and share crates
・Crates: A tree of modules that produces a library or executable
・Modules and use: Let you control the organization, scope, and privacy of paths
・Paths: A way of naming an item, such as a struct, function, or module
0213デフォルトの名無しさん
2023/03/11(土) 17:28:34.44ID:/GMTezZ0そのページは原文の2年半以上前の状態止まってる
日々改善されてるOSSで数年単位の遅れがあると全く役に立たないから
現状はRustの日本語ドキュメントは無いものと思っておいたほうがいい
0214デフォルトの名無しさん
2023/03/11(土) 18:00:56.32ID:bkYlWMhE原文のいつの状態を反映した訳なのか全然管理できてないらしいからね
アップデートは望み薄
0215デフォルトの名無しさん
2023/03/11(土) 19:45:03.63ID:+PZMhSrIかと言ってC++が登場したときのように
今はプログラミング言語の実装が
いくつも出てくる状況でもないのかな?
0216デフォルトの名無しさん
2023/03/11(土) 22:12:18.37ID:GtLfWJGzC++での混乱と失敗を繰り返さないことが重要
0217デフォルトの名無しさん
2023/03/11(土) 22:59:17.84ID:+PZMhSrI0218デフォルトの名無しさん
2023/03/11(土) 23:05:20.16ID:2/rFH0prマジかよw
たかだか100個程度のファイルが管理できないってどんだけよ
0219デフォルトの名無しさん
2023/03/11(土) 23:19:14.88ID:ChsfUoNW一方で言語仕様とその実現方法が確定して枯れた時は複数実装のメリットが上回る
Rustについては更なる理想の言語に向けて公開todoリストも多くまだ発展段階なので複数実装は向いていない
もちろん従来的な使い方ならば現状のRustで既に十分に利用できる
0220デフォルトの名無しさん
2023/03/11(土) 23:24:45.49ID:uRw385pvユーザーフォーラムのしかもたった二人の回答を「公式コミュニティの見解」にしてしまうオツムの人達だからさ一般常識があると思ったら大間違い
0221デフォルトの名無しさん
2023/03/11(土) 23:30:52.30ID:+PZMhSrI3行目は全否定しておく
CやC++に複数の実装があった第一の要因は開発ツールが売れたという背景がある
Rustに限らず開発ツールは最早ビジネスとしては成り立たなくなってしまった
0222デフォルトの名無しさん
2023/03/11(土) 23:34:33.13ID:2T5UBlcfあれ痛いよね
でもピン留めして晒し上げるのはさすがにどうかと思うわ
0223デフォルトの名無しさん
2023/03/11(土) 23:39:25.95ID:ChsfUoNWもちろんrust-analyzerはLSPなのでVScodeなどの既存の統合開発環境で使える
0224デフォルトの名無しさん
2023/03/11(土) 23:51:17.37ID:3ENT9RfURustユーザーの大半は英語のドキュメントを直接見てるからな
同じRustユーザーというだけであのリテラシーレベルと同類扱いされるのは誠に遺憾
0225デフォルトの名無しさん
2023/03/12(日) 06:07:53.91ID:b0Zzr0Fl一目瞭然ってことはないよ。
わかってるやつにはわかるっていうレベル。
特にmodule and use以下で戸惑うと思うよ。
Rustはプログラミング言語としてはCとかで神経使っていたところで楽させてくれる感じだけど、新人を呼び込むにはドキュメントがまずいかなあ。
0226デフォルトの名無しさん
2023/03/12(日) 09:19:37.91ID:XJpeOWKzJavascriptってドキュメントすっごい充実してるよな
2000年以前はHTMLとJavascript一緒になった解説本の最後の方に申し訳程度に乗ってたくらいで
あとは某とほほサイト見るくらいしかなかったけど
最近ちらっとみたらすごいのな
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/find
これは適当にクリックした特に選んでない一例だけど
ちょっと過剰なくらい説明と例が乗っててスゴイと思ったわ
Rustにここまでを要求したほうがいいとも思わんけど
いつかみんなが使う言語になったときはそうなってるのかもしれん
0227デフォルトの名無しさん
2023/03/13(月) 09:18:51.45ID:65XUJIc/0228デフォルトの名無しさん
2023/03/13(月) 11:30:57.14ID:QpsvkUdl0229デフォルトの名無しさん
2023/03/13(月) 12:04:07.60ID:wwEuDEVqほんと。自分もノーマークだったけどすごいね。
Rustも「英文ドキュメント読め」みたいに突っぱねいようにしなくちゃね。
Rustのサイトで各国語にトランスレートされたもののリンク先の更新日付を眺めてると、中国語版に負けてる感じだね。
0230デフォルトの名無しさん
2023/03/13(月) 12:11:38.79ID:CJ8zcgHs0231デフォルトの名無しさん
2023/03/13(月) 12:13:17.03ID:bP2+YJD9CSSのpositionとか
0232デフォルトの名無しさん
2023/03/13(月) 14:43:06.35ID:wwEuDEVqで、メモリ安全ってことだけをひたすらリピートするだけでは、新しい人は来ないでくださいと言ってるようなもん。
まあ、その方がチンケな優越感に浸れて良いのかもしれないけど。
0233デフォルトの名無しさん
2023/03/13(月) 15:10:59.37ID:cwbZasxHWasmのところも日本語版は古い情報のままなので肝心なAPIが足りていなくて英語版を見ないと致命的
リンク先が訳せてなくて英語版を指しているのは次善策としてまだマシ
英語版
https://developer.mozilla.org/en-US/docs/WebAssembly#api_reference
日本語版
https://developer.mozilla.org/ja/docs/WebAssembly#api_%E3%83%AA%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B9
0234デフォルトの名無しさん
2023/03/13(月) 15:27:59.03ID:kyo182dJスマートポインタで充分なんだし
チームで書くときにメモリ管理が怪しい奴が混ざり得るときに
Rustで書くことを強制されるってシチュエーションはありえるかもね
0235デフォルトの名無しさん
2023/03/13(月) 15:42:51.26ID:sbzZb6rB両方書いてると差は歴然
Rustは可読性もよいし開発効率もよく
特に実行時デバッグが激減するのも大きい
やむをえない場合を除いてC++を使い続けるメリットはない
0236デフォルトの名無しさん
2023/03/13(月) 15:54:03.52ID:kyo182dJ>Rustは可読性もよいし開発効率もよく
そんなのは人によるとしか言えない
所有権に割と馴染みがあるC++プログラマはともかく
他の言語からだと文法の解離に抵抗はあるだろうね
これからプログラミングを始めようという人は
特にRustだからという抵抗はないだろう
実績が増えればRustからって人が増えるかもね
0237デフォルトの名無しさん
2023/03/13(月) 16:03:04.23ID:UI2Ct8M3それよりもRustはまだ新しいから、何かしら思わぬ脆弱性が潜んでいることも考えて、まだ弄りながら様子見って感じ
0238デフォルトの名無しさん
2023/03/13(月) 18:05:23.37ID:QpsvkUdl0239デフォルトの名無しさん
2023/03/13(月) 18:37:31.12ID:cwbZasxH初心者や素人はC++でもRustでもなくBASICやPythonをやっていればいい
C++もRustも書きこなせる人なら自明なようにRustがはるかに効率いい
0240デフォルトの名無しさん
2023/03/13(月) 19:04:23.67ID:sbzZb6rBデバッグツールを持ち出さなくてもRustはコンパイル時点でほとんど解決する点で圧倒的に優れている
Rustはメモリ安全性だけでなくデータ競合がないことがコンパイル時点で保証される
ポインタ以外の汎用的なヌル安全とエラー処理忘れ防止もRustは標準ライブラリ全体でOptionとResult利用により保証される
C++と比べて開発効率が段違いに良くなる
0241デフォルトの名無しさん
2023/03/13(月) 19:17:45.07ID:9XZC5W3hRustなんて補助輪付きの言語はプロのプログラマッには温すぎる
コーディングに自信がない奴や素人向けだな、Rustは
0242デフォルトの名無しさん
2023/03/13(月) 19:49:16.47ID:zhi7FkgJC/C++はプログラマとして成長させてくれるよね
0243デフォルトの名無しさん
2023/03/13(月) 19:51:01.09ID:cwbZasxHC++はデバッグ時間のムダ
0244デフォルトの名無しさん
2023/03/13(月) 20:02:48.32ID:lNJwESa50245デフォルトの名無しさん
2023/03/13(月) 20:04:22.18ID:lNJwESa50246デフォルトの名無しさん
2023/03/13(月) 20:07:14.22ID:4NzLTP/20247デフォルトの名無しさん
2023/03/13(月) 20:22:48.71ID:4VuAJC20変わった言語なので
まず初めに学んだほうが先入観がなく覚えられるよ
そのためにも日本語のドキュメントは
整備したほうが良い
0248デフォルトの名無しさん
2023/03/13(月) 20:39:22.66ID:RfKK3GLn0249デフォルトの名無しさん
2023/03/13(月) 20:45:38.95ID:sbzZb6rBその通りでC++は無駄なデバッグ時間が必要となるけど
テストで発見できなかった分はデバッグもされず実行時のセキュリティ含めたバグとして残ってしまう
Rustならばコンパイル時点ですべて排除できる
>>244
勉強不足すぎだ
C++のスマポで解決できることはRustで解決できることのほんの一部にすぎない
0250デフォルトの名無しさん
2023/03/13(月) 21:04:50.75ID:kyo182dJ>勉強不足すぎだ
>C++のスマポで解決できることはRustで解決できることのほんの一部にすぎない
他は?
0251デフォルトの名無しさん
2023/03/13(月) 21:41:54.90ID:Lx/25M/Kそんなことも知らずにこのスレで書き込み続けているのかよ
他の人たちの書き込みを読んでないのかよ
0252デフォルトの名無しさん
2023/03/13(月) 21:46:41.78ID:kyo182dJ他は? GCしか書けない人なのかな?
0253デフォルトの名無しさん
2023/03/13(月) 22:00:51.65ID:sbzZb6rB既にたくさん書いて伝えた
理解できなかったのか？
0254デフォルトの名無しさん
2023/03/13(月) 22:16:19.15ID:P8sbSRo20255デフォルトの名無しさん
2023/03/13(月) 22:35:49.32ID:kyo182dJ本当にGCしか知らないんだな
>>249
>勉強不足すぎだ
熨斗をつけてそのままお返ししよう
0256デフォルトの名無しさん
2023/03/13(月) 22:38:39.16ID:Lx/25M/KC++もRustもGC無いぞ
0257デフォルトの名無しさん
2023/03/13(月) 22:43:20.72ID:kyo182dJんなことぁ誰でも分かってる
0258デフォルトの名無しさん
2023/03/13(月) 23:26:56.50ID:sbzZb6rBGC言語も使うしC/C++/Rustも使う
速さと省メモリの点でGC言語は不利だから使い分ける
0259デフォルトの名無しさん
2023/03/13(月) 23:40:00.84ID:kyo182dJ>勉強不足すぎだ
>C++のスマポで解決できることはRustで解決できることのほんの一部にすぎない
だから他は?
0260デフォルトの名無しさん
2023/03/13(月) 23:52:11.42ID:9+eE28f9C++スマートポインタは
unique_ptrは使わずともRustでは標準で全て自動解放されるよ
shared_ptrはRustではスレッド内で使えるRcとスレッド間で使えるArcに分かれていて効率的だよ
0261デフォルトの名無しさん
2023/03/14(火) 00:08:40.65ID:nARWep6y別にunique_ptrやshared_ptrでええがな
難しくないよ
>shared_ptrはRustではスレッド内で使えるRcとスレッド間で使えるArcに分かれていて効率的だよ
効率的をも少し詳しく!
0262デフォルトの名無しさん
2023/03/14(火) 00:17:28.43ID:g2aa4i950263デフォルトの名無しさん
2023/03/14(火) 00:51:48.86ID:mRkuEIyQshared_ptrは常に排他制御されコストが高い
共有を増減すると排他制御のコストがかかる
さらに単なる受け渡しも要注意でmoveしないとそのコストが無意味に余分にかかってしまう
一方でRustは排他制御するArcとしないRcの2つが用意されていてそれらの問題なく使い分けられる
>>262
Rustはコンパイルが通った時点でデータ競合がないことを保証されるのでかなり楽
0264デフォルトの名無しさん
2023/03/14(火) 00:58:40.53ID:Ff/IlIXh排他制御の意味も知らないのかよこいつw
0265デフォルトの名無しさん
2023/03/14(火) 01:09:54.31ID:gRogmLJeその代わり重い
0266デフォルトの名無しさん
2023/03/14(火) 01:26:54.27ID:nARWep6yなるほどね
std::shared_ptrには参照カウンタの排他制御をオフにする機能はなかったかな?
boost::shared_ptrだと美しくないけどBOOST_SP_DISABLE_THREADSマクロで切り替えられる
最近使ってないがLoki::SmartPtrは確かテンプレートパラメータで切り替えできたかな?
0267デフォルトの名無しさん
2023/03/14(火) 01:58:37.91ID:gRogmLJeスレッド内のみの共有はRc
スレッド間での共有はArc
切り替えでなく最初から二種類が用意されるべき
0268デフォルトの名無しさん
2023/03/14(火) 02:06:25.73ID:nARWep6y同意
std::shared_ptrもLoki::SmartPtrみたいに
テンプレートパラメータで切り替えできれば良いのにね
ただしstd::shared_ptrを規格に入れた時点で
既にboost::shared_ptrもLoki::SmartPtrもあったことを考えると
参照カウンタが競合する機会はほとんどないという見立てで
実装を単純化したのかなと予想する
誰か経緯を知らんかな?
0269デフォルトの名無しさん
2023/03/14(火) 02:13:23.45ID:nARWep6y#include <memory>
#define BOOST_SP_DISABLE_THREADS
#include <boost/shared_ptr.hpp>
template <typename T> using Arc = std::shared_ptr <T>;
template <typename T> using Rc = boost::shared_ptr <T>;
0270デフォルトの名無しさん
2023/03/14(火) 02:59:21.97ID:u9OB+g2bshared_ptrで排他制御される対象はreference counterの増減だけであり、指している値の読み書きはもちろん排他制御されない。
したがってshared_ptrはスレッドセーフだから安心だと誤解していると、危険なプログラムが出来上がるリスクがある。
C++ではプログラマーがこれらの誤解や見落としやミスを全くしないことを求められ、それに依存するためプログラムの安全品質は危うい。
Rustではその点も安全で、Arc<T>はTへの書き込みが出来ないため、排他制御の問題は起きない。
書き込みしたいならば、Arc<Mutex<T>>やArc<RwLock<T>>など必要となる排他制御の種類に合わせて選び、組み合わせて利用する。
それら組み合わせにより、Tへの書き込みができるようになるが、必ずロックで排他制御されるため問題は起きない。
たとえプログラマーが見落としやミスや使い間違えをしても、Rustコンパイラがエラーを出し、該当箇所を教えてくれるため、常に安全性が保証される。
0271デフォルトの名無しさん
2023/03/14(火) 03:15:26.07ID:nARWep6yMutex <T>を書けば良いのではないかな？
0272デフォルトの名無しさん
2023/03/14(火) 03:19:38.24ID:nARWep6y>shared_ptrで排他制御される対象はreference counterの増減だけであり、指している値の読み書きはもちろん排他制御されない。
>したがってshared_ptrはスレッドセーフだから安心だと誤解していると、危険なプログラムが出来上がるリスクがある。
想定してるレベルが低すぎる
マルチスレッドで書くやつにそんなやつはいない
議論が無理やり過ぎ
0273デフォルトの名無しさん
2023/03/14(火) 03:33:56.57ID:u9OB+g2bその件に限らずすべてにおいて、勘違い、見落とし、ミスなどは発生する。
複雑化したときにmutex忘れも、shared_ptr忘れも、間違えてunique_ptr使いも、その他のミスも、何でも実際に起きている。
Rustではそれらが起きてもコンパイラが通さないことで、常に安全性が保証され、無駄なデバッグを避けられる。
C++では無駄なデバッグを招くか、もしくは、そのままリリースしてセキュリティの穴が生じてしまう。
現実にC++が多数の問題を引き起こしてきた。
0274デフォルトの名無しさん
2023/03/14(火) 12:05:32.83ID:CPf3ZEOa0275デフォルトの名無しさん
2023/03/14(火) 12:21:44.83ID:nARWep6y「Rustはコンパイルが通っていればマルチスレッドで
競合問題が起きないことが保証される」
これで正しい? 正しいとすれば
マルチスレッドを習得したときの苦労を考えると有用なので
新しくプログラミングを始める人には勧めたい動機になる
俺自身は困ってないので使おうとはあんまり思わんけどね
0276デフォルトの名無しさん
2023/03/14(火) 12:39:04.29ID:RkFbHwTA一番は安全装置とかに使われる小規模な組み込みソフトかな。
CPUとか開発環境とかがまだ整ってないだろうから、ゆっくりだと思うけど
0277デフォルトの名無しさん
2023/03/14(火) 12:50:59.56ID:nARWep6yUNIX（C）やMFC（C++）や.NET（C#）のように
大手がプロダクトに採用してトップダウンで流行らせるしか
普及の道はないと思う
ゆっくり普及なんてのはないと思う
0278デフォルトの名無しさん
2023/03/14(火) 19:34:32.70ID:/poSvH9Z0279デフォルトの名無しさん
2023/03/14(火) 19:40:00.62ID://qYwEcnここ十数年だと人類一番の功績じゃね
良い点：
シンプルさ。C#で言う値型を入れようかどうか迷ったときもあったんだろうけど（想像）、
プリミティブと参照型変数の二個だけでやってくという線引がセンスある。
悲しい点：
立てまし。個人的にはジェネリクスもいらんかった。
C++のテンプレートを潔く排除して出てきたのすごいすっきり感あった。
でもあとでジェネリクスは押し負けて？付いてきちゃったけど。
あと貧相な貧相なラムダ式。クロージャを期待したけど結局はanonymous classのといっしょ。
異論は無いと思う
0280デフォルトの名無しさん
2023/03/14(火) 22:31:24.61ID:CPQICLeaRustはマルチスレッド時でもマルチタスク時(＝グリーンスレッドをRustではタスクと呼ぶ)でも
データ競合を起こさないことが静的に保証されている
唯一のプログラミング言語
0281デフォルトの名無しさん
2023/03/14(火) 23:07:45.86ID:5gRl/D4e0282デフォルトの名無しさん
2023/03/14(火) 23:17:29.22ID:CPQICLeaRust以外の言語があるならば教えて
0283デフォルトの名無しさん
2023/03/14(火) 23:54:49.43ID:AgG33ThB0284デフォルトの名無しさん
2023/03/15(水) 02:10:25.53ID:itMePwRG0285デフォルトの名無しさん
2023/03/15(水) 02:53:43.28ID:aLgn/lBf0286デフォルトの名無しさん
2023/03/15(水) 03:26:18.55ID:DXTHIxnh万一普及したとしてバカが使いこなせるはずもなく
0287デフォルトの名無しさん
2023/03/15(水) 07:08:24.89ID:SNoM8taVロケットをわざわざ Rust で描き替えて墜落しても
Rust は悪くない悪いのは GC のせいだと言い張るのが
Rust 信者
0288デフォルトの名無しさん
2023/03/15(水) 09:03:13.60ID:n0l+w21lAndroid(Java)
iOS(Objective-C++)
0289デフォルトの名無しさん
2023/03/15(水) 09:51:38.96ID:d2iGalsS0290デフォルトの名無しさん
2023/03/15(水) 10:13:26.89ID:aLgn/lBfC++もRustもGCないよ
0291デフォルトの名無しさん
2023/03/15(水) 10:52:34.36ID:d/hulDPrhttps://wired.jp/article/rust-secure-programming-language-memory-safe/
Androidでは今、暗号鍵を管理する機能の多くがRustで書かれているとGoogleのクライダーマーカーは話す。
たとえば、暗号化したインターネット通信の機能である「DNS over HTTPS」、新バージョンの超広帯域無線（UWB）チップスタック、
そしてグーグルの独自のチップである「Tensor G2」で使用される新しい「Android 仮想化フレームワーク（AVF）」 などもRustで書かれている。
また、BluetoothやWi-Fiなどの通信接続に使われるスタックも、Androidの開発チームによってRustへの変換が積極的に進められている。
理由は、これらが業界の複雑な標準規格に基づいており、脆弱性を多く含む傾向にあるからだとGoogleのクライダーマーカーは付け加える。
つまり最も狙われやすい、あるいは最も重要なソフトウェアの部分からRustに書き換えて、
そこから徐々にRustで書く範囲を広げることで段階的にセキュリティ上の恩恵を受けようという戦略である。
0292デフォルトの名無しさん
2023/03/15(水) 10:57:42.49ID:QVyWv/mnデッドロックは静的検出はできないでしょ?
0293デフォルトの名無しさん
2023/03/15(水) 12:50:04.82ID:FGvum1vT0294デフォルトの名無しさん
2023/03/15(水) 15:17:28.42ID:6d2zOTAf両方無い日本企業には無理無理カタツムリ
0295デフォルトの名無しさん
2023/03/15(水) 19:11:32.56ID:Raq+Bs5u0296デフォルトの名無しさん
2023/03/15(水) 19:46:51.43ID:rzl5B1H1Rustがターゲットとしているところで
プログラミングをやるなら
現状でCの習得は避けて通れない
となると学習コストの問題で
文法がほぼ包含関係にあるC++を選ぶことになる
OSの基盤からRustにしないと一向に増えないよ
0297デフォルトの名無しさん
2023/03/15(水) 19:49:13.81ID:N9nUYl96うだうだ続けたい奴はコード書く能力もないからここで自己顕示欲発揮しちゃうんだろｗ
0298デフォルトの名無しさん
2023/03/15(水) 19:50:50.82ID:zbLR3nEh>>294
ほとんどのシステムは複数のプログラムから構成されているため
それら各機能をグレードアップで更新するときにRustへ書き換えることで進んでいる
もちろん新規システムは最初からRustで書くことが多くなっている
0299デフォルトの名無しさん
2023/03/15(水) 19:55:49.97ID:rzl5B1H1トップダウンで基盤を整備するしか有り得ない
Cと文法が乖離してるのはメリットもあるだろうけど
普及にはデメリットとして働いている
0300デフォルトの名無しさん
2023/03/15(水) 20:02:03.89ID:zbLR3nEhこの動きはそれが出来るところから着実に進んでいるので止めようがない
0301デフォルトの名無しさん
2023/03/15(水) 20:52:20.68ID:QVyWv/mn>新規システムはC/C++禁止でRust必須が要件
どこで?
0302デフォルトの名無しさん
2023/03/15(水) 21:00:17.63ID:QVyWv/mnMSを見ていればまぁ自明だわな
0303デフォルトの名無しさん
2023/03/15(水) 21:15:24.65ID:itMePwRG0304デフォルトの名無しさん
2023/03/15(水) 21:55:22.51ID:46PmQs8i発表デモでなぜかPythonからRustへ
https://www.msn.com/en-us/news/technology/microsoft-s-new-bing-ai-chatbot-arrives-in-the-stable-version-of-its-edge-web-browser/
2023/03/15
本日マイクロソフトは、Edgeウェブブラウザの安定バージョンのサイドバーに、新しいBing AIチャットボットが含まれるようになったことを発表しました。
デモンストレーションで、AIにStack Overflowのヒントを調べながらコードのスニペットを書くように依頼しました。
AIはPythonコードをRustに変換することができました。
0305デフォルトの名無しさん
2023/03/15(水) 21:58:57.19ID:46PmQs8i正しいURLはこれ
https://www.msn.com/en-us/news/technology/microsoft-s-new-bing-ai-chatbot-arrives-in-the-stable-version-of-its-edge-web-browser/ar-AA18CPK2
0306デフォルトの名無しさん
2023/03/15(水) 22:07:43.40ID:QVyWv/mn自然に増えるもんじゃない
0307デフォルトの名無しさん
2023/03/15(水) 22:20:44.44ID:46PmQs8i日本語ドキュメントも充実してる
Rustを使用したWindowsでの開発
https://learn.microsoft.com/ja-jp/windows/dev-environment/rust/overview
0308デフォルトの名無しさん
2023/03/16(木) 00:10:36.78ID:srO8KDRmhttps://learn.microsoft.com/ja-jp/windows/dev-environment/
0309デフォルトの名無しさん
2023/03/16(木) 00:12:05.34ID:srO8KDRm0310デフォルトの名無しさん
2023/03/16(木) 00:25:01.88ID:AJSi61e9何もかも優れているRustの勝利
疑われる「C++」の安全性、今後の動きはどうなる
https://japan.zdnet.com/article/35199018/
0311デフォルトの名無しさん
2023/03/16(木) 06:24:59.05ID:R4dgmdECならば、RustなAPIにC++がきちんと接続できるようになってもおかしくない
そうすると、Rustが実績を積んだ「正しい縛り」を、C++でも使えるようになってくるんではないだろうか
もうそういう試みある?
0312デフォルトの名無しさん
2023/03/16(木) 08:50:45.88ID:zwODLYWH0313デフォルトの名無しさん
2023/03/16(木) 09:08:29.35ID:wZlU7tIR既にRustとC++の相互呼び出しは実現されているが
Rustから見てC/C++部分は当然unsafe扱い
最終的にC/C++部分が無くなる形で完成することになる
0314デフォルトの名無しさん
2023/03/16(木) 09:15:14.89ID:3C3pOHVnだとしたら、境界面であるAPIには、縛りにかかる属性情報が露出するはず
C++がそれに対応できないなら、今後C++ではアプリケーションを書けないことになってしまう
0315デフォルトの名無しさん
2023/03/16(木) 09:54:57.99ID:hwbAfXXmRustの方が書きやすいとほとんどの人が言うほど差があるのだから、
C++がいずれ消えるのは間違いない。
0316デフォルトの名無しさん
2023/03/16(木) 10:39:34.81ID:N2/NSeFa>能力ある人からRustへ移行していってる
まるでKENYAの作文だな
0317デフォルトの名無しさん
2023/03/16(木) 10:43:46.43ID:fxj0X8UB0318デフォルトの名無しさん
2023/03/16(木) 10:45:31.49ID:X3XJCWQc0319デフォルトの名無しさん
2023/03/16(木) 10:57:52.25ID:n4rBBOEiもちろんRustの変数を使う形でインラインアセンブリをRustでは記述できるが
当然ながらRustコンパイラによる保証範囲外となるunsafe部分になる
Rustはunsafe部分のみ人間が安全性を担保すれば全体についてはRustコンパイラが保証する形で役割分担できる
その点でプログラム全体が常にunsafe状態となってしまうC/C++とは根本的に異なる
0320デフォルトの名無しさん
2023/03/16(木) 10:59:13.64ID:mkPG1w5Oここの最後の方に載ってるよ
https://quick-lint-js.com/blog/cpp-vs-rust-build-times/
OSによっても違うみたいだけど、C++の方がちょっと早いくらいだね
0321デフォルトの名無しさん
2023/03/16(木) 11:04:29.29ID:srO8KDRmスマホみたいな何らかの新しいハードウェアが誕生して
それがRust製で書かれたOSで制御されている状況にならんと普及はせんよ
0322デフォルトの名無しさん
2023/03/16(木) 11:11:37.43ID:r79frV++頭の弱い子ですね
JavaやPerlやJavaScriptやRubyやPHPやPythonなどで書かれたOSは普及していませんが
それらの言語は普及しました
0323デフォルトの名無しさん
2023/03/16(木) 11:19:37.68ID:srO8KDRmJavaやPerlやJavaScriptやRubyやPHPやPython使ってるところで普及はするかもね
じゃこれで良い? ニッチと言って分かるかな?
0324デフォルトの名無しさん
2023/03/16(木) 11:22:05.57ID:3C3pOHVn0325デフォルトの名無しさん
2023/03/16(木) 12:18:46.17ID:xA7F3jfw自分が使って生産効率を上げたり良い作品を作って披露すれば良いだけなのに、
信者達が無理やり広めようとしているのが嫌だ。
困るのは、C++を使ってる人を馬鹿にすること。
0326デフォルトの名無しさん
2023/03/16(木) 12:23:14.36ID:0EJvJf6l0327デフォルトの名無しさん
2023/03/16(木) 12:23:28.58ID:xA7F3jfw彼らは5chやtwitterで徹底的にRustを褒めまくっている。
どうしてそんなことをするのか。思想家や哲学者なのか。
マルクスもそういう感じで結果、大勢の人々を苦しめた。
0328デフォルトの名無しさん
2023/03/16(木) 12:31:35.94ID:srO8KDRmRustを愛する者にとってはそこがフラストレーションなのでしょう
普及するパスが見えたら解消すると思うよ
0329デフォルトの名無しさん
2023/03/16(木) 12:37:22.05ID:3C3pOHVnエンジニアが本職なら、C++でもRustでも、なんでも読み書きできないといけないだろう
まあ、じきにC++も追いつくだろ 問題はC
0330デフォルトの名無しさん
2023/03/16(木) 13:52:30.33ID:xA7F3jfw必要あらば、どっちでも使うだろうが、C++でもメモリーエラーなんて滅多に
起こさないし、起きても原因究明して直せるから、敢えてRustに行く動機もない。
別にRustが使えないからC++を使ってるわけじゃないのに、Rust使う人の方が
憂愁みたいに言われるのはおかしい。
0331デフォルトの名無しさん
2023/03/16(木) 13:53:26.57ID:xA7F3jfw書き間違えた。
憂愁 ---> 優秀
0332デフォルトの名無しさん
2023/03/16(木) 13:55:47.65ID:xA7F3jfw「Rustは誇っていい」という意味が分かりにくい。Rustを作った人はちょっと
誇っていいかも知れないが、Rustの解説本を書いている人や、Rustを道具として
使っている人が誇っていいわけではない。
0333デフォルトの名無しさん
2023/03/16(木) 13:57:50.83ID:3C3pOHVnRust(言語と言語チーム)は誇っていい
その一派につらなる「信者」が誇るのは…まあ人の常かなって
0334デフォルトの名無しさん
2023/03/16(木) 14:00:22.48ID:xA7F3jfw>その一派につらなる「信者」が誇るのは…まあ人の常かなって
信者が誇って良い分けないと思うが。
0335デフォルトの名無しさん
2023/03/16(木) 14:06:46.30ID:3C3pOHVnC++に固執するのがもうクズ。っていう発想 それもわかるんだけどね
なんでも書けてこそのC++ 縛りを記述できないなんて、欠陥でしかない
だから、C++の進化には期待してる 遅々たるものになるかもしれないけど
0336デフォルトの名無しさん
2023/03/16(木) 14:20:33.51ID:xA7F3jfw>Rustに移れば、大多数の脆弱性は自然につぶれるのに、
>C++に固執するのがもうクズ。っていう発想 それもわかるんだけどね
本当に優秀ならば、C++でも脆弱性がが入らない。
mozillaやgoogleの社員がタコなだけ。
0337デフォルトの名無しさん
2023/03/16(木) 14:30:08.42ID:srO8KDRmC++からRustライブラリを呼ぶ場合もRustからC++ライブラリを呼ぶ場合も
文法違いすぎて大変そうだけどどうしてるんかな?
Cのライブラリを呼ぶのはどのプログラミング言語からでも余裕だけども
JavaとC++もかなり歪だよね?
0338デフォルトの名無しさん
2023/03/16(木) 14:31:40.01ID:hABarloL人間は必ずミスをするという当たり前のことも受け入れられない人はキチガイのみ
0339デフォルトの名無しさん
2023/03/16(木) 14:33:21.04ID:3C3pOHVn一人で作るもんでもないからねえ、大人数だと、体調の悪いヤツとかも混じるだろ
コンパイラに任せたいってのはわからんでもない
俺も、(たとえば)gccとヘッダライブラリに任せて、自分は気楽にごりごり書きたいｗ
0340デフォルトの名無しさん
2023/03/16(木) 14:34:51.94ID:srO8KDRm自信過剰も何もC++書ける人だとなぜに
スマートポインタで失敗するのか理解不能だよ
原因は生ポインタ使ってるからなんだろうけど
それなら生ポインタをプロジェクトで禁止にするだけで充分
あとマルチスレッドにおけるデッドロックはRustで検出できるのかい?
0341デフォルトの名無しさん
2023/03/16(木) 14:37:50.95ID:srO8KDRm0342デフォルトの名無しさん
2023/03/16(木) 14:39:57.56ID:3C3pOHVnC++でおんなじように書ければいいんだよ ハズしてたらコンパイルエラーになってくれてだな
Rustは実績を積んだ C++は早くその成果を取り込むべき
ラムダといいコルーチンといい、C++が他に学んだ前例はいくらでもある
>>341
まじそれ
0343デフォルトの名無しさん
2023/03/16(木) 15:04:51.89ID:bO6zkRLmそれはプログラマーのレベルが少なくとも俺よりは低いから。
0344デフォルトの名無しさん
2023/03/16(木) 15:07:17.05ID:3C3pOHVnお前みたいな優秀なヤツが、【わざと】脆弱性を仕込んだコードをコミットしたりするんだよｗ
他人は信用できねえ
俺クラスになったら、自分自身が一番信用できねえｗｗ
0345デフォルトの名無しさん
2023/03/16(木) 15:14:34.72ID:N2/NSeFa何分も待たされたらそりゃ遅いわ！！！ぷんぷんって
怒るアホも出て来るだろうね
0346デフォルトの名無しさん
2023/03/16(木) 15:18:25.89ID:N2/NSeFaRust(人気)は俺が育てた！(AA略)
0347デフォルトの名無しさん
2023/03/16(木) 15:36:54.04ID:07ACJDqQ現状では無理
C++33くらいで可能になるかもね
0348デフォルトの名無しさん
2023/03/16(木) 15:38:33.76ID:07ACJDqQ>あとマルチスレッドにおけるデッドロックはRustで検出できるのかい?
コンパイルエラーになるかという意味ならならない
その辺はGoとかと一緒でイディオムで対処
0349デフォルトの名無しさん
2023/03/16(木) 15:42:21.06ID:I4Z9PBKvメモリ安全だけだとあんまり有り難くないな
もしミスってもデバッガで直ぐ分かる訳だし
0350デフォルトの名無しさん
2023/03/16(木) 15:51:10.02ID:TBYrYTSUメモリ安全だけでなく
C++とは異なりRustはデータ競合を完全に防げる
C++とは異なりRustは広義のヌル安全であることも大きい
0351デフォルトの名無しさん
2023/03/16(木) 16:02:01.69ID:PpEtLqb1それでも言語が汚いから使いたくない。
0352デフォルトの名無しさん
2023/03/16(木) 16:24:46.13ID:TBYrYTSU言語機能が強力で可読性が高い
とくにパターンマッチング
これはC++でも導入しようとしているが進んでいないだけでなく
C++で出ている提案では強力でなく可読性もよくないようにみえる
Rustはパターンマッチングが非常に強力で可読性の向上の最大要因となっている
0353デフォルトの名無しさん
2023/03/16(木) 16:52:12.01ID:3grScBM3Rustかどうかは別として10年後くらいには
今Rustが実現してるやり方が標準的なものになるのは間違いないから
考え方やメリットデメリット、限界をある程度学んでおいた方がいいかもよ
Rust自体はいいところもあれば悪いところも沢山あるので実際に使うかどうかは状況次第
0354デフォルトの名無しさん
2023/03/16(木) 17:04:30.58ID:YeYGULup①エコシステム
②ライブラリ
なんじゃやいの？
①は流行ってきたら充実するものでニワトリと卵だけど、②はどうなん？
②が中々充実しないのは何かRustのライブラリ書いてやろうと言う人が出てこない理由あるんかな？
0355デフォルトの名無しさん
2023/03/16(木) 17:12:09.28ID:3C3pOHVn>>353
10年後には、いまRustが提示しているものを踏まえた、さらにスマートなものが出ているかもしれない
でも、それを理解するには、ここから10年間、Rustの成果を学び、踏まえるのがいい だから俺はいま学ぶぜ
願わくば、10年後にも、しぶとい感じでC++が現役であってほしいな
0356デフォルトの名無しさん
2023/03/16(木) 17:15:50.99ID:QTF1+6wX例えば話が出ている広い意味のnull安全はC++がoptionalの導入をとっくに行っているが
・なかなか普及しない
・既存ライブラリの仕様とのチグハグ
・パターンマッチング機能の導入がまだなので使い勝手が悪い
などの問題が山積みであまり使われていない
C++の他の機能導入でも似たような状況が多い
Rustが美しく書きやすく読みやすいのはそれらの多くが最初から解決されているからだと感じる
C++をさっさと棄てるのが現実解であると理解できた
0357デフォルトの名無しさん
2023/03/16(木) 17:23:01.97ID:3C3pOHVnRustには引き算の美学の成果が入ってる
C++も、先頭で縛りを宣言できるようにして、美しく書けるようになるべきだ 絶対に
0358デフォルトの名無しさん
2023/03/16(木) 17:47:47.57ID:VzH+f4s6大抵はテストツールまで書かないと使えない
0359デフォルトの名無しさん
2023/03/16(木) 19:59:01.19ID:srO8KDRmコンストラクタでlockしてデストラクタでunlockするproxyクラス作って
その一時オブジェクト経由で触れば良いだけなので何を今更という感じ
メモリ安全は別にデバッガですぐ特定できるし
マルチスレッドではRustの利点がない
デッドロックが検出できたらまぁ嬉しいが?
0360デフォルトの名無しさん
2023/03/16(木) 20:03:11.00ID:u3ZLVO1D0361デフォルトの名無しさん
2023/03/16(木) 20:03:55.24ID:srO8KDRm多くの人に使ってもらおうと思ったらCで書いて
各言語のラッパーを提供するってのが多い
RustにこのCの代わりができれば良いんだけども?
もしRustユーザしかリンクできないライブラリだったら
Rustはそもそもユーザー数が少ないし
Rustで書く動機が減る
0362デフォルトの名無しさん
2023/03/16(木) 20:07:00.05ID:srO8KDRm多人数でやるプロジェクトにはC++は自由過ぎて
その点は書き方にある程度拘束される意義はあると思う
0363デフォルトの名無しさん
2023/03/16(木) 23:56:33.56ID:ufHOK4fgありがと
意外と変わらないんだ
0364デフォルトの名無しさん
2023/03/17(金) 00:02:12.50ID:aeVIJ/KU0365デフォルトの名無しさん
2023/03/17(金) 00:04:03.80ID:aeVIJ/KU書き方はGitHubにいろんなOSSの見本があるから簡単でしょ？
0366デフォルトの名無しさん
2023/03/17(金) 00:04:27.28ID:aeVIJ/KU0367デフォルトの名無しさん
2023/03/17(金) 00:14:30.94ID:o5CBT2m0Rustで本体を書いて他の言語のバインディングって出来るの?
他の言語との乖離でRustならではの部分が封じられて
あんまり嬉しくないような気もするのだが?
それともRustでライブラリ書いたらターゲットはRustだけになるのかな?
0368デフォルトの名無しさん
2023/03/17(金) 00:14:49.50ID:6s2Kuhdf>Rustが美しく書きやすく読みやすいのはそれらの多くが最初から解決されているからだと感じる
俺とは感覚が違う。Rustを美しく感じない。
0369デフォルトの名無しさん
2023/03/17(金) 00:21:48.75ID:6s2Kuhdf・Rustの本を書きました。Rustは良い言語なので本を買ってください。
・Rust用のライブラリを書きました。Rustは良い言語なのでライブラリを買ってください。
これは理解できないし、問題:
・C++は害悪なのでRustをみんなが使って世の中を良くしよう。
・自分がC++を使いこなせないのに、使いこなせる人が許せないから、使いこなせるRustを普及させたい。
0370デフォルトの名無しさん
2023/03/17(金) 00:39:18.46ID:2hBAQcCo0371デフォルトの名無しさん
2023/03/17(金) 00:51:57.03ID:6s2Kuhdfそれも意見が分かれそうだ。
0372デフォルトの名無しさん
2023/03/17(金) 00:54:59.09ID:UJajhYy7出力をcdylibにすれば一般的なCソースのライブラリと同じ形式（soとかdll）で出力されるはず
当然FFI絡みの制約は出てくるしextern指定とかも必要だけど境界部分だけ気を付ければ内部は自由にRustできる
wgpuはRustで書かれたグラフィックライブラリだけどその機能をC/C++から呼ぶためのwrapperでwgpu-nativeがあって
さらにそのC用のwrapper経由で別言語（Pythonとか）のwrapperが作られてたりする
依存関係がややこしいけど
wgpu (Rust製、Rust用Lib出力) ← wgpu-native (Rust製、C用Lib出力） ← wgpu-py (C+Python製、Python用ライブラリ）
みたいな構造
0373デフォルトの名無しさん
2023/03/17(金) 01:04:51.03ID:o5CBT2m0なるほどー
0374デフォルトの名無しさん
2023/03/17(金) 05:58:07.48ID:HbMAHHRqRustならマルチスレッドでもマルチタスク(=グリーンスレッド)でも書きやすく
さらにデータ競合を完全に防げるRustしか現状の言語では選択肢ないと思うよ
各言語で書き比べてみれば一目瞭然
そのため並行並列を使うプログラムはC++→RustだけでなくJava→Rustの移行も進んでる
0375デフォルトの名無しさん
2023/03/17(金) 10:42:47.45ID:o5CBT2m0>>そのため並行並列を使うプログラムはC++→RustだけでなくJava→Rustの移行も進んでる
全く進んでいないのだが?w
俺の周りではC++やJavaでマルチスレッドで書く奴の方が多い
というかそもそもRustを使っている奴は一人もいないw
妄想なのか詐欺師なのか...
Linuxでも さもRustの導入が進んでるように言うが実際は>>39だし...
0376デフォルトの名無しさん
2023/03/17(金) 10:55:37.94ID:FKqwIQQI単純なWeb Serverくらいならいいがちょっと凝った処理を書こうとするとくっそ面倒くさい
tokio依存なのもダメなところ
0377デフォルトの名無しさん
2023/03/17(金) 11:06:44.98ID:tBmmskox結局、効率を求めたらC API に肉薄することになるし
0378デフォルトの名無しさん
2023/03/17(金) 11:15:24.56ID:TZnQdWAf誤解なきよう
0379デフォルトの名無しさん
2023/03/17(金) 11:17:48.64ID:RPqYd1dpマルチタスク(並行)で綺麗に書ける言語はRustとGoだけだな
GoはPromise(Future)使わないあのスタイルに寄せられるのとGC言語であるため
Rustが汎用では筆頭言語になる
0380デフォルトの名無しさん
2023/03/17(金) 11:33:47.61ID:Igk62yzoだよな
Rustの非同期が簡単だと勘違いしてるやつはチュートリアルレベルしかやったことないやつだと思うわ
0381デフォルトの名無しさん
2023/03/17(金) 11:43:37.53ID:RPqYd1dp自分でpollしたりするのも含めて色んなレベルで書いているが簡単だぞ
Rustで並行並列が難しいと言うならばとこが難しいのかを具体的に述べよ
そしてそのケースでRustの代わりに使える別言語があるならば述べよ
0382デフォルトの名無しさん
2023/03/17(金) 11:51:53.17ID:UWSndCzi0383デフォルトの名無しさん
2023/03/17(金) 12:19:57.65ID:CZQwnfV3そうやって自分が分かってない事を無料で聞き出してしまおうとする。ずる賢い。
0384デフォルトの名無しさん
2023/03/17(金) 12:31:22.55ID:RPqYd1dpGoが速い遅いと言ってたのは昔の話
今はGoもRust tokioも改善してほぼ同じwork stealing方式になり似たりよったりの速度
C++をあきらめてRustに対抗できるGoを持ち出すしかないほど追い込まれてるのかね
>>383
Rustで並行並列が他の言語より難しいことはない
難しいと主張するならば何が難しいのかを述べたまえ
もし本当に具体的に困ったことがあるならばアドバイスできる
0385デフォルトの名無しさん
2023/03/17(金) 12:38:18.49ID:YQ2F/Sw2楽しそうだね
0386デフォルトの名無しさん
2023/03/17(金) 12:39:30.67ID:o5CBT2m00387デフォルトの名無しさん
2023/03/17(金) 12:56:40.90ID:LTrpjv8n>Rustで並行並列が他の言語より難しいことはない
>難しいと主張するならば何が難しいのかを述べたまえ
>もし本当に具体的に困ったことがあるならばアドバイスできる
問題意識があること、気付くこと、それが大事。
あなたにはそれがない。
0388デフォルトの名無しさん
2023/03/17(金) 13:03:24.97ID:Gi38nai6わかり味
こいついつも教えて君だよなぁ
総論しか書けないところみると
マニュアルだけ読み込んだペーパープログラマーがそれを隠すためのネタを欲してるようにしか見えない
0389デフォルトの名無しさん
2023/03/17(金) 13:03:47.55ID:T8dNhcTzGoはあまりお勧めできないなあ
メモリ共有せずチャネルを使う範囲ならGoでもいいけど
Rustでもチャネルはもちろん使えるし
共有メモリで安全にデータ競合を起こさず使えるからRustがいいよ
0390デフォルトの名無しさん
2023/03/17(金) 14:28:10.79ID:ZRpBqjDt0391デフォルトの名無しさん
2023/03/17(金) 15:04:18.42ID:RPqYd1dpGoに限らずデータ競合を実行時にしか検出できない言語ではデータ競合が時々しか起きない場合のデバッグが難しい
Rustを使うべき理由はデータ競合を静的に検出できる点にある
0392デフォルトの名無しさん
2023/03/17(金) 15:55:42.60ID:LTrpjv8nそれはマルチスレッドプログラミングのアルゴリズムをRustは強く制限しているから。
だから、その制限から外れるようなアルゴリズムは使えないので柔軟性は欠く。
0393デフォルトの名無しさん
2023/03/17(金) 16:03:41.59ID:tBmmskox0394デフォルトの名無しさん
2023/03/17(金) 16:05:57.04ID:LTrpjv8nそして、独自のアルゴリズムは使えないので、アルゴリズムの研究には向かない。
0395デフォルトの名無しさん
2023/03/17(金) 16:11:31.46ID:TZnQdWAf0396デフォルトの名無しさん
2023/03/17(金) 16:16:19.10ID:tBmmskoxそのへんはC++もおなじ 自分も、ニッチすぎる薄いラッパなら頑張って書くし
0397デフォルトの名無しさん
2023/03/17(金) 16:20:04.75ID:KZujdKGkRustで記述できないマルチスレッドプログラミングのアルゴリズムなんてものは存在しない
Rustは柔軟性が非常に高い
0398デフォルトの名無しさん
2023/03/17(金) 16:32:10.93ID:LTrpjv8n嘘を書かないで。
0399デフォルトの名無しさん
2023/03/17(金) 16:41:56.97ID:T8dNhcTzRustにそんな制限はないからすべて書けるよたぶん
0400デフォルトの名無しさん
2023/03/17(金) 16:52:07.05ID:4tGjgBNl0401デフォルトの名無しさん
2023/03/17(金) 17:00:34.34ID:tBmmskoxC++は、なんでも書けるが、油断すると複雑すぎる代物ができあがる
そんで、「でも例外がくるとー」「でも異常値がくるとー」って
0402デフォルトの名無しさん
2023/03/17(金) 17:01:41.44ID:LTrpjv8nマルチスレッドのアルゴリズムは非常に多く存在していて、ある意味では無限に
考えられる。Rustは数個しかサポートしていないから、無理。
0403デフォルトの名無しさん
2023/03/17(金) 17:26:21.78ID:T8dNhcTzRustで書けない例があると主張したいなら例を出せばいいんじゃね
Rustに何か制限があるわけじゃないからおそらくなんでも書けるよ
0404デフォルトの名無しさん
2023/03/17(金) 17:31:51.55ID:LTrpjv8nunsafeになる。
0405デフォルトの名無しさん
2023/03/17(金) 17:42:50.37ID:T8dNhcTzマジ？信じられん
もし本当ならそのunsafeを使わざるを得なかった例を具体的に出せばいいんじゃね
0406デフォルトの名無しさん
2023/03/17(金) 17:43:39.56ID:tBmmskoxこれはC++も同様
0407デフォルトの名無しさん
2023/03/17(金) 17:52:35.17ID:2s/kFNH6そういう枯れた古いものをわざわざ書き直すことに熱意を燃やせる人間は少ない
新世代のデータベースやcrypt/blockchainのように金になる新しい成長分野ではc/c++よりもrustがよく使われてる
技術の自然な世代交代は既存システムの置き換えから始まるものではない
0408デフォルトの名無しさん
2023/03/17(金) 18:01:30.86ID:LTrpjv8n次のことが成り立っていれば教えてもらわなくても自然に分かる:
・マルチスレッドの事を理解している。
・Rustのことを理解している。
・算数的直観力に優れる。
0409デフォルトの名無しさん
2023/03/17(金) 18:03:48.04ID:u99ocdLbFight!
0410デフォルトの名無しさん
2023/03/17(金) 18:24:08.50ID:NC4w42Ntそのへんの問題もRustだと安全安心なのがいいよなー
特に例外機構を無くしたのは大成功
あとResult放置してると警告もしてくれるしな
>>404
そのunsafe使わないと書けなかったコードを出してみ
寄ってたかって添削してやろう
0411デフォルトの名無しさん
2023/03/17(金) 18:36:02.65ID:LTrpjv8n俺は天才だから、お前みたいな凡人に無料でヒントをくれてやらない。
0412デフォルトの名無しさん
2023/03/17(金) 19:13:16.48ID:tBmmskox0413デフォルトの名無しさん
2023/03/17(金) 19:55:25.86ID:9o1NNcpXRustをあんまり知らんけど言語間に根本的な差はなくね？
0414デフォルトの名無しさん
2023/03/17(金) 20:02:50.35ID:kImSYq8CRustもC++もコードを書けたことがない
相手にするだけ無駄
0415デフォルトの名無しさん
2023/03/17(金) 20:19:10.88ID:TZnQdWAf今さらなに言ってるんだ？
ここにはキチガイしかいないぞ？
俺もお前もな
0416デフォルトの名無しさん
2023/03/17(金) 20:29:34.70ID:Zxg/DnHCん？だから何？
0417デフォルトの名無しさん
2023/03/17(金) 21:29:42.97ID:o5CBT2m0アルゴリズムを書ける書けないの差はでない
0418デフォルトの名無しさん
2023/03/17(金) 23:44:57.66ID:Lcw0Ean/C++より後発言語で、で、ライバルになるC＋＋に劣っているようじゃダメだからな
で、お前らは、すごいRustで具体的に何を作っているんだ？
0419デフォルトの名無しさん
2023/03/18(土) 00:11:15.51ID:6kQD14Ek>>404の言う通り
template <typename T>
class LockFreeStack {
public:
void push(const T& value) {
Node* new_node = new Node(value);
new_node->next = head.load(std::memory_order_relaxed);
while (!head.compare_exchange_weak(new_node->next, new_node,
std::memory_order_release,
std::memory_order_relaxed));
}
std::shared_ptr<T> pop() {
Node* old_head = head.load(std::memory_order_relaxed);
while (old_head && !head.compare_exchange_weak(old_head, old_head->next,
std::memory_order_acquire,
std::memory_order_relaxed));
return old_head ? std::make_shared<T>(old_head->value) : nullptr;
}
private:
struct Node {
T value;
Node* next;
Node(const T& value) : value(value), next(nullptr) {}
};
std::atomic<Node*> head{nullptr};
};
0420デフォルトの名無しさん
2023/03/18(土) 00:31:48.86ID:jelBOeFa0421デフォルトの名無しさん
2023/03/18(土) 00:53:02.93ID:rMRLIFsDって言いたいんだろ
偉大なるChatGPT先生が言うんだから間違いないだろな
0422デフォルトの名無しさん
2023/03/18(土) 00:58:57.68ID:6kQD14EkいやChatGPTは信用しない方が良い
俺はRustは良く分からんがChatGPT曰く
>Rustには、このようなロックフリーなデータ構造を提供する
>クレート（ライブラリ）が存在します。その一つがcrossbeamです。
>このクレートは、スレッドセーフで効率的なデータ構造を提供しており、
>crossbeam内でUnsafeな操作が行われているにもかかわらず、
>APIを通じて安全に使用できます。
だそうな
crossbeamってRustで書かれとらんのかな?
0423デフォルトの名無しさん
2023/03/18(土) 01:14:24.86ID:pMxUNH+f本当は、ライブラリの中だけをunsafeにして、アプリ側はsafeに出来るケースも有れば、
アプリ側も unsafe を消せないケースもありえる。
0424デフォルトの名無しさん
2023/03/18(土) 01:17:39.13ID:6kQD14Ek0425デフォルトの名無しさん
2023/03/18(土) 01:29:02.55ID:6kQD14EkRustで書いてみよう！
0426デフォルトの名無しさん
2023/03/18(土) 04:35:18.48ID:+IGrKU6npointer dereferenceのためにunsafeは必須
0427デフォルトの名無しさん
2023/03/18(土) 10:03:55.24ID:fNuha5Rk0428デフォルトの名無しさん
2023/03/18(土) 10:25:46.77ID:fSPMk7mF0429デフォルトの名無しさん
2023/03/18(土) 11:41:47.24ID:ux4diyjf板違いのスレで必死に毎日お疲れさん
0430デフォルトの名無しさん
2023/03/18(土) 14:02:46.54ID:d2/CRNVk基本的な内容を説明してる本なのでC++でatomicsやmemory orderingに慣れ親しんでる人がわざわざ買うほどのものではないかもしれないけど
かなりわかりやすくまとまってるのでRustでこの辺りの機能を使ったコードを良く書く人は読んで置いて損はないと思う
0431デフォルトの名無しさん
2023/03/18(土) 16:09:57.63ID:fSPMk7mFhttps://bokuweb.github.io/undefined/articles/20230205.html
0432デフォルトの名無しさん
2023/03/18(土) 18:42:10.12ID:kFUsfJhuPorting Java's ConcurrentHashMap to Rust (part 1)
https://www.youtube.com/watch?v=yQFWmGaFBjk
0433デフォルトの名無しさん
2023/03/19(日) 12:22:41.89ID:LfQxDddq> cargo run
→ 3MB
main.rs に
use clap::Parser;
追加すると
> cargo run
→ 100MB 超えるんだが
どうすれば容量減らせるん？
0434デフォルトの名無しさん
2023/03/19(日) 12:44:51.20ID:TIfaDrwo0435デフォルトの名無しさん
2023/03/19(日) 13:32:03.94ID:fPDrKYk/https://igaguri.はてなぶろぐ.com/entry/2020/06/07/133847
https://crates.io/crates/cargo-clean-recursive
0436デフォルトの名無しさん
2023/03/19(日) 13:35:18.59ID:fPDrKYk/cargo clean
で良いはず
最初から余計なのは造りたくないって言う話ならほんまにしらん
0437デフォルトの名無しさん
2023/03/19(日) 14:03:33.37ID:4KWNgnTFありがとうございました
0438デフォルトの名無しさん
2023/03/20(月) 08:59:55.73ID:8VwEKWf+なんならCにも欲しい
attributeとか併用したら、やってできないことはないんじゃねーの
0439デフォルトの名無しさん
2023/03/21(火) 17:20:17.93ID:icU0z8mbhttps://github.com/rg3dengine/rg3d
から
https://github.com/FyroxEngine/Fyrox
に改名したのですか？
0440デフォルトの名無しさん
2023/03/21(火) 17:50:34.39ID:5MGYYNx+それ読むだけでも大分良い
後発言語らしくイイトコどりしまくってる
null無くした代わりになんでもかんでもラップしてるから若干だるいけど
すげー面白い
0441デフォルトの名無しさん
2023/03/21(火) 19:41:09.03ID:4irMO5jk0442デフォルトの名無しさん
2023/03/21(火) 19:42:14.14ID:4irMO5jk0443デフォルトの名無しさん
2023/03/21(火) 21:54:25.24ID:gItZ+a0Fただ、それだと、safeではあるけど、Rustのシンプルさは(メリットとして)失うな
0444デフォルトの名無しさん
2023/03/22(水) 07:30:44.03ID:7nCtmzjDほんとにできる？
0445デフォルトの名無しさん
2023/03/22(水) 09:09:27.85ID:II3LrhVDRustのコードとして使い物にならん
ゲテモノが出て来るわ
今のGPTも酷い
0446デフォルトの名無しさん
2023/03/22(水) 09:47:28.48ID:RLKJ2atP0447デフォルトの名無しさん
2023/03/22(水) 10:40:01.19ID:Motackg90448デフォルトの名無しさん
2023/03/22(水) 12:19:59.74ID:jZlOcGNt0449デフォルトの名無しさん
2023/03/22(水) 14:27:48.09ID:RqRpj7Axrustでもメモリリークの確認に使う
有用なツールだけど静的チェックと呼べるのかは疑問
0450デフォルトの名無しさん
2023/03/22(水) 21:31:28.83ID:vDLoPLCP0451デフォルトの名無しさん
2023/03/22(水) 21:43:05.82ID:jZlOcGNthttps://kivantium.hateblo.jp/entry/2018/07/14/233027
0452デフォルトの名無しさん
2023/03/22(水) 21:46:10.74ID:vDLoPLCP0453デフォルトの名無しさん
2023/03/22(水) 21:54:30.07ID:jZlOcGNthttps://cppcheck.sourceforge.io/
スマートポインタ使えばそもそもいらんがね
0454デフォルトの名無しさん
2023/03/23(木) 11:01:43.91ID:AQHpwrnP0455デフォルトの名無しさん
2023/03/23(木) 11:35:46.79ID:4E7FceMl0456デフォルトの名無しさん
2023/03/23(木) 11:37:47.99ID:rQpQMC7M例えばどういう状況かな?
0457デフォルトの名無しさん
2023/03/23(木) 13:26:58.89ID:4E7FceMlゲームのバグとか
0458デフォルトの名無しさん
2023/03/23(木) 13:54:38.12ID:Pj5jY94w0459デフォルトの名無しさん
2023/03/23(木) 14:56:19.59ID:vn3KCE0yhttps://doc.rust-lang.org/stable/std/process/
ここを観て
use std::process::{Command, Stdio};
let c = "cmd";
let a = "/c echo Hello, world!";
let o = Command::new(c).arg(a).output().expect("Failed to start process");
let v1 = o.stdout.as_slice();
すると v に必ず
[0x48, 0x65, 0x6c, 0x6c, 0x6f, 0x2c, 0x20,
0x77, 0x6f, 0x72, 0x6c, 0x64, 0x21, 0x22, 0x0d, 0x0a]
が入ります
let p = Command::new(c).arg(a).stdout(Stdio::piped()).spawn().expect("Failed to start process");
let e = p.wait_with_output().expect("Failed to open stdout");
let v2 = e.stdout.as_slice();
としても結果同じです
Hello, world!"+改行
で余計な"が入っているのですがなぜでしょう？どのように取り除くのが正しい対処方法を教えて！！
0460デフォルトの名無しさん
2023/03/23(木) 15:07:48.89ID:AQHpwrnP0461デフォルトの名無しさん
2023/03/23(木) 17:25:27.77ID:v7ZfYtIP0462デフォルトの名無しさん
2023/03/23(木) 19:55:36.72ID:oPmaaYed0463デフォルトの名無しさん
2023/03/23(木) 20:30:50.18ID:xqmW5G90失敗してもお金が減らない失敗は半分大成功だよ
0464デフォルトの名無しさん
2023/03/23(木) 23:42:04.79ID:/qDbj6Pr(1)ダングリングがないメモリ安全性の保証
(2)データやポインタのヌル安全性の保証
(3)データ競合がない安全性の保証
Rustはコンパイラが通れば保証されるが
C++は(2)(3)は無理として(1)についてもプログラマーがどんなに複雑化してもミスなく記述できた場合のみその自己責任で実現
そのためC++ではバグやセキュリティの穴が現在進行形で量産されている
0465デフォルトの名無しさん
2023/03/23(木) 23:55:58.81ID:rQpQMC7M0466デフォルトの名無しさん
2023/03/24(金) 00:33:14.50ID:sS+xf8yHhttps://docs.rs/lockfree/
中身はunsafeを使う部分が一部あるが全てコメントに理由が記述されているようにsafeな操作でありその部分の安全性のみを人が保証
Rustの最大の特徴はこのようにunsafeを使ったsafeな操作を内部に封じ込めて外部にsafeなインタフェースを提供できること
そしてそのライブラリを使った任意のプログラム全体の安全性がRustコンパイラにより保証される
0467デフォルトの名無しさん
2023/03/24(金) 01:00:04.81ID:STP4y0mBRustにはunsafeを認めるんだなw アンフェアだね
C++もスマートポインタを使えばメモリリークは起こらんのだよ
0468デフォルトの名無しさん
2023/03/24(金) 01:01:07.83ID:Qymt7I/Nそれだとマイコンでrustが使えなくなるし、safe C++だって実現しなくなる
0469デフォルトの名無しさん
2023/03/24(金) 01:08:19.45ID:F7DMT4640470デフォルトの名無しさん
2023/03/24(金) 01:13:06.10ID:STP4y0mBsafeじゃないRustねぇw 苦しいな
言語を覚えるのが趣味なら使えば
0471デフォルトの名無しさん
2023/03/24(金) 01:15:17.05ID:Qymt7I/NそれとC++はなんでもかんでもnewする習慣がついちゃって、
そこはスタックに物を置きたくなるRustのほうが能率よくなっちゃってねえか
0472デフォルトの名無しさん
2023/03/24(金) 01:22:55.16ID:IeJLDeif違いは明白
C++はプログラム全てがunsafeエリア(＝人が安全性を保証する)
Rustはプログラムのほとんとがsafeエリア(＝コンパイラが安全性を保証する)
（Rustには一部の閉じ込められた局所的な部分のみunsafeが存在しそこに限定して人が安全性を保証する）
0473デフォルトの名無しさん
2023/03/24(金) 01:25:05.80ID:F7DMT464.NET7でAOTコンパイル対応したから
Rustなんかより遥かに簡単だし
0474デフォルトの名無しさん
2023/03/24(金) 01:25:34.49ID:Qymt7I/Nちなみに、C#はプリコンパイルできるスクリプト言語として、とても便利に日々使ってる
0475デフォルトの名無しさん
2023/03/24(金) 01:34:37.55ID:F7DMT464まぁ時期対応するでしょ
使ってる人Rustより遥かに多いし
0476デフォルトの名無しさん
2023/03/24(金) 01:35:44.19ID:STP4y0mB後退したなw
Rustを覚えるよりもスマートポインタ使う方がずっと楽だよ
どうせC言語は覚えなきゃならんのだから
C/Rustを覚えるよりC/C++を覚える方がずっと効率的
0477デフォルトの名無しさん
2023/03/24(金) 01:36:16.07ID:IeJLDeifC#はC++やRustのカバーする範囲を全く満たせないのでこのスレでは論外
C#はGCがあるし省メモリや高速性もないし更にはインラインアセンブリも書けない
0478デフォルトの名無しさん
2023/03/24(金) 01:39:04.57ID:F7DMT464AOTにするとGCとか無くなるよ
0479デフォルトの名無しさん
2023/03/24(金) 01:39:24.39ID:STP4y0mBAOTに対応したんだから速度では勝負できるよ
0480デフォルトの名無しさん
2023/03/24(金) 01:41:10.62ID:F7DMT464https://takym.github.io/blog/general/2022/12/25/osdotnet.html
0481デフォルトの名無しさん
2023/03/24(金) 01:41:24.23ID:STP4y0mBへー
JavaのAOTってgcjのやつはGCなかったっけ?
C#のAOTはGCなくなるんだ
0482デフォルトの名無しさん
2023/03/24(金) 01:42:48.96ID:IeJLDeif後退って何？
Rustはコンパイラが安全性を保証できる言語でC++は人が安全性を保証する言語で何も変わっていない
C++スマポでなんとかできる安全性の範囲は>>464のうちの(1)だけだから話にならない
0483デフォルトの名無しさん
2023/03/24(金) 01:45:09.38ID:STP4y0mB>後退って何？
おまいさんのディフェンスライン
0484デフォルトの名無しさん
2023/03/24(金) 01:48:33.41ID:Qymt7I/N0485デフォルトの名無しさん
2023/03/24(金) 01:52:02.45ID:7trvtA/S嘘つき
C#はGC言語なのでAOTコンパイルしようがGCは無くなりません
C#がC/C++/Rustの代わりになることはできません
0486デフォルトの名無しさん
2023/03/24(金) 01:54:42.93ID:GMecybVR最近のC++はよく知らないけどスマートポインタで防げるの？
0487デフォルトの名無しさん
2023/03/24(金) 01:54:57.32ID:STP4y0mB>(3)データ競合がない安全性の保証
共有データをスマートポインタに入れといて
アクセスする際には共有データではなくて
一時Proxyを経由してアクセスすればよい
Proxyのコンストラクタでロックしてデストラクタでアンロックする
RustのMutex相当で簡単に実装出来る
>(2)データやポインタのヌル安全性の保証
これはどういうこと? 静的に保証しろってことかな?
0488デフォルトの名無しさん
2023/03/24(金) 01:57:35.21ID:STP4y0mBvectorは連続するアドレスに領域を取ることが保証されているコンテナなので
末尾に要素をしてcapacityを超えると当然再配置が起こる
他のコンテナを使うべし
0489デフォルトの名無しさん
2023/03/24(金) 02:03:47.17ID:STP4y0mBもし最大要素数が決まってるなら
vectorで領域をreserveしといて
その範囲で追加ってことなら
再配置は起こらない
いずれにしても仕様を調べて使うべし
0490デフォルトの名無しさん
2023/03/24(金) 02:07:17.26ID:GMecybVR>>489
サンクス
なんかスマートポインタ推されてるからリアロケーション追跡するポインタとか出来てるのかと思った
0491デフォルトの名無しさん
2023/03/24(金) 02:12:19.33ID:7trvtA/SC++のスマポは使い方をミスったらおしまいで実際に問題を起こし続けている欠陥品
null安全か否かは言語仕様で決まりもちろん静的に防げる
当然C++はnull安全な言語ではない
>>488
vectorの自動メモリ再配置によるダングリング発生がうっかりミスで容易に発生するC++は欠陥言語
0492デフォルトの名無しさん
2023/03/24(金) 02:30:27.68ID:STP4y0mB>C++のスマポは使い方をミスったらおしまいで実際に問題を起こし続けている欠陥品
どういうミスかな? 書いてみ
>null安全か否かは言語仕様で決まりもちろん静的に防げる
これもどういうケースを言っているのか分からんので書いてみて
>vectorの自動メモリ再配置によるダングリング発生がうっかりミスで容易に発生するC++は欠陥言語
連続するアドレスに領域を取ることが保証されているコンテナはRustにはないのかな?
C++はもちろんメモリ再配置しない（領域が連続しない）コンテナを選択できる
反論したいので具体的に書いてね
無理かもしれんがもし書けるならC++のソースで例示してね
0493デフォルトの名無しさん
2023/03/24(金) 02:43:13.61ID:Qymt7I/NC++は一刻も早く進化すべきだ
0494デフォルトの名無しさん
2023/03/24(金) 02:54:47.10ID:STP4y0mB0495デフォルトの名無しさん
2023/03/24(金) 03:22:24.82ID:pHWoHRbv欠陥言語というか他の言語たちと比べればCやC++はわずかなミスで危険なことになるから大きなマイナスかもしれないけど
省メモリで高速という他の言語では得られない巨大なプラスがあるからC++は必須の存在だったのよ
今はその巨大なプラスがありつつマイナスのないRustが登場したからC++は価値がなくなり役目を終えたけどね
0496デフォルトの名無しさん
2023/03/24(金) 04:28:25.21ID:F7DMT464役目を終えたならC++で書かれた全てのソフトウェアがRustになってもおかしくないけど全くそうじゃないよな？
0497デフォルトの名無しさん
2023/03/24(金) 04:38:49.00ID:pHWoHRbv既存システムの書き直しは時間と費用がかかるからやるとしても少しずつでしょ
多くのシステムは大規模更新時の機会にでしょ
新規に登場したシステムはRust製になっていってますね
0498デフォルトの名無しさん
2023/03/24(金) 04:46:18.91ID:F7DMT464ならないと思うけどね
まぁ何言っても無駄かw
0499デフォルトの名無しさん
2023/03/24(金) 05:43:54.98ID:pnAyfShUなんか初心者泣かせのトラップが多すぎるんだよな。
0500デフォルトの名無しさん
2023/03/24(金) 05:50:11.50ID:G7wXKrBjありがとうございました
0501デフォルトの名無しさん
2023/03/24(金) 05:58:04.68ID:G7wXKrBjGCって禿のことだったんですね
0502デフォルトの名無しさん
2023/03/24(金) 06:06:32.31ID:G7wXKrBj>初心者泣かせのトラップ
むしろ知ったかがドツボに嵌る
0503デフォルトの名無しさん
2023/03/24(金) 10:43:05.72ID:qDyrJPYZrustのvectorは再配置される可能性がある操作時は他からの参照がないことがコンパイル時に保証されるので連続領域でも問題ないよ
0504デフォルトの名無しさん
2023/03/24(金) 11:32:45.65ID:STP4y0mBほう! Rustはよう知らんのでC++で聞いて申し訳ないが
以下コメントの部分(1)と(2)は
Rustで相当するコードを書いたらコンパイルが通らないということかな?
#include <iostream>
#include <vector>
#define DOUT(arg) std::cout << #arg": " << arg << '\n';
int main () {
std::vector <int> v;
v.reserve (1);
DOUT (v.capacity ());
v.push_back (10); // (1) Rustで許容 or エラー?
auto itr {v.begin ()};
DOUT (*itr);
v.push_back (11); // (2) Rustで許容 or エラー?
DOUT (v.capacity ());
// DOUT (*itr); // dangerous
return 0;
}
$ ./a.out
v.capacity (): 1
*itr: 10
v.capacity (): 2
0505デフォルトの名無しさん
2023/03/24(金) 12:12:50.87ID:yujZIUnP(1)の段階では問題ないけど
(2)の段階ではitrとpush_backがコンフリクトするからコンパイルエラー
0506デフォルトの名無しさん
2023/03/24(金) 12:16:34.86ID:+nRUfXDq当然エラーは起きない
fn main() {
let mut v = Vec::<i32>::new();
v.reserve_exact(1);
dbg!(v.capacity());
v.push(10);
let first = &v[0];
dbg!(*first);
v.push(11);
dbg!(v.capacity());
dbg!(v.len());
// dbg!(*first); // dangerousなこれを入れたときだけコンパイルエラー
}
[src/main.rs:4] v.capacity() = 1
[src/main.rs:7] *first = 10
[src/main.rs:9] v.capacity() = 4
[src/main.rs:10] v.len() = 2
0507デフォルトの名無しさん
2023/03/24(金) 12:23:09.85ID:STP4y0mBどっちが正しいんだい?
0508デフォルトの名無しさん
2023/03/24(金) 12:23:39.80ID:xsjnwqf20509デフォルトの名無しさん
2023/03/24(金) 12:24:51.09ID:xsjnwqf2オレはdangerousがある前提で考えてたから
0510デフォルトの名無しさん
2023/03/24(金) 12:27:08.05ID:+nRUfXDq(2)の段階より後に使われなければ
(2)の段階より前までにそれらの参照のスコープが自動的に終わる(＝ライフタイムが尽きる)
したがってコンフリクトは起きない
一方でもしdangerousの部分のコードがある場合は
(2)の段階より後に使われているため
コンフリクトが起きるためコンパイルエラー
0511デフォルトの名無しさん
2023/03/24(金) 12:31:23.73ID:STP4y0mBreserve_exactの引数が定数1のときには
最終行のdangerousを入れるとコンパイルエラーを出すということだが
reserve_exactの引数が変数で実行時にしか定まらんときは
コンパイルエラーにできないと思うんだが危険じゃね?
0512デフォルトの名無しさん
2023/03/24(金) 12:35:02.24ID:STP4y0mBなるほどー
Rustってデストラクタはいつ呼ばれるの?
ライフタイムの終わり? あるいはデストラクタはない?
0513デフォルトの名無しさん
2023/03/24(金) 12:48:05.77ID:+nRUfXDq指定サイズは一切関係ない
データ競合が起きないようにmultiple readers or single writerの鉄則に基づく
pushすなわち書き換えたいならば他にreader(参照)もwriter(可変参照)も生きていてはいけない
>>512
所有権を持っている変数がスコープから外れると
所有者が居なくなりデストラクタ相当が呼ばれて自動的に安全にメモリ解放される
0514デフォルトの名無しさん
2023/03/24(金) 13:14:43.88ID:STP4y0mB>>>511
>指定サイズは一切関係ない
>データ競合が起きないようにmultiple readers or single writerの鉄則に基づく
>pushすなわち書き換えたいならば他にreader(参照)もwriter(可変参照)も生きていてはいけない
pushしたあとはたとえcapacityの範囲内で再配置が行われてないとしても
参照を取得し直すってことかな?
0515デフォルトの名無しさん
2023/03/24(金) 13:21:48.64ID:STP4y0mBRustのスコープ=ライフタイムとすると
デストラクタが呼ばれるタイミングが分かり難くないかい?
ちょっとソースをいじって後ろの方でインスタンスを触ると
呼ばれるデストラクタが呼ばれるタイミングも
自動的に後ろになるということかな?
C++ほどデストラクタに処理を書かないのかな?
0516デフォルトの名無しさん
2023/03/24(金) 13:23:02.73ID:+nRUfXDq再配置だけでなく値が書き換わる可能性もある
それらの可能性やそれらの操作を跨いで参照を保持してはいけない
逆に言えば参照を持ち続けることができているならば指している値が変わらないことが保証される
これはバグを防ぐとともにコンパイラによる最適化の余地も広げ高速化にも寄与する
0517デフォルトの名無しさん
2023/03/24(金) 13:31:39.50ID:STP4y0mBなるほどね
まぁ俺は再配置が起こらないと分かるところで
いちいち参照は取り直したくはないな
Rustのデストラクタが呼ばれるタイミングは
インスタンスのライフタイムで変わりうるということで良い?
0518デフォルトの名無しさん
2023/03/24(金) 13:32:37.18ID:+nRUfXDqデストラクタが呼ばれるのはその変数の「ブロックスコープ」のブロックを出るタイミングだから一定している
0519デフォルトの名無しさん
2023/03/24(金) 13:37:44.31ID:STP4y0mBライフタイムとまた違うのかな? 複雑だなぁ
0520デフォルトの名無しさん
2023/03/24(金) 13:53:25.98ID:+nRUfXDq誤解をしている
ブロックの途中で打ち切られる可能性があるのは参照のライフタイム
そして参照にはデストラクタはない
一方で値そのもののライフタイムつまり所有権が尽きるのは常にブロックスコープに従う
デストラクタが存在すればブロックを抜けるタイミングで呼ばれる
その後でメモリ解放が自動的に行われる
0521デフォルトの名無しさん
2023/03/24(金) 13:55:42.43ID:GMecybVR正確なタイミングはコンパイラが決めてるから予測はできない
例えば何かを解放しないと以降で競合が生じる場合はブロックの途中で解放されることもある
ただ
A()
B(&A)
みたいにBがAを参照してるような状況だとBが消えるまでAを動かせないから
結果的にC++と同じように逆順で解放されることになる
ライフタイム周りはコンパイラが制約を満たせる処理順を見つけて裏で調整する感じだから
最初は戸惑うかもしれないね
0522デフォルトの名無しさん
2023/03/24(金) 14:00:41.09ID:+nRUfXDqlet _ = x; で棄てる以外に
ブロックの途中でデストラクタが呼ばれるケースあるっけ？
0523デフォルトの名無しさん
2023/03/24(金) 14:34:12.82ID:JpLx+uLRそれどこのスマポ
0524デフォルトの名無しさん
2023/03/24(金) 14:38:27.83ID:STP4y0mBなるほどね
参照って読んでるのは>>506だとfirstのことかな?
参照の中にC++のstd::shared_ptrの挙動を内在させてるイメージを持った
Vecのアクセスにiteratorは使わないのかな?
0525デフォルトの名無しさん
2023/03/24(金) 14:55:23.36ID:+nRUfXDqデストラクタにスマポもポインタも関係ない
Rustでは任意の自作型にデストラクタを実装できる
(ただしCopyを実装していないことが条件)
// 例えば整数i32型のみを持つ構造体Foo
struct Foo(i32);
impl Drop for Foo {
// デストラクタ実装
fn drop(&mut self) {
println!("drop: Foo({})", self.0);
}
}
fn main() {
let _x = Foo(123); // メインブロックを終えてからdropされる
{
let _x = Foo(456); // 内ブロックを終えてからdropされる
let _x = Foo(789); // 内ブロックを終えてからdropされる
println!("内ブロック終わり");
}
println!("メインブロック終わり");
}
【実行結果】
内ブロック終わり
drop: Foo(789)
drop: Foo(456)
メインブロック終わり
drop: Foo(123)
0526デフォルトの名無しさん
2023/03/24(金) 15:07:39.53ID:GMecybVRすまん
ちょっと勘違いしてた
Dropあると明示的に捨てる必要あるな
0527デフォルトの名無しさん
2023/03/24(金) 15:07:52.15ID:+nRUfXDqC++とRustはiteratorで指すものが微妙に異なるので要注意だがまずは折衷するとして
例えば
let mut v = vec![1, 2, 3];
for p in v.iter_mut() {
*p += 10;
}
これでイテレータを使って11,12,13
0528デフォルトの名無しさん
2023/03/24(金) 15:18:17.49ID:m8vHxf3RDrop scopeがブロックとは限らないだけで予測できないわけではなくね？
>>525
let x = Foo(123).0 * 2;
とか
let mut x = Foo(124);
x = Foo(456);
とか
0529デフォルトの名無しさん
2023/03/24(金) 15:28:04.96ID:STP4y0mB>>506の let first = &v[0]; の部分をイテレータに差し替えると
（記法は分からんが仮に let first = v.iter() かな?）
イテレータのライフタイムも参照の場合と変わらず
v.push(11);と最終行のdangerousを併存させると
capacityに関わらず問答無用にコンパイルエラーといことかな?
0530デフォルトの名無しさん
2023/03/24(金) 15:30:39.43ID:+nRUfXDq変数が所有している値のデストラクタが呼ばれるのはブロックを抜けた直後だけど
変数が所有しない一時的な値や変数が所有しなくなる代入前の値などは
_へ棄てるのと同じくブロック途中でデストラクタが呼ばれるね
0531デフォルトの名無しさん
2023/03/24(金) 15:33:55.56ID:STP4y0mB0532デフォルトの名無しさん
2023/03/24(金) 15:51:46.07ID:+nRUfXDqもちろんイテレータは参照もしくは可変参照を持つ形となるのでsingle writer or multiple readersを満たす必要がある
それを満たせなければコンパイルエラーとなりデータ競合を防げる
0533デフォルトの名無しさん
2023/03/24(金) 15:55:15.22ID:+nRUfXDq棄てるのは _ へ棄てなくてもいくらでも方法があり
例えばブロックを作れば
{
let _tmp = x;
}
これで_tmpへ値が移動してブロックを抜けるときに消える
他にも例えば以下の関数を定義して
fn 棄てる<T>(_tmp: T) {
// 何もなし
}
棄てる(x); とすればその関数へ値が移動して関数ブロックを抜けるときに消える
この棄てる関数は同じものがstd::mem::drop()に用意されているので意図をはっきりさせるためにはそれを使うことで可読性を持たせる
0534デフォルトの名無しさん
2023/03/24(金) 17:20:54.03ID:ENxn1p6S細かいことだけど一時的な値は内部的に一時変数が所有してることになってて一時変数がDrop scopeを抜けていなくなるタイミングでデストラクタが実行される
let _ = Foo(123);やx = Foo(456);は代入によって値の所有者がいなくなるからそのタイミングですぐにデストラクタが実行される
0535デフォルトの名無しさん
2023/03/24(金) 20:26:32.48ID:STP4y0mBこういうことだわな
#include <iostream>
using namespace std;
struct A {
A () {cout << "constructor\n";}
~A () {cout << "destructor\n";}
};
template <typename T> void drop (unique_ptr <T> &&p) {}
int main () {
auto x {make_unique <A> ()};
{
auto _tmp = move (x);
}
drop (move (x));
return 0;
}
0536デフォルトの名無しさん
2023/03/24(金) 21:50:27.51ID:VHzrsylr0537デフォルトの名無しさん
2023/03/24(金) 21:51:22.79ID:STP4y0mB0538デフォルトの名無しさん
2023/03/25(土) 09:38:10.15ID:M09ogOTB0539デフォルトの名無しさん
2023/03/25(土) 20:06:44.69ID:sd+PB/iLそういう小さい単純な例ならばdangerousなデータ競合であると自明だが
もっと複雑化して見逃す例が実際に起きてセキュリティの穴になる
0540デフォルトの名無しさん
2023/03/25(土) 20:52:44.35ID:c5G720p2みょうちくりんな文法を新たに覚えようという動機にはならん
0541デフォルトの名無しさん
2023/03/25(土) 20:56:23.22ID:VVKoWVL2時間の無駄では？
デバッガでわかるよりコンパイラでわかるなら圧倒的にそっちがベターでもあるし
0542デフォルトの名無しさん
2023/03/25(土) 20:58:28.17ID:c5G720p2>不明な挙動があるのが発見されてない時点で
それはいくらなんでも無理だろw
0543デフォルトの名無しさん
2023/03/25(土) 20:59:37.07ID:tC35D9u3デバッガなど実行時でないと検知できないショボいプログラミング言語は滅びそう
昔はC++は神の言語と信じていたけどアドバンテージを全て失ってしまったもの
0544デフォルトの名無しさん
2023/03/25(土) 21:03:00.33ID:c5G720p2C/C++と乖離した文法を新たに覚えるというコストを払おうとは全く思わん
俺がRustを覚えるとしたらシステムコールがRustで書かれたOSを
使うことになったときだけ
当分ない
0545デフォルトの名無しさん
2023/03/25(土) 21:04:16.45ID:c5G720p2でもLockFreeQueueをsafeで実装できないんでしょ?
0546デフォルトの名無しさん
2023/03/25(土) 21:10:35.10ID:c5G720p2Rust推しの諸君は自らRustを選択したのだろうけど
そんなにCでのメモリの扱い方に苦労したのかい?
Rust使う人はどちらかというと言語マニアの人達だと思ってたのだが?
0547デフォルトの名無しさん
2023/03/25(土) 21:14:16.97ID:tC35D9u3そういうのはすべてsafeなインタフェイスでライブラリが作られてるから
LockFree{Queue,Stack,Map,Set,Chanel}すべてsafeなインタフェイスを用いてRustプログラミングできるよ
0548デフォルトの名無しさん
2023/03/25(土) 21:17:55.09ID:fB31q3I6開発効率と可読性が圧倒的にRust＞＞＞C++
Rustはコンパイル時点でミスが見つかるから効率良すぎ
可読性も大差でパターンマッチングの有無も大きい
0549デフォルトの名無しさん
2023/03/25(土) 21:18:50.17ID:c5G720p2Rustでプログラミンしたいのではなくて
言語のウリとしている特徴の不備の一例として上げている
平たく言うと中途半端
0550デフォルトの名無しさん
2023/03/25(土) 21:23:11.57ID:tC35D9u3すべてがunsafeなC++と違って
RustならLockFree{Queue,Stack,Map,Set,Chanel}をsafeなインタフェイスで使うことで自分の書くプログラムをsafeにできるよ
つまりRustコンパイラが書いたプログラムの安全性の保証をしてくれるよ
0551デフォルトの名無しさん
2023/03/25(土) 21:36:28.93ID:c5G720p2Rustではsafeで全てを表現したいという目論見が破綻した
ということを指摘したい
これで良いかな?
更に良い言語が出るかもね
0552デフォルトの名無しさん
2023/03/25(土) 22:24:32.21ID:fB31q3I6LockFreeも全く同様
unsafeを使ったsafeなコードで基本ライブラリを作成しsafeなインターフェースを提供できることがRustの最大の長所
それらを使うプログラムはsafeにすることが出来てコンパイル時点で各問題を排除できる
C++が敗北した理由である
0553デフォルトの名無しさん
2023/03/25(土) 22:28:23.02ID:c5G720p2>Rustは例えばVecすら中身はunsafeを使ったsafeなコードだらけだぞ
だめだめじゃん
設計が間違ってるんだよ（というか無理だったんだよ）
0554デフォルトの名無しさん
2023/03/25(土) 23:00:19.34ID:tC35D9u30555デフォルトの名無しさん
2023/03/25(土) 23:10:11.97ID:Ty/K+FgoC++大好きだが、神の言語とはちょっと違う希がす
0556デフォルトの名無しさん
2023/03/25(土) 23:25:09.01ID:c5G720p2Rustは一過性の言語だと思うよ
C++はCを包含しているからそうそう消えないと思うが
Rustは後続の言語にオーバーライドされると思う
0557デフォルトの名無しさん
2023/03/25(土) 23:58:43.93ID:EBh7DtZR理系のくせにそこに気付くとはえらいね
0558デフォルトの名無しさん
2023/03/26(日) 00:04:07.04ID:Vf0mvjFWC/C++は進化はよ
0559デフォルトの名無しさん
2023/03/26(日) 00:38:53.03ID:04xno5ob向こうの方が宣伝がうまかった
0560デフォルトの名無しさん
2023/03/26(日) 01:40:41.16ID:Vf0mvjFWC++が「負け」てるのは、今に始まったことじゃない
キャッチアップしていってくれればいいんだよ
0561デフォルトの名無しさん
2023/03/26(日) 08:24:37.76ID:4yCJuAuORustからは出て来ない
::が邪魔しとるんかの
0562デフォルトの名無しさん
2023/03/26(日) 08:28:50.22ID:UQsado+ICは神言語だが
C++は神じゃないどころか
クソ言語だと言うのは当初から言われてた
0563デフォルトの名無しさん
2023/03/26(日) 08:38:26.46ID:VUXuxgJn0564デフォルトの名無しさん
2023/03/26(日) 08:42:34.83ID:faqu5Hbk無理に挙げるとすれば過去のプログラムと過去のプログラマーくらいか
0565デフォルトの名無しさん
2023/03/26(日) 11:07:56.67ID:Vf0mvjFW自由が障壁になる用途ではメリットもクソもないｗ
C++で書きたいというニーズは当面残る
だからC++には進化してもらわないといけない
0566デフォルトの名無しさん
2023/03/26(日) 11:19:02.92ID:rT1rfVXrC/C++には滅びて欲しい人間が増えてんだろ
プレーンCのコードぐらいRustにコンバート出来るんじゃね？
知らんけど
0567デフォルトの名無しさん
2023/03/26(日) 12:33:33.90ID:g6NQ2zfC捨てろと言われても無理だねえｗ Rustを使わないとは一言もいってない
>>563
これまで、自由になりすぎたC++をいかに縛るかっていう試みはいくらもあったが、普及しなかった
ついにRustが答えを出した C++は「いや～負けましたね～」とかいいながら、その成果を吸収すればいい
0568デフォルトの名無しさん
2023/03/26(日) 13:03:12.58ID:BnHATVrm何らかの外からの圧力がない限りなかなか増えないだろうね
キラープロダクトがあれば一気に普及するだろうけど
0569デフォルトの名無しさん
2023/03/26(日) 13:05:22.20ID:BnHATVrm自分でメモリ管理に苦労して「あ! Rustが解決法だ!」って
始めた人はいないだろうし
0570デフォルトの名無しさん
2023/03/26(日) 13:06:33.66ID:g6NQ2zfCどう縛るのが「正解」か、なかなか答えが出なかったんだよね
スマポどころか、ハンドルや参照カウントの概念が大昔からあったけど、決定打にならなかった
0571デフォルトの名無しさん
2023/03/26(日) 13:09:22.51ID:BnHATVrmそれは自然言語と同じで使う人のレベルによる
0572デフォルトの名無しさん
2023/03/26(日) 13:12:55.73ID:BnHATVrm0573デフォルトの名無しさん
2023/03/26(日) 13:14:54.55ID:Lwno4Hfqどっちも供給されなければ胡散臭いとか偽善だとか
需要ってあなたの願望ですよね、とかいうのが自由にまつわる典型的な詭弁
0574デフォルトの名無しさん
2023/03/26(日) 13:19:57.22ID:BnHATVrm「自由になりすぎたC++をいかに縛るかっていう試みは
いくらもあったが、普及しなかった」のでは?
Rustもこのままだとone of themだろうけど
0575デフォルトの名無しさん
2023/03/26(日) 14:41:00.96ID:g6NQ2zfCあーでもないこーでもないいって、混沌を放置したのはC++の落ち度
バイナリだって肥大化し放題だったしね Cに近いC++erは、忸怩たる思いで眺めてたものさ
0576デフォルトの名無しさん
2023/03/26(日) 14:50:08.58ID:EIuzoBSLhttps://maku77.github.io/rust/
あと
if let Ok(hoge) = fuga {
}
って本当に可読性良くなってると思ってる？(嫌味じゃなくてマジでRust推しの人の意見聴きたい)
0577デフォルトの名無しさん
2023/03/26(日) 14:57:31.39ID:BnHATVrmは? C++はISOもJISも規格あるやろ?
Rustに規格あるの?
0578デフォルトの名無しさん
2023/03/26(日) 15:01:34.10ID:g6NQ2zfC大手が採用するといったんだから、採用されるバージョンが、当面のデファクトスタンダードになる
それは規格といっていいよ そして規格は、管理下で進化する
0579デフォルトの名無しさん
2023/03/26(日) 15:09:14.63ID:BnHATVrm普及はもしするとしても30年くらいは掛かりそう
0580デフォルトの名無しさん
2023/03/26(日) 15:58:38.13ID:LwxNksN70581デフォルトの名無しさん
2023/03/26(日) 16:29:03.94ID:v5z9D7dtRustの if let でのenumパターンマッチングは、
まずRustのenumを理解する必要があるけど、例えば、
enum State {
StateA(i32),
StateB(i32),
StateC(i32, f32),
}
if let State::StateA(i) = x {
println!("StateA: {i}");
}
これをc++で書こうとするとこうなるのかな。
struct StateA { int i; };
struct StateB { int i; };
struct StateC { int i; float f; };
typedef std::variant<StateA, StateB, StateC> State;
if (std::holds_alternative<StateA>(x)) {
StateA& a = std::get<StateA>(x);
std::cout << "StateA: " << a.i << "\n";
}
この両者がたぶん同じ。
if let構文のおかげでRustは可読性が増していると思う。
0582デフォルトの名無しさん
2023/03/26(日) 18:24:04.21ID:MldEMOwI>if let Ok(hoge) = fuga {
>}
>って本当に可読性良くなってると思ってる？
ResultやOptionが複数ネストしていくと可読性が低いコードはどうしてもできるけど単純なやつは何の問題もないと思ってる
ちなみに何と比べてる？
0583デフォルトの名無しさん
2023/03/26(日) 23:06:22.21ID:zumLAqybC++は利便性のいい代数的データ型の導入に失敗したからしょうがない
さらにパターンマッチングの導入は未だに議論中のまま進みそうにない
結果としてそのような不便で分かりにくい記述をするしかない
0584デフォルトの名無しさん
2023/03/26(日) 23:24:54.44ID:Lwno4HfqCとC++を意図的に隔離すれば縛りを無視できるから問題視されないが
0585デフォルトの名無しさん
2023/03/26(日) 23:35:48.82ID:BnHATVrm0586デフォルトの名無しさん
2023/03/26(日) 23:51:37.40ID:Lwno4Hfq0587デフォルトの名無しさん
2023/03/27(月) 00:02:41.74ID:+gsY9S8v安全性のためには
schemeとかHaskellみたいな言語には定義外の動作が(基本的には）存在しないという強力な安全性があるわけだし
じゃあなんでこんなにRUSTがもてはやされるのかというと、単に宣伝がうまかっただけ
0588デフォルトの名無しさん
2023/03/27(月) 05:32:45.27ID:UciRikyKそしてunsafeを用いてsafeなインタフェースを提供する時にもそれが義務付けられている
したがってそれらを用いるRustに未定義動作は存在しない
未定義動作まみれのC/C++との決定的な違いである
0589デフォルトの名無しさん
2023/03/27(月) 06:40:49.82ID:xp5TMlgQ0590デフォルトの名無しさん
2023/03/27(月) 11:50:25.04ID:kviG1IE2憧れてしまったら超えられないんで
0591デフォルトの名無しさん
2023/03/27(月) 12:09:54.31ID:iTDWuTVqRustの代数的データ型であるenumに対して
対応するC++のstd::variantは五重苦だよな
・機能が弱い
・使いにくい
・見にくい
・使われていない
・知られていない
C++の機能強化は尽く失敗していて進化が望めない
0592デフォルトの名無しさん
2023/03/27(月) 12:10:13.46ID:B8NoQCc/safeと限定しているところが誠実で笑える
良いと思うよ!w
0593デフォルトの名無しさん
2023/03/27(月) 12:48:40.60ID:8vpfa9xSこれまでの資産が全然違うわ
DirectXとかOpenGLとかオーディオ系の低レイヤーのやつはやっぱりC++が強い
0594デフォルトの名無しさん
2023/03/27(月) 12:49:34.80ID:8vpfa9xS0595デフォルトの名無しさん
2023/03/27(月) 13:03:55.96ID:03NojB4Mただラッパ書くだけじゃなくて、Rustで書けばAPIを適切に使用してるって保証されるものじゃないとね
0596デフォルトの名無しさん
2023/03/27(月) 13:12:32.89ID:B8NoQCc/Cと共存なんて考えだと廃れて消えると思うよ
カーネルからRustにしないとな
以下の考察は俺も同じ印象を持っている
RustもJuliaやGoみたいに廃れて消えていく気がしている。
https://qiita.com/AKKYM/items/78c04840bc72d9db834d
0597デフォルトの名無しさん
2023/03/27(月) 13:14:48.15ID:B8NoQCc/言語が使われるかどうかはその上の生態学の問題だからね
0598デフォルトの名無しさん
2023/03/27(月) 13:36:37.38ID:f2pr1T08スマホにはシェルスクリプトがないから？
0599デフォルトの名無しさん
2023/03/27(月) 13:46:30.78ID:B8NoQCc/諸君のフラストレーションは解消されないと思うよ
0600デフォルトの名無しさん
2023/03/27(月) 13:50:47.73ID:B8NoQCc/C++覚えればCの知識は付いてくるが
CとRust両方覚えるの面倒やん?
CをリプレースしなければC++もリプレスできん
0601デフォルトの名無しさん
2023/03/27(月) 14:18:03.99ID:arDcYvabC++の可読性の低さはそのような無理矢理な機能拡張の失敗にある
0602デフォルトの名無しさん
2023/03/27(月) 14:34:40.20ID:kviG1IE2https://qiita.com/tatsuya6502/items/cd41599291e2e5f38a4a
0603デフォルトの名無しさん
2023/03/27(月) 14:43:24.48ID:kviG1IE2>C++覚えればCの知識は付いてくるが
doubt
0604デフォルトの名無しさん
2023/03/27(月) 14:44:18.04ID:44rZZrUP反例は?
0605デフォルトの名無しさん
2023/03/27(月) 14:59:46.99ID:kviG1IE2>TypeScriptはずっと流行っていてこれから廃れていく気はしない。この差はなんなんだろう。。。
たいしたことやってないから
0606デフォルトの名無しさん
2023/03/27(月) 16:45:29.16ID:qgA22f4oQiitaって5chと同レベルだったんだな
記事もコメントもここまで酷いとは
0607デフォルトの名無しさん
2023/03/27(月) 17:02:39.76ID:V0RoakbK0608デフォルトの名無しさん
2023/03/27(月) 17:10:12.43ID:f4PBXzjX記事はバカだけどコメントはまあいいんじゃね？
それよりも、Rustを置き換えられる言語が出現しないと、Rustの天下が続きそ。
C並みに高速で何でも書けてGCもなく、にも関わらず様々な安全性が静的に保証される言語が、Rust以外に芽も出てこなさげ。
0609デフォルトの名無しさん
2023/03/27(月) 17:19:21.38ID:8vpfa9xSMSだから
0610デフォルトの名無しさん
2023/03/27(月) 17:23:03.66ID:ztwrSg39自演バレないように新文体開拓しようとしてんのマジでキモいわ
0611デフォルトの名無しさん
2023/03/27(月) 17:26:14.23ID:8vpfa9xSTypeScriptはC#やDelphiを作ったアンダースヘルスバーグが設計してるからです
以上
0612デフォルトの名無しさん
2023/03/27(月) 17:26:50.78ID:8vpfa9xS周り見えてない人なのかな？
0613デフォルトの名無しさん
2023/03/27(月) 17:27:28.03ID:8vpfa9xS0614デフォルトの名無しさん
2023/03/27(月) 17:28:15.22ID:8vpfa9xSゲームくらいじゃね？
0615デフォルトの名無しさん
2023/03/27(月) 17:28:57.15ID:8vpfa9xSマジで何してんの？って話よな
0616デフォルトの名無しさん
2023/03/27(月) 17:35:59.10ID:tLmo//P+車載ソフト関係だけど、命に関わるようなシステムは最大実行時間を理論的に算出出来ないとアカんのや
GCだとそれが出来ないから論外なんや、、
0617デフォルトの名無しさん
2023/03/27(月) 17:37:53.83ID:8vpfa9xSほんでその車載ソフトはRustで書かれんのか？
0618デフォルトの名無しさん
2023/03/27(月) 17:39:01.06ID:tLmo//P+いや、まだ言語的に対応してないからC/C++だね、、
0619デフォルトの名無しさん
2023/03/27(月) 17:40:35.92ID:8vpfa9xSやっぱりね
いつになるんだろうねRustが対応するの
一生来ないかもしれん
0620デフォルトの名無しさん
2023/03/27(月) 17:52:34.31ID:tLmo//P+そうやね
ぶっちゃけ危なそうなものはコーディングルールで縛られるし、過去トラブルや不具合対策も沢山あるから困らないんだよね。
品質保証のためにアセンブラも見るけど、C/C++はアセンブラと比べながら見やすいし
0621デフォルトの名無しさん
2023/03/27(月) 18:00:15.28ID:BAd7DBJ1そこでリアルタイムGCですよ
0622デフォルトの名無しさん
2023/03/27(月) 18:06:46.35ID:f2pr1T08電気代よりも例えば家賃の方がよっぽど高い人生だったら一生使わないのでは
0623デフォルトの名無しさん
2023/03/27(月) 18:13:00.08ID:arDcYvabアドバンテージが何も残っていない
0624デフォルトの名無しさん
2023/03/27(月) 18:17:46.08ID:9iT9giTF「Rustのライブラリはあらかた揃って退屈なメンテ作業しか残ってない状態、そんなつまらない作業誰もしないから誰もメンテしなくなってだんだん人が離れていく一歩手前」みたいなQiiitaの記事あったけど、そんなライブラリ充実し始めてる？
0625デフォルトの名無しさん
2023/03/27(月) 18:18:17.10ID:8vpfa9xSいやしてないよ
0626デフォルトの名無しさん
2023/03/27(月) 18:27:56.70ID:IKh8n5QH既存プロジェクトは大規模な更新でしか切り替わらないだろな
0627デフォルトの名無しさん
2023/03/27(月) 18:43:27.53ID:9iT9giTFライブラリが充実してきてみんなが使い出すかどうかって技術的な問題だけじゃなくてその言語が出てきたタイミングとか社会情勢とか背景とかそういう要素もかなり濃密に効いてて、その意味でPythonはすげぇタイミングよかったという気はする
0628デフォルトの名無しさん
2023/03/27(月) 19:22:16.60ID:dqg9sWUs儲かるから流行るんだぞ
0629デフォルトの名無しさん
2023/03/27(月) 19:23:51.08ID:IKh8n5QH既存のものはそのまま使えば良くそのまま使われている
新たなものはRustになっている
それだけの話
0630デフォルトの名無しさん
2023/03/27(月) 19:25:47.39ID:ZBCIgMCl0631デフォルトの名無しさん
2023/03/27(月) 19:33:28.90ID:byKu+Dgzrustもキラープロダクトが出れば一気に普及する
0632デフォルトの名無しさん
2023/03/27(月) 19:43:52.09ID:f4PBXzjX節電というか、こちらはクラウド利用だけど間接的には当たりじゃね？
GC言語からRustへだけど、CPUコストとメモリコストが激減、だからクラウド側では節電となり、Rustはエコ。
GCなく自動メモリ解放する言語Rustの出現が今までの流れを変えた。
0633デフォルトの名無しさん
2023/03/27(月) 20:10:16.56ID:eSmIEcJiC/C++からRustへの安全性を高める動き
GC言語からRustへの高速化＆省メモリ化の動き
まれに片方の動きの意識しかない人が想像力の欠如した書き込みをしている
0634デフォルトの名無しさん
2023/03/27(月) 20:59:51.90ID:f2pr1T08逆に1つの道具で色々できるという話はあまり聞かない
0635デフォルトの名無しさん
2023/03/27(月) 21:16:18.71ID:ztwrSg39AWSのバックエンドでRust使ってエネルギー効率が向上してもじゃあ俺もRust使おうとはならんのよ
理性的に考えろ
0636デフォルトの名無しさん
2023/03/27(月) 21:18:03.30ID:CXyrf6Yuこちらはクラウド利用www
0637デフォルトの名無しさん
2023/03/27(月) 21:25:42.06ID:B8NoQCc/Cのニッチェを奪わなければRustはこの先生
きのこれない
0638デフォルトの名無しさん
2023/03/27(月) 21:59:50.76ID:dqg9sWUsエンジニアの上澄が認めたのだから争っても無駄
0639デフォルトの名無しさん
2023/03/27(月) 22:10:09.18ID:B8NoQCc/儲かってる人ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
Rustで何開発してるの?
0640デフォルトの名無しさん
2023/03/27(月) 23:10:41.22ID:6TNfXJr3Rustの提唱するパラダイムがうまくいきだしたら、他言語もこぞって取り込むと思う
アカンとなったら、次のパラダイムが提唱…されるのは先の話だろうなあ 俺生きてるかなまじで
0641デフォルトの名無しさん
2023/03/27(月) 23:13:47.59ID:xSQDJ/Larustは新鮮で学べてるけど
c++はやばくね、、、
依存やらのコンパイルの時点で挫折しそうなんだが
ドキュメントもわけわからんし
0642デフォルトの名無しさん
2023/03/27(月) 23:20:50.21ID:B8NoQCc/所有権って途中から取り込めるの?
パターンマッチングとかは余裕だろうけど
0643デフォルトの名無しさん
2023/03/27(月) 23:43:11.84ID:Y8evRbQyただ他言語もこぞってと言ってもGC言語は対象外なのでメジャーな言語で可能性があるのはC++のみ
0644デフォルトの名無しさん
2023/03/27(月) 23:51:52.30ID:B8NoQCc/デフォルトでコピーコンストラクタやコピー代入演算子が起動するところを
moveコンストラクタやmove代入演算子が起動するように変更するってことでしょ?
余裕な訳ないじゃん
copy by valueな言語では後方互換性が犠牲になるので導入無理だよ
0645デフォルトの名無しさん
2023/03/28(火) 00:23:27.41ID:Q1TWiepdいろんなやり方があるけど実装ができないようなものはない
やろうとすればどのやり方にするのがいいか
細かい仕様をどうするのがいいか
そういう意思決定に時間がかかるだけ
所有権システムをあとから取り込めないなんて発想をする人がRustを宣伝してるのがむしろ驚き
0646デフォルトの名無しさん
2023/03/28(火) 00:42:21.55ID:ecLsJgbH文章読めないのかな?
今まででのコードでインスタンスがコピーされるところを
勝手にmoveにすり替えられたら大惨事だろw
今まで書いたコードを全部書き換えることになる
つまり後方互換性が犠牲になる
C++の開発当初からの方針で最大の特徴はCを内包していること
CもC++もcopy-by-valueな言語
0647デフォルトの名無しさん
2023/03/28(火) 00:54:04.89ID:9+wNikJy0648デフォルトの名無しさん
2023/03/28(火) 01:08:09.67ID:ecLsJgbH問題についてどう解決するかを書きな?
0649デフォルトの名無しさん
2023/03/28(火) 01:35:54.97ID:m2o7Qw0dしかし許された
また同じことをやってまた許されることは可能かもな
0650デフォルトの名無しさん
2023/03/28(火) 01:46:32.83ID:ImlVuHSqあとはsafeブロックとか？
0651デフォルトの名無しさん
2023/03/28(火) 02:00:41.86ID:ecLsJgbHほぼ互換性あるだろ? どういったケースのこと書いてるの?
0652デフォルトの名無しさん
2023/03/28(火) 02:21:00.53ID:gbUXYbOA新規プロジェクトって例えばどれよ？
0653デフォルトの名無しさん
2023/03/28(火) 02:21:41.39ID:gbUXYbOAなんの仕事してんの？
0654デフォルトの名無しさん
2023/03/28(火) 02:22:00.97ID:WlqhC76+>デフォルトでコピーコンストラクタやコピー代入演算子が起動するところを
>moveコンストラクタやmove代入演算子が起動するように変更するってことでしょ?
アフォ発見！
0655デフォルトの名無しさん
2023/03/28(火) 02:24:01.41ID:gbUXYbOAオブジェクト指向できてないからだろそれ
C#学べ
0656デフォルトの名無しさん
2023/03/28(火) 02:25:39.63ID:6yQ3WRoTパターンマッチング導入はC++23でも無理
出てる案では便利になりそうにない
こればっかりは結果論になってしまうがRustと比較するとこれまでの基本設計が失敗してる
0657デフォルトの名無しさん
2023/03/28(火) 02:31:45.17ID:6yQ3WRoT現状のスマポとmoveを用いたC++の所有権システムはRustのシンプルな記述と比べると面倒で忘れたりミスしたりしてしまうがあれが限界っぽい
後方互換性を保ったままC++を快適にするのは不可能
0658デフォルトの名無しさん
2023/03/28(火) 02:43:54.99ID:6yQ3WRoTそいつが書いている3つの言語ともにオブジェクト指向なのでC#は不要だろう
Pythonは普通
JavaScriptはプロトタイプ方式の継承だがそれ以外は普通
Rustは継承を排除していて機能(メソッド群)毎にトレイトで合成するがそれ以外は普通
0659デフォルトの名無しさん
2023/03/28(火) 03:31:25.51ID:gbUXYbOAPythonやってるやつはオブジェクト指向理解できてないやつ多いよ
JavaScriptはまぁ基本使わんし
Rustはオブジェクト指向的なことできるようにしてるけどオブジェクト指向わからんやつ向けに制限かけてるって印象
0660デフォルトの名無しさん
2023/03/28(火) 05:56:18.37ID:uty8q6BBC++では、やたらとややこしいクラスが上がってくる
それ〇〇使いたいだけちゃうん、みたいな
Rustが普及したら、Rust流のスマポにみんな慣れるから、自分の母語でも使うようになるよ
0661デフォルトの名無しさん
2023/03/28(火) 06:40:30.67ID:qh0NVSBOその3つの言語をやってることから例えばウェブ方面だとしても
PythonでDjangoなどのフレームワークを使うにはオブジェクト指向は基本知識として不可欠
JavaScriptもReactなどののフレームワークを使うにはオブジェクト指向は基本知識として不可欠
Rustに対してはデタラメな印象だけで基礎的な理解すらなし
このスレで連投してる人の中で最もレベル低すぎ
0662デフォルトの名無しさん
2023/03/28(火) 06:47:56.40ID:uty8q6BBそんな難しくないけど、美しく書くには多少の経験は必要
あと、吐かれるコードにはもうちょい気を留めてほしいなと、マシン語寄りの俺は思っちゃうな
「そういう」用途ばっかりじゃないのはわかるんだけど
0663デフォルトの名無しさん
2023/03/28(火) 07:05:58.21ID:uty8q6BBwebも、APIがOOP式で提供されてるから、OOP無関係とは言えないけど、
自分でどんどんクラスを編み出して問題解決するC++とは、OOPに向かう姿勢は異なってくるね
クラスは簡潔なほうが、結局効率もいいんだけどねｗ
0664デフォルトの名無しさん
2023/03/28(火) 07:15:22.07ID:qh0NVSBOそれはPythonでもJavaScriptでも同じ
Web APIと関係なくプログラム独自の部分も自分でどんどんクラスを編み出して問題解決する
他を知らないためC++だけを何か特別だと思い込んでそうだな
0665デフォルトの名無しさん
2023/03/28(火) 07:20:37.19ID:uty8q6BBどこだって、ライブラリ作成者はOOPに精通してるもんだが、
C++は、OOPに精通してないと、使ってますとか公言できないもんね
むっちゃ煽られるよｗ その違いはあるなって思った
0666デフォルトの名無しさん
2023/03/28(火) 07:41:04.68ID:qh0NVSBO初心者かね
0667デフォルトの名無しさん
2023/03/28(火) 07:49:36.20ID:uty8q6BBあるいは、traitsやattribute,constexpr を織り交ぜて、ほぼゼロサンクなバイナリを叩き出せるレベル
俺は初心者だからそのレベルにはないな
ちょっとよそよりは要求レベルは高いだろって思ってる
母語のことはちょっとだけ誇りに思ってるけど、それより、一長一短的立場
0668デフォルトの名無しさん
2023/03/28(火) 08:58:26.51ID:C7yLEzi8なんだけど…ソース単位で生ポ禁止ってのが普及しないんだよね
0669デフォルトの名無しさん
2023/03/28(火) 09:04:22.01ID:u9f8RzdU0670デフォルトの名無しさん
2023/03/28(火) 09:37:27.95ID:fedCMYV9嫌だからわかってないんだってばこいつはさ
だからC++の依存関係で頭パンクすんだよ
0671デフォルトの名無しさん
2023/03/28(火) 09:39:21.00ID:fedCMYV9>>641
こいつがオブジェクト指向理解してないのは確かだろ
0672デフォルトの名無しさん
2023/03/28(火) 09:56:21.67ID:cZnvlJgt君がオブジェクト指向理解できてなさそう
0673デフォルトの名無しさん
2023/03/28(火) 10:06:33.49ID:C7yLEzi8C++も なんでもスタックに置きたいんだけど、きつきつなのが本来なんだよね
どんどんスタックを食うのは野暮っていう流儀もある
Rust流はメモリ使用の局所化を促進するから、
メモリキャッシュまで考慮すると、悔しいけどC++より効率出る余地がある
まあ実測してみないと、知らんけどｗ
0674デフォルトの名無しさん
2023/03/28(火) 10:06:36.56ID:vBvHBfxi奴はクラスを書けたらオブジェクト指向を理解してると思ってるみたいだからな
0675デフォルトの名無しさん
2023/03/28(火) 10:09:59.68ID:fedCMYV9確かになw
普通逆で一番抽象化できるところで遡ってツリー形式にやっていくもんだもんな
0676デフォルトの名無しさん
2023/03/28(火) 10:28:38.80ID:u9f8RzdU「newを書かなきゃ」ってのは
make_uniqueとmake_sharedを使えって意味でした
0677デフォルトの名無しさん
2023/03/28(火) 10:51:13.90ID:P0df9Gxx極力オブジェクト指向的な書き方をしないほうが
メンテナンス性も可読性も高まる言語だから
C++やC#とは事情が違うわな
0678デフォルトの名無しさん
2023/03/28(火) 17:06:18.21ID:aUMSgZvECRTPはC++のOOPで最も効率よい実装となり必須なテクニックであるが
美しいというのはウソでむしろC++の汚さの象徴の一つになっている
初心者や他言語の人たちもいるようだからわかりやすいコード
例として各派生のadd1()を用いて共通のadd2()やadd3()などを用意する場合
template<typename T>
struct AddN {
void add2() {
static_cast<T*>(this)->add1();
static_cast<T*>(this)->add1();
}
void add3 ...略
};
struct Foo : AddN<Foo> {
int x;
Foo(int i) : x(i) {}
void add1() {
this->x++;
}
};
以上となり慣れてしまうと感覚が麻痺してしまうが
CRTP (Curiously Recurring Template Pattern)の名の通り
「Foo : AddN<Foo>」といちいち自分をパタメータとして与えなければならない
「static_cast<T*>(this)」といちいちダウンキャストをしなければならない
このように「美しくない無駄なコード」になっている
つづく
0679デフォルトの名無しさん
2023/03/28(火) 17:07:43.55ID:aUMSgZvE一方でRustではトレイトを用いて以下のコードとなる
C++での「美しくない無駄なコード」部分を消し去った状況とほぼ一致している
trait AddN {
fn add1(&mut self);
fn add2(&mut self) {
self.add1();
self.add1();
}
fn add3 ...略
}
struct Foo(i32);
impl AddN for Foo {
fn add1(&mut self) {
self.0 += 1;
}
}
逆にRustのこのコードと同じことを同じようにゼロコストで実現するには
C++ではCRTPを「美しくない無駄なコード」とはいえ使わざるをえない
0680デフォルトの名無しさん
2023/03/28(火) 17:58:49.48ID:C7yLEzi8早まるな、俺は【CRTPが】美しいとは言ってない
初めて見たときは、なんじゃこりゃすげぇとは思ったけどねｗ
0681デフォルトの名無しさん
2023/03/28(火) 20:04:32.17ID:jfKwOIRnCRTPを使わないで仮想関数にすると実行時のvtable経由のオーバーヘッドがあるんだよな
Rustは何も指定しなくてもCRTPと同じ状況になるから記述はシンプルで実行時オーバーヘッドもなく速いわけか
0682デフォルトの名無しさん
2023/03/28(火) 20:17:15.74ID:fedCMYV9アイペンテックとか？
0683デフォルトの名無しさん
2023/03/28(火) 20:32:01.59ID:iKmwqFtY関数呼び出しのvtableオーバーヘッドがあるだけでなくインライン展開ができず最適化の機会も失われている
Rustは基本が静的ポリモーフィズムだからそれらのコストがなく速い
0684デフォルトの名無しさん
2023/03/28(火) 20:33:07.14ID:QUV/Fh6a0685デフォルトの名無しさん
2023/03/28(火) 21:00:58.63ID:HSIaJTs3適当なことを言うと規格票で殴り殺される
それがC++村の掟
悪いことは言わない
君はここから早く撤退したほうがいい
0686デフォルトの名無しさん
2023/03/28(火) 21:30:24.26ID:pvMX8JEcRubyの話はもういいよ
0687デフォルトの名無しさん
2023/03/28(火) 21:35:05.32ID:iKmwqFtYCRTPを使えば常にインライン展開されるわけではない
CRTPを使った時のみ(vtable経由にならず静的に動作が確定するため)インライン展開が可能となり最適化の可能性も広がり速くなるという話
C++ではCRTPを使わないとRustと同等の速さになれない
0688デフォルトの名無しさん
2023/03/28(火) 22:58:28.07ID:rZiXTukV0689デフォルトの名無しさん
2023/03/28(火) 23:08:36.42ID:u9f8RzdU0690デフォルトの名無しさん
2023/03/29(水) 00:01:28.04ID:jlgG+N1i使ってる関数が常に固定値（nullとか）を返すって事前に分かればそれによって分岐の整理ができたりするけど
間にvtableが挟まるとそういう予測が難しくなる
0691デフォルトの名無しさん
2023/03/29(水) 00:09:55.54ID:jqKX3lj0CRTPを使わないと真に実現できないのはメソッド記法だけ
そしてvtableとインライン展開に君が想像するような関係性は無い
というか、同じ推論をRustで適用すれば「object-safeなtraitへのimplはvtableを量産しインライン展開を阻害するので悪、やめろ」ということにならないかい？
自分が何を書こうとしているのかよく考えてから書き込むことだ
0692デフォルトの名無しさん
2023/03/29(水) 00:26:00.18ID:hbkToQM4少々vtableを経ても平気だとしても、そういうバイナリ吐いてほしくないときはある
バイナリは覗かれるもの
0693デフォルトの名無しさん
2023/03/29(水) 02:17:33.72ID:0e8thR9U馬鹿馬鹿しい。
0694デフォルトの名無しさん
2023/03/29(水) 03:03:32.31ID:F3x5gAOrvtableの参照による速度低下よりも最適化できないことによる関数呼び出しのコストが重い
例えば>>679のRust及びCRTPで書かれたC++コードはどちらもadd2()関数呼び出しの中身は最適化されて単なる「add 2」となる
しかしCRTPを用いずにC++で書くとadd2()関数呼び出しの中身は「vtable参照」＋「add1()関数呼び出し」＋「add 1」を2回することになる
0695デフォルトの名無しさん
2023/03/29(水) 08:27:05.33ID:hbkToQM4パフォーマンスを測るまでもなく、吐かれるバイナリの汚さ
書いた一言一句が何になるか、気になって仕方ないのがC++erだよ(諸派あり、用途にもよる
バイナリエディタに放り込んだらわかるまである
0696デフォルトの名無しさん
2023/03/29(水) 08:41:42.91ID:jqKX3lj0おっ、そうだな
https://godbolt.org/z/M71z9cx74
0697デフォルトの名無しさん
2023/03/29(水) 09:39:43.93ID:gptXJHJdhttps://en.wikipedia.org/wiki/Virtual_method_table#Example
CRTPを使わないとvirtual method tableが出てきて不利になる
0698デフォルトの名無しさん
2023/03/29(水) 10:58:30.49ID:DCEr0ZuV0699デフォルトの名無しさん
2023/03/29(水) 11:49:15.76ID:KmrCY6Bhこれってダウンキャスト入ってるから危険なこともできそう
相当するコードはRustではコンパイル通らない?
#include <iostream>
#define DOUT(arg) std::cout << #arg": " << arg << std::endl
template<typename T> struct AddN {
void add2() {
static_cast<T*>(this)->add1();
static_cast<T*>(this)->add1();
}
};
struct Foo : AddN<Foo> {
int x;
Foo(int i) : x(i) {}
void add1() {
this->x++;
}
};
struct Bar : AddN<Foo> {
double y;
Bar(double i) : y(i) {}
void add1() {
this->y+=0.1;
}
};
int main () {
Foo foo (1); Bar bar (0.1);
DOUT (foo.x); DOUT (bar.y);
foo.add1 (); bar.add1 ();
DOUT (foo.x); DOUT (bar.y);
return 0;
}
0700デフォルトの名無しさん
2023/03/29(水) 11:51:44.76ID:KmrCY6Bh$ ./a.out
foo.x: 1
bar.y: 0.1
foo.x: 2
bar.y: 0.2
最後のbar.yは1.1になると思ってたんだがはて?
0701デフォルトの名無しさん
2023/03/29(水) 12:42:03.29ID:KmrCY6Bhダウンキャストのところでコンパイルエラー出て良いようなもんだけど
何で通すんだろ? templateだとチェックを緩和してるのかな?
あるいはコンパイラのバグかな?
$ g++ --version
g++ (Debian 10.2.1-6) 10.2.1 20210110
0702デフォルトの名無しさん
2023/03/29(水) 12:43:14.11ID:KmrCY6Bh+static_cast<T*>(this)->add1();のところでコンパイルエラー出て良いようなもんだけど
0703デフォルトの名無しさん
2023/03/29(水) 12:55:36.31ID:jlgG+N1idoubleをint扱いして1足しても1/(2^53)（←不正確、指数部による）くらいしか変動しないのかな
FooもBarもAddN継承してるからstatic_castでコンパイルエラーは出ないはず
Rustはクラス継承がないからstatic_castとの正確な比較はできない
traitで似たようなコード書くときはSelfキーワードで自分の型を指すからダウンキャスト必要ないし
敢えてstatic_castと対応させるならtransmuteだろうけどunsafe付きの関数だから危険でもコンパイルは通せる
（unsafeを使う範囲の安全性保証はプログラマの責任）
0704デフォルトの名無しさん
2023/03/29(水) 13:10:19.46ID:KmrCY6Bh>最近のC++はよく分からんけどその例だとadd2使わないと多分変なことにならない
あーごめんごめん！興味があったのはadd2を呼んだときの挙動だった
- foo.add1 (); bar.add1 ();
+ foo.add2 (); bar.add2 ();
$ ./test
foo.x: 1
bar.y: 0.1
foo.x: 3
bar.y: 0.1 <- 鼻から悪魔
>FooもBarもAddN継承してるからstatic_castでコンパイルエラーは出ないはず
なるほどキャストしているthisはAddN<Foo>*だから
Foo*にもBar*にもダウンキャストできるってことね
ありがとう
0705デフォルトの名無しさん
2023/03/29(水) 13:47:10.36ID:KmrCY6Bhでそれはvtable介してadd1にアクセスするのと変わらない
プログラマの責任でstatic_castして効率化する
ってテクニックは俺は割と好きだけども
0706デフォルトの名無しさん
2023/03/29(水) 14:18:14.91ID:JN59fMMetransmuteはダウンキャストではなく任意の型同士の強引な型変換(読み替え)だから当然unsafe
一方でダウンキャストは親から子、基底から派生、抽象から具体への変換を指す
Rustの場合は抽象的なトレイトから具体的な型への変換がダウンキャストとなる
Rustは基本的には静的ポリモーフィズムで
コンパイル時点で各具体的な型のコードへ安全に置き換わるモノモーフィズムなので
C++のstatic_castのような危険のあるダウンキャストを必要としないが正解
Rustでもdyn Traitを用いた場合のみ動的ポリモーフィズムとなり
C++のdynamic_castと同様に実行時ダウンキャストがdowncast()/downcast_ref()/downcast_mut()で可能だが
C++とは異なりRustはNull安全でダウンキャストできる
0707デフォルトの名無しさん
2023/03/29(水) 14:59:38.14ID:hbkToQM40708デフォルトの名無しさん
2023/03/29(水) 15:00:17.60ID:hbkToQM40709デフォルトの名無しさん
2023/03/29(水) 15:30:35.32ID:jlgG+N1iかといって分岐しないなら動的検査の意味ないし
0710デフォルトの名無しさん
2023/03/29(水) 15:35:36.31ID:jd4hHaC+ダウンキャストの根本的な問題点を理解してないね
静的か動的かUBかどうかは副次的な問題点に過ぎない
0711デフォルトの名無しさん
2023/03/29(水) 15:40:07.88ID:R/bWJVR7C++のdynamic_castもRustのdowncast_refも生成コードはどちらもダウンキャスト成功時はそのままポインタを返して失敗時は0を返す点で効率も同じだけど
Rustでは返す型としてはそれをポインタで直接に表さずにOption<&T>を返すと表現させて
成功時はOption::Some(&T)を返して失敗時の0はOption::Noneとして返すため
プログラムコード上はNoneかSomeか生成コードでは0か否かをチェックせずには使えないわけだ
C++でのNullポインタか否かのチェック忘れを静的な型チェックで防止できるってことは
もしかしてC++でもdynamic_castやその他のNullポインタを返すライブラリ全てをstd::optionalを返すように変更すればNull安全になるんじゃないか？
0712デフォルトの名無しさん
2023/03/29(水) 15:45:49.19ID:RttupHdJ闇雲に否定して別の問題点があると主張しつつ
その問題点を述べることは一切ないので書き込みの中身がない
0713デフォルトの名無しさん
2023/03/29(水) 17:50:54.05ID:aWl/4JyAデフォルトmoveの導入は無理だと思ってるくせにNull安全は導入できると思ってるのかw
オツム弱っww
0714デフォルトの名無しさん
2023/03/29(水) 18:18:44.67ID:eKurmGUmdynamic_castの返り値を確認しないやつは
流石におらんと思うよ
静的に確認してくれても全く嬉しくない
0715デフォルトの名無しさん
2023/03/29(水) 18:19:38.85ID:eKurmGUm静的に確認を強制されても嬉しくない
0716デフォルトの名無しさん
2023/03/29(水) 18:50:51.61ID:3DtieHtvヌルを使ってはダメ
0717デフォルトの名無しさん
2023/03/29(水) 19:05:30.65ID:KmrCY6BhC++では指し示した先にインスタンスがあるかどうか
分からんときにのみポインタを使う
確実にあるときは参照を使うのが流儀
ポインタが使われるところではnullptrのチェックを行う
この流儀の部分を守らないスカタンが問題なんだな
Cに参照がないので上記流儀が守られないことも問題
0718デフォルトの名無しさん
2023/03/29(水) 19:30:08.82ID:ap6Xt56VなぜそのC++のプログラムは正しく動かいていないの？
bar.yはadd2()で0.2足されて0.1から0.3にならないといけないのに0.1のままになってる
>>699のソースコードを見ても正しく動かない原因がよくわからない
0719デフォルトの名無しさん
2023/03/29(水) 19:36:28.24ID:KmrCY6BhBarはAddN<Bar>ではなくAddN<Foo>を継承しているから
0720デフォルトの名無しさん
2023/03/29(水) 19:41:07.31ID:ap6Xt56Vadd2()としてBarの+0.2が使われずFooの+2か使われるということ？
bar.yが2.1になっていないのはなぜ？
0721デフォルトの名無しさん
2023/03/29(水) 19:53:07.69ID:KmrCY6Bhvoid Add <Foo>::add2() {
static_cast<Foo*>(this)->add1();
static_cast<Foo*>(this)->add1();
}
thisはBarの基底AddN<Foo>*のポインタ
これをBarと無関係のFoo*にキャストしたら動作は不定
0722デフォルトの名無しさん
2023/03/29(水) 20:09:37.10ID:ap6Xt56V浮動小数点に対してそれを整数と見て+2してしまっているのかな
本来はコンパイル段階でエラーにしないとやばそうだ
今回はっきり動いていないとわかるケースだからいいけど何となく動いてしまってるケースがあると恐ろしい
0723デフォルトの名無しさん
2023/03/29(水) 20:11:29.28ID:KmrCY6Bhtemplate<typename T> struct AddN {
void add2() {
dynamic_cast<T&>(*this).add1();
dynamic_cast<T&>(*this).add1();
}
virtual ~AddN () {};
};
0724デフォルトの名無しさん
2023/03/29(水) 20:13:55.05ID:AtW1ukjc0725デフォルトの名無しさん
2023/03/29(水) 20:29:34.23ID:KmrCY6Bh0726デフォルトの名無しさん
2023/03/29(水) 20:42:15.15ID:rGt9yURA0727デフォルトの名無しさん
2023/03/29(水) 20:50:49.78ID:ij9aGzziなぜコンパイラは型不一致エラーを出せないんだ？
0728デフォルトの名無しさん
2023/03/29(水) 21:21:00.23ID:iEVzPlea実行デバッグが激減して開発効率も高い
0729デフォルトの名無しさん
2023/03/29(水) 21:39:38.92ID:KmrCY6Bh0730デフォルトの名無しさん
2023/03/29(水) 22:02:01.80ID:iEVzPlea0731デフォルトの名無しさん
2023/03/29(水) 23:01:50.75ID:UIOCT5jB有限個のバイナリファイルが正しく出力されればいいだけなので
ソースコードをチェックしなくても出力をチェックすればいいのでは？
0732デフォルトの名無しさん
2023/03/30(木) 06:54:28.38ID:xjlzONIR「違う」ところにひっかかってる traceを加えてみると誤解がとけるぞ
https://wandbox.org/permlink/AsyGpe34rpZ3en8v
0733デフォルトの名無しさん
2023/03/30(木) 06:54:54.18ID:uZvbGS3cC++ 最強カミソリ
剃り残しナシ
Rust 安全カミソリ
キレテナーィ なまくら
C# イケてるが
GCがあるからダメぽ
Java 論外
ヌルポとGCがあるからダメぽ
こんな感じ？
0734デフォルトの名無しさん
2023/03/30(木) 07:08:43.78ID:xjlzONIR0735デフォルトの名無しさん
2023/03/30(木) 07:25:50.11ID:xjlzONIR氏ぬまで忘れないと思う だからある意味最強、そんな奴が結構多いんだと思う
「ちゃんと話せ」って躾けられたのも、良し悪し
0736デフォルトの名無しさん
2023/03/30(木) 07:29:05.38ID:Lly0YXlC逆だろ
RustはC++ができることは何でもできる
C++はできないことが多すぎ
0737デフォルトの名無しさん
2023/03/30(木) 07:42:11.73ID:w91B/KcY0738デフォルトの名無しさん
2023/03/30(木) 07:43:46.76ID:xjlzONIR0739デフォルトの名無しさん
2023/03/30(木) 08:01:00.44ID:Lly0YXlCC++はできないことが多すぎる
このスレに出てきた話だけでも
代数的データ型
パターンマッチング
各種null安全
データ競合安全
メモリ安全
など多数
0740デフォルトの名無しさん
2023/03/30(木) 08:18:36.82ID:PJ70lfxq強制する方法がないから、ちっとも普及しないんだよね
0741デフォルトの名無しさん
2023/03/30(木) 08:28:14.61ID:Lly0YXlCC++はそのプリミティブを多数欠いている
まさか代数的データ型をunionで頑張ればできると主張するのか？
パターンマッチングは構文だからC++には無理
データ競合を静的に検知する方法もない
0742デフォルトの名無しさん
2023/03/30(木) 08:32:28.84ID:PJ70lfxqパターンマッチングは、いまどきIDEが記述支援するんだから、やってできなくはない
データ競合やらは、「そういう」スマポを導入すればいい
でもね、みんな使わないんだわ 使われないものは、ないものとして詰られても仕方ない
あ、Cとおんなじように、入れ子になった構造体をささっと書きたいとかは思うね
もうできるようになったっけ?
0743デフォルトの名無しさん
2023/03/30(木) 08:35:47.70ID:2ioUidZk0744デフォルトの名無しさん
2023/03/30(木) 09:18:55.32ID:PJ70lfxqパターンマッチング Rust でぐぐったら全然違うものが出てきたぜ その節は撤回 ちょっと読んでみる
0745デフォルトの名無しさん
2023/03/30(木) 10:37:10.30ID:z+Rtq9PG0746デフォルトの名無しさん
2023/03/30(木) 10:45:06.95ID:7YA3tv0i0747デフォルトの名無しさん
2023/03/30(木) 10:56:39.82ID:7YA3tv0i提案段階の機能を除けば一番直和型を直接的に表現できていると思う
https://www.modernescpp.com/index.php/visiting-a-std-variant-with-the-overload-pattern
0748デフォルトの名無しさん
2023/03/30(木) 10:58:13.17ID:xP+9HiJoRustのパターンマッチングはこんな感じで記述性や可読性を向上させている
fn slice_pattern(slice: &[(i32, i32)]) {
match slice {
[] => println!("空です"),
[(a, b)] => println!("要素は1つで({a},{b})です"),
[_, (123, b), ..] => println!("2つ目の前者が123なものは(123,{b})です"),
[.., next_last, _] => println!("その他の最後から2つ目の要素は{next_last:?}です"),
}
}
fn enum_pattern(shape: Shape) {
match shape {
Shape::Circle(r) => println!("半径{r}の円です"),
Shape::Rectangle(w, h) if w == h => println!("長さ{w}の正方形です"),
Shape::Rectangle(w, h) => println!("幅{w}高さ{h}の長方形です"),
x => println!("その他の図形{x:?}です"),
}
}
fn struct_pattern() {
let a = Foo { bar: 123, baz: 456, qux: 789 };
let b = Foo { baz: 555, ..a };
for Foo { bar, baz, qux } in &[a, b] {
println!("Foo: bar={bar}, baz={baz}, qux={qux}");
}
}
fn range_pattern(c: char) {
match c {
'0'..='9' => println!("数字({c})です"),
'a'..='z' | 'A'..='Z' => println!("アルファベット({c})です"),
_ => println!("その他の文字({c})です"),
}
}
0749デフォルトの名無しさん
2023/03/30(木) 11:05:35.09ID:wHEiYRW7Rustはユーザが少ないので標準で用意しとく必要がある
パタンマッチングは言語の話だけども
0750デフォルトの名無しさん
2023/03/30(木) 11:06:04.96ID:dh4KEwq/1ページ目は無料で1ページ目だけで動作するはずですが
https://xtech.nikkei.com/atcl/nxt/column/18/01920/081600022/
何故か1byteしか受け取らず常に 404 NotFound になります
何処を治せばよいですか？
0751デフォルトの名無しさん
2023/03/30(木) 11:14:15.70ID:xP+9HiJoC++のstd::variantは全体の型名を命名できない
各要素に対して専用の型を用意しなければならない
扱いづらいなど欠陥品
例えば>>748のShapeの定義例は
enum Shape {
Circle(u32),
Rectangle(u32, u32),
Parallelogram(u32, u32),
}
これだけで済む
さらに型Shapeに対して様々なメソッドを実装できる
C++ではそれぞれ困難と不可能
>>749
言語がサポートしないとライブラリでは無理
0752デフォルトの名無しさん
2023/03/30(木) 11:14:43.48ID:PJ70lfxq0753デフォルトの名無しさん
2023/03/30(木) 11:28:11.87ID:7YA3tv0i記事読んだ？
0754デフォルトの名無しさん
2023/03/30(木) 11:32:57.91ID:xP+9HiJo読んだけどそれでは無理
こちらはパターンマッチングのRustのコード例を>>748に出した
C++でも可能だと主張するならばそれぞれの実現コードをまず出すべき
0755デフォルトの名無しさん
2023/03/30(木) 11:39:46.03ID:PJ70lfxqそういう風に書きたいっていうニーズがあるんだな、表現力を誇るC++でこれが書けないのは確かに手落ちｗ
この型はあれでもこれでもあるっていうの、あんまり扱ってこなかったけど、
上手く書けば便利になるかもね ただし、ゼロサンクでね
0756デフォルトの名無しさん
2023/03/30(木) 11:39:46.85ID:xP+9HiJoそのRustのTcpListenerのサンプル動かしてみたけど普通に動いた
返すindex.htmlを用意してcargo run
ブラウザからhttp://localhost:9999/で表示された
0757デフォルトの名無しさん
2023/03/30(木) 11:46:33.32ID:7YA3tv0i「無理」とだけ言われても何も分からないので具体的にお願いします
それとも記事を読んだうえでも、無理な点の指摘は>>751ですべてだということですか
例を読んでいれば「各要素に対して専用の型を用意しなければならない」は嘘だとすぐ分かるはずですが
0758デフォルトの名無しさん
2023/03/30(木) 11:47:15.19ID:xP+9HiJoRustは>>748の各パターンマッチング例をオーバーヘッド無しで処理してくれる
使わずに手動でダラダラと書ける分もパターンマッチング記述の方が最適化が良いかもしれん
0759デフォルトの名無しさん
2023/03/30(木) 11:49:39.34ID:xP+9HiJo具体的に>>748にRustのパターンマッチングの各例のコードを書きました
次はC++でも可能だと主張するあなたが対応するC++のコードを出す番です
0760デフォルトの名無しさん
2023/03/30(木) 11:58:04.66ID:7YA3tv0iあなたの要求に答えるために質問だけさせてください
明確にしてほしいのは「何が無理なのか」の「何」の部分です
よろしくおねがいします
0761デフォルトの名無しさん
2023/03/30(木) 11:58:20.56ID:PJ70lfxq必要だから入った仕様だろう、手ごろにどっかあるはずだ お勧めのやつをたのむ
0762デフォルトの名無しさん
2023/03/30(木) 11:59:10.65ID:wHEiYRW7>>749>パタンマッチングは言語の話だけども
>例えば>>748のShapeの定義例は
>enum Shape {
> Circle(u32),
> Rectangle(u32, u32),
> Parallelogram(u32, u32),
>}
>これだけで済む
>さらに型Shapeに対して様々なメソッドを実装できる
>C++ではそれぞれ困難と不可能
横レスだけども
namespace Shape {
struct Circle {uint32_t r;};
struct Rectangle {uint32_t w; uint32_t h;};
struct Parallelogram {uint32_t ui0; uint32_t ui1;};
template <typename T> void function (ostream &os, const T &p);
void function (ostream &os, const Circle &p);
void function (ostream &os, const Rectangle &p);
// void function (ostream &os, const Parallelogram &p);
}
0763デフォルトの名無しさん
2023/03/30(木) 12:23:51.98ID:8gDdaVz7それだとShapeが型ではなく名前空間になってしまってるからダメでしょ
0764デフォルトの名無しさん
2023/03/30(木) 12:29:16.05ID:wHEiYRW7namespaceをstructに置換して最後に;つければ?
0765デフォルトの名無しさん
2023/03/30(木) 12:32:22.56ID:8gDdaVz7それだと全ての図形で必要となるメモリサイズの合計サイズが必要になっちゃうよ
0766デフォルトの名無しさん
2023/03/30(木) 12:32:39.23ID:wHEiYRW70767デフォルトの名無しさん
2023/03/30(木) 12:34:53.74ID:wHEiYRW7何か問題でも?
0768デフォルトの名無しさん
2023/03/30(木) 12:35:39.04ID:7YA3tv0iメンバ型定義しただけではメンバ変数は増えないから、サイズも増えないよ
0769デフォルトの名無しさん
2023/03/30(木) 12:35:54.76ID:wHEiYRW7>それだとShapeが型ではなく名前空間になってしまってるからダメでしょ
何で?
0770デフォルトの名無しさん
2023/03/30(木) 12:47:49.82ID:xP+9HiJoRustはパターンマッチングがあるため>>748のようにシンプルに記述ができて可読性にも優れている
あなたはC++でも代わりの手段で表現することが可能だと主張した
それが無理ではないことをRustコードの各々に対応する具体的なC++のコードとして示してほしい
0771デフォルトの名無しさん
2023/03/30(木) 12:56:56.84ID:wHEiYRW7所有権システムと違って後方互換性が犠牲になることはないので
そのうちC++に入るよ
0772デフォルトの名無しさん
2023/03/30(木) 13:16:45.82ID:tVTq+AM2パターンマッチング>>748の2番目の例の話だからShapeは関数に渡ってくる型じゃないとまずい
単体で動くコードで比較すればはっきりすると思うのでC++版を書いて。以下はRust版
// ここは再掲
fn enum_pattern(shape: Shape) {
match shape {
Shape::Circle(r) => println!("半径{r}の円です"),
Shape::Rectangle(w, h) if w == h => println!("長さ{w}の正方形です"),
Shape::Rectangle(w, h) => println!("幅{w}高さ{h}の長方形です"),
x => println!("その他の図形{x:?}です"),
}
}
#[derive(Debug)]
enum Shape {
Circle(u32),
Rectangle(u32, u32),
Parallelogram(u32, u32),
}
fn main() {
enum_pattern(Shape::Circle(100));
enum_pattern(Shape::Rectangle(200, 300));
enum_pattern(Shape::Rectangle(567, 567));
enum_pattern(Shape::Parallelogram(789, 456));
}
// 実行結果
半径100の円です
幅200高さ300の長方形です
長さ567の正方形です
その他の図形Parallelogram(789, 456)です
0773デフォルトの名無しさん
2023/03/30(木) 13:28:40.22ID:wHEiYRW7>パターンマッチング>>748の2番目の例の話だからShapeは関数に渡ってくる型じゃないとまずい
何で?
0774デフォルトの名無しさん
2023/03/30(木) 13:31:04.03ID:wHEiYRW7>>772は...
0775デフォルトの名無しさん
2023/03/30(木) 13:31:12.50ID:tVTq+AM2Shape型が渡ってきてその処理をしてるからだよね
とりあえずC++の動くコードを出してみたら？
0776デフォルトの名無しさん
2023/03/30(木) 13:32:51.26ID:wHEiYRW7Shape型を引数で取る必要があるならC++では
Shapeを基底として継承させるよ
もちろん静的ディスパッチはできない
0777デフォルトの名無しさん
2023/03/30(木) 13:35:28.76ID:wHEiYRW7enumを使う例としては適切ではないんじゃないかな?
Rustをよく知らん俺からしたらピンとこないよ
0778デフォルトの名無しさん
2023/03/30(木) 13:39:12.89ID:8gDdaVz7ディスパッチは静的には不可能で動的にしか行われないでしょ
静的に可能なのはモノモーフィゼイションだけど今回の例では適用できませんね
いずれにしてもC++で可能だと言うコードを示してみたら？
0779デフォルトの名無しさん
2023/03/30(木) 13:39:52.45ID:PJ70lfxq0780デフォルトの名無しさん
2023/03/30(木) 13:41:01.47ID:wHEiYRW7>ディスパッチは静的には不可能で動的にしか行われないでしょ
いいえ>>762は静的に行われる
>いずれにしてもC++で可能だと言うコードを示してみたら？
>>762に示した
0781デフォルトの名無しさん
2023/03/30(木) 13:42:20.94ID:7YA3tv0istd::variantとstd::visitでパターンマッチする例です
0782デフォルトの名無しさん
2023/03/30(木) 13:52:02.49ID:tVTq+AM2動くコードじゃないと意味がないのでmain()付きの動くコードを示そうよ
Rust版は>>772
>>781
パターンマッチングを全く行なっていないじゃん
例えば分かりやすくこの項目を増やすとして
Shape::Rectangle(100, h) => println!("幅100で高さ{h}の長方形です"),
これはC++でif (w == 100)のコードになるわけだよね
それはパターンマッチングとは言わないよ
0783デフォルトの名無しさん
2023/03/30(木) 14:01:06.19ID:7YA3tv0ienumのバリアント判定に相当するパターンマッチを行っていますので、全く行っていないという指摘は正しくありません
また、>>748のenum_patternにShape::Rectangle(100, h)にマッチするコードは含まれておらず、あなたの当初の要求に含まれていないものです
新しい要求を後から追加して批判するのは、誠実な態度とは言えません
このようなことが無いように、「何が無理か」を明確にするよう確認したつもりでした
今後はこうしたことが無いように、事前よく確認することをお願い申し上げます
また値によるマッチについてですが、同様の考えで似たライブラリを実装された方を見つけました
こちらは値によるマッチに拡張したライブラリを実装されているようです
https://qiita.com/Naotonosato/items/a1e710de2b78346146d1
0784デフォルトの名無しさん
2023/03/30(木) 14:04:54.89ID:8gDdaVz7かなり苦しいね
>>748の残り3つのパターンマッチングには応用できそうもないけど書ける？
0785デフォルトの名無しさん
2023/03/30(木) 14:14:54.28ID:wHEiYRW7別に関数プロトタイプまで書いてるんだから分かりそうなものだけど...
以下は静的ディスパッチでコンパイル時に定まるよ
>>772が静的ディスパッチできないとしても
たぶん同じように書けばRustでも静的にディスパッチできると思うよ
#include <iostream>
using namespace std;
namespace Shape {
struct Circle {uint32_t r;};
struct Rectangle {uint32_t w; uint32_t h;};
struct Parallelogram {uint32_t ui0; uint32_t ui1;};
template <typename T> void function (ostream &os, const T &p) {}
void function (ostream &os, const Circle &p) {}
void function (ostream &os, const Rectangle &p) {}
}
int main () {
using namespace Shape;
Circle circle;
function (cout, circle);
Parallelogram parallelogram;
function (cout, parallelogram);
return 0;
}
0786デフォルトの名無しさん
2023/03/30(木) 14:47:32.70ID:Evbafc70このように次々と何が来るかわからないリストが渡ってきた場合
Shape::Shape shape_list[4];
shape_list[0] = Shape::Rectangle{w: 33, h: 33};
shape_list[1] = Shape::Parallelogram{ui0: 4, ui1: 33};
shape_list[2] = Shape::Rectangle{w: 33, h: 4};
shape_list[3] = Shape::Circle{10};
その時にこれで処理できるのだから動的ディスパッチをしている
for (int i = 0; i < 4; i++) {
enum_pattern(shape_list[i]);
}
0787デフォルトの名無しさん
2023/03/30(木) 15:01:18.46ID:wHEiYRW7静的ディスパッチと書いているのは俺が書いた>>762と>>785のC++の例
コンパイル時にどの関数が呼ばれるか型によって決まる
0788デフォルトの名無しさん
2023/03/30(木) 15:04:41.33ID:PJ70lfxqパタンマッチングって、こんなもんが流行ってるのね、また一つ取り残されてたぜ
0789デフォルトの名無しさん
2023/03/30(木) 15:04:46.89ID:7YA3tv0iいいえ、これは静的ディスパッチです
簡単に確認する方法として、生成されたアセンブリ中のvtableを確認する方法があります:
https://godbolt.org/z/1W7jGnWEd
"vtable for std::bad_variant_access:"が唯一のvtableであり、Circleなどのためのvtableはありません
このことから、動的ディスパッチは発生しないことが分かります
0790デフォルトの名無しさん
2023/03/30(木) 15:09:53.24ID:Evbafc70おいおい
vtable使うことだけが動的ディスパッチだと思いこんでいるのか？
実行時にデータ内容に応じて分岐することを動的ディスパッチと言う
>>786はもちろん動的ディスパッチをしている
次に何が来るかはコンパイル時点で決まらないため静的に決定は不可能だ
0791デフォルトの名無しさん
2023/03/30(木) 15:10:42.88ID:wHEiYRW7昔はなかなか規格としてまとまらなかったが最近のC++はどうした?
俺もboostに入ってたやつくらいしか追えていない
0792デフォルトの名無しさん
2023/03/30(木) 15:12:35.47ID:wHEiYRW7それはRsutのコードか? C++のコードか?
0793デフォルトの名無しさん
2023/03/30(木) 15:20:37.87ID:Evbafc70そのC++コードの話しかしていない
0794デフォルトの名無しさん
2023/03/30(木) 15:23:32.35ID:78T5MT6s>>785は静的ディスパッチだよ
コンパイル時にどの関数が呼ばれるか定まる
0795デフォルトの名無しさん
2023/03/30(木) 15:29:45.34ID:7YA3tv0iいいえ
動的ディスパッチとは、多態メソッドの呼び出し式を実行するときに、具体型に応じて実際に呼ばれる関数が振り分けられることを言います
https://en.wikipedia.org/wiki/Dynamic_dispatch
動的ディスパッチはしばしばパフォーマンスの低下をもたらすと言われますが、その最大の理由は、
選択される各関数ポインタを一度メモリから(vtableから)読み出し、それをcallする必要があることです
動的ディスパッチをどう定義するかはさておき、vtableが無い>>789ではこのパフォーマンス低下の懸念が無いことが分かります
また、「実行時にデータ内容に応じて分岐することを動的ディスパッチと言う」という定義には明らかな問題があります
それは、この定義ではmatchやifなど通常の制御構造も動的ディスパッチに当てはまってしまうということです
これは、この定義が一般的な定義から大きく逸脱していることをよく象徴的に表わしています
少なくとも「データ内容」は「型」に置き換える必要があることが分かるでしょう
0796デフォルトの名無しさん
2023/03/30(木) 15:38:08.65ID:RiLc+pIfそれは動的ディスパッチだよ
C++のstd::visitはstd::variantのindex()の値で実行時に分岐してる
だから>>786のような実行時になるまで何が来るか不明な場合にも対応できる
0797デフォルトの名無しさん
2023/03/30(木) 15:39:00.20ID:PJ70lfxqinspectは、godboltでclangのexperimentalを遊べるようになってた
型に対しては、もうちょっとまだみたい、error: expected expression って言われた
ラムダみたいに、みんなが欲しがるものはそれでもわりと早いんだよね
一応入れとくか…みたいのは、いつまでたっても入らないｗ
ところで、godboltに、-Wlifetime ってのがみえたけど…これってもしかして
0798デフォルトの名無しさん
2023/03/30(木) 15:59:56.98ID:QNJ4BihPC++の仕様変更を許さない、とすれば秒速で終わる
0799デフォルトの名無しさん
2023/03/30(木) 16:08:41.30ID:7YA3tv0iいいえ、これは動的ディスパッチではありません
「実行時になるまで何が来るか不明な場合にも対応できる」ことは、それが動的ディスパッチであることの証明にはなりません
繰り返しになりますが、>>790の「実行時にデータ内容に応じて分岐することを動的ディスパッチと言う」という定義は、一般的な定義とはまったく異なります
>>790の定義を採用する限りにおいてはその推論は正しいですが、そのためにはまずこの定義の出典および正確性を確認する必要があります
0800デフォルトの名無しさん
2023/03/30(木) 16:15:52.14ID:tFh1pq1g文系の俺にはちんぷんかんぷん。
雑魚はPHPでもしてるわ。
0801デフォルトの名無しさん
2023/03/30(木) 16:26:34.28ID:8gDdaVz7「dyn」という予約語キーワードが出てきたものだけがvtableを使う動的ディスパッチとなるよ
>>772のRustコードは「dyn」が全く出てこないので、vtableを使う動的ディスパッチは一切無し、とわかる仕組み
0802デフォルトの名無しさん
2023/03/30(木) 16:30:55.38ID:MJaavB8Rレベル高すぎてディスパッチが動的かどうかすらわからないからなwww
0803デフォルトの名無しさん
2023/03/30(木) 16:39:07.20ID:PJ70lfxq0804デフォルトの名無しさん
2023/03/30(木) 17:58:32.57ID:/NM1S7efここは「朝から暇なおじさんの学習日記」だからある意味レベル高い。
0805デフォルトの名無しさん
2023/03/30(木) 17:59:31.96ID:7YA3tv0iC++では動的ディスパッチが発生する条件のひとつとして、「virtual指定子付きメンバ関数の呼び出しである」という条件があります
>>781のコードにはvirtualがまったく存在しないため、動的ディスパッチが発生しないことが分かります
>>789のようにアセンブリでvtableの生成を確認するよりも、こちらのほうがより簡単な確認方法でした
誤った情報をお伝えしてしまい、大変申し訳ございませんでした
0806デフォルトの名無しさん
2023/03/30(木) 18:59:14.51ID:7YA3tv0iそうだよな、ないわけないよな
https://github.com/BowenFu/matchit.cpp
0807デフォルトの名無しさん
2023/03/30(木) 19:20:59.17ID:DvxUCrw+アホか？
静的ディスパッチとはコンパイル時に呼び出す関数が決定されることだよ
match使ったら動的ディスパッチ
0808デフォルトの名無しさん
2023/03/30(木) 20:49:12.26ID:jpK8yCqoRustのenumのmatchはenumのインデックスで分岐してるだけ
C++のvariantのvisitがvariantのインデックスで分岐してるだけなのと同じ
どちらも動的ディスパッチはしていない
0809デフォルトの名無しさん
2023/03/30(木) 20:53:37.26ID:wHEiYRW7実行時ディスパッチと言った方が意味分かるかな?
0810デフォルトの名無しさん
2023/03/30(木) 20:55:04.82ID:wHEiYRW7インデックスによる条件分岐
仮想関数によるディスパッチを含む広い概念です
0811デフォルトの名無しさん
2023/03/30(木) 20:57:43.19ID:wHEiYRW7コンパイル段階でどの関数が呼ばれるかディスパッチされる
これが静的ディスパッチ（の1つ）
0812デフォルトの名無しさん
2023/03/30(木) 21:00:36.55ID:jpK8yCqo嘘つき
条件分岐つまりif文があれば動的ディスパッチだと主張するのか？
全てのプログラムが動的ディスパッチをしていることになるぞ
0813デフォルトの名無しさん
2023/03/30(木) 21:07:23.31ID:wHEiYRW7>条件分岐つまりif文があれば動的ディスパッチだと主張するのか？
その通り if文でどの関数を呼ぶか決めてるのであれば
それは動的ディスパッチと言う
0814デフォルトの名無しさん
2023/03/30(木) 21:29:24.91ID:c1ax4GEO> Rustのenumのmatchはenumのインデックスで分岐してるだけ
> C++のvariantのvisitがvariantのインデックスで分岐してるだけなのと同じ
> どちらも動的ディスパッチはしていない
0815デフォルトの名無しさん
2023/03/30(木) 21:42:01.94ID:wHEiYRW7>>772
>fn enum_pattern(shape: Shape) {
> match shape {
> Shape::Circle(r) => println!("半径{r}の円です"),
> Shape::Rectangle(w, h) if w == h => println!("長さ{w}の正方形です"),
> Shape::Rectangle(w, h) => println!("幅{w}高さ{h}の長方形です"),
> x => println!("その他の図形{x:?}です"),
> }
>}
ShapeがCircleなのかw == hであるRectangle(w, h)なのかそれ以外のRectangleなのか
それともそれらに該当しないのかは実行時に決めているので
動的ディスパッチだよ
0816デフォルトの名無しさん
2023/03/30(木) 21:45:16.53ID:wHEiYRW7>>785
>namespace Shape {
> struct Circle {uint32_t r;};
> struct Rectangle {uint32_t w; uint32_t h;};
> struct Parallelogram {uint32_t ui0; uint32_t ui1;};
> template <typename T> void function (ostream &os, const T &p) {}
> void function (ostream &os, const Circle &p) {}
> void function (ostream &os, const Rectangle &p) {}
>}
上記のどのfunctionが呼ばれるかは型に基づいてコンパイル時に選択される
これが静的ディスパッチ
0817デフォルトの名無しさん
2023/03/30(木) 21:53:29.79ID:5+VTvxRFvtableは無いしstd::visitでvariantのindex()値を見て実行時に分岐してるだけだから静的ディスパッチだと書かれているけど
0818デフォルトの名無しさん
2023/03/30(木) 21:54:22.26ID:BpzIAh0Kそれにあほなレスつけて食って掛かってるほうはIDコロコロなんで
草も生えない毎度毎度のいつもの百年前から一生やってるrustスレ名物展開
0819デフォルトの名無しさん
2023/03/30(木) 21:57:54.63ID:wHEiYRW7Shapeが何かによって決めてるのは実行時なので
動的ディスパッチだよ
0820デフォルトの名無しさん
2023/03/30(木) 21:58:56.34ID:nbxN6jLHID:7YA3tv0i氏の>>795の説明を読もうぜ
0821デフォルトの名無しさん
2023/03/30(木) 22:04:55.93ID:k5ePvr4kvariantまで動的ディスパッチ扱いにするのはおかしいよ
virtual関数をvtable経由で呼ぶのが動的ディスパッチじゃないかな
0822デフォルトの名無しさん
2023/03/30(木) 22:06:13.90ID:wHEiYRW7>また、「実行時にデータ内容に応じて分岐することを動的ディスパッチと言う」という定義には明らかな問題があります
>それは、この定義ではmatchやifなど通常の制御構造も動的ディスパッチに当てはまってしまうということです
何だそりゃ?w この説明の方が明らかにおかしい
0823デフォルトの名無しさん
2023/03/30(木) 22:08:44.12ID:7YA3tv0i0824デフォルトの名無しさん
2023/03/30(木) 22:09:30.46ID:wHEiYRW7variantは良く知らんがShapeが実際には
CircleかRectangleかParallelogramかを
実行時に判断しているので動的ディスパッチだよ
>>816との差は分かるでしょ? 分からんか?
0825デフォルトの名無しさん
2023/03/30(木) 22:11:02.64ID:8gDdaVz7それはif文を使ったら動的ディスパッチと言ってるようなもの
0826デフォルトの名無しさん
2023/03/30(木) 22:11:20.94ID:PJ70lfxqどっちが来てもおっけーなようにtemplate<>が書けるのがC++のOOPだろ
無駄な議論 Rustもそんな感じだろ?ｗ
0827デフォルトの名無しさん
2023/03/30(木) 22:12:32.19ID:PJ70lfxq0828デフォルトの名無しさん
2023/03/30(木) 22:17:03.62ID:PQ2EGsE8コンパイル後のenum_patternにCircleでもRectangleでもRectangleでもなく
HogeAngleぶち込んでもディスパッチしてくれるのが動的じゃないの？
0829デフォルトの名無しさん
2023/03/30(木) 22:18:51.34ID:wHEiYRW7>それはif文を使ったら動的ディスパッチと言ってるようなもの
>>772はShapeが何かはコンパイル時には決まりません
>>789もShapeが何かはコンパイル時には決まりません
matchやifを使うということは実行時に決めていることを意味しているので動的ディスパッチです
templateを駆使してコンパイル時に決定できる条件分岐を書けば
静的ディスパッチできるかもしれません
0830デフォルトの名無しさん
2023/03/30(木) 22:20:12.37ID:BpzIAh0Kディスパッチディスパッチ言ってんのは関数だけを前提にしたほうがいいんじゃない？
match についてはもとの？ディスパッチ話から分離させたほうがいいかも？
それとも元々matchの話なんだっけ？ 最初の方読んでないけど
今まで関数かメソッド以外の文脈でディスパッチとか聞いたことなかったわ個人的に
0831デフォルトの名無しさん
2023/03/30(木) 22:22:08.75ID:PJ70lfxqそこを雑に書くと、ぶん殴られたりするからｗ
だから、Rustの、書けばsafeになるってのは、欲しいんだなあ
生成コードに集中できる
0832デフォルトの名無しさん
2023/03/30(木) 22:23:47.54ID:7lKP8BwD>> https://www.weblio.jp/content/%E5%8B%95%E7%9A%84%E3%83%87%E3%82%A3%E3%82%B9%E3%83%91%E3%83%83%E3%83%81%E3%81%AE%E4%BE%8B
>> C++では以下のように仮想関数を派生クラスにてオーバーライドすることで、
>> 実際に呼び出される関数の実体をオブジェクトの型に応じて実行時に選択することができる。
>> これを動的ディスパッチと呼ぶ。
この定義だとC++のvariant/visitでの分岐やRustのenum/matchでの分岐は動的ディスパッチではないな
一方でC++のvirtual関数やRustのdynトレイトは動的ディスパッチとなる
0833デフォルトの名無しさん
2023/03/30(木) 22:27:18.66ID:wHEiYRW7>> https://www.weblio.jp/content/%E5%8B%95%E7%9A%84%E3%83%87%E3%82%A3%E3%82%B9%E3%83%91%E3%83%83%E3%83%81%E3%81%AE%E4%BE%8B
>> C++では以下のように仮想関数を派生クラスにてオーバーライドすることで、
>> 実際に呼び出される関数の実体をオブジェクトの型に応じて実行時に選択することができる。
>> これを動的ディスパッチと呼ぶ。
これは動的ディスパッチの1つで
実行時に条件分岐して呼ぶ関数を決めるのも動的ディスパッチと呼ぶ
仮想関数によるディスパッチより動的ディスパッチの方が広い概念だよ
0834デフォルトの名無しさん
2023/03/30(木) 22:39:32.69ID:Zoz9Js1jRustで日常茶飯事のこのパターンは動的ディスパッチですか？
let output = match input {
Some(input) => foo(input),
None => Default::default(),
};
0835デフォルトの名無しさん
2023/03/30(木) 22:47:00.93ID:PJ70lfxq0836デフォルトの名無しさん
2023/03/30(木) 22:56:12.40ID:7YA3tv0i何があれば「実践的」と言えるかの条件と、そもそも何のサンプルが欲しいのか、を明確にしないと誰も何も出せないよ
0837デフォルトの名無しさん
2023/03/30(木) 22:56:26.39ID:8gDdaVz70838デフォルトの名無しさん
2023/03/30(木) 22:58:11.58ID:8gDdaVz7それも動的ディスパッチじゃない
>>833が主張する『実行時に条件分岐して呼ぶ関数を決めるのも動的ディスパッチと呼ぶ』は無理があるんだよ
0839デフォルトの名無しさん
2023/03/30(木) 23:11:54.75ID:wHEiYRW7俺はRust分からんのだけど
これinputがSome(input)に適合するかしないかを
実行時に判断しているんやろ? だとしたら動的ディスパッチだよ
C++のtemplateみたいに上記をコンパイル時に判断して
例えばSome(input)に適合するからDefault::default()を
コールするコードが生成されないようなら静的ディスパッチ
0840デフォルトの名無しさん
2023/03/30(木) 23:16:28.37ID:PJ70lfxqいま話題にしてる もとになった、パタンマッチングを上手く使ってる実例
なるほどこれはパタンマッチングがあってこそ、キマってるねっていうか
0841デフォルトの名無しさん
2023/03/30(木) 23:17:10.18ID:7YA3tv0ihttps://en.wikipedia.org/wiki/Static_dispatch
Rustならtrait bound付きgenerics内のtrait method呼び出しのことで良さそうだけど
C++なら……ちょっとこのwikipediaの定義もなぜかオーバーロードに限定しててビミョ〜
これはRust以外の文脈では合意された定義無い気がする
0842デフォルトの名無しさん
2023/03/30(木) 23:21:08.11ID:BpzIAh0Kでも「ディスパッチ」って言うとき
言語機能として用意されてる関数オーバーロードやvirtual使ったポリモとか
動的静的に関わらずまぁそこまではディスパッチなんだけど
matchの結果やifの結果となってくるとそれって
言語の機能というより、言語の機能の機能ってことになってて
一気にぼんや〜りとしてくるんで一人一人にズレが生じるよね
0843デフォルトの名無しさん
2023/03/30(木) 23:21:22.01ID:PQ2EGsE8２．どの振る舞いをするかが動的に選択される構造
３．振る舞いが追加されても動的に選択できる構造
パターンマッチは振る舞いの選択の話だから２
ポリモーフィズムを語る上での動的ディスパッチは３
２を動的ディスパッチと呼ぶかどうか
0844デフォルトの名無しさん
2023/03/30(木) 23:22:10.90ID:Zoz9Js1j実行時にならないとSomeかNoneかわからないからプログラムを組むんですよ
コンパイル時点で決まっていたらプログラムを組む意味がありません
そしてプログラムを組めば必ずどこかに条件分岐があります
それを動的ディスパッチとは言わないと思うんです
0845デフォルトの名無しさん
2023/03/30(木) 23:23:46.15ID:7YA3tv0iC++？Rust？どっち？
てかやっぱり基準が曖昧だけど、何かしら有名OSSのソースでも出せばいいの？
0846デフォルトの名無しさん
2023/03/30(木) 23:23:58.24ID:wHEiYRW7>This contrasts with dynamic dispatch, which is based on runtime information
> (such as vtable pointers and other forms of run time type information).
そこにdynamic dispatchを説明する一文があって2行目()内の
and以下に書かれているのがまさにifやmatchで評価していること
0847デフォルトの名無しさん
2023/03/30(木) 23:27:47.63ID:BpzIAh0K明らかにそいつは周回遅れのド素人なので
アナタ以外のみんなは単に無視してるようですよｗ
時間の無駄はおすすめしません
0848デフォルトの名無しさん
2023/03/30(木) 23:29:52.13ID:Zoz9Js1jtype informationとありますね
SomeもNoneも型ではありませんから
>>834は動的ディスパッチではないということになります
Rustのenumによるmatchでの分岐は動的ディスパッチではないということでよろしいでしょうか？
0849デフォルトの名無しさん
2023/03/30(木) 23:30:14.28ID:PJ70lfxqRustのOSSで
>>847
よく言われるよ
0850デフォルトの名無しさん
2023/03/30(木) 23:31:40.58ID:wHEiYRW7条件により振る舞いを変えること一般をディスパッチと呼ぶ
例えば>>785でmain内でfunction (cout, circle);とfunction (cout, parallelogram);では
呼ばれる関数が変わり振る舞いが変わるんだけど
これはコンパイル時に選択されます
これを静的ディスパッチと呼びます
一方で834のmatchによる分岐は静的には決まらないので
静的ディスパッチに対して動的ディスパッチと呼びます
0851デフォルトの名無しさん
2023/03/30(木) 23:33:00.14ID:7YA3tv0iそれはjsとかRubyとかPythonではvtableじゃなくてハッシュテーブルを使ってメソッド呼び出ししてるって意味ですよ
0852デフォルトの名無しさん
2023/03/30(木) 23:36:51.72ID:wHEiYRW7それは字面に囚われていて本旨を捉えていないと思うよ
例えば憲法第二十四条第一項は「婚姻は、両性の合意のみに基いて成立し」を
根拠にして同性婚は憲法違反と主張するようなもの
0853デフォルトの名無しさん
2023/03/30(木) 23:39:51.85ID:Zoz9Js1j示してくださった定義>>846には
ランタイム型情報に基づく場合が動的ディスパッチですよね
しかしSomeもNoneも静的に決まっているenum Option型の中の話ですからランタイム型情報は使っていません
したがってenumのmatchは動的ディスパッチに該当する要素が全くないため、動的ディスパッチではありません、という結論になります
0854デフォルトの名無しさん
2023/03/30(木) 23:42:50.15ID:7YA3tv0irust-lang/rustのありそうなところからテキトーに拾ったけどこれとかどうすかね
https://github.com/rust-lang/rust/blob/master/compiler/rustc_ast/src/visit.rs#L302
0855デフォルトの名無しさん
2023/03/30(木) 23:46:30.65ID:PJ70lfxqこれだったら、yylvalでいいよね。。
もうちょっとない?
0856デフォルトの名無しさん
2023/03/30(木) 23:46:56.95ID:wHEiYRW7コンパイル時にその後の振る舞いが決まるかどうかに興味があって
それを動的か静的かと呼んで議論しているんじゃないのかな?
0857デフォルトの名無しさん
2023/03/30(木) 23:49:02.99ID:7YA3tv0iこれパーサじゃないです……yylvalでよくないです……
イチャモン付けたいだけならもう返しません……
0858デフォルトの名無しさん
2023/03/30(木) 23:49:55.47ID:8gDdaVz7静的ディスパッチ ← 静的に型情報が決まる場合にコンパイル時に呼び出しメソッドが確定すること
動的ディスパッチ ← 動的に型情報が決まる場合に実行時に呼び出しメソッドが確定すること
Rustのmatch文でのenumの分岐は静的に型情報は確定しているけど呼び出しメソッドを決めるわけではないので静的ディスパッチではない
Rustのmatch文でのenumの分岐は静的に型情報は確定しているため動的に型情報が決まる動的ディスパッチとは無縁
つまりRustのmatch文でのenumの分岐はどちらのディスパッチでもなく一つの型の中の値による条件分岐にすぎない
0859デフォルトの名無しさん
2023/03/31(金) 00:03:18.59ID:EUO40WZ7型情報による条件分岐に限らず値による条件分岐も動的ディスパッチだよ
なぜならC++の場合typeid演算子で取ったtypeinfoオブジェクトで条件分岐したら
それは型情報なのか値なのか?両者に差はないから
0860デフォルトの名無しさん
2023/03/31(金) 00:05:54.81ID:EUO40WZ7-両者に差はないから
+両者を分ける意味はないから
0861デフォルトの名無しさん
2023/03/31(金) 00:10:50.53ID:yzNtfP1nこの場合のディスパッチとは型情報に基づいて呼び出しメソッドを決定すること
それが静的に決まれば静的ディスパッチ
そして動的に決まれば動的ディスパッチ
型情報に基づかなければ単なる昔からの条件分岐プログラム
typeidで得られるのは型情報なのでtypeidに基づくならば動的ディスパッチに該当する
0862デフォルトの名無しさん
2023/03/31(金) 00:12:47.70ID:4rLmkYuJディスパッチは条件分岐を用いずに振る舞いを切り替えること
0863デフォルトの名無しさん
2023/03/31(金) 00:14:06.22ID:EUO40WZ7typeinfoの実装見てみ
環境違ってもそんなに変わらんと思うから
0864デフォルトの名無しさん
2023/03/31(金) 00:15:58.98ID:EUO40WZ7いや条件分岐ってディスパッチやろ
0865デフォルトの名無しさん
2023/03/31(金) 00:18:07.60ID:4rLmkYuJちゃうやろ
比較で分岐するか
次の振る舞いがあるところに飛ぶか
0866デフォルトの名無しさん
2023/03/31(金) 00:20:19.18ID:RaXhcLNj0867デフォルトの名無しさん
2023/03/31(金) 00:21:06.03ID:EUO40WZ70868デフォルトの名無しさん
2023/03/31(金) 00:22:01.37ID:E+GQTsPO型情報を整数値で表すのは当たり前だけど
それは型情報ではない普通のデータの整数値の分岐とは話が全く違う
型情報によって呼び出すメソッドが変わるからそれを決定することをディスパッチと呼ぶ
その型情報が静的に決まるか動的にきまるかの違いのみ
typeidを使っているならば型情報が動的に決まっているのだから動的ディスパッチ
0869デフォルトの名無しさん
2023/03/31(金) 00:23:24.62ID:XMbQ83Rxそもそもそれをディスパッチと普通呼ぶ？
やってることはvtable使った動的ディスパッチも似たようなものだから
動的ディスパッチの一種とすることにそこまで違和感はないけど
広く浸透してる定義ではないよね
0870デフォルトの名無しさん
2023/03/31(金) 00:24:13.24ID:EUO40WZ7実行時に比較のオーバヘッドがある認識は共通しているので
何も対立はないはず
C++のmatchの話にもどしましょ
0871デフォルトの名無しさん
2023/03/31(金) 00:26:02.54ID:EUO40WZ7>型情報を整数値で表すのは当たり前だけど
>それは型情報ではない普通のデータの整数値の分岐とは話が全く違う
わかんねーよw もういいよ
0872デフォルトの名無しさん
2023/03/31(金) 00:33:40.04ID:RaXhcLNjこりゃすでにdynamic dispatchが定義された前提の上で、static dispatchと異なる点を書いているだけだよ
自分の思い込みを肯定するために都合良く文章を解釈してしまうのは人間やりがちだけどね
0873デフォルトの名無しさん
2023/03/31(金) 00:34:12.53ID:4rLmkYuJディスパッチは条件により分岐しない
渡された振る舞いを実行するだけ
例えば>>841のサイトのspeakに分岐処理は無いでしょ
0874デフォルトの名無しさん
2023/03/31(金) 00:34:43.78ID:E+GQTsPOまず前提「オーバーロードにより型が決まらないと呼び出す実メソッドが決まらない」
つまり「型情報が決まると呼び出すメソッドが決まる」
この決定のことをディスパッチと呼ぶ
静的に型情報が決まる場合は静的ディスパッチが可能
動的に型情報が決まる場合は動的ディスパッチとなる
型情報と関係ない話はどちらでもない
0875デフォルトの名無しさん
2023/03/31(金) 00:40:10.18ID:RaXhcLNj> まず前提「オーバーロードにより型が決まらないと呼び出す実メソッドが決まらない」
> つまり「型情報が決まると呼び出すメソッドが決まる」
> この決定のことをディスパッチと呼ぶ
ここだけ読むとオーバーロード解決に聞こえるねｗ
https://ja.cppreference.com/w/cpp/language/overload_resolution
0876デフォルトの名無しさん
2023/03/31(金) 01:54:38.14ID:EgdFd66u複数のメンバー関数から一つ選ぶのもディスパッチ
だから多重という
0877デフォルトの名無しさん
2023/03/31(金) 03:36:49.58ID:jnb+4hS9何をディスパッチするのか考えなよ
0878デフォルトの名無しさん
2023/03/31(金) 07:31:14.10ID:8I8WcMJF実行時にしか型が判明しない場合に対してはdyn指定による動的ディスパッチが可能でvtableが使われる
vtableを避けたいならばenumに包むことで直和型として収容して扱うこともできる
0879デフォルトの名無しさん
2023/03/31(金) 09:01:13.01ID:RaXhcLNjC++でも同じだよ
0880デフォルトの名無しさん
2023/03/31(金) 10:05:33.29ID:TtdiO46p0881デフォルトの名無しさん
2023/03/31(金) 10:09:37.79ID:BBtS0ztFSpringやFluxのディスパッチャーだったり
Grand Central Dispatchだったり
何に対しても使える用語だから
区別できてない人もいるんだろう
0882デフォルトの名無しさん
2023/03/31(金) 11:47:51.48ID:3PkVSivi仮想関数テーブルには、仮想関数へのポインタが含まれインスタンスに対して仮想関数が呼び出されるたびに
vtableを参照して適切な関数が呼び出される。
Rustでは動的ディスパッチを実現するためにトレイトオブジェクトが使用される。
トレイトオブジェクトには、traitオブジェクトが実装する各メソッドに対応するポインタのリストが含まれていて
インスタンスに対してメソッドが呼び出されるたびに、トレイトオブジェクトが参照され
適切なポインタが見つかるまでリストを検索し適切な関数が呼び出される。
結果は同じ。
0883デフォルトの名無しさん
2023/03/31(金) 12:51:42.96ID:RaXhcLNj詳細の説明がいろいろおかしいと思うけどどこソースなの？
0884デフォルトの名無しさん
2023/03/31(金) 18:30:12.19ID:fT81IvHH『複オジ妄想虚言録』
0885デフォルトの名無しさん
2023/03/31(金) 18:44:18.60ID:KJ4yMLmSクラスとインスタンスの関係を理解してないな
C++の説明もRustの説明も同じように間違ってる
おまえオブジェクト指向を理解してなさそうと言われてたやつだろ
0886デフォルトの名無しさん
2023/03/31(金) 18:50:12.77ID:Q5ExbgOuうーむひどいな
とりあえずRustについて、この部分の間違いはあまりにひどい
＞ traitオブジェクトが実装する各メソッドに対応するポインタのリストが含まれていて
＞ 適切なポインタが見つかるまでリストを検索し適切な関数が呼び出される。
Rustは常にメソッドが静的に一意に確定するため、動的ディスパッチでも適切なポインタが見つかるまでリストを検索する必要がない
Rustはメソッド名が衝突する場合、まず自分の定義優先で確定、なくてトレイト間に衝突がなければ確定、衝突があればエラーだが、トレイト名を指定することでどのトレイトのメソッドでも常に利用可能
つまりRustではメソッド呼び出しが自分のメソッドかどのトレイトのメソッドかが静的に一意に確定する
静的ポリモーフィズムとして使われるときは、必要とする最小限のトレイトを列挙(＝トレイト境界)するため、メソッドの衝突の可能性は通常時よりも減ったり無くなったりする
いずれにせよ上述したようにメソッドは静的に一意に定まるため、静的ディスパッチでは単相化(モノモーフィゼーション)されてコンパイルされる
動的ポリモーフィズムとして使われるときは、現在の仕様では指定できるトレイトは(auto traitを除き)一つのみに限定されている
ただし必要とするトレイトを列挙(＝トレイト境界)したダミーなトレイトを任意に作ることも可能なため、事実上は複数のトレイトを指定できるのと同じ
指定トレイトが一つに限定されているということは、(そのトレイト境界を含めた)トレイト群すべてのメソッドを静的に一斉に把握できることを意味する
つまりRustのvtableはその指定トレイト一つのみに定まり、その親や祖先のvtableを辿る必要がなく、呼び出すメソッドは静的に確定してインデックス値となっているため、動的ディスパッチでも高速にメソッドを呼び出せる
0887デフォルトの名無しさん
2023/03/31(金) 18:59:29.64ID:Q5ExbgOuそれに対して間違ってる！とか、虚言！とかだけ言う連中は全く役に立たないから無視してよい
なぜなら、正しいことが書かれている場合でも、間違ってる！とか適当なこと言ったりするだけの連中も多いため
0888デフォルトの名無しさん
2023/03/31(金) 19:02:37.99ID:RaXhcLNj> つまりRustのvtableはその指定トレイト一つのみに定まり、その親や祖先のvtableを辿る必要がなく
C++も同じです
> 動的ディスパッチでも高速にメソッドを呼び出せる
何と比較して？静的に比べりゃどうやったって遅いしそこにC++との差はないはずだし
不合格
>>887
テキトーかどうかの検証のために、出典を貼っていただけるとみんなが助かります
やるつもりが無いなら頃合いを見てマサカリを投げさせていただきます
0889デフォルトの名無しさん
2023/03/31(金) 19:13:25.65ID:Q5ExbgOuそういう意味のない言いがかりはやめとけ
元の>>882が正しくないこと「適切なポインタが見つかるまでリストを検索」と書いているので、
それに対して正しいこと「親や祖先のvtableを辿る必要がなく、動的ディスパッチでも高速にメソッドを呼び出せる」と書いた
そこで「静的に比べりゃどうやったって遅い」と頓珍漢なことを言い出すのは理解力のない証拠
これ以上は相手にしない
0890デフォルトの名無しさん
2023/03/31(金) 19:25:39.32ID:Wg79uBjggdgd なんだが
0891デフォルトの名無しさん
2023/03/31(金) 19:29:08.86ID:RaXhcLNjhttps://mevius.5ch.net/test/read.cgi/tech/1677286186/756
https://mevius.5ch.net/test/read.cgi/tech/1677286186/786
つまんね〜の、もっとC++の話しようぜ複おじ
また名言バンバン出してくれよ
0892デフォルトの名無しさん
2023/03/31(金) 19:30:39.96ID:RaXhcLNjhttps://mevius.5ch.net/test/read.cgi/tech/1677286186/765
0893デフォルトの名無しさん
2023/03/31(金) 19:38:42.25ID:Wg79uBjgもしかして
遅延バインディング
0894デフォルトの名無しさん
2023/03/31(金) 19:40:08.33ID:7j0Yg6pd0895デフォルトの名無しさん
2023/03/31(金) 19:59:22.01ID:RaXhcLNj具体的にどういうリストなのかの説明は一切無し
なのになぜか>>886は「親や祖先のvtableを辿る」と、親子関係でリストができる？のを何故か仮定している
そういうことだよねｗ
0896デフォルトの名無しさん
2023/03/31(金) 20:11:31.44ID:EgdFd66u「最初から間違ってると思ってた」と事後に言うと、本当に最初からだったのかが真偽不明になるから
内容がなくても時刻を記録するだけで意味があるんだよ
0897デフォルトの名無しさん
2023/03/31(金) 20:19:56.47ID:f9v7p1HY特にJavaScriptはメソッドを後から生やせるから大変だった
0898デフォルトの名無しさん
2023/03/31(金) 20:24:26.37ID:JGH7phMuとりあえず、プライドは高いということは分かった
0899デフォルトの名無しさん
2023/03/31(金) 21:01:50.63ID:J9Ac7zVbどう見ても君が間違ってる本人じゃん
なぜバレないと思ったの？
0900デフォルトの名無しさん
2023/03/31(金) 21:50:12.55ID:RJ6Se/g42. 間違いを指摘されるとググって必死に正解を探す
3. そしてそんなことは最初から知ってましたというトーンで長文まとめスレを他人のフリして書く
これが複オジメソッド
0901デフォルトの名無しさん
2023/03/31(金) 22:09:18.69ID:RaXhcLNjそして話の内容がC++になると複おじにはちんぷんかんぷんなので
調べても間に合わないし、無限に別の間違いを生み出し続けてしまうというw
0902デフォルトの名無しさん
2023/03/31(金) 22:18:57.16ID:Q5ExbgOu俺が間違ってるって？？
>>886に間違ってるところがあるなら指摘してくれ
0903デフォルトの名無しさん
2023/03/31(金) 22:43:55.74ID:e2Ah0StU4. 他人のふりして書いた長文まとめも間違っている
というオチ付き
0904デフォルトの名無しさん
2023/03/31(金) 22:50:43.27ID:RaXhcLNjその「間違ってる本人」は>>882のことを指していて、間違いがあるのは>>886のことではないと思うが
それはそれとして>>886の間違いを指摘しておくと
あなたC++で「どのvtableを見るべきか」を実行時にしか判断できないケースがあると思ってない？ 嘘だよそれ
じゃないと「メソッドの衝突の可能性」なんて話が出てくる理由が無いと思うんだよね
そんなもんは静的に解決されて当然なのだから
ていうかね、参考にしたリンク貼ってくださいよって何回も言ってるでしょう
そのほうがあなたが（もしかすると私が）何を勘違いしているのかという答えにたどり着きやすいですって
いちいちあなたも長文で解説しなくて済むんですよ
0905デフォルトの名無しさん
2023/03/31(金) 23:03:06.56ID:Q5ExbgOu間違いがないのに間違いだと言い張る悪い癖はやめたほうがいいよ
冒頭に「Rustについて」と明記していてC++について一切記述していない
もしRustについて記述した>>886に間違いがあると主張するなら指摘してください
> 参考にしたリンク貼ってくださいよ
参考はRust公式ドキュメントとコードのみ
他の解説サイトがあるかどうか調べたこともないので知らない
0906デフォルトの名無しさん
2023/03/31(金) 23:13:20.94ID:oRUGNWak間違いがあるとタダで教えてくれるだけでも相当にありがたいことだと認識すべきだぞ
どこがどう間違えてるかをタダで懇切丁寧に教えてもらえると考えるのは甘えでしかない
0907デフォルトの名無しさん
2023/03/31(金) 23:15:00.18ID:RaXhcLNjなるほどね？
例えば「検索する必要がない」「メソッドの衝突の可能性は通常時よりも減ったり無くなったりする」は対比的にそれらが「ある」存在に暗に言及しているのだと思ったよ
行間を読んで根本的に何を勘違いしているのか探ろうと思ったが、これはあくまでRustに関する言及でしかないと
「高速」も何と比較してなのか不明で虚しい響きがあるが、高速だというならそうなんだろう
じゃあ私から言えるのはこれだけです
> Rustは常にメソッドが静的に一意に確定する
じゃあRustに動的ディスパッチなんて実装する必要無いじゃん
dyn存在意義無いじゃん
「『トレイトとメソッド名のペア』が一意に確定する」ならそう書かないと、この文脈でこの表現は語弊しか無いよ
0908デフォルトの名無しさん
2023/03/31(金) 23:19:08.47ID:EgdFd66u知らんけど
真似してくれれば人間皆どっちもどっちだと実証されるかも知れないから
0909デフォルトの名無しさん
2023/03/31(金) 23:22:31.74ID:tr7cKY8h発散させあってたらきりがないんよ
余計なことは省くこと
余計じゃないものが複数あってもより大事なほうを一つ選んで議論を続行すること
0910デフォルトの名無しさん
2023/03/31(金) 23:22:49.85ID:hy3TCCAcメソッド名が衝突した時にどうなるか？どう対応できるか？は
各言語によって異なるから
その説明があるのは普通じゃないか
alias付ける必要があったりなど十人十色
0911デフォルトの名無しさん
2023/03/31(金) 23:28:00.63ID:JG8RdAc0Rustは動的ディスパッチを使う場合は必ずポインタ経由になるので構造体のデータを読むのに間接参照が1回必ず入る
これが持ち方の違いによって出る差の一つ
0912デフォルトの名無しさん
2023/03/31(金) 23:50:08.60ID:FlP4pMOXでもまあ気にするようなオーバーヘッドじゃないよね
0913デフォルトの名無しさん
2023/03/31(金) 23:51:44.88ID:Q5ExbgOu後半の指摘については、短い中で詳細まで説明できていないから誤解を与えてしまったもしれないので、そこはすまん
しかしその指摘だとまだ別の誤解されてそうだからその部分についてだけ一応書いておくと
ある型Fooのメソッドmethodの各呼び出しがそれぞれ異なっていてもよくて
Foo::method() なのか
<Foo as Trait1>::method() なのか
<Foo as Trait2>::method() なのかが決まり
Foo::method()がなくてそれ以外が複数で曖昧な時はエラーになるというだけの話
いろんな言語があるからね
0914デフォルトの名無しさん
2023/03/31(金) 23:57:35.53ID:RaXhcLNj具体型Fooが確定している状態で動的ディスパッチは絶対に発生しません
dynと目印のついたトレイトオブジェクト経由でしか動的ディスパッチは発生しません
そしてこのときトレイトは確定しているのでメソッド名は衝突しません
だからメソッド名の衝突の話が出てくる意味が分からないと言っているんです
0915デフォルトの名無しさん
2023/03/31(金) 23:57:58.72ID:cX1DOwsp多重継承の場合はどうなるの？
そこが焦点な気がしてきた
0916デフォルトの名無しさん
2023/03/31(金) 23:59:30.92ID:Q5ExbgOuちゃんと>>886を読みなよ
動的ディスパッチの話は最後の段落にしか書いていない
0917デフォルトの名無しさん
2023/04/01(土) 00:04:38.33ID:AdU+jSWJそれはRustの基本が理解できていない
トレイトオブジェクトでも当然メソッド名は衝突しうる
なぜ衝突するのかも>>886に書いてあるな
0918デフォルトの名無しさん
2023/04/01(土) 00:04:51.67ID:XaCtro1Rそのメソッドは迷惑行為なので
間違いを信じそうな人がいる時だけ
レス内容が間違ってることのみを指摘するのが吉
0919デフォルトの名無しさん
2023/04/01(土) 00:09:36.60ID:+ti2a57c指摘できないけど誰か論破してくれねーかなっていう情けない感じ
0920デフォルトの名無しさん
2023/04/01(土) 00:09:53.12ID:YJwv5+ODボロボロですよ
トレイト境界を勉強しましょうね
0921デフォルトの名無しさん
2023/04/01(土) 00:12:20.97ID:ktHgE8AY>>882が「Rustでは動的ディスパッチを実現するために〜〜」という文脈だったから最初からその範囲の訂正しか書いてないんだと思ったよ
脈絡もなく余計な文章を足すとそれがどういう意図でそこにあるのか理解してもらえないから気をつけようね
>>917
ああ厳密にはそうだね、私が間違っておりました
動的ディスパッチには関係ない文脈で書いた文章だって聞いたんでそこはもうどうでもいいです
0922デフォルトの名無しさん
2023/04/01(土) 00:13:02.49ID:+UQ+9Bf4全然焦点じゃないから気にすんな
0923デフォルトの名無しさん
2023/04/01(土) 00:19:53.47ID:78d0gX0oだよねー
>>886は>>882の間違いを指摘できてるわけでもなく何の意味もない
0924デフォルトの名無しさん
2023/04/01(土) 00:21:52.63ID:AdU+jSWJまだ理解できていないのか？
動的ディスパッチの時こそメソッド名の衝突に対しての処置が重要
そのためどのトレイトのメソッドを呼び出すかを静的に確定するとともに
各トレイトの同名メソッドを区別してvtableのインデックス化をしている
0925デフォルトの名無しさん
2023/04/01(土) 00:32:15.20ID:DyolynIp>各トレイトの同名メソッドを区別してvtableのインデックス化をしている
うそーん
ソースを提示してね
0926デフォルトの名無しさん
2023/04/01(土) 00:34:01.19ID:ktHgE8AY「各トレイトの同名メソッドを区別してvtableのインデックス化をしている」
ここを詳しく説明してくれますか？
必要なら次の例を使ってください（こういう状況のことでいいんですよね？）
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a72f5f361d0e82594bace55483e66c7c
0927デフォルトの名無しさん
2023/04/01(土) 00:35:46.81ID:YJwv5+ODインデックス区別しないと動的ディスパッチできないですよ
0928デフォルトの名無しさん
2023/04/01(土) 00:50:45.22ID:ktHgE8AY気になるなら直してていいよ
0929デフォルトの名無しさん
2023/04/01(土) 00:56:33.36ID:tiKbQym2バカだな
動的ディスパッチが行われるときは具体型Fooが確定しているぞ
具体型が確定しているからこそ動的ディスパッチを実行することができる
おまえC++もRustも両方を理解できてねーな
0930デフォルトの名無しさん
2023/04/01(土) 01:55:13.58ID:AdU+jSWJトレイトオブジェクトを扱うためにBoxは不要
ヒープを使うのは必要性があるときのみ
求められているのは俺が書いた「各トレイトの同名メソッドを区別してvtableのインデックス化をしている」の部分だろ
それを直接わかるコードを書いた
ただしvtableはpubではないので現状の仕様を強引にアクセス
インデックス値の順序も変わる可能性ありなので注意
macro_rules! vtable_base { ($dyn:expr) => { *(&$dyn as *const _ as *const usize).offset(1) as *const usize } }
macro_rules! vtable { ($dyn:expr, $index:expr) => { unsafe { *(vtable_base!($dyn).offset($index)) } } }
trait TraitA {
fn method(&self);
}
trait TraitB {
fn method(&self);
}
trait TraitAB: TraitA + TraitB {}
struct Foo;
impl TraitA for Foo { fn method(&self) {} }
impl TraitB for Foo { fn method(&self) {} }
impl TraitAB for Foo {}
fn main() {
let foo = Foo;
let dyn_foo: &dyn TraitAB = &foo;
assert_eq!(vtable![dyn_foo, 3], <Foo as TraitA>::method as usize);
assert_eq!(vtable![dyn_foo, 4], <Foo as TraitB>::method as usize);
}
というわけで動的ディスパッチでもメソッド名衝突の話は必要であり>>886の説明で合っている
0931デフォルトの名無しさん
2023/04/01(土) 03:08:57.82ID:TpFQVX+V単にvtableが作られることを「vtableをインデックス化してる」と言ってたのね
もう嫌だ
0932デフォルトの名無しさん
2023/04/01(土) 03:10:50.58ID:AdU+jSWJ助詞を間違えてるぞ
「各トレイトの同名メソッドを区別してvtableのインデックス化」な
0933デフォルトの名無しさん
2023/04/01(土) 03:16:00.87ID:TpFQVX+Vどっちでも間違ってる
インデックス化されるのはメソッド
vtableはメソッドがインデックス化されたデータ構造
0934デフォルトの名無しさん
2023/04/01(土) 03:30:04.06ID:AdU+jSWJだからそう書いてるだろ
文章も>>930のコードも読めないのか？
0935デフォルトの名無しさん
2023/04/01(土) 05:02:11.23ID:J25MoQ6T0936デフォルトの名無しさん
2023/04/01(土) 05:11:37.13ID:J25MoQ6T0937デフォルトの名無しさん
2023/04/01(土) 05:12:17.82ID:J25MoQ6T0938デフォルトの名無しさん
2023/04/01(土) 06:30:37.76ID:ol7Kdurc>>3を理解しろ
0939デフォルトの名無しさん
2023/04/01(土) 06:56:17.26ID:073QzAPeなんだかんだで実際は両方使うけど、やっぱ俺はこっち推すぜ! みたいなスレになりつつ
テンプレ用意すんの?
0940デフォルトの名無しさん
2023/04/01(土) 10:28:30.10ID:h8xyCGJ+書いてないじゃん
見苦しい嘘つくなよ
0941デフォルトの名無しさん
2023/04/01(土) 10:56:30.89ID:3pQ6SLTI0942デフォルトの名無しさん
2023/04/01(土) 11:11:44.89ID:IIYgmYPvassert通るのを確認した
0943デフォルトの名無しさん
2023/04/01(土) 12:25:26.51ID:ktHgE8AY言いたいことは理解した
でもね、そもそも「衝突」は定義だけで発生するものなんですよ
そのコードのmainの中でdyn_foo.method()と書くと発生するエラーは、「名前解決の失敗」と呼ばれます
そしてこの「衝突」の有り無しは、「vtableのインデックス化」に特に影響を与えません
現に片方だけメソッド名を変更しても、同じレイアウトになりますよね
内部的には別トレイトのメソッドなのだから、"method"部分が「衝突」するしないに関係なく区別されます
「衝突」に、vtableに関して特筆すべき重要性は無いと思います
0944デフォルトの名無しさん
2023/04/01(土) 12:47:01.18ID:km+jzk5nそれを何か特別なことのように変な長文書くからバカにされる
0945デフォルトの名無しさん
2023/04/01(土) 13:18:48.32ID:hxeslJ4Q#![allow(unused)]
... = hoge().unwrap;
... = hoge()?;
let p: *const [u8] = &fuga;
unsafe {}
0946デフォルトの名無しさん
2023/04/01(土) 13:25:38.29ID:hxeslJ4QchatGPT そのもののことだな
0947デフォルトの名無しさん
2023/04/01(土) 13:33:41.52ID:hxeslJ4Qみたけどイマイチ
0948デフォルトの名無しさん
2023/04/01(土) 13:35:01.01ID:hxeslJ4Qほんそれ
C++出来る人はC++使えば良い
C++出来ない人やC++でやらかすうっかりさんだけRust使えば良い
0949デフォルトの名無しさん
2023/04/01(土) 13:38:19.66ID:goAbMbb3なぜかRustに引き寄せられてる気がする
ニワカ人間を引きつける同じニオイがするんだろうなRustには
0950デフォルトの名無しさん
2023/04/01(土) 13:46:59.44ID:WHqiXdwW未だにModern C++ Designを初めて読んだときの衝撃を上回る
本には出会ったことがない
0951デフォルトの名無しさん
2023/04/01(土) 14:05:07.99ID:goAbMbb3職業マ「C++？ 糞の糞糞」
アマチュア「C++？ vtableのコスト（ｷｬｯｷｬ）
鼻から悪魔（ｳﾌﾌﾌ）膝を撃ち抜く（ｷｬｯｷｬ）CRTP（ｳﾌﾌ）
0952デフォルトの名無しさん
2023/04/01(土) 14:25:21.95ID:hxeslJ4QC#はチョット良い感じ
Juliaは死んだ
Rustがんがれ
Nimもがんがれ
C++は使い続けるけどね
0953デフォルトの名無しさん
2023/04/01(土) 15:11:33.70ID:rIj/v2gaC++に挫折した者ども、いまこそRustに集え
そしてRustに挫折した者ども、いま一度C++に立ち返れ
の方がバランスいいと思う
0954デフォルトの名無しさん
2023/04/01(土) 16:41:11.09ID:HWGbnwVz同名メソッドが衝突した時にどうなるかは言語によってかなり異なるから一番重要じゃないかな
衝突が許されない言語と許される場合も条件がある場合もあるよ
衝突があってもエラー出ない言語もあれば特定な時だけエラーな言語もあるね
回避方法も別名定義方式から同名自己定義や直接指定と色々だ
0955デフォルトの名無しさん
2023/04/01(土) 17:25:01.59ID:/8VZFYJJ0956デフォルトの名無しさん
2023/04/01(土) 17:29:58.10ID:WHqiXdwWどういう意味?
0957デフォルトの名無しさん
2023/04/01(土) 17:52:08.96ID:/8VZFYJJこれまで、C++のスマポは、CppCoreGuidelinesなんてものはあっても、強制されなかった
0958デフォルトの名無しさん
2023/04/01(土) 18:00:21.17ID:WHqiXdwWスマートポインタの使用するしないにRustは全く関係ない?
ここ見てる人は俺も含めてRustに注目してはいるが
C++ユーザのほとんどはRustなど眼中にないだろう
0959デフォルトの名無しさん
2023/04/01(土) 18:01:23.45ID:WHqiXdwW0960デフォルトの名無しさん
2023/04/01(土) 18:06:42.88ID:/8VZFYJJ0961デフォルトの名無しさん
2023/04/01(土) 18:09:42.77ID:vBVsKFoD某オジお得意の誤訳だったんじゃねーの？
0962デフォルトの名無しさん
2023/04/01(土) 19:15:27.20ID:ugeMTEEj> 具体型Fooが確定している状態で動的ディスパッチは絶対に発生しません
逆
動的ディスパッチが実行される時点では必ず具体型Fooが確定している
> dynと目印のついたトレイトオブジェクト経由でしか動的ディスパッチは発生しません
> そしてこのときトレイトは確定しているのでメソッド名は衝突しません
衝突する
直接のトレイトは確定しても付随するトレイト境界があれば各トレイトでメソッド名は衝突しうる
0963デフォルトの名無しさん
2023/04/01(土) 19:16:31.21ID:ma7yA/CEでも>>905によるとRust以外の話をしたつもりは無いらしいよ？
深読みしすぎじゃないかな？
0964デフォルトの名無しさん
2023/04/01(土) 19:31:10.27ID:9m4PZsrBそれを説明されると困る人がいるのが不思議
0965デフォルトの名無しさん
2023/04/01(土) 21:31:47.02ID:WHqiXdwW何を言っているのかサッパリ分からん
0966デフォルトの名無しさん
2023/04/01(土) 21:44:43.97ID:NRw2BG4nなにかコメントしたいだけの池沼なので放置するしかない
0967デフォルトの名無しさん
2023/04/01(土) 21:50:56.74ID:WHqiXdwW0968デフォルトの名無しさん
2023/04/01(土) 21:55:20.36ID:3M3YuI+XC++でスマポを使ってもヌル安全性もデータ競合安全性も得られない
さらに複雑化した時のスマポの使い方ミスで多くの問題が起きてきたことを考えると
本当に必要なのはスマポが正しく使われていない時にコンパイルエラーを出すこと
現状のC++は欠陥品であり今後も多くのセキュリティホールを生み出し続けるだろう
0969デフォルトの名無しさん
2023/04/01(土) 21:57:58.76ID:WHqiXdwWおおGCくんが来た
>C++でスマポを使ってもヌル安全性もデータ競合安全性も得られない
どんなミスか興味があるのでソースで示してね
0970デフォルトの名無しさん
2023/04/01(土) 22:10:09.20ID:rBOo7R6g同感
Rustは衛生的マクロな点を始めとして各種マクロが優秀すぎる
C++がダメすぎるんだよな
テンプレートも問題ありすぎ
0971デフォルトの名無しさん
2023/04/01(土) 22:21:05.85ID:nbXeTJU5衝突の定義も捻じ曲げにきてるよな
0972デフォルトの名無しさん
2023/04/01(土) 23:32:16.53ID:AdU+jSWJコードがわかりくいのかなと思って
vtableのところをもう少しわかりやすくしてみた
trait TraitA { fn method1(&self); fn method2(&self); }
trait TraitB { fn method1(&self); fn method2(&self); }
trait TraitAB: TraitA + TraitB {}
struct Foo;
impl TraitA for Foo { fn method1(&self) {} fn method2(&self) {} }
impl TraitB for Foo { fn method1(&self) {} fn method2(&self) {} }
impl TraitAB for Foo {}
macro_rules! as_addr { ($target:expr) => { &($target) as *const _ } }
macro_rules! as_array { ($addr:expr, $index:expr) => { *(($addr) as *const usize).offset($index) } }
macro_rules! vtable { ($dyn:expr, $index:expr) => { unsafe { as_array![as_array![as_addr!($dyn), 1], $index] } } }
fn main() {
let foo = Foo;
let dyn_foo: &dyn TraitAB = &foo;
assert_eq!(vtable![dyn_foo, 0], std::ptr::drop_in_place::<Foo> as usize);
assert_eq!(vtable![dyn_foo, 1], std::mem::size_of::<Foo>());
assert_eq!(vtable![dyn_foo, 2], std::mem::align_of::<Foo>());
assert_eq!(vtable![dyn_foo, 3], <Foo as TraitA>::method1 as usize);
assert_eq!(vtable![dyn_foo, 4], <Foo as TraitA>::method2 as usize);
assert_eq!(vtable![dyn_foo, 5], <Foo as TraitB>::method1 as usize);
assert_eq!(vtable![dyn_foo, 6], <Foo as TraitB>::method2 as usize);
}
このように各トレイトの同名メソッドを区別してvtableのインデックス化(このコードだと他の部分含めてインデックス3～6)をしている
0973デフォルトの名無しさん
2023/04/01(土) 23:39:50.11ID:62NQQrT20974デフォルトの名無しさん
2023/04/01(土) 23:53:21.20ID:3egme1as雑スレだとGCの勢力が強くなりそう
0975デフォルトの名無しさん
2023/04/02(日) 00:22:03.90ID:Xkdfgrgvhttps://mevius.5ch.net/test/read.cgi/tech/1652347700/385-392
0976デフォルトの名無しさん
2023/04/02(日) 00:30:37.47ID:bY6+UifX汚コードに磨きをかけるなよ
普通に関数で書けるものをネストさせたマクロにするセンスに脱帽
0977デフォルトの名無しさん
2023/04/02(日) 00:32:38.03ID:xbcpqScoC++よりRustは実行デバッグの時間がかなり減って開発効率がいい
0978デフォルトの名無しさん
2023/04/02(日) 00:39:46.89ID:GYBlNyWI0979デフォルトの名無しさん
2023/04/02(日) 00:43:54.27ID:W9/nq+tL結局C++とRustってどっちが良いの？ 2traits
https://mevius.5ch.net/test/read.cgi/tech/1680363777/
0980デフォルトの名無しさん
2023/04/02(日) 00:48:46.53ID:Xkdfgrgv君の日本語がおかしいって話なんで、ソースで示すべきことは何も無いよ
それともなにか示してほしいの？
0981デフォルトの名無しさん
2023/04/02(日) 01:41:46.92ID:DBhEEanc他人への攻撃をしてる人たちは邪魔なんで消えてほしい
0982デフォルトの名無しさん
2023/04/02(日) 02:09:25.03ID:WdMf4Ye5特にC++は読めもしないのだろう
RustとC++を技術的に比較するなら両方のソースをある程度書けないと不可能
0983デフォルトの名無しさん
2023/04/02(日) 07:26:34.66ID:W9/nq+tL慣れは必要だけど、要求される頃には、定石も今以上に揃うだろうし
ここ読んでて、食わず嫌いしてたRustを眺めなおしてから、
CppCoreGuidelines 読んだら、めっちゃわかりやすかった
これだけで俺には十分収穫あったね
0984デフォルトの名無しさん
2023/04/02(日) 07:39:56.12ID:W9/nq+tLはずなのに、そのうえまだ、Rustの優位を主張するのに全力な香具師がいる
若いなって正直思う 昔俺もああだったぜ
C++を母語としている者が考えることは、次に何を取り込むか
やっぱ #pragma safe は欲しいね
そのうしろに値くらい付いてもいい safeの詳細も、進化していくだろうから
0985デフォルトの名無しさん
2023/04/02(日) 07:53:54.77ID:W9/nq+tL静的にソースコードを解析してsafeを証明できる、ガイドライン違反を指摘できることだとばかり
rustcのサンプル出してくれた奴には悪かった
「たしかに面白い…けど、こういうの、Cなら、yylvalっぽく処理するよね…」っていう印象だったんだ
inspectってのが来たら来るらしいので、来たら喜んで遊んでみるとして
優位性の根拠になるか? それホントC++に必要? ってのは次スレに持ち越したい
っていう埋め
0986デフォルトの名無しさん
2023/04/02(日) 10:51:04.91ID:D26hzdDfキミは周回遅れのド素人でかつ
人より知能が劣るからもう発言しなくていいです
これはいじわる発言じゃなくて、助言です
0987デフォルトの名無しさん
2023/04/02(日) 10:59:32.98ID:W9/nq+tLRustのエヴァンジェリストが暴れていいのに、初心者の俺に黙っとけはないなあ
せいぜい質問させてもらうよ
0988デフォルトの名無しさん
2023/04/02(日) 11:04:00.93ID:xlKg15xW皆さん次スレでも騙されないようご注意を
0989デフォルトの名無しさん
2023/04/02(日) 11:10:11.81ID:6UFMeU2Z複オジメソッドに釣られてるよ
気をつけて
0990デフォルトの名無しさん
2023/04/02(日) 11:12:51.90ID:Xkdfgrgv>>981は露骨に複おじだけど
>>986=>>847=ID:BpzIAh0Kは違う気がするんよなあ
あんまり雑認定しすぎるとおじサイドの「自演に見えてるやつは頭がおかしい」の批判が有効になってしまうから、確証を持てないならほどほどにな
0991デフォルトの名無しさん
2023/04/02(日) 11:17:21.13ID:W9/nq+tL0992デフォルトの名無しさん
2023/04/02(日) 11:34:39.31ID:E52hJVrBだって時間のムダだもん
0993デフォルトの名無しさん
2023/04/02(日) 11:42:03.77ID:Xkdfgrgvせっかく平和なRust本スレが実現できて、後はヤツが追い払った住民たちを呼び戻すだけだというのに！
0994デフォルトの名無しさん
2023/04/02(日) 11:44:18.44ID:W9/nq+tLそうくると思って、俺がとっととスレ建てちまったからねｗ
0995デフォルトの名無しさん
2023/04/02(日) 11:45:16.10ID:E52hJVrBそうかそっちか
それは申し訳なかった
こっちを隔離にすべきやね
複オジも池沼（ID:W9/nq+tL）もこっちに張り付く気マンマンらしいし
0996デフォルトの名無しさん
2023/04/02(日) 12:34:42.17ID:uooZ7ifu0997デフォルトの名無しさん
2023/04/02(日) 13:29:57.68ID:Ky8sq4kqC/C++のポインタとメモリ管理理解出来なかったからだろ
0998デフォルトの名無しさん
2023/04/02(日) 13:30:14.04ID:Ky8sq4kq0999デフォルトの名無しさん
2023/04/02(日) 13:30:23.82ID:Ky8sq4kq1000デフォルトの名無しさん
2023/04/02(日) 13:30:34.24ID:Ky8sq4kq10011001
Over 1000Thread新しいスレッドを立ててください。
life time: 36日 3時間 40分 48秒
10021002
Over 1000Thread運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。
ニュース
- 和久井学容疑者に同情などできない理由…26歳も年下の水商売の女性とまともに付き合えると思っている50代男性はどうかしている★11 [Hitzeschleier★]
- 【新宿タワマン刺殺】細客ほどストーカーに…カリスマキャバ嬢たちは事件をどうみる？「大事なもの売ってまでお金つくる男もヤバイ」 ★2 [樽悶★]
- 【テレビ】最高傑作だと思う「NHKアニメ」ランキング！「未来少年コナン」「十二国記」を抑えての1位は… [湛然★]
- 【𝕏】中国企業が「世論工作システム」開発か、Ｘアカウントを乗っ取り意見投稿…ネットに資料流出 [ぐれ★]
- 40代の男性受刑者 靴下と箸で首をくくる 搬送先の病院で死亡 自殺か 岐阜刑務所 [煮卵★]
- 【首都高速湾岸線】トンネル内でタクシーが横転 2人死亡 縁石に衝突後… [香味焙煎★]
- 好きなおにぎりの具（ドングリLV0可テスト） [462275543]
- 
【悲報】なんG、ガチのマジでどんぐりが育たなくなる
…🌰😭
- は！だ！か！の！チノ！完成で、貯めに貯めたチノのエロ画像貼りまくる
- 【画像】男ならこれくらいの筋肉が情けないようで逞しくもあるよな？？？？?
- レッドデッドリデンプション2やってるけどどんなプレイしたら楽しい？
- PS5で面白いゲームを教えてくれ