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/06(水) 13:43:35.56

ミスってる
!extend:checked:vvvvv:1000:512
を書き込み内容にするためにもう一行書かなければならないのね

2019/02/06(水) 13:53:52.35

そうしろって書いてあるじゃん

2019/02/06(水) 14:08:04.08

違うな
シェバンに類似する特殊な一行目は書き込みすると失われる、だろ
だから次の手順説明のために同じものをもう一行増やす

しかも「必ず1行目に入るように」って書いてあるから二行に増やしても先頭に空白行があると受理されないハズだ
もう一行書くだけじゃダメだからな

2019/02/06(水) 14:19:35.82

>>1 乙です、ドンマイ

2019/02/06(水) 16:08:05.73

では、続きをしようか

986 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ df01-vS77)[sage] 投稿日：2019/02/06(水) 04:57:27.49 ID:eUM592Vs0
ループから抜けるときに goto使ったらダメなんですか？

for (...) {
for (...) {
if (...) goto LOOP_EXIT;
}
}
LOOP_EXIT:

こういう感じで書いたら先輩に怒られました。
フラグ見てループ抜けるように修正しろと。
指示されたので従いますけど、どうしてダメなのかよく分かりません。

どなたか納得するような理由をご存知でしょうか？

2019/02/06(水) 16:09:43.98

若き日の俺は、gotoの他にフラグも無闇に使うなと教わったものだが
フラグはいいってことになったのは、いつからだ？　どういう経緯でだ？

2019/02/06(水) 16:21:58.32

Cにはラベル付きbreak文って無いんだね初めて知った

Javaのラベル付きbreak文
loop_exit: for(...) {
　for(...) {
　　if (...) {
　　　break loop_exit;
　　}
　}
}

まぁJavaでもあまり使ったことないけど…。

2019/02/06(水) 16:41:15.95

#define break goto
みたいなしょーもないことしても本質的に何も変わっちゃいねえ

2019/02/06(水) 18:02:39.46

gotoよりフラグがやばいよな。

2019/02/06(水) 19:00:59.18

goto があっても
いいじゃないか
C言語だもの

2019/02/06(水) 19:48:43.15

goto文そのものが悪いわけではない。いまだにgoto文の使用そのものがよくないというやつらのせいでおかしくなっている。

goto文で前のif文内に飛んでみたり、ループのなかに飛んでみたりと、乱用して人間には理解しづらいスパゲティプログラムを作るなという話なのに。

continue文だって実体はgoto文で、コンピュータにとってはメモリ上のマシン語を順番に実行しない場合はすべてメモリのアドレスのジャンプでgoto文。

2019/02/06(水) 20:21:21.69

センサーで取得した計測値を数値では無く文字列で返す関数を作ろうと思ってる。
どんな計測結果が得られるか事前には分からないため文字列のサイズは関数内で
mallocを使ってリサイズする予定。

このとき測定結果が格納された文字列を関数から渡してもらうのに、

a) 引数に文字列のポインタのポインタを渡す
void sokutei( char** buff )
{
・・・
*buff = (char*)malloc( sizeof(char)*length );
・・・
}

と、

b) 関数の返値に文字列のポインタを指定する
char* sokutei(void)
{
・・・
char* buff = (char*)malloc( sizeof(char)*length );
・・・
return (buff);
}

の二つの方法があるけど
一般的にはどっちの方法がお薦め？

2019/02/06(水) 20:30:53.85

>>12
機械語が分岐命令になる高級言語のステートメントを全否定というのは
構造化とはまったく違う話だな

2019/02/06(水) 20:31:48.22

>>13
別にどっちでも

2019/02/06(水) 20:34:02.27

>>15
そ、そう・・・

2019/02/06(水) 20:50:04.50

>>13
> センサーで取得した計測値を数値では無く文字列で返す関数を作ろうと思ってる。
これ自体が糞。
計測値は生で保持して、表示する時だけ文字列に変更しろ。
そうすればprintfだけで行けるだろ。

無駄に可変長のバッファなんて持とうとするから無駄に面倒になる。
初心者だから分からないのだと思うが、そもそも複雑にならないように全体像をまず組むんだよ。

2019/02/06(水) 21:37:14.88

voidにするならポインタ返した方がいいと思うよ。
正しさでいうと、既存のライブラリ使ってシリアライズするのが正しい。

2019/02/06(水) 22:39:39.17

関数の戻り値は処理の成否のみを返す。
正常終了なら０、異常終了なら非ゼロ。
入出力は引数で渡す。

と、決めて統一するのが良いと思う。

2019/02/06(水) 22:43:12.36

助言ありがとう
確かに関数の戻り値は処理の成否のみに限定するのはスッキリしていいかも

> 文字列で返すのが糞

確かにその通りで(；^ω^)

2019/02/06(水) 23:32:22.18

重要なのは統一するってこと。

標準ライブラリには戻り値に二つの意味を持たせているのが多いから、個人的に好きじゃない。

fopen() 成功時はファイルポインタを返し、失敗時はNULLを返す。

strtol() 成功時は変換結果を返し、失敗時は0を返す。
これじゃ変換結果が0なのか、失敗して0なのか分からない。
で、errnoを見ろってことになってる。

なんでこうなってるかというと、戻り値に処理の成否と結果の二つを持たせているから。
だったら、分ければいいじゃんって話。

2019/02/06(水) 23:38:05.98

>>20
多分相場が分かってないのだと思うけど、
正しく初心者の自覚があるのなら、ある程度縛りプレイで行った方がいい。
C言語なんて現役で50年来てるし、そのセンサーだって民生品なら誰かが同様に使ってる。
それでもそれ用のライブラリがないのなら、それはそもそもそういう使い方をする奴がこれまで居なかったということ。
つまり、そのやり方が間違っている、と見ていい。

初心者が自前でライブラリみたいな物をいきなり組まなければならない時点で設計が間違ってる。
それは君らがよく誤用している「無能な働き者」に該当する。
（ただし繰り返すが、Webでの多くは誤用されているので注意）

2019/02/07(木) 00:06:12.90

副作用がメインならともかく、欲しいものを素直にreturnすればいいよ。

2019/02/07(木) 00:29:49.70

strtol()は変換できなかった時の戻り値が曖昧だから0やらLONG_MAX、LONG_MINに固定してるだけだと思ってたんだけど

2019/02/07(木) 00:29:57.91

バカかコイツラNaNが出たらどーすんだよ
文字列が正しいだろJK

2019/02/07(木) 05:23:13.49

>>20
C言語の戻り値って、エラーのみで返して、正の値って無いから、C++だな、C++言語に行くように

2019/02/07(木) 06:44:41.17

>>19
それやだ
んなことするくらいならsetjmpだ

2019/02/07(木) 07:00:15.05

>>13
ほんとうはaのときは引数にエラーがいるし、bのときは戻り地を
エラーにしないといけないからあまり変わらない

2019/02/07(木) 17:48:23.42

くっそ初心者なんだがガウスの消去法でn次連立方程式を解くようにしたいんだがn次を入力させてからやるにはどうやりゃいいんだ？

2019/02/07(木) 17:57:54.86

行列の格納先に配列のかわりにmallocで動的に確保する。

2019/02/07(木) 21:03:55.08

n以外はどうやって入力させるつもりだったの？

13 (ﾜｯﾁｮｲ 82ab-/WZR) · 2019/02/07(木) 23:25:09.01

a)の方法。空の文字列を渡そうとすると失敗するっぽい

char** str;
sokutei( str );

これやっても有意な文字列はstrに返ってこなかった。
もしこれやるならb)の方法じゃ無いとダメかも↓

cha* str;
str = sokutei();

2019/02/07(木) 23:38:06.10

初心者だから間違ってるかもしれんけど
外でメモリ確保してないからじゃない？
文字列を関数内で作ってたら関数処理終わった後は文字列がそのまま残るかは保証されなかったような気が
外で配列宣言して関数に渡して、関数内でそこにmemcpyさせるとか？

2019/02/07(木) 23:41:01.38

>>32
それやるなら、こうじゃね?

char* str;
sokutei(&str);

2019/02/07(木) 23:59:08.20

あぁmallocしてんのね…
aは何でchar**なんだろう

2019/02/08(金) 00:24:25.67

ちゃ

2019/02/08(金) 07:47:48.49

>>29
C99以後ならVLAという手もある
int n;
scanf("%d", &n);
double mat[n][n + 1];

**デフォルトの名無しさん** (ｽﾌｯ Sd22-QV4H) · 2019/02/08(金) 08:37:48.99

>>34
あぁなるほど

char **str;
sokutei(str); // 関数の引数にstrのアドレスがコピーされるだけ

だから関数内で代入してもコピーに再代入してるだけか

char *str;
sokutei(&str); // str自体のアドレスを渡す

これなら外のstrにmallocで確保したアドレスが入るのね

2019/02/08(金) 09:08:14.73

渡した引数を書き換えてくれるインターフェースは
scanf() の使い方と同じくするしかない

2019/02/08(金) 13:03:58.19

Cに未来はあるのか

◆QZaw55cn4c (ﾜｯﾁｮｲ e247-3ywI) · 2019/02/08(金) 21:04:27.25

>>37
VLA は廃れていく方向のダメな子じゃないですか？c++ からも linux からも追放されたようですし

◆QZaw55cn4c (ﾜｯﾁｮｲ e247-3ywI) · 2019/02/08(金) 21:05:05.81

>>40
たくさんの人に使ってもらいたいライブラリを書くのなら、現状 C しかないと思います

2019/02/08(金) 21:45:38.59

>>41
C++にはもともと導入されてないから追放とかじゃない
vectorがあるからいらんかったというだけ

2019/02/09(土) 01:59:26.91

>>26
ANSI Cでは何かしらの値を返さなければいけない。

2019/02/10(日) 10:04:34.79

どこかのHPで「自分は頭悪くてC言語の命令が覚えられなかったからアセンブラでプログラミングしてた」という記述を見たんだけど
アセンブラの方がよっぽど難しいと思うんだけど、アセンブラできる人からしたら違うのかな？

2019/02/10(日) 10:40:12.32

単に、新しいものを覚えるより使い慣れたアセンブラのままでやった方が早いという話じゃないかな。
あるいは情報処理試験の話だったとか。

2019/02/10(日) 10:47:05.06

おそろしく英語がわからんプログラマーを見ると少し哀れみを感じる

2019/02/10(日) 10:48:33.87

>>45
ものにもよるけど理解するのはアセンブラのほうが単純なぶん簡単。

2019/02/10(日) 12:53:55.02

一部には変数概念を理解できなかった御仁もいるらしい

2019/02/10(日) 12:55:24.84

CPU設計者じゃないかな

2019/02/10(日) 13:26:11.80

アーキテクチャや機械語ニーモニックは簡単なんだけど
CPUと直接関係のない、アセンブラ指示子やコマンドを覚えて
エラーなくアセンブル通るようにするのは大変

2019/02/10(日) 13:34:57.75

わかりやすいアセンブラ作るとCになると思うよ

◆QZaw55cn4c (ﾜｯﾁｮｲ e247-3ywI) · 2019/02/10(日) 13:41:05.68

>>52
ならないですね…

2019/02/10(日) 14:46:39.63

構造化アセンブラとかあったな
結局流行らなかったけど

2019/02/10(日) 16:31:12.43

構造化アセンブラ使っていればいずれCに移行するし
Cで記述できない部分はインラインアセンブラで補うようになる
構造化されているとはいえアセンブラはあくまでアセンブラ
生産性はCには及ばない
元組込みマイコンプログラマより

2019/02/10(日) 17:36:00.24

>>45
アセンブラってのは理屈じゃない決めごとを憶えるだけでいいが
Cやその他の高級言語は構造化だとか処理系依存がどうたらという
どっかの知らん馬の骨が強弁する作法シキタリに付き合わされるから
気が短いやつはプイと出てっちまうのさ
鵜呑みをせず納得ずくでしか動かんやつという意味では大物の素養がある

2019/02/10(日) 17:48:21.83

最初がBASIC小僧だった経験から言わせてもらうと、
サブルーチン(Cでは関数)に値を渡す返すって部分が分からなかったな。
ある計算をさせるサブルーチンにパラメータを与えたいときは
大域変数に入れて共有する、値の返却も同様。
これはアセンブラでも同じでしょ。レジスタで渡す返すも可能だけど。

その後、8bitマシン語少年に進み、Cを勉強した時は
ポインタ加算の自動スケーリングに引っかかった。
int *p = &a[0];
p += 4; // ここで p == &a[4] になるのが納得いかない
新たな p が指す先は a[2] か a[1] (intのサイズに依存)、と考えたわけ。

2019/02/10(日) 18:06:18.52

プリプロセッサで MASM の REPT句と同じようなのが欲しいいかも　と思ったことはある

2019/02/11(月) 08:42:09.13

C言語学び始めたときに（BASIC、Z80/8086アセンブラの経験はあった）「C言語の非常識」とかいう本読んで
トラブルになりそうなところを先に学んだんでそう苦労しなかったな。

それより16bit DOS時代だったんでコンパイル設定でメモリモデルがLARGEだのHUGEだのの方が理解でできんかった。
まだ学生で「インターネットください」より前の時代で調べる手段がわからんかったし。

2019/02/11(月) 16:17:31.30

それ30年ぐらい前だよね。
large だの huge だのは本読んだりして覚えたなあ。

2019/02/11(月) 16:27:55.76

nearとfar
懐かしいな

2019/02/11(月) 16:39:10.95

数百MBの配列データを扱うときにコンパクトモデル利用したな

2019/02/11(月) 16:57:59.18

30 年前に C コンパイラにアセンブラソース出させて C を学んだけど
ひょっとして普通はしないことなの?

2019/02/11(月) 16:58:51.46

>>62
CPUはなんでしたか?

2019/02/11(月) 17:08:20.36

MS-DOSでPC98使ってました
多分80386だったんじゃないかな？

2019/02/11(月) 17:11:09.55

RA21

2019/02/11(月) 17:20:25.05

なんかそれっぽいｗ
CADのデータを扱うアプリで、データが大きくなりすぎて
PCによっては読込すら出来なくなってしまい
アプリを立ち上げずに画面表示やプロッター出力する
プログラムを作れという指令が飛んだんです
データ構造は比較的簡単で、先頭部分に部品基本イメージ、
その後ろから、固定長で膨大な描画情報がある感じです
描画情報を64k未満の配列に分割して格納し、
それぞれの配列アドレスを格納した配列経由で操作するイメージでした

2019/02/11(月) 17:31:32.52

DXFのENTITIESセクションとかかな　頭に部品イメージ云々

2019/02/11(月) 17:40:57.96

そんな感じです
ソフトは有名な高額ソフトではありません
スタンドアロンのMS-DOSで動作可能なほど
コンパクトなものでした（名前失念ｗ）

2019/02/11(月) 17:51:01.28

>>63
コードが最適化されるのが前提なところがあるので
今はしたくてもちょっと難しい気がする
できることはできるけど、イマイチ学習効果が薄そう

2019/02/11(月) 17:52:29.43

そもそもPC-98シリーズで数百MBのメモリー載る機種あるのか？
HDDですら数十MBクラスが普通だったと思うが…

2019/02/11(月) 18:00:50.47

>>71
メガバイトって事は無いですね
初期の無印98で128KB、MAX640KBだったかな
386乗せたRAシリーズだと標準で640KB+1024KBだったと思う

2019/02/11(月) 18:55:56.19

あれ？
98note 使ってたけどメモリ増設で16MB 積むか12MBで妥協するかで悩んでいた記憶が…
勘違いかな？

2019/02/11(月) 19:06:33.17

Ap2でいくら載せてたかなぁ・・・。
20だか30M程度だったと思う。
パリ有りメモリで近所で扱ってる店も無かった時代なんで。

ぐぐったら公式で最大 73.6MB 、非公式で125.6MBまでいけたらしい。

>HDDですら数十MBクラスが普通だったと思うが…
それはSASI HDDじゃないか？VM時代か？

RXで340M、AP2で4G のSCSI HDD使ってたよ。

2019/02/12(火) 02:24:51.56

Cしかかけませんっていうの

2019/02/12(火) 02:25:15.35

Cしか書けませんっていうのは新卒就活のときに不利？
他にどんな言語を習得すればいいんだろうか

2019/02/12(火) 02:52:19.85

まず「他にどんな言語を習得すれば良いんだろうか」なんて言ってること自体がかなり的外れかな
手段と目的の順序が逆

あと面接のときに「何故C言語を習得し、それを何に使ったんですか？」って聞かれてちゃんと答えられる？

2019/02/12(火) 03:06:28.22

新卒であればプログラム言語そのものより他にアピールした方がいいと思うけどな
組み込みであれば現代制御理論、解析系であれば有限要素解析などC言語のプログラミングを応用する専門分野の知識を売り込んだほうがいいと思う

2019/02/12(火) 05:55:34.89

>>76
俺んとこではそれで充分
ただしCが書けるといってもHello worldの域を出ていないのは書けるうちに入らない
アルゴリズムの基本ができているかどうかを見ている
できていれば他言語が必要になっても泥縄ができるからだ
俺だってもともとアセンブラ屋で正社員3年目くらいのときにCの案件が回ってきて必死こいて憶えた

2019/02/12(火) 06:06:40.84

>>76
冗談抜きで一番大事な言語は日本語と英語。
開発職に論理的な表現力は重要。

2019/02/12(火) 09:06:46.70

AならばBであるを表現できますか？と聞く

2019/02/12(火) 09:17:13.28

64ビットCPUでもデフォルトの命令のオペランドが３２ビットだから
linuxでint_fast32_tを使うのは間違いだったんだな
多分６４ビットのアドレス計算も32bitの命令があるからパッディングとかも
起こらないだろうな

2019/02/12(火) 09:24:10.34

>>82 どこが間違いなの？

2019/02/12(火) 09:29:01.84

>>83
linuxはint_fast32_tが６４ビットになってるから

2019/02/12(火) 13:06:03.99

>>82の４行目で多分って書いたけど
６４ビットのムーブ命令は３２ビットなら０埋めされるから
ポインターの引き算をしなければ６４ビット整数を使う必要ないということだな

2019/02/12(火) 13:19:08.47

ポインタの引き算に使うんならptrdiff_tだね
int_fast32_tが何ビットかには関係ない

2019/02/12(火) 15:07:18.06

>>84
amd64では64bitが最速でないのに64bitが選ばれるのはおかしいっていう主張？

2019/02/12(火) 15:11:10.99

>>86
わからん

>>87
正解

2019/02/12(火) 18:52:25.91

このスレの平均年齢って幾つなんだ…（驚愕）
Cってもう若者は触らないっていう感じなんですかね。

2019/02/12(火) 19:06:37.74

ここに書き込みしているのは、人間じゃないから

2019/02/12(火) 19:13:42.99

若者のC言語離れが叫ばれて久しいからな。

2019/02/12(火) 19:16:16.52

50年前は、概ね若者だった

2019/02/12(火) 19:43:56.33

いまどきの若者ならみんなPythonに行ってるよ
やや年食ってる連中ならJavaやC#
職人気質で頑固な偏屈者はC++
Cはかつての栄光を引き摺って余生を過ごす老人の言語

2019/02/12(火) 19:46:30.05

Lunuxのソースって言語はなんだっけ？

◆QZaw55cn4c (ﾜｯﾁｮｲ e247-3ywI) · 2019/02/12(火) 22:27:27.41

>>93
でも言語を超えて活用されるライブラリ（libzip, libpng/libjpeg etc)は C で書かれることはあっても、OOP 諸言語で書かれることはないかと思うのですが？
C++ で記述される汎用ライブラリはありますか？

2019/02/12(火) 22:30:48.71

Cの使い手が減ったんじゃなくて他の言語の仕事が増えてるんじゃないの。
もともとサーバー側のシステム開発をCでやったりはレアでしょ。

2019/02/12(火) 22:31:50.68

むしろ立場が怪しいのはjavaじゃないか？

2019/02/12(火) 22:33:34.82

>>95
やっぱりアプリよりになっちゃうのは確かだね。
XMLのパーサとかだとオブジェクト指向の有り難みがある。

2019/02/12(火) 22:38:44.87

jsonをcで扱うのは涙がでますよ……

2019/02/12(火) 22:57:01.03

Cでがんばろうと思うと、glibみたいな形になっちゃいますね。

2019/02/13(水) 12:23:21.90

俺は有名な言語はほとんど全種類使えるから適材適所で使い分けてるは