Rust part9

**デフォルトの名無しさん** · 2020/08/23(日) 01:07:35.52

Mozilla発のRust言語のスレ

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

前スレ
Rust part8
https://mevius.5ch.net/test/read.cgi/tech/1579834072/

**デフォルトの名無しさん** · 2020/12/28(月) 12:53:26.99

>>510
>その他の議論については影響は限定的だし
ところがC/C++が担ってきた領域ではそれが大問題になることが多いので
RustはC/C++の代替には成りえない。

>議論の俎上には挙がっているし徐々に改善されていくでしょう
少子化も日本の経済衰退も非常に何十年間も議論の俎上に上がっている
のに改善されていく気配は全く無いことからも分かる様に、
そんなことは一般的には成り立たない。

**デフォルトの名無しさん** · 2020/12/28(月) 12:58:19.94

>>510
>rustでも生ポインタ使えばよいのでは
Rustのsafeモードでは生ポインタは使えないんだが。

**デフォルトの名無しさん** · 2020/12/28(月) 13:13:50.09

>>512
実際に安全ではないので unsafe なのはあたりまえだが。
C++ のように常に危険なほうが良いなら C++ を使ってろよ。

**デフォルトの名無しさん** · 2020/12/28(月) 13:15:56.66

>>513
Rustはメモリーマネジメントの仕様がちゃんと公開されて無いので
C++よりずっと危険。

**デフォルトの名無しさん** · 2020/12/28(月) 18:08:21.04

>実行速度が遅いがコンパイルが速い言語で書かれたプログラムは、
>実際には速く実行できるようになる。

最近この苦情よく聞くんだけどどんなもんなの
コンパイル時間のボトルネックなんて
考える時間に比べたらたいしたことなくない
何十分もかからんだろ

**デフォルトの名無しさん** · 2020/12/28(月) 18:22:47.18

お前が弄る小さいプログラムではそうなんだろうね。

**デフォルトの名無しさん** · 2020/12/28(月) 18:27:17.21

どんなん

**デフォルトの名無しさん** · 2020/12/28(月) 18:58:25.81

CIとかでめちゃくちゃ時間かかるのはRustの醍醐味

**デフォルトの名無しさん** · 2020/12/28(月) 19:03:06.03

>>515
今のRustコンパイラはコア数で良くスケールするので
開発用の32コアマシンなら快適だけど、古いノートPCだと辛い、みたいなことはあるな
Actixみたいに大量の依存関係を要求するやつ+しょぼいシングルコアなら数十分かかるかもね

**デフォルトの名無しさん** · 2020/12/28(月) 19:27:10.85

個人的にはクレート単体で遅いと思ったことはなくて、体感では数万行のコードでもgccより速いかな、という感じ
なので遅い要因はほぼ依存関係の多さだと思っている

C++とかだと特定のディストリビューションの特定のバージョンでコンパイルエラー、みたいな地獄のデバッグが待っているので、それを回避するコストとしては十分安いと思うけど

**デフォルトの名無しさん** · 2020/12/28(月) 22:08:45.00

今の方法だとまだ依存crateのコンパイル待ちになるのにスケールする？
>>518に尽きる

**デフォルトの名無しさん** · 2020/12/28(月) 22:37:04.04

>>521
もちろん完全に直列な依存関係はスケールしないよ
もしそういうクレートがあるなら分割すれば改善するかもしれないし
具体的に挙げて欲しい

**デフォルトの名無しさん** · 2020/12/29(火) 01:19:43.87

>>520
>個人的にはクレート単体で遅いと思ったことはなくて、体感では数万行のコードでもgccより速いかな、という感じ
C言語のコンパイル意が遅くなるのは、Win32のヘッダファイルの巨大さが原因
であることが多い。
それが50MB位有ったりして、ヘッダファイルだけで数万行から数10万行くらいあったりする。
そのパースが遅い。
なので、VC++では precompiled header を使っている。

**デフォルトの名無しさん** · 2020/12/29(火) 08:29:57.63

cとc++じゃコンパイル速度は桁違いだけどな。

**デフォルトの名無しさん** · 2020/12/29(火) 10:56:10.54

ライブラリの依存関係を自動で解決するエコシステムがあると
依存関係が巨大になりがちっていうのは
Haskell や JavaScript でもよく聞くけどな。

まあ自分でそのライブラリ群を書く手間、
既存のものを使うにしても導入の仕方を調べる手間に比べたら
多少の時間はかかっても自動でやってくれるほうがマシではあるし、
度を越したときは個別に改善するしか仕方がないんだろう。

