我的任务是更新一系列对性能至关重要的VB.NET应用程序，这些应用程序实际上只是监视和返回网络统计信息。我只有三个要求：将其转换为C＃，使其快速运行并使其稳定

一个警告是，我们"可能"从.NET平台"很快"迁移到linux。

将来，我将负责维护这些应用程序，所以我想这样做。我决定根据MVP模式重构这些应用程序，以便可以正确地对这个坏男孩进行单元测试。但是我也一直在思考，因为我使用了MVP，所以我也可以用本机C / C ++代码来完成计算上昂贵的工作，而GUI可以使用.NET形式或者Qt或者其他形式来完成。

问题：

• 在winforms中创建GUI而不在本机，非托管C / C ++中进行昂贵的设计有意义吗？
• 对于适合上述情况的优质跨平台窗口工具包，有何建议？

解决方案

回答

1)过早的优化是邪恶的。在Cand中实施"昂贵的东西"，看看是否需要对其进行重构。或者，至少要设置一个测试来确定这一点。

2)Y。跨平台用户界面。我不会忍受"可能"的东西。将黄鼠狼钉下来；在不知道自己在设计什么的情况下，如何做出设计决策？如果我们使用纯.NET实现，他们是否会抱怨我们是否必须(至少)重构它以在Mono中工作？如果我们使用Java创建它，他们是否会因为看起来像丑陋的地狱而感到烦恼，并且用户抱怨他们无法在所有这些.jars中找到他们的.exe文件？

回答

对于第一个问题，很难说这是否有意义，因为这很可能取决于我们需要获得哪种性能。由于使用正确设计的使用WinForms的GUI中的GUI，我个人还没有看到系统范围内的速度下降，因此我不明白为什么它会引起任何问题，并且很可能会使GUI生活变得更轻松。

关于第二个问题，如果我们打算在某个时候转移到另一个平台，则需要查看Mono(http://www.mono-project.com/Main_Page)已实现的库，由于它支持WinForms和GTK＃，因此还应该满足跨平台窗口方面的大多数需求。

回答

不，在C / C ++中进行"昂贵的工作"没有任何意义。与C＃相比，潜在的(并且很可能是次要的)性能改进永远不会超过生产率是一个令人生厌的恶作剧。真的。还差得远

通读以下内容(以及其中引用的所有帖子)：
http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx

回答

1)不一定。我认为，不考虑性能影响，也许值得用C ++编写后端代码是更正确的说法。即使我们不能将较高的职位束缚在平台交换机上，也要为这种可能性做好准备，因为管理类型往往会在没有充分理由(或者警告)的情况下改变主意，这是谨慎的做法。即使他们决定现在不切换，也不意味着他们不会在六个月后决定切换。现在，用C ++编写逻辑，尽管知道这是一种可能性，尽管难度更大，但以后可能会使生活变得更加轻松。

2)不是。有" wxWindows"和" GTK＃"之类的"解决方案"，但通常它们都是错误的，或者很难正常工作，或者它们在一个或者另一个平台上缺少重要的内容。它们通常还会将我们锁定在最低公分母的UI中(即，常规控件可以正常工作，但我们可能会忘记曾经用它做一些有趣的事情-WPF)。 UI易于编写，因此我认为，如果我们以可移植的方式编写逻辑，将几个特定于平台的UI组合在一起应该是一件小事。

回答

我们可能想研究使用Mono。这是.NET的开源版本，可在许多平台上运行... Linux，Mac，Solaris，Windows等。

现在开始使用C / C ++编写昂贵的代码。这是一篇非常出色的文章
解释C / C ++与Cperformance之间的差异的工作。

回答

And again, let me emphasize, the C++ stuff is veerrrryyyy expensive. Would it make sense to do what I mentioned above? (.NET forms hiding heavy lifting C++)

如前所述，由于使用VB.NET和C＃编写的应用程序中的WinForms，我个人还没有注意到任何系统范围的速度下降。但是，如果该应用程序确实是性能密集型的，那么如果我们使用Cd编写了所有内容，则可能会注意到它的运行速度稍有下降，因为它已被编译为CIL(http://www.cl.cam.ac.uk/research/srg/han/ hprls / orangepath / timestable-demo /)。这样，用C之类的语言编写GUI可能会使开发的这一部分更加容易，这将使我们有更多的时间来处理代码的关键部分。这里唯一的问题22可能是由于从Ccode调用C / C ++代码可能会注意到速度有所下降。但是，这不太可能发生。

回答

我可能会误解这个问题，但是如果它是网络监视系统，为什么不将其写为"专用" Windows服务？

VB.NET不应比C＃慢很多。我不确定100％是否在生成的IL代码中有任何大的差异，但是我能想到的唯一优点(以及用C＃重写它的合理理由)(除了Chave更好的语法和一些其他优点)使用不安全的代码块可能会加快速度。

回答

首先，我将花一些时间尝试一些CBverter的VB.NET。我们基本上是在移植语法，如果没有必要，没有理由手工这样做。当然，我们可能必须清理转换器中产生的内容，但这比手动转换要好。

现在，关于问题：

1) does it make sense to do a GUI in winforms but the expensive stuff in native, unmanaged C/C++ ?

还没有。等待直到完成转换，然后找出我们实际在哪里花费时间。我们发现没有必要跳入C / C ++与Cuntil的混合。我们可能会发现，放入不安全的Cis就足够了。即使那样也可能是不必要的。我们可能只需要优化算法。找出瓶颈，然后决定如何解决它们。

2) any recommendations for a good cross platform windowing kit that would fit for the scenario described above?

我肯定会研究单声道。如果要使用C＃，那确实是我们能做的最好的事情。当/如果我们转移到Linux，它几乎是单声道的，或者是另一种语言的另一种重写。

回答

1) does it make sense to do a GUI in winforms but the expensive stuff in native, unmanaged C/C++ ?

很有可能不会。除非我们与许多其他本机C dll等进行通信，否则Cis的速度可能比C ++慢5％至5％(如果使用它，std :: string确实会杀死我们)

2) any recommendations for a good cross platform windowing kit that would fit for the scenario described above?

如果只是带有按钮的一些简单表单，mono可能会在不修改的情况下运行它们。这些天对.NET WinForms的支持非常好。但是，它是丑陋的:-)

回答

gtk-sharp是一个非常不错的跨平台工具包。

Gtk# is a Graphical User Interface Toolkit for mono and .Net. The project binds the gtk+ toolkit and assorted GNOME libraries, enabling fully native graphical Gnome application development using the Mono and .Net development frameworks.

回答

c / c ++可能最终是一个好主意，但现在YAGNI。与Linux相同。忽略它，直到我们需要它时，我们才需要它。把事情简单化。正如我们所说，对它进行单元测试。使代码正常工作并从那里进行设计。

回答

一段时间以前，我遇到了类似的难题，同时试图找到开发与嵌入式硬件(通过PCMCIA接口)交互的基于PC的硬件测试工具(显然意味着"具有UI选项")的最佳方法。

瓶颈在于，测试应与测试仪指定的预期时间相差最大10毫秒。

例如：如果测试人员创建了以下测试序列：

1.远程激活硬件。2.等待50ms延迟。
3.阅读硬件信息。

步骤2中提到的延迟不应大于60ms。

我选择C ++ WIN32应用程序作为我的后端，并选择VC ++ 2005 Winform(.NET平台)进行UI开发。 msdn中提供了有关如何连接这两者的详细信息
我像这样隔离系统：
在VC ++ .NET中：

1. UI具有有关硬件的完整信息(通过后端应用程序读取)并按需控制硬件。 (按钮，组合框等。等等。)2.运行时间关键的测试序列的UI(如以上示例中所述)。
   3.收集这些信息并以时间线性格式(即，按照必须执行的确切步骤顺序)构建流(文件流)。
2. WIN32后端应用程序的触发和握手机制(通过重定向标准输入和标准输出)。通用资源将是文件流。

在C ++ WIN32中：

1.解释输入文件流。
2.与硬件的交互。
3.收集来自硬件的信息，并将其放入其输出文件流中。
4.向UI指示测试完成(通过重定向的标准输出)。

完整的系统已启动并正在运行。它似乎很稳定。 (没有上述定时偏差)。
请注意，我们使用的测试PC仅用于硬件测试目的(它只运行了UI，没有自动更新，病毒扫描等。)。