24時間プログラミング 6時間目 〜 仕様変更のフィールド

その昔に自作した（その昔から自作している）ライブラリに、ちょっとした不具合があって軽く修正していたのですが……

いやー懐かしい。（ぉ

ファイルに記述してある日付が "2002/xx/xx" とか書いてあったりと、実に懐かしい。 そして確かに書いた記憶があるんですよねコレがまた。

で、その昔のコードなので、これまたヒドイ……というより、なんか "微笑ましい" です。 一生懸命頑張って調べて書いていた記憶はあるんですが、今見ると「xxxするとリークするよねー。ぷぷー」 見たいな問題を結構見つけられちゃったりします。 言語の有効活用を知らないが故のコードだよなーぷぷー って感じです。*1

…んまぁただ、今書いてるコードも５年後ぐらいには笑えちゃうコードになってるのかなー とか思うと、ちょっとやるせない気持ちになっちゃったりしますがー＾＾；

もうちょっとライブラリを見ていくと、もうね、みんな創るであろうラッパクラスがやっぱり定義されてるんですよね。 何かって

• CWindow
• CBitmap
• CPoint
• CRect

等など。

今の私だったら、標準/準標準の ATL/WTL で定義されているクラスをサクッと使っちゃいますねー。 こっちの方が明らかに 高機能ですしー！ Hahaha-！！

……正直、ちょっと無駄した感はありますが、当時の私としては勉強になった面もあったんじゃないかと思うことにします。ハイ。＾＾；

ぷよフィ

２時間ぐらい前の戦いは２連勝しました。が、その前に２連敗しました。orz

↑現状、勝率66.8%。

ここ数日気分が乗らなかったりしたので３段まで降格したりしましたが、何とか 2/3 程度の勝率は保っています。 …が、正直皆強いッス…。＾＾；

私が AJPA公認初段 取ったときとは大分状況が変わってきてますからなぁー…。GTR なんて存在しなかったよ。

*1:問題が起きる可能性は低いので、現状修正は保留しちゃってますケド：ぉ

24時間プログラミング 8時間目 〜 仕様変更のフィールド

大変困りました。

実装に。orz

この時間帯で実装に詰ってくると眠たくなってくるわけで…＾＾；
なんか３０分ぐらいウトウトしてたよーなきもします。（ぉ

全然関係ないんですが、RODの１１巻がいつのまにか出てる事を知りちょっとビックリしました。＾＾；
１０巻から何年ブランクがあったんでしょーか…。

R.O.D 第十一巻

posted with amazlet on 06.08.27

倉田 英之 (有)スタジオオルフェ 羽音 たらく
集英社 (2006/02/24)

Amazon.co.jp で詳細を見る

24時間プログラミング 10時間目 〜 仕様変更のフィールド

５時かしら〜！！

というわけで、皆さんおはようございますなのかしらー！　…って、みんな寝てますか。そうですかそうですか。orz

さて、私といえば、お腹減りました。 策士といえど、腹が減っては戦は出来ぬなのかしら！！
というわけで、

飯！

朝食何だか夜食何だかよくわかりませんが、今回食べるものはコレ！！

カナ 金のたまごうどん

うおおおおおおおおおおおおおお

なんだこの、ごく一部のデコ好きの為だけに有るような食べ物は！！！ 知人にコレを貰ったときはマジでビックラこきましたよ。 紅い狐と翠の狸……orz*1 赤い狐と緑の狸のシリーズといったら、「白いチカラうどん」「黒いカレー」程度しか知らなかったんですが、黄…ちゅーか、金もあったんですねぇ。

とりあえず、無条件に

テンション上がってきた！！*2

さて、インスタント麺といえば、至高の料理を制作した過去 が有ります。まぁ、その至高さは私も理解でき無かったんですけどね。