**デフォルトの名無しさん** · 2020/12/29(火) 15:03:36.81

依存関係のコンパイルは初回しかやらないんだから多少遅くても気にはならない
CIの場合はtargetディレクトリキャッシュすれば良いし
rust-analyzerの起動時間がちょっと気になるくらい

**デフォルトの名無しさん** · 2020/12/29(火) 23:35:14.28

>>522
昔より増えたapiとimplを分離したクレートは

自分のプロジェクト->api->impl->implが依存するcrate(s)->...

と直列に依存してる。log,slog,serde,thiserror,webrender(etc.)
それに直列に依存するかどうかよりcargoもrustcのフロントエンドもまだ並列化対応が部分的でコンパイル単位の粒度が大きいのが並列ビルドの妨げになるでしょ。

>>526
CIはたしかにキャッシュが効けばいいけど、アナライザの話なら初回しかやらないことはないよ。
アナライザの場合は解析結果が無効になるたびに起きる。
intellij rustはプロジェクト開くたびにやってるし。
JDTみたいにon the fly analyzeするとソースコード変更するたびに解析するから依存グラフは使い回せても他は都度、解析する必要がある。

**デフォルトの名無しさん** · 2020/12/30(水) 00:32:35.13

>>527
言葉足らずですまん
(解析結果をメモリ上にしか持たない設計だから起動時に解析を全部やり直す)rust-analyzerの起動時間が気になるくらい(がコンパイル時間に関して気になる点)
と言いたかった

**デフォルトの名無しさん** · 2021/01/01(金) 09:10:16.97

#![feature(min_const_generics)]だけじゃなく#![feature(const_generics)]も2021に入って欲しいな

**デフォルトの名無しさん** · 2021/01/01(金) 12:06:39.72

全く話は変わるけど、メモリ不足で Box::new に失敗したら、panicが起きて
プログラムがそこで停止するだけ？

**デフォルトの名無しさん** · 2021/01/01(金) 12:08:13.77

>>530
仮にそうだとすると、Cのmalloc()やC++のnew TYPEに比べるとエラー処理は
省ける反面、エラー処理を書きたくてもかけないね。
まあ、滅多に起きないので書いてもしょうがないけれども。

**デフォルトの名無しさん** · 2021/01/01(金) 12:36:28.83

*C++
TYPE *ptr = new TYPE; //メモリ不足の場合ptrにはNULLが返される。
*Java
TYPE obj = new TYPE; //メモリ不足の場合例外がthrowされる。
*Rust
Box<T> obj = Box<T>::new(T()); //メモリ不足の場合panicが生じアプリがダウンする。

Rustは、高度な安全性を要する分野や組み込みでは困るかも。
それに記述が長い。

**デフォルトの名無しさん** · 2021/01/01(金) 12:40:33.89

C++のnewはメモリ不足のとき通常は例外が送出されるぞ
メモリ不足でnullptrを返すにはnew(nothrow)にしないといけない

**デフォルトの名無しさん** · 2021/01/01(金) 12:54:35.66

>>533
昔、
TYPE *ptr;
if ( (ptr = new TYPE) == NULL ) {
　printf( "Memory allocation erro has occured.\n" );
}
みたいに書いていたことがあるけど、これは昔のC++でも間違っていたのだろうか？

**デフォルトの名無しさん** · 2021/01/01(金) 12:57:46.63

Javaは、例外をthrowする関数を呼び出した場合、必ずtryブロックで囲むか、
または、呼び出しもとの関数の宣言の最後にthrow/throws属性をつけるかしないと
いけないんだけど、なぜかnew演算子の場合だけはこの規則の例外で、
tryブロックで囲むこともthrow/throws属性を付ける必要も無いらしい。
ただし、tryブロックで囲んでcatch文でOutOfMemoryErrorという例外を
捉えることは出来るらしい。
意外と良く考えられていて、便利そう。

**デフォルトの名無しさん** · 2021/01/01(金) 17:48:44.20

検査例外等も知らない人が言語仕様にケチつけるなよ

**デフォルトの名無しさん** · 2021/01/01(金) 18:19:22.53

知識が無くてもそれが使いにくいことが分かる人もいれば、
知識があってもそれが使いにくいことが分からない人もいる。
その差はイマジネーションや経験や頭の良さの差。

**デフォルトの名無しさん** · 2021/01/01(金) 19:06:09.23

知識も経験もイマジネーションも頭の良さもない
お前さんどうすんの？

