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/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のルートにすることを想定してんのかな？

2021/05/06(木) 17:33:00.43

>>135
reposはリポジトリの複数形なんだからreposのサブフォルダーがgitのルートになるんだよ

2021/05/06(木) 17:51:39.05

source直下はreposしかないって事だよね？
sourceかreposいらなくね？　片方でよくね？　無駄に階層深くなってるだけの気がするんだけど
何か他に、sourceに置くことが想定されるファイルあるの？

2021/05/08(土) 00:06:50.96

ああVslsFileSystemProviderVSCorePackageのエラーうぜぇ。なんで直すのが16.10なんだよ。

2021/05/08(土) 11:53:30.03

16.10 次の水曜日には出るんじゃない？

2021/05/08(土) 17:13:25.44

来週なの？意外と早いね。16.8が11月で16.9が3月だからまだ先だと思ってた。

2021/05/08(土) 19:55:57.00

XBOXコントローラーでVisual Studioを操作したいです

2021/05/08(土) 20:45:14.83

構わんよ、遠慮せず操作したまえ

2021/05/08(土) 21:50:54.02

Visual Studio 最新版 (16.9.4)
C++で new char[サイズ(即値)] と書くと
サイズの上位32bitが消されて正しくアロケート出来ない
たとえば、new char[0x100000000ll] とやると new が 0 バイトで呼ばれる

おま環？

2021/05/08(土) 23:25:45.23

std::size_tにキャストされているからでは。

2021/05/08(土) 23:51:34.29

64bit環境なのでsize_tも64bitです。

uint64_t size = 0x100000000ull;
new char[size];
とやっても同じで、
コンパイラ上定数として扱える場合には上位がカットされ、
サイズが変数やテーブル参照のような場合には正しくアロケートされるようです。

以下コンパイル結果
--------
char* data_ = new char[0x100000000];
00007FF63F38310D xor ecx,ecx
00007FF63F38310F call operator new[] (07FF63F3811E5h)
--------
char* data_ = new char[0x110000000];
00007FF66238310D mov ecx,10000000h
00007FF662383112 call operator new[] (07FF6623811E5h)
--------

2021/05/09(日) 00:08:02.90

operator new()ならどうなる？

個人的には、配列要素数に32ビット制限があっても、そんなにおかしいとは思わんなあ。

2021/05/09(日) 00:21:06.52

operator new, operator new[] だと大丈夫

--------
char* data_ = (char*)operator new(0x100000000);
00007FF70520310D mov rcx,100000000h
00007FF705203117 call operator new (07FF705201046h)
--------
char* data_ = (char*)operator new[](0x100000000);
00007FF7CA02310D mov rcx,100000000h
00007FF7CA023117 call operator new[] (07FF7CA0211E5h)

2021/05/09(日) 00:54:34.36

コンパイラのバグ(仕様？)なのかなぁ
ツールセットをLLVMに変えると配列でもrcxレジスタを使うね

2021/05/09(日) 01:00:23.52

やっぱそうか。
じゃあコンパイラが期待する配列添字定数の型が32ビットなんやろ。

VCはintきめうちのところがときどきあるような。
今は知らんけど、昔はenumがそうだった。

2021/05/09(日) 08:14:59.02

6.7.2.2 Enumeration specifiers
3 The identifiers in an enumerator list are declared as constants that have type int and may appear wherever such are permitted.

6.7.2.2 列挙型指定子
意味規則　列挙子並びの中の識別子は，型int をもつ定数として宣言され，この型の定数が許されるところならばどこに現れてもよい。

はっきり、intと書いてある

2021/05/09(日) 10:37:55.18

今のVSにはclang-clが提供されているけど、これでカバレッジとれている人いないかな？
--coverage 付けて clang_rt.profile リンクしてビルドまではできたんだけど、実行すると
終了時にexit()の中で例外を吐いてしまう。

2021/05/09(日) 11:06:11.78

>>150
Cの話は関係ない。

2021/05/09(日) 13:41:37.14

コンパイルオプションを晒すべき

2021/05/10(月) 11:41:19.26

> 昔はenumがそうだった。
> Cの話は関係ない。

何の話？

2021/05/10(月) 12:23:27.91

>>154
そらC++やろ。
Cとは意外に違うんやで？

2021/05/10(月) 12:32:08.82

C++/CLIがいらんことしやがって
enum class なんてものが

2021/05/10(月) 12:38:07.54

>>140
それ書いた時、なんで来週と思ったか思い出せないんだけどw
多分16.5(2020.3/16)と16.6(2020.5/12)の間が2ヶ月だったからかな
でもリリース周期見ると必ずしも期間決まってるわけじゃないみたいだから、今週かわからんわ
先に謝っとく。ごめんw

16.0 2019.4/2
16.0.22 2020.1/22
16.1 2019.5/21
16.1.6 2019.7/9
16.2 2019.7/24
16.2.5 2019.9/10
16.3 2019.9/23
16.3.10 2019.11/10
16.4 2019.12/3
16.4.21 2021.4/13
16.5 2020.3/16
16.5.5 2020.5/12
16.6 2020.5/19
16.6.4 2020.7/14
16.7 2020.8/5
16.7.14 2021.4/13
16.8 2020.11/10
16.8.7 2021.3/9
16.9 2021.3/2
16.9.4 2021.4/13

2021/05/10(月) 13:47:44.37

>>156
enum classはC++11以降でも実装されてるけど

2021/05/10(月) 14:04:21.68

>>158
？その仕様の元がCLIなんだが？

前後の繋がりが読めない人？

**デフォルトの名無しさん** (ｽﾌｯ Sd8a-kakT) · 2021/05/10(月) 16:00:29.21

>>159
人に伝わる文章書けよ

2021/05/10(月) 16:17:34.07

お母さんに教えて貰え

2021/05/10(月) 17:08:17.00

>>145
「00007FF63F38310D xor ecx,ecx
　00007FF63F38310F call operator new[] (07FF63F3811E5h)」
ここが既におかしい。64BITアプリなら、ecx ではなく rcx でなくてはならない。
147 の方は実際にそうなっている。
ecxは32BITレジスタ、rcxは64BITレジスタ。
また、ecxやrcxは、メンバ関数の関数呼び出しに置いてはthisの値を入れるために使われるレジスタ。
なので、前者のnewは32BIT版が呼び出されていて個本的におかしい。
本当に何もかもが64BIT版になってるか点検すべき。

2021/05/10(月) 17:12:25.84

>>162
ただし、new char[N] の変わりに operator new[N] とすると正しくなっているのは良く分からない現象。
コンパイラオプションに問題が有るか、または、コンパイラのバグ。

2021/05/10(月) 17:52:35.89

>>145
https://stackoverflow.com/questions/19803162/array-size-error-x64-process

const uint64_t size = 0x100000000ull;
new char[size];
のように
変数sizeにconstキーワードが付いているとそうなってしまうが、constを取り除くといけると書いてある。

2021/05/10(月) 17:54:16.98

>>164
以下のように、配列サイズがコンパイル時定数にされてしまうのを無理やり防ぐといけるらしい：

extern size_t GetArraySize();

int main()
{
size_t allocationsize = GetArraySize();

char *cp = new char[allocationsize];
return 0;
}

size_t GetArraySize()
{
// compile time assert to validate that size_t can hold a 64-bit value
char compile_time_assert_64_bit[(sizeof(size_t) == 8)?1:-1];

size_t allocsize = 0x100000000UL; // 64-bit literal

return allocsize;
}

2021/05/10(月) 18:14:13.53

>>145
00007FF66238310D mov ecx,10000000h
00007FF662383112 call operator new[] (07FF6623811E5h)

147
char* data_ = (char*)operator new[](0x100000000);
00007FF7CA02310D mov rcx,100000000h
00007FF7CA023117 call operator new[] (07FF7CA0211E5h)

よく見ると、これら二つで、call文の呼び出し先のアドレスの下位16BIT
は、共に11E5 になっていて、上位アドレスは変わっているが本当は
同じ関数を呼び出しているようだ。リンクするとアドレスは上位も下位も変わることがあるが、
上位アドレスだけ変わる現象としてはセキュリティー対策のためと聞いている。
それで、mov 文が ecx と rcx の違いがあるが、実は mov ecx,imm 命令は
上位32BITが0拡張されるので mov ecx,10000000h は、
実際には、mov rcx,0 と同じなので、145の方は、動作的には
mov rcx,0
call operator new[] // 64BIT 版の new 演算子
となっていて、145もちゃんと 64BIT版の new 演算子が呼び出されているようだ。
問題は、new char[x]のxに定数が有ったときに下位32BITだけに切り捨てられてしまう
コンパイラの動作にあるようだ。

2021/05/10(月) 18:31:03.35

VS2010からのバグですか
早く直してください

>>147
コール元が原因だとわかるようにコンパイル結果を貼ったつもりだったんですが...
そもそも64bitアプリから32bitコードはコールできない

2021/05/10(月) 19:17:39.46

>>156
それ以前は、真面目なソースでは重複事故防止のために、わざわざ全要素にenum型名をつけてたからな。
最初からそうなっていてよかったレベルに、もっともな改善だった。

2021/05/10(月) 19:26:30.24

>>168
つ namespace

2021/05/10(月) 19:27:03.10

>>166
訂正。桁が大きすぎて1ケタ見間違えた：

上位32BITが0拡張されるので mov ecx,10000000h は、
実際には、mov rcx,10000000h と同じなので、145の方は、動作的には
mov rcx,10000000h
call operator new[] // 64BIT 版の new 演算子

そして、xor ecx,ecx の方が xor rcx,rcx になり rcx = 0 となる。

2021/05/10(月) 19:45:11.41

>>169
enum毎にnamespace?
お前アホだろw

2021/05/10(月) 20:23:12.80

>>170
リンク先を見つけて頂いて非常に感謝いたします。
それ以外の事は既に知っていますので大丈夫です。

2021/05/10(月) 21:40:04.54

新機能が無いと管理出来ませんって
プークスクス向いて無いんじゃね？

2021/05/10(月) 23:54:56.33

>>173
K&R Cでも使っとれ！

2021/05/11(火) 06:54:08.95

それを言うならBでしょ
ケントンプソンの

2021/05/11(火) 08:58:15.27

K&Rにenumは無いが？bakaかね

2021/05/11(火) 09:43:42.39

>>176
新機能がないと管理できないの？ｗ
バカなの？ｗ

2021/05/11(火) 20:43:13.86

baka vs バカ vs アホ

2021/05/12(水) 13:58:01.63

Visual Studio 2019 version 16.9.5
https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes#16.9.5

2021/05/12(水) 14:38:01.97

/std:c++20 ｺﾈ━━━━━('A`)━━━━━━!!!!

2021/05/13(木) 21:22:57.09

Visual Studio 2021 はまだかよ？
もうはよ出せよ

オフラインインストールだから中途半端なバージョンはインストールしたくねぇ