Objective-C [ObjC part:3]; - 暇つぶし2ch

Objective-C [ObjC pa ..

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の知識だけじゃどうにもならん場合はある。

542:デフォルトの名無しさん
08/07/20 09:02:36
そこまでする人間がまともなCの知識を持ってないというのも考えにくいような。

ちょっと凝ったことをするにはCで直に、あるいはObjCのラッパを書くことになるし
Objective-Cだけで開発するには限界があるのは同意。

543:デフォルトの名無しさん
08/07/20 10:04:26
ここで正規表現とか持ち出す奴っていったい何なの？
データベース使うJavaの人？BSDとかでスクリプト書いてる人？
文字列検索と文字列操作を美しく勘違いしてないかいw？

544:デフォルトの名無しさん
08/07/20 10:19:48
C言語の正規表現を使うにはregex.hをimportしてregcomp, regexec, regfree関数を利用する。

int regcomp(regex_t *preg, const char *regex, int cflags)
　　正規表現のコンパイルを行なう。コンパイル成功時には0を返す。

int regexec(const regex_t *preg, const char *string, size_t nmatch, regmatch_t pmatch[], int eflags);
　　正規表現による検索を実行する。

void regfree(regex_t *preg)
　　正規表現パターンバッファを解放する。

545:デフォルトの名無しさん
08/07/20 10:28:06
>>544
通りすがりだが横から質問させて。
で？そのregcomp,regxec,regfree関数ってどういう時に使うの？
sprintfとかscanfとか上の方で出てたNSStringの文字列操作と置き換えられるものなのかな？
教えてエロい人！

546:デフォルトの名無しさん
08/07/20 10:31:02
OgreKitとregex.h。OgreKit遅いやん。

547:デフォルトの名無しさん
08/07/20 10:35:06
>>546
ﾈｰﾈｰregex、OregKitとかいうのとsprintfは同じ機能のものなの？
文字列操作の話で来ているのになんで「正規表現」て出てきてegex、OregKitなの？
ﾜｶﾗﾅｲ、ﾜｶﾗﾅｲ...
「お前が馬鹿だから」と言うの無しでちゃんと説明して！、初心者なので。

548:デフォルトの名無しさん
08/07/20 10:36:33
>>545
適当にググッた。嫁。サンプルコードだけ読めば簡単に分かる。

regex.h

URLﾘﾝｸ(memo.majide.com)
URLﾘﾝｸ(sometime.minidns.net)

reglib.c ・・・ regcomp,regxec,regfree関数を使って、regsplit, regreplace, regrpall, regcnt関数を構築してる例

URLﾘﾝｸ(sometime.minidns.net)

549:デフォルトの名無しさん
08/07/20 10:41:36
要するにプログラマは文字列操作をテーマとした意思の疎通も困難な程、コミュニケーション能力がないという事か。
sprintfに対してreglib使え？おいおい(w。
挙げ句は自分の言葉で説明できないからググッたコピペと来たよ。
これじゃプロジェクトが座礁してデスマーチにもなる罠。

550:デフォルトの名無しさん
08/07/20 10:42:11
＞サンプルコードだけ読めば
いや、走らしてみろ。即分かる。

551:デフォルトの名無しさん
08/07/20 10:43:09
>>549
はいはい、ﾜﾛｽﾜﾛｽｗ

552:デフォルトの名無しさん
08/07/20 10:47:24
prm1という変数があってユーザーが入力した値を入れ、メッセージに表示する為の文字列を作りたいと思います。
例："prm1は不正な入力です。"

sprintfではなくreglibで処理を行なうにはどのようにしたら良いでしょうか。
具体的なコードをここに書いてくださると助かります。

553:デフォルトの名無しさん
08/07/20 10:57:59
>>552のこうげき
「かいしんのいちげき！」

>>551の無能さが露呈した。

554:デフォルトの名無しさん
08/07/20 11:06:05
hoge.strings
"hoge"="%sは不正な入力です。";

hoge.m
...
id hoge = NSLocalizedStringFromTable(@"hoge", @"hoge", @"hoge");
hoge = [NSString stringWithFormat:hoge, prm1];
fprintf(strerr, "%s¥n", [hoge UTF8String]);
...

てか、文字列操作の細かい部分をchar *でするかどうかの話でしょ？
なんで話変わってんの？

555:デフォルトの名無しさん
08/07/20 11:06:47
>>549
>これじゃプロジェクトが座礁してデスマーチにもなる罠。

いやいや多分>>548はプログラマですらないからwww
iPhoneブームで注目度があがるの結構だけど、知ったかぶる廚も多くなるから嫌だね。

556:522
08/07/20 11:07:29
>>554 は俺ね。
また勘違いされる所だ（w

557:デフォルトの名無しさん
08/07/20 11:08:37
上でlex&yaccの話が出てたと思うけど、文字列操作は字句解析と構文解析のふたつで出来てることが多い。
lexは字句解析のことで、文字列を1文字づつ読み込んでトークン、つまり単語に切り分ける仕事をする。
yaccは構文解析のことで、得られたトークンの意味を推測して構文木を作成する。
で、得られた構文木を元にして文字列の意味を翻訳する。

正規表現は、テキストの文字列に対してパターンマッチを行う強力な道具です。
TEXTファイル中からある単語を置換/検索するのもパターンマッチです。
例えばyaccを使わないで簡易にキーワード（文法上重要なトークン）を探したいときのパターンマッチを正規表現でやるとか出来ます。
regex、OregKitは正規表現プログラムなのでそういったことが簡単に出来ます。

int sprintf(char *str, const char *format, ．．． );

sprintfは書式formatにしたがって、printf関数と同様の変換を行った出力を、文字列strに格納します。使えるようになると凄く便利。
char *str　：　変換した出力を格納する文字列。
const char *format　：　書式指定文字列。

※　要するに、正規表現は文字列のパターンマッチをするのに対して、sprintf関数は文字列を変換します。だから役割はちがう。

558:デフォルトの名無しさん
08/07/20 11:12:15
煽らないと会話してもらえない可愛そうな香具師なのかな？

559:デフォルトの名無しさん
08/07/20 11:14:45
あ、あと出来上がった構文木はバックトラッキング（深さ優先探索）を使って各ノードをトラバース（順次訪れる）します。

560:デフォルトの名無しさん
08/07/20 11:15:58
夏休みに入った途端に変な子が来たね

561:547
08/07/20 11:17:06
>>557
ありがとうございます！
regex,OregKitはsprintfとは使い道が違うものなのですね。
困ったさんのおかげであやうく誤った知識を覚えてしまうところでした。

562:デフォルトの名無しさん
08/07/20 11:21:49
例えば、Ruby on RailsみたいなWebアプリでやってるようなことをObjective-Cとかで実現したいとしよう。
プログラムには、字句解析と構文解析をする部分を作成してHTMLやXMLの中から必要な情報を抜き取る必要がある。
そういうときに、パターンマッチで必要な情報を見つける。そして、sprintf関数とかを使って適切な形に仕上げて表示させるという風に使用する。

563:デフォルトの名無しさん
08/07/20 11:28:39
XML なら素直に既存の XML parser 使うだろ、普通。

564:デフォルトの名無しさん
08/07/20 11:31:52
>>563
じゃ、解説して！
もう疲れてきた。適切な例を考えるのめんどい。

565:デフォルトの名無しさん
08/07/20 11:35:32
すまんが>>514が悪あがきしているようにしか見えない。>>564

566:デフォルトの名無しさん
08/07/20 11:37:47
>>514じゃないからｗ
むしろ>>553だろ

おれはちゃんと>>557を書いて説明した。>>514と言われるのは心外だ。

567:デフォルトの名無しさん
08/07/20 11:47:41
>>566
すまん。疑心暗鬼になってて。

568:デフォルトの名無しさん
08/07/20 12:00:36
lex&yacc⇔flex&bison

569:デフォルトの名無しさん
08/07/20 12:27:02
Obj-C 以外の話題で盛りあがるのはやめようよ ...
夏休みだから仕方がないのかな。

570:デフォルトの名無しさん
08/07/20 13:18:46
>>569
＞夏休みだから仕方がないのかな。
>>495にあるように、この流れは君の嘘が元凶だったんだから反省してくれ

571:デフォルトの名無しさん
08/07/20 14:40:24
個人的にはOregKit意外にもCocoaOniguruma軽くて良い感じ。

572:デフォルトの名無しさん
08/07/21 00:32:36
>>495 にあげられてるのが全部同じ人だってのはどうしてわかったの？
もしかしてスーパーハッカー？

573:デフォルトの名無しさん
08/07/23 12:24:43
単に嘘ついてるのを並べ得たんじゃね
語録としてまとめるのは変だが

574:デフォルトの名無しさん
08/07/23 23:08:37
char* としての文字列の操作をしらなくても簡単な Cocoa プログラムは書けるというのは嘘ではないのでは ...
Apple としては C で書くときでも char* じゃなくて CFString つかってくれということだよね。

575:デフォルトの名無しさん
08/07/24 05:24:39
＞Apple としては C で書くときでも char* じゃなくて CFString つかってくれということだよね。

はぁ？ばかじゃねぇの？

576:デフォルトの名無しさん
08/07/24 08:44:13
>はぁ？ばかじゃねぇの？
煽り煽られたいだけじゃなくて、ほんとにそう思ってるなら、
BSD の API じゃなくて Apple 製の C API で、
char* を受け取るものがどういうのがあるか反省してみてください

577:デフォルトの名無しさん
08/07/24 09:28:05
stringWithCString?

578:デフォルトの名無しさん
08/07/24 09:47:18
>>577
それを使うと"default encoding"が変わったときに
文字化けして死亡するので、使わないでね。というか deprecated in 10.4.
stringWithCString:encoding:
か
stringWithUTF8String:
を使ってください。お願いだから。
これだけのせいで動かない海外製のフリーウェアに何度も出会っているので ...

579:デフォルトの名無しさん
08/07/24 09:54:16
典型的には、OS X の日本語環境では MacJapanese が "default encoding" で、
こいつは円記号とバックスラッシュを区別するので、
海外製の Cocoa でつくったシェルスクリプトのラッパで
不用意に -stringWIthCString: と -cString で行ったり来たりすると
シェルスクリプト内に ASCII code でのバックスラッシュ(0x5c)が
あるべきところにMacJapanese のバックスラッシュ (0x80) が入って
スクリプトが動かなくなったりします ...

580:デフォルトの名無しさん
08/07/24 19:55:33
>>574, >>576
オマエの妄想をAppleが言ってるように言うな、この詐欺師が

581:デフォルトの名無しさん
08/07/24 21:01:18
でたでた

582:デフォルトの名無しさん
08/07/24 21:24:17
>>574
char* としての文字列の操作すら知らなかったら、ほんとに簡単なプログラムしか書けない、というのは嘘ではないよ。

583:デフォルトの名無しさん
08/07/24 23:09:04
>char* としての文字列の操作すら知らなかったら、ほんとに簡単なプログラムしか書けない、というのは嘘ではないよ。
まあそれはそうですね。
NSString のメソッドって一杯あるけどなんか微妙に足りないことがしばしば。
Perl/Ruby/Python みたいに
正規表現が標準でつかえればそんな問題もなくなるんだけど。

584:デフォルトの名無しさん
08/07/24 23:29:01
ねぇねぇ、なんでいきなりchar*を受け取る「API」の話になるの？このスレ。。
それともわざとか？
釣られた俺？

585:デフォルトの名無しさん
08/07/24 23:30:01
>>583
>Perl/Ruby/Python みたいに
>正規表現が標準でつかえればそんな問題もなくなるんだけど。

この人、また来てるのね。正規表現廚。

586:デフォルトの名無しさん
08/07/24 23:46:52
>>584
char*を入力したり出力したりするAPIが存在しなければ、char*を使う必要がない。と言いたいんじゃないの？

587:デフォルトの名無しさん
08/07/25 06:28:52
「char*を受け取るAPI」と「正規表現」にこだわる思考回路が理解できない件ｗｗｗ

588:デフォルトの名無しさん
08/07/25 09:00:50
反抗期なんだろ。

589:デフォルトの名無しさん
08/07/25 09:12:03
ていうか普通 NSString なんか使わないだろ

590:デフォルトの名無しさん
08/07/25 15:16:41
>>574
>>576
>>578
>>579
>>583

591:デフォルトの名無しさん
08/07/25 17:08:20
NSString
NSAutoString
NSCString
NSIString
NSMutableString
NSAttributedString
・・・

592:デフォルトの名無しさん
08/07/25 20:07:49
Netscapeですか

593:デフォルトの名無しさん
08/07/26 07:19:51
Netscape
NetSTEP
NeXTSTEP
NeXTscape
・・・

594:デフォルトの名無しさん
08/07/26 08:21:40
ソープのゴム無し

595:デフォルトの名無しさん
08/07/26 09:41:26
　　　　　　　　　　　バカ専用　　　　　普通　　ハッカー　ウィザード
　　　　　　　　　　　　　┝　-　-　-　-　┿━━┿━━┥
　　 ∩＿＿＿∩　　　/)
　　 | ノ　　　　　ヽ　 ( i )))
　　/　　●　　　● | /　/
　 |　　　　( _●_)　 |ﾉ　/　　　今はここら辺クマーー！！
　彡､　　　|∪|　　　　,/
／　　　　ヽノ　　　/

