Faith最悪！！使いづらいったらありゃしねぇ（ー＿ー；）仕様は分かりづらいは、途中で申し込みデータ消えるは、かなり手間取った。今回はしかたない事情があるのでFaithで購入することに決まったけど･･･今後は二度と使うか。その点、ドスパラは親切。仕様や特徴が分かりやすい。初めて買うならドスパラだね♪　今後はドスパラを利用しましょう！一応フォロー。玄人にはFaith が人気らしいです。玄人に言わせると「ドスパラは商品数が少なくて選べない」そうです。確かに随分と数に差がありましたねぇ。

　先日にWebメモでデータが消えたのは、容量不足みたいですね。編集の際には、いったんコピーを作成してから編集、そして上書き移動、という形式をとっているのですが、そのコピー分の容量が足りなかったみたいです。CGIで0.9MB、それ以外のファイルで18.4MB使ってるんですが、限界容量が20.0MBなんですよね〜。なるほど納得。最初はWindows のサムネイル構成ファイルやFTPログファイルも容量にカウントしてたもんで「あれ？既にトータル20MB超えてる。ってことはCGI容量は別計算なのかな？」とか勘違いしてたので、原因＝発生要因がわからずかなり焦りました。分かれば対処法も出てくるってもんですｗ

　昨日「結局そのうちやるんだろうなぁ」とか言ってたCompleteGetterの改良。さっそく今日やってしまいました（爆）。思わぬ功名、String型じゃなくてChar型で書いてみたら随分とすっきり書けました。が、サクサクおわったのはそこまでで。その後、連続でDLL経由で呼び出してみたところ、予期せぬエラー多発（T＿T）。多粒子系じゃないんだから、そんな１つのころには現れなかった性質がボコボコ出てこられても困ります（＠＿＠）。辛いのは、モジュール単体で呼び出したときはエラーせずに、複数モジュール経由で連続呼び出しをして初めてエラーするタイプのバグなので、動作確認に時間掛かることかかること。てか、これはコンパイラ側の問題だし･･･。私にできるのは根本的解決じゃなくて、どうやったら避けられるか、ということだけ┐（−ε−）┌　結局、配列自体のメモリを動的確保して、そのポインタを渡す形になりました。String型、コイツ使えねぇ〜〜〜。すぐスタック・オーバーフローしやがる。まぁ10Kbyteくらいザクっと定義してるから、ありえるっちゃあありえるのか。はぁやれやれ。
　でも、苦労の甲斐あって、10倍以上も早くなりましたｗ　以前に１時間以上かかってたものが5分そこらで終わりまっせ☆　もうちょっとバグ取りしましたらアップしますので、こう御期待！（＾＿＾）

　CompleteGetterはActiveBasic Ver2.6で作っています。C言語に比べて、Window管理とマルチスレッド管理がはるかに楽なのです。ただ中間コード型なので、実行コード型のC言語に比べると動作がずいぶんと遅いのが欠点。
　そこで登場する「別の方法」とは、一番時間のかかるリンク走査部分を実行コード型であるActiveBasic Ver3.xで書いて、DLLとして呼び出すというもの。こうすれば、ぐっと早くなるはずなのです！　･･･ところが、実際にやってみると問題が２つ。
　一つ目。Ver2.xとVer3.xではString型変数（C言語のStringクラスみたいなものです）のコンパイラ側での扱い方が違うみたいなんですが、そのせいでDLLを介してのString型配列が正常に渡せないことが発覚。プログラミング質問掲示板で聞いてみるも、どなた様も正確な理由はわからない模様。コンパイラ製作者本人が出てきてくれれば分かったかもしれないが、そこまで暇じゃなかろうし。
　２つ目。Ver3.xで書いても、そこまで歴然とした速度差が出ない。たしかに若干は早くなるのだが。

そんなわけで諦めていたのだけれど。先日、とある方法を思いつく。
「C言語のChar型配列の概念に倣って、でっかいString型変数を1つを用意して、一定Byte数ずつ区切って、それぞれを配列要素扱いして渡せばいいんじゃねぇか？」
Char型でch[10,256]とか宣言すれば、256ByteずつのChar型文字列の配列10個、って扱えますよね？　んでこれって実体は、配列0番要素はこの変数の開始アドレスから255Byte目まで、1番要素は256Byte目から511Byte目まで･･･ってなってましたよね？　同じことをString型に対して自力でやれば良いんでない？ってことですｗ　で、やってみたら無事に成功しました♪　ポインタ万歳（笑）。
　･･･実は、以前に聞いた質問掲示板でも、最後にとある方が問題の回避方法（正確に渡す方法）を提示してくれてました（＾＾；）。でもそれはHeapReAlloc関数使ってたので、私は「？？？」ってなって投げ出したんですねー（苦笑）。いえ、さっきHeapReAlloc調べて理解しましたけど。ちなみに、代入文字列あわせて各配列要素のByte数を変動させる、という賢いもの。使用メモリ数の節約ですね。それを除けば、やってることは今回私が考えたことを似たようなことでした。ちょっと嬉しいｗ　やっぱこれが正しい解決法っぽい。
　
　2つ目の問題に関しても少々進展が。先日追加した広告削除機能は、Htmlファイルから広告っぽい文字列を探して削除しているので、ようはリンク走査と似たようなことをやっているんですが（リンクのほうが探す文字列パターン多いですけど）。これもVer3.xで書いてDLLとして呼び出してるんですが、リンク走査と同じ機構のはずなのに、動作がやたらめったら速い。･･･あれ？　そんなに速度差は無いはずなのに。　と、ふと気付く。「もしかして、String型を使わずByte型（C言語のChar型に相当。以下Char型と書く）のみで扱っているからか？」　個人的推測ですが、Ver3.xでのString型ってコンパイラによる自動動的確保＆開放のChar型文字列じゃなかろうかと。自動なのでコードを書く側からすると扱いは楽なのですが、一方で文字列の連結などの操作を行うたびに新たに確保しなおしてコピーして元の領域を開放、ってな作業がなされるだろうと思うのです。一般のChar型のように、あらかじめ必要な領域を確保しておいて、その中で操作が行われれば、その手間が省けるので、その分だけ動作が速くなっているのかもしれません。
　
　これはぜひともChar型のみでコードを書いて高速化しなきゃ！　･･･が、これまでString型で書いていたので、全部書き直す必要が･･･それはヤリタクナイ（−＿−）　しかも、実際に書いてみないことには、本当にそんなに目に見えて高速化するのかが分からないという罠。散々苦労して書き直した末に「なんだ、結局変わらないじゃないか」では泣くぞ（＞＿＜）

　まぁ･･･結局そのうちやるんだろうなぁ┐（´ー｀）┌

　数年ぶりに見てみると。「神様」と呼ばれていた人の演技が、いかに飛びぬけてたかが分かります。技術力だけじゃなくて構成力とか含めた総合力が、ずば抜けてます（・□・）。以前に見てたときは「さすがは同等！」と思ってた、神様の一番弟子と呼ばれている方の演技ですら、今見比べると実は結構の差があるよう感じました。技術力は確かに同レベルにまで達しているのですが･･･魅せるオーラが違います。神様の演技は、その気も無いに、気が付いたら目がくぎ付けにされちゃってました。最後まで見ちゃいました。飽きが、中だるみがサッパリ無い。それでいてメリハリも付いてるときちゃあ･･･流石は神！　そりゃ全国大会でも優勝する罠。うん、確か彼は優勝してたはず。
　あ、名誉のために追記。一番弟子の方のレベルにある演者は、神様とその仲間のもう一人を除いて私は知らないです。つまり十分に雲の上の達人レベル┐（´ー｀）┌

他には『親が、中でドラ・暗カン、1万2千点は確定☆』とかありえないってｗ　ちなみにその場はその後さらに別の方が明カン。ドラ牌が３枚ですよｗここはもちろんリーチでしょうｗ　ちなみにそのカンしたお二方が曰く「カンする意味無いけど、した方が面白いっしょ、この状況」だそうで。わかってらっしゃるｗ
　私の成績は、初回はリーチしたら実はチョンボで、上がり放棄の末に親満貫に振り込んだ〜（T＿T）もちろん最下位＿|￣|○　南場３局でのこれは痛かった。
　２回目はビックリ。５万５千点でトップ賞♪　もちろん、一人ハコリましたｗ　配牌で一盃口とか、ありえないほど幸運に恵まれました。親でメン・タン・ピン・三色・ドラドラでツモ！とか、笑いが止まんなかったぜ♪（＾▽＾）
　３回目へ２位。この回は、「ロン、跳満♪」と喜んでたら、次局で「ロン、跳満」されたり。点数がそのまま移動とか。まぁマイナスならなきゃ良いのですｗ　そいや、この局だっけ、小四喜テンパられたの（汗）。振り込まなくて良かった〜〜（−＿−；）役満かぁ。一度でよいから上がってみたいｗ
　なにはともあれ、リアル麻雀で５万５千は多分初めて。嬉しかったのです♪＼(＾▽＾)／

　この広告削除操作では、ファイルサイズの分だけメモリを動的に確保してChar型変数に読み込み、広告部分を削除したのちにファイルに書き込む、そして確保したメモリを開放、という方法を取っているのですが、どうにも最後のメモリ開放のところでエラーが続いて困りました。
　原因はNULL文字の分？だけメモリの確保が足りなかった、と言うことみたいです。ReadFile関数はNULL文字を自動付加はしてくれないらしく、そこにlstrcat関数とか使っちゃうと「どこまでが文字列？」という状態になり、ゴミ文字がついたり、確保した範囲を超えてメモリ空間にアクセスしたりするみたいです。ここの動作の詳細は不明。
　8Byteほど多くメモリを確保して、あらかじめZeroMemory関数でNULL文字で埋め尽くしておくことで、問題は解決しました。こうしておけば必ず終端はNULL文字になる、ってことですね。（あれ、でも普通に考えたら1Byte多く確保するだけで十分な気がするのだが、それだとなぜかエラー解決しなんだよね。まぁ薮蛇になっても困るから、深くつっこまず放置で^^;）　どーりで、あちらこちらのサンプルでZeroMemory関数にお目にかかるわけだ。

　別件ですけど、ポインタを１つ進める≠メモリ空間を１Byte進む、なんですよね。忘れがちで、ついイコールで結びたくなっちゃいます。実際は『変数に応じたバイト分（Long型なら32bit=4Byte）メモリ空間を進む』が正解。Char型の場合は8bit=1Byteなので勘違いしてても問題は無いはずですが。