我一直负责更新一系列性能至关重要的VB.NET应用程序，这些应用程序基本上只是监视和返回networking统计信息。 我只有三个要求： 将其转换为C＃，使其快速，并使其稳定
一个警告是，我们“可能”从.NET平台迁移到Linux “很快”
我将来会负责维护这些应用程序，所以我想这样做。 我已经决定根据MVP模式来重构这些应用程序，以便我可以正确地unit testing这个坏男孩的地狱。 但是自从我使用MVP以来，我也一直在想，我也可以在本地C / C ++代码中执行计算量大的代码，而GUI将使用.NETforms或Qt或其他方法完成。
问题：
C＃移动操作挂起，而不是立即抛出exception
在安装期间为每个客户端分配唯一的ID
Process.WorkingSet64和Process.PeakWorkingSet64之间的区别
WPF应用程序失去触摸function
在Windows上生成ActivityTracing事件日志
在WinForms中做一个graphics用户界面是否有意义，但是在本地的，非托pipe的C / C ++中是否是昂贵的东西？
对于适合上述场景的良好跨平台窗口套件的任何build议？
当有人试图运行我的.net桌面应用程序时，如何强制“运行方式”表单出现？
如何在.NET应用程序中正确实现“以pipe理员身份”或“以pipe理员身份运行”选定的操作？
创buildXML文件，赋予所有Windows帐户用户以写权限
首先，我会花一些时间尝试一些VB.NET到C＃转换器 。 你基本上是在移植语法，如果你不需要手动的话就没有理由去做。 当然，你可能需要清理转换器中的内容，但是这比转换更好。
现在，至于你的问题：
1）在WinForms中做一个图形用户界面是否有意义，但是在本地的，非托管的C / C ++中是否是昂贵的东西？
还没。 等到你完成了转换，然后找出你在哪里花费你的时间。 没有理由继续混合使用C / C ++，直到你发现它是必要的。 您可能会发现，放入不安全的C＃就足够了。 即使这可能是不必要的。 您可能只需要优化算法。 找出你的瓶颈， 然后决定如何解决它们。
2）对于适合上述场景的良好跨平台窗口套件的建议？
我肯定会看单声道 。 如果你使用C＃，那真的是你能做的最好的。 当/如果你移动到Linux，它几乎是单声道或另一种语言重写。
1）过早的优化是邪恶的。 在C＃中实现你的“昂贵的东西”，看看你是否需要重构它。 或者，至少建立一个测试，可以让你确定这一点。
2）Yowch。 跨平台UI。 我不会忍受“可能”的东西。 钉下黄鼠狼; 你怎么可能做出设计决定而不知道你在设计什么？ 如果你使用纯.NET实现，那么他们是否会抱怨，如果你必须（至少）重构它在Mono中工作？ 如果你用Java创建它，会不会觉得它看起来丑陋，用户抱怨他们在所有这些.jar中找不到它们的.exe文件？
1）不一定。 我认为用C ++编写后端代码可能是值得的，不管性能如何。 即使你不能把平台上的高层平台关在平台交换机上，但是为了应对这种可能性，你应该谨慎，因为管理类型往往会在没有理由（或警告）的情况下改变主意。 即使他们现在决定不转换，也不意味着他们不会决定从现在起六个月内转换。 现在用C ++编写你的逻辑，知道这是一种可能性，虽然比较困难，但以后可能会让你的生活变得更加容易。
2）不是真的。 有像wxWindows和GTK＃这样的“解决方案”，但是它们通常是越野车，或者难以正常工作，或者在一个平台或者另一个平台上缺少重要的东西。 他们通常也把你锁定在一个最低公分母的UI（即一般的控制工作正常，但你可以忘记做一些有趣的事情 – 例如WPF）。 用户界面很容易编写，所以我认为如果你将自己的逻辑写入可移植的东西，把几个特定于平台的用户界面合并在一起应该是一件小事。
对于第一个问题，真的很难说是否合理，因为这可能取决于你需要获得什么样的表现。 我个人还没有看到由于使用WinForms而设计的图形用户界面中的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
你可能想看看使用单声道 。 这是一个在许多平台上运行的.NET的开源版本。Linux，Mac，Solaris，Windows等。
现在关于在C / C ++中编写你的昂贵的东西。 下面是一篇很好的解释C / C ++和C＃性能差异的文章。
再一次，让我强调，C ++的东西是veerrrryyyy昂贵的。 做上面提到的是否有意义？ （.NET窗体隐藏繁重的C ++）
如前所述，我个人并没有注意到在VB.NET和C＃编写的应用程序中由于WinForms而造成的系统级缓慢下降。 但是，如果应用程序确实是性能密集型的，那么如果您使用C＃编写所有内容，那么您可能会注意到速度略有下降，因为它被编译进CIL（ http://www.cl.cam.ac.uk/research/srg/han / hprls / orangepath / timestable-demo / ）。 因此，使用C＃等语言编写GUI可能会使开发的这一部分变得更容易，从而使您有更多的时间来处理代码的关键部分。 由于C＃代码中的C / C ++代码的调用，这里唯一的catch-22可能会注意到一些缓慢的下降; 不过，这可能不太可能。
1）在WinForms中做一个图形用户界面是否有意义，但是在本地的，非托管的C / C ++中是否是昂贵的东西？
很可能不是。 除非你和很多其他的本地C dll交流，否则C＃可能比C ++慢5％到5％（如果你使用的话，std :: string真的会杀死你）
2）对于适合上述场景的良好跨平台窗口套件的建议？
如果只是一些简单的按钮形式，单声道可能会运行它们未经修改。 这是对.NET的支持WinForms现在是相当不错的。 然而，它是丑陋的:-)
我可能会误解这个问题 ，但如果是网络监控系统，为什么不把它写成“专用”的Windows服务呢？
VB.NET不应该比C＃慢很多。 我不是100％确定如果生成的IL代码有任何大的差异，但唯一的好处（和C＃重写它的正当理由）我能想到的（除了C＃有一个更好的语法和一些其他的好东西）是使用不安全的代码块，可以加快一点点。
C / C ++的东西可能最终是一个好主意，但现在YAGNI。 与Linux的东西一样。 忽略它， 你不需要它，直到你需要它。 保持简单 。 正如你所说，单元测试了它。 获取代码工作并从那里发展设计 。
我曾经有过类似的困境，同时试图找到一种开发基于PC的硬件测试工具（显然是指“使用UI选项”）与嵌入式硬件（通过PCMCIA接口）交互的最佳方法。
瓶颈在于测试应该在测试仪规定的时间的最大偏差10ms处运行。
例如：如果测试人员创建以下测试序列：
1.远程启动H / W
2.等待50ms的延迟。
3.阅读H / W信息。
在步骤2中提到的延迟不应该> 60ms。
我选择了C ++ WIN32应用程序作为我的后端和用于UI开发的VC ++ 2005 Winform（.NET平台）。 有关如何连接这两个的详细信息在msdn中可用
我这样隔离系统：
在VC ++ .NET中：
1. UI具有关于硬件的完整信息（通过后端应用程序读取）并按需控制硬件。 （按钮，组合框等..）
2.用户界面运行时间关键的测试序列（如上例中所述）。
3.收集这些信息并以时间线性格式（即，按照其必须执行的步骤的精确顺序）建立流（文件流）。
4.使用WIN32后端应用程序触发和握手机制（通过重定向标准输入和标准输出）。 公共资源将是文件流。
在C ++ WIN32中：
1.解释输入文件流。
2.与H / W的互动
整个系统正在运行。 这似乎是相当稳定的。 （没有上面提到的时间偏差）。
请注意，我们使用的测试PC仅用于H / W测试目的（它只有在其上运行的UI，没有自动更新，病毒扫描等）。
gtk-sharp是一个非常不错的跨平台工具包。
Gtk＃是一个用于mono和.Net的图形用户界面工具包。 该项目绑定了gtk +工具包和各种GNOME库，使用Mono和.Net开发框架实现了完全原生的图形化Gnome应用程序开发。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
