C言語なら俺に聞け 150

2019/02/06(水) 13:39:03.21

↑
次スレを作る時は上記1行をコピーして2行に増やして必ず1行目に入るようにしてください。

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言語なら俺に聞け 149
https://mevius.5ch.net/test/read.cgi/tech/1540731704/

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

2019/02/21(木) 20:29:14.38

「100までの素数」は単にロジックが書けるかどうかの話で、素数の話ではないだろうに。

2019/02/21(木) 20:33:10.06

配列に数字を並べて表示するだけの処理の何処にロジックがあるのやら
あれではただのゴリ押しだ

2019/02/21(木) 20:52:13.17

誰かがこの問題から実務向きかどうかがわかる、なんて言うからいけない

2019/02/21(木) 21:00:34.34

最近知ったことだが、clangとclang++には、-pedantic -Wallの他に-Weverythingというオプションがある。これを使えば最大限に警告してくれる。

2019/02/21(木) 21:25:46.65

とりあえず、Cできない娘は受付時に言うとか、ホームページにわかるようにしてくれないとキツイ。

2019/02/21(木) 21:49:34.71

ロジックはアタマの中に

2019/02/22(金) 11:10:49.03

>192
「オッケーグーグル、『100以下の素数を表示するブログラム』を端末にダウンロードして！」

2019/02/22(金) 15:27:06.91

С言語

2019/02/22(金) 15:32:39.50

偶素数と奇素数

2019/02/22(金) 21:00:52.74

C言語とか勉強じゃなくて仕事だったり動くもの作らないと覚えられないと思うんだけど
何をすることでC出来るようになったの？

2019/02/22(金) 21:11:58.58

勉強だったとしても動くもの作り続ければだろうよ

2019/02/22(金) 21:52:23.52

納期までに完成させないと大変な事になるというスリルとサスペンスが人間の能力を引き出すのです。
しかしこれは恐怖から逃れようとする行為なので恐怖がなくなる、または度胸がついてしまったらそこで終わりです。

2019/02/23(土) 16:48:48.66

#defineじゃなくてconstすすめてくるやつは机上の空論だな
constつかったら最適ななしにするとswitchのラベルにつかえないじゃないか

2019/02/23(土) 17:14:59.00

>>263
C++ では const 変数を case ラベルに使えるから、混同してる人かも。

2019/02/23(土) 17:46:54.59

C なら「名前のついた整数」は enum だね。
スコープ効くし case のラベルにも配列定義の要素数の指定にも使える。

2019/02/23(土) 20:56:53.69

Cのenumはenum-baseがないから
どでかい定数には使えない

2019/02/23(土) 21:13:59.35

enumはあくまで値の大小は関係なくユニークな識別子であって、大きな値が問題になるような用途に使うのはいかがなものか。

2019/02/23(土) 21:41:02.60

プリミティブな定数以外のスイッチって
ものすごく気持ち悪いんだが

長大数渡して色々工夫してスイッチするのと
似たようなことコンパイラがやらなきゃいかんよね

2019/02/24(日) 07:48:44.15

C の enum は「互いに区別できる一群の整数値の組」で、
具体的な値にさほど拘らない用途で使うべき、っていう
言語機能のそもそも論を言われると、その通りなんだよな。

その意味では case のラベルに enum の値を使うのはいいけど、
配列定義の要素数で使うのは便利にコキ使いすぎ、って感じか。
実際のところ enum で表現できる値の範囲が、
配列の要素数指定に使える範囲(size_t)と一致するか、という
疑問を持って調べたけど、いまいちハッキリせず今も解消してない。
まぁ、それ言うと case ラベルで受け入れられる値の範囲が
enum の範囲と同じか、についても確信ないんだが。

(権威主義に逃げ込む気はないと事前に言い訳した上で)
#define のマクロ値の代わりに enum の値を使うってのは、
カーニハンとパイクの『プログラミング作法』第1章、
「1.5 マジックナンバー」で紹介されてることを付記しておく。

2019/02/24(日) 08:31:42.99

enum
{
a = 4294967297
};

int main()
{
printf("%d\n", sizeof a);
printf("%llx\n", a);
}

gcc:
8
100000001

cl:
4
1

どっちが正しい？
とりあえずはコケるほうに合わせるが

2019/02/24(日) 08:40:26.06

