C言語なら俺に聞け 160

2022/12/28(水) 10:40:30.02

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

C17
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4713.pdf

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

C23 最新ドラフト
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.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言語なら俺に聞け 159
https://mevius.5ch.net/test/read.cgi/tech/1659623547/

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

2023/02/02(木) 14:37:47.00

sizeofて最近では()で対象を囲まなくてもいいんだってな
知らなかったｗ

2023/02/02(木) 14:52:29.74

最近もくそもANSI以降sizeof演算子に括弧が必要な時期ってあったの?
K&Rの頃でも要らなかった気がするけど

2023/02/02(木) 14:55:50.18

変数か単項式の場合な
型名とかはエラーだろうけど

2023/02/02(木) 14:56:34.41

型とオブジェクト(を表す式)のサイズを混同してるんじゃね？
複雑な式だと()があった方が読みやすい場合もあるけど、できる限りは明示的に使い分けたほうが

2023/02/02(木) 14:56:36.71

>>302
不完全型が「存在しない」ってこと？

2023/02/02(木) 15:03:22.53

別な話、BITMAPINFO構造体とかね

2023/02/02(木) 15:15:47.14

char*とvoid*なら問題ないのに
char**とvoid**だと代入時に警告が出るのはおかしい
ちなみにchar**とvoid*だと警告は出ない

**デフォルトの名無しさん** · 2023/02/02(木) 15:19:10.22

char
お前らこれ、なんて読んでる（呼んでる）？

2023/02/02(木) 15:26:34.49

テスト

2023/02/02(木) 15:27:11.52

>>304
いらなかったのを勘違いして付けてたのかもしれん
ちなみに1990年代HP-UX上で開発してた時代の話です

2023/02/02(木) 16:06:25.05

>>310
チャー

>>294
つうかヒープに確保するのはmalloc,calloc,reallocだけだと思ったら未規定なのか

2023/02/02(木) 18:25:47.28

>>313
言語仕様上は寿命が規定されているだけで、どこから確保するなどという詳細はない。
スタックとかヒープとかいう用語すら出てこないよ。

2023/02/02(木) 18:27:38.70

>>314
なるほどね

2023/02/02(木) 19:09:34.25

>>307
いや、なんかすまんかった
許してくれ

2023/02/02(木) 21:53:34.66

>>315
世の中には汎用機みたいにハードウェアスタック持たないマシンもあるしね

2023/02/02(木) 22:48:09.79

void hoge( char *src )
{
char hogebuf[strlen(src)+1];
strcpy( hogebuf, src );
...
}

みたいな使い方か
仕様にはないけど慣例としてローカル変数はスタックに取られるだろう
static char hogebuf[strlen(src)+1];
とするとデータセグメントに取られるがコンパイル時にサイズが決定できないのでコンパイルエラーになる

2023/02/02(木) 22:58:23.69

_alloca 使ってみるとか

2023/02/03(金) 02:49:42.07

普通スタックに取られるallocaがfree要らずでプロトタイピングに簡便だね
スタックだからBOするし、しない保証も得られないけど

ちゃんと固定長バッファ用意したり、ヒープ利用を考えるのは、とりあえず動くもんが出来てからやる派

2023/02/03(金) 11:57:56.75

c言語の標準入出力ストリームの
本当に基本的なことなんですが
わからずに困っています。
教えてください。

std::ofstream stream;

ostream << "ABCEFG";

この入力した文字列の"ABCEFG"を
右側3文字を削除して"ABC"にするには
どうすれば良いのでしょうか？

2023/02/03(金) 12:14:25.95

C++スレへ池
https://mevius.5ch.net/test/read.cgi/tech/1672409791/

2023/02/03(金) 12:29:37.05

再度スレ書込み致しました。
ご迷惑おかけ致しました。

2023/02/03(金) 20:02:26.07

>>318
この、外道が！
こんなんコンパイルエラーにしたる

2023/02/03(金) 22:09:59.33

ハッシュ君うるさいよ

2023/02/04(土) 18:01:20.17

>>321
それはC言語ではない。

2023/02/04(土) 23:59:34.16

C++は最初のアホなstream仕様から抜け出せずいまだに書式出力にすら苦労するのいいよね

2023/02/05(日) 00:32:35.28

文字列に埋め込んで置き換えるほうが楽だもんね

2023/02/05(日) 00:58:06.90

文字配列(へのポインタ値)は普通デカいから、ostreamのビット幅以上に左シフトすると0になるか、signedなら多分UD

2023/02/05(日) 02:05:11.68

君の言っていることがよく分からない。

2023/02/05(日) 02:13:54.95

C++でも一度もiostreamなんか使ったこと無いわｗ
かっこいいとでも思ったのかな？ｗ

