Visual Studio 2017 Part5

2018/03/06(火) 20:41:44.79

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

Visual Studio 2017
http://www.visualstudio.com/

日本語チームブログ
http://blogs.msdn.com/b/visualstudio_jpn

前スレ
Visual Studio 2017 Part4
http://mevius.5ch.net/test/read.cgi/tech/1509244956/

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

2018/05/27(日) 12:47:05.29

完全にスタンドアロンのシステムならともかく、仕様変更でシステム改変するならその時点で改めて要件見直して見積もりすると思うけど

2018/05/27(日) 13:51:46.75

変更の程度によるだろそんなもん
単なる表記の修正とかもあるし

2018/05/27(日) 16:20:10.44

どうしても開発環境を固定したいなら、
オフラインインストーラー作っとけば済む話じゃないの。

2018/05/27(日) 16:50:20.51

それ大事やね

2018/05/27(日) 16:50:29.75

ごく普通にあることなのに「どうしても～なら」とか悪意が透けて見えるな

2018/05/27(日) 16:55:17.65

**どうしても**開発環境を固定したいなら、EC2のインスタンスにでも開発環境一式インストールしてスナップショット撮って塩漬けにしとけよ

2018/05/27(日) 16:59:19.93

頭良い人キター(棒)

2018/05/27(日) 16:59:53.97

どうしても開発環境固定したいことがごく普通にある職場なんてかわいそう

◆QZaw55cn4c (ﾜｯﾁｮｲ d360-Ockd) · 2018/05/27(日) 17:02:59.27

>>749
VS って勝手にコンパイラのバージョンをあげたりしませんか？
なんか便利な固定指定のスイッチでもないものか…

2018/05/27(日) 17:19:08.66

>>758
勝手にはしません

2018/05/27(日) 17:25:52.35

いつの間にか動かなくなってるとか動作が変わってるなんてことはあるからね
凍結していつでも戻せる状態にしておくのは常識(特にVS入れてる場合)

2018/05/27(日) 17:31:13.63

C++のバージョンは増えし過ぎだな
もはや何が何やら違いが分からん
https://i.imgur.com/jYi5nhL.png

2018/05/27(日) 17:38:42.63

>>757
むしろ開発環境コロコロ変えられる職場の方が可哀想だわ w

2018/05/27(日) 18:01:57.38

アップデートして最新機能を好きに使って書ける方が良いに決まってるでしよ
わざわざ不便を楽しむなどというマゾにはなれない

2018/05/27(日) 18:08:35.38

>>761
言語のバージョンは確かに３年おきに上がっているが
おまえさんが言っているのはコンパイラのバージョンだ
まず、そこの違いを理解してからもう一度
何が何やら違いを探してみるヨロシ

◆QZaw55cn4c (ﾜｯﾁｮｲ d360-Ockd) · 2018/05/27(日) 18:18:23.98

>>763
それがね、アップデートしたとたんにコンパイルできなくなってしまう事例が発生したのです
つまり cuda 9.0 ～ 9.2

2018/05/27(日) 18:21:06.27

>>763
仕事したことない奴はお気楽でいいね w

2018/05/27(日) 18:21:23.99

コンパイラのバージョンアップで死ぬパターンはあるあるすぎる

2018/05/27(日) 19:06:02.57

>>764
いやコンパイラのバージョンの話をしてるんだろ
今の15.7.2に同梱されているC++コンパイラのバージョンの話
v14.00 VS2015.3 (2015update3)
v14.11 VS2017 15.4
v14.12 VS2017 15.5
v14.13 VS2017 15.6
v14.14 VS2017 15.7

2018/05/27(日) 19:21:08.73

最初から「コンパイラのバージョン」って書けよ

2018/05/27(日) 19:23:23.25

わざわざスクショ張ってるんだから分かるだろ

2018/05/27(日) 19:37:38.58

>>769
アスペ

2018/05/27(日) 21:12:55.45

>>768
いーや奴は「C++のバージョン」と言っている

2018/05/27(日) 21:22:19.34

奴って誰のことだ？

2018/05/27(日) 21:27:13.07

レスの連鎖を追えない池沼とは対話が成立しない

2018/05/27(日) 21:48:18.90

>>772
SS見たら分かるだろ

2018/05/27(日) 21:49:54.25

SSって何？

2018/05/27(日) 21:52:40.40

>>772
>>770

2018/05/27(日) 21:53:16.77

SexSpeciaistの事や
常識だから覚えておけ

2018/05/27(日) 21:55:20.70

なるほどそうか

2018/05/27(日) 21:57:57.90

>>777
奴が言っているのは「C++のバージョン」
スクショはコンパイラのバージョン
だから何？

2018/05/27(日) 22:04:54.12

「C++のバージョン」っていうのは普通はC++コンパイラのバージョンのことだと思うんですがw

2018/05/27(日) 22:04:57.73

「これコピーしといて
「わかったで。コピーしといたやで
「違うわコピーってそのこと違うわ
「コピーじゃなくてプリントと言えや

みたいな会話

**デフォルトの名無しさん** (ｽﾌｯ Sd33-vBdx) · 2018/05/27(日) 22:05:09.90

またアスペがスレ荒らしてる

2018/05/27(日) 22:06:26.03

それともCPPってHTMLみたいにどこぞの標準化団体が
言語そのもののバージョンを策定してるんだっけ？
よく知らんけど

2018/05/27(日) 22:09:00.31

>>784
ISO

2018/05/27(日) 22:12:46.30

>>781
それは違う
C++は言語だ
The C++ Programming languageはVisual Studioの説明をしているか？
ISO/IEC 14882はVisual Studioを規定しているか？

2018/05/27(日) 22:43:00.67

KY君乙

2018/05/27(日) 23:09:25.89

The C++ Programming languageはVisual Studioの説明をしているか？
ISO/IEC 14882はVisual Studioを規定しているか？
↑
こんなのは空気で変わったりはしない

2018/05/27(日) 23:14:41.56

>>761
＞C++のバージョンは増えし過ぎだな
＞もはや何が何やら違いが分からん
＞https://i.imgur.com/jYi5nhL.png

これの下から2番目の VC++2015 ツールセットを入れて使用しても
VS 2015 で同ツールセットを使用した場合には出ない不具合が出るの直ったかな

2018/05/27(日) 23:23:15.95

>>788
> こんなのは空気で変わったりはしない
うん、誰もそんな話をしてないって言う空気だから

2018/05/28(月) 04:24:27.91

>>790
そんな話を>>761がしてるんだよ

2018/05/28(月) 06:34:00.89

と思ってるのはID:ow8rtphp0だけ w

2018/05/28(月) 15:34:47.45

>>784
なんでよく調べもしないで話に加わろうとするわけ？
バカだろお前。

2018/05/28(月) 19:19:10.66

20年位前、Visual Studioのプロジェクトというのが何なのかさっぱりわからなかったとき、GUI流のMakefileだと説明されてよくわかりました。

2018/05/29(火) 05:39:04.79

>>792
と思いたいのはおまえだけ
現実は微動だにしない

2018/05/29(火) 05:42:43.64

>>795
> 現実は微動だにしない
お前だけの現実な w

2018/05/29(火) 11:39:23.41

>>794
makeより使いにくい

2018/05/29(火) 12:24:56.32

別にVSに限らず、プロジェクトファイルとソリューションみたいな構成は当たり前なんだどな。
Linuxにはアプリが無いからその辺りのリテラシーが無いんだろうね。

2018/05/29(火) 12:26:03.81

Linux使ってる奴ってペイントソフトだって画像ファイルだけで起動できるとか思ってそう

2018/05/29(火) 12:29:38.11

linuxだって普通はGUI操作だからユーザーのレベルや認識はwindows,macと大して変わらない

2018/05/29(火) 12:37:02.34

Linux にはアプリがない
Firefox とか Chrome が Windows で開発されてきたと思ってるような人いるんだな

2018/05/29(火) 12:45:36.31

Linuxだと乱立してるだけで、統合開発環境だっていくらでもあるような？

2018/05/29(火) 12:53:36.83

最近はソリューション的な概念をエディタが管理するのは好まれないだろ
ディレクトリ構造をベースにして柔軟に扱うのが主流だよ

2018/05/29(火) 13:27:03.09

>>803
え゛

2018/05/29(火) 13:38:03.26

>>803
Unix では昔からそんなだしな

2018/05/29(火) 14:06:55.01

a.out

2018/05/29(火) 14:11:29.79

それバイナリ

2018/05/29(火) 14:15:32.62

a.outフォーマット
https://ja.wikipedia.org/wiki/A.out%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%83%E3%83%88

2018/05/29(火) 14:30:35.46

VSはa.outで出力できるんかね？
ELFとかあるから意味無いと思うけど

2018/05/29(火) 16:50:46.79

KHTMLのころに使ってたけど、Linuxユーザーには不評だったよ。
当時、ネットスケープは良く落ちて、それはサイトがIE用に作られているからだと言われていた。
したがって、ネットスケープが落ちるページでKHTMLが落ちないということは、KHTMLが標準から逸脱しているからだと考えられていた。
ところで今、シェアを落としたMSは、標準がどうあろうとChromeと異なる動作があるなら、それはEdgeのバグとして対処すると言っている。

2018/05/29(火) 16:54:25.69

>>809
Visual StudioはIDEなので、コンパイラは何でもいいんですよ。
現在、cl、Clang、gccが使えます。
もちろん、gdbとも接続できます。

2018/05/29(火) 17:31:47.82

>>809
メイクファイルプロジェクトにすれば何でもok

**809** (ｱｳｱｳｴｰ Sae3-tYJm) · 2018/05/29(火) 17:58:39.92

>>811、>>812
サンクス

VSのクロスプラットフォームってビルドもリモートの環境を使うのね
そしてgccのデフォルト出力はELFだった(ファイル名はa.out)

2018/05/29(火) 18:06:14.01

考え方としては、Visual StudioはSSH経由でLinuxに接続できるので、ほとんど何でもできる。
MSBuildやCMakeはLinuxに対応している。
Visual StudioはMSBuildはもちろん、CMakeにも対応している。
CMakeに何かを書けばそのままインテリセンスが効くようなレベルで対応してますね。
見逃せないのは、MSはオープンソースのVCPKGというパッケージマネージャを出しているのですが、これがLinuxやMacにも対応していることですね。
これまでMSはオープンソースやクロスプラットフォームに後ろ向きだったのですが、心を入れ替えたようです。
これはもうMacなんか使ってる場合じゃないって感じです。

2018/05/29(火) 18:09:28.02

>>813
それがwslのおかげでWindowsだけで完結しちゃうんですよね。
wslはもっと重いものを想像していたんですが、フットプリントは小さいです。
つまり、Ubuntuを起動してもタスクマネージャには数メガバイトしか表示されません。
ディスクの消費も200MB程度だったと思います。

2018/05/29(火) 18:23:52.85

Linuxのコマンドには使えるものがかなりあるので、Windows開発者であってもwslは入れた方がいいと思いますよ。
たとえばgperfなんか普通に使いますよね。
これまではちょっと野良っぽいwin32版なんかを使っていたと思うのですが、開発環境に野良を入れるのは気が引けていました。
逆に、Linux開発者がWindowsとwslを使えば、Excelなんかが便利に使えると思います。
列挙体なんかを書く時には、Excelのシートに表を作り、整形させると思います。
これの良いところは、整形用のマクロが一緒に保存できることだと思います。

2018/05/29(火) 19:00:01.40

>>816
そろそろアホは黙れよ

2018/05/29(火) 19:21:53.06

これからの開発はVisual Studioを中心に考えたら良いんじゃないでしょうかね。

2018/05/29(火) 19:28:34.78

>>804
プロジェクトはともかく、ソリューションは頭の悪い非合理な概念
・大抵、現実のシステムはVSだけでは完結しない(他の言語、パッケージソフト、設定ファイル、ドキュメント、etc)
・一般に、作業単位は案件やチームごとに異なるため、ソリューションを唯一絶対のものとして中央管理することにはあまり意味がない
・バージョン管理やパッケージ管理との相性が悪い

2018/05/29(火) 19:37:03.46

>>819
所詮XMLファイルに過ぎないので大丈夫なんじゃないでしょうかね。

2018/05/29(火) 19:40:22.15

まあ僕はVisual Studioを使わない皆さんのためにCMakeプロジェクトを作るのは良い考えだと思います。
Visual StudioはCMakeプロジェクトへの対応も素晴らしいので、大変良いです。

2018/05/29(火) 19:48:53.47

>>819
TFSやVSTSの管理単位はソリューションの上位のチームプロジェクトが基本
ソリューションは唯一絶対という程のものではないよ

2018/05/29(火) 19:59:47.86

はあ～、Visual Studioが最強になってきて愉快愉快。

2018/05/29(火) 20:30:00.89

もう10年くらいeclipse使ってないけどだめなん？

2018/05/29(火) 20:51:36.44

>>824
そんなのもあったねえ

2018/05/29(火) 21:05:56.65

>・バージョン管理やパッケージ管理との相性が悪い

どこからそんな偏見を

◆QZaw55cn4c (ﾜｯﾁｮｲ d360-Ockd) · 2018/05/29(火) 21:34:00.16

>>823
でも最新 cuda をコンパイルできないヘボコンパイラが搭載されているのも事実

2018/05/29(火) 21:42:34.77

>>819
はぁー、物理構造に縛られるのが良いと

2018/05/29(火) 21:44:58.89

>>796
何とでも言えば？
おまえからも見えてる「それ」を

2018/05/29(火) 22:15:40.78

VCPKGは最新のライブラリへの追従が速いので、ディストリビューションが用意する開発版パッケージよりお勧めですよ。

2018/05/29(火) 22:16:05.97

>>827
そりゃnvccの方の問題だろ。

2018/05/29(火) 22:52:06.65

>>828
逆だよ
ソリューションに縛られずに物理構造を自由にできる
例えば、当のVSだって今の新しい形式のプロジェクトファイルはソースファイルをいちいち全部登録しなくても勝手に探してビルドしてくれるようになったりしてて、
時代は余計な設定やメタデータを省いてシンプルに構成する方向へ進んでるんだよ

2018/05/29(火) 23:04:40.04

>>829
では、お前に賛同してる奴のレス番示してみ w

2018/05/29(火) 23:18:23.34

まあよくわからんけど、俺の素晴らしいレスを上に押し出してまでする争いじゃないと思います。

2018/05/29(火) 23:29:57.19

>>827
MicrosoftのGPGPU支援はCUDAではなくてDirectComput
https://ja.wikipedia.org/wiki/DirectCompute

そのためのコンパイラ仕様はC++AMP
VC++は、C++/CLIだけではなくC++AMP仕様のコンパイラでもある

2018/05/29(火) 23:39:25.78

C++/CLIの標準規格はECMA372
https://ja.wikipedia.org/wiki/C%2B%2B/CLI

C++AMPには標準規格はない
https://ja.wikipedia.org/wiki/C%2B%2B_AMP

2018/05/30(水) 01:54:54.68

>>832
必要ないファイルまで勝手にコンパイルされたくないからソリューションファイルがいいですね

2018/05/30(水) 12:47:37.84

話変わるが
VSでは伝統的にC++プロジェクトのファイルをヘッダとソースで分けて登録するけど、
ヘッダとソースは同じグループに並べて登録した方が便利だと思わない？

foo
+ hige.h
+ hige.cpp
+ hage.h
+ hage.cpp

みたいに

2018/05/30(水) 15:49:34.42

　　　　　　　　　　　|
　　　　　　　　　　 |　　彡⌒ミ
　　　　　　　　　　　＼ (´･ω･`)　また髪の話してる・・・
　　　　　　　　　　　　　(|　　　|)::::
　　　　　　　　　　　　　(γ　/:::::::
　　　　　　　　　　　　　　し＼:::
　　　　　　　　　　　　　　　　　＼

2018/05/30(水) 17:59:46.22

伝統ってか単に標準のフィルタ設定がそうなってるってだけで
OSSとか見ててもそのまま使ってる方が稀じゃね

2018/05/30(水) 18:53:22.77

ソースとヘッダは並べてある方が便利ということについては同意してくれてると考えていいのだろうか

2018/05/30(水) 19:12:47.19

場合にもよる
数が増えてくると分けたほうが見やすくなるよ

2018/05/30(水) 19:18:14.04

>>838
そのプロジェクトでしか使わないならそれでいいと思うよ
ヘッダーが他のプロジェクトでも使われるならそのヘッダーは分離しておいた方が管理が楽

2018/05/30(水) 19:24:30.48

俺はソースを置くディレクトリ以下にサブディレクトリがあってそこにソースがあるなら同じようにプロジェクトにもフォルダを作ってソースを登録してるな。　サブディレクトリがないなら結果として >>838 みたいになる。

2018/05/30(水) 19:33:54.58

外部依存関係ってのが邪魔なんだよなぁ。あれ表示されないようにできないのかな。

2018/05/30(水) 22:09:34.51

>>833
賛同したら必ずレスするという前提なんだな

2018/05/30(水) 22:29:01.18

>>838
そういう分類にしたらいいじゃん
自由に分類できるんだから

2018/05/30(水) 22:32:52.96

>>846
レスもないのに賛同してるのがわかるとかエスパーかよ w
あほらし

2018/05/31(木) 00:04:31.39

2ちゃんなんて基本的に文句ない限りレスつかないからな

2018/05/31(木) 00:31:43.21

　/* */を含むブロックを/* */でコメントアウトしたら、コメントアウトがネストしなくて途中でコメントアウトが途切れてしまいました。
　テキストエディタの書式設定ではコメントのネストに関する設定を見付けられませんでしたが・・・本当にないのでしょうか。　私の見落とし？
　見落としではなく本当に無いのだとしたら、回避の定石とかありますか？