C++ vs Rust

**デフォルトの名無しさん** · 2021/04/24(土) 08:04:49.48

競え

**デフォルトの名無しさん** · 2021/11/23(火) 07:27:06.42

本当に良いことばかりなら
ここで宣伝しなくても自然に広まるはず

**デフォルトの名無しさん** · 2021/11/23(火) 13:48:55.03

いや、あわしろ氏もC++は窓から投げ捨てろと言ってる。

**ハノン** ◆QZaw55cn4c · 2021/11/23(火) 14:00:24.39

>>344
その、あわしろ氏とやらは、では、なにを推薦しているのでしょうか？

**デフォルトの名無しさん** · 2021/11/23(火) 14:20:23.73

ほんとRust気持ち悪いなｗ
リンクリストのような単純な構造でSTLでもboostでもそれ自体が「安全でない」ことはめったにない。
バグや脆弱性を作りこんでしまうのは多くは固定長のバッファに対するパース処理などで、確かに各種の
*nixコマンドなんかはRustで書いて貰ったほうが良い場合があるが、C/C++の数msが致命となる世界で
Rustが一般的となることはない。そんな布教をやってるから嫌われるんだよｗ
悔しかったらOpenSSLとか書き直して”安全なコード”で出してみろよ？WebkitにC/C++を排除させて
Rustだけにさせてみろｗ

**デフォルトの名無しさん** · 2021/11/23(火) 14:29:53.22

いまさらC++やってるようでは時代についていけない老害という評価しかない。

**デフォルトの名無しさん** · 2021/11/23(火) 14:45:56.12

Linusも老害だしChromeコミッターも全部老害、気持ち悪さNo1のRustたちが敵を作りまくる自己評価で
あらゆるスレで暴れてる

**ハノン** ◆QZaw55cn4c · 2021/11/23(火) 14:49:30.08

>>348
linus を老害呼ばわりするとは…

**デフォルトの名無しさん** · 2021/11/23(火) 14:56:32.81

>>346
usじゃなくてmsなのか...

**デフォルトの名無しさん** · 2021/11/23(火) 14:57:43.30

twitterでも、RustはHaskell程度にしか発言されて無い。
一方、C 言語で検索すると一日分でも見ることが不可能なくらい大量に
発言されてることが分かる。
twitterでは「C++」というキーワードでは検索できないので推定するしかないが、
C 言語以上であろう。

**デフォルトの名無しさん** · 2021/11/23(火) 15:54:02.42

>>340
>つまりRustの能力はC/C++を上回っている
ダウト。
安全面に置いては上回っているが、効率面では下がるケースがかなりある。

**デフォルトの名無しさん** · 2021/11/23(火) 16:13:02.54

・速度を落として安全性を高めたものは、既に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++を安全面では余り問題を感じて無い人が多い。

**デフォルトの名無しさん** · 2021/11/23(火) 16:19:09.75

>>353
さらに言えば、
・「自動参照外し」は便利だとされるが、逆に勝手に参照が外れることで、
　他人の書いたコードの理解が難しいことがある。明記してるコードと
　省略してるコードが同じことを意味してるのが理解しにくいので。
・&の意味が、let文の左辺ではパターンマッチング、右辺では参照、
　の意味になっているので混乱しやすい。左辺では参照をはずす意味
　になってしまう。
・＆は、reference(参照)演算子と呼ばれるのに、ref という演算子もあるが、
　これは、意味がかなり違うため、混乱し易い。
・nullポインタを代入するポインタは、Option<Box<T>> のように長くなる。
・ライフタイム注釈が発展途上中なのか、特に構造体に関するライフタイム注釈
　のドキュメントが少なく、例で説明されるだけで、根本的な意味を書いた
　ドキュメントが存在して無い。

**ハノン** ◆QZaw55cn4c · 2021/11/23(火) 16:26:18.07

>>353
IQの定義は？

**デフォルトの名無しさん** · 2021/11/23(火) 18:18:27.96

LinuxはRustを第二言語と位置づけ、カーネル開発に積極利用する計画です。

**デフォルトの名無しさん** · 2021/11/23(火) 18:21:55.09

C/C++/Rustをやってきた人ならRustが圧倒的にプログラミングしやすいことで一致している
調査結果でもRustが連続1位を続けていることからも客観的に明白

**デフォルトの名無しさん** · 2021/11/23(火) 18:23:28.79

あわしろ氏もC++は終了する言語と言っています。

**デフォルトの名無しさん** · 2021/11/23(火) 19:08:31.54

>>353
例示してるシンタックス全部間違ってるし釣りだろこれ

**デフォルトの名無しさん** · 2021/11/23(火) 19:22:32.43

>Rustが圧倒的にプログラミングしやすい
うんこ嘘つき野郎

**デフォルトの名無しさん** · 2021/11/23(火) 19:25:27.46

>>359
let mut a : mut &T = mut& b
Box<T>::new( T {・・・} );
だったかも知れんな。
複雑すぎるし、C++との違いが大きすぎて覚えてない。
C++ だと、new クラス名で、Rubyだと確か、クラス名.new。
Rustは、後者に近い書き方だから、書き方だけを見てもRustはC++とはやはり遠い。

**デフォルトの名無しさん** · 2021/11/23(火) 19:43:48.41

RustはRubyの影響を受けた言語。
大変使いやすい。

**デフォルトの名無しさん** · 2021/11/23(火) 19:51:13.12

>>362
いくつか本を読んだが、スクリプト言語的な範囲で使うならばそうかも知れん。
しかし、C++やCのようにポインタを駆使したリンクリストやツリー構造の様な
ものを効率よく高速に、メモリーも節約しながら扱うには、Rustはとても
複雑になる。訳の分からんCell,RefCellなどと組み合わせる必要があることも多い。

**デフォルトの名無しさん** · 2021/11/23(火) 19:53:12.58

訳が分かってから文句垂れてください

**デフォルトの名無しさん** · 2021/11/23(火) 19:59:41.90

いまどきC++使ってるのは老害でしょう。
すぐにRustを始めるべきです。

**ハノン** ◆QZaw55cn4c · 2021/11/23(火) 20:09:04.33

あわしろ氏って、もしかして馬鹿ぁ？

**デフォルトの名無しさん** · 2021/11/23(火) 21:01:08.57

低能が何か申しておりますｗ

**デフォルトの名無しさん** · 2021/11/23(火) 21:24:52.33

>>364
俺は調査目的で調べてるだけで、実用的に使うつもりはないからな。

**デフォルトの名無しさん** · 2021/11/23(火) 22:01:53.34

>>368
たまに見かける使いこなせなくて脱落したケース？

**デフォルトの名無しさん** · 2021/11/23(火) 22:12:56.79

あわしろって誰？調べても出てこない

**デフォルトの名無しさん** · 2021/11/23(火) 23:01:49.38

>>369
使う必要性を感じない。

**デフォルトの名無しさん** · 2021/11/24(水) 07:30:28.98

>>368
であれば、批判する資格はないな

**デフォルトの名無しさん** · 2021/11/24(水) 10:47:07.21

>>372
有る。

**デフォルトの名無しさん** · 2021/11/24(水) 10:49:35.25

仮に泡白という人物が実在したとしても
ここで連呼されるのは本人も迷惑してるんじゃないかな

**デフォルトの名無しさん** · 2021/11/24(水) 11:15:10.51

Ubuntu Linuxや OpenOffice系の洋書の翻訳家に、
「あわしろいくや」という人物がいるようだ。

**デフォルトの名無しさん** · 2021/11/24(水) 11:21:34.63

しかもRustやC++の専門家のようには見えんけども…

**デフォルトの名無しさん** · 2021/11/24(水) 17:09:21.00

>>373
CとRustそれぞれでコードを書いてみることをおすすめします
計算量オーダーが変わるアルゴリズムレベルの検討ならともかく
コンパイラの最適化でいくらでも性能が変わりうる実装の詳細についてはまず性能測定するのが常識だと思います

**デフォルトの名無しさん** · 2021/11/24(水) 17:29:56.67

リンクリストで頑張るより配列のほうが色々捗る場面も多々あるよな
キャッシュが効いてるとこ読むときの速度は目を見張るもんがある
ヒープで飛び飛びになったデータ構造はその点で恐ろしく不利
それを知ってる人は実測した結果で語る

**デフォルトの名無しさん** · 2021/11/24(水) 19:53:47.71

21世紀にもなってC++使ってるのは頭がおかしい。

**デフォルトの名無しさん** · 2021/11/24(水) 19:54:39.96

Linusは20世紀の頃からC++は駄目だと言ってた。
天才。

**デフォルトの名無しさん** · 2021/11/24(水) 22:30:18.26

Rustは言語が汚い。

**デフォルトの名無しさん** · 2021/11/24(水) 22:43:39.16

