結局C++とRustってど� ..
49:デフォルトの名無しさん
23/07/31 08:31:37.72 3Z/Pn9k1.net
まあmalloc失敗でpanicにならんのならええんやない？
50:デフォルトの名無しさん
23/07/31 10:22:06.96 8wbRk2dY.net
>>49
Rust の方でも .unwrap() 禁止するか unsafe {} 必須にして欲しいわ
51:デフォルトの名無しさん
23/07/31 10:26:23.87 fc/+y7rt.net
OSではCの支持率100%になってもアセンブラを排除するのは不可能
つまり、数値を抑制するのではなく
数値が上がりすぎるとスカウターみたいに爆発する脆弱性をなくせばいい
安全をどれだけ信奉してもunsafeを排除できないのは良いことだ
52:デフォルトの名無しさん
23/07/31 11:49:57.24 ulrQSEBD.net
>>47
>C++を邪道な言語として使用を拒否してきたLinuxもRustを導入した
$ wget 'URLﾘﾝｸ(cdn.kernel.org)'
$ tar xJf linux-6.4.7.tar.xz
$ find linux-6.4.7 -name *.c -o -name *.h | xargs cat | wc -l
32115936
$ find linux-6.4.7 -name *.rs | xargs cat | wc -l
17057
たった0.05%だよ
rsソースの増加速度よりcソース増加速度の方が速いのも前回示した通り
>しかしMicrosoftはWindowsでRustを導入しGoogleはAndroidでRustを導入した
Windowsは前に出回ったスクショにファイルサイズが出てたねw
Andoroidで使われているとか言ってるRustは果たしてどのくらいなのかな?
53:デフォルトの名無しさん
23/07/31 11:54:50.00 ulrQSEBD.net
>>46
ここは北朝鮮じゃないので何を使うかは選択でき自由がある
「無批判に受け入れすぎている」は全く当たらない
54:デフォルトの名無しさん
23/07/31 12:41:48.10 lZja90Kc.net
>>49
RustはLinuxなどのおかげで改善された
メモリ確保もエラーを返せるようになった
55:デフォルトの名無しさん
23/07/31 13:01:06.05 sgBBFIN2.net
>>52
ぐぐーるもM$も基本ウソツキだシナ
56:デフォルトの名無しさん
23/07/31 13:48:39.26 fc/+y7rt.net
行数もいいけど独裁者が何人いるか数えてみろよ
たったの1人しかいないから無力の無能だと言えるなら正直者
だが掌返して1人だからといって無能とは限らないとか言い出せば嘘つきだ
57:デフォルトの名無しさん
23/07/31 13:56:25.29 SQ3dcTOC.net
>>56
意味がわからん
日本語も書けなくなったのか？
58:デフォルトの名無しさん
23/07/31 13:58:30.69 eCR2qI4e.net
>>57
多分、アメリカ人が書いている。
59:デフォルトの名無しさん
23/07/31 14:57:58.99 MuwrPG3l.net
>>52
あの頑固者のLinusが解禁したこと自体が画期的
RustがOKなら、Rust程度のOOPはOKってことで、近い言語が続々参入したりして
そうなると、simple化付きC++ってのも見えてくる
60:デフォルトの名無しさん
23/07/31 15:00:33.59 ulrQSEBD.net
>>59
Rustコンパイラは何を使うの?
61:デフォルトの名無しさん
23/07/31 15:05:23.78 OPAJDfNb.net
何かの政治的な理由でRustを仕方なく使ったんじゃね？
62:デフォルトの名無しさん
23/07/31 16:30:08.80 MuwrPG3l.net
>>60
知らんまじで 処理系に指定があるかまでは存じ上げず
63:デフォルトの名無しさん
23/07/31 18:53:04.02 ky4iWRF2.net
普通にrustc（+llvm）でいいでしょ
知らんけど
64:デフォルトの名無しさん
23/07/31 19:29:15.62 f18AP/yx.net
>>63
じゃカーネルのコンパイルは何使うの?
65:デフォルトの名無しさん
23/07/31 22:08:37.01 +bjI2PCn.net
カーネルおじさん
66:デフォルトの名無しさん
23/07/31 23:55:46.68 bJxDuGa3.net
どいつもこいつもマウントを取る相手に飢えてるんやなあって
67:デフォルトの名無しさん
23/08/01 00:02:17.45 lcAcDegU.net
パタリとレスが止まったが
>>59みたいなこと書くのなら>>60とか>>64には答えられんとなぁw
68:デフォルトの名無しさん
23/08/01 01:13:33.06 enF/Vqu1.net
カーネルは知らないがrustcでコンパイルしたものとc言語で書かれたものはリンクできて動いてるし何を問題にしているのかわからない
最近はPythonやJavaScriptのライブラリもRustで書かれることが増えている
69:デフォルトの名無しさん
23/08/01 01:42:20.33 lcAcDegU.net
>>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なのか? あるいは別の方法かな?
70:デフォルトの名無しさん
23/08/01 01:44:23.88 lcAcDegU.net
>>59みたいなこと書くのなら答えられんとなぁw
71:デフォルトの名無しさん
23/08/01 01:47:19.20 lcAcDegU.net
WindowsでRustの利用が始まっているらしいが
MSはllvm使うのかね? Visual Rustかね?
72:デフォルトの名無しさん
23/08/01 02:10:15.58 enF/Vqu1.net
>>69
何を問題にしているのかさっぱりわからん
gccもclangも同じELF形式のオブジェクトファイルを吐くだけだぞ
共有ライブラリなども当然同じものが使われている
コンパイラ毎に別々の形式を吐いて共有ライブラリなども別々に用意されていると勘違いしている？？
73:デフォルトの名無しさん
23/08/01 02:15:20.41 8wU+ches.net
rustのコードはrustc on llvmでコンパイルされる
そうするとgccが吐いたオブジェクトファイルと
rustc on llvmが吐いたオブジェクトファイルをリンクできるのか?
あほすぎわろす
74:デフォルトの名無しさん
23/08/01 02:28:22.85 lcAcDegU.net
>>72,73
じゃ1で良いのかな?
75:デフォルトの名無しさん
23/08/01 02:44:40.50 enF/Vqu1.net
そもそもRustは全く関係なくC言語だけを使う世界でも同じ話
コンパイラを変えてもリンクする既存ライブラリは同じものを指定して同じものをリンクするだろ
それを知らないとはエアプログラマーかね？
76:デフォルトの名無しさん
23/08/01 02:46:40.94 rdOaCXEZ.net
まずrustcがllvmでコード生成してることを知ってるかどうか確認する必要があるな
rustc on llvmという表現に若干の不安を感じる
もしかしたらllvmを知ってるかどうかの確認も必要かもしれない
77:デフォルトの名無しさん
23/08/01 03:08:01.35 lcAcDegU.net
>>75,76
じゃ1で良いのかな?
つまりカーネルはgccでビルドして
Rustで書かれたカーネルモジュールは（まだないけどもw）
rustcでコンパイルするのかな?
78:デフォルトの名無しさん
23/08/01 03:19:00.62 y4WjFr+T.net
coff とか omf とか elf とか面倒だよなω
D は沈没したしωωω
79:59
23/08/01 06:25:09.53 1HHpj/ls.net
夏風邪で寝込んでた 隠れ新型コロナかもしれん ちなマスクはしてる
俺はC++派だし、どうしてるんかまで知らんって
Rust部のツールチェーンのバージョンを指定してるんじゃないか
見に行く元気はない まだだりぃ
Rustの努力にはライバルながら賛辞を贈る
Rustの成功をC++に取り込むべきだと思ってるからね
80:デフォルトの名無しさん
23/08/01 10:31:09.40 1HHpj/ls.net
ぐぐったらこれがあったので貼る
URLﾘﾝｸ(docs.kernel.org)
引き続き、精読する元気はない(ｗ
81:デフォルトの名無しさん
23/08/01 10:39:09.49 lcAcDegU.net
>>80
>>69の解法2だね
>>72,73,75,76
何で解法1じゃないの?
何でvery experimentalなの?
82:デフォルトの名無しさん
23/08/01 11:29:23.00 a8DQwFPL.net
Rustに詳しい人しか答えられないような内容を
ここに書くべきじゃない。
Rust専門スレがあるのに、何故そこに書かないか。
83:デフォルトの名無しさん
23/08/01 11:32:16.29 AvEKEx5a.net
昔はコンパイラとリンカは別物でコンパイラはposix標準のライブラリファイルを出すのが仕事でその後各言語が吐き出したライブラリファイルをリンカでくっつけてた
しかし今はコンパイラがリンクまでやってるのでこの“別言語間のリンク”がどうなんとなってるけど、流石にコンパイル後リンク前のライブラリファイル形式もその形式のファイルをはくオプションも残ってるやろ
84:デフォルトの名無しさん
23/08/01 11:34:34.48 lcAcDegU.net
>>82
>Rustに詳しい人しか答えられないような内容を
>ここに書くべきじゃない。
何やそれw
自分が詳しくないこと分からないことについては
ここに限らず（5chにも限らず）書くべきじゃない
85:デフォルトの名無しさん
23/08/01 11:53:54.57 1HHpj/ls.net
かたいこというなや
「しらんけど」って付けときゃいいんだよ
しらんけど
まあ、bfd/binutilみたいのができて久しいし、
そのへんに準拠してれば、リンクはできるよ
(最近のことは)しらんけどｗ
86:デフォルトの名無しさん
23/08/01 12:12:45.73 1HHpj/ls.net
calling convention は、今後もなんとか突き合わせてもらうとして。
だいぶ前に書いたのは、RustにはRustのname manglingがあって、C/C++がそれに合わせられないかってこと
それができれば、所有権情報付きの型に対応できることになるから、
C/C++も一気に所有権まわりを獲得できるってことになる
87:デフォルトの名無しさん
23/08/01 12:53:01.64 f+qzMJki.net
>>84
Rust専用スレがある。
そっちの住人にこっちは隔離スレとされた。
隔離されて無いはずのスレに戻れよ。
そっちの方が多いはずなんだろ、Rust信者の脳内では。
88:デフォルトの名無しさん
23/08/01 15:10:07.83 lcAcDegU.net
>>87
文章は丁寧に（自戒も込めて）
89:デフォルトの名無しさん
23/08/01 15:34:55.86 vjzMKnjk.net
>>88
ウザい
90:デフォルトの名無しさん
23/08/01 15:45:28.88 lcAcDegU.net
戻れも何も俺はそもそもRustユーザではないので
「Rust専用スレ」なるものを開いたことはない
ここには議論をしに来たのであってウザいと言われれば
反論できないのだなぁwとしか思わん
91:デフォルトの名無しさん
23/08/01 15:48:14.84 1HHpj/ls.net
またーりしていけよもう
たらこは言った、面白いことをかけって
92:デフォルトの名無しさん
23/08/01 18:54:49.18 a4U8O1ra.net
Rust一択でしょ
どっちもやったことないけど
93:デフォルトの名無しさん
23/08/01 19:06:00.69 G//O9I6m.net
質問してるヤツと答えてるヤツが同一人物って可能性もある
94:デフォルトの名無しさん
23/08/01 20:49:40.26 rdOaCXEZ.net
さすがにその可能性を疑い出したら病気の一歩手前だから気を付けてくれ
何か引っ掛かる点があったなら別だけど
95:デフォルトの名無しさん
23/08/01 20:51:58.06 lcAcDegU.net
>>93
同一人物で自作自演したとして
俺が何をどう思われたいと思ってるのかが分からんので
是非論理的に教えてくれ
96:デフォルトの名無しさん
23/08/02 00:36:41.42 NJTTLLY6.net
>>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
つづく
97:デフォルトの名無しさん
23/08/02 00:37:45.81 NJTTLLY6.net
次に関数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
98:デフォルトの名無しさん
23/08/02 00:59:42.14 NJTTLLY6.net
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)
99:デフォルトの名無しさん
23/08/02 01:09:19.89 iG8SsFh7.net
>>96-98
それは>>69の解法1を取り得ることを意味するが
公式文書では>>80のように解法2が説明されており
解法1はvery experimentalとある
なぜだい?
100:デフォルトの名無しさん
23/08/02 01:11:29.45 8pIQRBW6.net
誰でも知ってることを長文で書かなくていいから>>80読んでね
101:デフォルトの名無しさん
23/08/02 01:15:12.91 iG8SsFh7.net
>>86
>それができれば、所有権情報付きの型に対応できることになるから、
これが気になってて
>>98みたいにno_mangleすると
所有権システムは制限されるのかな?
102:デフォルトの名無しさん
23/08/02 01:28:10.98 NJTTLLY6.net
>>99
その文書に根拠が書かれていないからわからない
その文書によるとclangとrustcならば上手くいくのだからRust側の問題ではなくclang側の問題でもない
仮に問題があるとすればgcc側の問題なのだろう
そしてその場合かあると仮定するとC言語のみでもgccとclangで上手くいかないケースが存在するのだろう
103:デフォルトの名無しさん
23/08/02 01:34:00.68 MBDISWVo.net
very experimentalなのは単純に実績が浅いからでしょ
同じ規格に合わせて作ったつもりでも実際に組み合わせると想定外の問題が生じる場合がある
この辺は結合テストの経験がないとピンとこないかもしれない
104:デフォルトの名無しさん
23/08/02 01:51:18.44 TcjEDVFj.net
>>103
実績は10年以上あるでしょ
例えば/usr/lib/の下にあるライブラリファイルがgccかclangかどちらでコンパイルされたものかに関わらず
gccからもclangからもそれらライブラリを区別なく使われて問題を起こさず動いてきた
そこはELFのフォーマットが定められているからコンパイラの違いがあっても大丈夫
105:デフォルトの名無しさん
23/08/02 02:02:17.30 iG8SsFh7.net
linuxのソースに含まれない外部配布のカーネルモジュールのコンパイルって
普通コンパイラを（バージョンも含めて）揃えない?
神経質過ぎるだけかな?
106:デフォルトの名無しさん
23/08/02 03:18:19.71 stxSLRlm.net
結論
C++使いとRust使いは生産性が低い
107:デフォルトの名無しさん
23/08/02 06:19:43.25 2Ms30o08.net
生産性最強は…「さくっと探してくる」
なんでも自作(内製)しようとしちゃうよね、自分にもそんな時期がありました
勉強にはなるけど
108:デフォルトの名無しさん
23/08/02 09:10:06.07 4pI1Wfnv.net
>>93-95
hissi.org を AI に掛けたらそろそろ自演検出出来る時代
109:デフォルトの名無しさん
23/08/02 14:23:27.46 iG8SsFh7.net
教師データが少なすぎて精度が上がらんやろ
110:デフォルトの名無しさん
23/08/02 20:35:38.56 HZivUK5/.net
>>101
こういうことじゃないか
少し前にRust派が貼った URLﾘﾝｸ(github.com) は、
win32 APIをunsafeなRustで受けてる そういうreadmeになってるからそうなんだろう
unsafeなAPIにRustが接続してるんだから、たしかに道理
Rust派がいうように、どんどんRust世代(Swiftとかも含む)のAPIが増えてくると、
所有権情報がついたAPIになるわけだから、C++(とC)も当然それに合わせていく必要があるし、
それがわかってるなら、いまのうちから追随に向けたC++の発展を期待するぜ、っていうわけ
111:デフォルトの名無しさん
23/08/02 20:46:07.42 ss9KhaID.net
C++なんざ何処が良いのか分からん
C#ほどセーフティーな訳でも無ければ
アセンブラみたいに痒い所に手が届く訳でもない
112:デフォルトの名無しさん
23/08/02 21:02:46.80 bcW2DJn5.net
普通はインラインアセンブラとか使えるぞ たまに便利
113:デフォルトの名無しさん
23/08/02 21:43:56.55 2DJiiIQu.net
>>110
>所有権情報がついたAPIになるわけだから、C++(とC)も当然それに合わせていく必要があるし
C/C++の言語仕様・ライブラリでこれをサポートする予定があるのか
114:デフォルトの名無しさん
23/08/03 06:38:17.02 x4MCSOl6.net
サポートしてもらわないと困るって話
Rustがそこまで普及するんならね
115:デフォルトの名無しさん
23/08/03 08:14:30.82 8npqW66R.net
C/C++の問題点はプログラム全体がunsafeエリアな点にある
Rustのように自動的に安全が保証されるsafeエリアを作るべきだ
116:デフォルトの名無しさん
23/08/03 13:49:40.33 Lr04Zjag.net
unsafe { } なコード描き捲れば良いじゃん
誰も止めないし
117:デフォルトの名無しさん
23/08/03 14:47:00.92 8npqW66R.net
生のメモリはunsafeだからunsafeなエリアをゼロにするのは無理だが最小限に閉じ込めることはできる
ちなみにunsafeなエリアとは自動的に安全性が保証されず人間が安全性を保証しなければならない意味であり安全でないコードの意味ではない
C/C++は全てがunsafeなエリアとなっていることが根本的な問題であるためC/C++に導入すべきはsafeなエリアとunsafeなエリアの区別の導入
118:デフォルトの名無しさん
23/08/04 02:45:20.65 9vVWYNaF.net
科学者は、新しいものより古いものを好むような気がする。
やっとFortranからC++に移行したみたいな感じじゃない。
119:デフォルトの名無しさん
23/08/04 09:03:06.23 XLfSEGlw.net
unsafe { C++ }
unsafe { unsafe { Fortran }}
120:デフォルトの名無しさん
23/08/04 11:28:27.58 rcIkyW/J.net
>>118
ある年齢以下だと科学者でもかなりpythonが主流派だよ。
121:デフォルトの名無しさん
23/08/04 12:38:38.48 Hxv32tG4.net
unsafeは名前が悪い。
noguardがguidelessの方が実態に合っている。
122:デフォルトの名無しさん
23/08/04 12:40:31.64 l9tpj9tS.net
>>121
同意。
rustも別にunsafeだから安全じゃないってわけじゃないからな。
123:デフォルトの名無しさん
23/08/04 13:02:53.96 2tbTIxDy.net
>>121
>noguardがguidelessの方が実態に合っている。
wwwww
guidelesswww
124:デフォルトの名無しさん
23/08/04 13:09:44.29 TzILUUtf.net
俺はコンパイラの支援なんか不要！
安全なコード書けるから！
などというバカ対策
125:デフォルトの名無しさん
23/08/04 13:32:31.68 sr1c8EdF.net
いくら自信があっても
いくら百戦錬磨のプロでも
思い込みや見逃しでミスが入り込む可能性がある
そしてミスがないと主張してもその客観的な根拠はなく頭の中にしかない
C/C++にも客観的に自動的に安全性が保証されるsafeエリアを導入すべきだ
そしてプログラム本体にunsafeエリアが露出せずに済むようにsafeなライブラリ関数を充実すべきだ
126:デフォルトの名無しさん
23/08/04 14:14:29.32 egOIBhxw.net
急にスレのベレルが下がったな
127:デフォルトの名無しさん
23/08/04 14:23:45.74 neuFS+YA.net
気のせいです
128:デフォルトの名無しさん
23/08/04 14:45:44.75 z0X1ZVr3.net
>>125
唐突なポエム草
129:デフォルトの名無しさん
23/08/04 15:02:43.37 BcxuRAkw.net
もっともマトモな層は、コード書きに行ってこんなとこ来ないからｗ
130:デフォルトの名無しさん
23/08/04 15:21:59.11 9eDSr/2C.net
急にスレのベレルが下がったな
131:デフォルトの名無しさん
23/08/04 15:39:49.20 XLfSEGlw.net
高かったことが一度でも在ったかのような言い草だな
132:デフォルトの名無しさん
23/08/04 15:45:57.96 f95F43ae.net
散髪屋に安全ガミソリを強制したり、マシン語プログラマを
蔑みそうな思想だな。
133:デフォルトの名無しさん
23/08/04 15:49:31.23 f95F43ae.net
安全ガミソリは刃に毛が挟まって取れなくなって、
再利用しにくいのに対し、直刃のかみそりは、
安全面さえ気をつければ手入れが簡単で再利用しやすい
からプロは後者を好んで使う。
それと同じ。
134:デフォルトの名無しさん
23/08/04 15:51:38.78 f95F43ae.net
直刃のかみそりを好んで使うプロたちに対して、
「お前らは客の安全性を疎かにする自信過剰で傲慢な
駄目な奴ら」
だとか言うつもりか。
135:デフォルトの名無しさん
23/08/04 15:56:47.17 i+NL2LDR.net
急にスレのベレルが下がったな
136:デフォルトの名無しさん
23/08/04 15:58:20.80 BcxuRAkw.net
>>134
消毒(sanitize)はどうしてるのかって問題はたしかにあるな
俺は気にしてないが、気にする人がいてもいい
137:デフォルトの名無しさん
23/08/04 16:01:00.54 f95F43ae.net
マシン語プログラマに対して、
「おまえらは、自身の腕を過信する安全性軽視の
駄目プログラマだ」
なんて言う権利は他人には無いと思う。
138:デフォルトの名無しさん
23/08/04 16:09:50.05 S7yEvO65.net
>>137
安全性とは何なのかも定義も理解できていないからそんな馬鹿げた書き込みばかりしてるのか
139:デフォルトの名無しさん
23/08/04 16:17:28.67 f95F43ae.net
結局、相手を馬鹿にしてRustを推すのが、Rust信者の
やり口。
140:デフォルトの名無しさん
23/08/04 16:31:11.69 EJnCR0gN.net
安全カミソリは安全ではないし
直刃のカミソリを使うプロでも客に切り傷つけることはよくある
141:デフォルトの名無しさん
23/08/04 19:56:00.95 l9tpj9tS.net
直刃のカミソリっていうか、柄もないカミソリの刃だけを使うようなもんだろ。
自分も痛い目みること含めて。
142:デフォルトの名無しさん
23/08/04 20:09:16.36 S7yEvO65.net
他人が書いた部分や使ってるライブラリやその孫ライブラリまで含めて全ソースをチェックするのは非現実的だからな
もちろん自分で書いた部分やリファクタリングした部分も万が一のチェックを書き換えるたびにするのも手間暇コスト増
unsafeでもunguardでも呼び名はなんでもいいからsafe/guard部分がコンパイラによる自動チェックされるようになれば人間がチェックすべき部分は激減できる
143:デフォルトの名無しさん
23/08/04 20:15:00.62 bJlFt79O.net
急にスレのベレルが下がったな
144:デフォルトの名無しさん
23/08/04 20:26:53.92 og8Edpiv.net
ダングリングの検出ってGPTの登場で
言語側が備える意味は最早なくなった
そのうち外部にチェックプログラムが登場するよ
ABIが非互換になるデメリットを考えると
なおさらRustに追随する言語はないと思う
さよならRustの未来を信じた皆さん
145:デフォルトの名無しさん
23/08/04 20:36:35.81 q/UYza0u.net
>>144
ダングリングなんて小さな問題だけが対象ではないことを理解していなさそうにもみえるが
これまで外部ログラムがいくら頑張っても各種問題を静的に見つけることはできていないし今後も無理だろう
AIであろうとそれは同じであり神のようなAIが登場するならその時は全ての言語のプログラマー全員廃業だ
146:デフォルトの名無しさん
23/08/04 21:00:09.09 IJ6nE+NX.net
>>144
外部のチェックツールって今までもあったけどね。
上手いプロンプトを考えられたらいいね。
147:デフォルトの名無しさん
23/08/04 21:36:58.62 K3V5Xtdy.net
>そのうち外部にチェックプログラムが登場するよ
今まで使ったことないのかよww
148:デフォルトの名無しさん
23/08/04 22:00:25.44 CoH1yBj0.net
CheckGPTでRustは終わる
149:デフォルトの名無しさん
23/08/05 00:03:15.32 8PC/4Tei.net
残念だけど言語サポート無しにRustと同じレベルのチェックは不可能
それがわからない時点で安全なコードを書く能力もないことが分かる
150:デフォルトの名無しさん
23/08/05 01:06:25.49 YeB01PWa.net
>>149
SendやSyncのマーカートレイトなど
様々な安全性を型チェックで保証できるような枠組みがRustには揃ってるあたりのことか
C++にも導入すべきだよな
C++は色んな機能が足りなすぎる
151:デフォルトの名無しさん
23/08/05 01:50:07.55 dts8KIsS.net
Rustは人の命をあずかるシステムに使えますか？
152:デフォルトの名無しさん
23/08/05 02:47:29.11 LVFgAb7y.net
使えます
153:デフォルトの名無しさん
23/08/05 04:34:10.67 KocMWFZU.net
Rust信者の正体は、ぎゃあぎゃあ五月蝿い評論家だ。
自分が上だと思って色々言ってくる。
154:デフォルトの名無しさん
23/08/05 04:36:47.68 KocMWFZU.net
実際にソフトウェアでサラリーマンとしてではなく、事業
として成功している人以外の意見はさらっと流して無視
しなければ、上手く行かない。
155:デフォルトの名無しさん
23/08/05 07:16:06.28 xdlV5LLb.net
>>148
これ
156:デフォルトの名無しさん
23/08/05 07:31:06.33 YeB01PWa.net
>>155
Rustが様々な安全性をコンパイラで保証できる仕組みは
例えばスレッド間での移動や共有の可否などを抽象的なトレイトで表現して
各型をそれらのトレイト境界で制約して型チェックで実現したりしているようだから
C++にもそういう仕組みを導入すれば自動チェックの可能性が出てくるね
157:デフォルトの名無しさん
23/08/05 08:05:44.87 xdlV5LLb.net
>>156
将来的にそういうのはエディタに組み込まれたCheckGPTがやってくれるんじゃん
158:デフォルトの名無しさん
23/08/05 08:24:07.60 YeB01PWa.net
>>157
言語仕様に組み込まれていないとそれは不可能と思われる
もしそれさえ覆すAIが出現した時にはプログラミング言語自体が全て滅びてしまう新時代となる
その新時代になるまでは言語仕様が強力なRustがAI支援で圧倒的に有利にみえる
159:デフォルトの名無しさん
23/08/05 08:38:30.69 xdlV5LLb.net
>>158
AIに最適化された言語が登場するのかも
160:デフォルトの名無しさん
23/08/05 11:23:13.95 NzC+Rt9F.net
>>158
>言語仕様に組み込まれていないとそれは不可能と思われる
そなの?
人間がソースコードを読んで発見できるバグなら
直感的にはAIにも出来るのでは?
161:デフォルトの名無しさん
23/08/05 11:43:54.44 Lx+Vx/pL.net
クソスレ上げんな低能
162:デフォルトの名無しさん
23/08/05 12:00:58.94 YeB01PWa.net
>>160
そこは単純な話でプログラミングよりも遥かに難しいため
つまりそれが可能な領域にAIが達した時にはAIが最初から全て行なうのでそもそもチェックも不要になる
163:デフォルトの名無しさん
23/08/05 12:36:48.81 G0xPWQV0.net
人間がソースコードを読んで発見できるバグなら最初からバグ入らない
164:デフォルトの名無しさん
23/08/05 12:44:17.52 NzC+Rt9F.net
人間が読んで発見できないバグをRustが発見できるかのような言い草だな
165:デフォルトの名無しさん
23/08/05 12:48:32.07 C2ROzTMY.net
たぶん、いきなり初作でバグ書いたりはしないと思うのな
あとで改造したときにエンバグする
そこでコンパイルエラーになるように言語ができてる
166:デフォルトの名無しさん
23/08/05 14:13:18.22 NzC+Rt9F.net
ChatGPT-4では検出できないが
Rustで書けば検出出来るC/C++のバグを考えようぜ
ChatGPT-4はかなり賢いので俺は既に無いと予想するよ
167:デフォルトの名無しさん
23/08/05 14:14:11.76 NzC+Rt9F.net
俺は既に無いと主張するが
反証1つで論破できる
168:デフォルトの名無しさん
23/08/05 14:42:07.80 z8pTYjl5.net
ChatGPTは、
じゃんけんの論理構造が理解できないから、じゃんけんの
プログラムのバグを発見できない。
169:デフォルトの名無しさん
23/08/05 15:00:11.14 LVFgAb7y.net
とりあえずシンプルなバグ
ChatGPT使い方分からんから検証は任せた
C++は長いこと書いてないから古い書き方があったらすまん
#include <iostream>
#include <string>
#include <vector>
using namespace std;
int main() {
auto names = vector<string>();
names.reserve(8);
string empty = "";
string *longest = ∅
while (true) {
string name;
cin >> name;
names.push_back(name);
if (names.back().length() > longest->length()) {
longest = &names.back();
}
cout << names.size() << " names, (longest: " << *longest << ")" << endl;
}
}
170:デフォルトの名無しさん
23/08/05 15:14:36.79 LVFgAb7y.net
なんか＆empty；が空集合の記号に変換されて表示されてしまった…
たしかに文字参照形式だけど5chのバグ踏んだんかな
171:デフォルトの名無しさん
23/08/05 15:21:16.34 NzC+Rt9F.net
>>169
Thanks! そのまま貼るね
I: C++プログラムのバグを教えて欲しいのですが? コードレビューをできますか?
G: もちろんです、C++のコードを見せていただければ、そのコードのバグや改善点を提案することができます。どんなコードをレビューすればよいですか？
I: >>169のコード
ただし string *longest = は string *longest = nullptr; に修正
172:デフォルトの名無しさん
23/08/05 15:22:34.42 NzC+Rt9F.net
G: コードを見た結果、最初の問題点は次の行で生じます。
if (names.back().length() > longest->length()) {
G: 最初の入力が行われる前、longest ポインタは nullptr に設定されています。
したがって、デリファレンス操作（-> を使用）は無効なメモリへのアクセスを引き起こし、
これは未定義の動作につながります。
この問題を解決するためには、longest ポインタを使用する前に、
有効な string オブジェクトを指すように設定する必要があります。
コードを次のように修正することで、
最初の入力の後に longest ポインタを設定することができます。
173:デフォルトの名無しさん
23/08/05 15:23:56.83 NzC+Rt9F.net
#include <iostream>
#include <string>
#include <vector>
using namespace std;
int main() {
vector<string> names;
names.reserve(8);
string *longest = nullptr;
while (true) {
string name;
cin >> name;
if (name == "exit") { // 終了コマンドを追加
break;
}
names.push_back(name);
// 入力後にポインタを初期化
if (longest == nullptr || names.back().length() > longest->length()) {
longest = &names.back();
}
cout << names.size() << " names, longest: " << *longest << endl;
}
return 0;
}
174:デフォルトの名無しさん
23/08/05 15:24:14.45 LVFgAb7y.net
もし空集合の記号が見えてたら＆empty；（←半角）に修正してほしい
nullptrだと最初の比較で普通に死ぬから意図したバグが出ない
175:デフォルトの名無しさん
23/08/05 15:27:55.04 NzC+Rt9F.net
文章を解釈してオーダにない修正（exitの追加）までしている
ChatGPT-4はマルチスレッドの競合状態なんかも検出するよ
デッドロックは試してないがら無理かもね
Rustはデッドロックは検出するんだっけ?
176:デフォルトの名無しさん
23/08/05 15:30:21.32 LVFgAb7y.net
173見るとnullエラーは検出するけどvectorの再配置によるダングリングは見逃す感じでいいのかな
177:デフォルトの名無しさん
23/08/05 15:33:22.24 NzC+Rt9F.net
>>174 修正してみた
-string *longest = nullptr;
+string *longest = ∅
G: あなたのコードは、ユーザーからの入力を無限に受け取り、
最長の文字列を保持しようとしていますが、問題がいくつかあります。
まず、reserve関数はメモリを確保しますが、実際の要素数を増やすわけではありません。
したがって、push_backを使用すると、reserveで予約された領域を超えてメモリが確保されます。
しかし、それはこの特定のコードには重大な問題ではないと思われます。
大きな問題は、無限ループとポインタの管理です。
1. 無限ループ：while (true)とすると、無限ループになります。
これは、ユーザーが特定のアクション（例：特定のキーワードを入力する）を行わない限り、
永遠に終了しないプログラムを作成します。
これを解決するためには、ループを抜け出すための条件（例：空の名前が入力された場合）を設定する必要があります。
2. ポインタの管理：longestへのポインタが問題です。
names.back()が返す参照は、次にpush_backが呼び出されると無効になる可能性があります。
これは、push_backが内部の動的配列をリサイズする必要がある場合、
新しいメモリ領域に要素が移動され、古い参照が無効になるからです。
以下に修正したコードを示します。
178:デフォルトの名無しさん
23/08/05 15:33:27.10 97ZAjLd0.net
俺、C++ド素人で>>169が何をしているのかさっぱり分からんから、
どこが悪いのかさっぱり分からんが
でも、ChatGPTは何をしよう(しているのか)を理解して
(質問者にvectorの再配置でポンタ無効になるからと教えて)
>>171のような修正を提示するんだな。賢すぎだろ
179:デフォルトの名無しさん
23/08/05 15:34:42.49 NzC+Rt9F.net
#include <iostream>
#include <string>
#include <vector>
using namespace std;
int main() {
vector<string> names;
string longest = "";
while (true) {
string name;
cin >> name;
if (name.empty()) {
break;
}
names.push_back(name);
if (names.back().length() > longest.length()) {
longest = names.back();
}
cout << names.size() << " names, (longest: " << longest << ")" << endl;
}
return 0;
}
このコードでは、longestがポインタではなく値として管理されているため、
namesの内容が変更されても影響を受けません。
また、名前が空の場合にループを抜ける条件を追加しました。
180:デフォルトの名無しさん
23/08/05 15:39:09.24 NzC+Rt9F.net
>>176
その通りだね
ところが>>177の修正を加えて返ってきた答えには
vectorの再配置によるダングリングを考慮してある
>>177以外の修正は俺は一切加えていない
まだ間違った答えを返すことがあるが
正解を返すポテンシャルは既にある
181:デフォルトの名無しさん
23/08/05 15:41:17.99 NzC+Rt9F.net
ところで>>175なんだけど
Rustってデッドロックって検出できるんだっけ?
182:デフォルトの名無しさん
23/08/05 15:44:11.69 97ZAjLd0.net
いま、C＋＋で生ポンタを使うこと避けるようにするんじゃないのか
183:デフォルトの名無しさん
23/08/05 15:45:41.69 LVFgAb7y.net
>>174
サンクス
さすがにこのレベルだと検出できるか
（ほかに目立つバグがあるとスルーされるのかもしれないけど）
184:デフォルトの名無しさん
23/08/05 15:58:47.07 wQaB7TT9.net
デッドロックは人間でも解決できないパターンがあるからｗ
185:デフォルトの名無しさん
23/08/05 16:03:33.32 LVFgAb7y.net
あらゆるデッドロックを検出しようとするとデッドロックするから無理って
チューリング先生が証明してたと思う
停止性とは違うのかもしれないけどどうせ帰着ルート見つけるでしょ（適当）
186:デフォルトの名無しさん
23/08/05 16:22:05.73 z8pTYjl5.net
AIに関して。たまたま上手く行ったケースだけを
書いている可能性がある。
実際にやってみると変になることもあったりする
のがよくあるパターン。
187:デフォルトの名無しさん
23/08/05 16:44:23.90 NzC+Rt9F.net
>>186
>>171は1回だよ そのあと>>170を読んだので
チャットの途中から>>177の修正を加えて回答を生成させた
これも1回限り
ChatGPT-4を普段触っていて能力を知っていれば
納得の回答レベルだと思うけど?
188:デフォルトの名無しさん
23/08/05 16:52:12.45 z8pTYjl5.net
std::vector でよくある性質だけ、ChatGPTに
ハードコーディングされてる可能性がある。
189:デフォルトの名無しさん
23/08/05 17:30:10.13 YdmkUc66.net
>>181
デッドロックは静的に(実行せずに)検出できないことが理論的にわかっている
そのためRustを含めて任意のシステムで静的にデッドロックを検出するものは存在しない
190:デフォルトの名無しさん
23/08/05 17:46:13.30 YdmkUc66.net
デッドロックはロック順序が定まるように自主的対応するとして
一方でデータ競合についてはRustがデータ競合のないことを保証してくれる
191:デフォルトの名無しさん
23/08/05 18:41:15.10 NzC+Rt9F.net
>>190
データ競合はChatGPG-4も検出してくれる
192:デフォルトの名無しさん
23/08/05 18:58:04.88 nLwYtk1m.net
実は俺は未来が見える。
Rustは普及しない。
いっちゃった。
ヤバイ。
193:デフォルトの名無しさん
23/08/05 19:24:44.46 YdmkUc66.net
>>191
ChatGPTは検出できるケースもあるだけだぞ
Rustはデータ競合を100%回避できる
そしてデータ競合は100%回避しなければならない
100%回避できる方法がある状況でそうではないChatGPTに頼るやつはバカだと断言できる
194:デフォルトの名無しさん
23/08/05 19:35:03.34 3ig1p59X.net
>>193
GPT4使ったてないやろ？
そんなもんじゃない
195:デフォルトの名無しさん
23/08/05 19:45:05.47 YdmkUc66.net
>>194
100%防がなければいけないこと(今回の例だとデータ競合)で
ChatGPTに依存するは愚の骨頂
ましてや100%防げるRustが存在する状況で
196:デフォルトの名無しさん
23/08/05 19:56:21.43 ovYwnQ8g.net
>>195
だってRust覚えるのめんどいじゃん？
197:デフォルトの名無しさん
23/08/05 21:11:57.10 xdlV5LLb.net
はいRustの負け～
198:デフォルトの名無しさん
23/08/05 21:31:44.37 Ab8yJnrX.net
>>196
Rustは必要な高機能が充実しているにま関わらず
洗練されていて覚えることが少なくて楽だ
C++はC++20まで把握してもまだRustの高機能に追いつけていない
199:デフォルトの名無しさん
23/08/05 21:39:17.35 NzC+Rt9F.net
RustやってもCを別に覚えなきゃならないじゃん?
C++覚えればCはサブセットだし楽だよ
なによりRustはやってる人が少な過ぎて人が集まらん
200:デフォルトの名無しさん
23/08/05 22:16:55.85 lVlXn5uE.net
RUSTぐらいサクッと習得出来る人じゃ無ければ集まらなくって良くない？
201:デフォルトの名無しさん
23/08/05 22:45:10.55 HgL/MIsm.net
>>198
そういうのはdyn-upcastとかspecializationとかのRFCをstabilizeしてから言ったほうがいい
202:デフォルトの名無しさん
23/08/05 23:31:44.33 Z3AMXPsc.net
Rustは速くsimd命令周りをstableにして欲しい。
203:デフォルトの名無しさん
23/08/06 00:25:51.10 yMFHtXLh.net
Rustってなんで全然普及しないの？
204:デフォルトの名無しさん
23/08/06 01:19:10.93 3wcIZOky.net
それはね
もう十分普及してるからだよ
205:デフォルトの名無しさん
23/08/06 01:22:19.33 qy7GXfpS.net
直訳すると最期って意味だから縁起が悪い
206:デフォルトの名無しさん
23/08/06 01:36:56.92 /n3JPvRf.net
信者の脳内でLinuxは大成功している事と同様の事也。
207:デフォルトの名無しさん
23/08/06 01:59:35.05 0QxiCITa.net
Linuxって史上最も普及したカーネルだと思うよ
208:デフォルトの名無しさん
23/08/06 02:18:54.27 3wcIZOky.net
それじゃ全然足りないってことでしょ
「信者が～」とか言っちゃう奴って目標高過ぎというか欲張り過ぎなんだよね
どっちが信者だよって感じ
209:デフォルトの名無しさん
23/08/06 02:36:01.14 /n3JPvRf.net
無料なので、100均やユニクロより地位は下だということなんだがな。
210:デフォルトの名無しさん
23/08/06 02:37:30.46 /n3JPvRf.net
Linuxと比べれば底辺の食べ物みたいに馬鹿にされる
サイゼリヤやマクドナルドの方が遥かに高級ということになる。
211:デフォルトの名無しさん
23/08/06 02:45:19.77 /n3JPvRf.net
そしてgccやemacsやnasmは貧者のツール。
212:デフォルトの名無しさん
23/08/06 02:45:25.28 0QxiCITa.net
まーた始まった
213:デフォルトの名無しさん
23/08/06 02:48:06.95 0QxiCITa.net
>>211
50代だと思うけど引きこもりなのかな?
力になるよ
214:デフォルトの名無しさん
23/08/06 02:51:33.28 /n3JPvRf.net
無料なんだから、貧者のツールだ。
当たり前。
215:デフォルトの名無しさん
23/08/06 02:59:11.89 /n3JPvRf.net
アメリカ製のSNSが存続できているのは、アメリカ政府の
補助金のおかげ。YouTubeは個人情報をアメリカ政府に
差し出す見返りに政府から補助金を得ている。
216:デフォルトの名無しさん
23/08/06 02:59:19.72 0QxiCITa.net
>>214
引きこもってるの?
217:デフォルトの名無しさん
23/08/06 03:01:24.81 0QxiCITa.net
>>215
周りに気兼ねなく話せる人はいるかい?
218:デフォルトの名無しさん
23/08/06 03:07:03.60 /n3JPvRf.net
どうでもいい。
219:デフォルトの名無しさん
23/08/06 03:21:25.88 FBMr5AjE.net
Rust叩きをしている人たちがちょっと頭のおかしい人たちばかりなのは偶然なのか必然なのか
220:デフォルトの名無しさん
23/08/06 03:48:28.55 /n3JPvRf.net
Rust信者は域外者に対する批判に暇が無いね。
221:デフォルトの名無しさん
23/08/06 06:57:45.77 G1mNNcoT.net
>>214
C++も無料だから、それを言ったらどっこいどっこい
222:デフォルトの名無しさん
23/08/06 07:19:58.01 V97WePr1.net
スレのレベルがまた一段と下がってるね
低学年の小学生みたいw
223:デフォルトの名無しさん
23/08/06 07:47:32.01 yMFHtXLh.net
↑これってボット？
224:デフォルトの名無しさん
23/08/06 09:15:11.08 xJ7XeiL9.net
>>170
5chのバグではない
仕様通りの動作
225:デフォルトの名無しさん
23/08/06 09:23:00.88 xJ7XeiL9.net
>>199-200
今Rustで募集すると間違いなくゲーマーが応募してくる
226:デフォルトの名無しさん
23/08/06 09:56:02.83 ctz5BWzh.net
>>221
ほとんどのプロは無料環境を使ってない。
227:デフォルトの名無しさん
23/08/06 09:58:51.57 ES7Kp55N.net
VisualStudioって有料だよね
228:デフォルトの名無しさん
23/08/06 10:15:09.14 ctz5BWzh.net
GTK, wxWidgt, Qt, CodeBlocks などを試してみたが、
どれも使う気になれなかった。Qtは有料だが。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
276日前に更新/279 KB
担当:undef