Visual Studio 2019 Part6

2021/04/21(水) 23:27:05.12

!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512

Visual Studio 2019 の新機能
https://docs.microsoft.com/ja-jp/visualstudio/ide/whats-new-visual-studio-2019?view=vs-2019

The Visual Studio Blog
https://devblogs.microsoft.com/visualstudio/

リリースノート
https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes#

過去スレ
Visual Studio 2019
https://mevius.5ch.net/test/read.cgi/tech/1548765663/
Visual Studio 2019 Part2
https://mevius.5ch.net/test/read.cgi/tech/1562077164/
Visual Studio 2019 Part3
https://mevius.5ch.net/test/read.cgi/tech/1569978087/
Visual Studio 2019 Part4
https://mevius.5ch.net/test/read.cgi/tech/1585715794/

※前スレ
Visual Studio 2019 Part5
http://mevius.5ch.net/test/read.cgi/tech/1597722223/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2021/04/23(金) 13:08:35.59

Z80全盛時に8086憶えたけど
第一印象「オマエ、ソレハナイダロウ」だった

2021/04/23(金) 14:22:12.53

>>35
知らんがな。ｗ
そんな、クロックは今の数百分の一、キャッシュメモリもなかったような時代のことなんか。
提供する側ならともかく、提供される側が主張するようなことではない。

2021/04/23(金) 14:23:00.16

>>36
Z80のバンク切り替えよりマシやろ？ｗ

2021/04/23(金) 14:33:35.99

>>38
「Outportによる一部の領域のバンク切り替え」から
「CPUによる一般化されたバンク切り替え」に変わっただけという感じだった。
まだアドレスが、
　絶対アドレス = 上位16BIT * 65536 + 下位16BIT
だったら良かったのに、
　絶対アドレス = セグメント値 * 16 + 下位16BIT
という変な分け方がされていたのも最悪だった。

2021/04/23(金) 14:35:53.81

>>39
しかもセグメントレジスタが、汎用レジスタではなかったので
addなどの演算が直接的には出来なかったのも痛かった。

2021/04/23(金) 14:59:02.78

286/386はやってないっぽいな

2021/04/23(金) 16:08:27.34

>>39
> 　絶対アドレス = 上位16BIT * 65536 + 下位16BIT
それやるとページが64kB単位になるからページをまたがる処理がめっちゃ面倒になるぞ
今みたいに多少メモリーが無駄になってもいいやっていう時代ならいいけど物理メモリーにきちきち詰めていくとどうしても複数ページにまたがる領域ができてしまう

2021/04/23(金) 16:11:44.92

>>39
境界またがってアクセスするときに後者の方が便利だ(と当時は思われた)からだろう

2021/04/23(金) 16:32:30.16

>>42
現実にはアセンブラで書いた場合ですらそんな使い方が必要になる経験をしたことは無かったな。
Cで書いたらそういう機能はもっと不要。

2021/04/23(金) 16:51:18.22

8086のアドレスバスは20本(最大メモリ空間1MB)
16ビット長のレジスタでアドレス指定するためにセグメントレジスタで4bitシフトさせた上でオフセットと加算するという手法を採用した
8ビットCPU開発者からの移行を考えれば当時としては合理的な設計ではある

2021/04/23(金) 17:03:41.99

>>45
そうは思えなかったけどな。

2021/04/23(金) 17:20:02.93

CPU設計者はハードウェアよりで考えているのかも知れんが、
マシン語プログラミングを沢山経験積んだ一目線で見ると、
>>39 の前者の方になってる方が断然が使いやすかった。
8086よりマシン語が人気だったZ80は、ある意味では前者。
アドレスは、16BIT レジスタ HL, DE, BC, IX, IY に入れられるが、
HL は、8BIT レジスタの H と L が2つ組み合わさったもので、
HL = H * 256 + L
の関係が有った。
これは物凄く便利だった。

2021/04/23(金) 17:57:00.23

>>47
自分の理想としてのきれいさとかアドレスのわかりやすさにひっぱられすぎやろ。ｗ

実際には、セグメントレジスタをベースにしたら、実アドレスは忘れてオフセットで考えればよかったんだから、具体的にそんなにわかりにくいものでもない。

まあ、知らんけど。

2021/04/23(金) 18:04:08.66

>>48
マシン語には、せっかく carry flag という便利なものがあって、
16BIT レジスタを2つ使って 32BIT アドレスの足し算、引き算がとても
高速に出来る。例えば、DX:BX で 32BIT アドレスが表現できていたなら、
add BX,4
adc DX,0
のようにすれば、4バイト先のアドレスを 32BIT で正確に計算できる。
だから、ds:[BX] などとせずに、[DX:BX] と書くことが出来ていたなら、
物凄く便利だったはず。

2021/04/23(金) 18:21:57.89

アドレスが32ビットに拡張されたのはi386から
ページングと仮想記憶が導入されてやたら複雑化したけど

2021/04/23(金) 18:39:20.79

＞。ｗ

またこのアホが舞い戻ってきたか
知らない話題に首突っ込んで否定するだけの中身なしの阿呆

2021/04/23(金) 20:57:17.23

>>44
セグメントの考え方を理解してないだけじゃね？
セグメントはページとは違って論理的な領域でそれを物理アドレスの何処に置くかをセグメントレジスタで指定してるだけの話

>>49
> add BX,4
> adc DX,0
> のようにすれば、4バイト先のアドレスを 32BIT で正確に計算できる。
それ毎回やるの？
すげー遅くなるよ

2021/04/23(金) 22:38:27.09

>>51
「否定」？ｗ
ただの指摘やで？

「阿保」とか自己紹介もほどほどにな。

2021/04/23(金) 23:33:37.10

>[DX:BX] と書くことが出来ていたなら、物凄く便利だったはず。

これは判らんでもないが当時は貴重なレジスタがもったいない

2021/04/24(土) 00:27:28.34

VS2019スレで昔話するのやめてもらっても良いですか昭和生まれさん
プログラマー板でやれよ

2021/04/24(土) 02:20:23.22

>>52
>> add BX,4
>> adc DX,0
>> のようにすれば、4バイト先のアドレスを 32BIT で正確に計算できる。
>それ毎回やるの？
>すげー遅くなるよ
実際には、BYTE huge *ptr; に対し ptr += 4 を実行するともっと複雑な
例えば以下のようなコードにするしかなかった。もう少し高速なコードも
作れるかも知れないが、一番単純に書いた場合、
例えば、ES:BX が ptr に相当するとして、
xor cx,cx
add bx,4
adc cx,0
shl cx,12
mov ax,ES
add ax,cx
mov ES,ax

つまり、[DX:BX]方式なら2命令で済んでいたところが、SEG:[BX]方式しか使えなかった
8086は、7命令も必要となった。
だから、8086はZ80より設計が悪いとされた。

2021/04/24(土) 02:23:13.56

>>52
>セグメントの考え方を理解してないだけじゃね？
>セグメントはページとは違って論理的な領域でそれを物理アドレスの何処に置くかをセグメントレジスタで指定してるだけの話
むしろ、日本の中でも数人レベルで理解してると思ってるが。

2021/04/24(土) 02:25:11.37

>>54
その通りではあるが、それは霊で書いただけで、DXの変わりに
[DS:BX]や、[ES:BX]
と書けて、なおかつ、
adc DS,0 や adc ES,0
のような命令が有るだけでも大変喜ばれていたはず。

2021/04/24(土) 02:34:12.16

>>56
なお、8086は、shl reg16,imm という命令は無く、shl reg16,clを
使う必要があったのでさらに1命令増えて全体で8命令となる。短くしたいなら、
BYTE huge *ptrをES:[BX]でアドレッシングするとして、ESの下位12BITは
使わずに必ず0になっている約束にしておいて、
mov cl,4
mov ax,ES
rol ax,cl
add bx,4
adc ax,0
ror ax,cl
mov ES,ax
とすれば、7命令で済む。

2021/04/24(土) 02:40:55.43

