ds14050

矩形選択置換が範囲を無視して置換してしまう

矩形選択置換で置換範囲がおかしいバグの修正

SourceForge_ds14050_GitHub_ds14050_OSDN_ds14050

これはひとり言です。古いコードを見ていると新鮮な発見があります。 https://sourceforge.net/p/sakura-editor/code/215/tree//sakura/trunk/sakura_core/CProcess.h このときの CProcess::Run が呼ぶ３つのメソッドは =0 で純粋仮想とされておりテンプレートメソッドであることが明確でした。 https://sourceforge.net/p/sakura-editor/code/215/tree//sakura/trunk/sakura_core/CNormalProcess.cpp#l63 CNormalProcess::Initialize 関数で CShareData m_cShareData; DLLSHAREDATA m_pShareData; の２変数を m_cShareData.Init() などとして初期化していますが、この変数は Initialize 関数のローカル変数です！ CShareData のデストラクタで ::UnmapViewOfFile されるのに共有メモリの寿命は？？？と首をひねりましたが、CNormalProcess...

具象クラスがCProcessの継承ルールを守っている限り、CProcess::GetShareData()の呼出しで問題が起きることはないように思います。 これを信用していないんです。CControlProcess/CNormalProcess に手を入れる将来の人間、また第３のプロセスクラスを書く人間にそのルールを守らせるものがコードではなくコメントですらない。※その信用ならない人間が私です(反省) いいえ。 今後は積極的に例外を活用していくべきだと考えています。 自分について述べますと、これまで try/catch/throw を書いたことがありません。デバッグ時にコーディングエラーを捕捉する目的で assert を書く(間接的に例外を発生させる)程度です。数日前に実験して知ったのですが、引数を指定しないで例外を発生させる throw; は catch(...) でキャッチできないのですね。これは驚きでした。そして throw; といっても同じ例外を再スローする意味の場合はまた違うのでしょう。

具象クラスがCProcessの継承ルールを守っている限り、CProcess::GetShareData()の呼出しで問題が起きることはないように思います。 これを信用していないんです。CControlProcess/CNormalProcess に手を入れる将来の人間、また第３のプロセスクラスを書く人間にそのルールを守らせるものがコードではなくコメントですらない。※その信用ならない人間が私です(反省) いいえ。 今後は積極的に例外を活用していくべきだと考えています。 自分について述べますと、これまで try/catch/throw を書いたことがありません。デバッグ時にコーディングエラーを捕捉する目的で assert を書く(間接的に例外を発生させる)程度です。数日前に実験して知ったのですが、引数を指定しない throw; は catch(...) でキャッチできないのですね。これは驚きでした。

まとめて返答します。 こう書いたら良いんではないでしょうか？ つまり元の通りですね。共有メモリの確保と初期化を一体的に扱うためにはその手順が必要なことがわかったので、CShareData に関してそうすべきだという点を争うつもりはありません。ただそういう問題がなければ、どうして処理をコンストラクタに移したいと考えたのかは理解してもらいたいと考えています。 責任の放棄であり間違いの元 GetShareData というアクセサを定義しているのは CProcess だから、それを通してアクセスする CShareData が InitShareData 済みの有効なオブジェクトであることを保証するのは CProcess の仕事だということです。すべての派生クラス(具体的には CControlProcess/CNormalProcess)に対して「確保と初期化が一体的に行われるようになんらかの調停手段を講じたうえで CProcess::InitializeProcess を呼んでくださいね。そうしないうちに GetShareData を呼んで CShareData を操作すると何か良くないことが起きるけど、私は知りませんよ」という...

まとめて返答します。 こう書いたら良いんではないでしょうか？ つまり元の通りですね。共有メモリの確保と初期化を一体的に扱うためにはその手順が必要なことがわかったので、CShareData に関してそうすべきだという点を争うつもりはありません。ただそういう問題がなければ、どうして処理をコンストラクタに移したいと考えたのかは理解してもらいたいと考えています。 責任の放棄であり間違いの元 GetShareData というアクセサを定義しているのは CProcess だから、それを通してアクセスする CShareData が InitShareData 済みの有効なオブジェクトであることを保証するのは CProcess の仕事だということです。すべての派生クラス(具体的には CControlProcess/CNormalProcess)に対して「確保と初期化が一体的に行われるようになんらかの調停手段を講じたうえで CProcess::InitializeProcess を呼んでくださいね。そうしないうちに GetShareData を呼んで CShareData を操作すると何か良くないことが起きるけど、私は知りませんよ」という...