静的ライブラリの作成と利用 - It_lives_vainlyの日記
自称ライブラリアン(ホントか？)としては、ライブラリ開発が行えないと意味がないのです. そんなわけで、そろそろコードも貯まってきたし、xcode でのライブラリ開発とその利用方法について調べてみました. デバッグ用のマクロ設定 まずは、マクロ(プロジェクト定義define)の設定方法をまとめておく. メニューバーから、[プロジェクト] - [プロジェクト設定を編集] とたどり、プロジェクト情報を表示する. [ビルド] タブを選択し、"GCC 4.0 - Preprocessing" の項目にある、 Preprocessor Macros Preprocessor Macros Not Used In Precompiled Headers のいずれかに定数を記入する. 例) 構成 : Debug Preprocessor Macros Not Used In Precompiled Hea
iPhoneデバッグ用のマクロで、クラス名とメソッド名を自動的にログ出力する - 24/7 twenty-four seven
iPhone デバッグ用のマクロ - Windchase #ifdef DEBUG # define LOG(...) NSLog(__VA_ARGS__) # define LOG_CURRENT_METHOD NSLog(NSStringFromSelector(_cmd)) #else # define LOG(...) ; # define LOG_CURRENT_METHOD ; #endif iPhone デバッグ用のマクロ - Windchase このマクロをちょっと変えて、クラス名を自動的に出力するようにしました。 #ifdef DEBUG # define LOG(...) NSLog(__VA_ARGS__) # define LOG_CURRENT_METHOD NSLog(@"%@/%@", NSStringFromClass([self class]), NSSt
Xcodeでのプリプロセッサ定義
#ifdef DEBUG ????NSLog(@"debug"); #endif 上記みたいなコードはデバッグ用に必ず登場すると思いますが、このプリプロセッサの"DEBUG"というのをXcodeのプロジェクト設定で定義する方法がやっとわかったので下記にメモ。 もちろんソース上に #define DEBUG と直接書いてもいいんですが、これだとあまり意味がなくて、DebugビルドでのみDEBUGを有効にし、リリース用のDistributionビルドでは無効にしたい場合、いちいちソースを書き換えないといけません。そういうことしてると、Romlyみたくデバッグ用のビルドがApp Storeに並んでしまいます（ぉ やっべーと思って早速検索してみたら、英語のページでいくつか、ズバリの方法が書いてありました。でもどのページでもBuild設定のOther C Flagsに-DDEBUGと書けばいいとしか
xcodeを256倍使い倒す方法〜プロセスに接続編 | Eudyptes Chrysocome
最近、URLスキーマを使用したアプリケーションを作成しているが、Xcodeから実行したアプリケーションだけしかデバッガを利用できず、URLスキーマで呼び出されたアプリケーションにはデバッガが利用できない。 しかし、handleOpenURLからの処理を追いかけたいケースは頻繁にある。 そのような場合に役に立つ、起動中のアプリケーションにデバッガを後から接続する方法を紹介したい。 フラグを一つ作り、それを利用して無限ループにハメる。 この状態でiPhone(実機)からアプリケーションを起動する。 真っ黒の画面になったら、Xcodeのメニューからプロセスに接続する。 今回は「ProcessAtach」(正しくはAttachです)というプロジェクトを作成しているので、 「実行＞プロセスに接続＞ProcessAtach」を選択する。 接続が完了したら、デバッガの「一時停
【iPhone】メモリ不足時のシミュレートとデバッグ | iphoneアプリで稼げるのか
iPachiで起きていた不具合なのですが、 特定の画面を表示中にメモリ不足に陥り didReceiveMemoryWarningを受け取ると アプリがクラッシュするという問題をついに 解消しました。 didReceiveMemoryWarning後にクラッシュするので メモリ管理でどこかがおかしくなっているのだろうとは 予想がつくのですが、いかんせん貧弱なエラーメッセージの ため、まったく発生元がつかめませんでした。 EXC_BAD_ACCESSとか言われてもさっぱりわからんです。 が、すばらしい記事をみつけました。 NSDebugEnabled これでクラッシュをおこしているオブジェクトの生成場所を 特定できるので、格段にデバッグ効率があがります。 というわけで、エミュレータでのメモリ不足時のシミュレートと デバッグのための設定をまとめます。 エミュレータでのメモリ
EXEC_BAD_ACCESSのデバッグ方法 - Paradigm Shift Design
xcodeでプログラムを書いていると、メモリ管理なぞ忘却のかなたなので、リークしていたり、解放済みのメモリにアクセスしていたりと、問題が多々ある。 xcodeでのデバッグコンソールは、基本的にgdbなので、VisualStudioで開発するようには簡単に問題箇所を見つけ出すことができない。 ポインタに対する不正なアクセスは、大体のところ プログラムはシグナルを受信しました：“EXC_BAD_ACCESS” というメッセージが出るだけで、「どこでそれが起こったのか」についての何の手がかりも与えられない。Breakすらしない。 さすがにこんな状況でデバッグしている人はいないだろうと、検索をかけてみると、 DebuggingAutorelease - CocoaDev NSZombieEnabled - CocoaDev あたりが役に立ちそうである。 とりあえず色々試行錯誤してみたが、NSZom
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Cocoaの日々: +[NSThread callStackSymbols]でコールスタックのダンプ