Win32API質問箱 Build125

**デフォルトの名無しさん** · 2019/02/27(水) 15:09:08.64

Win32APIについての質問はこちらへどうぞ。

■注意
・質問する前にMSDNライブラリやPlatformSDK、Google等で検索しましょう。
・日本語版MSDN Online Libraryは不完全です。
　英語版( http://msdn.microsoft.com/en-us/library/ )の利用推奨。
・APIフックなど高度な事をしたい場合はできるだけAdvenced Windowsを読みましょう。
・言語特有の問題やIDE、MFCやVCLなどの質問はそれぞれの言語や開発環境スレで

■過去スレ
Win32API質問箱 Build124
http://mevius.5ch.net/test/read.cgi/tech/1510395780/
Win32API質問箱 Build123
http://mevius.2ch.net/test/read.cgi/tech/1475897582/
Win32API質問箱 Build122
http://echo.2ch.net/test/read.cgi/tech/1451988219/
Win32API質問箱 Build121
http://echo.2ch.net/test/read.cgi/tech/1438695290/
Win32API質問箱 Build120
http://echo.2ch.net/test/read.cgi/tech/1428570962/

■関連スレ
Visual Studio 2019
http://mevius.5ch.net/test/read.cgi/tech/1548765663/
Visual Studio 2017 Part6
http://mevius.5ch.net/test/read.cgi/tech/1528645068/
【C++】 DirectX初心者質問ｽﾚ Part41 【C】
http://mevius.5ch.net/test/read.cgi/tech/1521786252/

**デフォルトの名無しさん** · 2019/09/18(水) 14:01:12.80

Caretの点滅間隔について質問です

自アプリがアクティブの時のみ点灯(点滅間隔にUINT_MAXを指定して擬似的に)
自アプリが起動中はWM_SETFOCUSでON(点灯)に、WM_KILLFOCUSでOFF(元の間隔)にする事はできましたし他のアプリにも影響はありません
ですが自アプリが終了したら他のアプリでもONの状態になってしまいます
メッセージを追ってみると
WM_CLOSEでDestroyWindow
→WM_KILLFOCUSでOFFへ
→プロセスが終了
になっていたので自アプリ内で再度ONになっている事はないです

これはどういう事ですか？

**デフォルトの名無しさん** · 2019/09/18(水) 19:04:24.43

WM_CLOSE
→DestroyWindow (hWnd 失効)
→WM_KILLFOCUSでOFFへ (hWnd 違いで無視)
→プロセスが終了

かな
知らんけど

**デフォルトの名無しさん** · 2019/09/18(水) 19:30:38.13

ありがとうございます

引数は間隔のみですが一応DestroyWindow直前でOFFにしてみても同じ結果でした

**デフォルトの名無しさん** · 2019/09/18(水) 19:31:59.76

完成品には道のり遠くｗ

**デフォルトの名無しさん** · 2019/09/18(水) 19:37:10.52

Getで値を見てみるとONの状態になってしまうのではなく
アプリが終了したら間隔が0xfeeefeeeになってしまう
でした

言い直しますと
System設定の500(ミリ秒)からUINT_MAXではなく200へ変更するようにしても
アプリを終了したら間隔が0xfeeefeeeになってしまう
です

**デフォルトの名無しさん** · 2019/09/18(水) 19:39:32.20

たまねぎスレｗ

**デフォルトの名無しさん** · 2019/09/18(水) 19:57:32.75

方法は何でもいいけど、例えばクリックしたらキャレット処理を終了→その後アプリ終了でどうなるかやってみ
問題が絞り込めるでしょ

WM_CLOSEで終了処理が思ったように動いてないってのはありがち

**デフォルトの名無しさん** · 2019/09/18(水) 20:00:53.08

はい完成品なしｗ

**デフォルトの名無しさん** · 2019/09/18(水) 20:07:36.38

>>347
それも既に試しましたが同じ結果です
>>341でも書きましたがメッセージを追ってWM_CLOSEが正常な事も確認済みです

**デフォルトの名無しさん** · 2019/09/18(水) 20:10:21.94

はいBASICからやり直しｗ

**デフォルトの名無しさん** · 2019/09/18(水) 20:10:41.11

>>347
途中送信すみません
設定してもいない値0xfeeefeeeになるので
間隔はSystemと同じ値(500)にSetするだけにしてみても同じ結果でした

**デフォルトの名無しさん** · 2019/09/18(水) 20:12:42.36

0xfeeeってデバッグの時の初期化されてない奴の値じゃないっけ
終了時に数値の参照先おかしくなってるとかかな

**デフォルトの名無しさん** · 2019/09/18(水) 20:31:05.81

「あなたのアプリがWM_CLOSEで0xfeeefeeeにしてる」のは明白でしょ
0xfeeefeeeって特別な値よ、ググってみそ

**蟻人間** ◆T6xkBnTXz7B0 · 2019/09/18(水) 20:50:12.78

DestroyCaretしてないとか？

**デフォルトの名無しさん** · 2019/09/18(水) 20:51:02.69

DEBUGビルドのランタイムで
newからのdelete や malloc からの free の後に　確保領域の内容を0xfeee で埋める

ポインタを開放した後に指し先の内容値を取得し、セットしちゃってるんでないの？

**デフォルトの名無しさん** · 2019/09/18(水) 20:51:25.32

速度設定するとこにトレース出力でもおいて、まずはほんとに意図しないタイミングで呼ばれてないのかチェックだな

**デフォルトの名無しさん** · 2019/09/18(水) 20:54:27.99

イベントを2回通っていて、認識できてないとか。

**デフォルトの名無しさん** · 2019/09/18(水) 21:32:56.42

>>353
キャレット関係の終了処理をWM_LBUTTONDOWNのタイミングに変更した時に
WM_CLOSEの方のキャレット関係の終了処理はコメントアウトしました

>>354
してもしなくても同じ結果になります

>>355
値の指定をハードコードにしても同じでした

>>356-357
重複した呼び出しなども無かったです

**デフォルトの名無しさん** · 2019/09/18(水) 21:52:22.59

Releaseモードで検証したら

**デフォルトの名無しさん** · 2019/09/18(水) 21:58:28.43

別のとこでメモリ壊してるんかな
その部分だけの最小コード書いてみては
それでもなるなら手に負えない感じが

**デフォルトの名無しさん** · 2019/09/18(水) 22:24:23.19

>>352-353, >>355
0xfeee なんてパターンあったっけ？
0xFDFDFDFD No man's land (normally outside of a process)
0xDDDDDDDD Freed memory
0xCDCDCDCD Uninitialized (global)
0xCCCCCCCC Uninitialized locals (on the stack)
の４パターンしか知らんかったわ
https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-6.0/aa260966(v=vs.60)#what-exactly-do-you-mean-by-failure

**デフォルトの名無しさん** · 2019/09/18(水) 22:31:02.62

なかったっけ
うろ覚えで書いたから間違ってたかな

**デフォルトの名無しさん** · 2019/09/18(水) 22:48:37.86

0xfeeefeeeでググれ

**デフォルトの名無しさん** · 2019/09/18(水) 22:51:58.57

>>358
> キャレット関係の終了処理をWM_LBUTTONDOWNのタイミングに変更した時に
> WM_CLOSEの方のキャレット関係の終了処理はコメントアウトしました

マウスクリックで終了してる「はず」なのに終了してないなら、そもそもキャレット処理を
全く走らせてなくても問題が再現する「はず」

でもその場合は問題ないってなら、やはり終了処理に何かある

**デフォルトの名無しさん** · 2019/09/19(木) 04:56:26.34

>>363
お前がググれよw

**デフォルトの名無しさん** · 2019/09/19(木) 08:37:27.80

>>361
new -> delete -> 値が0xfeeefeeeに

もしnewしたクラスのメンバ変数が値を保持して間隔設定してるなら
delete後に0xfeeefeeeなるよ
クラスポインタをdeleteしてからNULLにしたらエラーになるはず

こんな感じじゃないかな

WM_CLOSEで(deleteしてから)DestroyWindow (クラスポインタとメンバ変数の値が0xfeeefeeeに)
→WM_KILLFOCUSでOFFへ (OFFにする時に参照してるメンバ変数が0xfeeefeee)
→プロセスが終了

でもハードコードでもなるみたいだから違うかも？

**デフォルトの名無しさん** · 2019/09/19(木) 09:42:21.55

unix の pipe は双方向だと思うのですが
win32api の pipe (namedpipe ではない方) は一方通行なんでしょうか？
先生なんとかなりませんか？

**デフォルトの名無しさん** · 2019/09/19(木) 09:45:58.80

WM_CLOSE
↓
WM_DESTROY

**デフォルトの名無しさん** · 2019/09/19(木) 09:51:38.16

ああ
WM_QUIT
かな

**デフォルトの名無しさん** · 2019/09/19(木) 10:17:38.29

>>367
UNIXも一方通行では

**デフォルトの名無しさん** · 2019/09/19(木) 10:35:55.09

>>366
間隔設定がよくわからんが

class C { int a; };

auto x = new C();
delete x;

ってやるとxのポイント先が0xddddddddになるんだが…
Visual Studio Express 2017, 15.9.16

**デフォルトの名無しさん** · 2019/09/19(木) 12:34:19.77

>>366
書き忘れたけど当然デバッグビルドな
ついでにライブラリのソース追っかけたけどパターンはバイト単位に設定されてるので0xfeeeなんてパターンは無いと思うよ

**デフォルトの名無しさん** · 2019/09/19(木) 16:05:31.90

>>365
どこのgoogle使ってんの？

＞0xfeeefeee を検索するとHeapFree で処分された後のヒープ領域がこの値で埋められている、とわかる。ということは「処分済みヒープへのポインタを誰かが使っている」ということだ。

なお、正解かどうかは論じてないので悪しからず

**デフォルトの名無しさん** · 2019/09/19(木) 16:41:49.39

解放バッファの埋めパターンは、ライブラリが自力でセットするものなの？

**デフォルトの名無しさん** · 2019/09/19(木) 17:15:02.02

-D_DEBUGで自動化やろ

**デフォルトの名無しさん** · 2019/09/19(木) 18:06:22.20

とりあえず>>373の検証
100バイトHeapAllocして適当にa~zの文字書き込んでHeapFreeの前後でダンプ取ったけど、
0xfeeefeeeが入ることはなかったな

debug版
前
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 00
後
F0 C6 42 05 88 41 47 05 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 00

release版
前
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 00
後
78 EF 81 05 F0 54 79 05 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 00

free後に何か入ってるけど、実行毎に違う値が入ってる

0xfeeefeeeに関しては、単純に何かのAPIがそういう処理してるんでは

**デフォルトの名無しさん** · 2019/09/19(木) 18:13:44.87

コンパイラによっても違うのか
http://www.nobugs.org/developer/win32/debug_crt_heap.html

**デフォルトの名無しさん** · 2019/09/19(木) 18:42:59.80

APIだからコンパイラ関係ないと思うけどね
OSは8.1だけど

コンパイラというかライブラリが関係するはずのmallocでやってみた
vs2017 - ツールセットvs2013（詳細略）
以下並びは>376と同じだけどダンプの長さはa~zの26+1バイトじゃなく30バイト
allocも100ではなく30バイト

debug
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 00 CD CD CD
DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD

release
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 00 00 00 00
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 00 00 00 00

**デフォルトの名無しさん** · 2019/09/19(木) 19:23:51.83

>>371
間隔設定はキャレットのね

こっちでは0xfeeefeeeになるね
https://i.imgur.com/tsMulbt.jpg

**デフォルトの名無しさん** · 2019/09/19(木) 22:12:42.24

>>379
環境は？
十数バイトをdeleteしただけでHeapFreeを呼ぶのも考えづらいし、そもそもこっちでも>>376と同じくHeapFreeで0xfeeefeeeが入ることもなかった

**デフォルトの名無しさん** · 2019/09/19(木) 22:36:38.24

vs2003とかそのあたりかなこれ

**デフォルトの名無しさん** · 2019/09/20(金) 00:25:02.03

Win10 Pro(32bit)でHeapFreeやってみた
VS2017(Community Edition)は0xfeeefeeeにならなかったが、
VC2010(Express Edition)でやってみたら0xfeeefeeeになったわ(確保していた領域の先頭8バイトほどに0xfeeefeeeじゃない値が入っていたが)
面倒だからオプションとか生成されたバイナリとか詳しく比較してない

**デフォルトの名無しさん** · 2019/09/20(金) 09:31:26.82

>>380
VC++2010Expressだよ
画像こっちの方がよかったね
ttps://i.imgur.com/eDh78Kq.jpg

**デフォルトの名無しさん** · 2019/09/28(土) 11:23:33.59

メッセージ処理の
case（msg）
ってなんで
case（msg.message）
じゃないの？
構造体直接評価できるの？

**デフォルトの名無しさん** · 2019/09/28(土) 11:29:50.08

どこかのサイト？

**デフォルトの名無しさん** · 2019/09/28(土) 11:46:59.83

メッセージは構造体じゃなくて UINT やろ

**デフォルトの名無しさん** · 2019/09/28(土) 14:28:14.81

>>384
多分サンプルの読み方を勘違いしている
GetMessage関数なんかで使われるlpMsgとかはMSG構造体なので中でメッセージIDを
確認したいならば「msg.message」を見ることになる
メッセージIDのハンドリング行うサンプルなんかで普通に使われてるWndProc関数の
uMsgはUNIT型の「msg.message」が実体なのでcaseでそのままハンドリングできる
でないか？

**デフォルトの名無しさん** · 2019/09/28(土) 16:13:30.79

caseにカッコつけんな

**デフォルトの名無しさん** · 2019/09/28(土) 17:54:36.06

本来ライブラリに任せるべきところをかなりネイティブなwinsockプログラミングをしています。
TCP通信にて最大セグメントを超えてwinsock2.sendを行った場合はどうなってしまうのでしょうか？
エラーとなるためそこも自前で実装する必要があるのか、それともwinsockが勝手に分割を行ってくれるのか、はたまたネットワークアダプタやルーターなどのデバイスが勝手にやってくれるのか、どういう挙動となるのかご伝授お願いします

**デフォルトの名無しさん** · 2019/09/28(土) 20:46:23.20

ソケット通信てそんなところ気にしなきゃいけなかったっけ？
アップロード・ダウンロードルーチン組んだけど記憶にない

**デフォルトの名無しさん** · 2019/09/28(土) 21:19:08.01

winsock2に限ればエラーが返るんじゃないか？
質問するよりもmasdn見たほうが確実だろ

**デフォルトの名無しさん** · 2019/09/28(土) 21:42:01.62

sizeof演算子に括弧つける派です？

**デフォルトの名無しさん** · 2019/09/28(土) 22:22:37.56

UDPだと知らん間に分割された挙句
場合によっては断片が届く順番まで変わるからな

**デフォルトの名無しさん** · 2019/09/28(土) 22:24:29.26

sizeofに括弧付ける
マクロの引数は使用時に必ず括弧付ける

**デフォルトの名無しさん** · 2019/09/29(日) 08:10:25.37

>>393
> 場合によっては断片が届く順番まで変わるからな
むしろTCPが頑張って順序を元通りに入れ替えてるんだが…

**デフォルトの名無しさん** · 2019/09/29(日) 08:12:55.60

>>392
不要なカッコは付けない派
例外は演算子の優先順位がわかりにくい時に付けるぐらい
理由は間違っててもコンパイルエラーにならないから

**デフォルトの名無しさん** · 2019/09/29(日) 08:26:06.28

>>392
俺も無駄な括弧はつけないな
わざわざつける理由がない

単項演算子の優先順位を知らんアホが仲間にいない

**デフォルトの名無しさん** · 2019/09/29(日) 09:39:48.44

どこから「単項」演算子の話が…

**デフォルトの名無しさん** · 2019/09/29(日) 10:26:13.14

そのアホがいた・・・驚愕
今 sizeof の話をしているんだが
脈絡が読めないとはな

**デフォルトの名無しさん** · 2019/09/29(日) 10:29:45.89

こういう奴が書くソースは総じて読みにくいｗ

**デフォルトの名無しさん** · 2019/09/29(日) 10:31:48.98

付ける派
if(...) switch(...)なのにsizeof(...)じゃないのはなんとなく嫌

**デフォルトの名無しさん** · 2019/09/29(日) 11:39:16.24

どこがAPIの話だ馬鹿は京急に突っ込んで死ね

**デフォルトの名無しさん** · 2019/09/29(日) 11:53:45.41

hoge = malloc(length * sizeof struct hage *);
hoge = malloc(sizeof struct hage * * length);
hoge = malloc(*length * sizeof struct hage *);
hoge = malloc(sizeof struct hage * * *length);
hoge = malloc(*length * sizeof struct hage **);
hoge = malloc(sizeof struct hage ** * *length);
()付けないとどんどんわかりにくくなっていく

**デフォルトの名無しさん** · 2019/09/29(日) 13:23:57.04

sizeof(型)は()必要だよ

**デフォルトの名無しさん** · 2019/09/29(日) 13:34:02.17

いらんよ

**デフォルトの名無しさん** · 2019/09/29(日) 13:50:41.73

Win32API以外の話は不要

**デフォルトの名無しさん** · 2019/09/29(日) 13:54:31.01

>>400
おまえみたいのに読んでもらう必要が皆無

**デフォルトの名無しさん** · 2019/09/29(日) 13:59:56.96

単項演算子とそうでないものの区別がつかないアホが
return にも括弧したがるんだろうな

# K&R 1st世代の人はともかく

**デフォルトの名無しさん** · 2019/09/29(日) 14:05:22.62

書いてから思ったが、排他の否定な書き方が好きじゃない>>406
読みにくい
肯定した書き方だけに統一したい
そういう意味では、好きじゃないという書き方もダメか
嫌いと書くべきか

ということで、
Win32APIの話をしろ

おやすみ

sizeofは計算式絡むことがほとんどなのと、明示的にした方が分かりやすく
馬鹿らしいミスの回避のためにも付けといて損はない

**デフォルトの名無しさん** · 2019/09/29(日) 15:27:53.48

自分らしいミスか、わかりますｗ

**デフォルトの名無しさん** · 2019/09/29(日) 15:43:36.72

>>403
この例からしても括弧つけた方が見やすいが、ID:MP9GBJ11は見やすさ全否定なの？
俺様はインデントもスペースも改行も無くても、優先順位・スコープ範囲が分かってるから無問題って理屈だよな

**デフォルトの名無しさん** · 2019/09/29(日) 15:50:52.56

typeidもsizeofも関数じゃなくて演算子なんだけど、typeidは括弧が必須。

**デフォルトの名無しさん** · 2019/09/29(日) 16:01:08.70

>>389
TCPのMSSは相手との関係で決まるので何バイト送り込んでもエラーには
ならないと思うけど
TCPとしては送れたデータ量をSeq番号で管理していてセグメントの分割は
ドライバの仕事なのでアプリケーションレベルでは意識する必要なかったと
思うけど
UDPとかIP直みたいなデータグラムの場合には「WSAEMSGSIZE」が返って
くるみたいだけどTCPは平気なんじゃないかな(転送データの保障がある
わけではない)

**デフォルトの名無しさん** · 2019/09/29(日) 17:35:14.18

さすがに return にまで () 付けてるのはうざいわ

**デフォルトの名無しさん** · 2019/09/29(日) 17:44:23.38

>>411
仲間に書かれても文句は言わねえな
見た目の問題じゃなく、やろうとしている内容がセンスに欠けるときなら
これ例えばこんな手もあるよなと議論に誘ったりはするし
iocccみたいな実験をTPOを間違えてやる大馬鹿野郎がいたら喧嘩売る
実例として/*/野郎は口汚く罵ってやった

**デフォルトの名無しさん** · 2019/09/29(日) 17:51:28.09

（）なんてあってもなくても分かりやすけりゃいいんだよ
逆に>>403なんて（）あってもなくても読みにくい。俺はこんなの絶対書かないな

**デフォルトの名無しさん** · 2019/09/29(日) 18:02:50.86

sizeof には、極力変数名側を与えるようにして型名は避けるようにしてるけど
WinAPI とは遠い話だな

**デフォルトの名無しさん** · 2019/09/29(日) 18:08:58.10

もうダメ、我慢できないから言っちまおう
>>403は必要な()とそうでないのが解ってねえ
アホｗバカｗｗｗ

**デフォルトの名無しさん** · 2019/09/29(日) 18:09:40.55

return (a);
とは書かないけど、
return (a+1);
のときは括弧を付けなくなる

**デフォルトの名無しさん** · 2019/09/29(日) 18:44:22.03

GCCではtemplate関数の記述する際に、ある文字列が型であることをコンパイラに教えるtypenameキーワードが必要なので、sizeof に括弧がないと読みづらくなる傾向はある。

**デフォルトの名無しさん** · 2019/09/29(日) 21:35:11.45

>>420
バーカｗｗｗｗｗｗｗｗｗｗ
typenameが必要か否かは規格17.7で明確化されている

**デフォルトの名無しさん** · 2019/09/29(日) 22:11:20.40

>>415
規約や仕様の話じゃなくて見た目の話してるんだから、それを分かっててセンスがどうのこうのって言い出すのなら
この話の流れで草を生やしながら馬鹿まき散らすのは、マジでセンスないねって話になるよ

**デフォルトの名無しさん** · 2019/09/29(日) 22:29:52.99

おはようさん

スレタイ読めない奴は総じてセンスも才能もないってことですよ

**デフォルトの名無しさん** · 2019/09/29(日) 22:52:38.22

>>387
ありがとうございました

**デフォルトの名無しさん** · 2019/09/30(月) 08:14:44.84

>>422
やろうとしている内容がセンスに欠けているときって言ってるのに規格がどうたらとか、いいからまず涙拭けよw

**デフォルトの名無しさん** · 2019/09/30(月) 08:23:22.14

もう少しwindowsに関係した話をだな

**デフォルトの名無しさん** · 2019/09/30(月) 09:28:52.10

ガイジの出身地方ではWin32APIの範囲なんだろ

**デフォルトの名無しさん** · 2019/09/30(月) 12:38:46.03

Win32APIがsizeof()推奨なのは
hoge * で済むものをわざわざ
typedef hoge *LPHOGE;
とかやっちゃって
sizeof LPHOGE
とかやって
不都合出て来るからだろ

**デフォルトの名無しさん** · 2019/10/01(火) 20:49:26.16

Win32 APIはバージョン差を吸収するのにパラメータ構造体にその大きさをセットするので
わりかし sizeof の頻度は高いかもな

**デフォルトの名無しさん** · 2019/10/01(火) 21:01:09.96

流れを読まず適当にレスすると
win32apiプログラミングにおけるapiの仕様やsizeofの使用頻度を考えたら括弧付きが自然なのは周知の事実なんだから
それにセンスが何ちゃらと難癖付けてるのはwin32apiプログラミングしてないアホでしょ
こんなん出ました

**デフォルトの名無しさん** · 2019/10/01(火) 22:45:12.05

カッコつけてんじゃねーよ的なやつな

**デフォルトの名無しさん** · 2019/10/01(火) 22:51:24.51

チコちゃんもといカコちゃんみたいな

**デフォルトの名無しさん** · 2019/10/02(水) 06:50:57.68

> win32apiプログラミングにおけるapiの仕様やsizeofの使用頻度を考えたら括弧付きが自然なのは周知の事実なんだから
理由もメチャクチャだし周知とかアホすぎる

> それにセンスが何ちゃらと難癖付けてるのはwin32apiプログラミングしてないアホでしょ
>>430出ましたw

**デフォルトの名無しさん** · 2019/10/02(水) 10:31:29.32

スレタイ読まないカコちゃんまた来たの？頭弱いね

**デフォルトの名無しさん** · 2019/10/02(水) 11:02:31.08

sizeofに括弧つけるかどうかなんて
正直どうでも良くね？

**デフォルトの名無しさん** · 2019/10/02(水) 11:33:56.30

構造体にサイズ入れることが一番多いからあんまつけないな

**デフォルトの名無しさん** · 2019/10/02(水) 13:04:47.75

64bit化してからHOGE_PTRが増えてさらに混乱

**デフォルトの名無しさん** · 2019/10/07(月) 18:52:52.31

sizeof付けるの嫌ならラッパー作ってそっちで呼び出せよ
win32APIの仕様がそーなるんだからしかたねーじゃん。手続き通りに記述するしかない。

**デフォルトの名無しさん** · 2019/10/07(月) 20:15:04.08

perlでWin32APIを使うライブラリWin32::APIを使ってると、
32bitと64bitで異なる構造体のアラインメントを正しく解釈してくれないので、アセンブラ並みに低レベルな記述が必要になることがある。

**デフォルトの名無しさん** · 2019/10/07(月) 21:01:12.36

cからperl呼ぶのも腐ってるな

**デフォルトの名無しさん** · 2019/10/07(月) 22:23:56.51

>>440
世の中には発酵食品が沢山ある。
発酵腐敗熟成の違いを見極めるのは難しい。