[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 02/27 03:27 / Filesize : 361 KB / Number-of Response : 1025
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

C++ vs Rust



1 名前:デフォルトの名無しさん mailto:sage [2021/04/24(土) 08:04:49.48 ID:nPKzA798.net]
競え

231 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 19:03:37.90 ID:kGsgeZzB.net]
結局Rustで実装できないテキストエディタ向けのデータ構造って具体的にはなんなんだ…
ropeもgap bufferもpiece tableも普通にRust実装あるが

232 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 19:07:47.11 ID:HWCOZSD4.net]
>>227
それは、人の知らないものを出してきて、根本問題から目を背けさせる手法。
どんなcrateがあろうと、根本的に出来無い事がRustには有るという話をしてる。

233 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 19:18:39.97 ID:4Q+A1yLL.net]
>>228
だからそのデータ構造をCでもC++でもなんでみいからはよソースコードで示せ

234 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 19:19:12.02 ID:5egSOJea.net]
>>225
まずCプログラマーには常識だけど
インデックスの番号を持つこととポインタを持つことでオーダーOが変わることはない
次に各々への複数のポインタを持つには配列やリンクリストなどの構造が必ず必要となる
いずれにせよポインタを使うことでオーダーOが変わることはない

>>228
そんなウソをついて何がしたいのかさっぱりわからない

235 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 19:21:02.53 ID:HWCOZSD4.net]
>>230
>インデックスの番号を持つこととポインタを持つことでオーダーOが変わることはない
>次に各々への複数のポインタを持つには配列やリンクリストなどの構造が必ず必要となる
>いずれにせよポインタを使うことでオーダーOが変わることはない

なんで、このスレはこんなにレベルが低いの。

236 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 19:21:28.08 ID:HWCOZSD4.net]
>>230
>そんなウソをついて何がしたいのかさっぱりわからない
真実だから。

237 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 19:27:10.84 ID:DZQ1+JmR.net]
>>232
数学の専門家であってプログラミング経験がないからソースコード出せとの指摘には一切答えられないということかな

238 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 19:32:17.29 ID:fRCpO7Rh.net]
>>194
ここであなたがおっしゃっているのは、以下のような実装のことでしょうか?

Element *array[] = {l0, l1, l2, l3, ...};

lnはリストのn番目の要素

239 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 19:43:59.25 ID:HWCOZSD4.net]
>>234
近いが、初期値が、{ &l5, &l1, &l123, &l25, ... };
のようになっているイメージ。
ただし、実際には、
・初期化子リストには書かず、プログラムの途中でリンクリストに挿入した直後に記録するような
 ことが多い。
・ノードの識別を常にポインタで扱うので、& で書くことは無い。
・固定配列ではなく、それもまたリンクリストにすることが多い。
 なぜなら、リンクリストは効率が良いことが多いから。



240 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 19:46:52.11 ID:HWCOZSD4.net]
>>233
そうではなく、
・大規模すぎて、こういうところには抽出して書ききれない。
・言葉で書いたほうが理解し易いはずだと思った。
 抽象概念を理解しにくい人がこんなに多いスレだとは思わなかったから。
・しかし、これだけ書いても理解できないと言うことは、具体的に書いても
 ますますそのコードの本質的な意味が理解できないと思われる。

241 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 19:57:10.45 ID:43z4eYfr.net]
中国共産党のお偉いさんって本当に偉いんですね

242 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 19:57:37.97 ID:43z4eYfr.net]
スレ間違えた まいいか

243 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 20:02:20.61 ID:fRCpO7Rh.net]
>>235
ある要素が複数のリストに所属するイメージでしょうか
例えば全要素が連なっているリストのn番目、特定の要素だけが抽出された別のリストのm番目に属すといったような
要素の削除に当たっては属するすべてのリストについて前後の要素からの参照を外す

244 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 20:03:50.15 ID:5egSOJea.net]
配列でもリンクリストでも他のコレクションでも全てに言えること
「格納要素が『データ本体でも、ポインタでも、何らかのid番号でも、他のインデックス番号でも、』そこは一切関係なく、様々な操作のオーダーOが変わることはない」
まずこの大原則をID:HWCOZSD4は理解できていないのたろう
だからポインタを使うと魔法のようにオーダーがO(1)になる

245 名前:と勘違いしている []
[ここ壊れてます]

