これがβ版は最後の予定です。今回は、ＨＴＴＰのプロトコル処理と、スレッドの管理方法を変更しているので、ImageGeterのかなり中枢部分が書き換わりました。作成当初の未熟なコードを一新できたので、気分的にはかなりすっきりですね。
スレッド処理は、今時のＣＰＵではそれほどロスはないと思っていましたが、バグ取りもしにくい構造でしたし、無駄な処理が多かったのは確かなので、思い切って処理を変更しました。個人的な汎用ライブラリとして作成できたので、まぁ、これはこれで価値がありかと。
ＨＴＴＰプロトコルの処理は、バージョン１．１で処理すべき圧縮転送と、チャンク形式の転送処理を実装していなかったので、今回はしっかり対応しました。これのおかげで通信での無駄はかなりなくなると思います。コネクションの接続維持も実装しようと思いましたが、意外と対応しているサーバーが少なかったので今回は見送りました。
今回のバージョンで特に大きな問題が無ければ、正式にリリースしようと考えています。
TKFP.DLLの不具合を調べていたら恐ろしい事実に気付いてしまいました。.NET FrameworkのIndexOf関数がカルチャに影響されるらしい。具体的には
"xxドラエモン".IndexOf("ト゛ラ")
の結果が「-1」では無く「2」なってしまいます。
今回、不具合が発生したのは
"/ー".IndexOf("//")
が「-1」にならなかったことです。
.NET 2.0 ではまだIndexOfに比較オプションが指定できるので比較的簡単に回避できたのですが、.NET 1.1ではそれが使えずに
System.Globalization.CultureInfo.CurrentCulture.CompareInfo.IndexOf
などと言う、関数を使う羽目になりました。
今更、.NET 1.1での影響はほとんど無いのですが、TKFP.DLLでは両バージョンを同一のソースで管理しているので、おかげでコンパイルオプションだらけです。
他にも、StartsWith とか EndsWith とかも影響するようなのでちょっと見直す必要がありそうです。ContainsとかReplaceが影響しないのがさらに混乱するんですけどね。
そもそも、この仕様ってどうなんでしょう？あいまいな日本語比較より厳密な文字比較をする場面のほうが圧倒的に多いような気がするので、あいまい比較をオプションにするべきだと思うのですが。
難読化用の属性に対応するのは前々から考えていたのですが、なかなか実装できませんでした。今回、別の不具合も発見されたのでそのついでに、実装に踏み切りました。検討している段階では、属性の削除など問題になりそうな点も有りましたが、実装してみると意外とすんなり機能するようになりました。これも、基本の設計がいい事にしておきましょう。
さて、この難読化プログラム「NanDoku」ですが、実は設定ＧＵＩには無い機能が実装されています。アセンブリの設定で保存した「なんとかini」ファイルに
ExtendOverload=True
と、追加すると、さらに強烈な同一名称の使用を行なうようになります。
大体、第１位置候補の文字使用率が１０％ほど上がります。
難読化自体に魅入られた方は一度試してみてください。
当プロジェクトのプログラムはこの設定で全て難読化しているので、それなりにの実績もあります。
なぜ、効率が上がるのかと、非公開なのかはまた機会があれば．．．
我が家のインターネット環境が復活しました。先日、モデムが故障した時にサポセンでは、３日から１週間かかると言われてへこんでいたのですが、奇跡的に２日後に新しいモデムが届き無事復旧が出来ました。最近ではあたりまえなのかもしてませんが、おまけにモデムに初期設定までして有ったのは、ちょっと感激です。５年近くまえに常時接続にした時にはルーター関連の設定も自力でやったのですが、最近は初心者も考慮してかつなぐだけでＯＫなんですね。
うちのADSLモデムがお亡くなりになりました。
レンタル品なので金銭的損失は無いのでよかったのですが、
連休前にインターネットに接続できないのはつらい。
故障早々にプロバイダーのサポートへ電話してみるも、時間帯が悪いのか一向に繋がりません。
気は短くないので、そのまま３０程度放置してみました。
空き時間に何かしようとPCを前にして凍りつきましたね。
インターネットに接続できないと何も出来ない！
困ったことにプログラムすら書けませんね。
ここまで依存しているとは正直思っていませんでした。
おかげでカーステ用のMP3データが大量に作成されました。
何とかサポートに繋がり症状を伝えましたが、予想通りのモデム交換で、３日～1週間との返事をいただきました。orz
奇跡的にモデムのカードを発見したので、おかげで、ダイヤルアップでネット接続しています。
とある作業にて大量の文字列中に特定の文字があるかどうかの検査を行う必要があり、そのときに確認した内容です。
.NET Framework 2.0 以前では文字列の存在確認で
IndexOf("あ") != -1
などという記述を大量にしていました。
最近は、
Contains("あ")
で代用することが多くなり、またこの使用法が正攻法でしょう。
通常は特にに気にしていませんでしたが、検索作業自体で数十秒かかるようになると話は別です。で、幾つかの方法を試してみることにしました。コード自体が読みにくくなる改変は避けたいので、候補は以下の3つで
(1)．IndexOf("あ") != -1
(2)．Contains("あ")
(3)．IndexOf('あ') != -1
処理速度は (3)、(2)，(1)の順で、(3)は(1)の十倍程度早くなりますね。最も、(3)は使用できる場合が限定されますが、(1)からの改変でほとんど見た目が変わらないのはいい感じです。(2)は内部では(1)を読み出していると思っていたので、最も遅いと思われましたが、検査条件を限定することで早くしていうるようで、これだけでも数倍の処理速度の差が発生します。
対象が文字列なので、すべて期待している結果が出るとは限りませんが、(1)の表記
IndexOf("あ") != -1
は、今後登場する機会はなくなりそうですね。
以上を踏まえると、大量の文章から該当するデータを探す、たとえば過去のメールデータからある文字が存在するメールを検索するようなことをする場合は、一旦、検査する先頭文字で「IndexOf('あ') != -1」と仮検査し、該当するものだけを本検査にまわす方法もありかと
最近のブログ更新がソフトのバージョンアップばかりになっているは良くない傾向です。今回はアンケートでの要望を重点的に修正しました。表面的な修正が多いのの致命的な不具合は無いと確信しています。 実はこの後に、もう次のバージョンが準備してありまして、現在最終のバグ取りの段階まで来ています。ＨＴＴＰの通信部分の全書き換えと、スレッド管理の最適化を行ったので、ツボにはまれば「軽量」「高速化」と行くでしょうが、失敗すると破綻しそうで怖いです。今のところ、コンパイルのオプションで常に全バージョンでコンパイルできる状態を維持しながら、慎重に書き換えをしています。で、そろそろβ版も終了したいのですが、どなたかテスト用の私にVISTA環境を提供してくれませんかねぇ。
最近のコメント