はらぺこ日誌

今回は 5章、モジュールの import の仕方やモジュールの書き方、あとはいくつかの標準ライブラリの紹介です。

手元ではもう概ね読了しています。ブログに書くのは一旦ここまでで終了しようかなと思っています… こうやって書き出すよりいろいろ作って実践していったほうが身につくのは早そうなので…。

(さらに…)

業務が始まったこともあり、間が空いてしまいました。余談ですが、業務でもすでに段階的に Python を使い始めておりまして、 selenium と BeautifulSoup を使って Web スクレイピングでクローリングする script kiddy な感じのツールをメンテする準備を進めたりしています。

「入門Python3」は電子版を購入したのですが、 O’reilly の電子書籍は一度購入してしまえば O’reilly のサイトからいつでもどこでもダウンロードできます。閲覧規制が若干厳しい職場の環境でもダウンロードできたので何気に便利で快適です^^。

今回は 4章の 4.6節から。手元ではすでに 8章の途中ぐらいまで概ね読み終わっているのですが、今回は 4章までの内容について記述します。

(さらに…)

今日は 4章の 4.5節まで。

(さらに…)

3章まで読了。データ構造を表す型が何気に豊富ですね…。

(さらに…)

Python 習得中です。今日は 3章の 3.2.16 まで。

(さらに…)

新しい現場で Python を使う仕事があるということなので、オライリーの入門 Python 3 の電子書籍版を購入して予習しています。とりあえず 2章まで読みました。

履修した中で気づいたことなどをちらほらとメモってみることにします。

(さらに…)

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

• cppgen.pl

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

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

• C++ APIデザイン
  

今回から第4章に入ります。4章は C++ での実装の話はなく、設計に入るまでの情報の収集や整理 (要するに要件分析)、および様々なレイヤーでの設計に関する議論となっています。プログラミング実習をするような内容でもないので、要点をまとめながら解釈したり考えたりしたことをレポートしたいと思います。

今回はその中でも、 4.1～4.3節の、要件分析までの内容について見ていきます。

大原則

最初のセクションに入る前の書き出しで、以下のように書かれています。これはもう、大原則ですよね… (強調は拙引用者によるものです)。
(さらに…)

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

• C++ APIデザイン
  

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

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

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

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

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

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

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

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

(さらに…)