!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
C言語なら俺に聞け 161
■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん (ワッチョイ 0f63-sFbk)
2023/04/21(金) 14:05:20.18ID:rqj2HSDF0363デフォルトの名無しさん (ワッチョイ e3ad-c/5M)
2023/08/06(日) 14:59:14.25ID:RhhSFLLO0 void だけ特殊な型と考えるしかないのではないかな。大きさが0ビットの型と考えても良いのかも知れないが。
364デフォルトの名無しさん (テテンテンテン MM17-2Tt6)
2023/08/06(日) 15:50:27.26ID:3R7VaRJUM sizeof(void) → 1 だな
これって正式な仕様なのか分からんけど
これって正式な仕様なのか分からんけど
365デフォルトの名無しさん (ワッチョイ 87cf-n4fA)
2023/08/06(日) 16:40:17.07ID:Raz9Sh7o0 それgccなんかの独自仕様のはず。void*をバイト単位で計算できるから便利なんだけどね。
366デフォルトの名無しさん (スッププ Sd03-EMqx)
2023/08/06(日) 17:35:17.48ID:/aV5Am17d それは気持ち悪いな
367はちみつ餃子 ◆8X2XSCHEME (ワッチョイ 5b3e-tyL0)
2023/08/06(日) 17:46:22.79ID:Mgx3ApDu0 言語仕様上は void は不完全型とする扱い、かつ sizeof に不完全型を与えることは出来ない。
368デフォルトの名無しさん (スッププ Sd03-EMqx)
2023/08/06(日) 17:48:27.27ID:/aV5Am17d gccだとsizeof(関数名)も1なんでしょ
明らかにただの手抜き
明らかにただの手抜き
369デフォルトの名無しさん (ワッチョイ b363-aAN6)
2023/08/06(日) 17:52:12.98ID:wnylhiXb0 仕様上の問題は置いておいて
1として扱うと何か良いことあるんでしょうか?
1として扱うと何か良いことあるんでしょうか?
370はちみつ餃子 ◆8X2XSCHEME (ワッチョイ 5b3e-tyL0)
2023/08/06(日) 17:56:04.37ID:Mgx3ApDu0 未定義な動作は規格として規格が何ら要求を課さないことを意味するが
但し書きの中に「文書化された環境に特有な方法で処理してもよい」ともある。
GNU C のドキュメントには void と関数 (関数指示子) の大きさについて記述がある。
https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html
これも規格が認める正しい動作のひとつ。
それはそうとして処理系に固有の挙動に依存するのを避けるに越したことは無いけど。
但し書きの中に「文書化された環境に特有な方法で処理してもよい」ともある。
GNU C のドキュメントには void と関数 (関数指示子) の大きさについて記述がある。
https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html
これも規格が認める正しい動作のひとつ。
それはそうとして処理系に固有の挙動に依存するのを避けるに越したことは無いけど。
371デフォルトの名無しさん (ワッチョイ 87cf-n4fA)
2023/08/06(日) 18:03:13.82ID:Raz9Sh7o0372はちみつ餃子 ◆8X2XSCHEME (ワッチョイ 5b3e-tyL0)
2023/08/06(日) 18:10:14.29ID:Mgx3ApDu0 void* は演算させないという意思表示なこともあるんで
演算できることが良いわけでもないんだけどね。
演算できることが良いわけでもないんだけどね。
373デフォルトの名無しさん (ワッチョイ 87cf-n4fA)
2023/08/06(日) 18:29:53.89ID:Raz9Sh7o0 どんな用途があるかな?デリファレンス先にアクセスできないってだけで十分な気もするが。
374デフォルトの名無しさん (アウアウウー Sa9f-W3Bx)
2023/08/06(日) 18:36:51.14ID:mq8IFmf1a 任意に渡ってきたポインタ間の距離?
375デフォルトの名無しさん (ワッチョイ 7510-WTQk)
2023/08/07(月) 01:08:17.44ID:zJXXdP4R0 アレじゃないかな?メリットあるとしたら
【struct に含めたメンバーは、サイズゼロはダメ】っていう仕様があったかと思う。
正確には【structの違うメンバーが同じアドレスになったらダメ】だったか
----
以下は蛇足
ただサイズゼロだめってのは例外があって。
structの末尾メンバーでchar[] だか char[0]ってのが、確かC99あたりでアリになった気がする。
これは…それまでも使われてたテクで
【structの最後に char [1] のメンバーを置いて、実際にはメモリ確保の時structのサイズ+可変長部のサイズでメモリ確保し、最後のメンバーを使ってstructのサイズを超えてアクセスする】という慣用句があって、
それの目的で
C言語公式仕様風では char[1] と書き
確か昔は gccだとchar[]
vcだと char[0]
ていう書き方してた。(gccとvcは逆だったかも知れない)
のが、公式仕様でもサイズゼロokになった…という話だったかと。
【struct に含めたメンバーは、サイズゼロはダメ】っていう仕様があったかと思う。
正確には【structの違うメンバーが同じアドレスになったらダメ】だったか
----
以下は蛇足
ただサイズゼロだめってのは例外があって。
structの末尾メンバーでchar[] だか char[0]ってのが、確かC99あたりでアリになった気がする。
これは…それまでも使われてたテクで
【structの最後に char [1] のメンバーを置いて、実際にはメモリ確保の時structのサイズ+可変長部のサイズでメモリ確保し、最後のメンバーを使ってstructのサイズを超えてアクセスする】という慣用句があって、
それの目的で
C言語公式仕様風では char[1] と書き
確か昔は gccだとchar[]
vcだと char[0]
ていう書き方してた。(gccとvcは逆だったかも知れない)
のが、公式仕様でもサイズゼロokになった…という話だったかと。
376デフォルトの名無しさん (ワッチョイ 7510-WTQk)
2023/08/07(月) 01:23:44.93ID:zJXXdP4R0 あ、メリットの言い方をすると
処理系内でstructのサイズ計算を実装するにあたって、あらゆる型がサイズ1以上である事が分かっていれば、合算処理を合理的に実装する事ができる
…よね?
処理系内でstructのサイズ計算を実装するにあたって、あらゆる型がサイズ1以上である事が分かっていれば、合算処理を合理的に実装する事ができる
…よね?
377デフォルトの名無しさん (スッップ Sdd7-EMqx)
2023/08/07(月) 08:18:18.04ID:SwgOJiZRd 意味不明
メンバーにvoidを含められたとしても参照すればエラーになるはずなので使いようがない
(void*はもともと正しいサイズを持つ)
unionで似たようなことはできる
メンバーにvoidを含められたとしても参照すればエラーになるはずなので使いようがない
(void*はもともと正しいサイズを持つ)
unionで似たようなことはできる
378はちみつ餃子 ◆8X2XSCHEME (ワッチョイ 5b3e-tyL0)
2023/08/07(月) 09:11:24.17ID:U9It/DCQ0 >>375
サイズゼロをOKとすると言ってしまうと語弊があると思う。
仕様上の理屈だと「不完全型を指定できる」だし、そうした場合の動作は
いくつかの特例で成立していて「長さ 0 の配列」は現れない。
sizeof などでは「フレキシブル配列メンバは無視される」だし、
メンバにアクセスするときは
> 置き換えられた配列が要素をもたないとき,それはただ一つの要素をもつのと同じ規則で動作する。
> しかし,その要素にアクセスした場合,又はその要素を一つ越えたポインタを生成した場合,
> その動作は未定義とする。
とあって、長さ 1 として扱うけど要素にはアクセスするなという回りくどい言い回しになってる。
サイズゼロをOKとすると言ってしまうと語弊があると思う。
仕様上の理屈だと「不完全型を指定できる」だし、そうした場合の動作は
いくつかの特例で成立していて「長さ 0 の配列」は現れない。
sizeof などでは「フレキシブル配列メンバは無視される」だし、
メンバにアクセスするときは
> 置き換えられた配列が要素をもたないとき,それはただ一つの要素をもつのと同じ規則で動作する。
> しかし,その要素にアクセスした場合,又はその要素を一つ越えたポインタを生成した場合,
> その動作は未定義とする。
とあって、長さ 1 として扱うけど要素にはアクセスするなという回りくどい言い回しになってる。
379デフォルトの名無しさん (アウアウウー Sa9d-mBaV)
2023/08/07(月) 10:17:41.09ID:wl/Lx6N5a >>375
typedef struct { int x; char a[1]; } A; A *p = (A *)malloc(sizeof(A) - 1 + N);
typedef struct { int y; char b[]; } B; B *q = (B *)malloc(sizeof(B) + N);
typedef struct { int z; char c[0]; } C; C *r = (C *)malloc(sizeof(C) + N);
かな
typedef struct { int x; char a[1]; } A; A *p = (A *)malloc(sizeof(A) - 1 + N);
typedef struct { int y; char b[]; } B; B *q = (B *)malloc(sizeof(B) + N);
typedef struct { int z; char c[0]; } C; C *r = (C *)malloc(sizeof(C) + N);
かな
380デフォルトの名無しさん (アウアウウー Sa9d-mBaV)
2023/08/07(月) 10:19:25.16ID:wl/Lx6N5a >>378 の主張だと
typedef struct { int y; char b[]; } B; B *q = (B *)malloc(sizeof(B) - 1 + N);
でなければならないのかな
typedef struct { int y; char b[]; } B; B *q = (B *)malloc(sizeof(B) - 1 + N);
でなければならないのかな
381はちみつ餃子 ◆8X2XSCHEME (ワッチョイ 5b3e-tyL0)
2023/08/07(月) 11:05:26.04ID:U9It/DCQ0 >>379
配列の大きさとして 1 を指定して可変長のように扱うやり方については
ちょっと不明瞭なんだが仕様に厳密にいうと準拠してない方法だと考えられている。
https://c-faq.com/struct/structhack.html
配列の大きさが 0 より大きくなければならないということについては
例外を見つけられないのでどこであろうと 0 を指定したら未定義と解釈していいと思う。
GNU C では構造体メンバの最後の配列要素に 0 を指定した場合は
C99 でフレキシブル配列メンバにしたときとほぼ同じような扱いになることがドキュメント化されてる。
https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
つまり GNU C では 0 を指定していいわけだが……結果が同じならあえてやる必要もないな。
GNU C でも構造体の最後の要素を除いて配列の大きさに 0 を指定するのは (可能だが) 推奨されていない。
アクセスした結果は未定義なのでなんの役に立つのかようわからん。
配列の大きさとして 1 を指定して可変長のように扱うやり方については
ちょっと不明瞭なんだが仕様に厳密にいうと準拠してない方法だと考えられている。
https://c-faq.com/struct/structhack.html
配列の大きさが 0 より大きくなければならないということについては
例外を見つけられないのでどこであろうと 0 を指定したら未定義と解釈していいと思う。
GNU C では構造体メンバの最後の配列要素に 0 を指定した場合は
C99 でフレキシブル配列メンバにしたときとほぼ同じような扱いになることがドキュメント化されてる。
https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
つまり GNU C では 0 を指定していいわけだが……結果が同じならあえてやる必要もないな。
GNU C でも構造体の最後の要素を除いて配列の大きさに 0 を指定するのは (可能だが) 推奨されていない。
アクセスした結果は未定義なのでなんの役に立つのかようわからん。
382デフォルトの名無しさん (スッップ Sdd7-EMqx)
2023/08/07(月) 11:36:51.88ID:SwgOJiZRd383デフォルトの名無しさん (ブーイモ MMf3-DyKn)
2023/08/07(月) 14:20:51.17ID:Xd8Y6/QgM384はちみつ餃子 ◆8X2XSCHEME (ワッチョイ 5b3e-tyL0)
2023/08/07(月) 14:26:13.65ID:U9It/DCQ0 >>382-383
どっちも間違い。 この場合は -1 をしてはいけない。
どっちも間違い。 この場合は -1 をしてはいけない。
385デフォルトの名無しさん (スッップ Sdd7-EMqx)
2023/08/07(月) 20:36:36.16ID:SwgOJiZRd386はちみつ餃子 ◆8X2XSCHEME (ワッチョイ eb32-oz9p)
2023/08/07(月) 21:06:32.92ID:+g1cDN8+0 >>385
1バイトごときのために余計なことをしないってのは理解できる理屈だが、不必要な1バイトを確保するってのもそれはそれで無駄に考えさせられてしまう感じがする。
やろうとしていることと合致しないコードなわけだから。
害はないが役に立ってもいないということを確信するのはどういう役に立っているのかを見つけるより難しい。
1バイトごときのために余計なことをしないってのは理解できる理屈だが、不必要な1バイトを確保するってのもそれはそれで無駄に考えさせられてしまう感じがする。
やろうとしていることと合致しないコードなわけだから。
害はないが役に立ってもいないということを確信するのはどういう役に立っているのかを見つけるより難しい。
387デフォルトの名無しさん (ブーイモ MMf3-DyKn)
2023/08/07(月) 21:30:20.59ID:6YHeZP2fM388デフォルトの名無しさん (スッップ Sdd7-EMqx)
2023/08/07(月) 22:08:57.23ID:SwgOJiZRd >>386
どうせmallocは1バイト単位では確保しないので正確なサイズを指定しても構造体一個につき数バイト以上の無駄な領域が確保されることになるし…
この構造体を数万個単位で使うような大規模プログラムで極力ムダを避けたいならmallocは使わず最初に大きなリニア領域を確保してそこから切り分けたほうがいいだろう
蛇足だが経験上こういう構造体を使うときはcopy=malloc(sizeof(A) + strlen(src)); strcpy(copy->a,src);のように使うことが多い
これなら正確なサイズ指定になる
>>387
どっちにしろ君は何か勘違いしてないかな
長ったらしく書くなら-sizeof(int)ではなく-sizeof(char)となる
どうせmallocは1バイト単位では確保しないので正確なサイズを指定しても構造体一個につき数バイト以上の無駄な領域が確保されることになるし…
この構造体を数万個単位で使うような大規模プログラムで極力ムダを避けたいならmallocは使わず最初に大きなリニア領域を確保してそこから切り分けたほうがいいだろう
蛇足だが経験上こういう構造体を使うときはcopy=malloc(sizeof(A) + strlen(src)); strcpy(copy->a,src);のように使うことが多い
これなら正確なサイズ指定になる
>>387
どっちにしろ君は何か勘違いしてないかな
長ったらしく書くなら-sizeof(int)ではなく-sizeof(char)となる
389デフォルトの名無しさん (ワッチョイ 7510-WTQk)
2023/08/07(月) 22:21:06.53ID:zJXXdP4R0 どんどん蛇足的になってしまってる気はするが
1バイトの加減算ってのはインクリ・デクリの1命令で演算できるし分岐しないし、
アライメント境界を1バイト超えたらバス幅分-1の無駄ができるかもなので
しかも100万個の「3d座標型」とかがその理屈で1個につき7バイト無駄にしたら700万バイトが無駄になるので
たかが1バイトと軽視して良いか否かは、状況によります
で、はちみつさんのちみつな調査に感謝。蛇足で変な事書いて仕事増やしてごめんなさい
1バイトの加減算ってのはインクリ・デクリの1命令で演算できるし分岐しないし、
アライメント境界を1バイト超えたらバス幅分-1の無駄ができるかもなので
しかも100万個の「3d座標型」とかがその理屈で1個につき7バイト無駄にしたら700万バイトが無駄になるので
たかが1バイトと軽視して良いか否かは、状況によります
で、はちみつさんのちみつな調査に感謝。蛇足で変な事書いて仕事増やしてごめんなさい
390デフォルトの名無しさん (ワッチョイ 7510-WTQk)
2023/08/07(月) 22:28:38.60ID:zJXXdP4R0 でも、ワシは(もしそれが有効だと判断したら)公式なC言語仕様上未定義になるとしても、
伝統的にgccとvcが「独自拡張」として許してきた書き方で
書くよ
もちろん責任者の許可は伺うけどね
ダメと言われたらもちろんやらない
伝統的にgccとvcが「独自拡張」として許してきた書き方で
書くよ
もちろん責任者の許可は伺うけどね
ダメと言われたらもちろんやらない
391デフォルトの名無しさん (ワッチョイ 0547-DyKn)
2023/08/07(月) 22:34:55.16ID:hZrkDm/B0 >>388
ちゃんとサイズ確かめた?そんなに簡単なら[]拡張なんて要らないと思わない?
ちゃんとサイズ確かめた?そんなに簡単なら[]拡張なんて要らないと思わない?
392デフォルトの名無しさん (ワッチョイ 7510-WTQk)
2023/08/07(月) 22:36:31.40ID:zJXXdP4R0 で
時には自分が、あるプロジェクトの最高責任者だったりする訳で
その環境は特定のカスタムgccの特定バージョンを使うしか選択肢がないから無用な心配は意味がなくて
次のプロジェクトではどうせ全部作り直しだったりする
時には自分が、あるプロジェクトの最高責任者だったりする訳で
その環境は特定のカスタムgccの特定バージョンを使うしか選択肢がないから無用な心配は意味がなくて
次のプロジェクトではどうせ全部作り直しだったりする
393デフォルトの名無しさん (スッップ Sdd7-EMqx)
2023/08/07(月) 22:48:24.16ID:SwgOJiZRd394デフォルトの名無しさん (ワッチョイ 0547-DyKn)
2023/08/07(月) 22:52:47.17ID:hZrkDm/B0 >>393
sizeof(A) != sizeof(int) + sizeof(char)
sizeof(A) != sizeof(int) + sizeof(char)
395デフォルトの名無しさん (ワッチョイ 0b01-W3Bx)
2023/08/07(月) 23:31:53.12ID:+QyISSA90396デフォルトの名無しさん (ワッチョイ 0b01-W3Bx)
2023/08/07(月) 23:39:40.36ID:+QyISSA90397デフォルトの名無しさん (スップ Sdcf-YWx9)
2023/08/08(火) 07:56:15.14ID:QQsYUamCd 引き算とか言ってる馬鹿初めて見たわ
398デフォルトの名無しさん (ワッチョイ b363-uQHI)
2023/08/08(火) 11:03:00.71ID:+jW/mKCz0 複素数使って計算すれば馬鹿にされませんよ?
399デフォルトの名無しさん (スッップ Sdd7-EMqx)
2023/08/08(火) 20:31:55.04ID:sLVQKk30d400デフォルトの名無しさん (ブーイモ MMf3-DyKn)
2023/08/08(火) 22:38:48.82ID:MjZ+EK1qM >>399
初歩的な構造体のパッキングルールを理解していたらどうって事無いはずなのだけども…この程度で可読性とか労力とか、そういうレベルの仕事なら使用禁止で良いんじゃないかな。
あと、何か勘違いしているようだけど、[1]だとややこしいけど出来るねって言ってだけで、使うなら[]だよ。c99標準な訳だし。
初歩的な構造体のパッキングルールを理解していたらどうって事無いはずなのだけども…この程度で可読性とか労力とか、そういうレベルの仕事なら使用禁止で良いんじゃないかな。
あと、何か勘違いしているようだけど、[1]だとややこしいけど出来るねって言ってだけで、使うなら[]だよ。c99標準な訳だし。
401デフォルトの名無しさん (スッップ Sdd7-EMqx)
2023/08/09(水) 00:47:58.70ID:3Zyc8vU6d 「-sizeof(int) が正解」とは言えないよ環境による
パッキングルールを変更できる#pragmaもあるから
それは単なる「思い込み」ということになるな
パッキングルールを変更できる#pragmaもあるから
それは単なる「思い込み」ということになるな
402デフォルトの名無しさん (ワッチョイ 7510-WTQk)
2023/08/09(水) 06:00:17.77ID:ye8eZ1o40403デフォルトの名無しさん (アウアウウー Sa9d-mBaV)
2023/08/09(水) 08:10:28.54ID:KudoDE9Va 言語仕様知らずに叩いてるんだから無理だろ
404デフォルトの名無しさん (ワッチョイ 915f-1PqA)
2023/08/11(金) 14:52:37.80ID:fYiGiCzQ0 質問失礼します
Windowsソフトが作りたく基礎を勉強したのですがここからソフトを作る道筋が見えてきません
SDKを用い制作するということまではわかったのですがそれについて解説しているサイトがなく詰まっている状態です
おすすめのサイトや参考書などあればご教示くさだい
Windowsソフトが作りたく基礎を勉強したのですがここからソフトを作る道筋が見えてきません
SDKを用い制作するということまではわかったのですがそれについて解説しているサイトがなく詰まっている状態です
おすすめのサイトや参考書などあればご教示くさだい
405デフォルトの名無しさん (スフッ Sd2f-SP/C)
2023/08/11(金) 15:39:30.67ID:zcS71Tbhd406はちみつ餃子 ◆8X2XSCHEME (ワッチョイ 5b3e-oz9p)
2023/08/11(金) 15:46:47.16ID:EnF/lRSf0 モダンなフレームワークを使った方が良いが
Windows の基礎的な理念というか考え方をかなり平易に
説明したものということだと↓とかが有名だと思う。
http://www.kumei.ne.jp/c_lang/
ただ、古いので実情に合わない部分はある。
Windows には異なる系統の API があって、
現在では COM をベースにした WinRT がモダン API として
整備されているのでそちらを軸にしても良いかもしれない。
Windows の基礎的な理念というか考え方をかなり平易に
説明したものということだと↓とかが有名だと思う。
http://www.kumei.ne.jp/c_lang/
ただ、古いので実情に合わない部分はある。
Windows には異なる系統の API があって、
現在では COM をベースにした WinRT がモダン API として
整備されているのでそちらを軸にしても良いかもしれない。
407デフォルトの名無しさん (ワッチョイ b363-yDkU)
2023/08/11(金) 16:09:36.01ID:Ib19PZqn0 SDK使っての開発は30年位昔のやり方なんではないだろうか
408デフォルトの名無しさん (ワッチョイ 915f-1PqA)
2023/08/11(金) 16:11:15.49ID:fYiGiCzQ0409デフォルトの名無しさん (ワッチョイ 915f-1PqA)
2023/08/11(金) 16:12:13.55ID:fYiGiCzQ0 >>407
基礎しかわからない初心者なものでして、、、
基礎しかわからない初心者なものでして、、、
410デフォルトの名無しさん (ワッチョイ e3ad-c/5M)
2023/08/11(金) 16:53:28.21ID:j3k4ZyED0 Windows のネイティブなプログラム作りには C というよりは C++ の方がよく使われていたと思うので、C++ も覚えた方が作り易くなるような気がする。
411デフォルトの名無しさん (アウアウウー Sa9d-SP/C)
2023/08/11(金) 17:26:57.28ID:v1edpQDwa412デフォルトの名無しさん (ワッチョイ e3ad-c/5M)
2023/08/11(金) 17:52:29.73ID:j3k4ZyED0 なるほど。
413デフォルトの名無しさん (ワッチョイ b363-yDkU)
2023/08/11(金) 17:54:37.84ID:Ib19PZqn0 最初残ろは16ビットアプリだったから、
メモリーモデルやアプリが使用可能なリソースサイズなど
結構管理が大変だった記憶がある
メモリーモデルやアプリが使用可能なリソースサイズなど
結構管理が大変だった記憶がある
414デフォルトの名無しさん (ワッチョイ b363-yDkU)
2023/08/11(金) 17:55:37.06ID:Ib19PZqn0 最初のころは
なんて変換するんだよ・・・
なんて変換するんだよ・・・
415デフォルトの名無しさん (ワッチョイ 87cf-uQHI)
2023/08/11(金) 18:22:42.78ID:WGGkjKOg0 勉強目的の縛りプレイじゃなければ最初からCじゃなくC++使う方が良いと思うが。
416デフォルトの名無しさん (ワッチョイ c379-IXit)
2023/08/11(金) 18:30:11.06ID:I7dwFhkG0 いまだにCOM ATL DirectX IDL辺りの定義見るとC知識では手に負えないイメージ
C++MFC全盛の時代は本当に嫌いだった
C#でそれらに一切関わる必要がなくなってほんと良かったわ
C++MFC全盛の時代は本当に嫌いだった
C#でそれらに一切関わる必要がなくなってほんと良かったわ
417デフォルトの名無しさん (ワッチョイ 2f9f-mBaV)
2023/08/11(金) 18:52:16.19ID:DMm7pQwE0 古いAPIの設計思想が時代に合わないのも多いし、フレッシュな知識を蓄積したほうがいいという意味ではWinRTかな
418デフォルトの名無しさん (ワッチョイ c379-IXit)
2023/08/11(金) 19:09:53.39ID:I7dwFhkG0 >WinRTかな
名前が終わってる
名前が終わってる
419デフォルトの名無しさん (アウアウウー Sa9d-mBaV)
2023/08/11(金) 19:10:12.84ID:v1edpQDwa DirectXはCでも使える
420デフォルトの名無しさん (アウアウウー Sa9d-mBaV)
2023/08/11(金) 19:11:09.76ID:v1edpQDwa MFCは糞だから触るな危険
421デフォルトの名無しさん (アウアウウー Sa9d-mBaV)
2023/08/11(金) 19:12:06.88ID:v1edpQDwa WinRTはないな
422デフォルトの名無しさん (ワッチョイ 0902-MkJ9)
2023/08/11(金) 19:17:33.71ID:yxSWeMo+0 とりあえず現在でWindowsアプリのプログラミングを始めるにあたり、C言語というのはやめるべき
悪いこと言わないからせめてC++にしておけ
そして楽に作りたいならC#にしておけ
悪いこと言わないからせめてC++にしておけ
そして楽に作りたいならC#にしておけ
423はちみつ餃子 ◆8X2XSCHEME (ワッチョイ 5b3e-oz9p)
2023/08/11(金) 19:26:30.18ID:EnF/lRSf0 C でやってみれば (やれるだけの知識を身に付ければ) 低レイヤで何が起こっているのかという具体的なメカニズムを理解できるという意味で悪くはないと思う。
ただ、今となっては日常的にやるもんではない。
ただ、今となっては日常的にやるもんではない。
424デフォルトの名無しさん (ワッチョイ c379-IXit)
2023/08/11(金) 19:26:45.26ID:I7dwFhkG0 C#で.NETにない事をやろうとするとpnvoke知識が必須だから
Cを適当に摘みつつC#でいいんじゃなかろうか
C++はもう時間の無駄
時間が無限にあるならどうぞ
Cを適当に摘みつつC#でいいんじゃなかろうか
C++はもう時間の無駄
時間が無限にあるならどうぞ
425デフォルトの名無しさん (ワッチョイ b363-yDkU)
2023/08/11(金) 19:35:56.75ID:Ib19PZqn0 Windowsの動作原理を学びたいなら、SDKやMFCは良いと思うよ
426デフォルトの名無しさん (テテンテンテン MM17-2Tt6)
2023/08/11(金) 19:53:56.21ID:eb/xI15cM 今のWindowsの最新のUIは全てWinRTの上に構築されている
Githubでソース見れば一目瞭然
完全に今のWindowsの基礎となるAPI
無知というのは罪だな
Githubでソース見れば一目瞭然
完全に今のWindowsの基礎となるAPI
無知というのは罪だな
427デフォルトの名無しさん (ワッチョイ c379-IXit)
2023/08/11(金) 19:58:54.93ID:I7dwFhkG0 まさかWinRTでマウント取ろうとする馬鹿が居ると思わないわ
428デフォルトの名無しさん (ワッチョイ 0f5f-4nYy)
2023/08/11(金) 20:00:58.18ID:xXGnDnZp0 黙NG
429デフォルトの名無しさん (テテンテンテン MM17-2Tt6)
2023/08/11(金) 20:32:13.88ID:iNvWur52M430デフォルトの名無しさん (テテンテンテン MM17-2Tt6)
2023/08/11(金) 20:35:15.14ID:iNvWur52M >>427
WinRT終わってるとか無いわーw
WinRT終わってるとか無いわーw
431デフォルトの名無しさん (ワッチョイ b363-yDkU)
2023/08/11(金) 21:00:42.88ID:Ib19PZqn0 変なのが湧いてきたね
432デフォルトの名無しさん (ワッチョイ 6b7a-o30X)
2023/08/11(金) 23:10:37.93ID:je510yk+0 mallocの戻り値は代入先のポインタ型にキャストして使おうと言ってる入門サイトがほとんどです。
これは正しくなくて、キャスト不要が正しいと思いますが達人の皆さんの意見はどうですか。
これは正しくなくて、キャスト不要が正しいと思いますが達人の皆さんの意見はどうですか。
433デフォルトの名無しさん (ワッチョイ 87cf-uQHI)
2023/08/11(金) 23:16:31.85ID:WGGkjKOg0 void*はキャストしなきゃ使いようがないだろ
434蟻人間 ◆T6xkBnTXz7B0 (スフッ Sdd7-38VD)
2023/08/11(金) 23:37:09.78ID:903ETN7Yd C++ならvoid*からのキャスト必須。C言語ならキャスト不要。
435デフォルトの名無しさん (ワッチョイ ab36-uQHI)
2023/08/11(金) 23:43:24.35ID:ayxoKHEe0 現場猫案件。
436デフォルトの名無しさん (テテンテンテン MMb6-v80P)
2023/08/12(土) 00:37:36.88ID:dWTISXa3M >>431
害悪はオマエだろ!
WinRTが終わったAPIみたいなフェイクを正したんだよ!
WinUIとかGithubでソース公開されてんだから、ソース見れば一目瞭然だろ!
2度とフェイクを書き込むなよ!
害悪はオマエだろ!
WinRTが終わったAPIみたいなフェイクを正したんだよ!
WinUIとかGithubでソース公開されてんだから、ソース見れば一目瞭然だろ!
2度とフェイクを書き込むなよ!
437デフォルトの名無しさん (ワッチョイ df9f-DXLR)
2023/08/12(土) 01:20:09.40ID:PG846lpi0 もしかしてWindowsRT(ARM版Windows8)と勘違いしてたりして
438デフォルトの名無しさん (テテンテンテン MMb6-v80P)
2023/08/12(土) 02:14:36.52ID:dWTISXa3M WindowsRTは失敗したプロダクトだけど、WinRTは完全にWin32を置き換える為のモダンな基盤APIになった
ちなみにWinRTに関する情報は全然出回ってないな(少なくとも日本では)
MSも直接使うAPIじゃないと考えてるのかもしれない
実際、WinUI3とかを通して使うことになるのだろう
ちなみにWinRTに関する情報は全然出回ってないな(少なくとも日本では)
MSも直接使うAPIじゃないと考えてるのかもしれない
実際、WinUI3とかを通して使うことになるのだろう
439デフォルトの名無しさん (テテンテンテン MMb6-v80P)
2023/08/12(土) 02:21:43.01ID:dWTISXa3M MSは一時的に、DirectXやActiveXみたいにRTを流行らそうと考えてたふしがある
でも、まったく浸透せずにRTに悪いイメージだけが残ったw
でも、まったく浸透せずにRTに悪いイメージだけが残ったw
440デフォルトの名無しさん (アウアウウー Sac7-DXLR)
2023/08/12(土) 04:30:30.39ID:XzrhAFZoa ないわ
441はちみつ餃子 ◆8X2XSCHEME (ワッチョイ 7f3e-Z7S6)
2023/08/12(土) 11:53:24.11ID:BlsfQ4Nv0 >>432
型変換とキャストを混同して説明していることがそれなりにある。
それとは別に不要でもキャストすべきかどうかというのは習慣の問題。 人にとっての読みやすさは仕様上の要・不用とは別の話なので明瞭な答えはない。
型変換とキャストを混同して説明していることがそれなりにある。
それとは別に不要でもキャストすべきかどうかというのは習慣の問題。 人にとっての読みやすさは仕様上の要・不用とは別の話なので明瞭な答えはない。
442デフォルトの名無しさん (オイコラミネオ MMe3-vKG+)
2023/08/12(土) 12:15:02.77ID:ufIhf+igM UWPのWinRTでファイルアクセスなどに制約がある場合があって
APIレベルでセキュリティ上の制限があるのかと思ってたが間違いで
他のプラットフォームで呼ぶと普通に色々アクセス出来てしまう
APIレベルでセキュリティ上の制限があるのかと思ってたが間違いで
他のプラットフォームで呼ぶと普通に色々アクセス出来てしまう
443デフォルトの名無しさん (ワッチョイ 7679-BXQ2)
2023/08/12(土) 14:04:01.34ID:DbL0Mu2X0 そろそろ他所でやってくれんか
普段Windowsには世話になってるけどUWPの存在には憎しみさえ感じる
普段Windowsには世話になってるけどUWPの存在には憎しみさえ感じる
444デフォルトの名無しさん (ワッチョイ 9aad-eQmn)
2023/08/12(土) 14:18:40.69ID:2oorck2f0445はちみつ餃子 ◆8X2XSCHEME (ワッチョイ 7f3e-po/e)
2023/08/12(土) 14:53:08.69ID:BlsfQ4Nv0446はちみつ餃子 ◆8X2XSCHEME (ワッチョイ 7f3e-po/e)
2023/08/12(土) 14:54:12.64ID:BlsfQ4Nv0447デフォルトの名無しさん (ワッチョイ 9701-DXLR)
2023/08/12(土) 20:19:50.46ID:eS+ePZlf0 「毎日出社したい」わずか3.8% リモートワーク経験者に聞いた
学研ホールディングスのグループ会社であるベンド(東京都千代田区)は、リモートワーク
経験者を対象に「リモートワークに関するアンケート」を実施した。その結果、半数近くの
人が「週5(フルリモート)」(44.4%)をリモートワークの理想の頻度だと考えていること
が分かった。
次いで「週3〜4」(30.7%)、「週1〜2」(20.1%)と続き、96.2%の人がリモートワークの
継続を希望していることが分かった。毎日出社を希望する人は、わずか3.8%だった。
出社を希望しない理由は「通勤にかかる時間や体力がもったいない」「子どもの都合で、
リモートワークのほうが仕事と家庭のバランスが取りやすい」「職場の人と毎日顔を合わせる
のはさすがにつらい」といった意見が寄せられた。
一方、「コミュニケーションが取りにくくなる」「出社しないとできない業務がある」
「たまには出社もいい気分転換になる」など、完全リモートだと不都合だという声もあった。
学研ホールディングスのグループ会社であるベンド(東京都千代田区)は、リモートワーク
経験者を対象に「リモートワークに関するアンケート」を実施した。その結果、半数近くの
人が「週5(フルリモート)」(44.4%)をリモートワークの理想の頻度だと考えていること
が分かった。
次いで「週3〜4」(30.7%)、「週1〜2」(20.1%)と続き、96.2%の人がリモートワークの
継続を希望していることが分かった。毎日出社を希望する人は、わずか3.8%だった。
出社を希望しない理由は「通勤にかかる時間や体力がもったいない」「子どもの都合で、
リモートワークのほうが仕事と家庭のバランスが取りやすい」「職場の人と毎日顔を合わせる
のはさすがにつらい」といった意見が寄せられた。
一方、「コミュニケーションが取りにくくなる」「出社しないとできない業務がある」
「たまには出社もいい気分転換になる」など、完全リモートだと不都合だという声もあった。
448デフォルトの名無しさん (ワッチョイ b67a-TNXw)
2023/08/12(土) 22:15:14.90ID:jlvbpae70449はちみつ餃子 ◆8X2XSCHEME (ワッチョイ 7f3e-Z7S6)
2023/08/12(土) 22:54:57.04ID:BlsfQ4Nv0450デフォルトの名無しさん (アウアウウー Sac7-DXLR)
2023/08/13(日) 11:59:59.00ID:mxfdwtiAa int *p = (int *)malloc(400);
冗長ではないよ
冗長ではないよ
451デフォルトの名無しさん (ワッチョイ 6301-vKG+)
2023/08/13(日) 22:00:40.70ID:37XsjItY0 C++でnewではなくmallocをあえて使う理由って何かあるのかな?
452デフォルトの名無しさん (ワッチョイ b67a-TNXw)
2023/08/13(日) 23:29:06.42ID:oUeYwTCa0453デフォルトの名無しさん (ワッチョイ 7679-BXQ2)
2023/08/14(月) 00:14:53.81ID:VnUPK1/b0 void *が無かった頃はmallocもintやchar *を返していた時代がある
処理系渡り歩いてきた老害ほどmallocでキャストしたがるだけだろ
大した話でも何でもない
処理系渡り歩いてきた老害ほどmallocでキャストしたがるだけだろ
大した話でも何でもない
454デフォルトの名無しさん (ワッチョイ 9aad-eQmn)
2023/08/14(月) 00:21:55.24ID:B5PklEie0 可読性を上げるためでもあるのでは?
455はちみつ餃子 ◆8X2XSCHEME (ワッチョイ 7f3e-po/e)
2023/08/14(月) 00:30:57.60ID:sy90BXR10456デフォルトの名無しさん (ワッチョイ 9aad-eQmn)
2023/08/14(月) 00:38:36.06ID:B5PklEie0 まあ確かに型がすぐ分かる場合は意味ないな。
457デフォルトの名無しさん (ワッチョイ 4e46-8Neb)
2023/08/14(月) 09:03:40.40ID:6kZXa4aF0458デフォルトの名無しさん (オイコラミネオ MMe3-vKG+)
2023/08/14(月) 09:28:55.46ID:4XD1xMqSM この話が一番冗長だtoomou
kanjidenakunatta
kanjidenakunatta
459はちみつ餃子 ◆8X2XSCHEME (ワッチョイ 7f3e-Z7S6)
2023/08/14(月) 10:36:19.28ID:sy90BXR10 >>452
K&R の第二版 (日本語版) でもキャストは必要だと書かれているんだよなあ……。
本の最後に仕様をまとめているところでは暗黙に変換されることも言及されているのでおそらく改定漏れなだけなんだろうけど。
かなり長く定番の入門書だったのでこの本の影響も大きいと思う。
K&R の第二版 (日本語版) でもキャストは必要だと書かれているんだよなあ……。
本の最後に仕様をまとめているところでは暗黙に変換されることも言及されているのでおそらく改定漏れなだけなんだろうけど。
かなり長く定番の入門書だったのでこの本の影響も大きいと思う。
460デフォルトの名無しさん (ワッチョイ 4e63-GMkv)
2023/08/14(月) 11:55:47.09ID:s6PscRDz0 暗黙に変換って、プログラム書いてる本人の意図通りなら良いんだけど
意図と違った変換するとやっかいだな
意図と違った変換するとやっかいだな
461デフォルトの名無しさん (オイコラミネオ MMe3-vKG+)
2023/08/14(月) 13:20:28.84ID:JlnnwsPwM ここがC言語スレだと思い出して欲しい
462デフォルトの名無しさん (スップ Sd5a-f0d0)
2023/08/14(月) 13:23:53.19ID:4NX3l0Vmd Cの暗黙の型変換なんて高が知れてるだろ
463デフォルトの名無しさん (テテンテンテン MMb6-v80P)
2023/08/14(月) 14:02:18.88ID:XhXbjspZM 昔のmalloc()ってchar*とか返してた気がするな
最初っからvoid*って有ったのだろうか?
最初っからvoid*って有ったのだろうか?
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 日本行き空路49万件キャンセル 中国自粛呼びかけ 日本行きチケット予約の約32%に相当 ★4 [ぐれ★]
- 【音楽】Perfume・あ~ちゃんの結婚相手「一般男性」は吉田カバンの社長・吉田幸裕氏(41) 高身長で山本耕史似 [Ailuropoda melanoleuca★]
- 中国の局長は「両手をポケット」で対峙 宣伝戦で国民に示す ★3 [蚤の市★]
- 【大分】佐賀関で大規模火災、170棟以上が延焼中 70代男性1人と連絡取れず [ぐれ★]
- 【サッカー】U-17日本代表、激闘PK戦制す 北朝鮮撃破で6大会ぶり8強入り U17W杯 [久太郎★]
- 「クマはなるべく山に返す努力を」「クマと戦争は間違っている」動物保護活動家の主張 棲み分けと学習放獣でクマ被害なくなるのか?★7 [ぐれ★]
- とらせん IPあり
- 巨専】
- こいせん 全レス転載禁止
- 侍ジャパンシリーズ2025「日本vs韓国」その12
- 【DAZN】ワールドカップ欧州予選総合 ★5
- 【ATP】テニス総合実況スレ2025 Part 211【WTA】
- 【悲報】大分市佐賀関の火事、20軒→170軒に延焼🔥 [481941988]
- アンケート調査で「高市発言は問題なし」 93.5%wwwwwwwwwwwwwwwwwwwwwwwww [279254606]
- 肴は炙った〰イカでいい〰って歌あるじゃん?
- 自閉症が「んなっしょい」と連呼するお🏡
- 日本人の海外旅行したきのマナーよくなったのはいつから
- へそグリグリ
