別に仮想クラスにする必要ないっぽいね

今日もプログラムネタ。とりあえずこのネタだとなんとか繋いでいけるんだよね^^;
昨日のポストで
「スーパークラスは仮想クラスにしなきゃだめ?」
みたいなことを書いたんですが、よくよく考えたら別にその必要もなさそうですね。
というのも、多重継承するなら仮想クラスにする必要も出てきますが、多重継承しないなら仮想クラスにしなくてもいいじゃないかと。今スーパークラスを持っていないクラスが自前のスーパークラスを継承するようにさえしてやればいいわけで。
というか、仮想関数と仮想クラスは分かりにくいよなぁ。C++でもinterfaceクラス的な実装は出来るけど、それしようと思ったら参照渡しにしておかないといけない。いっそのこと全部参照渡しにしてしまいたいと思うけど、ポインタでないといけない場面もあったりして困りものだ。アドレス渡しと参照渡しと値渡しが混在するのはほんと勘弁願いたいよ。クラスオブジェクトに関しては値渡しはすべきじゃないな、私の実装の仕方だと。クラスのメンバに配列を持つことが多いからなぁ。コピーコンストラクタをわざわざ定義なんかしてないし、デストラクタで確保した領域を確保しちゃってるから値渡しにするとえらいことに。
解決策としては、コピーコンストラクタをきちんと実装するか、値渡しを禁止するかいずれか。そりゃ値渡しを禁止した法が楽ってもんだ。
ビバ!マイルール。
VC#だと、コメント記法がちゃんと決まってて、それに沿ってコメントを書いておくとポップアップが表示されて便利。VC++でもポップアップは出るんだけど、特にコメント記法までは決まっていない。
が、Doxygenというツールを使えば、コメント記法に乗っ取って書くことで綺麗なAPI仕様書を簡単に作ることが出来る。でまぁそのコメント記法はそんなめんどうなもんじゃないのでちまちまと書いてAPI仕様書を作ったのですが、形になってくれるとなんか嬉しいですねぇ。大したクラスを実装したわけでもないのに大層な仕様書ができあがるので、すっごい自己満足に浸れます(笑)
さらに、このDoxygen、C++以外にも多くの言語に対応しておりまして、C#にも対応していると。C#のコメントからAPI仕様書を生成するツールはM$も出しているのですが、なんとコマンドラインからの実行。しかも超分かりにくい。ぶっちゃけ使えない。
それに対し、Doxygenは非常に優秀でした。ついでに言うと、M$が生成するHTMLよりはるかに軽かったです。まぁ、M$の生成するHTMLはJavaScriptを駆使してMSDNライクなページを生成してくれるので、それはそれで重宝するんですけれどね。
DoxygenはHTMLだけじゃなくLaTeX形式(他にもありますが省略)なんかでも吐いてくれるのですが、UTF-8形式でした。UTF-8に対応したLaTeXってありましたっけ・・・?あったら使ってみたいところ。LaTeXでもってPDFを生成したら紙の仕様書のできあがり。素晴らしい自己満足だ(笑)
さ、自己満足に浸ってないで、さっさと残りの仕事を片付けようOrz

どうやらだめらしい

