  |
はてなキーワード: Objective-Cとは
Appleが推奨するデスクトップ（アプリは全画面で使ってバーチャルデスクトップを切り替えろ）
Appleが推奨するポインティングデバイス（マルチタッチを活かすためにトラックパッドを使え）
Appleが推奨するソフト管理（CD・DVDドライブは要らないAppStoreを使え）
Appleが推奨するアプリ開発（Objective-C！）
Appleが推奨する読書（iBooks）、Appleが推奨する映像鑑賞（AppleTV）、Appleが推奨する生活（iLife）…
すくなくとも、ラッパーかませば C＋＋では作れるから問題無いだろ。
でC++が使えるんだからJavaだってRubyだって動くわけだし、動かしてる人もいるわけだ。
ごく単純に言えば Objective-C は GCをつんで、ポリモルフをvtableではなくて、動的マップテーブルを使ったC++のライブラリだと思えば
って質問に実際に使ってるほとんどの人が『Apple製品で動くから』って答えると思うんだがどうだろうか。
なんか他の言語と比較して、Objective-Cを選ぶ理由がそれ以外思いつかなかった。
それでも、ここまでObjective-Cを引っ張って行ってるAppleの巨人さがやべえなーと考えながらも
Objective-C自体は糞言語で、言語自身の価値なんてなかった。
例えば、C++やGoやJavaやRubyでもApple製品でObjective-Cと同じようにアプリを作ることができます！
とかなったとするだろ？
「それでもObjective-Cを選ぶ！」という人の
Objective-Cが他の言語を押しのけて有利に立てる箇所を知りたい。
Objective-Cは言語戦争に引きずり出された時勝つことができるのか？
カネの力ねぇ。
デファクトになるにカネは必要だが、カネを得るには良い所がなきゃダメだろ。
つか、言語言語ってやる事出来る事は五十歩百歩だろ。要はやり易いか否か。
後は文法が単純単機能なことだな。言語としては単純で、標準ライブラリが多機能でそっちで何でもできる。それが一番。
無駄に文法多くて自由に書けるとかいったらカオスってクソになってくに決まってるだろ。
後付けライブラリが沢山、自由に選べる作れるってのもカオス。自由って何求めてるの？
C++はCの資産あるうちは良かったよ。でもそれだけ。あとに碌なライブラリ残さなかった。
javaはライブラリに力入れてたし、文法もまあまあすっきりしてる。PHPも近い所はある。
javascriptはダメだ。ただDOMがある、それだけだ。
pythonはライブラリがそこそこいい。ただ、言語自体は下手に色々ありすぎ。
それでもperlよりマシ。あれはCとshしかなかった時代だからこそのもの。
perlの後釜なんにするの？python以外あるの？つか、日本に選択権ないって言ってるじゃん。
つか、javascriptはDOMなきゃ意味ないし、javaはVMなきゃ意味ないし、PHPはHTMLなきゃ意味ないし、
C#はMicrosoftなきゃ意味ないし、Objective-CはAppleなきゃ意味ないし。
棲み分け出来てるのに、それ以外どうするの？
つか、SQLどうにかしろよ。
272 ：名無しさん＠引く手あまた：2012/03/07(水) 01:07:37.91 ID:ycorXG6u0
これで生き残れ
javaやlinuxは手間がかかる 一人でやるには手間がかかりすぎる 手間がかからないで一人で一括開発できて
人の多いところで直接販売できる仕組みが提供されてているメーカ製の言語だけやる ずばりiphone またはWindow 8 Metro App Store C#
やるならメーカー製の言語、洗練された仕様、脆弱性が少なく 開発ソフトが優れていて開発しやすく情報も多い
奴隷になりたければオープン系をやればいい 時間がかかり 人は多く 足の引っ張り合い 脆弱性が多く 癖があり
大規模開発で詳細設計しかやれない体になって年取ってぽいだ 独立もできない 手間のかかりすぎる仕様だから
派遣屋・IT経営者はその方が喜ぶ 分散開発で使い捨てしても独立されない 代わりはいくらでもいる ひどいピンハネ 嫌なら辞めろ
オープン言語、日本独自開発フレームワーク ガラパコ携帯 html5 Android java linux codezineやgihoでよく紹介されるステマ言語rubyやnode.jsとかやめとけ メディアで釣っておいて数年後廃れて自己責任だと言われ捨てられる
手間がかかり一人でできない 売る場所もない 金にならない 使い捨てられ続け 生きれない ずっと奴隷仕様のままだ ここから抜け出すにはiphone一択 またはWindow 8 Metro App Store(未確) C#
Objective-CやC#を身に着けるとサーバーからクライアントまでカバーでき人の多い場所でソフトを売る権利を得られる セーフティーネットを得ることができる
派遣切りされても会社辞めることになってもソフトを売って生きていける オープン言語にはそれがない
潰しのきかないガラパコ日本仕様、オープン言語の完全否定から始めよう！！
地方で安い土地を買いコンテナ型の格安高性能オフィスを建て(300万～500万)
先日「Flashエンジニアが今後10年食べていくには？」というテーマを元に
Flash に精通した Web 技術者達のディスカッションが行われる催し物があった。
http://www.publickey1.jp/blog/11/flash10.html
この記事だけでは内容が省略しすぎているため
時間があれば是非録画の模様もみていただきたい。前半初頭は音量が小さいので注意。
こういった催し物は面白いなと、私はとても楽しく見させていただいた。
http://www.ustream.tv/recorded/19073524
http://www.ustream.tv/recorded/19074357
ディスカッションでは Flash だけではなく HTML5 についても触れている。
ディスカッションの感想をディレクションや営業を行なっている知人に聞いたり、
ネット上の反応を見てみたところ以下のような意見がいくつかあった。
「『Flash が好きな人』だけではなく HTML5 派の人との対談もあればよかった」
「Flash 派の人の話だから HTML5 が使えないという話はいまいち参考にならない」
『Flash 派』『HTML5 派』という くくりで考えてしまう人は
まだまだ多いと実感する。
パネリスト達は
過去から現在までに様々なプログラミング言語を利用し、あらゆる技術に精通している。
Flash という表示媒体/環境開発がベター(時にはベスト)だと考え、
Flash をよく扱っている、という旨を話している。
最後の締めとして
Flash よりも優れたものが登場するのであればそちらに移行するでしょう、
とも言っている。
これだけの説明があったのに
ディスカッション内で触れた HTML5 に対する否定的な話は、
『Flash 派』とやらのポジショントークだと目に写ってしまったのだ。
Java やら C やら objective-c やら perl やら php やら
サーバサイドからスマホ用ネイティブ言語を用いてのアプリ制作まで
色んな事やってます、と言っても
現在世の中には HTML5 を推し、合わせて Flash を否定する記事が結構出回っている。
技術者が話す専門的な用語の飛び交う話よりも
HTML5 vs Flash 的な読みやすい記事に耳を傾けてしまう人はいる。
Apple 製品を好む人は「ジョブズがそう選択したのだから」と
なおさらこういった記事に目を向けてしまう。
「Flash vs HTML5 の話にのせられてしまうのは、よくわかっていない人だ。」
ディスカッション内では、
ネット上の煽り記事を読み不安に思ったクライアントから連絡を受け
きちんと状況をゼロから説明するハメになってしまった、という内容があった。
似たような状況になっている人もいるのではないだろうか。
当方周辺では、
「Flash は駄目だ」「Flash でなくても HTML5 ならできるはずだ」
「HTML5 は Flash の代わりになるものだと言われている」と
クライアント、あるいは仕事先の関係会社から耳にする機会が増えてきた。
技術者の及ばないところで
ベターではない技術が選択、あるいは勧められてしまう やっかい性。
その記事は世間の目には届かない。
TV CM でバンバン流れている iPhone や iPad では Flash を見ることができない
という状況に乗じた
勘違いを正すためには、今までよりもより一層
あるいはメッセージを発信するよう心がけていかねばならないと感じる。
パネリスト達のような
Flash を扱う事が可能な技術力を持ち合わせている人にとって
Flash が終わろうが、代わりの技術が HTML5 やらその他何になろうが
大した影響はない。
『プログラミング』についての話をしてみる事にする。
「世にあらゆるプログラミング言語があるが
「何か一つ言語を習得し
『Flash の事は全く知らないがプログラミングプロフェッショナルの人』
が近くにいるならば是非上記について伺ってみてほしい。
その通りだと答えてくれるはずだ。
他の言語で作ったものを Flash のプログラミング言語に移植することも容易いのだ。
ここで上記三行の「他の言語」を「JavaScript」に置き換えてみてほしい。
HTML の DOM 操作に必要な言語は JavaScript である。
言語は、Flash ならば ActionScript、HTML5 ならば JavaScript を用いる。
画面描画は
あるいは用意されている描画用 API を ActionScript で呼び出し、
あるいは用意されている描画用 API を JavaScript で呼び出す。
Flash と似たような技術として Java Applet や Shockwave があるが、
これらも一緒で
言語を変え、その技術に合わせた描画を行う処理を記述するだけだ。
Web 技術者が何かに属していて、何かには属していないかのような区別の仕方は
的がはずれている事を なんとなく感じていただけただろうか。
仕事に対し、あるいは表現したい事に対し、ベターな選択を行うだけの事なのである。
環境や表示内容に合わせ両方を採る選択もあるだろう。
パネリストの中に ActionScript が好きだ、という人がいた。
これは別に
Flash が好き(製品のファン)だから ActionScript が好き、と言っているのではない。
ActionScript が優れたプログラミング言語だと判断しての発言なのだ。
HTML5 を選択するだけの事であり、
その別の技術を選択し、
Flash より優れた技術が登場しなければ Flash を使い続ける、
ただそれだけの事なのである。
もう少し突っ込んだ話をすると
Flash のプログラミング言語である ActionScript(ActionScript 1.0)と
HTML 表示制御を行う言語 JavaScript は 実は同じ言語仕様である。
『ECMAScript』という単語で調べてみてほしい。
「Flash と HTML5 は対立するもの」と考えていた人、
あるいは ActionScript や JavaScript を触れたことがない人にとって
「え？そうなの？」と思う人もいる事だろう。
JavaScript は大規模開発に向いていない、という話は聞いたことがないだろうか。
同様の言語仕様である ActionScript 1.0 はこの問題を解決するため
ActionScript 2.0 から ActionScript 3.0 へと進化していった。
Flash は開発がし易い、という話がよく挙げられるが
その理由の一つがこれである。
現行の JavaScript と ActionScript 1.0 は ECMAScript 3 準拠に対し、
ActionScript 3.0 は ECMAScript 4 準拠である。
言語として進化しているものを Flash は採用しているので
開発は抜群にし易い。
ECMAScript 4 準拠の JavaScript も登場する日もあったかもしれなかったのだが、
ECMAScript 4 標準化が白紙、
ECMAScript 4 は無かったことになってしまったのだ。
ActionScript 3.0 で作成したプログラムが
ちなみに JavaScript は大規模開発に向いていない、という事に対し、
最近では Google が新言語 Dart というものを開発している。
位置づけとしては ActionScript 2.0 に近いと比喩した人もいる。
ActionScript 2.0 はコンパイル時 ActionScript 1.0 に変換されて出力される。
Dart も同じく JavaScript 変換機能を持つ。
先の事は誰にもわからない。
HTML5 が成長するとは必ずしも言えない。
技術者は身を持って知っている。
表示と動作の差異、技術者はずっと苦しめられてきている。
めんどくさい。コストがかかる。
HTML5 も同じ道を辿るのでは、と言われてしまうのも仕方がない。
実際に HTML5 の各ブラウザの実装具合はバラバラである。
Flash はといえば、
今でも 10年以上前のスクリプト言語 (ActionScript 1.0 よりも前の言語)で
Flash が動作するブラウザがいつまで携帯に搭載され続けるのか、
まだ誰にもわからない。
今後も当面携帯向け Flash を作り続ける事になるのかもしれない。
携帯向け Flash は一つの容量が小さいというのが救いである。
IE6 対応 HTML サイト制作にせよ、携帯向け Flash 制作にせよ
状況に応じて何を選択するかを判断できるほどの技術力を身につける事
選択する技術に何ができて何ができないのか、
どの技術を組み合わせるとよいのか、
自ら判断できるようになった時、一人前の Web 技術者になったと言えるだろう。
一つ何かをモノにしてしまえば前述の通り移行は容易い。
それを極めるくらいまでとことん勉強してほしい。
続けていくと見えてくるはずだ。自信という名の悟りの道が。
気になった点をいくつか。
現状の HTML5 の実装具合のバラバラさに対し、
「(HTML5の)表示の差分を埋めてくれる何かが登場するかもしれない」
と言う発言があった。
言った当人も会場にいる人達も、きっとこう思っただろう。
「それってなんて Flash Player？」と。
「あれはやめたほうがいい」という発言があった。
勝手に注釈するのであればこの発言は
「Flash で作られた重たい Web を HTML5 でまた再現するつもりなの？」
という皮肉であろう。
2010/05/16 23:40
こんにちは。昨日会った者です（これで特定するには情報不足だけど、まあわかるよね）。
で「幅優先探索でやる」という方針自体はいいと思うし、データ構造の作り方も基本は押さえていると思います（斜め読みしかしてませんが）。
ただ、コーディングの発想が「C で作る」という大方針から見て、少しちぐはぐな印象も受けます。データ構造の設計や操作の部分、汎用のライブラリを作ろうというのならあれでもいいと思うのですが、わざわざ汎用のライブラリを使わずに自分で専用の道具を一から作ろうというのなら、問題の性質を考慮して能率良くやることが大事です。
ところが、ここに載っているコードを見ると、見かけが C らしくなく、C++ や Java の劣化版のような印象を受けます。記法（マクロを大文字化しない、ルーチン名を大文字で始めるなど）だけの問題ではなく、データ構造の設計思想が「C で書く」という方針と矛盾しているように見えます。
もう少し具体的に言うと、そもそも C というのは現在 Web 系の世界などで流行のスクリプト言語類とは逆で、汎用言語でありながら低レベル（ハードウェアに近い）処理が簡単にできることに特色があります。つまり、組み込みを想定してプラットフォーム非依存のコードを書いたり、ハードウェアの特性を考慮して低レベルな最適化をやりたいというときに適しています。
そこでこの問題ですが、これを C でやるということは、処理速度や使用メモリ量の最適化が要求される状況、つまり迷路の大きさが途方もなく大きいような状況を想定すべきです。もっと言ってしまえばこの問題、たとえば画像処理などで似たような発想が要求されることがあります。このため、どうすれば時間のかかる処理を切りつめることができるかを考えてやらねばなりません。
このプログラムの場合、時間のかかる処理の代表格である malloc() が大量に使われています。これはいかにもまずいです。このような大量データを処理する場合の定石は、あらかじめ必要なだけメモリを確保しておいて、自分で割り当てることです。具体的には、必要と想定される量だけメモリを配列の形でどかっと確保しておいて、配列のインデックスをポインタ代わりに使います。そして、足りなくなったら倍々のような感じでメモリを realloc() してやればよいのです。
なお、そのような観点で言って、木の各節点の子の数は高々 4 （スタート地点が内点でないとすれば 3）であることを使っていることはよいと思います。ここで「子のリスト」とかを作ってしまっていたらこれはもうアホもいいところですから（容量の節約にすらなりません）。
そんな感じでしょうか。
とにかく、この手の問題は、アルゴリズムさえわかっていれば可読性もヘッタクレもないので、「短く書く」というような表層的なことよりも、何が求められているのかをよく考えて、柔軟に設計思想を考えることが大事だと思います。
2010/05/17 13:54
Oさんですね。専門的なコメントありがとうございます！cで書くと言いつつObjective-Cっぽい発想で書いていました。マクロの命名もその影響で、関数はImage Magickなどに似た命名規則になっている気がします。mallocを使いすぎると時間がかかるということは全然意識していませんでした。今度作るときはメモリ管理を自前で用意する発想を取り入れてみたいです。参考になるコメントありがとうございました！
なぜ両方使うという選択肢がない。真の技術者はウェブ標準だろうがFlashだろうがネイティブだろうが、その場その場でユーザーの体験を最善にし、クライアントの要求を最高に満たすベストの技術を使う。JavaScriptかFlashかなんて動きさえすればユーザーには関係ないんだから。実際、HTML5スゲＥＥＥＥＥ！！！ってページにFlashタグのブクマが間違ってつけられたりしてるよ？（笑） ウェブ標準の崇高さなんてパンピーにはわからんのです。
そもそも分からないんだけど、HTML5が「投資」するほどたいしたもの？ 誰もが基礎教養として身につけているはずの、これまでのHTML＋CSS＋JavaScriptの延長線上の技術でしょ。今まで普通にやってきたウェブ開発者ならすぐにキャッチアップできるはずだよ。
どうせHTML5の実装の普及には当分かかるし、その時点のブラウザ環境で使用可能なものをゆっくりまったりと導入していけばいいだけ。その意味ではいわゆる遅延評価学習で十分。あわてることはないです。どうせ皆使うことになるんだから。
一応言っておくと、いいものだと思いますよ、HTML5は。現段階で頑張って凝ったものを動かしておられるイノベーターの方々もたいしたものだと思います。敬意を。マリオやらグラディウスやらは著作権的にどーなのかと突っ込みたいが。
それはシナリオのひとつですよね。Googleの甲斐性次第では十分にあり得る。それと、ジョブズが翻意するというシナリオもありますよ。今までに散々あったことですが。どこかでそれをネタにしている記事があったと思いますが。
もしEdgeを見てそう思ったのなら、Flash CSを使って制作したことがありますか？ Edgeを実際に使ってみましたか？ と問いたい。
他にも、最低でも、
これらにきちんと答えられない人間にHTML5 vs Flashなど語る資格はないです。そもそも対立させる時点でわかってないなー ┐(´д｀)┌ って感じなのだけど。
あとFlashへの投資が無駄になると思ってるようですが、俺はFlashは投資判断「Buy」継続だと見てますよ。たとえこのままiOSで動かずともね。AIRもあるし、ブラウザのプラグインとしてのFlashだけ見ていると考えを誤るよ。ブラウザのほうにしても、GPUアクセラレーションつきの3Dが真っ先に使用可能になるのはFlash。プレイヤーの普及が速いから、WebGLと異なり、今後1～2年内に実案件で使用可能になるでしょう。そういった面ではなおカッティングエッジな技術だよ。
まあ、プラットフォームや言語の選択は投機だから、どの銘柄が買いか売りかで紛糾するのはわかる。ただ、それなら分散投資だとか、インデックス投資という考え方もあるのでね。HTML5に惚れ込んで一点買いなんて若いエンジニアがいたら、それはもう相当危なっかしいなと、視野も相当狭くなるだろうなと危惧するよ。
というか、JavaだろうがC++だろうがObjective-CだろうがLLだろうがアセンブリ言語だろうが関数型言語だろうが、一度全部触ってみなよ。いいから。HTML5で手一杯なんてのでは話にならんですよ。
http://www.lastday.jp/2010/11/22/objective-c
早速Objective-Cとやらを勉強しようと思ってググってみたら、Objective-CはC言語の拡張なので先にC言語を学ぶ必要があるという驚愕の事実が発覚！
この文書はC言語については解説されていないため、C言語にある程度慣れていることが前提となり ます。しかし、それほど熟達している必要はありません。Objective-Cによるオブジェクト指向プロ グラミングはANSI Cの手続き型プログラミングとはかなり違っているので、熟達したCプログラマで なくても、さほど不利にはなりません。
http://developer.apple.com/jp/devcenter/ios/library/japanese.html
Cの知識があるに越したことはないけども、どこまで必要かという話になるとごにょごにょ。
少なくとも、Objective-Cを公開している連中が、"Cの手続き型プログラミングとはかなり違う"と言っているのだから、C言語的なコードの流れには（あんまり）ならない（はず）。
それより、フレームワークの扱いに慣れることに重点を置いたほうがいいんじゃないかな。
苦Cで言うところ、文字列やら、ファイルの取り扱いあたりになってくるとかなり微妙で、出来る限り言語機能やフレームワークに任せたい。
ポインタはそりゃ、Python使いが見たら発狂するんじゃないかってぐらいポインタ演算子が出てくるけど、オブジェクトインスタンスは全部ポインタなんだから、いっそ気にしなくていいんじゃない？ それとも関数ポインタとか使いたい？ きっとデバッグが大変だよ。
YouTubeやVimeoで『Xcode tutorial』で検索すると大量のiPhoneプログラミングのチュートリアルが無料で視聴可能です！
公式の「iOS アプリケーションチュートリアル（日本語版）」を読んだ上で言っているのであれば、どこの誰が作ったかも分からない英語の動画が、アップル公式の日本語ドキュメントより優れている点を挙げた上で、その動画のURLを示して欲しい。
英語なんて分からないよ。
オススメってことは必読じゃないのかな？
3.初期投資
Intel Mac + iPhone or iPod Touch + 10,800円
ここから、開発者プログラムの参加費用$99（¥8000程度）を差っ引くと、一冊分しか残らないから、下の方で紹介されてる本が必読なんだろう。
初心者にわかりやすくObjective-Cの事が書かれています。必読です！
こっちが必読？
内容全く知らないで発言するけども、書評を見てみると、Snow Leopardに対応していない旨が書きこまれていて、多少不安。
流行りに乗ってMacbook Airを購入した人は、大抵Snow Leopardのはず。
記事には、"二ヶ月前"からとあるので、少なくとも記事を書いた人はMacbook Airではないのだろう。
自分のアプリの必要な部分だけを勉強すれば、それだけリリースも早くなりますしモチベーションも下がりません。全部網羅しようと思うと開発自体を頓挫しかねません。
遅延評価勉強法の考えで行くと、C言語を先に勉強する必要はなかったと思うけど、どっちなんだろう。
その辺も遅延で気付いたのかな。
英語力がなくてもアプリは作れますが、英語がわかると公式ドキュメントや先にあげたYouTubeのチュートリアル動画も理解できるので簡単な英語くらいはできる方が良いです。
日本語の公式ドキュメントがあるので、是非参照して頂きたいです。
http://developer.apple.com/jp/devcenter/ios/library/japanese.html
Apple Developer Documentation日本語版
http://developer.apple.com/jp/documentation/japanese.html
日本語ユーザが増えたら、Xcodeのクイックヘルプとかドキュメントとかも日本語化してくれないかなあ。
それとも、実はただの調査不足で既にあったりとか…
誇張や事実と異なる表現がございます。ネタとしてお読みください。
特に関数型言語は全く触ったことが無いため誤っている可能性があることをご了承下さい。
while(i＜10000)++i;
| COBOL | バブル時代に銀行のCMにも出演したことがあるが現在はほぼ引退している。 |
| BASIC | 一時期は誰もが知っている国民的アイドルだったが、現在はほぼ引退している。しかし昔からの根強いファンによって現在も一部で活躍中。 |
| FORTRAN | インテリ層に大人気のアイドルグループ。 |
| Brainfuck | アイドルの定義を逆手に取った誰も得をしない名ばかりアイドル。 |
| PERL | もともとは活字メディアでの活動を主軸にと結成されたが、現在はネットで活動することが多い。 |
| RUBY | PERLを真似た純国産のアイドルグループ。こちらも最近はネットでの活動が多い。 |
| C | 今も現役で活躍する言わずと知れた国民的アイドル。しかし最近はJAVAなど後進のアイドルたちに仕事を奪われつつある。 |
| C++ | Cのメンバーに加え、あらゆる属性の女の子を集めた超大型アイドルグループ。しかしあまりにマニアックなため、一部のファン以外はついて行けていない。 |
| JAVA | C++の失敗を反省し一部のマニアックな属性を削った正統派アイドルグループ、初心者はJAVAから入ることを進められる。 |
| C# | まっくろ社がJAVAのパクリユニットとして一度デビューさせたが太陽社に訴えられたため名称を変えた。しかし後進だけあり、女の子の質は高いと好評。 |
| GO | 新進気鋭のぐぐるからデビューした新人アイドル、デビュー時は大きな注目を集めたがその後は期待ほど売れていない。 |
| D | 他のアイドル達のいいとこ取りをした最強ユニットのはずが、未だメジャーになりきれないマイナーアイドル。 |
| Objective-C | Cに新たなメンバーを加えたユニット。しかしC++ほどメジャーになれずそのまま消えるかと思われたが、出演した林檎の映画が大ヒットし延命した。 |
| JAVA SCRIPT | 身近がモットーのネットアイドル。あなたも気付いていないだけで、いろいろなところでお世話になっています。 |
| PHP | ネットアイドルとしてデビュー、物珍しさも手伝って人気になったが、女の子が明らかに寄せ集めと批判も多い。 |
| LISP | 81が新人声優を売り込むために作ったスフィアのパクリユニット。おっぱいが大きい。 |
今日改行コードまわりではまりまくった。「\n」じゃなくて「\r」なのか。linuxでも「\n」でよかったのに。文字コード周りでハマったことはあったけど、改行コードでハマったのは初めて。しかも
fputs([@"\r" UTF8String], fp);
的なことをやると、改行されなくて困った。原因が分からず、結局
putc('\r', fp);
ですました。
メソッドの呼び出しあたりもわけがわからん。例えば「詳解 objective-c 2.0」に次のようなコードがある。
-(id)initWithMin:(int)a max:(int)b step:(int)s;
aとbとsがメソッドの引数なんだが、maxとかstepとか必要性がわからん。指定して呼び出すときもa、b、sでいいじゃないか。しかも第一引数にはmax、stepにあたるものがないから、さらにわからなくなる。
慣れてないせいもあるんだろうけど、プログラミングしにくくてしかたないんだが。
X-Code勉強するのがめんどくさかったので、はじめコマンドラインでやろうとしたせいでかなりくだらないところでハマった。このあたりのことを書いたサイトがないので、増田に書いておく。
つけてください。つけないとwarningがいっぱい出るよ。
つけてください。つけなくてもコンパイルできるけど、実行時にメモリリークが起きたと警告が出る。このオプションをつけるとかベージコレクションが有効になるよ。
書いてください。書かないと
warning: no ‘ほげほげ’ method found
warning: (Messages without a matching method signature
みたいのがいっぱいでるよ。よもや文字列や配列を使うだけで、インポートが必要になるとは思わなかったよ。
しかもNSArrayクラスは要素の追加もできないよ。あとから要素を追加するなら、NSMutableArrayね。
うちの会社、今、それに近い流れだわ～。
まぁーSE兼プログラマで一人なんで被害は少ない(?)んだけど。
俺、Objective-Cとかしたことないから。
っていうか、Cすらここ10年はいじっていないから。
自分はMacメインなプログラマじゃないので、ズレたこと言うかも知れませんが……。
参考書も参考サイトも無数にある。その中にはプログラミング未経験者を対象にしたものも多い。しかもJavaなら将来WindowsでもLinuxでも通じるし、Webアプリなどにも利用出来る。C++様信者の私としては悲しいけど、時代はJavaだ。
ネイティブアプリを真面目に作ろうと思ったら、Objective-Cが基本っぽい（C++ではCocoa使えず、Carbonになってしまう）。
ただ、Objective-Cの参考書・サイトは、C/C++やJavaなんかと比べて絶望的に少ない上、ざっと見た感じCocoaな部分やXCodeの機能とごっちゃに記述されているものが多く、初心者にはとっつきにくい（理解しづらく、書かれている通りに打って動かす以上のことを行いにくい）点が多々あると思うので、まずはCでプログラミング（コンソールアプリ製作）を知っておくのが良いかも知れないです。
何にせよ、プログラミング言語というものは何か一つやっておくのが重要なので、（もの凄ーく悔しいですが）Javaが無難なんじゃないかなーと思います。
そうですね。逆でした。
考えるべき（「守るべき」かな）事が少ない環境でも出来ないんだから、考えるべき事が多い環境でなんか尚更無理。
しかも、ちょっと話してみたら、Objective-C/C++での参照カウンタによるメモリ管理が分かってない。