C++ vs Rust

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

競え

**デフォルトの名無しさん** · 2021/12/05(日) 19:54:51.36

>>823
話が噛み合いませんね、やっぱり私が馬鹿だからなんでしょうかね…
でも、仮にも計算機科学方面から解析を行っていただくのでしたら、C でいいから例示してほしいですよね

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

**デフォルトの名無しさん** · 2021/12/05(日) 22:25:34.77

Ruby のハッシュでは、データ数と共に、バケット数を増やしていく。
バケット数は、2 の累乗の次に現れる素数。
2^n + a, 2 <= n <= 30

8 + 3 = 11
16 + 3 = 19
32 + 5 = 37
64 + 3 = 67
128 + 3 = 131
256 + 27 = 283
512 + 9 = 521

データ数が、バケット数の5倍を超えると、ハッシュが再構成される。
再構成時には、極端に遅くなる

11 * 5 = 55 だから、データ数が56 個になると、バケット数が19 になる。
19 * 5 = 95 だから、データ数が96 個になると、バケット数が37 になる

バケット数は、2 の累乗で大きくなっていくから、
大きいほど、線形(全)探索に比べて、ハッシュが有利

増え方が、N に比例しなくて、log N に比例するから

例えば、2^20 = 百万で、2^21 = 2百万では、
線形探索では毎回、百万回増えるけど、
ハッシュでは、1回だけ再構築して、その後は、21回で見つかる

**デフォルトの名無しさん** · 2021/12/05(日) 22:30:23.53

>>826
Rustのハッシュそうなんだ？

**デフォルトの名無しさん** · 2021/12/05(日) 22:55:00.31

Rubyだぞ

**デフォルトの名無しさん** · 2021/12/05(日) 23:55:41.03

>>817
> ハッシュ構造は、「一回の検索」でも、数学的には、O(N)の時間が掛かる。

ホントですか？
>>826がO(logN)ですよ

**デフォルトの名無しさん** · 2021/12/06(月) 00:01:51.71

ベンチをもっと気楽に行うために単体テストフレームワークを使ってベンチ書いてる。

**デフォルトの名無しさん** · 2021/12/06(月) 00:03:31.65

>>829
O(N)の定義は、Nを無限に大きくしていった時に、処理時間を N で割った時に
ある固定された上限値の定数未満になる、という意味だぞ。
O(log N)のハッシュは有り得ない。

**デフォルトの名無しさん** · 2021/12/06(月) 00:07:28.71

なお、ハッシュ値の最大数を動的に増やしていくのならば、本来のハッシュ構造ではない。
本来のハッシュ構造は振り分けられる量は固定サイズ。
だから、ハッシュ値の計算も固定されたアルゴリズムで処理が固定された関数で
行う。
色々と勝手に定義を変えてはいかん。
言葉を勝手に再定義すれば議論になるわけ無い。

**デフォルトの名無しさん** · 2021/12/06(月) 00:25:08.26

（キリッ）が抜けてるのでは？

**デフォルトの名無しさん** · 2021/12/06(月) 00:25:34.03

リンクリストの次はハッシュテーブルかよ
データ構造スレでやれ

**デフォルトの名無しさん** · 2021/12/06(月) 00:49:48.95

良スレ。
アゲ。

**826** · 2021/12/06(月) 01:37:20.07

>>826
修正

>増え方が、N に比例しなくて、log N に比例するから

>例えば、2^20 = 百万で、2^21 = 2百万では、
>線形探索では毎回、百万回増えるけど、
>ハッシュでは、1回だけ再構築して、その後は、21回で見つかる

これはデータベースで使う、2分探索の事だった。
ハッシュは、バケット数で割った余りで決まるから、O(1)だった

**デフォルトの名無しさん** · 2021/12/06(月) 01:49:17.06

>>836
ハッシュの表の様なものが固定サイズであるところの
素朴なハッシュの検索は、Nが大きい時には、O(N)。N が小さい時には、O(1)。

Nが大きくなるに従ってその表を時々大きくしていくようなものは、
考慮の対象にはしない。

**デフォルトの名無しさん** · 2021/12/06(月) 01:53:00.58

>>837
[補足]
以下、ハッシュの表の様なものが固定サイズであるところの素朴なハッシュの検索
についてだけを考える。
ハッシュの中に入っているデータの個数が N 個の時に、あるキーを持つ
データを1個だけ探すのに掛かる平均時間を g(N)とすると、数学的には
g(N)=O(N)。
しかし、この g(N) は、g(N) = a N + b と近似した場合の a の値が極端に小さい。
なので、N が小さい時には、O(1)であるかのように振舞う。
そういう意味だ。
これで理解できないなら、数学的想像力や理解力が足りてない。

**デフォルトの名無しさん** · 2021/12/06(月) 02:05:17.38

RubyガイジとRustガイジの熱いマッチが今始まる

**デフォルトの名無しさん** · 2021/12/06(月) 02:22:55.84

>>839
この数学100点マンはRustを叩いてる人で常に生ポインタ派のC/C++史上主義な人
ただしコードを出したことがないのでプログラミング能力がないと推定されている
さらにオーダーについても勝手な定義で無茶な主張を繰り返している

**デフォルトの名無しさん** · 2021/12/06(月) 02:24:44.88

>>840
分かっとるわ
語呂がいいからRustガイジって言っただけ

**デフォルトの名無しさん** · 2021/12/06(月) 02:33:01.01

>>840
お前もとことん馬鹿だな。
コード書いても抽象理解が出来ない人には、そのコードの本質は分からんし、
こんなところに書ききれるわけでも無いからかけないだけだ。
なお、抽象 = シンボライズ、シンボリック
という意味で、曖昧や玉虫色という意味では無いぞ。
本質的な部分を記号化、定理化、規則化、一般化して理解できるようにしたもの
を「抽象化」と言う。

**デフォルトの名無しさん** · 2021/12/06(月) 03:29:12.50

linkedlistの計算量を勘違いし
平衡二分木とハッシュセットを混同する
数学100点マンがいると聞いて

**デフォルトの名無しさん** · 2021/12/06(月) 05:30:40.66

>>842
>こんなところに書ききれるわけでも無いからかけないだけだ。
スレじゃなくて、IdeoneとかGihubのgistに書いてもらえれば大丈夫ですよ

**デフォルトの名無しさん** · 2021/12/06(月) 05:43:24.70

>>838
＞、g(N) = a N + b と近似した場合の a の値が極端に小さい。…①
なぜですか？
ハッシュテーブルの実装方法から論じてみください
もしかして、あなたは①を数学の公理、みたいに扱っているのですか？そんなことではコンピューターサイエンスは無意味だし面白くないでしょう？
でもC/C++ 至上主義者というのなら、私と気が合いますね

**デフォルトの名無しさん** · 2021/12/06(月) 08:46:35.08

>>775
MFC(Win32)に関しては、メッセージキューとイベントは別物だぞ。　イベントは、
イベント処理中でも降って来る。

**デフォルトの名無しさん** · 2021/12/06(月) 10:07:17.08

なんでハッシュテーブルの話になったのかと思えば>>813にいちゃもん付けたいだけか

**デフォルトの名無しさん** · 2021/12/06(月) 11:16:09.54

ベンチマークもなしに実時間の話をされてもなぁ
しかも具体的な実装上の問題点の指摘もなく他人のベンチマークは信用できないとか宣われてしまうとこちらとしては会話しても意味がない人なんだと判断せざるを得ないんですよね

**デフォルトの名無しさん** · 2021/12/06(月) 11:52:31.39

>>845
公理ではなくて、処理時間の平均値を確率論で書いている。

**デフォルトの名無しさん** · 2021/12/06(月) 11:57:28.95

>>849
[補足]
確率論で証明することが出来るが、とてもめんどくさいので割愛する。
失礼だが、質問者のレベルから推測すると、ちゃんと書いても理解できない。

**デフォルトの名無しさん** · 2021/12/06(月) 12:01:12.30

>>845じゃないけど
最悪値が重要な用途もある
また、確率はデータの分布が決まってはじめて決まるもの
分布次第ではあなたの想定通りにはならない

**デフォルトの名無しさん** · 2021/12/06(月) 12:06:08.85

>>851
確率論では、ランダム性を仮定する。

