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

**デフォルトの名無しさん** · 2023/07/29(土) 15:05:46.55

C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」

っていう雑談スレ。

前スレ　
https://itest.5ch.net/mevius/test/read.cgi/tech/1688129795

関連スレ(マ板): Google&MS「バグの70%はC/C++。Rustにする」
https://medaka.5ch.n...cgi/prog/1619943288/

**デフォルトの名無しさん** · 2023/07/31(月) 13:56:25.29

>>56
意味がわからん
日本語も書けなくなったのか？

**デフォルトの名無しさん** · 2023/07/31(月) 13:58:30.69

>>57
多分、アメリカ人が書いている。

**デフォルトの名無しさん** · 2023/07/31(月) 14:57:58.99

>>52
あの頑固者のLinusが解禁したこと自体が画期的

RustがOKなら、Rust程度のOOPはOKってことで、近い言語が続々参入したりして
そうなると、simple化付きC++ってのも見えてくる

**デフォルトの名無しさん** · 2023/07/31(月) 15:00:33.59

>>59
Rustコンパイラは何を使うの?

**デフォルトの名無しさん** · 2023/07/31(月) 15:05:23.78

何かの政治的な理由でRustを仕方なく使ったんじゃね？

**デフォルトの名無しさん** · 2023/07/31(月) 16:30:08.80

>>60
知らんまじで処理系に指定があるかまでは存じ上げず

**デフォルトの名無しさん** · 2023/07/31(月) 18:53:04.02

普通にrustc（+llvm）でいいでしょ
知らんけど

**デフォルトの名無しさん** · 2023/07/31(月) 19:29:15.62

>>63
じゃカーネルのコンパイルは何使うの?

**デフォルトの名無しさん** · 2023/07/31(月) 22:08:37.01

カーネルおじさん

**デフォルトの名無しさん** · 2023/07/31(月) 23:55:46.68

どいつもこいつもマウントを取る相手に飢えてるんやなあって

**デフォルトの名無しさん** · 2023/08/01(火) 00:02:17.45

パタリとレスが止まったが
>>59みたいなこと書くのなら>>60とか>>64には答えられんとなぁw

**デフォルトの名無しさん** · 2023/08/01(火) 01:13:33.06

カーネルは知らないがrustcでコンパイルしたものとc言語で書かれたものはリンクできて動いてるし何を問題にしているのかわからない
最近はPythonやJavaScriptのライブラリもRustで書かれることが増えている

**デフォルトの名無しさん** · 2023/08/01(火) 01:42:20.33

>>68
Linuxカーネルは伝統的にgccでコンパイルされてきた
rustのコードはrustc on llvmでコンパイルされる
そうするとgccが吐いたオブジェクトファイルと
rustc on llvmが吐いたオブジェクトファイルをリンクできるのか?
という疑問が普通に浮かぶ
[解法1] できるのなら何も問題ない
[解法2] できないのならカーネルをclang on llvmでビルドすればリンクできるだろう
最近はclang on llvmでカーネルをビルドすることもあるみたいで
検索するとAndroidはclangらしい
[解法3] あるいはgccrsでrustコードをコンパイルすればgccのコードとリンクできるだろう
さて始まったらしい（しかし何もリリースされていないw）カーネルでRustの利用方法は
1なのか2なのか3なのか? あるいは別の方法かな?

**デフォルトの名無しさん** · 2023/08/01(火) 01:44:23.88

>>59みたいなこと書くのなら答えられんとなぁw

**デフォルトの名無しさん** · 2023/08/01(火) 01:47:19.20

WindowsでRustの利用が始まっているらしいが
MSはllvm使うのかね? Visual Rustかね?

**デフォルトの名無しさん** · 2023/08/01(火) 02:10:15.58

>>69
何を問題にしているのかさっぱりわからん
gccもclangも同じELF形式のオブジェクトファイルを吐くだけだぞ
共有ライブラリなども当然同じものが使われている
コンパイラ毎に別々の形式を吐いて共有ライブラリなども別々に用意されていると勘違いしている？？

**デフォルトの名無しさん** · 2023/08/01(火) 02:15:20.41

