Objective-C [ObjC part:8.1]; [転載禁止]©2ch.net

**デフォルトの名無しさん** · 2014/11/01(土) 13:35:17.70

Objective-C（オブジェクティブシー）はプログラミング言語の一種。C言語をベースにSmalltalk型のオブジェクト指向機能を持たせた上位互換言語。
　（Wikipedia：http://ja.wikipedia.org/wiki/Objective-C より）

前スレ
Objective-C [ObjC part:8];
http://peace.2ch.net/test/read.cgi/tech/1356341803/

Objective-C [ObjC part:7];
http://toro.2ch.net/test/read.cgi/tech/1330330906/
Objective-C [ObjC part:6];
http://toro.2ch.net/test/read.cgi/tech/1313891268/
Objective-C [ObjC part:5];
http://hibari.2ch.net/test/read.cgi/tech/1279730299/
Objective-C [ObjC part:4];
http://pc12.2ch.net/test/read.cgi/tech/1239721860/
Objective-C [ObjC part:3];
ttp://pc12.2ch.net/test/read.cgi/tech/1186543111/
Objective-C
ttp://pc11.2ch.net/test/read.cgi/tech/1106983092/
Objective-C
ttp://pc5.2ch.net/tech/kako/990/990574267.html

**デフォルトの名無しさん** · 2017/08/07(月) 17:19:28.82

中身がCの文法で書かれたモジュールを
Cの関数なんかじゃできなかったレベルで
取り回せるのが便利で評価されてる言語に
「そのCじゃない部分が嫌なのよね俺」とか
ここで口を開くレベルにも至ってなくて草ボウボウwww

**デフォルトの名無しさん** · 2017/08/07(月) 20:29:51.10

>>741
既に出来なかったっけ？ドット構文

**デフォルトの名無しさん** · 2017/08/07(月) 20:36:52.55

>>747
それはプロパティ限定。
seterとgetterの糖衣構文に限定してる

**デフォルトの名無しさん** · 2017/08/07(月) 21:11:50.86

>>748
あーそうだねｽﾏｿ

**デフォルトの名無しさん** · 2017/08/07(月) 21:19:43.31

>>741
それ。俺が書いたやつだけどマジで欲しいぞ。
https://github.com/ReactiveCocoa/ReactiveObjC
これとかみてくれればわかると思うけど。
ネストが深くなると凄く書きづらくなるし。Rxの学習をobjCで始めるとマジで辛い。
swiftはopensourceになって提案できるようになってるけど
objcにそういう仕組はないのかね

**デフォルトの名無しさん** · 2017/08/08(火) 00:11:51.35

>>750
たぶんこのスレで[ ]のネストについてなんか言ったところで暖簾に腕押しだと思うけど

**デフォルトの名無しさん** · 2017/08/08(火) 04:37:18.97

>>745
Swiftなんて商用利用に耐えないし他にApple OSで使える言語ないから、10年以上業務で使ってるよ
今更自分で使う分にはさほど問題ないけどだからってObjCは至上の言語！とか言うほど陶酔してないわ

>>750
[ ]のネストの深さに味があっていいんだろ
慣れてくると冗長な命名規則と[ ]ネストの深さで1行あたりの処理がアホほど伸びて、それが美しく感じられるようになるぞ

**デフォルトの名無しさん** · 2017/08/08(火) 09:10:19.12

メッセージ構文だろうがドット構文だろうがネスト数が多いこと自体が鬱陶しいだろ
どっちかっつぅとクラス設計の問題じゃないの

**デフォルトの名無しさん** · 2017/08/08(火) 09:54:27.79

>>753
Rxの概念的な都合によるものだから
どうしてもネストが深くなりがちなんだよね。
そもそもパイプが使えるとデバッグが楽だったりするし

ネスト構造でログを間にはさみたいときとかどうする？
結局ネストを壊して一時変数に途中経過を代入して出力するしかないでしょ？
メソッドチェーンなりパイプ演算子が使えると間に挟むだけになるから凄く
メンテナンス性が高い

**デフォルトの名無しさん** · 2017/08/08(火) 09:55:18.73

>>753
Reactive Functional Programmingは必然的に多重ネストしちゃうが、
鬱陶しいとは、初めての意見だなぁ。

variable.asObserver()
.foo()
.bar()
.baz() {|cell|
// do something
// do something
}

これって、鬱陶しいかなぁ？

