Repository navigation
MSVCのバージョンの書き方を変更したい #483
Description
Microsoft Visual StudioのC++コンパイラですが、バージョン表記がよくわからないことになってきたので、本サイトでのバージョン表記を変更したいです。
よくわからないこと、というのは、Visual Studio 2015が14.0、Visual Studio 2017が14.1ですが、14.1のさらにマイナーバージョンアップしたものが15.x表記になっていて、よくわからないことになっています。
対応策として、2017.5もしくは2017 Update 5のように、Visual Studio製品バージョン + アップデートバージョンの表記にすることで、コンパイラのメジャーバージョンの混乱を減らしたいです。
変更対象は、「コンパイラの実装状況」ページと、ライブラリの検証済みコンパイラの項目全てです。
対応が決まったら、私の方で作業します。
ちなみにcppreferenceの方は、_MSC_VERを見て書いているようです。
http://en.cppreference.com/w/cpp/compiler_support
http://en.cppreference.com/w/Talk:cpp/compiler_support
Activity
saki7 commentedon Nov 27, 2017
ああ、これは僕も以前からかなり不便に思っていました。提案通り製品バージョン（つまり西暦ベース）にするのが分かりやすくて良いと思います。
yumetodo commentedon Nov 27, 2017
同じメジャー/マイナーバージョンでもビルド番号で使える機能が違うとかxxx CTPとして出ているものを勘案すると
_MSC_FULL_VERも書くべきでは無いでしょうか？いわゆるconfig macroの類を書くときはそっちを見るわけで・・・
faithandbrave commentedon Nov 27, 2017
_MSC_FULL_VERは、implementationページに記載すればよいかと思います。ライブラリページを増やすたびに_MSC_FULL_VERを調べて書くのはしんどいです。saki7 commentedon Nov 27, 2017
@yumetodo
_MSC_FULL_VERとか 旧来の14.1のようないわゆる正規的なバージョン文字列は、同時に見たいということであればhover時のためにtitle属性とかに入れることは出来ます。バージョン文字列を特別扱いするのは新規の機能になるので、site_generatorとkunaiの両方に機能追加が必要です。この分かりづらさは2種類あるはずで、1つ目は執筆者の分かりづらさ、2つ目は閲覧者の分かりづらさです。 @yumetodo さんの提案は後者を改善する手段を提供する上では有用ですが、前者が阻害されるので僕は反対です。
oki-miyuki commentedon Nov 28, 2017
先日 msbuild 使うためのバッチファイル書いてて、ここら辺ではまりました。
https://github.com/oki-miyuki/build-oss-library-on-windows/blob/master/script/inspect_vc.bat
MSが表形式で一覧を提供すべきなのに、どこにも無いのが情けない。
XMLとかで提供してくれれば、XSLTにかけて自動で生成とかできるんだろうけど。
fix: visual studio 2015 and 2017 version numbers.
faithandbrave commentedon Nov 28, 2017
ひとまず方針として、本サイトはできるだけ多くの情報を提供しますが、メンテナンスできる範囲内で作業を行うので、たとえばWindows環境で継続的に作業できる人がいないのであれば、開発ブログを含む公式サイトで確認できる情報程度を、本サイトのimplementationページにまとめることになります。
そのページは、コンパイラの実装状況ページと、ライブラリの動作確認したコンパイラが記載されているページからリンクされているので、コンパイルオプションやバージョン表記の詳細などは、そちらで確認することになります (コンパイルオプションなどもメンテナンスできる範囲での記載です)。
vector::emplace_backこのIssueでの問題は、コンパイラの実装状況ページと、ライブラリの動作確認したコンパイラの項に表記するバージョンを何にするかです。
implementationページに記載する内容としては、
_MSC_VERはたとえばWikipediaとかでメンテナンスされていますが、_MSC_FULL_VERはVisual Studio環境を持つひとがローカルで検証しないと記載できないように思います。_MSC_FULL_VERを記載する場合は、継続したメンテナが必要なように思います。faithandbrave commentedon Nov 28, 2017
それと、このIssueではメンテナンス性を向上させることを目標としているので、コンパイラの実装状況ページやライブラリの各ページでは、メンテナンスコストが高い
_MSC_FULL_VERは採用できないと思います。faithandbrave commentedon Nov 28, 2017
Visual StudioのCTP (Preview, ベータ版) で入る機能については、「次の正式版でこの機能が入る」という認識で本サイトで表記し、CTP版でどの機能が入るという紹介はしないようにしたいです。
また、CTPは何段階かリリースされるために使用期間が短いこともあり、CTPのどのバージョンでどの機能が入り、
_MSC_FULL_VERの値がいくつ、というのを確認するのは、作業の猶予期間が短いためにメンテナの負担が大きいです。saki7 commentedon Nov 28, 2017
@faithandbrave アキラさんの他にWindows環境で作業量が多い人に1名くらい心当たりはありますか？ その人にpingして、特に問題がないようなら提案通りの方針で良いと思います。
faithandbrave commentedon Nov 28, 2017
@egtra さんがMSVCでの検証をずっとやってくれていたのですが、ここ数ヶ月連絡がとれず… (別件で連絡をとりたいのですが)。ほかだと、MSVCの検証をしてくれた方は、Google SitesからGitHub Pagesに移行してからはいないと思います。
saki7 commentedon Nov 28, 2017
なら大丈夫でしょう。あとはお任せします
faithandbrave commentedon Nov 28, 2017
もう少し期間を置いて意見を募集することにします。週末しか見ない人もいるため、2017/12/04(月)中くらいまで意見を募集します。
私の最初の投稿では選択肢を示して終わっていましたが、「2017.5」のように製品の西暦バージョン + アップデートバージョンで表記することを提案します。
それが採用された場合は、implementationページに、その表記の意味 (ドットの次がアップデートバージョンであることなど) を記載するつもりです。
「2017 Update 5」よりも「2017.5」を提案する理由は、コンパイラの実装状況ページの表での横幅をあまり使わず済ませるためです。
yumetodo commentedon Dec 6, 2017
@faithandbrave そういえばこれはどうなりましたか？
add9288
をcommitした結果
_MSC_FULL_VERを使うのは諦めるとしても、製品バージョンで(15.4とか)で書いてあげたほうがただでさえバージョンを表すものが4つもある現状の混乱に拍車を掛けなくていいかなと思っていて2017.5という表記には賛成できません。faithandbrave commentedon Dec 6, 2017
@yumetodo さんが異論あるなら議論継続です。
14.xと15.xで混乱が起きているのが現状ですが、この混乱はバージョンアップのたびに今後もずっと続いていくものです。そのため、Visual C++バージョンと製品バージョンの混乱から脱却したいというのが、
2015.xのような表記の目的です。たとえば15.x表記に決めたとして、それを編集者が全てのページで14.xと書き間違えないかという問題があります。仮に14.xと書き間違えたとして、ほかの編集者はその間違いに気づきにくいです。
であれば、14.xと15.xという似た形式のバージョン表記から離れれば、どのバージョンを指すかが一意に決まってよいと思います。
2 remaining items
usagi commentedon Dec 6, 2017
このスレッド追ってなかったので今更になりますが、私も
2017.5の表記には反対です。理由は2017.5から2017 Update 5を暗黙的に容易には連想できないからです（さいきん UE4 の Windows ビルドの一部でやむを得ず MSVC++ を触りますが、少なくともその程度の私には連想できませんでした）。表のユーザーの視点で実用から考えると、
Visual Studio 2017レベルの表記Update 5レベルの表記cl.exeのバージョン表記（ 19.x という形であれ）以上の4点を1つの row で横並びに見られないと実用性、薄いです。
参考: https://mycomputeradventures.foxinnovations.be/docs/microsoft-development-build-numbers/
faithandbrave commentedon Dec 6, 2017
横幅問題が解決できれば (解説文章の列幅を狭くできれば)、
2017 Update 5表記で私は問題ありません。その場合は、implementationページに「cpprefjpでの呼称」のような列を追加しなくてもよさそうですね。「本サイトでは2017 Update 5のような表記を採用する」のような説明は書いたほうがよさそうです。
saki7 commentedon Dec 7, 2017
取り急ぎ横幅の見た目に対応したい場合は、以下の書き方を試してみてください。
どちらでも正しいですが、後者はcpprefjpのバックエンドがHTMLの実態参照に対応していなかったはずなので、動かない可能性が高いです。前者は多分動くと思います。
faithandbrave commentedon Dec 7, 2017
まず結論ですが、
2017.5もしくは2017 Update 5のどちらか、という点では議論締め切り時点で @yumetodo さん以外からの合意がとられたものと理解しています。@yumetodo さんからの反論を解決して
2017 Update 5の表記になることで問題ないと判断できるかと思います。ですので、それを結論とさせてください。このIssueは、既存のバージョン表記を私の方で修正したら完了としようと思います。
implementation-statusページとimplementationページは個別に対処し、それ以外のリファレンスページは、スクリプトを書いて自動変換しようと思います。自動変換の方はPull Requestを提出します。
saki7 commentedon Dec 7, 2017
🎉
ここのPull requestに関しては、承認が必要なものではないと認識していますので、セルフマージして構いません。その場合でも、branchは消さないようにお願いします。変換で問題が起きた際は、気づいた人がPull requestをrevertしてください。そのときbranchが残っていれば、改めてマージできます。
saki7 commentedon Dec 9, 2017
補足ですが、
<nobr>は https://github.com/cpprefjp/markdown_to_html/blob/a567e5b66ba5523724f671a87d1ffcad550dd44d/html_attribute.py#L17-L126 ここに含まれていないので多分変換に失敗します。現状ではおそらく解決策は無いですyumetodo commentedon Dec 9, 2017
@saki7 どっか
<nobr>紛れ込んでましたっけ・・・？saki7 commentedon Dec 9, 2017
@yumetodo 僕がこの上のコメントで横幅問題の暫定対策方法として書いてます
Visual C++のバージョンフォーマットを、製品バージョンから、西暦バージョン + アップデート番号に変更 #483
言語階層のVisual C++バージョンのフォーマットを、製品バージョンから西暦バージョンに変更 #483
自動変換できなかったVisual C++バージョンのフォーマットを、製品バージョンから西暦バージョンに変更 #483
スタイルページ : Visual C++バージョンのフォーマットを、製品バージョンから西暦バージョンに変更 #483
処理系ページ : Visual C++バージョンのフォーマットを、製品バージョンから西暦バージョンに変更 #483
コンパイラの実装状況 : Visual C++のバージョンフォーマットを製品バージョンから西暦バージョンに変更 #483