C vs C++ vs Rust Part.2 YouTube動画>1本 ->画像>2枚

競え
※前スレ
C++ vs Rust
http://2chb.net/r/tech/1619219089/

たったぞ

C vs は余計だった

Cに原点回帰しようよ

GoはC++というよりCっぽいよな

Goはモダン言語にアレルギー反応が出てしまうC老人のための言語

顔真っ赤な怒り心頭Rustオジサンがなぜかスレタイに無いGoを粘着でディスり続ける

言語仕様が優れてるとかなんとかはあるだろうけど
結局使いものになる言語は何かと言われればC/C++なんだよ

Rustは流行りもの
C、C++は基本

RustとC++が互いに馬鹿にし合うのをCが高みの見物するスレですか？

CやC++なんて、UNIXかWindowsが成功してなきゃ流行ってたわけない
（そもそもUNIXがないなら、C言語も生まれてないけど）
結局は勝ち組プラットフォームにおんぶにだっこされてるだけよ

Rustも巨大企業に推されて採用されてるから、優れてる言語かどうかに関係なく流行る

流行は巨人が決めてる

Rustンサーガ
パンツ一丁でオッサンが闘うヤツ

本当のプログラマはPascalを使う

May the FORTH be with you.

いまだに組み込みはCオンリーですが、「UNIXがないなら、C言語も生まれてない」は間違いに近い
https://ja.wikipedia.org/wiki/C言語#歴史

>>8
でもチーム開発するならRustの安全性は100%じゃないとしても十分魅力的だなぁと思う。

>>15
それ読んだら、
UNIXの *ために* C言語が作られたわけじゃないけど、UNIXが *なかったら * C言語も生まれてない、と読めるけど。

>>9
C・・・ベーシックアイテム。
C++・・・おしゃれアイテム。
Rust・・・意識が高くなる壷。

RustやRubyは、まず伝道師から始まるからな。
どういうわけか伝道師が大量発生する。

C++使いがコード書いてる間、彼らは伝道する。
神の使いなのかもしれんな。
啓示があったんだろう。

Rustは実用に主眼を置いた泥臭い言語なので
伝道師の言う美辞麗句は無視してよい

っつか、いくら伝道師わいたってRust自身がその敷居の高さで安易に手を出すやつを排除するからRubyみたいには使われないんじゃねーの？

クソコード過ぎでこんなの誰も見ないよ

>>24
良いコードをご教授していただけませんか？
普通にループは使わずに足し算と比較のみで素数をその型の上限まで返すイテレータ関数です
言語はCでもC++でもRustでも構いませんのでよろしくお願いします

Playgroundでu16に変えたらTLEした

>>25
>>23ですらループ使ってるじゃん
馬鹿そう

>>27
どこにループが有りますか？
勉強不足でわからないので教えてください

Rustのコードはなに見てもきたねぇな

>>29
それは私がプログラミング勉強中だからだと思います
あるいはCやC++ならば「ループを使わずに足し算と比較のみで素数をその型の上限まで返すイテレータ関数」を
綺麗にプログラミングできますか？
綺麗なコードをご教示していただけるとうれしいです

>>23
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=3e0c372e78ce024307bd58c1f03df55e

.find(..).is_some() は .any() と書ける (これはclippyが指摘してくれる)
if let Some(x) = expr { .. } else { None } は let x = expr?; .. とした方がネストが浅くなる
類似の処理は名前をつけて関数に括りだした方がわかりやすい

>>23
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=6d5f63ffe7c46236a0957017db33a0b9
もう少し改善できた
スレ汚しすまん

>>31のコード見た後に>>23見るとゲロ吐きそうになるな

>>28
例えばfindはtry_foldを呼び出してるがこのメソッドはwhileを使って実装されている
どこかにループあるとわかりそうなもんなんやけどな

rustのコードはc/c++以上に見苦しい
こんな言語を業界全体でプッシュしてるのは異常だよ

>>35
どの業界の話だよ

日本のC++業界だよ

なんでこいつRustの本スレでやらないんだろ、ほんまキモイ

本スレで自己満足やられて本気でウザかったからここでいいよ

だからここはガイジ隔離用のスレなんやで

字面だけみるとPerlとどっこいの汚さだな

>>35 >>42
これ全く同じ機能をC++だと美しく書けるんかいな？
前スレでもRustの動くコードは出ていたがC++の動くコードは全く出てこなかったよな
だから既にC++プログラマーは絶滅していてRust派とアンチRust派(数学100点マン等)だと思ってた

unfold使ったこと無いから間違ってたら教えてほしいんだけど
これO(n^4)？

ゲロのようだ

さわやかな新宿の朝って感じですね。
ゲロの臭いでもらいゲロしそう。

そもそも
「ループを使わずに足し算と比較のみで素数をその型の上限まで返すイテレータ関数」
というのはどこからでてきたもんなんだ？
この条件になにか意味があるの？

>>48
まず素数なら列になるのでイテレータにするのはいいですよね
用いる型によって上限値が異なるから上限まで返すのも自然ですよね
足し算と比較は必要最低限として不可欠だと思います
どうしてもならばループは使ってもいいですよ
だから今回は可能ならばループを直接使わずに高階関数イテレータ使用でという話だけです
つまりそんな難しい話をしているわけではないと思います
他の言語のコードが出てこないのは難しいからなのでしょうか？

Rustのことは知らんのだけどsome, any, map, findって実質ループじゃないの？
Rubyっぽい構文も見られるけどブロックを毎度呼び出してもらってるだけだからループじゃないとかいうわけ？

>>49
人に読ませるためのコードを書いたことがないのかな？
アルゴリズム的にどうとかRustの書き方的にどうとか言う以前の問題

恥ずかしい自演

ん？
あと変数名をわかりやすく変えたほうがいいぞ

本スレでクソコード連投してた奴だな
素数列挙をジェネリックにしてうれしがるセンスが厨二病っぽい

計算量悪くね？

>>17
DEC PDP-11で動かすUNIXを書くためにC言語が生まれたと思ったが？
C言語の方が後なら、最初のUNIXは何の言語で書いてあったの？

アセンブリ言語

>>58
Wikipediaにすら「当初はアセンブリ言語のみで開発されたが、1973年にほぼ全体をC言語で書き直した。」と書かれているんだけど。

>>18
要するに
Cはマック
C++はスタバ
Rustはブルーボトルって理解でおｋ？

マジで何がしたいんだろこいつ

使えなさ加減は似たようなものだが
計算量を重視するだけ競プロ信者のほうがまだマシ

コードゴルフみたいなパズル感覚なんじゃね
知らんけど

rustの構文が本当に受け付けない

言語の構文が受け付けないというとこの話を思い出す
http://love-motif.com/article/art_13.shtml

rustの構文に対してこんな感じで生理的嫌悪覚えてるんですか？

rustが流行って、こういう素数なんて書く意識高い初心者が量産されて、汚ねぇコードを治すのかと思うと
今から頭痛がしてくる

>>61
Rustは晋三が飲んでる何とか還元水では？
意識タッケーーー！！！

>>65
今どきは他のプログラミング言語も似たようなものだぜ
例えば配列 [4, 9, 3, 7, 1, 8, 5] から文字列 "9-8-7-5-4-3-1" への変換

【Ruby】
a.sort().reverse().map{|x| x.to_s}.join('-')

【JavaScript】
a.sort().reverse().map(x => x.toString()).join('-')

【Rust】
a.iter().sorted().rev().map(|n| n.to_string()).join("-")

このように些細な違いのみでほとんど一緒
逆に古典的な記述法は以下のようにコードが読みにくい

【Python】
'-'.join(map(lambda x: str(x), reversed(sorted(a))))

>>69
FORTHの時代が来たな。

【Rust】
a.iter().sorted().rev().map(|n| n.to_string()).join("-")
これはどんなアセンブリコード吐くの？

>>71
元のコードコンパイル通らないので適当に変更してみた
https://godbolt.org/z/KTTcEccfz

>>72
Rustでは最小限しかstdに入れない方針
use itertools::Itertools; を付ければ>>69で通る

>>67
どう見てもめちゃくちゃ意識低いやつのコードなんですけど・・・
どこに意識高い系要素を見出だしたんだ？

>>71
Rustの各イテレータメソッドは全て各々の固有の構造体(struct)を返すだけです
アセンブリコードはスタック上に確保された構造体の大きさの領域にその値が入ることになるでしょう
そしてその構造体に対してnext()という関数が実装されています
後続の別のイテレータが自分に対してそのnext()を呼び出すことになります
そして他からnext()を呼ばれた側は自分の構造体のデータを利用して値を返します
これらのアセンブリコードは普通の関数呼び出しと同じでしょう

具体例を見たほうが早いと思います
例えばもう少し簡単な以下の例を動かしましょう
fn main() {
　let v = vec![5, 6, 7, 8, 9];
　v.my_iter().my_print();
}
このベクタvに対してmy_iter()さらにmy_print()とチェーンになっている例で説明します
多くの場合はライブラリにあるイテレータを使うので自分で実装しなくていいのですが
アセンブリコードが気になる(＝どう動作しているの？)とのことなのでゼロから実装します

このmy_iter()も構造体を返すだけの関数です
ここでは説明をわかりやすくするためジェネリックでなく
具体的な型『Vec<i32>』(符号付き32bit整数のベクタ)に対してmy_iter()を実装します

まずmy_iter()が返す構造体を定義します
struct MyIter {
　vec: Vec<i32>,
　index: usize,
}
ベクタの値を次々と返していけるようにベクタとそのインデックスを保有します
変数名と型の位置がC言語とRustでは逆なだけでわかると思います
インデックスのための型『usize』は符号なし整数です

今回>>77のmy_print()はメソッドチェーンの最後なので構造体を返していません
だから正確にはmy_print()はイテレータではなくイテレータに実装されたメソッド(の一つ)という立場だけです
逆に言えばメソッドチェーンの途中の全てのイテレータメソッドは各々の固有の構造体を返します
そして後続のイテレータ(など)からnext()の値を要求されたらそれを返す動作のみするのがイテレータです

長いメソッドチェーンで一番最後がnext()を要求して連鎖的に最初のnext()が呼ばれるパターンもよく有ります
なぜなら多くのケースで途中のイテレータは自分のnext()実装で先行するイテレータのnext()を呼び出すからです
そして連鎖的にnext()呼び出しが生じても動作原理は多段の関数呼び出しと同じです

したがって元の質問>>71「どんなアセンブリコード吐くの？」も
「イテレータとして機能するメソッド呼び出しは単なる関数であって構造体を返すだけ」と
「あとで後続からその構造体に実装されてるnext()関数が呼ばれる」だけなのです
特別な仕組みとか裏でインタプリタやランタイムや魔法が密かに動いている、ってことはないです

文章を構造化できない人はコードを構造化することもできない

ひとりよがりが過ぎる

>>79
では修正点や改善点などをお待ちしておりますw

ヒトに頼るな。

ワロタ

どんなアセンブリコード返すのという質問なんだから >>72 みたいにアセンブリ示せばよかろうに

イテレータの作りを説明してくれた人ありがとう
それ自体は他の言語でもよくあるパターンだね
ただ聞きたかったのは効率を重視するはずの（と思っている）言語が
この書き方で効率のよいコードを吐けるかどうかってこと
>a.iter().sorted().rev().map(|n| n.to_string()).join("-")
Rustはimmutableが基本と言う話を聞いてるからもしかしたら
新しいオブジェクトを生成しまくってるんじゃないかと思ったんだよ
この書き方をしてC/C++と同レベルの効率のコードが吐けるのかなって

>>84
そのコードは to_string() を要素数だけ呼んで最後に join してるからヒープアロケーションの回数が気になる場合は使うべきでないコードだね
だだrustのイテレーターのメソッドチェーン自体は不要なヒープアロケーション行わないしメソッドはインライン展開できるので
ある程度複雑なメソッドチェーンでもfor文と同じようなアセンブリになると言われているよ

>>84
例えばCのfor文などと比較すると、
その変化していく変数は構造体の中だが大元の関数のスタック上すなわちローカル変数と同じだからCと変わらん
あとinline展開指定されてるものなどで関数呼び出しオーバーヘッドも消えて前後のコードが繋がって最適化されるパターンもある
だから気にせずに使っても誤差範囲

RustってC++に似てるな
ゲロみたいな構文だ

>>85
結局メソッドチェーンとは別問題として
一般的にVecやStringなどのヒープ使うものがループ内にあると注意やな
あとcollectでスタック使うArrayVecやArrayStringを指定する手もあるな

>>69
> 配列 [4, 9, 3, 7, 1, 8, 5] から文字列 "9-8-7-5-4-3-1" への変換
> a.iter().sorted().rev().map(|n| n.to_string()).join("-")

このコード自体は他言語との類似比較のために冗長に書かれていて無駄がある
join("-")はDisplay実装あれば通るから事前のto_string()は不要
つまりa.iter().sorted().rev().join("-")でOK

さらにsorted()はヒープに結果Vecを確保する
もし元を書き換えていいならヒープ確保をjoin()でのString一つだけで済む

let mut a = [4, 9, 3, 7, 1, 8, 5];
a.sort();
assert_eq!("9-8-7-5-4-3-1", a.iter().rev().join("-"));

このrev()を無くすためにa.sort_by(|x, y| y.cmp(x))にするとcmp関数でやや不利
一方でrev()使用は配列やVec相手ならDoubleEndedIterator実装があるからコストかからない
現実にはこのコードが核心部分でなければそこまで気にしなくていいけどな

一つだけアドバイスしとくけど、ジェームス・ボンドが日本人だったら、大木・凡人だからね。

>>74
Rustを使ってればカッコイイという錯覚で、何も分かってないのに汚物のようなコードと意味不明な長文をまき散らす…
あんなに単純な初期のJavaやC#でさえスパゲッティコードだらけなのに、日本語の説明さえも気持ち悪い

>>91
こじらせてんな
ゲロコード君とは違う方向性だが

長文二人は属性が似過ぎだろ
こんなのが二人もいればRustスレが気持ち悪くなるわな

顔真っ赤で根拠も反論もない「こじらせてんな」マンが永遠と長文や短文を書き、本Rustすれに代わりキチガイを集めるスレ

延々とな
ガイジそう

元々rustスレの隔離スレなんだから大成功でしょ

>>91
>あんなに単純な初期のJavaやC#でさえスパゲッティコードだらけなのに、日本語の説明さえも気持ち悪い

文の前半と後半のつながりが全くわからないので解説頼む

> この難しさを取り除くために、Rustは、C/C++の落とし穴を排除し、その過程で使いやすく役に立つ
> 洗練された一連のツールを提供します。 低レベルな制御に「下がる」必要があるプログラマは、
> C/C++のクラッシュやセキュリティホールのリスクを負わず、 気まぐれなツールチェーンのデリケートな
> 部分を学ぶ必要なくRustで同じことができます。さらにいいことに、 Rustは、スピードとメモリ使用の観点で
> 効率的な信頼性の高いコードへと自然に導くよう設計されています。

顔真っ赤Rustオジサンの「 ＞」、やっぱ同一人物だったかｗ

>>84
その、新しいオブジェクトを生成しまくってるんじゃないか、の意味が曖昧なので
自動的にヒープ領域から動的に新たなメモリ確保をすると解釈すると、それはないです
Rustでもプログラムで明示的に指定しない限り勝手にそういうことが起きることはありません

もちろん例えばVec型(伸長可能な配列)やString型(伸長可能な文字列)を新たに返す関数を使えば
それはプログラムで明示的に指定したことになり、当然ヒープ領域が使われます

一般的にイテレータの長い連鎖があっても各イテレータが返す(＝用いる)構造体は各1つで
それらはコンパイル時に静的に確定してスタック上にローカル変数と同様に領域が確保されます
したがってイテレータ連鎖で動的にヒープが使われうるのは例えば
(1) イテレータがクロージャを引数として取る場合にそのクロージャのコードがヒープを使うものである場合
(2) sorted()のように前イテレータから全要素を一旦受け取る必要がある途中のイテレータが一時格納場所としてヒープを用いる場合
(3) collect()のようにイテレータ連鎖の最後に全要素を収集してVecやStringなどを新たに生成する場合
いずれもそれらの関数やクロージャをプログラムで使用した時のみ、動的にヒープが使われます

何が気持ち悪いかというと
自分も知らなかったことを調べてきてさも知ってたかのように上から目線でレスする精神
気持ち悪い

そしてその内容がいつも間違えてるからゲロ吐く気分になる

多少の間違いがあっても要点をおさえて質問に正面から答えてるんならまだいいんだけどねー
困ったもんだ

間違いがあれば俺が指摘修整してやるから安心しろ
おまえら雑魚はそれでいい

おまえは間違ってるって主張だけだと数学100点の人と同じだぞ
せっかくだからどこが間違ってるか指摘してあげなよ

そいつらは前スレからそんな感じだから放置されてる
ガイジとかゲロとか汚などの言葉を好む
具体的なコードや具体的な指摘は出来ないダメな連中

プログラム勉強しはじめたんだけど、CとかC++よりもRUSTのほうがかっこよさげだからRUSTやってる

意識他界系かよ

CやLispからはじめるのが意識高い系
Rustからはじめるのはカッコつけたいだけの単なる無知

C++から始めるのは何系？

CがあるのにC++から始めるひとはガイジ系

10年早い系

ウッホウッホホ、マウンテンゴリラです。得意なのはドラミングで毎日ドコドコやってます

>>108
なんでrustからだとあかんの？

マルチパラダイムだからでは。

>>114
よく知りもせんなら黙ってろや

最近c++勉強始めたんだが、cとかmapも使えないじゃん
どうしてんの？

mapを作るための言語がCだから。

RustはコンパイラもライブラリもRustで書かれているね

>>116
昔はアルゴリズムの教本を参考にして全部1からつくってた

今も必要があれば車輪の再発明をする能力を持つ人と持たない人にプログラマーは二分される
前者は新たな枠組みを作ることも可能な生産者
後者は既存の枠組みを使うだけの消費者

俺には検討もつかんわ
所詮俺は消費者か…

見当

コンシューマーって言えばカッコよくなるよ。

プロデューサーとコンシューマーと呼ぶと両方存在して初めて意味を持ちそうな感じがするな

この場合の生産者は、制作者(プロデューサー)ではなくて創造者(クリエイター)の方が近い

もっともらしく言ってるけど
新たな枠組みを作ることができるかどうかに
車輪の再発明をする能力は関係ないよ

プログラミングにおいて車輪の再発明すら出来ない人が
プログラミングにおいて新たな枠組みを作るのは無理

ザッカーバーグとかツールレベルでいえばあるもの使ってただけだがな。

クイックソートくらいは自作してみたほうがいい
最初混乱するだろうけど、ああなるほど！となった時に必ず経験値に加算される筈だ

>>128
そりゃ彼はプログラミングにおいて新たな枠組みを作ったわけではないからな

新たな枠組みって例えば何？
フレームワークのことではなさそうだけど

例えば画像データの取り扱いでbitmapをそのまま処理していたような時代にpngやjpgなどのアルゴリズムをはじめて考え出して
実装したようなプログラマが新たな枠組みを作ることが出来る人
既存のライブラリ使って画像処理や表示のアプリを実装しているようなプログラマが枠組みを使うだけの人

もちろん例としてプログラミングのフレームワークでもいいんじゃね？
例えばそのザッカーバーグの例ならば
Facebook社はプログラミングにおいて新たな枠組みとして世間にも広まるほどのReactを作った
一方でザッカーバーグ自体はReactを今から車輪の再発明すらできないしプログラミングにおいて新たな枠組みを作れないだろう

枠組みに限らず何か新しいもの自力で作るには
その対象レイヤーのものを作れる能力は必要
それは当たり前

ザッカーバーグだって掲示板システムを実装する能力があったからFacebookを作れたわけだが
それを「車輪の再発明する能力」と呼ぶのかどうか

「新しい枠組み」と「車輪の再発明をする能力」の定義が曖昧すぎて中身がない

結局のところ
「低レイヤーの開発をするには低レイヤーの実装能力が必要」という主張でしかない

そこは定義でもめるから深入りしない
例えば例に挙げたReactは自分の観点からは低レイヤーではなく高レイヤー
結局これでいいかね？

各分野のプログラミングにおいて車輪の再発明すら出来ない人が
その分野のプログラミングにおいて新たな枠組みを作るのは無理

車輪の再発明って何
自身で模倣できる程度には理解しているということ？

レイヤーは相対的なものだよ
低レイヤーで通じないなら下位レイヤーとでも言おうか

Reactのユーザーから見ればReactそのものの開発は下位レイヤー
Reactを作るために下位レイヤーのJavaScriptエンジンやレンダリングエンジンを再発明できる能力が必要か？

話はシンプル
それぞれの分野で見ればよい

Reactの分野だったら
『自分でウェブフロントフレームワークを簡易なものでよいから作ったことあるか？あるいは作れるか？』
これだけの話

つまりReactの開発者たちと同じような立ち位置に立てるプログラマーなのか、
それともReactの消費者としてユーザーの立場のプログラマーなのか、の違い

まとめると
「新しいウェブフロントフレームワークを作るには
ウェブフロントフレームワークを作る能力が必要」

そりゃそうだ
話はシンプルシンプル

なんだよこれ遅っせーなー
意味分かんねーんだよこの挙動
俺のほうがもっとうまく作れる

消費者プログラマーは色んな仕組みをわかっていなかったり理解できなかったりする人が多いね
そうなると車輪の再発明すらできないし車輪の改良もできない
もちろん車輪に代わる新たな仕組みを作り出すこともできない

>>138
これ本気で言ってるのか

元の話はmapの実装方法がわからない、だから、もっと深刻な状況なのか
プログラミングする上での基本的なことは
車輪の再発明であろうと自分でやってみて体験していくべき

習熟のために必ずしも車輪の再発明が必要であるわけではないでしょ

発明する必要はないけど何もないところから自分の力だけで車輪を組み立てられるようにはなっておいた方が良い

Cをやるとそういう力が身に付く

「フロントフレームワーク」なんて言い方するのかとググったら、まぁまぁ居たわ

IPアドレスの正規表現を再発明してるやつがいたけど
ああいうのが"新しい枠組みを作ることも可能な生産者"だったのかw

IPアドレスの仕組みも正規表現も別に目新しいものではないのでは？
何か特別な表現手法とかを導入する余地って残されていたか？

正規表現とか言ってもただの文字列だからな
数式やアルゴリズムに落とし込めないもので再発明も何も手の出しようがないだろ

使ってる言葉を自分なりに定義できないやつは普段物事を深く考えてない
知性の程度を簡単に測れる物差し

つまり…？

>>151
えっ？
正規表現⊆アルゴリズム
じゃない？

正規表現は文字列の集合を表すだけですよ。

ある正規言語に対応する文字列やろ

ただの検索や置換のためだけのメタ言語だよ
問題記述能力はない

問題記述能力？

>IPアドレスの正規表現を再発明してるやつがいたけど

再発明って具体的にどういうことやってたことを言っているんだろ

そのケースはアルゴリズムではないな
一般的に自分で一から作れる人はその時々に応じて最適なアルゴリズムを見つけ出すだろう

何がアルゴリズムで何がアルゴリズムでないか
ちゃんと境界値テストできてる？

数式はアルゴリズムなのか？

俺がすごいと思ったらすごいというのをいかに客観的評価のように見せるか議論しているようにしか見えない

>>163
その通り
ついでに「俺すごい」アピールをしてる

まあ議論には全くなってないがな

>>161
一般的には(決定性)チューリング機械で可能な処理のことだけどな。

なので一部の数式(無限大集合とか)は範囲外。

無限大を数値計算で扱うために優秀なソフトエンジニア達の手によって、例えば離散フーリエ変換や離散ウェーブレット変換などのアルゴリズムが工夫され考え出された
これが新しい枠組みを作り出すということ

無限大の連続量を有限の数値で扱う
フーリエ変換
https://ja.wikipedia.org/wiki/%E3%83%95%E3%83%BC%E3%83%AA%E3%82%A8%E5%A4%89%E6%8F%9B
https://ja.wikipedia.org/wiki/%E9%9B%A2%E6%95%A3%E3%83%95%E3%83%BC%E3%83%AA%E3%82%A8%E5%A4%89%E6%8F%9B

>>167
FTは無限大集合を扱っている訳では無いだろ。実数とか扱えないし。

周期信号のフーリエ級数展開なら有限だけど連続信号を扱うなら無限積分の計算が必要
FTは無限積分を数値計算するため分割統治のバタフライ演算に落とし込んで更に演算量を抑えるため各種のアルゴリズムが考案されてる

で、新しい枠組みを作り出すことが C vs C++ vs Rust にどう関わってくるの

枠組みを作ることは凡人には無理
殆どは枠組みを使う人
ただ枠組みの仕組みを知らないと使うことも出来ない

最早スレチの話題に突っ込んで悪いけど、無限積分を回避できている気になっているのは気のせいであって、バタフライ演算とか関係ないからね(笑)

以前に皆さま方からアドバイスをいただいて
『足し算のみで素数列を生成するジェネリックなイテレータの実装』
を当時O(N^3)という酷さでしたが、このたびほぼ O(N) の新たなアルゴリズムと実装が出来ましたのでご報告します

足し算の総回数を O(N log log N) すなわちほぼ O(N) 近くにすることに成功しました
具体的には 1億(＝10^8) までの素数生成に必要とする 足し算の総回数が 2.5億回 とリニアになりました
前回と異なりメモ化をしていますがこちらも工夫により配列の長さを O(√N / log N) に抑えることに成功しました
具体的には 1億(＝10^8) までの素数生成に必要とする 配列の長さが 1231 と非常に小さな領域のみで実現できました

10^kまでの素数を順に生成時の足し算の総回数 O(N log log N)
10^1　4.70×10^1＝47
10^2　2.03×10^2＝203
10^3　1.90×10^3＝1903
10^4　1.95×10^4＝19508
10^5　2.12×10^5＝212715
10^6　2.27×10^6＝2278220
10^7　2.41×10^7＝24148110
10^8　2.54×10^8＝254082528

10^kまでの素数を順に生成時の配列の長さ O(√N / log N)
10^1　4
10^2　6
10^3　13
10^4　27
10^5　67
10^6　170
10^7　448
10^8　1231

メモリ使用もこの程度の少なさで
足し算を2.5億回とその比較だけで1億までの全ての素数を順に出力できるようになりました
このスレは数学が得意な方々が多いようなのでご検証よろしくお願いします

コードは以上です

今回はitertools::unfold()を用いなかったため、それにより省略できていた、
「イテレータ用構造体の宣言」「その初期化」「そのIteratorトレイト実装宣言」
などが今回は必要となりコードがその分だけ長くなっていますが
イテレータの実装本体部分は>>174のみです

足し算の総回数が O(N log log N)　例: 素数を1億までで2.5億回
メモリは配列の長さが O(√N / log N)　例: 素数を1億までで長さ1231使用
これらを足し算のみで実現できています
どうぞご検証よろしくお願いします

嫌われ者Rusterのウザウザ全文貼り付け、見るのも嫌になる自己満足オナニー

なんかやたら足し算のみで、って強調してるけど、
アルゴリズムはエラトステネスの篩だよね？
そう言ってくれたほうが理解しやすいよ

Rustはまだあんま良くわかってないのでコードは参考になるかも
でもテストケースに127が入ってるのはおかしくない？

あ、おかしくなかった
すまん

アルゴリズムに興味がある場合はCが読みやすいということがよくわかった

1億までの素数を全て求めるのが2.5億回の足し算だけで出来るものなのか？？
メモリもエラトステネスだと1億必要だよな？

一億たって100メガにすぎませんからね。

>>182
1億回の素数判定を個別に考えると平均2.5回の足し算となりもちろん無理です
そこで過去の判定時で用いた足し算の結果を後の判定時に用いる方法で
結果的に平均2.5回の足し算で済ませています

また、単純にエラトステネスのふるいでは1億の長さの配列が必要となりますが
まず時間と空間を逆転させることで必要となる配列の長さを減らしています
さらに再帰的に子と孫のイテレータを活用することで
>>173の表のように1億(=10^8)まで判定時で配列の長さ1231に抑えています
その時点で子と孫では配列の長さ27となっています

>>183
そんなO(N)のペースでメモリを使用していくのはいずれ限界もありますし
メモリキャッシュヒットの観点からも望ましくないと思います

さらに今回は小さい方から順に素数を返すイテレータです
イテレータ利用者は1億を超えて素数を利用するかもしれませんし
逆にもっと少ない小さい数のみ利用するかもしれません
最初に上限が1億など決まって開始する古典的エラトステネスのふるいでは上手くいかないのです

キャッシュヒット率の話するならベンチマークとってくれ

わざわざ決まってる数列を順番に出力するイテレータ書くのにそんな記述が必要になるのか
ちょっと普通のループでいいからC言語で書いてみてよ

>>185
ベンチマークをとる前に実装が必要だな
その前に新たなアルゴリズムも必要か
エラトステネスの篩は「指定された整数以下の素数を求めるアルゴリズム」だからイテレーターとは相性が悪そうだ

イテレータにすると、プログラミングの方向が変わるんですよ。
詳細を未来に先送りできるんです。
伝統ある手続き型の手法では、システムやライブラリを書く人が詳細を実装し、使う人は大まかな指示を出しましたよね。
イテレータ手法は、未来に詳細を決定する。
つまり使う人が細かいことを決める事になるんです。
そこらへんの詳しい話は、書籍クリーンアーキテクチャに載ってます。
この本に書かれてることがすべて正しいとは言いませんが、正しいことにしろ間違ってることにしろ、読んでおいて損はないです。

イテレータ特有の話と言うより遅延評価全般の話に読めるが

イテレータ万能説を唱えて長文するガチキチおじさんｗｗｗ
yieldはgeneratorをレイトバインド
for(range)はiteratorをレイトバインド
async/awaitはfutrueをレイトバインド
詳細を未来に先送り！キリッｗ

>>190
さあご一緒に、キリツ！

レイト「バインド」？

クリーンアーキテクチャを出してるから遅延評価のことじゃなく
IoCの一例としての高階関数のことを言いたいんじゃないかな？

昔は局所化して先送りにできることは素晴らしいことだと思ってた
でも最近そんなのは些末な事で、無能な働き者が気にすることだったなと考えを改めた
木を見て森を見ずと言うべきか

>>188
ある意味その考え方も正しいかもしれませんが
イテレータは例えば大ざっぱに分けても5種類はあるので
自分が作る部分がどの部分かによってその立場も変わると思います
(1) 発信イテレータ … >>174で示しました素数生成、レンジ(0..n)、配列やVecに対するiter()などチェーンでは先頭に来るもの
(2) 仲介イテレータ … map()、filter()、enumerate()などチェーンでは中間に来るもの
(3) 受信イテレータ … find()、fold()、collect()などチェーンでは最後に来るもの
(4) 合成イテレータ … chain()、zip()、merge()など複数のイテレータを入力とするもの
(5) 創造イテレータ … unfold()などイテレータを生み出す汎用イテレータ
とりあえず(4)(5)は置いとくにしても自分が作る部分は用途によって(1)か(2)か(3)と変わるため大きく立場も異なります

>>189
一般的に遅延評価による先送りといえば主役はクロージャですね
上述したイテレータを作り出すunfold()もクロージャを渡すことで成立しています

>>190
futureは「未来に先送り」ではなく「未来を先取り」と捉えたほうがよくないでしょうか
そして遅延評価というよりも並行並列評価する形になりますね
したがって今回の話には適さないかなと思います

>>185
そのためにもぜひ異なるアルゴリズムの実装を作ってくださるとベンチ比較できますね
いまのところ足し算で素数生成するイテレータの実装は以前に作った明らかに非常に遅い>>62と
今回作った動作O(N log log N)でメモリ使用量O(√N / log N)となる>>174の2つしかないのです

>>187
そうなんですよ
エラトステネスのふるいは最初に上限数を指定するためそのままではイテレータと相性がよくないです
またメモリ使用量も大きくなってしまいます
そのため試行錯誤のうえ新たなアルゴリズムが生まれたのが今回の実装です
もっと良い方法を考えついた方は教えていただけるとうれしいです

より良い方法に興味があるんなら、普通に既存実装を研究してみたらいいんじゃない？
例えばRubyの標準添付ライブラリにも Prime.each があるよ
ソースはここ https://github.com/ruby/prime

おれはそこまで素数のアルゴリズム自体には興味ないから考えないけど

>>197
CかC++で書いて

C/C++/Rustならどの言語も理解できないほどの特異な書き方や奇妙な省略もなくどれも似たようなもんだ
どれか一つで書かれていれば普通のプログラマーなら読めるだろう
それでもわからない部分があれば質問したら皆が教えてくれるぞ

>>195
ええその通りです。
ですから使いどころを間違っていると思うのです。

>>200
普通のプログラマじゃなくて雑魚なんで
Rustで書かれたコードはわからないしRustの説明が欲しいわけじゃない
C/C++で書かれてれば説明無用だから全部わかるならC/C++で書いてくれない？

Ruby の無限generator は、遅延評価する。lazy

普通に、メソッドチェーンを左から処理していくと、
無限に処理できないので、右から処理していく

素数は、6 で割って余りが、1 か5

余りが3なら、3で割り切れる。
余りが2, 4なら、2で割り切れる

素数に2,3が含まれるの忘れてる？

if (25 % 6 == 1) {
//25は素数？
}

>>205
さすがに必要条件と十分条件がわからないのはどうかと思う

>>206
わからない
説明して

>>194
その考え方がまさに木を見て森を見ず

>>207
6で割って余りが1か5になるのは素数であることの必要条件や
xが素数⇒x%6=1,5

その事実を利用してまずは数を6で割って余りが1 or 5のとき
改めて素数かどうかを判定する関数に通すってことか？
rem = X % 6
if ((rem == 1 || rem == 5) && is_prime(X)) {
// Xは素数
}
else {
// Xは合成数
}

必要十分を理解してないエンジンは無価値

電気モーターの時代だから。

>>195
発信、受信、仲介、合成、創造？
コンピューターサイエンス分野を見てもRust公式を見てもそんな用語は１つもないけど
それってもしかしてあんたの個人的な思想ですか？それなら知りたくないのでウザいので黙っててもらえますか？
したがって今回のRustオジサンは気持ち悪い基地外だと思います

>>213
気持ちはわかるけど最後の一文が個人的な気持ちになってて同じ穴の狢になってない？

>発信、受信、仲介、合成、創造
たしかにこの用語なんなん？ どっから出てきたの？
どの界隈のコンセンサスで得てる言葉なの？

>コンサンサスで
じゃなくて、コンセンサスを

ワイもこの用語はわかんなかった

仲介なんて不動産屋でしか聞いたことないわw

イテレーターを作ったことがない初心者プログラマーには理解が難しいと思うが
命名はともかくイテレーターがそのように分類されることは俺でもわかるぜ

>(1) 発信イテレータ … >>174で示しました素数生成、レンジ(0..n)、配列やVecに対するiter()などチェーンでは先頭に来るもの

これはRustだとimpl Iterator for XXXのみ実装のイテレーター
つまり他者のnext()は利用せずに他者に対してnext()を提供

>(2) 仲介イテレータ … map()、filter()、enumerate()などチェーンでは中間に来るもの

これはRustだとimpl Iterator for XXXおよびimpl XXX for Iteratorと両方実装のイテレーター
つまり他者のnext()を利用しつつ別の他者に対してnext()を提供

>(3) 受信イテレータ … find()、fold()、collect()などチェーンでは最後に来るもの

これはRustだとimpl XXX for Iteratorのみ実装のイテレーター
つまり他者のnext()を利用するが他者に対してnext()を提供せず

以前に議論されていた消費者プログラマー(?)だと区別を一生気付かないままかもしれぬ

本来の用語は何？

>>218
デザインパターンのMediatorとかでは聞いたことあるのでは

>>220
2-4あたりをひっくるめてiterator adaptorというのはよく聞くけど細かい分類は >>195 の造語っぽい

>>219
自演バレバレやぞｗ

>>220
知らん
しかしプログラマーとしてはそれらの違いは必須の知識
なんせ真逆だからな
impl Iterator for XXX
impl XXX for Iterator

>>222
わざわざ知らない役をやって同調するバカをおびき寄せてから知ってる役をしてるってか？
しねーよ

足し算で素数を求めるアルゴリズムについて知りたいんだが誰かC/C++で書ける人いないの？

独自に分類名を付けようとする試みは評価するが
チュートリアルに書いてるレベルの内容で
「初心者プログラマーには理解が難しいと思うが」とか言っちゃう初心者プログラマーはどうかと思う

公式用語はsource、adapter、consumer

イテレータはライブラリ作者と利用者の間でループをやり取りするには便利なものです。
しかし、それ以外で使ってもパッとしない。

>>203 >>210
素数列の生成でそんな何度も割り算しまくるような無駄はしないはず
そんなことしていたら足し算平均2.5回のより遅くなってしまう

試し割り法で検索しろ

>>228
素数が足し算平均2.5回程度で求まるアルゴリズムを説明してくれないか？

Rustという世界最高の言語があるのに、なぜRubyを使うのが正しいのか。
リーン・スタートアップという本を読めばわかるよ。

Ruby on Railsは、GitHub, Airbnb, Disney, Hulu, SoundCloud, Shopify といった世界的に有名な企業や、
日本国内でも、note、クックパッド、freee、マネーフォワード、Progate、Qiita などで使われている

2021年10月には、GitHubのコピーで、Railsを使い続ける宣言をしている、
GitLab が上場し、時価総額は約1.9兆円！

一方、GitHubはGo へ以降する

Railsを使う理由を端的に言えば、もうかるから

Ruby biz Grand prix 2020 大賞を受賞した、Ruby の女神・池澤あやかも言ってる。
他の言語では開発者を確保しにくいので、Railsに切り替えた

Mediator は、空港の管制塔

>>214
仲介手数料、信用創造、お前が同じ穴の狢、アホのRustオジサンです

>>173
1億までの素数を全て生成するのに足し算2.5億回で済む理由がわかった
素数でなければ1万以下の素数が約数として必ずあるから順に最大素数9973まで調べるだけでよい
1億/2 + 1億/3 + 1億/5 + 1億/7 + 1億/11 + … + 1億/9973 = 約2.5億の足し算で原理的には済むはず

>>224
ある数がある数で割れるかどうかのテストに足し算を使っているだけ。
例えば12を3で割れるかどうか調べる場合、0 3 6 9 12と足し算していって、12が見つかったので割れる。

エラトステネスの篩、のことなのでは？
でも1億分のバッファとか、勿体ない気がしますね…

そこで区間篩ですよ

発見済みの素数を使ってループして数Xが素数かどうかを調べてるだけだろ？
足し算平均2.5回って意味不明なんだが？

>>239
1億までの素数列挙の場合が足し算平均2.5回なだけじゃね？
>>173を見る限り
100万までの素数列挙なら足し算平均2.2回
1万までの素数列挙なら足し算平均1.9回
足し算の回数はO(N log log N)とあるから多少増えていくのだろう

そう書いていたら謎が解けた

>>235
＞ 1億/2 + 1億/3 + 1億/5 + 1億/7 + 1億/11 + … + 1億/9973 = 約2.5億の足し算で原理的には済むはず

これは1億✕(1/2 + 1/3 + 1/5 + 1/7 + 1/11 + … )だから括弧内は素数の逆数の和でlog log N
1億がNだから足し算の回数はO(N log log N)なのか

>>239
素数かどうかを調べるのは>>236が書いているように足し算だけで可能です
必要となる足し算の数は>>241が書いているようにO(N log log N)です
足し算平均2.5回は1億まで素数を列挙した時の話であって>>240が書いているようにNに対してわずかですが増えていきます

>>242
C言語でいいから加算で素数を求めるアルゴリズム書いてくれない？

このスレで出てきているテレーターがよくわからんのだけど、wikipediaの定義と違うんかいな？
https://ja.m.wikipedia.org/wiki/%E3%82%A4%E3%83%86%E3%83%AC%E3%83%BC%E3%82%BF

>>244
その日本語wikiは怪しいので英語のwikiを見るといい

100回繰り返すのと1億回繰り返すのとどっちがマヌケに見えるか、億という言葉を使えば賢く見えるのか？
億回繰り返さないと理解できないのか、汚コードRust相談室と化したC vs C++ vs Rustスレに未来はあるのか

隔離スレに未来などあるわけあるか

>>244
実際のコード例で体験していくと理解が早い

例えばこの計算をしたいとする
>>235
> 素数でなければ1万以下の素数が約数として必ずあるから順に最大素数9973まで調べるだけでよい
> 1億/2 + 1億/3 + 1億/5 + 1億/7 + 1億/11 + … + 1億/9973 = 約2.5億の足し算で原理的には済むはず

コードは>>176の素数生成イテレータも使って以下のイテレータ4つの連鎖で求まる

let result: i32 = 素数生成::<i32>()
　.take_while(|&p| p < 10000)
　.map(|p| 100000000 / p)
　.sum();

