Xcode5アプリ日本語化初歩の初歩 [Xcode]

 Xcodeはもう6のベータ版が出ているので、さして5はもういいと成るかもしれませんが、日本語化のために敢て5で説明すると、画像で見る通りでアプリのひな形を日本語に直せます。


Xcodeメインxib日本語化.png


ただ、ネットに今有るような説明の状況ではないようです。これも、ソースコードの日本語化が出来たとしても、アプリ作成でinterface builderを使うと途端にエラーになるので、調べていた時に出て来たのですが、私もXcode5は余使っていなかったので、3.2.6とは大分違っていたのに戸惑いながらやってみました。で思ったのですが日本語に直すのは作りながら最初にやった方が効率が良いんじゃないかと思うのですが、使っている人はどのように使っているのでしょうか。まあこの辺は本や画像でも解りにくいところなので、何度かサンプルで試しながら独歩するしかありません。なのでこれ以降は省略しますが、何度かいじっている間 build ディレクトリとアプリファイルができなくなってしまいました?やり方が悪いのかと何度かやってもダメのようなので、ターミナルからビルドして作ることも出来るようなので、やってみました。$ xcodebuild -target <projectの名前> -configuration Debug (またはRelease)とやるとできるようです。で、これでやると、ビルド中Xcodeが何をやっているか、一目瞭然のようで、かなりなことをしています。これで、ibtoolコマンドを組み合わせるとXcode.appが無くてもビルドできそうですが、参考資料が乏しいので失敗だらけです。また、ローカライズする拡張コマンドには、appleglot があるようで、ダウンロードすれば使えます。なぜコマンドに拘ったかと言うと、Xcodeに内蔵されたInterface Builder からでは、コンパイル済みのライブラリしか受け付けないので、多言語のソースコードのコンパイルのようには行かない事が分かったからです。つまり、リソースもコンパイルしながらアプリをビルドしないと、審問官は許してくれないようです。そこを避けて一部日本語も使えますが、それを探すだけでも今のところ一苦労です。


Xcode6では、Interface Builderが Lang=en だけじゃないものを期待したいところです。


コード日本語化している時の出来事 [Xcode]

 プログラムで日本語を使うのはいいとしても、如何に理解しやすくして、利用するかによってそんなことをしてまで使う意味があるかどうかと、サンプルを色々試していた時です、信じられないことができているのに気付きました。そんな馬鹿な!と思って何度も確かめましたが、実際可能のようです。今回は全部のコードを載せませんが、画像とそのメイン部分を書いておきます。まあ、C++のコードに慣れている人であれば、自分で簡単なコードを作って確かめられますから、別段意地悪には当たらないと思っています。この画像はMac OSX10.9.3のXcode3.2.6のバージョンで試した時の画像です。またサンプルのコードは例によってデーブマークさんのサンプルです。


 時間コード.png


メインの中の関数で外部で日本語化したのは、クラスの時間とその関数群です。このコードの解説はC++の演算子の多重定義の使い方みたいなもので、operatorに言及しているところです。最初日本語部分は、すべて#defineで置き換える程度で考えていたので、そのようにやっていたつもりだったのですが、間違いを直しに直し過ぎて、疲れて来たせいか置き換えていない部分が有るにも関わらず、コンパイルに一応成功したもんだから、気にもしていなかったのですが、ちょっとその部分の表現が可笑しいので直そうと思ったのに、その定義していたつもりの define が有りません。あれれ?状態。これはメインのこの部分です。コード:

//--------------------------------------- メイン

メイン エンジン

始まり

時間 最初の時間(1,10,50) 中終わり

時間 二番目の時間(2,24,20) 中終わり

時間 合計時間 中終わり

最初の時間 ドット 表示関数 中終わり // ターミナルに表示

二番目の時間 ドット 表示関数 中終わり // 同じく

 

標準 から 出力 送信"---------\n"中終わり

合計時間 = 最初の時間 + 二番目の時間 中終わり

合計時間 ドット 表示関数 中終わり // 合計時間を表示

 

標準 から 出力 送信"* 2\n"中終わり // 二倍にするという意味の表示

標準 から 出力 送信"---------\n"中終わり

 

合計時間*=2 中終わり // 実際に二倍にする

合計時間 ドット 表示関数 中終わり // その時間を表示

戻る 0 中終わり

終わり

/***************************************************************************/