linusのc++否定ってのは当時の実装のバギーさとオブジェクト指向に対する否定だな。
関数型流行ってる今から見ると割と普通のこと言っとるわ。

**デフォルトの名無しさん** · 2021/11/24(水) 23:59:24.30

>>381
むしろ綺麗な方

**デフォルトの名無しさん** · 2021/11/25(木) 01:15:43.82

>>381
言語が汚いってのはよくわからないけど例えばどういうところが汚いと感じたの？

**デフォルトの名無しさん** · 2021/11/25(木) 01:47:48.10

でもLinkedList版sliceみたいなのって実現できないのかね

**デフォルトの名無しさん** · 2021/11/25(木) 02:58:46.76

ここまでのまとめ
(1) ほとんどの用途でLinkedListよりVecの方が有用
(2) Rustの標準ライブラリにはLinkedList型もVec型もどちらもある
(3) もしLinkedListやVecを使っても実現できないならまずはそのRustコードを示すべき
(4) 仮に超レアケースがあったとしてもRustでは自分で自由に必要な型を作ればよい

**デフォルトの名無しさん** · 2021/11/25(木) 07:50:48.33

>>381
アセンブラとチューリングマシン語以外の言語は汚い

**デフォルトの名無しさん** · 2021/11/25(木) 09:50:29.78

LLVM最強ですね判ります

**デフォルトの名無しさん** · 2021/11/25(木) 16:04:22.18

>>386
嘘を書くな。

**デフォルトの名無しさん** · 2021/11/25(木) 16:33:56.78

>>389
特に嘘はないと思うけど
stdのLinkedListがちょっと融通利かないところはあるけど

**デフォルトの名無しさん** · 2021/11/25(木) 16:34:58.88

>>386
様々な言語の中でRustだけ linked list の任意の要素にO(1)でアクセスできないというのは嘘だった
も追加で

**デフォルトの名無しさん** · 2021/11/25(木) 20:15:57.40

macro記述と言語がまるで別言語、いちいちウザいアトリビュート。letは固定を意味するのではなく式展開
何種類もある「文字列」、それに生えている似たようで意味が違ういっぱいのfn（これはトレイトのせい）
わざと敷居を高くしてるとしか思えん

**デフォルトの名無しさん** · 2021/11/25(木) 20:31:51.42

>>392
> letは固定を意味するのではなく式展開

letは常に成功する構造パターンマッチングにすぎないよ
if letは成功か失敗か不明な構造パターンマッチング
今どきの言語ならば左辺値にパターンが書けるのが普通

> 何種類もある「文字列」

文字列はヒープにあり伸縮可能なStringとそうでないstrの2種類しかないよ
ヒープを意識する言語なら2種類ある
あとは文字列の参照として&strがあってその本体はヒープにあろうがなかろうが同じ扱いできるだけ

**デフォルトの名無しさん** · 2021/11/25(木) 20:38:50.41

CString
CStr
OsString
OsStr

**デフォルトの名無しさん** · 2021/11/25(木) 20:58:33.97

>>394
それはRustの文字列ではなく単なるFFI
通常のプログラミングでは登場しない

**デフォルトの名無しさん** · 2021/11/25(木) 21:05:41.06

>>391
「任意の」
の定義をしないと無意味な主張

**デフォルトの名無しさん** · 2021/11/25(木) 21:16:25.34

じゃあ何種類もあるじゃない、全部が汚いことへの言い訳にしか聞こえない

**デフォルトの名無しさん** · 2021/11/25(木) 21:25:33.18

まとめ
・どの言語でもリンクリストでk番目を得るにはO(n)かかる
・そのk番目を配列で持てばO(1)だがそれはリンクリストではなく配列アクセスのコスト
・リンクリストのk番目を保持する配列を維持するには削除挿入のたびにO(n)の移動が生じる
・これらは言語に依存しない

**デフォルトの名無しさん** · 2021/11/25(木) 21:33:37.11

>>397
言語の汚さというよりもOSなどの環境が抱える複雑さをそのまま見せたらそうなったのでは

**デフォルトの名無しさん** · 2021/11/25(木) 21:38:29.78

それが低いレイヤーをやるってことだわな。
それを他の言語のせいにするrust野郎はクソってことだよ。

**デフォルトの名無しさん** · 2021/11/25(木) 22:13:10.27

