Swift part11 [無断転載禁止]©2ch.net

2017/06/28(水) 17:58:29.74

WWDC2014で発表されたAppleの新言語Swiftについて語りましょう

関連スレ

プログラミング言語Swift　Part4
http://egg.2ch.net/test/read.cgi/mac/1484763495/

[SDK]iPhoneアプリ開発初心者質問箱48[touch][iPad]
http://egg.2ch.net/test/read.cgi/mac/1484217623/

Xcode part14
http://egg.2ch.net/test/read.cgi/mac/1476190499/

Swiftアンチスレ part1
http://mevius.2ch.net/test/read.cgi/tech/1458491343/

前スレ
Swift part10
http://mevius.2ch.net/test/read.cgi/tech/1487552413/

スレ立て時は1行目に「!extend::vvvvv」

VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

**デフォルトの名無しさん** (JP 0H9b-Gzhg) · 2017/06/28(水) 19:25:31.37

1+1/2+1/4+1/8+....

2017/06/28(水) 21:39:14.29

＞ただし、Swiftは「クズ」だと思っている人は今でもいる

ひどい言われようだな。

「Android」アプリ開発言語に加わった「Kotlin」--開発者が寄せる期待
https://japan.techrepublic.com/article/35103377.htm

2017/06/30(金) 10:41:27.25

瑕疵担保責任（かしたんぽせきにん）

納品されたシステム、プログラムに不具合があった場合、10年後でも無償で修理してもらうことが可能になった。

民法改正で事実上期限が「無制限」になった
不具合を指摘されたらすぐに行動をとるべし　納品物に不具合があれば損害賠償を請求される可能性もある

http://www.atmarkit.co.jp/ait/articles/1706/26/news014.html
http://itpro.nikkeibp.co.jp/atcl/news/17/052601508/?rt=nocnt

改正法では欠陥に気付いてから1年以内にITベンダーに通知すれば、通知後5年以内は修正や報酬の減額などを求められるとしている

全ベンダーが泣いた民法改正案を解説しようその1
http://www.atmarkit.co.jp/ait/articles/1609/14/news009.html
http://www.atmarkit.co.jp/ait/articles/1609/14/news009_2.html
http://www.atmarkit.co.jp/ait/articles/1609/14/news009_3.html

ポイント1：修補や損害賠償、契約解除の期限がなくなる

従来あった「瑕疵担保期間は引き渡しから1年」という考えはなくなる。
条文にある通り、注文者は成果物が契約の目的に適合しないことを発見したら、
その「発見したときから1年以内」ならさまざまな請求ができる。発見が10年後なら、11年後まで請求可能なのだ。

もっとも、現実のユーザーとベンダーの関係でも、たとえ契約書に「瑕疵担保責任期間は納品から1年と」明記されていても、
「2年目以降は不具合の修正に対応しない」と主張するベンダーはまれだ。多くの場合は、納品から何年たっても、
バグが見つかればユーザーのところに飛んで行き、無償で改修するだろう。

重大な脆弱性が現バージョンから発見されました。こちらでアップデートしたところ、起動ができなくなりました。
至急弊社に来て修正作業をお願いします。なおお金は払わない。また営業に損失が出たので損害請求もする。

2017/07/02(日) 09:49:55.33

kotolinは劣化Swiftだけど、進化Javaではあるからな

2017/07/02(日) 10:10:02.70

>>5
Kolin nativeってのもあるし、Swift -> Kotlinへの移行しても良いかも。
Androidアプリ作って見たいし、だからと言ってJavaは嫌いだし。

2017/07/02(日) 10:23:22.94

>>5

//Kotlin
val a = generateSequence(0){it+1}
println( a.map{it*10}.filter{50<it}.take(5).toList() ) //正常動作

//Swift
extension Sequence { var array:[Iterator.Element] {get{return map{$0}}} }
let a = sequence(first:0){$0+1}.lazy
print( a.map{$0*10}.filter{50<$0}.prefix(5).array ) //実行時エラー

2017/07/02(日) 10:48:50.80

やっぱりJavaVMで動くKotlinは最強やな

>>6
実用に至ってから出直せｗ

2017/07/02(日) 11:53:55.69

>>7
lazy使って、実行時エラー回避できるんじゃなかったっけ？

2017/07/02(日) 13:53:19.97

>>9
既に let a = ….lazy でaはLazySequenceになっている

しかしオーバロードと型推論の設計上の問題により
LazySequence.filterでなくSequence.filterが呼ばれるため
prefixより前に無限シーケンスを全て処理しようとして死ぬ

2017/07/02(日) 15:07:17.13

Obj-Cで困らないんだが...

2017/07/02(日) 16:07:05.73

WWDCのSwiftのハイライト教えてください。どの辺がパワーアップした？

2017/07/02(日) 18:40:03.44

>>10
なるほど
回避するにはどう書けば良い？

2017/07/02(日) 18:44:51.58

SwiftとXcode学ぼうとおもってるんだけど、オヌヌメの本ある？

2017/07/02(日) 18:55:19.60

>>13
型推論ちゃんがドジらないようメソッドチェーンせず一つずつやらせる

do {
let a2 = a.map{$0*10}
let a3 = a2.filter{50<$0}
print( a3.prefix(5).array )
}

2017/07/02(日) 19:10:09.36

4.0だと>>7で問題ないぽいな

2017/07/02(日) 19:23:57.56

