1read 100read
2012年1月1期プログラム53: Objective-C [ObjC part:6]; (562) TOP カテ一覧 スレ一覧 2ch元 削除依頼
・ 次のスレ
54: JavaScriptスレ (554)
55: Git 3 (910)
56: Rubyについて Part46 (81)
57: 圧縮・復元 相談室 (873)

Objective-C [ObjC part:6];


1 :11/08/21 〜 最終レス :12/01/09
Objective-C(オブジェクティブ シー)はプログラミング言語の一種。C言語をベースにSmalltalk型のオブジェクト指向機能を持たせた上位互換言語。
 (Wikipedia:http://ja.wikipedia.org/wiki/Objective-C より)
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

2 :
*** プログラム技術板 ***
【マック】Macintoshプログラミング質問箱
http://hibari.2ch.net/test/read.cgi/tech/1113058054/
*** 新・mac板 ***
Cocoaはさっぱり!!! version.16
http://hibari.2ch.net/test/read.cgi/mac/1307162542/
Macでプログラミング{10}
http://hibari.2ch.net/test/read.cgi/mac/1248682344/
iPod touch/iPhone ネイティブアプリ製作 ver.16
http://hibari.2ch.net/test/read.cgi/mac/1312723856/

3 :
*** 本家 ***
Objective-C 2.0 プログラミング言語
ttp://developer.apple.com/jp/documentation/Cocoa/Conceptual/ObjectiveC/
Introduction to The Objective-C 2.0 Programming Language
ttp://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Introduction/introObjectiveC.html
そのほか英語
ttp://developer.apple.com/documentation/Cocoa/ObjectiveCLanguage-date.html
*** 書籍 ***
荻原本
http://amazon.jp/dp/4797346809
HMDTダイナミック本
http://amazon.jp/dp/4861006414

4 :
ダイナミック Objective-C サイト
http://journal.mycom.co.jp/column/objc/
Apple のランタイムのソースコード (10.7)
http://www.opensource.apple.com/source/objc4/objc4-493.9/
英語のサイト
Objective-C 入門
http://cocoadevcentral.com/d/learn_objectivec/
Objective-C Style 1, 2 (変数名のつけかた等)
http://cocoadevcentral.com/articles/000082.php
http://cocoadevcentral.com/articles/000083.php
Mike Ash さん(Audio Hijack の中の人)のブログ、 Obj-C のランタイムの話が良く出る
http://mikeash.com/?page=pyblog/
C++ と Objective-C の文法の比較
http://ktd.club.fr/programmation/objective-c.php

5 :
民主党web-site  http://www.dpj.or.jp/
民主党「生活が第一」チャンネル  http://www.youtube.com/dpjchannel?gl=JP&hl=en

6 :
*** 警句 ***
汝、retainCountを数える事なかれ
そは、理を知り真理に触れし者のみが振える御技
汝、オーナーシップの本質を見よ
そは、相反する一対の調和を守る事也
allocにはreleaseを。copyにはreleaseを。retainにはreleaseを。
アーメン

7 :
objcはgtagsできないわけ?

8 :
Objective-Cの言語的な面白さや美しさってどこですか?

9 :
age

10 :
円高なんとかしろよ、このヤロー!

11 :
うるせーバカヤロー!

12 :
SpeedMailerのこうなごさんのサイトがインドネシアのハッキンググループにハックされたままになってもう1週間以上。だれか教えてあげてw
http://kounago.jp/

13 :
>>3
それ古すぎ。こっちが最新。
*** 本家 ***
Objective-C 2.0 プログラミング言語
http://developer.apple.com/jp/devcenter/ios/library/documentation/ObjC.pdf

14 :
これもObjCか?
Blocksプログラミングトピックス
http://developer.apple.com/jp/devcenter/ios/library/documentation/Blocks.pdf
並列プログラミングガイド - GCDとか
http://developer.apple.com/jp/devcenter/ios/library/documentation/ConcurrencyProgrammingGuide.pdf
こっから
http://developer.apple.com/jp/devcenter/ios/library/japanese.html

15 :
すごいバグ発見したのだが。。。。
配列の要素の入れかえでNSMutableArrayのexchangeObjectAtIndex:withObjectAtIndex:って
メソッドが壊れていることに気づいた。
下のコード実行してみてほしい
NSMutableArray *dataSource = [[NSMutableArray alloc] init];
// 10個の要素を持つ配列を生成
for (int i = 0; i < 10; i++) {
 [dataSource addObject:[NSString stringWithFormat:@"%d", i]];
}
// 変更前の配列の中見を確認する
NSLog(@"%@", dataSource);
// インデックス0の要素とインデックス2の要素を入れ替える
[dataSource exchangeObjectAtIndex:2 withObjectAtIndex:0];
// 変更後の配列の中見を確認する
NSLog(@"%@", dataSource);

16 :
>>15
2011-09-02 00:46:40.895 gomi1[12097:707] (
0,
1,
2,
3,
4,
5,
6,
7,
8,
9
)
2011-09-02 00:46:40.897 gomi1[12097:707] (
2,
1,
0,
3,
4,
5,
6,
7,
8,
9
)

17 :
2011-09-02 00:49:10.310 Test[9304:707] (
0,
1,
2,
3,
4,
5,
6,
7,
8,
9
)
2011-09-02 00:49:10.312 Test[9304:707] (
2,
1,
0,
3,
4,
5,
6,
7,
8,
9
)
で?

18 :
これは、どういうバグだ?

19 :
初心者は自分の頭がバグってるという好例

20 :
正常にみえるけど、どこがバグってるの?

21 :
>>20
>>19

22 :
NSOperationQueueをmainQueueで作った場合にcancelAllOperationsしても
中のNSOperationクラスが残ったままなのですが、これは何が原因でしょう??
// キュー作成
self.queue = [NSOperationQueue mainQueue];
// NSOperationのサブクラス作成
Operation *op = [[[Operation alloc] init] autorelease];
// エンキューする
[self.queue addOperation:op];
// キャンセルする
[self.queue cancelAllOperations];
// キューの中身を確認する(0ではなく1になる)
NSLog(@"%@", [[self.queue operations] count]);

23 :
キャンセルする前に実行されてしまったとか?

24 :
>>22
cancelAllOperationsは[op cancel]するだけじゃなかったっけ。
Operationが停止するまで待ちたいなら、
その後にwaitUntilAllOperationsAreFinishedを追加かな。

25 :
>>23
テスト的に10秒くらいかかる処理にしてるのでそれはないです。
>>24
むしろ[op cancel]してもらえればop側で処理を停止するように書いてあるので
cancelメッセージを送信してほしいんですが、調べてみると送っていませんでした。
これが原因だと思います。なぜ送信しないかは不明です。
ちなみにwaitUntilAllOperationsAreFinishedはopが実行完了するまでスレッドを
ブロックするメソッドのなので、やりたい事とちがいます。
ちなみにNSOperationQueueの初期化を下記のようにすると
きちんとキャンセルされます。
self.queue = [[[NSOperationQueue alloc] init] autorelease];

26 :
mainQueueはまさに実行中のメインスレッドのキューだから、エンキューしたとたんにすぐ実行されて
キャンセルが間に合わないんじゃないの?
別に作ったキューは、エンキューしてから実際に実行されるまで間があるだろうから、実行前にキャンセル
できたのでは?
ドキュメントでも、一旦実行されたオペレーションのキャンセルができるかどうかは、オペレーション側の
実装次第ってかいてあるし。
キューに残っているオペレーションのステータスを確認してみたら?

27 :
mainQueue は共有資源で、他でも使ってるかも知れないのに cancelAllOperations してもいいのかな?
あと、残った 1 は、まさに cancelAllOperations を実行中の operation かも。
•cancelAllOperations の前には operations の数はいくつあったか
•cancelAllOperations で自分の作った operation がいくつ cancel されたか
を確認すべきでは?

28 :
>>22
NSOperationQueueにCancelAllOpetationを送ってもQueueからは削除されずに、全てのOperationをCancel状態にするだけです。cancel状態の時はmainメソッドは呼ばれないのです。昔、10,000個近く突っ込んでえらい目にあった(笑)

29 :
>>28
mainQueueのときはそもそもcancelを呼ばない?から、ちょっと違う問題な気がする。
ユーザーの操作に応答しなくなるだろうから、mainQueueに突っ込むメリットがあまり無いと思うんだけど、
どういう時に使うんだろうか。

30 :
mainQueueって、RunLoopで処理されるキューでしょ?
cancelしたあと、一度RunLoopに戻ってみたら?

31 :
>>30
cancelが呼ばれず、オペレーションを終了できないので、
戻す方法がわかりません。
(個別にcancelを呼べば、終了できる)

32 :
オペレーションの実装に問題があるような気がする。実行中にCancelが呼ばれた時の処理がうまくできてないとか。

33 :
mainQueueのときはcancelAllOpetationではcancelが呼ばれない?ので、
呼ばれたときの処理の問題では無い気がします。
オーバーライドしてログ出力するようにしても、ログが表示されない。
allocした場合はログが表示される。
(個別にcancelを呼んで対処は可能)
- (void)cancel {
NSLog(@"%s", __func__);
[super cancel];
}
- (void)main {
NSLog(@"%s", __func__);
while (![self isCancelled]) {
sleep(1);
NSLog(@"sleep");
}
}
- (void)dealloc {
NSLog(@"%s", __func__);
[super dealloc];
}

34 :
いい加減ウザイからNSOperationのリファレンス見たけど
理由と思われるものがちゃんと書いてあるよ
長いから自分で読んでね!
Responding to the Cancel Command
って所もね

35 :
>>34
mainQueueだとcancelAllOpetationでcancelを呼ばないって
理由と思われるものは書いて無いんじゃないかな。
英語は得意じゃないんで、間違ってたら指摘よろしく。
自身のcancelメソッドを呼ぶか、キューのcancelAllOpetationを呼べと書いてあるように見える。
You do this by calling the cancel method of the operation object itself or by calling the cancelAllOperations method of the NSOperationQueue class.

36 :
cancelは、少なくともキュー内にそのオペレーションが確実に存在してて、
実行前か、実行中じゃないと呼ばれないと思うので、エンキューと、キャンセルの
タイミングが書かれてないと、なんともわからない。
cancelが呼ばれた時のキューの中身と、各オペレーションのステータスを表示
してみたらいいんじゃあるまいか。
もしかしたら、メインキューの場合、次のループまで実際の処理が遅延するとか
あるのかもしれない。まぁ結構適当に書いた。

37 :
1秒かかるオペレーションを10個ほど突っ込んで -cancelAllOpetation 呼んで見れば何か分かるんじゃないかな?

38 :
動作確認用のサンプルコードを書いて見た。
int main(int argc, char *argv[]) {
CFShow(@"*** START ***");
CFRunLoopPerformBlock(CFRunLoopGetCurrent(), kCFRunLoopDefaultMode, ^() {
CFShow(@" begin Func1");
[[NSOperationQueue mainQueue] addOperationWithBlock:^() {
CFShow(@" begin Func2");
CFRunLoopStop(CFRunLoopGetCurrent());
CFShow(@" end Func2");
}];
[[NSOperationQueue mainQueue] cancelAllOperations];
CFShow(@" end Func1");
});
CFShow(@"RUN!!");
CFRunLoopRun();
CFShow(@"*** END ***");
return 0;
}
*** START ***
RUN!!
begin Func1
end Func1
begin Func2
end Func2
*** END ***

39 :
書き忘れてたけど、GCは必須ね

40 :
なにを動作確認しようとしているのか、さっぱりわからない。
キャンセルしようとした時にキューの中がどうなっているのかを確認しないと。

41 :
ようするに、cancelAllOperationsを呼んでもキャンセルされない、ということだ

42 :
Func2が実行されたのは、cancelが呼ばれた時点で、既に実行されてて間に合ってないからじゃないの。
だから、cancelを呼ぶ時点でのキューの中身とそれぞれのステータスを確認してみないと意味ないよ。
何回も指摘されてるけど、ドキュメントには、cancelは直ぐに効果を及ぼすとは限らないって書いてあるよね。

43 :
int main(int argc, char *argv[]) {
 CFShow(@"*** START ***");
 CFRunLoopPerformBlock(CFRunLoopGetCurrent(), kCFRunLoopDefaultMode, ^() {
  CFShow(@" begin Func1");
  [[NSOperationQueue mainQueue] addOperationWithBlock:^() {
    sleep(1);
    CFShow(@" begin Func2");
    CFRunLoopStop(CFRunLoopGetCurrent());
    CFShow(@" end Func2");
  }];
  [[NSOperationQueue mainQueue] addOperationWithBlock:^() {
    sleep(1);
    CFShow(@" begin Func3");
    CFRunLoopStop(CFRunLoopGetCurrent());
    CFShow(@" end Func3");
  }];
...続く

44 :
  [[NSOperationQueue mainQueue] addOperationWithBlock:^() {
    sleep(1);
    CFShow(@" begin Func4");
    CFRunLoopStop(CFRunLoopGetCurrent());
    CFShow(@" end Func4");
  }];
  [[NSOperationQueue mainQueue] cancelAllOperations];
    CFShow(@" end Func1");
  });
  CFShow(@"RUN!!");
  CFRunLoopRun();
  CFShow(@"*** END ***");
  return 0;
}

45 :
すまん間違った。忘れてくれ。

46 :
>>42
> Func2が実行されたのは、cancelが呼ばれた時点で、既に実行されてて間に合ってないからじゃないの。
何を言っているのか、いまいち分からないのだが、
まず、君の言う「cancel」って-[NSOperation cancel]のこと?
それとも、-[NSOperationQueue cancelAllOperations]のこと?

47 :
>>42
さっきから、RunLoopの話が出ている訳だが、このコードがシングルスレッドで動いていることは、分かっているよね?

48 :
ちょっと試してみたが、>>38の言うとおり、メインキューでは、cancelAllOperationsはきかないみたいだな。
allocして作ったキューではきく。違いは何かというと、シリアルか非同期かいうことか。
説明がドキュメントにみあたらないげと、もうそういう仕様ということでいいんじゃね?
メインキューはUIも処理するから、本来時間のかかる処理をメインキューでやるべきではないし。

49 :
GCDで書いてシングルスレッド?あるのか。
>>37,42 説を推すが。

50 :
>>49
GCDじゃなくて、あくまでNSOperationだから。じゃないのか?

51 :
-[NSOperationQueue cancelAllOperations] に breakpoint 設定して、
アセンブリコードおっかけて見りゃわかるが、
mainQueue の時だけ「何もしない」処理になってる。
mainQueue は共有資源なんだからこれはこういう仕様なんだろう。
cancelAllOperations で意図しない operation が cancel されないように。

52 :
>>49
メインスレッドで実行することを指定しているのだから、逆にマルチスレッドにはなれないだろう。

53 :
>>51に同意

54 :
UIのイベント処理なんかもオペレーションが使われてんだっけ?

55 :
>>54
それは、NSEventな話?

56 :
いや、>>51で意図しない operation が cancel されないように。ってあったから、
意図しないオペレーションってどんなんかなと思って。

57 :
>>56
マルチスレッドな環境では、あるスレッドで実行されているNSOperationの内部で、mainQueueに新しいNSOperationを追加するかもしれない。
だから、ある時点でメイン・スレッドのRunLoopに、どんなNSOparationがスケジュールされているか把握するのは無理。
という意味だと思います。
たとえ、-[NSOparationQueue operations]を呼び出して中身を確認したつもりでも、次の瞬間に新しいNSOperationが増えているかもしれない。

58 :
あぁ、でもそれは、MainQueueにかぎらず、GlobalQueue全般についていえることだね。

59 :
>>36
下の様なコードで、cancelAllOperationsを呼ぶ前はisReadyがYESで、他がNO。
メインキューで処理してる場合、次のループが来た時にはcancelする対象が無くなってるような気がする。
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
self.queue = [NSOperationQueue mainQueue];
Operation *op = [[[Operation alloc] init] autorelease];
[self.queue addOperation:op];
op = [[[Operation alloc] init] autorelease];
[self.queue addOperation:op];
NSArray *ops = [self.queue operations];
for (id op in ops) {
//[op cancel];//個別に呼べば、キャンセルできる。
NSLog(@"isCanceled:%d, isExecuting:%d, isFinished:%d, isConcurrent:%d, isReady:%d",
[op isCancelled], [op isExecuting], [op isFinished], [op isConcurrent], [op isReady]);
}
[self.queue cancelAllOperations];
NSLog(@"cancel");
>>42
実行前か実行中かでcancelが呼ばれたり、呼ばれなかったりするわけではないのでは?
ドキュメントに書いてあるのは、cancelがオペレーションを強制的に止めるわけでは無いことは書いてあるけど、
内部のフラグ更新するとも書いてある。
効果が出ないと書いてあるのは、(実行が?)終了してるものにcancelを送ってもキューに影響は無いと書いてあり、
実行中にcancelされた場合は、isCanceledを自分でチェックして、速やかにmainを終えるようにするのが望ましく、
実行前なら順番が回ってきた時にstartが呼ばれた後、
mainを呼ばずにキューから削除されるはず。(直ぐに効果を及ぼさないってのは、このキューに対してのことを指しているのでは?)
アセンブリを読めないから実装まではわからないけど、
>>51の言うようにそういう仕様なんだろうとは思う。
とはいえoperationsで簡単に回避できるので、個別に確認しろという意思表示なのかな。

60 :
そもそもmainQueueにぶちこんだoperationをまとめてcancelすることが必要になる設計がおかしい

61 :
まぁな

62 :
これで独立できる
売るものはスマートフォンアプリ WEBサイト運営
サーバーはクラウド VPS
電話はスマートフォンSkype
オフィスは地方にプレハブ型の格安高性能オフィスを建て(300万〜500万)
レンタル自習室&シェアオフィスで収入を得ながらそこで開発する
http://tinyurl.com/43xmk7m
http://tinyurl.com/3mopkfy

63 :
スマン。基礎的なことを教えてください。
- (NSString *)getString { //@
NSString *msg = @"temp";
return msg;
}
これでも問題なしで、以下とやってることは同じ?
- (NSString *)getString { //A
NSString *msg = [[NSString alloc] initWithString:@"temp"];
return [msg autorelease];
}
returnすると、中括弧の範囲内で終わるはずのmsgの寿命が、呼び出し元のrun loopに依存するようになるんですよね?
Aは問題ないと感覚的に分かるのですが、@はinitせずに一時オブジェクトをreturnしていることにいまでも違和感が。。

64 :
定数は一時オブジェクトではないので

65 :
char *hoge() { return "hoge";}
と一緒

66 :
>>64-65 サンクス
なるほど。
NSString以外でも、NSData *myDataとかでも同じですよね?
returnによって自動でつくautoreleaseのスコープが伸びるのであって、
一時オブジェクトという感覚を捨てたほうがいい感じでしょうか。

67 :
>>66
なにもかもが違う

68 :
何を聞かれてるのかわからないのに無理に答えなくていいです

69 :
へぇ

70 :
NSString *msg = @"temp";
って
NSString *msg = [[NSString alloc] initWithUTF8String:"temp"] autorelease];
または
NSString *msg = [NSString stringWithUTF8String:"temp"];
とほぼ同義だと思ってるんだが。@"〜"ってNSString用のシンタックスシュガーだろ。

