是否有可能有“超时”的源代码？（一定时间后无效）？

发布于 2024-09-17 08:39:37 字数 1214 浏览 11 评论 0原文

我们目前正忙于从 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 日期/时间函数。

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

原文

We are currently busy migrating from Visual Studio 2005 to Visual Studio 2010 (using unmanaged C/C++). This means that about half of our developers are already using Visual Studio 2010, while the other half is still using Visual Studio 2005. Recently, I came into a situation where a certain construction can be written in a clean way in Visual Studio 2010, but requires less-clean source code in Visual Studio 2005. Because not all developers have already Visual Studio 2010 on their machine, I have to write the code like this:

#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

Since all developers will migrate to Visual Studio 2010 by the end of this year, I want this code to 'disappear' automatically after a certain moment. Keeping the 'less clean version' in the source code results in unreadable source code in the long-term.

Of course, I know that code doesn't automatically disappear, so I actually want an automatic alarm bell after a certain moment. Something like this:

#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

That way, if we forget about this, we are automatically notified of this after 1 november 2010.

This trick probably requires the use of DATE, but since this needs to be handled by the precompiler, you can't perform string-manipulations or use the C date/time functions.

I also considered the alternative idea of just sending myself a delayed mail, but I was wondering if there wasn't a solution that could be built in in the source code.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

み格子的夏天 2024-09-24 08:39:37

如果是 GNU make 我会这样做：

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

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

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

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

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

In case of GNU make I'd do it like this:

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

It will add a macro CURDATE to compiler flags, that contains the current time in YYYYMMDD format.

So in source you could do something like this:

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

Can you do something like this in VS?

回复收藏 0 原文

这样的小城市 2024-09-24 08:39:37

就我个人而言，我会选择不相信每个人都会在预期日期之前真正迁移。即使我确信这会发生，我也不想为任何人创造额外的工作，或者阻止他们工作，以防万一我错了。

如果不出意外的话，构建应该是可重现的。如果在 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 以包含 #error“从此文件中删除 Visual Studio 2005 兼容性代码”。

实际上，我个人不会检查该更改，因为在删除 VS 2005 支持之前，它将阻止任何人进行任何工作。删除无效代码真的是您的公司在 11 月 1 日上午可能面临的最高优先级任务吗？是否需要所有人齐心协力才能做到这一点？相反，我会检查、删除文件、进行完整构建、继续删除兼容性代码，直到再次构建所有内容，然后将整个内容检查为“删除 VS 2005 支持”。

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

如果您确实希望 2010 年 11 月 1 日成为一个严格的截止日期，在此之后代码就会中断，那么只需熬夜到万圣节午夜，然后检查重大更改即可。它实际上并没有按照您的要求破坏代码，但它确实破坏了从源代码管理刷新的任何人，因此可能会破坏构建。最重要的是，如果它最终阻止某人完成工作，它很容易逆转，或者可以在本地被抑制。

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.

回复收藏 0 原文