昨日のポストで書いたコードですが、どうやらメモリリークの原因となりそうです。やっぱり、どんな形であれmalloc/newしたならfree/deleteしなさいということらしいですね。
安易に領域を確保してreturnするような関数を書いて利用するなってことですか。やはり自分でメモリ管理をするのは苦手です、トホホ^^;
というか、newやdeleteも演算子であるため、オーバーロードが可能であることに驚き。さらに、メモリリークについて調べていて参考にしたサイトには
「C++ならば自分の扱うクラス全てを派生させるスーパークラスがあるだろう。と言うか、普通はそのように実装する」
って書いてあってびっくり。マジすか。いわゆるJavaで言うところのObjectクラスを自前で用意するのがC++プログラマにとっては常識だったんすか。己の至らなさに目からウロコですよOrz
けど確かに理には適ってるな。なるほどさすればスーパークラスのnewとdeleteをオーバーロードして、確保と解放がきちんと対になっているかを調べられるように実装するのは可能だよな。JavaやC#のガベッジコレクションも考え方の基本はここにあるのかも知れない。
ただ、C++にて配列を確保したり解放した場合は問答無用でグローバルなnewとdeleteが呼ばれるらしい。自前のクラスの配列を用意したときなどはきちんと解放されているかを自分で管理しなくてはいけないのはCと同じところか。
もうちょっとこのことについて気付いていれば今回のC#からC++へのプログラムの移植でもスーパークラスについて考えておいたんだけどなぁ。まぁまだデッドラインまでは時間もあるし、考慮してみるのも面白いかも知れない。
別に凝った機能が必要なわけではないモノね。まーnewとdeleteのオーバーロードあたりでも用意してやりましょうか。仮想関数にしないとまずそうやな。というかそのスーパークラス自体が仮想クラスにしておかないとまずいか。仮想クラスにしたらそこに含まれるメソッドは自動的に仮想関数になると思っていていいのかしら・・・?
もうちょいとC++を勉強する必要がありそうだな、うん。

前々から疑問だったのですが

C/C++で組んでいて、前から疑問だったことがあります。
関数内でmallocなりnewなりで配列を確保し、それをreturnで返すようなものを実装したとします。まぁベクトルの演算を実装する場合なんかが挙げられるでしょうか。具体的には
double* Plus(double* a, double*b, length)
{
double* dst = new double[length];
for(int i=0; i<length; i++)
dst[i] = a[i] + b[i];
return dst;
}
みたいな関数ですね(ホワイトスペースってHTMLでどう書くか忘れた・・・)。こう定義すると、
double* c;
c = Plus(a, b, length);
みたいな書き方ができて多少分かりやすいかなと。関数内で領域を確保するのではなく、予め用意したバッファを引数に与えて実装するという手ももちろんありますが、見た目にどれが結果を格納するバッファか分かりにくいよな、と思っちゃうんですよね。実装するならこんな感じ?
void Plus(double* a, double* b, double* dst, length)
{
for(int i=0; i<length; i++)
dst[i] = a[i] + b[i];
}
見た目だけの問題で実際の処理量や確保するメモリ量に大差はないってのは分かってるんです。ただ、前者の例だと、d=a+b+cみたいな演算をするときに
d = Plus(a, Plus(b, c, length), length);
という書き方が可能です。後者の書き方だと、b+cの結果を一旦保持した上でそれとaの結果を加える必要があるため、変数が余計に必要となります。大した手間ではないと言われたらそれまでなんですが^^;
さて、前置きが長くなりましたが、本題はここからです。C/C++の場合、malloc/newした領域は使い終わったら必ずfree/deleteしましょうというのが作法です。自己責任ですが。ですので、こうした演算処理で確保した領域も用事が済んだら解放しなくてはなりません。
問題は
d = Plus(a, Plus(b, c, length), length);
と言った書き方をした場合の処理についてです。Plus(b, c, length)の結果は変数としてはどこにも格納されていませんから、先の「d = 〜」を実行した後はそのアドレスへアクセスする手段がありません。ですので明示的にfree/deleteできません。
ならばこの処理を延々繰り返すとメモリリークをいずれ起こしちゃうんでしょうか?これが気になってるんですよねー。
JavaやC#のようなガベッジコレクションが用意されている言語なら気にしないのですが、C/C++ではどうなるんだろうと。それとも、メモリリークの原因になるからこういう実装はするなということなのでしょうか? それならそうで、仕方ないので諦めるんですが・・・。
MATLABとかOctaveってどうやって実装してるんだろうなー。あの柔軟な言語体系をどうやってC++で実装してるのか気になる・・・。
あぁ、Octaveはオープンソースだからソースコード手にはいるのか。いやさすがに見る根性ないけれど^^;
ま、当面は少々一時変数が増えようとも確実に自身でfree/deleteできるような実装にしとくべきだろうなぁ。
どういうキーワードで探したらヒントになる実装見つかるかしら?

打つより喋る方が楽

