无论出于何种原因,我们公司都有一个编码指南,规定:
Each class shall have it's own header and implementation file.
因此,如果我们编写一个名为的类,MyString我们需要一个关联的MyStringh.h和MyString.cxx.
还有其他人这样做吗？有没有人看到任何编译性能影响？10000个文件中的5000个类的编译速度是否与2500个文件中的5000个类一样快？如果没有,差异是否明显？
[我们编写C++并使用GCC 3.4.4作为我们的日常编译器]
有没有人有战斗故事分享尝试使用Visual Studio开发Unix的应用程序？而且我不是在使用.NET,而是使用运行在下面的Mono或Wine虚拟平台.
我们公司有大约20名开发人员都在运行Windows XP/Vista,主要是为Linux和Solaris开发.直到最近,我们都以一种老式的方式登录了一个主Linux服务器并修改/构建了代码:Emacs,Vi,dtpad - 随你挑选.然后有人说,"嘿 - 我们生活在黑暗时代,我们应该使用IDE".
所以我们尝试了一些,并决定Visual Studio是唯一能满足我们性能需求的(是的,我确信IDE X是一个非常好的IDE,但我们选择了VS).
问题是,如何设置环境以使文件在本地可用于VS,但也可用于构建服务器？我们决定编写一个Visual Studio插件 - 每当我们点击"保存"时它就会在本地写入我们的文件和构建服务器,并且当我们的文件在服务器端发生变化时,我们可以推送一个"胖"同步按钮(当时我们从源代码管理服务器更新到最新文件.
该插件还使用Visual Studio的外部构建系统功能,最终只是ssh进入构建服务器并调用我们的本地"make"实用程序(Boost Build v2 - 具有很好的依赖性检查,但结果很慢,即30- 60秒开始).结果通过管道传送回Visual Studio,因此开发人员可以单击错误并转到相应的代码行(实际上非常流畅).构建服务器使用GCC并交叉编译所有Solaris构建.
但是即使在我们完成所有这些工作之后,每当我开始在Visual Studio中编写代码时,我都会忍不住感叹.我点击一个文件,开始输入,然后VS chugs赶上我.
还有什么比不得不停下来等待你的工具更烦人了吗？这些好处值得沮丧吗？
思想,故事,帮助？