9

我们目前正忙于从 Visual Studio 2005 迁移到 Visual Studio 2010（使用非托管 C/C++）。这意味着我们大约一半的开发人员已经在使用 Visual Studio 2010，而另一半仍在使用 Visual Studio 2005。最近，我遇到了一种情况，可以在 Visual Studio 2010 中以干净的方式编写某个结构，但是在 Visual Studio 2005 中需要不太干净的源代码。因为并非所有开发人员都已经在他们的机器上安装了 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

由于所有开发人员都将在今年年底之前迁移到 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 compilation_date is after 1 november 2010
#   error "Remove Visual Studio 2005 compatibility code from this file"
#endif

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

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

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

4

4 回答 4

15

如果是 GNU make，我会这样做：

CFLAGS += -DCURDATE=$(shell 日期 +%Y%m%d)

它将CURDATE向编译器标志添加一个宏，其中包含 YYYYMMDD 格式的当前时间。

所以在源代码中你可以做这样的事情：

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

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

于 2010-09-01T07:47:29.940 回答
6

Personally, I would choose to disbelieve that everyone will actually migrate by the expected date. Even if I'm confident that it's going to happen, I don't want to create extra work for anyone, or stop them working, in the event that I'm wrong.

If nothing else, builds should be reproducible. What if, in December, you realise that you need to reproduce a build from October? You can't (at least, not without bodging the clock on the build machine), because it won't compile any more.

So, I'd do this:

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

Once everyone has VS 2010, change support2005.h to contain #error "Remove Visual Studio 2005 compatibility code from this file".

Actually I personally wouldn't check that change in, since it will prevent anyone from doing any work until VS 2005 support is removed. Is removing dead code really the highest priority task your company might possibly have on the morning of 1st November? And does it require all hands on deck to do that? Rather, I would check out, delete the file, do a full build, keep removing compatibility code until everything build again, and check the whole thing in as, "remove VS 2005 support".

You say you're worried you might forget, but if you do, so what? The dead code isn't hurting anyone. You'll remember it the next time you look at any of those files, or the next time you see "support2005.h" in a file list, header dependency graph, etc. So it's not "making the source code unreadable long-term", because long-term anyone who sees it can just ignore or delete it. If you have any kind of issue-tracking software, you could find the first milestone targetted after 2010-11-01, and attach a task to it, "remove VS 2005 support, and get rid of support2005.h", with a note that this is currently blocked by developers still using VS 2005.

If you really want 2010-11-01 to be a hard deadline, after which the code breaks, then just stay up until midnight on Halloween, and check in the breaking change then. It doesn't actually break the code, as you requested, but it does break anyone who refreshes from source control, and hence presumably it breaks the build. Most importantly, it's very easily reversible, or can be suppressed locally, if it turns out to stop someone getting work done.

于 2010-09-01T11:25:35.090 回答
2

我只是使用预处理器定义，如#ifdef WARN_OLD_COMPAT. 使用延迟邮件，您将记住您对此进行了定义。

其他方式无法检查编译日期是否晚于 <X>。

于 2010-09-01T07:11:12.843 回答
1

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

于 2010-09-01T07:14:10.017 回答