596:デフォルトの名無しさん
08/07/26 20:44:47
ゴメンずれてる

597:デフォルトの名無しさん
08/07/27 12:45:31
　　　　　　　　　　　バカ専用　　　　　普通　　ハッカー　ウィザード
　　　　　　　　　　　　　┝　-　-　-　-　┿━━┿━━┥
　　　　　　　　　　　　　　　　　　　　　　　 ∩＿＿＿∩　　　/)
　　　　　　　　　　　　　　　　　　　　　　　 | ノ　　　　　ヽ　 ( i )))
　　　　　　　　　　　　　　　　　　　　　　　/　　●　　　● | /　/
　　　　　　　　　　　　　　　　　　　　　　 |　　　　( _●_)　 |ﾉ　/　　　今はここら辺クマーー！！
　　　　　　　　　　　　　　　　　　　　　　彡､　　　|∪|　　　　,/
　　　　　　　　　　　　　　　　　　　　　／　　　　ヽノ　　　 /

598:デフォルトの名無しさん
08/07/27 17:39:05
ごめんずれてる

599:デフォルトの名無しさん
08/07/27 21:48:06
　　　　　　　　　　　　普通　　　　　まったり　　超まったり　dat落ち寸前
　　　　　　　　　　　　　┝　-　-　-　-　┿━━┿━━━┥
　　　　　　　　　　　　　　　　　　　　　　　　　　　　∩＿＿＿∩　　　/)

600:デフォルトの名無しさん
08/07/29 19:06:09
"\psage"

601:sage
08/08/20 10:31:33
sage

602:デフォルトの名無しさん
08/08/21 05:21:02
すみません。教えてください。
a = [foo bar_A:[s get] B:[s get]];
というステートメントがありまして、いろいろ実験してみますと、
どうもB:[s get]がA:[s get]より先に実行されてるっぽいです。
どうしてなのか知りたいのですが。

603:デフォルトの名無しさん
08/08/21 06:02:59
引数の評価の順番って保証されてたっけ？
というか普通は保証されないから理由なんてないと思うよ

604:602
08/08/21 08:31:49
>>603
わかりました。ありがとう！

605:デフォルトの名無しさん
08/08/22 17:35:38
関数の引数をスタックに積んで渡す場合に逆順に積むと、
呼ばれた側で先頭から配列のようにアクセスできて楽だから。

606:デフォルトの名無しさん
08/08/22 23:33:22
>>605
それでいくと、IntelとPowerPCで動作が変わるのかな？

次ページ