2025
01
18
2008
11
19
文字コード一括変換
findとxargsとnkfを使った文字コード一括変換
find . -type f --name "*.txt" -print0 | xargs -0 nkf -w --overwrite
ファイルを探す。
それを引数としてnkfに渡す
変換する。UTF-8に。
2008/11/19 (Wed.) Trackback() Comment(0) 未選択
2008
09
26
MFC ソケットの使用時によくある 2 つの誤り
1. | support.microsoft.com/kb/185728/ja OnReceive 通知関数で、Receive 呼び出しを複数回実行する。 CSocket クラスは、すべてのデータが受信されるか完全に送信されるまで CAsyncSocket Receive 呼び出しおよび CAsyncSocket Send 呼び出しをループすることにより、Receive および Send 呼び出しに対してブロッキングを行います。そのため、Csocket および CAysncSocket のソケット タイプはどちらもブロッキング非対応です。ブロッキング非対応のソケットでは、TCP スタックからアプリケーションに FD_READ 通知が送信されて、データがあることが示されます。MFC により、その FD_READ 通知が OnReceive 通知呼び出しに割り当てられます。 Windows ソケットでは、recv 呼び出しの前の FD_READ 通知を無効にするのでない限り、1 つの FD_READ 通知で recv を複数回呼び出すことは避ける必要があります。しかし、CSocket および CAsyncSocket には、通知を無効にするしくみは備わっていません。そのため、Receive 呼び出しは、OnReceive 関数 1 つにつき 1 回だけ実行するようにします。また、データの転送速度が速い環境で、OnReceive 関数内で Receive 呼び出しを複数回実行すると、アプリケーションで FD_READ が認識されなくなり、偽の FD_READ が生成されるか、FD_READ が失われる (ハングする) ことがあります。 CSocket を CArchive および CSocketFile と一緒に使用して、MFC の CObject から派生したオブジェクトを直接受信または送信することができます。しかし、データの転送速度が速い環境では、内部で複数の Receive 呼び出しが生成される可能性があるため、CSocket を CArchive および CSocketFile と一緒に OnReceive 関数内で使用しないようにします。 |
||||||
2. | CAsyncSocket::Send 関数を使用する際に、すべてのデータを送信するために必要な回数の Send 呼び出しを実行しない。 非同期の Send 呼び出しを実行してバッファを送信した場合、実行結果には次の 3 とおりがあります。
3 番目の場合には、TCP/IP スタックでは、さらにバッファ領域を解放すると、MFC により OnSend 通知関数に割り当てられた FD_WRITE 通知をアプリケーションにディスパッチします。この時点でプログラムは、すべてのデータが送信されるか、WSAEWOULDBLOCK が発生するまでデータを送信し続ける必要があります。 OnReceive または OnSend の外部で、CSocket Receive および CSocket Send を使用する (つまり、デフォルトの何も実行しない OnSend および OnReceive を使用する) 場合には、Receive および Send をループで使用することや、CArchive および CSocketFile と一緒に使用することができます。 |
2008/09/26 (Fri.) Trackback() Comment(0) 未選択
2008
09
19
日付単位にログをとる
DailyRollingFileAppender
日単位で backup を取る Appendar。
・File ---- 保存するファイル
・DatePattern ---- backup ファイルの suffix
※以前にログを書いた日付と比較して日付が進んでいたら test.log.yyyy-MM-dd にファイルを退避する。 それから test.log にログを出力するという動作をとる。
# com.fc2web.himtodo.test
log4j.category.com.fc2web.himtodo.test=DEBUG, TEST
log4j.appender.TEST=org.apache.log4j.DailyRollingFileAppender
log4j.appender.TEST.File=C:/logs/test.log
log4j.appender.TEST.DatePattern='.'yyyy-MM-dd
log4j.appender.TEST.layout=org.apache.log4j.PatternLayout
log4j.appender.TEST.layout.conversionPattern=%d{yyyy/MM/dd HH:mm:ss.SSS} [%p] - %m%n
VM の再起動等を行うとログがロールしない場合があるので要注意
2008/09/19 (Fri.) Trackback() Comment(0) 未選択
2008
09
18
通知領域にアイコンが登録されないことがある
support.microsoft.com/kb/418138/JA
2008/09/18 (Thu.) Trackback() Comment(0) 未選択
2008
09
11
テスト プロジェクトと Visual C++
テスト プロジェクトと Visual C++
テスト プロジェクトには、プロジェクトに設定したコンパイラ オプションに基づいて、さまざまな機能があります。詳細については、「コンパイラ オプション」および「/clr (共通言語ランタイムのコンパイル)」を参照してください。次のセクションでは、さまざまなコンパイラ オプション設定で利用できる機能について説明します。
アンマネージ
テスト プロジェクトのプログラミング言語として、アンマネージ (ネイティブ) Visual C++ は使用できません。
混合
混合プロジェクトとは、/clr コンパイラ オプションを使用するプロジェクトです。この種類のテスト プロジェクトでは、次の実行コードをテストする機能が提供されています。
-
静的なネイティブ ライブラリ
-
ネイティブ DLL エントリ ポイント
-
スタンドアロン .obj ファイル
-
呼び出し可能なメソッドを備えた混合モード DLL アセンブリ。実行可能ファイルにはアンマネージ コードが含まれ、一般にアンマネージ実行可能コードは、再ベース アドレス対応ではないため、これには実行可能ファイルは含まれません。
-
呼び出し可能な任意のマネージ メソッド。/clr:pure または /clr:safe のコンパイラ オプションでコンパイルされるコードです。
安全または純粋
/clr:pure または the /clr:safe のコンパイラ オプションをテスト プロジェクトで使用している場合は、呼び出し可能なマネージ メソッドをテストできます。つまり、/clr、/clr:pure、または /clr:safe のコンパイラ オプションでコンパイルされる実行コードです。
コードの生成と Visual C++
単体テストを Visual C++ テスト プロジェクトに生成できます。これらのテストは Visual C++ 実行コード プロジェクトから生成できます。次の点に注意してください。
-
実行コード プロジェクト。実行コードが Visual C++ で記述されている場合、製品で /clr:safe コンパイラ オプションを使用する場合のみ単体テストを生成できます。
-
テスト プロジェクト。 コードの生成によって、Visual C++ テスト プロジェクトのあらゆる種類 (混合、安全、および純粋) で単体テストを作成できます。作成される既定のプロジェクトの種類は、/clr:safe プロジェクトです。プロジェクトを /clr または /clr:pure に変更する場合、常に Visual C++ コンパイラ オプションを使用して、それを行います。詳細については、「/clr (共通言語ランタイムのコンパイル)」を参照してください。
2008/09/11 (Thu.) Trackback() Comment(0) 未選択