C言語なら俺に聞け 163

2024/07/16(火) 22:43:54.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言語なら俺に聞け 162
https://mevius.5ch.net/test/read.cgi/tech/1698653580/

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

2024/11/01(金) 06:24:42.85

気休めじゃなくて気疲れの間違いだろ
長さやsignednessでわけわからん変換しやがるバグの根源と言ってもいい

2024/11/01(金) 11:11:58.05

訳が理解できるようになるまで､お前は使用禁止

2024/11/03(日) 13:27:09.33

https://togetter.com/li/1471386
こんな事本当にあるのか？

2024/11/03(日) 13:36:34.35

もともとバグってたのを対処療法で回避しただけじゃねーの？
そんな驚愕するほどのこととは思わんな
スペースは文字列に加えるってことだろ

2024/11/03(日) 13:45:35.99

ちゃんとソースを公開すればみんなで治してくれるよ

2024/11/03(日) 16:06:15.80

バイバイおさるさん

2024/11/03(日) 17:27:36.06

char []s = "うんこ"
s[20] = 0; // どっか判り難いとこにこんなのが紛れてる
回答「(sに)もっとスペースを追加して！」

2024/11/03(日) 17:39:48.03

どこか知らない国で "うんこ" が40バイトくらいある所があったりして

2024/11/03(日) 19:33:15.95

業務だとヨソの担当のモジュールに口出しするのがめんどいから対処療法で握りつぶすみたいなことはあるのかもしれん。

警備員[Lv.1][新芽] (ﾜｯﾁｮｲ 1259-WgI6) · 2024/11/03(日) 20:22:14.37

s("※んこ"の値)は読み取り専用になるんじゃないかな
処理系によるかもしれないけど

2024/11/04(月) 01:39:12.77

>「ここにスペースを入れてみて」「もっと沢山、もっともっと」
この辺りコピペ怪文書にしか思えないんだが
境界チェックしない言語ならありふれたバグだし、元文書はちんぽとかだったんじゃないだろうか

2024/11/04(月) 13:45:59.93

どうせメモリーリークだろうな
データ位置を変えると現象が変わるなんて典型的だろ

警備員[Lv.5][新] (ﾜｯﾁｮｲ 757b-WgI6) · 2024/11/04(月) 13:48:37.25

>>302
誤りでした

2024/11/04(月) 14:02:09.24

パンパース当てるのが正しい

2024/11/04(月) 20:44:45.70

おむつってあんま進化してないよな
吸収率だとか漏れだとかそんなのは上がってるだろうが、基本的な機能は変わらない
介護業界でも排泄介助っていう高齢者の汚物処理って割と大変な部類だと思うんだが
そろそろおもつ革命を起こさないと業界崩壊するんじゃないの
プログラミングでなんとかできませんかね

2024/11/04(月) 20:51:48.25

高齢者に限らず若い子でもうんこ漏らす時は漏らすし、そういう緊急時にも安心できるぐらいのものがそろそろ欲しいな
紙ベースで吸収率だとかで脳が退化してるおむつメーカーではおむつ革命はとても期待できないだろう

2024/11/04(月) 21:52:48.49

介護対象に飲ませるうんこがあまり臭くなくなる薬みたいな技術は進化してるぞ

2024/11/04(月) 22:10:34.76

薬で臭くなくしたうんこだからといって介護対象に飲ませるのはどうかと思うぞ。

2024/11/04(月) 22:15:25.35

>>295
こんなんじゃね

#include <stdio.h>
#include <string.h>
#include <limits.h>

int main(void)
{
　　char s[] = ""; // ←スペースを11個入れる
　　sprintf(s, "%d", INT_MIN);
　　puts(s);
}

2024/11/04(月) 22:17:04.25

>>310
完全に臭くなくなる訳ではないのでおｋ

2024/11/04(月) 22:57:47.13

ニホンゴ　ムズカシイネ

2024/11/05(火) 05:14:52.21

逆に考えるんだ。うんこはどうしても出てしまう。だったらそれはそのままにしておけ。
介護する側がそれを気にせず処理出来るのであれば問題は消滅する。だから介護者が
それを気にならなくなるような精神に効く薬を作れば良いんだ。

**デフォルトの名無しさん** · 2024/11/05(火) 06:59:24.91

>>295って実行時エラーの話なのかコンパイル時エラーの話なのかもわからなくない？

2024/11/05(火) 15:17:41.47

