Skip to content

Reading Record #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
iterable-company opened this issue Jul 4, 2022 · 39 comments
Open

Reading Record #1

iterable-company opened this issue Jul 4, 2022 · 39 comments

Comments

@iterable-company
Copy link
Owner

No description provided.

@iterable-company
Copy link
Owner Author

10.2から

@iterable-company
Copy link
Owner Author

10.3から

@iterable-company
Copy link
Owner Author

10.3 「ライフタイム省略」から

@iterable-company
Copy link
Owner Author

11.から

@iterable-company
Copy link
Owner Author

11.3から

@iterable-company
Copy link
Owner Author

12から

@iterable-company
Copy link
Owner Author

12.3から

@iterable-company
Copy link
Owner Author

12.4から

@iterable-company
Copy link
Owner Author

12.5から

@iterable-company
Copy link
Owner Author

13から

@iterable-company
Copy link
Owner Author

iterable-company commented Oct 31, 2022

13.2から

@iterable-company
Copy link
Owner Author

13.3から

@iterable-company
Copy link
Owner Author

13.4から

@iterable-company
Copy link
Owner Author

14から

@iterable-company
Copy link
Owner Author

14.2から

@iterable-company
Copy link
Owner Author

iterable-company commented Nov 27, 2022

14.3から

14.3の学習結果:
workspace ディレクトリに格納

@iterable-company
Copy link
Owner Author

iterable-company commented Dec 13, 2022

14.4から

14.4の学習結果:
#2 (comment)

@iterable-company
Copy link
Owner Author

iterable-company commented Dec 13, 2022

14.5から

14.5の学習結果:
cargo --listでcargo で実行可能なコマンドがみれる。
cargo install で入れたものもある

@iterable-company
Copy link
Owner Author

15章から

@iterable-company
Copy link
Owner Author

15.1から

@iterable-company
Copy link
Owner Author

15.2から

@iterable-company
Copy link
Owner Author

15.3から

@iterable-company
Copy link
Owner Author

15.4から

@iterable-company
Copy link
Owner Author

15.5から

@iterable-company
Copy link
Owner Author

15.6から

@iterable-company
Copy link
Owner Author

iterable-company commented Dec 22, 2022

16から
参考情報: https://doc.rust-jp.rs/rust-nomicon-ja/index.html

所有権と型システムはメモリ安全性と並行性問題を管理するのに役立つ。

  • スレッドを生成して、複数のコードを同時に走らせる方法
  • チャンネルがスレッド間でメッセージを送るメッセージ受け渡し並行性
  • 複数のスレッドが何らかのデータにアクセスする状態共有並行性
  • 標準ライブラリが提供する型だけでなく、ユーザが定義した型に対してもRustの並行性の安全保証を拡張するSyncとSendトレイト

@iterable-company
Copy link
Owner Author

iterable-company commented Dec 30, 2022

16.1から

Rustの標準は、OSスレッドと言語スレッドが1:1のみをサポートする。
これが M:N となっているグリーンスレッドではない。

@iterable-company
Copy link
Owner Author

16.2から

「転送機と受信機のどちらかがドロップされると、 チャンネルは閉じられたと言います。」

@iterable-company
Copy link
Owner Author

iterable-company commented Jan 2, 2023

16.3から

use std::rc::Rc;
use std::sync::Mutex;
use std::thread;

fn main() {
    let counter = Rc::new(Mutex::new(0));
    let mut handles = vec![];

    for _ in 0..10 {
        let counter = Rc::clone(&counter);
        let handle = thread::spawn(move || {
            let mut num = counter.lock().unwrap();

            *num += 1;
        });
        handles.push(handle);
    }

    for handle in handles {
        handle.join().unwrap();
    }

    println!("Result: {}", *counter.lock().unwrap());
}

Rcはスレッド間で共有するのには安全でないため、エラーとなる。

