Hobby::C++の最近のブログ記事

ずっと考えていたけど、無いんですよね、必要な場面って。

とりあえず修正終わりました。

今回のメインは多桁計算だったのに・・・

ま、いいか。
不具合潰せたんだし。

とりあえず、何かあったらサポートページにてコメントください(と、ここにも書いておこう)。

昨日からの続き。
そして、構造体にコンストラクタを用意したところ、構造体を取り込んだ共用体でコンパイルエラーが発生する罠。

曰く、「共用体メンバに既定のコンストラクタを持たせることはできません」だそうな。

じゃぁ、既存構造体から新たに継承したクラスを作って・・・とかやると大手術になってしまうので、仕方ないからそれは次期バージョンにて考慮。

今回は、newでサーチしてnewや変数宣言など、構造体メモリを確保している箇所で片っ端から初期化してやろうと思う次第。
＃必要な個所だけ。

他に、実はnewしているのは決まってExcelに返すデータをエクスポートする箇所なので、それらを一か所に集約してやろうかと。

これで今回の原因は撲滅できるはず。

実にえらいミスです。

概要は、こちら。

それにしてもtry～catchが効かないってのは痛い。

catchできてれば、狭めていくことで分かるのに。
＃いや、catchでスタックトレースすれば一発か？

今回は、トレースを入れて、どこまで出続けるかを追っていくという超アナログな方法を採用したため、非常に時間が掛った。

いや、言い訳に過ぎない。

100%確実ではないけれども、再現させる方法だけは見つけたので。

Windows 7を起動して、評価に使用したExcel95ブックをExcel2007で開くだけ。

すると、再計算50%を過ぎたところあたりでExcelがエラー(動作を停止)を起こす。

ここら辺が微妙なんだけど、50%のときもあれば、そうでない場合もあり。

2回目には起こらないので、都度OS再起動が必要。

ところが、通常、プロセスの異常時には、「デバッグしますか？」のダイアログが出るのだけれど、このExcel2007は自動修復するのか、デバッガでアタッチするとプロセスが終了してしまう。

困ったことナリ。

デバッグモードでは再現したことがないので、あたりをつけようにも・・・

とりあえず全エクスポート関数の大部分をtry～catchで囲んでみたのだけれども、状況は好転せず。

なんだか変。

Windows7やVistaで動作確認しようと、アドインを設定して、気を良くしてHLDIV(10,3)とかやるとExcel停止・・・
なんでやねん！

デバッグしようとしても痕跡なし。

じゃぁとVS2008からデバッグ実行すると、全く落ちず。
そうこうしてるうちにExcel停止が再現しなくなる。

なんだこりゃ？

重要。

でも、検算するのがとても大変なのは多桁演算の宿命。
だから、大体正しければいい、というものでもない。

除算の評価結果を見ていて、変なことに気付いた。

検算をするとどうもおかしい。

筆算してみても、自分が間違えてる可能性もある。

Windows付属の電卓はかなりの桁数計算できるが、それと比較すると、やはりどうも多桁計算側がおかしいようだ。

使用メモリ量と演算回数を削減したんだけど、Excel95落ちるようになっちゃいました・・・
多分、どこかで例外発生しているってことなんだろうけど。
おっかしいなぁ・・・って、よく見たら凡ミス。

直したら動くようにはなったけど、やはり重い。
＃加算・減算だけでなく、内部で加算処理をしている乗算も重い場合がある。

リソース絡みだと思いたい。
Excel95のリソース制約は一番厳しいので、Excel95で動けばExcel2003でも動く。
＃Excel2007からは別物だけど。

なんか、すごく重い。

今のところ原因不明。

Excel95で桁数多い場合に発生中。

Excel2003では発生しないようだした。

Excel95では同じ計算でも発生するときと、しないときがあるようだ。

数としてはあってもいいんだけど、-0が返るパターンがあったので、符号補正を入れて修正。

別に、1文字2文字で困る文字数じゃないから放置してもいいんだけど、0と-0が違うかっていうと十進数演算の中では同じなので、だったら符号不要ということで。

多桁計算にも一応、四捨五入丸め処理を入れている。
というのは既出だが、Excelに文字数制限があるため。
つまり、表現上、数に制限が生まれるわけで、普通の有効桁と同じ扱いと思ってくれればいい。
除算した場合、循環小数なんかはその限界まで延びるのだけれど、そこで四捨五入が必要になる。
掛け算でも桁が多ければ丸める必要がある。