71 :
>>67
違うなら違うで、どのあたりか指摘いただけるとありがたいです。
>returnによって自動でつく
とは@の場合に、msgがautorelease扱いになることを指して書きました。
>autoreleaseのスコープが伸びる
とは、
{
NSString *string = [self getString];
}
のように呼び出し元の有効範囲でautoreleaseされるという意味で書きました。
ちなみにこの辺を参考にして、質問しました
http://stackoverflow.com/questions/2279071/nsstring-returning

72 :
return で autorelease が自動でつくなんて初耳だぞ。
returnは関係ないだろ。

73 :
>>71
autoreleaseっていうのは、あとでreleaseするために
AutoreleasePoolに突っ込むっていう操作だよ。
returnで自動で付いたりしないしスコープとも関係ない。

74 :
63 は任意のメソッドに自動で
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
{//スコープ(笑)
...
}.
[pool release]; が付いていて、return の際にはスコープが伸びる(謎)とか思ってるんじゃ無かろうか。

75 :
>>70
@"〜" は CFSTR("〜") と等価みたいだよ。

76 :
伸びるって表現するならスコープじゃなくてライフサイクルでしょ。

77 :
スコープに対してエクステントっていうんだぜ

78 :
>>75
そうなんだ。@"〜"はautoreleaseされないんだな。勉強になった。

