C言語なら俺に聞け 157

2021/06/28(月) 11:22:51.50

!extend:checked:vvvvv:1000:512
(新スレ立ての際上記コマンドを2行書き込んでください)
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言語なら俺に聞け 156
https://mevius.5ch.net/test/read.cgi/tech/1601271690/

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

2021/07/26(月) 14:20:07.95

https://dev.grapecity.co.jp/support/powernews/column/clang/031/page02.htm
観たけど余談が多過ぎてなかなか本題に入らずイライラするω

あと確かに初心者向けではない
入口にたどり着く前に挫折する文章の書き方だと思う

2021/07/26(月) 14:22:50.46

>『C実践プログラミング』の17章「高度なポインタ」にある解説が

君にとって判り易かったのかも知れないが
君の感想文を読むとあまり良い本ではなさそう

2021/07/26(月) 14:35:32.21

ama zon 4900900648

2冊目か3冊目に読む本
2005年6月21日に日本でレビュー済み
以前、某雑誌の特集で、Ｃがわかればすべてがわかるというのがあり
ましたが、まぁヨイショのし過ぎな文句なのかもしれませんが、依然
として、知っておいたほうがよい言語だと思います。
Ｃでプログラムするような機会は、ほんとここしばらく全くないです
けど、Ｃを勉強していたおかげで今までかなり助かってます。なんと
いってもＣの影響を受けた言語は多いですからね、色々応用がきくも
のなのですよ。
で、肝心のこの本ですが、前訳本でも書きましたが、初心者を脱しよ
うとしている人にとっては最適だと思います。よくありがちな、Ｃの
文法やテクをただ書いているだけの本とは違います。プログラムのス
タイルやプログラムの仕方についての記述が数多くあります。
Ｃのような言語の場合、どのようにコーディングするのか、言い換え
るとWHATだけでなくHOWについて必ず考えなくてはならないと思いま
す。この本は常に、HOWについて意識した記述をしており、そういった
点が、この本を推奨する大きな理由です。
ただ、この本だけで、ポインタとかのキモはさすがに理解できません
でしたので、別の本を読む必要があります。

2021/07/26(月) 14:52:24.77

>>74
>(データ構造、また、その管理においては) 指している型が同じなのか違うのかで
>ことさらに区別して考える意味はあまりないように思う。

それ

>>94
>C言語の演算子に自己参照型構造体の操作に非常に便利な演算子
>構造体ポインタ演算子->が用意されているということが決め手なのかな。

まだ誤解してると思う

2021/07/26(月) 14:57:02.20

不充分。この本だけでは足りない。
2019年4月13日に日本でレビュー済み
敢えてこの本を買う意味が分からない。
20世紀に買ったが、この本だけでは解決できない問題があり、投げた。

よくある fgets & sscanf のコードの部分では、入力バッファのクリアを行う方法が書かれていなかった。
当時はインターネットのコンテンツが今ほど発達しておらず独学ではお手上げ。
他にも何か問題点があった気がするし、今や様々な解説サイト、また「よくある解説サイトの誤りを指摘するサイト」で足りる。

セキュリティ対策についても、wikipediaのサンプルコードやjpcertの「CERT セキュアコーディングスタンダード」など、今では豊富な資料がネットで入手できる。必要なら英文資料だってネットで容易に入手できる（もちろんC99の規格文書も）。

2021/07/26(月) 16:06:22.39

諸々のコンパイラや環境がC11に準拠するようになって久しく、また業務やOSSでもC11で導入された新機能を使うようになってきてる印象があるんだけど（要出典w）、こと並列処理に関してはまだまだC99+POSIXスレッドを使ってた方が良さそうね。
久しぶりに並列処理を書いてみようと思ったんだけど、C11で標準規格として導入されたthread.hに対応してるコンパイラが現時点でも（特にUnix系で）ほとんどないことが意外だった。
今のところthread.hをUnixで使いたかったらmusl Cくらいしか選択肢がないし、
ttps://www.etalabs.net/compare_libcs.html
3年前の電子掲示板の書き込み（要は典拠性が低い）ではあるけど
ttps://www.reddit.com/r/C_Programming/comments/94acpl/c11_vs_pthreads/
ほとんどの人がC11ではなくPOSIXが定めてるスレッド使ってるみたいだし。

せっかく汎OS的に並列処理がかけそうな規格なのに、もったいないというかなんというか。。。

**ハノン** ◆QZaw55cn4c (ﾜｯﾁｮｲ 7be9-8Qmj) · 2021/07/26(月) 20:52:03.28

>>99
＞入力バッファのクリアを行う方法
入力バッファのフラッシュは確か MS のコンパイラだけでしか使えない環境依存だったかと
行末に \n が在る、とかのルールがあれば、それが出るまで読み捨てればいいのですが、そういうルールがなければどうしようもない気が

**ハノン** ◆QZaw55cn4c (ﾜｯﾁｮｲ 7be9-8Qmj) · 2021/07/26(月) 20:54:03.66

>>100
＞せっかく汎OS的に並列処理がかけそうな規格

C11 は調べていませんが、C++ と比べてどうですか？私は C++11 以降でそういうのを書いています‥‥

2021/07/26(月) 21:07:00.92

>>100
C11 のスレッドはオプショナルなのでスレッドを提供しなくても C11 準拠を名乗れる。
C の立場からすれば標準ではあまり高レイヤな機能を要求するのは気が引けるだろうし、
かといっていまどきスレッドに全く触れないでいるというわけにもいかないという妥協なんじゃないかな。

C11 のスレッドの基本的なモデルは POSIX のスレッドとそんなに違いがない (名前が違う程度) ので、
かえって乗り換える強い動機にならないのかも。

62 (ﾜｯﾁｮｲ 2b28-h4Fy) · 2021/07/26(月) 22:30:44.17

>>96
>>98

ご指摘ありがとうございます。
構造体リストについてもう一度勉強しようと思います。
（他の方も書評の引用などありがとうございます）
『C実践プログラミング』のAmazon書評にあった
『Cクイックリファレンス第2版』というのを試しに読んでみたところ，
かなり規格網羅的で丁寧だと感じたので，
当面はこれで勉強してみようと思います。
こちらの書籍には「
struct data {
// some code...
struct data *next
}
」という形のコードの解説そのものはありませんが，
ポインタの解説をCの規格に沿ってしてくれているので
かなり良い教科書として使えそうです。

以後言い訳::
いまのところ，まだC言語の規格が全て頭に入っている状態ですらなく，
ましてや実際のプログラミング作法も分かっていない段階なので，
ある書籍を見たときの（現代における）正確性・信頼性の判断が
できないんですよね……。
『C実践プログラミング』は昔のO'Reillyが出している書籍なので
ある程度信頼できるかな，と思って読み進めていたんですが，
（実際，本質を突いていて分かりやすいと感じる部分も多くありました）
時代的にも正味の内容的にも現代において参考にすべき
良書とはいいがたいのかな……？

2021/07/27(火) 05:25:18.45

ポインターで次へつないでいく、リストみたいな自己参照型。next pointer。
同じ構造体のリスト。
動的関数型のElixir は、片方向リストを使う

a → b → c → d

struct data {
struct data *next
}

これが両方向リストなら、struct data *prev も持たなければならない。
次・前の2方向へ、たどれなければならないから

a ←→ b ←→ c ←→ d

ポインターに、null を代入すれば、次・前は存在しない。
つまり、終端を表す

詳細は、アルゴリズム・データ構造を参照

2021/07/27(火) 10:57:27.91

>>98
いや確かに -> は自己参照する構造体を使うときに好都合だぞ
(*(*p).next).next が p->next->next で済むんだから

2021/07/27(火) 11:05:53.35

双方向で b を削除するのに
b->prev->next = b->next;
b->next->prev = b->prev;
b さよなら
これで済むからありがたい表記ではあるな

2021/07/27(火) 11:39:36.88

>>107
あ、なる
良く出来てんな

2021/07/27(火) 11:42:04.93

忘れずにちゃんと成仏させろよな

2021/07/27(火) 16:12:06.91

>>106
屁理屈

2021/07/27(火) 17:25:02.44

>>110
異論があるなら堂々と言えよ
自分の意見が屁理屈かどうか見せずにそれを言うのは卑怯だぞ

2021/07/27(火) 18:25:54.21

そもそも話がかみあってない
こっちは気付いてるけど
君は気付いていない
ただそれだけ
だから屁理屈

2021/07/27(火) 18:38:55.37

結局、自分は尻尾を見せないんだな
やりあう価値もないゴミだな、唾棄

2021/07/27(火) 18:52:50.94

自己参照型の構造体で固定段数のリンク手繰るのに便利にはなってるけど
自己参照型の構造体があるがゆえに -> ができたんじゃなく
単にポインタの指し先（構造体）のメンバを　(*). じゃ遠回りなので直接指定したいがための存在だと思ってる

2021/07/27(火) 19:55:06.48

>>114
同意だが、.で共用出来なかったんかね？
関数と関数ポインタみたいな感じで、左辺がポインタだったら逆参照してからメンバアクセス。

2021/07/27(火) 23:09:50.37

>>115
Rust ではそうしてるんだから C でも最初からそういう選択も出来たはずではあると思う。
だけど違うことをするのに同じ見た目にするのが良いかどうかというのは微妙なところ。
どちらが良いと一概に言えるもんではないからな。

2021/07/28(水) 00:16:37.31

CはRustの派生だったのか、知らなかった

2021/07/28(水) 00:34:49.35

>>117
派生関係も時系列も前提にしてない。
別の選択をしたものが事実として存在するので可能であるのは疑いないと言ってる。

2021/07/28(水) 00:53:01.29

FortranやCobolにも導入して欲しいのか？

2021/07/28(水) 01:00:09.40

うーん？

ある構文（範疇としては演算子の形態論？）について，
「他の言語での採用例があるからC言語がそういう構文を持っていても不思議じゃなかった」
という話が展開されていたと思うんですけど，
どうして「RustはCの派生」とかFortranやCOBOLの構文の話になったんですかね……？

2021/07/28(水) 01:46:29.97

バカだから

**デフォルトの名無しさん** (JP 0Heb-qCnf) · 2021/07/28(水) 09:52:29.36

C99以降で真偽型をboolのように表記したいときは<stdbool.h>を読み込みますが，
規格票には「型boolはマクロとして定義しろ」とあります。
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2596.pdf#section.7.18

一般に既存の型から新しい表記の型を定義するときはtypedefを使うべきだと
（典拠は失念したのですが）聞いたことがあります。
たしか，コンパイラによる検査があったりより構文的に厳密になったりするから，
というような理由だったはずです。
真偽型boolがtypedefではなくマクロで定義されている理由ってなんでしょうか。

思い当たる理由としては，C++との互換性がありますが，それをC言語の規格で考慮する意味がない
（というか，C++の規格をC側から参照すると循環的になってしまう気がする）
気がします…。
C規格の論理的根拠の真偽型にかんする節も読みましたが，
「typedefではなくマクロを使う理由」は記載されていませんでした。
http://www.open-std.org/JTC1/SC22/WG14/www/docs/C99RationaleV5.10.pdf

2021/07/28(水) 10:26:19.41

マクロだと#undefできるから自分でboolを定義してる古いコードのための移行措置っぽいね
<stdbool.h>をincludeしなければいいと思うけど間接的にincludeされるケースもあるんだろう
_Boolの方は予約語になってる

7.18 (4)
..., a program may undefine and perhaps then redefine the macros bool, true, and false.
プログラムはbool、true、falseマクロをundefineして再定義することができる

7.31.11 (1)
The ability to undefine and perhaps then redefine the macros bool, true, and false is an obsolescent
feature.
⇒　bool、true、falseをundefineして再定義できる特性は廃止されつつある

2021/07/28(水) 12:14:26.76

Win32APIとか使わずに
Cの標準関数でカレントディレクトリではなく
今実行中のexeのpathを得る方法はどれですか？

2021/07/28(水) 12:21:24.51

int main(int argc, char* argv[])
の　argv[0] で実行ファイルへのフルパスがえられるのは環境依存だったかな･･･

2021/07/28(水) 12:22:28.68

mainの第2引数の argv[0] にはコマンドラインから入力した通りのコマンド名が入っているんだっけ
フルパスで入っているんだっけ

2021/07/28(水) 12:24:05.30

被った
たしか Windows はフルパスだったような…
違ってたらごめんなさい

2021/07/28(水) 12:27:22.89

実装に依存

2021/07/28(水) 12:35:40.50

Windows という書き方はよくないかな
シェルの実装によると思います
なので、WSLに持っていくと期待通りに動かなかったりするかもしれません
ここでは Windows限定でよさそうだけど

2021/07/28(水) 13:20:46.92

え？そう？ Windows で C 使う人って今はあまりいないのでは? Linux とかなら分かるけど。

2021/07/28(水) 13:41:10.64

powershellはフルパスだけどｃｍｄは入力のまま
結局はCreateProcessに渡した文字列なのでフルパス前提にしちゃだめよ

OSに依存しない方法で確実なのはないよなぁ
argv[0]が
ファイル名のみ：カレント＋環境変数pathを走査
相対パス：カレントと連結
絶対パス：そのまま
とかやればそこそこいけるだろうけどめんどくさいな

2021/07/28(水) 13:54:41.98

純粋なC標準の範囲では不可能な気がする
カレントディレクトリをとるgetcwd()もPOSIX（unistd.h）だし
C言語の標準ライブラリにはディレクトリ階層の概念自体がなさそう

2021/07/28(水) 13:55:33.60

>>131
powershell と cmd で違うのか…
なんでそうしたんだろ
何れにしても、けぅこう面倒なのね

2021/07/28(水) 14:05:55.87

みなさんありがとうございます
dirname(argv[0]) したら argv[0] が壊れました
ほんとうにがりがとうございました

**蟻人間** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd33-vTy/) · 2021/07/28(水) 14:19:05.25

本当のニガリが10、あったと？

2021/07/28(水) 14:21:25.34

これ解決策じゃなくて愚痴なんだが、main()関数が使えるのはホスト環境で、つまりmain()関数のargv[]引数は「OSによる支援」を前提にできるんだから、実装依存じゃなくて「argv[0]には実行されたファイルのOSにおけるパス名が格納される」みたいな仕様にしてもよかった気がする。
それこそstdint.hみたいに、多種多様な機器への対応を考えなくてもいい関数なんだから、実行環境のファイルシステムやらをある程度は仮定しちゃってもいいわけで。

2021/07/28(水) 16:21:41.95

ファイルシステムもOSもない組み込み機器もあるわけで・・・

2021/07/28(水) 16:21:59.41

>>136
どんな OS でも Unix 風のファイルシステムを採用しているというわけではなくて、
たとえば BTRON が採用しているファイルシステムでは
同名のファイルが存在してよく、ディレクトリのような階層化は存在しない。
全体で唯一に区別できる名前 (フルパスに相当するもの) がない。

OS だってファイルシステムだって多種多様なんで、
起動時に「なんらかの」文字列で情報が与えられるということ以上は
環境依存にならざるを得ないよ。

2021/07/28(水) 16:25:16.04

>>137
その場合は通常の main 関数からの起動にはならない (main に意味のある引数が渡されないか特別なスタートアップ経由で起動される)
ので、「main に値が渡されるならば」それなりの OS が仮定できるというのが >>136 の言ってることやで。

2021/07/28(水) 18:03:22.93

>>139
すげぇ
たまには正しくわかりやすい説明できんじゃん
ちょっと見直した

2021/07/28(水) 18:21:15.71

コード記述してて実行ファイルのフルパスが必要となるんだから
それなりのOSから叩き起こされてること前提よね

2021/07/28(水) 18:43:00.22

>>138
> BTRON が採用しているファイルシステムでは
> 同名のファイルが存在してよく、ディレクトリのような階層化は存在しない