**デフォルトの名無しさん** · 2017/08/08(火) 09:55:30.87

>>753
あとドット構文とかパイプ演算子を使うとネストは深くならない。
メソッドチェーンを繋げるとネストが深くなるとは言わないよね

**デフォルトの名無しさん** · 2017/08/08(火) 12:01:58.34

ドットでも[ ]でも大して変わらないって自分は思うってだけ

**デフォルトの名無しさん** · 2017/08/08(火) 12:24:05.02

[[[[variable asObserver] foo] bar] baz:^(id cell) {
// do something
// do something
}];
ふつくしい

**デフォルトの名無しさん** · 2017/08/08(火) 13:23:55.95

>>757
そうとも言えるし、そうとも言えない

リアルに最近、(ちょっと)ん？と思った文w
[self menuItemsForPath:[[[node attributes] getNamedItem:@"representedFile"] value]]
まあ、現在のObjective-Cでも、
[self menuitemsForPath:[node.attributes getNamedItem:@"representedFile"].value];
と書けば、全然w。ドットにしてみて、
self. menuitemsForPath(node.attributes.getNamedItem(@"representedFile").value)
まあ、あんま変わんないかな

そうとも言えないにはイマイチだったか

**デフォルトの名無しさん** · 2017/08/08(火) 13:47:41.40

>>758
同じように改行でもインデントでもなんでもいれれば？

**デフォルトの名無しさん** · 2017/08/08(火) 14:36:01.22

Apple様のXcode自動インデントに任せて baz:^ の:の所に合わせてブロック文の中身はインデントを入るよ？
ブロック処理がコード上のすごい右側に行ってしまって
もうこの美しさと言ったらObjC/Xcode以外では中々に見ることが出来ないレベルだと思ってる

**デフォルトの名無しさん** · 2017/08/08(火) 14:44:47.05

Apple様とか言ってるのはお前がだぞw
有るものを受け入れるに過ぎない＆有るものをいかにどう使うかがお前や俺らのやること。それを使うというのはお前や俺らが自分で決めたことなんだから。それは別にAppleのに限らず

なんか自称開発経験長いようだが、よくそんな自分では解決できない不満満々でやってるなあ。その分他に使えばいいのに。全然長いように見えないな

**デフォルトの名無しさん** · 2017/08/08(火) 15:38:18.31

2個目以降のblocks引数のことだろ
1個目の左側と揃えた方がいいよ

**デフォルトの名無しさん** · 2017/08/08(火) 16:10:59.77

デフォのフォーマットでは、2個目以降のblocksも引数のblock中身はインデントひとじゃね？
いくらあろうが右へ右へとは行かないよな？？

**デフォルトの名無しさん** · 2017/08/08(火) 16:22:42.51

インデントは2個目で止まる
だけどシグネチャがそもそも長いから右に寄りすぎるってのはある
1個目と同じで問題なさそうなのにね
まあ別にいいんだけど気になる点ではあるな

**デフォルトの名無しさん** · 2017/08/08(火) 16:29:39.36

そもそもデフォのフォーマットが気に入らないwから、自動補完後に整形するけど、自動補完中はTab(&click)とReturnで進めばBlockの中身分インデント一つだけのような／だけだけどなあ
2つになる場合がなんかあったかもしれないが補完後に整形するから忘れてるのかもしれないけど

**デフォルトの名無しさん** · 2017/08/09(水) 07:47:44.63

>>759
ドットもよくわからんよね
[ ]はどのオブジェクトに対して何の呼び出しをかけているかが明確にわかりやすくて個人的にはいいと思うんだけどな

**デフォルトの名無しさん** · 2017/08/09(水) 11:34:46.72

提供された言語仕様をあるがままに受け入れられないヤツはObjCを使うな

**デフォルトの名無しさん** · 2017/08/09(水) 12:55:35.37

「俺の馴染みのない表記が混ざってるのがキモチワルイ」言われても
評価してる側は「外への働きかけが表記分けで一目瞭然なのがイイネ」だから
話が平行線というか、
むしろ、最近の言語が(swiftみたいに)すぐにどのレベルの処理も
フラットにベターッと書くのを指向していて
それよく知られてるいつもの【ダメなやつ】なのになんで
あれやりたがる開発者多いのか…

**デフォルトの名無しさん** · 2017/08/09(水) 13:23:22.09

