Zenn
Open12

Rust

Rust
tetsu_kobatetsu_koba

extern crate  は昔は必要だったが、2018 edition 以降は不要になった。

tetsu_kobatetsu_koba

実行時に決まるサイズでバッファを確保する場合、
let mut buffer = vec![0; size];
とすればよい。要素の型は後続するコードから推測してくれる。
特に後で拡張する予定がなくても、カジュアルにVectorを使えばいいようだ。
これは実体はヒープ上に確保され、ローカル変数のbufferの変数はその参照を保持している。ローカル変数のスコープから外れれば、自動でヒープは解放される。

https://chat.openai.com/share/d68c6f05-799d-4b93-8e0c-4b13df77d89a

tetsu_kobatetsu_koba

use crate::Result;
は、現在のクレートのルートに定義されているか、またはルートからアクセス可能な Result という名前のアイテムを指します。

tetsu_kobatetsu_koba

APIドキュメントの中に Result と書いてあっても、実際にそれが何なのかはソースコードを見て確かめる必要があるということでしょうか

はい、正確にはその通りです。

APIドキュメントに Result と書かれている場合、それは通常、std::result::Result を指すと期待されます。しかし、Rustでは型やトレイトなどの名前を再エクスポートしたり、新しい名前でエイリアスとして定義したりすることが許されています。そのため、特定のコンテキストで Result が何を指すのかは必ずしも明確ではありません。

例えば、上記で触れた nix::Result や、あるクレート内で定義されたカスタム Result 型など、様々な場面で Result という名前が使用されることがあります。

ドキュメントがよく書かれている場合、Result の型のエイリアスや再エクスポートの定義に関するリンクや説明が含まれていることが多いです。しかし、もしその情報が不足している場合や、確実に知りたい場合は、ソースコードを参照するのが最も確実な方法です。

このような曖昧さを避けるため、APIドキュメントを作成する際には、特定の名前が何を指しているのかを明確に示すよう心がけることが重要です。

tetsu_kobatetsu_koba

libc と nix のクレートの比較

libc と nix はどちらも Rust で Unix ライクなシステムコールにアクセスするためのクレートです。これらのクレートを比較してどちらが "better" かを評価するには、具体的なコンテキストや使用ケースに応じていくつかの要因を考慮する必要があります。

  1. 安全性:

    • libc: このクレートは主に生のシステムコールや C ライブラリ関数への結合を提供しており、多くの場合、これらの関数を安全に使うために unsafe ブロックが必要です。
    • nix: このクレートは Rust の抽象化を使用して、多くのシステムコールをより "Rusty" で安全に使えるようにラップしています。そのため、しばしば unsafe を明示的に使用する必要はありません。

  2. 抽象化レベル:

    • libc: より低レベルな API を提供しています。
    • nix: より高レベルの Rust イディオムを用いた API を提供しています。

  3. ポータビリティ:

    • 両方のクレートは異なる Unix ライクなプラットフォームに対してサポートを提供していますが、特定のプラットフォームに固有の機能を利用したい場合、どちらのクレートがより適切にその機能をサポートしているか確認する必要があります。

  4. 依存関係:

    • nix は内部で libc に依存していますが、逆はありません。

結論:
もし、安全性が優先され、Rust のイディオムを尊重したコードを書きたいのであれば、nix の使用が推奨されることが多いです。一方で、特定の低レベルのシステムコールや C ライブラリ関数を直接使用する場面や、最小限の依存関係を保ちたい場合は libc の使用が適切でしょう。

https://chat.openai.com/share/00c10996-b847-46aa-9c9d-9e6717773f4d

tetsu_kobatetsu_koba

Cargoのパッケージ名に-（ハイフン）を使用することは可能ですが、Rustのモジュールやクレート名には-を使用することはできません。Rustのクレート名では、-は_（アンダースコア）に自動的に変換されます。

したがって、Cargo.tomlでのパッケージ名がlibivf-rsの場合、クレートをインポートする際はlibivf_rsとして参照する必要があります。

tetsu_kobatetsu_koba

受け取ったResult<Self, Box<dyn Error>> からstd::io::Error を取り出すにはどうすればできますか?

Result<Self, Box<dyn Error>>からstd::io::Errorを取り出すために、downcastメソッドを使用できます。これにより、Box<dyn Error>を具体的なエラータイプへとキャストダウンできます。

以下は、Resultからstd::io::Errorを取り出す基本的な例です：

use std::error::Error;
use std::io;

fn main() {
    let result: Result<(), Box<dyn Error>> = Err(Box::new(io::Error::new(io::ErrorKind::NotFound, "File not found")));

    match &result {
        Err(e) => {
            if let Some(io_err) = e.downcast_ref::<io::Error>() {
                println!("This is an io::Error: {:?}", io_err);
            } else {
                println!("This is some other kind of error: {:?}", e);
            }
        }
        _ => println!("No error"),
    }
}

上記の例では、downcast_refを使用して、エラーがio::Errorであるかどうかを確認しています。io::Errorの場合、それに対して操作を行うことができます。

このようにして、エラーが特定のタイプであるかどうかをチェックし、それに応じて異なる処理を行うことができます。

tetsu_kobatetsu_koba

自分のgitリポジトリのクレートの更新。

Cargo.tomlに以下のように書かれているとき

[dependencies]
libivf-rs = { git = "https://github.com/tetsu-koba/libivf-rs.git"}

実際のgitのhashはCargo.lockに保持されている。

[[package]]
name = "libivf-rs"
version = "0.1.0"
source = "git+https://github.com/tetsu-koba/libivf-rs.git#c548166c1b672d7c8b9b4f8ce91d5bbd3a6e018a"
dependencies = [
 "byteorder",
]

libivf-rs.gitを更新したときには、Cargo.lock を削除してからcargo build する