strstrの拡張No.03169
h-tom さん 09/08/20 00:51
 

h-tom です。

strstrですが、第3引数を追加して、検索開始位置を指定できないでしょうか?

endmacroで、execmacro実行時の戻り値の指定が、可能になりましたが、複数の
戻り値を返すために、適当な区切り文字を使って結合し、分割する場合など、
現状のstrstr関数だと、途中から検索できないため、対象文字列自体を加工する
必要があります。
hmjre.dllの関数を使う方法もありますが、組み込み関数で、可能になれば、
うれしいです。

[ ]
RE:03169 strstrの拡張No.03173
IKKI さん 09/08/20 06:38
 
こんにちは。IKKI です。

> strstrですが、第3引数を追加して、検索開始位置を指定できないでしょうか?

賛成1票。(‥)ノ

# 欲を言えば、マクロ側で loaddll せずに、文字列変数に対する正規表現検索/置換
# ができるとうれしいのですが…。
# 田楽 DLL を使っている最中に HmJre.dll の ReplaceRegular() 関数を使いたい
# 場面があるのですが、現状では 2 つ以上の DLL を同時にロードできないので、
# このようなマクロを作るのにアクロバティックな手法が必要です。

以上、ご検討いただければ幸いです。

[ ]
RE:03173 strstrの拡張No.03174
Iranoan さん 09/08/20 09:30
 
 今日は、Iranoan です。
> 現状では 2 つ以上の DLL を同時にロードできないので、
 これ関しては、tkinfo.dll の LoadDll(), DllFunc(), FreeDll() に当たる
関数と、DLL 自体を用意して頂いたほうが汎用性が高く使い勝手がよいと思い
ます。

[ ]
RE:03174 複数DLL対応No.03180
IKKI さん 09/08/20 12:07
 
こんにちは。IKKI です。

>  これ関しては、tkinfo.dll の LoadDll(), DllFunc(), FreeDll() に当たる
> 関数と、DLL 自体を用意して頂いたほうが汎用性が高く使い勝手がよいと思い
> ます。

その通りですね。
秀丸エディタ自身が複数の DLL を扱えるようになることで、次のようなメリットが
考えられます。

・マクロ作者としては、DLL をロードするためだけにステルス秀丸を起動する
 ような妙なテクニックが不要になり、マクロ製作上の壁が取り払われる

・DLL 作者としては、他の DLL にある機能を自作 DLL に取り込む動機が
 なくなり、車輪の再発明が避けられる
 
v8 正式版までにぜひご検討いただきたいと思います。> 秀丸担当さん

[ ]
RE:03169 strstrの拡張No.03182
秀丸担当 さん 09/08/20 12:53
 

>strstrですが、第3引数を追加して、検索開始位置を指定できないでしょうか?

それができたら便利だと思います。
検討させていただきます。
現状でhmjre.dllを使わずにやるとしたら、midstrなどでいったん別の変数にして
対策できるのではないかと思います。

[ ]
RE:03180 複数DLL対応No.03183
秀丸担当 さん 09/08/20 12:54
 

loaddllが複数できるようになったらいろいろ便利だと思います。
できるかどうかわかりませんが、ネタとして参考にさせていただきます。

[ ]
RE:03182 strstrの拡張 (midstr も)No.03318
A1 さん 09/08/24 20:42
 
A1 と申します。横から失礼します。

> >strstrですが、第3引数を追加して、検索開始位置を指定できないでしょうか?

> 現状でhmjre.dllを使わずにやるとしたら、midstrなどでいったん別の変数にして
> 対策できるのではないかと思います。

strstr() 関数に加えて、 midstr() 関数の第 3 引数を省略可にして

    midstr($s, #i)  // $s の #i 文字目から後ろ全部

と記述できると有難いのですが…

    例: $s = midstr("abcde", 2);    // $s == "cde"

--↓-動機-------------------------------------------------------------------
-----------
    strstr() を適用しながら midstr() で切り出すことは時々ありますが、
    「残り全部」というのを文字数で指定しなければならない為、
    (以下の) (2),(3) の様なズルをすることがありました。

        (1) midstr($s, #i, strlen($s)-#i);  // 多分、本来の書き方($s と #i
を2回評価)
        (2) midstr($s, #i, strlen($s));     // 反則(正しく動作するがヘン。$
s が2回)
        (3) midstr($s, #i, 9999);           // 反則(文字列変数の最大長に依存)

    「変数の評価」が曲者で、マクロ中では(配列を使うなどして)変数の数が
    多くなる程個々の変数へのアクセスが遅くなる、という特徴があります。

    なので、 "strlen($s)" よりもその場で評価できる "9999" といった
    数値で「決め打ち」するという、行儀の悪いことになっていました。
--↑------------------------------------------------------------------------
-----------

perl の substr() の様なものです。(ネタでも構いませんので)ご検討をお願いし
ます。

[ ]
RE:03318 strstrの拡張 (midstr も)No.03328
秀丸担当 さん 09/08/25 13:08
 

>strstr() 関数に加えて、 midstr() 関数の第 3 引数を省略可にして
>
>    midstr($s, #i)  // $s の #i 文字目から後ろ全部
>
>と記述できると有難いのですが…

他の言語でも見られるsubstrでもそうなっているようなので、それができたら作
りやすいかもしれません。
strstrと合わせて検討したいと思います。

[ ]
RE:03328 strstrの拡張 (midstr も)No.03339
A1 さん 09/08/25 19:32
 
>strstrと合わせて検討したいと思います。

ありがとうございます。
早速 β8 を DL して試している所ですが、次のコードでエラーが起きました。(@Vis
ta32)

-↓- test.mac - (この3行のみ) -----------------------------
    $s = midstr("abc",0,3); // 通常の3引数の呼び出し  $s=="abc"
    $s = midstr("abc",2); // 2引数の呼び出し(1回目) $s=="c"
    $s = midstr("abc",2); // 2引数の呼び出し(2回目)
-↑--------------------------------------------------------

3引数呼び出し(?)を続けている限りは問題ないようなのですが、
2引数呼び出しを始めると、大体2回目でコケます(while ループ中でも同様)。
エラーメッセージは

    「文字列が指定されるべき所に文字列以外のものが指定されています。」

というものでした(「引数が不足」等とは言われませんでした)。

(再現が難しいですが)別のコードでは突然検索ダイアログが開いたりします(閉じ
た後でエラーメッセージが出る)。

 ------

駆け込みの要望にも素早く対応して頂き、改めて御礼申し上げます。

とりあえずご報告まで。

[ ]
RE:03339 strstrの拡張 (midstr も)No.03351
秀丸担当 さん 09/08/26 09:40
 

>ありがとうございます。
>早速 β8 を DL して試している所ですが、次のコードでエラーが起きました。(@Vis
>ta32)

すみません。その通りでした。
実装が不完全でした。
報告ありがとうございます。
β9でさらに修正させていただきます。

[ ]
RE:03351 strstrの拡張 (midstr も)No.03377
A1 さん 09/08/26 18:35
 
>β9でさらに修正させていただきます。
ありがとうございます。よろしくお願いします。

[ ]
RE:03182 strstrの拡張No.03388
colder さん 09/08/27 10:15
 
>
>>strstrですが、第3引数を追加して、検索開始位置を指定できないでしょうか?

strstrの第3引数に第1引数の文字列の長さ以上の値を指定すると、
「最初に一致する位置+第三引数の値」が返ってくるようです。
-1が返ってくるべきでないでしょうか?

環境:秀丸エディタv8.00β8

[ ]
RE:03388 strstrの拡張No.03390
colder さん 09/08/27 10:59
 
まだ、あった。
「strstr("表","\\",1)」のように検索開始位置を全角文字の2バイト目にすると、2
バイト目から検索されますが、
このような指定がされた場合は、次の文字から検索されるべきでないでしょうか?

[ ]
RE:03390 strstrの拡張No.03393
秀丸担当 さん 09/08/27 11:59
 

>strstrの第3引数に第1引数の文字列の長さ以上の値を指定すると、

>「strstr("表","\\",1)」のように検索開始位置を全角文字の2バイト目にすると、

ご指摘ありがとうございます。
どちらもそのほうがいいと思います。
β9でそのように修正させていただきます。

[ ]
RE:03393 strstrの拡張No.03394
Iranoan さん 09/08/27 12:08
 
 秀丸担当さん今日は、Iranoan です。
> >「strstr("表","\\",1)」のように検索開始位置を全角文字の2バイト目にすると、
<snip>
> β9でそのように修正させていただきます。
 こちらについては、strstr() 等は、全角半角の区別をしないで、バイト単
位なので、これで良いと思います。そうでないと他との統一性がなくなるし、
Shift_JIS に無いけど、欧文には有る文字など強引に検索しようとした時に困
る気がします。

[ ]
RE:03394 strstrの拡張No.03398
colder さん 09/08/27 13:28
 
> こちらについては、strstr() 等は、全角半角の区別をしないで、バイト単
>位なので、これで良いと思います。そうでないと他との統一性がなくなるし、
>Shift_JIS に無いけど、欧文には有る文字など強引に検索しようとした時に困
>る気がします。

はて?
こちらの環境では、文字単位のように動作しているんですけど。
何か動作環境の設定があるのでしょうか?

[ ]
RE:03398 strstrの拡張No.03399
Iranoan さん 09/08/27 15:55
 
 colder さん今日は、Iranoan です。
> > こちらについては、strstr() 等は、全角半角の区別をしないで、バイト単
> >位なので、これで良いと思います。そうでないと他との統一性がなくなるし、
> >Shift_JIS に無いけど、欧文には有る文字など強引に検索しようとした時に困
> >る気がします。
>
> はて?
> こちらの環境では、文字単位のように動作しているんですけど。
> 何か動作環境の設定があるのでしょうか?
 たぶん動作環境によらないと思うのですが、末尾の様な例です。
 現在の仕様なら、Shift_JIS の「ぢ」と重なる欧文の「,`A」(`は上付き)
の様な綴りから、「`A」が検索できます。
 そこで、仕様が変わると「検索できなくならないかな〜」と心配です。
//------------------------------------------------------------
message str( strstr( "\x82\xC0", "\xC0", 0 ) );
message str( strstr( "\x82\xC0", "\xC0", 1 ) );//バイトで切れば検索か

[ ]
RE:03399 strstrの拡張No.03400
秀丸担当 さん 09/08/27 16:13
 

midstrも全角の2バイト目から切れるようになっていて、それと同じ動きという
意味ではstrstrも2バイト目を見たほうがいいのかもしれないですが、そこまで
して維持する仕様か疑問もあります。
とりあえずβ9では2バイト目を無視するのは保留にしようと思います。

[ ]
RE:03399 strstrの拡張No.03405
colder さん 09/08/27 17:32
 
> たぶん動作環境によらないと思うのですが、末尾の様な例です。
> 現在の仕様なら、Shift_JIS の「ぢ」と重なる欧文の「,`A」(`は上付き)
>の様な綴りから、「`A」が検索できます。
> そこで、仕様が変わると「検索できなくならないかな〜」と心配です。
>//------------------------------------------------------------
>message str( strstr( "\x82\xC0", "\xC0", 0 ) );
>message str( strstr( "\x82\xC0", "\xC0", 1 ) );//バイトで切れば検索か

確認ですけど、strstrが1を返すのは後者の例だけですよね?
strstrが全角の1バイト目を無視して、2バイト目からの文字に一致する例は、
第3引数の指定があってかつその位置でマッチする場合のみです。
これを仕様としても、ほとんど有意義な使い方はできないんじゃないかな。

[ ]
RE:03405 strstrの拡張No.03408
Iranoan さん 09/08/27 17:53
 
 colder さん今日は、Iranoan です。
> 確認ですけど、strstrが1を返すのは後者の例だけですよね?
 はい。

> これを仕様としても、ほとんど有意義な使い方はできないんじゃないかな。
 それでも、今まで出来ていたことが出来なくなるのは、まずいと思います。

[ ]
RE:03408 strstrの拡張No.03409
colder さん 09/08/27 18:19
 
>> これを仕様としても、ほとんど有意義な使い方はできないんじゃないかな。
> それでも、今まで出来ていたことが出来なくなるのは、まずいと思います。
今までできていたといっても、β8以降だけですし、正式リリースされたものではな
いし、これを利用しているマクロがほとんど無いと思われる今ならバグ修正扱いで済
むかと思います。

これは、現在は1を返しますが、私的には2を返して欲しい。
message str( strstr( "ラ演", "演", 1 ) );

[ ]
RE:03409 strstrの拡張No.03412
Iranoan さん 09/08/27 19:16
 
 colder さん今日は、Iranoan です。
> >> これを仕様としても、ほとんど有意義な使い方はできないんじゃないかな。
> > それでも、今まで出来ていたことが出来なくなるのは、まずいと思います。
> 今までできていたといっても、β8以降だけです
 確かにそうですね(^^;。
 ただ他の left/right/midstr() が考慮しないのに、この関数だけ考慮する
のは、やはりおかしい気がします。かといってこちらは、変更すると正式版と
の上位互換性もなくなってしまいます。

[ ]
RE:03412 strstrの拡張No.03425
IKKI さん 09/08/27 23:25
 
こんにちは。ユーザの IKKI です。横から失礼します。

> > これは、現在は1を返しますが、私的には2を返して欲しい。
> > message str( strstr( "ラ演", "演", 1 ) );
これは明らかに 2 を返すべきだと思います。

>  ただ他の left/right/midstr() が考慮しないのに、この関数だけ考慮する
> のは、やはりおかしい気がします。
「切り出し位置」と「検索開始位置」は意味が異なるのではないでしょうか。
意味が異なるもの同士の整合性を考えることには意味がない気がします。

[ ]
RE:03412 strstrの拡張No.03426
あべのり さん 09/08/27 23:55
 
> ただ他の left/right/midstr() が考慮しないのに、この関数だけ考慮する
>のは、やはりおかしい気がします。かといってこちらは、変更すると正式版と
>の上位互換性もなくなってしまいます。
しかし今のままだと,
strstr("表","\\")
は-1を返すのに,
strstr("表","\\",1)
は1を返す,というので,これはこれでおかしい気もします.(最初から探しても見
つからなかったのが,途中から探したら見つかった.)

# ただ,自分にはこういう中途半端な指定を第三引数でする可能性が
# どのくらいあるのかわかっていませんが.

[ ]
RE:03425 strstrの拡張No.03427
Iranoan さん 09/08/27 23:59
 
 IKKI さん今日は、Iranoan です。
> > > これは、現在は1を返しますが、私的には2を返して欲しい。
> > > message str( strstr( "ラ演", "演", 1 ) );
> これは明らかに 2 を返すべきだと思います。
 そうかなあ。この状態で観るとそう思えるけど、見方を変えて
message str( strstr( "\x83\x89\x89\x89", "\x89\x89", 1 ) );
とするとどうでしょう? 欧文でもありえるんですよね。

> >  ただ他の left/right/midstr() が考慮しないのに、この関数だけ考慮する
> > のは、やはりおかしい気がします。
> 「切り出し位置」と「検索開始位置」は意味が異なるのではないでしょうか。
 単なる 0, 1 のストリームとしてみると、同じだと思うんですよ。

 まあ、それ程拘っている訳ではありませんので、どちらでも構わないのです。
ただ日本語での動作だけ考えると、デフォルトの言語が日本語ではない OS で
整合性が取れなくならないか? は心配です。

 最後の変更したとして、
message str( strrstr( "演宴演", "演", 3 ) );
はどうすると良いでしょう? 今のままで良い?
> 「strstr("表","\\",1)」のように検索開始位置を全角文字の2バイト目にすると、2
> バイト目から検索されますが、
> このような指定がされた場合は、次の文字から検索されるべきでないでしょうか?
と同一の考え方なら、4 を返す仕様もありですよね。それとも前の文字から検
索して、結果として今と同じ 0 を返す?

 P.S 後は皆さんに任せてフェード・アウトします。

[ ]
RE:03426 strstrの拡張No.03433
秀丸担当 さん 09/08/28 10:55
 

strstrの開始位置指定で全角2バイト目をどうするかということですが、総合的
に考えて、新しい関数ということもあり、2バイト目は無視するように修正しよ
うと思います。
β9では保留にしていましたが、β10で修正します。

[ ]
RE:03433 strstrの拡張No.03439
bouz さん 09/08/28 11:40
 
dbcsとascii混在してのstrstr関数の特性上、先頭の位置は結構重要で
strstr("ラ演", "演", 1 )
というのは、"ラ演"ではなくてもはや
strstr("演\x89", "演")+1
と等価という風に見えて、これはこれで自然だと思い、とここまで書いて
message str(strstr("\x83\x89\x89\x89", "\x89"));
とやってみたら2を返すのですね。知りませんでした。既に1個目の\x89はstrstrだ
けでは発見できない仕様だったのですね。だとしたら、
strstr("\x83\x89\x89\x89", "\x89", 1 )も合わせたほうが、違和感がないというこ
とになるのでしょうか。

[ ]