結局C++とRustってどっちが良いの? 9traits
!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」
っていう雑談スレ。
・C/C++ <=> Rust いまさら聞けない移行質問なども適当にどぞ
・レスバはじめんのは勝手だけど、面白いこと・へぇなこと書いたヤツが優勝
・マな話は、マのスレもご活用ください↓
前スレ: 結局C++とRustってどっちが良いの? 8traits
https://mevius.5ch.net/test/read.cgi/tech/1698468300/
関連スレ(マ板): Google&Microsoft「セキュリティバグの70%はC/C++のメモリ管理ミス。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured あるあるトピックス
・後発のRustは優れている(この点で特に争いはない
・といっても、C/C++から「推し変」するほどじゃない(使わないとは言ってない
・ていうか、Cとの比較と、C++との比較は違うくね?
・いくら安全っつっても、ヘタクソがunsafeだらけに書いちゃったらおんなし
・てかC++にも unsafe{ } はよ
・web方面、特に基盤部分での人気すごいね
・ChatGPTとかが賢くなる(のに賭けてる)からどうでもいい === 複製おじさん(通称複おじ)について ===
Rustスレを中心に活動し、2023年4月現在で1年以上ム板に住み着くRustacean。無自覚な荒らし。
Rustスレでは、基本的に他住民の意見を聞いて糧とすることなく、自らのコードが最善であると、ID変更自演を交えいつまでも主張し続ける。
同スレで「所有権が複製される」という違和感のある表現を、「違和感がある」とする他住民の意見をすべて否定してしつこく擁護し続けたことから、「複製おじさん」というあだ名が付けられた。
それ以外のム板スレでは、基本的に他住民の意見を聞いて糧とすることなく、Rustこそが最善であると、ID変更自演を交えいつまでも主張し続ける。
その基本戦術は、「GC言語は遅い」の一声でC/C++/Rust以外の言語を否定し、残ったC/C++は安全ではないので、Rustが最善であるとするもの。
しかしながら、Rust以外の言語に関しては、正当な批判を展開するのに十分な知識を持っているとは言いがたい。
本スレPart1では、C++の問題点を指摘しようとして多数の誤り・知識不足を露呈することとなった。特にしつこく食い下がったのが「動的ディスパッチ」に関する誤解である。
https://mevius.5ch.net/test/read.cgi/tech/1677286186/786-799(ID:Evbafc70とID:RiLc+pIfが複製おじさんであると考えられている)
要約すると、通常「条件分岐」と呼ばれるものを「動的ディスパッチ」と呼ぶのが正しいと主張し続けたのである。
常識的にはあり得ない誤解だが、提示されたC++のコードが自らの主張(C++にはパターンマッチが無い)に不都合であると感じたためか、C++のコードを正しく読み解くことができないにもかかわらず脊髄反射的に否定してしまい、その根拠として誤った論理をこじつけてしまったものと思われる。
ちなみにこの後、同種の誤解を持って書き込むID:wHEiYRW7(これはID使用歴的に複製おじさんとは考えにくい)に対して、正しい理解に基づく指摘を行う単発IDが複数出現するが、この中にも複製おじさんが多数含まれていると考えられている。
このように自分の誤りを認識した場合、それを認める書き込みは決して行わず、別人の振りをして最初から正しく理解していた体を装うのも複製おじさんの特徴である。 複おじは全レスおじさんの事かと思ってたから解説助かる 複数垢を使って自演連投してるから複おじだと思ってた
考えを改めないといかんな >>3
複おじと言えば一文一文すべてがデタラメなこの名レスを忘れたら駄目だぞ
>ムーブでビットパターンのコピーは発生しない
>ビットパターンのコピーが発生するのは引数の値渡し等であってムーブとは関係ない
>さらに引数の値渡しでのでビットパターンのコピーとCopyのコピーも全く異なる
>Copyのコピーはディープであって高コスト
https://mevius.5ch.net/test/read.cgi/tech/1652347700/52 >>7
日本語として成立してない
怖い
なんかやってんじゃないか >>7
過去レス見ると嘘つき呼ばわりされてる理由がよくわかった >>2
>・てかC++にも unsafe{ } はよ
まだこんなこと言ってる奴がいることに草 改めて複おじの足跡を辿るか?
>>3のまとめも半年以上更新してないし ChatGPTにCopy Traitを実装するべき場合について聞いたら、「所有権の複製」って項目が現れてワロタ 「Copyのコピーはディープであって高コスト」以外は初心者によくある勘違いだし
勘違いから間違った内容を書いてしまうことは誰にでもあることだからまだいいのだが
繰り返し間違いを指摘されても謎の上から目線で無理筋の強弁を重ねることから荒らし認定されている Copyはクローンされるけどクローンの実装次第ではディープコピーにならんの? 自己愛性パーソナリティ障害持ちに多い特徴だよ
自分のミスは絶対に認めずに詭弁を言う Copyのクローンは単純なmemcpyだと思っていいよ
構造体の中に別の構造体(Copy可)が埋め込まれたような型だとディープコピーに見えるけど
再帰的なコピーは必要なくて単にバイト列全体を丸写ししてる
(逆に言えばそれができない型はCopyをつけられない) 前スレ
>0994デフォルトの名無しさん
>2023/12/08(金) 10:27:55.85ID:gyEpWkla
>Cで書かれたプログラムがある
>Rustに移植せよ
>https://uguisu.skr.jp/othello/7gyou.html
>https://ideone.com/0xz2SJ
Rustでできた? >>16
それだとヒープのデータはコピーしてないことになるけど
メモリをアロケートしてデータをコピーはしてないってこと?
シャローコピーなの? 参照を含まない型のコピーにdeepもshallowもないでしょうが ヒープ使う型は基本的にCopyにできない(Cloneは実装可能)
構造体に1つでもCopyにできない型が含まれてたらその構造体もCopyにできない
Copyはmemcpyしても問題ない型のマーカーだと思ってもらえばいいかな
メモリをアロケートしてデータをコピーする処理はCloneの方で実装する そういえばmutがない方の参照はCopy可能だから
「ヒープ使う型は基本的にCopyにできない」はちょっと誤解を招くかな
ヒープを所有する型の方がいいかも あー参照とかBoxは含められないのねCopyは
勉強になりますた >>14
ディープコピーにはならん
>>18
Copyはシャローコピー
>>22
参照は含められる
#[derive(Clone, Copy)]
struct Foo<'a>{
x: &'a Bar,
y: i32,
} C++は、全部 unsafe と言っても、
デバッグの済んだライブラリを正しく用いて
いれば、その部分は安全。なので、関数引数の
部分だけをよくチェックすると良い。
C++の関数呼び出しは、ポインタに
関しては、型チェックが強いので
間違った呼び出し型をしていれば
コンパイルエラーになることが多い。 >>24
間違えないように書けば正しい動作するという
意味にしか取れない >>26
Rustも同じだろ
「間違えないように書けば正しい動作する」も間違い
「間違えないように書けばコンパイルが通る」に過ぎない
正しい動作をするかどうかは間違えないように書くかどうかとは別の問題 >>27
その程度の理解力だと普段の仕事も間違いだらけぽいな 普段の業務も間違えだらけな奴がC++使うとか地獄か? ロジックエラーはrustも共通だけど
rustはコンパイラのチェックが厳しいので
そこで防げるエラーはあるな
俺はそんなとこで間違えないから不要だけども 複おじってrustを普及させようとステマ要員なんだろうな むしろRust支持者と見せかけてRustを貶めたい工作員だろう C++もさることながら、C++とセットで付いてくるCMakeが嫌すぎる
Cargoは良いよマジで autotoolsはcmakeよりさらに嫌かな…… >>33
makeに戻ったな
細かいことやろうとすると全部書き下せるmakeが1番自由度がある
典型的なことだけしたいならcmakeで良いけど >>37
ruby必要だけど、rakeコマンドいいんじゃないかなと最近気になってる。 結局新しくて便利なものに徐々に流れる運命かなと思う >>37,38
automake良いよ
makeの自由度があって依存関係の追跡もautoでやってくれる どれもこれもCargoのはるか下でどんぐりの背比べみたいな利便性の主張合戦をしてるイメージ meson割といい
cmakeが覇権とってるのは残念すぎる
あの文法の出来損ない感はひどい >>42
議論をしたいのであればどう優れているのか具体的に書かないと 嘲笑してるだけで議論をしたいわけではないだろ
どう優れてるか具体的に教えてほしいのであれば教えてくださいと書かないと >>45
ティッピングポイントに達することはないと踏んでいるので
どうでも良いというのが正直なところ そもそもCargoとmakeを比べること自体ナンセンスなんだが 完全に機能が一致するとは思わんけどautotools相当じゃねーの? パッケージを再利用可能な方法で定義するという面では共通しているかもしれんが
それも重要なのはautotools自体より
configureなりMakefileなりがGNUの規約に従っているってことのほうなんじゃねえかな…… Windowsネイティブビルド考えたらautotoolsはありえんでしょ
そのあたり機能がそろってるからcmakeがメタビルドシステムとして使われる
ほんとクソだけど >>51
標準はmsbuild、nmakeはレガシー 一般的なことしかしない素人にわかりやすく教えてくれ教えてくれないか
CMakeどういうところがクソ? >>53
あれXMLでしょ?
自動生成されるようなプロジェクトならいいだろうけど
手書きの場合nmakeがベスト >>54
まずは使ってみたら?
偉そうにする前にさ >>50
俺はWindowsバイナリはクロスコンパイルでしか作成しないけども
autotoolsはMSYS2で動くんじゃねーの? cmakeだったらbazel使った方がまだマシだろ あんなの使うメリットがない
モノレポのGoogleだから使ってるだけ >>54
単体のプロジェクトならあまり困らない
しかし他のcmakeプロジェクトの取り込みとかやりだすとなかなか思い通りにいかない
言語コアが貧弱で変数すら関数が提供するというとんでもない設計
滅んで欲しい Ruby関連のプロジェクトなら使って良いと思うけど
全く関係ないプロジェクトで別言語の環境を用意しなきゃいけない時点で厳しいかな >>45
教えてくださいと書いたところで議論したいわけではないなら答えは来ないだろw それJavaScriptの人に対しても同じこと言えんの? JavaScriptはそもそも使っている人も含めて番人が認めるクソなので いやC/C++のビルドも大概終わってるぞ
RustやGoみたいなやり方ができれば1番なのだが >>65
CMakeのインタプリタの作りが貧弱でなんでもCmake独自関数を通さないと書けないような仕様?
多種のプロジェクトを一括管理しようとすると、Cmakeでの書き方の定石みたいなのがとても面倒臭い
てな感じに理解した、どう? >>70
何でインタプリタが出てくるのか
本質は各プラットフォームのビルド環境を作って呼び出すだけのツール
LinuxだとMakefileを生成してmakeを実行するだけ
全然分かってないやん >>71
いやいや、もういいです。私の質問の流れからあなたのその回答だと的外してるし。
いわゆる揚げ足取りの人でしょ?
私はすでに転んでるから、揚げ足は取れませんよ。
ではあとは自分で調べますので。悪しからず。 >>73
的外れではないだろう
的外れなことを言い出したから正解を教えてあげただけ
揚げ足取りと取られるのは心外だし
他の連中も同じこと思ってるよ >私はすでに転んでるから、揚げ足は取れませんよ。
ナイスな言い回しだね
センスを感じる 開き直るのはやめてくれないか
正解か間違いかの2択しかない世界なんだよ
多少厳しいこと言うのは当然なんだ
そんな甘い世界ではない じゃあなおのことつねに正しいことを言ってくれよ
さっきから君は間違いしか言っていないじゃないか
それとも自分は例外なのか? 間違いを指摘してくれないか?
君はいつもそうだ
間違ってると言いつつ何も指摘しない
もうバレてるんだよ
この偽善者が この流れから行ってどちらが頭がおかしいか?は一目瞭然だと思うのだが
cmakeを一切触ったことがないにも関わらず
大体理解したとか嘘を自演しそれを指摘したらもういいと逃げ
さらに追い討ちをしたら揚げ足取りと言われる
異常行動してるのは俺かお前か 「一般的なことしかしない」とは書いたけど
一切触ったことないなんて書いてないし。
「なんとなく理解ができた」とは書いたけど
大体理解したなんて書いてない。
自己目線だけで考える癖を直したほうがいいのでは?
思わぬ間違いのもとだぞ。 いいから違いを指摘しろよ
お前が言ったんだぞ
あくしろよ
ほら ややこしい奴やな、まず頭冷やしてワッチョイを理解してこいや 結局答えられずか
何もできないなら何も発言するな
ほんとお前はしょーもないな >>84
もしかしてワッチョイが違うから違う人って思ってる?
いや思わそうとしてる?
クソワロタ Ruby でRubyで使う、C 拡張ライブラリを作る場合、
gemspec ファイルで、extconf.rb を指定して、rake install する
mkmfがMakefile を作成する
# extconf.rb
require 'mkmf'
create_makefile(〜) あーでもRuby拡張をビルドするとき限定ならいいか >>62
いうて、今時はmakeコマンドも別途入れないといけないOSばかりだけどな