cpprefjpを読み進めた。

<new>

• get_new_handler, set_new_handler, new_handler: こんなハンドラ設定できたの知らなかった。
• bad_alloc: 説明が若干分かりにくいが、確保失敗して「かつ」get_new_handlerの結果がnullptrの場合という話か。
• bad_array_new_length: こんな例外あったのか。
• align_val_t: 言語機能を全部読んだので知ってた。
• nothrow_t: 知ってた。使ったことはほとんどない。
• destroying_delete_t: これも言語機能の記事を読みとおしたので把握してはいた。使いこなせる気はしない。
• operator new: 5つ並べられているが、nothrowの有無×アラインメント指定の有無で4パターンとplacement newで+1の5パターンが並べて書いてあるだけのようだ。
• operator delete: 7つ並べられている。アラインメント要求の有無×サイズ情報の有無もしくはnothrow指定で6パターン、そしてplacement newで+1パターン。サイズ情報の有無とnothrowは独立ではないのがよく分からない。
• hardware_destructive_interference_size, hardware_constructive_interference_size: これもまたちょっと説明が分かりにくいが、destructiveの方が「キャッシュ共有を避ける」目的で、constructiveの方が「同一キャッシュに載せる」目的で使われる数値のようだ。
• launder: 最適化抑制の一種だが、やっぱりよく分からない。

<typeinfo>

• type_info
  • constructor: ユーザーが構築することはできないらしい。コピーやムーブも不可のようだ。これは意外。唯一const参照を使って束縛しておくことはできる。
  • destructor: はい
  • before: こんなのあったのか。ユーザーからこれが見えて嬉しいのってどういうケースだ？
  • hash_code: ただの比較なら素直にtype_info::operator==を使えばいいと思うが、持ちまわる用途だとこれがある方がありがたかったりするのだろうか。
  • name: お前が正式な型名を返す保証がないせいで初心者に教えるのがだるい…
  • operator==, operator!=: はい
• bad_cast: お前、typeinfoの中にいるのか。
• bad_typeid: nullptrのときだけという説明なので、じゃあ適当にメモリアドレス100番地とかを間接参照したらどうなるのか実験したら、セグフォした。それはそうか。

---

Celeste9面のデス数が14まで縮まった。かなり金イチゴが見えてきたが、determinationの0デス突破が未だに1度もないのはちょっと厳しい。