MSVC(に同梱されているcl.exe)のTwo-phase name lookupが未実装というのはどういう挙動をするのかという備忘録
Boost.勉強会の立ち話で id:redboltz さんからMSVCのTPLが未実装ということについて、詳細を聞いたので確かめてみた。
まぁ聞いたら話は簡単で、non-dependent typeであってもlookupがinstantiation timingまで遅れてしまうという感じ。
正しいTwo-phase name lookupの挙動は以下の様になる。
これをMSVC12に持ってくとこうなる
http://gyazo.flast.jp/6946ae3e7b533ce2ab610c5766789249.png
はー、なるほどね、たいへんだー
さて、VC14のCTPを出し始める頃にTwo-phase name lookupが新機能の予定に入っていてやっとか...となったわけですが、そのVC14のRCだとどうなるのかというと
http://gyazo.flast.jp/95b8c4057b8e0b0b7f50bcd0ca60d7bf.png
アッ、ハイ、
P.S. f*ck
Boost.Fusion 1.58 updates
Boost.Fusion 1.58は頑張ったし、Damien Buhlも頑張ったのでそれなりな更新がいくつかあります。 まだBeta出てない*1けどそろそろmasterがcloseしてbugfixのみになるので機能としてはfixした感じ。
主な新機能
- GitHub PR #12 Fusionのシーケンスを
boost::hash
で使えるように - GitHub PR #51
std::reference_wrapper
をサポート std::tuple
のサポート- GitHub PR #54 Fusionアダプタでの暗黙的な型推論をサポート
- ticket 9813, GitHub PR #14, GitHub PR #23, GitHub PR #26, GitHub PR #58 C++11/14 constexprのサポート
- いくつかのresult_ofをSFINAE-friendlyに
- ticket 10443
fusion::result_of::invoke
- GitHub PR #35
fusion::result_of::copy
fusion::result_of::move
fusion::result_of::swap
- GitHub PR #41
fusion::result_of::at_c
fusion::result_of::at
- ticket 10443
boost::hashのサポート
これまではFusionシーケンスは boost::hash
をサポートしていなかったので、Unordered Associative Containerに投げることができませんでした。
今回、新たに hash.hpp
が導入され、Boost.UnorderedへFusionシーケンスを投げることが出来るようになりました。
これはForward Sequenceであれば受け付けるので、アダプトしたシーケンスにも使えます。
#include <boost/unordered_set.hpp> #include <boost/fusion/include/vector.hpp> #include <boost/fusion/include/make_vector.hpp> #include <boost/fusion/include/equal_to.hpp> #include <boost/fusion/include/hash.hpp> // new int main() { boost::unordered_set<boost::fusion::vector<int>> m; m.insert(boost::fusion::make_vector(0)); m.insert(boost::fusion::make_vector(1)); }
今のところ、std::hash
は特殊化されていないので、std::unordered_{multi,}{map,set}
には直接使えませんが、boost::hash
を渡すことで同様のことが出来るようになります。
#include <unordered_set> #include <boost/fusion/include/vector.hpp> #include <boost/fusion/include/make_vector.hpp> #include <boost/fusion/include/equal_to.hpp> #include <boost/fusion/include/hash.hpp> // new int main() { std::unordered_set<boost::fusion::vector<int>, boost::hash<boost::fusion::vector<int>>> m; m.insert(boost::fusion::make_vector(0)); m.insert(boost::fusion::make_vector(1)); }
1.59には入れたいと思います。
std::reference_wrapper
boost::reference_wrapper
は前々から渡されたら通常の参照に展開するようになっていたんだけど、今回std::reference_wrapper
もそうなるようになった。
#include <functional> #include <cassert> #include <boost/fusion/include/vector.hpp> #include <boost/fusion/include/make_vector.hpp> #include <boost/fusion/include/at_c.hpp> int main() { int i = 0; auto v = boost::fusion::make_vector(std::ref(i)); boost::fusion::at_c<0>(v) = 1; }
reference_wrapper
のままでもええやんって思うかもだけど、reference_wrapper
のまま格納されると上のコードはコンパイルできない。
std::tuple
std::tuple
のサポートは実は前々から存在してはいたんだけど、ドキュメントが無かったり、一分実装が抜けていたりした。
今回ドキュメントを用意したし、大体実装されているはず。
いくつかのresult_ofをSFINAE-friendlyに
いくつかというのがミソ。1.59には全部をSFINAE-friendlyにしたい
アダプタでの暗黙的な型推論をサポート
これまでは構造体をアダプトするには型を書かないといけませんでした。
#include <boost/fusion/include/adapt_struct.hpp> #include <boost/fusion/include/at_c.hpp> namespace foo { namespace very_very_cool_namespace { typedef int how_quite_greatest_awesome_type; } struct bar { very_very_cool_namespace::how_quite_greatest_awesome_type hoge; very_very_cool_namespace::how_quite_greatest_awesome_type fuga; }; } BOOST_FUSION_ADAPT_STRUCT( foo::bar, (foo::very_very_cool_namespace::how_quite_greatest_awesome_type, hoge) (foo::very_very_cool_namespace::how_quite_greatest_awesome_type, fuga) ) int main() { foo::bar x = { 0 }; boost::fusion::at_c<0>(x) = 0xdeadbeef; }
very_very_cool_namespace::how_quite_greatest_awesome_type
を書くのは非常にだるいですし、構造体の変更に対して柔軟に対応できません。
一応これまでであっても型名の代わりにBOOST_FUSION_ADAPT_AUTO
を使えばBoost.TypeOfでの推論を使用できていましたが、依然として書かないといけないのは面倒です。
今回、Damienが頑張ってプリプロセッサしたところ、Variadic Macrosをサポートした環境では更に省略出来るようになりました。
#include <boost/fusion/include/adapt_struct.hpp> #include <boost/fusion/include/at_c.hpp> namespace foo { namespace very_very_cool_namespace { typedef int how_quite_greatest_awesome_type; } struct bar { very_very_cool_namespace::how_quite_greatest_awesome_type hoge; very_very_cool_namespace::how_quite_greatest_awesome_type fuga; }; } BOOST_FUSION_ADAPT_STRUCT( foo::bar, hoge, fuga ) int main() { foo::bar x = { 0 }; boost::fusion::at_c<0>(x) = 0xdeadbeef; }
C++11/14 constexprのサポート
#include <boost/fusion/include/vector.hpp> #include <boost/fusion/include/make_vector.hpp> #include <boost/fusion/include/at_c.hpp> int main() { constexpr auto v = boost::fusion::make_vector("foo", 0xdeadbeef); static_assert(boost::fusion::at_c<1>(v) == 0xdeadbeef, "Sadly, beef is daed ..."); }
見たまんまですね。これで不幸にも実行ができなくなってしまった環境であってもコンパイル時に計算できるので安心ですね。
C++14なら基本的にconstexprになってるはずです。C++11だといくつかがまだ対応出来てないです。少しずつなんとかしたいですね。
*1:3/11予定
CrystaX NDKとBoost
私はAndroidの開発をするわけではないが、Googleが出すAndroid NDKとは異なったNDKがあるらしい。
サイト名に.NETがついているがMicrosoftとは無縁の様。
で、そこの開発チームが最近Boostへ積極的に関わってきている。
いくつかのライブラリは動作が確認され、いくつかの修正も提案されているっぽい。
CrystaX NDK自体の開発とかは追って無いからわからないけど、チームはregression testの結果をコミットしているので今後徐々に修正が入るだろう。
Boost.orgが出しているregression testのsummaryはここ。
Boost.orgのページは他のプラットフォームがあったり、そもそも重かったりなので、CrystaXだけが気になるのであれば、開発チームがそこだけを抜き出して公開しているのでそちらを見るのが良い。
便利かもしれないGCC builtin
これは恐らくC++ Advent Calendar 2014の15日目です。
古来[要出典]より人々はいかに例外を投げた奴をトレースするかに命をかけてきた[要出典]。
投げられた例外自体や、そのメッセージを確認することはできるが、一体誰がその例外を投げたかという情報は一切乗らないからだ。
いっそのことsegfaultでもしてくれたほうがデバッガでスタックトレースを出力できる。
ある人は考えるだろう。
template <typename Base> struct exception_info : Base { explicit exception_info(const Base &base, const char *file, int line) : Base(base), file(file), line(line) {} virtual ~exception_info() noexcept {} const char *file; int line; }; template <typename E> [[noreturn]] inline void throw_(const E &e, const char *file = __FILE__, int line = __LINE__) { throw exception_info<E>(e, file, line); } { throw_(std::runtime_error("hogefuga")); }
残念。__FILE__と__LINE__はプリプロセッサで展開されてしまうので、throw_がある行とファイルが例外に乗って飛んでくる。
正解は
template <typename E> [[noreturn]] inline void throw_(const E &e, const char *file, int line) { throw exception_info<E>(e, file, line); } #define THROW(e) throw_(e, __FILE__, __LINE__) { THROW(std::runtime_error("hogefuga")); }
さて、関数名もほしい。C++11なら__func__が使える。GCCなら__FUNCTION__(場合によっては__PRETTY_FUNCTION__かもしれない)だ。
catchする側は今度受け取った例外オブジェクトがexception_infoから派生しているか確認して、fileとか取れるなら表示したい。RTTIで分岐するしかない。
とまぁ、ここまで来ると正直Boost使いましょう*1*2ってなる。なれ。
#include <boost/throw_exception.hpp> #include <boost/exception/diagnostic_information.hpp> { BOOST_THROW_EXCEPTION(std::runtime_error("Boooooooooooooost")); } catch (std::exception &e) { std::cout << boost::diagnostic_information(e) << std::endl; }
まぁでも、結局Boostもだいたい同じようなことをやっているので、エラー食らった後にいろいろやって、結果、例外を投げる的な共通関数をつくった時にはいい感じにBoostも使えない(そのいい感じの共通関数を呼んだ奴が結局誰かわからない)。
関数呼び出しもマクロで囲めば良いんだけど何でもかんでもマクロなのはほげふが〜ってなってしまうので、もうちょっとスマートな方法を探したい。
そんな時にはGCC 4.9以降*3*4で使える次のbuiltin関数*5を使うと良いかもしれない。
- __builtin_LINE()
- __builtin_FILE()
- __builtin_FUNCTION()
それぞれ、__LINE__、__FILE__と__func__に対応している。
これらは関数であるのでプリプロセッサで展開はされないし、デフォルト引数として使えば呼んだ奴のコンテキストで評価される*6。
実際に使ってみるとこうなる。
[Wandbox]三へ( へ՞ਊ ՞)へ ハッハッ
しかし自分でlineとか扱うとなると、先のBOOST_THROW_EXCEPTIONは使えないので、boost::throw_exceptionを呼ぶようにちょっと加工してやる。
template <typename E> [[noreturn]] inline void throw_(E &&ex, std::tuple<const char *, int, const char *> caller_ctx = std::make_tuple(__builtin_FILE(), __builtin_LINE(), __builtin_FUNCTION())) { boost::throw_exception( boost::enable_error_info(ex) << boost::throw_function(std::get<2>(caller_ctx)) << boost::throw_file(std::get<0>(caller_ctx)) << boost::throw_line(std::get<1>(caller_ctx))); }
これでnamespace下にthrow_を置いたり出来るし、もうちょっといろいろな関数を経由したりするときにはcaller_ctxを持ちまわってやれば良い。
私は更にbacktraceを乗せたりして使っているのでなにか参考になれば幸いだ。
shinano/exception.hpp at develop · Flast/shinano · GitHub
shinano/exception.cpp at develop · Flast/shinano · GitHub
あ、ちなみにclangは実装してないから。m9m9m9
returnとmoveと() ~ GCCを添えて
Boost.Move 1.56 で追加されたBOOST_MOVE_RET*1*2というマクロがあるのですが、GCC 4.9のC++14モードだけなぜかコンパイルできないと言う事象にぶつかってしまい、そういえばここらへんの暗黙のmoveとかって最後にドタバタしてたなぁと思いつつあんまりしっかり見ていなかったのですが、これを気に調べたのでまとめます。
基本的にコードを書いたりする上では気にする必要のない部分です。
BOOST_MOVE_RETマクロ自体はそれほど使い方が難しいわけではないですが、一応例示しておきます。
#include <boost/move/core.hpp> struct movable { BOOST_COPYABLE_AND_MOVABLE(movable) // copyもmoveもできる public: movable() { } movable(BOOST_RV_REF(movable)) { } // move ctor movable(const movable &) { } // copy ctor }; movable foo() { movable m; return BOOST_MOVE_RET(movable, m); }
上記コードは、C++03ではヘルパーを介しつつBoost.Moveを使ってmove ctorを呼びます。
一方、C++11以降では単に
movable foo()
{
movable m;
return (m);
}
へと置き換えられます。ところで、parenthesisで囲まれた式の型はdecltypeで調べれば解りますが、以下のようになります。
int i; decltype(i) // int decltype((i)) // int &
これは(おそらく)割と知られていると思いますが、これをふまえて、parenthesisで囲まれている先のreturn文はmove ctorが呼ばれるでしょうか。それともcopy ctorが呼ばれるでしょうか。
もしあなたが、答えに窮し以下の様な式でmoveとcopyどちらが行われるか疑問に思った場合、いい線をいってます。
movable foo()
{
movable m;
return m;
}
return文に渡された`m`という式の型は`movable &`ではなく`movable`ですが、これは確かにlvalueです。lvalueを渡しているのにmove ctorが呼ばれるでしょうか。
結論から言うとparenthesisで囲っていようがいまいがmove ctorが呼ばれます。そして、意外にもmove ctorが呼ばれる理由にはNRVOが関係してきます。
このreturn文での挙動はn3376 12.8 [class.copy] paragraph 31と32に記載があります。
paragraph 31ではcopy/move ctorを"実際"に呼ばなくていい条件(つまり、どういう時にNRVOを行ってよいか)を列挙していて、paragraph 32では、先の条件を満たした場合にはその式をどう評価するかと言うことが書かれています。
paragraph 31によると、return文では
- non-volatile automatic object
- オブジェクトの型とreturn typeが同じcv-unqualified type
の場合、copy/move ctorを省略出来ると書いてあります。
そしてparagraph 32では、paragraph 31の条件を満たしたオブジェクトがlvalueで渡されたとき、copyのために呼ばれるctorは、
- オブジェクトをrvalueとして扱った上でoverload resolutionする
- 先のoverload resolutionが失敗、若しくはctorの第一引数がrv-refでなかった場合は、オブジェクトをlvalueとして扱い再度overload resolutionする
- copy/move ctor呼び出しを"実際に"行わなくてもこの二段階のoverload resolutionは必ず実行される
とあります。
ちなみにこの文言だけではparenthesisで囲まれた場合moveできないと解釈できてしまうのですが、CWG DR1579でこの問題が解消されています。
ということで、return文でmove出来る謎が解決したわけですが、冒頭にも述べた
の場合、parenthesisで囲まれたオブジェクトを正しくrvalueとして扱わずにdelete指定されたcopy ctorを呼ぼうとしてしまうregressionがあります。
C++11 modeではコンパイル出来るので今のところあまり大きい問題では無いと思いますが、1.56.0のBOOST_MOVE_RETをC++14 modeのGCC 4.9で使用した場合はこの問題にぶつかってしまいます。
とてもひどい方法ですが、この問題にぶつかってしまった場合には
#define BOOST_MOVE_MSVC_AUTO_MOVE_RETURN_BUG #include <boost/move/core.hpp>
とすると回避できます。
GCCの修正かBoost 1.57のcloseのどちらか早いタイミングに合わせて修正を投げるつもりでいるので、1.57では改善されるはずです。
Boost.勉強会 #16で発表してきた
この発表したあとにBoostの開発のこと聞かれたり色々したので、やっぱりキチガイキワモノ達の発表もいいけど、こういう簡単なセッションもあったほうがいいんだろうなぁと思った。数回前まではアキラさん(id:faith_and_brave)が一周の旅とかやってたけど、ああいうの。
それはそうとして、30分あれば十分やろとか思って、じゃぁ30分でって言ったら、実は60分喋ってたらしいし、そういうところはもうちょっとしっかりしたほうが良かったかなぁと思った。
それはそうとして、タイトル、あーメール送らんとなぁと思いながら何話すかその時は具体的に決めてなかったので、適当に適当を重ねて送った結果、割と混乱というか変な期待をさせていた感じあったので、それも考えたほうが良かったなぁと思った。
まぁ色々反省はあるけど、アリスSOSは見れたのでトータルとしてOKだった。