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

**デフォルトの名無しさん** · 2023/02/25(土) 09:49:46.74

C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな？

**デフォルトの名無しさん** · 2023/03/24(金) 13:55:42.43

デストラクタは所有してる変数のブロックを抜けるまでに呼ばれることが保証されてるけど
正確なタイミングはコンパイラが決めてるから予測はできない
例えば何かを解放しないと以降で競合が生じる場合はブロックの途中で解放されることもある

ただ
A()
B(&A)
みたいにBがAを参照してるような状況だとBが消えるまでAを動かせないから
結果的にC++と同じように逆順で解放されることになる

ライフタイム周りはコンパイラが制約を満たせる処理順を見つけて裏で調整する感じだから
最初は戸惑うかもしれないね

**デフォルトの名無しさん** · 2023/03/24(金) 14:00:41.09

>>521
let _ = x; で棄てる以外に
ブロックの途中でデストラクタが呼ばれるケースあるっけ？

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

>>520
それどこのスマポ

**デフォルトの名無しさん** · 2023/03/24(金) 14:38:27.83

>>520,521
なるほどね
参照って読んでるのは>>506だとfirstのことかな?
参照の中にC++のstd::shared_ptrの挙動を内在させてるイメージを持った
Vecのアクセスにiteratorは使わないのかな?

**デフォルトの名無しさん** · 2023/03/24(金) 14:55:23.36

>>523
デストラクタにスマポもポインタも関係ない
Rustでは任意の自作型にデストラクタを実装できる
(ただしCopyを実装していないことが条件)

// 例えば整数i32型のみを持つ構造体Foo
struct Foo(i32);

impl Drop for Foo {
// デストラクタ実装
fn drop(&mut self) {
println!("drop: Foo({})", self.0);
}
}

fn main() {
let _x = Foo(123); // メインブロックを終えてからdropされる
{
let _x = Foo(456); // 内ブロックを終えてからdropされる
let _x = Foo(789); // 内ブロックを終えてからdropされる
println!("内ブロック終わり");
}
println!("メインブロック終わり");
}

【実行結果】
内ブロック終わり
drop: Foo(789)
drop: Foo(456)
メインブロック終わり
drop: Foo(123)

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

>>522
すまん
ちょっと勘違いしてた
Dropあると明示的に捨てる必要あるな

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

>>524
C++とRustはiteratorで指すものが微妙に異なるので要注意だがまずは折衷するとして
例えば
let mut v = vec![1, 2, 3];
for p in v.iter_mut() {
*p += 10;
}
これでイテレータを使って11,12,13

**デフォルトの名無しさん** · 2023/03/24(金) 15:18:17.49

>>521
Drop scopeがブロックとは限らないだけで予測できないわけではなくね？

>>525
let x = Foo(123).0 * 2;
とか
let mut x = Foo(124);
x = Foo(456);
とか

**デフォルトの名無しさん** · 2023/03/24(金) 15:28:04.96

>>527
>>506の let first = &v[0]; の部分をイテレータに差し替えると
（記法は分からんが仮に let first = v.iter() かな?）
イテレータのライフタイムも参照の場合と変わらず
v.push(11);と最終行のdangerousを併存させると
capacityに関わらず問答無用にコンパイルエラーといことかな?

**デフォルトの名無しさん** · 2023/03/24(金) 15:30:39.43

>>528
変数が所有している値のデストラクタが呼ばれるのはブロックを抜けた直後だけど
変数が所有しない一時的な値や変数が所有しなくなる代入前の値などは
_へ棄てるのと同じくブロック途中でデストラクタが呼ばれるね

**デフォルトの名無しさん** · 2023/03/24(金) 15:33:55.56

Rustってゴミ箱（_）があるんだなw

**デフォルトの名無しさん** · 2023/03/24(金) 15:51:46.07

>>529
もちろんイテレータは参照もしくは可変参照を持つ形となるのでsingle writer or multiple readersを満たす必要がある
それを満たせなければコンパイルエラーとなりデータ競合を防げる

**デフォルトの名無しさん** · 2023/03/24(金) 15:55:15.22

>>531
棄てるのは _ へ棄てなくてもいくらでも方法があり
例えばブロックを作れば
{
let _tmp = x;
}
これで_tmpへ値が移動してブロックを抜けるときに消える

