結局C++とRustってどっちが良いの？ 2traits

**デフォルトの名無しさん** · 2023/04/02(日) 00:42:57.53

「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」

っていうスレ。

前スレ: 結局C++とRustってどっちが良いの？
https://mevius.5ch.net/test/read.cgi/tech/1677286186/

**デフォルトの名無しさん** · 2023/04/29(土) 22:26:27.79

>>763
ハッシュテーブルでもリンクリストを使うチェーン法はリンクをたどるコストが無駄なので避けられる
現実的に効率の良いオープンアドレス法が好まれておりベクターが使われている

**デフォルトの名無しさん** · 2023/04/29(土) 22:39:43.93

なんか偶然ソートの話になってるけど
流れを読んでからこれ書いたんじゃなくて
「ところでインサーションソートなんてベクタじゃ苦しいだろうけど
リストならすごく効率がいいんではないか？　を確かめようとしたら
list::sortがおそらくすでに十分に効率的に書かれてることが分かって
インサーションソートを自分で実装する気が萎えた
（いちおう拾ったコードは乗せてあるけどクッソ遅い）」という別の話

https://ideone.com/D9ljA7
function asc desc shuf
std::sort(v) 16 13 72
list::sort 43 60 332　←十分早い
std::qsort(v) 47 45 144　←参考

**デフォルトの名無しさん** · 2023/04/29(土) 22:50:51.62

>>766
リンクをたどらず隣の要素を参照することはできないのね
チューリング賞ものの新アルゴリズムでもあるのかと思って期待しちゃったよ
数学的に

**デフォルトの名無しさん** · 2023/04/29(土) 22:57:10.41

>>769
>>765はそのリンクをたどることがどう不利になるのかを聞いたんだが？

**デフォルトの名無しさん** · 2023/04/29(土) 22:58:20.16

>>756か。

**デフォルトの名無しさん** · 2023/04/29(土) 23:51:59.24

Senior Microsoft exec says Windows 11 kernel will soom be booting with Rust inside

https://www.neowin.net/news/senior-microsoft-exec-says-windows-11-kernel-will-soon-be-booting-with-rust-inside/

うおおおおおお！！

**デフォルトの名無しさん** · 2023/04/30(日) 00:02:56.42

Microsoft's adoration of Rust does have limits.
"Rewriting Windows in Rust probably isn't going to happen anytime soon," said Weston,
"so while we love Rust, we need a strategy that also includes securing more of our native code."

**デフォルトの名無しさん** · 2023/04/30(日) 00:09:47.59

コンパイラはどうすんのかな?
社内に自社製のがあるのかな?

**デフォルトの名無しさん** · 2023/04/30(日) 01:22:44.98

>>769
LinkedListにおいて、キャッシュに載っていれば隣の要素は、1クロックで
辿れるから何の問題もない。アセンブリコードは、
mov rbx,[rbx + pNext]
みたいになり、キャッシュに載っていれば1クロック。
多くの場合、キャッシュに載っていることが多い。
乗っていない場合は、prefetch 命令で載せることができる。

**デフォルトの名無しさん** · 2023/04/30(日) 01:28:36.62

Stroustrup氏は、キャッシュミス時のハードウェアによる自動 prefetch が
数百クロックかかると書いていたが、それは過去の話で、
現在の DDR4-SDRAM だと、15クロックだと聞いた。
だから、キャッシュに載ってなくても15クロックのペナルティーで済む。
また、pNext を読む前に prefetch 命令で pNext の部分をキャッシュに読み込ます
ようにしておけば、ペナルティーは 1 クロック以下に近くなる。
「以下」と書いたのは、いまの CPU は複数命令の同時命令実行機能が有るので
prefetch命令自体は0クロックで実行できることがあるから。

**デフォルトの名無しさん** · 2023/04/30(日) 01:38:31.10

ほんと頭悪すぎだろ
数学的に

**デフォルトの名無しさん** · 2023/04/30(日) 01:38:51.52

なお、LinkedListでも多くの場合は、次のノードは、アドレスがほぼ隣接しているので
キャッシュに載っている確率が高い。ほぼ連続的なアドレスを次々に辿っていくので
ほとんどの場合、LinkedListのノードは読み込み時にキャッシュに載り続けている。
10万個の要素があった時、その内、2つの要素を10回交換したとしても、
キャッシュの乱れは、40回程度。10万要素の内の40回程度、キャッシュ
ナルティーが生じるだけ。
それぞれが15クロックほど遅くなるだけだから、10万個の要素を辿っても、
全体として、600クロックほど、キャッシュ読み込みの時間が追加されるだけ
のはず。ただし、キャッシュミス時の自動prefetchの時間が15クロック
かどうかは不明。
なお、ソフトウェア的にprefetch命令をマシン語で書いておけば、他の命令を
実行中にprefetch動作が入るので、キャッシュペナルティーを実質0クロック
にできる。

**デフォルトの名無しさん** · 2023/04/30(日) 01:39:45.77

>>777
俺の方があんたより数学的才能に恵まれてると思うぞ。

**デフォルトの名無しさん** · 2023/04/30(日) 01:44:17.33

ここの人は何か勘違いしてるようだが、LinkedListで隣のノードに辿るのは、
C で書くと
pNode = pNode->pNext;
という1行で書けるが、アセンブリだと、
mov rbx,[rbx + (pNextのオフセットアドレス)]
という 1命令になって、1クロックに過ぎない。
一方、配列の場合の、++ptr は、
add rbx,(1要素のバイト数)
という1命令で書けて、これも1クロック。

なので、キャッシュミスがない限り、LinkedListも配列と同じ速度で
ノードを辿っていける。

**デフォルトの名無しさん** · 2023/04/30(日) 01:48:48.78

>>754
QuickSortは、LinkedListではとても不利。
ただし、QuickSortと同じ速度のソートを俺は発見している。
なお、俺は数学的な天才だから、あなた達には無理なんだろう。

**デフォルトの名無しさん** · 2023/04/30(日) 01:49:24.07

1クロックw
数学的だねェ

**デフォルトの名無しさん** · 2023/04/30(日) 01:54:42.21

1クロックが何MHzだった時代のお話ですか？

**デフォルトの名無しさん** · 2023/04/30(日) 01:58:54.26

LinkedList指向アーキテクチャを使ってるんだろ

**デフォルトの名無しさん** · 2023/04/30(日) 01:59:20.86

>>778
>キャッシュの乱れは、40回程度。10万要素の内の40回程度、キャッシュ
>ナルティーが生じるだけ。
>それぞれが15クロックほど遅くなるだけだから、10万個の要素を辿っても、
>全体として、600クロックほど、キャッシュ読み込みの時間が追加されるだけ
>のはず。
訂正します。
実際には、AAAABAAACAAADAAA・・・
のようになるので、「行き」はキャッシュミスが生じますが、「帰り」は
キャッシュに載っているものを再度使うだけなので、キャッシュの乱れは
20回程度となり、キャッシュロードに掛かる追加時間は、全体で300クロックで
済むと考えられます。

**デフォルトの名無しさん** · 2023/04/30(日) 02:00:53.22

>>784
LinkedListでも効率の良い新しいソートアルゴリズムを独自に発見してます。

**デフォルトの名無しさん** · 2023/04/30(日) 05:06:03.85

>>786
高速なソートアルゴリズムを新たに発見するとは
天才すぎる
これでLinkedListの逆転勝ちかあ

>>780
1クロックで読み込みできるとは
ハードウェアでも天才すぎる
LinkedListの時代が到来だあ

**デフォルトの名無しさん** · 2023/04/30(日) 07:14:18.58

>>772
貼るんなら極力元ネタにしようぜ字幕でおｋ
https://youtu.be/8T6ClX-y2AE?t=3100

ブートローダはプログラムであって、ライブラリじゃないんだよな
はやくAPIをRust化してほしいそうすれば、C++も恩恵を受ける

**デフォルトの名無しさん** · 2023/04/30(日) 07:28:55.12

AIにコードを書いてもらえないかってのが研究されだして久しいけど、
Rustは(書いてもらうのに)向いてるかもね