Obj-Cのラインは行頭に@という手もあるぞ

**デフォルトの名無しさん** · 2017/08/09(水) 13:28:37.05

[] はコストが関数呼び出しより高いことを明示してる感じでとても良いと思う。

**デフォルトの名無しさん** · 2017/08/09(水) 14:34:41.41

プロパティとかいうドット表記が問題なんだよな, 挙句にgetter/setterのメソッドに紐づいてるし
あれをObjCに取り込んだ害悪は誰だったんだろうね

**デフォルトの名無しさん** · 2017/08/09(水) 14:53:43.66

>>772
変な日本語！
プロパティアクセスに限って、ドット表記ができるってのは、
Objective-Cらしくて良いんじゃ無い。

**デフォルトの名無しさん** · 2017/08/09(水) 15:10:08.58

230デフォルトの名無しさん (ﾜｯﾁｮｲ 056c-cJAr)2017/08/09(水) 14:56:18.93ID:ocU/hJiZ0
>>229
Objective-Cでもジェネリクス可能なのか？

どのレベルまでできる？
1. 型汎用な関数
2. 型汎用なクラス
3. 型汎用なプロトコル
4. 型汎用なプロトコル・エクステンション

SwiftスレでObjCについて聞く前にググれ
https://developer.apple.com/library/content/documentation/Swift/Conceptual/BuildingCocoaApps/InteractingWithObjective-CAPIs.html#//apple_ref/doc/uid/TP40014216-CH4-ID173

**デフォルトの名無しさん** · 2017/08/09(水) 15:10:17.60

プロパティじゃなくてもシグネチャ次第でドットにできるけどね

**デフォルトの名無しさん** · 2017/08/09(水) 15:15:27.76

あゲッターだけか

**デフォルトの名無しさん** · 2017/08/09(水) 15:47:05.07

>>774
Lightweight Generics
って書いてあるね。
Swiftから呼べるObjective-Cコードは軽量版ジェネリクスってことか？

軽量版ジェネリクスかぁ。。。なんかグッと来る日本語無いかな？
Matzだって名前重要って言ってるし。

**デフォルトの名無しさん** · 2017/08/09(水) 18:10:30.11

>>772
確かそもそもは、Cocoa Binding
Cocoa Binding(内で使う／に指定する)でメンバ(のメンバ？) の表記がドット。Cocoa Bindingとして対象は当然「プロパティ」という概念／名称になろう
この時点ではObjective-Cには property なんてなく、当然ドットもない。Cocoa Bindingがプロパティとして呼び出すのは単にセッター/ゲッター。セッター/ゲッターを量産する手段をObjective-Cには同時期かまたはちょっと後(それまでは、全部手でセッター/ゲッターを書く)

その後いろいろあって、今のに

なので、よくわからんが今やり始めてそう思うのは仕方がないのかもしれないが、無茶苦茶言ってるなてとこかなw

**デフォルトの名無しさん** · 2017/08/09(水) 18:46:53.08

>>769
その【ダメなやつ】を最近もクラスプロパティの言語仕様追加で従来[ ]で呼び出してたものを.で呼び出すように推進してるからなぁ
言語仕様変えただけじゃなくご丁寧にCocoa, UIKitのフレームワークライブラリの実装まで修正してくれてるし

昔は【ダメなやつ】だったのかもしれんが、今は【イイやつ】になってると思うべきなんじゃねw
ObjCの言語仕様が追加されるのはいつものことだし、変わったものをモダンで良いものと思って追い続けないとやってけないよ

**デフォルトの名無しさん** · 2017/08/09(水) 18:55:51.12

>>777
なんか誤解してそうだけどObjC単体でも使えるからな
ListやDictionaryなんかの一部コレクション系クラスの保持オブジェクトの型をコンパイル時チェックできるようになった
Java5の頃のジェネリクスと同じ感じだな, C++のTemplateみたいな使い方はできないがまぁ仕方あるまい

軽量"版"というからしょぼく見えるんだから軽量ジェネリクスでいいじゃん
コンパイル時間は多少伸びてるだろうが、実行時オーバーヘッドは０のはずだからな

**デフォルトの名無しさん** · 2017/08/09(水) 19:35:58.41

>>778
まあドット表記自体は構造体のメンバアクセスとしてC(=Objective-C)に備わってるけどな
それをオブジェクトに対してあえて適用しなかったのがObjective-C

**デフォルトの名無しさん** · 2017/08/09(水) 20:09:54.22

>>781
正確にはC(∈Objective-C)だけどな
まああえて＝って書いたのかもしれんが

**デフォルトの名無しさん** · 2017/08/09(水) 20:20:14.93

>>781
あえてというか、必要性が無かったからだろう
Cocoa BindingでGetter/Setterをたくさん用意しなくてはならない／するのを強制されるのは確か。そういえばGetter/Setterの命名規則もこれのせいだったような(それ以前にあったかもしれないが「でなければならない」ではなかった)

オブジェクトに対しては、
ClassA *obj = …
(*obj).instaceVariable = …;
として、(たぶん)最初からあるけどなww(Cの構造体メンバアクセスとは確か「ちょっと」違う)

最初は構造体のと同じ表記なのに単なるメソッド呼び出しの置き換えとかキモかったなw

**デフォルトの名無しさん** · 2017/08/09(水) 20:31:19.14

>>783
>それ以前にあったかもしれないが「でなければならない」ではなかった
ちょっと違うな
それ以前にあったかもしれないがルールが明文化された
かな。ルールに基づかないのにもなのがsetter=/getter=の存在でもあるし

**デフォルトの名無しさん** · 2017/08/09(水) 20:49:27.68

>>783
obj->instaceVariable = …;
とするとどこぞの言語っぽくもなるなｗ

**デフォルトの名無しさん** · 2017/08/09(水) 20:57:44.83

> オブジェクトに対しては、
> ClassA *obj = …
> (*obj).instaceVariable = …;
> として、(たぶん)最初からあるけどなww

最初からはねーよwww
ギリギリ->オペレータがあったくらいだわ
まぁその当時はC/C++を継承した->は【ダメなやつ】で[ ]のみが正義だったわけだが

**デフォルトの名無しさん** · 2017/08/09(水) 20:59:19.88

>>785
それは「たぶん」でなくて「確かに」だろう
そっちの書き方が普通で>>783の書き方する方はちょっと捻くれ者かなww

NSCopying実装するのに普通にそれをだったが、今時はsetter/getterやpropertyのがかな？まあ、setter/getterやpropertyを用意するまでもないインスタンス変数なんて普通にあるから、今でもだろうけど

**デフォルトの名無しさん** · 2017/08/09(水) 21:01:34.46

>>786
なるほど。使おうとしたことあるのか？w
なんか下みたらそんな気配は無さそうだが、まあ、俺は試したことは無いので、いう通りなんだろう。どうも

**デフォルトの名無しさん** · 2017/08/09(水) 21:03:58.20

(*obj).foo も obj->foo も@publicじゃなきゃならんな
Cの構造体の構文に似せてあるが、シュガーだよ

**デフォルトの名無しさん** · 2017/08/09(水) 21:15:38.13

>>789
うん。まあ、単なる目に見えるメソッド置き換えよりも、なんか気分的な親和性があったというか

NSObjectの構造を見るとアクセスするのに単純にいかなさそうなんだけど、今はなんか簡単にやってやがるっぽくない？よく調べてないがコンパイルで吐くコードがなんか単純(以前のでの吐くコードがどんなんか知らんけど)
struct objc_class が OBJC2_UNAVAILABLE だから、Objective-C 2.0 で何か思いきったことやってんのかなあ？

**デフォルトの名無しさん** · 2017/08/09(水) 21:51:51.46

>>786
稼働可能状態な古いMac持ってる知り合いに聞いて試してもらったら、10.4では (*).　はコンパイル＆ランで問題ないって
10.0 から 10.3 の間かなあ？そんな別に無くてもいいもんwいつサポートするようになったか興味がちょっとあるなw(いつの話か教えてくれたら嬉しいな)

**デフォルトの名無しさん** · 2017/08/12(土) 07:30:10.75

objective-c property のアクセス制限で相談です。
外部へはreadonlyプロパティとして公開し、内部向けにclass extentionにてreadwriteプロパティとして再定義したクラスがあります。

これを、swiftで使おうとしたところ、generated headerの中にこのプロパティ定義が作られない事に気付きました。(xcode 8.3.3)
多重定義を止めると、普通にプロパティ定義が作られます。

多重定義プロパティでのgenerated header不具合っぽいのですが、良い対処方法を教えてください。

