C言語なら俺に聞け 161

2023/04/21(金) 14:05:20.18

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

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

2023/08/13(日) 22:00:40.70

C++でnewではなくmallocをあえて使う理由って何かあるのかな？

2023/08/13(日) 23:29:06.42

>>449
くわしくありがとう。そういう見方もあるのですね。
アンケートで拮抗というのはわかる気がしていて、その理由が入門書やサイトにあるのではと思うのです。

>>450はなぜそう思いますか。

2023/08/14(月) 00:14:53.81

void *が無かった頃はmallocもintやchar *を返していた時代がある
処理系渡り歩いてきた老害ほどmallocでキャストしたがるだけだろ
大した話でも何でもない

2023/08/14(月) 00:21:55.24

可読性を上げるためでもあるのでは？

2023/08/14(月) 00:30:57.60

>>454
可読性が上がるだろうか？少なくとも >>448 のように変数の型がその行に書いてあるようなケースでは
誤読の余地は全然ないように見えるので同じ情報を重複して書く意味が感じられない。

2023/08/14(月) 00:38:36.06

まあ確かに型がすぐ分かる場合は意味ないな。

2023/08/14(月) 09:03:40.40

>>448
組織(会社とか)のコードだと、どんな水準の人がメンテするか分からないので、冗長を採るかな。

> 冗長 int *p = (int *)malloc(400);

2023/08/14(月) 09:28:55.46

この話が一番冗長だtoomou

kanjidenakunatta

2023/08/14(月) 10:36:19.28

>>452
K&R の第二版 (日本語版) でもキャストは必要だと書かれているんだよなあ……。
本の最後に仕様をまとめているところでは暗黙に変換されることも言及されているのでおそらく改定漏れなだけなんだろうけど。
かなり長く定番の入門書だったのでこの本の影響も大きいと思う。

2023/08/14(月) 11:55:47.09

暗黙に変換って、プログラム書いてる本人の意図通りなら良いんだけど
意図と違った変換するとやっかいだな

2023/08/14(月) 13:20:28.84

ここがC言語スレだと思い出して欲しい

2023/08/14(月) 13:23:53.19

Cの暗黙の型変換なんて高が知れてるだろ

2023/08/14(月) 14:02:18.88

昔のmalloc()ってchar*とか返してた気がするな
最初っからvoid*って有ったのだろうか？

2023/08/14(月) 14:16:28.68

すべての戻り値はintである
ポインタかどうかは書いた人間がが判断する

2023/08/14(月) 15:03:08.99

(void)main(void)

**蟻人間** ◆T6xkBnTXz7B0 (ｽﾌｯ Sdba-F9Mj) · 2023/08/14(月) 15:17:16.05

>>464
AIが混乱するようなことを言わないでほしいも

2023/08/14(月) 16:43:05.60

>>464
それ LLP64 でも同じこと言えるの？

2023/08/14(月) 17:46:44.25

>>464
それはB言語のようなミニ言語やBLISSやアセンブラのようなシステム記述言語でよくあるやつだな。
そういう血塗られたルーツを持つCが普及してしまったのがこの大災害の原因ではあるが。

2023/08/14(月) 18:03:50.08

今は血を流さずに戦争ができます

2023/08/14(月) 18:07:41.52

ポインタじゃない構造体の代入はメモリコピーで、intじゃないよね

2023/08/14(月) 18:22:17.15

>>467
それですよ。

あと、実際の案件で
メモリバスが32より大きい環境でも、64ビット全部が使われてるとは限らないです。
あるビットにこう入ってたら40ビットのxxメモリ空間を指し、あるビットにこう入ってたら48ビットのyy空間を指す、とか
ポインタ値にも複数の種類がある（ように設計する事がある）

何が言いたいかというと全部intだなんてのは、分かってない証拠

2023/08/14(月) 18:39:04.59

可変長のポインタって、すごいな

2023/08/14(月) 18:42:29.14

昔は関数から戻り値として構造体が返せなかった
MSか勝手に実装した

2023/08/14(月) 18:47:31.20

返せなくても困らなかったけど
例えばポインタで返しているAPIはいくつかあるだろうし
呼出時に渡す構造体で返すやり方も普通にある（こちらの方が多いかも）

2023/08/14(月) 21:33:10.14

8051風のMCUにはメモリ空間が複数種類あるものがあって、どのメモリ空間をポイントするかによってポインタのサイズが1byteか2byteかに分かれるというのがありました。

2023/08/14(月) 22:08:33.35

>>473
K&R の初版 (1978 年) の段階では
構造体を関数の返却値に出来る仕様ではなかったのは確かだが
その制限は将来的に削除されるとも書いてある。
構造体を返せるようにするのは設計者の計画の内だ。

