C言語なら俺に聞け 157
■ このスレッドは過去ログ倉庫に格納されています
>>99 >入力バッファのクリアを行う方法 入力バッファのフラッシュは確か MS のコンパイラだけでしか使えない環境依存だったかと 行末に \n が在る、とかのルールがあれば、それが出るまで読み捨てればいいのですが、そういうルールがなければどうしようもない気が >>100 >せっかく汎OS的に並列処理がかけそうな規格 C11 は調べていませんが、C++ と比べてどうですか?私は C++11 以降でそういうのを書いています‥‥ >>100 C11 のスレッドはオプショナルなのでスレッドを提供しなくても C11 準拠を名乗れる。 C の立場からすれば標準ではあまり高レイヤな機能を要求するのは気が引けるだろうし、 かといっていまどきスレッドに全く触れないでいるというわけにもいかないという妥協なんじゃないかな。 C11 のスレッドの基本的なモデルは POSIX のスレッドとそんなに違いがない (名前が違う程度) ので、 かえって乗り換える強い動機にならないのかも。 >>96 >>98 ご指摘ありがとうございます。 構造体リストについてもう一度 勉強しようと思います。 (他の方も書評の引用などありがとうございます) 『C実践プログラミング』のAmazon書評にあった 『Cクイックリファレンス 第2版』というのを試しに読んでみたところ, かなり規格網羅的で丁寧だと感じたので, 当面はこれで勉強してみようと思います。 こちらの書籍には「 struct data { // some code... struct data *next } 」という形のコードの解説そのものはありませんが, ポインタの解説をCの規格に沿ってしてくれているので かなり良い教科書として使えそうです。 以後言い訳:: いまのところ,まだC言語の規格が全て頭に入っている状態ですらなく, ましてや実際のプログラミング作法も分かっていない段階なので, ある書籍を見たときの(現代における)正確性・信頼性の判断が できないんですよね……。 『C実践プログラミング』は昔のO'Reillyが出している書籍なので ある程度信頼できるかな,と思って読み進めていたんですが, (実際,本質を突いていて分かりやすいと感じる部分も多くありました) 時代的にも正味の内容的にも現代において参考にすべき 良書とはいいがたいのかな……? ポインターで次へつないでいく、リストみたいな自己参照型。next pointer。 同じ構造体のリスト。 動的関数型のElixir は、片方向リストを使う a → b → c → d struct data { struct data *next } これが両方向リストなら、struct data *prev も持たなければならない。 次・前の2方向へ、たどれなければならないから a ←→ b ←→ c ←→ d ポインターに、null を代入すれば、次・前は存在しない。 つまり、終端を表す 詳細は、アルゴリズム・データ構造を参照 >>98 いや確かに -> は自己参照する構造体を使うときに好都合だぞ (*(*p).next).next が p->next->next で済むんだから 双方向で b を削除するのに b->prev->next = b->next; b->next->prev = b->prev; b さよなら これで済むからありがたい表記ではあるな >>110 異論があるなら堂々と言えよ 自分の意見が屁理屈かどうか見せずにそれを言うのは卑怯だぞ そもそも話がかみあってない こっちは気付いてるけど 君は気付いていない ただそれだけ だから屁理屈 結局、自分は尻尾を見せないんだな やりあう価値もないゴミだな、唾棄 自己参照型の構造体で固定段数のリンク手繰るのに便利にはなってるけど 自己参照型の構造体があるがゆえに -> ができたんじゃなく 単にポインタの指し先(構造体)のメンバを (*). じゃ遠回りなので直接指定したいがための存在だと思ってる >>114 同意だが、.で共用出来なかったんかね? 関数と関数ポインタみたいな感じで、左辺がポインタだったら逆参照してからメンバアクセス。 >>115 Rust ではそうしてるんだから C でも最初からそういう選択も出来たはずではあると思う。 だけど違うことをするのに同じ見た目にするのが良いかどうかというのは微妙なところ。 どちらが良いと一概に言えるもんではないからな。 >>117 派生関係も時系列も前提にしてない。 別の選択をしたものが事実として存在するので可能であるのは疑いないと言ってる。 FortranやCobolにも導入して欲しいのか? うーん? ある構文(範疇としては演算子の形態論?)について, 「他の言語での採用例があるからC言語がそういう構文を持っていても不思議じゃなかった」 という話が展開されていたと思うんですけど, どうして「RustはCの派生」とかFortranやCOBOLの構文の話になったんですかね……? 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 マクロだと#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して再定義できる特性は廃止されつつある Win32APIとか使わずに Cの標準関数でカレントディレクトリではなく 今実行中のexeのpathを得る方法はどれですか? int main(int argc, char* argv[]) の argv[0] で実行ファイルへのフルパスがえられるのは環境依存だったかな・・・ mainの第2引数の argv[0] にはコマンドラインから入力した通りのコマンド名が入っているんだっけ フルパスで入っているんだっけ 被った たしか Windows はフルパスだったような… 違ってたらごめんなさい Windows という書き方はよくないかな シェルの実装によると思います なので、WSLに持っていくと期待通りに動かなかったりするかもしれません ここでは Windows限定でよさそうだけど え?そう? Windows で C 使う人って今はあまりいないのでは? Linux とかなら分かるけど。 powershellはフルパスだけどcmdは入力のまま 結局はCreateProcessに渡した文字列なのでフルパス前提にしちゃだめよ OSに依存しない方法で確実なのはないよなぁ argv[0]が ファイル名のみ:カレント+環境変数pathを走査 相対パス:カレントと連結 絶対パス:そのまま とかやればそこそこいけるだろうけどめんどくさいな 純粋なC標準の範囲では不可能な気がする カレントディレクトリをとるgetcwd()もPOSIX(unistd.h)だし C言語の標準ライブラリにはディレクトリ階層の概念自体がなさそう >>131 powershell と cmd で違うのか… なんでそうしたんだろ 何れにしても、けぅこう面倒なのね みなさんありがとうございます dirname(argv[0]) したら argv[0] が壊れました ほんとうにがりがとうございました これ解決策じゃなくて愚痴なんだが、main()関数が使えるのはホスト環境で、つまりmain()関数のargv[]引数は「OSによる支援」を前提にできるんだから、実装依存じゃなくて「argv[0]には実行されたファイルのOSにおけるパス名が格納される」みたいな仕様にしてもよかった気がする。 それこそstdint.hみたいに、多種多様な機器への対応を考えなくてもいい関数なんだから、実行環境のファイルシステムやらをある程度は仮定しちゃってもいいわけで。 ファイルシステムもOSもない組み込み機器もあるわけで・・・ >>136 どんな OS でも Unix 風のファイルシステムを採用しているというわけではなくて、 たとえば BTRON が採用しているファイルシステムでは 同名のファイルが存在してよく、ディレクトリのような階層化は存在しない。 全体で唯一に区別できる名前 (フルパスに相当するもの) がない。 OS だってファイルシステムだって多種多様なんで、 起動時に「なんらかの」文字列で情報が与えられるということ以上は 環境依存にならざるを得ないよ。 >>137 その場合は通常の main 関数からの起動にはならない (main に意味のある引数が渡されないか特別なスタートアップ経由で起動される) ので、「main に値が渡されるならば」それなりの OS が仮定できるというのが >>136 の言ってることやで。 >>139 すげぇ たまには正しくわかりやすい説明できんじゃん ちょっと見直した コード記述してて実行ファイルのフルパスが必要となるんだから それなりのOSから叩き起こされてること前提よね >>138 > BTRON が採用しているファイルシステムでは > 同名のファイルが存在してよく、ディレクトリのような階層化は存在しない 知らんかった……。 調べたところBTRONは組込み機器向けのファームウェアじゃなさそうだし, ホスト環境=「それなりのOSが期待できる」環境あっても, 「あるファイルのパス名が存在して,その絶対値が文字列として一意に定まる」 ことさえ期待できないのか……。 >>134 dirname()は引数を破壊するのでコピーしてから渡すべし 今回のケースでは結局ダメだけどw > [...] 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だから,正確に訳すなら「ホスト済み環境」とかのほうが良いのかな? そのhosted environmentはプログラムの実行環境(execution environments)を ・freestanding(自立した環境=OS無しの組み込み系) ・hosted(OSにhostされた環境) に分けたものだからOSとかプラットフォームを指すホスト環境とはたぶん別の意味 hosted environmentの概念には明らかにUNIXが背景になってるね MS-DOSだのCP/MだのROM BASICだのまでは想定してない >>146 くわしくしりたいです。 「OSというのものは高性能である」という前提が Unixとかでしか通用しなかったってことですか? >>147 性能とかじゃなくてモデル化の仕方が多様という話。 たとえば古い時代の BASIC (N-BASIC など) は環境変数やコマンドラインという概念は持たないが、 違う形でデータを受け渡す方法は持っていて、どちらが高性能かというようなものではない。 >>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 などから,ちょっと納得しがたいです……。 IPLで起動して、ハードウエアへのアクセスを代行し、 コマンドをタイプして結果を文字で表示するCUI という観点からはUNIXとBASICは同列だよ MS-DOSでのデバドラはお行儀でしかなく アプリが直接I/Oなんて珍しくもなんともないが 一応argc, argvという概念はあった 言い出すとマイクロカーネルをヨイショする連中を嘲笑うように モノリシックカーネルでいったLinuxは、じゃあOSに非ずなのかと OSとは何か、何が該当し、何が該当しないのかは 見方が色々で誰もが認める基準はなかなかできない OSから外れた例をわざわざ挙げたのだろうと思っていたが、OSが何か分からない人でしたか... >>149 > N-BASICとかってそもそも「OS」なんですかね……? ---------- JIS X 0001-1994 ---------- オペレーティングシステム, OS(省略形) プログラムの実行を制御するソフトウェアであって, 資源割振り,スケジューリング,入出力制御, データ管理などのサービスを提供するもの。 備考 オペレーティングシステムは,ソフトウェアが主体であるが, 部分的にハードウェア化することも可能である。 ------------------------------------- まあ要するに OS がどのような構成を持つものなのかというのは曖昧で、 Unix 的な立ち位置も OS が持ちうる構成のひとつでしかないんよ。 > Unixと同列(あるいは類似)の概念として扱うのは > 違うような気がすること 「モデル化の仕方は多様」という例のひとつとして N-BASIC を出している。 違うように感じられるならそれは提示した意図通り。 この人の理解が間違えている。 わざと言っているとしたら悪質 >>154 俺もわからん。 何がどう間違ってるのか説明しておくれ N-BASICは確かにハードウエアを直接制御できるという意味では OSに近い。ただ今のOSとは全然違う。BASICだと遅すぎるので 大半はマシン語で直接書いてある。今のOSとは考え方が違う。 >>156 たしかにそういう意味では「OS」といえるのかもしれないですね。 ただ,それだと組込み機器のファームウェアだって 機器を操作できる,対人インターフェースがあるという点ではOSといえることになりません? >>158 はっきりした基準はないという前提だけどぼんやりとした概念的な部分では OS はアプリケーションソフトの対比的なものだと思う。 用途ごとのアプリケーションソフトを起動するという前提がないなら機能的に OS 相当のものを 含んでいても普通は OS とは言わないんじゃないかな。 ホントにOSだと主張するなら、ぜひWindowsの仮想環境で動かしてみてくれ 動かせないのなら、回りくどい事言わず、無理ですと言えば済むよ amd64で動くN-BASICがあるならできるんじゃない? 無いなら無理だわな 最近はスマホのカメラ部品にTRON OS入ってるんだって? もうBIOSやファームウェアもOSになるんじゃないかとも思っちゃう。 >>152-153 BIOS: BI + OS DOS: D + OS OSとは >>154 >わざと言っているとしたら悪質 ほんそれ 最近そういう書き込みが多い 5chから人を減らす作戦だろう >>167 > BIOS: BI + OS ネタか? Basic Input/Output System やぞ > DOS: D + OS こっちは合ってる >>169 もちろんネタと書いてあるのでネタなんでしょ。 質問です int flagA = 3 == 3; int flagB = 3 == 3 == 3; int flagC = 3 == 3 == 1; の結果が flagA : 1 flagB : 0 flagC : 1 になるのですが flag B とか flag C は何が怒っているのでしょうか? >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; int flagD = 3 != 3; int flagE = 3 != 3 == 0; int flagF = 3 != 3 == 1; flagD : 0 flagE : 1 flagF : 0 になります タイホするっ!! ダーン ダーン int flagB = ここまでと 3 == 3 == 3 が別のパーツになっていて == は左から結合するので (3 == 3) == 3 となり真は1になるので 1 == 3 で偽すなわち0だ 演算子の優先順位って覚えるのヤダー。自分書くと括弧だらけだわ。 どの辺が塩梅なんかねー?明示的でないと駄目よってコーディングとかもあるし。 & ^ | なんかのビット演算が比較よか低いのが微妙に嫌 結合の優先度は、自分が分かっていても 記憶があやふやな人が不安になるといけないから 結局カッコを明示的に描くかな… >>181 覚える気があっても、覚えさせられる気がしねー。 自分を磨くのは本人なので そんなお節介は考えなくていい CでC++の純粋仮想関数のような事をやりたいのですができますか? 疑似インターフェースです。 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; }; みたいなことか? あ、いかんvtableのtypedef忘れたけどまあ許せやw 幅があると言うなら狭めるようなヒント書けばいいだけ たたき台として>>187 はそれほど悪くないと思う >>187 スゴーイ 感謝感激 ありがとうございます。 typedef struct { void (*interface_a)(); void (*interface_b(); , . } TINTERFACEXXX; typedef struct { TINTERFACE ia; } TOBJA; なんてリレーションスタイルも考えたんですが、 いずれにしろ、クリーンアーキテクチャーのCでのSOLID原則ができるというところまでこぎつけました。 ありがとうございます。 奥村晴彦 『改訂新版 C言語による標準アルゴリズム事典』の 「改訂新版 序」に、 > 現代の慣習に従って、[…] EXIT_SUCCESSを0にしたりした とあるのですが、EXIT_SUCCESSマクロ変数を使った方が 定数即値を決め打ちするよりも可搬的であり、 それこそ「現代の慣習」であるように思うのですが、 実際はEXIT_SUCCESSより0を使う方が「現代的」なんですかね。 なお、誤植も疑ったのですが、集録されている実際のコードにおいても return 0;と書かれていました。 >>193 0以外 は1以上も-1以下もあるし、下手すりゃ数値以外の可能性すらあるけど 0 は絶対0なので、少なくともこれに関してだけは 私は許そう >>194 なるほど、「0 は絶対0なので」というので納得できました。 ありがとうございます。 >>193 思想的にはともかく、その件については習慣として定着してるという事実があるんで、 事実に逆らってもしょうがない。 ちなみに main 関数だけは return 文を通過せずに } に到達した場合には return 0; と同じになるという仕様になってるんで、 return 文自体を省略するという スタイルもある。 >>193 mainの出口は仕方ないんだよ enumなんて考え方ができる遙か前に決まったことで今さら変えられないというのが現実だ mainの第2引数だって今ならconst付けそうなところだけど これまたconstなんかなかった頃に決まったことだ >>197 歴史的にはそうなのかもしれないけど、それだと「EXIT_SUCCESSを0に」することが「現代の慣習」であることの説明になってなくないような なんでEXIT_SUCCESSと書いてたのを0と書くようにしたのかが知りたいんでは もう納得してるみたいなんでアレだけども マジックナンバーなんて駄目でしよってノリでEXIT_SUCCESSを使ってたけどあまり流行らなかったから0に戻したってことじゃないの? ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる