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

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

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

っていうスレ。

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

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

>>895
「言語学者」だな
どうにも話がかみ合わない時があるのは、こういうとこなんだろうな。。

じゃあ、WindowsからはC++はなくせない、貴方はその点には異論も関心もないということでおｋ?

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

言語としての良さを捨ててシェアをとりにいくのは本末転倒でしょうよ

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

>>897
もちろんLispの例は手続き型とは異なる例として出しただけだから直接関係ないよ
でも別の話としてRustは関数型言語としての特徴も随所に見られるから慣れてると有利だね
C++で所有権や無効な参照を生まないことに慣れてれば有利な点とは別方向だよ
それら両方に慣れてない人は多重に慣れないといけないもんね

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

>>898
継承と呼ばれているものは複数の役割を混在させた醜い悪だから廃止が好ましい
全く異なる言語であるGoでもRustでも同じ結論となったことがそれを実証している
複数の役割を各々個別に用意しているのでプログラマーが困ることはない
むしろコードが役割毎に分離されて保守性も可読性も上がっている

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

OOP理解してないやつが継承にダメ出ししてるからクソレスにしかならんよなw

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

Rustと違ってGoには実質継承と同じ使い方ができる機能があるのにね

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

STLのコンテナを拝借したいときとか
private継承protect継承は便利やぞ
これってRustの合成にあたる？

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

>>904
あれは継承ではなく移譲
全く異なるものを実質同じというのはこの議論で乱暴すぎる

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

Rustの美しいところだけで作ったOS…組み込みとかではできるかもしらんが

そうじゃない、Rustだって、泥臭いOOPもカバーできるだろ
泥臭いことを一切すべきでないとかいうなら、Rustは要らんぞ

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

いや、Rustは要らんだろ
Javascriptで十分

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

>>906
継承のメリットデメリットを理解してたら
そんな中身のない反論をするわけないんだけどな
まぁ他の人たちが複オジの嘘に騙されなければそれでいいや

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

継承と移譲は考え方も方向も真逆だよな
移譲を使うべきところで何でも継承を使ってしまう継承しか知らないプログラマーが多くて困ったことだが

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

ウィンドウシステムを考える時、

ボタンクリックで呼び出されるあなたのコードを

デリゲートで実装するか継承で実装するか

という風に考えると

まあ大した違いは無い

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

>>911
継承を敢えて持たないGo＆Rustにもすぐ適応できそうね

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

sudoとsuがRustで書き直される。メモリ安全性向上へ
https://pc.watch.impress.co.jp/docs/news/1498034.html

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

Rustはファイル分割の仕組みとクレート、モジュール構造が意味不明

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

>>913
これまだ世に出しちゃいけないレベルでは？
未完でも早めに発表しないと資金切られるのか？

https://github.com/memorysafety/sudo-rs
⚠ WARNING

Sudo-rs is currently under active development and is not suited for any production environment. Using sudo-rs is only recommended for development and testing purposes, but you should expect any system that has sudo-rs installed to break easily and to not be secure.

Rust part20
https://mevius.5ch.net/test/read.cgi/tech/1677771928/354
354: デフォルトの名無しさん sage 2023/05/02(火) 20:03:17.56 ID:6g8Nsfp3
>>341,345
sudu-rsとsudo(original)のtokeiしました
LOCが違い過ぎて機能的に同等とは思えませんが誰か確認してください
https://i.imgur.com/wqUfNLQ.png

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

>>913,915
スポーツ新聞やあるまいしｗ
挑戦するのはいいが相手がでかすぎる 1年かけてやりますってぶち上げたんだろ

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

>>914
確かに最初はそう思った

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

>>917
まともな解説サイトが知りたいんだけど

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

>>918
基本は公式
1. 2018 Edition Guide
2. Rust By Example
3. The Book

**デフォルトの名無しさん** · 2023/05/03(水) 10:07:34.41

クレート・モジュール周りでわかりにくかったのは以下の2点
どっちも公式に書いてはいるんだけど直感的じゃないからわかりにくい

