- Xamarin Part6
274 ：デフォルトの名無しさん[sage]：2019/01/29(火) 10:02:42.23 ID:8rAEnTT8 - AndroidでC#のアプリをダウンロードすればアイコンをクリックするだけで
起動できるようにする場合、.NET の RUNTIME はいつインストールされる？
AndroidマシンはCPUが色々あるらしいので、.NET RUNTIME は、1つだけの
CPUに特化したものでは駄目なはず。なので、以下のどれかを行わなくてはならない
ハズ：
1. アプリの起動前に、手作業でそのCPUに応じたRUNTIME をインストールしておく。
2. アプリの初回起動時にCPUに応じたものをネットから自動ダウンロードする。
3. RUNTIMEは、CPU Native 用ではなく、Java仮想マシン用のものとする。
つまり、.NET 仮想マシンが、Java仮想マシンの上で動作する二重構造
とする。<--- めちゃくちゃ効率が悪い。
|
- 【wasm】ブラウザでC++。Emscriptenを語ろう
18 ：L[sage]：2019/01/29(火) 10:27:43.11 ID:8rAEnTT8 - Emscriptenを使わずに、clang で wasm を出力してみたところ、
C の local auto 変数は、wasm の native stack(shadow stack) ではなく、
グローバル変数(wast において $global$0 という名前 ) を stack pointer
(asmjs における STACKTOP) として、memory なる HEAP8[] 相当の
JS 配列の中に確保されることが分かった。
つまり、asm.js を途中に介さないで直接 wasm を出力した場合でも、
local auto 変数は、wasm の native stack に確保されるわけではなく、
ちゃんと、HEAP8[SATCKTOP + ofs] のような意味でJS の グローバル変数の
HEAP8[] 配列のようなものの中に確保されていると言うこと。
だから、C の local auto 変数の(先頭)アドレスを取得することも出来るし、
C のglobal 変数のアドレスと、全く同じ扱いにすることが出来ている。
wasm において、Cのポインタの中に入っている「アドレス」は、
HEAP8[] 配列の index 番号である。だから、0 に近い小さな値となっている。
ポインタの値が、10 の場合、HEAP8[10] に対応している。
また、この memory は、現状、wasm 側で確保して、それを、JS 側に export
している。JS 側は、それを必要あらば、HEAP8[] 配列に「投影」することが出来る。
HEAP8 という名前は仮のもので、任意の名前をつけることが出来る。
また、同じ memory 領域を HEAP32、HEAP16、HEAP8 として、重ねるように
配列に投影することも出来る。
|
- Xamarin Part6
278 ：デフォルトの名無しさん[sage]：2019/01/29(火) 10:49:43.38 ID:8rAEnTT8 - >>275
でも、CPUの種類は時間がたつにつれて増えていくかも知れないので、
それだと、2019年に作ったC#アプリのapkは、再コンパイルなしでは
新しい Android マシンでは起動できないと思うけど。
|
- Xamarin Part6
279 ：デフォルトの名無しさん[sage]：2019/01/29(火) 10:53:42.11 ID:8rAEnTT8 - C#アプリの Android 版の apk は、15MB 程しかないらしい。
これに本当に全てのCPU向けの .NET ランタイムが入るだろうか？
Windowsマシンで、Windows Update の詳細記述を見ていると
.NET の 修正 Update だけで、数10MB〜数100MB あったと思う。
修正と言うのは、部分 patch にすれば小さく出来るはず。
それでも、こんなに大きい。
あらゆる Android マシンの、修正 patch ではない、完全な .NET ランタイムが、
本当に 15MB に入るのだろうか。
どっちにしろ、論理的に考えて、それでは新しいアーキテクチャの CPU には対応できない。
|
- Xamarin Part6
282 ：デフォルトの名無しさん[sage]：2019/01/29(火) 11:38:36.67 ID:8rAEnTT8 - >>281
そういう仕組みだったのか。
じゃあ、Java の思想とはぜんぜん違う。
Java の場合は、同じ jar ファイルが、異なるマシンでもそのまま動作する。
C#の場合、MSの判断一つで特定のCPU用のパッケージが作れなくなってしまう可能性が
ある訳だね。なんちゅうこっちゃ。Javaとは全く違うじゃない。
|
- Xamarin Part6
284 ：デフォルトの名無しさん[sage]：2019/01/29(火) 12:10:23.51 ID:8rAEnTT8 - >>283
Android マシンには、最初からそのマシンの CPU に合わせた
JVM がインストールされているので、違うぞ。
|
- Xamarin Part6
288 ：デフォルトの名無しさん[sage]：2019/01/29(火) 13:10:45.24 ID:8rAEnTT8 - >>287
x86コードの除去し忘れだったりして。
|
- Xamarin Part6
291 ：デフォルトの名無しさん[sage]：2019/01/29(火) 15:52:46.68 ID:8rAEnTT8 - >>289
「各アーキテクチャ向けapk」と「それらをまとめたapk」は、
それぞれ何MB 位なの。
同じサイズということは論理的にありえないハズだが。
|
- Xamarin Part6
294 ：デフォルトの名無しさん[sage]：2019/01/29(火) 16:29:26.37 ID:8rAEnTT8 - >>292
Android における C# の GUI の Hello World の場合に決まってるじゃん。
|
- C++相談室 part140
340 ：デフォルトの名無しさん[sage]：2019/01/29(火) 18:15:41.64 ID:8rAEnTT8 - そもそもスマポ自体が推奨されるものかどうか。
stl も boost も本当は C++ じゃない。
|
- C++相談室 part140
341 ：デフォルトの名無しさん[sage]：2019/01/29(火) 18:22:39.90 ID:8rAEnTT8 - 「どうして、人々は、『私は本当は boost を使いたくない』と遠まわしにほのめか
すのでしょう？」
Why do people seem to insinuate I would rather not use Boost?
Very often here on SO I see notes about boost such as
If you are fine with using Boost...
or
If you can use Boost...
https://stackoverflow.com/questions/33452925/why-do-people-seem-to-insinuate-i-would-rather-not-use-boost
|
- C++相談室 part140
343 ：デフォルトの名無しさん[sage]：2019/01/29(火) 18:25:40.64 ID:8rAEnTT8 - Why do people seem to insinuate I would rather not use Boost?
↓
多くの人が、「Boostを使わないほうがいい」、と主張しているように見えるのは
なぜですか？
|
- C++相談室 part140
360 ：デフォルトの名無しさん[sage]：2019/01/29(火) 23:26:25.60 ID:8rAEnTT8 - 年数の問題でなく、単に boost や C++ の設計者が馬鹿なだけだよ。
はっきり言って。
|