最終更新: 2010-01-15T21:20+0900
読みやすくも正確にも書けないのでリンクだけ。
サクラエディタの肥大化する一方の CEditView(描画、ダイアログの表示、文字列検索、単語判定、URL判定、ドラッグアンドドロップ対応、などなどなんでもござれ)を機能ごとに分割したいなあ、と考えていて、モデルとして想定していたのが Rubyの Enumerableモジュールのミックスイン。Enumerableを ミックスイン(include)するクラスが eachメソッドを提供するだけで、およそシーケンシャルアクセス可能なコレクションに対して行いたい操作(max, min, find, map,...)のすべてが可能になるという仕組み。
C++でやるにはどうするのかな、と想像していたときに「これってあれじゃね？」と結びついたのが「奇妙に再帰したテンプレートパターン(CRTP)」。このパターンは「[単行本（ソフトカバー）] ビョルン・カールソン【Boost C++をチューンアップする最先端ライブラリ】 ピアソンエデュケーション」で仕入れた。
仮に Enumerableモジュールのようなものをこのパターンで実現できたとして、その Enumerableテンプレート(eachメソッドが定義されたクラスをテンプレートパラメータとして受け取る)が配列っぽいあれやこれやのクラスにミックスイン(継承)されたらオブジェクトファイルがすごく肥大化しそうだという気がする。
純粋仮想関数にした eachに依存する形で Enumerableの各メソッドを実装すれば、テンプレートを使ったときと違って実装の共有ができるだろうか。
というようなことを想像してるだけ。
eachが yieldする型は何になるんだ？(C++で yieldなんてできないという話はおいておいて) 結局、型安全性を求めたらテンプレートになって、型ごとに実装(テンプレートのインスタンス)が作られるんじゃないか。
と、ここで boost::anyを使ってはどうか。Enumerableのメソッドの実装は要素の型に依存しないから anyのまま扱う。Enumerableのメソッドを呼び出す側が要素の型を知っているから anyから正しい型のオブジェクトを取り出せる。
と思ったら、「Enumerableのメソッドの実装は要素の型に依存しない」は嘘だ。比較できないと最大値や最小値が求まらん。Enumerableがコレクションに対して求めてるのは eachだけだけど、その要素に対しては比較できることや加算できることなど、いろいろ要求している。これじゃあテンプレートでないとやってられない。
いやいやいや、min, maxをはじめ Enumerableのほとんどのメソッドは要素を引数にとるブロックを受け付けて、その結果を基に処理を行っている。ブロックのコンテキストは Enumerableのメソッドを呼び出す側だから要素の型を知っている。やっぱり Enumerableの実装は要素の型を知らなくてもいい。
ブロックの代わりになるのは関数オブジェクトか traitsかな。
とまあ、かように面倒くさそうなことになるから CEditViewクラスになんでも突っ込む結果になるのも当然。言語の不備だ、とか言ってみる。
あるクラス(CEditDoc, CEditView)にいろいろな特性(検索可能性、ドラッグアンドドロップ可能性、範囲選択可能性、……)を、簡単にクラス外から付加する確立した手順が必要。……と、あくまで想像するだけ。
それに分割してしまうと機能間での連携(依存ともいう)に苦労することになるのが目に見えている。ANSI版の CEditViewはなんでも一カ所につっこめる限界点を超えているとは思うが。
mix-inや traitsは、使われる場所でいろいろ意味が違うみたい。自分は mix-inといえば Rubyのしか知らないし、traitsといえば std::stringの char_traitsしか知らない(それすら知っているとはいえない)。
最終更新: 2011-01-02T16:57+0900
/* 現在位置より前の位置を検索する */
bool found = false;
CLogicRange matchLogicRange = CLogicRange( CLogicPoint( -1, -1 ), CLogicPoint( -1, -1 ) );
CLayoutRange matchLayoutRange = CLayoutRange( CLayoutPoint( -1, -1 ), CLayoutPoint( -1, -1 ) );
const SearchPos originalSearchPos = searchPos;
if( pLayout ) {
bool retried = false; ///< 末尾から再検索したかどうか。
for(;;) {
found = 0 != GetDocument()->m_cLayoutMgr.SearchWord(
searchPos.y, searchPos.x, // 検索開始位置
m_pCommanderView->m_szCurSrchKey, // 検索条件
SEARCH_BACKWARD, // 0==前方検索 1==後方検索
m_pCommanderView->m_sCurSearchOption, // 検索オプション
&matchLayoutRange, // マッチレイアウト範囲
&m_pCommanderView->m_CurRegexp // 正規表現コンパイルデータ
);
if( retried ) {
break;
}
if( ! found && GetDllShareData().m_Common.m_sSearch.m_bSearchAll ) {
// From Here 2002.01.26 hor 見つからなかったので末尾から再検索する。
searchPos.y = GetDocument()->m_cLayoutMgr.GetLineCount() - 1;
searchPos.x = static_cast<Int>( MAXLINEKETAS ); // とにかく大きければよい。
retried = true;
continue;
}
if( found ) {
this->GetDocument()->m_cLayoutMgr.LayoutToLogic( matchLayoutRange, &matchLogicRange );
// 検索開始位置での幅0マッチはなかったことにして一つ前から探す。
if( matchLayoutRange.GetFrom() == matchLayoutRange.GetTo()
&& matchLayoutRange.GetFrom().GetY2() == originalSearchPos.y
&& matchLogicRange.GetFrom().GetX2() == originalSearchPos.x
) {
searchPos.x -= 1;
found = false;
continue;
}
}
break;
}
}
20090808p03の @2009-10-19に書いた*結果の一部が上のコード。@2009-10-20でちらりと書いた、現在の選択範囲が幅0かどうかで検索のその場足踏み対策を行っていたのは不十分だということがわかったので、対処するために CViewCommander::Command_SEARCH_NEXT()を同じように書き換えられたら楽だけど、テストがないからそれは(私家版でしか)できないんだよね。
gotoを使っていたり、bRedoや bFlag1という名前の変数があるコードをいじるのは嫌だなあ。(だからこそ Command_SEARCH_PREV()は全面書き直しになった)
まあ、bRedoはわからなくもない。いや、使われている部分を確認しないとわからないのだが、retriedだって他人にとっては似たり寄ったりかもしれないので許容しよう(ただし、スコープが狭まったことで使用部分の確認がしやすいのは明らかに前進している)。書き換えたっていうけど、ループだって単に飼い馴らされた gotoじゃないかと言われるかもしれない。しかも上の例では繰り返しを前提としていない(一回で抜けるのが通常パスだ)から意図が不明確になったおそれもある。でもこの関数で使われていたもう一つの gotoのように、変数が初期化されない云々のエラーが出るために変数宣言を関数の頭に置くことを要求してしまう、そんな使い方はできないことが担保されている。(goto end_of_func; のことですよ)
あ、上のコード、キャレットが行頭にあるときのことを考慮してない(searchPos.x -= 1; の部分)。一応、問題なく機能してるみたいだけど。
もうひとつ問題が見つかって、現状が問題ありありならばとザックリ Command_SEARCH_PREV()と Command_SEARCH_NEXT()を書き直した。どうせ問題続出するんだろうなあ、とこっそりアップロード。
CViewSelectの修正がないと、マッチの始点と選択開始点が重なったとき(選択範囲が空になるとき)に選択ロックが外れてしまう。
範囲選択中でないときは幅0マッチなどによる検索のやり直しをしないようにした。範囲選択中かどうかというのは条件として不十分なんだけど、すくなくとも検索前と後で状態が変わるということはいえる。Command_REPLACE()が事前に選択をキャンセルしてくれているので、とりあえずは置換が一つ飛ばしになることがなくなる。
「aaaaaaa...」というテキストを、F6による選択ロックを利用して上方向に選択中に「aaa」を下検索する。3文字ずつ選択範囲が縮小していくはずのところが、1文字ずつしか縮んでいなかったのを元通りにした。
誤) SEARCH_PREV, SEARCH_NEXT
正) Command_SEARCH_PREV, Command_SEARCH_NEXT
すべて置換の無限置換対策として「m_pCommanderView->GetDrawSwitch() // 全て置換の実行中じゃない」という条件(見落としていた)を元のソースからコピってきた。
CViewSelectの変更がステータスバーメッセージの不要な表示につながっていた。メッセージ表示部にそういうチェックをさせて、カーソル位置による選択範囲変更で幅0選択を可能にする(昨日の修正)部分は残したいけど、影響範囲を延々たたいていくようなことになったらいやなので CViewSelectの変更は取り消し。
F6でロックしてキャレットを動かしまた元の位置にもどす。この状態でダイアログを出して検索をすると選択範囲の拡大縮小ではなく、マッチ結果が選択されてしまう。こんなことが起こるならやはり昨日の修正を温存したくなる。不思議なのは ANSI版も同じ挙動だったのだが、UNICODE版ではきちんと選択範囲の拡大縮小になっていたこと。<<< どうやら「カーソル位置の単語文字列をデフォルトの検索文字列にする」の設定が違っていただけみたい。
CViewSelect.IsTextSelected()には、0文字選択を含むのか含まないのかはっきりしてほしい。定義⁑からは 0文字選択を含んでいるが、IsTextSelecting()というものの存在からは、意図としては 0文字選択を含まないようにもとれる。なんにせよ CViewSelect.ChangeSelectAreaByCurrentCursorTEST()が幅0選択を特別扱いして選択解除するのは意図がわからないし、仮に目的があったとしても不適切、あるいは不完全な処置だろうと思う。問題は選択解除によって IsTextSelected()が trueから falseに変わることで、IsTextSelected()は本当にあちこちから呼ばれているので ChangeSelectAreaByCurrentCursorTEST()の変更は影響範囲が広すぎる。(ステータスバーメッセージもそのひとつ)
そもそも、keepCurrentSelectionの条件に CViewSelect.IsTextSelected()は不要に思えるのでこれを外すことで対処。元のソースをできるだけ尊重するつもりでこうしてあったんだけど。
「末尾から再検索しました」が表示されないのは、条件が「先頭から再検索しました」と同じになっていたからでした。(不等号が逆向き)
「CViewSelect.cppの修正は、幅０なら何もしないのではなく、 (略)」 else節で「pSelect->Set(ptCaretPos);」と同じことをしていたつもりです。また「m_nLastSelectedByteLen = 0; // 前回選択時の選択バイト数」の扱い方がわかっていないのですが、選択解除もしていないのに「前回選択時の～」というのはあたらないのではないかと。
コメントで指摘されて rev2で導入した sel.IsTextSelected()を sel.IsTextSelecting()に変更したのは、CViewSelectの変更を取り消したことによって、検索結果による選択範囲の拡大(縮小)の結果が幅0になったときに sel.IsTextSelected()が falseになってしまうことへの対策。(選択開始点から先へ検索が進まなくなってしまうので)
「本の虫: シンタックスシュガーとしてのlambdaの解説」
ifの条件文に && や || が 3つも 4つも連なってくると 1つの Predicateにまとめてしまって名前を付けたくもなる。でも struct{ bool operator()() const {...} } IsHoge; と書くだけでも面倒なのに、スコープが断絶してしまうために、判断に必要な変数にアクセスするためにはコンストラクタで参照を受け取ってメンバ変数に保存しなければならない。コンストラクタを書くために型名も付けなければならない。もうね、やってられない。どうせコンパイラの最適化で消えてしまうコードを長々と書くのは無駄。消えなければもっと無駄。はやく lambdaを。
http://sakura-editor.svn.sourceforge.net/viewvc/sakura-editor?view=rev&revision=1724
とにかく無限ループで強制終了しかできなくなるのは良くない。
* 「# 幅0の上検索がいつまでもその場足踏みしてないで上へ進むように修正。 # キャレットより前の、幅0の行頭マッチがハイライトできていなかったのを修正。(あんまりやりにくいので CViewCommander::Command_SEARCH_PREV()から gotoを取り除いて、不必要に選択範囲を保存するのをやめた)」
⁑ CViewSelect.IsTextSelected() -> return CLayoutRange m_sSelect.IsValid() -> return CLayoutPoint m_ptFrom.BothNatural() && CLayoutPoint m_ptTo.BothNatural()。BothNaturalという名前だけど、実際は xと yが共に 0以上かどうかをテストしている。選択範囲の始点と終点の X,Y座標がすべて 0以上のとき CViewSelect.IsTextSelected()は trueを返す。
最終更新: 2015-11-26T01:15+0900
class MyClass
{
public:
MyClass() : hidden_variable_data(0), open_const_data( hidden_variable_data ) {}
const int& open_const_data;
private:
int hidden_variable_data;
};
「Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.42 for x64」では期待通りにコンパイルしてくれて、期待通り( open_const_dataは書き換えられず、hidden_variable_dataを書き換えると open_const_dataも変更された )に動作した。
でも sizeof(MyClass)が 16(bytes)になる。これは int 4個分のサイズ。const int&を const intにするだけで、サイズは int 2個分と妥当なサイズになる。いったい何をしてるんでしょうね。
x86 向けにコンパイルした結果と比較すると、参照のサイズはポインタのサイズらしい。それはわかるんだけど、64ビット(ポインタ 1つ) + 32ビット(int 1つ) = 12(bytes) とならないで 16になったのはなんでだろう、と。アラインメントってやつなのでしょうか。
/Zp[n] pack structs on n-byte boundary
試しに /Zp4 オプションをつけてみたら sizeof(MyClass)が 12(bytes)になった。やっぱりアラインメントだったのね。
ところで、合法なんでしょうか？ (見たことがないんだけど)
だとしても () を省くためだけに、ポインタ分のサイズ増加と間接アクセスによる実行コスト増加を受け入れられるかといえば、やっぱり割に合わないか。
「n-byte boundary」の byteが単数形なのは nが 1かもしれないからではなくて、n-byteが形容詞みたいになっているからだとか。退屈な例を出すと 10-year-old boyとか。64-bit OS もそうだな。たぶん塾で最初に聞いた。
なんで書いたかといえば、byteの複数形って bytesでいいのかなあ、と書いてから疑問に思ったから。「情報の単位」には「1MB = 1,000KB = (10^3)^2 = 10^6 = 1,000,000 Byte」というように書いてあって不安にさせられたが、「Byte - Wikipédia, a enciclopédia livre」には「Megabyte (MB) / 1 024 KB / 1 048 576 (2^20) Bytes / 8 388 608 Bits」と、Bytesが使われている。日本語ソースよりは ptと略される言語を信用する。ポーチュギーズ？
日本人が桁を 3つずつ区切るのが全く理解できない。
10,000,000 bytesを ten milion bytesだとか ten mega bytesだとか読むのであれば理解できる。でもたいていの場合、単位は円だ。4桁で区切れよ。そうすればカンマが万、億、兆だ。円以外の日常的な単位は n,µ,m,d,h,kを使って単位が 0を内包するから桁区切りなんて不要だし 3桁 4桁区切りが両方必要(円だけ例外扱い)になったりはしない。さすがに $は 3桁で区切ったほうがよさそうだけど、俺の日常に $という単位はない。
そんなわけで極力、桁を区切らないで済ますことにしてる。あんなもんは飾りだ。そして、飾りは不要だ(後半に異論はあるでしょう)。
最終更新: 2009-11-23T01:26+0900
Subject: Re: #Pharmacy Viagra Vicodin and Valium !!! From: <ds14050@vvvvvv.sakura.ne.jp> Date: Sun, 22 Nov 2009 02:28:21 -0500 To: <...>
こういうメールが受取人不明だとして Postfixから突き返されてきた。
送った覚えはないし、Toに書かれたアドレスに見覚えもなければアドレス帳に入ってもいない。
スパムとしての内容(リンクの URL)はすべて Toに書かれたアドレスをターゲットにしているから、スパマーは Postfixを使って俺にスパムを送りたかったのでもないだろう。
それだけなら他人(俺)のアドレスを囮にしたスパムメール(ただし未達)というだけなんだけど、ポイントは To に書かれたアドレスのホストがまるっきり知らないものではない、ということ。本当の送信者は俺のアドレスと To に書かれたアドレスの両方をアドレス帳に入れているウィルス感染者じゃないのかなあ、とか想像した。(送る当てもないメールアドレスをアドレス帳にしまう理由が想像つかないけどね)
最終更新: 2011-11-30T12:36+0900
Vistaの新機能：ハイブリッドスリープを有効にしているのに、Vistaになって新設された /h オプションで休止状態にはできてもスタンバイ(ハイブリッドスリープ)にはできない。
なんだってこんな基本的なことができないんだろう。マウスを使わせようとするな。キーボードを使わせようとするな。
#! rubyw
require 'Win32API'
SetSuspendState = Win32API.new('powrprof.dll', 'SetSuspendState', %w(i i i), 'i');
SetSuspendState.call(
0, # hibernate: S4(TRUE) or S3(FALSE)
0, # force: アプリケーションに事前に通知(PBT_APMQUERYSUSPEND)しない(TRUE)。通知する(FALSE)。
0 # disableWakeEvent: イベントによる復帰を許可しない(TRUE)。許可する(FALSE)。
);
rundll32.dllが要求する仕様を知っていますか？乱用されてもクラッシュせず黙って耐える rundll32.dllのことを知ってあげてください。
最終更新: 2010-04-08T22:28+0900
参照(説明の丸投げ)> 萌ディタの Lex 周り - miau's blog?
SHJSと萌ディタ、共通の泣き所。そもそも論を言えば、入力に対応した stateを一つ一つ定義していけば対応できなくもないし、Rubyの括弧を使った %記法、%r(pattern)flag のようなものでは括弧に分類される文字種が 4つしかなかったために実際そうしたのだが、非英数1バイト文字や識別子が使えるとなると状態数があっという間にふくれあがってしまう。
SHJSの場合は、JavaScriptであることと eval()で評価されることを利用して、ネイティブの RegExpオブジェクトの代わりに execメソッドと lastIndexプロパティを定義したオブジェクトを登録することで抜け道を用意できるように感じたが、どんな形で特定のキャプチャを参照するのか決めかねた。
今日試しにダウンロードしてみた K2Editorではヒアドキュメントの色分けが可能なようだ。配布パッケージに含まれる Ruby.txtと K2Editor.chmによると書式はこう。
・<<(["'`]?)(\w+)\1 .... ^$2$
ヒアドキュメント１。後ろのディスクリプターは行内に唯一でなければ
ならない。
右側の検索文字列には、後方参照が使えます。 左側で()でくくってグルーピングしたマッチ文字列を、 右側の検索文字列の中で取得できます。
取得するには、 K2Editorの置換機構の 後方参照と同じように、$1,$2などを使います。
\1、\2でなくて $1、$2だから、右側のパターンは左側のパターンマッチングが終わった後で、置換されてからコンパイルされるのかも。
SHJS(と萌ディタ)にあてはめた場合、$1、$2がどのマッチングのキャプチャを指しているのかが明らかではない。というところで二の足を踏んでいる次第。
formatted_text = <<TEXT.strip.gsub(/\t/, " "*8) TEXT
texts = [<<TEXT1, <<TEXT2] TEXT1 TEXT2
こんなんどうする？
最終更新: 2009-12-06T02:34+0900
たとえば、http://sakura.qp.land.to/?Junk%2F31 で展開されている GNU Global対応。息の長い支持があるが本体に取り込まれてはいない。こういう万人向けでない機能がプラガブルになっていると、
プラグイン化を推し進めると、不要な機能をそぎ落として、メニューも整理して、必要な機能は自分で用意する。自分だけのエディタになる。
っていうのが xyzzyや Emacsの方向性？ そう思うと途端につまらなく思えてくるのは何故？ プラットフォームだと思うとアイデンティティが希薄に感じられるのと、なんでもできる/やろうとする/できてしまう無節操さが嫌いなのかも。
いったい自分はどうしたいんだ？
なんでもできるエディタで、やりたいことだけを可能にする！？
でも実際は、エディタなんてなんでもいい＆使い比べもしないものぐさな人間だということを行動が示している。最初はメモ帳でスクリプトを書いていて、エラー行を見つける手段(行ジャンプ、行番号表示)がないのに困って最初にダウンロードした TeraPadを 2、3年使い、正規表現検索がないのを不便に思って最初にダウンロードしたサクラエディタを 5年以上使い、ソースが公開されてるもんだから色分けの不足を補えてしまって萌ディタをカスタマイズする機会を逸したまま現在に至る。名前の良さと最初から大概のことができる間口の広さで誘い込まれ、ソースをいじる究極のカスタマイズができる自由さで閉じ込められた。
という要素を自分は求めている(らしい。サクラエディタに最初の二つはなかったが、必要だとは思う)ので、プラグイン化で機能をそぎ落とせる必要はなく、それなりに需要のある機能をプラグインで置き換える必要もないかもしれない。プラグインの本命はニッチな機能、取り込むには大きすぎる機能、ライフサイクルの異なる機能の実現にある。……が、なんでもプラグインにしてしまって柔軟にデフォルトを設定できるような状態にしておく、というのもやはり魅力的だ。(それに、デフォルトのタイプ別設定(AWK、アセンブラ、COBOL、Java、TeX、Visual Basec、……)のうち使わないものは目にするのも嫌だという人種(潔癖だね)が一定数いるらしいから、それに応えることにもなる)
っていうのが Linuxの現れては消えるディストリビューション？ 適切なデフォルトが対象別に無数に存在する状態を、適切なデフォルトが用意されている、とは言いたくないな。適切なデフォルトはとっつきの良さのために導入した指標だから(注:Linuxの話ではない)。
この展開の着地点を Windows ということにしてみよう。エディタ界の Windows。普及(利益)を目指すなら当然の帰結、とかいって。とりあえず Linuxには、何も考えずこれを入れとけ、っていう強力なディストリビューションが一つだけ、ほしいね。(Ubuntuが五年後も続いていたらいいポジションだ)
最終更新: 2009-11-20T01:27+0900
/* * (略) * @author ピクミン (以下略) 何故・・・。
ピクミンをやったことはないけど、全体の利益のために我が身を敵に投げ出す白ピクミンの境遇を連想した。白ピクミンに限らず、ピクミンって個々は全く尊重されないよね。人間はもちろんそんな扱いを受けるはずがないけど……。
♭ ななしfix_searchword_selection_with_selectinglock_on 置換前：$ 置換後：..
♭ ななしてけとー。 CViewCommander.cpp 【追加】 3116: const bool wasSelected..
♭ ななしや、 3158: (sel.IsTextSelected() && matchLayoutRange.GetF..
♭ ななしrev2 「先頭(末尾)から再検索する」をONにしているのに、 末尾から再検索しても「▲末尾から再検索しました」 が..
♭ ななし「選択幅ゼロ」は自明なので一切表示しなくていいと思います。
♭ ななしCViewSelect.cppの修正は、 幅０なら何もしないのではなく、 以下のようにしたほうが良くないですか？ ..
♭ ななしrev2です。 abc というテキストで、 置換前：abc 置換後：xyz 先頭(末尾)から再検索する：ON 置換対..
♭ ななし※同じく、置換後を abcxyz、置換対象を[選択文字(0)]としても起きた