誤解している人が居るようなので正しい情報
・Rustの通常のプログラミングでCStrやOsStrが出てくることはない
・そこでファイルやディレクトリやソケットを操作してもCStrやOsStrは出てこない
・つまりRustで使う文字列はstrとヒープのStringの2種類しかない
・CStrやOsStrはFFIを書く人のみが用いるのでほとんどの人には無縁

**デフォルトの名無しさん** · 2021/11/25(木) 22:18:29.72

「通常」の定義は？

**デフォルトの名無しさん** · 2021/11/25(木) 22:30:32.62

>>402
Rustで未だ対応していない未知のものが出現した時にその対応する人だけがCStrやOsStrを用いる
その時のその人を除き、全ての人はCStrやOsStrなんか知らなくてもRustでプログラミング可能

**デフォルトの名無しさん** · 2021/11/25(木) 23:14:44.56

>>401
Pathの操作してるとOsStrは普通に出てくるのでFFIでしか出てこないというのは嘘

**デフォルトの名無しさん** · 2021/11/25(木) 23:16:52.42

他の言語がごまかしている箇所を正確に扱えるのがrustの強みでもありめんどくさいところでもある

**デフォルトの名無しさん** · 2021/11/25(木) 23:45:28.39

Rust擁護マンでも標準の文字列（String/str）以外がFFIのみというのはさすがに筋悪に見える
Rustで標準の文字列をUTF8のバイト配列（ヌル文字終端不採用）としたことによる弊害って側面が割と強い
でも他言語みたいにそこしっかりしないとなるとそれはそれでめんどくさいから結局のところトレードオフ

でもOsStrめんどいわ

**デフォルトの名無しさん** · 2021/11/26(金) 00:54:57.87

文字列エンコードを規定しないとそれはそれで移植性に問題あるし難しいところ
WTF-8なる概念必要になったりとにかくWindowsが悪いという気はする

**デフォルトの名無しさん** · 2021/11/26(金) 03:23:02.14

>>391
嘘を書くな。
正しくは、Rustは配列を使って独自実装しないとO(1)には出来無い事が明らかに成った。
参照だと借用規則で出来なくて、配列の添え字番号だと単なる整数なので借用規則の
適用範囲外だからできる。添え字番号をポインタの代わりに使って、独自に
リンクトリストを実装することで初めて、O(1)になる。
しかし、O(1)になっても、「係数」が大きくなり、1アクセスに20クロックくらいかかる。
配列の範囲チェックと、配列アクセスのための乗算と加算が追加で必要になるため。

一方、C、C++、C#、Javaではそんなことしなくても最初からO(1)。

**デフォルトの名無しさん** · 2021/11/26(金) 03:24:19.18

>>398
お前みたいなやつは、一度殴ってやりたい。
匿名掲示板だからと言って、でたらめを書くな！！
ばか者！

**ハノン** ◆QZaw55cn4c · 2021/11/26(金) 03:25:10.11

>>408
C/C++ のリンクリストがどうして O(1) なんですか？

**デフォルトの名無しさん** · 2021/11/26(金) 03:33:50.05

>>398は、数学できない。
細かい点が全然分かって無い。
リンクリストでは、「k番目にアクセスする」と言っても、次の二種類ある。
1. (乱数などで)整数 k を与えられて、ノードを探す。
　この場合、どうしても、O(N)、O(k)の時間がかかる。
2. 既に追加したノードを、もう一度アクセスする。
　これには、C、C++、C#、Javは、O(1)しかかからない。
　しかも、C、C++だと 1 クロック。
　Rustだと配列と添え字番号を使って独自実装しなければ、
　基本的にO(N)、O(k)かかる。独自実装した場合、
　O(1)ではあるが、20～50クロックくくらいかかる。
　

**デフォルトの名無しさん** · 2021/11/26(金) 03:34:37.06

>>410
>>411を読め。
俺は正直に言っている。また、数学が昔から良くできるので、間違ってない。

**デフォルトの名無しさん** · 2021/11/26(金) 03:40:28.33

>>411
[補足]
実際、>>257 の独自実装は、Rustでも、任意の場所のノードをO(1)で
アクセスできるが、1アクセスあたりに一般的なノードサイズでは
20～50クロック掛かる。

悪いが、QZが出てくると話がややこしくなる。
かわいそうだが、単刀直入にいえば、QZは頭が良くないので、
レベルが全体に下がってしまう。
ようは、レベルが違う人は、教室を分けないとめちゃくちゃに成る。
レベルというのは熟練しているかどうかではなく、生まれつき決まっていて、
直すことが出来ない。
すまん。