246 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 20:04:15.63 ID:HWCOZSD4.net]
>>239
今回例としてあげたのはそういうケース。
ただそれは一例であってさまざまなケースがある。

247 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 20:04:48.66 ID:HWCOZSD4.net]
>>240
アホか。
俺は現実世界では天才と言われてるのに。

248 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 20:05:43.93 ID:fRCpO7Rh.net]
>>241
この一例もやはりRustでは実装できないのでしょうか

249 名前:デフォルトの名無しさん [2021/11/22(月) 20:07:17.81 ID:HWCOZSD4.net]
>>243
読み込みオンリーに限定して、一切削除もしないという条件なら可能。
ノードの中に書き込んだり、ノードを削除するなら、不可能。



250 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 20:08:42.39 ID:HWCOZSD4.net]
>>244
[補足]
C/C++/Java/C#/JS/Ruby/Python など多くの言語では可能だが、Rust
だけが不可能。
なので、Rustだけが仲間はずれであり、他の言語でできる事ができない。

251 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 20:10:06.74 ID:5egSOJea.net]
>>243
C言語で可能なことはRustでも可能

>>244
嘘つき

252 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 20:11:54.24 ID:4Q+A1yLL.net]
>>236
gistでもどこでもいいからコード貼り付けてリンクここに貼ってください
日本語でうだうだ話すより議論が早く終わるでしょうあなたの言うことが正しければ

253 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 20:14:36.47 ID:EEj8G+es.net]
>>245
Rustでプログラミングをしたこともない人がデタラメな妄想を撒き散らしてるなw

254 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 20:14:53.48 ID:HWCOZSD4.net]
>>246
デタラメ一言ってんじゃないぞ!!

>>247
具体例を書いても、それはレアケースだの、本質的にはリンクリストの速度では
間違った評価が下るだけ。

そもそも、極簡単な話を書いてるのに理解できないのにコードを書いても理解できる
とは思えない。
そもそも、ランダムアクセスの意味すら理解出来て無い、ここの人達は。

255 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 20:15:30.95 ID:HWCOZSD4.net]
>>248
うそつきは黙れ。

256 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 20:18:44.14 ID:HWCOZSD4.net]
>>246
>>244 は、Rustの借用規則からそうなってる。

257 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 20:21:30.15 ID:4Q+A1yLL.net]
そもそもRustだって最悪UnsafeCell使えば1変数への多数読み書き参照は保持できるのだが

258 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 20:27:13.86 ID:4Q+A1yLL.net]
>>249
僕はリンクリストの速度がどうこう評価するつもりはあんまりなくて、
他言語で書かれたソースコードが本当にRustでは無理なのかを確認したいだけ

だから、その「Rustでは無理なコード」を見てみたい、と言っている
最悪ソースコードの中身は理解不能なものでもよい

259 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 20:27:43.67 ID:43z4eYfr.net]
>>249
説明するつもりもないのに、お前らはどうせ理解もできないバカだ、俺はいつも数学100点の天才だ、俺を信じろ

とか言ってても狂人扱いされるだけに決まってるじゃん・・・



260 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 20:29:18.57 ID:0LbM6y2O.net]
Cursorを使えと何回言っても聞かない
テキストエディタの例では>>119のアイデアを完全無視

261 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 20:50:09.64 ID:MtEs+7mt.net]
おれも興味があるな
C++では書けてRustでは書けないコード

リソースを無視すればチューリング完全だろうから
書けないなんて事はないはずで
何かしら制限を付けた上での「書けない」なんだろうけど

262 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 20:55:11.07 ID:fRCpO7Rh.net]
>>245
Rust でも書けるように思えてしまったのですが、以下のコードはどこが間違っているのでしょうか

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=7534885705cd5879f536acdf64947870

