はらぺこ日誌

C++ で開発する上で、クラスを一つ一つ実装するたびに毎回同じようなことを書かされるのは冗長なので、だいたいこんな感じになるよねという範囲のひな形を生成するスクリプトを perl で記述してみました。

• cppgen.pl

Getopt::Compact モジュールを使用しています。ご利用の際にはそちらも合わせてインストールしてあげてください。
(さらに…)

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

• C++ APIデザイン
  

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

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

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

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

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

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

これまた非常に初歩的な話なのですが…

• STL のコンテナ (std::vector とか) には基本的にオブジェクトへの参照を掴ませることはできない (領域確保の効率の問題とかでデフォルトコンストラクタが必須だから)。
• かといって、ナマポを掴ませるのは色々と危険 (意図せず寿命が切れて無効なポインタ掴まされた状態になったりとか)。
• そも non-copyable なオブジェクトを扱いたかったりと言った理由で値そのものを掴ませるのは却下したい (まぁ、いろいろあるんだよ…)。
• となると std::shared_ptr を噛ますのが順当かと思いきや…
• 必ずしもヒープに確保した (つまり、 new した) インスタンスだけを扱うとは限らないかもしれない。十分に寿命が長いことがわかっている自動変数やメンバ変数として確保したインスタンスのポインタをこのコンテナに突っ込んであげたい場合もあるかもしれない。
• そういう場合に std::shared_ptr 使っちゃって大丈夫なのか…??

(さらに…)

C++ の勉強ということでちょいちょいスモールケースを書いては意味もなく github に commit するということをやっているのですが…

• samples-for-blog/c++/minimal-cases/value-modifier-lambda at master · murachi/samples-for-blog

んー、何でしょうねこの雑なコード(^_^;A これ自体は確か、ステータスの変化を検知してステータスの種類にかかわらず共通の処理を自動で走らせるようにしたいんだけど、そうするとあれとこれとそれを変更しようとした時にあれを変更した時にもこれを変更した時にもそれを変更した時にも処理が重複して走っちゃうから無駄だよねってケースを想定して、じゃあ今あるステータスを全部一時的な構造体に突っ込んだものを引数にとってその構造体に変更を加えて返すコールバックを引数に取るようにすればいいんじゃね? って思ったんだけど、そんなの lambda で書きたいに決まってるけど変数キャプチャ付きの lambda は関数ポインタに変換できないじゃんねっていう訳で、コールバックに関数ポインタじゃなくて lambda を受け取る template メソッドにしてしまえ、ということを試してみたくて書いていたものでした (今考えたらそも素直に std::function 使えよ…って話ですねorz)。
(さらに…)

otoco プロジェクトの開発に着手するにあたって、私はまだ C++ でのライブラリ開発を 1 からコーディネートした経験がなかったので、クロスプラットフォームに対応したライブラリ API の開発手法を学ぶ必要があると感じました。ちょうどいい感じの教材が割りと最近出ていたようで、早速購入し、勉強を進めています。

• C++ APIデザイン
  

C++11 についても若干触れられているようで (原著執筆当時はまだ C++0x と呼ばれていた模様…)、この手の教材の中では比較的情報が新しい方なんではないかと思われます。

実はこの本を買って勉強し始めたのはもう結構前 (確か前原にいた頃… 昨年の暮れ頃?) なのですが、ここしばらく本業やら引っ越しやらが忙しくてなかなか手を回せずにいたので、久しぶりの着手ということで、すでに履修していた第3章の、 Pimpl イディオムとファクトリメソッド辺りを復習してみました。
(さらに…)

C++ で STL などによる任意のコンテナを引数に取る関数を実装する際、そのコンテナの種類は問わないものの、そのコンテナが持つ要素の型は限定したい、あるいは要素の型に応じて処理内容を切り替えたい、といったニーズがあると思います。

そのような場合、 C++11 であれば、 <type_traits> を利用します。

以下は、整数の型を要素に持つ任意のコンテナを受け取り、その全要素の合計を返す関数 calcSum() の実装例です。
(さらに…)

新年明けましておめでとうございます。去年はちっとも儲からなかったので、今年は本腰入れて開発やって自力で稼げる事業を立ち上げたく、その準備を進めて参る所存でございます。どうぞ生暖かく見守っていただければと思います…。

さて、前回の記事でお見せした、 iconv のラッパークラスをテンプレートクラスに作り直す際、 <unorderd_map> を利用していて気づいたことの備忘録です。

• EncodeString.hpp
• EncodeString.cpp

(さらに…)

このエントリは、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 に記述があります。
(さらに…)