C vs C++ vs Rust Part.2

**デフォルトの名無しさん** · 2021/12/15(水) 12:35:50.91

競え
※前スレ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

**デフォルトの名無しさん** · 2021/12/16(木) 20:34:01.51

ゲロのようだ

**デフォルトの名無しさん** · 2021/12/16(木) 20:37:46.92

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

**デフォルトの名無しさん** · 2021/12/16(木) 20:54:48.37

>>44
違うと思います
まずunfold自体はループするものではなくこれだけです
struct Unfold<S, F> { s: S, f: F }
fn unfold<S, F, R>(s: S, f: F) -> Unfold<S, F> where F: FnMut(&mut S) -> Option<R> {
　Unfold { s, f }
}
impl<S, F, R> Iterator for Unfold<S, F> where F: FnMut(&mut S) -> Option<R> {
　type Item = R;
　fn next(&mut self) -> Option<Self::Item> {
　　(self.f)(&mut self.s)
　}
}

次に今回のコードで使われているunfoldについてですが
一番外側のunfoldは上述の構造体を返すだけになります
次のunfoldは素数でない数をスキップするだけで残り2つがO(n^2)となるでしょうか
どの言語で書いても足し算のみ使用だとこれは避けられないかと思います

あとコードが汚いとおっしゃる方は同条件で綺麗なコードを示してくださるとありがたいです
CでもC++でもRustでも構いません

**デフォルトの名無しさん** · 2021/12/16(木) 22:36:01.50

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

**デフォルトの名無しさん** · 2021/12/16(木) 23:05:37.82

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

**デフォルトの名無しさん** · 2021/12/16(木) 23:20:42.17

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

**デフォルトの名無しさん** · 2021/12/16(木) 23:59:30.49

>>50
登場していたSomeは値付きenumなのでデータの型です
mapは変換するだけなのでそれ自体にループ要素はないです
一方でfindなどはループを内包している高階関数になりますね
だから>>49にて「今回は可能ならばループを直接使わずに高階関数イテレータ使用」と書いたのです

宿題となっていた類似部分を別関数へ切り出しが出来ました
これでわかりやすくなったでしょうか？

fn prime<T>() -> Unfold<T, impl FnMut(&mut T) -> Option<T>>
　where T: Copy + num::Zero + num::One + num::CheckedAdd + std::cmp::PartialOrd,
{
　unfold(T::one(), |a| {
　　inc(*a, T::one(), |x| x > T::zero()) // 無条件に+1していき次の素数を探す
　　.inspect(|b| *a = *b) // unfoldのため値更新
　　.find(|b| inc(T::one(), T::one(), |x| x < *b) // 自分より小さい数で+1していき約数を見つける
　　　.all(|c| inc(T::zero(), c, |x| x <= *b) // その約数の候補を自分以下で足し算していく
　　　　.all(|d| d != *b)))}) // 自分が倍数になっていなければOK
}

fn inc<T>(s: T, a: T, f: impl Fn(T) -> bool) -> Unfold<T, impl FnMut(&mut T) -> Option<T>>
　where T: Copy + num::Zero + num::One + num::CheckedAdd + std::cmp::PartialOrd,
{
　unfold(s, move |x| { *x = x.checked_add(&a)?; f(*x).then(|| *x) })
}

**デフォルトの名無しさん** · 2021/12/17(金) 00:00:59.02

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

**デフォルトの名無しさん** · 2021/12/17(金) 00:18:54.26

>>51
めっちゃ理解しやすくなったな
まるで宣言型論理プログラミングっぽい雰囲気だ
説明の日本語はこう書くとよい

//素数とは自分未満で次を満たす約数を見つけること
.find(|b| inc(T::one(), T::one(), |x| x < *b)
　// 条件は約数の倍数すべて(自分以下)が
　.all(|c| inc(T::zero(), c, |x| x <= *b)
　　// 自分と一致しないこと
　　.all(|d| d != *b)))})

**デフォルトの名無しさん** · 2021/12/17(金) 00:54:27.00

恥ずかしい自演

**デフォルトの名無しさん** · 2021/12/17(金) 01:40:56.99

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

**デフォルトの名無しさん** · 2021/12/17(金) 02:46:20.43

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

**デフォルトの名無しさん** · 2021/12/17(金) 05:16:05.83

計算量悪くね？

**デフォルトの名無しさん** · 2021/12/17(金) 07:30:23.20

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

**デフォルトの名無しさん** · 2021/12/17(金) 07:58:24.35

アセンブリ言語

**デフォルトの名無しさん** · 2021/12/17(金) 08:05:48.36

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

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

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

**デフォルトの名無しさん** · 2021/12/17(金) 12:36:06.54

>>55
ご指摘ありがとうございます
変数名を英語やローマ字にしてもわかりにくかったため日本語にしました
あとは無駄な部分を整理した結果シンプルになりました

fn 素数列<T>() -> impl Iterator<Item=T>
　where T: Copy + num::One + num::CheckedAdd + std::cmp::PartialOrd,
{
　range(T::one(), |_| true)
　.filter(|&素数|
　　range(T::one(), |約数| 約数 < 素数)
　　.all(|約数|
　　　range(約数, |約数倍数| 約数倍数 <= 素数)
　　　.all(|約数倍数| 約数倍数 != 素数)))
}

fn range<T>(unit: T, cond: impl Fn(T) -> bool) -> impl Iterator<Item=T>
　where T: Copy + num::CheckedAdd,
{
　itertools::unfold(unit, move |x| {
　　*x = x.checked_add(&unit)?;
　　cond(*x).then(|| *x)
　})
}

fn main() {
　itertools::assert_equal(素数列::<i8>(),
　　[2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71,73,79,83,89,97,101,103,107,109,113,127]);
　assert_eq!(素数列::<u8>().last(), Some(251));
}
コードが汚いとご批判くださっていた皆さま方
これでいかがでしょうか？

**デフォルトの名無しさん** · 2021/12/17(金) 14:02:48.80

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

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

**デフォルトの名無しさん** · 2021/12/17(金) 15:05:48.68

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

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

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

**デフォルトの名無しさん** · 2021/12/17(金) 15:43:15.77

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

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

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

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

**デフォルトの名無しさん** · 2021/12/17(金) 19:33:47.63

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

**デフォルトの名無しさん** · 2021/12/17(金) 19:45:38.64

>>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))))

**デフォルトの名無しさん** · 2021/12/17(金) 19:52:32.78

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

**デフォルトの名無しさん** · 2021/12/17(金) 20:12:51.70

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

**デフォルトの名無しさん** · 2021/12/17(金) 20:32:50.39

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

**デフォルトの名無しさん** · 2021/12/17(金) 20:41:41.40

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

**デフォルトの名無しさん** · 2021/12/17(金) 21:36:06.81

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

**デフォルトの名無しさん** · 2021/12/17(金) 23:16:23.03

>>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』は符号なし整数です

**デフォルトの名無しさん** · 2021/12/17(金) 23:19:50.48

そしてmy_iter()の関数をVec<i32>に対して実装します
まず以下のtraitの部分は今回おまじないとして無視していいです
trait MyIterTrait {
　fn my_iter(self) -> MyIter;
}
次が関数my_iter()のVec<i32>に対する実装(impl)です
impl MyIterTrait for Vec<i32> {
　fn my_iter(self) -> MyIter {
　　MyIter { vec: self, index: 0 }
　}
}
このように関数my_iter()は>>75で定義した構造体MyIterを返しているだけです
アセンブリコードはC言語などと同じになるでしょう
ただしC言語では構造体はポインタ返しのみだったと思いますが
Rustでは構造体をそのまま返せてこれはスタック領域にデータが返ります

あとは冒頭に説明しましたイテレータとして機能するためのnext()が必要です
構造体MyIterに対してイテレータの実装(impl)をします
impl Iterator for MyIter {
　type Item = i32;
　fn next(&mut self) -> Option<i32> {
　　if self.index < self.vec.len() {
　　　let ret = self.vec[self.index];
　　　self.index += 1;
　　　Some(ret)
　　} else {
　　　None
　　}
　}
}
ベクタの現在のインデックス値を Some(ret) と返しているだけです
インデックスがベクタの長さを超えたら None を返しています

**デフォルトの名無しさん** · 2021/12/17(金) 23:24:42.83

ではこの>>76の構造体MyIterのnext()は誰がいつ呼ぶのでしょう？
ここではメソッドチェーンになっているので後続のイテレータが呼びます
具体的には>>75で v.my_iter().my_print(); でしたからmy_print()が呼び出します

そこで関数my_print()の定義です
今回もtraitの部分はおまじないと思って無視していいです
trait MyPrint {
　fn my_print(&mut self);
}
下記で任意のイテレータに対して関数my_print()を実装(impl)します
そのためこの部分だけはジェネリック指定『<I: Iterator>』のコードをご容赦ください
後ろのwhere以降の std::fmt::Display は表示を許可するためのおまじないと思ってください
impl<I: Iterator> MyPrint for I
　where I::Item: std::fmt::Display
{
　fn my_print(&mut self) {
　　while let Some(val) = self.next() {
　　　println!("{}", val);
　　}
　}
}
ここでmy_print()のselfというのはここでimpl対象＝先行するイテレータすなわちMyIterになります
もちろんMyIter以外の別のイテレータに対してもこのmy_print()は機能します
今回の使い方ではselfは構造体MyIterになりますから
whileのところにあるself.next()も先程定義したMyIterのnext()になります
next()の返り値が Some である限りprintln!で表示して None になるとwhileを抜けて終了です

以上で冒頭の以下の例の全てコードが実装されましたので動きます
fn main() {
　let v = vec![5, 6, 7, 8, 9];
　v.my_iter().my_print();
}

**デフォルトの名無しさん** · 2021/12/17(金) 23:54:35.76

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

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

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

**デフォルトの名無しさん** · 2021/12/17(金) 23:54:47.66

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

ひとりよがりが過ぎる

**デフォルトの名無しさん** · 2021/12/17(金) 23:59:22.81

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

**デフォルトの名無しさん** · 2021/12/18(土) 01:55:26.24

ヒトに頼るな。

**デフォルトの名無しさん** · 2021/12/18(土) 02:17:36.05

ワロタ

**デフォルトの名無しさん** · 2021/12/18(土) 02:17:43.63

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

**デフォルトの名無しさん** · 2021/12/18(土) 02:43:52.24

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

**デフォルトの名無しさん** · 2021/12/18(土) 02:56:00.48

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

**デフォルトの名無しさん** · 2021/12/18(土) 03:05:51.15

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

**デフォルトの名無しさん** · 2021/12/18(土) 03:17:03.48

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

**デフォルトの名無しさん** · 2021/12/18(土) 03:38:45.07

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

**デフォルトの名無しさん** · 2021/12/18(土) 04:55:38.30

>>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実装があるからコストかからない
現実にはこのコードが核心部分でなければそこまで気にしなくていいけどな

**デフォルトの名無しさん** · 2021/12/18(土) 05:17:14.76

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

**デフォルトの名無しさん** · 2021/12/18(土) 08:35:30.45

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

**デフォルトの名無しさん** · 2021/12/18(土) 10:28:10.29

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

**デフォルトの名無しさん** · 2021/12/18(土) 11:41:10.36

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

**デフォルトの名無しさん** · 2021/12/18(土) 16:44:21.13

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

**デフォルトの名無しさん** · 2021/12/18(土) 17:42:36.78

延々とな
ガイジそう

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

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

**デフォルトの名無しさん** · 2021/12/18(土) 20:19:16.51

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

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

**デフォルトの名無しさん** · 2021/12/18(土) 21:02:25.05

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

**デフォルトの名無しさん** · 2021/12/18(土) 21:05:46.31

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

**デフォルトの名無しさん** · 2021/12/18(土) 21:56:16.22

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

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

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

**デフォルトの名無しさん** · 2021/12/18(土) 22:26:29.42

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

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

**デフォルトの名無しさん** · 2021/12/19(日) 08:59:28.05

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

**デフォルトの名無しさん** · 2021/12/19(日) 23:44:42.02

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

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

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

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

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

**デフォルトの名無しさん** · 2021/12/20(月) 13:09:41.04

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

**デフォルトの名無しさん** · 2021/12/20(月) 17:47:27.57

意識他界系かよ

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

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

**デフォルトの名無しさん** · 2021/12/20(月) 18:21:17.98

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

**デフォルトの名無しさん** · 2021/12/20(月) 18:34:34.79

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

**デフォルトの名無しさん** · 2021/12/20(月) 18:37:40.57

10年早い系

**デフォルトの名無しさん** · 2021/12/20(月) 19:11:56.15

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

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

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

**デフォルトの名無しさん** · 2021/12/20(月) 19:54:01.15

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

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

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

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

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

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

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

**デフォルトの名無しさん** · 2021/12/20(月) 21:00:54.00

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

**デフォルトの名無しさん** · 2021/12/20(月) 21:10:35.52

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

**デフォルトの名無しさん** · 2021/12/20(月) 21:56:05.64

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

**デフォルトの名無しさん** · 2021/12/20(月) 23:37:11.43

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

**デフォルトの名無しさん** · 2021/12/20(月) 23:37:21.66

見当

**デフォルトの名無しさん** · 2021/12/20(月) 23:47:18.19

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

**デフォルトの名無しさん** · 2021/12/21(火) 02:18:43.99

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

**デフォルトの名無しさん** · 2021/12/21(火) 02:38:28.55

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

**デフォルトの名無しさん** · 2021/12/21(火) 08:29:08.29

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

**デフォルトの名無しさん** · 2021/12/21(火) 08:37:17.38

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

**デフォルトの名無しさん** · 2021/12/21(火) 08:59:49.41

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

**デフォルトの名無しさん** · 2021/12/21(火) 09:42:52.55

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

**デフォルトの名無しさん** · 2021/12/21(火) 10:37:29.68

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

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

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

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

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

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

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

**デフォルトの名無しさん** · 2021/12/21(火) 14:51:21.09

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

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

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

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

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

**デフォルトの名無しさん** · 2021/12/21(火) 15:02:25.60

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

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

**デフォルトの名無しさん** · 2021/12/21(火) 16:17:27.88

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

**デフォルトの名無しさん** · 2021/12/21(火) 17:55:52.77

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

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

**デフォルトの名無しさん** · 2021/12/21(火) 19:16:57.14

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

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

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

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

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

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

**デフォルトの名無しさん** · 2021/12/21(火) 22:16:57.85

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

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

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

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

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

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

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