1. modにはinline定義と定義読み込みという2つの使い方があること
2. main.rsとlib.rsが両方あるプロジェクトは2つのcrateができるのでmain.rs内でcrate::と書いてもlib.rs内のモジュールは参照できないこと

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

>>920
インライン定義とファイル指定の二種類あるのは色んなものでそんな感じ
Rustでも色んなサンプルを見てそうなってるから初めてでも違和感なかった

プログラムのディレクトリにはlib.rsは無しでmain.rsが始点
クレートのディレクトリは別に作ってlib.rsが始点とするよね
Cargo.tomlも分けたいし

**デフォルトの名無しさん** · 2023/05/03(水) 11:20:24.78

>>921
さすが複オジ
わかってないね

**デフォルトの名無しさん** · 2023/05/03(水) 11:30:59.61

>>849
すべてUTF8に統一すればいいのになにか支障があるの？

**デフォルトの名無しさん** · 2023/05/03(水) 11:55:22.78

クレートとモジュールの仕組みがあまり賢い作りじゃない気がする
なんかもっとやりようがあっただろうと

**デフォルトの名無しさん** · 2023/05/03(水) 12:04:46.25

>>914
>>924
なぜ全く別物であるクレートとモジュールを混ぜて語るんだ？
区別ついてるならそこを問題にしないだろ

**デフォルトの名無しさん** · 2023/05/03(水) 12:20:32.02

>>925
なぜ全く別物であるクレートとモジュールを混ぜて1つの章にするんだ？
区別ついてるならその関連性くらい自明だろw
https://doc.rust-lang.org/book/ch07-00-managing-growing-projects-with-packages-crates-and-modules.html

**デフォルトの名無しさん** · 2023/05/03(水) 12:57:47.35

これわかりやすいよ
https://m.youtube.com/watch?v=969j0qnJGi8

**デフォルトの名無しさん** · 2023/05/03(水) 13:04:28.94

>>923
太古からあるCだからこそ、太古のソースをも扱うってわけさ
おかげで、文字列の扱いがよそ(他言語)と比べて一見美しくないｗ

**デフォルトの名無しさん** · 2023/05/03(水) 13:38:42.16

モジュールはクレートの内部の話だから両者に混乱は起きないはず

**デフォルトの名無しさん** · 2023/05/03(水) 13:44:20.92

パッケージとクレートが紛らわしいって話でしょうが

**デフォルトの名無しさん** · 2023/05/03(水) 14:05:40.38

クレートは独立した存在として
パッケージ内にいようが外部パッケージにいようが動作するはずだよね
紛らわしいならパッケージを分離して確認してみたら

**デフォルトの名無しさん** · 2023/05/03(水) 14:17:42.39

クレートとモジュールを整理するとこんな感じ
どこか間違ってるかもしれない

・Rustのクレートは１つの仮想的なソースファイル（以下ルートファイル）から作られる
（rustcはインプットで１つのrsファイルだけを受け取ってクレート（bin, rlib, etc.）を出力する）

・ルートファイルは内部に階層的なモジュール（mod foo {...}）を持つことができる

・ルートファイルのモジュール"mod foo {...}"は"mod foo;"とすることでモジュール本体を別ファイルに切り出すことができる
　別ファイルのパスはそのモジュールの階層と名前によってルートファイルから相対的に決定される（ここが分かりにくい）
　また、#[path="..."]で場所を直接指定することもできる
　参考：https://doc.rust-lang.org/stable/reference/items/modules.html

・ルートファイルは慣習的に"main.rs"（実行用）、"lib.rs"（ライブラリ用）が使われる
　（Cargo.tomlのpathで指定可能）
　テスト実行用のルートファイルは見えないところで勝手に作成される

ルートファイルとかオプションを切り替えることで同じファイル群から
複数のクレート（ライブラリ、ツール、テスト、etc.）を出力できるのがパッケージかな
別に複数じゃなくてもいいけど

**デフォルトの名無しさん** · 2023/05/03(水) 14:43:03.53

>>907
unsafe 最強ですね判ります

**デフォルトの名無しさん** · 2023/05/03(水) 14:56:29.41

>>932
>どこか間違ってるかもしれない
こう思わせること自体が間違いだな
どんだけ複雑なんだよ