>>14
あんたのbackground次第だな。
萩原本は、万人向けだが。

2017/07/02(日) 20:44:23.57

>>16
確かに4だと直ってるな
issues見たけどオーバーロードやlazy等に関する直接的な対応は見付けられなかった
オーバーロード解決に後続のチェーン使う地雷が修正されてるなら有り難いけど

2017/07/02(日) 21:36:26.29

>>15
ありがとう
いつか嵌ったときに思い出すよ

2017/07/07(金) 10:54:58.74

ワンライナーに至上の価値を置いてるやつは初心者
複数言語、プラットフォームにまたぐ開発をやったことなく
狭い世界で安全なコード規約に保護されてないと開発できない箱入り息子ども
その狭い価値観でプログラミング言語を語り出すと>>7のような間抜けなことを言い出す
SwiftがあるのにピザってるJVMで動作するkotlinを選ぶやつは初心者も初心者

2017/07/07(金) 10:58:39.58

ていうかKotlinなんか眼中になくてCrystallangやElixirがめっちゃ気になってるんだがね
やつらベンチだとSwiftより速いらしいやん
どんなマジック使ってるんだ

2017/07/07(金) 12:57:22.01

他言語を専スレで話題にしようとする初心者
加えて、VM言語が下手なネイティブより高速になることがある背景を知らない初心者

Swiftは特定条件下ではobjcより早いけど、一般的には別段速くないって昔から言われてるから

2017/07/07(金) 16:27:22.50

"ワンライナー"と呼んでいるやつは初心者

ちなみにElixirでは単なるメソッドチェーンに留まらずパイプ演算子が用意されている
https://blog.drewolson.org/elixir-streams/

import Stream
a = iterate(0,&( &1+1 ))
IO.inspect a |> map(&( &1*10 )) |> filter(&( 50<&1 )) |> take(5) |> Enum.to_list, char_lists: false

2017/07/08(土) 17:59:47.97

Obj-Cで困らないんだが...

2017/07/08(土) 18:06:37.95

Cベースじゃないモダンスタイル言語にsmalltalk思想かと思ったら
objective-Cとまったく関係ない実験作が出てきたからなぁ…
あきらかにAppleWatchともどもジョブズが
「これじゃまだダメだろ」って止めてたのが
お漏らしして表に出てきちゃった感

2017/07/08(土) 20:54:25.61