最初に実装したのが誰なのかは知らんが「勝手に」とは言えないだろう。

2023/08/14(月) 22:12:43.60

えてして実装が先で、規格になるのは後
というのはよくある話

2023/08/15(火) 18:53:02.89

規格が先行することなんて無いでしょ
出来レースみたいな例外を除けば

2023/08/15(火) 19:27:12.11

仕様もクソもANSI Cが出来るまでCに仕様だの規格だの自体がなかったよ
K&Rにしても当時はあくまで標準って位置づけだったし、各処理系で互換性のない部分が結構ある時代だった
そもそもK&Rって本自体Cの言語としての仕様を示すための本じゃなくて、Cの使い方を説明するユーザーガイド的な書籍だしな
大体、当のデニスリッチーからしてK&R初版の時点で自分のコンパイラではすでに構造体のやりとりを実装させてたんだから

2023/08/17(木) 17:55:25.45

K&Rはバイブルってだけ
宗教に喩えて開祖だか教祖だかが著したもの

2023/08/17(木) 17:57:11.47

バイブルに従え

2023/08/17(木) 18:38:44.78

C言語ルター派

2023/08/17(木) 19:50:44.50

般若心経

2023/08/17(木) 20:29:24.71

>>481
天国が来るだろう(構造体の戻り値)って書いてあるんだから天国の到来を疑ってはいかんだろｗ

2023/08/19(土) 16:55:05.41

剣かK&Rか貢納か

2023/08/19(土) 21:36:28.88

天国から帰ってくるのはヨッパライくらい

2023/08/19(土) 22:45:11.13

なーおまえ、c言語ちゅーもんはそんなに甘いもんやおまへんのや。もっと真面目にやれー

2023/08/20(日) 15:24:28.02

>>480
そういう感じでバイブルと呼ばれる本がいくつかあって、暫くしたら本のタイトルにバイブルって入ってるやつが出てきてアホかと思った事がある。
まあ、本のタイトルは出版社側がなんとなく売れそうな感じのものを考えて付ける事が多いらしいので仕方がない事なのかも知れないが。

2023/08/20(日) 15:26:20.60

>>487
レコードの回転数変えるように。

などと書いて話が通じる人は年寄り。

2023/08/20(日) 16:08:23.89

33回転、45回転、78回転

2023/08/20(日) 16:45:30.39

LP 33+1/3 回転を更に Long Play 化したのが LLP64 なの?

2023/08/20(日) 20:08:06.72

針ってまだ売ってるんだな、知らなかったｗ

2023/08/20(日) 20:37:34.57

逆に今はレコードブームだし

2023/08/20(日) 20:38:55.31

>>491
なんで回転数早くなってるねんｗ

2023/08/20(日) 20:40:51.45

回転数が速いと情報量が増える
要するに音質が良くなるんだろ

2023/08/20(日) 21:28:54.03

>>492
いまどきのレコードプレイヤーはレーザーで読み取るタイプのもあるんやが
音質や使い勝手よりも針を落とす感覚が好きな懐古趣味の人も
少なからずいそうやなと思う。

2023/08/20(日) 21:44:18.30

そのうち量子センサーなんてでてきて、
盤面を一瞬で読み取って再生する何て出てくるかもね
知らんけど

2023/08/20(日) 22:47:50.93

盤面を写真撮影して凹凸を一度に全部読み、後は再生するだけ。なんてのはできそうだな。

2023/08/20(日) 22:56:04.52

>>498
盤面をスマホで読み取らせて、それを再生してると思わせといて、実はラベルを解析して事前に録音済みのデータを再生するという、イカサマサービスを思い付いたw

2023/08/20(日) 23:03:56.28

こまわりくんはレコードの溝読めたな。

2023/08/20(日) 23:13:57.98

>>499
OCRプログラムでラベルの写真のタイトル部分の文字列読ませれば可能だが、問題は、ラベルに似せたものの上に書いた文字でも同じように読んで成功してしまうことだ。つまりレコード不要。

2023/08/20(日) 23:16:52.12

そういえばオープンリールも速度とトラック数にこだわりがあったな

2023/08/20(日) 23:22:22.29

>>501
さすがにレコードか位は判別可能なんで、そういう誤魔化しは除外できるでしょ
つうか、インチキなんだからどうでもいいんだけどねw

2023/08/20(日) 23:46:32.25

人間「このレコードかけて」
AIスピーカー「かしこまりました…あーあーはってしーないー」
人間「お前が歌うんかい！」

2023/08/21(月) 00:56:03.52

>>499
ワロタ

…でも「顧客が本当に必要なもの」はそれかもしれない

2023/08/21(月) 00:58:44.27