**デフォルトの名無しさん** · 2023/05/03(水) 15:09:24.50

>>932
ルートモジュールやクレートルートならわかるがルートファイルという言葉は初めて聞いた
公式のどこかに出てくる用語？

**デフォルトの名無しさん** · 2023/05/03(水) 15:25:37.38

なぜzennは嫌われてるの？
https://zenn.dev/newgyu/articles/3b4677b4086768

**デフォルトの名無しさん** · 2023/05/03(水) 15:26:33.96

>>934
Rustが複雑に見えるように枝葉末節を混ぜて説明してるだけだろ
単純にクレートという名の各々独立したライブラリ用クレートまたはプログラム用クレート(＝バイナリクレート)があるだけだ
モジュールも単純でクレートの内部の名前空間にすぎずファイルディレクトリ構造と一致(もしくはmod xxx {...}と内蔵)
パッケージは複数のプログラム用クレート(とおまけに一つのライブラリクレート)をまとめただけ
以上で終わり

**デフォルトの名無しさん** · 2023/05/03(水) 15:30:44.88

>>932
>・Rustのクレートは１つの仮想的なソースファイル（以下ルートファイル）から作られる
ふーん

>・ルートファイルは慣習的に"main.rs"（実行用）、"lib.rs"（ライブラリ用）が使われる
仮想的やなかったんかーいwww

**デフォルトの名無しさん** · 2023/05/03(水) 15:35:16.94

rustのモジュールの仕組みが分かりにくいから徐々に仕組みが変わったんじゃないの？

**デフォルトの名無しさん** · 2023/05/03(水) 15:42:15.30

>>935
「ルートファイル」は説明のために勝手に作った
モジュールとかクレートを説明するのに「ルートモジュールやクレートルート」は使いにくい

**デフォルトの名無しさん** · 2023/05/03(水) 15:43:07.18

>>939
モジュールは単純明快
クレート内部の名前空間にすぎない
ファイルディレクトリ構造と一致
クレートの外に対してその深い構造を見せたくないならpub use boo::foo::woo;とシンボリックリンク相当を張るだけ

**デフォルトの名無しさん** · 2023/05/03(水) 15:49:18.63

コアのstructをファイルごとに分ける場合が単純にわからない
他の言語は分けて書けば終わり
rustはそれがどうなるのかわからない

**デフォルトの名無しさん** · 2023/05/03(水) 15:50:38.86

traitなどもどのようなファイルに書いてどのように分割していくのかがわからない
モジュールなんだろうけど意味がわからない

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

trait　animalがファイルであって
struct dog
struct cat
を別ファイルにした場合どのように書くのが正解なのかがわからない
traitを何らかのモジュールにおいて別のモジュールでdog　catを実装するのか

もうそこから理解できない

**デフォルトの名無しさん** · 2023/05/03(水) 16:05:48.81

それとも別のクレートにおいてそれを利用するのが正しいのかそしたら同のように利用するのが正しいのかもわからない
パッケージクレートモジュールの設計がわからない
そこから何も進まない

**デフォルトの名無しさん** · 2023/05/03(水) 16:19:54.29

ファイルの分け方に正解はないと思う
pubじゃない要素（構造体フィールド等）にアクセスしたいかどうかが一つの指標になるけど
自分はとりあえずJavaみたいに１ファイルにつきpub型定義１つをベースにしてる（絶対ではない）

参考になるかは分からないけど
・モジュール内ではpubでない要素に相互にアクセスできる
・子モジュールは親モジュールのpubでない要素にアクセスできる
・親モジュールは子モジュールのpubでない要素にアクセスできない
が設計のヒントになるかな

Javaのデフォルト公開（パッケージ内アクセス）みたいなことがしたければ
同じクレート内でのみアクセスできるpub(crate)みたいな公開指定もある

**デフォルトの名無しさん** · 2023/05/03(水) 16:23:38.18

仮に自由にかけるとしてもベストプラクティス的なのがまだ育ってないのがRustの巨大な弱点だと思う

**デフォルトの名無しさん** · 2023/05/03(水) 16:30:32.53