ひょんなことからVelnirとボイスチャットしてました。
というか、Velnirはマイクを持っていないので、私が一方的に話し、向こうはテキストで返事をするという変則的なチャットでしたが(笑)
やってみて思ったのは、
「喋るだけって楽でいい」
ですね。ながら作業で会話できるし、普段通りのテンポで話せるのがステキ。私が持ってるマイクは古くて非常にしょぼくれた代物ですけれど、そんなマイクでもVelnir曰くふつーに聞こえてるとのことでしたので、Skypeが流行ったのも頷ける。
テキストチャットだと、打ち込むときにそのウィンドウに切り替えなきゃいけない。それが手間っちゃー手間ですからねぇ。ボイスチャットならとりあえず喋れば相手に伝わるので便利。テキストチャットはログが残るのでそこはすごく魅力ですけれどね。
今回は私が一方的に喋り、Velnirはテキストで返事を書いていたため、ログがまるで独り言に(ぁ
私は人と話してないと退屈する人間なので、ボイスチャットというのは魅力的。今持ってるマイクはヘッドセット型なのですが、装着するのは邪魔くさいので据え置き型が欲しいところ。やっすーいので構わないのでちょっと購入検討しようかしらw

-10度

今日、本屋に行くついでにPCパーツショップへ寄ってきました。CPUファン用の3ピンコネクタの接続コネクタを買うためです。
今使っているケースには最初から3つのファンがついていました。前後に1つずつと、ケース横のパッシブダクトです。で、そのどれもが3ピンだったのですが、マザーボードの3ピンコネクタは2つしかなく、かつ電源についているコネクタに3ピンは1つもありませんでした。
ということで、どれか諦めざるを得ないので、前後のケースファンに繋いで、横は放置してました。
が、なんか勿体ないなということで、ようやく今日買いに行った次第です。安いもんでした。500円ですね。電源から4つのファンが繋げられるように分岐してました。4つも要らなかったんですけど、それしかなかったので^^;
で、帰って早速接続。でPC起動。今まではアイドル状態で
システム:46度前後
GPU:66度前後
だったのですが、横のファンを稼働させたところなんと
システム:36度前後
GPU:57度前後
と、約10度も下がりました!
驚いたーあたしだけ?
まさか横のファンを稼働させただけでそんなに効果があるとは驚き。騒音レベルもほとんど分からない程度。こんなことならもっともっと早く、というかこのPC組み立てたときに買っておくんだったなぁ・・・。夏本番終わった後だよOrz まぁこれは来年もまだ元気に動いていると思うからいいけどさ。
とりあえずこれで結構冷えてくれるようなので、熱暴走の心配はなさそう。どうやらLinuxでBerylが不安定なのもGPUが熱暴走しているからではないかとの噂ですし。確かに、私が今使っているのはファンレスですからねぇ・・・。今になって思えば、ファン有りでも別によかったかも。大して騒音気にならないや。夜中稼働させるわけで無し。今度組むときはそこいらにも注意しよう。
次に組むとしたらミュージックサーバかな。コンパクトに仕上げて、音楽再生に特化させたいところ。AmarokとかはHTTPで操作できる拡張とかあったりするから、家庭内ミュージックサーバとしては便利そうだ。
ま、就職して、給料入ったら、の話だけれどね^^;

まぁ、充実していると言えなくもない

このところ、
・論文執筆
・それに必要なシミュレーション結果の採集
・執筆内容や方針について教授と相談
・後輩の進捗具合確認
・C#で組んだシミュレーションプログラムをC++へ移植
と、中々に忙しい日々を過ごしてます。移植は家でちまちまと。思ったより早く移植できそうな感じ。油断してたら痛い目見るけど^^;
さらにさらに、このくそ忙しい中、友達から借りてる「DDD2」と「Fate/Zero1〜3」を読んでるという無茶ぶり。というかまぁ、本読むくらいの息抜きがないとやってらんねーよばーろーってとこですな。
おかげさまでここ1週間くらいはほぼ同じ生活サイクルなのでBlogのネタもなく。今朝5時頃、激しい雷雨によって起こされてしまったくらいしかネタがないですね。2時過ぎに寝たのにそんな時間にたたき起こすなよと。あんなに雷にびびったのは初めてかも。かなり近かったからなぁ。おまけに夜明け前?ということもあって雷ですっげー明るくなったからなおびびる。あんだけ激しい雷雨だったのにまったく気付かなかったらしい母親の剛胆さが羨ましいぜ(ぉ
と、こうも忙しくなってくるとむしろ色々とやりたくなってまいりまして。できたらデスクトップアクセサリとしてカレンダーが欲しいなと。簡単な予定管理機能付きの。
これだけなら腐るほどあるんですが、できたらWinとLinux両方で使えるやつ。クライアントそのものが両方で使えなくても、せめてネットワークで同期くらいはさせたい。ローカルにサーバは立ててるので、そこにファイルを置いて同期するようにしてもいいし、GoogleカレンダーやらMSNカレンダー、Y!カレンダーのようなものを利用してもいいかなと。APIがあればですけど。
そーゆー公開されたAPIを使ってアプリを作るってのはやったことがないので、是非ともやってみたいとは常々思ってたんですよね。ただ、アイデアが浮かばなかったんですよ。けど「カレンダー」っていう明確な目標というかカタチが見えたので、ちょっとやる気にはなってたり。
Linuxで言えば、SuperKarambaを使うのが楽そう。Skinはthemeファイルで管理できるし、同期部分はPythonで管理。Pythonを触るいいチャンスかも。
WinではRainlenderがいいかなぁと思ったけれど、あれにはネットワークに対応させるとかそういった機能はないと思うとVelnirが言ってた。ので、Y!Widgetかなぁとか考えたけど、あれはあれでよく分からないんだよなぁ。XML+Javascriptだけど、両方ともよく知らない。ちゃんとしたドキュメントもあるし、サンプルというかWidgetがあるしそれ展開して中身調べて真似したらいいんだろうけど、前にやろうとしてうまくいかなかったのでトラウマが>< なんかうまい手はないかなぁ。
と、ある意味現実逃避してたり。さすがにそんな遊びに手を出す余裕が今のところないんですよねー。C#->C++の移植が片付いたら多少余裕が生まれるかもなので、ほんとに作り始めるとしたらその後か。けど論文書けてもスライド作らないといけないからやっぱり暇はあんまりないかもなぁ。
まーでもスライドはPowerPoint使うし、それは家にないから家で遊ぶ余裕はできるだろう、うん。その時までやる気を持続できているかは甚だ疑問だけれど(笑)
ま、なるようになるかねぇ? さて、今晩もカリカリ移植しましょ。

夕立、虹。

にわかに忙しくなってまいりました。とりあえず、論文投稿のGoサインは出ました。が、その期限が来月末と再来月半ば。どの程度までのデータを揃えるか、ですねぇ。
まぁプログラムは一応できあがっており、後はパラメータを弄る程度なのでさして困りはしないでしょうけれど。大幅なプログラム変更がないだろうと思える分気は楽ですね。データはそれなりに揃える必要がありますが。そこいらは地道に頑張るとしましょう。
幸い、PCは2台所有しており、ディスプレイもそれぞれに繋いであるので、Winでシミュレーションプログラムを走らせつつLinuxで論文を書くという作業が可能です。つかまーそうしないと時間が勿体ないやね。
さらにさらに、共同研究先の企業の方から
「9月末にはプログラムをC#からC++に移植してね☆」
と依頼されましたので、タイトなスケジュールに更に重しがのっかりましたOrz
ま、YesマンなのでNoとは言えないんですけどね;;
移植作業は家でやりますかね。どうせなので零から構成し直す予定。C#で今作っている部品構成を基に、気持ち悪いから直したいと思っていたところを洗い出す。んでもってC++では自分でやらんといかんのでメモリ管理周りをしっかりと整理。まぁ、自分が主に使う部品なのでそこまでシビアにならなくてもいいとは思う。解放し忘れがないようにデストラクタでdeleteをしっかと呼び出さなくては。
ま、とりあえず今週中に部品リストの作成かな。基本部品をしっかりと作っておくとシミュレーションプログラムは部品の組み合わせだけでできあがるからさして難しくはないし。しっかと部品を作ろう。
ま、効率は2の次さね。見通しとバグなく動くことを目標に頑張りますかね。