X

結局C++とRustってどっちが良いの？

レス数が1000を超えています。これ以上書き込みはできません。
1デフォルトの名無しさん
垢版 |
2023/02/25(土) 09:49:46.74ID:VRyB88xR
C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな？
2デフォルトの名無しさん
垢版 |
2023/02/25(土) 11:00:27.52ID:9NhnUjd2
いうほどでもない
2023/02/25(土) 13:27:35.74ID:P9AUzv0x
うだうだ言ってないで仕事で必要なのをやればいいんだよ
趣味なら好きなのやればいい
4デフォルトの名無しさん
垢版 |
2023/02/25(土) 13:38:44.05ID:QyjTyTMe
>>3
そうなんだけど、今後の流れが気になったので
2023/02/25(土) 17:13:51.27ID:lt8vujMQ
もう10年ぐらい前ぐらいからここはじめネット、SNSで
何か急にある言語をプッシュして他を異様にディスるムーブメントある場合
それは情報商材売りたい勢のゴリ押しってのが判明してる
そんなものに右往左往してたら話にならんよ
6547
垢版 |
2023/02/25(土) 18:15:55.88ID:VqXFnbZE
>>5
どの言語がプッシュされたんですか？
7デフォルトの名無しさん
垢版 |
2023/02/25(土) 20:03:19.10ID:bUASXHz9
c -> c++ のが自然に学べるってのはあるけど、c++の余計な仕様を覚えるのもどうかなってのはある。
rustからいきなり入る奴が本当に理解できるのか正直わからん。
2023/02/26(日) 08:44:07.54ID:NKFFZ0EI
rusty nail
9デフォルトの名無しさん
垢版 |
2023/02/26(日) 10:30:55.37ID:W2bio7pu
結論から言うと
少しずつRust縛り(必須)となっていく

C/C++だと気付かないうっかりミスが紛れ込んでセキュリティにも影響してきた確固たる暗い実績が様々なソフトウェアにある
Rustはコンパイル時点でエラーや警告として示し防止する
この差を非常に大きくそしてそれを満たすのは現状Rustしか現実的な選択肢がなく代替候補もない

Rustを書ける人員を揃えることができたところから既に移行は少しずつ始まっており着実に進んでいる
市場的にも公的にもRust製とC/C++製どちらがセキュリティ含めて信頼できるか明確なためいずれは必須指定要件となるだろう
10デフォルトの名無しさん
垢版 |
2023/02/26(日) 11:58:18.24ID:R0VbvaR9
>>9
詳しい説明ありがとうございます。
少しずつRustも勉強していこうと思いました。
11デフォルトの名無しさん
垢版 |
2023/02/26(日) 13:02:29.94ID:E7NCL2qF
>>6
Rust,Python,UnrealEngine
2023/02/26(日) 14:38:46.87ID:0HNO0Bah
しゃぶれよ
2023/02/26(日) 16:48:37.69ID:M2zxuPcR
とりあえずC/C++は小さなワンチップマイコンからスパコン富岳、そしてハードウェアの高位合成まで使える共通言語になってるから、使えれば利用できる範囲が広いかな？

オブジェクト指向が求められてCからC++が出てきたように、C/C++の構文スタイルをとりながらメモリ安全を実装したものが出てくるかもね。

学習コストとしても文法的に新規性が少ない方が好まれるだろうし。
2023/02/26(日) 17:26:20.61ID:32xuZUXu
>>13
C/C++系言語の可能性を試みる時間は既に終わった
ここ10年間でC/C++拡張やその系統では無理だと結論が出たためGAFAMなどIT大手がこぞってRustへ舵をきった
2023/02/26(日) 20:14:35.53ID:DFLJCTJ6
Rust案件なんかないやろw
時期尚早
2023/02/26(日) 21:44:33.99ID:GQhuf+Lw
アーリーアダプタ(?)的な人って、新しいものが出てきたときに良い面ばかりを
見てしまう癖が有るらしい。それでしばらくして別のものが出てくると絶賛し、
前のものを批判に変える。
2023/02/26(日) 22:00:08.16ID:32xuZUXu
大昔のRustはそうだったが実績を積み重ねて今はIT大手どこもが採用する言語となった
世界中のインフラが次々とRust製へ変わりつつある
例えばAWSなどのクラウドもそう
2023/02/26(日) 22:11:58.45ID:GQhuf+Lw
企業の中の一部で使われてきたというだけであって、言語そのものを良く見てみると
そこまですばらしい言語ではないと思えるぞ。
19デフォルトの名無しさん
垢版 |
2023/02/27(月) 01:07:20.97ID:uT3J6RSV
>>17
嘘つけ
2023/02/27(月) 01:48:26.87ID:O9/5cYsg
>>19
https://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などをはじめとする
複数の言語のエネルギー効率を相対的に示した研究結果を紹介している。
2023/02/27(月) 13:40:42.65ID:csXgFZ4x
rusty nail
2023/02/27(月) 16:14:37.34ID:dFRgN5US
>>20
それでどれくらいがRustで書かれているのかな？
2023/02/27(月) 16:27:08.91ID:NzhKA4cT
>>20
>CやRustが他の言語よりもエネルギー効率に優れていることに驚きはない。
実に疑わしい。
Cは高級アセンブラ。
基本的に効率がよいプログラムがエネルギー効率も良いはずで、だとしたら、
高級アセンブラより効率がよい言語が存在しないといけないことになるが、
あらゆる言語が高級アセンブラを越えることは不可能であるはずなので、
矛盾しているように思える。
2023/02/27(月) 16:30:03.92ID:NzhKA4cT
>>23
[補足]
手書きアセンブラだと超えることが出来る場合が有る。
C言語レベルで最も良いアルゴリズムで書いた場合、最終的にはコンパイラの
バックエンドの最適化次第ということになる。
そしてバックエンドは Rustもclang(C)も同じLLVMのものを使っているので、
Rustがclang(C)が到達できないように効率がよくなる可能性は数学的に
有りえないはず。
Rustでできるなら、Cでも出来るはずだからだ。
2023/02/27(月) 17:32:52.43ID:NzhKA4cT
>>24
[補足2]
C言語は、ノイマン型コンピュータでできる限りどんなアルゴリズムでも
使えて、使えるアルゴリズムに制限が無い。
だから、発見されている中での世界最良のアルゴリズムを使うことができる。
そしてその場合に、世界最速になれない可能性があるとしたら、
バックエンドの最適化層の最適化の能力が人間の手作業の最適化に劣る
ような場合だけである。
それに対してRustがCを速度で上回るというのは数学的に矛盾している。
むしろ、Rustのsafeモードでは、使えるアルゴリズムに強い制限が掛かっている。
2023/02/27(月) 17:55:34.32ID:jgoAw3Ga
>>24
もちろんRustとCと全く同様の低レベル記述もできるしCと同様にインラインアセンブラが書けてRust変数との連携もできるしそれらを安全に閉じ込めることができる
一方でRustはプログラム全体の安全性を大域的にコンパイラが保証することが出来るため仮に局所的にunsafeな部分かあっても人間はそこだけに注力できる点でCとは異なり決定的で革新的な変化をもたらした
そしてRustとCが他のプログラミング言語と決定的に異なるのはガベージコレクション(GC)無しで動きプログラミング言語の中で最も高速であり電力消費面でもCPUメモリリソース面でも最も有利な言語である
2023/02/27(月) 18:16:27.45ID:NzhKA4cT
>>26
>安全に閉じ込めることができる
Rustでは、これは不可能なケースが有ることが分かってる。
2023/02/27(月) 18:17:38.69ID:NzhKA4cT
Rustでそういうことができるのは、一部のアルゴリズムだけで、閉じ込めきれない
アルゴリズムが存在することがいくつも知られている。
2023/02/27(月) 18:31:59.25ID:BUZw0Bcx
>>27 >>28
プログラム全体に非安全が散らばっているアルゴリズムを考えることは可能だがバカな行為
非安全な部分を局所的に閉じ込めて安全なインターフェイスを公開するライブラリを作るのが正しい道
そうすればRustはプログラム全体の安全性を規模に関わりなく保証することができるためGAFAMなど大手ITを筆頭にその方法へと次々に切り替え始めた
2023/02/27(月) 18:36:09.13ID:NzhKA4cT
>>29
ですから、そのように閉じ込めることが絶対に出来ないアルゴリズムが存在しているのです。
2023/02/27(月) 18:36:32.74ID:NzhKA4cT
これは数学の問題です。
2023/02/27(月) 22:09:41.53ID:LP8T7WNZ
Rustの安全性って言語を乗り換える際に払うコストほど
大きなメリットはないのでね
Rustは使う人も少ないし仕事も全くない
CのUNIXやC++のMFCのようなものがないと
Rustをやろうという人は増えないだろう
33デフォルトの名無しさん
垢版 |
2023/02/27(月) 22:13:22.96ID:3K/qRK7o
結局どっちも使えるくらいのやつじゃないとどっちにしろまともな仕事にはならん。
どっちかだけと言ってるやつは仕事になってないやつだろ。
2023/02/27(月) 22:37:20.68ID:KG8RKFb2
両方使いこなせるようになると一目瞭然で
Rustは洗練されていてモダンな便利な機能も含めて開発効率も良い
もちろん安全性の保証なども付いてくるため比較するとRustが大差で有利

唯一の問題はまだRustを使える人が少ないこと
しかし着実にRustも使える人が増えていってるため
人数を揃えられたところからRustを使うところがどんどん増えている
この流れは逆になりようがない
2023/02/27(月) 23:35:53.90ID:LP8T7WNZ
Rustの仕事なんてないんだが?
2023/02/27(月) 23:38:16.05ID:LP8T7WNZ
最近だとpythonユーザがAIの流行で増えたように
Rustも牽引する何かがないと増えることはないよ
2023/02/28(火) 00:08:33.64ID:pH6hfy6B
Cじゃないとダメだと長年C++を拒絶していたLinuxもRustの導入を始めた
Google ChromeやMicrosoft Edgeで使っているChromiumもC++での多発するセキュリティ問題に耐えかねてRust採用を発表した
クラウドTOPのAmazonも>>20の記事にあるようにインフラをRust製にしている
Meta(旧Facebook)もRust製の基幹システムに変えたとの記事が出ている
この世界的な動きは日本でも少しずつ進み始めている
38デフォルトの名無しさん
垢版 |
2023/02/28(火) 11:57:56.87ID:xNmaYcy8
>>18
>>33
ほんそれ
C/C++ 使えるがどうしても Rust 嫌いって人は
Nim を使うと幸せになれる
2023/02/28(火) 14:09:00.41ID:e51yPnPZ
>>37
>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にキラープロダクトは無いので
増えることはないと断言できる
2023/02/28(火) 15:53:29.33ID:5HrxdEqK
>>36 >>38
Rust嫌いは無知が多いな
NimもPythonもGCのあるプログラミング言語であり代替になれない
超遅いPythonは論外としても
NimはNull安全すらなくC/C++と同様に安全性を保証できない言語
2023/02/28(火) 16:39:39.54ID:eD9OZA2Z
rusty mail
2023/02/28(火) 17:12:23.08ID:e51yPnPZ
>>40
無知はお前さんじゃないかな?
都合の良い記事ばっかり検索して貼っとらんで
>>39のようにソースを見なさい
2023/02/28(火) 18:20:57.50ID:Owe2yvkD
Linux Kernel 6.1はRustyというコード名前だしRust宣言だね

https://codezine.jp/article/detail/17038
> Linus Torvalds氏は、Linux OSのカーネルの最新バージョンである「バージョン6.1」を公開したと2022年12月11日に明らかにした。
> バージョン6.1は、カーネルの記述にRust言語を一部使用した最初のバージョンとなる。
> 従来、LinuxカーネルはC言語とアセンブリ言語で記述していたことから、Rustの採用は大きな変化と言える。
2023/02/28(火) 18:25:06.29ID:ilYsCf2n
>>43
プログラマならソースコードをみなよw
2023/02/28(火) 21:39:14.49ID:y7e/yQA5
>>43
C++は中途半端でクソなことがLinux界でも結論出たのは大きいな
人間チェックで安全を保証するCか
コンパイラによるチェックで安全を保証するRustか、どちらかしかないな
2023/02/28(火) 21:43:01.23ID:e51yPnPZ
LinuxカーネルにC++が使われたことはない
2023/02/28(火) 21:46:42.30ID:e51yPnPZ
ところRustってllvmだと思うけどRustでドライバ書きたい場合は
カーネルはclangでビルドするのかな?
gccとバイナリ互換じゃなかったような気がするんだけども?
というかカーネルってclangでビルドできるようになったのかな?
2023/02/28(火) 21:47:06.07ID:y7e/yQA5
>>46
そのことだよ
C++は中途半端でクソだから使う意義がないので採用しないとLinux界からも却下されていた
ところがRustは意義があるとして採用された
2023/02/28(火) 21:48:12.02ID:e51yPnPZ
>>48
全く違う
2023/02/28(火) 21:54:59.06ID:e51yPnPZ
37 / (37 + 32329) = 0.0011431749366619293
00.11% だからな...
プログラムの隆盛を見るとCにおけるUNIX
C++におけるMFC
PythonにおけるAIのようなキラープロダクトが出て
コードを書ける人が増えないと
メモリ安全ごときでRustが流行ることはあり得ない
2023/03/01(水) 02:20:06.43ID:Mc7FdiYo
>>18
Rustを本格的に始めたら言語仕様が秀逸だと分かった
これまでの言語の既成の固定観念に引きずられてるうちは分からなかったことが見えてきた
2023/03/01(水) 03:16:12.01ID:1Oup3Ez2
仕事でCを使ってきた
Pythonは苦労せず使えるようになった
でもrustは無理くさい
書き方が違いすぎるのと脳が老化して覚えられないw
2023/03/01(水) 04:54:30.39ID:HcVT2tre
>>52
モダンな言語なんでもいいけど
何らか抽象的なプログラミングをサポートしている言語でそういう保守性の高い書き方したことがない場合
どの言語でもまずは抽象的なプログラミングに慣れて習得しないままだと
仮に長年プログラミングやってきたとしても初心者止まりのままになっちゃうのでどこかへ進むとよいかも
CやってきたのならばRustはあとその部分を習得するだけだね
2023/03/01(水) 08:01:08.42ID:82Husj9h
>>52
C/C++のリプレースで使われることで騒ぐしかないんじゃ、できること自体はCと変わらないってことだしね。
小規模なプログラムだと一番のウリのメモリ安全も利益感じられないし。

制御関係とかでC++のClassや継承とかは部品の組み合わせと対応させられて便利だったけど、Rustでは継承はバッサリ切り捨てちゃったみたいだしなあ。

そういえば、脳科学者が言うには脳は老化しない、何歳になっても海馬は大きくなるらしいよ。
自分はChatGPTで掛け合い漫才しながらチュートリアル眺めてるけど、以前三日坊主だった時の壁は越えられた気がする。
55デフォルトの名無しさん
垢版 |
2023/03/01(水) 10:16:16.06ID:BrtIIoCo
>>51
C#のほうが言語仕様秀逸だよ
56デフォルトの名無しさん
垢版 |
2023/03/01(水) 10:16:52.64ID:BrtIIoCo
正直クラス無いと頭こんがらがってダメだわ
2023/03/01(水) 10:20:08.76ID:68s28u+f
>>45
なんで二択なんだよ
Nimがあるじゃないか
58デフォルトの名無しさん
垢版 |
2023/03/01(水) 10:23:04.35ID:BrtIIoCo
Rustってドライバとかにも使えるの？
組み込みで使われてる？
2023/03/01(水) 10:24:39.92ID:68s28u+f
>>52
脳の老化じゃなくて過学習が始まった年頃なんじゃね
60デフォルトの名無しさん
垢版 |
2023/03/01(水) 10:35:28.60ID:jxeZ0t7/
GoogleのCarbonが完成したら覇権とりそう
あとはZigとかはどうなんだ
61デフォルトの名無しさん
垢版 |
2023/03/01(水) 10:39:50.76ID:NalgN/NX
Rustは継承じゃなくて合成みたいだけど、そもそも継承ってそんなに危険だったっけ？
62デフォルトの名無しさん
垢版 |
2023/03/01(水) 10:41:08.58ID:jxeZ0t7/
>>57
上でも言われてたけどNimでGC無効メモリ手動管理でやったらどれくらい使い物になるんだってのは気になる
まあふつうNimならもうメモリ管理せずにORCでやるだろうけど
2023/03/01(水) 17:09:50.12ID:FMM19mI8
>>55 >>57
C#もNimもGCが基本の言語
このスレに持ち出すのは場違い

>>60
Carbonは公式ページに「Rustを使える状況ならばRustを使った方が良い」と明記されてる位置付けの言語
CarbonはC++記述遺産のメンテ用が目的

Zigは手動でメモリ解放する言語
Rustは自動でメモリ解放する言語
そしてRustではメモリ安全性がコンパイル通れば保証される信頼性が大きな差
2023/03/01(水) 17:19:17.03ID:FMM19mI8
>>58
もちろんRustはC言語と同じく低レベル記述も可能
必要ならばインラインアセンブリもサポートしておりRustの変数を使ってその場でasm挿入記述もできる

組み込みもRustのメインターゲットの一つ
https://www.rust-lang.org/ja/what/embedded
2023/03/01(水) 23:46:27.72ID:YuYxAjXZ
>>63
>C#もNimもGCが基本の言語
>このスレに持ち出すのは場違い
ここはどういう場なんでしょうか?www
2023/03/01(水) 23:58:04.67ID:Faf+SNlo
>>65
スレタイ見ればわかるようにガベージコレクション使う遅い言語は対象外だと思うよ
67デフォルトの名無しさん
垢版 |
2023/03/02(木) 00:15:37.04ID:4/ee2SHc
>>66
>スレタイ見ればわかるように
飛躍し過ぎていて「結局C++とRustってどっちが良いの？」で
GC使う言語がスレの対象外になるのがサッパリわからん
68デフォルトの名無しさん
垢版 |
2023/03/02(木) 02:30:04.05ID:bqXvu2FA
より良いものを否定し
伝統ばかりに固執する人らに
過去の栄華はあっても
未来など無い
2023/03/02(木) 05:01:47.34ID:s9foVenT
>>67
プログラミング言語は大きく2つに分かれていて
GCのある遅くてメモリ消費も多い言語と
GCのない速くてメモリ消費も少ない言語に分かれる
そこには決定的な違いがある

次にスレタイというのはいちいち説明しなくても
例えば「Vue vs React vs Angular vs Svelte Part.11」というスレはそれら比較対象からJavaScriptフロントフレームワークのスレだと分かる

そしてここはスレタイが非GC言語の既存代表例C++と非GC言語の新興代表例Rustの比較的となっているから
基本的にその両者が対象でおまけとしても同じ非GC言語のCやZigなどが対象ギリギリかなと思う
2023/03/02(木) 05:13:35.95ID:MiifFeAk
いい加減にほんに何言ってんだこのバカ
2023/03/02(木) 05:44:38.60ID:6fagNnHa
Cと名前が似てるだけで狭い範囲でしか役に立たないC#の話をされてもそりゃ困るわな
最低限ガベージコレクション無しと低レベル記述可を備えた最高速クラス言語じゃないと比較の土俵にも上がらんわ
2023/03/02(木) 06:35:13.17ID:M8IdVdds
一言で言えば、リアルタイム性を要求されるアプリケーションでも使える言語ってことだね。
2023/03/02(木) 07:12:21.96ID:ZOdXc5Gl
>>67
猫と犬とどっち飼ったらいいかな？
の質問に「金魚が良いよ」と回答しても意味ないだろ
2023/03/02(木) 07:14:53.01ID:D5BhE+0S
書こうと思えばどの分野でも書くことができるプログラミング言語だね
例えばC#やPythonではまともなOSを作ることができない

GoogleがRustで書かれたセキュアなOS「KataOS」を発表
https://japan.zdnet.com/article/35194751/
2023/03/02(木) 11:41:51.38ID:v0ZnzcWP
>>72
高い性能や高い応答性くらいの意味でリアルタイム性という用語を使ってるのかもしれないけど意味違うからね
76デフォルトの名無しさん
垢版 |
2023/03/02(木) 12:13:29.31ID:4/ee2SHc
>>69,74
そういうのは飛躍と言う
お前が>>1でそのつもりでこのスレを立てたのならスレタイは不適切
2023/03/02(木) 12:17:03.65ID:4/ee2SHc
>>72
「リアルタイム性」も知らんようだし
お前はRustについてGCのあるなしくらいしか語れないのかな?
ちなみにこの板読んでる人でGCを分からん人はほぼいないと思う
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
79デフォルトの名無しさん
垢版 |
2023/03/02(木) 13:19:48.65ID:2W3DfR3d
>>1です。色々と混乱させてしまってすみません。
C++で今まで作られてきたものがどれだけRustに変わっていくのか気になってスレ立てしました。
メモリ安全性という観点だとRustになりますが、C++にはRustより優れている点があって、今後もまだ残り続けるのかどうかです。
2023/03/02(木) 13:47:49.79ID:9x7ptNRV
VB6やCOBOLみたいに進化を止めたゴミにならない限りはC++も残り続けるでしょう
今のところC++がそういったゴミになる兆候は無いと思います

Rustが優れているかどうかは一切関係がありませんね
2023/03/02(木) 13:48:50.41ID:BxgVYWtl
C++は残り続けるけど徐々にメインストリームはRustかそれと同等のメモリ安全性を備えた言語に移っていく
既存のコードベースが大きいから急激には変化しない

残る理由はCOBOLが残っているのと同じで優れてるという理由からではない
2023/03/02(木) 14:11:06.82ID:4/ee2SHc
試しにChatGPT先生にRustにキラーアプリがあるか聞いたらSolanaやRayonだって
>SolanaやRayonがUNIXやMFCのようにプログラミング言語を新たに習得しようと
>する人を爆発的に増やすことは、現時点では考えにくいと言えます。
>UNIXやMFCが広く普及した理由の一つは、それらが当時の主流であったプラッ
>トフォームやアプリケーションの開発に必要不可欠であったためです。一方、
>SolanaやRayonは、それぞれ特定の分野において高いパフォーマンスを発揮す
>るためのライブラリやプラットフォームであり、必ずしも全ての開発プロジェ
>クトに必要不可欠なものではありません。
>また、Rust自体がまだ比較的新しい言語であるため、多くのプログラマがRust
>を習得する必要性を感じているわけではありません。ただし、Rustの安全性や
>パフォーマンスが注目されるにつれ、より多くのプログラマがRustに興味を持
>ち、学習する可能性はあります。
>つまり、SolanaやRayonがプログラミング言語を新たに習得しようとする人を
>爆発的に増やすことに貢献するかどうかは、それらが必要不可欠なライブラリ
>やプラットフォームとして広く普及するかどうかにかかっていると言えます。
2023/03/02(木) 14:16:45.49ID:4/ee2SHc
例えばRustで書かれたOSをAndroidやiOSの後継にするとか
携帯に匹敵する新たな情報端末が出現して
それがRustで制御されているとか
2023/03/02(木) 14:23:37.36ID:N97puPhx
質問がバカだと回答もバカになるいい例
ググり力と同じくジピり力が求められる
2023/03/02(木) 14:36:25.48ID:4/ee2SHc
「ジピり力」かぁw 大事だね
SolanaやRayonが返ってきた質問は以下
>あるプログラミング言語が流行るにはC言語におけるUNIXやC++のMFC、最近だ
>とpythonがAIによって流行ったようにキラープロダクトが重要だと思います。
>キラープロダクトがあれば、その言語を習得したプログラマが一気に増えます。
>Rustにそのようなキラープロダクトはありますか？
Rustの爆発的普及にはキラープロダクトが不可欠
2023/03/02(木) 14:38:15.81ID:D5BhE+0S
>>79
C++は今も違法増改築を続けて無数に部屋(仕様)が作られていくような言語
そして新たな増改築が決まっても、完成(実装)されなかったり、新たな部屋の存在が知られていなかったり、ほとんどの部屋は極一部の人しか使われていない
結果的に良い機能があっても使われないのは無駄に大きく重複もある複雑な言語仕様のせい
例えばC++20で導入されたstd::rangesはRustでいうとIteratorなどの基本的なデータ取り扱い機能で超重要だが今後も広まらないのだろう
歴史的な事情でC++の全容は複雑怪奇となっていて理念の一貫性もなくどうしようもない状態

Rustは洗練された言語仕様となっていてC++と比べれべるとシンプルで分かりやすい
全体の理念も統一されており特に安全性に関する保証が与える信頼性はこのセキュリティ重視の時代に完全にマッチしている
今後Rust人口が増えてくると企業案件でC/C++が使われてきたものはRust指定(必須)となっていくだろう
2023/03/02(木) 14:45:55.72ID:4/ee2SHc
>>86
普及して長いことたてばRustもご多分に漏れずいずれ複雑怪奇になるってw
若いと分からんかもしれんが
C++は複雑怪奇に見えるかもしれんが規格変更には慎重の方だと思うよ
ところでRustって規格あるの? 仕様しかない?
2023/03/02(木) 15:24:09.80ID:4/ee2SHc
実装が1つしかないから規格はないかな
2023/03/02(木) 15:30:29.97ID:o+lCraYI
C++もスマートポインタでメモリ安全を取り込んできているけどね。なんでも飲み込む奴だからなあ。
2023/03/02(木) 15:41:34.24ID:4/ee2SHc
例えばstd::shared_ptr相当のものは
90年代中盤から後半にかけて使われ始めたと思うけど
（boost::shared_ptrはいつからだっけ？）
std::shared_ptrが規格に入ったのはC++11
規格の拡張は無節操というより慎重というかクソ遅いよ
2023/03/02(木) 15:59:19.04ID:dC3Ayx4m
>>86
Javaが出た時に聴いたことあるような文句だな
割とマジでフラッシュバック
2023/03/02(木) 16:08:40.39ID:eS6QMQkY
>>79
それは分類が非常に簡単
既に作られており穴も発見されないものをわざわざRustに移植する意味はない
穴が多く悩まされてるものはChromiumのようにRust併用やRustへ切り替えが進んでいる
新たに作ったり大きく作り直す場合はRust一択
2023/03/02(木) 16:24:01.58ID:eS6QMQkY
>>89
C++はスマートポインタがあっても言語システムとして安全を保証する枠組みがない
まともなIT企業からRustへ移動し始めている根本的な理由がそこ
2023/03/02(木) 16:40:50.78ID:4/ee2SHc
>>93
Rustプログラマを支障なく確保できなければ企業は
試験的採用こそすれど本格採用はしない

Rustプログラマが多い -> Rust生態圏が良くなる ->
Rustプログラマが増える -> （最初に戻る）

※Rust生態圏が良くなるとはライブラリやtipsが増えRustの仕事が増えること

この好循環を作らないことにはRustが流行りだすことはないだろう
そのためのキラーコンテンツ
>>37で上げてるようなソフトはしょぼすぎて該当しない
>>83くらいの状況になれば変わる
2023/03/02(木) 16:53:27.06ID:eS6QMQkY
Rust自体がプログラミング言語史上でも革新的なキラーコンテンツ
まともなIT企業からRustを導入していっている理由がそこにある
非GC言語でメモリ安全性を言語システムが保証する初で唯一のプログラミング言語がRust
2023/03/02(木) 17:10:59.88ID:oc1UgWLG
ダメダコリャ
2023/03/02(木) 18:47:07.82ID:9x7ptNRV
なんだかんだで置き換えられずにユーザ空間ソフトの基礎ライブラリになってるC言語の奴らすげーよな
2023/03/02(木) 19:04:35.27ID:o+lCraYI
とりあえずC/C++は今ところほぼ全てのCPUで環境が整備されているし、
メーカーさんのサンプルにしても、過去の資産も（FreeRTOSだのもArduinoなんかも）膨大。
それらが全て使われなくなったり、他の言語でで書き換えられるということが仮に
にあるとしても相当先の話になるだろう。
と考えると、C/C++はほぼ基礎教養かな？

あとは実務で要求されたものを身につけるっていう感じなんだろうな。
パラパラ眺めた範囲ではRustもC++知っていればさほど難しくなさそうだけど
個人で趣味レベルでやってますといっても、実務経験ないとキャリアとしてのアピール度は低いしな
2023/03/02(木) 19:14:16.94ID:OHJUJNoL
>>98
Cの基礎は必要だがC++は要らん
特殊な組み込み環境などでない通常利用ならば対応していてRustが使える
2023/03/02(木) 19:20:18.08ID:OAWE1K4h
でもお前組み込みエアプじゃん
2023/03/02(木) 19:22:55.17ID:OAWE1K4h
ルビキチも自分の実績とは関係なく人工衛星がどうのと褒めそやす奴だった
これもいずれはあのような壊れたレコードに成り果てるのだろう
2023/03/02(木) 19:42:00.55ID:+4hIkzuc
Firefoxだけかと思っていたらChromeもRustなのかよ

Google Chrome、プログラミング言語「Rust」の採用を発表
https://news.mynavi.jp/techplus/article/20230113-2561774/
2023/03/02(木) 23:06:33.64ID:4/ee2SHc
>>102
それでRustプログラマが増えることはないな
>>83くらいの状況にならんと
104デフォルトの名無しさん
垢版 |
2023/03/03(金) 06:56:09.99ID:3EPD3050
>>99
その「特殊な組み込み環境」とやらでもC/C++は使えるからね。

C++はフルには要らんかもだけど、
クラスと継承は組み込みとかでも便利に使われてたりするね。

できることが大差ないとすると、仕事でRustを使えと言われない限り、個人レベルで積極的に使う理由に乏しいかなぁ。
個人でメンテできる程度だとメモリ安全ってそれほど重要ポイントではないし。

PythonにとってのAIみたいに、こういうアプリケーションなら、C/C++より遥かに楽で簡単に実現できるというものが必要なのではないかな。

今の段階じゃ、メモリ安全にするために制約やチェックを厳しくしたC/C++ってだけって感じだもの。
2023/03/03(金) 07:13:09.62ID:5+VE8dsn
Rustは後発なアドバンテージで
洗練されたモダンな言語仕様のため非常に書きやすい
これが一番大きなメリット
おまけとしてメモリ安全性の自動保証とデータ競合なしの保証
これらにおかげでC/C++で書いてた時に無駄に必要だった実行時デバッグが激減して消えた
Rustは開発効率が大きく向上する
106デフォルトの名無しさん
垢版 |
2023/03/03(金) 09:31:41.76ID:oC7cFOXy
>>95
Dが出た時に聴いたことあるような文句だな
割とマジでフラッシュバック
2023/03/03(金) 13:09:51.97ID:t7eEMnCD
>>106
どこが似てんだよ何も区別付かないアフォ
2023/03/03(金) 13:21:04.67ID:mNTxopBi
おちんちんランドへおいでよ！
2023/03/03(金) 13:21:58.74ID:PdMH/ctM
altJSブームが落ち着いたせいで下火になっちゃったけど
やっぱりHaxeは復活すべきだよな
2023/03/03(金) 13:26:08.63ID:HbtHbRsb
>>107
凄い似てるよ
Javaが出たときにも聞いたぞ
「C/C++を置換する！」は人間の性なんだろうw
長くやってると何度も見るし結果もだいたい分かる
2023/03/03(金) 16:49:35.55ID:lJwnZSPr
>>110
しかも、Javaの普及速度は物凄く速かったが、Rustは伸びてない。
2023/03/03(金) 19:36:46.54ID:NsCHD7Iu
>>91 >>110
プログラミング言語の一般的な基礎知識を持たない人がRustのアンチをやっているのかしら
JavaがCやC++に置き換わらなかった理由の一つはJavaがガベージコレクション必須の言語だからですよ
CやC++の置き換えとなるためにはGCを必要としないプログラミング言語でないとダメなんですよ

