プロトコルを使うメリット 複数適用できる 柔軟性が高い 抽象化できる 基本文法 多言語でいうインターフェース classやstructやenumなどで使える。 複数適用可能 @objc optional なメソッドを定義できる デリゲートで使う ドキュメント Extensionで読みやすく protocol SomeProtocol { var computedA: String { get } func methodA(_ str: String) func methodB(a: Int, b: Int) -> Int } class someClass {} extension someClass: SomeProtocol { var computedA: String { return "a" } func methodA(_ str: String) { print(str) }
nonatomic と atomic の使い分けの指針は次のとおり： 参照型: メモリアドレスのみの書き込みなので、常にnonatomicでよい プリミティブ型: int, BOOL等ワンステップでの書き込みが可能: 常にnonatomicでよい 単一のスレッドからしかアクセスされない: 設計に気をつけつつnonatomic推奨 複数のスレッドからのアクセスがあり、long,構造体などサイズの大きい値: atomic推奨 (thx to @takasek) 複数のスレッドから同時に読み書きが行われる可能性があるプロパティには atomic を指定する。 atomic を指定することで getter と setter が排他的に実行されるようになり、値の書き込みに複数のメモリ操作命令が必要な型（構造体など）が中間状態で読み出されることがなくなる。 atomic を指定してもスレッドセーフにな
最近 DirectShow や GStreamer などのマルチメディアフレームワークを勉強している。これらの特徴を表すキーワードとして pipe-and-filter とか graph-based とか filter chains とかいろいろ出てくるのだが、どうやら filter graph という用語が一般的のようだ (wikipedia に項目としてあるという意味で)。 ところで、グラフという言葉でふと思い出したのが表題の「グラフ(Graph) と 木(Tree) の違い」。グラフ理論の教科書に書いてあるような厳密な定義はおいておいて、要するに一言で言うと違いは何という部分。私なら、 木は各ノードへの入力(親)が必ず一個しかない。そうじゃないのが(親が複数あれば)グラフ。 という説明をする。木をその特殊なケースの二分木のことだと理解していると、子の数や深さを説明に出してしまう。もち
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く