途中のtake_while()は条件を満たす間だけ取るイテレータでこの場合は「1万未満」が条件
map()は変換するイテレータで「素数pを1億/p」へ変換している
最後にsum()で流れてきた1億/pを「全て足して」目的を達成

このように個々の単機能イテレータを複数組み合わせて連鎖させることでプログラミングできる

まーたイテレータの定義をよくわかってないやつがヘンテコな説明しちゃう

ヘンテコなとこに気がつけなかったんだけど、どのへん？

今どきの言語のイテレータは>>248で合っている
しかしC++のイテレータは低レベルでポインタを抽象化したものと考えたほうがいいので注意
C++にもようやくmap()に相当するものが入ったが他言語とは異なりtransform()という名前など使いにくい
今どきのプログラミングしたいなら素直にRustを使ったほうが便利

>>250
イテレータとは何かを分かってない
用語の使い方見れば一目瞭然でしょ

分かってない人が書いた説明を読むよりもある程度査読されてる英語のwikiや各言語のリファレンス見たほうがいい

この文中に>>入れる自作自演の同一人物の基地外Rustのくせはほんと気持ち悪い。また引用で > 使う

伝統的には値を生成するものはジェネレータと呼ぶわな

>>253
はちみつ病だからスルーしてさしあげろ

>>254
それは観点が違うな
値を生成するものであってもイテレータとして機能するものと機能しないものがある
つまり重要な点はイテレータとして機能するか否かのみ
Rustの1..nやこのスレの素数生成はイテレータとして機能しているから明白にイテレータ

ジェネレータはみんなイテレータだから

やっぱり頭がおかしいよ、1..nはRange { start: 1, end: n }と同じ。Rust公式でもイテレータじゃなく
単にRangeと言っているだけなのに、それが機能するかという観点ならfor inが無ければ機能しないから
イテレータじゃない。collect()がイテレータをコレクションに変換するように、for inで(暗黙)変換されるだけ。
こいつ、あちこちで暴れてる

RangeはIterator実装してるからrustの定義ではイテレータではあるのでは

汚コード厨まだ居るのか

>>258
君もイテレータがわかってないお仲間さんなので仲良く勉強しとけ

プログラミング初心者でもないのにイテレータを理解してないやつがRustスレに多いのはなぜ？

ここ本スレではなく隔離スレ
スレ民の目的はただの冷やかし

"仲介イテレータ"
約 2 件 （0.26 秒）

すげー、全世界で、このスレにしかその言葉は存在しない

厨怪イッテレータ

>>262
一番レスの多い自演厨が理解してないから、そう見えるだけ

イテレータには狭義のイテレータと広義のイテレータがある
広義のイテレータは狭義のイテレータとイテレータメソッドを合わせたものである

(A) イテレータ(狭義)
Rustで言えばtrait Iteratorを実装するもの
コード上で「impl Iterator for 各イテレータが返す型」となって現れる
各イテレータが返す型は通常structでありimpl Iterator<Item=T>を満たす
メソッドとしてnext()を持ちこれがOption<T>を返す

(B) イテレータメソッド
Rustで言えば上述イテレータ(狭義)のメソッドとなるもの
コード上では「impl 宣言用トレイト for Iterator」の中で現れる
各イテレータメソッドが返す型は任意でありfor_each()のように無しもある
対象となったイテレータ(狭義)のnext()を利用する側となる

>>195
| (1) 発信イテレータ … >>174で示しました素数生成、レンジ(0..n)、配列やVecに対するiter()などチェーンでは先頭に来るもの
| (2) 仲介イテレータ … map()、filter()、enumerate()などチェーンでは中間に来るもの
| (3) 受信イテレータ … find()、fold()、collect()などチェーンでは最後に来るもの

その分類で言えば
(1) ＝ (A) かつ not (B) ＝ イテレータ(狭義)だが イテレータメソッドではない
(2) ＝ (A) かつ (B) ＝ イテレータ(狭義)であり イテレータメソッドでもある
(3) ＝ not (A) かつ (B) ＝ イテレータメソッドだが イテレータ(狭義)ではない

>>267
>広義のイテレータは狭義のイテレータとイテレータメソッドを合わせたものである
この定義のソースはどこ？

素数生成君と仲介イテレータ君は同一人物だったのか
どおりで

>>267
> Rustで言えばtrait Iteratorを実装するもの
これは無理矢理名前をつけるとすれば Iteratee と呼ぶべきでイテレーターではないのでは

こいつ何度間違っても全く反省しないなww
良い子は鵜呑みにしないで自分で調べようね

あ、>>270のことじゃないからね

>>270
詫びがてら説明しておくがイテレータは数えあげる人のこと

「次くれ」→ 「はい、どうぞ」
「次くれ」→ 「はい、どうぞ」
「次くれ」→ 「もうありません」

数えあげる対象物を数えあげる人自身が持ってる場合もあれば持ってない場合もある
impl Iteratorしてるのがイテレータなのは間違いない

>>270
君の中ではそうなのかもしれないが
世間では>>267の(A)をイテレータと呼んでいる
そしてイテレータパターンでもnext()を持つものをイテレータと呼んでいる
したがって>>267の説明で正しい

出典もなしに能書き垂れるのやめろ

デザインパターンの一つであるイテレータパターンの説明図 (wikipediaより)

next()を持つものがイテレータ
つまり>>267の定義で合っている

視野が狭く思い込んだら多くの人が警告しているのに完全に無視し「定義」だの仲介だの創造だの自分勝手に講釈を垂れる

Rust公式Bookでも同じ

https://doc.rust-jp.rs/book-ja/ch13-02-iterators.html
全てのイテレータは、標準ライブラリで定義されているIteratorというトレイトを実装しています。
Iteratorトレイトを実装するには、Item型も定義する必要があり、
そして、このItem型がnextメソッドの戻り値の型に使われています。
イテレータに対して直接nextメソッドを呼び出すこともできます。

じゃ>>248が間違ってたんだね

素数生成イテレータ
take_while()イテレータ
map()イテレータ
sum()イテレータ
4つの単機能イテレータの連鎖で求まるだっけ？

>>267に照らし合わせると
上3つが狭義のイテレータ
下3つがイテレータメソッド(広義のイテレータ)
って感じかね
間違ってるとまでは言えまい

イテレーターの定義はIteratorを実装してる型で良いと思うがそれがどう C vs C++ vs Rust に繋がるのか

>>280
そりゃ間違ってた本人の言い訳定義だからな
御本人さんよ

イテレータメソッドというのは多くの言語では一般的にはイテレータを返すメソッドのこと
Java, C#, C++, JavaScript, Python, Ruby, Scala等々

RustではIterator Trait’s Methodsの意味で
“iterator methods”という言葉が使われるがこれは訳すなら”イテレータのメソッド”

Rustに限った話でもIterator Traitの個別メソッドを
”イテレータ”と呼んでるのはnext()を除いて聞いたことがないので
広義のイテレータを定義してるソースがあるなら提示してもらいたい

>>283
必死こいて言い訳のソースを調査中だから期待して待っててね

javaだと
public interface Iterator<E>
ここにあるメソッドをiterator methodsと読んでる人居るね
まあ単にイテレータのメソッドってことなんだけど

>イテレータメソッドというのは多くの言語では一般的にはイテレータを返すメソッドのこと

ググってみたがほとんど用例が見つからん。

ばっかもーん！それがイテレータだ！定義しろ〜！
みたいな

>>284
いいわけが見つからず
必死に話題そらしを始めるに1000ペリカ

発信イテレータ<Item=オレオレ定義>

たしかに「イテレータメソッド」だと「イテレータ生成メソッド」を意味する用例もあり曖昧さがある
「の」を入れて「イテレータのメソッド」とした方がいいだろう

(A) イテレータ
trait Iteratorを実装するもの
コード上で「impl Iterator for 各イテレータが返す型」となって現れる
各イテレータが返す型は通常structでありimpl Iterator<Item=T>を満たす
メソッドとしてnext()を持ちこれがOption<T>を返す

(B) イテレータのメソッド
イテレータのメソッドとして機能するもの
コード上では「impl 宣言用トレイト for Iterator」の中で現れる
イテレータの各メソッドが返す型は任意でありfor_each()のように無しも可
対象イテレータのnext()を利用する側となる

// 例: イテレータ CountUp
struct CountUp(isize);
impl Iterator for CountUp {
type Item = isize;
fn next(&mut self) -> Option<isize> {
self.0 += 1;
Some(self.0)
}
}

// 例: イテレータのメソッド average()
trait AverageMethod {
fn average(&mut self) -> isize;
}
impl<I: Iterator<Item=isize>> AverageMethod for I {
fn average(&mut self) -> isize {
let mut len = 0;
let mut sum = 0;
while let Some(n) = self.next() {
len += 1;
sum += n;
}
sum / len
}
}

fn main() {
let a = CountUp(0).take(99).average();
assert_eq!(a, 50);
}

反応がないとうんこしたと流してない。不安に襲われるような感じ

>>291のイテレーターとメソッドをCやC++で実装することも可能ですか？
どんな感じのコードになりますか？

Rustを勧めるとだけ言っておく

ここにいるRust屋はC/C++が書けないってことがはっきりしている

単純にC++が不得手な分野が多すぎ
Rustだと楽に書けるからこのスレに書かれているコードがRustばかりになっている
プログラミング言語としての優劣の違い

Rustだと楽にかける分野ってメモリ安全性関連以外ない気がする

Rustはイテレータ作れる文法用意されててスゴイ言語ってことか
まあトイプログラム作るのに秀でた言語いじって喜んでるレベルじゃ
あらゆる分野のアプリケーションが書かれてきたC++の実績は理解できないだろうな
せいぜい不得意なことと言えばスクリプト言語で代用される分野くらいだろ

>>297
パターンマッチがハマるプログラムは書きやすいと思う
言語処理系とか

>>299
なるほど
でもそれってc/c++でもenumと構造体か共用体組み合わせればできるよね？

>>297
マルチスレッドは楽だと思うけどな
というかC++が辛すぎる

>>300
できるできないの話じゃなく
どちらが楽にできるかの話をしてたんじゃないの？

C++20 からコルーチンが入ってジェネレータは割と書きやすくなったよ
とはいえイテレータのほうが従来通りのポインタ的用法に引きずられてるからなんともだけど
https://cpprefjp.github.io/lang/cpp20/coroutines.html

