清单常量vs C ++关键字“const”

Question

阅读迈耶斯的书（第2项和第34期;更喜欢#define）我想了解下面列出的一些句子：

1. 参考#define ASPECT_RATIO 1.653和const aspect_ratio = 1.653之间的比较，Meyers要求＆＃34; ...在浮点常数的情况下（例如在本例中）使用常量可能比使用#define产生更小的代码。＆＃34; 问题是： 使用较小的代码Meyers意味着可执行文件的磁盘空间更小？ 为什么它更小？我认为这可能在32位系统上有效，因为在这种情况下，int（或指针）需要4个字节和一个双8字节。由于ASPECT_RATIO可能无法输入到符号表中，因此名称将替换为值，而在其他情况下，可能会使用指向唯一double值的const指针。在这种情况下，这个概念在64位机器上不再有效（因为指针和double是相同的字节数）。我不知道我是否解释了我的意思，特别是如果这个想法是正确的？

2. 然后迈耶斯要求＆＃34; ...虽然好的编译器不会为整数类型的const对象留出存储空间（除非你创建一个指针或对象的引用），但草率的编译器可能会，并且你可能不愿意留出内存对于这些物体......＆＃34; 在这种情况下，内存是执行过程占用的RAM？如果验证这个是正确的我可以使用任务管理器（在Win中）或顶部（在Linux中）？

Answer 1

首先，微观优化是愚蠢的。不要关心几个不断的双重值占用你所有的RAM。它不会发生。如果确实如此，那就处理它，而不是在你知道它甚至相关之前。

其次，如果使用过多，#define可能会产生令人讨厌的副作用，即使使用ALL_CAPS_DEFINES约定也是如此。迟早你会错误地制作一个在其他变量名称中使用的短宏，预处理器替换会给你一个不可思议和可避免的错误，根本就没有可调试性。正如问题评论中的链接问题所述，宏缺乏命名空间和类范围，并且在C ++中肯定是不好的。

第三，C ++ 11增加了constexpr，它允许类型安全的宏性能（无论这个误称是什么意思）常量表达式。甚至有些人（参见SO Chat中的C ++ Lounge）在编译时使用constexpr进行整个计算。不幸的是，并非所有主要的编译器声称支持C ++ 11，实际上支持足够的C ++ 11功能才真正有用（我在看着你，MSVC2012！）。

Answer 2

1. 它“可能”产生较小代码的原因是，定义的多次使用可能（可能：优化器做奇怪的东西）也会一次又一次地生成相同的常量。而使用const只生成一个定义，然后引用相同的定义（如果优化器不计算内联内容）。
2. 链接可执行文件时，链接器会输出多个部分。某些部分包含常量，其他部分包含可执行代码。在执行之前，您的（操作）系统是否将可执行文件加载到ram中，并未在C ++标准中定义。我已经使用了代码从闪存存储执行的系统，因此只有堆栈和动态分配的内存使用ram。