思いつくのは
・Immutable classのサブクラスとしてmutable classを作り、そこでプロパティを再定義
・readwriteのpropertyを別名でclass extentionで定義しインスタンス変数を共有、内部からはwrなプロパティを使う
くらいです。

**デフォルトの名無しさん** · 2017/08/12(土) 12:13:53.23

こういうこと？

Hello.h
--
@interface Hello : NSObject
@property (readonly) int i;
@end

Hello+ReadWrite.h
--
#import "Hello.h"
@interface Hello()
@property (readwrite) int i;
@end

ObjCでもSwiftでもHello+ReadWrite.hをimportしてればrwプロパティとしてアクセスできてる(Xcode8.3.3/High Sierra)
Hello.hをimportしてrwプロパティを持つgenerated headerにならないのは不具合ではなく仕様通りではないかと

**デフォルトの名無しさん** · 2017/08/12(土) 12:32:23.62

いえ、公開したいのは、readonlyなプロパティなので、上記例で言えばHello.hの方です。

その場合、プロパティ自体が存在しない空のgenerated headerになってしまいました。

Foobar.h
@interface Foobar: NSObject
@property (readonly) uint32_t count
@end
Foobar+internal.h
@interface Foobar ()
@property (readwrite) uint32_t count
@end
Foobar.m
#import "Foobar.h"
@implementation Foobar
@end

**デフォルトの名無しさん** · 2017/08/12(土) 13:46:56.49

同一プロジェクト内で双方向のpublic getter, private setterはこんな感じでいけた
ttps://pastebin.com/2ckH2LeE

ライブラリプロジェクトでプロジェクトを跨る時はObjC側はBuild Phrases -> HeadersでHello.hをpublic設定して
Swift側は@objc public class HelloSwiftで宣言するんだったかな, @objc publicは最新で不要になってる気もする
多分、ライブラリプロジェクトについて話してるんではないだろうから、ここは意識する必要ないだろうけど
プリミティブ型じゃない時に何か特殊な障害があったかな・・・

**デフォルトの名無しさん** · 2017/08/12(土) 14:18:44.04

372仕様書無しさん2017/08/11(金) 10:31:43.41
フリーランスで検索すると引っかかる零細ITがやっているフリーランスのサイトはだめだ。
高額に見せているけど実際は50万前後
JIET加入した方がいいよ。案件は毎日千件以上末端価格は60万円　平凡な稼働時間の80万円の案件もある。
ユー子も求人をだしてる。名刺も渡せる。ユー子に名刺が渡せるんだぞ。夢のようだ

それらの案件まさぐってHPで転売していたのが零細ITがやるフリーランスサイト

473非決定性名無しさん2017/08/03(木) 15:21:30.71

JIETに加入すれば誰でも3次60万からスタートだ。フリーランスのサイトをやってる
自称エージェントもそこから案件情報を取得しきてる。サイトで60万で釣って40万から55万の
間でやらしている。

446非決定性名無しさん2017/08/02(水) 22:12:48.95

JIETに毎月5千円払えば３次から入場できるだろ？
高額をうたうフリーランスのサイトはだいたい５次から４５万円
JIETで閲覧応募できる末端価格からさらに搾取するのが高額をみせつけるフリーランスサイトでした
高額案件をみせつけるフリーランスサイトも案件の取得はJIETでした

自称エージェントはJIETから流れてくる案件を転売してるだけだった。
JIETに加入すれば誰でも案件に応募することができた。収入が40万50万台にならなくて済む

**デフォルトの名無しさん** · 2017/08/12(土) 15:21:17.11

その方法でまんま何も問題ないけど？
Swift側で、入力補完でプロパティ出てくるし、参照に問題なく代入で
cannot assign to property: 'count' is a get-only property
ってエラー出るし

generated headerってなんじゃらほいだが。SwiftでFoobar.countの定義参照(Command+Click)してもFoobar.hのそれまんまがだし
Swift -> Objective-C が Generated Header(SwiftソースからObjective-Cのヘッダーをじぇねれーと)じゃないのかな？？Objective-C -> Swift はBridge Header (なにかしているんだろうが、単なる参照用)

**デフォルトの名無しさん** · 2017/08/12(土) 15:26:34.38

>>797は>>794宛て

>>795
すでにレスってたのね、失礼。ほぼ、同じどす

**デフォルトの名無しさん** · 2017/08/12(土) 15:37:26.13

>>795,797
コメントありがとうございます。指摘通り、Generated interfaceの誤りですね。

