結局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/13(土) 04:06:17.18

>>351
それがrustだろ

**デフォルトの名無しさん** · 2023/05/13(土) 07:59:34.64

天下ねえ
天下って思われてると、むだに煽られるよねえ

C++サイコーｗｗｗ(大好き)とは思ってるけど

**デフォルトの名無しさん** · 2023/05/13(土) 10:20:28.21

何故プログラミング言語が変わるのか
まずハードが変わる、当然命令セットも変わる、さりとてハードが変わるたんびに新しい言語を覚える、既存のソフト移植する、など不可能なのでここで一個
ソフトサイドで新しい考え方が出てくる、既存の考え方ではバグ出やすい、効率悪い、こう考える方がいいという新しいプログラミングに関する知見が出れば言語そのものの刷新に向かう圧力が出る
ここで一個
大別すればこの2段やろな

①高級言語
━━━━━━
②繋ぎレイヤ
━━━━━━
③アセンブラ

①、③は必然的な刷新圧力に応じてどんどん変わっていく、③は必然的に新しいハードが出るたびに、①は絶対ではないけどBasic, Perl, Java, Ruby, Python などなど概ね5～10年周期で変わってきた
しかし②のレイヤはほぼ半世紀近くC,C++の独壇場, MachとかObjectice Cとかあったけど結局消えていった
さてさてどうなるのか？
Windows, Linuxでは一部Rubyに置き換える試みがなされてるけどコレは本流の大きなにがれになるのか、あるいはやはりごく一時的なものでやはりC,C++の牙城は崩れないのか

**デフォルトの名無しさん** · 2023/05/13(土) 10:27:54.96

>>365
Rustは③だよね？

**デフォルトの名無しさん** · 2023/05/13(土) 11:14:30.77

たった今あるソリューションがRustだから、切迫した更新需要にはRustが入ると思う
もうちょっとゆとりのあるものは、improved C/C++ でいいかなって感じじゃないかな
自分もその位置

**デフォルトの名無しさん** · 2023/05/13(土) 12:46:24.99

C++は倒れたままなのか？

死亡フラグ

**デフォルトの名無しさん** · 2023/05/13(土) 12:48:52.48

倒れたと言いますと?

**デフォルトの名無しさん** · 2023/05/13(土) 13:37:03.03

>>365
頭悪過ぎ

**デフォルトの名無しさん** · 2023/05/13(土) 13:52:20.03

>>362
make_unique知らないの？知ってて黙ってる？
それとも知ってたけどunique_ptrに属さないから駄目だって言いたいの？

というかその差異を認めたとしても、スコープを抜けるとき/ムーブされるときに内容の後始末とヒープの解放を行うという重要な共通点が依然としてあるし、
その点を無視してunique_ptr<T>を任意の非Copy型と対応付けようとするほうがよっぽど無理があると思うけどね

**371** · 2023/05/13(土) 13:54:01.76

あ、ムーブされるときは違うなすまん

**デフォルトの名無しさん** · 2023/05/13(土) 18:07:44.55

lifetime の &'static と
global の static で
同じ名前になってるのはセンス無いな
Rust 界にも static おじさんは息衝いている

**デフォルトの名無しさん** · 2023/05/13(土) 18:08:15.66

なんかメチャクチャ書いたな
NeXT Stepとかはあくまで周辺プログラミング環境がobjective CだっただけでOS本体はMach kernelでそれはCとかでかかれてるから②のレイヤでC,C++に変わるものは四半世紀でてきていない
果たして本当にここにRustが食い込めるのかね、あるいは置き換わるなどということが本当に起こりうるものなのか

**デフォルトの名無しさん** · 2023/05/13(土) 19:38:25.85

>>373
そこはむしろRustの美学というか方針
Rustは予約キーワード類を最小とするために巧妙な使い回しと組み合わせを意図的にしている

**デフォルトの名無しさん** · 2023/05/13(土) 21:15:21.97

>>371
make_uniqueは複合の合わせ技だから、
unique_ptrのコンストラクタを見た方がよいね
引き数はnewで確保したポインタなどだから、
unique_ptrの構築前に別途ヒープ領域を確保済
一方でBoxの構築時はまだヒープ領域を確保しておらず、Boxがヒープ領域を確保
だから両者は決定的に違うんじゃないかな

さらにunique_ptrは空っぽの状態、つまりヒープ領域を伴わない状態が許されるのに対して、
Boxは必ずヒープ領域を伴っていて、そこに値を必ず持っている、という重要な違いもあるね

スコープを抜けたときの処理や内部で持っているヒープ領域の解放については、
unique_ptrやBox以外でも行われる話だから、両者の共通点というよりもっと大きな範囲の共通点だね

**デフォルトの名無しさん** · 2023/05/13(土) 21:18:10.27

>>375
騙されないぞ

それじゃC++とおんなじじゃないかｗ

**デフォルトの名無しさん** · 2023/05/13(土) 21:55:24.10

>>373,375
staticはglobalスコープとは関係ない
lifetimeがstaticなだけなのでどっちも同じ意味

美学てｗ

**デフォルトの名無しさん** · 2023/05/13(土) 22:14:54.43

Copy非実装型とBoxとどちらがunique_ptrに近いかと言えば大多数の人はBoxだと言うだろうな

まあ言語が変われば1対1で対応しない機能があるのが普通なので
無理に対応づけようとするよりもそれぞれの違いを学んだほうがいいよ

**デフォルトの名無しさん** · 2023/05/13(土) 22:22:25.59

>>376
> さらにunique_ptrは空っぽの状態、つまりヒープ領域を伴わない状態が許されるのに対して、
> Boxは必ずヒープ領域を伴っていて、そこに値を必ず持っている、という重要な違いもあるね

だからBoxとunique_ptrは対応しないってんなら、Arcとshared_ptrを対応させるのはもっと間違ってるぞ

**デフォルトの名無しさん** · 2023/05/13(土) 22:50:11.88

Boxはボックス化つまりヒープに置くこと
C++で対応するのはnew

**デフォルトの名無しさん** · 2023/05/13(土) 22:51:59.52

BoxもZero Sized Type(ZST)だとheapを伴わないよね

**デフォルトの名無しさん** · 2023/05/14(日) 02:32:01.76

>>377
Rustは凄いと言ってる奴は、自分はRust使ってないからな

**デフォルトの名無しさん** · 2023/05/14(日) 09:24:48.35

Javaが出てきたとき
Javaすげぇぇ他の言語は駆逐される

PHPが出てきたとき
PHPすげぇぇ他の言語は駆逐される

何か出るたびそれを信仰し同じコトを繰り返すんだな

**デフォルトの名無しさん** · 2023/05/14(日) 09:25:10.34

>>383
使いどころがないからなｗ

**デフォルトの名無しさん** · 2023/05/14(日) 09:27:43.22

自分で作るじゃなく他所で作られたものを自慢をするというね
こういう言語そうだそれ以外の物でもそうだし

**デフォルトの名無しさん** · 2023/05/14(日) 09:34:52.10

>>384
結局どうなったかっていうと、PHPはサーバサイドのDSLとして落ち着いた
JavaはOracleが接収? した
立ち位置が減少したのは多分Perlだが、いまPerl使ってるって言っても殴る人はいない
(以上、すべて個人の感想)

今回は、LLVMの成熟により、様々な言語が2.0化しようとしてるみたい
わりと何ででも、安全に、高効率なプログラミングができる時代になるのかもしれない

Rustは、新しいbetter C のような気がしてきた
…けど、記述法がどうしても見慣れない(ｗ

**デフォルトの名無しさん** · 2023/05/14(日) 10:27:30.61

javaはIT企業ではある意味他言語をを駆逐したと思うわ
特殊なケースだけc++、ｖｂ使う
webのDSLでtypescript

地元（田舎）の求人見ると
java,C++が使える人かjs使える人の求人が99%だから…

**デフォルトの名無しさん** · 2023/05/14(日) 14:29:21.51

WindowsのカーネルもRustに移行するのか

**デフォルトの名無しさん** · 2023/05/14(日) 15:10:39.12

これでWindows、Linux、AndroidがRust採用かー

**デフォルトの名無しさん** · 2023/05/14(日) 19:44:19.16

rubyは使ってると殴られる言語だが
pythonはまだ大丈夫だな
phpやvbは死んでいい

**デフォルトの名無しさん** · 2023/05/14(日) 19:45:39.76

>>387
記述法が見慣れないのは
キミが関数型をやってないからじゃね

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

色んな言語やっている中で見比べて
Rustの記述法のほとんどの部分は
複数言語に見られるものかその平均に近い記述
>>387の見慣れない記述法とは何を指すのだろう

**デフォルトの名無しさん** · 2023/05/14(日) 20:36:25.87

🐟::🐟::🐟::

**デフォルトの名無しさん** · 2023/05/14(日) 20:47:29.76

::も<type>もC++と同じだから連続してもそれほど違和感ない

**デフォルトの名無しさん** · 2023/05/14(日) 20:57:09.57

goの配列の指定はいまだに慣れないと言うかなんじゃこれだけど
rustは&mutとかライフタイムの指定をもっと独自のものにして欲しかった

**デフォルトの名無しさん** · 2023/05/14(日) 20:59:37.48

C++構文定義上の最大の罪である山括弧ジェネリクスを引き継いでしまい
構文の曖昧性を無くすために苦肉の策で生まれたのがあの悲しきお魚ちゃんなのですよ

**デフォルトの名無しさん** · 2023/05/14(日) 21:00:38.00

>>392
関数型はマイナーだからな

**デフォルトの名無しさん** · 2023/05/14(日) 21:02:12.13

>>397
>C++構文定義上の最大の罪である山括弧ジェネリクスを引き継いでしまい
何が問題なのかな?

**デフォルトの名無しさん** · 2023/05/14(日) 21:06:28.92

< >は解釈の時若干邪魔なのかとは思うけど

ヒマだからANTLRで構文解析器でも作ってみようか

**デフォルトの名無しさん** · 2023/05/14(日) 21:08:03.75

ｃはtypedefとかの仕組みがクソ

**デフォルトの名無しさん** · 2023/05/14(日) 21:30:13.88

>>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;
}

**デフォルトの名無しさん** · 2023/05/14(日) 22:05:58.43

何かの言語でvector<vector<int>>の">>"の間にスペースが必要だった記憶があるけど
昔のC++だったかJavaだったか思い出せない
シフト演算子と相性悪いんだよね
どうやって解決したんだろ

**デフォルトの名無しさん** · 2023/05/14(日) 22:07:54.16

>>403
昔のC++はそうだったよ

**デフォルトの名無しさん** · 2023/05/14(日) 22:57:53.83

次スレのスレタイはC++ Considered Harmfulにしよう

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

>>402
頭が痛くなるからやめて

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

>>402をtypedefなしで書くと逝っとるよな
- Mage mage {&Hoge::hage};
+ void (Hoge::*mage) () const {&Hoge::hage};
何でこんな記法にしたんだろ?

**デフォルトの名無しさん** · 2023/05/14(日) 23:26:10.97

作った人たちも失敗したと言ってるからな

**デフォルトの名無しさん** · 2023/05/14(日) 23:29:27.12

変数宣言と構文を共有することでパーサの実装量節約に一役買っているのです

**デフォルトの名無しさん** · 2023/05/14(日) 23:34:59.36

俺は使える程には理解してるが人にはちょっと説明できん

**デフォルトの名無しさん** · 2023/05/14(日) 23:35:38.40

>>408
誰?

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

>>411
しばらく検索してみたけどソースが見当たらないので取り消します

**デフォルトの名無しさん** · 2023/05/15(月) 00:06:48.33

>>412
お時間使わせてスミマセン

**デフォルトの名無しさん** · 2023/05/15(月) 09:27:18.72

C/C++ は(関数ポインタのときを除いて)
hoge と &hoge と &&hoge と &&...&hoge は明確に区別されるけど
Rust だと区別されずにコンパイル通ってしまうケースもあるんだな
むしろ警告でも良いので出してくれればいいのに

**デフォルトの名無しさん** · 2023/05/15(月) 09:33:17.96

>>399
C++ の <Hoge> 入れ子で
<Hoge<Hoge>> とは書けなくて
<Hoge<Hoge> > と書くとちゃんと動く
だっさーと思った

**デフォルトの名無しさん** · 2023/05/15(月) 09:37:02.63

>>411
ハゲ麦紐じゃなかった？

**デフォルトの名無しさん** · 2023/05/15(月) 09:38:10.71

>>414
型で厳格に区別できるから使い間違えることや問題がおきることはなく
さらにfoo.barとfoo->barを一本化してfoo.barだけにしたRustが便利で合理的かな

**デフォルトの名無しさん** · 2023/05/15(月) 11:36:55.02

>>414
Rustでも区別されてるけど場所によってはDeref Coercionが働くから
区別されてないように見えるというだけ
https://doc.rust-lang.org/book/ch15-02-deref.html

**デフォルトの名無しさん** · 2023/05/15(月) 12:27:59.24

>>415
いつの話だよ。
C++11以降を知らんのか。

**デフォルトの名無しさん** · 2023/05/15(月) 12:36:46.16

じゃあジェネリクスの記号を何にすればよかったのかの話は無いよね。
代替案が無いなら貶さない方がいいよ

**デフォルトの名無しさん** · 2023/05/15(月) 12:58:13.92

Box[T]
Box t
't box
(box t)

**デフォルトの名無しさん** · 2023/05/15(月) 13:30:47.16

今さら代替案を出したってもう広まってるから無理だし、本気でこれを変えて「改善」になるなんて思ってる人はいないだろうが
C++の山かっこがC++11で改善されるまで長いことクソクソ言われてたのになぜRustは……ってだけのただの冗談だよ
本気にさせちゃったようですまないね

**デフォルトの名無しさん** · 2023/05/15(月) 13:45:50.28

Rustのジェネリックスの記法はこうこうこうだから美しい！マンセー！
って言わなきゃ話が続かないよ

**デフォルトの名無しさん** · 2023/05/15(月) 13:49:25.75

http://www.kmonos.net/alang/d/templates-revisited.html
クソクソ言われていた時代にRustと似た動機で作られたD言語はBox!(T)だったんだね
みんないろいろ考えるんだね～

**デフォルトの名無しさん** · 2023/05/15(月) 14:23:03.39

> C++構文定義上の最大の罪である山括弧ジェネリクス
> C++の山かっこがC++11で改善されるまで長いことクソクソ言われてた

完全にコイツはエアプ
当時そんなとこに文句言ってるやつ見たこと無い
みんな真顔で「> >」隙間開けてたわ
指がオートマチックでスペース叩いてるはず

仕事やってりゃ色々クソなことはあるが
それを言語に転嫁するようなザコはここにはいないよね？

**デフォルトの名無しさん** · 2023/05/15(月) 14:37:29.92

C++11までそんなので頑張ってたんだねw

**デフォルトの名無しさん** · 2023/05/15(月) 14:44:13.08

「もう広まってる」とは言うがRustがわざわざ山かっこ<>をジェネリクス用に選んだ経緯とかはあるのか？
本当に惰性と流れで<>にしたの？

Dみたくa!(b,c)にしなかったのはなんでだ？
やっぱりDのa!(b,c)なる記法は純粋に見映えがダサくて、C++的なa<b,c>なやつはなぜかイケてる、ていうだけのことだろ

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

()が増えるのは良くない

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

https://github.com/rust-lang/rfcs/pull/2544#issuecomment-422078938
https://github.com/rust-lang/rust/commit/014c6922e12d4faa6a2181674d12a7f487c06bb6

0.1すら出る前の超初期は角括弧だったんすねえ

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

https://soc.me/languages/stop-using-angle-brackets-for-generics.html
ここに書いてあることも一理あるけど
Goのようにsquare bracketでのインデックスアクセスを残したままFoo[T]にするのも微妙
unlimited look-aheadが必要だとしても実際にそんな長く先まで読む必要性なんてないので
読みやすさが勝るのならそれでいいと思う
ターボフィッシュはイケてないけど

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

>>425
C++がだらしないから、こんだけRust勢に煽られてる、っては思ってるけどね

あまりに煽られて、一行もRust書いてないのに、併用する心の準備ができつつある
でもぜってえC++は捨てねえ、ぜってえにだｗｗｗ > 煽り勢

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

言語そのものを作ってるような人じゃなければ
あまり特定の言語に固執しないほうがいいよ
RustだろうがC++だろうがレゾンデートルに特定の言語を組み入れてる人は成長が止まりやすく老害化しやすいので自分が損するだけだから
所詮は使い分ける道具の一つ

**デフォルトの名無しさん** · 2023/05/15(月) 18:44:18.46

プログラミング言語をただの道具と言うやつは大抵無能

**デフォルトの名無しさん** · 2023/05/15(月) 18:58:00.82

>>433
ただの道具とそうでない道具の違いは何？
定義を説明してみて

**デフォルトの名無しさん** · 2023/05/15(月) 19:22:58.71

何か作るときに道具に拘る気持ちはめっちゃわかるけどなあ

**デフォルトの名無しさん** · 2023/05/15(月) 19:25:10.97

道具によって成果物の品質が変わるのだからこだわるのは当たり前
ただの道具とか言うやつは安定してゴミを作るからそういう感覚がないのよ

**デフォルトの名無しさん** · 2023/05/15(月) 19:32:41.90

ここからは理論無用でレスできるのでスレが進むのか？

**デフォルトの名無しさん** · 2023/05/15(月) 19:32:43.22

作るものが複雑になると、普段から使ってよく理解している言語でないと
調べ物が多くなって効率が悪い。

**デフォルトの名無しさん** · 2023/05/15(月) 19:34:27.68

問題領域の濃度と文法の濃度を考えれば、全ての用途で便利に使える万能言語なんてありえない。
言語には必ず得意領域と不得意領域があるんだから、問題領域に合わせて言語を選択・作成するのが望ましい。

**デフォルトの名無しさん** · 2023/05/15(月) 19:38:48.81

If all you have is a hammer, everything looks like a nail.

>>437
宗教上の理由でﾜｯﾁｮｲスレに書けない人が荒れることを無限に書き込むから

**デフォルトの名無しさん** · 2023/05/15(月) 19:42:25.96

ちょっとしたスクリプトを書く程度で済むケースは、シェルスクリプトやスクリプト言語を使えば済むから対象外として、
がっちりプログラミングするならば、実行速度やメモリ使用量などのリソース、可読性や保守性を含めた開発効率などで、プログラミング言語を選びたい。
慣れれば大した手間増加にならないのだから、CPUメモリリソースや時間を考えると、C++とRustが選ばれるべきシーンは多そう。
C++とRustが忌避される理由は他言語より「難しい」「面倒」だけど、慣れてしまえば他の言語と大した違いはないわけだから。

**デフォルトの名無しさん** · 2023/05/15(月) 19:47:06.01

目玉焼きに醤油を掛けるのかソースを掛けるのかマヨネーズ掛けるのか塩を掛けるのか
ぐらいのレベルがこの後30レスぐらい続くのかなあ？

**デフォルトの名無しさん** · 2023/05/15(月) 20:18:45.40

塩だろ。俺は邪道のアジシオだな

どんなターゲットにも合う。最悪、スイカにすら合う。
Cもそんな感じ。

**デフォルトの名無しさん** · 2023/05/15(月) 20:36:08.15

>>433
道具を「ただの道具」にするかどうかは使い手の問題なんだよ
それがわかってない君は無能

そもそも>>432が「ただの道具」と言ってるように見えるようじゃ終わってるよ

**デフォルトの名無しさん** · 2023/05/15(月) 21:11:38.66

マンパワー依存の無能はさすがに苦笑
エンジニア向いてないよ笑

**デフォルトの名無しさん** · 2023/05/15(月) 22:00:39.87

まあC++にもunsafe{ } は来てほしいけどね
統一的な方法がなかったので、今後Rustのやりかたが他言語にも波及するっしょ

**デフォルトの名無しさん** · 2023/05/16(火) 03:39:12.30

>>446
global deleteを無くすのと、参照渡しのライフタイム保証があればいいよ。

**デフォルトの名無しさん** · 2023/05/16(火) 04:35:10.15

何か未知で不確実だとしてもただの道具ならその目的は既知だったりするでしょ
デストラクタの後で参照しないとか
デストラクタの後でデストラクタを呼ばないとか

だがメモリリークをあまり問題視しない件などは目的自体が変化してしまうから
ただの道具ではない

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

>>447
Rust勢が言っているのは、Rustで書いたものは安全といって納品できる、ということなので、
ガイドラインチェッカとかじゃなく、言語にちゃんとunsafe{ } があるというのはモダン

何をもってsafeとするかには議論があったが、Rustがデファクトスタンダードになるなら、それを取り込めばいい
ひとつの夜明けは近い

**デフォルトの名無しさん** · 2023/05/16(火) 10:02:16.98

>成長が止まりやすく老害化しやすい
道具云々は↑これが図星で悔しかったんだろ
その後のレス見れば成長止まって老害化してる人だとよくわかる

**デフォルトの名無しさん** · 2023/05/16(火) 10:57:49.38

当たり前だけど、攻撃力がレーゾンデートルになるよりは回避力か防御力のほうが
ダメージやストレスが少ない

**デフォルトの名無しさん** · 2023/05/16(火) 11:13:49.28

レーゾンデートルｗｗｗ

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

>>449
shared XOR mutableはちょっと面倒くさい。
せっかくスタックフレームベースなんだから、それ前提にもっと手軽にできないかなぁ。

**デフォルトの名無しさん** · 2023/05/16(火) 13:33:35.88

インテリだなぁwおい

**デフォルトの名無しさん** · 2023/05/16(火) 13:41:37.03

>>453
値を変更する時にそれが他から参照されてるかはRust以外でも多少は意識してるはずだし
変更可能な状態で共有することに意味があるならRefCellとかCellに入れて共有すればいい
面倒といっても安全のための規約レベルでしょ
（違反するとコンパイラに殴られるからある意味手間が省ける）

**デフォルトの名無しさん** · 2023/05/16(火) 15:40:22.92

>>453
正確にはshared NAND mutable

**デフォルトの名無しさん** · 2023/05/16(火) 18:00:25.19

所有と参照を区別しない場合は
参照が一つもない値の存在は許されない (循環参照が許されないとは言ってない) ので
むしろxorが正確である場合もあるかも

**デフォルトの名無しさん** · 2023/05/16(火) 22:00:57.33

>>457
それじゃ値について述べてるのか参照について述べてるのかそれとも型について述べてるのか曖昧すぎてルールとしては使い物にならない
主語と目的語を明確に意識してないと所有権複製の二の舞だよ

**デフォルトの名無しさん** · 2023/05/16(火) 23:06:18.96

ああ、C++では値と参照を区別するとかしないとか言うね
でも動詞を使いたくなったら「参照する」は正しいが「値する」はおかしい
だから値を所有する、値を参照するというのが良い

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

C/C++の値に所有なんてあるのか
参照なら実体側の所有が誰か問題になるかも知れんが

**デフォルトの名無しさん** · 2023/05/17(水) 11:15:53.89

>>460
無い。
特に「所有」の一般的な概念に含まれる(他から制限を受けないという意味での)排他性・専有性は無い。

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

C++の参照がダングリングを引き起こす根本的原因は、
値の所有とその生存期間を参照に対してはっきりさせていないため？