**デフォルトの名無しさん** · 2021/11/26(金) 03:46:37.90

>>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個のノードだけに限定すれば出来る。

**デフォルトの名無しさん** · 2021/11/26(金) 04:02:58.56

例えばこういうことだ。
リンクリストに、
ハンバーガー、りんご、みかん、ドーナツ、パイナップル
の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("パイナップル");

**デフォルトの名無しさん** · 2021/11/26(金) 04:03:19.69

>>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)の時間が掛かる!!

**デフォルトの名無しさん** · 2021/11/26(金) 04:10:09.81

>>411
＞2. 既に追加したノードを、もう一度アクセスする。
これカーソルでO(1)でできるって何度も言われてるやんけ
書き換え可能なカーソルを複数持つコードを書くのがめんどくさいってならわかるが

**デフォルトの名無しさん** · 2021/11/26(金) 04:12:10.51

>>416
[補足]
cout << aaa;
は、分かりにくいが、aaa の内容を表示する、という意味だと思って欲しい。
他の言語だと、print aaa; と書くことが多い。この点 C++ は異質であることは
認める。

**デフォルトの名無しさん** · 2021/11/26(金) 04:15:36.11

>>417
Rustでは、標準 Cursorでは、読み、書き、削除を出来る参照を同時に持つことは出来ない。
C、C++、Java、C#では、
ll.RemoveAt(p2);　// p2 のノードを削除。
もアクセス自体は1クロックで出来るし、今示したコードの好きな場所に
追加しても何の問題も無い。
p2は削除されているからアクセスできなくなるだけで、
他のポインタの値は変更されないので、それ以外は何もしなくても
そのままで良い。

**デフォルトの名無しさん** · 2021/11/26(金) 04:16:36.76

>>417
良く確認してくれ。
RustのCursorは、順番に辿ることはできるが、読み込みと書き込みと削除が
出来るタイプの参照を同時に複数記憶することは出来ない。

**デフォルトの名無しさん** · 2021/11/26(金) 04:18:59.29

>>419
標準(std)のLinkedListならそれはそう

前にも言ったような気がするが、
自前で作って内部構造にunsafecellを使えば、
不変参照を複数持っている状態でも書き換えが可能になる
例えば要素の追加時にそういうことをするカーソルを返せばよい
実装がめんどくさすぎるのは認める

**デフォルトの名無しさん** · 2021/11/26(金) 04:19:23.54

>>420
もっと言えば、C、C++、Java、C#の LinkedListは、
p2 の直後に「じゃがいも」ノードを追加した後、
p4 の直前に「トマト」ノードを追加するなどと言ったことも、
O(1)で出来る。しかも、O(1)と言っても、極限的に速くて、
C、C++の場合は、アクセスには1クロック。

こういうことが、Rustでは、Cursorを使っても出来ない。

**デフォルトの名無しさん** · 2021/11/26(金) 04:23:10.27

>>421
>>257のように、遅くするつもりなのか。
1ノードのアクセスに20～50クロックくらい掛かるが。
しかも、ダングリングポインタ、つまり、削除後にアクセスしてしまう
減少を防ぐことが出来なくなってるぞ。

**デフォルトの名無しさん** · 2021/11/26(金) 04:25:26.12

>>423
アンセーフ前提だから>>257とは全然違う
ダングリングも当然防げない（でもそれは他言語でもそう

**デフォルトの名無しさん** · 2021/11/26(金) 04:29:37.41

>>424
>>257 の実装でもそうだが、まだノードAに対する参照がどこかに残っている状態で、
ノードAの中身を削除できて、ノードAが使っていた要素を新規作成ノードのために
使用されてしまうね。

**デフォルトの名無しさん** · 2021/11/26(金) 04:42:30.98

>>420
[RustのCursorの補足]
・書き込み用のCursorを1個でも作ると、読み込み用のCursorは作れない。

はずだ。難しすぎてちゃんと理解して無いことは認める。

**デフォルトの名無しさん** · 2021/11/26(金) 04:49:17.40

>>421
std::cell::UnsafeCell なるものがあるのか。
Rustの参照は種類が多すぎ。
学んでも学んでもキリが無い。
しかも、1つずつをちゃんと理解するのが難しい。

**デフォルトの名無しさん** · 2021/11/26(金) 09:55:21.11