さあどんどん識者は回答してくださいよ
rustの優位性を示してくださいな

**デフォルトの名無しさん** · 2023/05/03(水) 16:40:24.03

ファイルは別けるな
だな

**デフォルトの名無しさん** · 2023/05/03(水) 16:42:06.06

『Effective Rust』待ち
サイトはあるっぽいけど

>>948
識者は優位性とか興味ないだろ

**デフォルトの名無しさん** · 2023/05/03(水) 16:49:42.50

メカニズムがわからないという話かと思ってたが
プラクティスがわからないという話だったのか

**デフォルトの名無しさん** · 2023/05/03(水) 16:55:25.45

>>951
メカニズムがそもそもおかしい
それでベストプラクティスが必要になる

実際はこれという書き方のために仕組みができたはずなんだけどこれと言うものが見当たらず…
それで大勢が迷いながら試行錯誤しながら書いてる
おかしいことこの上ない

**デフォルトの名無しさん** · 2023/05/03(水) 17:03:04.61

そもそもモジュールに分ける必要も無いくらい小規模なだけなんじゃ？

**デフォルトの名無しさん** · 2023/05/03(水) 17:09:09.40

迷ったら分けないってのも一つの戦略だな
分けたくなったら分ければいい

**デフォルトの名無しさん** · 2023/05/03(水) 17:37:47.24

ファイルは変更のタイミングで分ければいいんじゃないか
AとBがあるとして、Aを変更するときに、Bも変更しがちなら同じファイル、
そうでないなら別のファイルてな具合にね

**デフォルトの名無しさん** · 2023/05/03(水) 17:43:35.45

>>944
モジュールの主目的は関数や型の論理的グループをまとめるためなので分け方にRust特有の事情は基本的にないよ

ファイルを別にしたら必ず別モジュールになるんだけどそれは理解してる？

**デフォルトの名無しさん** · 2023/05/03(水) 18:01:00.42

例えば>>927の動画だとルート含めて4つのモジュールに分割してる

auth_service(ルート)
auth_service::auth_util
auth_service::auth_util::models
auth_service::database

この分け方に正解はなくてアプリの用途や開発組織の事情でいろんな分け方になりうる
それはRust以外の他言語でも全く同じ

**デフォルトの名無しさん** · 2023/05/03(水) 18:02:29.01

Rustが言語レベルでデザインパターンを縛っているわけでもないんだから
言語レベルでのベストプラクティスとかあるわけもなし

**デフォルトの名無しさん** · 2023/05/03(水) 18:03:18.87

部分的に別クレートに分けるかどうかはRust特有の事情が絡んでくるけどクレート分割を考えるのはプロジェクトが大きくなってからで十分

**デフォルトの名無しさん** · 2023/05/03(水) 18:41:43.51

どうもRust勢の答えがずれてるね
ファイル分轄したいときは普通はどうしますかって問いにまともに答えていない

他の言語だと大体はファイル分轄しても同じ名前空間的なものにつっこめばそれでもう参照可能
rustは違うんだろう？
それが何でそうなったのかは考えたことがあるのかな？
それで何かコーディングするうえで有利だなと思ったことはあるのかな？
なんかもう回答のレベルが低い

**デフォルトの名無しさん** · 2023/05/03(水) 18:44:09.53

>>946
>自分はとりあえずJavaみたいに１ファイルにつきpub型定義１つをベースにしてる（絶対ではない）
RustのモジュールはJavaだとクラスよりパッケージに当たるものでは？

**デフォルトの名無しさん** · 2023/05/03(水) 18:45:33.01

他の言語やってた時は1クラス1ファイルでとか言ってたくせにrustに移動したら
大きなコード書くまで考えなくてもいいとか言い出すのは変だよ

こんなレベルの低い回答はないし答えなくてもいい
識者が答えればいいんだ

**デフォルトの名無しさん** · 2023/05/03(水) 18:48:42.23

イノベーター(マニアに近い)には「なぜか売れる」という現象がある。
熱狂的に支持する層が一部にはいる、ということは恐らく事実で悪いことではないが、
それはたまたまその人達のニーズに合っていただけであり、それだけで普及には
至らない。

