Win32API質問箱 Build126

**デフォルトの名無しさん** · 2020/05/01(金) 22:16:51.96

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

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

■過去スレ
Win32API質問箱 Build125
https://mevius.5ch.net/test/read.cgi/tech/1551247748/
Win32API質問箱 Build124
https://mevius.5ch.net/test/read.cgi/tech/1510395780/

■関連スレ
Visual Studio 2019 Part4 https://mevius.5ch.net/test/read.cgi/tech/1585715794/
Visual Studio 2017 Part7 https://mevius.5ch.net/test/read.cgi/tech/1558179898/
【C++】 DirectX初心者質問ｽﾚ Part41 【C】 https://mevius.5ch.net/test/read.cgi/tech/1521786252/

**デフォルトの名無しさん** · 2021/08/25(水) 20:26:18.34

>>75
されるわけないだろ
OSがナイナイしてくれるだけ

**デフォルトの名無しさん** · 2021/08/25(水) 21:58:54.28

>>751
プロセスごと始末してくれるから放置で構わん

**デフォルトの名無しさん** · 2021/08/26(木) 05:00:21.78

変な日本語・・・

**デフォルトの名無しさん** · 2021/08/26(木) 16:28:52.50

こっちくんな

**デフォルトの名無しさん** · 2021/08/26(木) 17:50:13.63

やって来ました
メッセージボックスで「計算結果はXX」って表示したくて

1 LPCWSTR func() {LPCWSTR a = L"//計算結果の値"; return a;} //計算結果を文字列にして返す関数
2 //以下WinMain()内
3 LPCWSTR a = L"計算結果は";
4 LPCWSTR b = func();
5 LPCWSTR c = 文字列を連結する関数(a, b); //StringCchCatW(), lstrcatW()などを試したがだめだった
6 MessageBoxW(hWnd, c, L"タイトルバー", MB_OK);

と書いたが動かなかった・・・
まず、1行目の「L"//計算結果の値"」に計算結果の変数を入れる方法がわからない
そして、5行目のLPCWSTR型の文字列を連結する方法がわからなからない
一日の大半がエラーとのにらめっこに費やされて辛い・・・
頼む、手伝ってくれさい

**デフォルトの名無しさん** · 2021/08/26(木) 17:58:52.10

宿題スレ案件ですか？

**デフォルトの名無しさん** · 2021/08/26(木) 18:24:36.40

>>757
いや普通にニート

**デフォルトの名無しさん** · 2021/08/26(木) 18:27:20.48

>>756
Win32APIではなくC言語の文字列とポインタの違いを勉強するところからやり直し

**デフォルトの名無しさん** · 2021/08/26(木) 18:29:12.42

wsprintf

**デフォルトの名無しさん** · 2021/08/26(木) 19:08:13.70

ニートならできないことは諦めればいいんじゃね？

**デフォルトの名無しさん** · 2021/08/26(木) 19:18:34.62

>>756

1 void func(CString &str) { str = "計算結果の値" } //計算結果を参照型引数の str に返す関数
2 //以下WinMain()内
3 CString str1 = "計算結果は";
4 CString strKekka;
5 func( strKekka );　// strKekka に計算結果の文字列が入って返って来る。
6 CString str2 = str1 + strKekka;
7 str2 を wide 文字列に直して、wpszText に入れる。 // ここはやり方を調べる。
8 MessageBoxW(hWnd, wpszText, L"タイトルバー", MB_OK);

**デフォルトの名無しさん** · 2021/08/26(木) 19:19:53.55

>>756
自分がどう書いたのかソースそのまま出して

**デフォルトの名無しさん** · 2021/08/26(木) 19:21:59.37

普通にwstringベースで作れ。
win32のwchar_t*型渡すところで、data()やc_str()使え。

std::to_wstring で数値などなどメジャーな数値型はwstringになる。

最初はwin32の型に代替名つけまくりな文化は
一体なんの型だよって感じで戸惑うわな。

**デフォルトの名無しさん** · 2021/08/26(木) 19:22:39.20

>>762
以下の関数を使えば、7 は、
wchar_t *wpszText = ConvertAcpMbcsToUtf16(str2);
でいける。

