C vs C++ vs Rust Part.3

**デフォルトの名無しさん** · 2022/01/27(木) 22:19:47.56

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

**デフォルトの名無しさん** · 2022/03/14(月) 01:04:15.62

いや俺は当時検索デスクを欠かさず読んでた検索っ子だったぞ
そんな事実はなかった

**デフォルトの名無しさん** · 2022/03/14(月) 01:10:14.46

>>452
検索リテラシーが低かったんじゃないの？
とにかく俺や周りの人達は98年末くらいからGoogle使ってるよ

**デフォルトの名無しさん** · 2022/03/14(月) 01:12:22.48

検索デスクを知らないってことは嘘だね。。。

**デフォルトの名無しさん** · 2022/03/14(月) 01:18:10.05

うーん、やっぱいまいち思い出せないけど2001年頃にはVisual Studio6つかって趣味でいろんなゲーム作ってたような学生だったし、おれはとっくにGoogle使いまくってたような気がする
当時のIEって何かといろんなバーが追加されまくって表示が狭かったんだっけ、なつかしいね
初代Sleipnirとか出てからネットサーフィンも快適になったんだったかな

たしかに一般認知されるか、っていうとテレビCM出しまくるようになってからだろうし、もっとずっと後だね

**デフォルトの名無しさん** · 2022/03/14(月) 01:42:30.09

出た瞬間からアーリーが早く認知してたことをベースにするならRustは10年余裕で超えるので浸透速度が非常に遅い。
そりゃそうよ。OS付近やかなりな低レベルライブラリ向きで、アプリ開発にはバッテリーが小さすぎて向いてないんだから。

**デフォルトの名無しさん** · 2022/03/14(月) 01:49:04.04

>>437
関係無い。
RustはRubyやPerlよりも生産性が低い。

**デフォルトの名無しさん** · 2022/03/14(月) 02:24:15.93

年末に世の中の流行について行こうとPython+OpenpyxlでExcelファイルいじくるプログラム書いてみた
単にワークシート読み込むだけで分オーダー
ライブラリがワークシート読み込みだけなのでこっちはなんもやってない。
こりゃあかんってなって
ためしにC#+EPPLUSで同じプログラム書いてみた
全プログラム終了するまで5秒ww
あと、既存チャートの参照範囲変更するとかEPPLUSでサクッとできることがOpenpxlじゃできねぇんだわ
どこがいいのPythonて?

**デフォルトの名無しさん** · 2022/03/14(月) 02:25:55.59

>>458
両方のコードを公開しない限り、誰も何とも言えないと思う
ああ、この人python使えないんだなって普通は思うよ

**デフォルトの名無しさん** · 2022/03/14(月) 02:33:50.85

Pythonて集合演算ができるってんで
{a,b,c}3要素からなるべき集合のべき集合とか(ホントは位相空間を作ってみたかった)簡単に書けるかな?とおもってやってみたが、
とても簡単にできそうにない
MathematicaだとSubsets[Subsets[{a, b, c}]]で済む話
このPythonとかゆーがらくた言語なんでこんなに流行ってんの?
インターフェース誌あたりはずーっとPython一色だし。
Web scrapingとかだとC# Scriptでも実行時コンパイルで待たされるんで、
Pythonはイライラ感なく即実行できてウマーとはオモタ

**デフォルトの名無しさん** · 2022/03/14(月) 02:44:33.00

>>459
ま、Python使えないとお前が思うのは勝手だが
ワークシート読み込みのはライブラリが勝手に読むこともわからないんだろな。
プログラマが手を下すとことじゃない。
Matlabあたりも同様だけどこういうインタープリタは繰返し制御文で実行するんじゃなく
ライブラリに任すようにコーディングすんだわ。そこで1分とかかかってるようじゃゴミ判定が正解
ま、Python+Openpyxlは糞だな。とても日々の業務になんか使えないシロモノ。
こんなの使ってエクセルの自動化とか糞本買った方お気の毒としか言い様がない。
会社から金貰ってるって仕事してるっていう気持あるなら、
直接エクセルファイルunzipしてxmlいじくるか、素直にC#+EPPLUS使った方がはるかにまとも

**デフォルトの名無しさん** · 2022/03/14(月) 02:48:39.91

でもおれPythonには日々世話になってんのよな
fakymac+keyhac
しょっちゅう動作がおかしくなるけど、
sunキーボード+emacsで育った世代なんでさww