知らんかった……。
調べたところBTRONは組込み機器向けのファームウェアじゃなさそうだし，
ホスト環境=「それなりのOSが期待できる」環境あっても，
「あるファイルのパス名が存在して，その絶対値が文字列として一意に定まる」
ことさえ期待できないのか……。

2021/07/28(水) 18:54:22.92

>>134
dirname()は引数を破壊するのでコピーしてから渡すべし
今回のケースでは結局ダメだけどｗ

2021/07/28(水) 18:56:43.36

> [...] the array members argv[0] through argv[argc-1] inclusive shall contain pointers to strings, which are given implementation-defined values by the host environment prior to program startup.

http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2596.pdf#section.5.1.2.2.1

C2xでもargv[0]に何が格納されるかは「実装依存」って書いてあるね……めちゃくちゃ残念だ。
あとこれ読んでて気が付いたけど，「ホスト環境」ってhost environmentじゃないのね。
hosted enviromentだから，正確に訳すなら「ホスト済み環境」とかのほうが良いのかな？

2021/07/28(水) 22:12:53.76

そのhosted environmentはプログラムの実行環境（execution environments）を
・freestanding（自立した環境＝OS無しの組み込み系）
・hosted（OSにhostされた環境）
に分けたものだからOSとかプラットフォームを指すホスト環境とはたぶん別の意味

2021/07/30(金) 19:40:44.58

hosted environmentの概念には明らかにUNIXが背景になってるね
MS-DOSだのCP/MだのROM BASICだのまでは想定してない

2021/07/31(土) 21:45:13.12

>>146
くわしくしりたいです。

「OSというのものは高性能である」という前提が
Unixとかでしか通用しなかったってことですか？

2021/08/01(日) 11:25:29.19

>>147
性能とかじゃなくてモデル化の仕方が多様という話。

たとえば古い時代の BASIC (N-BASIC など) は環境変数やコマンドラインという概念は持たないが、
違う形でデータを受け渡す方法は持っていて、どちらが高性能かというようなものではない。

2021/08/01(日) 18:29:17.83

>>148
今調べた知識なのでいろいろ間違っているとは思うのですが，
N-BASICとかってそもそも「OS」なんですかね……？

「hosted environmentという概念はUnixを想定したもので，
古いBASICでは通用しない」
という話からは，
1. Unixと古いBASICが同列の概念である
2. hosted environmentは「OSがある環境」を指している
ようなことが読み取れるんですが，

1. N-BASICはUnixのような
「機器→抽象化層1 (HAL/OS) →カーネル→シェル」
みたいな構造では表わせない位置にあるため
Unixと同列（あるいは類似）の概念として扱うのは
違うような気がすること

2. そもそもhosted environmentは
C2x規格の5.1.2.2で規定されている動作を実装した処理環境であって
「OSがある環境」を指してはいないこと
（だからUnixがどう，みたいな話は関係ない？）
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2596.pdf#paragraph.5.1.2.2

などから，ちょっと納得しがたいです……。

2021/08/01(日) 18:40:30.22

IPLで起動して、ハードウエアへのアクセスを代行し、
コマンドをタイプして結果を文字で表示するCUI
という観点からはUNIXとBASICは同列だよ

MS-DOSでのデバドラはお行儀でしかなく
アプリが直接I/Oなんて珍しくもなんともないが
一応argc, argvという概念はあった

言い出すとマイクロカーネルをヨイショする連中を嘲笑うように
モノリシックカーネルでいったLinuxは、じゃあOSに非ずなのかと

OSとは何か、何が該当し、何が該当しないのかは
見方が色々で誰もが認める基準はなかなかできない

2021/08/01(日) 19:45:48.16

なんかわざと煽ろうとしている？

2021/08/01(日) 20:00:02.07

OSから外れた例をわざわざ挙げたのだろうと思っていたが、OSが何か分からない人でしたか...

2021/08/01(日) 20:46:27.86

>>149
> N-BASICとかってそもそも「OS」なんですかね……？