rustのコードはrustc on llvmでコンパイルされる
そうするとgccが吐いたオブジェクトファイルと
rustc on llvmが吐いたオブジェクトファイルをリンクできるのか?

あほすぎわろす

**デフォルトの名無しさん** · 2023/08/01(火) 02:28:22.85

>>72,73
じゃ1で良いのかな?

**デフォルトの名無しさん** · 2023/08/01(火) 02:44:40.50

そもそもRustは全く関係なくC言語だけを使う世界でも同じ話
コンパイラを変えてもリンクする既存ライブラリは同じものを指定して同じものをリンクするだろ
それを知らないとはエアプログラマーかね？

**デフォルトの名無しさん** · 2023/08/01(火) 02:46:40.94

まずrustcがllvmでコード生成してることを知ってるかどうか確認する必要があるな
rustc on llvmという表現に若干の不安を感じる

もしかしたらllvmを知ってるかどうかの確認も必要かもしれない

**デフォルトの名無しさん** · 2023/08/01(火) 03:08:01.35

>>75,76
じゃ1で良いのかな?
つまりカーネルはgccでビルドして
Rustで書かれたカーネルモジュールは（まだないけどもw）
rustcでコンパイルするのかな?

**デフォルトの名無しさん** · 2023/08/01(火) 03:19:00.62

coff とか omf とか elf とか面倒だよなω
D は沈没したしωωω

59 · 2023/08/01(火) 06:25:09.53

夏風邪で寝込んでた隠れ新型コロナかもしれんちなマスクはしてる

俺はC++派だし、どうしてるんかまで知らんって
Rust部のツールチェーンのバージョンを指定してるんじゃないか
見に行く元気はないまだだりぃ

Rustの努力にはライバルながら賛辞を贈る
Rustの成功をC++に取り込むべきだと思ってるからね

**デフォルトの名無しさん** · 2023/08/01(火) 10:31:09.40

ぐぐったらこれがあったので貼る
https://docs.kernel.org/rust/quick-start.html

