【初心者お断り】ガチ規格準拠C専用スレ Part133

【初心者お断り】ガチ ..

751:デフォルトの名無しさん
09/03/04 23:56:45
そしてオーバーフローするんですね、わかります

752:デフォルトの名無しさん
09/03/05 10:58:14
>>750
その比較が意味のあるものとなる保障はない。
それに>>751がいうようにintじゃだめだろう。

753:デフォルトの名無しさん
09/03/05 23:11:20
ポインタをポインタと同じサイズの整数型に変換可能な事は保証されてるから
uintptr_t 使うならええんでないかい？

754:デフォルトの名無しさん
09/03/05 23:14:22
それなら問題ないよ。

755:デフォルトの名無しさん
09/03/21 12:06:23
double v;
としてvがnanやinfinityであるかを判定するにはどうやるんでしょうか？
標準ライブラリ見てもそのような関数が用意されてないので困っています。
v!=vでnanなのは分かっているのですが、他に方法はないのでしょうか。
それと、実数のときと複素数のときの判定方法を教えてください。
一応GCCです。

756:デフォルトの名無しさん
09/03/21 12:33:17
>>755
-std=c99 でisnan、isinfあたり。

757:デフォルトの名無しさん
09/03/21 13:06:48
c99にすれば用意されているのですが、コンパイラ・オプションで指定しないと標準ではinf, nanは判定できないって事ですか？

758:デフォルトの名無しさん
09/03/21 13:20:38
>>757
いちおう、 C99 は「標準」だよ。

gcc のデフォルトは C99 じゃないけど、拡張の一部として isnan, isinf は
使えたりするかもしれない。っていうか、試せばいいよ。

759:デフォルトの名無しさん
09/03/21 13:40:11
そういえばinfinityの判定はやったことなかったけど、今までみんなはどうやってたんだろう・・

760:デフォルトの名無しさん
09/03/21 13:42:21
>>756に書いてあるじゃんw

761:デフォルトの名無しさん
09/03/21 13:54:44
古いAPIを読んでたのでなかったんですが、今後はコーディングするときはC99準拠で必ずやることにします。

762:デフォルトの名無しさん
09/03/21 14:02:39
昔も標準でなかっただけで普通にあった。
isinfinity()の環境もあった。

> 今後はコーディングするときはC99準拠で必ずやることにします。

素晴らしいです。

763:デフォルトの名無しさん
09/03/22 10:12:15
restrictとか可変長配列とか勝手に使うと迷惑になることもあるから気を付けろよ
個人ならいいけど

764:デフォルトの名無しさん
09/03/22 14:04:37
>>763
kwsk

765:デフォルトの名無しさん
09/03/23 13:18:20
>>764
c99ではrestrictは予約語。iccだとオプションを指定すればc++でも使える。

766:デフォルトの名無しさん
09/03/23 16:59:58
ところで今の規格準拠コンパイラは複素数のinf, nanを判定できるのか？

767:デフォルトの名無しさん
09/03/28 01:41:09
Cに複素数なんて概念あったっけ？

768:デフォルトの名無しさん
09/03/28 05:50:48
>>767
c99

769:デフォルトの名無しさん
09/03/28 06:37:18
いい加減、このスレの参加資格に、C99の規格書を読むことを入れとこうぜ

770:デフォルトの名無しさん
09/03/28 09:36:52
まあURLﾘﾝｸ(seclan.dll.jp)くらいは参照した方がいいかと。

771:デフォルトの名無しさん
09/03/28 09:48:37
確かに2009年にもなってC99を知らんのはこのスレ的にはお断りだ
Cを知らないに等しい

772:デフォルトの名無しさん
09/03/28 09:50:19
旧規格もそうと断ったうえでなら可だろ
事実上まだ現役だし

773:デフォルトの名無しさん
09/03/28 10:24:27
C99を実際には使わなくても
知っていなくてはこのスレにいる資格は無いな

774:デフォルトの名無しさん
09/03/28 10:34:44
まあ複素数は置いといて、何かを知らないことをもって C99 を知らないことにされたら
資格者ほとんどいないんじゃね？

775:デフォルトの名無しさん
09/03/28 10:49:42
今規格をあたろうとすると必然的にC99になるからそうでもないと思うが

776:デフォルトの名無しさん
09/03/28 10:58:12
それなら C99 を「知っている」のではなく「規格票にアクセスできる」ことが資格というべきではないか？