---------- JIS X 0001-1994 ----------
オペレーティングシステム， OS（省略形）

プログラムの実行を制御するソフトウェアであって，
資源割振り,スケジューリング，入出力制御，
データ管理などのサービスを提供するもの。

備考
オペレーティングシステムは，ソフトウェアが主体であるが，
部分的にハードウェア化することも可能である。
-------------------------------------

まあ要するに OS がどのような構成を持つものなのかというのは曖昧で、
Unix 的な立ち位置も OS が持ちうる構成のひとつでしかないんよ。

> Unixと同列（あるいは類似）の概念として扱うのは
> 違うような気がすること

「モデル化の仕方は多様」という例のひとつとして N-BASIC を出している。
違うように感じられるならそれは提示した意図通り。

2021/08/01(日) 20:59:26.94

この人の理解が間違えている。
わざと言っているとしたら悪質

2021/08/01(日) 21:23:59.60

>>154
俺もわからん。
何がどう間違ってるのか説明しておくれ

2021/08/01(日) 21:37:13.51

N-BASICは確かにハードウエアを直接制御できるという意味では
OSに近い。ただ今のOSとは全然違う。BASICだと遅すぎるので
大半はマシン語で直接書いてある。今のOSとは考え方が違う。

2021/08/01(日) 21:43:51.38

BASICそのものはマシン語で書かれているんだが

2021/08/01(日) 21:54:08.54

>>156
たしかにそういう意味では「OS」といえるのかもしれないですね。
ただ，それだと組込み機器のファームウェアだって
機器を操作できる，対人インターフェースがあるという点ではOSといえることになりません？

2021/08/01(日) 21:58:23.19

なるね
何か困るの？

2021/08/01(日) 22:05:54.64

>>158
はっきりした基準はないという前提だけどぼんやりとした概念的な部分では
OS はアプリケーションソフトの対比的なものだと思う。
用途ごとのアプリケーションソフトを起動するという前提がないなら機能的に OS 相当のものを
含んでいても普通は OS とは言わないんじゃないかな。

2021/08/01(日) 23:18:55.12

ホントにOSだと主張するなら、ぜひWindowsの仮想環境で動かしてみてくれ

2021/08/02(月) 00:18:03.59

もしかして仮想マシンとエミュレータ混同してる？

2021/08/02(月) 00:39:04.73

動かせないのなら、回りくどい事言わず、無理ですと言えば済むよ

2021/08/02(月) 01:06:43.81

amd64で動くN-BASICがあるならできるんじゃない？
無いなら無理だわな

2021/08/02(月) 05:11:39.16

>>163
>>151

2021/08/02(月) 07:46:31.20

最近はスマホのカメラ部品にTRON OS入ってるんだって？
もうBIOSやファームウェアもOSになるんじゃないかとも思っちゃう。

2021/08/02(月) 10:11:13.69

>>152-153
BIOS: BI + OS
DOS: D + OS
OSとは

2021/08/02(月) 10:12:43.19

>>154
>わざと言っているとしたら悪質

ほんそれ
最近そういう書き込みが多い
5chから人を減らす作戦だろう

2021/08/02(月) 11:03:41.91

>>167
> BIOS: BI + OS
ネタか？
Basic Input/Output System やぞ

> DOS: D + OS
こっちは合ってる

2021/08/02(月) 12:33:14.68

>>169
もちろんネタと書いてあるのでネタなんでしょ。

2021/08/02(月) 13:13:02.28

Basic Interpreter OS

2021/08/02(月) 13:17:25.48

質問です
int flagA = 3 == 3;
int flagB = 3 == 3 == 3;
int flagC = 3 == 3 == 1;
の結果が
flagA : 1
flagB : 0
flagC : 1
になるのですが
flag B とか flag C は何が怒っているのでしょうか？

2021/08/02(月) 13:31:37.39

>int flagB = 3 == 3 == 3;
↓
int flagB = (3 == 3) == 3;
↓
int flagB = (1) == 3;
↓
int flagB = 0;