wchar_t *ConvertAcpMbcsToUtf16( const char *pszStr )
{
　　// ワイド文字列(UTF16, unicode) へ変換後の文字列長を得る
　　int　　　　　　lenUnicode　　= MultiByteToWideChar( CP_THREAD_ACP, 0, pszStr, -1, NULL, 0 );
　　
　　// 必要な分だけワイド文字列(UTF16, unicode) のバッファを確保
　　wchar_t　　　　*pbufUnicode　　　　= new wchar_t [lenUnicode];
　　if ( pbufUnicode == NULL ) {
　　　　return　　NULL;
　　}
　　
　　// デフォルトコードページ(ShiftJISなど) からワイド文字列(UTF16, unicode) へ変換する :
　　MultiByteToWideChar( CP_THREAD_ACP, 0, pszStr, -1, pbufUnicode, lenUnicode );
　　
　　return　　pbufUnicode;

**デフォルトの名無しさん** · 2021/08/26(木) 19:24:55.54

>>765
訂正:
1. は代入文の最後にセミコロンが抜けていたので正しくはこう :
void func(CString &str) { str = "計算結果の値"; }

**デフォルトの名無しさん** · 2021/08/26(木) 19:30:35.44

おっと、最後、MessageBoxW ではなく、MessageBoxA を使っていれば、
7や >>765 の工程は不要で、
MessageBoxA(hWnd, str2, "タイトルバー", MB_OK);
だけでいける。

**デフォルトの名無しさん** · 2021/08/26(木) 19:32:37.80

なのでまとめると以下のようになる :

void func(CString &str) { str = "計算結果の値"; }

// 以下WinMain()内
CString strKekka;
func( strKekka );　// strKekka に計算結果の文字列が入って返って来る。
CString str2 = CString("計算結果は") + strKekka;
MessageBoxA(hWnd, str2, "タイトルバー", MB_OK);

**デフォルトの名無しさん** · 2021/08/26(木) 22:24:23.76

連結はstrcatかsprintf("%s%s", s1, s2 )のTCHAR(wchar_t)版でいけるやろ
あとLPCWSTRはポインタなので、ちゃんと割り当てしてなくて未初期化のままとかないだろうな？

**蟻人間** ◆T6xkBnTXz7B0 · 2021/08/27(金) 02:18:22.79

LPCWSTRのCはCONST(定数)という意味だから、変更できない。WはWide、つまりUTF-16.
Win32をやる前にC言語の文字列処理をマスターしてくれ。
wsprintfは時代遅れ。バッファオーバーフローを避けるため、バッファサイズ指定できる<strsafe.h>のStringCch...関数群を推奨。

**蟻人間** ◆T6xkBnTXz7B0 · 2021/08/27(金) 02:34:26.66

ポインタ変数は実体を持たない。文字列扱うにはバッファが必要。動的にバッファを確保して楽したいなら、標準C++のstd::wstringか、MFC/WTLのCStringWを使う。
ただし、std::wstringを使う場合でC文字列が欲しい場合はc_str()メソッドを使う必要がある。下手な型キャストはケガのもと。

**デフォルトの名無しさん** · 2021/08/27(金) 07:26:15.44

WindowsでC/C++を学ぼうとすると、文字列の扱いは混乱するだろうね
OSを特定しない教科書に載ってるようなやり方もできるから心配するな
一応の結果の表示をできるようになったら、とりあえずその方法だけ使って次に進んで、一通り理解したらまた文字列処理に戻ってくるといいんじゃないかな

**デフォルトの名無しさん** · 2021/08/27(金) 07:43:07.26

ぎゃー
教えてくれたのに遅れてすまん
今からエディター起動する

**デフォルトの名無しさん** · 2021/08/27(金) 08:37:51.16

スレタイ読もうな？

**デフォルトの名無しさん** · 2021/08/27(金) 10:35:04.22

>>770-771
この段階の人には情報過多

**デフォルトの名無しさん** · 2021/08/27(金) 10:43:55.91

C言語の基礎からやり直せ、と助言するのが正しい

**デフォルトの名無しさん** · 2021/08/27(金) 11:25:56.35

付き合ってくれた人が多くて感謝！
上のコードで実験しながら知識の掘り下げも含めて少し調べてみる
ありがとうな
いつか立派なプログラマーになってこのスレで恩返しするわ（泣ける）

>>774
文字列の扱いがここまで面倒だとは思ってなかった
Windows APIの関数に適当に投げ込むだけだと思ってた

>>776
入門書は読んだだけで実作は先週始めた
（これ以上は理解が進まないので実作をすることにした）
まだ知識が実践で使えるように修正されてない状態
まあ知識もないんだが

**デフォルトの名無しさん** · 2021/08/27(金) 11:59:25.59

お前には完成する能力は無い

**デフォルトの名無しさん** · 2021/08/27(金) 12:35:37.97

先が思いやられるな
特にWin32APIにこだわる理由が無いならC#でやることをおすすめする

**デフォルトの名無しさん** · 2021/08/27(金) 18:42:32.62

特殊な理由でもない限りネイティブc/c++なんて使わんでいいよ

**デフォルトの名無しさん** · 2021/08/27(金) 19:44:48.26

Cだと、こんな感じかな
- - - - - - - - - - - - - - - -
LPCTSTR a;
int b;
TCHAR c[20];

a = TEXT("計算結果は");
b = 2;
wsprintf(c, TEXT("%s%d"), a,b);
MessageBox(NULL, c, TEXT("タイトルバー"), MB_OK);

**デフォルトの名無しさん** · 2021/08/27(金) 20:04:56.02

今でもTEXT()って要るの？

**デフォルトの名無しさん** · 2021/08/27(金) 20:22:50.96

なんでせっかくTCHAR使っててwsprintfやねん

**デフォルトの名無しさん** · 2021/08/27(金) 20:24:35.54

MBCSかUNICODE決め打ちならいらない
LPCTSTR,TCHARも同じ

**デフォルトの名無しさん** · 2021/08/27(金) 20:35:07.25

>>783
#ifdef UNICODE
#define wsprintf wsprintfW
#else
#define wsprintf wsprintfA

**デフォルトの名無しさん** · 2021/08/27(金) 20:36:31.85

>>783
wsprintfはTCHARでは

**デフォルトの名無しさん** · 2021/08/27(金) 20:36:59.87

>>785
つ >>760

**デフォルトの名無しさん** · 2021/08/27(金) 20:42:31.64

**蟻人間** ◆T6xkBnTXz7B0 · 2021/08/27(金) 20:45:13.11

sprintf/swprintfはC標準。
wsprintfはWin32。
これはテストに出ないぞ！

**デフォルトの名無しさん** · 2021/08/27(金) 20:48:57.74

>>789
Win32apiのスレなので、それ以外の答えを
書いた奴全員アウトあるね

**デフォルトの名無しさん** · 2021/08/27(金) 22:20:01.88

>>786
TCHARはワイドとマルチバイトの両方なんだからwprintf決め打ちじゃなくて_tprintf

**デフォルトの名無しさん** · 2021/08/27(金) 22:35:10.18

>>791
wsprintfはTCHARでは

**デフォルトの名無しさん** · 2021/08/27(金) 22:53:41.84

>>782
これからWin32APIを理解し始めようと考えている人には、そうゆう疑問を持てるレベルにまで頑張って到達してほしいな、という思いでマクロ表記にしてみたよ。
実用上、必要か不要か・・・で言えば場合によるんだろうけど。
現時点でWin32API が内部で ANSI と UNICODE を明確に区別しているので、作法として気にする必要はあると思われます

**デフォルトの名無しさん** · 2021/08/27(金) 23:06:30.48

>>792
なんでだよｗ
wprintfはWCHAR

**蟻人間** ◆T6xkBnTXz7B0 · 2021/08/27(金) 23:07:19.75

_T系の関数マクロは<tchar.h>で定義されていて、主にC実行時関数を振り分ける。これらはAnsi/Wideを振り分けるTEXT系とは別に分離された機構になっている。

**蟻人間** ◆T6xkBnTXz7B0 · 2021/08/27(金) 23:09:32.07

>>794
wprintfはC標準のワイド関数。
wsprintfはWin32関数でA/W版がある。
一文字違いに注意。

**蟻人間** ◆T6xkBnTXz7B0 · 2021/08/27(金) 23:18:41.05

UNICODEマクロでA/Wの振り分け。
頭に下線のついた_UNICODEマクロで_T系の振り分けができる。
これらはVisual Studioで適切にソリューション/プロジェクトの設定を行えば自動で定義される。
GCCやclangでは-municode をコンパイルオプションに追加する。

ただし、ユニコードプロジェクトではWinMainはwWinMainに切り替わるので注意しよう。

**蟻人間** ◆T6xkBnTXz7B0 · 2021/08/27(金) 23:22:46.33

ユニコードプロジェクトにせず、代わりにUNCODEマクロと_UNCODEマクロを定義済みにするというやり方もある。こちらはCMakeでよく使う。

**蟻人間** ◆T6xkBnTXz7B0 · 2021/08/27(金) 23:25:34.94

ユニコードプロジェクトではないときにUnicode のコマンドラインを取得したい場合は、GetCommandLineWと
CommandLineToArgvWと
LocalFree を使う。

**蟻人間** ◆T6xkBnTXz7B0 · 2021/08/27(金) 23:32:23.92

ミッキマウスミッキマウスミッキミッキマウス
天安門事件
旭日旗☀

**デフォルトの名無しさん** · 2021/08/28(土) 06:56:04.31

,>>798
まぁ今となってはWindowsのUTF16LEはUNCO(ウンコ)なコードだったな
2バイト固定で1文字ってのは、簡易な多言語対応とstrlen系の文字数計算に楽だったんだろうけどそれだけだろ

**デフォルトの名無しさん** · 2021/08/28(土) 08:30:55.56

サロゲートペアに対応したので、その文字数計算も単純にできなくなってしまった。
文字数計算がややこしいのはUTF-8もそうなので、UTF16～が全然ダメということではないが。

開発面では、将来的に UTF-16（IVS）が必要になってくると、UTF8でいいじゃん、ということになって。
Visual stduio のデフォルトが再度ANSI（UTF-8）に戻る可能性はある。
長い目でWin32APIを見るなら、ANSIアプリの構築方法も忘れないでおく必要はありそうだ

**デフォルトの名無しさん** · 2021/08/28(土) 09:06:21.83

アラビア語かなんか知らんが、サロゲートペアの問題ではなく、さらに
UTF32 では 2 文字(32BIT x 2) なのに、画面上では文字の上や下に斜線
が入るような文字がある。日本語の濁点のようなもの。サに点々を打ってザ
と書くようなのを、サ + ” みたいな二文字で表現するらしい。
そんなものまで日本人が対応しなくて良いと個人的には思ってる。

**デフォルトの名無しさん** · 2021/08/28(土) 09:09:13.47

UTF8 --> UTF16(サロゲートペア) --> UTF32 1 文字
の問題だけでなく、特殊な言語では、
UTF8 --> UTF32 2文字 --> 画面上では 1 文字
の問題が有るということ。
日本人が対応できるのは、UTF32 1文字が画面上で1文字に見えるまでが限界。

**デフォルトの名無しさん** · 2021/08/28(土) 09:33:08.48

KPS 9566-2000にはフル対応しる

**デフォルトの名無しさん** · 2021/08/28(土) 09:53:59.20

>>803
> サ + ” みたいな二文字で表現するらしい
Macってこれだよね
UTF-8-MACくたばれ

**デフォルトの名無しさん** · 2021/08/28(土) 10:02:21.59

>>779
C#だっておバンバン

**デフォルトの名無しさん** · 2021/08/28(土) 10:50:07.25

>>794
勘違いしましたごめんなさいは？ｗ

**デフォルトの名無しさん** · 2021/08/28(土) 12:21:19.46

>>803
>そんなものまで日本人が対応しなくて良いと個人的には思ってる。
欠けリンゴの世界ではそっち採用してるからファイル名の扱いとか厄介だよ

**デフォルトの名無しさん** · 2021/08/28(土) 13:14:56.03

>>801
MBCSのsjisとeucに戻りたいかというと、嫌かな(´・ω・`)
今の敵は絵文字

**デフォルトの名無しさん** · 2021/08/28(土) 13:29:17.35

中東とアメリカは中が悪いから、わざと変な文字コードにしたのかも知れんな。
経済的な敵である日本を倒すため、オートリピートなんてそもそも不要なIMEのON/OFF
キーに普通のアルファベットキーよりも開始時間の短いオートリピート機能を付けた
上に、現在のON/OFF状態を画面の右下の分かりにくい場所に小さく表示したりとか
と同じで。

**ハノン** ◆QZaw55cn4c · 2021/08/28(土) 14:51:45.63

>>811
政治の世界と商売の世界は違いますよ、商売のためならなんでもするのが商売人というやつですよ

**デフォルトの名無しさん** · 2021/08/28(土) 15:17:42.31

そして悪徳へ

**デフォルトの名無しさん** · 2021/08/28(土) 17:32:49.86

>>794
スレタイ３回音読してからごめんなさいは？

**ハノン** ◆QZaw55cn4c · 2021/08/28(土) 18:09:30.98

ワンワンワンごめんなさい

**デフォルトの名無しさん** · 2021/08/29(日) 01:17:36.66

どうでもいいけどオリパラのRPCはリモートプロシージャコールじゃなくてなんちゃってロシア
まめな

**デフォルトの名無しさん** · 2021/09/06(月) 20:30:01.34

ﾌﾌﾌﾌﾌ…で埋められたWin32アプリデバッグメモリを思い出した人、どのくらいいるかな

「フフフ…」4歳娘が撮影した花火に家族で爆笑! 見ると笑顔になる“奇跡の1枚”の状況を父親に聞いた | FNNプライムオンライン
https://www.fnn.jp/articles/-/224754

**デフォルトの名無しさん** · 2021/09/06(月) 20:54:15.47

0xABADBABE がwindows7のUSB
0xBAADF00D がlocal alloc

深淵に到達するとﾌﾌﾌじゃないのよ

**デフォルトの名無しさん** · 2021/09/09(木) 19:55:16.63

ｶｶｶ

**デフォルトの名無しさん** · 2021/09/10(金) 06:52:10.21

六歌仙のひとり

**デフォルトの名無しさん** · 2021/09/10(金) 11:54:52.84

Debugモードで実行すると配列の中身が「ﾌﾌﾌﾉﾌﾌﾌ」になってワロタ

**デフォルトの名無しさん** · 2021/09/10(金) 11:56:22.34

16進数で表示して英語で読んでみ

**デフォルトの名無しさん** · 2021/09/11(土) 21:33:34.97

INT3

**デフォルトの名無しさん** · 2021/09/11(土) 23:15:17.42

dabadabada

**デフォルトの名無しさん** · 2021/09/15(水) 09:50:59.74

HANDLE SetClipboardData(UINT uFormat, HANDLE hMem);
に渡すhMemは必ずGlobalAllocで確保したものでなくてはいけないのでしょうか？

mallocやnewやスタック領域のポインタを渡すとどうなるんでしょうか・・・？

**デフォルトの名無しさん** · 2021/09/15(水) 12:24:45.10

>>825
渡すのはポインタではなくハンドルやぞ

**デフォルトの名無しさん** · 2021/09/15(水) 12:43:50.08

>>825
クリップボードはOS単位
スタックはプロセス単位

**デフォルトの名無しさん** · 2021/09/15(水) 12:49:21.43

>>827
スタックはスレッド単位あるね

**デフォルトの名無しさん** · 2021/09/15(水) 12:51:46.74

>>828
あぁプロセスを跨がないって言った方がよかったな

**デフォルトの名無しさん** · 2021/09/15(水) 13:39:40.30

>>826
確かにデータへのポインタであれば長さも渡す必要があるはずですし型名からしても説明からしても明らかに仰る通りでした

>>827
GlobalAllocもあくまでプロセス単位であって、GlobalAllocに書き込んだデータをOSに教える　→　SetClipboardDataでOS管理化のバッファに渡される（CloseClipboardするまでフラッシュはされない？）
という原理であるはずなので、hMemはスタックやmallocでも良いのでは？と思った次第です
しかしながら単純なデータへのポイントではないという事で納得しました

**デフォルトの名無しさん** · 2021/09/15(水) 14:21:18.54

>>830
GlobalAllocと言っても引数に渡すオプションで変わるぞ
GMEM_FIXEDを渡せばプロセス単位でアクセス可能なメモリ（プロセスを超えてアクセスはできない）
GMEM_MOVEABLEを渡すとプロセスを超えて使用できるハンドルが返る
この時点でプロセスのメモリ領域はまだ確保されていない
その後GlobalLockによってプロセスのメモリ空間にマップされる

＞SetClipboardDataでOS管理化のバッファに渡される
SetClipboardDataに渡すのはハンドルであってメモリじゃない
言い換えると、システム（クリップボード）は渡されたハンドルの複製を作ってそれを保持するだけ
ハンドルが示すリソースには参照カウンタがあって、すべてのハンドルが閉じて初めて解放される
つまりGlobalAlloc、GlobalFreeでプロセスがハンドルを閉じても、クリップボードに渡されたハンドルが生きているからデータを維持し続ける
新たにクリップボードにコピーや切り取りをするとそれまでの複製されたハンドルを閉じるので参照カウンタが0になり実際に開放されることになる

＞（CloseClipboardするまでフラッシュはされない？）
GlobalUnockをした時点で書き込まれたデータはハンドルさえ知っていれば誰でもアクセスできる状況にある
言い換えると「フラッシュされるタイミング」はGlobalUnockしたときと言えるだろう
ただしCloseClipboardすることで「ハンドルの複製」が確実に行われるということではある
プロセスはCloseClipboardを呼び出す前に渡したハンドルの開放を行うべきではないと書かれている
（これはシステムがハンドルの複製する前にプロセスが元のハンドルを解放して参照カウンタが0になってしまいデータそのものが解放されるのを防ぐためだろう）

**デフォルトの名無しさん** · 2021/09/15(水) 14:22:39.60

訂正

×　つまりGlobalAlloc、GlobalFreeでプロセスがハンドルを閉じても、
〇　つまりGlobalFreeでプロセスがハンドルを閉じても、

**デフォルトの名無しさん** · 2021/09/15(水) 14:54:01.66

クリップボードを使うときGlobalAllocで割り当てたメモリは解放しなくていいって聞くけど
クリップボードを経由せずにHGLOBAL値を他のプロセスに渡してもGlobalLockでアクセスできないよな
ということはクリップボードもメモリオブジェクトそのものをムーブしているのではなく実はコピーしてるだけ？
だったら貼り付けた側でもGlobalFreeすべきなのかな

**デフォルトの名無しさん** · 2021/09/15(水) 14:55:37.48

>>833
＞クリップボードを経由せずにHGLOBAL値を他のプロセスに渡してもGlobalLockでアクセスできないよな
あれできなかったっけ？

**デフォルトの名無しさん** · 2021/09/15(水) 15:21:21.14

さっきやってみたらできなかった
実験のやり方がまずいのかな

**デフォルトの名無しさん** · 2021/09/15(水) 15:22:27.17

FileMappingより簡単な方法があるのかと期待したんだけど

**デフォルトの名無しさん** · 2021/09/15(水) 15:32:27.38

win16apiと混ざってないか？

**デフォルトの名無しさん** · 2021/09/15(水) 15:33:50.71

32だとGlobalFreeすべきってなってる？

**デフォルトの名無しさん** · 2021/09/15(水) 15:39:39.86

>>833
GlobalAllocしたプロセスを閉じた後もちゃんとクリップボード内のデータは残るのと
SetClipboardData → CloseClipboard → GlobalFreeという非公式な手順でFreeをした後もちゃんとクリップボード内のデータは残るため、あくまで実データはOS側へコピーされているという認識でした

メモリビューアで眺めた感じだと成功した後にGlobalFreeを行わなくても、
GlobalAlloc(GMEM_MOVEABLE, size)の戻り値->、GlobalLockの戻り値->共に該当アドレスへ別データ上書きは確認されたので、ちゃんと解放されているものと思われます

**デフォルトの名無しさん** · 2021/09/15(水) 15:45:35.08

https://docs.microsoft.com/ja-jp/windows/win32/api/winuser/nf-winuser-setclipboarddata
> The application may not write to or free the data once ownership has been transferred to the system
ないね

**デフォルトの名無しさん** · 2021/09/15(水) 15:46:32.86

SetClipboardData　の第一引数は　CF_PRIVATEFIRST + 定数だったりするのかな

**デフォルトの名無しさん** · 2021/09/15(水) 15:46:35.24

なるほど
クリップボードがメモリオブジェクトをGlobalFreeしているので
アプリ側でGlobalFreeすると二重解放になるのは
ムーブかコピーかによらないってことか

**デフォルトの名無しさん** · 2021/09/15(水) 15:56:39.26

「メモリ割り当て方法の比較」という
MicroSoftの資料を一読したら？

GlobalAlloc はHeapAllocのラッパ

**デフォルトの名無しさん** · 2021/09/15(水) 16:10:58.96

ヒップホップ

**デフォルトの名無しさん** · 2021/09/15(水) 23:17:32.21

Win16の頃のドキドキひやひや感が無くなったよな

**デフォルトの名無しさん** · 2021/09/16(木) 02:35:41.36

せやな

**833** · 2021/09/16(木) 07:33:53.55

礼を言ってなかった
みんな、ありがとう

**デフォルトの名無しさん** · 2021/09/18(土) 08:35:19.11

https://mevius.5ch.net/test/read.cgi/tech/1553075856/
>>743-744
最近は LLVM が API 出力してんのか

**デフォルトの名無しさん** · 2021/09/18(土) 21:23:52.02

**デフォルトの名無しさん** · 2021/09/18(土) 21:25:09.62

**デフォルトの名無しさん** · 2021/09/20(月) 12:21:13.96

馬鹿はこっち来んな