79 :
自分が考え違いをしていたのだけなんとなく分かってきました。
>>72-73
>returnで自動で付いたりしないしスコープとも関係ない。
はい。
>>74
>return の際にはスコープが伸びる(謎)とか思ってるんじゃ無かろうか。
似たようなことを思ってました。
まだ分かってないんですけど、下の@Aは両方とも問題なく使えますか?
- (id)getData { //@
NSData *data = [NSData dataWithContentsOfURL:[NSURL URLWithString:@"http://hoge/hoge.xml"]];
return data;
}
- (id)getData { //A
NSData *data = [[[NSData alloc] initWithContentsOfURL:[NSURL URLWithString:@"http://hoge/hoge.xml"]] autorelease];
return data;
}
呼び出すときの有効範囲は中括弧内ですよね?
{
NSData *data = [self getData];
}

80 :
何を聞きたいのかがよく分らんな。
まず、スタックとヒープの違い、オブジェクトのオーナーシップ、
メインループとAutoreleasePoolの関係を理解しれ。

81 :
>>79
@とAは等価。
@は予めautoreleaseされたオブジェクトをdataに受け取ってる。
Aは自分で生成してautoreleaseしてる。
getDataが返したオブジェクトの有効範囲という意味なら中括弧は無関係。
どこかで現在のAutoreleasePoolが開放されるまでは生きてる。
たぶんフレームワークに制御を戻すまで。

