のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,062,921人
昨日:no data人
今日:
最近の注目
人気の最安値情報

    元スレCygwin + MinGW + GCC 相談室 Part 3

    gcc覧 / PC版 /
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : - 932 + - cannotfind + - cp932 + - FreeHDL + - heap + - known + - log4cxx + - WinMain@16 + 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter
    551 = :

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

    553 = :

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

    554 = :

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

    >>551に一票。

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

    556 = :

    _controlfp あたりでぐぐれ

    558 = :

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

    559 = :

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

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

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

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

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

    560 = :

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

    561 = :

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

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

    育毛にはげみます。

    562 = :

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

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

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

    563 = :

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

    564 = :

    >>563
    >556-559

    565 = :

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

    566 = :

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

    567 = :

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

    569 = :

    相談じゃなくて雑談になるんだけど
    g++4.3.0をビルドしてみたんだけど、g++のbinが460,475ってでかくね?
    cygwinのインストーラからのg++3.4.4は96,789、verうpとかモジュール化とか考えてもねぇ。
    とか思いながら動作テストで↓コンパイルしたら、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++で

    571 = :

    なるほど、どうもー。

    572 = :

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

    573 = :

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

    574 = :

    嫌味だけは一丁前でな

    575 = :

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

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

    576 = :

    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() によるシステムメニュー項目のグレーアウトができている方がいれば
    方法など教えていただけないでしょうか?

    577 = :

    すみません。追記です。

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

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

    578 = :

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


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

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

    579 = :

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

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

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

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

    580 = :

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

    581 = :

    >>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 って難しいです。

    582 = :

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

    584 = :

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

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

    585 = :

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

    586 = :

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

    587 = :

    >>586
    おおありがとう!
    じゃあ遠かったHelloWorldも近づきますノシッ

    588 = :

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

    589 = :

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

    590 = :

    >>588
    使える

    591 = :

    >>588さん
    >>580さん

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

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

    592 = :

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

    593 = :

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

    594 = :

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

    595 = :

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

    597 = :

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

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

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

    598 = :

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

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

    599 = :

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

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

    600 = :

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


    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / gcc一覧へ
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : - 932 + - cannotfind + - cp932 + - FreeHDL + - heap + - known + - log4cxx + - WinMain@16 + 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

    類似してるかもしれないスレッド


    トップメニューへ / →のくす牧場書庫について