21/11/22 17:48:40.73 43z4eYfr.net
「Rustだとできない」っていうのはよくわからないし、そこだけ気になってるんだけど、
Rustって参照を持ち回すことがそんなにできないんだ
201:デフォルトの名無しさん
21/11/22 17:49:16.27 EEj8G+es.net
C言語であろうがなかろうが言語に関係なくO(1)は無理
わからない人はコーディングすればすぐわかる
ランダムでkが与えられた時にリンクリストのk番目を常にO(1)で得るためには
全てのk番目の位置を別の配列で保持管理しないといけない
そしてリンクリストで挿入削除が行われるたびにk番目がズレるから保持管理する配列で毎回O(n)を必要とする移動が発生
どんな言語でどんな手法を用いてもO(1)は絶対に不可能
202:デフォルトの名無しさん
21/11/22 17:53:40.47 ejqG4gpN.net
>>198
俺もそう思う
彼の主張にはポインタの配列をケアする時間を含んで無さそうに聞こえたけどｗ
せっかくのリクリストとは別にアクセス用のポインタ配列をケアするってことも
ふしぎなコーディングだけど
そこまでするなら最初から配列だけでやれって思うけどｗ
203:デフォルトの名無しさん
21/11/22 17:55:47.65 HWCOZSD4.net
>>198
その別の配列に用意したアドレスに基いてアクセスすれば、立派なランダム
アクセスなんだ。
ランダムアクセスとは、毎回デタラメにアクセスすることでは無いぞ。
テープレコーダーの場合、キメウチで、100, 1, 200, 10, 30, 2, 1000
の位置の7個のデータを取得するには、シーク時間が必要だから、
100+99+199+190+20+28+998 の時間が掛かる。
そしてこの読み取りを2回行ってもまた同じだけの時間が掛かる。
その意味で、ランダムアクセス時間は、テープの長さがNの時、O(N)とされている。
ところが、リンクリストの場合、アドレスが毎回決まっている 7 個のデータ
をアクセスするには、一個当りのノードに掛かる平均時間は O(1)だ。
これを2回行っても同じ。
あなたがおもっているような、シーク時間はリンクリストの場合には不要だから。
204:デフォルトの名無しさん
21/11/22 17:56:50.13 HWCOZSD4.net
>>199
そうでなくて、その配列が既に決まっている場合もあるんだということだ。
それを上手く用意することが出来るケースが現実にかなり有る。
205:デフォルトの名無しさん
21/11/22 17:57:28.92 ejqG4gpN.net
いや配列ケアのほうは時間はそれほどでもないか
挿入削除場所以降のコピーする必要が出るだけで
206:デフォルトの名無しさん
21/11/22 17:59:39.65 ejqG4gpN.net
>>201
へー
207:デフォルトの名無しさん
21/11/22 17:59:44.70 HWCOZSD4.net
なぜかというと、アドレスは、ノードを追加した時に分かるから、それをどこかに
記録しておけば「シーク時間」が不要だから。
例えば、100個のノードを任意の位置に追加したとしよう。そのアドレスは、
100個分は既知である。そのアドレスをまたどこかのリンクリストの末尾に
でも順番に追加して全て記録しておいたとしよう。
そうすると、元のリンクリストは、立派にO(1)でランダムアクセスできるんだ。
208:デフォルトの名無しさん
21/11/22 18:00:15.83 43z4eYfr.net
> リンクリストの場合、アドレスが毎回決まっている 7 個のデータをアクセスするには、
> シーク時間はリンクリストの場合には不要だから。
そら、あらかじめアドレスがわかってればできるだけで、別にLinked Listの性質ではないよね
209:デフォルトの名無しさん
21/11/22 18:01:09.38 EEj8G+es.net
>>200
そこでO(1)とは配列のアクセスのみ
つまりリンクリストは全く関係なく配列のアクセスがO(1)だと主張していることに気付こう
そしてリンクリストで削除や挿入が行われるたびにその配列でO(n)の大移動が行われる
結論: O(1)ではどんな言語でもプログラミングできない
210:デフォルトの名無しさん
21/11/22 18:02:14.47 HWCOZSD4.net
>>206
そんなことない。
あなたは、ポインタを使ったプログラミング経験が浅い。
211:デフォルトの名無しさん
21/11/22 18:04:00.68 HWCOZSD4.net
>>205
そうでない。
テープレコーダーとリンクリストでは、明らかにランダムアクセスに掛かる時間の
性質が違う。
「アドレスが既知」であるのは、ポインタを全面的に使ったプログラミング法
では当たり前の事だから、リンクリストに置いてシーク時間は不要。
212:デフォルトの名無しさん
21/11/22 18:05:44.36 HWCOZSD4.net
>>206
違う。
ツリーの場合でも、番号ではなく、ノードをポインタで識別することで、
0の時間でシークできる。
リンクリストでも同じ。
通し番号を使おうとするから遅くなってるだけ。
ノードの識別をポインタで統一してしまうと、本当に O(1)でいける。
213:デフォルトの名無しさん
21/11/22 18:07:52.10 EEj8G+es.net
>>204
あなたの主張を整理すると
「k番目をO(1)でアクセスできる配列」は「k番目をO(n)でアクセスできるリンクリスト」よりも優れている、となる
O(1)の部分はリンクリストと全く無関係であることに気付かないとね
ここまで壮大な勘違いをしてるのはおそらくプログラミングをしたことがないのだろうけど
214:デフォルトの名無しさん
21/11/22 18:09:34.28 43z4eYfr.net
アドレスへのランダムアクセスは定数オーダー。そりゃメモリはそういう設計で作られてるんだから当然
テープレコーダーはランダムアクセスできない。これも当然
なんでテープレコーダーと、メモリ上に実装したLinked Listを比較しているのか意味がわからない
何を説明しようとしてるんだろう
215:デフォルトの名無しさん
21/11/22 18:10:17.50 ejqG4gpN.net
>>206
なんか話途中から首突っ込んだけど
結局はそういうしょうもないオチっぽいなこれｗ
ポインタの指す先のデータ構造に一切関わらず
アクセス用のポインタを回収して配列にするんならそりゃO(1)だもんな
そしてわざわざそれをしたいという動機もよーわからんかった
216:デフォルトの名無しさん
21/11/22 18:12:45.44 HWCOZSD4.net
例えば、データベースの様なものが有ったとしよう。
個人情報がリンクリストに入っているが、ID番号と個人情報は別に配列の中に
入っていて、ID番号の構造体には、リンクリストのノードのアドレスも
入っているとする。
これだと、ID番号を全て巡って、それぞれの個人情報を巡る時、
個人情報の1個当りのアクセスに掛かる平均時間はO(1)だ。
しかし、ノードのアドレスの変わりに、ノードの通し番号を入れてしまって
いたとすると、ノードをシークするためにO(N)の時間が掛かってしまう。
なので、ノードの識別をポインタにしてしまえば、O(1)で、通し番号に
してしまえばO(N)の時間が掛かる。
だから、リンクリストを使う場合には、通し番号ではなく、ポインタを
使うことが推奨されている。ところが、Rustではそれがほぼ不可能。
217:デフォルトの名無しさん
21/11/22 18:14:22.43 43z4eYfr.net
へー、Rustってそんなこともできないんだ
218:デフォルトの名無しさん
21/11/22 18:15:23.83 HWCOZSD4.net
>>210
いや、ノードの識別をアドレスで行いさいすれば、
リンクリストと配列のランダムアクセスに掛かる時間はどちらもO(1)だから
リンクリストが劣っていることは無い。
なぜなら、乱数で与えられた位置のノードをアクセスする必要は無いから。
ランダムアクセスする場合でも、アクセスすべき位置は、アドレスで決まっている。
シークの時間は不要。
219:デフォルトの名無しさん
21/11/22 18:16:52.13 HWCOZSD4.net
>>214
次の借用規則に引っかかる。
・1個でも書き込みの参照が有る場合、読み込み参照は1つも持てない。
書き込み参照も1個しか持てない。
220:デフォルトの名無しさん
21/11/22 18:26:59.33 5egSOJea.net
>>214
Rustが次々とC/C++の領域を置き換えていってるように
両者で実現できることは同じ
彼はアルゴリズムとオーダーについてもよく理解できていないだけでなく
Rustについても全く理解していない
221:デフォルトの名無しさん
21/11/22 18:28:27.85 43z4eYfr.net
なるほど。もうちょっとRust覚えたらそういうデータ構造も自分で実装して試してみるよ
222:デフォルトの名無しさん
21/11/22 18:31:34.64 HWCOZSD4.net
>>217
計算時間のオーダーが全く違ってくる。
データベースなどは速度やメモリー効率を高めるために、さまざまな構造を
駆使して作られていることが有り、Rustでは自由に作ることが難しいことが
有り得る。
100万行のテキストエディタの先頭に1000行のデータをペーストするような
時にもリンクリストが大活躍する。単純な配列では遅すぎて駄目。
223:デフォルトの名無しさん
21/11/22 18:34:23.79 HWCOZSD4.net
>>217
あなたは、データ構造やポインタを深く理解して無いか、
高度な実践的プログラミング経験が浅いかのどちらか。
224:デフォルトの名無しさん
21/11/22 18:41:12.00 EEj8G+es.net
>>219
やはりプログラミングしたことがないようだな
そこで50万行目に行く場合に配列併用なし実装だとリンクを50万回たどるO(n)
配列併用あり実装だと50万行目へ一気に行けるO(1)が挿入削除時のたびに配列内で大移動O(n)
つまりO(1)になっているのは配列アクセスのみ
225:デフォルトの名無しさん
21/11/22 18:45:29.95 HWCOZSD4.net
>>221
リンクリストAの中のランダムな位置のノードのアドレスを、
別のリンクリストBに入れておいて、Bの先頭から順番にループすれば、
リンクリストAのノードをランダムアクセスできるが、その時の
一個のノードあたりの平均アクセス時間はO(1)だ。
ここに配列は一個も出てこない。
226:デフォルトの名無しさん
21/11/22 18:51:10.61 5egSOJea.net
>>222
それ、あるkが与えられたときにk番目のアクセスがO(n)になってる
それがリンクリストの性質
ランダムアクセスすなわちk番目のアクセスはO(1)の配列が圧倒的に有利
227:デフォルトの名無しさん
21/11/22 18:54:15.44 HWCOZSD4.net
>>221
それはテキストエディタでは結構問題になる部分だが、
実際的には、ページ単位の大きな移動は文字挿入や文字削除などの編集操作に比べて時々しか
行わないことと、現在位置から相対的な移動距離は大きくないことが多いことから、
行の記憶は配列ではなくリンクリストにしておく手法を取ると良い。
実際に行の記憶を何も配慮せずに配列でやると、ペーストした時にとても遅くなる。
一方、行の記憶をリンクリストにすると、実際問題はかなり快適になる。
スクロールなども速い。
一気に決め打ちの行番号に移動するのはO(N)の時間が掛かることはかかるが、
決め打ちの番号に移動することは、たまにしか行わないので遅くは感じない。
228:デフォルトの名無しさん
21/11/22 18:55:48.2
229:9 ID:HWCOZSD4.net
230:デフォルトの名無しさん
21/11/22 18:59:38.49 HWCOZSD4.net
>>223
ランダムアクセスとランダムに生成した通し番号 k のノードにアクセスする
ことは別の概念だぞ。
231:デフォルトの名無しさん
21/11/22 19:03:37.90 kGsgeZzB.net
結局Rustで実装できないテキストエディタ向けのデータ構造って具体的にはなんなんだ…
ropeもgap bufferもpiece tableも普通にRust実装あるが
232:デフォルトの名無しさん
21/11/22 19:07:47.11 HWCOZSD4.net
>>227
それは、人の知らないものを出してきて、根本問題から目を背けさせる手法。
どんなcrateがあろうと、根本的に出来無い事がRustには有るという話をしてる。
233:デフォルトの名無しさん
21/11/22 19:18:39.97 4Q+A1yLL.net
>>228
だからそのデータ構造をCでもC++でもなんでみいからはよソースコードで示せ
234:デフォルトの名無しさん
21/11/22 19:19:12.02 5egSOJea.net
>>225
まずCプログラマーには常識だけど
インデックスの番号を持つこととポインタを持つことでオーダーOが変わることはない
次に各々への複数のポインタを持つには配列やリンクリストなどの構造が必ず必要となる
いずれにせよポインタを使うことでオーダーOが変わることはない
>>228
そんなウソをついて何がしたいのかさっぱりわからない
235:デフォルトの名無しさん
21/11/22 19:21:02.53 HWCOZSD4.net
>>230
>インデックスの番号を持つこととポインタを持つことでオーダーOが変わることはない
>次に各々への複数のポインタを持つには配列やリンクリストなどの構造が必ず必要となる
>いずれにせよポインタを使うことでオーダーOが変わることはない
なんで、このスレはこんなにレベルが低いの。
236:デフォルトの名無しさん
21/11/22 19:21:28.08 HWCOZSD4.net
>>230
>そんなウソをついて何がしたいのかさっぱりわからない
真実だから。
237:デフォルトの名無しさん
21/11/22 19:27:10.84 DZQ1+JmR.net
>>232
数学の専門家であってプログラミング経験がないからソースコード出せとの指摘には一切答えられないということかな
238:デフォルトの名無しさん
21/11/22 19:32:17.29 fRCpO7Rh.net
>>194
ここであなたがおっしゃっているのは、以下のような実装のことでしょうか？
Element *array[] = {l0, l1, l2, l3, ...};
lnはリストのn番目の要素
239:デフォルトの名無しさん
21/11/22 19:43:59.25 HWCOZSD4.net
>>234
近いが、初期値が、{ &l5, &l1, &l123, &l25, ... };
のようになっているイメージ。
ただし、実際には、
・初期化子リストには書かず、プログラムの途中でリンクリストに挿入した直後に記録するような
ことが多い。
・ノードの識別を常にポインタで扱うので、& で書くことは無い。
・固定配列ではなく、それもまたリンクリストにすることが多い。
なぜなら、リンクリストは効率が良いことが多いから。
240:デフォルトの名無しさん
21/11/22 19:46:52.11 HWCOZSD4.net
>>233
そうではなく、
・大規模すぎて、こういうところには抽出して書ききれない。
・言葉で書いたほうが理解し易いはずだと思った。
抽象概念を理解しにくい人がこんなに多いスレだとは思わなかったから。
・しかし、これだけ書いても理解できないと言うことは、具体的に書いても
ますますそのコードの本質的な意味が理解できないと思われる。
241:デフォルトの名無しさん
21/11/22 19:57:10.45 43z4eYfr.net
中国共産党のお偉いさんって本当に偉いんですね
242:デフォルトの名無しさん
21/11/22 19:57:37.97 43z4eYfr.net
スレ間違えた まいいか
243:デフォルトの名無しさん
21/11/22 20:02:20.61 fRCpO7Rh.net
>>235
ある要素が複数のリストに所属するイメージでしょうか
例えば全要素が連なっているリストのn番目、特定の要素だけが抽出された別のリストのm番目に属すといったような
要素の削除に当たっては属するすべてのリストについて前後の要素からの参照を外す
244:デフォルトの名無しさん
21/11/22 20:03:50.15 5egSOJea.net
配列でもリンクリストでも他のコレクションでも全てに言えること
「格納要素が『データ本体でも、ポインタでも、何らかのid番号でも、他のインデックス番号でも、』そこは一切関係なく、様々な操作のオーダーOが変わることはない」
まずこの大原則をID:HWCOZSD4は理解できていないのたろう
だからポインタを使うと魔法のようにオーダーがO(1)になる
245:と勘違いしている
246:デフォルトの名無しさん
21/11/22 20:04:15.63 HWCOZSD4.net
>>239
今回例としてあげたのはそういうケース。
ただそれは一例であってさまざまなケースがある。
247:デフォルトの名無しさん
21/11/22 20:04:48.66 HWCOZSD4.net
>>240
アホか。
俺は現実世界では天才と言われてるのに。
248:デフォルトの名無しさん
21/11/22 20:05:43.93 fRCpO7Rh.net
>>241
この一例もやはりRustでは実装できないのでしょうか
249:デフォルトの名無しさん
21/11/22 20:07:17.81 HWCOZSD4.net
>>243
読み込みオンリーに限定して、一切削除もしないという条件なら可能。
ノードの中に書き込んだり、ノードを削除するなら、不可能。
250:デフォルトの名無しさん
21/11/22 20:08:42.39 HWCOZSD4.net
>>244
[補足]
C/C++/Java/C#/JS/Ruby/Python など多くの言語では可能だが、Rust
だけが不可能。
なので、Rustだけが仲間はずれであり、他の言語でできる事ができない。
251:デフォルトの名無しさん
21/11/22 20:10:06.74 5egSOJea.net
>>243
C言語で可能なことはRustでも可能
>>244
嘘つき
252:デフォルトの名無しさん
21/11/22 20:11:54.24 4Q+A1yLL.net
>>236
gistでもどこでもいいからコード貼り付けてリンクここに貼ってください
日本語でうだうだ話すより議論が早く終わるでしょうあなたの言うことが正しければ
253:デフォルトの名無しさん
21/11/22 20:14:36.47 EEj8G+es.net
>>245
Rustでプログラミングをしたこともない人がデタラメな妄想を撒き散らしてるなｗ
254:デフォルトの名無しさん
21/11/22 20:14:53.48 HWCOZSD4.net
>>246
デタラメ一言ってんじゃないぞ!!
>>247
具体例を書いても、それはレアケースだの、本質的にはリンクリストの速度では
間違った評価が下るだけ。
そもそも、極簡単な話を書いてるのに理解できないのにコードを書いても理解できる
とは思えない。
そもそも、ランダムアクセスの意味すら理解出来て無い、ここの人達は。
255:デフォルトの名無しさん
21/11/22 20:15:30.95 HWCOZSD4.net
>>248
うそつきは黙れ。
256:デフォルトの名無しさん
21/11/22 20:18:44.14 HWCOZSD4.net
>>246
>>244 は、Rustの借用規則からそうなってる。
257:デフォルトの名無しさん
21/11/22 20:21:30.15 4Q+A1yLL.net
そもそもRustだって最悪UnsafeCell使えば1変数への多数読み書き参照は保持できるのだが
258:デフォルトの名無しさん
21/11/22 20:27:13.86 4Q+A1yLL.net
>>249
僕はリンクリストの速度がどうこう評価するつもりはあんまりなくて、
他言語で書かれたソースコードが本当にRustでは無理なのかを確認したいだけ
だから、その「Rustでは無理なコード」を見てみたい、と言っている
最悪ソースコードの中身は理解不能なものでもよい
259:デフォルトの名無しさん
21/11/22 20:27:43.67 43z4eYfr.net
>>249
説明するつもりもないのに、お前らはどうせ理解もできないバカだ、俺はいつも数学100点の天才だ、俺を信じろ
とか言ってても狂人扱いされるだけに決まってるじゃん・・・
260:デフォルトの名無しさん
21/11/22 20:29:18.57 0LbM6y2O.net
Cursorを使えと何回言っても聞かない
テキストエディタの例では>>119のアイデアを完全無視
261:デフォルトの名無しさん
21/11/22 20:50:09.64 MtEs+7mt.net
おれも興味があるな
C++では書けてRustでは書けないコード
リソースを無視すればチューリング完全だろうから
書けないなんて事はないはずで
何かしら制限を付けた上での「書けない」なんだろうけど
262:デフォルトの名無しさん
21/11/22 20:55:11.07 fRCpO7Rh.net
>>245
Rust でも書けるように思えてしまったのですが、以下のコードはどこが間違っているのでしょうか
URLﾘﾝｸ(play.rust-lang.org)
263:デフォルトの名無しさん
21/11/22 21:10:18.70 ejqG4gpN.net
>>216
プログラマを守るためそれをさせないのがRustっていう言語ではｗ
Rc<RefCell>ではいかんの？
URLﾘﾝｸ(play.rust-lang.org)
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:デフォルトの名無しさん
21/11/22 21:13:26.74 7gi7NmEv.net
>>255
Cursorでも無理だ。
265:デフォルトの名無しさん
21/11/22 21:14:06.15 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:デフォルトの名無しさん
21/11/22 21:17:24.64 DZQ1+JmR.net
Rustの実装 (>>257) はポインタでの直接アクセスではなく配列への添え字アクセスだからオーバーヘッドが大きいとか言い出したらみんなで笑ってあげましょう
267:デフォルトの名無しさん
21/11/22 21:26:20.75 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:デフォルトの名無しさん
21/11/22 21:27:13.68 7gi7NmEv.net
>>261
ゼロコストが謳いなのに、ゼロコストで無い。
269:デフォルトの名無しさん
21/11/22 21:27:14.40 5egSOJea.net
>>257
それで実装も動作も良いけど
_bはどちらも不要
_a.0と_a.1はそれぞれprevとnextと書いたほうが読みやすい
270:デフォルトの名無しさん
21/11/22 21:33:11.94 fRCpO7Rh.net
>>264
_b は単一の要素が複数のリストに属するという要件に対する実装ですね
面倒だったのでメンバーだけ用意して実装はしてないですが
タプル使ってるのも構造体定義が面倒だったため
というかできるできないを実証するための例なので細かいところは適当です
お好きなように修正してください
>>263
>>245 の
> C/C++/Java/C#/JS/Ruby/Python など多くの言語では可能だが、Rust
だけが不可能
> なので、Rustだけが仲間はずれであり、他の言語でできる事ができない。
というのはほかの言語ではゼロコストで実装できることを意味していますか？
それともRustでも実装できることを認めた上でのただの負け惜しみですか？
はたまたこれを書いたのは自分とは別の人と主張されるのでしょうか
271:デフォルトの名無しさん
21/11/22 21:34:40.04 fRCpO7Rh.net
>>262
ゼロコストを定義してください
272:デフォルトの名無しさん
21/11/22 21:37:06.49 7gi7NmEv.net
>>265
後半のあなたの主張、おかしくないか。
Rustの参照では無い独自の参照風の様な構造を添え字番号で実装してしまって、
C言語より速度を落としているのだから、ゼロコスト性に反してる。
273:デフォルトの名無しさん
21/11/22 21:38:01.88 7gi7NmEv.net
>>266
参照に関しては、参照がC言語の生ポインタと同じ速度で扱えること。
274:デフォルトの名無しさん
21/11/22 21:38:56.97 fRCpO7Rh.net
>>267
あらゆる言語の中でRustだけが実装できないという主張は撤回されて
CにRustは劣るという主張へと変更されるのですね？
275:デフォルトの名無しさん
21/11/22 21:49:14.11 EEj8G+es.net
>>257
elements_aはinto_iterにしたらあかんの？と思ったけど
2つ持った時の前半用として用意した意味なのかw
276:デフォルトの名無しさん
21/11/22 21:56:48.89 7gi7NmEv.net
>>269
1. データを格納している場所が配列になっているが、動的に長さを長くしようとすれば
動的配列と同様のコピー動作が生じてしまうから、その実装は、本来のLinkedListの
性質とはかなり異なる。リンクリストは速度的に安定である事が重要なのに、
この性質により、動的配列と同様に、時々大規模コピーが生じて、スパイク的に
速度が遅くなる減少を伴うことになってしまう。このようなスパイク的な
速度低下は、twitterかFacebook のどちらか忘れたが、どっかのSNSでも問題
になっていた。
2. アクセスするときに、番号を配列のアドレスに変換する動作を毎回行っている。
277:デフォルトの名無しさん
21/11/22 22:00:19.83 7gi7NmEv.net
>>271
[補足]
誤解を招いて議論に混乱を来たしそうなので捕捉しておくと、
271の2で書いた「番号」は、リンクリストの先頭からの通し番号の事ではなく、
今回示されたリンクリスト風のコードで、内部で用いられている配列の添え字番号
のことで、リンクリストの先頭からは、辿っていっても、連続した番号には成ってないもの。
278:デフォルトの名無しさん
21/11/22 22:05:48.24 fRCpO7Rh.net
>>271
あらゆる言語で実装できないがRustでは実装できない
他の言語だと O(1) だが Rustだと O(N) になる
という主張を撤回されたと理解しました
そういうことでしたら私の方から言うことはなにもありません
またアロケーションについてはVecを実装が工夫されたコンテナ型に変えることで対応できそうですね
実装詳細のないまま議論してもしょうがないトピックなのでこれ以上こちらからレスを重ねることはやめます
ありがとうございました
279:デフォルトの名無しさん
21/11/22 22:10:00.62 7gi7NmEv.net
>>271
[追加]
3. そこにさらに削除メソッドを実装したとしよう。
削除したノードに対する番号が、どこかのCursorの中にまだ生きた状態に
なっている場合、ダングリング参照と似た現象が起きる。
削除したノードの中を参照できてしまうのだ。
280:デフォルトの名無しさん
21/11/22 22:15:27.68 7gi7NmEv.net
>>273
その主張、Rustの中に超軽量のインタプリタの様なものを載せておいて、
そのインタプリタの中ではランダムアクセスがO(1)のリンクリストが
完全に実装できることを示しただけだね。
しかも、追加すると、時々、大規模なメモリーコピーが生じるし。
newやmallocではそのようなメモリーコピーは生じない。
ノードを追加しても、リンクリスト中の他のノードの本当のマシン語レベルでの
線形アドレスが固定で変化し無いし。
あなたの実装では、それが変化してしまう。相対アドレスは変化しないが。
ベースアドレスが変化している。
281:デフォルトの名無しさん
21/11/22 22:19:00.36 fRCpO7Rh.net
>>274
generational arenaという手法を利用することでダングリングポインタ的アクセスを検知してハンドリング可能になります
282:デフォルトの名無しさん
21/11/22 22:19:03.44 7gi7NmEv.net
>>274
[補足]
実質的なダングリング参照が起きるということは、Rustのもう一つの柱である
ところのメモリー安全性が部分的に壊れてしまってるということだ。
283:デフォルトの名無しさん
21/11/22 22:23:12.75 7gi7NmEv.net
>>276
動的コストを掛けていいなら、C++でも安全性の高いものは作れるぞ。
ポインタも正しいメモリーブロックを指していることを動的に確認した後で
実際に参照するようなことは、C++でも出来るから。
Rustも配列の範囲チェックはやっているが、配列以外のアドレスでも、動的に
チェックしようと思えばいろいろなチェック法はある。
その一つの方法が、アドレスではなく、あなたが書いたような配列の中の
番号方式にしてしまうこと。
番号に対する配列要素がNULLになっていれば、動的にエラーを出力して
アプリを停止させる、などの方法が有る。
284:デフォルトの名無しさん
21/11/22 22:25:32.33 fRCpO7Rh.net
>>278
Rustの zero-cost abstraction はあなたの期待するような物ではありませんでした
残念でしたね
285:デフォルトの名無しさん
21/11/22 22:36:23.68 7gi7NmEv.net
>>265
>>
286:C/C++/Java/C#/JS/Ruby/Python など多くの言語では可能だが、Rust だけが不可能 >> なので、Rustだけが仲間はずれであり、他の言語でできる事ができない。 >というのはほかの言語ではゼロコストで実装できることを意味していますか？ >それともRustでも実装できることを認めた上でのただの負け惜しみですか？ 分かった。ゼロコストで無くて良いなら Rustでも実装できるということだね。 なるほど、今回の実装法のような裏技の発想は無かったよ。それは認める。 でも、ゼロコストでなくなるということは、RustがC/C++の代替になるという 説には反することになるね。 それと、C++, Java, C# では最初から標準ライブラリ的なもので最初から実装済み なのに対して、あなたのやり方は、少なくとも標準のLinkedListではないね。 Cursorも標準のものとは別。
287:デフォルトの名無しさん
21/11/22 22:37:35.24 0LbM6y2O.net
結局何がしたいのよ
ノードへの参照を持ったままリストを変更したいの？
288:デフォルトの名無しさん
21/11/22 22:44:50.09 7gi7NmEv.net
>>281
何がしたいって、C/C++/C#/Javaでは、LinkedListへのアクセスがO(1)で
自由自在に出来るのに、標準のRust実装では出来ないことが問題なんだ。
それに、今回示された実装法では、内部では配列で実装されているから、
ノードを追加してい言って、配列の要素数を超える時には、新しい配列を
コピーして内部でコピー動作が生じる。これは、C++のnewよりも遥かに
遅い動作になってしまうし、スパイク的に時々生じるから速度的な安定性
が求められるソフトでは好ましくない現象。
また、実質的なダングリング参照的が生じることも指摘した。
結論は、このやり方で、C/C++などと同じO(1)にはなったものの、安全性も失われ、
ゼロコスト性も失われ、C/C++の実装に比べて速度的に不安定でありスパイク的に
遅くなるということだ。
289:デフォルトの名無しさん
21/11/22 22:51:04.06 0LbM6y2O.net
>>282
「LinkedListへのアクセスがO(1)で自由自在に出来る」
が正確にはどういう意味かと聞いているんだ
>>257の実装は忘れなさい
290:デフォルトの名無しさん
21/11/22 22:52:27.47 7gi7NmEv.net
>>281
>ノードへの参照を持ったままリストを変更したいの？
もちろん、それもある。
291:デフォルトの名無しさん
21/11/22 22:56:03.63 qBbb57Hy.net
デマを流すのはゼロコストなんだから相手にした時点で負け
292:デフォルトの名無しさん
21/11/22 22:57:09.11 7gi7NmEv.net
>>283
>「LinkedListへのアクセスがO(1)で自由自在に出来る」
>が正確にはどういう意味かと聞いているんだ
Cの場合、ポインタでアクセスすれば、O(1)でリンクリストの
ノードを参照できるし、削除も出来る。
削除しても、他のノードのアドレスは変化しないから、ポインタも
書き換える必要も無い。
配列だったら、削除するとそれより後ろのノードの番号が全て
変化してしまうので、書き直さなくてはならない。
リンクリストでも、先頭からの通し番号を識別番号に
している場合には、同様にそれ以後のノードの全ての番号を書き換えないといけない。
リンクリストのノードにO(1)でアクセスするというのは、ポインタでアクセスすれば
当たり前の事で、どう説明していいのか分からない。マシン語では、間接参照の
[アドレス]
だけの話だから。
コンピュータの基礎から学び直してもらわないと理解してもらえないかも知れない。
マシン語を学んで欲しい。
293:デフォルトの名無しさん
21/11/22 22:57:21.67 0LbM6y2O.net
コンテナと各要素の&mutと&が同時に取れない件はsplitして借用の単位を分けるべし
Vec::split_at_mutと同様の発想
294:デフォルトの名無しさん
21/11/22 22:59:22.03 0LbM6y2O.net
>>286
だからそれだけならCursorMutでできるんだって
でもダメなんだろ？
それはなぜ？
295:デフォルトの名無しさん
21/11/22 23:01:06.85 7gi7NmEv.net
>>285
どっちがデマだと思ってるのか知らんが、俺のはデマじゃないぞ。
実際に、今回の実装を示した彼は、俺の言ってることはある程度正しく理解していた。
つまり、基本的にデマじゃないということを理解した人がいるということだ。
ただし、彼は、ゼロコスト安全性である、ということを無視して独自実装したり、
参照を独自に修正したものを勝手に導入した誤魔化しがあったのが残念であった
だけだ。
つまり、俺の主張自体は、彼は本当は理解している。
理解しているが、悔し紛れに詐欺めいた独自実装をしたことだけが残念なだけだ。
296:デフォルトの名無しさん
21/11/22 23:01:57.98 7gi7NmEv.net
>>288
1つのリンクリストに対して、書き込み参照や読み込み参照を同時に複数持てない。
297:デフォルトの名無しさん
21/11/22 23:13:17.79 5egSOJea.net
>>290
デマを流すのはそろそろやめとけよ
RustはRefCellもあるし複数からポインタで指しつつ書き換えもできるぞ
298:デフォルトの名無しさん
21/11/22 23:14:41.21 7gi7NmEv.net
>>291
そもそも、RefCellは、動的チェックが入るからゼロコストではない。
C には存在しないコストが新たに導入される。
299:デフォルトの名無しさん
21/11/22 23:15:37.93 WXoW4mOX.net
unsafe で生ポインタ使えばCと同じ実装は確実にできるが
300:デフォルトの名無しさん
21/11/22 23:15:41.59 NDd1353W.net
リンクトリストな？
301:デフォルトの名無しさん
21/11/22 23:16:05.08 5egSOJea.net
>>292
何を言ってるんだ？
そういうコストかけずにどうやって排他制御するんだよ？
302:デフォルトの名無しさん
21/11/22 23:18:27.46 WXoW4mOX.net
>>295
そこはCだとプログラマが気をつけることで排他制御してるんだと思うよ
unsafe Rustでも同じだけど
303:デフォルトの名無しさん
21/11/22 23:18:40.37 7gi7NmEv.net
>>295
C++と同じ事が出来るのに「ゼロコスト」で「安全」、と謳ってるのが間違いだと
言ってる。
間違いというより、デマや誇大宣伝。
304:デフォルトの名無しさん
21/11/22 23:21:22.25 0LbM6y2O.net
>>290
そうだ、最初からそう言えばよかったんだ
蓋を開けてみればO(1)なんかまるで関係無いじゃないか
でそれに対して>>287という策があるわけだがどう思う？
305:デフォルトの名無しさん
21/11/22 23:22:12.49 7gi7NmEv.net
>>295
「排他制御」とは、マルチスレッドプログラミングで使う用語なのだが、
本当にその意味で使ってるか？
306:デフォルトの名無しさん
21/11/22 23:22:18.49 EEj8G+es.net
>>292
ゼロコストって他のことでもそうだけど全くコストがかからないってことではない
必要最低限のことのみでそれ以外はゼロコストってこと
今回のRefCellならば並行プログラミングの時の書き換え競合が起きないことを保証する
RefCellはゼロコスト
ゼロコストでないと主張するならば他の対処方法を述べよ
307:デフォルトの名無しさん
21/11/22 23:24:19.66 7gi7NmEv.net
>>298
「策」があるっていうが、どんどん複雑化し、コストも増えているだろ。
308:デフォルトの名無しさん
21/11/22 23:28:31.00 7gi7NmEv.net
>>300
俺も正直言うとRefCellとか出てくると複雑すぎてよくわからなくなってくるが、
RefCellは内部可変性に対するものだから、並行プログラミングを使わない時
にも使うことがあるはずだが。
309:デフォルトの名無しさん
21/11/22 23:28:31.66 NDd1353W.net
Rustは安全性を追求した言語でC++と比較する物ではない。
比較するならRubyが妥当。
310:デフォルトの名無しさん
21/11/22 23:30:51.55 7gi7NmEv.net
>>303
つまり、CやC++の代替には成りえない。
アプリレベルであってもC/C++の全てをカバーすることは出来ない。
311:デフォルトの名無しさん
21/11/22 23:33:19.88 WXoW4mOX.net
コンパイラに安全性を保証してほしければ実行時のコストを払ってRefCellを使えばいいし、
そのコストを払いたくなければunsafe 使って自分で安全性を保証すればいいって話なんだが
312:デフォルトの名無しさん
21/11/22 23:35:15.39 4Q+A1yLL.net
必要最低限のunsafeを使うのは大前提で、
それでもリンクリストがどうたらって話じゃなかったっけ・・・？？
313:デフォルトの名無しさん
21/11/22 23:36:31.09 NDd1353W.net
だからリンクトリストな？
314:デフォルトの名無しさん
21/11/22 23:38:22.71 5egSOJea.net
>>299
シングルスレッドマルチタスクでも競合は起き得る
そのため書き込み権限がある者がある瞬間に複数存在しないことを保証する(排他制御)ためにRefCellがある
マルチスレッドの場合は並列に起き得るからもっと厳しくてRefCellではダメでMutexやRwLockを使う
315:デフォルトの名無しさん
21/11/22 23:39:08.56 NDd1353W.net
Rustは安全性を追求した言語でC++と比較する物ではない。
比較するならVBAが妥当。
316:デフォルトの名無しさん
21/11/22 23:40:06.95 NDd1353W.net
RustがC++をライバル視してきて非常にウットオシイ。
貴様のライバルはJavascriptだろ。
317:デフォルトの名無しさん
21/11/22 23:41:22.24 7gi7NmEv.net
>>291
LinkedListの中のノードへの参照を10個持っている状態で、
その参照を使って1個のノードを削除しようとしてコンパイルは通るか？
318:デフォルトの名無しさん
21/11/22 23:42:38.96 0LbM6y2O.net
>>301
safeであるためには必要なコストだと思うけどね
mutabilityが前後のノードに影響するデータ構造だから仕方がない
319:デフォルトの名無しさん
21/11/22 23:44:32.43 5egSOJea.net
>>311
それCでもC++でもダングリングポインタ発生の駄目プログラマーパターン
320:デフォルトの名無しさん
21/11/22 23:49:43.35 7gi7NmEv.net
>>313
そんなことないぞ。
vectorと勘違いして無いか。
321:デフォルトの名無しさん
21/11/22 23:55:11.62 4Q+A1yLL.net
>>311
参照先自体を削除するんじゃなくて、参照先からさらにnextとかprevたどってどっかのノードを削除するってこと？
参照先自体を削除するのはRustに限らず問題でるよね
322:デフォルトの名無しさん
21/11/22 23:58:04.28 7gi7NmEv.net
>>315
参照先を削除するのは普通なことで、安全に行えるぞ。
参照とは、つまり、識別番号の代わりに使うものだからな。
参照はオブジェクトに付けられた名前みたいなもんだから、
逆に言えば、参照先を削除できないなら、削除する方法がほぼ無い。
323:デフォルトの名無しさん
21/11/23 00:00:50.13 1c3aeddQ.net
何の話についてもまずは具体的なC言語のコードを示すべきじゃないかな
そうすればRustのコードを2種類みんなが出してくれるよ
・1つは元のC言語と同じ安全度で場合によってはunsafeを用いて実装
・もう1つはメモリ安全性を保証してunsafeを使わずに実装
つまり「C言語で出来ることはRustで必ず出来る」＋「Rustではメモリ安全性を保証した実装も可能」
明らかにC言語よりもRustの方が能力も高く優れている
324:デフォルトの名無しさん
21/11/23 00:00:51.12 16zHq7La.net
>>314
残り9個の参照はそのノードが削除されたことを知る術がないからダングリングポインタになるってことだろ
325:デフォルトの名無しさん
21/11/23 00:08:02.67 xJBrssBV.net
>>318
本来は、明らかに別のノードであれば問題ない。
C++では普通に安全にそれが行える。
リンクリストの中に、A, B, C という名前の人のデータが入っていて、
それぞれに対して1つずつそれぞれ、ポインタ pA, pB, pC が存在している時に
ポインタ pA を介してAを削除しても、B, C へのポインタ pB, pC は残っていて、
値も変更されることも絶対に無いから完全に安全。
Aさんのデータを削除する場合にはこのようなことが起きるが、その時には、
delete pA の後、pAを捨ててしまうだけで全く安全。
pB, pC は何事も無くまったく安全に残せるし、何のバグも入らない。
こんな単純なロジック、何の問題も無い。
326:デフォルトの名無しさん
21/11/23 00:15:34.94 8Ju98kPx.net
同一のノードに10個の参照って意味ちゃうん？
327:デフォルトの名無しさん
21/11/23 00:16:47.17 1c3aeddQ.net
>>319
それだと>>311の条件を満たしていないのでやり直し
・いずれにせよC/C++で書けるコードはそのままの形でそのままの安全度で必ずRustでもunsafeを用いて書ける
・更にRustでは安全性を保証する形でunsafeを用いずに実装することもできる
C/C++よりもRustのほうが明白に能力が高い
328:デフォルトの名無しさん
21/11/23 00:20:07.35 xJBrssBV.net
>>320
1つのリンクリストの異なる10個のノードに対する10個の参照。
329:デフォルトの名無しさん
21/11/23 00:21:41.44 /rTkTwIT.net
>>319
C++でノードへのポインタは実装依存な方法でしか取れないよ
pAその他は本当にポインタ？イテレータではなく？
330:デフォルトの名無しさん
21/11/23 00:21:54.64 xJBrssBV.net
>>321
何度もしているが、それはフェイク。
Cできることのうち、Rustでは追加コストを掛けずにはsafeモードで出来ないことはたくさん有る。
unsafeモードを使いまくれば別。
しかしそれではRustを使う意味が無い。
331:デフォルトの名無しさん
21/11/23 00:22:40.62 xJBrssBV.net
>>323
C++ではなく、Cのリンクリストで考えよう。C++は別の複雑さを入れ込んだから。
332:デフォルトの名無しさん
21/11/23 00:22:46.42 s6k3uLQ1.net
>>324
なぜRustを使う意味がないのですか
333:デフォルトの名無しさん
21/11/23 00:25:21.42 xJBrssBV.net
>>326
Rustの売りはゼロコスト+安全性にあるからだよ。
どちらが掛けても意味が無い。
ゼロコストで無いなら既にC#やJavaがある。
安全で無いなら既にC++がある。
334:デフォルトの名無しさん
21/11/23 00:26:18.34 6/+wazXE.net
ああ、なるほど
安全性を考慮していないCのLinked Listと、安全性が保証されたRustのLinked Listを比較して、
Rustは遅い、できることが少なくて不便だ、みたいなことを述べてたわけか
Cでもメモリリークしないようにして、スレッドセーフにするとかしたら、途端に大変になりそう
335:デフォルトの名無しさん
21/11/23 00:26:36.02 s6k3uLQ1.net
>>327
違いますよ
336:デフォルトの名無しさん
21/11/23 00:27:06.93 8Ju98kPx.net
>>324
リンクトリスト内のメソッドでunsafeを閉じ込めることできると思うんだけどそれではだめなのか
337:デフォルトの名無しさん
21/11/23 00:28:01.20 8Ju98kPx.net
なんなら>>330は「基本的な操作のメソッドは」ってしてもいいけど
338:デフォルトの名無しさん
21/11/23 00:31:19.33 xJBrssBV.net
>>330
複数のノードへの読み書き自由なアクセスの速度をO(1)を保ったままで、
RustではunsafeをLinkedListのメソッド内には閉じ込めることが基本的に
出来ない。基本的に、と言ったのは、先ほど彼が示したリンク先の独自
実装の様に、ゼロコストであることを諦めてコストを掛ければできる
ようになるから。ただし、その場合、スパイク的にO(N)の時間でコピー
動作が発生してしまう。
339:デフォルトの名無しさん
21/11/23 00:32:59.52 xJBrssBV.net
>>332
[補足]
スパイク的なコピーの発生だけでなく、普段からコスト増加もある。
ベースアドレス + 相対アドレスでアクセスするから。
340:デフォルトの名無しさん
21/11/23 00:38:03.01 1c3aeddQ.net
>>262
その人が作ったLinkedList実装がポインタではなく格納配列のインデックスを使っているだけだよ
Rustの標準ライブラリのLinkedList実装ではポインタを使っています
std::collections::LinkedList
URLﾘﾝｸ(doc.rust-lang.org)
341:デフォルトの名無しさん
21/11/23 00:39:30.31 xJBrssBV.net
>>334
それは分かってる。
で、標準の方は、ノードのアクセス速度に問題がある。
342:デフォルトの名無しさん
21/11/23 00:43:10.08 qrGqDm2c.net
>>335
RustはLinkedListでも問題を感じたことがないですが何を根拠に？
343:デフォルトの名無しさん
21/11/23 00:49:14.22 xJBrssBV.net
>>336
1つのリンクリストの異なる10個のノードに対する10個のmut参照を同時
に持ち事は出来ないので、O(1)でアクセスできないからだ。
344:デフォルトの名無しさん
21/11/23 01:04:38.76 qrGqDm2c.net
>>337
意味がわからないので具体的に意味のあるCコードを書いて
345:デフォルトの名無しさん
21/11/23 01:08:49.01 8Ju98kPx.net
Rustだと確かに複数個所のノードへの可変参照を得るのはunsafeメソッドになるだろうね
そのノードが全部別々であることが保証できないから
でもそれは他の言語でも同じで、例えば1のノードに複数の可変参照があって、
1の参照がノード消したらまずことになる
そしてunsafeを許すのなら、内部実装でUnsafe Cell使えばコンパイラからの見た目は不変参照になるから、
オーバーヘッドなしでそういうのは実装可能（ただしstdのLinkedListはそのようにはなっていない）
んで、複数個所のノードへの可変参照を得るというのは相当レアな操作なはずなので、
それはunsafeにしてもAPIの使い勝手としては全然問題はない
346:デフォルトの名無しさん
21/11/23 01:37:22.61 1c3aeddQ.net
あるC/C++コードがあった時
(A) 常にRustではC/C++コードと同じ安全度で(必要時はunsafeを用いて)実装できる
(B) ほとんどのケースでRustでは安全なコードを(unsafeを用いずに)実装できる
つまりRustの能力はC/C++を上回っている
言い換えると
C/C++を捨ててRustを使えば
(B) ほとんどのケースで安全性を保証する形で実装できる
(A) 残りのレアケースでもC/C++と同じ安全度で実装できる
したがってC/C++を用いずにRustを用いたほうがよい
347:デフォルトの名無しさん
21/11/23 05:32:01.67 RKGfozTd.net
安全性よりも、
とにかくパフォーマンスや使用リソースが最重要な用途がある
そういう所でC/C++が使われる
C/C++は少なくとも今後20年は使われ続ける
348:デフォルトの名無しさん
21/11/23 05:47:19.80 qrGqDm2c.net
>>341
RustはC/C++と同じパフォーマンスを出せます
>>340を読みましょ
C/C++からRustへ移ったほうが誰の目にも得です
349:デフォルトの名無しさん
21/11/23 07:27:06.42 RKGfozTd.net
本当に良いことばかりなら
ここで宣伝しなくても自然に広まるはず
350:デフォルトの名無しさん
21/11/23 13:48:55.03 VKZug2mU.net
いや、あわしろ氏もC++は窓から投げ捨てろと言ってる。
351:ハノン
21/11/23 14:00:24.39 A++o7U7T.net
>>344
その、あわしろ氏とやらは、では、なにを推薦しているのでしょうか？
352:デフォルトの名無しさん
21/11/23 14:20:23.73 BTZW3nye.net
ほんとRust気持ち悪いなｗ
リンクリストのような単純な構造でSTLでもboostでもそれ自体が「安全でない」ことはめったにない。
バグや脆弱性を作りこんでしまうのは多くは固定長のバッファに対するパース処理などで、確かに各種の
*nixコマンドなんかはRustで書いて貰ったほうが良い場合があるが、C/C++の数msが致命となる世界で
Rustが一般的となることはない。そんな布教をやってるから嫌われるんだよｗ
悔しかったらOpenSSLとか書き直して”安全なコード”で出してみろよ？WebkitにC/C++を排除させて
Rustだけにさせてみろｗ
353:デフォルトの名無しさん
21/11/23 14:29:53.22 VKZug2mU.net
いまさらC++やってるようでは時代についていけない老害という評価しかない。
354:デフォルトの名無しさん
21/11/23 14:45:56.12 CrSl9z1L.net
Linusも老害だしChromeコミッターも全部老害、気持ち悪さNo1のRustたちが敵を作りまくる自己評価で
あらゆるスレで暴れてる
355:ハノン
21/11/23 14:49:30.08 A++o7U7T.net
>>348
linus を老害呼ばわりするとは…
356:デフォルトの名無しさん
21/11/23 14:56:32.81 s6k3uLQ1.net
>>346
usじゃなくてmsなのか...
357:デフォルトの名無しさん
21/11/23 14:57:43.30 2khltGI7.net
twitterでも、RustはHaskell程度にしか発言されて無い。
一方、C 言語 で検索すると一日分でも見ることが不可能なくらい大量に
発言されてることが分かる。
twitterでは「C++」というキーワードでは検索できないので推定するしかないが、
C 言語以上であろう。
358:デフォルトの名無しさん
21/11/23 15:54:02.42 hMtNqdGd.net
>>340
>つまりRustの能力はC/C++を上回っている
ダウト。
安全面に置いては上回っているが、効率面では下がるケースがかなりある。
359:デフォルトの名無しさん
21/11/23 16:13:02.54 hMtNqdGd.net
・速度を落として安全性を高めたものは、既にJavaやC#がある。
・Rustが仮に速度面ではCに比べて余り遅くならないケースが多いと
仮定しても(この仮定には嘘があるのだが)、使いこなすのがJavaやC#
に比べると難しい。
特に参照関連だけでも、Option, Box, Rc, Arc, Cell, RefCell, Cursor, ref, &
の理解が必要な他、mut &'a などの表記、
let mut a : mut &:T = mut& b
や
Option<Rc<RefCell<T>>> a;
new Box<T>( T {・・・} );
のような解読が難しいシンタックスも多い。
このような複雑な表記は、JavaやC#には存在しない。
また、& と * の違いもあれば、& と ref の違いも有る。
let文ですらパターンマッチング方式になっているので Cのポインタの 10倍理解が難しい。
つまり、普通IQ者には理解が難しい。
逆に高IQ者は、C++でも安全に使えるし、C++を安全面では余り問題を感じて無い人が多い。
360:デフォルトの名無しさん
21/11/23 16:19:09.75 hMtNqdGd.net
>>353
さらに言えば、
・「自動参照外し」は便利だとされるが、逆に勝手に参照が外れることで、
他人の書いたコードの理解が難しいことがある。明記してるコードと
省略してるコードが同じことを意味してるのが理解しにくいので。
・&の意味が、let文の左辺ではパターンマッチング、右辺では参照、
の意味になっているので混乱しやすい。左辺では参照をはずす意味
になってしまう。
・＆は、reference(参照)演算子と呼ばれるのに、ref という演算子もあるが、
これは、意味がかなり違うため、混乱し易い。
・nullポインタを代入するポインタは、Option<Box<T>> のように長くなる。
・ライフタイム注釈が発展途上中なのか、特に構造体に関するライフタイム注釈
のドキュメントが少なく、例で説明されるだけで、根本的な意味を書いた
ドキュメントが存在して無い。
361:ハノン
21/11/23 16:26:18.07 A++o7U7T.net
>>353
IQの定義は？
362:デフォルトの名無しさん
21/11/23 18:18:27.96 VKZug2mU.net
LinuxはRustを第二言語と位置づけ、カーネル開発に積極利用する計画です。
363:デフォルトの名無しさん
21/11/23 18:21:55.09 1c3aeddQ.net
C/C++/Rustをやってきた人ならRustが圧倒的にプログラミングしやすいことで一致している
調査結果でもRustが連続1位を続けていることからも客観的に明白
364:デフォルトの名無しさん
21/11/23 18:23:28.79 VKZug2mU.net
あわしろ氏もC++は終了する言語と言っています。
365:デフォルトの名無しさん
21/11/23 19:08:31.54 s6k3uLQ1.net
>>353
例示してるシンタックス全部間違ってるし釣りだろこれ
366:デフォルトの名無しさん
21/11/23 19:22:32.43 4h9SSBVx.net
>Rustが圧倒的にプログラミングしやすい
うんこ嘘つき野郎
367:デフォルトの名無しさん
21/11/23 19:25:27.46 1ymEsXZx.net
>>359
let mut a : mut &T = mut& b
Box<T>::new( T {・・・} );
だったかも知れんな。
複雑すぎるし、C++との違いが大きすぎて覚えてない。
C++ だと、new クラス名で、Rubyだと確か、クラス名.new。
Rustは、後者に近い書き方だから、書き方だけを見てもRustはC++とはやはり遠い。
368:デフォルトの名無しさん
21/11/23 19:43:48.41 VKZug2mU.net
RustはRubyの影響を受けた言語。
大変使いやすい。
369:デフォルトの名無しさん
21/11/23 19:51:13.12 1ymEsXZx.net
>>362
いくつか本を読んだが、スクリプト言語的な範囲で使うならばそうかも知れん。
しかし、C++やCのようにポインタを駆使したリンクリストやツリー構造の様な
ものを効率よく高速に、メモリーも節約しながら扱うには、Rustはとても
複雑になる。訳の分からんCell,RefCellなどと組み合わせる必要があることも多い。
370:デフォルトの名無しさん
21/11/23 19:53:12.58 /rTkTwIT.net
訳が分かってから文句垂れてください
371:デフォルトの名無しさん
21/11/23 19:59:41.90 VKZug2mU.net
いまどきC++使ってるのは老害でしょう。
すぐにRustを始めるべきです。
372:ハノン
21/11/23 20:09:04.33 A++o7U7T.net
あわしろ氏って、もしかして馬鹿ぁ？
373:デフォルトの名無しさん
21/11/23 21:01:08.57 VKZug2mU.net
低能が何か申しておりますｗ
374:デフォルトの名無しさん
21/11/23 21:24:52.33 dif3t6ob.net
>>364
俺は調査目的で調べてるだけで、実用的に使うつもりはないからな。
375:デフォルトの名無しさん
21/11/23 22:01:53.34 qrGqDm2c.net
>>368
たまに見かける使いこなせなくて脱落したケース？
376:デフォルトの名無しさん
21/11/23 22:12:56.79 WEl5Ae/m.net
あわしろって誰？調べても出てこない
377:デフォルトの名無しさん
21/11/23 23:01:49.38 dif3t6ob.net
>>369
使う必要性を感じない。
378:デフォルトの名無しさん
21/11/24 07:30:28.98 bRL60DLP.net
>>368
であれば、批判する資格はないな
379:デフォルトの名無しさん
21/11/24 10:47:07.21 vbixrgR4.net
>>372
有る。
380:デフォルトの名無しさん
21/11/24 10:49:35.25 kXzWnsgO.net
仮に泡白という人物が実在したとしても
ここで連呼されるのは本人も迷惑してるんじゃないかな
381:デフォルトの名無しさん
21/11/24 11:15:10.51 vbixrgR4.net
Ubuntu Linuxや OpenOffice系の洋書の翻訳家に、
「あわしろいくや」という人物がいるようだ。
382:デフォルトの名無しさん
21/11/24 11:21:34.63 RpLLJ5lb.net
しかもRustやC++の専門家のようには見えんけども…
383:デフォルトの名無しさん
21/11/24 17:09:21.00 5wn/1hS5.net
>>373
CとRustそれぞれでコードを書いてみることをおすすめします
計算量オーダーが変わるアルゴリズムレベルの検討ならともかく
コンパイラの最適化でいくらでも性能が変わりうる実装の詳細についてはまず性能測定するのが常識だと思います
384:デフォルトの名無しさん
21/11/24 17:29:56.67 mlqzRK
385:jQ.net
386:デフォルトの名無しさん
21/11/24 19:53:47.71 6QwWetEE.net
21世紀にもなってC++使ってるのは頭がおかしい。
387:デフォルトの名無しさん
21/11/24 19:54:39.96 6QwWetEE.net
Linusは20世紀の頃からC++は駄目だと言ってた。
天才。
388:デフォルトの名無しさん
21/11/24 22:30:18.26 Vyl+UaHe.net
Rustは言語が汚い。
389:デフォルトの名無しさん
21/11/24 22:43:39.16 RtLWv5R+.net
linusのc++否定ってのは当時の実装のバギーさとオブジェクト指向に対する否定だな。
関数型流行ってる今から見ると割と普通のこと言っとるわ。
390:デフォルトの名無しさん
21/11/24 23:59:24.30 e1u6MioL.net
>>381
むしろ綺麗な方
391:デフォルトの名無しさん
21/11/25 01:15:43.82 /vPuyV+m.net
>>381
言語が汚いってのはよくわからないけど例えばどういうところが汚いと感じたの？
392:デフォルトの名無しさん
21/11/25 01:47:48.10 pEcDGUra.net
でもLinkedList版sliceみたいなのって実現できないのかね
393:デフォルトの名無しさん
21/11/25 02:58:46.76 6PNOZvLH.net
ここまでのまとめ
(1) ほとんどの用途でLinkedListよりVecの方が有用
(2) Rustの標準ライブラリにはLinkedList型もVec型もどちらもある
(3) もしLinkedListやVecを使っても実現できないならまずはそのRustコードを示すべき
(4) 仮に超レアケースがあったとしてもRustでは自分で自由に必要な型を作ればよい
394:デフォルトの名無しさん
21/11/25 07:50:48.33 3Rcu7yrD.net
>>381
アセンブラとチューリングマシン語以外の言語は汚い
395:デフォルトの名無しさん
21/11/25 09:50:29.78 r5Heuy4P.net
LLVM最強ですね判ります
396:デフォルトの名無しさん
21/11/25 16:04:22.18 S6TYxgmH.net
>>386
嘘を書くな。
397:デフォルトの名無しさん
21/11/25 16:33:56.78 sK32tKJd.net
>>389
特に嘘はないと思うけど
stdのLinkedListがちょっと融通利かないところはあるけど
398:デフォルトの名無しさん
21/11/25 16:34:58.88 ug4Dh0aR.net
>>386
様々な言語の中でRustだけ linked list の任意の要素にO(1)でアクセスできないというのは嘘だった
も追加で
399:デフォルトの名無しさん
21/11/25 20:15:57.40 SwFLZgNz.net
macro記述と言語がまるで別言語、いちいちウザいアトリビュート。letは固定を意味するのではなく式展開
何種類もある「文字列」、それに生えている似たようで意味が違ういっぱいのfn（これはトレイトのせい）
わざと敷居を高くしてるとしか思えん
400:デフォルトの名無しさん
21/11/25 20:31:51.42 6PNOZvLH.net
>>392
> letは固定を意味するのではなく式展開
letは常に成功する構造パターンマッチングにすぎないよ
if letは成功か失敗か不明な構造パターンマッチング
今どきの言語ならば左辺値にパターンが書けるのが普通
> 何種類もある「文字列」
文字列はヒープにあり伸縮可能なStringとそうでないstrの2種類しかないよ
ヒープを意識する言語なら2種類ある
あとは文字列の参照として&strがあってその本体はヒープにあろうがなかろうが同じ扱いできるだけ
401:デフォルトの名無しさん
21/11/25 20:38:50.41 pEcDGUra.net
CString
CStr
OsString
OsStr
402:デフォルトの名無しさん
21/11/25 20:58:33.97 88pS2ZzI.net
>>394
それはRustの文字列ではなく単なるFFI
通常のプログラミングでは登場しない
403:デフォルトの名無しさん
21/11/25 21:05:41.06 NJM+Y62L.net
>>391
「任意の」
の定義をしないと無意味な主張
404:デフォルトの名無しさん
21/11/25 21:16:25.34 vljrMlfk.net
じゃあ何種類もあるじゃない、全部が汚いことへの言い訳にしか聞こえない
405:デフォルトの名無しさん
21/11/25 21:25:33.18 88pS2ZzI.net
まとめ
・どの言語でもリンクリストでk番目を得るにはO(n)かかる
・そのk番目を配列で持てばO(1)だがそれはリンクリストではなく配列アクセスのコスト
・リンクリストのk番目を保持する配列を維持するには削除挿入のたびにO(n)の移動が生じる
・これらは言語に依存しない
406:デフォルトの名無しさん
21/11/25 21:33:37.11 /vPuyV+m.net
>>397
言語の汚さというよりもOSなどの環境が抱える複雑さをそのまま見せたらそうなったのでは
407:デフォルトの名無しさん
21/11/25 21:38:29.78 beDf3C1p.net
それが低いレイヤーをやるってことだわな。
それを他の言語のせいにするrust野郎はクソってことだよ。
408:デフォルトの名無しさん
21/11/25 22:13:10.27 88pS2ZzI.net
誤解している人が居るようなので正しい情報
・Rustの通常のプログラミングでCStrやOsStrが出てくることはない
・そこでファイルやディレクトリやソケットを操作してもCStrやOsStrは出てこない
・つまりRustで使う文字列はstrとヒープのStringの2種類しかない
・CStrやOsStrはFFIを書く人のみが用いるのでほとんどの人には無縁
409:デフォルトの名無しさん
21/11/25 22:18:29.72 3Rcu7yrD.net
「通常」の定義は？
410:デフォルトの名無しさん
21/11/25 22:30:32.62 6PNOZvLH.net
>>402
Rustで未だ対応していない未知のものが出現した時にその対応する人だけがCStrやOsStrを用いる
その時のその人を除き、全ての人はCStrやOsStrなんか知らなくてもRustでプログラミング可能
411:デフォルトの名無しさん
21/11/25 23:14:44.56 /vPuyV+m.net
>>401
Pathの操作してるとOsStrは普通に出てくるのでFFIでしか出てこないというのは嘘
412:デフォルトの名無しさん
21/11/25 23:16:52.42 /vPuyV+m.net
他の言語がごまかしている箇所を正確に扱えるのがrustの強みでもありめんどくさいところでもある
413:デフォルトの名無しさん
21/11/25 23:45:28.39 sK32tKJd.net
Rust擁護マンでも標準の文字列（String/str）以外がFFIのみというのはさすがに筋悪に見える
Rustで標準の文字列をUTF8のバイト配列（ヌル文字終端不採用）としたことによる弊害って側面が割と強い
でも他言語みたいにそこしっかりしないとなるとそれはそれでめんどくさいから結局のところトレードオフ
でもOsStrめんどいわ
414:デフォルトの名無しさん
21/11/26 00:54:57.87 Ye0bskEh.net
文字列エンコードを規定しないとそれはそれで移植性に問題あるし難しいところ
WTF-8なる概念必要になったりとにかくWindowsが悪いという気はする
415:デフォルトの名無しさん
21/11/26 03:23:02.14 FqYYA0QW.net
>>391
嘘を書くな。
正しくは、Rustは配列を使って独自実装しないとO(1)には出来無い事が明らかに成った。
参照だと借用規則で出来なくて、配列の添え字番号だと単なる整数なので借用規則の
適用範囲外だからできる。添え字番号をポインタの代わりに使って、独自に
リンクトリストを実装することで初めて、O(1)になる。
しかし、O(1)になっても、「係数」が大きくなり、1アクセスに20クロックくらいかかる。
配列の範囲チェックと、配列アクセスのための乗算と加算が追加で必要になるため。
一方、C、C++、C#、Javaではそんなことしなくても最初からO(1)。
416:デフォルトの名無しさん
21/11/26 03:24:19.18 FqYYA0QW.net
>>398
お前みたいなやつは、一度殴ってやりたい。
匿名掲示板だからと言って、でたらめを書くな！！
ばか者！
417:ハノン
21/11/26 03:25:10.11 xSrpn+m5.net
>>408
C/C++ のリンクリストがどうして O(1) なんですか？
418:デフォルトの名無しさん
21/11/26 03:33:50.05 FqYYA0QW.net
>>398は、数学できない。
細かい点が全然分かって無い。
リンクリストでは、「k番目にアクセスする」と言っても、次の二種類ある。
1. (乱数などで)整数 k
419:を与えられて、ノードを探す。 この場合、どうしても、O(N)、O(k)の時間がかかる。 2. 既に追加したノードを、もう一度アクセスする。 これには、C、C++、C#、Javは、O(1)しかかからない。 しかも、C、C++だと 1 クロック。 Rustだと配列と添え字番号を使って独自実装しなければ、 基本的にO(N)、O(k)かかる。独自実装した場合、 O(1)ではあるが、20～50クロックくくらいかかる。
420:デフォルトの名無しさん
21/11/26 03:34:37.06 FqYYA0QW.net
>>410
>>411を読め。
俺は正直に言っている。また、数学が昔から良くできるので、間違ってない。
421:デフォルトの名無しさん
21/11/26 03:40:28.33 FqYYA0QW.net
>>411
[補足]
実際、>>257 の独自実装は、Rustでも、任意の場所のノードをO(1)で
アクセスできるが、1アクセスあたりに一般的なノードサイズでは
20～50クロック掛かる。
悪いが、QZが出てくると話がややこしくなる。
かわいそうだが、単刀直入にいえば、QZは頭が良くないので、
レベルが全体に下がってしまう。
ようは、レベルが違う人は、教室を分けないとめちゃくちゃに成る。
レベルというのは熟練しているかどうかではなく、生まれつき決まっていて、
直すことが出来ない。
すまん。
422:デフォルトの名無しさん
21/11/26 03:46:37.90 FqYYA0QW.net
>>398
>・どの言語でもリンクリストでk番目を得るにはO(n)かかる
これは間違いである事は何でも説明した。例えば>>411。
>・そのk番目を配列で持てばO(1)だがそれはリンクリストではなく配列アクセスのコスト
これも間違いで、C、C++、Java、C#では、配列で持たずに、直接、ポインタや参照
で持っても、O(1)でアクセスできる。
Rustでは、借用規則が邪魔して、複数の読み書き参照を同時に永続的に保持できないので、
「k」のような番号でしか場所を維持できないため、そんな風になってしまうだけ。
だから、配列と番号を組み合わせてやっとO(1)にできる。
C、C++、Java、C#では、ポインタや参照を永続的にいつまでも保持できるので
配列を使わなくても O(1)でアクセスできる。
その際、「シーク」動作は必要ない。つまり、先頭から k 番目までを辿る必要が
なく、いきなり、k番目に 1 クロックでアクセスできる。
Rustでは、それが、一般的には出来ない。Rustでも、
局所的に1個のノードだけに限定すれば出来る。
423:デフォルトの名無しさん
21/11/26 04:02:58.56 FqYYA0QW.net
例えばこういうことだ。
リンクリストに、
ハンバーガー、りんご、みかん、ドーナツ、パイナップル
の5つを追加したとする。
C、C++、Java、C#では、追加した時に、どこかの5つの変数にこれらの
ポインタを残しておけば、あとから好きなタイミングで、どの
食べ物にも、一瞬でアクセスできる。C、C++では、1クロック。
1番目: ハンバーガー
2番目: りんご
3番目: みかん
4番目: ドーナツ
5番目: パイナップル
3番目のみかんにアクセスするのも、1クロック。
その後に、1番目のハンバーガーにアクセスするのも、1クロック。
その後に、4番目のドーナツにアクセスするのも、1クロック。
例えば、こうだ:
LinkedList ll;
p1 = ll.append("ハンバーガー");
p2 = ll.append("りんご");
p3 = ll.append("みかん");
p4 = ll.append("ドーナツ");
p5 = ll.append("パイナップル");
424:デフォルトの名無しさん
21/11/26 04:03:19.69 FqYYA0QW.net
>>415
[続き]
cout << p3->name; // 1 クロックで3番目のノードのみかんにアクセス。
p3->name="orange"; // 名前を英語に直す。アクセスには1クロックしかかからない。
cout << p1->name; // 1 クロックで1番目のノードのハンバーガーにアクセス。
p1->name="hamburger"; // 名前を英語に直す。アクセスには1クロックしかかからない。
cout << p4->name; // 1 クロックで4番目のノードのドーナツにアクセス。
p4->name="donuts"; // 名前を英語に直す。アクセスには1クロックしかかからない。
書き込みも変更も、アクセスには1クロックずつしか掛からない。
これが、Rustでは借用規則に引っかかるために出来ない。
その結果、標準実装では、k番目のノードに「シーク」する必要があるため、
O(k)や、O(N)の時間が掛かってしまう。
例えば:
cout << seek(ll, 3)->name; // O(N)の時間が掛かる!!
seek(ll, 3)->name="orange"; // O(N)の時間が掛かる!!
425:デフォルトの名無しさん
21/11/26 04:10:09.81 r6ugNRE0.net
>>411
＞2. 既に追加したノードを、もう一度アクセスする。
これカーソルでO(1)でできるって何度も言われてるやんけ
書き換え可能なカーソルを複数持つコードを書くのがめんどくさいってならわかるが
426:デフォルトの名無しさん
21/11/26 04:12:10.51 FqYYA0QW.net
>>
427:416 [補足] cout << aaa; は、分かりにくいが、aaa の内容を表示する、という意味だと思って欲しい。 他の言語だと、print aaa; と書くことが多い。この点 C++ は異質であることは 認める。
428:デフォルトの名無しさん
21/11/26 04:15:36.11 FqYYA0QW.net
>>417
Rustでは、標準 Cursorでは、読み、書き、削除を出来る参照を同時に持つことは出来ない。
C、C++、Java、C#では、
ll.RemoveAt(p2); // p2 のノードを削除。
もアクセス自体は1クロックで出来るし、今示したコードの好きな場所に
追加しても何の問題も無い。
p2は削除されているからアクセスできなくなるだけで、
他のポインタの値は変更されないので、それ以外は何もしなくても
そのままで良い。
429:デフォルトの名無しさん
21/11/26 04:16:36.76 FqYYA0QW.net
>>417
良く確認してくれ。
RustのCursorは、順番に辿ることはできるが、読み込みと書き込みと削除が
出来るタイプの参照を同時に複数記憶することは出来ない。
430:デフォルトの名無しさん
21/11/26 04:18:59.29 r6ugNRE0.net
>>419
標準(std)のLinkedListならそれはそう
前にも言ったような気がするが、
自前で作って内部構造にunsafecellを使えば、
不変参照を複数持っている状態でも書き換えが可能になる
例えば要素の追加時にそういうことをするカーソルを返せばよい
実装がめんどくさすぎるのは認める
431:デフォルトの名無しさん
21/11/26 04:19:23.54 FqYYA0QW.net
>>420
もっと言えば、C、C++、Java、C#の LinkedListは、
p2 の直後に「じゃがいも」ノードを追加した後、
p4 の直前に「トマト」ノードを追加するなどと言ったことも、
O(1)で出来る。しかも、O(1)と言っても、極限的に速くて、
C、C++の場合は、アクセスには1クロック。
こういうことが、Rustでは、Cursorを使っても出来ない。
432:デフォルトの名無しさん
21/11/26 04:23:10.27 FqYYA0QW.net
>>421
>>257のように、遅くするつもりなのか。
1ノードのアクセスに20～50クロックくらい掛かるが。
しかも、ダングリングポインタ、つまり、削除後にアクセスしてしまう
減少を防ぐことが出来なくなってるぞ。
433:デフォルトの名無しさん
21/11/26 04:25:26.12 r6ugNRE0.net
>>423
アンセーフ前提だから>>257とは全然違う
ダングリングも当然防げない（でもそれは他言語でもそう
434:デフォルトの名無しさん
21/11/26 04:29:37.41 FqYYA0QW.net
>>424
>>257 の実装でもそうだが、まだノードAに対する参照がどこかに残っている状態で、
ノードAの中身を削除できて、ノードAが使っていた要素を新規作成ノードのために
使用されてしまうね。
435:デフォルトの名無しさん
21/11/26 04:42:30.98 FqYYA0QW.net
>>420
[RustのCursorの補足]
・書き込み用のCursorを1個でも作ると、読み込み用のCursorは作れない。
はずだ。難しすぎてちゃんと理解して無いことは認める。
436:デフォルトの名無しさん
21/11/26 04:49:17.40 FqYYA0QW.net
>>421
std::cell::UnsafeCell なるものがあるのか。
Rustの参照は種類が多すぎ。
学んでも学んでもキリが無い。
しかも、1つずつをちゃんと理解するのが難しい。
437:デフォルトの名無しさん
21/11/26 09:55:21.11 5+U4u14D.net
>>404
Pathといってもこちらから使うだけならAsRef<Path>だからStringと&strでも全く問題なくOsStringの存在すら知らなくていい
したがって出てくるのはDirEntryのみとなる
それも周り全てUTF8環境ばかりなのでinto_string()で全てSome(String)になるため結局OsStringを扱ったことは一度もない
438:デフォルトの名無しさん
21/11/26 10:08:20.18 5+U4u14D.net
ミスったｗ
ResultのOk(String)ね
439:デフォルトの名無しさん
21/11/26 12:12:39.51 Ye0bskEh.net
>>428
いやいやせっかく標準ライブラリがWindowsでも動くよう苦労してくれてるのにそれを台無しにするなよ
個々のアプリで雑に対処するならともかくRust擁護派がRustの強みを否定してどうする
あと Path::file_name も Option<&OsStr> 返すしこれは利用頻度高い
440:デフォルトの名無しさん
21/11/26 20:45:27.01 MbvsChzk.net
>>430
Rustはちゃんと考えられてるね
ただし自分はWindowsを使うことは100%ないから path.file_name().unwrap().to_str().unwrap() 等でいいし
他にも use std::os::unix::fs::MetadataExt して metadata.uid() 等することもある
441:ハノン
21/11/26 21:02:52.31 xSrpn+m5.net
>>411
リンクリストや広く一般的なデータ構造の空間的・時間的オーダーを語る場合には
ノードの追加
ノードの検索
すでに取得している指定ノードの削除
あたりを考えるのが普通ですが、
「一度取得したノードの再アクセスコスト」を特に取り上げて考えるというのは、確かに rust の特殊性を示しているものといえそうですね…
>>413
生まれてきてすみません…
442:デフォルトの名無しさん
21/11/27 13:14:46.65 Y9o/DNQu.net
>>432
また、話を混乱させている。
指摘していることが、全く的を外しているから。
443:デフォルトの名無しさん
21/11/27 13:16:38.57 Y9o/DNQu.net
ちゃんと正確に議論されているのに、最後の最後でQZがめちゃくちゃな
ことを言い出す。それが最後に書かれたことによって、このスレに
後から来た人には「まとめ」の様に見えてしまうから、大迷惑。
全くまとめになってない、でたらめなことを書くから。
444:デフォルトの名無しさん
21/11/27 13:19:47.46 Y9o/DNQu.net
ようは、秀才達が集まっているクラスで、一人だけレベルの低い人がいて、
秀才達が大体理解したのに、「まとめ」として、レベルの人が全く
デタラメなことを話す。それがQZ。
クラスの場合、みんなの雰囲気でQZがレベルが低いことが分かるので呆れられ、
無視され、せせら笑いが聞こえるが、ネットだとそれが分からないから困る。
現実世界では言葉にしなくても、ひそひそ場なしや、せせら笑いなどで分かるが
ねっとではそのような言外のコミュニケーションが出来ないから。
445:デフォルトの名無しさん
21/11/27 13:22:32.48 Y9o/DNQu.net
>>435
どうせ、QZは、この文書の誤字脱字を発見して馬鹿にするんだろう。
誤字訂正:
誤:レベルの人が全く
正:レベルの低い人が全く
誤:ひそひそ場なしや
正:ひそひそ話や
誤:ねっとでは
正:ネットでは
446:デフォルトの名無しさん
21/11/27 17:31:40.13 v9cw8FEl.net
4レスも使って成果物も作れない評論家様はそびえ立つクソだからなぁ。
>>432のまとめが嫌なら、中身のない4レスのうち1レスを使ってご立派なまとめぐらい書き込んだら？
447:デフォルトの名無しさん
21/11/27 17:48:27.29 d/xEnnZB.net
たしかに4レスも使って人格批判しかしてね～
448:デフォルトの名無しさん
21/11/27 19:00:17.29 tDXnKU/S.net
ID:Y9o/DNQu
こいつがまとめを書けば話は終わりだな
449:デフォルトの名無しさん
21/11/27 19:39:40.61 SLaQ3CeJ.net
あわしろ氏はC++は使わないほうが良いと言ってる。
450:デフォルトの名無しさん
21/11/27 20:00:10.09 WDqbhltk.net
C++をあまり使用してなさそうなよくわからないあわしろ氏でなく自分の意見出しなよ
451:ハノン
21/11/27 20:25:46.13 bCVlBsXA.net
>>433
すみません
>>434-436
生まれてきてすみません…
452:デフォルトの名無しさん
21/11/27 21:09:50.54 riEP2Tv6.net
>>434 >>442
お二人方どちらでもいいから
具体的に削除でダングリングが発生しないCかC++のO(1)コードを示してよ
それが示せない限り机上の空論
もしコードが示されれば対応するRustのコードを出します
453:デフォルトの名無しさん
21/11/27 22:07:53.33 kID5mUHa.net
オブジェクトのアドレスをハッシュテーブルで持たせて、双方向リストで実装。
454:ハノン
21/11/27 22:11:02.52 bCVlBsXA.net
>>443
＞具体的に削除でダングリングが発生しないCかC++のO(1)コードを示してよ
>>432
＞「一度取得したノードの再アクセスコスト」を特に取り上げて考える
という、他ではあまり聞いたことのない特殊な話ゆえに筋を深く追えていないのですが、
>>432
＞