Objective-C

1 名前：デフォルトの名無しさん mailto:sage [05/01/29 16:18:12 ] ほんとプログラマにとってはMacって 本当に興味が無いOSだよねｗ Macでの標準的な言語であるObjective Cのスレすら無いし。 過去にはあったんだろうけど。 898 名前：デフォルトの名無しさん mailto:sage [2007/04/24(火) 12:55:18 ] Accept-Encoding : gzip に答えてサーバーが gzip してコンテンツを返す かつ レンジ指定の場合 そのレンジは”何に対して”のレンジでしょう？ 元のコンテンツですか？違いますか？ 違う場合は、何に対してですか？ 899 名前：デフォルトの名無しさん mailto:sage [2007/04/25(水) 08:09:24 ] >>898 curl -H 'Range: bytes=6198-' -A 'Monazilla/1.00 (Jane/0.01)' -H 'Accept-Encoding: gzip, deflate' -H 'Accept: text/plain' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' -H 'Connection: keep-alive' news21.2ch.net/namazuplus/dat/1177098491.dat | gzip -d -c curl: (18) transfer closed with outstanding read data remaining あれ、zip元のデータ長ではないのですね… 900 名前：デフォルトの名無しさん mailto:sage [2007/04/25(水) 22:09:45 ] 2ch の dat を差分取得しようとするときに誰もがはまる罠です。 不意のコネクション切断等のときに、 その続きを取得する時のことを考えれば、 この動作が”正しい”ことが分かると思います。 http コンテンツで 2ch の dat の様に差分を取得できる物って そんなに無いと思いますよ。 901 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 22:42:59 ] selfでないインスタンスオブジェクトに対して->を使って @protectedまたは@publicなインスタンス変数にアクセスするのって お前ら的にはどうなの？ 902 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 22:48:35 ] そういうおまえはどうなのよ 903 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 23:40:48 ] インスタンス変数fooがあったとして、 メソッド内でselfを書き換えるとself->fooはもちろんとして 修飾なしのfooも実体が書き換えた後のインスタンスのインスタンス変数になるみたいなのですが、 これって処理系(gcc)依存の挙動でしょうか？それとも言語規約通りの挙動でしょうか？ すなわち、メソッド内において(& foo == & self->foo)が常に成り立つのでしょうか？ 904 名前：デフォルトの名無しさん [2007/05/05(土) 03:16:03 ] 《プログラミング言語の本来あるべき正しい進化》 C言語→Objective-C→D言語 《忌まわしき現実》 C言語→C++→JAVA→C# 905 名前：デフォルトの名無しさん mailto:sage [2007/05/05(土) 04:36:28 ] >>904 《忌まわしき事実》 C++(膨張した言語仕様への反省)→Java(もっと簡素・洗練しろ！)→C# 906 名前：デフォルトの名無しさん mailto:sage [2007/05/05(土) 06:41:41 ] 《とりあえずそれなりの仕事になった順番》 C → C++ → Perl → ASP → PHP → Ruby → Java 907 名前：デフォルトの名無しさん [2007/05/05(土) 09:17:03 ] そしてNemerleの時代へ 908 名前：デフォルトの名無しさん mailto:sage [2007/05/05(土) 13:28:30 ] Visual Objective-C出たら考える 909 名前：デフォルトの名無しさん mailto:sage [2007/05/05(土) 18:26:33 ] そんなものでたらCに戻る 910 名前：デフォルトの名無しさん mailto:sage [2007/05/05(土) 19:08:06 ] >>909 まじで、最近は一部C言語に回帰しているね。 プレゼンテーションはJavaとC#に収束。 Web系以外のサーバーサイドは、C言語がいい場合がある。 911 名前：デフォルトの名無しさん mailto:sage [2007/05/05(土) 20:05:24 ] Objective-C.NET 912 名前：デフォルトの名無しさん [2007/05/05(土) 23:41:59 ] 言語仕様はObjective-CよりもC++のほうが優れている。 多機能という意味では。 しかしC++プログラマーの大半はC++を使いこなせていない。 大抵はベターＣとして使っている。 だからほとんどのプログラマーにとってObjective-Cの機能は十分なんだ。 BorlandのVCL並のRADツールを備えたWindowsで使える統合開発環境さえあれば Objective-Cは即座にC++を駆逐するだろう。 C++が普及したのはひとえにVisualC++の存在が大きい。 913 名前：デフォルトの名無しさん mailto:sage [2007/05/06(日) 00:16:26 ] >>912 まあ、C++はC and ++だからな。 C++をフルに使いこなすには、C標準ライブラリ使用禁止、非クラス関数禁止でもしないと 追加機能付きCとして使ってしまう。 914 名前：デフォルトの名無しさん mailto:sage [2007/05/06(日) 02:43:54 ] ObjC は C++ に比べて動的型決定なのも受け入れられない理由の一つかと 915 名前：デフォルトの名無しさん mailto:sage [2007/05/06(日) 07:50:01 ] しかし動的型決定のないObjCなんて・・・ 916 名前：デフォルトの名無しさん mailto:sage [2007/05/06(日) 17:52:53 ] >>912 >BorlandのVCL並のRADツールを備えたWindowsで使える統合開発環境さえあれば Mac OS XならXCodeとInterfaceBuilderがある。 ただObjective-CやれるのAppleぐらいだしWindowsへの進出はなさそうだな。 917 名前：デフォルトの名無しさん mailto:sage [2007/05/06(日) 21:10:57 ] InterfaceBuilderのIntel版はあったんだけどね 918 名前：デフォルトの名無しさん mailto:sage [2007/05/06(日) 22:29:25 ] そりゃ、MacOSXはIntel上で動きますから。 と釣られてみるテスト。 919 名前：・∀・）っ-○◎● mailto:sage [2007/05/07(月) 00:05:15 ] NeXT OSのIntel版じゃないの いや、Windows進出の野望はあったにはあったみたいだよ。 YellowBoxってのが。 ポシャったけど。 APIとしてのQuickTime for Windowsを提供する予定は 無いようだしな。 920 名前：デフォルトの名無しさん [2007/05/07(月) 01:47:52 ] こんなん？ QuickTime 7.1 SDK for Windows (ZIP) developer.apple.com/quicktime/download/ 921 名前：・∀・）っ-○◎● mailto:sage [2007/05/07(月) 02:03:32 ] どっちかというとそれプレイヤーのプラグイン書くためのSDKのような MacのQuicktime APIって、WindowsでいえばDirectXみたいな もんじゃなかったっけ。 922 名前：デフォルトの名無しさん [2007/05/07(月) 06:03:08 ] WinAPIってこの先どうなるのかね？ それがわからんとWin対応のObjective-Cなんておいそれと作れたもんじゃない。 Obejective-CってのはC言語にオブジェクト指向とかGCとかをマクロ機能を使って搭載したやつだ。 だから言語そのものに機能を組み込んでいるC++とは違うんだな。 ただあれだよね。 常に機能を追加するという発想。 そこはC++と同じ。 JAVAやC#みたいに機能に制限を加えるという発想はない。 Objective-Cを普及させるならば案外その辺がポイントなのかもしれんと思った。 923 名前：デフォルトの名無しさん mailto:sage [2007/05/07(月) 07:05:08 ] という話は15年くらい前から何も変わってない訳で 924 名前：デフォルトの名無しさん mailto:sage [2007/05/07(月) 13:51:05 ] マクロ機能というのは言い過ぎでは... まあ runtime の上の syntactic sugar であるのは事実だけども。 925 名前：デフォルトの名無しさん mailto:sage [2007/05/08(火) 00:35:53 ] もともと C の思想はプログラマを信じる事だから、C の延長上に機能制限なんてものは無い。 間違いのように見えても、プログラマ様がお書きになられたコードは絶対なのです。 926 名前：デフォルトの名無しさん mailto:sage [2007/05/08(火) 01:19:43 ] まあマシン語も埋め込める最強の言語だし、なんでもできる。 OSを作るための言語だけの事はある。 927 名前：デフォルトの名無しさん [2007/05/08(火) 06:52:22 ] 安全性と柔軟性は両立しないと。 928 名前：デフォルトの名無しさん mailto:sage [2007/05/09(水) 00:50:53 ] 女は両方好む 929 名前：デフォルトの名無しさん mailto:sage [2007/05/09(水) 22:09:08 ] ちょっと入り組んだ書き方するとLispも真っ青な括弧の入り組み方になるなぁ カスケード記法があればいいのに Lispと違ってうまくインデントスタイルが組めないから読みにくい 930 名前：デフォルトの名無しさん mailto:sage [2007/05/09(水) 22:30:27 ] Lispほどネストする必然がないと思うのだが… 931 名前：デフォルトの名無しさん mailto:sage [2007/05/09(水) 22:36:27 ] カスケードくらい追加できる気がするけど、何か文法的に問題があるのかな 932 名前：デフォルトの名無しさん [2007/05/14(月) 11:33:35 ] Objective-Cのオブジェクトシステムの部分はSmalltalkの影響を受けているわけで、 そのSmalltalkはLispの影響を受けているので、括弧が多くなるのはそういう理由からでしょう。 933 名前：デフォルトの名無しさん mailto:sage [2007/05/14(月) 12:01:36 ] ふーん 934 名前：デフォルトの名無しさん mailto:sage [2007/05/14(月) 12:37:10 ] >>932 すごい三段論法だな。ｗ というか、どうして lisp や smalltalk をろくに知りもしないのに そういう見てきたような嘘をつくかなー。 objc が smalltalk の影響を受けているのは [ ] の中だけ。 というか、objc の [ ] の中は、smalltalk の世界。 objc は smalltalk のコードを C コンパイラに通すためのプリプロセッサとして 開発された経緯がある。そんなわけで、[ ] のネストの多さは objc の勝手な事情で smalltalk とは無関係だよ。 あと、smalltalk への lisp からの影響は、everything is an object のポリシーや クロージャ、ブロッククロージャメソッドのたぐいで、 S 式（つまりこの文脈でいうところの括弧の多さ）じゃあない。 ちなみに残念ながら objc は、これら（lisp からの影響）の恩恵の外にある。 メタクラスやメソッドはオブジェクトじゃないし、ブロッククロージャメソッドはおろか、 ブロック（クロージャ）すら使えない。これらは objc の言語拡張のやりにくさや イントロスペクションの貧弱さ、コレクションの扱いにくさとして出てくる。 935 名前：デフォルトの名無しさん mailto:sage [2007/05/14(月) 14:19:56 ] ま〜たそんなマジレスしちゃって。 936 名前：デフォルトの名無しさん mailto:sage [2007/05/14(月) 14:53:23 ] >>934 がマジレスしてくれなかったら俺がマジレスする所だったわ 危ない危ない… 937 名前：デフォルトの名無しさん mailto:sage [2007/05/14(月) 16:53:09 ] >>934 > ブロック（クロージャ）すら使えな 使える処理系もあるけどね。 938 名前：デフォルトの名無しさん mailto:sage [2007/05/14(月) 19:43:36 ] poc poc ﾁｰﾝ 939 名前：デフォルトの名無しさん [2007/05/14(月) 21:09:12 ] 説明していただきありがとうございました。 おかげでOjective-Cの勉強を諦めることが出来ました。 感謝します。 940 名前：デフォルトの名無しさん mailto:sage [2007/05/14(月) 21:24:24 ] まだ ObjC にクロージャ入らないんだっけ? 941 名前：デフォルトの名無しさん mailto:sage [2007/05/15(火) 00:01:30 ] クロージャを入れるのは一苦労じゃけん 942 名前：デフォルトの名無しさん mailto:sage [2007/05/15(火) 00:05:46 ] ふーん 943 名前：デフォルトの名無しさん mailto:sage [2007/05/15(火) 00:29:33 ] そこでRubyですよ 944 名前：デフォルトの名無しさん [2007/05/15(火) 00:52:11 ] Objective-Cやっている人はそれがC++よりも優れていると思う？ それともMacについてきたからやっているの？ 945 名前：デフォルトの名無しさん mailto:sage [2007/05/15(火) 00:59:06 ] 優れているところもあるし劣っているところもある ちなみにMacOSXについてるのは Objective-C じゃなくて Objective-C++ だから 946 名前：デフォルトの名無しさん mailto:sage [2007/05/15(火) 02:34:24 ] > ちなみにMacOSXについてるのは > Objective-C じゃなくて Objective-C++ だから ちがいます 947 名前：デフォルトの名無しさん mailto:sage [2007/05/15(火) 16:14:25 ] >>944 C++より先にObjCを学んだからC++使ってると違和感を感じることがある。 多分C++が先な人は逆なんだろうけど。 948 名前：デフォルトの名無しさん mailto:sage [2007/05/16(水) 19:40:39 ] 俺はどうもC++の変数の型の縛りが苦手だなあ。 virtualとか、何種類もあるキャストとか... そんなわけで最近はruby。Cocoaも呼べるし。 949 名前：デフォルトの名無しさん mailto:sage [2007/05/16(水) 22:01:25 ] 使いやすいのでいいんじゃない 950 名前：デフォルトの名無しさん mailto:sage [2007/07/01(日) 21:02:32 ] ほしゅ 951 名前：デフォルトの名無しさん mailto:sage [2007/07/19(木) 04:34:52 ] ttp://ja.doukaku.org/lang/objectivec/ 952 名前：デフォルトの名無しさん mailto:sage [2007/07/19(木) 09:40:00 ] >>947 先にC++だったけどC++使ってると違和感を感じる やっぱりObjective-Cの方がいいよ 953 名前：デフォルトの名無しさん mailto:sage [2007/07/19(木) 09:50:28 ] ＞先にC++だったけどC++使ってると違和感を感じる これって、MFCじゃね？ MFCとCocoaを比較したらCocoaがマシかもしれない。 でもMFCのトンデモ設計とちょーサイアクGUIビルダーよりましといった事に意味は無い。 954 名前：デフォルトの名無しさん mailto:sage [2007/07/19(木) 22:22:06 ] 何で C++ == MFC だと思ったのかな? 955 名前：デフォルトの名無しさん mailto:sage [2007/07/20(金) 02:14:36 ] かな？ 956 名前：デフォルトの名無しさん mailto:sage [2007/07/20(金) 08:50:11 ] だって、C++Builderなんて使ったらCocoaの変にIDEにコントロールされて 逆にMVCを開発者側が制御できない変なもの使ってられないよ。 MVCを変に制御して困るものでC++といえばMFC。 957 名前：デフォルトの名無しさん mailto:sage [2007/07/20(金) 09:52:47 ] どっからMVCなんて出てきたんだか。 958 名前：デフォルトの名無しさん mailto:sage [2007/07/20(金) 10:20:20 ] ttp://developer.apple.com/jp/documentation/cocoa/Conceptual/CocoaBindings/Concepts/WhatAreBindings.html#//apple_ref/doc/uid/20002372/175802 959 名前：デフォルトの名無しさん mailto:sage [2007/07/27(金) 20:00:51 ] 日本語でok　って言うトコロなんだと思う 960 名前：デフォルトの名無しさん mailto:sage [2007/08/06(月) 11:22:30 ] プロトコルと抽象クラスってどういう風に使い分ければ良いのよ 961 名前：デフォルトの名無しさん mailto:sage [2007/08/06(月) 12:07:29 ] Objective-C 2.0 には抽象クラスがあるの？ 962 名前：デフォルトの名無しさん mailto:sage [2007/08/06(月) 12:32:23 ] いや、言語仕様にはないけどさ… 963 名前：デフォルトの名無しさん mailto:sage [2007/08/07(火) 10:38:33 ] どっちも使わない。ふつうは informal protocol というか単にセレクタの名前を取り決めておくだけ 964 名前：デフォルトの名無しさん mailto:sage [2007/08/07(火) 11:05:51 ] もうObjective-C廃止にしない？ Mac OS XとC++でポトペタ開発しようよ。 965 名前：デフォルトの名無しさん mailto:sage [2007/08/07(火) 11:14:55 ] C++なんてクソ言語使ってられるかっつーの 966 名前：デフォルトの名無しさん mailto:sage [2007/08/07(火) 12:01:59 ] というか Interface Builder はポトペタの元祖なのでは？まあ癖はあるような気がするけど。バインディング可なパレットきちんと作っておくと殆ど IB だけで出来るべ 967 名前：デフォルトの名無しさん mailto:sage [2007/08/07(火) 12:07:23 ] 出来るってだけで、GUIの凝ったコントロールを作る事が不可能だお。 968 名前：デフォルトの名無しさん mailto:sage [2007/08/07(火) 12:49:00 ] ポトペタってなんですか＞＜ インターフェースビルダーよりどこが凄いのか押しえて下さい！！！！ 969 名前：デフォルトの名無しさん mailto:sage [2007/08/07(火) 13:03:28 ] コンポーネントを派生して、差分コーディングで処理を足して、画面に"ポトペタ"貼る事でつよ。 他人のハイパーなコンポーネント使ったり、ネットに派生コンポーネントが溢れたりするお。 970 名前：デフォルトの名無しさん mailto:sage [2007/08/07(火) 13:16:29 ] それはまさに IB でパレットから D&D して、カスタムクラスを設定することだとおもうんだけど、どっか違うの？ Apple が提供してる以外の新規パレット自体をつくることもできるよ。 www.bignerdranch.com/palettes/ 確かにネット上にカスタムパレットが溢れてはいないが ... 971 名前：デフォルトの名無しさん mailto:sage [2007/08/07(火) 13:26:51 ] 派生前クラスのソースコードって公開されてる？ やっぱ、クラス派生する場合にはそれが無いとスゲー足かせだお。 972 名前：デフォルトの名無しさん mailto:sage [2007/08/07(火) 14:07:21 ] というか、Cocoa のプログラミングは 1) view はパレットから D&D してカスタムクラス 2) controller も最近はバインディング用のをパレットから D&D 3) model は手で書いても良いし、CoreData でも良い だとおもうんだけど。 Apple 提供のパレットはソースコードは流石にないよ。でもドキュメントは(英語なら)完備してる。まあ GNUStep が 8割方再実装してるから読みたけりゃよめばいいけど。 ネットにころがってるのは、そもそも数が少ないけども、ころがってるやつはソースも配ってると思うよ あと、Objective-C はカスタムクラスが面倒だったら、元クラスのソースコードもってなくても元クラスにメソッドを追加できるよ。これは非常に便利。 973 名前：デフォルトの名無しさん mailto:sage [2007/08/07(火) 14:12:17 ] ＞1) view はパレットから D&D してカスタムクラス やっぱ、そうだよね。 プロジェクトと強く結びついたカスタムクラスであって、 クラスライブラリのベースクラスが派生したハイパークラスで溢れる、 というイメージじゃないだよね。 974 名前：デフォルトの名無しさん mailto:sage [2007/08/07(火) 14:21:49 ] 別にプロジェクトと強く結びついてんくても良いんだけど。 975 名前：デフォルトの名無しさん mailto:sage [2007/08/07(火) 14:25:37 ] まあハイパークラスなんて配られてないからね。 Apple 謹製の NSTextView, WebView は充分 Hyper な気がするけど。 あと、Cocoa ではクラス派生をする前に大抵の処理は delegate で済む気もする。 (コントローラが標準 view の機能を拡張できるみたいなかんじ) ポトペタでハイパーなコンポーネントののってるページの例をなんか URL おしえてください 976 名前：デフォルトの名無しさん mailto:sage [2007/08/07(火) 14:33:25 ] ttp://hp.vector.co.jp/authors/VA015730/vcl/vclworld.html ttp://norg1964.hp.infoseek.co.jp/delphianworld/ 977 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 00:43:11 ] o ひとつめの URL にあがってるような機能は Cocoa /Carbon API にある気がする o ふたつめのにはいっぱいカスタム GUI コントロールがのってるけど、 あんまり Apple はカスタムコントロールをつくるのは推奨してない気がするし、 そういうことすると OS X ぽくないソフトになりがちで嫌われがちだと思われる 978 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 00:45:43 ] shiira.jp/hmblkappkit/ こういうカッコいいコントロールもあるよ。まあ Apple がまだ公開してない API を再実装した奴だけど、Interface Builder でふつうに配置してクラスの名前をこれにかえるだけで使える 979 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 01:38:51 ] MacのプロアプリのようなUIにしたければカスタムするしかないよね。 スライダーとか機能的にも不十分だしIBにあるパーツだけじゃ足りなくなってきたからパーツの作り方勉強しなきゃ。 980 名前：・∀・）っ-○◎● mailto:sage [2007/08/08(水) 02:12:08 ] リストボックスをオーナーデータ化するにはどーすりゃいいんだ？ 981 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 08:48:20 ] ＞あんまり Apple はカスタムコントロールをつくるのは推奨してない気がするし、 これが今の時代の開発ではネック。 ＞そういうことすると OS X ぽくないソフトになりがちで嫌われがちだと思われる だからコントロールを派生して元々OS Xの描画の上に描画を足したり処理を足したりするわけじゃん。 982 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 11:16:36 ] >>979 ProKitでなんとかなるかもしれないけど。 983 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 11:40:52 ] >>981 まあ確かに、機能豊富で、ちゃんと Cocoa の window にマッチするパレット集が一杯おちてたら便利だろうね。 もうちっとデヴェロッパ層が厚くならないとだめかな。 984 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 12:11:56 ] ええと、そろそろCocoaスレに行ってくれません？ 985 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 12:20:11 ] >>978 この黒パネルはLeopardのIBで実装されてる。 986 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 12:25:15 ] 次スレ pc11.2ch.net/test/read.cgi/tech/1186543111/ 987 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 12:29:14 ] >>984 Cocoa の話が駄目とすると GNUStep も駄目？ 988 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 12:37:22 ] 漢は黙って objc/Object.h をインポート 989 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 13:39:09 ] >987 AppleがCocoaで新たに組み込んだ関係がうぜ〜って事じゃね？ IBの話すんならGORMの話しろや！ってきっといいたいに違いないと思ってるのだが（w あ，クラスライブラリはどうでもいい言語そのものの話をしたいって人だったのかも＞984 990 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 14:22:59 ] OOP言語ならクラスライブラリと切り離して話できんわ。 991 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 15:24:09 ] そこでObjective-C標準クラスであるObjectを… 992 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 18:27:56 ] Object.hと同じディレクトリにList.hってのもあるんだけど、 ListもObjective-Cの標準クラス？ 993 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 22:29:02 ] 純粋に Objective-C の話ってなかなか難しいのでは ... Apple の独自拡張も多いし。 Object と NSObject がどっちが「標準」かというと、 一社/一グループの実装だけじゃなくて、 標準を定めた文書が別個に存在するかという意味では Openstep のほうが「標準化」されているのではないかと思わなくもない GCC もせめて GNUStep の non-GUI 部分を一緒に配布してくれればいいのに。 994 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 22:38:23 ] 基本Java厨で、現在C++で食っていきながら、 Rubyが一番好きかも知れないという俺ですが、 Objective-Cに興味を持っています。 他のOOPLとくらべてどうでしょうか。 メリットとかデメリットとか。 995 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 22:44:25 ] 実際に運用する上で言語使用だけを他の OOPL とくらべるのは難しい... Cocoa つかうぶんには非常に便利ですよ。 RubyCocoa も Leopard から標準になるので Ruby が いいならそれでいいけれども、API の仕組みはかなり Objective-C に影響されているので、 RubyCocoa を使うための基礎として Obj-C を学ぶのは悪くないと思う GNUStep はちゃんとつかったことがないのですいません C++ を知っているひとのための、C++ と Obj-C の文法の比較は ktd.club.fr/programmation/fichiers/cpp-objc-en.pdf が簡単にまとまってる。英語だけど。 996 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 22:49:00 ] >>994 CとJavaが使えるなら30分で覚えられるからとりあえず使ってみれ 997 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 22:51:58 ] ご丁寧にどうもありがとうございます！！ Cocoa使ってウハウハにも興味はあるんです。 Win32でどうのこうのに飽きちゃってですね。 言語としても興味津々なんでリンク先熟読します。 998 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 22:52:59 ] >>996 やってみます！ で、998ゲットォ！！ 999 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 22:55:59 ] そういう興味のある人なら Apple のこのあたり Objective-C Language developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/index.html Cocoa Fundamentals Guide developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/index.html が面白いかも。あと他にもいっぱいあるよ: developer.apple.com/documentation/Cocoa/index-date.html いや、GNUStep にリンクはらんで済まんね ... 1000 名前：デフォルトの名無しさん mailto:sage [2007/08/08(水) 23:03:19 ] 次スレ立てました Objective-C Part3 pc11.2ch.net/test/read.cgi/tech/1186581730/ 次スレでもみんなよろしく〜 1001 名前：１００１ [Over 1000 Thread] このスレッドは１０００を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef