いきなり寒くなったりする季節ではありますが、、、天気の良い日は音楽聴きながらドライブに限ります。
特に、一日中家にいるなんて当たり前のおいらにとって、外出ってやつはとても重要なのです。
最近、車につんであるCDも聞き飽きてきたので、イッパツ、よさげな1枚を探している最中なんです。
先日、フラッと立ち寄ったショップで気になったのが「COVERS~REGGAE meets R&B/HIPHOP」。
COVERS~REGGAE meets R&B/HIPHOP
あんまし新しいレーベルではありませんが、おなじみのR&B/HIPHOPがおいらの好物であるレゲエにリミックスされております。普段レゲエ聞かない方でも、入りやすいかも…！？
今日は半日、時間を割いて確定申告を済ませてまいりました。申告するのは初めてだったんで、何をどこへ書いていいのか、もうアタフタ状態…。控除とか扶養とか、あー、もうわけわからん〜
結局、係の人に来てもらって、事細かに説明してもらい、手取り足取りで記入を済ませました。
ギリギリだったけど、これで一件落着です（ホッ
C++のclass定義とヘッダファイルの絡み合い、気になる方は多いんじゃないでしょうか？今の時代、人間が書きやすいような言語仕様であるべきなのに、プロトタイプ宣言がイヤでイヤで仕方なくなってしまう自分。
こういうところを見ると、ABのClass定義は悪くはないんです（未実装な機能には目をつぶるとして…）。
こんなことは当たり前ですが、大規模アプリを対象にクラスモジュールを作っていると、どうしても一つのEXEが膨大な量になってしまいます。そこで注目すべきなのが分散型オブジェクトの構想です。
クラスモジュールを外部DLLにしたい場合、どうしても呼び出し元との繋がりを持たすための関数を用意しなければなりません。EXE-DLL間でイベント処理が発生することまで考えると、関数定義だけでかなり辛いものがあります。
DLLファイルで生成した実行モジュールは、型情報を持たないってヤツです。ここまでくると、Javaに逃げなよと言われそうですが、まだまだ回避方法はいくらでもあります。
ようは、DLL内にクラスモジュールを埋め込んで、外部から
Dim obj As CClassInDll
と定義した瞬間にCClassInDllを持ち合わせるDLLとリンクして、型情報を読んでしまえばいいんです。ここで言う定義とは、コーディングの段階での出来事なので、コーディング環境に対象のDLLが存在する必要がありますが…（突き詰めれば、ネットワーク上でつながっていれば問題ないです）。
そんでもって、各メソッドの呼び出しやメンバへのアクセス、継承などができれば一応はめでたしめでたし。
肝心の型情報は、DLLに新セクションとして設ければよいのです。DLLをコンパイルし、エディタ側から見えるようになった瞬間に、おなじみの.sbpライブラリをインクルードしたのと全く同じ感覚になるというわけです。
あとは、リリースコンパイルに条件をつけて、パッケージング機能でもつければ一筋つながるのではないでしょうか。
この発想はCOMに限りなく近いと思うので、どれだけすり合わせが可能なのか、もう少し検討の余地があるのかもしれません。
P.S.
と、真夜中に殴り書きをしてみましたが、これらはVer5.0の課題とでもしておきます。何かご意見などがありましたら、お願いします。
未踏ユース仲間の刺激をうけ、自分のPCにEclipseをインストールしてみました。おいらだってJava使いの身になるわけです（ホントになれるんか！？）
それにしても、起動がおっそい！スプラッシュ画面嫌いのおいらにとってはちょいと苦痛っす。
いやはや、それにしても、IDEの出来具合としてはピカイチです。プラグインとやらで無限の拡張性を感じさせつつ、使用しているコントロール類は丸みがあってオシャレときます。土日は休日なので、もっと掘り下げてみるとしましょうか。。。
ちなみに、一番最初に自分でインストールしたプラグインがBytecode outlineだったりします（重症だな〜）。
話が飛びますが、ActiveBasicも、Lunaとか取り入れたい〜。ツールバー周りのコントロール（グラフィカルなヤツ）をABで製作するのが最近の夢だったりしますf(^^;;;
オブジェクト指向。
この言葉が意味するものって、実はかなり曖昧だと思ってしまう今日この頃。「JavaやC#のオブジェクト指向は〜」と言ってもらえれば、おおよそ検討がつくのですが、Visual C++のオブジェクト指向、そしてActiveBasicのオブジェクト指向というと、何か中途半端な、オブジェクト指向になりきれない部分がどうしても存在してしまうような感じを受けちゃうんです。
Visual C++なんかは、MFCでそれらのグレーゾーンを限りなく白に近づけたわけですが、それでも、何か物足りないような印象が残ります。COMに関しても、一つのオブジェクトが定義され、それが複数のメンバを持ち、複数のメソッドによって行動するという単純な指向とは少し異なるものです。
オブジェクト指向の最大の利点は、オブジェクト同士が一つの環境化に無くても（ネットワーク上に分散していても）、このことを気にせずに互いが参照しあえるところにあります（賛否両論がありそうですが、おいらはこのように理解しております）。まぁ、それってJavaじゃん！となるのですが、おいらはどうしても、ネイティブ化した上でJavaの構造を作れるのではないかと思っているのです。
というのも、パソコンに限ったシステムであれば、数種類のネイティブコードへの対応を考慮するだけだし、速度の面でも、CPUアーキテクチャやグラフィックボードをバリバリ使うものを除けば、別に問題はありません。むしろ、仮想マシン系の言語システムは、後数年間はネイティブコードを超えることは有り得ないですし、超えたとしてもその差は微々たるものでしょう。
いちいちコンパイルしないとならないってのも、なんらかの方法で自動化すればカバーできる問題ですし、あとはガベコレの実装やライブラリの実装に左右されてくるんだと思います。
サーバーサイドで動き、クライアントPCで動き、ケータイで動き、あとは家電製品で動く。ここらへんまでネイティブでカバーできそうな感じはするのですが、、、どんなもんなんでしょう？？
本当の意味でオブジェクト化されたシステム、一度体感してみたい・・・
と、かなり知っているような文章を書いてしまいましたが、あまり深い意味はないっす。最近のごちゃごちゃしていた頭の中を文章化しただけですんで・・・
先日、実家にあった無線LANの機器類をパクッてきてしまい、実家へ帰っても無線LANすることができなくなってしまいました。
ネットにつなぐときは、一階へ降りて、自分でケーブルをブスッとさす。この動作が必要になってしまったのです。←どう考えても、パクッてった自分が悪いのですが…
そこでふと思い出したんです。
そういえば、一年くらい前、無線LANアクセスポイントが壊れて、新しいのに取り替えたんだっけ。壊れたやつ、確か押入れの中にしまったままだ。なんで壊れたんだっけ？？
そう、このときおいらは直感的に昔の壊れたアクセスポイントにもう一度電源を入れれば、何事も無かったかのように復活してくれちゃったりしないかな〜と、意味のわからない期待をしていたのです。
案の定、眠っていた無線ブロードバンドルーターを発見。コレガのWireless LAN APRS-11でございやす。
コンセントをさすと、説明書とおりにランプが点灯し、待機状態へとうつります。で、おいらのノーパソの電源を入れて・・・
ワイヤレスなアクセスポイントへ接続っと
・・・・・
やはり無反応。
そこからケーブル使ってアクセスポイントに接続して、何回かリセットして、ファームウェアまで最新のものにして、、、
とにかく色々やったのですが、どうしてもつながりません。送信はされているようで、設定してあるSSIDは見えるのですが、肝心な接続ができないんです。
こうなったら、ドライバーであけて（ニヒヒ
ふたを開けてみると、そこには意外な素顔がありました。
そう、そこで発見されたのは、無線LANのPCカード。無線アクセスポイントの内部には、ご丁寧なことに、PCカードがささっておったのです。この無線LAN PCカード、持っているやつと型番も一緒だし、もしかしたら普通に使えるんじゃ！？
最終的に、内部の無線LANカードを抜かれた無線LANアクセスポイント。こいつの存在価値は一体なんなのだろう…。DHCPくらいか…。
Recent Comments