Clang with Microsoft CodeGen対応(Visual Studio 2015 Update1)

[yumetodo]

ついに！ついにVisual Studio 2015 Update1でClangが使えるようになった。 http://blogs.msdn.com/b/vcblog/archive/2015/12/04/introducing-clang-with-microsoft-codegen-in-vs-2015-update-1.aspx

というわけでそれに関して修正が必要な部分を探す。

[yumetodo]

とりあえずdefine周りで、_MSC_VER/_MSC_FULL_VERと__clang__が同時にdefineされる 状況に対応する必要があるな ・・・と思ったら

11 の作業でcompiler.hppを作ったおかげで多分対応できている！(実際に後でいれて確認してみます)

[Nagarei]

ちょっと試してみましたが、相変わらずclangではtry-catch-throwが使えないですね...。

error : cannot use 'throw' with exceptions disabled

[yumetodo]

相変わらずclangではtry-catch-throwが使えない

ええええ・・・・

[yumetodo]

あれ、やっとインストール終わって https://gist.github.com/yumetodo/dad352ffdc27c19cf825 試したけど普通に通るような。(ついでにconstexpr delegating constructorのテストもしたのでコード長いです。Clang with Microsoft CodeGenはもちろん、Update1のMSのコンパイラでも問題なしでした。なおったようで)

どんなコードでしょうか？

[Nagarei]

こんなです。

#include <iostream>

int main()
{
    try {
#ifdef __clang__
        std::cout << "clang" << std::endl;
#endif
#ifdef _MSC_VER
        std::cout << "VC++" << std::endl;
#endif
    }
    catch (...) { throw; }
    return 0;
}

clang for windowsを別に入れてるせいでしょうか？ いったんアンインストールしてみます。

[Nagarei]

clang for windowsのアンインストールやClang with Microsoft CodeGenのrepairもやってみましたが直らないです。 なんでだろう...。

[yumetodo]

え・・・、私は https://www.visualstudio.com/ja-jp/downloads/download-visual-studio-vs.aspx ここから落として、Visual Studio 2015がある環境に入れただけなんですが・・・。もちろんマルチプラットフォームのclangのチェックを入れて。

[yumetodo]

うーん、成功していたのはラグのせい・・か？ PC再起動したら動かなくなった・・・。

そもそも__has_include_nextマクロが定義されてないから、stdint.h/cstdintが実質つかえない・・・

それに__clang__マクロがdefineされていない・・・。 http://blogs.msdn.com/b/vcblog/archive/2015/12/04/introducing-clang-with-microsoft-codegen-in-vs-2015-update-1.aspx これの解釈を間違えてるのか・・・？ビルドツールセットでClang 3.7 with Microsoft CodeGen (v140_clang_3_7)を選ぶだけではダメなのか？

[yumetodo]

http://blogs.msdn.com/b/vcblog/archive/2015/12/04/introducing-clang-with-microsoft-codegen-in-vs-2015-update-1.aspx When changing from MSVC toolset, exception handling is currently off-by-default even though exception handling works. The developer can override this switch manually. The default will change in the next release.

げ・・・。throwはかけてもcatchできないということ・・・？

[yumetodo]

this switch manually

これがわかった。ビルドツールセットでClang 3.7 with Microsoft CodeGen (v140_clang_3_7)を選んでいる状態で、 構成プロパティ→C++→コード生成→C++の例外を有効にする を「はい」にすれば例外が使える！

・・・「テーブルをアンワインドする」ってなんだ

__clang__,__has_include_nextマクロが無い問題もIntelliSenseが対応してないだけで、早合点だった。

[Nagarei]

僕のところでもできました。 が、確認したところDxLibの方が対応してません。

error : unknown type name 'TCHAR'

どうやらtchar.hのこのコード

#ifndef _TCHAR_DEFINED
#if !__STDC__
typedef char            TCHAR;
#endif  /* !__STDC__ */
#define _TCHAR_DEFINED
#endif  /* _TCHAR_DEFINED */

によって、

• windowsヘッダの方でのTCHARの定義を抑制
• !__STDC__がfalseになっているためここでは定義しない

という風になっている模様です。

このTCHARの定義はTCHARがVCの言語拡張という意味でしょうかね？ だとしてもwindows.hの方の定義まで潰さないでほしい...。

[yumetodo]

C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\tchar.h

の1261行目ですか・・・。

https://msdn.microsoft.com/ja-jp/library/b0084kay.aspx ANSI/ISO C99 規格への準拠を示します。 /Za コンパイラ オプションが指定され、C++ コードをコンパイルしていない場合のみ、整数リテラルの定数 1 として定義されます。それ以外の場合は、定義されません。

