継承関係ということについての試論

どうもJudaです。
ちゃんとOOPを学習していないのですし、該当する書籍を読み込んでいないのでなんともいえませんが、軽症という事象にはいくつかの要因があるのではないかと推察します。

1. インターフェイス


2. 実装


3. データ構造

この3要素があると思う。
よく考えずにこれらをごっちゃにして継承をさせていくとどこかで使いにくさが出てくるように思われる。さらにいうとデータ構造の部分が特に危険だと感じています。
インターフェイスの継承は一般的なOOPでの利用に関して合致しそうです。多態性の文脈に合致します。
実装の部分は、特化したインターフェイスを生かし続ける形で実装しないといけないのでとてもナイーブな感じがします。
データ構造に関しては実に困難さを覚えるのですが、多態のためにサブクラス分化するとあまりにクラスが分割されすぎる気もしますし、それぞれの振る舞いがデータ構造に依存しているときにはやりようがないのですが、うまくまとめないと理解しにくくなりすぎる感があります。
どうすりゃいいんだ。OOPはあまりに強い困難さを覚えます。設計ということに向いていないのかもしれない、、、データ構造と実装があまりに緊密になっている感が。。。でもデータ構造が抽象された実装はアルゴリズムとなっているなぁ。。。
インターフェイスはある意味ではさらにもう一層上のレベルでの継承関係をあらわすのかもしれない。
そう仮定すると、COMやインターフェイス志向の記述は、実装を含めたデータ構造を抽象化したものであり、これは一層抽象度が高いので変更可能性強度が増すと思う。

MacでBoostを使う

どうもJudaです。
とりあえず、作業をする前に調べてみる。

■[Macプログラミング][Boost]MacにC++の高速ライブラリBoostをインストールしたCommentsAdd Startomisima


Mac でBoostCommentsAdd Star

手始めに調べておいていれてみる。いろんなところで実践実践。

2010/10/11 0:14:45
XCodeの最新版を導入
MacPortの導入
導入後にUpdateをかける
BoostJamの導入
Boostの導入<ここでError発生　ちなみにMacOSX SnowLeopard
DEBUG: Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/boost
DEBUG: OS darwin/10.4.0 (Mac OS X 10.6) arch i386
DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided
DEBUG: org.macports.unload registered provides 'unload', a pre-existing procedure. Target override will not be provided
DEBUG: org.macports.distfiles registered provides 'distfiles', a pre-existing procedure. Target override will not be provided
DEBUG: Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
DEBUG: universal variant already exists, so not adding the default one
DEBUG: Starting logging for boost
Error: Cannot install boost for the arch(s) 'x86_64' because
Error: its dependency zlib is only installed for the arch 'i386'
Error: and the configured universal_archs 'i386 ppc' are not sufficient.
DEBUG: architecture mismatch
while executing
"macports::_upgrade_mport_deps $mport $target"
(procedure "mportexec" line 26)
invoked from within
"mportexec $workername $target"
Error: Unable to execute port: architecture mismatch
おいおいどうすればいいんだよ。。。
2010/10/11 1:53
なんとなくだけど、
$port varibants boost
でオプションを調べて、
universalを確認してから
$sudo port install boost +universal
ってやるとなんか依存関係もまとめて調べてくれるから、何とかなりそう。
でもBoostのBuildにかかる時間がすげーなげー。か？

2010/10/11 09:51
放置しておいて、朝見たら、Build終わっていた。
---> Computing dependencies for boost
---> Fetching boost
---> Verifying checksum(s) for boost
---> Extracting boost
---> Configuring boost
---> Building boost
---> Staging boost into destroot
---> Installing boost @1.44.0_0+universal
---> Activating boost @1.44.0_0+universal
---> Cleaning boost
とりあえず導入まではできた。

std::vectorは連続領域なのか？

どうもJudaです。
http://cranehouse.dojin.com/program/vector.html
http://www.s34.co.jp/cpptechdoc/article/vectorastemp/
ここの二つでなんか問題は解決できそうですな。
それにしても、言語の仕様書を読んだのが初めてというへたれっぷり。C#さんの仕様書でも探し読もうかなぁ。
あと先ほどのリンクにあげたS34って会社が大阪にあるので、ちょっと興味ありかも。

Code Kata的な 練習

どうもJudaです。

// Kata000.cpp : コンソール アプリケーションのエントリ ポイントを定義します。
//

#include "stdafx.h"
#include 
#include 
#include 
#include 
#include 


void foreachMethod(const size_t& size)
{
  boost::progress_timer t;

  using namespace boost::lambda;
  using namespace std;
  vector tmpArray(size);
  tmpArray[50] = 200;

  boost::progress_display show_progress( tmpArray.size());
  for_each(
    tmpArray.begin(),
    tmpArray.end(),
    (_1 + 1) );

}
void forMethod(const size_t& size)
{
  boost::progress_timer t;

  using namespace std;
  vector tmpArray(size);
  tmpArray[50] = 200;
  boost::progress_display show_progress( tmpArray.size());
  for( size_t i = 0; i < tmpArray.size(); i++){
    int itt = tmpArray[i] + 1;
    ++show_progress;
    //cout << tmpArray[i] << endl;
  }
}
void foriterMethod(const size_t& size)
{
  boost::progress_timer t;
  using namespace std;
  vector tmpArray(size);
  tmpArray[50] = 200;
  
  boost::progress_display show_progress( tmpArray.size());
  for( 
    vector::const_iterator i = tmpArray.begin();
    i != tmpArray.end(); i++){
    int itt = *i + 1;
    ++show_progress;
    //cout << *i << endl;
  }
}

int _tmain(int argc, _TCHAR* argv[])
{
  const size_t size(1000000);
  foreachMethod(size);
  forMethod(size);
  foriterMethod(size);
 return 0;
}

とりあえずいえるのは、VS2008のReleaseならforeachがはやい。Debugならforが早い。とりあえずどれでもイテレータは遅い。でもこの場合に重要な点は、こんな単純なケースで通常のイテレータ回しはあまり有用ではない、という点と、イテレータでの制御はもっと凝ったもののほうがいいかもしれない。とりあえずforeachすげー。投げる要素数が増えるとかなり露骨に早くなる。