C言語なら俺に聞け 157

2021/06/28(月) 11:22:51.50

!extend:checked:vvvvv:1000:512
(新スレ立ての際上記コマンドを2行書き込んでください)
C言語の話題のみ取り扱います C++の話題はC++スレへ
質問には最低限の情報(ソース/コンパイラ/OS)を付ける
数行で収まらないソースは以下を適当に使ってURLを晒す
https://paiza.io/
https://ideone.com/
http://codepad.org/

C11
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf

C99
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
http://kikakurui.com/x3/X3010-2003-01.html

C FAQ 日本語訳
http://www.kouno.jp/home/c_faq/

JPCERT C コーディングスタンダード
https://www.jpcert.or.jp/sc-rules/

※前スレ
C言語なら俺に聞け 156
https://mevius.5ch.net/test/read.cgi/tech/1601271690/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2021/12/13(月) 03:50:46.86

>>973
あともう１点念のため。
その例 a = i++ + ++i は未定義動作になる例として適切なんだけど、未定義動作になる理由は >971 の規定であって、
>961 の「評価順序によりaに入る値が変動する場合」というような理由じゃない。
例えば a = (i = 0) + (i = 0) は、どっちの i = 0 を先に評価しても a に入る値は 0 で変動しないけど、未定義動作となる。

2021/12/14(火) 17:26:28.72

自作ライブラリのヘッダと標準関数のヘッダの読み込み順って
なにか決まりごとはあるの？

#include "jisaku.h"
#include <stdio.h>
ってやってたらキモイって言われたんだけど、これなんかおかしいか？

インクルードガード利いてるし順番なんてどうでもいいだろっていうか
だったら自作のヘッダが先に来るべきだろって思うんだけど

2021/12/14(火) 18:00:24.76

>>975
たとえば assert.h を #include する前にマクロ NDEBUG が定義されていると assert が無効になるといったように
動作の切り替えをするマクロというものが存在する。
標準ではそういうマクロは下線で始まる名前になってることが多いから自分のコードの中の名前がたまたま衝突するということは
そうそうないんだけど、各処理系やライブラリに固有の切り替え用マクロが雑な短い名前だったら意図せず影響を与えるかもしれない。

単なる習慣としてもプロジェクト内のヘッダは後に書くのが定着しているね。

2021/12/14(火) 18:01:10.76

ユーザー先だと、標準的な関数やdefineが定義済みになって不具合が出るかもしれないし
一般的な方から読み込んだほうがいいのでは?

2021/12/14(火) 18:42:48.59

なんか本の著者は自作モジュールを先にインクルードするって言ってたな
理由はそのほうがコンパイルエラーが早くなるかららしい

2021/12/14(火) 19:01:07.43

>>976-978
なるほど

若い時分なら「そんなの間違ってる！俺が世界を正す！」って言ってたかもなぁ
とりあえず自分ヘッダは後ろで読むようにするわ

2021/12/14(火) 19:56:33.18

コンパイルエラーが無くなってもバグは残るからなあ

2021/12/14(火) 21:37:05.35

>>977
標準ヘッダを後に書くと
衝突したとき標準ヘッダ側がエラーとして表示されるからな

2021/12/14(火) 22:16:45.94

>>979
決断に水を差すことになるかもしれないけど、↓のベストアンサーでは自作ヘッダが先だよ。
https://stackoverflow.com/questions/2762568/c-c-include-header-file-order

2021/12/14(火) 22:26:46.15

くだらねえ
単に依存関係ってだけのことだろ
一概にどっちが先であるべきだなんて押しつけは糞食らえだ

2021/12/14(火) 23:19:28.66

以前のサイトだと
標準ライブラリ
業務共通ライブラリ
個別ライブラリ
の順にインクルードしなさいと決められてた

2021/12/15(水) 00:55:34.24

まぁ、これも他のスタイルと同じで、どっちがいいというよりは単純なルールで統一されていることが重要なものと思ってる。

2021/12/15(水) 05:27:05.50

押しつけはやる気と引き換えだ
そのコストに見合う理があるべき

2021/12/16(木) 11:05:28.00

ヘッダのインクルードは全て .c の側でやる (ヘッダ内でインクルードしない) という流儀もある。
既にほとんど滅びた流儀だろうし、現代的ではないと断っておくがこの考え方を取るのであれば
インクルードの順序は重要になる。

// foo.h
struct foo{};

// bar.h
// ここで foo.h や stdint.h をインクルードしない
void bar(foo, uint32_t);

// bar.c
#include <stdint.h>
#include "foo.h"
#include "bar.h"
void bar(foo x, uint32_t y) { printf("bar\n"); }

// main.c
#include <stdio.h>
#include <stdint.h>
#include "foo.h"
#include "bar.h"
int main(void) { struct foo x; bar(x); }

メインの側で適切な順序にしないといけないから抽象不足だが、
インクルードガードしてても読み込んでプリプロセスの手順を通すという処理は発生してしまうので
それすらも最低限であるのが好ましいなどの思惑があるのだと思う。
(いまどきのコンパイラではインクルードガードのパターンを検出して
二度目にはファイルを読むことすらしないものもあるらしい。)
まあリソースをケチるのが正義だった昔の話やね。

2021/12/18(土) 21:34:42.48

test

2021/12/23(木) 19:14:59.61

レジスタから「値を読みだす」というのは「値をコピーする」と同義ですか？

2021/12/24(金) 05:09:46.99

なんか違和感ある言い方だな
「読む」とはCPUへの入力、「書き込む」がCPUからの出力で
たとえばメモリリードはメモリからの出力、メモリライトはメモリへの入力を意味する

「コピー」はそれで合ってる
「ムーブ」になる場合は必ずそう断るから

2021/12/24(金) 05:42:34.84

>>990
たとえば

int a = 1;
int b = a + 2;

この「a + 2」の「a」の部分はメモリリードしてるということですよね
このとき計算のためにCPUに値を入力（コピー）しているという理解で合ってますか？

2021/12/24(金) 05:43:27.34

レジスタからの読み出しは読み出しという操作自体に副作用がある(レジスタに対する読み出しを検知してデバイスが何かを行う)場合があるので, 必ずしも同義とは言えない

2021/12/24(金) 05:58:42.33

>>991
合ってる

2021/12/24(金) 06:05:01.87

>>992
>>993
ありがとうございました

2021/12/24(金) 06:43:15.91

>>991
＞CPUに値を入力

レジスタはCPUなのかメモリなのか
int a = 1;
int b = a + 2;

これがアセンブラだと
mov ax,1
add ax,2
mov ptr[b], ax
メモリに書き込んでるのは3行目しかないが

2021/12/25(土) 01:01:40.65

>>995
アセンブラよくわからないんですが

mov ax, 1 // axレジスタに1をコピー
add ax, 2 // axレジスタの値に2を加算
mov ptr[b], ax // axレジスタの値をptr[b]にコピー

でしょうか
ptr[b]っていうのはなんですか？

2021/12/25(土) 01:29:37.77

最適化で変数aがレジスタに充てられてるんだな
最適化を抑制すれば
mov ax,1
mov ptr[a], ax
mov ax, ptr[a]
add ax,2
mov ptr[b], ax
とかになるんじゃね

2021/12/25(土) 11:51:05.24

#include <stdio.h>

2021/12/25(土) 11:51:41.94

int main(void)
{
　printf("good-bye 157\n");

2021/12/25(土) 11:52:11.17

}
/*このすれは終了しました*/

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 180日 0時間 29分 20秒