GCを必要としない言語も数少ないながら今までいくつか出て来たのになぜCやC++を置き換えられなかったか分かりますか？
CやC++で問題となってきたのはメモリ操作の安全性とデータ競合の安全性です
それらを完璧に対応して言語自体が安全性を保証する言語が今までなかったからですよ
Rustが初めて対応して初めて真にCやC++を置き換えられるようになりました
だからIT大手各社がライバル関係を超えて共同してRustを支援そして採用しているのですよ
2023/03/03(金) 20:45:25.65ID:56kfvkVg
>>112
>>77

お前はそればっかりだなw
そんなものはこの板の住人が知らん訳ないやろw
GCくらいしか語る知識がないんだろうな
2023/03/03(金) 21:06:34.40ID:NsCHD7Iu
>>113
その>>77を見てみましたがリアルタイム性の話ですか
それは直接はプログラミング言語とは関係ない話ですが少し関係がありますね
言語に関わらず作成したシステム側の話でOSからゲームのようなアプリまで必要とされる時間的制約があることをリアルタイム性と言います
もちろんガベージコレクションはリアルタイム性の障害となりますのでそれを軽減する手法を取ったりリアルタイム性を必要としないタイミングでGCを実行します
しかしそれでも現実的なOSや基幹システムでGC言語の利用は厳しいでしょう
そのためOSなどの記述にはCやC++やRustが使われます
メモリ安全性などの保証をプログラマーではなく言語システムに任せることができるRustがベストとなります
2023/03/03(金) 21:20:32.28ID:qLiBhaKu
エアプするにしてもせめてthe embedded bookくらいざっくり読んでからにすればいいのに
2023/03/03(金) 21:26:29.88ID:HbtHbRsb
>>114
リアルタイム性の話ではなく
GCの話しかしないことを言っている
GCくらいしか語る知識がないと俺は推測している
2023/03/03(金) 21:48:53.60ID:IWtB3OsL
C++とRustの比較スレだからGCない言語が前提だもんな
Javaとか持ち出す>>110や>>111はアホすぎ
118デフォルトの名無しさん
垢版 |
2023/03/03(金) 21:51:10.69ID:HbtHbRsb
>>118
>>76
119デフォルトの名無しさん
垢版 |
2023/03/03(金) 21:51:28.18ID:HbtHbRsb
>>117
>>76
2023/03/03(金) 22:54:44.50ID:3xVHehJY
ここが新しい隔離スレちゃんですか
2023/03/03(金) 23:40:18.48ID:DSH9vzOS
ここは純粋にC++とRustの比較スレ
しかし無関係なGC言語を持ち出してくるバカがいてそれを邪魔をしているようだ
2023/03/03(金) 23:41:20.65ID:kiJ4JQPs
実務経験の乏しい人が言語機能だけで頭でっかちなアピールしてるのを見ると狙ってアンチ活動してるのかと勘繰りたくなるよね

まぁ隔離ファイト続けてくれ
2023/03/03(金) 23:57:24.37ID:gZNQib4P
それらの言語を実際に書いて使っていればガッべージコレクションのある言語がC言語系を置き換えできないことくらい分かるはずだもんなー
2023/03/04(土) 02:04:08.56ID:OUzFL/z0
WinAPI/ATL/MFCの系譜をWinFormsが現れて.NETが置き換えていった歴史は無かったことにされたらしい
2023/03/04(土) 05:09:33.55ID:zMMeSguG
CやC++に置き換わる言語の話でWinAPIやWinFormsを持ち出してくるとは頭おかしいな
2023/03/04(土) 10:37:16.20ID:4/pts6A0
C#もGCないネイティブでビルドするオプションがあったら天下取れたかもな
VB6はGC無かったのになぜこうなった
2023/03/04(土) 10:41:49.65ID:CDmz22lO
>>125
君はてをにはがおかしい
寝ぼけた頭で脊髄反射で書き込むのはやめたほうがいいな
2023/03/04(土) 10:54:13.03ID:RFNVa0Qi
>>114
chatGPTの回答に似てるなωωω
129デフォルトの名無しさん
垢版 |
2023/03/04(土) 10:59:11.20ID:RFNVa0Qi
>>127
何処が可笑しいか指摘してくれ
おれには判らん
2023/03/04(土) 11:05:58.63ID:54Un32Sk
>>129
「CやC++に置き換わる言語の話」なんて誰もしていない
「CやC++に取って代わる」あるいは「CやC++を置き換える」と言いたいのだろう