Rustは人の仕事を奪うかもよ?ｗ

**デフォルトの名無しさん** · 2023/04/30(日) 09:22:37.96

ただの人を目標にしているから月に行けなくなった

**デフォルトの名無しさん** · 2023/04/30(日) 09:46:01.58

クリックベイトかな？と思ったら速攻で出ていた

>>772-773
>>788

> Microsoft's adoration of Rust does have limits.
> "Rewriting Windows in Rust probably isn't going to happen anytime soon," said Weston,
> "so while we love Rust, we need a strategy that also includes securing more of our native code."

**デフォルトの名無しさん** · 2023/04/30(日) 09:55:02.85

隣へたどる方法比較
https://ideone.com/sVvoxX
p++ 28
v ++it 29
v next(it) 30
l next(it) 151

最初の三つに数字の上では差が付いてるが本質的ではない
書いてる最中にここの数字入れ替わったりしてるので誤差
リストは遅いっちゃあ遅いけど致命的に遅いわけでもない
リストにとっては有利なメモリ配置にはなってると思うけど

**デフォルトの名無しさん** · 2023/04/30(日) 10:14:47.83

中立ぶってリストを擁護する人も、中立やめてリスト推しになるかといえば
ならないだろう
結局、誰も推してないのに誰かが推しているように偽装することを
中立という綺麗事で正当化しているだけだ

**デフォルトの名無しさん** · 2023/04/30(日) 10:19:43.94

>>792
ideoneはコンパイラバージョンが古いしマシンも古いと思う
ただしWS級だからメモリ帯域は大きそう(オンザフライ数が大きい)
vectorならDT級マシンでもHWプリフェッチがうまくやってくれる

p++ 6
v ++it 6
v next(it) 6
l next(it) 241 <- 致命的に遅い、よね？

**デフォルトの名無しさん** · 2023/04/30(日) 10:21:32.29

>>768
偶然ソートの話になってるんじゃなくて誰かが書いたコードが
linkedlistに不利なソートを取り上げてたから荒れてるだけなんだ
原因はその誰かなんだ

上に書かれてるように挿入ソートは実質ランダムアクセスよりlinkedlistに不利になるんだから
そういうのをテーマに選んだ時点でちょっとセンスがないと思う

**デフォルトの名無しさん** · 2023/04/30(日) 10:24:45.00

原因はどうでもいい
因果関係に縛られた機械では人間に勝てない

**デフォルトの名無しさん** · 2023/04/30(日) 10:27:36.27

人間も因果に縛られてるんだから、巨視的にはどっこいどっこいかもよｗ

**デフォルトの名無しさん** · 2023/04/30(日) 10:53:23.23

>>792,794
もう面白くないからやらないけど補足すると、一昨日のlistのscanがイイ感じだったのは
Arena使っているからchunk毎にリニアアクセスだったからなんだ

>>792,794はdefault allocatorで、Cacheから出たらnext(it)ですら遅いよ

**デフォルトの名無しさん** · 2023/04/30(日) 10:56:20.23

bindgenでC/C++のheader変換させると
warning: type `ho_ge` should have an upper camel case name
help: convert the identifier to upper camel case: `HoGe`
みたいな余計な御世話なメッセージが出捲るんだが
これを抑制する方法って無い？

**デフォルトの名無しさん** · 2023/04/30(日) 11:30:23.83

