結局C++とRustってどっちが良いの？ 3traits
■ このスレッドは過去ログ倉庫に格納されています
「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」
っていう雑談スレ。
前スレ: 結局C++とRustってどっちが良いの？ 2traits
https://mevius.5ch.net/test/read.cgi/tech/1680363777/
関連スレ(マ板): Google&MS「バグの70%はC/C++。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/ >>480
クロージャが関数ポインタに自動的にcoerceされてるだけでは？ pythonさんが無名関数を雑に実装したおかげで
雑な名前をつけるより無名のほうがいいという価値観がもうない map とかで
let e = hogemap.entry(hogeid).or_insert_with(|| Hoge::new());
は確かに便利なのですが
id が重複しないことはどうやって保証するの？
同じ id なら既存のに上書きは判らなくはないけど
それも禁止して上書き前に阻止したいときどう書く？ entryの時点でハッシュ計算と衝突時含めたエントリ探索済
つまりエントリが空か既存かの状態を持つのがentry
あとはその状態により既存のを返すか空ならinsertしてそれを返すのがor_insert_withなどのメソッド 紛らわしくてごめん
上書きというか
重複してたらシレっと既存のデータ魅せるんじゃなくて
let e = hogemap.entry(hogeid).or_insert_with(|| Hoge::new());
新規の場合しか登録出来ない？みたいな動きを期待しています それ新規の場合しか登録してないんだよ・・・
すでに同じキーがあった場合にどうしたいのか
もう少し望んでる仕様を日本語で明確にしてくれ Entryの結果で分岐させたいってことなら
そうすればいいと思うんだが こんな感じでいいのかな
Entryはmapの型に合わせて別途useする必要があるけど
use std::collections::hash_map::Entry; // HashMapの場合
match hogemap.entry(hogeid) {
Entry::Occupied(_) => {
// エラー返す？
}
Entry::Vacant(e) => {
e.insert(Hoge::new());
}
} >>476
この表ではCとC++を分けて書いてあるので、10位と7位になっているが、
「合算」して、C/C++ と捉えると、遥かに順位が上がって、
tiobeや日経では一位になっていた。但し、日経は「プロのプログラマ」限定
のランキング。 >>497
海外の掲示板でC++とJavaの投稿数はほぼ互角。
C#はそれらの2/3ほどだった。 >>497
>「合算」して、C/C++ と捉えると
この考え方が既にプロからかけ離れてるだろw
日経wなら納得だけど 混ぜたものh単にC++だし純粋なCを使ってる人はC++と区別してるだろ。 この板ですらC/C++とかいう表記好むやつおって頭痛いわ
CのこともC++のこともおそらく両方とも聞きかじり程度なんだろう C/C++ってのはCやC++という意味なので
グループ化して扱いたい文脈ならともかく
言語のランキングで異なる言語をまぜちゃダメでしょ 世界ランク1位のAIや世界ランク1位の法人は何人分なのかしら C++ってCを内包してるので異なる言語なのかっていうと
それはちょっと違う K&R CとC++98使えるから両方名乗ってもいいよね CとC++は人気シェア被ってるだろうから、単純に加算じゃいかんだろうなｗ
ちな、最強は…ってのの意味は、C++かRustかとかって言ってる間に、
世界最強はJavaScriptじゃねーか、まあ確かにｗｗ ってつもりだったよ
Rust流のメモリ管理がJavaScriptに流れ込んだら、どうなるかね >>502,503
二つは一緒でしょう？
私はね C++ コンパイラを通らない C は書く気がしなくなりました、いまや C コードを C++ コンパイラでコンパイルが通るか試すのが日課ですね
そりゃCでかくときはCの書き方で、C++ で書くときはC++の書き方で書きますが、C++ はCの上位互換であるように気をつけていますね >>505
＞C++ってCを内包している
べきで、C++ コンパイラを通せないCコードは書かないようにしてますね C/C++にダングリングは存在しない
C/C++は実体の無いものを参照出来る
もちろんポインタに代入して良い
アクセスさえしなければ問題は発生しない
問題を起こすのは馬鹿プログラマの責任
頭の良いプログラマは承知の上で使ってる C/C++って書くとき、どっちも生ポ世代の、息の長い人気言語、って意味かなあ
そこを踏まえてRustが生まれた
なによりCにunsafe{ } 追加待ったなしだと思う Cに来れば、C++に来るのも早いだろう
そんな流れを想像するに、またC/C++って書いたりする >>512
この一行一行に頭の悪さ出てるのスゲーな
釣りとして考えたら上出来だけど >>512
Google＆Microsoft「セキュリティバグの70%はC/C++のメモリ管理不備が原因。問題の起きないRustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/ 想像以上に、ダメ人間がC/C++系に動員されてたって証左だね 俺を含むｗ 片方の小手先の文法にばかり文句つけて反対側の長所は言えない
サンプルコードレベルしか理解できず書けないからそんなことしかできない
だからクソスレになるんだよここ >>517
小手先の文法のいちゃもんは、
「まあそんなこと言っても始まらないから着手してるけど、やっぱ慣れんなあ」みたいな愚痴だぞｗ 手続き型言語は基本的にはどれも大差はなく文法や言語仕様は慣れの問題しかないもんな
スクリプト的な使い方をするだけならどの言語でも良いと思う
ただし本格的にプログラミングするなら速さや省メモリが効いてくる
とはいえC++の仕様では静的解析に実行時解析デバッグでも>>515が残りうる 小手先の文法っていうと、「hoge/fuga/b.rs」モジュールを「hoge/a.rs」から触りたい時に
なんでいちいち「hoge/fuga.rs」作って、人間が「pub mod b」みたいなこと書かなきゃならないんだろ
b.rsの先頭にでもpubって書いとけば、単にa.rsで「mod fuga::b」とか書くだけで認識できるようにするんじゃあかんのか >>520
どの言語でもモジュールの目的は隠蔽にある
つまり必要となる最低限のものだけを外部に公開して他は内部構造として隠蔽するのがプログラミングの基礎
言語によって基本状態が何でも公開と何でも隠蔽があって後者は公開必要のあるものだけにpub等を付ける
そのモジュールfugaのサブモジュールbも同様で無指定ならばfugaの内部構造として隠蔽してくれる
公開したいならばRustではpubあるいは公開範囲を指示してpub (xxx)を付ける
例えばそのクレート内部だけに公開したいならばpub (crate)を付ける まともなプログラミングをしたことない人は隠蔽の重要性をなかなか理解しづらいかも
Rustのようにデフォルトがあらゆる隠蔽の言語の方が保守性の良いコードに導きやすいね デフォで不可視なのとか、パスとモジュール階層が対応してるのは文句なくて
パスと対応してるのに、いちいちpub modが並んでるだけのフォルダ名と同名ファイル「hoge/fuga.rs」作らないと
サブフォルダに切ったサブモジュールさわれないらしいのがウザいなあって思ったんだけど、今「hoge/a.rs」で
mod fuga {
pub mod b;
}
って書いたら普通にhoge/fuga/bを触れたんで、そもそもフォルダ分けてもfuga.rsなんて作る必要なかったんか？ 他のファイルからfuga.rs触らないならまあそうなのか
普通はやらないけど >>526
×fuga.rs
○fugaモジュール 他のファイルからはa::fuga::bとかでアクセスできるやろ
依存性や役割のまとまりに応じてモジュール階層を切ればいい >>525
そこは>>10と>>13に書かれてるように3つの自由度がある
ただし今回の場合はその対処でよいならばfugaというモジュール自体が本質的には不要なのだろう
fugaという名前空間を外に見せる必要がないならばaのサブモジュールとしてa/b.rsとするかhoge直下にhoge/b.rsとするところ ついにC#の時代がきた
AzureでChatGPTが動かせるサンプルが来たぞ
なんとjupyterでC#を動かしている
(python以外の言語も使えたのかよ)
そさてサンプルの豊富さと美しさよ
ここまできても無視してる奴らは本当に技術力が低いと思う
https://github.com/Azure-Samples/openai-dotnet-samples/blob/main/tweet-classifier.ipynb jupyterってjuliaとpythonとrの略なんですよMAUI君 >>530
Web APIだからどの言語でも使えるんだぞwww
MAUI君は技術力低過ぎて理解できないかもしれないが >>520
その仕様は許容範囲というか
むしろ余計なものを隠したい時に重宝すると思うが？ >>530
AOAI_KEYにSMS認証要らなくなってから来てください
いろいろとボトルネックはそこなので >>496
Occupied とか Vacant とか便所の扉でしか観たことなかったが
こんな使い方するんだな勉強になったわ C++でnewはヒープ領域にメモリを確保するけど
Rustのnewは可変サイズでなければスタック領域にメモリを確保しちゃうんだな >>538
C++と違ってRustのnewは言語仕様じゃなく
関数の慣習的な命名にしかすぎないので
メモリ確保がどう行われるかは関数の実装による 関数名がnewかどうかは自由だが
Selfを返すことになるのでそれは必ずスタック上に置かれる
Selfの中のフィールドなどがVecなどであれば間接的にヒープも使うことになるが
あくまでも間接利用であり直接のSelfの実体はスタック上となる
Selfをヒープ上に置きたいならば明示的にBoxで包めばよい
常にヒープ上に置く使い方のみをするならば
newという関数がSelfを返すのではなくBox<Self>を返す仕様にすることも可能 分数 みたいな 論理演算は昔からあったのに
Rustになって それが強化されたみたいに感じるのは
ただ単に ハードウェアの性能が上がったからじゃないの Rustは後でスタックにもヒープにも移動できるから
最初にどこに確保しようが関係ない
C/C++は合算の対価として、値の移動ができないCの仕様を守る
対価を支払ったのだから合算していい >>541
なんじゃそりゃ
C++のnewも返される値(ポインタ)はスタックに置かれる
Box<T>だってTはヒープでもBox<T>はスタック
さすがにそんな話をしてるわけではないと思うんだが >>544
インスタンスの値の話じゃないかな
C++だとnewしてヒープに置かれる
RustだとBox使わない限りスタックに置かれる >>545
それを言うなら「C++だとnew使わない限りスタックに置かれる」だろ >Selfを返すことになるのでそれは必ずスタック上に置かれる
C++のnewは「ポインタを返すことになるのでそれは必ずスタック上に置かれる」と言ってるのと同じ
以降の文もだけどポイントがズレてるってことわかんないかな RustのBox ＝ C++のnew
どちらもインスタンスをヒープで作ってそれを指すポインタを返す >>547
RustがSelfつまりインスタンスを返す時にポインタは返さない
つまりC++のnewとは異なる >>549
さらにズレたレスだね
しかも間違ってる >>543
C++でオブジェクトのmoveは値が移動するわけではないが
Rustでmoveは値がスタック⇔ヒープと移動することも必要なら可能だからか move等が無かった時代に書かれた仕様を現代の価値観で解釈するのは誤読と言われそうだが
C/C++は常習的にそれをやっていた
CのstructにはOOPの機能が無い・・・のではなく省略できることを書かなかっただけ
と解釈される どこかのタイミングで c++ → c+++ 辺りに解明白 int i {0};
cout << ++i++ << ' ' << i << '\n';
何と表示? >>551
C++のmoveは機能が非常に小さく限られてるのね .NET普通に使えるRust#欲しいかな
要らんな >>558
データがないんだよなあって言うだけならまあいいけど
データがない、ゆえに使いどころが (論理的に) ないと言ってはいけないよ
ほぼ死亡フラグに近い 社内でもRust化は検討してるけど、一番のネックはRustを使える人が集まらないことやね 言語のアシストがあるから、C++よりは安全といっても…習熟が要らないかっていったらまた別の話だしな まぁ実際“安全”って言ったって実際どうなんってよくわからんよな
ただ、マーケティング的に「今Rustってのが出てきました、Microsoftのwindowsも使い始めました、Linuxもです、これからはこういう安全性の高い言語で開発されたものがおすすめできます」というのは売りにはなるやろな
実際ほんとにどれほど安全なのかはわからんけど GCの使いどころを知るためにGCを追放してみた感がある
自分が絶対正しい的な動機がなくても、身の程をわきまえた上でGCをクビにする >>562
ゼロから習得スタートならば
C++よりRustがすっきりしていて習得しやすい
C色んな機能や概念を後付けしてきたC++との違い ソフトウェアの売り文句がその通りだった試しはないんだけどな トロッコ問題もそうなんよ
死者は1人または5人と断定して利点や欠点を皮算用させるけど
現実は0人だったり2人だったりする
問題文がその通りだった試しがないことを知っている人は問題文を否定する >>566
ほぼすべての人にとってはそうだ
しかし抽象化が進んでいるため一部のバカはRustなどの言語を理解できないようだ そういう具体性皆無の発言にいちいち反応してっからくだらん話になっていくんや バカには理解できない言語？
それは習得し易いとは言えないのでは 習得しやすさを基準にすると宗教に勝てないよ
習得しやすいが残酷な教義を信じて戦争したりするよ C,C++,Rustはそのあたりの機能も性能も同じ 勉強するときに参照するサンプルコードはぼぼCで書かれてるからね
3言語ともまだって人にはRustは選択肢にならんだろうね 言語を勉強するのが目的の人はRustかなと思う。
でも、通信やOSの仕組みが知りたかったら大体の本はCで書かれてるし、デザインパターンの勉強やゲームを作りたかったらC++で書かれている本が多い。
そういった先のことを勉強したい場合、Rustで実装されてることは少ないので、優先順位が下がってしまう。 Rustって何て読むのか知らないけど、なんかあまりカッコよく無いな。カッコで言語選ぶべきじゃないとは思うけどね。 ■ このスレッドは過去ログ倉庫に格納されています