**デフォルトの名無しさん** · 2022/03/14(月) 03:00:48.63

>>460
そんな大変なんだろうか・・・
def subsets(x):
　　return [y for i in range(1,len(x)+1) for y in itertools.combinations(x, i)]

>>461
別に俺何を使っても書けるし、大昔から出来るし、時間かかるなら使い方悪いだけだと思う＝お前はpython使えない

**デフォルトの名無しさん** · 2022/03/14(月) 08:06:12.15

>>431
それだと使える人間が少なくなって全体の生産性は落ちるだろ。
Haskellの二の舞コースじゃね？

**デフォルトの名無しさん** · 2022/03/14(月) 11:35:31.82

>>461
直接って、xlxsの仕様を理解している前提じゃん。

Pythonは、速度要らなくて、目的で検索してライブラリが出て来て、コードコピペでも大体動く的なそういう使い方が多いと思う。

**デフォルトの名無しさん** · 2022/03/15(火) 12:52:11.85

rustが広まったらどっちにしろ大して理解してない奴が投入されて地獄見るわ。
そういう当たり前のことすら想像できない奴がrustマンセーしてるんだよな。

**デフォルトの名無しさん** · 2022/03/15(火) 15:22:25.57

>>466
一番儲かるのはスコップ売る奴という落ちだろうな。

**デフォルトの名無しさん** · 2022/03/15(火) 15:34:13.41

参考文献というお布施

**デフォルトの名無しさん** · 2022/03/15(火) 16:52:44.24

習得難易度が多少高くても自由度が低い言語を使う場合
低スキルメンバーが混ざっても惨事になりにくい

逆に習得難易度が低くても自由度の高い言語を使う場合は
高スキルメンバーで揃えないとすぐに破綻する

**デフォルトの名無しさん** · 2022/03/15(火) 17:42:54.49

昔はJavaの習得難易度高かったからな(VBに比べて)
その頃はそういう言い分もあって、実際にJavaはVBから来たコピペ野郎の洗礼は受けたものの、簡単なことしかさせないフレームワークという武器を得て、人海戦術の片腕となり得た

しかし今は当時より更に難しくなったJavaが習得難易度低に分類されているｗ
そのJavaより習得難易度がはるかに高く、ライブラリの使い方ではなく言語レベルでの書き方が難しいRustが低スキルメンバーに扱えるかというと・・・ｗ

**デフォルトの名無しさん** · 2022/03/15(火) 18:36:25.33

C++が出来ないからRustに移ったのにそれも習得できないってあとナニをがんばるのやおまいら

**デフォルトの名無しさん** · 2022/03/15(火) 18:46:13.42

C++理解できんようなやつがRustを理解できるわけないやろ

**デフォルトの名無しさん** · 2022/03/15(火) 18:58:34.72

でも多分ほとんどそういう連中だと思うぞ
普通に勉強対象としてgoとRustを比べてるところがもう死ぬほどおかしいんだけど、そこに思い至らないってことは・・・

**デフォルトの名無しさん** · 2022/03/15(火) 19:00:10.43

言語を習得するのは最低限必要なスキルレベルでしかないのに
それをもってプログラミングスキルを推し測ろうとする人って所詮そのレベルなんだよね

**デフォルトの名無しさん** · 2022/03/15(火) 19:02:39.63

C++はバカでも使えるが、バカは使えこなせず、C++コンパイラはバカコードを通すので、問題を起こす
Rustもバカは使えこなせない点で同じだが、Rustコンパイラはバカコードを通さないため、問題が起きない

**デフォルトの名無しさん** · 2022/03/15(火) 19:03:52.90

あとC++が理解出来ないからRustに移るということはない
C++で開発し続けることに挫折して、Rustに移るだけだと思う

**デフォルトの名無しさん** · 2022/03/15(火) 19:11:28.15

Rustが問題が起きないということもなくて、Rustを使ったらプログラムを書けなくなる人がかなりの量出るだけｗ

**デフォルトの名無しさん** · 2022/03/15(火) 19:13:15.97

>>460 >>463
二人ともそれぞれsubsetsとcombinationsというライブラリ関数に頼って書いているだけに過ぎない
ライブラリ関数が充実してると言いたいのか、プログラムを書きやすいと言いたいのか、中途半端
そして自力で書けるならばライブラリ関数の有無は大した問題ではないから何が要点かわからない