2023/02/05(日) 14:25:38.00

そういや C++ の cout みたいなやつには printf() みたいなメソッドはないの？
Java だと System.out (java.io.PrintStreamクラス)に printf() が Java 1.5 から追加されたが。

2023/02/05(日) 14:52:22.62

C++20からformatってのが追加されたそうな

2023/02/05(日) 14:56:17.20

>>332
c++20 から std::format
c++23 から std::print と std::println

2023/02/05(日) 15:16:48.89

>>333 >>334
ありがとう。あるにはあったか。

2023/02/05(日) 16:27:06.84

C++20でstd::formatが追加されたよ

2023/02/05(日) 16:27:42.01

リロードしてなかったのか…失礼

2023/02/05(日) 22:53:24.77

char x=1
char y=2

上記のchar型変数のxとyを比較する際に関して質問させていただきます。

上記の変数に格納されている変数を比較する際はif文で問題ありませんか？
if(x==y)

それともmemcmpやstrcmpで比較するべきでしょうか？

2023/02/05(日) 23:00:33.79

問題無いよ
memcmp()は使えても
strcmp()は流石に無いわｗ
メモリにどう格納されているかなんてエンディアンやらで違うし
memcmp()はcharの配列での比較に普通は使うだろう

2023/02/05(日) 23:06:30.35

strcmp使うと、yもxも文字列である想定で比較するから
メモリー上の配置次第で変な結果が出る可能性がある

2023/02/05(日) 23:20:42.10

ご教授いただきありがとうございました。

2023/02/05(日) 23:41:43.70

>>338
charは(ちょっと変わってるけど)整数型なので、当然数値比較でok

何か付け加えるとすれば、整数型だからといってcharと他の整数型と比較/同値テストを行うのは、Cの自明でない算術変換が落とし穴になりがちなので避けた方が賢明

>>339
!memcmp(&a, &b, 1)
的な？
その発想に感心
何の役に立つのか俺には思い付けないけど、面白いからヨシ！

2023/02/05(日) 23:51:31.50

>>342
memcmp()も良く考えてみたらどうメモリに格納されているか分からないから使えないよね
intelなどのリトルエンディアンならそれで比較可能だろうけど
今ビッグエンディアンのマシンがあるのか分からないけど、昔あったpowerpcなんかはビッグエンディアンだったね

2023/02/05(日) 23:59:54.19

>>343
aがアドレスの取れない変数なら&aの時点で自明にダメだね

上で提示した比較バイト数が1の特殊ケースに限っては単なるunsigned charとしての比較だから、エンディアンネスは関係ないのでは

**デフォルトの名無しさん** · 2023/02/06(月) 00:52:52.00

>>343
ビッグエンディアンだろうとリトルエンディアンだろうと1バイトのcharの比較に影響しないんじゃね？

**デフォルトの名無しさん** · 2023/02/06(月) 00:53:39.48

ちんこ被った

**デフォルトの名無しさん** (ｽﾌｯ Sd5f-g5ke) · 2023/02/06(月) 01:11:21.66

複数byteから成るwordには並べ方の任意性はあるけど、単一byteからなるword内にbyteを並べる方法は一通りしかない、って事だね

2023/02/06(月) 01:12:53.01

>>345
charで例えばchar a = 1でリトルエンディアンだとmemcmp()で1バイト比較でも大丈夫だろうけど
ビッグエンディアンの場合、プロセッサの制約次第だろうけど必ずしも
01と1バイトのみでデータが入っているとは限らず
00 00 00 01みたいに4バイトで格納されてるかも知れないから
どんなマシンでも動くという前提で作るなら辞めておいた方が無難かなという風に思った

2023/02/06(月) 01:14:24.69

実際の所は分からないけど、char同士の比較は単にa == bで問題無いし
蛇足だったな・・・

2023/02/06(月) 01:38:26.50

エンディアンなんか関係ねーだろアホか

2023/02/06(月) 02:12:44.74

>>348
処理系/マシンが同一なら問題無い
Cのcharをuint_32相当として保持するマシンが仮に有ったとして、Cがcharのつもりで書き出し/読み返しを行い、unsigned char(とその配列)として比較する限りはCから違いは見えないよ
だって高級言語だもの()

バイナリデータのやり取り、詰め物あり、他言語プロセスとの共有メモリなら適切に変換するルーチンが必要だけど、それはCに限らず全てのプログラムに当てはまる事

2023/02/06(月) 02:49:15.07

32bit以下のデータを全て32bit値として扱うマシンを想定してるのかな？

それは最小アドレス単位、cで言うCHAR_BITSが32のマシンと言い換えられるよね
CHAR_BITSが何bitであろうが、cから見ればsizeof(char)==1である事には変わりがない

と言えば分かりやすいだろうか