**デフォルトの名無しさん** · 2023/05/03(水) 18:52:33.52

何か作って売るとき、この商品は競合品に比べると総合的に見て欠点が多くて
お勧めは出来ないんだけど、一部の人にはなぜか売れて、結構評判もいい、
ということがある。
それがRustではないか。

**デフォルトの名無しさん** · 2023/05/03(水) 19:00:10.90

個人的にC++よりRust使いたいけど、結局Windows App SDKなりCUDAなりがデフォルトでRustインターフェースを提供していないので、ハイパフォーマンス&ローレイテンシなデスクトップアプリ/ゲーム開発に使うのが大変で厳しいって話はもう数年間改善されてない

コミュニティ的にはWebview使う方向に行ってたりして方向性かみ合わないし

いやWin32とDirectX叩けるだろって言われたらそうなんだけど、そこから実用レベルまで個人で環境やライブラリを叩き上げるのは現実的ではないと思ってる

この辺の話はどうよ

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

rust使ってても1ファイルで完結するようなものしか作ってないのかな？
それとも一個モジュール作ってそこに全部入れて膨大なソースをスクロールさせてるのか？

**デフォルトの名無しさん** · 2023/05/03(水) 19:13:03.51

ファイルの分け方は言語論というより開発論だよな
この話は終わりでいいかと

**デフォルトの名無しさん** · 2023/05/03(水) 19:16:06.88

>>967
rustは言語仕様上簡単にファイル分轄はできませんで終わり？

**デフォルトの名無しさん** · 2023/05/03(水) 19:18:34.10

>>961
Rustのモジュールは階層化して親子関係を作れるからJavaのパッケージよりちょっと柔軟かな
必要ならもう１つ上の階層のモジュールをJavaのパッケージに対応させればいいし
自分がファイルを分けてるのは単純に編集しやすいから

**デフォルトの名無しさん** · 2023/05/03(水) 19:30:08.58

Rustでは実用上有意義なファイル分轄は難しいので1ファイルにしてくださいと言うことでいいのか？
それも特殊な例じゃなくて本当によくあるケースレベルで分割は難しいってこと？

**デフォルトの名無しさん** · 2023/05/03(水) 19:32:28.01

「Rustのここはおかしいんじゃないか」と言った時、「いやいや、それは現実的
には問題ない、それより○○が素晴らしいから何の問題もない」
という受け答えをよく目にするが、それはまさにその人の「ニーズ」に
たまたま合っている、ということであり、イノベーター理論が語るところ
であろう。イノベーターはあらゆることでマニアやオタク、ということではなく、
たまたま、その商品に対してだけはニーズに合っていた、と言われている。

**デフォルトの名無しさん** · 2023/05/03(水) 19:39:09.58

何かしらのフレームワーク使ってるならそこに分ける方針とかだいたい書いてんじゃねーの
そういうのが無いならご自由にどうぞ
別に分け方を間違えたからって困ることは無い

**デフォルトの名無しさん** · 2023/05/03(水) 20:14:37.30

それは言いがかりだ！Rustはすばらいぃいいいいと言う人が出て来ないんだけど
自分のような初級三軍質問者の愚問には答えられないんだろうか？

**デフォルトの名無しさん** · 2023/05/03(水) 21:54:10.72

プラクティスがわからないんじゃなくて
結局メカニズムがよく理解出来ませんって話みたいね

ファイルを分けたときに分けたファイルをどうやって使えばいいか分からないってことでいいのかな？

**デフォルトの名無しさん** · 2023/05/03(水) 23:29:24.40

>>960
Rustはファイル分割の自由度が高く簡単に分割することが可能
分割するか否かは自分やプロジェクトの方針次第
最初はmain.rs一つから始めて進行とともに分割していく方針でも構わない

名前空間としてはファイル名がそのままモジュール名となる
その同名ディレクトリを作ればその下のファイルがサブモジュールになる
いずれもmod foo;と書くだけで使えるようになる
あとはfoo::TypeNameやfoo::boo::func_nameで自由に使える
長くて面倒ならuse foo::boo::func_name;すればfunc_nameで使える

