Objective-C [ObjC part:9];

1デフォルトの名無しさん2017/11/17(金) 21:00:33.77ID:oYmLZZ1y
Objective-C(オブジェクティブ シー)はプログラミング言語の一種。C言語をベースにSmalltalk型のオブジェクト指向機能を持たせた上位互換言語。
 (Wikipedia:http://ja.wikipedia.org/wiki/Objective-C より)

前スレ
Objective-C [ObjC part:8.1];
http://mevius.2ch.net/test/read.cgi/tech/1414816517/

Objective-C [ObjC part:8];
http://peace.2ch.net/test/read.cgi/tech/1356341803/
Objective-C [ObjC part:7];
http://toro.2ch.net/test/read.cgi/tech/1330330906/
Objective-C [ObjC part:6];
http://toro.2ch.net/test/read.cgi/tech/1313891268/
Objective-C [ObjC part:5];
http://hibari.2ch.net/test/read.cgi/tech/1279730299/
Objective-C [ObjC part:4];
http://pc12.2ch.net/test/read.cgi/tech/1239721860/
Objective-C [ObjC part:3];
ttp://pc12.2ch.net/test/read.cgi/tech/1186543111/
Objective-C
ttp://pc11.2ch.net/test/read.cgi/tech/1106983092/
Objective-C
ttp://pc5.2ch.net/tech/kako/990/990574267.html

5デフォルトの名無しさん2017/11/17(金) 21:15:12.40ID:oYmLZZ1y

6デフォルトの名無しさん2017/11/17(金) 21:30:22.97ID:0jV1JJrR
>>1
とりあえずw、さんきゅーっ

7デフォルトの名無しさん2017/11/17(金) 22:13:33.72ID:00kx/Fcv
前スレ最後の方は
「ぼく電気工事士ですけど、ブレーカーとスイッチの違いってなんですかね?
いつも電気ケトルでお湯沸かすのにブレーカーオンオフしてますけど?」
みたいでトリップ感あった。

8デフォルトの名無しさん2017/11/17(金) 22:14:19.37ID:Tpi/0V/R
メソッドに渡されるselfがclassのポインタかインスタンスのポインタかの違い
って言ってもわからんだろうな

9デフォルトの名無しさん2017/11/17(金) 22:18:26.81ID:Q8rdVBz+
>>7
上手い例えだと思う。

10デフォルトの名無しさん2017/11/17(金) 22:45:46.26ID:KuiGlQ+X
わかりました!
クラスメソッドはプロジェクトで1つしかインスタンスが持てない
インスタンスメソッドは複数持てる
ですね!

つまりメソッドのロジックは同じで内部変数が違うものをいくつも同時に保持したいかどうかですね!

11デフォルトの名無しさん2017/11/17(金) 22:51:49.08ID:EkFnC7lu
一周回って合ってるおめでとう

12デフォルトの名無しさん2017/11/17(金) 22:57:51.02ID:Tpi/0V/R
ちょっと違う

13デフォルトの名無しさん2017/11/17(金) 22:58:24.49ID:KuiGlQ+X
ありがとうございます!

14デフォルトの名無しさん2017/11/17(金) 22:59:02.57ID:KuiGlQ+X
あれ?(汗)

15デフォルトの名無しさん2017/11/17(金) 23:04:16.69ID:oYmLZZ1y
逆に面白い解釈で初心者に解説する時の勉強になる可能性?
は無いか。

ここでNSObjctのインスタンスを見てみると
objc_object という構造体であり
中には Class ってのがいるだけだ
struct objc_object {
Class isa OBJC_ISA_AVAILABILITY;
};

Classってのはobjc_classと定義されているこんな感じの構造体だ
struct objc_class {
Class isa OBJC_ISA_AVAILABILITY;
Class super_class OBJC2_UNAVAILABLE;
const char *name OBJC2_UNAVAILABLE;
long version OBJC2_UNAVAILABLE;
long info OBJC2_UNAVAILABLE;
long instance_size OBJC2_UNAVAILABLE;
struct objc_ivar_list *ivars OBJC2_UNAVAILABLE;
struct objc_method_list **methodLists OBJC2_UNAVAILABLE;
struct objc_cache *cache OBJC2_UNAVAILABLE;
struct objc_protocol_list *protocols OBJC2_UNAVAILABLE;
};


そうインスタンスとはクラスを持っていてクラスはインスタンスを持っていないのだ
クラスメソッドもインスタンスメソッドもクラス構造体の中で定義されていて呼び出せる範囲が違うだけなのだ

そしてメソッドがインスタンスを持っているわけではなく
インスタンスの中のクラスの中にある物を呼び出しているのだ

これは構造はなくルールに近い話になる

16デフォルトの名無しさん2017/11/17(金) 23:09:06.54ID:Tpi/0V/R
>>14
インスタンスメソッドも、メモリに確保される実体は一つだけ
インスタンスをいくら作ろうがメソッドの実体は一つ
selfが違うからインスタンスごとに確保されたように見えるんだろ?
インスタンスを生成するごとに新たにメモリに確保されてるのはインスタンス変数

17デフォルトの名無しさん2017/11/17(金) 23:21:41.87ID:KuiGlQ+X
ロジックは1つで変数が複数ですね。
確かに無駄がないですね!
ここは超人レベルの方ばかりで難しいんですが、親切なので助かりました!

18デフォルトの名無しさん2017/11/17(金) 23:25:13.48ID:wg33BRe2
そうです

19デフォルトの名無しさん2017/11/17(金) 23:59:36.79ID:yjTQ4fwn
なぜ多くの開発者が今なお Swift よりも Objective-C を好むのか
https://frasco.io/why-many-developers-still-prefer-objective-c-to-swift-2c624232cdd2

20デフォルトの名無しさん2017/11/18(土) 00:00:27.78ID:jHta9B9D
もう一つ聞いていいですか。

Self.hensuと_hensuって同じものですか?
とりあえず全部_hensuで書いてます。

21デフォルトの名無しさん2017/11/18(土) 00:11:21.74ID:GufJ21C4
>>20
Self.hensuはゲッターが呼び出される
例えばこんな感じ
-(id)hensu{
 return _hensu;
}
これは
@synthesize hensu = _hensu;
としてインスタンス変数の_hensuを紐づけてると言う事
_hensuは直接_hensuを取る

取る時はそこまで問題にならないけど
セットする時は@propertyでretainを指定してる時は
@property (retain)id hensu;

Self.hensu = obj;
とするだけでセッターの中でretainしてくれるので
_hensu = obj;
とするより安全

色々自動で処理されて記述量が減った分、省略され過ぎて逆に分け分からなくなってる所は多い

22デフォルトの名無しさん2017/11/18(土) 00:24:14.19ID:jHta9B9D
せっかく値保持したくてretainにしていても_hensuにセットしてたら効果なくて、アプリが落ちるかもってことですね!
うわー、今までたくさん書いてきちゃった

23デフォルトの名無しさん2017/11/18(土) 00:41:51.30ID:GufJ21C4
例えばこうしたら
@interface test(){
 int _iHensu, _hensu;
}
@property (assign)int hensu;
@end
@implementation test
@synthesize hensu = _iHensu;
- (void)test{
 _hensu = 10;
 _iHensu = 90;
 NSLog(@"h1 %d", _hensu); //10
 NSLog(@"h2 %d", self.hensu);//90
}
@synthesize で hensuに_iHensuを登録すれば
self.hensuで呼び出されるのは_iHensuになる感じ
これはプリミティブ型のintだからassignだけど
オブジェクト型のインスタンスを
MRRチックに自分でretainするならセッター使わなくても問題ないよ
もちろんreleaseも必要
セッターゲッター使うとそれを省略出来るってこと

retainもセッターの中で
こんな感じの関数が呼ばれるだけだから
- (void)setHensu:(id)value{
 if(_iHensu != value){
   id oldValue = _iHensu;
   _iHensu = (value != nil ? [value retain] : nil);
   if(oldValue != nil) [oldValue release];
 }
}

24デフォルトの名無しさん2017/11/18(土) 00:50:08.22ID:jHta9B9D
知り尽くしてますね!
コツコツ_をselfに置換する方向でいこうかと思います(泣)

25デフォルトの名無しさん2017/11/18(土) 01:15:54.95ID:GufJ21C4
ただ処理速度の観点からいくとクリティカルな部分ではゲッターの関数呼び出しより
直接インスタンス変数を呼んだ方が良い場合もあるセッターもしかり
自分でコントロール出来るなら出来合いの関数を使わない方がスマートだったりする
あと
@property (assign)int hensu;
と登録してる場合は自動でソースにセッターも追加されてるから
関数を書かなくても
[self setHensu:10];

self.hensu = 10;
は同じなんだけど前者の書き方の方が都合がいい場合もあるから覚えとくと良い
自動入力での候補から入力した場合も数値まで行くから多少速い気もするし (これは慣れかもしれないけど

ちなみに@property setter =やgetter = で呼び出しの関数を変える事も出来るよ
こういうのを覚えておくとセッター関数をオーバーライドして同期処理を追加したりして
KVOを登録しないでKVOチックな事が出来たりする

26デフォルトの名無しさん2017/11/18(土) 01:58:32.81ID:GufJ21C4
あ、ちなみにオブジェクト型の個別のretain とか release はMRCでの話で
ARCだとまた少し話が変わってくるわけだけどもね
そんなに気にしなくても美味い事やってくれますよ彼女なら

27デフォルトの名無しさん2017/11/18(土) 03:58:01.57ID:jHta9B9D
objective-cってなんかすごく深いですね

28ビル・ジョブス2017/11/18(土) 08:36:45.51ID:22t4JudU
X MRC
O MRR - Manual Retain Release

29デフォルトの名無しさん2017/11/18(土) 09:39:22.21ID:GufJ21C4

30デフォルトの名無しさん2017/11/18(土) 09:52:05.60ID:y+yjhIU6
こんな感じに理解してたんですけど合ってます?

-initWithString
インスタンスメソッド。allocしないと使えない。あとでreleaseが必要。

+stringWithString
クラスメソッド。allocしなくていい。
autoreleasepoolに登録された状態のインスタンスが返るので、
releaseしなくていい。

ARCだと、「releaseしなくていい」という
コンビニエンス・コンストラクタのメリットが薄れた。
(気軽にallocしちゃってもメモリリークしない)

31デフォルトの名無しさん2017/11/18(土) 10:19:53.99ID:QpBxoTJw
>>30
今時Obj-CでMRRを使う場面は無いと思うが、参照カウント方式は基本なので教えると

Obj *obj = [[Obj alloc] init];

“init”から始まる、名前がlower camel caseのインスタンスメソッドは、retain済みのオブジェクトのポインタを返す
これを「initファミリー」と言い、この命名規則を守れば自作メソッドでも自動的にretain済みを返す
変数objはただのポインタで、-initから返る上記のポインタ値を代入してるだけ
retain済みなので使いおわったら-releaseを呼んで解放する

AppleのAPIの、いわゆるコンビニエンスコンストラクタはautorelease済みのオブジェクトを返すので、releaseしてはならない
その場合main()のautoreleasepoolに登録されるので解放されるのはアプリ終了時になる
解放のタイミングを自分で制御したい場合はinitファミリーを使うかautoreleasepoolで囲うかする必要がある

32デフォルトの名無しさん2017/11/18(土) 10:34:38.89ID:QpBxoTJw
{ initファミリー/retain } と { release } は対で使うこと

View *view_ = [[View alloc] initWithFrame:CGRectMake(0,0,100,100)];
[self.view addSubview:view_];
[view_ release]; //上記initWithFrameと対

これはself.viewがview_をretainして保持するので、以降直接参照しないのならここでreleaseしても良い
self.viewはselfが解放されるときに解放され、その時にview_にもreleaseが呼ばれる //self.view側で呼んだretainと対

33デフォルトの名無しさん2017/11/18(土) 10:38:27.21ID:QpBxoTJw
対で使うのが大原則なので、例えば

@property (retain) id obj;

というプロパティを持ったクラスなら必ずそれをdeallocでreleaseすること

- (void)dealloc
{
 [_obj release];
 [super dealloc];
}

34デフォルトの名無しさん2017/11/18(土) 10:41:50.62ID:QpBxoTJw
こんなことを全自動でやるのがARCなので、普通はARC使うけどね
でARCとは、ビルド時にretain/releaseの行を、strong/weakに応じて挿入するだけで実現できているのだ
シンプルだね

35デフォルトの名無しさん2017/11/18(土) 11:34:23.42ID:y+yjhIU6
>>31-34
詳しい説明ありがとうございます!

自作メソッドでも、initから始めると自動的にretainされるのは
知らなかったです。

あと、main()のautoreleasepoolが解放されるのは
アプリ終了時、というのも分かってなかった…。

ARCがない時は、メモリリークが怖くて、
コンビニエンス・コンストラクタばっかり使ってましたけど、
あんまり意味がなかったのかも…。

今はARCのおかげで、何も考えずにallocとかnewできて
楽になりました。

36デフォルトの名無しさん2017/11/19(日) 11:30:09.61ID:RC6H/PLj
>>1
遅くなったけどスレ立てありがと

37デフォルトの名無しさん2017/11/22(水) 03:50:42.17ID:xPTGudok
複数のhファイルで同じ#import~をたくさんかくと何かデメリットがあるのでしょうか?
わかりやすくmで使っているものをそれぞれ全部書くべきか、書かなくてもビルドが通るなら書かない方がいいのかベストは何でしょうか。

38デフォルトの名無しさん2017/11/22(水) 10:19:35.09ID:r2ZqOIfG
>>37
#include
使ってた人は
重複定義とか循環参照とかでビルドエラーになった経験があるからね
#import
でも#include時と同じように気を付けるってだけ
実際#importは多重インクルードしない機能があるから問題ないけど
ソースが汚れるし参照でエラーが出る事あるしで無闇にimportしない
必要な物だけimportして
親子関係をしっかり考えたコーディングを心がけましょうってこと

39デフォルトの名無しさん2017/11/22(水) 15:51:24.96ID:xPTGudok
なるべく必要最小限にということですね。

40デフォルトの名無しさん2017/11/22(水) 15:55:29.92ID:xPTGudok
AViewcontrollerを開いたあとに、BViewcontrollerを開くと、Aでimport たファイルはBでしなくてもビルドが通るので書かない方がいいのかなとモヤモヤしてました

41デフォルトの名無しさん2017/11/22(水) 19:21:42.58ID:X4A9CpkS
ヘッダで必要ならヘッダでimport、ソースで必要ならソースでimport

42デフォルトの名無しさん2017/11/23(木) 00:42:23.09ID:OCoBz1Jl
ヘッダにはimportせず
@class
の登場も多い

43デフォルトの名無しさん2017/11/25(土) 10:14:21.83ID:QEaE88pM
すれ違いだったらすみません。
dudReciveMemoryWarningの活用方法って何かありますでしょうか?

44デフォルトの名無しさん2017/11/25(土) 10:47:26.89ID:HXFBSnjY
今必要でなくて再取得/再計算できるものは解放するんや
せやないとクラッシュする

45デフォルトの名無しさん2017/11/25(土) 10:57:22.27ID:QEaE88pM
するarcの場合は自動なのでやることはないとうことですか?
または配列にnilを入れたりすることも効果ありますか?

46デフォルトの名無しさん2017/11/25(土) 14:12:30.26ID:xzKXUh+9
strong変数にnilを代入してメモリを解放
NSArrayは要素をstrongで保持するのでNSArrayごとnilにすれば解放される
ただでかいメモリ食うのは主にビューなんで、表示してない不要なビューは解放するのが効く
つうか、ビューは必要な分を動的に生成が基本だろ
そもそもそのメッセージ飛んできたらユーザーに再起動を促すね俺は

47デフォルトの名無しさん2017/11/26(日) 03:28:42.31ID:9JZfehuk
>>46
Viewを動的作成しておいて解放は効果ありそうですね。
Tabだったら他のViewcontrollerを解放することは可能でしょうか?
確かにこまごま対処するより再起動なら間違いないですね

48デフォルトの名無しさん2018/01/08(月) 17:55:53.60ID:PDDlr6cN
返り値複数の関数は作れますか?

49デフォルトの名無しさん2018/01/08(月) 19:39:48.53ID:g3wGVkXu
構造体とかobject(メンバ)を返す

50デフォルトの名無しさん2018/01/10(水) 20:03:11.34ID:BUMGzXZx
cocoa event handling 難しいです。

Windowに置いたAVPlayerViewのjkl キーナビゲーションをカスタマイズ=潰したいです。
別のViewを配置して、NSResponderのkeyEquivalent系メソッドでキーコードのjklなNSEventをぶんどれば良いのでしょうか。

AVPlayerViewは、acceptFirstResponderにYesと返してくるのに、Viewをクリックしてもfirstresponderにならないので悩んでます。

51デフォルトの名無しさん2018/01/10(水) 22:15:32.63ID:oP8dWPVt
AVPlayerViewのサブクラスを作って、その(キー)イベントハンドラでやればいいんじゃないの。てかそれが普通で簡単確実じゃないかなあ。もしくはMethod Swizzlingでとか
NSResponder云々はResponder chainを理解してなさげ。奪うとかよりも取りこぼしを拾うような感じで、やりたいような処理機会を奪うのはムズいだろう

52デフォルトの名無しさん2018/01/13(土) 21:00:50.73ID:r2JNGeyO
もう少し教えて下さい。
event handling guideを読み進めたのですが、keyboard eventの場合には、最初にperformkeyequivalent
がWindow上の全viewに対して一通り呼ばれて、
その後にmenu barのショートカットが評価され、
それでも該当しない場合に初めて
keyDown:をresponder chainへ投げる流れに進む、
と理解したのですが、正しいでしょうか。

この理解ですと、acceptFirstResponder/responder chainが意味を持つのはキーイベント処理のかなり後になるように思えます。
viewが実装しているキーボード処理をoverrideする場合
親クラスがkeydownのみ実装していると仮定するのは
微妙かなと感じたのですが、AppKitではkeyequivalentでは実装しない、そういう前提で書くのが正しいのでしょうか。

53デフォルトの名無しさん2018/01/13(土) 21:39:21.90ID:CuNC/zNj
読んだだけだろ?テストしたらわかるよperformKeyEquivalent:の意味が

54デフォルトの名無しさん2018/02/16(金) 06:10:45.34ID:W1XJdyx1
☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が3分の2を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆

55デフォルトの名無しさん2018/02/16(金) 11:15:20.63ID:619F/gvV
こういう宣伝活動はエセ右翼

新着レスの表示
レスを投稿する