で、今回は一般人でもわかるような、知人にでも理解できるような、私でも解るような食べ物を作ろうと。 …とはいえ今回は、基本的に粉末スープ入れてお湯入れるという極基本的なステップになるので、マズ問題ないだろうと。 うむ、さすがに徹夜中といえど、このステップをミスｒ………いやいや、前回のアレは至高の料理を作る上でのステップだったんですが、今回は一般人でも理解できるような物を作れるだろうと。うん、問題ない問題ない。問題ない問題な

かしら！かしら！ご存知かしら！？
世の中には ロスタイムと言うものがあるのをご存知かしら！？

さて、中に入っているコンポーネントですが

• うどん
• エビ入りたまごやき
• 粉末スープ
• 調味油

最後の調味油が結構ポイントかもしれません。ラーメンに調味油は結構見ますが、うどんに調味油ですからねー。
ってことで、お湯を入れて５分待って………

いただきかしらーーーーーーーーーー！！！

………はい、えーっと。味の方ですが、普通においしかったですね。 調味油のおかげでマッタリ感が出てた気がします。 たまごやきもおいしかったです。

…が、日持ちし無そうなたまごやきなので、購入後は早めに食べた方が良いかもしれません。＾＾；

…購入

……

ぶっちゃけ、見かけないよね。コレ。

*1:一発変換：誰か描いてくれ！：ぉ

*2:今まで割とローだった

24時間プログラミング 12時間目 〜 仕様変更のフィールド

ようやく詰っていた部分のベクトルが見出せた感じで、セコセコ打ってます。

…でまぁ、ぶっちゃけ見た目としては何も変わってません。（ぉ

んー、今回、内部ではごにょごにょ変わってきてるんですが、それを上手く外部に伝える手段がないのぅ…。＾＾；

というわけで、ネタ放出。

• http://www.asahi.com/national/update/0826/TKY200608260179.html
• 総務省がWeb用「ウソ発見器」を開発へ | スラド

で、また何人おうちに帰れなくなるでしょう？（ぉ

24時間プログラミング 14時間目 〜 仕様変更のフィールド

ネタに出来るような更新がない！ どないせいちゅーねん。（ぉ orz

というわけで、突っ込みたいけれどどうもタイミングを逃してしまったバトンについてツッコミを入れてみる。

id:sui_k:20060823 な人 本家はこっち

＞本家で別の人から回ってきたのを回答済み

ぎちょびん
blogの方は確認しとらんかった…うは。すまんそ。＾＾；

＞着物

なるほどだから……。 ＯＫ、了解。文化祭期待してます。

http://homepage3.nifty.com/k_sou/ 氏

＞あゆあゆ

カンベンしてください。（ぉ

？普通の女子高生の制服・・・はコスプレじゃないですよね？

コスプレじゃないかもしれませんが、それ以上のヤヴァさを感じ取りましたよ。にんにん。

＞和服

ちっくしょう！和服大人気かよ！！

http://www.geocities.jp/mononohu_08/top5.html 氏

えーっと、突っ込もうかと思ったんですが、全ての回答が私より濃いです。 ヘタに突っ込めません、本当にありが

で、なんといいますか、時間のない中予想以上の回答をしていただけて有りがたく思う次第であります。 割とマジでお疲れさんでした。

しかしまー、みんな あったま悪ぃなーおぃ！（※誉め言葉です）

24時間プログラミング 16時間目 〜 仕様変更のフィールド

よぉぉぉぉぉーーーーし！！ ようやく見た目が更新されましたよ！！

いでよ、ウィンドウぅぅーーーーーーーーーーーーーーー！！！

よし、ようやくクライアントサイズが 640 x 480 のウィンドウが作れましたよ。 うむ！
…んまぁ、コレだけなんですが。（ぉ ＾＾；

ただ基盤はある程度できつつあるので、あとは DirectX の初期化等をいれて、行けば何かしら表示できるはず。

そして、コールバック先の関数を変更してあげればいろいろ対応できるようなった…ハズ。 ハズ。 ハズ…

