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

**デフォルトの名無しさん** · 2023/10/28(土) 13:45:00.38

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

っていう雑談スレ。

・C/C++ <=> Rust いまさら聞けない移行質問なども適当にどぞ
・レスバはじめんのは勝手だけど、面白いこと・へぇなこと書いたヤツが優勝
・マな話は、マのスレもご活用ください↓

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

関連スレ(マ板): Google&Microsoft「セキュリティバグの70%はC/C++のメモリ管理ミス。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

**デフォルトの名無しさん** · 2023/11/06(月) 18:45:27.89

>>138
お前もかなりのザコだぞ

**デフォルトの名無しさん** · 2023/11/06(月) 19:58:38.94

>>137
文法はNimの圧勝。

**デフォルトの名無しさん** · 2023/11/06(月) 21:52:22.89

Nimの唯一のメリットがPythonに似た文法と言われているが
このスレの住人はそれをメリットと感じない

**デフォルトの名無しさん** · 2023/11/06(月) 22:00:03.84

何でお前が住人を代表してるの?w

**デフォルトの名無しさん** · 2023/11/06(月) 22:14:50.32

複オジ代表チーっすw

**デフォルトの名無しさん** · 2023/11/06(月) 23:09:22.63

まあ複おじ隔離スレなんだから代表は複おじでいいんじゃない？

**デフォルトの名無しさん** · 2023/11/06(月) 23:55:02.14

>>141
インデントではなく波括弧でブロックを表すのが好まれている多数派

**デフォルトの名無しさん** · 2023/11/07(火) 07:52:40.08

>>146
c世代はそうだけど、pythonユーザーの方が多い現在はインデントブロックの方が主流。じゃなきゃYAMLとか流行らん。
LISPも丸括弧使ってるけどインデントブロック風の整形しているし、波括弧ブロックが多数派とは思えん。

**デフォルトの名無しさん** · 2023/11/07(火) 09:16:54.55

詭弁 - Wikipedia
https://ja.wikipedia.org/wiki/%E8%A9%AD%E5%BC%81

**デフォルトの名無しさん** · 2023/11/07(火) 09:19:09.61

>>147
どさくさに紛れてYAMLを流行り扱いすんなやｗｗ

**デフォルトの名無しさん** · 2023/11/07(火) 09:23:10.10

Pythonみたいなインデントずれたら明後日の動きする様な言語は欠損言語だろ

**デフォルトの名無しさん** · 2023/11/07(火) 09:32:16.68

「Linux」メンテナーの燃え尽き症候群問題--業務内容の変化と支援の必要性
https://japan.zdnet.com/article/35210969/

Corbet氏は「Rust」言語がLinux開発で採用されたことについて歓迎しているものの、これによってメンテナーにさらなる負担がかかるようにもなるとした。同氏は、「カーネルメンテナーを務める以上、Rust言語で記述されたコードのマージ依頼も受け取ることになるため、同言語に対する極めて深い知識が必要となる(中略)既に多忙を極め、自らの仕事量に圧倒されているメンテナーに対して、この新言語の学習を求めるのは酷というものだ。このため、この点は今後、問題となりそうだ」と述べた。

**デフォルトの名無しさん** · 2023/11/07(火) 09:58:24.32

>>147
インデントに整形以上の意味を持たせた言語の方が好まれてるかどうかの話をしてるのに
他の言語でもインデントで整形してることを根拠にしても意味ないだろ

**デフォルトの名無しさん** · 2023/11/07(火) 10:27:17.78

インデントより会話の論点を揃えないとな

**デフォルトの名無しさん** · 2023/11/07(火) 10:45:48.18

whitespace significantな言語はプログラミングの素人にとっては多少読みやすいというメリットはある
しかしそれ以外はデメリットだらけなので素人を釣りたい場合を除いて採用するメリットがない

**デフォルトの名無しさん** · 2023/11/07(火) 10:53:19.67

リモートワーク制度が削減・廃止されたら「転職や別案件を探す」が4割--
「Offers」登録者調査

ITエンジニア／デザイナーの副業・転職サービス「Offers」を提供するoverflowは、
同社が運営する「Offersデジタル人材総研」にて「リモートワーク実態調査2023」
を公表した。
これによると、リモートワークになり、5人に1人が引っ越したと回答した。そのうち、
現職でリモートワーク制度が削減・廃止された場合、「転職や別案件を探す」という
回答が44.0％にものぼった。一方「会社と交渉する」という回答は40.0％、
「引っ越さず受け入れる」が12.0％となった。
さらにリモートワークを希望している理由として「通勤時間が無駄だと感じている」が
87.7％でトップとなった。このほか「個人の時間ができる」(62.3％)、「副業を続け
やすいから」(39.6％)、「子育てができる」(35.8％)と続いた。

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