ただしモジュール側ではモジュール外で使えるようにpub宣言が必要
逆に言えばpub宣言しなければモジュール内にプライベートにできる
pub宣言はpub(crate)やpub(super)など公開範囲の制限も可能

以上がモジュール分割
その一部を複数のプロジェクトから使えるライブラリとして独立させたくなったらクレート分割
クレートは並列コンパイル単位にもなるので専属利用でも敢えてクレート分割することもある
他にも構文解析木を入出力とする手続きマクロを作るときも単独クレート化が必須

**デフォルトの名無しさん** · 2023/05/04(木) 00:00:52.77

>>975
そこに書かれてる内容がすべてならファイル分轄の自由度は低いよね
ファイル名がモジュール名になるんなら自由度は制限される
サブモジュールの位置もフォルダ内と限定されてる

**デフォルトの名無しさん** · 2023/05/04(木) 00:27:31.14

>>965
需要が無い
Webviewで十分

**デフォルトの名無しさん** · 2023/05/04(木) 00:31:42.11

>>976
Rustは自由度が高い
分割する時にはモジュール＝ファイルにすぎない
一部の言語のようにモジュールの意味や位置付けや使い方を限定していない

さらにコード上(＝ファイル上)はモジュールやサブモジュールにあっても公開位置付けは別にできる
例えばpub use foo::Foo;とすることでFooがfooの下にあるにも関わらず直上にあるものとして公開できる

つまりプログラミングするときは完全に自由にファイル分割やディレクトリ分割していくことが可能
それらを公開するときにその分割内部構造を見せたくないならば見せずに整理して公開することが可能
公開するときのモジュールの位置付けとコーディングするときのファイル分割の自由度それぞれが独立に存在できる

**デフォルトの名無しさん** · 2023/05/04(木) 07:51:33.36

新スレ、プレオープン
好きな資料勝手に貼ってくれ

マ板のスレも入れておいたから、適宜御贔屓に

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

**デフォルトの名無しさん** · 2023/05/04(木) 08:18:45.38

Javaとかはその当たり結構うるさいけど他の言語ってそもそもあまりそういうのうるさくないよな。JVM系の言語はJava文化圏の中にあったりクラスファイルの仕様が言語側のモジュールの粒度を規定してしまうけど、そういうのがない言語だとどういう分け方がベストかみんな試行錯誤している期間があったり、ベストプラクティスが結局ない状態になるよな。

俺から見るとGoとかは現代の言語としてはありえないぐらい無法なディレクトリ構成がまかり通ってると思うけど、ああいうのが性に合ってる人もいる。

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

>>978
＞　分割する時にはモジュール＝ファイルにすぎない

本当にこれだけなら非常に自由度が低いなあ…
他の言語知らないのか？

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

1ファイルが1モジュール限定なら1960～80年代の古代の言語じゃん
ファイルの冒頭でモジュール名やプロシージャー名を指定するあれ

**デフォルトの名無しさん** · 2023/05/04(木) 09:23:38.28

>>979
ありがとう

**デフォルトの名無しさん** · 2023/05/04(木) 09:28:14.17

>>981
その後に説明しているのに
説明を読まずに一部を切り取りするとは性格歪んでる

>>982
Rustはそんなことはなく自由度が高い
自由にファイル分割やディレクトリ分けをして全体を一つのモジュールとして見せることも可能
逆にファイル一つに複数のモジュールを定義することも可能

**デフォルトの名無しさん** · 2023/05/04(木) 12:05:42.79

自由度が高いからJavaのように何も考えなくてもファイル分割できる指針がなくて困ってるんでしょ

モジュール分割って疎結合高凝集になるようグルーピングしましょうという当たり前の話なんだけどたぶんやったことがないと難しいんだよ
だからどうモジュール分割すべきかなんて小難しいそうなことを考えなくてもファイルを分割できる指針を”ベストプラクティス”という名で求めてるんだと思う
モジュール分割が先にあってそれに合わせてファイル分割するのが本来の姿だから考え方が逆なんだけどね

**デフォルトの名無しさん** · 2023/05/04(木) 12:16:56.04

