msのランタイムって、FPUの精度を固定していないか?
>544はもう一回動かしてもtest1のx[6]は違う値のまま?

15桁目まで同じだからdoubleの精度としては問題ない。

C99以前ではhhxって使えなかったんだ。
知らなかった。

x86のFPUは、80ビット精度と64ビット精度が存在する。
SSE2は64ビット精度。
とかそのへんの問題かな?

>>551に一票。

浮動小数点演算の検算で精度気にしすぎると禿げるぞ。
ε使えε

テキストで出力すると計算の問題なのか出力関数の問題なのか分からんな。
バイナリで出力（あるいは１６進ダンプ）してみて
どうなるかチェックした方がいいと思う。

例えば
fprintf(fp, "%.16e\n", x[5]);
これを
output(fp, x[5]);
にして、output を別翻訳単位で下のように定義してみたらどう？

void output(FILE *fp, double value)
{
　union {
　　double value;
　　char array[sizeof (double)];
　} dc = { value };
　int i;

　for(i = 0; i < sizeof (double); ++i) {
　　fprintf(fp, "%02X ", dc.array[i]);
　}
　fputchar('\n', fp);
}

_controlfp あたりでぐぐれ

VCとgccのデフォルトのFPU計算精度は異なるらしい
http://homepage1.nifty.com/herumi/prog/prog90.html
_controlfpでいじると同じ精度にできる

おー、それだそれだ、思い出した。

皆さまコメントありがとうございました。>>556-557の方法で解決いたしました。

使用していた Windows 環境では MinGW でコンパイルしたコンソールアプリは 53 ビット、
MinGW でコンパイルした GUI アプリと VC++ Toolkit 2003 でコンパイルした両アプリは
64 ビットの演算精度を用いていたようです。

別の Windows 環境で試したところ MinGW でも両アプリとも同じ計算結果になりました。

コンソールアプリを MinGW でコンパイルすると演算精度が 53 ビットになる環境がある、
確実を期すなら  _controlfp を使え、ということですね。

髪がすこし減ってしまった気がします。本当にありがとうございました。

つーか、doubleの精度以上の処を云々すると禿げるよ。
どうせ微小誤差が付き纏うんだから適当な桁で丸めて表示するとかしないと。

>>560
おっしゃる通りです。

今回の件が気になってしまったのは、シミュレーションコードのデバッグ中だったためです。
実行環境やコンパイラが違ったら気にしないところですが、同じ環境で同じオブジェクトコードに
同じ入力データを与えているにも関わらず計算結果が違うことにとまどってしまいました。
原因はdoubleの範囲を越えた部分の誤差でしたが、この問題を調べるきっかけになった
シミュレーション結果の違いはもっと有意な差だったので看過できませんでした。

育毛にはげみます。

>>561
> シミュレーション結果の違いはもっと有意な差だったので

俺は予言する
もまいは禿げる。

肝心のアルゴリズム、あるいはテストベクタが草ってんじゃない?

>>561
IEEEに準拠するように80bitではなく強制64bitにするオプションがあったはずだが

>>563
>556-559

そんなあなたを禿増してあげましょう

>>541 発見しますた
http://sohda.net/cygwin/dist/mirror/www.geocities.jp/meir/cygwin_ck/