>>54
なお、8086はバレルシフタが搭載されてなかったので、shl reg,clや
rol reg,cl, ror reg,cl 命令は、cl の回数だけCPUの中で実際に繰り返して
シフトやローテートを行っていたので、clに4を指定すると4*4=16
クロックほど必要だった。
だから、>>59 は7命令のように見えても、実際には、合計8回分の
ローテートを含んでいるので13命令を実行する程度の時間が掛かる
ことになる。
これが8086の設計の悪さである。

2021/04/24(土) 02:52:41.94

いつまで昔のアセンブラの話やってんの

2021/04/24(土) 03:05:41.82

>>61
8086系においての 16BITから32BITへの進化は 32BITから64BITへの進化
に比べて遥かに重要だったという事を知って欲しいため書いている。

2021/04/24(土) 03:22:04.75

>>62
アーキテクチャの話なら286のプロテクトモードの話
すっ飛ばして何の意味があるのかね？

2021/04/24(土) 08:41:08.49

>>56
いや、セグメントなら領域のサイズが64KB以内とわかってるならそんな計算は不要
ページだと小さいサイズであってもページまたがりを考慮しないとダメだから常に
> add BX,4
> adc DX,0
が必要になるって話

>>57
> むしろ、日本の中でも数人レベルで理解してると思ってるが。
数人レベルで誤解してるの間違いだろw

2021/04/24(土) 09:45:37.22

あー、もしかして8086のセグメントと286以後のセグメントを混同してるのかな

2021/04/24(土) 09:51:46.26

zobがこの間、技術書展(4?)で薄い本出して
いただろ。
数人しか理解してないなんてマウントの
材料にするような話では無いな

2021/04/24(土) 11:23:46.98

>>64
+1

2021/04/24(土) 11:49:50.37

>>57
> 日本の中でも数人レベル
あー、そういうおひとの書き込みななんか。ｗ
もうマジメに相手しないほうがええな。

2021/04/24(土) 11:57:51.43

アセンブラ談義したいなら過疎ってるしここでやれよ

アセンブラ 13
https://mevius.5ch.net/test/read.cgi/tech/1314512680/

2021/04/24(土) 14:54:47.34

>>64
馬鹿？

2021/04/24(土) 14:57:46.77

>>30
アドイン？

2021/04/24(土) 15:02:37.62

>>70
スレ違いという意味なら甘んじて受けるわ

2021/04/24(土) 22:51:22.11

なになに、またアセンブラは不要君が暴れてるの？

2021/04/24(土) 22:58:35.21

アッセンブルEX-10の話題なら良いよ

2021/04/24(土) 23:02:25.75

子供のころにアセンブラの経験をしてない平成生まれはかわいそうだがプログラマに向いてない。
Java連呼してる奴もそうだろう。あんな糞言語にあっさり洗脳されるなんて。

2021/04/24(土) 23:08:22.13

はいNG

2021/04/24(土) 23:40:18.11

出たわね

2021/04/24(土) 23:45:35.60

これだけは言える。Java使いは低能ばかり。
そもそも一番Javaの普及に貢献したMSとgoogleを訴えまくってJavaから撤退させたアホ集団。

2021/04/25(日) 00:03:30.26

>>78
Sun/Oracleのゴールは、Javaの普及やないんやろ。
それはそれで一理。

まあ、今から考えると、あんなものが普及しなくてよかった。ｗ

2021/04/25(日) 00:14:57.25

>>69
そこキチが住み着いてるやん…

2021/04/25(日) 01:35:20.50

わりとまじめに聞いたいんだが
キチが住みついてないスレって、あるのか？

2021/04/25(日) 02:05:44.56

SQL Server 2019 Developer
https://i.imgur.com/qkBZfN4.png

Azure DevOps Server 2020 Express
https://i.imgur.com/FE8YCUs.png

2021/04/25(日) 06:04:38.72

>>81
キチにもレベルっつーもんがあると思うんだ…

2021/04/25(日) 09:11:09.05