>>300
c++でもできるけどenumの値とunionのvariantの組み合わせはプラグラマが意識しないといけない
rustだとmatch式のcond部分に値を書けばrust-analyzerがすべてのarmのスケルトンを作ってくれるから
穴埋めしていくだけで処理が書けて楽

>>304
まあrustの方がc++よりパターンマッチング楽なのは認めるよ間違いない

C++と比べてRustだとメモリ安全にできるから、スレッドセーフなコードも誰でも書けるよ
そういったメモリ安全関連の利点がなきゃ存在意義のない言語だよね

書いたコードが高速に動作するかどうか、とかはまた別の話だけど

>>301
マルチスレッドの並列処理だけでなくシングルスレッドマルチタスクの並行処理も便利かつ安全に書けるところも

>>304
match式だけでなくletやif letでのデストラクチャリング＆マッチングがある点も
一方でC++は多重構造の分解分配もダメでif letも値付きenumもないからほとんど何も出来ない

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1371r3.pdf
パターンマッチング構文が提案されてる。

>>298
C++で書けることは全てRustで書ける
C++が優位な点は過去実績しかない
これは両方やればはっきりと認識できる
そのスクリプト言語的な記述や利便性がRustにあるという認識は正しい
かゆいところにも手が届くスクリプト言語という側面もある

Rustはスクリプト言語なのか。

>>306
CやC++と同等の性能特性を持つ言語の選択肢は限られてるから安全性以外の理由でRustが採用されることもあると思うよ

Rustって循環参照安全に書けないんじゃなかったけ？

>>308
構文のアーム「=>」や後置のifガードなどRustのmatch式の後追いパクリw
それが仮に導入できても要である値付きenum(＝タグ付き共用体)を持たないC++では活用に限界

>>312
曖昧すぎてどういう状況で何が書けないとの主張かわからないけど
C/C++で安全に書けることはRustでも安全に書ける
つまりRustで安全に書ける範囲の方が完全に広い

>>313
C/C++にはRustでいうところの安全(⇔unsafe)はないから "C/C++で安全に書ける物" が何を意味するかわからない

そもそも >>309 の "C++で書けること" や "Rustで書けること" ってどう定義されるの？

>>312
循環参照は安全に書けるよ
https://doc.rust-jp.rs/book-ja/ch15-06-reference-cycles.html

Rustのmatch式はScalaの後追いパクリw

ML系のパクりだよ
https://doc.rust-lang.org/reference/influences.html

プログラミング言語としての比較結果は明瞭

適用可能な範囲は同じかつ最速
いずれもGCがなく低レベル操作も可能
Rust = C++ = C

したがって勝負は他の点
コード記述が楽に簡潔に書けるか
Rust > C++ > C

安全なコードを書けるか保証できるか
Rust > C++ > C

>>318
> いずれもGCがなく低レベル操作も可能
これはRustはnightly使うこと前提？
低レベルな機能についてはまだまだunstableなものが多いので少なくともstableなRustではC/C++でできること (処理系依存なものも含む) がすべてできるとは言えないのでは
https://doc.rust-lang.org/stable/unstable-book/

新たな(pre-)RFCも日々提案されてるし現状で十分とあぐらをかくべきではないと思う

ということは、RustはC++よりJavaと比較する言語なのでは？

>>309の
> C++で書けることは全てRustで書ける
を念頭に置いた話で "全て" は言い過ぎ、C++でないとできないこともあるだろうと言いたかった

CやC++の低レベル操作は Rust でも "だいたい" できて大抵のユースケースでは困らない
と言うのが正確だと思う

Java は GC あり VM 言語だから低レベル操作の観点でのRustとの類似度で言ったらCやC++の方が近い

メモリーの安全性を強調する言語と言えばJavaが筆頭に挙げられるのでは？
Javaは実行時最適化を行うのでC++より速いと主張されます。
この点もRustと酷似している。

JavaもRustもC++と比較した優位性を主張するのですが、JavaとRustならどちらが優れているのでしょう？

>>319
勘違いしてないか？
それらのほとんどは既に別の手段でコードを書くことができるが更に利便性を高めようと検討されている機能だぞ
C++で言えば>>308提案のマッチングは現在できないがそれが無くとも別の手段でコードは書ける話

>>320
C++とRustは適用可能な範囲が同じ
Rustの記述性能が高いという違いしかない

>>322
Javaはガベージコレクションがあり適用可能な範囲が狭い
さらにヌルポインタ例外もありJavaはメモリ安全ではない

Javaは組み込みにも使われ、それどころかpico javaというJavaを効率よく実行できる組み込み用プロセッサのアーキテクチャ迄あるんですよ。
完全にRustと一致するじゃないですか。
実績を考えたらRustを完全に包含しています。
なぜJavaとの比較を嫌がるのですか？

もしかしてRustはJavaに負けているのですか？

GCがあってデータ競合も起きないマルチパラダイム言語で、C,C++以上の爆速で動く処理系があるとするならそら優秀だろうと思うわ

Javaは実際にはそんなに爆速じゃないだろうし、データ競合の対策がしやすい言語とも思えんけど

活気があったころは、C++と比較して20倍速いと主張するサイトもありましたよ。
まさに爆速です。
Rustと似ています。

安全性という観点では、RustはHaskellと似ているように思います。
熱心なHaskellユーザーはコンパイルが終わればバグが無いことを保証されると主張します。
Rustと全く同じです。

Javaを含めるとこうなる

安全なコードを書けるか保証できるか
Rust > Java > C++ > C

Javaはヌルポインタによる参照でエラー例外が実行時に起き得る
Rustはそれさえも起きない
したがって速さだけでなくメモリ安全の点でも Rust > Java が確定済
Javaが勝てる点がない
そのためJavaを捨ててRustへ移行するプロジェクトもある

Haskellもまた、C++と比較して優位性が主張されることの多い言語のひとつです。
しかし、JavaやRustと比較されることは一切在りません。
Java、Rust、Haskellでは、どれが最も優れているのでしょう？

でもRustはJavaより遅いですよね？
Javaは実行時最適化によりC++より20倍速いことがbenchmarkで判明していますよ。
10年以上も前に。

C++を改良したD言語もあります。
DとRustならどちらが優れているのでしょう？

出自からして、D言語もまたC++と比較して優位性が述べられる言語のひとつです。
しかし、RustやHaskellと比較されることは在りませんね。
どちらが優れているのでしょう？

まずは決定的な違いを勉強しなさい
GCのない言語　Rust C++ C
GCのある言語　Java D C# Go Haskell Python Ruby JavaScript ...

>>335
GCの有無で何が変わりますか？
JavaやRuby、Pythonは組み込みにも使われますし、宇宙にだって行きます。
Rustよりずっと広範囲に使われています。
Rustで作られた実用的なソフトウェアはFirefoxしかないじゃないですか。
しかも、そのFirefoxだって熱心な信者以外誰も使わない。
それと比較したら、これらの言語は実用的に使われています。
GCが在ろうとなかろうと。

>>324
大体代替手段があるのはそうだと思います
例えばnaked functionやglobal_asmは別途asmなりCなりからオブジェクトファイル生成してリンクするという代替手段があります (これがありならC-FFIできる言語は皆同等になってしまいますが...)

もともと C++ でできることは "全て" できるというかなり強い主張をされてた人がいたのでそれは言い過ぎじゃないかと言いたかっただけです


>>332
ご参考まで
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/java.html
他の言語との比較もありますよ

Rustのポジションに取って変わりたいなら、RustみたいにLinuxのKernelコードに取り込まれていってくれるとわかりやすいんだけどね
なぜC++を含む他の言語はLinux Kernelに採用されないのか、って考えると差が明瞭になってきそうだ

Firefoxのバグの多さを考えても、Rustはバグを生産する言語のように思います。

>>338
ドライバにクラスは必要ないからでは？

>>336
RubyやPythonは遅すぎ＆メモリ食い過ぎで話にならない
例えばクックパッド社はRubyで書かれていたのをRustへ置き換えて経費節減に成功している

そういえば Windows 10にRust使う話ってどうなったんだろうか

>>336
以下の記事にメモリ安全な既存の言語ではだめでCやC++やRustでないといけない理由
それらの中でもRustが良いとされる理由が書かれていますよ
https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/

>>339
FirefoxについてC++コードをRustに書き換えたらセキュリティに関わる脆弱性数がどうなるか分析した記事がありました
https://hacks.mozilla.org/2019/02/rewriting-a-browser-component-in-rust/
結論としては完璧ではないけどRustの方がバグを減らせるということのようです

MS ResearchやGoogleのAndroidチームも類似の調査をやっていてRust採用は効果有りと判断しているみたいです

JavaやHaskellも多くの人がC++より優れていると分析しています。
速く容易で安全なのです。
全ての点でC++を上回っています。
では、それらの言語を比較した場合、どれが最も優れているのでしょう？

ほとんどすべての言語がC++より優れていると主張します。
という事は、C++はもっとも劣った言語のひとつなのです。
Rustはもっとも劣った言語より優れていると主張しますが、優れた言語、例えばJavaやHaskellと比較したら、かなり劣っているのでは？

多くの人がRustとC++と比較している
比較するなら優れたもの同士を突き合わせるはずだ
なのにJavaやHaskellは影も形もないつまり論外ってことだ
全ての言語がC++に対して優位性を主張するのも
C++が最も現実的で優れた言語だと認めているからであって
わざわざ劣っているものと比較する必要なんてないからだ

>>344
JavaやHaskellがC++より常に高速というのは明確に誤りです
https://benchmarksgame-team.pages.debian.net/benchmarksgame/index.html

ではC++がこれらの言語より優れているかというとそうではありません
言語にはそれぞれ得手不得手があります
唯一絶対の尺度で優劣を決めようとするのではなく、ある特定の用途に対してどの言語が適しているかという観点で議論した方が生産的かと思います

スレタイ読め。

いつもの人の自作自演

GitHub・Cookpad などは、遅いRuby on Rails から、Go・Rust などへ移行している

2021年10月には、GitHubのコピーのGitLab が上場し、時価総額は約1.9兆円！
こんな大きい時価総額でも、Railsを使い続ける宣言をしている

基本、Railsは中小ベンチャーが、高品質なサービスを作るツール。
2億レコード・取引先が2万社みたいな規模でも、問題ないと言ってた

他には、組み込みのmruby の本も出た。
Webで使えるmrubyシステムプログラミング入門、近藤宇智朗、2020/11

