Swift part11 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>ただし、Swiftは「クズ」だと思っている人は今でもいる
ひどい言われようだな。
「Android」アプリ開発言語に加わった「Kotlin」--開発者が寄せる期待
https://japan.techrepublic.com/article/35103377.htm 瑕疵担保責任(かしたんぽせきにん)
納品されたシステム、プログラムに不具合があった場合、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年目以降は不具合の修正に対応しない」と主張するベンダーはまれだ。多くの場合は、納品から何年たっても、
バグが見つかればユーザーのところに飛んで行き、無償で改修するだろう。
重大な脆弱性が現バージョンから発見されました。こちらでアップデートしたところ、起動ができなくなりました。
至急弊社に来て修正作業をお願いします。なおお金は払わない。また営業に損失が出たので損害請求もする。 kotolinは劣化Swiftだけど、進化Javaではあるからな >>5
Kolin nativeってのもあるし、Swift -> Kotlinへの移行しても良いかも。
Androidアプリ作って見たいし、だからと言ってJavaは嫌いだし。 >>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 ) //実行時エラー やっぱりJavaVMで動くKotlinは最強やな
>>6
実用に至ってから出直せw >>7
lazy使って、実行時エラー回避できるんじゃなかったっけ? >>9
既に let a = ….lazy でaはLazySequenceになっている
しかしオーバロードと型推論の設計上の問題により
LazySequence.filterでなくSequence.filterが呼ばれるため
prefixより前に無限シーケンスを全て処理しようとして死ぬ WWDCのSwiftのハイライト教えてください。どの辺がパワーアップした? SwiftとXcode学ぼうとおもってるんだけど、オヌヌメの本ある? >>13
型推論ちゃんがドジらないようメソッドチェーンせず一つずつやらせる
do {
let a2 = a.map{$0*10}
let a3 = a2.filter{50<$0}
print( a3.prefix(5).array )
} >>14
あんたのbackground次第だな。
萩原本は、万人向けだが。 >>16
確かに4だと直ってるな
issues見たけどオーバーロードやlazy等に関する直接的な対応は見付けられなかった
オーバーロード解決に後続のチェーン使う地雷が修正されてるなら有り難いけど >>15
ありがとう
いつか嵌ったときに思い出すよ ワンライナーに至上の価値を置いてるやつは初心者
複数言語、プラットフォームにまたぐ開発をやったことなく
狭い世界で安全なコード規約に保護されてないと開発できない箱入り息子ども
その狭い価値観でプログラミング言語を語り出すと>>7のような間抜けなことを言い出す
SwiftがあるのにピザってるJVMで動作するkotlinを選ぶやつは初心者も初心者 ていうかKotlinなんか眼中になくてCrystallangやElixirがめっちゃ気になってるんだがね
やつらベンチだとSwiftより速いらしいやん
どんなマジック使ってるんだ 他言語を専スレで話題にしようとする初心者
加えて、VM言語が下手なネイティブより高速になることがある背景を知らない初心者
Swiftは特定条件下ではobjcより早いけど、一般的には別段速くないって昔から言われてるから "ワンライナー"と呼んでいるやつは初心者
ちなみに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 Cベースじゃないモダンスタイル言語にsmalltalk思想かと思ったら
objective-Cとまったく関係ない実験作が出てきたからなぁ…
あきらかにAppleWatchともどもジョブズが
「これじゃまだダメだろ」って止めてたのが
お漏らしして表に出てきちゃった感 >>26
Swift -> ObjCへ移行中。Swiftだけしか知らない事に、危機感。
ObjCコンパイル早いし。 mac板での自爆ギャグが悔しかったのか必死だなw
こっちの板はアンチスレもあるし老害orガイジでないならそっち行くといいよ 他スレにも出向いてObj-C=老害を吹聴してSwiftを布教して回ってんのかよ...
82 1 名前:名称未設定 (ササクッテロリ Sp71-yTFi) Mail:sage 投稿日:2017/07/03(月) 20:24:07.40 ID:ipKiHhaqp
これは老害ですわ
なんでこんな古いObjCの記述をするんだよw
Modern Objective-Cを学び直すか、ObjCを捨ててSwiftを学ぶべきだな >>26
何歳から老害なんですか?
あなたはいつから老害になるんですか?
それとも、歳くってもModernな言語をさわって布教してれば老害にはならないのですか? いや、そこSwiftスレじゃん
そしてあまりにも酷いObjCコードをスレチで書いた老害が悪いわw
業務ではObjCしか使わないしSwiftが良い言語と思っちゃいないが、専スレでアンチは勘弁な >>33
もう一度おききしますね
何歳から老害なんですか?
あなたはいつから老害になる予定ですか?
それとも、歳くってもModernな言語をさわって布教してれば老害にはならないのですか? ObjCでいいはないだろ...
何たってサーバーサイドも書けるんだぜ?
何もせんでもキャリアが伸びるこんなおいしい話はない
来年あたりSwiftのサーバーサイドでの積極採用の会社も出てくると予想してる >>34
Modern Objective-Cが書けるなら老人であっても老害じゃないんじゃないの
あとSwiftスレでObjCで荒らしてるのはガイジかな:) >>36
さすがにそこまではないと思う
サーバーサイドに使われるようになるには
ライブラリやフレームワークの充実度が重要
すでに他言語が相当前にいるので追いつくまでそうとうかかる >>36
サーバーサイドは実験レベルで書けるけど実務レベルでは無理だろ
まだまだ時間が必要だと思う >>34
老害=年齢で決まると思ってる時点でお前はただのアホやで ObjC専用スレ覗いて見た。最後のレスが今年の2月だった。
ObjCをちょっと触ってるけど、良い感じだわぁ。
ちょいと、メソッド名が冗長な感じはするけど、スルスルとコンパイルされるのが良い。
コンパイルエラーが不親切って感じはするけど。
その点、Swiftコンパイラは親切but時間かかる。 差分ビルドなら結局ObjCもSwiftも大して差を感じたことがないが
Swiftのビルド遅い遅い言ってるのは常にクリーンビルドでもやってんのかな
それかMacbook or Airだと体感差が出るとか?Proだと差が感じられない まーSPMの構成変えた後一からビルドすることになる時は俺もイラッ☆とするけどな >>45
SSDだとSwiftが遅いって思ったこと無いけど、HDDだとめちゃくちゃ遅く感じる、というかやってられない ビルドの速さを語るときはせめての目安としてコンパイルするファイル数も言わないと意味がないかと Copying swift library ... が怒り通り越して笑いが出る
SSDでも普通に体感差があるけどないの? AppleがCoffeeタイムを提供してくれているのさ
と信者ならポジティブに解釈できることだろう Swiftのビルドは遅いと思わないな。
遅いと言ってる人は多分StoryBoard使ってたり、変数の宣言時に型指定してないんだろうな。 型推論全否定すんな
だいたいC#はvarでも速いぞ ふーんHDDだとそんなに遅いんだ
Pro Retina SSDがSwiftやる上での下限スペックってことかな
13inch 128GBは罠だが・・・ ARCって循環参照したらメモリリークすんでしょ?
だからってweakとかunownedにしたら間違って解放後にアクセスしちゃうかもしれないし
マジ使えねー >>44
Objective-Cはキモいくらいにコンパイル速いよな。
なんかSwiftよりも楽しそうな感じするな。 >>55
自分でメモリ管理したら循環参照しないってこと?
どっちもどっちだろ
あんまり関係ないと思うけど たぶんガーベージコレクションなら背後でCPUパワーを食い続けて全部監視してくれる!と言いたいのでは 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>!' >>59
すみません。エラーが出ている箇所はSendUDP(char* str, int strsize)を呼び出した部分でエラーが出ています。
その他の場所は特に問題ないみたいです GCと比較してたのか…
それなりのコストかかるから単純に比較できんけどなぁ >>59
何が原因って、エラー内容のままじゃん…
英語読めないならぐくるとかしてみなよ 最近書き始めたけど、これ凄いな
簡単にアプリ作れて驚いた、凄い書きやすいわ
ただ基本的な文法をもっと勉強したいんだけど、良い参考書って何かないですかね
アプリ入門系の本だと、アプリで使うメソッドしか解説がないのでもっと基本的な所から勉強したい 言語仕様として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みたいに極限までに研ぎ澄まされたシンプルさと美を兼ね備えた言語で開発したい ■ このスレッドは過去ログ倉庫に格納されています