あるいは本気で「CやC++に置き換わる言語の話」をしているのなら今度こそ本当に頭がおかしいな
131デフォルトの名無しさん
垢版 |
2023/03/04(土) 11:14:10.28ID:RFNVa0Qi
それがてにをはどどう関係あるの？
2023/03/04(土) 11:23:10.42ID:33wAkDSd
>>126
VB6はトレースGCではないけど参照カウンタGC方式のGC言語
VB6オブジェクトは裏で参照カウンタが自動的に使われていてそれにより使われなくなったメモリを回収している
ちなみにC++のshared_ptrなども参照カウンタ方式だが裏で勝手に使われることはなく必須でもなくプログラマー裁量なのでC++はGC言語ではない
133デフォルトの名無しさん
垢版 |
2023/03/04(土) 11:59:27.29ID:Ss9j+0Cw
Rustに期待している人のフラストレーションを解消したいなら
フルスクラッチでOSを書くくらいしか方法はないだろうね
OSの普及は更に至難の技だけども
2023/03/04(土) 12:08:40.51ID:2fdiw2OM
(実務経験ゼロ + 論理的思考力の欠落 + 自己愛性パーソナリティ障害) * Rustへの執着 = 通称複製おじさん
2023/03/04(土) 12:51:29.76ID:SdQ3Tgr2
　　　　　　　　　　　|
　　　　　　　　　 　 |　　彡⌒ミ
　　　　　　　　　　　＼ (´･ω･`)またGCの話してる
　　　　　　　　　　　　　(|　　　|)::::
　　　　　　　　　　　　 　(γ　/:::::::
　　　　　　　　　　　　　　 し ＼:::
　　　　　　　　　　　　　　　　　 ＼
2023/03/05(日) 00:54:23.16ID:OH6jTTZv
うるせー馬鹿
2023/03/05(日) 00:59:18.56ID:eidG4gk+
>>133
フルスクラッチの新たな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/
138デフォルトの名無しさん
垢版 |
2023/03/05(日) 09:30:23.81ID:B0+xSixt
>>137
次第に現行プロジェクトを置換して増えていくなんて展開はありえないっての
AndroidやWindowsをRust製のOSで置換するくらいしかストーリとしてはない
Linuxに入っているRustコードは>>39で書いた通り
2023/03/05(日) 10:00:51.19ID:N4QaJnep
私はRustで年収1億稼ぎましたみたいな話はないのかよ
マイナープロジェクトでちょっと使われたら勝利なのかよ
2023/03/05(日) 11:14:29.69ID:/Qd0pRlS
Winnyの作者みたいに逮捕されるかと思ったら怖くて無理
2023/03/05(日) 11:34:54.12ID:ukOUhlGm
話し飛躍しすぎでしょ
2023/03/05(日) 11:49:22.14ID:nmaj3sub
Rustで検証してうまくいったらそのままCにコンバートすれば余計なチェックコードが削れてる速く動く

とかね。
143デフォルトの名無しさん
垢版 |
2023/03/05(日) 14:28:35.02ID:FAqgXVt3
てかGCって別に悪いもんじゃねぇしな
144デフォルトの名無しさん
垢版 |
2023/03/05(日) 14:30:11.56ID:FAqgXVt3
>>133
それよりもグラフィックソフト作ったほうが広まると思うけどね
Blender参考に3Dモデリングソフトつくってよ
145デフォルトの名無しさん
垢版 |
2023/03/05(日) 14:54:49.80ID:B0+xSixt
>>144
それでは心が満たされないんだよ
GCの話しかしない人とか
2023/03/05(日) 15:15:15.70ID:WdTi9AcG
>>143
GCの有無はその言語がカバーできる範囲の差となり優劣関係が明白
GCのない言語は全てをカバーできる
147デフォルトの名無しさん
垢版 |
2023/03/05(日) 15:45:42.10ID:09jM8Cxo
>>146
UEとかのゲームエンジンは当たり前だがついてる
うまく付き合ってくほうが大事
2023/03/05(日) 15:50:56.78ID:7nv7saAE
本当にGCの話しかしないんだね
GC以外のことを語る知識がない
GCはこの板見てる人はほぼ誰でも知っているだろう
2023/03/05(日) 15:58:09.36ID:Y+o3TKYe
色んな言語のライブラリがC++(や最近はRust)で書かれているのを考えると
C++とRustが王者決定戦になるのは当たり前じゃね？
2023/03/05(日) 16:07:43.53ID:RiJu3w7U
入力にゴミデータを与えるとゴミしか出力されないことの好例
2023/03/05(日) 18:26:02.22ID:xsWqtK1g
いつのまにかPythonやJavaScriptのライブラリがRustで作れるようになってるのな
152デフォルトの名無しさん
垢版 |
2023/03/06(月) 00:49:06.50ID:pFRSokg0
そりゃラップするだけなんだから作れるだろ
アホか
2023/03/06(月) 09:19:45.87ID:93HR+LQR
そして我が道をいくLISP
2023/03/06(月) 09:45:52.37ID:4Z2NP+rF
LISPといえばGCの元祖だな
155デフォルトの名無しさん
垢版 |
2023/03/06(月) 13:40:13.02ID:diWxUEyJ
　　　　　　　　　　　|
　　　　　　　　　 　 |　　彡⌒ミ
　　　　　　　　　　　＼ (´･ω･`)またGCの話してる
　　　　　　　　　　　　　(|　　　|)::::
　　　　　　　　　　　　 　(γ　/:::::::
　　　　　　　　　　　　　　 し ＼:::
　　　　　　　　　　　　　　　　　 ＼
2023/03/06(月) 15:05:53.11ID:diWxUEyJ
memo
https://zenn.dev/dumblepy/articles/3db2134ff88763
2023/03/06(月) 17:14:45.53ID:93HR+LQR
ふと思ったんだけど、Rustのmutableな構造体の中にimmutableなフィールドって持てるんだっけ？
2023/03/06(月) 20:00:50.97ID:BPh5rEIJ
>>157
そういえば、C++のcv属性は、論理和方式で、constは足し算の様に0から1に
変わるが、mut 属性はそうはならないだろうから、どうなるんだろうな。
constは意味的に考えてもcastしない限りは、、constなものはいくらやっても
書き込めるようにはならない、というのは安全性から当然なんだけど、
mutだとそうはいかない。
2023/03/06(月) 20:09:02.49ID:BPh5rEIJ
>>158
mutとconstは逆さまの働きみたいだから、どっちで行くかは言語設計者の自由と
思われがちだけど、constな構造体のメンバは勝手に全てconst扱いになるという
単純な論理に出来るけど、mut方式の場合は、constキーワードも別に必要になりそう。
2023/03/06(月) 21:18:31.55ID:HKTArltY
>>157
他の言語と同じでsetter相当をなくしてgetterだけにすればいい
専用のラッパーを作る方法もあるができて当然の機能なので誰もやらないだろうね
2023/03/06(月) 21:44:09.47ID:l1NoBYC6
>>159
C++でconstを誤用しているのとは異なり
Rustではconstを正しく定数の意味で使っているので注意
つまりconstは定数でありコンパイル時に静的に定まる
もちろんconstとは別の概念としてmutableとimmutableがあり、これらは可変性の有無を表す
さらにそれらと別の概念として所有権があり、所有権を持っていればimmutableであろうと関係なくmutableな変数へ移すことで可変性を得られる
一方で所有権を持たないimmutableな参照からは可変性を得られない
2023/03/06(月) 21:51:25.41ID:1935XsNt
>>161
>C++でconstを誤用しているのとは異なり
誤用なの?
2023/03/06(月) 22:01:32.22ID:l1NoBYC6
>>162
そうだよ
実行するたびにあるいは関数を呼ぶたびに値が変わりうる変数(＝静的に値が定まらず変わりうること)に対して、
変数がimmutableであることを間違えてconstと付けてしまった
そのためC++では定数(＝静的に値が定まること)の場合は苦肉の策でconstexprと変な名前を付けることになった
2023/03/06(月) 22:21:12.53ID:1935XsNt
>>163
C++では単に値が`constant'って意味で使っただけではないのかな?
それを誤用とは言わんと思う

ところで何でconstexprではないconst変数は
静的に定まらないことになってるの?
2023/03/06(月) 22:37:19.16ID:l1NoBYC6
>>164
もちろんC++は整数などに限ればconstで静的な定数となるが
それ以外C++のconstは定数ではなく静的にコンパイル時に定まらない
そのため真のconstを表すためにconstexprというキーワードを新たに用意する本末転倒な状況となった
2023/03/06(月) 22:52:19.69ID:1935XsNt
以下の2つは矛盾してないかい?

>>163
>実行するたびにあるいは関数を呼ぶたびに値が変わりうる変数(＝静的に値が定まらず変わりうること)に対して、
>変数がimmutableであることを間違えてconstと付けてしまった

>>164
>もちろんC++は整数などに限ればconstで静的な定数となるが

2つ目はなるんだっけ?
2023/03/06(月) 22:53:11.95ID:1935XsNt
>>165
>そのため真のconstを表すためにconstexprというキーワードを新たに用意する本末転倒な状況となった
「本末転倒」とは違うと思うよ
2023/03/06(月) 23:09:16.19ID:h8dbx3na
>>166
C++で何らかのクラスのインスタンスを作ってconstに入れることを考えてみるとわかりやすいよ
もちろんこのconstのインスタンスはコンストラクタの引き数の値によって変わるから静的な定数じゃないよね
つまり単なるimmutableな変数に過ぎないわけだけどC++はそれに対してconstと間違えて名付けちゃった
だから本当の定数に対してconstexprと名付けることになった有名な話だよ
2023/03/06(月) 23:20:34.22ID:1935XsNt
>>168
>つまり単なるimmutableな変数に過ぎないわけだけどC++はそれに対してconstと間違えて名付けちゃった
C++のconstは単なる`constant'の意味で
静的な定数という意味でないというだけなのでは?
本当に「間違えて」名付けたのかな?
俺にはC++のconstにあなたが「間違えて」静的な定数という意味を
期待しているだけに見えるのだが?
2023/03/06(月) 23:31:32.57ID:l1NoBYC6
>>169
環境によって実行毎に、または、関数の引き数によって関数が呼ばれるごとに、>>168の示してる例だと値が変わりうる
その変わりうるものに対して、C++がconstと付けたのは失敗としか言いようがないのではないか
そしてC++は本当にconstantなものに対して、後からconstexprと付けざるをえなかったことが、C++の失敗を誰の目にも明らかにしている
2023/03/06(月) 23:33:40.69ID:1935XsNt
>>170
>環境によって実行毎に、または、関数の引き数によって関数が呼ばれるごとに、>>168の示してる例だと値が変わりうる
これはどいう状況か分かりにくい? ソースで書いてみて
2023/03/06(月) 23:42:46.60ID:l1NoBYC6
>>171
関数に渡ってきた毎回変わりうる引き数を使ってそれを渡してインスタンス作成してconstに突っ込む場合でもよい
あるいは環境変数やargv使ってインスタンス作成でもよい
いずれも毎回インスタンスの値が変わりうるため定数ではないがC++ではconstと付けてしまった
そして本当の定数にconstexprと付けた
2023/03/06(月) 23:47:46.47ID:1935XsNt
>>172
曖昧さを避けたいのでソースで書いて
反論する
2023/03/06(月) 23:52:15.11ID:p7JhiTtQ
ただし*const Tのconstだけはコンパイル時定数の意ではなく、C++と同じで書き換えを行えないという意味です
一貫性がありませんね
2023/03/06(月) 23:56:33.22ID:h8dbx3na
>>169
数字でも物理でも定数は静的に定まるものだよ
でもC++はconstをimmutableの意味で間違えて名付けてしまいました
そして定数を表すためにconstを使えなくなりconstexprと名付けたという誰でも知ってる有名な話だよ
2023/03/07(火) 00:01:46.05ID:gZ1LpnCS
>>175
>でもC++はconstをimmutableの意味で間違えて名付けてしまいました
とあなたが思っているだけではないかな?
C++のconstにあなたなが「間違えて」静的に定まるものを期待しているだけでは?
2023/03/07(火) 00:09:47.95ID:6eBCzRN0
言われてみれば数字や物理で定数は静的に定まる値だな
どうせC++で静的に定まる値を示すキーワードも必要となるんだから素直にそれをconstにしておくべきだったか
設計ミスだな
2023/03/07(火) 00:57:00.01ID:UNnBBHt0
>>175 >>177の頭が設計ミス
179デフォルトの名無しさん
垢版 |
2023/03/07(火) 01:08:45.38ID:gZ1LpnCS
>>177
>言われてみれば
www
2023/03/07(火) 01:27:52.75ID:phr7A4jU
immutableとconstantの違いを区別できていない人がimmutableに対してconstと命名してしまったのかな
そのためconstantに対してconstと命名できなくなってconstexprと命名したと
2023/03/07(火) 01:31:47.04ID:CjRtBzJ1
同じ言葉や字句でも言語ごとにその概念が指すものは異なる
相対主義的に考えなさい
相手の価値観を理解しなければ説得力は生まれません
2023/03/07(火) 02:21:18.68ID:oSHTm7sl
・y = ax　(a=10である)
aをimmutableと呼ぶかconstantと呼ぶか
・y=f(a)　(a=10である)
f(a)をconstantと呼ぶかconstant expressionと呼ぶか

まあ考え方次第だよな
2023/03/07(火) 02:29:20.82ID:phr7A4jU
>>182
上はxが実行時に値がわかる変数なんでしょ？
それならconstantには成りえないんじゃない？
2023/03/07(火) 08:05:58.19ID:oSHTm7sl
>>183
かかるaについてなんと呼ぶかって話だから別にxについて気にする必要は無いよ
2023/03/07(火) 08:10:06.41ID:X5urLXgj
>>182
理解できていなさ過ぎだろｗ
2023/03/07(火) 08:16:15.53ID:X5urLXgj
>>182
あと例を出すにしても
整数は特殊でconstexprでなくconstでも静的定数になる例外だから例として最も不適切
2023/03/07(火) 09:21:06.13ID:hj+ftEk+
自演してRustゴリ推し他言語叩きをしてるのは
複製おじさんと呼ばれてるRustスレでは有名な荒らし
しかもそいつが「RustJP公式 」の中の人で間違いなさそうって話だから手に負えない
2023/03/07(火) 10:27:35.30ID:QCj9HjAv
>>187
「RustJP自称公式 」なのでなんの問題もない
189デフォルトの名無しさん
垢版 |
2023/03/07(火) 11:40:31.33ID:gZ1LpnCS
>>180
それはお前用語なんじゃね?
2023/03/07(火) 11:55:27.75ID:CdvGJ9oA
y = ax
y も a も x も変数としか言いようがない
2023/03/07(火) 12:47:12.28ID:CHI/c7S+
aを10としたときにコンパイル時
最適化してしまうかaという入れ物残しとくか更にはf(a)も計算して結果だけ使うか
2023/03/07(火) 21:59:54.08ID:6AJw5hNk
整数はconstやconstexprの有無に関係なくコンパイル時に最適化されるから整数を持ち出して来ても意味がない
C++ならクラスのインスタンスを生成する場合などを考えるとわかりやすい
コンパイル時点でそのインスタンスを定数化できる時にconstexprを使い静的に定数となる
そうでなく実行時にならないと値が定まらない変数となる時はconstexprを使えない
その変数がimmutableつまり生成以降は値を変更できない時はconstを使う
193182
垢版 |
2023/03/07(火) 22:28:59.56ID:oSHTm7sl
constというものの表現を語るうえで言語依存しない形で書いただけなので
少数でも文字列でも適当に読み替えてね
2023/03/08(水) 00:26:55.95ID:Ax/TB2dR
>>192
C++の命名ミスだな
定数にconstと命名すべきであり
immutableな変数にconstと命名すべきでなかった
2023/03/08(水) 00:36:06.87ID:o1WhyvRq
壊れたテープレコーダは生まれてくるべきでなかった
2023/03/08(水) 00:46:11.75ID:+ZMcnEdg
事後諸葛亮
2023/03/08(水) 01:01:29.10ID:qkb67oYH
同じ事しか書けない命名君はGC連呼厨なのか
2023/03/08(水) 01:22:37.49ID:9h+oJZcX
結果的に後からみればC++の命名ミスなんだろうが歴史的経緯で仕方ないだろ
昔はimmutableとconstantの概念の区別が曖昧だった
2023/03/08(水) 01:53:12.26ID:CbNEQcSB
どうしても`immutable'を使いたければマクロ定義すれば?
#define immutable const
2023/03/08(水) 02:01:56.79ID:3vDDzLqz
Rustはconstをimmutableとcompile-time constantの両方の意味で使うので一貫性が無い
>>174
2023/03/08(水) 07:29:50.16ID:OMAPV4fU
>>200
Rustでconstは常に静的な定数を表す
*constはconstとは全く別のものであり予約語を最小限にするための使い回し組み合わせ

両者は種別も異なるため混乱することもない
constは定数の定義なのでこの位置に来る
let foo: i32 = 12345;
const FOO: i32 = 12345;

*constは生ポインタの型を示すのでこの位置に来る
const BAR: &i32 = &FOO;
const BAZ: *const i32 = &FOO;
このように両者は全く別物で出現位置も異なり共存もでき混乱することもない

この生ポインタはunsafe Rustでしか使わないため通常は出て来ない
そのために新たな予約語を消費するのは馬鹿げているため既存の組み合わせという合理的な選択をした
2023/03/08(水) 07:30:57.28ID:/qygPgTx
constはCからの流れだしな。
元々Cがシステムプログラミング向けだったことを思えば、「リードオンリーセクションに置け」っていうくらいのつもりだったんだろ。
定数は#defineで指定しろって感じかな。
2023/03/08(水) 08:49:19.07ID:w2ee/I/N
>>201
> この生ポインタはunsafe Rustでしか使わないため通常は出て来ない

safeの範囲で普通に使うけど
参照の同一性比較とか書いたことないの？
2023/03/08(水) 09:00:01.62ID:OMAPV4fU
>>203
参照の比較は生ポインタ直接比較ではなくstd::ptr::eqを使うのが行儀良いマナー
参照を渡せば*constに自動でcoerceされるためコードに*constを記述する必要はない
2023/03/09(木) 14:43:18.74ID:lc0skjdv
本題に戻ろう
206デフォルトの名無しさん
垢版 |
2023/03/09(木) 19:02:01.89ID:33ubz+zP
Rustは優秀なんだろうけど、言語仕様が難解なのと、「〜の分野ならRust」と言えるものがないから広がりにくいんだろうね
2023/03/11(土) 11:27:51.97ID:E47xdjIQ
それにRustは左翼的な弱者救済的な雰囲気が漂う。
VBも同じ理由で使ってるだけで駄目プログラマとみなされていったから、
同じようにRustを使ってるだけで駄目プログラマ決定されてしまう気がする。
2023/03/11(土) 11:29:57.74ID:E47xdjIQ
Excelもそうだ。Excelを使ってるだけで弱者扱いされてしまうようになっている。
VBもそうなったから、中味はそう変わってないのに名前を変えてC#にされた。
しかし、だんだんと、C#もVBと同じように馬鹿プログラマ専用言語とみなされる
ようになってきてる。
Rustもきっとそうなるだろう。
2023/03/11(土) 14:27:01.34ID:lvldJuuV
Rustも悪くないけど日本語のドキュメントが酷すぎるかなあ。
たとえば第七章のパッケージとグレートの話とかでも
-------
最初に学ぶモジュールシステムの要素は、パッケージとクレートです。 クレートはバイナリかライブラリのどちらかです。 クレートルート (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に尋ねたら複数入ることもあると断言されたけど。
2023/03/11(土) 14:31:08.67ID:+PZMhSrI
面倒ならとりあえずDeepLに掛ければ良いのにね
> モジュールシステムで最初に取り上げるのは、パッケージとクレートです。
>
> クレートは、Rustコンパイラが一度に考慮する最小のコード量です。cargoで
> はなくrustcを実行し、1つのソースコードファイルを渡したとしても（第1章
> の「Rustプログラムの作成と実行」でやったように）、コンパイラはそのファ
> イルをクレートと見なします。
2023/03/11(土) 16:27:23.47ID:BtFFfdHV
>>209
ひどすぎるのには同意するが
それはボランティアによる非公式な翻訳で
識者による監修や査読がされてないから
質が低いのは当然といえば当然

一部専門用語を除くと機械翻訳のほうが
それよりはマシな訳になることが多いので
多少英語が苦手でも公式を見たほうが断然効率がいいよ
2023/03/11(土) 16:39:48.49ID:47WJOH0Y
>>209
7章の最初のページ見ればそれぞれどういう関係なのか一目瞭然
単数形複数形の違いを丁寧に訳してなければ重要な意味が日本語訳では消えてるかもね

・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
2023/03/11(土) 17:28:34.44ID:/GMTezZ0
>>209
そのページは原文の2年半以上前の状態止まってる
日々改善されてるOSSで数年単位の遅れがあると全く役に立たないから
現状はRustの日本語ドキュメントは無いものと思っておいたほうがいい
2023/03/11(土) 18:00:56.32ID:bkYlWMhE
>>213
原文のいつの状態を反映した訳なのか全然管理できてないらしいからね
アップデートは望み薄
2023/03/11(土) 19:45:03.63ID:+PZMhSrI
規格がないので二流感が拭えない
かと言ってC++が登場したときのように
今はプログラミング言語の実装が
いくつも出てくる状況でもないのかな?
2023/03/11(土) 22:12:18.37ID:GtLfWJGz
>>215
C++での混乱と失敗を繰り返さないことが重要
217デフォルトの名無しさん
垢版 |
2023/03/11(土) 22:59:17.84ID:+PZMhSrI
実装は複数あった方がメリットが大きいよ
2023/03/11(土) 23:05:20.16ID:2/rFH0pr
>>214
マジかよw
たかだか100個程度のファイルが管理できないってどんだけよ
2023/03/11(土) 23:19:14.88ID:ChsfUoNW
実装が複数あることはメリットもあるがデメリットも多くユーザを混乱させてきた
一方で言語仕様とその実現方法が確定して枯れた時は複数実装のメリットが上回る
Rustについては更なる理想の言語に向けて公開todoリストも多くまだ発展段階なので複数実装は向いていない
もちろん従来的な使い方ならば現状のRustで既に十分に利用できる
2023/03/11(土) 23:24:45.49ID:uRw385pv
>>218
ユーザーフォーラムのしかもたった二人の回答を「公式コミュニティの見解」にしてしまうオツムの人達だからさ一般常識があると思ったら大間違い
2023/03/11(土) 23:30:52.30ID:+PZMhSrI
>>219
3行目は全否定しておく

CやC++に複数の実装があった第一の要因は開発ツールが売れたという背景がある
Rustに限らず開発ツールは最早ビジネスとしては成り立たなくなってしまった
2023/03/11(土) 23:34:33.13ID:2T5UBlcf
>>220
あれ痛いよね
でもピン留めして晒し上げるのはさすがにどうかと思うわ
2023/03/11(土) 23:39:25.95ID:ChsfUoNW
Rustは公式が提供するcargoやrust-analyzerで開発環境は十分だもんな
もちろんrust-analyzerはLSPなのでVScodeなどの既存の統合開発環境で使える
2023/03/11(土) 23:51:17.37ID:3ENT9RfU
>>220
Rustユーザーの大半は英語のドキュメントを直接見てるからな
同じRustユーザーというだけであのリテラシーレベルと同類扱いされるのは誠に遺憾
2023/03/12(日) 06:07:53.91ID:b0Zzr0Fl
>>212
一目瞭然ってことはないよ。
わかってるやつにはわかるっていうレベル。
特にmodule and use以下で戸惑うと思うよ。

Rustはプログラミング言語としてはCとかで神経使っていたところで楽させてくれる感じだけど、新人を呼び込むにはドキュメントがまずいかなあ。
2023/03/12(日) 09:19:37.91ID:XJpeOWKz
前にもこれどこかで同じレスしたことあるけど
Javascriptってドキュメントすっごい充実してるよな
2000年以前はHTMLとJavascript一緒になった解説本の最後の方に申し訳程度に乗ってたくらいで
あとは某とほほサイト見るくらいしかなかったけど

最近ちらっとみたらすごいのな
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/find
これは適当にクリックした特に選んでない一例だけど
ちょっと過剰なくらい説明と例が乗っててスゴイと思ったわ
Rustにここまでを要求したほうがいいとも思わんけど
いつかみんなが使う言語になったときはそうなってるのかもしれん
227デフォルトの名無しさん
垢版 |
2023/03/13(月) 09:18:51.45ID:65XUJIc/
udemyからrust勉強すれば良いと思う
228デフォルトの名無しさん
垢版 |
2023/03/13(月) 11:30:57.14ID:QpsvkUdl
C++は既に意味不明な域に来ていて、誰も新規に習得しようとはしないだろう
2023/03/13(月) 12:04:07.60ID:wwEuDEVq
>>226
ほんと。自分もノーマークだったけどすごいね。
Rustも「英文ドキュメント読め」みたいに突っぱねいようにしなくちゃね。

Rustのサイトで各国語にトランスレートされたもののリンク先の更新日付を眺めてると、中国語版に負けてる感じだね。
2023/03/13(月) 12:11:38.79ID:CJ8zcgHs
中国なんてどうでもいい
2023/03/13(月) 12:13:17.03ID:bP2+YJD9
MDNもMDNで英語読まないとやってられない記事はちょいちょいあるけどね
CSSのpositionとか
2023/03/13(月) 14:43:06.35ID:wwEuDEVq
少なくとも手解き用として、TheBookの日本語版ではねえ。
で、メモリ安全ってことだけをひたすらリピートするだけでは、新しい人は来ないでくださいと言ってるようなもん。

まあ、その方がチンケな優越感に浸れて良いのかもしれないけど。
2023/03/13(月) 15:10:59.37ID:cwbZasxH
>>231
Wasmのところも日本語版は古い情報のままなので肝心な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
2023/03/13(月) 15:27:59.03ID:kyo182dJ
メモリ安全ってのは個人が始める動機としては弱い
スマートポインタで充分なんだし
チームで書くときにメモリ管理が怪しい奴が混ざり得るときに
Rustで書くことを強制されるってシチュエーションはありえるかもね
2023/03/13(月) 15:42:51.26ID:sbzZb6rB
>>234
両方書いてると差は歴然
Rustは可読性もよいし開発効率もよく
特に実行時デバッグが激減するのも大きい
やむをえない場合を除いてC++を使い続けるメリットはない
236デフォルトの名無しさん
垢版 |
2023/03/13(月) 15:54:03.52ID:kyo182dJ
>>235
>Rustは可読性もよいし開発効率もよく
そんなのは人によるとしか言えない
所有権に割と馴染みがあるC++プログラマはともかく
他の言語からだと文法の解離に抵抗はあるだろうね
これからプログラミングを始めようという人は
特にRustだからという抵抗はないだろう
実績が増えればRustからって人が増えるかもね
237デフォルトの名無しさん
垢版 |
2023/03/13(月) 16:03:04.23ID:UI2Ct8M3
C++はコンパイラ買う時にデバッグツールもあって、そこでメモリリーク含む大体の解析が出来ることが多いから、今の所メモリ安全で困ったことはないな。
それよりもRustはまだ新しいから、何かしら思わぬ脆弱性が潜んでいることも考えて、まだ弄りながら様子見って感じ
238デフォルトの名無しさん
垢版 |
2023/03/13(月) 18:05:23.37ID:QpsvkUdl
C++の有料コンパイラってそんなすげえのか？
2023/03/13(月) 18:37:31.12ID:cwbZasxH
>>236
初心者や素人はC++でもRustでもなくBASICやPythonをやっていればいい
C++もRustも書きこなせる人なら自明なようにRustがはるかに効率いい
2023/03/13(月) 19:04:23.67ID:sbzZb6rB
>>237
デバッグツールを持ち出さなくてもRustはコンパイル時点でほとんど解決する点で圧倒的に優れている
Rustはメモリ安全性だけでなくデータ競合がないことがコンパイル時点で保証される
ポインタ以外の汎用的なヌル安全とエラー処理忘れ防止もRustは標準ライブラリ全体でOptionとResult利用により保証される
C++と比べて開発効率が段違いに良くなる
2023/03/13(月) 19:17:45.07ID:9XZC5W3h
C/C++のメモリリークと隣合わせなスリルがいいんだよ
Rustなんて補助輪付きの言語はプロのプログラマッには温すぎる
コーディングに自信がない奴や素人向けだな、Rustは
242デフォルトの名無しさん
垢版 |
2023/03/13(月) 19:49:16.47ID:zhi7FkgJ
>>241
C/C++はプログラマとして成長させてくれるよね
2023/03/13(月) 19:51:01.09ID:cwbZasxH
>>241
C++はデバッグ時間のムダ
2023/03/13(月) 20:02:48.32ID:lNJwESa5
別にスマートポインタでええがな
2023/03/13(月) 20:04:22.18ID:lNJwESa5
Rustは規格が出てからだな
2023/03/13(月) 20:07:14.22ID:4NzLTP/2
マ板でやれバカども
2023/03/13(月) 20:22:48.71ID:4VuAJC20
>>239
変わった言語なので
まず初めに学んだほうが先入観がなく覚えられるよ
そのためにも日本語のドキュメントは
整備したほうが良い
248デフォルトの名無しさん
垢版 |
2023/03/13(月) 20:39:22.66ID:RfKK3GLn
トラ枝 5月号 Rust 特集
2023/03/13(月) 20:45:38.95ID:sbzZb6rB
>>243
その通りでC++は無駄なデバッグ時間が必要となるけど
テストで発見できなかった分はデバッグもされず実行時のセキュリティ含めたバグとして残ってしまう
Rustならばコンパイル時点ですべて排除できる

>>244
勉強不足すぎだ
C++のスマポで解決できることはRustで解決できることのほんの一部にすぎない
250デフォルトの名無しさん
垢版 |
2023/03/13(月) 21:04:50.75ID:kyo182dJ
>>249
>勉強不足すぎだ
>C++のスマポで解決できることはRustで解決できることのほんの一部にすぎない
他は?
2023/03/13(月) 21:41:54.90ID:Lx/25M/K
>>250
そんなことも知らずにこのスレで書き込み続けているのかよ
他の人たちの書き込みを読んでないのかよ
252デフォルトの名無しさん
垢版 |
2023/03/13(月) 21:46:41.78ID:kyo182dJ
>>251
他は? GCしか書けない人なのかな?
2023/03/13(月) 22:00:51.65ID:sbzZb6rB
>>250
既にたくさん書いて伝えた
理解できなかったのか？
2023/03/13(月) 22:16:19.15ID:P8sbSRo2
絵に描いたような負け犬のセリフw
255デフォルトの名無しさん
垢版 |
2023/03/13(月) 22:35:49.32ID:kyo182dJ
>>253
本当にGCしか知らないんだな

>>249
>勉強不足すぎだ
熨斗をつけてそのままお返ししよう
2023/03/13(月) 22:38:39.16ID:Lx/25M/K
>>252
C++もRustもGC無いぞ
257デフォルトの名無しさん
垢版 |
2023/03/13(月) 22:43:20.72ID:kyo182dJ
>>256
んなことぁ誰でも分かってる
2023/03/13(月) 23:26:56.50ID:sbzZb6rB
>>255
GC言語も使うしC/C++/Rustも使う
速さと省メモリの点でGC言語は不利だから使い分ける
259デフォルトの名無しさん
垢版 |
2023/03/13(月) 23:40:00.84ID:kyo182dJ
>>249
>勉強不足すぎだ
>C++のスマポで解決できることはRustで解決できることのほんの一部にすぎない
だから他は?
2023/03/13(月) 23:52:11.42ID:9+eE28f9
>>244
C++スマートポインタは
unique_ptrは使わずともRustでは標準で全て自動解放されるよ
shared_ptrはRustではスレッド内で使えるRcとスレッド間で使えるArcに分かれていて効率的だよ
2023/03/14(火) 00:08:40.65ID:nARWep6y
>>260
別にunique_ptrやshared_ptrでええがな
難しくないよ

>shared_ptrはRustではスレッド内で使えるRcとスレッド間で使えるArcに分かれていて効率的だよ
効率的をも少し詳しく!
262デフォルトの名無しさん
垢版 |
2023/03/14(火) 00:17:28.43ID:g2aa4i95
C/C++でスレッドセーフな並列処理を作ろうと思ったら一苦労だけど、Rustだとそうでもないんかな。
2023/03/14(火) 00:51:48.86ID:mRkuEIyQ
>>261
shared_ptrは常に排他制御されコストが高い
共有を増減すると排他制御のコストがかかる
さらに単なる受け渡しも要注意でmoveしないとそのコストが無意味に余分にかかってしまう
一方でRustは排他制御するArcとしないRcの2つが用意されていてそれらの問題なく使い分けられる

>>262
Rustはコンパイルが通った時点でデータ競合がないことを保証されるのでかなり楽
2023/03/14(火) 00:58:40.53ID:Ff/IlIXh
うわっw
排他制御の意味も知らないのかよこいつw
2023/03/14(火) 01:09:54.31ID:gRogmLJe
shared_ptrは排他制御してリファレンスカウンタの増減を行うからスレッドセーフ
その代わり重い
2023/03/14(火) 01:26:54.27ID:nARWep6y
>>263
なるほどね
std::shared_ptrには参照カウンタの排他制御をオフにする機能はなかったかな?
boost::shared_ptrだと美しくないけどBOOST_SP_DISABLE_THREADSマクロで切り替えられる
最近使ってないがLoki::SmartPtrは確かテンプレートパラメータで切り替えできたかな?
2023/03/14(火) 01:58:37.91ID:gRogmLJe
Rustでは共存可能
スレッド内のみの共有はRc
スレッド間での共有はArc
切り替えでなく最初から二種類が用意されるべき
2023/03/14(火) 02:06:25.73ID:nARWep6y
>>267
同意
std::shared_ptrもLoki::SmartPtrみたいに
テンプレートパラメータで切り替えできれば良いのにね
ただしstd::shared_ptrを規格に入れた時点で
既にboost::shared_ptrもLoki::SmartPtrもあったことを考えると
参照カウンタが競合する機会はほとんどないという見立てで
実装を単純化したのかなと予想する
誰か経緯を知らんかな?
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>;
2023/03/14(火) 02:59:21.97ID:u9OB+g2b
shared_ptr単独では完全なスレッドセーフではない、という問題もある。
shared_ptrで排他制御される対象はreference counterの増減だけであり、指している値の読み書きはもちろん排他制御されない。
したがってshared_ptrはスレッドセーフだから安心だと誤解していると、危険なプログラムが出来上がるリスクがある。
C++ではプログラマーがこれらの誤解や見落としやミスを全くしないことを求められ、それに依存するためプログラムの安全品質は危うい。

Rustではその点も安全で、Arc<T>はTへの書き込みが出来ないため、排他制御の問題は起きない。
書き込みしたいならば、Arc<Mutex<T>>やArc<RwLock<T>>など必要となる排他制御の種類に合わせて選び、組み合わせて利用する。
それら組み合わせにより、Tへの書き込みができるようになるが、必ずロックで排他制御されるため問題は起きない。
たとえプログラマーが見落としやミスや使い間違えをしても、Rustコンパイラがエラーを出し、該当箇所を教えてくれるため、常に安全性が保証される。
2023/03/14(火) 03:15:26.07ID:nARWep6y
>>270
Mutex <T>を書けば良いのではないかな？
2023/03/14(火) 03:19:38.24ID:nARWep6y
>>270
>shared_ptrで排他制御される対象はreference counterの増減だけであり、指している値の読み書きはもちろん排他制御されない。
>したがってshared_ptrはスレッドセーフだから安心だと誤解していると、危険なプログラムが出来上がるリスクがある。
想定してるレベルが低すぎる
マルチスレッドで書くやつにそんなやつはいない
議論が無理やり過ぎ
2023/03/14(火) 03:33:56.57ID:u9OB+g2b
>>272
その件に限らずすべてにおいて、勘違い、見落とし、ミスなどは発生する。
複雑化したときにmutex忘れも、shared_ptr忘れも、間違えてunique_ptr使いも、その他のミスも、何でも実際に起きている。
Rustではそれらが起きてもコンパイラが通さないことで、常に安全性が保証され、無駄なデバッグを避けられる。
C++では無駄なデバッグを招くか、もしくは、そのままリリースしてセキュリティの穴が生じてしまう。
現実にC++が多数の問題を引き起こしてきた。
2023/03/14(火) 12:05:32.83ID:CPf3ZEOa
暇を持て余すニートの日記
2023/03/14(火) 12:21:44.83ID:nARWep6y
>>273
「Rustはコンパイルが通っていればマルチスレッドで
競合問題が起きないことが保証される」
これで正しい? 正しいとすれば
マルチスレッドを習得したときの苦労を考えると有用なので
新しくプログラミングを始める人には勧めたい動機になる
俺自身は困ってないので使おうとはあんまり思わんけどね
276デフォルトの名無しさん
垢版 |
2023/03/14(火) 12:39:04.29ID:RkFbHwTA
Rustが流行るとすればどの分野になるんだろうか？
一番は安全装置とかに使われる小規模な組み込みソフトかな。
CPUとか開発環境とかがまだ整ってないだろうから、ゆっくりだと思うけど
2023/03/14(火) 12:50:59.56ID:nARWep6y
普及するのにはキラープロダクトが必要
UNIX（C）やMFC（C++）や.NET（C#）のように
大手がプロダクトに採用してトップダウンで流行らせるしか
普及の道はないと思う
ゆっくり普及なんてのはないと思う
2023/03/14(火) 19:34:32.70ID:/poSvH9Z
Visual Studio Rust .Netがでるまで待とう
2023/03/14(火) 19:40:00.62ID://qYwEcn
あらためてJavaって良い言語だなって思うわ
ここ十数年だと人類一番の功績じゃね

良い点：
シンプルさ。C#で言う値型を入れようかどうか迷ったときもあったんだろうけど（想像）、
プリミティブと参照型変数の二個だけでやってくという線引がセンスある。

悲しい点：
立てまし。個人的にはジェネリクスもいらんかった。
C++のテンプレートを潔く排除して出てきたのすごいすっきり感あった。
でもあとでジェネリクスは押し負けて？付いてきちゃったけど。
あと貧相な貧相なラムダ式。クロージャを期待したけど結局はanonymous classのといっしょ。

異論は無いと思う
2023/03/14(火) 22:31:24.61ID:CPQICLea
>>275
Rustはマルチスレッド時でもマルチタスク時(＝グリーンスレッドをRustではタスクと呼ぶ)でも
データ競合を起こさないことが静的に保証されている
唯一のプログラミング言語
281デフォルトの名無しさん
垢版 |
2023/03/14(火) 23:07:45.86ID:5gRl/D4e
んなわけねえだろ
2023/03/14(火) 23:17:29.22ID:CPQICLea
>>281
Rust以外の言語があるならば教えて
2023/03/14(火) 23:54:49.43ID:AgG33ThB
Ownershipの元ネタのCycloneはやってねーのけ？
284デフォルトの名無しさん
垢版 |
2023/03/15(水) 02:10:25.53ID:itMePwRG
Rust、コンパイル遅いっていうけどどれ程なの？C++と比べて遅い？
2023/03/15(水) 02:53:43.28ID:aLgn/lBf
コンパイル後の実行デバッグ時間が激減したのでトータルで要する時間は減少した
2023/03/15(水) 03:26:18.55ID:DXTHIxnh
現状はバカがイキる為だけに持ち上げられるRust
万一普及したとしてバカが使いこなせるはずもなく
287デフォルトの名無しさん
垢版 |
2023/03/15(水) 07:08:24.89ID:SNoM8taV
今まで C++ で制御して成功率 99.99% だった
ロケットをわざわざ Rust で描き替えて墜落しても
Rust は悪くない悪いのは GC のせいだと言い張るのが
Rust 信者
288デフォルトの名無しさん
垢版 |
2023/03/15(水) 09:03:13.60ID:n0l+w21l
>>277
Android(Java)
iOS(Objective-C++)
2023/03/15(水) 09:51:38.96ID:d2iGalsS
ロケットでGCは無いわ
2023/03/15(水) 10:13:26.89ID:aLgn/lBf
>>287
C++もRustもGCないよ
2023/03/15(水) 10:52:34.36ID:d/hulDPr
プログラミング言語「Rust」は世界のセキュリティレベルを底上げする
https://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で書く範囲を広げることで段階的にセキュリティ上の恩恵を受けようという戦略である。
2023/03/15(水) 10:57:42.49ID:QVyWv/mn
>>280
デッドロックは静的検出はできないでしょ?
2023/03/15(水) 12:50:04.82ID:FGvum1vT
やっぱりC++だよね
294デフォルトの名無しさん
垢版 |
2023/03/15(水) 15:17:28.42ID:6d2zOTAf
段階的に置き換えることができるだけのお金と能力のあるエンジニアを確保できるアメリカの大企業ならいいんだろうけどね
両方無い日本企業には無理無理カタツムリ
295デフォルトの名無しさん
垢版 |
2023/03/15(水) 19:11:32.56ID:Raq+Bs5u
能力ない人の発想だね
2023/03/15(水) 19:46:51.43ID:rzl5B1H1
まず初めにの人はRustは選ばんと思う
Rustがターゲットとしているところで
プログラミングをやるなら
現状でCの習得は避けて通れない
となると学習コストの問題で
文法がほぼ包含関係にあるC++を選ぶことになる
OSの基盤からRustにしないと一向に増えないよ
2023/03/15(水) 19:49:13.81ID:N9nUYl96
>>3で終わってんだよこのスレ
うだうだ続けたい奴はコード書く能力もないからここで自己顕示欲発揮しちゃうんだろｗ
2023/03/15(水) 19:50:50.82ID:zbLR3nEh
能力ある人からRustへ移行していってる

>>294
ほとんどのシステムは複数のプログラムから構成されているため
それら各機能をグレードアップで更新するときにRustへ書き換えることで進んでいる
もちろん新規システムは最初からRustで書くことが多くなっている
2023/03/15(水) 19:55:49.97ID:rzl5B1H1
Rustユーザが増えるストーリーは
トップダウンで基盤を整備するしか有り得ない
Cと文法が乖離してるのはメリットもあるだろうけど
普及にはデメリットとして働いている
2023/03/15(水) 20:02:03.89ID:zbLR3nEh
セキュリティ観点から新規システムはC/C++禁止でRust必須が要件になっていってる
この動きはそれが出来るところから着実に進んでいるので止めようがない
301デフォルトの名無しさん
垢版 |
2023/03/15(水) 20:52:20.68ID:QVyWv/mn
>>300
>新規システムはC/C++禁止でRust必須が要件
どこで?
2023/03/15(水) 21:00:17.63ID:QVyWv/mn
デファクトスタンダードの強さは
MSを見ていればまぁ自明だわな
303デフォルトの名無しさん
垢版 |
2023/03/15(水) 21:15:24.65ID:itMePwRG
結局コンパイルってどのくらい遅いの？
2023/03/15(水) 21:55:22.51ID:46PmQs8i
今日のMicrosoftの発表が面白い
発表デモでなぜか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に変換することができました。
2023/03/15(水) 21:58:57.19ID:46PmQs8i
>>304
正しい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
2023/03/15(水) 22:07:43.40ID:QVyWv/mn
Rust普及はMSの動向が鍵だよ
自然に増えるもんじゃない
2023/03/15(水) 22:20:44.44ID:46PmQs8i
Microsoftは自社製品のRust化を進めると同時に普及も進めてるね
日本語ドキュメントも充実してる

Rustを使用したWindowsでの開発
https://learn.microsoft.com/ja-jp/windows/dev-environment/rust/overview
2023/03/16(木) 00:10:36.78ID:srO8KDRm
PriorityはF#の次だな
https://learn.microsoft.com/ja-jp/windows/dev-environment/
2023/03/16(木) 00:12:05.34ID:srO8KDRm
「C++とCの概要」の位置に来ないと普及には程遠い
2023/03/16(木) 00:25:01.88ID:AJSi61e9
RustがC++と同じ土俵へ採用されてしまった時点で
何もかも優れているRustの勝利

疑われる「C++」の安全性、今後の動きはどうなる
https://japan.zdnet.com/article/35199018/
2023/03/16(木) 06:24:59.05ID:R4dgmdEC
次の10年はRustが取った、となると、APIがRustになる
ならば、RustなAPIにC++がきちんと接続できるようになってもおかしくない
そうすると、Rustが実績を積んだ「正しい縛り」を、C++でも使えるようになってくるんではないだろうか

もうそういう試みある?
2023/03/16(木) 08:50:45.88ID:zwODLYWH
何言ってんだこのバカ
2023/03/16(木) 09:08:29.35ID:wZlU7tIR
>>311
既にRustとC++の相互呼び出しは実現されているが
Rustから見てC/C++部分は当然unsafe扱い
最終的にC/C++部分が無くなる形で完成することになる
2023/03/16(木) 09:15:14.89ID:3C3pOHVn
OSもアプリケーションも、pure Rustになるんだろ、理想論としては
だとしたら、境界面であるAPIには、縛りにかかる属性情報が露出するはず
C++がそれに対応できないなら、今後C++ではアプリケーションを書けないことになってしまう
2023/03/16(木) 09:54:57.99ID:hwbAfXXm
慣れて使いこなせるようになると、
Rustの方が書きやすいとほとんどの人が言うほど差があるのだから、
C++がいずれ消えるのは間違いない。
316デフォルトの名無しさん
垢版 |
2023/03/16(木) 10:39:34.81ID:N2/NSeFa
>>298
>能力ある人からRustへ移行していってる
まるでKENYAの作文だな
2023/03/16(木) 10:43:46.43ID:fxj0X8UB
Rustからインラインアセンブラでレジスタいじって安全性が担保されつつC++と遜色ないならもういらんわな
2023/03/16(木) 10:45:31.49ID:X3XJCWQc
ここでぐちゃぐちゃ言っても何も変わらないからさっさとC/C++で書かれた森羅万象の移植やってこいよ
2023/03/16(木) 10:57:52.25ID:n4rBBOEi
>>317
もちろんRustの変数を使う形でインラインアセンブリをRustでは記述できるが
当然ながらRustコンパイラによる保証範囲外となるunsafe部分になる
Rustはunsafe部分のみ人間が安全性を担保すれば全体についてはRustコンパイラが保証する形で役割分担できる
その点でプログラム全体が常にunsafe状態となってしまうC/C++とは根本的に異なる
320デフォルトの名無しさん
垢版 |
2023/03/16(木) 10:59:13.64ID:mkPG1w5O
>>303
ここの最後の方に載ってるよ
https://quick-lint-js.com/blog/cpp-vs-rust-build-times/
OSによっても違うみたいだけど、C++の方がちょっと早いくらいだね
321デフォルトの名無しさん
垢版 |
2023/03/16(木) 11:04:29.29ID:srO8KDRm
まぁRustでスクラッチから書かれたOSでWindowsやiOSやAndroidを取っ替えるか
スマホみたいな何らかの新しいハードウェアが誕生して
それがRust製で書かれたOSで制御されている状況にならんと普及はせんよ
2023/03/16(木) 11:11:37.43ID:r79frV++
>>321
頭の弱い子ですね
JavaやPerlやJavaScriptやRubyやPHPやPythonなどで書かれたOSは普及していませんが
それらの言語は普及しました
323デフォルトの名無しさん
垢版 |
2023/03/16(木) 11:19:37.68ID:srO8KDRm
>>322
JavaやPerlやJavaScriptやRubyやPHPやPython使ってるところで普及はするかもね
じゃこれで良い? ニッチと言って分かるかな?
2023/03/16(木) 11:22:05.57ID:3C3pOHVn
マイコンでRustを使う試みは結構普及してるみたいだね
2023/03/16(木) 12:18:46.17ID:xA7F3jfw
Rustは電気ドリルや3Dプリンタのような道具なんだから、本当に良いと思えば
自分が使って生産効率を上げたり良い作品を作って披露すれば良いだけなのに、
信者達が無理やり広めようとしているのが嫌だ。
困るのは、C++を使ってる人を馬鹿にすること。
2023/03/16(木) 12:23:14.36ID:0EJvJf6l
Rust製の高速なwebpack互換バンドラ「Rspack」登場。現時点で5倍から10倍の性能向上 https://www.publickey1.jp/blog/23/rustwebpackrspack510.html
2023/03/16(木) 12:23:28.58ID:xA7F3jfw
C++をディスってC#を上げまくっていた人達が、Rustに鞍替えした模様。
彼らは5chやtwitterで徹底的にRustを褒めまくっている。
どうしてそんなことをするのか。思想家や哲学者なのか。
マルクスもそういう感じで結果、大勢の人々を苦しめた。
2023/03/16(木) 12:31:35.94ID:srO8KDRm
Rustはポテンシャルはあるけど現状で普及するパスが見えていないですから
Rustを愛する者にとってはそこがフラストレーションなのでしょう
普及するパスが見えたら解消すると思うよ
2023/03/16(木) 12:37:22.05ID:3C3pOHVn
C++が怠っていた部分を成し遂げたんだから、Rustは誇っていい
エンジニアが本職なら、C++でもRustでも、なんでも読み書きできないといけないだろう
まあ、じきにC++も追いつくだろ 問題はC
2023/03/16(木) 13:52:30.33ID:xA7F3jfw
本当に優秀なプログラマなら、C++でもRustでもどっちでも簡単に使えるので、
必要あらば、どっちでも使うだろうが、C++でもメモリーエラーなんて滅多に
起こさないし、起きても原因究明して直せるから、敢えてRustに行く動機もない。
別にRustが使えないからC++を使ってるわけじゃないのに、Rust使う人の方が
憂愁みたいに言われるのはおかしい。
2023/03/16(木) 13:53:26.57ID:xA7F3jfw
>>330
書き間違えた。
憂愁 ---> 優秀
2023/03/16(木) 13:55:47.65ID:xA7F3jfw
>>329
「Rustは誇っていい」という意味が分かりにくい。Rustを作った人はちょっと
誇っていいかも知れないが、Rustの解説本を書いている人や、Rustを道具として
使っている人が誇っていいわけではない。
2023/03/16(木) 13:57:50.83ID:3C3pOHVn
ああ、うん
Rust(言語と言語チーム)は誇っていい
その一派につらなる「信者」が誇るのは…まあ人の常かなって
2023/03/16(木) 14:00:22.48ID:xA7F3jfw
>>333
>その一派につらなる「信者」が誇るのは…まあ人の常かなって
信者が誇って良い分けないと思うが。
2023/03/16(木) 14:06:46.30ID:3C3pOHVn
Rust派先鋒衆がいうのは、Rustに移れば、大多数の脆弱性は自然につぶれるのに、
C++に固執するのがもうクズ。っていう発想 それもわかるんだけどね

なんでも書けてこそのC++ 縛りを記述できないなんて、欠陥でしかない
だから、C++の進化には期待してる 遅々たるものになるかもしれないけど
2023/03/16(木) 14:20:33.51ID:xA7F3jfw
>>335
>Rustに移れば、大多数の脆弱性は自然につぶれるのに、
>C++に固執するのがもうクズ。っていう発想 それもわかるんだけどね
本当に優秀ならば、C++でも脆弱性がが入らない。
mozillaやgoogleの社員がタコなだけ。
2023/03/16(木) 14:30:08.42ID:srO8KDRm
>>314
C++からRustライブラリを呼ぶ場合もRustからC++ライブラリを呼ぶ場合も
文法違いすぎて大変そうだけどどうしてるんかな?
Cのライブラリを呼ぶのはどのプログラミング言語からでも余裕だけども
JavaとC++もかなり歪だよね?
2023/03/16(木) 14:31:40.01ID:hABarloL
>>336のような勘違いしてる自信過剰なダメな人たちが今までセキュリティの穴を多数あちこちで生じさせてきた
人間は必ずミスをするという当たり前のことも受け入れられない人はキチガイのみ
2023/03/16(木) 14:33:21.04ID:3C3pOHVn
>>336
一人で作るもんでもないからねえ、大人数だと、体調の悪いヤツとかも混じるだろ
コンパイラに任せたいってのはわからんでもない
俺も、(たとえば)gccとヘッダライブラリに任せて、自分は気楽にごりごり書きたいｗ
340デフォルトの名無しさん
垢版 |
2023/03/16(木) 14:34:51.94ID:srO8KDRm
>>338
自信過剰も何もC++書ける人だとなぜに
スマートポインタで失敗するのか理解不能だよ
原因は生ポインタ使ってるからなんだろうけど
それなら生ポインタをプロジェクトで禁止にするだけで充分

あとマルチスレッドにおけるデッドロックはRustで検出できるのかい?
2023/03/16(木) 14:37:50.95ID:srO8KDRm
ボローチェッカだっけ? CとC++で実装できんのかな?
2023/03/16(木) 14:39:57.56ID:3C3pOHVn
ていうか、Rustがもたらそうとしてるのは、プログラミングパラダイムだから、
C++でおんなじように書ければいいんだよ ハズしてたらコンパイルエラーになってくれてだな

Rustは実績を積んだ C++は早くその成果を取り込むべき
ラムダといいコルーチンといい、C++が他に学んだ前例はいくらでもある

>>341
まじそれ
2023/03/16(木) 15:04:51.89ID:bO6zkRLm
>>338
それはプログラマーのレベルが少なくとも俺よりは低いから。
2023/03/16(木) 15:07:17.05ID:3C3pOHVn
>>343
お前みたいな優秀なヤツが、【わざと】脆弱性を仕込んだコードをコミットしたりするんだよｗ
他人は信用できねえ
俺クラスになったら、自分自身が一番信用できねえｗｗ
2023/03/16(木) 15:14:34.72ID:N2/NSeFa
use 描くだけでコンパイル中にダウンロード始まって
何分も待たされたらそりゃ遅いわ！！！ぷんぷんって
怒るアホも出て来るだろうね
2023/03/16(木) 15:18:25.89ID:N2/NSeFa
>>334
Rust(人気)は俺が育てた！(AA略)
2023/03/16(木) 15:36:54.04ID:07ACJDqQ
>>341
現状では無理
C++33くらいで可能になるかもね
2023/03/16(木) 15:38:33.76ID:07ACJDqQ
>>340
>あとマルチスレッドにおけるデッドロックはRustで検出できるのかい?
コンパイルエラーになるかという意味ならならない
その辺はGoとかと一緒でイディオムで対処
2023/03/16(木) 15:42:21.06ID:I4Z9PBKv
>>348
メモリ安全だけだとあんまり有り難くないな
もしミスってもデバッガで直ぐ分かる訳だし
2023/03/16(木) 15:51:10.02ID:TBYrYTSU
>>349
メモリ安全だけでなく
C++とは異なりRustはデータ競合を完全に防げる
C++とは異なりRustは広義のヌル安全であることも大きい
2023/03/16(木) 16:02:01.69ID:PpEtLqb1
>>350
それでも言語が汚いから使いたくない。
2023/03/16(木) 16:24:46.13ID:TBYrYTSU
様々なプログラミング言語と比較してもRustは美しい側に入るとともに
言語機能が強力で可読性が高い

とくにパターンマッチング
これはC++でも導入しようとしているが進んでいないだけでなく
C++で出ている提案では強力でなく可読性もよくないようにみえる
Rustはパターンマッチングが非常に強力で可読性の向上の最大要因となっている
2023/03/16(木) 16:52:12.01ID:3grScBM3
>>351
Rustかどうかは別として10年後くらいには
今Rustが実現してるやり方が標準的なものになるのは間違いないから
考え方やメリットデメリット、限界をある程度学んでおいた方がいいかもよ

Rust自体はいいところもあれば悪いところも沢山あるので実際に使うかどうかは状況次第
2023/03/16(木) 17:04:30.58ID:YeYGULup
結局Rustがもひとつ流行らないのって
①エコシステム
②ライブラリ
なんじゃやいの？
①は流行ってきたら充実するものでニワトリと卵だけど、②はどうなん？
②が中々充実しないのは何かRustのライブラリ書いてやろうと言う人が出てこない理由あるんかな？
2023/03/16(木) 17:12:09.28ID:3C3pOHVn
採用宣言が大手から出たんだし、そのへんは急ピッチで進むっしょ

>>353
10年後には、いまRustが提示しているものを踏まえた、さらにスマートなものが出ているかもしれない
でも、それを理解するには、ここから10年間、Rustの成果を学び、踏まえるのがいい だから俺はいま学ぶぜ
願わくば、10年後にも、しぶとい感じでC++が現役であってほしいな
2023/03/16(木) 17:15:50.99ID:QTF1+6wX
C++は次々と新たな機能を増やし続けてきたが増築工事だから色んな点で限界が多い
例えば話が出ている広い意味のnull安全はC++がoptionalの導入をとっくに行っているが
・なかなか普及しない
・既存ライブラリの仕様とのチグハグ
・パターンマッチング機能の導入がまだなので使い勝手が悪い
などの問題が山積みであまり使われていない
C++の他の機能導入でも似たような状況が多い
Rustが美しく書きやすく読みやすいのはそれらの多くが最初から解決されているからだと感じる
C++をさっさと棄てるのが現実解であると理解できた
2023/03/16(木) 17:23:01.97ID:3C3pOHVn
C++はなんでも書けるかわりに、いまや考えなしに勝手に組み合わせると めちゃくちゃになるんだよね
Rustには引き算の美学の成果が入ってる
C++も、先頭で縛りを宣言できるようにして、美しく書けるようになるべきだ 絶対に
2023/03/16(木) 17:47:47.57ID:VzH+f4s6
ソースコードのコンパイル・ビルドの時点ですべての問題点をエラーで全部弾いてくれたら理想的だね
大抵はテストツールまで書かないと使えない
359デフォルトの名無しさん
垢版 |
2023/03/16(木) 19:59:01.19ID:srO8KDRm
>>350
コンストラクタでlockしてデストラクタでunlockするproxyクラス作って
その一時オブジェクト経由で触れば良いだけなので何を今更という感じ
メモリ安全は別にデバッガですぐ特定できるし
マルチスレッドではRustの利点がない
デッドロックが検出できたらまぁ嬉しいが?
360デフォルトの名無しさん
垢版 |
2023/03/16(木) 20:03:11.00ID:u3ZLVO1D
クラス笑
2023/03/16(木) 20:03:55.24ID:srO8KDRm
>>354
多くの人に使ってもらおうと思ったらCで書いて
各言語のラッパーを提供するってのが多い
RustにこのCの代わりができれば良いんだけども?
もしRustユーザしかリンクできないライブラリだったら
Rustはそもそもユーザー数が少ないし
Rustで書く動機が減る
2023/03/16(木) 20:07:00.05ID:srO8KDRm
>>357
多人数でやるプロジェクトにはC++は自由過ぎて
その点は書き方にある程度拘束される意義はあると思う
363デフォルトの名無しさん
垢版 |
2023/03/16(木) 23:56:33.56ID:ufHOK4fg
>>320
ありがと
意外と変わらないんだ
364デフォルトの名無しさん
垢版 |
2023/03/17(金) 00:02:12.50ID:aeVIJ/KU
Rustでゲームエンジンやグラフィックソフト作れたら認めてやるよ
365デフォルトの名無しさん
垢版 |
2023/03/17(金) 00:04:03.80ID:aeVIJ/KU
DTMに使いそうなDAWソフトとかでもいいぞ
書き方はGitHubにいろんなOSSの見本があるから簡単でしょ？
366デフォルトの名無しさん
垢版 |
2023/03/17(金) 00:04:27.28ID:aeVIJ/KU
Rust使いこなせるくらいなら余裕のはず
2023/03/17(金) 00:14:30.94ID:o5CBT2m0
SDLのRustバインディングはあるけども
Rustで本体を書いて他の言語のバインディングって出来るの?
他の言語との乖離でRustならではの部分が封じられて
あんまり嬉しくないような気もするのだが?
それともRustでライブラリ書いたらターゲットはRustだけになるのかな?
2023/03/17(金) 00:14:49.50ID:6s2Kuhdf
>>356
>Rustが美しく書きやすく読みやすいのはそれらの多くが最初から解決されているからだと感じる
俺とは感覚が違う。Rustを美しく感じない。
2023/03/17(金) 00:21:48.75ID:6s2Kuhdf
これは理解できるし、はっきりそう書けばよい:
・Rustの本を書きました。Rustは良い言語なので本を買ってください。
・Rust用のライブラリを書きました。Rustは良い言語なのでライブラリを買ってください。
これは理解できないし、問題:
・C++は害悪なのでRustをみんなが使って世の中を良くしよう。
・自分がC++を使いこなせないのに、使いこなせる人が許せないから、使いこなせるRustを普及させたい。
2023/03/17(金) 00:39:18.46ID:2hBAQcCo
RustはC++なんかよりずっと簡単! <- これならわかる
2023/03/17(金) 00:51:57.03ID:6s2Kuhdf
>>370
それも意見が分かれそうだ。
2023/03/17(金) 00:54:59.09ID:UJajhYy7
>>367
出力を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用ライブラリ）
みたいな構造
2023/03/17(金) 01:04:51.03ID:o5CBT2m0
>>372
なるほどー
2023/03/17(金) 05:58:07.48ID:HbMAHHRq
>>359
Rustならマルチスレッドでもマルチタスク(=グリーンスレッド)でも書きやすく
さらにデータ競合を完全に防げるRustしか現状の言語では選択肢ないと思うよ
各言語で書き比べてみれば一目瞭然
そのため並行並列を使うプログラムはC++→RustだけでなくJava→Rustの移行も進んでる
375デフォルトの名無しさん
垢版 |
2023/03/17(金) 10:42:47.45ID:o5CBT2m0
>>374
>>そのため並行並列を使うプログラムはC++→RustだけでなくJava→Rustの移行も進んでる
全く進んでいないのだが?w
俺の周りではC++やJavaでマルチスレッドで書く奴の方が多い
というかそもそもRustを使っている奴は一人もいないw
妄想なのか詐欺師なのか...
Linuxでも さもRustの導入が進んでるように言うが実際は>>39だし...
2023/03/17(金) 10:55:37.94ID:FKqwIQQI
マルチスレッドはまあ普通だけどマルチタスクはめちゃくちゃ書きにくいぞ
単純なWeb Serverくらいならいいがちょっと凝った処理を書こうとするとくっそ面倒くさい
tokio依存なのもダメなところ
2023/03/17(金) 11:06:44.98ID:tBmmskox
そここそ、OSがRust化するっていうんだから、きれいなAPIが出てきてほしいね
結局、効率を求めたらC API に肉薄することになるし
2023/03/17(金) 11:15:24.56ID:TZnQdWAf
Linuxの現状はRustでドライバが書けるようになったってだけだよ
誤解なきよう
2023/03/17(金) 11:17:48.64ID:RPqYd1dp
>>376
マルチタスク(並行)で綺麗に書ける言語はRustとGoだけだな
GoはPromise(Future)使わないあのスタイルに寄せられるのとGC言語であるため
Rustが汎用では筆頭言語になる
2023/03/17(金) 11:33:47.61ID:Igk62yzo
>>376
だよな
Rustの非同期が簡単だと勘違いしてるやつはチュートリアルレベルしかやったことないやつだと思うわ
2023/03/17(金) 11:43:37.53ID:RPqYd1dp
>>380
自分でpollしたりするのも含めて色んなレベルで書いているが簡単だぞ
Rustで並行並列が難しいと言うならばとこが難しいのかを具体的に述べよ
そしてそのケースでRustの代わりに使える別言語があるならば述べよ
2023/03/17(金) 11:51:53.17ID:UWSndCzi
Goと比較したら性能面でも劣ることが多くて同程度の性能を実現したければ手動であれこれやらないといけないからな
2023/03/17(金) 12:19:57.65ID:CZQwnfV3
>>381
そうやって自分が分かってない事を無料で聞き出してしまおうとする。ずる賢い。
2023/03/17(金) 12:31:22.55ID:RPqYd1dp
>>382
Goが速い遅いと言ってたのは昔の話
今はGoもRust tokioも改善してほぼ同じwork stealing方式になり似たりよったりの速度
C++をあきらめてRustに対抗できるGoを持ち出すしかないほど追い込まれてるのかね

>>383
Rustで並行並列が他の言語より難しいことはない
難しいと主張するならば何が難しいのかを述べたまえ
もし本当に具体的に困ったことがあるならばアドバイスできる
2023/03/17(金) 12:38:18.49ID:YQ2F/Sw2
追い込まれてるってなんだろうね
楽しそうだね
2023/03/17(金) 12:39:30.67ID:o5CBT2m0
この人は妄想癖がある
2023/03/17(金) 12:56:40.90ID:LTrpjv8n
>>384
>Rustで並行並列が他の言語より難しいことはない
>難しいと主張するならば何が難しいのかを述べたまえ
>もし本当に具体的に困ったことがあるならばアドバイスできる
問題意識があること、気付くこと、それが大事。
あなたにはそれがない。
2023/03/17(金) 13:03:24.97ID:Gi38nai6
>>383
わかり味
こいついつも教えて君だよなぁ

総論しか書けないところみると
マニュアルだけ読み込んだペーパープログラマーがそれを隠すためのネタを欲してるようにしか見えない
2023/03/17(金) 13:03:47.55ID:T8dNhcTz
Goはgoroutine間のデータ競合の発見を実行時のランタイムでやるしかなく
Goはあまりお勧めできないなあ
メモリ共有せずチャネルを使う範囲ならGoでもいいけど
Rustでもチャネルはもちろん使えるし
共有メモリで安全にデータ競合を起こさず使えるからRustがいいよ
2023/03/17(金) 14:28:10.79ID:ZRpBqjDt
ほんと嘘ばっかりだな
2023/03/17(金) 15:04:18.42ID:RPqYd1dp
>>389
Goに限らずデータ競合を実行時にしか検出できない言語ではデータ競合が時々しか起きない場合のデバッグが難しい
Rustを使うべき理由はデータ競合を静的に検出できる点にある
2023/03/17(金) 15:55:42.60ID:LTrpjv8n
>>391
それはマルチスレッドプログラミングのアルゴリズムをRustは強く制限しているから。
だから、その制限から外れるようなアルゴリズムは使えないので柔軟性は欠く。
2023/03/17(金) 16:03:41.59ID:tBmmskox
そこが、新規書き起こしのRustのメリットでもあるわけよな
2023/03/17(金) 16:05:57.04ID:LTrpjv8n
>>393
そして、独自のアルゴリズムは使えないので、アルゴリズムの研究には向かない。
2023/03/17(金) 16:11:31.46ID:TZnQdWAf
第n次LinkedListおじさんvsGCおじさん戦争
2023/03/17(金) 16:16:19.10ID:tBmmskox
頑張ったら書けるんじゃねーの、それもsafeで
そのへんはC++もおなじ 自分も、ニッチすぎる薄いラッパなら頑張って書くし
2023/03/17(金) 16:20:04.75ID:KZujdKGk
>>392
Rustで記述できないマルチスレッドプログラミングのアルゴリズムなんてものは存在しない
Rustは柔軟性が非常に高い
2023/03/17(金) 16:32:10.93ID:LTrpjv8n
>>397
嘘を書かないで。
2023/03/17(金) 16:41:56.97ID:T8dNhcTz
Rustで書けないのがあると主張している人が例を出せばいいんじゃね
Rustにそんな制限はないからすべて書けるよたぶん
2023/03/17(金) 16:52:07.05ID:4tGjgBNl
結局何年か後にはlinux kernelを全部rustで書くつもりなんかな
2023/03/17(金) 17:00:34.34ID:tBmmskox
書けなくはないだろ、書きやすいかどうかだ 実際どうなん
C++は、なんでも書けるが、油断すると複雑すぎる代物ができあがる
そんで、「でも例外がくるとー」「でも異常値がくるとー」って
2023/03/17(金) 17:01:41.44ID:LTrpjv8n
>>399
マルチスレッドのアルゴリズムは非常に多く存在していて、ある意味では無限に
考えられる。Rustは数個しかサポートしていないから、無理。
2023/03/17(金) 17:26:21.78ID:T8dNhcTz
>>402
Rustで書けない例があると主張したいなら例を出せばいいんじゃね
Rustに何か制限があるわけじゃないからおそらくなんでも書けるよ
2023/03/17(金) 17:31:51.55ID:LTrpjv8n
>>403
unsafeになる。
2023/03/17(金) 17:42:50.37ID:T8dNhcTz
>>404
マジ？信じられん
もし本当ならそのunsafeを使わざるを得なかった例を具体的に出せばいいんじゃね
2023/03/17(金) 17:43:39.56ID:tBmmskox
unsafeをゼロにするよりも、極小なunsafeブロックを組み込んで華麗にキメてほしいね
これはC++も同様
2023/03/17(金) 17:52:35.17ID:2s/kFNH6
>>400
そういう枯れた古いものをわざわざ書き直すことに熱意を燃やせる人間は少ない
新世代のデータベースやcrypt/blockchainのように金になる新しい成長分野ではc/c++よりもrustがよく使われてる

技術の自然な世代交代は既存システムの置き換えから始まるものではない
2023/03/17(金) 18:01:30.86ID:LTrpjv8n
>>405
次のことが成り立っていれば教えてもらわなくても自然に分かる:
・マルチスレッドの事を理解している。
・Rustのことを理解している。
・算数的直観力に優れる。
2023/03/17(金) 18:03:48.04ID:u99ocdLb
複製おじさん vs 100点おじさん
Fight!
2023/03/17(金) 18:24:08.50ID:NC4w42Nt
>>401
そのへんの問題もRustだと安全安心なのがいいよなー
特に例外機構を無くしたのは大成功
あとResult放置してると警告もしてくれるしな

>>404
そのunsafe使わないと書けなかったコードを出してみ
寄ってたかって添削してやろう
2023/03/17(金) 18:36:02.65ID:LTrpjv8n
>>410
俺は天才だから、お前みたいな凡人に無料でヒントをくれてやらない。
2023/03/17(金) 19:13:16.48ID:tBmmskox
Rustって、削ぎ落したものは復活させません、って宣言とかしてるん?
2023/03/17(金) 19:55:25.86ID:9o1NNcpX
>>408
Rustをあんまり知らんけど言語間に根本的な差はなくね？
2023/03/17(金) 20:02:50.35ID:kImSYq8C
>>408はいつものキチガイ
RustもC++もコードを書けたことがない
相手にするだけ無駄
2023/03/17(金) 20:19:10.88ID:TZnQdWAf
>>414
今さらなに言ってるんだ？
ここにはキチガイしかいないぞ？
俺もお前もな
2023/03/17(金) 20:29:34.70ID:Zxg/DnHC
>>413
ん？だから何？
2023/03/17(金) 21:29:42.97ID:o5CBT2m0
>>416
アルゴリズムを書ける書けないの差はでない
418デフォルトの名無しさん
垢版 |
2023/03/17(金) 23:44:57.66ID:Lcw0Ean/
Rustほとんど知らん俺でも総合的にRustのほうがC++よりはいいだろと思う
C++より後発言語で、で、ライバルになるC＋＋に劣っているようじゃダメだからな
で、お前らは、すごいRustで具体的に何を作っているんだ？
2023/03/18(土) 00:11:15.51ID:6kQD14Ek
ChatGPT先生に聞いてみた
>>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};
};
2023/03/18(土) 00:31:48.86ID:jelBOeFa
先生にからかわれとるぞｗ
2023/03/18(土) 00:53:02.93ID:rMRLIFsD
>>419はこれと同じのをRustで書いたらunsafeになる(だろ?)
って言いたいんだろ
偉大なるChatGPT先生が言うんだから間違いないだろな
2023/03/18(土) 00:58:57.68ID:6kQD14Ek
>>421
いやChatGPTは信用しない方が良い
俺はRustは良く分からんがChatGPT曰く
>Rustには、このようなロックフリーなデータ構造を提供する
>クレート（ライブラリ）が存在します。その一つがcrossbeamです。
>このクレートは、スレッドセーフで効率的なデータ構造を提供しており、
>crossbeam内でUnsafeな操作が行われているにもかかわらず、
>APIを通じて安全に使用できます。
だそうな
crossbeamってRustで書かれとらんのかな?
2023/03/18(土) 01:14:24.86ID:pMxUNH+f
>>422
本当は、ライブラリの中だけをunsafeにして、アプリ側はsafeに出来るケースも有れば、
アプリ側も unsafe を消せないケースもありえる。
2023/03/18(土) 01:17:39.13ID:6kQD14Ek
unsafeってキーワード使えばチェックをオフにできるのね
2023/03/18(土) 01:29:02.55ID:6kQD14Ek
>>420
Rustで書いてみよう！
2023/03/18(土) 04:35:18.48ID:+IGrKU6n
ArcとAtomicでほぼそのまま書けるけど
pointer dereferenceのためにunsafeは必須
2023/03/18(土) 10:03:55.24ID:fNuha5Rk
言語マウントごっこにしか使われてないrust
428デフォルトの名無しさん
垢版 |
2023/03/18(土) 10:25:46.77ID:fSPMk7mF
no chance
2023/03/18(土) 11:41:47.24ID:ux4diyjf
平日の昼にID真っ赤なのは仕事か
板違いのスレで必死に毎日お疲れさん
2023/03/18(土) 14:02:46.54ID:d2/CRNVk
ちょうどオライリーから「Rust Atomics and Locks」という本が出てるよ

基本的な内容を説明してる本なのでC++でatomicsやmemory orderingに慣れ親しんでる人がわざわざ買うほどのものではないかもしれないけど
かなりわかりやすくまとまってるのでRustでこの辺りの機能を使ったコードを良く書く人は読んで置いて損はないと思う
431デフォルトの名無しさん
垢版 |
2023/03/18(土) 16:09:57.63ID:fSPMk7mF
ほう
https://bokuweb.github.io/undefined/articles/20230205.html
2023/03/18(土) 18:42:10.12ID:kFUsfJhu
Lock-Freeなデータ構造を自分で作りたい人はこれを見るといい

Porting Java's ConcurrentHashMap to Rust (part 1)
https://www.youtube.com/watch?v=yQFWmGaFBjk
2023/03/19(日) 12:22:41.89ID:LfQxDddq
> cargo new hoge
> cargo run
→ 3MB
main.rs に
use clap::Parser;
追加すると
> cargo run
→ 100MB 超えるんだが
どうすれば容量減らせるん？
2023/03/19(日) 12:44:51.20ID:TIfaDrwo
とりあえず--releaseつける
2023/03/19(日) 13:32:03.94ID:fPDrKYk/
しらんけど
https://igaguri.はてなぶろぐ.com/entry/2020/06/07/133847
https://crates.io/crates/cargo-clean-recursive
2023/03/19(日) 13:35:18.59ID:fPDrKYk/
とりあえずは
cargo clean
で良いはず
最初から余計なのは造りたくないって言う話ならほんまにしらん
2023/03/19(日) 14:03:33.37ID:4KWNgnTF
>>436
ありがとうございました
2023/03/20(月) 08:59:55.73ID:8VwEKWf+
やっぱC++にもボローチェッカ欲しい
なんならCにも欲しい
attributeとか併用したら、やってできないことはないんじゃねーの
2023/03/21(火) 17:20:17.93ID:icU0z8mb
rg3d はなぜ
https://github.com/rg3dengine/rg3d
から
https://github.com/FyroxEngine/Fyrox
に改名したのですか？
2023/03/21(火) 17:50:34.39ID:5MGYYNx+
rustの読み物公式が面白いのしっかり出してるから
それ読むだけでも大分良い
後発言語らしくイイトコどりしまくってる
null無くした代わりになんでもかんでもラップしてるから若干だるいけど
すげー面白い
441デフォルトの名無しさん
垢版 |
2023/03/21(火) 19:41:09.03ID:4irMO5jk
Unity超えるゲームエンジン作ってから言え
442デフォルトの名無しさん
垢版 |
2023/03/21(火) 19:42:14.14ID:4irMO5jk
Blenderとかでもいいよ
2023/03/21(火) 21:54:25.24ID:gItZ+a0F
cpp2rsみたいのがじきできるから、そしたら一発
ただ、それだと、safeではあるけど、Rustのシンプルさは(メリットとして)失うな
444デフォルトの名無しさん
垢版 |
2023/03/22(水) 07:30:44.03ID:7nCtmzjD
>>443
ほんとにできる？
445デフォルトの名無しさん
垢版 |
2023/03/22(水) 09:09:27.85ID:II3LrhVD
文法がRustなだけで
Rustのコードとして使い物にならん
ゲテモノが出て来るわ
今のGPTも酷い
2023/03/22(水) 09:47:28.48ID:RLKJ2atP
ああ、あと全自動とは言わない あっちこっちで、あれなおせーこれなおせーって言われるかと
447デフォルトの名無しさん
垢版 |
2023/03/22(水) 10:40:01.19ID:Motackg9
たしかに、C++でメモリ安全性を静的チェックするツールを作るのはなかなか難しいもんかね？
2023/03/22(水) 12:19:59.74ID:jZlOcGNt
gccだとvargrindとかあるけどね
2023/03/22(水) 14:27:48.09ID:RqRpj7Ax
valgrindはgcc関係なくないか？
rustでもメモリリークの確認に使う

有用なツールだけど静的チェックと呼べるのかは疑問
2023/03/22(水) 21:31:28.83ID:vDLoPLCP
valgrindは実行時チェックだから出現レアケースだと時間内に検出できない
2023/03/22(水) 21:43:05.82ID:jZlOcGNt
AddressSanitizerでもValgrindでもmtraceでも好きなの選べ
https://kivantium.hateblo.jp/entry/2018/07/14/233027
2023/03/22(水) 21:46:10.74ID:vDLoPLCP
全て実行時チェックだな
2023/03/22(水) 21:54:30.07ID:jZlOcGNt
静的ツールだとこんなのもあるね
https://cppcheck.sourceforge.io/

スマートポインタ使えばそもそもいらんがね
454デフォルトの名無しさん
垢版 |
2023/03/23(木) 11:01:43.91ID:AQHpwrnP
C++で出来る人には要らん
455デフォルトの名無しさん
垢版 |
2023/03/23(木) 11:35:46.79ID:4E7FceMl
メモリ不安全の何が悪いかってメモリリークじゃなくて間違った場所にアクセスしちゃうことだと思うのだが
2023/03/23(木) 11:37:47.99ID:rQpQMC7M
>>455
例えばどういう状況かな?
457デフォルトの名無しさん
垢版 |
2023/03/23(木) 13:26:58.89ID:4E7FceMl
>>456
ゲームのバグとか
2023/03/23(木) 13:54:38.12ID:Pj5jY94w
Segmentation fault：呼んだ？
2023/03/23(木) 14:56:19.59ID:vn3KCE0y
Windowsで実行しています
https://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!"+改行
で余計な"が入っているのですがなぜでしょう？どのように取り除くのが正しい対処方法を教えて！！
2023/03/23(木) 15:07:48.89ID:AQHpwrnP
let o = Command::new(c).args(&["/c", "echo Hello, world!"]).output().expect("Failed to start process");
461デフォルトの名無しさん
垢版 |
2023/03/23(木) 17:25:27.77ID:v7ZfYtIP
C++は例外処理とかもバグを生みやすくしていると思う
2023/03/23(木) 19:55:36.72ID:oPmaaYed
C++にmoveや右辺値参照ができる前に挫折した連中がRustスゲーとか言うのは何か違うと思う。
2023/03/23(木) 20:30:50.18ID:xqmW5G90
失敗だか挫折だか知らんけど
失敗してもお金が減らない失敗は半分大成功だよ
2023/03/23(木) 23:42:04.79ID:/qDbj6Pr
とりあえず3つに絞るとして
(1)ダングリングがないメモリ安全性の保証
(2)データやポインタのヌル安全性の保証
(3)データ競合がない安全性の保証
Rustはコンパイラが通れば保証されるが
C++は(2)(3)は無理として(1)についてもプログラマーがどんなに複雑化してもミスなく記述できた場合のみその自己責任で実現
そのためC++ではバグやセキュリティの穴が現在進行形で量産されている
2023/03/23(木) 23:55:58.81ID:rQpQMC7M
でもRustはLockFreeQueueをunsafeにしか書けないでしょ?
2023/03/24(金) 00:33:14.50ID:sS+xf8yH
LockFreeQueueもsafeなインタフェースを提供できている
https://docs.rs/lockfree/
中身はunsafeを使う部分が一部あるが全てコメントに理由が記述されているようにsafeな操作でありその部分の安全性のみを人が保証
Rustの最大の特徴はこのようにunsafeを使ったsafeな操作を内部に封じ込めて外部にsafeなインタフェースを提供できること
そしてそのライブラリを使った任意のプログラム全体の安全性がRustコンパイラにより保証される
467デフォルトの名無しさん
垢版 |
2023/03/24(金) 01:00:04.81ID:STP4y0mB
>>466
Rustにはunsafeを認めるんだなw アンフェアだね
C++もスマートポインタを使えばメモリリークは起こらんのだよ
2023/03/24(金) 01:01:07.83ID:Qymt7I/N
full safeが至上なんじゃないんだよ
それだとマイコンでrustが使えなくなるし、safe C++だって実現しなくなる
469デフォルトの名無しさん
垢版 |
2023/03/24(金) 01:08:19.45ID:F7DMT464
C#もAOTコンパイルに対応したしもうこっちでよくねる
2023/03/24(金) 01:13:06.10ID:STP4y0mB
>>468
safeじゃないRustねぇw 苦しいな
言語を覚えるのが趣味なら使えば
2023/03/24(金) 01:15:17.05ID:Qymt7I/N
スマポスマポいうけどさ、なら、スマポオンリーっていうpragmaつくればよくね
それとC++はなんでもかんでもnewする習慣がついちゃって、
そこはスタックに物を置きたくなるRustのほうが能率よくなっちゃってねえか
2023/03/24(金) 01:22:55.16ID:IeJLDeif
>>467
違いは明白

C++はプログラム全てがunsafeエリア(＝人が安全性を保証する)
Rustはプログラムのほとんとがsafeエリア(＝コンパイラが安全性を保証する)
（Rustには一部の閉じ込められた局所的な部分のみunsafeが存在しそこに限定して人が安全性を保証する）
473デフォルトの名無しさん
垢版 |
2023/03/24(金) 01:25:05.80ID:F7DMT464
C#でいいやって時代が来そうだな
.NET7でAOTコンパイル対応したから
Rustなんかより遥かに簡単だし
2023/03/24(金) 01:25:34.49ID:Qymt7I/N
たとえば、メモリマップドI/Oが扱えない言語は、本気でやりこもうとは思えない
ちなみに、C#はプリコンパイルできるスクリプト言語として、とても便利に日々使ってる
475デフォルトの名無しさん
垢版 |
2023/03/24(金) 01:34:37.55ID:F7DMT464
>>474
まぁ時期対応するでしょ
使ってる人Rustより遥かに多いし
2023/03/24(金) 01:35:44.19ID:STP4y0mB
>>472
後退したなw
Rustを覚えるよりもスマートポインタ使う方がずっと楽だよ
どうせC言語は覚えなきゃならんのだから
C/Rustを覚えるよりC/C++を覚える方がずっと効率的
2023/03/24(金) 01:36:16.07ID:IeJLDeif
>>473
C#はC++やRustのカバーする範囲を全く満たせないのでこのスレでは論外
C#はGCがあるし省メモリや高速性もないし更にはインラインアセンブリも書けない
478デフォルトの名無しさん
垢版 |
2023/03/24(金) 01:39:04.57ID:F7DMT464
>>477
AOTにするとGCとか無くなるよ
479デフォルトの名無しさん
垢版 |
2023/03/24(金) 01:39:24.39ID:STP4y0mB
>>477
AOTに対応したんだから速度では勝負できるよ
480デフォルトの名無しさん
垢版 |
2023/03/24(金) 01:41:10.62ID:F7DMT464
まぁこれ見てくれ
https://takym.github.io/blog/general/2022/12/25/osdotnet.html
2023/03/24(金) 01:41:24.23ID:STP4y0mB
>>478
へー
JavaのAOTってgcjのやつはGCなかったっけ?
C#のAOTはGCなくなるんだ
2023/03/24(金) 01:42:48.96ID:IeJLDeif
>>476
後退って何？
Rustはコンパイラが安全性を保証できる言語でC++は人が安全性を保証する言語で何も変わっていない
C++スマポでなんとかできる安全性の範囲は>>464のうちの(1)だけだから話にならない
483デフォルトの名無しさん
垢版 |
2023/03/24(金) 01:45:09.38ID:STP4y0mB
>>482
>後退って何？
おまいさんのディフェンスライン
2023/03/24(金) 01:48:33.41ID:Qymt7I/N
また髪の話してる
2023/03/24(金) 01:52:02.45ID:7trvtA/S
>>478
嘘つき
C#はGC言語なのでAOTコンパイルしようがGCは無くなりません
C#がC/C++/Rustの代わりになることはできません
2023/03/24(金) 01:54:42.93ID:GMecybVR
C++って今もvectorの要素を参照しながら末尾に要素を追加しまくると参照先がいなくなる事故は発生すると思う
最近のC++はよく知らないけどスマートポインタで防げるの？
2023/03/24(金) 01:54:57.32ID:STP4y0mB
>>464
>(3)データ競合がない安全性の保証
共有データをスマートポインタに入れといて
アクセスする際には共有データではなくて
一時Proxyを経由してアクセスすればよい
Proxyのコンストラクタでロックしてデストラクタでアンロックする
RustのMutex相当で簡単に実装出来る

>(2)データやポインタのヌル安全性の保証
これはどういうこと? 静的に保証しろってことかな?
2023/03/24(金) 01:57:35.21ID:STP4y0mB
>>486
vectorは連続するアドレスに領域を取ることが保証されているコンテナなので
末尾に要素をしてcapacityを超えると当然再配置が起こる
他のコンテナを使うべし
2023/03/24(金) 02:03:47.17ID:STP4y0mB
>>486
もし最大要素数が決まってるなら
vectorで領域をreserveしといて
その範囲で追加ってことなら
再配置は起こらない
いずれにしても仕様を調べて使うべし
2023/03/24(金) 02:07:17.26ID:GMecybVR
>>488
>>489
サンクス
なんかスマートポインタ推されてるからリアロケーション追跡するポインタとか出来てるのかと思った
2023/03/24(金) 02:12:19.33ID:7trvtA/S
>>487
C++のスマポは使い方をミスったらおしまいで実際に問題を起こし続けている欠陥品
null安全か否かは言語仕様で決まりもちろん静的に防げる
当然C++はnull安全な言語ではない

>>488
vectorの自動メモリ再配置によるダングリング発生がうっかりミスで容易に発生するC++は欠陥言語
492デフォルトの名無しさん
垢版 |
2023/03/24(金) 02:30:27.68ID:STP4y0mB
>>491
>C++のスマポは使い方をミスったらおしまいで実際に問題を起こし続けている欠陥品
どういうミスかな? 書いてみ

>null安全か否かは言語仕様で決まりもちろん静的に防げる
これもどういうケースを言っているのか分からんので書いてみて

>vectorの自動メモリ再配置によるダングリング発生がうっかりミスで容易に発生するC++は欠陥言語
連続するアドレスに領域を取ることが保証されているコンテナはRustにはないのかな?
C++はもちろんメモリ再配置しない（領域が連続しない）コンテナを選択できる

反論したいので具体的に書いてね
無理かもしれんがもし書けるならC++のソースで例示してね
2023/03/24(金) 02:43:13.61ID:Qymt7I/N
ちゃんと書けば動く、は言語として甘え
C++は一刻も早く進化すべきだ
2023/03/24(金) 02:54:47.10ID:STP4y0mB
具体的にね
2023/03/24(金) 03:22:24.82ID:pHWoHRbv
>>491
欠陥言語というか他の言語たちと比べればCやC++はわずかなミスで危険なことになるから大きなマイナスかもしれないけど
省メモリで高速という他の言語では得られない巨大なプラスがあるからC++は必須の存在だったのよ
今はその巨大なプラスがありつつマイナスのないRustが登場したからC++は価値がなくなり役目を終えたけどね
496デフォルトの名無しさん
垢版 |
2023/03/24(金) 04:28:25.21ID:F7DMT464
>>495
役目を終えたならC++で書かれた全てのソフトウェアがRustになってもおかしくないけど全くそうじゃないよな？
2023/03/24(金) 04:38:49.00ID:pHWoHRbv
>>496
既存システムの書き直しは時間と費用がかかるからやるとしても少しずつでしょ
多くのシステムは大規模更新時の機会にでしょ
新規に登場したシステムはRust製になっていってますね
498デフォルトの名無しさん
垢版 |
2023/03/24(金) 04:46:18.91ID:F7DMT464
>>497
ならないと思うけどね
まぁ何言っても無駄かw
499デフォルトの名無しさん
垢版 |
2023/03/24(金) 05:43:54.98ID:pnAyfShU
そもそもC++ってCと比較しても脆弱性が下がる気がする。
なんか初心者泣かせのトラップが多すぎるんだよな。
2023/03/24(金) 05:50:11.50ID:G7wXKrBj
>>460
ありがとうございました
501デフォルトの名無しさん
垢版 |
2023/03/24(金) 05:58:04.68ID:G7wXKrBj
>>484
GCって禿のことだったんですね
2023/03/24(金) 06:06:32.31ID:G7wXKrBj
>>499
>初心者泣かせのトラップ

むしろ知ったかがドツボに嵌る
2023/03/24(金) 10:43:05.72ID:qDyrJPYZ
>>492
rustのvectorは再配置される可能性がある操作時は他からの参照がないことがコンパイル時に保証されるので連続領域でも問題ないよ
2023/03/24(金) 11:32:45.65ID:STP4y0mB
>>503
ほう! 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
2023/03/24(金) 12:12:50.87ID:yujZIUnP
>>504
(1)の段階では問題ないけど
(2)の段階ではitrとpush_backがコンフリクトするからコンパイルエラー
2023/03/24(金) 12:16:34.86ID:+nRUfXDq
>>504
当然エラーは起きない

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
2023/03/24(金) 12:23:09.85ID:STP4y0mB
>>505,506
どっちが正しいんだい?
2023/03/24(金) 12:23:39.80ID:xsjnwqf2
ああそれはそうね
2023/03/24(金) 12:24:51.09ID:xsjnwqf2
>>506が正しいよ
オレはdangerousがある前提で考えてたから
2023/03/24(金) 12:27:08.05ID:+nRUfXDq
(2)の段階より前に参照や可変参照があっても
(2)の段階より後に使われなければ
(2)の段階より前までにそれらの参照のスコープが自動的に終わる(＝ライフタイムが尽きる)
したがってコンフリクトは起きない

一方でもしdangerousの部分のコードがある場合は
(2)の段階より後に使われているため
コンフリクトが起きるためコンパイルエラー
2023/03/24(金) 12:31:23.73ID:STP4y0mB
有難う
reserve_exactの引数が定数1のときには
最終行のdangerousを入れるとコンパイルエラーを出すということだが
reserve_exactの引数が変数で実行時にしか定まらんときは
コンパイルエラーにできないと思うんだが危険じゃね?
2023/03/24(金) 12:35:02.24ID:STP4y0mB
>>510
なるほどー
Rustってデストラクタはいつ呼ばれるの?
ライフタイムの終わり? あるいはデストラクタはない?
2023/03/24(金) 12:48:05.77ID:+nRUfXDq
>>511
指定サイズは一切関係ない
データ競合が起きないようにmultiple readers or single writerの鉄則に基づく
pushすなわち書き換えたいならば他にreader(参照)もwriter(可変参照)も生きていてはいけない

>>512
所有権を持っている変数がスコープから外れると
所有者が居なくなりデストラクタ相当が呼ばれて自動的に安全にメモリ解放される
2023/03/24(金) 13:14:43.88ID:STP4y0mB
>>513
>>>511
>指定サイズは一切関係ない
>データ競合が起きないようにmultiple readers or single writerの鉄則に基づく
>pushすなわち書き換えたいならば他にreader(参照)もwriter(可変参照)も生きていてはいけない
pushしたあとはたとえcapacityの範囲内で再配置が行われてないとしても
参照を取得し直すってことかな?
2023/03/24(金) 13:21:48.64ID:STP4y0mB
>>513
Rustのスコープ=ライフタイムとすると
デストラクタが呼ばれるタイミングが分かり難くないかい?
ちょっとソースをいじって後ろの方でインスタンスを触ると
呼ばれるデストラクタが呼ばれるタイミングも
自動的に後ろになるということかな?
C++ほどデストラクタに処理を書かないのかな?
2023/03/24(金) 13:23:02.73ID:+nRUfXDq
>>514
再配置だけでなく値が書き換わる可能性もある
それらの可能性やそれらの操作を跨いで参照を保持してはいけない
逆に言えば参照を持ち続けることができているならば指している値が変わらないことが保証される
これはバグを防ぐとともにコンパイラによる最適化の余地も広げ高速化にも寄与する
2023/03/24(金) 13:31:39.50ID:STP4y0mB
>>516
なるほどね
まぁ俺は再配置が起こらないと分かるところで
いちいち参照は取り直したくはないな

Rustのデストラクタが呼ばれるタイミングは
インスタンスのライフタイムで変わりうるということで良い?
2023/03/24(金) 13:32:37.18ID:+nRUfXDq
>>515
デストラクタが呼ばれるのはその変数の「ブロックスコープ」のブロックを出るタイミングだから一定している
2023/03/24(金) 13:37:44.31ID:STP4y0mB
ブロックスコープって多分C++のスコープと同じだよね?
ライフタイムとまた違うのかな? 複雑だなぁ
2023/03/24(金) 13:53:25.98ID:+nRUfXDq
>>519
誤解をしている
ブロックの途中で打ち切られる可能性があるのは参照のライフタイム
そして参照にはデストラクタはない

一方で値そのもののライフタイムつまり所有権が尽きるのは常にブロックスコープに従う
デストラクタが存在すればブロックを抜けるタイミングで呼ばれる
その後でメモリ解放が自動的に行われる
2023/03/24(金) 13:55:42.43ID:GMecybVR
デストラクタは所有してる変数のブロックを抜けるまでに呼ばれることが保証されてるけど
正確なタイミングはコンパイラが決めてるから予測はできない
例えば何かを解放しないと以降で競合が生じる場合はブロックの途中で解放されることもある

ただ
A()
B(&A)
みたいにBがAを参照してるような状況だとBが消えるまでAを動かせないから
結果的にC++と同じように逆順で解放されることになる

ライフタイム周りはコンパイラが制約を満たせる処理順を見つけて裏で調整する感じだから
最初は戸惑うかもしれないね
2023/03/24(金) 14:00:41.09ID:+nRUfXDq
>>521
let _ = x; で棄てる以外に
ブロックの途中でデストラクタが呼ばれるケースあるっけ？
2023/03/24(金) 14:34:12.82ID:JpLx+uLR
>>520
それどこのスマポ
2023/03/24(金) 14:38:27.83ID:STP4y0mB
>>520,521
なるほどね
参照って読んでるのは>>506だとfirstのことかな?
参照の中にC++のstd::shared_ptrの挙動を内在させてるイメージを持った
Vecのアクセスにiteratorは使わないのかな?
2023/03/24(金) 14:55:23.36ID:+nRUfXDq
>>523
デストラクタにスマポもポインタも関係ない
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)
2023/03/24(金) 15:07:39.53ID:GMecybVR
>>522
すまん
ちょっと勘違いしてた
Dropあると明示的に捨てる必要あるな
2023/03/24(金) 15:07:52.15ID:+nRUfXDq
>>524
C++とRustはiteratorで指すものが微妙に異なるので要注意だがまずは折衷するとして
例えば
let mut v = vec![1, 2, 3];
for p in v.iter_mut() {
*p += 10;
}
これでイテレータを使って11,12,13
2023/03/24(金) 15:18:17.49ID:m8vHxf3R
>>521
Drop scopeがブロックとは限らないだけで予測できないわけではなくね？

>>525
let x = Foo(123).0 * 2;
とか
let mut x = Foo(124);
x = Foo(456);
とか
2023/03/24(金) 15:28:04.96ID:STP4y0mB
>>527
>>506の let first = &v[0]; の部分をイテレータに差し替えると
（記法は分からんが仮に let first = v.iter() かな?）
イテレータのライフタイムも参照の場合と変わらず
v.push(11);と最終行のdangerousを併存させると
capacityに関わらず問答無用にコンパイルエラーといことかな?
2023/03/24(金) 15:30:39.43ID:+nRUfXDq
>>528
変数が所有している値のデストラクタが呼ばれるのはブロックを抜けた直後だけど
変数が所有しない一時的な値や変数が所有しなくなる代入前の値などは
_へ棄てるのと同じくブロック途中でデストラクタが呼ばれるね
2023/03/24(金) 15:33:55.56ID:STP4y0mB
Rustってゴミ箱（_）があるんだなw
2023/03/24(金) 15:51:46.07ID:+nRUfXDq
>>529
もちろんイテレータは参照もしくは可変参照を持つ形となるのでsingle writer or multiple readersを満たす必要がある
それを満たせなければコンパイルエラーとなりデータ競合を防げる
2023/03/24(金) 15:55:15.22ID:+nRUfXDq
>>531
棄てるのは _ へ棄てなくてもいくらでも方法があり
例えばブロックを作れば
{
let _tmp = x;
}
これで_tmpへ値が移動してブロックを抜けるときに消える

他にも例えば以下の関数を定義して
fn 棄てる<T>(_tmp: T) {
// 何もなし
}
棄てる(x); とすればその関数へ値が移動して関数ブロックを抜けるときに消える
この棄てる関数は同じものがstd::mem::drop()に用意されているので意図をはっきりさせるためにはそれを使うことで可読性を持たせる
2023/03/24(金) 17:20:54.03ID:ENxn1p6S
>>530
細かいことだけど一時的な値は内部的に一時変数が所有してることになってて一時変数がDrop scopeを抜けていなくなるタイミングでデストラクタが実行される

let _ = Foo(123);やx = Foo(456);は代入によって値の所有者がいなくなるからそのタイミングですぐにデストラクタが実行される
2023/03/24(金) 20:26:32.48ID:STP4y0mB
>>533
こういうことだわな

#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;
}
2023/03/24(金) 21:50:27.51ID:VHzrsylr
dropバグっとるがな
2023/03/24(金) 21:51:22.79ID:STP4y0mB
ごめんごめん
538デフォルトの名無しさん
垢版 |
2023/03/25(土) 09:38:10.15ID:M09ogOTB
屁臭
2023/03/25(土) 20:06:44.69ID:sd+PB/iL
>>504
そういう小さい単純な例ならばdangerousなデータ競合であると自明だが
もっと複雑化して見逃す例が実際に起きてセキュリティの穴になる
2023/03/25(土) 20:52:44.35ID:c5G720p2
デバッガですぐに分かることなので
みょうちくりんな文法を新たに覚えようという動機にはならん
2023/03/25(土) 20:56:23.22ID:VVKoWVL2
不明な挙動があるのが発見されてない時点でもデバッガ使うの？　変なコード書いた本人に自覚がないから不具合として発現するのであって、正常に動くであろうと期待できてる時点でも？
時間の無駄では？
デバッガでわかるよりコンパイラでわかるなら圧倒的にそっちがベターでもあるし
2023/03/25(土) 20:58:28.17ID:c5G720p2
>>541
>不明な挙動があるのが発見されてない時点で
それはいくらなんでも無理だろw
2023/03/25(土) 20:59:37.07ID:tC35D9u3
>>540
デバッガなど実行時でないと検知できないショボいプログラミング言語は滅びそう
昔はC++は神の言語と信じていたけどアドバンテージを全て失ってしまったもの
2023/03/25(土) 21:03:00.33ID:c5G720p2
コンパイル時点でチェックが入るのはRustの利点だが
C/C++と乖離した文法を新たに覚えるというコストを払おうとは全く思わん
俺がRustを覚えるとしたらシステムコールがRustで書かれたOSを
使うことになったときだけ
当分ない
2023/03/25(土) 21:04:16.45ID:c5G720p2
>>543
でもLockFreeQueueをsafeで実装できないんでしょ?
2023/03/25(土) 21:10:35.10ID:c5G720p2
周りに使用を強制されるほどRustは普及していないので
Rust推しの諸君は自らRustを選択したのだろうけど
そんなにCでのメモリの扱い方に苦労したのかい?
Rust使う人はどちらかというと言語マニアの人達だと思ってたのだが?
2023/03/25(土) 21:14:16.97ID:tC35D9u3
>>545
そういうのはすべてsafeなインタフェイスでライブラリが作られてるから
LockFree{Queue,Stack,Map,Set,Chanel}すべてsafeなインタフェイスを用いてRustプログラミングできるよ
2023/03/25(土) 21:17:55.09ID:fB31q3I6
>>546
開発効率と可読性が圧倒的にRust＞＞＞C++
Rustはコンパイル時点でミスが見つかるから効率良すぎ
可読性も大差でパターンマッチングの有無も大きい
2023/03/25(土) 21:18:50.17ID:c5G720p2
>>547
Rustでプログラミンしたいのではなくて
言語のウリとしている特徴の不備の一例として上げている
平たく言うと中途半端
2023/03/25(土) 21:23:11.57ID:tC35D9u3
>>549
すべてがunsafeなC++と違って
RustならLockFree{Queue,Stack,Map,Set,Chanel}をsafeなインタフェイスで使うことで自分の書くプログラムをsafeにできるよ
つまりRustコンパイラが書いたプログラムの安全性の保証をしてくれるよ
2023/03/25(土) 21:36:28.93ID:c5G720p2
>>550
Rustではsafeで全てを表現したいという目論見が破綻した
ということを指摘したい
これで良いかな?
更に良い言語が出るかもね
2023/03/25(土) 22:24:32.21ID:fB31q3I6
Rustは例えばVecすら中身はunsafeを使ったsafeなコードだらけだぞ
LockFreeも全く同様
unsafeを使ったsafeなコードで基本ライブラリを作成しsafeなインターフェースを提供できることがRustの最大の長所
それらを使うプログラムはsafeにすることが出来てコンパイル時点で各問題を排除できる
C++が敗北した理由である
2023/03/25(土) 22:28:23.02ID:c5G720p2
>>552
>Rustは例えばVecすら中身はunsafeを使ったsafeなコードだらけだぞ
だめだめじゃん
設計が間違ってるんだよ（というか無理だったんだよ）
2023/03/25(土) 23:00:19.34ID:tC35D9u3
プログラムすべてがunsafeなC++という失敗作を改善したことを設計ミスと言うのは理不尽ね
2023/03/25(土) 23:10:11.97ID:Ty/K+Fgo
>>543
C++大好きだが、神の言語とはちょっと違う希がす
2023/03/25(土) 23:25:09.01ID:c5G720p2
>>554
Rustは一過性の言語だと思うよ
C++はCを包含しているからそうそう消えないと思うが
Rustは後続の言語にオーバーライドされると思う
2023/03/25(土) 23:58:43.93ID:EBh7DtZR
現代語はコロコロ変わるが古文漢文は変化しないからそうそう消えない
理系のくせにそこに気付くとはえらいね
2023/03/26(日) 00:04:07.04ID:Vf0mvjFW
大手が採用するといったんだから当面生きてるでしょ
C/C++は進化はよ
2023/03/26(日) 00:38:53.03ID:04xno5ob
もう負けたんだよC++は
向こうの方が宣伝がうまかった
2023/03/26(日) 01:40:41.16ID:Vf0mvjFW
ついこないだまで、コルーチンだって書けなかっただろ
C++が「負け」てるのは、今に始まったことじゃない
キャッチアップしていってくれればいいんだよ
561デフォルトの名無しさん
垢版 |
2023/03/26(日) 08:24:37.76ID:4yCJuAuO
Nimは脳汁出るんだが
Rustからは出て来ない
::が邪魔しとるんかの
2023/03/26(日) 08:28:50.22ID:UQsado+I
>>543
Cは神言語だが
C++は神じゃないどころか
クソ言語だと言うのは当初から言われてた
563デフォルトの名無しさん
垢版 |
2023/03/26(日) 08:38:26.46ID:VUXuxgJn
C++はたとえリアルタイム性があっても、信頼性が求められる業務をしようとすると、どうしてもCで良いじゃんってレベルまでコーディングルールをガチガチに制約するからね。
2023/03/26(日) 08:42:34.83ID:faqu5Hbk
C++のメリットが完全に無くなったな
無理に挙げるとすれば過去のプログラムと過去のプログラマーくらいか
2023/03/26(日) 11:07:56.67ID:Vf0mvjFW
C++のメリットは自由度
自由が障壁になる用途ではメリットもクソもないｗ

C++で書きたいというニーズは当面残る
だからC++には進化してもらわないといけない
2023/03/26(日) 11:19:02.92ID:rT1rfVXr
GC無し言語でやりたいことは全部Rustでやって
C/C++には滅びて欲しい人間が増えてんだろ
プレーンCのコードぐらいRustにコンバート出来るんじゃね？
知らんけど
2023/03/26(日) 12:33:33.90ID:g6NQ2zfC
C++中毒な人が多いからね(俺含む
捨てろと言われても無理だねえｗ Rustを使わないとは一言もいってない

>>563
これまで、自由になりすぎたC++をいかに縛るかっていう試みはいくらもあったが、普及しなかった
ついにRustが答えを出した C++は「いや～負けましたね～」とかいいながら、その成果を吸収すればいい
2023/03/26(日) 13:03:12.58ID:BnHATVrm
自分で自由を縛ろうというインセンティブは働かないからね
何らかの外からの圧力がない限りなかなか増えないだろうね
キラープロダクトがあれば一気に普及するだろうけど
2023/03/26(日) 13:05:22.20ID:BnHATVrm
メモリ管理云々言ってる人もセールストークの受け売りで
自分でメモリ管理に苦労して「あ! Rustが解決法だ!」って
始めた人はいないだろうし
2023/03/26(日) 13:06:33.66ID:g6NQ2zfC
C++に依存すればするほど、これｇｄｇｄだ…ってのがわかってくるもんだけど、
どう縛るのが「正解」か、なかなか答えが出なかったんだよね
スマポどころか、ハンドルや参照カウントの概念が大昔からあったけど、決定打にならなかった
2023/03/26(日) 13:09:22.51ID:BnHATVrm
>>570
それは自然言語と同じで使う人のレベルによる
2023/03/26(日) 13:12:55.73ID:BnHATVrm
おまいらRedoxとかどうよ? GoogleのOSは一般の人は使えるの?
2023/03/26(日) 13:14:54.55ID:Lwno4Hfq
自由には需要のある自由と需要のない自由があってだな

どっちも供給されなければ胡散臭いとか偽善だとか
需要ってあなたの願望ですよね、とかいうのが自由にまつわる典型的な詭弁
2023/03/26(日) 13:19:57.22ID:BnHATVrm
需要あるから>>567の言うように
「自由になりすぎたC++をいかに縛るかっていう試みは
いくらもあったが、普及しなかった」のでは?
Rustもこのままだとone of themだろうけど
2023/03/26(日) 14:41:00.96ID:g6NQ2zfC
規格となるに足る、縛り(の規格)の決定打がなかった
あーでもないこーでもないいって、混沌を放置したのはC++の落ち度
バイナリだって肥大化し放題だったしね Cに近いC++erは、忸怩たる思いで眺めてたものさ
2023/03/26(日) 14:50:08.58ID:EIuzoBSL
ここって情報古い？
https://maku77.github.io/rust/

あと
if let Ok(hoge) = fuga {
}
って本当に可読性良くなってると思ってる？(嫌味じゃなくてマジでRust推しの人の意見聴きたい)
2023/03/26(日) 14:57:31.39ID:BnHATVrm
>>575
は? C++はISOもJISも規格あるやろ?
Rustに規格あるの?
2023/03/26(日) 15:01:34.10ID:g6NQ2zfC
>>577
大手が採用するといったんだから、採用されるバージョンが、当面のデファクトスタンダードになる
それは規格といっていいよ そして規格は、管理下で進化する
2023/03/26(日) 15:09:14.63ID:BnHATVrm
ダメだこりゃ
普及はもしするとしても30年くらいは掛かりそう
2023/03/26(日) 15:58:38.13ID:LwxNksN7
どちらを習得すればセックスできますか
2023/03/26(日) 16:29:03.94ID:v5z9D7dt
>>576
Rustの 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は可読性が増していると思う。
582デフォルトの名無しさん
垢版 |
2023/03/26(日) 18:24:04.21ID:MldEMOwI
>>576
>if let Ok(hoge) = fuga {
>}
>って本当に可読性良くなってると思ってる？
ResultやOptionが複数ネストしていくと可読性が低いコードはどうしてもできるけど単純なやつは何の問題もないと思ってる

ちなみに何と比べてる？
2023/03/26(日) 23:06:22.21ID:zumLAqyb
>>581
C++は利便性のいい代数的データ型の導入に失敗したからしょうがない
さらにパターンマッチングの導入は未だに議論中のまま進みそうにない
結果としてそのような不便で分かりにくい記述をするしかない
2023/03/26(日) 23:24:54.44ID:Lwno4Hfq
C++にはswitchを使うなunionを使うなという縛りがあった
CとC++を意図的に隔離すれば縛りを無視できるから問題視されないが
2023/03/26(日) 23:35:48.82ID:BnHATVrm
何か問題でも?
2023/03/26(日) 23:51:37.40ID:Lwno4Hfq
if letとその比較対象も、言語を統一しようと思わなければ問題ないんだろう
2023/03/27(月) 00:02:41.74ID:+gsY9S8v
ぶっちゃけRUSTでなくてもいいんだよ
安全性のためには

schemeとかHaskellみたいな言語には定義外の動作が(基本的には）存在しないという強力な安全性があるわけだし

じゃあなんでこんなにRUSTがもてはやされるのかというと、単に宣伝がうまかっただけ
2023/03/27(月) 05:32:45.27ID:UciRikyK
safe Rustには未定義動作が存在しない
そしてunsafeを用いてsafeなインタフェースを提供する時にもそれが義務付けられている
したがってそれらを用いるRustに未定義動作は存在しない
未定義動作まみれのC/C++との決定的な違いである
2023/03/27(月) 06:40:49.82ID:xp5TMlgQ
間違うヤツが悪い、って世代の規格だもんな、変に不親切は徹底してるわｗ
590デフォルトの名無しさん
垢版 |
2023/03/27(月) 11:50:25.04ID:kviG1IE2
C++に憧れるのをやめましょう
憧れてしまったら超えられないんで
2023/03/27(月) 12:09:54.31ID:iTDWuTVq
>>581
Rustの代数的データ型であるenumに対して
対応するC++のstd::variantは五重苦だよな
・機能が弱い
・使いにくい
・見にくい
・使われていない
・知られていない
C++の機能強化は尽く失敗していて進化が望めない
2023/03/27(月) 12:10:13.46ID:B8NoQCc/
>>588
safeと限定しているところが誠実で笑える
良いと思うよ!w
593デフォルトの名無しさん
垢版 |
2023/03/27(月) 12:48:40.60ID:8vpfa9xS
まぁRust使うくらいならC++使うよねってのはあるよね
これまでの資産が全然違うわ
DirectXとかOpenGLとかオーディオ系の低レイヤーのやつはやっぱりC++が強い
594デフォルトの名無しさん
垢版 |
2023/03/27(月) 12:49:34.80ID:8vpfa9xS
Rust信者が全部ラッパー作ってくれるならまぁわからんでも無いけど君たちどうせ人が作ったライブラリしか使わないんでしょ？
2023/03/27(月) 13:03:55.96ID:03NojB4M
大手が採用するっていうんだから、大手がどんどんライブラリ置き換えやるでしょ
ただラッパ書くだけじゃなくて、Rustで書けばAPIを適切に使用してるって保証されるものじゃないとね
2023/03/27(月) 13:12:32.89ID:B8NoQCc/
人任せだなw
Cと共存なんて考えだと廃れて消えると思うよ
カーネルからRustにしないとな
以下の考察は俺も同じ印象を持っている

RustもJuliaやGoみたいに廃れて消えていく気がしている。
https://qiita.com/AKKYM/items/78c04840bc72d9db834d
2023/03/27(月) 13:14:48.15ID:B8NoQCc/
技術的な良し悪しとしてはRustは充分だと思うけど
言語が使われるかどうかはその上の生態学の問題だからね
2023/03/27(月) 13:36:37.38ID:f2pr1T08
なんでカーネルとシェルが共存する現実を学ぶことすらできないんだろうなあ
スマホにはシェルスクリプトがないから？
2023/03/27(月) 13:46:30.78ID:B8NoQCc/
カーネルから書かないと
諸君のフラストレーションは解消されないと思うよ
2023/03/27(月) 13:50:47.73ID:B8NoQCc/
打倒するC++の最大の特徴はCを包含していること
C++覚えればCの知識は付いてくるが
CとRust両方覚えるの面倒やん?
CをリプレースしなければC++もリプレスできん
2023/03/27(月) 14:18:03.99ID:arDcYvab
>>591
C++の可読性の低さはそのような無理矢理な機能拡張の失敗にある
602デフォルトの名無しさん
垢版 |
2023/03/27(月) 14:34:40.20ID:kviG1IE2
>>576
https://qiita.com/tatsuya6502/items/cd41599291e2e5f38a4a
2023/03/27(月) 14:43:24.48ID:kviG1IE2
>>600
>C++覚えればCの知識は付いてくるが

doubt
2023/03/27(月) 14:44:18.04ID:44rZZrUP
>>603
反例は?
2023/03/27(月) 14:59:46.99ID:kviG1IE2
>>596
>TypeScriptはずっと流行っていてこれから廃れていく気はしない。この差はなんなんだろう。。。

たいしたことやってないから
606デフォルトの名無しさん
垢版 |
2023/03/27(月) 16:45:29.16ID:qgA22f4o
>>596
Qiitaって5chと同レベルだったんだな
記事もコメントもここまで酷いとは
2023/03/27(月) 17:02:39.76ID:V0RoakbK
酷いのはお前の頭と顔だよ
2023/03/27(月) 17:10:12.43ID:f4PBXzjX
>>606
記事はバカだけどコメントはまあいいんじゃね？
それよりも、Rustを置き換えられる言語が出現しないと、Rustの天下が続きそ。
C並みに高速で何でも書けてGCもなく、にも関わらず様々な安全性が静的に保証される言語が、Rust以外に芽も出てこなさげ。
609デフォルトの名無しさん
垢版 |
2023/03/27(月) 17:19:21.38ID:8vpfa9xS
>>605
MSだから
2023/03/27(月) 17:23:03.66ID:ztwrSg39
何が続きそ。だよ
自演バレないように新文体開拓しようとしてんのマジでキモいわ
611デフォルトの名無しさん
垢版 |
2023/03/27(月) 17:26:14.23ID:8vpfa9xS
コメントしたった

TypeScriptはC#やDelphiを作ったアンダースヘルスバーグが設計してるからです
以上
612デフォルトの名無しさん
垢版 |
2023/03/27(月) 17:26:50.78ID:8vpfa9xS
Rustまだ全然天下じゃないんだが…
周り見えてない人なのかな？
613デフォルトの名無しさん
垢版 |
2023/03/27(月) 17:27:28.03ID:8vpfa9xS
言うほどガベコレ悪いか？って話になるんだが君たち何を作ってんだ？
614デフォルトの名無しさん
垢版 |
2023/03/27(月) 17:28:15.22ID:8vpfa9xS
言うほど1フレーム1フレームの処理落ちが問題になることしてんの？
ゲームくらいじゃね？
615デフォルトの名無しさん
垢版 |
2023/03/27(月) 17:28:57.15ID:8vpfa9xS
その点ゲームでRustは使われない
マジで何してんの？って話よな
616デフォルトの名無しさん
垢版 |
2023/03/27(月) 17:35:59.10ID:tLmo//P+
>>614
車載ソフト関係だけど、命に関わるようなシステムは最大実行時間を理論的に算出出来ないとアカんのや
GCだとそれが出来ないから論外なんや、、
617デフォルトの名無しさん
垢版 |
2023/03/27(月) 17:37:53.83ID:8vpfa9xS
>>616
ほんでその車載ソフトはRustで書かれんのか？
618デフォルトの名無しさん
垢版 |
2023/03/27(月) 17:39:01.06ID:tLmo//P+
>>617
いや、まだ言語的に対応してないからC/C++だね、、
619デフォルトの名無しさん
垢版 |
2023/03/27(月) 17:40:35.92ID:8vpfa9xS
>>618
やっぱりね
いつになるんだろうねRustが対応するの
一生来ないかもしれん
620デフォルトの名無しさん
垢版 |
2023/03/27(月) 17:52:34.31ID:tLmo//P+
>>619
そうやね
ぶっちゃけ危なそうなものはコーディングルールで縛られるし、過去トラブルや不具合対策も沢山あるから困らないんだよね。
品質保証のためにアセンブラも見るけど、C/C++はアセンブラと比べながら見やすいし
621デフォルトの名無しさん
垢版 |
2023/03/27(月) 18:00:15.28ID:BAd7DBJ1
>>616
そこでリアルタイムGCですよ
2023/03/27(月) 18:06:46.35ID:f2pr1T08
噂によると節電のためにRustを使うらしいな
電気代よりも例えば家賃の方がよっぽど高い人生だったら一生使わないのでは
2023/03/27(月) 18:13:00.08ID:arDcYvab
このままC++は消えていくだろう
アドバンテージが何も残っていない
2023/03/27(月) 18:17:46.08ID:9iT9giTF
上の方で
「Rustのライブラリはあらかた揃って退屈なメンテ作業しか残ってない状態、そんなつまらない作業誰もしないから誰もメンテしなくなってだんだん人が離れていく一歩手前」みたいなQiiitaの記事あったけど、そんなライブラリ充実し始めてる？
625デフォルトの名無しさん
垢版 |
2023/03/27(月) 18:18:17.10ID:8vpfa9xS
>>624
いやしてないよ
2023/03/27(月) 18:27:56.70ID:IKh8n5QH
新規プロジェクトは大方Rustになったが
既存プロジェクトは大規模な更新でしか切り替わらないだろな
2023/03/27(月) 18:43:27.53ID:9iT9giTF
どっちかって言うと今Pythonとかでちゃんと動いてる、例えばAI用のテンソル計算処理、統計処理のライブラリをRuby用のために用意し直すのっていわゆる「車輪の再発明」みたいになってしまうからわざわざRustに移植するのってどうなん的な感じで充実してこないんじゃないかという気はする
ライブラリが充実してきてみんなが使い出すかどうかって技術的な問題だけじゃなくてその言語が出てきたタイミングとか社会情勢とか背景とかそういう要素もかなり濃密に効いてて、その意味でPythonはすげぇタイミングよかったという気はする
628デフォルトの名無しさん
垢版 |
2023/03/27(月) 19:22:16.60ID:dqg9sWUs
Rustで仕事してないやつらばかりだの
儲かるから流行るんだぞ
2023/03/27(月) 19:23:51.08ID:IKh8n5QH
既存のものを移植するのは無駄な行為
既存のものはそのまま使えば良くそのまま使われている
新たなものはRustになっている
それだけの話
2023/03/27(月) 19:25:47.39ID:ZBCIgMCl
Rustの仕事あるかい？
2023/03/27(月) 19:33:28.90ID:byKu+Dgz
>>627
rustもキラープロダクトが出れば一気に普及する
2023/03/27(月) 19:43:52.09ID:f4PBXzjX
>>622
節電というか、こちらはクラウド利用だけど間接的には当たりじゃね？
GC言語からRustへだけど、CPUコストとメモリコストが激減、だからクラウド側では節電となり、Rustはエコ。
GCなく自動メモリ解放する言語Rustの出現が今までの流れを変えた。
2023/03/27(月) 20:10:16.56ID:eSmIEcJi
Rustへの動きは2系統あるよな
C/C++からRustへの安全性を高める動き
GC言語からRustへの高速化＆省メモリ化の動き
まれに片方の動きの意識しかない人が想像力の欠如した書き込みをしている
2023/03/27(月) 20:59:51.90ID:f2pr1T08
目的は1つだけ・手段はいくらでもあるという世界観はしつこく宣伝されてきた
逆に1つの道具で色々できるという話はあまり聞かない
2023/03/27(月) 21:16:18.71ID:ztwrSg39
Rust製のTurbopackでjsのバンドルが数百倍高速になってもじゃあ俺もRust使おうとはならんのよ
AWSのバックエンドでRust使ってエネルギー効率が向上してもじゃあ俺もRust使おうとはならんのよ

理性的に考えろ
636デフォルトの名無しさん
垢版 |
2023/03/27(月) 21:18:03.30ID:CXyrf6Yu
オジの自演は特徴出すぎで草
こちらはクラウド利用www
2023/03/27(月) 21:25:42.06ID:B8NoQCc/
Windows3.1からMacOSにも流れなかったし
Cのニッチェを奪わなければRustはこの先生
きのこれない
638デフォルトの名無しさん
垢版 |
2023/03/27(月) 21:59:50.76ID:dqg9sWUs
アンチは願望ばっかだな
エンジニアの上澄が認めたのだから争っても無駄
639デフォルトの名無しさん
垢版 |
2023/03/27(月) 22:10:09.18ID:B8NoQCc/
>>638
儲かってる人ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
Rustで何開発してるの?
2023/03/27(月) 23:10:41.22ID:6TNfXJr3
>>608
Rustの提唱するパラダイムがうまくいきだしたら、他言語もこぞって取り込むと思う
アカンとなったら、次のパラダイムが提唱…されるのは先の話だろうなあ 俺生きてるかなまじで
2023/03/27(月) 23:13:47.59ID:xSQDJ/La
js、ptyhon、やってきて
rustは新鮮で学べてるけど
c++はやばくね、、、
依存やらのコンパイルの時点で挫折しそうなんだが
ドキュメントもわけわからんし
2023/03/27(月) 23:20:50.21ID:B8NoQCc/
>>640
所有権って途中から取り込めるの?
パターンマッチングとかは余裕だろうけど
643デフォルトの名無しさん
垢版 |
2023/03/27(月) 23:43:11.84ID:Y8evRbQy
余裕だろ
ただ他言語もこぞってと言ってもGC言語は対象外なのでメジャーな言語で可能性があるのはC++のみ
2023/03/27(月) 23:51:52.30ID:B8NoQCc/
>>643
デフォルトでコピーコンストラクタやコピー代入演算子が起動するところを
moveコンストラクタやmove代入演算子が起動するように変更するってことでしょ?
余裕な訳ないじゃん
copy by valueな言語では後方互換性が犠牲になるので導入無理だよ
645デフォルトの名無しさん
垢版 |
2023/03/28(火) 00:23:27.41ID:Q1TWiepd
>>644
いろんなやり方があるけど実装ができないようなものはない
やろうとすればどのやり方にするのがいいか
細かい仕様をどうするのがいいか
そういう意思決定に時間がかかるだけ

所有権システムをあとから取り込めないなんて発想をする人がRustを宣伝してるのがむしろ驚き
646デフォルトの名無しさん
垢版 |
2023/03/28(火) 00:42:21.55ID:ecLsJgbH
>>645
文章読めないのかな?
今まででのコードでインスタンスがコピーされるところを
勝手にmoveにすり替えられたら大惨事だろw
今まで書いたコードを全部書き換えることになる
つまり後方互換性が犠牲になる
C++の開発当初からの方針で最大の特徴はCを内包していること
CもC++もcopy-by-valueな言語
647デフォルトの名無しさん
垢版 |
2023/03/28(火) 00:54:04.89ID:9+wNikJy
視野の狭い人だな
2023/03/28(火) 01:08:09.67ID:ecLsJgbH
>>647
問題についてどう解決するかを書きな?
2023/03/28(火) 01:35:54.97ID:m2o7Qw0d
既にCとC++に互換性はない
しかし許された
また同じことをやってまた許されることは可能かもな
2023/03/28(火) 01:46:32.83ID:ImlVuHSq
まあ拡張子変えれば許されるよcpoとか
あとはsafeブロックとか？
2023/03/28(火) 02:00:41.86ID:ecLsJgbH
>>649
ほぼ互換性あるだろ? どういったケースのこと書いてるの?
652デフォルトの名無しさん
垢版 |
2023/03/28(火) 02:21:00.53ID:gbUXYbOA
>>626
新規プロジェクトって例えばどれよ？
653デフォルトの名無しさん
垢版 |
2023/03/28(火) 02:21:41.39ID:gbUXYbOA
>>628
なんの仕事してんの？
654デフォルトの名無しさん
垢版 |
2023/03/28(火) 02:22:00.97ID:WlqhC76+
>>644
>デフォルトでコピーコンストラクタやコピー代入演算子が起動するところを
>moveコンストラクタやmove代入演算子が起動するように変更するってことでしょ?
アフォ発見！
655デフォルトの名無しさん
垢版 |
2023/03/28(火) 02:24:01.41ID:gbUXYbOA
>>641
オブジェクト指向できてないからだろそれ
C#学べ
2023/03/28(火) 02:25:39.63ID:6yQ3WRoT
>>642
パターンマッチング導入はC++23でも無理
出てる案では便利になりそうにない
こればっかりは結果論になってしまうがRustと比較するとこれまでの基本設計が失敗してる
2023/03/28(火) 02:31:45.17ID:6yQ3WRoT
>>644
現状のスマポとmoveを用いたC++の所有権システムはRustのシンプルな記述と比べると面倒で忘れたりミスしたりしてしまうがあれが限界っぽい
後方互換性を保ったままC++を快適にするのは不可能
2023/03/28(火) 02:43:54.99ID:6yQ3WRoT
>>655
そいつが書いている3つの言語ともにオブジェクト指向なのでC#は不要だろう
Pythonは普通
JavaScriptはプロトタイプ方式の継承だがそれ以外は普通
Rustは継承を排除していて機能(メソッド群)毎にトレイトで合成するがそれ以外は普通
659デフォルトの名無しさん
垢版 |
2023/03/28(火) 03:31:25.51ID:gbUXYbOA
>>658
Pythonやってるやつはオブジェクト指向理解できてないやつ多いよ
JavaScriptはまぁ基本使わんし
Rustはオブジェクト指向的なことできるようにしてるけどオブジェクト指向わからんやつ向けに制限かけてるって印象
2023/03/28(火) 05:56:18.37ID:uty8q6BB
複雑になりすぎないようにするのは、それはそれでメリットでもある
C++では、やたらとややこしいクラスが上がってくる
それ〇〇使いたいだけちゃうん、みたいな

Rustが普及したら、Rust流のスマポにみんな慣れるから、自分の母語でも使うようになるよ
2023/03/28(火) 06:40:30.67ID:qh0NVSBO
>>659
その3つの言語をやってることから例えばウェブ方面だとしても
PythonでDjangoなどのフレームワークを使うにはオブジェクト指向は基本知識として不可欠
JavaScriptもReactなどののフレームワークを使うにはオブジェクト指向は基本知識として不可欠
Rustに対してはデタラメな印象だけで基礎的な理解すらなし
このスレで連投してる人の中で最もレベル低すぎ
2023/03/28(火) 06:47:56.40ID:uty8q6BB
C++のOOPって、CRTPとかがすっと書ける、読めるレベルだからねえ
そんな難しくないけど、美しく書くには多少の経験は必要

あと、吐かれるコードにはもうちょい気を留めてほしいなと、マシン語寄りの俺は思っちゃうな
「そういう」用途ばっかりじゃないのはわかるんだけど
2023/03/28(火) 07:05:58.21ID:uty8q6BB
そういや気にしてなかったけど
webも、APIがOOP式で提供されてるから、OOP無関係とは言えないけど、
自分でどんどんクラスを編み出して問題解決するC++とは、OOPに向かう姿勢は異なってくるね

クラスは簡潔なほうが、結局効率もいいんだけどねｗ
2023/03/28(火) 07:15:22.07ID:qh0NVSBO
>>663
それはPythonでもJavaScriptでも同じ
Web APIと関係なくプログラム独自の部分も自分でどんどんクラスを編み出して問題解決する
他を知らないためC++だけを何か特別だと思い込んでそうだな
2023/03/28(火) 07:20:37.19ID:uty8q6BB
>>659 をちょっとだけ擁護してみたくなっただけだよｗ
どこだって、ライブラリ作成者はOOPに精通してるもんだが、
C++は、OOPに精通してないと、使ってますとか公言できないもんね
むっちゃ煽られるよｗ その違いはあるなって思った
2023/03/28(火) 07:41:04.68ID:qh0NVSBO
OOPは精通するしないとか難しいものではないだろ
初心者かね
2023/03/28(火) 07:49:36.20ID:uty8q6BB
C++でOOPができるといったら、当然のようにSTLが使え、boostが使える
あるいは、traitsやattribute,constexpr を織り交ぜて、ほぼゼロサンクなバイナリを叩き出せるレベル
俺は初心者だからそのレベルにはないな

ちょっとよそよりは要求レベルは高いだろって思ってる
母語のことはちょっとだけ誇りに思ってるけど、それより、一長一短的立場
2023/03/28(火) 08:58:26.51ID:C7yLEzi8
上のほうでだれかいってたけど、まともなC++erは、スマポくらい使えて当然
なんだけど…ソース単位で生ポ禁止ってのが普及しないんだよね
2023/03/28(火) 09:04:22.01ID:u9f8RzdU
newを書かなきゃ良いだけなのにね
670デフォルトの名無しさん
垢版 |
2023/03/28(火) 09:37:27.95ID:fedCMYV9
>>661
嫌だからわかってないんだってばこいつはさ
だからC++の依存関係で頭パンクすんだよ
671デフォルトの名無しさん
垢版 |
2023/03/28(火) 09:39:21.00ID:fedCMYV9
とりあえず
>>641
こいつがオブジェクト指向理解してないのは確かだろ
672デフォルトの名無しさん
垢版 |
2023/03/28(火) 09:56:21.67ID:cZnvlJgt
>>661
君がオブジェクト指向理解できてなさそう
2023/03/28(火) 10:06:33.49ID:C7yLEzi8
>>669
C++も なんでもスタックに置きたいんだけど、きつきつなのが本来なんだよね
どんどんスタックを食うのは野暮っていう流儀もある

Rust流はメモリ使用の局所化を促進するから、
メモリキャッシュまで考慮すると、悔しいけどC++より効率出る余地がある
まあ実測してみないと、知らんけどｗ
674デフォルトの名無しさん
垢版 |
2023/03/28(火) 10:06:36.56ID:vBvHBfxi
>どんどんクラスを編み出して問題解決する
奴はクラスを書けたらオブジェクト指向を理解してると思ってるみたいだからな
675デフォルトの名無しさん
垢版 |
2023/03/28(火) 10:09:59.68ID:fedCMYV9
>>674
確かになw
普通逆で一番抽象化できるところで遡ってツリー形式にやっていくもんだもんな
2023/03/28(火) 10:28:38.80ID:u9f8RzdU
>>673
「newを書かなきゃ」ってのは
make_uniqueとmake_sharedを使えって意味でした
2023/03/28(火) 10:51:13.90ID:P0df9Gxx
JavaScriptとPythonは
極力オブジェクト指向的な書き方をしないほうが
メンテナンス性も可読性も高まる言語だから
C++やC#とは事情が違うわな
2023/03/28(火) 17:06:18.21ID:aUMSgZvE
>>662
CRTPは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)」といちいちダウンキャストをしなければならない
このように「美しくない無駄なコード」になっている
つづく
2023/03/28(火) 17:07:43.55ID:aUMSgZvE
>>678のつづき
一方で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を「美しくない無駄なコード」とはいえ使わざるをえない
2023/03/28(火) 17:58:49.48ID:C7yLEzi8
>>678-679
早まるな、俺は【CRTPが】美しいとは言ってない
初めて見たときは、なんじゃこりゃすげぇとは思ったけどねｗ
2023/03/28(火) 20:04:32.17ID:jfKwOIRn
>>679
CRTPを使わないで仮想関数にすると実行時のvtable経由のオーバーヘッドがあるんだよな
Rustは何も指定しなくてもCRTPと同じ状況になるから記述はシンプルで実行時オーバーヘッドもなく速いわけか
682デフォルトの名無しさん
垢版 |
2023/03/28(火) 20:17:15.74ID:fedCMYV9
そういえば初心者向けのサイト無いな
アイペンテックとか？
2023/03/28(火) 20:32:01.59ID:iKmwqFtY
C++のオブジェクト指向は動的ポリモーフィズムだから遅い
関数呼び出しのvtableオーバーヘッドがあるだけでなくインライン展開ができず最適化の機会も失われている
Rustは基本が静的ポリモーフィズムだからそれらのコストがなく速い
2023/03/28(火) 20:33:07.14ID:QUV/Fh6a
CRTP使うと全部インライン展開されるのマジで不思議だよな
2023/03/28(火) 21:00:58.63ID:HSIaJTs3
>>684
適当なことを言うと規格票で殴り殺される
それがC++村の掟
悪いことは言わない
君はここから早く撤退したほうがいい
686デフォルトの名無しさん
垢版 |
2023/03/28(火) 21:30:24.26ID:pvMX8JEc
>>627
Rubyの話はもういいよ
2023/03/28(火) 21:35:05.32ID:iKmwqFtY
>>684
CRTPを使えば常にインライン展開されるわけではない
CRTPを使った時のみ(vtable経由にならず静的に動作が確定するため)インライン展開が可能となり最適化の可能性も広がり速くなるという話
C++ではCRTPを使わないとRustと同等の速さになれない
688デフォルトの名無しさん
垢版 |
2023/03/28(火) 22:58:28.07ID:rZiXTukV
vtableが重く感じるとかどんな環境やねん。どうせエアプやろ。
2023/03/28(火) 23:08:36.42ID:u9f8RzdU
呼び出し回数多いと馬鹿にならんよ
2023/03/29(水) 00:01:28.04ID:jlgG+N1i
vtableが重いというよりインライン展開＋αの最適化が効かなくなるのが問題なんでしょ
使ってる関数が常に固定値（nullとか）を返すって事前に分かればそれによって分岐の整理ができたりするけど
間にvtableが挟まるとそういう予測が難しくなる
2023/03/29(水) 00:09:55.54ID:jqKX3lj0
>>687
CRTPを使わないと真に実現できないのはメソッド記法だけ

そしてvtableとインライン展開に君が想像するような関係性は無い
というか、同じ推論をRustで適用すれば「object-safeなtraitへのimplはvtableを量産しインライン展開を阻害するので悪、やめろ」ということにならないかい？

自分が何を書こうとしているのかよく考えてから書き込むことだ
2023/03/29(水) 00:26:00.18ID:hbkToQM4
C++もRustも、OOPなアセンブラの用途があるからね
少々vtableを経ても平気だとしても、そういうバイナリ吐いてほしくないときはある
バイナリは覗かれるもの
693デフォルトの名無しさん
垢版 |
2023/03/29(水) 02:17:33.72ID:0e8thR9U
こういうしょーもない連中に限ってvtableによって速度が何%落ちるかなんて測ったこともないんだよ。
馬鹿馬鹿しい。
2023/03/29(水) 03:03:32.31ID:F3x5gAOr
>>688
vtableの参照による速度低下よりも最適化できないことによる関数呼び出しのコストが重い
例えば>>679のRust及びCRTPで書かれたC++コードはどちらもadd2()関数呼び出しの中身は最適化されて単なる「add 2」となる
しかしCRTPを用いずにC++で書くとadd2()関数呼び出しの中身は「vtable参照」＋「add1()関数呼び出し」＋「add 1」を2回することになる
2023/03/29(水) 08:27:05.33ID:hbkToQM4
>>693
パフォーマンスを測るまでもなく、吐かれるバイナリの汚さ
書いた一言一句が何になるか、気になって仕方ないのがC++erだよ(諸派あり、用途にもよる
バイナリエディタに放り込んだらわかるまである
2023/03/29(水) 08:41:42.91ID:jqKX3lj0
>>694
おっ、そうだな
https://godbolt.org/z/M71z9cx74
2023/03/29(水) 09:39:43.93ID:gptXJHJd
この英語版wikipediaのC++サンプルコードとコンパイル結果が詳しい
https://en.wikipedia.org/wiki/Virtual_method_table#Example
CRTPを使わないとvirtual method tableが出てきて不利になる
698デフォルトの名無しさん
垢版 |
2023/03/29(水) 10:58:30.49ID:DCEr0ZuV
CRTPが嫌ならテンプレート分ければいいだけでは？
2023/03/29(水) 11:49:15.76ID:KmrCY6Bh
>>678
これってダウンキャスト入ってるから危険なこともできそう
相当するコードは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;
}
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になると思ってたんだがはて?
2023/03/29(水) 12:42:03.29ID:KmrCY6Bh
そもそもBarはFooを継承してないんだから
ダウンキャストのところでコンパイルエラー出て良いようなもんだけど
何で通すんだろ? templateだとチェックを緩和してるのかな?
あるいはコンパイラのバグかな?
$ g++ --version
g++ (Debian 10.2.1-6) 10.2.1 20210110
2023/03/29(水) 12:43:14.11ID:KmrCY6Bh
-ダウンキャストのところでコンパイルエラー出て良いようなもんだけど
+static_cast<T*>(this)->add1();のところでコンパイルエラー出て良いようなもんだけど
2023/03/29(水) 12:55:36.31ID:jlgG+N1i
最近のC++はよく分からんけどその例だとadd2使わないと多分変なことにならない
doubleをint扱いして1足しても1/(2^53)（←不正確、指数部による）くらいしか変動しないのかな
FooもBarもAddN継承してるからstatic_castでコンパイルエラーは出ないはず

Rustはクラス継承がないからstatic_castとの正確な比較はできない
traitで似たようなコード書くときはSelfキーワードで自分の型を指すからダウンキャスト必要ないし
敢えてstatic_castと対応させるならtransmuteだろうけどunsafe付きの関数だから危険でもコンパイルは通せる
（unsafeを使う範囲の安全性保証はプログラマの責任）
2023/03/29(水) 13:10:19.46ID:KmrCY6Bh
>>703
>最近の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*にもダウンキャストできるってことね
ありがとう
2023/03/29(水) 13:47:10.36ID:KmrCY6Bh
正当?なC++的にはdynamic_castすべきなんじゃなかろうかって思うんだよね
でそれはvtable介してadd1にアクセスするのと変わらない
プログラマの責任でstatic_castして効率化する
ってテクニックは俺は割と好きだけども
2023/03/29(水) 14:18:14.91ID:JN59fMMe
>>703
transmuteはダウンキャストではなく任意の型同士の強引な型変換(読み替え)だから当然unsafe
一方でダウンキャストは親から子、基底から派生、抽象から具体への変換を指す
Rustの場合は抽象的なトレイトから具体的な型への変換がダウンキャストとなる

Rustは基本的には静的ポリモーフィズムで
コンパイル時点で各具体的な型のコードへ安全に置き換わるモノモーフィズムなので
C++のstatic_castのような危険のあるダウンキャストを必要としないが正解

Rustでもdyn Traitを用いた場合のみ動的ポリモーフィズムとなり
C++のdynamic_castと同様に実行時ダウンキャストがdowncast()/downcast_ref()/downcast_mut()で可能だが
C++とは異なりRustはNull安全でダウンキャストできる
2023/03/29(水) 14:59:38.14ID:hbkToQM4
そこは、わずかにコストを支払って、reinterpret_castでもいいとは思うけどね
2023/03/29(水) 15:00:17.60ID:hbkToQM4
ああちがう、reinterpret_castを避ける、だ
2023/03/29(水) 15:30:35.32ID:jlgG+N1i
動的検査のコストよりもキャストに失敗した時の分岐処理のせいで最適化が阻害されるのを問題視してる感じ
かといって分岐しないなら動的検査の意味ないし
710デフォルトの名無しさん
垢版 |
2023/03/29(水) 15:35:36.31ID:jd4hHaC+
>>706
ダウンキャストの根本的な問題点を理解してないね
静的か動的かUBかどうかは副次的な問題点に過ぎない
2023/03/29(水) 15:40:07.88ID:R/bWJVR7
Rustのポインタ(参照)のNull安全ってすごく上手い仕組みだな
C++の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安全になるんじゃないか？
2023/03/29(水) 15:45:49.19ID:RttupHdJ
>>710はいつものデタラメ言いがかり君に似てる
闇雲に否定して別の問題点があると主張しつつ
その問題点を述べることは一切ないので書き込みの中身がない
713デフォルトの名無しさん
垢版 |
2023/03/29(水) 17:50:54.05ID:aWl/4JyA
>>711
デフォルトmoveの導入は無理だと思ってるくせにNull安全は導入できると思ってるのかw
オツム弱っww
2023/03/29(水) 18:18:44.67ID:eKurmGUm
たぶん人違いじゃないかな？
dynamic_castの返り値を確認しないやつは
流石におらんと思うよ
静的に確認してくれても全く嬉しくない
2023/03/29(水) 18:19:38.85ID:eKurmGUm
訂正
静的に確認を強制されても嬉しくない
2023/03/29(水) 18:50:51.61ID:3DtieHtv
ヌルポインタが返る全ての関数についてそうしないとヌル安全にならない
ヌルを使ってはダメ
2023/03/29(水) 19:05:30.65ID:KmrCY6Bh
それは当然だよ
C++では指し示した先にインスタンスがあるかどうか
分からんときにのみポインタを使う
確実にあるときは参照を使うのが流儀
ポインタが使われるところではnullptrのチェックを行う
この流儀の部分を守らないスカタンが問題なんだな
Cに参照がないので上記流儀が守られないことも問題
2023/03/29(水) 19:30:08.82ID:ap6Xt56V
>>704
なぜそのC++のプログラムは正しく動かいていないの？
bar.yはadd2()で0.2足されて0.1から0.3にならないといけないのに0.1のままになってる
>>699のソースコードを見ても正しく動かない原因がよくわからない
2023/03/29(水) 19:36:28.24ID:KmrCY6Bh
>>718
BarはAddN<Bar>ではなくAddN<Foo>を継承しているから
2023/03/29(水) 19:41:07.31ID:ap6Xt56V
>>719
add2()としてBarの+0.2が使われずFooの+2か使われるということ？
bar.yが2.1になっていないのはなぜ？
2023/03/29(水) 19:53:07.69ID:KmrCY6Bh
templateを展開すると
void Add <Foo>::add2() {
static_cast<Foo*>(this)->add1();
static_cast<Foo*>(this)->add1();
}
thisはBarの基底AddN<Foo>*のポインタ
これをBarと無関係のFoo*にキャストしたら動作は不定
2023/03/29(水) 20:09:37.10ID:ap6Xt56V
なるほど
浮動小数点に対してそれを整数と見て+2してしまっているのかな
本来はコンパイル段階でエラーにしないとやばそうだ
今回はっきり動いていないとわかるケースだからいいけど何となく動いてしまってるケースがあると恐ろしい
2023/03/29(水) 20:11:29.28ID:KmrCY6Bh
正当?なC++的にはdynamic_castすべきだと思うんだよね
template<typename T> struct AddN {
void add2() {
dynamic_cast<T&>(*this).add1();
dynamic_cast<T&>(*this).add1();
}
virtual ~AddN () {};
};
2023/03/29(水) 20:13:55.05ID:AtW1ukjc
静的に一意に決まるんならいいのでは
2023/03/29(水) 20:29:34.23ID:KmrCY6Bh
俺は割と好きだけどもね
2023/03/29(水) 20:42:15.15ID:rGt9yURA
C++最適化効きすぎてadd2そのものが展開されて最短コードにしかならん
2023/03/29(水) 20:50:49.78ID:ij9aGzzi
doubleのビット列をintとして扱ってインクリメントしてるから結果がおかしいんだろ
なぜコンパイラは型不一致エラーを出せないんだ？
2023/03/29(水) 21:21:00.23ID:iEVzPlea
問題があれば何でもコンパイル時点でエラーを出してくれるRustを使おう
実行デバッグが激減して開発効率も高い
2023/03/29(水) 21:39:38.92ID:KmrCY6Bh
でもunsafeないとダメなんでしょ?
2023/03/29(水) 22:02:01.80ID:iEVzPlea
普通のプログラムでunsafeは出てこない
2023/03/29(水) 23:01:50.75ID:UIOCT5jB
ライブラリが一個もない状態から基本的なライブラリを作るためにunsafeが必要という話だったら
有限個のバイナリファイルが正しく出力されればいいだけなので
ソースコードをチェックしなくても出力をチェックすればいいのでは？
2023/03/30(木) 06:54:28.38ID:xjlzONIR
>>727
「違う」ところにひっかかってる traceを加えてみると誤解がとけるぞ
https://wandbox.org/permlink/AsyGpe34rpZ3en8v
733デフォルトの名無しさん
垢版 |
2023/03/30(木) 06:54:54.18ID:uZvbGS3c
そういえばJavaが全然話題にもならないが言語のヒエラルキーって

C++ 最強カミソリ
剃り残しナシ

Rust 安全カミソリ
キレテナーィ なまくら

C# イケてるが
GCがあるからダメぽ

Java 論外
ヌルポとGCがあるからダメぽ

こんな感じ？
2023/03/30(木) 07:08:43.78ID:xjlzONIR
一つ間違うと自分の手とか余計なところまで切れちゃうｗ
2023/03/30(木) 07:25:50.11ID:xjlzONIR
俺にとってのC++は、日本語だよ 物心ついたときには、C++だったんだ
氏ぬまで忘れないと思う だからある意味最強、そんな奴が結構多いんだと思う

「ちゃんと話せ」って躾けられたのも、良し悪し
2023/03/30(木) 07:29:05.38ID:Lly0YXlC
>>733
逆だろ
RustはC++ができることは何でもできる
C++はできないことが多すぎ
737デフォルトの名無しさん
垢版 |
2023/03/30(木) 07:42:11.73ID:w91B/KcY
C++が出来なくてRustが出来ることってある？
2023/03/30(木) 07:43:46.76ID:xjlzONIR
縛りプレイ
2023/03/30(木) 08:01:00.44ID:Lly0YXlC
>>737
C++はできないことが多すぎる
このスレに出てきた話だけでも
代数的データ型
パターンマッチング
各種null安全
データ競合安全
メモリ安全
など多数
2023/03/30(木) 08:18:36.82ID:PJ70lfxq
プリミティブはいろいろ備わってるから、やってできなくはないんだろうけど、
強制する方法がないから、ちっとも普及しないんだよね
2023/03/30(木) 08:28:14.61ID:Lly0YXlC
>>740
C++はそのプリミティブを多数欠いている
まさか代数的データ型をunionで頑張ればできると主張するのか？
パターンマッチングは構文だからC++には無理
データ競合を静的に検知する方法もない
2023/03/30(木) 08:32:28.84ID:PJ70lfxq
C/C++には昔から、「なければgenerateすればいいじゃん」っていう文化がある
パターンマッチングは、いまどきIDEが記述支援するんだから、やってできなくはない
データ競合やらは、「そういう」スマポを導入すればいい

でもね、みんな使わないんだわ 使われないものは、ないものとして詰られても仕方ない

あ、Cとおんなじように、入れ子になった構造体をささっと書きたいとかは思うね
もうできるようになったっけ?
2023/03/30(木) 08:35:47.70ID:2ioUidZk
Rustのマクロって結構凄くね？
2023/03/30(木) 09:18:55.32ID:PJ70lfxq
…いやまてよ、パターンマッチングって、エラー等検出のことだと思ってたけど、
パターンマッチング Rust でぐぐったら全然違うものが出てきたぜ その節は撤回 ちょっと読んでみる
745デフォルトの名無しさん
垢版 |
2023/03/30(木) 10:37:10.30ID:z+Rtq9PG
ｒ
2023/03/30(木) 10:45:06.95ID:7YA3tv0i
std::visitはパターンマッチに含まれますか
2023/03/30(木) 10:56:39.82ID:7YA3tv0i
こういうのね
提案段階の機能を除けば一番直和型を直接的に表現できていると思う
https://www.modernescpp.com/index.php/visiting-a-std-variant-with-the-overload-pattern
2023/03/30(木) 10:58:13.17ID:xP+9HiJo
パターンマッチングはC++23に入れようとしたがRustと比べて機能も弱すぎて失敗している
Rustのパターンマッチングはこんな感じで記述性や可読性を向上させている
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})です"),
}
}
2023/03/30(木) 11:05:35.09ID:wHEiYRW7
C++はユーザが多いので標準でなくてもライブラリがあるからね
Rustはユーザが少ないので標準で用意しとく必要がある
パタンマッチングは言語の話だけども
2023/03/30(木) 11:06:04.96ID:dh4KEwq/
Rust の TcpListener のサンプルについて質問です
1ページ目は無料で1ページ目だけで動作するはずですが
https://xtech.nikkei.com/atcl/nxt/column/18/01920/081600022/
何故か1byteしか受け取らず常に 404 NotFound になります
何処を治せばよいですか？
2023/03/30(木) 11:14:15.70ID:xP+9HiJo
>>747
C++のstd::variantは全体の型名を命名できない
各要素に対して専用の型を用意しなければならない
扱いづらいなど欠陥品

例えば>>748のShapeの定義例は
enum Shape {
Circle(u32),
Rectangle(u32, u32),
Parallelogram(u32, u32),
}
これだけで済む
さらに型Shapeに対して様々なメソッドを実装できる
C++ではそれぞれ困難と不可能

>>749
言語がサポートしないとライブラリでは無理
2023/03/30(木) 11:14:43.48ID:PJ70lfxq
一発目から GET / HTTP/1.1 じゃないものが来てるかもよ、buffer 表示させてみては
2023/03/30(木) 11:28:11.87ID:7YA3tv0i
>>751
記事読んだ？
2023/03/30(木) 11:32:57.91ID:xP+9HiJo
>>753
読んだけどそれでは無理
こちらはパターンマッチングのRustのコード例を>>748に出した
C++でも可能だと主張するならばそれぞれの実現コードをまず出すべき
2023/03/30(木) 11:39:46.03ID:PJ70lfxq
パターンマッチングの件、5分くらい読んできた
そういう風に書きたいっていうニーズがあるんだな、表現力を誇るC++でこれが書けないのは確かに手落ちｗ

この型はあれでもこれでもあるっていうの、あんまり扱ってこなかったけど、
上手く書けば便利になるかもね ただし、ゼロサンクでね
2023/03/30(木) 11:39:46.85ID:xP+9HiJo
>>750
そのRustのTcpListenerのサンプル動かしてみたけど普通に動いた
返すindex.htmlを用意してcargo run
ブラウザからhttp://localhost:9999/で表示された
2023/03/30(木) 11:46:33.32ID:7YA3tv0i
>>754
「無理」とだけ言われても何も分からないので具体的にお願いします
それとも記事を読んだうえでも、無理な点の指摘は>>751ですべてだということですか
例を読んでいれば「各要素に対して専用の型を用意しなければならない」は嘘だとすぐ分かるはずですが
2023/03/30(木) 11:47:15.19ID:xP+9HiJo
>>755
Rustは>>748の各パターンマッチング例をオーバーヘッド無しで処理してくれる
使わずに手動でダラダラと書ける分もパターンマッチング記述の方が最適化が良いかもしれん
2023/03/30(木) 11:49:39.34ID:xP+9HiJo
>>757
具体的に>>748にRustのパターンマッチングの各例のコードを書きました
次はC++でも可能だと主張するあなたが対応するC++のコードを出す番です
2023/03/30(木) 11:58:04.66ID:7YA3tv0i
>>759
あなたの要求に答えるために質問だけさせてください
明確にしてほしいのは「何が無理なのか」の「何」の部分です
よろしくおねがいします
2023/03/30(木) 11:58:20.56ID:PJ70lfxq
教科書的サンプルとは別に、実践的なサンプルが見たいぞ
必要だから入った仕様だろう、手ごろにどっかあるはずだ お勧めのやつをたのむ
2023/03/30(木) 11:59:10.65ID:wHEiYRW7
>>751
>>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);
}
2023/03/30(木) 12:23:51.98ID:8gDdaVz7
>>762
それだとShapeが型ではなく名前空間になってしまってるからダメでしょ
2023/03/30(木) 12:29:16.05ID:wHEiYRW7
>>763
namespaceをstructに置換して最後に;つければ?
2023/03/30(木) 12:32:22.56ID:8gDdaVz7
>>764
それだと全ての図形で必要となるメモリサイズの合計サイズが必要になっちゃうよ
2023/03/30(木) 12:32:39.23ID:wHEiYRW7
関数はstaticにする
2023/03/30(木) 12:34:53.74ID:wHEiYRW7
>>765
何か問題でも?
2023/03/30(木) 12:35:39.04ID:7YA3tv0i
>>765
メンバ型定義しただけではメンバ変数は増えないから、サイズも増えないよ
2023/03/30(木) 12:35:54.76ID:wHEiYRW7
>>763
>それだとShapeが型ではなく名前空間になってしまってるからダメでしょ
何で?
2023/03/30(木) 12:47:49.82ID:xP+9HiJo
>>760
Rustはパターンマッチングがあるため>>748のようにシンプルに記述ができて可読性にも優れている
あなたはC++でも代わりの手段で表現することが可能だと主張した
それが無理ではないことをRustコードの各々に対応する具体的なC++のコードとして示してほしい
2023/03/30(木) 12:56:56.84ID:wHEiYRW7
パターンマッチングは便利だけども必須じゃないよね
所有権システムと違って後方互換性が犠牲になることはないので
そのうちC++に入るよ
2023/03/30(木) 13:16:45.82ID:tVTq+AM2
>>769
パターンマッチング>>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)です
2023/03/30(木) 13:28:40.22ID:wHEiYRW7
>>772
>パターンマッチング>>748の2番目の例の話だからShapeは関数に渡ってくる型じゃないとまずい
何で?
2023/03/30(木) 13:31:04.03ID:wHEiYRW7
ちなみにディスパッチは>>762は静的に行われる
>>772は...
2023/03/30(木) 13:31:12.50ID:tVTq+AM2
>>773
Shape型が渡ってきてその処理をしてるからだよね
とりあえずC++の動くコードを出してみたら？
2023/03/30(木) 13:32:51.26ID:wHEiYRW7
>>775
Shape型を引数で取る必要があるならC++では
Shapeを基底として継承させるよ
もちろん静的ディスパッチはできない
2023/03/30(木) 13:35:28.76ID:wHEiYRW7
図形は典型的なオブジェクト指向の例題だから
enumを使う例としては適切ではないんじゃないかな?
Rustをよく知らん俺からしたらピンとこないよ
2023/03/30(木) 13:39:12.89ID:8gDdaVz7
>>774
ディスパッチは静的には不可能で動的にしか行われないでしょ
静的に可能なのはモノモーフィゼイションだけど今回の例では適用できませんね
いずれにしてもC++で可能だと言うコードを示してみたら？
2023/03/30(木) 13:39:52.45ID:PJ70lfxq
お、俺の>>761をだな。。
2023/03/30(木) 13:41:01.47ID:wHEiYRW7
>>778
>ディスパッチは静的には不可能で動的にしか行われないでしょ
いいえ>>762は静的に行われる

>いずれにしてもC++で可能だと言うコードを示してみたら？
>>762に示した
2023/03/30(木) 13:42:20.94ID:7YA3tv0i
https://wandbox.org/permlink/Q94E20qAAS5G8iiX
std::variantとstd::visitでパターンマッチする例です
2023/03/30(木) 13:52:02.49ID:tVTq+AM2
>>780
動くコードじゃないと意味がないのでmain()付きの動くコードを示そうよ
Rust版は>>772

>>781
パターンマッチングを全く行なっていないじゃん
例えば分かりやすくこの項目を増やすとして
Shape::Rectangle(100, h) => println!("幅100で高さ{h}の長方形です"),
これはC++でif (w == 100)のコードになるわけだよね
それはパターンマッチングとは言わないよ
2023/03/30(木) 14:01:06.19ID:7YA3tv0i
>>782
enumのバリアント判定に相当するパターンマッチを行っていますので、全く行っていないという指摘は正しくありません
また、>>748のenum_patternにShape::Rectangle(100, h)にマッチするコードは含まれておらず、あなたの当初の要求に含まれていないものです
新しい要求を後から追加して批判するのは、誠実な態度とは言えません
このようなことが無いように、「何が無理か」を明確にするよう確認したつもりでした
今後はこうしたことが無いように、事前よく確認することをお願い申し上げます

また値によるマッチについてですが、同様の考えで似たライブラリを実装された方を見つけました
こちらは値によるマッチに拡張したライブラリを実装されているようです
https://qiita.com/Naotonosato/items/a1e710de2b78346146d1
2023/03/30(木) 14:04:54.89ID:8gDdaVz7
>>781
かなり苦しいね
>>748の残り3つのパターンマッチングには応用できそうもないけど書ける？
2023/03/30(木) 14:14:54.28ID:wHEiYRW7
>>782
別に関数プロトタイプまで書いてるんだから分かりそうなものだけど...
以下は静的ディスパッチでコンパイル時に定まるよ
>>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;
}
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]);
}
2023/03/30(木) 15:01:18.46ID:wHEiYRW7
>>786
静的ディスパッチと書いているのは俺が書いた>>762と>>785のC++の例
コンパイル時にどの関数が呼ばれるか型によって決まる
2023/03/30(木) 15:04:41.33ID:PJ70lfxq
もうちょっと調べてたが、C++にもinspectってのが来そうみたいじゃん
パタンマッチングって、こんなもんが流行ってるのね、また一つ取り残されてたぜ
2023/03/30(木) 15:04:46.89ID:7YA3tv0i
>>786
いいえ、これは静的ディスパッチです
簡単に確認する方法として、生成されたアセンブリ中のvtableを確認する方法があります:
https://godbolt.org/z/1W7jGnWEd

"vtable for std::bad_variant_access:"が唯一のvtableであり、Circleなどのためのvtableはありません
このことから、動的ディスパッチは発生しないことが分かります
2023/03/30(木) 15:09:53.24ID:Evbafc70
>>789
おいおい
vtable使うことだけが動的ディスパッチだと思いこんでいるのか？
実行時にデータ内容に応じて分岐することを動的ディスパッチと言う
>>786はもちろん動的ディスパッチをしている
次に何が来るかはコンパイル時点で決まらないため静的に決定は不可能だ
2023/03/30(木) 15:10:42.88ID:wHEiYRW7
>>788
昔はなかなか規格としてまとまらなかったが最近のC++はどうした?
俺もboostに入ってたやつくらいしか追えていない
2023/03/30(木) 15:12:35.47ID:wHEiYRW7
>>790
それはRsutのコードか? C++のコードか?
2023/03/30(木) 15:20:37.87ID:Evbafc70
>>792
そのC++コードの話しかしていない
2023/03/30(木) 15:23:32.35ID:78T5MT6s
>>793
>>785は静的ディスパッチだよ
コンパイル時にどの関数が呼ばれるか定まる
2023/03/30(木) 15:29:45.34ID:7YA3tv0i
>>790
いいえ
動的ディスパッチとは、多態メソッドの呼び出し式を実行するときに、具体型に応じて実際に呼ばれる関数が振り分けられることを言います
https://en.wikipedia.org/wiki/Dynamic_dispatch

動的ディスパッチはしばしばパフォーマンスの低下をもたらすと言われますが、その最大の理由は、
選択される各関数ポインタを一度メモリから(vtableから)読み出し、それをcallする必要があることです
動的ディスパッチをどう定義するかはさておき、vtableが無い>>789ではこのパフォーマンス低下の懸念が無いことが分かります

また、「実行時にデータ内容に応じて分岐することを動的ディスパッチと言う」という定義には明らかな問題があります
それは、この定義ではmatchやifなど通常の制御構造も動的ディスパッチに当てはまってしまうということです
これは、この定義が一般的な定義から大きく逸脱していることをよく象徴的に表わしています
少なくとも「データ内容」は「型」に置き換える必要があることが分かるでしょう
2023/03/30(木) 15:38:08.65ID:RiLc+pIf
>>789
それは動的ディスパッチだよ
C++のstd::visitはstd::variantのindex()の値で実行時に分岐してる
だから>>786のような実行時になるまで何が来るか不明な場合にも対応できる
2023/03/30(木) 15:39:00.20ID:PJ70lfxq
>>791
inspectは、godboltでclangのexperimentalを遊べるようになってた
型に対しては、もうちょっとまだみたい、error: expected expression って言われた

ラムダみたいに、みんなが欲しがるものはそれでもわりと早いんだよね
一応入れとくか…みたいのは、いつまでたっても入らないｗ

ところで、godboltに、-Wlifetime ってのがみえたけど…これってもしかして
2023/03/30(木) 15:59:56.98ID:QNJ4BihP
C++の仕様を変えようという時に国語辞典の変更を許さないのはタイパ最悪だな
C++の仕様変更を許さない、とすれば秒速で終わる
2023/03/30(木) 16:08:41.30ID:7YA3tv0i
>>796
いいえ、これは動的ディスパッチではありません
「実行時になるまで何が来るか不明な場合にも対応できる」ことは、それが動的ディスパッチであることの証明にはなりません
繰り返しになりますが、>>790の「実行時にデータ内容に応じて分岐することを動的ディスパッチと言う」という定義は、一般的な定義とはまったく異なります
>>790の定義を採用する限りにおいてはその推論は正しいですが、そのためにはまずこの定義の出典および正確性を確認する必要があります
800デフォルトの名無しさん
垢版 |
2023/03/30(木) 16:15:52.14ID:tFh1pq1g
このスレレベル高いね。
文系の俺にはちんぷんかんぷん。
雑魚はPHPでもしてるわ。
2023/03/30(木) 16:26:34.28ID:8gDdaVz7
Rustはそのへんの話も明瞭で
「dyn」という予約語キーワードが出てきたものだけがvtableを使う動的ディスパッチとなるよ
>>772のRustコードは「dyn」が全く出てこないので、vtableを使う動的ディスパッチは一切無し、とわかる仕組み
802デフォルトの名無しさん
垢版 |
2023/03/30(木) 16:30:55.38ID:MJaavB8R
>>800
レベル高すぎてディスパッチが動的かどうかすらわからないからなwww
2023/03/30(木) 16:39:07.20ID:PJ70lfxq
静的にディスパッチできたらいいのか、動的にディスパッチしたいのか。なんていうかｇｄｇｄ ｗｗ
804デフォルトの名無しさん
垢版 |
2023/03/30(木) 17:58:32.57ID:/NM1S7ef
>>800
ここは「朝から暇なおじさんの学習日記」だからある意味レベル高い。
2023/03/30(木) 17:59:31.96ID:7YA3tv0i
>>801を読んで思い出しましたが、
C++では動的ディスパッチが発生する条件のひとつとして、「virtual指定子付きメンバ関数の呼び出しである」という条件があります
>>781のコードにはvirtualがまったく存在しないため、動的ディスパッチが発生しないことが分かります
>>789のようにアセンブリでvtableの生成を確認するよりも、こちらのほうがより簡単な確認方法でした
誤った情報をお伝えしてしまい、大変申し訳ございませんでした
2023/03/30(木) 18:59:14.51ID:7YA3tv0i
ちゃんと検索したらなんかもうなんでもできそうなパターンマッチライブラリあった
そうだよな、ないわけないよな
https://github.com/BowenFu/matchit.cpp
2023/03/30(木) 19:20:59.17ID:DvxUCrw+
>>801
アホか？
静的ディスパッチとはコンパイル時に呼び出す関数が決定されることだよ
match使ったら動的ディスパッチ
2023/03/30(木) 20:49:12.26ID:jpK8yCqo
>>807
Rustのenumのmatchはenumのインデックスで分岐してるだけ
C++のvariantのvisitがvariantのインデックスで分岐してるだけなのと同じ
どちらも動的ディスパッチはしていない
2023/03/30(木) 20:53:37.26ID:wHEiYRW7
条件分岐は動的ディスパッチという
実行時ディスパッチと言った方が意味分かるかな?
2023/03/30(木) 20:55:04.82ID:wHEiYRW7
動的ディスパッチというのは
インデックスによる条件分岐
仮想関数によるディスパッチを含む広い概念です
2023/03/30(木) 20:57:43.19ID:wHEiYRW7
Rustも関数のオーバーロードくらいあるだろ?
コンパイル段階でどの関数が呼ばれるかディスパッチされる
これが静的ディスパッチ（の1つ）
2023/03/30(木) 21:00:36.55ID:jpK8yCqo
>>809
嘘つき
条件分岐つまりif文があれば動的ディスパッチだと主張するのか？
全てのプログラムが動的ディスパッチをしていることになるぞ
2023/03/30(木) 21:07:23.31ID:wHEiYRW7
>>812
>条件分岐つまりif文があれば動的ディスパッチだと主張するのか？
その通り if文でどの関数を呼ぶか決めてるのであれば
それは動的ディスパッチと言う
2023/03/30(木) 21:29:24.91ID:c1ax4GEO
これらはvtableを使うわけでもないし動的ディスパッチじゃないでしょ

> Rustのenumのmatchはenumのインデックスで分岐してるだけ
> C++のvariantのvisitがvariantのインデックスで分岐してるだけなのと同じ
> どちらも動的ディスパッチはしていない
2023/03/30(木) 21:42:01.94ID:wHEiYRW7
>>814
>>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なのか
それともそれらに該当しないのかは実行時に決めているので
動的ディスパッチだよ
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が呼ばれるかは型に基づいてコンパイル時に選択される
これが静的ディスパッチ
2023/03/30(木) 21:53:29.79ID:5+VTvxRF
じゃあ>>789のC++コードは動的ディスパッチなの？
vtableは無いしstd::visitでvariantのindex()値を見て実行時に分岐してるだけだから静的ディスパッチだと書かれているけど
2023/03/30(木) 21:54:22.26ID:BpzIAh0K
ID:wHEiYRW7は一つのIDを一貫して使ってるのに対し
それにあほなレスつけて食って掛かってるほうはIDコロコロなんで
草も生えない毎度毎度のいつもの百年前から一生やってるrustスレ名物展開
2023/03/30(木) 21:57:54.63ID:wHEiYRW7
>>817
Shapeが何かによって決めてるのは実行時なので
動的ディスパッチだよ
2023/03/30(木) 21:58:56.34ID:nbxN6jLH
ID:wHEiYRW7 >>809がバカすぎる
ID:7YA3tv0i氏の>>795の説明を読もうぜ
2023/03/30(木) 22:04:55.93ID:k5ePvr4k
>>819
variantまで動的ディスパッチ扱いにするのはおかしいよ
virtual関数をvtable経由で呼ぶのが動的ディスパッチじゃないかな
2023/03/30(木) 22:06:13.90ID:wHEiYRW7
>>795
>また、「実行時にデータ内容に応じて分岐することを動的ディスパッチと言う」という定義には明らかな問題があります
>それは、この定義ではmatchやifなど通常の制御構造も動的ディスパッチに当てはまってしまうということです
何だそりゃ?w この説明の方が明らかにおかしい
2023/03/30(木) 22:08:44.12ID:7YA3tv0i
他人に教えてもらったばっかりの内容で偉そうにしてんじゃねえ
2023/03/30(木) 22:09:30.46ID:wHEiYRW7
>>821
variantは良く知らんがShapeが実際には
CircleかRectangleかParallelogramかを
実行時に判断しているので動的ディスパッチだよ
>>816との差は分かるでしょ? 分からんか?
2023/03/30(木) 22:11:02.64ID:8gDdaVz7
C++のvariantやRustのenumの値で条件分岐することを動的ディスパッチというのは無理があるんじゃないかな
それはif文を使ったら動的ディスパッチと言ってるようなもの
2023/03/30(木) 22:11:20.94ID:PJ70lfxq
まだやってら
どっちが来てもおっけーなようにtemplate<>が書けるのがC++のOOPだろ
無駄な議論 Rustもそんな感じだろ?ｗ
2023/03/30(木) 22:12:32.19ID:PJ70lfxq
っていうか、お、俺の>>761をだな。。
2023/03/30(木) 22:17:03.62ID:PQ2EGsE8
どっちも動的ディスパッチじゃなくね
コンパイル後のenum_patternにCircleでもRectangleでもRectangleでもなく
HogeAngleぶち込んでもディスパッチしてくれるのが動的じゃないの？
2023/03/30(木) 22:18:51.34ID:wHEiYRW7
>>825
>それはif文を使ったら動的ディスパッチと言ってるようなもの
>>772はShapeが何かはコンパイル時には決まりません
>>789もShapeが何かはコンパイル時には決まりません
matchやifを使うということは実行時に決めていることを意味しているので動的ディスパッチです
templateを駆使してコンパイル時に決定できる条件分岐を書けば
静的ディスパッチできるかもしれません
2023/03/30(木) 22:20:12.37ID:BpzIAh0K
静的じゃないものは動的でいいと思うけど
ディスパッチディスパッチ言ってんのは関数だけを前提にしたほうがいいんじゃない？
match についてはもとの？ディスパッチ話から分離させたほうがいいかも？
それとも元々matchの話なんだっけ？　最初の方読んでないけど

今まで関数かメソッド以外の文脈でディスパッチとか聞いたことなかったわ個人的に
2023/03/30(木) 22:22:08.75ID:PJ70lfxq
C++erは、書いたコードがディスパッチになるかは常に気にしてるからね(諸派あり
そこを雑に書くと、ぶん殴られたりするからｗ

だから、Rustの、書けばsafeになるってのは、欲しいんだなあ
生成コードに集中できる
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トレイトは動的ディスパッチとなる
2023/03/30(木) 22:27:18.66ID:wHEiYRW7
>>832
>> 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つで
実行時に条件分岐して呼ぶ関数を決めるのも動的ディスパッチと呼ぶ
仮想関数によるディスパッチより動的ディスパッチの方が広い概念だよ
2023/03/30(木) 22:39:32.69ID:Zoz9Js1j
横からすみません
Rustで日常茶飯事のこのパターンは動的ディスパッチですか？
let output = match input {
Some(input) => foo(input),
None => Default::default(),
};
2023/03/30(木) 22:47:00.93ID:PJ70lfxq
ジャンプテーブルがあれば、それはディスパッチ
2023/03/30(木) 22:56:12.40ID:7YA3tv0i
>>827
何があれば「実践的」と言えるかの条件と、そもそも何のサンプルが欲しいのか、を明確にしないと誰も何も出せないよ
2023/03/30(木) 22:56:26.39ID:8gDdaVz7
>>772はジャンプテーブルがないから動的ディスパッチじゃない
2023/03/30(木) 22:58:11.58ID:8gDdaVz7
>>834
それも動的ディスパッチじゃない

>>833が主張する『実行時に条件分岐して呼ぶ関数を決めるのも動的ディスパッチと呼ぶ』は無理があるんだよ
2023/03/30(木) 23:11:54.75ID:wHEiYRW7
>>838
俺はRust分からんのだけど
これinputがSome(input)に適合するかしないかを
実行時に判断しているんやろ? だとしたら動的ディスパッチだよ
C++のtemplateみたいに上記をコンパイル時に判断して
例えばSome(input)に適合するからDefault::default()を
コールするコードが生成されないようなら静的ディスパッチ
2023/03/30(木) 23:16:28.37ID:PJ70lfxq
>>836
いま話題にしてる もとになった、パタンマッチングを上手く使ってる実例
なるほどこれはパタンマッチングがあってこそ、キマってるねっていうか
2023/03/30(木) 23:17:10.18ID:7YA3tv0i
というか>>789の「静的ディスパッチ」もよく考えたら誤用だったわ
https://en.wikipedia.org/wiki/Static_dispatch

Rustならtrait bound付きgenerics内のtrait method呼び出しのことで良さそうだけど
C++なら……ちょっとこのwikipediaの定義もなぜかオーバーロードに限定しててビミョ〜
これはRust以外の文脈では合意された定義無い気がする
2023/03/30(木) 23:21:08.11ID:BpzIAh0K
静的か動的かはお互い認識にズレ無いと思うんよね
でも「ディスパッチ」って言うとき
言語機能として用意されてる関数オーバーロードやvirtual使ったポリモとか
動的静的に関わらずまぁそこまではディスパッチなんだけど
matchの結果やifの結果となってくるとそれって
言語の機能というより、言語の機能の機能ってことになってて
一気にぼんや〜りとしてくるんで一人一人にズレが生じるよね
2023/03/30(木) 23:21:22.01ID:PQ2EGsE8
１．どの振る舞いをするかがコンパイル時に選択される構造
２．どの振る舞いをするかが動的に選択される構造
３．振る舞いが追加されても動的に選択できる構造

パターンマッチは振る舞いの選択の話だから２
ポリモーフィズムを語る上での動的ディスパッチは３
２を動的ディスパッチと呼ぶかどうか
2023/03/30(木) 23:22:10.90ID:Zoz9Js1j
>>839
実行時にならないとSomeかNoneかわからないからプログラムを組むんですよ
コンパイル時点で決まっていたらプログラムを組む意味がありません
そしてプログラムを組めば必ずどこかに条件分岐があります
それを動的ディスパッチとは言わないと思うんです
2023/03/30(木) 23:23:46.15ID:7YA3tv0i
>>840
C++？Rust？どっち？
てかやっぱり基準が曖昧だけど、何かしら有名OSSのソースでも出せばいいの？
2023/03/30(木) 23:23:58.24ID:wHEiYRW7
>>841
>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で評価していること
2023/03/30(木) 23:27:47.63ID:BpzIAh0K
>>845
明らかにそいつは周回遅れのド素人なので
アナタ以外のみんなは単に無視してるようですよｗ
時間の無駄はおすすめしません
2023/03/30(木) 23:29:52.13ID:Zoz9Js1j
>>846
type informationとありますね
SomeもNoneも型ではありませんから
>>834は動的ディスパッチではないということになります
Rustのenumによるmatchでの分岐は動的ディスパッチではないということでよろしいでしょうか？
2023/03/30(木) 23:30:14.28ID:PJ70lfxq
>>845
RustのOSSで

>>847
よく言われるよ
2023/03/30(木) 23:31:40.58ID:wHEiYRW7
>>844
条件により振る舞いを変えること一般をディスパッチと呼ぶ

例えば>>785でmain内でfunction (cout, circle);とfunction (cout, parallelogram);では
呼ばれる関数が変わり振る舞いが変わるんだけど
これはコンパイル時に選択されます
これを静的ディスパッチと呼びます
一方で834のmatchによる分岐は静的には決まらないので
静的ディスパッチに対して動的ディスパッチと呼びます
2023/03/30(木) 23:33:00.14ID:7YA3tv0i
>>846
それはjsとかRubyとかPythonではvtableじゃなくてハッシュテーブルを使ってメソッド呼び出ししてるって意味ですよ
2023/03/30(木) 23:36:51.72ID:wHEiYRW7
>>848
それは字面に囚われていて本旨を捉えていないと思うよ
例えば憲法第二十四条第一項は「婚姻は、両性の合意のみに基いて成立し」を
根拠にして同性婚は憲法違反と主張するようなもの
2023/03/30(木) 23:39:51.85ID:Zoz9Js1j
>>850
示してくださった定義>>846には
ランタイム型情報に基づく場合が動的ディスパッチですよね
しかしSomeもNoneも静的に決まっているenum Option型の中の話ですからランタイム型情報は使っていません
したがってenumのmatchは動的ディスパッチに該当する要素が全くないため、動的ディスパッチではありません、という結論になります
2023/03/30(木) 23:42:50.15ID:7YA3tv0i
>>849
rust-lang/rustのありそうなところからテキトーに拾ったけどこれとかどうすかね
https://github.com/rust-lang/rust/blob/master/compiler/rustc_ast/src/visit.rs#L302
2023/03/30(木) 23:46:30.65ID:PJ70lfxq
>>854
これだったら、yylvalでいいよね。。
もうちょっとない?
2023/03/30(木) 23:46:56.95ID:wHEiYRW7
>>853
コンパイル時にその後の振る舞いが決まるかどうかに興味があって
それを動的か静的かと呼んで議論しているんじゃないのかな?
2023/03/30(木) 23:49:02.99ID:7YA3tv0i
>>855
これパーサじゃないです……yylvalでよくないです……
イチャモン付けたいだけならもう返しません……
2023/03/30(木) 23:49:55.47ID:8gDdaVz7
結局まとめるとこうかな？

静的ディスパッチ ← 静的に型情報が決まる場合にコンパイル時に呼び出しメソッドが確定すること
動的ディスパッチ ← 動的に型情報が決まる場合に実行時に呼び出しメソッドが確定すること

Rustのmatch文でのenumの分岐は静的に型情報は確定しているけど呼び出しメソッドを決めるわけではないので静的ディスパッチではない
Rustのmatch文でのenumの分岐は静的に型情報は確定しているため動的に型情報が決まる動的ディスパッチとは無縁
つまりRustのmatch文でのenumの分岐はどちらのディスパッチでもなく一つの型の中の値による条件分岐にすぎない
2023/03/31(金) 00:03:18.59ID:EUO40WZ7
>>858
型情報による条件分岐に限らず値による条件分岐も動的ディスパッチだよ
なぜならC++の場合typeid演算子で取ったtypeinfoオブジェクトで条件分岐したら
それは型情報なのか値なのか?両者に差はないから
2023/03/31(金) 00:05:54.81ID:EUO40WZ7
>>859
-両者に差はないから
+両者を分ける意味はないから
2023/03/31(金) 00:10:50.53ID:yzNtfP1n
>>859
この場合のディスパッチとは型情報に基づいて呼び出しメソッドを決定すること
それが静的に決まれば静的ディスパッチ
そして動的に決まれば動的ディスパッチ
型情報に基づかなければ単なる昔からの条件分岐プログラム
typeidで得られるのは型情報なのでtypeidに基づくならば動的ディスパッチに該当する
2023/03/31(金) 00:12:47.70ID:4rLmkYuJ
条件分岐は条件分岐でしかない
ディスパッチは条件分岐を用いずに振る舞いを切り替えること
2023/03/31(金) 00:14:06.22ID:EUO40WZ7
>>861
typeinfoの実装見てみ
環境違ってもそんなに変わらんと思うから
2023/03/31(金) 00:15:58.98ID:EUO40WZ7
>>862
いや条件分岐ってディスパッチやろ
2023/03/31(金) 00:18:07.60ID:4rLmkYuJ
>>864
ちゃうやろ
比較で分岐するか
次の振る舞いがあるところに飛ぶか
2023/03/31(金) 00:20:19.18ID:RaXhcLNj
C++のmatchはもういいの？
2023/03/31(金) 00:21:06.03ID:EUO40WZ7
条件により振る舞いが分岐するので同じ
2023/03/31(金) 00:22:01.37ID:E+GQTsPO
>>863
型情報を整数値で表すのは当たり前だけど
それは型情報ではない普通のデータの整数値の分岐とは話が全く違う

型情報によって呼び出すメソッドが変わるからそれを決定することをディスパッチと呼ぶ
その型情報が静的に決まるか動的にきまるかの違いのみ
typeidを使っているならば型情報が動的に決まっているのだから動的ディスパッチ
869デフォルトの名無しさん
垢版 |
2023/03/31(金) 00:23:24.62ID:XMbQ83Rx
>>834
そもそもそれをディスパッチと普通呼ぶ？

やってることはvtable使った動的ディスパッチも似たようなものだから
動的ディスパッチの一種とすることにそこまで違和感はないけど
広く浸透してる定義ではないよね
2023/03/31(金) 00:24:13.24ID:EUO40WZ7
名称はともかくmatchの分岐はコンパイル時に決まらず
実行時に比較のオーバヘッドがある認識は共通しているので
何も対立はないはず
C++のmatchの話にもどしましょ
2023/03/31(金) 00:26:02.54ID:EUO40WZ7
>>868
>型情報を整数値で表すのは当たり前だけど
>それは型情報ではない普通のデータの整数値の分岐とは話が全く違う
わかんねーよw もういいよ
2023/03/31(金) 00:33:40.04ID:RaXhcLNj
まず>>846のstatic dispatchのページからとって来た文章をdynamic dispatchの「定義」として参照するのが間違い
こりゃすでにdynamic dispatchが定義された前提の上で、static dispatchと異なる点を書いているだけだよ

自分の思い込みを肯定するために都合良く文章を解釈してしまうのは人間やりがちだけどね
2023/03/31(金) 00:34:12.53ID:4rLmkYuJ
>>867
ディスパッチは条件により分岐しない
渡された振る舞いを実行するだけ

例えば>>841のサイトのspeakに分岐処理は無いでしょ
2023/03/31(金) 00:34:43.78ID:E+GQTsPO
話は簡単
まず前提「オーバーロードにより型が決まらないと呼び出す実メソッドが決まらない」
つまり「型情報が決まると呼び出すメソッドが決まる」
この決定のことをディスパッチと呼ぶ
静的に型情報が決まる場合は静的ディスパッチが可能
動的に型情報が決まる場合は動的ディスパッチとなる

型情報と関係ない話はどちらでもない
2023/03/31(金) 00:40:10.18ID:RaXhcLNj
>>874
> まず前提「オーバーロードにより型が決まらないと呼び出す実メソッドが決まらない」
> つまり「型情報が決まると呼び出すメソッドが決まる」
> この決定のことをディスパッチと呼ぶ

ここだけ読むとオーバーロード解決に聞こえるねｗ
https://ja.cppreference.com/w/cpp/language/overload_resolution
2023/03/31(金) 01:54:38.14ID:EgdFd66u
Visitorパターン＝多重ディスパッチ説があったからそれが元凶だろう
複数のメンバー関数から一つ選ぶのもディスパッチ
だから多重という
877デフォルトの名無しさん
垢版 |
2023/03/31(金) 03:36:49.58ID:jnb+4hS9
動的ディスパッチや静的ディスパッチは
何をディスパッチするのか考えなよ
2023/03/31(金) 07:31:14.10ID:8I8WcMJF
Rustは普通に書くだけでこのスレで言うところの静的ディスパッチとなりコンパイル時点で単相化されて速い
実行時にしか型が判明しない場合に対してはdyn指定による動的ディスパッチが可能でvtableが使われる
vtableを避けたいならばenumに包むことで直和型として収容して扱うこともできる
2023/03/31(金) 09:01:13.01ID:RaXhcLNj
>>878
C++でも同じだよ
880デフォルトの名無しさん
垢版 |
2023/03/31(金) 10:05:33.29ID:TtdiO46p
vtableの持ち方がRustとC++では違うんだよね
881デフォルトの名無しさん
垢版 |
2023/03/31(金) 10:09:37.79ID:BBtS0ztF
>>877
SpringやFluxのディスパッチャーだったり
Grand Central Dispatchだったり
何に対しても使える用語だから
区別できてない人もいるんだろう
2023/03/31(金) 11:47:51.48ID:3PkVSivi
C++では、クラスが仮想関数を持つ場合、そのクラスのインスタンスに対して仮想関数テーブルが作成される。
仮想関数テーブルには、仮想関数へのポインタが含まれインスタンスに対して仮想関数が呼び出されるたびに
vtableを参照して適切な関数が呼び出される。

Rustでは動的ディスパッチを実現するためにトレイトオブジェクトが使用される。
トレイトオブジェクトには、traitオブジェクトが実装する各メソッドに対応するポインタのリストが含まれていて
インスタンスに対してメソッドが呼び出されるたびに、トレイトオブジェクトが参照され
適切なポインタが見つかるまでリストを検索し適切な関数が呼び出される。

結果は同じ。
2023/03/31(金) 12:51:42.96ID:RaXhcLNj
>>882
詳細の説明がいろいろおかしいと思うけどどこソースなの？
884デフォルトの名無しさん
垢版 |
2023/03/31(金) 18:30:12.19ID:fT81IvHH
>>883
『複オジ妄想虚言録』
885デフォルトの名無しさん
垢版 |
2023/03/31(金) 18:44:18.60ID:KJ4yMLmS
>>882
クラスとインスタンスの関係を理解してないな
C++の説明もRustの説明も同じように間違ってる
おまえオブジェクト指向を理解してなさそうと言われてたやつだろ
2023/03/31(金) 18:50:12.77ID:Q5ExbgOu
>>882
うーむひどいな
とりあえずRustについて、この部分の間違いはあまりにひどい

＞ traitオブジェクトが実装する各メソッドに対応するポインタのリストが含まれていて
＞ 適切なポインタが見つかるまでリストを検索し適切な関数が呼び出される。

Rustは常にメソッドが静的に一意に確定するため、動的ディスパッチでも適切なポインタが見つかるまでリストを検索する必要がない

Rustはメソッド名が衝突する場合、まず自分の定義優先で確定、なくてトレイト間に衝突がなければ確定、衝突があればエラーだが、トレイト名を指定することでどのトレイトのメソッドでも常に利用可能
つまりRustではメソッド呼び出しが自分のメソッドかどのトレイトのメソッドかが静的に一意に確定する

静的ポリモーフィズムとして使われるときは、必要とする最小限のトレイトを列挙(＝トレイト境界)するため、メソッドの衝突の可能性は通常時よりも減ったり無くなったりする
いずれにせよ上述したようにメソッドは静的に一意に定まるため、静的ディスパッチでは単相化(モノモーフィゼーション)されてコンパイルされる

動的ポリモーフィズムとして使われるときは、現在の仕様では指定できるトレイトは(auto traitを除き)一つのみに限定されている
ただし必要とするトレイトを列挙(＝トレイト境界)したダミーなトレイトを任意に作ることも可能なため、事実上は複数のトレイトを指定できるのと同じ
指定トレイトが一つに限定されているということは、(そのトレイト境界を含めた)トレイト群すべてのメソッドを静的に一斉に把握できることを意味する
つまりRustのvtableはその指定トレイト一つのみに定まり、その親や祖先のvtableを辿る必要がなく、呼び出すメソッドは静的に確定してインデックス値となっているため、動的ディスパッチでも高速にメソッドを呼び出せる
2023/03/31(金) 18:59:29.64ID:Q5ExbgOu
間違ったことを書いてる人は完全に悪いけど、内容があれば議論のネタになるからまだマシ
それに対して間違ってる！とか、虚言！とかだけ言う連中は全く役に立たないから無視してよい
なぜなら、正しいことが書かれている場合でも、間違ってる！とか適当なこと言ったりするだけの連中も多いため
2023/03/31(金) 19:02:37.99ID:RaXhcLNj
>>886
> つまりRustのvtableはその指定トレイト一つのみに定まり、その親や祖先のvtableを辿る必要がなく
C++も同じです
> 動的ディスパッチでも高速にメソッドを呼び出せる
何と比較して？静的に比べりゃどうやったって遅いしそこにC++との差はないはずだし

不合格

>>887
テキトーかどうかの検証のために、出典を貼っていただけるとみんなが助かります
やるつもりが無いなら頃合いを見てマサカリを投げさせていただきます
2023/03/31(金) 19:13:25.65ID:Q5ExbgOu
>>888
そういう意味のない言いがかりはやめとけ
元の>>882が正しくないこと「適切なポインタが見つかるまでリストを検索」と書いているので、
それに対して正しいこと「親や祖先のvtableを辿る必要がなく、動的ディスパッチでも高速にメソッドを呼び出せる」と書いた
そこで「静的に比べりゃどうやったって遅い」と頓珍漢なことを言い出すのは理解力のない証拠
これ以上は相手にしない
2023/03/31(金) 19:25:39.32ID:Wg79uBjg
OpenCV-rs ってもうメンテされてないんか？
gdgd なんだが
2023/03/31(金) 19:29:08.86ID:RaXhcLNj
https://mevius.5ch.net/test/read.cgi/tech/1677286186/751
https://mevius.5ch.net/test/read.cgi/tech/1677286186/756
https://mevius.5ch.net/test/read.cgi/tech/1677286186/786

つまんね〜の、もっとC++の話しようぜ複おじ
また名言バンバン出してくれよ
2023/03/31(金) 19:30:39.96ID:RaXhcLNj
756じゃなくてこっちだった
https://mevius.5ch.net/test/read.cgi/tech/1677286186/765
2023/03/31(金) 19:38:42.25ID:Wg79uBjg
>動的ディスパッチ

もしかして
遅延バインディング
2023/03/31(金) 19:40:08.33ID:7j0Yg6pd
おじオジ言ってる人は頭がおかしいと他のスレで習ったけどここでもそうなの？
2023/03/31(金) 19:59:22.01ID:RaXhcLNj
てかよく読んでみれば>>882自体は「適切なポインタが見つかるまでリストを検索」としか書いてなくて
具体的にどういうリストなのかの説明は一切無し
なのになぜか>>886は「親や祖先のvtableを辿る」と、親子関係でリストができる？のを何故か仮定している

そういうことだよねｗ
2023/03/31(金) 20:11:31.44ID:EgdFd66u
>>887
「最初から間違ってると思ってた」と事後に言うと、本当に最初からだったのかが真偽不明になるから
内容がなくても時刻を記録するだけで意味があるんだよ
2023/03/31(金) 20:19:56.47ID:f9v7p1HY
祖先のテーブルをたどっていく実装や言語あるよ
特にJavaScriptはメソッドを後から生やせるから大変だった
898デフォルトの名無しさん
垢版 |
2023/03/31(金) 20:24:26.37ID:JGH7phMu
>>896
とりあえず、プライドは高いということは分かった
899デフォルトの名無しさん
垢版 |
2023/03/31(金) 21:01:50.63ID:J9Ac7zVb
>>887
どう見ても君が間違ってる本人じゃん
なぜバレないと思ったの？
900デフォルトの名無しさん
垢版 |
2023/03/31(金) 21:50:12.55ID:RJ6Se/g4
1. 知ったかぶりして嘘をさも本当かのように書き連ねる
2. 間違いを指摘されるとググって必死に正解を探す
3. そしてそんなことは最初から知ってましたというトーンで長文まとめスレを他人のフリして書く

これが複オジメソッド
2023/03/31(金) 22:09:18.69ID:RaXhcLNj
>>900
そして話の内容がC++になると複おじにはちんぷんかんぷんなので
調べても間に合わないし、無限に別の間違いを生み出し続けてしまうというw
2023/03/31(金) 22:18:57.16ID:Q5ExbgOu
>>899
俺が間違ってるって？？
>>886に間違ってるところがあるなら指摘してくれ
903デフォルトの名無しさん
垢版 |
2023/03/31(金) 22:43:55.74ID:e2Ah0StU
>>900
4. 他人のふりして書いた長文まとめも間違っている
というオチ付き
2023/03/31(金) 22:50:43.27ID:RaXhcLNj
>>902
その「間違ってる本人」は>>882のことを指していて、間違いがあるのは>>886のことではないと思うが
それはそれとして>>886の間違いを指摘しておくと

あなたC++で「どのvtableを見るべきか」を実行時にしか判断できないケースがあると思ってない？ 嘘だよそれ
じゃないと「メソッドの衝突の可能性」なんて話が出てくる理由が無いと思うんだよね
そんなもんは静的に解決されて当然なのだから

ていうかね、参考にしたリンク貼ってくださいよって何回も言ってるでしょう
そのほうがあなたが（もしかすると私が）何を勘違いしているのかという答えにたどり着きやすいですって
いちいちあなたも長文で解説しなくて済むんですよ
2023/03/31(金) 23:03:06.56ID:Q5ExbgOu
>>904
間違いがないのに間違いだと言い張る悪い癖はやめたほうがいいよ
冒頭に「Rustについて」と明記していてC++について一切記述していない
もしRustについて記述した>>886に間違いがあると主張するなら指摘してください

> 参考にしたリンク貼ってくださいよ

参考はRust公式ドキュメントとコードのみ
他の解説サイトがあるかどうか調べたこともないので知らない
906デフォルトの名無しさん
垢版 |
2023/03/31(金) 23:13:20.94ID:oRUGNWak
>>887
間違いがあるとタダで教えてくれるだけでも相当にありがたいことだと認識すべきだぞ
どこがどう間違えてるかをタダで懇切丁寧に教えてもらえると考えるのは甘えでしかない
2023/03/31(金) 23:15:00.18ID:RaXhcLNj
>>905
なるほどね？
例えば「検索する必要がない」「メソッドの衝突の可能性は通常時よりも減ったり無くなったりする」は対比的にそれらが「ある」存在に暗に言及しているのだと思ったよ
行間を読んで根本的に何を勘違いしているのか探ろうと思ったが、これはあくまでRustに関する言及でしかないと
「高速」も何と比較してなのか不明で虚しい響きがあるが、高速だというならそうなんだろう

じゃあ私から言えるのはこれだけです

> Rustは常にメソッドが静的に一意に確定する
じゃあRustに動的ディスパッチなんて実装する必要無いじゃん
dyn存在意義無いじゃん
「『トレイトとメソッド名のペア』が一意に確定する」ならそう書かないと、この文脈でこの表現は語弊しか無いよ
2023/03/31(金) 23:19:08.47ID:EgdFd66u
自分が長文を書きたいのではなく、相手に自分の真似をさせたいんじゃないか
知らんけど
真似してくれれば人間皆どっちもどっちだと実証されるかも知れないから
2023/03/31(金) 23:22:31.74ID:tr7cKY8h
ぽまいら一人一人が要点を絞ってくれ
発散させあってたらきりがないんよ

余計なことは省くこと
余計じゃないものが複数あってもより大事なほうを一つ選んで議論を続行すること
2023/03/31(金) 23:22:49.85ID:hy3TCCAc
>>904
メソッド名が衝突した時にどうなるか？どう対応できるか？は
各言語によって異なるから
その説明があるのは普通じゃないか
alias付ける必要があったりなど十人十色
911デフォルトの名無しさん
垢版 |
2023/03/31(金) 23:28:00.63ID:JG8RdAc0
動的ディスパッチするために必要な間接参照の数はRustもC++も同じで高速とか低速とかないから

Rustは動的ディスパッチを使う場合は必ずポインタ経由になるので構造体のデータを読むのに間接参照が1回必ず入る
これが持ち方の違いによって出る差の一つ
912デフォルトの名無しさん
垢版 |
2023/03/31(金) 23:50:08.60ID:FlP4pMOX
あ、多重継承のケースがあったか
でもまあ気にするようなオーバーヘッドじゃないよね
2023/03/31(金) 23:51:44.88ID:Q5ExbgOu
>>907
後半の指摘については、短い中で詳細まで説明できていないから誤解を与えてしまったもしれないので、そこはすまん
しかしその指摘だとまだ別の誤解されてそうだからその部分についてだけ一応書いておくと
ある型Fooのメソッドmethodの各呼び出しがそれぞれ異なっていてもよくて
Foo::method()　なのか
<Foo as Trait1>::method()　なのか
<Foo as Trait2>::method()　なのかが決まり
Foo::method()がなくてそれ以外が複数で曖昧な時はエラーになるというだけの話
いろんな言語があるからね
2023/03/31(金) 23:57:35.53ID:RaXhcLNj
>>913
具体型Fooが確定している状態で動的ディスパッチは絶対に発生しません
dynと目印のついたトレイトオブジェクト経由でしか動的ディスパッチは発生しません
そしてこのときトレイトは確定しているのでメソッド名は衝突しません
だからメソッド名の衝突の話が出てくる意味が分からないと言っているんです
2023/03/31(金) 23:57:58.72ID:cX1DOwsp
>>912
多重継承の場合はどうなるの？
そこが焦点な気がしてきた
2023/03/31(金) 23:59:30.92ID:Q5ExbgOu
>>914
ちゃんと>>886を読みなよ
動的ディスパッチの話は最後の段落にしか書いていない
2023/04/01(土) 00:04:38.33ID:AdU+jSWJ
>>914
それはRustの基本が理解できていない
トレイトオブジェクトでも当然メソッド名は衝突しうる
なぜ衝突するのかも>>886に書いてあるな
918デフォルトの名無しさん
垢版 |
2023/04/01(土) 00:04:51.67ID:XaCtro1R
>>900
そのメソッドは迷惑行為なので
間違いを信じそうな人がいる時だけ
レス内容が間違ってることのみを指摘するのが吉
2023/04/01(土) 00:09:36.60ID:+ti2a57c
そのムーブはわかってないけどとりあえずケチつけてんだなとしか思わないよ
指摘できないけど誰か論破してくれねーかなっていう情けない感じ
2023/04/01(土) 00:09:53.12ID:YJwv5+OD
>>914
ボロボロですよ
トレイト境界を勉強しましょうね
2023/04/01(土) 00:12:20.97ID:ktHgE8AY
>>916
>>882が「Rustでは動的ディスパッチを実現するために〜〜」という文脈だったから最初からその範囲の訂正しか書いてないんだと思ったよ
脈絡もなく余計な文章を足すとそれがどういう意図でそこにあるのか理解してもらえないから気をつけようね

>>917
ああ厳密にはそうだね、私が間違っておりました
動的ディスパッチには関係ない文脈で書いた文章だって聞いたんでそこはもうどうでもいいです
922デフォルトの名無しさん
垢版 |
2023/04/01(土) 00:13:02.49ID:+UQ+9Bf4
>>915
全然焦点じゃないから気にすんな
923デフォルトの名無しさん
垢版 |
2023/04/01(土) 00:19:53.47ID:78d0gX0o
>>921
だよねー
>>886は>>882の間違いを指摘できてるわけでもなく何の意味もない
2023/04/01(土) 00:21:52.63ID:AdU+jSWJ
>>921
まだ理解できていないのか？
動的ディスパッチの時こそメソッド名の衝突に対しての処置が重要
そのためどのトレイトのメソッドを呼び出すかを静的に確定するとともに
各トレイトの同名メソッドを区別してvtableのインデックス化をしている
925デフォルトの名無しさん
垢版 |
2023/04/01(土) 00:32:15.20ID:DyolynIp
>>924
>各トレイトの同名メソッドを区別してvtableのインデックス化をしている
うそーん
ソースを提示してね
2023/04/01(土) 00:34:01.19ID:ktHgE8AY
>>924
「各トレイトの同名メソッドを区別してvtableのインデックス化をしている」
ここを詳しく説明してくれますか？
必要なら次の例を使ってください（こういう状況のことでいいんですよね？）

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a72f5f361d0e82594bace55483e66c7c
2023/04/01(土) 00:35:46.81ID:YJwv5+OD
>>925
インデックス区別しないと動的ディスパッチできないですよ
2023/04/01(土) 00:50:45.22ID:ktHgE8AY
SubとSuper逆だわ
気になるなら直してていいよ
2023/04/01(土) 00:56:33.36ID:tiKbQym2
>>914
バカだな
動的ディスパッチが行われるときは具体型Fooが確定しているぞ
具体型が確定しているからこそ動的ディスパッチを実行することができる
おまえC++もRustも両方を理解できてねーな
2023/04/01(土) 01:55:13.58ID:AdU+jSWJ
>>926
トレイトオブジェクトを扱うために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の説明で合っている
931デフォルトの名無しさん
垢版 |
2023/04/01(土) 03:08:57.82ID:TpFQVX+V
>>930
単にvtableが作られることを「vtableをインデックス化してる」と言ってたのね
もう嫌だ
2023/04/01(土) 03:10:50.58ID:AdU+jSWJ
>>931
助詞を間違えてるぞ
「各トレイトの同名メソッドを区別してvtableのインデックス化」な
933デフォルトの名無しさん
垢版 |
2023/04/01(土) 03:16:00.87ID:TpFQVX+V
>>932
どっちでも間違ってる
インデックス化されるのはメソッド
vtableはメソッドがインデックス化されたデータ構造
2023/04/01(土) 03:30:04.06ID:AdU+jSWJ
>>933
だからそう書いてるだろ
文章も>>930のコードも読めないのか？
935デフォルトの名無しさん
垢版 |
2023/04/01(土) 05:02:11.23ID:J25MoQ6T
C++からメタ言語機能のような黒魔術を無くして使いやすくしたのがRustという認識でよろしいか？
936デフォルトの名無しさん
垢版 |
2023/04/01(土) 05:11:37.13ID:J25MoQ6T
今月のInterfaceはRust特集だぞ
937デフォルトの名無しさん
垢版 |
2023/04/01(土) 05:12:17.82ID:J25MoQ6T
C++に挫折した者ども、いまこそRustに集え
2023/04/01(土) 06:30:37.76ID:ol7Kdurc
マ板でやれ無能
>>3を理解しろ
2023/04/01(土) 06:56:17.26ID:073QzAPe
ディスパッチがどうとか言ってるあいだに1000きそうだぞこれ

なんだかんだで実際は両方使うけど、やっぱ俺はこっち推すぜ! みたいなスレになりつつ
テンプレ用意すんの?
940デフォルトの名無しさん
垢版 |
2023/04/01(土) 10:28:30.10ID:h8xyCGJ+
>>934
書いてないじゃん
見苦しい嘘つくなよ
2023/04/01(土) 10:56:30.89ID:3pQ6SLTI
要するに「へぇ、継承ってのがあるのか、どうやって実現するんやろ？あ、オレならこうするな、でもそれだとこうなってコストメチャメチャかかるじゃん、使えねぇな」と思ってるくちじゃないの？
2023/04/01(土) 11:11:44.89ID:IIYgmYPv
その件は>>930が正しい
assert通るのを確認した
2023/04/01(土) 12:25:26.51ID:ktHgE8AY
>>930
言いたいことは理解した

でもね、そもそも「衝突」は定義だけで発生するものなんですよ
そのコードのmainの中でdyn_foo.method()と書くと発生するエラーは、「名前解決の失敗」と呼ばれます

そしてこの「衝突」の有り無しは、「vtableのインデックス化」に特に影響を与えません
現に片方だけメソッド名を変更しても、同じレイアウトになりますよね
内部的には別トレイトのメソッドなのだから、"method"部分が「衝突」するしないに関係なく区別されます
「衝突」に、vtableに関して特筆すべき重要性は無いと思います
944デフォルトの名無しさん
垢版 |
2023/04/01(土) 12:47:01.18ID:km+jzk5n
静的型付けをしてればどのメソッド実装を呼び出すか静的に決まるのは当たり前のこと
それを何か特別なことのように変な長文書くからバカにされる
2023/04/01(土) 13:18:48.32ID:hxeslJ4Q
C++er あるあるシリーズ
#![allow(unused)]
... = hoge().unwrap;
... = hoge()?;
let p: *const [u8] = &fuga;
unsafe {}
946デフォルトの名無しさん
垢版 |
2023/04/01(土) 13:25:38.29ID:hxeslJ4Q
>>900
chatGPT そのもののことだな
2023/04/01(土) 13:33:41.52ID:hxeslJ4Q
>>936
みたけどイマイチ
948デフォルトの名無しさん
垢版 |
2023/04/01(土) 13:35:01.01ID:hxeslJ4Q
>>937
ほんそれ

C++出来る人はC++使えば良い
C++出来ない人やC++でやらかすうっかりさんだけRust使えば良い
2023/04/01(土) 13:38:19.66ID:goAbMbb3
面白いのはC++ちょっとかじったくらいのド素人ほど
なぜかRustに引き寄せられてる気がする
ニワカ人間を引きつける同じニオイがするんだろうなRustには
2023/04/01(土) 13:46:59.44ID:WHqiXdwW
C++は底なし沼な感じが良い
未だにModern C++ Designを初めて読んだときの衝撃を上回る
本には出会ったことがない
2023/04/01(土) 14:05:07.99ID:goAbMbb3
職業マとアマチュアで感想違うよね
職業マ「C++？　糞の糞糞」
アマチュア「C++？　vtableのコスト（ｷｬｯｷｬ）
鼻から悪魔（ｳﾌﾌﾌ）膝を撃ち抜く（ｷｬｯｷｬ）CRTP（ｳﾌﾌ）
2023/04/01(土) 14:25:21.95ID:hxeslJ4Q
Javaは糞
C#はチョット良い感じ
Juliaは死んだ
Rustがんがれ
Nimもがんがれ
C++は使い続けるけどね
2023/04/01(土) 15:11:33.70ID:rIj/v2ga
>>937
C++に挫折した者ども、いまこそRustに集え
そしてRustに挫折した者ども、いま一度C++に立ち返れ

の方がバランスいいと思う
2023/04/01(土) 16:41:11.09ID:HWGbnwVz
>>944
同名メソッドが衝突した時にどうなるかは言語によってかなり異なるから一番重要じゃないかな
衝突が許されない言語と許される場合も条件がある場合もあるよ
衝突があってもエラー出ない言語もあれば特定な時だけエラーな言語もあるね
回避方法も別名定義方式から同名自己定義や直接指定と色々だ
2023/04/01(土) 17:25:01.59ID:/8VZFYJJ
Rustが「認め」られたことで、C++のスマポも、べき・べからずが確定したと考えておｋ?
2023/04/01(土) 17:29:58.10ID:WHqiXdwW
>>955
どういう意味?
2023/04/01(土) 17:52:08.96ID:/8VZFYJJ
大手が認めたんだから、Rustと同等に書ければ、それはsafeなんだよな?
これまで、C++のスマポは、CppCoreGuidelinesなんてものはあっても、強制されなかった
2023/04/01(土) 18:00:21.17ID:WHqiXdwW
Rustに関係なくC++ではスマートポインタを使用すれば安全に書けるし
スマートポインタの使用するしないにRustは全く関係ない?
ここ見てる人は俺も含めてRustに注目してはいるが
C++ユーザのほとんどはRustなど眼中にないだろう
2023/04/01(土) 18:01:23.45ID:WHqiXdwW
二行目最後?を消し忘れた
2023/04/01(土) 18:06:42.88ID:/8VZFYJJ
強制されるってのがミソだろ Rust派は、Rustなら、必ず・全部安全って言ってるんだからさ
961デフォルトの名無しさん
垢版 |
2023/04/01(土) 18:09:42.77ID:vBVsKFoD
>>933
某オジお得意の誤訳だったんじゃねーの？
2023/04/01(土) 19:15:27.20ID:ugeMTEEj
>>914
> 具体型Fooが確定している状態で動的ディスパッチは絶対に発生しません

逆
動的ディスパッチが実行される時点では必ず具体型Fooが確定している

> dynと目印のついたトレイトオブジェクト経由でしか動的ディスパッチは発生しません
> そしてこのときトレイトは確定しているのでメソッド名は衝突しません

衝突する
直接のトレイトは確定しても付随するトレイト境界があれば各トレイトでメソッド名は衝突しうる
2023/04/01(土) 19:16:31.21ID:ma7yA/CE
>>954
でも>>905によるとRust以外の話をしたつもりは無いらしいよ？
深読みしすぎじゃないかな？
2023/04/01(土) 19:31:10.27ID:9m4PZsrB
どの言語でも他の言語とは異なる特徴があるからその説明をしてくれないとわからん
それを説明されると困る人がいるのが不思議
2023/04/01(土) 21:31:47.02ID:WHqiXdwW
>>957,960
何を言っているのかサッパリ分からん
2023/04/01(土) 21:44:43.97ID:NRw2BG4n
そいつはRustのこともC++のことも何も知らないくせに
なにかコメントしたいだけの池沼なので放置するしかない
2023/04/01(土) 21:50:56.74ID:WHqiXdwW
ひょっとしてGC君かな?
2023/04/01(土) 21:55:20.36ID:3M3YuI+X
>>958
C++でスマポを使ってもヌル安全性もデータ競合安全性も得られない
さらに複雑化した時のスマポの使い方ミスで多くの問題が起きてきたことを考えると
本当に必要なのはスマポが正しく使われていない時にコンパイルエラーを出すこと
現状のC++は欠陥品であり今後も多くのセキュリティホールを生み出し続けるだろう
969デフォルトの名無しさん
垢版 |
2023/04/01(土) 21:57:58.76ID:WHqiXdwW
>>968
おおGCくんが来た

>C++でスマポを使ってもヌル安全性もデータ競合安全性も得られない
どんなミスか興味があるのでソースで示してね
2023/04/01(土) 22:10:09.20ID:rBOo7R6g
>>743
同感
Rustは衛生的マクロな点を始めとして各種マクロが優秀すぎる
C++がダメすぎるんだよな
テンプレートも問題ありすぎ
971デフォルトの名無しさん
垢版 |
2023/04/01(土) 22:21:05.85ID:nbXeTJU5
ディスパッチの定義を捻じ曲げたのと同じで
衝突の定義も捻じ曲げにきてるよな
2023/04/01(土) 23:32:16.53ID:AdU+jSWJ
>>940
コードがわかりくいのかなと思って
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)をしている
2023/04/01(土) 23:39:50.11ID:62NQQrT2
これ次スレたてるの? あるいはどっかの雑スレに合流?
974デフォルトの名無しさん
垢版 |
2023/04/01(土) 23:53:21.20ID:3egme1as
C/C++ vs Rustとしてあった方が良いと思うけどね
雑スレだとGCの勢力が強くなりそう
2023/04/02(日) 00:22:03.90ID:Xkdfgrgv
5chでC++↓Rust↑している人のC++理解度の低さは強調してしすぎることはない

https://mevius.5ch.net/test/read.cgi/tech/1652347700/385-392
976デフォルトの名無しさん
垢版 |
2023/04/02(日) 00:30:37.47ID:bY6+UifX
>>972
汚コードに磨きをかけるなよ
普通に関数で書けるものをネストさせたマクロにするセンスに脱帽
2023/04/02(日) 00:32:38.03ID:xbcpqSco
単純に開発効率の問題だよな
C++よりRustは実行デバッグの時間がかなり減って開発効率がいい
2023/04/02(日) 00:39:46.89ID:GYBlNyWI
汚コード唱えるやつがコードを示したことがなく信用できない
2023/04/02(日) 00:43:54.27ID:W9/nq+tL
建てた 叫んで埋めていいぞー

結局C++とRustってどっちが良いの？ 2traits
https://mevius.5ch.net/test/read.cgi/tech/1680363777/
2023/04/02(日) 00:48:46.53ID:Xkdfgrgv
>>978
君の日本語がおかしいって話なんで、ソースで示すべきことは何も無いよ
それともなにか示してほしいの？
2023/04/02(日) 01:41:46.92ID:DBhEEanc
スレを読んでいて技術的な論争は興味深いんだけど
他人への攻撃をしてる人たちは邪魔なんで消えてほしい
2023/04/02(日) 02:09:25.03ID:WdMf4Ye5
そもそも>>1がソースを書けないと思われる
特にC++は読めもしないのだろう
RustとC++を技術的に比較するなら両方のソースをある程度書けないと不可能
2023/04/02(日) 07:26:34.66ID:W9/nq+tL
>>3 にあるとおり、やれっていわれたらやる マとしてはこれでFA
慣れは必要だけど、要求される頃には、定石も今以上に揃うだろうし

ここ読んでて、食わず嫌いしてたRustを眺めなおしてから、
CppCoreGuidelines 読んだら、めっちゃわかりやすかった
これだけで俺には十分収穫あったね
2023/04/02(日) 07:39:56.12ID:W9/nq+tL
Linusに認められた、これだけで、Rustの「勝利」は外形的事実 争う必要はない
はずなのに、そのうえまだ、Rustの優位を主張するのに全力な香具師がいる
若いなって正直思う 昔俺もああだったぜ

C++を母語としている者が考えることは、次に何を取り込むか
やっぱ #pragma safe は欲しいね
そのうしろに値くらい付いてもいい safeの詳細も、進化していくだろうから
2023/04/02(日) 07:53:54.77ID:W9/nq+tL
あああと、パタンマッチを知らなかったのも俺だ (知らぬは)一生の恥になるとこだったｗ
静的にソースコードを解析してsafeを証明できる、ガイドライン違反を指摘できることだとばかり

rustcのサンプル出してくれた奴には悪かった
「たしかに面白い…けど、こういうの、Cなら、yylvalっぽく処理するよね…」っていう印象だったんだ
inspectってのが来たら来るらしいので、来たら喜んで遊んでみるとして
優位性の根拠になるか? それホントC++に必要? ってのは次スレに持ち越したい

っていう埋め
2023/04/02(日) 10:51:04.91ID:D26hzdDf
>>985
キミは周回遅れのド素人でかつ
人より知能が劣るからもう発言しなくていいです
これはいじわる発言じゃなくて、助言です
2023/04/02(日) 10:59:32.98ID:W9/nq+tL
よく言われるよ

Rustのエヴァンジェリストが暴れていいのに、初心者の俺に黙っとけはないなあ
せいぜい質問させてもらうよ
988デフォルトの名無しさん
垢版 |
2023/04/02(日) 11:04:00.93ID:xlKg15xW
>>981と>>986は同一人物です
皆さん次スレでも騙されないようご注意を
989デフォルトの名無しさん
垢版 |
2023/04/02(日) 11:10:11.81ID:6UFMeU2Z
>>976
複オジメソッドに釣られてるよ
気をつけて
2023/04/02(日) 11:12:51.90ID:Xkdfgrgv
自分の間違いを認められるだけマシ

>>981は露骨に複おじだけど
>>986=>>847=ID:BpzIAh0Kは違う気がするんよなあ

あんまり雑認定しすぎるとおじサイドの「自演に見えてるやつは頭がおかしい」の批判が有効になってしまうから、確証を持てないならほどほどにな
2023/04/02(日) 11:17:21.13ID:W9/nq+tL
ダックタイピングみたいなもんじゃないんｗ
2023/04/02(日) 11:34:39.31ID:E52hJVrB
俺は池沼と複オジをこのスレから排除したいだけよ
だって時間のムダだもん
2023/04/02(日) 11:42:03.77ID:Xkdfgrgv
やめろバカ！複おじを野に放つ気か！？
せっかく平和なRust本スレが実現できて、後はヤツが追い払った住民たちを呼び戻すだけだというのに！
2023/04/02(日) 11:44:18.44ID:W9/nq+tL
残念だが、初心者お断りとは書いてなかったんだなあ

そうくると思って、俺がとっととスレ建てちまったからねｗ
2023/04/02(日) 11:45:16.10ID:E52hJVrB
>>993
そうかそっちか
それは申し訳なかった
こっちを隔離にすべきやね
複オジも池沼（ID:W9/nq+tL）もこっちに張り付く気マンマンらしいし
996デフォルトの名無しさん
垢版 |
2023/04/02(日) 12:34:42.17ID:uooZ7ifu
まあまあ同じスレで出会った仲間なんだから仲良くしようや
997デフォルトの名無しさん
垢版 |
2023/04/02(日) 13:29:57.68ID:Ky8sq4kq
Rustが良いって言ってる人は
C/C++のポインタとメモリ管理理解出来なかったからだろ
998デフォルトの名無しさん
垢版 |
2023/04/02(日) 13:30:14.04ID:Ky8sq4kq
おにまい
999デフォルトの名無しさん
垢版 |
2023/04/02(日) 13:30:23.82ID:Ky8sq4kq
梅
1000デフォルトの名無しさん
垢版 |
2023/04/02(日) 13:30:34.24ID:Ky8sq4kq
櫻
10011001
垢版 |
Over 1000Thread
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 36日 3時間 40分 48秒
10021002
垢版 |
Over 1000Thread
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。


───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。

▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/

▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況