如何处理Windows消息中动态分配数据的生命周期？
简单的任务：发送带有动态分配数据的Windows 消息，例如任意长度的字符串。您将如何承担释放这些数据的责任？
Windows 消息的接收者可能负责释放该数据。但是：如何保证所有消息都会被实际接收，从而释放链接的数据？想象一下接收者正在关闭的情况，因此它将不再处理其消息队列。但是，消息队列仍然存在（一段时间）并且仍然可以接受消息，这些消息将不再被处理。
谢谢！
Simple task: Send a windows message with dynamically allocated data, e.g. an arbitrary length string. How would you manage the responsibility to free this data?
The receiver(s) of the windows message could be responsible to free this data. But: How can you guarantee that all messages will actually be received and thus the linked data will be freed? Imagine the situation that the receiver is shutting down, so it won't process it's message queue any more. However, the message queue still exists (for some time) and can still accept messages, which won't be processed any more.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
PostMessage 返回一个
BOOL，告诉您该消息是否是否已发布。这通常就足够了，因为您的窗口在收到WM_DESTROY和WM_NCDESTROY消息之前应该一直有效。调用 DestroyWindow （发送这些消息）后，您不应该能够再次调用PostMessage成功。现在，如果您的 PostMessage 返回 FALSE，您必须进行清理。如果没有，窗口消息处理程序就必须清理。不要将必须清理的消息发送到可能无法处理它们的随机窗口。实际上，不要向您不处理的任何窗口发送任何
WM_USER+ x 消息。PostMessage returns a
BOOLthat tells you whether the message was posted or not. This is usually good enough, because your window should be valid until it receives theWM_DESTROYand theWM_NCDESTROYmessages. After a call to DestroyWindow (which sends these messages) you should not be able to successfully call PostMessage again.Now, if your PostMessage returns FALSE you have to clean up. If it doesn't, the window procedure has to clean up. Don't send messages that have to be cleaned up to random windows that might not handle them. Actually, don't send any
WM_USER+ x messages to any windows you don't handle.这里没什么可做的。一旦对 SendMessage 的调用返回，您就可以释放数据。碰巧的是，另一个应用程序不会查看您的内存，因为它处于不同的进程中。相反，Windows 跨进程边界封送数据。
更重要的是，如果您在 WndProc 中接收数据，则无法获取指向字符串的指针的副本。相反，您必须获取字符串内容的副本，因为该指针仅在调用 WndProc 期间有效。
另一点是您对消息队列感到困惑。当您发送消息时，消息同步发生并且不涉及队列。消息队列是放置发布消息的地方。它们是异步处理的。
There's nothing to do here. As soon as the call to SendMessage returns, you can free the data. As it happens, the other app isn't looking at your memory anyway since it's in a different process. Instead Windows marshals the data across the process boundary.
What's more, if you are receiving the data in a WndProc, you can't take a copy of the pointer to the string. Instead you must take a copy of the contents of the string since that pointer is only valid for the duration of that call to WndProc.
The other point to make is that you have a confusion about the message queue. When you send a message, that happens synchronously and the queue is not involved. The message queue is where posted messages are placed. They are process asynchronously.