小编Mar*_*ark的帖子

有没有人使用makefile进行Visual Studio C++构建(在VS 2005下)而不是使用项目/解决方案设置.对于我们来说,项目/解决方案的工作方式并不直观,当您尝试使用特定的编译时标志调整构建时,会导致配置爆炸.

在Unix下,很容易设置一个makefile,其默认选项被用户设置(或其他配置设置)覆盖.但是在Visual Studio中执行这些类型的操作似乎很困难.

举例来说,我们有一个项目需要为3个不同的平台构建.每个平台可能有多个配置(例如调试,发布和其他几个).我在新成立的项目中的目标之一是拥有一个可以让所有平台构建在一起的解决方案,这使得构建和测试代码更改变得更容易,因为您不必打开3个不同的解决方案来测试代码.但visual studio将需要3*(基本配置数)配置.即PC Debug,X360 Debug,PS3 Debug等

看起来makefile解决方案在这里要好得多.使用一些基本的批处理文件或脚本,可以很容易地将配置explotion保持在最低限度,并且只为我们必须执行的所有不同构建维护一小组文件.

但是,我没有在visual studio下使用makefile的经验,并且想知道其他人是否有他们可以分享的经验或问题.

谢谢.

(编辑后发现这些是C++版本)

在VS的外部工具设置下,有一个"使用输出窗口"复选框,用于捕获工具命令行输出并将其转储到VS选项卡.

问题是:当我点击F5时,我可以为我的程序获得相同的处理吗？

编辑: FWIW我在C#但是如果这对你的答案有所影响那么你的答案就不太可能是我正在寻找的.

我想要的是获取程序的输出流并使用输出重定向('|'和'>')在cmd提示符中使用的相同设备将其传输到VS中的输出选项卡.

我对Windows 7注册表问题感到困惑,虽然各种问题和答案让我在那里找到了一些方法,但我见过的那些问题解决了我的特定问题.我不知道其他Windows版本是否会影响这个问题,但我们都有win7x64机器.

我们的工作中有各种各样的工具,一些C++,一些C#,一些python(2.6)等.我们还运行32位和64位工具.在过去,我们很高兴地存储了注册表信息HKLM.我们一直在努力将东西转移到HKCU.我们已经就是否要这样做,影响UAC等进行了很多讨论.我们真的想尝试做出这一举动.那说:

我们无法读取/写入注册表项HKCU/software/CompanyABC/App.我们app在python中进行了一次设置编写,使用将注册表项写入上述位置_winreg.我们是否指定KEY_WRITE| KEY_WOW64_32KEY或只是KEY_WRITE,值被写入HKCU/Software/WOW6432Node/companyABC/app.精细.

然后我有一个C#应用程序试图读取这些值.使用Microsoft.Win32.Registry,我打开子键('HKCU/Software/CompanyABC/app'),我看不到我的值.事实证明我看到以下行为:

• 当读取/写入注册表项时HKLM,这些东西都可以正常工作.python应用程序将写入HKLM/Softare/Wow6432Node/CompanyABC/app,C#代码将从该位置读取.考虑到我们如何构建C#应用程序以及通过python编写注册表值,这一切都是正确的
• 从HKCU读取/写入注册表值,我得到不同的行为.该_winreg功能将写入HKCU/Sofrware/Wow6432Node/CompanyABC/app,但C#应用程序会读取HKCU/Software/CompanyABC/app.C#应用程序是作为x86应用程序构建的(不是任何CPU而不是x64)所以我假设应用程序将被正确地重定向到wow6432Node,但它似乎没有.

经过一番调查,似乎HKCU/Software有所不同. 此文章似乎表明,这个区域是"共享",而不是重定向.如果是这样的话,那么我不明白为什么我们的Python应用程序(再次使用_winreg)被写入到HKCU使用了一个位置Wow6432Node-它似乎应该没有地方可以重定向写它.我想这可能是一个错误_winreg.

我真的希望避免WOW6432Node明确地使用我们的工具,但这就是我今天所处的位置.任何人都可以向我解释如何使32位和64位进程的注册表访问HKCU正常工作,而不必求助于32位配置单元的硬编码路径？

我正在拼命寻找降低家用电脑上构建时间的廉价方法.我刚刚阅读了一篇关于在Windows XP上禁用文件的上次访问时间属性的文章,因此简单的读取不会将任何内容写回磁盘.

这也很简单.在DOS提示符下写:

fsutil behavior set disablelastaccess 1

有没有人在构建C++项目的环境中尝试过它？有什么缺点吗？

[编辑]有关此主题的更多信息.

我的工作室拥有超过10年的大型代码库.我们开始使用的编码标准是在内部开发人员很少的情况下开发的,早在我们不得不担心与C++相关的任何标准之前.

最近,我们在内部开展了一个小型研发项目,我们更新了我们的编码惯例,使其更适合我们的环境.研发工作将集成到现有项目代码中.我们面临的一个主要问题是,我们现在对这两个工作领域有两个标准,现在代码库将会交叉.我不想在工作室有两个标准,我真的很乐意用一个标准来推进.(我们如何进入这种情况的"方式"并不重要 - 只是我们是,而且我曾希望我们不会这样做.)

问题是重构现有代码.我不太热衷于有两个代码库(一个相对较小,一个非常大)看起来不同.我有兴趣对现有的一个代码库进行一些重构,使其符合其他标准.问题是,较小的代码库是(IMO)更令人向往的标准.

我开始寻找可以为我做大规模重构的工具.我对重新排列和收紧代码不感兴趣.我有兴趣改变这样的事情

class my_class {}
....
class my_class A;

至

class MyClass {}
....
class MyClass A;

基本上做功能/变量级重命名.我不想使用像Visual Assist这样的东西,因为这需要很长时间.我有超过10000个源/头文件,包含数十万行代码.一次使用VA一个类将是一个时间杀手,不值得努力.

我确实在另一篇关于SO的帖子中遇到了Vera.这似乎可以完成这项工作并做得很好.我想知道是否有人具有使用Vera的特定经验,以了解我所处的情况,或者对可能完成工作的工具有任何其他建议.我认为这个工具实际上理解代码结构很重要,这样我们就不会只是以搜索/替换方式重命名变量,因为如果不仔细完成,这将导致细微的错误.

编辑:虽然我的例子显示我将从名称之间使用_转换为camelcase类型表示法,但对我们来说,移动另一种方式可能更有利.我真的在寻找一种有助于大规模重命名的通用解决方案.

谢谢.