263 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 21:10:18.70 ID:ejqG4gpN.net]
>>216
プログラマを守るためそれをさせないのがRustっていう言語ではw
Rc<RefCell>ではいかんの?

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=50e9fc65e69dd1859478ee62dde963aa
fn main() {
use std::collections::LinkedList;
use std::rc::Rc;
use std::cell::RefCell;
let mut list: LinkedList<Rc<RefCell<i32>>> = LinkedList::new();
list.push_back(Rc::new(RefCell::new(1)));
list.push_back(Rc::new(RefCell::new(2)));
list.push_back(Rc::new(RefCell::new(3)));
println!("{:?}", list); // [RefCell { value: 1 }, RefCell { value: 2 }, RefCell { value: 3 }]
let mut vec: Vec<Rc<RefCell<i32>>> = Vec::new();
let mut it = list.iter();
vec.push(Rc::clone(it.next().unwrap()));
vec.push(Rc::clone(it.next().unwrap()));
vec.push(Rc::clone(it.next().unwrap()));
println!("{:?}", vec); // [RefCell { value: 1 }, RefCell { value: 2 }, RefCell { value: 3 }]
println!("{:?}", vec[1]); // RefCell { value: 2 }
*vec[1].borrow_mut() = 22;
println!("{:?}", vec[1]); // RefCell { value: 22 }
println!("{:?}", list); // [RefCell { value: 1 }, RefCell { value: 2 }, RefCell { value: 3 }]
println!("{:?}", vec); // [RefCell { value: 1 }, RefCell { value: 2 }, RefCell { value: 3 }]
}

264 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 21:13:26.74 ID:7gi7NmEv.net]
>>255
Cursorでも無理だ。

265 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 21:14:06.15 ID:ejqG4gpN.net]
あっコメントはミスってる
実行結果はこちら
[RefCell { value: 1 }, RefCell { value: 2 }, RefCell { value: 3 }]
[RefCell { value: 1 }, RefCell { value: 2 }, RefCell { value: 3 }]
RefCell { value: 2 }
RefCell { value: 22 }
[RefCell { value: 1 }, RefCell { value: 22 }, RefCell { value: 3 }]
[RefCell { value: 1 }, RefCell { value: 22 }, RefCell { value: 3 }]

266 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 21:17:24.64 ID:DZQ1+JmR.net]
Rustの実装 (>>257) はポインタでの直接アクセスではなく配列への添え字アクセスだからオーバーヘッドが大きいとか言い出したらみんなで笑ってあげましょう

267 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 21:26:20.75 ID:7gi7NmEv.net]
>>257
独自のLinkedListで、実装としては配列を持っていて、
ノード間が参照でリンクされておらず、添え字番号でリンクしており、
get(), set()が添え字番号を返して配列要素を返しているので
ゼロコストではないね。

struct LinkedList<T> {
 first_idx_a: Option<usize>,
 first_idx_b: Option<usize>,
 elems: Vec<Elem<T>>,
}
struct Cursor {
 a_idx: usize,
}
fn get(&self, elem: Cursor) -> &T {
 &self.elems[elem.a_idx].data
}
fn set(&mut self, elem: Cursor, data: T) {
 self.elems[elem.a_idx].data = data;
}

268 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 21:27:13.68 ID:7gi7NmEv.net]
>>261
ゼロコストが謳いなのに、ゼロコストで無い。

269 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 21:27:14.40 ID:5egSOJea.net]
>>257
それで実装も動作も良いけど
_bはどちらも不要
_a.0と_a.1はそれぞれprevとnextと書いたほうが読みやすい



270 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 21:33:11.94 ID:fRCpO7Rh.net]
>>264
_b は単一の要素が複数のリストに属するという要件に対する実装ですね
面倒だったのでメンバーだけ用意して実装はしてないですが
タプル使ってるのも構造体定義が面倒だったため
というかできるできないを実証するための例なので細かいところは適当です
お好きなように修正してください

>>263
>>245
> C/C++/Java/C#/JS/Ruby/Python など多くの言語では可能だが、Rust
だけが不可能
> なので、Rustだけが仲間はずれであり、他の言語でできる事ができない。

というのはほかの言語ではゼロコストで実装できることを意味していますか?
それともRustでも実装できることを認めた上でのただの負け惜しみですか?
はたまたこれを書いたのは自分とは別の人と主張されるのでしょうか

271 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 21:34:40.04 ID:fRCpO7Rh.net]
>>262
ゼロコストを定義してください

272 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 21:37:06.49 ID:7gi7NmEv.net]
>>265
後半のあなたの主張、おかしくないか。
Rustの参照では無い独自の参照風の様な構造を添え字番号で実装してしまって、
C言語より速度を落としているのだから、ゼロコスト性に反してる。

273 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 21:38:01.88 ID:7gi7NmEv.net]
>>266
参照に関しては、参照がC言語の生ポインタと同じ速度で扱えること。

274 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 21:38:56.97 ID:fRCpO7Rh.net]
>>267
あらゆる言語の中でRustだけが実装できないという主張は撤回されて
CにRustは劣るという主張へと変更されるのですね?