777:デフォルトの名無しさん
09/03/28 10:59:29
# 今日はここまで、遊びに出かける

778:デフォルトの名無しさん
09/03/28 11:00:14
でも最低でも>>770くらいのことは知っておいて欲しい

779:デフォルトの名無しさん
09/03/28 12:46:04
コンパウンドリテラルとか便利だけどね。
ただどれがGCC拡張か規格機能なのかよく分からないことがよくある。
それよか、API文章をC99対応にしないと広まらないだろう。
とくにMSDNが率先してC99に対応しないとGNU方面の人たちだけになるんじゃないか？
MSはカオスだしそのうち空中分解しそうだけど。

780:デフォルトの名無しさん
09/03/28 13:42:40
>>779
> MSはカオスだしそのうち空中分解しそうだけど。
突然それまでの話と関係ない一言を最後に入れるあたり、天声人語かと思った

781:デフォルトの名無しさん
09/03/28 13:58:20
コンパウンドリテラルはC++にも欲しい

782:デフォルトの名無しさん
09/03/28 14:24:48
コンストラクタ主義と
コンパウンドリテラルは合わない。

デフォルトコンストラクタのみなら、
リスト初期化子の記法で何とかなりそうではあるけど。

783:デフォルトの名無しさん
09/03/28 14:28:01
配置newで乗り切る。

784:デフォルトの名無しさん
09/03/28 15:09:28
配列のコンパウンドリテラルの代わりになるものは
C++0xにあるんだっけ？

785:デフォルトの名無しさん
09/03/28 15:36:26
まだバタバタしてますがこれ。
Initializer List
URLﾘﾝｸ(www.open-std.org)