>>794
（´･∀･`）ﾍｰ
これは致命的に遅いね

>>798
勉強になります

**デフォルトの名無しさん** · 2023/04/30(日) 14:46:52.74

.to_string() とか
.to_str() とか
.to_str().expect("やりなおせ") とか
.to_str()? とか
.as_str() とか
一貫性がないな

**デフォルトの名無しさん** · 2023/04/30(日) 14:50:03.03

>>799
抑制する方法もエラーメッセージに出てなかったっけ？

**デフォルトの名無しさん** · 2023/04/30(日) 16:01:15.73

#![allow(non_snake_case)]
#![allow(non_camel_case_types)]
#![allow(non_upper_case_globals)]
で出来たけど
#[allow(non_snake_case)]
#[allow(non_camel_case_types)]
#[allow(non_upper_case_globals)]
にしろって書いてあるサイトもある
どっちなんだろ

**デフォルトの名無しさん** · 2023/04/30(日) 16:11:01.60

2つ以上のC/C++のprojectから
bindings1.rs
bindings2.rs
みたいに造って同時にinclude!()すると
定義の衝突とか出るけど
header1.hとheader2.hのどっちにも
#include <iostream>
みたいなの書いてあるとそうなるんかな
面倒だな

**デフォルトの名無しさん** · 2023/04/30(日) 18:48:15.79

DDR4-SDRAMのCASレイテンシーは、15クロックではなく、15(ns)程度だった。
3GHzのCPUだと、45クロックという事になる。

**デフォルトの名無しさん** · 2023/04/30(日) 19:13:17.45

>>805
いろいろ間違ってるで
SDRAMのCASレイテンシってのはナノ秒じゃなくクロックサイクル数
それもCPUクロックじゃなくRAMクロックのサイクル数

**デフォルトの名無しさん** · 2023/04/30(日) 19:16:56.82

>>805 これネタ？
プログラム組めないならAIDA64で測ってみなさい
Trialでもmemory latency出るから

**デフォルトの名無しさん** · 2023/04/30(日) 19:21:05.07

公式ページの画像でも大体のレベル感はわかる
https://aida64.co.uk/user-manual/tools/cache-and-memory-benchmark
https://i.imgur.com/9V9Vbt1.png

**デフォルトの名無しさん** · 2023/04/30(日) 19:41:46.22

>>801
Rustは一貫性があるようにガイドラインで命名ルールも定められている
as_xxxとto_xxxの違いは基本的に
as_xxxはコストなく別の型とみなす
to_xxxはコストかけて別の型を作るかみなす

その例ではもちろんstrとStringは別の型
基本的にas_strとto_stringが使われる
as_strは内部でstrとみなせるデータを持っている時にそこを指すだけなのでコストがかからない場合
to_stringは任意の型からStringを作り出すのでコストがかかる
to_stringはtrait ToStringのメソッドだがtrait Displayを実装することで自動的に実装される

唯一の例外がto_str
これは外部からのデータに対して存在する
strは必ずvalidなUTF8であると保証されている
一方でOsStrやそれを使っているPathは必ずしもvalidなUTF8であると保証されない
そこでUTF8チェックのコストが生じるのでto_strとなる
FFIであるCStrからも同様にto_strとなる

**デフォルトの名無しさん** · 2023/04/30(日) 19:47:21.24

>>752=805 ?

moveもレイテンシーも分かってないRust使いがいるけどホームグラウンドはPythonかよ!

**デフォルトの名無しさん** · 2023/04/30(日) 21:38:41.35

1クロック君も分かってないんだから
あんまり人のことは言わんほうがええで

**デフォルトの名無しさん** · 2023/04/30(日) 21:45:00.52

Python界隈のCodonを以前評価したけど速度面でC/C++と同等なのは単純なケースに限られるようだった
しかも多分皆が最初にみたAckermannの例はgccがclangを凌駕するパターン(再帰Fibonacciなんかもそう)
良いとこだけ記事にした方がいいねもらえるという情報ジレンマ..

**デフォルトの名無しさん** · 2023/04/30(日) 21:55:02.14

どうせCPUじゃなく、GPUだのFPGAだのにオフロードするんだしｗ

**デフォルトの名無しさん** · 2023/05/01(月) 00:28:33.95

>>811
1クロック君 = ID:bU1qZ3nv のことか？
流し読みだと805は1クロック君で、>>752=move君(C++,Rust,Python)とコムソートの話をしてるのね

Rustユーザ-> >>563みたいな数独パズル状態でどん詰まり傾向、途中LinkedListは遅い発言を受けるも >>581でやっと動くが何もしない
1クロック君->呼ばれて登場、いつもの虚言連射自分の思い込みと異なる現実を見たくないから意地でもコード書かない
move君->(いろいろ分かってないので、1クロック君の虚言でも)何かしら動くコードにしてideoneに置く、慣れないC++で
C++側->面白がってコード弄る、ベンチ晒す、けど全員離脱 move君はそれでも勉強になったとお礼

move君、いい奴なんじゃね？

**デフォルトの名無しさん** · 2023/05/01(月) 02:07:28.85

>>814
あなたが理解できてないだけ。

**デフォルトの名無しさん** · 2023/05/01(月) 09:28:12.86

あらゆるところに関所がある
まるで江戸時代だ
裏山に抜け道を見付けて分け入っても
突然藪から棒に番人が現れる
ところがそんな番人も
unsafe印籠を魅せれば一撃で退散だ
unsafe万歳!!!
こんなことなら最初から
表通りでunsafe印籠を出しておけば良かったんだ
きっと番人たちも思っているはず
さっさと最初からunsafe印籠魅せやがれ
無駄な手間取らせやがって
こんなのがエコシステムとか失笑もの

**デフォルトの名無しさん** · 2023/05/01(月) 10:11:02.89

C++のバイブルeffective C++でやってることを何も考えなくても
できるのがRustだよな

**デフォルトの名無しさん** · 2023/05/01(月) 11:26:54.16

C++のconstを更にウザくした感じをデフォルトにした?
まぁ安全なんだろうけども

**デフォルトの名無しさん** · 2023/05/01(月) 12:33:03.54

>>817
間違い：何も考えなくてもできる
正解：考えないとエラーが出る

**デフォルトの名無しさん** · 2023/05/01(月) 12:59:11.10

これが先週のLinkedListチャレンジの結末である

Rust → どん詰まり傾向、1になればゴール
慣れないC++で → 慣れてなくとも独力で0を1にして動くコード提出、その先は先輩たちがサクッと引きあげ

**デフォルトの名無しさん** · 2023/05/01(月) 13:08:10.08

ちょっとした車輪ならぱぱっと組めて当然なのがC++ (俺はまだまだだけどｗ
だからこそ、メモリ関係のバグ・デバグに気を取られたくない unsafeの取り込みは急務

**デフォルトの名無しさん** · 2023/05/01(月) 13:35:33.76

よろしくゴサシュー

×Rust → どん詰まり傾向、1になればゴール
〇Rust → どん詰まり、1に出来ずに、ポエムにいいね

**デフォルトの名無しさん** · 2023/05/01(月) 13:52:07.74

FPGA君も居るんだね

**デフォルトの名無しさん** · 2023/05/01(月) 17:12:27.61

C++でもnew/deleteなんてだいぶ前から使ってないけどな
C++03時代の話を未だにしてるけど、20年も前の環境だし、Boostも1.84からC++03のサポート終了が本格化する
この際、C++20まで一気にジャンプしたら良い
C++17と20の間にも互換性の壁があるので、過去の資産があるならC++17でも良いかもしれない
C++20は便利なので、資産が無いなら一気に飛べ

**デフォルトの名無しさん** · 2023/05/01(月) 20:01:02.15

顧客には「リスク歓迎型」と「リスク重視型」いるが、Rustはいまのところ
前者が使ってる段階。

**デフォルトの名無しさん** · 2023/05/01(月) 20:02:56.23

突然俺様用語で書かれてもサッパリ分かりません

**デフォルトの名無しさん** · 2023/05/01(月) 20:50:37.93

let temp = Client::RiskFriendly;

**デフォルトの名無しさん** · 2023/05/01(月) 21:35:47.11

>>824
C++20になったらこれに対応できるようになるって話はどうなったんだっけ？

[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(|x| x.to_string()).join("-")

**デフォルトの名無しさん** · 2023/05/01(月) 23:46:23.25

よく表れる偉そうな人は
プロジェクトでは活躍できているの？

**デフォルトの名無しさん** · 2023/05/02(火) 00:22:12.87

>>828
既存のイテレータの問題を改善するためにC++20でstd::rangesが導入された
しかし限界というか期待外れというか無理があって使いやすいものにならなかった

**デフォルトの名無しさん** · 2023/05/02(火) 00:49:58.35

>>826
リスクを恐れずに新しいものを好む人、失敗しても特になんとも思わない人が
試している状態だということ。

**デフォルトの名無しさん** · 2023/05/02(火) 01:35:45.73

>>831
それは5年以上前の話
現在は様々なインフラがRust製に置き換わりつつある段階
例えばRustで書かれたAWSが安全に問題なく高速に作動し、その上に世界中の各社のサービスが動いていて、世界中の人々が恩恵を受けている

**デフォルトの名無しさん** · 2023/05/02(火) 01:41:41.06

>>832
ただ、プログラミング業界において、まだ、使用者数が1%未満くらいしかない。
イノベーター理論によれば、2.5%位までが「イノベーター層」、次の20%
位が、アーリーアダプター層で、それらを合わせた23%位が、「リスク歓迎層」
いわゆる「人柱層」であり、その後に「キャズム」と呼ばれる溝が有ると言われている。
だからRustが普及するためにはまだまだずっと先が有る。

**デフォルトの名無しさん** · 2023/05/02(火) 01:45:06.54

>>833
大勢に影響ないが、数値はちょっとずれていて、ちゃんと調べてみたら、
イノベーター層: 2.5%
アーリーアダプター層: 13.5%
----キャズム----
アーリーマジョリティー層 34.0%
だったわ。

**デフォルトの名無しさん** · 2023/05/02(火) 01:46:19.77

ソースコードはAWSの0.001%も使われとらんと思うぞw

**デフォルトの名無しさん** · 2023/05/02(火) 01:54:56.85

有料商品だとリスクを恐れて買わない人が多いけど、Rustは無料だから
試すのはタダだから、金銭的には損はしないが時間とストレージ容量は損する。
ジュースみたいに飲んで美味しいわけでもない。

**デフォルトの名無しさん** · 2023/05/02(火) 01:58:03.27

Rustを試す場合、ストレージが結構食うのと、「パス汚染」の問題や、いつのまにか
大事にしていた開発の複雑なツールチェイン環境が
「おかしくなるかも知れない問題」が有る。
経験法則として、ツールチェインが壊れることは辛すぎる。

**デフォルトの名無しさん** · 2023/05/02(火) 02:05:41.68

Rustは、確かにニーズは有ることはあるが、緊急レベルが低いのかもね。
それとターゲット層が狭いかも。

**デフォルトの名無しさん** · 2023/05/02(火) 02:12:40.43

Rustを使いたがってる層って、なぜかサーバーサイドで使おうと思ってる人が多いが、
複雑で遅くなるような処理はMySQLやSQLiteみたいなDBMSがやってしまう。
だから自分でやる部分は余り速度が必要なかったりする。
Rustは安全性と速度の両方重視だが、この場合、速度は不要であり、安全面だけ
しか残らないがだとすると、JavaやRubyなどでも互角と言えてしまう。
しかも分かり易さは後者の方が勝ってる。

**デフォルトの名無しさん** · 2023/05/02(火) 02:15:06.87

SNSを見ても、なぜかRustをフロントやデスクトップアプリで使おうとしている人は少ない。
そもそもデスクトップアプリが絶滅危惧種になりつつあるが。
多分、GAFAMが全部需要を吸い取っているからかも知れんが。

**デフォルトの名無しさん** · 2023/05/02(火) 02:28:34.92

ガンダム00のイノベーター理論か

**デフォルトの名無しさん** · 2023/05/02(火) 02:28:36.64

そもそも、サーバーサイドやフロントは、CもC++も余り使われてこなかったが、
SNSでは、なぜか、そっち側でRustを使いたがってる人が目立つ。
そもそも、デスクトップやゲームでCやC++が強い。だから、C++の優位性や
慣れ親しみが有る人と層が被ってない。
なのに、彼らは「C/C++をRustが置き換える」と主張している。
彼らにはそもそも自分がCやC++を愛した時期があったのかと問うてみたい。
C++を使いこなした上で、さらにそれより便利だからRustを使おうとしている
ならまだしも、C++とは縁遠い人達がRustを礼賛している様に思えてならない。

**デフォルトの名無しさん** · 2023/05/02(火) 02:32:22.41

もともとC++が大嫌いな状態で、C++が消えてなくなればいい、と思っている
層がRustを嬉々として使いたがっている様に見えるのだ。
そして彼らはC/C++を一切話題にしない。もし今ままでC/C++を使い倒してきた
ならば、少しは触れてもいいはずなのに、彼らが好きな言語としてあげるリスト
の中には、決まって、C/C++が全く触れられておらず、
JS、Go、Kotlin、Java、Pythonなどが上がってくる。
C#ですら上がって来ない事が多い。

**デフォルトの名無しさん** · 2023/05/02(火) 02:33:32.83

よく見ると、彼らがリストアップする言語は、無料の環境ばかりだ。

**デフォルトの名無しさん** · 2023/05/02(火) 02:36:05.66

昔から言われてきたことだが、Windowsのデスクトップアプリを作るのは、
ほぼ Visual Studio 一択だということである、
そして、その場合、通常、C/C++(MFC、Win32)、C#(WinForms、WPF)、VB
のどれかとなる。
プロは、有料のVSを購入して、C++でMFCで組むのが標準とされてきた。

**デフォルトの名無しさん** · 2023/05/02(火) 02:50:16.47

MFCは流石にストレスだな

**デフォルトの名無しさん** · 2023/05/02(火) 02:51:03.38

BoostはURLやJSON、そしてついにMySQLが入ったぞ

**デフォルトの名無しさん** · 2023/05/02(火) 03:00:27.06

RegexはC++のパワーが発揮される好例だが、あまり使われてないね
文字を返すイテレータさえ用意できれば、どんなデータ構造にも正規表現が使えるんだから凄いけどね

**デフォルトの名無しさん** · 2023/05/02(火) 03:04:05.05

>>848
RegExの基礎の部分で、日本語周りがちょっと独特の仕様だった気がする。
UTF8やSJISには状態がない(Stateless)符合なのに、状態があるかのような
独特のC関数(?)を基礎にしている。
それは、もはやほとんど使われて無い、「Shiftじゃない方のJIS」の
ShiftIn(SI), ShiftOut(SO)方式ならそうかも知れないが。

**デフォルトの名無しさん** · 2023/05/02(火) 03:04:47.55

>>846
だとするとC#しか選択肢が無い事になる。

**デフォルトの名無しさん** · 2023/05/02(火) 03:11:39.95

>>843
補足すると、C++が好きで、または、どこかに問題点を感じながらも使ってきたが、
さらに良いものを見つけたからRustに移行したい、というなら、C++も好きな
言語リストに入れたり、話題に触れたりするものだが、彼らは一切、
C++に触れようとしない傾向がある。
どんな言語にも欠点があるから、長年使ってきた言語であるならば、
愛着があっても、欠点も知っている。だから、もしC++を使ってきたならば、
C++の欠点を沢山気付いても、一方で、愛着も持っているはずだ。
ところが、彼らは、C++について一切触れずに、初心者用の簡易言語で
あるところの、JS、Java、Kotlin、Go、C#、Pythonなどには沢山触れるが、
C++には一切触れようとしない。

**デフォルトの名無しさん** · 2023/05/02(火) 03:20:05.38

>>851
キミもあまりC++を使っていないのでは？

**デフォルトの名無しさん** · 2023/05/02(火) 03:25:47.05

>>852
使ってる。

**デフォルトの名無しさん** · 2023/05/02(火) 04:07:41.22

世の中の流れが様々な方向からRustへ向かっているところをみると残るは時間だけの問題かな
ロジックに弱い一部のプログラマーはRustでスマートに組めない傾向があるからその点での差別化も進むのかもしれない

**デフォルトの名無しさん** · 2023/05/02(火) 04:14:17.45

>>854
もしかしたらそうなのかも知れないな、と思う自分もいるが、
数値を見れば、ランキングは19位くらいで、使用者数は1%未満の状態。
それと個人的には、言語としてメンドクサイ。

**デフォルトの名無しさん** · 2023/05/02(火) 04:38:02.37

>>855
Rustをメンドクサイと感じるならロジックが苦手な人なのかもしれないね
一般的にどの言語でもプログラミングする時はロジックをパズルのように解いて組み立てていくんだけど
複雑な対象かどうかでそのパズルの難易度は様々でロジックが苦手な人は難しいパズルのケースではお手上げ

Rustではその解かなきゃいけないパズルが問題によって難易度が増す場合もある
それと引き換えに様々な多大な恩恵が生じるわけだけどロジックが苦手な人には難しかったり面倒だったり無理だったりしてしまう
でも元々のパズル自体の難度に対してそれほど難しくなるわけではないためプログラマーのほとんどはクリアできるけどね
結果的に極一部のロジックが苦手なプログラマーを切り捨てることで可読性や開発効率や安全性などを上昇させるのがRustというものの本質かもね

**デフォルトの名無しさん** · 2023/05/02(火) 04:41:01.18

>>856
ロジックは大好き。
ロジックではなく、Rustの字面が合わない。

**デフォルトの名無しさん** · 2023/05/02(火) 04:45:42.58

ぶったぎるようでいて、多分関連ある素直に聞かせて
上のほうでも少し出たけど、RustのOOPってどうなん慣れればわりとなんでも書ける?
所有権関係を見習いたくて、そればっかり今まで調べてて、OOPの書き心地に目を向けてなかった

**デフォルトの名無しさん** · 2023/05/02(火) 04:54:26.56

>>850
たまにはATL/WTLも思い出してあげてください

あれ使いこなせるようになりたいな
そんなことを思いながらC++を趣味でやってる(異業種です

**デフォルトの名無しさん** · 2023/05/02(火) 04:58:39.18

>>858
RustやGoなど最近の言語ではOOPの癌であるクラス継承を完全に廃止してくれている点が朗報
代わりにRustでは強力なトレイトがあって非常に分かりやすく可読性もよいコードに誘導されて書き心地もよいよ
ただしクラス継承という癌におかされ中毒症状というか依存症の人の一部はリハビリ期間が必要なこともあるみたい

**デフォルトの名無しさん** · 2023/05/02(火) 05:48:34.65

COMとか使ってたしねえ今でもあるけど
やたらややこしくしないまで含めて、継承は使ってた世代だねえ
template<>だけがあるような感覚? (概要を聞いてからリファレンス見る勢

**デフォルトの名無しさん** · 2023/05/02(火) 06:21:41.90

Rustのtraitは機能や能力や属性でもあるし制約条件でもあるし抽象的な型でもあるしtraitオブジェクトとしての値でもあるし
traitと普通の型とは直交する存在だから多対多の関係になるけど
trait自体に別のtraitが制約としてつく形でtraitの持つ機能の継承のように見せかけて継承ではないけど親子関係的になったり
実際のコードではほとんどのケースで具体型にモノモーフィゼーションされるからコストはないけど
一部のケースではtraitオブジェクトになって動的ディスパッチになる点ではC++で仮想関数を定義する基底クラス的な立ち位置でもあり

**デフォルトの名無しさん** · 2023/05/02(火) 07:08:44.62

>>861
templateをRustでジェネリクスとして表現する時に、そのジェネリックパラメータに対して、条件(制約)を課す指示となる「トレイト境界」としてもトレイトが登場
そのおかげで、C++のtemplate使用時の展開深入りしたわかりにくいエラーメッセージが出る前に、Rustではトレイト境界を指定するようにとコンパイラが叱ってくれて話が早いこともある

**デフォルトの名無しさん** · 2023/05/02(火) 07:41:43.85

世界中で使われたはずのHaskellが跡形もないからどうだろな

**デフォルトの名無しさん** · 2023/05/02(火) 08:07:22.94

GC言語なんていくらでも置き換えが効くからな
しかもGC言語は用途が狭く限定
ダメ言語C++が長く崩れなかったのはライバルが登場しなかっただけにすぎない
何もかも優れている非GC言語が登場してC++がようやく崩れた

**デフォルトの名無しさん** · 2023/05/02(火) 08:21:54.70

なんでそんな目の敵ｗ C++はいいぞ