NASAはネットなんてなかった1970年代にボイジャー1号打ち上げて
240億km離れててもプログラムを送受信してるのに俺らときたら

2024/11/05(火) 21:46:02.31

どうみても脳筋エラー

2024/11/05(火) 21:49:31.93

脳筋がCを使いません

2024/11/05(火) 22:03:42.83

240億kmの伝書鳩

2024/11/06(水) 09:37:06.45

1970年代にもテレビやラヂオはあったわけでね…

2024/11/07(木) 17:53:15.92

1960年代はラジオ少年が秋葉原詣でしてたな

2024/11/07(木) 22:04:17.92

質問失礼

LPTSTR lptStr = TEXT("テスト");
って書くとE0144とC2044ってエラーを吐くんだがプロパティの文字セットって項目を設定なしにすると正常に処理されるのはどういう理屈なの？
const wchar_t[]からLPTSTRに変換できませんってメッセージ出るし型が違うのかなと思うが
だとしたら何故文字設定いじれば解消するのかもよくわからない

警備員[Lv.1][新芽] (ﾜｯﾁｮｲ e9eb-WgI6) · 2024/11/07(木) 22:09:23.47

LPCTSTR ではダメですか?
当てずっぽうですが

警備員[Lv.1][新芽] (ﾜｯﾁｮｲ e9eb-WgI6) · 2024/11/07(木) 22:10:11.25

>>323
そういうことじゃないのか、ごめんなさい

2024/11/08(金) 09:56:22.05

>>322
設定変えても依然エラーだが
VS Community 2022

2024/11/08(金) 10:31:35.11

>>324
気持ちだけで十分よ

2024/11/08(金) 10:32:35.47

>>325
2022だと設定項目見つからなかったから2012でやった、そしたら上記の結果になるんすよねえ

2024/11/08(金) 10:36:22.46

最近のVSはCの当たり前な構文が通用しないから困るよな

2024/11/08(金) 10:51:18.29

>>328
Visual Studio側の問題なのこれ？

2024/11/08(金) 11:51:09.67

>>327
2022で設定変えたって書いただろ
あほなのか

2024/11/08(金) 12:18:22.14

LPTSTR lptStr = L"テスト";

2024/11/08(金) 12:20:09.93

あと
#define UNICODE
#define _UNICODE
だったかな

2024/11/08(金) 12:28:34.80

それでもだめなら
文字コードが違うんじゃないですかね

2024/11/08(金) 12:59:02.56

>>330
どストレートな罵倒は久しぶりに聞いたよ
高校上がってからは聞かなくなったけどね

2024/11/08(金) 13:00:18.41

>>331
ありがとう、だけどダメそうだ
文字コード関連のエラーなんだろうけどどうしたものか

2024/11/08(金) 13:02:23.75

char と wchar_t の不整合じゃなくて const の有無の問題じゃないの？

C++ で文字列リテラルまわりの扱いで仕様変更があったからそれに関係してるのかも？
C++ での文字列リテラルの型は const char[] (ワイド文字リテラルの場合は const wchar_t[]) だが、文字列リテラルから直接変換する場合に限り char* (ワイド文字リテラルの場合は wchar_t*) に暗黙に変換して構わないというルールが C++03 まではあって、このルールは C++11 で削除されたという経緯がある。
つまり C++11 以降は文字列リテラルから暗黙には const を剥がすことが出来ない。 (キャストを書けば出来るけど。)

C では文字列リテラルの型は元から char[] で、 const が付いてない。
だから const まわりの制限とは関係ないんだが、これは C の仕様のほうがおかしいし、 C++ と同様の判定をしたほうが理に適っているとマイクロソフトが考えることはあるかもしれない。

2024/11/08(金) 13:18:44.37

E0144 エンティティの初期化
型”cont wchar_t *"の値を使用して"wchar_t *"のエンティティを初期化することはできません

C2044は関係無い

2024/11/08(金) 14:51:25.22

>>336
なるほどね、LPTSTRがchar*だから代入できないって話になるのか
それがわかったらエラー文にかいてあることが理解出来るね

昔の仕様だとconst charに見えて実際は違かったってこと？
それなら今回のコードもエラー吐かないし悩まなくてよかったのに

2024/11/08(金) 14:52:37.02

>>337
関係ないの？LPSTRに代入できませんって言ってるように見えるけど

2024/11/08(金) 16:25:31.55

signedとunsignedでも怒り狂うからなぁw
いいんだよ、こっちは中身しってんだから余計なエラー吐くなよ

2024/11/08(金) 17:24:12.05

>>338
> 昔の仕様だとconst charに見えて実際は違かったってこと？

C の規格としては本来的に文字列リテラルの型には const は付かない。
これは今も昔も同じ。変更はない。

なので何かが変わったとしたらマイクロソフトの独自仕様。
私はそのへんに詳しいわけじゃないけど C++ の規格改定に引きずられた可能性は想像できるなぁというぼんやりした予想なので経緯はわからぬ。

でもまあ結果的に const の問題ってのは妥当なみたいだね。

2024/11/09(土) 14:04:43.61

LPTSTR lptStr = (LPTSTR)TEXT("テスト"); で警告出たりするのかな？
糞面倒だけどキャストで通るならそれ以上の対応不用

2024/11/09(土) 14:22:07.15

VS使ってるからたぶんCじゃなくてC++
こういうボンクラの自覚ないボンクラは相手しても疲れるだけ

2024/11/09(土) 18:12:46.73

>>341
理解した
constは付かないはずなのにリテラルにVisual Studioが勝手に付いてることにしてくるってことね
わざわざありがとうスッキリしたよ

2024/11/09(土) 18:13:16.97

>>342
いけた
たしかに面倒だけど仕方ないね

2024/11/09(土) 18:17:26.89

>>343
そんなこと言いながら何回もレスくれるなんて

2024/11/09(土) 18:29:31.05

>>315
どっちもいける

実行時エラー
https://wandbox.org/permlink/r9w30EwoyKVxIguC
> Segmentation fault

コンパイル時エラー
https://wandbox.org/permlink/yPJz2UPs8xHYPLAr
> prog.c: In function 'main':
> prog.c:8:17: error: '%d' directive writing 11 bytes into a region of size 1 [-Werror=format-overflow=]
> 8 | sprintf(s, "%d", INT_MIN);
> | ^~
> prog.c:8:5: note: 'sprintf' output 12 bytes into a destination of size 1
> 8 | sprintf(s, "%d", INT_MIN);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors

2024/11/10(日) 00:27:12.07

左辺をLPCTSTRにすれば良くない？
リテラルの文字列を可変にすること自体が本来は不要だし、右辺を可変にキャストするよりは左辺を不変として (LPCTSTRとして) 受け取れば良いと思う

2024/11/10(日) 09:35:26.26

>>344
オンラインコンパイラで VS17.10 を確かめてみたが文字列リテラルには const は付かないぞ。
お前が間違って C++ を使ってるという >>343 の意見に一票。

2024/11/10(日) 15:28:44.44

>>322
・Microsoft Visual Studio Community 2022 (64 ビット) を使用し「C++コンソールアプリ」で新規プロジェクト作成
・ソリューションエクスプローラーでソースファイルにあるファイル名を*.cppから*.cへ変更
・ファイル名を変更したファイルに下記をコピペ
#include <windows.h>

int main(void)
{
LPTSTR lptStr = TEXT("テスト");
}
・ビルド(B)→ソリューションのビルド(R) でフツーにビルド通ったわ。

2024/11/11(月) 11:10:09.47

つまりスレタイ嫁ということか

2024/11/11(月) 11:32:56.82

>>343 は速攻ぶったたいてるが、学生か初学者はこういう経験しとくもんだ
Cは汗に似て泥臭いんだよ

俺もあとで追試しよっとテキトーでやってて知識整理できてないわ

2024/11/12(火) 18:11:56.60

>>322
コンパイラオプションを見れば明らかになるじゃろう。

**デフォルトの名無しさん** (JP 0H93-qgn8) · 2024/11/13(水) 18:56:16.48

EchoAPIがVS Codeのワークフローにピッタリで、APIテストの能力がグッとアップしったって聞いて

2024/11/15(金) 18:07:01.60

まるちんこしね

2024/11/22(金) 19:50:13.47

Q.
doubleをprintfで表示するには%lfでいいの？

A.
double 型を printf で表示する場合、%lf ではなく %f を使用するのが一般的です。

理由:
printf の可変長引数において、float 型は double 型に自動的に昇格されます。
そのため、%f は double 型の値も受け取ることができます。

%lf は scanf で double 型の値を読み込む際に使用されますが、
printf では %f と同じ意味として扱われます (C99規格以降)。

2024/11/24(日) 19:40:17.88

