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

**デフォルトの名無しさん** · 2023/05/04(木) 07:49:56.33

「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/

**デフォルトの名無しさん** · 2023/05/30(火) 09:49:54.38

>>632
そいつは特殊学級の子だから
やさしくしてやれ

**デフォルトの名無しさん** · 2023/05/30(火) 10:22:31.41

多分この一件以外でも問題のある人物だったか、揉めたりしてたんじゃない？そうじゃなきゃ講演の構成わざわざ変えさせたりしないと思うけどな

**デフォルトの名無しさん** · 2023/05/30(火) 10:37:01.02

>>630
でも決定はしたんだろ

**デフォルトの名無しさん** · 2023/05/30(火) 10:59:30.52

>>637
誰が何を？

**デフォルトの名無しさん** · 2023/05/30(火) 12:35:51.17

>>634
なら格下げした人間を洗い出してリーダーシップチームから罷免して、不透明なプロセスをジャンヘイド氏に謝罪してから改めて基調講演を依頼だな。
リーダーシップチームが関係していないならなおさら謝罪すべきかと。

**デフォルトの名無しさん** · 2023/05/30(火) 15:11:07.97

Rustの基礎的なことを知らずに批判的なブログを書いてしまったジャンヘイド氏を基調講演に招待する必要はない
ジャンヘイド氏が謝罪すれば一考の余地はあるかもしれない

**デフォルトの名無しさん** · 2023/05/30(火) 15:39:27.39

>>640
結構長くてまだ読めてないけど
あなたが言うRustの基礎的な理解が抜けていて批判的な内容のブログ記事というのはこれのことか？
https://soasis.org/posts/a-mirror-for-rust-a-plan-for-generic-compile-time-introspection-in-rust/

**デフォルトの名無しさん** · 2023/05/30(火) 16:45:23.01

>>622の記事にリンクがあるこのブログだろうね
https://thephd.dev/the-c-c++-rust-string-text-encoding-api-landscape

**デフォルトの名無しさん** · 2023/05/30(火) 17:01:53.53

>>640
招聘するかどうかは論点じゃない
そんなこともわからないのか

**デフォルトの名無しさん** · 2023/05/30(火) 17:05:04.05

ギスギスして嫌やわー

**デフォルトの名無しさん** · 2023/05/30(火) 17:12:20.67

>>642
https://www.jntrnr.com/why-i-left-rust/
> 6. [...] as best as I understand it, because of the content of JeanHeyd's blog post on reflection in Rust.

オリジナルにはリンク貼ってないけど、「リフレクションに関する」JeanHeydのブログポストって書いてるから、その記事は違うのでは？
GIGAZINEの英語力を信頼してはいけないよ

**デフォルトの名無しさん** · 2023/05/30(火) 17:28:40.28

>>642
既知のUTF8に対してUTF8チェックをしない効率的なAPIを用意すべきだという主張をしている感じかな
JeanHeyd氏はstd::str::from_utf8_uncheckedを知らないのだろうか？

**デフォルトの名無しさん** · 2023/05/30(火) 19:39:03.67

>>640
> Rustの基礎的なことを知らずに批判的なブログを書いてしまった

そこまでわかっているなら、ブログの批判的な部分を指摘してくれないかね。
本当に「基礎的なことを知らずに」書いたように読めるの？
でっち上げじゃないの？

**デフォルトの名無しさん** · 2023/05/30(火) 19:45:23.06

>>646
第一にそんな主張は書いていないし
第二にそもそもこの記事はC/C++で使えるテキストエンコーディングライブラリの比較ですよ
比較対象に挙げられたencoding_cの裏にencoding_rsがいるので参考程度にRustに言及されてるってだけで

from_utf8_uncheckedでstr作ったところでそれC++にどう持ってくるのかと
文脈読めてないからそういうこと言っちゃうんだろうけど

**デフォルトの名無しさん** · 2023/05/30(火) 19:54:32.62

>>623
>無知思い込みでRustを勘違い批判
これ何？

**デフォルトの名無しさん** · 2023/05/30(火) 20:00:14.58

https://blog.rust-lang.org/2023/05/29/RustConf.html
経緯は現在調査中だが、意志決定のプロセスに不透明さがあったことは認める
JeanHeydおよびRustコミュニティに謝罪します、だそうです

**デフォルトの名無しさん** · 2023/05/30(火) 20:06:40.81

Rustは独裁だぞっみんな逃げろっ

**デフォルトの名無しさん** · 2023/05/30(火) 20:14:44.53

>>650
責任のなすりつけあいになるかな。
あるいはこのままウヤムヤになるか。

**デフォルトの名無しさん** · 2023/05/30(火) 20:22:43.78

>>623,634,636,640
Rust Leadership Councilは謝罪したようだが、お前らはどうだ？
特に>>623と>>640

**デフォルトの名無しさん** · 2023/05/30(火) 21:28:34.48

嫌やな人達やわー

**デフォルトの名無しさん** · 2023/05/30(火) 21:52:32.09

>>653
全部複オジやんw

**デフォルトの名無しさん** · 2023/05/31(水) 09:24:17.89

結局、カスが出て行っただけ、Rustとしては願ったりかなったりって感じでおｋ?

**デフォルトの名無しさん** · 2023/05/31(水) 10:51:38.71

>>656
お前これ書いた奴だろ、良識の欠片もねえ全エンジニアの敵

結局C++とRustってどっちが良いの？ 2traits
https://mevius.5ch.net/test/read.cgi/tech/1680363777/604
604: デフォルトの名無しさん 2023/04/26(水) 16:48:15.43 ID:9EDgaMeS
月面着陸船が落っこちたそうだが
Rustで書いてれば成功したはず
それにしてもローバーは活躍出来ず流産乙

**デフォルトの名無しさん** · 2023/05/31(水) 11:02:53.91

どう誤解されようとかまわんが、俺はもうC++でいいや派だぞ

**デフォルトの名無しさん** · 2023/05/31(水) 11:19:20.25

Rustの環境はC++と全然違うのでC++で練習できないし、ぶっつけ本番の方が安い
と言ったな、あれは全部嘘だ

**デフォルトの名無しさん** · 2023/05/31(水) 11:41:10.94

>>658
c++巻き添えにすんな。

**デフォルトの名無しさん** · 2023/05/31(水) 12:30:15.41

補助輪付きは安全で素晴らしい

**デフォルトの名無しさん** · 2023/05/31(水) 12:31:26.42

補助輪無しは道路が危険になるので禁止するべき

**デフォルトの名無しさん** · 2023/05/31(水) 12:39:24.63

コストと不自由さを気にしなければ、インストラクター付き教習車は事故を起こしづらい。

**デフォルトの名無しさん** · 2023/05/31(水) 12:41:23.70

二輪のヘルメットや四輪のシートベルトみたいなもんだな
導入前の人間からしたらウザくて仕方がない

**デフォルトの名無しさん** · 2023/05/31(水) 13:40:22.77

コストを気にしないんじゃないんだよ
数値化できないことを数値化するのは無駄な努力だと思ってるんだ
質素倹約と富豪の対立じゃなくてどっちも相手のことを浪費家だと思ってる

**デフォルトの名無しさん** · 2023/05/31(水) 14:04:07.40

シープラに既にどっぷり浸かった老兵はそりゃシープラがいいさ😔

**デフォルトの名無しさん** · 2023/05/31(水) 21:46:50.85

長らく正直、スマポは甘えだと思ってた
いまや、スマポは許された

**デフォルトの名無しさん** · 2023/05/31(水) 22:15:59.53

新技術に自身のポジションを脅かされると思って叩くのはよくあること

**デフォルトの名無しさん** · 2023/05/31(水) 22:27:42.59

バイリンガルのような掛け持ちは新技術じゃないが
一人で二票も三票も入れられたら人気投票データの権威が脅かされる

**デフォルトの名無しさん** · 2023/05/31(水) 22:30:14.41

叩かれない限りほっとくんだけどな
自身の、っていうか、推しのポジションだね
推しだよ推し付き合い長いんだ

**デフォルトの名無しさん** · 2023/05/31(水) 22:31:16.45

新技術ってほど画期的かね?

**デフォルトの名無しさん** · 2023/05/31(水) 22:52:07.27

開発効率の上昇がありがたいね
関数型言語の成果導入による短くわかりやすい記述面から
メモリ管理やデータ競合のバグや実行デバッグから解放されたことまで

**デフォルトの名無しさん** · 2023/05/31(水) 23:14:15.12

>>672
バレバレ

**デフォルトの名無しさん** · 2023/06/01(木) 05:13:56.85

はっきり言ってスマポとデバッガで事足りる

**デフォルトの名無しさん** · 2023/06/01(木) 05:52:07.39