の「最初の時間、二番目の時間、合計時間」です。これは英語の部分はどこにもありません。つまり時間クラスがインスタンスとして、日本語のインスタンスを認識したということです。つまり、この方法を使えばわざわざ日本語で定義しなくても、もう日本語が使えるということではないでしょうか。試しているのはこれだけで、ホットニュースとして即上げようと思ったので、もっとテストが必要だとは思いますが、これだけでも私に取っては「たいしたたまげだぁ」です。報告までですけれども、誰かもっと進んだことやってる人いないのかなあ?


Xcode_Objective-C++ [Xcode]

オブジェエムエム.png

 これはXcodeでコードを日本語化した場合、NSLogを使う場合と、C++のcoutを使う場合どちらが見やすく使い勝手が良いかを比較してみた時の、テストです。Objective-C2.0では、自動解放プールから始まり段落終わり迄ですが、iostreamであれば、保管庫から始まり終で終わりで、比較的ストレートで改行してもエラーにならないのですが、@“”の場合は途中で改行するとエラーになってしまうので、@“”を三回使っています。まあ改行しなければ一回で済みますが、コードが見辛くなるのでこうしました。

実際の話、日本語に置き換えると手間が掛かって、かえって煩わしいのですが、あくまでテストであって、ヘッダーファイルの名前を日本語補助車としたのは、理屈がわかった時点、構文の用い方がわかった時点ではずすつもりで、付けています。でも実際やってみないとこれだけの中に知っていないと、エラーになってしまう箇所がいくつか発見できました。それだけでもやってみる価値が私的には有ります。日本語に変えると色(colorSyntax)が無くなってしまうのが残念ですが、それはXcodeが警告やエラーを教えてくれますから、大した気にはならないと思います。

WindowsやLinuxでもできるはずですが、@autoreleasepoolは今現在Macだけなはずですので、前のNSAutoreleasePoolを使うとなると、日本語の部分が更に増えることになります。

このコードをコマンドラインからコンパイルビルドするには、llvm-g++が一番良さそうです。Xcodeはこれを使っているようです。このくらいであれば、g++, c++, clang++でも大した変わらないと思います。このコードはひな形で新規で立ち上げると出てくるコードなので、どこを何に置き換えたは、すぐ分かると思います。

どうでしょう、たまには試してみませんか?


続・C++コードを日本語化する [Xcode]

 これ、続きなのですが今度は楽をしてXcode5.1.1でC++ソースコードを日本語化しました。


C++Xcode2.png


英語の部分は、「” ” : ; , ( ) { } * + - # % & …」「\n」で、つまり演算子の部分だけしませんでした。これは万国共通部分なので、変えてはいけない部分だという認識です。そもそもこれらの演算子は、片言の言葉では表現できない深い働きをするので、それを理解する方が優先です。


この結果は見ての通り、問題なく完了しています。コードの内容はこれ:日本語.h *******


#define 保管庫 std


#define 戻り値 return


#define メイン main


#define 整数宣言 int


#define シーアウト cout


#define 改行 endl


#define 使う using


#define ネーム空間 namespace


#define 汎用型 void


#define 型 short


#define パラメータ param


#define 例題関数 MyFunc


#define クラス class


#define ルート Root


#define パラメータ番号 numParam


#define 番号 num


#define 保護する protected


#define 自在アクセス可 public


#define ベース1 Base1


#define 仮想化 virtual


#define ベース2 Base2


#define 継承する Derived


#define 番号取得 GetNum


#define 新規継承 myDerived


 


****** main.cpp *******


#include "日本語.h"


#include <iostream>


 


//---------------------------------------  ルート


 


クラス ルート


{


保護する:


    番号;


 


自在アクセス可:


    ルート( パラメータ番号 );


};


 


ルート::ルート( パラメータ番号 )


{


番号 = パラメータ番号;



    保管庫::シーアウト << "ルート呼び出しコンストラクタ\n";


}


 


//---------------------------------------  ベース1


 


クラス ベース1 : 自在アクセス可 仮想化 ルート


{


自在アクセス可:


    ベース1();


};


 


ベース1::ベース1() : ルート( 1 )


{


保管庫::シーアウト << "ベース1呼び出しコンストラクタ\n";


}


 


//---------------------------------------  ベース2


 


クラス ベース2 : 自在アクセス可 仮想化 ルート


{


自在アクセス可:


    ベース2();


};


 


ベース2::ベース2() : ルート( 2 )


{


保管庫::シーアウト << "ベース2呼び出しコンストラクタ\n";


}


 


//---------------------------------------  継承する


 


クラス 継承する : 自在アクセス可 ベース1, 自在アクセス可 ベース2


{


自在アクセス可:


    継承する();


    番号取得();


};


 


継承する::継承する() : ルート( 3 )


{


保管庫::シーアウト << "継承元呼び出しコンストラクタ\n";


}


 


継承する::番号取得()


{


戻り値( 番号 );


}


 


//---------------------------------------  メイン()


整数宣言 メイン(整数宣言 argc, const char * argv[])


{



継承する 新規継承;



保管庫::シーアウト << "-------\n"


    << "番号 = " << 新規継承.番号取得();


 


戻り値 0;


}


 


このコードはCodeWarriorのwin95からまた持ち出したものですが、wineで問題なく動く古いコードですけど今でも変わらずコンパイルできます。元々Mac用にも動くコードですから何々に特化した使用にはなっていません。そのようなものは月日が経つと自然に消滅していくものだと思います。


このXcodeを使った時のメリットは、先にヘッダーファイルに置き換えたい英語を定義しておけば、コンパイラーはそれを認識して、間違った語句、ないものを入力した時入力した時点で、赤丸マークで教えてくれます。また見えない日本語の空白などを間違って入力すると、三角黄色印でこれも教えてくれます。今時のIDEは大概この機能はありますけど。


で、いろいろ試して行くとこのやり方では、g++ でもコンパイルできるようでした。これはMacのX11からgeanyで試した時に気付きました。その時の画像:


c++日本語geany.png


つまり、Linuxでも当たり前にコンパイルできるようです。まあこうなればファイルはUSBメモリなんかに保存しなくてもMac側から共有ディレクトリを作っておけばすべてのOSからアクセスできます。今このディスクには6種類のLinuxが入っているので、同じファイルを使えます。ただし、Mac使用時にはLinuxは見ることができないので、あくまでMac側に作っています。


で、実際日本語化してコードが読みやすく理解し易いのかというと、ん~どうでしょうか。私自身はこのコードが何を目的で作られているのか既に知っていいるので、何とも言い難いところではありますが、役立つかどうかは、訳し方の持って行き処なのだと思います。つまり、なるだけ文章として繋がるようになっていれば、そこそこためになるのではないでしょうか。まあ私自身はその醍醐味を探し出した時の感激を味わうしかないのですが、それを依頼形式にしたとすると、また立場は違ってくるのでしょうか。私自身はこれらの挑戦はコードがなくならない限り続くもんだと思っています。


XcodeとCarbon [Xcode]

この間、Emacsなら通常にコンパイルできると言いましたが、どうやら違っていたみたいです。あれはCarbonEmacsのことで、今の新しいEmacsは、universalであり、ターミナルからダウンロードしたバージョンは、24.0であり開発版です。でやはりこれにはXcodeからコンパイルする未開発版が有り、エラーで出来ませんでした。CUDAもそうですが、OpenCV, Emacs…これらは開発途上であり、カーボンで出来ているアプリケーションは、移行期だと言う事なのでしょう。なのでuniversalのEmacsからは、C言語もコンパイルできませんでした。Ruby On Railsも先先迄やっているとおかしなエラーが出て来ます。やはり何かが足りないようです。
勿論開発のiPhoneやiPadなどは、最初からuniversalですから大した心配は無いのですが、元々有ったアプリケーションは、ここが一山超える形です。多分移行が済めば、カーボンは消えるのでしょう。つまり、世界標準の企画であるuniversal bainaryになると言う事でしょうか。
このemacsは、ターミナルからインストールし、コンパイルしてから使っているのですが、もともとアプリ化されているものもあります。
しかしこれには時間がかかりました。直接海外からダウンロードしている事も有り、田舎暮らしの場所では、光通信といえども前のISDN並みの早さで、コンパイルもかなり掛かりました。
それでもって何が変わったのかというと、少し勝手が違って、使いにくくなった反面、64ビットになり実メモリも減ったと言う事でしょうか。確かに起動が前より速くなっています。
他にも便利な面が有るのですが、大きく言って、Lispが扱えると言う事でしょうか。今の所使い道が無いですが。これから色々便利な機能を探すつもりです。で前のemacsは、ゴミ箱に捨て、空にしてしまったので、タイムマシンを使って復活させようと思ったのですが、オリジナルではなく、最新版になってしまい無理でした。

それにしても気になるところが、Mac OSX 10.7 Lionになって、良い情報が中々見つかりません。
Dev Centerを訪ねても、大した情報も無く、Xcode4のサンプルコードも中々出て来ません。
やはり何か問題が有るみたいです。ここはネットで探らないと、不覚を取りそうです。

*補足 emacsを更にいじっていたら、何故か普通にコンパイルできました。勘違いか、再起動したせいか判断がつきません。
nice!(0)  コメント(0)  トラックバック(0) 
共通テーマ:学問

XcodeとOpenCV [Xcode]

eclipseでも、C/C++で開発できるキットがあることを思い出し、早速ダウンロードして日本語化して使ってみると、Xcodeとは打って違います。!!!Hello World!!!でさえバイナリでないとエラーを吐き出します。何故なんだろうと調べていると、OpenCVで作ったinclude, libの利用方法のページにぶつかりました。これはこれでバイナリを利用できてよいのかも知れません。
しかし、このOpenCVはバージョンごとに、使えなくなる可能性があり、これはGNUが開発しているので、馴染みが有りません。この方式はアップルは推奨していないのか、何処にも出て来ません。
GNUというと私は、Emacs.appを使っておりこれを使いこなせば、普通にC/C++ファイルもコンパイルできるので、この方が楽だなと思います。ターミナル版も有りますが、わざわざそれで使う理由も無いので、使っていません。このアプリは拡張子でファイルを認識できるので、今はやりの言語を除けばほとんど、カラー表示してくれ、ファイルの違いごとにメニューも変わり、構文の間違いも探し易いのでは有りますが、Xcodeほどは使い易いとは言えません。下図はEmacsで、コンパイルしたものです。
em1emacs.png
次はターミナルのemacsでファイルを表示したものです。
em2emacs2.png
出来たunix実行ファイルをダブルクリックすれば、
今日は、Cの世界へようこそ!logout

[プロセスが完了しました]と出て来ます。eclipseではこんな簡単な事も最初からつまずき、OpenCVなるものを利用しなければならないと言う事なのでしょうか。でも私はこれには躓きました。言われるままに、Cmake.appで、Xcodeプロジェクトを作りコンパイルすると、問題なく完了しましたと出て来て、11のエラーマークです。
今はバージョンが二つ上であり、古かったのかも知れませんが、pythonファイルの応酬であり、これがまだ開発途上なのかも知れません。OpenCV.frameworkは作る事が出来ましたが、多分Xcodeでは使う事は無いだろうと思っています。これがエラーの図です。

detDetection.cu.png
しかし、驚いた事にcudaファイルを利用しています。このインスタンスは何処からと言うエラーメッセージです。
どこかに無理が有るとしか言いようが有りません。この分野は開発段階であり、アップルには多分リスクが多過ぎて、手が出せないところなのでしょう。MacPortもそれには対応しきれないところが有ります。
pythonがMacから縁遠くなっているので、rubyはどうなのかと思っているのですが、articlesに有るところを見ると、ruby on railsであるようです。なので、MacPortを使って、updateしてみました。$mkdir rubys;cd rubys;mkdir work;rails demoと打つと、usage メッセージです。どうやらコマンドラインを変えたみたいです。つまりこう打たなければならなかったみたいです。
$mkdir rubys;cd rubys;rails new work demoです。さあ次もコマンドラインが違います。同様に、$ruby script/rails serverと打つと、サーバーが動いたみたいです。http://localhost:3000/でアクセスすると、いつもの画面が出て来ました。これは、amazonや楽天のようにホームページで本を売るサンプルなのですが、良く出来ています。かといって私が本屋さんになる気もなく、ただこれからITがどのような方向に動いて行くのか確認するために、参考にしているだけです。

取り合えず、今の開発事情が分かって来ました。私がこの手の開発に興味が有るのは、かつての原子のイメージをコンピュータ上で表したいのですが、大部難しいようです。第一多くの人は、原子をそんな風には思っていないし、自然に対しても同じです。
なので誰彼を参考にする事は出来ません。なので今の所は、あれやこれやで繋いで行こうかなと思っています。
nice!(0)  コメント(0)  トラックバック(0) 
共通テーマ:学問

CUDAとMakefile [Xcode]

NVIDIAのCUDA、OpenCLによる並列処理に依る速度の向上も大事なのが分かりました。しかしここで問題が生じるのではないでしょうか。今パソコンはハ-ド的に64ビットに移行していますし、ソフトも64ビット化していますが、アップルのアクティビティモニタで見ると、まだ64ビット化していないものも有ります。アプリではインターフェースビルダーがあり、一番メモリーを使っているのが、kernel_taskです。カーネルがI/Oを管理しているとすると、CPU、GPUもメモリー管理していると言う事であり、私のパソコンは、CPUはインテル64だとしても、GPUは、512MBしか無く、CUDAコアも32しか有りません。この画像処理は、CPUの処理速度に比べれは、見劣りするのかも知れません。
これから並列処理の開発が進み、良いソフトの製品が出て来る事を予想すれば、自作機が一番良いのかも知れませんが、アップルの場合、タワー型のデスクトップは、MacProしか有りません。ノートブックでは、熱処理の問題が有って、唸るようでは使いづらいと思います。勿論ノートの場合は、適材適所で使うしか無いでしょうけれども。

NVIDIAで提供しているこれらGPUの製品群は、上位の方では、40万円から有りとても買う気にはなれない価格では有りますが、仕事上使う人もいるのでしょう。
それにしても、このkernel_taskは、何をどうしているのか、使っているうち100メガも増えて来ます。ウ〜気になる。

ところで、NVIDIAが用意してくれている、アップル用のCUDAのサンプルはまだないようです。
Windows, Linuxはあるようですが、少々のコマンドラインと考えさせられるようなファイルとライブラリ群です。コマンドには、manページもまだ有りません。また、Developer > GPU ComputingのC言語用と、OpenCL用は比較できるように、同じものが作られています。これらのサンプルは、独自のライブラリで出来ているので、アップルのOpenCLとは若干違って来るみたいです。また、最大の違いは、Xcodeに移植するのに、どうなんでしょうか。
つまり今の所、Makefileでターミナルから立ち上げる構図であり、正に実験段階といったところでしょうか。このMakeFileの作り方に、今はまっています。色んな書き方も有り、これはどうなのかなと思いきや、CUDAの場合比較的簡単です。この辺も追々攻略したいところです。が、
ここは少し模様眺めに徹したい気がします。

タグ:Cuda GPU
nice!(0)  コメント(0)  トラックバック(0) 
共通テーマ:学問

Xcode(11回目) [Xcode]

NVIDIAが自らのGPUのために開発している、MacOS X用のCUDA ToolKitは、圧巻なのですが、computeprofというアプリケーションは動作するのですが、ターミナルでこれ用のライブラリにパスが通らなく、アクセスできなくてSDKサンプルをコンパイルできません。なので比較も出来なく、意味不明の状況です。何度やっても駄目です。第一何処にインストールされたのか最初分からず、マニュアルも無いので、焦りました。
考えられるのがusr/local/かなと思い探すと有りました。これは、defaults write com.apple.finder AppleShowAllFiles -bool YESで隠しファイルを最初から見れるようにしてあるから良いのですが、この状態でない人なら、どうするのでしょうか。

しかしこれは諦めた方が良さそうです。アップル自体がXcodeでサポートするならいざ知らず、取り合えずclファイルが有れば今の所大丈夫です。

ですがそれならclファイルは、何でコンパイルすれば良いのでしょうか、と言う疑問が生じます。Xcode自体は、clファイルを無視しています。一つでもエラーが有ればアプリケーションは呼ばれません。八方塞がりで悩んだ末、もう一度Developer >GPU Computing > C > bin の中身を見てみると、実行ファイルが少し有ります。ターミナルからmakeコマンドを打ったときエラーが出るので駄目かと思って、諦めたのが大きな間違いでした。src のエラーファイルをゴミ箱に捨てたら、全てビルド完了と出て来ました。これはこのコマンドを実行したとき出て来たものです。
./deviceQuery Starting...

CUDA Device Query (Runtime API) version (CUDART static linking)

There is 1 device supporting CUDA

Device 0: "GeForce GT 120"
CUDA Driver Version: 4.0
CUDA Runtime Version: 4.0
CUDA Capability Major revision number: 1
CUDA Capability Minor revision number: 1
Total amount of global memory: 536543232 bytes
Number of multiprocessors: 4
Number of cores: 32
Total amount of constant memory: 65536 bytes
Total amount of shared memory per block: 16384 bytes
Total number of registers available per block: 8192
Warp size: 32
Maximum number of threads per block: 512
Maximum sizes of each dimension of a block: 512 x 512 x 64
Maximum sizes of each dimension of a grid: 65535 x 65535 x 1
Maximum memory pitch: 2147483647 bytes
Texture alignment: 256 bytes
Clock rate: 1.40 GHz
Concurrent copy and execution: Yes
Run time limit on kernels: Yes
Integrated: No
Support host page-locked memory mapping: Yes
Compute mode: Default (multiple host threads can use this device simultaneously)
Concurrent kernel execution: No
Device has ECC support enabled: No

