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

**デフォルトの名無しさん** · 2023/02/25(土) 09:49:46.74

C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな？

**デフォルトの名無しさん** · 2023/03/06(月) 23:56:33.22

>>169
数字でも物理でも定数は静的に定まるものだよ
でもC++はconstをimmutableの意味で間違えて名付けてしまいました
そして定数を表すためにconstを使えなくなりconstexprと名付けたという誰でも知ってる有名な話だよ

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

>>175
>でもC++はconstをimmutableの意味で間違えて名付けてしまいました
とあなたが思っているだけではないかな?
C++のconstにあなたなが「間違えて」静的に定まるものを期待しているだけでは?

**デフォルトの名無しさん** · 2023/03/07(火) 00:09:47.95

言われてみれば数字や物理で定数は静的に定まる値だな
どうせC++で静的に定まる値を示すキーワードも必要となるんだから素直にそれをconstにしておくべきだったか
設計ミスだな

**デフォルトの名無しさん** · 2023/03/07(火) 00:57:00.01

>>175 >>177の頭が設計ミス

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

>>177
>言われてみれば
www

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

immutableとconstantの違いを区別できていない人がimmutableに対してconstと命名してしまったのかな
そのためconstantに対してconstと命名できなくなってconstexprと命名したと

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

同じ言葉や字句でも言語ごとにその概念が指すものは異なる
相対主義的に考えなさい
相手の価値観を理解しなければ説得力は生まれません

**デフォルトの名無しさん** · 2023/03/07(火) 02:21:18.68

・y = ax　(a=10である)
aをimmutableと呼ぶかconstantと呼ぶか
・y=f(a)　(a=10である)
f(a)をconstantと呼ぶかconstant expressionと呼ぶか

まあ考え方次第だよな

**デフォルトの名無しさん** · 2023/03/07(火) 02:29:20.82

>>182
上はxが実行時に値がわかる変数なんでしょ？
それならconstantには成りえないんじゃない？

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

>>183
かかるaについてなんと呼ぶかって話だから別にxについて気にする必要は無いよ

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

>>182
理解できていなさ過ぎだろｗ

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

>>182
あと例を出すにしても
整数は特殊でconstexprでなくconstでも静的定数になる例外だから例として最も不適切

**デフォルトの名無しさん** · 2023/03/07(火) 09:21:06.13

自演してRustゴリ推し他言語叩きをしてるのは
複製おじさんと呼ばれてるRustスレでは有名な荒らし
しかもそいつが「RustJP公式」の中の人で間違いなさそうって話だから手に負えない

**デフォルトの名無しさん** · 2023/03/07(火) 10:27:35.30

>>187
「RustJP自称公式」なのでなんの問題もない

**デフォルトの名無しさん** · 2023/03/07(火) 11:40:31.33

>>180
それはお前用語なんじゃね?

**デフォルトの名無しさん** · 2023/03/07(火) 11:55:27.75

y = ax
y も a も x も変数としか言いようがない

**デフォルトの名無しさん** · 2023/03/07(火) 12:47:12.28

aを10としたときにコンパイル時
最適化してしまうかaという入れ物残しとくか更にはf(a)も計算して結果だけ使うか

**デフォルトの名無しさん** · 2023/03/07(火) 21:59:54.08

整数はconstやconstexprの有無に関係なくコンパイル時に最適化されるから整数を持ち出して来ても意味がない
C++ならクラスのインスタンスを生成する場合などを考えるとわかりやすい
コンパイル時点でそのインスタンスを定数化できる時にconstexprを使い静的に定数となる
そうでなく実行時にならないと値が定まらない変数となる時はconstexprを使えない
その変数がimmutableつまり生成以降は値を変更できない時はconstを使う

**182** · 2023/03/07(火) 22:28:59.56

constというものの表現を語るうえで言語依存しない形で書いただけなので
少数でも文字列でも適当に読み替えてね

**デフォルトの名無しさん** · 2023/03/08(水) 00:26:55.95

>>192
C++の命名ミスだな
定数にconstと命名すべきであり
immutableな変数にconstと命名すべきでなかった

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

壊れたテープレコーダは生まれてくるべきでなかった

**デフォルトの名無しさん** · 2023/03/08(水) 00:46:11.75

事後諸葛亮

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

同じ事しか書けない命名君はGC連呼厨なのか

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

