Visual Studio 2019 Part6

■ このスレッドは過去ログ倉庫に格納されています
2021/04/21(水) 23:27:05.12ID:3qCJi6070
!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/21(水) 23:28:23.16ID:3qCJi6070
無いから立てたよぉ…
2021/04/21(水) 23:34:17.12ID:k1BHxrbM0
乙
2021/04/21(水) 23:42:19.87ID:LBvRjqkNM
乙
5デフォルトの名無しさん (ｵｯﾍﾟｹ Sr8b-On5Q)
垢版 |
2021/04/22(木) 05:50:38.91ID:C6ndQuaCr
乙
2021/04/22(木) 08:07:37.29ID:8Baz0o+5d
俺個人の勝手な予想では
マイクロソフトはOS事業からの撤退の準備を始めてるんだと思うよ
2021/04/22(木) 08:54:17.77ID:cnOQHdKja
VSの64ビット化って具体的に何がうれしいの？
メモリ馬鹿食いになるだけじゃん
2021/04/22(木) 09:44:52.91ID:zdS1gT1X0
わからないなら使わなくていい
2021/04/22(木) 09:57:48.35ID:lkJtfBhJ0
>>6
勝手だな
2021/04/22(木) 10:17:33.08ID:yNSfYish0
> メモリ馬鹿食いになるだけじゃん

RAMとHDDを大量に売りつけるのが64の真の目的だからな
11デフォルトの名無しさん (ｵｯﾍﾟｹ Sr8b-On5Q)
垢版 |
2021/04/22(木) 10:19:23.98ID:C6ndQuaCr
じゃあ2019でいいわ
困ることねぇしな
12デフォルトの名無しさん (ｵｯﾍﾟｹ Sr8b-On5Q)
垢版 |
2021/04/22(木) 10:19:54.94ID:C6ndQuaCr
>>6
勝手すぎワロタw
2021/04/22(木) 10:54:28.83ID:JxVnPstuM
やっぱりメモリ消費が少ない地球に優しい16bitに皆戻るべきだよね
2021/04/22(木) 11:12:48.77ID:8Baz0o+5d
>>9,12

だってMicrosoftが独自にOS開発続ける明確な理由が
もうなくなってきてるでしょ

Linuxへ移していくための準備に思えるわ
2021/04/22(木) 11:28:01.94ID:lkJtfBhJ0
これまでのWindows資産バッサリ捨てられるわけないやろ
2021/04/22(木) 11:44:44.18ID:X3s7nmsp0
蘇るLindows
2021/04/22(木) 12:48:40.50ID:zqNu2+/3M
>>6
Ｘ 俺個人の勝手な予想では
〇 バカの妄想では
2021/04/22(木) 12:53:08.62ID:29onDo3W0
>>14
Linuxは、いろんな意味で全然Windowsと同じ土俵に立ててない。
今までを考えると、これからもたいして変わらない。

そんなものにユーザーが移るわけがないし、Microsoftがそれを期待するわけもない。
2021/04/22(木) 13:04:56.58ID:8Baz0o+5d
>>15
ばっさりとは行かないから
連携とかマルチプラットフォーム化やってるんでしょ

Windowsにメリットがあって辞める必要もないなら
WSLだっていらない気がする
2021/04/22(木) 13:14:03.92ID:lkJtfBhJ0
Windowsでどれだけ稼いでるか少しは調べてから現実を見ようね
2021/04/22(木) 13:25:48.15ID:y1VykytYM
WSLはプログラマー需要を少しでもWindowsにも取り込もうとしてるだけに思えるが
2021/04/22(木) 13:50:27.76ID:tuOeGeux0
>>6
もっとマシな予想しろよ
2021/04/22(木) 16:32:21.05ID:tcTtemzbM
VSスレで何の話をしているのかと
2021/04/22(木) 16:52:14.70ID:DfMofs+Z0
前スレのJavaの話題でふと思ったけど、ドザ個人的な使用範囲では.NETなソフトは
たくさん使っているけどJavaなソフトはMinecraftしかないわ
Minecraftも最近全然やってないんだが、Javaランタイムの更新通知がこないだ
表示された時に、長いこと使ってないみたいだから消せば？みたいなメッセージ
が出てた

俺の使用範囲が狭いのは置いといて、どこでJavaが活躍してんの？
Androidくらいしか知らん
2021/04/22(木) 18:19:57.55ID:2Gq+bd80d
>>24
これ以上はJavaスレでやってくれ
2021/04/22(木) 19:05:19.54ID:FMsdOyI8M
Microsoft製品関係だとSQL Serverのデータ仮想化PolyBaseやDevOps Serverのコンテンツ検索ElasticSearchなどでJavaは必須
現状ではAzul SystemのZulu OpenJDKがデフォルトでインストールされる
2021/04/23(金) 02:37:32.30ID:5oUB9lPR0
失礼します
visual studio 2019　でWindowsアプリケーションのフォームにメニューバーを付けようとMenuStripドラッグ&ドロップしたのですが「ここへ入力」が表示されません
表示するための解決法はありますか？
2021/04/23(金) 02:45:50.23ID:2Y/qf88b0
>>20
20%ぐらいだったっけ
2021/04/23(金) 06:39:30.07ID:0hTQ9bnmM
>>28
16%ちょい、収益構造はなかなかいいバラスを保ってる
https://i.gzn.jp/img/2020/08/06/big-tech-billions/00005_m.png
30デフォルトの名無しさん (ｵｯﾍﾟｹ Sr39-Rdia)
垢版 |
2021/04/23(金) 09:29:58.48ID:C2KB28Aor
>>29
サーフェスってBingアドインより売れてないってマジ？
2021/04/23(金) 10:02:16.82ID:PzJ645RSM
まあ売れてないって言っても6ビリオンドルだから6,000億は超えるけどね
32デフォルトの名無しさん (ｵｯﾍﾟｹ Sr39-Rdia)
垢版 |
2021/04/23(金) 10:17:21.53ID:C2KB28Aor
逆にサーフェスを超えるbing Addinって…
2021/04/23(金) 11:08:31.59ID:2fhWSDpqM
Ads は Addin ではなくて Advertisings
いわゆる検索ページからの広告収入だろう
2021/04/23(金) 11:42:24.03ID:mAev2lqU0
>>13
それは違う。
16BITの8086系では、セグメントアドレスを買えずに一度に扱えるメモリは
64KB に制限されていたが、それではほとんどのGUIのアプリでは足りなかったので
far pointer や huge pointer を使うのが広く行われていたから、16BITの
アドレスでは足り無い事が明らかだった。
ところが32BITのアドレスでは未だに2GBのメモリーで足りなくなるアプリは
ほとんど存在し無い事が知られている。
2021/04/23(金) 11:49:55.52ID:mAev2lqU0
>>34
誤: 16BITの8086系では、セグメントアドレスを買えずに一度に扱えるメモリは
正: 16BITの8086系では、セグメントアドレスを変えずに一度に扱えるメモリは

少なくとも8086系の16BIT CPUでは、フラットにアクセスできるアドレス範囲
が狭すぎて、本格的なGUIアプリを作っているプログラマーはとても苦労していた。
huge pointerを使えばずっとアドレス範囲が広がるが、とても遅くなるので積極的
に使うのは避けられていた。far pointerは、セグメントアドレスを変えなければ
一度にアクセスできるのは 64KB までだったので、使いにくかった。
一度に使えるアドレス範囲が 32BITになることは劇的にプログラミングがし易くなった。
ところが、64BIT化しても、このような激的な利便性の向上は起きない。
2021/04/23(金) 13:08:35.59ID:wmFgppeg0
Z80全盛時に8086憶えたけど
第一印象「オマエ、ソレハナイダロウ」だった
2021/04/23(金) 14:22:12.53ID:7NT1P8pu0
>>35
知らんがな。ｗ
そんな、クロックは今の数百分の一、キャッシュメモリもなかったような時代のことなんか。
提供する側ならともかく、提供される側が主張するようなことではない。
2021/04/23(金) 14:23:00.16ID:7NT1P8pu0
>>36
Z80のバンク切り替えよりマシやろ？ｗ
2021/04/23(金) 14:33:35.99ID:iLw20nf00
>>38
「Outportによる一部の領域のバンク切り替え」から
「CPUによる一般化されたバンク切り替え」に変わっただけという感じだった。
まだアドレスが、
　絶対アドレス = 上位16BIT * 65536 + 下位16BIT
だったら良かったのに、
　絶対アドレス = セグメント値 * 16 + 下位16BIT
という変な分け方がされていたのも最悪だった。
2021/04/23(金) 14:35:53.81ID:iLw20nf00
>>39
しかもセグメントレジスタが、汎用レジスタではなかったので
addなどの演算が直接的には出来なかったのも痛かった。
2021/04/23(金) 14:59:02.78ID:pVbXeaGwM
286/386はやってないっぽいな
2021/04/23(金) 16:08:27.34ID:8Z6dL8IIM
>>39
> 　絶対アドレス = 上位16BIT * 65536 + 下位16BIT
それやるとページが64kB単位になるからページをまたがる処理がめっちゃ面倒になるぞ
今みたいに多少メモリーが無駄になってもいいやっていう時代ならいいけど物理メモリーにきちきち詰めていくとどうしても複数ページにまたがる領域ができてしまう
43デフォルトの名無しさん (ｴﾑｿﾞﾈ FF70-SFxq)
垢版 |
2021/04/23(金) 16:11:44.92ID:QhHVXSoAF
>>39
境界またがってアクセスするときに後者の方が便利だ(と当時は思われた)からだろう
2021/04/23(金) 16:32:30.16ID:iLw20nf00
>>42
現実にはアセンブラで書いた場合ですらそんな使い方が必要になる経験をしたことは無かったな。
Cで書いたらそういう機能はもっと不要。
2021/04/23(金) 16:51:18.22ID:2t0a66vKM
8086のアドレスバスは20本(最大メモリ空間1MB)
16ビット長のレジスタでアドレス指定するためにセグメントレジスタで4bitシフトさせた上でオフセットと加算するという手法を採用した
8ビットCPU開発者からの移行を考えれば当時としては合理的な設計ではある
2021/04/23(金) 17:03:41.99ID:iLw20nf00
>>45
そうは思えなかったけどな。
2021/04/23(金) 17:20:02.93ID:iLw20nf00
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.23ID:7NT1P8pu0
>>47
自分の理想としてのきれいさとかアドレスのわかりやすさにひっぱられすぎやろ。ｗ

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

まあ、知らんけど。
2021/04/23(金) 18:04:08.66ID:iLw20nf00
>>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.89ID:fgWFdvl4M
アドレスが32ビットに拡張されたのはi386から
ページングと仮想記憶が導入されてやたら複雑化したけど
2021/04/23(金) 18:39:20.79ID:a5VG36DE0
＞。ｗ

またこのアホが舞い戻ってきたか
知らない話題に首突っ込んで否定するだけの中身なしの阿呆
2021/04/23(金) 20:57:17.23ID:kH73arGsM
>>44
セグメントの考え方を理解してないだけじゃね？
セグメントはページとは違って論理的な領域でそれを物理アドレスの何処に置くかをセグメントレジスタで指定してるだけの話

>>49
> add BX,4
> adc DX,0
> のようにすれば、4バイト先のアドレスを 32BIT で正確に計算できる。
それ毎回やるの？
すげー遅くなるよ
2021/04/23(金) 22:38:27.09ID:7NT1P8pu0
>>51
「否定」？ｗ
ただの指摘やで？

「阿保」とか自己紹介もほどほどにな。
54デフォルトの名無しさん (ﾜｯﾁｮｲ bc85-SFxq)
垢版 |
2021/04/23(金) 23:33:37.10ID:hyXGjiN10
>[DX:BX] と書くことが出来ていたなら、物凄く便利だったはず。

これは判らんでもないが当時は貴重なレジスタがもったいない
2021/04/24(土) 00:27:28.34ID:LJqR30KO0
VS2019スレで昔話するのやめてもらっても良いですか昭和生まれさん
プログラマー板でやれよ
2021/04/24(土) 02:20:23.22ID:CW6Yf84b0
>>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より設計が悪いとされた。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況