**デフォルトの名無しさん** · 2021/12/06(月) 12:43:27.37

>>842
ここはC++ vs Rustスレなのだからコードを出さなければ何も判定できない
机上の空論ばかり書き綴るよりも現実に使われるCPUと向き合わなければならない

例えばRustの標準ライブラリHashMapでも用いているSwiss Tables法ではハッシュ衝突時の別エントリ探索にSIMD命令を用いている
CPU命令4つで16エントリ同時に探索候補を判別していきメモリキャシュも活かすようこのためのメタデータを連続領域に配置している

**デフォルトの名無しさん** · 2021/12/06(月) 13:08:20.11

>>852
値がガウス分布に従うとかなんらかの仮定をおいていると思うのですがあなたの言うランダム性とはなんですか
あらゆる分布を想定しているのですか

**デフォルトの名無しさん** · 2021/12/06(月) 13:21:52.08

>>831
> O(N)の定義は、Nを無限に大きくしていった時に、
コンピュータサイエンスでアルゴリズムの評価をするときは、Nを無限にするなんて考えません
ハッシュアルゴリズムはO(1)でFA

**デフォルトの名無しさん** · 2021/12/06(月) 13:46:42.22

>>848
ずっとそんな感じ
計算量ではちゃんとわからない、コストがかかって遅くなる、とか言いつつ、忙しいから実装はできない、お前は馬鹿だから理解できない、みたいなことを数ヶ月に渡って大量に書き込み続けてる
数学でいつも100点取るらしいし、さぞ偉いお方なんでしょうなあ…

**デフォルトの名無しさん** · 2021/12/06(月) 18:09:07.25

>>854
いまの場合で言えば、N個のキーに対するハッシュ値が、可能な限り重ならずに
分布すること。

**デフォルトの名無しさん** · 2021/12/06(月) 19:52:13.50

>>856
リジェクトされたネタだとか…

**デフォルトの名無しさん** · 2021/12/06(月) 20:04:46.70

>>857
意味不明

**デフォルトの名無しさん** · 2021/12/06(月) 21:08:31.14

ハッシュが衝突しやすいコリジョンデータを使ったDDos攻撃が出来るのでは？

**デフォルトの名無しさん** · 2021/12/07(火) 13:11:29.70

>>854
最大M個の振り分け能力があるハッシュ構造にN個の(key, value)ペアを
書き込んでいる場合を考える。
ただし、Mは定数とし、N が大きくなっても拡張していかないものとする。
このとき、一回の検索に掛かる平均時間をg(N,M)とすると、
ほぼ、
g(N,M)=b・(ceil(N/(2M))
ただし、
・b は、一回の文字列比較に掛かる時間。
・ceil(x)は、xを越えない最小整数。
と書ける。これは、ほぼ、
g(N,M)=b・((int)(N/(2M) + 1)
　　　 =(int)(N/(2M))*b + b
と書ける。Nが大きい時には、
g(N,M)=a*N + b
a = b / (2M)
と書ける。
Mが大きい時、aは、小さいが0ではないので、処理時間は、O(1)ではなく、O(N)である。

**デフォルトの名無しさん** · 2021/12/07(火) 13:27:33.41

Wikipediaでも明記されている
・ハッシュテーブルの検索や追加はO(1)
・ハッシュテーブルの拡張もO(1)

> ハッシュテーブルはキーをもとに生成されたハッシュ値を添え字とした配列である。
> キーを要約する値であるハッシュ値を添え字として値を管理することで、検索や追加を要素数によらず定数時間O(1)で実現する。
>
> 利用率が一定を超えた場合に、より大きいサイズのハッシュテーブルを用意して格納し直す操作が必要となる。これをリハッシュ (rehash) と呼ぶ。
> この操作はすべての要素のハッシュ値を再計算して新たなハッシュテーブルに格納するためO(n)であるが、
> 配列のサイズを指数的に拡張する事で、動的配列の末尾追加操作と同様に償却解析によって計算量をO(1)とみなす事ができる。

**デフォルトの名無しさん** · 2021/12/07(火) 14:35:15.82

>>862
例えば、M=128で、128種類のハッシュ値に振り分けられるなっている
ハッシュ構造の場合、N=128万にすると、1つのハッシュ値に1万個の
(key, value)のペアが対応している。
そして、1個のkeyを検索する時、平均的には、1万個の半分の5000回
くらいkey値の比較を行うと一致するものが見つかる。
なのでこの場合、1個のkeyに対する検索時間は
5000*(keyの比較に要する時間)
となる。
Nを128億にすると、
5000万*(keyの比較に要する時間)
になる。

**デフォルトの名無しさん** · 2021/12/07(火) 14:52:05.46

>>863
誤:128種類のハッシュ値に振り分けられるなっている
正:128種類のハッシュ値に振り分けられるようになっている

誤:5000*(keyの比較に要する時間)
正:5000*(1回のkeyの比較に要する時間)　// ()内は、keyが文字列の場合、1回の文字列比較に掛かる時間。

誤:5000万*(keyの比較に要する時間)
正:5000万*(1回のkeyの比較に要する時間)　// ()内は、keyが文字列の場合、1回の文字列比較に掛かる時間。

>>862
> 利用率が一定を超えた場合に、より大きいサイズのハッシュテーブルを用意して格納し直す操作が必要となる。これをリハッシュ (rehash) と呼ぶ。
>>861 の4行目で、リハッシュは行わないと断った。
はっきり、Mを定数とすると書いている。

**デフォルトの名無しさん** · 2021/12/07(火) 17:09:08.05

数学100点マンの机上の空論がさらに輪をかけてるな

>>864
> 最大M個の振り分け能力があるハッシュ構造にN個の(key, value)ペアを書き込んでいる場合を考える。
> M=128で、128種類のハッシュ値に振り分けられるようになっている
> Nを128億にすると、5000万*(keyの比較に要する時間)になる。

つまり128億個のデータを128個のハッシュ値パターンでハッシュテーブルに格納か
現実の世界ではなく一人だけの特殊な妄想世界で空論

**デフォルトの名無しさん** · 2021/12/07(火) 17:09:50.30

worst caseはO(n)って言えば一言で終わる話だった

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

平均もO(n)だろ

**デフォルトの名無しさん** · 2021/12/07(火) 18:19:10.70

でそれにC++やRustとどう関係が？

**デフォルトの名無しさん** · 2021/12/07(火) 18:22:43.53

さあ

**デフォルトの名無しさん** · 2021/12/07(火) 18:27:32.38

とにかく、この >>813 の書き込みはすごい、ってことだ
このスレの集大成に近い出来だと思う

**デフォルトの名無しさん** · 2021/12/07(火) 18:35:18.60

>>623 を無駄に長く書いただけに見える
>>624 はスルーで

**デフォルトの名無しさん** · 2021/12/07(火) 18:37:25.57

計算可能性 > 計算オーダー > 計算時間

混ぜるな危険

**デフォルトの名無しさん** · 2021/12/07(火) 19:22:19.85

>>861
あなたの言うランダム性の定義を伺いたかったのですが
挿入されるkeyはどのような分布に従う仮定なのですか

**デフォルトの名無しさん** · 2021/12/07(火) 19:28:32.42

確率論では衝突の発生確率が一様分布と仮定した場合、衝突回数はポアソン分布に従う

**デフォルトの名無しさん** · 2021/12/07(火) 19:37:51.93

要するに衝突回数は幾何平均(算術平均)とは異なる

**デフォルトの名無しさん** · 2021/12/07(火) 19:51:15.50

>>873
衝突が起きるとしても、5chのIDが被る程度の稀な確率となる程度のランダム性を想定しています。

**デフォルトの名無しさん** · 2021/12/07(火) 20:13:15.75

>>876
分布については特に何も想定してないということですね

**デフォルトの名無しさん** · 2021/12/07(火) 20:15:39.60

>>877
データに合わせてハッシュアルゴリズムを変更する、アダプティブ・ハッシュ・テクノロジー™をご提案いたします。

**デフォルトの名無しさん** · 2021/12/07(火) 20:16:48.35

結局のところ衝突回数が算術平均に従う場合はO(n)であるが、この場合確率そのものが極めて小さく分布の期待値が小さいためO(1)に極めて近いとしか評価の仕様がない

**デフォルトの名無しさん** · 2021/12/07(火) 20:23:38.39

>>813は、言語のバイナリ生成能力を論じるときに計算オーダーは意味がないと言っているのでは？
その理由として、同一の計算オーダーを持つアルゴリズム、あるいは同一のアルゴリズムから、どちらが優れたバイナリを生成できるか論じているので、それはベンチでしか判明しない、と挙げていると思うのです。

**デフォルトの名無しさん** · 2021/12/07(火) 20:33:30.11

特定のアルゴリズムを特定の計算オーダーで実装出来ない言語もあるので
全く意味がない事はない

**デフォルトの名無しさん** · 2021/12/07(火) 21:45:05.70

RustとC++は万能

**デフォルトの名無しさん** · 2021/12/07(火) 21:53:06.58

リンクリストの話は？リンクリスト、皆のアドバイスを受け入れて辞め、ハッシュテーブルに絞ることにしたんですか…

**デフォルトの名無しさん** · 2021/12/07(火) 21:54:51.19

リンクトリストね？

**デフォルトの名無しさん** · 2021/12/07(火) 23:00:58.24

>>873
異なるキーに対するハッシュ値が、可能な限り異なるランダム性。

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

>>866
処理時間を g(N)とすると、worst case ではなく、平均が、g(N) = O(N)。
O(N)という記号を使わずに、詳細に書くと、
g(N) = a * N + b
だが、利用されるハッシュ値の振り分け数が M 個の場合、
a = b / M
程度となり、M = 1024 の場合、a は、0.001 * b 程度の小さな値になる。

横軸を N、縦軸を g(N) とするグラフを書くと、一次関数となり、y 切片が b、
傾きが 0.001 * b 程度となり、ほぼ水平であるが、僅かに右肩上がりとなる。
もしこれが完全に水平なら O(1)。
今回の場合、非常に水平に近いが確実に単調増加であるので、O(1)のように
見えるが本当は O(N)。

**デフォルトの名無しさん** · 2021/12/07(火) 23:13:13.90

>>886
O(1)とO(N)の間にはO(logN)やO(√N)など無数にある

**デフォルトの名無しさん** · 2021/12/07(火) 23:15:17.87

>>887
もちろん、それは当然。
それは全く否定していない。

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

>>888
[補足]
「グラフが水平なら O(1)」とは書いたが、「O(1)ならグラフが水平」とは
書いてない。
つまり、グラフが水平である事はO(1)であることの十分条件であるが、
必要条件ではない。

「グラフが水平　⇒ O(1)」とは述べているが、その逆の
「O(1) ⇒ グラフが水平」とは述べて無いことに注意。

**デフォルトの名無しさん** · 2021/12/07(火) 23:59:06.43

>>886
それがworst caseの話なんだってw
amortized average caseがO(1)とみなせる前提をガン無視して
「ほらO(n)だろ」とか言ってても誰も相手にしてくれない

**デフォルトの名無しさん** · 2021/12/08(水) 00:07:41.43

>>890
いや、違う。
平均は、
g(N) = b * (N/M + 1)
程度。
worst は、
g(N) = b * N

どちらも O(N)ではあるが。

**デフォルトの名無しさん** · 2021/12/08(水) 00:20:29.77

>>891
なお、数学の秀才なら気付くと思うが、この平均の式は、本当は正しくない。
ただし、大体は合ってる。

**デフォルトの名無しさん** · 2021/12/08(水) 00:22:38.55

>>892
[補足]
何が正しくないかというと、本当は、ある箇所を2 で割る必要があるから。
例えば次のように :
g(N) = b * (N/(2M) + 1)
しかし、これでも、まだ少し正しくない。

**デフォルトの名無しさん** · 2021/12/08(水) 01:40:32.51

1次関数の試験で100点取れそうな説明

**デフォルトの名無しさん** · 2021/12/08(水) 01:51:55.62

数学100点君は数学用語の定義を誤解釈しまくって理解してしまっている感じ
説明の内容からしても多分中高生か啓蒙書を読みかじったおじさんなんだろ

**デフォルトの名無しさん** · 2021/12/08(水) 03:16:15.50

なんでここは、数学が理解できない人ばっかりなんだ。
だから、プログラマが馬鹿にされる。

**デフォルトの名無しさん** · 2021/12/08(水) 03:18:58.91

C++ vs Rust を語る前に、せめて、数学的に明らかに正しいことを理解できるから
でないとどうにもならん。
それ以前の問題。

**デフォルトの名無しさん** · 2021/12/08(水) 03:20:41.94

それと、科学者にとって最も大事なことは、頭の良さでも知識でもなく、
正直さだ。
自説を主張するために正しい主張を否定してはいけない。

**デフォルトの名無しさん** · 2021/12/08(水) 03:21:17.48

「ランダムアクセス」って任意の要素にアクセスすることを指すんだけど、乱択的に与えられた要素にアクセスすることをそう呼ぶんだと思い込んでる奴が複数いてクソワロ

**デフォルトの名無しさん** · 2021/12/08(水) 03:25:58.49

>>894
結果は一時式でも、それを求めるには確率論以前に、イマジネーションが必要。
どこかに書いてある知識の組み合わせでは導出できない。
確率論は、自分の想像力が重要に成るので、計算力だけでは無理な分野。
書いてある定理を組合すだけでも導けない。
数学は、基礎の部分はイマジネーションで作られているから、頭の良い
人以外には作れない。
いくら勉強しても無駄。

**デフォルトの名無しさん** · 2021/12/08(水) 04:31:15.37

ハッシュに格納するまでの過程は確率論でも格納された後はただのリニア検索だけの話にすり替わってないか？

**デフォルトの名無しさん** · 2021/12/08(水) 08:47:15.25

>>900
誰でも後から客観的に検証できる性質が数学含む科学の特徴ですよ
イマジネーションって言い換えればあなたの妄想ってことですよね

**デフォルトの名無しさん** · 2021/12/08(水) 12:57:52.28

データ追加の話をするのであれば、どのようなアルゴリズムでも無限個数を追加するなら無限時間かかるわw

**デフォルトの名無しさん** · 2021/12/08(水) 13:53:27.51

chaining使ってる場合でスロット数(M)が固定値かつ要素数(N)に対して小さければO(n)になるのは当然だよね

それで100点君は何を主張したいんだっけ？

**デフォルトの名無しさん** · 2021/12/08(水) 14:37:30.67

これか >>813

>また、N個のデータを持っているハッシュ構造は、1回の検索は、数学的に厳密にはO(N)
>だが、実験的(実際的)にはO(1)のように振舞うと言われており、厳密に扱うには、
>オーダーの記号だけでは表現しきれない。

「1回の検索は、数学的に厳密にはO(N)」になるのは
一般的なハッシュテーブルの実装とは関係ない架空の条件下の話だね

つかBig O記法が何の目的で使われるのか把握してなかったのか・・・
長々とお疲れさんでした

**デフォルトの名無しさん** · 2021/12/08(水) 17:48:45.17

何の目的で使われるの？せっかくだから聞いておきたい

**デフォルトの名無しさん** · 2021/12/08(水) 18:48:01.53

なにを言いたいのかさっぱりわからないんだが、さかのぼって読んでみると

>>861
> 最大M個の振り分け能力があるハッシュ構造にN個の(key, value)ペアを
> 書き込んでいる場合を考える。
> ただし、Mは定数とし、N が大きくなっても拡張していかないものとする。
> このとき、一回の検索に掛かる平均時間をg(N,M)とすると、
> ほぼ、
> g(N,M)=b・(ceil(N/(2M))

いや、全然違うし
一体何をあらわしてる式なんだ？

**デフォルトの名無しさん** · 2021/12/08(水) 18:55:15.30

c++: cほど性能はいらないけど、コーティングでcより楽したい
Rust: c++くらいの性能はほしいけど、間抜けがメモリリークをエンバグするのを防ぎたい

Rustの狙いはc++＆コーティング規約＆lintでけっこうカバーできるけど、Rustは言語仕様としてコーダー全員に規約遵守を強制しているのが強み。
Rustが本当に普及してきたら、Rust対抗としてC++と連携できるSmartC++が出てくるんじゃないのかね。

**デフォルトの名無しさん** · 2021/12/08(水) 19:27:33.65

>>908
＞Rust: c++くらいの性能はほしいけど、間抜けがメモリリークをエンバグするのを防ぎたい

これが重要だな。

**デフォルトの名無しさん** · 2021/12/08(水) 20:11:11.64

C++はCと同じ性能が出る
楽をしなければ

**デフォルトの名無しさん** · 2021/12/08(水) 21:56:00.76

間抜けがミスをするというと十分に訓練を受けたパログラマーならミスをしないと読めるが
実際にはコードベースが大きくなると間抜けなミスをする確率が高まるので
自分はミスをしないと思い込むのではなくミスした場合も検出できるようにすべき
静的解析やrustの真価はそういうところにあると思う

**デフォルトの名無しさん** · 2021/12/08(水) 22:28:44.41

>>902
ここの人には理解できないようだがな。

**デフォルトの名無しさん** · 2021/12/08(水) 23:45:42.27

>>911
そのためのコーディング規約＆lintだろ。
極端な話、Rustみたいに
基本unique_ptrにして共有する部分だけshared_ptrを使用＆生ポインタ禁止、
3rdパーティライブラリはunsafeなラッパークラスで閉じ込めた使用のみ可、
といったコーディング規約にして設計すりゃポカミスぐらいは防げる。

**デフォルトの名無しさん** · 2021/12/09(木) 01:07:49.62

>>913
何もrustに限った話ではないというのはその通りで
静的解析やrustと書いたのはそういう規約やlintで補うことも可能という意図

ただrustのshared mutabilityを原則禁じるルールなど、lintで同等のチェックするのは難しい気がする

**デフォルトの名無しさん** · 2021/12/09(木) 08:41:44.98

>>913
その規約を遵守させる工数がバカにならないんだよなぁ
人数が増えるとさらに倍になるし

**デフォルトの名無しさん** · 2021/12/09(木) 08:48:29.40

ポカミスってのは規約守り忘れとかも含むんだよな
lintやコンパイラみたいな機械的なチェック以外は基本信用できない

**デフォルトの名無しさん** · 2021/12/09(木) 09:09:54.36

lint、コンパイラを無駄に信用しすぎだな。

**デフォルトの名無しさん** · 2021/12/09(木) 12:41:39.28

コンパイラに強制させたいのならnext c++待ちかね。

Rustの問題点が顕在化してきたくらいのタイミングで、RustアンチテーゼとしてSmartC++とか出てくるんじゃない？

c++のバットノウハウを禁止できればRust使う必要性はずいぶん薄れるな。
「SmartC++のスコープ内では生ポインタ変数禁止」「nullのスマートポインタの生成禁止」くらいでも十分な気がしてきた。

**デフォルトの名無しさん** · 2021/12/09(木) 14:23:33.22

Lifetime ProfilerでRustのborrow checkerに近いものを実装しようとしてるけど
機能的にも未熟だし標準的に使われるレベルになるかどうかも現段階では怪しい

そんな夢見てるくらいならRust使ったほうが堅いし現実的

**デフォルトの名無しさん** · 2021/12/09(木) 14:58:02.48

>>918
Rustの問題点てなんですか？
揶揄してるわけじゃなくてまだ入門の勉強中なのでいろいろ興味あります

**デフォルトの名無しさん** · 2021/12/09(木) 17:02:43.74

>>920
よく言われるのが学習コストの高さ。
c++もいいかげん複雑すぎる言語と言われているけど、Rustはそれに輪をかけて難しい。
特に他の言語を勉強した初級・中級者は変数の挙動から何から違う(＆他の言語のようにやるときのためのガイドラインも無い)ので地獄を見るかと。

**デフォルトの名無しさん** · 2021/12/09(木) 18:08:02.53

んなアホな

**デフォルトの名無しさん** · 2021/12/09(木) 18:22:55.56

>>921
そんなことはないと思う
Rustはわかりやすかったぜ
しかも他より書きやすく便利になった

**デフォルトの名無しさん** · 2021/12/09(木) 18:25:55.97

さすがのとほほさんも、Rust入門は書けてもC++入門は言語使用がでかすぎて書けなかった模様w
https://www.tohoho-web.com/www.htm