プログラミング言語Swift Part4 [無断転載禁止]©2ch.net
え？標準のオプティマイズ無しでパフォーマンス語って何の意味があるの？ って、>>53の最もいいねwって付いているのに及び付けてるのに言いに行けば？
何言ってんの？頭大丈夫？と思われるだけだと思うがw ド素人かな
-Ononeはデバッグ用であって速さなんか誰も求めてないぞ？
遅くなってもいいから色んなデバッグ用に有用な情報を埋め込むモードだぞ？
頭大丈夫？ >>59
-O 自体はオプションであってなければコンパイルできないわけじゃないぞ？玄人さん
ちなみにちゃんとしたデバッグオプションは別にあるけどな
どうも、オプティマイズの意味がわかってなさそうにしか見えないな。デバッグ用って言い切ってしまうあたり、すげえな自称ど素人じゃない人はw
(ちなみに一般的にオプティマイズするとほげほげな場合もまあ稀にあるとかないとかw)
てか、なにをオプティマイズありきに必死なの？オ
プティマイズ有無でこんな差があるのは珍しすぎる、いったいなんなんだ？という技術的w興味は普通わくだろうと思うんだがな、自称ど素人じゃない人なら尚更
ただ、それだけだよ？ 良くある最適化のトラブルとしては、基本的なインライン展開なんかでさえ期待通りに動かなくなるケースはあるから、デバッグというか、問題の切り分けに最適化なし。で走らせてみる必要がある。ってのは別に間違ってないと思うんだけど。
Swiftがどういうステップで機械語を作ってるか知らないけど、配列操作の話題については、ループの最適化とか、並列処理への展開とか、するしないで激烈に性能差が出るのも、まあ、そんなものだと思うし。
どの辺が問題なのかよくわかんない。 何も分かってなさそうなやつが技術的興味とか笑かすわ release設定ではデフォルトでオプティマイズ有りだしドキュメントにもオプティマイズしろって書いてあるし
逆にオプティマイズしたらデバッガがトレースできなくなるからdevelopビルドはデフォではオプティマイズされてない。
だからSwiftでreleaseするにはオプティマイズ有りきが前提でしょ あれは全然人間が読めるコードじゃん、、、
むしろ、嗜みとして読めるようになっとけよ >>66
すげーな
例えばllvmコードでFizzBuzz問題を書くとどんな感じになるの？ swiftでFizzBuzz問題のコード書いてemit-llvm-irとかでダンプしれ
その環境もないなら知らんわ >>68
>emit-llvm-ir
ir = intermidiate representationなのね
Web Assembliesにllvmのコードが使われるって聞きました。
なんの事かよく知らんですけど、ブラウザで3Dゲームできるんだってねぇ。 >>68
「llvm fizzbuzz」でググったら出てきたわ おう、良かったな。これでお前もLLVMコード読めるようになったじゃん。
すげーな >>72
情報処理試験、Java選択してラッキーで合格した。
危なかった。 >>49
だからさ、Cに頼るならObj-Cでよくね？ Obj-C、ワンポイント・レッスン
メソッド定義
(戻値)Keyword1:(型)arg1 Keyword2:(型)arg2 Keyword3:(型)arg3
メソッド呼出
[レシーバー Keyword1:arg1 Keyword2:arg2] Obj-Cワンポイント
クラスの定義
@interface MyClass: NSObject {
NSString* message;
}
-(void)setMessage:(NSString*) str;
-(NSString*)message;
-(void)printMessage;
@end
クラスの実装
@implementation MyClass
-(void)setMessage:(NSString*) str {
message = str;
}
-(NSString*)message {
return message;
}
-(void)printMessage {
NSLog(@“%@“, message);
}
@end Obj-Cワンポイント
インスタンス変数
@interface MyClass: NSObject {
NSString* message; // インスタンス変数
}
// インスタンス変数のプロパティ化
@property NSString* message;
@end
プロパティの実装
@implementation MyClass
@synthesize message;
@end これは老害ですわ
なんでこんな古いObjCの記述をするんだよｗ
Modern Objective-Cを学び直すか、ObjCを捨ててSwiftを学ぶべきだな >>82
じゃぁ、Modern Objective-Cを教えて！ Adopting Modern Objective-C
こんなん、見つけた。 #import <FrameWork/lib.h>
@interface MyClass : SuperClass
@property NSString *message;
- (void)printMessage;
@end
#import “MyClass.h”
@implementation MyClass
- (void)printMessage
{
NSLog(@“%@“, _message);
}
@end >>87
@synthesize message;
って不要なのか？
それから、_messageってインスタンス変数が宣言されてない様だが、
@propertyで暗黙的に宣言されるって事か？ スレチを続けてる奴は老害というより単なるガイジだな >>87
>@property NSString *message;
@property (copy)NSString *message;
って書きかえろ！とwarningが出た。
これがModern Objective-Cなのか？ mutable/immutableをクラス分けでしか表現できない残念モダンなObjC 新概念！が出るたびに言語仕様に直接組み込んでは
後で仕様グダグダになる【モダン】より
なんでも「クラスの仕様です」で済ますObj-Cの方が
実はスマートなんじゃないかとずっと Fast Enumだの@synthesisだのドット記法だの@リテラルだのBlocksだのinstancetypeだの...
ObjCほど後から後から醜いツギハギだらけの言語も無いと思うがね 最初からCとオブジェクト機能を糊で貼り合わせたつぎはぎですしおすし ObjectiveCを基準にすれば、他のだいたいのものは良いものだ。 >>97
その都度、新概念！素晴らしい！って絶賛続けた信者はスゴイ
Swiftも新言語！素晴らしい！って受け入れてくれればこうはならなかったろうに >>98
おれはむしろそれが強みだと思ってるけどな
Cのソースがそのまま使えるなんて他言語ではないだろ NSObjectの上にCのソース貼るだけでもうクラスとして取り回しできるしな それをわかってくれるかぁ ゜*。(*´Д`)。*° C++のfriend相当とか、Objective-Cのprotected相当のアクセス指定が欲しいな… 今のswiftで書いたアプリってMavericksではもう動かせんの？ >>107
Deployment Targetを10.6にしてやれば良いんじゃない？
そすれば、Mavericksどころかその前までOKかも。 mozc for iOS使おうと思ったら、日本語の変換候補が出てこない…(泣)
どうしたらいいんだよ… appstoreって2つのアカウント作って別名で登録してもいいの？ >>110
Apple IDを２つ作るって事？
Developer用Apple IDと、non-Developer用Apple ID２つ作ってる人は多いのでは？ >>111
2つのサークル別々に開発して作者名をかえたいの 可変個の引数から別の可変個引数に、可変個扱いのまま渡す方法ってありますか？
func f(_ args: Any...) {
sub(args) //これだと引数1個扱い
}
func sub(_ args: Any...) {
} 補足
Array版を作るしかない？
func f(_ args: Any...) {
sub(args)
}
func sub(_ args: Any...) {
sub(args)
}
func sub(_ args: [Any]) {
} withVaListを使えばできるのかもしれないけど
Array版作ったほうが良さそう
https://stackoverflow.com/a/29401619 >>115
ありがとうございます。
Cのva_list用で、可変個を可変個で、ってものではなさそうですね。 UIApplication.shared.isNetworkActivityIndicatorVisibleはiPhone Xでは表示されないんかな？ 表示されないっぽい
代替表示用してくれても良さそうなものを… Macの市販アプリってGUIの表示がアプリ毎に違ってるけど
あれってMacの標準GUIの見た目だけカスタマイズしてるの？
それともGUIの仕組み自体を自前でプログラムで作ってるの？ swiftでかいてるならだいたいカスタマイズ
unityとかなら全部てづくりかも OpenGLとかMetal使ってるなら手作りするかそれ用のGUIライブラリ使うやろ 詳解Swiftっていまいち詳解じゃないよね
載ってないこと多すぎ 言語仕様という点で日本語書籍でこれより詳解なのある？ Apple公式の奴を翻訳してくれたらそれで十分なんだけどな
あれ結構分かりやいいし >>126
ないな
日本語では一番・詳解Swift
って書名なら正しい お、今回はKindle版も同時発売か
でも固定レイアウトなのね 買い替えじゃなくてアップデートされるなら電子版買いたいな >>127 それがあれば一番だね
今回はiBooksStoreにも出てるよー
なぜかKindle版よりちょっと高いけど 本読むくらい熱心なら、変更内容に加えて
経緯から議論まで追える最強のリストを読んでいった方が良い
https://apple.github.io/swift-evolution/
英語直が無理ならChromeのページ翻訳使えば良いし Swift4 変更点
で、検索したら満足できる記事がヒット iPhoneアプリの開発者離れが起きている。
アプリ提出の審査が理不尽で不公平になってしまって、iPhoneアプリの開発者離れが起きている。
アンドロイドにはKotlinが出てきて開発者が増えている。
Guideline 4.2 - Design - Minimum Functionality
アップルのGuideline 4.2の連発で簡単なアプリはもう提出しても審査には通らない。まだアンドロイドの方が通る。
簡単でなく多機能なアプリでも4.2を連発してくる。もはや作為的やっているとしか言いようがない。
開発者は開発情報のみなもとだった。それを閉め出してからiosの勢いがなくなった。
今からiphoneアプリやってもまず4.2で通らない。審査で落とされる。簡単な機能だけのアプリはまずリジェクトされる。
ちなみに複雑なアプリでも同じようなことが起きている。Rssリーダーのようなアプリでも機能が簡単すぎるといわれリジェクトされている。
アップルは信用できない。これは確か。ころころ方針を変える。昨日まで審査に通ったアプリが、今日から通らなくなるというのが普通にある。 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f) Appleの審査がウザいのは同意だが、少なくともSwiftって言語自体はよくできてると思うんだがな Swiftの変更も含め、開発者に負担かけすぎなんだよな 68k-> PowerPC-> Intel->ARM
toolbox-> carbon-> cocoa-> ?
pascal-> C-> objective-C -> swift 市場の影響やら色々あってやはりクロスプラットフォームが検討される
そこそこのアプリならCordova(TypeScript)、ゲームならUnity(C#)
Xamarin(C#)、Multi-OS Engine(Java / Kotlin)、Kotlin/Nativeとかもあって
Swiftは立ち位置が辛くなりつつある GoogleがSwiftの開発者引き抜いてAndroidアプリもSwiftで開発出来るようにする
って噂があったけど、あれどうなったんだろうな
少し期待してるんだが https://iphone-mania.jp/news-200890/
＞「Swiftは、プログラミング言語がオタクっぽすぎるという認識をもとに作られた。
＞学生の多くはプログラミング言語を見て、”これはできない”と思ってしまう」と、クックCEOは語りました。
＞
＞「誰でも使い方をすぐ覚えられる、Apple製品のようなプログラミング言語をデザインしたかった」と、
＞クック氏はSwiftの敷居の低さを強調しました。
Swiftはそこまでじゃねえな。それならAppleScriptぐらいにしないと。 Swiftはいい言語だと思うけど、やっぱこれからは小鳥が主流になるのかな？
Springも5になって対応して、Webもスマホも作れるし BASICの昔から初心者の最初の理解を阻害しているのが
「型」の存在だ。というのは真理ではあるのだけど
「そういうことはオブジェクトに命令とクラスを渡す形にして
普段はあまり気にしなくていいようにしよう」って言語の後継です！つって
「なんじゃかんじゃわからんものになんじゃかんじゃわからないことするんですよ！進歩してるでしょ？」
って言われてもなんじゃかんじゃわからないソースになるだけだよねコレ？というか… 結局型を意識しなきゃコードは書けないと思う。初めてのプログラミング言語がSwiftだった人達が型を意識しないでいいだとかその他の理由でもいいけど、Swiftを分かりやすいと感じているかどうかが気になる。 型ってそんなにわかりにくいかねえ。$には文字列が入って％には整数が入るとか、
当時小学生だった自分にもわかりやすかったけどね。%と!と#の違いはともかく、$はぜんぜん違うものが入るからなぁ。 昔のBASICも型を意識させないようにしてたろ
方法は違うけど Swiftはコーディングにあまり不満はないが、Buildにクソ長くて開発がままならん。
早くコンパイラーを何とかせい >>151
クロスプラットフォームは多かれ少なかれ面倒なところはあるさ >>152
推論させないで明示的に型を書けば早くなるでしょたぶん Swiftの型推論は初動から風呂敷を広げ過ぎた
双方向推論は含めるべきではなかった
右辺値からの推論のみにしておけば型推論に関するビルド時間はここまで掛からなかったはず let a = b( c() ) { d in e(d) }.f().g()
単方向(右辺値から)だと
・c()の戻り値型c_typeを導出
・b(c_type, func_type)の候補が一つになることをチェック
・func_typeからdを導出
・e(d)戻り値型を導出してfunc_typeと型チェック
・b(..)の戻り値型からb_type.f()を導出
・同様にfの戻り値型からg, gからaが決定
双方向だと e(*)の候補一覧からb(c_type, e_type*).f()が成立するものまで探し始める
bの引数の型が決まってない段階で
その絞り込みのためにf、さらにはgまで先読みして推論し始める
時間が掛かるだけでなくオーバーロードやエクステンションが絡んで
Ambiguousエラー出したり
LazySequence.map(..) -> LazyMapSequence<..> でなく
Sequence.map(..) -> [T] の方に間違って確定したりする Swift3で推論に問題あったケースが、知っている範囲ではSwift4で正常になったので
かなり改善されているようだけどビルド時間はさらに犠牲になってそう
コーディングの利便性のために双方向の推論に対応した結果
ビルド時間が掛かり過ぎて型を明示するようになる本末転倒 