24時間プログラミング 18時間目 〜 仕様変更のフィールド

共通ライブラリとなりそうなファイルを引越し中………

………依存関係がヒドイ。orz

24時間プログラミング 20時間目 〜 仕様変更のフィールド

ちょっくら技術的な面で悩んでみる。

あるインターフェースは、別のクラス１つにしか継承されない事がわかっている場合って、微妙にインターフェース作るの負け組み感がありますよねぇー。

// IInterface は CClass にしか
// 継承されない事がわかっている
class IInterface
{
public:
  int Func(int);
  int Kanaria(int, double);
};


class CClass : public IInterface
{
public:
  int Func(int);
  int Kanaria(int, double);
  int Manna();
  int Misya(void*, void*, void*, void*); // 何この関数
};

CClass では、関数がえらい量あるにも関わらず、ある別のクラスがそのインスタンスを利用する場合、ごく一部の限られた関数しか利用しないとかいう事態になったとき（長いよ）、その利用する部分だけを Interface として抽出し、数限られた状態で扱ったほうが混乱しないよなー って思ったんです。

ただ、別にインターフェース別にしなくて CClass へのポインタを直接扱っちゃえば、結局同じことが出来る訳で…。寧ろ仮想関数経由で扱った場合、vtable 見に行く分遅くなってしまうという。で、今作ってるのがゲームじゃーないですか。

うーん。

Interface で必要な関数を抽出したものを扱ったほうが混乱しなくて済む事は済むんですけど…つまりはそれ、自分側の capacity 足りてないだけなんじゃねーの？ とか思ってみたりするわけで。

うーん…

…んまぁ、今の時代は、CPUが無駄に高速になった故に、よっぽどの事がない限り「超高速なコード」を求める必要性は無く、寧ろ見やすいコードを目指した方が良いってのはわかるんですけどねー。

まぁ、分離化しちゃおうかしらー。

24時間プログラミング 22時間目 〜 仕様変更のフィールド

５時からし〜！

いやー、なんというか、私のつくりがヘタというか。 前々から問題になっていたことが今、結構強めに問題になってます。

1. クラスＡが、クラスＢの 内部情報を利用 する為 #include している。
2. クラスＢの定義で、描画用クラスＣのヘッダー を #include している。
3. クラスＣはクラスＡに本来必要とされないのに、コンパイラ的には必要とされてしまう。

クラスＢが「内部情報保持しつつ描画用コードを兼ねている」ってのが悪いんじゃないかと個人的には思っています。 Document and View スタイルを完全無視 というか、MVC を完全無視と言うか。 （…いやまぁ言ってることが正しい自信は無いんですが…（ぉ＾＾；）
内部情報と描画用コードが上手く分離できれば A と C の関係は切り離せるのに…

…とはいえ、これらの考え方は何となく解るんですが、実際ゲームで利用するとなるとどーすりゃいいんだろうなぁ…ってのが正直な所です。

Viewする時に利用するデータは、Document にあるわけですから、View が Document にデータを取りに行かなくてはならない……って、なんか逆じゃね？ Document が更新されたら View に更新されたデータを通知する話なハズです。

とはいえ、ぶっちゃけ動けばいいわけですから、柔軟に考えて、View が取りに行くって話にするべきかー…ということで、頑張って Document と View を別のクラスに分けたとしても、Document 定義してるヘッダーで View 用のヘッダー include しちゃうと、結局描画用のヘッダーも include されるような気がするし…。

うーん。

View 用のクラスを、Document クラスの頭で先行宣言してポインタを保持、document の cpp で View を #include して new してインスタンスをつくる…とか？

#include 関係については問題解決できるんです…が…

綺麗に実装できるのかなぁ…。＾＾；
デザパタ本でも見るかのぅ…。

24時間プログラミング prev時間目 〜 仕様変更のフィールド

