☆テクニカルQ&A
- ターミナルを起動する。見つからないときはspotlightで「ターミナル」と打ち込んで検索して実行
- 「cpp -dM /dev/null」と打ち込んでEnter。「cpp -dM /dev/null | sort」の方がソートされるので読みやすいかも。
ただ、余り有益なのはなさそう。
コンパイル条件(Device/Simulatorとかアクティブな構成等)を知りたかったのだが。
実Device上かSimulator上かはプログラムで識別できる。
[[UIDevice currentDevice]model]によりNSStringでモデル名が得られるので、これで判別すれば良い。
結論から言えば「外した方が良い」。
動作に影響がないように思われるが、
出力先がNULデバイス相当になるだけで処理そのものは動いていると思われ、
速度とおそらくログを取るためのバッファーメモリも確保されるので、その影響も出る。
DEBUG(デバッグ時)だけNSLog()/printf()を有効にしたいなら、
#define DEBUG // コンパイラオプションに入れてももちろんOK(というか、その方が普通)
//
#ifndef DEBUG
#define NSLog(...)
#define printf(...)
#endif
と書いておけば、基本的にそれぞれの場所でのソース変更は不要である。
プロジェクト名_Prefix.pchというソース内に記述しておけば、全てのソースから暗黙でインクルードされるので楽である。
本当は「アクティブな構成」がDebugかどうかを識別出来るマクロがあると良いのだが、
現在までの所、発見出来ていない。インターネット上にはDEBUGが定義されるような記述もあったが、間違い。
Xcode4ではコンパイルオプションの設定が楽になっているので、デバッグコンパイル時のみ-DDEBUGを設定しておいた方が良いだろう。
なお、NSLog()/Printf()内だけで参照するような変数があるとコンパイラが警告を出すので、
無視するか、その辺りを#ifdef DEBUGで処置しておく。
if () {
NSLog(～);
}
のような処理は、気になるなら同様に処置すればよいが、ほっておいてもコンパイラが最適化で式自体を勝手に削除してくれるはずなので
問題ない。こちらは警告も出ない、はず。
いわゆる組み込み機器におけるソフト開発をしていた人が、iOS上に来た場合、
果たしてその技能が役に立つかどうかを、経験からまとめてみた。
「プログラムを設計する」とか言う、基本的な部分は除く。
また、Web上でのプログラムも除く。
μITRON系からの場合
- 基本的に非力なマシンパワーとRAM上で動くことを信条とし、その量を常に考慮するμITRON上でのプログラムの考え方は、
iOS上でも活かせる。
iOSのマシンパワーやメモリは「ある」ようで「ない」。もっとも、世代を重ねるごと速くなっているので、そのうちノートPCクラスなら追い越すかもしれないが。
- μITRONではプログラムはROM上で動き、ワークとスタックのみRAM上に来る。
従って、プログラムを長くしてでもワークを削減するのが常套手段となるが、
iOSはプログラムも(実行時は)RAM上に置かれるため、両方の兼ね合いで決める必要がある。
- (同じことの繰り返しになるが、)基本的にプログラム実行時にはROMを意識する必要がないので、
定数をROM上に置く意味でのconst命令とかも、無意味である。
- μITRONはOSレベルの処理負荷がきわめて軽いが、iOSはかなり重たいので、それを考慮する必要がある。
- iOSはOSレベルで用意されていることが非常に多いので、極力それを探し出して使った方が良い。
- Objective-CのクラスとCの構造体は似て非なる物である。
- Objective-Cでのポインタの扱いはC上でのそれとかなり異なるが、本質は同じであり、その意識は必須である。
- iOS上のプログラミングは、μITRONに比べかなり規約が強く慣れが必要だが、
Objective-C自体はCの上位互換なので、「うまくすれば」かなりその技術を移行できる。
- iOSにおけるOS内部的なマルチタスク(!=ユーザー操作から見えるマルチタスクではない)はμITRON
とは違いイベントドリブンではないので、プログラムが書いた順番で実行されるとは考えてはいけない。これが意外に重要。
Linux系からの場合
- 最近は組み込み機器にも使われるようになったLinuxだが、所詮はマシンパワーもメモリもPCクラスを
必要とするPC用OSなので、その環境に頼った作り方をしているとだめ。
経験で言えば、μITRONベースとLinuxベースでは、メモリを10倍多く、CPUも10倍速くしないと見かけ上の処理速度は同じにならない。
（μITRONはROMベースでプログラムが動くのでプログラムサイズはROM容量だけ考えれば良いが、
LinuxはROMからブートしても結局プログラムはRAM上に展開しなければならないので、
ROM/RAM共に大きな容量が必要となる。組み込み機器にLinuxなんて、きわめて無駄。)
- 特にメモリについては、iOS上では仮想メモリの考え方はないので、実メモリ搭載量だけで設計する必要がある
- 中間ファイルを作ってと言うのも、記録デバイスがROMである以上速度が望めないし、書き換え回数の制約もあるので
やらない方が良い。
- プログラム・ワーク共にRAM上にあると言う意味では同じ。
- ファイル関係は全く違うと考えた方が良い
- Linux(というUnix上にある)ライブラリはどこまで使えるかわからない
- Linuxのツールに頼るプログラムの組み方をしていると「非常に困ることになる」と思う
他は知らん。
どちらからの場合であっても、iOSというものは、非常に特異な環境であり、
Objective-C、NSクラス、UIKitクラスを始め、覚えることが非常にたくさんあり
それはそれで大きな「山」であることは間違いない。
それでもどちらかと言えば、μITRONからの移行の方が、楽に出来ると思う。
これはある意味「アセンブラを知ってたら、C言語なんて理解するのに何の苦労もない」のと同じで、
プログラム動作の根本というか基本を知っていたら、それより上位の考え方は理解出来るのに近い。
iOS上でも、Web環境上だけでプログラムを組むならLinux上で行うのと大差ないのかもしれないけど、
それはよく知らないので語らない。