275 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 21:49:14.11 ID:EEj8G+es.net]
>>257
elements_aはinto_iterにしたらあかんの?と思ったけど
2つ持った時の前半用として用意した意味なのかw

276 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 21:56:48.89 ID:7gi7NmEv.net]
>>269
1. データを格納している場所が配列になっているが、動的に長さを長くしようとすれば
 動的配列と同様のコピー動作が生じてしまうから、その実装は、本来のLinkedListの
 性質とはかなり異なる。リンクリストは速度的に安定である事が重要なのに、
 この性質により、動的配列と同様に、時々大規模コピーが生じて、スパイク的に
 速度が遅くなる減少を伴うことになってしまう。このようなスパイク的な
 速度低下は、twitterかFacebook のどちらか忘れたが、どっかのSNSでも問題
 になっていた。
2. アクセスするときに、番号を配列のアドレスに変換する動作を毎回行っている。

277 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:00:19.83 ID:7gi7NmEv.net]
>>271
[補足]
誤解を招いて議論に混乱を来たしそうなので捕捉しておくと、
271の2で書いた「番号」は、リンクリストの先頭からの通し番号の事ではなく、
今回示されたリンクリスト風のコードで、内部で用いられている配列の添え字番号
のことで、リンクリストの先頭からは、辿っていっても、連続した番号には成ってないもの。

278 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:05:48.24 ID:fRCpO7Rh.net]
>>271
あらゆる言語で実装できないがRustでは実装できない
他の言語だと O(1) だが Rustだと O(N) になる
という主張を撤回されたと理解しました

そういうことでしたら私の方から言うことはなにもありません

またアロケーションについてはVecを実装が工夫されたコンテナ型に変えることで対応できそうですね
実装詳細のないまま議論してもしょうがないトピックなのでこれ以上こちらからレスを重ねることはやめます
ありがとうございました

279 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:10:00.62 ID:7gi7NmEv.net]
>>271
[追加]
3. そこにさらに削除メソッドを実装したとしよう。
 削除したノードに対する番号が、どこかのCursorの中にまだ生きた状態に
 なっている場合、ダングリング参照と似た現象が起きる。
 削除したノードの中を参照できてしまうのだ。



280 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:15:27.68 ID:7gi7NmEv.net]
>>273
その主張、Rustの中に超軽量のインタプリタの様なものを載せておいて、
そのインタプリタの中ではランダムアクセスがO(1)のリンクリストが
完全に実装できることを示しただけだね。
しかも、追加すると、時々、大規模なメモリーコピーが生じるし。
newやmallocではそのようなメモリーコピーは生じない。
ノードを追加しても、リンクリスト中の他のノードの本当のマシン語レベルでの
線形アドレスが固定で変化し無いし。
あなたの実装では、それが変化してしまう。相対アドレスは変化しないが。
ベースアドレスが変化している。

281 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:19:00.36 ID:fRCpO7Rh.net]
>>274
generational arenaという手法を利用することでダングリングポインタ的アクセスを検知してハンドリング可能になります

282 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:19:03.44 ID:7gi7NmEv.net]
>>274
[補足]
実質的なダングリング参照が起きるということは、Rustのもう一つの柱である
ところのメモリー安全性が部分的に壊れてしまってるということだ。

283 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:23:12.75 ID:7gi7NmEv.net]
>>276
動的コストを掛けていいなら、C++でも安全性の高いものは作れるぞ。
ポインタも正しいメモリーブロックを指していることを動的に確認した後で
実際に参照するようなことは、C++でも出来るから。
Rustも配列の範囲チェックはやっているが、配列以外のアドレスでも、動的に
チェックしようと思えばいろいろなチェック法はある。
その一つの方法が、アドレスではなく、あなたが書いたような配列の中の
番号方式にしてしまうこと。
番号に対する配列要素がNULLになっていれば、動的にエラーを出力して
アプリを停止させる、などの方法が有る。

284 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:25:32.33 ID:fRCpO7Rh.net]
>>278
Rustの zero-cost abstraction はあなたの期待するような物ではありませんでした
残念でしたね

285 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:36:23.68 ID:7gi7NmEv.net]
>>265
>>

286 名前:C/C++/Java/C#/JS/Ruby/Python など多くの言語では可能だが、Rust
だけが不可能
>> なので、Rustだけが仲間はずれであり、他の言語でできる事ができない。
>というのはほかの言語ではゼロコストで実装できることを意味していますか?
>それともRustでも実装できることを認めた上でのただの負け惜しみですか?

分かった。ゼロコストで無くて良いなら Rustでも実装できるということだね。
なるほど、今回の実装法のような裏技の発想は無かったよ。それは認める。
でも、ゼロコストでなくなるということは、RustがC/C++の代替になるという
説には反することになるね。

それと、C++, Java, C# では最初から標準ライブラリ的なもので最初から実装済み
なのに対して、あなたのやり方は、少なくとも標準のLinkedListではないね。
Cursorも標準のものとは別。
[]
[ここ壊れてます]

287 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:37:35.24 ID:0LbM6y2O.net]
結局何がしたいのよ
ノードへの参照を持ったままリストを変更したいの?

288 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:44:50.09 ID:7gi7NmEv.net]
>>281
何がしたいって、C/C++/C#/Javaでは、LinkedListへのアクセスがO(1)で
自由自在に出来るのに、標準のRust実装では出来ないことが問題なんだ。

それに、今回示された実装法では、内部では配列で実装されているから、
ノードを追加してい言って、配列の要素数を超える時には、新しい配列を
コピーして内部でコピー動作が生じる。これは、C++のnewよりも遥かに
遅い動作になってしまうし、スパイク的に時々生じるから速度的な安定性
が求められるソフトでは好ましくない現象。

また、実質的なダングリング参照的が生じることも指摘した。

結論は、このやり方で、C/C++などと同じO(1)にはなったものの、安全性も失われ、
ゼロコスト性も失われ、C/C++の実装に比べて速度的に不安定でありスパイク的に
遅くなるということだ。

289 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:51:04.06 ID:0LbM6y2O.net]
>>282
「LinkedListへのアクセスがO(1)で自由自在に出来る」
が正確にはどういう意味かと聞いているんだ

>>257の実装は忘れなさい



290 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:52:27.47 ID:7gi7NmEv.net]
>>281
>ノードへの参照を持ったままリストを変更したいの?
もちろん、それもある。

291 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:56:03.63 ID:qBbb57Hy.net]
デマを流すのはゼロコストなんだから相手にした時点で負け

292 名前:デフォルトの名無しさん [2021/11/22(月) 22:57:09.11 ID:7gi7NmEv.net]
>>283
>「LinkedListへのアクセスがO(1)で自由自在に出来る」
>が正確にはどういう意味かと聞いているんだ

Cの場合、ポインタでアクセスすれば、O(1)でリンクリストの
ノードを参照できるし、削除も出来る。
削除しても、他のノードのアドレスは変化しないから、ポインタも
書き換える必要も無い。
配列だったら、削除するとそれより後ろのノードの番号が全て
変化してしまうので、書き直さなくてはならない。
リンクリストでも、先頭からの通し番号を識別番号に
している場合には、同様にそれ以後のノードの全ての番号を書き換えないといけない。

リンクリストのノードにO(1)でアクセスするというのは、ポインタでアクセスすれば
当たり前の事で、どう説明していいのか分からない。マシン語では、間接参照の
[アドレス]
だけの話だから。
コンピュータの基礎から学び直してもらわないと理解してもらえないかも知れない。
マシン語を学んで欲しい。

293 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:57:21.67 ID:0LbM6y2O.net]
コンテナと各要素の&mutと&が同時に取れない件はsplitして借用の単位を分けるべし
Vec::split_at_mutと同様の発想

294 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:59:22.03 ID:0LbM6y2O.net]
>>286
だからそれだけならCursorMutでできるんだって
でもダメなんだろ?
それはなぜ?

295 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:01:06.85 ID:7gi7NmEv.net]
>>285
どっちがデマだと思ってるのか知らんが、俺のはデマじゃないぞ。

実際に、今回の実装を示した彼は、俺の言ってることはある程度正しく理解していた。
つまり、基本的にデマじゃないということを理解した人がいるということだ。
ただし、彼は、ゼロコスト安全性である、ということを無視して独自実装したり、
参照を独自に修正したものを勝手に導入した誤魔化しがあったのが残念であった
だけだ。
つまり、俺の主張自体は、彼は本当は理解している。
理解しているが、悔し紛れに詐欺めいた独自実装をしたことだけが残念なだけだ。