これが同じ値書いてくれないのは普通だったんだっけ．

#include <stdio.h>

int main() {
int s=31;
unsigned long i = 1 << 31;
unsigned long j = 1 << 31;
unsigned long k;

while(i) {
k = 1 << s;
printf("%lu,%lu,%lu¥n",i,j,k);
i = (unsigned)i>>1;
j >>= 1;
s--;
}

return 0;
}

2024/11/24(日) 19:55:59.76

手元にあるGCCとMS-C(32bit)は
同じ値が出てました

2024/11/24(日) 20:09:10.15

質問失礼します
ダイアログボックスについて学習しようとしているのですが、サンプルのリソースをコピペしたところ、ダイアログボックスのIDが認識されなく手詰まりになってしまっています。
どなたかご助力ください。

TEST DIALOG (座標を書くと書き込みできない)
C2059
C2061

以上のソースでエラーを吐いてしまいます。リソースをベタ打ちで記述する参考サイトが少ないので判断がつきません。

2024/11/24(日) 20:28:06.09

記述に文法上の誤りがあるって事です。
コピペで失敗しているのか、
元々のサンプルに誤りがあるかは
これだけでは分かりません
文法の基本から学び直して
自分で見つけるしかないかもしれません

2024/11/24(日) 20:47:32.93

>> 358
試していただきありがとうございます．
FreeBSD clang version 18.1.6 (https://github.com/llvm/llvm-project.git llvmorg-18.1.6-0-g1118c2e05e67)
Target: x86_64-unknown-freebsd14.1
と，gccは共に jの値がおかしいのです．
試しに，
unsigned long j = 1 << 31;
を
unsigned int j = 1 << 31;
にすると同じ値になる．

これはコンパイラのBUGかなぁ．

警備員[Lv.1][新芽] (ﾜｯﾁｮｲ 9fe5-fjqo) · 2024/11/24(日) 22:17:04.46

よく分からないけど
unsigned long i = 1 << 31;
unsigned long j = 1 << 31;
を
unsigned long i = 1L << 31;
unsigned long j = 1L << 31;
とするとうまくいく？　clang

どちらでも同じ結果になりそうだけど
見当違いだったらごめんなさい

警備員[Lv.1][新芽] (ﾜｯﾁｮｲ 9fe5-fjqo) · 2024/11/24(日) 22:25:28.27

gcc -S
でアセンブラ出してみてみたけど、
いや、アセンブラよくわからないんだけど、
修正前の iと jは初期化時にいずれも符号拡張されて大きな値になっていて
その後なぜか iの方は下32ビットで、jの方は64ビットで計算されているようで、正しいのはむしろ jのように見えたがごめんなさい
本当にアセンブラ分からないので多分間違ってます…

2024/11/24(日) 22:26:25.59

gcc, clang
sizeof(int) == 32
sizeof(unsigned long) == 64
での出力

18446744071562067968,18446744071562067968,18446744071562067968
1073741824,9223372035781033984,1073741824
536870912,4611686017890516992,536870912

省略

8,68719476728,8
4,34359738364,4
2,17179869182,2
1,8589934591,1

これはこれで正しいと思うが

警備員[Lv.2][新芽] (ﾜｯﾁｮｲ 9fe5-fjqo) · 2024/11/24(日) 22:45:06.29

あ、iは unsigned (int)でキャストしてるのか

2024/11/24(日) 23:09:31.94

わかりやすく，intのものとcastかけたのにしてみました．
これだとやはり，pの値だけ変でした．

元々は，binaryで数を8bit 16bit 32bitで表示する関数が，8,16が普通で32だけ変なので気がついたのでした．なんでintだと符合拡張されなくてlongだとされるかが謎．

#include <stdio.h>

int main() {
int s=31;
unsigned long i = 1 << 31;
unsigned int j = 1 << 31;
unsigned long p = 1 << 31;
unsigned long k;

while(i) {
k = 1 << s;
printf("%lu,%u,%lu,%lu¥n",i,j,k,p);
i = (unsigned)i>>1;
j >>= 1;
p >>= 1;
s--;
}

return 0;
}

2024/11/24(日) 23:16:12.94

unsigned long p = 1 << 31;
を
unsigned long p = 1L << 31;
にしたら同じ値になりました．

ううむ，なぜ
unsigned int j = 1 << 31;
だとうまくいって，longだと1Lにしないとうまくいかんのだ．

警備員[Lv.4][新芽] (ﾜｯﾁｮｲ b72e-fjqo) · 2024/11/24(日) 23:36:41.28

右辺が 1<<31だと
左辺が intだと0x80000000がそのまま、
longだと 0xffffffff80000000に拡張されて転記されるからでは

警備員[Lv.4][新芽] (ﾜｯﾁｮｲ b72e-fjqo) · 2024/11/24(日) 23:49:31.80

unsigned long i = (unsigned long) 1 << 31;
とすれば iは 0x80000000になるかと

警備員[Lv.4][新芽] (ﾜｯﾁｮｲ b72e-fjqo) · 2024/11/24(日) 23:50:27.79

1lとするのと同じだけど

2024/11/25(月) 02:42:55.67

>>367
言語仕様的に解釈すると……

シフト演算子の結果の型は左オペランドを整数拡張した後の型と同じになる。
整数リテラルは int の範囲で表せる限り int なので 1 は int 。
int は整数拡張の必要がないので 1<<31 の結果の型も int 。

そして結果の型が signed かつ結果の値が結果の型で表現可能な範囲にないときの動作は未定義なので
2147483648 が int (おそらく質問者の環境では 32 ビット) の最大値である 2147483647 を越えていて未定義の挙動となる。

不定とか処理系定義ではなく未定義と明記されてる。
つまり言語仕様上は何が起きても良いということ。

2024/11/25(月) 07:22:58.48

6.3.1.3のこれじゃないの
Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or
subtracting one more than the maximum value that can be represented in the new type
until the value is in the range of the new type.

2024/11/25(月) 08:27:04.40

6.3.1.3

符号付き整数型及び符号無し整数型整数型の値を̲Bool型以外の他の整数型に変換する場合，

その値が新しい型で表現可能なとき，値は変化しない。

新しい型で表現できない場合，新しい型が符号無し整数型であれば，新しい型で表現しうる最大の数に

1加えた数を加えること又は減じることを，新しい型の範囲に入るまで繰り返すことによって得られる値

に変換する(49)。

なるほど，1がintで<<31すると負の最大値となって，unsignedとして表せないからか．

皆様，ありがとうございました．

2024/11/25(月) 09:22:18.85

>>372-373
いいえ。
シフト演算の段階で既に未定義を踏んでいるので型変換は関係ないです。
6.5.7 をご覧ください。

2024/11/25(月) 09:32:20.82

科学＋ンニュース 5ch

保守派もリベラル派も「自分の政治的信念に合致したニュース」を信じやすいという研究結果 [すらいむ★]
https://itest.5ch.net/egg/test/read.cgi/scienceplus/1732447647

コメントも含めて読むと
陰謀論が収まら無い理由が判明する

2024/11/25(月) 09:46:02.42

なるほど、32bitのみでやるときも1u<<31にしないといけないのか

2024/11/25(月) 10:29:04.22

なぜ浮動小数型をシフトしようとした？

2024/11/25(月) 13:39:22.46

>> 374 なるほど，そっちで既に未定義だったか．

6.5.7
ビット単位のシフト演算子
構文規則
シフト式：
加減式
シフト式 << 加減式
シフト式 >> 加減式
制約各オペランドは，整数型をもたなければならない。
意味規則整数拡張を各オペランドに適用する。結果の型は，左オペランドを拡張した後の型とする。右オペランドの値が負であるか，又は拡張した左オペランドの幅以上の場合，その動作は，未定義とする。
E1<<E2の結果は，E1をE2ビット分左にシフトした値とする。空いたビットには0を詰める。E1が符号無し整数型をもつ場合，結果の値は，E1×2E2の，結果の型で表現可能な最大値より1大きい値を法と
する剰余とする。E1が符号付き整数型と非負の値をもち，E1×2E2が結果の型で表現可能である場合，それが結果の値となる。それ以外の場合，その動作は未定義とする。

E1>>E2の結果は，E1をE2ビット分右にシフトした値とする。E1が符号無し整数型をもつ場合，又はE1が符号付き整数型と非負の値をもつ場合，結果の値は，E1/2E2の商の整数部分とする。E1が符号付き整数型と負の値をもつ場合，結果の値は処理系定義とする。

**デフォルトの名無しさん** (JP 0Hdf-6m00) · 2024/11/26(火) 22:12:07.51

VS CodeでEchoAPIを使うと、ツールを切り替えずにAPIテストをシームレスに管理できるようになったよ！

2024/11/29(金) 15:48:48.81

以下のサンプルプログラムが理解できず困っています。
該当プログラムは、コマンドラインから読み込んだBMPの色データを矩形として並べていくというものの一部を抜粋しています。

以下のfor文は
カラーテーブルの数を取得する→
ブラシを設定する→
先頭の構造体メンバからiCount先の構造体メンバを指定→
iCountにインクリメント

という流れだと考えられると思うのですが、１に対し1カラービット分左シフトとなっている部分がどういったロジックによって数の取得が実現されているのかわかりません。
質問は2点あり、どのようにしてテーブル数を取得しているのか、コードの理解は正しいのかについてお答えしていただければと思います。

サンプルコード

#include <windows.h>

BITMAPFILEHEADER bmpFileHeader;
BITMAPCOREHEADER bmpCoreHeader;
RGBTRIPLE *prtColor;

for ( ; iCount < (1 << bmpCoreHeader.bcBitCount) ; iCount++) {
SelectObject(hdc , CreateSolidBrush(
RGB( (prtColor + iCount)->rgbtRed ,
(prtColor + iCount)->rgbtGreen ,
(prtColor + iCount)->rgbtBlue
))

2024/11/29(金) 16:12:14.82

bcBitCountはピクセルあたりビット数で1,4,8,24だそう
nビットで表せる値は2^n通りで、これは左シフト1<<nで計算できる

2024/11/29(金) 23:08:43.43

# 質問されていない部分だけど…
iCountと比較する値はループ内で変動しないよね？
だったら毎回計算せずにループ前で計算して別変数に記憶しておくほうがよくないかい？

2024/11/30(土) 00:28:19.69

今時のコンパイラは十分賢いので気にすることない

2024/11/30(土) 00:37:35.21

ユーザーの犯したバグも直してくれるとありがたいなあ

2024/11/30(土) 00:47:56.34

シフトでも掛算でもどっちでもいいけど
質問者のように読んで悩むのは問題
コメント書いておけ

ループ内毎回計算か最適化でループ外に出したかは
コンパイル後の逆アセンブルとかで確認するの？
だったら間違いないようにループ外に出す方が良い癖にもなると思うのだが

2024/11/30(土) 09:43:24.89

380の知能では最適化したつもりが新たなバグを埋め込む事になるかもしれん
自身の身の丈に合ったコードにしとけ
未来の自分が賢くなってる事を信じて

2024/11/30(土) 09:49:47.60

#include <windows.h>

BITMAPFILEHEADER bmpFileHeader;
BITMAPCOREHEADER bmpCoreHeader;
RGBTRIPLE *prtColor;
↑
この間に何も描かれてないのは投稿者が勝手に削除したの？元から無いの？
↓
for ( ; iCount < (1 << bmpCoreHeader.bcBitCount) ; iCount++) {
SelectObject(hdc , CreateSolidBrush(
RGB( (prtColor + iCount)->rgbtRed ,
(prtColor + iCount)->rgbtGreen ,
(prtColor + iCount)->rgbtBlue
))

2024/11/30(土) 11:23:36.84

なんでこんなに読めないのか理由がわかった
変数名や字下げや「,」前のブランクなど
論理そのもの以前にコーディングの美しさが全然無い

2024/11/30(土) 11:53:49.47

この掲示板書き込むと、スペースやタブは消されちゃうんだよな。
だから綺麗に整形した状態でソース載せたいなら、
全角スペース使うしかない。
あるいはソース公開出来るサイトにアップロードして、
そのリンクを張るなりする。
そういうサイトは、>>1 に書いてある。

2024/11/30(土) 12:18:13.55

美しさとか言い出したら自転車置き場の議論なるからやめとけ

2024/11/30(土) 12:21:38.32

https://mevius.5ch.net/test/read.cgi/tech/1402617355/

色々試し書きしたいなら、テストスレがあるから、そこでやって

2024/11/30(土) 15:56:34.50

python自体のスタイルPEP8に加えてCについてのPEP7も整備されているのに
https://peps.python.org/pep-0007/
あえてそれに背くコーディングをする理由が見つからない
GNUのへんてこコーディングも規約文章は整備されている

2024/11/30(土) 16:28:54.09

他人のふんどしででかい顔のpythonは存在自体がきしょくってぇ
そんなもん使ってる奴の押し付けに従う気にはとてもなれないって感じぃ