**デフォルトの名無しさん** · 2021/01/01(金) 19:06:27.88

20年以上前？のC++だとNULLが返ってきてたみたいだな
C++98の頃には例外が投げられてる

**デフォルトの名無しさん** · 2021/01/01(金) 19:07:24.81

出た、”地頭”信者ｗ

**デフォルトの名無しさん** · 2021/01/01(金) 19:20:38.81

Rustのpanicはスレッド単位ですよ

**デフォルトの名無しさん** · 2021/01/01(金) 19:55:37.74

プラットフォームにもよるのでは
panic=abort
しかない環境もある

**デフォルトの名無しさん** · 2021/01/01(金) 22:11:27.78

かなり初歩的な質問で申し訳ないんだけど、例えばHashMapをイテレータで舐めてるときに内部でそのHashMapを更新したいときはどうするのがベストなの？
例えば次のようなケースではどうすれば……

https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=f6c554ab761450881f28e48faa55bf8c
use std::collections::HashMap;
fn main() {
let mut map: HashMap<_, _> = HashMap::new();
for i in -5..=5 {
map.insert(i, i);
}

for (key, value) in map.iter() {
if *value == 0 {
continue;
}
if let Some(another_value) = map.get_mut(&(-key)) {
// keyの絶対値が同じものを処理して、処理済みにする気持ち
*another_value = 0;
}
}
}

**デフォルトの名無しさん** · 2021/01/02(土) 00:25:45.81

>>543
map.iter() を map.iter().cloned().collect::<Vec<_>>() にする

**デフォルトの名無しさん** · 2021/01/02(土) 00:53:14.75

keyの絶対値が同じものでgroupingしてからイテレート

**デフォルトの名無しさん** · 2021/01/02(土) 02:08:00.06

rust的にはそういうことしないのがベストじゃない
俺だったらキーだけ取り出してループさせる

**デフォルトの名無しさん** · 2021/01/02(土) 09:20:56.29

>>544-546
ありがとう！
しかしRust的には褒められたやり方じゃないんだね
LL言語脳から切り替えないといけないなあ

**デフォルトの名無しさん** · 2021/01/02(土) 14:15:48.62

逆に-keyで絶対値にする言語とかあんの？
Rustではkey.abs()だぞ

> keyの絶対値が同じものでgroupingしてからイテレート
ソース見る限り元キーはそのままで{-1: 0, 1: 0}みたいにしたそうだからグルーピングでは絶対値にキー統一されるからダメだね

**デフォルトの名無しさん** · 2021/01/02(土) 15:20:56.88

>>543
イテレータを回してるときに内部でそのcollectionをいじくる一般的な方法を聞きたかっただけで、そのコードはただ説明のためのモックなのでコードの妥当性とかはどうか気にしないでください……

**デフォルトの名無しさん** · 2021/01/02(土) 16:10:45.39

これは個人的な解釈だけど、ループ中にコレクションをイジるのを許可すると要素の追加削除も許可されるので、動作が想定しにくいから言語に関わらずやるべきじゃないと思う

**デフォルトの名無しさん** · 2021/01/02(土) 17:40:37.90

有名なアルゴリズムでも破壊的に処理を進める物は少なくないから
それらをリソースを押さえたままより安全に実装するかという問題はある

**デフォルトの名無しさん** · 2021/01/02(土) 20:33:28.09

単純に破壊的操作とイテレータの組み合わせが良くないんだと思うけどね
基本的なアルゴリズムの実装でならC++でも大抵インデックスアクセスするし

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

絶対値で比較されるようなkeyの型を用意してBtreeMapにぶちこんでiter_mut()すれば
絶対値が同じキー同士は連続して現れるからうまいことやればやりたいことはできるのでは
コード複雑になりそうだけど

**デフォルトの名無しさん** · 2021/01/03(日) 02:42:58.53

>>550
C++狂い「安全性よりも論理的、数学的に正しいかが重要」

**デフォルトの名無しさん** · 2021/01/03(日) 15:16:13.09

Rustで大量の敵が同時に出現する2Dゲームを作ろうと考えています。
Amethyst、ggez、Bevyの中で最もおすすめのゲームエンジンはどれでしょうか？

**デフォルトの名無しさん** · 2021/01/03(日) 15:58:43.30

イニダン亡き後の移住先か…！

**デフォルトの名無しさん** · 2021/01/03(日) 17:51:55.22

スライムが5000匹現れた！

**デフォルトの名無しさん** · 2021/01/03(日) 20:23:57.03

