【PHP】下らねぇ質問はここに書き込みやがれ 15 (92ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
50(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:42:04.65 ID:MhxTwPG60(1/25) AAS
>>4949(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 1f74-3+vo) [sage] 2025/05/01(木) 09:10:43.14 ID:7ocNYzTh0(2/2) AAS
開発終了の理由は Oniguruma#349 です。 最後のコメントをご覧ください。
Oniguruma#351 は Oniguruma の fix_351_349 ブランチでのみ解決済です。
Oniguruma#351で解決した問題
github.com/kkos/oniguruma/issues/290#issuecomment-1805754012
Oniguruma#351で解決した問題の原因
github.com/kkos/oniguruma/issues/290#issuecomment-1825555154
個人的にはもしPHPが再び Oniguruma を取り込む場合は fix_351_349 ブランチ を取り込むことをおすすめします。
上記の通り、ユーザーを困らせる問題が１つ解消されるからです。
しかし、この修正は正規表現の仕様変更です。正規表現の動作が変わってしまいます。
しかしその影響を受けるケースはごくわずかであり、ほとんどのユーザーにとっては不可思議なエラーが
出なくなることのほうが重要だと思います。
------------
PHP で ONIG_SYNTAX_ONIGURUMA を使えるようにする方法。このスレの(*SKIP)の話のまとめです。
github.com/tonco-miyazawa/PHP_syntax_oniguruma
現在の PHP では ONIG_SYNTAX_ONIGURUMA を選択出来ません。
お疲れ。#290,#350,#351は読んだ。
相変わらず君はまともだね。正しく議論も出来ているし。
昨今の馬鹿ばかり無限に湧いてくる5chに辟易してる俺にはかなりの驚きだ。
(ただしこれは誰が悪いというわけではなく、俺が今更「永遠の９月」を追体験してるだけではあるが。
参考: 外部ﾘﾝｸ:ja.wikipedia.org永遠の9月)
51: デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:43:10.74 ID:MhxTwPG60(2/25) AAS
> 個人的にはもしPHPが再び Oniguruma を取り込む場合は fix_351_349 ブランチ を取り込むことをおすすめします。
PHPは互換重視、というより、互換絶対、だ。だから厳しいだろう。
(いうて最近はコンテナにぶち込んでさようなら、というのもありのようなので、
互換性の問題を仮想化で解決したとも言え、問題ないのかもしれんが)
界隈の状況全く知らんが、普通に考えて、
・特に問題ない場合(＝互換性が保たれている場合)、最新リリースを取り込む
・最新リリースでbreaking changeされており、互換性を保ったリリースの提供が今後もされない見込みの場合、
・しばらくは現行バージョンを使い続ける
・メンテ可能であればフォークしてPHP専用onigurumaにしてしまう
・諦めて別エンジンに乗り換える
の順だと思う。
52: デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:44:00.03 ID:MhxTwPG60(3/25) AAS
(実際どうなのかは確認してないが)、一番可能性のあるパターンは、
fix_351_349は一時的な解決策として動作確認の為のリリースであり、
問題なければ、最終的に正式ブランチに「何らかの動作モードで切り替えられる」形式でマージされる。(例: (外部ﾘﾝｸ:github.com 内 \U)
そしてPHPは php_mbstring.c 内でそれを互換モード(＝非fix_351_349モード)に固定して取り込む、といったところか。
だから君はこうなるよう、つまり、
・fix_351_349が希望通りの動作をすることをを確かめ、
・正式ブランチに何らかのフラグで切り替えられる形式でマージされ、
・自分の php_mbstring.c 内でそれをfix_351_349に固定してしまうか、
PHP側からフラグ与えられるように書き換え、プルリク出す
方向で行動すればいい。
(あるいはコンテナがあるから最早互換性なんて必要ないです！！！というキャンペーンもありなのか？)
ただ
> I would consider changing the spec to not match different number of characters with flag i.
なのは下手すると今後は互換バージョンは提供されないのか？
なら前述のとおり、しばらく様子見され、その後は不明だね。
(後述するが、現時点ではこの判断は間違いのように見える)
53: デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:44:31.05 ID:MhxTwPG60(4/25) AAS
…と思っていたが、昨日mergeしたのか？
(まあ実は俺はGitHubはほぼ使ってないのでissueのアイコン見ても何が何だか分からないのだが)
breaking change したのなら、決定が拙速すぎる気はする。
少なくともユーザー界隈、つまりPHP,Ruby,VSCode界隈に打診して反応聞いたほうが良い気が。
まあこれからフラグ付加すりゃいいだけという話かもしれんが。
54: デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:45:11.55 ID:MhxTwPG60(5/25) AAS
breaking changeは結局、
・これまで書いたコード
・これから書くコード
のどちらを優先するか、でしかない。
ちなみにRubyが死んだのはこの辺の判断を間違ったためだと思ってる。
2012年のRubyカンファレンスだか何かで、
・互換性を重視してこの仕様にしました！！！ ← ウォー！！！
とか盛り上がってたらしいが、そりゃそこに居る連中は「既に書いてる」奴だから、互換重視の方がウケるのは当たり前。
存続するためには「ご新規さん」を取り込むことが必要で、
当然彼らに魅力的なよう、くだらない仕様は修正していく必要がある。
丁度この時期にRuby界隈でそこそこ頑張ってたやつがイマイチな仕様を修正しようとしてて、(確か%sだったか)
結果的に互換重視の決定となり、「俺の影響力なんて皆無だと知ったぜ…」てなボヤキをしてた。
単純には、breaking change は既存ユーザーを減らし、新規ユーザーを増やす方向に圧力がかかるので、
界隈の状況を見つつ、結果的にユーザー総数が増える方向に舵切りするのが正しい。
だから言語の前半期(成長期)はbreaking change を恐れず積極的に問題を修正し、
後半期(安定期)には互換性重視で既存コードを守るべきで、
つまりこの意味ではRubyは2012年に後半期に入る宣言したとも言え、実際その辺からだだ下がりで現在がある。
してPHPは、というと、どう考えても既に後半期に入っている。
だから互換性は絶対で、それ以前にそもそもONIGURUMAモードすら使えてないし、おそらく今後ともしばらく使えないのでは？
これには後述するが、PCRE程度でいいや、という考えもあるのではないかと思う。
55: デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:46:06.00 ID:MhxTwPG60(6/25) AAS
ついでに、前回結果的に投稿しなかった内容も書いておく。
(というか、中途半端には書いたが、全部書ききるのが面倒で、とりあえず結果も出たようだし、まあいいか、になってしまった)
PHPではなくほぼ正規表現とonigurumaの話なので、PHPにしか興味ない人は読む必要はない。
以後続くようならスレは移動してもいい。
俺はIP表示がなければどこでも可(ワッチョイも問題なし)なので、
別スレに落とされたレスがあれば、それに対するレスはそこに落とす。
56: デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:46:41.16 ID:MhxTwPG60(7/25) AAS
>>2929(1): 前スレ 947 (ﾜｯﾁｮｲ 6274-erF6) [sage] 2024/11/09(土) 01:35:17.88 ID:k7Zpjetb0(1) AAS
NGスレ06 にお返事を書いてましたが連投規制なのか続きを書けなくなりました
agree.5ch.net/test/read.cgi/mango/1715675838/334-n
書けない間についに問題の核心部分を突き止められました！
原因は oniguruma で廃止された onig_init(); を php_mbregex.c で使っていたことでした
github.com/php/php-src/blob/84400eefbb6f09ca7de971f49a86ab26520dfff3/ext/mbstring/php_mbregex.c#L115
PHPを知らない私は PHP_MINIT_FUNCTION(mb_regex) の MINI の部分を見て
「これはバージョン番号が小さい(=古い) oniguruma を使うときのものだな、きっと」
と思ってしまったのが大間違いでした。ググったところ、この関数は
「モジュールがロードされたときに最初に呼び出される関数」だそうです.....(T_T)
ということで新しい初期化関数の onig_initialize() を使った書き方に直したところ、
(*FAIL) や (*SKIP) がPHP上で正常に動作しました
onig_initialize() ※ これは引数が２つ必要なので注意です
github.com/kkos/oniguruma/blob/f6723fd940b993b39b1535f71c8695867a5e92d1/doc/API.ja#L6
onig_initialize() 周りのコ-ドは oniguruma/sample/callout.c からそのままコピペしました
github.com/kkos/oniguruma/blob/f6723fd940b993b39b1535f71c8695867a5e92d1/sample/callout.c#L189
こんなことで2週間もスレを占領してしまってすみませんでした..
超優秀な方には感謝感謝です、他の方もありがとうございました！ とても勉強になりました！
良かったら>>23 さんにも教えてあげて下さい、がんばれ23さん！！！
解決したのはすごいよ。
普通はたどり着けないからね。ラッキーでど命中したというのはあるが、それにしても、だ。
> 速度面での恩恵が大きい (2chｽﾚ:mango
正規表現にもよるが、'/....ABC/'とか書きたければそうね。
(俺の理解が正しければ)O(n^2)が(*FAIL)でO(1)になるのだから爆速だ。
ただ現在は、こういう「頭が決まらない(＝頭が何でもマッチする)正規表現はバックトラックが激しく発生するので駄目、
後読み/(?<=/等使って頑張れ、となってるが、これらについて、つまり正規表現エンジンの進化の方向としては、
α. バックトラックを正しく理解した上で、制御しきる。（＝ホワイトボックス化)
この為に(*FAIL)や++等追加する。
β. 単純に速い正規表現エンジンとする。バックトラックの理解はしなくていい。（＝ブラックボックス化)
ただし内部的な最適化を限界まで行うので、動作の曖昧さが残る。結果、
> /^(?>s|ss)$/ does not match "ss". (外部ﾘﾝｸ:github.com
等はバージョンによって動作が異なるので、現実的に使えない。
つまり、頭から検索する前提でバックトラック制御等を行っている正規表現は動作の保証が出来ない。(＝仕様として追加できない)
言い換えれば、現在onigurumaで導入してる ?> 等は永久に使えない。
の2つの方向があって、見る限り、onigurumaは明らかにα方向だ。
ただ俺は、βが正解だと思ってるんだな。αはMatzの言う「実装が仕様にはみ出している」から。
つまり、今回も、あるいはバックトラックの理解/制御が必要なのも、「遅い」からであって、
十分速ければこの必要もないし、ユーザーもバックトラックなんて理解したいわけではなく、正規表現を使いたいだけだから、と考える。
富豪プログラミング万歳！！！ってところだ。
57(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:47:46.13 ID:MhxTwPG60(8/25) AAS
とはいえ、現実的に無理だからαという判断なのだと思うし、実際この方向の需要も確実にあるのも事実。
例えば
A. preg_match('/OK|NG/', ... よりも、
B. if ($str[i]==='O' && $str[i+1]==='K' || $str[i]==='N' && $str[i+1]==='G') ...
の方が(PHPでは微妙だが、少なくともCでは)速いのは確実だが、
正規表現の方が読みやすさが格段に上なので、if文だと将来的にメンテコストが上がる。
(この辺しょうもないと思うかもしれないが、Aだと見た瞬間理解《所要0.5秒》に対し、
Bだと読まないと理解できないので《所要5秒》、長期的に大規模なコードをメンテする場合はかなり問題になる。
まあこの例だと簡単すぎてイマイチだが、もっと複雑な文字列検索をif文で書くとだいぶ酷いことになる)
この為、if文記述が最速と分かっていても、正規表現『的な』、見た瞬間分かる記述で書きたい需要はある。
そしてこれをオレオレライブラリ化しても、仕様自体は正規表現的なものになってしまうので、
なら、正規表現の仕様として追加し、正規表現エンジンにやらせる、というのは、非常にもっともな解ではある。
そしてこの方向を向いているのがonigurumaではある。
58: デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:48:44.34 ID:MhxTwPG60(9/25) AAS
ただし俺として最高なのは、Aのソース記述をコンパイル段階でBにして最速化する、であって、
つまり全自動での最適化を望んでる。手動で手間かけてまでやりたくない。
この場合に必要なのは「明示的な『任意の最適化の許可』フラグ」だ。
これはつまり、現在 retry-limit-in-match over 等で落ちてる正規表現に対し、
「任意の最適化の許可」フラグを付ければ、「通る『事がある』」という、なんとも微妙な方向で、
制御して確実に動作させきるという、αな「正道派」からすると許容できない仕様ではある。
ただ俺は「結果が正しく、十分速ければ、何も問題ない」という、大半の、βな「ライトユーザー」的な発想であり、
バックトラックの制御なんてしたいとは全く思ってない。
ただし、問題になる箇所が後々でもすぐ分かるように、「明示的に」フラグを付ける。
結果、以後はそのフラグが付いた正規表現だけを気にしていればいい、それ以外は確実に動く、といった所。
(フラグが付いてないところはこれまでどおりの仕様で動く。
つまり、現行の動作で retry-limit-in-match over 等で落ちず、今後とも互換で同様なら、同様に落ちないことが保証される)
ある意味、「現在」確実に動かすよりも、「将来」的にメンテナンス性を上げることを優先してる。
これは上記のif文と同様、バックトラック制御を駆使して事細かに書いてる正規表現は、
単純な正規表現と比べて読むのに時間がかかるので、
バックトラック制御を追加したら同様の結果を速く得られると分かっていても、
特に問題ない箇所はできるだけ単純な記述を使うべき、とする考えになる。
《ちなみに逆の考え方は、バックトラック制御等が付加されてる程度の正規表現は一瞬で読めるように鍛えろ、となる。
あるいはBのif文記述の読み込み速度を上げろ、もありか》)
59: デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:49:28.23 ID:MhxTwPG60(10/25) AAS
そして一般的には、プログラマはα方向、非プログラマはβ方向を好む。
これは、プログラマは論理的理解をしてでも確実に制御しきりたいのと、
そもそもプログラマはソースコード内に記述して使うことが大前提のため、
読む回数>>>書く回数、というか、読むことに費やす時間>>>書くことに費やす時間、となるから。
だから、プログラマにとっては、多少冗長でも、すぐ読める記述のほうが好まれる。
逆に非プログラマは、まあ俺の偏見でもあるのだろうが、例えば昔に5chの正規表現スレにも書き込んだことがあるが、
かなりアウェイ感、というか、見解の相違を感じた。
どうやら連中はブラウザや蔵書検索エンジン等の「検索窓」で正規表現を使うことが主目的らしく、
基本的に正規表現はその場で使い捨て、つまり、書く時間>>>読む時間、なのだな。
だから、凄まじく記号化して、結果的に1文字でもタイプ数を減らす方を好むようだ。
等々、色々な点で大前提が違うので、プログラム板以外ではだいたい俺はアウェイで、
色々酷いことになってるが、まあそれも含めて楽しんでる。
そして上記の5chの正規表現スレ、どうやらonigurumaの連中の巣窟だったようで、
当然のごとくPCREと覇権争いをしてて勝つのはonigurumaだ、みたいな奴らだった。
俺的には、速く動けば何でもいいので、勝手にやってろ糞ウゼーとしか感じず、
よって、俺はそもそもoniguruma連中にいい感情を持ってない。
まあこれは君がここで質問するだいぶ前の事だが。
60: デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:50:11.38 ID:MhxTwPG60(11/25) AAS
とはいえ、VSCodeにもonigurumaが入ってるらしいので、連中が順調に成長してるのは事実だ。
もしかするとRuby以上にいい線行ってるかも、とも思う。
とはいえ、αの方向はどうなの？とはかなり疑問ではある。
現行の先読み/後読み等もそれなりにややこしいので、
そもそも論理的理解力が乏しい非プログラマ連中にはかなり向いてない。
結果、現在もいるであろう、「正規表現だけしか出来ない馬鹿」を余計にのさばらせるだけではある。
61(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:50:33.88 ID:MhxTwPG60(12/25) AAS
まあこれに関しては余談になるが、
ずいぶん昔にコメントアウトの /* */ を正規表現で削除する処理する、というブログページがあって、(とはいえ今検索しても出てこないんだが)
曰く、単純に preg_replace するだけでは、内部に任意のコメントを書かれたときに対応出来ない、
だからコメントとしてこういう文字列を書かれた場合に対応するためにこう、そしてこう、、、、と続き、
最終的にこれだ！！！これで何をコメントされても完璧に動く！！！
というのがあって、この程度書けないようなやつは困る(ｷﾘｯ、みたいな締めになっていたが、
うむ、なるほど、俺には読めんな、とは思った。(結果忘れてここに書けないのはすまん)
しかしこれ、そもそもコメント /* */ なんて正規表現以前の時代の産物で、
当然その時代のコンパイラでも問題なく処理できる仕様となっており、
実際、whileとif文でなら(面倒ではあるが)馬鹿みたいに簡単に書ける。
だから、プログラマには「whileとif文で書く」というオプションがあり、
(あるいは、被検索文字列を前処理したり、正規表現処理を複数回に分けたり等の、プログラムを書く事も可能)
結果的に正規表現を極めきる必要はなく、
世間と同程度の正規表現を読み書き出来ればまあ問題ない。
この点、「検索窓」ではどうにもならないので、非プログラマは何がなんでも「正規表現で一撃で済ませる」必要があり、
結果的に正規表現を極める奴が出てきて、
そいつらからすると俺らプログラマはなんとも中途半端な理解に見えるようだ。
62: デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:51:02.34 ID:MhxTwPG60(13/25) AAS
結果、「プログラマ」連中は、ソースコードに書かれてる程度の正規表現は読める必要があるが、
過度な正規表現は他のプログラマが読めないので禁止であり、中庸の正規表現の使用に落ち着く。(これがPCRE程度、というのが多分一つの目安)
非プログラマ連中は、極めた「匠」となり、なんでも正規表現でやり切るか、
「正規表現書けるの？すごーい！！！」程度の「ウルトラライト」に二極化する。(勿論断然多いのは後者)
なので、α方向は実際どうなのよ？はかなり疑問である。
現実的に現在のPCREな正規表現だと色々足りてないのは事実だが、
onigurumaなバックトラック制御を今後もてんこ盛りな方向だと、
結局読みにくい(＝読むのに数十秒かかる)正規表現になってしまう気もする。
プログラマ的には、正規表現と、if文と、読みやすい方を選べばいいだけではあるので、使わなければいい、ではあるが。
ただ件のスレのoniguruma連中は、「匠」なので、α一択なのだろうけど。
俺としては、つべこべ言わず動けばいいだけなので、問題になってる正規表現にだけ明示的に「任意の最適化の許可」付けて、
結果的に動作し、バックトラック制御なんてしなくて済むほうが助かるが。
63(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:51:33.26 ID:MhxTwPG60(14/25) AAS
さて読んでて思ったのだが、これ、仕様が矛盾してて、現実的に実装できない可能性も有るのでは？
これは当人も気づいてて言及してるが、実際に矛盾してるかどうかまでは分からないようだ。
> JS also ensures that /\w/iu is the inverse of /\W/iu. (外部ﾘﾝｸ:github.com
俺も考えてみたが、よく分からん。
単純には、[\w]!==[^\W]でどうにも実装できないケースがあれば、
どのみちいつか breaking change するしか無いので、後腐れなく出来るのだが。
ところで同様の問題は、多分「濁点」にもある。
(この板がunicode許可してるかは知らんので以下見た目意味不明になるかもだが)
Unicodeには、結合文字用濁点(0x3099)があるので、「あ゙」とかも出来る。(表示系が対応してれば前の字と重ねて表示され、あに濁点がつく)
よって、「が(0x304c)」と「が(0x304b,0x3099)」は見た目区別がつかない。
(0x304b,0x3099を表示するのに、通常は、単純にビットマップを重ねるわけではなく、0x304cのフォントが使用されるから)
おそらくこの辺もonigurumaは対策されてるのではないかと思う。
正直、これはヒットしてくれたほうが助かるのは事実。
というかね、ブラウザ(Ctrl+F)ではヒットするが、JSではヒットしないので、
見た目表示されてるのにJSから検索すると存在せず、あれ？ってなったことがあった。
だから見た目、現行の動作は、「仕様的に正しい」。
これは本当に重要で、先日も言ったが、仕様を追加するのはいつでも楽勝だが、削除するのは基本的に無理なので、
おかしな仕様を追加した時点で将来的に詰むのが確約されるから、これは全力で回避しなければならない。
現行の動作は、確かに正しい。
問題は、その場合に異常に遅くなるケースがある、ということであって、
本来は、仕様変更ではなく、速度対策『だけ』で済ませるべき状況であり、実際に高速化すれば何も問題なくなるはず。
とはいえ高速化はもう出来ません、ということなのだろうが、果たしてそうなのか？とは思う。
64(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:51:59.95 ID:MhxTwPG60(15/25) AAS
例えば典型的な糞ッタレ正規表現、
> a.*b.*c.*d.*e // --- (a)
についてだが、
> a.*+b.*+c.*+d.*+e // --- (b)
は確かに一つの解だろう。しかしこれは、最速ではない。
人間がやるときを考えれば分かるが、
$len = strlen($str); // ---(c)
$e = strrpos($str,'e'); // 最後のe
$d = strrpos($str,'d',$e-$len); // eより前の最後のd
$c = strrpos($str,'c',$d-$len); // dより前の最後のc
$b = strrpos($str,'b',$c-$len); // cより前の最後のb
$a = strpos($str,'a',$b-$len); // 最初のa
if ($a<$b) // check
と後ろから検索するのが速く、正規表現にすると
/(?<=(a.*))(?<=b.*?)(?<=c.*?)(?<=d.*?)(?<=e(.*?))$/ --- (d)
となる。が、まあ、(d)だと得られる結果が微妙に異なってしまうので後処理必要だが、(というより同じ結果を得られる正規表現を書けなかったorz)
内部的に自動的にこの方向で高速化してくれ、となる。
単純には、greedyに対してnon-greedyで右から検索すれば多分最速になる。
この辺、バックトラックの指定を事細かく出来る＝走査順が仕様として規定されてしまう＝左から右に走査、となってしまってるのが問題なので、
「任意の最適化の許可」フラグで、右から左に走査することも許可し、(勿論それ以外にもやっていい)
結果的にクソ速いがバックトラック制御は出来ませんよ、が正しい気がする。
(フラグ指定した場合、どう走査されるかはエンジン任せで、
結果的にバックトラック制御を指定してもどう動くか予想できず、実質使えなくなる。
が、問題は速度が遅いことであり、バックトラック制御をするのが目的ではないのでこれでいいはず)
65(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:52:39.44 ID:MhxTwPG60(16/25) AAS
ちょっと伝わりにくいだろうからもう一度書いておくと、俺の希望としては、
プログラマがコードとして書くのは(a)で、
これを内部的に(c)で処理して最速化しろ、
処理順だけ書けば(d)になるが、この正規表現では読むのに時間がかかる(所要30秒)ので無理、
「匠」は(b)を書くが、これは(a)よりは理解に時間がかかる(所要10秒)し実行速度も最速ではない。
「プログラマ」は(a)で無理なら最速の(c)プログラムを書くが、
(a)は2秒で理解出来るのに対して、
(c)見て(a)と理解するには1分かかるので、前述のとおり、これをプログラム全域にまぶすと後々詰む。
最低限、(c)の先頭行に、// /a.*b.*c.*d.*e/ を高速化した とコメントがないと死ねる。
しかし結局、(a)の処理が速ければ最初から何も問題ないので、目指す仕様はここで、内部的に頑張ってくれ、という事。
ユーザーに「匠」となり、最適な正規表現を精巧に作り上げることを要求するのではなくてね。
(だから仕様追加するなら「後ろから検索」フラグ、でもいい。
そして /e.*?d.*?c.*?b.?a/Backwards で(a)と同様の結果が得られるとかでも)
66(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:53:03.02 ID:MhxTwPG60(17/25) AAS
とにかく、ユーザーが困っているのは「仕様」ではなく「実行速度」なのだから、
それを「仕様」の限定化(仕様縮小＝スペックダウン)で回避するのは悪手であり、まず高速化をやるのが先だ。
あるいは \U のように、unicode対策を外すフラグ付加（＝フラグ付加時のみ仕様縮小での高速化)で対応できる。
kkos氏はこの仕様が実行速度に多大な影響を及ぼしているのを知っており、元々外したいと思ってたのだろうがね。
しかし、この状況で「仕様」を変更するのは、一般論としては明確な間違いだ。
何度も言ってるが、今の仕様は正しいので。
(とはいえ、結局この辺の采配、つまり理想と現実の兼ね合いでどう仕様を決めていくかが最終的な繁栄/衰退につながるので、
勿論kkos氏が決めるべきだし、実際、この仕様を捨てたら爆速化して更に支持率ダダ上がり、の可能性もある。
まあこの辺の采配を間違えたのがRubyと見てるが、onigurumaは果たしてどうなるか、といった所)
67: デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:53:24.95 ID:MhxTwPG60(18/25) AAS
> Therefore, choices for elements other than the character class are generated after the character class.
ちなみにこの意味が分からない。(が、#350にもそのまま転載されてるから彼らの中では通じてるのだとは思う)
これって具体的にどういう意味か分かる？
/(?i)[\S]/ を
/(?-i)(?:s|t|st|ss)/ ではなく、
/(?-i)(?:ss|st|s|t)/ (greedyなので長いほうが先、ついでにアルファベット順でssの方が先)
と見なす(に近い)ということか？
以下 外部ﾘﾝｸ:github.com 内について
> [r`(?i)^[\w]$`, 'ss'], // ✅
> [r`(?i)^[^\W]$`, 'ss'], // ❌ ← むしろこれがアウトだろ、疑問マーク付いてないが
>
> // The negation rule is about negation of the outermost class, only 🤔 ← この解釈が間違いで、
> [r`(?i)^[[^\W]]$`, 'ss'], // ✅ 🤯 ← これと
> [r`(?i)^[\w&&[^\W]]$`, 'ss'], // ✅ 🤯 ← これには俺は問題を感じない
> // In the reverse direction with quantifiers; nothing surprising here ← いや、
> [r`(?i)^s{2}$`, 'ß'], // ❌ ← これはヒットするべきでは？
と思うが、まあこの辺は互換性もあり、なかなか変更できないのだとは思う。
68: デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:54:13.31 ID:MhxTwPG60(19/25) AAS
以降は前回の話について
(途中まで書いてたのに付け足してるので時系列的にちぐはぐかもだが。
あと若干、何まで書いたのか忘れてるので、重複も有るかも？)
> 名前が見つからずにエラーになる原因は oniguruma に "FAIL" や
> "SKIP" などが登録される前に callout_name_find されているのが原因でした
つまりonigurumaの「登録」(初期化ルーチン)と「検索」(phpのmb_ereg_replace)が
レーシングしていて(通常「競合」と訳されてるようだが、個人的には「競争」と訳すべきだと思っている)
fprintfのおかげで偶々運良く上手く行く方向に変わったわけだ。
(まあ一般的にレーシングの場合は再現性が低い＝ちょっと条件を変えたらすぐ収まってしまうので、こういうこともよくある。後述)
69: デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:54:36.67 ID:MhxTwPG60(20/25) AAS
> C言語のことを知りたいなら本なりで基礎から学ばないとダメですね
そうだが、実際の所、何となく読めるはず。
理由は簡単で、C言語は現在のメジャー言語全部の下敷きになっており、
文法はメジャー言語から見ればスモールセットでしかないから。
実際学んでも、ifとforとwhileだけですかー、と何も無さ過ぎてビビるはず。
ただしポインタを生で使える点だけが違う。
(とはいえphpでも全容を把握する為にはポインタの理解はある程度必要なので、
逆に言えばphpを完全理解してるのなら《知識的な》修得自体は容易。
phpで言うと、配列を「値渡し」して関数内で変更しても、元の配列は変更されないので、
変更したい場合は「参照渡し」しなさい、となってるが、その辺)
C言語は基本的に一対一でアセンブラに落ちるので、高級アセンブラのようなものではある。
だからC言語はCPUの動作そのものに近く、プログラミングにおいてはベースの前提知識として役立つ。
結果、どの言語を学ぶにしても見通しがよくなり、修得が早くなる。
だから職業プログラマを目指すなら、できるだけ早い段階でやっておいた方がいいし、
実際、大学のCS系では今でも1年生の時期にやってるはず。
何だかんだでベースの前提知識として役立つ。
70: デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:55:17.31 ID:MhxTwPG60(21/25) AAS
というのを11月に思ってたのだが、(特定する気もないので該当するかどうかを答える必要はないが)
もし君が学生で、職業プログラマを目指しているのなら、今すぐにでもCをやるべきだ。
理由は上記のとおり、上達速度が上がるから。
なんかね、君の「知識/経験」と「能力/実力」のアンバランスさが異常で、正直俺は遭遇した事がないレベル。
「やってみたら出来ちゃった」的に話が進んで行ってるのが異常で、
普通は知らない言語の時点で諦めるし、勿論環境も立ち上げない。
こういうの無視して闇雲に突撃したところで成果も出ない。
ある程度年取って「分別のある」プログラマなら、この辺知ってるから、突撃もしない。
だから無鉄砲に突っ込んで結果まで出してるのはかなりありえない展開で、
俺が思いつくのは、あまりにも若すぎて、自分の実力を認識できてない、とかだね。
まあスポーツ選手にしろアーティストにしろ20代そこそこで世界に駆け上がっていくので、
本当に実力のある若者はこんなものなのかな？程度に思ってる。
君は俺のアシストが効いたと思ってるのだろうが、そうじゃない、それは明らかに君の実力だ。
確かに今回はラッキーもあったが、GitHubでまともに議論参加できてるし、実力の片鱗は見えまくり、といった所。
71: デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:55:29.47 ID:MhxTwPG60(22/25) AAS
ただし、C言語の「理解」が目的で、C言語を「極める」必要はないことに留意すること。
C言語が50年も現役で居続けられるのは仕様/構成が素晴らしいからであり、この理由を理解するのは重要だが、
今C言語を書く必要がなければ、達人である必要はなく、当然書ける必要もない、
というか、Cにも問題が多々あったから、Cをベースとして他言語が発達してて、
つまりCの駄目なところは他言語使えばだいたい解決してる。だからCを書くこと自体に苦労する必要はない。
ただし、どういう思想でどういうコードを要求してる言語なのかを理解することは本当に重要。
まあこれでは分かりにくいので一つ例を上げると、「ポインタ」になる。
「ポインタ」の概念を理解できてて、他言語でも、ああこれは「ポインタ」だね、と分かることはかなり重要。
ただし、「ポインタ」を使いこなして、素晴らしいCコードを書ける必要はない、という事。
まあ「ポインタ」はよく言われるけど、その他も、例えば変数のライフタイムとかうまく出来ており、
Cの仕様は、「確かにこれしかない」と思えるものなので、無駄のないコードをどう書くかの参考にはかなりなる。
72: デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:56:10.52 ID:MhxTwPG60(23/25) AAS
さて話を戻すと、onigurumaはC界隈でもあまりやってはいけないとされている「マクロ芸」をやってる。
だからCマクロを知らないと読めないが、これはoniguruma側の問題だ。
(なおC++ではCの問題はCマクロで色々誤魔化せる事だとし、
Cマクロが使われる状況毎にC++文法を用意し、これを使う事でCマクロの除去を目指している。
だからC++ではCマクロは禁忌とされてる。
《と言っても『当初の』C++は、で、その後明後日の方向に暴走してたが》)
Cマクロは「ソースコードを直接書き換える」ので強力だが、結果、
「プログラマが見てるコード」とコンパイラで「実際に使用されるコード」が異なる事が大問題だとされてる。
なので、注意喚起、つまり、
「お前が今見てるコードと実際使われるコードは『別物だ』」と
『見た瞬間』分かるように全部大文字で書け、とされている。
だから小文字マクロは可読性の意味では完全にアウト。
(といってもLinuxコードには使われまくってるのだが、
あれはこういう決まり事が出来る前の産物だし、
また、小文字マクロでも可読性を損なってないのも凄いのだが)
73: デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:56:36.96 ID:MhxTwPG60(24/25) AAS
onigurumaで小文字マクロが大量に使われてるのは、おそらく大改修中だからだ。
全部大文字マクロに変更して変更箇所が膨大になるよりは、小文字のままで行ったほうが混乱しないと踏んだのだろう。
そして今回は初期化ルーチンのレーシングだが、こうなったのは仕様が変更されたから。
単体のonigurumaの使い方は分からんが、PHPで言うと、
当初：CGIで、毎回PHPを起動しては全部捨てる(各PHP毎にonig_initを呼ぶ)
今：モジュールで、一度PHPを起動したら常駐(初回にonig_initializeを呼んで以降は呼ばない)
レーシングしてたのは改修中で整合性取れてなかったのか、単に変更忘れててバグってたか知らんが。
そして条件を変えたら直ってしまった、というのは運だが、そこから追跡して原因まで到達してるのだから順当に実力だ。
ただもっと運が良ければ、例えばlaravelとか使ってたら、最初から動いていたかもだが。
つまり、レーシング自体はかなり微妙な場合も多い為、
mb_xxxxを呼ぶ前にlaravelのコードを大量に処理すると、これだけで動く方に倒れてたかもしれない、ということ。
ただこの場合、再現性が低くなり、（＝俺の環境では問題ないが続出、あるいはlaravelのバージョン毎に出たり出なかったり)
デバッグには相当手こずるので、
まあ状況不明だが、デバッグ出来たのは、kkos氏にとっても意味はかなり大きいとは思う。
後は、上記の通りCGI環境でやってれば、onig_initで問題なく、最初から動いていた可能性もある。
(まあここら辺は運だが)
74: デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:57:49.64 ID:MhxTwPG60(25/25) AAS
あとちなみに、(*FAIL)が辞書にない＝(*FAIL)も辞書登録する、ということであって、
つまりonigurumaは(*FAIL)もユーザーが動作を上書きできるようにしてる。
普通はこの辺はリテラルで与えるので、登録されてねえ…ってことには構造的にならないんだけどね。
まあこの辺はkkos氏のポリシーなんだろう。
てな感じ。まあぶっちゃけだいぶ忘れちゃってるのを色々覚えで書いてるし、どこまで投稿したかも忘れてるので、
重複があったり、間違ってたらごめん。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.024s