82 :
>>79
AppKit とかが AutoreleasePool 作ってるのを、
言語レベルで勝手に AutoreleasePool で括られてると勘違いしてるようだが、それは違う。

83 :
変数のスコープと、オブジェクトのライフサイクルがごっちゃになってる気がするな。
{
 NSData *data = [self getData];
}
は、dataという変数のスコープは中括弧内に限定される(中括弧の外で参照しようとしても、
コンパイルが通らない)が、[self getData]から返された実体が実際に破棄されるのは、
次のループのサイクルに戻ってAutoreleasePoolが中身を破棄する時でしょ。 
autoreleaseした時点で、AutoreleasePoolに登録されている。
基本的にスコープとオブジェクトのライフサイクルは関係ない。スコープを抜けるときに
自動的にreleaseされることもない。
C++でローカルで宣言したオブジェクトがスコープを抜ける時に呼ばれるデストラクタと
ごっちゃになってないか。どっちかっつうと、allocとreleaseの関係は、C++のnewとdelete
に近い。でもC++のオブジェクトは参照カウンタによる管理ではないけど。最近のC++は
よく知らないが。

84 :
じゃあ、混乱させよう
今のMac OS Xでの実装では
- (NSString *)hoge { return @"hoge";}
- (NSString *)fuga { return [NSString stringWithString:@"hoge"];}
で返されるものは同じインスタンス。