ライフタイムが無いとスマポだけでは無理

**デフォルトの名無しさん** · 2023/06/01(木) 06:13:04.77

まじで? たとえば?

**デフォルトの名無しさん** · 2023/06/01(木) 09:22:18.21

どうせまたdangling pointerが作れちゃうって話を長文で書くんだろ
もういいよ

**デフォルトの名無しさん** · 2023/06/01(木) 09:37:25.18

ライフタイムがないと関数から返そうとしている参照(ポインタ)が有効なスタッフ領域もしくは有効なヒープ領域を指していのかを保証できない

**デフォルトの名無しさん** · 2023/06/01(木) 10:16:34.79

>>677
草
入門書の最初のほうに書いてるような内容を
ひたすら繰り返し演説するのが好きなんよ彼はｗ

**デフォルトの名無しさん** · 2023/06/01(木) 12:18:27.95

入門書の最初のほうに書いてるような内容を
入門書も読まずに聞いちゃう676みたいな初心者がいるからしゃーないやん

**デフォルトの名無しさん** · 2023/06/01(木) 14:35:57.29

RefCellからget_mut()したらどこかでget()したRefが生きてたせいでpanicしたということがあって
そのときはデバッガのお世話になって問題のget()してる場所を探すことができたんだが
実行デバッグから解放されたらしい>>672はもっといい方法を知っているんだろうか

**デフォルトの名無しさん** · 2023/06/01(木) 14:43:24.51

他スレッドに持ち出さない保証ができればどうだ

**デフォルトの名無しさん** · 2023/06/01(木) 14:43:52.25

あら、IDかわってる >>682は>>676

**681** · 2023/06/01(木) 14:52:20.51

×get()/get_mut()
○borrow()/borrow_mut()
でした

**デフォルトの名無しさん** · 2023/06/01(木) 15:32:59.04

clippyとかで多少拾えるだろうけど実行時チェックがpanicにならないようにするのはプログラマの責任

デバッグから解放されるなんて話は夢物語だが
デバッグしないとborrowとborrow_mutのlifetimeが分からない状態は見直した方が良い

**デフォルトの名無しさん** · 2023/06/01(木) 15:54:48.22

English translation:

No.

**デフォルトの名無しさん** · 2023/06/01(木) 16:50:46.87

>>678
本当にそんな不自然な状況に頻繁に出くわして困ってるの?
設計おかしいんじゃないの?

**デフォルトの名無しさん** · 2023/06/01(木) 21:02:26.16

常に問題なく設計できる人はRustでライフタイムを満たすことも容易
複雑になると混乱しうる場合はC++で穴の可能性が残るがRustならライフタイムのコンパイルエラーが検出され助かる
実際にMicrosoftやGoogleがその穴の頻出でセキュリティ脆弱性も招いていたと判断してライフタイムを用いるRustへ移行中

**デフォルトの名無しさん** · 2023/06/01(木) 21:07:45.31

>>688
>>678
>ライフタイムがないと関数から返そうとしている参照(ポインタ)が有効なスタッフ領域もしくは有効なヒープ領域を指していのかを保証できない
スマポ返せばええだけちゃうの?

**デフォルトの名無しさん** · 2023/06/01(木) 21:10:07.38

>>688
>実際にMicrosoftやGoogleがその穴の頻出でセキュリティ脆弱性も招いていたと判断してライフタイムを用いるRustへ移行中
社内の好き者が試してるだけじゃないのん?
全ソースの何%くらいなんかな?
移行って書くと新規は全て感じがするがそれ誇大広告じゃ?

**デフォルトの名無しさん** · 2023/06/01(木) 21:23:32.48

>>689
スマポunique_ptrはカバーできる範囲が狭い
スタック上のインスタンスに対しては使えないためヒープ上のインスタンスと共通に扱えなくなる
部分領域に対しての扱いも同様

**デフォルトの名無しさん** · 2023/06/01(木) 21:33:58.30

5/30の一連の流れは何事も無かったかのように平常運行に戻ってるの、ふてえ野郎だぜ

**デフォルトの名無しさん** · 2023/06/01(木) 21:39:32.47

Rust公式と自分の意見が違っているのが分かった瞬間急にｽﾝ……ってフェードアウトするの最高にダサかったよ

**デフォルトの名無しさん** · 2023/06/01(木) 21:53:38.87

>>691
C++でスタックのポインタ返しちゃいかんだろw
論外