以前に組込み用途の8bitマイコン用C言語を使っていた時の話
CPUの機能的にint型は8bitだった
ところが多条件の分岐処理でif-elseを使った時よりenum変数のswitch文使った方が明らかにパフォーマンスが
低下して問題になったことがあった
訳が分からず逆アセンブルして調べてみるとenum変数は何故か16bitに展開されていて条件判定毎に型変換が
発生していたことが原因だっということがあった、という昔の思い出

2019/02/24(日) 13:48:01.77

>>271
int が 8bit という時点で仕様に反しているので
整数演算のいろんなところで暗黙に int に変換してから
計算する C のルールが破綻するんじゃなかろうか。

処理系が必ずしも言語の規格に完全準拠する必要はないけど、
基本的な部分で変えちゃうとどういう挙動になるのか
予想しづらいよな。

2019/02/24(日) 14:00:01.86

charがその処理系の最小bit数であることだけは仕様に明記されてるけど
それ以外の整数型は大小関係だけが規定されていてintそのものに
具体的なbit数の決まりはなかったんじゃなかったっけ？
実際その時もchar、short、intが8bitで、longが16bitだったと思う

2019/02/24(日) 14:04:53.91

>>270
C ではこういうルールになっている
・列挙定数の値を定義する式は int 型で表現可能な値を持つ整数定数式でなければならない
・列挙体 (列挙型のオブジェクト) の大きさは要素の全てを保持可能な大きさをもつ
　がその選択は処理系定義である。
・列挙定数の型は (列挙型ではなく) int である

つまり、 C では列挙体と列挙定数の型が異なり、
列挙定数の型は int そのもの。
それは単に int の大きさがそれぞれ違うってだけじゃないの？
だとするとどちらの挙動も仕様通り。

(余談だが C++ では列挙定数の型は列挙型なので、 C とは少し解釈が違う。)

2019/02/24(日) 14:05:53.36

>>273
気持ちとしては賛成したいんだが
残念なことにISO/IEC9899 5.2.4.2.1 Sizes of integer types <limits.h>に、
INT_MAX +32767と書いてあるんだ
腹立たしいクソ規定だがそうなっている

2019/02/24(日) 14:15:23.84

>>273
ビット数という形ではないが、
limits.h で定義される各整数型が表現可能な数値の範囲を表すマクロ
についての最低限度の値という形で間接的に定義されている。
C99 だと 5.2.4.2.1 にある。
int は実質的に 16bit は必要。

2019/02/24(日) 15:01:36.58

整数型をワードより大きくしなきゃいけない
なんてなったら使い物にならんよな

2019/02/24(日) 16:23:47.05

確かにint型は規格的には最低16bit必要みたいだなぁ

C11 N1570 draft
5.2.4.2.1
―int型オブジェクトの最低値
INT_MIN -32767 // -(2^15 - 1)
―int型オブジェクトの最大値
INT_MAX 32767 // 2^15 - 1
6.2.5.5
「単なる」int型オブジェクトは実行環境のアーキテクチャにとって自然な（<limits.h>ヘッダに定義されたINT_MINからINT_MAXまでの任意の値を含むに十分大きい）サイズをもつ。

2019/02/24(日) 16:36:11.63

>>271
そのせいで組み込みでswitch使うな伝説が発生したんだな
逆に16ビット以上なら使っても問題ないということか

2019/02/24(日) 16:49:38.07

言語規格そのものというより標準ライブラリの都合というかヘッダーの仕様だけのような気がするけど
limit.hで最大値と最小値を規定するのであれば-128と127を宣言すればintの範囲を変更した実装も可能ではあるな
厳密には問題があるかも知れないけどC99準拠の実装と言うことでお茶を濁している処理系はあり得そうだ

2019/02/24(日) 19:23:23.70

>>279
組み込み市場的に8ー16bitが主流だけどな。

2019/02/24(日) 22:09:42.91

一時期、組み込みもLinuxに席巻されそうになったこともあるけど昨今のIoTブームで16bit以下の超省電力が復権してきたイメージあるわ。

2019/02/24(日) 22:14:44.36

でもそういう機器ってメモリの読み書きしかすることねえもんな。
あんまりおもろない。

2019/02/24(日) 22:24:41.13

組み込みではLinuxどころかOSすら搭載してないシステムも多いよ
ネット家電なんかの一部を除けばエアコン、冷蔵庫、洗濯機など家電製品の殆どはOSもファイルシステムもネットワークスタックも無縁のスタンドアローン動作
電源投入リセット後ひたすら処理ループを回すだけ
CPUコアは8bitか16bitでRAMは数KB、ROMは数十KB程度のワンチップマイコン

