我目前正在开发一个标准的 Windows 桌面应用程序（标准意味着没有花哨的东西：只有按钮、文本、滑块等），并且在研究了一些 GUI 框架并被排斥后决定自己编写一个 GUI 框架他们都。由于这是一个业余项目，我也愿意尝试，并决定使 GUI 立即模式，而不是保留模式，因为我非常喜欢它简化代码的方式。不过，这里有一个问题：

当将即时模式 GUI 用于典型桌面应用程序时，与保留模式 GUI 相比，使用即时模式 GUI 对性能有何影响？

我总是听说 IMGUI 的性能更差，因为它必须重绘每一帧（或者，如果它以某种方式缓存，它仍然必须每帧都执行逻辑）。但我们在这里谈论的还有多少？我是不是消耗了两倍的 CPU 时间？更多的？如果我假设运行 20 个 IMGUI 程序，它会最大限度地使用 CPU（假设我已经对其进行了优化）？我只是想知道大概情况以及权衡在非游戏环境中是否仍然可行，在这种环境中无需重新绘制每一帧。

还有一个我不明白的关于延迟的含义。在章讨论IMGUI的工作正在进行书由约翰内斯Norneby，解释如下：

框架剪切

在实时应用程序的上下文中需要注意的 IMGUI 的一个方面（每秒不断渲染新帧多次）是用户交互将始终响应在前一帧上绘制的内容。这是因为用户界面必须至少绘制一次，以便用户知道那里有要与之交互的小部件。大多数情况下，如果帧速率足够高，这不会导致任何问题，但这是需要注意的。

这在保留模式 GUI 中有何不同？这是否意味着我在保留模式的 GUI 上多了一个输入延迟帧？

我最近在研究噪声函数，即柏林噪声和单纯形噪声。我对噪声算法没有任何疑问，因为我已经启动并运行了它们，但我对 ken perlin 使用的哈希方法有一些疑问：

一些背景：

因此，在这些噪声函数中，每个坐标都需要一个（伪）随机值。在 Ken Perlins 的实现中，他使用查找表来获取这些值：

static const U8 perlin_hash_values[] = {
151,160,137, 91, 90, 15,131, 13,201, 95, 96, 53,194,233,  7,225,
140, 36,103, 30, 69,142,  8, 99, 37,240, 21, 10, 23,190,  6,148,
247,120,234, 75,  0, 26,197, 62, 94,252,219,203,117, 35, 11, 32,
57,177, 33, 88,237,149, 56, 87,174, 20,125,136,171,168, 68,175,
74,165, 71,134,139, 48, 27,166, 77,146,158,231, 83,111,229,122,
60,211,133,230,220,105, 92, 41, 55, 46,245, 40,244,102,143, 54,
65, 25, 63,161,  1,216, 80, 73,209, 76,132,187,208, 89, 18,169,
200,196,135,130,116,188,159, 86,164,100,109,198,173,186,  3, 64,
52,217,226,250,124,123,  5,202, 38,147,118,126,255, …

语境：

我正在开发一个需要快速访问大文件的应用程序，因此我使用内存映射。memcpy阅读和写作因此变得简单。我现在正在尝试添加中止任何正在进行的读取或写入的功能。

我想到的第一件事（因为我不知道任何可中断的 memcpy 函数）是定期检查memcpy几KB并检查操作是否应该中止。如果读取速度相当快，这应该可以确保近乎瞬时的中止。

如果不是，那么应用程序不应该花费很长时间才能中止，所以我的第二个想法是使用多线程。memcpy 发生在它自己的线程中，控制线程使用WaitForMultipleObjects发出中止信号的事件和 memcpy 线程。如果中止事件收到信号，它将杀死 memcpy 线程。然而，TerminateThread 的文档指出，应该绝对确保不会因为不释放资源而使系统处于不良状态。

问题：

memcpy 是否会执行任何操作，导致在复制映射内存时杀死它变得不安全？这样做安全吗？它是否依赖于实现（使用与 Windows x86-64 不同的操作系统/体系结构）？

我确实意识到使用第二种方法可能完全是矫枉过正，因为实际上没有 1KB 读/写会花费那么长时间，但我只是想安全一点。

#include <stdio.h>

void print(int a = __LINE__){printf("hello %d\n", a);}

void main(){
  print();
  print();
  print();
  print();
}

本例中的宏__LINE__扩展为 3，因此使用相同的值调用 print 函数 4 次。有没有办法说服编译器在调用点扩展此宏，以便使用 C++11 中存在的功能6,7,8,9而不是调用 print 函数？3,3,3,3

我的用例：

在我的应用程序中，我提供了多个采用唯一 ID 的函数。每个调用站点/位置的 ID 应该是唯一的（因此，如果通过同一语句调用该函数两次，它应该收到相同的 id）。目前，用户始终必须LOCATION在调用站点手动键入宏，如下所示：

#define S1(x) #x //voodoo to concat __FILE__ and __LINE__
#define S2(x) S1(x)
#define LOCATION __FILE__ S2(__LINE__)

do_stuff1(arguments, LOCATION)
do_stuff2(arguments, LOCATION)

如果我可以节省他们的打字时间，而不需要为每个函数创建宏，如下所示，那就更方便了：

#define do_stuff1(do_stuff1_imp(arguments, LOCATION))
#define do_stuff2(do_stuff2_imp(arguments, LOCATION))

因此我认为默认参数可以解决问题。有什么办法可以实现这一点吗？