はらぺこ日誌

ライブラリ API の設計手法を学ぼうシリーズの第2弾です。前回の記事はこちら。以下の教材を利用しています。

• C++ APIデザイン
  

さて、API のラッピングパターンについてはざっと読むだけで終了とし、今回は Observer パターンについてさらってみました。

MVC っぽいことをやってみたい。

本書では、オブザーバーパターンの説明に入る前に、 MVC アーキテクチャについての説明がありました。

シンプルなアプリケーションでは、コントローラはユーザ入力に基づいてモデルへの変更に影響を与え、こうした変更をビューに通信して、UIを更新できるようにする。しかし、実際のアプリケーションでは、通常、水面下のモデルへの追加変更を反映するために、ビューも更新する必要がある。(…中略…)とはいえ、先ほど述べたように、モデルコードはビューコードを静的にバインディングして呼び出すことはできない。そこでオブザーバーが必要になるのだ。

なるほどなるほど。とまぁ、こんな説明の後に Observer パターンの実装例とその説明に入っていくのを見せられたら、そりゃあまぁ、 MVC っぽいことをやってみたい、って普通思いますよね…??

ただ、上記にあるようにモデルがビューを監視できるようにする必要があるという話であるにもかかわらず、多くの MVC フレームワーク実装を見るに、ビューからのメッセージを受け取って何らかの制御を行うコードは通常コントローラに書かれているように見えます。現実的には、ビジネスロジックはフレームワークを差し替えても流用可能であることが望ましく、オブザーバーにするための抽象クラスの継承でさえ避けたいというのが実情なのではないかと思います。
(さらに…)

• Boost.勉強会 #14 東京 – boostjp
• ヲレが書いたメモ

というわけで boostjp 書記担当(?)の @T_MURACHI でございます。ご報告遅れましたが、 3/1 に開催された Boost.勉強会 #14 に行ってきました。過去ログ見る限り #4 以来なので 3年ぶりですか…。なんかもうそろそろコンパイラ的に C++11 使えるのも当たり前になってきて当時に比べてもだいぶいい時代になったなぁとか思ってみたり (M$ 除く)。

内容についてはメモに書いた以上のことを語り尽くせる自信がないので、以下、感想などを思いつきで綴ってみます…。

• 並列処理に関連する話題を取り上げた話が多かったように思います。トレンドというよりは、プロセッサなどのハードの進化の方向がもう完全にこっちに移行していっているが故の必然、といった感じなんですかね。GPGPU に関して言えば応用カテゴリはまだまだ限られている模様ですが…。
• cpprefjp の github 連携のための涙ぐましい… という程でもないとは思うんですが^^;、Google Sites なんて使い始めちゃったのが運の尽きっちゃあ運の尽きだったのかなぁとは… でも用意されたものにうまいこと順応できるよう対応する能力ってのはこのギョーカイで仕事やってる上で絶対重宝されると思うので、そういう意味でも良い経験をされたんじゃないかなと思います。
  • ていうか @melponn さんかわいい。
• 聴衆の食付きは glfw3 を使った GUI フレームワークの話が一番良かったように思います。なんだかんだ言ってみんなビジュアルグリグリ動かす系好きなんだなぁと…。 @hira_kuni_45 さん経験豊富そうで尊敬します… OpenGL 大好きで GCC 大好きで Unix ライクなのの方が好きそうなのにメインの開発環境が MinGW て… なんか某 R 社 (コピー機とか作ってる方) で働いてた時もそういう感じの方結構いらっさったような…
• その他、グラフアルゴリズムの話とか、 C# でやってることを C++ で実装したら…の話とか、どれも非常に興味深いお話でした。面白かった。
• 会場には江添さんもいらっさってましたね。ドワンゴステッカー配り始めたところで確信しましたが… 思ってたよりもなんだかずっと元気なちっさいオッサンって感じでした^^;。 @cpp_akira さんと C++WG の主査がどうのこうのとかで話をしていて平行線を辿ったりとかしていたのを見るにつけ、 C++ 標準化界隈も一枚岩じゃないんだなぁとか思ってみたり…

そんなこんなで、割とぶっ通しの 8時間。流石に疲れました…。参加された皆様も本当にお疲れ様でした。

このエントリは、C++11 Advent Calendar 2011 への参加記事です。

初心者表明を免罪符にするつもりは毛頭無いのですが、 C++0x/11 の学習、およびそれを用いた経験はまだまだ浅いため、内容的に拙い部分が多々あることを、あらかじめご容赦願いたいと思います m(_ _)m 。ていうか突っ込みだいかんげいでつ。