>>552
まあ通常そういう場合はint値でモロにインデックスアクセスするわな。
これがrustとは全く馴染まない。

**デフォルトの名無しさん** · 2021/01/03(日) 21:45:20.19

single writer or multiple readerのモデルに沿うようなロジックに変換するか
interior mutabilityを使うかのどちらか

**デフォルトの名無しさん** · 2021/01/05(火) 22:41:10.79

>>555
個人的にはAmethyst。
なぜなら俺が個人的にECSアーキテクチャが大好きだから。
小さなプロジェクトに向かないとか言われるけど知らないそんなの。

**デフォルトの名無しさん** · 2021/01/05(火) 23:32:43.62

RustでTDみたいなブラウザゲー作った猛者おりゅ？

**デフォルトの名無しさん** · 2021/01/08(金) 08:35:58.68

なんでこんなゴミを100M単位でボコボコダウンロードせなならんのや

ゴミ

**デフォルトの名無しさん** · 2021/01/09(土) 00:36:27.01

>>562
それって回線がゴミなだけじゃ...

**デフォルトの名無しさん** · 2021/01/10(日) 12:11:15.45

評価順序のルールがよくわからないんですが、
タプル生成のときの呼出し順序って保証がありますか？
つまり

(foo(), bar())

みたいに書いたときに foo が常に先に呼ばれることは保証されますか？

**デフォルトの名無しさん** · 2021/01/10(日) 13:02:46.89

保証されてるんじゃない？
でも呼び出し順が重要なら行を分けて書いてからtupleに入れたほうがいいような気もする

The meaning of each kind of expression dictates several things:
・Whether or not to evaluate the sub-expressions when evaluating the expression
・The order in which to evaluate the sub-expressions
・How to combine the sub-expressions' values to obtain the value of the expression
https://doc.rust-lang.org/reference/expressions.html

**デフォルトの名無しさん** · 2021/01/10(日) 15:22:53.59

評価順序についてはもう少しわかりやすくリファレンスを更新する予定みたい
https://github.com/rust-lang/reference/blob/964dc5bab5f7418aea36233c271ceedaea216598/src/expressions.md#evaluation-order-of-operands
https://github.com/rust-lang/reference/pull/888/

**デフォルトの名無しさん** · 2021/01/10(日) 15:34:43.17

>>565-566
ありがとうございます。
無学なので少し書き方が分かりやすくなっても英語だとしんどい……。

**デフォルトの名無しさん** · 2021/01/11(月) 14:09:54.51

ファイル (またはネットワーク) から得られる所定の書式のレコードの繰り返しを
イテレータとして抽象化したいと考えました。
(ちなみにレコードの繰り返しの前にレコードの個数を含むヘッダもあります。)

しかし IO はエラーの可能性があります。
書式の仕様に違反する入力になっている可能性もあります。

イテレータが返す型を Option<Result<要素の型,エラーの型>> としてしまうと
エラーの時点で終端という扱いにならないので様々なメソッドと組み合わせ難いですし、
Result を挟まないとエラーの内容を返せないのでハンドリングしづらいです。

何か綺麗にやれるイディオムのようなものがあったりしませんか？

**デフォルトの名無しさん** · 2021/01/11(月) 15:21:23.54

エラーの時点で終端にするかどうかは呼び出し側が決めることじゃない？
Option<Result<T, E>>もResult<Option<T>, E>もイディオムとしてよく使われてる

**デフォルトの名無しさん** · 2021/01/11(月) 15:47:03.74

>>569
出来るか出来ないかで言えば出来るし好きにすれば良い話ではあるんですが、
標準で良いされている様々なメソッド (たとえば map のような基本的なメソッドさえ！)
と「組み合わせ難い」ということが綺麗じゃないなぁという気持ちなんですが、
そこらへんの不格好さは許容するしかない雰囲気ということでしょうか？

(通常の終端に到達するのとは別に) 中断を表現する方法があって
中断の理由を伝播するのに便利な語彙を詰め込んだクレートがあったりすると
助かるんですが。

**デフォルトの名無しさん** · 2021/01/11(月) 16:05:22.66

>>570
公式にあるイディオムっぽいのはこれとか。
https://doc.rust-lang.org/rust-by-example/error/iter_result.html

クレートは探すと色々見つかるけど、結局「便利な」ってのが人それぞれだし、あまり流行ってる感じはしないな。
むしろその中断表現をうまくやるアイデアがあるなら自分で作ったほうがいいのでは。

**デフォルトの名無しさん** · 2021/01/11(月) 16:41:17.67