>int flagC = 3 == 3 == 1;
↓
int flagC = (3 == 3) == 1;
↓
int flagC = ( 1 ) == 1;
↓
int flagC = 1;

2021/08/02(月) 13:31:42.08

int flagD = 3 != 3;
int flagE = 3 != 3 == 0;
int flagF = 3 != 3 == 1;

flagD : 0
flagE : 1
flagF : 0
になります

2021/08/02(月) 13:31:46.39

タイホするっ！！　ダーン　ダーン

int flagB =
ここまでと
3 == 3 == 3
が別のパーツになっていて
== は左から結合するので
(3 == 3) == 3 となり真は1になるので
1 == 3 で偽すなわち0だ

2021/08/02(月) 13:41:18.14

解決しました
ありがとうございました

2021/08/02(月) 16:38:34.45

俺が怒っている

2021/08/02(月) 19:33:02.95

演算子の優先順位って覚えるのヤダー。自分書くと括弧だらけだわ。
どの辺が塩梅なんかねー？明示的でないと駄目よってコーディングとかもあるし。

2021/08/02(月) 19:49:19.60

それでいいよ

2021/08/02(月) 20:03:46.84

& ^ | なんかのビット演算が比較よか低いのが微妙に嫌

2021/08/03(火) 09:51:48.02

憶える気のない者は成長しない

2021/08/03(火) 10:01:19.19

結合の優先度は、自分が分かっていても
記憶があやふやな人が不安になるといけないから
結局カッコを明示的に描くかな…

2021/08/03(火) 10:17:52.20

中学のマイコン部かよ

2021/08/03(火) 13:41:40.87

>>181
覚える気があっても、覚えさせられる気がしねー。

2021/08/03(火) 13:45:58.11

自分を磨くのは本人なので
そんなお節介は考えなくていい

2021/08/03(火) 14:20:08.34

CでC++の純粋仮想関数のような事をやりたいのですができますか？　疑似インターフェースです。

2021/08/03(火) 14:30:35.30

typedef struct iunknown iunknown;

struct vtable
{
int (*query_interface)(iunknown*, int, void**);
int (*add_ref)(iunknown*);
int (*release)(iunknown*);
};

struct iunknown
{
long count;
vtable* vtbl;
};

みたいなことか？

2021/08/03(火) 14:31:17.98

あ、いかんvtableのtypedef忘れたけどまあ許せやｗ

2021/08/03(火) 14:32:38.22

のような事の解釈余地に幅がありすぎ

2021/08/03(火) 19:27:01.81

幅があると言うなら狭めるようなヒント書けばいいだけ
たたき台として>>187はそれほど悪くないと思う

2021/08/03(火) 20:41:05.50

>>187
スゴーイ　感謝感激　ありがとうございます。

typedef struct {
void (*interface_a)();
void (*interface_b();
,
.
} TINTERFACEXXX;

typedef struct {
TINTERFACE ia;

} TOBJA;

なんてリレーションスタイルも考えたんですが、
いずれにしろ、クリーンアーキテクチャーのCでのSOLID原則ができるというところまでこぎつけました。
ありがとうございます。

2021/08/03(火) 23:48:19.32

COM最強

**デフォルトの名無しさん** (JP 0Hee-YhuA) · 2021/08/05(木) 14:10:06.71

奥村晴彦『改訂新版 C言語による標準アルゴリズム事典』の
「改訂新版序」に、
> 現代の慣習に従って、[…] EXIT_SUCCESSを0にしたりした
とあるのですが、EXIT_SUCCESSマクロ変数を使った方が
定数即値を決め打ちするよりも可搬的であり、
それこそ「現代の慣習」であるように思うのですが、
実際はEXIT_SUCCESSより0を使う方が「現代的」なんですかね。

なお、誤植も疑ったのですが、集録されている実際のコードにおいても
return 0;と書かれていました。

2021/08/05(木) 14:30:14.22

>>193
0以外は1以上も-1以下もあるし、下手すりゃ数値以外の可能性すらあるけど
0 は絶対0なので、少なくともこれに関してだけは
私は許そう