**デフォルトの名無しさん** · 2022/03/15(火) 19:17:58.62

>>476
C/C++/Rustいずれか一つでも挫折するような人は、いずれも使いこなせないから結果は同じ
C/C++/Rustいずれも使える人はRustを使う
なぜなら言語の機能が他より高くてプログラミングしやすいため

**デフォルトの名無しさん** · 2022/03/15(火) 19:29:06.52

>>478
自力で用意できるかできないかはどうでもよくて、標準ライブラリにあるかないかが大きく違う
だってどの言語でも用意できないわけがないからｗ
俺はpythonでやるならという条件で書いただけ

>>479
C/C++/Rustはそれぞれ共同開発する人が誰かによって変わるだけ
自分で使うだけなら速いし面白いし安定してるし、C++で書く
C使いが多ければCを使うし
Rust自体を使うことが目的でないのなら、Rustやってみたい人が多いときRustにするだけ
量的には
C > C++ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Rust
かなぁ

**デフォルトの名無しさん** · 2022/03/15(火) 19:35:38.12

C/C++/Rustの3つならば明白に言語が提供する機能差がある
3つとも書けるプログラマーならば99%がRustを選ぶのは間違いない

**デフォルトの名無しさん** · 2022/03/15(火) 19:38:32.90

どんだけ馬鹿にされようが罵られようが構わないけど
C++は糞すぎるワイには手に負えない言語とだけは言っておく
C++20以前はジェネリックスに渡す型引数の制約を実現するために偶然見つかった「SFINAE」という「コンパイラの挙動を応用する方法」を用いるのが標準レベルでデファクトスタンダードになっていたとかヤバすぎだろ
普通の人なら気にも留めないような挙動を一般ユーザーにも把握させることを強要する時点で狂っているとしか思えない
SFINAEの代替手法として導入されたconceptsですらごちゃごちゃしているしそこらの一般ユーザーはc++のバージョンアップについていけるほど忍耐強くはない
だからみんなRustに移る

**デフォルトの名無しさん** · 2022/03/15(火) 19:46:14.60

>>480
その様子だと君にはどちらも無理だろう
もし書けると言うならば
そのcombinationsをRustで型Tのイテレータとして実装コードを出してごらん

**デフォルトの名無しさん** · 2022/03/15(火) 19:57:31.66

>>481
そんなことねーよｗ

>>482
まあね。その剥き出し感がいいんだよ遊びで使う分には。見えてない部分がないところ。
一応言っておくと難しい機能は公開するようなコードでは使わないよ。

>>483
https://docs.rs/itertools/0.7.8/src/itertools/combinations.rs.html

**デフォルトの名無しさん** · 2022/03/15(火) 20:02:15.14

>>482
C++のSFINAEはもちろん酷くて論外だが
逆にRustの現状のトレイト実装ルールは実装型を互いに排他を満たす必要があり厳しすぎる
もちろんRustコンパイラは進化し続けていて一部特殊化がそろそろ安定化しそうで少し緩和となり期待

**デフォルトの名無しさん** · 2022/03/15(火) 20:03:31.49

若い頃はSFINAEのパズル解く感じが好きでヤバいコード結構書いてたけど、だんだんあれは正気ではなかったなと思うようになってきた

**デフォルトの名無しさん** · 2022/03/15(火) 20:06:07.03

>>486
やめてそういうこと言うのｗ

**デフォルトの名無しさん** · 2022/03/15(火) 20:13:48.68

>>484
あなたはそのリンクを出すことでRustを全く知らない無知だとバレました
なぜならそのリンクのitertoolsバージョン0.7.8は4年前なのです
検索でリンクを拾ってこない限りそんな超古いバージョンを示す人はいません
あなたはプログラミング未経験者もしくは初心者であることがバレてしまいました

**デフォルトの名無しさん** · 2022/03/15(火) 20:30:44.95

>>484
偉そうなこと言っていてRustを理解できす挫折した落ちこぼれだったのか
>>480でRustを蔑んでいたから怪しいと思っていたらやっぱりか

**デフォルトの名無しさん** · 2022/03/15(火) 20:46:50.19

>>488-489
別に最新だろうがすぐ行けるだろｗ
俺が自分で書いたら正解はコレって出す予定だったからわざわざ出題したチキンなんだろ？
だからこれにしただけｗ

