【初心者お断り】ガチ ..
666:デフォルトの名無しさん
09/01/26 01:01:17
>>658-659
inline void func();
これを(*func)と関数ポインタで使うときどうなるんでしょうか？
例えばqsortに渡したりするときも、qsortみたいな関数ポインタを受け付けるAPIは実行時評価が目的の設計なので、
インライン展開されると不都合な気がするんですけど。
static関数もファイルスコープにおいて展開されるのは初耳だったんですけど、同じように実行時に不都合がありませんか？
667:デフォルトの名無しさん
09/01/26 01:20:20
memcmp、strcmp、strncmpの返値だけど
The memcmp function returns an integer greater than, equal to, or less than zero,
accordingly as the object pointed to by s1 is greater than, equal to, or less than the object
pointed to by s2.
これはつまり、a > b > c だとしても、
memcmp(a, b, n)で100を返し、memcmp(a, c, n) で1を返してもいいんですよね？
0より大きいか小さいかだけが問題で。
accordinglyってのは、「大きい小さい等しい」に従うだけで
数値に従う必要はないですよね？
668:デフォルトの名無しさん
09/01/26 01:21:53
うん。
669:デフォルトの名無しさん
09/01/26 01:29:38
>>666
上で誰かが書いていたと思うけど、必要なら普通の関数のコードも併せて作るだけ。
670:デフォルトの名無しさん
09/01/26 05:22:44
>>669
私だよん。
>>666
たまにはアセンブリ出力を眺めてみるもんだよ。
個々の行の意味が判らなくても、全体のボリュームとシンボルの位置でいろんなことが見えてくる。
>>667
その通り。実際、1,0,-1しか返さない処理系もあった筈だし、
最初に不一致だったバイトの差分を返す処理系もあった筈。
671:デフォルトの名無しさん
09/02/14 05:16:14
ctype.h の関数を手持ちの char について使いたいときは、 char が符号付の場合を考慮して
unsigned char にキャストしないといけないことを理解しました。
でも toupper() の戻り値 int は引数と同じ範囲の値を取るので、そのまま char に戻すことが
できないように思います。
たとえば char 型の変数 c について、以下の条件をすべて満たすとき。
- (unsigned char)c == UCHAR_MAX
- UCHAR_MAX > CHAR_MAX
- toupper(UCHAR_MAX) == UCHAR_MAX ※変換なし
c = toupper((unsigned char)c) という式は char には収まらない UCHAR_MAX を
char に変換することになり、符号付整数のオーバーフローにより未定義動作と
なってしまいそうです。
任意の char 型の値を大文字に変換して結果を char 型で得る方法として、
未定義動作も実装依存も回避した移植性のある方法はあるのでしょうか？
現実的には黙って char に変換すればいいように実装されてることが期待できるとは
思うのですが、ちょっと気持ち悪いです。
672:デフォルトの名無しさん
09/02/14 07:29:40
なんか、とても杞憂な気がするるが、神経質にするならこうか？
c= isalpha((unsigned char) c) ? toupper((unsigned char)c) : c;
673:デフォルトの名無しさん
09/02/14 07:42:03
気になってるのは、大文字アルファベットの表現がsinged charで負値になる環境とかだよね。
全く規格確認してないが、intの戻り値retについて、
CHAR_MINが負値でretがCHAR_MAXを超える場合、
自力でunsigned charをcharに変換するコードを書けば
とりあえず解決するんじゃね？
1バイト文字の英数がASCIIで無い処理系ってあんま想定したこと無いから分からないけども、
「ASCIIじゃなきゃダメ」って記述は規格には無かった気がするなぁ。
詳しい人フォローよろしく。
674:デフォルトの名無しさん
09/02/14 07:44:12
fgetc() なんかも同じだよね。とりあえず EOF をチェックして、それが済んだら char として
扱いたいんだけど、変換できるの？っていう。
675:デフォルトの名無しさん
09/02/14 09:13:41
>>671
そもそも規格上は unsigned char を signed long するだけでだめなケースがあるから
> 未定義動作も実装依存も回避した移植性のある方法はあるのでしょうか？
の答えは「ない」だよ。
>>673
> 「ASCIIじゃなきゃダメ」って記述は規格には無かった気がするなぁ。
汎用機用の C言語処理系で文字コードが EBCDIC のものがある。
676:デフォルトの名無しさん
09/02/14 09:45:53
>>671
toupper に正しく小文字を与えれば、正しく大文字になるでしょ？
それ以上のものはないよ
UCHAR_MAXを toupper に与えたらUCHAR_MAXが返るだろうけど、
そもそもなんでその結果を signed char にキャストするの？
UCHAR_MAXを与えるということは signed char じゃなかったんでしょ？
>>674
toupper()やfgetc()の結果をcharと比較したい場合、
charに変換して戻すんじゃなくて、比較先をintにするのが普通では？
int c = fgetc();
if ( c == 'a' ){
…
とか
677:デフォルトの名無しさん
09/02/14 10:11:11
>676
明示的に UCHAR_MAX を与えるわけじゃなくて、unsigned char に変換すると UCHAR_MAX になる値が
char としてあった場合に、unsigned char にキャストしてから toupper に与えた場合とか。
> toupper()やfgetc()の結果をcharと比較したい場合、
比較ならいいけど、char に代入したくなったらどうするの？
例えば、文字列中の小文字を全て大文字に変換する関数 strupper(char*) を定義しようとかいう場合。
やっぱ >672 のように書けってことだろうか。
678:デフォルトの名無しさん
09/02/14 10:13:56
>>676
> toupper()やfgetc()の結果をcharと比較したい場合、
単純比較なんて誰も悩んでないと思うが。
配列に入れて、printf() で出力したい時とか考えつかないわけ？
679:デフォルトの名無しさん
09/02/14 11:51:23
signed char が -127〜127 で文字コードが 0〜255 の環境なら、
処理系は char を unsigned char 固定で扱うようになっているんじゃないのか？
じゃないと char が文字コードを収める事ができるという
最低条件をクリアできないじゃん。
680:デフォルトの名無しさん
09/02/14 11:56:18
>>677
>>unsigned char にキャストしてから toupper に与えた場合とか。
だから、なんでキャストするの？
入力が signed char なら signed char → int に変換されても
UCHAR_MAX はありえない。
入力が unsigned char なら UCHAR_MAX はありうるけど、それは
変換前も変換後も UCHAR_MAX のままでしょ
681:デフォルトの名無しさん
09/02/14 13:17:25
>>680
ふふ、
682:デフォルトの名無しさん
09/02/14 13:24:25
一連のレスで、UCHAR_MAX は一例だと思うよ。
問題は、signed charで表せないのにunsigned charで表せる文字
ではなくて、signed charで負の値になるunsigned charの文字
ではなかろうか。このような文字を安全に
unsigned char から signed charに変換する標準的な方法が無いこと。
もう一つは、toupperの引数は非負が仮定されているので、
toupperの引数は(intだけど)数値としては実質的にunsigned char
を渡す事になる。
この二つの問題が絡み合っているのね。
683:デフォルトの名無しさん
09/02/14 15:38:04
>680
unsigned char 範囲の値を渡せって規格で要求されてるから。
> 9899:1999 7.4
> The header <ctype.h> declares several functions useful for classifying and mapping
> characters. In all cases the argument is an int, the value of which shall be
> representable as an unsigned char or shall equal the value of the macro EOF. If the
> argument has any other value, the behavior is undefined.
684:680
09/02/14 22:52:12
>>683
その文章は知ってるよ。
でもそれは toupper の引数は unsigned char でキャストしろ、って意味.じゃない
signed char を指定した場合で -2 〜 -128 の場合は undefined だよ、って言ってるだけ
(EOFが-1として)
685:デフォルトの名無しさん
09/02/15 00:14:28
実際死ぬケースもあったな。マイナス与えると。
日本語扱うとよくある。
686:デフォルトの名無しさん
09/02/15 00:16:35
> 未定義動作も実装依存も回避した移植性のある方法はあるのでしょうか？
最初っから全部unsigned charにしとけでイナフ
687:デフォルトの名無しさん
09/02/15 00:23:38
>>679 についてはどうなんだ？
688:デフォルトの名無しさん
09/02/15 01:03:33
>>684
未定義動作を回避するのに、 unsigned char にキャストするほかにどうすんの？
689:デフォルトの名無しさん
09/02/15 01:06:46
>>679
basic character set に無い処理系依存の拡張文字の char としての値について、
符号も含めて規定は無いから、負の値が拡張文字に対応しても問題なさそう。
6.2.5 Types p3
> An object declared as type char is large enough to store any member of the basic
> execution character set. If a member of the basic execution character set is stored in a
> char object, its value is guaranteed to be nonnegative. If any other character is stored in
> a char object, the resulting value is implementation-defined but shall be within the range
> of values that can be represented in that type.
690:デフォルトの名無しさん
09/02/15 01:11:07
>684
じゃ、
> signed char を指定した場合で -2 〜 -128 の場合
はどうすれば？
範囲チェックして toupper には渡すなって主張？
>687
0〜255 だというなら確かにそうかもね。
> 9899:1999 6.2.5/3
> If a member of the basic execution character set is stored in a
> char object, its value is guaranteed to be positive. If any other character is stored in a
> char object, the resulting value is implementation-defined but shall be within the range
> of values that can be represented in that type.
という記述を見ると basic execution character set 以外なら負値も認めているように読めるけど、
後は実装依存の闇の中、かな。
691:デフォルトの名無しさん
09/02/15 01:22:17
int toupper(int c);
692:デフォルトの名無しさん
09/02/15 01:22:20
なるほど・・・。
完全に環境無依存のコードは無理っぽいね。
693:デフォルトの名無しさん
09/02/15 01:55:08
卓上の妄想なら不可能だが、現実的にはみんなやってるだろ
694:デフォルトの名無しさん
09/02/15 01:59:26
なんで文字を扱ってるのに符号を気にしなきゃいけないんだよＣ言語のバカ！
695:デフォルトの名無しさん
09/02/15 02:11:42
char の符号が未規定なのって
どんなケースを想定してのことなのだろうか。
符号つきの文字コードがあったらいけないから？
696:デフォルトの名無しさん
09/02/15 02:18:33
8 bit 符号付でも ASCII の表現には十分だから実装任せで良いよね。
っていう話だと思う。
C++ では char を受けて char を返す toupper/tolower があるから、今さら
規格を変更する（変更を検討する）モチベーションも無いだろうしなぁ。
697:デフォルトの名無しさん
09/02/15 04:13:14
リアルタイムの人間じゃないけど。
規格がまとまる前にsigned, unsigned両方の実装が出ていたから、
というのが最大の理由だったと思う。
そこから先は>>696のとおり。
698:デフォルトの名無しさん
09/02/15 09:07:58
int は、ディフォルトで signed なのに、char のディフォルトを決めなかったのが
敗因だと思う。
まあ今時だとメモリも潤沢だからわざわざ char に詰め込もうなんて思わないけど、
当時だと short short int の役目もあったのかもしれないな。
699:デフォルトの名無しさん
09/02/15 10:18:39
MS-ｃがオプションでcharをアンサインドにできる仕様だったからねぇ。
intとは事情が違うね。
700:デフォルトの名無しさん
09/02/15 10:52:13
lattice-c(2のころ)はunsignedだったっけ？
701:デフォルトの名無しさん
09/02/15 11:12:02
>>688
出力を未定義にしたくないなら、未定義にならない引数を与えろってこと。
toupper呼ぶ前に、入力文字の範囲チェックしないってことは無いだろう普通
それを unsigned char へのキャストで済ませられたらいいな、と
考えたのだろうけどそれじゃダメって話
702:デフォルトの名無しさん
09/02/15 11:29:04
>>701
範囲をどうチェックするするべきだと言うの？
チェックで範囲外だとわかったらどうしろっていうの？
toupper() に渡さないと大文字にできんのだが。
703:デフォルトの名無しさん
09/02/15 12:16:42
馬鹿なの？
大文字にしたければ小文字を渡せよ
if( isascii(c) && islower(c)) c = toupper(c);
これを
c = toupper((unsigned char)c);
とすると規格上不定になります（；＿；）とか言ってるから
キャストするからだろ馬鹿、って言ってるんだ
704:デフォルトの名無しさん
09/02/15 12:23:28
大馬鹿なの？ toupper の前に islower なんかいらねーよ
705:デフォルトの名無しさん
09/02/15 12:23:30
>>703
標準の範囲で実装依存せずにどうするかって話なのに、
非標準の isascii() とか入れてみたり勝手に ASCII 大文字だけに要求を絞ったり、
ギャグでやってるのか？
706:デフォルトの名無しさん
09/02/15 12:37:08
いいえ、ボールギャグです。
707:デフォルトの名無しさん
09/02/15 15:08:42
で、実際のところa-z|A-Zが符号付き表現で負になることはありえるの？
708:デフォルトの名無しさん
09/02/15 15:11:34
それは知らないけど、
"C" locale以外ではa-z|A-Z以外でもislower/isupperが真になるということなら有り得ると思う。
709:デフォルトの名無しさん
09/02/15 15:12:31
真になるってどういう事だよ。
710:デフォルトの名無しさん
09/02/15 15:13:04
あ、空目してた。ごめんよ。
711:デフォルトの名無しさん
09/02/15 15:14:32
結局は>>686
712:デフォルトの名無しさん
09/02/15 16:26:35
>>707
そいつらは basic execution character set に入ってるから char 型の符号の有無に
かかわらず負にならないことが保証されてる。 （ >689,690 が引用してる箇所参照）
713:デフォルトの名無しさん
09/02/15 17:39:56
>>712
素朴な疑問、EBCDIC な文字コードの処理系の場合どうなるんだ？
714:デフォルトの名無しさん
09/02/15 18:09:27
>>713 文字コードは関係ない。（ >689,690 が引用してる箇所参照）
715:デフォルトの名無しさん
09/02/15 18:30:21
>>714
EBCDIC って 8bit だと MSB たってんじゃん, char 9bit 以上で実装しろって話？
716:デフォルトの名無しさん
09/02/15 19:33:50
>>699
MS-C はシフトJIS でトラブル奴が多いからそういうオプションを
サポートしただけだろ。
717:デフォルトの名無しさん
09/02/15 19:35:12
>>715 EBCDIC のコードを 8 bit char の値に使うなら char 型を unsigned にするしかないということ。
718:デフォルトの名無しさん
09/02/15 20:08:24
>>717
fgetsやprintfやstrcmpなどの型も全部変更するの?
719:デフォルトの名無しさん
09/02/15 20:11:42
>>718
きっと何か勘違いしてると思うけどそれらの関数でどういう問題が起きると思うの？
720:デフォルトの名無しさん
09/02/15 21:19:58
>>718
unsigned charにするんじゃなくて、
char自体を符号無しにするってことだろ。
721:デフォルトの名無しさん
09/02/15 22:46:22
>>717 ああ、それなら納得
「>>712 char 型の符号の有無にかかわらず負にならない」
てな、書き方はやめてほしかった
722:デフォルトの名無しさん
09/02/26 04:13:51
今現在、charをsignedで使う意味ってあるのかな。
723:デフォルトの名無しさん
09/02/26 15:09:34
>>722
charを文字ではなく数値として使うこと考えれば。
intへの昇格も考えなきゃならんし。
724:デフォルトの名無しさん
09/03/01 00:55:23
Ｃ言語なら俺に聞け（入門篇） Part 45
ｽﾚﾘﾝｸ(tech板)l50
こっちが埋まったんで、とりあえずageておく。
725:デフォルトの名無しさん
09/03/01 03:16:58
あのグダグダを持ち込まれても困るんだが
726:デフォルトの名無しさん
09/03/01 21:51:47
ネタ切れ？ じゃぁ
問題：
int i, j;
int main()
{
i = 1;
j = i++ * i++;
printf("%d, %d\n", i, j);
}
このプログラムを実行するとどうなるか？ どうなるべきか？ 結果もしくは挙動を推測せよ。
（includeとかmainの型なんかは、適宜補え。文句言うな）
727:デフォルトの名無しさん
09/03/01 22:17:00
jの右辺が未定義動作だから何が起こるかわからない
「3,6」と表示されるかもしれないし「3,9」と表示されるかもしれないし
「5196823, -98600289」と表示されるかもしれないし「ｑあｗせｄｒｆｔｇｙふじこｌｐ；」と表示されるかもしれないし
プログラムが異常終了するかもしれないしOSがクラッシュするかもしれないし
PCが火を噴くかもしれないし地球が爆発するかもしれないし鼻から悪魔が出てくるかもしれない
常識だと思うが、今更どうした
728:デフォルトの名無しさん
09/03/01 22:54:37
mainが値を返してないからコンパイルできない
729:デフォルトの名無しさん
09/03/01 22:56:00
C99なら可だが
730:デフォルトの名無しさん
09/03/02 11:15:52
鼻から悪魔は無いな、たぶん。
731:デフォルトの名無しさん
09/03/02 20:09:45
出てきてからじゃ遅いんだよ、出てきてからじゃ。
732:デフォルトの名無しさん
09/03/02 21:31:38
ネタ切れ？ じゃぁ
問題：
int a[32], b[32], *p = a;
if (p < b || b + 32 <= p) printf("悪魔が出る。");
else printf("いずれにせよ悪魔が出る。");
このプログラムの断片について議論して。前後は適当に補ってね。
733:デフォルトの名無しさん
09/03/02 21:50:06
どこにも悪魔は出ないだろ・・・
b + 32 は脱参照しなければ合法だし
ポインタは順序付け可能だ（どういう順序になるかは未規定だが）
734:デフォルトの名無しさん
09/03/02 21:55:05
p < b の大小関係が未規定ゆえ、結果が未定義となる
735:デフォルトの名無しさん
09/03/02 22:14:11
どういう順序になるかは未規定だが
順序付け可能とは定義されてるよ
736:デフォルトの名無しさん
09/03/02 22:14:47
結果は未定義じゃなくて未規定
少なくとも鼻から悪魔は出ない
737:デフォルトの名無しさん
09/03/02 22:17:06
When two pointers are compared,
<ばっさり省略>
In all other cases, the behavior is undefined.
738:デフォルトの名無しさん
09/03/02 22:24:43
未規定の動作が生じうる可能性のうちのいずれかに依存したコードには可搬性があるというのか？
739:デフォルトの名無しさん
09/03/02 22:25:46
ばっさり省略しすぎだろwww
同じ型なら比較可能だ
740:デフォルトの名無しさん
09/03/02 22:28:54
>>739
俺も今6.5.8をみていたところだが
> 同じ型なら比較可能だ
これはどこに書いてある？
741:デフォルトの名無しさん
09/03/02 22:29:03
>>739
同じ型でも違うオブジェクトであればだめだよ。
742:デフォルトの名無しさん
09/03/02 22:40:59
ああ、Cだとダメなのか。
C++だといいからCでもいいのかと思った。
743:デフォルトの名無しさん
09/03/03 21:56:44
>742
C++ でも駄目だろ、と思ったけど未規定なのな。
そして std::less とかだと全順序保証、と。
744:デフォルトの名無しさん
09/03/04 00:43:13
Cだとポインタを二分探索木で管理するには
その先の値を見るしかないのか。
その先の値の順番に特に意味が無くても。
745:デフォルトの名無しさん
09/03/04 00:54:51
>>744
先の値の順番に意味がなかったらなにを基準に木構成する気だ
746:デフォルトの名無しさん
09/03/04 11:51:54
ポインタのアドレスそのもので探索する？
747:デフォルトの名無しさん
09/03/04 13:05:25
連続メモリ空間上のポインタなら二分木で管理するまでもないし
そうでないなら比較の保障がない以前に意味がないだろ
748:デフォルトの名無しさん
09/03/04 13:05:56
×空間上のポインタ
○空間上へのポインタ
749:デフォルトの名無しさん
09/03/04 22:25:15
>>744
この世にはデリファレンスできないポインタも存在するわけだが。
750:デフォルトの名無しさん
09/03/04 23:54:43
int にキャストして比較すれば良いんじゃない
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が少ないからだ
最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5401日前に更新/178 KB
担当:undef