296 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:01:57.98 ID:7gi7NmEv.net]
>>288
1つのリンクリストに対して、書き込み参照や読み込み参照を同時に複数持てない。

297 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:13:17.79 ID:5egSOJea.net]
>>290
デマを流すのはそろそろやめとけよ
RustはRefCellもあるし複数からポインタで指しつつ書き換えもできるぞ

298 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:14:41.21 ID:7gi7NmEv.net]
>>291
そもそも、RefCellは、動的チェックが入るからゼロコストではない。
C には存在しないコストが新たに導入される。

299 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:15:37.93 ID:WXoW4mOX.net]
unsafe で生ポインタ使えばCと同じ実装は確実にできるが



300 名前:デフォルトの名無しさん [2021/11/22(月) 23:15:41.59 ID:NDd1353W.net]
リンクトリストな?

301 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:16:05.08 ID:5egSOJea.net]
>>292
何を言ってるんだ?
そういうコストかけずにどうやって排他制御するんだよ?

302 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:18:27.46 ID:WXoW4mOX.net]
>>295
そこはCだとプログラマが気をつけることで排他制御してるんだと思うよ
unsafe Rustでも同じだけど

303 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:18:40.37 ID:7gi7NmEv.net]
>>295
C++と同じ事が出来るのに「ゼロコスト」で「安全」、と謳ってるのが間違いだと
言ってる。
間違いというより、デマや誇大宣伝。

304 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:21:22.25 ID:0LbM6y2O.net]
>>290
そうだ、最初からそう言えばよかったんだ
蓋を開けてみればO(1)なんかまるで関係無いじゃないか

でそれに対して>>287という策があるわけだがどう思う?

305 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:22:12.49 ID:7gi7NmEv.net]
>>295
「排他制御」とは、マルチスレッドプログラミングで使う用語なのだが、
本当にその意味で使ってるか?

306 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:22:18.49 ID:EEj8G+es.net]
>>292
ゼロコストって他のことでもそうだけど全くコストがかからないってことではない
必要最低限のことのみでそれ以外はゼロコストってこと
今回のRefCellならば並行プログラミングの時の書き換え競合が起きないことを保証する
RefCellはゼロコスト
ゼロコストでないと主張するならば他の対処方法を述べよ

307 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:24:19.66 ID:7gi7NmEv.net]
>>298
「策」があるっていうが、どんどん複雑化し、コストも増えているだろ。

308 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:28:31.00 ID:7gi7NmEv.net]
>>300
俺も正直言うとRefCellとか出てくると複雑すぎてよくわからなくなってくるが、
RefCellは内部可変性に対するものだから、並行プログラミングを使わない時
にも使うことがあるはずだが。

309 名前:デフォルトの名無しさん [2021/11/22(月) 23:28:31.66 ID:NDd1353W.net]
Rustは安全性を追求した言語でC++と比較する物ではない。
比較するならRubyが妥当。



310 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:30:51.55 ID:7gi7NmEv.net]
>>303
つまり、CやC++の代替には成りえない。
アプリレベルであってもC/C++の全てをカバーすることは出来ない。

311 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:33:19.88 ID:WXoW4mOX.net]
コンパイラに安全性を保証してほしければ実行時のコストを払ってRefCellを使えばいいし、
そのコストを払いたくなければunsafe 使って自分で安全性を保証すればいいって話なんだが

312 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:35:15.39 ID:4Q+A1yLL.net]
必要最低限のunsafeを使うのは大前提で、
それでもリンクリストがどうたらって話じゃなかったっけ・・・??

313 名前:デフォルトの名無しさん [2021/11/22(月) 23:36:31.09 ID:NDd1353W.net]
だからリンクトリストな?

314 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:38:22.71 ID:5egSOJea.net]
>>299
シングルスレッドマルチタスクでも競合は起き得る
そのため書き込み権限がある者がある瞬間に複数存在しないことを保証する(排他制御)ためにRefCellがある
マルチスレッドの場合は並列に起き得るからもっと厳しくてRefCellではダメでMutexやRwLockを使う

315 名前:デフォルトの名無しさん [2021/11/22(月) 23:39:08.56 ID:NDd1353W.net]
Rustは安全性を追求した言語でC++と比較する物ではない。
比較するならVBAが妥当。