2019/02/24(日) 22:29:53.46

メモリの読み書きよりもIOポートを制御するのがメインの仕事

2019/02/24(日) 22:33:57.82

殆ど電卓だな

2019/02/24(日) 22:41:13.06

電卓ほど単純ではないけどね
まともにフィードバック制御を実装するにはそれなりの演算負荷は掛かる
センサー入力に応じて出力を迅速安定に目標に追従させるには裏では予測判断も必要
マイコン使っている以上は単調なON/OFF制御では無いよ

2019/02/24(日) 22:49:58.22

欲深い人間のことだからどうせすぐいろんなことをさせたくなる

2019/02/24(日) 23:23:28.26

IoTなら制御はサーバー側じゃないの？

2019/02/24(日) 23:28:06.97

Fog computing がキーワードだそうだ

2019/02/25(月) 00:12:03.18

IOポート制御とメモリ読み書きの違いがわからない

2019/02/25(月) 00:27:51.25

メモリーバスが I/O につながってることもあるしな。

2019/02/25(月) 06:19:38.59

>>291
IOポートを弄るにはそれぞれのSFR(特殊機能レジスタ)を操作する
一般的なメモリマップトIO方式ではSFRはCPUの特定のアドレス空間にマッピングされてる
Cプログラムからはそのアドレス空間をそれぞれ適当な変数に割り当てて基本的にはビット操作で制御する
SFRのイメージが分からなければ適当なマイコンのデータシートでも見てみるとある程度は分かると思うよ
参考として電子工作で有名なPICマイコンのサイト貼っておくので見てみるといいよ

2019/02/25(月) 06:22:12.63

ごめん
リンク貼り忘れた
https://www.microchip.co.jp/download/index.php

2019/02/25(月) 07:08:32.40

>>274
だな
あのあとgcc -pedanticとやってみたら
ちゃんと警告出たわ

2019/02/25(月) 07:37:13.02

組み込みマイコンでI/O空間がx86みたいに別なマイコンってあるかな

2019/02/25(月) 07:40:18.98

>>293
だから、区別ないじゃん

2019/02/25(月) 07:52:33.64

メモリ(RAM)に割り当てられた変数は演算とその結果に意味がある
IO(SFR)に割り当てられた変数はビットのR/W操作そのものに意味がある
SFR変数上で演算操作を行うとほぼ確実に誤動作、暴走する

2019/02/25(月) 07:58:55.56

>>297
I/Oポートの挙動はメモリと同じとは限らない
書き込みと読み出しが別のものに繋がっていることもある
volatileは本来このためにある

2019/02/25(月) 08:52:03.76

本当か？
揮発性だぞ

2019/02/25(月) 08:52:04.55

>>296
あるよ。AVRはメモリマップされたIO空間にin/out命令で効率的にアクセスできる。

2019/02/25(月) 10:42:31.86

>>299
READアクセスでSR、WRITEアクセスでCRというケースは珍しくないが
なんで突然volatileが出てくるんだ？　全然関係ないぞ

2019/02/25(月) 11:12:53.53

Read動作を確実に実行するためだろう
プログラム上はSFR変数からダミー変数への代入にしか見えないので何の演算にも関与しないと判断されて
コンパイル時の最適化で処理が削除される恐れがある
SFR変数はvolatile宣言しておくのが普通

2019/02/25(月) 11:41:24.89

それはREADの回数やタイミングの話だろ
READとWRITEで対象が異なる場合があることと何の関係があるんだよ

2019/02/25(月) 11:52:53.97

そこに拘っていたのか
てっきりメモリとIOによる変数の扱いの注意点のことかと思っていたわ

2019/02/25(月) 11:58:40.63

volatileなしだと、同じsfrにwriteした直後にreadすると最適化により実際にはreadされないことがある。

2019/02/25(月) 12:03:53.38

メモリとIOは違うっていっても、要は裏でなんかやってるだけだし。
だからvolatileなんて話も出てくる。

2019/02/25(月) 12:15:38.73

>>305
他に何に拘っていると言うんだ？

> 書き込みと読み出しが別のものに繋がっていることもある
　↑
　何の関係があるんだ
　↓
> volatileは本来このためにある

答えるか撤回かどうなんだ

2019/02/25(月) 12:41:00.22

>>308
>>306

2019/02/25(月) 12:44:45.62

>>309
306は話のすり替えだ
READの回数やタイミングの話なんかしていない
READとWRITEの対象が違うということについてだ
volatileと何の関係があるのか
ただの言い間違えか
どっちだ？

2019/02/25(月) 12:48:10.76

>>310
CRにwriteした直後に同じアドレスのSRをreadした時に最適化され、write値がそのままread値に使われるのをvolatileなしでどうやって回避するのん？

2019/02/25(月) 12:49:09.15

>>308
横からだけど>>305の２行目ぐらい読んでやれよ
それとも俺様に謝らないと許せないってか？ w

2019/02/25(月) 12:53:40.05

>>308
知らんがな、>>299本人に聞けよ
一般に言えることはメモリ上の変数の場合は読み込みと書き込みの間には必ず何らかの関連性を持っている
意味もなく読み込みや書き込みを行うことはなくその値は必ず何処かで利用される
利用されなければ変数もろとも普通は最適化で削除される
SFRの変数の場合はRead/Writeその操作の行為そのものが目的であってその結果その値がどうなろうが値そのものには何の意味もない
コンパイラにそのことを明示的に指示する方法がvolatileということ

2019/02/25(月) 12:57:22.86

こうして見るとやはりC言語は組み込み屋専門ということか
話が難しすぎてついていけねえｗ

2019/02/25(月) 12:59:43.43

>>311
という説明ができるの、あんただけみたいだな
頓珍漢なレスばっかでイラついてたわ

2019/02/25(月) 13:15:23.23

>>314
全然難しくはないし、組み込みに限った話じゃないよ。
ただ単に「今見えている処理とは別のとこからそのアドレスの値が更新される可能性があるので最適化しちゃダメよ」ってのを明示的に示すためのvolatileなので。
C#やJavaとかでもスレッドをまたいで不用意にアクセスする変数はvolatileつけないとバグるし。

2019/02/25(月) 13:16:39.48

組込専門、みたいなひとって抽象的な話のできないクソ多いよ。
コードもクソが多い。sleepせずにビジーウェイト使うタイプ。

2019/02/25(月) 13:17:16.26

横レスだけどWrite属性のSFRの値(この場合CR)をReadしても値は不定だけどね
同一アドレスにマッピングされているRead属性のSFRの値(SR)の値が返ってきて変数に代入されているだけ
普通はWrite属性のSFRの状態を記憶する必要があればバッファ変数に内容を保存しておく

2019/02/25(月) 13:49:48.67

write属性なんて用語あったっけ
ゲートだけ出てるのはREでデコード
トーテムポールになってるのをWEでデコード
というのは属性か？

2019/02/25(月) 14:03:17.60

Read/Write属性というのはあるよ
むしろその方が多い
ただ前レスに出てきたCR(コントロールレジスタ)とSR(ステータスレジスタ)は意図的にその名称通りにWriteまたはRead専用属性の例として
提示してきたんだろ、多分

2019/02/25(月) 14:20:45.00

いやーないだろ
ゲートが出てるだけのユニットにWRITEサイクルを実行なんてしねえし

2019/02/25(月) 14:31:07.16

すまん
書き込みの意図がいまいちよく分からんのだけど出力形式の切り替えの話か？
オープンコレクタ出力とトーテムポール出力の切り替えか？
というかこの文脈でデコードの意味が分からん、何のこと？

2019/02/25(月) 14:45:57.95

キモい奴だなおい

2019/02/25(月) 14:54:09.36

誰かわかる奴いるのか？
俺も>>319は意味わからん

2019/02/25(月) 15:17:20.76

何となくだけど入出力兼用ポートの設定か？

2019/02/25(月) 17:25:52.43

volatileの話が本筋と関係ないなら適当に流して先に進めばよかったんだよ。
それなのに噛みついて話を爆発させてしまったところにコミュニケーション能力の欠如を感じる。

2019/02/25(月) 17:28:47.58

このスレはC言語という話題を通じてマウント取り合うスレなので、今日も平和に通常運転。

2019/02/25(月) 18:07:46.57

ゲートが出てるのがオープンコレクタとかもう
そのうち電圧が流れるとか言い出しそうな勢いだな

2019/02/25(月) 18:39:15.96

volatileまではまだ分かる
ゲートやトーテムポールやデコードの単語の羅列は意味不明

2019/02/25(月) 19:02:12.96

>>320
> Read/Write属性というのはあるよ
いやいや、 Read onlyとかWrite onlyって言うのはわかるけどRead/Write属性なんて言う用語を使うか？
って話な

