natsuの秘密基地です
カレンダー
| 03 | 2025/04 | 05 |
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 |
カテゴリー
プロフィール
ＨＮ：
natsu
性別：
男性
趣味：
酒など
自己紹介：
ここに書かれていることはフィクションです。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
ある意味で、ある文章から特定の文字列を
抜き出さなければならないという仕事は、
いつだってある仕事なのだと思う。
従って、「ある意味で」という言葉を文書から検索し、
その位置を導きだすこというサンプルは、
ある意味、非常に有益だと思う。
管さんはある意味でを使い過ぎらしい。
ある意味で。
これまで、なんか重い話題が続いたので、
ある意味ちょっと息抜きで。
レッツrangeOfString:options。
第一引数で検索したい文字列を指定。
私の場合、@"ある意味で"。
第二引数はオプション。
実際はunsigned int。
オプションは適宜指定で。
まずは無しで検索してみたいの私は0で。
戻り値のNSRangeはlocationとlengthを持つ構造体。
NSLog(@"location : %d length : %d", range.location, range.length);
とかやれば値が見れる。
locationは先頭の文字を0として、
多バイト文字でも文字数で何文字目か出してくれる。
lengthも文字数。
私の場合、「ある意味で」が２回登場するので、
もう一回やる必要がある。
ふつう２回出る、なんて知らないので、
do whileで回す必要がある。
そんなとき、rangeOfString:options:range:。
第三引数で、残りの部分を指定してやればいい。
range= NSMakeRange(0, 0);
result = NSMakeRange(0, 0);
do
{
range.location = result.location+result.length;
range.length = [base length] - (result.location+result.length);
result = [base rangeOfString:@"ある意味で" options:0 range:range];
if(result.location != NSNotFound)
NSLog(@"location : %d length : %d", result.location, result.length);
}while(result.location != NSNotFound);
オプションについてはunsigned intなんで、
cのノリで
NSCaseInsensitiveSearch | NSLiteralSearch
とかしちゃえばOK。
例えばこんなオプションがありんす。
NSCaseInsensitiveSearch
大文字小文字を区別しない。
NSLiteralSearch
これを指定した場合、byteをみて比較する。
例えば、UCS2で3071,306F,309Aとした場合、
それは"ぱぱ"となる。
3071が"ぱ"。
306Fが"は"。
309Aが"゜"
"ぱは゜"ではなく、だいたいちゃんと"ぱぱ"と表示される。
このオプションを指定すると、
3071の"ぱ"で検索した場合、
306F,309Aの"ぱ"で引っかからなくなる。
NSBackwardsSearch
終わりから検索。
エディタの"前を検索"を実装するときに使うんだろうなと。
NSAnchoredSearch
先頭しか検知しない。
（NSBackwardsSearchのときは最後）
NSNumericSearch
文字列に含まれる数値で比較。
たぶん、compare:optionsとか使うときに使う。
NSDiacriticInsensitiveSearch
発音区別符号無視。
無視すると、'ö’は‘o'で検索に引っかかる。
試してないけど。
NSWidthInsensitiveSearch
全角ａが半角aとマッチするようになる。
半角aもまた全角ａとマッチするようになる。
NSForcedOrderingSearch
compare:optionsとかで使えるんだと思う。
こいつは言ってることがよくわかんなかった。
NSCaseInsensitiveSearch指定で"aaa"<"AAA"らしい。
NSCaseInsensitiveSearchとNSLiteralSearchが大事なんだと思う。
PR
キューを作って、実際使ってみた。
なんかデータを入れようということで、
NSDateとintを持つクラスを作り、
そのオブジェクトをキューに放り込んでみた。
で、取り出す。
放り込む人が５スレッド。
取り出す人が３スレッド。
ばらばらばらばら。
ログが入り乱れる。
放り込んだときと、
取り出したときにNSDateとintの内容を表示する。
で、取り出したとき、280個目あたりで落ちる。
どうも、NSDateの内容が無効になっているみたいだった。
気づくのにだいぶ時間がかかってしまった。
[NSDate date]で
かえってきたインスタンスをそのまま使っていたのが
まずかったんだと思う。
retainしてなかったんだな。
retainは大事だと思った。
頼りない感じだけど、
こんな感じでいんじゃね。
と、おもわれ。
できたてほやほや。
もうちょっと試さないといかんね。
ロックをしたいとき、
どんな方法がとれるのか調べてみたけど、
以下の３つからどれにしようかといったところ。
・@synchronized
・POSIX mutex
・spin lock
なにも考えずにやりたい場合、
普通は@synchronizedでやればいいんだと思う。
POSIXのmutexも特になんも考えなくていいと思う。
spin lockはなんか、もっと低レベルの仕組みなんだと思う。
ドライバ書いたりする人はこんなの使うんでしょ。
ちょいと調べる限り、
ロックで待ってる間はビジーループで回るとかなんか書いてあるけど、
最近の実装じゃ、もっとうまいことやるでしょ。
きっと。
ほかのスレッドにCPU渡したり。
spin lockは実際に使わないと思うけど、
実験だし使ってみる。
計測計測。
ロックかけて
インクリメント
ロック外す
を10000回まわしてみる。
インクリメントすらスレッドセーフではない世の中。
何を信じればいいのか。
阿弥陀様を信じればいいと思うよ。
さて。計測計測。
一応すべての方法で、ロックがうまいこといくのは確認。
ロックなし
大体 0.035ms
@synchronized
大体1.84ms
POSIX mutex
大体0.65ms
spin lock
大体0.29ms
10000回連続でロックとアンロックをやってるので、
なんとかテクノロジ的なもので、
２回目以降は速くなるのかもしれないけど。
一回あたりのロックは
@synchronizedでも計測する意味が無いレベルだと思う。
とりあえず、
普通に使う分ではどれでも問題ない気はした。
すくなし、
@synchronizedなんて遅くて使えないよー。
なんてことは、いわないと思う。