結局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/ >>376
> さらにunique_ptrは空っぽの状態、つまりヒープ領域を伴わない状態が許されるのに対して、
> Boxは必ずヒープ領域を伴っていて、そこに値を必ず持っている、という重要な違いもあるね
だからBoxとunique_ptrは対応しないってんなら、Arcとshared_ptrを対応させるのはもっと間違ってるぞ Boxはボックス化つまりヒープに置くこと
C++で対応するのはnew BoxもZero Sized Type(ZST)だとheapを伴わないよね >>377
Rustは凄いと言ってる奴は、自分はRust使ってないからな Javaが出てきたとき
Javaすげぇぇ他の言語は駆逐される
PHPが出てきたとき
PHPすげぇぇ他の言語は駆逐される
何か出るたびそれを信仰し同じコトを繰り返すんだな 自分で作るじゃなく他所で作られたものを自慢をするというね
こういう言語そうだそれ以外の物でもそうだし >>384
結局どうなったかっていうと、PHPはサーバサイドのDSLとして落ち着いた
JavaはOracleが接収? した
立ち位置が減少したのは多分Perlだが、いまPerl使ってるって言っても殴る人はいない
(以上、すべて個人の感想)
今回は、LLVMの成熟により、様々な言語が2.0化しようとしてるみたい
わりと何ででも、安全に、高効率なプログラミングができる時代になるのかもしれない
Rustは、新しいbetter C のような気がしてきた
…けど、記述法がどうしても見慣れない(ｗ javaはIT企業ではある意味他言語をを駆逐したと思うわ
特殊なケースだけc++、ｖｂ使う
webのDSLでtypescript
地元（田舎）の求人見ると
java,C++が使える人かjs使える人の求人が99%だから… これでWindows、Linux、AndroidがRust採用かー rubyは使ってると殴られる言語だが
pythonはまだ大丈夫だな
phpやvbは死んでいい >>387
記述法が見慣れないのは
キミが関数型をやってないからじゃね 色んな言語やっている中で見比べて
Rustの記述法のほとんどの部分は
複数言語に見られるものかその平均に近い記述
>>387の見慣れない記述法とは何を指すのだろう ::も<type>もC++と同じだから連続してもそれほど違和感ない goの配列の指定はいまだに慣れないと言うかなんじゃこれだけど
rustは&mutとかライフタイムの指定をもっと独自のものにして欲しかった C++構文定義上の最大の罪である山括弧ジェネリクスを引き継いでしまい
構文の曖昧性を無くすために苦肉の策で生まれたのがあの悲しきお魚ちゃんなのですよ >>397
>C++構文定義上の最大の罪である山括弧ジェネリクスを引き継いでしまい
何が問題なのかな? < >は解釈の時若干邪魔なのかとは思うけど
ヒマだからANTLRで構文解析器でも作ってみようか >>401
typedefかっけーやん
#include <iostream>
using namespace std;
struct Hoge {
void hage () const {cout << "hage" << '\n';}
};
int main () {
typedef void (Hoge::*Mage) () const;
Hoge hoge;
Mage mage {&Hoge::hage};
(hoge.*mage) ();
return 0;
} 何かの言語でvector<vector<int>>の">>"の間にスペースが必要だった記憶があるけど
昔のC++だったかJavaだったか思い出せない
シフト演算子と相性悪いんだよね
どうやって解決したんだろ 次スレのスレタイはC++ Considered Harmfulにしよう >>402をtypedefなしで書くと逝っとるよな
- Mage mage {&Hoge::hage};
+ void (Hoge::*mage) () const {&Hoge::hage};
何でこんな記法にしたんだろ? 変数宣言と構文を共有することでパーサの実装量節約に一役買っているのです 俺は使える程には理解してるが人にはちょっと説明できん >>411
しばらく検索してみたけどソースが見当たらないので取り消します C/C++ は(関数ポインタのときを除いて)
hoge と &hoge と &&hoge と &&...&hoge は明確に区別されるけど
Rust だと区別されずにコンパイル通ってしまうケースもあるんだな
むしろ警告でも良いので出してくれればいいのに >>399
C++ の <Hoge> 入れ子で
<Hoge<Hoge>> とは書けなくて
<Hoge<Hoge> > と書くとちゃんと動く
だっさーと思った >>414
型で厳格に区別できるから使い間違えることや問題がおきることはなく
さらにfoo.barとfoo->barを一本化してfoo.barだけにしたRustが便利で合理的かな >>414
Rustでも区別されてるけど場所によってはDeref Coercionが働くから
区別されてないように見えるというだけ
https://doc.rust-lang.org/book/ch15-02-deref.html >>415
いつの話だよ。
C++11以降を知らんのか。 じゃあジェネリクスの記号を何にすればよかったのかの話は無いよね。
代替案が無いなら貶さない方がいいよ Box[T]
Box t
't box
(box t) 今さら代替案を出したってもう広まってるから無理だし、本気でこれを変えて「改善」になるなんて思ってる人はいないだろうが
C++の山かっこがC++11で改善されるまで長いことクソクソ言われてたのになぜRustは……ってだけのただの冗談だよ
本気にさせちゃったようですまないね Rustのジェネリックスの記法はこうこうこうだから美しい！マンセー！
って言わなきゃ話が続かないよ http://www.kmonos.net/alang/d/templates-revisited.html
クソクソ言われていた時代にRustと似た動機で作られたD言語はBox!(T)だったんだね
みんないろいろ考えるんだね〜 > C++構文定義上の最大の罪である山括弧ジェネリクス
> C++の山かっこがC++11で改善されるまで長いことクソクソ言われてた
完全にコイツはエアプ
当時そんなとこに文句言ってるやつ見たこと無い
みんな真顔で「> >」隙間開けてたわ
指がオートマチックでスペース叩いてるはず
仕事やってりゃ色々クソなことはあるが
それを言語に転嫁するようなザコはここにはいないよね？ 「もう広まってる」とは言うがRustがわざわざ山かっこ<>をジェネリクス用に選んだ経緯とかはあるのか？
本当に惰性と流れで<>にしたの？
Dみたくa!(b,c)にしなかったのはなんでだ？
やっぱりDのa!(b,c)なる記法は純粋に見映えがダサくて、C++的なa<b,c>なやつはなぜかイケてる、ていうだけのことだろ https://soc.me/languages/stop-using-angle-brackets-for-generics.html
ここに書いてあることも一理あるけど
Goのようにsquare bracketでのインデックスアクセスを残したままFoo[T]にするのも微妙
unlimited look-aheadが必要だとしても実際にそんな長く先まで読む必要性なんてないので
読みやすさが勝るのならそれでいいと思う
ターボフィッシュはイケてないけど >>425
C++がだらしないから、こんだけRust勢に煽られてる、っては思ってるけどね
あまりに煽られて、一行もRust書いてないのに、併用する心の準備ができつつある
でもぜってえC++は捨てねえ、ぜってえにだｗｗｗ > 煽り勢 言語そのものを作ってるような人じゃなければ
あまり特定の言語に固執しないほうがいいよ
RustだろうがC++だろうがレゾンデートルに特定の言語を組み入れてる人は成長が止まりやすく老害化しやすいので自分が損するだけだから
所詮は使い分ける道具の一つ プログラミング言語をただの道具と言うやつは大抵無能 >>433
ただの道具とそうでない道具の違いは何？
定義を説明してみて 何か作るときに道具に拘る気持ちはめっちゃわかるけどなあ 道具によって成果物の品質が変わるのだからこだわるのは当たり前
ただの道具とか言うやつは安定してゴミを作るからそういう感覚がないのよ ここからは理論無用でレスできるのでスレが進むのか？ 作るものが複雑になると、普段から使ってよく理解している言語でないと
調べ物が多くなって効率が悪い。 問題領域の濃度と文法の濃度を考えれば、全ての用途で便利に使える万能言語なんてありえない。
言語には必ず得意領域と不得意領域があるんだから、問題領域に合わせて言語を選択・作成するのが望ましい。 If all you have is a hammer, everything looks like a nail.
>>437
宗教上の理由でﾜｯﾁｮｲスレに書けない人が荒れることを無限に書き込むから ちょっとしたスクリプトを書く程度で済むケースは、シェルスクリプトやスクリプト言語を使えば済むから対象外として、
がっちりプログラミングするならば、実行速度やメモリ使用量などのリソース、可読性や保守性を含めた開発効率などで、プログラミング言語を選びたい。
慣れれば大した手間増加にならないのだから、CPUメモリリソースや時間を考えると、C++とRustが選ばれるべきシーンは多そう。
C++とRustが忌避される理由は他言語より「難しい」「面倒」だけど、慣れてしまえば他の言語と大した違いはないわけだから。 目玉焼きに醤油を掛けるのかソースを掛けるのかマヨネーズ掛けるのか塩を掛けるのか
ぐらいのレベルがこの後30レスぐらい続くのかなあ？ 塩だろ。俺は邪道のアジシオだな
どんなターゲットにも合う。最悪、スイカにすら合う。
Cもそんな感じ。 >>433
道具を「ただの道具」にするかどうかは使い手の問題なんだよ
それがわかってない君は無能
そもそも>>432が「ただの道具」と言ってるように見えるようじゃ終わってるよ マンパワー依存の無能はさすがに苦笑
エンジニア向いてないよ笑 まあC++にもunsafe{ } は来てほしいけどね
統一的な方法がなかったので、今後Rustのやりかたが他言語にも波及するっしょ >>446
global deleteを無くすのと、参照渡しのライフタイム保証があればいいよ。 何か未知で不確実だとしてもただの道具ならその目的は既知だったりするでしょ
デストラクタの後で参照しないとか
デストラクタの後でデストラクタを呼ばないとか
だがメモリリークをあまり問題視しない件などは目的自体が変化してしまうから
ただの道具ではない >>447
Rust勢が言っているのは、Rustで書いたものは安全といって納品できる、ということなので、
ガイドライン チェッカとかじゃなく、言語にちゃんとunsafe{ } があるというのはモダン
何をもってsafeとするかには議論があったが、Rustがデファクトスタンダードになるなら、それを取り込めばいい
ひとつの夜明けは近い >成長が止まりやすく老害化しやすい
道具云々は↑これが図星で悔しかったんだろ
その後のレス見れば成長止まって老害化してる人だとよくわかる 当たり前だけど、攻撃力がレーゾンデートルになるよりは回避力か防御力のほうが
ダメージやストレスが少ない >>449
shared XOR mutableはちょっと面倒くさい。
せっかくスタックフレームベースなんだから、それ前提にもっと手軽にできないかなぁ。 >>453
値を変更する時にそれが他から参照されてるかはRust以外でも多少は意識してるはずだし
変更可能な状態で共有することに意味があるならRefCellとかCellに入れて共有すればいい
面倒といっても安全のための規約レベルでしょ
（違反するとコンパイラに殴られるからある意味手間が省ける） >>453
正確にはshared NAND mutable 所有と参照を区別しない場合は
参照が一つもない値の存在は許されない (循環参照が許されないとは言ってない) ので
むしろxorが正確である場合もあるかも >>457
それじゃ値について述べてるのか参照について述べてるのかそれとも型について述べてるのか曖昧すぎてルールとしては使い物にならない
主語と目的語を明確に意識してないと所有権複製の二の舞だよ ああ、C++では値と参照を区別するとかしないとか言うね
でも動詞を使いたくなったら「参照する」は正しいが「値する」はおかしい
だから値を所有する、値を参照するというのが良い C/C++の値に所有なんてあるのか
参照なら実体側の所有が誰か問題になるかも知れんが >>460
無い。
特に「所有」の一般的な概念に含まれる(他から制限を受けないという意味での)排他性・専有性は無い。 C++の参照がダングリングを引き起こす根本的原因は、
値の所有とその生存期間を参照に対してはっきりさせていないため？ use Hoge; と
extern crate Hoge; の違いが判ったわ
新しいとか古いとか言ってる人が以前居たけど嘘だったω 待て待て
そもそもC++でダングリングを起こしたことがない
Rustは言語仕様上関数でヒープまで消しちゃうから
仕組みがないとダングリングを起こしやすい
ダングリングはRust固有の持病 >>464
逆だよな
ダングリングポインタが生じるのはC++ >>464
関数でヒープを自動解放する仕組みすなわち自動的にデストラクタが呼ばれる仕組みはC++とRustで同じ デバッグビルドでよければ、結構重厚にチェックしてくれるんだけどね
リリースビルドでも一定程度チェックが残ってくれるようになれば、まだましになるか >>462
C++でも値に対する所有とライフタイムを明確にして参照のライフタイムがそれ以内に収まる枠組みにすればダングリングを防げるようになる Rustの知名度の上昇は、WasmのWASIのサンプルがCではなくRustで書かれている
ことにも起因するらしい。だから、Wasmで検索するとRustが出てきてしまう。
しかし、このことは、WASIの普及の足を引っ張るかも知れない。
なぜなら、C言語が基本だから。 >>468
「～でも～できるようにすれば～できる」
万能だねw 願望だから嘘だとか万能だから嘘だとかいう雑な説明は蛇足だな
説明しない自由があるべき
嘘でもいいから何か説明した方がマシというのは大嘘だ C++君はコンパイルでチェック出来るようになってから出直してきなさい 5ch見ない間に変なスレ立ってんじゃん
どっちが優勢なのこれ C++ってasync/awaitもまだstableではないんだな
大変だね GitHubとStack Overflowか
まあお世話になってるけどそれでランキング付けされてもなあ
5chのム板を集計してみてよ外人 Rust では || {} が
closure になるものとばかり思っていたが
関数ポインタとして扱われるケースもあるんだな
区別されてるということを学習した ■ このスレッドは過去ログ倉庫に格納されています
