Hobbyの最近のブログ記事

そうでした。

いくら加算・減算ができるといっても、返却可能な桁数には制限があるのです。

桁数が足りないからエラーにしちゃうのは、まずいわけで、少なくとも、整数部が制限に収まっているのであれば、値を返すべきでしょう。

であれば、特定の桁位置の値で四捨五入しなければならないのですが・・・これがちょっと難しい。

四捨五入処理自体はそれほどのことはないのだけれども、返却文字列長を考えるとね。

既出のアプバーをアップしてみる。

20091201_TwitbarSetup.msi

動作には、.NET Framework 2.0が必要。
64bitOS未確認。

正常にPOSTできると、IDとパスワードを保存する。
＃保存するけど、暗号化はしない。

正式なAPIを使用しているかは不明。

サポートサイトでのサポートはなし。

何かあればコメントで。

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の省略はコンパイラエラーを招く。

うっかり忘れて多量のエラーを吐かれると、イヤなのでメモ。