今手元でこんな感じです。
ttp://i.imgur.com/D8CWZTP.jpg

上がCocoaアプリ、下がFrameworkに置いたものです。
いずれも、Generated I/Fの中に上書きしたプロパティが出てきません。

Xcode再インストールが先でしょうか？

**デフォルトの名無しさん** · 2017/08/12(土) 15:52:20.34

>>799
絵が見えないー。何をやってるのか見えなーい

んー… Swiftで作ったクラスをObjective-CでがGenerateだと思うんだがな。HeaderとInterfaceの違いではなく…まあ、どうでもいいけど、Objective-Cで作ったクラスをSwiftででいいのね？

何やってるのか見えないのでなんともだが、とりあえず Product メニューの Clean(よりも、Option押しながらのClean Build Folder…)かな

**デフォルトの名無しさん** · 2017/08/12(土) 15:57:11.27

ttp://light.dotup.org/uploda/light.dotup.org471442.png.html
すみません貼り直します。

Obj-c => Swift が目標です。

**デフォルトの名無しさん** · 2017/08/12(土) 16:09:41.21

>>801
ん？？右端の Hello.h が generated header/Generated interface とやら？んなのいらんだろ？？
単に、Bridge Header に、その左隣の Objective-C 用の Hello.c をインポートすればいいだけだろ？？>>795さんのでいえば30から31行目、Hello-Bridging-Header.hというファイルに#import "Hello.h"を一行

Bridge Headerを使うようには設定でだが、Objective-Cのプロジェクトで最初にSwiftファイル作れば、「Bridge Headerつくるよ」とXcodeが勝手にやってくれるし、その後設定を確認してみればBridge Headerを使う設定がわかるだろう

**デフォルトの名無しさん** · 2017/08/12(土) 16:13:00.14