Obj-C使ってる奴の老害感(Mac板

2017/07/08(土) 21:44:39.09

>>26
Swift　 -> ObjCへ移行中。Swiftだけしか知らない事に、危機感。
ObjCコンパイル早いし。

2017/07/08(土) 23:37:48.53

>>26
老害以外に言うことないのかね...

2017/07/09(日) 05:46:33.77

>>26
ボキャブラリ貧困

2017/07/09(日) 07:02:46.84

mac板での自爆ギャグが悔しかったのか必死だなｗ
こっちの板はアンチスレもあるし老害orガイジでないならそっち行くといいよ

2017/07/09(日) 09:43:38.60

他スレにも出向いてObj-C=老害を吹聴してSwiftを布教して回ってんのかよ...

82 1 名前:名称未設定 (ｻｻｸｯﾃﾛﾘ Sp71-yTFi) Mail:sage 投稿日:2017/07/03(月) 20:24:07.40 ID:ipKiHhaqp
これは老害ですわ
なんでこんな古いObjCの記述をするんだよｗ

Modern Objective-Cを学び直すか、ObjCを捨ててSwiftを学ぶべきだな

2017/07/09(日) 09:48:07.95

>>26
何歳から老害なんですか？
あなたはいつから老害になるんですか？
それとも、歳くってもModernな言語をさわって布教してれば老害にはならないのですか？

2017/07/09(日) 09:50:16.64

いや、そこSwiftスレじゃん
そしてあまりにも酷いObjCコードをスレチで書いた老害が悪いわｗ
業務ではObjCしか使わないしSwiftが良い言語と思っちゃいないが、専スレでアンチは勘弁な

2017/07/09(日) 10:04:05.98

>>33
もう一度おききしますね

何歳から老害なんですか？
あなたはいつから老害になる予定ですか？
それとも、歳くってもModernな言語をさわって布教してれば老害にはならないのですか？

2017/07/09(日) 10:09:22.98

(^^;;

2017/07/09(日) 10:43:37.17

ObjCでいいはないだろ...
何たってサーバーサイドも書けるんだぜ？
何もせんでもキャリアが伸びるこんなおいしい話はない
来年あたりSwiftのサーバーサイドでの積極採用の会社も出てくると予想してる

2017/07/09(日) 10:50:14.35

>>34
Modern Objective-Cが書けるなら老人であっても老害じゃないんじゃないの
あとSwiftスレでObjCで荒らしてるのはガイジかな:)

2017/07/09(日) 10:59:41.20

>>36
さすがにそこまではないと思う
サーバーサイドに使われるようになるには
ライブラリやフレームワークの充実度が重要
すでに他言語が相当前にいるので追いつくまでそうとうかかる

2017/07/09(日) 11:16:23.18

>>36
サーバーサイドは実験レベルで書けるけど実務レベルでは無理だろ
まだまだ時間が必要だと思う

2017/07/09(日) 11:16:38.17

>>34
老害＝年齢で決まると思ってる時点でお前はただのアホやで

2017/07/09(日) 12:31:30.62

>>40
shine

2017/07/09(日) 12:35:41.50

>>34
お前が老害

2017/07/09(日) 12:39:52.64

>>29
>>42
shine

2017/07/09(日) 12:40:36.19

ObjC専用スレ覗いて見た。最後のレスが今年の2月だった。
ObjCをちょっと触ってるけど、良い感じだわぁ。
ちょいと、メソッド名が冗長な感じはするけど、スルスルとコンパイルされるのが良い。

コンパイルエラーが不親切って感じはするけど。
その点、Swiftコンパイラは親切but時間かかる。

2017/07/09(日) 12:56:04.79

差分ビルドなら結局ObjCもSwiftも大して差を感じたことがないが
Swiftのビルド遅い遅い言ってるのは常にクリーンビルドでもやってんのかな
それかMacbook or Airだと体感差が出るとか？Proだと差が感じられない

2017/07/09(日) 12:57:56.01

まーSPMの構成変えた後一からビルドすることになる時は俺もｲﾗｯ☆とするけどな

2017/07/09(日) 13:13:17.68

>>45
SSDだとSwiftが遅いって思ったこと無いけど、HDDだとめちゃくちゃ遅く感じる、というかやってられない

2017/07/09(日) 13:21:17.87

ビルドの速さを語るときはせめての目安としてコンパイルするファイル数も言わないと意味がないかと

2017/07/09(日) 13:23:32.50

Copying swift library ... が怒り通り越して笑いが出る
SSDでも普通に体感差があるけどないの？

2017/07/09(日) 13:24:42.64

AppleがCoffeeタイムを提供してくれているのさ

と信者ならポジティブに解釈できることだろう

2017/07/09(日) 17:27:56.47

Swiftのビルドは遅いと思わないな。
遅いと言ってる人は多分StoryBoard使ってたり、変数の宣言時に型指定してないんだろうな。

2017/07/09(日) 18:51:26.63

型推論全否定すんな
だいたいC#はvarでも速いぞ

2017/07/10(月) 07:36:25.56

型推論の比較対象はC++だろｗ

2017/07/10(月) 08:29:12.31

ふーんHDDだとそんなに遅いんだ
Pro Retina SSDがSwiftやる上での下限スペックってことかな
13inch 128GBは罠だが・・・

2017/07/10(月) 18:53:10.56

ARCって循環参照したらメモリリークすんでしょ？

だからってweakとかunownedにしたら間違って解放後にアクセスしちゃうかもしれないし
マジ使えねー

2017/07/10(月) 20:47:48.41

>>44
Objective-Cはキモいくらいにコンパイル速いよな。
なんかSwiftよりも楽しそうな感じするな。

2017/07/10(月) 22:05:22.14

>>55
自分でメモリ管理したら循環参照しないってこと？
どっちもどっちだろ
あんまり関係ないと思うけど

2017/07/10(月) 22:20:27.57

たぶんガーベージコレクションなら背後でCPUパワーを食い続けて全部監視してくれる！と言いたいのでは

2017/07/10(月) 23:35:14.81

Cで作った関数をSwift上で使いたいのですが、
文字列のアドレスを渡す関数でエラーが出てしまいます。
何が原因でしょうか。。。

@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(Unmanaged<AnyObject>.passUnretained(str as AnyObject).toOpaque() ,str.utf16Count)
}

int SendUDP(char* str, int strsize){
// パケットをUDPで送信
int ret = sendto(g_sockets[SOCK_SEND].sd, str, strsize, 0,
(struct sockaddr *)&g_sockets[SOCK_SEND].sock, sizeof(g_sockets[SOCK_SEND].sock));
if( ret < 0) {
perror("sendto");
}
return ret;
}

エラー内容
Cannot convert value of type 'UnsafeMutableRawPointer' to expected argument type 'UnsafeMutablePointer<Int8>!'

2017/07/10(月) 23:36:58.98

>>59
すみません。エラーが出ている箇所はSendUDP(char* str, int strsize)を呼び出した部分でエラーが出ています。
その他の場所は特に問題ないみたいです

2017/07/10(月) 23:37:47.31

GCと比較してたのか…
それなりのコストかかるから単純に比較できんけどなぁ

2017/07/10(月) 23:39:48.29

>>59
何が原因って、エラー内容のままじゃん…
英語読めないならぐくるとかしてみなよ

2017/07/10(月) 23:52:21.77

>>59
bindMemory

2017/07/11(火) 01:40:47.21

最近書き始めたけど、これ凄いな
簡単にアプリ作れて驚いた、凄い書きやすいわ
ただ基本的な文法をもっと勉強したいんだけど、良い参考書って何かないですかね
アプリ入門系の本だと、アプリで使うメソッドしか解説がないのでもっと基本的な所から勉強したい

2017/07/11(火) 03:13:01.93

とりあえず萩原本の最新の買っとけ

2017/07/11(火) 04:41:16.12

言語仕様としてtypescriptも十分楽しいしあえてswiftえらんでベンダーロックインする必要もない

2017/07/11(火) 11:23:21.08

>>64
appleにあるでしょ

2017/07/11(火) 11:56:52.95

>>64
Core Foundationのソースを見ろ！
いろんなCの関数が並んでる。

2017/07/11(火) 12:07:35.73

swiftってあんまUDP使ってる人いないきがするけど、主流はTCPなの？

2017/07/11(火) 12:25:37.46

主流も何も用途次第でしょ

2017/07/11(火) 13:47:20.91