一応 ISO/IEC 14882:2011 の draft “n3242″ を参照しています。 GCC は 4.7 入れるの面倒だったので、動作確認できるものについては Ubuntu 11.10 に入っていた 4.6.1 を用いています。

Unicode に対応したリテラル

文字リテラルについてはドラフトの 2.14.3、文字列リテラルについては 2.14.5 に記述があります。
(さらに…)

なんとなく Virtual Box から利用している Ubuntu のアップグレードなどをして、そこからなんとなく「やっぱり Long Time Release 版の Ubuntu もテスト環境に持っておきたいよなぁ」などと思いつつ Virtual Box ディスクイメージを追加でこさえて、 Boost ライブラリのセットアップなどもしつつ動作チェックも兼ねて昔書いた記事なんぞを掘り起こしておりましたら、そこに書かれた内容に関連して、そういえば Boost.Regex も ICU ライブラリと組み合わせれば Unicode に対応できたはずだよなぁなどということが気になりだしてしまいまして、いろいろ試しているうちに、以下のようなサンプルコードが問題なく動作してしまうことを発見してしまったのでメモしておこうかと思った次第なのであります。ああ、なんだかこちらのブログも口調が個人ブログや普段の Twitter とかでのそれに似てきてしまいました (^_^;A 。
(さらに…)

• Boost.勉強会 #4 : ATND
• 前回

今回も必死こいてメモ執りましたよ。終盤力尽きたけど orz

• Boost.勉強会 #4 ノート

しかしさすがにこの年で一日通しはキツいっすなぁ…。

UTF-32 が内部文字列に使えないことがわかったので、 UTF-8 を内部文字列に使用するというルールで libiconv によるエンコーディング操作と Boost.Regex による正規表現の両方を同時に試すサンプルを作成してみました。

• sample/EncodeString.hpp
• sample/EncodeString.cpp
• sample/regex-test.cpp

Makefile は作ってません＼(^O^)／。試してみたい人は頑張ってコンパイルしてねｗ

$ g++ -std=c++0x -o regex-test regex-test.cpp EncodeString.cpp -lboost_regex

まともな環境 (Linux + GCC4.5 とか) なら上記コマンドで通るはず。libiconv を (glibc に上書きする形で) インストールしている場合は -liconv を末尾に入れる必要があるかも。そして MinGW を使う場合は更にもう一工夫必要かも (((;/^^)/
(さらに…)

C++0x では UCS に対応し、専用の型やリテラルの記法が導入されました。その関係で、以下の点について調査を行っていました。

1. C++0x で UCS を UTF-32 として扱う型 char32_t, u32string およびリテラル U"..." と、 libiconv の UCS-4-INTERNAL との間に互換性はあるか。
2. C++0x で新たに追加された正規表現ライブラリ <regex> は利用可能か。
3. <regex> が利用できない場合、 Boost.Regex を用いて UTF-32 文字列を処理することは可能か。

これらの調査は、すべて otoco のコアデータを扱うプログラム内で内部文字列に UTF-32 を採用することを前提としたものでした。
(さらに…)

• Boost.勉強会 #2 : ATND

実に楽しいイベントでした。 5時間ほぼぶっ通しだったのでさすがにくたびれましたが… (^_^;A

自分なりにメモしたノートを公開していますので、よかったら復習にご活用ください。かなり荒いメモですが…。
(さらに…)

Boost セットアップ中… orz

実は先日 HDD に物理的損傷らしきものを見つけてしまいまして、必要なデータだけ抜き取ってフォーマットを試みたら見事にエラーで止まりやがったのでやむなく新しいのに交換したのですよ。

ここ最近は忙しかったり体調も安定しなかったりだったので otoco の方の作業はずっと停滞してました…。やっと朝まともに起きれるぐらいに体調は戻ってきたので、そろそろ otoco の作業も復活したいなぁと思いつつ…。

ああそうだ、Linux も使えるように grub 入れ直さないと…。

Boost ライブラリの Ubuntu へのインストールは容易でした。単に libboost-dev パッケージを aptitude install してあげるだけです。

問題は、前回も書いた通り、 apt からインストールできる Boost のバージョンは通常で 1.34.1、最新のものを選んでも 1.37.0 になってしまう、ということです。

そこで、 otoco の開発に影響する範囲で、バージョン間にどの程度の差異があるのか、調べておくことにしました。

• Boost ライブラリ – バージョン間の差意について

とりあえず今思いつくのは正規表現まわりだけだったのでまだそこしか調べていないのですが (空文字列マッチは何気に影響範囲大きそうですが…古いバージョンで統一しておけばとりあえず問題にはならないかな…)、実際に開発が進めば利用範囲が広がり、都度気づく部分も増えていくかもしれません。上記ページはその都度更新して行く予定です。