11/07/31 15:43:00.85
>>149
そんなことより、Objective-Cのメモリ管理を
効率よく管理する方法を知ってるならぜひご教授願いたい。
151:名無しさん＠お腹いっぱい。
11/07/31 15:45:44.88
工作員がそんな知識持ってるわけないだろw
152:名無しさん＠お腹いっぱい。
11/07/31 15:49:17.64
>>150
まず、参照されてるかされてないかを調べろ
153:名無しさん＠お腹いっぱい。
11/07/31 15:51:26.26
URLﾘﾝｸ(cdn-ak.f.st-hatena.com)
154:名無しさん＠お腹いっぱい。
11/07/31 15:51:47.75
>>151
Apple大好き人間で、きっと昔からMacでCocoaの開発もバリバリやってて、
Objective-Cのことももちろん熟知してて、
iOS開発からObjective-Cに触った俺のような新参が知らないような
あのクソ難解なメモリ管理の手間を打破する目からうろこが落ちるような
そんな方法を知っているというわずかな可能性にかけてみたんだ。
>>152
コード中でインスタンスの参照カウントを見るのはAppleが非推奨にしてたと思った。
155:名無しさん＠お腹いっぱい。
11/07/31 15:53:51.72
retainした分、releaseすれば良いだけだが
156:名無しさん＠お腹いっぱい。
11/07/31 15:59:48.38
>>155
コンビニエンスコンストラクタとautoreleaseの存在とか、
あとxibの変数はコード上ではretainしてないのに、
開発者の責任でreleaseしなきゃならなかったりとそう単純でもない。
>>153
InstrumentsがなきゃZombie探しができない
157:名無しさん＠お腹いっぱい。
11/07/31 16:08:08.71
autoreleaseが分かってないだけ
ドキュメントを読んでないだけ
158:名無しさん＠お腹いっぱい。
11/07/31 16:11:04.18
>>157
もう少し詳しく。
159:名無しさん＠お腹いっぱい。
11/07/31 18:20:51.25
>>148
VBでどや顏かよ？！
マジうける、ワロタ。
160:名無しさん＠お腹いっぱい。
11/07/31 18:34:59.85
>>159
そんなことより>>157について詳しく
161:名無しさん＠お腹いっぱい。
11/07/31 21:16:42.07
GCマンセーとかｗ
ドンだけヘボグラマーなんだよｗ
162:名無しさん＠お腹いっぱい。
11/07/31 22:09:47.59
>>161
人のことを馬鹿にする以前にそもそもお前、Xcodeの使い方すら知らないじゃん。
163:名無しさん＠お腹いっぱい。
11/07/31 23:50:45.91
Apple製品が大好きそうな連中が多そうな板の割りに
踏み込んだ話になると煽りしか出てこない。
164:名無しさん＠お腹いっぱい。
11/08/01 00:36:24.03
>>162
都合の良い暗愚に俺を重ねて悦に浸ってるのか？ 小さいなｗ
165:名無しさん＠お腹いっぱい。
11/08/01 01:11:29.72
>>164
>>157の言う「autoreleaseが分かってない」ってのがつまりどういうことなのか代わりに解説してくれないか。
あるいは、Objective-Cのような参照カウント方式でのうまい管理方法。
166:名無しさん＠お腹いっぱい。
11/08/01 01:21:20.37
クラスは理解できてるんだよね？
で使わなくなるタイミングがわからないってこと？
167:名無しさん＠お腹いっぱい。
11/08/01 07:38:46.60
>>165
代価を払ってくれるのなら考えなくもないな。 -> 愚図へのレクチャーｗ
というか……うん、色々な意味で……ｗ
168:名無しさん＠お腹いっぱい。
11/08/01 20:36:47.07
>>165
旧VBは、それをかなりの部分解決しているね。
169:名無しさん＠お腹いっぱい。
11/08/02 16:23:37.66
autorelease理解出来ない人用の仕組みが秋に出るから、待ってなよ。1万払うか。
170:名無しさん＠お腹いっぱい。
11/08/02 18:45:27.16
VBじゃ、iPhoneアプリ作れないからなあ。
171:名無しさん＠お腹いっぱい。
11/08/02 19:05:36.49
ぶぶ、VB…
172:名無しさん＠お腹いっぱい。
11/08/02 19:07:15.17
？りぶり
173:名無しさん＠お腹いっぱい。
11/08/02 19:18:19.36
VBﾜﾛﾀ
174:名無しさん＠お腹いっぱい。
11/08/02 19:29:30.59
>>169
URLﾘﾝｸ(www.friendpaste.com)
こういう場合とかプロジェクトの規模が大きくなってくると厄介じゃね？
こういうミスを出さないうまい方法ってある？
175:名無しさん＠お腹いっぱい。
11/08/02 20:12:47.90
プロジェクトの規模が大きくなっても
設計が間違ってなくて、部分部分でミスしなければしっかり動く。
逆に設計で間違ってる奴、部分でミスする奴は、何をやっても無駄。
176:名無しさん＠お腹いっぱい。
11/08/02 20:35:28.07
>>175
お前、おかしなこと言ってるぞｗ
177:名無しさん＠お腹いっぱい。
11/08/02 21:28:06.77
池沼発言はたいていMS信者wwwww
178:名無しさん＠お腹いっぱい。
11/08/02 21:29:38.74
設計も間違ってなくて、部分部分も間違ってなきゃそりゃしっかり動くだろーよｗ
179:名無しさん＠お腹いっぱい。
11/08/02 21:54:05.35
Windowsは「なんとなく」でアプリが動いてしまうからいけないんだよ
だからいつまでたってもエレガントさに欠けるしマルウェアが蔓延る
×codeの洗礼を受けて生き残った者だけに開発が許される
それがiOSワールドの調和と発展に繋がる王道なのです
180:名無しさん＠お腹いっぱい。
11/08/02 21:56:36.26
>>179
>>174のコードもコンパイル通るし、実行も出来るぞ。
だから検知が難しいので「どうしたらいい？」って話なんだと思うが。
181:名無しさん＠お腹いっぱい。
11/08/02 23:52:24.68
Android最大の失態はNDKだな。
パフォーマンス出すにはJNIするしかない→機種依存地獄スタート。
Appleのように自社プロダクト専用OS、互換機無しならまだしもマルチベンダでコレはマズい。
MSのアプリ層を.Net Frameworkで縛るのは正解だと思う。
182:名無しさん＠お腹いっぱい。
11/08/02 23:52:58.63
Android最大の失態はNDKだな。
パフォーマンス出すにはJNIするしかない→機種依存地獄スタート。
Appleのように自社プロダクト専用OS、互換機無しならまだしもマルチベンダでコレはマズい。
MSのアプリ層を.Net Frameworkで縛るのは正解だと思う。
183:名無しさん＠お腹いっぱい。
11/08/03 00:00:25.21
NDKはパフォーマンス出すのが目的というより、
機種固有の機能を使用するために使われてる感じじゃね。
184:名無しさん＠お腹いっぱい。
11/08/03 00:16:22.66
JAVAの既視感が。
185:名無しさん＠お腹いっぱい。
11/08/03 01:17:50.42
というか、スマートフォンにそんなパフォーマンスが必要なアプリを作るな、っちゅう話だな。
AndroidがJava、iOSがObjective-Cという
決して速度に優れているとはいえないものを採用してるあたり、スマートフォンにはそぐわないな。
186:名無しさん＠お腹いっぱい。
11/08/03 01:36:52.65
>>184
ジャバのデジャバ
187:名無しさん＠お腹いっぱい。
11/08/03 07:51:05.16
JavaはともかくObjective-Cは速度として十分だが。
C++があるって?あんな開発効率の悪い言語使わせるとかどこのキチガイ。
188:名無しさん＠お腹いっぱい。
11/08/03 11:03:39.92
>>187
開発効率で言えばObjective-CもC++も大差ないだろ
189:名無しさん＠お腹いっぱい。
11/08/03 12:13:38.32
>>188
そんなことない。C++の開発効率の悪さはダントツ。
190:名無しさん＠お腹いっぱい。
11/08/03 12:21:49.44
ObjectiveCとC++は、同時期に登場したが、前者はジョブズの支配下のもとだけで使われ、後者はいまや標準中の標準言語。
191:名無しさん＠お腹いっぱい。
11/08/03 19:20:13.53
C++で開発効率が悪いのは、単に理解できてないから
192:名無しさん＠お腹いっぱい。
11/08/03 19:32:47.62
理解するのに多大な労力がかかる言語はクソ言語。
プログラム書いたことないバカだな。
193:名無しさん＠お腹いっぱい。
11/08/03 20:05:14.77
Objective-C ですむ範囲なら、変わらんだろ。
194:名無しさん＠お腹いっぱい。
11/08/03 22:12:25.98
誰か>>174のコードの説明してくれ。
195:名無しさん＠お腹いっぱい。
11/08/04 00:06:13.13
>>192
おっと、Perlの悪口はそこまでだ
196:名無しさん＠お腹いっぱい。
11/08/04 23:05:44.41
>>192
理解に要する労力 ＜＜ 開発に要する労力xPrj数
ささいな労力に拘るのは脳が糞な証拠なんだよ。
197:名無しさん＠お腹いっぱい。
11/08/04 23:31:14.66
Androidはデベロッパーからも見放され始めたか。
198:名無しさん＠お腹いっぱい。
11/08/05 00:01:22.55
Googleの方から見捨てられた台湾のデベロッパー
199:名無しさん＠お腹いっぱい。
11/08/05 15:30:22.09
>>191
それc言語が悪いわけでは無くて
PHPとかJavaとかの特定用途用の言語が優れているから Cの得意分野は言語以上に用途の専門知識が必要 Mpegとか衝突判定とか
Cができても あまり意味が無い
200:名無しさん＠お腹いっぱい。
11/08/05 16:01:08.09
>>165
Autoreleaseにこだわりすぎ
できるだけ 使わない方がいいよ
ただ どうしても解放タイミングが取れない局面が出てくるから その時に使う
ObjectiveCってC++と違って先祖はSmallTalkだから C++の先祖はCだけど
iPhone程度のコード量だと素直に
Char文字列でmalloc使った方が楽だよ
iPhone程度で保守性かんがえちゃダメ
201:名無しさん＠お腹いっぱい。
11/08/05 21:57:57.47
Objective-C は、CのSmalltalk 風糖衣。
202:名無しさん＠お腹いっぱい。
11/08/05 22:10:10.76
だが、Objective-C++のカオスさは異常。
外注に出したらObjC++で上がってきたｗ
203:名無しさん＠お腹いっぱい。
11/08/06 01:45:12.67
>>200
そうはいってもCocoa使ってる以上はautoreleaseは避けられない
>>202
なにその悪夢
204:名無しさん＠お腹いっぱい。
11/08/06 04:19:37.99
>>203
LeopardにはGCがあるし、LionにはARCがあるじゃないか。
205:名無しさん＠お腹いっぱい。
11/08/06 06:03:18.48
>>204
iOSにくるのはいつですか？
206:名無しさん＠お腹いっぱい。
11/08/06 10:56:00.86
>>205
ARCは秋。
207:名無しさん＠お腹いっぱい。
11/08/06 20:24:14.54
>>206
ちょっとまだドキュメントが少ないが便利そうだな。
だが、既存のretainとか使ってるコードと併用できないのはアレだが。
いっそ、MSのC#みたいに新しい言語を作ったらいいんじゃなかろうか。
208:名無しさん＠お腹いっぱい。
11/08/06 22:07:18.29
>>203
いやいや>>165の人はautorelease使わないといけないと思っているとこからスタートしているから 何か変な本でも買ったんだろ
あなたの言うように cocoaやっているとautorelease使わないと解決できない局面ってあるでしょ？
その道を通った人は そもそもautoreleaseの使い道がなんて質問 書かないでしょ？
209:名無しさん＠お腹いっぱい。
11/08/07 01:45:27.19
>>208
>>156に対して>>157が「autoreleaseわかってない」と言い出したのが発端だが、
その>>157が>>156のなにを見てわかってないと言い出したのか、という話じゃないか？
210:名無しさん＠お腹いっぱい。
11/08/07 06:11:22.50
去年の六月私は知人に
「向こう二年間はiPhoneがもっとも優れた端末になるだろ。だが二年後はAndroidの方がシェアとってるだろう。」
と言ってiPhone買わせたんだが、もう二年いけそうだな。
211:名無しさん＠お腹いっぱい。
11/08/07 11:30:51.94
whinPhone7<させるか！！
212:名無しさん＠お腹いっぱい。
11/08/07 13:40:33.20
>>211
そのセリフ、死亡フラグ。
213:名無しさん＠お腹いっぱい。
11/08/07 14:29:46.24
そうか？そのセリフなら
まだ死なない可能性あるだろ
214:名無しさん＠お腹いっぱい。
11/08/07 18:41:01.45
>>209
cプログラマーの俺が通った道だったりする よく考えた結果=気にしない
215:名無しさん＠お腹いっぱい。
11/08/08 13:18:35.75
>>144
GC付けるとメモリ食うんだよ。
もうちょっと実メモリが多い機種にならないと厳しい。
216:名無しさん＠お腹いっぱい。
11/08/09 23:22:28.43
>>210
少なくともiPhone5の内なら十分だと思うよ。
そこから先は知らん。
217:名無しさん＠お腹いっぱい。
11/08/15 01:28:18.57
シェアって言ってもあくまで販売台数であってユーザー数ではない。
2年は使う人の多いiPhoneと半年や1年で買い替えるガラケーやAndroidを比較するのは無理があるよ。
iPhoneを1回買い替える間にAndroidは2～3回も買い替えるわけだ。同じユーザーザー数だとしても2～3倍売れるわな。
でもアプリなどのデベロッパーにとってはユーザー数の方が大事。
販売台数のバブルに気がついたデベロッパーが増えてきたんだろう。
218:名無しさん＠お腹いっぱい。
11/08/15 01:41:14.06
Androidは終わってる
219:名無しさん＠お腹いっぱい。
11/08/15 01:57:19.17
iPhoneユーザーがAndroidユーザーよりアプリをたくさん買う傾向があるとの分析記事を見た覚えがある。
たしかにそれもあるかもしれないが、販売台数=ユーザー数と間違ってAndroidユーザーを過大にして分析していたのかもしれない。
220:名無しさん＠お腹いっぱい。
11/08/15 02:29:44.22
iPhoneの単一ハード
Androidの開発環境
MSの開発バックアップ体制
合体しろ。
221:名無しさん＠お腹いっぱい。
11/08/15 02:44:35.87
iPhoneはアプリを入手するルートが基本的にApp Store一本だから、
着実に金稼ぎしようと思ったら確かにiPhoneだろう。
他にはiOS Dev Enterpriseに参加するか、わざわざiOSデバイスのUDIDを開発者に送りつけて
ipaファイルを送ってもらうかOTA配布するしかない（しかもこれは使用期限がある）。
逆に旧来的なフリーウェアを配布するような感じでアプリを公開したい人にはiPhoneは本当にめんどくさい。
一長一短だな。
222:名無しさん＠お腹いっぱい。
11/08/15 05:58:27.99
Androidはまだ不安定だからな・・・
4.0あたりになったらマシになるだろうか
iOSのApple税とApple検閲もうざいけどね
223:名無しさん＠お腹いっぱい。
11/08/15 07:11:30.59
>>220
Macの単一ハード
Linuxの開発環境
Windowsの開発バックアップ体制
合体できません。
224:名無しさん＠お腹いっぱい。
11/08/15 07:20:10.49
>>221
アプリを作る人と使う人どちらが多いかということだな。
225:名無しさん＠お腹いっぱい。
11/08/22 00:33:24.33
>>220
三身合体！完成、WebOS！
226:名無しさん＠お腹いっぱい。
11/08/22 00:39:46.82
>>225
止めるみたいよ、HPは。
227:名無しさん＠お腹いっぱい。
11/08/22 00:50:56.86
>>225
統一を通り越してハード皆無
開発環境そのものが未完成
どこもサポート放棄
228:名無しさん＠お腹いっぱい。
11/09/20 13:07:49.45
Androidアプリは無料が前提。
有料アプリなんか買う奴は情弱。
229:名無しさん＠お腹いっぱい。
11/09/20 21:03:54.16
自分で作るので無料とか有料とか以前の問題
230:名無しさん＠お腹いっぱい。
11/10/09 21:34:11.14
iOS一択
231:名無しさん＠お腹いっぱい。
11/12/04 12:47:52.57
Windows Phoneは？ｗ