処理系/VC++: バージョン表記の表の構成を見直す

[yumetodo]

そもそもこの表の役割は

#525 (comment) by @sayurin
ある製品に対し、それを表すバージョンが複数存在するため整理することこそが、この表が用意された目的

であると思われる。

#521, #525 より、Visual StudioのバージョンとVisual C++のバージョンは一対一対応しないことがわかった。ところが #483 で、西暦ベースのバージョニング(ex. 2017 Update 5)をすでに採用している。

そこで

#525 (comment) by @akinomyoga
現在の 2017 Update 6, etc. 基準の列挙はやめて、v141 や v14.11 などをベースとして表を作り直した方が良いのでしょうかね

を採用し、

Visual C++ バージョン	_MSC_VER	_MSC_FULL_VER	Visual Studio の製品名 (例)	製品バージョン(例)
14.13	1913	191326128	2017 Update6	15.6

をたたき台に表を改変し、cpprefjp各所にある2017 Update 5のような表記に該当する主なVisual C++ バージョンを発見できるようにすることを提案する(つまり #483 の方針は維持)。

論点

• そもそもVisual C++ バージョンを基準にするのは妥当か？
• Visual C++ 6.0やDDKを考慮した上でどう表をまとめるか(<th>タグ該当箇所など)

ref:

• 処理系ページのVisual C++の記載について #524

[faithandbrave]

んー。見方が逆だと思うのですが、コンパイラの実装状況ページに記載されているコンパイラバージョンと、リファレンスページに記載されているコンパイラバージョンから、その人の知っているバージョン形式を調べるための表です。
ですので、それらのページに掲載されているバージョン形式が、表の一番左の列である必要があります。

[faithandbrave]

それと、さらに情報を足しますと、本サイトでは言語のバージョンが記載されていないものについて、C++98/C++03からサポートされている機能であるとする規定があります。
そのため、C++98/C++03から存在する機能については、リファレンスページで処理系バージョンを記載する必要がありません。ですので、処理系ページに記載されているVisual C++ 6.0やDDKのバージョンを、そのページ以外からcpprefjpサイトで使用することは少なくともありません。
なので、それらについては処理系ページでユースケースが閉じていると考えてください。

[yumetodo]

@yumetodo 今ちゃんとしたキーボードがないから明日の夜に書くつもりhttps://t.co/zcGB3qaY1l

— akinomyoga (@akinomyoga) March 9, 2018

[faithandbrave]

私の考えとしては、14.xと15.xは今後ずっと続く「バージョンの意味がVisual StudioのものかVisual C++のものかがわからない」という混乱を回避するために、どちらも使いたくないです。これは #483 で述べたときのままです。

それを踏まえた上で私の提案ですが、以下のどちらかがよいと思います。

1. 「2017 Update 6」のような現状のバージョン表記を維持して、注釈として「そのアップデートに含まれている最新バージョンを指す」のような説明を書く、
2. もしくは「2017.6」のような西暦バージョン + Visual Studioのマイナーバージョンという独自バージョン形式を作る (1列増やす)

Visual Studio (Visual C++) のユーザーが、いま広く認識しているバージョンは、14.xでも15.xでもなく西暦バージョンの方だと思います。2003を7.1、2005を8.0、2008を9.0、2010を10.0まではVisual C++バージョンで認識していたユーザーが多いですが、いまは西暦バージョンが基準に考えられていると私はとらえています。
ですので、調べる最初のキーは西暦バージョンにしたいです。

[yumetodo]

ええっと、私が #483 をひっくり返したいとかそういうことではないというのが伝わりきっていないようです。

西暦バージョンが基準に考えられているのはその通りで私自身もそうです。で、ところがVisual StudioのバージョンとVisual C++のバージョンは一対一対応しない。じゃあこの表はどうするのか、それをこの表に求められる役割から考えた結果、

それらのページに掲載されているバージョン形式が、表の一番左の列である必要があります。

という現状をやめて、Visual C++のバージョンを基準にしようという話です。

あと #483 でも述べましたが2017.6は混乱に拍車を掛けているだけにしか見えません。

[faithandbrave]

いえ、理解してます。
ですが、表はデータベースの主キーと同じように、一番左の列をキーとして、値となる以降の列を参照する、のような対応付けとして使われます。
ですので、以下のように書きました。

それらのページに掲載されているバージョン形式が (2017 Update 5 引用のための追記)、表の一番左の列である必要があります。

[yumetodo]

ええっと、 @akinomyoga 氏が書き込むまでちょっと自分の意見を整理します・・・

[akinomyoga]

私が現在考えているのは以下のような物です。何故このようにするかは取り敢えず省略しますが、考え方の大筋は @faithandbrave 様と同様です。

• 一番最初の列として「当サイトの表記」を増やす。形式は 2017 Update 6 の形式。
• 製品名の欄には実際に存在した名称 (の総称) を用いる (最近のものについては Visual Studio をつける)。(追記: もちろん、そのことの注記を加える)
• 製品バージョンについては該当するものがない場合もあるということ、また、表の横幅が大きくなりすぎないようにしたいということから、"製品バージョン" は該当する場合に "製品名" の列に付記する。
• 他の列の順序は変えない

例

表記	製品名 [Visual Studio バージョン]	VC++ バージョン	_MSC_VER	_MSC_FULL_VER
2017 Update 6	Visual Studio 2017 Update 6 [15.6]	14.13	1913	191326128
2017 Update 5	Visual Studio 2017 Update 5 [15.5.7] Visual Studio 2017 Update 5 [15.5.6]	14.12	1912	191225835
	Visual Studio 2017 Update 5 [15.5.4]	14.12	1912	191225834
	Visual Studio 2017 Update 5 [15.5.2]	14.12	1912	191225831
2017 Update 4	Visual Studio 2017 Update 4 [15.4.5]	14.11	1911	191125547
	Visual Studio 2017 Update 4 [15.4.4]	14.11	1911	191125542
2017 Update 3	Visual Studio 2017 Update 3 [15.3.3]	14.11	1911	191125507
2017	Visual Studio 2017 [§注1] [15.0]	14.10	1910	191025017
2015 Update 3	Visual Studio 2015 Update 3 [14.0]	14.0	1900	190024210
2015 Update 2	Visual Studio 2015 Update 2 [14.0]	14.0	1900	190023918
2015 Update 1	Visual Studio 2015 Update 1 [14.0]	14.0	1900	190023506
2015	Visual Studio 2015 [14.0]	14.0	1900	190023026
2013 Update 5	Visual Studio 2013 Update 5 [12.0]	12.0	1800	180040629
2013 Update 4	Visual Studio 2013 Update 4 [12.0]	12.0	1800	180031101
2013 Update 3	Visual Studio 2013 Update 3 [12.0]	12.0	1800	180030723
2013 Update 2	Visual Studio 2013 Update 2 [12.0]	12.0	1800	180030501
2013 Update 1	Visual Studio 2013 Update 1 [§注2] [12.0]	12.0	1800	180021005
2013	Visual Studio 2013 [12.0]	12.0	1800	180021005
2012 Update 4	Visual Studio 2012 Update 4 [11.0]	11.0	1700	170061030
2012 Update 3	Visual Studio 2012 Update 3 [11.0]	11.0	1700	170060610
2012 Update 2	Visual Studio 2012 Update 2 [11.0]	11.0	1700	170060315
2012 Update 1	Visual Studio 2012 Update 1 [11.0]	11.0	1700	170051106
2012	Visual Studio 2012 [11.0]	11.0	1700	170050727
2010 SP1	Visual Studio 2010 SP1 [10.0]	10.0	1600	160040219
2010	Visual Studio 2010 [10.0]	10.0	1600	160030319
2008 SP1	Visual Studio 2008 SP1 [9.0]	9.0	1500	150030729
2008	Visual Studio 2008 [9.0]	9.0	1500	150021022
2005 SP1	Visual Studio 2005 SP1 [8.0]	8.0	1400	140050727
2005	Visual Studio 2005 [8.0]	8.0	1400	140050320
	Windows Server 2003 SP1 DDK (for AMD64)		1400	140040310
2003 SP1	Visual Studio .NET 2003 SP1 [7.1]	7.1	1310	13106030
	Windows Server 2003 SP1 DDK		1310	13104035
2003	Visual Studio .NET 2003 [7.1]	7.1	1310	13103077
	Visual Studio Toolkit 2003 [7.1]	7.1	1310	13103052
	Windows Server 2003 DDK		1310	13102179
2002	Visual Studio .NET (2002) [7.0] Visual C++ .NET [7.0]	7.0	1300	13009466
	Windows XP SP1 DDK		1300	13009176
	Visual Studio 6.0 SP5 Visual C++ 6.0 SP5	6.0	1200	12008804
	Visual Studio 97 [5.0] Visual C++ 5.0	5.0	1100
	Visual C++ 4.2	4.2	1020
	Visual C++ 4.1	4.1	1010
	Visual C++ 4.0	4.0	1000
	Visual C++ 2.0	2.0	900
	Visual C++ 1.0	1.0	800
	Microsoft C/C++ 7.0		700
	Microsoft C 6.0		600

追記: こんな感じ

[akinomyoga]

ところで、"製品バージョン" や "Visual C++ バージョン" の定義は明確に記述したほうが良いように思います。つまり、どのような方法で確認した時に表示されるバージョンのことを "○○バージョン" と呼ぶのか、ということです (実のところ、そこらじゅうに様々なバージョン表記があります)。検証可能でないし今回のように大きく変更するときにどのように取り扱えば良いかが分かりません。

というか私自身がよく分からなかったのですが、@yumetodo 様、教えて頂ければ幸いです。

参考

• site/implementation.md at master · cpprefjp/site
• _MSC_VERと_MSC_FULL_VERをまとめる - Qiita
• Visual C++ 2017のバージョン番号がややこしすぎる件 - Qiita

[yumetodo]

@akinomyoga Visual StudioのバージョンとVisual C++のバージョンは一対一対応しない件についてどうするのか見えないのですが・・・？

---

ところで、"製品バージョン" や "Visual C++ バージョン" の定義は明確に記述したほうが良いように思います。

少なくとも私が検証している_MSC_VER/_MSC_FULL_VERについては下記プログラムの実行結果(IntelliSenseはマクロの値をcl.exeとは別に持っているので信用してはいけない)

#include <iostream>
#include <cstdlib>
int main()
{
	std::cout
		<< "_MSC_VER: " << _MSC_VER << std::endl
		<< "_MSC_FULL_VER: " << _MSC_FULL_VER << std::endl;
	std::system("pause");
}

製品バージョンは、ヘルプ→Microsoft Visual Studio のバージョン情報

で確認しています。

"Visual C++ バージョン" は・・・今までPlatformToolsetのv141とかから変換して読んでいたんだけど要求有効桁数も増えたのでもっと直接的に調べるには

>cl.exe
Microsoft(R) C/C++ Optimizing Compiler Version 19.12.25835 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

使い方: cl [ オプション... ] ファイル名... [ /link リンク オプション... ]

のように開発者コマンドプロンプトからcl.exeを叩くしかないかな

[akinomyoga]

@akinomyoga Visual StudioのバージョンとVisual C++のバージョンは一対一対応しない件についてどうするのか見えないのですが・・・？ by @yumetodo

あれ、すみません。その点について書いたはずなのですが、編集の過程で消してしまったみたいです。@faithandbrave 様の考えと同様です。その製品での最新版 (というか既定で選択されるツールセット) について記述するという方針です。そしてその旨を注記する。

ただ、ちょっと確認しなければならないなと思っているのは、最新でないツールセットについて独立の _MSC_VER / _MSC_FULL_VER が割り当てられる (つまり以前の Visual Studio の最新版ツールセットでも使われていなかった _MSC_VER / _MSC_FULL_VER が割り当てらる) 可能性があるかどうかということです。もしそういうことがないのであれば、余り気にしなくて良いかなという気がします。もし、そのようなことがある場合、それを表に含めるか含めないか・含めるとしたらどう記述するかなどについて、考えなくてはなりません。

>cl.exe
Microsoft(R) C/C++ Optimizing Compiler Version 19.12.25835 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

by @yumetodo

これで確認できるのは寧ろ _MSC_FULL_VER の値 (と等価なバージョン番号) だと思うのですが、どのように VC++ バージョンを決定するのでしょうか。ツールセットの番号と cl.exe のビルド番号を合成するということでしょうか。

[sayurin]

（読んでますがまずは口を挟まず経過を見守っています。）

最新でないツールセットについて独立の _MSC_VER / _MSC_FULL_VER が割り当てられる (つまり以前の Visual Studio の最新版ツールセットでも使われていなかった _MSC_VER / _MSC_FULL_VER が割り当てらる) 可能性があるかどうか by @akinomyoga

Visual C++ 2017 Update 6、15.6.1でインストールできるcl.exeを確認してみました。

19.13.26128.0
19.12.25833.4 <= 191225835 (Visual C++ 2017 Update 5)
19.11.25548.2 <= 191125547 (Visual C++ 2017 Update 4)
19.00.24231.0 <= 190024210 (Visual C++ 2015 Update 3)

うんまぁバラバラですね。

[akinomyoga]

@akinomyoga Visual StudioのバージョンとVisual C++のバージョンは一対一対応しない件についてどうするのか見えないのですが・・・？ by @yumetodo

確認してみたところ、既定でインストールされるツールセットは依然として一つだけのようですね。Visual Studio Installer で手で指定すれば追加することができるということのようです。これは Update 5 でも Update 6 でも同様でした。つまり、既定でインストールされているものとの1対1の対応はあると考えて問題ない様に思います。

---

@sayurin 様、確認ありがとうございます! インストールに手間取ってなかなか確認できていないところでした。

[yumetodo]

つまり、既定でインストールされているものとの1対1の対応はあると考えて問題ない様に思います。

既定じゃないものが選べる時点でまずくないかなと思うんですが。わたしが提示した例で(例)をつけているのはその辺の対応なので