他にも例えば以下の関数を定義して
fn 棄てる<T>(_tmp: T) {
// 何もなし
}
棄てる(x); とすればその関数へ値が移動して関数ブロックを抜けるときに消える
この棄てる関数は同じものがstd::mem::drop()に用意されているので意図をはっきりさせるためにはそれを使うことで可読性を持たせる

**デフォルトの名無しさん** · 2023/03/24(金) 17:20:54.03

>>530
細かいことだけど一時的な値は内部的に一時変数が所有してることになってて一時変数がDrop scopeを抜けていなくなるタイミングでデストラクタが実行される

let _ = Foo(123);やx = Foo(456);は代入によって値の所有者がいなくなるからそのタイミングですぐにデストラクタが実行される

**デフォルトの名無しさん** · 2023/03/24(金) 20:26:32.48

>>533
こういうことだわな

#include <iostream>
using namespace std;

struct A {
A () {cout << "constructor\n";}
~A () {cout << "destructor\n";}
};

template <typename T> void drop (unique_ptr <T> &&p) {}

int main () {
auto x {make_unique <A> ()};
{
auto _tmp = move (x);
}
drop (move (x));
return 0;
}

**デフォルトの名無しさん** · 2023/03/24(金) 21:50:27.51

dropバグっとるがな

**デフォルトの名無しさん** · 2023/03/24(金) 21:51:22.79

ごめんごめん

**デフォルトの名無しさん** · 2023/03/25(土) 09:38:10.15

屁臭

**デフォルトの名無しさん** · 2023/03/25(土) 20:06:44.69

>>504
そういう小さい単純な例ならばdangerousなデータ競合であると自明だが
もっと複雑化して見逃す例が実際に起きてセキュリティの穴になる

**デフォルトの名無しさん** · 2023/03/25(土) 20:52:44.35

デバッガですぐに分かることなので
みょうちくりんな文法を新たに覚えようという動機にはならん

**デフォルトの名無しさん** · 2023/03/25(土) 20:56:23.22

不明な挙動があるのが発見されてない時点でもデバッガ使うの？　変なコード書いた本人に自覚がないから不具合として発現するのであって、正常に動くであろうと期待できてる時点でも？
時間の無駄では？
デバッガでわかるよりコンパイラでわかるなら圧倒的にそっちがベターでもあるし

**デフォルトの名無しさん** · 2023/03/25(土) 20:58:28.17

>>541
>不明な挙動があるのが発見されてない時点で
それはいくらなんでも無理だろw

**デフォルトの名無しさん** · 2023/03/25(土) 20:59:37.07

>>540
デバッガなど実行時でないと検知できないショボいプログラミング言語は滅びそう
昔はC++は神の言語と信じていたけどアドバンテージを全て失ってしまったもの

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

コンパイル時点でチェックが入るのはRustの利点だが
C/C++と乖離した文法を新たに覚えるというコストを払おうとは全く思わん
俺がRustを覚えるとしたらシステムコールがRustで書かれたOSを
使うことになったときだけ
当分ない

**デフォルトの名無しさん** · 2023/03/25(土) 21:04:16.45

>>543
でもLockFreeQueueをsafeで実装できないんでしょ?

**デフォルトの名無しさん** · 2023/03/25(土) 21:10:35.10

周りに使用を強制されるほどRustは普及していないので
Rust推しの諸君は自らRustを選択したのだろうけど
そんなにCでのメモリの扱い方に苦労したのかい?
Rust使う人はどちらかというと言語マニアの人達だと思ってたのだが?

**デフォルトの名無しさん** · 2023/03/25(土) 21:14:16.97

>>545
そういうのはすべてsafeなインタフェイスでライブラリが作られてるから
LockFree{Queue,Stack,Map,Set,Chanel}すべてsafeなインタフェイスを用いてRustプログラミングできるよ

**デフォルトの名無しさん** · 2023/03/25(土) 21:17:55.09

>>546
開発効率と可読性が圧倒的にRust＞＞＞C++
Rustはコンパイル時点でミスが見つかるから効率良すぎ
可読性も大差でパターンマッチングの有無も大きい

**デフォルトの名無しさん** · 2023/03/25(土) 21:18:50.17

>>547
Rustでプログラミンしたいのではなくて
言語のウリとしている特徴の不備の一例として上げている
平たく言うと中途半端

**デフォルトの名無しさん** · 2023/03/25(土) 21:23:11.57

>>549
すべてがunsafeなC++と違って
RustならLockFree{Queue,Stack,Map,Set,Chanel}をsafeなインタフェイスで使うことで自分の書くプログラムをsafeにできるよ
つまりRustコンパイラが書いたプログラムの安全性の保証をしてくれるよ

**デフォルトの名無しさん** · 2023/03/25(土) 21:36:28.93

>>550
Rustではsafeで全てを表現したいという目論見が破綻した
ということを指摘したい
これで良いかな?
更に良い言語が出るかもね

**デフォルトの名無しさん** · 2023/03/25(土) 22:24:32.21

Rustは例えばVecすら中身はunsafeを使ったsafeなコードだらけだぞ
LockFreeも全く同様
unsafeを使ったsafeなコードで基本ライブラリを作成しsafeなインターフェースを提供できることがRustの最大の長所
それらを使うプログラムはsafeにすることが出来てコンパイル時点で各問題を排除できる
C++が敗北した理由である

**デフォルトの名無しさん** · 2023/03/25(土) 22:28:23.02

>>552
>Rustは例えばVecすら中身はunsafeを使ったsafeなコードだらけだぞ
だめだめじゃん
設計が間違ってるんだよ（というか無理だったんだよ）

**デフォルトの名無しさん** · 2023/03/25(土) 23:00:19.34

プログラムすべてがunsafeなC++という失敗作を改善したことを設計ミスと言うのは理不尽ね

**デフォルトの名無しさん** · 2023/03/25(土) 23:10:11.97

>>543
C++大好きだが、神の言語とはちょっと違う希がす

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

>>554
Rustは一過性の言語だと思うよ
C++はCを包含しているからそうそう消えないと思うが
Rustは後続の言語にオーバーライドされると思う

**デフォルトの名無しさん** · 2023/03/25(土) 23:58:43.93

現代語はコロコロ変わるが古文漢文は変化しないからそうそう消えない
理系のくせにそこに気付くとはえらいね

**デフォルトの名無しさん** · 2023/03/26(日) 00:04:07.04

大手が採用するといったんだから当面生きてるでしょ
C/C++は進化はよ

**デフォルトの名無しさん** · 2023/03/26(日) 00:38:53.03

もう負けたんだよC++は
向こうの方が宣伝がうまかった

**デフォルトの名無しさん** · 2023/03/26(日) 01:40:41.16

ついこないだまで、コルーチンだって書けなかっただろ
C++が「負け」てるのは、今に始まったことじゃない
キャッチアップしていってくれればいいんだよ

**デフォルトの名無しさん** · 2023/03/26(日) 08:24:37.76

Nimは脳汁出るんだが
Rustからは出て来ない
::が邪魔しとるんかの

**デフォルトの名無しさん** · 2023/03/26(日) 08:28:50.22

>>543
Cは神言語だが
C++は神じゃないどころか
クソ言語だと言うのは当初から言われてた

**デフォルトの名無しさん** · 2023/03/26(日) 08:38:26.46

C++はたとえリアルタイム性があっても、信頼性が求められる業務をしようとすると、どうしてもCで良いじゃんってレベルまでコーディングルールをガチガチに制約するからね。

**デフォルトの名無しさん** · 2023/03/26(日) 08:42:34.83

C++のメリットが完全に無くなったな
無理に挙げるとすれば過去のプログラムと過去のプログラマーくらいか

**デフォルトの名無しさん** · 2023/03/26(日) 11:07:56.67

C++のメリットは自由度
自由が障壁になる用途ではメリットもクソもないｗ

C++で書きたいというニーズは当面残る
だからC++には進化してもらわないといけない

**デフォルトの名無しさん** · 2023/03/26(日) 11:19:02.92

GC無し言語でやりたいことは全部Rustでやって
C/C++には滅びて欲しい人間が増えてんだろ
プレーンCのコードぐらいRustにコンバート出来るんじゃね？
知らんけど

**デフォルトの名無しさん** · 2023/03/26(日) 12:33:33.90

