C言語なら俺に聞け 149

2018/10/28(日) 22:01:44.38

!extend:checked:vvvvv:1000:512
↑
次スレを作る時は上記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言語なら俺に聞け 148
https://mevius.5ch.net/test/read.cgi/tech/1537347410/

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

2018/12/22(土) 07:52:56.06

Linusがcppを排したのは正解だったんだな

2018/12/22(土) 08:27:41.36

低学歴知恵遅れ＆お前ら連呼の人が、引数 void って初めて見たぞ
の人と同一人物だったとは

2018/12/22(土) 10:05:42.90

C言語のスレだから、そろそろ話をC言語に戻そうよ
C++の話は専用スレでも立ててそこで継続してくれ

2018/12/22(土) 10:15:17.63

iZ-Cは魅力的なAPIがいっぱいだよ。

2018/12/22(土) 11:12:54.97

新設するまでもなくC++のスレッドも複数あるからなぁ。
濃いネタばっかりで「C++はいいぞ、早くCから移行しろ」程度じゃ
相手にしてもらえないレベルだと思うけど。

…いや、俺も理解できてるわけじゃないがな。

2018/12/22(土) 11:51:34.32

Cでオブジェクト指向っぽく書くと継承しなくていいのがいいよね。
冗長にはなるけど。

2018/12/22(土) 12:11:28.34

OOP自体が間違い。OOP書きたいのにC使うのは間違い中の間違い。

2018/12/22(土) 12:26:28.69

>>718
じゃあどう書くわけ？
デザインパターンを常に排除すんの？

2018/12/22(土) 12:55:54.08

関数の第一引数を構造体にするならファイルポインターもオブジェクト指向に
なっちゃうからな。
仮想関数テーブルとかつくっちゃってるのかな？

2018/12/22(土) 13:17:52.98

昔CでのOOPが流行った頃は「オブジェクト指向=継承」みたいな捉え方が主流だったから
構造体にvtable持ってピギーバックで継承して、って感じだったな。

2018/12/22(土) 13:20:28.89

>>717
それは一理ある。

俺自身はCもclass構文を取り入れるべきだと思っているが、実際そうならないのは、

・分かっている奴が書けば何とかなる

からなのも事実だ。
そして「継承」が無駄に嫌われているのは、Javaでは関数ポインタを提供しなかった為、
継承を使うべきでない局面で使われまくり、余計に意味不明になる事が多かったからだ。
デザインパターン自体がバッドプラクティス集なのもそのせいだ。
あれも本来は「第一級関数」を持つ言語で書き直し、
既存のJavaで書かれたデザインパターンは老害ゴミとして捨て去られるべきなのさ。

ただ、本来「継承」を用いるべき局面については当然「継承」の方がフィットするわけで、
Goみたいに

×　継承に代わる便利なものを用意したから継承が不要となった
○　ただ単に継承/仮想関数を排除しただけ

の言語は完全に乗り遅れてる。あれならCで書いても同じだし。
（Goは元から80年代の言語だと揶揄されていたが、全くその通りだった）

とはいえ、Goを作った連中は君と同じ感覚なのだろうとは思う。
君はGoを気に入るかもね。

**デフォルトの名無しさん** (ｱﾒ MM59-wUZI) · 2018/12/22(土) 13:27:38.05

> 本来「継承」を用いるべき局面については当然「継承」の方がフィットする

設計時どれだけそう思い込んでいても、のちに覆され得る。それは設計時には知り得ない。
単純に継承のことは完全に忘れ去ってしまうべきである。
そんなものは無かった。

2018/12/22(土) 13:50:48.44

老害ゆとりのvoid君
相変わらず言ってる事が支離滅裂で草

2018/12/22(土) 13:56:16.04

void君がよく「ゆとり」連呼してるけど
彼本人はどうなん？
発言内容からはキャリアを感じさせないし
そもそも年齢もせいぜい35くらいじゃないの？

2018/12/22(土) 13:59:01.93

カサブランカの世界だな

2018/12/22(土) 14:00:34.13

>>721
そうね。便利なマクロ用意したら結局それC++じゃんみたいな。
無遅刻無欠勤がとりえでコピペの手間を厭わないsubversion大好きかつ注意深い人達が作った、再利用を全く考えないワンオフ物の超巨大クラス構造みたいなの見ると、継承は初めから無い方がいいなと思うよ。ほんとつらい。

2018/12/22(土) 14:03:16.29

>>723
まあ実際それをやったのがGoな訳で。そう思う人がいるのも事実だろうさ。
（俺はGoはポシャると思っているけど）

2018/12/22(土) 14:26:09.40

>>717
書き方次第だよ。linuxで最も有名なライブラリの一つであるglibは継承してるし

2018/12/22(土) 15:34:01.41

空想論の域を出てないなあ

2018/12/22(土) 21:50:01.34

死にたい

2018/12/22(土) 21:56:40.29

死にたいのは何かが足りないから。

その何かを探しに旅行へ行こう。

旅人は旅に旅立つ。

2018/12/22(土) 22:42:35.80

片道切符に誘うのやめろ！

2018/12/23(日) 01:05:41.98

Cの世界へ逝こう

2018/12/23(日) 11:39:57.84

>>731
Cぬな

2018/12/23(日) 12:16:27.31

全てがCになる

2018/12/23(日) 12:39:52.20

2018/12/27(木) 23:00:48.46

全てがFになる

2018/12/27(木) 23:16:13.58

そして、全てはぬるぽ

◆QZaw55cn4c (ﾜｯﾁｮｲ 3a60-I/qK) · 2018/12/27(木) 23:48:52.00

>>738
冷密＝「冷たい密室と博士たち」の方が好きです他は雰囲気ワードを散りばめただけのどちらかというと駄作に見えてしまうのですが、唯一これは極上のロジックだと思うのです

2018/12/28(金) 06:05:14.46

このスレで全てがFつーたら、-1のことだろ

2018/12/28(金) 09:26:28.29

255もよろしく

2018/12/28(金) 17:38:41.28

#defineを使って関数を定義するテクニックがあります

#define kansuu() （ここに関数の内容を書く）

一時的にその関数を無効にしたいときはどうしたらいいでしょうか？

#dfine kansuu()

こんな感じにkansuu()以降を空白にしておくのがいいですか？

2018/12/28(金) 17:40:24.93

#define kansuu() (いっぱい書いてる)

#undef kansuu
#define kansuu()

2018/12/28(金) 17:54:33.91

void kansuu(void)
{
ここに関数の内容を書く
}

#define kansuu() (ここに関数の内容を書く)

int main(void)
{
kansuu(); //マクロ
(kansuu)(); //関数
}

2018/12/28(金) 23:36:56.58

よくあるdebug printfのアレじゃね

2018/12/29(土) 00:42:29.78

>>744
> #define kansuu()

kansuu()の後には何も記述しないのが正しいスタイルってことですね

>>745
関数とマクロ、そういう使い分けができたんですか・・・

2018/12/29(土) 10:25:00.95

-Dじゃあかんのか？

2018/12/30(日) 17:16:13.69

いいんじゃないか？
コンパイラのコマンドがどう解釈するかに掛かってはいるが。

2018/12/31(月) 21:39:38.58

よくやるのは
#ifdef HOGE
#define func()　ここに処理
#else
#define func()
#endif
で、-DオプションでHOGEの定義を切り替える。
好みや宗教により#ifdefを#if definedにしたり、HOGEの値により分けたり、プリプロセッサを使わず処理のifで分岐したり。

2019/01/01(火) 01:03:53.24

初心者です。
あけましておめでとうございます。
本年もよろしくお願いいたします。

2019/01/02(水) 20:01:12.90

かっぱらいプログラム言語と言うのが出来そうな予感がした。

2019/01/03(木) 09:41:01.80

Linux環境のデバドラと組み込みの違いって何ですか？

2019/01/03(木) 10:32:23.68

デバイスドライバというのはデバイスをドライブするプログラムである。
組み込みというのはまあ特定の製品を制御するための専用のシステムである。専用というのはつまり汎用ではないということで、要はPC向けではないということである。

2019/01/03(木) 10:38:18.81

>>754
ありがとうございます！

2019/01/03(木) 16:57:06.44

LinuxならLinuxに合わせた形でデバイスとのやりとりを作る必要があるが、そうでないならその辺は自由になる。

2019/01/03(木) 17:09:14.18

>>756
なるほど
自分はLinuxに合わせて作ろうと思ってます

2019/01/03(木) 19:27:30.38

そもそも組込み機器でLinux使うこともあるから>>753の質問自体がイミフなんだが

2019/01/03(木) 23:20:49.06

まあ、組み込みとだけ言ってしまうとなんでもありになってしまうな。
Windows Embedded なんてのもあるし。組み込みだからといってOSがないとは限らない。
というか今となっては何も入ってない方が珍しいかな？

2019/01/04(金) 07:14:05.80

わざわざ「組み込み」と言う意味があるかどうかだな
ノートPCをロボットの脳として搭載することもできるが
OSがWindows10 Homeじゃ組み込みとは言えないのか

2019/01/05(土) 18:26:16.82

今じゃ小さいの幾らでもあるからなんでも組み込みにできるな。
コストと耐久性の問題はあるが。

2019/01/06(日) 21:17:49.87

一時はECUなど特定の分野を除いて組み込みもLinuxに席巻されそうになっていたけど、最近のIoTブームのせいか超小型超低消費電力のマイコンのニーズが高くなり昔ながらの職人芸的組み込みソフトが復権してきてるイメージあるわ。

2019/01/06(日) 21:36:48.83

まあプログラムはむしろ楽だね。
貧弱なプラットフォームの方が。

2019/01/07(月) 06:58:10.64

PICなんかを使った、電子工作の延長みたいな
「Cでもプログラムできるワンチップ」ていうジャンルも
盛んになってるみたいだし。

あそこまで小さくなると、直接マシン語で考える方が
手っ取り早いような気がするわ。

2019/01/07(月) 17:11:01.86

気がするんではなく実際そうだ
あれはアセンブラで使うもの

2019/01/07(月) 17:19:52.92

アセンブラで出来てC言語で出来ないことがイマイチわからないです。
なんか具体的な例などあれば・・・

2019/01/07(月) 17:22:48.61

C言語使う為には最低限コンパイラが動く環境を
用意しないと行けないが
アセンブラは比較的簡単に実装できる
いざとなったら16進で入力すれば良いし

2019/01/07(月) 18:58:49.76

>>767
なーるほど！コンパイラがいらずでCPUやメモリ使えるってことですね！
それは確かに便利だありがとうございます。初めてアセンブラの利用価値に合点がいきました。アセンブラわからないですが(´・ω・｀)

◆QZaw55cn4c (ﾜｯﾁｮｲ d347-5am+) · 2019/01/07(月) 19:01:38.90

>>766
自己書き換えプログラム、とかはどうですか？

2019/01/07(月) 19:06:52.70

8ビットCPUの頃はやった事あるけど
今のCPUだと難しいのではないかな

2019/01/07(月) 19:13:29.39

真のハーバードアーキテクチャだとな

2019/01/07(月) 19:20:28.86

コンパイラが要らなくてもアセンブラは必要なものじゃないの？

2019/01/07(月) 19:34:19.06

>>772
8bit時代、サブルーチン程度ならニーモニックどころかダンプ直打ちしてた基地外もいた

2019/01/07(月) 19:41:40.02

おっさん世代はZ80ぐらいなら主要なニーモニックは未だにヘキサで覚えてる。

2019/01/07(月) 21:33:52.93

>>773
ごめんな
コーディング用紙つかってた
I/Oの鬼ダンプとか今でも思い出すよ

2019/01/07(月) 21:46:22.29

このスレの平均年齢いくつなの……w

2019/01/07(月) 21:58:59.48

>>768
それだけでなく本当にCだけではできない事があるのが普通だ。CPUにもよるけどね。

何か特定のレジスタに値をセットしないと何かの機能が使えないみたいな場合はCではレジスタの指定をして値をセットすることができないので最低でもその部分だけインラインアセンブラにしたり全部アセンブラで書いたりする(またはそれ用に拡張がされたCコンパイラを使う)。

その他、80系やx86系ってI/Oポートあるが、あれはCからはアクセスできないのでその部分はアセンブラにする。

まあしかしそういうのはほとんどデバイスドライバの中で必要になる事なので普通は一般ユーザは考えなくてもよくなっている。

2019/01/07(月) 22:02:17.91

>>773
それ昔は普通に居た。何せアセンブラなかったりあっても高かったりで使えないことが多かったからな。

>>774
3E 00　　　LD A,0

のような。

2019/01/07(月) 22:31:49.44

>>778
XOR使おうぜ

◆QZaw55cn4c (ﾜｯﾁｮｲ d347-5am+) · 2019/01/07(月) 22:37:49.75

>>777
思い出した！たしか 386 にて real mode から protected mode に移る命令は C では書けませんね…
他にもなにか面白い話があったような気がしましたが、もう思い出せない…実は 286 はリアルモードに戻れるとか…

>>774
HALT を言ってみよ

2019/01/07(月) 23:02:03.29

LD はゼロやキャリーフラグ変化するんだっけ？

2019/01/07(月) 23:06:04.57

オムニバースを解析するソフトウェアを開発するにはどうすれば良いですか？

2019/01/07(月) 23:11:49.25

>>780
逆じゃないか？
286では戻れずに、不便だったけど
386では戻れるようにしたとか

2019/01/07(月) 23:51:44.52

>>780
76

◆QZaw55cn4c (ﾜｯﾁｮｲ d347-5am+) · 2019/01/07(月) 23:54:17.89

>>783
＞286では戻れずに、不便だったけど
通説ではそうなんですが、「実は…」という話があった気がします、そのため「だけ」に 286機を確保していたつもりだったのですが、うっかり捨ててしまった、やりたかったことを今思い出してしまった…

2019/01/08(火) 00:17:51.75

NECのPC98での話ですが、プロテクトモードとリアルモードを行き来するのに
リセットで実装していたと聞きました（死中に活ありみたいな感じ）。

「実は・・・」って話は知らないｗ

2019/01/08(火) 07:38:36.71

>>785
0F 05 LOADALL

2019/01/08(火) 07:56:15.99

なんか286はPC用じゃなく工業製品用を想定して設計されてたって記事読んだ記憶が。

2019/01/08(火) 08:00:10.01

さあ、C言語の話をしようか。

2019/01/08(火) 10:13:36.31

昔から疑問なんだけど、マップドIO制御を除いてC言語だけでRTOSのカーネルは書けるのだろうか？
タスク同士のシステムコール発行によるプリエンプトはsetjmp/longjmpで何とかなりそうだけど、割り込みハンドラからのシステムコールによるタスクディスパッチは何をどうあがいてもスタックポインタの直接書き換えが必要な気がしてならない。

**デフォルトの名無しさん** (JP 0H95-OLjn) · 2019/01/08(火) 10:40:29.19

ハンドラ内でsetjmpしたらどうなるんだろう

2019/01/08(火) 11:39:30.49

CだけでOSなんて、Cは元々そういう使い方を想定していない
実際UNIXは5%がアセンブラだった

特権命令は誰か言っていたとおりだし
PCとSPのようなCが前提にしているものの初期化をCでは絶対に書けない

2019/01/08(火) 13:48:48.48

でも最近のUEFIとかなら全部Cで書かれたOSでも起動できそうだけどね。

2019/01/08(火) 16:18:38.83

C言語を一番最初に学んで、C++、ほかスクリプト言語と使っているが、C言語で文字列処理ライブラリーってみんなどうしてる？
C++ だとboost C++ とかいろいろなライブラリがあって、オープンソースだったり商用利用できたり、物によってはGPLだったりするけど、そういうのに相当するC言語の文字列処理ライブラリってある？
各自で作りためたオレオレライブラリをみんな使ってるの？？

**0794** (ｵｲｺﾗﾐﾈｵ MM95-hx//) · 2019/01/08(火) 16:22:15.64

つまり今から俺が自分用に文字列処理ライブラリ(独りよがりのオレオレライブラリ)を作る意味があるのか、俺が知らないだけでboostみたいに出来合いの洗練されたライブラリがあるのか…な…？
Pythonとかは言語仕様で十分複雑なことが出来るし、ホントC言語だけなんでこんな毎回面倒な目に合うのだろう。

2019/01/08(火) 16:37:12.54

Cを修行中ならオレオレライブラリを作ることにも充分に意味がある
既製品を使うことしかできないくせに天狗になってるやつが時々いる
使っているライブラリがオレオレか既製品かといった手段ではなく
知的な旅でどこへ行けたかが問題であることを見失うな

2019/01/08(火) 16:56:52.52

俺はboostを知らない。
Cではあまり複雑な文字列処理を書かないしな。
複雑なのはPerl使ったりする。

2019/01/08(火) 18:11:31.32

みんなありがとう

Cは全然修行中なわけではなく、別に必要にも迫られてない(C++もPythonも使える恵まれた環境)
ただ必要になったとき、みんなどーしてんだろうと。
C言語で文字列処理なんてするシチュエーションが少ない、とかかな。

初めてPython使ったときは感動した。簡単すぎて。C++では修行中に文字列処理ライブラリとかオレオレライブラリ作成やってみたけど、できあがった物がどう見てもboostの下位互換で悲しかった。
だからC言語で良いライブラリがあったら知っておきたいと思ったんだ。

2019/01/08(火) 18:41:54.19

>>792
頑張れば書けるよ！

Cというよりは Cの文法を使った何かになったけどな・・・

**デフォルトの名無しさん** (JP 0H95-OLjn) · 2019/01/08(火) 19:47:06.06

>>795
glibとか？

2019/01/08(火) 22:16:50.19

ちょっとすみません
gccの最適化オプションの-O2を使った場合に動作がおかしくなったりすることはありますか？

2019/01/08(火) 22:19:56.62

あるかもしれないし、ないかも知れない
そういうソースがあるなら、晒して皆に確かめてもらえ

2019/01/08(火) 23:00:38.10

>>801
ある。
多分これからvolatileに関するやりとりが始まる。

2019/01/08(火) 23:28:52.41

>>802
最適化したことでおかしくなったと言うわけではないんですが
どうなのかなと気になったもので
具体的にはO2の中のどの最適化でバグが出ることがありますか？
あとgccではなくg++でした

2019/01/08(火) 23:31:24.43

>>803
volatileというものに気を付けないといけないわけですか

2019/01/08(火) 23:45:28.12

>>804
仕様上規定されていない部分は最適化によって挙動が変わることがある。だから不確定な処理や誤った処理を書いていた場合に、これまでたまたま上手く動くコードが生成されていただけで、最適化によって挙動が変わってバグが顕在化することがある。
例えば、評価順序が不確定な処理を書いていたのがたまたま期待通りの順序で実行するコードになっていただけとか、不正なアドレスのメモリを参照や更新してしまっていたがたまたま問題がなかっただけだったとか。

◆QZaw55cn4c (ﾜｯﾁｮｲ d347-5am+) · 2019/01/09(水) 00:17:56.61

>>803
volatile は一切使わないことにしました…

2019/01/09(水) 00:28:20.37

volatileにすべきところでしないから最適化でバグるんだよ

◆QZaw55cn4c (ﾜｯﾁｮｲ d347-5am+) · 2019/01/09(水) 00:40:32.88

>>808
volatile すべきところ、って具体的にどういうところですか？それは本当に volatile にする必要があるのですか？

2019/01/09(水) 01:08:46.29

>>809
メモリマップドIOと
共有メモリマルチプログラミングで
最適化時のアクセス省略防止。

2019/01/09(水) 02:45:48.52

>>806
ありがとうございます
そうであれば不確定な部分がなければバグはでないということですね
最適化用にプログラムの書き方も変える必要があるのかと思っていました

volatileはライブラリの中で使っていそうですがきっと大丈夫でしょう

◆QZaw55cn4c (ﾜｯﾁｮｲ d347-5am+) · 2019/01/09(水) 03:15:23.18

>>810
個人的には、memory-maped な世界はよくしらない（インテル系しかしらない…）．
shared memory って、特別なことはありましたっけ？マルチスレッドなら排他処理用のオブジェクト（pthread-mutex/cond）を使っておれば問題ないし、fork() の中と外で同じ変数をつつくときは…はて、どうしてたっけ？