Visual Studio 2008 Part 22

**デフォルトの名無しさん** · 2014/10/13(月) 15:13:20.18

■公式
ttp://www.microsoft.com/japan/msdn/vstudio/default.aspx

■前スレ
Visual Studio 2008 Part 21
http://peace.2ch.net/test/read.cgi/tech/1290969016/

■リンク
Visual Studio 2008に搭載された17の新機能
ttp://www.atmarkit.co.jp/fdotnet/special/visualstudio2008_01/visualstudio2008_01_01.html
5000個のバグと戦った、MSが「Visual Studio 2008」RTM出荷
ttp://www.atmarkit.co.jp/news/200711/20/vs.html

■関連
Visual Studio 2013 part4
http://peace.2ch.net/test/read.cgi/tech/1404333757/
Visual Studio 2012 Part8
http://peace.2ch.net/test/read.cgi/tech/1392639689/
Visual Studio 2010 Part21
http://peace.2ch.net/test/read.cgi/tech/1412136476/
Visual Studio 2005 Part 27
http://peace.2ch.net/test/read.cgi/tech/1291513609/

その他テンプレ>>2-5

**デフォルトの名無しさん** · 2018/09/17(月) 10:25:48.51

その他諸々、話を整理すると、以下となる。（ソースは>>191参照）
1. managedコードではMSILが出力され、x86コードは含まれていない。
2. 起動時、MSILはJITされ、x86コードに落とされる。
3. このため、mainの1行目でブレークポイントで止め、calc_norm_and_regulateの逆アセンブルを見ようとしても、
　IDE上で「逆アセンブルを表示できません。式がまだネイティブマシンコードに翻訳されていません。」と出る。
　これはmainの1行目に System::Diagnostics::Debugger::Launch(); を入れたときも同様。
4. そしてこのJITに関して、上記IDE中の『[モジュールの読み込み中に JIT 最適化を抑制する] オプション』が効いてくる。
　規定ではオフ、つまり、ReleaseビルドでもIDE起動ならJIT最適化は抑制される。
　これがfld/fmul/fadd/fstpのループコードになる理由。
　これをオンにすれば、確かにReleaseビルドIDE起動でも、
　fld/fmul/faddのループコードとなり、コマンドプロンプト起動と同じ結果になることは確認した。
5. 上記では表現が微妙だが、JIT最適化をするかどうかは読み込まれるときに決まるらしい。
　したがって、Releaseビルドを起動後にアタッチした場合は通常通り最適化され、
　IDEからReleaseビルドを起動した場合は『既定では』最適化が抑制されてしまう。
　これがIDE起動とコマンドプロンプト起動で挙動が異なった原因。
　上記、『[モジュールの読み込み中に JIT 最適化を抑制する]』のチェックを外せば、直った。
6. おそらくこのオプションはソリューション毎ではなく、IDEのインストール毎なんだと思う。
　（ソリューション毎のオプションはプロジェクトのプロパティにあり、場所が違う)
　だからその人の環境によっては最初からオフにしている人がいたかも？
　これが再現実験をしてくれた人たちと微妙に結果が異なったりした原因か？

これで>>191についての疑問は解消した。（はず）
俺の本番コードについては再度確認し、また報告する。

**デフォルトの名無しさん** · 2018/09/17(月) 10:28:21.54

同じﾘﾘｰｽﾋﾞﾙﾄﾞで
結果がかわってんのになにいってんの？

fprintf入れるだけで
ﾘﾘｰｽﾋﾞﾙﾄﾞで結果が変わる

**デフォルトの名無しさん** · 2018/09/17(月) 10:31:16.66

やはり低学歴知恵遅れは
結果が意味するところが分かってないわ。。。

**デフォルトの名無しさん** · 2018/09/17(月) 10:32:49.39

ちなみにｵﾚがあげた結果は
すべてﾘﾘｰｽﾋﾞﾙﾄﾞの結果だからな
ﾃﾞﾊﾞｯｸﾞﾋﾞﾙﾄﾞの結果なんかあげても
意味ないからな

**デフォルトの名無しさん** · 2018/09/17(月) 10:38:00.02

CLRのｹｰｽもCLRでない普通のexeのｹｰｽでも
結果はまったく同じだからな

しかもすべてﾘﾘｰｽﾋﾞﾙﾄﾞで
おきてる誤差までぴったり一致してる

**デフォルトの名無しさん** · 2018/09/17(月) 10:52:24.35

>>288
お前は相変わらず理解してないな。