- Rc<T>が参照カウントを管理する際、 cloneが呼び出されるたびにカウントを追加し、クローンがドロップされるたびにカウントを差し引きます。 
- しかし、並行基本型を使用してカウントの変更が別のスレッドに妨害されないことを確認していないのです。 
- これは間違ったカウントにつながる可能性があり、今度はメモリリークや、使用し終わる前に値がドロップされることにつながる可能性のある潜在的なバグです。 
- 必要なのは、いかにもRc<T>のようだけれども、参照カウントへの変更をスレッドセーフに行うものです

@iterable-company
Copy link
Owner Author

16.4から

Sendマーカートレイト => Sendを実装した型の所有権をスレッド間で転送できる。
Rustの型のほとんどはSendだが、Rcは違う。
Sendの型から構成される型もSendになる

Sync

@iterable-company
Copy link
Owner Author

iterable-company commented Jan 3, 2023

17から

17.1

trait のデフォルトメソッドをそのtraitを実装する型が利用できる点が、子が親の実装を利用できる点において継承に似ている。
親の型と同じ箇所で子の型を利用できる多相性がある。

@iterable-company
Copy link
Owner Author

17.2から

17.2

pub struct Screen<T: Draw> {
    pub components: Vec<T>,
}

impl<T> Screen<T>
    where T: Draw {
    pub fn run(&self) {
        for component in self.components.iter() {
            component.draw();
        }
    }
}

のようなジェネリックな型とトレイト境界を使用する実装では、Drawの型が同種のものしか取れなくない。

トレイトオブジェクトはダイナミックディスパッチ。実行時に具体的にどのコードを呼び出すかが決まる。
ダイナミックディスパッチの場合、コンパイラは、どのメソッドを呼び出すか実行時に弾き出すコードを生成します。
スタティックディスパッチでは行われないこの検索が起きる時には、 実行時コストがあります。
ダイナミックディスパッチは、コンパイラがメソッドのコードをインライン化することも妨げ、 そのため、ある種の最適化が不可能になります。

トレイトオブジェクトに必要なオブジェクト安全性

  • 戻り値の型がSelfでない。
  • ジェネリックな型引数がない。
pub trait Clone {
    fn clone(&self) -> Self;
}

pub struct Screen {
    pub components: Vec<Box<Clone>>,
}

Selfを返しているので、エラーになる。
以下のコンパイラに関する知識が不足しているため、具体的にどうダメなのかがわからない。

Selfキーワードは、トレイトやメソッドを実装しようとしている型の別名です。
トレイトオブジェクトは、 一旦、トレイトオブジェクトを使用したら、コンパイラにはそのトレイトを実装している具体的な型を知りようがないので、 オブジェクト安全でなければなりません。
トレイトメソッドが具体的なSelf型を返すのに、 トレイトオブジェクトがSelfの具体的な型を忘れてしまったら、メソッドが元の具体的な型を使用できる手段はなくなってしまいます。
 同じことがトレイトを使用する時に具体的な型引数で埋められるジェネリックな型引数に対しても言えます: 具体的な型がトレイトを実装する型の一部になるのです。
トレイトオブジェクトの使用を通して型が忘却されたら、 そのジェネリックな型引数を埋める型がなんなのか知る術はないのです。

@iterable-company
Copy link
Owner Author

17.3

メソッドの第1引数にself、&self、&mut selfではなく、 self: Box<Self>としていることに注意してください。
この記法は、型を保持するBoxに対して呼ばれた時のみ、 このメソッドが合法になることを意味しています。
この記法は、Box<Self>の所有権を奪い、古い状態を無効化するので、 Postの状態値は、新しい状態に変形できます。

よくわからない。

@iterable-company
Copy link
Owner Author

18 から

@iterable-company
Copy link
Owner Author

19から

@iterable-company
Copy link
Owner Author

19.2 高度なトレイト

関連型

genericsで実装すると、複数の実装が可能になる。
型パラメータ T で宣言しているので、複数の実装が可能になる。
その中から適したものを実行するために、注釈をつけなくてはいけないなる。
関連型の場合は、その型のみの実装となるので、使用するときに型注釈の必要がない。

@iterable-company
Copy link
Owner Author

20から

@iterable-company
Copy link
Owner Author

次回20.2から

@iterable-company
Copy link
Owner Author

次回20.2の復習

非同期IOとfork/join の場合をやるかどうか。。。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant