Objective-C [ObjC pa ..
369:デフォルトの名無しさん
08/07/08 00:00:35
>>368
> alloc、init、finalizeは、普通にObjective-C言語の一部として定義されてるメソッドです。
日本語でおk
370:デフォルトの名無しさん
08/07/08 00:47:08
↑おまえはまずは日本語を勉強した方がいいんじゃないか？
371:デフォルトの名無しさん
08/07/08 08:13:14
364 ですが、嘘を言ってすいませんでした。
どこまでが Obj-C 2.0の機能かというのは、
Apple 版 GCC 以外に Obj-C 2.0 をまともにコンパイルできるのがないので考えても仕方がないのでは？
NSFastEnumeration とかはどう思うの？
372:デフォルトの名無しさん
08/07/08 08:45:22
嘘つきはお断り
373:デフォルトの名無しさん
08/07/08 18:03:58
alloc init が Objective-C言語の一部として定義されてるメソッドと断定している理由は何？
374:デフォルトの名無しさん
08/07/08 21:07:27
NSFastEnumerationは、それに関連して文法が拡張されてるぐらいだから、ObjC2.0の一部なんじゃない？
あと、インスタンスを生成するときは、[[MyClass alloc] init]ってやるって、決まってるし。これは、Cocoaだからじゃなくて、ObjCだからそういう仕様になってるんです。これらのメソッドは、Objectクラスにも定義されてるし。
>Apple 版 GCC 以外に Obj-C 2.0 をまともにコンパイルできるのがないので考えても仕方がないのでは？
そういう部分もあるけど、Foudationフレームワーク全体がObjCだっていう訳でもないと思うけど。
375:デフォルトの名無しさん
08/07/08 22:08:59
>>373
それ外したら言語機能の範囲内でオブジェクトが作れなくなってしまわないか。
ANSI-Cみたいな規格がなくて(ないの？)断定は出来んのかもしれんが、alloc
init が言語の一部じゃないってのは考えにくいなぁ。それとも俺が無知なだけ
で言語が定める正統なオブジェクトの作り方が他にあるのかな。
376:デフォルトの名無しさん
08/07/08 22:24:16
Mac OSXのオブジェクトは、フツーにC言語なCore Foundationで表現されてたかと。
ANSIとかどうでもいいが、規格ある言語をラップして表現する方向で統一してるね
CF自体はwin/linux/fBSDにportingされてるし、Darwinコードにも各OSへのコントリビュータの名前が並んでたり
Cocoaもまた、結構CFをまんまラップして表現してるんだよね
Carbonとの基盤統一のためにやってる事なんだろうけど。
今のOSXではalloc/initは本質的にどっちで表現されてんだろな
377:デフォルトの名無しさん
08/07/08 22:44:33
OSObjectは?
378:デフォルトの名無しさん
08/07/08 22:52:08
>>374
そういう曖昧なものを定義としていいの？
>>376
それは実装の話で、規格の話じゃないでしょ？
>>375
だから、Obj-Cではそれすら実装依存なんでしょ？
379:デフォルトの名無しさん
08/07/08 23:03:30
>>378
>だから、Obj-Cではそれすら実装依存なんでしょ？
どのプラットホーム上でも、オブジェクトの生成にはalloc - initを使う。これが言語仕様だから。
逆に、alloc - init以外でオブジェクトを生成する実装ってあるの？
380:デフォルトの名無しさん
08/07/08 23:13:12
>>379
それが言語仕様だってどこに書いてるの？
ほかの実装がないから言語仕様なの？
381:デフォルトの名無しさん
08/07/08 23:39:51
なんだよ、おまえらココアで酔ったか？
382:デフォルトの名無しさん
08/07/08 23:42:10
そもそも言語仕様の規格とかないんだから現存する「特定の実装の言語仕様」しか
語ることができないような… 議論そのものがナンセンスじゃね？
383:デフォルトの名無しさん
08/07/08 23:58:59
しようがねえな
384:デフォルトの名無しさん
08/07/09 00:01:56
ところでこの議論の先には何があるんだ？
385:デフォルトの名無しさん
08/07/09 00:20:13
>>381
多分そうなんだと思う。
別に今更、Obj-CとApple独自の実装を分けて考えろとは思わないけどさ、
＞alloc、init、finalizeは、普通にObjective-C言語の一部として定義されてるメソッドです。
＞逆に、valueForKeyはObjective-Cの一部として定義されていません。
＞一緒にしてはいけません。
とか言われるとちょっと意地悪してみたくなるじゃない？
君こそ一緒にしてるじゃん？て。
あまつさえ、
＞NSFastEnumerationは、それに関連して文法が拡張されてるぐらいだから、ObjC2.0の一部なんじゃない？
＞あと、インスタンスを生成するときは、[[MyClass alloc] init]ってやるって、決まってるし。これは、Cocoaだからじゃなくて、ObjCだからそういう仕様になってるんです。これらのメソッドは、Objectクラスにも定義されてるし。
なんて意味不明な事言い出す始末だし。
普通は規約が改定されたからそれにあわせてAppleはNSFastEnumerationを実装して対応した。
って考えるでしょ。
なんで、一部になっちゃうかな？
分けて考えるなら、徹底して分けて考えろって思う訳よ。
書いてるうちに、先書かれちゃった。
問題はそこなんだけどねw >382
ANSIかISOで管理してるって話も聞くんだけど、全く見当たらないんだな、これが。
URLﾘﾝｸ(developer.apple.com)
これだって、Apple実装を例にしたObjective-Cのお勉強資料だしね。
>>384
[self release]; // 自身の解放？
386:デフォルトの名無しさん
08/07/09 08:01:32
alloc, initで生成と初期化を行うのはただの慣習であってObjCの仕様じゃない。
逆にfinalizeやFast Enumeration系はランタイム側で定義された仕様。
387:デフォルトの名無しさん
08/07/09 08:21:00
ほんとつまんない事にこだわる奴らだな。
タクシーのエンジンの構造や燃料の効率について、なんも知らなくったって、
運転手さんに行き先を言えば望んだ場所に連れて行ってくれるというのに。
388:デフォルトの名無しさん
08/07/09 08:30:09
いや、一応ここ専門板だし。俺はもう寝るけど。
389:デフォルトの名無しさん
08/07/09 08:56:01
>>388
というか、ISO / ECMA 規格がないのにどこまでが言語でどこからがライブラリかという話をしても仕方がないのでは。
390:デフォルトの名無しさん
08/07/09 09:12:05
多分それでFAだろね
それ以上はAppleがどう認識してるか調べるくらいが関の山かと
391:デフォルトの名無しさん
08/07/09 13:01:36
コンパイラが認知する部分は言語仕様
ランタイムが認知する部分はランタイム仕様
コンパイラやランタイムを変えなくても変えられる部分は慣習・規約
392:デフォルトの名無しさん
08/07/09 13:31:57
じゃあ、コンパイラが
@"hogehoge"
でNSStringオブジェクト定数を生成してるわけだから、
NSStringは言語仕様に含まれてるんだ。
NSCFStringだと主張するならNSCFStringもまた言語使用に組み込まれている。
で、まだ続けるの？
もう不可分で良いじゃん。
393:デフォルトの名無しさん
08/07/09 14:09:41
そうだよ。java.lang.StringがJava言語、System.StringがC#と結びついているのと同じ。特別扱い。
394:デフォルトの名無しさん
08/07/09 14:22:09
「@"hogehoge"がNSStringだ」というのは言語仕様
NSStringの具体的な中身はライブラリの仕様
395:デフォルトの名無しさん
08/07/09 14:23:47
じゃあ、コンパイラの不可思議な動作も言語仕様のうちだ。
@"hoge" "fuga" @"hogera";
が正しく連結されたりね。
396:デフォルトの名無しさん
08/07/09 15:01:25
>>391
Obj-C のどこからどこまでが言語仕様かという話をするために、
>コンパイラが認知する部分は言語仕様
というわけだけど、
「コンパイラが認知する部分」は「言語仕様」という定義をしてるのは誰？
397:デフォルトの名無しさん
08/07/09 15:05:08
>>394
>@"hogehoge"がNSStringだ」というのは言語仕様
そうだったのかー。じゃあ GNU実装の gcc -fconstant-string-class オプションでの
文字列リテラルクラスの変更は言語仕様違反ですね…
-fconstant-string-classのデフォルトは NXConstantString だから変更しなくてもやっぱり
言語仕様違反ですか…GNUの実装はひどいですねー
# その言語仕様とやらがどこに存在してるのか知らんけどｗ
398:デフォルトの名無しさん
08/07/09 15:27:08
>>397
それは間違いでしょ？
だって、「コンパイラが認知する部分は言語仕様」とされている訳だから、
Apple拡張されていないgccのコンパイラが認知するものだって言語仕様だよ。
つまりObj-Cの言語仕様はコンパイラの数だけあるってことでしょ。
399:デフォルトの名無しさん
08/07/09 15:30:23
ほんとは実装依存って言うんだろうけど
皮肉に皮肉で返しあってgdgd
400:デフォルトの名無しさん
08/07/09 15:32:58
/ヽ /ヽ
/ ヽ / ヽ
＿＿＿＿＿＿ / ヽ＿＿/ ヽ
| ＿＿＿＿ ／ :::::::::::::::＼
| | /／ ＼ :::::::::::::::|
| | | ● ● ::::::::::::::| ・・・
| | .| :::::::::::::|
| | | （__人__丿 .....:::::::::::::::::::/
| |＿＿＿＿ ヽ .....:::::::::::::::::::::::<
└＿＿＿／￣￣ :::::::::::::::::::::::::|
|＼ | :::::::::::::::::::::::|
＼ ＼ ＼＿＿＿ ::::::::::::::::::::::::|
401:デフォルトの名無しさん
08/07/09 15:44:38
>>398
>コンパイラの数
Obj-CのコンパイラってAppleのgcc,GNUのgccとPOCぐらいだろ
402:デフォルトの名無しさん
08/07/09 15:47:38
>>401
それに何の問題が？
403:デフォルトの名無しさん
08/07/09 16:44:53
しょうもない話題をいつまでひっぱってんだ
404:デフォルトの名無しさん
08/07/09 18:45:14
alloc と init がObjective-C 言語仕様に規定されているという人がいるからしようがない。
もしくは、
Objective-Cの言語仕様はそのコンパイラが規定すると言い張る人がいるからどうしようもない。
Objective-Cには公開された言語仕様が存在しない。
ってことをどうして認めようとはしないの？
それとも僕はとんでもない勘違いをしていて、
これこれは言語仕様と断言している人たちは、
非公開な言語仕様を閲覧できる立場の人たちなの？
405:デフォルトの名無しさん
08/07/09 19:08:29
標準規格がない言語には言語仕様がないと？
406:デフォルトの名無しさん
08/07/09 20:30:53
さすがにもう飽きてきた。w
>405
じゃあそれ、これこれは言語仕様です。これこれは違います。
って自信満々に言ってる人に言っといて。
標準がないのにそんな自信たっぷりに言われてもねぇ、って。
407:デフォルトの名無しさん
08/07/09 21:23:01
皆さん熱弁を振るってますが、
「どこからが美人でどこまでがブスか。」
という議論に近い不毛なものを感じますた。
以上、通りすがりの私の感想でした。
408:デフォルトの名無しさん
08/07/09 22:37:47
だよな
どこからAPIの機能でどこから言語の規格が議論して何か意味あるのかね。
C++でもAPIがなけりゃ文字列処理もでない屑言語だが
409:デフォルトの名無しさん
08/07/09 23:45:04
>>405
> 標準規格がない言語には言語仕様がないと？
そりゃ標準規格がない言語には、どこまでが標準言語仕様でどこからが標準ライブラリでどこからが独自ライブラリかの違いなんてないだろうよ
アホ？
410:デフォルトの名無しさん
08/07/10 00:14:55
標準ライブラリも含めて言語仕様でしょ
NSObjectがなければ何もできないんだから
411:デフォルトの名無しさん
08/07/10 00:23:09
「仕様」を「規約」と解釈する人と「実装の裏にある本質」と解釈する人が争ってる感じ
412:デフォルトの名無しさん
08/07/10 08:59:06
この流れは…iPhoneのお陰かな。
413:デフォルトの名無しさん
08/07/10 09:03:29
>>410
NS～は「de fact」標準ライブラリです。
414:デフォルトの名無しさん
08/07/10 09:11:29
>>413
de facto ですよ正しい綴りは。
415:デフォルトの名無しさん
08/07/10 09:15:43
>>414
どうも。
416:デフォルトの名無しさん
08/07/10 16:04:21
>>410
objc/Objectじゃだめですか＞＜
417:デフォルトの名無しさん
08/07/10 17:17:44
>>411
仕様は仕様でしょ？
それがあって始めてApple方言とかGNU方言とか言える訳で。
一番近いのは、
URLﾘﾝｸ(developer.apple.com)
これ。文書全体じゃなくてこの章だけね。
>>412
おれは茶化してるだけのCocoaがなかったら死ぬタイプの人間ですｗ
418:デフォルトの名無しさん
08/07/10 17:33:50
URLﾘﾝｸ(developer.apple.com)
こっちもそうだった。
こっちはコンパイラのディレクティブのところにNSStringと明記されてる。
これが要求仕様なのかどうかは不明。
419:デフォルトの名無しさん
08/07/10 17:48:03
アップルは、Objective-CとCocoaを別々に開発している。
当然、仕様も別々に存在している。
特に、Objective-Cに関しては、Darwinプロジェクトの中で開発されているのだから、どこまでがObjective-Cなのかは明確になっているんじゃないのか？
Objective-Cの仕様に合わせてCocoaを作る事はできても、Cocoaの仕様に合わせてObjective-Cを作ることはできないのだから。
420:デフォルトの名無しさん
08/07/10 23:13:07
>>419
アップルにしてみればObjective-Cの言語仕様とCocoaライブラリの境界をはっきりさせなくても別に困りはしないでしょ。OpenDarwinも終わっちゃったし。
>Objective-Cの仕様に合わせてCocoaを作る事はできても、Cocoaの仕様に合わせてObjective-Cを作ることはできないのだから。
Objective-C文字列リテラル、メッセージの転送、例外処理、@synchronized、ObjC 2.0のプロパティ、高速列挙。Cocoaを前提とした機能はずいぶんと追加されてるよ。
421:デフォルトの名無しさん
08/07/10 23:27:38
>当然、仕様も別々に存在している。
その自信はどこから来るわけ？
Apple 社員で社外秘の仕様をみられるというの？
社外秘の仕様があるばあいは社外の人には仕様はあることになるのないことになるの？
422:デフォルトの名無しさん
08/07/11 00:18:39
>>420
> アップルにしてみればObjective-Cの言語仕様とCocoaライブラリの境界をはっきりさせなくても別に困りはしないでしょ。
困ると思うよ。
「分割して統治せよ」って言葉聞いた事あるよね？
大規模なシステムを設計する場合は、全体が一枚岩のようになると、とても保守が面倒になるので、複数のコンポーネントに分割して管理するものなんだよ。
Cocoaだって、あえてAppKitとFoundationに分かれているのもそういった理由があるからだと思うよ。
NSStringがFoundation側で定義されていて、-[NSString drawAtPoint:withAttributes:]があえてAppKit側にカテゴリーを使って定義してあるのも、そういった理由があるからでしょう。
Objective-Cも同じようにCocoaから分割されていると思う。
423:デフォルトの名無しさん
08/07/11 00:48:59
Appleの場合、仕様はJobs(笑)ってのもあるから。
最近、GPGPUに興味を持ってるみたいだから、「Snow Leopard」公開後は新しい言語
「OpenCL（open computing language）」を使用するように仕様が変更されるかもしれない。
424:デフォルトの名無しさん
08/07/11 01:08:20
Rubyの仕様がまつもとひろゆきみたいなもんだね
425:デフォルトの名無しさん
08/07/11 02:25:22
Jobs本人がOpenCLについてなんか言及してるん？
426:デフォルトの名無しさん
08/07/11 02:26:24
>>422
システム全部大雑把でいいなんて書いてない。あくまで言語仕様とライブラリの境目の話。拡大解釈しないでおくれ。
>Objective-Cも同じようにCocoaから分割されていると思う。
文字列リテラルとかプロパティとか高速列挙とか、いろいろ挙げたのは無視？
Objective-Cの権利は全部アップルが持ってるし、自社OSのためにコンパイラもランタイムも開発してるんだから、Cocoa前提の機能を言語仕様に含めたほうがアップルにとって楽なこともあるでしょ。
427:デフォルトの名無しさん
08/07/11 07:42:15
文字リテラルもプロパティも高速列挙もCocoaなしで使えるし
428:デフォルトの名無しさん
08/07/11 09:37:12
>>423
>新しい言語
>新しい言語
>新しい言語
>新しい言語
>新しい言語
>新しい言語
>新しい言語
>新しい言語
429:デフォルトの名無しさん
08/07/11 12:05:41
まずは自分でコンパイラ程度を作れる技術をつけてからじゃないか？
言語仕様がどうとか言う奴は、どうせ素人だろｗ
430:デフォルトの名無しさん
08/07/11 12:57:08
コンパイラなんて、誰でも作れる基礎技術じゃん。
大学生が授業でやるくらいのはなし。
431:デフォルトの名無しさん
08/07/11 16:15:29
OpenCLってObjective-Cから簡単に呼び出せるなら問題ないんじゃね？
FFI（Foreign Function Interface）とか経由するのかな？
432:デフォルトの名無しさん
08/07/11 16:22:24
今議論している内容を小学生1年生でも分かるように
説明しなさい。
433:デフォルトの名無しさん
08/07/11 16:35:54
>>432
人にモノを頼むときにはそれなりのｗ
434:デフォルトの名無しさん
08/07/11 21:41:24
>>432
つくえの上にりんごが一つあります。
さて、このりんごはなぜここにあるのでしょう。
1.りんご農家のおじさんがりんごを育てたから
2.お母さんがかってきたから
3.まさしくんがつくえの上においたから
4.言語仕様
5.苺も食べずにりんごとか素人だろｗ
435:デフォルトの名無しさん
08/07/12 00:46:40
>>434
私という自我がリンゴを個体としてのリンゴをそこに存在すると認識したからそこにあるのです。
436:デフォルトの名無しさん
08/07/12 01:21:47
>>434という他者が「そこにりんごが一つある」と主張
しているだけだから、正確には>>435は信用した上で認識「することにした」段階かと
437:デフォルトの名無しさん
08/07/12 16:26:01
みなさんは変態さんですか？
438:デフォルトの名無しさん
08/07/12 18:43:08
多態です。
439:デフォルトの名無しさん
08/07/12 23:30:11
>>431
URLﾘﾝｸ(www.apple.com)
>OpenCL is based on the C programming language and has been proposed as an open standard.
URLﾘﾝｸ(en.wikipedia.org)
>The initial OpenCL implementation is reportedly built on LLVM and Clang compiler technology.[citation needed]
参考になりそうなのは、これくらい。。。
440:デフォルトの名無しさん
08/07/13 04:38:19
OpenCLはCUDAらしい。CgではなくCUDAベースだから見かけほどC言語には似てない気がする。
441:デフォルトの名無しさん
08/07/13 17:09:50
Cocoaラッパ待ち
442:デフォルトの名無しさん
08/07/15 18:42:43
>>440
>OpenCLはCUDAらしい
らしいという話はよくでるんだが
ソースって見たことがないんだよな。
443:デフォルトの名無しさん
08/07/17 17:13:14
プログラム初心者がobjective-Cから入るのってマズい？
444:デフォルトの名無しさん
08/07/17 17:29:51
>>443
マズくはないけど資料は少ないから初心者にとっては最初の学習曲線が急勾配になってしまう。
JavaやC++で基本的なアルゴリズムやデザパタを学んだ方が資料が豊富だから楽に勉強できると思う。
ダイナミックな部分を勉強するにはSmalltalk（Squeak）が適している。あとRubyやPythonも。
そういったことを承知の上でどれで始めるのが良いかを選べばいいんじゃないかな。
あとは好みの問題。
445:デフォルトの名無しさん
08/07/17 17:30:36
>>443
あんまりまともなプログラムを書いた事のない俺が思う程度だけど、
他言語をちょっと囓っている＋英語の情報も読んでいけるのならアリだと思う。
ただ、全く分からない人がいきなりObjective-Cからだと
・最近は増えてきたものの日本語の情報（Web＆書籍）が少なめ。
・AppleのドキュメントもC言語の基礎知識とかを前提にしている感あり。
この辺でちと大変かも。
基本的には意欲だと思う。逆に言えば意欲が弱いとJavaだろうがC言語だろうがPHPだろうが関係なくだめだと思う。
ベストな環境はリアルでもメールでも掲示板でもいいけど疑問に答えて教えてもらえるような人間がいると覚えは早いと思う。
446:デフォルトの名無しさん
08/07/17 17:40:36
>>444
サンクス
各言語の違いが全くわからないのでググって検討してみます
Ｃ#よりＣ++の方がいいんですね
>>445
サンクス
意欲・・・きっかけがそもそもiPhoneという厨な理由だからどこまでいけるか
わかりませんが・・・
>AppleのドキュメントもC言語の基礎知識とかを前提にしている感あり
やっぱりＣ関連から入った方がいいのかもしれませんね
447:デフォルトの名無しさん
08/07/17 17:51:48
>>446
そういう動機であれば最初はRuby on RailsとかでWebアプリを作成してiPhoneから利用すれば簡単だと思う。
そういう資料はネット上に沢山転がってるからググって見るといいよ。
ある程度プログラミングに自信が付いてからObjective-Cに移行すればスムーズに学習できそう。
こういう順番でやれば、サーバーサイドとクライアントサイドの両方の知識が得られる。
両方の視点でプログラミングできればiPhoneに負荷をかけないプログラムを作成するノウハウも見つけられると思う。
448:デフォルトの名無しさん
08/07/17 18:22:14
>>447
ありがとう。なんて親切なんだ(つД｀)・ﾟ・
Ruby on Railsを調べてみます
449:デフォルトの名無しさん
08/07/17 18:46:27
ObjCの前にCはやっといた方が良いけど、C++は覚えなくてOK.
（C++専用のライブラリを使いたいのでもなければ）
C#はiPhoneでの開発には全く不要。
iPhone用プログラムならまずWebアプリから作ってみるというのには賛成。
PHPでベタ書きか、Python + DjangoかRurby + Railsあたりがおすすめ。
450:デフォルトの名無しさん
08/07/17 18:58:24
>>449
㌧クス。感涙で前が見えない｡ﾟ(ﾟ´Д｀ﾟ)゜｡
うーむ、C++でもC#でもなく初代Cがいいのか・・・
iPhone用ゲームの開発が主目的なんですが、やはりWebアプリから学んでいったほうが
いいんですかね？
451:デフォルトの名無しさん
08/07/17 19:21:49
明確にiPhone開発がしたいならObjCから始めるべきだと思う．
モチベーションは全てに優先するよ．
452:デフォルトの名無しさん
08/07/17 19:32:08
うむ、iPhone Application Tutorialからど～ぞ。
453:デフォルトの名無しさん
08/07/17 20:03:11
皆さんありがとう
明日Amazonから萩原本が届くのでとりあえず読んでみます(｀･ω･´)
454:デフォルトの名無しさん
08/07/17 20:33:13
まてまて、荻原本はプログラミング初学者には敷居が高いぞ。
他言語でokなので、何かしらの入門本を読んでからの方が良いと思われ。
455:デフォルトの名無しさん
08/07/17 20:43:01
初めてで萩原本読むくらいなら、
英和辞書片手にヒレガス本第3版読んだ方が良さそうだな。
平易な文体だから高校生以上なら辞書なしでも
大体のフィーリングは掴めると思うし、スクリーンショットや挿し絵も多いしな。
456:デフォルトの名無しさん
08/07/17 20:46:52
>>454>>455
Σ (ﾟДﾟ；)
そ、そうなのか・・・
では上で教えてもらったＣとか、Ruby on Railsとかの入門書から挑戦してみます
ヒレガス本第3版というのも見てみます（洋書は気おくれしそうですが・・・）
ありがとう
ってか皆さん滅茶苦茶お詳しいっすね・・・(；´Д｀)
457:デフォルトの名無しさん
08/07/17 20:50:31
個人的な趣味としてRubyと Railsを押すけど、webアプリを作って外部に公開する場合レンサバ借りるときにいろいろ困ることがあるよ。
英語が得意なら海外でRails向けのホスティングサービスがあるけどね。
iPhoneアプリを作りたい位だからLeopardユーザだと思うけど、
TextMateってテキストエディタをDLしてきて
p "Hello World"
って書いて拡張子を rb 保存して Command＋Rをするだけで実行できて楽だと思う。
ってスレ違いになるからこのくらいにしておく。
その心意気はすばらしいけど、荻原本はまったくもってプログラミング初心者が読む本じゃないよ。
458:デフォルトの名無しさん
08/07/17 21:25:47
でもObjective-Cの仕様なんてCに毛が生えたようなもんだし、
Objective-Cの書籍として荻原本はベストな選択の一つなのは間違いない。
強いて言うなら、Cの入門書とCocoaフレームワークやInterface Builderに
ついての本を一冊ずつ買っとくといいと思う。
459:デフォルトの名無しさん
08/07/17 22:16:38
>>457
>>458
アドバイスサンクス
道は一本じゃなさそうなのでいろいろ齧ってみます
しかしプログラムの道は高く険しいなぁ・・・
460:デフォルトの名無しさん
08/07/17 23:21:38
>>459
あと、iPhone プログラムを突然はじめるより、いちど OS X 用の小さいプログラムを書いてから iPhone にいったほうがわかりやすいかもしれない。
大体構造いっしょだし、OS X 用プログラムの書き方のほうがネットに沢山ころがってます。
461:デフォルトの名無しさん
08/07/17 23:25:19
>うーむ、C++でもC#でもなく初代Cがいいのか・・・
Obj-C は C++ と同時期に(80年代) C から派生した言語なので、まあ並列だよ。
べつに C++ を勉強したから Obj-C がわかりやすいとかその逆ということではないです。
両方ともオブジェクト指向だけど、毛色が360度違います。
C# は Java のクローンだよね。Java 自体が C, Obj-C, C++ を参考に開発されたものだし。
462:デフォルトの名無しさん
08/07/17 23:49:02
C#、特にC# 3.0はJavaより強力な言語になってるよ。
ただ実質的に実行環境や開発環境がWindowsに限られるのが難。（Monoもあるけど）
MS製の環境にどっぷり浸かるならば良いとは思う。VS.Netも強力だし。
ただiPhoneの開発には使えないし、応用できるテクもおそらく無いw
463:デフォルトの名無しさん
08/07/17 23:53:15
勘違いさんいらっしゃーい >>462
はいさようなら。
464:デフォルトの名無しさん
08/07/17 23:55:19
>>460
>>461
>>462
俺みたいなクレクレ厨にここまで親切にアドバイスしてくれるなんて・・・
みんな優しいな｡ﾟ(ﾟ´Д｀ﾟ)゜｡
よその板なら「ググれやカス」で終わっても不思議じゃないのに・・・
ありがとう、このご恩は忘れませぬ ﾉｼ
Windowsのゲーム作りならC#がいい、って聞いたことあるので
いつかC#も触ってみます
465:デフォルトの名無しさん
08/07/17 23:58:27
>>464
>このご恩は忘れませぬ
検討を祈る。成功したら後輩に優しくな！
466:デフォルトの名無しさん
08/07/17 23:59:10
自作er乙
467:デフォルトの名無しさん
08/07/18 00:14:15
iPhoneアプリに関しては正式に配布できるような形のプログラムのTipsとかは現時点ではNDAがあるからないに等しい。
Appleのサンプルプログラムくらいしかソースも読めない。
Objective-Cをやるなら
>>460が言うようにMacアプリからやった方が現時点ではいいだろうね。
468:デフォルトの名無しさん
08/07/18 13:19:01
Mac用だけどObjective-Cの入門記事です。
URLﾘﾝｸ(journal.mycom.co.jp)
469:デフォルトの名無しさん
08/07/18 13:36:38
Objective-CってVisitor Patternが使えないの?
470:デフォルトの名無しさん
08/07/18 18:39:27
え？
471:デフォルトの名無しさん
08/07/18 19:03:20
そもそも visitor pattern なんて使わないだろ
472:デフォルトの名無しさん
08/07/18 19:03:52
Visitor Patternを使うのに、何か問題でも？
473:デフォルトの名無しさん
08/07/18 20:49:15
Visitor Patternといえば木構造の処理系作成に使ったことがある。
でも、Objective-Cはメソッドオーバーロード出来ないから特殊な方法でやった。
普通の意味でならVisitor Patternが使えないのは本当。
474:デフォルトの名無しさん
08/07/18 21:05:42
Visitor Patternって、メソッドのオーバーロードができないと、実装できないんだっけ？
オーバーロードって、引数の型によって「静的に」同じ名前のメソッドを区別するためのものなんだから、プログラムの構造に影響しないように思えるけど。
単純に複数の名前のメソッドを使い分けるだけでは？
475:デフォルトの名無しさん
08/07/18 22:08:31
＞単純に複数の名前のメソッドを使い分けるだけでは？
そんなメンテナンス性の悪いコーディングしてどうする
476:デフォルトの名無しさん
08/07/18 22:41:48
ようするに
void action(A obj)
void action(B obj)
と定義されていたものが、
void actionWithA(id obj)
void actionWithB(id obj)
となるだけだから、ソースコードの見た目の問題はあるけど、Visitor Patternが実装できない理由にはならないよね？
477:デフォルトの名無しさん
08/07/18 22:55:39
今帰宅
萩原本届いてた
ちょっと読んでみた
(´；ω；`) ・・・。
やっぱりＣの入門書から読みます
>>467>>468
ありがとう
心折れかけたけど地道に頑張ります
478:デフォルトの名無しさん
08/07/18 23:13:32
>>477
まあプログラミングにも王道は無しだよ。あなたの今のように謙虚な気持ちを忘れなければきっとできるようになります。
あと、C のポインタのあたり、文字列操作の細かい話は
あまり勉強しなくても大丈夫なので読み飛ばしてください。
479:デフォルトの名無しさん
08/07/18 23:23:20
おいおい、ポインタはいるだろ。
Cocoaだって最近のAPIはNSError **が大量にあるだろ。
480:デフォルトの名無しさん
08/07/18 23:26:42
ポインタってみんなどういうところでつまづくの？
「変数を入れてるメモリエリアのアドレスを渡す。」
それ以上になにか必要か？
481:デフォルトの名無しさん
08/07/18 23:32:40
478 ですが、全然いらないというつもりはないんだけど。
>>480
さんの言ったことを言いたかったです。言葉が足りませんでした。
& と * はわかっておいたほうがいいけど、Objective-C ではそれで充分だよね。
malloc / free は要らないし、ポインタ演算 (足し算引き算) は要らないでしょ。
あと、配列は知らなくてもいいし、配列とポインタの等価性も要らないし、
文字列が char* 配列だということも知らなくてなんとかなるのでは。
482:デフォルトの名無しさん
08/07/18 23:56:38
>>476
＞ソースコードの見た目の問題はあるけど、Visitor Patternが実装できない理由にはならないよね？
それで多重継承や多重ディスパッチを出来ると強弁するならご勝手にｗ
483:デフォルトの名無しさん
08/07/19 00:01:28
>>480
＞配列とポインタの等価性
エキスパートC読んでこれが嘘だと理解した。こういうところに躓きの原因がある。>>481はわかっていない。
484:デフォルトの名無しさん
08/07/19 00:13:51
>>482
Obj-C は reflection があるから多重ディスパッチはむしろ実装しやすい気が ...
visitor pattern はvirtual member 止まりの静的型付け言語用の気がします。
とわからない言葉をならべてみる
485:デフォルトの名無しさん
08/07/19 00:15:10
>エキスパートC読んでこれが嘘だと理解した。こういうところに躓きの原因がある。
いやまあ、Objective C スレとしては、そのへんでひっかかろうがひっかかるまいが
Objective C では必要ないよというので充分なのでは。
486:デフォルトの名無しさん
08/07/19 00:19:14
こういうスレで嘘は良くないのではないかい？
487:デフォルトの名無しさん
08/07/19 00:34:22
世の中には平気で嘘をつける人がいる。
嘘を指摘されるとそういうものは必要ないと言いだす。
そういう無反省な態度は無自覚に行われるから本人は嘘を良くないとは考えていない。
488:デフォルトの名無しさん
08/07/19 00:41:12
>>484
＞visitor pattern はvirtual member 止まりの静的型付け言語用の気がします。
ほんと馬鹿。逝ってよし。
489:デフォルトの名無しさん
08/07/19 01:09:23
481 ですが、嘘を付いてすいませんでした。
折角なので配列とポインタがどんなふうに違うかわかりやすく教えてください ...
490:デフォルトの名無しさん
08/07/19 01:18:07
URLﾘﾝｸ(www.cocoadev.com)
でも同じような議論になってる
491:デフォルトの名無しさん
08/07/19 01:48:48
>>364でも同じような議論になってる
嘘つきはお断り
492:デフォルトの名無しさん
08/07/19 01:52:06
>>489
C FAQ
493:デフォルトの名無しさん
08/07/19 03:46:16
>>489
ぐぐれｶｽ
494:デフォルトの名無しさん
08/07/19 05:46:43
>>483
たしかにそうだ
なんとなく分かってるつもりでも
間違って覚えてるケースが結構ある
正しい理解が必要
495:デフォルトの名無しさん
08/07/19 06:28:26
嘘つき語録
>>474
Visitor Patternって、メソッドのオーバーロードができないと、実装できないんだっけ？
オーバーロードって、引数の型によって「静的に」同じ名前のメソッドを区別するためのものなんだから、プログラムの構造に影響しないように思えるけど。
単純に複数の名前のメソッドを使い分けるだけでは？
>>476
ようするに
void action(A obj)
void action(B obj)
と定義されていたものが、
void actionWithA(id obj)
void actionWithB(id obj)
となるだけだから、ソースコードの見た目の問題はあるけど、Visitor Patternが実装できない理由にはならないよね？
>>478
①C のポインタのあたり、②文字列操作の細かい話はあまり勉強しなくても大丈夫なので読み飛ばしてください。
>>481
③malloc / free は要らないし、④ポインタ演算 (足し算引き算) は要らないでしょ。
あと、⑤配列は知らなくてもいいし、⑥配列とポインタの等価性も要らないし、
⑦文字列が char* 配列だということも知らなくてなんとかなるのでは。
>>484
Obj-C は reflection があるから多重ディスパッチはむしろ実装しやすい気が ...
visitor pattern はvirtual member 止まりの静的型付け言語用の気がします。
とわからない言葉をならべてみる
496:デフォルトの名無しさん
08/07/19 07:42:09
他はしらんが、C における文字列操作の細かい話は勉強しなくてもいいのは本当では？strstr とか知っててもしかたないよね。NSString でいいんじゃね？
497:デフォルトの名無しさん
08/07/19 09:19:11
いろいろな言語の文字列操作関数の比較表
Ruby, Python, JavaScript, Perl, C++
URLﾘﾝｸ(0xcc.net)
Ruby, PHP, Objective-C
URLﾘﾝｸ(d.hatena.ne.jp)
意外とObjective-Cも健闘してる希ガス。
実際にOpen環境（ｲﾜﾕﾙ野良SDK）でのプログラミングが公開されているので以下に紹介する。
テキストエディタの作成のところでもNSStringを使ってる。
第1回：iPod touchにアプリケーションがインストールできる不思議
URLﾘﾝｸ(www.thinkit.co.jp)
第2回：iPod touchの自作アプリケーションが作れる＆動かせる！
URLﾘﾝｸ(www.thinkit.co.jp)
第3回：iPod touchで動作するテキストエディタはこう作る！
URLﾘﾝｸ(www.thinkit.co.jp)
第4回：夢のオフラインRSSリーダを作ろう！
URLﾘﾝｸ(www.thinkit.co.jp)
498:デフォルトの名無しさん
08/07/19 09:27:53
実際のHello Worldプログラムを紹介する。（その１）
// hello.m
#import <UIKit/UIKit.h>
#import "HelloApplication.h"
int main(int argc, char **argv)
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
return UIApplicationMain(argc, argv, [HelloApplication class]);
}
499:デフォルトの名無しさん
08/07/19 09:28:40
>>497
>実際にOpen環境（ｲﾜﾕﾙ野良SDK）でのプログラミングが公開されているので以下に紹介する。
>テキストエディタの作成のところでもNSStringを使ってる。
べつに NSString の使い方を示すのなら
「実際に」iPhone じゃなくて「実際に」Mac / GnuStep でいいのでは...
500:デフォルトの名無しさん
08/07/19 09:28:56
（その２）
// HelloApplication.h
#import <Foundation/Foundation.h>
#import <UIKit/UIKit.h>
#import <UIKit/UIApplication.h>
#import <UIKit/UIPushButton.h>
#import <UIKit/UITableCell.h>
#import <UIKit/UIImageAndTextTableCell.h>
@interface HelloApplication : UIApplication
{
UIImageAndTextTableCell *pbCell;
UITableCell *buttonCell;
}
@end
501:デフォルトの名無しさん
08/07/19 09:31:14
（その３）
// HelloApplication.m
#import <CoreFoundation/CoreFoundation.h>
#import <Foundation/Foundation.h>
#import <UIKit/CDStructures.h>
#import <UIKit/UIPushButton.h>
#import <UIKit/UIThreePartButton.h>
#import <UIKit/UINavigationBar.h>
#import <UIKit/UIWindow.h>
#import <UIKit/UIView-Hierarchy.h>
#import <UIKit/UIHardware.h>
#import <UIKit/UITable.h>
#import <UIKit/UITableCell.h>
#import <UIKit/UITableColumn.h>
#import "HelloApplication.h"
@implementation HelloApplication
- (int) numberOfRowsInTable: (UITable *)table
{
return 2;
}
- (UITableCell *) table: (UITable *)table cellForRow: (int)row column: (int)col
{
return row ? buttonCell : pbCell;
}
502:デフォルトの名無しさん
08/07/19 09:33:15
（その４）
- (UITableCell *) table: (UITable *)table cellForRow: (int)row column: (int)col
reusing: (BOOL) reusing
{
return pbCell;
}
- (void) applicationDidFinishLaunching: (id) unused
{
UIWindow *window;
BOOL i = TRUE;
window = [[UIWindow alloc] initWithContentRect: [UIHardware
fullScreenApplicationContentRect]];
pbCell = [[UIImageAndTextTableCell alloc] init];
[pbCell setTitle: [NSString stringWithFormat:@"Hello World!"]];
UIPushButton *button = [[UIThreePartButton alloc] initWithTitle:
@"Touch Me"];
buttonCell = [[UITableCell alloc] init];
[buttonCell addSubview: button];
[button sizeToFit];
UITable *table = [[UITable alloc] initWithFrame: CGRectMake(0.0f, 48.0f, 320.0f, 480.0f - 16.0f - 32.0f)];
UITableColumn *col = [[UITableColumn alloc] initWithTitle: @"HelloApp" identifier: @"hello" width: 320.0f];
503:デフォルトの名無しさん
08/07/19 09:33:47
（その５）
[window orderFront: self];
[window makeKey: self];
[window _setHidden: NO];
[table addTableColumn: col];
[table setDataSource: self];
[table setDelegate: self];
[table reloadData];
UINavigationBar *nav = [[UINavigationBar alloc] initWithFrame: CGRectMake(
0.0f, 0.0f, 320.0f, 48.0f)];
[nav showButtonsWithLeftTitle: @"Foo" rightTitle: @"Bar" leftBack: YES];
[nav setBarStyle: 0];
struct CGRect rect = [UIHardware fullScreenApplicationContentRect];
rect.origin.x = rect.origin.y = 0.0f;
UIView *mainView;
mainView = [[UIView alloc] initWithFrame: rect];
[mainView addSubview: nav];
[mainView addSubview: table];
[window setContentView: mainView];
}
@end
504:デフォルトの名無しさん
08/07/19 10:10:59
勘違いさんいらっしゃーい >>499
はいさようなら。
505:デフォルトの名無しさん
08/07/19 12:04:42
POCはMacじゃ使えないんですか？
506:デフォルトの名無しさん
08/07/19 12:23:12
めずらしく伸びてると思ったらもう夏休みなんだな…
小中学生ばっかりか
507:デフォルトの名無しさん
08/07/19 12:25:50
Objective-Cは、文字列を`char *'型にするか、NSStringオブジェクトにするか選択できるハイブリッド型であるということが特徴です。
これがObjective-CのほうがSmalltalkより高速な理由です。
別な観点から言えば、 Objective-Cプログラムのすべての要素がオブジェクトで表現されていたとしたら、おそらくSmalltalkと同程度の速度であり、
Smalltalkが行なえる基本クラスへの最適化がないことで苦戦するでしょう。
つまり、文字列操作の細かい話は勉強しなくてもいいと言っている人はObjective-Cのメリットを全く理解していないんです。
508:デフォルトの名無しさん
08/07/19 12:27:01
>>506
ボクが小学生だからってバカにするオマエがバカ！
509:デフォルトの名無しさん
08/07/19 12:33:53
>>505
PoweMacのみ。IntelMacでは動かない。EtoileはIntelMacでも動くよ。
510:デフォルトの名無しさん
08/07/19 12:47:16
>>507
ええと、一応聞いておくけど、本気でそう思っているのか ?
おまえは全ての encoding に対応した文字列操作ルーチンを自分で書いて最適化できるのか ?
511:デフォルトの名無しさん
08/07/19 13:02:20
＞おまえは全ての encoding に対応した文字列操作ルーチンを自分で書いて最適化できるのか ?
逆に質問しよう。なぜ、最適化という問題を持ち出したかと言えばオブジェクトのオーバーヘッドを理解しているからじゃないのか？
自分で最適化しないでも、問題を理解していれば、そういった処理を注意深く扱うようになる。それで速度的な問題を回避できるようになる。
512:デフォルトの名無しさん
08/07/19 13:12:05
近頃の人ってsprintfとか使わんの？
513:デフォルトの名無しさん
08/07/19 13:48:32
「文字列操作ルーチンを自分で書いて最適化できるのか ? 」って極端すぎるだろｗ
よっぽど悔しかったのかｗ
514:デフォルトの名無しさん
08/07/19 14:11:34
>>512
sprintfなんて使ってるやつはばかです
515:デフォルトの名無しさん
08/07/19 14:25:30
>>514
理路整然とした理由も述べないで否定するだけなら小学生でもできる。
まさか小学生じゃないよな？
sprintfとNSStringでの文字列操作の用例を挙げて比較したうえで
なぜsprintfを使うのがばかなのか述べてくれないかなぁ。
これは非常に興味深いテーマだ、>>514、君の意見が聞きたい。
516:デフォルトの名無しさん
08/07/19 14:37:03
sprintfのmanくらい読んでから質問してください
517:デフォルトの名無しさん
08/07/19 14:48:23
snprintfだろう常考
518:デフォルトの名無しさん
08/07/19 15:20:33
クズばっかだな
519:デフォルトの名無しさん
08/07/19 15:33:50
snprintf！！
wwww
現場を知らない廚はｺﾚだから困る。
520:デフォルトの名無しさん
08/07/19 15:37:21
>>514の言い分けﾏﾀﾞー？(゜∀゜)
521:デフォルトの名無しさん
08/07/19 16:30:50
わけけ?
522:デフォルトの名無しさん
08/07/19 16:52:33
>507
一行目は同感だけど、最終行は同意できない。
いまさら自力で文字列”操作”をする人はいないでしょ。
使うとしたら簡易パーサぐらいだろうけど、
それでもその辺に落ちてる高級パーサとか正規表現ライブラリ使う方が手っ取り早い。
それともこの程度のことも”操作”に入る？
NSLogは改行されるし、妙な出力が追加されるんで、fprintfを使うことは多いよね。
>>516
+[NSString stringWithFormat:format, ...] がsprintf相当だね。
523:デフォルトの名無しさん
08/07/19 17:07:54
＞一行目は同感だけど、最終行は同意できない。
結局、全く理解してないことを指摘されて図星だったのかｗ
まともな反論も出来ないチンカスｗ
524:デフォルトの名無しさん
08/07/19 17:39:14
＞いまさら自力で文字列”操作”をする人はいないでしょ。
＞使うとしたら簡易パーサぐらいだろうけど、
＞それでもその辺に落ちてる高級パーサとか正規表現ライブラリ使う方が手っ取り早い。
で、NSStringを使う利点まだぁ？ﾁﾝﾁﾝ
その程度でC言語の文字列操作の細かい話は勉強しなくてもいい理由だって主張してるの？
525:デフォルトの名無しさん
08/07/19 17:56:20
佐藤藍子 「NSStringさえあればもうNSStringC言語の文字列操作の細かい話は勉強しなくてもいいと思ってました」
526:デフォルトの名無しさん
08/07/19 18:27:42
ごめん。
人違いだわ、それ。
おれ、>522が初発言ね。
＞NSStringを使う利点まだぁ？
楽だから。
べつにお勉強の為に文字列を操作するのは止めないけど、
お勉強以外であえて泥沼を選ぶ意図が俺には分からないね。
527:デフォルトの名無しさん
08/07/19 18:40:21
>>526
「>>514じゃないけど」ぐらいことわってから書くぐらいしろよ。
間違われても仕方ないだろ。
まぎらわしいぞｗ
528:デフォルトの名無しさん
08/07/19 19:02:20
ごめん。
ID無いの忘れてたんだよ。
529:デフォルトの名無しさん
08/07/20 01:14:12
外人さんがつくった Cocoa ソフトで日本語環境でつかうと
おかしくなるのがあって、ソースみて原因追及してみたら
内部でアルファベットだけと仮定して char* で操作してるところのせい
だったというのがあるので、char* のほうが速いかもしれませんが、
非日本人が使うかもしれないというのを考えて、
ShiftJIS / MacJapanese とかエンコーディングを仮定して
char* を操作するプログラムを書くのではなくて、
NSString (か他の国際化文字列ライブラリ)をつかって書くようにして
おいてくださると多分世界のどこかで誰かが助かります。
530:デフォルトの名無しさん
08/07/20 01:19:21
文字を右から左に書く言語も考慮して作れということか？
531:デフォルトの名無しさん
08/07/20 01:31:05
NSString (とかほかの国際化文字ライブラリ) をつかっておくと、
自分で考えなくても自動的にある程度は考慮されたことになるというのが利点。
Mail.app にイスラエル人の知り合いからメールがきて、
名前欄がちゃんとヘブライ語になってたので感心しました。
まあきっと外人さんには名前欄に漢字が出る時点でびっくりなんだろうけど。
海外製のフリーウェアシェアウェアでも Cocoa なら大抵は
日本語問題なくつかえるのは一貫して NSString つかってあるからで、
(というと言い過ぎだと思いますが、)
昔の Carbon のころはそうではなかったです。
メニューバーとかよく化けてたでしょ。
532:デフォルトの名無しさん
08/07/20 01:39:10
>>529
君のまだ知らない世界にはユニコードっていうものがあってな
533:デフォルトの名無しさん
08/07/20 02:09:08
>>532
個人が作るソフトにはUTF-8なcharとかwchar_tを使わずに
US-ASCIIかISO-8859-1前提でcharを使ってるのがままあるよ。
作者がUnicodeにする必要を感じてないから仕方ない。
Mac用のソフトだと素直にCocoaで作ればそんなことにはなりづらいけどね。
534:デフォルトの名無しさん
08/07/20 02:14:19
アホにわざわざ説明してやらんでも
535:デフォルトの名無しさん
08/07/20 02:16:53
>>522
＞それでもその辺に落ちてる高級パーサとか正規表現ライブラリ使う方が手っ取り早い。
その辺に落ちてるのほとんどchar*になってるだろｗ
NSString使わない方が良いみたいに読めてしまうｗ
536:デフォルトの名無しさん
08/07/20 02:18:38
UTF-8NとUTF-8はちと違うし、UTF-16にもUTF-16Nがあるんだよな。
537:デフォルトの名無しさん
08/07/20 02:27:05
>>535
＞それともこの程度のことも”操作”に入る？
も読んでね。
文字列を渡したり、もらったりも文字列操作に入れちゃうのか？
538:デフォルトの名無しさん
08/07/20 04:08:53
>>537
てかさぁ、ライブラリでパターンマッチングやバックトラッキング用のクラスを用意してその上に高級パーサとか正規表現ライブラリを構築してる例なんてあるの？
なかったらどのみちchar*を使うんだから勉強せざるを得ないんじゃないのか？
539:デフォルトの名無しさん
08/07/20 05:30:58
char *は使うよ。
でも、文字列は操作しないよ。
540:デフォルトの名無しさん
08/07/20 05:39:33
正規表現ならOgreKitがある
541:デフォルトの名無しさん
08/07/20 08:36:55
パーザをlex&yaccで作成するときにはまともなCの知識が必要だ。
上で言ってるObjective-Cの知識だけじゃどうにもならん場合はある。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5029日前に更新/212 KB
担当:undef