80bit（拡張倍精度）と64bit(倍精度)の演算で桁落ちが異なり、結果が異なるのは当然なんだよ。
問題は同じバイナリの癖に何故起動方法によって異なるのか？だったんだ。

理由はMSILだからだ。
MSILはCLR上でJITされ、x86コードに落とされる。
このときにJIT最適化がかかれば、拡張倍精度（を保ったまま）のコードになるし、
最適化がかからず毎回メモリに書き戻していれば、倍精度のコードになる。
.NETにおける同一バイナリってのは、同一MSILという意味であって、同一x86機械語という意味ではない。
だから、確かに同一バイナリを掴んでいたが、起動方法によって結果が異なっていたんだよ。
(VSがデバッグ用に意図的にそういう仕様にしていただけ。俺はそれを知らなかった）

君のコードについては、
いちいちfprintする場合はdouble(倍精度）が毎回必要になるから、
コンパイラはその部分での拡張倍精度でのループを断念し、
結果的にそのループが倍精度で回っているだけのこと。
もし仮にCが拡張倍精度型 ExDouble を持っていたとして、printfもそれに対応していれば、
もしかするとその毎回printfするコードでも拡張倍精度で回っていたかもしれん。
勿論手動でそういうコードのすることも可能だ。
そこはコンパイラがどう判断したのかでしかなく、あまり詰めても意味がない。

**デフォルトの名無しさん** · 2018/09/17(月) 10:54:19.52

× fprint
○ printf
まあ、分かると思いますが

**デフォルトの名無しさん** · 2018/09/17(月) 10:57:31.99

で、最適化されてるかされてないかすら
いまのいままで気付くことすらできない
そして気付く方法すらわからなかったわけか

うあわ
頭わるう。。。

ｷﾐ、ﾌﾟﾛｸﾞﾗﾑくむの向いてないわ

**デフォルトの名無しさん** · 2018/09/17(月) 10:58:47.63

問題の切り分けができない人は
ﾌﾟﾛｸﾞﾗﾑはくめない

ｺﾚは定説だからな

**デフォルトの名無しさん** · 2018/09/17(月) 11:09:05.96

>>286
なるほど面白いね。

レスが膨大過ぎて最初の方しか読んでなかったけど、ネイティブコードの話と思い込んでたら
.NETの話だったのかw

**デフォルトの名無しさん** · 2018/09/17(月) 12:34:14.16

個人的には、C++やx87 FPUは割と知識があったけど、.NET関連は余り追いかけてなかったので、気づくのが遅れた。

managedコード、unmanagedコードについて、今回初めて調べてみたくらいだし。

**デフォルトの名無しさん** · 2018/09/17(月) 12:53:34.77

>>292
「ID:dj7qSZnZ」の人は理解していないね。
彼は人の事馬鹿にしてるけど・・・。

**デフォルトの名無しさん** · 2018/09/17(月) 13:39:23.91

最初に指摘されたことだろうに。
アセンブラレベルで精度や効率に介入したきゃ.netなんて使うな、なんて分かりきったこと。

**デフォルトの名無しさん** · 2018/09/17(月) 14:58:46.52

エディタ使ってるとたまに Intellisense機能が効かないときがあるんだが
あれなんなの？
中間ファイルとか消せば直るの？

**デフォルトの名無しさん** · 2018/09/17(月) 17:03:46.83

>>300
はい。よく壊れます。
> [C++] There is an issue with the .ncb file
> Close the solution.
> Delete the . ncb file.
> Reopen the solution.
> Reopening the solution creates a new . ncb file.
> https://msdn.microsoft.com/ja-jp/library/ks1ka3t6(v=vs.110)

**デフォルトの名無しさん** · 2018/09/17(月) 17:17:56.66

>>301
なるほど .ncbファイルね
今度消してやってみるわ

**デフォルトの名無しさん** · 2018/09/17(月) 18:30:58.83

さて俺の本番コード、以下のようだ。
疑問は解消した。協力してくれた皆様ありがとう。

◎：拡張倍精度、○：倍精度、として、(ソースは>>191参照)
・Releaseビルドをコマンドプロンプトから起動→◎積和、◎平方根
・Debugビルドをコマンドプロンプトから起動→◎積和、○平方根
・IDEから起動→○積和、○平方根

これで3種類出来上がってた。
(なお、>>166内バイナリをアタッチした際の「AまたはC」は、「AまたはB」の間違い)
そしてIDE上で『[モジュールの読み込み中に JIT 最適化を抑制する]』を変更すると、
確かにRelease/Debugの2種類に絞れる。
Debugだからといって、全く最適化がかからないわけでもないようだ。
（1行内なら最適化がかかる？）

参考に、Releaseビルドの該当部分の逆アセンブルは以下。
積和が拡張倍精度で行われ、そのまま fsqrt で平方根が取られる。
（関数ごとインライン化されているのでアドレスが中途半端だが）
double retval = calc_norm_and_regulate(count, vec, false);
0000003e fldz
00000040 xor edx,edx
00000042 test esi,esi
00000044 jle 00000056
00000046 lea eax,[esp+28h]
0000004a fld qword ptr [eax+edx*8]
0000004d fmul st(0),st
0000004f faddp st(1),st
00000051 inc edx
00000052 cmp edx,esi
00000054 jl 00000046
00000056 fsqrt
00000058 fstp qword ptr [esp+10h]

**デフォルトの名無しさん** · 2018/09/19(水) 17:24:44.24

VC++2008だけど、突然一部のファイルだけブレークポイントが入らなくなった・・・
.ncb消したり、そのプロジェクトだけリビルドしたけど直らない
全リビルドすればおｋ？

**デフォルトの名無しさん** · 2018/09/19(水) 18:59:08.26

>>304
根本的な解決策とは違うが
「ブレークポイントは現在の設定ではヒットしません。ソースコードが元のバージョンと異なります。」
なら
[オプション] の[デバッグ]から[元のバージョンと完全に一致するソースファイルを必要とする] をオフで

**デフォルトの名無しさん** · 2018/09/20(木) 12:44:39.12

>>305
ありがとうございます。

結局、全リビルドでも直らなかったので、.sln と .vcproj 以外全部消して
Windowsも再起動して完全にまっさらな状態にして全ビルドしたら直りましたが、
そのうちまたブレークポイントが入らなくなったので、>>305の方法で
回避しました。

**デフォルトの名無しさん** · 2019/06/19(水) 14:12:16.93

お、おう

**デフォルトの名無しさん** · 2019/10/04(金) 14:14:25.88

C++　CLRのWindowsフォームアプリ作ってると、
イベントとか記入するときインデントがおかしい（スペースが1つ付く）んですが、
これを直す方法ってありますか？

**デフォルトの名無しさん** · 2019/10/06(日) 21:09:30.88

テンプレート特殊化ってVisualC++2008 SP1 ではできないですか？

**デフォルトの名無しさん** · 2019/10/06(日) 21:48:55.66

>309
https://programming-place.net/ppp/contents/cpp/language/023.html
こちらでできました、スレ汚しすみません

**デフォルトの名無しさん** · 2021/04/20(火) 20:00:45.05

わからないので教えてください。
シリアル通信をするプログラムを作りたく、
VS2008にて、「SerialPort」を使え、というのが
サイトにあったのですが、
ツールボックスにSerialPortがありません。
追加する方法を教えてください。

使用環境：VS2008 C++ MFCアプリケーション

**デフォルトの名無しさん** · 2021/04/20(火) 20:36:15.98

ねぇねぇ今日は何処まで逝こうかな～

COMはネイティブなのかね

**デフォルトの名無しさん** · 2021/04/23(金) 21:39:54.21

>>311
SerialPortは使ったこと無いから知らんが、
その程度のことを自力で解決出来ない奴が今更VS2008でしかもMFCとか無理だ。
サイトを参考にするのもいいが、日付は必ず見るようにしろ。
.NET serial port で検索すると以下が当たるし、今なら普通にこれだと思うが。
https://docs.microsoft.com/ja-jp/dotnet/api/system.io.ports.serialport?view=dotnet-plat-ext-5.0

どうせ見えた展開だし、面倒だから先に言っておくが、
お前のやってることは初心者のあるある

・そもそもやり方を間違っているのに、それ以外の解決方法を認めない
・正しいやり方を教えても、それは聞いてないとして受け付けない

だ。だからどうせこれから文句も言うのだろうが、重ねて言うが、
今更その環境(VS2008+MFC)はあり得ないくらいの異常さだ。
お前が初心者で何も知らないだけなら、常に最新の環境を使うように心がけろ。それだけで無駄なことに嵌りにくくなる。
その環境に拘る何らかの理由があり、それを強いてきた上司等が居るのなら、まずそいつに聞け。
聞く人が居ないのなら、今のお前にその環境でやりきる能力はないから諦めろ。

**デフォルトの名無しさん** · 2022/02/16(水) 02:27:10.00

記念カキコ