316 名前:デフォルトの名無しさん [2021/11/22(月) 23:40:06.95 ID:NDd1353W.net]
RustがC++をライバル視してきて非常にウットオシイ。
貴様のライバルはJavascriptだろ。

317 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:41:22.24 ID:7gi7NmEv.net]
>>291
LinkedListの中のノードへの参照を10個持っている状態で、
その参照を使って1個のノードを削除しようとしてコンパイルは通るか?

318 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:42:38.96 ID:0LbM6y2O.net]
>>301
safeであるためには必要なコストだと思うけどね
mutabilityが前後のノードに影響するデータ構造だから仕方がない

319 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:44:32.43 ID:5egSOJea.net]
>>311
それCでもC++でもダングリングポインタ発生の駄目プログラマーパターン



320 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:49:43.35 ID:7gi7NmEv.net]
>>313
そんなことないぞ。
vectorと勘違いして無いか。

321 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:55:11.62 ID:4Q+A1yLL.net]
>>311
参照先自体を削除するんじゃなくて、参照先からさらにnextとかprevたどってどっかのノードを削除するってこと?
参照先自体を削除するのはRustに限らず問題でるよね

322 名前:デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:58:04.28 ID:7gi7NmEv.net]
>>315
参照先を削除するのは普通なことで、安全に行えるぞ。
参照とは、つまり、識別番号の代わりに使うものだからな。
参照はオブジェクトに付けられた名前みたいなもんだから、
逆に言えば、参照先を削除できないなら、削除する方法がほぼ無い。

323 名前:デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:00:50.13 ID:1c3aeddQ.net]
何の話についてもまずは具体的なC言語のコードを示すべきじゃないかな
そうすればRustのコードを2種類みんなが出してくれるよ
 ・1つは元のC言語と同じ安全度で場合によってはunsafeを用いて実装
 ・もう1つはメモリ安全性を保証してunsafeを使わずに実装
つまり「C言語で出来ることはRustで必ず出来る」+「Rustではメモリ安全性を保証した実装も可能」
明らかにC言語よりもRustの方が能力も高く優れている

324 名前:デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:00:51.12 ID:16zHq7La.net]
>>314
残り9個の参照はそのノードが削除されたことを知る術がないからダングリングポインタになるってことだろ

325 名前:デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:08:02.67 ID:xJBrssBV.net]
>>318
本来は、明らかに別のノードであれば問題ない。
C++では普通に安全にそれが行える。
リンクリストの中に、A, B, C という名前の人のデータが入っていて、
それぞれに対して1つずつそれぞれ、ポインタ pA, pB, pC が存在している時に
ポインタ pA を介してAを削除しても、B, C へのポインタ pB, pC は残っていて、
値も変更されることも絶対に無いから完全に安全。
Aさんのデータを削除する場合にはこのようなことが起きるが、その時には、
delete pA の後、pAを捨ててしまうだけで全く安全。
pB, pC は何事も無くまったく安全に残せるし、何のバグも入らない。
こんな単純なロジック、何の問題も無い。

326 名前:デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:15:34.94 ID:8Ju98kPx.net]
同一のノードに10個の参照って意味ちゃうん?

327 名前:デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:16:47.17 ID:1c3aeddQ.net]
>>319
それだと>>311の条件を満たしていないのでやり直し
 ・いずれにせよC/C++で書けるコードはそのままの形でそのままの安全度で必ずRustでもunsafeを用いて書ける
 ・更にRustでは安全性を保証する形でunsafeを用いずに実装することもできる
C/C++よりもRustのほうが明白に能力が高い

328 名前:デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:20:07.35 ID:xJBrssBV.net]
>>320
1つのリンクリストの異なる10個のノードに対する10個の参照。

329 名前:デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:21:41.44 ID:/rTkTwIT.net]
>>319
C++でノードへのポインタは実装依存な方法でしか取れないよ
pAその他は本当にポインタ?イテレータではなく?



330 名前:デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:21:54.64 ID:xJBrssBV.net]
>>321
何度もしているが、それはフェイク。
Cできることのうち、Rustでは追加コストを掛けずにはsafeモードで出来ないことはたくさん有る。
unsafeモードを使いまくれば別。
しかしそれではRustを使う意味が無い。

331 名前:デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:22:40.62 ID:xJBrssBV.net]
>>323
C++ではなく、Cのリンクリストで考えよう。C++は別の複雑さを入れ込んだから。






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧](;´∀`)<361KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef