Visual Studio 2017 Part5
■ このスレッドは過去ログ倉庫に格納されています
!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 Linux使ってる奴ってペイントソフトだって画像ファイルだけで起動できるとか思ってそう linuxだって普通はGUI操作だからユーザーのレベルや認識はwindows,macと大して変わらない Linux にはアプリがない
Firefox とか Chrome が Windows で開発されてきたと思ってるような人いるんだな Linuxだと乱立してるだけで、統合開発環境だっていくらでもあるような？ 最近はソリューション的な概念をエディタが管理するのは好まれないだろ
ディレクトリ構造をベースにして柔軟に扱うのが主流だよ VSはa.outで出力できるんかね？
ELFとかあるから意味無いと思うけど KHTMLのころに使ってたけど、Linuxユーザーには不評だったよ。
当時、ネットスケープは良く落ちて、それはサイトがIE用に作られているからだと言われていた。
したがって、ネットスケープが落ちるページでKHTMLが落ちないということは、KHTMLが標準から逸脱しているからだと考えられていた。
ところで今、シェアを落としたMSは、標準がどうあろうとChromeと異なる動作があるなら、それはEdgeのバグとして対処すると言っている。 >>809
Visual StudioはIDEなので、コンパイラは何でもいいんですよ。
現在、cl、Clang、gccが使えます。
もちろん、gdbとも接続できます。 >>809
メイクファイルプロジェクトにすれば何でもok >>811、>>812
サンクス
VSのクロスプラットフォームってビルドもリモートの環境を使うのね
そしてgccのデフォルト出力はELFだった(ファイル名はa.out) 考え方としては、Visual StudioはSSH経由でLinuxに接続できるので、ほとんど何でもできる。
MSBuildやCMakeはLinuxに対応している。
Visual StudioはMSBuildはもちろん、CMakeにも対応している。
CMakeに何かを書けばそのままインテリセンスが効くようなレベルで対応してますね。
見逃せないのは、MSはオープンソースのVCPKGというパッケージマネージャを出しているのですが、これがLinuxやMacにも対応していることですね。
これまでMSはオープンソースやクロスプラットフォームに後ろ向きだったのですが、心を入れ替えたようです。
これはもうMacなんか使ってる場合じゃないって感じです。 >>813
それがwslのおかげでWindowsだけで完結しちゃうんですよね。
wslはもっと重いものを想像していたんですが、フットプリントは小さいです。
つまり、Ubuntuを起動してもタスクマネージャには数メガバイトしか表示されません。
ディスクの消費も200MB程度だったと思います。 Linuxのコマンドには使えるものがかなりあるので、Windows開発者であってもwslは入れた方がいいと思いますよ。
たとえばgperfなんか普通に使いますよね。
これまではちょっと野良っぽいwin32版なんかを使っていたと思うのですが、開発環境に野良を入れるのは気が引けていました。
逆に、Linux開発者がWindowsとwslを使えば、Excelなんかが便利に使えると思います。
列挙体なんかを書く時には、Excelのシートに表を作り、整形させると思います。
これの良いところは、整形用のマクロが一緒に保存できることだと思います。 これからの開発はVisual Studioを中心に考えたら良いんじゃないでしょうかね。 >>804
プロジェクトはともかく、ソリューションは頭の悪い非合理な概念
・大抵、現実のシステムはVSだけでは完結しない(他の言語、パッケージソフト、設定ファイル、ドキュメント、etc)
・一般に、作業単位は案件やチームごとに異なるため、ソリューションを唯一絶対のものとして中央管理することにはあまり意味がない
・バージョン管理やパッケージ管理との相性が悪い >>819
所詮XMLファイルに過ぎないので大丈夫なんじゃないでしょうかね。 まあ僕はVisual Studioを使わない皆さんのためにCMakeプロジェクトを作るのは良い考えだと思います。
Visual StudioはCMakeプロジェクトへの対応も素晴らしいので、大変良いです。 >>819
TFSやVSTSの管理単位はソリューションの上位のチームプロジェクトが基本
ソリューションは唯一絶対という程のものではないよ はあ〜、Visual Studioが最強になってきて愉快愉快。 もう10年くらいeclipse使ってないけどだめなん？ >・バージョン管理やパッケージ管理との相性が悪い
どこからそんな偏見を >>823
でも最新 cuda をコンパイルできないヘボコンパイラが搭載されているのも事実 >>796
何とでも言えば？
おまえからも見えてる「それ」を VCPKGは最新のライブラリへの追従が速いので、ディストリビューションが用意する開発版パッケージよりお勧めですよ。 >>828
逆だよ
ソリューションに縛られずに物理構造を自由にできる
例えば、当のVSだって今の新しい形式のプロジェクトファイルはソースファイルをいちいち全部登録しなくても勝手に探してビルドしてくれるようになったりしてて、
時代は余計な設定やメタデータを省いてシンプルに構成する方向へ進んでるんだよ >>829
では、お前に賛同してる奴のレス番示してみ w まあよくわからんけど、俺の素晴らしいレスを上に押し出してまでする争いじゃないと思います。 >>827
MicrosoftのGPGPU支援はCUDAではなくてDirectComput
https://ja.wikipedia.org/wiki/DirectCompute
そのためのコンパイラ仕様はC++AMP
VC++は、C++/CLIだけではなくC++AMP仕様のコンパイラでもある >>832
必要ないファイルまで勝手にコンパイルされたくないからソリューションファイルがいいですね 話変わるが
VSでは伝統的にC++プロジェクトのファイルをヘッダとソースで分けて登録するけど、
ヘッダとソースは同じグループに並べて登録した方が便利だと思わない？
foo
+ hige.h
+ hige.cpp
+ hage.h
+ hage.cpp
みたいに |
| 彡⌒ミ
＼ (´･ω･`) また髪の話してる・・・
(| |)::::
(γ /:::::::
し ＼:::
＼ 伝統ってか単に標準のフィルタ設定がそうなってるってだけで
OSSとか見ててもそのまま使ってる方が稀じゃね ソースとヘッダは並べてある方が便利ということについては同意してくれてると考えていいのだろうか 場合にもよる
数が増えてくると分けたほうが見やすくなるよ >>838
そのプロジェクトでしか使わないならそれでいいと思うよ
ヘッダーが他のプロジェクトでも使われるならそのヘッダーは分離しておいた方が管理が楽 俺はソースを置くディレクトリ以下にサブディレクトリがあってそこにソースがあるなら同じようにプロジェクトにもフォルダを作ってソースを登録してるな。 サブディレクトリがないなら結果として >>838 みたいになる。 外部依存関係ってのが邪魔なんだよなぁ。あれ表示されないようにできないのかな。 >>833
賛同したら必ずレスするという前提なんだな >>838
そういう分類にしたらいいじゃん
自由に分類できるんだから >>846
レスもないのに賛同してるのがわかるとかエスパーかよ w
あほらし 2ちゃんなんて基本的に文句ない限りレスつかないからな /* */を含むブロックを/* */でコメントアウトしたら、コメントアウトがネストしなくて途中でコメントアウトが途切れてしまいました。
テキストエディタの書式設定ではコメントのネストに関する設定を見付けられませんでしたが・・・本当にないのでしょうか。 私の見落とし？
見落としではなく本当に無いのだとしたら、回避の定石とかありますか？ >>850
Cだと思うけど、この辺かな？
ttp://www.amy.hi-ho.ne.jp/~lepton/program/p3/prog322.html
構文に関する所だから、Visual Studioじゃなくて言語仕様の方だね CTestのGoogle Test Adapterが機能していないようなのだが。 https://ideone.com/3LDXGx
質問です。定期的に同じ関数をスレッドで起動するクラスを作りました。
んでコード中のここ無駄って書いてある行を削除する方法はありませんか。
開発はVCでやってますが、GCCでも通ればいいなーと思っています。
相談室で答えてもらえなかったので誰か教えてください。 2012から2017に上げるコストを容認できるような、派手なメリットってある？ C++ならC++14、C#ならC#7.0、VBはよく分からん
使用言語によってどうぞ 逆に2012を使い続けるデメリットでもいいけど
なんかｷｬｯﾁｰなの頼む 環境を変えるモチベを持てないのなら2012に留まるのもよし
他人の価値観なんか分からん >>858
アップデートしちゃってまともに動かなくなるスリルが味わえる >>855
.NET Core, .NET Standard >>858
Visual Studio Live Share
役に立つかはともかく、ここ数年のVSの新機能の中では間違いなく最もｷｬｯﾁｰ アップデートしてここにこのような不具合発生したという正確かつ具体的な情報はほとんど報告されていないのですが StackOverflowの中の人とかも結構報告してるよ うーん…予算捻出に効く感じのものは乏しいな
効率あがるような新機能のデモするとかかな…めんどいなぁ
Gitとの連携が強化されてるのは材料になるかな
あと2017は起動や挙動が早くなったらしいけど、感動できるくらいある？ 確かに自分でDeveloper Comminityに投稿したポスト紹介してvoteよろしことかは一度も見たことないねｗ >>866
稟議書の審議でなくてプレゼンでもして決済を通すのか？
変わった職場だな >>848
賛同してるのがわかるってどこに書いてあるんだ？
俺は現実と書いただけなんだが、
おまえはエスパーかそれともスキャナーか？ >>869
・賛同してるレスは出せない
・レスはないと賛同してるのはわからない
結局
> と思ってるのはID:ow8rtphp0だけ w
って結論でいいかな w 自分が勝った状態で終わらないと気が済まない人、女みたいで情けない >>870
よくない
コンパイラのバージョンと言語のバージョンは違う
誰が賛同しようがしまいが微動だにしない現実だ >>866
起動速度は2015で遅くなったのが2017でましになったかな位。
新機能はCodeLensとC#インタラクティブはどうだろうか。 そもそもこんなところでメリットを聞いているのが変な話。
自分たちの仕事に役に立つと思ってるからこそバージョンアップしたいわけだろう。 Community入れて自分で試せば済む話ではあるな。
CodeLens以外は無料で使えるのだし。 VSCodeなら無料でCodeLens使えるよ
WebならVSCodeでの.NET開発も実用的になってきた >>878
IntelliJなどの競合製品に同様のものが無いからだろ
ゼロからの挑戦者であるVSCodeとは違って、VSの他製品に対する圧倒的な優位性はCodeLensの有無なんかでは全く揺らがない
だから他製品との差別化ではなくエディションの差別化に利用したほうが利益があるという判断だろうな >>872
> コンパイラのバージョンと言語のバージョンは違う
お前以外は誰もそんな話をしてない
これが微動だにしない現実だよ w 15.7.3 (2.73GB@Enterprise) すごー
何十項目更新すんねん
FIXが不安になる
干渉でもすんのか溜め込みやがって てかやっとVSインストーラー自動終了
更新のとき地味に煩わしかった インストーラーがちゃんと動くことに感動できるようになった。 >>886
本人が>>768でそんな話じゃないと書いてるのにバカすぎる w 完璧に論破されたからって話そらすとか恥ずかしくないの？ｗ インストール済みと表示しながらダウンロードしてるぞｗ インストール済み（ダウンロードしてるともしてないとも言ってはいない） 何がインストール済みであるかについては特に言及していないので間違いではないでしょ。 コミュニティ、プロ、エンタープライズのうち、このバージョンがインストール済みという意味なんだろうけど、ぱっと見変だよね。
ダウンロードしながらタイトルがインストール済みだから。 >>868
稟議を出すための根回しに必要なんだよ。
稟議書なんてハンコ押すための書類だよ。
>>875
開発者としてのメリットではお金はでない。
お金を持ってる人向けのメリットを紹介して欲しいんじゃないかな。
メリットでも脅し（保守期限切れたとかの類）でも。 VS2012はメンテされてないからセキュリティホールがある可能性があるよ
それでもいいのなら使えばいいさ 有償版ならスタンドアローンライセンスでなくてサブスクリプションにすればいいのにな
というかMSDNなしでどうやって検証環境のライセンスを確保してるんだろ
評価版利用するにしても限度があるだろうに ■ このスレッドは過去ログ倉庫に格納されています
