アカウント名:
パスワード:
……既存のソフトウェア資産どーすんだよ
iOS の元となった OS である Mac OS X でいえば、そもそも少し前のだって、x86 と PowerPC の混成バイナリだったし、今は 32bit と 64bit の2種類のバイナリがワンパッケージ化されていたりしますので。そういうユニバーサルなのは Apple の十八番です。
無論、ユニバーサルでないバイナリそのものを動かそうとしたらエミュがいるけど。そんな環境を用意しなくても、普通はあっという間に対応ソフトがそろう。
なぜならば、ほとんど、開発環境だけで吸収できる。ぶっちゃけビルドし直すだけなので。
一瞬でアプリ側で新しいCPUに対応できます。そして、Atom と ARM の両方に対応したパッケージとしてアプリをリリースできる。
全くなんの問題もなく、過去の資産を使えますよ。そういう事態が起きても心配無用。
全くなんの問題もなく、過去の資産を使えますよ。
ビルドが通れば問題なくアプリは動作すると思ってる方? おめでたいですね。
もしビルドが通ったのにもかかわらず動かないんだったら、それは XCODEがまともなバイナリを吐いて無いってことだ。もしくは元々バグってたかのどっちかだ。バグがあったのならちょうどいい機会だから直せば良い。
アセンブラでも使って無い限りCPUの違いなんざ微々たるもんだ。そのためのライブラリやAPIだろ。
XCODEがまともなバイナリを吐いて無い場合はどうすんですか? それ以前の話として、ビルドが通ったアプリの動作確認もせずに動くか動かないか判るんですか?
アセンブラでも使って無い限りCPUの違いなんざ微々たるもんだ。
コンパイラの、ARMかx86用にコード吐く部分て結構違うと思いますが。
もしXCODEのx86コードが使い物にならない代物なら、すでにおおさわぎになってるはずだよね。
もしXCODEのx86コードが使い物にならない代物なら、
誰かそんなこと言ってますか?
親コメントで言ってるよね
XCODEがまともなバイナリを吐いて無い場合はどうすんですか?
特定のソースの書き方や最適化の設定なんかでコンパイラがおかしなコード吐くのってそんな珍しいもんでないし、ソース書き換えたりコンパイルオプション変えて回避するなんてのは常套手段でしょ。そんな程度のことでコンパイラのことを「使い物にならない代物」とはそうそう言わないと思いますが。
「特定のソースの書き方」といえばごまかせると思ってるようだけど、それってのはたまたま特定環境では顕在化しないだけのバグだから。
「最適化の設定なんかでコンパイラがおかしなコード吐くのってそんな珍しいもんでない」ってほど頻発してたら既に大騒ぎになってる。
そうではなく、本当に規格が許す書き方で変なコードをはいたり、最適化で可笑しくなるのだったらそれは「そんな程度のこと」という問題ではない。
今時のコンパイラがおかしなコードを吐くような書き方って凡人がそう簡単に出来るようなもんじゃないと思うんだけど、そんな珍しくないものなの?もちろん規格違反のコードもしくは意図するコードを書けないでおきながらおかしなコードを吐く!とほざくアホは論外として。
#もちろんVC++は今時のコンパイラーじゃないです
今時のコンパイラがおかしなコードを吐くような書き方って凡人がそう簡単に出来るようなもんじゃないと思うんだけど、そんな珍しくないものなの?
おそらくはまだ贔屓目に見れば今時のコンパイラに含まれないことないと思われるGCCで、比較的最近、正式にリポジトリに取り込まれてるあるプロセッサでおかしなコード出まくりとかあるんでまあそんな珍しい話じゃないっしょ。
それはなんてことのないコードでもおかしなコードを吐くという単なるバグの話では。アーキテクチャに依存するって話でもないし(依存するバグもあるけど)
そういういつもドッグフード食ってる連中の話をされましても。
XcodeでのARMのコード生成する処理とx86のコード生成する処理が同じコードで行われてるってんなら聞いてやらんでもない話ダナ
gccの話をしてるのになぜ関係のないXcodeの話を?
同様のことはXcodeでは絶対に起こり得ないとでもお思いですか?
だからなんでそんな関係ない話を。
もともとXcodeの話じゃん
(#2417027) からの流れはgccの話です。Xcodeの話をしたいなら、まず(#2417027) でいっている
> おそらくはまだ贔屓目に見れば今時のコンパイラに含まれないことないと思われるGCCで、比較的最近、正式にリポジトリに取り込まれてるあるプロセッサでおかしなコード出まくりとかあるんでまあそんな珍しい話じゃないっしょ。
という話がXcodeでも適用できるという情報を出してください。
appleがXcodeにそんなあやしげなバージョンのコンパイラをしょっちゅう突っ込んでいるなんて話は聞いたことがないですが。
過去も将来もリリース後の不具合やそれへの修正も一切発生しえない完璧な製品であるXcodeはすばらしいですね。
誰がそんなことを言ってるんですか?
それよりも> おそらくはまだ贔屓目に見れば今時のコンパイラに含まれないことないと思われるGCCで、比較的最近、正式にリポジトリに取り込まれてるあるプロセッサでおかしなコード出まくりとかあるんでまあそんな珍しい話じゃないっしょ。という話がXcodeでも適用できるという情報を出してください。
Xcode bugsでぐぐるだけ [google.co.jp]で何十万件だか出てくる程度には珍しくないですな。
一般論としてソフトウェアに不具合は付き物ですが、過去も将来もリリース後の不具合やそれへの修正も一切発生しえない完璧な製品であるXcodeはすばらしいですね。
いくつかコンパイラ関連のバグの内容を見てみましたが、アーキテクチャ依存のバグは見当たりませんね。
x86のコード品質に問題があるという話は成り立ちません。
LLVM の Bugzilla [llvm.org]でARMとかthumbとかx86とかで検索するだけでアーキテクチャ依存の不具合なんて沢山報告されてるの分かると思うけどね。
アーキテクチャ依存のバグも見当らない、常に完璧なコードを出力するXcodeはすばらしいですね。
XcodeはMacOSX用開発環境なんだから、x86コードはIntelMac向け開発で十分プルーフ済だろ。
にもかかわらずそうやって根拠もなしにぐだぐだ文句言ってるのって何なの?
完全なる信頼性があって動作確認もせずにリリース可能とおっしゃるわけですね、了解しました。
それなりの信頼性はある。動作確認の話なんて一言も言ってない。
既に動作実績がありそれなりの信頼性がある物を動かない動かないとごねるのはなんで?
動作確認の話なんて一言も言ってない。
ビルドし直すだけで動作確認もせずにリリースできると言ってるのだからそりゃ一言も言ってないでしょうね。
ぶっちゃけビルドし直すだけなので。
XcodeのARMコードって「完全なる信頼性があって動作確認もせずにリリース可能」だったんですか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
Intel「今後のiPhoneもiPadも全部Atom採用にするなら作ってやるよ(ホジホジ」 (スコア:0)
……既存のソフトウェア資産どーすんだよ
Re: (スコア:1)
iOS の元となった OS である Mac OS X でいえば、そもそも少し前のだって、x86 と PowerPC の混成バイナリだったし、今は 32bit と 64bit の2種類のバイナリがワンパッケージ化されていたりしますので。そういうユニバーサルなのは Apple の十八番です。
無論、ユニバーサルでないバイナリそのものを動かそうとしたらエミュがいるけど。
そんな環境を用意しなくても、普通はあっという間に対応ソフトがそろう。
なぜならば、ほとんど、開発環境だけで吸収できる。
ぶっちゃけビルドし直すだけなので。
一瞬でアプリ側で新しいCPUに対応できます。
そして、Atom と ARM の両方に対応したパッケージとしてアプリをリリースできる。
全くなんの問題もなく、過去の資産を使えますよ。
そういう事態が起きても心配無用。
Re: (スコア:0)
なぜならば、ほとんど、開発環境だけで吸収できる。
ぶっちゃけビルドし直すだけなので。
一瞬でアプリ側で新しいCPUに対応できます。
そして、Atom と ARM の両方に対応したパッケージとしてアプリをリリースできる。
全くなんの問題もなく、過去の資産を使えますよ。
ビルドが通れば問題なくアプリは動作すると思ってる方? おめでたいですね。
Re: (スコア:0)
もしビルドが通ったのにもかかわらず動かないんだったら、
それは XCODEがまともなバイナリを吐いて無いってことだ。
もしくは元々バグってたかのどっちかだ。
バグがあったのならちょうどいい機会だから直せば良い。
アセンブラでも使って無い限りCPUの違いなんざ微々たるもんだ。
そのためのライブラリやAPIだろ。
Re:Intel「今後のiPhoneもiPadも全部Atom採用にするなら作ってやるよ(ホジホジ」 (スコア:0)
もしビルドが通ったのにもかかわらず動かないんだったら、
それは XCODEがまともなバイナリを吐いて無いってことだ。
もしくは元々バグってたかのどっちかだ。
バグがあったのならちょうどいい機会だから直せば良い。
XCODEがまともなバイナリを吐いて無い場合はどうすんですか? それ以前の話として、ビルドが通ったアプリの動作確認もせずに動くか動かないか判るんですか?
アセンブラでも使って無い限りCPUの違いなんざ微々たるもんだ。
コンパイラの、ARMかx86用にコード吐く部分て結構違うと思いますが。
Re: (スコア:0)
もしXCODEのx86コードが使い物にならない代物なら、
すでにおおさわぎになってるはずだよね。
Re: (スコア:0)
もしXCODEのx86コードが使い物にならない代物なら、
誰かそんなこと言ってますか?
Re: (スコア:0)
親コメントで言ってるよね
XCODEがまともなバイナリを吐いて無い場合はどうすんですか?
Re: (スコア:0)
特定のソースの書き方や最適化の設定なんかでコンパイラがおかしなコード吐くのってそんな珍しいもんでないし、ソース書き換えたりコンパイルオプション変えて回避するなんてのは常套手段でしょ。そんな程度のことでコンパイラのことを「使い物にならない代物」とはそうそう言わないと思いますが。
Re: (スコア:0)
「特定のソースの書き方」といえばごまかせると思ってるようだけど、それってのはたまたま特定環境では顕在化しないだけのバグだから。
「最適化の設定なんかでコンパイラがおかしなコード吐くのってそんな珍しいもんでない」ってほど頻発してたら既に大騒ぎになってる。
そうではなく、本当に規格が許す書き方で変なコードをはいたり、最適化で可笑しくなるのだったらそれは「そんな程度のこと」という問題ではない。
Re: (スコア:0)
今時のコンパイラがおかしなコードを吐くような書き方って凡人がそう簡単に出来るようなもんじゃないと思うんだけど、そんな珍しくないものなの?
もちろん規格違反のコードもしくは意図するコードを書けないでおきながらおかしなコードを吐く!とほざくアホは論外として。
#もちろんVC++は今時のコンパイラーじゃないです
Re: (スコア:0)
今時のコンパイラがおかしなコードを吐くような書き方って凡人がそう簡単に出来るようなもんじゃないと思うんだけど、そんな珍しくないものなの?
おそらくはまだ贔屓目に見れば今時のコンパイラに含まれないことないと思われるGCCで、比較的最近、正式にリポジトリに取り込まれてるあるプロセッサでおかしなコード出まくりとかあるんでまあそんな珍しい話じゃないっしょ。
Re: (スコア:0)
それはなんてことのないコードでもおかしなコードを吐くという単なるバグの話では。
アーキテクチャに依存するって話でもないし(依存するバグもあるけど)
そういういつもドッグフード食ってる連中の話をされましても。
Re: (スコア:0)
XcodeでのARMのコード生成する処理とx86のコード生成する処理が同じコードで行われてるってんなら聞いてやらんでもない話ダナ
Re: (スコア:0)
gccの話をしてるのになぜ関係のないXcodeの話を?
Re: (スコア:0)
同様のことはXcodeでは絶対に起こり得ないとでもお思いですか?
Re: (スコア:0)
だからなんでそんな関係ない話を。
Re: (スコア:0)
もともとXcodeの話じゃん
Re: (スコア:0)
(#2417027) からの流れはgccの話です。
Xcodeの話をしたいなら、まず(#2417027) でいっている
> おそらくはまだ贔屓目に見れば今時のコンパイラに含まれないことないと思われるGCCで、比較的最近、正式にリポジトリに取り込まれてるあるプロセッサでおかしなコード出まくりとかあるんでまあそんな珍しい話じゃないっしょ。
という話がXcodeでも適用できるという情報を出してください。
appleがXcodeにそんなあやしげなバージョンのコンパイラをしょっちゅう突っ込んでいるなんて話は聞いたことがないですが。
Re: (スコア:0)
過去も将来もリリース後の不具合やそれへの修正も一切発生しえない完璧な製品であるXcodeはすばらしいですね。
Re: (スコア:0)
誰がそんなことを言ってるんですか?
それよりも
> おそらくはまだ贔屓目に見れば今時のコンパイラに含まれないことないと思われるGCCで、比較的最近、正式にリポジトリに取り込まれてるあるプロセッサでおかしなコード出まくりとかあるんでまあそんな珍しい話じゃないっしょ。
という話がXcodeでも適用できるという情報を出してください。
Re: (スコア:0)
Xcode bugsでぐぐるだけ [google.co.jp]で何十万件だか出てくる程度には珍しくないですな。
Re: (スコア:0)
一般論としてソフトウェアに不具合は付き物ですが、過去も将来もリリース後の不具合やそれへの修正も一切発生しえない完璧な製品であるXcodeはすばらしいですね。
Re: (スコア:0)
いくつかコンパイラ関連のバグの内容を見てみましたが、アーキテクチャ依存のバグは見当たりませんね。
x86のコード品質に問題があるという話は成り立ちません。
Re: (スコア:0)
いくつかコンパイラ関連のバグの内容を見てみましたが、アーキテクチャ依存のバグは見当たりませんね。
LLVM の Bugzilla [llvm.org]でARMとかthumbとかx86とかで検索するだけでアーキテクチャ依存の不具合なんて沢山報告されてるの分かると思うけどね。
Re: (スコア:0)
アーキテクチャ依存のバグも見当らない、常に完璧なコードを出力するXcodeはすばらしいですね。
Re: (スコア:0)
XcodeはMacOSX用開発環境なんだから、x86コードはIntelMac向け開発で十分プルーフ済だろ。
にもかかわらずそうやって根拠もなしにぐだぐだ文句言ってるのって何なの?
Re: (スコア:0)
完全なる信頼性があって動作確認もせずにリリース可能とおっしゃるわけですね、了解しました。
Re: (スコア:0)
それなりの信頼性はある。
動作確認の話なんて一言も言ってない。
既に動作実績がありそれなりの信頼性がある物を動かない動かないとごねるのはなんで?
Re: (スコア:0)
動作確認の話なんて一言も言ってない。
ビルドし直すだけで動作確認もせずにリリースできると言ってるのだからそりゃ一言も言ってないでしょうね。
ぶっちゃけビルドし直すだけなので。
一瞬でアプリ側で新しいCPUに対応できます。
そして、Atom と ARM の両方に対応したパッケージとしてアプリをリリースできる。
Re: (スコア:0)
XcodeのARMコードって「完全なる信頼性があって動作確認もせずにリリース可能」だったんですか?