Swift part11 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
言語仕様としてtypescriptも十分楽しいしあえてswiftえらんでベンダーロックインする必要もない >>64
Core Foundationのソースを見ろ！
いろんなCの関数が並んでる。 swiftってあんまUDP使ってる人いないきがするけど、主流はTCPなの？ iosは基本的にhttpsで通信なんだから強いて言えばtcpなんだろうけど、
今時その層を意識する必要あるのかな。websocketとかある時代だし
ルーター超えとか考慮するのにtcpから触るとか無理ある httpに限らずTCP利用のサービスの方が多いだろ。UDPはよほどパフォーマンス気にするようなサービスでだが、ビデオストリームでさえTCP(それもhttpなんて)でいいやの方が主流でUDP使ってるのが稀になってるだろ (まだ)マイナーなの出しても意味ないだろw
そのQUICとやらも>>69が使うぶんにはTCPだのUDPだの気にすることは無いだろし。UDPでちまちまやるんだったら意味ねえからな リアルタイム性が重要な分野以外では生UDPの出番なんてない
QUICだって結局改良版TCPじゃん Aさんが書いたコードなclassだらけ、Bさんが書いたコードはstructだらけ
classは糞、structは糞と水と油をひたすら掛け合う日々
このクソ言語なんとかして 互いにだらけになる方がおかしいだろ
一方は値型で一方は参照型なのに
どんなアプリ作ったらそんなんなるんだ？ Aさんはstruct不要論者のjavaerでclassしかつかわない
Bさんは継承アンチで基本struct、部分的にclassを使う
はあ糞すぎる >>76
When to use struct?
https://stackoverflow.com/questions/521298/when-to-use-struct
Choosing Between Class and Struct
https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/choosing-between-class-and-struct
✓ CONSIDER defining a struct instead of a class if instances of the type are small and commonly short-lived or are commonly embedded in other objects.
X AVOID defining a struct unless the type has all of the following characteristics:
It logically represents a single value, similar to primitive types (int, double, etc.).
It has an instance size under 16 bytes.
It is immutable.
It will not have to be boxed frequently. goみたくclass無くしてstructだけにしてくれたら良かったのにね。
値型と参照型の違いとは言うけど、
普通にそんなん考慮して使い分けてるのって何割いるか >>81
型定義で指定するか変数定義の違いだけでは classはiOS frameworksとの互換性維持のためにあるだけだろ
基本structでいいよ
サーバーサイドはほぼStruct一色だわ var a = Array<Int>()
var a = [abc]()
違いって何？ >>59
誰も答えないからやってみた
ref. ttps://stackoverflow.com/a/41308592
@IBAction func BtnClick_ConnectTest(_ sender: Any) {
//接続先設定
var port:Int32 = Int32(_textFirld_sendPort.text!)!
var IP:String = _textField_sendIP.text!
var str:String = "test"
MyScocket_init()
setScoketSend(port,IP)
SendUDP(str)
}
int SendUDP(const char* str) {
// パケットをUDPで送信
int ret = sendto(g_sockets[SOCK_SEND].sd, str, strlen(str), 0,
(struct sockaddr *)&g_sockets[SOCK_SEND].sock, sizeof(g_sockets[SOCK_SEND].sock));
if( ret < 0) {
perror("sendto");
}
return ret;
}
昔はUnmanagedやらOpaqueやらUnsafeやら操作しなきゃいけなかったような気がするけど変わったかな
まぁ、Stringは(ほぼ)組み込み型で特別扱いされてるだけで、ARC管理下の自前オブジェクトは管理が必要なはず >>85
ありがとうございます！
助かりました。
ちなみにiosでTCP/UDP使う時に使いやすいapiないですか？
今回、UDP通信するにあたってCFソケットも検討したんですが、いまいち使いづらくて
C言語の方が慣れてるんでCで書いたんですけど Cのでええやん？慣れてるなら
あくまでもSwiftっぽくなら、Objective-Cのでもええやろ？iOS APIがほぼそれなんだし >>88
ありがとう。Cで書くよ
調べてたらswiftでCでソケット通信を作るのは一般的じゃないみたいな記事みたからちょっと気になった Cで出来てることはObjective-Cならそのままできる >>86
ポインタがないのが面倒なんじゃなくARCが面倒なんだぞ
今回はARC度外視できたけどARC管理下のオブジェクト取り回しはObjCでも同じだからな Pythonみたいに極限までに研ぎ澄まされたシンプルさと美を兼ね備えた言語で開発したい if __name__ == '__main__':
美しい？ >>94
無駄にかっこ無くしたSwiftも似たようなもんだけどな 日本ではSwift大人気だけど、海外だとそれほど人気ないらしいね。
言語ランキングとかだと日本だけ異様に高いらしい。 >>96
だろうな
相当のApple信仰心がないと付き合ってらんねぇよってなるだろ
しかもにわかでない元々のApple好きはJobs教だからObjective-Cでいいって思ってるし >>94
書きたくなければ書く必要ないんだぜ。
そもそもswiftじゃ同じことを書くことすらできないだろ。。 スクリプトはPython一強になりつつあるな
コンパイラは何だかんだとJAVA、強者はC/C++で次点にC#が勢いを増しつつある感じ >>92
Python文法を踏襲しつつ、イマドキ？な言語PFになってるnimがあるぞ
Swiftを越えるクソっぷりで海外でも日本でも不興だけども >>102
wikipedia見ただけだと凄そうなんだけど、どんなところがクソなの？ >>103
1. 目標として掲げた言語仕様に対する完成度がswift betaくらいに未完成
2. nimソースを他言語ソースにコンバートして、他言語ソースをネイティブバイナリにコンパイルという微妙なコンパイル手法
3. 1, 2に引きずられているのか書いたコードが仕様通りに動かない(バグったコードがバグるんじゃなく、正しいコードがバグる
Python好きだし期待してた頃もあったけど、一向に完成度が上がらないから諦めた
大企業スポンサーがつかない新興言語はどうしようもないんだなって, Apple/IBMがついてるSwiftはまだマシ 2の手法は良いと思うけどな
まぁ完成しないんじゃどうしようもないけど コンバートって
なんかの言語がPythonっぽい見た目だったらいいなーと思って作ったのだろうか 一応、GCが付いてたりとランタイムに独自機能は乗ってるけどな
SwiftもObjCへのトランスコンパイラとして実装すれば良かったのかもしれないとふと思った
その程度だとApple公式PJになる意義はなかったかもだけど、今のSwiftランタイムの存在意義と比べてトントンじゃね >>109
objcって中身は動的言語みたいなもんだからメッセージ呼び出しのオーバーヘッドがかなりある。 呼び出しのオーバーヘッドもなにもクラス実体があるポインタアドレスに
まるっとデータ送ってるだけだから逆にリンカがコンパイル時に
「ここ」って指定してるのとどこがそんなに違うんですか？的な メッセージ式って、レシーバーが文字列解析してるとか？ SwiftはObjCと違ってメッセージ呼び出しのダイナミックコールしないから早いんだぜって言ってたな
なお体感できるものだとは思えない すまん語弊があるな、ダイナミックコールしないケースがある、が正しかった まあ何と言われようと、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好きに迷惑だからやめろやｗ >>139
時々見る、この「つ」ってどういう意味？ >>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を起動すると捕捉できるんだよねぇ。 ■ このスレッドは過去ログ倉庫に格納されています