deviceQuery, CUDA Driver = CUDART, CUDA Driver Version = 4.0, CUDA Runtime Version = 4.0, NumDevs = 1, Device = GeForce GT 120


PASSED

Press to Quit... ----------------------------------------------------------- これは、C/C++のファイルだけです。(ターミナルはドラックドロップが出来ますので、移動はその方が早いです。)ではOpenCLのサンプルはどうでしょうか、エラーのソースは捨ててやってみると、全てコンパイルできました。取り敢えず環境が分かって来たので、次回にもっと踏み込んでみたいと思います。
タグ:Cuda
nice!(0)  コメント(0)  トラックバック(0) 
共通テーマ:学問

Xcode(10回目) [Xcode]

アップルのレパード10.5迄は、Developer > Exampleがいっぱい有ったのですが、10.6からほとんど消えてしまい、ネットでダウンロードするしか無くなりました。勿論10.6では動作しなくなったものも多く、中でもJAVAのサンプルは、仕様が大幅に変更されたため、Xcodeからコンパイルできなくなりました。Xcodeには、オーガナイザーと言うものが有り、テンプレートから新規作成 > Java Templetes > Appletといった具合に、ジャバファイルをコンパイルできるようにしてあるのですが、単純なものであればいざ知らず、ブラウザは起動されますが、エラーが出ます。htmlファイルを編集すれば良いのですが、これでは意味が有りません。
JAVA言語は、Sun Microsystemsが開発した、オブジェクト指向としては一早く登場した言語なのですが、アプリケーション開発では、一線から退いた形です。Eclipseと言う手も有るみたいですが、Xcodeとは明らかに環境が違うので、よっぽどでない限り使う気には成りません。ですが、ちょっと触ってみました。
やはり思ったような動作をしてくれないみたいです。ただ日本語化が出来ていて、エラーも親切に日本語で教えてくれます。Xcode4もこの良いところをまねた形跡が有ります。コンパイルする前に、間違いを指摘してくれるのです。でもJAVA言語は今の所諦めた方が良さそうです。

なので、もう一度OpenGL、OpenCLに戻って調べていると、Shaderファイルとか無くてもコンパイルできると言いましたが、もう一つのサンプルを見るとやっと違いが分かりました。ターミナルから実行ファイルを実行する時に読まれるファイルで、これが無いと、エラーで終わってしまう事が分かりました。しかしこれは新たな発見です。JAVAではhtmlファイルから、アプレットを実行する時には、同ディレクトリ内にクラスファイルなどが無いと、又はパスを指定しないとブラウザで表示できないように、アプリケーションが立ち上がらないと言う事でした。しかし、会社が違うのであれば、使用料が掛かるので、自己責任で使って下さいと言う事でしょうか。因にOpenCLはmacの商標のようです。なので、OpenCLで例のごとくネットで検索してみると、有るんですねえ。
これで悩みは有る程度解決なのですが、何と言っても解説がウインドウズ系で、アプリ内でどう使われるのかの、説明が有りません。サンプルで拡張子のclファイルを読めば一目瞭然なのですが、大約するとマルチコアCPU・GPUの並列処理のための言語のようです。しかしMacの場合shaderファイルと併用であり、この手の解説が殆ど皆無です。と言うか、最新の正式版が2010年6月11日となるとまだまだこれからのフレームワークということでしょうか。
アップルでは他にもグラフィック関係のフレームワークはたくさん用意しています。なのでこの手の開発は、やはりMacなのではないでしょうか。
私も詳しい事は分かりませんが、シミュレーションする場合、これを避けては通れません。
頭の整理が付いたら、またアップします。
タグ:OpenGL OpenCL
nice!(0)  コメント(0)  トラックバック(0) 
共通テーマ:学問

Xcode(9回目) [Xcode]


今回は少し懐かしのサンプルです。SonOfSillyBallsと言う名で、昔ながらのMacファンであれば、分かるのではないでしょうか。Think Cのプログラムソフトにも有ったはずです。もう昔なので記憶も定かではないのですが、もはやそれを動かす機種は、iBookしか持ち合わせていません。このCファイルはこんな感じです。

 #

 # Simple Color QuickDraw Sample Application

 #

 # SillyBalls

 #

 # SillyBalls.c - C Source

 #

 # Copyright 1988 Apple Computer, Inc.

 # All rights reserved.

 #

 # Versions: 1.0 8/88

 #

 # Components: SillyBalls.c August 1, 1988

 # SillyBalls.make August 1, 1988

 #

 # This is a very simple sample program that demonstrates how to use Color 

 # QuickDraw.  It is about two pages of code, and does nothing more than open

 # a color window and draw randomly colored ovals in the window.

 #

 # The purpose is to show how to get some initial results with Color QuickDraw.

 # It is a complete program and is very short to be as clear as possible.

 #

 # It does not have an Event Loop.  It is not fully functional in the sense that

 # it does not do all the things you would expect a well behaved Macintosh 

 # program to do, like size the window naturally, have an event loop, use menus, 

 # etc.

 #

 # See Sample and TESample for the general structure and MultiFinder techniques that

 # we recommend that you use when building a new application.

 #

 ------------------------------------------------------------------------------*/


//

// Modified for Symantec C++ on 30Nov93 by Tree to test the development

// release of the PowerPC compiler. Uses the Universal headers off E.T.O. #12.

//

// Changes required:

//

//    1. Added return value for main()

//


#include <Types.h>

#include <Memory.h>

#include <Quickdraw.h>

#include <Fonts.h>

#include <Events.h>

#include <Menus.h>

#include <Windows.h>

#include <TextEdit.h>

#include <Dialogs.h>

#include <OSUtils.h>

#include <ToolUtils.h>

#include <SegLoad.h>


/* Constants */

#define BallWidth 20

#define BallHeight 20

#define UdiSize 8 /* Size of text in each ball */


/* Globals */

Rect windRect;


/* Prototypes */

void Initialize(QDGlobals *);

void stub(void);

void NewBall(void);


/* 

 ** Main body of program SillyBalls

 */


main()

{

QDGlobals qd;

Initialize(&qd);

#if 0

DebugStr("¥pループの準備完了。");

#endif

do {

NewBall();

} while (!Button());

return 0;

}


/* 

 ** Initialize everything for the program, make sure we can run

 */

void Initialize(QDGlobals *qd)

{

WindowPtr mainPtr;

OSErr error;

SysEnvRec theWorld;

/*

** Test the computer to be sure we can do color.  

** If not we would crash, which would be bad.  

** If we cant run, just beep and exit.

*/

error = SysEnvirons(1, &theWorld);

if (theWorld.hasColorQD == false) {

SysBeep(50);

ExitToShell(); /* If no color QD, we must leave. */

}

InitGraf(&qd->thePort);

InitFonts();

InitWindows();

InitMenus();

TEInit();

InitDialogs(0L);

InitCursor();

/*

** To make the Random sequences truly random, we need to make the seed start

** at a different number.  An easy way to do this is to put the current time

** and date into the seed.  Since it is always incrementing the starting seed

** will always be different.  Dont for each call of Random, or the sequence

** will no longer be random.  Only needed once, here in the init.

*/

GetDateTime((unsigned long*) &qd->randSeed);

/*

** Make a new window for drawing in, and it must be a color window.  

** The window is full screen size, made smaller to make it more visible.

*/

windRect = qd->screenBits.bounds;

InsetRect(&windRect, 50, 50);

mainPtr = NewCWindow(nil, &windRect, "¥pUdi Land", true, documentProc, 

(WindowPtr) -1, false, 0);

SetPort(mainPtr); /* set window to current graf port */

TextSize(UdiSize); /* smaller font for drawing. */

}


void stub()

{}


/* 

 ** NewBall: make another ball in the window at a random location and color.

 */

void NewBall()

{

RGBColor ballColor;

Rect ballRect;

long int newLeft,

newTop;

/* 

** Make a random new color for the ball.

*/

ballColor.red   = Random();

ballColor.green = Random();

ballColor.blue  = Random();

/* 

** Set that color as the new color to use in drawing.

*/

RGBForeColor (&ballColor);

/*

** Make a Random new location for the ball, that is normalized to the window size.  

** This makes the Integer from Random into a number that is 0..windRect.bottom

** and 0..windRect.right.  They are normalized so that we don't spend most of our

** time drawing in places outside of the window.

*/

newTop = Random(); newLeft = Random();

newTop = ((newTop+32767) * windRect.bottom) / 65536;

newLeft = ((newLeft+32767) * windRect.right) / 65536;

SetRect(&ballRect, newLeft, newTop, newLeft+BallWidth, newTop+BallHeight);

/*

** Move pen to the new location, and paint the colored ball.

*/

MoveTo(newLeft, newTop);

PaintOval (&ballRect);

/*

** Move the pen to the middle of the new ball position, for the text

*/

MoveTo(ballRect.left + BallWidth/2 - UdiSize, 

  ballRect.top + BallHeight/2 + UdiSize/2 -1);

/*

** Invert the color and draw the text there.  This wont look quite right in 1 bit

** mode, since the foreground and background colors will be the same.

** Color QuickDraw special cases this to not invert the color, to avoid

** invisible drawing.

*/

InvertColor(&ballColor); 

RGBForeColor(&ballColor);

DrawString("¥pウディー");

}

勿論もうこれに使っているヘッダーファイルは、Xcodeにはないのでコンパイルはできません。これはSymantecがPowerPCのために、Think Cにもあったサンプルを1993年に編集した事になっていますが、元はApple Inc.の著作権で1988年になっています。今迄気にもしていなかったのですが、Windows95が出るより7年も前の話です。日本では、’パーソナルコンピュータとは何者だ’の世界で、市販では市場に出回ってはいませんでした。

知りませんでしたね。因に私が買ったソフトに掲載されているMacOSは、漢字Talk7.5です。iBookの入っているOSはご覧の通り、

                                   OSOSv.png

この時は、MacOS9がエミュレートで十分動作していて、それなりに良かったのですが、後は次第に消え行く運命を辿ってしまいました。と言うよりハードもCPUがインテルに変わり、値段も安くなり、操作性も向上して来ました。10.6になってから格段と良くはなっているのですが、多くのユーザは、職場ではウインドウズです。つまり、煩わしい操作の切り替えよりも、実務をこなせるソフトの開発には舵を切らないようです(それがスティーブジョブスの意向なんですかねえ)。私の使う操作は、10.5から変わらなくなりました。使いきれないのです。10.7に移行したところで、使わないでしょう。

昔のMacのように、進むべき道がかろうじてあった時代であれば、未来のために投資する気持ちで買う気持ちにもなりますが、Appleよどこへ行くといった感じです。


話が大分脇道にそれましたが、上のコードを見た感じ、OpenGLのCのコードに似ています。では、Objective-Cの場合はどうなんでしょうか。このバージョンは三つのアクションが付いているので一概に比較は出来ませんが、長いし、使い方がやはりこっています。それだけ厳格になったと言えばそれまでですが、~?

ここでの注目点は、@property@synthesize からの変数のアクセスです。これはObjective-C2.0から出て来たものですが、Delegateファイル内では、もっぱらself.sillyBallView.runningといった使われ方ですが、SillyBallsView内では、&self->ballInterval_のような使われ方です。こういった使い方は初めて見ます。これはC言語で言うところの構造体へのアクセスであり、アドレスを指定した変数渡しです。当然これでコンパイルでき動作するところを見ると、可能のようです。では、構造体と言えるものはどれでしょうか。@property@synthesizeで宣言した変数しか見当たりません。しかしこれは問題です。だったら初めから構造体で宣言すれば?と思ったので、構造体宣言をフレームワークから探してみると、そうは有りませんが、@interface{ }ないで宣言されていて、大概がFlagsでunsigned int hasCustomColor:1;といった感じです。この使われ方は、C言語ではないし、ユーザが自分のコードの中に使う事は滅多になく、もっぱらコンパイル時に、動的にプロセスに組み込まれるみたいです。

この辺からC言語とは神髄が違って来るみたいです。

@interface AppDelegate : NSObject

{

    BOOL                running_;

    double              ballRate_;

    

    NSWindow *          window_;

    SillyBallsView *    sillyBallView_;

    NSSlider *          sliderView_;

    NSTextField *       textView_;

}

これを見ると、どこか構造体の宣言にも似ています。しかしこのデータメンバーに直接アクセスする事は出来ません。なので、プロパティ、シンセサイズでアクセス可能にしています。こうする事に依って、クラスとしてコンパイラーが認識して、オブジェクトが設定されると考えた方が良さそうです。これは実際コードで色々試さないと、分かりにくいところです。コード上正しくても、コンパイラーが認識できなければ、無視して、エラー無しでデバッグに落ちる事しばしばです。ここでは、xibファイルを意識してコードを組み立てなければなりません。アウトレットやアクションの使い方は、色んなサンプルを見て覚えるのが近道だと思います。

このサンプルの留意点はこんなところでしょうか。



タグ:XCode
nice!(0)  コメント(0)  トラックバック(0) 
共通テーマ:学問

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。