結局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(火) 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++はいいぞ

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

>>833
プロダクトライフサイクルにおける顧客割合の意味を理解してたらそんなアホみたいな比較はしない

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

>>860
このレベルの理解力しかない複オジがRustを推すからバカにされるんだよな
いい言語なのに

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

>>860
何で継承を廃止したのかな?
新たなパラダイムを採用するにしても
継承を残しとけばC++ユーザの取り込みが進んだだろうに

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

>>867
じゃあ、Rustのプロダクトライフサイクルにおいて、分母は何で分子は何なのさ？

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

>>869
C++ユーザーは取り込めないし、取り込む気もないのでは

C++より優れているという宣伝文句は、主にスクリプト言語を使っている人の心をくすぐるのだと思う

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

>>870
自分で考えなよ
顧客タイプ別の割合を足せば100%になるんだからちょっと考えればわかるでしょ

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

>>869
何でか説明してるレスに何でか聞くのってヤバいと思う

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

そもそもRustはC++に比肩しうるような性能を持たない

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

>>873
説明がサッパリ分からん

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

#[derive]は継承とどう違うの？

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

DEVICE=A:\DOS\HIMEM.SYS

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

JavascriptやTypeScript関係の基盤やツールはRust製がかなり増えたね

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

主にJS使いがRustを使ってるからね

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

>>874
上手に書けば似たようなもんだろうから、性能はそんなに争わなくていいぞ
ヘタクソが使ったら性能出ない、じゃどっちもどっちｗ

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

>>869
Rustと関係なく昔からOOPでは
継承(is-a)より合成(has-a)が望ましい
という話を聞いたことがない？
合成(has-a)の方が柔軟性が高いだけでなく
各機能ごとにコードを分けられるため
可読性も上がり保守性も良くなる
菱形多重継承の問題も避けられる
巨大な親クラスを用意する必要もなくなる

別の見方をすると
継承は複数の役割を混ぜて詰め込んでいる
コードの共通化や多層性など別々の役割が混在してる
それが上述の継承の様々な問題を引き起こしている
それぞれの役割が個別に提供されたら継承は不要となる
そして問題はなくなり可読性も保守性も向上する

以上の話はRust以前から言われてきた話
そしてGoもRustも当然のように継承は廃止した
まともなプログラマーなら継承は複数の役割が混在してることに気付いてる
だから継承がない言語でもそれぞれの役割ごとにプログラミングすることができる
一部のダメなプログラマーを除いて継承がない言語で困ることはない
コードの可読性や保守性が上がったことで継承廃止に納得賛成する

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

>>872
分かりませんので教えていただければ幸いです。
Rustにおける100%になるような顧客の集合(分母)とは何に当りますか。

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

>>881
新たなパラダイムを採用するにしても
継承を残しとけばC++ユーザの（Javaとかもかな?）取り込みが
もっと進んだのではないのかな?
本当に良いパラダイムであるのなら継承を残したままC++が呑み込むと思うよ

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

>>876
#[derive]は継承ではない
継承とは複数の役割を混在させた汚い概念
その説明については>>881を読んでほしい

#[derive]自体は手続き型マクロによる機能の付加
だから何を付加するかそのマクロ実装によって機能は変わる
トレイトを自動実装させるものもあれば
トレイトは出て来ず無関係にその対象にメソッドを生やすことも可能
マクロといってもRustコードの構文解析木を入出力とできるため高機能

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

継承といってすぐ思いつくのは、COMのIFoo2:IFoo みたいなときだけど、Rustでもできないわけじゃないでしょ

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

>>873
説明できてるつもりなのがマジでヤバいな
トレードオフを理解出来ないやつは適性ないから早めに辞めたほうが本人のためにも世の中のためにも良い

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

crate hoge を使うとき
extern crate hoge; する人と
use hoge; する人がいるけど
どっちがどう違うん？

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

ちな、C++は継承全盛の時代にクソの山が築かれたので、その反省から、継承はナシでいくって発想はそんな違和感ない
現役のC++erは、そのクソの山をくぐってる(新参も過去資産を読まされるからね)から、継承するにしても注意深く設計する
だから、あんま反論する気はないからね

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

>>883
継承はコードの可読性や保守性を下げるだけの存在なので不要
継承は複数の役割が混在した汚い存在
それぞれの役割を分離して実現できる方がまともなプログラマーとってうれしい

>>885
複数の役割が混在した継承という言葉や概念を用いるのはよくない
そのような汚い継承というものはRustに存在しない
もちろんそれぞれの役割の実現方法は別々の方法としてRustにある

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

>>856
C/C++もRustもどっちでも良いけど
Rustはアルゴリズムで悩むよりコンパイル通すことに悩む時間の方が長くなると感じる
まだ慣れてないだけかも知れないのは認めるが
アルゴリズムを実装したいのに集中力を削がれる

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

>>858 >>860
traitは便利だけどC#のpartialに似てる部分もあって
実装があっちのファイルこっちのファイルに分散してて
管理出来てないとどこに何があるのか判らなくなる傾向はあると思う
C/C++はヘッダーさえ追いかければどこに何が定義されているか見付け易いが
Rustは時々えっこんなのここで定義してあったんだみたいな発見があるし
気付かないで再発明してから後になってえっ既にあったの？ってなるときがある

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

>>889
伝わってねえ
継承時代のインタフェースってのがあるんだよ特にWindowsにはね
MSが全面採用って言ったんだから、できないはずないんだって

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

>>890
それは単に慣れていないだけだよ
Lispを始めた時も最初は手続き型言語以外に慣れなくて似たような感じだった
Prologの時も宣言型言語の発想の転換に慣れるまでそんな感じだった
狭い範囲の言語しかやって来てないとその感じを初体験かもしれないね
いずれも最初のうち慣れるまでを乗り越える

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

>>881
>Rustと関係なく昔からOOPでは
継承(is-a)より合成(has-a)が望ましい
という話を聞いたことがない？
合成(has-a)の方が柔軟性が高いだけでなく
各機能ごとにコードを分けられるため
可読性も上がり保守性も良くなる
菱形多重継承の問題も避けられる
巨大な親クラスを用意する必要もなくなる

↑ここはNimもうまくやってると思うが
規模が大きくなると型推論とかmatchで時間かかりそう

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

>>892
申し訳ないがWindows特有の話には一切関心かない
そしてそれはプログラミング言語の話でもない
マイクロソフトがRustについても大量のドキュメントとライブラリ提供している
それらを見ればよいのではないか

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

>>887
extern crateはちょっと古い書き方（今でも用途ゼロではない）

rustコンパイラが外部のクレートを参照するためには
ソース内でextern crateを指定するかrustcに--externオプションで渡す必要があるんだけど
今はcargoがdependenciesの中身を全部渡してくれるからextern crateの出番は減ってる

今でも外側からのテストコードでdependenciesに含まれてない自分のクレートを参照する時は
extern crate [テスト対象のクレート名];
みたいに使われたりする

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

>>893
LispもErlangも慣れてるんだけどな
Rustには別の面倒くさがある
(難しいとは言っていない)

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

>>889
>継承(is-a)より合成(has-a)が望ましい
使う場所が違うんでないの?
composition（has-a）を使うべきところで
継承で設計するので破綻すのではないかな?

所有権システムの話と違って
継承は合成と両立できるのなら
排除する必要はなかったと思うんだよね

**デフォルトの名無しさん** · 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

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