**デフォルトの名無しさん** · 2022/03/15(火) 21:05:33.57

>>490
言い訳ばかりだな
じゃあもう一つの>>460のsubsetsイテレータをRustで書けたら認めてやろう

**デフォルトの名無しさん** · 2022/03/15(火) 21:23:06.07

もしプログラミングが不慣れで難しいようだったら
イテレータを「どんな仕様」にしてしまってもいいぜ
それがヒントだ

**デフォルトの名無しさん** · 2022/03/15(火) 21:27:42.88

お前に認めてもらう必要なんてねーよｗ Rustを使うやつはバカしかいないんだなｗ

**デフォルトの名無しさん** · 2022/03/15(火) 21:37:04.88

>>493
今回は検索してリンクを拾ってこれなかったのね

**デフォルトの名無しさん** · 2022/03/15(火) 21:38:31.66

煽って正解もらいたいバカしかいないの？ｗ

**デフォルトの名無しさん** · 2022/03/15(火) 22:05:39.63

>>492
subsetsをどんな仕様のイテレータでもいいってことは
初心者でもすぐ出てくるあれでいいってことか

>>495
これは超初心者でもいいからプログラミングをしたことがあるのか
それとも煽っているだけなのかが判明しちゃう良問のようです
断念ですか

**デフォルトの名無しさん** · 2022/03/15(火) 22:10:01.54

断念もクソもなんでお前らに言われて俺がやる必要があるんだよｗバカだろｗ
ハッキリ言っておくが俺はRust書けるし、多分お前らより詳しいよ普通にｗ
こういうのがRust推してる信者頭おかしくて性格歪んだやつしかいない雰囲気100%で毛嫌いされてる理由なんだろうなｗ

**デフォルトの名無しさん** · 2022/03/15(火) 22:11:58.21

端的に言うと、流行りばかり気にするすごい頭悪い人たちと同じ匂いがするんだよｗ

**デフォルトの名無しさん** · 2022/03/15(火) 22:16:52.73

>>497
Rustに詳しいならば
既存のこれを使えばいい、と即答できる問題
あるいはsubsetsイテレータという問題だから仕様が自由に何でもいいならば初心者でもコードを一瞬で示せる問題
どちらも出来ないならRust未経験と断定できる

**デフォルトの名無しさん** · 2022/03/15(火) 22:31:30.23

permutationやcombinationとか普通にはあまり使わないんだよ
競プロとかやってる実利のないコードをメインに書いてるバカがそういうのをやたら使いたがって、俺より遅いコードしか書けないし、創造的なロジックもどうやら苦手そうなのに、そういう問題やたら出してくるんだよね
俺は元々そういうの得意だけど、その手の問題を好き好んで出してくるバカに答えを書いてやるのが嫌なんだよｗ
納得？

**デフォルトの名無しさん** · 2022/03/15(火) 22:43:02.13

>>500
permutationやcombinationのアルゴリズムが少し難しいのはわかります
でも今回はsubsetsですよ
さらに>>492でどんな仕様にしてもいいと言っていてしかもそれがヒントだと言ってるのでこれは気付きますよ

**デフォルトの名無しさん** · 2022/03/15(火) 22:45:50.74

俺pythonで書いてるし、自分でもすぐ書けるけど、お前に回答すんのが嫌なんだよｗ
なぜならお前がバカだからｗ何度もそう書いてんだけどｗ

**デフォルトの名無しさん** · 2022/03/15(火) 22:50:52.11

ああ、ちなみにpermutationやcombinationのアルゴリズムは簡単ｗ

**デフォルトの名無しさん** · 2022/03/15(火) 22:53:14.37

さきほどcombinationsイテレータをググって古いversionのitertoolsのソースで回答したよな>>484
ところが今回のsubsetsについては回答できない
検索で出てこないから答えられないのだとわかる

**デフォルトの名無しさん** · 2022/03/15(火) 23:04:20.16

永久に書いてやるよｗ
すぐ書けるけど、お前に回答すんのが嫌なんだよｗ
なぜならお前がバカだからｗ何度もそう書いてんだけどｗ

**デフォルトの名無しさん** · 2022/03/15(火) 23:07:34.34

>>503
なるほど
subsetsのアルゴリズムは難しくて無理でしたか