2023/02/06(月) 06:44:27.92

>>340
変な結果どころかそもそも&xや&yの次のアドレスを読もうとすることあるから未定義動作だし

2023/02/06(月) 08:54:18.69

おそらく初心者であろう質問を深読みして暇をつぶすお前らに乾杯

2023/02/06(月) 11:15:52.75

MISRA-C 2004 の本がある。
MISRA-Cをやっていないと、2004の潜在型/2012の本質型が分からないはず

int 型未満の型を、4バイトに変換してから、元に戻す仕組み。
CPU には、int型未満のレジスタが無いので、使わない部分をマスクするしかない

こういう内部の仕組みは、C/C++ の本には載っていない

こういう変換を知っている香具師は、
むしろ初心者じゃなくて、かなり研究している香具師

普通の香具師は、こういう仕組みを知っているはずがないから。
C/C++の本には載っていないはず

2023/02/06(月) 11:23:50.95

そりゃ絶対とは言わないけどさ、詳しいのにあんな質問の仕方ならかなりひねくれてるわ

2023/02/06(月) 15:55:39.76

1 byte は 8 bit とは限らないってことだな。
1 octet は 8 bit 固定と決まっているが。

2023/02/06(月) 17:55:31.90

いやでもマシンによってバイトのサイズは変わるかもしれないけど、
少なくともC言語のchar型は8ビットでしょ？違うの？

2023/02/06(月) 18:07:02.20

>>358
ちがうよ。 CHAR_BIT がなんのためにあると思ってんの。

**デフォルトの名無しさん** · 2023/02/06(月) 18:13:28.24

>>355
そういうCPUの制約を気にしなくていいのが高級言語だと思うけど違うんかね？
そういうCPU相手のコンパイラならマスクするなり0埋めするなりしてるんじゃない？
想定外のCPU相手なら起こりえるかもしれないけど、それはしょうがないよね

2023/02/06(月) 18:36:57.74

Cは処理系定義が至る所にあるからな
intが2byteの環境もあるし

x86(x64)しか使わないと決め打ちできりゃいいけど
しょぼいCPU向けのしょぼいコンパイラのこと考えなきゃいけないとかなり面倒くさい

2023/02/06(月) 19:21:28.86

>>360
> そういうCPUの制約を気にしなくていいのが高級言語だと思うけど違うんかね？
そういう人はJavaなりC#なりを使えばいいと思うよ

2023/02/06(月) 20:45:09.59

>>360
システム記述言語として使うことが想定内にあるので高級言語の中では低級なほう。
半世紀前に登場した時点では高級だったかもしれんがそのときの事情を引きずり続けてたら高級になりきれないのもしょうがない。

2023/02/06(月) 21:35:59.24

中の下あたり？

2023/02/06(月) 21:49:50.35

>>363
> 半世紀前に登場した時点では高級だったかもしれんが
当時すでにPL/1とかPascalとかあったのに何を言ってるんだか

2023/02/07(火) 04:23:47.45

高級比べなんてウルトラしょーもない比較してんの初めて見たｗｗｗ

**デフォルトの名無しさん** (JP 0Hbf-lzBW) · 2023/02/07(火) 08:13:05.30

格納サイズが1octetな符号無し/符号付きの型

**デフォルトの名無しさん** (JP 0Hbf-lzBW) · 2023/02/07(火) 08:15:09.01

>>349
等しいかどうかだけなら
そこまで神経質にならなくても良いんじゃなかろうかと

2023/02/07(火) 08:51:22.05

>>355
> CPU には、int型未満のレジスタが無いので

x86にはAL/AHレジスタがあるぞ

2023/02/07(火) 09:53:53.00

>>359
つまりcharはマシンのバイトなのでmemcmpではバイトオーダーなんて気にしなくていいって話だろ

2023/02/07(火) 13:10:28.46

>>359
すまん、8ビット固定じゃなくて8ビット以上なんだな

>>370
char型は1バイト固定だからエンディアンは関係ないよな

2023/02/07(火) 17:31:48.89

>>360
Cは色々なCPUで使える使いやすいアセンブラのようなものと思った方が良い。
色々な工夫をしてあたかも高級言語であるかのように見える状態にまで持ち込んだのだ。

2023/02/07(火) 17:35:32.67

高級アセンブラ

2023/02/07(火) 19:08:47.78

名誉高級言語

2023/02/08(水) 04:20:38.79

なるほどね

2023/02/08(水) 08:22:16.03

UNIXの解説書に「UNIX OSの移植の為にC言語を開発した」的なことが書かれてたなぁ。

2023/02/08(水) 23:07:52.52

そうそう。

2023/02/08(水) 23:18:47.11

へーそうなんだ
デニスリッチーはそうは思ってないみたいだけど

2023/02/09(木) 00:04:11.97

デニスリッチーはゲームで遊びたくてC言語を開発した

2023/02/09(木) 06:30:22.83

>>376
その辺りの経緯はK&R本でも触れられてなかったっけ？

2023/02/10(金) 01:35:56.41

形にしたのはken, dmrだろうけど、個人的にはCの精神とCS的な観点はbwkに帰したい
the practice of programing, software tools (in pascal), the awk programing language、あたりからプロファイリング

ライターとしてずば抜けている、unixには特に拘らず節操無し、スタイルに拘りが強い、形式言語大好き

しかしk&rではセカンドオーサーだから、著作自体にどれだけ影響力あったかは？(言及あったっけ)
まあk&rは汚いコードを得意気に語るあたり、dmr成分多めな気がするなあ…

2023/02/10(金) 01:48:35.12

いやk&rなんだからファーストオーサーはkernighanだわ、素で間違えた

2023/02/10(金) 02:07:22.27

俺はunix系ソフトウェアツールはベル研が出してるカジュアル資料で学んだ口だけど、手元の年季入ってくたびれたハードコピーを漁るとほぼbwk著
https://i.imgur.com/n9gVQZ0.jpg

著者は意識してなかったけど、マジ伝道師

2023/02/10(金) 03:12:31.86

書籍はともかくC自体誰が作ったってデニスリッチーが1人で作ったんだろうが
なんで勝手にカーニハンに帰してんだよおまえの所業は朝鮮人よりヒドイだろｗ

2023/02/10(金) 04:20:45.54

>>384
日本PC市場でのPC向けUNIX(minix/bsd/linux)本格参戦前(90'後半？)の情報源は、彼に負う所が多かったろう、というバイアスはまあある
大学にでも所属してないとUNIX機に触る機会も無かったし、俺のように>>383のようなサンプルを見て仕様を想像しただろうアマチュア実装(だからmanページは付いてない)が流布していた

なぜCはUNIX文化から脱却できたのか？という(>>376を念頭に置いた)考察ね
bwkの著作にはCP/M, DOS, winプログラ厶の例が多いし、アーキテクチャ/OS間のポータビリティやアルファベット圏以外への進出を真剣に考えてた稀有な人なのは間違いなかろう

wchar_tやらを提唱したのはその一例だし、それを許容するためにC独特の柔軟な(=至る所unspecified)型/メモリモデルを拵えたわけで

あれ、今やどっちも負債になってるような…
いや理論上頑張ればできるけど、まあ頑張ればね？

2023/02/10(金) 08:31:20.48

カーニハンのWikipediaのページには、C言語の作成には全く関わっていないと書いてあるぞ
出典のインタビューにはリッチーが全部やったと言っている

**デフォルトの名無しさん** (ｽﾌｯ Sd5f-ZaaW) · 2023/02/10(金) 09:02:55.50

なんか色々とそれっぽい事書いてるけど中身全くないのにワロタ

2023/02/10(金) 13:52:45.73

>>386
だからライターとしての側面を述べてるのだが

2023/02/10(金) 14:24:32.35

相方を持ち上げるために
自分は何もしてないよと謙るやつか

2023/02/10(金) 15:51:06.46

wchar_tに関しては確か日本語版2版に訳者がKへ吹き込んだ、という記述が

いわゆるK&R以外にもK&R共著は無数にあるが、おおむねイノベーターがRでKがまとめ役というのは察せられるし、そこに異論はないよ

2023/02/10(金) 20:03:34.55

おまえらかっこつけんな

2023/02/10(金) 21:52:14.87

LISPに言ってくれ

2023/02/10(金) 22:02:01.42

カギ括弧で勘弁

2023/02/11(土) 17:33:42.32

名前カニチャーハンぽいから仕事してなくても許すね

2023/02/11(土) 21:40:15.68

>>394
はずしたなｗ

2023/02/12(日) 05:54:47.01

>>394
かに飯じゃないんだ。charは何処へ消えたの。

2023/02/13(月) 03:01:58.65

Kani & chaRhan

2023/02/13(月) 03:07:30.87

こん平を思い出すな…

2023/02/14(火) 09:52:16.15

カニ入ってる、あぁんリッチ～

2023/02/14(火) 15:36:46.24

ファミ通のお習字コーナーかよｗ

2023/02/15(水) 16:00:13.19

最近、Cが熱いのは、どのフィールドですか？

pythonなら、人工知能、みたいな

2023/02/15(水) 16:15:56.41

エンベデッド

2023/02/15(水) 16:24:04.96

純粋なCって実際使われている気がしないんだがなぁ
結局C++使ってるんじゃね？
組み込みとかでさえC/C++じゃなくなりつつあるような