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

**デフォルトの名無しさん** · 2023/06/30(金) 21:56:35.52

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

っていう雑談スレ。

結局C++とRustってどっちが良いの？ 4traits
https://mevius.5ch.net/test/read.cgi/tech/1686046386/

関連スレ(マ板): Google&MS「バグの70%はC/C++。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

**デフォルトの名無しさん** · 2023/07/06(木) 01:38:49.41

お前らエロ画像ぶっこ抜くときもRust使ってんの？

**デフォルトの名無しさん** · 2023/07/06(木) 02:02:58.99

Rustならエロも安全さ

**デフォルトの名無しさん** · 2023/07/06(木) 03:18:32.83

>>172
計算効率の向上のためですね。よく使うような奴はコピーにする様に動くようにしたいですね。
>>171
途中で伸び縮みはしないと思う。
途中で中身が書きかえられたらすごい都合が良い。出来れば途中で中身が書きかえられるようにしたい。

**デフォルトの名無しさん** · 2023/07/06(木) 03:21:51.88

>>175
Rustは構造体の使用的に属性に参照渡しするのが結構ダルいのではと思っています。正直、自分はライフタイムの`aとかいう感じの修飾子に関してあまり理解できてない

**デフォルトの名無しさん** · 2023/07/06(木) 03:30:31.36

>>174
Numpyはデフォルトでは浅いコピー、要は参照で渡してるっぽいです。自分が調べてみた感じでは。

**デフォルトの名無しさん** · 2023/07/06(木) 04:40:27.15

スレチですが、
k0 レジスタを、opmask レジスタとして predicate
としては使用できない、ということで正しいのでしょうか？
つまり、
EVEX.512.0F.W0 5E /r
VDIVPS zmm1 {k1}{z}, zmm2, zmm3/m512/m32bcst{er}
と書いてある場合、{k1} の部分は、{k2}や{k3}
などを指定できて、EVEX.aaa の部分には、2や3など、
1～7 の数値が指定できますが、0 だけは指定できないのでしょう
か？　しかし、それだと、k0 のビットが常に全て 1 である
という便利な性質が利用できない気がします。
もしかして、たとえば、k2 レジスタに k0 レジスタの値を
代入してから、{k1}の部分を{k2}と書け、と言うことなんで
しょうか。
だとすれば、なぜ、そんな回りくどい事を。

**デフォルトの名無しさん** · 2023/07/06(木) 05:15:09.86

>>178
書き換えありの場合
同時共有しないなら単純に&mut [T]渡し
共有するならスレッド内かスレッド間か排他制御の粒度や種類はどうかなどで分かれる
例えばスレッド間で共有しつつ書き込みありで排他制御の粒度はスライス全体で読み込み複数同時可ならばArc<RwLock<&mut [T]>>など

**デフォルトの名無しさん** · 2023/07/06(木) 06:11:31.90

すまん&mutはもちろん不要
Arc<RwLock<[T]>> ね
配列からでなくVecからなら
Arc<RwLock<Vec<T>>> か
長さ変わらないならBox化して
Arc<RwLock<Box<[T]>>>

**デフォルトの名無しさん** · 2023/07/06(木) 08:06:47.31

>>179
それは例えると
「私はC言語を書けますがポインタを使えません」
と言ってるのと同じでマズいな

**デフォルトの名無しさん** · 2023/07/06(木) 12:21:28.35

>>164
lifetime 付けたくないなら
struct Ndarray<T> {
pub data: Option<&Vec<T>>,
pub shape: Option<&Vec<usize>>,
pub stride Option<&Vec<usize>>,
}

**デフォルトの名無しさん** · 2023/07/06(木) 12:24:16.16

>>176
初めてのRustはエロ収集scrapingツールだった

**デフォルトの名無しさん** · 2023/07/06(木) 14:30:31.20

ネタにマジレスですまんが、スクレーピングみたいのってRust得意なんけ

**デフォルトの名無しさん** · 2023/07/06(木) 14:53:35.46

得意かは知らないが非同期io機能が充実しててやりやすい

**デフォルトの名無しさん** · 2023/07/06(木) 17:09:56.98

rustに全てを置いてきた

**デフォルトの名無しさん** · 2023/07/06(木) 21:21:05.78

>>185
ないわw

**デフォルトの名無しさん** · 2023/07/06(木) 21:34:07.17

シャローコピーってスライス代入と普通の代入の時だけでしょ？
ディープコピーは...演算子を使う
さらにin-place演算子(+=など)は変数を書き換える
それ以外は全てコピーを作って返す
これがnumpy

**デフォルトの名無しさん** · 2023/07/06(木) 21:39:43.66

ndarrayはスライスをマクロで定義している
さらにスライスはArrayViewを返す
これは真似た方が良い
あとはslice_mut...assignという書き方を踏襲するかどうか

**デフォルトの名無しさん** · 2023/07/07(金) 02:03:56.84

>>192
自分は初学者でも分かりやすいように気本的に配列に関する全ての操作はNdarray構造体に押し込みたいんだよね。

**デフォルトの名無しさん** · 2023/07/07(金) 03:34:18.30

ダメそう

**デフォルトの名無しさん** · 2023/07/07(金) 04:58:02.59

オプソのするつもりならRustに反対しないが
オプソにするつもりの無いプロジェクトなら
迷わずC/C++ジャマイカ？

**デフォルトの名無しさん** · 2023/07/07(金) 11:05:05.39

RustでNumpyライクなクレートを制作中だけど、ある程度形になったら公開するつもりだよ。OSSにするつもりだし。

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

>>193
rust使いに初心者がいるとは思えないのだが
ということはやはりRcで持つということになるんかね
chainerのarrayの実装もshared_ptrで持ってる
https://github.com/chainer/chainer/blob/master/chainerx_cc/chainerx/array_body.h

**デフォルトの名無しさん** · 2023/07/07(金) 13:01:06.40

まぁでも実際には難しいやろな
かつてプログラミングの世界を席巻していたPascalを駆逐してCが覇権を握ったのは多分基本的な関数の呼び出し方式をcall by refference からcall by valueね変更したのが大きい
cpuの性能が上がるにつれ整数型とか浮動小数点型の受け渡し時程度なら毎回値をコピーする実装にしてもそれで落ちるパフォーマンスの低下はやはりcall by valueの持つ“読みやすさ、組みやすさ”の優位性が際立ってきた
でもとはいえ毎回呼び出しのたびに値をコピーするcall by valueに全統一するのは無理なので文字列やベクトル処理についてはcall by refferenceをえらべるようなよくいえば柔軟、悪くいえば場当たり的な実装にしたのがCが覇権を握った最大の要因かもしれない
しかし今日さらにプログラミング言語の研究が進んでRVO技術などを利用して"call by valueの文法なのにコピーしない"という事が可能になってきて話が違ってきたのは事実、この先この技術がさらに発展すれば“call by valueを使わないベクトル処理ライブラリ”なんてものが出てきてもおかしくはない
でもこのRVOはまだまだ使いにくい、Rustの資料色々読んでも「関数の戻り値の受け渡しの際必ずしもコピーが発生するわけではない」程度の話しか出てこない、この辺は今現在開発がどんどん進んで行っててまだまだ“企画”としてまとめられる段階にないんやろ
だとすると現状“ベクトル処理ライブラリ”をまとめるならcall by refferenceを使う他ない
問題はその際発生するlife time注釈をどうするかの問題、しかしコレもRustの版が進むにつれ変化している“開発途上”の立ち位置で“注釈の省略”の機能を了して“一才注釈なしで使える”はちょっと難しいかも

**デフォルトの名無しさん** · 2023/07/07(金) 13:05:19.96

>>197
初心者がRustに参入しやすくなるようなライブラリを作ることが目標だから。私自身も初心者に毛が生えたようなレベルだし。
同じ可変参照を持つ構造体のインスタンスが複数作られることを考慮してるからRxとかArcを使うことになる可能性は高い。

**デフォルトの名無しさん** · 2023/07/07(金) 13:17:59.91

いや高いじゃなくてw

**デフォルトの名無しさん** · 2023/07/07(金) 13:29:06.48

>>198
馬鹿には無理

**デフォルトの名無しさん** · 2023/07/07(金) 15:12:40.92

>>198
パフォーマンス？なんか思い込み主導のでたらめな話が書かれてるな
PASCALは教育用の言語でCは高級アセンブラみたいな実用言語
比べるほうがおかしい

pascalはPコードを吐く
Cは実行ファイルを吐く
パフォーマンスを考えるならそこから考えろよ
もともとpascal自体の活躍の場がない

移植性でCがドンドン実用化されてすそ野が広がった
Pascalはほぼ教育分野が主な活動の場であって大学などで2000年代初頭まで主に使われた

1990年中ぐらいから言語自体より何が出来るかの方が重要視されだした
UNIXがらみのCのツール(yacc lex)などを使う実用の方が教育の中心となりPascalが使われなくなった

**デフォルトの名無しさん** · 2023/07/07(金) 16:10:55.60

やりたいことが
・変更されない間は同じデータを共有する
・変更が必要になったらそこで自分専用に複製する
であれば一般にcopy-on-writeとかclone-on-write（cow）って呼ばれるパターン

RustにもCowって型があるけどこれは原本がはっきりしてる場合じゃないと使い難くて
全てのデータが対等というか原本が特定できない状況ならRc、Arcのmake_mutで似たようなことができる

ndarray使ったことないけどドキュメント見た感じだとArcArrayが似たようなことしてそう

**デフォルトの名無しさん** · 2023/07/07(金) 16:21:09.69

補足というかドキュメント読めば分かるけど
自分以外が参照してない場合は複製しないでそのまま変更するから余計なコピーは発生しない

**デフォルトの名無しさん** · 2023/07/07(金) 16:23:08.62

>>195
その他にも、英語で検索すると、Rustが向いて無い分野の事を指摘
する人が多い。
この板とは全然違う。

**デフォルトの名無しさん** · 2023/07/07(金) 16:24:54.69

RustがC/C++と比べて向いてない分野は沢山指摘されているが、
・ゲーム
・GUI
・大規模プログラム
・IDEが使いたい人
・パソコン用アプリ

Rustが向いているかもしれない分野は
・CUIの小規模プログラム
・サーバーサイドプログラム

**デフォルトの名無しさん** · 2023/07/07(金) 16:44:26.36

やべえ全く同意できねえ
パソコン用プログラムってどういうことだよせめてデスクトップアプリとかマシな言い方有るだろ

**デフォルトの名無しさん** · 2023/07/07(金) 16:47:26.05

>>206はいつものデタラメ君

**デフォルトの名無しさん** · 2023/07/07(金) 16:48:41.65

Delphiってpascalじゃなかったっけ？

**デフォルトの名無しさん** · 2023/07/07(金) 16:53:58.33

>>208
デタラメに感じないんだけど

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

>>210
C/C++とRustは同じ特性(ネイティブコンパイル・GC必要なし・低レベル記述可など)の言語
向いてる向いていないの大きな差異はない
違いとしてはC/C++はこれまでの様々な蓄積(ライブラリや既存システムに書ける人員など)を活かせることがメリット
Rustは後発言語のため言語自体に便利な機能や高度な機能が備わっており開発効率の高さなどがメリット

**デフォルトの名無しさん** · 2023/07/07(金) 17:45:59.16

Swift・Dartと並んで、LLVMに載ってる最新世代の言語だからな
いろいろと不可能が可能にもなるだろ

ただし、処理系自体がクソデカ
これはclangも同罪

**デフォルトの名無しさん** · 2023/07/07(金) 18:09:19.57

>>203
基本的にはこの感じでNdarray構造体を開発しようと思ってる。変更なしの間はデータを共有。変更時には他のインスタンスとデータを共有している場合は自分用にデータをクローンしてから変更。

**デフォルトの名無しさん** · 2023/07/07(金) 18:11:47.12

>>203
CowArrayというのを内部で使ってるね
Cowと類似したやり方で普遍のスライス配列と所有配列を両方表すことができるとコメントにある

**デフォルトの名無しさん** · 2023/07/07(金) 18:21:22.66

ndarrayよくできてんな
これでいい気がしてきたw

**デフォルトの名無しさん** · 2023/07/07(金) 18:39:25.19

crates.ioとかゴミだらけ
cargo clean すると何GBもゴミが使ってることが判る

**デフォルトの名無しさん** · 2023/07/07(金) 18:46:24.16

何GBとかTBの時代に大したことないのでは?

**デフォルトの名無しさん** · 2023/07/07(金) 21:11:30.29

RcとかArcってメモリ安全性が完全じゃないの？

**デフォルトの名無しさん** · 2023/07/07(金) 21:43:23.63

メモリ安全性が完全とは？

**デフォルトの名無しさん** · 2023/07/07(金) 21:59:23.68

>>219
所有権と借用のシステムが完璧に守られること。

**デフォルトの名無しさん** · 2023/07/07(金) 22:26:56.09

>>220
それは変わらんよ
ただ循環参照という厄介な問題が増える

**デフォルトの名無しさん** · 2023/07/07(金) 22:58:09.40

そこはC++でもRustでも同じで巡回参照にならないよう幹をツリー型にして巡回は弱参照にする

**デフォルトの名無しさん** · 2023/07/07(金) 23:39:19.49

>>202
TurboPASCALやDelphiを知らないのか？

**デフォルトの名無しさん** · 2023/07/07(金) 23:54:40.55

>>223
知ってる何なら両方使ってた

**デフォルトの名無しさん** · 2023/07/08(土) 01:05:12.94

Rustは開発効率が低い。

**デフォルトの名無しさん** · 2023/07/08(土) 01:06:47.91

とりあえずNdarray構造体はArcとMutexを使ってもう一度書き直すことにしたわ。

**デフォルトの名無しさん** · 2023/07/08(土) 01:08:55.16

C++と比べてRustの開発効率の高さは誰もが体感できる

**デフォルトの名無しさん** · 2023/07/08(土) 01:12:13.79

使いたい人は使えばいいよ。俺は知らん。自己責任。

**デフォルトの名無しさん** · 2023/07/08(土) 02:06:58.40

C, C++の方がRustに比べて制約が少ない分、ある意味楽に自分の考えてることをコードに落とし込めてたのはあるな。その代わり安全性はあれな訳だったのだけれど。

**デフォルトの名無しさん** · 2023/07/08(土) 02:21:17.48

new や delete も実はとても安全で単純で理解し易い。
void func()
{
　BYTE *p = new BYTE[100];
　(p に対する処理);
　delete [] p;
}
のように単純明確で、最初に new、最後に delete を書くだけ。
そして複雑な場合のケアレスミスを防ぐため、class のコンストラクタと
デストラクタが発明された。それもとても簡単で
class CSome {
protected:
　BYTE *p;
public:
　CSome() { p = new BYTE[100];}
　~CSome() { delete [] p;}
};
と書くだけでいい。これは定型みたいなもので、何も難しいことは無い。

**デフォルトの名無しさん** · 2023/07/08(土) 02:31:43.22

>>230
the rule of 5/3/0違反
ザコ

**デフォルトの名無しさん** · 2023/07/08(土) 02:38:47.91

本当は頭が良い人なら問題なく使える。
馬鹿だからミスや論理間違いを犯すのでnewやdeleteは使うな、
となる。
おおっぴろげに言わないだけで馬鹿な人対策に過ぎない。
なのに、むしろ、頭のいい人を馬鹿な人が馬鹿にする。
馬鹿な人が行く会社や学校では、危険だから禁止、となる。
しかし、頭のいい人が行く会社や学校では何も言われない。
そういうことがある。むしろ、効率を高めるため使うべきで
ある場合があるからだ。

**デフォルトの名無しさん** · 2023/07/08(土) 02:41:12.58

なぜ禁止にするかと言えば、
「おまえらは馬鹿が多いから、禁止にしないとミスばっかり犯すから。
　おまえらはザコ要員として雇っているに過ぎないのに、
　頭がいい人限定の仕組みを使っていいわけない。」
と上の人は心の中にあるからだ。
そして決してそのことには触れない。

**デフォルトの名無しさん** · 2023/07/08(土) 02:43:21.56

普通の学校では「ゲームセンター禁止」となっていただろうが、
頭のいい人しか入れない学校では、別に行ってもいいですよ、
と言われたりしたものだ。
それと同様。

**デフォルトの名無しさん** · 2023/07/08(土) 03:00:11.97

間違わなければ間違わない
というのはエンジニアの考え方ではないね

**デフォルトの名無しさん** · 2023/07/08(土) 03:09:09.66

要は会社や学校では本当の事を言わないで、「禁止」とだけいうから
それが誰にでも当てはまることだと思って、掲示板に書いてしまう
人が多い。
ところが、それは秀才が集まる組織では当てはまらない。
秀才が当てはまる組織では、「あなたたちにだけ言う、
他の学校/組織には当てはまらない」
から話が始まる。
普通の人達が集まる組織では、そのことには絶対に触れない。

**デフォルトの名無しさん** · 2023/07/08(土) 03:10:02.90

>>235
それ言い出したら、難しいプログラムは出来ない。
速度もRustがC++と同じと言うのは嘘。
しかし、ここの人の知能では理解できない。

**デフォルトの名無しさん** · 2023/07/08(土) 03:12:22.92

>>235
だったらC#やJavaScriptでも使ってなさいな。

**デフォルトの名無しさん** · 2023/07/08(土) 03:15:35.36

>>230
メモリを確保した関数でそのメモリを解放する簡易なプログラムならばその通り
しかし現実には確保したメモリが他のデータ構造に組み込まれて最終的に解放されるのは別の複数の関数であったり
そこへの参照(ポインタ)が解放時に残っていないことを満たさなければいけなかったり
複数のスレッドで共有することもある
それらが複雑に組み合わさって全てのケースを細かく人間がミスなく管理しきれるかというと無理だ
そしてメモリ管理バグを日々どこかで量産され続けている

**デフォルトの名無しさん** · 2023/07/08(土) 03:16:15.71

>>238
以下の様に訂正する：
「うん。じゃあ、そういう人は Rust を使っていればいいよ」

**デフォルトの名無しさん** · 2023/07/08(土) 03:16:56.52

>>239
そのためにクラスの概念が発明されたんだよ。

**デフォルトの名無しさん** · 2023/07/08(土) 03:18:11.94

優秀なエンジニアは性善説に頼ったりはしない

**デフォルトの名無しさん** · 2023/07/08(土) 03:19:59.66

頭のいい人にとって便利な方法と、凡人にとって便利な方法とは異なる。
前者にとっては、後者用の方法はメンドクサく、
利便性が損なわれ、記述が長くなり、コーディングに時間がかかる。
頭がいいので、別にバグも入らない。
道具とはそういうものだ。

**デフォルトの名無しさん** · 2023/07/08(土) 03:20:54.59

>>242
程度問題だ。
利便性が損なわれすぎる場合は、安全性が高くても意味が無い。

**デフォルトの名無しさん** · 2023/07/08(土) 03:21:57.34

>>241
色んな基礎知識を欠いているだけでなく
まともなプログラミング経験がほとんどなさそう

**デフォルトの名無しさん** · 2023/07/08(土) 03:24:16.15

馬鹿な人は、自分と、自分の周囲に人を基準にしか考えられない。
「人間とは沢山ミスをするものだ」
「ミスするとそれを見つけ出して直すのにとても苦労するものだ」
などと。
実は優秀な人は、ミスもとても少ないし、ミスしても短時間で
根本原因を探り当てて、根本治癒できる能力がある。
凡人はそれが出来ないから、Rustが輝いて見えるらしい。

**デフォルトの名無しさん** · 2023/07/08(土) 03:24:55.50

>>245
俺は実世界ではとても優秀だと評価されている。

**デフォルトの名無しさん** · 2023/07/08(土) 03:25:04.83

>>244
性善説に頼るあなたは下手くそプログラマー

**デフォルトの名無しさん** · 2023/07/08(土) 03:33:15.30

>>248
そんなことない。
人によって能力に大差があるのに、一律に安全性だけを
重視する方がおかしい。
だから日本はプログラミング産業が大成しなかった。
絵と音楽と運動能力だけが才能だと見なし、
生まれながらの知的能力の差は認めない。
そして実験ばかり重視して理論軽視。
この板も、何かと言えば、測定しろ、ばかり。
測定せずに、イマジネーションを働かせて思考実験する
風土が育ってない。

**デフォルトの名無しさん** · 2023/07/08(土) 03:35:32.85

性善説に頼るという判断ミスはプログラミング以前の問題
エンジニアとしての資質がない

**デフォルトの名無しさん** · 2023/07/08(土) 03:44:16.18

>>250
むしろ、どんなプログラマも同じ制約やレギュレーションに従わなければ
ならないと考えるのは、まさに左翼的な考え。
左翼は個人差を認めず、みんなが同じ様に低め合おうとする。
能力が高ければ十分に安全に使えるのに、その方法を使ってる
人を軽蔑したりする。
「マシン語を直接使っている人は安全軽視だから能力が低い」
などと考えるのか、ということになる。
それは評価軸が間違っている。

**デフォルトの名無しさん** · 2023/07/08(土) 03:50:33.97

安全でないのはC++ではなくあなた
経験値が足りないのだろう

**デフォルトの名無しさん** · 2023/07/08(土) 03:59:42.63

>>252
違う。
IQと地頭の良さの違い。

**デフォルトの名無しさん** · 2023/07/08(土) 04:08:07.96

アメリカ生まれの「Security 詐欺」という経営方法が有り、
このスレの人はそれを使っている。
「C++は危ないんだから、それを使ってる人は馬鹿、愚か、無能」
と。
Securityの事を言われるとそれに従わざるを得なくなる人間心理を
悪用し、商売に結びつける詐欺商法。
マイクロソフトがOS Updateしない人を悪人扱いするのは、
UpdateのたびにOSを遅くして、新しいOSを買わせる手段。

**デフォルトの名無しさん** · 2023/07/08(土) 04:12:16.47

エンジニアは願望ではなく事実に基づいて判断する
これは難しいことではないが、向かない人もいる

**デフォルトの名無しさん** · 2023/07/08(土) 04:44:39.71

>>229
制約していく点はどちらもほぼ同じ
C++てもRustでもメモリ安全や競合に対応するため自分で律して正しく制約してプログラミングする
自分で律して正しく制約できなかった時に違いが出る
C++はコンパイルが通って実行時にミスに気付くかあるいは気付かないまま完成したと思い込む
Rustはコンパイルエラーとなりすぐに必ず気付くことでこの点でも開発効率が高い

**デフォルトの名無しさん** · 2023/07/08(土) 04:52:36.07

まあ、使わないのは自由なんだよ

所有権。あれはいいものだ
はよC++にも来い
大げさだなと思うような超小コードには使わなきゃいいだけ

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

>>256
それで開発効率が高くなるかどうかは人による。

**デフォルトの名無しさん** · 2023/07/08(土) 05:54:00.44

>>258
C++は実行時デバッグとなるため開発効率が低くなる
さらにレア発生のため気付かぬまま実運用に入ってから発覚するとペナルティコストも大きい
早期にコンパイルエラーとなるRustはそれらのコストが不要となる

**デフォルトの名無しさん** · 2023/07/08(土) 05:56:31.34

>>259
メモリ関連バグ以外のバグはRustでも残り得て、それがレア発生
のため気付かぬまま実運用に入ってから発覚することも有り得る。

**デフォルトの名無しさん** · 2023/07/08(土) 06:26:49.21

>>246

> 馬鹿な人は、自分と、自分の周囲に人を基準にしか考えられない。

これを言ってるお前が「自分を優秀だと思い込んでる実は馬鹿な人」だと考えると成立するよな

**デフォルトの名無しさん** · 2023/07/08(土) 07:59:41.56

>>260
C++とRustで同条件の話を持ち出しても反論になっていないよ

**デフォルトの名無しさん** · 2023/07/08(土) 08:44:23.04

シープラ使ってるハゲって自己評価高いな

**デフォルトの名無しさん** · 2023/07/08(土) 09:35:05.64

>>230
virtual 忘れるなよ

**デフォルトの名無しさん** · 2023/07/08(土) 09:39:11.12

>>239
>それらが複雑に組み合わさって全てのケースを細かく人間がミスなく管理しきれるかというと無理だ

これまさに
馬鹿には無理

**デフォルトの名無しさん** · 2023/07/08(土) 09:45:26.32

>>254
>アメリカ生まれの「Security 詐欺」という経営方法が有り、
>このスレの人はそれを使っている。
>「C++は危ないんだから、それを使ってる人は馬鹿、愚か、無能」
>と。
ほんそれ

>Securityの事を言われるとそれに従わざるを得なくなる人間心理を
>悪用し、商売に結びつける詐欺商法。
その通り
USO800認証取得で金も時間も掛かるとか能率を下げさせる攻撃がまかり通ってる

>マイクロソフトがOS Updateしない人を悪人扱いするのは、
>UpdateのたびにOSを遅くして、新しいOSを買わせる手段。
これは言い過ぎ(気持ちは判る)

**デフォルトの名無しさん** · 2023/07/08(土) 09:48:22.81

>>265
どんなに優秀な人たちでもミスを必ずする

Google＆Microsoft「セキュリティ脆弱性バグの70%はC/C++のメモリ管理ミスが原因。それがRustを採用した理由だ。」
https://xtech.nikkei.com/atcl/nxt/column/18/00692/042700054/

**デフォルトの名無しさん** · 2023/07/08(土) 09:48:50.55

>>259
>>258
>C++は実行時デバッグとなるため開発効率が低くなる
うそ
>さらにレア発生のため気付かぬまま実運用に入ってから発覚するとペナルティコストも大きい
判る
>早期にコンパイルエラーとなるRustはそれらのコストが不要となる
言い過ぎ

**デフォルトの名無しさん** · 2023/07/08(土) 09:50:07.66

>>261
お前モナ

**デフォルトの名無しさん** · 2023/07/08(土) 09:51:51.79

>>267
それはC/C++の責任ではない
馬鹿プログラマーに描かせてるのが原因

**デフォルトの名無しさん** · 2023/07/08(土) 09:56:21.11

>>270
と、これが馬鹿の思考です

**デフォルトの名無しさん** · 2023/07/08(土) 09:57:58.69

>>270
C++の欠陥のせいでセキュリティ脆弱性が多発している現実の記事
C++はメモリ管理ミスを検出すらできないためコンパイルエラーにすることができない
致命的な欠陥のあるC++を今後は捨てていこうという話

**デフォルトの名無しさん** · 2023/07/08(土) 10:49:35.84

Rustの次の言語に期待

**デフォルトの名無しさん** · 2023/07/08(土) 11:04:17.25

メモリ確保と開放位置をきっちり考えて書けないような奴がそれをプログラム言語のせいにしてるだけだな
ここからここまでがどうなってとか理論的に構造を考えれない奴に限って言語が悪いと責任転嫁をする
そういう奴がプログラム書くな
メモリ関連だけじゃなくバグだらけのプログラムしかできない

**デフォルトの名無しさん** · 2023/07/08(土) 11:10:07.92

間違わないやつは間違わない
は論理的ではない
エンジニアの考え方ではない