タグ

ブックマーク / dechimal.hatenadiary.com (9)

  • な〜にがStrongTypedefじゃ - デ-mk6

    この記事はC++ Advent Calendar 2012の20日目の記事です. 前の記事 : Boost.Asioによる非同期関数呼び出しと、非同期ノンブロッキングFuture 次の記事 : CEANによる配列操作 導入 ある型に別名を付けるtypedefに対して,ある型を元に新しい型を作る機能をstrong typedefと言います.もちろんC++の仕様としてそのようなものがあるわけではなく,Boost.Serializationにマクロとして実装されているほか,同様のマクロによる実装がいくつかあります. なぜこのようなものが必要かという話ですが,世の中にはグーグル=センセイという実際博識なセンセイがいらっしゃいますので,氏にお尋ねいただくのがよろしいかと思います. ところで,Boost.Serializationにあるstrong typedefには制限があり,適用範囲が組み込み型に

    な〜にがStrongTypedefじゃ - デ-mk6
  • C++/CLIについてのよくある誤解 - デ-mk6

    以前にも書いたような気がしますが、もう一度書きます。C++/CLI(仕様の邦訳)は、.netからC++やその他ネイティブコードのライブラリを楽に使えるようにするためと、そのための作業を楽に行うための言語です。「.netで使えるC++」ではありません。そういうことを言う人は悉くこの言語の厳つい顎で頭を砕かれ、手足をもがれて、腸をらい千切られ死にます。それが摂理なのです。あらがえません。C++/CLIは大きく分けてC++と、C++風構文を持つ何か.netっぽい言語(ここでは仮に「Cヰ」と呼びましょう)からなる、キメラです。二つの言語のコードは一つのファイルに混ぜて書くことができます。C++の部分はそのままC++です。何も違いはありません。GCもありません。ありませんが.netのGCにネイティブオブジェクト(要するにC++で作ったオブジェクト)を通知して管理させる方法はあります。interfa

    C++/CLIについてのよくある誤解 - デ-mk6
    Akineko
    Akineko 2010/06/07
  • プリプロセッサ基礎文法最速マスター - デ-mk6

    最速だけに催促されたので書きますね! 1.基礎 印字命令を見てみましょう。 lesson1-1.cpp 123 abc AAAAAAAAAAAAAAAAA!と書いたファイルを実行すると、 123 abc AAAAAAAAAAAAAAAAA!このようになります。見てのとおり書いたまんま印字されるので、特に印字するための命令とかはないです。これだけだと「おいプログラミング言語ちゃうんかボケが!」と罵られること請け合いなので、印字以外の命令を見ましょう。 lesson1_2.cpp #define FOO 1 #define BAR A FOO BAR FOO FOO BAR結果は、 1 A 1 1 Aと印字されます(改行は適宜省略しています)。 「#define HOGE PIYO」と書くと、「以後に登場するHOGEをPIYOに置き換えますよ」という命令です。記号以外の文字が置き換え後として使

    プリプロセッサ基礎文法最速マスター - デ-mk6
    Akineko
    Akineko 2010/02/05
  • 全部前にもってくる - デ-mk6

    型修飾子を識別子の前に持ってこれるようにした。 #if !defined EXIST_DECLARE_HPP_INCLUDED #define EXIST_DECLARE_HPP_INCLUDED #include <boost/function_types/function_type.hpp> #include <boost/function_types/member_function_pointer.hpp> #include <boost/function_types/parameter_types.hpp> #include <boost/function_types/property_tags.hpp> #include <boost/mpl/back_inserter.hpp> #include <boost/mpl/begin.hpp> #include <boost/mpl

    全部前にもってくる - デ-mk6
    Akineko
    Akineko 2009/12/17
  • 本を積んでみた - デ-mk6

    http://d.hatena.ne.jp/RiSK/20090709/1247119159 その他みなさん 私も参加。写真機を持っていないので念写した。でもあんまりないなぁ…

    本を積んでみた - デ-mk6
  • tieで初期化させろ - デ-mk6

    #include <boost/preprocessor/tuple/elem.hpp> #include <boost/preprocessor/tuple/rem.hpp> #include <boost/preprocessor/seq/fold_left.hpp> #include <boost/preprocessor/arithmetic/inc.hpp> template<size_t N, typename T> typename std::tuple_element<N, T>::type & get_with_tuple_ref_collapsing(T & tup) { return std::get<N>(tup); } template<size_t N, typename T> typename std::tuple_element<N, T>::type &&

    tieで初期化させろ - デ-mk6
    Akineko
    Akineko 2009/08/31
  • REIGAI REIGAIせよ! - デ-mk6

    昨日のカオスの続き。 例外は「エラーを取り扱う手段の一つ」として考案されたもので、それ以外を扱うのはマナー違反。よって例外を投げることはエラーであることを上位レイヤーに報告するものであるが、エラー自体は必ずしも例外ではない(ほかにも手段はある) どういったものがエラーなのかについては、関数にとって何が正常なのかを定義して、その否定がエラーである、と考えればなんとかなるんじゃないか? そのためには多分関数が何であるかが決まってる必要があるんじゃないか。例えば「ファイルをオープンする」とか。 で、正常ってのが関数が何であるかに従って動作している間のことで、正常なまま終了するとそれは正常に終了したってことでいいか。 例外が飛んできて捕捉して続行した場合はなんだろう?捕捉して続行したということは、その関数にとっては想定内の出来事だったのでエラーではない? 想定内だとエラーじゃないのか?どうなんだ?

    REIGAI REIGAIせよ! - デ-mk6
  • そろそろれいがいさんへの思いを適当にまとめる - デ-mk6

    関数が何であるかを決めないとエラーが何であるかを決められない エラーは例外以外でも表現できる エラーのときは関数終了してエラーを通知する エラーを例外で通知する場合は、とりあえず今知ってることを適切な型の値として投げる(多分適切な型ってのがアレな部分) 例外を投げられる側は、どれが捕捉して加工して再度投げるべきで、どれが捕捉して対処して続行すべきで、どれが知らんぷりで通す例外なのかを考えるんば エラーを通知される側は例外で通知されるとめんどいことのほうが多い気がする…というのも例外は構文的に陶しい。 捕捉するための構文として型パターンマッチだけでは明らかに不足。もっと細やかな指定ができるような仕組みが必要。CSSのセレクタ?このへんは今の言語に求めても仕方のないところ 例外をラップして使うライブラリとか。wraith13さんのhttp://d.hatena.ne.jp/wraith13/

    そろそろれいがいさんへの思いを適当にまとめる - デ-mk6
  • れいがい! - デ-mk6

    例外むずい。むずいから考える。考えても全然文章にならないので言葉の断片を並べる。以下ではレイヤーとスコープはだいたい同義だと思う。 例外はいつ使うべきなのか? エラーであることの表現として使うとすると、あるレイヤーで、そのレイヤーから分かる情報だけでは対処不能な状況に対して、より多くのコンテキストを持っているであろうと予想される上位のレイヤーに対してその対処を委ねる手段となる? 関数が例外を投げる理由 どんな状況をエラーとするのか? アサートとエラーと例外 上位レイヤーが必要としている情報 エラーを例外として表現するレイヤーが用意できる情報 あるレイヤーが捕捉して対処できる例外とそれ以外の例外 あるエラーに関する例外が全てそのエラーに対応する例外用の型もしくはその派生型で表現するべきというコンベンションがあるなら、検査例外は十分に有効なはずじゃないの?それでも私がこうやってうなってるのは何

    れいがい! - デ-mk6
  • 1