>>324
なんとなくデコードって言うのはアドレスデコードした信号（要するにChip select）にRE（多分Read enable）とかWE（Write enable）をandする話だと思う
ゲートとトーテムポールはよくわからん

2019/02/25(月) 20:16:10.80

>>330
そういうことか
マイコン内蔵デバイスの話ではなくてガチのハードウェア回路設計のアドレスデコードとコントロール信号の話か
唐突過ぎて訳が分からなかった

2019/02/25(月) 20:28:08.49

ReadやWriteではなくて入力信号と出力信号だな

2019/02/25(月) 20:33:09.01

内部or外部CPUバスのことを言ってるにしても、Write onlyがないってとこに繋がらない。
やっぱ解読不可だわ。

2019/02/25(月) 20:33:17.49

そういえばread-modify-writeっのを思い出したな
もう10年以上前の事だが

2019/02/25(月) 20:50:44.04

懐かしい話題だな
わざわざラッチ回路を設けて問題回避したりしていたな

2019/02/26(火) 06:45:38.56

>>330
ちょっと亀レス気味だけど、確かに属性というのは一般的ではなかったかな
当時使っていたCコンパイラでは同一アドレスにマッピングされたRead OnlyとWrite OnlyのSFR変数は
共用体unionで宣言するのだけど、それぞれが読み込み/書き込み専用の変数名であることを明示するために
プリプロセッサの#pragmaでいわゆる属性(R, W, R/W)を宣言することが出来た
Read属性変数に代入操作を行なったりするとコンパイル時に警告されるような仕組みになってた

2019/02/26(火) 07:46:54.76

write属性レジスタってのは確かに一般的ではないけど、かといって用語としてwrite専用レジスタじゃないといけないって明確なルールもないだろうし、仕様書書いてるわけじゃないので別に雰囲気で伝わるから気にしなくていいんじゃない？

2019/02/26(火) 08:50:06.80

一般的な用語じゃないとそこにどんな機能が含まれてるかわからんからな
>>336見りゃわかると思うがそもそもレジスタの機能ですらなかったわけだし

2019/02/26(火) 09:19:26.09

議論の流れで大体わかるけどな
さすがにプログラム言語やマイコンの話の中でいきなり回路設計の話が出てきた時は
しばらく話について行けなかったが

2019/02/26(火) 12:28:24.64

>>339
お前はわかるのかも知れんが>>319みたいにちゃんと確認しようとする奴もいる
そもそも一般的で無い用語を使う理由もないだろ

2019/02/26(火) 12:41:52.52

これぐらいのことが話の流れで推測できないなんて、生き辛そう。
お大事に。

2019/02/26(火) 12:49:02.64

>>317で指摘されているけど抽象的な話のできない人というのは確かにいるからな

2019/02/26(火) 13:31:09.42

確かに昔からハードウェア弄ってきた純粋の組込み専門屋にとって、周辺デバイスの制御レジスタをSFR変数として抽象化して捉えることが出来ないとは思ってもなかった
一般的ではなくても属性で話は通じると思ってたんだけどなあ
というか本当にC言語で開発してるのだろうか？

2019/02/26(火) 13:45:18.64

「出来ないとは思ってもなかった」

否定の否定表現でわかりにくい。

**デフォルトの名無しさん** (JP 0Hb5-haK8) · 2019/02/26(火) 14:19:05.67

SFRって特定アーキテクチャの特殊用語じゃん。何勝手に一般化してるん。

2019/02/26(火) 14:38:19.53

ワンチップマイコン使ったことが無いのなら口を挟まないほうがいいよ
どこの製品でもSFRで話は通じる

2019/02/26(火) 14:46:05.57

分かったからワンチップマイコンは別の所でやれ

2019/02/26(火) 14:55:37.46

もしかして組み込み以外の話は
【初心者歓迎】C/C++室 Ver.104【環境依存OK】
で聞いた方がいいのか？

2019/02/26(火) 15:07:48.55

C言語の一般的な話題を扱うスレなんだから
特定の人間を排除するような発言をするのはおかしいだろう
そういう特定の話題をしたいならスレを立ててすればいい
ワンチップマイコンは専用スレ立ててそこでやれと言う話

2019/02/26(火) 15:14:00.56

今や純粋なC言語の所理系は初心者の学習用途か組込み開発用途くらいでしか使われていない
スレに組込み開発経験者が集まるのは自然な流れ

2019/02/26(火) 15:18:02.00

どちらかといえばC言語学習者は高圧的で排他的な気はする