initializer-list constructorってのがあって(以下上の提案参照

786:デフォルトの名無しさん
09/03/28 21:27:50
C90に準じていても、それをゆるさない車載標準規約であるMISRA-C。
マジでうざい規約です・・・

787:デフォルトの名無しさん
09/03/28 22:21:01
>>785
かなりバタバタしてる雰囲気がするねw

788:デフォルトの名無しさん
09/03/29 09:28:51
union { char a[4]; int i } u;

というような共用体があったとき、
u.a[0]～u.a[3]に代入した後、それをu.iで参照するのは未定義でしょうか？
6.5のeffective typeの説明を読む限りではそうなってしまいそうなんですが。
未定義でないとすると、その根拠は規格のどの辺で規定されています？

789:デフォルトの名無しさん
09/03/29 10:43:24
The effective type of an object for an access to its stored value ... ってとこ？
どこに未定義って書いてある？

790:デフォルトの名無しさん
09/03/29 11:11:42
> 4. 規格合致性
> この規格では，このほかに，用語“未
> 定義の動作”を使うことによるか又は動作の明示的な定義を与えないことによって未定義の動作を示すこ
> ともある。

791:デフォルトの名無しさん
09/03/29 11:13:29
>>788
参照はして構わない。値は未定義。

792:デフォルトの名無しさん
09/03/29 12:31:08
多くの実装ではこちらが期待したとおりのビット列として読み出すことができる
しかし規格上は、ある型で与えた値を別の型で読み出せることは保障していない

結論：自己責任

793:デフォルトの名無しさん
09/03/29 12:49:17
>>792
実装の説明には書かれているものなのかな？
たとえば、gccとか。

794:デフォルトの名無しさん
09/03/29 12:54:16
規格で保証してないことを保証してるなら、書いてあることもある。

gccでは保証してないどころか、予想だにしない結果になるんじゃなかったっけ？
-O2 とかだと。

795:デフォルトの名無しさん
09/03/29 13:04:43
いやalignとかpaddingとかオプションで指定できるし。> gcc
それにconfigureで確かめたり、実行時にassertしたりできるでしょ。

ただ何がやりたいのか不明だけど、勝手に想像すると、今時のマナーでは、
#include <stdint.h>
union { uint8_t a[4]; int32_t i; } u;
とするんじゃないのかな。

796:デフォルトの名無しさん
09/03/29 13:08:39
何が今時なのか分からん。

797:デフォルトの名無しさん
09/03/29 13:12:49
sizeof(int) == 4と仮定しない方がいい→今時

798:デフォルトの名無しさん
09/03/29 13:13:10
>>796
サイズが同じなら、予想した動作になるってことかな？

799:デフォルトの名無しさん
09/03/29 13:13:53
charとuint8_tが等価なのも今時なのか？

800:デフォルトの名無しさん
09/03/29 13:18:32
粘着乙

801:デフォルトの名無しさん
09/03/29 13:54:11
char だと 0x80 の値が使えないかもしれないジャマイカ

802:デフォルトの名無しさん
09/03/29 13:57:04
charが9ビット以上である可能性がな・・・

803:デフォルトの名無しさん
09/03/29 13:57:58
>>801
いや、もともとcharで切ってたならcharとしての使い方しかしないでしょ。
なんでuint8_tにするの？ってことなんだけど。

804:デフォルトの名無しさん
09/03/29 14:11:03
>>803
何言っているか意味がわからんが？

> charとしての使い方しかしないでしょ。

ここはC++スレじゃないぜ？

805:デフォルトの名無しさん
09/03/29 18:55:14
C++が何で関係あるのか分からんが
もともとcharで切ってる事自体、
本当によく考え抜かれたものか怪しいことは確か

806:デフォルトの名無しさん
09/03/29 19:05:34
結局 >>788 批判ですかｗ

807:デフォルトの名無しさん
09/03/29 20:06:01
C++が何で関係あるのか分からんやつは答えなくてよろし

808:デフォルトの名無しさん
09/03/29 21:02:11
みなさま、ご回答ありがとうございます。
intとcharは例が悪かったかも知れませんが、
相談の主旨は

union U { t1 m1; t2 m2; } u;

（ただしt1とt2はcompatibleでない）

に対して、u.m1に書き込んだ値をu.m2で読み込んだときの
言語仕様についてでした。
例だと、

uの表すobjectのeffective typeはunion U
u.m1の表すobjectのeffective typeはt1
u.m2の表すobjectのeffective typeはt2

になるわけですが、u.m1とu.m2の表すobjectが同じものと考えれば、
1つのobjectがt1とt2という2つのeffective typeを持つ。
だから、u.m1に書き込んだ値をu.m2で読み込むのは許される。
ただし、読み込まれる値については未規定である。

という理解でよいのでしょうか？

809:デフォルトの名無しさん
09/03/29 22:29:36
そだね。

810:デフォルトの名無しさん
09/03/29 22:32:37
CとC++でcharの扱いが全く違うことは、
まあスレ違いなんで知らなくてもいいけど、
Cのcharがintegral typeでintegral promotionの対象、
ANSIでも"as is"が認められているだけってことは知っておかないと。

811:デフォルトの名無しさん
09/03/29 23:44:30
>>809
適当なことを言わないように

812:デフォルトの名無しさん
09/03/31 08:00:10
Cの言語仕様というと、俺はいまだにK&Rなんだが。

813:デフォルトの名無しさん
09/04/01 22:59:50
>>788
どうせおもいっきり環境依存なんだから、
面倒なことしないで、
char a[4]; にセットして
*(int*)a で読んじゃえ。

814:デフォルトの名無しさん
09/04/01 23:08:51
>808
> になるわけですが、u.m1とu.m2の表すobjectが同じものと考えれば、
とあるが、共用体のメンバに対応するオブジェクトはすべて同じなのか？
大きさも型も違うのに。

むしろ同じアドレスだけど、オブジェクトは別と考えるのが自然だと思う。

815:デフォルトの名無しさん
09/04/01 23:15:21
static_assert(期待通りの値が入ってるかどうか) をどっかに入れておけばいい。

816:デフォルトの名無しさん
09/04/01 23:15:40
>>813
strict aliasing rule違反じゃね？どうなの？

817:デフォルトの名無しさん
09/04/01 23:30:28
>>816
大丈夫なCPUとダメなCPUがある。
x86系は大丈夫。

逆の方が適用可能な範囲が広いか。
int a; を ((char*)&a)[0～3] で書く。

818:デフォルトの名無しさん
09/04/02 02:58:14
>>816
違反。

逆に int a; を用意して (char*)&a 経由でセットし、その後 a を読むのなら OK 。

819:デフォルトの名無しさん
09/04/05 00:23:29
なんでC言語には累乗計算の為の演算子がないのですか？

820:デフォルトの名無しさん
09/04/05 00:43:38
累乗計算命令を積んでるCPUが少ないからだ