私は、命名基準が日常的に無視されてきたコードベースを扱っています。そのため、一部のクラスには、メソッド名がNARCに準拠していなくても、参照カウントが1のオブジェクトを返すメソッドがあります。素晴らしいもの。
プロジェクトを自動参照カウントを使用するように変換したいのですが、NARCの命名基準が完全に無視されているため、少し緊張しています。ARCが正しく機能するためにNARC命名基準に依存しているかどうかを誰かが知っていますか?
ありがとう、
ショーン
私は、命名基準が日常的に無視されてきたコードベースを扱っています。そのため、一部のクラスには、メソッド名がNARCに準拠していなくても、参照カウントが1のオブジェクトを返すメソッドがあります。素晴らしいもの。
プロジェクトを自動参照カウントを使用するように変換したいのですが、NARCの命名基準が完全に無視されているため、少し緊張しています。ARCが正しく機能するためにNARC命名基準に依存しているかどうかを誰かが知っていますか?
ありがとう、
ショーン
ARCは、正しく機能するために命名規則に依存しています。でも...
ObjCオブジェクトのみを使用した場合、ARCコードしかない限り、通常は「うまくいく」でしょう。たとえば、次のようなメソッドがある場合:
- (id)something {
return [[Something alloc] init];
}
これは(非ARCコードでは)間違っていますが、ARCは効果的に余分なを追加することでバランスを取りautorelease
ます。実際、上記は正しいARCコードなので、問題ありません。
私の提案は、これがほとんどすべてのObjCコードである場合、ARCに自動変換してから、静的アナライザーを実行することです。たまたま名前が間違っている非常に単純なコードの場合、問題は実際にはあなたが恐れているよりもはるかに小さいかもしれません。
これがCoreFoundationのフリーダイヤルのブリッジコードである場合、状況はもう少し複雑になります。次に、最初に静的アナライザーを実行し、変換する前に命名権を取得することをお勧めします。幸いなことに、命名規則は静的アナライザーが非常に得意なものです。
私はいくつかのプロジェクトをARCに変換する必要がありましたが、これまでのところ、命名規則がまったく原因で直接問題が発生することはありませんでした。
実際、変換は非常に簡単です。つまり、処理する必要のあるコードについてのあなたの心の状態を完全に理解していますが、それほど心配する必要はありません。
これまでのところ、変換されるコードがそもそも正しく、どういうわけか理解しやすいものである限り、変換中に深刻な困難な状況に遭遇したことはありません。
実際、ARCを使用すると、GCが組み込まれている他の言語と同じように問題が発生しません。もちろん、メモリの問題に関してです。
最悪の場合、常に静的アナライザーを実行できますが、最近のARCではそれが必要になることはめったにありません。
おそらく最も重大な状況についてここで説明します。Objective-Cの自動参照カウントでは、どのような種類のリークが防止または最小化されないのでしょうか。