C言語なら俺に聞け 159

1 名前：デフォルトの名無しさん mailto:sage [2022/08/04(木) 23:32:27.83 ID:yWVViPyIM.net] !extend:checked:vvvvv:1000:512 (新スレ立ての際上記コマンドを2行書き込んでください) C言語の話題のみ取り扱います C++の話題はC++スレへ 質問には最低限の情報(ソース/コンパイラ/OS)を付ける 数行で収まらないソースは以下を適当に使ってURLを晒す https://paiza.io/ https://ideone.com/ codepad.org/ C17 www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4713.pdf C11 www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf C2x ドラフト www.open-std.org/jtc1/sc22/wg14/www/docs/n2731.pdf C99 www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf kikakurui.com/x3/X3010-2003-01.html C FAQ 日本語訳 www.kouno.jp/home/c_faq/ JPCERT C コーディングスタンダード https://www.jpcert.or.jp/sc-rules/ ※前スレ C言語なら俺に聞け 158 https://mevius.5ch.net/test/read.cgi/tech/1640401906/ VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured 237 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 5701-dv3E) [[ここ壊れてます] .net] WindowsではBOM付きのほうが便利だけどね。 238 名前：デフォルトの名無しさん [2022/09/18(日) 23:12:31.63 ID:a87PubfG0.net] gccもBOMに対応したことですし。 239 名前：デフォルトの名無しさん mailto:sage [2022/09/18(日) 23:23:26.35 ID:CUVLEdWC0.net] UTF-8にBOMが要らないと主張しているのは今の現実について言っているわけじゃなくて 「UTF-8しか存在しない美しい世界」を目指している活動家だからな。 説明したところで話が?み合わない。 240 名前：212 mailto:sage [2022/09/19(月) 00:00:08.46 ID:hV59E8S+H.net] >>236 よくわかっていますね、実はそうなんですよね 241 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 00:15:30.26 ID:YVA4ZVOh0.net] 自覚したなら今度からはバイトオーダーにかこつけたアホな主張はやめとけよ。 242 名前：ハノン mailto:sage [2022/09/19(月) 00:18:28.74 ID:hV59E8S+H.net] 美しい世界（爆笑）のために、今後も活動を続けていきます！ 243 名前：デフォルトの名無しさん [2022/09/19(月) 02:37:34.04 ID:Z9ZARiSG0.net] ユニコードの上位セットであるGB18030もあるんだけど。 244 名前：デフォルトの名無しさん [2022/09/19(月) 11:10:12.09 ID:NE4NRLG3F.net] >>236 そんなあなたに Nim がおすすめ 245 名前：デフォルトの名無しさん [2022/09/19(月) 11:11:36.70 ID:NE4NRLG3F.net] >>233 ASCII (8bit以内) しかないテキストに BOM 付いてたらさすがにうざいと思う 246 名前：ハノン mailto:sage [2022/09/19(月) 11:21:09.68 ID:PpMrjNAJH.net] >>242 ですよね！ コードは普通コメントも英語で書くし、なんで BOM がつかなきゃならないのか意味不明なんですよ、ましてや UTF-8 に BOM つけてもいい規約なんて後付けなんでしょう？ 美しい世界（爆笑）のために今日もがんばります！ 247 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 11:40:57.93 ID:YVA4ZVOh0.net] >>241 まさに今、話が噛み合わないことを痛感した。 248 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 11:41:54.30 ID:zeLiCYh20.net] なくても使えるなら、ない方が良い 249 名前：はちみつ餃子 mailto:sage [2022/09/19(月) 11:43:27.96 ID:npVSxydm0.net] どれでもいいけど規格で決めないという対処には愚痴を言いたくもなる。 250 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 11:55:32.42 ID:M3xsgC0JM.net] >>242 ウザいの定義を言え 普通にテキストエディタで編集してるだけなら気付きもしないだろう 251 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 12:00:13.75 ID:zeLiCYh20.net] 気付かなかったあなたはたぶん幸せ者です 252 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 12:13:35.24 ID:b1CdxAyP0.net] 10年前ならともかく今時BOMの有無で困ることなんてほぼなくね？ 253 名前：デフォルトの名無しさん [2022/09/19(月) 12:30:39.37 ID:/08McGz80.net] BOMなしUTF-8のデータを読ませるとエラーになるプログラムを作ったやつがいる。 こういうやつをどうするべきか？ 254 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 12:33:02.11 ID:zeLiCYh20.net] 市中引き回しのうえ、磔獄門で 255 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 13:00:37.09 ID:YVA4ZVOh0.net] 仕様で読めることになっているのにエラーになるならバグだがそうでないなら読ませる方が悪い。 日本語Windows向けアプリの大半はそうだな。 256 名前：デフォルトの名無しさん [2022/09/19(月) 13:09:05.53 ID:/08McGz80.net] 仕様ではUTF-8と書いてあるだけ。ならばBOMの有無に関係なく読めるようにするべき。 257 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 13:13:10.64 ID:zeLiCYh20.net] 仕様ではUTF-8と書いてあるなら、あったら読み飛ばせば良いだけだな 258 名前：デフォルトの名無しさん [2022/09/19(月) 13:29:40.55 ID:/08McGz80.net] にも関わらずBOMがないとわざわざエラーを出して終わる 259 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 13:40:15.70 ID:b1CdxAyP0.net] 単なるバグだろ、とっとと直させろよ 260 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 14:03:09.97 ID:Y3ojWtlT0.net] > こういうやつ BOMなしUTF-8のデータそのものを修正したいのか BOMなしUTF-8のデータを読めるようにプログラムを修正したいのか プログラムを作ったやつに復讐したいのか どれだ 261 名前：ハノン mailto:sage [2022/09/19(月) 15:32:18.43 ID:PpMrjNAJH.net] BOM はもともと UTF-16 のためのものでしょう？ それを、UTF-8 に対しても無条件に BOM をつけてしまうウンコエディターを量産している奴等に問題があるん� 262 名前：ﾅすよ… また、正直にいって、規格で決めればいいとかいう思考停止にも我慢ならないんですよ 美しい世界（爆笑）のために今日もがんばります！ [] [ここ壊れてます] 263 名前：デフォルトの名無しさん [2022/09/19(月) 15:34:28.84 ID:Z9ZARiSG0.net] HTMLもBOM推奨してなかったっけ。 264 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 15:56:49.87 ID:zeLiCYh20.net] HTMLの場合、「BOM」付けると、PHP で謎の空白ができてしまう など動作や表示に不具合が出る可能性があるそうです。 265 名前：デフォルトの名無しさん [2022/09/19(月) 16:04:04.51 ID:Z9ZARiSG0.net] それは、BOM付けるのがPHPの仕事だからじゃないの？ 266 名前：デフォルトの名無しさん [2022/09/19(月) 16:20:33.07 ID:x76VqF340.net] PHPは中途半端に歴史が古いから、Unicodeといえば、UTF-16なんだよな。 でもそのおかげでWindowsとの相性は悪くない。 267 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 16:20:51.69 ID:zeLiCYh20.net] そもそも UTF-8 には、エンディアンの違いがなく、BOM（バイトオーダーマーク）を付ける必要がないんだそうだ 268 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 16:22:57.02 ID:zeLiCYh20.net] HTMLの場合はHEADに使っている文字コード情報が入っているのでそれを見れば良い事になる 269 名前：デフォルトの名無しさん [2022/09/19(月) 16:25:44.76 ID:Z9ZARiSG0.net] >>264 たしか規格でBOMを優先することになってなかったっけ？ 270 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 16:33:42.03 ID:zeLiCYh20.net] 文字列としてバイトオーダーが実際に問われるのは、 UTF-16やUTF-32のケースだけです その場合は必要ですね 271 名前：デフォルトの名無しさん [2022/09/19(月) 16:34:41.81 ID:Z9ZARiSG0.net] 確認したところ、なってたわ。 HTMLパーサー書いたことがあるから、おぼろげに覚えてた。 272 名前：デフォルトの名無しさん [2022/09/19(月) 16:46:36.41 ID:Z9ZARiSG0.net] ・BOMがある場合、BOMに従う。 ・ない場合、500ms、あるいは1024バイト読み込むまで待機し、エンコーディング走査アルゴリズムを呼び出す。 エンコーディング走査アルゴリズム内で、ヘッダー内の情報が読み取られる場合もある。 （このアルゴリズムでも、他に優先される情報がある。） やはり、HTMLにおいては、BOMをつけるべきだな。 読み込みが速くなるし、文字コードの違いを利用した攻撃を避けることが出来るし。 273 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 16:47:54.37 ID:zeLiCYh20.net] HTMLの場合は、HEADに使用するcharsetが記述されてますから心配ありません 274 名前：デフォルトの名無しさん [2022/09/19(月) 16:48:57.21 ID:Z9ZARiSG0.net] 昔の外国映画で「ふにゃちん野郎が！」という悪口があったよね。 今後は「BOM無し野郎が！」と言うことを提案いたします。 275 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 16:49:03.30 ID:zeLiCYh20.net] それにUTF-8にはバイトオーダーがありません 276 名前：デフォルトの名無しさん [2022/09/19(月) 16:50:38.05 ID:Z9ZARiSG0.net] >>269 規格上、BOMのほうが優先される。 BOMがある場合、エンコーディング走査アルゴリズムは呼び出されない。 BOMをつけましょう。 277 名前：デフォルトの名無しさん [2022/09/19(月) 16:52:03.62 ID:Z9ZARiSG0.net] BOMをつけないとセキュリティ上の問題がある。 278 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 16:52:15.94 ID:zeLiCYh20.net] 付けたWebサイトをここで公開して下さい 楽しみにしています 279 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 17:25:06.78 ID:UNULYZvbM.net] すべてのUTF-8にBOMがついてたらSJISはもっと早く消えてくれたと思うんだよね 280 名前：デフォルトの名無しさん [2022/09/19(月) 17:31:57.08 ID:Z9ZARiSG0.net] この話題は、BOMをつけましょうということで、良いのでは？ 281 名前：ハノン mailto:sage [2022/09/19(月) 18:02:53.27 ID:PpMrjNAJH.net] >>276 違います BOM を付けるべき正統な理由がある時には付け、特に理由がなく惰性で付けてるんだったらやめよう、です 282 名前：デフォルトの名無しさん [2022/09/19(月) 18:05:47.85 ID:Z9ZARiSG0.net] BOMを付けていない人を見かけたら、注意して差し上げましょう。 ということで、良いのでは？ 283 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 18:12:09.41 ID:iQkZER0Ad.net] テキストファイルを開いたとき最初の三文字がゴミかどうかいちいち判断するの？ 2つのテキストファイルを結合するときゴミをひとつにまとめる処理するの？ BOMという考えが誤りなんだよ 284 名前：デフォルトの名無しさん [2022/09/19(月) 18:14:42.87 ID:Z9ZARiSG0.net] 法令でBOMを義務付けるべきでは？ BOMが無かったら通報するみたいな。 285 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 18:15:00.74 ID:zeLiCYh20.net] Windowsの一部アプリでBOMがないと動作不具合起こすんだよ Officeとか、Officeとか、その辺 この辺への思いやりが必要な時は付けてあげると良い 286 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 18:19:47.40 ID:BENNO3a0H.net] >>278 それに加えて BOM を無駄につけている人を見かけたら、注意して差し上げましょう、も追加してください。 287 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 18:20:53.56 ID:BENNO3a0H.net] >>280 その法令は間違っていますね 正直いって、規格で決めればいいとかいう思考停止にも我慢ならないんですよ 美しい世界（爆笑）のために今日もがんばります！ 288 名前：はちみつ餃子 mailto:sage [2022/09/19(月) 18:22:38.11 ID:npVSxydm0.net] >>279 ふたつのテキストファイルが Unicode である保証もない。 メタ情報で保証があるなら BOM があっても困らないし、 保証がないなら BOM があろうがなかろうが困る。 289 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 18:23:22.11 ID:BENNO3a0H.net] >>281 たしかに office とか office とか office とか office とかに思いやりを示す寛大な処置ということであれば、付けて差し上げることにやぶさかではないのですけれどもね 290 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 18:27:12.50 ID:YVA4ZVOh0.net] >>277 後半に関して言えば、そのテキストがどのエンコードを用いているかが他の手段で示されているなら BOMは用いるべきではないとされているからそれに従えばいい話だね。 「俺が扱うテキストは全部UTF-8に決まってるんだからBOMは要らない」という自己中心的な主張と 混同してくれなければいい。 291 名前：デフォルトの名無しさん [2022/09/19(月) 18:28:42.31 ID:Z9ZARiSG0.net] まあ私はどちらでも良いんですけれども。 （レイヤード・ストリームをつこてますので） gccがBOMに対応したのだから、BOM付ける陣営の勝利では？ 292 名前：デフォルトの名無しさん [2022/09/19(月) 18:33:34.93 ID:Z9ZARiSG0.net] ところで明日は地下鉄が止まるかもしれないので、調べておいた方が良いですよ。 293 名前：デフォルトの名無しさん [2022/09/19(月) 18:35:51.09 ID:Z9ZARiSG0.net] わたくし思うのですが、BOMに対応しないソフトウェアを企画してしまう技術者って、もはや技術者で無いのでは？ ユーザーが必要としてるわけですからね。 294 名前：デフォルトの名無しさん [2022/09/19(月) 19:59:29.61 ID:x76VqF340.net] WindowsはBOMがあった方が判別しやすいが、LinuxやUNIXはBOMがあると余計なものが付いているという感じになる。 マルチバイト圏への配慮が足らなかったマイクロソフトが一番悪い。 だいたい2バイトで漢字がすべて収まると思ったアメリカ人に対して、早く日本人が漢字は何万字もあると教えなかったのが失敗だった。 295 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 20:35:04.98 ID:EmjBwTYRd.net] BOMキチガイども 296 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 20:42:51.60 ID:F9okSTEiM.net] MS-DOSの頃は、これで十分って思ってたからな。 297 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 21:05:32.45 ID:BENNO3a0H.net] >>290 ＞だいたい2バイトで漢字がすべて収まると思ったアメリカ人 CJK 漢字統合なんて醜い仕様のひと言に尽きますよね >>286 自己中心的、という言葉の使い方が間違っていますよ その昔は Shift-JIS, JIS, EUC が入り乱れまくっていましたが、だれもテキストデータにエンコードを示すプリフィックスを付けようなどとは思わなかった事実があります UTF-8 にバイトオーダーマークなんか絶対に不要なのにバイトオーダーマークを安易につける発想そのものが自己中心的なのでは？ 美しい世界（爆笑）のために今日もがんばります！ 298 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 22:08:36.69 ID:YVA4ZVOh0.net] 「俺が扱うテキストは全部UTF-8に決まってるんだからBOMは要らない」というのが自己中心的な主張だと言ったんだが？ こんな単純な日本語の文章すらまともに読解できない奴に間違ってるとか言われても困惑するわ。 299 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 22:24:33.90 ID:BENNO3a0H.net] >>294 同じことを繰り返しますが、 ①過去、エンコードの違うテキストを各種取り扱っていたからといって、「テキストの内部に恣意的にエンコードを示すマークを入れる」などという自己中心的なことをした歴史はなかったのです。 　特にそういうことをしたいときは、ソースコードにその言語のコメントでエンコードを示す、くらいの配慮をしていたものです ②UTF-8 でエンコードされている限り、そのコンテンツがアスキーコードのみで構成されているのならば、特にバイトオーダーコードは不要で、as is で使えるように、欧米諸国に配慮した設計です 特に②が重要で、バイトオーダーコードを要れずとも、C のソースコードは UTF-8 であれば普通にコンパイルできる、はず、なのに、なぜわざわざバイトオーダーコードを付加して既存の処理系がそのままでは使えなくなってしまったのか？ コンパイラは MS-VC だけではなく、gcc も clang も lsi-c （ｗ）もあるというのに、既存のコンパイラの動作を妨害してまで、バイトオーダーコードを付加するエディター側の方が自己中心的といえるのではないでしょうか？ そしてエンコードを示すマークなどではないバイトオーダーマークをエンコード種を示すマークに乱用するしている二重の矛盾も指摘しなければなりますまい 私の言っていることがわかりますか？ 300 名前：デフォルトの名無しさん [2022/09/19(月) 23:05:07.14 ID:/08McGz80.net] >>264 そのHEADの箇所に行くまでエンコードが分からないのだよな？ そこまでどうやって読むのか？ まあ、現実問題としてASCIIで入れておきゃいいわけだけど、厳密にはそれじゃいかんよな。 301 名前：はちみつ餃子 mailto:sage [2022/09/19(月) 23:10:53.08 ID:npVSxydm0.net] >>290 エンコード切り替えの規格は ISO/IEC 2022 がある。 PC-9801 時代あたりにはマニュアルで KI/KO コードという名前で説明されていた。 ヨーロッパ言語も ISO/IEC 8859 として十種類以上の文字セットが定義されているんだ。 日本での事情以上に混在は深刻な問題であって、対処する規格は当然ある。 302 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 23:18:33.90 ID:a+e8LTLZH.net] >>296 おっしゃるとおり、そこまでは、ただのアスキー7bit で記述するんですよ 大概は第一行目にエンコード種をアスキーで書くものでしたけれどもね 厳密っていうけれども、あなたのおっしゃる厳密の意味がよくわかりませんね 303 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 23:19:31.82 ID:a+e8LTLZH.net] >>297 英語が一番簡単で、ウムラウトとか苦労していたと思いますよ、ウムラウトは確か 7　ビット領域に侵食していたような気が 304 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 23:23:44.77 ID:a+e8LTLZH.net] >>297 おっと、私のいっていたことが少し不正確でしたね、たしかに　KI/KO は生 JIS にありましたね 305 名前：はちみつ餃子 mailto:sage [2022/09/19(月) 23:40:42.70 ID:npVSxydm0.net] 自然言語なんて数千年単位の歴史的経緯の塊だ。 その文字も。 綺麗に整理しようとしたって元がグダグダなんだからどこかしらでグダグダになる。 そんでそのグダグダをひとつに寄せ集めたのが Unicode なんだぞ。 そりゃグダグダで当たり前だし、そういうもんだと思うしかしょうがないだろ。 そんでもって Unicode がかなり広まったといっても従来の文字コードが消滅したわけでもない。 https://xkcd.com/927/ 306 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 23:43:18.98 ID:a+e8LTLZH.net] >>240 チャイナ規格ですか‥‥（差別意識満々） 調べてみましたが基本的に4ビット固定長であり、UTF-8 を包含してはいないようですね、UTF-8 の上位規格というのはどういう根拠でそういっているのですか？ どっちかというと 現行中国漢字エンコード規格の上位規格でしょう 私の理解 ・7 ビット圏は 1 バイト ・拡張部分は可変長ではなく 4 バイト固定 ・現行の中国の漢字エンコード規格 GBK（シフトJIS と同じ仕組み）を包含するように第二・第四バイトの範囲を GBK と被らない範囲に制限している。 307 名前：デフォルトの名無しさん [2022/09/19(月) 23:48:55.05 ID:Z9ZARiSG0.net] >>302 ユニコード・コードポイント全てを内蔵したうえで、さらに少数民族の文字を追加してあるからでしょ。 そういう生い立ちなんだから。 308 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 23:52:42.86 ID:A/Pc+E3NH.net] >>301 How standards have been overproducted とか易しい英語にしてほしいなあ 309 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 23:55:05.42 ID:A/Pc+E3NH.net] >>303 コードポイントの数は十分確保している、って言う意味で「ユニコードの上位規格だ」と主張しているわけですか この理解で正しいですか？ 310 名前：デフォルトの名無しさん mailto:sage [2022/09/19(月) 23:55:54.72 ID:zeLiCYh20.net] EBCDIC なんていうコード体系もあるんだよな これはASCIIよりも古い このコードで動いていたPCもあった（今もあるかは知らない） 311 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 05:35:11.57 ID:JyAf+et+0.net] N5200か 312 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 05:38:15.50 ID:AtHbCf2+0.net] >>290 2千字の常用漢字で済ませという時代だったから。 > だいたい2バイトで漢字がすべて収まると思ったアメリカ人に対して、早く日本人が漢字は何万字もあると教えなかったのが失敗だった。 313 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ ffb0-okD4) mailto:sage [[ここ壊れてます] .net] >>295 ここまでくると狂気しか感じないが。>>286で自己中心的と書いた内容と全然関係ない内容を 延々と繰り返すのはなんでだろう。 ついでに>>295の内容について言えば、規格で定めているもののどこがどう自己中心的なんだか。 この場合の「自己」って誰のこと？ 314 名前：デフォルトの名無しさん [2022/09/20(火) 09:59:52.88 ID:2fXkGtCja.net] >>270 PHP+SJIS全盛の頃にBOMの代わりに「美乳」が使われてた時代があったな 315 名前：デフォルトの名無しさん [2022/09/20(火) 10:02:30.30 ID:2fXkGtCja.net] >>275 そうかな 全てのファイル名にBOM付いてたら嫌だな 316 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 10:04:55.52 ID:Sk0Tcp2N0.net] MSならやりかねない 317 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 10:08:20.39 ID:x6uHKNFtM.net] >>311 asciiなら不要だよ 318 名前：デフォルトの名無しさん [2022/09/20(火) 10:19:31.19 ID:2fXkGtCja.net] >>313 BOM付けろ派はASCIIかどうかもBOM付いてないと判らないみたいだし 319 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 10:27:10.48 ID:Sk0Tcp2N0.net] MSの事だから、UTF-16使いそう 320 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 22:46:15.84 ID:oGqR16NY0.net] >>309 ＞>>286で自己中心的と書いた内容と全然関係ない内容 >>286 ＞「俺が扱うテキストは全部UTF-8に決まってるんだからBOMは要らない」という自己中心的な主張と混同してくれなければいい。 まあ、活動家のなりきりをしているので、そういうスタンスをとっているけれども、本質的には >>295 1. 過去、エンコードの違うテキストを各種取り扱っていたからといって、「テキストの内部に恣意的にエンコードを示すマークを入れる」などという自己中心的なことをした歴史はなかった 2. UTF-8 でエンコードされている限り、そのコンテンツがアスキーコードのみで構成されているのならば、特にバイトオーダーコードは不要で、as is で使えるように、欧米諸国に配慮した設計 が言いたいことですね UTF-8 ならば通常は as is で使えるんですよ、特に C/C++ のコード（コメントは英語・これって普通でしょ？）をそのまま使えるのに、どこぞのエディターが勝手につけるバイトオーダーマークまで正当化する風潮に苛立ちを感じているんですよ 長いものに巻かれよ、みたいなみっともない風潮を正当化するあさましさにあきれ果てているのです あなたがそうだ、とはいいませんけれどもね 321 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 22:50:52.98 ID:an1sf52Dd.net] どこでも演説をおっぱじめるガキにいらだちを感じてる 322 名前：デフォルトの名無しさん mailto:sage [2022/09/20(火) 23:07:44.32 ID:Sk0Tcp2N0.net] 多国語が混在しても扱えるところが気に入ってる 323 名前：デフォルトの名無しさん mailto:sage [2022/09/21(水) 00:15:08.73 ID:z4iK/HUS0.net] gdbについて質問いいですか？ ステップ 324 名前：実行でfopenを通過しようとすると 　"iofopen.c: そのようなファイルやディレクトリはありません" とメッセージがでて先に進めません。どうすれば回避できますか？ OS:Linux [] [ここ壊れてます] 325 名前：デフォルトの名無しさん mailto:sage [2022/09/21(水) 00:17:32.94 ID:z4iK/HUS0.net] ちなみにソースは以下の感じです fopenで開くファイルは実行ファイル(a.out）と同じ場所に置いてあります。 #include <stdio.h> void main(void){ 　FILE *fp; 　fp =fopen("aa.txt", "r"); 　fclose(fp); } 326 名前：デフォルトの名無しさん mailto:sage [2022/09/21(水) 00:45:37.65 ID:itvuUNqP0.net] このあたり参考にしてください https://doss.eidos.ic.i.u-tokyo.ac.jp/html/advanced_gdb.html#libraries 327 名前：デフォルトの名無しさん mailto:sage [2022/09/21(水) 06:00:40.75 ID:z4iK/HUS0.net] >>321 サンクス 328 名前：デフォルトの名無しさん mailto:sage [2022/09/21(水) 06:25:52.07 ID:tW9j9RfF0.net] includeガードって割と使われてるように思いますが、エラい人の批評とかありません？ 依存関係を把握しきれてないヤバい状態の発覚を先延ばしにするだけのハックだと個人的な経験から思うのですが… 329 名前：デフォルトの名無しさん mailto:sage [2022/09/21(水) 06:39:05.65 ID:6JiKBcvPd.net] とりあえず各ソースファイルの実行部、なければinit_xxxみたいなエントリーポイント作って #ifdef XXX perror("xxx loaded twice"); exit(XXX); みたいの置いたりしてます 330 名前：デフォルトの名無しさん mailto:sage [2022/09/21(水) 06:47:28.88 ID:6JiKBcvPd.net] init_xxxを呼び忘れると無意味なので、文法エラーで落とせたら良いと思うんですが、分かりやすいメッセージ吐いて落ちてくれる違法構文(あるいはそうするときの標準的なイディオム)あったら教えて欲しいです 331 名前：デフォルトの名無しさん mailto:sage [2022/09/21(水) 07:18:22.65 ID:sLC8V8J20.net] >>323 エロい人の批判ねえ。。。 #pragma onceなんか色んなコンパイラの中の人が真似してるけど？ 依存関係を把握っていうけど、じゃあ #include <stddef.h> #include <stdio.h> なんて書かされたいわけ？ ライブラリだって-lstdcじゃなく fputc.o iobuf.o fprintf.o printf.oなんて書くべきだと思う？ 何かを使いたいときの窓口を１つにまとめておくのは 作る側として行儀のいいことだと思うぞ 332 名前：デフォルトの名無しさん (ｽﾌｯ Sdbf-MXZj) mailto:sage [[ここ壊れてます] .net] >>326 むしろグッドプラクティスとされてる感じですか、確かにシステムヘッダにも見掛けますね 標準ライブラリは使うものを共通ヘッダにまとめてますね ライブラリとして公開する場合は当然慣習に従うべきだと思いますが、書いてる時には丁度必要十分でなく、余計なヘッダがあると何処に何があったか混乱したりしません？ コードを弄らずスタティックアナライザとか道具に頼った方がいいのかな 333 名前：はちみつ餃子 mailto:sage [2022/09/21(水) 09:18:02.72 ID:tPUkcfIa0.net] >>323 ライブラリはそのライブラリの使用者に対して インターフェイス部分だけを公開したいのが普通で、 細かい依存関係が見えてしまうのは悪い設計だろ。 でも C のヘッダファイルの仕組みは隠蔽しきれない部分が出てしまうので そもそも C の言語としての仕組みが悪い。 C を使う以上は悪い部分ともつきあわないとしょうがないし、 インクルードガードは比較的マシな解決方法だと誰もが考えているからこそそうなってる。 C++ にはモジュールが導入されたけど今のところはヘッダファイルとも共存し続ける必要があるから 完全な移行にかかる時間は数十年単位かもしれんな……。 334 名前：デフォルトの名無しさん [2022/09/21(水) 09:58:34.67 ID:hjFc1SVt0.net] 新言語作った方が早いw 335 名前：デフォルトの名無しさん [2022/09/21(水) 18:18:19.49 ID:E8IgYMeHa.net] >>327 >余計なヘッダがあると何処に何があったか混乱したり へたくそなライブラリだとそういうの見掛けるが 上手なライブラリはすっきりしてるイメージ 336 名前：デフォルトの名無しさん [2022/09/21(水) 18:19:32.68 ID:E8IgYMeHa.net] >>328 FILE * とかって結局使う方からしたら void * でも動くしな 337 名前：デフォルトの名無しさん [2022/09/21(水) 18:21:06.66 ID:E8IgYMeHa.net] >>329 Nimがある

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef