23/05/13 02:08:25.96 IwTcnmrR.net
>>361
C++のunique_ptrとRustのBoxは対応しない
Boxはヒープ確保であり例えば以下でのnew int(123)部分にあたる
std::unique_ptr<int> foo(new int(123));
そしてunique_ptr自体にヒープ確保の機能はない
363:デフォルトの名無しさん
23/05/13 04:06:17.18 rghdYpRz.net
>>351
それがrustだろ
364:デフォルトの名無しさん
23/05/13 07:59:34.64 Mq7eAK7K.net
天下ねえ
天下って思われてると、むだに煽られるよねえ
C++サイコーｗｗｗ(大好き)とは思ってるけど
365:デフォルトの名無しさん
23/05/13 10:20:28.21 rDLT/gzF.net
何故プログラミング言語が変わるのか
まずハードが変わる、当然命令セットも変わる、さりとてハードが変わるたんびに新しい言語を覚える、既存のソフト移植する、など不可能なのでここで一個
ソフトサイドで新しい考え方が出てくる、既存の考え方ではバグ出やすい、効率悪い、こう考える方がいいという新しいプログラミングに関する知見が出れば言語そのものの刷新に向かう圧力が出る
ここで一個
大別すればこの2段やろな
①高級言語
━━━
②繋ぎレイヤ
━━━
③アセンブラ
①、③は必然的な刷新圧力に応じてどんどん変わっていく、③は必然的に新しいハードが出るたびに、①は絶対ではないけどBasic, Perl, Java, Ruby, Python などなど概ね5～10年周期で変わってきた
しかし②のレイヤはほぼ半世紀近くC,C++の独壇場, MachとかObjectice Cとかあったけど結局消えていった
さてさてどうなるのか？
Windows, Linuxでは一部Rubyに置き換える試みがなされてるけどコレは本流の大きなにがれになるのか、あるいはやはりごく一時的なものでやはりC,C++の牙城は崩れないのか
366:デフォルトの名無しさん
23/05/13 10:27:54.96 R1hDb7+8.net
>>365
Rustは③だよね？
367:デフォルトの名無しさん
23/05/13 11:14:30.77 qbLWQV0Y.net
たった今あるソリューションがRustだから、切迫した更新需要にはRustが入ると思う
もうちょっとゆとりのあるものは、improved C/C++ でいいかなって感じじゃないかな
自分もその位置
368:デフォルトの名無しさん
23/05/13 12:46:24.99 TFo/sDKR.net
C++は倒れたままなのか？
死亡フラグ
369:デフォルトの名無しさん
23/05/13 12:48:52.48 OKlDpUB8.net
倒れたと言いますと?
370:デフォルトの名無しさん
23/05/13 13:37:03.03 0/cn7SoC.net
>>365
頭悪過ぎ
371:デフォルトの名無しさん
23/05/13 13:52:20.03 IGToM9iL.net
>>362
make_unique知らないの？ 知ってて黙ってる？
それとも知ってたけどunique_ptrに属さないから駄目だって言いたいの？
というかその差異を認めたとしても、スコープを抜けるとき/ムーブされるときに内容の後始末とヒープの解放を行うという重要な共通点が依然としてあるし、
その点を無視してunique_ptr<T>を任意の非Copy型と対応付けようとするほうがよっぽど無理があると思うけどね
372:371
23/05/13 13:54:01.76 IGToM9iL.net
あ、ムーブされるときは違うなすまん
373:デフォルトの名無しさん
23/05/13 18:07:44.55 1P8OgH65.net
lifetime の &'static と
global の static で
同じ名前になってるのはセンス無いな
Rust 界にも static おじさんは息衝いている
374:デフォルトの名無しさん
23/05/13 18:08:15.66 Zeyov0xO.net
なんかメチャクチャ書いたな
NeXT Stepとかはあくまで周辺プログラミング環境がobjective CだっただけでOS本体はMach kernelでそれはCとかでかかれてるから②のレイヤでC,C++に変わるものは四半世紀でてきていない
果たして本当にここにRustが食い込めるのかね、あるいは置き換わるなどということが本当に起こりうるものなのか
375:デフォルトの名無しさん
23/05/13 19:38:25.85 rkpDrS5+.net
>>373
そこはむしろRustの美学というか方針
Rustは予約キーワード類を最小とするために巧妙な使い回しと組み合わせを意図的にしている
376:デフォルトの名無しさん
23/05/13 21:15:21.97 C/HTc2pJ.net
>>371
make_uniqueは複合の合わせ技だから、
unique_ptrのコンストラクタを見た方がよいね
引き数はnewで確保したポインタなどだから、
unique_ptrの構築前に別途ヒープ領域を確保済
一方でBoxの構築時はまだヒープ領域を確保しておらず、Boxがヒープ領域を確保
だから両者は決定的に違うんじゃないかな
さらにunique_ptrは空っぽの状態、つまりヒープ領域を伴わない状態が許されるのに対して、
Boxは必ずヒープ領域を伴っていて、そこに値を必ず持っている、という重要な違いもあるね
スコープを抜けたときの処理や内部で持っているヒープ領域の解放については、
unique_ptrやBox以外でも行われる話だから、両者の共通点というよりもっと大きな範囲の共通点だね
377:デフォルトの名無しさん
23/05/13 21:18:10.27 qbLWQV0Y.net
>>375
騙されないぞ
それじゃC++とおんなじじゃないかｗ
378:デフォルトの名無しさん
23/05/13 21:55:24.10 ps1U4+yC.net
>>373,375
staticはglobalスコープとは関係ない
lifetimeがstaticなだけなのでどっちも同じ意味
美学てｗ
379:デフォルトの名無しさん
23/05/13 22:14:54.43 ps1U4+yC.net
Copy非実装型とBoxとどちらがunique_ptrに近いかと言えば大多数の人はBoxだと言うだろうな
まあ言語が変われば1対1で対応しない機能があるのが普通なので
無理に対応づけようとするよりもそれぞれの違いを学んだほうがいいよ
380:デフォルトの名無しさん
23/05/13 22:22:25.59 IGToM9iL.net
>>376
> さらにunique_ptrは空っぽの状態、つまりヒープ領域を伴わない状態が許されるのに対して、
> Boxは必ずヒープ領域を伴っていて、そこに値を必ず持っている、という重要な違いもあるね
だからBoxとunique_ptrは対応しないってんなら、Arcとshared_ptrを対応させるのはもっと間違ってるぞ
381:デフォルトの名無しさん
23/05/13 22:50:11.88 awcNL8zc.net
Boxはボックス化つまりヒープに置くこと
C++で対応するのはnew
382:デフォルトの名無しさん
23/05/13 22:51:59.52 ps1U4+yC.net
BoxもZero Sized Type(ZST)だとheapを伴わないよね
383:デフォルトの名無しさん
23/05/14 02:32:01.76 WzlwealS.net
>>377
Rustは凄いと言ってる奴は、自分はRust使ってないからな
384:デフォルトの名無しさん
23/05/14 09:24:48.35 20ql+77K.net
Javaが出てきたとき
Javaすげぇぇ他の言語は駆逐される
PHPが出てきたとき
PHPすげぇぇ他の言語は駆逐される
何か出るたびそれを信仰し同じコトを繰り返すんだな
385:デフォルトの名無しさん
23/05/14 09:25:10.34 hi4Bq2pn.net
>>383
使いどころがないからなｗ
386:デフォルトの名無しさん
23/05/14 09:27:43.22 20ql+77K.net
自分で作るじゃなく他所で作られたものを自慢をするというね
こういう言語そうだそれ以外の物でもそうだし
387:デフォルトの名無しさん
23/05/14 09:34:52.10 1jFVCpuN.net
>>384
結局どうなったかっていうと、PHPはサーバサイドのDSLとして落ち着いた
JavaはOracleが接収? した
立ち位置が減少したのは多分Perlだが、いまPerl使ってるって言っても殴る人はいない
(以上、すべて個人の感想)
今回は、LLVMの成熟により、様々な言語が2.0化しようとしてるみたい
わりと何ででも、安全に、高効率なプログラミングができる時代になるのかもしれない
Rustは、新しいbetter C のような気がしてきた
…けど、記述法がどうしても見慣れない(ｗ
388:デフォルトの名無しさん
23/05/14 10:27:30.61 pb1Dbmn7.net
javaはIT企業ではある意味他言語をを駆逐したと思うわ
特殊なケースだけc++、ｖｂ使う
webのDSLでtypescript
地元（田舎）の求人見ると
java,C++が使える人かjs使える人の求人が99%だから…
389:デフォルトの名無しさん
23/05/14 14:29:21.51 ePHWuoFt.net
WindowsのカーネルもRustに移行するのか
390:デフォルトの名無しさん
23/05/14 15:10:39.12 +xFqdUJk.net
これでWindows、Linux、AndroidがRust採用かー
391:デフォルトの名無しさん
23/05/14 19:44:19.16 JeiAQ+ra.net
rubyは使ってると殴られる言語だが
pythonはまだ大丈夫だな
phpやvbは死んでいい
392:デフォルトの名無しさん
23/05/14 19:45:39.76 JeiAQ+ra.net
>>387
記述法が見慣れないのは
キミが関数型をやってないからじゃね
393:デフォルトの名無しさん
23/05/14 20:14:19.79 pJuPP/LG.net
色んな言語やっている中で見比べて
Rustの記述法のほとんどの部分は
複数言語に見られるものかその平均に近い記述
>>387の見慣れない記述法とは何を指すのだろう
394:デフォルトの名無しさん
23/05/14 20:36:25.87 QmAlZPFj.net
🐟::🐟::🐟::
395:デフォルトの名無しさん
23/05/14 20:47:29.76 aUfiFIOV.net
::も<type>もC++と同じだから連続してもそれほど違和感ない
396:デフォルトの名無しさん
23/05/14 20:57:09.57 pb1Dbmn7.net
goの配列の指定はいまだに慣れないと言うかなんじゃこれだけど
rustは&mutとかライフタイムの指定をもっと独自のものにして欲しかった
397:デフォルトの名無しさん
23/05/14 20:59:37.48 oUsSKvxr.net
C++構文定義上の最大の罪である山括弧ジェネリクスを引き継いでしまい
構文の曖昧性を無くすために苦肉の策で生まれたのがあの悲しきお魚ちゃんなのですよ
398:デフォルトの名無しさん
23/05/14 21:00:38.00 QE+keqW6.net
>>392
関数型はマイナーだからな
399:デフォルトの名無しさん
23/05/14 21:02:12.13 QE+keqW6.net
>>397
>C++構文定義上の最大の罪である山括弧ジェネリクスを引き継いでしまい
何が問題なのかな?
400:デフォルトの名無しさん
23/05/14 21:06:28.92 pb1Dbmn7.net
< >は解釈の時若干邪魔なのかとは思うけど
ヒマだからANTLRで構文解析器でも作ってみようか
401:デフォルトの名無しさん
23/05/14 21:08:03.75 pb1Dbmn7.net
ｃはtypedefとかの仕組みがクソ
402:デフォルトの名無しさん
23/05/14 21:30:13.88 QE+keqW6.net
>>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;
}
403:デフォルトの名無しさん
23/05/14 22:05:58.43 RldwXebz.net
何かの言語でvector<vector<int>>の">>"の間にスペースが必要だった記憶があるけど
昔のC++だったかJavaだったか思い出せない
シフト演算子と相性悪いんだよね
どうやって解決したんだろ
404:デフォルトの名無しさん
23/05/14 22:07:54.16 QE+keqW6.net
>>403
昔のC++はそうだったよ
405:デフォルトの名無しさん
23/05/14 22:57:53.83 bfYFgiq9.net
次スレのスレタイはC++ Considered Harmfulにしよう
406:デフォルトの名無しさん
23/05/14 23:23:04.77 pb1Dbmn7.net
>>402
頭が痛くなるからやめて
407:デフォルトの名無しさん
23/05/14 23:23:32.31 QE+keqW6.net
>>402をtypedefなしで書くと逝っとるよな
- Mage mage {&Hoge::hage};
+ void (Hoge::*mage) () const {&Hoge::hage};
何でこんな記法にしたんだろ?
408:デフォルトの名無しさん
23/05/14 23:26:10.97 pb1Dbmn7.net
作った人たちも失敗したと言ってるからな
409:デフォルトの名無しさん
23/05/14 23:29:27.12 bfYFgiq9.net
変数宣言と構文を共有することでパーサの実装量節約に一役買っているのです
410:デフォルトの名無しさん
23/05/14 23:34:59.36 QE+keqW6.net
俺は使える程には理解してるが人にはちょっと説明できん
411:デフォルトの名無しさん
23/05/14 23:35:38.40 QE+keqW6.net
>>408
誰?
412:デフォルトの名無しさん
23/05/15 00:00:45.30 wsaXJZjZ.net
>>411
しばらく検索してみたけどソースが見当たらないので取り消します
413:デフォルトの名無しさん
23/05/15 00:06:48.33 I+wFjT19.net
>>412
お時間使わせてスミマセン
414:デフォルトの名無しさん
23/05/15 09:27:18.72 wFuQ/qib.net
C/C++ は(関数ポインタのときを除いて)
hoge と &hoge と &&hoge と &&...&hoge は明確に区別されるけど
Rust だと区別されずにコンパイル通ってしまうケースもあるんだな
むしろ警告でも良いので出してくれればいいのに
415:デフォルトの名無しさん
23/05/15 09:33:17.96 wFuQ/qib.net
>>399
C++ の <Hoge> 入れ子で
<Hoge<Hoge>> とは書けなくて
<Hoge<Hoge> > と書くとちゃんと動く
だっさーと思った
416:デフォルトの名無しさん
23/05/15 09:37:02.63 wFuQ/qib.net
>>411
ハゲ麦紐じゃなかった？
417:デフォルトの名無しさん
23/05/15 09:38:10.71 DhZrO8d7.net
>>414
型で厳格に区別できるから使い間違えることや問題がおきることはなく
さらにfoo.barとfoo->barを一本化してfoo.barだけにしたRustが便利で合理的かな
418:デフォルトの名無しさん
23/05/15 11:36:55.02 ujHFmMNa.net
>>414
Rustでも区別されてるけど場所によってはDeref Coercionが働くから
区別されてないように見えるというだけ
URLﾘﾝｸ(doc.rust-lang.org)
419:デフォルトの名無しさん
23/05/15 12:27:59.24 GXc9JAaS.net
>>415
いつの話だよ。
C++11以降を知らんのか。
420:デフォルトの名無しさん
23/05/15 12:36:46.16 HovYgrQ4.net
じゃあジェネリクスの記号を何にすればよかったのかの話は無いよね。
代替案が無いなら貶さない方がいいよ
421:デフォルトの名無しさん
23/05/15 12:58:13.92 s5edYhaR.net
Box[T]
Box t
't box
(box t)
422:デフォルトの名無しさん
23/05/15 13:30:47.16 s5edYhaR.net
今さら代替案を出したってもう広まってるから無理だし、本気でこれを変えて「改善」になるなんて思ってる人はいないだろうが
C++の山かっこがC++11で改善されるまで長いことクソクソ言われてたのになぜRustは……ってだけのただの冗談だよ
本気にさせちゃったようですまないね
423:デフォルトの名無しさん
23/05/15 13:45:50.28 I+wFjT19.net
Rustのジェネリックスの記法はこうこうこうだから美しい！マンセー！
って言わなきゃ話が続かないよ
424:デフォルトの名無しさん
23/05/15 13:49:25.75 s5edYhaR.net
URLﾘﾝｸ(www.kmonos.net)
クソクソ言われていた時代にRustと似た動機で作られたD言語はBox!(T)だったんだね
みんないろいろ考えるんだね～
425:デフォルトの名無しさん
23/05/15 14:23:03.39 1m/NLizK.net
> C++構文定義上の最大の罪である山括弧ジェネリクス
> C++の山かっこがC++11で改善されるまで長いことクソクソ言われてた
完全にコイツはエアプ
当時そんなとこに文句言ってるやつ見たこと無い
みんな真顔で「> >」隙間開けてたわ
指がオートマチックでスペース叩いてるはず
仕事やってりゃ色々クソなことはあるが
それを言語に転嫁するようなザコはここにはいないよね？
426:デフォルトの名無しさん
23/05/15 14:37:29.92 8jCFowEK.net
C++11までそんなので頑張ってたんだねw
427:デフォルトの名無しさん
23/05/15 14:44:13.08 HovYgrQ4.net
「もう広まってる」とは言うがRustがわざわざ山かっこ<>をジェネリクス用に選んだ経緯とかはあるのか？
本当に惰性と流れで<>にしたの？
Dみたくa!(b,c)にしなかったのはなんでだ？
やっぱりDのa!(b,c)なる記法は純粋に見映えがダサくて、C++的なa<b,c>なやつはなぜかイケてる、ていうだけのことだろ
428:デフォルトの名無しさん
23/05/15 15:00:31.60 5sS8eRrw.net
()が増えるのは良くない
429:デフォルトの名無しさん
23/05/15 15:09:20.65 s5edYhaR.net
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(github.com)
0.1すら出る前の超初期は角括弧だったんすねえ
430:デフォルトの名無しさん
23/05/15 15:11:35.81 ujHFmMNa.net
URLﾘﾝｸ(soc.me)
ここに書いてあることも一理あるけど
Goのようにsquare bracketでのインデックスアクセスを残したままFoo[T]にするのも微妙
unlimited look-aheadが必要だとしても実際にそんな長く先まで読む必要性なんてないので
読みやすさが勝るのならそれでいいと思う
ターボフィッシュはイケてないけど
431:デフォルトの名無しさん
23/05/15 15:21:53.58 gbsleJgn.net
>>425
C++がだらしないから、こんだけRust勢に煽られてる、っては思ってるけどね
あまりに煽られて、一行もRust書いてないのに、併用する心の準備ができつつある
でもぜってえC++は捨てねえ、ぜってえにだｗｗｗ > 煽り勢
432:デフォルトの名無しさん
23/05/15 15:44:34.72 YPCsGXtE.net
言語そのものを作ってるような人じゃなければ
あまり特定の言語に固執しないほうがいいよ
RustだろうがC++だろうがレゾンデートルに特定の言語を組み入れてる人は成長が止まりやすく老害化しやすいので自分が損するだけだから
所詮は使い分ける道具の一つ
433:デフォルトの名無しさん
23/05/15 18:44:18.46 FgOHTeF5.net
プログラミング言語をただの道具と言うやつは大抵無能
434:デフォルトの名無しさん
23/05/15 18:58:00.82 VaeCf5Jf.net
>>433
ただの道具とそうでない道具の違いは何？
定義を説明してみて
435:デフォルトの名無しさん
23/05/15 19:22:58.71 W6wSx7Ot.net
何か作るときに道具に拘る気持ちはめっちゃわかるけどなあ
436:デフォルトの名無しさん
23/05/15 19:25:10.97 FgOHTeF5.net
道具によって成果物の品質が変わるのだからこだわるのは当たり前
ただの道具とか言うやつは安定してゴミを作るからそういう感覚がないのよ
437:デフォルトの名無しさん
23/05/15 19:32:41.90 wsaXJZjZ.net
ここからは理論無用でレスできるのでスレが進むのか？
438:デフォルトの名無しさん
23/05/15 19:32:43.22 Zmr9JaW+.net
作るものが複雑になると、普段から使ってよく理解している言語でないと
調べ物が多くなって効率が悪い。
439:デフォルトの名無しさん
23/05/15 19:34:27.68 fkhy8mxo.net
問題領域の濃度と文法の濃度を考えれば、全ての用途で便利に使える万能言語なんてありえない。
言語には必ず得意領域と不得意領域があるんだから、問題領域に合わせて言語を選択・作成するのが望ましい。
440:デフォルトの名無しさん
23/05/15 19:38:48.81 s5edYhaR.net
If all you have is a hammer, everything looks like a nail.
>>437
宗教上の理由でﾜｯﾁｮｲスレに書けない人が荒れることを無限に書き込むから
441:デフォルトの名無しさん
23/05/15 19:42:25.96 LmW7vJqn.net
ちょっとしたスクリプトを書く程度で済むケースは、シェルスクリプトやスクリプト言語を使えば済むから対象外として、
がっちりプログラミングするならば、実行速度やメモリ使用量などのリソース、可読性や保守性を含めた開発効率などで、プログラミング言語を選びたい。
慣れれば大した手間増加にならないのだから、CPUメモリリソースや時間を考えると、C++とRustが選ばれるべきシーンは多そう。
C++とRustが忌避される理由は他言語より「難しい」「面倒」だけど、慣れてしまえば他の言語と大した違いはないわけだから。
442:デフォルトの名無しさん
23/05/15 19:47:06.01 wsaXJZjZ.net
目玉焼きに醤油を掛けるのかソースを掛けるのかマヨネーズ掛けるのか塩を掛けるのか
ぐらいのレベルがこの後30レスぐらい続くのかなあ？
443:デフォルトの名無しさん
23/05/15 20:18:45.40 Kl4uDN3z.net
塩だろ。俺は邪道のアジシオだな
どんなターゲットにも合う。最悪、スイカにすら合う。
Cもそんな感じ。
444:デフォルトの名無しさん
23/05/15 20:36:08.15 sS887eTb.net
>>433
道具を「ただの道具」にするかどうかは使い手の問題なんだよ
それがわかってない君は無能
そもそも>>432が「ただの道具」と言ってるように見えるようじゃ終わってるよ
445:デフォルトの名無しさん
23/05/15 21:11:38.66 FgOHTeF5.net
マンパワー依存の無能はさすがに苦笑
エンジニア向いてないよ笑
446:デフォルトの名無しさん
23/05/15 22:00:39.87 Kl4uDN3z.net
まあC++にもunsafe{ } は来てほしいけどね
統一的な方法がなかったので、今後Rustのやりかたが他言語にも波及するっしょ
447:デフォルトの名無しさん
23/05/16 03:39:12.30 mxMgusoo.net
>>446
global deleteを無くすのと、参照渡しのライフタイム保証があればいいよ。
448:デフォルトの名無しさん
23/05/16 04:35:10.15 4S8kS8o+.net
何か未知で不確実だとしてもただの道具ならその目的は既知だったりするでしょ
デストラクタの後で参照しないとか
デストラクタの後でデストラクタを呼ばないとか
だがメモリリークをあまり問題視しない件などは目的自体が変化してしまうから
ただの道具ではない
449:デフォルトの名無しさん
23/05/16 05:49:36.67 LhFniP55.net
>>447
Rust勢が言っているのは、Rustで書いたものは安全といって納品できる、ということなので、
ガイドライン チェッカとかじゃなく、言語にちゃんとunsafe{ } があるというのはモダン
何をもってsafeとするかには議論があったが、Rustがデファクトスタンダードになるなら、それを取り込めばいい
ひとつの夜明けは近い
450:デフォルトの名無しさん
23/05/16 10:02:16.98 dncY24o+.net
>成長が止まりやすく老害化しやすい
道具云々は↑これが図星で悔しかったんだろ
その後のレス見れば成長止まって老害化してる人だとよくわかる
451:デフォルトの名無しさん
23/05/16 10:57:49.38 4S8kS8o+.net
当たり前だけど、攻撃力がレーゾンデートルになるよりは回避力か防御力のほうが
ダメージやストレスが少ない
452:デフォルトの名無しさん
23/05/16 11:13:49.28 afLAkRaY.net
レーゾンデートルｗｗｗ
453:デフォルトの名無しさん
23/05/16 12:35:37.97 ALDBkD8o.net
>>449
shared XOR mutableはちょっと面倒くさい。
せっかくスタックフレームベースなんだから、それ前提にもっと手軽にできないかなぁ。
454:デフォルトの名無しさん
23/05/16 13:33:35.88 d+qszQ7T.net
インテリだなぁwおい
455:デフォルトの名無しさん
23/05/16 13:41:37.03 spgQVWRA.net
>>453
値を変更する時にそれが他から参照されてるかはRust以外でも多少は意識してるはずだし
変更可能な状態で共有することに意味があるならRefCellとかCellに入れて共有すればいい
面倒といっても安全のための規約レベルでしょ
（違反するとコンパイラに殴られるからある意味手間が省ける）
456:デフォルトの名無しさん
23/05/16 15:40:22.92 HCiu7CXC.net
>>453
正確にはshared NAND mutable
457:デフォルトの名無しさん
23/05/16 18:00:25.19 4S8kS8o+.net
所有と参照を区別しない場合は
参照が一つもない値の存在は許されない (循環参照が許されないとは言ってない) ので
むしろxorが正確である場合もあるかも
458:デフォルトの名無しさん
23/05/16 22:00:57.33 LSAD/UZx.net
>>457
それじゃ値について述べてるのか参照について述べてるのかそれとも型について述べてるのか曖昧すぎてルールとしては使い物にならない
主語と目的語を明確に意識してないと所有権複製の二の舞だよ
459:デフォルトの名無しさん
23/05/16 23:06:18.96 4S8kS8o+.net
ああ、C++では値と参照を区別するとかしないとか言うね
でも動詞を使いたくなったら「参照する」は正しいが「値する」はおかしい
だから値を所有する、値を参照するというのが良い
460:デフォルトの名無しさん
23/05/17 06:30:13.75 u+07gdJ+.net
C/C++の値に所有なんてあるのか
参照なら実体側の所有が誰か問題になるかも知れんが
461:デフォルトの名無しさん
23/05/17 11:15:53.89 qIPYqCzM.net
>>460
無い。
特に「所有」の一般的な概念に含まれる(他から制限を受けないという意味での)排他性・専有性は無い。
462:デフォルトの名無しさん
23/05/17 12:05:12.66 jyReDlhf.net
C++の参照がダングリングを引き起こす根本的原因は、
値の所有とその生存期間を参照に対してはっきりさせていないため？
463:デフォルトの名無しさん
23/05/17 12:13:29.10 BpkuThno.net
use Hoge; と
extern crate Hoge; の違いが判ったわ
新しいとか古いとか言ってる人が以前居たけど嘘だったω
464:デフォルトの名無しさん
23/05/17 12:13:39.98 F24a8wLt.net
待て待て
そもそもC++でダングリングを起こしたことがない
Rustは言語仕様上関数でヒープまで消しちゃうから
仕組みがないとダングリングを起こしやすい
ダングリングはRust固有の持病
465:デフォルトの名無しさん
23/05/17 12:57:26.72 gejLyGRv.net
>>464
逆だよな
ダングリングポインタが生じるのはC++
466:デフォルトの名無しさん
23/05/17 13:13:25.46 BC7Hht5L.net
>>464
関数でヒープを自動解放する仕組みすなわち自動的にデストラクタが呼ばれる仕組みはC++とRustで同じ
467:デフォルトの名無しさん
23/05/17 13:36:00.32 bmOF/eVQ.net
デバッグビルドでよければ、結構重厚にチェックしてくれるんだけどね
リリースビルドでも一定程度チェックが残ってくれるようになれば、まだましになるか
468:デフォルトの名無しさん
23/05/17 13:56:37.30 ICP0Cmin.net
>>462
C++でも値に対する所有とライフタイムを明確にして参照のライフタイムがそれ以内に収まる枠組みにすればダングリングを防げるようになる