曲を再生して、それをスマホに聴かせ、曲名やアルバム名を調べる

というのは割と使ってる

2023/08/23(水) 12:33:50.88

localtimeでtm型のポインタが返ってきますが
これはfreeのような後始末はしなくても良かったんでしたっけ?
以下のt1の後始末です

#include <time.h>
#include <stdio.h>
int main () {
time_t t0 = time (NULL);
struct tm *t1 = localtime (&t0);
return 0;
}

2023/08/23(水) 12:46:33.56

不要
静的な領域なんで
その代わりスレッドセーフじゃないし
次に呼び出したら値が変わっちゃうのでそのまま使うならコピー必須

2023/08/23(水) 13:08:22.64

時間系関数の一部では同じ型のポインタを返す他の関数が
内容を書き換えることもあるということにも気を付ける必要がある。

つまり localtime が返したポインタが指す先は
gmtime の呼び出しで内容が変わるかもしれないし変わらないかもしれない。

2023/08/23(水) 13:18:07.19

>>508,509
あざーす!
思い出しました! そうでした

2023/08/23(水) 13:23:04.60

Cの標準ライブラリはメモリ操作関係やsprintfみたいな書式出力系以外は古臭くてほぼ使い物にならないから
システムのAPIを直接呼んだ方がいいよ
ガハハ

2023/08/23(水) 13:57:11.07

>>511
えー、お名前教えて
あなたとあなたのコードが関係するプロジェクトは全部避けたいですw

2023/08/23(水) 13:59:16.75

>>511
以前に以下のように書いてるところを
using boost::posix_time;
using std;
cout << to_simple_string (second_clock::local_time ()) << '\n';
C++にchronoが入ったので標準ではどう書けば良いのか調べてまして
以下の例を見つけそこでstd::localtime使ってるので聞きました
https://cpprefjp.github.io/reference/chrono/time_point.html
std::system_clock::time_pointってstd::ostreamに直接出力できないんですかね?
すれ違いかもしれんですが

2023/08/23(水) 15:39:04.68

同じ出力になる以下を使用することにします
$ cat test.cpp
#include <iostream>
#include <boost/date_time/posix_time/posix_time.hpp>
#include <chrono>
#include <ctime>
#include <iomanip>
int main () {
std::cout << boost::posix_time::to_simple_string (boost::posix_time::second_clock::local_time ()) << '\n';

std::chrono::system_clock::time_point p {std::chrono::system_clock::now ()};
std::time_t t {std::chrono::system_clock::to_time_t (p)};
std::tm lt; localtime_r (&t, <);
std::cout << std::put_time (<, "%Y-%b-%d %H:%M:%S\n");
return 0;
}
$ g++ test.cpp
$ ./a.out
2023-Aug-23 15:35:01
2023-Aug-23 15:35:01

2023/08/23(水) 16:21:15.95

>>512
Win32使ってCでコーディングするなら、Win32以外のAPIを呼び出す必要がないな

2023/08/23(水) 19:26:23.68

標準入出力関数を Win32APIだけで実装しなおすのはなかなか
車輪の再発明くさい案件になるな

2023/08/23(水) 19:53:06.85

残念ながらC標準ライブラリは古くて当たり前なんだ…
それを基準にして多くの人が回ってるから変えられないんだろう

でも人間の使える時間は限られてるので使えるものはうまく使ったほうがいい
メンテナンス性は知らないが

2023/08/23(水) 19:55:44.31

新しく作り直したのに使い物にならないのがWIN32APIの凄いところなんだよなｗ

2023/08/23(水) 19:59:10.27

win95ってほぼ30年前でしょ…

2023/08/23(水) 20:09:03.11

>>515
Win32？今の話の流れと全然関係ないです
私はLinux上で開発してるけど、それも関係ない

いいからお名前教えて

2023/08/23(水) 20:14:42.63

まあいいや。どうせ永遠に話通じないし、意味ないね、スレ汚しごめん> all

世界中のあらゆる人と意思疎通できる訳がない

2023/08/23(水) 20:17:30.73

>>515
あなたもごめんね、信念に従ってそのまま生きて下さい

2023/08/23(水) 20:26:41.70

何でWinで開発する人って標準ライブラリを毛嫌いしてるんですか？

2023/08/23(水) 20:37:13.42

システムコールとか呼んでなかったか？
たしか、目標をセンターに入れてスイッチ、だった

2023/08/23(水) 23:51:05.54

Win32とかゲーム開発する時は必須だろ
デバッグ中はprintf使ったりするけど、最終的にはバイナリに標準ライブラリのコードは含めない

2023/08/23(水) 23:56:23.25

