昨日の予想通り体調が崩れた。

diary

昨日、夜まで仕事して、お酒も飲んでしまったので、日課が崩れて、今日の体調も崩れた。

vacant

虚無な一日を送ってしまった。

昨晩、薬を飲み忘れ、朝も薬を飲み忘れて、何もできなかった。

ご飯食べて寝るという生活をまた送ってしまった。

休息は日常生活において重要な役割をはたしているが、それでもなお、虚無な一日を送ることはつらさがある。

ecs

朝起きたら、無限再起動ではなく、無限タスク起動が起きていたことが判明した。

次回の出社で修正する。

dream

夢の記録

• 部屋の隅で蜘蛛が巣を張っている。
• 黒と紅。コントラストがキレイ。
• 蜘蛛がたまごを抱えている。
• 親の腹を子供たちが食す。

今日の勉強

rust

TRPL

• pp. 65-68
• 文字列リテラルが不変であるから、中身がコンパイル時にわかっているから、バイナリに直接ハードコードされ、高速で効率的になる。
• サイズが不明・可変なら、テキスト片用に一塊のメモリをバイナリに確保するのは不可能
• String型は、コンパイル時に不明な、メモリをヒープに確保して内容を保持する
  • メモリは実行時にOSに要求する(String::from)
  • String型を使用し終わったら、OSに個のメモリを返す方法が必要
    • GCがある言語なら、使用していないメモリを自動で解放
    • GCがない言語では、明示的に返還するコードを呼び出すのはプログラマの仕事
      • これの難しいところ:
        • 返還忘れで、メモリの無駄な使用
        • 返還が早くて、無効な変数を生成
        • 返還を二回して、バグを生み出す
    • Rustが歩む道は、所有権
      • メモリを所有している変数がスコープを抜けたら(ここが自然な地点)、メモリを自動的に返還する
        • スコープを抜けたところで、drop関数という特別な関数が呼ばれる
      • ヒープ上に確保されたデータを複数の変数に使用されるような、もっと複雑な場面でコードの振る舞いは予期しないものになる可能性がある
• 複数の変数が同じデータに対して、異なる手段で、相互作用する
  • 不変な場合、整数などの既知の固定サイズの単純な値の場合は問題にならない
    • スタック上に保持されているので、変数のコピーを作成することは、スタックのデータをコピーしている。
  • String::fromで生成されたものは3つの部品で構成されており、それはスタック上に保持されている。
    • ptr: 文字列の中身を保持するメモリへのポインタ
      • その中身はヒープ上に保持されえている。
    • len: 現在使用しているメモリ量をバイトで表す「長さ」
    • capacity: OSから受け取った全メモリ量をバイトで表す「許容量」
  • String型の変数をコピーすることは、スタック上のデータのコピーをしており、ヒープ上のデータをコピーしない
  • 問題点
    • 変数がスコープを抜けると、Rustは自動的に、その変数が使っているヒープメモリを開放する
    • スタック上のデータをコピーした変数、両方は、同じヒープメモリを見ている。
    • 両方の変数がスコープを抜けると、2重解放が発生するのでは？
      • 2重解放の問題は、memory coruptionを産み、脆弱性を産む可能性がある
      • (moveの話につながっていく)