C++中毒な人が多いからね(俺含む
捨てろと言われても無理だねえｗ Rustを使わないとは一言もいってない

>>563
これまで、自由になりすぎたC++をいかに縛るかっていう試みはいくらもあったが、普及しなかった
ついにRustが答えを出した C++は「いや～負けましたね～」とかいいながら、その成果を吸収すればいい

**デフォルトの名無しさん** · 2023/03/26(日) 13:03:12.58

自分で自由を縛ろうというインセンティブは働かないからね
何らかの外からの圧力がない限りなかなか増えないだろうね
キラープロダクトがあれば一気に普及するだろうけど

**デフォルトの名無しさん** · 2023/03/26(日) 13:05:22.20

メモリ管理云々言ってる人もセールストークの受け売りで
自分でメモリ管理に苦労して「あ! Rustが解決法だ!」って
始めた人はいないだろうし

**デフォルトの名無しさん** · 2023/03/26(日) 13:06:33.66

C++に依存すればするほど、これｇｄｇｄだ…ってのがわかってくるもんだけど、
どう縛るのが「正解」か、なかなか答えが出なかったんだよね
スマポどころか、ハンドルや参照カウントの概念が大昔からあったけど、決定打にならなかった

**デフォルトの名無しさん** · 2023/03/26(日) 13:09:22.51

>>570
それは自然言語と同じで使う人のレベルによる

**デフォルトの名無しさん** · 2023/03/26(日) 13:12:55.73

おまいらRedoxとかどうよ? GoogleのOSは一般の人は使えるの?

**デフォルトの名無しさん** · 2023/03/26(日) 13:14:54.55

自由には需要のある自由と需要のない自由があってだな

どっちも供給されなければ胡散臭いとか偽善だとか
需要ってあなたの願望ですよね、とかいうのが自由にまつわる典型的な詭弁

**デフォルトの名無しさん** · 2023/03/26(日) 13:19:57.22

需要あるから>>567の言うように
「自由になりすぎたC++をいかに縛るかっていう試みは
いくらもあったが、普及しなかった」のでは?
Rustもこのままだとone of themだろうけど

**デフォルトの名無しさん** · 2023/03/26(日) 14:41:00.96

規格となるに足る、縛り(の規格)の決定打がなかった
あーでもないこーでもないいって、混沌を放置したのはC++の落ち度
バイナリだって肥大化し放題だったしね Cに近いC++erは、忸怩たる思いで眺めてたものさ

**デフォルトの名無しさん** · 2023/03/26(日) 14:50:08.58

ここって情報古い？
https://maku77.github.io/rust/

あと
if let Ok(hoge) = fuga {
}
って本当に可読性良くなってると思ってる？(嫌味じゃなくてマジでRust推しの人の意見聴きたい)

**デフォルトの名無しさん** · 2023/03/26(日) 14:57:31.39

>>575
は? C++はISOもJISも規格あるやろ?
Rustに規格あるの?

**デフォルトの名無しさん** · 2023/03/26(日) 15:01:34.10

>>577
大手が採用するといったんだから、採用されるバージョンが、当面のデファクトスタンダードになる
それは規格といっていいよそして規格は、管理下で進化する

**デフォルトの名無しさん** · 2023/03/26(日) 15:09:14.63

ダメだこりゃ
普及はもしするとしても30年くらいは掛かりそう

**デフォルトの名無しさん** · 2023/03/26(日) 15:58:38.13

どちらを習得すればセックスできますか

**デフォルトの名無しさん** · 2023/03/26(日) 16:29:03.94

>>576
Rustの if let でのenumパターンマッチングは、
まずRustのenumを理解する必要があるけど、例えば、

enum State {
StateA(i32),
StateB(i32),
StateC(i32, f32),
}

if let State::StateA(i) = x {
println!("StateA: {i}");
}

これをc++で書こうとするとこうなるのかな。

struct StateA { int i; };
struct StateB { int i; };
struct StateC { int i; float f; };
typedef std::variant<StateA, StateB, StateC> State;

if (std::holds_alternative<StateA>(x)) {
StateA& a = std::get<StateA>(x);
std::cout << "StateA: " << a.i << "\n";
}

この両者がたぶん同じ。
if let構文のおかげでRustは可読性が増していると思う。

**デフォルトの名無しさん** · 2023/03/26(日) 18:24:04.21

>>576
>if let Ok(hoge) = fuga {
>}
>って本当に可読性良くなってると思ってる？
ResultやOptionが複数ネストしていくと可読性が低いコードはどうしてもできるけど単純なやつは何の問題もないと思ってる

ちなみに何と比べてる？

**デフォルトの名無しさん** · 2023/03/26(日) 23:06:22.21

>>581
C++は利便性のいい代数的データ型の導入に失敗したからしょうがない
さらにパターンマッチングの導入は未だに議論中のまま進みそうにない
結果としてそのような不便で分かりにくい記述をするしかない

**デフォルトの名無しさん** · 2023/03/26(日) 23:24:54.44

C++にはswitchを使うなunionを使うなという縛りがあった
CとC++を意図的に隔離すれば縛りを無視できるから問題視されないが

**デフォルトの名無しさん** · 2023/03/26(日) 23:35:48.82

何か問題でも?

**デフォルトの名無しさん** · 2023/03/26(日) 23:51:37.40

if letとその比較対象も、言語を統一しようと思わなければ問題ないんだろう

**デフォルトの名無しさん** · 2023/03/27(月) 00:02:41.74

ぶっちゃけRUSTでなくてもいいんだよ
安全性のためには

schemeとかHaskellみたいな言語には定義外の動作が(基本的には）存在しないという強力な安全性があるわけだし

じゃあなんでこんなにRUSTがもてはやされるのかというと、単に宣伝がうまかっただけ

**デフォルトの名無しさん** · 2023/03/27(月) 05:32:45.27

safe Rustには未定義動作が存在しない
そしてunsafeを用いてsafeなインタフェースを提供する時にもそれが義務付けられている
したがってそれらを用いるRustに未定義動作は存在しない
未定義動作まみれのC/C++との決定的な違いである

**デフォルトの名無しさん** · 2023/03/27(月) 06:40:49.82

間違うヤツが悪い、って世代の規格だもんな、変に不親切は徹底してるわｗ

**デフォルトの名無しさん** · 2023/03/27(月) 11:50:25.04

C++に憧れるのをやめましょう
憧れてしまったら超えられないんで

**デフォルトの名無しさん** · 2023/03/27(月) 12:09:54.31

>>581
Rustの代数的データ型であるenumに対して
対応するC++のstd::variantは五重苦だよな
・機能が弱い
・使いにくい
・見にくい
・使われていない
・知られていない
C++の機能強化は尽く失敗していて進化が望めない

**デフォルトの名無しさん** · 2023/03/27(月) 12:10:13.46

>>588
safeと限定しているところが誠実で笑える
良いと思うよ!w

**デフォルトの名無しさん** · 2023/03/27(月) 12:48:40.60

まぁRust使うくらいならC++使うよねってのはあるよね
これまでの資産が全然違うわ
DirectXとかOpenGLとかオーディオ系の低レイヤーのやつはやっぱりC++が強い

**デフォルトの名無しさん** · 2023/03/27(月) 12:49:34.80

Rust信者が全部ラッパー作ってくれるならまぁわからんでも無いけど君たちどうせ人が作ったライブラリしか使わないんでしょ？

**デフォルトの名無しさん** · 2023/03/27(月) 13:03:55.96

大手が採用するっていうんだから、大手がどんどんライブラリ置き換えやるでしょ
ただラッパ書くだけじゃなくて、Rustで書けばAPIを適切に使用してるって保証されるものじゃないとね

**デフォルトの名無しさん** · 2023/03/27(月) 13:12:32.89

人任せだなw
Cと共存なんて考えだと廃れて消えると思うよ
カーネルからRustにしないとな
以下の考察は俺も同じ印象を持っている

RustもJuliaやGoみたいに廃れて消えていく気がしている。
https://qiita.com/AKKYM/items/78c04840bc72d9db834d

**デフォルトの名無しさん** · 2023/03/27(月) 13:14:48.15

技術的な良し悪しとしてはRustは充分だと思うけど
言語が使われるかどうかはその上の生態学の問題だからね

**デフォルトの名無しさん** · 2023/03/27(月) 13:36:37.38

なんでカーネルとシェルが共存する現実を学ぶことすらできないんだろうなあ
スマホにはシェルスクリプトがないから？

**デフォルトの名無しさん** · 2023/03/27(月) 13:46:30.78

カーネルから書かないと
諸君のフラストレーションは解消されないと思うよ

**デフォルトの名無しさん** · 2023/03/27(月) 13:50:47.73

打倒するC++の最大の特徴はCを包含していること
C++覚えればCの知識は付いてくるが
CとRust両方覚えるの面倒やん?
CをリプレースしなければC++もリプレスできん

**デフォルトの名無しさん** · 2023/03/27(月) 14:18:03.99

>>591
C++の可読性の低さはそのような無理矢理な機能拡張の失敗にある

**デフォルトの名無しさん** · 2023/03/27(月) 14:34:40.20

>>576
https://qiita.com/tatsuya6502/items/cd41599291e2e5f38a4a

**デフォルトの名無しさん** · 2023/03/27(月) 14:43:24.48

>>600
>C++覚えればCの知識は付いてくるが

doubt

**デフォルトの名無しさん** · 2023/03/27(月) 14:44:18.04

>>603
反例は?

**デフォルトの名無しさん** · 2023/03/27(月) 14:59:46.99

>>596
>TypeScriptはずっと流行っていてこれから廃れていく気はしない。この差はなんなんだろう。。。

たいしたことやってないから

**デフォルトの名無しさん** · 2023/03/27(月) 16:45:29.16

>>596
Qiitaって5chと同レベルだったんだな
記事もコメントもここまで酷いとは

**デフォルトの名無しさん** · 2023/03/27(月) 17:02:39.76

酷いのはお前の頭と顔だよ

**デフォルトの名無しさん** · 2023/03/27(月) 17:10:12.43

>>606
記事はバカだけどコメントはまあいいんじゃね？
それよりも、Rustを置き換えられる言語が出現しないと、Rustの天下が続きそ。
C並みに高速で何でも書けてGCもなく、にも関わらず様々な安全性が静的に保証される言語が、Rust以外に芽も出てこなさげ。

**デフォルトの名無しさん** · 2023/03/27(月) 17:19:21.38

>>605
MSだから

**デフォルトの名無しさん** · 2023/03/27(月) 17:23:03.66

何が続きそ。だよ
自演バレないように新文体開拓しようとしてんのマジでキモいわ

**デフォルトの名無しさん** · 2023/03/27(月) 17:26:14.23

コメントしたった

TypeScriptはC#やDelphiを作ったアンダースヘルスバーグが設計してるからです
以上

**デフォルトの名無しさん** · 2023/03/27(月) 17:26:50.78

Rustまだ全然天下じゃないんだが…
周り見えてない人なのかな？

**デフォルトの名無しさん** · 2023/03/27(月) 17:27:28.03

言うほどガベコレ悪いか？って話になるんだが君たち何を作ってんだ？

**デフォルトの名無しさん** · 2023/03/27(月) 17:28:15.22

言うほど1フレーム1フレームの処理落ちが問題になることしてんの？
ゲームくらいじゃね？

**デフォルトの名無しさん** · 2023/03/27(月) 17:28:57.15

その点ゲームでRustは使われない
マジで何してんの？って話よな

**デフォルトの名無しさん** · 2023/03/27(月) 17:35:59.10

>>614
車載ソフト関係だけど、命に関わるようなシステムは最大実行時間を理論的に算出出来ないとアカんのや
GCだとそれが出来ないから論外なんや、、

**デフォルトの名無しさん** · 2023/03/27(月) 17:37:53.83

>>616
ほんでその車載ソフトはRustで書かれんのか？

**デフォルトの名無しさん** · 2023/03/27(月) 17:39:01.06

>>617
いや、まだ言語的に対応してないからC/C++だね、、

**デフォルトの名無しさん** · 2023/03/27(月) 17:40:35.92

>>618
やっぱりね
いつになるんだろうねRustが対応するの
一生来ないかもしれん

**デフォルトの名無しさん** · 2023/03/27(月) 17:52:34.31

>>619
そうやね
ぶっちゃけ危なそうなものはコーディングルールで縛られるし、過去トラブルや不具合対策も沢山あるから困らないんだよね。
品質保証のためにアセンブラも見るけど、C/C++はアセンブラと比べながら見やすいし