C++でフォームアプリつくってたら、デザイナの挙動がおかしくなって、しまいにはデザイナエラー。
仕方ないので、C#。
でも、結果としてC#の方が楽だった。
C++でフォームアプリつくってたら、デザイナの挙動がおかしくなって、しまいにはデザイナエラー。
仕方ないので、C#。
でも、結果としてC#の方が楽だった。
TechNet Plus Directからもキーを落としてきたので、まとめて見れたらうれしいかと思い、試行錯誤を再び。
なんとなく、前と挙動が違う感があるのだけど、MSXML更新されてたような気がするので、そのせいかも知れないとか思いつつ。
件のXMLコードはMSDNプロダクトキー変換表示用XSLT/XMLコードに更新。
見るだけなら問題なし、かな?
html化が必要なら、msxslを使えばよい(はず)。
http://fne.cocolog-nifty.com/blog/2009/10/post-7c67.html
で書いたコード、確かにコマンドラインコンパイルでは問題なく動いたのに、プロジェクトに組み込んだら、#defineの中身を解釈してくれないばかりか、コンパイルエラー出まくる。
仕方ないので、ベタ書きした。
Office2010βの32bit版を動かしてみた。
なんか変なこと起こるかなと期待半分だったけど、アドインは問題無く動作。
Excel2007からの文字列長(32767文字)制限もそのままらしいので、内部仕様も全く問題なし。
さて、64bitは、どうなのか。
32bit混在で動くわけがないから、Excel自体が32bitであると64bitの恩恵を受けられないってことは64bitネイティブって可能性が。
アドイン呼び出し部だけ32bit化されてる可能性はあるけど、それだとオーバーヘッドでかいだろうし。
件の構造体のアラインメントは64bitだと変わりそうな感じがしてて・・・
あぁ、恐ろしい。<すぐにやってみれよ、俺。
パース方式考えなきゃな。
カンマくらいは大目に見てあげようとか考えつつ、本当に数万桁の計算ができるかやってみようかと。
やりすぎたか。
ロジック的には整数部小数部それぞれで2^32-1桁の計算に対応したはずなので3万桁なんて屁でもないんだけど、それを見るのは厄介。
とりあえず内部処理だけだが、加算・減算ができるようになった。
処理速度はイマイチだけど、負数も小数も含めて、600桁計算しても大丈夫になった。
結果の一例を載せておこう
忘れないように。
constメンバ関数のconst意味は、そのconstメンバ関数を実行する際に所有するオブジェクトの内容を変更しないという意味だが、それ故、constオブジェクトが実行できるのはconstメンバ関数に限られるということ。
つまり、
void Hoge::Func(const Hoge &obj)
{
if( obj.IsOK() ) // call Hoge::IsOK()
{
Hoge.m = obj.m;
}
}
のときの、Hoge::IsOK()
はconstで定義されていなければならないということ。
この場合、bool Hoge::IsOK() const;
のような定義が必要。
#たとえ、Hoge::IsOK()
の中で変更をして無いとしても、constの省略はコンパイラエラーを招く。
うっかり忘れて多量のエラーを吐かれると、イヤなのでメモ。
シェアウェア登録したのだけれど、使ってもらえてないのか、まだ売り上げが無いので、やはり追加関数で対応していきたい。
Excelで計算できる数値は10の309乗程度までの浮動小数点範囲なので、ここはひとつ、3万桁目指して計算できたら、何かうれしいことが起こることを期待しつつ実装中。
#3万桁使えるのはExcel2007以降だけど。
なにやら超胡散臭い方法を多々取り入れつつできたのだけれど、なぜ例外が発生していたのか、さっぱりわからない。
try catchでも捉えきれないってのは、tryブロック外か、catchブロック内で例外になっているのかも知れないんだけど、それでも超想定外で、さっぱり。
でも、とりあえず、動くようになったから、一応信じておくとするか。