宇宙開発などの組み込み用、MicroPython, Lua, Squirrel の代替になる。
Ubuntu 18.04, C99 対応

人工衛星イザナギ・イザナミで、使っている

C++もJavaも実行時にnull pointerによる参照が起きる可能性があるためどちらも安全性に劣るよね
Rustではenum Option使用でnull pointerによる参照が絶対に起きないことをコンパイル時点で保証した上で
コンパイル後は最適化でOptionがNoneの時にnull pointerを使うという二段構えにより
Rustはコストをかけずに無駄なく安全性の保証を実現しているところに感動した

null安全ぐらいはモダン言語なら当たり前の機能なので、もはやメリットとは感じないわ
例えばTypeScript、Swift、Kotlin、Haskellとか

C++とJavaが前近代的でダメな言語なだけだよな

Javaは速度を追求した言語だから。

Haskellは安全性と並列化を追求した言語です。

RustはHaskellの長所である型クラスをトレイトとトレイト境界で採り入れていたり
HaskellのMaybeモナドやEitherモナドを採り入れてRustの型の核としているところにも感動した

システムプログラミングでCに代替となれるほどRustがイケてるのは、
null安全やメモリ安全はモダンな言語だから当然として、データ競合が起きないことも保証しつつ、実行速度もCに劣らなくて、
それでいてRustと多少のアセンブラだけ使えば、OSや組み込みソフトウェアも普通に記述できるほどフットプリントの小さい低レベルな言語だから

システムプログラミングにはJavaのほうが向いています。
単純に速いからです。
Javaは宇宙でさえ使われる安全で実績のある言語です。
しかも速い。
実行時最適化を行わない言語では無理な速さです。

結局RustはHaskellの真似をするだけの偽物言語にすぎません。
Haskellの並列性、安全保証を移植するには、結局Haskellになるしかないのです。
RustはいずれHaskellになるでしょう。
その時もまだRustと呼び続けるのでしょうか。

>>358
ねー、>>347 無視しないでよー

rustのnull安全？はクリティカルコンテキストでも保証されるんか？

もちろんです。

現状でRustの欠陥は指摘なしなのか
まあ優れた言語だから主流になるとも限らんけど
ここはRust礼賛が多くて参考にならんな

>>360
キチの相手するならメールかなんかでやってくれ

キチの相手するスレやぞ

良いという人だって使ったことないんだから、欠点なんか出てこないよ。

>>361
クリティカルセクションのこと？

int型(32ビット)でyy/MM/dd/HH/mmの形で日時を実装しているプログラムは、2022年1月1日0時0分(2201010001)に32ビットの最大値(2147483647)を越えてしまい、エラーが発生する。そういう実装をしているMicrosoft Exchangeでは既に問題が発生中。
みんな仕事始めになって気づいて大騒ぎに

DosDateTime爆死確認w

>>367
ハードウェア割り込みの割り込みコンテキストのつもりで書いた
社内独自用語なんだと思う
そこは気にせんでくれ

>>361
Rustのポインタ(参照)および実体にはnull/nil/undefined等が一切ない
そのためnull問題が起きることはなく所謂null安全が保証されている

nullになる可能性がある場合は汎用のオプション型であるenum Option<T>型を用いる
このOption<T>はenumとしてSome(T)とNoneの二値を取り型Tは任意な型
つまり所謂NullはenumのNoneで表現され型Tとは異なるためnull問題が起きようがない

これで効率やコストはどうなるのか？
null(RustではNone)が使われない時は型Tのまま扱うので従来と同じ
null(RustではNone)が使われうる時は型Option<T>として扱う
型Option<T>から型Tを使うにはNoneでない確認が必要だがこれこそ必須な確認コスト
ポインタ(参照)の場合は値がnullすなわち0になることがないためコンパイル後はNoneが0で表現される最適化となる
つまり結果的にはC/C++と同じになるのだがRustは上述のようにコンパイル時点でnull安全を保証できる点で異なる

Javaのほうが安全。

ぬるぽ例外が発生するから安全じゃないとか言う書き込みがあった。
これはウソ。
ないほうが良いならCはヌルポを検出できないから安全って事になる。
Javaは検出して例外を発生させるから安全なのです。
キチガイに騙されるな。

>ないほうが良いならCはヌルポを検出できないから安全って事になる。

発生したことを検出できないことと発生しないことを意図的に混同している

Firefoxの惨状を見れば全然安全でないことがわかるのに。
なぜ安全と言い張るのか。

CもC++もJavaも実行時にヌルポ発生するからいずれもダメ
Rustは実行時にヌルポ発生しないことが保証されているから安全

RustアンチがRustを称賛してるのではないか。

その可能性高いかも

学会が自らキチガイを演出する手口に栗卒

RustはC++と同じ匂いがする

このようにRustをやってる奴は性格が捻じ曲がってる

rustってc++より難解だよな
こんな言語が流行るとは思わない

他の言語と比べればめちゃくちゃ難解だし、Rustコミュニティでもどうすれば簡単になるのかいろいろ議論されている

ワイじゃないけど必死に褒めてるのにアンチだとか、ウジ沸いてる

Rustファンも、こんなスレに書き込みしないで初心者向け解説でも書けばいいのにな。

https://seiya.me/this-website-is-now-powered-by-kerla
このOS Rustで書かれている割にはメモリリークで落ちたりするらしんだけどなんで？

必須じゃないけど他の言語も知らないRust初心者が異常に増えてきているからトンチンカンな推しをするだけで
コミュニティの増加は良いことだが、初心者が書いた意味不明なコードを直すのはあんたら
Null安全系の推しをしてるのはド素人

メモリ安全が守れればすべてが安全と謳ってる連中は原発は止めれば安心安全とほざいてた奴等と瓜二つ

>>386
そもそもRustはメモリリークが起きないことは保証してくれない
参照カウントが循環参照にならないようにしたり、不要になった参照が残り続けたりしないようにするのはプログラマの責任
なのでプラグラム側になんらかのバグがあったのではないかと

メモリ管理周りを標準ライブラリやOSに全部任せられる普通のアプリケーションとは違って
全部自分でやらなきゃいけない自作OSだからバグなく作るのは難しいというのはあるかと思う

COBOLならメモリーリーク起こらないよ

>>389
結局C++と同じで習熟甘いやつが作れば問題起きまくりなの？

>>387
Rustを含めていまどきの言語がnull安全なのは常識
むしろC++やJavaが古すぎて様々な点で時代遅れにすぎない
もちろんRustはもっとその先へダングリングポインタ排除とGC排除を両立した点にある

このように攻撃性と倒錯を丸出しを両立してしまうと初心者っぽさが出てとても引っ掛かりやすい
どこで覚えたのかNull安全からダングリングポインタという関連性がない事を言い出す。
ゴミくずが降り積もっていく・・・

>>391
一般的にメモリ関係諸問題のうちメモリリークのみはGC利用でしか解消と判明している
しかし一方でRustではメモリリークを起こすのも意図的にしか起こせない
Rustには所有権の概念があるため特別に複数の所有権を認める特別な参照を
自分で明示的に使用した上でさらに循環参照を生じさせた時のみメモリリークが生じうる
もちろんそのような場面でも通常は弱参照を併用するためメモリリークは起きない

>>386
自分で独自OSのランタイムやGCを作って
その上で稼働させるアプリがリークを起こすかどうかは
アプリだけじゃなく作ったランタイムやGCのロジックに依存するよね

nullで落としてるようなバカがnull安全な言語使っても同じく死亡するコード作るだけにしか思えんがな。
あれで救えるコードなんてほとんどないと思うが。

もっとその先へ！草
上のOS記事の作者はリークというかフラグメンテーションの発生だと推測してるが絶対読んでないね。
「意図的にしか起こせない」はい嘘

nullで落としてるようなバカって例えばGoogleのChromeチームとかかな？
まぁ全人類バカなのでしょうがないね

ポインタ(参照)になぜかnull値を許してしまう欠陥言語でのみnull問題が起きる
そうでない普通の言語にとってnull安全は当たり前でありそれを意識することすらない
欠陥言語の存在に対してのみnull安全なる言葉の存在意義がある

>>395
そりゃランタイムやライブラリがバグってたらしゃーないわ

>>396
いや、コンパイルエラーになるからそこでちゃんと直せばいい
まあバカがコンパイルエラーを回避することが目的になって余計ひどいことになる未来もあるけどw

null安全はマジで当たり前すぎてメリットでもなんでもないから
nullの話なんてしたくないわ

そもそもnullのある言語でもnull参照で死ぬなんてのは
よっぽどのクソコードでテストもしてないときだけだろ

関数の定義からnullableが否かが分かるのがOption<T> のうれしいところと思う
加えて引数や戻り値の所有権が分かるのもRustのうれしいポイントかと

fool proofの話をすると Option<T> でも闇雲に unwrap はできるので考えなしのプログラムだとクラッシュする点は変わらない
SEGVじゃなくpanicになるとか、落ちる可能性のある箇所が明示される点でnullよりはマシだが

ほんま、そういうことやな
null安全で助かるケースなんてそもそもわずかしかないんだ
unwrapだとかゼロ除算だとかいろんなロジックミスで結局は落ちる

borrow checkerのおかげでデータ競合が起きない、とからへんが重要なメリットと思う

いやいやww

>>402
> よっぽどのクソコードでテストもしてないときだけだろ
そう言うのがボロボロ転がってますけどw

こちらはNull安全協会です、今なら3,000円お支払い頂くとより安全になり免許証入れまでついてます。
本協会ではNullは許しませんが、DBなどの道路にNullが転がっています。
また外部値など入力が無いことを示すのはResult::Errや特異値:-1やNaNなどで表すものではありませんので
クソ設計はやめてください、Option::NoneでNullを示し、ほかの言語と同じく必ずmatchで検査してください。
unwrapもダメです。Null安全協会では皆様に頂いたご声援でド素人が語れてゴリラのマウントのように
ウッホウッホホと潤っています。またNull安全語り部Rusterの攻撃性は以上ですので近づかないでください

C++の利点は何だろ？

>>409
自由であること

Rustはコーディング刑務所

Null安全性はまともなUXを提供したい場合に生産性を改善する道具
なくても落ちることはほとんどないみたいな視点でしか捉えてないなら価値を理解してない

誰のUXやねん
誰の生産性やねん

>>386
GCはメモリーリークおこすし
どこで起こすかが実装によって変わる

