仏教　愚か者と共同してはならない

　たまたま仏教について説明している文章をみました。その中には昔の偉人と言われている人の言葉が紹介されており、愚か者と共に歩いてはならない、と説いており、仏教というのは意外と諦めの宗教だったんだなと思います。

　ちなみに仏教は嫌いです。なぜなら、煩悩さえなければ苦しみや憎しみなど生まれないなどと説いてはいるものの、実際煩悩について人並み以上に悩む坊主のほうが煩悩が強いと思うからです。現代日本の坊主においては、ほとんどそのようなことなど考えず、割のいい商売としてやっており、キャバクラにも行きたいし高級車にも乗りたいし、いい家にも住みたいと内心思っているやつらばかりです。また、宗教法人は非課税です。正直仏教なんぞをありがたがる理由がありません。檀家システムによって、地域社会に根付いていることをいいことに惰性で続いているものとしか認識できません。

　しかしこの、愚か者と共同するなという旨の教えはなかなか正しいと思います。

倒錯の中で就職して結婚する弱者は危険

　つまらないものが嫌いで、面白い人生が好きだ。

　こんな自分にとって、「普通」という常識に凝り固まった人物はきっと自分にとって害になることのほうが多いだろう。本当にヘタに付き合う必要がないものだと付き合ってから気づくものだ。

　そういう人物ほどそれなりに自分の価値観を美化しているものだ。きっと最初はつまらない割にそれなりに大変だと思っていたのだろうが、そのうち「それでいい、と思えるにはどうしたらいいか」ということを無意識に脳内でまとめていく作業に入る。なぜなら逸脱するだけの力、知識、行動力が身につくように生きては来なかったし、おそらくそれからもそうはなれないからだ。そういった者が最終的に確立した自尊心というものは醜悪極まりなく、実力もない。地域社会でどうでもいい職につかせてもらい、しょぼい親になり、子に恨まれるのだろう。

　同じ国、同じ地域にいるからといって仲間の定義にはなり得ない。面白い奴と面白いことをする、又は人には言えない秘密の方法で面白い結果を出すに限る。ネット全盛の現在は本当にありがたい。地域社会はこれ以上のものにはもう成り得ないだろう。

VC++2013とboost1.55のスレッドとvolatile修飾子について

　VC++2010（まで？）では、スレッドと、スレッドワーカー（ここではファンクタ）が保持する変数へのアクセスについて、とある禁断の手法が使えていた。
　それは、ワーカーのメンバー変数にvolatile修飾子をつけることで、コンパイラの最適化を抑止し、最新の値をどのスレッドからでも読み書きできるようにすることで、ワーカーのメンバー変数を簡単に読んだり変更したりし、フラグの制御などに使うという手法だ。

　これは、コンパイラオプションやターゲットプラットフォームによって挙動が変わるため、単一環境に絞って使う以外ではもちろん非推奨だし、単一環境で開発するにしても推奨できる方法ではなく、エレガントではない。もちろん、スレッドワーカーのメンバー変数をこれぐらい簡単に読み書きできる言語というものがもっともエレガントなのだろうが、C++はそのようには出来ていない。ただこの方法は、とてもポータブルなので使いたくなってしまう。
　だが、VC++2013とboost1.55で試したところ、どうやらこの禁断の手法はデフォルトでは使えないようだ。コンパイラオプション等によってはできるのかもしれないが、試していない。
　まぁ、この方法を禁止することはいいことなんじゃないだろうか。

　で、代替として何を使うのか、ということなのだが、boost::threadに用意されているinterruption系のプリミティブを使う。もっとも安易な使い方としては。

　１．スレッドルーチン内（ワーカーのスレッド用関数）の任意の位置に、this_thread::interruption_point関数を配置。
　２．別スレッド（メインスレッド等）から、thread::interrupt関数を呼ぶ。

　これだけ。ただし、これだとワーカー内でのリソース解放等をうまく行うために、interruption_pointをどこに配置するか悩むことになる上に、場合によってはジレンマが発生し、配置場所を決められないということになるだろう。なので、この方法でスレッドに割り込み終了させるときは、例として、

  • 割り込みが成功し、thread::joinが呼ばれた後に、ワーカーの後始末処理を実行する。
    • 普通の感覚だと、ワーカースレッド内で終了前に後始末処理を行いたいところだが、割り込みによって終了させる場合、下記に示すような特別な機構を用意しないと難しいと思うので、簡単に行えればよいときはこういったもので良いだろう。
  • スレッド管理機構（クラス等）を作り、 this_thread::at_thread_exitで登録したスレッド終了時呼び出し関数において、スレッド管理機構に終了しようとしているスレッドIDを渡し、そのIDを元に目的のワーカーを探し、終了処理をさせる。

といった工夫が必要だろう。そんなんじゃなくてもっといいのあるわという人はそれで。

　this_thread::at_thread_exitで登録出来るスレッド終了時関数が、現在の理解では「void f(void)」型しか受け付けないようで、なんだか気が利かないなぁという印象。

VC++2013＋boost1.55のxpressive::smatchとwchar_tでエラー

　VC++2013とboost1.55の組み合わせをいろいろ試していておぞましい例に出会った。
　ビルドしているプロジェクトの文字コードはUnicode Character Setで今まで通り。なぜかこの環境でxpressive::smatchを使おうとするとエラーが出る。
　具体的にはsmatchの変数を宣言しただけだが、以下のようにエラーを出した。

e:\dev\lib\boost-trunk\boost\xpressive\sub_match.hpp(190): error C2664: 'int boost::mpl::assertion_failed<false>(boost::mpl::assert<false>::type)' : cannot convert argument 1 from 'boost::mpl::failed ************(__thiscall boost::xpressive::<<::CHARACTER_TYPES_OF_STREAM_AND_SUB_MATCH_MUST_MATCH::* ***********)(Char,char_type)' to 'boost::mpl::assert<false>::type'
3>          with
3>          [
3>              Char=wchar_t
3>          ]
3>          No constructor could take the source type, or constructor overload resolution was ambiguous

　な・・・なんじゃこりゃ。なんだかコンパイル時にsmatchがテンプレートで受け取った文字コードを受け付けず、mpl::assertion_failedで失敗しちゃってるのでwsmatchで変数を宣言してみたら出なくなった。
　・・・・・？？？？？
　いやぁ・・・なんというか・・・なんだこれ・・・。前は全く問題なかったのですが？？？

VC++2013＋boost1.54でエラー

　VC++2013は古めのboostがビルドすらできないので、最近のものを使うことになる。1.54をビルドしておいたのだが、使ってみたらバグがありエラーを出す。

　どうせなのでboostのSVNからtrunkを引っ張ってきてこまめにビルドしては使うことに。

boost1.55がめちゃ変わってて萎えぇ

　なかなか変わってくれたなという印象。そこそこの修正を余儀なくされる。今のところ以下のようなものに当たった。

  • this_thread::sleepが廃止される。1.56まではなんとなく残すとかなんとか。コンパイル時におかしなエラーが出て実質使えない。ｳﾋｬｰ
    • this_thread::sleep_for等が使えるが、時間を扱うためのライブラリがposix_time等からchronoメインになっているような感じ。変わりすぎでしょ。正直前のインターフェイスでなにが問題だったのかよくわからない（精度？）。
    • 以下のような感じで、xtimeを使ったsleepはサンプルにあるので残るのかもしれない。この使い勝手は昔となんら変わらない。インクルードするヘッダファイルが変わっている（1.46から見て）。this_thread::sleepが出て、便利だなと思ったから使うことに決め、xtimeによるsleepを置き換えたという経緯があるのにいきなりどんでん返しで廃止とはね・・・
#include <boost/thread/thread_only.hpp>
#include <boost/thread/xtime.hpp>
#include <iostream>

struct thread_alarm
{
    thread_alarm(int secs) : m_secs(secs) { }
    void operator()()
    {
        boost::xtime xt;
        boost::xtime_get(&xt, boost::TIME_UTC_);
        xt.sec += m_secs;

        boost::thread::sleep(xt);

        std::cout << "alarm sounded..." << std::endl;
    }

    int m_secs;
};

int main()
{
    int secs = 5;
    std::cout << "setting alarm for 5 seconds..." << std::endl;
    thread_alarm alarm(secs);
    boost::thread thrd(alarm);
    thrd.join();
}
    • こんな感じでもいいっぽい。
boost::this_thread::sleep_for(boost::chrono::seconds(1));
  • boost/strong_typedef.hppが廃止。boost/serialization/strong_typedef.hppを代わりに使えとコンパイル時に怒られる。

VC2013の感触とVisual Studio TV

　VS2013を起動すると、最初にガイド動画へのリンク等が表示され、IDEとしての便利さがそれぞれ説明されている。

　なるほど、このVisualStudioというIDEは、なんという高等なIDEへと進化したのだろうと感心する。いろいろ出来すぎでしょ・・・
　言いたくはないがMicrosoft先輩ぱねっす。

　チュートリアル的な小さいプロジェクトではパフォーマンスがよくわからないので、ソースが10万行ぐらいはあり、複数のプロジェクトで構成されているソリューションをビルドしてみた・・・・速い。
　気のせいだろうか・・・なんなんだこの速さは。まだ必要とはいえ、VisualC++2010とは一体なんだったのだろう。段違いでビルドの終了が速いわけだが・・・首をひねるしかないこの結果。VC++2010のインテリセンスの遅さ等から、駄作ではないかと思っていたがやはり・・以下略。