**デフォルトの名無しさん** · 2022/03/15(火) 23:09:47.42

永久に書いてやるよｗ
すぐ書けるけど、お前に回答すんのが嫌なんだよｗ
なぜならお前がバカだからｗ何度もそう書いてんだけどｗ

**デフォルトの名無しさん** · 2022/03/15(火) 23:20:19.51

>>507
さきほどcombinationsイテレータをググって古いversionのitertoolsのソースで回答したよな>>484
itertoolsをもし本当に使ったことがあるならばsubsetsもあるだろうことくらいわかるだろ？

**デフォルトの名無しさん** · 2022/03/15(火) 23:24:18.79

>>508
>>507

**デフォルトの名無しさん** · 2022/03/15(火) 23:32:35.94

>>508
そこは英語力の問題かな
subsetsが見つからなかった時にpowersetを探せるかどうか

**デフォルトの名無しさん** · 2022/03/15(火) 23:54:14.91

俺理系院卒だから数学一般教養くらいはあるぞｗ
難しい話をしてるつもりなのかもしれんけどｗ

**デフォルトの名無しさん** · 2022/03/16(水) 00:52:00.92

>>481
俺はC++もRustも基本的部分は理解しているつもりで、書こうと思えば Rustでも
書けると思うが、書こうとは思えない。
しかし、C++は使う。

**デフォルトの名無しさん** · 2022/03/16(水) 10:39:48.98

同じことをやるにしてもrustは面倒くさそう

**デフォルトの名無しさん** · 2022/03/16(水) 14:20:20.70

rustは詳しく知れば知るほど使える領域が狭いことに気付く。まあ勉強して損することはないとは思うけど。

**デフォルトの名無しさん** · 2022/03/16(水) 16:01:45.47

まぁ、Rustがものすごく人気になるようだったら、Rustを下敷きにしたC++サブセット Smart C++が出てくると思うわ。

そしてc++はライブラリアン向けのunsafe的な扱いになる、と。

**デフォルトの名無しさん** · 2022/03/16(水) 17:58:27.77

>>515
無理じゃないかな。

**デフォルトの名無しさん** · 2022/03/16(水) 20:15:10.51

rustが他言語の仕様に影響を与える部分はでてくるだろうね。

**デフォルトの名無しさん** · 2022/03/16(水) 21:02:09.61

反面教師にはなるよねｗ

**デフォルトの名無しさん** · 2022/03/16(水) 21:24:41.08

>>512
それはあなたの能力では理解できなかったから思うだけで留まり実際には書けていない

>>513
逆だ
同じことが簡潔に書ける

>>514
むしろ幅広い分野で有効
後発だからとも言えるが言語仕様が幅広いパラダイムを洗練して採り入れていることが勝因とみた

**デフォルトの名無しさん** · 2022/03/16(水) 21:56:01.01

少なくともC++はリプレイスしてほしいな

**デフォルトの名無しさん** · 2022/03/16(水) 21:58:33.64

Rust信者って本当にバカだなｗ
妄想で他人を説得はできないんだよ
グラフ構造を標準ライブラリとunsafe使わずに簡潔に書いてみろよｗ
他の言語で出来ないやつないから
Rustも超狭い領域ではオンリーワンくらい有効なんだけど、それ以外では趣味でしか使われない

**デフォルトの名無しさん** · 2022/03/16(水) 23:51:54.51

>>491 >>492
横からやけどほんまにどんな仕様にしてもええの？
それなら長さlenのsubsetsイテレータは10文字で完成
『0..(1<<len)』
数字を2進数で見てbit立っている要素による各subset
0は全ての要素がないから空集合

それで納得してもらえんのやったら入力inputとして
(0..(1 << len))
.map(|c| (0..len)
.filter_map(move |i| (c & (1 << i) != 0).then(|| &input[i]))
.collect::<Vec<_>>())
これでちゃんとしたsubsetsイテレータが完成
例えばinput = &["a", "b", "c"]ならば以下が順に出る
[]
["a"]
["b"]
["a", "b"]
["c"]
["a", "c"]
["b", "c"]
["a", "b", "c"]

**デフォルトの名無しさん** · 2022/03/16(水) 23:53:02.55

>>491 >>492
横からやけどほんまにどんな仕様にしてもええの？
それなら長さlenのsubsetsイテレータは10文字で完成
『0..(1<<len)』
数字を2進数で見てbit立っている要素による各subset
0は全ての要素がないから空集合

それで納得してもらえんのやったら入力inputとして
(0..(1 << len))
.map(|c| (0..len)
.filter_map(move |i| (c & (1 << i) != 0).then(|| &input[i]))
.collect::<Vec<_>>())
これでちゃんとしたsubsetsイテレータが完成
例えばinput = &["a", "b", "c"]ならば以下が順に出る
[]
["a"]
["b"]
["a", "b"]
["c"]
["a", "c"]
["b", "c"]
["a", "b", "c"]

**デフォルトの名無しさん** · 2022/03/17(木) 01:31:24.96

collectするならfoldで十分かな

fn subsets<T>(input: &[T]) -> impl Iterator<Item=Vec<&T>> {
let len = input.len();
(0..(1 << len))
.map(move |c| (0..len)
.fold(vec![], |mut v, i| {
if c & (1 << i) != 0 {
v.push(&input[i])
};
v
})
)
}

**デフォルトの名無しさん** · 2022/03/17(木) 02:22:57.24

C++でsubsetsイテレータを書くとどんな感じになるの？

**デフォルトの名無しさん** · 2022/03/17(木) 02:29:21.66

>>519
馬鹿

**デフォルトの名無しさん** · 2022/03/17(木) 02:39:09.51

Rust同様どうとでも出来るよｗ
C++のは古いから名前がアレだけど
俺は>>522じゃないけどfilterとmapで書いた方が分かりやすいとは思う
この書き方でpushとかは見たくなかったｗ

**デフォルトの名無しさん** · 2022/03/17(木) 02:53:46.50

うむ

>>522
filter_mapとthenによるOption利用が分かりやすいな

**デフォルトの名無しさん** · 2022/03/17(木) 03:28:10.97

>>527
ぜひC++版お願い

**デフォルトの名無しさん** · 2022/03/17(木) 04:22:11.55

>>529
何度でも言うけど、そういう要求は飲まない
金くれたら書くよｗ

**デフォルトの名無しさん** · 2022/03/17(木) 08:12:49.73

>>520
リプレースはしなくていい。
コーダーとかが通常使う安全運転版と、ライブラリアン用のフル版が住み分け・共存できればいい。
従来はコーディング規約とライブラリでやっていたところだけど、こういうのはshared ptrみたいに旨が使う共通仕様にしたほうがいい。

**デフォルトの名無しさん** · 2022/03/17(木) 08:19:10.27

Rustに移行すれば
色んな問題が一気に解決するだけでなく
プログラミングもしやすくなって一石二鳥

**デフォルトの名無しさん** · 2022/03/17(木) 08:41:07.21

>>532
サンプルコードがもっと充実してきて、標準的なコーディングが普及してきてから検討するわ。

Rustは土方向け言語目指しているのに、今のRustの仕様だと土方に難しすぎるから中途半端。それならc++＆コーディング規約でいいや。

**デフォルトの名無しさん** · 2022/03/17(木) 08:49:29.01

>>533
君たち土方には難しいのかも知れないが普通のプログラマーにとっては難しくないしコーティングがC++より快適

**デフォルトの名無しさん** · 2022/03/17(木) 08:57:01.71

Pythonくらいしかやったことない人にとって難しいのはそうだろうけど
C++14/17についていってる人ならRust余裕だと思うけどなぁ

**デフォルトの名無しさん** · 2022/03/17(木) 10:08:01.84

Rustに出来てC++が似たようなことを出来ないってことはまずないよ
ただ同じことをしたい場合、手間がすごいかかる(23は知らんけど)
そしてどう転んでもエラーがRustほど人間に優しくなったりはしない(と思う)

C++に出来てRustが似たようなことを出来ないってこともそんなに多くない
まあでもこっちは本当に出来ない
https://www.reddit.com/r/rust/comments/n7rjfk/what_can_c_do_that_rust_cant_2021_edition/

ただRustは初心者には難しすぎ、ある程度他の言語をやってる人にも難しいというハンデがある
なのでスクリプト言語感覚でRustをやろうと思うのはちょっとオススメできない
楽を出来る場面は確かにあるので、そこをどの程度メリットと捉えるか
制約をどの程度デメリットと捉えるかで評価が分かれる

**デフォルトの名無しさん** · 2022/03/17(木) 12:06:55.23