OS再ｲﾝｽｺしてdevcpp+SDLで以前のソースコンパイルしたらWinMain@16なエラーが('A`)
int main(ryから始めてるし-mwindowsも付けてるのに
cygwinでもｲﾝｽｺすれば変わるかなあ

-lSDLmain付け忘れ&-l順番ミスでしたｻｰｾﾝ
SDL外したらコンパイル通って、sdl-config見てやっと思い出した

相談じゃなくて雑談になるんだけど
g++4.3.0をビルドしてみたんだけど、g++のbinが460,475ってでかくね？
cygwinのインストーラからのg++3.4.4は96,789、verうｐとかモジュール化とか考えてもねぇ。
とか思いながら動作テストで↓コンパイルしたら、2,339,843、メガってどうなの。（ちなみに3.4.4でも477,682、g++4.3.0binよりでけぇ
#include <iostream>
int main(){return0;}
これって一体何がバイナリに組み込まれてるのか気になるんだけど、分かる人教えてー、誘導だけでもいいから。
ちなみに#include<iostream>だけ消したら3.4.4が7,673、4.3.0が10,915と小さくなった。（勿論gccじゃなくてg++で

stripしろよ
ライブラリのdebug infoもな

なるほど、どうもー。

g++ 普通にビルドできるのか？
それならなんで Cygwin のパッケージは 3.4 のままいっこうに動かないんだろう。

そのうち、stripしてもまだサイズがでかいがどうしてだ？　といった
ググれば5秒で分かるFAQを聞きに戻ってきそうだ

嫌味だけは一丁前でな

>>572
できたよー
そういや俺も昔クロスコンパイラ作ろうとしたけどビルド出来なかった覚えがあるな
そんときは原因分からず仕舞いやったけど

cygwinのパッケージはlinuxでビルドされてるらしいから3.4で動かない原因は別なんじゃない？

Windows XP SP2 上で Cygwin gcc 3.4.4 の MinGW モードで開発してるんですが、
システムメニューの項目を EnableMenuItem() を使ってグレーアウトさせようとしてもできません。

具体的には、ウィンドウプロシージャで WM_CREATE を受け取ったとき

　EnableMenuItem(GetSystemMenu(hWnd, FALSE), SC_MOVE, MF_GRAYED);

としても、システムメニューの「移動」がグレーアウトせず、有効なままになってしまいます(実際にウィンドウ移動もできる)。
MF_GRAYED を MF_DISABLED にしても同様で、システムメニューからウィンドウ移動ができてしまいます。

　DeleteMenu(GetSystemMenu(hWnd, FALSE), SC_MOVE, MF_BYCOMMAND);

ならば正常に機能し、項目が削除されるんですが…。

似たような環境で EnableMenuItem() によるシステムメニュー項目のグレーアウトができている方がいれば
方法など教えていただけないでしょうか？

すみません。追記です。

　EnableMenuItem(GetSystemMenu(hWnd, FALSE), SC_CLOSE, MF_GRAYED);

は正常に機能し、システムメニューの「閉じる」とタイトルバーの×ボタンがグレーアウトするようです。
となると「移動」とか「サイズ変更」がグレーアウト/無効化できないのは Windows API 自体の仕様なんですかね？
もしそうだったらスルーしてください。Cygwin + MinGW 環境固有の問題かと早合点してしまったので。

Win32 API スレの管轄だろうな。
ま、それはともかく設定するタイミングが駄目だと思う。


http://msdn.microsoft.com/library/ja/jpwinui/html/_win32_getsystemmenu.asp?frame=true
>GetSystemMenu
>
>状況によって、システムはウィンドウメニューの標準的なメニュー項目の一部を自動的に淡色表示にします。
>アプリケーションは、どのメニューも表示されていないうちに WM_INITMENU メッセージに応答することにより、
>メニュー項目を独自に選択したり淡色表示にすることができます。

ということで、WM_INITMENU でやればいいと思う。っつーか、普通のメニューでも項目の無効化等はそこでやると思うんだけど。

>>578
スレ違いの質問にお答えいただいて恐縮です。
仰る通り WM_INITMENU を受け取ったときに設定することで「移動」「サイズ変更」もグレーアウトさせることができました。

ただし、WM_INITMENU メッセージでは wParam に対象メニューハンドルが格納されるらしいのですが、
システムメニューに関してはこれは当てはまらないようです。なので、

　if(wParam == (WPARAM)GetSystemMenu(hWnd, FALSE)){
　　...
　}

などとすると if 文の中身は決して実行されないようです。
よって、システムメニューを設定するだけなら wParam は無視すべき、ということみたいです。

WM_INITMENUPOPUPなら見分けがつくんでない?

>>580 アドバイスありがとうございます。やってみましたが、

　if(HIWORD(lParam) == 1){
　　...
　}

というテストはうまくいくものの、wParam にはシステムメニューのハンドルが入っていないようです。
ですので、EnableMenuItem() などに渡すメニューハンドルはやはり GetSystemMenu() を使って自前で取得しなければ
ならないようです。
また、WM_INITMENUPOPUP を受け取ったときに EnableMenuItem() を呼ぶと、タイトルバーから初めてシステムメニュー
を呼び出したとき、システムメニューの表示位置が若干上にずれて、タイトルバーを覆い隠すような形で出てくるようです。
まあ2回目以降は正常に戻るので、気にするほどのことではないかもしれないですが…。
あと、WM_INITMENU の場合は対象がシステムメニューかどうか見分けが付かないので、自分で初回スイッチのような
ものを用意して対処する必要がありそうですね。

それと、さっき色々試していて気が付いたのですが、WM_INITMENU または WM_INITMENUPOPUP を受け取ったときに
EnableMenuItem() する方法だと、タスクバーを初めて右クリックしたときに項目が無効にならないようです。
2回目以降、もしくは初回であっても事前にタイトルバーからシステムメニューを表示させていれば EnableMenuItem()
の設定が反映されるんですが…。

調べてみたところ、タスクバーが右クリックされたときには非公開メッセージ 0x313 が送られてくるとの情報があったので、
(参考:http://www.hey-to.net/ML-archive/vcppML/1999/msg03694.html)
0x313 を捕捉し、そのハンドラで EnableMenuItem() などの設定を行い、
さらに DefWindowProc() にメッセージを処理させればよい…みたいです。

>>576の環境でしかテストしていないのであまり自信がないですが、これだと一応タスクバー初回右クリック時も正しく
項目が無効化されたシステムメニューが表示されます。
とはいえ、非公開メッセージに依存するのも微妙な感じなので、いっそ WM_CREATE のハンドラで無効にしたい項目を
DeleteMenu() してしまうのが一番簡単かもしれないですね。

長文失礼しました。Windows って難しいです。

>>581
Win32 API スレいって揉まれてくるといい

cygwinでopenmpは使える？？

>>581
これじゃダメなんかい？

DWORD dwStyle = GetWindowLong(hWnd, GWL_STYLE) & ~WS_SIZEBOX;
SetWindowLong(hWnd, GWL_STYLE, dwStyle);

windows2k MinGW を入れたいのです
MinGWインストーラがネット無いので使えません
ソースフォージからどれを落とせば良いでしょうか
またそれは全て同じフォルダに上書きで良いでしょうか
binフォルダなどかぶっているものがおおいんです
使いたいのはC、C++、SDL、OpenGLです
パスは適当に通そうと思っています

MinGWインストーラはDownload Onlyを選べば、落とすだけを選択できるぞ
あとは上書きで桶

>>586
おおありがとう！
じゃあ遠かったHelloWorldも近づきますﾉｼッ

ちょっとお聞きしたいのですが、mingwでは-Iオプションは使えないのでしょうか？
g++ --help でリストに出てこないのです。
しかしg++ -I とすると argument to `-I' missing のような感じで、unrecognize option `-j' みたいな感じではでてこないので、使えるような気もするのですが・・

>>588
g++ -v --help で出てきませんかな。
正直 gccのオプションはかなり多いので g++ --version でバージョンを確認してから
ぐぐるなり GCC online documenthttp://www.gnu.org/software/gcc/onlinedocs/
から探すなりしてマニュアルを読んだほうがよいかと思います。

>>588
使える

>>588さん
>>580さん

レスありがとうございます。
使えるのですか。
-I使う場合は、Windows用に
-IC:\Program Files\...
みたいな感じで書けばよいのでしょうか？

上記の感じでやってみたのですが、うまくいかなく・・

>>588さん→>>589さん
>>580さん→>>590さん

>>591
スペースが入ってるみたいだけど...

>>591
パスにスペースを含む場合は "" で囲むと聞いたことがあるけど
-I"C:\Program Files\..." ではだめかな

分割されなきゃいいのだから、空白をエスケープするだけでもいいかも。
それはさて、ディレクトリ区切りのバックスラッシュってエスケープする必要あるんでない?

スラッシュにした方がいいな
-l"C:/Program files/..."

ていうか相対パス指定できるように環境を整えた方が
のちのち便利だと思う

レス下さった方々、ありがとうございます。

-l"C:/Program files/..."
こんな感じでとりあえず目的のコンパイルはできるようになりました。多謝です。

相対パス指定のための環境構築について、検索してみたのですが、それっぽいのが出てきませんでした。
スレ違いで申し訳ないのですが、よろしければどなたか解説してるサイト教えて頂けると幸いです。

msysかcygwinをいれちゃう。
あなたならおそらくmsysのほうがおすすめ。

ふと思ったがmingw単体で使ってる人ってけっこういるんだろうか。

あっちの関連スレにここがあったから貼り返し。

Cygwin使っている人いますか？ その18
http://pc11.2ch.net/test/read.cgi/unix/1184677144/

>>598
俺々、俺だよ
msysはgccのsnapshotをコンパイルするときくらいしか使ってない