Swift part11 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>148
c++にはなんでもあるんだね。
でも言語仕様で縛らなくても静的にメモリ管理って可能なの？c++のプリプロセッサがすごいってこと？ >>151
俺には「つ」が手に見えない。手のひら？手の甲？ >>152
オブジェクトへの参照が１個、複数の別で、
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
「メモリの参照は一箇所」
まあ、そうかもしれんけど、俺の理解では参照カウントを１以上に上げない
様なメモリ管理ポリシーを実践する事で、メモリリークは防げると思う。
それから、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ですので、
お茶をハイ、と差し出している様子を表しています。
２ちゃんねるでは省略形をよく用いますので
顔文字が省略されて[つ]のみで使用されます。
>>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は変態だと尊敬してる >>216
すまんｗ
まあメッセージ式のネスト地獄もLisp様から見ればかわいいもんですｗ >>212
メソッド呼び出しに、ドット構文が使えればObjCも描きやすくなるよねぇ。
Objective-C 3.0に期待だね。
id a = [[NSObject alloc] init];
->id a = NSObject.alloc().init(); // こんな感じ！ 既にクラスプロパティとオブジェクトプロパティで実現できてるね！ObjCはすごいね！
クラスプロパティの存在を知らないんだろうなぁ、ObjCについてもうちょっと勉強してこい >>219
いや、引数あったら出来ないだろ
ところでドット構文マンセーな人ってiOSやる前は何の言語がメインの人？ >>218
obj-cの魅力ってあくまでcの拡張でありobj-cの世界は[]の中だけってスタンスであってほしいから
ドット構文?はあんまり増やしてほしくない
個人的にはElixrのパイプ演算子(|>)をobj-cに採用して欲しい。
(元ネタはElixirじゃないかもしれないけど。)
[NSObject alloc] |> [@ init]
みたいな感じで使う。Elixirの場合だと返却値を次のメソッドの第一引数に渡すって意味だけどobj-cでは@を置き換えるみたいな感じで >>223
自己レス
プロパティへのアクセスだけだた 最近ObjC ageが激しいがnukeとかvaporとか読んで腰が引けちゃった連中が多いのかな？
ああこれc++の再発明かなと思うくらい難解なコードになってきたからな
POPがあるからまだ扱いやすいが SwiftはC++っぽくて地雷にしか見えない。
闇の軍団が好きそうな言語。 Objective-Cがまぁ長年主に言語仕様を弄るんじゃなくて
外部のクラスライブラリ更新で"外"に括り出してきたタイプの問題を
2010年代になっていまさら言語仕様直接変更の繰り返しで泥沼って
そりゃ車輪の再発明ってレベルじゃねーぞっつか…
あきらかに(筋の悪い)車輪を知らないところからの使者が
「おまえら未開の蛮族にまったく新しい言語を作ってやるぜ」って
泥の中でのたうってるのを眺めてるこの感じ。 ObjCが長年プロパティ、GC/ARC, ブロック文, nillable, ジェネリクスと言語仕様追加を繰り返して泥沼を作ってる中で
Swiftという新しい泥沼を作ってくれたから皆で泥遊びをしている中、泥遊びって子供かよ・・・と高二病な感じ
一緒に泥遊びしようぜ、やってみたら案外楽しいよ >>229
Objective-Cでもジェネリクス可能なのか？
どのレベルまでできる？
1. 型汎用な関数
2. 型汎用なクラス
3. 型汎用なプロトコル
4. 型汎用なプロトコル・エクステンション LattnerがGoogle Brainに就職
やっぱり人工知能やりたいんだな Google BrainといったらTensorFlow開発してるところだから、これはいよいよTensorFlowがオフィシャルにSwift対応するかもしれん 良かったな、お前らの教祖様の就職先見つかって。
Apple「Swift」の生みの親がテスラの自動運転開発をやめてGoogleの人工知能開発チーム入り
http://gigazine.net/news/20170815-google-hire-apple-engineer/ あのおっちゃん短期で技術リーダー採用してくれる所を探してたよな
来年には再転職しそう どうせまたリスケするんでしょ、、、とか思ってるけど
それとは別にラットナー のgist記事がRustのオーナーシップモデルをディスっててワロタ
Rustライクなメモリ管理をSwift4で投入するって言って結局Swift5に持ち越したのは忘れんぞ
ファーストクラスの非同期とファーストクラスのオーナーシップモデルを並走させるのはキッツイだろうがどうするんだろうね
理論的には出来なかないだろうが時間も技術力も足りずどっちかSwift6に持ち越しすることになるんじゃねーのか オーナーシップは初めから「4には入れられないけど」「将来的に〜」ってエクスキューズしてた
オーナーシップを4のゴールに含めるなんて話は一度も出てないはずだが 思うんだけどrustのオーナーシップモデルって後付で入れられるものなの？
rustを見る限り無理そうだし、
スマホの性能もこれから上がっていく一方なのに学習コストが上がる
メモリオーナシップモデルって導入する意味あるのん？ SwiftからObjective-CのArreyを取得しようとすると、x0756846 のような、メモリーアドレス？しかとれないのですが、何か特別な変換とか必要ですか？ >>245
CManeger.mmの関係しそうなところ
@property (nonatomic, readwrite) NSArray *hoge;
データ取得関数の最後に
self.hoge = hoge.array;
dispatch_async(dispatch_get_main_queue(), ^{
[self.delegate CManager:self didCompleteWithCandidates:self.hoge];
});
とあり、ブレークポイントはって確認すると、取得したデータがhogeにある。
HOGE-Bridging-Header.h
#import "CManager.h"
Hoge.swift
let objcCMng = CManager()
let ret = objvCMng.hoge
print(ret)
出力データは
Optinal([<CCandidate: 0x170226b80> , <CCandidate: 0x170226ce0>)]
という感じになります。
ただし、デバックエリアで確認するとself>objcCMng>_hoge>_orderedSet>_array>[x]>_hogeに取得データがあることは確認できます。
型変換か何か必要なのでしょうか？ >>246
let ret = objvCMng.hogeを
let ret:Array! = objvCMng.hoge
にしてみたら？ >>247
ありがとうございます。
試しましたが、出力結果はほとんど同じでした。
[<CCandidate: 0x170226b80> , <CCandidate: 0x170226ce0>] 何がみたいのかよくわからんのだが、、
dumpだとどうなる？ 多分descriptionをオーバーライドしてなくてprintで<CCandidate: 0x170226b80>みたいに出力されるのと、型変換してなくて[AnyObject]?型のままになってるのの複合で混乱してるんだろう
前者はCCandidateのdescriptionを自分の望みどおりの出力をするようにオーバーライドすればいい
後者はSwift側で as? [CCandidate] するか、Obj-C側で @property (nonnull, nonatomic, copy) NSArray<__kindof CCandidate *> *hoge; とかすればいい >>249
some: 2 elements
- <CCandidate: 0x170226b80> #0
super: NSObject
- <CCandidate: 0x170226ce0> #1
super: NSObject
となります。
まだはまってます… ■ このスレッドは過去ログ倉庫に格納されています
