『関わってもどうせ粘着されるのは.....
タイトル
『関わってもどうせ粘着されるのは漏れなんだよ。大丈夫だよ、
引き受けるよ。そういうの担当だから。きっと。昔から。
それより、スプラッシュ画像楽しんでくださいよぅ。
まあ、もちろん漏れが画像をぶっこぬきしたわけではごじゃらんのでなんでもかんでも
他人のふんどしですけどね。といいつつ文字列処理について』
※タイトルからして、会話形式になっているのですが
話の流れが見えない人は、Delphiサイトやブログを
めぐりにめぐって、みんなのところのカウンターをたくさん
まわしてきてあげてください。
誰かのDelphiページと、コラボレーションしてます。
誰なのかは内緒。
∧,,∧ エーーーーー
ミ*ﾟДﾟ彡
ミつ旦(ﾐ
〜と,,,~),,~)
だって、文字数単位の処理ってするでしょーに。
しないの？楽だよ？考えるのが。
文字数単位に対する処理コードを書けば
エンコードがなんであっても、ソースが一つで済むじゃなくない？
なんか違うのかなあ？どこか理解不足があるのかしら？
例えば、XMLパースとか
HTMLから、http://切り出しとか、
Pascalソースからコメントアウト除去とか、コメントアウトのみ取得とか
コストがかかっても、文字数毎に処理するコードを頭で考えて
「何文字目から何文字目を切り出してー、」
「何文字目から何文字目までの中から、○○を何文字目にみつけてー」
と考えて実装した方が楽でいいんちゃうの？
その処理を、エンコードごとに書くのは、いややわ〜〜
もちろん、高速化チューニングは
リファクタリングですればいいと思うけど
ん？書いて気がついたけど
文字数毎に処理するコードを書くなら
UTF-32に変換してから処理する事がコスト的に早い。
って教えてもらっているので、単にそういう法則？
他の文字コードだと文字数単位での処理はコストがかかるから
そこに問題が生じないように、先頭から文字列処理していって
途中の文字数を求めて何かするという処理には、気をつけろ。
そういう事ね？
あら。納得できてきました。
つまり、漏れの思考パターンではちょっぴり文字列操作処理は
文字数単位で行いたい風に考えてしまうのでそれなら
UTF-32あたりが最適で、UTF-32にキャストしてから
文字処理を行うようなソースを、書いてみるのがいいのであり、
UTF-8でもキャッシュとしてもつ仕組みをつくれば
文字数単位での処理が楽になるのかもしれないが
そんな面倒事を持ち込む前に、文字数単位処理をしないという
選択肢になるんだろう。
俺は物事がやたら簡単になっていれば、誰もが気軽に文字列処理が出来る
ようになっていって欲しいと思ってるので
文字列処理パーサーを作るのが
簡単に出来るようになっていれば、生産性があがると、思っているので
(文字列処理のRAD化)
そのような実装をしたいのなら他のエンコードは遅すぎるから
UTF32形式がいい。
ということですな。
！ ＿＿＿＿＿＿＿＿＿＿＿＿＿
∧,,∧ ／
ミ,,ﾟДﾟ彡 ＜ 勉強になる！！！
ミ.,,Ｏ),,ﾐ ＼
＠ﾐ ﾐ ￣￣￣￣￣￣￣￣￣￣￣￣￣
∪''∪
タイトルからして、話が見えにくいので
解説が必要な方は、漏れにメールください。
ところで、みなさん、、、『FTの事かけよ！』、って思ってらっしゃる？？？
カウンター、あがりすぎですよ。
<<カウンター回りすぎ | ホーム | ちょっと我々にはなつかしの>>
『関わってもどうせ粘着されるのは漏れなんだよ。大丈夫だよ、
引き受けるよ。そういうの担当だから。きっと。昔から。
それより、スプラッシュ画像楽しんでくださいよぅ。
まあ、もちろん漏れが画像をぶっこぬきしたわけではごじゃらんのでなんでもかんでも
他人のふんどしですけどね。といいつつ文字列処理について』
※タイトルからして、会話形式になっているのですが
話の流れが見えない人は、Delphiサイトやブログを
めぐりにめぐって、みんなのところのカウンターをたくさん
まわしてきてあげてください。
誰かのDelphiページと、コラボレーションしてます。
誰なのかは内緒。
∧,,∧ エーーーーー
ミ*ﾟДﾟ彡
ミつ旦(ﾐ
〜と,,,~),,~)
だって、文字数単位の処理ってするでしょーに。
しないの？楽だよ？考えるのが。
文字数単位に対する処理コードを書けば
エンコードがなんであっても、ソースが一つで済むじゃなくない？
なんか違うのかなあ？どこか理解不足があるのかしら？
例えば、XMLパースとか
HTMLから、http://切り出しとか、
Pascalソースからコメントアウト除去とか、コメントアウトのみ取得とか
コストがかかっても、文字数毎に処理するコードを頭で考えて
「何文字目から何文字目を切り出してー、」
「何文字目から何文字目までの中から、○○を何文字目にみつけてー」
と考えて実装した方が楽でいいんちゃうの？
その処理を、エンコードごとに書くのは、いややわ〜〜
もちろん、高速化チューニングは
リファクタリングですればいいと思うけど
ん？書いて気がついたけど
文字数毎に処理するコードを書くなら
UTF-32に変換してから処理する事がコスト的に早い。
って教えてもらっているので、単にそういう法則？
他の文字コードだと文字数単位での処理はコストがかかるから
そこに問題が生じないように、先頭から文字列処理していって
途中の文字数を求めて何かするという処理には、気をつけろ。
そういう事ね？
あら。納得できてきました。
つまり、漏れの思考パターンではちょっぴり文字列操作処理は
文字数単位で行いたい風に考えてしまうのでそれなら
UTF-32あたりが最適で、UTF-32にキャストしてから
文字処理を行うようなソースを、書いてみるのがいいのであり、
UTF-8でもキャッシュとしてもつ仕組みをつくれば
文字数単位での処理が楽になるのかもしれないが
そんな面倒事を持ち込む前に、文字数単位処理をしないという
選択肢になるんだろう。
俺は物事がやたら簡単になっていれば、誰もが気軽に文字列処理が出来る
ようになっていって欲しいと思ってるので
文字列処理パーサーを作るのが
簡単に出来るようになっていれば、生産性があがると、思っているので
(文字列処理のRAD化)
そのような実装をしたいのなら他のエンコードは遅すぎるから
UTF32形式がいい。
ということですな。
！ ＿＿＿＿＿＿＿＿＿＿＿＿＿
∧,,∧ ／
ミ,,ﾟДﾟ彡 ＜ 勉強になる！！！
ミ.,,Ｏ),,ﾐ ＼
＠ﾐ ﾐ ￣￣￣￣￣￣￣￣￣￣￣￣￣
∪''∪
タイトルからして、話が見えにくいので
解説が必要な方は、漏れにメールください。
ところで、みなさん、、、『FTの事かけよ！』、って思ってらっしゃる？？？
カウンター、あがりすぎですよ。