>>985
「公開されるモジュール仕様」に対して
「実際にプログラミングする際のファイルやディレクトリ構成」の自由度がどの程度かが焦点だろ
前者の「公開されるモジュール仕様」はプログラミング言語やその機能とは直接関係ない話でありこのスレでも対象外
後者の「実際にプログラミングする際のファイルやディレクトリ構成」の自由度が言語により異なってくる部分
Rustは最大限の自由度がある言語の一つ

**デフォルトの名無しさん** · 2023/05/04(木) 12:27:57.50

Javaも
クラス大きすぎるとダメだから分けろとか
クラス多すぎるとダメだからまとめろとかパッケージ分けろとか
パッケージまたぐと絡まるから変な分け方するなとか
それなりに悩みはあったと思う

ただC++でも似たような悩みはあるはずだからファイル分割の仕組みの違いで戸惑いがあるのかもしれない
C/C++はソース単位でコンパイルして最後にリンカでくっつけるけど
Rustは全体を分割された１つのソースの塊とみなして一気にコンパイルする感じだから
とりあえず部品から考えるボトムアップ的なアプローチの人は引っ掛かりそう

**デフォルトの名無しさん** · 2023/05/04(木) 12:34:51.67

私の頭がわるいんだろうけどファイル分割は他よりわかりにくかったわ

**デフォルトの名無しさん** · 2023/05/04(木) 12:47:28.68

>>987
どういう方針でモジュールを分けるかはプロジェクトの方針やライブラリの方針でしょう
その方針に対してプログラミング言語によってはモジュール分けやファイル分けやディレクトリ分けに何らかの制限があって方針が引き摺られてしまうかどうかが重要なところでしょう
Rustはそこに制限はないから方針が言語によって引き摺られることはないでしょう
仮にどんなにファイルを分けたとしてもRustではそれとは関係なく外に対して見せずに済みますから外向けと内部構造は互いに自由度があります

>>988
外に対してどう見せるかと内部をどう分けるかを別々に決められるようになっているからその区別する意識を持たないと迷う人が出るかもしれませんね

**デフォルトの名無しさん** · 2023/05/04(木) 13:05:47.30

>>986
Javaの1クラス/インターフェースで1ファイルという指針があれば自由度は低いけど考えなくて済むでしょ
Rustではstructの定義とimplをtraitの実装と同じモジュールに入れることもあればtraitを定義してるモジュールのほうにstructのtrait実装を含めることもある
そんなに自由だとどうしていいかわからないからもっとルール(ベストプラクティス)で縛って欲しいというのが最初の質問者の本音だと思うわけ
だとしたら君の返答は的外れじゃないかい？ってこと

**デフォルトの名無しさん** · 2023/05/04(木) 13:23:02.85

何でそんなつまらんことで議論してるのか分からんC/C++ユーザの俺

**デフォルトの名無しさん** · 2023/05/04(木) 13:27:53.50

バカだから

**デフォルトの名無しさん** · 2023/05/04(木) 13:42:19.29

モジュールの分け方なんてC/C++で完成されてると思うんだけども
後発の言語は何が便利になったのかね?

**デフォルトの名無しさん** · 2023/05/04(木) 13:56:22.33

Rustだと何かができなくて困る、ってことは何もない
Java方式でも他の方式でも何でも各自や所属先やプロジェクトの方針でやればいい
まともなプログラマーは標準ライブラリや有名クレートのソースを読むのでRustでの普通の流儀を分かっている
参考になるものが公開されているのに見ずに文句を言うバカは放置しとけ

**デフォルトの名無しさん** · 2023/05/04(木) 14:17:24.34

rustだけで見ていてはダメだな。
CとRustが混在するprojectを考えないと本当の用途は分からない

**デフォルトの名無しさん** · 2023/05/04(木) 14:18:33.91

リファレンス読む前に、概要を教わりたい派だから、ゆるい議論は役に立ってるよ
文句は言わないから

**デフォルトの名無しさん** · 2023/05/04(木) 14:43:36.62

>>993
完成してんのにC++20でも変更するのかよw

**デフォルトの名無しさん** · 2023/05/04(木) 14:46:43.50

>>997
モジュール化に関わる変更あったっけ?