>>570
組み合わせ難いと言ってる内容をコードで示してくれないとなんとも

**デフォルトの名無しさん** · 2021/01/11(月) 20:34:05.33

イテレータとして抽象化したいってどういう意味なの
Iteratorをimplするってことなのかしら

**デフォルトの名無しさん** · 2021/01/11(月) 23:06:51.09

>>573
ここでいう「イテレータとして」というのは std::iter::Iterator に限るわけではなく、
繰り返しを表現する何らかの型定義と思ってください。
適当なクレートがあるならそれでいいですし、考え方だけでもいいです。

欲しい機能をあらためてまとめると

・繰り返しに (終端に到達する以外の) 中断の方法が用意されている
・中断したときに中断の理由 (エラー型の値) を伝える方法がある

なのですが、
std::iter::Iterator だと next が返す Option<Result<T, E>> でエラーのときに
「中断」しようとすると for 文の中で break する書き方くらいしか思いつかず、
自分で便利なものを作ろうにもどう作れば便利になるのかも
想像がつかないのです。

**デフォルトの名無しさん** · 2021/01/12(火) 02:11:34.65

>>574
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=aaf882f54a7b6330ee6ad2106be92717
こんな感じでscan使えばNoneを返したところで
イテレーションを中断できるしErrの値も列挙できる

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

中断するだけなら take_while 使うという手もある

**デフォルトの名無しさん** · 2021/01/12(火) 08:20:11.60

俺もtake_whileを思い浮かべたけど関数を作るわけじゃないんでしょ
ゴールがいまいちみえないからイメージでいいのでコードで用件を示してほしい

**デフォルトの名無しさん** · 2021/01/12(火) 11:44:28.63

単にエラー返して中断したいだけならResultにcollectしたりtry_for_eachで消費すればいいよ
イテレータアダプターとしてエラーも含めて列挙しつつ次につなげたいなら>>575が書いてるscanやtake_while系
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=113dcf689b4d941c89e714ebb1414958

**デフォルトの名無しさん** · 2021/01/12(火) 20:39:12.01

AsRefトレイト使ってenumから&str返すのっておかしい？
Display実装で文字返してたらアロケートされるからAsRef使おうと思ってるんだけど

**デフォルトの名無しさん** · 2021/01/12(火) 20:51:33.48

Rustの利用状況調査、ビジネス利用が進む一方で習得の難しさなどが依然課題
https://www.atmarkit.co.jp/ait/articles/2101/12/news046.html

**デフォルトの名無しさん** · 2021/01/12(火) 21:41:00.77

>>579
AsRef に拘らず独立した as_str 用意した方が良いと思う

**デフォルトの名無しさん** · 2021/01/12(火) 22:42:54.02

AsPath が AsRef<Path> になった過去もあるから汎用性持たしてas_str実装するよりAsRefで実装する方がいいといいと思うけど他の人はどう思う？

**デフォルトの名無しさん** · 2021/01/12(火) 23:59:44.33

as_strに一票

**デフォルトの名無しさん** · 2021/01/13(水) 08:49:31.39

自分で使う、as_str
ライブラリとして他で使われる、AsRef

**デフォルトの名無しさん** · 2021/01/13(水) 09:22:05.24

>>580
学習難度はまず低級言語と高級言語両方の利点欠点を理解しないと良さが理解出来ないからねえ…
設計思想からして中上級者向けだから仕方ないかも

**デフォルトの名無しさん** · 2021/01/13(水) 10:55:46.25

単に学習難易度が高いだけでなく、学習が済んだ後もこの言語はめんどくさいが、
C++よりもむしろ。

**デフォルトの名無しさん** · 2021/01/13(水) 12:45:22.11

>>582
AsRefはIntoOwnedと対になっていて str<->String Path<->PathBuf みたいな ref/owned 関係にあるもの同士の変換に使うものだと思う
enum -> &str はそういう関係にはないので微妙に思う

**デフォルトの名無しさん** · 2021/01/13(水) 13:36:01.48

>>586
風俗で事が済んだ後で説教始めるオッサンみたい

**デフォルトの名無しさん** · 2021/01/13(水) 13:53:35.67

C++とRustで難しさめんどくささの方向性違うしな
好みの範疇だと思ってる

**デフォルトの名無しさん** · 2021/01/13(水) 21:18:34.66

