Swift part11 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
どうせまたリスケするんでしょ、、、とか思ってるけど
それとは別にラットナー の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
となります。
まだはまってます… 何したいのかいまいちわからんな
>>250のいう通りにすればいいだけだろとしか思えない >>250
ありがとうございます。
書き込み頂いた情報を元に、objc-cの言語仕様を調べながら触ったんですが解決せず、AnyObjectに問題を絞りこんで見ました。
結果、出力部分のコードを書き替え、データの取得が出来ました。
for i in 0..<objvCMng.candidates.count{
let ret = objvCMng.candidates[i] as AnyObject
print(ret.candidate)
}
皆様、ありがとうございました。 >>253
candidatesとhoge置き換えミスってます… let blue = #colorLiteral(red: 0, green: 0.4577052593, blue: 1, alpha: 1)
let white = #colorLiteral(red: 0.7803494334, green: 0.7761332393, blue: 0.7967314124, alpha: 1)
let orange = #colorLiteral(red: 1, green: 0.5803921569, blue: 0, alpha: 1)
let red = #colorLiteral(red: 1, green: 0.2352941176, blue: 0.1882352941, alpha: 1) 長ったらしい型名ばっかのコードは思考が阻害される
型チェックはしてるんだからべつにデメリットもない ビルドに時間がかかるようになるだろ。型推論なんて使わないほうがいい Swiftの型推論は単純だからObjCの型チェックとビルド時間は変わらないけどな
Rustくらいに賢い型推論して欲しいよ その解説だと型推論じゃなく数値型がstructであることが本質の問題だよね？
let a: Double = -(1 + 2) + -(3 + 4) + -(5)
と
double a = -(1 + 2) + -(3 + 4) + -(5);
で違いが出るならそれはコンパイラ組み込み型を常用せずstruct型扱うからでしょ
プリミティブ型削って構造体型を多用するSwiftはイマドキだよな
NSIntegerみたいに32bitなのか64bitなのか分からんことになるよりは良きも悪きもあるわな 推論に任せないで型を記述した方がコードの見通しが良い気がする 型を決定するために5cm以上目線の移動がある場合は型を記述したほうがいい俺ルール ジェネリクスみたいに長い同じ型を何度も書く羽目になるやつは
混ぜた方が見やすい Swift 3移行まだしてない人いる？
うちの会社は再テスト面倒で未だに2.4使ってるんだが。
Swift 2.4 -> Swift 4で済ませようかなって思ってる。 そもそもSwiftに移行してない(する必要がない) 自分とこは業務でSwift使うの金かかりすぎると2.2の後は3にせずObjCに移行した
メンテ工数かかるし素直に実装し直しを検討した方が良いんではないかね
1.1から2.2まで商用コードをメンテした過去の自分らを褒めたい >>266
Swift使ったことないなら参考にならないから黙ってるといいよ:D 移行してない＝使った事が無いというのは発想が貧弱ではなかろうか func sum(i:Int, i2;Int, i3:Int) -> Int{
return i + i2 + i3
-> Intが後ろの方にあるの､変な感じがするんですよ
func Int sum(i:Int, i2;Int, i3:Int)
こうしなかったのは､どうしてですか？ c++でも型推論が簡潔にかけるという理由で戻り値の後置構文が追加された。
その経緯をみて決めたんじゃないかな。 >>272
アレってtemplateの引数依存の戻り値を返したいからじゃなかったの？
コンパイラに型導出させてｳﾏｰ、っていう
template<typename T, typename U>
auto operator+(const T& t, const U& u) -> decltype(t +u) { return t + u; } >>270
C言語っぽくないことにとことんこだわったから >>270
セミコロンじゃなくてコロンだよ
引数の型の指定は xcodeが使いにくいんですがjetbrains製のideでiosアプリ開発ってできるんでしょうか 何が使いにくいのか？
慣れの問題もあるの思うが
とりあえずAppCode触ってみたら？ realmはcasecade使えるようになりましたか？ この言語仕様改定多すぎだろ。
C++が三年周期でやってることをこいつら一年単位でやってねえか？ xcode9で新規に画像がimageViewに表示されないんだが
xcode8で作成したものは9でも表示される。
iMacもMacBook Proも同じ現象なんだが俺だけだろうか どうせ画像をターゲットに入れてないとかしょうもないオチだろ 284ですが解決したので一応報告。
Xcode 9のバグでした。
画像をドラッグアンドドロップではシュミレーターで画像ファイルが
参照出来ない。
メニューから画像追加で表示されるようになりました。 >>282
Javaは今後6ヶ月ごとにバージョンアップらしいで また来年おなじことの繰り返しやで
再来年も、その翌年もずっとやで 今回Swift対応なんて無いようなもんだろ
フレームワークやX対応のほうが大変 Swift4対応のXcodeにアップグレード完了した。。 >>292
バージョンによっては速いぞ。
初期は遅かったけど。 先月Swift 3対応したばかりなのにまたSwift 4対応しなきゃならない。
Swift 2から一気にSwift 4対応したほうが良かったかな、失敗した。 >>294
昨日の会議でSwift3.1対応が残課題で有ったんだけれど、もう4になったとは言わなかった。 Objective-Cで書いときゃメンテフリーだったのに iOS 11で脱落したアプリはSDKの変更についていけなかったか費用対効果で更新をやめただけ。言語のメンテナンス性とは別の話 実質同義なんだよなぁ
せめて費用対効果がObjC AppメンテよりSwift Appメンテの方が効率悪いと言えば良いのに
ObjCならメンテフリーとかアホなこと言うから突っ込まれる
さておき、このスレでもSwift2の頃にSwift採用したPMは死ねとPG視点で大合唱だったのに
まだSwiftを商用採用する企業いるのが悲しいのう、その頃に作ったものをメンテしてるのかもしらんが辛いな >実質
>App
言語スレで言語の話をしてるのに勝手に条件を付加するなよ iOS11でObjC Appがメンテできなくてアプリが減ったと言う話をしてたのに何を言ってるんだ・・・
「Objective-Cで書いときゃメンテフリー」とは一体何を指しているのか
あと、ObjCの話をしたいならObjCスレかせめてSwiftアンチスレに行けよ
別にApple信者じゃないからSwiftマンセーしてるわけじゃないのにObjCを笑われたからってSwiftスレで絡むなw ObjC Appがメンテできなくて でなくて、メンテされてないアプリが消えただけじゃないの
ObjCだかrメンテできなくなったって、なに？ ああ、Swiftだったら簡単(？)なのにObjCだからメンテされなくなったとでも言ってるのか？？まさかだが、そう思ってるならそれはナイな
お前みたいに変なこと言い出すヤツいるから聞きたくもないObjCの話が長くなるだろうにw 開発環境の話
・Xcodeアプデ→言語VerUp→Swiftコード要メンテ
・ObjCならメンテ不要だった
ユーザー環境/ストアの話
・iOSのVerUpでObjCもメンテが必要になる
・Swiftの方が効率悪いと言えば良い
↑
前提がズレてる
・ObjCだからメンテできなくなったって
・Swiftだったら簡単とでも
↑
対偶的な意味でズレてる swudt2あたりで知識が泊まってるんだけど今のswiftはどれくらい良くなった？
俺の中でoptional型の概念とか関数型の世界を見せてくれたswiftには感謝してる。
今はtypeScriptメインだけどね swiftは良いものだがRXとかReduxはライブラリ必要で恐ろしく書きかたが変わり危険なので個人的に好きじゃない
iOSはそもそもMVCなのでMVVMいけ swiftのビルドの重さで新型Macが売れてます
ReduxとかRXのおかげでiPhoneのバッテリがガンガン減ります
結局ObCのほうが良かった、とかwww 型推論とかでビルド遅くなるなら要らないけどな
Optional型も適切にnilチェックしてれば要らない
Macとか本売りたいだけなのかな >ReduxとかRX
RXは書式が気持ち悪くて論外だが、Redux使うくらいならビジネスアプリはシンプルでライブラリレスなMVVMでしょ絶対に開発早いし
Appleはrxcocoa禁止したほうがいい xcode XくらいでAppleがMVVM的なフレームワーク出してくるかな
RXは早く死に絶えて ライブラリレスなんていう移植無視な開発なんてやらぬ >>308
バッテリの減りは初耳
裏で動く処理が多いから？ Swift 4になってからコンパイルめっちゃ遅くね？
Xcodeが固まりそうなほどなんだけど。 なんでそんなに時間がかかるのかね
構文解析がめんどい→人間にも解析がめんどい
じゃないのかと... Swiftの読みづらさは異常
無駄なwithout Cの追及により構文解析効率が悪化してんだろ swift+reactive なんて読めたもんじゃない
KVO地獄 varとか書くんだったらもはやvarも無くしちまえよまったく... 型推論とかいうおバカプログラマ向け仕様をやめればvarなどという間抜けなキーワードはいらないわけで いまだにJEPどまりで予定すら立ってないというのが 99% varでいいよ、面倒くさいから
変わらないobjective-cの安定感がたまらん
超開発早いし 新しいこと覚えるくらいならビジネスロジックを勉強するよ
言語だのリアクティブだの状態管理だの
フルスクリーンアプリじゃユーザーに全くメリットないし
業界に踊らされているだけ しっかりobject志向で作れば読みやすいしnullはチェックすればいいだけ
swiftでif letやguard書くようにobjective-cで書けばいいじゃん
ビルド速いしobjective-cで何の不満もない
swiftでreactiveで状態管理でとか、Appleがやってない事を無理矢理・・開発難航させるだけ そのチェックが大変すぎるから問題になってるんだろうがああああ
全変数だぞ全変数
Javaのオブジェクト変数は全部NULLになりうるんだ Javaだとこんなんでもアウトだしな
return a.getName().length(); ObjCもプロパティアクセスはドット表記がモダンでnilアクセスで落ちるだろ
こんなんでアウトだ
return a.name.length;
まぁSwiftでもObjCの関数の渡ってきた変数は信用できずちょいちょい落ちるんだがな(ワロエン swiftのビルド時間がobjcの半分でもなったら使おうかな
型推論なんか時間の無駄 >>329
スレッド間競合でいつnil化されるか分かんね、ってケースか？
だったらスコープ内でローカルの強参照に放り込んでからnil判定挟めば自分のスレッドで当該スコープ内はしなないんじゃね >>336
それにはまったく同意だがスレチじゃね？ ■ このスレッドは過去ログ倉庫に格納されています
