- - PR -
C の localtime() の引数は混乱を招く。
投稿者 | 投稿内容 | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-09-22 17:37
コブラさん
そうですね、CでC++を完全に模倣するのは難しいですけど、 「staticをつけた大域変数・大域関数はファイルスコープになる」 という性質を利用すれば、近いところまでいけるかもしれませんよ。 めげずに頑張って下さい。 蛇足ですが、ほむらさんの件は
ですね。 | ||||||||||||||||
|
投稿日時: 2004-09-22 22:14
ども、ほむらです。
--------- 未記入氏へ
フォローサンクスです。 なんとなく違う気だけはしていたのですけどやっぱ間違えていましたかぁ^^;;; コブラ氏へ
多重継承は無理でしょうけど継承みたいなことならできますよ。
これつまりは継承なので(笑 基底の構造体を先頭に持ってくるのがポイントです。(実体) # あくまでintel系の話なのでモトローダ系は反対になると思います やっぱC言語ってメモリとの格闘だ(意味が違う笑 | ||||||||||||||||
|
投稿日時: 2004-09-27 13:26
いやー、皆さん色々引き出しが多いですな・・・勉強さして貰ろてます。
ほむら氏のこれは、 struct tagSuper {}; struct tagSub { struct tagSuper super; int x; int y }; struct tagSuper {}; struct tagSub { int x; int y; struct tagSuper super; }; こうしないのは、コンパイラのパディングを予想してという理由だけなのでしょうか? それとも他に何か私の思いもよらない理由があるのでしょうか? 後、また困ってます (笑)
$ gcc -o pi -O pi.c -lm $ ./pi 3.00000000, 0.00000000, 2.38821840 3.00000000, 4.00000000, 2.38821793 4.00000000, 3.00000000, 2.38821793 4.00000000, 0.00000000, 2.38821840 0.00000000, 0.00000000, 2.38821840 0.00000000, 0.00000000, 2.38821840 $ 順番に依っても結果は変わってくるみたいですけど、ちょっと、酷くないすか? これ(笑) round() が最悪。まぁ、printf で表示した時だけですけども。オカしく なるのは。va_list には公平に値が渡ってるハズなんですが。。。 しかも、Solaris上 で $man round ってやっても「マニュアルには round のエントリがありません。」 これですわ・・・(プ printf() の引数に ceil(), round(), floor() の内、どれか一個だけ指定 したら、何事も無く期待値が表示されるんですがねぇ〜 | ||||||||||||||||
|
投稿日時: 2004-09-27 15:05
以下、私の環境(vine-3,gcc3.3.2)で確認した話です。
round()について この関数は、C99で追加されたようで、 標準状態では、ヘッダで定義されない状態になっています。 -Wallオプションをつけてコンパイルすると、 implicit declaration of function `round' という警告が出ます。 プロトタイプが無いため、round()がintを返すと判断されて、 結果がおかしくなっているのでしょう。 #define _ISOC99_SOURCE #include <math.h> とすると、 round()のプロトタイプが有効になって結果が正常になります。 このあたりのしかけは、features.hで行われています。 Solarisでも同じかどうかは不明です。 このあたり、C99の仕様に書いてあるんでしょうか。。。 [ メッセージ編集済み 編集者: ナキヲ 編集日時 2004-09-27 15:07 ] | ||||||||||||||||
|
投稿日時: 2004-09-27 17:15
>プロトタイプが無いため、round()がintを返すと判断されて、
>結果がおかしくなっているのでしょう。 >#define _ISOC99_SOURCE >#include <math.h> >とすると、 >round()のプロトタイプが有効になって結果が正常になります。 >このあたりのしかけは、features.hで行われています。 指摘の通りでした。 ミソは _ISOC99_SOURCE の #define でした。 RedHat9 の gcc で正しい結果が表示されました。 しかし、Solaris の gcc3.2 では、、ダメでした。。。 man にも無いし、やはり関数として存在しない様です。 しかし、Linux系でも round() を標準算術関数として公にしないのは何か 理由でもあるのでしょうかね。 | ||||||||||||||||
|
投稿日時: 2004-09-27 17:36
コンパイル・リンク・実行まで出来たのなら、 関数自体はあるんじゃないでしょうか。
さっきも書きましたが、C99という新しいC標準規格で追加されたものです。 標準状態を、旧仕様にするか新仕様にするかは 意見がわかれるところだと思いますが、 互換性重視で、旧仕様をデフォルトとしているのでしょう。 私の環境で、前の投稿に書いた、 features.hには _ISOC9X_SOURCE _ISOC99_SOURCE と、二つのマクロがあります。 _ISOC9X_SOURCEの方が古いのかもしれません。 これまた歴史的経緯でしょうか。詳しい方教えてください。 一度、math.hとその中でincludeされているファイルを覗いて、 round()の定義まわりをみてみるといいんじゃないでしょうか。 結局ソースが一番信頼出来るドキュメントということで。。 ソース以外まともなドキュメントが無い場合もありますし。。 ところで、 round()のmanページにはC99で追加されたことしか 書いてありませんが、 _ISOC99_SOURCEのdefineは常識的事項なんでしょうか? C99の追加仕様自体あんまり詳しくないのでなんともわかりません。 | ||||||||||||||||
|
投稿日時: 2004-09-28 12:05
>コンパイル・リンク・実行まで出来たのなら、
>関数自体はあるんじゃないでしょうか。 いや、、一番最初に貼り付けた printf の6通りの結果は、RedHat9 上での結果です。 ちょっと、日本語を省略し過ぎました。。 どうやら 「しかも、Solaris上 で」 この表現がマズかったらしく、Solaris への言及が唐突過ぎるので、printf の結果 そのものも Solaris 絡みという判断もできてしまいますが、実は、前提は RedHat9 で _ISOC99_SOURCE の #define 無しで出た round() の結果は散々・・・ で、最初の printf での 6通りの結果が "Linux Square" だからというので Linux(RedHat) 上での結果であるというのを暗黙にしてしまったのがマズかった 様です。 正しくは、 「RedHat9 で斯様な惨憺たる実行結果を招き、しかも Solaris では RedHat9 に 存在しておる "man round" ってやっても「マニュアルには round のエントリがありません。」 ・・・・ と書かないと、正確な意味が伝わり難いかも知れませんな。 こういうとこから認識のギャップが・・・ っちゅぅこって、Solarisではコンパイルできなかったので、round() を外して ceil() と floor() のみで実行してました。 ん〜、面倒臭がらず、背景を省略せずに書く事はこういう媒体では重要であると再認識 させられる顛末でした。 で、round() の部分的封印は、互換性の為でしたか。。。何らかの体系変更の過渡期には こういう事もあるんですな。 | ||||||||||||||||
|
投稿日時: 2004-09-29 13:09
前に、誰かに「標準関数が気に食わんのなら自分用の関数作ったらエエ」とか言われましたが、
全くその通りやと思いました。で、localtime(); の引数を間違え易いので、自分で localtime() そっくりの結果を返す localtime_s() っちゅぅ関数を作りました。
お気づきとは思いますが、第一引数は tm 構造体の「実体の」アドレス、 第二引数は time_t 型の実値が入ります。 、、ぶっちゃけ曜日が一日狂う時が「たまに」あるんですが (プ 今、原因を調べてます。 使用例:
こんな感じで・・・ |