>>534
土方にやらせる話をしているんだよ。

Rust信者がそういう意識なら、RustがJavaみたいに流行ることは無いな。
やっぱりHaskellコースかね。

**デフォルトの名無しさん** · 2022/03/17(木) 16:20:31.29

>>534
>君たち土方には難しいのかも知れないが普通のプログラマーにとっては難しくないしコーティングがC++より快適
自分がどれくらい矛盾してること言ってるのかも理解してなさげ。

**デフォルトの名無しさん** · 2022/03/17(木) 18:26:55.16

>>522
Rustはスクリプト言語のように簡潔に書ける点もいいね
それでいてC言語並に速い
C++は簡潔に書けず手間暇かかりすぎる

**デフォルトの名無しさん** · 2022/03/17(木) 18:35:40.91

お手軽さっていう話だと、関数の仮引数の型も型推論してほしい、ってたまに思っちゃう

**デフォルトの名無しさん** · 2022/03/17(木) 18:44:45.18

>>540
技術的にはできるし、できるならやりたくなっちゃうところをあえて削ったのは英断だと思ってる
過去のコードや他人のコードを読むときに直近に型があるのは大きい

**デフォルトの名無しさん** · 2022/03/17(木) 18:59:38.79

> 仮引数の型も型推論
OCamlだとそれはフツーにできてるのにね

> 過去のコードや他人のコードを読むときに直近に型があるのは大きい

同じような話だがJavaのジェネリクスで

> List<Foo> list = new ArrayList<>();
> この右辺のパラメータが省略できるのを有難がるのは残念で
> ホントは左を省略してvar ist = new ArrayList<Foo>();
> と書けたほうが嬉しいのにJavaはやっぱりダメダメ

みたいな意見をみたことがあるが、左を残すことこそ大事なんだよな
実装に対してではなくてインタフェースに対してプログラミングするのであって
変数の型を必要最低限の小さいインタフェースで宣言するのが嬉しいのに
それをわかってないやつはタイピング数などで判断して世迷い言を言う

**デフォルトの名無しさん** · 2022/03/17(木) 19:25:12.70

Rust学習しはじめだがEnumの仕組みは良いと思う。
C#あたりに組み込まれればいいのに。

**デフォルトの名無しさん** · 2022/03/17(木) 20:43:27.53

enum Optionとか便利で簡潔に
null nil undefined -1など無くして安全に出来ていいよね
それでいてコンパイル後は最適化されたり消えたりして効率も両立されたり

**デフォルトの名無しさん** · 2022/03/17(木) 20:52:32.01

別にC++でも同じことはできるけどね
自分で組めばC++14とかでもrxっぽく書いたり、Optionの実装も余裕
手間さえ惜しまなければｗ

**デフォルトの名無しさん** · 2022/03/17(木) 20:55:03.76

Javaも最近は左側省略できるよ
おっしゃるとおり基底型何にするかは選べないけどｗ

**デフォルトの名無しさん** · 2022/03/17(木) 20:58:40.56

C++17にstd::optional<T>があるにはあるのだが...

膨大な量の既存のSTLが無効値をoptionalに置き換えられることはない
つまり無効値でoptionalを返す風潮ができにくいから悲しみ

**デフォルトの名無しさん** · 2022/03/17(木) 20:59:36.98

引数の型推論は原理的にはかなり出来そうだけど
例えば引数がas_ref()で使われていて変換後がPathなら引数はimpl AsRef<Path>までやっちゃう？
でもその利用者へのインタフェース明示や可読性と保守性を考えると型明記でいいような気がする

**デフォルトの名無しさん** · 2022/03/17(木) 21:13:38.45

C++もautoだらけlambdaだらけにすると引数も戻り値も結構型書かなくていいけど、遠すぎて何に怒られてるのか分からん代入エラーが出たりもするｗ
Rustも同じだけどエラーは分かりやすい

**デフォルトの名無しさん** · 2022/03/17(木) 21:15:46.46

>>545
そこはやろうと思えばできるレベルと
Rustが標準ライブラリで全面採用サポートしてるレベルで天と地の差があるよね
例えば>>522もbool値がthenでOptionを生成してそれをfilter_mapが受け取ることで簡潔なコードになっていたり

**デフォルトの名無しさん** · 2022/03/17(木) 21:23:13.02

そこはfilterとmapの方が分かりやすい