GNUみたいにそれなりの人たちがディスカッションして作ったものではなく
いかにもマイクロソフトのサラリーマンプログラマたちが適当に会議して作った仕様に見えるので信仰の対象にしてるのは気がしれんｗ

2023/08/24(木) 00:03:34.65

>>523
Win16でmallocなんか使ってたらころされてしまいますよ

2023/08/24(木) 00:24:02.15

そこでfar pointerです

2023/08/24(木) 00:43:25.45

16ビットで十分なハンドル値をnearポインタにキャストするというのはいいアイデアだった

2023/08/24(木) 00:56:52.45

あぁなるほど!
16bitの頃のMSの貧弱な開発環境で育ったせいで
標準Cに対しては屈折した気持ちのままなのねw

2023/08/24(木) 01:06:43.62

標準ライブラリは古いつーか実環境を考慮してないだけでbit数はあまり関係ない…
理解してないのに無理に話に入ってこんでもいいぞ

2023/08/24(木) 01:26:43.52

>>526
いや、初期のマイクロソフト知らないのかよw
闘うプログラマーとか読んでみろ
めちゃくちゃおもろいよ
そんなことも知らないとか、モグリも大概にしろ

2023/08/24(木) 01:40:06.60

macOS(iOS)のアプリ作る時は、OPENSTEP由来のFoundationフレームワークを使うだろ
こうなるとprintfも使わずにNSLogばっかりだなw

2023/08/24(木) 02:24:55.77

そもそもC言語で新規開発すること自体がほとんどないので標準ライブラリ使うかどうかは今となってはどうでも良い。

**デフォルトの名無しさん** (ｽﾌｯ Sdb3-G+yN) · 2023/08/24(木) 07:36:25.07

macOS以前のmacのCはもっとひどかった黒歴史

2023/08/24(木) 12:16:23.79

>>532
その手の本を本気にするなよ恥ずかしいｗ
小説だぞ

2023/08/24(木) 12:58:04.14

>>536
それで煽ってるつもりかよw
知らないなら黙ってろよ

2023/08/24(木) 13:05:10.53

闘うプログラマーをディスる奴が居るとはな
さすがモグリは違うw

2023/08/24(木) 16:07:54.33

お前の聖書を貶されて怒るのはわかるが
ただの宗教を他人におしつけるなｗ

2023/08/24(木) 17:35:21.45

「綺麗なのは使われてないものだけ」みたいな格言をどっかで見た。

2023/08/24(木) 22:11:17.69

闘うプログラマー懐かしいな
随分と前に上下巻の頃に読んだ

うろ覚えで申し訳ないがwinodwsのAPIセットを考えるのにカトラーと幹部がクルーザーを1～2週間借りて
湖でクルージングしながらゆっくり考えたってところが印象的

クリエイターって感じで良かった

2023/08/24(木) 22:22:10.52

残りの人生がどれだけあるか知らないけどそういう環境でそういう仕事してみたいなと思う

2023/08/24(木) 22:45:31.31

C言語の開発って、
ジャングルの中、誰からも支援を受けずに
自給自足で生き残って敵に勝つイメージがあるな
必要な道具は自分で作るみたいな
恵まれた環境で使うには難しい世の中になってきた

2023/08/24(木) 23:08:24.66

闘うプログラマー読んだことないモグリだけど
カトラーがDECから来る前からWindows APIはあったよね？

2023/08/24(木) 23:36:03.41

Windowsは1.0からあるからなあｗ

闘うプログラマーはNTの開発物語
カトラーが関与したのはWindowsNTのAPIセット

2023/08/24(木) 23:47:18.67

カトラーが実装したのはカーネルレベルのAPIでしょ
Win32はその上にある

2023/08/25(金) 00:02:25.25

win32はもともとWindows NTの機能だよ
それにカーネルだけ実装してWindows NTを発売したとは思えないけど

3.1とかはwin16
ついでNTでwin32
そのあと95が出てくる

2023/08/25(金) 00:08:33.68

フリーセルはWIn32sで動いていたんだよな

2023/08/25(金) 00:18:17.29

あの頃はネット接続も一般的ではなかったから Win32s は雑誌の付録とかの形でよく入ってたのを覚えてる。
俺はテックウィンの付録CDから入れたわ。

2023/08/25(金) 07:12:39.12

>>533
macOS（Mac OS X)になって、旧Mac OS由来のCarbon APIのサポートのため
Foundationの下にCoreFoundationというCの共通ライブラリが作られたよね
すなわちC言語が基礎と。おそらく今でも
Carbon亡き今、CoreFoundationを直接使う必要はほぼないけど

書式出力は文字列のクラス（NSString/CFString)に含まれるというべきかな
NSLogも書式出力を受け付けるが、元々ログ出力関数なので