引き続き、精読する元気はない(ｗ

**デフォルトの名無しさん** · 2023/08/01(火) 10:39:09.49

>>80
>>69の解法2だね

>>72,73,75,76
何で解法1じゃないの?
何でvery experimentalなの?

**デフォルトの名無しさん** · 2023/08/01(火) 11:29:23.00

Rustに詳しい人しか答えられないような内容を
ここに書くべきじゃない。
Rust専門スレがあるのに、何故そこに書かないか。

**デフォルトの名無しさん** · 2023/08/01(火) 11:32:16.29

昔はコンパイラとリンカは別物でコンパイラはposix標準のライブラリファイルを出すのが仕事でその後各言語が吐き出したライブラリファイルをリンカでくっつけてた
しかし今はコンパイラがリンクまでやってるのでこの“別言語間のリンク”がどうなんとなってるけど、流石にコンパイル後リンク前のライブラリファイル形式もその形式のファイルをはくオプションも残ってるやろ

**デフォルトの名無しさん** · 2023/08/01(火) 11:34:34.48

>>82
>Rustに詳しい人しか答えられないような内容を
>ここに書くべきじゃない。
何やそれw

自分が詳しくないこと分からないことについては
ここに限らず（5chにも限らず）書くべきじゃない

**デフォルトの名無しさん** · 2023/08/01(火) 11:53:54.57

かたいこというなや
「しらんけど」って付けときゃいいんだよ
しらんけど

まあ、bfd/binutilみたいのができて久しいし、
そのへんに準拠してれば、リンクはできるよ
(最近のことは)しらんけどｗ

**デフォルトの名無しさん** · 2023/08/01(火) 12:12:45.73

calling convention は、今後もなんとか突き合わせてもらうとして。
だいぶ前に書いたのは、RustにはRustのname manglingがあって、C/C++がそれに合わせられないかってこと

それができれば、所有権情報付きの型に対応できることになるから、
C/C++も一気に所有権まわりを獲得できるってことになる

**デフォルトの名無しさん** · 2023/08/01(火) 12:53:01.64

>>84
Rust専用スレがある。
そっちの住人にこっちは隔離スレとされた。
隔離されて無いはずのスレに戻れよ。
そっちの方が多いはずなんだろ、Rust信者の脳内では。

**デフォルトの名無しさん** · 2023/08/01(火) 15:10:07.83

>>87
文章は丁寧に（自戒も込めて）

**デフォルトの名無しさん** · 2023/08/01(火) 15:34:55.86

>>88
ウザい

**デフォルトの名無しさん** · 2023/08/01(火) 15:45:28.88

戻れも何も俺はそもそもRustユーザではないので
「Rust専用スレ」なるものを開いたことはない
ここには議論をしに来たのであってウザいと言われれば
反論できないのだなぁwとしか思わん

**デフォルトの名無しさん** · 2023/08/01(火) 15:48:14.84

またーりしていけよもう

たらこは言った、面白いことをかけって

**デフォルトの名無しさん** · 2023/08/01(火) 18:54:49.18

Rust一択でしょ

どっちもやったことないけど

**デフォルトの名無しさん** · 2023/08/01(火) 19:06:00.69

質問してるヤツと答えてるヤツが同一人物って可能性もある

**デフォルトの名無しさん** · 2023/08/01(火) 20:49:40.26

さすがにその可能性を疑い出したら病気の一歩手前だから気を付けてくれ
何か引っ掛かる点があったなら別だけど

**デフォルトの名無しさん** · 2023/08/01(火) 20:51:58.06

>>93
同一人物で自作自演したとして
俺が何をどう思われたいと思ってるのかが分からんので
是非論理的に教えてくれ

**デフォルトの名無しさん** · 2023/08/02(水) 00:36:41.42

>>69
それはRustと全く関係ない問題
オブジェクトファイルはコンパイラと独立した存在
C言語だけの話でもclangとgccを当然併用できる

まず関数fooだけのfoo.cを用意
$ cat foo.c
#include <stdint.h>
int foo(int32_t a, int32_t b) {
　return a + b;
}

これをclangでコンパイル
$ clang -c foo.c

オブジェクトファイルfoo.oが出来ている
$ ls foo.o
foo.o

つづく

**デフォルトの名無しさん** · 2023/08/02(水) 00:37:45.81

次に関数mainのmain.cを用意
$ cat main.c
#include <stdio.h>
#include <stdint.h>

int32_t foo(int32_t, int32_t);

int main(void) {
　int ret = foo(10, 20);
　printf("ret = %d\n", ret);
　return 0;
}

このmain.cをgccでコンパイルして(clangで作った)foo.oをリンクして実行ファイル生成
$ gcc -o main main.c foo.o

無事に足し算が実行できました
$ ./main
ret = 30

**デフォルトの名無しさん** · 2023/08/02(水) 00:59:42.14

clangとgccで上手くいった話は
rustcとgccにしても当然上手くいく

今度はRustで関数fooだけのfoo.rsを用意 (区別できるように掛け算に変えた)
$ cat foo.rs
#[no_mangle]
pub extern "C" fn foo(a: i32, b: i32) -> i32 {
　a * b
}

念のためfoo.oを削除しておく
$ rm foo.o

そしてrustcでコンパイルしてオブジェクトファイル生成
$ rustc -O --emit obj --crate-type staticlib foo.rs

さっきと同様にオブジェクトファイルfoo.oが出来ている
$ ls foo.o
foo.o

再び全く同じくgccでmain.cをコンパイルして(rustcで作った)foo.oもリンクして実行ファイル生成
$ gcc -o main main.c foo.o

無事に掛け算が実行できました
$ ./main
ret = 200

つまりRustで書かれたコードとその生成オブジェクトファイルは
何の問題もなくgccでコンパイルしたC言語コードから呼び出せる
(もちろん逆向きもOK)

**デフォルトの名無しさん** · 2023/08/02(水) 01:09:19.89

>>96-98
それは>>69の解法1を取り得ることを意味するが
公式文書では>>80のように解法2が説明されており
解法1はvery experimentalとある
なぜだい?

**デフォルトの名無しさん** · 2023/08/02(水) 01:11:29.45

誰でも知ってることを長文で書かなくていいから>>80読んでね

**デフォルトの名無しさん** · 2023/08/02(水) 01:15:12.91

>>86
>それができれば、所有権情報付きの型に対応できることになるから、
これが気になってて
>>98みたいにno_mangleすると
所有権システムは制限されるのかな?

**デフォルトの名無しさん** · 2023/08/02(水) 01:28:10.98

>>99
その文書に根拠が書かれていないからわからない
その文書によるとclangとrustcならば上手くいくのだからRust側の問題ではなくclang側の問題でもない
仮に問題があるとすればgcc側の問題なのだろう
そしてその場合かあると仮定するとC言語のみでもgccとclangで上手くいかないケースが存在するのだろう

**デフォルトの名無しさん** · 2023/08/02(水) 01:34:00.68

very experimentalなのは単純に実績が浅いからでしょ
同じ規格に合わせて作ったつもりでも実際に組み合わせると想定外の問題が生じる場合がある
この辺は結合テストの経験がないとピンとこないかもしれない

**デフォルトの名無しさん** · 2023/08/02(水) 01:51:18.44

>>103
実績は10年以上あるでしょ
例えば/usr/lib/の下にあるライブラリファイルがgccかclangかどちらでコンパイルされたものかに関わらず
gccからもclangからもそれらライブラリを区別なく使われて問題を起こさず動いてきた
そこはELFのフォーマットが定められているからコンパイラの違いがあっても大丈夫

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

linuxのソースに含まれない外部配布のカーネルモジュールのコンパイルって
普通コンパイラを（バージョンも含めて）揃えない?
神経質過ぎるだけかな?

**デフォルトの名無しさん** · 2023/08/02(水) 03:18:19.71

結論
C++使いとRust使いは生産性が低い

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

生産性最強は…「さくっと探してくる」

なんでも自作(内製)しようとしちゃうよね、自分にもそんな時期がありました
勉強にはなるけど

**デフォルトの名無しさん** · 2023/08/02(水) 09:10:06.07

>>93-95
hissi.org を AI に掛けたらそろそろ自演検出出来る時代

**デフォルトの名無しさん** · 2023/08/02(水) 14:23:27.46

教師データが少なすぎて精度が上がらんやろ

**デフォルトの名無しさん** · 2023/08/02(水) 20:35:38.56

>>101
こういうことじゃないか
少し前にRust派が貼った https://github.com/microsoft/windows-rs は、
win32 APIをunsafeなRustで受けてるそういうreadmeになってるからそうなんだろう
unsafeなAPIにRustが接続してるんだから、たしかに道理

Rust派がいうように、どんどんRust世代(Swiftとかも含む)のAPIが増えてくると、
所有権情報がついたAPIになるわけだから、C++(とC)も当然それに合わせていく必要があるし、
それがわかってるなら、いまのうちから追随に向けたC++の発展を期待するぜ、っていうわけ

**デフォルトの名無しさん** · 2023/08/02(水) 20:46:07.42

C++なんざ何処が良いのか分からん
C#ほどセーフティーな訳でも無ければ
アセンブラみたいに痒い所に手が届く訳でもない

**デフォルトの名無しさん** · 2023/08/02(水) 21:02:46.80

普通はインラインアセンブラとか使えるぞたまに便利

**デフォルトの名無しさん** · 2023/08/02(水) 21:43:56.55

>>110
>所有権情報がついたAPIになるわけだから、C++(とC)も当然それに合わせていく必要があるし
C/C++の言語仕様・ライブラリでこれをサポートする予定があるのか

**デフォルトの名無しさん** · 2023/08/03(木) 06:38:17.02

サポートしてもらわないと困るって話
Rustがそこまで普及するんならね

**デフォルトの名無しさん** · 2023/08/03(木) 08:14:30.82

C/C++の問題点はプログラム全体がunsafeエリアな点にある
Rustのように自動的に安全が保証されるsafeエリアを作るべきだ

**デフォルトの名無しさん** · 2023/08/03(木) 13:49:40.33

unsafe { } なコード描き捲れば良いじゃん
誰も止めないし

**デフォルトの名無しさん** · 2023/08/03(木) 14:47:00.92

生のメモリはunsafeだからunsafeなエリアをゼロにするのは無理だが最小限に閉じ込めることはできる
ちなみにunsafeなエリアとは自動的に安全性が保証されず人間が安全性を保証しなければならない意味であり安全でないコードの意味ではない
C/C++は全てがunsafeなエリアとなっていることが根本的な問題であるためC/C++に導入すべきはsafeなエリアとunsafeなエリアの区別の導入

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

科学者は、新しいものより古いものを好むような気がする。
やっとFortranからC++に移行したみたいな感じじゃない。

**デフォルトの名無しさん** · 2023/08/04(金) 09:03:06.23

unsafe { C++ }
unsafe { unsafe { Fortran }}

**デフォルトの名無しさん** · 2023/08/04(金) 11:28:27.58

>>118
ある年齢以下だと科学者でもかなりpythonが主流派だよ。

**デフォルトの名無しさん** · 2023/08/04(金) 12:38:38.48

unsafeは名前が悪い。

noguardがguidelessの方が実態に合っている。

**デフォルトの名無しさん** · 2023/08/04(金) 12:40:31.64

>>121
同意。
rustも別にunsafeだから安全じゃないってわけじゃないからな。

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

>>121
>noguardがguidelessの方が実態に合っている。
wwwww
guidelesswww

**デフォルトの名無しさん** · 2023/08/04(金) 13:09:44.29

俺はコンパイラの支援なんか不要！
安全なコード書けるから！
などというバカ対策

**デフォルトの名無しさん** · 2023/08/04(金) 13:32:31.68

いくら自信があっても
いくら百戦錬磨のプロでも
思い込みや見逃しでミスが入り込む可能性がある
そしてミスがないと主張してもその客観的な根拠はなく頭の中にしかない

C/C++にも客観的に自動的に安全性が保証されるsafeエリアを導入すべきだ
そしてプログラム本体にunsafeエリアが露出せずに済むようにsafeなライブラリ関数を充実すべきだ

**デフォルトの名無しさん** · 2023/08/04(金) 14:14:29.32

急にスレのベレルが下がったな

**デフォルトの名無しさん** · 2023/08/04(金) 14:23:45.74

気のせいです

**デフォルトの名無しさん** · 2023/08/04(金) 14:45:44.75

>>125
唐突なポエム草

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

もっともマトモな層は、コード書きに行ってこんなとこ来ないからｗ

**デフォルトの名無しさん** · 2023/08/04(金) 15:21:59.11

急にスレのベレルが下がったな

**デフォルトの名無しさん** · 2023/08/04(金) 15:39:49.20

高かったことが一度でも在ったかのような言い草だな

**デフォルトの名無しさん** · 2023/08/04(金) 15:45:57.96

散髪屋に安全ガミソリを強制したり、マシン語プログラマを
蔑みそうな思想だな。

**デフォルトの名無しさん** · 2023/08/04(金) 15:49:31.23

安全ガミソリは刃に毛が挟まって取れなくなって、
再利用しにくいのに対し、直刃のかみそりは、
安全面さえ気をつければ手入れが簡単で再利用しやすい
からプロは後者を好んで使う。
それと同じ。

**デフォルトの名無しさん** · 2023/08/04(金) 15:51:38.78

直刃のかみそりを好んで使うプロたちに対して、
「お前らは客の安全性を疎かにする自信過剰で傲慢な
駄目な奴ら」
だとか言うつもりか。

**デフォルトの名無しさん** · 2023/08/04(金) 15:56:47.17

急にスレのベレルが下がったな

**デフォルトの名無しさん** · 2023/08/04(金) 15:58:20.80

>>134
消毒(sanitize)はどうしてるのかって問題はたしかにあるな
俺は気にしてないが、気にする人がいてもいい

**デフォルトの名無しさん** · 2023/08/04(金) 16:01:00.54

マシン語プログラマに対して、
「おまえらは、自身の腕を過信する安全性軽視の
　駄目プログラマだ」
なんて言う権利は他人には無いと思う。

**デフォルトの名無しさん** · 2023/08/04(金) 16:09:50.05

>>137
安全性とは何なのかも定義も理解できていないからそんな馬鹿げた書き込みばかりしてるのか

**デフォルトの名無しさん** · 2023/08/04(金) 16:17:28.67

結局、相手を馬鹿にしてRustを推すのが、Rust信者の
やり口。

**デフォルトの名無しさん** · 2023/08/04(金) 16:31:11.69

安全カミソリは安全ではないし
直刃のカミソリを使うプロでも客に切り傷つけることはよくある

**デフォルトの名無しさん** · 2023/08/04(金) 19:56:00.95

直刃のカミソリっていうか、柄もないカミソリの刃だけを使うようなもんだろ。
自分も痛い目みること含めて。

**デフォルトの名無しさん** · 2023/08/04(金) 20:09:16.36

他人が書いた部分や使ってるライブラリやその孫ライブラリまで含めて全ソースをチェックするのは非現実的だからな
もちろん自分で書いた部分やリファクタリングした部分も万が一のチェックを書き換えるたびにするのも手間暇コスト増
unsafeでもunguardでも呼び名はなんでもいいからsafe/guard部分がコンパイラによる自動チェックされるようになれば人間がチェックすべき部分は激減できる

**デフォルトの名無しさん** · 2023/08/04(金) 20:15:00.62

急にスレのベレルが下がったな

**デフォルトの名無しさん** · 2023/08/04(金) 20:26:53.92

ダングリングの検出ってGPTの登場で
言語側が備える意味は最早なくなった
そのうち外部にチェックプログラムが登場するよ
ABIが非互換になるデメリットを考えると
なおさらRustに追随する言語はないと思う
さよならRustの未来を信じた皆さん

**デフォルトの名無しさん** · 2023/08/04(金) 20:36:35.81

>>144
ダングリングなんて小さな問題だけが対象ではないことを理解していなさそうにもみえるが
これまで外部ログラムがいくら頑張っても各種問題を静的に見つけることはできていないし今後も無理だろう
AIであろうとそれは同じであり神のようなAIが登場するならその時は全ての言語のプログラマー全員廃業だ

**デフォルトの名無しさん** · 2023/08/04(金) 21:00:09.09

>>144
外部のチェックツールって今までもあったけどね。
上手いプロンプトを考えられたらいいね。

**デフォルトの名無しさん** · 2023/08/04(金) 21:36:58.62

>そのうち外部にチェックプログラムが登場するよ
今まで使ったことないのかよww

**デフォルトの名無しさん** · 2023/08/04(金) 22:00:25.44

CheckGPTでRustは終わる

**デフォルトの名無しさん** · 2023/08/05(土) 00:03:15.32

残念だけど言語サポート無しにRustと同じレベルのチェックは不可能
それがわからない時点で安全なコードを書く能力もないことが分かる

**デフォルトの名無しさん** · 2023/08/05(土) 01:06:25.49

>>149
SendやSyncのマーカートレイトなど
様々な安全性を型チェックで保証できるような枠組みがRustには揃ってるあたりのことか
C++にも導入すべきだよな
C++は色んな機能が足りなすぎる

**デフォルトの名無しさん** · 2023/08/05(土) 01:50:07.55

Rustは人の命をあずかるシステムに使えますか？

**デフォルトの名無しさん** · 2023/08/05(土) 02:47:29.11

使えます

**デフォルトの名無しさん** · 2023/08/05(土) 04:34:10.67

Rust信者の正体は、ぎゃあぎゃあ五月蝿い評論家だ。
自分が上だと思って色々言ってくる。

**デフォルトの名無しさん** · 2023/08/05(土) 04:36:47.68

実際にソフトウェアでサラリーマンとしてではなく、事業
として成功している人以外の意見はさらっと流して無視
しなければ、上手く行かない。

**デフォルトの名無しさん** · 2023/08/05(土) 07:16:06.28

>>148
これ

**デフォルトの名無しさん** · 2023/08/05(土) 07:31:06.33

>>155
Rustが様々な安全性をコンパイラで保証できる仕組みは
例えばスレッド間での移動や共有の可否などを抽象的なトレイトで表現して
各型をそれらのトレイト境界で制約して型チェックで実現したりしているようだから
C++にもそういう仕組みを導入すれば自動チェックの可能性が出てくるね