Rustのめんどくさいところはダントツでクレート関係だよな
標準で入ってないかつ、細かすぎるからコンパイル糞長いし、APIの仕様が統一されてないからドキュメント見ないと話にならんとこ
しかもクレートによっちゃライフタイム絡ませてきてめちゃくちゃになるし
C++はとにかく言語仕様のいらない豊富さが嫌気さす

**デフォルトの名無しさん** · 2021/01/13(水) 21:41:40.93

D言語かDelphiやれ

**デフォルトの名無しさん** · 2021/01/13(水) 23:05:33.49

もう.net5とC#でいいやん

**デフォルトの名無しさん** · 2021/01/14(木) 01:15:26.66

>>590
traitのおかげで他と比べるとAPIの統一性は達成されてるようにおもう

**デフォルトの名無しさん** · 2021/01/14(木) 01:57:39.37

クレートいいと思うけどな
標準ライブラリに入れると破壊的変更できなくなるけどクレートなら古いバージョン使うことも出来るから
気兼ねなくライブラリを進化させることが出来る

**デフォルトの名無しさん** · 2021/01/14(木) 08:51:13.78

pure-Rustのクレートなら今のところ確実にコンパイルは通るしな。
C++だとGitHubから拾ってきたライブラリが手元でコンパイル通るかどうか半々って感じで厳しい。
マイナーなディストリビューションのせいではあるけど、全部Ubuntuに統一というわけにもいかんしなぁ。

**デフォルトの名無しさん** · 2021/01/15(金) 20:23:33.58

struct A;
struct A();
これとこれが定義できる理由ってなんかある?

struct A {};
だけで済むし、記述バラバラになるから統一したいんだけど

**デフォルトの名無しさん** · 2021/01/16(土) 00:28:37.68

Rustが一番めんどくさいのはメモリ管理だな。
というよりメモリ管理の事ばかり気にしてプログラムしなくてはならない。
plain CやC++ではそこまで気にしなくて良い。

**デフォルトの名無しさん** · 2021/01/16(土) 01:28:58.93

？？？？？？？？？

**デフォルトの名無しさん** · 2021/01/16(土) 11:40:00.74

いつものやつだ気にするな

**デフォルトの名無しさん** · 2021/01/16(土) 14:07:27.84

結局メモリを気にする言語にへんな暗黙性を入れるのは失敗ってことだな。

**デフォルトの名無しさん** · 2021/01/21(木) 02:51:30.26

Rust で書いたツールにドキュメントを付けようとしています。
ライブラリのドキュメントではなくツールとしての使い方の詳細で、
readme に書くには大きすぎるような文章です。

cargo.toml では package.documentation でドキュメントの場所を URL で
示すことは出来るようですが、パッケージ内にドキュメントを一緒に入れておいて
cargo install で適当なところにインストールするようなことは出来ないのでしょうか？

あるいは cargo の直接の管理下には入れられないにしても
なんらかの習慣があったりしますか？

**デフォルトの名無しさん** · 2021/01/21(木) 07:00:10.04

ゴミ言語

**デフォルトの名無しさん** · 2021/01/21(木) 14:31:58.28

manみたいにドキュメントインストールする方法は知らないな。
ローカルにインストールしなくてもリポジトリのwikiあたりに使い方書いておいてそれ見てねでいいんじゃないかとおもうけど。

**デフォルトの名無しさん** · 2021/01/21(木) 21:40:35.33

ビルドスクリプト使ってenv::var("OUT_DIR”)で取得できるパスにファイル出力してるのが多いみたい

**601** · 2021/01/21(木) 22:18:23.22

なるほど。そういうやり方もあるんですね。
でもドキュメントを各環境で適切な場所に
インストールするのは結局は手作業ということになりそうですね。

そういうことなら無理に自動化するのは諦めて
必要ならこのディレクトリで mdbook コマンドを実行してねみたいな感じにした方がかえって楽かな……

**デフォルトの名無しさん** · 2021/01/21(木) 22:42:45.36

cargo installでrustバイナリ以外をインストールするオフィシャルの方法は長年用意されてないから別の手段で頑張るしかない
https://github.com/rust-lang/cargo/issues/2729

**デフォルトの名無しさん** · 2021/01/24(日) 00:35:05.68

fn num() -> usize {
10.pow(9)
}
この定数はなぜ推論でusizeにならないんですか？

**デフォルトの名無しさん** · 2021/01/24(日) 19:33:54.83

もういい加減にしてクレート

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

なんでいちいちゴミをワサワサDLしなきゃならねーんだよゴミ言語

**デフォルトの名無しさん** · 2021/02/03(水) 21:58:38.43

どしたのわさわさ