- C++相談室 part119 [転載禁止]©2ch.net
365 ：デフォルトの名無しさん[sage]：2015/09/22(火) 00:26:02.37 ID:PT+IC+/U - >>363
CLRはMSILという中間言語を実行時にJITして配置するから、
結果的に各関数は使うまで配置されないし、使い終わったら捨てられるのかと。
多分オリジナルのMSILはstaticに存在するのではないかと。
ただそれがメモリ上である必要はないが。
結果的に透過的になる。
https://msdn.microsoft.com/ja-jp/library/z1zx9t92.aspx
|
- C++相談室 part119 [転載禁止]©2ch.net
366 ：デフォルトの名無しさん[sage]：2015/09/22(火) 00:36:49.33 ID:PT+IC+/U - >>361
そこまで知っているのなら俺が言っていることの意味は分かるはずだが。
PAEまで使えばとりあえず4GBx10までは見える。
ただ、PAEがマトモに使えるようになったのはWin8からだ。
そして、そんなことをやるより64bitに移行するのをMSは選択した。
XPにPAEという声も根強かったが、ガン無視したからね。（それで正しいと思うが）
|
- C++相談室 part119 [転載禁止]©2ch.net
369 ：デフォルトの名無しさん[sage]：2015/09/22(火) 00:57:27.51 ID:PT+IC+/U - >>367
各クラスのメンバ関数は、そのクラスのインスタンスが全て無くなれば要らなくなる。
当たり前だが、GC上のオブジェクトについては全て「型」を知っている。
だから、GCヒープしか提供していない言語であれば、全く問題なく回収可能。
それ以前に、JIT前提であればとりあえず回収して例外処理で再配置も可能。
コピーオンライトの関数版だ。
とにかく君達が懐疑的なのは分かったが、実際CLRはそうなんだよ。
|
- C++相談室 part119 [転載禁止]©2ch.net
373 ：デフォルトの名無しさん[sage]：2015/09/22(火) 01:11:24.05 ID:PT+IC+/U - >>371
X x = new X(); //ここで初めてオブジェクトのメンバ関数も配置される
x.Baka();
x = null; //これ以降解放してよし。GC対象。
x = new X(); //ここで再びXがメンバ関数と共に配置される
x.Baka();
|
- C++相談室 part119 [転載禁止]©2ch.net
376 ：デフォルトの名無しさん[sage]：2015/09/22(火) 01:17:40.85 ID:PT+IC+/U - てかまあもうスレチだし止めよう。
とにかくCLRはそうなんだよ。
ググッてもなかなかでてこないのだけど、（いいキーワードが思いつかない）
例えば delegate というのは関数ポインタなんだけど、これはへまをするとGCされる。
https://msdn.microsoft.com/ja-jp/library/43yky316(v=vs.110).aspx
http://kchon.blog111.fc2.com/blog-entry-139.html
https://msdn.microsoft.com/ja-jp/library/17sde2xt(v=vs.90).aspx?cs-save-lang=1&cs-lang=csharp#code-snippet-3
|
- C++相談室 part119 [転載禁止]©2ch.net
377 ：デフォルトの名無しさん[sage]：2015/09/22(火) 01:19:10.62 ID:PT+IC+/U - >>375
分かりやすく書いただけ。
もっと分かりやすく言えるのなら、君が371にレス付ければいい。
要するにエラーにはならないということが明確に分かればいいだけだろ。
|
- C++相談室 part119 [転載禁止]©2ch.net
379 ：デフォルトの名無しさん[sage]：2015/09/22(火) 01:24:00.21 ID:PT+IC+/U - >>375
32bit版とかいう概念がJavaやC#の仕様にないってことだよ。
そこは既に抽象化済みなんだよ。
はいもうこの件は終わり。
PAEまで使って32bitを延命させる意味はないとMSが判断した以上、.NETもそれに追従だ。
今後はどうなるかは知らない。
|
- C++相談室 part119 [転載禁止]©2ch.net
384 ：デフォルトの名無しさん[sage]：2015/09/22(火) 03:20:50.96 ID:PT+IC+/U - >>375
ちなみに知らないのだとおもうが、PAE対応アプリもあるにはある。
SQL Server とか、他にも一つか二つくらいあったはず。逆に言えばそれくらいしかなかったと思う。
> この結果、アプリケーションは 15 GB までの物理メモリにアクセスできます。
https://msdn.microsoft.com/ja-jp/library/Cc785115(v=WS.10).aspx
https://technet.microsoft.com/ja-jp/library/ms175581(v=sql.105).aspx
APIはMapUserPhysicalPagesで窓アクセスになる。
https://msdn.microsoft.com/ja-jp/library/windows/desktop/aa366527(v=vs.85).aspx
てかこの件について君らがムキになる意味が分からん。
ランタイムで隠蔽すれば普通に出来る。（ユーザーが全く関知する必要がない＝同じソースコードで動く）
ただし出来るのとやるのは別で、MSは64bit化を急ぐという判断だった。
PAEは延命で、64bit化は解決なのだから、妥当な判断だと思う。
逆にLinuxはPAE派だったと思ったが、どうなったのかは知らない。
|
- C++相談室 part119 [転載禁止]©2ch.net
385 ：デフォルトの名無しさん[sage]：2015/09/22(火) 03:21:26.35 ID:PT+IC+/U - 広範囲にランダムアクセスをするのでなければ、窓アクセスでもそこそこ使える。
オブジェクト指向なら見えないもの(privateやスコープ外)の方が多いのだから、
ランタイムがしこしこ貼り直してくれれば問題ない。
これを手動でやるとなると、実際には管理しきれないから、
単純なキャッシュ的使い方にするか、あるいはラッパを用意するかになる。
もちろんそれでもやりたい人はやれるようにAPIがあるわけだが。
> 大量のデータを操作するアプリケーションが、ハード ディスクの代わりにメモリにデータを維持することで、パフォーマンスが向上します。
https://msdn.microsoft.com/ja-jp/library/cc775523(v=ws.10).aspx
C/C++はメモリモデルがフラットで、リニアにアクセスできる前提だ。(ポインタは常にアクセス可能）
だから4GBの壁が直接見える。
C#とかはそもそもメモリモデル自体が必要ない。
変数はただの箱で、前回入れたものが出てくるだけ。共用体は禁止だ。
だから4GBの壁なんてものがそもそも存在しない。
ランタイムさえ対応すれば同じソースでPAE/AWEで15GBまでヒープ上に確保できることになる。
（C#のArrayは必ず添字チェックをしているため、ランタイム側で細切れに貼り直すことが出来、
結果、ユーザ側に15GBの一つのArrayを確保することも可能。)
ただしMSはこれを目指さなかった。
特に不思議なわけでもなく、ムキになる話でもないと思うが。
GCヒープ自体が一つのオブジェクトみたいなもので、get/setしかインタフェースを提供してない。
だからこういう事が普通に出来る。
（ただし繰り返すが、出来るのとやるのは別）
|
- C++相談室 part119 [転載禁止]©2ch.net
390 ：デフォルトの名無しさん[sage]：2015/09/22(火) 04:22:58.08 ID:PT+IC+/U - >>386
そうじゃなくて、Cの場合は sizeof(void*) が確定的なんだよ。
だから32bit版というものが絶対的に存在してしまう。
C#にはそれがないって話。
ただこれは379と同じなんだけどね。
|
- C++相談室 part119 [転載禁止]©2ch.net
391 ：デフォルトの名無しさん[sage]：2015/09/22(火) 04:24:02.48 ID:PT+IC+/U - >>384
> C#なら回収されるのはアプリケーションドメイン単位
了解した。
> それはおそらく関数ポインタを入れてる変数がGCされている
その線は考えたが、、、まあ上記と合わせて冷静に考えればそのようだ。
ここの人達は関数の動的配置/回収をそもそも信じていない。
だから回収事例として用意したつもりだが確かに間違いのようだ。
動的関数生成をしないのなら、GCする必要もなく、回収がAPドメイン単位なら静的展開してそれっきりだね。
ちなみに回収タイミング/単位自体は俺は気にしておらず、動作できる例として出していたのだが、
そこに噛みつく奴がいて余計におかしな事になった。
ただまあ、APドメイン単位での回収で確定だし、助かった。
> プロセス全体を停止せずに、個々のアプリケーションを停止できます。 アプリケーション ドメインを使用すると、1 つのアプリケーション内で実行されているコードをアンロードできます。
> 個々のアセンブリや型はアンロードできません。 アンロードできるのはドメイン全体だけです。
https://msdn.microsoft.com/ja-jp/library/2bh4z9hs(v=vs.110).aspx
ただこれならもうちょっとC++/CLIは緩くてもいいはずなのだが、、、
他クラスのpublicメンバ関数を呼ぶ場合もstaticじゃないとC2352エラー（下側例）になるのだが、これは何故？
APドメイン単位で展開してるのなら呼ばせてくれよーと思う。（これがあるから型単位だと思っていた）
https://msdn.microsoft.com/ja-jp/library/2x426hte.aspx
なお回答頂けるのであれば、CLIスレで構いません。
http://peace.2ch.net/test/read.cgi/tech/1268613679/
|
- C++相談室 part119 [転載禁止]©2ch.net
392 ：デフォルトの名無しさん[sage]：2015/09/22(火) 04:25:27.88 ID:PT+IC+/U - すいません、>>391は>>383宛て
|
- C++相談室 part119 [転載禁止]©2ch.net
401 ：デフォルトの名無しさん[sage]：2015/09/22(火) 11:52:36.13 ID:PT+IC+/U - >>399
どれのこと？Nxxxxでよろしく。またはググるからキーワードをくれ。
http://www.wdic.org/w/TECH/ISO/IEC%2014882%3A2014
|
- C++相談室 part119 [転載禁止]©2ch.net
402 ：デフォルトの名無しさん[sage]：2015/09/22(火) 11:54:51.98 ID:PT+IC+/U - スレチだが、動的関数配置に関してはもうちょっと分かりやすい例があった。
> DynamicMethod クラス
> コンパイル、実行、および破棄できる動的メソッドを定義し、表します。 破棄されたメソッドは、ガベージ コレクションの対象となります。
> Just-In-Time (JIT) コンパイラ によって作成された実行可能コードは、DynamicMethod オブジェクトがクリアされたときにクリアされます。
https://msdn.microsoft.com/ja-jp/library/system.reflection.emit.dynamicmethod(v=vs.110).aspx
C/C++ではやってない話だから気味が悪いのだと思うが、とにかくCLRの世界はこんな感じなんだよ。
なおこれは既存のMSIL（中間言語）をコピーするようなので、生成ではなく流用になる。(evalではない)
|
- C++相談室 part119 [転載禁止]©2ch.net
408 ：デフォルトの名無しさん[sage]：2015/09/22(火) 13:57:03.37 ID:PT+IC+/U - 俺の疑問(302)は解消したよ。
お前らの疑問はあるみたいだし、それについて説明も出来るけど、もう面倒なので止める。
誰か分かる人は回答してやってくれ。
てかお前らもうちょっと他言語も触った方がいいぞ。
Cの世界だけで閉じているから、Cを客観的に見れてないんだよ。
それとは別に、401に対する回答は募集する。
|
- C++相談室 part119 [転載禁止]©2ch.net
420 ：デフォルトの名無しさん[sage]：2015/09/22(火) 16:59:16.98 ID:PT+IC+/U - >>412
> contiguous bytes
他の言語ではこの必要すらない。
これがリニアって事だよ。
ちなみに君はC以外の言語一つでも使えるかい？
だったらその言語でこの必要があるかを考えてみるといい。
|
- C++相談室 part119 [転載禁止]©2ch.net
431 ：デフォルトの名無しさん[sage]：2015/09/22(火) 18:59:44.87 ID:PT+IC+/U - >>424
別に逃げているわけではなくて、
今の君の知識範囲では理解できないだろうから諦めたんだよ。
もう既に十分説明している。
俺の疑問は既に解消したのだから、君の突っかかりにいちいち答える必要もない。
君は知っているつもりなんだろうけど、全然分かってない。
元々のブログ(>>295)、以下のくだりは真なんだが、そもそもこれを理解できてないだろ。
> たとえば、32bitのCPU上では、通常のプログラムは、4GBのメモリ空間に制限され、4GB以上のメモリを利用することは非常な困難を伴います。
> ところが、JavaやC#といった言語は、原理上、そのような制限を受けません(バンク切り替えだとか、セグメントだとかの話はあえて無視)。
> あくまでも原理上の話ではあるので、現状がそうなっているわけではないのですが、ポインタといった概念が言語上に出現しないことによって、
> データをメモリ上の番地で表現する必要がないためです。
俺はこの部分の説明をしていただけなんだよ。ただ、君が理解できていないとなると、その前の部分
> C/C++のプログラマの住んでいる世界は、ポインタがあるおかげで、ある意味では、何でも出来るアセンブラの世界ではあるのですが、
> そのことが逆にC/C++プログラマの発想を狭い範囲に閉じこめてしまっていることが多々あります。
> JavaやC#のようなポインタのない世界が実は、
> アセンブラのようなポインタというかアドレスに支配されている世界では想像しにくい新たなパラダイムや手法を与えてくれることもあります。
も真なのかな、とも思えてくる。（個人的にはこの部分はハズレだと思っていた。)
君が無知なままでいるのは君の責任だ。
誰かが君のことを可哀想と思うのなら、いつか教えてくれるかもしれない。
俺はここに認めてもらいに来たわけではなくて、疑問を解消しに来ている。だから用は済んだ。
君が俺のことを誤解するのも君の自由だ。それを修正する必要もない。
ただなあ、とりあえず最初のブログの中身も理解出来ないのにその態度は、痛いよ。
そういうのは止めた方がいい。
傍観している連中の中にも明らかに分かっている奴もいるはずだが、誰も出てこないのはそういうことだよ。
|
- C++相談室 part119 [転載禁止]©2ch.net
435 ：デフォルトの名無しさん[sage]：2015/09/22(火) 19:24:45.07 ID:PT+IC+/U - >>432
生ポインタを使えないC言語なんて存在価値がないだろ。
実際それがあったとして、使う奴がいるとも思えないが、
ネイティブコードを吐くJavaが欲しい時に使うのか？
|
- C++相談室 part119 [転載禁止]©2ch.net
439 ：デフォルトの名無しさん[sage]：2015/09/22(火) 19:34:46.81 ID:PT+IC+/U - >>432
ちなみに禁止されていないのは確かだが、C言語では実現出来ないだろ。
C++で演算子のオーバーロードを基本型にも全部やってラップすれば達成可能な気もするが、
ポインタのところに若干制限があった気がする。（ただこの辺は余り詳しくない）
|
- C++相談室 part119 [転載禁止]©2ch.net
441 ：デフォルトの名無しさん[sage]：2015/09/22(火) 19:42:18.38 ID:PT+IC+/U - >>437
いやちょっと待て。実はEmscriptenは使用を検討しようとしていた。
理由は生JavaScriptが色々糞だからで、TypeScriptも検討中だ。
それはEmscripten用の書き方だということか？
ならば確かにその記述方法は妥当だろう。
LLVMからの変換だと思っていたが、それ以前にLLVMに生ポインタコードが出ないようにラップするわけだな。
|
- C++相談室 part119 [転載禁止]©2ch.net
444 ：デフォルトの名無しさん[sage]：2015/09/22(火) 19:58:39.53 ID:PT+IC+/U - >>438
それは繰り返しにしかならないが、以下の通り。
原理的な話なら、抽象化された変数領域しか持たない言語(C#,Java)では、アドレスというものがそもそも見えない。
だから、4GBの壁がそもそもユーザーに見えない。
これに対して、C/C++では4GBの壁がユーザーに丸見えだ。
>>432のように、ポインタをユーザーがラップして全てint**とかにした場合、それは「ユーザーがそう記述した」という。---(A)
そうではなくて、ユーザーが通常通り int* のまま使っていて、
それをコンパイラだけで int* のネイティブにするのか、int** のJava的参照ポインタにするのかをコンパイルオプションで切り換えられるのなら、 ---(B)
それは「コンパイラで4GBの壁を越えた」という。
いずれにしても、C/C++言語自体で4GBの壁を越えたというのは言い過ぎだ。
ところで、Emscriptenは(B)のどちらなのか、知っていたら教えてくれ。
（ユーザ側で int** と意識して書く必要があるのか、
もしかしてユーザーは int* のままで書いてもEmscriptenが int** に完全に変換できるのか）
|
- C++相談室 part119 [転載禁止]©2ch.net
446 ：デフォルトの名無しさん[sage]：2015/09/22(火) 20:06:26.45 ID:PT+IC+/U - >>442
違う。
> ポインタのところに若干制限があった気がする。
演算子のオーバーライドは俺は使ってないので詳しくないのだが、
最近読み直した「プログラミング言語C++」には11.2.3に（第3版ならP317)
> 特に、ポインタだけを操作する演算子関数は定義できないことに注意して頂きたい。
とあって、この件について本の中で別に説明されていたのだが、今見ても該当部分がすぐには出てこないということ。
たしかC言語との互換性を保つために、ポインタ演算子については自由に上書きできない部分があったはず。
> C/C++はメモリモデルがフラットで、リニアにアクセスできる前提だ。(ポインタは常にアクセス可能）
> だから4GBの壁が直接見える。
根拠も何も、そのまんまだ。
逆に聞いてみよう。
君はC#が使えるみたいだが、C#のマネージドコードだけの世界で、4GBの壁を意識することはあったかい？
無いだろ。そういうことだよ。
|
- C++相談室 part119 [転載禁止]©2ch.net
448 ：デフォルトの名無しさん[sage]：2015/09/22(火) 20:21:17.81 ID:PT+IC+/U - >>447
> これも「気がする」かな。断言するなら根拠をはっきり示せることを確認してね。
いや見えてるだろ明らかに。
void*が32bit環境では4GBまでしか表せない。だから4GBの壁が見える。
C#やJavaにはこれがない。それだけの話だよ。
> 「演算子が上書きできない」→「4GBの壁」っていうつながりがあると思ってるのか。
あるだろ。というか言い出したのはそちらだが。
4GBの壁は変数領域が抽象化されていないから見える。
だから、int**にして抽象化すれば直接は見えなくなる。
これがC#やJavaで4GBの壁が見えない理由そのものだ。ブログ主もこの観点で言っている。
まあいいよ。完全にループだし、君の論法もループしている。
降りで了解だ。こちらもその方が助かる。
それはそうとEmscriptenの情報があればよろしく。
|
- C++相談室 part119 [転載禁止]©2ch.net
451 ：デフォルトの名無しさん[sage]：2015/09/22(火) 21:58:18.19 ID:PT+IC+/U - >>444,448
スレチだが自己解決した。
生ポインタはTypedArrayにマッピングされるようだ。
まあ、冷静に考えれば当然だった。
|
- C++相談室 part119 [転載禁止]©2ch.net
453 ：デフォルトの名無しさん[sage]：2015/09/22(火) 23:39:14.16 ID:PT+IC+/U - むしろ俺は話の通じなさにびっくりだったわ。
32bit環境でのC言語で4GBの壁が見えるのは自明でしかない。
それを見えないと言われても頭おかしいとしか思えない。 >>447
マジでお前らは他言語少しでも触った方がいい。
完全に盲目になっている。
|
- C++相談室 part119 [転載禁止]©2ch.net
455 ：デフォルトの名無しさん[sage]：2015/09/22(火) 23:55:40.08 ID:PT+IC+/U - >>454
いやそこは関係ないんだよ。
ちなみに君もC/C++しかできないのか？
ちょっとマジで他言語、何でもいいからやってみた方がいい。
|