2020年12月26日から2020年12月31日 のRustの勉強記録

TRPL pp. 324-347

13.5

ループとイテレータをパフォーマンスの比較をする

イテレータは、

• 高度な抽象化に関わらず、低レベルなコードを地震で書いているかのように、ほぼ同じコードにコンパイルされる
  • ループを展開し、ループ制御コードのオーバーヘッドを除去し、代わりにループの繰り返しごとに同じコードを作成
  • ゼロコスト抽象
    • 抽象化を使うことが追加の実行時オーバーヘッドを産まないことを意味する
    • C++ のゼロオーバーヘッドと類似

13.6

低レベルのパフォーマンスで、高レベルの考えを明確に表現するというRustの能力に貢献

14

Cargoの色々な機能

14.1

リリースプロファイルでビルドをカスタマイズする。

• dev プロファイル
  • cargo buildで利用される
  • 開発中に役立つデフォルト設定がされている
• release プロファイル
  • cargo build --relaseで利用される
  • リリース用の設定がなされてりう

Cargo.tomlファイルに[profile.*]セクションを追加することでデフォルト設定の一部を上書きする

e.g., opt-levelは最適化の度合いで0(dev)から3(release)まで

14.2

Crates.ioにクレートを公開する

14.2.1

ドキュメンテーションコメント

• 三連スラッシュ(///)で始める。
  • コードコメントは二連スラッシュ(//)
  • Markdown記法もサポート
• 他のユーザーがパッケージについて理解する手助けになるから書くことに時間を費やす価値はある
• cargo docを実行することでHTML Documentを生成できる
  • target/docディレクトリに配置される

14.2.1.1

よく使われるセクション

• Examples
  • 例
• Panics
  • panic!する可能性のある筋書
• Errors
  • 関数がResultを返すなら、
    • 起きうるエラーの種類と
    • どんな条件がそれらのエラーを引き起こすか
  • の解説をするかしょ
• Safety
  • 関数が呼び出すのにunsafeなら、その理由の説明と期待する不変条件を記述

14.2.1.2

ドキュメンテーションコメントにコードブロックを追加すると、cargo testでドキュメントのコード例をテストとして実行する。 動かない例がついているよりも悪いものはない。

• ///
  • コメントに続く要素にドキュメンテーションを付け加える
• //!
  • コメントを含む要素にドキュメンテーションを付け加える
  • クレートやモジュール全体にドキュメントを付ける
  • クレートの目的や体系を説明するのに有用
  • //!で始まる最後の行のあとにコードを入れない

14.2.2

• modで体系化
• pubで公開
• useでスコープに導入

これらは開発する自分にとって意味ある構造であり、使用者よりも開発者に関係すること

ユーザーにとってはそうではない。 使用者にとって役立つ構造を含んでいないし、use文で指定するのは不便。

再構築する必要なしに、要素を再エクスポートし、自分の非公開構造とは異なる公開構造にできる。 もちろん内部構造を見て使用することもできる。 これはクレートの使用経験に大きな違いを生む。

14.2.3

クレートを公開するためにやること

• crates.ioにアカウントを登録
• APIキーを発行
• cargo login
• cargo publish

14.2.4

• Cargo.tomlファイルの[package]セクションに
  • 名前(name)を追加
    • 名前はcrates.ioで早い者勝ち
  • ライセンス(license)にライセンス識別子を
    • SPDEのもの
    • それ以外はファイルを配置せよ
  • 説明文
  • authors　
  • version
    • セマンティックバージョンルールを使用して公開

14.2.5, 14.2.6

crates.ioに公開したら永久にアーカイブされる。決して削除されない。

crates.ioの1つの主な目標が、crates.ioのクレートに依存している全てのプロジェクトのビルドが動き続けるようにすること

yank(取り下げ)はできる。それのundoもできる。取り下げると新規のプロジェクトは新たに依存できない。既存のは使い続けられる。

14.3

ライブラリクレートが肥大化したら、服須のライブラリクレートに分割したくなる。

ワークスペース:

• 関連のある複数のパッケージを管理するのに役立つ
• 同じCargo.lockと同じ出力ディレクトリを共有する一連のパッケージ
  • 最上位にtargetのディレクトリがあり、下位のにはtargetディレクトリがない
  • なぜなら、ワークスペースのクレートは互いに依存しあうことを意味する

やり方:

1. ワークスペース用の新しいディレクトリを追加する。
2. ワークスペース全体を設定するCargo.tomlファイルを作成する
   1. [workspace]セクションから開始
   2. members = ["xxx", ...]
3. そのディレクトリ内でcargo newを実行し、クレートを追加する
4. cargo buildを走らせるとワークスペースを構築できる

14.3.2

メンバクレートの追加とその使用

• メンバクレートを作成
  • membersリストで新たなパスを追加
  • その名前のライブラリクレートを作成
• メンバクレート間での依存を記述
  • 一方のメンバクレートのCargo.tomlにそれへのパス依存を追加する
    • Cargoはワークスペースのクレートがお互いに依存しているとは想定していないので、クレート間の依存関係について明示する必要がある
• メンバクレートの関数を使用する
  • extern crate行を追加してスコープを導入
• cargo build
• 最上位のディレクトリからバイナリを実行する方法は、cargo run -p (パッケージ名)

メンバクレートのパス依存を追加する方法

[dependencies]
yy = {path = "../yy"}

14.3.2.1

• ワークスペースの最上位階層にただ1つのCargo.lock
• 全クレートが全依存の同じバージョンを使用する
  • スペースの節約
  • ワークスペースのクレートが相互に互換性を維持する

それぞれのクレートのCargo.tomlファイルに外部クレートを追加する

buildすると最上位のCargo.lockに、それに対する依存の情報を含むようになる

最上位のCargo.lockにその外部クレートが存在しても それぞれのクレートのCargo.tomlファイルにもそれが存在しない限り、その外部クレートを使用することはできない。 これで、明示的に依存していることを示す。

14.3.2.2

個別のクレートにテストを追加する

ワークスペースの最上位のディレクトリで、

• cargo testを実行するとワークスペースの全クレートのテストを実行する
• -pフラグを使用し、テストしたいクレータオの名前を指定することで最上位ディレクトリから、ワークスペースのある特定のクレート用のテストを実行することができる

ワークスペースのクレートの公開は個別にそれぞれの各クレートを公開しなければならない

ワークスペースの利用の利点:

• 個別のコンポーネントの方が理解しやすい
• 変更されることが多いなら、クレートを保持することは、強調しやすくすることにもつながる

14.4

cargo installで、crates.ioから

• バイナリクレートを
  • バイナリターゲット(単独で実行可能なプログラム)を持つパッケージのみインストールできる
• ローカルにインストールし
  • binフォルダに保持される
• 使用することができる
  • 実行できるようにするためには、そのディレクトリが$PATHに含まれている

14.5

$PATHにあるバイナリが、 cargo-somethingという名前なら、 cargo somethingとサブコマンドであるかのように実行できるように拡張することができる

cargo installと拡張しやすさ、これら2つの組み合わせはCargoの設計上の非常に便利な恩恵