iosは基本的にhttpsで通信なんだから強いて言えばtcpなんだろうけど、
今時その層を意識する必要あるのかな。websocketとかある時代だし
ルーター超えとか考慮するのにtcpから触るとか無理ある

2017/07/11(火) 15:38:11.48

httpに限らずTCP利用のサービスの方が多いだろ。UDPはよほどパフォーマンス気にするようなサービスでだが、ビデオストリームでさえTCP(それもhttpなんて)でいいやの方が主流でUDP使ってるのが稀になってるだろ

2017/07/11(火) 18:57:19.43

QUIC

2017/07/11(火) 19:48:11.70

(まだ)マイナーなの出しても意味ないだろw
そのQUICとやらも>>69が使うぶんにはTCPだのUDPだの気にすることは無いだろし。UDPでちまちまやるんだったら意味ねえからな

2017/07/11(火) 20:10:17.79

リアルタイム性が重要な分野以外では生UDPの出番なんてない
QUICだって結局改良版TCPじゃん

2017/07/11(火) 20:23:33.95

Aさんが書いたコードなclassだらけ、Bさんが書いたコードはstructだらけ
classは糞、structは糞と水と油をひたすら掛け合う日々
このクソ言語なんとかして

2017/07/11(火) 20:40:30.35

互いにだらけになる方がおかしいだろ
一方は値型で一方は参照型なのに
どんなアプリ作ったらそんなんなるんだ？

2017/07/11(火) 20:58:45.14

>>76
AさんBさんに、使い分けどころか組み合わせることもあるんすよって教えてあげて
https://github.com/apple/swift/blob/master/stdlib/public/core/HashedCollections.swift.gyb#L36

2017/07/11(火) 21:12:02.54

Aさんはstruct不要論者のjavaerでclassしかつかわない
Bさんは継承アンチで基本struct、部分的にclassを使う
はあ糞すぎる

2017/07/11(火) 21:21:14.43

>>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.

2017/07/11(火) 23:20:13.04

goみたくclass無くしてstructだけにしてくれたら良かったのにね。
値型と参照型の違いとは言うけど、
普通にそんなん考慮して使い分けてるのって何割いるか

2017/07/12(水) 00:00:01.48

>>81
型定義で指定するか変数定義の違いだけでは

2017/07/12(水) 12:14:48.88

classはiOS frameworksとの互換性維持のためにあるだけだろ
基本structでいいよ
サーバーサイドはほぼStruct一色だわ

**デフォルトの名無しさん** (JP 0H3f-KuRC) · 2017/07/12(水) 13:32:57.34

var a = Array<Int>()
var a = [abc]()
違いって何？

2017/07/12(水) 17:42:49.46

>>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管理下の自前オブジェクトは管理が必要なはず

2017/07/12(水) 18:21:47.80

ポインターがないSwiftめんどくさ

**デフォルトの名無しさん** (JP 0H8a-FPdr) · 2017/07/13(木) 13:42:07.18

>>85
ありがとうございます！
助かりました。
ちなみにiosでTCP/UDP使う時に使いやすいapiないですか？
今回、UDP通信するにあたってCFソケットも検討したんですが、いまいち使いづらくて

C言語の方が慣れてるんでCで書いたんですけど

2017/07/13(木) 14:26:17.90

Cのでええやん？慣れてるなら
あくまでもSwiftっぽくなら、Objective-Cのでもええやろ？iOS APIがほぼそれなんだし

**デフォルトの名無しさん** (JP 0H8a-FPdr) · 2017/07/13(木) 17:57:36.12

>>88
ありがとう。Cで書くよ
調べてたらswiftでCでソケット通信を作るのは一般的じゃないみたいな記事みたからちょっと気になった

2017/07/13(木) 22:54:25.78

Cで出来てることはObjective-Cならそのままできる

2017/07/15(土) 09:53:18.00

>>86
ポインタがないのが面倒なんじゃなくARCが面倒なんだぞ
今回はARC度外視できたけどARC管理下のオブジェクト取り回しはObjCでも同じだからな

2017/07/16(日) 18:56:33.79

Pythonみたいに極限までに研ぎ澄まされたシンプルさと美を兼ね備えた言語で開発したい

2017/07/16(日) 23:52:07.18

if __name__ == '__main__':

美しい？

2017/07/17(月) 08:21:51.45

>>93
とても高級言語とは思えない醜さ

2017/07/17(月) 09:25:14.61

>>94
無駄にかっこ無くしたSwiftも似たようなもんだけどな

2017/07/17(月) 10:35:41.40

日本ではSwift大人気だけど、海外だとそれほど人気ないらしいね。
言語ランキングとかだと日本だけ異様に高いらしい。

2017/07/17(月) 10:39:22.12

>>96
だろうな
相当のApple信仰心がないと付き合ってらんねぇよってなるだろ
しかもにわかでない元々のApple好きはJobs教だからObjective-Cでいいって思ってるし

2017/07/17(月) 10:49:55.85

隙あらば妄想語り

**デフォルトの名無しさん** (JP 0H3a-G/zD) · 2017/07/17(月) 15:18:50.28

>>93-94
shebangが美しいとかω

2017/07/17(月) 16:28:59.78

>>94
書きたくなければ書く必要ないんだぜ。
そもそもswiftじゃ同じことを書くことすらできないだろ。。

2017/07/17(月) 22:42:54.90

