ゆく年

えー、相変わらず更新頻度は最低レベルです。日常が忙しいとなかなか手が回りません。記事を書く事そのものは兎も角、記事の元ネタとなるべきプログラミングが。

そんなこんなで多分来年もあんまり状況は変わらないように思いますが、ぐぐって偶然探してた事が見つかってラッキーみたいなのを目指して頑張ります。

今回はちょっとしたことをいくつか。

• ジェネリクスの型制約になぜ delegate キーワードや Delegate クラスが使えないんだー！

• アンマネージドとの相互運用にもジェネリクスを使わせろー！　せめて DllImport だけでも！

あれ、それだけ？　ときどきふと思うことも色々あった気がするけど今思い返すと取りあえずこれくらいしか出てこないや。

それではまた。ごきげんよう。

もどかしさ

間違ってるのは分かるけど、ではどうすれば良いのかは分からない。

そんなことって良くありますよね。

とあるスレッドを見ての感想ですが。

失意の底に沈んで

唐突に、メインに使用していたノートPCが壊れました。何かの拍子に完全に止まってしまうという凶悪なもの。起動もままならないことさえあるので、マザーボードかメモリの不良と思われます。

幸いデータの退避は何とかなりましたが、困ったのは.NWT 2.0のSDKです。もうすぐ日本語の正式版が出るのに今更ベータ版を入れる気も起きませんが、かと言ってMSDN2は耐えられない重さ。

ほかにも色々快適だった環境が失われたわけで、再建が大変です……。

DDEMLの妙な癖

ちょっとしたつぶやき。

DDEMLの.NETクラス化は一応続けています。まあおおよそのところは把握しました。しかし一点、理解できない点があります。

DDEにはコールドリンク、ウォームリンク、ホットリンクの3種類があります。このうちコールドリンクは単純にクライアントの要求にサーバがデータを返す、と言う単純な構造なのでまあいいんです。

問題はウォームリンクとホットリンク。これらはサーバ側がループ（アドバイズループと言います）を回し、何らかの条件が変わったとかそう言うタイミングでクライアントに通知する、という構造なんですが、両者の違いとして、ウォームリンクの方は通知するだけに留まるのに対し、ホットリンクは変更されたデータそのものも同時に送信するという差があります。

で、クライアント側はこの二つを、サーバ側にアドバイズループ開始を要求するメッセージを送信するときのフラグで分けます。

頭が痛いのはサーバ側の実装です。クライアントからのアドバイズループ開始要求を受け取るとき、ホット/ウォームに関するフラグが失われてしまうようなのです。つまりサーバ側はクライアントがホットリンクを要求してきたのかウォームリンクを要求してきたのか全く分かりません。これではクライアントが正しい要求をしてきたかどうかも分かりません。例えばホットリンク要求だけを突っぱねるなんてのが不可能になります。

DDEサーバは両方を透過的に扱えってことなんですかねぇ。

検索エンジンから来て残念な思いをする方増加中？

トップページに10件も表示していると、記事にまとまりがない関係で検索エンジンから「残念ですがそれはうちのサイトでは……」なキーワードでいらっしゃる方が多いようなので、取りあえず3件だけ表示するようにしてみました。C言語のオーバーフローチェックなんて記事はありませんから！（あ、こんなの書くと一層引っかかるようになっちゃうのか……）

ところで検索エンジンの順位が全体に妙に高いんですが、これってBlogの特徴なんですかね？　そう被リンク数が多いとも思えないんですが。作ったばっかりだし。「C言語 オーバーフロー チェック -バッファ」で何故10位以内に来るんですかGoogleさん。Blogの弊害ですか。……しかしほかのを見てもC言語に直接関する記事が余りないですね……。

あ、こんなのやって欲しいって意見は歓迎しますので（採用できるかは私の技術力次第ですが）好きにコメントを残してくださいね。もっともASP.NETは管轄外ですのでそれ以外で。あ、ADO.NETもほとんど管轄外だ。デザインとかにはこだわりませんし。……まあこれまで/これからの記事の内容を見てその辺は判断して頂ければ。