C++ 是否可能有'；超时'；（某一时刻后失效）？

我们目前正忙于从VisualStudio2005迁移到VisualStudio2010（使用非托管C/C++）。这意味着大约一半的开发人员已经在使用VisualStudio2010，而另一半仍然在使用VisualStudio2005。最近，我遇到了这样一种情况：在VisualStudio2010中可以以干净的方式编写某个构造，但在VisualStudio2005中需要更少干净的源代码。由于并非所有开发人员的计算机上都已安装Visual Studio 2010，因此我必须编写如下代码：

#if _MSC_VER >= 1600
   // clean version of the source code
#else
   // less clean version
   // of the source code
   // requiring multiple lines of code
   // and requiring some dirty static_casts
#endif

#if _MSC_VER >= 1600
   // clean version of the source code
#else
   // less clean version
   // of the source code
   // requiring multiple lines of code
   // and requiring some dirty static_casts
#endif
#if compilation_date is after 1 november 2010
#   error "Remove Visual Studio 2005 compatibility code from this file"
#endif

#if CURDATE > 20101101
#error "Do whatever you have to do"
#endif

由于所有开发人员都将在今年年底迁移到VisualStudio2010，我希望这段代码在某一时刻后自动“消失”。在源代码中保留“不太干净的版本”会导致长期无法读取源代码

当然，我知道代码不会自动消失，所以我实际上希望在某一时刻后自动发出警报。大概是这样的：

#if _MSC_VER >= 1600
   // clean version of the source code
#else
   // less clean version
   // of the source code
   // requiring multiple lines of code
   // and requiring some dirty static_casts
#endif

#if _MSC_VER >= 1600
   // clean version of the source code
#else
   // less clean version
   // of the source code
   // requiring multiple lines of code
   // and requiring some dirty static_casts
#endif
#if compilation_date is after 1 november 2010
#   error "Remove Visual Studio 2005 compatibility code from this file"
#endif

#if CURDATE > 20101101
#error "Do whatever you have to do"
#endif

这样，如果我们忘记了这一点，我们将在2010年11月1日后自动收到通知

这个技巧可能需要使用日期，但由于这需要由预编译器处理，因此不能执行字符串操作或使用C日期/时间函数

---

我也考虑过向自己发送一封延迟邮件的替代方案，但我想知道是否在源代码中没有内置的解决方案。

我只会使用一个预处理器定义，如

\ifdef WARN\u OLD\u COMPAT

。对于延迟邮件，您将记住您要定义它

---

检查编译日期是否晚于其他方式是不可能的。

为什么不在dev builds中的运行时进行检查？当然你要测试你的代码，所以当有人在日期之后第一次测试它时，你会收到通知。

如果是GNU

make

我会这样做：

#if _MSC_VER >= 1600
   // clean version of the source code
#else
   // less clean version
   // of the source code
   // requiring multiple lines of code
   // and requiring some dirty static_casts
#endif

#if _MSC_VER >= 1600
   // clean version of the source code
#else
   // less clean version
   // of the source code
   // requiring multiple lines of code
   // and requiring some dirty static_casts
#endif
#if compilation_date is after 1 november 2010
#   error "Remove Visual Studio 2005 compatibility code from this file"
#endif

#if CURDATE > 20101101
#error "Do whatever you have to do"
#endif

CFLAGS+=-DCURDATE=$（外壳日期+%Y%m%d）

它将向编译器标志添加一个宏

CURDATE

，其中包含YYYYMMDD格式的当前时间

因此，在source中，您可以执行以下操作：

#if _MSC_VER >= 1600
   // clean version of the source code
#else
   // less clean version
   // of the source code
   // requiring multiple lines of code
   // and requiring some dirty static_casts
#endif

#if _MSC_VER >= 1600
   // clean version of the source code
#else
   // less clean version
   // of the source code
   // requiring multiple lines of code
   // and requiring some dirty static_casts
#endif
#if compilation_date is after 1 november 2010
#   error "Remove Visual Studio 2005 compatibility code from this file"
#endif

#if CURDATE > 20101101
#error "Do whatever you have to do"
#endif

---

你能在VS中做这样的事情吗？

就我个人而言，我不相信每个人都会在预期的日期之前迁移。即使我相信这会发生，我也不想为任何人创造额外的工作，或者在我错的情况下让他们停止工作

如果没有其他内容，构建应该是可复制的。如果在12月份，您意识到需要从10月份复制构建，该怎么办？你不能（至少，在构建机器上没有预兆），因为它不会再编译了

所以，我会这样做：

support2005.h
-------------

// empty file

source file
-----------

#include "support2005.h"
#if _MSC_VER >= 1600
   // clean version of the source code
#else
   // less clean version
   // of the source code
   // requiring multiple lines of code
   // and requiring some dirty static_casts
#endif

一旦每个人都拥有VS 2010，将support2005.h更改为包含

#错误“从此文件中删除Visual Studio 2005兼容性代码”

实际上，我个人不会在中检查该更改，因为在VS2005支持被删除之前，它将阻止任何人做任何工作。在11月1日上午，删除死代码真的是贵公司可能拥有的最高优先级任务吗？这需要甲板上所有的人手吗？相反，我会签出，删除文件，进行完整构建，不断删除兼容性代码，直到所有内容都重新构建，然后将整个过程签入为“remove VS 2005 support”

你说你担心你可能会忘记，但如果你忘记了，那又怎样？死代码不会伤害任何人。下次查看这些文件时，或者下次在文件列表、标题依赖关系图等中看到“support2005.h”时，您都会记住它。因此，这不是“使源代码长期不可读”，因为长期来看，任何看到它的人都可以忽略或删除它。如果您有任何类型的问题跟踪软件，您可以找到2010-11-01之后的第一个里程碑，并在其上附加一个任务“删除VS 2005支持，并删除support2005.h”，注意，这目前被仍然使用VS 2005的开发人员阻止

---

如果你真的希望2010-11-01成为一个艰难的最后期限，在这之后代码就会中断，那么就在万圣节的午夜前熬夜，然后检查一下中断的更改。它实际上并没有按照您的要求破坏代码，但它确实会破坏任何从源代码管理刷新的人，因此它可能会破坏构建。最重要的是，它非常容易逆转，或者如果结果是阻止某人完成工作，它可以在本地被抑制。

听起来清理可以非常容易地编写脚本，因此，我不会费心插入额外的警告来提醒开发人员删除多余的代码。我更喜欢在编译时而不是在运行时检查。我也是这样做的，但在这种情况下，在运行时检查没有坏处。参数不错。您当然有一点是关于“构建应该是可复制的”。我不同意“死代码不会伤害任何人”的说法。死代码可能会/将使开发人员感到困惑。最近，我们遇到了一个问题，有人修改死代码，使其与内部数据结构中的更改一起工作。因此，我认为必须删除死代码（尽管11月1日可能不是一个好时机）。“support2005.h”的想法提出了一个更好的想法：为什么不使用/D_support2005来定义_support2005符号，如果这个符号不在这里，就让编译失败，但旧的代码仍然在这里。公平地说，我假设在您的组织中，大家都知道这个临时的2005支持是必要的。如果是这样的话，那么一旦不再需要它，它就不应该让任何人感到困惑或导致不必要的工作，因为任何想修改它的人都可以将其删除。我同意，出于您所说的原因，通常应该删除死代码。如果有人删除了旧代码，但没有删除头怎么办。下次他们看到错误时，他们将不知道需要做什么，因为所有的旧代码都已经不存在了！这个