**デフォルトの名無しさん** · 2023/06/01(木) 21:54:37.80

FirefoxがプチフリするのはRustのせいじゃないのか？

**デフォルトの名無しさん** · 2023/06/01(木) 22:03:56.60

>>694
スタック領域を指すポインタを返せないと不便で効率が悪くなるぞ

**デフォルトの名無しさん** · 2023/06/01(木) 22:14:49.71

>>696
は? C++で?

**デフォルトの名無しさん** · 2023/06/01(木) 22:21:04.58

未だに未定義動作という不発弾を検出できない欠陥言語

**デフォルトの名無しさん** · 2023/06/01(木) 22:29:25.95

スタック上を指すポインタを常に安全に返せるようになると
ヒープを使わずにスタック上だけで済ませられるケースが生じる
それは高速化に寄与する

**デフォルトの名無しさん** · 2023/06/01(木) 22:41:03.06

そもそもC++は関数でスタックのポインタを返してはいけない
それを
>>678
>ライフタイムがないと関数から返そうとしている参照(ポインタ)が有効なスタッフ領域もしくは有効なヒープ領域を指していのかを保証できない
ってのは支離滅裂な議論

**デフォルトの名無しさん** · 2023/06/01(木) 22:43:29.65

C/C++では確かに以下の関数をエラーなく書けるが（警告は出るけどね）
これにエラーを出すことにどれだけの意味があるかな?

int *fun ()
{
int a;
return &a;
}

**デフォルトの名無しさん** · 2023/06/01(木) 22:50:50.58

Rustはライフタイムがあるからそういう返してはいけないポインタ(参照)はコンパイルエラーとなるし
たとえスタック領域を指すポインタであっても安全に返せる時はコンパイルが通って使えるね

**デフォルトの名無しさん** · 2023/06/01(木) 23:02:08.29

>>702
>Rustはライフタイムがあるからそういう返してはいけないポインタ(参照)はコンパイルエラーとなるし
C/C++で>>678のような間違いする人はいないから全く意味がないんだよ
頓珍漢なことを書かぬように
批判の前にはそれなりに批判対象も勉強し給え
（念の為に書いておくがライフタイムを否定するものではない）

**デフォルトの名無しさん** · 2023/06/01(木) 23:11:12.73

>>694
> C++でスタックのポインタ返しちゃいかんだろw
> 論外

普通に返すぞ

**デフォルトの名無しさん** · 2023/06/01(木) 23:30:58.01

>>704
は? どんなコード?

**デフォルトの名無しさん** · 2023/06/01(木) 23:34:30.43

>>703
その単純な例で間違える人はいないけど、
複雑に込み入った例で返してもよいポインタと返してはいけないポインタの判断を間違えることは起き得る
その発生がレアで運用時に発覚となると悲惨だ

**デフォルトの名無しさん** · 2023/06/01(木) 23:43:15.74

>>706
>複雑に込み入った例で返してもよいポインタと返してはいけないポインタの判断を間違えることは起き得る
絶対に間違えないと断じれる
ライフポイントが役立つのはそんなところじゃない

**デフォルトの名無しさん** · 2023/06/01(木) 23:43:54.39

-ライフポイント
+ライフタイム

**デフォルトの名無しさん** · 2023/06/01(木) 23:51:59.43

見事に単発ばっかりだけど
複おじはこの構図を「顔を真っ赤にしたC++信者に群がる勇敢なRust戦士たち」と見てもらえると本気で思っているのかな？

**デフォルトの名無しさん** · 2023/06/01(木) 23:53:45.26

>>707
ライフタイムを指定する関数や構造体を書いたことないのか

**デフォルトの名無しさん** · 2023/06/01(木) 23:54:57.04

自演じゃないならこっちでやってみてよ
ちょうどいい題材

C/C++のソースをRustへ全力で置き換えるスレ
https://mevius.5ch.net/test/read.cgi/tech/1681777958/

**デフォルトの名無しさん** · 2023/06/01(木) 23:58:48.29

>>700
そんな制限はない
C++でもスタックのポインタを返してもよい

**デフォルトの名無しさん** · 2023/06/02(金) 00:08:14.98

>>712
どんなコードを言ってるのか分からんので書いてみて
もちろん>>701のようにコンパイルは通るけど
関数脱したら消滅するスタックのポインタ返して
どう実用するのかスゲー興味ある

**デフォルトの名無しさん** · 2023/06/02(金) 00:09:53.77