アセンブラ界の沼は深いぞ
日本で屈指のレベルとか自称するような奴はまだ沼にたどり着いてすら居ない

2021/04/25(日) 11:32:59.28

google,ms
これからはrust推しでいくよー

google→androidのコードをrust化
ms→vsにrustは入れません！

いつも口だけで何もやらないマイクロソフト

2021/04/25(日) 12:12:47.53

>>85
それは短絡的だろ
googleが自分らが入れるから
msより自分らを優遇して欲しいって
交渉しないわけがないんだよ
そうなるとmsサイドとしてもえーってなっちゃうじゃん
こういうのってそういうものよ

2021/04/25(日) 12:32:03.77

>>85
だからこその後方互換性の高さっつーのもあるやろ。
vscodeからでええんや！

2021/04/25(日) 12:36:51.86

GoogleだってAndroidよアプリ開発にRustが使える訳でもないし
そもそもRustはまずRust for Windowsが安定化しないとわざわざVisual Studioでインストールできるようにする必要性もない

2021/04/25(日) 12:37:51.40

>>88
タイポ
Androidよ→Androidの

2021/04/25(日) 15:19:56.74

>>85
わざわざ既存のコミュニティを壊しにかかるとしたらそれこそアホやろ

2021/04/25(日) 16:16:48.21

MSはすでにカーネルの一部をrustで書いてるとかゆーのどこかで読んだ気がしたけど

2021/04/25(日) 16:38:38.24

>>86
>googleが自分らが入れるから
>msより自分らを優遇して欲しいって
>交渉しないわけがないんだよ
>そうなるとmsサイドとしてもえーってなっちゃうじゃん

ここ、意味が分からない。
優遇って、誰がだれを優遇するの？

2021/04/25(日) 22:10:26.97

どのプロジェクトにも頭がおかしい奴がいて勝手にマイナー言語使ってドヤ顔するアホがいる。
それをもってMSはJava押しだのrust押しだの言い出すバカがいるから困る。

2021/04/25(日) 22:34:33.49

いや、でもRustはホントによさそうなんだよなあ。。。

ためしにcargoをインストールしてみ？

2021/04/26(月) 00:59:45.57

rustをマイナー言語とか言ってる時点で注意せんともう化石状態やで

2021/04/26(月) 05:20:03.42

https://docs.microsoft.com/ja-jp/learn/paths/rust-first-steps/

2021/04/27(火) 18:17:13.82

アップデートで勝手にアジュールインストールするなよ。

2021/04/27(火) 18:25:30.16

何か追加されたっけ？

**デフォルトの名無しさん** (ｽﾌｯ Sd94-n3U+) · 2021/04/27(火) 18:45:39.46

Azureってインストールするようなものなの？

2021/04/27(火) 18:46:39.39

アズールって読んでたわ

2021/04/27(火) 19:53:22.79

>>100
公式セミナー出た事無いね！

貴方には人脈が足りないわ

2021/04/27(火) 20:47:50.73

サーバは手元にあるのが一番

2021/04/27(火) 20:58:28.03

IIS (Web Server)
SQL Server
DevOps Server

Visual Studio関係で手元に置いておくならこれくらいか

2021/04/27(火) 21:00:33.99

アジャーって読んでたわ

**デフォルトの名無しさん** (ｽﾌｯ Sd94-n3U+) · 2021/04/27(火) 21:58:39.86

Azure出始めの時は日本MSの人が英語読みでアジュアって言ってたけどしばらくしてアジュールになったね

2021/04/28(水) 07:07:58.29

俺アズレって読んでた

2021/04/28(水) 07:52:32.27

https://azure.microsoft.com/ja-jp/pricing/member-offers/credit-for-visual-studio-subscribers/

2021/05/02(日) 20:34:40.73

C++で実装して、Windows10 64bit用のDLLや実行形式exeをビルドする場合、
どのバージョンのVisual Studioを使うのが効率的で確実なんだろ？
2019？それとももっと古いVSの方がいいのかな？
新しいバージョン恐怖症なもんでｗ

2021/05/02(日) 20:48:03.77

>>108
VCランタイムが2015,2017,2019で共通になって(2019のアップデートに伴い)頻繁に更新されるから
古いバージョンを使うことによるライブラリが原則更新されないというメリットがなくなった

2021/05/02(日) 21:07:13.59

>>109
早速ありがとう。
実は、VC++2005で【ヒープ割り当て→計算、描画処理→ヒープ解放】を繰り返し行う、.DLL＋.exe を実装してるんだけど、
その .exe+.DLL をWindows10 - 64bitで走らせると：

１）VC++2005、Debug Win32ビルド　→　問題なし。exe起動後、【ヒープ割り当て→計算、描画処理→ヒープ解放】を何回でも反復できる。
２）VC++2005、Release Win32ビルド　→　exe起動後、【ヒープ割り当て→計算、描画処理→ヒープ解放】を100回繰り返したあたりで、固まる。エラーは出ない。VC++をプロセスにアタッチしてデバッグすると、無限ループに陥っている模様。
３）VC++2005、Release x64ビルド　→　上の２）に同じ
４）VC++2005、Release x64ビルドの.slnを、VC++2005の「デバッグ開始(F5)」から実行する　→　１）と同じく問題なし。
５）VC++2005、Release x64ビルドの.exeを「Windows 7の互換モード」で実行する　→　１）と同じく問題なし。

てな具合で、Windows10主流の今、大概VC++2005も潮時かなｗって思ってるｗｗｗ
それとも俺のプログラムにどこかエラーがあるのかな？！
_DEBUGディレクティブ周りは何回も見直したんだけどなぁ。

2021/05/03(月) 02:28:18.09

>>109
マジですか
MBCS関連のライブラリ不具合が放置されてた件は、不具合があるまま更新されちゃうってこと？
例えばこの件とか
https://social.msdn.microsoft.com/Forums/ja-JP/74a82359-39bc-47ca-bb39-7f0d1478f5a1/vs2015mbcs12391splitpath123912599123383210151230034920123011236420?forum=vcgeneralja

>108と同じく、新しいバージョン恐怖症（というか不具合発覚して戻したことある）なので
vs2019使いながらビルドで古いバージョンのライブラリ使ってるんだけど、
個人的にvs2019のアプデを放置してる現在、アプデすると死亡する可能性があると思うとガクブルなんですが

2021/05/03(月) 02:48:32.26

その問題を逆手に取ってシステム攻撃可能なコードにでもしたらセキュリティの問題として修正せざるを得ないんじゃない？w

2021/05/03(月) 03:25:09.58

>>110
おまえのエラーであるほうに賭ける！

でも、コンパイラの不具合もたしかにあるからなあ。ｗ

2021/05/03(月) 03:56:06.92

>>111
自己レス
よくよく思い出せば、自分が問題を確認した時のバージョンはvs2017だったからvs2013に戻してた
という経緯だったので、>109そのまま受け取れば個人的には問題無さそう
というか、vs2013とvs2015の間に壁があるのかな？

>>110
とりあえずvsのバージョン変えてテストしてみればいいと思う

**デフォルトの名無しさん** (ｽﾌｯ Sdff-qWuH) · 2021/05/03(月) 09:37:00.71

>>110
それ単純に2005だからじゃないの

2021/05/03(月) 12:01:12.56

>>110
なにやら騒がせてしまったが、無限ループに陥った原因は、どうやら俺のプログラムミスだったっぽい。
ビルド方法や実行方法や互換モードの違いで、プログラム挙動が変化する理由は不明だけど。
またおとなしくROMってるわｗ

結論：

　ま　だ　ま　だ　VC++2005　は　い　け　る　！　！　！

2021/05/04(火) 12:48:40.66

>>108
VS2019を入れれば問題無い
ちなみにインストールするときにオプションで
VC2017コンパイラとかインクルードファイルとかライブラリとかの環境も
それ以前のも一緒に入れるとか選べる
あとでbuild環境を選択すれば良い

2021/05/04(火) 12:52:44.55

>>110
>>116
概出だから知ってるだろうけど
デバッグモードだけ成功するパターンは
初期化し忘れとかヌルポとかが多い

2021/05/04(火) 15:25:08.43

visual studio code を使い始めたのですが、固まることが多く使い物になっていません。
推奨スペックを教えていただけないでしょうか？
メモリ４Gではダメでしょうか？

2021/05/04(火) 15:28:53.20

>>119
4Gで固まるんだ
開発するなら8Gはあったほうが良いかと
今時のPCならそんなに問題起きないけど結構古いPC使ってない？

2021/05/04(火) 16:57:10.50

>>119
環境を書かないで、vs codeが使いやすいという人が多くて混乱するよね。
ggってもどのくらいのスペックでまともに使えるかの情報が出てこない。
例えばYouTubeで動作してる動画があったとしても、まず環境が書いてない。
Androidエミュレーターでもそうだ。試して見ると極端に遅いのになぜかYouTubeでは
高速に動いてる動画があり、環境は書いてない。スパコン上のLinuxで
Wineエミュレーター上でAndroidエミュレーターを動作させている可能性すらある。

2021/05/04(火) 18:00:41.13

Ruby on Rails, WSL2, Docker Compose, Node.js,
VSCode(拡張機能・Remote WSL, Remote Container)

今は未経験者でも、こういう技術。
10年以上のプロよりも、技術力は上！

メモリの最低ラインが、Windows 10 で16GB、Mac で32GB。
Windows でも、32GB あった方が良い

メモリ8GB じゃ、Windows/Linux, Docker, Rails、データベースを動かすのは、キツイ

2021/05/04(火) 18:20:51.47

ここはvscodeのスレじゃないのでどっちにしろスレチ

2021/05/04(火) 18:51:17.07

120<<< 中古です
東芝ダイナブック　satellite pro 550Bです。

2021/05/04(火) 21:22:34.27

>>117
ありがとう。VS2019も検討してみる。

>>118
ヌルポインタやらかした場合、そのポインタのメンバに触った瞬間に実行時エラーにならないこともあるんかな？！

>>110は何とか解決して、今はVC++2005のReleaseビルドでも、Win10上でヒープ割り当て→処理→ヒープ解放を何回でも反復できるようになった。
無限ループが発生しないように、問題のループを実装から取り除く改修を行って解決した！

2021/05/04(火) 22:44:58.60

>>119 >>121
公式ドキュメントくらい読めよ
ドキュメント類を読まない輩は論外

2021/05/04(火) 22:50:39.27

Visual Studio Code / VSCode Part10
https://mevius.5ch.net/test/read.cgi/tech/1616255273/

2021/05/05(水) 14:06:46.62

>>126
ADPの人？

2021/05/05(水) 14:39:00.30

>>128
ADHDだよ

2021/05/06(木) 04:05:33.16

自作のミニツールをプロジェクトごと公開したい場合、削除しておくべき不要なファイルって何があります？

2021/05/06(木) 04:15:15.20

必要なもの以外すべて。
ソリューションファイル、プロジェクトファイル、ソースファイル、リソースファイル以外。

つーか、必要最低限そうなファイルだけcommitして、それをexportして、もしビルドに失敗したら足りないファイルを追加して、を繰り返せば。

2021/05/06(木) 04:21:42.34

visual studioがデフォルトで生成する.gitignoreに従えば大抵は事足りるでしょ

2021/05/06(木) 12:09:09.61

よほど特殊なライブラリとか使ってるんじゃなければ
自分で作ったヘッダとソースとリソースだけあればOK
ソリューションとかプロジェクトは新規で突っ込んでも逝ける状態のが理想的でクリーンな公開

2021/05/06(木) 13:24:29.11

>>133
やりすぎ。

2021/05/06(木) 17:08:57.31

新規ソリューションのデフォルトフォルダってsorce\repos\ソリューションフォルダだと思うだけどさ、このreposって何か意味あるのかな？
sorce直下にソリューションフォルダ置くのと変わらなくない？
repos直下をgitのルートにすることを想定してんのかな？