> Pythonみたいなインデントずれたら明後日の動きする様な言語は欠損言語だろ
ほんとこれ
> インデントより会話の論点を揃えないとな
ほんとこれ

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

>>150
ずれたら思ってない動作になる場合があるのは確かだが
ずれることがめったに起こらない

**デフォルトの名無しさん** · 2023/11/07(火) 17:52:17.78

正直食わず嫌いなんだが、あのインデント式、慣れない悪寒しかしない
yaml書かされるけど、おっかなびっくりだわ

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

ifとかforがネストしてるときに論理構成変えたときに
ぐちゃぐちゃになったりしないの？

**デフォルトの名無しさん** · 2023/11/07(火) 19:03:13.54

コピペした時困るのはあるけど
そんなネスト深いところにコピペする時点でコードが終わってるのだろう

**デフォルトの名無しさん** · 2023/11/07(火) 19:24:21.76

あっちのファイルはスペースで、こっちのファイルはタブでそれぞれインデントしてるとかw
更に同じファイル内でスペースとタブが混在したインデントしてるとかw

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

シープラの文法が醜いってとこまで合意できてるってことでいいかな

**デフォルトの名無しさん** · 2023/11/07(火) 22:35:55.75

>>162
ダメなのはNim

**デフォルトの名無しさん** · 2023/11/07(火) 23:28:55.99

長いだけあって、いくらでも悪く書ける

**デフォルトの名無しさん** · 2023/11/07(火) 23:29:26.17

>>151
>メンテナーに報酬を支払おうというところはほとんど「ない」のだ
メンテナーほぼ金貰ってないのかｗ
壮絶な時間の無駄だな
linuxなんて潰れちまえ

**デフォルトの名無しさん** · 2023/11/07(火) 23:40:27.67

>>162
インデント構文はその醜さを完全に理解した親切な人が書くとわりとマシに読めるって話なら同意できる

**デフォルトの名無しさん** · 2023/11/08(水) 07:17:12.54

>>163
Nimの文法が駄目ならRustは産業廃棄物だな。

**デフォルトの名無しさん** · 2023/11/08(水) 09:28:37.50

>>167
最初からそう言ってますよね

**デフォルトの名無しさん** · 2023/11/08(水) 10:02:49.03

>>165
Linuxなんて無料だから普及したってだけだし
無名の大学生が作った有料カーネルなんか誰が使うかよ

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

Rustが最も美しいけどC++に比べたらPythonの方がまし

**デフォルトの名無しさん** · 2023/11/08(水) 10:21:07.20

cppは汚らしい

**デフォルトの名無しさん** · 2023/11/08(水) 10:34:17.23

あれがいいんだぞ

でも、template<>のごちゃっとしてるのは苦手

**デフォルトの名無しさん** · 2023/11/08(水) 10:49:02.95

NimはPython由来の文法が多い中でprocヘッダーの区切りをわざわざ=記号にしたのは何でなの？

**デフォルトの名無しさん** · 2023/11/08(水) 11:13:52.74

痘痕もエクボっていうしずっと使ってると美しく見えるのかもしれん
始祖のハゲ散らかしもイケオジに見えるのかもしれん

**デフォルトの名無しさん** · 2023/11/08(水) 11:26:24.47

>>173
macro

**デフォルトの名無しさん** · 2023/11/08(水) 12:07:42.23

>>175
関係ないやろ

**デフォルトの名無しさん** · 2023/11/08(水) 13:10:09.47

>>169
BSD

**デフォルトの名無しさん** · 2023/11/08(水) 14:09:53.13

Nimは継承あるじゃん
だれか突っ込めよ
複オジ嘘つき放題じゃねーか

**デフォルトの名無しさん** · 2023/11/08(水) 14:45:54.44

Nim使ってる時点でセンスがないからな

**デフォルトの名無しさん** · 2023/11/08(水) 15:29:55.01

Nimはクラスがないため当然クラス継承もない

**デフォルトの名無しさん** · 2023/11/08(水) 15:41:40.86

このスレの半分は複オジのウソで出来ています。
用法・用量を守って正しくご使用下さい。

**デフォルトの名無しさん** · 2023/11/08(水) 15:50:23.42

複おじってニートでしょ？
なんか我々と対等に喋れること自体がとんでもない体験なんだし
もっと感謝して欲しいね

**デフォルトの名無しさん** · 2023/11/08(水) 17:01:15.09

C++er的にC23ってどうなの？

**デフォルトの名無しさん** · 2023/11/08(水) 17:32:19.27

#embed はあると安心ないとやっぱり一手間かかる
clangではできてたっぽいけど(VC派

**デフォルトの名無しさん** · 2023/11/08(水) 17:35:31.79

>>180
www

**デフォルトの名無しさん** · 2023/11/08(水) 18:12:04.23

>>180
クラス継承だけが継承ではないのだけどね

**デフォルトの名無しさん** · 2023/11/08(水) 19:11:51.53

有害とされているのはクラスの継承
それ以外の継承はあってもいい

**デフォルトの名無しさん** · 2023/11/08(水) 19:13:26.39

>>182
とニートが申しております

**デフォルトの名無しさん** · 2023/11/08(水) 20:13:44.98

有害なのは多重継承では？
単一継承はいいでしょ

**デフォルトの名無しさん** · 2023/11/08(水) 20:15:54.45

綺麗に書けるならという条件がつく
本来、綺麗に階層化するのが目的だったのが、どうしてもごちゃついてしまう
基本にして難それが継承

って感じでいい?

**デフォルトの名無しさん** · 2023/11/08(水) 20:28:47.14

>>189
大抵は駄目。
継承は「インターフェイスの共有」という外部との契約と、「実装の共有」という内部との契約をごっちゃにしているから、すぐに設計がごちゃごちゃになる。

内部と外部は明確に分離したほうが手間がかかるが問題になりにくい。

**デフォルトの名無しさん** · 2023/11/08(水) 20:35:51.69

クラス継承では複数の機能を継承したくなった時に多重継承が起きてしまう
多重継承を避けるには使うすべての機能を巨大なツリー関係に押し込める本末転倒な事態になる

**デフォルトの名無しさん** · 2023/11/08(水) 20:37:37.21

>継承は「インターフェイスの共有」という外部との契約と、「実装の共有」という内部との契約をごっちゃにしている
Nimの継承にも同じことが当てはまるけど
Nimにはクラスはないから有害じゃないという主張でいいのかな？

**デフォルトの名無しさん** · 2023/11/08(水) 20:53:57.66

>>189
そのレベル浅い知識ならおそらく「SOLID原則」を知らないでしょ
勉強しな？
メンテや機能追加を繰り返してるとどうしても内部構造が腐敗していくものよ

**デフォルトの名無しさん** · 2023/11/08(水) 21:01:44.80

>>193
理想は継承なしの共通インターフェイス。継承自体いらん。

原理的には同じメソッドを持つのならどんなインスタンスでも同じインターフェイスで扱えるから、継承を使って扱えるインターフェイスを制限するのは「早すぎる最適化」としかいえん。

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

多重継承って本当に悪か?
多重継承を使う前に周りに悪って教え込まれたので
これまで本格的に使ったことはないのだが
みんなは酷い目にあったことあるかい?
敢えて「多重継承=悪」思考停止論を提起したい

**デフォルトの名無しさん** · 2023/11/08(水) 21:20:08.15

有用なものを何も生み出せない
目的と手段を履き違えた無能たちの知識バトルロワイヤル

**デフォルトの名無しさん** · 2023/11/08(水) 21:23:09.85

現在動作してる過去のシステムを捨てるわけにいかない状況で、新しい共通システムを書くには継承がいいと思うけど
どうなんでしょう？素人考えなんですけど。

**デフォルトの名無しさん** · 2023/11/08(水) 21:23:13.22

オブジェクト指向のメリットってホントにメリットなんだろうか？

**デフォルトの名無しさん** · 2023/11/08(水) 21:35:45.96

>>199
モジュール分割の方法を広げるっていうメリットはある。
カーネルドライバー部分はオブジェクト指向した方がいいって、否定派のlinusも認めてる。

**デフォルトの名無しさん** · 2023/11/08(水) 21:56:55.44

オブジェクト指向 ⊃ クラスの使用 ⊃ クラス継承の使用

オブジェクト指向自体は問題ない
クラスの使用も継承を用いなければ問題ないが
クラスと他との違いはクラス継承にあるように本質がその継承機能にあるため
クラス自体を無くしたプログラミング言語が最近は多数派となった

**デフォルトの名無しさん** · 2023/11/08(水) 22:24:24.52

>>201
全部マイナー言語じゃん
支持されてないんだよ

**デフォルトの名無しさん** · 2023/11/08(水) 22:32:30.66

>>195
全く答えになってない
Nimの継承は君が主張している有害な継承に該当するのか否か？

**デフォルトの名無しさん** · 2023/11/08(水) 22:52:12.05

>>203
「継承自体いらん」と書いているだろ。

shared_ptr<function<T>>のTがインターフェイスになったのがあれば継承自体いらん。

**デフォルトの名無しさん** · 2023/11/08(水) 23:04:09.93

>継承は「インターフェイスの共有」という外部との契約と、「実装の共有」という内部との契約をごっちゃにしている
もう一つ付け加えると↑これはデフォルト実装のあるTraitやインターフェースにも同じことが当てはまる
でもインターフェースのデフォルト実装を有害と言う人は少ない
なぜだろうね？

**デフォルトの名無しさん** · 2023/11/08(水) 23:45:38.02

特殊事情持ち出して一般論を語るな。
例外的なのが無いとでも思ってるのか

**デフォルトの名無しさん** · 2023/11/08(水) 23:46:51.04

最初はきれいなんだよ、最初は

**デフォルトの名無しさん** · 2023/11/08(水) 23:59:18.59

>>205
Rustのtraitはデータ(メンバー)とは切り離された設計になっているから
デフォルト実装自身がデータ(メンバー)にアクセスできない点で違うんじゃないか

**デフォルトの名無しさん** · 2023/11/09(木) 11:54:56.82

>>196
iostream観たら判るし

**デフォルトの名無しさん** · 2023/11/09(木) 12:57:22.06

>>194
SOLIDは名前しか知らないがライブラリのクラスを拡張するときは継承あると便利だけどな
コンポジションだとゲッターかプロパティでライブラリクラスのオブジェクト取得しないといけないし面倒じゃない？

**デフォルトの名無しさん** · 2023/11/09(木) 15:49:49.48

>>210
その継承やらインターフェースの設計をうまくやるためのパターンがSOLIDだよ
これを知らずに継承使ってるやつは大抵ゴミコードを量産してる

**デフォルトの名無しさん** · 2023/11/09(木) 16:57:59.50

>>211
ゴミコードは沢山書いてきたが継承使う時はほどほどにしてるからな
あまりゴミ化はしたことないな
SOLIDは概念が難しかったがこれって継承の複雑さが出ちゃってるね
継承はもっとシンプルに使わないと

**デフォルトの名無しさん** · 2023/11/09(木) 17:02:28.18

>>212
継承がなければSOLIDなんてほぼ考えなくて良いからね
「インターフェース分離の原則」あたりさえ気にしていれば問題ないし
モダンな言語ならインターフェースは言語のコアとして搭載されてる
継承を無くすることでSOLID原則みたいな面倒なことを考えなくても良いし
コードもシンプルになるしメリットしかない
だから最近の言語では継承がない
これがモダンな言語では継承が存在しない理由

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

>継承がなければSOLIDなんてほぼ考えなくて良いからね
おいおいw
揃いも揃って何なんだここは

**デフォルトの名無しさん** · 2023/11/09(木) 17:41:32.22

>>214
？
ほぼ継承に関する問題を解決するための原則だぞこれは

**デフォルトの名無しさん** · 2023/11/09(木) 17:53:14.45

Lだけだろ

**デフォルトの名無しさん** · 2023/11/09(木) 18:02:47.11

S 継承がなければ単一にしかなりようがない
O 継承がなければ勝手に追加も削除も容易
L 継承がなければ置換もクソもない
I 継承がなければインターフェースなんていくらでも分離できる
D 言わずもがな

継承があるからこの原則は生きる
つまり継承の悪い部分を避けるための
オブジェクト指向の原則

その知識は何のためにあるのか？
きちんと自分の頭で考えよう
それが知恵というものだ

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

オブジェクト指向の全ての悪は継承にあり
DIなんかもこの悪を退治するための刃だ
継承こそがソフトウェアをゴミ化し
変更をしにくくする悪魔👿なのだ
この事実を誰も指摘してないことは驚愕に値する
オブジェクト指向はオワコンとかいう人に限って何が悪なのか明示的に指摘できていない

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

俺ははっきりと言う
継承こそが全ての間違いの始まりだと

**デフォルトの名無しさん** · 2023/11/09(木) 18:09:54.14

はるか昔「オブ脳」という概念があった
全てをオブジェクト指向で考えようというものだ
まずベースクラスを考えて～
いやちょい待ち
その発想がまず間違っている
なんでベースクラスを最初から考えられると思った？
そんなことは神でもできない
そのようなオブ脳🧠こそゴミエンジニアへの入り口
幸いモダンな言語は継承を排除した
英断だと思う

**デフォルトの名無しさん** · 2023/11/09(木) 18:13:43.54

モダンな言語に置いては
インターフェース(トレイトとか制約とかプロトコルとか言語によって名前は違うが本質は同じ)
ありきで考える
言語のコアもインターフェース前提で設計されている
誰もベースクラスガーとか考えない
まずインターフェース考えよ、となる
そしてそのインターフェースを満たすための構造を考える
こうすることでデータがシンプルになり
頭を悩ますことが減る
これは業務ロジックでも同じ
インターフェースから考えよ

**デフォルトの名無しさん** · 2023/11/09(木) 18:24:54.65

solidが面倒ってのもよくわからんな

**デフォルトの名無しさん** · 2023/11/09(木) 18:28:01.90

このスレの半分は複オジのウソで出来ています。
用法・用量を守って正しくご使用下さい。

**デフォルトの名無しさん** · 2023/11/09(木) 18:41:12.35

「それは、継承から始まった。」っていう世代の資産がまだまだあるからね

自分用には、継承を、きれいに書けるようになりたい
C++から逃げるな

**デフォルトの名無しさん** · 2023/11/09(木) 19:19:30.86

継承を綺麗に書けないバカの断末魔ww

**デフォルトの名無しさん** · 2023/11/09(木) 19:22:43.00

断末魔で結構
継承カッケーと思ってるエンジニアにどどいてくれ

**デフォルトの名無しさん** · 2023/11/09(木) 19:23:51.89

ソフトウェア業界における設計失敗2選
1.ヌルポ
2.継承

**デフォルトの名無しさん** · 2023/11/09(木) 19:28:25.39

ぬるぽは原始より居ただろ
飼い慣らせない人間が悪い(俺を含む

**デフォルトの名無しさん** · 2023/11/09(木) 19:45:53.51

ヌルポをなくしてOption型をデフォルトにすべきだった
コンパイラによるチェックを必須にすべきだったのよ
本当にこれだけのことで全てが変わった

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

>>229
10年後に今の言語がどうけなされてるか言ってみ？

**デフォルトの名無しさん** · 2023/11/09(木) 20:26:38.28

result型とoption型
rustだけがこの２つをデフォルトに採用した
生き残るのはrustだけ

**デフォルトの名無しさん** · 2023/11/09(木) 20:29:05.07

>>229
Object型じゃ型情報少なすぎるだろ。
全てのクラスにNullObjectを付けてnullptrを禁止すればマシになる。

あとインターフェイスはもっと制約を減らすべき。
c++テンプレートだと、テンプレート引数に指定するクラスはテンプレートについて何も知らなくていいけど、インターフェイスもそのレベルでクラス・インスタンスから切り離されているべきだ。

**デフォルトの名無しさん** · 2023/11/09(木) 20:57:20.45

> Object型じゃ型情報少なすぎるだろ。
> 全てのクラスにNullObjectを付けてnullptrを禁止すればマシになる

Object型ではなくOption型
全ての各型にNullObjectを付ける必要はなく
任意のT型に対してOption<T>型を用いればよい
Option<T>型の値はSome(Tの値)のNone二択
T型自体は決してNull値やNone値をとなってはいけなくここが肝要

**デフォルトの名無しさん** · 2023/11/09(木) 21:05:40.49

ただジェネリクスやテンプレートがないCに追加するのは容易ではない
それほど罪深い仕様

**デフォルトの名無しさん** · 2023/11/09(木) 22:19:33.09

C++はまだ改良頑張ってるよ。
Cなんて、C11ぶり10年以上も改良してないとか酷すぎる。

**デフォルトの名無しさん** · 2023/11/09(木) 22:33:55.61

C23ってどうなったんだっけか
もう少し先？

**デフォルトの名無しさん** · 2023/11/09(木) 23:32:03.13

SOLIDすら理解してないやつがRust推してるのか
呆れを通り越して悲しみを感じる

**デフォルトの名無しさん** · 2023/11/09(木) 23:45:28.17

SOLID理解してない人はクラス継承派だからアンチRust側

**デフォルトの名無しさん** · 2023/11/09(木) 23:51:27.12

>>236
新機能は決まって来年ISOから発行