Modern C++ Design(Loki)のTypeList(これは古い日記です) - Diary(uid)
今日の日記はModern C++ Designを読んだ人とかLoki(Modern C++ Designで解説されているライブラリ)を使ったことのある人しか意味がわからないと思うのでご了承ください。 Modern C++ Designでは、型のリスト「TypeList」を可変長に扱うため、TYPELIST_1 〜 TYPELIST_50まで、要素の数に応じたマクロを用いることで対応している。つまり、 #define TYPELIST_1(T1) Typelist<T1, NullType> #define TYPELIST_2(T1, T2) Typelist<T1, TYPELIST_1(T2)> #define TYPELIST_3(T1, T2, T3) Typelist<T1, TYPELIST_2(T2, T3)> // ... #define TYPELIST_50(T1, T
手軽な低レベルプログラミング環境として GBA はもっと評価されるべき
とりあえず開発を始めるにあたっては特殊なハードウェアなどは必要なくて、 コンパイルは gcc テストはエミュレータの VisualBoyAdvance といった流れで開発を進めます。 最後の最後に実機確認をする段階になったら、ロムイメージを書き込んで GBA の実機で実行させるためのマジコンが必要になりますが 当面は必要ありません。 まず VisualBoyAdvance で動けば実機で動きますし、その逆も真です。 ちなみに「Linuxから目覚めるぼくらのゲームボーイ！」などで用いられている ブートケーブル経由での開発はハードウェア資源の制限がキツくなるのでオススメできません。 コンパイルについては gcc で OK で、これは devkitPro r18 (buildscripts 20060412) をインストールすれば一式入ります。 Windows, MacOSX, Linux など
2008-10-01 - 兼雑記 ■[Program] デバッガとスレッドとイベント
実行パスが一つしか無くて、ユーザやらネットワークやら、外部とのインタラクションもブロッキングして読んで問題ないようなプログラムならいいんですが、まぁなんかそうもいかないことも多く、そういう時はスレッドやら select/epoll やら使ってごにょごにょしてるわけです。でまぁ、あろはさんのとこのコメント欄を荒らさせてもらったんですが、まぁデバッガに欲しいスレッドやらイベントサポートの話。なんとなくもやもや思ってることを適当にまとめてみます。 まずまだマシなスレッドの方。まぁ適当に 100 スレッドくらいのスレッドプールの中の一つのスレッドが SEGV したとする。さあデバッガの出番。とりあえず適当に現在のスレッドの値を調べてみたところ、なんかおかしな値が入ってたとします。でまぁ、シングルスレッドでバグが無いとしたら、レースコンディションです。でそいう時にとりあえず、 thread appl
![2008-10-01 - 兼雑記 ■[Program] デバッガとスレッドとイベント](https://cdn-ak-scissors.b.st-hatena.com/image/square/b978c5bdeb221158433e1bf43f86027422246c8a/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F12704346814673860805%2F8454420450066433267%2F1411772550)
感想: イベントVs.スレッドをhigh-conccurencyサーバを対象に して真面目に考え直してみた論文。
Rob von Behren, Jeremy Condit and Eric Brewer (UCB) Why Events Are A Bad Idea (for high-concurrency servers) Proceedings of HotOS 03, May 2003. 感想: イベントVs.スレッドをhigh-conccurencyサーバを対象に して真面目に考え直してみた論文。 Abstract イベントモデルは high-concurrency システムでは良いとされて きたが、それは間違いだ! (筆者らの信じるところによれば) イベントの良い点(高い並列性、低いオーバヘッド、シンプルな 並列モデル)などはスレッドでも達成できる。さらに、スレッドの 方がよりシンプルで自然なモデルでプログラムを書ける。 スレッドの弱さは本質的なものではなくスレッドパッケージの実装
はじめてのにき(2008-09-16)
_ イベントvsスレッド http://morihyphen.hp.infoseek.co.jp/log2/200809.html#091530 あー説得されるなぁ。 このへんは考えるたびに違う結論になる気がするんだよな。 今はスレッド派。 woさんと想定してる例が全然違う感じがして、 結局適材適所的なんじゃないかと思ったりとか。 一度イベント派vsスレッド派の宗教闘争とかするべきだな。 とりあえず前教えてもらった正反対の主張をはっておく。 http://www.spa.is.uec.ac.jp/~kinuko/survey/body/events-are-bad.html で、この話で僕がとりあえず最初に想定するのは webサーバ的なサーバで、 サーバの main thread が accept した fd を 別スレッド以下 slave とでも呼ぶに渡すとかそういう。 で、そいうモデル
最新 Google Toolbar で使える iGoogle ガジェットの作り方 - WebOS Goodies
先日、ついに Google Toolbar 5 の Firefox 版が公開されました。 IE 版から遅れること 10 ヶ月、ようやく Firefox でも最新機能が使えるようになったわけです。この Google Toolbar 5 にはさまざまな新機能がありますが、なんといっても注目なのは iGoogle ガジェットに対応したことです。任意の iGoogle ガジェットをカスタムボタンとして登録できるのはもちろん、ガジェットのパラメータに URL や選択文字列を指定することで、さまざまな処理を行わせることが可能です。 すでに Google ツールバー ボタンギャラリーでガジェット機能を活用した多数のカスタムボタンが公開されています。これらを利用するだけでもじゅうぶん便利ですが、このブログを読んでいる皆さんなら、きっと自分で作ってみたいと思うことでしょう。そこで、本日はこの Google
不良債権買取の仕組み - 漂流する身体。
昨日に引き続いての金融ネタである、米国政府が用意した75兆円の公的資金による不良債権買取枠だが、その後のニュースを見ると、ほぼ同種の債権について政府が買入入札を行い、安い順に政府が買っていくという仕組みらしい。つまり、「サブプライムローンを背景にしたMBSの03年ビンテージ」とか、何らかカテゴリーに分けて買取入札が行われるのである。それに対し、売り手の金融機関は、簿価100円に対して20円とか30円とか、売りたい金額をオファーする。結果、安値を呈示した順に政府が買い入れる、ということになる。これによって、安い順に買うから政府の損失は最小限になるだろうし、ある種の納税者向けの公平性は担保できるだろう。 また、この値付けがどこで決まるかと考えると、なかなか絶妙な仕組みである。金融機関にとってみると、この入札には、当然ながら売却による損失に自らが耐えられる金額でしか応札できない。従って、この値段
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
日本ベリサイン - Enterprise & Internet Security Solutions