>>710
俺はRustは書かないよ
それともその「ライフタイムを指定する関数や構造体」ってのは
C++の話しかい?
よく分からんので簡単なコードで示してみて

**デフォルトの名無しさん** · 2023/06/02(金) 00:11:47.32

アドレス値を返すだけで読み書きしないんじゃね

**デフォルトの名無しさん** · 2023/06/02(金) 00:12:42.40

Rustを書かないやつが連投して暴れてるのかｗ
通りで無知なわけだ

**デフォルトの名無しさん** · 2023/06/02(金) 00:48:31.36

>>713
複おじはバカだがお前もお前で「スタック」が「現在の関数のスタックフレーム」以外も指すことにいい加減気付け

**デフォルトの名無しさん** · 2023/06/02(金) 00:54:45.14

スタック領域のポインタ返すってstatic変数のこと言ってんの？

**デフォルトの名無しさん** · 2023/06/02(金) 01:14:58.53

>>716
C++に関して頓珍漢なことを書いていたら否定している
知らんことに関してはコメントしていない

**デフォルトの名無しさん** · 2023/06/02(金) 01:16:10.14

>>717
「現在の関数のスタックフレーム」以外のスタックって何なん?
知らんので教えて

**デフォルトの名無しさん** · 2023/06/02(金) 01:17:36.57

>>718
さすがに違うと思う

**デフォルトの名無しさん** · 2023/06/02(金) 01:58:01.64

スタックからアドレスを取得して、それをスマポにしないのは、その段階でunsafeだろ

**デフォルトの名無しさん** · 2023/06/02(金) 02:03:25.21

>>722
スタックのインスタンスのアドレスはスマポには入らん
C++では参照型を使う
Rust的にはたぶんunsafeかな?

**デフォルトの名無しさん** · 2023/06/02(金) 02:08:30.56

>>720
典型的には呼び出し元のスタックフレーム、呼び出し元の呼び出し元のスタックフレーム、呼び出し元の……以下略

具体例で言うなら、strchr()にスタック上の文字列を渡したら帰ってくるのはスタックを指すポインタでしょうが
strchrのスタックフレームとして積まれた領域じゃなきゃ別にスタックを指すポインタを返すこと自体に問題はないのよ
分かったらもう黙っててくれ、例の自演君がつけあがるだけだから

**デフォルトの名無しさん** · 2023/06/02(金) 02:22:36.30

>>723
Rustの参照はsafe
常に有効な領域を指す

**デフォルトの名無しさん** · 2023/06/02(金) 02:31:49.11

>>724
なるほど関数呼び出し元のスタックね
しかし話の起点>>678に書かれているのは呼び出し先関数が返そうとしている
参照（ポインタ）の有効性をどう保証するかという話
一方で呼び出し元のスタックの有効性を保証すべきは呼び出し元で
呼び出し先が感知すべき内容ではないと思うが?

**デフォルトの名無しさん** · 2023/06/02(金) 02:34:40.83

>>725
参照のダングリングなんて起こらないけどね
ただしマルチスレッドだと起こり得るのでshared_ptrで指す
このくらいのことを出来ない輩がいるので
Rustの存在意義がある

**デフォルトの名無しさん** · 2023/06/02(金) 02:38:30.45

>>722
C++はそれをすることができない
スマポに格納できるのはヒープ領域を指すポインタのみ
Rustはスタック領域でもヒープ領域でも所有権を持つがC++はスタック領域で持てない

**デフォルトの名無しさん** · 2023/06/02(金) 02:42:18.59

>>728
参照型で受ければ良いのでは？

**デフォルトの名無しさん** · 2023/06/02(金) 02:44:59.65

>>727
C++の参照は気をつけないとダングリングになる
この記事の二つの例は興味深い
https://qiita.com/sumomoneko/items/58358eb8bcc8b70a481b

**デフォルトの名無しさん** · 2023/06/02(金) 07:24:04.28

rvalueとlvalueを理解しないものにC++は無理
Javaを使いなさい

**デフォルトの名無しさん** · 2023/06/02(金) 07:42:10.08

やだことわる、Oracle怖い

**デフォルトの名無しさん** · 2023/06/02(金) 12:13:39.36

>690
unsafe {} だらけだよ！

**デフォルトの名無しさん** · 2023/06/02(金) 13:57:04.29

>>730
面白いけどtrivialだと思うね
しかしtrivialなので嵌るのかもしれない