スクリプトはPython一強になりつつあるな
コンパイラは何だかんだとJAVA、強者はC/C++で次点にC#が勢いを増しつつある感じ

2017/07/18(火) 07:56:20.08

>>92
Python文法を踏襲しつつ、イマドキ？な言語PFになってるnimがあるぞ
Swiftを越えるクソっぷりで海外でも日本でも不興だけども

2017/07/19(水) 00:14:23.59

>>102
wikipedia見ただけだと凄そうなんだけど、どんなところがクソなの？

2017/07/19(水) 03:21:11.49

これからはDNAプログラミングの時代

2017/07/19(水) 12:36:23.74

>>103
1. 目標として掲げた言語仕様に対する完成度がswift betaくらいに未完成
2. nimソースを他言語ソースにコンバートして、他言語ソースをネイティブバイナリにコンパイルという微妙なコンパイル手法
3. 1, 2に引きずられているのか書いたコードが仕様通りに動かない(バグったコードがバグるんじゃなく、正しいコードがバグる

Python好きだし期待してた頃もあったけど、一向に完成度が上がらないから諦めた
大企業スポンサーがつかない新興言語はどうしようもないんだなって, Apple/IBMがついてるSwiftはまだマシ

2017/07/19(水) 16:09:56.39

2の手法は良いと思うけどな
まぁ完成しないんじゃどうしようもないけど

2017/07/19(水) 20:32:46.34

コンバートって
なんかの言語がPythonっぽい見た目だったらいいなーと思って作ったのだろうか

2017/07/19(水) 20:34:41.55

ただのトランスコンパイラ

2017/07/21(金) 13:51:26.30

一応、GCが付いてたりとランタイムに独自機能は乗ってるけどな

SwiftもObjCへのトランスコンパイラとして実装すれば良かったのかもしれないとふと思った
その程度だとApple公式PJになる意義はなかったかもだけど、今のSwiftランタイムの存在意義と比べてトントンじゃね

2017/07/21(金) 20:51:00.68

>>109
objcって中身は動的言語みたいなもんだからメッセージ呼び出しのオーバーヘッドがかなりある。

2017/07/21(金) 21:03:26.40

>>110
と思っていた時期が私にもありました

2017/07/21(金) 21:32:57.35

呼び出しのオーバーヘッドもなにもクラス実体があるポインタアドレスに
まるっとデータ送ってるだけだから逆にリンカがコンパイル時に
「ここ」って指定してるのとどこがそんなに違うんですか？的な

2017/07/21(金) 21:50:28.57

メッセージ式って、レシーバーが文字列解析してるとか？

2017/07/21(金) 22:25:12.37

文字列解析はランタイムだろ

2017/07/21(金) 22:30:29.43

SwiftはObjCと違ってメッセージ呼び出しのダイナミックコールしないから早いんだぜって言ってたな
なお体感できるものだとは思えない

2017/07/21(金) 22:31:33.55

すまん語弊があるな、ダイナミックコールしないケースがある、が正しかった

2017/07/22(土) 15:09:54.42

まあ何と言われようと、OSX、iOSをここまで発展させてきたObjective-Cの実績は事実として存在している

2017/07/22(土) 15:18:51.98

apple専用言語だから実績と言われてもピンと来ない

2017/07/22(土) 15:43:16.95

iOSが毎年更新してるのにアホみたいに安定してる事実が
もう「あたりまえ」だと思われてるんだなぁ…
C/C++製の自分の足下の更新ペースと安定性を忘れきってるのが笑える。

2017/07/22(土) 15:59:40.76

Cocoa, UIKitで他の言語が使えないからなぁ
ObjCだったから発展したんじゃなく、発展に合わせてObjCが普及したのが事実よな

Swiftでないと使えないという環境がないから普及しねぇ
Carthageも流行らなかったから普及に貢献してないし

2017/07/22(土) 16:20:59.31

>>120
Objective-Cだから発展したというよりは、Objective-Cのままでも何ら問題がないということだろう

2017/07/22(土) 21:33:30.66

Carbon(C++)からCocoa(ObjC)に切り替えて選択肢を無くした状態でObjCをゴリ押ししたからな
Swiftのゴリ押し、足りてないよー

2017/07/22(土) 22:47:39.39

>>122
あの時はそもそもOSが根本的に変わったけどな

2017/07/22(土) 22:49:41.31

まあObjective-CはJobsが原点回帰(NeXT系譜)した感じだな

2017/07/22(土) 23:41:33.63

>>122
CarbonがいつC++だったのよ。Cだろ
>>123のいう根本から変わる過渡期にどうするかで出てきたCarbonなんて最初からいつか無くなる運命だし、Carbonよりも先にObjective-Cあったので切り替えでもなんでもないだろ
いつまでもOSネイティブなObjective-Cにしなかったアホが悪いでしかないのに、ゴリ押しとか基礎も結論も妄想がひどすぎ

2017/07/23(日) 00:09:20.02

Swiftやってる連中はにわかが多いからしゃーない

2017/07/23(日) 02:37:14.48

>>118
ソニーが採用してただろ

2017/07/23(日) 02:58:25.19

旧MacOSはそういやPascal推しだったの思い出した

2017/07/23(日) 07:21:28.71

Pascal, C/C++を拒否してObjCに強制誘導してるじゃないか、、、
同じようにSwiftも頼むよー

2017/07/23(日) 08:39:16.33

C/C++が拒否されてるなんて全く感じたこと無いけど
C/C++でバリバリ書かれてるコードにちょっとCocoa APIをObj-Cで呼び出せばプログラムが完成するって感じだと思うけど
ObjCに強制誘導って思うのは、単にMac OS XのAPIを学びたくないからじゃないの？

2017/07/23(日) 11:21:23.34

強制誘導ってアホか？
Objective-CのベースだってMac OS X/OS X/macOSのバージョンアップによってC++に書き換えられてるし、CoreはCのままだし、OS X/CocoaはほぼNEXT STEPのまんまと言っていいくらい元々Objective-Cだし、IO KitはC++で書けだし

2017/07/23(日) 11:40:38.80

>>128
推しというか、Macの開発(ほんとの生み出す開発)はPascal/Assembleで作っていたんだなあというのは、どこぞの博物館で公開されたQuickDraw/MacPaintのソースでわかる
推すも何もそうだったらそうなるだろ、ドキュメントとか。だが、サード開発ではCが大多数(＆CでPascal形式API呼ぶのにほぼツーカーで何も問題ない)で、Appleもそれにならうでしかないな

2017/07/23(日) 12:24:47.14

The 2017 Top Programming Languages
http://spectrum.ieee.org/computing/software/the-2017-top-programming-languages

2017/07/23(日) 12:29:34.74

Google Search
Google Trends
Twitter
GitHub
Reddit
などなどを"X programming"っていうテンプレートで検索し、hits countsをrankingしたって事らしい。

2017/07/23(日) 12:31:12.51

>>130
ObjCをちょっと書かないとmacOS, iOSアプリが作れないように
Swiftをちょっと書かないとモノが作れないくらいのゴリ押しして欲しいなぁと

Appleは作りっぱなしで押さないし、信者はジョブズの聖遺物(ObjC)を崇めるし
Appleがゴリ押しした製品に寄生して銭稼ぎしようとbetaの頃に始めたのに悲しいよ

2017/07/23(日) 12:40:43.51

世界初のWebブラウザはObjective-Cによって産み出された
まあどーでもいいけど、いまやWeb全盛の時代にそういう言語で最新のアプリが作れる環境が与えられてんだから少しくらい感慨というものを感じてもいいんじゃないの

2017/07/23(日) 12:58:28.23

元々アホかなとは思ったが, >>135ぶりからアホってもんじゃねええ。Swift好きにも迷惑だと思うぞ

2017/07/23(日) 13:19:23.25

>>130
C++を拒否というならSwiftによって／Swiftがだろうな、現在はw
macOS上のSwiftでは、まあ、Objevtive-C++でラッパー書いてそれをSwiftでだが、Linuxでぼちぼちっとじわっと使われているので、はよSwiftでC++のブリッジを(まあ、Cのインターフェースでラッパー作ればいいんだろうけど)
C++ブリッジの予定ないのかなあ

2017/07/23(日) 13:22:04.20

つ swiftpp

2017/07/23(日) 13:26:14.58

Uiview.アニメーション関数を使いたいのですが、uiviewanimationoptionsの選択肢が
でてきれくれません。Youtubeを参考にしながら、optionsの部分をcurveLiniearに
したいのですが・・・cを入力しても候補が一切表示されず途方に暮れています。
どういった原因が考えられますか？助けてください。ゲーム作りたいです。

2017/07/23(日) 13:27:23.92

>>139
macOS/Objevtive-C++ありきのじゃね？

2017/07/23(日) 13:49:07.88

>>127
すげー初耳なんだけど

2017/07/23(日) 16:19:01.64

rustのメモリ管理の仕組みが採用されたらどんだけ幸せになれんのかな。
そもそもrustごと採用してくれれば良いのに

2017/07/23(日) 20:38:41.65

Rust使いがあんまり幸せそうじゃない件

2017/07/23(日) 20:39:56.87

いやそうでもないか…

言語仕様に振り回されてはいるが大概自分に原因を帰着してる
まだ信仰心旺盛なようだ

2017/07/23(日) 21:47:12.66

Rustなんか採用されたら気が狂うわ

2017/07/24(月) 07:40:43.41

でも静的にメモリ管理を解決するって
どんだけ良いものか気になるんだよね。
どうせswift5辺りで採用されんだから、先にrustに触って先行学習してても良いかもね。
多分swiftに採用されたら下位互換性また壊れるぜ

2017/07/24(月) 07:47:11.93

Rustの元になってるC++ std::unique_ptrをどうぞ
ObjC++でも使えるゾ

>>141
下手な風評はSwift好きに迷惑だからやめろやｗ

2017/07/24(月) 09:18:58.69

>>139
時々見る、この「つ」ってどういう意味？

2017/07/24(月) 09:21:05.48

三重の県庁所在地じゃない？

2017/07/24(月) 09:52:25.50

>>149
「つ」は、差し出す手のイメージ

2017/07/24(月) 10:26:23.68

>>148
c++にはなんでもあるんだね。
でも言語仕様で縛らなくても静的にメモリ管理って可能なの？c++のプリプロセッサがすごいってこと？

2017/07/24(月) 10:27:01.25

>>151
俺には「つ」が手に見えない。手のひら？手の甲？

2017/07/24(月) 10:29:33.52

>>152
オブジェクトへの参照が１個、複数の別で、
unique_ptr, shared_ptrを使い分ける。

参照するだけで、所有しないweak_ptrってのもある。

要するにリファレンス・カウント式のメモリ管理なのだ。
Objective-Cの設計をC++が取り入れたのかな？

2017/07/24(月) 10:30:53.63

ちなみに、俺はC++を最近全然使ってない。C++詳しい人、
unique_ptr, shared_ptr, weak_ptr
の解説、よろしこ！

2017/07/24(月) 10:47:25.46

>>154
ただのリファレンスカウント方式ならrustとは違うで。

2017/07/24(月) 10:49:27.16

逆だよ、C++のshared_ptrをObjCのARCに文法糖衣で取り込んだんだよ

>>152
unique_ptrは元々C++ boostのライブラリとして提供してたから出来るでしょ
ObjCもSwiftもそういう機能はライブラリじゃなく文法で取り込みたがるから言語更新待ちになるだけで

2017/07/24(月) 10:49:41.82

リファレンスカウントは全然静的に解決しているメモリ管理機構じゃない。
rustのやり方はコンパイル時に指摘してくれるけど、リファレンスカウントはけっきょく動的に解決するわけだし。
それならとっくにswiftで実現してるし。ARCだろ。

2017/07/24(月) 11:07:27.25

>>157
Boost Software License - Version 1.0 - August 17th, 2003

って事は、Boostの方が歴史が古そうですなぁ。ObjCよりも。
俺、誤解してたわぁ。

2017/07/24(月) 11:11:24.98

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からみたい。

2017/07/24(月) 12:00:46.09

rustのメモリ管理の仕組みを見てきたけどプリプロセッサで何とかなるというものじゃなかったから、
c++ならあると言うものじゃなかった。
言語仕様から改変か必要なものだったよ。

簡単に言えば、メモリの参照は一箇所に制限されて、そこからしかアクセスできないようにする。

たから、もしswiftでrustのメモリ管理機構が導入されたら、
100%既存のコードでは動かないし単純に変換もできない。
ロジックの見直しが必要だからね。

例えば配列にループアクセス中は
配列に対する変更操作はすべてコンパイルエラーになる。とか。

2017/07/24(月) 12:08:11.82

いやownership manifesto読めよお前ら
全部書いてあんのに

2017/07/24(月) 14:33:26.45

>>148
https://github.com/sandym/swiftpp
これじゃねえの？XcodeありきObjective-Cありきだろ？
これじゃねえ、どれやねん？

2017/07/24(月) 15:17:51.01

>>161
「メモリの参照は一箇所」
まあ、そうかもしれんけど、俺の理解では参照カウントを１以上に上げない
様なメモリ管理ポリシーを実践する事で、メモリリークは防げると思う。

それから、Instrumentsとdebuggerを活用するのが吉。
最近気がついたのが、command+IでInstruments leaksを起動して捕捉出来なかったメモリリークが、不思議な事に、break pointで一旦止めてdebuggerからInstruments leaksを起動すると捕捉できるんだよねぇ。

2017/07/24(月) 22:22:24.32

>>151
マジか
俺ずっと「つ」って読んでたわ

2017/07/24(月) 22:26:31.27

=ア【はい】

こういうのも👉に見えてなかったとか…

2017/07/24(月) 22:40:40.19

>>153
つ http://i.imgur.com/PCvtAbc.jpg

2017/07/24(月) 22:52:15.68

ﾉｼ

2017/07/24(月) 23:24:01.06

>>153
手の平。
https://nanapi.com/ja/25657

https://m.chiebukuro.yahoo.co.jp/detail/q1410591729?__ysp=MmNoIOOBpA%3D%3D
[つ]は手を表現しています。

例えば、[（・∀・）つ旦]というAAでしたら
旦はお茶のAAですので、
お茶をハイ、と差し出している様子を表しています。
２ちゃんねるでは省略形をよく用いますので
顔文字が省略されて[つ]のみで使用されます。

>>165
まじっす！

2017/07/25(火) 00:35:48.08

つ⌒□

馬券、車券、くじ券をすてている

2017/07/25(火) 11:28:49.52

>>170

そんな、補足説明が必要なAAなんて、不要だわぁ。

2017/07/25(火) 13:50:52.52

わかんねー奴の方が少数だから

2017/07/25(火) 18:36:52.92

>>135
つまりは皆が出来ないうちに自分だけはSwiftを沢山書けるようになっておけば、Swiftがゴリ押しされたときに先行者利益を得られると思ったけどそうはならなかったから悲しいってことだろ？
別にAppleが推してないなんてことないと思うし、Obj-Cを崇めてる奴なんていないと思うし、Swiftはまだまだバージョンごとに変更がある割には十分普及してると思うけどな

大体Swiftをちょっと書かないと作れないぐらいのレベルだったら大してSwiftの知識もいらないと思うし銭稼ぎできるようなもんでもないと思うんだけどな
はじめにObj-C使わなきゃいけなくなったときに本1,2冊ぐらいしか買ってないし、Swiftに関してはお金まったく書けてないし、金稼ぎできる要素がある気がしない

>>138
C++をブリッジするとなるとC++の複雑な機能全てをブリッジ出来なきゃ有用性が落ちそう
限定された機能で書かれたC++コードだけブリッジしてくれるとかだと結局C++側がそれ以外の機能使ってたらラッパー書かなきゃいけなくなるし、落とし所が難しそう

2017/07/25(火) 21:49:06.28

Swiftの完成度が最初から高ければ状況は違ったかもな
あとむだにWithout Cに走ったのは筋が悪かったと思うわ

2017/07/25(火) 22:11:09.32

C++ブリッジってそれもうwith C++だからな
テンプレート除けばそれなりに出来るだろうけど
テンプレート除いたC++に対応したところでだから何なのって話になるし

2017/07/26(水) 00:11:43.09

Without Cをぶち上げたんだからもうCに関わるなよ
韓国人かよ...

2017/07/26(水) 00:29:39.23

Cライクforもインクリメント、デクリメントもなくす無駄な徹底ぶりだからな

2017/07/26(水) 06:41:21.77

Pythonぽくて好きよ

2017/07/26(水) 12:41:46.12

なんかswiftどんどん構文追加して複雑になってないか？
phpみたい

2017/07/26(水) 12:46:08.87

せめてObjCみたいって言ってくれよ

2017/07/26(水) 12:53:13.70

>>176
マルチプラットフォーム化に加えて
膨大なossがcやc++で書かれてるんだから無視は不可能だ。

2017/07/26(水) 13:24:53.92

Without Cは言語仕様(構文)の話

2017/07/26(水) 16:59:40.71

むしろ、Objective-Cの「インスタンスは母体クラスに［おまえのインスタンスを作れ］命令で作成します」とか
「クラス間の通信はクラス［命令:引数］で明示的に他のクラスに実行させてるとわかります」が好きだったので
そのあたりswiftが「退化」しちゃったのが嫌。

言語仕様とクラス仕様が分離しててクラスライブラリだけ進歩してくとか
ソース内で自他の表記がしっかり別れてて「ここであいつがこれやって次…」
と読めるのが気に入ってたのに
他のグチャグチャモダン言語と同じ言語仕様変更地獄と
ソースになんだかわからない誰かが作った記号が普通に混じりますって
これ、ずっとプログラミング文化の発展阻害してた奴だ…と

2017/07/26(水) 17:12:34.07

>>183
>明示的に他のクラスに実行させてるとわかります

Swiftでは分からんの？

2017/07/26(水) 17:16:43.62

>>184
いやわかるよ

2017/07/26(水) 17:17:39.81

>>183
>ソース内で自他の表記がしっかり別れてて

これ何のことを言ってんの？
自他の区別がつかない言語なんてあんの？
そんな精神病みたいなプログラムあっても実行できなくね

2017/07/26(水) 17:37:22.29

多分全部staticで書いてんだろ
おそらくインスタンスとクラス、動的メッセージと静的メソッドの違いがわかってない

2017/07/26(水) 19:04:57.26

$

↑こいつ

今までの理念をぶちこわすような暴挙
itでもなんでもよかったのになんでこれにした

2017/07/26(水) 19:22:50.49

一方俺は、ObjCの言語仕様にクラス変数が追加されて、既存フレームワークのクラスメソッドがクラス変数に変わって発狂していた

>>188
$0, $1, etc.として複数引数の場合でも引数記述を省略させるためでしょ
シェルスクリプトを書いたことないとなんぞこれってなるが、it0, it1よりはスマートだと思うが

2017/07/26(水) 19:32:05.98

>>181
なので普通に考えるとObjective-C 3.0として改良発展させるのがよかったと思うんだよね...

2017/07/26(水) 19:33:29.48

>>183
禿同すぎる

2017/07/26(水) 19:44:28.65

>>189
いちいち引数に名前つけさせて、
省略できるのはひとつまでって感じで今まできてたじゃん！

ここにきてこれ
itですら多少は意味があるが、$ってなに？
なんで急にドル記号が出てくんの

2017/07/26(水) 20:10:19.84

itの方がマシというのは別に否定しないけど
「今までの理念」というのはSwiftには無くね

2017/07/26(水) 21:11:05.37

俺はitより$nの方がマシだと思うけどね

「名前を省略する」ためのものに「名前をつけた気になる」ために$nをやめてitにするってかなり本末転倒じゃない
どうせ具体的な名前が無いなら、極めて曖昧なitなんて単語じゃなく、どこまでも記号的な$nでいい
敢えて単語にするならanonymousArgumentとかclosureArgumentとかにして、クロージャの名前がない引数であるという意味を表さないと
itなんて、$nと同じぐらい何も意味を表さないのに、無駄に単語の体をしてるだけタチ悪いと思うわ

逆にwillSetの引数名省略時のnewValueみたいに、最低限あらかじめ意味が限定されてるところでは、$nでもitでもなくちゃんと最低限の意味を表す省略形になってる

2017/07/26(水) 22:07:58.73

どーでもいいけどいい加減syntaxのセンスがクソ過ぎやしないか？

2017/07/26(水) 23:04:09.76

シンタックスのセンスなんてどーでもいいし・・・

2017/07/26(水) 23:45:24.29

本音をいうと省略させたくない
書き方増やしてどうする

2017/07/27(木) 00:17:20.77

俺も書き方のバリエーションが増えるのは反対だな。誰が書いても同じ文法で、誰が書いたコードでも誰でもさっと読めるのが理想だったな。

2017/07/27(木) 00:19:52.29

swiftでrxSwiftさわったらすごくRxがわかりやすくなったのは良い思い出。
objcだとわけわかめだった。
構文って結構学習コストに関わるんだなって理解した瞬間でした。

2017/07/27(木) 00:21:32.40

>>198
Haskellが普及しないのは、その理想を追い求めすぎてるからだけどね