85 :
みなさんの説明で、ようやく理解できてきたと思います。
スタックありきで考えていました。すんません。自分がスタックと考えていたもの全てヒープなんですね。
>>79の@がひっかかっていた理由が、
スタックに制限されると誤解していたので、スコープで理屈がつくよう自分理論を作ってました。
ありがとうございました。いやマジで。

86 :
>>84
つまり、クラスクラスタの為せる技ってこと?

87 :
>>86
+ (NSString*) stringWithString:(NSString*)s { return s; }
っていう実装になってる事に加えて、
コンパイラが同じ内容の文字列定数をひとつにまとめるようになってる
っていう事では?

88 :
いやこんな風かな?
+ (NSString*) stringWithString:(NSString*)s { return [s autorelease]; }

89 :
あれなんか違いそう

90 :
NSString *s1 = @"hoge";
NSString *s2 = [NSString stringWithString:@"hoge"];
NSString *s3 = [NSMutableString stringWithString:@"hgoe"];
NSString *s4 = [NSString stringWithString:s3];
NSString *s5 = [NSString stringWithString:s4];
NSLog(@"%p, %p, %p, %p, %p", s1, s2, s3, s4, s5);
0x100002058, 0x100002058, 0x10054f3f0, 0x10054f450, 0x10054f450

91 :
へー [NSString stringWithString:@"hoge"] も
autorelease されないんだな。
他の[NSString stringWith〜]はautoreleaseされるのに。
奥が深いというか、的というか。 黒魔術の一端を垣間見た気がした。

92 :
されないってなんだよ。release に意味がないだけ

93 :
あぁ定数だから、関係ないのか。

94 :
定数はとにかく使いまわされるっていう事だな。

95 :
つうことはあれか、ソース内に@"〜"の記述が増えれば増えるほど
それが一時的な用途であったにせよ、メモリを圧迫するってことか。

96 :
でもリードオンリのページに置かれてプロセス間で共有されるだろうから、
同時にいくつも起動するプログラムなら節約になりそう。

97 :
>>95
> 容量の初期値は 2500。
http://hmdt.jp/core/string/const.html

98 :
それは文字列の内容が同じ場合でそ

99 :
>>97
あぁつうことは、多少@"〜"が多かろうが少なかろうが、
その領域の容量は予め決まっているから、メモリ的には
あまり関係ないっつうことか。

100read 1read
1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼
・ 次のスレ
54: JavaScriptスレ (554)
55: Git 3 (910)
56: Rubyについて Part46 (81)
57: 圧縮・復元 相談室 (873)