C++11/14で書くにはdeferred async使ってやればいいけど、future::thenが来たらそれで実装してもいいのかもしれない。 future::then自体は提案とか読んでたりしてないからdeferredなのかasyncなのか、既にreadyでかつasyncなfutureをthenした時どこで走るのかとかそういうことを考え始めると困るかもしれない。

標準ライブラリの都合でMSVC12とかはとにかく酷いものになってるのでやめていただきたい。 C++14だと素直で良ても良い。

immediate

futureって未来に得られるかもしれない値を格納する感じのオブジェクトだけど、インターフェースとしてfutureを書かれると、「いや俺もう値持ってるし」みたいなときに（futureに直接値を仕込めないから）面倒で、じゃぁオーバーロードかー？というのもなんかなぁとなるので、即値をfutureでくるんでやるものが欲しい。

http://melpon.org/wandbox/permlink/ySucdA6uAo6BRKCu

実装としてはpromiseを使えば確かにできるんだけど、これshared stateをMT-safeにするオーバーヘッドが入るので、標準ライブラリの実装としてはMT-safeである必要はないようにもできるかもしれない（shared_futureは今のところ考えてなかったから問題はあるかもだけど）。

2015-06-20

MSVC（に同梱されているcl.exe）のTwo-phase name lookupが未実装というのはどういう挙動をするのかという備忘録

C++

Boost.勉強会の立ち話で id:redboltz さんからMSVCのTPLが未実装ということについて、詳細を聞いたので確かめてみた。

まぁ聞いたら話は簡単で、non-dependent typeであってもlookupがinstantiation timingまで遅れてしまうという感じ。

正しいTwo-phase name lookupの挙動は以下の様になる。

[Wandbox]三へ( へ՞ਊ ՞)へﾊｯﾊｯ

これを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

http://melpon.org/wandbox/permlink/St5rFyoF50zcegGp

http://gyazo.flast.jp/a29dc24650835c8dd09c21d1808e6bc3.png

2015-04-01

退職エントリ

特にない

退職エントリです。 Twitterで結構前から辞めるだのどうのこうのって騒いでたので、見てた人はわかると思いますが。

正確には本日が最終出社日で、4末の退職です。

特に現職にどうこう言うつもりも無いので淡々と報告となります。

で、次職ですが、さっき正式な通知がきた感じです。某所の某社です。

入社は5頭からになるかがわからないのでもしかしたら5月中は無職となる可能性があるけどまぁなんとかします。

2015-03-07

Boost.Fusion 1.58 updates

Boost Boost.Fusion

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

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のまま格納されると上のコードはコンパイルできない。

[Wandbox]三へ( へ՞ਊ ՞)へﾊｯﾊｯ

std::tuple

std::tupleのサポートは実は前々から存在してはいたんだけど、ドキュメントが無かったり、一分実装が抜けていたりした。今回ドキュメントを用意したし、大体実装されているはず。

std::tuple - develop

いくつかの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予定

2015-02-10

CrystaX NDKとBoost

Boost C++

私はAndroidの開発をするわけではないが、Googleが出すAndroid NDKとは異なったNDKがあるらしい。

CrystaX .NET

サイト名に.NETがついているがMicrosoftとは無縁の様。

で、そこの開発チームが最近Boostへ積極的に関わってきている。
いくつかのライブラリは動作が確認され、いくつかの修正も提案されているっぽい。

CrystaX NDK自体の開発とかは追って無いからわからないけど、チームはregression testの結果をコミットしているので今後徐々に修正が入るだろう。

Boost.orgが出しているregression testのsummaryはここ。

Boost.orgのページは他のプラットフォームがあったり、そもそも重かったりなので、CrystaXだけが気になるのであれば、開発チームがそこだけを抜き出して公開しているのでそちらを見るのが良い。

とはいえC++11/14の環境でAndroidの開発ができるのなら遊んでみるのも良さそう。

2014-12-15

便利かもしれないGCC builtin

Boost GCC C++

これは恐らく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)));
}