Objective-Cの日付周りの処理ってホンっッとイヤだな・・・。
ロケールとか絡んでくるから複雑になりがちなのは分かるが、もっと素直でシンプルな実装あるだろ・・
プログラミングのことを書くぞ。I'm gonna write programming-related topics here.
Objective-Cの日付周りの処理ってホンっッとイヤだな・・・。
ロケールとか絡んでくるから複雑になりがちなのは分かるが、もっと素直でシンプルな実装あるだろ・・
オブジェクトを保持するためには、オブジェクトに retain を送る。そのためには
[anObject retain];
などとする。これはいいとして、では、具体的に retain カウントを持っているのは誰か? といえば、それは anObject ではなく、あくまで 0x33994b2c とかいうアドレスで「メモリ上に格納されているそれ」である。
anObject は単なるポインタであって、「それ」と通信する窓口にすぎない。窓口は複数あっても良いから、anotherObject という別の窓口から retain やら release を送ってもよい。
・・・こんな話は Objective-C の入門書に書いてあることをよく噛みしめて読めば分かることなのだけど、始めた当初はどうにもこの仕組みを把握しにくかった。
で、最近思うに、その理由は「『それ』はメモリ上の『それ』であって、あくまで名前は無い」ということをハッキリ意識できていなかったからではないか、と。
静的な変数では、「名前」と「それに対応するメモリ上のデータ」を別個に意識する必要はないわけで、そのイメージが当初はなかなか拭えなかったのかもしれない。
Objective-C はいわゆるクラス変数というのがないから、それ相当のものが必要なら static 変数を定義してそのファイル内で静的に確保される変数を作りなさい、というのだけど、いざそのようにしてみると一応動くものの "defined but not used" という警告がやたらめったら出る。
なんじゃいこれは、と思って調べたら出てきた。
static変数宣言をヘッダファイルの方に書いてしまうと #import で呼ばれるたびに変数を確保してしまうんだそうで。
僕のプロジェクトはかなり #import が入り乱れているので(二重取り込みを気にしなくていいから基本多めに書いてしまう)、static 変数ひとつあたり10個とか警告が出る;
解決策は、static 変数を .m ファイルの方に書くこと。
なーんだ簡単。
メモリ管理の難しさは、自分が設計する部分じゃなくて、
ライブラリとか他人が作ったもののに受け渡すところが
難しいようですね。
渡した先でretainされるのかどうか? っていのと、
どのタイミングでreleaseが送られるのか? ってあたりですかね。
ちゃんと時間作ってよく調べてみないとな。
多分現状だとメモリがダダ漏れ状態と思う;