Swift part11 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
すまん語弊があるな、ダイナミックコールしないケースがある、が正しかった まあ何と言われようと、OSX、iOSをここまで発展させてきたObjective-Cの実績は事実として存在している apple専用言語だから実績と言われてもピンと来ない iOSが毎年更新してるのにアホみたいに安定してる事実が もう「あたりまえ」だと思われてるんだなぁ… C/C++製の自分の足下の更新ペースと安定性を忘れきってるのが笑える。 Cocoa, UIKitで他の言語が使えないからなぁ ObjCだったから発展したんじゃなく、発展に合わせてObjCが普及したのが事実よな Swiftでないと使えないという環境がないから普及しねぇ Carthageも流行らなかったから普及に貢献してないし >>120 Objective-Cだから発展したというよりは、Objective-Cのままでも何ら問題がないということだろう Carbon(C++)からCocoa(ObjC)に切り替えて選択肢を無くした状態でObjCをゴリ押ししたからな Swiftのゴリ押し、足りてないよー >>122 あの時はそもそもOSが根本的に変わったけどな まあObjective-CはJobsが原点回帰(NeXT系譜)した感じだな >>122 CarbonがいつC++だったのよ。Cだろ >>123 のいう根本から変わる過渡期にどうするかで出てきたCarbonなんて最初からいつか無くなる運命だし、Carbonよりも先にObjective-Cあったので切り替えでもなんでもないだろ いつまでもOSネイティブなObjective-Cにしなかったアホが悪いでしかないのに、ゴリ押しとか基礎も結論も妄想がひどすぎ Swiftやってる連中はにわかが多いからしゃーない 旧MacOSはそういやPascal推しだったの思い出した Pascal, C/C++を拒否してObjCに強制誘導してるじゃないか、、、 同じようにSwiftも頼むよー C/C++が拒否されてるなんて全く感じたこと無いけど C/C++でバリバリ書かれてるコードにちょっとCocoa APIをObj-Cで呼び出せばプログラムが完成するって感じだと思うけど ObjCに強制誘導って思うのは、単にMac OS XのAPIを学びたくないからじゃないの? 強制誘導ってアホか? Objective-CのベースだってMac OS X/OS X/macOSのバージョンアップによってC++に書き換えられてるし、CoreはCのままだし、OS X/CocoaはほぼNEXT STEPのまんまと言っていいくらい元々Objective-Cだし、IO KitはC++で書けだし >>128 推しというか、Macの開発(ほんとの生み出す開発)はPascal/Assembleで作っていたんだなあというのは、どこぞの博物館で公開されたQuickDraw/MacPaintのソースでわかる 推すも何もそうだったらそうなるだろ、ドキュメントとか。だが、サード開発ではCが大多数(&CでPascal形式API呼ぶのにほぼツーカーで何も問題ない)で、Appleもそれにならうでしかないな Google Search Google Trends Twitter GitHub Reddit などなどを"X programming"っていうテンプレートで検索し、hits countsをrankingしたって事らしい。 >>130 ObjCをちょっと書かないとmacOS, iOSアプリが作れないように Swiftをちょっと書かないとモノが作れないくらいのゴリ押しして欲しいなぁと Appleは作りっぱなしで押さないし、信者はジョブズの聖遺物(ObjC)を崇めるし Appleがゴリ押しした製品に寄生して銭稼ぎしようとbetaの頃に始めたのに悲しいよ 世界初のWebブラウザはObjective-Cによって産み出された まあどーでもいいけど、いまやWeb全盛の時代にそういう言語で最新のアプリが作れる環境が与えられてんだから少しくらい感慨というものを感じてもいいんじゃないの 元々アホかなとは思ったが, >>135 ぶりからアホってもんじゃねええ。Swift好きにも迷惑だと思うぞ >>130 C++を拒否というならSwiftによって/Swiftがだろうな、現在はw macOS上のSwiftでは、まあ、Objevtive-C++でラッパー書いてそれをSwiftでだが、Linuxでぼちぼちっとじわっと使われているので、はよSwiftでC++のブリッジを(まあ、Cのインターフェースでラッパー作ればいいんだろうけど) C++ブリッジの予定ないのかなあ Uiview.アニメーション関数を使いたいのですが、uiviewanimationoptionsの選択肢が でてきれくれません。Youtubeを参考にしながら、optionsの部分をcurveLiniearに したいのですが・・・cを入力しても候補が一切表示されず途方に暮れています。 どういった原因が考えられますか?助けてください。ゲーム作りたいです。 >>139 macOS/Objevtive-C++ありきのじゃね? rustのメモリ管理の仕組みが採用されたらどんだけ幸せになれんのかな。 そもそもrustごと採用してくれれば良いのに いやそうでもないか… 言語仕様に振り回されてはいるが大概自分に原因を帰着してる まだ信仰心旺盛なようだ でも静的にメモリ管理を解決するって どんだけ良いものか気になるんだよね。 どうせswift5辺りで採用されんだから、先にrustに触って先行学習してても良いかもね。 多分swiftに採用されたら下位互換性また壊れるぜ Rustの元になってるC++ std::unique_ptrをどうぞ ObjC++でも使えるゾ >>141 下手な風評はSwift好きに迷惑だからやめろやw >>139 時々見る、この「つ」ってどういう意味? >>148 c++にはなんでもあるんだね。 でも言語仕様で縛らなくても静的にメモリ管理って可能なの?c++のプリプロセッサがすごいってこと? >>151 俺には「つ」が手に見えない。手のひら?手の甲? >>152 オブジェクトへの参照が1個、複数の別で、 unique_ptr, shared_ptrを使い分ける。 参照するだけで、所有しないweak_ptrってのもある。 要するにリファレンス・カウント式のメモリ管理なのだ。 Objective-Cの設計をC++が取り入れたのかな? ちなみに、俺はC++を最近全然使ってない。C++詳しい人、 unique_ptr, shared_ptr, weak_ptr の解説、よろしこ! >>154 ただのリファレンスカウント方式ならrustとは違うで。 逆だよ、C++のshared_ptrをObjCのARCに文法糖衣で取り込んだんだよ >>152 unique_ptrは元々C++ boostのライブラリとして提供してたから出来るでしょ ObjCもSwiftもそういう機能はライブラリじゃなく文法で取り込みたがるから言語更新待ちになるだけで リファレンスカウントは全然静的に解決しているメモリ管理機構じゃない。 rustのやり方はコンパイル時に指摘してくれるけど、リファレンスカウントはけっきょく動的に解決するわけだし。 それならとっくにswiftで実現してるし。ARCだろ。 >>157 Boost Software License - Version 1.0 - August 17th, 2003 って事は、Boostの方が歴史が古そうですなぁ。ObjCよりも。 俺、誤解してたわぁ。 Apple Inc. deploys ARC in their operating systems, such as macOS (OS X) and iOS. Limited support (ARCLite)[5] has been available since Mac OS X Snow Leopard and iOS 4, with complete support following in Mac OS X Lion and iOS 5.[6] Garbage collection was declared deprecated in OS X Mountain Lion, in favor of ARC, and removed from the Objective-C runtime library in macOS Sierra.[7][8] ref. en.Wikipedia://ARC ARC Liteの出現は、2009, Snow Leopardからみたい。 rustのメモリ管理の仕組みを見てきたけどプリプロセッサで何とかなるというものじゃなかったから、 c++ならあると言うものじゃなかった。 言語仕様から改変か必要なものだったよ。 簡単に言えば、メモリの参照は一箇所に制限されて、そこからしかアクセスできないようにする。 たから、もしswiftでrustのメモリ管理機構が導入されたら、 100%既存のコードでは動かないし単純に変換もできない。 ロジックの見直しが必要だからね。 例えば配列にループアクセス中は 配列に対する変更操作はすべてコンパイルエラーになる。とか。 いやownership manifesto読めよお前ら 全部書いてあんのに >>148 https://github.com/sandym/swiftpp これじゃねえの?XcodeありきObjective-Cありきだろ? これじゃねえ、どれやねん? >>161 「メモリの参照は一箇所」 まあ、そうかもしれんけど、俺の理解では参照カウントを1以上に上げない 様なメモリ管理ポリシーを実践する事で、メモリリークは防げると思う。 それから、Instrumentsとdebuggerを活用するのが吉。 最近気がついたのが、command+IでInstruments leaksを起動して捕捉出来なかったメモリリークが、不思議な事に、break pointで一旦止めてdebuggerからInstruments leaksを起動すると捕捉できるんだよねぇ。 =ア 【はい】 こういうのも👉に見えてなかったとか… >>153 手の平。 https://nanapi.com/ja/25657 https://m.chiebukuro.yahoo.co.jp/detail/q1410591729?__ysp=MmNoIOOBpA%3D%3D [つ]は手を表現しています。 例えば、[( ・∀・)つ旦]というAAでしたら 旦はお茶のAAですので、 お茶をハイ、と差し出している様子を表しています。 2ちゃんねるでは省略形をよく用いますので 顔文字が省略されて[つ]のみで使用されます。 >>165 まじっす! >>170 そんな、補足説明が必要なAAなんて、不要だわぁ。 >>135 つまりは皆が出来ないうちに自分だけはSwiftを沢山書けるようになっておけば、Swiftがゴリ押しされたときに先行者利益を得られると思ったけどそうはならなかったから悲しいってことだろ? 別にAppleが推してないなんてことないと思うし、Obj-Cを崇めてる奴なんていないと思うし、Swiftはまだまだバージョンごとに変更がある割には十分普及してると思うけどな 大体Swiftをちょっと書かないと作れないぐらいのレベルだったら大してSwiftの知識もいらないと思うし銭稼ぎできるようなもんでもないと思うんだけどな はじめにObj-C使わなきゃいけなくなったときに本1,2冊ぐらいしか買ってないし、Swiftに関してはお金まったく書けてないし、金稼ぎできる要素がある気がしない >>138 C++をブリッジするとなるとC++の複雑な機能全てをブリッジ出来なきゃ有用性が落ちそう 限定された機能で書かれたC++コードだけブリッジしてくれるとかだと結局C++側がそれ以外の機能使ってたらラッパー書かなきゃいけなくなるし、落とし所が難しそう Swiftの完成度が最初から高ければ状況は違ったかもな あとむだにWithout Cに走ったのは筋が悪かったと思うわ C++ブリッジってそれもうwith C++だからな テンプレート除けばそれなりに出来るだろうけど テンプレート除いたC++に対応したところでだから何なのって話になるし Without Cをぶち上げたんだからもうCに関わるなよ 韓国人かよ... Cライクforもインクリメント、デクリメントもなくす無駄な徹底ぶりだからな なんかswiftどんどん構文追加して複雑になってないか? phpみたい >>176 マルチプラットフォーム化に加えて 膨大なossがcやc++で書かれてるんだから無視は不可能だ。 むしろ、Objective-Cの「インスタンスは母体クラスに[おまえのインスタンスを作れ]命令で作成します」とか 「クラス間の通信はクラス[命令:引数]で明示的に他のクラスに実行させてるとわかります」が好きだったので そのあたりswiftが「退化」しちゃったのが嫌。 言語仕様とクラス仕様が分離しててクラスライブラリだけ進歩してくとか ソース内で自他の表記がしっかり別れてて「ここであいつがこれやって次…」 と読めるのが気に入ってたのに 他のグチャグチャモダン言語と同じ言語仕様変更地獄と ソースになんだかわからない誰かが作った記号が普通に混じりますって これ、ずっとプログラミング文化の発展阻害してた奴だ…と >>183 >明示的に他のクラスに実行させてるとわかります Swiftでは分からんの? >>183 >ソース内で自他の表記がしっかり別れてて これ何のことを言ってんの? 自他の区別がつかない言語なんてあんの? そんな精神病みたいなプログラムあっても実行できなくね 多分全部staticで書いてんだろ おそらくインスタンスとクラス、動的メッセージと静的メソッドの違いがわかってない $ ↑こいつ 今までの理念をぶちこわすような暴挙 itでもなんでもよかったのになんでこれにした 一方俺は、ObjCの言語仕様にクラス変数が追加されて、既存フレームワークのクラスメソッドがクラス変数に変わって発狂していた >>188 $0, $1, etc.として複数引数の場合でも引数記述を省略させるためでしょ シェルスクリプトを書いたことないとなんぞこれってなるが、it0, it1よりはスマートだと思うが >>181 なので普通に考えるとObjective-C 3.0として改良発展させるのがよかったと思うんだよね... >>189 いちいち引数に名前つけさせて、 省略できるのはひとつまでって感じで今まできてたじゃん! ここにきてこれ itですら多少は意味があるが、$ってなに? なんで急にドル記号が出てくんの itの方がマシというのは別に否定しないけど 「今までの理念」というのはSwiftには無くね 俺はitより$nの方がマシだと思うけどね 「名前を省略する」ためのものに「名前をつけた気になる」ために$nをやめてitにするってかなり本末転倒じゃない どうせ具体的な名前が無いなら、極めて曖昧なitなんて単語じゃなく、どこまでも記号的な$nでいい 敢えて単語にするならanonymousArgumentとかclosureArgumentとかにして、クロージャの名前がない引数であるという意味を表さないと itなんて、$nと同じぐらい何も意味を表さないのに、無駄に単語の体をしてるだけタチ悪いと思うわ 逆にwillSetの引数名省略時のnewValueみたいに、最低限あらかじめ意味が限定されてるところでは、$nでもitでもなくちゃんと最低限の意味を表す省略形になってる どーでもいいけどいい加減syntaxのセンスがクソ過ぎやしないか? 本音をいうと省略させたくない 書き方増やしてどうする 俺も書き方のバリエーションが増えるのは反対だな。誰が書いても同じ文法で、誰が書いたコードでも誰でもさっと読めるのが理想だったな。 swiftでrxSwiftさわったらすごくRxがわかりやすくなったのは良い思い出。 objcだとわけわかめだった。 構文って結構学習コストに関わるんだなって理解した瞬間でした。 >>198 Haskellが普及しないのは、その理想を追い求めすぎてるからだけどね >>200 書き方のバリエーションの少なさでいったらgoがいい感じではないかと。 中括弧の位置すら強制するからね。 objCは文法に多様性がありすぎて俺には理解できなかった Blocks構文は「それそういうクラスじゃいかんの?Cに付け足す理由は…?」といまだに >>199 ObjCにはCocoa Bindingがある。 >>204 双方向バインディングとRxを一緒にするない。 >>202 メッセージ式は面食らったが、CとJavaをやってたからあんまり覚えることなかったけどなObjC >>183 > クラス[命令:引数] スレチ引っ張って悪いけど、ObjCにこういう記法あったっけ? [クラス 命令:引数] とかだと思ってたのだが… レベルに合わせた書き方すりゃいいじゃんよ generics,typealias,operator overload この辺は無理して使うことない boilerplate無くしてえなーもっとコードを直感的に書きてえなー、そもそも今までの書き方飽きたから違った書き方してえなー という欲求が生まれた時に導入すれば良い。そうすりゃObjCとも大して見た目変わらんしな >>209 なるほどぉ。 ところで、Swift -> ObjCへ移行する時に、RxSwift相当のFramework って、ReactiveCocoaって事になるのかなぁ? Swift一発屋になってんじゃねえか。 ピコ太郎だってもっとまともにやってるぞ。 もっと頑張れよApple。熱くなれよ! >>210 言っておくけど、Rxとobjcは全く相性が悪い。 なんでかというとあのobjcのメッセージ式 Rxってメソッドチェーンが無いとかなり実装しづらいのに objcでは書けないのだよ。 []のネスト地獄を味わう事になる >>212 なるほどぉ Cocoa BindingとかCore Dataを使えって事なのね。 ところで、ObjC Wizardの方々は、Core Data使うんでしょうかねぇ? Lispのtypoかよw そういうワードがあるのかと真面目に受け取ってた あ、自分はvim派なんでelisp含め使ったことないわ elisp wizardは変態だと尊敬してる ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる