Visual Studio 2019

2019/01/29(火) 21:41:03.68

!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
↑冒頭にコレを三行重ねてスレ立てしておくこと

Visual Studio 2019 Preview
https://visualstudio.microsoft.com/ja/vs/preview/

The Visual Studio Blog
https://blogs.msdn.microsoft.com/visualstudio/

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

2019/05/01(水) 21:25:54.58

>>329
ネイティブC++ならまだしもC++/CLIとの比較でそんなこと言ってるなら単なるアホだぞw

2019/05/01(水) 21:27:19.50

Microsoft、新元号“令和”対応のWindowsパッチを配信開始
オプション扱い、連休前の適用はトラブルに注意
https://forest.watch.impress.co.jp/docs/news/1182431.html

2019/05/01(水) 21:43:11.40

>>330
C++/CLIの最大の利点はnativeコードと容易に混在できる点だね。
パフォーマンスが重要な部分はnativeで記述すればよい。

2019/05/01(水) 21:49:45.21

境界を超えるコストが大きいから大抵のケースではかえって遅くなるよ
それを無視できるほど纏まった処理なら別プロセスでいいし

2019/05/01(水) 22:03:21.31

「かえって遅くなる」なんてのはそもそも設計が間違ってるだろ。

>それを無視できるほど纏まった処理なら別プロセスでいいし

それをIPCとか面倒なことをせずに容易に呼べるのが最大のメリットだと書いた。

2019/05/01(水) 23:30:59.54

C++/CLIとか10年ぶりに聞いたくらい忘れ去ってたわ

2019/05/02(木) 01:32:24.08

インテリセンスが不完全で色々諦めた思い出

2019/05/02(木) 07:16:31.35

>>336
> インテリセンスが不完全
俺もこれでMSのやる気のなさを感じて触れないようにしてた

2019/05/02(木) 07:32:40.14

今のインテリセンスはいいよ。

2019/05/02(木) 07:50:53.21

C++の拡張言語という無茶ぶりを受けたためにC++/CLIとC++/CXで二度の敗北を喫したHarb Sutter…
いや本人が好きでやってんのかも知らんけど

ちゅーかC++/WinRTもなんだ、あれは正気か
メタデータから純粋なC++ラッパーを生成するのはいい、そこは筋が良いと思う
だがWinRTクラス生成するのにこのご時世にIDLファイル書かせるのは噴飯もの

2019/05/02(木) 09:36:36.51

>>309
これを入れると元号表示が
”平成３１”は”令和元年”と出るのか？

2019/05/02(木) 09:54:08.06

framework変わらんと無理でしょ

2019/05/02(木) 09:58:33.55

>>341
そうなのか。
なぜMSは５月１日までに新元号対応したframeworkの改良版を出さなかったの？

2019/05/02(木) 10:08:47.43

783 名無し~3.EXE sage 2019/04/23(火) 10:20:57.13 ID:kLvuOR3d
.NET Framework 用の日本の新元号対応更新プログラムの概要
https://support.microsoft.com/ja-jp/help/4477957/new-japanese-era-updates-for-net-framework

2019/05/02(木) 10:14:42.67

>>342
プログラムを作って確認したら、平成31年5月2日って出たww

令和対応の更新プログラムの配信は既に開始されているけど
オレの所には未だ来てないな

**デフォルトの名無しさん** (ｽﾌｯ Sd02-9/XU) · 2019/05/02(木) 10:36:56.42

Wnsows のアップデートが済んでれば
.net framework でなにもする必要ないはずなんだが。

2019/05/02(木) 10:38:42.74

CLIだのCXだのいらんからMFCを全部今風に書き直して復活してほしいね

2019/05/02(木) 10:40:34.86

>>343
今それ入れてみたが
令和は出ないぞ。なんで？

2019/05/02(木) 10:57:14.79

>>345
元号レジストリを見てるんだな

2019/05/02(木) 10:59:59.72

組み込み系のCのソースを単体デバッグする時に、win32とかMFCが重宝するんだが、UI周りの機能が退化して貧弱になってないかこれ。

2019/05/02(木) 11:33:28.30

>>349
C++/CLIを使えば?

2019/05/02(木) 11:59:57.06

平成 31/04/30
令和 01/05/01
確認ok

2019/05/02(木) 18:00:19.94

>>331
なんで 1809 が一番後回しなんだω

2019/05/02(木) 18:29:24.96

>>352
やっと1809用が公開されたみたい
https://support.microsoft.com/en-us/help/4501835

2019/05/04(土) 15:12:44.39

>>353
オレのところにもやっと飛んできて令和ってでるようになった

2019/05/05(日) 09:06:16.39

http://codepad.org/Lmj9mr9X
↑
これの結果が、実行する度毎に毎回違うんだけど、何で？

2019/05/05(日) 09:16:02.00

Pを何だと思って使ってるんだ？

2019/05/05(日) 10:04:27.36

コンパイル通るのか?

2019/05/05(日) 11:21:36.69

コンパイラは、警告出して通すのかな？？

何をやりたいのか見えないので、答えが出ない。
トレース機能を何回か繰り返して、動作確認するしかない。

2019/05/05(日) 11:27:56.31

何をやりたいかは目いっぱいメモリ確保してみたい！じゃないの？

2019/05/05(日) 11:34:43.76

&pの値によって結果は変わるだろうな

2019/05/05(日) 11:52:42.29

>>360
なぜそう思った？
pの初期値はNULLでなきゃ何でもいいし、そもそも
do {
s <<= 1;
free(p = malloc(s));
} while(p);
ってやれば初期値も不要

2019/05/05(日) 12:24:38.68

>>361
>pの初期値はNULLでなきゃ何でもいいし

null来てんじゃないの?

2019/05/05(日) 12:52:50.65

>>361
確保する領域サイズが０の場合はどうなのかな？
確保する領域がなければ、実アドレス返す必要無いし
解放する必要も無い。

2019/05/05(日) 13:23:07.18

やってみた
「初期化されていないメモリpを使用しています」とエディタには出るけどビルドでは何も言われない

毎回変わるのはpの初期値とmallocの戻りが不定だからだと思うけど
64bitでビルドすると実行が終わらんね…

2019/05/05(日) 13:44:34.56

>>363
サイズが0でもエラーでなきゃ非NULLが返るはず

>>362
初期値の話な

2019/05/05(日) 14:04:10.88

>>365
だから最初から初期値って言ってるでしょーにw

2019/05/05(日) 14:06:03.21

malloc しても実際に割り当てられたか
どうかはOS or ランタイムしか知らないので
memset かcalloc で書き込み推奨

2019/05/05(日) 14:50:29.24

>>366
？？？
初期値にNULLが来てるとかどこの話だ？

2019/05/05(日) 17:37:07.28

#include <stdio.h>
#define WIN32_LEAN_AND_MEAN
#include <Windows.h>

int main()
{
HANDLE hHeap = GetProcessHeap();
void* p = HeapAlloc(hHeap, 0, 1);
printf("GetProcessHeap(): %p\n", hHeap);
printf("HeapAlloc(1): %p\n", p);
}

この結果が毎回異なることを確認してみ。

https://www.blackhat.com/docs/us-16/materials/us-16-Yason-Windows-10-Segment-Heap-Internals-wp.pdf

端的に言えば、（ヒープの）ASLR がかかっているから。

2019/05/05(日) 17:49:08.68

なお、予期しない最終結果になった原因を探るなら、途中経過のどこで予期しない現象が発生したのかを探らなければならない。
この場合は p の経過を見てみるとよかったであろう（実は最初の malloc から p の値が違う）。

2019/05/05(日) 18:03:40.90

なんでいきなりASLRとか言い出したんだ？

2019/05/06(月) 12:30:49.46

> サイズが0でもエラーでなきゃ非NULLが返るはず

これはoperator newとmallocの挙動の相違だったはず

2019/05/07(火) 07:24:16.80

Introducing .NET 5
https://devblogs.microsoft.com/dotnet/introducing-net-5/

ポイント：
・.NET 5 が 2020年11月にリリース予定
・.NET Framework と .NET Core の二系統を一本化へ
・毎年11月にメジャーバージョンをリリース
・Windows Forms とか WPF は引き続きWindowsのみ

って感じかな？

毎年メジャーバージョンとかまた面倒だな

2019/05/07(火) 07:42:14.85

>>373
でもLTSの間隔は毎年じゃないっしょ

2019/05/07(火) 08:22:36.98

>>373
Windows10は実質、半年でメジャーバージョンアップでしょ

2019/05/08(水) 11:44:09.23

コードの検索範囲に現在のブロックってのが追加されてるね。めちゃくちゃ助かったわ

2019/05/08(水) 12:04:21.96

よろこんでいただけてこちらも嬉しいです

2019/05/08(水) 12:10:26.84

>>373
.NET Frameworkは4.8で終了の間違いでは？

2019/05/08(水) 14:16:23.26

Visual Studio Onlineっていくらになるんだろ？
てか、前にも同じ名前のサービスを見たような気もするけど別もんなのか？

2019/05/08(水) 14:19:44.36

>>379
http://ufcpp.net/blog/2019/5/build2019/
> ALM とか Team Services とか DevOps とか呼ばれてるやつの名称が「Visual Studio Online」だった時期がある
前の同名サービスとは別物

2019/05/08(水) 14:42:26.16

.Net5 ってネーミングセンスなさすぎ。
絶対混乱するだろ。紛らわしいわ。

2019/05/08(水) 14:56:31.44

ホント、.NET Core5 で良かったのに

2019/05/08(水) 19:59:28.53

どう混乱すんの？

2019/05/08(水) 20:05:29.04

>>383
.NET4の後継でCoreじゃないように見える。
事情を知ってる昔の人はいいけど、新規開発者は混乱する。
上に出てたVisualStudioOnlineもそう。
過去に使ったサービス名を違うサービスに流用するからご新規さんは検索したときに両方出てきて混乱する。
MSはネーミングセンスがなさすぎ。

2019/05/08(水) 20:13:35.60

>>383
.NET Frameworkが消えて.NET Coreに統合でそ

2019/05/08(水) 20:19:45.23

むしろシンプルで混乱の芽を摘んだ。MSグッジョブっておもたわ

2019/05/08(水) 20:54:22.98

Framework 5は出さないしCoreの流れで.NETは一本化するので
Coreという単語で差別化する必要も無く余計だから無くすってことみたいだね
混乱するのは半端に知ってるベテランの方でしょうな

VS Online命名はやっぱコイツらバカだろ、みたいな感想

2019/05/08(水) 20:58:37.32

>>384
新規開発者の方が混乱しないやろ

2019/05/08(水) 21:19:44.41

>>387
ゲームみたいだよね

2019/05/08(水) 21:57:16.18

なんだよOnlineってCommunityなくなるのかと思ったぜ
紛らわしいからVisualStudio.htmlにでも改名しろよ

2019/05/08(水) 22:08:57.26

Windows Forms / WPF なくすわけでもないから
.NET Framework がなくなるって言い方はどうかな・・・。

APIがそろってきたから一本化ってだけでしょ。

2019/05/08(水) 23:01:10.01

VB6だってまだ消えてない
そういうこと

2019/05/09(木) 03:32:35.31

ここまで生き残ったんだからVB6もメンテしてよ

2019/05/09(木) 05:23:43.62

むしろとどめを

2019/05/09(木) 06:12:22.58

>>394
大賛成!

2019/05/09(木) 07:57:54.86

VB6はもういいだろww

2019/05/09(木) 08:11:19.88

一番抹殺したいと思ってるのはMS

2019/05/09(木) 10:23:54.96

VB2C#コンバータをバンドルしなきゃ

2019/05/09(木) 10:44:20.03

VBAもC#で書けるようになればいいのに。

**デフォルトの名無しさん** (ｽﾌｯ Sdbf-rNgt) · 2019/05/09(木) 11:48:38.60

それもうVBAとちゃうから

2019/05/09(木) 12:06:09.74

Visual Studio による Office および SharePoint 開発
https://docs.microsoft.com/ja-jp/visualstudio/vsto/office-and-sharepoint-development-in-visual-studio?view=vs-2019

Roadmap for Apps for Office, VSTO, and VBA
https://blogs.msdn.microsoft.com/officeapps/2013/06/18/roadmap-for-apps-for-office-vsto-and-vba/

2019/05/09(木) 13:08:41.72

むしろVBであらゆることが出来るようにしろ

2019/05/09(木) 16:11:33.63

>>399
C#のコードをVBAに変換する処理実装すればいいんでね？

2019/05/09(木) 16:42:54.51

>>403
大から小への変換は無理です

2019/05/09(木) 19:35:32.79

MS OfficeでVBAだけじゃなくてpythonも使用可能になるって話はどうなった？

2019/05/09(木) 21:29:42.00

>>405
マイクロソフトが手綱握れない言語なんて載せるわけ無いだろ。

2019/05/09(木) 21:52:59.54

>>405
そんな話もあったね
アンケートだったって事らしいけど
ttps://qiita.com/yniji/items/b38bc312e860027108ac

2019/05/09(木) 22:08:44.78

>>406
C++は手綱握れると仰る？

2019/05/09(木) 22:12:01.53

>>405
javaScriptじゃなくて？

2019/05/09(木) 22:26:32.54

>>408
MSは仕様策定にがっつり参加してるよ

2019/05/09(木) 23:41:29.67

だったら早く #pragma once を標準に入れてくれ

2019/05/10(金) 01:29:46.37

>>409
ユーザーから要望があってとりあえずアンケートしていたけど
いつものマイクロソフトらしくその後だんまりだったような

2019/05/10(金) 01:45:08.01

アンケートの結果はVBのままでいいということだったんだな

2019/05/10(金) 07:51:36.91

Celeron 1000M/メモリ16GB/SSD500GBのオンボロPCにVisualStudio 2019をフルインストールしたが、遅すぎてツライ。
フルインストールしたのが原因？
インストール時に必要最小構成に絞れば軽くなる？
2019はCPUバカ喰いする？

素直に2017に入れ替えた方がいいのかな？

2019/05/10(金) 08:08:42.95

そもそも何が必要最小構成なのか判断できる知識はあるのか？
何だか書込みが馬鹿っぽいぞ

2019/05/10(金) 08:23:53.88

むしろ2019は2017よりも軽いくらい

2019/05/10(金) 09:12:54.63

>>415
環境依存のバグかもな。
公式リリース当初、とあるWPFのViewModelにブレークポイント置いて、
次ステップ(F10)へ進もうとしたら何秒も待たされていたりした。
2017だと問題ないし、全てのWPFアプリでそうなったわけでもなかった。
1ステップ毎に何秒も待たされて使い物にならなかったが、いつの間にやら直ってた。

2019/05/10(金) 09:13:44.53

レス先待ちがい。
>>417は>>414へのレス。

2019/05/10(金) 09:39:46.34

>>414
cpuはそんなにバカ喰いしない
5MBくらいのC++ソースファイルをビルドした場合で
core i9 9900k@5GHzの使用率が10%くらい

2019/05/10(金) 09:43:43.84

>>419
>core i9 9900k@5GHz
オイ!

2019/05/10(金) 18:53:26.30

>>417
2017に比べて「えっ？」てくらい遅いよね。
やっぱ戻すわ。

>>419
それひょっとして自慢ですか？
パソコン自慢ですか？
見せびらかしですか？

2019/05/10(金) 19:07:57.33

自分に投資するときはババーンとやらんとね

2019/05/10(金) 19:16:43.49

Xeon Phi 7210 だとどんな感じになる？

2019/05/10(金) 19:18:52.67

>>422
せやな
自己投資は大事
スレ的にはEnterprise w/ MSDNのVS Subscription使うのが望ましい

2019/05/10(金) 19:26:24.10

環境はwin8.1・Celeron M（1.73GHz）
RAM1.5GB・Cドライブ空き6.73GB
VS2015なら使えていたけど
VS2019にしたら、立ち上がり・プロジェクト作成・コンパイルで
物凄い時間がかかる。
キャッシュの設定でUSBメモリか空きＨＤＤ用意すれば使える様になるかな？

使えないなら、管理専用に使うか。

2019/05/10(金) 19:38:41.61

https://docs.microsoft.com/en-us/visualstudio/releases/2019/system-requirements
> 1.8 GHz or faster processor. (後略)
> 2 GB of RAM; 8 GB of RAM recommended (後略)
> Hard disk space: (中略) typical installations require 20-50 GB of free space.
新しくPC買った方が幸せになれると思う

2019/05/10(金) 19:52:48.81

>>425
>RAM1.5GB

8GBは必要だろう

2019/05/10(金) 20:12:21.20

皆さんはメインのPCにVisualStudio入れてるの？
環境汚れるのは気にならない？

Celeron/16GBの他にi7/32GB、i7/16GB、i5/8GBがあるけど、環境汚れるからVisualStudio入れるの躊躇してる。

2019/05/10(金) 20:14:21.87

>>428
何で1番ゴミにVSを入れてるんだ？
残りは何に使ってるんだよ。