GCはゴミなんよ

>>409
もっとも健全なアプリを作りうること

>>409
鼻から悪魔が出てきたりしても言語仕様を逸脱していないこと

Rustはコンパイルできたら問題は起きないみたいに思ってたけど違うのね
これじゃやっぱり初心者に毛が生えたようなのがゴミコード量産するのかな

ゴミコーダ矯正所

それはそう
たとえPrologを使ってもバグはなくならない

でもコンパイラのチェックでなくせる類のバグならなくしたいよね

コンパイルを通すために問題の発生するコードを書くとかも考えられるんじゃねーの
そっちのほうが分かりにくいような気がする

>>417
あらゆる問題が起きないかというとそうではない(というかそんなプログラミング言語存在しないと思う)けど
大部分のコードのメモリ安全性がコンパイル時に保証されるのはかなり大きなメリットだと思う

例えばuse-after-freeやバッファオーバーフロー、データ競合なんかは問題が発生してもプログラムかその場でクラッシュするとは限らず、しばらく正しく動くように見えてしまう場合もある
この手の異常の原因特定は難しいので、rustでコンパイルエラーや実行時の問題発生時のpanicなどで即問題箇所が分かるようになっているのはかなり嬉しい

初心者に毛の生えたようなのがゴミコード量産しないようなプログラミング言語ってそもそもどういったものなんだろうか
記述に自由度がなく誰がどう書いても同じになるような言語？

それpythonがうたってたきがする

386みるとメモリリークの原因が不明っぽいんだけど
言語処理系にメモリ関連任せられるにしても結局原因不明のバグが残るんじゃ意味ないんでわ

>>424
OS書いてるのに言語処理系にメモリ管理任せられるわけないだろ
自作したメモリアロケータのバグとしか思えんが

>>424
バグの数が0じゃなきゃ意味がないというのは違うのでは
100個バグがあるのと1個しかないのでは開発効率が全然違う

>>409
C++の利点は過去資産
既にバグが枯れた過去資産を活用するのが得策
その他の点ではRustが全て完全に有利

Google&MS「バグの70%はC/C++。Rustにする」
http://2chb.net/r/prog/1619943288/

C++でうまくかけないヤツとか構造化の仕方がヘタクソなだけだろ

>>424
そう思うんならそれでいいじゃない
意味ないってことで

>>430
それでいいということを認めるなら、>>424にもちゃんと反論しろ

>>428
で、バグが減ったか？まるで変わらんやろ。馬鹿馬鹿しい。

C++の存在意義がゼロになったわけではない
C++で作られた過去の莫大なライブラリは今後も併用される
C++しか使えない過去のプログラマーの活用のためにC++を用いる案件もしばらくは残る

議論したいならまず相手を選ぼうね
ルサンチさんを相手にしても理性的な議論にはならんから

個人的には大規模なC/C++の組み込み開発で散々メモリ破壊系の不具合に泣かされてきたから組み込みでRustを使う流れがきてるのに期待してる
国産RTOSだとKMCのToppersベースのOS、SOLIDが最近Rustに対応し始めた

>>435
メモリ破壊ってそんな起きる？
lock,off,len,remainさえ揃ってたら破壊なんて起きなくね？

>>436
そんなには起きないけど1,2機種に1個ぐらいは難問と言われるような不具合があるかな？
共通してるのは再現性がとても低いかつランダムな領域のメモリを破壊する
でもいざ何週間もかけて仕込み入れて再現されて原因特定するとしょーもない不具合だったりする
それこそRustじゃコンパイル通らないような初歩的な原因だったこともある
静的解析ツールは回してるけどどうしても漏れることはある

嘘くせえｗメモリ破壊を理由にRustに期待とか意味わからん
MMUがちゃんと設定できてないか、スタック不足でリークしてるだけとか、あるいはスレッド競合に見えるし
比べてる対象がOS前提のRustと、そんなもの無い開発を比べてないか

>>436
同意だな
Cなんて学習の過程でなんぼでもメモリ壊すもんだから
逆説的だけどメモリなんて壊し慣れてるんだよ
どうやって壊してるのかどうやったから壊れたのか
だからだんだん目新しい壊し方が無くなってきてスリルは無くなる

バカだろおまえ

このスレがム板内で一番勢いあるのが笑える
C++やRustの本スレより勢いあるやん

>>437
すまん、よく分からんわ…

>>439
分かる
壊し方も調査方法もパターン化してくるし、熟れてくると糞コードセンサーが働いて「この辺じゃね？」って見当つくしな
ログもコアもダンプもないなら難しいけども

本当に調査が難しいのは、並列処理があって競合状態が起きてるときかなあ

ランダムな領域のメモリを破壊が毎回起きて組み込みやってます！キリッ

HaskellとRustはコンパイル出来た時点でバグが無いことを保証される。

釣り針見えてますよ

これが釣りに見えるのか。
驚きです。

HaskellとRustのバグはバグじゃなくて仕様と呼ぶからなｗ

どうせバカが使ってもRc、RefCellばっかのコードで全く所有権なんて活かせないコードにしかならんよ。

>>447
rustのコンパイラって不等号の向き間違ってますよとか教えてくれるの？

日付比較で不等号の向きで古いファイルが消されるか新しいファイルが消されるか決まることもあるしな
ふるい分けファイルの方が日にち稼いでいるからデカいはずだと錯覚するヤツが必ずでてきてデススパイラル撒き散らしたりな

×ふるい分け
○古い

仲介イテレータ君かな
「バグ」という言葉すら独自解釈

釣りじゃなくてマジだったらアカンやつだ

でかい釣り針は不都合なものから注意をそらせるために使うもの

>>338
リーナスが例外（パニック含む）を受け入れないから

Rustなら例外機構がそもそも無いし
パニックを引き起こさないチェック付きの代替も揃っているからな

SanitizerなしでCやC++書ける人にはRust不要かもね
逆に必要な人はRust使った方が幸せになりそうです

例外機構≠パニックという主張はGoでもあるが無理がある。チェックも近代的な言語ならほぼある

Rustは標準ライブラリの条件付きコンパイルをサポートしてるしそのうちpanic-freeな標準ライブラリも作れるようになるんじゃね。知らんけど

Rustで特別に安全っていうのはあくまでメモリらへんの事なんだよね
ダングリングポインタ、データ競合、未初期化の変数を読んでしまう、とかみたいなのは起きない
こういうのはC/C++だと巨大プロジェクトではどうしても抜け漏れが出るし、よく脆弱性になるからこれが保証されるだけでもめちゃくちゃ心強い

そんで例外っていう危うい仕組みはなくても、他にも気をつけなきゃいけない事はいくらでもある
例えば内部部割り込み、デッドロック、競合状態、メモリリークとかはunsafe使ってなくても普通に起こるので、
プログラマがちゃんと理解して考えて制御しなければいけない

>>445が明らかに嘘八百なのに、そのことを無視して>>447とか>>453とか言うのはさすがに無能すぎない？

>>462
445 = 447だし、何いってるかわかんない

>>463
「HaskellとRustはコンパイル出来た時点でバグが無いことを保証される。」
が大嘘ということ。
こんなことを言うのは無能か詐欺師。

誰でも知ってる常識を鬼の首を取ったように言うなよ
見てるほうが恥ずかしくなる

>例外っていう危うい仕組み
この捉え方のほうが危うい

>>466
ここで言う例外はプログラミング言語の機能としての例外(大域脱出)のことで一般的な例外処理のことではないのでは

>>435
組み込みでRustを使う流れがきてるのに期待してる

同意

>>467
「一般的な例外処理」の定義をしないで語られても

>>464
お前一人だけこのスレで浮いてるわw
黙っとけ

再帰から一気にジャンプ出来る例外案件

Rustの勉強も始めたが
驚き感動することが多くてはまりそうだ
try/throw/catchがないのに同じことが出来てる仕組みに感動した
?一文字でエラーを上位へ委ねることができたり
単なるenumに過ぎないはずのResult型が巧妙に使えるヤツだったり

>>472
おまえいい加減にしろよ

>>467
一般的な例外処理で大域脱出でないのがあればそう言えるけど、そんなのあったっけ。

>>472
enumといっても値付きenumだからな
値付きenumとマッチング機構のせいでRustにC++が敗北したとみている

>>469
>>474
https://ja.m.wikipedia.org/wiki/%E4%BE%8B%E5%A4%96%E5%87%A6%E7%90%86
この意味での例外
確かに言語でサポートするなら大域脱出になるか

>>476
そのwikiの定義はめちゃくちゃ曖昧だな
回復不能なエラーのことだったり、業務エラーに対するシステムエラーのことだったり
さらには設計で想定されてない問題と言いつつ
ユーザーの入力間違いや他システムと疎通が取れない場合が含まれてたり

>>477
なら例外（処理）の明確な定義ってなんだ？

>>478
話の意図や文脈によっていろんな定義がありえる言葉なんだから
自分の定義を話せばいいじゃん

>>478
まぁ、ここはプログラミング言語を取り扱っているので、各言語ごとの例外機構のことなんじゃないかな

GoやRustなどの言語には例外処理がないと一般的に言われているけど
これはtry/throw/catchといった特別な枠組みが存在しないことを意味してる

いやまず>>477が定義を示すべきだろｗ

> そのwikiの定義はめちゃくちゃ曖昧だな

じゃあはっきりしたやつよろしく

結局いつもの気持ち悪い自演コース

例外が発生しないので安全です。

いやいや、まず>>467が示すべきだろう
示されたWikipediaは曖昧と言うより色々な例外が記載されてるから、この意味での例外と言われてもどれよ？
ってなってるんだから

古典的言語はどれも例外が発生するので危険です。

panicよりマシだろ。

例外が発生しない安全な言語を使うべきです。

例外が発生すると大変危険です。

正確には、例外が発生する「ような」状況、な。

例外すら出さずにpanicするような言語は論外。

元々 >>461 の言う例外とはなんのことかという話で
言語機能としての例外のことを >>461 は指しているのではないかと推測したのが >>467

461 は panic による大域脱出の発生を防げたとしても他にも気にすることがある、と言い換えても良いのかと思う

で >>466 は業務エラーに対するシステムエラーなど他の意味での "例外" (例えばカーネルにおけるメモリ獲得失敗とか) はきちんと取り扱うべきという主張だと思ったので 467 を書いた

変な理解してたらスマン

例外安全性を静的に保証できる言語なんて無かったよな