なのでVSでは通ってたのか。これはVS側のバグだなぁ・・・。 しかも

#define _TCHAR_DEFINED

の位置が凶暴すぎる・・・。

これは_STDC__のdeifneを見て、自力で定義しろということかな・・・。

mingwのヘッダでは

#ifndef __TCHAR_DEFINED
#define __TCHAR_DEFINED
  typedef char _TCHAR;
  typedef signed char _TSCHAR;
  typedef unsigned char _TUCHAR;
  typedef char _TXCHAR;
  typedef int _TINT;
#endif

のようになっているので。

これ、バグレポ投げるべきですかね・・・？

-vオプションつけてコンパイルさせてincludeみたら、

1>  #include "..." search starts here:
1>  #include <...> search starts here:
1>   C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\Clang 3.7\include
1>   C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include
1>   C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\atlmfc\include
1>   C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt
1>   C:\Program Files (x86)\Windows Kits\8.1\Include\um
1>   C:\Program Files (x86)\Windows Kits\8.1\Include\shared
1>   C:\Program Files (x86)\Windows Kits\8.1\Include\winrt
1>  End of search list.

のようになっていたので

C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\Clang 3.7\include

にtchar.hをおいて欲しいですし。

[yumetodo]

いや、tchar.hをincludeしなければ大丈夫なのか。 でDxLibのどこでtchar.hはinclude されているんだ・・・？

[Nagarei]

define _TCHAR_DEFINEDの位置が凶暴すぎる・・・。

本当に、それさえまともならうまく動くのに...。 実際には定義しなかった場合でも、他の場所での明示的な定義をつぶすというのは悪しき仕様だと思う。

でDxLibのどこでtchar.hはinclude されているんだ・・・？

DxLib.h -> DxCompileConfig.h -> DxDataType.h -> DxDataTypeWin.h -> tchar.h です。 一応windows.hを先にインクルードすることでLoadGraphScreenのサンプルのコンパイルに成功しました。

[yumetodo]

一応windows.hを先にインクルードすることでLoadGraphScreenのサンプルのコンパイルに成功しました。

おお！

これはDxLib側で対処してもらうのが楽そうですね・・・。MSには絶対バグレポ投げてやりますが。

[yumetodo]

これをネタにQiitaに http://qiita.com/yumetodo/items/bd41f31f39dd590e8c80#comment-cbf3549e43d5ad5c82c9 を書いたんですが、

TCHARと__STDC__に関連して、 http://blogs.msdn.com/b/vcblog/archive/2015/12/04/introducing-clang-with-microsoft-codegen-in-vs-2015-update-1.aspx には、

If you get an "error : use of undeclared identifier 'O_WRONLY'", define in your project settings macro STDC=0.

とあるので、STDC=0 と定義してしまうのが良いのかもしれませんね。

というコメントが付きましたが、これ、注意書きに書く方向にします？DxLib側に要望出します？

[Nagarei]

MSがそういっているのであれば「STDC = 0を定義する」が良いと思います。 さしたる変更ではないですし、DxLib側にも要望を出しても良いかもしれません。

おかげさまでmsys2のインストールができました。

[yumetodo]

おかげさまでmsys2のインストールができました。

あ、予想外の結果・・・。

DxLib側にあとで書き込んでみます

[Nagarei]

あ、途中を削除したせいで文脈がおかしくなってる...。 「STDC = 0を定義する」はコンパイルオプションで定義するという事です。 「DxLib側にも要望を」は「tchar.hの前のwindows.hの読み込みを」です。

伝わっているとは思いますが一応。

[yumetodo]

最初読んだ時

define in your project settings macro

だから 「STDC = 0を定義する」 を要望ってDxLibの注意書きに書いてもらうということか？とか思いましたが、読みなおしてちゃんと理解できています

というわけで http://hpcgi2.nifty.com/natupaji/bbs/patio.cgi?mode=view&no=3708 投げました。 MSのバグレポってどこに投げるんだったかな・・・。 https://connect.microsoft.com/VisualStudio/Feedback http://blogs.msdn.com/b/vcblog/archive/2015/12/04/introducing-clang-with-microsoft-codegen-in-vs-2015-update-1.aspx どっちだろう

[Nagarei]

MSのバグレポってどこに投げるんだったかな・・・。

tchar.hのバグが、Clang with Microsoft CodeGenによって露見した形なので、 https://connect.microsoft.com/VisualStudio/Feedback の方ではないでしょうか。 間違えても誘導されるだけです。

[yumetodo]

https://connect.microsoft.com/VisualStudio/feedback/details/2122400 投げました。この英語力のなさ、どうにかしたい

[yumetodo]

多分とりあえず対応できているので一旦closeでどうでしょう。