C言語なら俺に聞け 157
レス数が1000を超えています。これ以上書き込みはできません。
>>945 を昨日書いたが、さっきこんなの見つけた。有料だけどな。
JetBrains、リモート開発機能と軽量IDE「Fleet」を発表
https://japan.zdnet.com/article/35180131/ 漏れは、Ruby on Rails, WSL2, Ubuntu 18.04 で、
Web Socket など、Railsで使う各モジュールがネイティブコンパイルされるけど、
build-essential とか入れておけば、
Rails のインストール時に、勝手にコンパイルされる
build-essential には、
gcc(GNU C compiler), g++(GNU C++ compiler), libc6-dev(GNU C Library), make などが入っています
パッケージ: build-essential
https://packages.ubuntu.com/ja/bionic/build-essential
43.0 MB のアーカイブを取得して、165 MB のディスク容量が使われます VS2022に昔のプログラム持ってったら
isspace()とかに80h以上の文字入れると例外になるけど
いいのかこれ
テーブルで処理してて80h以上は負だからテーブル外になるって理由はわかるんだけどさあ
昔のはなんとかうまくやってた気がするんだけど >>954 それ char で負の値を渡してるんじゃね? >>954
int isspace(int c)
ですよ、ちゃんと int の正の数で渡してます?char をまんま渡してたらまずいっすよ
>>956
「unsigned char にキャストして、暗黙の型変換(プロモーション)に頼る」ってかなりアクロバットに見えますね char が符号付か符号無しかは処理系定義で、
符号無しであるような処理系では char が int に拡張されたときに負数になることはない。
(考慮する必要はない。)
C にはそういう処理系定義とか未規定とか未定義がもりだくさんなので
ある処理系の定義では未定義を踏まずに済むプログラムでも
別の処理系では (処理系定義のコンボで結果的に) 未定義に引っかかることはよくある。
C のプログラムで完全に処理系定義や未規定を避けるというのは困難な話だし、
(可能なら環境依存を避けるように意識するのは良い作法ではあるけど)
違う環境に持ってきたらその程度の修正は必要なものだと思って諦めるしかしょうがない。 未規定を避ける必要はない
未規定のブレ幅以内に収まるように書いてあるプログラムは適格
そうでないプログラムは不適格で未定義の動作となるだけだ 違う。
たとえば
int f1(), f2();
int a = f1() - f2();
のようなことをしているとき、
f1とf2の評価順序は未規定
f1とf2の評価順序によりaに入る値が変動する場合は未定義の動作だ 未規定って処理系毎に好きに実装して良いんでしたっけ? 処理系が好きに実装してよいし, ひとつの処理系の中で一貫している必要も, ドキュメントに明記する必要もない >>962
未規定な動作を含むプログラムは正しい。
あり得る動作の内のどれかにはなる。
未定義はどんな保証もない。
未定義の挙動を含むプログラムはプログラム全体がどんな動作をするかわからん。
全然関係ないと思う箇所でわけわからん動作になることもあるし、
未定義を踏んでる箇所より前に問題が表れることもないとはいえない。
>>963
処理系定義は「未規定の動作のうち,各処理系が選択した動作を文書化するもの。」ということになっている。
つまり処理系定義は未規定の一種という扱い。 >>962
処理系どころか同じソースでもコンパイル毎に変えることすら許される >>961
> f1とf2の評価順序によりaに入る値が変動する場合は未定義の動作だ
これは嘘じゃね? >>968
いやあってる
演算子の結合規則・優先順位は、あくまでも複数の演算子があったときにどの演算子を先に処理するか、に過ぎない
オペランドを二つ持つ演算子一つに限れば、どっちのオペランドを先に評価するかは処理系依存だったと思う
これは関数の引数についても同じ >>969
だれも結合優先度の話はしてないと思う。
> f1とf2の評価順序は未規定
これについては未規定で異論は無いんだよ。
> f1とf2の評価順序によりaに入る値が変動する場合は未定義の動作だ
でも、こっちは嘘じゃね?という話。そんな規定文面確認できない。 C17Draftのpp.65 6.5 1では?
> If a side effect on a scalar object is unsequenced relative to either a different side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined.
> If there are multiple allowable orderings of the subexpressions of an expression, the behavior is undefined if such an unsequenced side effect occurs in any of the orderings. >>971
複数の関数呼び出し先にある評価同士、あるいは呼び出し元と呼び出し先にある評価同士は
indeterminately sequenced となり、 unsequenced にはならない。
6.5.2.2 Function calls p10
> ... Every evaluation in the calling function (including other function calls)
> that is not otherwise specifically sequenced before or after the execution of the body of the called
> function is indeterminately sequenced with respect to the execution of the called function. 96)
...
> 96) In other words, function executions do not “interleave” with each other.
>961 の f1, f2 は関数なので、 f1() - f2() の結果が未規定だからといって未定義動作にはならない。 >>972
OK, 関数呼び出しを噛ませたことで評価順序が未規定ではなく不定(一方が他方の後(先)であることは保証される)になるので, 呼出先関数で副作用があっても(結果は未規定だが)未定義動作ではない, と
確かによくある a = i++ + ++i; みたいな例が適切だったか >>973
あともう1点念のため。
その例 a = i++ + ++i は未定義動作になる例として適切なんだけど、未定義動作になる理由は >971 の規定であって、
>961 の「評価順序によりaに入る値が変動する場合」というような理由じゃない。
例えば a = (i = 0) + (i = 0) は、どっちの i = 0 を先に評価しても a に入る値は 0 で変動しないけど、未定義動作となる。 自作ライブラリのヘッダと標準関数のヘッダの読み込み順って
なにか決まりごとはあるの?
#include "jisaku.h"
#include <stdio.h>
ってやってたらキモイって言われたんだけど、これなんかおかしいか?
インクルードガード利いてるし順番なんてどうでもいいだろ っていうか
だったら自作のヘッダが先に来るべきだろ って思うんだけど >>975
たとえば assert.h を #include する前にマクロ NDEBUG が定義されていると assert が無効になるといったように
動作の切り替えをするマクロというものが存在する。
標準ではそういうマクロは下線で始まる名前になってることが多いから自分のコードの中の名前がたまたま衝突するということは
そうそうないんだけど、各処理系やライブラリに固有の切り替え用マクロが雑な短い名前だったら意図せず影響を与えるかもしれない。
単なる習慣としてもプロジェクト内のヘッダは後に書くのが定着しているね。 ユーザー先だと、標準的な関数やdefineが定義済みになって不具合が出るかもしれないし
一般的な方から読み込んだほうがいいのでは? なんか本の著者は自作モジュールを先にインクルードするって言ってたな
理由はそのほうがコンパイルエラーが早くなるかららしい >>976-978
なるほど
若い時分なら「そんなの間違ってる! 俺が世界を正す!」って言ってたかもなぁ
とりあえず自分ヘッダは後ろで読むようにするわ >>977
標準ヘッダを後に書くと
衝突したとき標準ヘッダ側がエラーとして表示されるからな くだらねえ
単に依存関係ってだけのことだろ
一概にどっちが先であるべきだなんて押しつけは糞食らえだ 以前のサイトだと
標準ライブラリ
業務共通ライブラリ
個別ライブラリ
の順にインクルードしなさいと決められてた まぁ、これも他のスタイルと同じで、どっちがいいというよりは単純なルールで統一されていることが重要なものと思ってる。 押しつけはやる気と引き換えだ
そのコストに見合う理があるべき ヘッダのインクルードは全て .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); }
メインの側で適切な順序にしないといけないから抽象不足だが、
インクルードガードしてても読み込んでプリプロセスの手順を通すという処理は発生してしまうので
それすらも最低限であるのが好ましいなどの思惑があるのだと思う。
(いまどきのコンパイラではインクルードガードのパターンを検出して
二度目にはファイルを読むことすらしないものもあるらしい。)
まあリソースをケチるのが正義だった昔の話やね。 レジスタから「値を読みだす」というのは「値をコピーする」と同義ですか? なんか違和感ある言い方だな
「読む」とはCPUへの入力、「書き込む」がCPUからの出力で
たとえばメモリリードはメモリからの出力、メモリライトはメモリへの入力を意味する
「コピー」はそれで合ってる
「ムーブ」になる場合は必ずそう断るから >>990
たとえば
int a = 1;
int b = a + 2;
この「a + 2」の「a」の部分はメモリリードしてるということですよね
このとき計算のためにCPUに値を入力(コピー)しているという理解で合ってますか? レジスタからの読み出しは読み出しという操作自体に副作用がある(レジスタに対する読み出しを検知してデバイスが何かを行う)場合があるので, 必ずしも同義とは言えない >>991
>CPUに値を入力
レジスタはCPUなのかメモリなのか
int a = 1;
int b = a + 2;
これがアセンブラだと
mov ax,1
add ax,2
mov ptr[b], ax
メモリに書き込んでるのは3行目しかないが >>995
アセンブラよくわからないんですが
mov ax, 1 // axレジスタに1をコピー
add ax, 2 // axレジスタの値に2を加算
mov ptr[b], ax // axレジスタの値をptr[b]にコピー
でしょうか
ptr[b]っていうのはなんですか? 最適化で変数aがレジスタに充てられてるんだな
最適化を抑制すれば
mov ax,1
mov ptr[a], ax
mov ax, ptr[a]
add ax,2
mov ptr[b], ax
とかになるんじゃね int main(void)
{
printf("good-bye 157\n"); このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 180日 0時間 29分 20秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。