>>404
Pathといってもこちらから使うだけならAsRef<Path>だからStringと&strでも全く問題なくOsStringの存在すら知らなくていい
したがって出てくるのはDirEntryのみとなる
それも周り全てUTF8環境ばかりなのでinto_string()で全てSome(String)になるため結局OsStringを扱ったことは一度もない

**デフォルトの名無しさん** · 2021/11/26(金) 10:08:20.18

ミスったｗ
ResultのOk(String)ね

**デフォルトの名無しさん** · 2021/11/26(金) 12:12:39.51

>>428
いやいやせっかく標準ライブラリがWindowsでも動くよう苦労してくれてるのにそれを台無しにするなよ
個々のアプリで雑に対処するならともかくRust擁護派がRustの強みを否定してどうする

あと Path::file_name も Option<&OsStr> 返すしこれは利用頻度高い

**デフォルトの名無しさん** · 2021/11/26(金) 20:45:27.01

>>430
Rustはちゃんと考えられてるね
ただし自分はWindowsを使うことは100%ないから path.file_name().unwrap().to_str().unwrap() 等でいいし
他にも use std::os::unix::fs::MetadataExt して metadata.uid() 等することもある

**ハノン** ◆QZaw55cn4c · 2021/11/26(金) 21:02:52.31

>>411
リンクリストや広く一般的なデータ構造の空間的・時間的オーダーを語る場合には
ノードの追加
ノードの検索
すでに取得している指定ノードの削除

あたりを考えるのが普通ですが、

「一度取得したノードの再アクセスコスト」を特に取り上げて考えるというのは、確かに rust の特殊性を示しているものといえそうですね…

>>413
生まれてきてすみません…

**デフォルトの名無しさん** · 2021/11/27(土) 13:14:46.65

>>432
また、話を混乱させている。
指摘していることが、全く的を外しているから。

**デフォルトの名無しさん** · 2021/11/27(土) 13:16:38.57

ちゃんと正確に議論されているのに、最後の最後でQZがめちゃくちゃな
ことを言い出す。それが最後に書かれたことによって、このスレに
後から来た人には「まとめ」の様に見えてしまうから、大迷惑。
全くまとめになってない、でたらめなことを書くから。

**デフォルトの名無しさん** · 2021/11/27(土) 13:19:47.46

ようは、秀才達が集まっているクラスで、一人だけレベルの低い人がいて、
秀才達が大体理解したのに、「まとめ」として、レベルの人が全く
デタラメなことを話す。それがQZ。
クラスの場合、みんなの雰囲気でQZがレベルが低いことが分かるので呆れられ、
無視され、せせら笑いが聞こえるが、ネットだとそれが分からないから困る。
現実世界では言葉にしなくても、ひそひそ場なしや、せせら笑いなどで分かるが
ねっとではそのような言外のコミュニケーションが出来ないから。

**デフォルトの名無しさん** · 2021/11/27(土) 13:22:32.48

>>435
どうせ、QZは、この文書の誤字脱字を発見して馬鹿にするんだろう。

誤字訂正:
誤:レベルの人が全く
正:レベルの低い人が全く

誤:ひそひそ場なしや
正:ひそひそ話や

誤:ねっとでは
正:ネットでは

**デフォルトの名無しさん** · 2021/11/27(土) 17:31:40.13

4レスも使って成果物も作れない評論家様はそびえ立つクソだからなぁ。

>>432のまとめが嫌なら、中身のない4レスのうち1レスを使ってご立派なまとめぐらい書き込んだら？

**デフォルトの名無しさん** · 2021/11/27(土) 17:48:27.29

たしかに4レスも使って人格批判しかしてね～

**デフォルトの名無しさん** · 2021/11/27(土) 19:00:17.29

ID:Y9o/DNQu
こいつがまとめを書けば話は終わりだな

**デフォルトの名無しさん** · 2021/11/27(土) 19:39:40.61

あわしろ氏はC++は使わないほうが良いと言ってる。

**デフォルトの名無しさん** · 2021/11/27(土) 20:00:10.09

C++をあまり使用してなさそうなよくわからないあわしろ氏でなく自分の意見出しなよ

**ハノン** ◆QZaw55cn4c · 2021/11/27(土) 20:25:46.13

>>433
すみません

>>434-436
生まれてきてすみません…

**デフォルトの名無しさん** · 2021/11/27(土) 21:09:50.54

>>434 >>442
お二人方どちらでもいいから
具体的に削除でダングリングが発生しないCかC++のO(1)コードを示してよ
それが示せない限り机上の空論
もしコードが示されれば対応するRustのコードを出します