結果的に後からみればC++の命名ミスなんだろうが歴史的経緯で仕方ないだろ
昔はimmutableとconstantの概念の区別が曖昧だった

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

どうしても`immutable'を使いたければマクロ定義すれば?
#define immutable const

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

Rustはconstをimmutableとcompile-time constantの両方の意味で使うので一貫性が無い
>>174

**デフォルトの名無しさん** · 2023/03/08(水) 07:29:50.16

>>200
Rustでconstは常に静的な定数を表す
*constはconstとは全く別のものであり予約語を最小限にするための使い回し組み合わせ

両者は種別も異なるため混乱することもない
constは定数の定義なのでこの位置に来る
let foo: i32 = 12345;
const FOO: i32 = 12345;

*constは生ポインタの型を示すのでこの位置に来る
const BAR: &i32 = &FOO;
const BAZ: *const i32 = &FOO;
このように両者は全く別物で出現位置も異なり共存もでき混乱することもない

この生ポインタはunsafe Rustでしか使わないため通常は出て来ない
そのために新たな予約語を消費するのは馬鹿げているため既存の組み合わせという合理的な選択をした

**デフォルトの名無しさん** · 2023/03/08(水) 07:30:57.28

constはCからの流れだしな。
元々Cがシステムプログラミング向けだったことを思えば、「リードオンリーセクションに置け」っていうくらいのつもりだったんだろ。
定数は#defineで指定しろって感じかな。

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

>>201
> この生ポインタはunsafe Rustでしか使わないため通常は出て来ない

safeの範囲で普通に使うけど
参照の同一性比較とか書いたことないの？

**デフォルトの名無しさん** · 2023/03/08(水) 09:00:01.62

>>203
参照の比較は生ポインタ直接比較ではなくstd::ptr::eqを使うのが行儀良いマナー
参照を渡せば*constに自動でcoerceされるためコードに*constを記述する必要はない

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

本題に戻ろう

**デフォルトの名無しさん** · 2023/03/09(木) 19:02:01.89

Rustは優秀なんだろうけど、言語仕様が難解なのと、「～の分野ならRust」と言えるものがないから広がりにくいんだろうね

**デフォルトの名無しさん** · 2023/03/11(土) 11:27:51.97

それにRustは左翼的な弱者救済的な雰囲気が漂う。
VBも同じ理由で使ってるだけで駄目プログラマとみなされていったから、
同じようにRustを使ってるだけで駄目プログラマ決定されてしまう気がする。

**デフォルトの名無しさん** · 2023/03/11(土) 11:29:57.74

Excelもそうだ。Excelを使ってるだけで弱者扱いされてしまうようになっている。
VBもそうなったから、中味はそう変わってないのに名前を変えてC#にされた。
しかし、だんだんと、C#もVBと同じように馬鹿プログラマ専用言語とみなされる
ようになってきてる。
Rustもきっとそうなるだろう。

**デフォルトの名無しさん** · 2023/03/11(土) 14:27:01.34

Rustも悪くないけど日本語のドキュメントが酷すぎるかなあ。
たとえば第七章のパッケージとグレートの話とかでも
-------
最初に学ぶモジュールシステムの要素は、パッケージとクレートです。クレートはバイナリかライブラリのどちらかです。クレートルート (crate root) とは、Rustコンパイラの開始点となり、クレートのルートモジュールを作るソースファイルのことです
--------

英文の方は版が新しいこともあってか

The first parts of the module system we’ll cover are packages and crates.

A crate is the smallest amount of code that the Rust compiler considers at a time. Even if you run rustc rather than cargo and pass a single source code file (as we did all the way back in the “Writing and Running a Rust Program” section of Chapter 1), the compiler considers that file to be a crate.
と、いう具合で以下だいぶ丁寧に解説してる。
パッケージにはa library crateとあるから一つだけなの？とChatGPTに尋ねたら複数入ることもあると断言されたけど。

**デフォルトの名無しさん** · 2023/03/11(土) 14:31:08.67

面倒ならとりあえずDeepLに掛ければ良いのにね
> モジュールシステムで最初に取り上げるのは、パッケージとクレートです。
>
> クレートは、Rustコンパイラが一度に考慮する最小のコード量です。cargoで
> はなくrustcを実行し、1つのソースコードファイルを渡したとしても（第1章
> の「Rustプログラムの作成と実行」でやったように）、コンパイラはそのファ
> イルをクレートと見なします。

**デフォルトの名無しさん** · 2023/03/11(土) 16:27:23.47

>>209
ひどすぎるのには同意するが
それはボランティアによる非公式な翻訳で
識者による監修や査読がされてないから
質が低いのは当然といえば当然

一部専門用語を除くと機械翻訳のほうが
それよりはマシな訳になることが多いので
多少英語が苦手でも公式を見たほうが断然効率がいいよ

**デフォルトの名無しさん** · 2023/03/11(土) 16:39:48.49

>>209
7章の最初のページ見ればそれぞれどういう関係なのか一目瞭然
単数形複数形の違いを丁寧に訳してなければ重要な意味が日本語訳では消えてるかもね

・Packages: A Cargo feature that lets you build, test, and share crates
・Crates: A tree of modules that produces a library or executable
・Modules and use: Let you control the organization, scope, and privacy of paths
・Paths: A way of naming an item, such as a struct, function, or module

**デフォルトの名無しさん** · 2023/03/11(土) 17:28:34.44

>>209
そのページは原文の2年半以上前の状態止まってる
日々改善されてるOSSで数年単位の遅れがあると全く役に立たないから
現状はRustの日本語ドキュメントは無いものと思っておいたほうがいい

**デフォルトの名無しさん** · 2023/03/11(土) 18:00:56.32

>>213
原文のいつの状態を反映した訳なのか全然管理できてないらしいからね
アップデートは望み薄

**デフォルトの名無しさん** · 2023/03/11(土) 19:45:03.63

規格がないので二流感が拭えない
かと言ってC++が登場したときのように
今はプログラミング言語の実装が
いくつも出てくる状況でもないのかな?

**デフォルトの名無しさん** · 2023/03/11(土) 22:12:18.37

>>215
C++での混乱と失敗を繰り返さないことが重要

**デフォルトの名無しさん** · 2023/03/11(土) 22:59:17.84

実装は複数あった方がメリットが大きいよ

**デフォルトの名無しさん** · 2023/03/11(土) 23:05:20.16

>>214
マジかよw
たかだか100個程度のファイルが管理できないってどんだけよ

**デフォルトの名無しさん** · 2023/03/11(土) 23:19:14.88

実装が複数あることはメリットもあるがデメリットも多くユーザを混乱させてきた
一方で言語仕様とその実現方法が確定して枯れた時は複数実装のメリットが上回る
Rustについては更なる理想の言語に向けて公開todoリストも多くまだ発展段階なので複数実装は向いていない
もちろん従来的な使い方ならば現状のRustで既に十分に利用できる

**デフォルトの名無しさん** · 2023/03/11(土) 23:24:45.49

>>218
ユーザーフォーラムのしかもたった二人の回答を「公式コミュニティの見解」にしてしまうオツムの人達だからさ一般常識があると思ったら大間違い

**デフォルトの名無しさん** · 2023/03/11(土) 23:30:52.30

>>219
3行目は全否定しておく

CやC++に複数の実装があった第一の要因は開発ツールが売れたという背景がある
Rustに限らず開発ツールは最早ビジネスとしては成り立たなくなってしまった

**デフォルトの名無しさん** · 2023/03/11(土) 23:34:33.13

>>220
あれ痛いよね
でもピン留めして晒し上げるのはさすがにどうかと思うわ

**デフォルトの名無しさん** · 2023/03/11(土) 23:39:25.95

Rustは公式が提供するcargoやrust-analyzerで開発環境は十分だもんな
もちろんrust-analyzerはLSPなのでVScodeなどの既存の統合開発環境で使える

**デフォルトの名無しさん** · 2023/03/11(土) 23:51:17.37

>>220
Rustユーザーの大半は英語のドキュメントを直接見てるからな
同じRustユーザーというだけであのリテラシーレベルと同類扱いされるのは誠に遺憾

**デフォルトの名無しさん** · 2023/03/12(日) 06:07:53.91

>>212
一目瞭然ってことはないよ。
わかってるやつにはわかるっていうレベル。
特にmodule and use以下で戸惑うと思うよ。

Rustはプログラミング言語としてはCとかで神経使っていたところで楽させてくれる感じだけど、新人を呼び込むにはドキュメントがまずいかなあ。

**デフォルトの名無しさん** · 2023/03/12(日) 09:19:37.91

前にもこれどこかで同じレスしたことあるけど
Javascriptってドキュメントすっごい充実してるよな
2000年以前はHTMLとJavascript一緒になった解説本の最後の方に申し訳程度に乗ってたくらいで
あとは某とほほサイト見るくらいしかなかったけど

最近ちらっとみたらすごいのな
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/find
これは適当にクリックした特に選んでない一例だけど
ちょっと過剰なくらい説明と例が乗っててスゴイと思ったわ
Rustにここまでを要求したほうがいいとも思わんけど
いつかみんなが使う言語になったときはそうなってるのかもしれん

**デフォルトの名無しさん** · 2023/03/13(月) 09:18:51.45

udemyからrust勉強すれば良いと思う

**デフォルトの名無しさん** · 2023/03/13(月) 11:30:57.14

C++は既に意味不明な域に来ていて、誰も新規に習得しようとはしないだろう

**デフォルトの名無しさん** · 2023/03/13(月) 12:04:07.60

>>226
ほんと。自分もノーマークだったけどすごいね。
Rustも「英文ドキュメント読め」みたいに突っぱねいようにしなくちゃね。

Rustのサイトで各国語にトランスレートされたもののリンク先の更新日付を眺めてると、中国語版に負けてる感じだね。

**デフォルトの名無しさん** · 2023/03/13(月) 12:11:38.79

中国なんてどうでもいい

**デフォルトの名無しさん** · 2023/03/13(月) 12:13:17.03

MDNもMDNで英語読まないとやってられない記事はちょいちょいあるけどね
CSSのpositionとか

**デフォルトの名無しさん** · 2023/03/13(月) 14:43:06.35

少なくとも手解き用として、TheBookの日本語版ではねえ。
で、メモリ安全ってことだけをひたすらリピートするだけでは、新しい人は来ないでくださいと言ってるようなもん。

まあ、その方がチンケな優越感に浸れて良いのかもしれないけど。

**デフォルトの名無しさん** · 2023/03/13(月) 15:10:59.37

>>231
Wasmのところも日本語版は古い情報のままなので肝心なAPIが足りていなくて英語版を見ないと致命的
リンク先が訳せてなくて英語版を指しているのは次善策としてまだマシ

英語版
https://developer.mozilla.org/en-US/docs/WebAssembly#api_reference
日本語版
https://developer.mozilla.org/ja/docs/WebAssembly#api_%E3%83%AA%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B9

**デフォルトの名無しさん** · 2023/03/13(月) 15:27:59.03

メモリ安全ってのは個人が始める動機としては弱い
スマートポインタで充分なんだし
チームで書くときにメモリ管理が怪しい奴が混ざり得るときに
Rustで書くことを強制されるってシチュエーションはありえるかもね

**デフォルトの名無しさん** · 2023/03/13(月) 15:42:51.26

>>234
両方書いてると差は歴然
Rustは可読性もよいし開発効率もよく
特に実行時デバッグが激減するのも大きい
やむをえない場合を除いてC++を使い続けるメリットはない

**デフォルトの名無しさん** · 2023/03/13(月) 15:54:03.52

>>235
>Rustは可読性もよいし開発効率もよく
そんなのは人によるとしか言えない
所有権に割と馴染みがあるC++プログラマはともかく
他の言語からだと文法の解離に抵抗はあるだろうね
これからプログラミングを始めようという人は
特にRustだからという抵抗はないだろう
実績が増えればRustからって人が増えるかもね

**デフォルトの名無しさん** · 2023/03/13(月) 16:03:04.23

C++はコンパイラ買う時にデバッグツールもあって、そこでメモリリーク含む大体の解析が出来ることが多いから、今の所メモリ安全で困ったことはないな。
それよりもRustはまだ新しいから、何かしら思わぬ脆弱性が潜んでいることも考えて、まだ弄りながら様子見って感じ

**デフォルトの名無しさん** · 2023/03/13(月) 18:05:23.37

C++の有料コンパイラってそんなすげえのか？

**デフォルトの名無しさん** · 2023/03/13(月) 18:37:31.12

>>236
初心者や素人はC++でもRustでもなくBASICやPythonをやっていればいい
C++もRustも書きこなせる人なら自明なようにRustがはるかに効率いい

**デフォルトの名無しさん** · 2023/03/13(月) 19:04:23.67

>>237
デバッグツールを持ち出さなくてもRustはコンパイル時点でほとんど解決する点で圧倒的に優れている
Rustはメモリ安全性だけでなくデータ競合がないことがコンパイル時点で保証される
ポインタ以外の汎用的なヌル安全とエラー処理忘れ防止もRustは標準ライブラリ全体でOptionとResult利用により保証される
C++と比べて開発効率が段違いに良くなる

**デフォルトの名無しさん** · 2023/03/13(月) 19:17:45.07

C/C++のメモリリークと隣合わせなスリルがいいんだよ
Rustなんて補助輪付きの言語はプロのプログラマッには温すぎる
コーディングに自信がない奴や素人向けだな、Rustは

**デフォルトの名無しさん** · 2023/03/13(月) 19:49:16.47

>>241
C/C++はプログラマとして成長させてくれるよね

**デフォルトの名無しさん** · 2023/03/13(月) 19:51:01.09

>>241
C++はデバッグ時間のムダ

**デフォルトの名無しさん** · 2023/03/13(月) 20:02:48.32

別にスマートポインタでええがな

**デフォルトの名無しさん** · 2023/03/13(月) 20:04:22.18

Rustは規格が出てからだな

**デフォルトの名無しさん** · 2023/03/13(月) 20:07:14.22

マ板でやれバカども

**デフォルトの名無しさん** · 2023/03/13(月) 20:22:48.71

>>239
変わった言語なので
まず初めに学んだほうが先入観がなく覚えられるよ
そのためにも日本語のドキュメントは
整備したほうが良い

**デフォルトの名無しさん** · 2023/03/13(月) 20:39:22.66

トラ枝 5月号 Rust 特集

**デフォルトの名無しさん** · 2023/03/13(月) 20:45:38.95

>>243
その通りでC++は無駄なデバッグ時間が必要となるけど
テストで発見できなかった分はデバッグもされず実行時のセキュリティ含めたバグとして残ってしまう
Rustならばコンパイル時点ですべて排除できる

>>244
勉強不足すぎだ
C++のスマポで解決できることはRustで解決できることのほんの一部にすぎない

**デフォルトの名無しさん** · 2023/03/13(月) 21:04:50.75

>>249
>勉強不足すぎだ
>C++のスマポで解決できることはRustで解決できることのほんの一部にすぎない
他は?

**デフォルトの名無しさん** · 2023/03/13(月) 21:41:54.90

>>250
そんなことも知らずにこのスレで書き込み続けているのかよ
他の人たちの書き込みを読んでないのかよ

**デフォルトの名無しさん** · 2023/03/13(月) 21:46:41.78

>>251
他は? GCしか書けない人なのかな?

**デフォルトの名無しさん** · 2023/03/13(月) 22:00:51.65

>>250
既にたくさん書いて伝えた
理解できなかったのか？

**デフォルトの名無しさん** · 2023/03/13(月) 22:16:19.15

絵に描いたような負け犬のセリフw

**デフォルトの名無しさん** · 2023/03/13(月) 22:35:49.32

>>253
本当にGCしか知らないんだな

>>249
>勉強不足すぎだ
熨斗をつけてそのままお返ししよう

**デフォルトの名無しさん** · 2023/03/13(月) 22:38:39.16

>>252
C++もRustもGC無いぞ

**デフォルトの名無しさん** · 2023/03/13(月) 22:43:20.72

>>256
んなことぁ誰でも分かってる

**デフォルトの名無しさん** · 2023/03/13(月) 23:26:56.50

>>255
GC言語も使うしC/C++/Rustも使う
速さと省メモリの点でGC言語は不利だから使い分ける

**デフォルトの名無しさん** · 2023/03/13(月) 23:40:00.84

>>249
>勉強不足すぎだ
>C++のスマポで解決できることはRustで解決できることのほんの一部にすぎない
だから他は?

**デフォルトの名無しさん** · 2023/03/13(月) 23:52:11.42

>>244
C++スマートポインタは
unique_ptrは使わずともRustでは標準で全て自動解放されるよ
shared_ptrはRustではスレッド内で使えるRcとスレッド間で使えるArcに分かれていて効率的だよ

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

>>260
別にunique_ptrやshared_ptrでええがな
難しくないよ

>shared_ptrはRustではスレッド内で使えるRcとスレッド間で使えるArcに分かれていて効率的だよ
効率的をも少し詳しく!

**デフォルトの名無しさん** · 2023/03/14(火) 00:17:28.43

C/C++でスレッドセーフな並列処理を作ろうと思ったら一苦労だけど、Rustだとそうでもないんかな。

**デフォルトの名無しさん** · 2023/03/14(火) 00:51:48.86

>>261
shared_ptrは常に排他制御されコストが高い
共有を増減すると排他制御のコストがかかる
さらに単なる受け渡しも要注意でmoveしないとそのコストが無意味に余分にかかってしまう
一方でRustは排他制御するArcとしないRcの2つが用意されていてそれらの問題なく使い分けられる

>>262
Rustはコンパイルが通った時点でデータ競合がないことを保証されるのでかなり楽

**デフォルトの名無しさん** · 2023/03/14(火) 00:58:40.53

うわっw
排他制御の意味も知らないのかよこいつw

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

shared_ptrは排他制御してリファレンスカウンタの増減を行うからスレッドセーフ
その代わり重い

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

>>263
なるほどね
std::shared_ptrには参照カウンタの排他制御をオフにする機能はなかったかな?
boost::shared_ptrだと美しくないけどBOOST_SP_DISABLE_THREADSマクロで切り替えられる
最近使ってないがLoki::SmartPtrは確かテンプレートパラメータで切り替えできたかな?

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

Rustでは共存可能
スレッド内のみの共有はRc
スレッド間での共有はArc
切り替えでなく最初から二種類が用意されるべき

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

>>267
同意
std::shared_ptrもLoki::SmartPtrみたいに
テンプレートパラメータで切り替えできれば良いのにね
ただしstd::shared_ptrを規格に入れた時点で
既にboost::shared_ptrもLoki::SmartPtrもあったことを考えると
参照カウンタが競合する機会はほとんどないという見立てで
実装を単純化したのかなと予想する
誰か経緯を知らんかな?

**デフォルトの名無しさん** · 2023/03/14(火) 02:13:23.45

苦肉の策としては
#include <memory>
#define BOOST_SP_DISABLE_THREADS
#include <boost/shared_ptr.hpp>
template <typename T> using Arc = std::shared_ptr <T>;
template <typename T> using Rc = boost::shared_ptr <T>;

**デフォルトの名無しさん** · 2023/03/14(火) 02:59:21.97

shared_ptr単独では完全なスレッドセーフではない、という問題もある。
shared_ptrで排他制御される対象はreference counterの増減だけであり、指している値の読み書きはもちろん排他制御されない。
したがってshared_ptrはスレッドセーフだから安心だと誤解していると、危険なプログラムが出来上がるリスクがある。
C++ではプログラマーがこれらの誤解や見落としやミスを全くしないことを求められ、それに依存するためプログラムの安全品質は危うい。

Rustではその点も安全で、Arc<T>はTへの書き込みが出来ないため、排他制御の問題は起きない。
書き込みしたいならば、Arc<Mutex<T>>やArc<RwLock<T>>など必要となる排他制御の種類に合わせて選び、組み合わせて利用する。
それら組み合わせにより、Tへの書き込みができるようになるが、必ずロックで排他制御されるため問題は起きない。
たとえプログラマーが見落としやミスや使い間違えをしても、Rustコンパイラがエラーを出し、該当箇所を教えてくれるため、常に安全性が保証される。

**デフォルトの名無しさん** · 2023/03/14(火) 03:15:26.07

>>270
Mutex <T>を書けば良いのではないかな？

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

>>270
>shared_ptrで排他制御される対象はreference counterの増減だけであり、指している値の読み書きはもちろん排他制御されない。
>したがってshared_ptrはスレッドセーフだから安心だと誤解していると、危険なプログラムが出来上がるリスクがある。
想定してるレベルが低すぎる
マルチスレッドで書くやつにそんなやつはいない
議論が無理やり過ぎ

**デフォルトの名無しさん** · 2023/03/14(火) 03:33:56.57

>>272
その件に限らずすべてにおいて、勘違い、見落とし、ミスなどは発生する。
複雑化したときにmutex忘れも、shared_ptr忘れも、間違えてunique_ptr使いも、その他のミスも、何でも実際に起きている。
Rustではそれらが起きてもコンパイラが通さないことで、常に安全性が保証され、無駄なデバッグを避けられる。
C++では無駄なデバッグを招くか、もしくは、そのままリリースしてセキュリティの穴が生じてしまう。
現実にC++が多数の問題を引き起こしてきた。

**デフォルトの名無しさん** · 2023/03/14(火) 12:05:32.83

暇を持て余すニートの日記