>>802
>勝手にやってくれる
Bridge Headerファイルの作成と、プロジェクトへのBridge Headerファイル登録と、ビルド設定ね
Swiftで使うクラスは、Bridge Headerに自分で記述する(単に#import "….h")

**デフォルトの名無しさん** · 2017/08/12(土) 16:22:45.31

>>802
すまん。ちょこちょこ間違えた
>その左隣の Objective-C 用の Hello.c
その左隣の Objective-C 用の Hello.h
>でいえば30から31行目
でいえば30から32行目

**デフォルトの名無しさん** · 2017/08/12(土) 20:56:39.29

>>801
そういえば、(標準の)Frameworkは？ってのは、umbrella headerってのをFrameworkに仕込むらしい
それも、ヘッダーはそんなSwiftみたいなのではなく、単にObjective-Cのヘッダー(をSwift用にプリコンパイル(？)してモジュール化しての)
すると、Swiftで
import Foobar
ってだけで

**デフォルトの名無しさん** · 2017/08/12(土) 21:33:48.50

>>805
ああ、umbrella headerって、Objective-Cでも／でのModulesのためのか。@importの。@importなんて忘れてたw
それの使用／流用か？@importはSwiftより1年先みたいだし

**デフォルトの名無しさん** · 2017/08/12(土) 21:37:17.32

流用っていうかLLVMの機能

**デフォルトの名無しさん** · 2017/08/13(日) 11:30:09.68

解決できてなさそうだから一式上げた
ttps://www.dropbox.com/s/dycv00sv7gc9c9a/Hello.zip?dl=0

Swift PJをベースに作ったけど、ObjC PJベースで作っても同じ感じ
Hello-Bridging-Header.h を適切に作成、参照させてないのが原因とエスパーしとく
参照設定はXcodeで Hello -> Build Settings -> Swift Compiler - General -> Objective-C Bridging Header の所な

**デフォルトの名無しさん** · 2017/08/13(日) 14:47:06.11

アンブレラヘッダって、Cでよくやる各モジュールのヘッダをincludeしてまとめてあるヘッダのこと

**デフォルトの名無しさん** · 2017/08/13(日) 16:13:58.67

iOSでアンブレラヘッダって出来るんだっけ

**デフォルトの名無しさん** · 2017/08/13(日) 16:17:13.40

できるよ
.h作って必要なヘッダを#import

**デフォルトの名無しさん** · 2017/08/13(日) 16:32:48.83

Accelerate.frameworkを見ると出来るみたいね
>>811
サンクス

**デフォルトの名無しさん** · 2017/08/13(日) 17:27:14.87

>>811
ごめん、アンブレラヘッダとアンブレラフレームワークと混同してた。frameworkも出来るみたい。

**デフォルトの名無しさん** · 2017/08/13(日) 19:08:50.09

皆さんありがとうございます。

どうにもドツボにはまっているので、頂いたものを勉強し直します。

**デフォルトの名無しさん** · 2017/08/30(水) 09:43:22.83

Xcodeのメジャーバージョンアップに合わせた言語仕様更新
ここ２年くらいないけどもうObjCの改善はやめたのかな

**デフォルトの名無しさん** · 2017/08/30(水) 14:31:13.31

Xcode 8からクラスプロパティが入った。
Xcode 9はわからん。

仕様変更は正直いらないよ。新機能の追加だけで十分。
最近のObjective-Cの良いところは仕様変更が少ないことだと思う。
Swiftは変更しすぎでついていけない。

**デフォルトの名無しさん** · 2017/08/30(水) 16:55:31.83

そうか、クラスプロパティが去年だったか, 地味だから忘れてた
Xcode9は今出てるリリースノートの範疇を見るになさそうなんだよねぇ

最近のObjC下位互換破棄はGCの完全撤廃がXcode8であったような？誰も使ってないだろうけども
ObjCはシンタックスシュガー多いけど基本は残していくスタンスよな

**デフォルトの名無しさん** · 2017/08/30(水) 18:53:05.49

>>816
ころころ仕様が変わったら何のデバッグしてるのかわからんからね

**デフォルトの名無しさん** · 2017/08/31(木) 12:33:49.66

Xcode9では言語仕様追加はないのか
毎年何らか追加してきてたし、ネタ切れってわけでもないだろうに、Swiftにリソース食われてるのかねぇ

Swiftはコミュニティにぶん投げて、AppleはObjCの言語仕様をアップデートしてくれよなぁ

**デフォルトの名無しさん** · 2017/08/31(木) 16:41:09.38

nullability にしろ generics にしろ、最近の変更は swift から obj-c を使いやすくするのに必要なものだったから、もうやることはあまり残ってなさそう

**デフォルトの名無しさん** · 2017/09/01(金) 09:02:41.01

autoキーワードのデフォルト有効化はよ
ObjC++(.mm)にすれば良いんだけどなんか違う、idをautoの代わりに使うのはもっと違う

**デフォルトの名無しさん** · 2017/09/01(金) 10:47:18.17

C++17も出るし、C++14, 17の新規機能のポーティングが始まるんじゃね？今年はもう間に合わんだろうけど
clangとしてC++17は進めてるんだろうから、いつものように文法糖衣してObjCに突っ込むだろ

**デフォルトの名無しさん** · 2017/09/01(金) 11:18:48.86

いっそのことObjective-C++使おうかな。
C++の仕様を部分的にポーティングしてくれるならそれもいいけど。
@autoみたいな記法は流石に勘弁だけど。

**デフォルトの名無しさん** · 2017/09/01(金) 12:05:12.13

ObjC++はコンパイル遅い。

**デフォルトの名無しさん** · 2017/09/01(金) 17:48:15.95

ObjC++だとリファクタリング効かないから大変。
あれ何とかならないかなぁ。

**デフォルトの名無しさん** · 2017/09/01(金) 18:21:04.93

C++はコンパイル速度より実行時速度に重きを置いてるから仕方ないね

ObjC++でTemplateが使えたら幸せなんだけどなぁ
常時Dynamic Dispatchで実行速度が遅いObjC環境でTemplate使った速度改善なんて滑稽な話ではあるが

**デフォルトの名無しさん** · 2017/09/01(金) 22:21:55.44

>実行速度が遅い
それが問題になるほどの崇高なプログラムを組んでらっしゃるのかな

**デフォルトの名無しさん** · 2017/09/01(金) 22:30:27.59

そういう人はいくらでもいるでしょ

**デフォルトの名無しさん** · 2017/09/01(金) 22:34:33.64

計算物理学とか処理速度は常に足を引っ張ってくるからね

**デフォルトの名無しさん** · 2017/09/01(金) 22:44:52.87

ObjC++ってC++で書かれたコア部分をラッピングするための装置。

**デフォルトの名無しさん** · 2017/09/01(金) 23:03:50.42

> ObjC++はコンパイル遅い。
これが問題になる人よりは多いでしょ, コンパイル速度より実行速度を気するわな

ObjC++はC++の機能を使うための装置でもあるがな
auto以外にもモダンな機能が使えるからModern Objective-Cがモダンじゃないと感じ始めたら使うのも一興
性能良くてモダンな機能が使えるObjC++はイイゾー

**デフォルトの名無しさん** · 2017/09/01(金) 23:45:22.97

コンパイル遅くなるって具体的にどんなケースなの？
既存のobjcソースをobjc++としてコンパイルする程度ならほとんど変わらなそうだけど。
autoやメンバー関数なんかの簡単な機能使う程度なら十分お釣りが来る気がする。

**デフォルトの名無しさん** · 2017/09/02(土) 10:48:43.59

モダン、モダンうるせーよｗ
モダンであることが目的になってねーか？おまえら

**デフォルトの名無しさん** · 2017/09/02(土) 12:06:13.00

ものによっちゃあクラシックよりは良いだろうな

**デフォルトの名無しさん** · 2017/09/02(土) 18:57:24.45

>>832
- (instancetype) init {
self = [super init];
// メソッドcountがNSIntegerを返すと誤認して利用
// NSInteger a = [self count]; // 型推論なし:ここでビルドエラー
auto a = [self count];
/* 100行くらいの処理 */
a = a + 1; // 型推論あり:ここでビルドエラー
return self;
}
- (NSNumber *) count {
return @0;
}
こんな感じのマヌケなコード書いてると
100行くらいの無駄なコンパイル処理を経てようやくビルドエラーが出るので
autoキーワード(型推論)を使うObjC++はビルド時間が遅い
・・・という型推論否定論があるんだろうと最近は思うようにしてる

なお、auto a = [self count];とNSNumber *a = [self count];だけを比較したら
型推論使った方が両辺の型一致を判定する必要ない分だけ早くなり得ると思う

**デフォルトの名無しさん** · 2017/09/02(土) 19:14:40.76

マヌケっぽいけどイ㌔

**デフォルトの名無しさん** · 2017/09/02(土) 20:19:08.25

C++の型推論は戻り値型が確定していればその場でNSNumber *に置き換えてくれるんじゃね？

よほど変なコード書かない限りコンパイル速度が問題になることは無いだろう。
Xcodeはデフォルトでプリコンパイルしてくれるし、C++でもやってくれるでしょ。

**デフォルトの名無しさん** · 2017/09/02(土) 20:20:06.63

型推論にかぎらず

**デフォルトの名無しさん** · 2017/09/04(月) 00:53:58.51

ObjC++がコンパイル遅いって具体例、他にないのかね
一例は捻り出してみたけど、遅いと主張してる人たちからは何も出てこない...

**デフォルトの名無しさん** · 2017/09/04(月) 01:11:16.27

遅さが実感できないならそれで良いんじゃね

**デフォルトの名無しさん** · 2017/09/05(火) 06:26:53.84

>>824はObjC信者の妄言ではないと実証しないとダメじゃない？

**デフォルトの名無しさん** · 2017/09/05(火) 13:34:45.75

真の信者はObjC++も受け入れる。

実際ObjC++はそれほど遅くはないよ。
今はClangコンパイラがデフォルトになってるからかなり早い。
むしろSwiftのほうが遅く感じる。

**デフォルトの名無しさん** · 2017/09/05(火) 22:19:53.34

今は亡き真のApple信者はObjCは素晴らしい、Swiftも素晴らしい
Appleの提供するものは全て素晴らしいってSwiftスレで孤軍奮闘してたよ(Swift1.xの時代
Swiftはcopying swift libraryにクッソ時間かかるから論外だと思う, 10Mbyteの小さな()ランタイムのコピーは失笑しか出ない

それはそれとして、いい加減ObjCのみが素晴らしいって主張のObjC信者はObjC++が遅いって実証を出せゴルァ
ObjC++を許容する真の信者(笑)の根拠のない感想なんてどうでもいいんだよ

**デフォルトの名無しさん** · 2017/09/05(火) 23:15:55.98

信者信者ってわざと言ってるのにはもう見えないな。マジで言ってるのならキチだな

**デフォルトの名無しさん** · 2017/09/06(水) 17:08:25.60

>>843はどう見ても基地外だろう。

**デフォルトの名無しさん** · 2017/09/07(木) 08:58:40.01

触ると増える