というわけで、２年ぐらい前からやり始めている、２４時間テレビに対抗して２４時間プログラミングしちゃうという 遅れを取り戻す為の この企画。今年も頑張ります。*1

ちなみに、本家の方が１８時３０分という中途半端な時間から始まってしまうので、私の公式スタート時間は１９時という事にするつもりです。

さて、今年のお題はというと……「ふぃふぽん＠全力で開発中」。

去年も同じコードメンテしてたような気がしますが、そのあたりは可憐にスルー方向しちゃうのかしらー

…それにしても、今年は完走できるかしら…。＾＾；

って、あーーー！！

そうか、少なからず、去年はやってない！！！（ぉ
そうだ。書き込んでから気づいた。

去年は「やろうと思ったけど、元居た theSpoke が無条件でメンテに入り、一切アクセス不可 -> やる気をなくした」んでした…。 あれー？ でもはてなに引っ越してからやった記憶があるんだけどなぁ…何時だろう……？

………あぁ、この日 だ…。

*1:…というか今年が最後かも。＾＾；

24時間プログラミング 0時間目 〜 仕様変更のフィールド

今年は実験を兼ねてこの企画を進めてみようかと思うのですよ。 ２４時間作業に適したアイテム一式とは何かと。

今回は次のものを用意してみました。

• リポＤ-沢山 (当たり前ですね）
• 飴玉
• ビスケット
• 塩化ナトリウム摂取用アイテム （※あげもちのこと）
• BlackBlack (１枚消費しちゃった)
• Mintia x 4

作業中どうも口の中が寂しくなるので、何かしら良いアイテムはないかと模索中なのですが…

ガム…は、どうも噛みすぎるので、こめかみ近辺の筋肉が疲労してくるんですよね。＾＾；
で、今回は飴玉を用意してみました。 本当ははっか系（あれ？変換できないって事はなんか日本語間違ってるな…：辛い系って事ね）の飴玉用意したかったんですが、「のど飴」…　なんかちょっと違いそうな。 でも、マツキ■で、コレしかなかったんだよなぁ…。 ちくしょう薔薇水晶め。

まぁまだ始まったばかりなので利用する事はありませんが（でもリポＤだけは例外＾＾；）、辛くなったときに利用していきましょう。

なお今年は、２時間おきの更新を予定しています。

１時間後とだと大して作業が進まないわ、文章書くのに１０分ぐらいかかるわ、そもそも１時間に１回ネタを用意するのがムリなので、今回は span を長くしてみます。 次回更新は２１時ですかねー。

生きてたらですケド（まだ早い

よーし、ちょぃと頑張るにょー。

24時間プログラミング 24時間目 〜 仕様変更のフィールド

Javaで学ぶデザインパターン入門を読みつつ「む、ブリッジパターンを適用するべきなのかしら？…いやでも、結局（諸事情により）状況変わらんよなぁー…」なんて悩んでいると、母親に呼ばれました。

母「ちょっとー、私のパソコンが壊れちゃったんだけど」

ほー？

なんやー、また Windows の設定弄くったーだーの、変な画面が出てきたとかそんな話やろうかと思ったんですが

母「火花が出でたのよ！！」

はぁ！？

……あー、なんか先が読めました。
実際見に行ってみると、明らかにショートした匂いが立ち込めています。

母「パソコンの後ろから火花が出たのよ！！」

どう考えてもコンデンサ破裂です。本当にありがとうございました。

ってマジかー！！
何でまた突然。

んー、電源の在庫はあるんですけど、さすがに今の状況で電源交換作業やる気力は起きなかったので「とりあえずまた明日」と言って、電源ケーブルだけ抜いてきました。

……ちょっと不安なのが、板とかＨＤＤとか死んでないだろうなぁ……過電流等でごにょごにょ…みたいに死んでないだろうなぁ……。

大丈夫な事を祈る。

という、プログラミングとは全く関係ないネタで２４時間目を迎えた ２４ｈプログラミング企画@2006夏。 何とか２４時間記事の更新をしつづける事が出来ました。

んまぁ、作業結果といったらボロがでまくりで散々なんですがー（ぉ
コードメンテって大変ですねぇ…。

でさて、今回もコレで終わり…となる所ですが…あまりにも中途半端すぎるので、もうちょっと続けるかも。いやでも続けるとしても、とりあえず 風呂に入らせてください。orz
あせがギトギトむれむれにょ。

目指せヘッダーinclude摩擦解消よー！

（続く…かも。）

Java言語で学ぶデザインパターン入門

posted with amazlet on 06.08.27

結城 浩
ソフトバンククリエイティブ (2001/06)
売り上げランキング: 826

Amazon.co.jp で詳細を見る

デザパタ本では結構有名な本ですねー。

24時間プログラミング 2時間目 〜 仕様変更のフィールド

おぉ、無事更新してるよ！（何

で、さて。今回の目的ですが「スタティックライブラリを活用したモジュールの分割」を行おうと考えています。なぜかというと

1. モジュールごとに開発してテストしやすい環境にしたい。
2. ソースコードの量が肥大化して１つのプロジェクトじゃ管理しきれない。

前者については、このスタティックライブラリを活用しモジュールごに開発していくって事は、普通にやってる人は本当に極普通にやっているような気がするのですが、私はここ４ヶ月ぐらい前に便利さを覚えまして。＾＾；
ついでにモジュールテストの重要さってのも痛感させてもらった次第です。 こりゃー ふぃふぽんにも適用するしかないだろうと。

後者については…いやもうね。 ……ひどい状態なんですよ。

この状態はバージョン管理してても開発できん！

というわけで、現在モジュール事の分割（つか、分配？）に必死こていてます。

24時間プログラミング 27時間目 〜 仕様変更のフィールド

風呂入ってリフレッシュしてきました。

でさて、クラスが無駄に依存しちゃう問題ですが…う〜ん…やっぱりどう頑張っても依存しちゃうなぁ…という結論に。

というのもですね。

// B.h

#include "C.h"

class B :
  public C    // 描画用基底クラス
{
  int Draw(); // 基底クラスからコールバックされる。
  int x, y;   // 描画用内部データ
};

という状態なので、B.h を #include しちゃうと、どう頑張っても依存してしまう状態です。

じゃぁコレを、内部データ保持クラスと描画用クラスに分けるべきかー。内部データのみを取得して処理するクラスにとって、描画用の関数は不要だからー …なんて思ったんですが、別の描画用クラスを作ってしまうとデータ保持クラスを見に行くコードが増えてかえって複雑になりそうな……うーん…

……とか結構悩んでます。

…悩むな。コードを打て？ …なんか強ちこの格言（？）間違いでもないような気がするんですよね…
Subversion でいくらでもコードは戻せる訳ですから、とりあえず思ってみたことを実践してみますからネェー。

…あぁでもその前に。

寝ます。
長い間、ダラダラな文章見ていただけてありがとうございました。 そしてご迷惑をおかけしました。いや何となく。＾＾；

24時間プログラミング 19時間目 〜 仕様変更のフィールド

あまりにもあんまりだったので緊急更新。

こんなコードがありました。

namespace PG
{;

namespace RESULT
{
    namespace Loss
    {
        namespace Block
        {
            class C8LossBreakBlockMng;
        }
    }
}
※先行宣言

なんか、ね。 如何にも 「namespace の有用性に気づいちゃったんで、頑張って適用しまくりました」 的ニュアンスが…

…さーて、頑張ろーっと。orz

…そういえば、本来弄ってた場所から大分離れた所弄くってるなー ははははー orz

24時間プログラミング 4時間目 〜 仕様変更のフィールド

いやー困った困った。 というより、案の定と言うか。

１年前の自分のコードなんてサッパリだぜ！！ Hahaha!!!

ぷよフィで２勝してこよーっと…。 orz